I suppose there really is no need as one could always check the vsync flag before the operation and after to determine if it was interrupted. Redo it if so. The use case I mean just for streaming in some data which needn't all be in 1 frame, as cycles allow.
For SD access is it possible to break it into small enough parts that a screen disable is not required? Like prepare a sector read, disable the card and draw the frame, re-enable the card(is the last command still active or must everything start over?), read some stuff bytes then a sector, before disabling it before next frame?
The 2bpp mode sounds very powerful. I would love to see that approach taken in an Uzebox game, then there are so many extra capabilities at that point it could be beyond what we would normally think of fitting into a game.
SPI RAM Mode74 development
Re: SPI RAM Mode74 development
I wouldn't recommend this. Remember that until I figured it out, we couldn't even use the SPI RAM and the SD card together. The card is very picky on its protocol, and might end up in a state requiring a complete reinitialization if its access deviates from the standard, and until that, it can also make the SPI RAM inaccessible. So I would suggest to make provisions that the SD card's access is not broken by keeping the video mode disabled during it (which normally won't cause anything visible when the access finishes within the VBlank). You should be able to perform a complete sector read in a VBlank even with the bootloader API library.D3thAdd3r wrote: ↑Sat May 05, 2018 8:44 pmFor SD access is it possible to break it into small enough parts that a screen disable is not required? Like prepare a sector read, disable the card and draw the frame, re-enable the card(is the last command still active or must everything start over?), read some stuff bytes then a sector, before disabling it before next frame?
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: SPI RAM Mode74 development
The AmstradCPC had only 4 colours in its medium resolution mode.
You can make some nice looking games in 4 colours. Head over Heals for example.
I had fleshed out on a spreadsheet a 2Bpp, 5 clock per pixel mode that had 128 RAM and 128 ROM times. It was (similar to T2K) pretty heavy on the flash usage.
@Jubatian - how are you doing the colour decoding? Are you unrolling the decision with IJMP also?
You can make some nice looking games in 4 colours. Head over Heals for example.
I had fleshed out on a spreadsheet a 2Bpp, 5 clock per pixel mode that had 128 RAM and 128 ROM times. It was (similar to T2K) pretty heavy on the flash usage.
@Jubatian - how are you doing the colour decoding? Are you unrolling the decision with IJMP also?
Re: SPI RAM Mode74 development
Sure, those Amstrad high-res games are nice! I especially like the aesthetic of those, not only Amstrad, but also on several other systems. An extreme is the Japanese PC98, which had 8 colors at most, but at a very high resolution for the age, and had seen a lot of quality art.
Yes, I do it that way, but I already have means to reduce flash usage on these modes. Mode 40-41-42 are nice examples of this, you may look into their code to see how extreme size trimming can be achieved (Mode 40 and 41 take some 3 KBytes only, Mode 42 is a bit larger). The new mode by my current estimate will be around 10 KBytes, this includes the capability of having the optional attribute mode.CunningFellow wrote: ↑Sat May 05, 2018 10:34 pmI had fleshed out on a spreadsheet a 2Bpp, 5 clock per pixel mode that had 128 RAM and 128 ROM times. It was (similar to T2K) pretty heavy on the flash usage.
@Jubatian - how are you doing the colour decoding? Are you unrolling the decision with IJMP also?