RiscPC support

Discuss LCDGameModes by Steve Harrison
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: RiscPC support

Post by steve3000 » Thu Aug 01, 2013 8:58 am

Hi Jon, that sound good - I'd done the FSIZE code in 2.16v, but I'll take a look this weekend.

Did you read my ADFFS 2.16v source? You don't actually need to calculate FSIZE at all. Providing FSIZE is set small enough to allow a suitable refresh gap, followed by the initial VRAM reload before vsync completes and output starts, then we're fine. As these modes are in no way stressing VIDC20, I just used a single value for FSIZE when any resolution < 480 lines (VGA) screen is selected. That saves all the need to update FSIZE on VDSR and VDER - so you can just follow and update on VCR. Which saves a huge amount of effort.

Steve

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

Re: RiscPC support

Post by JonAbbott » Thu Aug 01, 2013 10:08 pm

steve3000 wrote:Did you read my ADFFS 2.16v source?
Yes, I looked at the source before doing anything. My initial thought was...there's no way it should be a fixed value, what's the equation to calculate it correctly.

It's obviously a small figure as its less than 255, but what? I need to find the IOMD TRM, to figure out the correct way to calculate it.

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

Re: RiscPC support

Post by steve3000 » Fri Aug 02, 2013 6:26 am

I did a calculation routine, taken from the RO source, if you prefer. However there are a number of down sides - firstly it doesn't appear to work for all V-sizes (think RO assumes Y to be in multiples of 16? or mayve I introduced a bug sonewhere!) but it misbehaves on some translated VIDC 1 screens sizes. Also if you calculate FSIZE, then because you dont know the order which VDSR, VDER and VCR will be written, you have to adjust FSIZE on setting all three, not just VCR as I do... possibly need to adjust on VBER too (eg. if VBER < VDER)... So you end up needing to track a lot variables, and recalc on each. Then I noticed that each time you set FSIZE to a new value there appears to be a momentary flicker (1 frame?) which is fine if you are set it once on mode change, but problematic if set once a frame.

In the end I used a fixed size - and calculated that fixed FSIZE based on a 320 line screen, which is the maximum possible number of lines at 50Hz/15kHz. This value works for all smaller screens, because FSIZE dictates minimum time before reloading VRAM. Also at this number of lines VIDC20 is hardly ticking over, IOMD and VRAM are the same, so there's no stress on anything by using a slightly shorter FSIZE delay than absolutely necessary. I think you could happily use a fixed FSIZE for all modes possible on VIDC1, up to 800x600 at 256 colours, but I put a cut-off for larger numbers of lines ie. VGA modes or larger, because 1) no games use larger sizes by poking VIDC1 and 2) just to be completely sure we dont stress anything.

Steve

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

Re: RiscPC support

Post by JonAbbott » Fri Aug 02, 2013 10:15 am

Something else is wrong, if I reduce FSIZE until it works (-18 in the case of James Pond), the screen is knackered in the bottom third. I think I've broken something somewhere, so will need to check through the source as I made quite a few changes to get it ready for public release.

Looking at the VIDC test program, I have the correct calculation for FSIZE.

Do we need to add a further check to the LCDgm modules so the service code exits if the monitor type is wrong?

EDIT: DCTL is wrong, I'll fix it later tonight.

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

Re: RiscPC support

Post by JonAbbott » Fri Aug 02, 2013 11:40 pm

ADFFS 2.17b full ZIP on dev site. Load !ADFFS, mount a game and provided there's a boot script it should just work via "Boot floppy"

I've checked the following games:

Boogie Buggy
Caverns (scrolling is broken but works under emulation, pointer is wrong)
Chuck Rock
James Pond
Manchester United Europe (FSIZE is calculating incorrectly)
Pesky Muskrats
Rockfall (no display, works under emulation though)
YAIG

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

Re: RiscPC support

Post by JonAbbott » Sun Aug 04, 2013 3:08 pm

ADFFS 2.17c module, source and full ZIP now on dev site. Lots of fixes for bugs introduced in 2.17a/b

To get around the vertical scroll/FSIZE issue, I've simply reduced the FSIZE value by 15 and cleared the bottom four bits - effectively putting a window on it.

