IBM 1410 ALD to FPGA Volume VIII complete – only two to go

Volume VIII started off pretty uneventfully, for a while. I did find another page (16.20.02.1) where a couple of gates have their internal connections brought to the edge of the sheet, but those are trivial to fix by adding “faux pins” to the gate definitions and using those on the sheet.

I continue to be somewhat surprised that I haven’t found very many connector errors – a testament to the value of verifying gate and signal use counts on each sheet.

Also, the number of ILD diagrams I have checked off as being completely tested in the CPU section is approaching closure. Of 65 such ILD diagrams, I have completely checked off the diagrams in all but 15 of them. (In addition I have quite a number of additional diagrams of the ILD ilk (i.e., drawn as positive logic with AND and OR gates, etc.).

Page 16.20.10.1 was a bit more interesting. On the surface, it is just a couple of latches. However, the corresponding diagrams on ILD figure 31 were in error. The outputs of these latches go to DOT-ed connection. While they are not like triggers in that they don’t “pull over” the output directly, they DO form part of the feedback loop for the latch, and thus can cause it to set (provided nothing else is keeping it reset). However, the engineer drawing the ILD didn’t take that behavior into account (and it did seem rather odd, just looking at the ILD, to have both a latch and a combinatorial group feeding the same output. ;))

In addition, on that same page, the latch comprised of the gates at 4E and 3E are unusual – the reset portion (4E) is a NAND gate, but at I first I thought that the set portion (3E) was NOR gate thinking that the engineer doing the ILD diagram did not spot it, which caused them to depict it as part of an “OR” to set the latch, when in fact those two inputs are effectively ANDed together.

However, when I ran into the same situation on page 16.20.14.1, the second use of card type YLH in my travels, I got suspicious and took a closer look at the circuit, which has a 3 diode DDTL (0-6V) *AND* circuit feeding an inverter/converter to SDRTL (-12V – 0V) – in other words, a NAND gate. This was actually the third card type where I had made this error – it caused me to go through all the card types I had interpreted as NOR gates to confirm that there were not any more such gaffes.

Page 16.20.15.1 had something else interesting. This is the Complement Latch page. There is also a related signal, “+B COMP ADD A” derived from that latch anded with “ADDER A CH USE T + C” (OR’ed with a couple of other things). The latch is set, among other ways, by the OR of a couple of signals “START COMPL ADD 1” or “START COMPL ADD 2”. Interestingly, “+B COMP ADD A” will also generate its output via (“START COMPL ADD 1” or “START COMPL ADD 2”) and that same “ADDER A CH USE T + C”. Since the effect of the OR part of this would also be setting the latch, it is in a sense redundant. I suspect that this might be in place get the +B COMP ADD A signal up just a tad quicker than the latch sets, by OR’ing it with the pair of signals that are also going to eventually to set the latch.

A “D’Oh” Moment

I had noticed in my travels that a number of signals end in asterisk or have an asterisk near the end. I had seen quite a number of them, particularly as inputs to DOT’ed connections on their destination sheets. But it wasn’t until I got to page 16.50.04.1 where what was logically an identical signal appeared with both a name without an asterisk and one with an asterisk (-B MPLY.MQ.B.B0 and -B MPLY.MQ.B.B0*) that I finally recognized what that actually meant – that those signals are indeed open collector outputs intended to be DOT’ed on their destination sheets. D’Oh. Sheesh – it took me two YEARS to catch on.

(Addendum: There are exceptions – probably when things were changed. Example: Page 17.13.06.1 generates signal “-S SET DOLLAR SIGN * EDIT”. However, this is a driven signal, not open collector and in most places, the “* EDIT” does not appear on the input side – only on page 12.12.51.1 does that signal appear with an asterisk – and it is not dotted. My guess is that originally there was an open collector variant, but they later found they did not need it.)

Signal Names Can Be Misleading

