Detecting available file systems

Discuss all aspects of programming here. From 8-bit through to modern architectures.
Post Reply
Ottly
Posts: 152
Joined: Tue Jun 10, 2014 10:34 am
Contact:

Detecting available file systems

Post by Ottly » Mon Aug 19, 2019 9:03 am

Hi All,

What is the best method for detecting the available file systems in a Beeb? (ie: How would you program it in a program?) Is it just a matter of probing all the sideways ROMS and discovering DFS, NFS, ADFS, etc... or is there another method?

Also is there a way of detecting if a floppy drive is connected to the computer without it hanging/waiting for a response for eternity?

Thanks, Scott.
Last edited by Ottly on Mon Aug 19, 2019 9:04 am, edited 1 time in total.

User avatar
tricky
Posts: 3915
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Detecting available file systems

Post by tricky » Mon Aug 19, 2019 11:03 am

You might find something on Beeb Wiki.

I think tape and ROM are always available, and you van find the currently active file system number and if it is in a sideways ROM, the number from the extended vector table.
Last edited by tricky on Mon Aug 19, 2019 11:05 am, edited 1 time in total.

tom_seddon
Posts: 361
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: Detecting available file systems

Post by tom_seddon » Mon Aug 19, 2019 11:43 am

It's probably easiest to attempt to select the fs by its number using the rom service call, and then use osargs to see if the fs of interest was actually selected (in which case you know it's available).

You could have problems with ADFS trying to mount drive 0 though, i suppose...

In general (but without wanting to second guess too much...) I can't help thinking you'd probably be better off just letting the user select the fs they want using a * command, or assuming the selected fs is the right one, in case they're using one you're not aware of.

--Tom
Last edited by tom_seddon on Mon Aug 19, 2019 11:45 am, edited 1 time in total.

User avatar
lurkio
Posts: 2368
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Detecting available file systems

Post by lurkio » Mon Aug 19, 2019 4:06 pm

Here's a very crude way to do it in BASIC:

Code: Select all

 10 MODE7:VDU14:PRINT

 20 ONERROR PRINT"# Can't select DFS"':GOTO 80
 30 *DISC
 40 *DRIVE 0
 50 ONERROR PRINT"# DFS selected"'"# Can't catalogue drive 0"':GOTO 80
 60 *CAT
 70 PRINT '"# Selected DFS"'"# Catalogued drive 0 okay"'

 80 ONERROR PRINT"# Can't select ADFS"':GOTO 150
 90 *ADFS
100 ONERROR PRINT"# ADFS selected"'"# Can't mount drive 0"':GOTO 150
110 *MOUNT 0
120 ONERROR PRINT"# ADFS selected"'"# Drive 0 mounted"'"# Can't catalogue drive 0"':GOTO 150
130 *CAT
140 PRINT '"# Selected ADFS"'"# Catalogued drive 0 okay"'

150 REM etc.

160 VDU15:END

:idea:

User avatar
jgharston
Posts: 3806
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Detecting available file systems

Post by jgharston » Mon Aug 19, 2019 5:21 pm

tom_seddon wrote:
Mon Aug 19, 2019 11:43 am
It's probably easiest to attempt to select the fs by its number using the rom service call, and then use osargs to see if the fs of interest was actually selected (in which case you know it's available).
You could have problems with ADFS trying to mount drive 0 though, i suppose...
The proper way is to use Service Call 18 and cycle through all filing system numbers 1-255, unfortunately, DFS 0.90 doesn't respond to Service Call 18, and (if configured) ADFS tries to mount a disk. You then have to fall back on *commands, which means requiring psychic abilities, dealing with Bad command errors, and ADFS trying to mount disks...

It's easier on the Master with FileSwitch-compliant filing systems, as you send Service Call &25 to ask for filing system information blocks. It can only be done from the I/O processor, along these lines:

Code: Select all

LDA #buffer AND 255:STA &F2
LDA #buffer DIV 256:STA &F3
LDY #0                       ; (&F2),Y=>start of buffer to receive FS info blocks
LDA #143:LDX #&25:JSR OSBYTE ; Service call &25 - ask for FS info blocks
; on return, (&F2),Y=>end of filled buffer
This will fill the buffer with a number of 11-byte filing system information blocks in the format:

Code: Select all

EQUS "FSNAME  "   ; 8 characters, padded with spaces
EQUB channel_low  ; lowest channel number
EQUB channel_high ; highest channel number
EQUB fsnumber     ; filing system number

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

johnkenyon
Posts: 225
Joined: Wed Jul 20, 2011 2:21 pm
Location: Coventry
Contact:

Re: Detecting available file systems

