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


joystick was okay; the keyb was the one throwing it off (surprisingly). Essentially, I really can't get away with _anything_ in pin-response interupts, everything has to be done during vblank (which is a reasonable amount of time, but I had hoped to do back and forth protocol stuff then.)

Just having a pin-change interupt like:

ISR(PCINT2_vect) {
  // ps/2 protocol is: http://www.computer-engineering.org/ps2keyboard/

  // no delta/state is needed here; we're only triggered on falling edge of clock
  // ps/2 protocol has clock only when its sending us data (or when we're sending it data,
  // which we don't bother with); as such, when we start getting interupted, we know a
  // piece of data is inbound, just need to collect it up.

  _g_keyb_int = 1;

} // PCINT2_vect
 

That alone causes flicker in the display, thats how bad the VGA is...

So maybe doing _Everything_ via IO chip, and then having _that_ do i2c to the VGA during vblank, would be the way to go; avr to avr should be able to martial things a bit better, than banging on the bus all the time. Send the entire IO bus to IO chip, and i2c commands to/from the VGA chip when its available.

(with z80 as the brains, and having no i2c of serial or anything, means we're on the bus for everything, and that means responding to IOREQ when it wants us too; ti does mean we can WAIT or BUSREQ to hang up the z80 but I'd prefer to avoid it.. I imaigne any chance of animation or the like would go to shit if we're constantly holding up the z80 for the VGA chip. So if the z80 wants to send an OUT 0,c to send a character to the display, the VGA would have to get IOREQ and check the data bus immediately, which I think woudl shake the VGA.)

esp if we want useful audio, keyb, or god knows what :)

hmm.. at my RL work office all day, and no EAgle CAD here to pull up my schematics with. Blast :) Just want to peek and mull over lunch :eek:

Can't think straight until I get this schematic done ;)
 
ckblackm said:
skeezix said:
(who am I kidding, not a single person will ever want a zikzak kit :)

jeff
Click to expand...
That depends on 1) How hard it is to build, and 2) How much it costs. I like kits. :)

Christopher.
Click to expand...
I'm with Christopher on this one. You might be wrong here, skeezix :)
skeezix said:
Just having a pin-change interupt like:

ISR(PCINT2_vect) {

_g_keyb_int = 1;

}

That alone causes flicker in the display, thats how bad the VGA is...
Click to expand...
Wow, really? This ISR can't get any shorter! (I removed comments) Damn, that's timing sensitive stuff. Surprised, that's all.
Much respect for these guys: http://www.linusakesson.net/scene/craft/ You might have seen it already. It was demonstrated at Breakpoint 2008. Granted, they don't go input. There's some smart stuff going on where they use (abuse?) the SPI hardware on the AVR to generate the VGA signals, but the details are beyond me (and I'm not really comfortable reading asm code).
 
Last edited by a moderator:
Perhaps the issue is how the video chip is timing things.  If it's using cycle counting, even if interrupts just add an indirect jump, an assign to memory then a return jump that's a half dozen clicks, and I don't know how C-based interrupt routines get coded to machine code so it may be worse than that.
 
panik said:
ckblackm said:
skeezix said:
(who am I kidding, not a single person will ever want a zikzak kit :)


jeff
Click to expand...
That depends on 1) How hard it is to build, and 2) How much it costs. I like kits. :)


Christopher.
Click to expand...
I'm with Christopher on this one. You might be wrong here, skeezix :)
skeezix said:
Just having a pin-change interupt like:


ISR(PCINT2_vect) {


_g_keyb_int = 1;


}


That alone causes flicker in the display, thats how bad the VGA is...
Click to expand...
Wow, really? This ISR can't get any shorter! (I removed comments) Damn, that's timing sensitive stuff. Surprised, that's all.

Much respect for these guys: http://www.linusakesson.net/scene/craft/ You might have seen it already. It was demonstrated at Breakpoint 2008. Granted, they don't go input. There's some smart stuff going on where they use (abuse?) the SPI hardware on the AVR to generate the VGA signals, but the details are beyond me (and I'm not really comfortable reading asm code).
Click to expand...
Yes, much respect to them .. I mean, waay up in this thread I've posted a few pics and probably some schems.. I can do some limited graphics; you can do about 200x100 or even 320x480 (320x240 say, double lining) .... its tricky, but its doable, in a dedicated single chip thing (ie: using avr with built in RAM, and using that RAM only.) But they did animation and _audio_.. crazy! One fun thing I did was an avr + a RAM chip, and then direct the RAM data line to the VGA DAC, and the avr just ticked the VGA clocks and set address lines on the RAM; so avr had no access to the RAM, but did direct what it was emitting. You coudl use a ROM or eeprom/etc to set the content, and then the thign woudl show it; that was pretty slick. Used another IC too, a buffer, so that you coudl turn on/off the RAM output to DAC, since VGA requires pure black during blanking. But thats also a fairly specific trick, not good for general.

