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

[skeezix]

Got things working a treat without much effort; right now I'm just typing commands into the terminal, but will whip up a 10 line python script to do the burn/test cycle for me .. but check this out

lowercase -> commands I entered by hand

+TEXT -> responses back from the burner microcontroller

#TEXT -> debug log from the burner

The dialog below is..

i) ask burner if ok ("ohai")

ii) tell burner to receive 5 bytes (which I then just type in 12345 or whatever)

iii) tell burner to dump existing memory for a small region

iv) tell burner to burn the buffer to device

v) tell burner to dump the memory again, so we can see it changed

FWIW, the 'F383' response is the crc32 checksum of the received buffer; this way the client-side can crc32 as well, and verify the received buffer was in fact correct; the actual burn process does a burn and verify as well, so this should be pretty 'fool proof' within reason (you send bad args in, too bad! its supposed to be driven by an automated client, so no malformed commands..)

+BOOTUP
+READY
ohai
+OHAI
+READY
dump 0 30
# Dump 30 bytes starting at 0
a 0 r 31 00110001
a 1 r 32 00110010       a 2 r 33 00110011       a 3 r 34 00110100       a 4 r 35 00110101       a 5 r 73 01110011       a 6 r 73 01110011
a 7 r 69 01101001       a 8 r 6F 01101111       a 9 r 6E 01101110       a 10 r 73 01110011      a 11 r 20 00100000      a 12 r 6C 01101100
a 13 r 69 01101001      a 14 r 73 01110011      a 15 r 74 01110100      a 16 r 65 01100101      a 17 r 64 01100100      a 18 r 20 00100000
a 19 r 62 01100010      a 20 r 65 01100101      a 21 r 6C 01101100      a 22 r 6F 01101111      a 23 r 77 01110111      a 24 r 20 00100000
a 25 r 61 01100001      a 26 r 72 01110010      a 27 r 65 01100101      a 28 r 20 00100000      a 29 r 72 01110010
+OK
+READY
receive 5
+RECEIVE F383
+READY
burn 7
# Burn 5 bytes to address 7
# Verifying..
+BURNOK
+READY
dump 0 30
# Dump 30 bytes starting at 0
a 0 r 31 00110001
a 1 r 32 00110010       a 2 r 33 00110011       a 3 r 34 00110100       a 4 r 35 00110101       a 5 r 73 01110011       a 6 r 73 01110011
a 7 r 31 00110001       a 8 r 6F 01101111       a 9 r 6E 01101110       a 10 r 73 01110011      a 11 r 35 00110101      a 12 r 6C 01101100
a 13 r 69 01101001      a 14 r 73 01110011      a 15 r 74 01110100      a 16 r 65 01100101      a 17 r 64 01100100      a 18 r 20 00100000
a 19 r 62 01100010      a 20 r 65 01100101      a 21 r 6C 01101100      a 22 r 6F 01101111      a 23 r 77 01110111      a 24 r 20 00100000
a 25 r 61 01100001      a 26 r 72 01110010      a 27 r 65 01100101      a 28 r 20 00100000      a 29 r 72 01110010
+OK
+READY
 

So I'll write up the little command line driver tool, and its pretty much good to go.

I've got a partial schematic done.

I should add some safeties to it, so it can do the trick where it can be used as a pass-through read, or as a burner, without ejecting the IC or anything; but for now, its a good standalone 32K burner

jeff

 

[skeezix]

Progress goes so slow when oyu onyl get an hour a night

Serial comms is working very nicely; can connect with a terminal just fine, or via command line tools (just started, trivial to write)

A terminal session (some new commands added) is here:

ohai
+OHAI
+READY
receive 5
+RECEIVE F383
+READY
buffer
    0: 31           1: 32           2: 33           3: 34           4: 35
+READY
dump 0 10
    0: 7F           1: 61           2: 73           3: 64           4: 66           5: 61           6: 73
    7: 66           8: 73           9: 64
+OK
+READY
burn 0
    0: 31           1: 32           2: 33           3: 34           4: 35
+BURNOK
+READY
dump 0 10
    0: 31           1: 32           2: 33           3: 34           4: 35           5: 61           6: 73
    7: 66           8: 73           9: 64
+OK
+READY
help
Enter commands into terminal.
ohai -> return OHAI; reset to defaults. (use as first command, always)
echo -> enter loop, returning received characters.. forever
receive N -> store next N chars (after command return) to buffer
burn A -> given a received buffer, burn to address A
dump A L -> hexdump from address A of length L
charecho -> toggle character echo
buffer -> dump the currently received buffer
format -> toggle dump formatting; default on. When off, only 1 address/value per line
help -> duh
+READY
 

