Caverns

[JonAbbott]

Two issues we need to resolve with this one:

1. The mouse pointer not appearing correctly on RO3.70+
2. Scrolling not working on a RiscPC

[JonAbbott]

I've noticed that if you really slow the machine down under emulation, the pointer randomly appears. I'm searching through the RO source, to see if does anything.

[steve3000]

I've noticed that if you really slow the machine down under emulation, the pointer randomly appears. I'm searching through the RO source, to see if does anything.

RISC OS redefines the pointer back to the RO defined pointer on VSync, well known (annoying) feature of RO. Games (like Caverns) that want to use the pointer as a sprite with larger dimensions than the RISC OS pointer need to redefine it on every VSync, after RISC OS, by writing directly to VIDC. Games (like ManU) which want to use the pointer as a sprite of the same size or smaller dimensions than the allowed RISC OS pointer size can just redefine the RISC OS pointer rather than write to VIDC.

Think I've spotted this code in the VSync handler section of RO source.

[JonAbbott]

Think I've spotted this code in the VSync handler section of RO source.

Can you point me to it, as I've been searching for two days and still can't find it!

[Phlamethrower]

UpdatePointer looks like it's the code you're looking for. This is from the 3.7 sources: http://www.riscosopen.org/viewer/view/c ... arkup#l411

I'm assuming it's the LCDSupport = TRUE version of the function which was being used at the time, especially as the non-LCDSupport version appears to have been deliberately hobbled by indenting it by 4 chars to break all the label definitions.

RISC OS 3.6 version is here: http://www.riscosopen.org/viewer/view/c ... arkup#l328

Unfortunately that's as far back as CVS goes, at least for that file.

If you want to get sources for a specific version of a module, it's best to do so via CVS. E.g. this should get you a copy of the 3.7 kernel sources (RO_3_70 is the tag to fetch, as listed in the file histories in the web viewer)

Code: Select all

cvs -d :pserver:anonymous@riscosopen.org:/home/rool/cvsroot login
cvs -z9 -d :pserver:anonymous@riscosopen.org:/home/rool/cvsroot co -r RO_3_70 castle/RiscOS/Sources/Kernel

[JonAbbott]

There's no diffence between the pointer code on RO3.6 and RO3.7, which leads me to believe that perhaps the order in which things are called on a VSync triggering have changed.

I'll try a callback to update the pointer if its height is above 32. I've already tried updating it on VSync, which made no difference.

Another alternative is to add a check to the ADFFS SWI handler for pending VCSR / VCER changes, although timing the write will be tricky.

A last resort could be altering the values in VduDriverWorkSpace and leave RO to write the correct values. I wonder if that's what Manchester United does to get the smooth pointer motion?

[JonAbbott]

Even writing the VCSR / VCER values on every SWI entry makes no difference. That hints at a timing issue in the Caverns code, I'll debug the Caverns code and find out what it's doing.

I have however found an issue with LCDgm enabled on RO3.1 (and using VIDC translation on RO3.5+), the pointer is out by H:+1, V:+8. You have an H adjust value in LCDgm, is it definitely correct for mode 9? The vertical will be down to Caverns not expecting HDSR to have changed, I can correct in ADFFS but I doubt there's anything we can do for RO3.1x

[JonAbbott]

I'll debug the Caverns code and find out what it's doing.

In GameCode at 4AD28 it claims the OS_Byte vector and ignores OS_Byte 19 if R1 isn't set to &F7, that could be how it's preventing RO3.6 and below from updating the VIDC1 pointer registers, by blocking it's wait for VSync when the pointer is changed. I can't think why else you'd want to block OS_Byte 19.

The pointer set code (4ACD0) sets a fixed X, Y and height of 140 pixels, and is called at five points: 44798, 49E0C, 49E4C, 4B33C. 49E44 issues a VSync, 49E48 calls a subroutine that sets HDSR and HDER and the screen base address via OS_Word 22, 49E4C then calls the pointer set code. So it's pretty much immediately after a VSync...with any delays the VIDC translation is adding of course.

The main game loop code is 49A60-4A138

I can correct in ADFFS but I doubt there's anything we can do for RO3.1x

It uses hardcoded values for HCSR, VCSR and VCER, which are stored in GameCode at 4AD08 so I've fixed the values in the Boot Script for <RO3.5.

The H:+1 turned out to be under translation only, so I've fixed that in the ADFFS H correction table for 4bit modes. I suspect it's actually a rounding issue due to the VIDC1 parameters being /2 for HDSR etc. To correct the V:+8 in ADFFS, I've added a correction value for VCxR for each bitdepth and set to -8 for 4bit modes.

[JonAbbott]

2. Scrolling not working on a RiscPC

I've ruled out FIFO and Hdis. When I say it goes bonkers on the RPC...here's a frame by frame shot of what it does as it scrolls horizontally.

Caverns_2mb_bonkers1.png (23.68 KiB) Viewed 17357 times

Caverns_2mb_bonkers2.png (17.16 KiB) Viewed 17357 times

Caverns_2mb_bonkers3.png (39.95 KiB) Viewed 17357 times

Caverns_2mb_bonkers4.png (29.39 KiB) Viewed 17357 times

Caverns_2mb_bonkers5.png (66.83 KiB) Viewed 17357 times

This final shot is what you see if you scroll vertically and horizontally a bit.

Caverns_2mb_bonkers6.png (16.78 KiB) Viewed 17357 times

I don't think VIDC20 is very happy!

EDIT: On further investigation, this is what happens when there's no VRAM (seems my 2mb strip is faulty). Behaviour is identical on both ARM610 and StrongARM. With 1MB or 2MB of VRAM there's no corruption, just juddering when scrolling horizontally.

[JonAbbott]

ISSUE 1 solved

At 49E34 a subroutine is called that issues OS_Byte 106, 2 (Select pointer / activate mouse) - it would appear the behaviour of OS_Byte 106 changed between RO3.60 and RO3.70.

It's easily fixed in the Boot script by a NOP at 49E34. The updated Boot script (F10072) is on the dev site in the Obey file area, just drop it into !ADFFS.Obey to override the Obey file in the JFD image. This script fixes both the pointer V:+8 issue on RO3.1 and the pointer not appearing correct on RO3.6+