MMFS2: Drives 2 and 3 don't work

[hoglet67]

From Mincr on stardot:

One quick bug: I don't seem to be able to DIN drives 2 and 3, although 0 and 1 work fine. If I do DIN 3 FILE.SSD, I don't get an error but a CAT gives "Disc sector not found at :3 00/00". It makes no difference if I do that or DRIVE 3 / *DIN FILE.SSD. The file and card are fine, I think, as it works as disc 0 or 1.

https://stardot.org.uk/forums/viewtopic.php?p=293279#p293279

[hoglet67]

It's likely this is by design.

Looking a the code to parse a drive number deliberately limits the drive to 0 or 1: https://github.com/hoglet67/MMFS/blob/master/MM32.asm#L1035

I think Martin envisaged the system to work more like physical disk drives, of which there are only two.

*DIN can be used with physical drives 0 or 1.

If you load a .ssd file to physical drive 0, then just drive 0 is populated.

If you load a .dsd file to physical drive 0, then drive 0 and 2 are populated

Really, *DIN to 2 or 3 should return an error, but in practive it silently maps 2->0 and 3->1.

Martin's original note eludes to this:

Instead it uses a FAT32 formatted card and offers the following commands
*DCAT (<filter>) shows the current DOS dir, filter allows '*' wildard, e.g. *.*sd
*DDIR (<dos dir>) changes the current DOS dir, or if no parameter goes to root
*DIN (<drive>) <dos file> loads image (drive = 0 or 1 only)
*DOUT (<drive>)
(*DBOOT to follow)
temp command *DDUMP dumps the contents of the current drive image.

Personally, I would prefer to also be able to load .SSD files to any of 0/1/2/3, but I can imagine issues, such as:

*DIN 0 <dsd disk>
*DIN 2 <ssd disk>

What happens to drive 0 now?

Dave

Dave

[SteveFosdick]

It gets complicated. So it looks like MMFS2 take the same approach as B-Em does with plain image files in that, as one can't "mix and match" the sides of a physical disc it doesn't allow you do so with images.

On the other hand B-Em supports MMB files too and this works as a kind of overlay. First, to explain, B-Em doesn't implement MMB by emulating an SD card and running MMFS or any of the other card filing systems, instead it uses the existing code for SSD/DSD and adds an offset for the selected image. B-Em implements the DIN and DABOUT commands and the file access is done by regular DFS.

So when an MMB file is opened, initially it loads image 0 into drive 0 (side 0). If an SSD or DSD was loaded into that drive previously, the image file is closed by the filename is remembered. *DIN does allow loading images from the MMB file into drives 2 and 4.

If the MMB file is "ejected" the non-MMB SSD/DSD images files, if any, are reloaded.

So what to do about loading SSDs into the 2nd side of a drive. If there is an SSD loaded for the first side then it seems reasonable to load another SSD for the 2nd side but then it gets more complicated.

If a DSD is already loaded in the drive and one tries to load an SSD into the 2nd side there are two choices:

1. Reject the attempt with an error.
2. Have the new SSD take priority over the 2nd side of the already loaded DSD.

Likewise there a similar choice when trying to load a DSD into the 2nd side:

1. Reject the attempt with an error.
2. Use the 1st side of the DSD (as the 2nd side in the drive).
3. Use the 2nd side of the DSD.

The other complicationI can see is that there is probably not that much space to do anything fancy.

[mincebert]

Thanks. I was wondering if the problem was down to DSDs when I thinking about it last night but haven't had time to check today. If it was a choice of one on the other — support DSDs as the only mechanism to have a drive 2/3, or only support SSDs — I think I'd pick the latter as I only ever use SSDs and you can always split a DSD into two SSDs; having two extra SSD drives seems much more beneficial to me (especially as the Library is on 3 — I like having that permanently accessible).

I suppose the simplest and least confusing situation, if it could accommodate both, would be to prohibit *DIN 2/3 if a DSD was loaded into 0/1. If a DSD is loaded as drive 2/3, maybe a warning would be enough.

I don't know what's possible: I amazed all this fits into 16KB already! I was trying to understand the code last night and got very confused! :)