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


Its amazing so much C64 stuff is 160x200 or even 96x200/etc. I guess later trickery got 320x200 but still with limited palette. Plus overscan. Hmm, wasn't he base text mode 40chars by 8pix font? Thats pretty good.Makes sense if I recall, with the vic chip reloading the colour cells every 8 scanlines (in most modes)


Most early arcade stuff is 256x256 or varistions.. The single-bute per x/y can be handy.


Current gpu can render full vga from generated image but hasn't much ram for storing image; so in framebuffers-on-gpu (not external bus ram) you're limited by the stm32f4 ram .. 112K + 32K + 64K all separate regions


Scaling 80% of 320x240 gets you 256x192.. With 8bit colour thats 49K per framebuffer; with double buffering that plenty fits into 112K and leaving 64K for sprite storage and other stuff. 256 width again is a handy number.. Less to transmit around.


With the external ram on rev2 should be doable to have sone much higher resolutions and more action per frame
 
I never cared much for GB/GBC/GBA.. Didnt realize the GBA was 240x160 with nearly 16-bit. We get so spoilt nowadays :) getting old and forgetting specs :0
 
Last edited by a moderator:
Even with the lame code I've got going now (straight C, a lot of goofy late night quick hack) it can handle a pretty decent image; looks like (if we had the RAM) could do 800x600 maybe even more; certainly 640x480 no problem.

I'm currently doing 256x192 as its a nice old school looking view, nice wide pixels :) , and X and Y both fit into a single byte which can be handy. Everything is running nice, so need to add some basic demos beyond colour palettes; should maybe solder in the diodes and such, get the brightness bits going.. having RRGGBB isn't all that fancy, when we can get RRGGBBXX going as well. (Brightness gives us colours*4, which is not bad.) Or should go with RRRGGGBB like a lot of systems do? Still, rev1 assumes RRGGBBXXwith XX being brightness.)

I suppose I have some spares, if anyone is interested in fiddling around with one of these.. though I expect if anyone, they'd want 'em when they're rev2 (have addrss bus etc), and with cpu and carts and base board (complete package!) .. but rev1 gpu pcb is still a not bad little stm32 f2/f4 break-out-board and VGA driver :p

jeff
 
I guess question is ..

Is anyone interested in really early stuff? Or are folks (all 1 of you! ;) interested in the later more solid stuff? Or kits only? pre-soldered and tested, baggy of parts, source your own parts?

ie: I'll almost certainly have a half dozen extra rev1 GPU boards, which are the STM32 F2/F4 BoB's with VGA stuff there (though need not populate it if not needed.) Inputs are by serial, i2c, or using the BoB headers. So you can talk to it with a PC and issue requests to draw from scripts, or hook it up to whatever. The rev2 additions will make it definately somethig more angled towards zikzak assembly .. the address bus/etc, is not really useful for working with PCs or robots or whatever. Right now I'm not kitting anything but the parts list is minimal .. need the STM32 itself, and the rest is just headers, resistors, capacitors, diodes, easy stuff to find anywhere.

Also leads to that question .. even down the road when its all rev2 or rev3 and ready to go out .. soldering your own STM32 F2/F4 is a little tricky if you're nervous, due to the pin density and count. (Esp if I move to 100pin version.) I'm pretty good at it, get it right first time most every time, but I've also got a USB microscope handy. So I'd encourage anyojne interested to wathc ebay and get a cheapo one (the andonstar one is _awesome_; anythign else is fine too, as long as it has a stand or you can make one out of lego/whatever, since you need two hands to solder and its great to watch your soldering live under the scope.) You can live without heat guns etc.. a microscope, solder-wick and solder iron are all you need really, imho.

Theres a bit of fuzz (not much) on the VGA right now, simce I'm still doing everythign in straight C and not leveraging a lot of timing yet (ie: using NOPs for timing isn't ideal, though I'm using the timer to drive each raster line; in DMA mode it uses a timer for pixel elease, but still kicked off by the C code each line.) So some limnes any given frame are over a pixel, but doesn't concern me.

Goal I think now is to have atmega644 and/or PC just upload some graphics to the thing and have it move around a bit, just as a quick demo, and picture viewer; it'll be nice to see full 60fps movement of a few sprites. Then I'll start laying out the cpu and base pcb's and start on the rev2 GPU pcb. Getting really close to the good crazy .. assemvbling it all together. *drools*

