RiscPC support

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

RiscPC support

Post by JonAbbott » Wed Jun 19, 2013 2:28 pm

Seeing the comments on startdot, we should probably have a dedicated thread on the subject here.

In the most part, games that need LCDgm are RISCOS 3.1 games that directly write to VIDC1 and would go through the VIDC translator code, so are monitor definitions really relevant?

Could we not alter the VIDC translator code to use the type 4 mode definition table and LCDgm stay pretty much as it is?

The last discussion on the subject that I can remember, was that Steve was going to try ADFFS on an ARM610 RISC PC with a monitor that could handle a TV input - to prove the VIDC translator clock code worked correct. Provided there are no issues we should then add the type 4 MODE table in, get ADFFS to auto-select the correct table and turn LCDgm on. It may then work on a standard monitor.

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

Re: RiscPC support

Post by steve3000 » Wed Jun 19, 2013 6:58 pm

JonAbbott wrote:Seeing the comments on startdot, we should probably have a dedicated thread on the subject here.
Good idea.

I've edited from your post below my comments in red, just to make sure I understand the requirements correctly:
JonAbbott wrote:In the most part, games that need LCDgm on the RiscPC are the same RISCOS 3.1 games currently fixed by LCDgm on RO3.1 computers running SVGA monitors, ie. those that directly write to VIDC1 and would go through the VIDC translator code on VIDC20.., so are RiscPC monitor definitions really relevant?
No mode definitions shouldn't be required providing we get the translation code perfect. LCDgm currently patches any change into Modes 9/13/etc. with its full set of VIDC1 mode definition parameters anyway, so it does not rely on the MonitorType 4 table - hence why it works on MonitorType 1, on RO3.1, if you enable it. :)

However, suitable 'LCDgm' mode definition files would be a useful stop-gap for those wanting an improved aspect-ratio display for games that currently work fine without ADFFS/VIDC translation.
JonAbbott wrote:Could we not alter the VIDC translator code to use the type 4 SVGA mode definition table and LCDgm stay pretty much as it is?
I need to look back at the VIDC translator code. As I recall it stores up values to send to VIDC20 in one go? So it should take note of all LCDgm's parameters sent out upon a mode change, and use those, without the need to rely on any table?
JonAbbott wrote:The last discussion on the subject that I can remember, was that Steve was going to try ADFFS on an ARM610 RISC PC with a monitor that could handle a TV input - to prove the VIDC translator clock code worked correct. Provided there are no issues we should then add the type 4 MODE table in, get ADFFS to auto-select the correct table and turn LCDgm on. It may then work on a standard SVGA monitor.
I did get as far as plugging my RPC into the TV monitor and using Arm610, then trying this out... Only to find ADFFS didn't work well on RiscOS 4...

I now have RiscOS 3.70 roms, and they're plugged in/ready to go. Unfortunately I'm working away from home at the moment. I'll be back this weekend, but then away for another 2 weeks. I'll try to redo the TV monitor test this weekend, as the RPC is still sat next to it... :)

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

Re: RiscPC support

Post by JonAbbott » Wed Jun 19, 2013 7:25 pm

Your edits are spot on. There's no rush on this, we just need to know how we're going to implement it and confirm the current clock conversion code works.

Recap on how the translator works:

- Following a MODE change, if it sees a command that isn't Stereo, HCSR, VCSR, VCER, Sound Frequency or a Control Command, it will reset all the VIDC geometry parameters* to the translated RO3.1 native values. Currently this only uses the type 0 TV table, I'll need to extend it to also use the RO3.1 type 4 SVGA table if the RiscPC is set to type 4 SVGA.
- VIDC command(s) are translated immediately on the Abort to the VIDC1 addresses being triggered. It takes account of both STR and STM, so can issue one to N commands in succession.

* Clock rate (VMOD / RMOD / FIFO), HCR, HSWR, HBSR, HDSR, HDER, HBER and VCR, VSWR, VBSR, VDSR, VDER, VBER

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

Re: RiscPC support

Post by JonAbbott » Wed Jun 19, 2013 7:50 pm

Am I correct in presuming that we don't require AutoVIDC and LCDgm will handle setting the clock speeds?

Just concious of the fact that AutoVIDC is VIDC1 specific and LCDgm will need to set the VIDC clock. Note I say VIDC, as it can either be done through translation as a VIDC1 write, or direct to VIDC20...however the order will be critical, the clock will need to be set after ADFFS has seen at least one geometry command so that the MODE is in the RO3.1 native state.

Should I go ahead and code the type 4 SVGA table support? I've got to find the correct table first, which was fun for type 0 TV, as the RO3.1 source is MIA. I think I extracted it from the ROM in the end.

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

Re: RiscPC support

Post by steve3000 » Wed Jun 19, 2013 8:12 pm

