Vinit, Vstart, Vend

[JonAbbott]

Steve, am I correct in thinking that Vinit is used as the start address of the frame, which stops at Vend or VDER, whichever comes first. Where does Vstart come into it? The VLSI manual doesn't make that clear.

I'm using your Hscroll code to get it working on both IOMD and the Pi, as I've yet to find a game that alters Vinit. I'm guessing the reason this is the case is because most games are written for 1mb machines and the extra memory required when altering Vinit in dual frame display doesn't leave a lot in application space. I expect it's only use is in scene demos.

[steve3000]

Steve, am I correct in thinking that Vinit is used as the start address of the frame, which stops at Vend or VDER, whichever comes first. Where does Vstart come into it? The VLSI manual doesn't make that clear.

I'm using your Hscroll code to get it working on both IOMD and the Pi, as I've yet to find a game that alters Vinit. I'm guessing the reason this is the case is because most games are written for 1mb machines and the extra memory required when altering Vinit in dual frame display doesn't leave a lot in application space. I expect it's only use is in scene demos.

Almost right.

Vinit is the start address corresponding to the uppermost left hand pixel. Unless VBSR > VDSR of course...in which case you need to jump forward by however many lines are hidden by the top border. (And for purposes of this, I'm ignoring horizontal borders, which can also be used to cover up the frame pixels).

Output continues until Vend is reached, or VDER or VBER are reached, whichever is reached first.

If VDSR or VBSR is reached then no more output during this frame, and next frame will start back at Vinit, as above.

However if Vend is reached before VDSR or VBSR, then output continues in this frame, starting at Vstart.

This enables vertical hardware scrolling, eg when you press f12. It is used by pretty much every vertical scrolling game, because it is a lot easier to implement than horizontal scrolling.

I have some vertical scrolling code somewhere... I'll dig it out...

[JonAbbott]

However if Vend is reached before VDSR or VBSR, then output continues in this frame, starting at Vstart.

Obvious when you think about it

[JonAbbott]

I'm struggling to get Hscroll to work. RedSquirrel goes into some weird resolution when ADFFS is loaded on both RO3.1 and RO3.7, RPCEmu seems okay but its not smooth and you can see the redraw that should be offscreen - the Pi does the same thing. I can't fathom out how ADFFS is breaking it on RO3.1, it should affect it.

Under RPCEmu there appears to be what looks like DMA overrun as the end of the screen isn't wrapping around at the correct point. I think I need to reduce Vend when VRAM is present, as per MemSizeIOMD_notSA in the RISC OS source

The other problem I've noticed is that as RPCEmu has a bug in its memory access, you can write to 3600000 in User mode and lock the machine up. I've sent repro code so they can hopefully fix that.

On RedSquirrel, writing to 3600000 does strange things.

On physical writing to 3600000 has the desired effect in User mode, However Hscroll doesn't set either the screen width correctly or perform the hardware scroll implying there is something mapped to 3600000 with SVC access. I've confirmed this by switching Hscroll to do the write in User, which triggers ADFFS to take over. Under this I see the same result as RPCEmu...hardware scrolling that's jurky and DMA overrun.

[JonAbbott]

RedSquirrel goes into some weird resolution when ADFFS is loaded on RO3.1

For some reason it needs LCDGameModes loaded to work under RedSquirrel, I can't get it displaying correctly under RO3.7 though, it's a scrambled mess.

Under RPCEmu there appears to be what looks like DMA overrun as the end of the screen isn't wrapping around at the correct point.

I've fixed the DMA overrun by mirroring what the RO drivers do: /HWSupport/VIDC20Video/s/GVect
As for the screen width, its simply wrong under RPCEmu, it doesn't look like RPCEmu is taking account of HDSR/HDER.

On RedSquirrel, writing to 3600000 does strange things.

This seems to be the case on physical as well, although PRM5a-41 states that 3600000-3700000 is reserved for future expansion, so there shouldn't be anything mapped there.

On physical ... I see the same result as RPCEmu...hardware scrolling that's jurky and DMA overrun.

Note, that's on a RPC with 1MB VRAM. The DMA overrun is fixed, however the screen that's wrapped flickers as if it's blank on every other frame.

On a RPC with 2MB VRAM Hscroll locks the machine on a blank screen. I can't find any documentation on how to program IOMD so this is all very frustrating.


Steve...I need your assistance to track down the issues. The latest source and builds are in /development/32bit/CPU, you want ADFFS400 for RPC and the source in question is adffs.vectors.memc_abort ._RO5_IOMD
To get Hscroll working, you need to comment out all the code that switches in/out of SVC - at least until I figure out what's at 3600000.

EDIT: I've just tried Hscroll under GameOn! and it suffers the same problems...jerky scrolling that doesn't work in SVC mode and DMA overrun. So...GameOn! doesn't support hardware scrolling as indicated...well it does in User mode.

From reading the RPCtrm1-15/16 it states Vinit/Vend must be on a half SAM length boundary with VRam (2048 bytes for 2mb VRAM, 1024 bytes for 1mb VRAM) - this doesn't seem to be the case, however it does imply that hardware scrolling will never work correctly on a RPC with VRAM. With DRAM, the boundary is a quad word (16 bytes), which matches MEMC1 I believe, so it may work without VRAM.

GameOn! hangs the machine with no VRAM, ADFFS works but its still jerky so I'm none the wiser.

Incidentally, I OCR'd the RPC trm and put it on the dev site: RiscPCtrm-OCR.pdf

[JonAbbott]

To get Hscroll working, you need to comment out all the code that switches in/out of SVC - at least until I figure out what's at 3600000

This is now resolved 2.29d onward maps the section out, if you could take a look at Hscroll with ADFFS on an RPC, I'd appreciate it.

[JonAbbott]

Whilst testing SA, I noticed Pesky Muskrats doesn't use OS_Byte 113, but writes to MEMC Vstart / Vend instead.

Running under MEMC emulation, the first frame is okay but the second looks as below. Note how it changes based on VRAM size which indicates the issue may be SAMLength related.

1MB VRAM

muskrats_IOMD_1MB.png (48.46 KiB) Viewed 17657 times

2MB VRAM

muskrats_IOMD_2MB.png (48.69 KiB) Viewed 17657 times

EDIT: I've managed to fix it for 1MB VRAM. 2MB is no longer striped as in the picture above, although the 2nd frame is offset by about half a screen.
EDIT2: Now all fixed, Pesky Muskrats is correct on A7000 and RISC PC with 1/2MB VRAM. Hscroll also works, although its highlighted an issue in that *ScreenLoad goes to a non-standard MODE number. I'll need to figure out how to work out the actual MODE.

[JonAbbott]

I've done some further testing, Caverns scrolling is improved on IOMD but still not correct - it's jerky. I suspect IOMD doesn't support the same byte boundary that IOC did, currently it's 16 bytes. I'll try reducing it on the off chance it may work.

Although I initially thought Hscroll was working, now I've added a fix for *ScreenLoad I can see the pixels after the wrap at Vend aren't quite right on every alternate frame.

Hscroll_IOMD1.png (71.32 KiB) Viewed 17648 times

EDIT: It's the frame at &2000000 that doesn't wrap correctly.

[JonAbbott]

Somewhat improved now, by cross referencing the ARM7500 and RPC TRM I've managed to work out the restrictions and have both frames mostly correct.

The only issue remaining is that as there's a restriction on Vstart and Vend needing to be aligned to 2KB for 2MB VRAM and 1KB for 2MB VRAM, as Vinit drifts N bytes from that boundary, the first N bytes from Vstart seem to repeat most of the 1st raster. What is also odd is that it only seems to affect the frame that starts at the start of the physical buffer.

I've turned off the image in Hscroll, so you can see more clearly what's happening:

Frame 0 repeats most of the 1st raster several times

Hscroll_f0.png (14.83 KiB) Viewed 17643 times

Frame 1 looks okay

Hscroll_f1.png (13.9 KiB) Viewed 17643 times