RiscPC support

[steve3000]

Sorted.

Load ADFFS216s from the dev site (I've patched my translator code in here). Load your modified LCDgm 0.22. Turn on remapping. Load James Pond... And you get a picture very similar to the display you saw back on page 4.

Now switch off. Pull your VRAM out. Repeat the above and you get JP displayed perfectly. Job done

You weren't programming HDWR (new register on VIDC20) - this controls VRAM DMA, and if you don't programme it, you get the broken, but stable, picture. Glad to see we weren't 100% wrong in thinking it looked like a FIFO/DMA issue! You must have been very lucky to find that effect of shifting VCR - clearly this has a strange side effect of aligning VRAM DMA timings correctly.

It's easy to programme HDWR, I'll post up my fix shortly.

[JonAbbott]

So it was working all along!

If you modify the ADFFS source that's on the dev site, it matches the ADFFS module. I had the VRAM code in there, at the end of the CR code, but having tried various settings with little effect, I removed it!

[steve3000]

Ok, I'll take a look through that to see what VRAM code is there. It's quite an easy fix, but we need to keep track of the screen width in pixels from the difference between the values written to HDSR and HDER. Is there a variable to hold this value? We can reset it at each mode change to the default for that mode, then update this along with HDWR, every time HDSR and HDER are written.

Just tried an old 1Mb VRAM stick for fun - and the display break-up is different to what you saw, so I conclude you have 2Mb VRAM in your RPC.

[steve3000]

Also, do you realise that even under RISC OS 3.7, the physical screen memory address is mapped at &10000000 if no VRAM is present? But sits at &2000000 if 1 or 2 Mb VRAM is available...

Will this lead to remapping problems for non-VRAM computers, or is this all taken care of?

[JonAbbott]

It's quite an easy fix, but we need to keep track of the screen width in pixels from the difference between the values written to HDSR and HDER. Is there a variable to hold this value? We can reset it at each mode change to the default for that mode, then update this along with HDWR, every time HDSR and HDER are written.

Just tried an old 1Mb VRAM stick for fun - and the display break-up is different to what you saw, so I conclude you have 2Mb VRAM in your RPC.

We're only tracking HDSR/HDER when VIDC20_debug is enabled. It sounds like we need to track the registers regardless.

Working out DCTL isn't straight forward, as all the parameters change depending on the amount and type of RAM fitted and RAM speed. From looking at the RO source, BUS[1:0] is set to %11 for 2mb VRAM and %01 for less or DRAM. VRAM[1:0] and HDWR change depending on the amount of VRAM and screen width, VRAM[1:0] also changes based on VRAM bandwidth. Hdis is enabled if the calculation of HDWR doesn't drop the lower bit when adjusted for VRAM size and is disabled otherwise.

I've coded some of this over the past few hours, it's not exactly straight forward with so many variables. We now have a visible display in Boogie Buggy, although we're getting double images in all modes, so something is still wrong with it. Source and ADFFS 2.16n are on the dev site, the DCTL code is at the bottom of adffs.vectors.vidc_abort, its only set when HDER changes.

Will this lead to remapping problems for non-VRAM computers, or is this all taken care of?

We don't go near physical addresses, so should make no difference.

Whilst looking through the RO source, I found the following code, which might explain the cursor being incorrect in Caverns. I've yet to try this to see if it fixes the issue:

Code: Select all

        LDR     R14, [WsPtr, #CursorFudgeFactor] ; R14 = horiz display start
        BIC     R14, R14, #&FF000000    ; lbpp = 0, 1, 2, 3
        MOV     R14, R14, LSR #14       ; R14 = (m-19, m-11, m-7, m-5)/2

        MOV     R8, R2, LSR #2          ; put bits 2,3 (lbpp) into bits 0,1
        AND     R8, R8, #3              ; just look at these bits
        RSB     R8, R8, #3              ; R8 = 3, 2, 1, 0
        MOV     R9, #1
        ADD     R14, R14, R9, LSL R8    ; R14 = (m-3, m-3, m-3, m-3)/2
        MOV     R14, R14, LSL #1        ; R14 = m-3
        SUB     R14, R14, #3            ; R14 = m-6
        STR     R14, [WsPtr, #CursorFudgeFactor]

[steve3000]

We're only tracking HDSR/HDER when VIDC20_debug is enabled. It sounds like we need to track the registers regardless.

Working out DCTL isn't straight forward, as all the parameters change depending on the amount and type of RAM fitted and RAM speed. From looking at the RO source, BUS[1:0] is set to %11 for 2mb VRAM and %01 for less or DRAM. VRAM[1:0] and HDWR change depending on the amount of VRAM and screen width, VRAM[1:0] also changes based on VRAM bandwidth. Hdis is enabled if the calculation of HDWR doesn't drop the lower bit when adjusted for VRAM size and is disabled otherwise.

Ok, I wrote this too last night. So will compare my code to yours. I said it was 'easy' because its all in the RO source. I have all the zero page locations in my ZP map, so straight forward to read VRAM size, Bandwidth etc.

Tracking HDSR and HDER was the trickiest bit, but still not that bad.

Whilst looking through the RO source, I found the following code, which might explain the cursor being incorrect in Caverns. I've yet to try this to see if it fixes the issue:

Code: Select all

        LDR     R14, [WsPtr, #CursorFudgeFactor] ; R14 = horiz display start
        BIC     R14, R14, #&FF000000    ; lbpp = 0, 1, 2, 3
        MOV     R14, R14, LSR #14       ; R14 = (m-19, m-11, m-7, m-5)/2

        MOV     R8, R2, LSR #2          ; put bits 2,3 (lbpp) into bits 0,1
        AND     R8, R8, #3              ; just look at these bits
        RSB     R8, R8, #3              ; R8 = 3, 2, 1, 0
        MOV     R9, #1
        ADD     R14, R14, R9, LSL R8    ; R14 = (m-3, m-3, m-3, m-3)/2
        MOV     R14, R14, LSL #1        ; R14 = m-3
        SUB     R14, R14, #3            ; R14 = m-6
        STR     R14, [WsPtr, #CursorFudgeFactor]

Yes, 'CursorFudgeFactor' is the variable which LCDgm patches to correct the pointer position under RO3.1 - see LCDgm source file 'service' (stores m-6 to &10D4 on mode change) and recall the thread/discussion around Caverns and ManU under LCDgm v0.09. The code you've listed is for VIDC1, it is converting the VIDC1 HDSR register into the HCSR offset, hence needs to account for different offsets according to bpp of the mode. This will be different for VIDC20, since VIDC20 uses the same HDSR offset (m-18) for all bpps.

So I disabled this in v0.22 because I wasn't sure if the location or variable contents differ on RO3.5+.

EDIT: looking into the RO source the location is the same, but the contents have changed. VIDC20 (RO3.5+) uses m-17 in this location, and the VIDC20 equivalent code in 'vdudriver.v' to the segment you've included above is as follows:

Code: Select all

LDR     R14,[WsPtr,#CursorFudgeFactor]
BIC     R14,R14,#&FF000000
ADD     R14,R14,#(18-17)
STR     R14,[WsPtr,#CursorFudgeFactor]

[steve3000]

Further to my last post - I've now compared your code and my code (I've uploaded as 'ADFS216t'). Two very separate designs, but we both generate the same values for HDWR/DCTL ...and we both still fail to correct the double/broken image. Clearly there's more to this VRAM issue. I expect we need to set a register on the IOMD too...?

[JonAbbott]

Yes, 'CursorFudgeFactor' is the variable which LCDgm patches to correct the pointer position under RO3.1 - see LCDgm source file 'service' (stores m-6 to &10D4 on mode change) and recall the thread/discussion around Caverns and ManU under LCDgm v0.09. The code you've listed is for VIDC1, it is converting the VIDC1 HDSR register into the HCSR offset, hence needs to account for different offsets according to bpp of the mode. This will be different for VIDC20, since VIDC20 uses the same HDSR offset (m-18) for all bpps.

So I disabled this in v0.22 because I wasn't sure if the location or variable contents differ on RO3.5+.

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.

You didn't upload your DCTL source code for me to look at...so I started again from scratch as I couldn't sleep

I avoided poking around in ZP for values, as it's not forward compatible and went for legal calls to get the VRAM size. 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. Might be worth testing the latest ADFFS with just DRAM to see if it works correctly, as that's the only scenario where DCTL is correct at the minute.

With James Pond, increasing VCR by 4 fixes it and with Boogie Buggy, increasing VCR by ~20 fixes it (use CTRL-SHIFT-Up Arrow in-game to see what I mean), so we're very close. Seeing overscan modes working on the RiscPC is certainly good to see.

[JonAbbott]

The VIDC20 TRM states "When using VIDC20 with VRAM, bits [19:18] must be programmed"

I've searched the RO5 and RO3.7 sources and neither set bits [19:18] of DCTL. The static variables are there for them (DCR_VRAMDiv1, DCR_VRAMDiv2, DCR_VRAMDiv4), but they're unused.

Unless I'm missing something obvious, it looks like VRAM is permanently set to "disable". I can only guess that when in this state its driven by an external clock and not VIDC20.

[JonAbbott]

I believe we need to reduce VDER by 1 (the code is commented out at the minute), looking at both Pesky Musrats and Boogie Buggy, there's an extra row of pixels on the bottom that shouldn't be there.

EDIT: I've checked MODE 13, which is correct, so it's only games that are adjusting VDER that we see the problem.