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

[skeezix]

oscilator or crystal? I've got a huge bag of assorted crystals now, built up over time.. I hate to be stuck waiting on some specific timing but oscilators are expensive. Everything else, seems like you can get an ebay cheapo assortment of values in things, cheap; but not them. Theyu're 1 by 1, and pricy beggars..

AVR or stm8 .. whatever you have 'in stock' already?   I've never much looked at stm8.. just assume for 8bit to go with AVR, since so readily available, and in through-hole or SMT. But I'm really liking STM's devices.. good solid things.

Tough choice

 

[Asiyura]

It's an oscillator, the large 4 pins rectangular "tin box"…


And yeah, they're indeed more expensive than crystals. For four pieces, I almost paid 4$.
I guess I could have done some researches to use the video chip with a crystal and some resistors. But it's easier to use an oscillator and solder it's 4 pins

I still don't know if the "brain" of the mod will be a STM8 or AVR… I've got both in my stock. (I should organize my electronic parts, the box I use is a mess of antistatic bags)
AVR programmers are more commonly owned than STM ones, so it could be nice to use those for people who could want to replicate my work.
But I really want to actively use STM µC in my projects… they look to be much fun to play with :wub:  
I've just been reading datasheets and looking at some source code about STM till now.
If going with STM8, I could also open a small web shop selling pre-programmed/soldered PCB with STM8… not to make profits out of it, just recoup the price of the components and PCB. 

 

[fantomid]

It's an oscillator, the large 4 pins rectangular "tin box"…

And yeah, they're indeed more expensive than crystals. For four pieces, I almost paid 4$.


I guess I could have done some researches to use the video chip with a crystal and some resistors. But it's easier to use an oscillator and solder it's 4 pins


I still don't know if the "brain" of the mod will be a STM8 or AVR… I've got both in my stock. (I should organize my electronic parts, the box I use is a mess of antistatic bags)


AVR programmers are more commonly owned than STM ones, so it could be nice to use those for people who could want to replicate my work.


But I really want to actively use STM µC in my projects… they look to be much fun to play with :wub:  


I've just been reading datasheets and looking at some source code about STM till now.


If going with STM8, I could also open a small web shop selling pre-programmed/soldered PCB with STM8… not to make profits out of it, just recoup the price of the components and PCB. 

STM µC are great.

I would like to use them in my projects too.

STM released new boards with Arduino Uno Revision 3 connectivity (STM Nucleo).

Being Arduino friendy, I hope more projects will use these µC.

 

[skeezix]

Of interest .. got a note a week ago from digikey that the AVR ISP MKII avr programmer is EOL. I'm not sure if that implies a MKIII is coming out, or if everyone should use the older but still awesome AVR Dragon (comes in a cool box with a dragon on it ), or any of the dozens of open hardware/cheapie programmers out there (such as using an arduino.) I like the AVR ISP MKII since a lot of people have it, it worked, was pretty cheap, and was officially supported.. but certainly can get by without it. (The AVR Dragon has good debugging support, and can also do the high voltage flash I think, to reset the 'fuses', for example).

Am curious, need to find out what the official Atmel plan is.

jeff

 

[skeezix]

I think I'm going to shift rev2 of the GPU board to be STM32 F4 QFP100 package, instead of 64pin, as mentioned before.

The features on the F407 are directly comparable to the F405 used, just more pins, which makes using either FSMC or bitbanged memory bus much easier to accomodate. The F4 and F2 families are directly pin compatible as well, which does make it interesting..

F407 is the model nearly identical to the F405 I've been using so far .. same speed (up to 168MHz instruction clock), same RAM, etc.

F429 is the higher end newer crazy model, which is pin compatible, but can go up to 180MHz instruction clock, and features an extra 64K (might be core coupled, I forget), for a total of 256KB fragmented memory. I've actually got a few of these bad boys on hand, free samples from sTM (they're almost as awesome as TI that way.. so awesome!)

And someone asked.. no, not switching to TI.. they have some insane ARM chips.. cheaper than the other guys, and up to 450MHz, and all that, but i'm sticking with AVR and STM for this project Certainly an awesome set of chips that TI has, though. (The MPS mcu's and such really are sweet, and TI is very generous with the samples and dev boards.)