Post by johnkenyon » Tue Aug 20, 2019 10:13 am

jgharston wrote:
Mon Aug 19, 2019 5:21 pm
The proper way is to use Service Call 18 and cycle through all filing system numbers 1-255, unfortunately, DFS 0.90 doesn't respond to Service Call 18, and (if configured) ADFS tries to mount a disk. You then have to fall back on *commands, which means requiring psychic abilities, dealing with Bad command errors, and ADFS trying to mount disks...
Can't you use *FADFS to select ADFS without mounting a disc?

User avatar
jgharston
Posts: 3806
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Detecting available file systems

Post by jgharston » Tue Aug 20, 2019 10:48 am

johnkenyon wrote:
Tue Aug 20, 2019 10:13 am
jgharston wrote:
Mon Aug 19, 2019 5:21 pm
The proper way is to use Service Call 18 and cycle through all filing system numbers 1-255, unfortunately, DFS 0.90 doesn't respond to Service Call 18, and (if configured) ADFS tries to mount a disk. You then have to fall back on *commands, which means requiring psychic abilities, dealing with Bad command errors, and ADFS trying to mount disks...
Can't you use *FADFS to select ADFS without mounting a disc?
That's part of the psychic abilities. How does the person writing the program know that there's a filing system number 73 which is selected with the *ZEEBAR command, but must be selected with the *XEBURE command to prevent it attempting to electrocute nearby cats on selection?

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
Rich Talbot-Watkins
Posts: 1578
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Detecting available file systems

Post by Rich Talbot-Watkins » Tue Aug 20, 2019 11:07 am

jgharston wrote:
Tue Aug 20, 2019 10:48 am
That's part of the psychic abilities. How does the person writing the program know that there's a filing system number 73 which is selected with the *ZEEBAR command, but must be selected with the *XEBURE command to prevent it attempting to electrocute nearby cats on selection?
How did that get out in the wild? I only ever wrote that for my own personal use!!

