Conqueror on Pi using ADFFS

[jms2]

I have been gradually building up a stock of working games on my Pi, with generally a lot of success and the kids surprisingly keen on Risc OS! But one problem which I am really struggling with is Conqueror, which ADFFS says ought to run OK.

I have got an image which runs fine on a real machine under ADFFS. But although it runs on the Pi, it hangs, making a buzzing noise. Subsequently, ADFFS won't run, I just get a black screen when loading the application. This is ADFFS 2.72. Deleting the application and copying it back doesn't fix the problem, so it must have corrupted something that ADFFs relies on.

Anyone else seen this?

[sirbod]

What model of Pi? And more importantly is the floppy image of Conqueror from the original, the Superior collection or a hacked copy? If it's modified in any why, ADFFS might not be able to patch it in the boot script.

Pretty sure Conqueror was working the last time I checked it on a Pi3, but I'll recheck it when I get a chance.

[jms2]

Its a Pi2+ Jon. The Conqueror image is definitely a hacked one I think, so that could be it. I didn't appreciate that the images had to conform closely to the originals.

I think I might have figured out the black screen problem with ADFFS - I don't seem to have the disable_mode_changes flag set.

EDIT: Actually that's not right - I did have it set. To be clearer on the nature of the issue:

- Pi boots OK
- Double clicking on !ADFFS causes the screen to instantly go black and the machine makes a VDU7 beep. After that it is totally unresponsive, even ctrl-Break doesn't work!
- This is a new problem. I have only seen it since installing version 2.72, which I tried out to see if it would address my problem with Conqueror. It seemed to run fine until I loaded Conqueror, which provoked the usual crash that I described above. After that, my system doesn't seem to be able to run ADFFS any more.

[jms2]

I think I have spotted the issue - having read the release notes carefully, I see that version 2.72 requires the use of Risc OS 5.27. I'm still on 5.23. That'll probably be it then!

[jms2]

Aargh! I started the process of upgrading to Risc OS 5.27. One of the earliest steps is to check the content of the cmdline.txt file, which I decided to do by putting the SD card into my PC. I could open, edit and save the file, but after I saved it back the computer now says that the SD card doesn't have a valid format. The Pi doesn't recognise the card either, and doesn't boot.

I have all sorts of problems using those micro SD to full size SD adaptors, I wonder if a glitch has somehow corrupted the card.

[sirbod]

One of the earliest steps is to check the content of the cmdline.txt file, which I decided to do by putting the SD card into my PC. I could open, edit and save the file, but after I saved it back the computer now says that the SD card doesn't have a valid format. The Pi doesn't recognise the card either, and doesn't boot.

That's usually fixable by running a disk check on the PC, it's happened to me dozens of times.

As you spotted ADFFS 2.72 requires RISCOS 5.27, this is because fundamental changes were made to the way RISCOS handles mode changes, which required a complete rewrite of the legacy mode emulation to match.

From memory Conqueror is a game that has a bug in its code in the form of an invalid instruction, this gets NOP'd on ARM3 generating silent corruption. On a Pi3 is halts the CPU, so will be patched in the boot script.

[jms2]

That’s a relief... was going to be my next move, but I’m not feeling very lucky today so I’ll wait until the weekend before messing with anything!

[jms2]

I have tentatively started to try to fix this, using a proper micro-SD reader instead of one of those dodgy SD-to-micro-SD adaptor sleeve things.

Unfortunatel CHKDSK says it can't fix the issue because the partition is RAW, and trying to set the partition as active in Windows Disk Management also doesn't work.

Is it as simple as reformatting the FAT32 partition and dropping Risc OS on there? Or would the formatting process wipe the whole card? Obviously I want to preserve the SDFS partition (which seems to be OK).

Edit: I decided to take the plunge and format it. Seems to have worked ok. I'm not going to test the Pi until tomorrow though.

[sirbod]

From memory Conqueror is a game that has a bug in its code in the form of an invalid instruction, this gets NOP'd on ARM3 generating silent corruption. On a Pi3 is halts the CPU, so will be patched in the boot script.

Having checked today, it was Zarch that had this issue, not Conqueror. There's no fixes for the original Conqueror release in its boot script, so provided the version you have doesn't introduce bugs it should work okay, provided you use the correct script (!ADFFS.obey.F1009001) which will need modifying to match your copy. ie I suspect you need to remove references to the floppy and probably replace the !Run if its sitting under an application icon.

There were three other releases of Conqueror: Play It Again Sam1, Games Hyperpack and Games Minipack Two. It's possible the version you have is ripped from PIAS1, which I've yet to looked at.

[jms2]

I'm very pleased to be able to report 100% success on all fronts!

After formatting the FAT32 partition I was able to put Risc OS 5.27 on there, and now ADFFS works as it should.