...

Will report back, but should be interesting to rejigger the schem and re layout the pcb for 100pin; double up those headers.. no way I'm putting on 4x 25x1 breakout headers there; 4x 13x2 headers in the same square-around fashion should work, and lets me tweak a few other things on the board, plus adding the RAM bus stuff.

Love living in an era of $13 for 10 pcbs .. makes prototyping more interative, and much less risky.

jeff

edit: Not had a lot of time as (as usual), but laying down the schematic updates for the 100pin QFP is going quick; did much of it last night, maybe finish it off or be 90% tonight/tomorrow, and almost certainly done by Sunday night. Maybe with luck, can submit another pcb to elecrow Monday?

 

[skeezix]

Hmm, looks like boned on the FSMC use on the QFP100 packages: (FSMC is the built in memory controller, so you can 'just use' memory; refer to an address in the flat address space, and it maps certain addresses to FSMC RAM use, more or less.)

"


For the LQFP100 and BGA100 packages, only FSMC Bank1 and Bank2 are available :

Bank1 can only support a multiplexed NOR/PSRAM memory using the NE1 Chip. A 16-bit multiplexed, bidirectional address/data bus is available.
Bank2 can only support a 16- or 8-bit NAND Flash memory using the NCE2 Chip Select. The interrupt line cannot be used since Port G is not available in this package.

"

 


Don't care about using Flash; I want to share memory between the GPU on STM32, and a cpu (z80, etc.) Sort of odd having to first-class processors hitting RAM

So that leaves Bank1 doing PSRAM.

Goal: I was hoping to set the RAM up on pins that could be fully bitbanged (for fun!), and also for FSMC (so you could get higher bandwidth and use DMA easy, etc.)

Goal: Using DIP SRAM, since I have a bunch, and they're cheap (1Mbit .. 128KB 32pin DIP, for $2.. nice!)

PSRAM at digikey is all BGA package (no way), or some TSSOP -> unavailable for quite some time.
Same story at Mouser and the other big name shops .. not stocked, or not available, unless you want BGA.

And well, I do have a stack of DIP RAM here already

Blast, guess I'll have to just bitbang it; I don't want to go higher than 100pin; 64pin is okay, 100 pin is tolerable.

On the one hand, sure slows you down when bitbanging it .. if we trim to 16bit address (64K, and just use it for framebuffer or sprite lists) on the gpu to RAM (could still have more address lines for the CPU itself, to go higher addresses), then its one full 16bit register on the GPU (say, PE0..15), which is a single write; something akin to "my_address +=1; PE = my_address' or more likely just "PE += 1" sort of thing; so thats fast. Maybe also toggle the OE and WE pins, unless you're batching up and can just whip through without toggling them. So you end up with first-read being a few cycles to set up pins, and then a couple cycles per subsequent read.. plus any padding needed to delay things. Using the FSMC so its all 'just done' in the mcu core is way handier.

On the other hand .. if the cpu we're typically saddlign ourselves with is a 6502 or something, its quite likely at 1-10MHz anyway; an eZ80 or Atmega can be higher, say 30 to even 50MHz. But even if we assume 10MHz, theres only so much a Z80 can write out there, especially with processing; if its updating a framebuffer stored in external RAM, its likely using some pixel painting code, or line drawing code, etc, so its not full speed spitting out to RAM, either.

The GPU is likely also limited by how much it can read it .. if you're being careful and reading only during VBLank to avoid compromising the VGA timings (until we get some time into the code and figure out a workaround for that.. cpu is idle much of the time, just the GPIOs are busy .. maybe we can figure it out.).. then bitbang reading only during vblank into on-board ram as real framebuffer is the trick. Still, I should think the GPU with reading only during VBL can outpace the 'cpu' writing during most of the time (non-VBL.)

Could even add a pin from cpu -> gpu 'buffer ready', so the gpu could avoid vblank-reading (grabbing the Bus and halting the actual cpu) until theres actually something there. Thats sort of silly though

jeff

And if you are wondering.. given the 64pin chip, you can almost squeeze it all on there; ie: i2c, serial (console + communication to cpu), VGA data + syncs, vblank and some other signalling .. + 16bit addr, 8it data, some control lines.. but even if you can fit it all on there tight, I want some extra pins for BoB sake, but other things. Hooking up some quick buttons to, some sensors, etc. So hence the push to the QFP100 model.

