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


Out of interest, what does a fake capacitor look like?  I guess at the cheap end you're going to get ones that don't last very long before the puke up their electrolyte, but that's just crappy, not fake.  Do fake caps have the wrong capacitances or something?  Or are actually for a lower voltage than they're labelled for?
 
I've not run into any yet myself, but a buddy has had a few.

He's into audio equipment restoration, getting the serious audio gear from the 80s (which in many ways can exceed the stuff today) and switchign in new big caps and so on. These are fist-sized capacitors :) The fake ones there are big caps, that are hollow and win little capacitors soldered inside; like a soda can, with a little tiny electrolytic inside :)

Theres some websites online ..

jeff
 
Like C and D cell batteries which turn out to just be AA (or even AAA) batteries with a case around them.
 
Anyone in GTA need a handheld osciliscope? I'm thinking of upgrading so may have a really decent one spare.. PM me :)

jeff
 
Alright, this schematic is _nearly there_; I need to work through all those A<-> bank switches, and figure out if I need any diodes around the RAM SWitches to avoid 'backflow', and need to make some NETs of the V, GND, and AB-switch-choice to everything .. but otherwise, its more or less there!

Man, I'm going to piss myself if this actually works :p Going ot be a bitch to breadboard all this! (and I'm scared to think about the PCB.. 4 layer pcb? nightmare time..)

zikzak3-memswitch3.png
 
If you do a large enough PCB a two layer one could be enough, I think.

When I first thought about making large PCBs with Eagle and learnt about the size limit on the free edition, I knew I would make modular designs.

You know, having some kind of main board with all the fast components and having the slower components on remotes ones.

For example, having a board dedicated to power regulation, another one dedicated to the joypad connectors and controller, etc.

That way, you can re-use the various boards for another design  :ph34r:

Of course, if you do it that way, you'll need a way to connect boards. The two "easy" way I could think of are pin headers and short ribbon cables (quite used in arcade PCB) or PCB edge connectors (used everywhere :p ).

EDIT : I just ordered a shitload of capacitors, 5 prototyping boards (1140 holes… they're large enough ^.^) and cheap tweezers from china. My tin is on it's way too, but I ordered it with a screwdriver I urgently need to fix the blender (milkshake time is coming… I hope) from a "local" online shop . Now I only need to way for the various deliveries!
 
Last edited by a moderator:
The trick here is the number of crossing over lines; thats not just the schematic, an actual pcb layout would be a mess too (given the whole idea here is to have two cpus and two ram banks and hardware switching, its a big mess.)

I've definately thought of having an I/O board for example, or even an edge connector and separate 'video board' (lol! like CGA and EGA..), but not sure I want to go there; end up a big mess like the Williams arcade games with 4 boards or so :) Lots of ribbons around..

But for the mani cpu/ram board, don't want propagation delays, and its tightly bound.. one board anyway.

Be a hard one to do in two surface...

jeff
 
after the Zikzak, you must invent a time machine and go back to 1970 so you can make your millions selling this very advanced console!! :)
 
Nice :)

I did a quick check of ebay, and no obvious cheapo 'lots' jumped out; could buy a few carts cheapish, like $3.00CDN each, but most have ugly shipping; would have to buy a 'lot' of cards (like 10 or something) to the shipping spreads out sensibly.. but then you're getting good carts that would be a shame to kill.

It wouldn't be hard to put a perfboard with a flash on it (or an eprom/eeprom), and an edge connector .. but sort of nasty; need to have a cart shell!

What systems were cart based, more current and thus cheaper, and mass produced so no shame in killing a dozen carts.. just to get cases. NES or SNES or Atari 2600, or Atari XE/XL/etc .. C64 had some cart games, but not many; ... hmrf.

Anyone got a line on 5 or 10 carts ready to kill? :)

--

My schematic isn't perfect yet, but its about 80% there; I started laying out on my Giant BreadBoard Bread Board, and added the power wiring and the gpu/sync-generator; the hard part is stripping all the damned wires (and at the right lengthws to avoid propagation delay problems) and getting them onto the big memory switcher circuit. I took some pics, but its not all that impressive yet, but the BBlayout does look more or less simialr to the schematic, which is nice for .. documentation/illustration sake.

Maybe I'll try to get most of the switcher wiring down over the weekend, and then I can post pics of the stages of wiring if anyone cares.

--

