This ALU has a bug in it. It does not properly compute the AND operation because of a bad optimization in the implementation of bits 1..15. Carry out from the full adder is used as the input to the "f" multiplexor. 15 additional Nand gates will be required to invert the half adder carry out to get the correct multiplexor input.
This image shows the effect of this bug on bits 0 and 1 when computing
zx = nx =1
zy = ny = f = no = 0
The result is
out = 0xFFFF should be 0!
(Note: trailing "-" on a signal name means inverted signal.)
While fixing the AND bug he figured out how to apply one of my tricks to the X and Y input channels, reducing each to a single Mux (4 Nands). He also saw that it's much cheaper to detect -1 with Ands than to detect 0 with Ors.
The net result is an ALU with 441 Nands! Proving yet again that two minds are better than one.
I'll get the original schematic updated in a couple days.
What is the usefulness of this exercise. As Mark pointed out to me earlier on this forum this ALU wouldn't hold up in the real world due to race and hazard glitches.Simplifying chips The most important lesson:
By rewiring the ALU to its minimal Nand implementation you will rewire your brain. You start recognizing the importance of analyzing of what is asked and what is given. What information can I compute before even processing i/O values. Most astonishing was that X and Y value could act as selection bit for the Mux handling nx,ny and zx,zy.
As Mark pointed out to me earlier on this forum this ALU wouldn't hold up in the real world due to race and hazard glitches.Simplifying chips
Actually, since the Hack computer architecture is fully synchronous, the glitches are not a problem. They occur after the data changes in response to the clock. The real word implication of the glitches, along with other propagation delay effects, is to limit the maximum clock rate.
This is one of the reasons that PALs and FPGAs are usually synchronous. The individual cells in these devices usually implement their logic with tiny ROMs used as lookup tables.
Thankyou for pointing me in the direction of Logisim.
I've tinkered with it for about an hour, and already got most of an ALU slice put together. I'm hoping to simulate the timing delays of the proposed ALU and possibly look at Carry Look ahead logic to speed up the arithmetic.
If any hardware enthusiasts are looking for a challenge... I've come up with a proposal for a bitslice version all in TTL - called Nandroid
I've also done an eagleCAD schematic for a more complete bitslice, which includes the D Register, the A register, the PC (and associated incrementer), and the two multiplexers.
The first iteration is intended to be made entirely from 74xx00 nands and 74xx74 for the registers.
There are a total of 18 chips in each slice, and it looks like it would fit easily onto a 4" x 2" pcb using soic packages of the ICs. The slice would also include LEDs to show the status of the register bits (using the /Q output of the 74xx74) and a toggle switch register to allow simple programs/data to be toggled in - just like the old PDP8s.
The 16 slices connect together using double ended header pins, making an Arduino "shield like" construction. This would leave a RAM/ROM pcb to include, and some sort of a PC interface - such as an Arduino MEGA, which has enough I/O pins to dump data directly into a 64K x 16 RAM. (To emulate the ROM).
I may never get around to building this HCTTL implementation - as I think I would be better to concentrate on moving on to FPGAs, but it would be a great nostalgia piece.