I was even able to run a rudimentary test of the address loading by taking the 4th bit of the address, inverting it, and assigning that pin to the !LOAD pin of the ADDR_LOAD socket. I was then able to observe the address counting properly from 0x0007 (0111 in the last four bits) to 0x0008, saw !LOAD de-asserted, then on the next clock tick, the current address properly jumped to the value on the ADDR_LOAD socket (which happened to be 0xFFFF since the pins are tied high).
The next step for the program counter is to get an EEPROM programmer and develop a method to compile and burn code into the EEPROMs efficiently. The Willem EEPROM programmer seems to be the best bet, as it's orders of magnitude less expensive than other programmers, and its software natively supports the Atmel AT28C256 EEPROMs that I'm using. I ordered one this afternoon, and it should arrive in a couple weeks.
Of course, the Willem programmer has a couple issues:
- The software is Windows-only. And the software hasn't been touched sine the Win98 days, so realistically you can't go much beyond Win2000 and expect it to work.
- The programmer requires a parallel port. Who the heck has one of those anymore?
Surprisingly, my desktop PC (running Fedora 14) has a parallel port. Check. I created a QEMU/KVM virtual machine running Windows 2000, and added the parallel port of the host to the VM. As far as I can tell, it *should* work. But the only way to find out for sure is to go ahead and get the programmer and try it out. If all else fails, I've got enough spare hardware in my closet that I can build a Win2000 PC for the sole purpose of burning EEPROMs, but I hope it doesn't come to that.