"Immediate" goal is .. the main cpu just doing a pin up/down/wait cycle, a square wave in other words, to drive the mem switch line (and the alive-LED-blinker of course.) Then the gpu will just do an address count-up and vga-sync timings, and the rams to be wire dup to the DAC (already down on BB) and VGA (already down..)

So with this getup, I don't need to have the CPU and RAM bus working; the CPU will drive a (sa) every other second memswitch, and the GPU will drive the sync (its whole purpose in life, until I replaced it with discrete logic chips), and the VGA wil just show whatever random garbage it pulls out of RAM (since CPU not having a RAM bus to populate it.)

So this should let it show random static on the display, then switch to the other RAM, and show static; bit the static should be visible random colours, and given my pixels are as big as your finger likely at this early stage (do the code in C, not assembly, so wide pixels.. maybe even one pixel wide across whole screen :eek: ) ... so the two static displays should be _different_ anyway, so can sww the memswitch going on.. bam, bam, bam!

This would let me test the memswitch is working .. shoudl be able to see the whole screen changing, and if anythign doesn't change, or there is corruption or something, will know theres a loose wire or bad chip or something; and given location on the screen, I'll know which components on the BB are misbehaving (sweet!)

Should be very exciting (to me!), since this is the _heart_ of the whole computer/console design.. the hardware dual buffering is pretty sexy! Once this works, 'just' adding the RAM bus to the CPU so he can update it, and then start coding some basic demos.

--

Yes, I will take pics and videos each step.. when the memswitcher first works and we can see the static pages alternate, I'll be a proud nerd-daddy, and show videos :p

jeff
 
I wonder what Matthias did for the retrode plug-in adaptor cases, and the people selling Everdrives do (I'm not sure if ED buys them in in cases, or sources boards and cases himself).
 
Levi said:
KodeIn said:
Try to find the hidden stack of ET cartridges buried in the desert xD
Click to expand...
Funny should mention that:

http://www.krqe.com/dpp/news/southeast/alamogordo-approves-atari-excavation


Watch out Atari! The cancuks are coming to get cha!
Click to expand...
The hazard is awesome sometimes! x'D


About cartridges, there are many shitty games on every devices (I.E. Barbie games, many movie or anime-based games).


Personally, I plan to "butcher" a Ariel: The Little Mermaid (this games is just awful… it sucks!) to make a MasterSystem to MegaDrive/Genesis adapter.


I'll keep the board (you never know, it could be useful to make a cartmod or something) but will adapt the enclosure to my needs.


I also don't care about sports games… there are too many of them and most of them sucks. (yeah, I don't like sport, archery excepted :p )
 
Last edited by a moderator:
I got about 40% of the switcher wiring down (and boy do I hate stripping wire tips now!) .. but the 40% is about 80% of the GPU/sync-gen wiring. If I get a couple hours tonight or tomorrow, I'll get the SRAM control lines in place, SRAM power, MUX A/B switch control and some other bits going, and see 'if it works' (Static A to Static B switching :) .. getting there, not too far off now to find out if any of this works 'at all' :eek:

I've got a couple pics stored up, so can have a stage0->1->2->3 type thing in a day or two..

jeff
 
I think the overall design is 'proven'! ...

Theres some noise still, but I've got it so the CPU can toggle between the two hardware framebuffer pages; it can do so as frequently as it likes.. 60/sec, once per second, whatever. Right now, the one page is stable (shows up all red or whatever is in the ram location), and then toggles to the other page .. but that one is all noisey/shimmery.. and back (stable again.)

One of my RAMs is a little funky from some abuse I put it through, so it could be that; or could be .. I dunno, something (I have misconnected a few things by mistake, but those are not usually chip damaging given my supply voltage is nearly the same as the high-logic-level). Its not sync and its not VGA connector and such, since the other page is stbale.. something to do with one side, not the other; have to comb through the wiring, make sure its all stable and correct, make sure no pin is left hanging (and thus randomly spitting out values, instead of stable ones). Will replcae the funky RAM with a new one.

Hopefully not too much effort to get that one side stable, and then we're in business.

..

I also think I can get increased resolution; now that my GPU is just a sync generator and address incrementor (so it can eventually be replaced by high speed pure IC logic, no microcontroller at all), I shoudl be able to tighten the code down; right now I'm using C which is not at all acceptible for the high speed and timing sensitive nature of this, but it 'more or less works' (surprisingly.) If I cut back to pure ASM, and make a really tight routine (or more likely, a bi copy/paste unrolled ugly _Thing_), then I should be able to do each ppixel with just two opcodes..

  INC address-counter

  NOP <- bandwidth on pins is less than the chip clock rate :/ sucks.

