Re: network booting

[Jonno Downes <jonnosan@gmail.com>]

On Jan 16, 9:18 pm, ol...@web.de (Oliver Schmidt) wrote:
> Hi,
>
> Sorry that my statement above wasn't precise enough but I certainly
> didn't want to propose to use a network file system to access
> individual Apple2 _files_. Rather I wanted to point out that
> reading/writing sectors/blocks in Apple2 _disk_images_ located on a
> server basically maps 1:1 to ordinary network file system I/O in these
> files.

So you mean have the client convert a track/sector into a file offset,
and seek to that point in the file? I.e. for a standard 16 sector DOS
3.3 dsk, a RWTS for track 3, sector 2 would be converted to a read
request for 256 bytes from offset (((16*3)+2)*256)=12800

I've got some concerns with that - not sure if that's just because I'm
already mentally committed to my original approach. They're mostly
minor things (like how do you handle sector ordering) and I could
probably live with them if I thought it meant I could use a standard
NFS server, but I suspect I'd still need to roll my own to do
everything I want. But I'll sleep on it...

> >I'm actually proposing to have the bytes per sector, sectors per
> >track, and tracks per volume all be negotiated within the protocol
> >itself.
>
> I see. But what about the sector order?
That should be transparent to the client, the server would apply some
heurestics (using the same code I'm already using for that purpose in
peekbot) to work out what sector order the dsk image is in - this
would actually be one of the reasons an out-of-the-box nfs may not
work.

>
> Could you elaborate on what you are refering to with "layered device
> drivers" in ProDOS8?
>

I meant the fact ProDOS8 supports device drivers, seperate from the
file management layer. So instead of patching RWTS, and hoping any
program you want to run does actually use the loaded RWTS and not try
to access the disk drive directly, you can be a lot more confident
that a ProDOS8 app will work regardless of what the storage medium it
resides on is.


> >I
> >actually started with trying to put the code in the aux bank, and
> >changed my mind when I couldn't get it to work straight away :-) (this
> >is my first experience with bank switching).
>
> Yes, it's not that simple... You might be interested in the afaik not
> so popular idea of switching in only $2000-$3FFF from AUX RAM intended
> for easier DHGR programming while not actually switching on DHGR. This
> gives access to 8k of AUX very easily.

I'll give that a go - thanks for the suggestion.

Cheers

Jonno