ADFFS 2.60 released

ADFFS 2.60 is now available from the JASPP site, which adds more game support for modern machines and has some improvements over the previous build.

This hits somewhat of a milestone, as pretty much every game the project has floppy images for, now run on the Pi (excluding titles that rely on the Wimp or require CDROM emulation.) That’s 193 unique games, or 239 including release variations, such as SA or RPC versions.

To date, the project has released 63 titles (55 unique) and have gained permission to release a further 54. In total, 367 unique commercial games were released for the Archimedes or RiscPC.

Thanks for all your hard work with this. I just played a few levels of Lemmings for old time’s sake :)

I do have a question though – what’s the process for running games that aren’t supplied as images? For example, the 2.60 download page contains a link to Dune II, which is supplied as zip file containing the app directly. How do I get that working?

What’s the process for running games that aren’t supplied as images?

For Dune II v1.32 you replace the contents of its !Run with the contents of its ADFFS boot script, which you can find in !ADFFS.Obey. The filename of the script matches the game ID, F1053501 in this case.

Some of the other games I’ve linked too may also require you to remove the first few lines of the boot script, up to the first line break, which select ADFS and set Obey$Dir to point to the floppy.

With other games that I haven’t provided a link too, if none of the above advice works, you can either try to figure it out using the boot script as a basis, or create a new thread in the JASPP General forum and I’ll see what I can do. If you go with the later, bare in mind that some games have taken weeks to get running as I generally fix any Page Zero access bugs and if the code is significantly different from the release version I’ve based the ADFFS boot script on, I’ll be starting from scratch.

If you’d like to request a game I’ve yet to get working on 32bit, again ask on the JASPP site. Games that require the Wimp aren’t currently supported as RISCOS doesn’t have any public SWI’s for task switching.

Presumably ADFFS does not yet work on ARMX6 where no high vector build is supported (a pre June 2016 low vector build is needed on ARMX6 so as not to break Aemulor).

ADFFS does not yet work on ARMX6 where no high vector build is supported

If you comment out the High Vector check in !ADFFS.!Run it might work, although it won’t be able to track Page Zero accesses so some games will fail. Lemmings 2 springs to mind as one that requires emulated Page Zero access to work. For the most part, I’ve fixed the Page Zero access bugs in most games, as well as any bugs I’ve come access, so most games do not access Page Zero to work.

You’ll have to try it and let me know how you get on, as its never been tested on a Low Vector build. Myself and all the testers are all running very recent High Vector builds on Iyonix and newer machines.

The other requirement ADFFS has is a ROM build of 9th Jun 2016 or newer, so you would require a custom LV or supplier provided LV ROM build newer than that date.

My ARMX6 is up to date from the latest service pack with a 29-Jun-2016 low vector build. I get an error ‘Module ’TequeMemory’ is not 32 bit compatible’ when running Lemmings 1991. Using Aemulor I get ‘file ’Tequemem’ not found’ or ‘SWI &1AA03 not known’. Puzzled.

I get an error ‘Module ’TequeMemory’ is not 32 bit compatible’ when running Lemmings 1991

Are you running Lemmings directly, or selecting “Boot floppy” from the ADFFS Filer? I’ve just double checked the code, the JIT should in theory start up on a Low Vector build of 5.23, with the caveat that Page Zero accesses won’t be handled.

Nota: it would be great to have a low vector version, that would work for example with the famous October low vector build, used by many Pi3 owners. And me :)

Nota bis: anymode has a big problem with Pi3 (or October ROM, or big screen modes, or software cursor): system will hang if used. It can takes 5 minutes or 5 hours, but it will. So perhaps it could be cool too not to rely on it. Especially since it’s easy to define modes on a Pi.

I don’t think this bug is really specific to Pi3. I now using my Pi 10 hours a day or more… and so I see some bugs that a 2 hour use can’t detect.

it would be great to have a low vector version

ADFFS is developed closely in step with the OS, the OS went High Vector over a year ago and I don’t envisage ever supporting old or custom builds of the OS. Every public build of ADFFS is available on the project site, if someone wishes to use an old build of the OS, then there will be a matching build of ADFFS suitable for it. Likewise, if someone was to create a custom build of the OS, the source for ADFFS is publicly available and could be custom built for Low Vectors.

The only build that currently supports Low Vectors is the IOMD 26bit build but I no longer actively maintain or test it, as there’s too many issues associated with Low Vectors.

Why are Low Vectors such an issue? It has to do with what ADFFS is trying to do, its providing a Hypervised/Paravirtualized IOC Virtual Machine that appears to be running the RISC OS version a game expects, and one of the things games loved to do is write directly to Page Zero hardware vectors and/or IRQv. The main problem comes from how ADFFS works, unlike other software it does not emulate the memory map or CPU, games running under ADFFS are running natively on the CPU and reading/writing directly to memory with no supervision.

This all leads to the problem of how do you trap Page Zero reads without emulating all memory read instructions.

anymode has a big problem with Pi3 (or October ROM, or big screen modes, or software cursor): system will hang if used. It can takes 5 minutes or 5 hours, but it will. So perhaps it could be cool too not to rely on it. Especially since it’s easy to define modes on a Pi

I’m not aware of any issues with AnyMode. AnyMode only does things during a mode change, so I wouldn’t expect any issues once the mode change is complete.

The reliance is again due to the way ADFFS works. ADFFS doesn’t emulate VIDC fully, only the registers, which are translated to VIDC20 internally and then to a “VIDC type 3 list” and passed to GraphicsV at the beginning of the frame, should the geometry change. ADFFS relies on the OS to pass these onto the GPU unaltered and for the GPU to then upscale to the physical resolution.

I’ve purposely avoided coding a software upscaler, as the Pi does such a good job of it in hardware. The alternative is to copy the screen to a Sprite and let OS_Sprite then display on the GPU, although it could turn into a slideshow depending on the resolution.

ADFFS is developed closely in step with the OS, the OS went High Vector over a year ago and I don’t envisage ever supporting old or custom builds of the OS.

Nota: I do not speak of old ROM, but of new ROM compiled with low vector. It’s still used a lot, since high vector ROM is a problem with many old applications. In fact it’s not old ROM that I need to support, but old applications :) Of course, if we have a better low vector apps support (and less logs) under high vector ROM, why not.

I’m not aware of any issues with AnyMode. AnyMode only does things during a mode change, so I wouldn’t expect any issues once the mode change is complete.

Now you are :) If I load it and change of mode, just once (for example when switching to 2560×1400 at boot), I’m absolutely sure RISC OS will crash in the day. Without: no crash (crash that can’t be explained) since one month. It took my more than one month to find the culprit. Anymode. Why? No idea. I suspect this bug is present only when you use a very high res mode for desktop.

I did have also crashes with Netsurf, but it’s OK now. I suspect an upgrade to Tinct that I did not see. Or something closed.

Anyway, that’s just suggestions.

Anyway, that’s just suggestions.
I really need a crash proof system. Bref, a Pi2 with high vector ROM and no data.