There's more to the keypad than just the CPLD. The CPLD implements a 16 bit address counter that will count up or down and can be preset to some value from the keypad.
The thing is, there's a bunch of unspecified logic around the keypad itself including the 2 digit 7 segment display and none of that is described (AFAICT). This is important because most keypads output a row/column connection when a key is pressed. There are 4 rows and 4 columns for the typical 16 button keypad and when a button is depressed one row wire is shorted to 1 column wire. There is no concept of an 8 bit binary output. That needs to be created!
What usually happens is there is some kind of scanner sending outputs to the row lines and looking for signals coming back on the column lines (or vice versa). It is often done with a chip like this:
https://www.jameco.com/z/74C922-Major-Brands-16-Key-Keyboard-Encoder-DIP-18_44564.htmlFor a keypad like this:
https://www.jameco.com/z/AK-1604-N-BWB-Keypad-16-Keys-Matrix-Output_2131055.htmlThe encoder gets us a 4 bit binary code of the key and a DataAvailable strobe. Note the two digit display! I believe they take two consecutive keypresses and shift them into an 8 bit output. This makes sense as there are 8 databits in the 16 bit output of the CPLD. The upper two bits of the 16 bit word are the dipswitches and the low 4 bits are '0'.
So what has to happen is to figure out how they took the keypresses, latched them and shifted them. AFAICT, none of this is shown.
Oh, and you need some 7 segment driver chips - these are mostly out of production.
https://www.eevblog.com/forum/beginners/7-segment-display-driver-for-hexadecimal/After the keyboard has finally come up with the 8 bits + 2 high bits for pushbuttons and 4 low order bits of '0', the 16 lines are sent over to the CPLD and it uses the data to load the counter under some circumstance (LoadBar or SyncLoadBar go active).
All of which is to say that there is some substantial design work to implement the keyboard as it is shown on page 618. Those extra DIP packages are there for a reason. And, yes, they could all be replaced by another CPLD.
So, what is the point of the Labs? This material makes sense if you're in a lab at Harvard where they have the boards made up. Following along at home appears hopeless or maybe just extremely difficult. There are plenty of processors that can do everything their boards can do and the experiments can be modified easier than it will be to duplicate their environment. An environment based on what most would consider to be obsolete. There are better ways. Even the Arduino should be able to do all of the application experiments. Or the experiment can be modified until it can!
It is true that the idea of 'buses' is better described on an 8051 (or, better yet, a Z80) because they are so obsolete that they don't have internal flash and RAM. They actually NEED an external bus to connect to memory.
If you just absolutely MUST do the LTAOE stuff, you build up the keypad thusly: You use an Arduino with IO Expanders. One IO expander will scan the 8 keypad inputs. There will be 4 outputs and 4 inputs on this expander. You use two expanders for the 16 bit output. You run the two dip switches to Arduino inputs. You can use 2 more IO expanders to drive the LEDs.
You need 5 IO lines for CS' for the five IO expanders that are connected to an SPI bus on the Arduino. Now all you have to do is write code to scan for a key press, decode the press to hex and shift it into an 8 bit binary variable. You take this (and its higher order mate) and decode them to 8 bits for driving the 7 segment displays. Send the result out over SPI. While you're at it, make up the 16 bit value and send it out to the other pair of expanders.
http://www.microchip.com/ParamChartSearch/chart.aspxYou can use 16 bit expanders for both the counter output and the LED drivers. This reduces, by 2, the number of IO lines needed for CS'
Definitely doable! Elegant even! It sounds more complicated than it is. You have a 16 bit expander for the keypad output, a 16 bit expander to drive the LEDs and an 8 bit expander to read the keypad. And an Arduino for the orchestra conductor. Definitely doable! And it could be built on a prototype board. In fact, the ATmega328 could be programmed as a separate device so no Arduino board is used at all. Just chips on a breadboard. How cool is that?
I would think about my goals. Do I want to know at the chip level how a CPU works? This is a worthy goal and the education will be worth the time and money. I would take on Ben Eater's project in a heartbeat! It is documented and it works. It isn't going to set the world on fire but there is a lot of value in the project if low level logic design is a learning goal.
If I didn't give a rat's patuti about chips and logic and I just wanted to stay at the microcontroller level and above, I certainly wouldn't take a trip down memory lane with an 8051 just so I could see some bus signals. I would grab up an Arduino or, better, one of the STM32F ARM boards and get on with higher level projects. Nobody is designing with DIP packages any more. If we do want to experiment with CPU designs, all the logic is created by typing and synthesizing to an FPGA.
More ironic: If you don't have a scope, you can't see the bus signals anyway. A logic probe is another artifact of a long ago world. Yes, I have several and I can't recall using one in the last 20 years. Logic is moving too fast for a probe to be able to do anything more than say that something happened about a million clocks back.
Unless you can single step the logic and, to their credit, LTAOE does make an arrangement for that. It's yet another CPLD. Ben's CPU does single step as well.
Enough... Good luck!