Month: August 2020

IBM 1410 ALD to FPGA: Volume V complete – a “quickie”

No, not that kind of “quickie”. Instead, it is about Volume V of the ALDs – now tested – in just over a week! This was due to a couple of related factors. The first 30 pages were address registers – continuation from the end of Volume IV. Then after a few more pages, the memory address register pages were up.

The second factor was a new testing technique. For cases where there are and or and/or or or gates that are similar (fed from a character of storage or another register), I started using a test vector generated from an integer counter, and then checked the results using straight-forward logic equations derived from the Instruction Logic Diagrams (ILDs), which allows me to zoom through those kinds of pages.

I also evolved how I test control signals. I typically don’t test those exhaustively with a loop (especially when they feed a latch or trigger), but I started a copy-paste routine with the variables that lets me build the tests a bit more quickly.

I really wish VHDL had a macro facility or call by name (or reference) capability, though, so I could write procedures that modify signals in a test bench. It would allow me to write generic and, and/or and or tests for various numbers of variables. Sure, I could generate the HDL with an external program, but that would actually take more time than the copy/paste technique I am currently using.

Volume V is the first volume that uses NOR (primitive DTL) for actual logic. NOR logic also shows up in gated input interface signals, but that is a different animal. I was only about 90% confident of my interpretation of some of those circuits, but so far they have been spot on.

Volume V did present a few challanges. First, another missing page: page 14.18.04.1, part of the zone adder, was missing in action. It was clearly a copy/assembly error when the drawings were assembled – page 14.18.05.1 appears twice on both sides of the same sheet: one of those shoud be 14.18.04.1.

Now, I could easily have just replicated the ILD as equations, but I took it a bit further than that, consistent with what I have done on other missing ALD pages. Research based on the card location chart uncovered that I had one card at 11C3A16 (type DEV) entirely dedicated to this page, though the chart only showed four of the seven gates on that card actually being used. I also discovered that the card at 11C3A17 (type DFS) had 3 gates dedicated to the cause and by elimination of a gate or two that appeared on other sheets I was able to determine which gates/pins were “available”. I struggled for a day to make it work with just 6 gates (3 from the DEV and 3 from the DFS) but I couldn’t find a way. So in the end I drafted the remaining 3 gates from DEV (which are a AND/OR triad) to complete the task. While this doesn’t agree 100% with the card location chart, who is to say that the card location chart wasn’t quite right. 😉

I did find a couple of ILD errors in this volume. On page 17 of the ILD, relating to ALD page 14.30.06.1 a couple of signals are inverted and depicted as feeding OR logic. In reality, these signals are inverted on the inputs (-Y – negative active) and ANDed together. It happened because that ALD happens to depict a single NOR gate as two – one feeding the other – because that card has more inputs than can fit on a single logic block in an ALD. The symbols on the gates on the ALD do indeed imply that all the inputs are ANDed together, but if one didn’t spot that both blocks involved are the same card gate, one could easily misinterpret it. Curiously, the same thing happens on page 14.30.05.1 (the previous page), but in that case the engineer who prepared the ILD interpreted it correctly.

Those same blocks on those same two gates allowed me to leverage a feature on my application. When I entered those logic blocks, I realized that they were, in both cases, the same gates. However, since they are next to each other on the ALD they were not candidates for using the “extension” capability to combine them – there would have been room for that on the page, but they were not depicted as extensions. So I moved the inputs from one of the gates of the pair to the other, and removed the output from that first one as well. When I first tried generate the HDL, the application noticed the unconnected gate and generated a (harmless) error. However, a while back I added the ability to tell the application to ignore a given logic block when generating HDL. Worked like a charm.

Another case where I ran into that sort of thing was on the real time clock, where a given switch “deck” was split in two, and also the block title — which I used to generate the name of a switch signal — was replicated between decks. In order to generate this correctly I had to tweak the logic block titles to separate them, and join the switches together in the test bench.

The ILD’s also, generally, did not include the gates for address wraparound from x9999 to 00000 for 60K and 80K – only for 20K and 40K machines. The wraparound logic was present on the ALDs however, and was easy to decipher. (Wraparound for 100K is automatic because there are only 5 digits of addressing. 10K machines to no support wraparound at all, if I recall correctly)

I discovered a typo on a signal name on page 14.17.10.1 “-S AR BUS GRD OUT THP0B” — GRD should be GTD (gated).

ILD figure 24 had an error relating to page 14.16.04.1 om calculating the Address Register Exit Channel “C” bit – at the least it didn’t match the ALD. In general I defer to the ALD after carefully checking the logic, figuring that the ALDs are later in the timeline than the ILDs.

I also found a case of a misleading signal name, where the signal name implies two factors in an AND, when there are actually three. However, going back I can’t seem to find it – I will update this page if I come across it.

