Date   : Mon, 22 Nov 2010 20:22:29 +1100
From   : station240@... (paul aslin)
Subject: BBC file formats

> Date: Sat, 20 Nov 2010 21:57:50 +0000
> From: kranser@...
> To: bbc-micro@...; mfirth@...
> Subject: Re: [BBC-Micro] BBC file formats
> 
> --- On Fri, 19/11/10, Michael Firth <mfirth@...> wrote:
> > What he said :-)
> > 
> > Plus, the reason it can be done is that games usually have
> > a startup 
> > screen in Mode 7, which only needs 1K of RAM
> > (HIMEM=&7C00), but run the 
> > actual game in one of the high graphics and colour modes
> > (usually Mode 1 
> > or Mode 2), which need 20K of RAM (HIMEM=&3000).
> > 
> > Thus, with DFS you load the game above PAGE while in Mode
> > 7, then switch 
> > to TAPE, move the code down, and then you can switch to the
> > high memory 
> > mode.
> 
> Thanks for the detail Michael.
> 
> The simple loop to move the code down in memory doesn't do any address
translation for JSR/JMP - so I presume that the code was developed to run
at &E00 (using O%)?
> 
> So, this begs the question as to how the programmer(s) tested the work,
seeing that they would need DISC access and the code would need to run at
&E00 and use a high-memory requirement MODE. So any ideas on how they would
test the Machine Code program?
> I guess they would run the source BASIC program to create the machine code
on disk and then transfer the disk to another machine to run the machine
code, and then transfer the disk back to update and save the source program!

There is a thread on *. in which on programmer admits to having a modifed 
OS rom that bypasses the copy protection system he was writing (so it wouldn't
clear the memory on break if I recall). Never assume they didn't have some
less than obvious solution.

It would be easy enough to  write a reverse the process, by switching back
to mode7 and relocating the code back so DFS can be used again.