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 »

JonAbbott wrote:Will add clock rate tonight, when I'm back.
Updated ADFFS module and source on the dev site, controls as below. To build without this debug code use "#set VIDC20_debug = 0" in MkADFFS. VCR is still increased by 20 in this version (see comments above to turn it off), but the clock rate hasn't been compensated.

SHIFT-<cursor up/down> to alter VIDC1 clock +/- 100Hz
CTRL-<cursor keys> to alter HSWR / VSWR
CTRL-SHIFT-<cursor keys> to alter HCR / VCR

Down/Left reduce the value, Up/Right increase the value.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: RiscPC support

Post by JonAbbott »

I've played around with all the settings and can't get a stable 640x350 image. Can I suggest we go higher and increase the image to fill the screen? 720x400 seems to be a lot more stable and does actually fill my monitors width.

Having got about as far as I can with my limited monitor knowledge, I feel I need to hand the baton to you Steve :)
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: RiscPC support

Post by steve3000 »

No problem Jon, thanks for trying what you can and documenting, so I don't repeat.

It's been a nightmare two weeks at work, but I'll find time on the Risc PC soon... Things are looking up too, it's 5 'C cooler tonight, so might get some sleep :)
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: RiscPC support

Post by steve3000 »

Ok, so much for sleep...

I've been mulling over what reasons there could be as to why LCDgm modes wouldn't work under VIDC20. And I can't come up with a good reason - VIDC20 should be able to output exactly what VIDC1 could do - the only change in restriction of parameters is an odd/even change in horizontal parameters, which should cause a 1-pixel shift when a VIDC1 driven screen is compared to a VIDC20 driven screen (but even on the same monitor, that would be hard to notice).

So I've written a VIDC1 register to RISC OS 3.5+ mode definition file converter... and it works :)

But better than that, I can now feed in the exact LDCgm register values as used under RISC OS 3.1, and get out the RISC OS 3.5+ mode definition file to generate LCDgm Modes 4/9/13 and 0/8/12/15 under RISC OS 3.5+.

I've loaded the output into my Risc PC running RO3.7, and connected to the same LCD monitor I've been testing LCDgm with under RO3.1... and the result... The LCDgm modes work perfectly :D

Jon - I've emailed you the converter, and example mode definition file - take a look when you can. Also, can you pop these on the ftp site for all to use? The mode definition file is an Acorn AKF52 file with 320x256 and 640x256 modes replaced with LCDgm equivalents, just pull these into your mode definition file to test.

Conclusion - as LCDgm modes are possible on VIDC20, we must still have something in ADFFS that isn't quite right in the conversion. I'll focus on this next, but not now - need to get some sleep...
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: RiscPC support

Post by JonAbbott »

I've uploaded to the dev site.

Looking at the code, it does seem to deviate from the VIDC20 docs. For example, instead of VXXX = N - 2, its using VXXX = N + 1. The HXXX parameters are similar, which is where ADFFS is probably going wrong. I coded ADFFS to match the VIDC20 docs, however that doesn't seem to translate VIDC1 parameters to the correct matching VIDC20 values.

Reverse engineering your code, I believe its using the following corrections:

Vxxx = Vxxx + 1

sub = 18 (1/bpp)
sub = 10 (2/bpp)
sub = 6 (3/bpp)
sub = 4 (4/bpp)

HCR = (HCR * 2) + 2
HSWR = (HSWR * 2) + 2
HBSR = (HBSR * 2)
HDSR = (HDSR * 2) + sub
HDER = (HDER * 2) + sub
HBER = (HBER * 2)

EDIT: Just tried these and James Pond ends up at 720x400 @ 69Hz and an output identical to how it was before I adjusted VCR+20. If I increase the clock rate by 800KHz, it goes to 640x350 @ 70Hz, but again the output is identical to how it looked without adjusting VCR.

With Boogie Buggy, the screen is totally scrambled as before.

Under emulation, the geometry is correct for James Pond however the scrolling judders. Boogie Buggy displays correctly, however it looks like HDSR is too low, as I can see extra pixels on the left of the image.

Can you try the ADFFS216m module on the dev site and see if you get the same results on your monitor.
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: RiscPC support

Post by steve3000 »

Thanks for that Jon - yes I'll give 216 a try at the weekend.

I did get a little lost on your post above - around use of 'it' and 'the code' - are you referring to ADFFS or my VIDC1 to mode definition conversion code? I'm guessing ADFFS?
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: RiscPC support

