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


Also need to experimwnt with..


- gpu as coprocessor; that chip is crazy fast so for something like frqctal calculations just shove it to that guy


- gpu taking scenegraph; instead of fighting over the bus for full screen data, just send it the sprite id and locations, and you get huge speedup


- add high res modes


Hardware is goofy by design but fairly flexible :)
 
Ahh, I think I found the 'every other memory address' cause .. with the new board, which is all nicely soldered etc, everything is working.. where everything was me being cautious and testing bit by bit; but put it all together and memory reads started getting funky; how odd! .. fiddle around a touch an oh-ho, if you put everythign in the board, except the PSG audio chip, all works; add the audio chip, and memory starts getting odd every other cell. Well, guess what I do with A0 (address 0, for even/odd ..), it feeds into BC1 (a mode select) on the audio chip; it all works a treat.. driving audio works just fine; driving video works fine; but driving audio and video same time.. not so much - the audio chip start fighting with the A0 line, somehow. Very weird.

I'll have to look into that more.. it may well mean I need a buffer chip in there, so that when audio signal is not being written/read that it is entirely isolated from the rest of the board; ie: when it is active on bus, its good; but when it is not active on bus, maybe its turding on the bus anyway in some fashion..

How annoying!

So solder pads that lifted caught one thing, and this caught another, on the previous board; at least now I know.

So new board works 99%, but that last 1%.. maybe anotehr revision needed (or maybe I've learnt enough and don't care.. not sure yet ;) Another $60 down the drain for pcbs, just to add a buffer, would be a drag; but maybe I could make a little perfboard and do it there as a bridge .. I've got stacks of credit card sized perfboards, and just put 2 sockets on it .. maybe doable without a board revision.

jeff
 
Last edited by a moderator:
Strikes me another easy fix.. Slice A0 trace from audio chip on pcb and connect really high address pin on cpu to it with jumper; or any spare gpio pin or whatever.. Then I can operate audio without it screwing A0 up .. Should be cake :)


Jeff
 
Another lame little video, but hey, its what I did tonight :)

The cpu is now offering up a basic menu, with some demos and test screens available; this whole menu really should be a submenu but I've not built the next level up yet, so straight to the demos! Ultimately, the boot process is something like this:

- set up the BIOS API jump vector table (so carts can have some basic built in routines they can jump to, or monkey patch/chain)

- check for cart

--> if cart, jump to carts entry point

--> if no cart, show top menu

top menu (no cart present) is supposed to offer some options like .. fire up a BASIC, and go into test and demo mode, or offer up some flashing options so you can use USB/serial to flash the cart, or the BIOS, say.

For now, I just have it jump to the little demo menu so can fiddle around.

As you can see, its a little faster now, but still too slow for my books; I mean really.. at full colour 320x240 resolution (and this can go about 800x480 VGA!) we're talking 64KB of framebuffer being pulled 60fps; and since I'm not 'cheating', the GPU doesn't use dedicated memory lines (or DMA), and its bitbanging the whole bit manually; given its spending most of its time doing VGA, it can onyl afford so many cycles, and it does so during vblank to avoid screwing up the image; but during vblank, it has just enough time to pull in the framebuffer. So during every vblank, the cpu is being held paused.. sort of suboptimal. (the VIC chip, or Stella chip, etc, in the 80s.. they cheated; they had custom hardware designed that knew how to sneak inbetween the clocks of the cpu, interleaved; we can't get away with that trick, without custom made graphics hardware; I may do that with an FPGA, but Not Today!) So that constant bus hammering is killing the cpu, and hence the slowdown.

I think I'll work on a demo using a scenegraph mentality; I need to set up a command queue to the gpu, so the cpu can change resolutions, tell the screen to turn on and off, stuff like that. Or pass code over to the gpu to execute, since its quite a performant beast.. conceivably, you coudl ask gpu to turn off the screen (or stop updating the framebuffer or etc), and do some real computation, and put the results back into RAM; neato. Anyway, have a command that sets mode.. is the GPU in framebuffer raw mode (slow but nifty!), or in other modes.. like scenegraph mode, where you supply command lists (heres sprite data, or move sprite Z to (x,y)), or other modes (heres an image, now rotate, pan, tilt it..); then its more like OpenGL and a clean interface.. 'here, GPU, is some sprite data, during setup; now, subsequently, you just have to copy it here, and here"; so instead of 60fps of 64KB/shot, the cpu can raise the 'frame ready' flag, and pass along a few hundred bytes with updates for the scene, and let the gpu spend its time assembling the image.