Note that these avr's don't have enough RAM for a framebuffer, so you have to be crazy :)

For _Generated_ artwork its not as bad.. you 'just' have to calculate it on the fly or in batches, and shove those pixels out; they have some clever ideas.. I've just learnt a similar one, from someone else, which got my text mode to draw sharper. (Using uart to emit the character data, instead of pure bitbang, since the uart will implicitly use the right timing, with luck; they're doing it simialrly using SPI IIRC.) 

But the trick is, that I've banged my head against, that VGA is itself demanding a higher speed than the avr can do _at all_; this necessarily limits your resolution, but especially for me since I'm doing it in a more general sense; if your'e doign a very specific thing, you optimize for that, so you can squeeze more work out; but if you're doing a general thing, its harder. ie: Doing a in-flash picture viewer, you can get say 320x240(480) out, since you're just seeking across image data and rendering it flat out. Buit if you're trying to do a general framebuffer in RAM like me, and you've got say 8K of RAM, its rough ;) (320x200 *8bit colour is already 64K.)

So you can't ocmpare what I'm doing and what they did..

Earlier zikzak, the 'big one' I'm fairly proud of, was dual framebuffer with hardware switchign, which was _Awesome_.. smooth and gorgeous, but pretty complex; and I'm steering away from that. So I have done 'pretty badass', without building a VGA card myself from scratchj (which I'm thinking of, btw.. about 25 ICs or so, but doable :p ) That sucker ahd a few RAMs, and switcthed between them with some reasomnably complex switch logic, all in hw.. is teas beautioful smooth animation, made coding easy as pie. But pricey board to make, and hard soldering for everyone. (Really hard board to make, multiple layers and all that.)

The current zikzak, code name zik80, is driven by a Z80 (like 1MHz, or overclocked to say 8 or 10MHz..); and we're using ROM and RAM here, for most of the heavy lifting; talking to other chips. When you're getting the avr mixed it, then talking to an external RAM is two modes.. the 'big chips' can use external RAM directly by chip hardware, but its less than 64K, and ahs some limits.. but works; I'm not using those chips here for various reasons. Or you can bitbang it yourself, but it takes several instructions to do it .. (set out mode, set address bus, set data bus direction, read byte, wait a NOP, continue.)

And with the avr at top speed 20MHz (which they can't all do, the bigger chips _cannot_), you're talking 50ns per opcode; VGA is like 1 pixel per 25ns or thereabouts, so just executing a dingle cycle you lose 2 pixels.

Anyway, I mention that timing info since this -- a ISR context switch itself takes X cycles -- I had it looked up months ago, but sub in 10, 20, 30 cycles.. probablt 17 or something, I forget; so just having an ISR _enter_ burns up say 20-30-40 pixels; then your ISR code handles, and then you context switch back to the mainline where you were before the ISR happens.

Right now for VGA text mode being sharp, in C code (got a lot of battle sot fight at once, so I'm using 'easy mode graphics' now, then working on hardware design and proto, and then go abck and work on asm graphics routines later) .. so to do C code, I have to have all the timing in interupts so its predictable, so anything that interuptds that or gets in the way, totally visible. If your'e doing it in tight asm, its best to just use a loop in asm, and then you count the opcodes to make it use the right timing, and throw NOPs in to kill time as needed; just a big long 400 opcode linear listing, mostly NOPs, to render a page. Not too hard, but tedious, and inflexible to change.

I've got the VGA generator taking orders from the z80 and/or IO chip, so it has to be able to take those instructions; but that protocol is to be defined yet; but I'm planning on having video modes.. at least 2 anyway: test mode, and graphic mode; but more likely iof anyone else gets involved, we'll ahck out a few modes, .. a text mode, and maybe chunky low res graphic moe, like 40x40 giant pixels or something, and then a medium res, like a 200x150 or something, with 4 colours, and maybe a high res mono 320*200*mono or something. Who knows. That can be hacked in later.

For now, need to keep moving.. simple software, keep at the hardware :)

So we're going for general purpose retro styled _computer_, that can do gaming, or shitty audio, or run BASIC etc; not just a specific demo set, which lets you cheat more :)
 
Thanks for that detailed response. It's clear how Zikzak and the Craft demo are different.

BTW: great to see that you seem to have more time for yourself now to do stuff like this after the initial "twin scare" ;)
 
I tend to get free time around 11pm.. So the only time I get is by not sleeping; fortunately the twinpocalypse has me well trained on that count :0


It means I have to be very focussed; if I hit youtube or something, theres my free time gone; watch only specific downloaded shows, no gaming or books or other pursuits; pick one thing, di a hour or two and thats that..


That drives me nuts but it is what it is; someday it'll let up, but then I will miss the kids :)
 
Not had much time in a week, but I've just done a quick update to the zik80 schematic, adding in another mcu as IO chip.

See schematic here in the spoiler tag:

https://raw.github.com/skeezix/zikzak/master/zikzak5-zikz80/images/zik80-003-schem.png

- added another mcu as IO chip

- Removed all function from the VGA mcu, so he can concentrate

- all communications to VGA is via i2c from IO chip; so z80 -> IO -> VGA .. is a little clumsy, but lets us leverage hardware i2c for background processing more (I think, I will experiment.) We can always use serial to talk into VGA mcu, or bitbang something up, we'll see.

- frees up serial quite a bit, so we can use atmega644 or other chip that has a single UART

- The IO chip has everything else.. keyboard, joystick, sound... may be too much for him too, just by limited pin count :)

