Wishful thinking - B+ OS, C/C++ DFS/ADFS

discussion of beeb/electron applications, languages, utils and educational s/w
Post Reply
crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by crj » Thu Dec 14, 2017 12:20 am

I'm struggling to find a couple of things...

The first is a copy of the BBC B+ MOS. I'm sure it must be out there somewhere on the Internet, but it's not an easy thing to Google for. One with disassembly would be superb, of course, but beggars can't be choosers.

The second I'm less sure will exist: is there by any chance a fully-featured and robust C/C++ implementation of DFS out there anywhere? I know there are various tools for packing files into DFS .ssd images, but they don't do a full range of filesystem operations, and many seem to be closed-source.

I'd also be interested if anyone knew of an equivalent C/C++ implementation of ADFS. But I get the impression ADFS .ssd images are way less common?

PS: Was the BBC Basic 2 in the Electron identical to the one in the BBC Micro?

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

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by lurkio » Thu Dec 14, 2017 12:32 am

crj wrote:I'm struggling to find a couple of things... The first is a copy of the BBC B+ MOS. I'm sure it must be out there somewhere on the Internet, but it's not an easy thing to Google for. One with disassembly would be superb, of course, but beggars can't be choosers.
http://mdfs.net/Info/Comp/Acorn/Source/

:idea:

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by crj » Thu Dec 14, 2017 1:08 am

Aha, thanks!

User avatar
danielj
Posts: 6144
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by danielj » Thu Dec 14, 2017 6:33 am

Yes, elk basic II is identical to beeb basic II. The elk will happily run basic 4 if you drop a 65C02 into it too :)

d.

ThomasHarte
Posts: 458
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by ThomasHarte » Thu Dec 14, 2017 4:48 pm

Part of the puzzle only, alas, but David Boddie's 2008 fuse_adfs purports to be a plug-in for FUSE that implements ADFS. Inspired by that, Andrew Benham also offers a plug-in for DFS. although his is in Perl and hasn't been updated for a little longer.

FUSE is the filesystem in userspace project, it's a Linux kernel module that allows the logical parts of filesystem interpretation to run in userspace i.e. with no special permissions needed, and in a much more relaxed environment. You implement just the basic parsing, and then the filesystem you've implemented acts just like any other: all the standard manipulation and navigation tools just work.

Supposing you're not a Linux user, there's also a version of FUSE for the Mac. Given the kernel driver that underlies it, I would not expect it to work with the Linux subsystem for Windows, and sadly am not aware of any obvious alternatives there.

If you're looking for C/C++ in order to build it into your own project then I'm aware of even less. I can point you to my own C++ unpacking code for DFS and ADFS (105 lines total, you probably could have read it by now, MIT licence, fill your boots) but you'd need to adapt it very, very slightly to work directly with a disk image as at the minute it takes the emulator's abstract version of a disk (which is very abstract indeed by most emulator's standards), attaches an [M]FM parser and then goes through that to read sectors. So just replace the various usages of get_sector.

EDIT: no, wait, it looks like I've skimped on ADFS parsing. It's just verifying that an ADFS root catalogue exists and grabbing the boot option. Work to do. Scratch that suggestion for ADFS. Obviously I went as far as necessary to be able to detect that a disk image has ADFS content and no further than that. It'll possibly need to grab file contents at some point to do machine detection, so that will be corrected.
danielj wrote:Yes, elk basic II is identical to beeb basic II. The elk will happily run basic 4 if you drop a 65C02 into it too :)

d.
Though with a processor swap it'll probably no longer run Exile or E-Type...

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

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by Rich Talbot-Watkins » Thu Dec 14, 2017 9:19 pm

ThomasHarte wrote:Though with a processor swap it'll probably no longer run Exile or E-Type...
Why's that? Do the Electron versions exploit the illegal NMOS opcodes or something? :?:

ThomasHarte
Posts: 458
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by ThomasHarte » Thu Dec 14, 2017 9:41 pm

