26bit Module support

Discuss development specific to the Pi version of ADFFS
Post Reply
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: 26bit Module support

Post by JonAbbott »

Vanfanel wrote:CTRL-ALT-PgUp doesn't make anything really. But if I do press 3 on the numeric keypad, there's a game message that says "Enhanced framerate selected. Only suitable for ARM3 processors." And then, even if the game has booted in "slow mode" (around 6 FPS), it gets to 25FPS.
If it has booted in "normal mode" (around 12FPS) it does 25FPS too.
Sorry, my mistake, it's CTRL-SHIFT-PgUp/PgDn to change the FPS :roll:

Anyhow, you've confirmed its doing a Hz check and getting the wrong result. Hopefully adding ADFForceVSync 4 to the top of the boot script should fix it, if not, I'll have to hunt for the code and patch it at runtime.

The root cause is that the frame pacing doesn't kick in until 1 second after a MODE change, as it has to work out the Hz - I really must look to see if there's a way in RISCOS to calculate the Hz, instead of counting VSync's.
Vanfanel
Posts: 576
Joined: Mon Sep 16, 2013 12:01 am

Re: 26bit Module support

Post by Vanfanel »

Adding ADDForceVSync 4 to the boot script makes the game boot in 12FPS mode always, so it's good. No more 6 FPS mode with that. Should that be considered a definitive solution?

Regarding HZ calculation by counting VSYNCs after every MODE change: on the Pi at least, it seems HZ don't change. Video modes are all "scaled" to the mode specified in config.txt, so if it's a 50.000HZ mode, it will be 50.000HZ no matter what video mode you chose once RISC OS has booted. So I don't think VSYNC calculation needs to be done every time MODE is changed, at least on the Pi. Maybe you could do it once, before game starts, and that's all.

