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


The only problems I can think of with this design, software-wise is that in forcing people to use double-buffered code, you're forcing them to redraw the whole stage each frame. Certainly on old 8-bit hardware at lower clock speeds that was tricky to achieve. I suppose if the CPU were to remember the sprite positions from two frames ago, it could still paint out those locations before redrawing, but that means actually having to plan and remember things, rather than just using the current values of X and Y for each sprite from last render before invoking new code to calculate new positions.


Hardware wise, how do you cope with switching banks on the fly like that? Does the CPU do any sort of pipelining? If so, it could have done a fetch on one bank and end up writing to the other, if it does fetch and write in separate cycles.


Edit: @Kodeln Sure your soldering iron is hot enough? Lead free's more likely to half melt than old solder. Also, flux.

No worries there..

The page flipping is controlled by the CPU; right now the code will be all flashed in.. one big shot; 'firmware' and 'game' are built together and flashed in, so the game can have page flipping or not.

When I add a cart slot (or SD slot?), I'll have a bootloader or other base firmware setup, and it'll be an option to use the page flipping or not. I'm expecting to make it so the cart, if it wants, can fully take over the system .. do what it wants, so it can install inteupts and such as it sees fit. (Not even started mulling over carts yet.. ie: are they just ROM-packs, or can you add periopherals with them, such as additional joysticks or serial ports? and if so, need to support multiple cart slots.. one for games, one for expansion? *Fear*)

Either way, its consentual .. the 'gpu' raises the 'we're going into vblank now' pin (and clears it later); the cpu-side is supposed to watch for it (or software can set up an interupt on that pin), and then if it is _Ready_ to flip, it can toggle the page.

ie: The gpu can't force a flip, since you'd end up with tearing; you want to flip at end of screen (to avoid tearing) and avoid flipping mid-write (to avoid tearing, of another kind.)

..

Theres no caching or pipelinging magic going on I think, but a good thing to check for :eek: )

The actual page flipping is just a single pin .. high or low, and that sets which RAM (lets call them VRAM) is on cpu, and the other is on display. If you want to know how it works.. chek the schematic, and I can write it out for you.. but its essentialyl just using MUXers (multiplexers.) Each MUX I'm using is two sets of 4pins in, and one set of 4pin out, and some pins to control which set is connected. Think of it like the letter "Y", and you can pick which side is connected.. A or B. Its a one way flow, which is annoying, though, so mostly only useful for write stuff.. address lines, control lines; for the I/O back from RAM into CPU (so it can read from thge page), its some work (not much.)

It is tempting to make the VRAM write-only, simplify some of the wiring a little, but its not too hard to make read/write work, so _Should_.

Also, as the VRAM is 'large' (and I can make it bigger, add 128k or 256k say), it can be used for storing stuff:

i) If you're not doing page flipping at all, then its easy to use for extra RAM

ii) If you are doing flipping, you can still use it for RAM, but have to be mindful of..

- which page is live, for which data you've got stored there; only udpate certain thigns while the extra RAM page is available to you? Like move sprites every other frame? :eek: Or if doing some big calculation, do it gradually there?

- or if you need to store reference data, stick it in both pages? write it out to address XYZ on both, and then read it as needed not caring which chip is available?

..

I can add another data bus, a pure RAM private-to-cpu bus too, but I'm avoiding that complexity for now.

Right now the 8bit cpu's I'm using, have say 4k of RAM in them, so that I call 'fast ram', and that is probably enough for most games anyway, or simple applications. (These guys also have 128K of flash space, so quite a lot of data could come in there, read only wise.)

If I cut over to a real 6502 or the like, though, I need to add a RAM and ROM separately, no flash/ram built in.. no big deal, but more wiring :)

jeff
 
Hmm, that would make the coding of sprites over flipped pages easier - store the locations of the sprites in the spare bit of vram. Hence that data is encapsulated with the image it was generated from - so your redraw logic is just:


- read sprite coordinates