Notice built in help (lame as it is .. also new is the ability to dump the current received buffer, toggle some formatting options, and reduced verbosity on the dumps

I've also whipped up a very basic dump tool for command line; a little python script that just invokes the above and writes out the dump.

I'll add a quickie burn script next chance I get (tomorrow or Tuesday) and that'll be that for the burner.

(and finish the schematic for you guys..) -- but this is a 2 chip burner Its essentially .. ISP interface for reflashing the burner code, a serial (or serial USB) interface (thats one chip.. either a MAX232 serial voltage level adaptor, or a FTDI usb/serial adaptor), an atmega chip (I use atmega644) for the brain, and a socket for the target eeprom to burn. Thats it, no crystals, no resistors, nothing. (Well okay, theres 2 caps on the atmega to keep it happy.)

Now if you want to burn smaller eeproms.. just move the power pin on the target side as needed.

For larger eeproms, add an extra address line or two (theres a few spare pins on the mcu) and move power as needed

For much larger eeproms, would need to add a shift register to handle the >18bit address, but I doubt you'd need that.

It is tempting to try to design some flexible thing in to handle various size eeproms, but thats Work, and I Don't Need It, so too bad (ie: some switching logic so you can set which pin the power goes to, or adaptor modules to do pin mappings.) Bleh.

Those modificationsare Left as an Exercise for the Student

btw, source is over at github:

https://github.com/skeezix/zikburner/tree/master/from-serial

jeff

 

[skeezix]

Oh, and you already know this code is rushed; its not my best

But it works!

 

[skeezix]

OKay, initial burn script is done too..

./zikburner.py -m burn -d /dev/ttyUSB0 -f ../from-serial/lib_crc32.h
Mode:    burn
Port device:    /dev/ttyUSB0
Filename:    ../from-serial/lib_crc32.h
>>> Sending data to burn...
>>> Display copy of received buffer...
>>> Burn buffer to device...
    Burn success
>>> Pull dump of device for comparison...
>>> Comparing...
>>> Burn verification OK
 

Things to do still..

i) Code the mcu for 'fast write' (right now it uses 'slow write')

  - fast write tries to do page-burn at a time (instead of byte burn), so much faster

  - fast write can check if current byte is finished burning much quicker than just waiting the datasheets 'max time to burn' microseconds; this would speed things up enormously

  --> right now, just burning 1K can take a minute; burning 32K would take a few mins.. should take one second total

ii) Alter burn script to break file into PageSize instead of just trying to send the whole file at once; current code allows max of 256b on micro at any given time, so trying to burn a >256b file will explode if using the command line tool. Easy fix, just didn't do it yet.

iii) Schematics

... then done the burner...

Can't wait to get back into the actual main zikzak (r5 I think now?) board, the full on z80 retro board

jeff

 

[sebt3]

I'm in awe with your progress

 

[skeezix]

The burner is a simple thing (2 chips + target device), so no biggy; the Big Zik Zak from a couple months back, that one was the awesome one

