RiscPC support
Re: RiscPC support
I've modified everything to match your comments and will try to get something up and running before you're back.
Re: RiscPC support
We have the beginnings of a picture, so are making progress.
- Attachments
-
- James Pond on a RiscPC under VIDC translation with LCDgm 0.22
- photo.JPG (31.51 KiB) Viewed 5852 times
Re: RiscPC support
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?
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?
Re: RiscPC support
The right of the rectangle box?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.
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...
Re: RiscPC support
Yes, I need to reset the monitor before knowing for certain.steve3000 wrote:The right of the rectangle box?
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.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?
RHS disappearing is when CR is written. However, if CR was out it's unlikely we'd get a display at all.
Yes, I need to check all the main game modes, so 9, 13 etc.steve3000 wrote:If you fancy playing with fire, edit PokeMode to start in Mode9 and use the Mode9 VIDC params from LCDgm source...
Re: RiscPC support
Ok, yes if your values match mine and the effect is only happening when you poke CR, then it must be down to that.JonAbbott wrote:RHS disappearing is when CR is written. However, if CR was out it's unlikely we'd get a display at all.
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.
Re: RiscPC support
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.7steve3000 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 !
How does one calculate the FIFO? Is there's a formula I can code as its the only bit I'm not familiar with.
Re: RiscPC support
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).
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).
Re: RiscPC support
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
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
Re: RiscPC support
That's great! (well the 57Hz is great, not the missing 2 pixels)JonAbbott wrote:Final result: 640x480 @ 57Hz, and the right 2 pixels missing.
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!