Ah ok. So after mode change, if a VIDC1 parameter is set, the translation code pokes in the RO3.1 table settings, followed by the translated parameter? And continues translation as required (without further resetting of parameters) until the next mode change? That won't be a problem for LCDgm, as I said before - it sends out all the settings anyway, so absolutely no table required by ADFFS (but might be worth keeping to allow for situations where LCDgm isn't present?).

You say the translation does not trigger on VIDC1 control register (CR) parameter, but presumably it does still translate the VIDC1 CR divider bits into the VIDC20 pixel rate? That is essential for LCDgm, as this is required to selects the correct pixel rate.

LCDgm does use AutoVIDC to select the VIDC input clock rate and sync polarity settings via the IOC latch. But as this isn't translated or monitored by ADFFS, just assume an input rate of 24MHz and divide using the CR divider bits - and you'll be fine (ie. reflecting an older Archimedes platform) - as that's what LCDgm was designed for.

Presumably the current version of LCDgm will cause an abort when it writes to &3350048 (IOC latch address?) as that isn't translated. So it'll have to be reassembled to ignore the OS check in order to run on RO 3.5+ and will need some code to skip the the clock selection process on OS 3.5+. I'll also have to refresh my memory on how sync polarity is set on VIDC20, I expect it's all in the VIDC20 CR?

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

Re: RiscPC support

Post by JonAbbott » Thu Jun 20, 2013 5:40 am

steve3000 wrote:Ah ok. So after mode change, if a VIDC1 parameter is set, the translation code pokes in the RO3.1 table settings, followed by the translated parameter? And continues translation as required (without further resetting of parameters) until the next mode change? That won't be a problem for LCDgm, as I said before - it sends out all the settings anyway, so absolutely no table required by ADFFS (but might be worth keeping to allow for situations where LCDgm isn't present?).
Correct, it writes all settings followed by the translated one sent. LCDgm will always be present, so I'll drop the VIDC table and relevant code. That makes things even easier, it should all just work once I've made that change - in theory!
steve3000 wrote:You say the translation does not trigger on VIDC1 control register (CR) parameter, but presumably it does still translate the VIDC1 CR divider bits into the VIDC20 pixel rate? That is essential for LCDgm, as this is required to selects the correct pixel rate.
CR is translated, you might recall the weeks I spent writing code to work out VMOD RMOD and FIFO on the fly. This is the bit you were going to verify on your RPC, so we could then sort out the RPC type 4 SVGA support.
steve3000 wrote:LCDgm does use AutoVIDC to select the VIDC input clock rate and sync polarity settings via the IOC latch. But as this isn't translated or monitored by ADFFS, just assume an input rate of 24MHz and divide using the CR divider bits - and you'll be fine (ie. reflecting an older Archimedes platform) - as that's what LCDgm was designed for.

Presumably the current version of LCDgm will cause an abort when it writes to &3350048 (IOC latch address?) as that isn't translated. So it'll have to be reassembled to ignore the OS check in order to run on RO 3.5+ and will need some code to skip the the clock selection process on OS 3.5+. I'll also have to refresh my memory on how sync polarity is set on VIDC20, I expect it's all in the VIDC20 CR?
AutoVIDC wont be present on RO3.5+ and writing directly to the IOC latch will cause an abort as you say. Do I need to add an SWI into ADFFS for you to set the VIDC20 clock rate? ADFFS currently sets the VIDC20 clock to the RO3.1 clock rate for the MODE it's currently in, although I'll obviously remove that code when removing the VIDC parameter MODE table, so LCDgm will need to set the clock if its different from the default RPC clock for the MODE it's in.

The VIDC20 PDF is on the dev site, I'm not sure on sync polarity either. I'll do some reading later.

Actions are:

1. Recompile LCDgm to load on RO3.5+ and skip IOC latch code. Put the upper limit at <RO 5.0
2. Remove the VIDC parameter table and any associated code from ADFFS
3. TBC: Add an SWI into ADFFS so LCDgm can set the clock?

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

Re: RiscPC support

Post by steve3000 » Thu Jun 20, 2013 6:22 pm

JonAbbott wrote:ADFFS currently sets the VIDC20 clock to the RO3.1 clock rate for the MODE it's currently in, although I'll obviously remove that code when removing the VIDC parameter MODE table, so LCDgm will need to set the clock if its different from the default RPC clock for the MODE it's in.
Ok that may or may not be a problem. LCDgm needs 24MHz, divided to 16MHz for Modes 9/13, at the moment. Although 36MHz, 25MHz, or a RiscPC specific clock speed are potential for future.

So on the above assumptions, the current ADFFS uses monitortype 0 table so will be selecting 24MHz - which is fine. If you update to using the SVGA table, that will use 25MHz, which will through LCDgm out of alignment a little.

Do you trap the SWI vector by default? One thought could be for you to implement a slightly modified SWI AutoVIDC_ClockAvailable and SWI AutoVIDC_SetClock, and then LCDgm will work seamlessly.

Code: Select all

