- Site Admin
- Joined: 19 Oct 1999
- Posts: 14741
- Location: London
|
Detecting VDP mode 4 availability
Posted: Sun Jul 04, 2021 9:44 am
|
I was thinking about adding support in ZEXALL for the earlier systems, by adding support for a TMS9918a mode. However, it seems it would be nicest to automatically detect this scenario. I know I could simply detect the RAM size but it seems it’d be nicer to detect the mode 4 capability before using it. What’s a good way to do that?
I was thinking of maybe using sprite collision, but I’m not sure how the legacy modes would interact with the mode 4 sprite table data. I don’t have a system to test on. Any suggestions?
|
- Joined: 24 Mar 2021
- Posts: 120
|
Posted: Sun Jul 04, 2021 6:59 pm
|
Looks like the simplest difference is that the TMS9918-based systems don't have the V counter, and trying to read from it will instead just write garbage to the PSG.
|
- Joined: 16 Mar 2018
- Posts: 29
- Location: Indiana
|
Posted: Mon Jul 05, 2021 2:42 am
|
I was also thinking of doing that and just started reading up on the TMS video modes. Was having the same questions on if it could be auto detected or not.
|
- Site Admin
- Joined: 19 Oct 1999
- Posts: 14741
- Location: London
|
Posted: Tue Oct 12, 2021 12:18 pm
|
Well, I have done the work but it turns out the detection fails on Meka at least - it has a functional line counter in SG-1000 mode.
Setting a "typical" mode 4 register setup on a TMS9918a is interpreted as mode 0. If we then set our mode 4 sprite table at address $3f00, with bit 0 of register 5 set, then TMS9918a mode will interpret it as a sprite table at $7f80. Thus we can put some sprites at x = 208 and an SMS VDP will render them (and we can place multiple sprites and see the overflow status); but a TMS9918a will see a sprite table terminator and draw no sprites.
This seems to work well in Meka and Emulicious, at least.
|