There are a lot of straight-forward if complex combinatorial sheets in this parcel of ALDs, and sometimes there is no corresponding ILD. In such cases I have been using the signal name to drive my test bench, but sometimes those signal names can be misleading. Case in point, on page 16.50.04.1 there is a signal name “-B MPLY.MQ.B.1.B0.BW” which implies Multiply OP and MQ latch and B Cycle and 1st Scan and B Channel 0 and B Channel wordmark. However, when I ran my test, it failed, because, looking at the ALD, it also incorporates the True Latch (usually represented at a “T” in the signal name dot sequence – but missing from this particular signal name.) I suppose that they added this factor somewhere during the design and testing phase, but didn’t want to bother renaming the signal to “-B MPLY.MQ.B.T.1.B0.BW”.

When a Space is NOT a Blank and vice-versa

Came across something interesting on the Edit Translator pages (17.11.*.1). These pages refer to “Blank” and “Space” as different characters. Say whaaaat? Fortunately, the ILD Figure 41.1 contained a hint: “NOT SPACE (NOT &)”. There are four BCD characters that have no number bits (bits 8, 4, 2 and 1 are all 0). “Blank” (no bits), – (Just a B Bit), Cent sign – which is also called “alternate or substitute blank” (just an A bit) and & – also known as “+” and, apparently, as “Space” (just the BA bits). I had been aware of the blank / alternate blank thing, because it appears in the principles of operation, but calling BA—- as anything but ampersand or “+” was a new one on me.

Keep on Learning, Learning, Learning

One of the fascinating things that has been going on throughout this entire project is learning to write test benches. Once I am through it all, I plan to post the generated VHDL on github, and this evolution will be very apparent. Ordinary VHDL of course, with signals, requires a flip flop/register/latch to remember state – they correspond to actual hardware logic signals. The IBM 1410 has a bunch of those latches, and some of them have “control” latches that remember something until the next major cycle comes around. What is more, often those control latches are hidden, i.e., their signals are not brought out on the ALD sheet. This presents a challenge in writing a test bench – because you need to know the state of that control latch from a previous iteration of the test vector to know whether the actual latch whose signal does appear as an ALD output ought to be. Even worse, some of these latches are in a latch loop – using the “visible” latch to “regenerate” the setting into the control latch until some kind of condition is satisfied. Up until today, I had been “remembering” that with code – which made writing the test bench both more intricate and complicated, and less complete as well. Enter another “D’Oh” moment: test benches can and do make use of VHDL variables, which, unlike signals, “remember” – they are like variables in most any other programming language. So, one can remember the *expected* state of the control latch, and then see if that results in the corresponding state of the “visible” latch on the next iteration. Better still, another variable enables the test bench to “remember” the state of the visible latch as well. This makes testing significantly easier and more thorough. The test bench for page 17.12.01.1 shows this new technique in practice. With this technique the latch testing on this page worked perfectly the first time – and was verified with the waveform trace in the simulator. BIG time saver here. Wish I had thought of it sooner.

