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


Not had much time a tall the last few weeks (sigh, sleep you little bastards!) ..

But a few small steps (and acquired lots of handy parts for Someday.. Beaglebone Black, a Teensy for emulating USB HIDs, FTDI chips, etc..)

- Added a raspberry-pi to my car/tank/thing; rpi has 2 USB slots.. one for wifi (EDIMAX teeny one) and another for webcam (the homemade electronics has the servo control, to move the webcam around.) rpi talks i2c/TWI to the avr side of things (which drives all the adc, motors, etc)

- Working on basic CGI/service, so a phone or browser can connect to the rpi on the car, and control the motors/cam that way; think -- full screen pics/video from the car webcam, with overlaid driving controls!

- Zikzak with some serial to a PC acting as wifi bridge; zikzak 8bit computer now controlling homemade RC car :)
 
Blimey, this project has certainly moved on from your original aims to just make an 8-bit computer using modern parts, but I guess you've already acheived most of what you originally set out to do, so more power to you!
 
Got distracted by summer and finding by no by wheels ...


I'm actually redesigning the zikzak to use a dual port ram; whole thing goes from like 20 ICs to like 4 or something .. Zikzak as-is is a proven success, and I started making somid perfboard version which proved unpleasant..


So currently on the go..


- make solid (perf? Pcb?) zikzak with giant chip count


- wrap up phase 2 of the car so it can rest .. Drive it around till end of summer and shelve it a bit


- work on Zikzak The Younger which allows some cheating (dpram)


---> add a basic interpreter to it


I should make a little website for these and publish all the schems..
 
Trying to figure out how a C64 does its business now ..

It didn't have double buffering so Zikzak is superior that way, but I've never quite figured out how it does the timing right .. so that the VIC chip can read RAM, at the same time as the 6502 wants to read/write to it. I think it works by virture of out-of-sync clocks, and the CPU is doing the memory management itself.. pretty easy. But with an mcu like an avr, the trick is that i'm bitbanging external memory and every opcode takes a long enough period of time, that I'm lcoking out other things from bus access for too long. (VGA is very demanding.)

So what I need to do is actually convert to using a z80 or 6502 or 6809, and figure out how to have one block but suppress every other signal to each of the two sides.

Another option is to use an mcu with memory manager in it (like some of the larger pincount avr's.. I have some), that have an XMEM interface; they allow less than 64K RAM however, and I wanted more (MOAR!) .. but if I did something like 150x100 resolution it'd only take up 1/4 of the RAM, so could still double buffer in that space, and do it without any of the crazy circuitry.

So maybe I'll look at that for zikzak4 .. a more cut down minimal version .. more like those simpler machines, a lot easier to wire up on a perfboard, but still a good learning aid and fun hack for people; a cheaper kit :)

jeff
 
I can't say how the C64 worked, but I know the BBC Micro internals moderately well. That worked by running the memory at twice the clock rate of the 6502 CPU or the VIDC video controller (hence the main reason the machine was expensive - lots of fast RAM) - run one on odd ticks and one on even and bob's your uncle. It's overkill, of course - 6502 ops take at least two cycles, the first of which is indstruction fetch but the rest mainly tweak the registers. The fast memory access instructions to zero page take 3 cycles, which presumably is fetch/decode, calculate, access. Very little of this stuff is pipelined, so most of the time the CPU's memory bus isn't doing anything anyway.


Like you say though, if you don't have the luxury of fast RAM that's guaranteed to be free when you want it, stopping the CPU mid-instruction just for a single cycle is something I don't know how you'd do. I did earlier think it used an interrupt pin to do that on machines like the C64, but the way interrupts worked on the BBC was it popped PC on the stack and jumped to the preconfigured interrupt service address - which implies many clock cycles even if your interrupt routine returns immediately, and I suspect can't be trigger mid instruction process, as the 6502 is very much not a real-time CPU. There are other pins on that vintage of the 6502 though, and I've not found a good description of what they do - RDY, for example, or SYNC. In addition to that, pins marked 'not connected' often are IIRC, and with hand spun logic designs like the 6502, can do interesting things if tweaked, all on top of the now known corner cases and other odd standard behaviour.


Edit: FWIW, the BBC Micro used at most 20k of RAM for video. In monochome it was 640x256x.125, or 320x256x.25 for four colour, or 160x256x.5 for 16 colour (though the video hardware could only actually output the 6 primary and secondary colours, plus black and white, so the high colours just flashed in the default palette).
 
Last edited by a moderator:
I think its just a question of... if the processor (whatever flavour) is doing its own memory handling, you have a shot.

For me, I wanted to bitbang it to learn something, and because the chips I picked were cheap, and had no external memory interface at all.

So I have to do things like..

Set read (or write) mode

Set address pins (increment is 1 instruction, or go to arbitrary address.. 2 instructions)

And if every instruction is say 50ns (20MHz), then we're talking say 100-150 or more ns to set up a read/write, plus the actual read/write. You also need sometimes some NOPs to let the bus settle.

For VGA, every 50ns that passes, it blows on past like 4 pixels :) Its bloody fast!

