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


I'd actually picked up some LM386 samples (I love TI!) just for this purpose; didn't realize they had a circuit in the datasheet :) (the DS I've been using is cleaner but less complete.)

Thanks for the tip -- they don't even bother with a ladder, just plug it right into the amp. Slick. For a quick test then I just jumpered across and joined channels.. works fine. Didn't leave it like that.. just feels like theres got to be some contention, feedback in when the analog are out .. feels like it needs a diode or something to protect it. But that just a 30s test on the usual no sleep, so I'm off to bed now :)

Back to VGA hacking; such a simple protocol, but I've tried way too many different approaches. Only a matter of time until I build my own video card from discrete components :)

jeff
 
Last edited by a moderator:
I already have my three AS1130, AMS was really fast to deliver the samples. So I just ordered a few 28 pin SOP/SSOP to DIP adapters.

I may order some of their Hall sensor chips and joystick/magnet pairs…

But right now, let's focus on the AS1130 and one of their noise cancelling chip (if I ever start making that wired remote for pandora I dream about, it would be awesome to have a noise cancelling system in it).

I also bought five AY-3-8910A, since from what's been said, it's simple to setup an use.

I have some LM328 samples, so it should be easy to setup on a breadboard. :D
 
OKay, we need to all share notes on where to get samples, and cool things to get ;)

TI is great for all sorts of things; order a sample, and it ships hours later, right out of digikey I think.

STM will do samples as well, through some suppliers.

AMS will apparently do some; what are their best samples to get? :0 .. the AS1130 looks pretty nifty, but I best resist :)

.. any others? :)

*mooching*

jeff

The AY-3-8910A is _TRIVIAL_ to get going; I've put in some lame duck code into my zikzak git repo, half of which was swiped from another dude, who swiped it form somewhere else, etc :) Still, I hooked up avr8 to AY-3-8910, with just what, 11 wires (8 for bus, 3 for control, plus power) and worked easily. I got 5 of the AY-3-8912 (fewer pins, same chip; theres a couple unused ports on the bigger one.) on ebay for a couple bucks each or something, ended up being Microchip 1988 ones.

... good news for me/zikzak anyway -- figured out the basic circuit for STM32 F2 (what to power to bring it alive, doing nothing); I've managed to get a toolchain going and some libraries, and have gotten a blinking LED going! Doesn't sound like much, but with these ARM chips its a fair amount of work. With an avr, its .. put 2 caps and the power pins, and the chip is alive; put the 4 ISP lines (MOSI, MISO, SCK, Reset) on, and you can program it. With the STM32 F2 the documentation is so vast (thousands of pages, plus all the generic ARM stuff) its sort of hard to tell what you need and what you don't. Likewise for toolchains.. so many options, mostly commervial ware or broken FLOSS, its hard to know. etc and so on ..

.. but turns out not so bad, at the basic level of understanding I have acquired so far. 5 Vdd's, 3 GNDs, and the chip will come alive. No need for fancy bootloaders, can just flash code into it, and it'll still go. 4 lines for the ISP (JTAG), though the ISP itself needs another 5 or so Vcc's and a couple grounds.

Coding for bare metal ARM Cortex-M3 is a bit of a nightmare too, what with chip families, tempalter header files from ARM, and chip specific versions of those headers, big over-architected mess .. hard to penetrate.

Still, got blinking LED (hello world equivilent) going, which is pretty exciting.

These chips are so freakishly powerful .. so many peripherals, so many options .. pretty astounding. I do love the simplicity of the avr8's, but future projects.. if I need performance or features, these may be my go-to guys.

Anyway, need to figure out timers on these guys, and start porting over my VGA code :)
 
