ADFFS 2.17 RC

Discuss ADFFS development and download test releases
Post Reply
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

ADFFS 2.17 RC

Post by JonAbbott »

I've put the release candidate of ADFFS 2.17 onto the dev site, which includes:

AutoVIDC 2.09
LCDGameModes 0.21b (autoloaded on <RO3.5, provided ADFFS$LCDGM set to "Y" in !Boot)
LCDGameModes 0.22d (autoloaded if VIDC20 present, provided ADFFS$LCDGM set to "Y" in !Boot)


Known existing issues
- Random crashing if ADFRemapVideoMemory used on Kinetic
- Hangs when shelling from the desktop if an HD floppy is mounted on RO3.5+
- adfs:Format doesn't work after loading ADFFS
- Will cause memory mapping conflicts if more than 13mb or RAM is allocated to Application space on RO3.1x

VIDC translation issues
- Caverns: Scrolling not working on RPC's
- Manchester United Europe: Pointer movement not smooth on RO3.7+
- Rockfall: Locks VIDC20
- Rotor: Flickers and randomly hangs


Basic testing done on the following platforms
A440/1 RO3.11
A4000 RO3.11
A5000 RO3.11
A7000+ RO3.71
RiscPC RO3.71 / ARM710
RiscPC RO3.71 / SA
RiscPC RO4.02 / ARM610
RiscPC RO4.02 / SA (not compatible)
RiscPC RO4.39 / ARM610
RiscPC RO4.39 / SA (not compatible)
RiscPC RO5.20 / ARM610
RiscPC RO5.20 / SA
Pi


Issues
RESOLVED - If ScreenSize is too low when ADFRemapVideoMemory is issues, it locks. It needs to increase DA 2 first if required. This is immediately obvious on the Pi, where DA 2 is 0 byte by default.
RESOLVED - RO5.20 IOMD: Wasn't loading LCDGameModes
RESOLVED - OS_Byte 113 is corrupting R14

- RO5.20 IOMD: Video memory remapping not working (Application space maps past &1000000)
- RO5.20 IOMD: Randomly reporting "Broken Directory" after mounting floppies (shelling from the desktop with Zarch and mounting Caverns in the desktop)
- RO4.x / SA: Abort handler is causing random problems, including possible stack corruption and random hanging
- RO4.x / SA: Screen memory is allocated in 1MB chunks
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: ADFFS 2.17 RC

Post by JonAbbott »

JonAbbott wrote:- If ScreenSize is too low when ADFRemapVideoMemory is issues, it locks. It needs to increase DA 2 first if required. This is immediately obvious on the Pi, where DA 2 is 0 byte by default.
This is fixed in RC3, which is on the dev site.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: ADFFS 2.17 RC

Post by JonAbbott »

I'll be releasing this as 2.17 very soon.

I can't test RPC RO4.x / SA but suspect there may be issues, particularly around screen memory allocation. I believe RO4/SA allocates VRAM in 1MB chunks, which knackers quite a few games.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: ADFFS 2.17 RC

Post by JonAbbott »

Fixed an issue with the loader, where it wasn't loading LCDGameModes on RO5.20 IOMD.

I'm trying to also softload RO4 (4.02 and 4.39), to test RO4/SA compatibility except it just Aborts continuously...hence how I ended up testing RO5.20, which does softload okay.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: ADFFS 2.17 RC

Post by JonAbbott »

Finally got softloading working on one of the RPC's, so can now quickly swap between OS's from RO3.71 up to RO5.20

As I suspected ADFFS is not compatible with RO4 if a StrongARM is present. The Abort handler causes all kinds of issues and the way RO4 allocates screen memory may be a show-stopper.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: ADFFS 2.17 RC

Post by JonAbbott »

JonAbbott wrote:- RO4.x / SA: Abort handler is causing random problems, including possible stack corruption and random hanging
I've started re-writing the abort handler to try to resolve this, the incompatibility is due to RO4's reliance on screen memory writes generating Aborts. It marks the screen memory as read only so it can enable screen caching, it subsequently uses the Abort to know when flush the CPU cache on VSync.

If an abort occurs in video memory, the ADFFS abort handler looks for the offending page in the opposite screen address, so if the abort occurs in the actual video memory range, it looks for the page in the legacy screen memory range and visa-versa.

The root cause is that screen memory is mapped in 1MB chunks, combined with the fact RO4 maps memory to 1F00000 it means that a write to the first page of screen memory causes a memory map conflict.

The next issue is that RO4/SA allocates memory from the start of the DA upwards, not from the end downwards as it does when a non-SA is present. I can't for the life of me think why they thought implementing memory differently, dependent on processor type, was a good idea.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: ADFFS 2.17 RC

Post by JonAbbott »

JonAbbott wrote:
JonAbbott wrote:- RO4.x / SA: Abort handler is causing random problems, including possible stack corruption and random hanging
I've started re-writing the abort handler to try to resolve this
Whilst coding this (it will be in 2.18 as it's a major re-write of the abort handler), I noticed two fatal bugs in the abort handler. I've implemented the fixes for both in 2.17 and updated the ZIP / source on the dev site.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: ADFFS 2.17 RC

Post by JonAbbott »

Found another bug where OS_Byte 113 was corrupting R14. I've back-ported the fix to RO2.17 and updated the ZIP / source on the dev site.
Post Reply