How did games written for tape-based BBC micro, get officially and unofficially ported to disk, bearing in mind extra workspace needed by DFS ROM?

Question

If I recall, PAGE = &E00 for a BBC Model B system with cassette tape based storage.

On installation of Acorn DFS ROM (with 8271 Floppy disc controller), the ROM allocated more memory, increasing PAGE to &1900 . It could be reduced as far back down to &1300 if I recall, if the user wasn't making use of *COMPACT I think.

PAGE is the starting point address for programs such as BASIC and other programs to run.

( Where & (ampersand) is the BBC micro / Acorn notation for stating a number is hexadecimal/hex. On other systems it was $ (dollar) and modern engineering general convention denotes it as 0x e.g. 0xFFFF or 0xE00 etc. )

So, 3 constraints / considerations here for porting games written before disks common place:

• relocatable code if starting address changed
• less memory available
• copy-protection for unofficial ports - I've certainly seen this in Ghouls ("END OF THE LINE" message followed by a hard reset when attempting the port amateurishly).

As far as I can remember, there wasn't any game that couldn't be ported. Indeed, a friend of another school had a hacker-friend who would seemingly hand port games from tape to disk. This was necessary as the original tape-based game couldn't sometimes just be loaded into memory from tape and then *SAVEd to disk to be *LOADed and run - they may not have worked. This was due to at least one of the above 3 constraints.

On the BBC Master 128, with more memory, I think this workspace memory claimed by the DFS was mapped elsewhere, so 2 of the above constraints may not have applied but other compatibility issues e.g. undocumented 6502 instructions or (unofficial) assumptions about locations of memory mapped things might then have been a challenge.

Answer 1

Both the DFS and the ADFS did indeed reserve memory for themselves at startup, increasing PAGE; this memory was used to hold the current catalogue and other bookkeeping.

For adapting existing tape software two observations are helpful:

1. almost nothing on the BBC was a multiload; and
2. you can turf the [A]DFS out of memory if you don't intend to use it again.

So the task was to find enough space to load the game, disable whichever filing system it had come from, then relocate the game to its proper place.

Usually you could achieve that just by loading into the screen area — this needn't be visible as there are a multitude of ways to disable the display temporarily.

More elaborately you might load a compressed version of the game and decompress after loading.

In principle you could alternatively write a small stub that disabled the filing system and then directly piloted the disk controller; on both disk filing systems files are always stored contiguously so the amount of state required to do a destructive load is negligible, being just the current sector and length remaining.

Cracking copy protection is a much larger topic, and substantially more involved, and I'm not sure I could give it a thorough treatment. Luckily it wasn't that common for tape-based games since a twin-deck tape player was essentially impossible to defeat as a copying device.

PAGE &E00 filing systems also definitely weren't exclusive to the Master; if you had sideways RAM then suitable third-party DFSs were available.