skeezix said:
AMS will apparently do some; what are their best samples to get?
Click to expand...
Most of their led driver chips look really nice.Be careful when ordering they have two version of some of their chips for the same package. One version works at CMOS level logic, while the other works at "mobile" level logic ( High ≥ 1.6V, I don't know max voltage).

They also let you sample their Hall sensors chips and the magnets to work with. Don't really know about the rest of their devices.

skeezix said:
OKay, we need to all share notes on where to get samples, and cool things to get
Click to expand...
I'm currently trying to get some samples from ATMEL (some MCU and 2-wire EEPROM), it's "pending approval".EDIT: Nope, seems like sampling from Atmel isn't an option. They invited me to buy the parts because they don't want to give them for free :p

Microchip allow some sampling IIRC.

EDIT: Can't find how to order samples on Microchip's website…

EDIT: not straightforward method, you need to know the part n° you want, then you can order your sample. You can only order two kind of chips by sample order.

Zilog do too, got some modern Z80 from them.

Maxim give out samples. You can even ask them for more than 3 chips, but it'll have to be approved.

skeezix said:
TI is great for all sorts of things; order a sample, and it ships hours later, right out of digikey I think.
Click to expand...
In Europe, some parts are shipped from Netherlands, others directly from Texas :D
 
Last edited by a moderator:
Ordered a pack of samples from TI, STM, Zilog .. TI's arriving overnight. So awesome :) STM is via USPS, and Zilog is still considering it.

Got some op-amps and amps from TI which may go right into the zikzak audio, not sure. ie: Include SDIO on the board, or leave it as an exercise for the hacker (not hard, just solder 4+2 wires..), and likewise for audio amp; leave it off, or add in an amp and away you go. (For me, I just wrapped wire from ay-3-8910 around 3.5mm jack on computer desktop speakers, and it worked fine.. speakers have an amp.)

Spent the last few days banging my head on data sheets (a lot of them) and bugging folks in a couple forums and mailing lists, ultimately to find out the problem I was having is just a side effect of the ARM design on this chip. Blast! (spurious interupt invocations .. solution .. make my interupt handler _longer_ by a couple NOPs, and all is well. More datasheet diving needed, but blast..)

So I think I've got almost all I need to figure out, figured out, to start working on the VGA driver for STM32 at 120MHz :) Mmmm... Sort of cheating, but its just the video handler, so its okay.

jeff
 
Are ARM MCU that hard to get started with?

(Do they need lot of components to get running? Did you have to use a specific programmer?)

With a 120MHz chip, I bet it'll be fast enough to get a stable VGA signal out of it. (IIRC VGA clocks around 25MHz)

I think that only a few changes will be needed to get a component RGB output. The two differences are the horizontal refresh rate (~31kHz for VGA, ~15kHz for component RGB) and how the sync signals are made.

I tried to find out how some old computers and consoles generate video signal. Most of the time a proprietary chip produce R, G, B & sync signals, then use various off-the-shelves chips to translate them to composite PAL/NTSC or (for the oldest) UHF/VHF signal.
 
The ARM cortex m3 I'm using - stm32f205re - is a 64 pin lqfp package; I pretty much went for highest performer in 64pin or less package withbeasy hookups and 3.3V.. Most more modern chips are 144pin or some crazy BGA ..


These guys are astoundingly powerful and actually pretty easy to grt going .. Just like an avr but more wires. The one here is something like 7 or so Vcc's and a couple gnd's; no crystal needed but I couldn't get stable 100Mhz or more without one .. So crystal and a couple caps and thats it!


I'm using official programmer, but you can get the $7.99 demonboard which includes a built in programmer than in turn can program off-board chip, so pretty cheap.


Once your make the dip adapter its easy to bring up.


Harder is figuring out your toolchain and getting your head around things.. So mich documentation and a weird split between official ARM api and the manuf api..


Ie; turns out CMsIS is a standard ARM makes .. A enormous pile of structs and standard register names/addresses; you can code to that.


Or next level up is 'standard library' type HAL, which are lowest level peripheral wrapper functions named after cmsis entries. Very basic but a bit easier .. Set up a struct, feed it to helper function.


The next level up is IDE's and toolchains, each with custom libs. Keil etc. some of these support ARM cortex-M3 but not the f2 line of chips (but do support f1, f3, f4 maddendingly. And of course gcc .. A half dozen unsupported variants and a new arm supported one.


Then programmer software for linux .. Stlink OSS doesnt support my chip; again most people use eval and demo boards and never go to bare metal .. Odd.


Openocd can flash my chip and also act as jtag<-> gdb bridge (amazing)


So before you write a line of code you're figuring out what library level to code at and finding a toolchain supporting your libraries and chipset; also you need to learn anout jtag taps and gdb bridges and openocd and all that junk .. Before you can donhello-blinky first app.


Its a challenge .. The attack surface is much larger and much less defined .. Googling doesn't help much.


The hello blinky app is a little more complex than an avr8 which just works; these chips are fully optional for every piece due to power consumption so before a gpioncan work you need to learn to turn a gpio clock on, and to do that you need to figure out thatyour gpio pins are on multiple busses so which one do you turn on?


I just wasn't aware of that granularity at all; not hard to fond out, but just one of 20 concepts to grok before you get anywhere.


If you look st just commited vgatest.c in my git you'll see it all looks pretty familiar and easy .. But getting there took awhile. Twiddlong registers to ser PLL and all was weird (and no idea how tondebug ..) butnthen I found some libs to make life easier.


Need to fond an m3 emulator to make my life easier :)but now after just a few days I've got gdb ttalking to the chip .. Can just ctrl-c and set breakpoints etc - quite amazing - and can do all the gpio I need.