AutoVIDC_ClockAvailable (SWI & 59386)
On entry R0 = clock speed in kHz (e.g. 25175) or 0-3 to read the oscillator speed in that slot
On exit  R0 = -1 if not available or R0 = slot number (currently 0 to 3) if available and R1 = Clock speed in kHz

AutoVIDC_SetClock (SWI & 59380)
On entry R0 = slot number to select (currently 0-3)
On exit  R0 = current slot number (0-3)
LCDgm will always call AutoVIDC_ClockAvailable followed by AutoVIDC_SetClock with the result. (This as the most future proof method, and it also allows Paul the future possibility of setting up AutoVIDC to cope with enhancers that have the clocks attached to the Aux port in any random order, ie. not relying on what 0-3 are).

So on RiscOS 3.5+ ADFFS could implement SWI AutoVIDC_ClockAvailable in a dummy form, always returning R0 preserved (ie. = clock speed), then as a result LCDgm will call AutoVIDC_SetClock with R0=clock speed, and at this point ADFFS can store that speed as its current 'VIDC clock' variable. When the next VIDC1 CR setting is received by the translator, your code will calculate the intended pixel rate using the new clock speed and the CR divisor bits, and set the VIDC20 oscillator accordingly.

Hope that makes some kind of sense?

(Paul could even expand AutoVIDC_SetClock to allow R0=clock speed, as well as 0-3, in his module. So when SetClock is called with R0>3, it would call ClockAvailable itself to get the slot number, and return an error if the clock isn't present... just a thought for RO3.1 machines :) )

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

Re: RiscPC support

Post by JonAbbott » Thu Jun 20, 2013 9:08 pm

steve3000 wrote:Do you trap the SWI vector by default? One thought could be for you to implement a slightly modified SWI AutoVIDC_ClockAvailable and SWI AutoVIDC_SetClock, and then LCDgm will work seamlessly.
No problem.
steve3000 wrote:So on RiscOS 3.5+ ADFFS could implement SWI AutoVIDC_ClockAvailable in a dummy form, always returning R0 preserved (ie. = clock speed), then as a result LCDgm will call AutoVIDC_SetClock with R0=clock speed, and at this point ADFFS can store that speed as its current 'VIDC clock' variable. When the next VIDC1 CR setting is received by the translator, your code will calculate the intended pixel rate using the new clock speed and the CR divisor bits, and set the VIDC20 oscillator accordingly.
Is this necessary? ADFFS doesn't track the clock speed, the only parameter it needs to track is BITS/pixel so it can set CR on VIDC20. If you write CR to VIDC1 with the pixel rate set at 24MHz, ADFFS will set VIDC20 to 24MHz.

Obviously, if you need clocks above 24MHz we'll need an SWI to set it.

I've implemented both anyhow and removed the code that sets all the VIDC20 geometry, ADFFS 2.16 module is on the dev site. I've not done any testing as we'll need LCDgm modified first, I can then test under emulation to ensure the VIDC20 geometry is correct. Once we've confirmed that, we can check it on a physical monitor to ensure the pixel rate is correct.

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

Re: RiscPC support

Post by steve3000 » Thu Jun 20, 2013 10:28 pm

JonAbbott wrote:Is this necessary? ADFFS doesn't track the clock speed, the only parameter it needs to track is BITS/pixel so it can set CR on VIDC20. If you write CR to VIDC1 with the pixel rate set at 24MHz, ADFFS will set VIDC20 to 24MHz.
Ok maybe wires are crossed here, but we need to be sure on this one.

AutoVIDC_SetClock is used by LCDgm at the moment to select 24MHz only (in a future version will also make use of 25MHz and 36MHz - this is underway, but not ready for release as I haven't designed all the modes yet). Those are the only input clock speeds used by LCDgm as they are the only available speeds on RO 3.1.

However pixel rate is defined by the VIDC1 CR.

So with AutoVIDC set to 24MHz, the pixel clock is then set by VIDC1 CR to 8 / 12 / 16 or 24MHz.

Likewise, if AutoVIDC is set to 36MHz, the pixel clock can be set by CR to 12 / 18 / 24 or 36 MHz.

So ADFFS must be tracking the two settings - input clock speed and CR divisor bits for pixel clock?

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

Re: RiscPC support

Post by JonAbbott » Thu Jun 20, 2013 11:04 pm

The clock is fixed on VIDC20 and the pixel rate is based on a divisor and modulus of it. The clock rate isn't really relevant to LCDgm on VIDC20, you just need to let ADFFS know what pixel rate you want and it will work out the divisor, modulus and FIFO settings based on the reference clock.

I coded AutoVIDC_SetClock to take the pixel rate, but obviously if you then write CR it will change, in this scenario CR doesn't need to be set, or if it is, it should be done before using AutoVIDC_SetClock. It sounds like I need to modify this to take the VIDC1 clock and then work out a divisor to adjust the reference VIDC20 clock, to end up with the final pixel rate. Obviously a lot messier than just asking for the pixel rate you want ;)

Post Reply