Date   : Mon, 31 Jul 2000 21:27:26 +0100
From   : "Shaileen Shah" <shaileen.shah@...>
Subject: Re: How does tape filing system handle addresses?

----- Original Message -----
From: Rich Talbot-Watkins <Richard_Watkins@...>
To: BBC Micro <bbc-micro@...>
Sent: Monday, July 31, 2000 6:18 PM
Subject: Re: [BBC-Micro] How does tape filing system handle addresses?


> [Apologies if this arrives twice]
>
> Mark de Weger wrote:
>
> > As Robert pointed out, the reason that his copy of Hampstead won't run
on an
> > emu (or a disc-based Beeb with an E00 DFS) is the weird load and exec
> > addresses. However, according to Dave, the sane copy works fine on in
> > UEF-format (tape).
> >
> > Therefore, I assume that the tape filing system handles load and exec
> > addresses different than the DFS. Anybody got a clue how?
> >
> > Thanx,
> > Mark.
> >
> > P.S. The first program that won't run, HAMPST1, is loaded by a Basic
program
> > with the command */
>
> and Robert Schmidt wrote:
>
> > The version on TBL! is tape based and uses longer filenames than DFS
> > supports.  I've managed to hack the filenames, but it still doesn't load
> > correctly.  Could the weird load addresses be a problem, even when using
> > a E00 DFS?
> >
> > $.HAMPST1 d9cd ffff 3c5
> > $.HAMPST2 400 67e 5700
>
> One reason that this won't work on a disc system is that it's attempting
to
> load HAMPST2 straight over the DFS NMI workspace between &D00 and &D9F -
and
> since this is rather crucial to the disc system, it's not surprising it
> doesn't work when it gets corrupted.
>
> The solution to this would be to load HAMPST2 at &1400 and then relocate
the
> code and run it using this little code snippet:
>
> P%=&380:[OPT2:LDX#&57:LDY#0:.loop LDA&1400,Y:STA&400,Y:INY:BNEloop:
> INCloop+2:INCloop+5:DEX:BNEloop:JMP&67E:]
> CALL&380
>
> As for HAMPST1, I'm rather baffled - I can't really believe that those are
the
> correct load/exec addresses.  It's trying to load into the area occupied
by
> the OS (which is obviously not writable) and then supposedly execute from
FFFF
> which makes little sense either.
>
> Hmmmm.... any more info?

Going back to the good old days, I remember that the data on the individual
tape blocks could be altered. This was used to great effect on programs such
as Arkanoid (changing file names), Stairway to Hell (reverse loading), and
Firebird software (no gaps between the tape blocks). The point is that I
think whereas the displayed file info is obtained from the last block, the
machine takes its readings from the first block i.e. the first block has the
correct load/exec addresses, and the rest are false, created by an interrupt
driven program which places the false data into the tape address memory.
(Could be the other way round). At one time, I would have been able to sort
this problem, but unfortunately, I cannot remember a single bit of 6502
assembler (even the bit above barely makes sense to me now). Obviously, a
tape based copy of the game would be needed. I haven't got my Advanced User
Guide handy, but one way that may work is to use a *OPT command (can't
remember which but one causes loading to abort on error) and *run the
hampstead1 file, stop the tape after the first block and check what the real
load/exec buffers are. Hope this helps in at least clearing up the mystery
if not solving it.

(What is the UEF format? I'm surprised the tape image works through this,
and if so the above won't make sense.)

Shaileen.