forums.jaspp.org.uk

JonAbbott wrote:There's also a further odd failure on the Pi, the loader screen locks the machine - again I can't see anything obviously wrong in the code that could cause the behaviour.

This looks like a bug in the Lemmings 2 code, if the machine isn't already in a MODE that Lemmings 2 expects, the code locks. Changing to MODE 27 prior to running the title screen fixes it.

Another game I'd love to have working on the Pi is "Simon The Sorcerer". Is it far from working?
I know it's not into the JASPP project, but still it's an awesome game and maybe the best native graphic adventure ever to grace the Archimedes.

Vanfanel wrote:Another game I'd love to have working on the Pi is "Simon The Sorcerer". Is it far from working?

I don't believe I've looked at it yet, but will add it to the list.

To support Simon the Sorcerer properly requires full Wimp support and ADFFS to provide a virtual CD, the former isn't possible and the later is way down on the list.

Bypassing the Wimp frontend and supporting the floppy only version might be possible. I created the Boot Script for it and fired it up, but sadly it resulted in a blank screen. The Wimp frontend Module looks like it may also provide a bespoke MODE, so may need modifying at runtime so it loads, but doesn't start the Wimp task.

If floppy version is supported, it's VERY possible that the CD version can be manually installed and lauched under ADFFS. The CD version doesn't have any protection that I know about.
But having the floppy version working would be incredible anyway

I have the CD version (somewhere!). It had no protection. I copied the entire game to a spare hard disk so a friend of mine could play it. There was no requirement to run via CDFS or such. I think CD burners and large disks were expensive back then!

I have Wolfenstein 3D working under RO5 in build 2.52h, but for some reason it just shows a blank screen on the Pi. It was working earlier today, so I suspect one of the extensions I've added to get it running are at fault. Having said that, I've tried rolling all the changes back and it's still doing the same thing, which has me somewhat bemused.

I also had to reimage disc 1 as the protection has been broken since 2.13, when the floppy head code was changed to advance based on time.

This is the third game from the requested list that works okay under RO5 SA, but fails under RO5 ARM11 (Alone in the Dark, Lemmings 2 being the other two)

Spent a few hours yesterday trying to find out why Alone in the Dark is failing to load on the Pi. It works on IOMD RO5, which has me very confused.

I've established the "ListSamp" function is failing, but haven't yet determined why. I've ruled out VoxLib as the cause, although have fixed a bug in it that was causing an Abort on RO5.23. I suspect the underlying problem is filesystem related, with CLib and SWI flag preservation possibly coming into play.

Lemmings 2 suffers a similar fate, working on IOMD RO5 but not the Pi. I suspect that's IRQ related as it hangs around the time it starts the palette bashing code.

Wolfenstein 3D is running under the debug build, but is unplayable due to the keyboard being very intermittent. I noticed BlowPipe is suffering the same issue, so this is hopefully a bug in my code. I've been through all the Wolfenstein code and can't see anywhere, where IRQ's are off for any period of time. One thing I have noticed however, is that when both games are slowed down via CTRL-SHIFT-PgUp, the sound stutters, which makes no sense as IRQ's are enabled whilst ADFFS stalls the game; neither are affected in this way on StrongARM.

Could it be that your slowing down loop prevents some background task related to the sound generation to be performed?
IIRC callbacks and the like are called on exit of the SWI handler (with an empty SVC stack?), so long loops without SWI calls could be the source of the stutering.
An example of this is I think AMPlayer which stops playing when I press F12 to go to the command line.

Could it be that your slowing down loop prevents some background task related to the sound generation to be performed?

No, I'd see it occur on StrongArm if that were the case. The delay loop repeatedly calls OS_ReadMonotonic with IRQ's enabled and sound in both games is coming via Voice Generators which probably sit under RTSupport on the Pi. It shouts "IRQ's are disabled" to me.

Finding what's regressed BlowPipe might point to the root cause.