Rich Talbot-Watkins wrote:
ThomasHarte wrote:Though with a processor swap it'll probably no longer run Exile or E-Type...
Why's that? Do the Electron versions exploit the illegal NMOS opcodes or something? :?:
If memory serves, Exile uses the illegal opcodes while decrypting itself, and E-Type uses them for scaling graphics. This is a dim, distant memory from when I had implemented some of them incorrectly, way back in the '90s.

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by crj » Fri Dec 15, 2017 12:56 am

ThomasHarte wrote:Part of the puzzle only, alas, but David Boddie's 2008 fuse_adfs purports to be a plug-in for FUSE that implements ADFS.
Mmm. I did find that. But as well as being written in Python, it's read-only. It also "cheats" by unpacking the ADFS floppy image into Python structures before it begins then servicing requests from that. Such a strategy involves keeping the entre disc in memory, and not even in an efficient form, plus the architecture is completely unsuited to being extended to perform writes. )-8

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

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by jgharston » Fri Dec 15, 2017 4:16 am

Andrew Benham has written FUSE ADFS and DFS filesystem modules in Perl here: http://www.adsb.co.uk/bbc/linux/

Code: Select all

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

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by crj » Fri Dec 15, 2017 5:53 am

Those seem to have the same limitations as the previous one, with the additional handicap of being written in Perl rather than Python. /-8

I suspect I'll end up writing my own C++ DFS implementation using the real DFS as a crib, and leaving ADFS as a project for anybody who's sufficiently keen...

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

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by Rich Talbot-Watkins » Fri Dec 15, 2017 8:35 am

ThomasHarte wrote:If memory serves, Exile uses the illegal opcodes while decrypting itself, and E-Type uses them for scaling graphics. This is a dim, distant memory from when I had implemented some of them incorrectly, way back in the '90s.
Oooh, that's surprising, but also kinda cool. Obviously the Beeb versions can't as they need Master series compatibility, but it's nice to think that, since the Electron version is distinct anyway, they tried to squeeze a bit more performance out of it by using the illegal opcodes.

