More later (awesome!) but .. $4 for how many how big? Where from?
It's from OshPark, they charge 5$ per square inch, you get three copies and free shipping.
My board design is a bit smaller than a square inch.
I bet there are cheaper per square inch PCB factories. But they often have a minimum number of boards, so it's actually cheaper to pay more per inch when you're prototyping and/or only need two or three boards.
I've always ignored those per-inch guys, since my pcbs for ZZ are all 'big'.. 4inch square, and I'd like more
4in-square is 16-sq-inch, which would be like $80 for 3pcb. But I see how that works for teeny guys. What can you do on a 1inch-sq-pcb?
I keep thinking it'd be neat to make an Atari 2600 mod, with my own 'all ROMs cart' sort of deal; I've got a stupdendous stack of Atari 2600 carts actually (not a full set, but say 80% set), but lord knows I do not want to dig that box out.. the kids would be using them like lego and I'd never find half of them again; so compressing them into a all in one cart would be neat. (I'm sure there are things like that out there, but easy and fun to make your own!)
I'm rather stuck right now for zikzak, need ot do some more research and tests.. sort of mind blown right now.
One thing that seems challenging is just using an o-scope is changing the outputs; ie: with all the buses plugged together, cpu <-> gpu, I get different results when the o-scope is touching; ie: want to see if GPU setting /mreq and address lines, does the cart ROM chip select go live? So o-scope on /CS1 and see.. and it seems okay; but the data lines return different stuff if the o-scope is attached or not. Start touchign around with the scope to see whats going on, and it changes things. That I find rather intimidating.. what to do with no visibility? You need to o-scope around to figure stuff out, but it changes what you see? Uuuuugh, welcome to Real Electronics
Stuff like that sort of suggests to me an impedance problem; the sort of black voodoo where if one side has higher impedance than the other, and the rise-times differ than expectations, you get ringing back and forth, voltage flopping around on the line. The cart rom is fairly modern, so its not like I'm doing issues with 1970s tech to new tech (and in fact, the audio chip is working fine and that _is_ old tech..).. still.
So I'm not entirely sure what values I'm seeing right now .. it looks like this-and-such, but not sure if the o-scope is lieing for the real operating details; need to find out how to work with _that_ situation. At least, try to get the mcu's to report pin state and such themselves, but theres only so much you can do for output pins, if you can't touch 'em with the scope.
So right now GPU works a treat, and the base/cpu works a treat; just having trouble bussing together. Bloody annoying, that
1) - tempted to do some more serial hacking, for fun; the cpu can spit out 57600 pretty easily; going to the next one up seems iffy. Wild rounding, thats about 5KB/sec, which is not a lot in some contexts; say you want to upload a full bitmap 8bit colour to GPU, at 24x240 res (about 60KB), you're talking 60KB / 5KB/s or about 12sec to do so (wow!), not even worrying about vblank (disable screen while uploading, say.) Lame. But if you're doing 16x8 sprites, you could upload like 40 of them per second, no problem, so say spend 1-2sec uploading sprites, then no problem just working with them. (ie: update the scene graph, tell the gpu to move sprites around, would only take a few bytes per sprite, so no problem.)
--> could write a little game, and BASIC interpreter and all that, no problem, using serial cpu->gpu communications
2) - also tempted to do a thing where gpu is a device on the bus; /cs3 was what I planned for this. So here, you memory map the gpu into the z80 memory space, and then when z80 writes to it ("*gpu = 10" sort of thing), the bus would do its magic; here you'd have z80 on interupt waiting for the vblank to start, and then soon as it lands, start doing a blit-loop (say), to transmit sprite data or screen data; the GPU shoudl be fast enough to handle the bitbanging there .. not sure how fast transmission could handle but might be on the order of 1MB/sec or something, who knows. That would surely suffice, but was only one of the options I wanted to enable.
--> see, the bus _works_, its just having a problem reading from cart ROM -> GPU; cart ROM -> z80 is not a problem. How annoying is that
----> it could just be the ribbon cables too; too many cables too close together in arching maybe causes inductance problems; maybe it'd all work on a pcb, with ground plane all around it...
3) - and want to figure out and fix wtf is going on here.. its annoying when gpu can't read ROM or RAM as I intended
Anyway I have planned for (1) (2) (3) to all be available; if (1) and (2) are available, thats still a win, but not quite As Much Win as I'd like
More to do...
jeff