jeff
 
Last edited by a moderator:
I'm interested, but I already have a pile of "things to do/try/play/make" that I've still not got around to; this would just be added to the list.

I will keep an eye on your progress, and maybe when you've got something more solid and I've got through a few things on my pile, I'll take a gander
 
I'm following along (mostly).. I'm mostly going to be interested in a kit if it's not too hard, but I'm with pmprog... it's definitely on my todo list.. it'll just have company  :)
 
The drag is how slow I'm moving here; so very little time in the nights to work on it. Should've been done 6mo or more ago :)   But finally getting closer!
 
What is your plan for an OS for this system?

(Sorry if there is a bit here already but your first post says to skip to the end :p )

I have some experience with older systems like the Atari 8-Bits and 16/32-Bit systems at assembler level. I have other projects on the go but if I can help with the software side of something like this I would be chuffed. :)

Very cool project - this was how people were getting home computers when I first learned about them as a kid (many many years ago :rolleyes: )
 
(long rambling post; you know me ;) .. see below in bold for the actual answer.. the parts we need to build in software)

Lots to say on that arena but the hard part is.. and certainly, all help is welcome; I'm having fun designing it in a shoddy fun way, but when it comes to the software, hacking it, etc, that is all up to whoeveer has the bits. Its entirely open source and open hardware, and it can go as far as you guys want to take it. It would bring a tear to my eye if someone other than me puts together a little cart with a game or application on it. Naturally blank carts will be available .. just a cart fingerboard with an eeprom on it, but folks could put sensors onto a board or whatever too. The hardware is not serious .. it coudl certainyl ber designed much better, but I've got constraints in place to keep it simple (so everyone can understand it) and cheap and fun-old-school .. no 'video does it all chip'. A single chip computer is easy to do nowadays, but thats not the point; this is a goofy thing, that is fun to hack on, and all are welcome!

Initial goal was Z80 based computer/console, with all the random supporting bits; then could run original MS Basic for lulz, and I enjoy screwing with Z80.

But I was getting annoyed with eZ80, and rather than just use plain original Z80 I started to think about pluggable CPUs, so we could use 6502, 6809, 68000, or even microcontrollers like atmega and so on. As long as they can conform to the 'zikzak memory bus' or use their own sram, should work out just fine. And RAM bus are all more or less the same (assuming voltage level compatibility or on-cpu-pcb level adjustor).