(also, once you go F407, you can skip righ tto F429 for the higher speed and more built-in features, if you want to.)

 

[skeezix]

Man, routing this 100pin QFP based board is really a pain.

i) Thats a lot of pins!

ii) PCB dimensions cost a lot, so trying to keep to 10cm-square or less

iii) Layers cost a lot, but I could seriously use a couple more

Summer special is on now.. 2 layer, 10cm-square, 10 copies.. $12.

4 Layer 10cm-square -> about $50

2 Layer, 10cm x 15cm, 5 copies .. about $40

So daaaamn, 2 layer 10cm-square is totally the way to go.

Real problem here is the STM32's seeminhly random pin locations; you want to use one continuous bank of 8bits, and they're randomly around the chip. When you're trying to use say PE all 16bits for an address bus, and its split across 3 sides, its just a real tragedy to route. The density is brutal. I'm probabyl missing a trick or convention to make it easier, but daaaaamn.

4 layer would make it a lot easier, but the cost is 4x as well it would seem.

Surface mount shows its worts here .. ure you've got 100+ pins in small area, but _getting_ those pins anywhere sucks; you have to extend them out in  fan, then drop them, to appropriate layers somehow, and thats where you get stuck.

hmmm..

edit: and yeah, if Nicholas can pull off Pyra on 2 layer, I shoudl be able to pull off this. But he's got 20 years experience or more at this

 

[panik]

Every time you drop a via to the bottom layer, some deity kills a kitten.

Edit: See if I care, I'm not a cat-person.

 

[skeezix]

Everyone says that.. buddy of mine on his high horse with 'I'm not happy until the board has no vias at all!' .. well, try and do some SMT parts and good lulck to ya

I'm weaving up and down like a basket maker to make this work; I'm just assuming vias are reliable (don't tend to fall out or have shoddy connections), and using them willy nilly on this board. Theres no price-per-via at elecrow, so screw it. My other board designd were minimal vias, but I totally blew this one somehow. 100pin QFP with the 4x 25x2 breakout pins around it is one dense mess, and with signals going to 3 sides of the chiop, wrapping all over, plus all the various other things going on.. just a mess.

Once this one is routed, and if the bloody thing works, I'll be happy.. but need to devise some strategies to handle this sort of thing.

jeff

 

[skeezix]

Wondering if you can 'via to a gnd plane'?

Eagle takes it sort of oddly, but seems to work; hoping it'll also work for the pcb house.

ie:

Top is signal

Bottom is gnd plane

Routing along top, just drop a via to bottom; Eagle doesn't realize its now gnded (in theory..), so you route a trace out a tiny amount, and leave it hanging.. and then Eagle recognizes the connection to gnd.

1) Is that working, or cheating myself into failure?

2) Sort of also assuming Eagle will catch when the gnd plane bubbles are cut off from actual gnd, and then require them to be joined.

jeff

edit: I think I'll be okay on this one .. its complex via spaghetti hell, but onyl got about 8 more traces to go. It'll be a miracle if it works... I'm hoping you guys know the answers above, to ease my soul Still, $11.90 for 10, muahuahua!

edit 2: okay, got the damned thing routed. Learnt a new Eagle 'workaround' .. so many oddball little keystrokes you need to know, with no documentation It wants you to route airwires, but often they're the worst match (since it just assumed closest points, not easiest or least obstructed points) .. ctrl-Route lets you select any point on any trace to begin routing from, and it'll take over the airwire then. So stepping back, zooming out, sometimes you can just see some oddball path that is 10x easier than what its airwiring, and save the day. Airwires are not 'recommended' connection paths, just required connection hints. I bet if I redid it, I could do better, but damn if this is not one complex pcb, and its not all that many parts. Ultimately the GPU pcb is a breakout board for one chip, with some passives and a right pile of headers. So it shouldnt' be _that_ complex, but the sheer pile of pins, and trying to get them to headers in sensible fashions, is just brutal on a 'smaller' pcb. (its not really small at all at 10cm-square, but with all this stuff on it, it is quite jam packed. It really needs more space to work, or more layers .. both of which cost $$. Trying to keep it small then, makes it 4x more work than it would otherwise be.) This sucker had to have taken two or three times longer to route, than the 64pin one (which also lacked the RAM bus. The RAM bus is what, 36 pins or so extra, spread all around the chip.. so yeah.)

 