The new Z80 based on is a much simpler design (we'll see if it works .. _very_ rudimentary; but talking to minimal OS, or BASIC, via serial is cool I'll see about adding a keyboard interface as well, and of course I want to try to get VGA going on it. And maybe an LCD so we can make a portable one (with a cart slot). But the base core design shoudl be like I dunno.. 9 chips or something, nice and teeny.

The thing I've not breached yet is making pcb's.. too many variables, and routing all these wires on a board seems like hell.

I wonder how Mike did it for Pandora; just hit 'autoroute' and go, or did he hand craft every trace on the board....

jeff

 

[Asiyura]

About routing, I usually hit the autoroute button, then make many changes until it's good

 

[skeezix]

The vias really get to me

The big zik zak had a bajillion connections (like what, 20 ICs?), and all criss-crossing due to the hardware switching between banks; that was Via hell .. hundreds of traces going up and down over the boards, wanted to kill myself So no big zik zak pcb there Then I branched off into designing individual component boards and using ribbons to join a video board to criss-cross board to cpu board, etc, but that got out of control quick too.

So back to basics, a much simpler one..

Kodeln --- how did the elevator project go?

jeff

 

[Asiyura]

[…]

Kodeln --- how did the elevator project go?

jeff

Still working on that.

I don't have much free time and most of it is spent doing the chores

Sadly, I got so many things to do that it's troublesome to choose which one I'm going to do.

 

[skeezix]

OKay, got faster and large-file burning going; all thats left is to schematic it up, which shouldn't be too bad given its such a small thing

I could do a much faster burn still (I'm not doing page-burning), but I'll worry later if it annoys me. Right now its about 6K in 40 secs, which sort of stinks, but its good enough for now

edit: for that matter, I bet most of the time is spent just serial xfering bytes back and forth; right now I think I'm running it at 38400 baud; cranking it up to 115k baud would be 4 times faster. (I'm not using a crystal on this atmega644 right now, so its running at its internal 8MHz right now.) Adding a 20MHz crystal should get the 115k Baud in there; 40sec cut down by 4 would be 10sec, which seems a lot closer to what I'd expect.

./zikburner.py -m burn -d /dev/ttyUSB0 -f zikburner.py

>>> Starting the burn process...
0 secs    Burning block 0 (address 0 - remaining 6491 )
2 secs    Burning block 1 (address 255 - remaining 6236 )
4 secs    Burning block 2 (address 510 - remaining 5981 )
5 secs    Burning block 3 (address 765 - remaining 5726 )
7 secs    Burning block 4 (address 1020 - remaining 5471 )
8 secs    Burning block 5 (address 1275 - remaining 5216 )
10 secs    Burning block 6 (address 1530 - remaining 4961 )
11 secs    Burning block 7 (address 1785 - remaining 4706 )
13 secs    Burning block 8 (address 2040 - remaining 4451 )
15 secs    Burning block 9 (address 2295 - remaining 4196 )
16 secs    Burning block 10 (address 2550 - remaining 3941 )
18 secs    Burning block 11 (address 2805 - remaining 3686 )
19 secs    Burning block 12 (address 3060 - remaining 3431 )
21 secs    Burning block 13 (address 3315 - remaining 3176 )
23 secs    Burning block 14 (address 3570 - remaining 2921 )
24 secs    Burning block 15 (address 3825 - remaining 2666 )
26 secs    Burning block 16 (address 4080 - remaining 2411 )
27 secs    Burning block 17 (address 4335 - remaining 2156 )
29 secs    Burning block 18 (address 4590 - remaining 1901 )
30 secs    Burning block 19 (address 4845 - remaining 1646 )
32 secs    Burning block 20 (address 5100 - remaining 1391 )
34 secs    Burning block 21 (address 5355 - remaining 1136 )
35 secs    Burning block 22 (address 5610 - remaining 881 )
37 secs    Burning block 23 (address 5865 - remaining 626 )
38 secs    Burning block 24 (address 6120 - remaining 371 )
40 secs    Burning block 25 (address 6375 - remaining 116 )
41 secs    Burning block 26 (address 6491 - remaining 0 )
>>> Pull dump of device for comparison...
>>> Comparing...
>>> Burn verification OK

jeff

 

[skeezix]

Here is your simple schematic porn for the evening

Github has the firmware and commandline source, design notes, etc: https://github.com/skeezix/zikburner

edit: Fixed schematic

 

[skeezix]

I've started working on a schematic for a minimal z80 computer; like, a 10 chip one or something

But looking around at others work.. wow, theres peopel with 5chip ones, up to 100 chips that rivals a C64.. insane

But perhaps I shoudl work on a perfboard eeprom burner from the breadboard I've got working .. a more permanent solution, that I can re-use forever..

The z80 design is making my brain bake, but not enough sleep and doing this at midnight and later is the problem

Given a 16bit addressing space, I'm rather thinking something like..

32K for RAM

8 or 16K for memory mapped I/O

16 or 24K for ROM (at the bottom of memory)

Going for serial I/O up front (nice and easy), and then see if I can work on maybe keyboard, cart and all that later; I'd liek ot get VGA on there again, in a cheapo few-chip way. I'm really not sure if its possible to do VGA like that, but I got pretty close before; or maybe I'll cheat, drop a Properller chip on there which just reads RAM and uses its built in VGA controller

jeff

 

[Asiyura]

I plan on designing a Z84 44pin PLCC package to DIP adapter, to be able to use my free sample on various home-made creations.

Since I'm pretty busy lately, I hope it'll be before 2015

I've some basic functions working for the elevator, I'll try to post something this month… 

 

[ckblackm]

You are going to make a kit for this, right? 

 

[skeezix]

A PLCC->DIP isn't too bad; lot of damned pins, but its just perfboard and some wire and you're good to go; I've got an 84p PLCC->DIP I made (twice); first try.. one big long damned header, sort of dumb; another try, using a few headers on ribbons, so they can go anywhere they want.. addresses here, etc.

PLCC sockets are cheap and easy to get, so you can make as many as you need to try with, before plugging the chip in

--

ckblakm --for the zikzak itself, or the burner?

<pardon the ramble below; late at night, and brain fried from sleep dep and watching The Worlds End just now >

<bah, delete the ramble, too long >

I keep doign revisions, and keep plodding along (I don't get a lot of time each night) to various directions; VGA? Cart? Keyboard? USB/serial? SD? framebuffer? dual framebuffer? etc.. more modern GPU, or super retro GPU? ... so many directions.

So now going super minimal, but trying to leave some holes in it for expansion later; serial/usb SkeezBASIC, then add VGA monitor for some 200x150 retro big-pixels!

At some point I should mark a line in the sand 'done enough', and make a perfboard, and a PCB out of it; so you can dive in at any stage.. any revision .. get the notes, the schems (I have a github up with some of it) and build it; or if you want an actual kit, a baggy with a pcb and parts to solder into it, then it'll be awhile yet.. but hopefully we'll get there.

It'd be fun to order up a 10-spot of boards and send 'em off (or who knows, maybe people will want it and we can knock out a few.)

Theres also ZikMobile!

But I am meandering around a little, sorry, can't help it, its too much fun Having my retro little machin talking to SD is too neato

jeff

 

[skeezix]

Not much time, but again mulling over options for video.

As mentioned before.. generating a VGA signal is itself not too hard -- it is a timing challenge for sure, but its doable; when the timing gets hard, you just lower your resolution until it works At best, you can maybe pull off 250x240 or the like, but if you get tight you can drop down to 120x240 or 80x120 or whatever, on a 20MHz atmega644 driver. Fine, whatever   Timing gets challenged on a few fronts..

i) the code doing the work; doing it in C makes sync near impossible, and costs you just enough cycles that your resolution is compromised

ii) where the video data is stored; if you're using inboard SRAM, you're limited to 4K on most atmegas.. pretty tight (very small resolution, unless you're playing a lot of look up table games, limiting your colour options.) If you're using external SRAM, you'd better have an XMEM interface .. if you're bit banging your own serial or parallel SRAM access, you will not have time, and will en up with a 20x240 resolution or somesuch But if you do have an XMEM interface (such as atmega128), then you can have a large (nearly 64K) memory to play with, and still be full speed (the mcu can do the memory handling, as if its local RAM); then you can pull off the 250x240 sort of 'high resolution'.

iii) syncing the video data to the actual cpu; this is is the hard one.. (hard_er_)

