I've tested most of the multi-disc games that have Boot scripts, it looks like there are some issues around memory allocation since the change to a DA.
I suspect it's down to RMA space allocation as there are no longer large chunks of empty space. It's going to be a case of checking each game individually and working out the settings.
Multi-disc games post DA changes
Re: Multi-disc games post DA changes
Issues so far:
BlowPipe - R13 corrupt after changing disc (need to debug to see where it's getting corrupt)
Carnage Inc - At the point you swap discs, it's in BASIC, which blocks the memory allocation. Reserving memory for ADFFS should fix this
Cataclysm - Could be the same issue as Carnage Inc as it works when launched under the WIMP
DarkWood - The Boot script wasn't reserving ScreenMemory, so completely unrelated to the DA changes
BlowPipe - R13 corrupt after changing disc (need to debug to see where it's getting corrupt)
Carnage Inc - At the point you swap discs, it's in BASIC, which blocks the memory allocation. Reserving memory for ADFFS should fix this
Cataclysm - Could be the same issue as Carnage Inc as it works when launched under the WIMP
DarkWood - The Boot script wasn't reserving ScreenMemory, so completely unrelated to the DA changes
Re: Multi-disc games post DA changes
I've just been looking at BlowPipe. It works under VIDC translation on RO3.5 - so I'm sure there's a problem with the DA on RO3.1. I can sense days of painful debugging ahead of me!
I'm going to add a *ADFReserveMemory command and alter the boot script, to see if it's related. Both BlowPipe and Cataclysm take over various vectors for their protection, which may or may not be having an effect on the SWI's I'm calling to reallocate memory.
I'm going to add a *ADFReserveMemory command and alter the boot script, to see if it's related. Both BlowPipe and Cataclysm take over various vectors for their protection, which may or may not be having an effect on the SWI's I'm calling to reallocate memory.
Re: Multi-disc games post DA changes
Bizarrely it works when run under the WIMP on RO3.1
The only difference between the WIMP and Supervisor is about 10 instructions where ADFFS issues a Service_Memory service call, before taking the memory from the top of the application space. I have a hunch that MemLimit and ApplicationSpaceSize might be different, if that is the case ADFFS doesn't need to issue the Service_Memory and can just take memory from MemLimit down to ApplicationSpaceSize.
The only difference between the WIMP and Supervisor is about 10 instructions where ADFFS issues a Service_Memory service call, before taking the memory from the top of the application space. I have a hunch that MemLimit and ApplicationSpaceSize might be different, if that is the case ADFFS doesn't need to issue the Service_Memory and can just take memory from MemLimit down to ApplicationSpaceSize.
Re: Multi-disc games post DA changes
BlowPipe - think I've figured out what's going on. R13 isn't corrupt, its been set to the end of the application space by the game. When ADFFS takes memory, it's taking BlowPipe's stack!
Only way around this is to reserve memory before the game starts, or run it under the WIMP. I need to implement reserving memory next anyway, so I'll test it with this game.
Only way around this is to reserve memory before the game starts, or run it under the WIMP. I need to implement reserving memory next anyway, so I'll test it with this game.
Re: Multi-disc games post DA changes
I've added *ADFReserveMemory which has fixed BlowPipe by reserving 700KB in the boot script.
I can see a looming problem though. If DA's can't take memory from application space, delta writes wont be able to allocate more space for writes, we'll have to know how much to reserve up front or take a guess. I'm not sure how widespread this problem will be, it could be a particular C compiler that puts the stack at the end of memory, or simply this one game.
We can work around it in this case, by running BlowPipe from the WIMP - I'll post another thread on this.
EDIT: Forgot to mention the updated ADFFS module and source are on the dev site.
I can see a looming problem though. If DA's can't take memory from application space, delta writes wont be able to allocate more space for writes, we'll have to know how much to reserve up front or take a guess. I'm not sure how widespread this problem will be, it could be a particular C compiler that puts the stack at the end of memory, or simply this one game.
We can work around it in this case, by running BlowPipe from the WIMP - I'll post another thread on this.
EDIT: Forgot to mention the updated ADFFS module and source are on the dev site.
Re: Multi-disc games post DA changes
ADFReserveMemory is doing some weird things, I'm seeing RMA issues after it alters the DA (corruption and modules failing to load). This only happens when it's done from the Supervisor prompt though, under the WIMP it's okay.
Even more oddly, it happens on RO3.1 and RO3.5+ so it's not my DA code.
The code simply checks if the DA is larger than the size requested and increases it if it's not. I fail to see how that's causing all the issues I'm seeing.
Even more oddly, it happens on RO3.1 and RO3.5+ so it's not my DA code.
The code simply checks if the DA is larger than the size requested and increases it if it's not. I fail to see how that's causing all the issues I'm seeing.
Re: Multi-disc games post DA changes
Reserve issue now fixed, I've no idea what was causing it though. Copying the DA allocation code from .MemAlloc to the ADFReserveMemory code instead of BL'ing to MemAlloc, seems to have cured the issue.
Updated ADFFS module and source are on the dev site.
This incidentally fixes both Carnage Inc. and Catacylsm.
Updated ADFFS module and source are on the dev site.
This incidentally fixes both Carnage Inc. and Catacylsm.
Re: Multi-disc games post DA changes
I'm still seeing problems with swapping discs in 2.14b, neither Chuck Rock or Pesky Muskrats seem to swap on a physical machine. It works under emulation with the same memory config which is somewhat confusing.
I've also noticed that after ejecting a floppy, Discop and Miscop aren't handing back to ADFFS under emulation, but do on physical.
All very odd!
I've also noticed that after ejecting a floppy, Discop and Miscop aren't handing back to ADFFS under emulation, but do on physical.
All very odd!
Re: Multi-disc games post DA changes
This issue looks memory related as Chuck Rock does work from the Desktop (provided you do *ADFS / *DRIVE 0 first), its launching from the Supervisor prompt that causes the issue. I'll do some debugging, one possibility is the memory reservation isn't working correctly.JonAbbott wrote:I'm still seeing problems with swapping discs in 2.14b, neither Chuck Rock or Pesky Muskrats seem to swap on a physical machine. It works under emulation with the same memory config which is somewhat confusing.
This seems to have cured itself without making any changes to the code, I won't lose any sleep over it!JonAbbott wrote:I've also noticed that after ejecting a floppy, Discop and Miscop aren't handing back to ADFFS under emulation, but do on physical.