Caverns - I noticed that after adding code to only write VIDC20 values if they change, the pointer disappeared. It looks like RO3.7+ may write VCSR / VCER on every frame, which might explain why it's missing from the top of the screen. Further investigation required.
I've no idea why the scrolling is broken, more investigation required.

Rockfall - Does this work on any version of LCDgm? Is it only broken on VIDC20?

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

Re: RiscPC support

Post by JonAbbott » Sun Aug 04, 2013 8:41 pm

steve3000 wrote:Also if you calculate FSIZE, then because you dont know the order which VDSR, VDER and VCR will be written, you have to adjust FSIZE on setting all three, not just VCR as I do... possibly need to adjust on VBER too (eg. if VBER < VDER)
I did try checking for VBSR/VBER being inside VDSR/VDER but it didn't work very well, it looked like it was taking effect on most games and causing FSIZE to be wrong.

One thing I did notice, is that most games are continually writing the same values to VIDC1 which was causing FSIZE issues...hence why ADFFS is now only writing changes. I had to exclude VCSR/VCER from this due to something resetting them each frame. I'm guessing it's RO3.7x as RO3.5 doesn't have the problem, I need to look through the OS source code and figure out how to disable it. There's also the issue of the mouse pointer not moving smoothly in Manchester United Europe, I'm not certain if that's down to the game or RO.

Another issue is several MODE's not working with LCDgm on, 2, 5, 6, 7, 10 to name a few. The LCDgm mode extension code may be causing this, but I haven't investigated yet. Can we remove this code as ADFFS is dealing with it? LCDgm should kick in when ADFFS switches to the base mode, if it's one it supports.

Should we be restricting any values? Rockfall is an example where it does crazy things with values as the height goes over 512 pixels by the looks of it. The width of some of the screens (title / game over) also ends up wrong under emulation and looks like HBSR or HDSR may be too high, so it's missing the left of the screen.

I'll probably start a new thread for A7000 support, as I suspect that's going to be fun, I'll try changing the clock settings and see what happens.

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

Re: RiscPC support

Post by steve3000 » Tue Aug 06, 2013 7:42 am

JonAbbott wrote:Rockfall - Does this work on any version of LCDgm? Is it only broken on VIDC20?
If you recall because of its strange shaped screen, Rockfall was one of the first games tested with LCDgm and after a couple of attempts, it worked quite early on (v0.02/3 I think) but it, along with Caverns and a few other, had issues once the screen position was centred vertically - hence why that vertical centring code was removed in v0.07 - and Rockfall has worked fine since then on VIDC1.

So yes, it is a VIDC20 / translation problem.

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

Re: RiscPC support

Post by steve3000 » Tue Aug 06, 2013 8:11 am

JonAbbott wrote:I did try checking for VBSR/VBER being inside VDSR/VDER but it didn't work very well, it looked like it was taking effect on most games and causing FSIZE to be wrong.
Ok good to know.
JonAbbott wrote:One thing I did notice, is that most games are continually writing the same values to VIDC1 which was causing FSIZE issues...hence why ADFFS is now only writing changes.
Yes I noticed that too, it's to get round problems with RISC OS 2-3.1 doing the same on each VSync. So writing changes is a good solution.
JonAbbott wrote:I had to exclude VCSR/VCER from this due to something resetting them each frame. I'm guessing it's RO3.7x as RO3.5 doesn't have the problem
I'm surprised RO3.5 doesn't do this as RO2-3.1 does this on every VSync. As well as this, RO2-3.1 also resets the cursor and palette colours on VSync. I'd be surprised if RO3.5 doesn't do this too?
JonAbbott wrote:Another issue is several MODE's not working with LCDgm on, 2, 5, 6, 7, 10 to name a few. The LCDgm mode extension code may be causing this, but I haven't investigated yet.
Did you have to edit anything in the mode extension code to LCDgm working on RO3.5+?

