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


Audio good :)

https://www.youtube.com/embed/gQMVjop-Os8?feature=oembed

Hu! Just checked with my headphones, and sounds great, nice and loud; I guess an amp isn't needed, per se. Probably needing a variable amp or POT for volume control but pfft, who needs that! Just no roomn on that pcb for fancy connectors and options.. just headers baby, add the connectors offboard for now :p
 
Last edited by a moderator:
Really only a couple tests left, before sending out for another 'more final' revision. (ie: Hopefully next revision is final dev style, and then maybe another one that has space for real connectors and far less debug/breakout headers, and is designed to fit in a case.) (yeah, imagine.. get the 3 pcbs, make them stackable, and you have a neat little zik-cube with cart slot on top!)

But I prefer to leave a lot of headers on there, so can add SD support as a mod, or even ethernet or something.

Testing left to do is really the cpu->gpu over the ribbon cable test, and maybe some more testing os keyboard/joystick hookups. I'd like to work on a .ym converter/playback tool .. maybe have a cart that just plays back old Atari ST and arcde/vectrex/etc songs, as that'd be neat. Or taking instructions over serial/usb and playing it, like a 8bit sound card for a PC :eek:

So ultimately, not much left to test. *sadface*

Given the connector issue, not sure how best to approach it, but if I'm feeling feisty tonight.. see if I can heat up the header pins and push them right through the pcb; with luck that works and poof, have inverted headers on both sides, and then easy to test.

Then it either works or not, and some code to exercise the bus; should work, given the bus is working so well for everything else, but if anything will get borked now, it'll be cpu<->gpu bus stuff.

Way too much fun.

jeff
 
Well, I am quite bewildered.

Problem: trying to read the cart-ROM bus (for example) from the GPU over ribbon cables.

Hookup: power from base pcb over to gpu pcb, and the 3 ribbons (control, data, address)

Cleared up a signalling issue (I was forgetting to send MREQ over the control bus); once I sorted that, after sending the busreq and getting busack back, using address bus + MREQ will have the ez80 set the appropriate chip select and the cart rom comes alive; then I use OE to get read mode and away I go, as things expect.

Problem is .. the data is not coming through right.

Hooking the scope up to the data pins looks a little fishy.. voltage maybe seems shifted up, so high and low are both coming through high to the gpu stm32.. could be.

While fiddling around, I noticed that disconnecting gnd .. the GPU kept going; *hu* I thought. Started unhooking stuff, and as long as the +3.3 power line was coming in, and data bus ribbon hooked up, things would run. So evidently data bus was acting as GND. Weird. So disconnect the ribbon.. jumper from gnd on base pcb to a data line pin on gpu and voila, GPU came alive (dimly, but alive nonetheless.) Touching the gnd to any of the 8 data pins, and gpu came alive. Any of those 8 pins can act as return path for current. Thats fricking weird.

Maybe since the stm32 can have pull up/down on any gpio pin the circuitry is there to hook each pin up to gnd; these guys are configured for INPUT always; input do not have pull up/down option... I suppose I should measure resistance .. seems high-Z (more than 40MegOhms!) resistance from a data pin to gnd.

I dunno, fricking weird; I'm no expert, maybe this is normal.. but still, blows my mind.

Spent an hour checking gnd connectivities and such and well, data and address do not connect to gnd; but touching gnd to any of them (Address bus too) and the GPU comes alive.

I guess thats normal then :)

--

But the real question is .. wtf is going on with the data bus; address bus is okay, working fine; mreq, oe, all that is okay. Looking at the signalling .. chip select goes active (meaning address+mreq are okay), and then OE goes active, and I have it wait tenth of a second (plenty of time!) and grab the value on databus, then let OE go inactive. Should damned work. But data bus is getting crazy values, like 253/254/255 .. sometimes 0 or 64 or 128.

Certainly should not need pull downs on the ROM output data pins, and it works just fine to the eZ80.

data pins do head through the audio chip and other things on the bus, but again.. work from ez80, and those guys have their chipselects off.

Damn, this is bugging me.. this is the last thing to test before its all 'good'; the GPU runs fine in isolation; the base pcb is running great; but they can't talk over bus.. just over serial. Damnit :) Serial is not good enough here.. not for me :)

jeff
 
Guess i should check data bus voltages from ram and audio during rom chip select .. Maybe they really are screwing around at wrong time ..