I actually bought some 10ns RAM (!!), which wasn't too expensive at all .. figured it should recover from anything I do fast enough to move on.. but even there, I found sometimes I need to NOP or two .. (!!) depending. Didn't test heavil. Next time I do serious testing I'm tieing TX (serial transmit) to a MAX232 and up to a PC, so I can stream debug logs like mad.. pretty tired of stepping bit by bit through an o-scope :)

I actually ebay'd a cheapo super low-end logic analyser for $21 (hahahaha!), which is 6 weeks from arrival due to China being far. Still, that could even be useful ... i2c and serial debugging :)

Anyway .. hmrf!

If you're using an external memory oriented processor, then you don't need to set up all the CS, OE etc on the RAM, you just LDA or whatever and away you go, using the RAM; so you get 'free' timeless actions.

So if you're taking every other clock cycle (or raising versus lowering edge?) then it may just work out.

I need to figure out how to divide a clock signal now :)
 
I got my little arduino uno, the starter pack that came with it is nice.

But I'll be ordering a few more tools, components and consumables. I need flux (to do better lead-free solder joints), 2 pins tact switches (easier to use on breadboards), high quality crimping pliers (expensive, but f**king useful), small pulleys, small braided steel wire (found some used in jewellery) and a few other thing.

I'll be able to get those in a few weeks : I signed a contract for a 3 months job with renewal possibility… The money must flow (in my pockets)!
 
Last edited by a moderator:
Still seems pretty tricky to me if the processor is wired up to handle the memory natively. Your LDA takes three ticks to do it's stuff. You can bet the first tick reads the program memory, but does it then spend two ticks reading the data or sit and chew the cud for a tick before blasting the data right out of that memory cell in one go? And if you're relying on the coder to know this stuff and allow the video chip to access memory on the right ticks, well, if it's me doing the coding then that's straight out of the window.
 
yeah; its why I dodged it all and went to the current Heavy design; makes coding a real breeze, but a lot of ICs, and a big board.

There is always an option I discarded early on..

Big RAM (say 64K or 128K or whatever), with reserved graphic banks; toggle a pin to get bank 0/1.. easy right? The problem again is the VGA reader eats up all your time.. its plowing through the reads, and your main cpu gets 0 time to actually read/write anything.

Some points of interest..

- using an avr, it has built in RAM (say 8K or 16K) .. fair amount of working space!

- using an avr, you have a pretty sizable flash, for read-only tables or some small sprites. (more space than a C64 woudl give you, anyway)

- updating the video ram then ... do it at hsync and vsync time.

Hsync in my test code in C:

  VGA_OFF;

  /* 1uS Front Porch */
  _delay_us ( 1 ); /* 1uS */

  /* 3.2uS Horizontal Sync */
  HSYNC_LOW;
  _delay_us ( 3 );
  NOP4;

  /* 2.2uS Back Porch */
  HSYNC_HIGH;
  _delay_us ( 1 );
 

About 6.4uS or so; sucks, about 15 ticks worth.. not a lot :)