- blank sprites


- calculate new sprite locations


- write sprites


- write spite coordinates


There are other good reasons for making the vram readable. Main one I can think of is collision detection - one simple way of doing it back in the 8-bit days is checking if a selected set of pixels are the background colour before plotting your sprite.


But both those problems are work-roundable. They just make code a bit more complex and slower, if more flexible and powerful.


Regarding allowing cart code to take over the system, seems to me it's simpler not to try to block it. To block it you're going to have to so some VM type stuff where you parse and rewrite code, which is going to be hellaslow. Just leave it such that code can either read the current interrupt address before pointing it to their own code, allowing their code to daisy-chain on to the existing handler, or just blat over it.


I have had a good look at your schematic, I'm just not that familiar with all your chip codes and their pinouts. But it makes sense that the lines going from the CPU to the RAM control chip control switching, and like you say that sounds like a good way to do things. It wouldn't result in tearing as I understand it (that is, swiching banks half-way through the scan) but rather the GPU switching banks when the scene was only half-rendered, if the GPU controlled switching. As the CPU controls it if it's not ready when the vsync pin is raised, it just doesn't switch that frame, and your frame-rate drops. That was how it used to be when I coded 8-bit - invoke an OS subroutine to sit and wait until the vsync pin raises, then do your stuff (including switching banks, although those didn't come in 'til after the 8-bit era for me). If you missed the window then you just end up waiting through the remainder of the next scan until the next v-sync window.
 
Hm,, one brain pulse..

RAMS usually have /CE (chip enable), /OE (output enable, read mode), and /WE (or /WR) (write enable, store mode)

Some also have RD for read mode.

Not entirely clear on difference between OR and RD, so I bet you can tie those together.