Vgatest.c has vsync implemented in about half an hours work; if babies sleep I'll plop in base hsync and some show-all-red or grid code and see if I can bring vga up! So you can see .. Went from no congidence and pain knto operaying okay in just a few days


So its weird, but not too bad. At least physical wiring is easy!


Be mindful .. 3V, don't blow em up with 5V :)


You can get F4 (similar but faster, and 144+ pincount)! On free sample from sT .. 180MHz!! I've just got some .. But making thatbadaptor is hell so another week.

Any chip you know to convert rgb to composite?


I wrote some mono and colour composite generator and its pretty challenging .. Much uglier than vga.


C64 etc used Vic chip to do it .. Custom stuff


Jeff
 
Speaking before I've proven anything, but hey..

In theory, the 120MHz should be plenty enough to work VGA out, even in C (trying it now.) Worst case fall back to assembly, whatever. Anyway, in theory it shoudl be doable to support a full 800x600, or some variation; at least 640x480 should be doable. If things get tight, theres doubling.. 640x240 doubled to be 640x480, that sort.

Anyway, the limiting factor in the chip I have STM32F205RE is 128K of RAM: http://www.digikey.com/product-detail/en/STM32F205RET6/497-11155-ND/2640801

So if you do 320x200 with 1byte-per-cell (ie: RRGGGBBB or RRGGBBII, something like that), you're eating up 64K per framebuffer. You need a bit of operating RAM, and be nice to have double buffering (but not strictly required.)

So obviously we have 'modes' needed; a text-mode that has a small buffer (80x40 or whatever) for text, and low res double buffered bitmap colour, higher res single buffered colour, high res double buffered mono, etc. Obviously peopel could code up their own strategies, but I'm rather thinking it'd be nice to have double buffered low res colour, with some basic sprite options too.

So maybe something like 240x240 first off or something, so theres some RAM left over. If you do somethign liek you can shove uip 16x16 sprites (256b each sprite) to the 'GPU', and save a few K, you could have a dozen little sprites floating around.

So despite having enough performance to pull off high res, may not be able to do it all the time, due to RAM. I had figured that .. once I get some simple code in palce can do some timing games, but the question from a few weeks back is.. if we drop in an ARM chip with higher peformance, is it 'just' a GPU so that it is conceptually a black box (not cheating), or do we dump it in and have it be the I/O chip as well (joystick, keyboard, SDIO, etc.) In _that_ case, its nice ot have some performance left over so when someone hits a key, it doesn't interupt and distort your display like on the avr8 ..

I'm inclined (because its fun!) to have z80 brain, avr8 I/O chip, and stm32 as GPU. Keep design simple and 'compartmentalized', though drives price up a bit (bigger board, extra few chips). Still, rule #37.. this is not the best design, nor the cheapest, nor the fasest, .. but will be fun :)

jeff
 
okay right off, with just a couple hours of hacking around (including wiring stuff up), I've got a pretty stable 180x600 in straight C; and this is really lame-duck C, just to make it draw a grid. (We don't get the full 120Mhz on the gpio lines, I think they can go no more than say 60k or 30k times a second, which is 'just enough' for our needs, and leaves some cpu left over.)

#if 1 // vertical stripes of 20px                                                                                                                                                              
  unsigned int i = 180;
  unsigned int r = 1;
  while ( i-- ) {
    if ( i % 20 == 0 ) {
      r ^= 1;
      red_go_level ( r );
    }
    __asm__("nop");
  }
  red_go_level ( 0x00 ); // full off                                                                                                                                                    
#endif
 

