Another lame little video, but hey, its what I did tonight
The cpu is now offering up a basic menu, with some demos and test screens available; this whole menu really should be a submenu but I've not built the next level up yet, so straight to the demos! Ultimately, the boot process is something like this:
- set up the BIOS API jump vector table (so carts can have some basic built in routines they can jump to, or monkey patch/chain)
- check for cart
--> if cart, jump to carts entry point
--> if no cart, show top menu
top menu (no cart present) is supposed to offer some options like .. fire up a BASIC, and go into test and demo mode, or offer up some flashing options so you can use USB/serial to flash the cart, or the BIOS, say.
For now, I just have it jump to the little demo menu so can fiddle around.
As you can see, its a little faster now, but still too slow for my books; I mean really.. at full colour 320x240 resolution (and this can go about 800x480 VGA!) we're talking 64KB of framebuffer being pulled 60fps; and since I'm not 'cheating', the GPU doesn't use dedicated memory lines (or DMA), and its bitbanging the whole bit manually; given its spending most of its time doing VGA, it can onyl afford so many cycles, and it does so during vblank to avoid screwing up the image; but during vblank, it has just enough time to pull in the framebuffer. So during every vblank, the cpu is being held paused.. sort of suboptimal. (the VIC chip, or Stella chip, etc, in the 80s.. they cheated; they had custom hardware designed that knew how to sneak inbetween the clocks of the cpu, interleaved; we can't get away with that trick, without custom made graphics hardware; I may do that with an FPGA, but Not Today!) So that constant bus hammering is killing the cpu, and hence the slowdown.
I think I'll work on a demo using a scenegraph mentality; I need to set up a command queue to the gpu, so the cpu can change resolutions, tell the screen to turn on and off, stuff like that. Or pass code over to the gpu to execute, since its quite a performant beast.. conceivably, you coudl ask gpu to turn off the screen (or stop updating the framebuffer or etc), and do some real computation, and put the results back into RAM; neato. Anyway, have a command that sets mode.. is the GPU in framebuffer raw mode (slow but nifty!), or in other modes.. like scenegraph mode, where you supply command lists (heres sprite data, or move sprite Z to (x,y)), or other modes (heres an image, now rotate, pan, tilt it..); then its more like OpenGL and a clean interface.. 'here, GPU, is some sprite data, during setup; now, subsequently, you just have to copy it here, and here"; so instead of 60fps of 64KB/shot, the cpu can raise the 'frame ready' flag, and pass along a few hundred bytes with updates for the scene, and let the gpu spend its time assembling the image.
In this way, the bandwidth over the bus is _enormously_ reduced, and it'll make things like scrolling backgrounds easy as pie; the cpu will be free'd to run full tilt, since the bus won't be hogged each shot, and the bus shots will only come when the cpu says okay, ready!
In this scenario, I'd expect no problem with hundreds of sprites on screen at once, etc, which is where I've been going.
...
And I think I have the audio issue sorted, but take awhile before I can prove it; probabyl should use a bus line driver or somethign to help with power management on the pcb, but I'm trying to keep things relatively minimum here.. its 'at spec' so far, though, I think. (power draw is higher than I'd like, but the actual power regulator is off-pcb, so I don't sweat it; right now I'm running off PC USB, and USB2+ can support quite a high amperage draw, so no problem.)
Let me know what you think .. I know, its lame demos, but I like them; and this is the baseline.. once we see how fast they go in the near future, we can compare
https://www.youtube.com/embed/videoseries?list=UUGQF542dq8RhizMRFbBnBaA
jeff