The vsync however is pretty good:

    LINENOP(); /* front porch -> 1 line */
    VSYNC_LOW;
    LINENOP(); /* 1 - sync pulse -> 4 lines */
    LINENOP(); /* 2 */
    LINENOP(); /* 3 */
    LINENOP(); /* 4 */
    VSYNC_HIGH;
    /* back porch -> 23 lines */
    i = 0;
    while ( i < 23 ) {
      LINENOP();
      i++;
    } // while
 

about 28 lines worth. I forget offhand, but I think a line was about 15 or 20uS + the hsync above.. so say about 25uS for sake of argument.

28 * 25 is 700uS or about (say) 1400 20MHz ticks, if my brain is working right now (it may well not be :)

Now, thats not bad, but say you want to clear a screen (a full screen change), and you're doing (say) 150x100 (15k display buffer), then we're talking a few full screen refreshes to get the time to do all of it.

So this woudl give you (total guessing)..

- a full screen update at say 15Hz

- partial screen updates, you could probably still keep pretty full speed

Also note: You could even keep a snapshot of the display in the avr RAM, and then do lots of updates there fast, and then sync it over to the framebuffer over a few frames (with tearing, ftw!).

Heck, could still do the RAM toggle bit, to switch between two buffers..

So - double buffering, no crazy pile of hardware, but much reduces update times.

---> what do you think of them apples?

I'm still thinking then.. for v1, it'd be:

- an avr cpu

- an avr gpu (v7 or whatever, swap it out with discrete logic for infnite faster updates)

- ram chip

-> ram wired to both the cpu avr, and to the VGA port; the gpu avr is just there to drive the VGA clock, more or less. (ie: it could toggle the buffer bit, or at least raise the vsync line so the cpu coudl switch it cleanly..)

- avr gpu has the all important 'BUSY line' (or could just be the 'vsync' line); the main cpu on interupt, so when the pin changes to not busy, it burps out as much as it can and returns

What do you think there?

Coding should be pretty easy, just as long as you're careful how much you update at a time; you woudlnt' have to count cycles too much, but would have to think 'I can only update 20% of the screen at a time, if I want it in one frame'.

jeff
 
Hmm, you HSYNC idea reminds me of the way the Atari 8-bit machines (includin VCS) worked - by having a line buffer instead of a screen buffer. The video chip would freeze the CPU at hsync I believe, then presumably blat a copy of the 50-or-so-byte buffer to work from during the next H scan.


Not that that's an option for you with 1.5kish bytes of video data per line to handle (assuming 24-bit colour), unless you've got something to blit the data across. It's also a bit of a headache for coding, doing it line-by-line as you've got to start doing things concurrently without any support for it (though I think Atari had sprite handler OS routines all the way back to the VCS).


I do still like the idea of being able to update the video memory ahead of time in the current scan. Unless you're swimming in clock cycles, it's important to be able to schedule things to get the longest time to do stuff you can.


For a v1, considerations about making it nice to code on and elegant aren't as important as just getting something that works. But to my mind you've almost done a v1 now and it's perhaps time to start learning stuff for a v2.


But yes, using the AVR RAM is both a blessing and a curse. Nice and fast to write to, but like you say it'll take a few syncs to pull the video data off. But doing it that way might be a useful precursor to doing the same thing on a chip that properly supports external RAM, where the GPU-side can pull the data off all by itself. In your pre v1 design you've tried out having GPU accessible external RAM, but in v1 proper you can practise having it accessible from the CPU instead and then in v future, actually use a CPU where you can have both (and hopefully have figured out the perils of simultaneous access before then).
 
RL been busy the last few weeks, but slow progress on a few fronts..

I've been (in the back oy my head) trying to work out some of the details behind a quadcopter, for lulz. See if its something you can build 'relatively easily' for a sucky version of, or if its 'in for a pound, in for a penny' (which seems to be the case.) You can buy a toy little quad for $50, or build your own for $300+ .. ugh.

But I'm trying to go down the road of a Lego frame (an 'X' frame), with some pcbs, a battery and a camera in the middle; try to kepe it small, like a 6" frame with some 3" props or something; more a toy, assumed to explode, more than anything.

