skeezix
Internal Development
The only problems I can think of with this design, software-wise is that in forcing people to use double-buffered code, you're forcing them to redraw the whole stage each frame. Certainly on old 8-bit hardware at lower clock speeds that was tricky to achieve. I suppose if the CPU were to remember the sprite positions from two frames ago, it could still paint out those locations before redrawing, but that means actually having to plan and remember things, rather than just using the current values of X and Y for each sprite from last render before invoking new code to calculate new positions.
Hardware wise, how do you cope with switching banks on the fly like that? Does the CPU do any sort of pipelining? If so, it could have done a fetch on one bank and end up writing to the other, if it does fetch and write in separate cycles.
Edit: @Kodeln Sure your soldering iron is hot enough? Lead free's more likely to half melt than old solder. Also, flux.
No worries there..
The page flipping is controlled by the CPU; right now the code will be all flashed in.. one big shot; 'firmware' and 'game' are built together and flashed in, so the game can have page flipping or not.
When I add a cart slot (or SD slot?), I'll have a bootloader or other base firmware setup, and it'll be an option to use the page flipping or not. I'm expecting to make it so the cart, if it wants, can fully take over the system .. do what it wants, so it can install inteupts and such as it sees fit. (Not even started mulling over carts yet.. ie: are they just ROM-packs, or can you add periopherals with them, such as additional joysticks or serial ports? and if so, need to support multiple cart slots.. one for games, one for expansion? *Fear*)
Either way, its consentual .. the 'gpu' raises the 'we're going into vblank now' pin (and clears it later); the cpu-side is supposed to watch for it (or software can set up an interupt on that pin), and then if it is _Ready_ to flip, it can toggle the page.
ie: The gpu can't force a flip, since you'd end up with tearing; you want to flip at end of screen (to avoid tearing) and avoid flipping mid-write (to avoid tearing, of another kind.)
..
Theres no caching or pipelinging magic going on I think, but a good thing to check for )
The actual page flipping is just a single pin .. high or low, and that sets which RAM (lets call them VRAM) is on cpu, and the other is on display. If you want to know how it works.. chek the schematic, and I can write it out for you.. but its essentialyl just using MUXers (multiplexers.) Each MUX I'm using is two sets of 4pins in, and one set of 4pin out, and some pins to control which set is connected. Think of it like the letter "Y", and you can pick which side is connected.. A or B. Its a one way flow, which is annoying, though, so mostly only useful for write stuff.. address lines, control lines; for the I/O back from RAM into CPU (so it can read from thge page), its some work (not much.)
It is tempting to make the VRAM write-only, simplify some of the wiring a little, but its not too hard to make read/write work, so _Should_.
Also, as the VRAM is 'large' (and I can make it bigger, add 128k or 256k say), it can be used for storing stuff:
i) If you're not doing page flipping at all, then its easy to use for extra RAM
ii) If you are doing flipping, you can still use it for RAM, but have to be mindful of..
- which page is live, for which data you've got stored there; only udpate certain thigns while the extra RAM page is available to you? Like move sprites every other frame? Or if doing some big calculation, do it gradually there?
- or if you need to store reference data, stick it in both pages? write it out to address XYZ on both, and then read it as needed not caring which chip is available?
..
I can add another data bus, a pure RAM private-to-cpu bus too, but I'm avoiding that complexity for now.
Right now the 8bit cpu's I'm using, have say 4k of RAM in them, so that I call 'fast ram', and that is probably enough for most games anyway, or simple applications. (These guys also have 128K of flash space, so quite a lot of data could come in there, read only wise.)
If I cut over to a real 6502 or the like, though, I need to add a RAM and ROM separately, no flash/ram built in.. no big deal, but more wiring
jeff