So right now it is all separte pcbs just to keep prototyping easy (I've built them all on breadboard and perfboard, just moving them to actual pcbs now)

- gpu, power, base (audio, joysticks, ram, cart slot, etc), cpu adaptor, cart

Eventual goal is either to leave them all separate and people can bolt them down (and use the bits for other projects etc), or merge them onto one larger pcb thats easier to handle or put into case (or both options..)

... but the cpu may always be pluggable, because its really neat, and not too hard to do

(ie: an atmega pluggable cpu pcb is really just the atmega, plus ISP header, plus the 2 caps, plus the headers to the serial lines say, or it could have the RAM bus and drive gpu that way. For something like a honest real Z80, its a level adjustor o not (Depending on my RAM final selection) and not much else .. it won't need programming, since it'll just use the cart; you'll flash the cart. For an eZ80, its similar to an atmega, since it can have its own programming ISP and its own sram, or use the RAM bus. 6502, 6809, same sort of thing as honest Z80.. not needing much on there, just a pin mapping to the memory bus.

So the OS becomes a problem .. I'm not sure what cpu most people would want, and I'm not even sure msyelf anymore; The whole idea was Z80 and eZ80 based, and the whole current tree is still called 'zik80' in reference to that.

Myself, I think I will mostly be interested in eZ80 and atmega644 as CPU plugins; the eZ80 is an original z80, plus all sorts of fun peripherals and options, so its quite powerful, and very cheap (like $5ea IIRC.)

But if someone wants a 6809 or 6502 I can make up the mapping pcbs for those pretty easily. A 6809 is pretty hot in my books, one of the Great Chips. The 6502 was hot just because I was a vic-20 kid, and loved doing aSM on it, but its a pretty ugly chip in a lot of ways; mostly, they're hard to come by and expensive.. I don't think anyone is making 6502's or related anymore, and on ebay they're crazy expensive.

...

So likely a Z80 firmware of some sort.

But people able to plug a cpu, flash it with whatever.

Cart will be flashable with whatever, of course.

GPU will be STM32 F4 (that at least is 'well defined'), and of course you can flash that too with whatever graphic driver you want to code up.

Oh, sometime need to test if the gpu is flashable via serial; should work, to save people getting a jtag setup there (not expensive.. can get the stm32 f4 demo pcb for like $11, which can act as a jtag programmer via usb)

I'm assuming we need to build a few parts then..

- 'official' stm32 f4 GPU firmware, that offers a few protocols; serial, i2c, and memory bus in various ways; offer a basic text mode, and some graphics primitives, and a framebuffer on RAM sort of dump

- maybe a cart flasher from the GPU firmware as well, to avoid people needing to get or build a flasher there ("zikburner" is something I also designed, but did not make a PCB of yet; easily done though.)

- need an 'official' firmware for carts to use as starting point, in Z80 say

- for eZ80, we could put a bootloader or basic firmware into the eZ80, that checks for and then jumps to cart if present; that way a certain memory range could be reserved as a jump vector table to firmware functions like clear-screen/etc, for carts to leverage like a BIOS

- could try to in hardware on base pcb, map a certain chunk of ROM to go to a firmware chip, so that a BIOS could be provided; but I'm not sure I want that complexity on board or in the system .. ie: if firmware is entirely in the cart, and gpu, and maybe in eZ80 (or atmega/etc), then that works okay, and keeps costs/complexity down

So there are numerous pieces to work on, independently.

I have quite cleverly, left that for 'later' :) Too much for me to worry about right now.. I've done basic proving of the parts as I go along (keyboard driver works, joystick reading works, RAM read/write works, ROM read works, etc), but worry about the higher level firmware stuff till I have some working pcbs all plugged together in 'rev1', and then if it all seems to work as basic firmware, revise and put out rev2 and start kitting it out as people want

It is very encouraging to see people replying today :)
 
Last edited by a moderator:
Having all firmware on the carts themselves as a header is pretty much how most early cart based systems worked AFAIR . It should certainly help anyone developing to have some sort of BIOS to start with (unlike say the 2600 where you more or less code an entire system from scratch to make a basis for the game itself). Some primitives to help use the peripheral chips, RAM, IO etc would be possible if the architecture is settled on. I don't mind brushing up on 650X or Z80 but both at once would be work rather than a hobby with the peripheral chips to learn as well :p

I haven't had an in-depth  read over of everything yet and I am gearing up for getting my pandora and programming that too so I can't make promises yet. I am unlikely to be able to work on the real hardware but most 8-Bit off-the-shelf stuff is already in emulation / VM I think so I am keen to help on the software side if I can and if I can find the time so don't hesitate to ask me - I can only say yes or no ;)

I will keep an eye on your progress :)

EDIT: P.S. most of the bits in bold made sense to me so I think I am not too rusty to be of some help but I definitely need more revision to be done! I think I am most likely to be of help once you have a more settled set of hardware decisions made.

P.P.S. I was last attuned to 16/32-bit M68K stuff for low-level programming so bear with me if I make incorrect assumptions and have expectations of things that don't exist on 8-Bit architectures!
 
Last edited by a moderator:
No worries .. we all have real life, so things are not moving as fast as I would like, and its all hobby; you could help out if you like, and any time you like, and it doesn't need to be for a year or whatever .. up to you :) I imagine a few months before I get the full stack of pcbs in my hands, and thats still wishful thinking. They're not going to appear, and then vanish over night .. if I happen to run out of the few I make, will make more. They're not expensive at all to produce.

(The ICs can add up.. the STM32 ARM mcu I'm using as GPU is about $16ea for low volume; an eZ80 is about $5 or so; maybe an atmega as IO chip to abstract out the IO (keyboard, joysticks) so low end chips like 6502 etc needn't worry about them directly since they have no GPIOs, and PIAs etc are pricey.) So the majority of cost is in all these chips. If people want me to solder the surface mount or whole pcbs up, that'll cost a bit, since it takes awhile to verify everything .. but most parts are through-hole and easy to work with.

