Disk swapping issues

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

Disk swapping issues

Post by JonAbbott » Fri Jan 09, 2015 11:25 am

There are several reasons why it's difficult to swap discs in some games. The root cause itself is when a game sits in a tight loop waiting for input, be it a key or a disc change. Blowpipe, Chuck Rock and Xenon 2 all sit in loops of less than a dozen instructions; Blowpipe and Xenon 2 continually try to open a file and Chuck Rock continually checks for SPACE.

This has several side effects:

1. The Abort handler that corrects self modifying code is very likely to be entered tens of thousands of times a second if the code is writing into pages that contain code. IRQ's are off whilst the Abort handler is proxying the write
2. Any SWI's will turn off IRQ's, so the ratio of IRQ's being off to on rises. ie IRQ's are disabled more than they're enabled
3. The blitter is taking up most of the CPU cycles

(1) and (2) we can't do much about. Enabling IRQ's during the blit will however give a good chuck of CPU time back to allow IRQ's to be generated. To date, IRQ's have been off during the blit as its triggered by GraphicsV 1. I've found that enabling IRQ's whilst in GraphicsV 1 for any extended period of time seems to cause IRQ stack corruption, so they have to remain off whilst in GraphicsV code.

Investigating why the IRQ stack was being corrupt led me to the RTSupport module as being the culprit. Having then read the API documentation it seems like this module may be the perfect solution to the blitter IRQ problem.

Essentially what RTSupport brings to the table is pre-emptive multitasking, which it provides by hanging off the IRQ vector. This has some obvious issues in that code is called at random, however...for our purposes, it's an ideal location to put the blitter when we're generating our own 50Hz VSync, as the trigger for the 50Hz comes from TickerV which is IRQ driven. Rather conveniently RTSupport also allows code to be called at centisecond intervals.

For the next release of ADFFS, I've modified the GraphicsV 1 / Frame Pacing code and moved the blitter to a thread under RTSupport. This seems to have resolved the issue of swapping discs, however it now instantly locks the machine when a disc swap happens. I'm currently investigating why and hope it's resolvable, I also need to confirm that the IRQ stack corruption issue is resolved by moving the blitter out of GraphicsV.

JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: Disk swapping issues

Post by JonAbbott » Tue Jan 13, 2015 9:49 am

JonAbbott wrote:This seems to have resolved the issue of swapping discs, however it now instantly locks the machine when a disc swap happens. I'm currently investigating why and hope it's resolvable
I've managed to track down the issue and find a solution. RTSupport is again the root cause of the issue, it looks like it's leaving something on the IRQ stack which subsequently causes FileCore's IRQsema check to fail and the machine to then lock. The locking could be my code, I've not investigate, but it should exit cleanly and simply not swap discs if FileCore returns an error...investigation required.

I first attempted to work around this problem by checking IRQsema before the start of the disc swap sequence, this didn't resolve the issue though. On further investigation, even though IRQsema was clear at the start of the disc swap, at some point RTSupport is altering IRQsema and causing FileCore to again fail.

My next attempted fix was to simply shut down the blitter, based on the assumption that as it takes a fair bit of CPU time to blit a screen, there's a fair chance it will be interrupted by another IRQ and sit on the IRQsema chain until RTSupport resumes it. Again this didn't resolve the problem.

Taking a wild stab in the dark, I wondered if there was a chance that I could be attempting unregistering the blitter whilst it was still active. In this situation RTSupport may hand back to my code before the thread is actually unregistered and is still sitting in the IRQsema chain (although the documentation states it doesn't return in this scenario). To confirm this, I added a loop after the XRT_Deregister which waits until IRQsema is cleared down. Bingo, problem resolved.

All this RTSupport behaviour could be by design, but I'll try to produce a repro just in case it is an issue that the RISCOS dev's need to look into. If it's by design, it just needs the RTSupport documentation updating so other users don't fall foul of the problems I've experienced.


All these changes to the blitter/GraphicsV code have however broken the GPU frameswap. Zarch (use OS_Byte 113 only) looks okay, but Pac-mania (uses OS_Byte 113 / OS_Byte 19 combo) doesn't - it's tearing. Whilst debugging is turned on, I'm also seeing it update the debug text which is actually happening on the backbuffer. This behaviour implies there's a 1 frame delay between the GPU frameswap and it actually happening, which I've confirmed by making the GPU frameswap code swap to the wrong buffer.

Whilst testing, I also noticed Zarch was randomly hanging, which is possibly sound related. This could be RTSupport causing issues again, but hard to tell at this stage due to the large amount of changes I've made in 2.47. I'll come back to this once I've resolved the GPU frameswap issue.

Brilad
Posts: 1
Joined: Sun Jun 28, 2015 8:48 pm

Re: Disk swapping issues

Post by Brilad » Sun Jun 28, 2015 9:18 pm

Hi Jon,

As you can see I have just registered, and firstly I would like to say thanks for what you have done with this project. :)
I left sixth form in 1990, so never really got to use the Archimedes first time around and I did not do any further education involving computers, but what has led me here is a love of gaming in general and a lot of nostalgia for Acorn in particular. I also like to mess with emulators, so this project is great. I'm really curious about the Archimedes as a gaming machine. I also want to make use of any educational and PD stuff I can find. I have managed to get some stuff going in this respect with !ArcEm.

I am on a Pi, OS 5.21

Successes today have been James Pond and Zool, but I have had disk swapping problems...any multi disk game goes to the egg timer indefinitely. I have sparkFS loaded and the clenched fist (great icon!) in the icon bar. I feel I must be doing something basic, such as putting disk2, disk3 etc in the wrong place (?) is there a directory that adffs is looking for?

I have had a couple of other teething probs...Lotus 2 (which runs beautifully) seems to ignore my keyboard most of the time although I did get it to work once!

Finally: if anyone has any adfs of PD or especially educational titles would it be possible for you to host these? I appreciate that the focus is on commercial titles and you have a backlog as it is, so it's more something for the future. Sorry for newbie questions on my first post...if there is a read me file etc please direct me!!


Cheers, Brian

JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: Disk swapping issues

Post by JonAbbott » Mon Jun 29, 2015 7:09 am

Brilad wrote:I have had disk swapping problems...any multi disk game goes to the egg timer indefinitely.
This means it can't find the disc you've selected, check that the disc ID is the last characters in the filename, ie you've removed any post fix that's been appended by coping from a PC.
Brilad wrote:I have had a couple of other teething probs...Lotus 2 (which runs beautifully) seems to ignore my keyboard most of the time although I did get it to work once!
If you have your mouse and keyboard plugged directly into the Pi, this can and does happen due to power droops. Try powering them through a powered USB hub.
Brilad wrote:if there is a read me file etc please direct me!!
There's a help file bundled with ADFFS, middle click !ADFFS within the filer and select Help.

Post Reply