Never did get around to figuring it out and now I don't have to!
[+] Once upon a time you could write to TI, National etc and they would send you data sheets and even whole databooks for free. (I think I remember buying a set of TI TTL datebooks at a junk shop, but I think National or Linear would send theirs for free). Since I had to pay for parts out of my pocket money there was a lot of pouring over designs before getting parts and trying to build anything. I guess this is the equivalent of the folks who had to submit card decks once a day.
These days, for a given part-number, Googling "part-number pdf" returns links to where datasheets can be downloaded. This is a distinct improvement: disk space is easier found than shelf space.
Most teams implemented these elaborate instruction decoding methods, mapping 000 -> addition, 001 -> and, etc.
We just jammed 4 bits from our opcode right into the ALU select, so we ended up with all of the weird operations this writeup documents. Worked great; our CPU was almost "too simple".
Woz would have approved, I think.
This build could be improved in a lot of ways as I've grown as a developer and engineer in the years since I built it, but back then, "Jam the opcode bits into the ALU" was the simplest thing I could think of at the time, and worked quite well. If I ever tackle something like this again (a year's worth of Redstone is... I'm not sure I have the patience for that anymore) I'd like to try an 8-bit system just for the challenge of packing the opcodes down a bit. The 16-bit opcodes I used here were rather inefficient.
Kudos to any teachers that use Minecraft as a neat visual aid. That would have been awesome.
That's how it is meant to be used, so props to you for picking the right (and shortest) path.
The ALU is implemented using three 24LS181
(N6M6L6) function generators, three 74LS85
(N9,M9,L9) 4 bit magnitude comparators, and
a 74S182 (L4) look ahead carry generator.
An existing article about how the '181 works starts here and continues for a few pages: