Zikzak - crummiest 8bit console/computer ever .. but I'm making it!

[EvilDragon]

If only there was a market for this; I really should try to marketize it somehow .. roll out a first actual game, try to make some easy to access libraries etc, tie into Arduino or something :O

Well, why not?
If there's a way to code games in a relatively simple way, and the price would be low, it's something to try.
I would be up for it, I could handle production here (GC also does small quantities) and sell them in the shop, I've got quite a few customers

 

[directive0]

I've wanted an 8-bit project to teach me some more fundamentals of computing but I've yet to see a product in that category that interest me.

The zikzak is honestly a pretty cool little device, and from the looks of it Canadian to boot. If the price were right I may be interested, especially if there is a strong auto-didactic angle to the device, I assume it will run a BASIC interpreter?

 

[skeezix]

Its 'general purpose', so coudl do a lot of things; I've not finished any real BASIC interp yet, but its on my bucket list. Course, any number of small (and classic from 30 years ago) BASICs could compile, and some classics (from CP/M, or the original MS BASIC) can be ported to run on there. (Someone has ported MS BASIC to ru off serial I/O instead of screen, and that should be an easy port to ZikZak.)

ED .. is there any safety concerns, or can stuff like that be disclaimered away? ie: I'm not an EE, just a basement hacker, and while it more or less works, its certainly not perfectly working/tested, and probably not to any sort of code. So, if we did think it worthwhile to pursue making little DIY computer kits, would it be sellable? Or would I need to get all serious, get some EE pals together to go over the design and and worry about certifications and all that?

I doubt we'd need GC, as I think the goal is DIY kit; I have thought about having Elecrow (or GC say) just populate the two main SMT chips (or maybe 3, include the FTDI), since most DIYers aren't crazy like me and want to own microscopes So it'd probably be an easy setup, but those chips are pricey (the STM32F4 I use for the GPU is probably $15-$18 each.)

The main cost offenders are .. in USD

ZZ main boards
- AY-3-8910 -> I should rework this out of existance, and replace with another chip or roll the function into the main z80 or stm32; this is Rare and as such, $5-$40ea :/
- STM32F4 for GPU -> $15
- eZ80 -> $5
- FTDI -> $3
- cartridge edge connector -> $5
- PCB -> say $2 ea
- RAM .. I forget, but say $5
- then all the passives, like two oscilators, all the caps, etc etc; jacks a $1ea, etc.
- 3d printed ugly case say, to avoid massive up front case costs .. $5 at a guess
- cost to populate the stm32, eZ80, ftdi ... $? the rest is all through-hole easy to solder.

A cartridge dev kit would be
- another little pcb
- ZIF connector say
- eeprom -> $5
- 3d printed case -> $2 say

course, a lot of it could be optional; want a couple of cart blanks, or no carts/edge-connector at all? Want a 3d printed case or no?

So if someone wanted a base naked PCB, it'd be a cost of say $50-60 conservatively, could be more since just top of my head; add a cart, cost would be say $10; cases and stuff extra.
--> so to make it worth selling, have to sell for what, $100?

I imagine the audience is small, so would only 'produce' 10 or 20 and see if they sell at all; and if demand suddenly goes up, then you make 100 or 500 as needed, and make any meagre profit on volume.

I dunno, while guesses

jeff

PS: yep, I'm out of Toronto.
[doublepost=1464706642,1464705483][/doublepost]I'm fiddling on cases right now (though I just blew up my printer nozzle, and molten plastic blew all over the place.. ugh!) .. so once I get a simple case done (ugly but workable!) I'll call the hardware 'done for now', and work on some simple demos to help me nail down basic firmware, and some demos just so it can look cooler in videos.

ie: I'd like to have two carts .. a BASIC cart, and a Space Invaders ("Zikinvaders!") clone, with a basic BIOS menu (when no cart is put in), that can do board self tests and reflashes and stuff.

So, thats actualy a fair amount of work (given how little time I get), but at least its in the 'home run' end of things. Much nicer than being at the very beginning

FWIW, the so-far total in-progress case looks like this; this is the top piece (currently a two-U styl case; a U for left, bottom, right, with the other being this one .. front, top, back); I'm not sure I like the look of a fan out of holes on the top, but it does provide lots of airflow. It doesn't need airflow, but better safe than sorry.

