SPI RAM Mode74 development

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI RAM Mode74 development

Post by D3thAdd3r »

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.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI RAM Mode74 development

Post by Jubatian »

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?
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.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: SPI RAM Mode74 development

Post by CunningFellow »

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.
figure2c-full.jpg
figure2c-full.jpg (37.75 KiB) Viewed 5462 times
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?
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI RAM Mode74 development

Post by Jubatian »

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.
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?
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.
Post Reply