- IO chip has 1 pin dedicated to emitting clock, fed into Z80; thus we now have mcu controlled clock speed, so we can speed up or slow down Z80, based on.. Z80, or IO.. or host PC, etc. (Host PC can talk over USB/serial to IO, and a console shoudl be there, offering memory dumps, and setting clock speeds and stuff. I think thats pretty awesome, for writing debuggers ;)

     -> may want to hook up a BUSREQ or WAIT type line on IO to Z80, so that IO can essentially hang the Z80 indefinately, while we inspect RAM say....

- IO chip has run out of pins nearly; only about 3 left I think, due to the bus's eating everything up

--> for Audio, right now it ahs only dumb single pin speaker; should should allow (I think?) PCM straight up sample playback (crappily), and for sure will let us drive a buzzer. ie: fart noise. Maybe good enough for our purposes..

..... but I'll mull it over; be cool to have the option of a 4bit or 6bit DAC.. even run a SID emulator (or some sound basic system), and emit decent audio ..

....... could try to free up pins or move audio to VGA (bleh), or mayeb use a shift-register so we can drive the shift-reg with just the 3 pins we have; slows down our audio response, but we may have the spare cycles on the IO chip...

ToDo:

- figure out how we can wire up _BOTH_ colour DAC for vga, and the existing mono .. maybe a Buffer IC inbetween, or a MUXer, so we can switch hookups on the fly? I'm not convinced we can do much useful colour through this whole systrem, but some basic low res colour is certainly doable; might be better to wire it in, and then see if we go all crazy ASM and make it happen later.

----> for now, I'm going with mono text mode, to keep my life simple

- audio DAC, as noted above, maybe with shifter

I've not verified correctness of the Z80 communications bus/interupts, but it looks pretty solid.

So with this design, it may be time to move onto breadboarding.. already have the mono VGA gen you've seen; need to plan layout, and drop second avr on there as IO chip, and get that working talking to PC and i2c to VGA. Once that is all working..
 add the Z80 and get that stuff going; two avr's talking at least makes thigns easier on one hand (I'm good at them, and they can talk to PC etc), but does make it weird .. need another ISP programming port, and flip my USB connection back and forth to program them.. bleh :)

zik80-003-schem.png
 
I ebayed up some ay-3-8912s ..5for$15 isn't bad; I grew up on the y2149 variant in the ST and we all had the 8910 on atRi and arcade machines.


Tempted to order up a 10 pack of SN76489 as well .. 16p instead of 28, but similar interface. Was used by Sega in home and arcade (think Genesis/Megadrive).. 10 for $9 ....


But go for ay-3-8912 first (with parallel out unconnected)


