You will have no time in HSync to do extra VRAM accesses unless you drop the inline mixer. The mode however could be compatible with music streaming from SPI RAM as for reading the VRAM, it needs to send an address (so each scanline is a complete SPI transaction, in the spare HSync time, you can access something else, but to send an address and do anything meaningful, that's already 100 cycles).D3thAdd3r wrote: ↑Thu Sep 07, 2017 4:55 pmQuite nice, and 16bit vram could allow a lot more flexibility in tilesets which might help save flash. I guess if sprite blitting is not too effected, that is the ultimate.
Do you think it is possible to squeeze code in the HSYNC with the existing channels, something to give user access to vram? Or perhaps it is best to build into the scanline giving up some width but keeping max sound/UART options? Even if it was nothing more than a circular buffer where it sent 1 raw user byte to SPI per line, it seems it can work. All time requirements are easily met with a scanline in between each one at least. Perhaps even the old UserHsyncCallback() idea could allow the choice of different short asm routines to fit the requirements of the game, and allow a lot of customization without being a different video mode or submode.
User HSync callbacks (of course assembly only) could be introduced, but they will be a bit tight. Almost every video mode have the inline mixer, usually above 200 clocks for it. With 4 channels (167 clocks), usually there should be enough time to do something of use. I will possibly do inline mixer optimizations later to trim this down (like I did in FoaD). It has no great uses though on the Uzebox as for example in Mode 3, you really can't do anything with video (the VRAM has RAM tiles on it, you can't move around sprites since they are blitted, there is no palette to mess around with). Mode 74 has most conceivable possibilities supported through RAM arrays (such as replacing colors in the palette, generating the sky in Flight of a Dragon).
What would you like to do by the way?
(Scrolling and similar stuff shouldn't be required as the SPI RAM should be large enough to hold a scene, otherwise loading stuff from SD or depacking from SPI RAM to SPI RAM VRAM would be something possibly too complex to be anything useful within HSync)