You must never have WE and OE at the same time, or the data is inconsistent. (in practice since cpu is slower than RAM in my case, I go from write-to-read by first disabling write, then enabling read.. I think thids is the implied best practice. But if you do it in the other order, I'm sure the chip does not explode.)

Still, it uses up two pins for control lines.

Strikes me .. I wonder if I can just run one through an inverter.

ie: Use 1 pin, and imply that low is read, and high is write, say. Normally OE and WE are active-low.

So maybe have 1 cpu pin, and join it to the two control pins on the RAM, but with WE on an invertor?

ie: So if cpu pin is low, then OE is low, and WE is high; if cpu pin is high, then OE is high, and WE is low.

Sounds like you should be able to drive the RAM control off one pin, and save a pin?

jeff
 
Hmm, that would make the coding of sprites over flipped pages easier - store the locations of the sprites in the spare bit of vram. Hence that data is encapsulated with the image it was generated from - so your redraw logic is just:


- read sprite coordinates


- blank sprites


- calculate new sprite locations


- write sprites


- write spite coordinates


There are other good reasons for making the vram readable. Main one I can think of is collision detection - one simple way of doing it back in the 8-bit days is checking if a selected set of pixels are the background colour before plotting your sprite.


But both those problems are work-roundable. They just make code a bit more complex and slower, if more flexible and powerful.


Regarding allowing cart code to take over the system, seems to me it's simpler not to try to block it. To block it you're going to have to so some VM type stuff where you parse and rewrite code, which is going to be hellaslow. Just leave it such that code can either read the current interrupt address before pointing it to their own code, allowing their code to daisy-chain on to the existing handler, or just blat over it.


I have had a good look at your schematic, I'm just not that familiar with all your chip codes and their pinouts. But it makes sense that the lines going from the CPU to the RAM control chip control switching, and like you say that sounds like a good way to do things. It wouldn't result in tearing as I understand it (that is, swiching banks half-way through the scan) but rather the GPU switching banks when the scene was only half-rendered, if the GPU controlled switching. As the CPU controls it if it's not ready when the vsync pin is raised, it just doesn't switch that frame, and your frame-rate drops. That was how it used to be when I coded 8-bit - invoke an OS subroutine to sit and wait until the vsync pin raises, then do your stuff (including switching banks, although those didn't come in 'til after the 8-bit era for me). If you missed the window then you just end up waiting through the remainder of the next scan until the next v-sync window.
Yeah, I expect so; if we have a big RAM chip attached dedicated to the cpu say, we coudl copy bits of cart space into RAM space for execution and all sorts of stuff.. but seems that we just have a memory map; some of it dedicated RAM chip, some of it cart ROM space. Default bootloader checks and sees cart, and jumps to cart address if present, and away you go. The curret syststem here, means getting to RAM you have to set address pins and go, its not 'automatic' by the cpu, so it slows you down .. cart woudl have to have a loader, that you copy into chip native ram, run, and that loader in turn messes around .. pretty ugly.

But could just use "XMEM" type interface for high pincount avr's, and then use an extra RAM chip and it acts as chip native RAM; or use a 6502 or z80 or the like that has no built in RAM, and then a ROM/RAM decoder and go to town.

So for carts, I may wait for going to 6502, not sure .. need to think it ovber a bit; I've not really thouht about it at all (given the schematic, you can see.. theres just no place to put in a cart at all.)

I could stick in an SD card reader and write some 'get sector X' type code, so that it could load up small program parts (like old DOS overlays) or something.

But only considering doing any of that stuff if peopel start wanting to build their own zikzaks, and we actually want non-demo software; if its just me, I don't really _need_ to go that far (but may well do it anyway.. for SCIENCE!)

RL is too busy right now,m no time for hacking here.. but *feeling the need*

jeff
 
But only considering doing any of that stuff if peopel start wanting to build their own zikzaks, and we actually want non-demo software; if its just me, I don't really _need_ to go that far (but may well do it anyway.. for SCIENCE!)
I would without a doubt! And wen you'll have a demo working, I'll make (with your permission) a little topic about the zikzak on a french forum. They're arcade cabinet collectors, they quite like to mess with PCB, soldering irons and old-school electronic devices  :p
 
For that, you'd likely want a pcb you could get (but each person could source their own ICs, sockets/etc right?) Or woudl they breadboard/perfboard it? Or need full kit, with ICs?

ie: If I go to pcb (seems likely, though another challenge) I may try to get a pack of 5 or 10 (or more?) done; or maybe a 5-pack first, to see if it works at all (glitches in the pcb design), and then maybe a few more if people want 'em..

No pre-order mess here :)

Guess I should start thinking about the larger picture .. making sure audio works and some other expansion bits.

Do we need cart slot day-one, or just let folks flash into the avr for demos/games/code?

Do I need keyboard support, so we can type into it? :) (then we get zxdunny to port his zxbasic interp ;) (actually, I was thinking of Gordo's Tiny Basic from what, 35 years ago ;)

Or do I just go ahead with zikzak r3 (the current one), and then worry about cart/keyboard for zikzak r4? (still hoping to get 2 joy and 2 serial ports in for r3)

jeff
 
Last edited by a moderator:
No need for full kit.

Many of them have the tools needed to etch one sided PCB (two sided ones are really tricky since the layers must be accurately aligned during insulation).
Since you told sooner that the zikzak will most probably need 2 or more layers, it's probably better to do a test in a PCB factory (I can't remember who told me about OshPark… but they're not expensive and they ship worldwide for free).
Then either you release your pcb design as open hardware or you sell the bare boards yourself.
 
I don't think keyboard is needed if you include a cartridge slot. That would make the zikzak look like a "real" console (we love to plug PCB in edge connectors like with JAMMA, MVS and all the consoles with cartridges :D ).
 
 
Just a little long thought here :
Most of us (in the arcade forum I was talking about) are avid CRT fanatics for old-school gaming.
VGA signal isn't that far from the RGB + composite sync (VGA is a 35kHz signal while RGB is a 15kHz signal) used in most CRT TV sets (all the french crt tv sets have at least one SCART plug with RGB).

That's why, with a VGA to SCART cable, a compatible video card (mostly ati, it's the reason I love them xD) and a software called Soft15kHz, we can run MAME on TV sets and arcade screens without additional hardware/converter.
All that to say that it would be great to be able to output RGB or VGA with zikzak.  :unsure:
 
