8-bit acorn software: classic games • Re: Exile: the disc incompatibility bugs

Hi Cris,

Sorry for dragging up an old thread...

- Exile_D1S1_80T_HG3_2066CA7D_1.hfe
Believed to be the v1 release.
Contains a disc protection system whereby the catalog is hidden. Even !BOOT is hidden via some control character trickery. The main copy protection track is a track with a bunch of funky sector headers that spell out an ASCII message.

- Exile_D1S1_80T_HG3_EA8CECA2_1.hfe
Believed to be v2. Same set up as v1.

- Exile_D1S1_40T_HG3_0E245387_1.hfe
- Exile_D1S2_80T_HG3_162468BD_1.hfe
Let's call this v3.
A later flippy disc release (40T / 80T flipside) with much simpler disc protection based on Superior's standard "deleted sector" protection.

I've been having a look at these discs as part of an effort to get them running via Ecoent, and I'm getting different results to you. However, the first thing I would like to clarify is naming, to make sure I'm using the same files as you. On your google drive, the three versions are named Exile_Vx_FSDyyy_1.hfe, where x appears to be the version number, and yyy is some other reference. Do these files relate to the three versions above?

On my real beeb with a 1770 controller, V1 won't load, but both V2 and V3 will load and run. Also, I get an empty catalogue on the V1 and V2 disk and see the files listed on the V3 disk, so I do believe the files I'm using are the correct ones.

Now the problems:
2) v1 has a serious bug with DFS-0.9.
This one is a surprise, and I confirmed it on real hardware. Most earlier beebs with discs had Acorn's 8271 based DFS-0.9. It's a very common setup so this bug may have been a big chunk of the Exile woes.
The Exile menu program (where you load / save games, view position, run main game, etc.) appears to clash in some way with the DFS-0.9 work space when you do disc operations such as load saved games. Sometimes it works, sometimes it behaves a bit weird but works and sometimes it dies horribly.
After a bit of investigation:
- It loads saved files more reliably if you hit F3 (show catalog) first, although it displays some system messages the the Exile font:

exile_load_reddor.png

- If you load without F3, it seems to erroneously jump to memory location $0100 and execute unintended 6502 opcodes, including the filename you are trying to load (!!!!!). In the case of my 1REDDOR file name, "R" is opcode $52 which is undocumented and called "KIL". It wedges the 6502 CPU totally, so you've got a total hang. Shockingly, in the case of many other file names, it'll often stagger along, perhaps corrupting a bit of screen memory, but succeed in the load.

Code:

(6502db) m 1000100: D3 C8 24 2E 31 52 45 44 44 4F 52 20 20 20 20 20  ..$.1REDDOR     0110: 46 46 32 43 30 30 20 30 30 30 30 30 30 20 30 30  FF2C00 000000 000120: 30 34 30 30 20 31 33 45 0D 44 69 73 6B 20 63 68  0400 13E.Disk ch0130: 61 6E 67 65 64 00 D3 75 D3 75 D3 75 D3 75 D3 75  anged..u.u.u.u.u(6502db) d 100[ITRP] 0100: DCP ($C8),Y[ITRP] 0102: BIT $2E[ITRP] 0104: AND ($52),Y[ITRP] 0106: EOR $44[ITRP] 0108: NOP $4F[ITRP] 010A: !!!: $52

This is where it gets a bit odd. I've just loaded the V1 version of this game up on beebjit (great emulator, btw), and it seems to load and run fine for me. I'm saving to a blank ssd disc that is mounted as disc 1 in beebjit. I've checked that and confirmed that beebjit is using DFS v0.9, and it is. I'm running beebjit 0.9.8 if that's relevant.

Using the debugger, I even managed to grab a copy of the loader file (ExileL) once it had decrypted itself and it's identical to the loader from the V3 disc. Given that the loader files are identical, and we know V3 works ok, I'm struggling to understand why you were seeing the corruption when trying to load or save. All very odd!

Statistics: Posted by KenLowe — Tue Jan 21, 2025 1:34 am

---