D3thAdd3r wrote: ↑Sat May 05, 2018 6:27 pmOne thing I did not notice anywhere, is there some method for reading and writing from/to SPI Ram that would cooperate with the kernel's scanline reads? I was hoping to find some mechanism where a volatile variable could indicate if the SPI Ram is busy, and also if a user operation was interrupted if for instance taking too long in a user callback. Not sure if it would be some general purpose thing or not, but if it were possible to schedule these things for the kernel to do it safely, it could be quite handy.
There is no such thing as there is no real use for it. Mode 748 accesses SPI during the full frame, so you have to do your SPI stuff between frames. In VBlank the mode leaves SPI alone. Since the M74 blitter has no automatic sprite render capability, that neither can cause any trouble: SPI will be accessed when you blit sprites from your main program, and not any other time. If you happen to be interrupted by a video frame, the video frame will cancel any pending SPI access, so video will always be fine (and only your main program SPI access will be broken, which is a tolerable outcome for blitting sprites from SPI RAM). The video frame can not be delayed at all, so nothing really can be done there. I imagined one would turn the display off for the duration of SD accesses, as with the SPI RAM present, one could load assets for a scene in one pass. If you still wanted to display something, such as a loading bar, you could do a safety toggle of the Mode 748 display enable flag: Wait Vsync, then on the beginning of the VBlank you turn it off, you do the critical SPI task, then turn it on. If for any reason the critical task couldn't finish in the VBlank (for example a very unlucky slow read from SD), you only get a frame of blank screen without breaking your SPI task (Toggling M748 Display Enable is perfectly okay, M748 even has a disabled screen color feature: it just causes M748 to output empty rows, not affecting the kernel at all. This case of course the mode leaves SPI alone).
2bpp: Yes, something like that, I even programmed the original GameBoy for a little (displayed some images on it). There are diverse possibilities here, the current 5 cycles / pixel scanline code is capable to optionally have an attribute source (so one color can be replaced for every tile if you want), and it can also set an arbitrary split between ROM and RAM tiles from a register (so you can even change between scenes depending on what you need). 64 RAM tiles take only 1K, and at that point if they are used for sprite targets, likely a CPU bottleneck will be near (blitting capability, I don't know yet how it would relate with the M74 blitter, whether it could be faster or would be slower). For a single screen scene (No attributes used, 1K VRAM + 1K RAM tiles), this could even permit reserving some RAM for sprites loaded from SD.