Last edited by a moderator:
All I know is I don't want to go back to NTSC/PAL .. *nightmares*

Are there cheapo VGA->RGB cables? ;)

(On my emu-cabinet, I just use an old ATI card .. "ArcadeVGA" in fact, to make my life easier at the time, to drive the CRT. I too am a CRT nut .. my arcade machines are authentic, generally.. but I put an emu cab in one, too..)

What sort of connectors you talking about? Hmm.. shoudl just route RGB+composite sync through VGA connector, and then guys coudl hack together a VGA connecto to whatever is needed; ie: flash a different 'gpu' to spit out one or t'other signals, or something. Hmrf... probably not too hard, given I'm using an mcu for the address adder and sync gen. (zikzak r4, maybe do it all with discrete logic chips, much faster and tighter, higher res, but less flexible of course..)

Now you have me thinking.. jsut like designing for home, versus designing for production; designing for self, versus designing for other people..

jeff
 
320px-SCART_20050724_002.jpg


I'm talking about SCART connector, the standard created in France that was quickly adopted almost everywhere in europe for VCR and consoles. (mainly because RGBS had a beautiful image quality compared to composite signal) ;)

RGBS have nothing to do with NTSC, PAL, composite or even s-video. It's sort of the ancestor of VGA.
In SCART, you can have 4 separate signals, one for each colors and one for the sync the other pins CAN carry many other signals (stereo audio, image format selection - 4:3 or 16:9 -, it can carry s-video and composite signals too, but it's not required … there is even a pin to force the tv to switch to AV channel).

From what I've read the only thing that change between VGA and RGBS is the sync signal.

That's the reason why that kind of cable, with the right graphic card driver, allows us to display VGA signal on tv set.

EDIT : The main difference is that in a VGA monitor the horizontal refresh frequency is ±31kHz while TV sets have it at 15kHz, in fact, it would probably be easier to manage the display at TV frequencies than at VGA ones… 

EDIT 2 : Max resolution on tv sets is an interlaced 640*480. Of course, it's halved if you want to do progressive scan… that's how you get scanlines :D
 
Last edited by a moderator:
hell, could just..

i) add a SCART connector, with the same pins as VGA gets; then just flash a SCART or VGA firmware onto the gpu avr and plug into the right connector ;)

ii) use a VGA conn -> SCART conn adaptor; put the SCART signal onto VGA conn, and flash the right firmware, and use an adaptor.

So question is .. is there two ports on the device, to save you an adaptor... then you solder on the connector you want :)

*shrug*
 
Put me on preorder and update firstpost with a list of takers?  Would be handy to have something like this to bring along for presentations, everywhere has vga and you dont need a whole computer to do a few words and simple images onscreen.
 
Wow, a 21-pin connector?  I guess SCART still fits into the initial vision of the Zikzak - "I'm going to make an early '80s style 8bit computer and game console, from scratch, using more or less the same kinds of parts as available back then."  SCART was around in the early 80's, but mostly in France - it didn't have much support outside of that country though.  It did have a superior picture as opposed to NTSC/Composite.  I just sort of thought that it was a barebones project with simple chips and standards from around in that era.  Like this was more of an educational/engineering type of project about learning how the chips/silicon/electricity work together to make an early 8-bit computer work.  NTSC and maybe 6502 chips would make more sense to me, but then I might be biased(?).  I haven't read most of this thread, just bits and pieces upon occasion...so I saw that you had a rudimentary video signal from your breadboard back a few days ago...