(With apologies to Dory and Ellen DeGeneres. 😉 ).

   -- The variable declarations, VHDL wrapper declarations, etc. etc. are not shown here...

   testName := "17.12.01.1        ";
   
   MS_LOGIC_GATE_B_1 <= '0';
   MS_LOGIC_GATE_D_1 <= '0';
   wait for 30 ns;
   MS_LOGIC_GATE_B_1 <= '0';
   MS_LOGIC_GATE_D_1 <= '0';
   wait for 30 ns;
   
   check1(PS_NOT_0_SUPPRESS,'0',testName,"+S ZS Reset");
   check1(MS_NOT_0_SUPPRESS,'1',testName,"-S ZS Reset");

   for tt in 0 to 2**10 loop
      tv := std_logic_vector(to_unsigned(tt,tv'Length));
      d := tv(0);
      e := tv(1);
      f := tv(2);
      g := tv(3);
      h := tv(4);
      j := tv(5);
      k := tv(6);
      l := tv(7);
      m := tv(8);
      n := tv(9);

      g1 := g and h and k;
      g2 := g1 or (k and l) or m or n;
      g3 := d and e;
      g4 := (lastNotZSLatch and g2 and e) or g3 or (e and f and k);
      -- Note that g4 (gate 4) depends on the state from the previous iteration!!
      
      lastNotZS <= lastNotZSLatch;
       -- These two signals are just here so that I can see the variables on the "scope" waveform trace
      lastNotZSCtrlA <= lastNotZSCtrl;   -- There declarations appear before this "code" nearer the top of the test bench and are not shown

      -- Reset Not 0 Suppress Latch
      
      MS_LOGIC_GATE_B_1 <= '0';
      wait for 30 ns;
      MS_LOGIC_GATE_B_1 <= '1';
      wait for 30 ns;

      check1(PS_NOT_0_SUPPRESS,'0',testName,"+S ZS Loop Reset");
      check1(MS_NOT_0_SUPPRESS,'1',testName,"-S ZS Loop Reset");

      -- If Not ZS Ctrl was set last iteration, then set Not ZS Latch now
      
      PS_LOGIC_GATE_C_1 <= '1';
      wait for 30 ns;
      PS_LOGIC_GATE_C_1 <= '0';
      wait for 30 ns;
      
      check1(PS_NOT_0_SUPPRESS,lastNotZSCtrl,testName,"+S ZS From Ctrl");
      check1(MS_NOT_0_SUPPRESS,not lastNotZSCtrl,testName,"-S ZS From Ctrl");
      
      -- Reset Not ZS Ctrl  This should not affect Not ZS Latch
      
      MS_LOGIC_GATE_D_1 <= '0';
      wait for 30 ns;
      MS_LOGIC_GATE_D_1 <= '1';
      wait for 30 ns;
      
      check1(PS_NOT_0_SUPPRESS,lastNotZSCtrl,testName,"+S ZS From Ctrl Reset ZS Ctrl");
      check1(MS_NOT_0_SUPPRESS,not lastNotZSCtrl,testName,"-S ZS From Ctrl Reset ZS Ctrl");
      
      -- Remember the setting of the Not ZS Latch for the next iteration
      
      lastNotZSLatch := PS_NOT_0_SUPPRESS;
      
      -- Now maybe set Not ZS Ctrl
      
      PS_LAST_INSN_RO_CYCLE <= d;
      PS_LAST_LOGIC_GATE_1 <= e;
      
      PS_SIG_DIGIT <= f;
      PS_1ST_SCAN <= g;
      PS_NOT_CTRL_0 <= h;
      PS_E_OP_DOT_B_CYCLE_1 <= j;
      PS_E_OR_Z_DOT_2ND_SCAN_DOT_EXTENSION <= k;
      PS_BLK_0_PUNCT_OR_SIG_DIGIT <= l;
      MS_A_CYCLE <= not m;
      MS_3RD_SCAN <= not n;

      wait for 30 ns; -- Perhaps set Not ZS Ctrl
      
      -- Remember the *expected* state of Not ZS Ctrl for the next iteration
      
      lastNotZSCtrl := g4;
      
      -- Reset the signals before the next iteration
      
      PS_LAST_INSN_RO_CYCLE <= '0';
      PS_LAST_LOGIC_GATE_1 <= '0';
      
      PS_SIG_DIGIT <= '0';
      PS_1ST_SCAN <= '0';
      PS_NOT_CTRL_0 <= '0';
      PS_E_OP_DOT_B_CYCLE_1 <= '0';
      PS_E_OR_Z_DOT_2ND_SCAN_DOT_EXTENSION <= '0';
      PS_BLK_0_PUNCT_OR_SIG_DIGIT <= '0';
      MS_A_CYCLE <= '1';
      MS_3RD_SCAN <= '1';
                                
   end loop;

IBM 1410 ALD to FPGA: Volume VII Testing Now Complete

Volume VII started off interesting right off the bat with page 15.49.01.1. First of all, I ran into more cases where “B” level signals fed into DOT functions, and recognized these situations are ANDs because the gates transistors go to 0V when on (logic 0, rather than one) and go to 6V when off (logic 1, rather than 0). Any single transistor turning on is enough to bring the signal to logic 0 – a logical AND. This triggered a move to have logic generation recognize when a DOT function is feeds a gate with a “B” level input or feeds a sheet edge with a B level signal, and makes it an AND – which I then later changed to snagging the logic function to use out of the signal levels table.

Also, on this same page, I discovered that I had mis-interpreted the logic function for two logic gates on card type DND as NOR, when they are actually NAND. As a result of investigating what to do about page 15.50.05.1, I also discovered I had goofed on card type YLJ as well, confirmed by comparing the logic on page 16.20.13.1 with the ILD figure 30. (Later I also found the same miss-interpretation for card type YLH).

Trouble in River City, page 15.50.*.1

Page 15.50.05.1 (and, really, all of the pages 15.50.01.1 – 15.50.09.1) are problematic, because they are not for the IBM 1410 Accelerator feature. This feature uses a fair amount of DTL (IBM DDTL) logic to speed things up. The card location diagram for panel 11C3 shows the DTL cards, but the ALD’s I have don’t match, and generally use SDRTL. For the most part, it doesn’t matter to the actual logic that I will produce for the FPGA. Rather than figure out exactly what the DDTL would be, I have been deferring to the ALD’s. However, on page 15.50.05.1, I ran into a problem. that page takes two inputs not shown on the ALD to produce an output which is also not shown on the ALD (or ILD, for that matter) and that signal is used on page 15.50.10.1 – which is for the accelerator feature.

The input signals are: “-B B CH MIN+INV PLUS SIGN GATED” (which I will refer to as signal “A”) and “-B B CH PLU+IN MIN SIGN GATED” (which I will refer to as signal “B”). The page also produces an output signal, “+B B CH PL+INV MIN SIGN GATED”, which I will refer to as signal “C”). Note that the wording of the output signal is slightly different than the input signal “B”, and is also +B vs -B.

Page 15.50.10.1 also uses signal “A” “-B B CH MIN+INV PLUS SIGN GATED” which originates on page 16.16.06.1, and it is , logically speaking (B CH Minus and Use B Ch Sign) or (B Ch Plus and Use Inv B Ch Sign) as one of many signals that can set the NOT Zone C Bit.

The ILD for page 15.50.10.1 does not match the ALD – it shows a pair of signals used among others in a large “OR” arrangement to set the ASSM Ch Zone C Bit: B CH Plus Sign Gated and B CH Invert Minus Sign Gated – which clearly matches signal “C”), and does not show “A” at all.

