Level 3 File Server Source Code

bbc/electron apps, languages, utils, educational progs, demos + more
Post Reply
User avatar
BeebMaster
Posts: 3662
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Level 3 File Server Source Code

Post by BeebMaster » Tue Sep 08, 2020 10:30 am

Alan Williams posted the L3 file server source code (version 1.06) here, but it got trampled in all the excitement about the 256K second processor. I've used the source code a couple of times to try to understand things about the L3 server, such as the calculations for the cylinder free space bitmaps here and cracking the mystery of how the Real Time Clock dongle is read and written here.

For this I've used an amalgamated text file of the source code files so it's all in the right order. Here's that file now for people to have a look at.

There's lots of possibilities with the source, such as putting in 21st century dates (as with hacks to other versions), optimising the way free space is allocated, so it doesn't have to read and write dozens of sectors of free space bitmaps to allocate the space for a big file. I'm thinking just have a free space bitmap at the start of the Econet part of the disc for the entire disc instead of spacing it out at the beginning of each "cylinder".

I don't know if it would be possible to add support for the 256K second processor, being able to use a large object cache would help a lot.

Also this version pre-dates the parent directory being stored in a directory (allowing *DIR ^) so that could be added as well.
Attachments
L3All.zip
(122.12 KiB) Downloaded 22 times
Image

awilliams
Posts: 42
Joined: Sun Feb 22, 2015 10:51 am
Location: Adelaide, Australia
Contact:

Re: Level 3 File Server Source Code

Post by awilliams » Thu Sep 24, 2020 1:25 am

Just some random comments.

In another thread discussing 1.24 there was mention that the parent directory pointer was implemented in the 2ndProcessor build and that the second hard drive did not work any more.

I think what happened here is that the Filestore build, targeting SCSI discs, changed the idea of the next drive from the next lun on the same scsi id to lun 0 on the next scsi ID. (which is what the stacking filestore, EO1S, expects, and EO1 if you hack it to stack)

The other thing as you mention above that happened in the filestore builds, the earliest of which I have is 1.23 is the change to filling the bitmap blocks and not thinking about the drive in CHS any more. This would need changes to the disk initialiser too, the filestore one knows how to do it.

I don't have 1.24 to test yet but 1.23 on filestore also adds server side resolution of context prefixes on file names. ie & @ % for clients that don't do that locally. This is mostly BBC's I think. This facility was dropped in later versions of the filestore code such as 1.39.

The filestore builds also included a check for the a copywrite message in one of the Rodime drive's 'driver controller pages', though later this could be configured in filestore cmos to be disabled. This largely stopped you taking a L3 disk and plugging it into a EO1.

Alan

User avatar
BeebMaster
Posts: 3662
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Level 3 File Server Source Code

Post by BeebMaster » Thu Sep 24, 2020 1:38 pm

Interesting - the L3 initialiser WFSInit and Net partition sector zero have variables for next physical drive and next logical drive, but only the next physical drive is set by WFSInit based on the "next drive" value input by the user, and it always sets the next logical drive offset to 1. So maybe that was changed in the FileStore to better address multiple SCSI drives. There's also a Winchester vs. Floppy flag in Net sector 0, but I don't know what software implements that or what it does with it. (I think the free space sector bitmap of an ADFS floppy disc is actually stored in the ADFS part of the disc, not the Net part).

The FileStore initialiser groups the disc into chunks of sectors for the purpose of storing a free-sector bitmap at the beginning of each chunk, rather than storing a free-space bitmap in the first sector of each disc cylinder. So you end up with less wasted space, the E20 initialises with about 38 bitmaps whereas if it was done with WFSInit it would be over 600.

I'd be interested to see how the copyright check can be disabled. Using SCSI2SD, which supports vendor-specific SCSI commands, you can make it supply the correct copyright information in response to the mode page requested supported on the Rodime drives used by Acorn.
Image

awilliams
Posts: 42
Joined: Sun Feb 22, 2015 10:51 am
Location: Adelaide, Australia
Contact:

Re: Level 3 File Server Source Code

Post by awilliams » Fri Sep 25, 2020 5:55 am

> I'd be interested to see how the copyright check can be disabled.

Unfortunately my pair of EO1 units are both playing dead, and are next on the queue for some attention when I get my System4 running again. I can't remember or test, but the Filestore Service manual refers to FServCMOS, which I think is likely the tool to use to turn off the the copy write checking. It will only be in the later versions of those tools.

Let me know if I have to look for it, I am bound to have it. If so please recommend a imaging strategy. I am not that up with beeb disk imaging. I am inclined to convert to 3 1/2 put in RISC PC and pack with SparkFS, copy to nas email from mac. I may be able to attach a 5/14 drive to a PC, maybe linux or Win95 if doing it from there is more straight forward. I don't see populated FDD connectors on any of my newer machines. Potentially I could put a 5/14 drive into a RISC PC, amusingly that might just be more useful now than the CD ROM, but I don't know at all if that works.

Alan

User avatar
BeebMaster
Posts: 3662
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Level 3 File Server Source Code

Post by BeebMaster » Fri Sep 25, 2020 7:23 pm

Flippin eck, all that work I did bodging SCSI2SD to allow custom vendor specific mode pages and had to nag the developer about it - and all I had to do was change the copyright check bit in the E01 CMOS RAM! I've looked at Rick Murray's FileStore pages, he confirms byte 49 is the copyright check flag. I don't recall ever seeing that before.

FServCMOS is part of the dealer test disc which has been archived, the version I have doesn't mention the copyright flag:
E01E20FSTest43.jpg
Image

Post Reply

Return to “8-bit acorn software: other”