Its all janky crummy stuff, but homemade

 

[levi]

An EEPROM? I thought EEPROMs were old hat? And I'm not sure too many people without a microscope own an EEPROM burner to be honest.

Edit: Presumably it wouldn't be too much work to wire up an emulated Z80 core to an emulation of your graphics setup, and get a development environment out of it, so more of us can work on writing software for it even if we don't own a zikzak to test our builds out on.

 

[skeezix]

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

 

[levi]

Ah yes, you did mention those EEPROMs before, and I forgot, sorry.

Sprite mode sounds cool. Rolling your own graphics mode sounds even cooler - presumably you could have a frame slide on screen with it only reading part of the bitmap on each frame. And then it could transition to sprite mode, assuming it has enough space for the backdrop and the sprites.

 

[skeezix]

One thing thats interesting too is .. 'glitching' the screen is really where you have some wiggly columns, since you've been doing GPIOs and causing some slight microsecond delay, so ap pixel gets to be a tiny bit too big, etc.

That only shows if you're doing non-black; one option of course is who cares about glitching if you're not showing anythign for part of the screen; so you could have a bouncing line or bouncing text demo thing going on, and in the parts of the screen not being drawn, just do extra GPU bus stuff. So if you're drawing 30% of the lines in the display, why worry about glitchign for the other 70%?

But the part that gets painful is .. say you want to do a vertical shooter, and your entire background is scrolling artwork, generated live from CPU? That would be a hard problem.

But that was a hard problem back in the day, too; most systems couldn't do it; Zikzak has the muscle, but is held back by the bitbanging. Still, you could do it with a plane of custom font and text mode, and add a modulo() sort of handler to the GPU, so that it offsets the background by so many pixels down, and loops modulo() over the source, so that you could simulate a background scroll (just like arcade Phoenix does it.) .. or have the GPU manufacturing screens..