In this way, the bandwidth over the bus is _enormously_ reduced, and it'll make things like scrolling backgrounds easy as pie; the cpu will be free'd to run full tilt, since the bus won't be hogged each shot, and the bus shots will only come when the cpu says okay, ready!

In this scenario, I'd expect no problem with hundreds of sprites on screen at once, etc, which is where I've been going.

...

And I think I have the audio issue sorted, but take awhile before I can prove it; probabyl should use a bus line driver or somethign to help with power management on the pcb, but I'm trying to keep things relatively minimum here.. its 'at spec' so far, though, I think. (power draw is higher than I'd like, but the actual power regulator is off-pcb, so I don't sweat it; right now I'm running off PC USB, and USB2+ can support quite a high amperage draw, so no problem.)

Let me know what you think .. I know, its lame demos, but I like them; and this is the baseline.. once we see how fast they go in the near future, we can compare :)

https://www.youtube.com/embed/videoseries?list=UUGQF542dq8RhizMRFbBnBaA

jeff
 
Last edited by a moderator:
Well, it certainly looks nice :)

And those colours I really like btw.

...#7, should the [T] in [Test] be lowercase, for consistency?

Yes, I am a picky sod :)
 
FZERO - quiTe right :)

I was debating today .. right now, current default/only mode is a pure framebuffer on external RAM; thats great for simple updates, but if you (say) want to do full screen updates like crazy every frame, its rough; whern you think back to retro style days, they tended not to have a lot of stuff onscreen, or at least in busy areas; a lot of blank palette fills with a few sprites on top; or in the case of C64 you'd have bitmap backtground with hardware half dozen sprites. For NES and SNES and most machines, you'd have tilemaps and some hardware scrolling. Thewy (and by extension, Zikzak) are not well suited to full dynamic screen updates per-frame; its just too much data. We're spoilt today, where you could get away with it. (Hard to derscribe.. but think random plasma display, not using palette rotation tricks.. whwere every pixel could change every frame.) 60fps * 64KB framebuffer, you're shifting a lot of data. Of course it ties things up. (Whereas a C64 etc was using custom hardware and bus timing tricks to not hold up things, granted.)

So the sorts of tests I"m doing here are torture tests in a way.. not how the hardware was really designed, but wanted it to work anyway (which as you can see it does, not too bad, but still subpar without some serious optimization.)

The alternatives? I've been mulling over a more openGL sttyle scenegraph; instruction lists, sent over to GPU; ie: You could send an instruction list every frame, and have GPU render it to framebuffer and display; or send over instruction lists or data for storage on GPU itself, which you then refer to from cpu; 'heres a list of lines, call it line list A' and for each frame 'draw list A'; this gives you major signal/noise benedfits.. 'draw list A' becomes 1-2 bytes, whereas the data for the lines is only sent as changed; still, doing that, you need a 'heavy' protocol for sending all this crap to the GPU, and knowing its been received and consumed without timing problems, and .. just seems unnatural for a retro inspired device.

So I think I'll just go with tilemaps, as Crom intended.

I'm defaulting to 256x240 video mode, though it can go higher; 256x240 means both X and Y are Byte, instead of 16bit values, which amuses me :) (A lot of classic arcade games were 256x256, or less, too; most machines tended to 320x200 or 320x240, but pfffft!)

So 256x240 in 8x8 tiles is what, 32x30 tiles; thats about 1KB of data. Additionally you include sprite lists.. say 'hardware' support for 8 or 16 or 500 or whatever sprites; maybe allow for sprites of size 8x8, 16x8, 8x16, 16x16, 16x32, 32x16, 32x32 type sizes, something like that.

Now your frame of data (at 60fps say), is 1K for tilemap, maybe even anotehr 1K for a second tilemap overlay on top (mmm, fun!), plus a couple hundred bytes for sprite lists (ie: x,y is 2byte per sprite, times say 50 or 100 sprites, whatever.) Plus the actual sprite data -- but we could have a flagh or command that says 'sprite data updated', versus 'sprite data not updatyed' (also for tile data), so the GPU only has to grab it once; we're talking then say 2.5KB per frame average case; or if single layer tilemap, say about 1KB 'more or less' in data. So you end up with 1-2 frames where you're sending over all the sprite/tile data (slows down processing for 60th of a second), and then its speed time.

Right now, about 61-64KB depending, with eZ80 doing the blitting (compositing stuff.)

Tilemap based, you go to about 1K (ie: 60x less data hogging the bus), with GPU doing the blitting.

Anyway, a few people asked where I expected to get speedups from, and thats the big one; other than that is better handling of 'when to draw'; vblank and 'frame ready' negotiation, to make sure the cpu and gpu aren't tripping each other up unnecessarily.