Can unsocket them too..


Ahh to have more time .. Another 24 hours till I get my hour of freedom :)
 
Great to see that your project is coming along.

A zikzak "cube" would be sexy as hell  :p

I've started playing with STM8S003K3, quite a nice chip!

I was surprised to discover that a value line product has so many integrated peripherals :D

(3 timers, 5 channel ADC, SPI, UART, I²C and off course SWIM)

The ST-Link/V2 is working like a charm with IAR Workbench. Thanks to IAR, I can code in C which I find far more pleasant than assembler.  :rolleyes:

For some project I'm modding a MegaDrive2 (Genesis) and I wanted to make the mod extra clean.

So I "copied" a region select switchless mod, but using STM8 instead of a PIC.

The mod allows the choice of the region (NTSC or PAL) and language (International or Japanese) using the Reset button from the console.

A RGB led replace the original power led (because I want to make my mod as awful as car "tuning"   :lol:  ).

With one fast press, the console reset.

If you keep the button pressed for some time (about a second, I'd say), the led colour change sequentially to allow you to choose between PAL (turquoise), NTSC-J (red) or NTSC-US (purple). The µC change the region/language only when the reset button is released (allowing to wait for the current region and "cancel" the change). The colors can be changed by modifying the "firmware"… I may add some PWM magic to make a "breathing led" effect (see my previous comment about car tuning :lol:  )

It works on breadboard connected to a MegaDrive2, so I just designed and ordered the PCB from OshPark (they always make 3 copies of the board).

The PCB are really small, so they only cost me 4$ for the production and the shipping.

The boards will probably be in the mailbox before the SMD components ordered from china   :ph34r:
 
Last edited by a moderator:
More later (awesome!) but .. $4 for how many how big? Where from?


Pretty slick sounding mod :)


I love avr, stm, and now zilog. Pic are okay :)


Gcc for stm32

Zikzak is doing great .. Just this one hump. Too bad ita a weird one .. Hope only a few nights to sort out and not weeks.. I've come so far in the last month or two I can taste the finish :)
 
More later (awesome!) but .. $4 for how many how big? Where from?
 
It's from OshPark, they charge 5$ per square inch, you get three copies and free shipping.

My board design is a bit smaller than a square inch.

I bet there are cheaper per square inch PCB factories. But they often have a minimum number of boards, so it's actually cheaper to pay more per inch when you're prototyping and/or only need two or three boards.
 
More later (awesome!) but .. $4 for how many how big? Where from?
 
It's from OshPark, they charge 5$ per square inch, you get three copies and free shipping.

My board design is a bit smaller than a square inch.

I bet there are cheaper per square inch PCB factories. But they often have a minimum number of boards, so it's actually cheaper to pay more per inch when you're prototyping and/or only need two or three boards.
I've always ignored those per-inch guys, since my pcbs for ZZ are all 'big'.. 4inch square, and I'd like more :) 4in-square is 16-sq-inch, which would be like $80 for 3pcb. But I see how that works for teeny guys. What can you do on a 1inch-sq-pcb? :)

I keep thinking it'd be neat to make an Atari 2600 mod, with my own 'all ROMs cart' sort of deal; I've got a stupdendous stack of Atari 2600 carts actually (not a full set, but say 80% set), but lord knows I do not want to dig that box out.. the kids would be using them like lego and I'd never find half of them again; so compressing them into a all in one cart would be neat. (I'm sure there are things like that out there, but easy and fun to make your own!)

I'm rather stuck right now for zikzak, need ot do some more research and tests.. sort of mind blown right now.

One thing that seems challenging is just using an o-scope is changing the outputs; ie: with all the buses plugged together, cpu <-> gpu, I get different results when the o-scope is touching; ie: want to see if GPU setting /mreq and address lines, does the cart ROM chip select go live? So o-scope on /CS1 and see.. and it seems okay; but the data lines return different stuff if the o-scope is attached or not. Start touchign around with the scope to see whats going on, and it changes things. That I find rather intimidating.. what to do with no visibility? You need to o-scope around to figure stuff out, but it changes what you see? Uuuuugh, welcome to Real Electronics ;)

