After a bit of faffing around this evening looking at some PIAS discs for Daniel regarding a couple of games that LCDGameModes doesn't fix, it seems that the later versions of ADFFS have broken support for SquishFS.
I'm using the most up to date version of ADFFS downloaded from the FTP server this evening and the SFS module fails to load throwing an exception. Daniel mentioned that he uses version 2.09 without problems and I have version 2.08 installed side by side with the latest version.
SFS works just fine with 2.08 and 2.09 but not with the current ADFFS.
I assume there's some sort of conflict with ADFFS implementing DA's and SquishFS doing its dynamic decompression of discs which I expect is quite a memory intensive process.
Anyway I thought you'd want to be made aware of it.
Paul
SquishFS (SFS module) breaks on later versions of ADFFS
Re: SquishFS (SFS module) breaks on later versions of ADFFS
RO3.11 I presume?
Hopefully it's a bug and not SFS using the same address range!
Hopefully it's a bug and not SFS using the same address range!
Re: SquishFS (SFS module) breaks on later versions of ADFFS
Yes, RISC OS 3.11.
The PIAS 2 disks Daniel uploaded to the FTP server in the Kryoflux directory have SFS on them.
Paul
The PIAS 2 disks Daniel uploaded to the FTP server in the Kryoflux directory have SFS on them.
Paul
Re: SquishFS (SFS module) breaks on later versions of ADFFS
I'll do some debugging, probably won't be until the weekend though.
Re: SquishFS (SFS module) breaks on later versions of ADFFS
Managed to fix it, it's a bug in the APD handler where it reduced the memory after loading - it forgot to take account of the track table.
Fixed version and source on the dev site.
A word of warning though...those APD's are over the 900k size limit ADFFS sets for an APD. At a guess there are false positive FM sectors coming across which are inflating the size. If you're after PIAS2, grab F104860X from the Untested folder.
Fixed version and source on the dev site.
A word of warning though...those APD's are over the 900k size limit ADFFS sets for an APD. At a guess there are false positive FM sectors coming across which are inflating the size. If you're after PIAS2, grab F104860X from the Untested folder.
Re: SquishFS (SFS module) breaks on later versions of ADFFS
Hmm. No, those ones have no FM tracks in, those are just the DD streams. They come in at under 900k, albeit gzipped, by my reckoning?
d.
d.
Re: SquishFS (SFS module) breaks on later versions of ADFFS
They're converting to over 900kb of data for some reason, I've not analysed why. In MFM I think the one I looked at was 2mb, which seamed rather large to me, but it appeared to run okay once decoded.
Perhaps it picked up sectors in tracks 80-83? I can't think of any other reason for the size, as I say I didn't analyse it so am guessing.
Incidentally, only Fire & Ice uses tracks above 79 that I'm aware of, so you could default to 0-79 and have a parameter to include any extra tracks.
EDIT: A thought has just occurred, instead of starting at 900kb allocated when decoding an APD, it should start at half the size of the undecoded expanded APD. Don't know why I didn't think of that before, it can't possibly be any bigger than that after all.
Perhaps it picked up sectors in tracks 80-83? I can't think of any other reason for the size, as I say I didn't analyse it so am guessing.
Incidentally, only Fire & Ice uses tracks above 79 that I'm aware of, so you could default to 0-79 and have a parameter to include any extra tracks.
EDIT: A thought has just occurred, instead of starting at 900kb allocated when decoding an APD, it should start at half the size of the undecoded expanded APD. Don't know why I didn't think of that before, it can't possibly be any bigger than that after all.
Re: SquishFS (SFS module) breaks on later versions of ADFFS
Seems I did think of it before...but there's no way to find out the decompressed size in ZLib without first decompressing it! I'll leave it at the 900kb limit.JonAbbott wrote:instead of starting at 900kb allocated when decoding an APD, it should start at half the size of the undecoded expanded APD. Don't know why I didn't think of that before, it can't possibly be any bigger than that after all.