LCDGameModes VIDC20

Discuss LCDGameModes by Steve Harrison
JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

LCDGameModes VIDC20

Post by JonAbbott » Thu Sep 12, 2013 1:19 pm

We need to decide the future of this module so we can sort out native VIDC20 game support - currently it only supports VIDC1 games.

At minimum, we need to rewrite it to use VIDC20 registers.

JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: LCDGameModes VIDC20

Post by JonAbbott » Wed Dec 18, 2013 10:01 am

JonAbbott wrote:We need to decide the future of this module so we can sort out native VIDC20 game support - currently it only supports VIDC1 games.

At minimum, we need to rewrite it to use VIDC20 registers.
Are you going to implement a VIDC20 native version of LCDGameModes? I wonder if it's worth making it support both VIDC1 and VIDC20 in the same module, it's fairly easy to detect if VIDC20 is present from legal OS calls.

steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: LCDGameModes VIDC20

Post by steve3000 » Thu Feb 06, 2014 11:03 am

JonAbbott wrote:Are you going to implement a VIDC20 native version of LCDGameModes? I wonder if it's worth making it support both VIDC1 and VIDC20 in the same module, it's fairly easy to detect if VIDC20 is present from legal OS calls.
Been thinking about this.

How would a VIDC20 version of LCDgm actually work?

Currently LCDgm works by monitoring Service_ModeChange and Service_ModeExtension on VIDC1 computers and after a TV resolution mode has been entered, it patches the necessary registers (VCR, CR, etc.) to suitable values for VGA/LCD screens.

When running under ADFFS, LCDgm works on VIDC20 by virtue of the VIDC1 translation. If a VIDC1 game enters a TV resolution mode and patches it for overscan by setting VIDC1 registers, ADFFS catches these and LCGgm issues its LCD patches using VIDC1 parameters, which ADFFS also catches.

But on native VIDC20 with VIDC20 software there is no need for this. As far as I know, there are no VIDC20 mode extension modules in existence (other than my "AnyMode" programme, which is RPi only) and I'm not aware of any game that patches VIDC20 registers to achieve overscan - everything is now done by mode definition files, and even then there were very few VIDC20 games which used specific overscan mode definitions.

So would LCDgm on VIDC20 still be patching VIDC1 mode extensions? And if so, how?

Options:
1) First thought, as an immediate "LCDgmVIDC20", I could provide a pre-patched VIDC20 mode definition file for all standard TV resolution modes (9, 13, 12, 15 etc), I've already tested this and it gives nice square, LCD-compatible low resolution modes on the Risc PC. It won't solve VIDC1 overscan modes provided in extension modules, but it will work for the large number of games which generate overscan by selecting a standard TV mode and setting HCR/HDSR/HDER for overscan, since ADFFS will still catch those VIDC1 registers and translate them - this should work at least as well as the current combination of LCDgm-under-ADFFS.

2) Next step up from the above, is to include the pre-patched VIDC20 TV resolution modes as a VIDC20 compatible mode extension module, this avoids need for users to add a new mode definition file...however I don't know which would have priority - the original mode definition file, or the extension module - need to check.

3) Long term option...would be for LCDgm or another module, to detect VIDC1 mode extension modules as they load, then patch their extensions to be VIDC20 compatible and LCD compatible. This would be a lot more work and I'm not quite sure as yet on a good way to do the detection as the module loads...I suspect we'd have to scan all mode numbers 32-127 for extensions each time any module loads, which could be s....l....o....w....

Thoughts?
Steve

JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: LCDGameModes VIDC20

Post by JonAbbott » Thu Feb 06, 2014 1:42 pm

We simply need the module to check if VIDC20 is present when it's loaded and write VIDC20 registers instead of VIDC1 registers, so it's not dependent on ADFFS.

ADFFS already handles type 0/1 mode extensions, feel free to lift the code if you want to add it to LCDgm, it's in adffs.service. It does however rely on writing to VIDC1 and ADFFS translating it, so you'd need to pass the values though VIDC1>20 translation first. If you go that route, I'll remove it from ADFFS so we're not duplicating. Apart from the translation bit, you could literally drop it straight into LCDgm, you'd need _modeextension and _modeextension_callback and drop the "existing_DataAbort" check in _modeextension.

To implement type 0/1 it intercepts Service_ModeExtension, re-raises the call and checks if it was claimed. If it was claimed (ie rejected by RISCOS) it raises a CallBack to manually process the registers.

steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: LCDGameModes VIDC20

