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

[skeezix]

This will emit VGA signal; jack it into whatever is desired. There is no software scaling going on per se .. its all hardware timing. Double the X? take a bit longer to add the next address. Double the Y? Decrement the address by line-width. Piece of cake

Resolution is pretty much arbitrary (and still up in the air, this is all pie in the sky just for back of the envelope feasibility.)

(That said, I did build a zikzak3 with a full hardware double buffered framebuffer, from scratch out of basic ICs, and it worked great.. with arbitray low resolutions; I'm using low speed micro's, so can't really support high resolutions until I switch to dedicated graphics hardware of some sort, but thats cheating

jeff

 

[skeezix]

Neat! DC outrunner motors have their can spin instead of the axle ... Crazy!

 

[skeezix]

OKay, back to Zikzak ..

(RL has been kicking our tails for a few weeks; but I did manage to mess around with some servos and make a pan/tilt camera for my car/tank/thing; so it can look around, and up/down, with a webcam. Now I just need to code up a high speed webcam image stream server so a phone can see what it sees..)

Zikzak wise, I've just ordered a few Z80's; they're still in manufacture, which is crazy awesome considering how old they are. The 6502 and 6809 are harder to come by and not cheap (though strikes me a 'cheap' way is to buy up old yardsale computers, or cheapo ebay auctions, and pull out all the chips.) For these old chips, you tend to need a CPU (6502 say), and some peripheral chips like a PIA or ACIA or the like, for interfacing to stuff.  I was leaning towards 6502 based system anyway, since I was a Vic-20 kid, or a 6809 since it was really quite superior in a lot of ways to that whole generation.. but Z80 is a classic all the same, and used in a great machine awesome machins of the era (and still, apparently.)

So now I'm back to designing Zikzak, but on a pure old chip, not even a newer CPU design like a microcontroller. The mcu's have built in RAM and flash which is very handy, but cheating a little; still, I wanted to learn about them so I've got those under my belt now .. but time to dig a little deeper into time, and go authentic. (I'm not going to dig so far as to making my own CPU from primitives.. you _can_, people do, but they're sick people. Dimented people

Anyway, so I'm aiming now for..

Z80 CPU

32K (?) ROM

32K (or possible as much as 128K or 256K) of RAM

Phase 1: serial (or perhaps usb serial) communication with it; might be able to run 1970 old MS BASIC on there

Phase 2: my old axe to grind.. VGA and framebuffer!

With these machines, carts are pretty easy to implement I suppose; but the real annoyance is that you have the ROM/RAM division, and tend to use eeprom's for ROM. (Or flash, or even SD with a RAM loader or something nowadays perhaps..) -- but to be authentic I'm going to use some old eeprom's from an arcade board I ripped apart 20 years ago... (god, I feel old )

So the trick then is how to make life convenient; you get spoilt on modern mcu's where you add a ISP programming header and flash it to your hearts content; I coudl add a ZIF socket for the ROM, to make it trivial to eject and stick into a programmer of some sort, but thats pretty annoying. (Could make my own prorgrammer out of an atmel or arduino or something, too.)

But I'll see if I can design in a programming header onto the board. It'd be cool to be able to program the eeprom live (or on the target board anyway), without having to pop out the chip.

We'll see how the design comes..

... and back to figuring out how to interleave RAM access so I can get a VGA out of this sucker. Due to old parts (an original 1980's ACIA for instance), I might well be limited to 1MHz or something, so I may hav emore 'timing cycles' to do VGA with

jeff

 

[skeezix]

Buddy of mine suggested that instead of building an eeprom programmer onto the board (why not?! I say , to just put an eeprom socket on the board, and then have a riser-adaptor type board as the programmer; ie: the little programmer board in turn has a eeprom socket, and a tall riser set of pins.. plug the whole programmer into the eeprom slot on the main z80 computer board, and it acts like a pass-thru when not programming.

Should work, as long as it has its own separate isolated power supply (so that you can turn on the programmer, or the z80, but not really both; when programming, you don't want to leek power into the rest of the board and wake it up, or else you'd end up with bus contention etc..)

Anyway, neat idea.. I'm inclined to just design the programmer right in, but might be fun to make it more modular like this; try to keep the z80 computer to a minimum of chips/complexity, make kits of it for a few of you sickos, and an optional programmer kit, or something

jeff

 

[comradekingu]

i guess that adds to the modularity, seems good. I already have a programmer.

 

[skeezix]

Funny thing about building a minimal programmer..

Assumption: Using a plane atmega644 (most atmega's will do)

--> could use an arduino if you have one lieing around, but arduino sometimes uses up half your I/O pins for random stuff (depending on the arduino model); I tend not to bother with arduino myself.. I'd rather roll it from scratch and learn a bit more, and have lower power usage, more control, no wasted pins or devices on there ...

--> given at atmega644 (I have a half dozen of them so I use them for everything), thats 64KB flash on the device itself (some models have less, some have more)

So theres two easy methods for programming that pop to mind..

i) Use ISP (USB programming say) to flash the atmega, which in turn then programs the target eeprom

  - limits target device flash size to whatever flash you have in atmega; my target is a 32K eeprom, so 64KB flash on atmega is plenty; then just a simple script to translate your flash data into a .c file of hexdump, build the programmer, and send it to atmega which in turn flashes the eeprom..

ii) Use serial (say)

  - atmega reading serial (over usb possibly) and banking up and live flashing the target device; this lets you flash any size target with any atmega, but the disadvantage is needing to code up some simple PC->atmega protocol like xmodem from days gone past. ie: You'd want some basic error checking, as serial introduces some amount of error. (ie: if your crystal is not exactly set on the mcu, then you introduce some small %age of errors; if you're flashing 256K or more of data, you only need a byte or two to go bad to ruin your day .. so might as well build a self-correcting PC<->mcu protocol right?)

Using (ii) may mean adding an ftdi chip (say), so that you can do USB<->serial, or a MAX232 chip so you can do pure PC<->mcu serial. (mcu to mcu can get away with direct RX/TX serial hookups usually, but talking to a real serial device like a PC means upping the voltages, so using a MAX232 to do that for you.)

I think I'll do (i) first since its pretty easy, and the programmer mini-board becomes..

i) a mcu socket (40pin socket) to hold atmega644 (or whatever)

