MMFS Version 2

[mm67]

For fun I've been working on a new version of MMFS which does away with the MMB file.

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.

A very early version is attached (i've disabled writing):

[Superseded : attachment removed]

It works such that I can load games, but I have a list of improvements I want to make, plus I need to 'IF' out all the redundant code and tidy up.

All based on hoglet's much improved MMFS, mods to which I've tried to keep to a minimum.

Not having a real beeb anymore, it's only been tested on beebem. Therefore it would be useful to know if it works on real hardware!

[danielj]

This is a very welcome update! I look forward to seeing how it plays with real hardware

d.

[hoglet]

Very interesing work Martin.

It's pretty exciting to see a full FAT32 implementation in 6502 assembler.

Did you have to chop much out to make it fit?

(I'm guessing the PAGE=&E00 SWRAM versions aren't going to have enough space for this)

Dave

[mm67]

Hi Dave,

Well, when all the code for the MMB file is gone (well ifed out), there will hopefully be plenty of room.

[lurkio]

For fun I've been working on a new version of MMFS which does away with the MMB file.

Instead it uses a FAT32 formatted card ...

Very interesting!

[myelin]

Excellent!

[duikkie]

this is what i was thinking about with my project userdos and tubedos rom
maybe my idea of the names to use

*dcat i want it to name it *dosdir
*ddir i want it to name it *doscd
*din i want it to name it *dosload

my roms are a little diffent then the mmfs roms
so maybe the mmfs ver.2 will beat the userdos rom

why only fat32 ??

smart-spi <.....> mmfs
mmfsv2 <....> userdos ???

for now i have not the time

For fun I've been working on a new version of MMFS which does away with the MMB file.

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.

A very early version is attached (i've disabled writing):

build.zip

It works such that I can load games, but I have a list of improvements I want to make, plus I need to 'IF' out all the redundant code and tidy up.

All based on hoglet's much improved MMFS, mods to which I've tried to keep to a minimum.

Not having a real beeb anymore, it's only been tested on beebem. Therefore it would be useful to know if it works on real hardware!

[Coeus]

why only fat32 ??

Do you mean why only the 32bit version of FAT? Or is there some other filing system you want to see? ExFAT, maybe? I think it unlikely that someone would need to use an SD card big enough that it needs to be formatted as ExFAT with a BBC micro.

Although I believe there is a proprietary ROM to allow the BBC Micro to use a FAT filing system as a native filing system so BBC files can be ready individually with ease from a PC that isn't how FAT is used with the original MMFS or what is proposed here. As far as I can tell the existing MMFS only works with a FAT formatted partition on the SD card because that is what SD cards have been formatted with historically and because WIndows doesn't make it easy to access raw partitions.

I think mm67's idea is to make the disc images that would otherwise be inside an MMB file, FAT files in their own right. This makes it easier to replace one of the SSDs on the card as one then only has to copy the SSD file onto the card which can be done from Windows or any other OS that works with SD cards without the need for a special program that can maintain an MMB file. It also means that the code within MMFS that is specific to the MMB file format can go.

[duikkie]

there are FAT and FAT32 and others but most of them use FAT or FAT32 , mmfs and SMART-SPI can detect now FAT and fat32, so why del. the FAT detection ?

i understand what mm67 whants to do , it is the same i want with USERDOS and TUBEDOS , i only don't have the time to make the softwarerom

the names DOSCD,DOSDIR,and DOSLOAD , is to make a different name
els you get people who are using DIN in the mmfs/smart-spi , and allso in the dos version. that will not work fine

alldo i have difficult understand how mmfs are made ( c++ based ?) i use the martin .... option

i allso know you have to loss a lot of stuff in the mmfs calc for MMB file to make the dos version

*doscd= because the command in DOS to change directorie is cd ( cd c:\main\ssdfiles)
*dosdir= because the command in dos too list directorie is dir ( dir c:\main or dir *.* or dir .. )
*dosload= because to load normal thing to do in dos is type in ( programmes with *.exe or *.bat )

*dossave is not possible because you only have 4 kilobytes for a bbcrom. you save a file in your *dosload game.ssd file

why only fat32 ??

Do you mean why only the 32bit version of FAT? Or is there some other filing system you want to see? ExFAT, maybe? I think it unlikely that someone would need to use an SD card big enough that it needs to be formatted as ExFAT with a BBC micro.

Although I believe there is a proprietary ROM to allow the BBC Micro to use a FAT filing system as a native filing system so BBC files can be ready individually with ease from a PC that isn't how FAT is used with the original MMFS or what is proposed here. As far as I can tell the existing MMFS only works with a FAT formatted partition on the SD card because that is what SD cards have been formatted with historically and because WIndows doesn't make it easy to access raw partitions.

I think mm67's idea is to make the disc images that would otherwise be inside an MMB file, FAT files in their own right. This makes it easier to replace one of the SSDs on the card as one then only has to copy the SSD file onto the card which can be done from Windows or any other OS that works with SD cards without the need for a special program that can maintain an MMB file. It also means that the code within MMFS that is specific to the MMB file format can go.

[geraldholdsworth]

I think that this is a fantastic idea. I never saw the point of the MMB file anyway.

*dossave is not possible because you only have 4 kilobytes for a bbcrom. you save a file in your *dosload game.ssd file

What if you wanted to create a new disc image on the SD card, on the BBC side, and then copy data from a real disc?

Cheers,

Gerald.

[Coeus]

there are FAT and FAT32 and others but most of them use FAT or FAT32 , mmfs and SMART-SPI can detect now FAT and fat32, so why del. the FAT detection ?

Ok, so this refers to the variations where the number of bits in the file allocation table is different. I think I have seen 12, 16 and 32 and there is an 8-bit version that pre-dates MS-DOS. I assume what you are calling FAT is actually FAT16?

the names DOSCD,DOSDIR,and DOSLOAD , is to make a different name
else you get people who are using DIN in the mmfs/smart-spi , and allso in the dos version. that will not work fine

That would make it possible to have more than one ROM that provides DFS-like access to an SD installed at the same time but I wonder how many people want to do that? On the other hand the *DIN and *DABOUT commands have been built into a nice games menu that people like so there is an advantage to being compatible.

alldo i have difficult understand how mmfs are made ( c++ based ?) i use the martin .... option

If you're referring to the Hoglet version of MMFS, the assembler BeebAsm is written in C++ but there are pre-built versions of that for Windows and Linux so you don't need a C++ compiler. The rest of the build automation is a bash script. This works natively on Linux and I assume Hoglet has in mind that the Windows GIT implementation includes bash so presumably that is sufficient to run it on Windows.

[duikkie]

yes fat =fat16
i don't understand why people use *rom commando's in there games menu ? if one you can change *din in *dosload
but never use *rom commando's , i have seen this with utilsroms or basicedit rom , if someone do not have this roms , program blocks , allso if you use real disc. oke programmer standpoint

i am old even windows is new stuff , give me 6502,8088 and i am happy , all other languane is too high for me
event basic is a high languane , i ones did a program in c++ terible simple instuctions of a simple man

there are FAT and FAT32 and others but most of them use FAT or FAT32 , mmfs and SMART-SPI can detect now FAT and fat32, so why del. the FAT detection ?

Ok, so this refers to the variations where the number of bits in the file allocation table is different. I think I have seen 12, 16 and 32 and there is an 8-bit version that pre-dates MS-DOS. I assume what you are calling FAT is actually FAT16?

the names DOSCD,DOSDIR,and DOSLOAD , is to make a different name
else you get people who are using DIN in the mmfs/smart-spi , and allso in the dos version. that will not work fine

That would make it possible to have more than one ROM that provides DFS-like access to an SD installed at the same time but I wonder how many people want to do that? On the other hand the *DIN and *DABOUT commands have been built into a nice games menu that people like so there is an advantage to being compatible.

alldo i have difficult understand how mmfs are made ( c++ based ?) i use the martin .... option

If you're referring to the Hoglet version of MMFS, the assembler BeebAsm is written in C++ but there are pre-built versions of that for Windows and Linux so you don't need a C++ compiler. The rest of the build automation is a bash script. This works natively on Linux and I assume Hoglet has in mind that the Windows GIT implementation includes bash so presumably that is sufficient to run it on Windows.

[DutchAcorn]

This is an excellent improvement!

Combining this with Ultra DFS would make it even more extremely useful.

What if you wanted to create a new disc image on the SD card, on the BBC side, and then copy data from a real disc?

Yes, that.

[Coeus]

Combining this with Ultra DFS would make it even more extremely useful.

As long as that doesn't remove the ability to use the Turbo hardware.

BTW, that thread mentions the disappearance of SRAM utilities. I don't know if the official Acorn utils will fit but I was able to get sideways RAM utilities into the spare space in the Exmon II ROM using the usual trick of daisy chaining the service calls.

[mm67]

Finished this a month ago and have been meaning to do some checks to make sure it compiles exactly the same as Dave's (hoglet) version before posting (that is when the switch _MM32_ = FALSE).

This I have finally done - plus I've updated it to version 1.44.

Here it is:

Builds:

MMFS2_Build_20190923.zip

(559.5 KiB) Downloaded 58 times

Source:

MMFS2_Source_20190923.zip

(50.26 KiB) Downloaded 44 times

Notes (some quick ones):

MMFS2_Notes.txt

(2.65 KiB) Downloaded 80 times

New version of mmbeeb.dll (for BeebEm) which deals with images > 2GB:

mmbeebXL.zip

(22.06 KiB) Downloaded 73 times

(I will post the source when I find it.)

Not done much testing, but Elite seems to run ok.

[KenLowe]

Nice one .

Will be testing this out tonight.

[KenLowe]

Just done a quick test with User Port version of SWMMFS installed into RAM bank 4. When trying to load Elite, I get a 'Not Allowed' error when I try to LOAD"MENU". Using the standard MMFS version works fine.

Edit: I like the way that *DIN file.dsd loads to both drives 0/2 and DIN 1 file.dsd loads to both drives 1/3. So *DBOOT lancelot.dsd starts up and runs perfectly without having to worry about loading two single sided .ssd files.

[Ramtop]

No time to really test today, but trying to load Jet Set Willy and Elite on my Electron with an ElkSD64 I also get the 'not allowed' error using the ESWMMFS. The 'Haven' menu program crashes on both the SW and non-SW versions.

Have to say, though, I really like dealing with individual disk images. It's a lot less cumbersome than having to use the beeb.mmb file.

[mm67]

I think I was trying to be too clever by getting it to check if the load address was >=&10000.

Of course host addresses should be &FFFFxxxx so always producing the error.

Difficult to check on beebem, so although I've fixed it I haven't tested it (SW ram versions only attached):

buildz.zip

(194.16 KiB) Downloaded 48 times

Don't know what the Haven menu is.

Also, in the notes I put BOOT.SSD, this should be BOOT.DSD.

[KenLowe]

Thank you. I'll re-test again this evening and report back.

[KenLowe]

I think I was trying to be too clever by getting it to check if the load address was >=&10000.

Of course host addresses should be &FFFFxxxx so always producing the error.

Difficult to check on beebem, so although I've fixed it I haven't tested it (SW ram versions only attached)

Just done a quick test with Elite, and that's working now. Will test more thoroughly later.

[Bobbi]

Hi folks,

Someone on here pointed me to the MMFS2 fork that allows one to access individual SSD files and DSD files on an SD card, rather than having to pack them all into an .MMB file. I have been experimenting with it and I was sufficiently happy with it that I have switched over to it full time.

For the record, the MMFS2 fork is discussed here: viewtopic.php?f=2&t=17559&p=248927

I used @sweh's MMB-Utils tools to extract all of the disk images from the MMB file with all the games (I use the one with @tricky's launcher). I created files without extensions (ie: 1, 2, 3 not 1.SSD, 2.SSD, 3.SSD) and put them all in a directory. Because MMFS2's *DIN command just takes a file name, commands like *DIN 100 still work, and this allows the games menu to work too!

Right now it seems to work perfectly and I can't see any downside. I can create different directories of disk images and use the *DDIR command to switch between them. This is far easier to manage than the .MMB file. I pulled out my MMFS EPROM completely and I am using MMFS2 for everything now.

I am using the ZMMFS version of MMFS2, which installs into sideways RAM automatically on startup, leaving PAGE at &0E0. What's not to like?

One question I have ... The thread above seemed to go dead and I don't see more recent posts from @mm67. Is anyone maintaining this MMFS2 fork which uses FAT32 directly? If not I may stick it on GitHub and try to look after it, since I am going to be running it on my own system from now on.

All the best,
Bobbi

[Ramtop]

I don't think it's been updated at all since then. I implemented MMFS2 as an option on my original ElkSD-Plus 1 catridge since I'm not much of a fan of the beeb.mmb file approach, but it seemed to just die so I got cold feet and went back to the standard build of MMFS for rev 2 of the cartidge.

[hoglet]

Is anyone maintaining this MMFS2 fork which uses FAT32 directly?

I'm not aware of anyone actively working on this.

It might be worth contacting Martin and see if he has privately developed it any further.

Dave

[Bobbi]

It seems worth the effort to keep this alive, especially seeing as it basically works as-is. (Maybe a few rough edges though!)

I will message Martin.

[sydney]

Martin has not logged into stardot for over a year so a pm might not reach him.

[Bobbi]

Does anyone have another way to reach him?

[roland]

Try the PM anyway. He might get an email to notify him that there is a private message.

[Bobbi]

Yep, I did already. I was thinking the same. I hope he is okay!

[JasonStonier]

Is anyone maintaining this MMFS2 fork which uses FAT32 directly?

I'm not aware of anyone actively working on this.

It might be worth contacting Martin and see if he has privately developed it any further.

Dave

Would there be a reason you couldn't port this into yours, Dave? Seems like it would be a nice cross-over option, making the SD systems more like Gotek, and be something like mimicking a harddrive for dirt cheap. And of course, it would be nice for those of us with your P/ version

[edited]