ADFFS 2.18 beta

[JonAbbott]

To get ADFFS working on RO4/SA I've had to track OS_ChangeDynamicArea, implement Service_MemoryMoved and completely rewrite the abort handler, I also took the opportunity to optimize the code so it's about half the size it used to be. It's still not working 100%, although I've got it all running on everything except RO4/SA, which is a start.

There's two outstanding issues I need to resolve.

1. OS_ChangeDynamicArea needs to reset DynamicArea 2's pages before passing off to the OS. For some reason, calling OS_SetMemMapEntries causes the machine to hang. I suspect it's issuing Service calls and either corrupting registers or causing a loop. The only legal thing I can try here is to only issue OS_SetMemMapEntries on pages that have actually moved to see if there a bug when setting pages to the same location.

2. On RO4/SA there seems to be an issue with early/late aborting (eg STM R0! either increments R0 or resets it back to the original value on an Abort), for some reason the code which handles this doesn't work on RO4/SA, but does on everything else.


I've put 2.18d on the dev site, as it now includes the obey.zip file to override JFD Boot Scripts, I've also included all the trackers as I'm starting to make use of them where they work on later OS's. The other notable change is "Boot floppy" now boots within the WIMP, this will break quite a few games so you can hold CTRL to use the old method, the dialogue that comes up explains things. I've updated Zarch to work with either method, but haven't tested any other games yet.

[JonAbbott]

2.18e module and source on the dev site, the issues detailed above are now resolved.

I've struggled for days to get RO4 with a StrongARM to work, it would hang immediately when mapping memory back to DA2. It turns out RO4 has it's own abort handler that maps the memory back into DA2's address space, if we don't let that do the re-mapping RO4 hangs. Begs the question, if they went that far with their implementation, why didn't they add the 8 additional instructions required to implement RO3.1 compatibility.

Either it forces the StrongARM into late abort mode, or has a full abort handler with register fix-up to correct for early abort mode, it couldn't possibly work otherwise. I've not checked, it may be that the SA's late abort mode works correctly, in which case RO4 can just SUBS PC, R14, #4 to exit and set CPSR.

What I've yet to test, is the effect of this on screen caching - currently it will be on when RO4 maps the page back. That shouldn't cause a problem, as the caching was turned off when it was mapped to RO3.1 address space by ADFFS, however should the game then use the OS to update the screen there may be flickering prior to RO4 flushing the cache on the next VSync.


I've further improved the abort handler and fixed a bug in the handling of LDR Rd, [Rn, {+-}Rm, RRX]!. Later, I'm going to write some test code to double check all the pre-indexed LDR/STR's with write-back and LDM/STM Rn! instructions are being rolled back correctly. I also need to test and implement a fix the StrongARM errata, which I'm still struggling to find a complete list of. All the ones I've found so far are trivial to fix, so I'm not sure what all the fuss was around StrongARM and memory management back in the day - unless there's an errata I've yet to find.

[JonAbbott]

I'm going to write some test code to double check all the pre-indexed LDR/STR's with write-back and LDM/STM Rn! instructions are being rolled back correctly

Slowly getting this done, although it threw up an issue with the code that detects early / late abort mode.