ii) a ZIF socket (with slots), so it can hold a variety of eeproms

iii) power headers

  - for the 28C256 (or 28C___ with ___ being size in kbits) it programs with 5V (or mass erases with 12V, but who cares for now..), so no special V needs

  - for some chips, you need a 12V for writing to it, and regular 3-5V for reading; I'm avoiding those (older) chips, but easy enough to add a header pin for a 12V drop. I keep a simple bench variable bench power supply, so I can run in a 12V if I need pretty easily with a couple alligator clips; if I didn't have this (kit made variable PSU, I'd wire up a PC power supply from an old machine.. they've got an assortment of good voltages, plus some high wattage, and lots of space to drill holes into to add Posts...

iv) ISP headers - for programming the atmega

v) serial/usb header/sockets - for phase 2 there

For minimal, just need the atmega/socket, the eeprom/socket and power ... on a breadboard, we're talking 2 chips and some jumpers. Awesome

jeff

 

[skeezix]

oh, I suppose thats dumb..

- on the one hand, fire and forget is fine; flash the atmega, then flash the target device, and then read back target device and compare. Cool beans.

But what if you want to read a ROM/EPROM/EEPROM as well? That definately needs serial, since you can't really flash the atmega's full space from itself. So I'll defiantely have to put a serial port onto the mini burner board

jeff

 

[skeezix]

Oops, guess I lost everyone again

I've got the eeprom burner breadboarded up, but its not quite working right. I didn't hook up serial yet, so no real way to debug other than a LED, which is telling me nothing worked

So guess I need to hook up serial -> MAX232 -> serial on PC, or serial -> FTDI USB adaptor chip -> USB -> PC, and get data dumps of whats coming out of the chip after I flash it.

Once I get the burner working right, I can..

i) turn it into a protoboard, and/or

ii) design an actual pcb, if anyone wants one; ie: add a few more LEDs for power, error, success, add in the serial/usb comms ports, try to make it work like semething reusable .. power in plugs, etc. When I do it for myself, I just jack the power into the pins and go, but normal folks expect a jack.

And of course .. work on zikzak-z80 (and 6809, and 6502 .. all very similar, at this simple level of design.) I've got the design roughed out, but I need to schematic it down. But ocne I get the burner/dumper going, I can burn in a hello world type program, and start assembling the zikzak computer itself (again .. the old design on microcontrollers was awesome, but I guess this is ultimately where it needs to go.. cheaper, less parts, and more authentic and good for learning.