[skeezix]

I suppose FWIW, I should've perhaps routed the actually-used traces first, then gone back to fill in the BoB lines. At least that way it woud've been easy to get the real work done, and then hard for the lesser critical stuff. Normally for a production release, you wouldn't likely be oruting every pin on the thing, for lulz

jeff

 

[skeezix]

eZ80 is a bit blowing my mind right now, going through the datasheets.

As you recall I didn't have a lot of luck with that guy, due to the funky power supply issues; as a result I've long since switched gears to pluggable CPUs .. just a standard zikzak cpu header, and plug in a 6502, 6809, z80, whatever, and let the pluggable cpu pcb do its own decoupling caps and ISP headers for programming, and so forth. This generalyl works pretty well as an idea, but does lead to a lot of schematicing and so on.. and does complicate the design a little (ie: you have to assume no GPIOs on the cpu, since 6502's and such didn't have it.. so end up throwing on an avr (say) to do gpio stuff, such as converting joysticks into usable signal.) And then you have to bus up the IO chip to the cpu bus, and add headers and so on.. starts to be more mess/complexity. I'm okay with it, was my plan for quite some months.. but I'm feeling pinchy, lately.

Right now I'm going through the motions of designing the base pcb (again), but this time its from scratch and a lot different than my previous designs. This is the 'all in one' sort of design (not counting GPU and power, which are separate.) This has joystick port, ps/2 port, audio chip and speaker headers, all that stuff. ROM cart slot. And RAM. Good stuff.

