levi
Still fresh, damnit!
Firstly, I think we should ignore double buffering where you can only write the the visible buffer, as that's almost entirely pointless for games. Yes, two buffers where it can be set up so the video output comes from one buffer while OS writes go to the other.
So regarding your chip switching, are those RAM chips going to be dedicated buffer/vram chips? So your program code will be in some other RAM (perhaps the on-die cache you mentioned earlier). That makes sense - previously I was imagining you switching out my program every 60th and wondering how that would all work.
I understand why you're thinking of double buffering and CPU/GPU interleave in the same headspace, but I'd just like to point out it's possible to do double buffering on a system with either double ported VRAM or blocking RAM. FWIW the old BBC Micro used to have its RAM clocked twice the speed of the CPU/GPU which enabled the nifty trick of the CPU having access on even RAM clock ticks and the GPU having access on odd ones. But your approach is another way I'd not thought of before, so I'll be interested to see if there are any downsides to it, other than making it not possible to use a lower resolution mode and reuse the now freed screen space very easily.
FWIW I see the colour change apparently fade to right and down on that video, but I guess that's just the serially connected sensor in your cellphone causing that effect.
I don't think I really have a handle on your GPU yet, though thanks for clarifying how the VGA's wired in. What sort of ASM does it take? And how fast is it clocked?
I think that just about covers everything. Impressive spaghetti there, and I'm glad to see from the video that the inclusion of blinkenlights is proceeding apace. Out of interest, what's that board with the akilter connector that seems to be wedged through the gap between your breadboards (and have you had to cut a slot in your actual bread board to fit it?)
So regarding your chip switching, are those RAM chips going to be dedicated buffer/vram chips? So your program code will be in some other RAM (perhaps the on-die cache you mentioned earlier). That makes sense - previously I was imagining you switching out my program every 60th and wondering how that would all work.
I understand why you're thinking of double buffering and CPU/GPU interleave in the same headspace, but I'd just like to point out it's possible to do double buffering on a system with either double ported VRAM or blocking RAM. FWIW the old BBC Micro used to have its RAM clocked twice the speed of the CPU/GPU which enabled the nifty trick of the CPU having access on even RAM clock ticks and the GPU having access on odd ones. But your approach is another way I'd not thought of before, so I'll be interested to see if there are any downsides to it, other than making it not possible to use a lower resolution mode and reuse the now freed screen space very easily.
FWIW I see the colour change apparently fade to right and down on that video, but I guess that's just the serially connected sensor in your cellphone causing that effect.
I don't think I really have a handle on your GPU yet, though thanks for clarifying how the VGA's wired in. What sort of ASM does it take? And how fast is it clocked?
I think that just about covers everything. Impressive spaghetti there, and I'm glad to see from the video that the inclusion of blinkenlights is proceeding apace. Out of interest, what's that board with the akilter connector that seems to be wedged through the gap between your breadboards (and have you had to cut a slot in your actual bread board to fit it?)