So no worries.. this'll be around in a few months, and in a few years :) And I assure you, programming via Pandora/Pyra -> Zikzak is in the cards (and has been done. I've flashed a cart from Pandora already.)

jeff
 
well not reading all the big posts, but i'd be interested in such a thing, if it's "plug and play" - i have no idea about electronics, thats my main problem :)
 
This is still hardware prototyping level, so its all very early super-alpha code. ie: You can write your own API and graphcis driver for one :)

Buit even at this level, you can usb->ftdi basic ->the gpu pcb, and have a python script on your winows or linux box (for example) driving graphics on a second monitor this way, works great.

For now, there are 3 main ways to talk to GPU (2 for rev1, all for rev2 or you can use BoB and bitbang it all onto rev1)

- serial (lame little protocol.. "DL" (plus params) for draw-line; DF plus params for draw-filled-box; BS for binary sprite upload, DS for draw sprite, BF for buffer-flip, stuff like that. Works :p

- i2c .. pins are on the board, but I've not coded 'em up yet

- rev 2 oriented: RAM .. sprites, sprite-list, or even just raw-framebuffer, on the RAM; gpu just pulls from RAM into its own framebuffer during vblank.

---> todo: see how fast we can pull it in

Existing code is pretty lame; timer to drive each line, and each line does counting to know if it has to do vsync and hsync bits. Works fine, but means its tied up quite a bit. I should set up a chain of timers so that timer drives tiny interupts that are in turn doing the sync and DMA-kickoffs, so the mcu is spinning in the main loop most of the time. Even still, the mcu is pretyt idle*

*  one problem with the mcu as GPU design is .. timing is so critical, that virtually any time you hit a GPIO pin during non-vblank, it can blurp on the display; so I'm restridting all framebuffer updates, serial, etc, to during vblank, which keeps things running sharo.. but doesn't give it much time to pull in external stuff. I imagine theres more we can do here, to speed up the data transfer into the gpu, as things are not at all well coded yet.

jeff
 
LameGorgious demo, but what the hell :)
let me fix that for you :)
Naw man, you should've seen when I was working on these two totally alternate methods..

i) my near-oldest hardware dual framebufferer all in TTL trick, that did timing in an mcu; 17 chips I think, and really quite nivce to work with, but again a little costlier, and a higher complexity; didn't want to scare people, but I might make one of these as an alternate gpu board for zikzak, since it was cool as hell. Roll your own video card ftw :)

ii) VGA in pure TTL  .. big stack of like 50 chips to try and get basic 320x200 in pure hardware .. totally awesome, and doable, but a _nightmare_ that I wasn't up to; got it partially working, and it was just too expensive, and too complex (no one ever would be able to reproduce it after me.) ... not ideal for a beginner trainer project!

iii) VGA using a FPGA; FPGAs and dev kits are typically very expensive, but you can pick up a "Gameduino" pretty cheap; that sucker has a little FPGA and the supporting stuff on it, can use as a VGA and FPGA prototyping system, then go build your own; it looks like that guy has gone and made a full arduino shield out of it, so you could just arduino+gameduino to make your own little system.. but for me, thats cheating, since I want to do z80, and roll it all myself.

--> using an FPGA to make your own video card, is Awesome.

--> but com,plexity is higher, and programming it is complex, so I didn't think people would like that option ...

Hence I went with the STM32 as GPU (or microcontroller for other projects) .. flexible, easy, fun.

jeff
 
I'm still lurking around and I would be interested by a more polished product than this first revision.

Right now I still have those old unfinished projects, but started yet another one (quite simple, I only want to make it extra clean) :p

That new project is modding my MegaDrive :

I've modified the cartridge port to accept japanese games.

It's already switchable between 50Hz and 60Hz (really easy mod). But it still need a colour fix to get a correct composite NTSC signal when switched to 60Hz. And connectors (S-Video + 2 cinch for stereo) to be able to easily capture my games with my old usb stick.

But I'm waiting the 3.579545MHz oscillator…

Once I'll have everything working on prototyping board, I'll try making a PCB. My Eagle skills are rusty -_-

Now I'm wondering which µC to use, AVR (with or without arduino) or stm8…
 
Back
Top