Does anyone want a design (or kit?) for a cheapo lame eeprom burner? This is essentially a single chip solution .. 1 chip (socket) for a atmel to drive the burning process, another socket (zif say?) for the target device to program,  plus a few resistors, leds, and caps. Piece of cake. (Mind you, this makes assumptions abotu sizing.. real burners cost piles of money because i) reasons/greed, and ii) they have a chuck/adaptor system to let different pin-count chips go into their socket; my little thing here is specifically made for small retro eeproms, like 26pins period, sort of thing. But the design is simple, so if you just breadboard it, you could adjust the pincount easily.. just bump over the power line as needed as the chip grows. (if too many address lines are needed, then would need a shift register .. hmm.. maybe I shoudl go that route anywaym, put in a single shift register for the high addresses, to buy extra pins .. but as I don't need it, I'm not bothering. I'm only targeting 32k, 64K, 128K flash chips.)

jeff

 

[levi]

Yeah, I might be interested in a design for a board I could use to flash retro EEPROMs with. I've got a small collection of old computers, and I might even be able to make ROMs for Amstrad or Atari carts, to try things out on real hardware, dunno.

 

[bsp]

hi skeezix, freaky project you got going on here last year I dabbled in electronics myself, for the very same reason as you (software dev, no big clue about hardware). I bought one of those 12 EUR stm32f4 discovery boards (cortex m4 @80Mhz, 192kb RAM, 1MB flash), some bread boards and some sorted lengths of wire and build a GPIO VGA out (also via a resistor ladder), and a MIDI controller box (4 rotaries, 4 pots, 2x20 hdd44780 lcd). Damn, getting the TFT monitor to properly sync to the VGA signal was really not easy (I heard analog monitors are more forgiving, not sure if that's true since I no longer have any of those around). Anyways, fun stuff and learnt a lot

 

[slaeshjag]

^ Depends on the monitor. A friend got an old VGA/TTL monitor. It'll sync on anything, it can even do composite sync on green.

Heck, that thing will display stuff even without a vsync!

It's a nice monitor to play with.

 

[skeezix]

3 days of no internet connectivity at home, probably another week or more to go .. Incumbant ISP playing games with smaller ISPs, driving me crazy (I work at home, so lately..working at coffee shop.)

I've got good progress on the eeprom programmer, and working on a more refined design so I can convert it to a perfboard instead of breadboard.. but working great!

Doing from-flash and from-serial right now .. so can flash it, and have it burn chips (good for over and over burning), or flash the burner for from-serial and then it takes commands from serial port,and can dump and flash both. (and by serial, I mean USB .. I've added an ftdi usb<->serial chip, so the micro is talking serial but its going over usb-serial, totally slick. Serial using a null-modem cable sucks, I'm never diong that again

Schematics soon..

jeff

 

[skeezix]

Aaaargh, so annoying! Had no internet connectivity for most of the week, but spent all that time banging my head against my eeproim burner. It had one issue .. depending on a few factors, it woudl fail its post-burn test; it seemed like it was looping data.. I'd get value A B C D, A B C D, over and over, for certain address ranges. Made no sense. Rechecked my wiring and code 20,000 times, and hacked up the code to have stupid amounts of logging and do things in the most basic annoying way possible.

(And added usb-serial logging, which I'll use in every board I ever make again; havcing printf from microcontroller to dump text onto your terminal, is absolutely required )

Turns out, I'd made a total noob mistake; I forgot.. a new atmega chip has a default configuration which has a few pins mapped out to nmever never land, so they can be used for JTAG; most of th other defaults are sensible, to get programs up and working easy -- ie: use internal clock, rather than require an external one, etc. Cool. But the JTAG pins is annoying as shit .. by default, 4 pins on the one side of the chip are essentially dead, thogh your code will happily try to use them.

This is why it was looping.. some pins not ever changing, despite being set; I stick my logic analyser on there and poof.. ehy, I'm setting the values, but they're not changing.. w-t-f -> oooooooh, walk of shame.

That caught me once before.

I'm going to wrap all my parts box for mcu's with a big red sticker -- 'fix JTAG fuse!', so it doesn't bite me again

---> but at least my burner is working great now!

Its not set up for anyone else, and its just on breadboard, but hey ..

I've got serial working. So now I just need to add a basic protocol..

- 'dump data from address X to Y'

- 'receive X bytes and write to address Y'

- 'checksum range X to Y'

- 'self test, all is well'

- 'echo all data in serial port'

Given that, serial controlled programmer, I can write a 50 line python script or something that drives the burning.

Then maybe make a perfboard solid board out of it, or just leave it on the breadboard

Need to make up a schematic for you guys; pretty trivial circuit.

IT is tempting to mount a really tall set of pins on the bottom of the chip socket, so it can just plug down into my zikzak boards ROM socket, so I Can live program things (when zikzak is unpowered), to save ejecting the eeprom to flash, and pop it back in zikzak to run. I need to schem all that out though ... make it all electrically safe (relay? trnasistors?) so that when the eeprom is powered from below its not leaking power into the mcu that does the programming. (Even that could be safe, as the default code for the mcu first thign is just set eveyrthign to harmless mode .. butI could set it to 'all pins high impedence', while it waits for something..

Once I figure that out, I'll see if its practical to make that fancy bord, or if I just put a ZIF on the programmer, and a ZIF on zikzak, and eeasy eject/swap for programming

BAby steps.. but having the programmer working is a huge relief! Finalize that design and perfboard, and move onto Zikzak Z80 proper! woowoo!

jeff

 

[Klumpen]

Will there be a ZZP (ZikZakPortable)?

 

[panik]

Turns out, I'd made a total noob mistake; I forgot.. a new atmega chip has a default configuration which has a few pins mapped out to nmever never land, so they can be used for JTAG; most of th other defaults are sensible, to get programs up and working easy -- ie: use internal clock, rather than require an external one, etc. Cool. But the JTAG pins is annoying as shit .. by default, 4 pins on the one side of the chip are essentially dead, thogh your code will happily try to use them.

Wow! You saved me a lot of frustration. I was seeing some weird behavior on two of my analog joystick axes when I was working on my version of the picade firmware (I'm 'Rik' on kickstarter, we met there in the comments, update #31).


My ATmega32U4 development board that I soldered myself is getting a bit old, so I thought it was some loose wires or something. I thought "I'll check that later", but with the correct fuses it's solid now.


I had the fuses correct before, but reset them to factory defaults when I started this new project. I did the 'disable clock-divide by 8' and the crystal thing, but simply forgot about the JTAG.


Thanks, this really helped! I'm also really enjoying your detailed write-up about the Zikzak. Cool stuff!

[edit] *your

 

[moxie]

Eprom burner - Yes please!

 

[skeezix]

Will there be a ZZP (ZikZakPortable)?

I've ogten thought about it; depended on the revision..

The initial zikzak r1 was NTSC/PAL output, so a traditional console to TV; NTSC/PAL are annoying as hell to produce (though I did some basic accomplishments there), and I abandoned it. (I don't even have a TV that does NTSC/PAL anymore, except an old C64 monitor )

So most of my work was on r2 and r3, the big guys with hardware framebuffering and VGA output; struck me as VGA may be able to talk to little LCD panels, but certainly is on every monitor so is a good protocol to work with; but not many LCD panels talk VGA. In the end, I got my Huge Board working (!) with the double hardware framebuffer, but I've moved on from that whole design; now I'm going for straight old school, with Z80 (for now, and later 6809 and 6502) straight up design; like 5-10 ICs level of design.. something easier to assemble in breadboard, perfboard and even PCB, and using straight old school parts and design. Probably no hardware framebuffer, but I still want to get VGA out of these puppies.

As to portable, the new Z80/etc old school design should be convertable to run with a little LCD panel; given this is going to be old school and slow (not like a GHz nowadays, probabyl 1-30MHz), then any old LCD panel will likely work; I'll look into cheapo serial LCDs with their own framebuffer; nice and cheap and easy to get, but not really fast. You know, those like 200x100 sort of shitty ones they use on old phones.

Adding a d-pad and such isn't too hard at all, but making a nic case is very painful; so I might make a design thats just a portable, with a couple boards; if you want to craft a case, feel free. Most I could do is a black rectangular box, with cutouts for the dpad and lcd

(oh, and a cartridge slot _natch_)

But maybe someone _else_ on these boards knows about mechanical and so on; I'm a good software monkey, and tolerably well acquainted with electronics, but I have _no clue_ when it comes to cases etc.

Then again, if someone has a 3d printer.. that coudl do it. (I was thinking of buying into the Peachy Printer, a $100 3d printer, but the cost of resins, and the way it works, sort of make it likely not cool for larger things like cases, but great for little widgets; I'm poor righht now, so have to be consdervative, so taking a pass on it..)

But anyone has aqn idea on how to make little cases, maybe a dozen of them, let me know; we coudl do a Thing

jeff

 

[skeezix]

Turns out, I'd made a total noob mistake; I forgot.. a new atmega chip has a default configuration which has a few pins mapped out to nmever never land, so they can be used for JTAG; most of th other defaults are sensible, to get programs up and working easy -- ie: use internal clock, rather than require an external one, etc. Cool. But the JTAG pins is annoying as shit .. by default, 4 pins on the one side of the chip are essentially dead, thogh your code will happily try to use them.

Wow! You saved me a lot of frustration. I was seeing some weird behavior on two of my analog joystick axes when I was working on my version of the picade firmware (I'm 'Rik' on kickstarter, we met there in the comments, update #31).


My ATmega32U4 development board that I soldered myself is getting a bit old, so I thought it was some loose wires or something. I thought "I'll check that later", but with the correct fuses it's solid now.


I had the fuses correct before, but reset them to factory defaults when I started this new project. I did the 'disable clock-divide by 8' and the crystal thing, but simply forgot about the JTAG.


Thanks, this really helped! I'm also really enjoying your detailed write-up about the Zikzak. Cool stuff!

[edit] *your

Glad to have helped you That JTAGEN fuse ahs burnt me a few times.

I'm thinking.. theres very likely a way to in-software read the fuses; the chips have a small eeprom space, I bet they just flash the fuses in there somewhere. If the atmels are consistent with fuse layouts, which they likely are, its probably a piece of cake to read them... or even alter them in code.

So may be cool to have a standard little library function I always use, that checks (and sets?) my usual default settings; the trick is how to report issues, given you may not even have a blinkenlight .. so an auto-check-and-set standard function might be groovy,

*shrug*

I really need to chill out for a night or two, but these projects are way too much fun

jeff

 

[skeezix]

Awesome, got serial I/O working nicely. With the particular FTDI chip I'm using, I've got RTS and CTS flow control pins; I just ignored them so far, but turns out I was lucky.. output (TX from mcu, to input on PC) has been working great for debug logging. Absolutely essential .. I'll be adding ftdi's to every pcb from now on

But trying to read from the PC, didn' get anywhere with first 10 minutes blush, so I left it. (I added a basic 'echo mode' to my test code, so anything comes in, it'd send back.) Hit the scope on the pin, just to make sure something is coming in from PC.. nothing. *mrf* Check /dev/ttyUSB0 permissions and such, all looks good on the PC side.

Look up how flow control works .. okay, so if CTS is not set right, the sender may be waiting for CTS (clear to send); likewise is RTS (ready to send). Tie CTS to ground (logic 0) and it means 'we're clear, send away', and poof, PC is sending no problem now; I expect I'm suppose to handle CTS and toggle it as needed but screw it for now .. tied to ground, and Echo Mode works fine.

I've not yet thought about how I'd like to receive data from the PC; assuming (say) a 9600 baud connection, is my mcu running fast enough to burn and pull from serial? Well, the bigger question is .. I'm rather figuring to receive a page at a time (say 256b or something), and then burn, and repeat as needed. I could use CTS/RTS flow control to notify the PC-side 'wait up', or maybe we can pull the full 256 in real time, then burn it. I'm rather expecting the protocol I write to be 'heres a page of 256', then say 'burn last page to address X', and wait for OK from the burner, and repeat as needed; so at a page level, flow control is done in the protocol. So for CTS/RTS its just a quesiton of what we can receive without errors.

I guess the protocol should really have to be ..

(from PC perspective, since the python or whatever code will be the driver's seat)

Connect to /dev/ttyUSB0

Send 'You there?' and wait for some OK ACK

(on error, notify user and bail out of course; assume that always.)

Send 'Receive data name 1, size 256'

Wait for OK Data Receive ACK sort of thing

Transmit the block

Wait for OK Block Received, CRC32 checksum is <big number> ACK

Compare received checksum to locally calculated checksum

If checksum good, send 'Burn data named 1, to address A'

Wait for OK

.... repeat as needed

Send Done and hang up

This should be pretty safe more or less, and allow for re-burning same page data without transmitting or something. Features I'll never use

Given this, it should be easy to run say 1000 burn operations and see if I get any errors or not; if so, maybe need to implement CTS/RTS. Probably should.

On the mcu side, I may just busy loop to receive data, or maybe I shoudl turn on an interupt and do it that way; either way, CTS could be easy..

Wait on char present in UART (theres a bit on the UART to check this fact; or an interupt.)

When char received, drop CTS (rather, raise it high, since high is block)

Pull character

Reset CTS low (clear for more)

That is a pretty dumb strategy, but shoudl work well enough.

I'll worry about it tomorrow.. time to watch Agents of Shield!

jeff

 

[panik]

I believe bit 7 (JTD) in the MCUCR register enables and disables JTAG. Interesting thought to do it all in software on startup.


See for example clock_prescale_set() to set the clock divider and override the fuse setting here: http://www.nongnu.org/avr-libc/user-manual/power_8h_source.html (bottom of the page). Clock settings are in CLKPR. Maybe there are functions for the other stuff as well. Haven't got time to check further now, gotta run.