ie: another idea is 'streaming', I call it; where every few rows of video, the GPU calls a function to populate the next few rows of data, and then the live scanline chasing iterupt just spits out the next values from the buffer. (think of it like an audio buffer, where in most modern apps your'e generating audio in blocks, and the system is live using the previous block.) So we could have fractals or calculated rendered terrain or other crazyness being 'streamed' out of function into the live video buffer, and using up almost no memory, and no GPU.

The GPU actually has a fair amount of its CPU time available for shenanigans; its just like a vegetable in a wheelchair .. its got lots of CPU muscle, but it can't communciate easily outside, except during vblank. But its runing at a very fast clock rate, so you can do awesome stuff!

It woudl be hard to write an emulator for ZZ to handle all these crazy things, but writing a basic z80 emulator would be trivial.

Crazy machine, I know

jeff

 

[levi]

It'd be interesting to know how much data the GPU can download in one vblank. Presumably since it's rendering the VGA on a widescreen set you have anamorphic wide pixels, and it's still what, 800 wide and 640 down. Can it also get a little time during hblank? And how much RAM does it have? Presumably if it's calculating stuff to go out live, it can leave the CPU on the bus during that time.

Perhaps it might be worth starting a new thread with this stuff in, assuming it's more than just me and thee interested.

 

[skeezix]

Blast, looks like my 3d printer wrecked itself good (by which I mean, I wrecked it .. it was mostly homemade, and I never got around to making a fancy wire guide, so there was a wire harness just hanging down over the print area,m sweeping around behind the print nozzle. I was trying to locate one of those plastic wrap around (yet high heat handling!) wraps .. silicone or something. None of that dollar stop cheap cable guide stuff. Anyway, after firing off the zikzak top box part (a good 4 hour print or so) and heading to bed a few nights back, it was all a mess in the morning. My guess is the wire harness got caught on something, as the heat bed was pulled aside (glass plate pulled off), and the wires have a stripped part in the middle (pulled on somethign hard!) .. the hot end was twisted to the side, and the thermistor was yanked out (ie: its non-existant?!) so it lost track of temperature; looks to me like it poured cvurrent in to bring the "temp" back up, and melted off part of the hot end, while it continued to try and print (which it did an admirable job of, all thigns considered. I mean, its a mess, but it continued to render out nice streams ofplastic, so.. the electroncis is omstly working and the overcurrent handling probably kept it all safe.)

So, I guess its gonna be a few weeks or more before the printed case starts comign around again; going to cost me a pile of money in new parts (new hot end alone is about $100USD for the one I'd like), and all new filament to match it, and new wood and aluminum to replace warped rails, new drive pullies and such.. BLEH.

Well, guess I can get back to hacking on abstract syntax trees for SkeeBASIC then

jeff

 

[skeezix]

Nothing too interesting to show today, but its still exciting to me

When coding on the z80 side, I've tended to cheat and just flash to the device ROM; keeps a lot of things simple, but at the same time .. you risk wearing out the flash prematurely. I fiddled for awhile and got things all set up so I coudl do Debug builds that dump the code into RAM and run from there, or Release builds that flash the device. Little faster to work this way, and no risks; just hit reset button on the zikzak and poof, its running the code from flash, good to go.

I also ported in some old code I'd written for 'zikburner' experiment a couple years back; that board was hand soldered and fell apart, so isn't useful anymore anyway.. and zikzak should be able to flash its own carts and be its own dev system, right?

Well, I've turned up the flasher tool menu on serial (ie: USB via a terminal app like Hyperterminal for windows folks, or minicom for Linux folks, etc.) ... I've also got a command line python tool that talks to this, so from the commandline can just send binaries right out to cart. Of note, the flash tool doesn't actually limit where you flash to, so can use it to update the eZ80 built in registers, or the ROM-code, or the cart, or I suppose anything on the bus (the audio chip, the screen buffer, etc.) .. Sort of awesome. The sort of thing you would never tolerate (enormous security backdoor!) on a modern machine, but on a retro style crazy dev machine like this.. _perfect_

Here is a sample session so far. See help screen below, but more or less:
- I used 'testbuf' command to fake up a buffer of data; normally you'd feed a buffer in by hand or from command line tool or something, but I did't want to make it too long a sample session
- 'burn' writes to the memory address supplied; ZZs default (and changable) memory map has the cart ROM at 0x1C0000 which is decimal 1835008 (commands are entered in decimal, but spit back out in hex)
.... the burn does a memory test after to verify the write succeeded
- 'dump' just does a hexdump in the range specified, for manual eyeballing memory or verifying stuff

So this little lame tool could actually do really good stuff already; show and edit registers, show or edit memory/bus/cart.

Eventually I'll add some protocol to talk to the GPU, and then you could use this tool to reflash the GPU as well.

+READY
help
Enter commands into terminal.

ohai -> return OHAI; reset to defaults. (use as first command, always)
echo -> enter loop, returning received characters.. forever
receive N -> store next N chars (after command return) to buffer
burn A -> given a received buffer, burn to address A
dump A L -> hexdump from address A of length L
charecho -> toggle character echo
buffer -> dump the currently received buffer
testbuf V -> generate a buffer of 0xV
format -> toggle dump formatting; default on. When off, only 1 address/value pee
help -> duh

+READY
testbuf 16
# Generated 255 bytes of value 10
+READY
burn 1835008
# Address 1C0000
+BURNOK
+READY
dump 1835008 32
1835008: 10 1835009: 10 1835010: 10
1835011: 10 1835012: 10 1835013: 10 1835014: 10 1835015: 10
1835017: 10 1835018: 10 1835019: 10 1835020: 10 1835021: 10
1835023: 10 1835024: 10 1835025: 10 1835026: 10 1835027: 10
1835029: 10 1835030: 10 1835031: 10 1835032: 10 1835033: 10
1835035: 10 1835036: 10 1835037: 10 1835038: 10 1835039: 10 K
+READY

 

[comradekingu]

after firing off the zikzak top box
jeff

>the zikzak top box
>zikzak top
Not the ZZ top,
its like you aren't even trying. Get your beard straight.

 

[skeezix]

Oh consistency has been shot forever

Zikzak project
Zik80 (z80 variant)
Zikzak <Zik80> SBC (single board computer) version (there are many other variations)
Zikzak SBC rev 1 thru 4
Zikshield for ZZr3 (top pcb)
Zikpower

Then of course accessories... I'm surely forgetting some

Zikcase top and bottom
Zikcart (pcb)
Zikcart Demo 1 (prototype code to run on cart)
Zikburner

So when I say ZZ it means the SBC r3 + Shield + whatever

There clear as mud?

 

[FBnil]

and melted off part of the hot end, while it continued to try and print

Any pictures of this "happy accident"?

btw: Glad nothing bad happened, like, say... falling on a box of matches, which then fizz and set the power cable ablaze, which then puts the wall on fire, which then...etc

 

[skeezix]

current limiting hopefully avoids that but yeah when the thermistor got pulled out .. that's enlightening (or thankfully -not-!) ... next design, backup heat sensing?

Ordered new parts from a kit though so won't be a homemade printer next build but more stable

I have messed up print job photo I can take but printer is disassembled already
[doublepost=1465143808,1465138695][/doublepost]You know, the stm32 has an LCD controller I ignore. I should use smt parts to reduce size and make a ZZ to fit into a Pyre case. just to be goofy

 

[FBnil]

make a ZZ to fit into a Pyra case

 

[skeezix]

Trying to sort out some of the assembly trickery; I'm not super hot at asm (especially z80 asm but..

My base 'firmware' (what happens first, and especially if no cart present; could keep a BIOS in there for carts to use, or let carts be 100% self contained after the firmware verifies there is one there..)..
Option; no firmware, and just run from cart, _always_. But thats silly.. having a base mini firmware in flash is vital, so that we can use the zikzak to program its own carts!
- production release will be flashed to eZ80, check for cart presence, and jump over to the cart if its valid and no keyboard input for a few seconds (say)
- debug build - runs out of RAM on the eZ80; ie: in the IDE just build the firmware and send to device RAM and fire up the cpu .. saves on wear and tear on the flash.

Likewise.. for carts..
- debug build - run out of ram right off the eZ80 is convenient for fast turnaround testing
- production release - just build it and get the .hex file, and don't flash to eZ80 .. instead, run it through the zikzak flashtool to write it via the firmware into the cart

So we end up with some mish-mash ...
Debug build of firmware running out of RAM (RAM mapped to address 0x00), that tries to jump to cart (address 0x1C0000 and up).
Prod firmware is running out of flash (address 0x00 instead of RAM), and jumps to cart (0x1C0000 still.)

So, fine.

Now, what I'm fiddling with is .. reset the cpu and it goes to 0x00 and starts running; that is the Zilog startup code, which sets up the IRQ vectors, sets a stack, basic stuff like that, and then jumps over to the actual code. The cart also has all this in it (though I could have the compiler skip the startup code, and then just jump over to the cart main() myself, say.) Another thought is just have the firmware jump over to 0x1C0000 .. if the cart is a no-startup code, or startup-code, should it work either way? I need to disassemble and work through whats going on, but strikes me as a solid ... _maybe?_ ..

I did the naive first cut:
void (*foo)();
foo = (void*) 0x1C0000; // cart base addreess
foo();

Alas, no joy; if I get the compiler link map and find out where the cart is trying to do some serial magic, I can jump to that and get serial garbage coming out (as expected), and I can verify the cart is flashed right etc, but now need to get nitty gritty into that asm and get that working.

Once the firmware can jump to cart, that'll be pretty hot. Right now i've been building for cart, or for firmware (can put a game in either spot, say), but having it jump back and forth.. never bothered yet.

Also, be nice if the firmware could expose a jumptable of standard routines, so the carts coudl just rely on the BIOS for stuff like 'draw text at (x,y)' and so forth; this makes for smaller code size on carts, and some reusable code (update the firmware, avoid having to rebuild all the carts), and some crazy hackery like having one job modify the jump table so that it can change how things work..

I did update the flashtool command line and firmware bits, so can just grab intel format .hex files and flash them right into memory or cart etc. Thats just really nifty

jeff

 

[levi]

Do you know what proc call standard that compiler is adding to that function call? It probably expects some sort of lookup table at that address defining god knows what shit a C compiler thinks it needs to know. For Z80 asm you just need 'JP address', or c3+address in machine code. The z80 is little endian as far as I can tell, so that address would be smallest byte first.

That address also looks funky. I know the 6502 used 16 bit addresses, so I'd tend to assume an 8-bit processor of a similar vintage would also. So it that address actually 'bank 0x1c, address 0x0000'? If so, how you switch banks is presumably defined by your hardware.

 

[skeezix]

ez80 can run in pure z80 mode, or an enhanced mode with larger addressing. Its pretty funky

 

[levi]

Okay, looks to me like you want a JP.LIL instruction that will take a 24-bit value, and force ongoing processing to continue in 24-bit mode. Despite being a little endian processor, the official assembler takes values in conventional big endian format, so effectively it writes out the bytes you enter backwards. Whatever assembler you use might be the same, or it might be different.

Alternately, if you want to write pure z80 code, it's a bit more involved. First you need to enter 24-bit mode (ADL) by doing a JP.LIL to somewhere in your BIOS code, and from there LD A, 0x1c then LD MC, A then JP.SIS 0x0000 and from there it'll run z80 instructions in the first 64k of the cart space.

 

[skeezix]

yeah, for sure, it looks like the C compiler is doing some funny business. I'll have to try some inline asm to do the jump to cart.

I actually think theres some toolchain gotchas/bugs here .. I'm currently using official Zilog ZDS-II toolchain (in virtualbox natch), as I wanted 'some stability' since I'm fighting a lot of surface area here at the same time, generally. ie: At some point I was writing my own ZDI tool to talk to the processor and do breakpoints and after awhile .. I'm not writing my own debugger today So using official toolchain cost a few bucks (ie: ethernet box that talks ZDI to the board .. so linux host with all ym general dev tools, and virtualbox with WinXP running ZDS II, and ZDSII talking over IP to the programmer, which is connected directly to the zikzak board; pretty handy to just flip over to the virtualbox, hit F5 to build and deploy, and up comes the official debugger with memory dumps, breakpoints, etc.) .. but their official tools are pretty dated and goofy. So for one .. they seem to want to have the ROM at 0x00 or get weird. I typically keep the built in flash at 0x00, or RAM at 0x00 if deploying to RAM so its not somethign that got to me. But for thre cart, I'm building for 0x1C0000. With gcc and so on you can specific -fPIC to ensure position independant code, but there doesn't seem to be an option here; so I need to write a few goofy tests in the C code and compile and check it out, to see if it looks like it does PIC or not, and maybe it depends on 'optimise for size' vs 'optimize for speed' setting. But if its doing PIC code, I shoudl be able to build for 0x00 and deposit wherever I want in the address space; if its really married to non-PIC, then I need to build for 0x1C0000; but in whe I do that, it seems to be complaining about a few issues in the toolchain asm where it sets up default IRQs and such.

So all that told .. I'm thinking it might be screwing itself up .. I need a 'couple hours' (yeah right :/) to attack a few of these things and see what its doing. Hopefully soon, as I really want to get this 'checked off' my to-do list, so I can get back to the fun part and actually make a couple little games and demos. I want to add a few features to the GPU firmware, have some visible fun. Just screwing around behind the scenes .. not what I'm all juiced up for right now

levi -- seeing as you know your shit in this arena, maybe I'll do some dumps from the C compiler output and you can take a look? I'll clean up things a bit to make it less verbose.. ie: the 'firmware' is mostly just a mess of #if's I can turn on or not, for different test cases. ie: test joy port, test audio port, test ps/2 port, show a menu on serial, show a menu on framebuf, etc etc, as proving each compoonent. But for actual 'firmware', theres barely anything there. So the lst files and map and so forth are full of 90% disabled cruft. I'll clean it up to a nice tight little thing, and then maybe you can help me out.

On the cart header, my plan has been to have the built offset by a bit, and have the first (say) 32B have some config values. ie: Short nam for the cart, a serial number, a game number, but more importantly.. 'operation mode' (pure z80, or the eZ80 ADL mode), and address to start, maybe some features needed to start (ie: amount of RAM needed, stuff like that.)

ie: It shoudl be possible to use TASM and do a strict z80 build of some code (or CP/M original say) and deploy to a cart .. or use the wider memory and stuff available on the eZ80 (ie: GPIOs).

My zikzak r3 board that I test on, actually has 512KB of RAM, which is sexy as hell

jeff