RiscPC support

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

Re: RiscPC support

Post by JonAbbott »

I've modified everything to match your comments and will try to get something up and running before you're back.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: RiscPC support

Post by JonAbbott »

We have the beginnings of a picture, so are making progress.
Attachments
James Pond on a RiscPC under VIDC translation with LCDgm 0.22
James Pond on a RiscPC under VIDC translation with LCDgm 0.22
photo.JPG (31.51 KiB) Viewed 5792 times
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: RiscPC support

Post by JonAbbott »

I should add that the image above is static (ie doesn't jump around the screen) and that it appears correct under emulation, so from that we know LCDgm is correcting the geometry as I stripped all that code out of ADFFS - without LCDgm running the screen is a garbled mess.

So...what could cause it to create a double image on physical but work correctly under emulation? Pixel rate springs to mind, however pokemode seems to translate okay - we don't get the double image at any rate. I did notice the right of the screen disappeared, but I didn't try resetting my monitor...I'll check that next.

One thing I have noticed, is that after enabling LCDgm, stock MODEs (tested 0, 13, 27) either don't display or are a total mess. If however, I enable at supervisor, run James Pond and then quit out, MODE 0, 13 work - but with a double image. I'll do some checks on this, to pin the issue down.

Poking a stock RO3.1 type 0 MODE 13, with LCDgm and ADFFS running is probably a good test.

The other outstanding issue is Service_ModeExtension (type 0, 1) - which is currently not supported. I'll need to figure out how to capture this in ADFFS and write them to VIDC1 - allowing the translator to do it's bit.

Diggers / Fervour are two that use this method, do we know of any other titles that use ModeExtension?
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: RiscPC support

Post by steve3000 »

JonAbbott wrote:So...what could cause it to create a double image on physical but work correctly under emulation? Pixel rate springs to mind, however pokemode seems to translate okay - we don't get the double image at any rate. I did notice the right of the screen disappeared, but I didn't try resetting my monitor...I'll check that next.
The right of the rectangle box?
That sounds like HDSR/HDER translation is off a little. What register causes the RHS disappear? You say you are definitely getting the same values as my method in the VIDCompare program? I think I left Mode25 values in there too, as another comparison - try editing the VIDCompare for Mode25 (just open the listing, comment out Mode27 and enable Mode25).

Not that this will necessarily solve the JP problem, but it's another step closer if you can solve the disappearing RHS.

If you fancy playing with fire, edit PokeMode to start in Mode9 and use the Mode9 VIDC params from LCDgm source...
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: RiscPC support

Post by JonAbbott »

steve3000 wrote:The right of the rectangle box?
Yes, I need to reset the monitor before knowing for certain.
steve3000 wrote:That sounds like HDSR/HDER translation is off a little. What register causes the RHS disappear? You say you are definitely getting the same values as my method in the VIDCompare program?
My values match yours, they were only out by 1 anyhow, so shouldn't be a major issue only affecting the horizontal position of the display.

RHS disappearing is when CR is written. However, if CR was out it's unlikely we'd get a display at all.
steve3000 wrote:If you fancy playing with fire, edit PokeMode to start in Mode9 and use the Mode9 VIDC params from LCDgm source...
Yes, I need to check all the main game modes, so 9, 13 etc.
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: RiscPC support

Post by steve3000 »

JonAbbott wrote:RHS disappearing is when CR is written. However, if CR was out it's unlikely we'd get a display at all.
Ok, yes if your values match mine and the effect is only happening when you poke CR, then it must be down to that.

In which case, I expect you'll see the scrambled screen occurs on writing CR too (in mode9)... And thinking laterally now - if your monitor is locked on correctly, at a sensible resolution and refresh rate (can you check this on the OSD?) then your clock values must be correct!

In which case I'd be fairly certain that the scrambling is being caused by the DMA / FIFO settings !

These are easy to get wrong and would definitely result in a scrambled mess, as the VIDC20 will be requesting data too soon (causing screen compression) or too late (causing screen stretch/repeated parts of the screen). The latter is what you're seeing in the JP screen.

It also explains why all looks good under emulation - as VIDC20 DMA will not be emulated, the screen will just be translated as needed by the emulator.

Take a look at the stardot LCDgm thread - page1, the first screenshot by MarcT - this was caused by getting the DMA slightly out on VIDC1... You can see some doubling up/screen stretch.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: RiscPC support

Post by JonAbbott »

steve3000 wrote:Ok, yes if your values match mine and the effect is only happening when you poke CR, then it must be down to that.

In which case, I expect you'll see the scrambled screen occurs on writing CR too (in mode9)... And thinking laterally now - if your monitor is locked on correctly, at a sensible resolution and refresh rate (can you check this on the OSD?) then your clock values must be correct!

In which case I'd be fairly certain that the scrambling is being caused by the DMA / FIFO settings !
My first thought was FIFO and it was the first thing I checked on seeing the image appear on the RiscPC. The FIFO calculation code is identical to RO3.7

How does one calculate the FIFO? Is there's a formula I can code as its the only bit I'm not familiar with.
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: RiscPC support

Post by steve3000 »

There is a recommended method to calculate FIFO, I can't recall off top of my head though. I'm pretty sure you have to account for whether or not VRAM is in use.

Do you have the RiscPC TRM and VIDC20 docs to hand - I would have thought it's in there, possibly the TRM is best?

Alternatively... Can you read the CR value for Mode27 from RO3.7 zero page (should be same location as VIDC1 CR copy, &1584?) and compare to the value ADFFS is generating during PokeMode? You could then try reading CR for mode 12 (translation off) and then poke that into VIDC20 during translation with LCDgm running of JP's mode 9 screen - to see if it solves the problem? (LCDgm uses ~mode 12 default DMA settings for its patched mode 9).
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: RiscPC support

Post by JonAbbott »

I've checked the FIFO and it's the same as RO - as I'd expect as the code is the same. MODE 13 for example is 4, as are most modes as they're not really pushing the bandwidth. MODE 27 is also 4.

I think we can rule out FIFO

EDIT1: Observations from pokemode (MODE 27):

Starts at 640x480 @ 60Hz

HCR - no change
HSWR - display shifts left 2 pixels
HBSR - display loses the left 2 pixels
HDSR - display regains the left 2 pixels
HDER - no change
HBER - display loses to right 2 pixels
HIR - no change

VCR - no change
VSWR - no change
VBSR - no change
VDSR - no change
VDER - no change
VBER - no change

CR - Hz change

Final result: 640x480 @ 57Hz, and the right 2 pixels missing.


EDIT2: If I put my original code back (where HDSR / HDER are out by 1), the final result is a perfect screen with all pixels @ 57Hz.

I think we can safely say the pixelrate is out slightly.


EDIT3: I've double and triple checked the clock code with all reference pixel rates and it's spot on...provided the documentation is correct and VCLK is 24000

For example, a pixel rate of 8000 sets VIDC20 as:

VMOD = 7
RMOD = 3
CK = 7
= (VMOD/RMOD*VCLK)/CK = (7/3*24000) / 7 = 8000

or, pixel rate of 12000:

VMOD = 5
RMOD = 2
CK = 5
= (VMOD/RMOD*VCLK)/CK = (5/2*24000) / 5 = 12000

or, pixel rate of 12587

VMOD = 11
RMOD = 3
CK = 7
= (VMOD/RMOD*VCLK)/CK = (11/3*24000) / 7 = 12571
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: RiscPC support

Post by steve3000 »

JonAbbott wrote:Final result: 640x480 @ 57Hz, and the right 2 pixels missing.
That's great! :) (well the 57Hz is great, not the missing 2 pixels)

It was my test - forgot to explain that. 57Hz means your CR code is good. Remember I said to keep clock at 24MHz - as we're working on the basis of an old hardware Archimedes with VIDC1. These run the RISC OS 3.1 Mode 27 at 57Hz, not 60Hz. So that confirms your HCR, VCR and CR code are correct, at least wrt to any clock timings in CR. If you change your clock code to 25.175MHz, you'll get exactly 60Hz, as this is what 'new' hardware A5000/etc. do.

The pixel left/right shift is very strange. You've confirmed your code gives the same result as mine in the VIDCompare programme, so since we've gone about this with two different translation methods (actually three if you count my BASIC routine), then we can be fairly sure we're getting the 'right' values. So I'm not sure why the shift is happening. I would just double-check your HSWR code though (I'll check mine when I'm back), as it is the shift that is not correct - the left/right chopping occur as a result of that 2 pixel shift...(although if you do solve HSWR, then check how HDSR/HDER respond with the fixed HSWR). If we can't spot an error in our translation, then I can go back to the RO source and see if there's anything obvious there which RO does and we don't...

I'm likely to be offline from midday tomorrow for the next 8-9 days, although may check in if I get a signal :) It seems you're very close to success though...good luck!
Post Reply