Anyway, no matter what route you go down, it's a really interesting project.  Please keep truckin' on.  Perhaps I should read up on what you've tried before I blather on anymore.   ;)
 
 
Put me on preorder and update firstpost with a list of takers?  Would be handy to have something like this to bring along for presentations, everywhere has vga and you dont need a whole computer to do a few words and simple images onscreen.

I doubt this would be any use for presentations; for that, use a Pandora :) (or a raspberry-pi, or a phone..)

This is an 8bit very old school console/computer; its not going to run any modern software; any software for it will have to be hand rolled by a scant few people.

Now, if you wanted to code up a image-to-zikzak-converter (not hard) and then cycle through images with a joystick, it would not be hard; but you're not getting high res or high colour depth, either .. it'd be more like what a Commodore-64 could show :)

(this is not the best I could design; this is a design to be simple, and to learn basic old school electronics..); making a modern high res linux machine is easier :eek:

jeff

I did NTSC/PAL first, but they're _REALLY_ painful, and I barely have any displays that can show that stuff.

I've switched to VGA, since its actually useful .. can plug it into anything .. and its actually much easier to spit out.

jeff
 
I did NTSC/PAL first, but they're _REALLY_ painful, and I barely have any displays that can show that stuff.   I've switched to VGA, since its actually useful .. can plug it into anything .. and its actually much easier to spit out.   jeff
NTSC/PAL composite signal is a nightmare, I agree.
Like I said the RGBS (also called components) is VGA with a slower horizontal refresh and slightly different sync signal. (I found a pattern generator with complete schematics and source code here it's made using an ATtiny )

So yeah, we can solder a VGA to SCART connector and flash the GPU with RGBS out code. 

On the other hand, if you switch to discrete ICs, it probably won't be that easy to change the video output. So if you switch to "pure hardware video out" it would be nice to have both VGA and RGB circuitry.

Why I like SCART connectors? It's all-in-one! You connect one cable, and you get good quality video and stereo sound instantly. :p

Franko said:
SCART was around in the early 80's, but mostly in France - it didn't have much support outside of that country though.
It was mostly in France at first (since it's been designed there), but it's been used almost everywhere from the late 80's until HDMI/DVI became mainstream. Especially for devices that were used to record and/or playback video (Gaming consoles, VCR, dvd players, early HDD/DVD video recorders, …).
EDIT : I forgot to say that Amiga monitors (1084S-P1, don't know about the others) have a DB9 connector for RGBS input :D (I love that monitor, I still use it frequently)
 
Last edited by a moderator:
I don't think SCART made it out to North America (?) .. don't think I've ever seen one, anyway :)

But yeah, since its mostly a software mod (on this revision anyway), not something I need to sweat over yet :)

jeff
 
Just about the only time you see SCART here in Australia is on stuff imported from Europe.  It was certainly never a standard connection method here.

- Neelix
 
I must admit, for carts I was assuming you'd use NOR flash so you could execute the code in space, like you could on masked ROMs back in the old days. You'd just need to have some free space in your address map (and it looks to me like you're not using the top bit set area on your RAM chips currently, if I'm reading your schematic right), and circuity to check that bit and redirect your lines to the flash reader/masked rom. It looks to me like this is one place where you can't do it like an old-school computer if you want to do it cheap though - dunno what NOR flash prices are like, but stopping you using cheap SD cards seems a bit like cutting your nose off to spite your face.


Edit: I'm not reading your schematic right - you need the spare pins on the CPU side, not the RAM side. But perhaps PC0 could be coerced? Dunno.


I guess it should work pretty similar with SD cards and other NAND flash, just you have to have a spare RAM bank somewhere for a loader to copy the code into. It can then jump into that address space and run from there with full privs. You could wire up that RAM bank similarly to how you'd wire in a ROM cart - use even more MUXes to switch to the CPU over to this RAM (in place of the vRAM banks).


You could still have subroutines on the internal flash if you want to make it easier to code for, and to assist coders in getting to grips with your particular architecture, especially when it gets a bit more complex and you start having to deal with joysticks and other peripherals.
 
Last edited by a moderator:
Regarding 'execute in place' ..

Theres a few architectures, Harvas versus others etc; the avr8 architecture is one where .. we've got that bit of built in flash and RAM; thats handy as heck for small things, but it often means its painful to add externals. ie: Easy up front, painful a bit later; with 6502, z80, 8080, etc, you have pain up front, but easier later -- you have no built in ram or rom so you have to build it in, but it works as expected.

With avr8's, you have ..

- no external memory interface (on smaller pin count guys)

- a simple external memory interface (XMEM) on larger pincont guys (64pins and up, for those that support it)

The XMEM interface is still small RAM too .. I think limited to 64K address size, and due to the built in RAM, _some_ of that address space is already occupied; ie: if its a 4K RAM chip, then the first 4K will go to local RAM, and then theres osme buffer space and funkyness, and then the rest can go to XMEM if you enable that interface.

So if no XMEM, or bitbanging it (like I am doing), you have to manage it all yourself -- set the address pins up, set the control lines, wait a moment, get the value back, rinse and repeat; since you're using your code, to set pins up its hard to just run your coce from the external memory. When you are using XMEM it is essentially like native memory .. the mcu will work with it, and no problems.

I'm handicapping myself here..

- trying to do it all myself (so bitbanging it all), when I _could_ use XMEM and have the memory treated native .. so I am making it harder on myself than I have to

- I'm also trying to the deisgn simple enough where switchign back to a 6502 or z80 or the like shouldn't be too hard

- Regarding XMEM or not .. I was originally planning on using the atmega644p's for both mcu's, since I have some, and its common and inexpensive, a simple 40pin package .. but I alloowed a little bit of cheat a few pages back, so for my cpu mcu, I've cut over to the atmega128 .. 64pins, less RAM. Now, this guy does have XMEM, but I'm chosing not to use it (though I am using the same address lines as XMEM uses, so could probably just toggle it on if I wanted to..) .. but I want peopel to be able to use most any atmega without a problem. You could cut to a attiny or an atmega, as long as you have enough pins for what you want, and no problems.. same design 'more or less'. (like, say oyu cut back to a 644, just drop some of the extra pins I use, or use a bit less memory pins; same for an attiny..) -- same code, same everything else .. but if I start relying on XMEM, you end up being very restricted which avr's are design and code compatible.

.. so yeah, a bit weird.

This means for a cart, its essentially a read-only source and we copy parts of it into the limited native RAM; sort of like old DOS overlays in a way .. say keep 3K of RAM as local, and them copy in 3K blocks from the cart, or something.

Sucks for graphics, though :/

Again, this isn't the 'best console I can design', but it is one that is both simple, and exercises a number of pints I wanted to play with and learn.

I think for r4, I'll think about carts, and how to make it much _better_; r4 is a ways off.

ie: It might be time to go back to a 6502, and use EEPROM for ROM and a 64K or 128K ram chip for RAM, ... tonnes of space!

So I've been thinking somethign like..

r3 -> the current avr based design, works great, but limited and goofy RAM

r4 -> maybe cart based, maybe 6502 or z80 or something

r5 -> same as r4, but possibly using a discrete graphics system? Very much mroe complexity, but higher res faster grahics, tiles, sprites..

We shall see :)

jeff
 
.. so yeah, a bit weird.
Erk! You can say that again! Sounds awfully wasteful in that you're presumably looking at 3+ ops to get a single byte back from RAM, and (assuming your CPU supports it) missing out on all that indirect lookup goodness. Still, it's only your VRAM I suppose, and by my reckoning writing to it should be quicker.


Wouldn't be too bad for reading joysticks and the like, but yeah, deffo no XIP.
 
:)

yerp, one step at a time. 4K ram (with 128K flash on this chip!) is pretty stupendous though, in early 80s terms. And slow reference ram available every other cycle (or stick to single buffering..), what more could you ask for ;)

I'll make it better for r4 :eek:
 
Back