iv) (iii) can be dodged if you use dual port ram (dpram).. a special ram which has two interfaces .. a _tonne_ of pins (full sets of address + data + control lines, times 2!) .. but very much created just for this purpose (especialyl used in vram applications.) The problem is it is very expensive in low quantities for small SRAM sizes; on the order of.. if you want to buy a dpram with 64K in it, you're paying something like $50 per chip. (ouch!) When the entire zikzak board should cost $20 in parts or whatever, thats seriously uncool. I did pick up a dpram, and its slick as hell, but yeah.. not cost effective for a kit or 'general design' imho. So .. abandoned.

In the big zikzak r3, I was doing dual framebuffer with hardware switching; totally awesome, but very complex board (for me).

Alternatives .. zikzak r4 'mini' idea I had was during vblank, the 'cpu' mcu could send data to the gpu 'mcu', who could then store it wherever he wanted. (internal RAM, XMEM SRAM, or something else.) A pretty cool idea.

An idea I just ahd last night (not sure if it would work, or have bus contention problems) is to 'clone'; for the ZikZ80 board, where ROM and RAM and purely external.. could hook up the gpu mcu to the bus as well, but in a purely read-only mode; address, data, and control lines all hooked up to mcu, and ain interupt set on the /we write-enable pin; whenever the cpu raises the 'I want to write to RAM' pin, the mcu wakes up, and latches the current address+data lines, and stored values to SRAM; if its fast enough, it shouldn't miss anything. This way its got its own copy of the video memory. Sort of cheating, but I bet this would work

..

Another idea, to minimize pin count and leverage UARTs, is just serial communications; again, during vblank on the gpu mcu, it could raise 'vblank' gpio, and the cpu interupt wakes up, and serial sends over a screen dump of data (or as much can fit into the vblank; may well take a few vblanks to do a full update.) Same timing problem as with the vblank idea above; but if it takes 3 vblanks to send a full screen, just means you avoid full screen changes, or assume a fps rate of say 20fps or 10fps .. not too bad