Stuff like that sort of suggests to me an impedance problem; the sort of black voodoo where if one side has higher impedance than the other, and the rise-times differ than expectations, you get ringing back and forth, voltage flopping around on the line. The cart rom is fairly modern, so its not like I'm doing issues with 1970s tech to new tech (and in fact, the audio chip is working fine and that _is_ old tech..).. still.

So I'm not entirely sure what values I'm seeing right now .. it looks like this-and-such, but not sure if the o-scope is lieing for the real operating details; need to find out how to work with _that_ situation. At least, try to get the mcu's to report pin state and such themselves, but theres only so much you can do for output pins, if you can't touch 'em with the scope.

So right now GPU works a treat, and the base/cpu works a treat; just having trouble bussing together. Bloody annoying, that :)

1) - tempted to do some more serial hacking, for fun; the cpu can spit out 57600 pretty easily; going to the next one up seems iffy. Wild rounding, thats about 5KB/sec, which is not a lot in some contexts; say you want to upload a full bitmap 8bit colour to GPU, at 24x240 res (about 60KB), you're talking 60KB / 5KB/s or about 12sec to do so (wow!), not even worrying about vblank (disable screen while uploading, say.) Lame. But if you're doing 16x8 sprites, you could upload like 40 of them per second, no problem, so say spend 1-2sec uploading sprites, then no problem just working with them. (ie: update the scene graph, tell the gpu to move sprites around, would only take a few bytes per sprite, so no problem.)

--> could write a little game, and BASIC interpreter and all that, no problem, using serial cpu->gpu communications

2) - also tempted to do a thing where gpu is a device on the bus; /cs3 was what I planned for this. So here, you memory map the gpu into the z80 memory space, and then when z80 writes to it ("*gpu = 10" sort of thing), the bus would do its magic; here you'd have z80 on interupt waiting for the vblank to start, and then soon as it lands, start doing a blit-loop (say), to transmit sprite data or screen data;  the GPU shoudl be fast enough to handle the bitbanging there .. not sure how fast transmission could handle but might be on the order of 1MB/sec or something, who knows. That would surely suffice, but was only one of the options I wanted to enable.

--> see, the bus _works_, its just having a problem reading from cart ROM -> GPU; cart ROM -> z80 is not a problem. How annoying is that

----> it could just be the ribbon cables too; too many cables too close together in arching maybe causes inductance problems; maybe it'd all work on a pcb, with ground plane all around it...

3) - and want to figure out and fix wtf is going on here.. its annoying when gpu can't read ROM or RAM as I intended :)

Anyway I have planned for (1) (2) (3) to all be available; if (1) and (2) are available, thats still a win, but not quite As Much Win as I'd like :)

More to do...

jeff
 
an old trick we used to use if the scope probe was loading the system and affecting the results was to use a 1Mohm resistor hanging off the probe.... heck ive used 100Mohm at times... many moons ago this was on an analog scope.
 
oh? So that would reduce your signal level, but the wave form should still be intact? (ie: feed it a known voltage, say 5V, and then check the scope and it'd show as 1V say; same waveform, but now you know the voltage scale due to the resistor?)

--

As I'm a noobie when it gets right down to it, this one item has been throwing me off .. grounds :)

Consider this example:

I've got an FTDI Basic here (rather, a clone; got a bag of 5 of them for $2 from ebay, naturally.) An FTDI chip with a few breakouts and resistors on it, more or less, for mapping TTL serial to USB Serial; super handy. It has its own +3.3 or +5 and GND pins, and the usual serial lines (CTS, RTS, TX, RX, etc). So in a given project, just jumper from your TX and RX to the FTDI and plug into USB and voila, instant serial console. Really handy. (Could do the same with a breadboard, or using an arduino with the avr8 yanked out, etc and so on.)

Observations:

1) If you do this, you sometimes get signal noise; I need to put it on the scope to find out whats going in and out, to be sure

    ie: my power supply -> my power pcb -> board in question

2) If you instead use the +3 and GND coming out of the FTDI, it works 100%

Hooking it all up to FTDI for power, and then powering up my power pcb (unconnected):

- measure FTDI GND->+3.3 == +3.2V .. great.

- measure my power pcb GND->3.3V == 3.3V great

- measure FTDI +3 to my pcb GND == random ..

So ultimately these are all coming from my house power, so I'd have thought all the GNDs would be relative to that.

