Wow, quite some ideas there!
rv6502 wrote: ↑Fri Jun 28, 2019 5:18 am
How about a 9th color pin that forces the output to white?
bst/bld could be used with that pin to add some kind of overlay for cheap, or quicker 1bpp output.
I don't see too much point in doing that as I already have a 2.25 cycles / pixel 1bpp mode with arbitrary FG / BG colour for each scanline. That's up to some 400 pixels width! You could only do better than that by clocking pixels out using UART in SPI master mode (2 cycles per pixel I think), but that again would be fixed colours. Without that going higher in resolution than 2.25 cycles / pixel is not possible as you need loads and jumps, which enforce some 3 clocks wide pixels. Primarily this 2.25 cycles / pixel mode is designed to go along with the 4.5 cycles / pixel 4bpp mode (for a similar effect to mixing high-resolution text and Multicolour on Commodore 64).
rv6502 wrote: ↑Fri Jun 28, 2019 5:18 am
Allowing a mode where the GPU to do BG(s) and the logic MCU could do sprites, which would take less processing than BGs if timers are used. Leaving plenty for game logic. Bonus: it saves transferring the sprite updates.
This could be interesting! I am envisioning something along the lines of Mode 72 for such, whether it was possible to get the L-MCU preparing a scanline with sprite data, which then can be transferred and merged onto the background in the V-MCU. The greatest benefit would be RAM as otherwise this setup is a freaking powerhouse, to generate a normal Uzebox-style tiled mode, you have about 3-4 times more CPU. The most often you would run out of RAM before hitting the blitting bottleneck, especially if you wanted all the graphics to be loaded from SD. Which you would have to keep in the L-CPU's RAM as well to blit sprites. So if such a mode could be devised, that would save RAM (as background would only have to be placed on the V-CPU). CPU not so much since such a mode takes away all the display frame time with no frame drop (30FPS) option.
I will definitely look into this, without hardware mods. We certainly have the transfer bandwidth, the greater unknown being whether it was possible to code such on the V-CPU.
SPI, I am a bit uncertain on this one. I purposely chose the way Uzebox does it as it allows reusing the programmer pins to communicate with the SD card, and it works quite fine. The SD card otherwise is a real mess, giving lots of headache even when interfacing the SPI RAM on Uzebox. I wouldn't really want to share at least the MISO (which the card can affect) with anything.
Gamepads are fine scanned slow, in the Uzebox kernel, it is normally a tightly timed code, however in Flight of a Dragon, the new bootloader, and other kernel experiments, I set them up to be clocked from the HSync interrupt. This allows these programs to work with wireless SNES controllers (at least as it was reported, they are apparently slow). There are only a few bits to clock in, so no real latency. On the MicroDuo, I would similarly add the code to the L-CPU's audio engine. So with them I am also a bit reluctant on sharing, due to the uncertainties related to those wireless SNES controllers (such as even whether they could be messed up by "foreign" data on their lines from the SD card when communicating with the SD card).
Otherwise it might be interesting to experiment with using the SCK and MOSI for other things beyond the SD card (when the SD's Chip Select is high), but again, the programmer could be in the way. Probably not that much like I envision, though, and they could be used for some things. Maybe to communicate with an alphanumeric LCD panel, that could be a fun optional item only needing the out direction
Protection resistors, definitely not a bad idea of course if you worry about getting them driving each other! I purposely plan towards fixed directions though. The 16 lines always L-CPU => V-CPU, communicating back data would be slow bit banging by the few control signals (rare utility, and this case I would say better be safe than sorry). So the software provided with the MicroDuo would be designed to minimize the chance of such happening even if you built the most bare-bone minimalistic HW for it.