The upshot is, the equation for signal “C” might be as simple as C <= not B, but it is quite possible that it should be C <= not B and A. That latter equation would be equivalent in most circumstances, should not be harmful, and would automatically prevent this signal from setting the Zone C bit when its partner (signal not A) is setting the NOT Zone C bit – so that is what I chose to do.

To make that happen, I “fudged” some gates. I had on sheet 15.50.05.1 a DND gate (B level inverter) and a YLJ (NAND, B level input S level output) from the card location chart (which is for the accelerator feature) that I was not actually using as they don’t appear on the ALD. That combination produces NOT(NOT “B” and “A”) – the desired logic, but at a “-S” level. But 15.50.10.1 expects a “+B” level input. So I “tacked” on a gate “borrowed” from card type YLK 11C3F05. YLK is a an inverter accepting “-S” level input and producing “+B” level output. I doubt that this is how it was actually done, but since my ALD is using mostly SDRTL (“S” level) logic, and there aren’t any accelerator feature ILD’s, I went with this approach. Time will tell if it works.

Back to the more mundane stuff

On page 15.62.01.1 I discovered a signal name error. Usually I catch these the first time I come across them. This one was a little different, because the origin page, being for the 1311 disk, is not present in my print set. On page 15.62.01.1 I had miss-read the signal as “-S RECEIVER LATCH*1311” when the correct signal name is “-S RECOVER LATCH*1311” – the latter also appeared on an earlier page as well. Easy fix.

Page 15.62.03.1, which controls the strobe of I/O data was a tiny adventure. First, although the VDHL I wrote to handle SMS gate type TAM has the capability of being forced reset by an attached DOT function, I hadn’t told the database to assign that function to the faux pin “T”. In addition, both of the triggers on this page have their gates tied to ground (since these are SDRTL, that means LOGIC ONE), but the database did not reflect that – an easy fix. Finally, the ILD figure 44 has an error where it shows the various buffer strobes going into an OR which feeds the forced reset on the E Ch Strobe trigger, when in fact they feed into the clock (gated set) input on the trigger. It was pretty obvious when the test I wrote based on the ILD failed the first time that forced reset came into effect.