So the FTDI feeds it expects are relative to _its_ power; it more or less works when using my own power, but much better with its own. The normal pinout on this guy offers 3.3 or 5V (no both) soI tend to use my power supply pcb and jack in the TX/RX and live with the semi reliable output. I'm going to solder on a 5V output to the FTDI (it has that, since its switchable), and then I can use it to power the pcb direct for both voltages.

But the question in my mind is.. what is actually going on here; obviously, as soon as you do some voltage level adjustments (LDO or switching power supply etc), your outputs are nolonger directly comparable to other level adaptors.

Any tips on this behaviour?

Given there are voltage level adaptor chips for inline circuitry (or even using Buffers and such), I'd think it'd be a simple thing, but using my 7805 and TPS7133, versus the PC power supply going through USB and FTDI, is making problems. Curious :)

Easily worked around, but I'd like to know whats going on..

jeff
 
No time to talk now, really damned tired, no sleep in 3 days ..

.. but suffice to say, full SUCCESS!

Lame pics tomorrow. Big ribbon cable mess incoming :)

eZ80 -> RAM -> ribbon cables -> GPU --> working

So framebuffer in shared external RAM, and GPU is able to read the cart ROM.

eZ80 really can't update the whole screen very fast (need to work on that..), but still, the fact it can do it at all.. sweet!

So, serial good, joysticks good, audio good, framebuffer to gpu good, etc and so on.. all tests are pass!

Theres a few minor physical things needing fixing in the pcbs, and the layout is really not condusive to ribbons; I really should redo the two pcb layouts so they can be stacked, with headers jacking into each other, or perhaps at least line up ribbon cables in a sensible fashion so they connect easy. Really not looking forward to routing those pcbs agian.. like a week each!

Anyway,

IT FUCKING WORKS.

If I quit now... mission accomplished.

But I won't quit now .. not until keyboard driver etc is written and I can type stupid BASIC into my TV and draw lame games.

So pleased right now :)

jeff
 
oh? So that would reduce your signal level, but the wave form should still be intact? (ie: feed it a known voltage, say 5V, and then check the scope and it'd show as 1V say; same waveform, but now you know the voltage scale due to the resistor?)
 
Last edited by a moderator:
Two lame pictures, but it was really late and I'm a tired old man ;)

The 'cthulhu ribbons' mess, that I will clean up somehow for next revision (or just make a single pcb, but I like having the gpu separate since its cheaper, and I can use it for other projects):

https://raw.githubusercontent.com/skeezix/zikzak/master/photos/zik80/zikzak-gpu+cpu-cthulhu-ribbons-001.jpg

(the cthulhu mess is because I made the pcb layout a little easier by rotating the pin headers around; didn't worry about the ribbon twisting needed :) then turns out the headers are close together, and flipping around every which way, so the ribbons are a silly mess. Definately not ideal. The more final pcb revisions won't have so many breakout pins for debugging etc, so are easier to route.. but I do sort of like having all those extra pins available 'in case you need em!')

And a simple screenshot .. the cpu rendering colour stripes to the external sram framebuffer, and the GPU reading it:

https://raw.githubusercontent.com/skeezix/zikzak/master/photos/zik80/zikzak-gpu+cpu-sram-framebuffer-001.jpg

You can see a few spots in there, as my timing is not quite right and theres some annoyances; need to fiddle with wait states and other random stuff, but, the fact it _works_ is awesome.

I'm keeping the 'actual' framebuffer on the GPU ship itself, and the external ram is just for the eZ80 scratchpad; he can udpate the framebuffer there, and the gpu detects the change and pulls it into itself; this way it can run on its own local copy fast, withotu tieing up the bus (so the z80 can actually _run_); but the pull from external ram into the gpu chip is not perfect yet.

Still, all components are proven to work at least a little; so now is cleaning up the hardware, and working on 'drivers' and firmware to make it all work nicely.

For a cartridge signature - the first couple of bytes, so the system knows a cart is in place, and not just empty air, I was thinking of using the hex code: 0xBAADF00D (Bad Food!), the idea being the Zikzak is eating the cartridge, like cookie monster :) Nom nom nom!

jeff
 
Last edited by a moderator:
ah, maybe you are right.. maybe I don't need to hook up the ftdi's power lines, just the gnd; maybe I've been using a floating ground there, which .. suirprised it works at all.

I will check that later, and check the ftdi datasheet.

