Date   : Thu, 29 Jul 2010 09:30:01 +0100
From   : michael.firth@... (michael.firth@...)
Subject: Spitting expletives

> -----Original Message-----
> From: 
> bbc-micro-bounces+michael.firth=bt.com@... 
> [mailto:bbc-micro-bounces+michael.firth=bt.com@...
> .uk] On Behalf Of Rob
> Sent: 29 July 2010 08:34
> To: BBC micro mailing list
> Subject: Re: [BBC-Micro] Spitting expletives
> 
<snip>
> >
> > I think the problem is that Jonathan is using an archemedes 
> which does
> > not IIRC have the no extension problem that widows does, so it's not
> > broken as far as he is concerned.
> 
> Hey, we're using Beebs, which have no file-typing method at all - we
> should be used to this :-)
> 
But the Beeb still manages to have more file Metadata than Windows - you 
get a minimum (on DFS) of 18 bit load and execution addresses, while Windows 
has none. To be fair, these days Windows has longer filenames than the Beeb,
but contemporary systems only had one extra filename character (8.3 vs 10.0),
and arguably the ".3" bit isn't really usable.

While it wasn't done on the Beeb (AFAIK), it would have been possible to
use load / exec address combinations that were illegal (or at least improbable)
as M/C addresses to represent file type information for application files. 

For FSes with true 32 bit load/exec addresses, for the period that the BBC 
was active, you could have used "top bit set, but not top 16 bits set" as
a pretty safe indicator. If you limited your 2nd processor capability to
the 16-bit 2nd processors, then you could have generated something that would
have worked for DFS too.

To some minor extent this was actually done for text files (load/exec either
all 0s or all 1s), and for Basic applications (exec address points to the
entry point for the Basic ROM)

I think that files copied from the Arc to the Beeb may have ended up like
this - I think the Arc access times and file types ended up in the BBC load/exec
address space on an ADFS floppy.

Regards

Michael