If so, thats about 200x240 resolution .. not half bad at all! (and in 'full colour', RGB222 .. 64 glorious colours!) If I add a brightness bit ("I"), it'd be RGBI2222 which would get some 64 colours at 4 brightness levels == 256 'colours'.

With 256 colours and 200x240 I coudl do quite some game (not that I'm intending to, since no one but me would ever see it, likely :p ) .. Still, hopefully make a nice couple demos in not too far off time..

Schematic so far:

http://www.skeleton.org/zikzak/zikzak3-memswitch3.png

jeff
 
Last edited by a moderator:
Great job!

I think it would be nice to have a "hardware" video circuit, that way, the "Sync Generator" could be used as a real GPU by the games  :)

(that way, you can lessen the load of the CPU and make fancy things with you sprites)

I just got some USB enabled MSP430 to make USB HID devices.

Problem is, they're LQFP packages, so I don't have what it needs to use them on breadboards. Need to buy some adaptors  :p

… and I need some flux, to solder them easily …
 
Last edited by a moderator:
Flux pens are awesome, and easy to come by; just make sure you get the 'no cleanup' kind .. I can't bne bothered to use it, then have to wash the surface later :)

I coudl do a lot more, but I'm artificially limiting myself to 'old school' parts, 'old school' design. ie: A vic-20 and c64 and so on didn't have hardware double buffering.. they just used timing games, so the timer ran faster than the cpu, and on some clicks the cpu could hit the ram, other times the VIC-chip could for graphics. I could do something similar, but I want at least hardware double buffering.

But it woudl be easy to use a FPGA or ARM chip or somethig to do "real GPU" .. high speed, scaling, etc etc but thats 'cheating' (and not what I want to learn.)

So Zikzak is not 'the best I can do', it is merely 'a learning tool for old school digital electronics'. Simple but pretty effectively (hopefully.)

Later I'll cut over to discrete logic for the "gpu", so it'll be mad-fast, simple.

It is also tempting to make a 'best I can make' console, but then.. to what end? it'd be a one-chip SoC or something, and .. useless, right? Who'd use it? You don't learn much that way.

jeff

LQFP is not hard to deal with at least, once you get an adaptor (can be pricey, get a cheapo one.) If they're <64pin, pretty easy to deal with; if theyr'e 100 pin.. _ugh_ :) The TQFP is the 'thin' model, so much more fragile, but still not bad to deal with; I should post pics one of these moments, but my cpu I cut over to TQFP64 avr8, just to get more pins without using a pile of shift registeres (got sick of making my life hard for no reason, so thats a little cheat in the name of 'fun' :)

This guy is around the corner from me (an hour away), so probably no good for you; he's also pricey.. but you can see what you can get. (CHECK EBAY and wait 1 month to arrive..): http://www.proto-advantage.com/store/index.php?cPath=2200_2207

oh yeah .. I'm also tempted to put on edge cards and have somethign like CGA, EGA, etc .. the various revisions of the video card :eek:

On BB it sort of sucks, since you really cna't go past about 20MHz before it blows up.. but haddd it all to perfboards or pcb, and then go fast...
 
Definitely sounds like it's getting to the stage where this thread needs more pics of wiring spaghetti awesomeness.

I don't really understand modern GPUs, and I certainly don't understand the GPU you've got there, but given they're generally built to poke video ram addresses and spit out RGB, it seems odd you're just using it for timing and counting.  I guess I understand that to use it to do anything fancy is kind of cheating, but getting it to do the sort of thing these chips did in early 80's computers seems uncheaty to me.

Also, I don't get why you're conflating double bu**ered graphics and CPU/GPU interleave.  The latter just keeps interrupting the CPU when it wants to access RAM but the GPU's got it, while double buffered just needs loads of RAM and some pretty slick timing to ensure you do the switch at the right time.  And have the GPU understanding that the start and end of video RAM might be in a different place sometimes.  I guess that's why I don't recall seeing it before the 16-bit era - there were certainly games doing funky stuff with the video chip in real time on the 8-bit machines.  Elite, for example switched to a lower resolution (but 4 colour) mode at or around the same place on the screen every refresh on the BBC micro, and that was without any sort of horizontal sync indicator.  Just had to count cycles from the v-sync vector.
 
The term 'double buffering' is non-specific really; it just means two buffers, and you're swapping the visible one.

The following is garbled as I started editing and moving things around, but babies are fidgety so I'm in and out... but heck with it:

One way that first comes to mind, at a hardware level is .. say you've got 16bit addressing (a 64K chip) and you need 32K or less for your screen; a-ha! you think, you can just toggle any one of the address lines to switch banks! And you'd be right! Your code wouldn't even have to know.. it just writes o-32768 and somethign else switches the high-order address line bit (say), and good to go.

But thats not how I'm using the term; I'm using it to mean double buffered yes, but also the cpu being able to read/write to the off-buffer without concern, and the 'graphics system' displaying the other without concern.

And there is how you control who has read/write access; I'm using MUXing to have multiple buses switched around willy nilly; another approach is the timing trick, interleaving the cpu and the video system, so that they take turns working on one RAM or whatever, without colliding on the bus. ie: Reduce your wiring massively, since you have just one bus and timing games, as opposed to my way.. no timing games, but multiple buses and a nasty switching mechanism.

Can't use 1 RAM chip anymore at all, since can't have two systems reading/writing to the same chip at the same time. (Unless its a dual-port RAM, like in more modern systems; I have one of those, a 128K dpram is like $50, so I ended up figuring to do it with pure SRAM.) So say the cpu is writing merrily away to your single RAM, and the graphcis system wants to read from the ram to display something.. you're out of luck, contention; its a few problems really.. i) graphcis at high speed like VGA completely peg the chips accesses, and peg the bus probably too. ie: For VGA, I'm reading continuously and can't stop at all.. so the cpu who wants to read/write here just couldn't budge in at all.

One way you can fake a few things is to do the timing trick; say you're running cpu at 20MHz, you run a oscilator at 40 or 60MHz, and have your cpu get only every other or every third slice, while your graphics system gets the other slices; thats more or less how a vic-20 or c64 did it (I think.) The c64 had no dual buffer at all, but some games could fake it, but thats neither here nor there. (And systems like Atari 2600 didn't even have a framebuffer.. I did that first, and I want to make coding easier, not hell on earth; having to inect your code in and around the live scanline generation sucks beyond belief.)

Anyway, sorry, merging concepts stream of thought there but back to point .. I want cpu to be able to write as much as it wants, or dilyl dally as much as it wants, without impacting the smooth graphics out the other side.

So I figured then, two RAMs, swapping them. Probably one of the most complicated ways to do it (a lot of nasty wiring, much more than a c64 needed), but makes code very easy; the 'gpu' is just an address counter and sync generator, and the cpu can do what it wants.

What I'm doing now is, since my 'gpu' is not very fast (limits of breadboard, limits of 8bit avr's) I can't read the RAM and spit it out to DAC/VGA. So I have the RAM data lines put right to the DAC/VGA, with the 'gpu' just counting up the addresses and doing sync; so the gpu starts at addr0 and increments as fast as it can, remembering to do sync pulses. This should let me get 200x240 going on.

Meanwhile, the CPU has its RAM, and can do whatever it wants with it.

The CPU can toggle one pin and poof, the RAMs swap, entirely. So there are two full framebuffers ("double buffered").
 
TBD .. current 'gpu'/sync-gen is just C code, which works 'more or less', but as you can see I'm not even trying to do pixels across right now.

To go to higher resolutions and keep timing right, I'm going to have to write up the gpu piece all in pure ASM, and I'm not great at ASM these days (been a long time since I did it every day :) , and especially avr 8bit assembly. But hey, gotta keep learning right :)

So next step is..

- wire up the cpu switching ram lines (another what, 40 wires or so, not too bad) and get the control lines right (right now, I've tied RAMs to OE, but with cpu they need to have switching lines, and OE/WE managed properly when on the cpu; no biggy.)

- write the gpu bits in asm (will take ahwile tyo get right.. cycle exact is always painful)

- then some basic demos, bouncing a square around from the cpu, showing vclean with no tearing on the video side

The so-far picture (not quite recent, but .. yesterdays or two days back):

zikzak3-gpu-memswitch-complete.JPG
 
You must log in or register to reply here.

Similar threads

skeezix
Anyone able to help with faking up a bogus prototype render? :)
2
Replies
34
Views
4K
Fzero
Fzero
V
Saturn Help
Replies
1
Views
1K
V3X
V
nubie
Uzebox Console, Build It Yourself For <$30
Replies
10
Views
6K
nubie
nubie
E
Prospective Console Recruitment
2 3
Replies
57
Views
11K
anexanhume
A
M
GP32 8bit Or 16bit Render Target?
Replies
4
Views
5K
Radek
R
Back
Top