The only pre-Master title I was aware of which uses them (other than for some of the old Acornsoft disk protections) is Zalaga. It uses them to quickly transpose bits 0,2,4,6 with 1,3,5,7 when plotting flipped sprites (which I'm sure you were aware of!).

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

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by jgharston » Fri Dec 15, 2017 5:20 pm

crj wrote:Those seem to have the same limitations as the previous one, with the additional handicap of being written in Perl rather than Python. /-8
I suspect I'll end up writing my own C++ DFS implementation using the real DFS as a crib, and leaving ADFS as a project for anybody who's sufficiently keen...
The DFS code has some comments in it along the lines of "Acorn DFS uses 10-bit sector addresses, Solidisk DFS overflows its 11-bit sector address into the load address, but I've misplaced my Solidisk manul to be certain, but this seems to work".

I've downloaded a handful of Solidisk DFS manuals trying to find this infomation, but none of the ones I can find describe the on-disk catalog layout. Or the extensions to the ADFS on-disk layout. Can anybody point to the info?

If I get around to getting a C compiler for my Linux system I might have a bash at a C-coded ADFS module.

Code: Select all

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

ThomasHarte
Posts: 458
Joined: Sat Dec 23, 2000 5:56 pm
Contact:

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by ThomasHarte » Fri Dec 15, 2017 7:13 pm

jgharston wrote:I've downloaded a handful of Solidisk DFS manuals trying to find this infomation, but none of the ones I can find describe the on-disk catalog layout. Or the extensions to the ADFS on-disk layout. Can anybody point to the info?
I just had a quick search too, and it doesn't look like Solidisk were big fans of technical documentation.

All I found stated definitively is that Solidisk's definitely not compatible with Opus' double density version DFS, and that at least as of version 2 it'll store extra catalogues as needed. That latter tip is under 'unlimited filenames' in the 'provisional user guide for the STL DDFS 2.0 ROM' from 8bs.

So there are at least two deviations from Acorn DFS, even putting data encoding aside. Possibly reverse engineering is all we have?

Coeus
Posts: 770
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by Coeus » Fri Dec 15, 2017 8:43 pm

I did write some ADFS stuff in C/C++ a while back so I have put it up on GitHub as a project at https://github.com/SteveFosdick/adfs-c-

Looking back at it, the API appears to be at file level, rather than at byte level in the sense that you can read afile from an ADFS virtual disk into a block of memory or save a block of memory as an ADFS file, but not "open" a file, seek around and read it a small number of bytes at a time.

Even if that API is not suitable you may find some functions/methods that are helpful to write what you really want.

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by crj » Sat Dec 16, 2017 12:20 am

jgharston wrote:I've downloaded a handful of Solidisk DFS manuals trying to find this infomation, but none of the ones I can find describe the on-disk catalog layout. Or the extensions to the ADFS on-disk layout. Can anybody point to the info?
There were extensions to the ADFS on-disk layout?

When my BBC B with Solidisk disc interface got burgled, we upgraded to a Master. That read all my old Solidisk ADFS discs just fine, so any extensions must have been compatible.

Because I migrated to ADFS at the earliest opportunity, my memory of the catalogue layout for Solidisk DFS is extremely hazy, and may have got conflated with the Opus/Watford ones over the decades, but when it wanted to overflow the normal catalogue, didn't it just stick a file there with a corrupt filename that spanned the rest of the disc, and put a new catalogue in the first two sectors of that file?

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

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by jgharston » Sat Dec 16, 2017 5:28 am

crj wrote:
jgharston wrote:I've downloaded a handful of Solidisk DFS manuals trying to find this infomation, but none of the ones I can find describe the on-disk catalog layout. Or the extensions to the ADFS on-disk layout. Can anybody point to the info?
There were extensions to the ADFS on-disk layout?
You can set a per-directory password. You set a directory's password with a "PROTECT" program, and "log into" a directory with a *PASSWORD command. I'm assuming that gets stored in the "reserved - zero" bytes at &4EC-&4FA.
crj wrote:When my BBC B with Solidisk disc interface got burgled, we upgraded to a Master. That read all my old Solidisk ADFS discs just fine, so any extensions must have been compatible.
If the password was just stored in the spare bytes and compared to what is set with *PASSWORD, and the directory itself isn't encrypted with the password, then the security can be bypassed by the simple method of using a different ADFS!
crj wrote:Because I migrated to ADFS at the earliest opportunity, my memory of the catalogue layout for Solidisk DFS is extremely hazy, and may have got conflated with the Opus/Watford ones over the decades, but when it wanted to overflow the normal catalogue, didn't it just stick a file there with a corrupt filename that spanned the rest of the disc, and put a new catalogue in the first two sectors of that file?
I've added what I can glean from ADSB's fuse-dfs module to my DFS documentation. I haven't yet worked out how it extends the directory, I'll have to find some ROMs and plug them into an emulator and do some testing.

Code: Select all

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

Coeus
Posts: 770
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Wishful thinking - B+ OS, C/C++ DFS/ADFS

Post by Coeus » Mon Dec 18, 2017 6:29 pm

It looks like STL DFS stores the sector address for the 2nd catalogue at &0103 in the first catalogue, in space normally used for the disc title, but it also sets &0102, in the case I tried to &C0. As nothing else in the first catalogue has changed it looks like it doesn't put a fake entry in the first catalogue to occupy the space used by the 2nd catalogue, at least not when the first catalogue is full.

I attach a ZIP of two SSDs, one will exactly 31 files so the first catalogue is full and one with 32 files so a second catalogue has been created.

It seems this scheme can be extended to a third catalogue and maybe more using the same mechanism, i.e. with a third catalogue the sector address of that is stored at offset 3 into the second sector of the second catalogue and the byte at offset 2 in that same sector is also &C0. In the last extended catalogue in the chain that byte is &80. Also the byte at offet 1 in the second sector of a catalogue appears to be involved - with three catalogues it is &00 in the first (Acorn standard) one, &21 in the second catalogue and &41 in the third catalogue.
Attachments
stltwocat.zip
ZIP of two SSDs, one catalogue and two STL DFS
(1.29 KiB) Downloaded 9 times

Post Reply