Anyway ..

One day when ordering a batch of parts I couldn't get around here, I for fun put in a couple Paralax propeller chips; they were $7ea, and I got 2; theyu're a sort of neat chip, with a lot of bogus junk; ie: they're multicore, 8 cores.. pretty fun! Each core has only 2KB, and they share a 32KB region; runs fast (up to an 80Mhz crystal!), but takes a few cycles per opcode (boo); still, with 8 cores, and some dedicated video hardware, it can do a lot of neat tricks pretty easily.

I also have a dumb little SX chip, that can also run up to 80MHz, but is single core; thesr fast chips are freaks (most mcu's are limited to 16 or 20MHz max, or less) .. but they can simulate i2c and a lot of other protocls purely due to speed.

The propeller uses a weird proprietary language (or C I think), with a lot of proprietary editors and bumf; so I'm not overly a fan, but .. interesting all the same.

So it is tempting to use a Propeller for VGA generator; its much easier (much fewer timing problems; only really left with the data sync timing challenge, not the others).

On the other hand, I'm much more familiar with the avr atmegas, and have a little pile of them, and already wrote VGA generators.. so I can pull it off, and its 100% rolled myself and understood.

So I should probably stick with the atmega as VGA generator. But that 4K of RAM is annoying.

Soooo, long story finish .. I fiddled earlier with bitbanged SRAM, but never the XMEM interface. Maybe I should put together an XMEM interface and get 32K or 64K onto an atmega128 (which I already have.. that was the big sharkfin pin adaptor board you may recall from earlier zikzak r3 pictures).

The XMEM interface on atmega is .. 16pin; you have a full 16pin address range, and and 8pin data bus; they put data and address into the same pins (dang, the atmega 128 has like 64 or more pins why compress so much Anyway, I think they used the low address lines in the dual form (odd.. you'd think they'd do that to the high pins, since they change less often..) - so you need to put a D-latch onto the low address lines, and latch them. ie: The chip has a latch-enable line, so it can store the current 16bit address to latch/high, and then activate the data lines.

So adding XMEM to atmega128 is a latch + sram chip.. a nice little memory expansion board.

I use a 20" LCD HDMI/VGA monitor for my day to day work; it has the dual inputs, so I can pop back and forth, but I've found it _really_ annoying to do that; code, flash, hit goofy monitor button to switch and see what happens, hit switch to go abck, change code.

Some time ago for the Shadow car/tank/thing project I picked up a 'rear view backup LCD' for cars; it was maybe $5 from ebay, free shipping from HK (woowoo!); takes composite in, and r-pi has composite output, so easy r-pi display. (Shadow car/thing has an r-pi for veyr high level communications (phone control via web), though I generally don't use that.)

I just ordered a VGA -> Composite adaptorf for $7 from ebay, will arrive hopefully in a week or two. I'm all about free delivery and cheap ebay parts When pin headers are 10c/pin locally .. a 40pin header is $4 for one! .. and you can get a bag of 40 40-pin headers for $2 with free shipping from china.. you just can't say no

Anyway, if the VGA->Composite adaptor works (big if!) and works with my resolution and sync rates (big if!), it might be possible to use this little 5" composite LCD panel has a crummy VGA approximation; be nice to have this little monitor on my desk, so I can get immediate feedback of whats going on from the board without switching over monitor. Otherwise, I may have to haul out one of my 20 year old VGA CRT monitors, big and heavy, and stick it up on my desk somewhere (theres no space, amongst my PCs and pile of electronics parts, gear, work area, etc.)

So.. whats next..

Not sure, a number of directions to go.

It is tempting though, to see about the atmega128 XMEM interfacew board; latch + SRAM + 16pin IDC ribbon connector (say), and then IDC receptical -> .1" header mini board; this way could just plug in beside the atmega128, and poof, more RAM shows up!

that'd likely take me a week or two to sort out, and by then hopefully the VGA -> composite adaptor arrives, and I can fire up some old VGA code and see if it works at all. Be nice..

If that all works, maybe code up an assembly VGA generator based on XMEM SRAM, which would take me a couple weeks to get right I bet (timing hell!) .. but that'd be sweet.

That'd leave just the synchronization problem again, but if its a serial or bitbanged parallel (during vblank) sort of interface, it'd be easy to add onto any board .. so may be the way to go for now.

I'm probably missing a way better solution for the 'how to read main RAM and show on display', but the C64 and so forth had a dedicated VIC chip, and didn't have VGA speed to contend with; composite was way more forgiving. I think they just played interleaving games.. run cpu on high clock, and video subsystem on low clock, but with VGA I always run into contention where the gpu needs to hold things the whole time, starving the cpu... (but then, I'm a total noob.)

jeff

edit; yeah, okay, to keep things moving faster ..

Given an atmega644 (no XMEM interface, but I have a little pile to work with), add a 16MHz crystal (since thats where the atmega128 maxes out, so I can match the timing tightness there; that loss of 4MHz really hurts though .. 20% more pixels gone ..) .. 74HC245 buffer to make vblank a single gpio pin toggle .. and work on the assembly to do the display from SRAM. Not sure how much I can do at 16MHz, but if I want to do an XMEM based thing, this is the constraint to work with. atmega644 only has 4K of RAM (so assume 2-3K free for the vram buffer), so I can do a small looping thing.. always loop over the same line, say, to simulate things.

This saves me bodging together the XMEM interface before I can move on, but with my sleep dep, not sure I want to tackle the super fine timing assembly right now (in an asm I don't know very well .. avr8.)

Will see if I get any time at all the next day or two..

 

[levi]

I wonder if there's any value of nicking an idea from later PC developments when you're hitting the timing wall due to needing to keep hitting the RAM to update the VGA out - that is, make the video RAM only accessible to the GPU, and make it responsible for colouring in pixels during h-sync and v-sync windows. You'd need a little shared RAM where the CPU and GPU could cooperatively manage communication of pixel draw commands and pixel testing requests (for collision detection etc.), possibly using some sort of FIFO rolling stack. Later on you could make the language more intelligent by adding block fill commands, blits, lines, polygons etc., but just as a proof of concept it strikes me as a simpler way to get hi-res (if slow) graphics up on screen without having to mess about with timing CPU writes to RAM to not interfere with the GPU reads.

 

[skeezix]

So, a single framebuffer, you mean

ie: I've been meaning to do that in the 'gpu' mcu, and then its the trick of .. gpu is busy, so it has only a small window to receive data; cpu is relatively unbusy, and can update any time.. fast as it can, anyway. So timing problem on gpu reception side.

The trick with the buffer 'sram' or whatever is how to manage its access; you're having 2 devices working it -- one writing (possibly reading), and the other just reading it; they both need to work at different addresses of it, and they both need different read/write modes. So you're talking serious contention on the buffer. (or else its dpram buffer, or some other trick.)

Struck me when mulling this over before, that you're not gaining anything; the big zikzak did this with the dual framebuffer, by doing the big A/B switching mechanism, but I'm trying to way simplify here ..

Or do you know of something that would let two devices to interleave reads/writes really easily?

(I really should go hit up a C64 schematic for a serious read, rather than blundering around in the dark )

jeff

 

[levi]

Hmm, yeah contention on the shared communication ram would be an issue. I was thinking that the CPU could write to it during the scan and the GPU would read it during horizontal or vertical flyback. It's the same problem you have if you have both CPU and GPU hitting the same VRAM, except in that model the CPU stays quiet during the scan and is noisy during flyback, whereas in this model it's quiet during flyback and noisy during scan, which should hopefully get you more time to spit out actions to the communication buffer.


dpram would be lovely, and I'd hoped that since you only need a small amount of RAM for the buffer it'd be doable within budget, but from what you say especially small DPRAM costs too much. Fair enough. Another strategy would be for the GPU to only read from the buffer during vertical flyback. Hence the CPU's got a block of millseconds to blat everything it can think of into the buffer. That would simplify timings, but reduce the amount of work the GPU could do during each frame.


As I say before, the way to get this work for games and things is to embed polygons and sprites and things on the GPU side, so the CPU can just say 'put this sprite here' in a handful of bytes and the GPU will colour in all of those pixels, but as a proof of concept, the coding for the GPU will be simpler if you just stick to two calls -set and test - to begin with.


It works on the C64 and machines of its era mainly because they're not trying to output VGA - only 600x240ish, at 60Hz interlaced. Even then there's a lot of pixel stretching going on by writing out the same colour twice, but only hitting the RAM once. Line doubling was much less common, as then to avoid hitting the RAM twice (as you're doing, I think) you'd need to buffer the line the first time you read it into internal graphic chip RAM, and they didn't have that much RAM back then.

 

[ckblackm]

ckblakm --for the zikzak itself, or the burner?

For the zikzak.