Also, I had noticed how HZ adjustment is done in the first second once the game is running. Would you be able to calculate HZ (it that's needed at all on the PI) before the game starts displaying graphics? That would save the first "broken" second. Not important of course, but it would be nice.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: 26bit Module support

Post by JonAbbott »

JonAbbott wrote:
Vanfanel wrote:-Inferno hangs here after I press 1 to start game.
I've been looking into this today, it looks like recursive Aborts are occurring but I'm not sure why. This is breaking a few other games as well.
Although I fixed the recursive Abort issue in the last dev build, Inferno and a few others are still crashing.

The crash is being caused by IRQ's occurring during sound buffer fills. On return to the fill code from the 2nd interrupt the IRQ stack is collapsed - this is the behaviour of RTSupport and the reason I originally had to code my own IRQ handler to effectively manage RTSupport, so it didn't collapse the stack. I'm unsure why it's suddenly become a problem, unless the issue has always been there and its only now become apparent in newer working games.

There's a couple of possible solutions:
  1. Turn off IRQ before calling fill code
  2. Switch to SVC before calling fill code
  3. Prevent RTSupport from collapsing the IRQ stack
My concern is that this could also occur in any other IRQ code (which could potentially be any Vector claim) if IRQ's a re-enabled and it relies on the stack. I worked around the issue internally within ADFFS by using a private IRQ stack, RTSupport can then reset the stack all it likes and it won't affect ADFFS; externally however I have no control over the stack once IRQ's are enabled.

I'll have to study RTSupport again and double check under what conditions (if any) it collapses the stack.

EDIT: It can't be RTSupport as it's occuring on RO5.22 IOMD - which doesn't have RTSupport included :roll:. Something else must be collapsing the stack.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: 26bit Module support

Post by JonAbbott »

Updated Modules and obey.zip on the dev site, which gets The Last Ninja working. Hopefully that's the last bug in the 26bit Module support ironed out.

Oh, No! More Lemmings also works, but I need to add the same patch we applied to Lemming to fix the cursor wrap - not really a show stopped though.
Vanfanel
Posts: 576
Joined: Mon Sep 16, 2013 12:01 am

Re: 26bit Module support

Post by Vanfanel »

Tried The Last Ninja with the latest Modules and Obey and it works great on the Pi!
As for Oh no! More Lemmings, it was working before, but I confirm it needs the no-cursor-wrap patch.
Howeverm there are lots of games not working in these "experimental" versions as you know.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: 26bit Module support

Post by JonAbbott »

Vanfanel wrote:However there are lots of games not working in these "experimental" versions as you know.
I spent a few days looking at it and although I'm no closer to finding the root cause, it is definitely IRQ related. None of the IRQ code has changed since 2.50, with the exception of moving the private IRQ stack to a private Dynamic Area. A few things I spotted whilst debugging:
  1. A specific instruction in the JIT exit code is being overwritten with the Hypervisor instruction. This is causing some of the crashes
  2. irq_R13 which normally points to the private IRQ stack is sometimes being changed back to the actual IRQ stack. This is causing the remainder of the crashes
Both are random though and occur without fail on the Pi and seldom on RO5 SA under emulation. Inferno for example is now working on RO5 SA, but hangs on the Pi.

Its frustrating trying to track it down, so I've switched to testing games for the time being in the hope I'll have a brainwave as to the cause, or how to track down the root cause.

Speaking of brainwaves, whilst testing Drifter yesterday one of the issues causing it to break was a reliance on the CPU pipeline that I couldn't fix at runtime. After a few hours pondering a solution, I realized that with a few additional instructions in the Abort handler I could partially add CPU stage 2 pipeline support - certainly enough to get Drifter to work:

Updated Modules and obey.zip on the dev site, which get Drifter running. It's hanging when you quit the level, which only occurs on RO5, so there's possibly another SWI that behaves differently under RO5.

Incidentally, the fix for The Last Ninja was a bug that relied on a quirk of RO3.71 (and below) OS_SpriteOp 36 (set Pointer) to work. I'd already applied a fix for this to get a few other games working, but it appears there are two issues in OS_SpriteOp 36. The implementation was changed in RO5 to match the PRM exactly and it's this that's broken quite a few games.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: 26bit Module support

Post by JonAbbott »

Latest Modules and obey.zip on the dev site get Drifter, Holed Out!!, Hero Quest and Repton 3 running.

I believe Grievous Bodily ARM is also working, although the screen width is wrong. It's also wrong on a RISC PC, so I suspect there may be an issue with the VIDC1->VIDC20 translation. I'd expect it to work on the Pi and all Modes start off with the original RO3.11 TV VIDC1 parameters, at a guess the blitter is calculating the screen width incorrectly as the game's ModeExtension module only writes HDSR and HDER - they may be overlapping HBSR and HBER.

Some big changes in this build, BASIC SYS command is now hypervised, 26bit Modules can now be removed and managed Vectors no longer use a codelet but are instead handled within ADFFS via a jump table. As a consequence these changes may have a knock on effect on previously working games, I'm aware Carnage Inc. has regressed but haven't tested any games besides Pandora's Box and The Dungeon.
Vanfanel
Posts: 576
Joined: Mon Sep 16, 2013 12:01 am

Re: 26bit Module support

Post by Vanfanel »

These are the resuls on th Raspberry Pi:

-Hero Quest hangs on the language selection screen.
-Drifter hangs after the rotating engine logo.
-Repton 3 seems to work fine.
-Holed Out! seems to work fine: not sure because I only see some menus I can't figure out.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: 26bit Module support

Post by JonAbbott »

Updated Modules and obey.zip on dev site, which get James Pond II Robocod, Flashback and Talisman working.

There's an issue with the walking sound in Talisman yet to resolve and the scrolling isn't as smooth as it should be in James Pond II, both work otherwise.
Vanfanel
Posts: 576
Joined: Mon Sep 16, 2013 12:01 am

Re: 26bit Module support

Post by Vanfanel »

Results on the Pi are:
-James Pond 2: repeating frames, so scroll is broken. I'd say it will drive me nuts if I play it for a while! :D
ALSO: the music is veeeeeery wrong here. Listen how the game should sound in the ARchimedes version:
https://www.youtube.com/watch?v=hNM_Vc5t7F8
When I tested it in ADFFS I thought they had f**ed up the music as they did with Lemmings, but it has the fantastic music of the Amiga version! However it sounds terribly wrong with ADDFS, notes are changed in a very strange way.

-Flashback: "UNKNOWN OPERAND" when booting the floppy image. Maybe there's something wrong with the obey?
-Talisman: working!

I have also noted that GODs has also music problems. I thought the version was also bad done, but here's how it should sound:
https://www.youtube.com/watch?v=2tyKbOvMFmk
Almost like the Amiga version as you see!
In ADFFS it sounds like this, as you know:
https://www.youtube.com/watch?v=-pyFsad2v5k
Post Reply