Gribbly's Day Out on the Arc

[Idge]

I am trying to get Gribbly's Day Out on the Arc to run on my physical A3010 using ADFFS but am not having any luck.
It seems to load the intro ok. Once you start the game, it loads up the background and shows Game On in text, but you then cannot do anything and I have to physically power off the machine. It also hangs when it loads the demo, you get the same background image and it says Demo Mode, but I think you should see Gribbly appear after that, but it just hangs.
I see this was an issue in ADFFS 2.80 originally and it was fixed in 2.80RC2 but I have tried the latest version as well as the beta and both have the same issue.
Is this a known issue or is there something I have to do to get this to work properly?

I am using a JFD of the game and am using Boot Floppy

If I set my screen type to normal and mode 12 and run the game by double clicking the icon instead of boot floppy, the game runs, so seems to be something to do with the boot script for it in ADFFS.

It does the same in arculator, so not related to it being run on a physical machine.

Thanks

[JonAbbott]

it loads up the background and shows Game On in text, but you then cannot do anything

I'm seeing the same issue so will investigate.

[JonAbbott]

It's an interesting issue. It's getting stuck in IRQ's, as despite single stepping for several hours yesterday the CPU didn't hit any code that wasn't an IRQ handler, be it VSync, Sound or Timer 1.

Oddly the issue occurs when run directly or under the ARM3 JIT on a StrongARM but doesn't occur under the ARM3 JIT on ARMv5.

I looked at what the script does different to running the game directly and it's very minor. The only real difference is the script is doing it in stages, so it can patch the code at each step. My initial thought was possibly the stack location but moving that doesn't change things.

As it doesn't occur on ARMv5, it may be an instruction ADFFS is correcting in the JIT, something corrected by the Hypervisor, something X Lock 2 is doing with the CPU mode or IOC mask related, so there's a few more things to check.

Whilst looking at this, I've taken the opportunity to patch the code so the game can be HD installed and also switched its IRQ handler to something more legal than assuming the hardware vectors are branch instructions. That will need testing later to see if the highscore table is retained.

[Idge]

Appreciate you looking into this Jon. I hadn’t got around to testing it on the Pi, but sounds like that works ok.
Happy to test anything you need me to.

Cheers

[JonAbbott]

I've tracked the issue to the game's IRQ handler and have also reproduced the issue with the original game, unmodified, so it's not due to anything the script is doing.

I suspect it's timing related and probably luck that it doesn't occur all the time. Disable the IRQ vector claim and remove all waits that hang off its VSync detection and the game works correctly, all be it without Copperbars.

As I do not see user code entered when step debugging, my first thought is the game is either not clearing down IRQ correctly or its setting the Timer 1 registers incorrectly, causing IRQs to occur so quickly it can never recover.

The next step is to check all the T1 altering code is wrapped with IRQ disable/enable and is setting the registers correctly; and to confirm it does set the T1 registers prior to enabling it's IRQ.

[JonAbbott]

it loads up the background and shows Game On in text, but you then cannot do anything and I have to physically power off the machine. It also hangs when it loads the demo

Updated obey.zip available that fixes this, it also details how to HD install the game.

The next build of ADFFS will also include some code changes to resolve the underlying issue, although they're not required provided the latest obey.zip is used.

[Idge]

Great Thank you Jon. I will give this a test tonight

[Idge]

Thanks Jon, this now works. The only thing I have noticed is when playing the game through ADFFS the pitch of the music is different compared to playing it directly from double clicking the game. Not a big issue, just thought I would mention. Its possible that ADFFS is probably the correct pitch but I have no idea what is correct.

[JonAbbott]

when playing the game through ADFFS the pitch of the music is different compared to playing it directly from double clicking the game

ADFFS corrects pitch and music speed in quite a few games, this being one of them.

It also corrects the game speed to match original hardware, although it was that, that was causing the lock you were seeing. I've disabled it for the time being until I can figure out a solution, which I'll probably do within ADFFS instead of patching the game.

The knock-on effect will be the game will play too quickly on a RiscPC or an overclocked ARM3. It's not an issue post RiscPC as IRQs are virtualised by ADFFS, so the OS call that was locking the machine isn't affected when the game disables IRQ and masks off Timer 0 on IOC.