Hey now, I should go Exo or notaz to write up some sick-as-shit ARM asm for this, get the cycle count right low :)

Quick hack to make it pull from a framebuffer (array) is trivial too; in straight naive C code, you get just a few less horizontal pixels due to the function call.

Now, going to asm and being anal will speed it up quite a bit; can use peripherls to run the data too.. spit it out using DMA, or USART, or whatever so that is _automatic_ could be awesome as well. (ie: feed the uart a buffer, since we're using 8bit pixel packing.. just give it a 'string' that is the entire line of pixels, and configure the UART output rate to be the speed we need and voila). Etc. A lot of options.

But it works with a 10 line C function :)

jeff
 
skeezix said:
Any chip you know to convert rgb to composite?
Click to expand...
From what I've found, the AD725 chip is able to spit out composite and S-Video signals, NTSC or PAL. It just need to be fed the right clock signal depending if you need PAL or NTSC signal.
About the ARM programmer, I suppose that this device would do the trick : http://www.ebay.com/itm/ULINK2-USB-JTAG-Emulator-support-MDK4-54-ARM7-Cortex-Keil-Ulink-II-Debug-Adapter-/321265477065

Well, I'll probably try to get started with ARM MCU later, since I still have quite a few project to finish before starting yet another one…

I frequently learn new things that can improve either my code or my circuitry. But every time I do, I mostly have to start back from scratch :D
 
Last edited by a moderator:
skeezix said:
The ARM cortex m3 I'm using - stm32f205re - is a 64 pin lqfp package; I pretty much went for highest performer in 64pin or less package withbeasy hookups and 3.3V.. Most more modern chips are 144pin or some crazy BGA ..

[...]

You can get F4 (similar but faster, and 144+ pincount)! On free sample from sT .. 180MHz!! I've just got some .. But making thatbadaptor is hell so another week.
Click to expand...
The STM32F405RG is an F4 with 64 pins, 186MHz, 192K SRAM, 1MB Flash. See appnote AN3364 for pin compatibility (quick glance: looks good).

There's also the 64 pins STM32F401RC, but that runs on 84MHz, and has (much) less memory.
 
Oh crap, I did not see that one when I ran down the list. How did I miss it?

Damn , fedex is starting to love me ...

jeff

edit: how to explain to the wife.. 'listen hon, the guys in the forum, they're performing a denial of service attack against my wallet'
 
Last edited by a moderator:
Looks like you can hook up a DMA to GPIO okay, which makes for data transfers using nil cpu time, and apparently twice as fast as a regular naive memory copy ... Should take care of high speed vga output nicely :)
 
Did some tweaking, and with this 120MHz STM32..

Plain boring C, unrolled main render loop, but no DMA or fancy features being used yet.

--> 180 x 600 resolution with full RGB (well, RRGGBB so far anyway)

Going to DMA is hard to predict, but from what documentation and peoples anecdotal evidence suggest, should be able to get 320 or 360 or more horizontal, and this is straight C without any real optimization yet. We'll see on this point though.

Still, I'm quite happy that we can achieve nearly 200x600 with crystal sharp rendering, in C thats just a days hacking. Right now I'm doing double buffering 240x240 framebuffer and eratrs up a lot of the RAM, but with single framebuffer could do the full resolution. If I get the bigger chip, would have another pile of RAM to work with.

Anyway, experimentation going well; another week of screwing around here to see if I can get it better, and then go back to the design to start fleshign it out.. I think the stm32F_ is proven as a pretty good option for the board. I'm not going to optimize anythign here at the prototype stage, just proving stuff works.

I'd like to get some DMA going in prototype at least, since then can measure how much CPU time is free (right now CPU is pretty busy doing it all itself, but if you use DMA you free up the CPU and let the hardware do the work for you), so I know if we can connect anythign mto the chip; but may be 'safe' to just not load it with anything, leave any cpu time for say sprites or other handling we may like to do, later.

Design phase is rejigger the schematic to fit this new chip in, and sort out how in fact we will send data _to_ it.. without blowing up the whole crystal sharp display aspect of it all :) But if DMA is doing the heavy lifting, cpu shoudl be 80% clear to poll or watch the bus, and shoudl be a treat.

jeff

I suppose I should render some image to 240x240 and then display it, as a nice test.. maybe add a bouncing ball :p
 
