forums.jaspp.org.uk

JonAbbott wrote:I did try adjusting VCSR for Caverns, but it makes no difference. It's as if the hardware is programmed to only start displaying the cursor at a certain raster.

If I reduce VCSR the ship appear further up the screen, but from the same position in the ship. This leads me to think that perhaps the start address of the cursor is incorrect or it's being copied to the OS cursor area, which has moved slightly. I doubt its using official methods to set the cursor, as I believe they're restricted to 32 pixels in height.

A give away is that if you increase VCER you see part of the OS mouse cursor...implying Caverns has copied the cursor over the OS area and simply has the wrong address. If this is the case, we've either got to set Cinit (MEMC) to the RO3.1 address or fixup Caverns as it loads to use the new OS address.

Anyone know what the address is on RO3.1 or 3.5+?

steve3000 wrote:I would prioritise the Service_ModeExtension patch, as this will give access to more overscan games and also will allow us to generate test extension modules with !customvdu - for specific testing.

I've got to figure out how to capture Service_ModeExtension in a way that doesn't affect its normal operation.

EDIT: Done some memory browsing, it looks like the mouse cursor is at 1F03800 on both RO3.1 and RO3.71 (it looks like the cursor at any rate!), so its unlikely it's overwriting the OS cursor directly.

EDIT2: Spoke too soon, Caverns is overwriting the cursor by directly writing to 1F03800, (GameCode offset 4ABE8)

JonAbbott wrote: I've got to figure out how to capture Service_ModeExtension in a way that doesn't affect its normal operation.

Thought on this - trap the SWI OS_ServiceCall... Now I'm not sure RISC OS actually calls the SWI when VDU 22 is issued to select an unknown mode... the other equally likely option is RISC OS just issues a service call directly to the modules - but if it does call the SWI, then it's easy.

After trapping, call OS SWI routine and upon return from the SWI, before handing control back to OS, check if the mode number has been claimed, if so, examine the VIDC block and if VIDC1 then make a copy, and convert to the VIDC20 format block then hand back...

If RISC OS doesn't call SWI OS_ServiceCall then it's more tricky... You'd need to monitor the Service Calls from ADFFS module Service entry point... But even then it's not straight forward...

steve3000 wrote:Thought on this - trap the SWI OS_ServiceCall...

The only viable option I can think of, is to reimplement the service call to all modules when we see the OS call us. If we get a type 0/1 back, we claim the call and translate.

Provided the OS calls modules in load order, we can be absolutely certain that the module will be after us in the stack.

I'll try coding it and see what happens.

JonAbbott wrote:Provided the OS calls modules in load order, we can be absolutely certain that the module will be after us in the stack.

Now I may be wrong but I was always under the impression that newly loaded modules are called first before older modules. How RO3.5+ handles this and how it deals with modules which claim ModeExtension but return an old format block (does it reissue call to all remaining modules?) I'm not sure...but worth a quick check if you code a test routine.

steve3000 wrote:Now I may be wrong but I was always under the impression that newly loaded modules are called first before older modules.

If that is the case, we're screwed.

JonAbbott wrote:

steve3000 wrote:Now I may be wrong but I was always under the impression that newly loaded modules are called first before older modules.

If that is the case, we're screwed.

Lol! I'm sure we can find a way, especially with the RO source code to trawl through

steve3000 wrote:Lol! I'm sure we can find a way, especially with the RO source code to trawl through

It will probably be easier to detect the mode extension module loading and load our own.

We could alternatively add a *command to ADFFS to create custom modes and simply avoid modules altogether. We're only talking about a few games anyway...currently 2 unless more pop up.

JonAbbott wrote:The only viable option I can think of, is to reimplement the service call to all modules when we see the OS call us. If we get a type 0/1 back, we claim the call and translate.

Provided the OS calls modules in load order, we can be absolutely certain that the module will be after us in the stack.

This should actually work thinking about it, LCDGameModes wouldn't work currently if it didn't see the Service_ModeExtension call. From the look of the LCDgm code, it falls through to use mode9 as a base setting and alters it based on the bits/pixel of the current mode. Or, is 0.22 different to 0.21 / 0.23?

Without integrating LCDgm back into ADFFS, how should I pass trapped ModeExtension's onto it? Or should we shift the ModeExtension code into LCDgm?

JonAbbott wrote:This should actually work thinking about it, LCDGameModes wouldn't work currently if it didn't see the Service_ModeExtension call. From the look of the LCDgm code, it falls through to use mode9 as a base setting and alters it based on the bits/pixel of the current mode. Or, is 0.22 different to 0.21 / 0.23?

LCDgm acts on Service_ModeChanged, which is issued after the mode change is complete.

This is the problem - the mode change won't actually happen if the Service_ModeExtension is not already translated and converted to VIDC20.

Good question though as to where this code should be.

LCDgm would need to be VIDC20 compatible if it is to correctly cope with VIDC20 mode extension modules. However RO3.5+ games, as far as I'm aware, don't use mode extension modules, they just add a new mode to the mode defn file if required - in fact I don't know of any game/demo/software which uses RO3.5+ VIDC20 mode extension modules... So I'm not sure we need to go as far as supporting VIDC20 from LCDgm - in which case we're back to having ADFFS detect VIDC1 extension modules, translate them, and then provide some way for LCDgm to ask ADFFS to return a VIDC1 CR value, which LCDgm can use.

steve3000 wrote:LCDgm would need to be VIDC20 compatible if it is to correctly cope with VIDC20 mode extension modules.

We don't need to worry about RO3.5+ MODE extension modules as they should be compatible with SVGA anyhow. It's just the RO3.1 ones we're worried about.

I'll create an SWI "ADFFS_VIDCCR" and return a VIDC1 style CR. It wont be a complete CR, as DMA isn't relevant for example, but will have the clock and bits/pixel. We can use that instead of poking around in ZP for the CR, as ADFFS can track it during writes and MODE changes.

So, the sequence will be:

1. Game loads MODE extension module
2. Game changes MODE
3. RO polls modules
4. ADFFS re-poll the modules to get the MODE extension table (need to determine if this works)
5. ADFFS updates its copy of the CR to match the bits/pixel and VIDC clock ... taking account of type 1 extensions.
6. ADFFS changes to the base MODE
7. LCDgm picks up the MODE change
8. LCDgm queries ADFFS for the CR and does it's thing
9. ADFFS writes the VIDC values from the MODE extension to the VIDC1 address, triggering translation