Date   : Fri, 11 May 2001 17:30:03 +0100
From   : "Richard Gellman" <r.gellman@...>
Subject: Re: DFS to ADFS, *MOVE/*COPY

>Right, the new execution address of a relocated code
>is <new load address> + (<old execution address> -
><old load address>) yeah?  It's a simple formula,
>should this work then?  Unless the copyrighters have
>faked the file info, I find &8023 to be a pretty
>common execution address for some files.

Uh....

I dont know about that.

The way games relocation worked was thus:
Load BASIC program into &1900
Set MODE 7 - frees memory up to &7C00
Load machine code into a location higher than TOP
If its small enough, the BASIC program would relocate it to a lower
location, else call a machine code routine which:
Move the entire code (currently overflowing into what would be the memory
area for MODE x) to a lower location, such that the last byte is BEFORE the
first byte of screen memory, e.g. &5F00 (>&5800, MODE 5) becomes something
like &5700 - out of the way
Jump to proper starting point, (which would be in filing system workspace,
but is now free because disc operations are done).
Game then sets screen mode.

Cunning eh?

As for &8023... BASIC sets that to a point in the BASIC ROM which
essentially does nothing. This is supposed to be in case you accidentally
try to *RUN a BASIC program. If you do CALL &8023 on a model B, nothing
happens, u get the BASIC prompt back.

This kinda fails when you consider that on the Master 128, this address
moved to &802B, thus making most BASIC programs crash the system anyway when
*RUN.

As a sidenote, you mention faking info. A lot of discs had "fake" files on
them, which were actually loaders for files that had their data hidden on
the disc. This prevented file-for-file copying from working, and also, due
to the way the data was stored (move disc head to far end of disc, then work
back), it made sector-for-sector copying impossible too. But there are ways
around it... *glances at his ADFS disc full of games*

-- Richard Gellman