Looking through my regular SRAM chips, most have a standby mode with just a few micro amps of current draw and function down to 2 volts. So, a perfect match for one of these and a coin cell. That makes programming from scratch easy, and one can iterate without a ROM programmer. Once a subroutine is verified, it can be transferred to an EEPROM. Then there is no fussing with paged erasure, not that erasure is a big deal. It just requires the subroutine and a 12 volt source.
Anyways, the battery backed SRAM on the board is the plan for tomorrow. I might have expanded the real estate a bit today, and built a custom breadboard for the 68k Hershey bar. I don’t know if I will mess with the 68k stuff as all chips I have are NMOS, and I think that means they cannot single step through code. Reading up on the Z80, that thing is really really nice compared to the 6502.
Putting the power lines underneath the 68k is clever. I had never thought of doing that before.
As for EEPROM vs NVRAM, if you have an EPROM programmer, there isn’t any effort required to program the ROM, and NVRAM is just more expensive compared to ROM.
Also, what is your general plan for the design? Is it to have multiple CPUs running simultaneously, or will only one CPU execute code at a time? In addition, will they be sharing a bus, or doing some mailbox message passing?
No solid plans yet, mostly just a wandering explorer.
I am loosely following Ben Eater’s 6502 build, but thinking of how to replicate it with the Z80, and '618, maybe more. I know such an effort will force me to learn instead of copypasta.
I also have the book Threaded Interpreted Languages. That is about a writing a FORTH like interpreter on a Z80 example. I want to understand a threaded interpreter from several angles. I have FORTH running on several microcontrollers but I have never fully grasped the stack and branching in a deep level, like creating a threaded scheduler to interface sensors, motors, display, and user input. Honestly, it is a similar issue I have faced with all languages mostly due to independent learning and inexperience.
I tend to need a fundamental understanding of the lowest levels of any system and build a functional abstract map of the subject. With Arduino, PIC, STM32, ESP32, and MSP430, I can copy code and kinda hunt and search my way around until I get basic stuff working, but I really struggle with my questions of why, like why do I need to set all of these flags and setup registers just to enable I/O. Without an answer to such fundamental questions, I have no functional understanding to build upon. I realized this paradigm years ago; that all modern microcontrollers are built upon the bones of the first microprocessors and that all of the integrated steps to configure the hardware were actually external chips in these earlier systems. These in turn are mostly just logic chips, and the real magic happens in the ALU. I’m now looking to solidify that loose abstraction with actual hardware.
I have several programmers. I would like to try building something without cross compiling or bootstrapping, but he idea probably won’t survive the tedium.
I may try creating a multi processor system if I can get an interpreter running on one, it would be interesting to use it to play with the others. It just depends on how long the project holds my attention. I have an old digital picture frame with a hacked composite input. Maybe I could build the logic based video circuit from the Apple 1 to interface. I also have one of the MC6845 video chips that might be an option.