Re: network booting

[ol.sc@web.de (Oliver Schmidt)]

Hi,

>> So the client would need to tell on which offset into on of the
>> images it wants to read/write. This is however - as you surely noticed
>> yourself - the basic functionality of a network file system, isn't it?
>
>Not exactly - in a network file system, all the knowledge about what
>"blocks" (or sectors) make up a file exist in
>the server. The client asks the server to open a specific file (by
>name) and then to move around inside that file.

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.

>What I propose is to have the
>knowledge of what blocks make up a file (and what block contains VTOC
>or equivalent) stay in the client, but just redirect requests for a
>particular block to go over the network, not to the disk controller
>card.

With my clarification above it should be visible by now that I'm
exactly thinking about the same thing you do.

>> Most probably you've done that already but I've been looking around a
>> bit and found that NFSv2 is relatively simple and typically runs over
>> UDP:http://www.ietf.org/rfc/rfc1094.txt
>
>I did look at NFS but ruled it out since I want something that works
>at the block level not the file level.

Yes, but as stated above you could consider the Apple2 disk images as
the "the files" and then the puzzle pieces fall into place:

- RWTS redirection does read/write at a certain offset in a selected
disk image on the server.
- Your "main menu" does a directory listing of the available disk
images on the server.

>so in the query I can ask for "show me
>only A2 images that are ProDos", also as well as the name, I want the
>response to include the file system and size.

An NFS directory listing would support those requirements easily.

>> As far as I understand it's "only" a question of
>> doing the sector skewing on the "right" side (server vs. client).
>
>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?

>> I see. Even if 2) wouldn't be possible with ProDOS 8 it would still be
>> cool to patch/extend ProDOS 8 to access your server, maybe replacing
>> the /RAM device. This would allow to use the whole AUX bank for the
>> IP65 and client code...
>
>the bootstrap code I have at the moment (which is just the DHCP+TFTP
>layer), all lives in the language card. I'm struggling a bit to know
>where to stash everything, probably because I'm still a little fluffy
>on my use cases.

I see.

>Given ProDOS already supports layered device drivers, I figured if
>I can get this system working with DOS 3.3, then it shouldn't be too
>hard to get ProDOS working also.

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

>The advantage of putting stuff in the language card is, it's
>(slightly) more likely to be there than AUX is (i.e. you're not
>restricting yourself just to 128Kb IIes).

I see, but you need to know that the Uthernet card doesn't work in a
typical ][+ (most likely) because of slightly different CPU timings.

So avoiding the use of AUX adds only support for the quite few //e
without extended 80col board.

>The disadvantage is, it's
>more likely to get clobbered by the code that you d/l and execute.

Yes, quite some cracked games I know (converted from "disk games" to
"file games") use the LC - not only at runtime but having parts loaded
there by DOS...

>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.

>Thanks for the feedback to date!

You're welcome, Oliver