Also, I used the technique you described to modify the !Run file of Conqueror, and now it works perfectly! The only thing missing is a sensible icon, but I might just go and design one of my own... I note actually that at least one video of Conqueror on Youtube has the same icon as mine, which is just a "C" against a grainy background. This must be some kind of hacked version.

[sirbod]

I've used the attached sprite for the packaged version of the game.

!Sprites.png (834 Bytes) Viewed 7580 times

[jms2]

Nice... thanks!

My son's playing it now actually, its a game I have fond memories of because whilst it's not a lot of fun initially it definitely grows on you. It's actually a lot better than Zarch.

Every version I've ever seen has a bug on the map screen where the status of each tank is reported. Instead of "Panzer III Tank OK" it says "Panzer III ank OK" for some reason. Presumably the officially released version doesn't do that... or does it?

[sirbod]

Every version I've ever seen has a bug on the map screen where the status of each tank is reported. Instead of "Panzer III Tank OK" it says "Panzer III ank OK" for some reason. Presumably the officially released version doesn't do that... or does it?

I wasn't aware of that bug, I'll work out a fix and add it to the boot script.

[jms2]

Maybe the official version doesn't do it?

It's nothing to do with ADFFS or the Pi though, it does it on my real machines.

Just noticed that if the tank's name spreads onto two lines, the blanks appear on lines 1 and 2 instead of just line 2. So you can have " ing iger Tank OK"

[sirbod]

Maybe the official version doesn't do it?

It's a bug in the game code.

I'm not entirely sure what the code is supposed to be doing (it's at A1D0), but its calling OS_WriteI+11 to go up a line if the text is blank. Somehow its printing a space before it goes down a line when there is text to print.

A quick fix is to simply NOP the OS_WriteI+11 by adding the following line before Conqueror is called in the Obey file:

Code: Select all

JITMEMORYA A1DC 0F00010B E1A00000

[jms2]

Cool, I'll give that a try!

[jms2]

Cool, that works!! I can't believe that Superior released the game with that bug in it...

Just for my personal interest, I *Loaded Conqueror to have a look at the code using *MEMORYI A1D0, but I couldn't find the SWI at A1D0 or anywhere nearby. It doesn't really matter as the problem is fixed anyway, but it would help my limited understanding of how the Arc works if I knew why my disassembling isn't throwing up the relevant code. Actually the disassembly doesn't really look like valid code.

One further bonus is that I now understand the use of *GOARM3JIT 0.... so I have managed to get Bloxed (two player Tetris) working as well! ADFFS is superb, thanks for writing it!

[sirbod]

Just for my personal interest, I *Loaded Conqueror to have a look at the code using *MEMORYI A1D0, but I couldn't find the SWI at A1D0 or anywhere nearby. It doesn't really matter as the problem is fixed anyway, but it would help my limited understanding of how the Arc works if I knew why my disassembling isn't throwing up the relevant code. Actually the disassembly doesn't really look like valid code.

I expect you'll need to decrypt/expand the code first.

One further bonus is that I now understand the use of *GOARM3JIT 0.... so I have managed to get Bloxed (two player Tetris) working as well! ADFFS is superb, thanks for writing it!

Glad you find it useful, *HELP <command> explains what the commands do as does the application help.

[jms2]

I have now turned my attention to Zarch, and discovered some more ADFFS features that I had not seen before, specifically the ability to identify whether an image is an ADF, APD or JFD, and the ability to convert APDs to JFD.

The Zarch image that I have is an APD which works on a real machine (at least, I can play Zarch on my Arc and I think its the same image). It's an Arthur style disc with no !Zarch application, only a machine code !Boot file and two 2.5k executables - clearly some hidden files must exist. I converted this to a JFD but it still doesn't quite work... I get a mode 15 screen with a cursor but nothing else. One question I have is all the tick boxes in the converter window - what do these actually do? I tried ticking the boxes relevant to the Pi but it didn't make any difference.

[sirbod]

The Zarch image that I have is an APD which works on a real machine (at least, I can play Zarch on my Arc and I think its the same image)

From memory, there was something odd with the APD of Zarch, its a sequential image that only worked if track 40 was redirected to track 80. I added a hack in ADFFS 1.22 that checked for the Zarch APD and botched it to work; this was subsequently removed in ADFFS 2.38.

As the hack isn't in ADFFS now, it will fail the disk protection. It's possibly a bug in ADFFS, but I've never managed to recreate with any other sequential discs, so put it down to a quirk with the APD.

[jms2]

OK thanks Jon, that's fair enough... I'll check my real discs and see if I have an unprotected version of Zarch which I can get working.

I'm still curious about the JFD convertor check boxes though - are these just an indication of what the game was originally compatible with, ie checking them doesn't actually change anything?