Maybe z80 -> IO avr -> shift register -> sound chip.. Should be doable on remaining pins; then could drive samples direct, or PSG :)
 
I thought the MD used the SMS CPU as its sound chip. All the way up to Mars (I think) they did it this way and it made backwards compatibility much more straightforward.


The SN76489 was designed as the TI-99/4A's sound chip, and also got used in the BBC Micro and various arcade boards of the era.


If you do get one wired up, get it to play a long sound at a given frequency, say 128 and also play a long tone in a second channel at an adjacent frequency, say 129 for a cool effect a number of emulator's can't do right.
 
Maybe take a peek at the mockingboard sound card for AppleII, it's based on those audio chips.

They used two y-3-8910, I guess it was for stereo or the ability to generate more complex sounds.

From what I read on Wikipedia, Ultima V could use two of those cards :p
 
I'll not sweat it :)

I'm not going for 'best machine I can design', as thats an entirely different story. And not 'neatest design ever' either, since then I'd just drop an FPGA down there.

I'm going for 'simple, old school styled, easy to hack with, parts I've mostly got, blundering through experiments as I learn stuff, hey lets use that'; so its sort of a dumb design, and not going over the top; I really shoudl design a 'best I can do' since its not so hard and I've learnt a lot, but I'm still having fun blundering along with this dumb design sequence :) .. and hopefully others may enjoy it too. Get audio at all just so we can screw with it, but not planning on anything fancy. Certainly though keep suggesting, and maybe twist my arm, and maybe I'll bend on the matter :) or maybe I can rough in 2 '8910's and only populate one, or whatever. Its one thing I've woried about is leaving pads in, or sockets, or little mapping pad to pad points so we can adjust which chips are in place on board easily, to make it more hackable. But so far I'm going with a basic z80 design (in the r5 design anyway :) , with a couple other chips thrown in to fake peripherals, but without getting fancy. Its fairly hackable and flexible, but not extremely so.

But please tell me if I'm 'wrong'.. if the design coudl use a few tweaks to be much more hackable, or if its really too dumb, etc..

I have 'nearsightedness', for lack of free time; given only a couple hours a week, it keeps me into a fairly narrow focus :/

jeff
 
Last edited by a moderator:
This project is waaaay beyond my level of understanding :)

You got any idea/sketches on how it will look yet, just the casing i mean?
 
edit: I'm not taking preorders, not until I've got the pcbs sitting in my lap :)

Case isn't on my target yet; for a low run of 1-10 sort of units, I'd just expect a black plastic box with holes cut in it for the ports to go in :) This is a 'for learning and hacking' project, not actually deisgned to be a useful console per se.

Cases are _very_ expensive to make (plastic or metal), but I'm not at the level of readyness to even sweat it yet.

(I do have breadboards (temporary circuits) set up so I can move a dot around with a joystick etc, but I'm still amid the current redesign using the Z80 processor (common in the early 80s), and designing the board layout and all that. (Designing a pcb is a nightmare :p ) I'm still at the stage of proving the components I'm using, and coding up little test cases to isolate each component and make sure it works as I think it does and with everything else, etc etc..

So while I've sunk months of time into hacking around, and am pretty far in some regards, its still very prototypey. (Most avenues I've gone down have been very interesting, but aborted; learned what I wanted, moved on, or decided too expensive for a kit, or whatever.)

So right now expect..

.. I'm working on proving the bits

.. then once its assembled onto a breadboard

.. I'll write up a bunch of test cases for that version, so I can show audio, joystick, keyboard, video, serial, console and clock speeds, etc are working

... then firm up the pcb design

... then get some pcbs made up

... wait a couple months, get pcbs.. then test those, and hope they work (not too bad a bed, given the simplicity of trhe design.. its no pandora :)

--> then we figure out if people want some, and what to do.. cases, components, etc. (ie: if X peopel firm up and send me $$, I can order XX components and bag them up as kits.. or I can just send out a pcb, and people can source their own parts individually, etc, or some mix thereof.) It depends on the kinds of people interested..

If a tonne of people wanted it, I'd just packit up ready to go.. soldering iron, case, step by step assembly instructions in printe dmanual etc, but we're no where near that :)

jeff
 
Last edited by a moderator:
You know, it would be funny to have a retro-styled case, but no way I could afford it; should just convert a VHS cassette or an Atari XEGS or something :p

jeff
 
You must log in or register to reply here.

Similar threads

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