I should just make a single-chip 'console' as well; not nearly as fun or retro, but a little shitty 32bit VGA with audio and a joystick port, and programmer port .. cost like $20 to build or something :p

jeff
 
Screwing with the DMA .. I should move on to redoing the schematic but having fun (and dreading doing the pcb layout part :) these chips are sensitive to the point of pita ... But I'll get it sorted soon and make a dumb little demo.


Should be interesting after board release .. So many buts of code that all work, but can be tweaked. Soldering on other peripherals is easy with these modern chips..


Hmm, adding SD is trivial at hardware layer but should I include one or just go for cart slot? So much less convenient than sD but also so authentic.


Hmm. I was originally planning cart or nothing (reflash using dedicated programmer cable/gizmo) but cart or sdio should be in there ..


..


I should do a single or two chip unit .. I wonder if anyone would care .. $12 cpu, $5 sound chip for old school audio, power connector, joystick connector, away you go. But then , just buy one of those 'pacman' tc-game-sticks and reflash it i guess. To make something nerd sellable you need wifi dpads and hdmi and all the whistles .. No time for that


So stick to goofy designed all fun zikzak, go for lowest selling console of all time award :)
 
OKay, after 2 nights of trying everything with no luck .. finally figured out I had a impossible to see typo that prevented my DMAs from working right. Lesson learned :p (not really.)

Very pleased! So if we go this route with this chip, zikzak is z80 driving a full colour 320x200 (or up to say 600x600) display.. woowoo :)

Anyway, got medium-fast DMA (memory to memory transfer, using hardware) working; theres faster options for that - using burst modes and so on, but they tended to 'shimmer' on the VGA; since the DMA is just going hella-fast, then its not consistent exactly on each scanline, causing bluring at the sub-pixel level. If I add a really fast timer (not sure offhand if it can go that fast) to drive the DMA timing, it'd probably be rock solid.

For now, I just turn off the burst and some other options, so its DMA based, just not full crazy DMA. This _does_ free up the CPU at least, so its not spending all its time copying from framebuffer memory to the GPIO VGA pins, which is awesome; can use that cpu time to do some basic effects of move sprites.

So, _straight C_ without too much optimization at all, and this basic VGA Test is now running at...

450 * 600 with full colour! (RRGGBB so far anyway; I'm not expecting to do more than 8bit colour with Zikzak, since I'd meant it ot be retro styled; this resolution already blows away any retro device :p )

If I play fast and loose with VGA timings I can actually get 600x600, and it'd only work on some monitors.

If we can get timings right for the DMA and use it full speed, we could get more!

Now, this is more than I expect, and more than we'd want to do .. consider that an 450x600x8bpp = 270K of RAM just for a single framebuffer; and I might add, the chip I'm using now has only 128K. I could cut over to that faster chip with 192K of RAM (fun!), but that really doesn't buy us too much here. If I go to kits (seems likely..) I'll go to that chip anyway (fun!), but for prototyping I'm limited to 128K (and need some of that for runtime space, and maybe sprites and stuff.)

Now, we could do line doubling .. 300 vertical instead of 600, or tripling .. 200 instead of 600. With this DMA method, without a timer to drive it, it means its all 'bunched to left', so if we did 200 wide it'd be the left-1/4 sort of thing. Can worry about fleshing all those timings out in later firmware version, just prototyping now.

Still, 320x200 is a pretty nice resolution, and is 64,000B, so maybe 300*200 would be a not bad resolution .. 60,000b/buffer; I'd have space for 2 framebuffers.

Let me take a pic..

jeff
 
Last edited by a moderator:
Using a 192K RAM "GPU", there would be quite a few interesting graphical modes to have.

Like a "slow" single buffered 640*240 mode.

That way, with scanlines, we can get a "fake" 640*480. It worked pretty nicely for arcade cabinets.

And for slow games like RPG, it would be far enough IMHO.

And a "fast" double-buffered 320*240 mode.

Pixel doubling horizontally and scanlines would still get us a fake 640*480, just less detailed. Or just a simple 2x upscaling ;)

I'm still all for cartridges, adding SD card isn't on my "most wanted feature" list.
 
Last edited by a moderator:
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
10K
anexanhume
A
M
GP32 8bit Or 16bit Render Target?
Replies
4
Views
5K
Radek
R
Back
Top