Page 15.70.33.1, the last page in this volume, also had a signal name error: there was an extra blank on the signal name “-C CPU TO CH TAU C BIT” which prevented group generation from generating a bit vector for it. Easily fixed. (FYI, TAU on the IBM 1410 stands for Tape Adapter Unit).

Triggers are a Pain

In working on page 15.62.04.1 I was reminded that the SMS trigger circuits are a pain. I had already dealt with the fact that another single gate “DOT-ed” with an on or off output can force that output on (either the “on” output or the “off” output can be so affected.) A second issue, though, is that some inputs are typically AC coupled – edge triggered, if you will. That means tracking state, because once an AC coupled input has reached logic 1, it cannot trigger again until it goes back to logic 0. I had dealt with the edge triggering before, but on this page my test tripped up because the variables that were tracking the edge were undefined. That bit me for the first time on this page, because I had neglected to force the trigger counters (4 of them, as there are 4 AC inputs, each requiring tracking 3 FPGA clock pulses to look for a logic-one-going pulse) to reset when the trigger is forced to a 1 or 0 – just initializing them to logic 0 didn’t help. This issue cropped up with card type TAM, which I fixed, but could also happen with card type DEY or DEZ (and maybe others I haven’t run into yet) as well. Did I mention that triggers are a pain? 😉

And, indeed, page 15.62.05.1 had the same issue, with card type SMS_DEY. Did I mention that triggers are a pain? 😉

Another thing about triggers: sometimes they are daisy-chained together, which means one has to be very careful about the relationship between test assertions and clock pulses. In a couple of tests I had to save what the state of the first trigger in a chain WAS before clocking in the 2nd trigger, which sets the 2nd trigger based on the state of the first one, but also clears the first one. Did I mention that triggers are a pain? 😉

Work to do merging switches

Not surprisingly, several switches on the IBM 1410 are multi-deck affairs. Right now the HDL group generation code does not recognize them, such that if a group contains multiple decks of the same switch, it gets it wrong. What it ought to do is recognize when the name of the switch and its number of positions match, and use a common bit vector for them. Until this gets fixed, I have to either test such pages separately, or tweak the generated group and test bench by hand.

1410 ALD to FPGA Volume VI is in the bag

The first adventure in Volume VI was on page 14.50.08.1, which generates +S INDEX REQUIRED and +S INDEX NOT REQUIRED . (They are not simply inverses of each other). The ILD figure 21 depicts part of the index not required signal as 1401 mode and Index C tag and NOT Hundreds position B and NOT Hundreds position B. When I wrote the test bench based on this it failed. No wonder: the 1401 uses the TENS position for indexing. The ALD itself was correct – the ILD was wrong. I actually don’t mind these kinds of “adventures” as long as there are not too many, as it validates the process I am using for testing when I catch errors like this.

Immediately following that was another non-adventure. The ILDs list ALD pages in ALD page order near the end of the ILDs. That table references 3 pages, 14.61.02.1 (twice, which is odd in and of itself), 14.61.03.1 and 14.61.04.1. However these pages are not listed anywhere, and no signals flow to or from them – they are completely nonexistent. These entries reference figure 24, which in fact covers pages 14.16.*.1. So, the table is simply wrong.

I am now using the new technique where I generate a test vector from an integer counter to test pages that don’t have latches or triggers. This creates a more thorough test, and as I get more comfortable with the process, it is usually quicker than what I had been doing.

A very curious thing happened on page 14.71.32.1 using this technique. There was a time period when the main output signal, to read out the C address register on the waveform trace was, well, blank – it was not ANY valid STD_LOGIC value. Yet VHDL code that was added to check to make sure the value was either ‘0’ or ‘1’ did not detect anything amiss. Finally, in desperation, I added a slight time delay before setting the variables that were changing the most slowly on the test vector which affected the output, and the anomaly went away. The equations that were generated from the ALD look fine, so I suspect it was some kind of bug in the waveform display code in Vivado 2018.2

