The EEPROMs I use are read/write just like a RAM; you're more thinking EPROMs, that need a UV eraser/etc. Theres high voltage erase and so on (that use a 12V erase cycle etc), but mine just write and good to go. Look up AT28C256 (for a 32KB chip); theres a lot of similar newer parts out there.
Its a little annoying as the move has been to more "very SMT", or i2c/SPI chips; for ones that act like RAM like the AT28 line, they're getting hard to get, but justy lovely to hack around with for a project like this.
jeff
edit: Yep, making a Zikzak emulator would be trivial I imagine; now, I do use an eZ80 so you can use more advanced aspects of it, but you can just treat it as a Z80 entirely and most things still work just fine (ie: the eZ80 is mostly just being used to handle the chip select magic, that a regular Z80 can't do.) So, yeah a straight up Z80 emu, with the memory mapped to RAM, and some video mode code put in, would do the trick. Timing is very odd with ZZ, due to the bit bang nature of a lot of it (ie: the GPU being bitbang, and not hardware per se doing the video, means the video RAM update rate is poor .. but this is deliberate to make it a code-your-own-gpu exercise)
That said, I've got only a few basic video modes in right now, but its _easy_ to add more (and how many projects can say that!) .. ie: it has a pure text mod where you have an array for text, an array for colour; and it has a sprite-mode where you give it a list of sprites and their locations. I need to build a sprite-uploader BIOS function for instance, and then those two modes should be good enough for many basic games. A pure bitmapped mode works, but its slow due to how I've set timing up for now...
Maybe I shoudl start some discussions up (separate threads?) to go over some of the system goals and where they're at right now, so we can learn together and hammer out some details, and turn it into doc pages on the zikzak.ca page, and start thinking about building an emu and so on.
So, for bitmapped mode its like this though .. theres the eZ80, and the GPU (stm32f4); they're both "on the bus", but the eZ80 is _really_ on the bus, and the GPU is bitbanging on the bus. ie: the stm32 is running its own flashed firmware, and that code can in turn read and write to the bus. The stm32 also has the 'suspend' line to the z80 .. so that when the STM32 wants to grab the bus, it has absolute authority to do so, without wait. Since the GPU is on a very tight timing cycle, and _any_ interuption of that cycle causes visible blip on the VGA output, it means we generally have to do any GPIO activity only during the vblank period of time (annoying!); if we do GPIO during horizontal rendering, we see a tiny but visible skew in the picture.
So, right now, when VBL starts up, we suspend the Z80 and grab the bus, and read the first few bytes of VRAM, and look for a 'to do?' flag; there is also a line from the eZ80 to the GPU that I assume is to be used for 'frame ready?' .. the idea being the eZ80 can signal the GPU to say 'hey, we got something for you'; this coudl be left perma-on to mean 'alwasys have something', or toggled on when frames change; this would allow the GPU to run full out, and the eZ80 full out, and not bother each other, but once the eZ80 is ready and the VRMA updated, the GPU coudl come get it. But right now, the GPU I think justy checks RAM and checks for a 'to do?' flag, and if present, does something. In text mode, it only needs what was it, say 40x30 (or whatever) bytes for the text array and again for the colour array, so not a lot of bandwidth; the GPU can bitbang read that in no time, and more.. before VBL is up. In sprite mode, its similar.. the list of sprites and their x/y is not that many bytes, even if you do 64 or 256 sprites. The more bandwidth intensive is uploading sprites into the GPU.
So yes, the GPU has a small amount of RAM; rather than have the GPU hammeirng the bus every frame (killing the eZ80 bandwidth), we pull from VRAM into the _actual_ VRAM on the GPU, and the GPU renders from that. Keeps things fast, and approximates how a real system workws. Now, the old days had the CPU and the VIC-chip (or others) do rendering, on interleaving access; but they had custom hardware and coudl get away with that.. we generally can't, since various devices that could be used can't interleave at the speed we need for VGA.
So, in a pure bitmapped mode.. if you're using a recent resolution screen, it might even exceed the VRAM on the GPU, so has to be streamed in; but in a sensible retro resolution, you can suck it all into the GPU VRAM.But even there, we're talking a few hundred KB of data to pull over; if you're doing 320x320 and updating 60fps, you're talking 100KB/frame * 60fps .. thats a lot of bandwidth, and doing that during VBL on the GPU, when bitbanging, is just not feasible. (Theres a limit to how fast you can bitbang read the bus before things get flaky reads.)
So, in pure bitmapped mode, it actually takes a number of frames to shove over a full screen worth of full colour higher resolution data, during VBL; and compounding that, is the GPU is locking up the bus while sdoing that, meaning the eZ80 is suspended; so when you're sucking the most data out of VRAM, your CPU is not actually able to put it in there, either.
Now, thats just getting started, theres lots that can be done; some fun trick would be to actually use the bus as signalling, maybe, and not actually bother writing out to RAM and then reading it into the GPU; or, more fun would be to honor the 'frame ready' signalling I put in, and do stuff like .. command to the GPU to stop updating the screen at all', and then just full speed upload to the GPU; ie: if you let the screen blink off for a quarter second, you've suddenly got 15 frames of time to do full bus hammering and read into the GPU, and thats quite a bit of data you can suck in. So strikes me that when a game is about to start up, or changing into full game screen from a menu, the screen just blinks for a moment. And that is natural since you're clearing the screen to go into the game screen anyway. Just that when you clear the screen, you stay blank for a couple moments, and then its loading the data for that quarter second..
But even more .. you could upload code to the GPU, and have it rendering something at less framerate; like a fade-in, or displaying fractals, or something, and updating at 20fps, with the other fames being used to suck in some data or something.
So,m yeah, Zikzak is qwirky like mad, but thats what makes it feel retro