Also, its all straight C code right now, since time is tight for me; doing it all in ASM would be a boost.

Using chip advantages would help a tonne, but is also sort of cheating; 'degrees of cheating' is the term I use in my head; I'm trying to keep it all 'dumb and honest', and then once proven, I'll possibly use more cheats to improve experience, but knowing they're cheats; ie: the GPU chip has built in 2D DMA and such, so it can do a lot of cool tricks fast/free; later. But theres a lot of optimization potential there.

jeff
 
I suppose another case option comes to mind .. always always comes to mind ;) Instead of 3d printing a case, there is always Lego. But lego retains heat like crazy, and putting solid component jacks (VGA, joysticks, ps/2 keyboard..) on there would be trouble. I suppose a piece of hard plastic, dremel in the connector holes, and then lego fgor the main bod of the casing, would do, though :eek:

"Do it yourself computer; you solder, you lego."

jeff
 
Last edited by a moderator:
I'm pretty sure I figured out why the audio chip was mucking up the bus. The AY-3-8912 variation of the PSG drops some of the no-one-cares pines; the AY-3-8913 drops more, and adds a chipselect. All models feature an 'A8' address line (and some an '/A9' as well.) The documentation is a little fuzzy but I took A8 as essentially a chip-select (when the audio is watching the bus.) If A8 is active, then the device would pay attention. Makes some sense, since makes bus integration a snap .. and in my case, I wired the chip select to its A8; great!

Except the problem is A8 is only used to select the addressing for the register latching; I should've recalled this, but my emu work on the PSG itself was probably 15+ years ago .. ugh! In the wiring configuration I have set it up, the PSG woudl wake up when a RAM read is going on, for odd addresses; it'd then try to dump data onto the bus, fighting with the actual RAM read going on at the same time; this is why every other byte came throiugh funny, when the PSG was socketed. Blast! Damn thing works fine when RAM isn't being used, but RAM and audio same time.. poof. Doh!

The fix is to either add some more complex hardware logic, to set up the mode pins to keep the device off the bus when its not really supposed to be, or just use the AY-3-8913 which has an hones tto go chip select on it; then I don't need A8 at all, and can just wire chip select to chip select, as Crom intended.

So I've ordered a few of those guys .. thankfully, the guy selling them is only 8 or 10 hours away, so hopefully they'll show up next week; also hopefully, should be easy to make a hack perfboard that does the wiring adapter from AY-3-8912 to AY-3-8913, and just socket that experiment .. should let me find out if I'm right, without needing another pcb revision at all.

--

That all said .. since I've gone out of my way to punish myself with awesome retro bits, it sort of makes any 'mass production' (ie: more than a few hand made units) infeasible; if I was going to make mo9re than a dozen units, like make a Kickstarter or something, I'd have to make my own synthesis code, and use a Z80 or STM32 or avr as that; ie: someone has in fact made a SID chip emulator in avr code, so that'd be neat, too.

Anyway, sort of means.. if people are getting interested, I could maybe make a couple (like 2-3 :) limited edition Zikzak boards for people; if some folks magicly get really excited and I get 200 peopel saying 'me wants!', then I'll have to do the design work to nail it down for wider production (which is not too hard, but it means taking out a few of my 'personel rules/guidelines' .. ie: dropping the AY-3-89xx and using an emulated SID, say.)

jeff
 
Oh, and another video ..

This time its a tilemap + sprite demo; artwork wasn't the point, so excuse me if the tilemap graphics are just the character set (full colour supported, though no actual colour is being used in the character set), and the actual map is random garbage from RAM :) Nonetheless, its going through the tilemap and rendering the artwork per tile to the display; then over top, it is overlaying sprites.. where sprites are a 32x32 star thingy, in full colour.

In this one, its a full screen tile map, with 100 fully moving sprites on top; fully double buffered for smooth rendering, fully vblank monitored to avoid tearing when swapping the frames, and using vbl for timing so its nice and smooth without jerkyness or sputtering.

I'm really enjoying the retro feal of low res and lower colours, so I doubt I'll even bother fiddling with say 800x480 etc; I proved it worked months back, but the extra RAM needed for framebuffers and such just sucks, and its not like I'm delivering a fancy product.. so why worry?

It makes me feel like a kid again seeing all the goofy colours, big 'fonts', and all that; in the previous video, with the bootup menu screen to pick options, I have it pick a random colour for each block of text; for some reason, _that_ feels retro; sort of like how the old Colour Computer had the cursor rotate through the colour palette. I dunno.. just 'feels' now, that back in the day, we did a lot of goofy colours.. we were just so excited to use colours at all? And on devices like the Sinclair Spectrum etc, the colour palette was so limited as to be iconic.

