IOC emulation

Discuss development specific to the Pi version of ADFFS
steve3000
Posts: 198
Joined: Thu May 02, 2013 9:25 pm

Re: IOC emulation

Post by steve3000 »

JonAbbott wrote:So...there's now no RPC emulators I can use to develop this as they all have fatal bugs. Aarrghhh!
ahh yes... the joys of coding to the limit of emulation and beyond :)
JonAbbott wrote:This doesn't of course explain the very similar random crash on the Pi, using Jahangir Khan as an example; if I change the interrupt code so it doesn't write to VIDC, it still crashes in the same way - so the issue on the Pi isn't related to VIDC writes and is more likely related to HAL timers.
That is more worrying. Have you been able to test on other RISC OS 5 hardware?
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: IOC emulation

Post by JonAbbott »

steve3000 wrote:Have you been able to test on other RISC OS 5 hardware?
Not yet, I've been trying to get the Iyonix fixed since Dec so 1. Can get ADFFS500 working on it and 2. Have something other than the Pi to cross check against.

Getting ADFFS500 to work will be fun, in theory it should already work as it's using standard SWI's and OS features, but it's the minor differences in RISCOS across platforms that usually break it. Which reminds me, I need to test ADFFS400 on RISCOS5 IOMD and see what's broken.

I changed the code yesterday (extASM500236f), so instead of the T1 code clearing the IRQ as soon as it's raised, it leaves it until the user code clears it via a write to IRQA clear. That's changed the random crash to a predictable hang that always happens at the same time, so it's definitely the HAL timer call causing the problem and is possibly timing related.

I'm going to try stopping the Timer when the IRQ fires to see what difference that makes and only restart it when IRQA clear is written too. It will make the Timer somewhat random, but worth trying to see if it changes the hang although from Jeffrey's description it sounds like the hang may be caused by another (non-Timer) IRQ firing before the Device IRQ is cleared. The are however two IRQ's to clear, the Device IRQ (which I hope is causing the hang) and the Timer IRQ which I don't really understand and hope simply prevents the Timer from raising an IRQ again.
JonAbbott
Posts: 2938
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex
Contact:

Re: IOC emulation

Post by JonAbbott »

Emulation of the IRQ processor vector, IRQ1V vector, IOC T1 and IOC VSync pulse is now complete however there's still some general debugging of ADFFS to do:

1. StrongARM is completely broken, all games lock up solid. The games are working under emulation, so must cache related
2. James Pond now loads but crashes at various points on the Pi

I found out why Red Squirrel crashed for so many games, it seems related to its implementation of MSR CPSR_c, ... Which seems to behave slightly differently than a StrongARM processor when going from SVC26 to USER. By changing the way it does it slightly, I've managed to get Chuck Rock and others to no longer crash when they're waiting for disc changes.

Another possible issue I've found, is how MSR CPSR_all, Rx behaves when in USER on the Pi. All hypervised IRQ related code is executed in USER32, so it saves the state before calling the IRQ and restores it on return. MSR CPSR_all, Rx was causing crashes, changing it to MSR CPSR_f, Rx resolves the problem although there shouldn't be any difference as USER isn't privileged so can't change anything other than flags.
Post Reply