(I think the usual way is that a program doesn't try to force any particular filing system at all; it just sticks with the one which was active when it started, and can provide a '*' command input if someone really wants to change it.)

johnkenyon
Posts: 225
Joined: Wed Jul 20, 2011 2:21 pm
Location: Coventry
Contact:

Re: Detecting available file systems

Post by johnkenyon » Tue Aug 20, 2019 5:04 pm

Rich Talbot-Watkins wrote:
Tue Aug 20, 2019 11:07 am
jgharston wrote:
Tue Aug 20, 2019 10:48 am
That's part of the psychic abilities. How does the person writing the program know that there's a filing system number 73 which is selected with the *ZEEBAR command, but must be selected with the *XEBURE command to prevent it attempting to electrocute nearby cats on selection?
How did that get out in the wild? I only ever wrote that for my own personal use!!

(I think the usual way is that a program doesn't try to force any particular filing system at all; it just sticks with the one which was active when it started, and can provide a '*' command input if someone really wants to change it.)
For most programs that's the way forward, but if you want to write the new 21stC version of "Copyfiles" or "treecopy" you might need to populate an array with all the available file systems...

User avatar
jgharston
Posts: 3806
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Detecting available file systems

Post by jgharston » Tue Aug 20, 2019 7:37 pm

johnkenyon wrote:
Tue Aug 20, 2019 5:04 pm
Rich Talbot-Watkins wrote:
Tue Aug 20, 2019 11:07 am
jgharston wrote:
Tue Aug 20, 2019 10:48 am
That's part of the psychic abilities. How does the person writing the program know that there's a filing system number 73 which is selected with the *ZEEBAR command, but must be selected with the *XEBURE command to prevent it attempting to electrocute nearby cats on selection?
How did that get out in the wild? I only ever wrote that for my own personal use!!

(I think the usual way is that a program doesn't try to force any particular filing system at all; it just sticks with the one which was active when it started, and can provide a '*' command input if someone really wants to change it.)
For most programs that's the way forward, but if you want to write the new 21stC version of "Copyfiles" or "treecopy" you might need to populate an array with all the available file systems...
Why? It's the user who knows what the user wants to do. Just let them select whatever they want and - to quote various Microsoft forums - the program should just ****y well do as it's ****y well told. Programs that try and read the mind of the user are one of the worst sources of frustration there is, and I've wasted too much of my life having to code around such brain-dead programmers.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

Ottly
Posts: 152
Joined: Tue Jun 10, 2014 10:34 am
Contact:

Re: Detecting available file systems

Post by Ottly » Wed Aug 21, 2019 8:10 am

Thank you all for your input. Its very much appreciated.

Just one last question. I was also wanting to know if you can detect if a drive is connected to an interface. Is this possible without the system just hanging?

tom_seddon
Posts: 361
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: Detecting available file systems

Post by tom_seddon » Wed Aug 21, 2019 11:38 am

Don't think so, at least not with os routines - for some reason the 8 bit filling systems never seem to have a timeout and will just sit waiting forever.

On the plus side, this gives you plenty of time to insert the disc.

--Tom
Last edited by tom_seddon on Wed Aug 21, 2019 11:40 am, edited 2 times in total.

User avatar
Rich Talbot-Watkins
Posts: 1578
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Detecting available file systems

Post by Rich Talbot-Watkins » Wed Aug 21, 2019 12:12 pm

tom_seddon wrote:
Wed Aug 21, 2019 11:38 am
for some reason the 8 bit filling systems never seem to have a timeout and will just sit waiting forever.
Actually, that's something I've never really thought about. If you send the 8271 a command when there's no disk in the drive, will it return an error result, or will it just stall and wait for one? Or, in other words, did DFS have no choice on this, or was it deliberately designed to just keep waiting instead of timing out?

tom_seddon
Posts: 361
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: Detecting available file systems

Post by tom_seddon » Wed Aug 21, 2019 6:40 pm

Rich Talbot-Watkins wrote:
Wed Aug 21, 2019 12:12 pm
tom_seddon wrote:
Wed Aug 21, 2019 11:38 am
for some reason the 8 bit filling systems never seem to have a timeout and will just sit waiting forever.
Actually, that's something I've never really thought about. If you send the 8271 a command when there's no disk in the drive, will it return an error result, or will it just stall and wait for one? Or, in other words, did DFS have no choice on this, or was it deliberately designed to just keep waiting instead of timing out?
You can reset the 1770 mid-command, so a timeout of some form would have been possible on 1770 DFSs. Maybe it's impossible on the 8271 though (I have no idea) and the later 1770-based filing systems just followed suit?

--Tom

User avatar
Rich Talbot-Watkins
Posts: 1578
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Detecting available file systems

Post by Rich Talbot-Watkins » Wed Aug 21, 2019 6:46 pm

Quick look at the datasheet, and it seems like the 8271 can return "Drive Not Ready" if the drive is not powered up, the disk is not loaded or a non-existent drive is accessed. So no idea why Acorn's DFS doesn't respond to it.

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

Re: Detecting available file systems

Post by BeebMaster » Wed Aug 21, 2019 8:23 pm

In some circumstances with DFS 0.98 or 1.20 I can get the not ready error (Drive fault &14) when there is a floppy disc drive plugged into the port but it is not powered on.

This error also occurs with 3.5" disc drives when the head steps to the next track during a load operation.
Image

Ottly
Posts: 152
Joined: Tue Jun 10, 2014 10:34 am
Contact:

Re: Detecting available file systems

Post by Ottly » Fri Aug 23, 2019 11:23 am

Another question. If I write a routine in assembly to cycle through the file systems how do I capture/handle the errors?
(For example is basic we use ON ERROR GOTO XXX.)

Is it a matter of redirecting the BRK vector to my own error handling routine or is there another method?

What is best practice? Is there any example source code out there to get the idea?

Thanks Scott.
Last edited by Ottly on Fri Aug 23, 2019 11:26 am, edited 2 times in total.

julie_m
Posts: 112
Joined: Wed Jul 24, 2019 8:53 pm
Location: Derby, UK
Contact:

Re: Detecting available file systems

Post by julie_m » Sat Aug 24, 2019 2:57 pm

Does any program other than a file systems diagnostic test even have to be aware of different file systems?

If different file systems -- cassette, ROM, Acorn DFS, third-party DFS, DDOS, ADFS, econet -- are available, then all you really need do is make sure your software works with them all transparently, and gives the user the full opportunity to choose one for themselves.

Obviously something like an on-screen file selector needs to be able to spot things like whether a file is a plain file or, where supported, the directory of a folder. (and there is usually room on screen for all 31 files on a DFS disc, without having to pretend DFS "directories" are folders -- you can just treat the directory letter as part of the filename.) But if you use only legal MOS calls and extensions, and have robust error-trapping including responding to ESCAPE key presses in case the user does something like asking for a catalogue of files on a cassette, you've really done all that can be expected of you. If you can provide a CALL or GOTO statement of last resort, in case the user attempts something really hopelessly wrong and winds up dumped back at the BASIC prompt, so much the better.

The user is queen or king of their own hardware, especially in retro-computing land where you can generally assume the user has some smarts; and your software should not get in the way of whatever they may be trying to do.

Post Reply