RiscPC support

Discuss LCDGameModes by Steve Harrison
Post Reply
PaulV
Posts: 97
Joined: Thu May 02, 2013 8:33 pm
Location: Leicestershire
Contact:

Re: RiscPC support

Post by PaulV »

JonAbbott wrote:
PaulV wrote:Running at 66Hz indicates that you're running the VIDC clock at 24MHz.
LCDgm is setting the clock to 24MHz, should I change LCDgm to set 25.175 instead?
That'd be for Steve to decide I guess...
JonAbbott wrote:The reference clock is fixed at 24MHz, the VCO output can be anything from 55MHz to 100MHz which is then divided by up to 8 to set the pixel rate. It's incredibly flexible.
Right I see, so as I understand it, the VCO needs to be set to something that will allow the 25.175MHz dotclock to be generated then.
JonAbbott wrote:I've no idea :lol:, you tell me, LCDgm is your baby! What does 0.21 do?
Ummm.. Steve's baby :lol: but...

I took photo's during my testing a dual VIDC Enhancer setup which shows the monitors OSD

http://www.retro-kit.co.uk/page.cfm/con ... -Enhancer/

About half way down that page it show the photo of MODE 15 with a dotclock of 24MHz and then a dotclock of 25.175MHz. Clearly these are from a VIDC1 driven Arc but the dotclock calculations should still hold true for VGA type modes in terms of dotclock to refresh rate.

Paul
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: RiscPC support

Post by JonAbbott »

PaulV wrote:Ummm.. Steve's baby :lol: but...
Half asleep!!! I thought I was replying to Steve :oops:
PaulV wrote:I took photo's during my testing a dual VIDC Enhancer setup which shows the monitors OSD

http://www.retro-kit.co.uk/page.cfm/con ... -Enhancer/

About half way down that page it show the photo of MODE 15 with a dotclock of 24MHz and then a dotclock of 25.175MHz. Clearly these are from a VIDC1 driven Arc but the dotclock calculations should still hold true for VGA type modes in terms of dotclock to refresh rate.
Good point, unfortunately I don't have the LCDGameModes 0.21 code to check ... however, there's a comment at the end of 0.22 saying "need to disable 25175Hz clock now...", which made me think early on that there should be clock manipulation code in there somewhere. Steve may have stripped it out for this version.

Switching LCDGameModes to force 25.175 I get:

- Desktop modes now work :)
- James Pond is 720x400 x 69Hz
- No change to Manchester United or Lemmings :|
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: RiscPC support

Post by JonAbbott »

Steve, I've moved the cursor corrective code into ADFFS as the zero page entries are tied to the HDSR / VDSR values.

Manchester United - the cursor is now correct
Caverns - still not showing a cursor, so I'm going to double check the ADFFS code

Incidentally, the ZP values are HDSR and VDSR with the VIDC command stripped off - no adjustment is required.

EDIT: ADFFS code now fixed and ship showing in Caverns, however as I've seen under emulation only the bottom half of the screen is showing the cursor.
Caverns on VIDC20 with VIDC1 translation
Caverns on VIDC20 with VIDC1 translation
ssCaverns1.png (2.05 KiB) Viewed 8936 times
It should look like this...
Caverns on VIDC1
Caverns on VIDC1
ssCavernsO.png (2.24 KiB) Viewed 8936 times
PaulV
Posts: 97
Joined: Thu May 02, 2013 8:33 pm
Location: Leicestershire
Contact:

Re: RiscPC support

Post by PaulV »

JonAbbott wrote:Good point, unfortunately I don't have the LCDGameModes 0.21 code to check ... however, there's a comment at the end of 0.22 saying "need to disable 25175Hz clock now...", which made me think early on that there should be clock manipulation code in there somewhere. Steve may have stripped it out for this version.
AFAIK it's never been in there.

If you read the comments in LCDGamesMd from the POV of running on an A5000 with SVGA monitortype, they make more sense. The standard RO3 modes get mapped and use the 25.175MHz dotclock so it needs to be disabled for Steve's current (0.21) mode timings/settings to work their magic.

As Steve has said, he's working on 25.175MHz mode defs for LCDGamesMd but they're not complete yet.

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

Re: RiscPC support

Post by steve3000 »

Very slow Internet out here in the dark ages... Have read all the above and think you've worked it out :) or are close!
Great progress to see some of the mouse cursor too...

FYI LCDgm v0.22 currently uses only 24MHz clock and it uses this to generate 70Hz modes. Version v0.23 uses AutoVIDC to select 24/25/36MHz but this is still experimental code, so I've not sent it out yet.

So Jon - you should see 70Hz without changing clock to 25.175MHz. Something is not quite right if you're only seeing 66Hz at 24MHz... (And it is just coincidental that 66Hz is also the same rate that the acorn modes which are designed for 25.175MHz run at when you feed 24MHz).

I can't think why LCDgm is affecting mode 32? Any thoughts? It shouldn't pick that mode up at all...