Page 14.71.41.1 proved challenging. First, I found I really have not implemented switches right, so for now I am faking it a bit in the test benches. Secondly, there was a discrepancy between the ILD and the ALD for signal “+S ADDR MOD SET TO ZERO”. The ILD shows a term for an and which is NOT 1401 STORE AR OP CODE *AND* NOT 1ST SCAN CTRL. However, the ALD actually implements NOT 1401 STORE AR OPCOD *OR* NOT 1ST SCAN CTRL. Have to ponder which is right, but usually the ALD is. This is not the first discrepancy – I should have been better at documenting them as I go.

Page 14.71.51.1 had a different challenge: it has 2 input signals and one output signal that are referred to from other pages, but don’t actually appear on the sheet. Signal +S LOGIC GATE E2 is an input and +S STOP AGE G*ARITH is the other “extra” input (the latter from page 16.42.04.1). The output signal is clearly a NAND of these two: -S STOP AT G . LOGIG GATE E used on page 12.12.31.1, as are most of the other signals originating on this page. The only question is that the rest of these sorts of signals also feed a DOT connection to generate -Y WRITE CALL. My guess is that this one would as well – but I did not research it. As for gates, fortunately the card type TAU at 11C1F12 has an available gate (#2) that fits right in with the rest (and is also used on this page).

Another missing page has also been recovered: Page 15.41.06.1, which detected a record mark on the A Channel (The A and B “channels” are not I/O Channels, but rather really just busses inside the machine). In this case it was easy: the card location chart showed 8 gates of type DFF, which is almost identical to page 15.41.03.1.

A really interesting thing happened on pages 15.41.04.1 and 15.41.07.1, which detect blanks and group mark characters with word marks on the B Channel. These pages use DTL logic, with +B logic levels. However, though the system fundamentals manual which depicts DTL as using voltage levels of +Y 0V for logic 1 and -Y or -6V for logic 0, these sheets are using +B as +6V for logic 1 and -B as 0V for logic 0, and instead the gates using pull “ups” to logic 0 (a negative voltage), they have pull ups to +6V – logic one, and if the output transistor turns on it pulls the output DOWN to 0v – like traditional DTL — and the system fundamentals manual doesn’t describe that (it was added for the Accelerator feature which reduces the machine cycle time from 4.5us to 4.0us). Furthermore, on both of these sheets, the outputs from more than one gate are “DOT” ed together. With +S/-S or +Y/-Y logic, when gate outputs are joined, if one transistor turns on it brings the output to 0V – the DOT function therefore acts as an “OR”. However, with +B/-B, the transistor still brings the output to ground – but for +B/-B ground is logic *zero*, thus the DOT function behaves as an AND.

I had anticipated that I might run into this – in away I am surprised it took so long. So, I modified my application so that I could explicitly specify the logic function for a DOTed connection. (If this were in wide use, I’d also modify it so one could specify the default on a per-machine basis.) This change will also be helpful when I eventually go back and fix how switches work. Another great thing about this issue was that I caught it running my tests. It is good to have tests fail when they ought to. 😉

This also cropped up on the first page of Volume VII. It would probably be possible to automate the detection, based on the output logic level of the gates feeding the DOT Function being “B” or, alternatively, for the destination for the DOT function being a gate or sheet edge signal with logic level B. But, for now, I am holding off on that until I can write a report that looks at the DOT functions to make sure changing it now would not break anything I have already generated. I am thinking of adding a column to the logic levels table to set the default for based on logic level.

Page 15.41.12.1, which generates the E Channel Reset also presented a challenge. Pages that feed it send it signals for I Ring 2 time and for E CH Wrong Length Record (the latter being page 13.63.03.1), however page 15.41.12.1 does not use either signal. I caught this one with the test, as well – I had entered the sheet using the aforementioned wrong length record signal. Upon examination, page 15.41.12.1 is a later ECO that 13.63.03.1, so I changed it to match the ALD, using I Ring 1 Time instead of the wrong length record signal.

One other milestone that I crossed while working on this volume was that the first of two pages of the ALD sheet to ILD index was finished.

These all point to being well over half-way done with this process!

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.

IBM 1410 ALD to FPGA – Punch Column Binary ALD anomaly

Came across something interesting today on Automatic Logic Diagram 13.50.04.1. It refers to unit “8” – which is for punch column binary – a special feature. An 8 character is just the 8 bit – odd parity. However, to decode unit 8 per the ALD one would have to have B 8 – and no check bit – even parity- which can never happen. So, if one were going to have the column binary feature installed, it would require an actual rework to change the input to one of the pins on ALD 13.50.04.1, coordinate 3A (11DJ02) from “+S E CH U SEL REG B BIT” to “+S E CH U SEL REG NOT B BIT”. So, without this rework, the machine would simply not decode unit 8 at all – perhaps intentionally. (Of course, on the generated version, this would be an easy fix, but for now I just left it as is.)

IBM 1410 ALD to FPGA – I “got one”

I have been testing the logic generated from each Automated Logic Diagram (ALD) page, using the Instructional Logic Diagrams (ILD) were available to guide my testing. Until today I don’t recall finding any cases where I actually made a connection mistake when I entered the ALDs into the database – until today. On page 13.50.01.1, I had mis-substituted signal “-S I-O Lozenge Latch” where I should have had “+S Logic Gate E 1” as the input to the gate at coordinate 5H. The testing caught it.

When I entered data for each sheet, I tracked usage of each signal count. I had a “2” written next to “+S Logic Gate E1” — as I should have. I must have missed that when I checked the signal usage counts after entry (“-S I-O Lozenge Latch” had the two instead). The latter is right below the former on the left side of the ALD, which made the mistake not unlikely, and made it easier to mis-interpret where I had written the signal count of 2. I even circled the 2, meaning I checked it. Oops.

IBM 1410 ALD / FPGA Progress Report: Volume III Complete

I continue to make progress testing the logic generation from ALDs into VHDL. I have now completed the generation and testing of pages in Volume III, which includes the operation and operation modifier registers and decode.

To aid testing, I created a BCD enumeration, which, because VHDL enumerates them in order, starting at 0, made BCD character (by name, such as BCD_A) to binary string conversion easy, which facilitated testing.

I continue to find very few errors. I did find a couple of signal names with (consistent) typos and a few cases where gates had an input shorted to ground (logic 1 for SDRTL) where I removed that connection as handling it would have required code changes to the generation code which I did not care to make.

Q: When is a Capacitor not “just a capacitor”

A: When it is acting as a simple delay line

While working on ALD page 12.65.01.1, which generates power on and computer reset signals, I noticed something that didn’t look quite right. The computer reset signal (active negative) when negative when the button push was simulated, then went back inactive, then went active again 25 microseconds later – when it was actually supposed to go active (the result of the timeout of a 25 microsecond single shot gate).

Puzzling – the logic all looked fine. What was going on? At first I thought, “so what – it is going to reset anyway — so no big deal”. But then I looked at the IBM 1410 system fundamentals document, S223-2648, page 26, which makes it pretty clear that the computer reset signal should only be active after the computer reset clock start single shot times out, indicating that the logic gate should stop at either state A or state R. But why?

Then it hit me: CORE STORAGE. If one resets the machine at the wrong time – say, in between reading a character from core (which is a destructive operation) and writing it back, bad things would happen. — the character would be erased. But, how did the actual machine avoid this problem? Sure, I have a relatively long (90 ns, with a 100MHz FPGA clock) single shot setup time to detect the rising edge of an asynchronous trigger on the single shot, but regardless, that setup time would not be 0.

Then I saw it: A 0.047 microfarad capacitor in the ALD page 12.65.0.1 between that computer reset signal and logic ground. Ah HA! A delay!

Fortunately, I had already learned how to implement a delay on an FPGA: with a “bucket brigade” delay line – whose length determines the delay. Sticking a 4 cell (120 ns) delay at that point in the circuit fixed things up just fine.

The results are shown in the simulated ‘scope trace, below. (The count signal and SSTAGE# signals below are for a different 20 millisecond single shot.)