Without having yet calculated a 'weight guess', I've been trying to find out the 'rules of thumb' to determine what you need... lift-wise. ie: Given weight X, what amperage for motors do you need? and how do you determine what props to get the right lift? (based on rpm etc.)

So far I've found one rule of thumb is .. 'an amp per ounce, so the plane doesn't bounce'. That tickles my funny bone, and is interesting :)

jeff
 
This thread I've read and enjoyed what I understood, bit of an advanced project but a kool one.


I'd like to follow any progress you make with the quadcopter too, those are great little things
 
Right now I'm assembling an Elemco bench variable power supply kit; normally I make dedicated built power supplys.. such as a little battery/plug -> 5V board that can then be plugged into a breadboard or project. (that guy is 7805 based, a 5V voltage regulator.) I'm looking at building a LM317 3.3V power board as well, or just a multi-voltage board that puts out a half dozen voltages. (Sure, you can use an old PC power supply, but it also weighs a huge number of pounds and is big and noisy; my little power boards are 2" square little pcbs.)

But in the end, it can be handy to have a variable adjustable bench power supply around, and always fun to build a kit and learn how it works better ..

Then using that to power an mp6050 3axis gyro and 3axis accelerometer  and a micro, to see if the micro can get useful telemtry info; could use this to feed into my car/tank/thing (See if it can stand on two weels upright and self-balance!), or a quadcopter for self-balancing.

And then back to Zikzak retro computer :)

jeff
 
Re: Zikzak r4 idea.. see post above:

http://boards.openpandora.org/index.php/topic/13166-zikzak-crummiest-8bit-consolecomputer-ever-but-im-making-it/page-11#entry266066

Strikes me theres a big gold mine of time there..

I've rather been aiming around the 150x150 sort of display size, or 120*120, or 150*120 .. something piddly like that, with nice blocky pixels. Try to aim for say 16K per image, and double buffer in 32k; or if single buffering with harsdware buffer, a 32K chip would give you like 200x150 nicely, with a bit for external RAM, scrolling flags, sprites, etc.

For low res like that, I've been doubling/tripling up on Y, since VGA is X*Y, wit Y of 480 minimum more or less; ie: just increment Y and wrap at bottom, or do each line 2-3 times.

Now, the graphic subsystem has to care, since its not using its own framebuffer per se; just counting down addresses and having RAM point out to video during screen rendering time; so I can't do doubling etc and have the cpu messing around .. wouldnt' work out.

But one option, if more time is needed, is to not double.. just say render the top 150 (or middle 150....) lines; say we're doing 200*150, and VGA is 480 high.. that frees up 480-150 lines for other stuff; the gpu could just black out the display, and suddenly we get 320 more lines of time (give or take signalling) to do cpu stuff against the RAM.

So not only do we get about what was it, 28 lines of vblank+assorted (see above), we get another couple hundred lines worth. Or whatever amount we need. Could be configurable by the cpu, just set a flag in the video ram, and let the gpu deal with it.

ie: _video modes_

a 200*150 1:1 centered mode <- tonnes of cpu time talking to ram, can do full screen update every frame! <- games etc.

a 200*150 doubled centered mode <- medium cpu time talking to ram

a 200*150 tripled mode <- minimal cpu time talking to ram, takes a few screens of refreshes to do a full screen update (think, for slow stuff; tile games, applications, picture viewers, etc)

Noooow we're talking :)

I think this could result in a much simpler machine than the big zikzak I designed previously; like a handful of chips, much less elegant to code.. but cheap and simple to make!

I'll get back to this guy when I get time.. just moved my home office into basement, everything in boxes, and not a lot of free time anyway.. but got my desk all set up, new variable power supply assembled from a kit, got my solder station and lamps and all that already going, a new armoir/thing that is my electroncisd parts locker all set up .. fun fun :)

jeff
 
Last edited by a moderator:
Maybe a display that is available in bulk, like something used in a phone. 150x150 sounds like software scaler input lag. At least something that pixelmaps on an even (heh) edge.
 
Last edited by a moderator:
Back
Top