To detect early / late, the code has to actively generate two aborts (LDMIA Rn!, {Rd} and LDR Rd, [Rn, #immed_12]) and see if Rn has been updated (Late Abort Mode) ... easy enough. The problem is which address to use to generate an abort, I initially used 1FFFFFC but switched to FFFFFFFC in 2.18 to fix the Pi. Trouble is FFFFFFFC is valid on Acorn machines, so I'll change it back to 1FFFFFC and report an error if it doesn't generate an abort - this will prevent the abort handler starting if Application space overlaps the RO3.1 screen address range.

Provided WimpSlot is used prior to ADFRemapVideoMemory, it should still work on the Pi.

[JonAbbott]

All pre-indexed LDR/STR / STMxx instructions have checked out okay and are being corrected okay by the abort code.

2.18f module and source on the dev site, to correct the early / late abort detection.

There's two other issues I need to look into:
1. Zarch causes an abort a few seconds after loading, most of the time. Why it works occasionally is somewhat bemusing.
2. "Boot floppy" locks one of my RPC's if I let the !Boot sequence run. It loads updated FileCore/FileSwitch and ADFS modules, so I suspect they're at fault, not ADFFS. Need to confirm though.

Incidentally, there's an update obey.zip file on the dev site. Don't attempt running Zarch without it (ensuring you have SparkFS running first of course) and use "Boot floppy". Should you wish to run Zarch manually, ensure you issue ADFProtectCMOS first, or it will unplug all your modules.

[JonAbbott]

1. Zarch causes an abort a few seconds after loading, most of the time. Why it works occasionally is somewhat bemusing.

Turns out this is caused by SparkFS when it closes obey.zip a few seconds after it's read the boot script. It happens if Zarch is run from an obey script in a ZIP file, regardless of ADFFS version.

[JonAbbott]

Finally have RO4's screen caching disabled, which took some head scratching. It would appear OS_Memory blocks cacheability changes, if you don't set bit 16 in R0 - which is an internal flag. It's mentioned on line 107 of the MemInfo source.

2.18g module is on the dev site. At the minute, it gets RO4 to return back to our code after it's handled the abort. Our code then disables the caching for the page in question. I'm going to see if it can be turned off for all screen pages when *ADFRemapVideoMemory is initially called, which will be a lot neater.

[JonAbbott]

2.18g module is on the dev site. At the minute, it gets RO4 to return back to our code after it's handled the abort. Our code then disables the caching for the page in question.

This isn't actually working, I must have booted to another RO version when I tested it so back to the drawing board. I also misread the OS source code, bit 16 isn't used. It shifts bits 0 to 30 up to bits 1 to 31, hence the confusion.

[JonAbbott]

2. "Boot floppy" locks one of my RPC's if I let the !Boot sequence run. It loads updated FileCore/FileSwitch and ADFS modules, so I suspect they're at fault, not ADFFS. Need to confirm though.

It was FileCore / FileSwitch or the updated ADFS causing the locking. Its related to OS_FSControl 15, which looks like it may be causing stack corruption on exit. I've not investigated further as these modules aren't standard versions.

[JonAbbott]

It turns out RO4 has it's own abort handler that maps the memory back into DA2's address space, if we don't let that do the re-mapping RO4 hangs. Begs the question, if they went that far with their implementation, why didn't they add the 8 additional instructions required to implement RO3.1 compatibility.

It seems a very complicated abort handler now that I've studied the code (/castle/RiscOS/Sources/Kernel/s/Attic/VMSAv6,v), over 300 instructions vs 64 for ADFFS.

The screen cleaning code is in /castle/RiscOS/Sources/Kernel/s/ARM600,v in the section ChocolateScreen, it sets up the screen area on CPU domain 1, with write disabled. This triggers an abort (actually a domain fault), RO then enables write access to the zone and flags the screen as needing cleaning on the next VSync. In theory, this should prevent flickering although in reality it fails badly in games - possibly due to the timing of the VSync code, which is called after all other VSync code has been dealt with. This possibly pushes it past the flyback period and causes some games flicker.

EDIT: There's some discussion of the RO abort handler here.

EDIT2: I was looking at the RO5 abort handler, the RO4 one is here, search for DAbPreVeneer

[JonAbbott]

Looking at the ScreenMode_ChocolateControl section of /castle/RiscOS/Sources/Kernel/s/vdu/vduswis,v it would appear there's an SWI to control screen caching:

OS_ScreenMode 4

Code: Select all

;   r0 = reason code (4)
;   r1 = cached screen control flags
;          bit  0     set to suspend cached screen for this mode
;          bit  1     set to suspend all screen cleaning (foreground and VSync)
;          bits 2..30 reserved for future expansion (must be 0)
;          bit  31    must be 0 when setting flags
;        or r1 = -1 to read current flags
;   r2 = sets VSync cache cleaner laziness (to be used when not suspended)
;        1 means VSync cleans on the 1st vsync after 'screen needs clean' is triggered and not reset by foreground
;        2 means VSync cleans on 2nd vsync
;        3 means VSync cleans on 3rd vsync
;        or r2 = -1 to read current vsync control value
;        other values reserved (undefined behaviour)
; exit: r1 = current value of cached screen control flags (either for r1=-1 on entry,
;            or value actually invoked given any restrictions for current platform)
;       r2 = current value for VSync cleaner control (similar considerations to r1 exit)

Unfortunately it doesn't seem to work. Looking at the code that's supposed to turn the caching off for the screen area (Screen_makevanilla in /castle/RiscOS/Sources/Kernel/s/ChangeDyn,v), I can't see the code that disables the caching for the screen memory pages, it seems to only flush the cache.