RiscPC support

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

Re: RiscPC support

Post by steve3000 » Sun Jul 21, 2013 8:32 pm

JonAbbott wrote:I implemented CursorFudgeFactor in ADFFS...the point I'm making is that RO changes the value based on lbpp, which may explain why Caverns is out slightly.
It doesn't vary with lbpp on RO3.5+ - look carefully where you found that code, it's conditionally assembled if 'Arthur' is set, however if 'VIDC20' is set, it assembles the non lbpp specific code which I posted above.
JonAbbott wrote:You didn't upload your DCTL source code for me to look at...so I started again from scratch as I couldn't sleep :roll:
Sorry, it's up now - the 'vidc_abort' file.
JonAbbott wrote:I avoided poking around in ZP for values, as it's not forward compatible and went for legal calls to get the VRAM size.
Looks good, never considered SWIs during Data Aborts - I guess they'll be fine unless they cause another...

Although we're patching ZP for the CursorFudgeFactor, so can't escape the incompatibility problem.
JonAbbott wrote: I think the only code I've got to add is to calculate VRAM[1:0] based on VRAM speed/pixel clock, which may fix it.
I've not done that. I thought VRAM was externally driven, and as you say - RO doesn't set those bits. So programming to '00' I guess must count...

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

Re: RiscPC support

Post by JonAbbott » Sun Jul 21, 2013 10:07 pm

ADFFS 2.16o module and source on dev site. I've rewritten the Hdis and Horizontal code, which now uses a table for the correction values. I've also put the correction values back to match the VIDC1 / 20 TRM's, instead of the tweaked values we previously had for pokemode (they're commented out)
steve3000 wrote:
JonAbbott wrote:I implemented CursorFudgeFactor in ADFFS...the point I'm making is that RO changes the value based on lbpp, which may explain why Caverns is out slightly.
It doesn't vary with lbpp on RO3.5+ - look carefully where you found that code, it's conditionally assembled if 'Arthur' is set, however if 'VIDC20' is set, it assembles the non lbpp specific code which I posted above.
Well spotted (I had to use notepad to figure it out!), back to the drawing board for Caverns then.

EDIT: If I increase VCR by 2, stock MODEs 0, 9, 13, 15 work. However, for games that overscan horizontally it needs to go up more. Caverns for example is correct with VCR+2, James Pond with VCR+18 (although goes to 720x400), Boogie Buggie/Pesky Muskrats with VCR+36 (although go to 640x480)

Sounds related to lbpp, as Caverns is 2bpp, James Pond 4bpp and Boogie Buggie/Pesky Muskrats 8bpp.

EDIT2: Have coded this into ADFFS216p on the dev site, everything now displays (in the wrong resolution and refresh rate of course), but at least they're all visible now :)

I've noticed Caverns is juddering when scrolling, so something is out slightly, possibly only affecting 2bpp.

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

Re: RiscPC support

Post by steve3000 » Sun Jul 21, 2013 11:22 pm

Reading the docs closely again. Is the ADFFS VIDC20 External register code correct? RO does some rather convoluted switching on and off of test bits in that register during mode change...

I wonder if our broken screen could be down to that register? There's a lot of LCD settings on that register - particularly around dual panel screens, but if so, then why does it work from DRAM...

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

Re: RiscPC support

Post by JonAbbott » Sun Jul 21, 2013 11:29 pm

steve3000 wrote:Reading the docs closely again. Is the ADFFS VIDC20 External register code correct? RO does some rather convoluted switching on and off of test bits in that register during mode change...

I wonder if our broken screen could be down to that register? There's a lot of LCD settings on that register - particularly around dual panel screens, but if so, then why does it work from DRAM...
The code for setting it is set_HV_sync at the bottom of adffs.vectors.vidc_abort. Its set when a CR is seen and sets HSYNC / VSYNC, DAC's and ereg. Everything else is set to zero.

What does ereg[1:0] do in a RiscPC? That's the only thing that stands out, it's current set to %11
I've no idea what ECK is, it's not documented.

EDIT: If its working for DRAM, it's obviously memory related. It's as if the FIFO has run ahead on every other frame, so the first few rasters are missing. At what point does the VRAM reset to the start of the screen and start buffering into the VIDC FIFO? What's the effect of increasing VCR?

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

Re: RiscPC support

Post by steve3000 » Mon Jul 22, 2013 7:09 pm

Check RiscPC TRM page 2-13. Although what you have is probably correct...

IOMD does have several VRAM-related registers, so may need investigation.

Just had a thought to try. Load the LCDgm mode defn file. Load ADFFS and LCDgm. Enable ADFFS remapping, but keep LCDgm module off. Enter Mode 13 (should enter the LCDgm mode defn file version of Mode 13). Now enable LCDgm module (which will override the mode defn file) and enter Mode 13 again, from Mode 13. This will trigger the LCDgm module and ADFFS translation, but on top of the correct LCDgm mode from the definition file. Does it work?

If it does, then the broken screen is because we've missed out a register or setting somewhere in the translation, and RISC OS has fixed it for us by setting it from the mode definition file.

If it doesn't work then the broken screen is our mistake - we're mis-translating something, or setting a register incorrectly.

I'll try that tonight...

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

Re: RiscPC support

Post by JonAbbott » Mon Jul 22, 2013 8:09 pm

steve3000 wrote:Load the LCDgm mode defn file. Load ADFFS and LCDgm. Enable ADFFS remapping, but keep LCDgm module off. Enter Mode 13 (should enter the LCDgm mode defn file version of Mode 13). Now enable LCDgm module (which will override the mode defn file) and enter Mode 13 again, from Mode 13. This will trigger the LCDgm module and ADFFS translation, but on top of the correct LCDgm mode from the definition file. Does it work?
Like your thinking...

It works with LCDgm on ...640x350 @ 70Hz as expected and visibly correct.

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

Re: RiscPC support

Post by steve3000 » Mon Jul 22, 2013 8:36 pm

Exactly!

Just tried it myself. Works fine when selecting the default modes, but doesn't solve the broken screen for JamesPond...

JP uses a 320x200 screen size IIRC?

So is there something memory/VRAM related which we need to be doing with the IOMD (presumably) when setting the screen to a different size? Something like two Vinit/Vend pointers maybe, one for each bank?

Think we're getting close...

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

Re: RiscPC support

Post by JonAbbott » Mon Jul 22, 2013 8:51 pm

Time to consult the MODE change code in RO 3.7 (he says trying to find it!)

EDIT: It's here, search for "DbgFilename". It starts at label 20 a few lines below.

EDIT2: The only difference I can see is that it updates ZP entries. I think you need to double check I've not missed something.

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

Re: RiscPC support

Post by steve3000 » Mon Jul 22, 2013 11:59 pm

Look at '80' onwards.

Not had time to go further, but this could be interesting...

Code: Select all

BL      SetVendDefault                  ; set to ScreenEndAdr-16

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

Re: RiscPC support

Post by JonAbbott » Tue Jul 23, 2013 12:41 am

That would match my description:
JonAbbott wrote:It's as if the FIFO has run ahead on every other frame
However, as Service_ModeChange is called after the OS has already changed mode, aren't the MEMC registers already setup correctly?

EDIT: I wonder if it's something we haven't considered...such as having to prep VIDC before writing certain parameters? I notice RO goes through a rather convoluted process to write fsynreg. I think its there to prevent the PLL from overrunning on the first frame after the MODE change.

I've upload ADFFS 2.16q module and source to the dev site. Added code to adjust V parameters by the configured TV value and PLL reset code.

Post Reply