Post by steve3000 » Thu Feb 06, 2014 3:21 pm

JonAbbott wrote:We simply need the module to check if VIDC20 is present when it's loaded and write VIDC20 registers instead of VIDC1 registers, so it's not dependent on ADFFS.
Ok, this can be done, but there is a real probability that the behaviour will be different to as it is now, since we'll have LCDgm updating VIDC20 registers in response to Service_ModeChanged, which may be at different times to ADFFS doing its VIDC1->VIDC20 translation. So I really need to understand how ADFFS interacts with mode translation and LCDgm, or we could end up in a mess here.
JonAbbott wrote:ADFFS already handles type 0/1 mode extensions, feel free to lift the code if you want to add it to LCDgm, it's in adffs.service. It does however rely on writing to VIDC1 and ADFFS translating it, so you'd need to pass the values though VIDC1>20 translation first. If you go that route, I'll remove it from ADFFS so we're not duplicating. Apart from the translation bit, you could literally drop it straight into LCDgm, you'd need _modeextension and _modeextension_callback and drop the "existing_DataAbort" check in _modeextension.

To implement type 0/1 it intercepts Service_ModeExtension, re-raises the call and checks if it was claimed. If it was claimed (ie rejected by RISCOS) it raises a CallBack to manually process the registers.
Ok, so to check my understanding: ADFFS detects any Service_ModeExtension, then reissues this itself to check for a claim. If claimed, it then checks for the old format of extension (0 or 1), and if 0 or 1, issues a CallBack to fire off the translated registers to VIDC20. Does ADFFS also issue a formal mode change before updating VIDC20 registers? If not, how do the mode variables/VDU variables get updated? I'm just after a few pointers - so I know what I'm looking for when I take a close look at the source later.

Also, does LCDgm kick in properly for these intercepted mode extensions? I can imagine it might not, since it responds to Service_ModeChanged and even if ADFFS is issuing a mode change, it won't be to the final mode as the registers won't have been translated until the CallBack occurs, unless LCDgm's VIDC1 register changes are being cached by ADFFS?

JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: LCDGameModes VIDC20

Post by JonAbbott » Thu Feb 06, 2014 5:17 pm

steve3000 wrote:Ok, this can be done, but there is a real probability that the behaviour will be different to as it is now, since we'll have LCDgm updating VIDC20 registers in response to Service_ModeChanged, which may be at different times to ADFFS doing its VIDC1->VIDC20 translation. So I really need to understand how ADFFS interacts with mode translation and LCDgm, or we could end up in a mess here.
It shouldn't be any different to how it is now, I'm fairly certain we used the same translation. We'll soon know, as the screen will be wrong on one of the test games we were using when we coded the translation.
steve3000 wrote:Ok, so to check my understanding: ADFFS detects any Service_ModeExtension, then reissues this itself to check for a claim. If claimed, it then checks for the old format of extension (0 or 1), and if 0 or 1, issues a CallBack to fire off the translated registers to VIDC20.
You understand correctly :)
steve3000 wrote:Does ADFFS also issue a formal mode change before updating VIDC20 registers?
It does. It mirrors RO behaviour in that it changes to the base mode first and then writes the VIDC1 registers.
steve3000 wrote:Also, does LCDgm kick in properly for these intercepted mode extensions?
It does and was tested on all games I could find that issued Service_ModeExtension and ran on RO3.5+. The list of games that use the service is rather small.

hmm...Paradroid 2000 uses it when it starts a level - that may explain why it crashes on the Pi...will fix that later.

steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: LCDGameModes VIDC20

Post by steve3000 » Thu Feb 06, 2014 8:41 pm

Good stuff. I'll get going with this at the weekend - first will be simple VIDC20 support and patching, I won't add the Service_ModeExtension code yet, let's just make sure it's all working.

I'm sure our translation is the same, thinking about it... But the CallBack might be a problem. If LCDgm responds to the Service_ModeChanged by immediately patching the VIDC20 registers, this will happen before ADFFS has sent through the VIDC1 translations (which happens after the mode change has completed and control has returned to ADFFS), so ADFFS will then reset the VIDC20 registers patched by LCDgm. I suppose if this does happen, then we'll just have to proceed to move the Service_ModeExtension translation code into LCDgm and manage it all in the one module. Probably best all in one place anyhow :)

Next up after that will be patching those mode extension modules to work on RO5, and avoid VIDC1/20 dependency. I already have an idea on that one, as I have a short piece of code which will translate from format 0/1 to format 3...then just need to add a "TV-resolution-to-LCD" patch... But then we will need to get 26bit modules working somehow before this is useful.

JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: LCDGameModes VIDC20

Post by JonAbbott » Fri Feb 07, 2014 9:04 am

steve3000 wrote:But the CallBack might be a problem. If LCDgm responds to the Service_ModeChanged by immediately patching the VIDC20 registers, this will happen before ADFFS has sent through the VIDC1 translations (which happens after the mode change has completed and control has returned to ADFFS), so ADFFS will then reset the VIDC20 registers patched by LCDgm. I suppose if this does happen, then we'll just have to proceed to move the Service_ModeExtension translation code into LCDgm and manage it all in the one module. Probably best all in one place anyhow :)
Isn't that how LCDgm works anyhow? Game changes MODE, LCDgm patches it, game updates VIDC1. The test games certainly worked the last time I tried them.
It certainly makes sense to move the Service_ModeExtension code into LCDgm as it will allow you to extend it RiscPC games.
steve3000 wrote:Next up after that will be patching those mode extension modules to work on RO5, and avoid VIDC1/20 dependency. I already have an idea on that one, as I have a short piece of code which will translate from format 0/1 to format 3...then just need to add a "TV-resolution-to-LCD" patch... But then we will need to get 26bit modules working somehow before this is useful.
Suggest we leave that for the time being, at least until we have some games that use it working under the JIT. ADFFS will intercept any writes to VIDC1 / 20 whilst the JIT is running anyhow. I don't think there's any requirement for native RO5 support as there's no native games that require it, they're all going to be 26bit games.

26bit modules are next on my list after I have the IOC T1 emulation working, it's coded and just needs debugging/testing. I also need to extend the blitter to support mid-frame palette changes, unless you'd like to pick that up along with extending it to take account of VIDC parameters. 8 bpp may be fun requiring separate code which could be added at a later date, 4 bpp is the priority.

steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: LCDGameModes VIDC20

Post by steve3000 » Sat Feb 08, 2014 10:25 am

JonAbbott wrote:Isn't that how LCDgm works anyhow? Game changes MODE, LCDgm patches it, game updates VIDC1.
Yes, but in the back of my mind I thought that ADFFS cached the VIDC1 writes for translation, and fired them off together to VIDC20 at the same time? This would be slightly different behaviour. But we'll see if it works soon enough...
JonAbbott wrote:I also need to extend the blitter to support mid-frame palette changes, unless you'd like to pick that up along with extending it to take account of VIDC parameters.
Yes, I can have a look at that - I've already done something similar. If you've seen the latest !QTMdisply, picture here, you'll see this runs in Mode12, but on the RPi it's converted through my 4bpp to 32bpp converter and here I've included raster-level accurate palette redefinition. The test is the VUbars on the RPi - which are in fact solid, single-colour, rectangles, with palette changes on each line :)

JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: LCDGameModes VIDC20

Post by JonAbbott » Sat Feb 08, 2014 12:45 pm

steve3000 wrote:in the back of my mind I thought that ADFFS cached the VIDC1 writes for translation, and fired them off together to VIDC20 at the same time? This would be slightly different behaviour. But we'll see if it works soon enough...
What I normally do when hijacking RISC OS code, is to look at the original RISC OS source code, then either mirror it or it's behaviour. I don't recall if I did in this case, but I certainly tested it on the test games. If you discover any issues, I'm sure we can easily rectify them by moving the code into LCDgm.
steve3000 wrote:I can have a look at that - I've already done something similar.
Great, that takes a whole chunk of coding off me so I can concentrate on IOC and the JIT. I documented the changes required, whilst it was fresh in my mind, which you've now seen.
steve3000 wrote:If you've seen the latest !QTMdisply, picture here, you'll see this runs in Mode12, but on the RPi it's converted through my 4bpp to 32bpp converter and here I've included raster-level accurate palette redefinition.
I'm afraid I haven't tried it yet, I've literally been coding the JIT from 8am through to 2-3am every day since the beginning of Dec, so haven't had much time for anything.
In hindsight, it would have been easier to code a true hypervisor and run RISC OS 3 within it. This was my original intention to avoid all the SWI issues, after a conversation with Aaron Timbrell however, it was clear that the distribution of RISC OS 3.1x ROM's wasn't that straightforward, as although 3QD has a contract with Pace, it didn't necessarily allow JASPP to get rights from 3QD. I'd certainly like to code a full hypervisor, for the technical challenge more than anything. Anyhow...I digress.

Post Reply