v0.21 doesn't interfere with any of those modes on RO3.1. It checks the CR value in ZP before applying any extension trap code and only applies the extension code if it finds a 8MHz mode, ie. 320 base x pixels.
JonAbbott wrote:Should we be restricting any values? Rockfall is an example where it does crazy things with values as the height goes over 512 pixels by the looks of it.
Not sure we do as it works on VIDC1, and restrictions are not in place there.
JonAbbott wrote:The width of some of the screens (title / game over) also ends up wrong under emulation and looks like HBSR or HDSR may be too high, so it's missing the left of the screen.
There is a problem with the title screen width on RO3.1 running LCDgm - it's an artefact of the 'zoom' effect used by Rockfall. The in-game screen displays and scrolls fine under RO3.1 so I hadn't pushed to fix the title page yet.
JonAbbott wrote:I'll probably start a new thread for A7000 support, as I suspect that's going to be fun, I'll try changing the clock settings and see what happens.
The VCO code should be the only difference? Once that's sorted we'll be fine. I have two A7000's, but one is deceased (no output or any indication of life, not even POST error) and the other is in intensive care (every POST error you can think of, and a dead PSU in its original box). I think the battery position in the A7000 has to be the most lethal location of all Acorns for leak damage!

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

Re: RiscPC support

Post by JonAbbott » Tue Aug 06, 2013 11:24 am

steve3000 wrote:
JonAbbott wrote:I had to exclude VCSR/VCER from this due to something resetting them each frame. I'm guessing it's RO3.7x as RO3.5 doesn't have the problem
I'm surprised RO3.5 doesn't do this as RO2-3.1 does this on every VSync. As well as this, RO2-3.1 also resets the cursor and palette colours on VSync. I'd be surprised if RO3.5 doesn't do this too?
I've searched the RO code, but can't find anything obvious, mind you, it's like looking for a needle in a haystack! I'll continue looking, could really do with Jeffrey's knowledge here, I did eMail him about it in June but guess he's busy.
steve3000 wrote:
JonAbbott wrote:Another issue is several MODE's not working with LCDgm on, 2, 5, 6, 7, 10 to name a few. The LCDgm mode extension code may be causing this, but I haven't investigated yet.
Did you have to edit anything in the mode extension code to LCDgm working on RO3.5+?
I've now commented out all the ModeExtension code in LCDgm 0.22d as it's not required, ADFFS is trapping and handling ModeExtensions, leaving LCDgm to kick in if it goes to a base mode it supports. There's next to nothing left in the module, if we're not going to extend it further we could move the VIDC values into ADFFS, re-instate the code that writes all the VIDC20 values on a mode change, update to use your values and drop the separate LCDgm module completely for A7000/RPC. I've uploaded lcdgm022d ZIP to the dev site, so you can see what I mean.
steve3000 wrote:
JonAbbott wrote:Should we be restricting any values? Rockfall is an example where it does crazy things with values as the height goes over 512 pixels by the looks of it.
Not sure we do as it works on VIDC1, and restrictions are not in place there.
It looks like Rockfall is causing VIDC20 to fail. I'll need to investigate and implement restrictions if this does prove to be the case. I'll continue that discussion on the Rockfall thread once I've investigated.
steve3000 wrote:
JonAbbott wrote:The width of some of the screens (title / game over) also ends up wrong under emulation and looks like HBSR or HDSR may be too high, so it's missing the left of the screen.
There is a problem with the title screen width on RO3.1 running LCDgm - it's an artefact of the 'zoom' effect used by Rockfall. The in-game screen displays and scrolls fine under RO3.1 so I hadn't pushed to fix the title page yet.
We could resolve this by tracking the VIDC1 values and shift them when writing to VIDC20, to ensure they're within the screen boundaries. Something to look into at a later date.
steve3000 wrote:
JonAbbott wrote:I'll probably start a new thread for A7000 support, as I suspect that's going to be fun, I'll try changing the clock settings and see what happens.
The VCO code should be the only difference? Once that's sorted we'll be fine. I have two A7000's, but one is deceased (no output or any indication of life, not even POST error) and the other is in intensive care (every POST error you can think of, and a dead PSU in its original box). I think the battery position in the A7000 has to be the most lethal location of all Acorns for leak damage!
A7000 support is in the latest ADFFS, tested and working. See the Caverns thread, for some reason the A7000 doesn't suffer the scrolling issues the RPC does.

Post Reply