Finally, I have come to dislike a certain idiom that has appeared on a handful of sheets, where a pair of latches are ins sequence, usually named “… Control” and “…” where the output of “…” resets “…Control”. A real pain to devise a test bench.

IBM 1410 ALD to FPGA Another one bites the dust!

Volume IV now joins Volumes II and III as having had its Automated Logic Diagrams (ALDs) generated into VHDL and tested.

One interesting situation popped up on this volume, with respect to some missing pages. I was really struggling to test pages for the E and F channel File Controls, particularly the E and F Channel End of 2nd Addr Transfer (which is used to verify that the disk head is in the right place.) The relevant sheets (13.72.01.1 for the E channel and 13.73.01.1 for the F Channel) both depend on signals that potentially come from different kinds of disk drives: 1301, 1405 and 1311. These feed into logic that drives a trigger, and what was really confusing was that they were using one common set of signals to both set and reset the trigger – which, left on its own, would simply switch back and forth between its on and off states. I finally figured out that the signals coming from the 1311 were designed as relatively short-lived signals that would go away once the trigger was set. It was all complicated by the fact that three sheets relating to the 1311, 13.73.03.1, 13.73.04.1 and 13.73.05.1 are not in my diagram set – presumably they were only supplied with machines that had the relatively late-coming (from the 1410’s point of view) 1311 disk drives.

So, while I could probably figure out how to make 1301 and 1405 disk drives interface to the CPU work the same way that they did back in the day, doing that with 1311 disks would provide a considerable challenge – I know what signals went in and out of each of those pages (aside from any that appeared on just those three pages), figuring out the logic with only the gate information to guide me would be tricky.

I also found a mistake I had made entering the data on one of the sheets for the B address register, which was easy to fix. (Unfortunately, I no longer recall exactly what the error was). Typos on signal names aside, I can count such errors on one hnad.

Finally, a kind of humorous note. The 1410 could be equipped with a “Real Time Clock”. This was a motor drive set of cams and switches that could be read under program control, storing a 4 digit number: HH:hh (HH is hours, hh is hundredths of an hour – but only to 2 hundredths of an hour resolution). This is described in the 1411 CPU Instruction-Reference 1411 Processing Unit Instructions and Special Features manual, S223-2698. On page 110 of that manual is a little picture, with dials representing the cam switches. Some engineer though it would be cute to set the time to “1410”, and the dials show those digits starting at the top, Unfortunately, the dials on the diagram are such that the top is the least significant digit, so the actual time would have read out as 0141, or 1AM plus 41 hundredths of an hour, not 2:10 PM. 😉

Volume IV has lots of registers, so the generated logic now includes many of the machine’s address registers.

IBM 1410 FPGA – A Tale of Two Sheets

I encountered my second missing Automated Logic Diagram (ALD) page: 13.64.03.1, which, based on the signals fed to it and which it produces, would, fortunately, have the same logic as page 15.41.10.1 – “E CH FULL CONTROL-ACC”. Page 13.64.03.1 is for the second, or F Channel.

The E Channel version uses 9 NAND gates and 4 drivers. However, based on the card location chart, the F Channel version, even though it would have corresponding logic, has TWENTY-ONE gates (some of those could be just load resistors) on card type DGR. These are ALL just INVERTERS. The card location chart also calls out 2 gates on card type DFS – also inverters, and one gate on card type AEK which uses equation (NOT IN1) OR IN2 to produce its output.

The F channel logic used up two cards slots plus parts of six others. The E Channel logic version used three card slots (probably in their entirety) and the drivers used parts of four other cards slots

What to do? As readers will likely know, you can’t do any real logic with just inverters. However, SMS card outputs can be hooked together with all but one of the gates so connected (or “DOT-ed”) having open collector outputs. Electrically, given the circuits on the DGR and DFS cards (as well as most others the IBM 1410 uses), if you follow that with an inverter you get OR => NOT, aka “NOR” logic. Now that we can do something with.

So, I wrote a VHDL test bench, based on the Intermediate Logic Diagram (ILD) that shows the necessary logic for the E Channel (and indicates the F Channel is the same), and tested that against the E Channel page to make sure my understanding of the logic was correct.

Then, as an exercise, with liberal application of DeMorgan’s theorems, I proceeded to lay out the logic for the F channel version in that fashion. It took 21 inverters (using the AEK as an inverter) and 1 load resistor (which I probably didn’t need to use) and eight DOT functions (ORs) to produce the necessary logic. So, pretty close, but not a perfect reproduction. One thing is an issue for sure: I “DOT-ed” two inputs together that come from other sheets whose outputs are used on still other sheets – which is generally a no-no. It would not have been that way on the original machine – they would need to be isolated by being fed into gates of some sort – even if only back to back inverters.

I could probably spend a bit more time, find a way to leverage the second input on the gate AEK, and get it more exact, but frankly, it isn’t worth the effort right now.