EDIT: reread your posts. Increasing VCR will *decrease* the frame rate. So I expect by adding &1C to VCR you have dropped the frame rate from 70 to 66Hz. Try adding another &1C to VCR to confirm it drops further - to around 62Hz. Then try decreasing VCR towards my original values. How close can you get before the screen corrupts? We need to work out why the original values aren't working. Otherwise any work you do to fix the cursor positions/etc at 66Hz will be redundant if we sort out the 70Hz in future.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: RiscPC support

Post by JonAbbott »

steve3000 wrote:LCDgm v0.22 currently uses only 24MHz clock and it uses this to generate 70Hz modes. Version v0.23 uses AutoVIDC to select 24/25/36MHz but this is still experimental code, so I've not sent it out yet.

So Jon - you should see 70Hz without changing clock to 25.175MHz. Something is not quite right if you're only seeing 66Hz at 24MHz... (And it is just coincidental that 66Hz is also the same rate that the acorn modes which are designed for 25.175MHz run at when you feed 24MHz).
How much would the clock need to increase to account for VCR being increased by 32?
steve3000 wrote:I can't think why LCDgm is affecting mode 32? Any thoughts? It shouldn't pick that mode up at all...
I'll investigate.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: RiscPC support

Post by JonAbbott »

JonAbbott wrote:How much would the clock need to increase to account for VCR being increased by 32?
By my calculations it needs to increase by just over 6% ... from 24000 to 25465. The register conversion values I'm using are listed on this post.

And sure enough, James Pond is back to 720x400 @ 70Hz. I've put the latest LCDgm and ADFFS modules on the dev site, along with the ADFFS source. The LCDgm source is identical except for the increased AutoVIDC_SetClock value.

We either need to figure out why VCR needs increasing or simply increase the pixel rate to compensate if it's a requirement.

Anyone have an idea as to why Manchester United, etc look scrambled? Or why the mouse cursor (ie ship in Caverns) only appears on the bottom half of the screen - is there a ZP entry we need to alter perhaps?

EDIT: The cursor on Caverns starts appearing 11 pixels below the bottom half of the screen, I don't know if that's significant.
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: RiscPC support

Post by steve3000 »

JonAbbott wrote:
JonAbbott wrote:How much would the clock need to increase to account for VCR being increased by 32?
By my calculations it needs to increase by just over 6% ... from 24000 to 25465. The register conversion values I'm using are listed on this post.

And sure enough, James Pond is back to 720x400 @ 70Hz. I've put the latest LCDgm and ADFFS modules on the dev site, along with the ADFFS source. The LCDgm source is identical except for the increased AutoVIDC_SetClock value.

We either need to figure out why VCR needs increasing or simply increase the pixel rate to compensate if it's a requirement.

Anyone have an idea as to why Manchester United, etc look scrambled? Or why the mouse cursor (ie ship in Caverns) only appears on the bottom half of the screen - is there a ZP entry we need to alter perhaps?
Only problem with arbitrarily increasing the clock to compensate for the patched VCR value, is that the other values are all linked - including geometry. There is no technical reason you should have to increase VCR by the amount you have. Its a useful patch to get round whatever translation error, or our lack of knowledge of VIDC20, that has stopped the original LCDgm values from working - but we will get them working soon and spending time adjusting the clock to compensate for this patch is not the long term solution.

I expect one of our values is subtly out - causing ManU and, I'm sure we'll find some other vertical overscan games will also be scrambled.

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.

As you recall it took a while to get the cursor working with LCDgm on VIDC1 - this was all linked to VCR and VCSR. VCR controls the cursor clipping so I expect you just need to 'fudge' VCSR by the same amount +&1C.

EDIT: added missing paragraph, writing via an iphone is a pain...
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: RiscPC support

Post by JonAbbott »

Pokemodes stays static on each write, so I think we can accept the translation is correct. It's the odd res modes where VCR is needing to be adjusted, which implies these an incompatibility between the values that work on VIDC1 and VIDC20. Fudging VCR may be the only answer, although a more detailed analysis of the differences between VIDC1 and VIDC20 values for type 4 modes may indicate where the issue is.

MU etc...we may need to fudge HCR as well, it's not something I've looked at.

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.
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: RiscPC support

Post by steve3000 »

PokeMode is only correct for Mode 27. We'll need to check a 16MHz mode and 256 colour mode too. Also, you can get away with having some out of range values depending on what other values are, so the fact PokeMode works doesn't mean translation is correct for everything - only that it works sufficiently to change from a Mode27 screen to another Mode 27 screen.

VIDC20 can produce all the screen modes that VIDC1 can do - there are no technical restrictions. We just need to send it the right information.

One good test would be to adapt PokeMode to start in, say, Mode 15... Then patch through to Mode27... The screen will be garbage (since RISC OS wont realise) but does this work on the monitor and does it lock correctly? But ideally we need to go from Mode 27 to Mode 9 LCDgm... More complicated...

Yes, you're right about VCSR. I'll have to think about that - the VIDC1 problem was a combination of VCR/VBER/VBSR - if you set VCSR outside VBER or VBSR then the cursor does not display, or is clipped by the border. LCDgm works by shifting the screen higher up the monitor, to allow the TV resolution VCSR values to work in VGA modes on VIDC1. This isn't actually required for VIDC20 as ADFFS is translating all the VCSR values, so we can lower the screen position and patch the cursor start and end accordingly...in theory...
Post Reply