Anyway, so here goes.. what do you think, another lame demo, but still awesome to me :)

https://www.youtube.com/embed/videoseries?list=UUGQF542dq8RhizMRFbBnBaA
 
That's really neat. Does your sprite system support a transparent colour though?
 
I'm using a general purpose ARM micro as the gpu (which is the wrong - but fun - way to do it); this means it has whatever features we code in; adding a transparency colour would be easy (and the chip I use actually has hardware for that, that I didnt make use of yet)


Someday I'll convert to an fpga or even a discrete logic video cars but thats work :)


So .. Yeah, transparencies, should be no problem; adding a transparent tilemap layer etc too
 
The zikzak (zik80 specifically) is really a dual cpu beastie, with most peripherals usable by both cpus; the vga output hangs off the one and joysticks hang off the other and the design is really for the z80 as cpu and arm as gpu.. But you could also ignore the z80 mostly and do the entire thing in arm say, or have a z80 serial/usb computer with the arm chip as a coprocessor..


Its a fairly flexible system for just hacking around on (ie: why I made it so goofy :)
 
wow... it's becomming a great little toy. Congrats for the effort of going from conception to fruition.
 
No internet at home in ages (and I work at home).. Totally annoying the shit out of me and can't get anything done :0


Hopefully a small update soon (re; audio), and hopefully some c4a work when I get ISP sorted out again..
 
Finally received the 'final' revision of the zikzak single board computer pcb; which is to say, I was super busy and just rushed out a last rev, that uses the 4pin pokey PSG audio chip instead of the 28pin one, to hopefully address a couple annoyances in the 28pin guy; assuming that works, no more revs anticipated .. need to take a break on this guy for awhile, worked way too much on it for awhile :) Hopefully get a chance to solder it all together soon.

In the mean time, I'd ebay'd about 30 various sundry little items to use on my robot car projects; notably, I want to fiddle with adding a bunch of IR trans/receiver pairs as range/hit detection, for obstacle/wall/children avoidance (or line following, but thats boring.) For example, got a pack of 20-pairs (40 items) of IR 2pin diodes for I think $3 or something; these ones are really narrow field of transmission (which is annoying imho, but handy in other ways), but do work and very simply with a microcontroller. My car projects tend to have an avr8 (atmega644 say) on them for handling the wheel driving, servos etc logic (though I've got all these eZ80 and STM32 pcbs around from zikzak, so may use them :p ), so having a micro on board is no problem.

Here is a lame little hit-test, where waving a diet-coke can over the IR pair turns on/off a normal visible LED, so can see that it works; the range is not great the way I've got it set up on the breadboard, but if I add a straw wrapped in electrical tape as a light-pipe (say), that ought to get better range/accuracy .. still, it should allow car to stop a few inches before ramming a wall/person.

(Another idea is to put a IR pair on the nose pointing down, and if the distance suddenly stops being a hit, can try to all-brake, on the idfea that its about to off a cliff/stair, or has rolled over.)

Really, my idea has been..

- 3 on front (one on nose, and 1 on 45deg eangle to each side of nose)

- 1 on each side

- 1 on rear

- 1 pointing up, and 1 pointing down

--> 8 pairs of diodes

This would cover a lot of ifo .. if: if the nose is blocked, and left side blocks, can try to weelze out to the right say,, etc.

Who kows :)

Lame demo just to see if I know how to operate 2pin LEd trans/recv pair:

https://www.youtube.com/embed/videoseries?list=UUGQF542dq8RhizMRFbBnBaA
 
In case anyone is still paying attention..

Currently fiddling with my second 'robot car thing'; 'currently' meaning, when I get a fleeting moment here or there..

Anyway, using the zikzak gpu rev1 pcbs (since I have 10 of them ;) , the STM32F405 guys (64pin, not 100pin like I eventually ended up with) .. the zikzak boards are all pretty handy and flexible; the gpu rev1 pcb is essentially a full breakout board for the 64pin STM32 F2 and F4 lines, as well as having the video DAC and VGA and such on it; I coudl probably saw off the right-40% of the pcb and have no problem using the BoB part.. (which I may well do, or at least put a big hole in, as a cable channel for the motor wiring to go through multiple levels of pcb..)

--> so GPU board is going to be the brain; was going to use an atmega644 avr but I don't have any ready-to-use pcbs handy, so would have to solder up a perfboard .. which is more effort, and inherently weaker (when robot cars smash into things, and kids..)