Post by JonAbbott »

It - I'm referring to the code you sent me.
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: RiscPC support

Post by steve3000 »

JonAbbott wrote:It - I'm referring to the code you sent me.
Oh, really confused now. The VIDC1 to mode definition code should all be in BASIC? File: 'vdc1tomd.bas'

It converts the VIDC1 parameters from the register values to the pixel timings, as used in Mode definition files. I've not added VIDC20 to this yet, but will do, so we can switch between all formats.
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: RiscPC support

Post by steve3000 »

JonAbbott wrote:It - I'm referring to the code you sent me.
Ahhhhhh....

You're talking about the VIDC1 to 20 register translation code - the file I sent last month?

That makes sense... it's been a while since I sent that.

Ok... will review your questions and answer below...
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: RiscPC support

Post by steve3000 »

JonAbbott wrote:Looking at the code, it does seem to deviate from the VIDC20 docs. For example, instead of VXXX = N - 2, its using VXXX = N + 1.
Let's look at VCR for example:

The VIDC20 docs say "If N rasters required...value (N-2) should be programmed".

We are converting from a VIDC1 register value, so if you look in the VIDC1 docs, they say "If N rasters required...value (N-1) should be programmed".

So my code takes the VIDC1 value (ie. N-1) from the register, and subtracts 1 to get the VIDC20 value (ie. N-2).

Code: Select all

1940 CMP       R0,#&A0/4           ;above &A0 (vertical setting)
 1950 ADDGE     R0,R0,#104          ; convert to VIDC20 register number
 1960 SUBGE     R1,R1,#1            ; translate vidc20value=(vidc1value-1)
I don't see where you find N+1?
JonAbbott wrote: The HXXX parameters are similar, which is where ADFFS is probably going wrong. I coded ADFFS to match the VIDC20 docs, however that doesn't seem to translate VIDC1 parameters to the correct matching VIDC20 values.
I've only used the same VIDC1 and VIDC20 docs which you have for this. I've compared my code to RISC OS sources, to double check everything, but we're both working off the same information, I hope...

JonAbbott wrote: Reverse engineering your code, I believe its using the following corrections:

Vxxx = Vxxx + 1

sub = 18 (1/bpp)
sub = 10 (2/bpp)
sub = 6 (3/bpp)
sub = 4 (4/bpp)

HCR = (HCR * 2) + 2
HSWR = (HSWR * 2) + 2
HBSR = (HBSR * 2)
HDSR = (HDSR * 2) + sub
HDER = (HDER * 2) + sub
HBER = (HBER * 2)
Again, I'm not sure where these values are from, in my code I use the following (BASIC code shown, because it's easier to follow, the ARM code is a little optimised, but does the same):

Code: Select all

 2960 IF bpp=8 THEN sub=5
 2970 IF bpp=4 THEN sub=7
 2980 IF bpp=2 THEN sub=11
 2990 IF bpp=1 THEN sub=19
Then:

Code: Select all

 3010 IF vidc1reg=&80 THEN vidc20reg=&80:vidc20value=((vidc1value*2)+2)-8      :REM HCR
 3020 IF vidc1reg=&84 THEN vidc20reg=&81:vidc20value=((vidc1value*2)+2)-8      :REM HSWR
 3030 IF vidc1reg=&88 THEN vidc20reg=&82:vidc20value=((vidc1value*2)-1+1)-12   :REM HBSR (hbpch+1 VIDC1 fix)
 3040 IF vidc1reg=&8C THEN vidc20reg=&83:vidc20value=((vidc1value*2)-1+sub)-18 :REM HDSR (hbpch+1 VIDC1 fix)
 3050 IF vidc1reg=&90 THEN vidc20reg=&84:vidc20value=((vidc1value*2)-1+sub)-18 :REM HDER (hbpch+1 VIDC1 fix)
 3060 IF vidc1reg=&94 THEN vidc20reg=&85:vidc20value=((vidc1value*2)-1+1)-12   :REM HBER (hbpch+1 VIDC1 fix)
 3070 IF vidc1reg=&9C THEN vidc20reg=&87:vidc20value=(vidc1value*2)            :REM HIR
As I said, I'll grab ADFFS216m now, and have a play. I'll also pull up the source code and take a closer look to see where our conversion of VIDC1 differs.
Post Reply