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

[skeezix]

Whats annoying me right now is the SRAM. (Well, right now, and always

The atmega644 I'm generally fond of has 4K RAM. No real space for a framebuffer in there, except maybe mono. 20MHz max (without overclocking..)

The atmega128A/1280 I have some of, feature XMEM so can go up to just-under 64K, but max out at 16MHz.

The atmega 1284 is like a 644, but with 128K flash; no XMEM interface. Might have 16K of SRAM if memory serves. 20MHz cap.

So more or less, the newer chips, or at least the ones with XMEM interface (and a higher pincount, like 64 or 100 pins), are all 16MHz; I looked 6mo or a year back, but that was generally the case.. more pins meant XMEM, but less max speed.

So I'd really liek the XMEM interface here, so I could get 32K or 64K, but 16MHz (say, a 15MHz crystal..) isn't really enough; some of these timings are 2.2uS, and at 20MHz you get 1cycle for .5uS .. so you can do NOP/NOP to burn 1uS; doing 2.2uS is quite doable with a few opcodes.

But at say 15MHz, you're getting .75uS per cycle .. 2 NOPs is 1.5uS; 3 is going to be 2.25 say, which is pretty good, but you can see the problem.. it starts to get hard and these timings have to be tight.

I keep bumping my head on this, pretty annoying. (okay, could go to 10MHz as well, but still.)

Anyway, just stream of consiousness logging my thoughts as I go, in this thread..

jeff

edit: Oh hell, I'll just try with a 10MHz crystal and see if I can make it work; the gpio pins are limited to 10MHz anyway, but 20MHz is much more flexible especially given the timing urgency here.

Alternative is.. I have those propeller goofy chips on hand, could make that work; 32K RAM and can do VGA pretty handily, but not a product I want to learn too much about

 

[levi]

I really suspect you're biting off more than can be done with such hardware here. Granted, clocks are five, ten times faster than early 80's machines (I'll assume instruction sets are equal here, since I know nothing about ATMega ISAs).


But you're trying to (or were, I may be out of date) squeeze 24-bit colour out of it, and 480-odd lines of it too. Old computers worked on interlaced, so that's half the number of lines every 60th, and a palette of a few colours. On my old BBC micro workhorse you had (at max bandwidth) a choice of 16 colour by 160 pixels across, 4 colour by 320 pixels or 2 colour by 640 pixels. That's 80 bytes a line - assuming the same bandwidth at three bytes per pixel you're limited to 25 pixels across or so - if you were still painting 240 lines. But you're not, so on the same vintage hardware you'd be hitting limits at about 13 pixels.


That's your starting point, I suspect. Now, memory access rates won't have stood still here - the BBC memory ran at 1MHz. So divide how many bytes you can read a second by a million then times by 13. ISTR that the BBC Micro's successor, the Archimedes had memory that clocked at 8Mhz, like the CPU but random access took many cycles (3 or 5 I think) - although I think there was a trick you could so with sequential paged memory. Still, they managed to up the bandwidth to 16 colour by 640 by 240 lines there, which'd be about 50 pixels full colour progressive. For the next generation of core hardware, the Risc PC they went DPRAM for the portion of the memory map where you could direct the video hardware at, and they finally achieved 24-bit colour VGA IIRC, although by then CPU speeds were 20Mhz, and the machines cost over a grand, so it's a different league of tech from what you're trying to do.

 

[skeezix]

Ideally I do my own dedicated VGA circuit, using a bunch of counters to keep a rock solid sync, etc. But thats a lot of work Later baby

I have _actually_ pulled off on the order of 250x240 using a 20MHz atmega644 .. so its not just a fools errand; the trick as I say is getting the data in there as well I mean, I'm not just being stupid here (not _just_ being stupid , I've actually pulled this off to some extent (though that was just alternating colour blocks, not indexing memory.) And I'm also trying to do it in C, which is sort of dumb, but I'm bullheaded that way .. be neat if I could pull it off. (The interupt handling method is working pretty well to keep timing tight, and I'm quite surprised.. the interupt overhead itself burns a lot of pixel time..) -- but cutting over to straight asm shoudl do it pretty well. I just stink at avr asm Too many things ot bite off at once. But in straight C, I've done 640x240 with colour bars, and I've done 256x240 colour blocks.

So _assuming_ you have the data in the avr, you _can_ blast it out pretty good. And during vblank there is some good time to screw around with data exchange. (This is all just a stop gap, but be satisfying to work; I mean.. if there is a well defined pipe from whatever computer to the 'gpu circuitry', then can swap in better as time permits. Especially if its sending sprite-lists over or something abstract like that.)

(Problems with the atmega644 is the 4K RAM, so no real storage there, unless you may do a monochrome bitmap; I have been considering flashing a font into the flash on the avr, and then using a character based array for now, like a dumb terminal; would fit in there..); my build of avr-gcc doesn't have the atmega1284 which has 16K (and I have a couple of them) so I need to build a new one, but its (for some reason) a problematic build right now, so not going down that rabbit hole. So using a 644, I have some code that can more or less do a pretty good res, with no frills. Mixing in some frills should cut me down a bit, but I'm sort of betting I can hit 160x240 or 160x120, which is pretty respectible for the limited amount of time I'm sinking into it.

If only I had more time! an hour here or there is just enough to fiddle a touch withotu gtting far, and I sit stewing all day with ideas in my head, but you have to assemble the circuit, do the code, and fire it up and hit the o-scope to see whats going on :/

This is also why I've thought about going with the propeller .. I've got a couple, and they have a bit of video helper circuitry in there; but its a _Really_ goofy environment so I don't want to go into it much/at-all I think, but it does work; last resort. (well, last resort is buying some VGA out chip or board, but thats waaaaay cheating!)

So I'm going to beat this to death a bit more, see if I can pull it off.

Otherwise, back to the drawing board, or just go serial-usb for now. But VGA is more fun

Well, I could go back to NTSC/PAL, as I did do some code there, but it hurt my brain. As I do all this at 1am or so, working out the NTSC math got old, fast ;(

jeff

 

[skeezix]

Arrgh, looks like the memory fetch is using up too much time .. I didn't work it out right before.

So right off, just doing the memory fetch and pushing the value out, you're burning up like 5 cycles .. (actually, I think Id id work that out back on like page 3 or something )

At best I can get about 60-80 pixels across, then; if you do 8pixel wide font, you could get what .. 7-10 characters across; like half a vic-20 Its just not worth it.. so I think you are right, doing _colour_ is not practical. (Well, maybe could use one of the other devices, like the UART, to feed the graphcis line, but thats hurting my brain at this late hour.) The UARt has a double-speed mode even..

So I guess at best, would be able to do a mono display driven by atmega; that'd get a higher res (hopefully, unless all the masking/shifting kills it) and solves the RAM issue.

I'll have to look into that; at least, right now, I have a nice red screen showing! :/ another night shot

Of course, could just wimp out and pick up a uVGA board for $50, that gets you serial draw access (with API) to a framebuffer, and a nice full VGA out. But not practical for a kit, but an easy way out for debugging anyway

Let me work on the monochrome angle..

jeff

 

[levi]

Erk, you're doing all this timing stuff in an optimisable language? Erk again!


As I say, it's worth working out what your max sequential memory bandwidth is. Knowing when to pulse H and V is pretty important, but not if you've not got enough time to fill it with actual video data.


As a first port of call I'd look up the LDx instructions and see how many ticks they take to complete, although I dunno if you'll find different counts for sequential and random there (if that even applies to AVRs, not a clue). Ultimately you'll need to code up a little simplistic assembler, I guess - and helpfully you've got a handy timing tool in your video out circuitry.


Have you thought about dipping your toe in the grown-up processor side of things for the video chip? Pick your preferred machine code, and you can knock up a kick-ass video chip running on nothing but instruction timings. I'd hope that's achievable in a sequence of hour-long stretches - the code's pretty short, it just loops a lot.

 

[skeezix]

Once you go to more modern processors, it seems like cheating; hell, I could plop down a Pandora board and use that for video if I wanted to Ultimately, pulsing out the VGA is _Trivial_ (its an astoundingly simple protocol), so the only real challenge is the ones I'm baking in myself .. using low end processors never designed for this.

Historically I've also tried limiting how many different technologies I want to tackle at once, otherwise I'd end up going into FPGAs or something (VHDL could be fun who knows, but no sure what costs are involved.. I'm broke right now

The XMEGA line from atmel is slightly tempting; 32MHz but the same SRAM limitationts (4k-16k I think), but they do include USB drivers and some of them have LCD controllers; never looked... its possible the LCD controllers have some framebuffer or timing logic whichi might be helpful, without 'going too modern.'

Theres the freescale Coldfire type stuff as well; 68000 derived so still touches me in that 'old time' way, but beefed up; I've not followed the specs, but some of those bad boys run at 200MHz or more.

But a lot of these more modern guys come in nasty packages (100 or more pins), or cost a pile; I've not looked too much, but the mid-end Coldfires and even many of the ARM chips are $30 or $40 a pop.

---> perhjaps its time to spend some time shoipping around for options though.. I've kept a tight leash ("cheating") on my design options, to keep it easy and challenging and fun at once, but widenign the noose makes for a lot of options. Let me know if you have any ideas for somethign thats a step up, but not rediculous.

jeff

okay, even Atmel makes some cheap ARM chips ... that run Linux! $16 for this guy:

http://www.digikey.ca/product-detail/en/ATSAMA5D31A-CU/ATSAMA5D31A-CU-ND/3911016

But I mean, who want sto play with 300+pin ICs

 

[skeezix]

That all said.. with the super low end stuff I've been playing with --

I _can_ do a full 20 or so character display (like a vic-20), on VGA, readably; monochrome, colour A on colour B. I _can_ simulate a green on black old school display just fine.

If I use the goofy parallax propeller chip, I can also get high res text.. its goofy, but it does have 32 shared and 2K per 'cog', with 8 cog processors in one $5 chip. Could set up one cog to talk to a bus, and 2-3 cogs can drive the VGA very nicely. It can do graphics as well, it has just enough performance to pull off some 320x200 or the like, but I've not looked much into it.. but I've proven it can do text quite nicely.

So the question is .. what do I need to do?

My primary goal has really just been to learn stuff, with a back pocket goal of actually building a bord so its solid.. so I can plug it in and it'll do 'something', someday, and give me a smile. A text terminal on VGA, running BASIC or something, is pretty cute; be nice if it coudl do some basic graphics.

Personally, I do _not_ expect to actually run a TCP stack on there for a server, or write any real graphics demos or the like; I'll write a space invader game, a bouncing bar demo, and call it a day.

But if _anyone else_ wants to assemble one, and theres been a few bites (and maybe more if I make a nice website up and push it a bit), then it'd be nice if it could do a few things. (Really, its such a simple rudimentary design, that what you want is what you build in.. add serial, or graphcis, or whatever, not too bad; adding it all at once is more of a 'real project', but not sure I want to go there; if I have the time, adding cart port, keyboard, etc woudl be pretty cool.. a full computer.. but that'd take me a year or more to get through, given the time constraints I seem to have right now.

So where am I, or we?, going with this?

And cheap, gotta keep it cheap; if its cheap, a kit becomies much more feasible to many more peoplke; no one minds dropping $30 or $40 on something for fun, but if its $100, .. you cut your audience way down; also, I'm feeding a lo tof mouths on one income, so gotta keep it cheap anyway.

jeff

 

[levi]

Sorry, seems like we were typing at the same time. Good to see that you've double checked your maths.


When I said grown-up processors, I was thinking more Z80 or 68k or something like that. Although I don't know if you can get them up to the requisite clock speeds. Just something designed to be used with an external RAM bank.


Also, perahps not using a CPU at all is the way to go. Five cycles? Should be possible to drive the RAM harder than that given you're only changing a few address bits most of the time between reads. Heh, you could even store your VRAM in gray encoding


Ah, ideas ideas. So easy when you're sitting on the sofa not trying anything out. And I know you've already got enough ideas and not enough testing time, so I'm almost certainly not helping here.

 

[skeezix]

The z80 side is fun .. rather than dismantle too many of my existing boards (mostly working arcade boards..), I bought a few 'new' Z80s; they can clock up pretty high, rated up to 10, 20, maybe 30 MHz; but for peripherals, I do have some leftover 6800 ACIA and sundry parts, from some scavenging (many) years ago; those parts are rated in the 800KHz-1MHz range, since they're the real old goods.

I may have to get an adder for my clock to drive, so that I can do a big divider to drive the serial-usb ACIA, but I need to go over those datasheets in some serious detail

Now, there is the Z180 line, which is like a Z80, but with a bunch of 'optional' peripherals thrown in; ie: it acts exactly like a Z80, except when you want to turn on the new bits. So if you want to use a UART instead of an external SIO/PIO, it has one. MMU up to 1MB (!), 'serial I/O port', dual high speed UARTs, .. oh, looks up to 33MHz. Pretty badass But you do still need to add a ROM, RAM and the decoders and so forth to drive it. If you're really on your game, use (say) a 40MHz clock and send 2 pulses to one side, and 2 to the other, and interleave the RAM access that way shoudl likely work for shared RAM too.

There are very nearly _too many_ options

jeff

 

[skeezix]

Here is a pic of the current text mode I can get out of atmega644; approx 20-22 characters wide (like a Vic-20), mono text. (Sorry about the tile-lines, used to help align stuff and do vertical testing).

I can do this in straight C (very carefully done so the asm dump is quite specific and timing accurate), or in asm (embedding gnu-as into gcc C is sort of annoying, but I'm not great at it either )

I picked up a few tips from some other project I just found; I'd been discounting interupts for most of my 'gpu' hacking, since the interupt overhead is itself quite a few pixels; but if you do it at the right times, it works out pretty well and definately simplifies the timing, to get nicer straight lines. I tend to get some wavey lines.. (notice that the branch opcodes can use 1 or 2 cycles, depending on which branch is taken; I often fook that up, and get some waves

Now, this piece of code can be modified to pick up text into text buffer from..

- i2c

- bitbanged clock/date type serial

- serial if got a spare UART (atmega644p has 2 uarts, for example)

- whatever

Theres a few spare cycles, especially at vblank time, to pull data; for text, you generally arent' scrolling like mad; if it is spamming, it'll be lossy .. unless I had some CTS/RTS type flags, but *bleh*

This is why I've been banging at it, trying to get a few more bits of resolution; this is already _pretty workable_, right?

Check it .. 160x240 VGA bitmapped, but using a text buffer and flashed ROM font (since only 4k RAM on this guy):

 

[dgame]

Nice! Been following this thread from the beginning. Very interesting.

 

[levi]

Very nice! That's certainly workable for text mode stuff. Not idea for playing games (although plenty of kids back in the 80s ran their Spectrum's on their parents' old B&W TV) but you just need to make it slurp data twice as fast and you can have two extra colours, which'd be perfectly servicable for simple stuff.

 

[skeezix]

yeah I think I'll run with this for now, skip to the next side of things I'll have to work on serial commands and so on, but thats easy stuff.

I've looked into PS/2 keyboards, and turns out they're serial by default; ie: clock + data, thats it. Piece of cake!

Right now then I need serial -> GPU, and now keyboard seiral into cpu; thats TX and RX accounted for! So if I use a real z80, and throw on an ACIA, I'll have serial okay; I could cheat a little and use the z8s180 and have a UART right in the z80 .. I have some ACIAs, but sourcing them is challenging and expensive. (Check ebay, theyu go from $5-$100 !)

So we suddenly hit the wall of --

Am I designing for me, or for kit?

ie: for me .. go with real z80, make my life harder, but interesting

for kit .. go with a z180 -- readily available, cheap, higher speed, more features, less complex board by a couple chips. *hmm*

Design is coming together!

One thing I've barely looked into is cartridge slot; I think I need to break open an Atari 2600 schematic and wallpaper my office with it

jeff

 

[sswam]

when do you start accepting pre-orders?  

edit:

Spoiler

I never have really understood perl "pack", but this seems to work:

# perl -e 'print pack "H*", "74776F206D6F6E746873"'

two months

 

[skeezix]

Too easy; so, in code then:

ASCII Bytes: x" 74776F206D6F6E746873 "

EBCDIC Bytes: x" A3A69640949695A388A2 "

jeff

 

[levi]

I thought with most consoles you just wire up the cart port to all the lines you're currently connecting to RAM (or perhaps a few more if you've only got 1024b of RAM like on the VCS) but wire up an extra bit at the MSB end to issue reads to either the masked ROM in the cart or to your RAM. So when you set up the address lines you end up setting the lines to both RAM and cart ROM, and setting this top bit to prime a few logic gates, then you raise the read line (or whatever) and those gates either raise read on RAM or the cart ROM.

 

[skeezix]

yeah, that too is my assumption more or less; the cart takes over system ROM. I'm sure I have a wall-size Vic-20 or 2600 schematic around somewhere though, and it is sort of cool  to pull out once in awhile (I've got a small stack of arcade schems, but they're purpose built and less fun; mind, they do have video logic in discrete cirtcuitry..)

But I wonder if there is some overlay .. if the cart takes over a slice of ROM, and the remaining OS ROM perhaps has a cart check (cart slides in, grounding a pin or something, to show it is in place), enabling some function, and then jumping into the cart blindly (or in modern days, checksumming its boot loader or something )  ie: Does the OS ROM offer some standard API functions out down to the cart, or a jump table or something.

In my case I thought maybe a gate on the high address pin that is ANDed with a cart-present pin; when the AND goes true, it chip-selects off the OS ROM and chip-enables the cart ROM. Shouldn't be too hard to put that in. (Getting ahead of myself, I barely have RAM/ROM decoding at all right now, but hey, getting ahead of myself is fun

jeff

 

[levi]

No, with what I'm proposing the cart occupies extra space in your memory map.


Say, you have it wired such that addresses 0x1xx go to cart and 0x0xx go to system RAM. 0x0FF is the last byte of system RAM and 0x100 the first of cart ROM.

 

[skeezix]

yeah I get that.. "if the cart takes over a slice of ROM"; in my late night delerium, I am probably not at all clear, and meandering all over the place; I should be more precise

I'm really wanting to dive into the schematics of this, but just haven't had much of that time lately; hopefully tomorrow and over the weekend I can start to get this down, and start to get some concrete numbers in there for the memory map. I need to pour over datasheets and mull over.. memory mapped I/O versus In/Out port I/O and so on, to allow for some future expansion options (ie: if we end up with a pcb, which I hope, then you need to plan in the expansion options; I normally just breadboard and perfboard, so don't have to worry about that much.)

...

Something I've not thought at all about is audio; just another few pins and an r2r ladder really, for a basic squeeker. Or maybe a FM generator chip, to get sawtooth or sinewaves or the like? Sounds like work to me (and I never cared about audio that much.) Hmrf. For a kit, though, you might expect it to be able to make a fart noise when your ship gets shot or something..

Using a z80 really puts it to the point though.. no GPIO pins; having 32+ GPIO make life easy in a lot of ways.

Still debating Z180 or real Z80; I have some Z80s, and some old parts like the ancient 800KHz ACIA's, but they're possibly hard and or expensive to locate; so dropping ACIA may be cool for kit-sake (more than the 2 I have already, anyway); going to Z180 is same as Z80 but with some more pins (for built in dual UARTs, among other stuff.) This would simplify design, if I go with UART serial -> VGA generator (fine for text and sprite control, but too slow for full screen bitmapped graphics..), dropping the ACIA and some other funny business. (No need to worry about using a counter as a clock-divider to drop down speed for ACIA, say.) Also, Z80s typically limited to 1MHz, or even 8MHz; the newer ones may be higher, but older ones certainly limited to 1MHz or so. The Z180's come in 10, 20, 33 type max speeds, and care cheap (I forget, $5 or $7 a piece in low quantity.)

So although I've been planning for some time a true Z80, I'm sort of leaning (today) towards a Z180 .. same essential function (it is binary compatible with Z80, runs all the old software), but has some bonus features (built in MMU for up to 1MB etc.)

Hmmmm.

jeff

So.. anyone care about audio, or do I drop it?

 

[levi]

Hmm, passable audio would be nice if one of the uses for this is going to be games. Square wave would be a start, and IIRC a little bit beyond what the Spectrum could do.


I've just had a dig for something similar to the AY-3-8310 (but preferably without such bonkers bus requirements), but it would seem that history has felt no need for that particular niche (or my google-fu is lacking).


As for real Z80 versus less-real Z180, I vote the latter. The idea is to make an 80s style computer, but using modern bits, right? So using old bits is cheating.