It has breakouts for serial and I2C among other things

Zikzak power pcb rev1 is also pretty handy; its a little goofy, but was built to take a higher power source and feed it through a 7805 as stage 1 (drop X down to 5V), and then feed that in turn to 1 or 2 secon stages to drop it again to 3.3V (say); ie: 7805 can supply 1Amp or so, (hotly), and the TPS7133's and such I use can do half an amp, so I put two slots on the pcb so you could have a full amp worth if you wanted. The pcb also has a 'skip the 7805' set of traces, so you can just connect an existing +5V, like from a USB, and feed it into the second stage direct. With a power switch or not, etc. Handy.

--> so I am going to use a 7.5V battery pack, which is not quite enough to feed into 7805 and get reliable output; so skip the 7805 stage

----> but put 7133 on one stage 2 slot, and a 7150 on the other stage 2 slot; so now the board is putting out 7.5V, and 3.3V, and 5V .. nice!

Receiver .. I'll worry about it later, have a huge stack of GPIOs, so no concerns. (Receiver handling is already in my car-tank-thing)

But this time I'm adding some sensors to drive it..

i) IMU (the MPU-6050 so far) for accelerometer, and gyro

ii) IR or ultrasonics for distance and hit-sensing, for self driving/maze-solving/etc

Got the MPU-6050 wired up over i2c.

So now can detect rotation in various axis, and speed in various axis. Nifty!

This car will drive on all 4 wheels, but if it hits a wall, it'll be able to stand up on two wheels, balance, and drive around that way as a stunt!

Zikzak lives on in robot cars :)

jeff
 
New robot car project; this uses some of the earlier revision parts from the zikzak homemade computer project .. why make a new brain pcb when I've got some STM32F4 boards lieing around? Can dremel out the bits nolonger needed, right? :)

This is a little guy, about the size of a couple VHS tapes stacked atop each other. You know what VHS is, right? :eek:

Here is the car assembled and mounted, but before I put in the wiring and batteries. This car should be the usual 4 wheel drive with tank-style differential steering (rotate on the spot etc), pretty rugged little guy. He theoretically has a super power, but I'll get it working before demonstating that little gem..

Here is first glimpse!

rouge_prewire_isofrontish_001.jpg
 
Looks wicked!

Get out the chrome montana and spray those alloys up :)
 
Zikzak-wise.. still had some issues with the AY-3-8913 (YM2149, PSG, Pokey, etcly named) .. wonder if my chips are bad (being 20 years old and all), or if timing is funny, or what; it all looks good when probing with the oscope and all .. so time to go back to breadboard and drop in my AY-3-8912's (work fine), and then jumper over to the -8913 and see if it works or not. ie: avr8 -> straight to sound chip. Should prove if something is awry with the -8913's or my pcb design.

Mind you, the AY-3-8910 family there is awesome for me (being an Atari ST nutjob, and of course it was used in a lot of classics), but its also an expensive and hard to get old chip; another option is the SID chip from the C64, even mroe expensive and hard to find ... but someone has coded up an avr SID emulator, so you can use it as a drop in chip that pretends to be an SID (slightly different pinout), or use it as a library in your own avr code; pretty slick. So I could drop the AY-3-891x family and use an avr chip on there, and have it be a SID, or simulate its own sound generator. I thought of this long ago, but since I wanted badly to have the eZ80 on there, and also decided on STM32 for my GPU/video .. having an avr on there is just getting excessive for number of architectures. Also, really, the STM32 has the spare cycles, just has a hard time driving the GPIOs while also driving VGA .. but STM32 could do the audio just as well; could throw another STM32 or STM8 on there, or evne throw another eZ80 on there (since Z80 was used for audio on Neo Geo); or maybe the actual eZ80 CPU I'm using has spare cycles enough to render its own audio, and just hook it up to the DAC/audio-out....... Mind oyu, the entire thing coudl be done on STM32 as a nearly single-chip solution .. the whole exercise was to add in the Z80 family and make it all work :)

So, it is all very tempting to reduce chip count and just toss the audio chip; but of course, what is fun to do?

But boyo, I gotta pound this a bit more, figure out whats going wrong; if I blew something in the design, or if this batch of -8913's just are too slow (and I need to slow down my signalling speed somehow), or if they're bad, or what; once I have it nailed down, I'll figure out whats next.

Certainly can't make kit's of zikzak with AY-3-8910 family though; they're $5 and up, but hard to find too .. if I wanted to kit it up or future proof if a little, something else would be wise. *Shrug*

Sort of thinking it'll never kit up, but who knows :)

jeff
 
Back
Top