[sirbod]

OK thanks Jon, that's fair enough... I'll check my real discs and see if I have an unprotected version of Zarch which I can get working.

Zarch has a fatal bug in it, which is corrected in the boot script. It's unlikely the code will be different, but be aware you need to either use the ADFFS boot script, or take the bug fix across to the !Run.

I'm still curious about the JFD convertor check boxes though - are these just an indication of what the game was originally compatible with, ie checking them doesn't actually change anything?

The title, OS and CPU version are informational only, everything else is used by ADFFS when the floppy is booted.

[jms2]

It turns out that I do have an unprotected version of Zarch, in the form of a Risc OS 2 style "!Zarch" application, so I will give that a go using the ADFFS boot script. The challenge is getting it off the A3000 floppy...

[jms2]

It almost works... but not quite. I tried patching the !Run file in both a copy of the application running straight from SDFS, and also the same application running from an ADF image (leaving in the *ADFS command that time). I got pretty much identical results from both.

I get to the intro screen which says "You are about to enter Zarch demo mode, otherwise press any key", but at this point there is a very short beep and the mouse pointer appears. I think an invisible error message also appears, because if I press escape it returns to the desktop.

The Zarch executable is about 97k long and has an execution address of &DBA8. I was able to check out the memory locations referenced by the two bugfixes in the !Run file, and found exactly the expected code at both two locations - so the patches were clearly going to work (or at least, I assume they would anyway). So it's a bit of a mystery why the game is exiting in this way.

[sirbod]

Is it loading Zarch at 8000? It doesn't sound like the patches are being applied.

[jms2]

Well, I assumed it was!

The "Info" box in the filer says that the main Zarch executable loads at &8000 and executes at &DBA8. The !Run file just does "*Run Zarch", with GOARM3JIT 0 beforehand plus also the patches, the addresses for which I don't recall right now but one was at an &Axxx address and the other at &Dxxx. One of the patches moves a stack to above &10000 but I can't see anything which shifts the loading address, unless GOARM3JIT implicitly does this. If that's what it is supposed to do, then it probably is doing it!

When I manually *Loaded the file at &8000 and checked the patch locations with *MemoryI, I found the expected target code at those locations (ie, the instructions which need to be patched over).

So that all stacked up for me - why wouldn't it (or shouldn't it) load at &8000?

[sirbod]

You'll have to do some debugging to find out why it's crashing:

1. From the desktop press F12, then type:
2. GOS
3. DIR <Zarch directory>
4. !Run
5. When it crashes, press ENTER
6. FX 113,1 or FX 113,2 to switch to the screen with the error
7. Once you've noted the error, see if the JIT dump indicates any issues:
8. JITSHOWREG
9. Finally, use SHOWREG and note where PC is and what the register values are. This will be blank if it didn't actually crash

It's possible an OS error is occurring, which is causing it to drop back to the command prompt. Percussion, StringLib or WaveSynth are missing perhaps? Not enough video memory?

[jms2]

Hi Jon

That method of finding the error worked perfectly! I'll be using those tips again!

So the reported error is "Abort on Data Transfer at &010FCABC", and JITSHOWREGS reveals that the PC was at &FC046FE0 (so nowhere near &8000).

The instruction there is LDR R3,[R1,#0].

I'm a bit lost at this point, because I can't see any reference to an address even vaguely similar to the one in the error message. However, SHOWREGS demonstrates that the ARM registers are completely different to the JIT registers (I didn't appreciate this aspect) and I see that R15 is set to &010FCA94, which could be relevant maybe?

I have attached a screen dump showing all this.

Thanks for all this help by the way - I'm finding it educational!

[sirbod]

The JIT dump isn't much use as the RISC OS Abort handler has generated aborts whilst it paged in memory.

The Abort at &010FCABC is within a codelet, if you do a MEMORYI at that address and work back you'll get to the codelet header (probably around 10FCA40), which has the address+8 of the original instruction. Once you have that, you can see what triggered the Abort. My guess would be an LDM. From there you're on your own, as you'd need to figure why it aborted and resolve the issue.

[jms2]

The first thing to say is that because of the blocky font used in Zarch I misread the location of the data abort. It's at &10FCA8C (the 8 looked like a B).

At the beginning of the codelet I can see that it enters with an address stored in R1, which it promptly saves it in a spare address just before the codelet block. At the end of the codelet it does LDR PC with the contents of that address, so I'm confident that the R1 value must be an address. The address is &A3FC, so that presumably means that the codelet was entered from &A3F8.

That location is within the Zarch code, assuming it gets loaded at &8000 as its file attributes suggest (and *memoryi 8000 confirms that it is there). However, there is no meaningful code at &A3FC - it's an undefined instruction. So I don't know how it could have ended up there.