RiscPC support

[JonAbbott]

I've coded it, however it doesn't work at the minute. For Diggers its going into MODE 28, but the VIDC1 values aren't applying correctly for some reason.

EDIT: I believe the issue is the clock rate isn't being set correctly

EDIT2: Have a bigger issue to resolve - stopping RO from doing anything after we've written the VIDC registers. If I let the Diggers claim go through, RO goes into MODE 28 and appears to try and write the VIDC1 parameters to VIDC20, ending up with a corrupt display. If I claim the call, RO switches to the MODE in the claim or to a MODE of it's choice if I specify an invalid claim.

I'll try setting up a callback and let the claim run its original course.

[JonAbbott]

Using CallBack seems to have got around the issue. Under emulation, Diggers ends up in a screen with the correct dimensions. Hard to tell if it's working though as Diggers never works anyhow.

Fervour however seems okay:

Fervour with ADFFS providing Service_ModeExtension translation

ssFervour1.png (3.67 KiB) Viewed 16292 times

I'll test with LCDgm under emulation next, then LCDgm on physical. The latest ADFFS module, source and LCDgm module are on the dev site.

[JonAbbott]

Fervour works with LCDgm on RO3.5 under emulation, rather annoyingly the display height is wrong on RO3.71, so I'm currently checking other games to see if I can find one that does use ModeExtension that I can test on RO3.71 physical.

K.V. I'm getting no display on physical, under emulation it goes to a 100Hz refresh and works.
Manchester United is scrambled on physical.
Nevryon works on physical.

[steve3000]

Despite the ones which don't work on physical - it sounds like significant progress!

I have a huge bundle of mode defn modules on my discs. Some identical to ones used in comnercial and PD games.

I'll happily offer these all up for testing. I'm back late on Friday, so sometime sat/sun will get a few of them off the Acorn and uploaded, along with a simple screen display test (I have a hardware scroll test and a raster bar test somewhere...).

[JonAbbott]

I've put a copy of the 0.22b source onto the dev site for you to take over. The changes I've made were to add an ADFFS constant file for the SWI it's using and changes to services. In services, the changes are:

1. Removed the cursor fix code as ADFFS is now doing it as VIDC parameters are written
2. Switched the ZP reads of the VIDC CR to use ADFFS_VIDCCR
3. Set the VIDC clock to 25465 to account for the increased VCR
4. Uncommented most of the code

I've also put the latest compiled ADFFS module and the ADFFS source on the dev site. When you look at why VCR needs to be increased, you'll need to comment the following code out in adffs.vectors.vidc_abort (~line 287) and recompile:

Code: Select all

TEQ     R1, #&90
ADDEQ   R0, R0, #31 + 1

I noticed you're setting bit 12 in VIDC1 CR, was that added to VIDC1a as it's not in the VIDC1 documentation. I'm disregarding it in ADFFS, should I be doing something if it's set?

EDIT: ADFFS_VIDCCR will return the VIDC1 CR in R0, in the form: E000000Y - Y being the only bits set

adffs.service contains the Service_ModeExtension code, starting at _modeextension

For type 0/1, it writes all parameters to VIDC1 via a CallBack (_modeextension_callback)
For type 1 extended parameters, I've yet to implement the clock change correctly and am not doing anything with sync polarity
I'm totally ignoring the workspace list.

Regards the sync polarity, this is set in ereg on VIDC20, but I'm unsure of the correct values for the register. I think its:
C0001700 OR HSYNC<<17 OR VSYNC<<19

[JonAbbott]

Regards the sync polarity, this is set in ereg on VIDC20, but I'm unsure of the correct values for the register. I think its:
C0001700 OR HSYNC<<17 OR VSYNC<<19

Could the fact we're not currently altering ereg be causing the VCR issue? I originally took a guess that the polarity wouldn't change from the default RO MODE setting.

If it is relevant, the next question of course is what am I translating? How is the polarity set on VIDC1? And how does it map to HSYNC/VSYNC on VIDC20?

I'm guessing that VIDC1 CR bit 7 toggles VSYNC or HSYNC (the TRM is somewhat confusing as it says "V/CSYNC can be programmed to output either a VSYNC or CSYNC pulse which is exclusive-NOR of VSYNC and HSYNC" - implying HSYNC is set elsewhere).

EDIT: Cross checking with AutoVIDC, I see that the polarity is set in CR bits 11/12 - this isn't mentioned in the TRM, so how do I translate these bits to VIDC20 ereg?

[JonAbbott]

Caverns...the ship is only missing on RO3.7, it appears on RO3.5. What's different between the two OS versions that's causing the issue?

Caverns on RO3.71

ssCaverns1.png (2.05 KiB) Viewed 16292 times

Caverns on RO3.5

ssCaverns2.png (2.24 KiB) Viewed 16292 times

Compared to RO3.11, the ship is also out slightly, being down and right a bit, so our cursor correction may be out slightly or need to be bit depth specific. Manchester United Europe is spot on.

Caverns on RO3.11

ssCavernsO.png (2.24 KiB) Viewed 16292 times

[JonAbbott]

Latest ADFFS and LCDgm on the dev site. Changes are:

- Removed the code from LCDgm that compensated for the VCR increase, and corrected it in ADFFS by

Code: Select all

#set reference_clock = 21765

at the top of adffs.vectors.vidc_abort, this will have the effect of setting the VIDC20 clock to 25465 when VIDC1 is 24000

LCDgm should be near identical to 0.21 now, the only changes being the use of ADFFS_VIDCCR instead of the ZP LDR, the clock being set before the CR is written, the cursor corrective code being removed and no ZP writes.

If we don't want to increase VCR, this line should be changed to 24000 and the following lines commented in adffs.vectors.vidc_abort _VIDC_vertical

Code: Select all

TEQ     R1, #&90
ADDEQ   R0, R0, #32 + 1

- adffs.service _modeextension_callback sets both the VIDC20 clock rate and polarities for Type 1 extensions

- adffs.vectors.vidc_abort sets the polarity in the CR code, based on VIDC1 bits 11/12 by calling set_HV_sync

- set_HV_sync added at the bottom of adffs.vectors.vidc_abort. It writes the VIDC20 CR as &C0001000 with bit 18 set to match VIDC1 bit 12 and bit 16 set to match VIDC1 bit 11, I'm not sure if that's correct or not without any VIDC1 documentation to base it on.

If you'd like to upload the code for the next version of LCDgm (with the multiple clock support), I'll test and confirm what needs changing for RO3.5+ support. As the changes are now minimal, we may be able to retain one code path, instead of branching it.

[steve3000]

Thanks for the update Jon - some really good progress there.

I'm now back from my summer holiday (strange coming back from a cold/wet/windy holiday to good old hot and sunny England!)... So after I've dealt with the backlog of work emails, I can catch up on the Risc PC.

I'll download these versions tonight and have a try to recreate what you see.

FYI - I've also had a useful parcel arrive in the post while I was away, containing RO3.71 ROMs, RO4.39 ROMs and RO3.6 ROMs. So now I have all the old versions of RISC OS to hand for testing...

[JonAbbott]

The two things I'd like you to look at are the VCR issue (although it's working, so we could ignore until it's an issue!) and Service_ModeExtension.

I can't get a display when Service_ModeExtension is used on physical, we're not exactly spoilt for choice of games that use it. Diggers doesn't work under emulation and Fervour doesn't work on RO3.7. If you have RO3.5 ROM's, Fervour is probably the best one to go with as I've confirmed the geometry is correct under emulation.

We need to find more games that use Service_ModeExtension, note the other thread on the subject.