But looking at the extra stuff to support swappable CPUs, I'm getting lazy feeling again. And as all this started out trying to be Z80, I'm thinking (right now, this minute to go try aZ80 again, and simplify the design.

eZ80 is a great chip, with full Z80 compatibility, but also some handy stuff built in; little bit of RAM we don't care about likely; little bit of flash we can use as a boot loader or BIOS. 24 GPIO pins. ho-ho!

zikzak GPIO needs are approx:

2 for keyboard (clock and data)

5/6 or 10/12 joystick or two (I'd like to get 2 on there); I'd planned for 4way plus 1 fire at minimum (Atari style), but might be nice to have a few more on there.. like 4dir + 2 fire (fire and jump, say), and wire up some gamepad.

10 for AY-3-8912 (8 data lines, 2 control)
1 for vblank handler

1 ideally for frame-ready (may not be needed, but seems handy right now)

--> 26 at best; if we just use 1 fire button for each stick, that gets is 24 (voila!)

---> if we use just one joystick, we can use 4dir + 2fire and get back 4 pins for general use

We can also avoid deciding on joystick, or let you do what you want.. just make the joystick interface a row of 10 pins, and use them however you like.. 2 sticks with 1 fire, or 1 stick with more fire buttons and some free pins.

I do need to sort out the programming interface for flashing the thing, to load our base firmware in. We can flash the chip to not have flash or ram, or keep flash or ram as we see fit. ie: If we disable flash, then it'll have to go to cart for all ROM and startup; or we can enable flash, and it boots from that, and then have that check for cart and if present, fire up the cart, or do some built in BASIC or something. Handy. (Also can do bootloader stuff such as copy cart ROM chunks into SRAM, so it runs faster. Running out of flash or off ROM cart might be a touch slower, .. tbd)

Anyway, so looking at building eZ80 right onto the rev1 base pcb for now, since theres a few unknowns about the elecxtrical design (the ISP notably.. I'fve not built one yet. I was using official cable and some jumpers and the chips were frying before I could get it alive.)

ie: The programmer pins can do OCI, or ZDI (on chip instrumentation, zilog debugt interface) or JTAG; not sure how well it all works.. can we just use generic jtag to reflash? or need I make an avr flasher for this, or drive it via buspirate/etc, so many choices..

Anyway, base pcb is coming along; rev2 gpu pcb I'm awaiting and should arrive in a week or two or three, and can find out if its bus interface is working right. (so much crazyness with vias, worry something is too close to something else, etc.) will be able to test RAM->gpu for framebuffer in RAM nicely, and in theory it should have a few ways for using the gpu .. serial (framebuffer on gpu, like an opengl scenegraph), i2c (too slow to be practical imho), and via RAM. For RAM, can use scenegraph on gpu with RAM as sprite-list, or actual framebuffer in RAM and GPU just renders it. (more or less)

--> of course, its all codable, so folks can do whatever they like for gpu and cpu communications

Good times..

jeff

 

[skeezix]

Ah, just learned something I've been ignoring for awhile. The whole question about chip families .. LS, vs HC, versus HCT, versus LV, etc, is confusing and best avoided (getting match families, try not to mix!) .. but when using modern chips with retro chips, you get into some goofy spots. I've been looking at buffers, line drivers, voltage shifting chips, etc, to try and mask some of these possible issues. Typically I've just been lucky.. run an avr at 5V, and hook it up to AY-3-8910 and good to go. Run STM32 at 3.3V and hook it up to something else, no problem. avr's run fine at 5 or 3.3, and STM32s run at 3.3, and eZ80 at 3.3, so just using 3.3V all along the way tends to make everything happy for me (which is why my boards typically all include 5V, 3.3V, 1.8V .. Iv'e rather been assuming I need a level shifter for the PSG though .. but someone has just clued me in, so I think I'm good to go.

Looking at the AY-3-891x series, checking the Vin for Low and for High's, seem compatible with the eZ80 Vout for Low and High.

AY-3-891x: High is 2.4V+

eZ80: Out Low is .4, and Out High is 2.4

Likewise for the eeprom I have stocked up for my carts (AT28C256).

AT28C256: In V high is 2.0V+ .. that sort of thing

Sometimes you get lucky (and in the back of your head, you know it was good designing on the engineers who built all these things.)

No voltage shifter needed!

 

[skeezix]

Little status update ..

I sent an order some weeks ago for the rev2 GPU pcb that includes the full bus (address, data, control lines, +some extras like vblank); rev2 ratcheted up the pcb design complexity quite a bit .. I'm getting better at handling that density, but I suspect I either need more practice or the density just needs more layers or pcb surface size to work with (theres only so much you can do per square inch, though I'm not entirely sure of best practices there); adding header pins really causes a lot of extra trace crossing and travel distance. Anyway, that pcb design is nearly here at my place I think (taking its sweet time in transit!), so will be very interesting to see. ie: Smaller trace widths, much higher via and trace 'basketweaving' going on. Its all within Elecrow's specs for minimum distance/etc, but we'll see. Also fixed the one connection that needed me add a jumper for the jtag to work. When that arrives, I'll have a fun week hooking it up to an avr and some RAM to see if the bus control and framebuffer-in-ram is working well.

I've also added to the bus a chip-select for the gpu board, so in a a way we could send data to the gpu right over the bus (in addition to sertial, i2c, or via RAM/ROM.) And yes, the cart rom is available on the bus, so the gpu should be able to read it directly as well, and should be able to flash the cart; so the cart should be updatable from the eZ80 or the STM32 (with old school bus you've got some logic ICs in place to map addresses to chips and such, and I originally thought to ensure only RAM visible to the GPU.. but with eZ80 it can operate the chip selects through software address mapping, which greatly simplifies a few things (I had no space on the pcb .. so with all that, cpu + gpu can both talk to the sound chip, ram, cart, and each other. Woowoo! (We'll see if it actually works in a few weeks.. it may just catch fire. But the design is sound, even if I have some mechanical issue.)

(There is some small question about specifics.. when interfacing a newer chip to an older chip, you've got to watch the chip expectations and outputs carefully; some of the datasheets are not quite as specific as I'd like, but it should all work out. Like an inverter chip.. you can use HC, LS, HCT, etc variations.. one of them will match, damnit, but IT hink I got it all sorted out.)

I had intended to wait to test this guy before sending in the base pcb, which is even more complicated again.. but with the long shipping times (too cheap to pay extra shipping , I think I'm just going to send in the base pcb as well. If it all works, I'll have a working full machine here, so.. can't wait any more!

Annnnyway, I'm going to send in the base pcb design now; rather than wait; a little simplified from my goal the last few months, just due to lack of space for routing and parts, without increasing cost. Skipping including pluggable cpu's (for now), I've currently gone with eZ80 flat out since that was always the goal and it cuts down complexity. (and if thats the baseline, and if more than 1 person gets a zikzak going, it'll be nice if we can swap applications  or carts a little   Of course, I had no luck with eZ80 before but that was squarely in the power supply arena so here's to having better luck this time. And also, I'm really really sick of routing 100pin SMT components, so hope it works so I don't have to do it again for awhile

Given the eZ80 wants to use a Zilog product (based on Visual Studio) to do flashing etc, its a bit annoying; I may have to build my own interface to that, but I'm not too worried.. the eZ80 itself should have a very minimal flash setup .. a basic bootloader code to check the cart, and do somethign if present or not. Maybe include some basic BIOS functions so the carts don't have to all duplicate the entire firmware, but not well defined yet. ie: It might be cool to put a little game or BASIC or something in the eZ80 flash, for when no cart is inserted. But thats all optional. Whats not optional is flashing the eZ80 memory map, so it knows what goes where, to handle the chip selects; it being configurable id awesome (originally was going to do it purely old school and use AND gates etc, to put screen at $xxxx address, and audio at $yyyy etc. Z80 reset vector is $0000. Anyway, now we can map things wherever we like, which is neat.. but it should be well defined and standard, so we can all depend on things working, and because its not like they need to change. So could always flash eZ80s and send them out with kits, or build a flasher or something.

Assuming a few people want in on this insanity, they may not be comfortable with soldering 100pin smt, so I get the impression I'll be doing those for peeps anyway. (ugh .. at least I'm pretty good at it now

So, the base pcb, is also 4" square (ugh.. 4x6 would be awesome!)

- features the cart slot! totally sexy.

- features the AY-3-8912 audio chip (same as in Vectrex, Atari ST, many arcade games, you name it)

- has RAM on board; currently just supporting 128KB of RAM, though the eZ80 can actually handle quite a bit more

    .. I had envisioned the RAM being primarily a single framebuffer, plus space for other stuff; the framebuffer RAM size depends on the resolution and mode... mind you, a full 640x480 is 300K (doh); 320x240 is about 76KB, 320*200 is 64KB, and 256x256 is 64KB. So we have a fairly good resolution to work with.

    .. the ROM space iws quite large (couple of MB) so is plenty to play with

    .. the GPU itself has the live framebuffer on it, which depends on the chip itself; 64KB or 128KB or a little more is workable; likely put some sprites in there..

- two joysticks

- ps/2 keyboard

...

- theres some spare GPIOs on the GPU and CPU, so could put an SD card interface on one side or the other fairly easily; all those sorts of mods are unofficial fun things to try

Right now due to board space, its all headers (there slike what, 17 headers on the base pcb!), so when I say joystick port or keyboard port, you solder on or jumper on some wires to a port; no big deal.

Once its all tested and happy, maybe I'll design a big one-piece pcb with actual connectors on it; not a big priority for me, but later, baby.

A heck of a lot of testing to do for me .. testing all the peripherals any numebr of ways (flashing the cart from z80, from gpu; communciation to gpu over serial, i2c, framebuffer, or gpu-as-bus device; joysticks, ps/2 keyboard driver in z80; various text and video modes; etc.) Its all worked in isolation, but all working together is another thing.

Probably anothe rev or two of the base pcb to fix bugs etc.. who know2s, maybe it won't work at all when it arrives All part of the game..

--> but I'm quite stoked; all the zikzak pcb components are waiting to arrive. The gorramned design is 'done'. Not debugged yet, but done.

Woowoo

jeff

 

[skeezix]

(and he mulls over.. try to write a POSIX environment to run in 128KB? or just a firmware like in a C64 or SNES.. basic BIOS routines only )

jeff

 

[Franko]

WOW!  I'm amazed that you're still at this project - skeezix.  old school hardware and almost reverse engineering things... I remember thinking how great a learning/teaching guide that this would be...you're a great tinkerer who got more out of his Commodore 64 - Mine was the Atari 800.  Similar processor(s) and even engineering family.

 

[skeezix]

Never actually had a C64; my family had an Atari 2600, then a Vic-20 - the 64's little brother; instead of going to Amiga after that, we went Atari ST and hence my eternal fascination with all things Atari

I need to restructure the www.zikzak.ca webpage .. its fairly poor; a crummy use of wiki, to be sure

There definately is somethign to be said for knowing how the old machines worked inside, to actually putting one together yourself; a new appreciation for how they tick, to be sure. Its fun as hell, for that special kind of nerd type that I am, anyway

jeff

 

[HamishTPB]

Dunno if you know about this website or not but it might be rather interesting if not helpful.

http://www.atariarchives.org/

 

[skeezix]

A classic page; that and http://www.commodore.ca/gallery/magazines/gazette/gazette-magazine-1-45.htm I need to go through someday .. I have stacks of those books from when I was a kid

I really need to go through and redo the zikzak.ca site.. that wiki is sure handy, but the back-button is so totally mishandled as to make the page useless; not sure if its the wiki itself, or just the mod that gives it the tabs, but either way .. annoying. Will look into.

jeff

 

[skeezix]

OKay, decent news.

Got the rev2 GPU pcb in the post today; selected a blue pcb this time, to help differentiate versions. Pretty snazzy, but a little too dark.. sort of hoped it was a lighter blue. Still, the darker blue does help contrast pins, so you can see dark blue showing up between pins and help know theres no solder bridging. (I'm still using the USB microscope for everything though .. would never touch these QFP100's and QFP64's without it!)

Definitely needs the caps on all the power pins for this guy; I found the F2 line could run okay without caps; the F405 (64 pin) seemed to run okay with most but not all caps; the F429 seems to need them all on there to work, at all. Thats okay, I was just trying to see what I could get away with.. the pcb has places for everything of course.

Right off, the familiar zikzak test pattern comes up on the display, so it at least works at a basic level; running my line/boxes demo shows some glitching, so I need to verfy .. the F429 is a much more powerful chip, and can run at a faster speed (up to 180MHz, whereas the F405 maxes at 168.)  I was out of 8mhz crystals so desoldered one from previous rev gpu and placed into the new pcb.. its possible the crystal isn't soldered right or got damaged during the transplant; or perhaps the timing settings are different for the F429, or any number of things.

Late at night now, and a holiday tomorrow, and babies kept me up till 3:30am last night.. I think I'm not in the best of shape at 1am tonight to be tackling this; best to rest on it, and fiddle some more.

Still, the GPU rev2 pcb is alive and kicking, and no more bodge to make jtag work; its all good so far.

To be done ASAP: hook up an avr8 to SRAM, and test it writing and read-verifying to the SRAM; then also hook up the rev2 GPU board to the SRAM, with them coded to respect the bus (ie: have avr8 pretending to be the z80, and using /BUSREQ and /BUSACK to allow the gpu to take control.) This way can verify the RAM and bus new parts of the rev2 GPU (which was the entire point of rev2; rev1 had already nailed down serial and i2c.)

--

The base pcb with z80, audio, joysticks, keyboard _etc cetera_ should be arriving _next week_ (already in the courier hands.. this time went with courier, can't wait ; this one is still a bit of a concern, since it has the eZ80 on it and I've not a lot of experience with its electrical characteristics yet, but have faith in the datasheets. Assuming the eZ80 works at all (god damned better! , then it'll be time to hook up the base and test it out, and then hook it up to the GPU, and write some code, and see the magic.

Really going to be a fun few weeks, testing bits out. With luck and the base cb works, in a few weeks will have a full zikzak console/computer sitting on my desk, letting me type text onto the screen, and control sprites with joystick.

Gooood times

--

I wonder if there is any sensible way to kit this up. Need to check what price point population ca work for, for low run builds; be nice if they could stick mcu's onto the pcbs for me, save me some work and testing .. kitify these things. Still some worry over getting the audio chip (AY-3-8912) .. but ebay still seems to have a fair number. Still, can't count on that supply or pricing, so would have to build an emulator for it into an avr8 as a backup, or make my own audio engine or something. Doing those 2 things would allow kitifying all this, throw a few up on EDs store.. blah, doesn't seem workable Who knows.. why worry yet, got months to go before we know if the darned thing even works

jeff