I keep debating building the FTDI right in .. hell, it seems to be doing power level adaption so if it can handle the amperage, it might just be a handy thing to put in there; but as its 'unnecessary' I've been keeping it off to save on space, and just assume everyone has an ftdi-basic type thing lieing around. I used to have it in the schematic direct. Hmmmm.

I think I need a couple days to recover from the sleep dep, and then figure out where I'm going .. all my best decisions are seriously sleep depped ;)

jeff
 
I guess the next step, hardware wise, is another revision of the boards.

- Theres some minor things to fix up (such as wrong drill hole size for the cart edge connector)

- The layout is sub-optimal in ways I didn't think about until I started putting ribbon cables on there

- I'm still not planning on putting actual connectors on the pcb yet (like DB9 joystick connectors) - just pin headers still; way easier to do, and I don't mind soldering connectors -> wires -> female headers, and plugging them on the pcb; can still put them in a bo this way. Save the actual connector for a 'final' (if ever) edition .. since once you do that, you're locked to specific vendor and all that.

I keep waffling over the idea of single board (little larger, and more epensive), but all in one, no ribbon sillyness, etc. Less noise on the traces too, since no cabling needed. But larger is expensive and thats not cool, and it also means you get it all at once .. which is fine, and handy, but its also handy to have separate cpu and gpu boards, so you can use the gpu in other projects, or use the cpu as a serial audio terminal without all the extra gpu bumf in there, etc. *shrug*

Mentioned before.. making them stackable might be the 'best' of both worlds?

- I should look into standoff standard sizes, and see if I can get long pin headers that'd work, so that you can both stack and make solid

- even if you make it stackable, with headers for the address/control/data buses above each other, you could still use ribbon cables to place the pcbs side by side

- and stackable means no ribbons if you stack.. just put female header on pcb, and long pinheaders to bridge the pcbs!

The trick then is arranging the boards around that stacking need, and leaving lots of space around each connector (unlike my previous run.)

Given the cart slot, I guess base/cpu board on top, and gpu on bottom.

I guess it means lining up some of the power pins too, make them stackable as well, or use jumpers as fit. Hmm. Need to allow for some taller things like jumpers or tall-can oscilator crystals.

I guess maybe thats my next job.. spend a couple weeks laying out pcbs again (uggggh :) , and go from there.

Also: may lay out another power pcb, and see if I have any switching power ICs; the 7805 is reliable and a little workhouse beastie, but it does get hot as hell; I've got some litlte heatsinks around I can screw on there, but really.. the switching power ICs generate no heat, and do more or less the same job; I've avoided them due to ripple concerns but I'm sure a cap or two will sort that out.. so probably okay. Will check my IC inventory :)

jeff
 
To fill your meaningless days? (oh wait, only mine are meaningless..)

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

When it starts up, the previous run is still visible in the RAM; a countdown moment later, it clears and does the linedraw; during, you can hear my tapping keyboard to tell it to keep going; at the end, I hit a few keys to tell it to clear and then to render the test pattern.

The speed is not all that fancy, but the GPU is hammering the bus at its leisure (which suspends the cpu); they really should be watching the signalling, but I couldn't be bothered to set it up.. its only a 20 line code demo on the eZ80 :)   ie: the GPU should be waiting for 'frame ready' signal from the cpu, and the cpu should be using vblank to inform it to start another frame; instead, the cpu is sitting on countdown spin timers, and the gpu is just going willy nilly 'more or less'.
 
Last edited by a moderator:
What can you do on a 1inch-sq-pcb?
Not much, I have to concede ;)

But it's far enough for a bunch of SMD components. My board only has a STM8S, a SWIM connector, some "large" pads to solder kynar wires, a dual pin connector, a bunch of resistors and capacitors, an rgb led and a few SMD transistors. That's all what's needed for a MD switchless region mod… I've even been told that some parts are a bit "overkill", the mod could have worked without it :p

i.png


The board is more or less 30mm by 17mm. 

I'm currently writing the "story" of the work I've done for this mod … in french :D

I'm so involved in this project that I have troubles to keep the writings short. It's not easy to remove the parts that could be less interesting for the reader.

Will check my IC inventory
 
I should do an IC inventory… and get a bunch of electronic parts drawers to get them sorted :D
 
Last edited by a moderator:
Back
Top