MMFS Development and Support

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
hoglet
Posts: 7600
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Tue Nov 14, 2017 10:08 pm

KenLowe wrote:I'm running SWMMFS in one of my SWRAM banks and generally it works very well. However, I've noticed that immediately after a BREAK, the *FREE command doesn't work. If I do a *CAT first, it then works. Is this a problem with my setup, or can others replicate this?
What version are you running? I'll try to replicate this tomorrow.

Dave

User avatar
KenLowe
Posts: 378
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: MMFS Development and Support

Post by KenLowe » Tue Nov 14, 2017 11:08 pm

hoglet wrote:What version are you running? I'll try to replicate this tomorrow.
Sorry, should have mentioned that in my initial post. I'm running the model B, sideways ram version V1.36

User avatar
hoglet
Posts: 7600
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Wed Nov 15, 2017 10:12 am

KenLowe wrote: Sorry, should have mentioned that in my initial post. I'm running the model B, sideways ram version V1.36
Hmm, I've tried and haven't been able to replicate this.

Which probably just means there is some small but significant difference between your setup and mine.

Could you possibly post a screen shot or two showing what actually happens, starting from powering on the machine?

Could you also do a *HELP so I can see the ROMs you have?

Does *MAP give the same error?

Dave

User avatar
KenLowe
Posts: 378
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: MMFS Development and Support

Post by KenLowe » Wed Nov 15, 2017 7:08 pm

Thanks for the feedback.

I have a bunch of other ROMs installed, so I disabled all the non essentials, and MMFS started working fine. I was then able to narrow it down to Master ROM (Beebug) which I have temporarily installed in one of the sockets. It turns out this ROM also processes the FREE and MAP commands. The Master ROM was higher priority than SWMMFS, so I guess the FREE and MAP commands were being grabbed by the Master ROM and never getting to MMFS.

Although less relevant now, to answer your other questions - with Master ROM installed and enabled, *FREE causes the machine to hang and *MAP causes the machine to continuously print the free map after power up / reboot, unless I do a *CAT first. It looks like the Master ROM can process the FREE and MAP commands, as long as the drive catalogue has previously been loaded to RAM.

User avatar
mlouka
Posts: 53
Joined: Wed Sep 27, 2017 3:57 pm
Location: Halden, Norway
Contact:

Re: MMFS Development and Support

Post by mlouka » Wed Dec 13, 2017 6:11 pm

MMFS works great on my Master 128 with TurboMMC hardware, and Tube Elite runs as expected using an internal 2nd processor (PiTubeDirect, so emulated 6502). So, a couple of days ago I burnt the BBC Model B variant of MMFS to replace the TurboMMC ROM in my Beeb. It seems to work just as well as the Master variant except for one thing -- it won't run Tube Elite. Loading the game hangs after displaying the loading screen (with the Saturn-like planet). I am using a real 6502 2nd processor (although not Acorn's) in this case. If I swap MMFS back out with TurboMMC then Tube Elite runs fine so this appears to be related to the Beeb variant of MMFS rather than an issue with the disk image or the second processor itself. At the moment there are no expansion boards installed in the beeb -- just MMFS, HIBASIC and the "BOS" ROM required by the PMS B2P-6502 2nd processor (in addition the usual OS 1.2 and BASIC ROMs, of course). I took the DFS ROM out in order to test HIBASIC with the 2nd processor. Both Master and Beeb copies of MMFS are the 1.36 release variants for TurboMMC hardware. Unfortunately, although I have an external PiTubeDirect, I don't have a suitable cable for it on hand so cannot test to see if that works (implying a conflict with MMFS and the BOS ROM). I also don't have a non-TurboMMC card reader yet so cannot check if this is only an issue with the "MMFS for Model B with TurboMMC" hardware variant (since the Master variant for the same hardware works).
BBC Master 128, BBC Model B i7, Watford Electronics Solderless Sideways ROM board, PMS B2P-6502 2nd proc., PiTubeDirect (both internal and external), RetroClinic Multi-OS Selector, Sundby 256k RAM/ROM card, MMFS, ++

User avatar
hoglet
Posts: 7600
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Wed Dec 13, 2017 6:48 pm

This is a bit weird, as Tube Elite is my most used test program!

Can you post the .ssd image of Tube Elite that you are actually using.

User avatar
mlouka
Posts: 53
Joined: Wed Sep 27, 2017 3:57 pm
Location: Halden, Norway
Contact:

Re: MMFS Development and Support

Post by mlouka » Wed Dec 13, 2017 8:03 pm

hoglet wrote:This is a bit weird, as Tube Elite is my most used test program!

Can you post the .ssd image of Tube Elite that you are actually using.
Thanks for the quick reply.

I guess I could but it is jut the DIN45 one in the typical beeb.mmb installs. I have tried the one that came on the MMC card with TurboMMC as well as then Higgy posted on stardom a few months ago on SD card, which appear to be based on the same image from STH.

I've done a bit more testing, to compare what happens when loading other games with the second processor enabled using the TurboMMC ROM and the MMFS ROM and I think I can confirm that this is related to the combination of the MMFS and the second processor -- presumably because this particular processor is a little unconventional in how it works with the TUBE in that it does some stuff in software (hence the need for the BOS ROM) that would normally have been done in hardware (this processor was a relatively cheap alternative to Acorn's). If I turn off the processor off (with the BOS ROM still installed, as the ROM enables the processor to be turned on and off via commands on the ROM) then MMFS works fine so this only appears to be a problem when the second processor is operating. With other games I typically just got junk on the screen when loading with MMFS and the 2nd processor on so it is weird that Tube Elite actually displays a correct loading screen. Not a big deal for me since the PiTubeDirect is faster so I will mostly use that in future with the Beeb (and I guess that that will work fine with MMFS), but still curious that TurboMMC works correctly so MMFS might be assuming something about the TUBE incorrectly? I don't think I'll have time this evening but will give SmartSPI a go too and see how that goes since that would be better than TurboMMC if it works, and if it doesn't work then that might be interesting too...
BBC Master 128, BBC Model B i7, Watford Electronics Solderless Sideways ROM board, PMS B2P-6502 2nd proc., PiTubeDirect (both internal and external), RetroClinic Multi-OS Selector, Sundby 256k RAM/ROM card, MMFS, ++

User avatar
BigEd
Posts: 2140
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: MMFS Development and Support

Post by BigEd » Wed Dec 13, 2017 8:08 pm

Does this second processor connect to the Beeb's Tube connector, or to some other port? Does it have a Tube chip in it? It sounds like it doesn't.

User avatar
hoglet
Posts: 7600
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Wed Dec 13, 2017 8:17 pm

Is this the second processor?
http://chrisacorns.computinghistory.org ... S_B2P.html

Is yours also running at just 2MHz?

I wonder if that's the issue.. When the filesystem transfers data over the tube, timing is done by dead reckoning. The spec says no faster than 10us per byte. I recently fixed an issue where MMFS was going a tad faster than this. This didn't seem to be causing a problem. But it's possible that's what is happening here, with your system running more slowly.

The fix was this:
https://github.com/hoglet67/MMFS/commit ... ef804a7277

It's included in 1.38 and 1.39. Neither of these have been published yet.

So let me add a build of 1.39 to github and you can see if that helps.

Dave
Last edited by hoglet on Wed Dec 13, 2017 8:39 pm, edited 1 time in total.

User avatar
mlouka
Posts: 53
Joined: Wed Sep 27, 2017 3:57 pm
Location: Halden, Norway
Contact:

Re: MMFS Development and Support

Post by mlouka » Wed Dec 13, 2017 8:31 pm

Yes, that is correct.

Will certainly try 1.39 when you make it available.

Thanks,
MIchael.
hoglet wrote:Is this the second processor?
http://chrisacorns.computinghistory.org ... S_B2P.html

Is yours also running at just 2MHz?

I wonder if that's the issue.. When the filesystem transfers data over the tube, timing is done by dead reckoning. The spec says no faster than 10us per byte. I recently fixed an issue where MMFS was going a tad faster than this. This didn't seem to be causing a problem. But it's possible that's what is happening here, with your system running more slowly.

The fix was this:
https://github.com/hoglet67/MMFS/commit ... ef804a7277

It's included in 1.37, 1.38 and 1.39. None of these have been published yet.

So let me add a build of 1.39 to github and you can see if that helps.

Dave
BBC Master 128, BBC Model B i7, Watford Electronics Solderless Sideways ROM board, PMS B2P-6502 2nd proc., PiTubeDirect (both internal and external), RetroClinic Multi-OS Selector, Sundby 256k RAM/ROM card, MMFS, ++

User avatar
mlouka
Posts: 53
Joined: Wed Sep 27, 2017 3:57 pm
Location: Halden, Norway
Contact:

Re: MMFS Development and Support

Post by mlouka » Wed Dec 13, 2017 8:32 pm

BigEd wrote:Does this second processor connect to the Beeb's Tube connector, or to some other port? Does it have a Tube chip in it? It sounds like it doesn't.
Tube, but it doesn't have the Tube chip in it -- emulates it in software.
BBC Master 128, BBC Model B i7, Watford Electronics Solderless Sideways ROM board, PMS B2P-6502 2nd proc., PiTubeDirect (both internal and external), RetroClinic Multi-OS Selector, Sundby 256k RAM/ROM card, MMFS, ++

User avatar
CMcDougall
Posts: 6304
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

Re: MMFS Development and Support

Post by CMcDougall » Wed Dec 13, 2017 8:34 pm

^Tube code already in the MMFS rom/s 8)

mine works fine, but I use the MatchBox Pro (all mHz speeds), in a beeb (the M128s are only good for electron keyswitches!)
& the 33p MMC card interface.

also, try using this .SSD Elite Executive version in your beeb.mmc file, linky below:
viewtopic.php?f=2&t=8325&p=99929&hilit= ... ive#p99929
ImageImageImage

User avatar
hoglet
Posts: 7600
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Wed Dec 13, 2017 8:37 pm

mlouka wrote: Will certainly try 1.39 when you make it available.
Here you go...
https://github.com/hoglet67/MMFS/releases

User avatar
Pernod
Posts: 1317
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK
Contact:

Re: MMFS Development and Support

Post by Pernod » Wed Dec 13, 2017 8:42 pm

mlouka wrote:
BigEd wrote:Does this second processor connect to the Beeb's Tube connector, or to some other port? Does it have a Tube chip in it? It sounds like it doesn't.
Tube, but it doesn't have the Tube chip in it -- emulates it in software.
Oooh, you have a B2P! Would you be able to dump the BOS ROM and post in my request post at viewtopic.php?f=7&t=13555 ?
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
mlouka
Posts: 53
Joined: Wed Sep 27, 2017 3:57 pm
Location: Halden, Norway
Contact:

Re: MMFS Development and Support

Post by mlouka » Wed Dec 13, 2017 8:56 pm

Brilliant! It worked !!!

Thanks,
Michael.
hoglet wrote:
mlouka wrote: Will certainly try 1.39 when you make it available.
Here you go...
https://github.com/hoglet67/MMFS/releases
BBC Master 128, BBC Model B i7, Watford Electronics Solderless Sideways ROM board, PMS B2P-6502 2nd proc., PiTubeDirect (both internal and external), RetroClinic Multi-OS Selector, Sundby 256k RAM/ROM card, MMFS, ++

User avatar
mlouka
Posts: 53
Joined: Wed Sep 27, 2017 3:57 pm
Location: Halden, Norway
Contact:

Re: MMFS Development and Support

Post by mlouka » Wed Dec 13, 2017 8:57 pm

Will do.

Michael.
Pernod wrote:
mlouka wrote:
BigEd wrote:Does this second processor connect to the Beeb's Tube connector, or to some other port? Does it have a Tube chip in it? It sounds like it doesn't.
Tube, but it doesn't have the Tube chip in it -- emulates it in software.
Oooh, you have a B2P! Would you be able to dump the BOS ROM and post in my request post at viewtopic.php?f=7&t=13555 ?
BBC Master 128, BBC Model B i7, Watford Electronics Solderless Sideways ROM board, PMS B2P-6502 2nd proc., PiTubeDirect (both internal and external), RetroClinic Multi-OS Selector, Sundby 256k RAM/ROM card, MMFS, ++

User avatar
hoglet
Posts: 7600
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Wed Dec 13, 2017 9:00 pm

mlouka wrote:Brilliant! It worked !!!

Thanks,
Michael.
Excellent.... (and Phew!)

Dave

User avatar
mlouka
Posts: 53
Joined: Wed Sep 27, 2017 3:57 pm
Location: Halden, Norway
Contact:

Re: MMFS Development and Support

Post by mlouka » Sat Jan 06, 2018 2:41 pm

Not sure if this is by design or accident, but the Master Emulator ROM and MMFS do not work as expected when MMFS is the active file system. The emulated MOS commands that use the DFS, such as SRLOAD, give ""Bad filing system name" with MMFS.' On the same beeb, TurboMMC and a "real" DFS work OK with MER so this appears to be MMFS-specific. See http://www.stardot.org.uk/forums/viewto ... =7&t=14320 for potentially useful additional information.
BBC Master 128, BBC Model B i7, Watford Electronics Solderless Sideways ROM board, PMS B2P-6502 2nd proc., PiTubeDirect (both internal and external), RetroClinic Multi-OS Selector, Sundby 256k RAM/ROM card, MMFS, ++

User avatar
hoglet
Posts: 7600
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Sat Jan 06, 2018 2:44 pm

mlouka wrote:Not sure if this is by design or accident, but the Master Emulator ROM and MMFS do not work as expected when MMFS is the active file system. The emulated MOS commands that use the DFS, such as SRLOAD, give ""Bad filing system name" with MMFS.' On the same beeb, TurboMMC and a "real" DFS work OK with MER so this appears to be MMFS-specific. See http://www.stardot.org.uk/forums/viewto ... =7&t=14320 for potentially useful additional information.
I'm always happy to look into possible MMFS incompatibilities.

Can you post a screen shot showing an example command and the exact error please?

Also can you list the ROMs you have in your Beeb, and the slots they are in.

Dave

User avatar
mlouka
Posts: 53
Joined: Wed Sep 27, 2017 3:57 pm
Location: Halden, Norway
Contact:

Re: MMFS Development and Support

Post by mlouka » Sat Jan 06, 2018 4:14 pm

hoglet wrote:
Can you post a screen shot showing an example command and the exact error please?

Also can you list the ROMs you have in your Beeb, and the slots they are in.
Thanks, Dave. Am currently out of the house but will check a little when I get home and see if I can reproduce it in BeebEm. When attempting to load a romfile into a spare RAM slot using SRLOAD, the exact error message was “Bad filing system name”. Entering *disc or disk (with MMFS active) first made no difference. Physically taking out the Watford DFS rom also had no effect. From memory, I tested with 15:BASIC, 14: MMFS (T), 13: Watford DFS, 12 to 8 set to «unplugged» (these slots are in EEPROM), 7: Master Emulator (SWRAM). My slots 0 to 7 are SWRAM. I «unplugged» MMFS and loaded TurboMMC info a RAM slot while testing and found that with File config set to 13 (DFS) or 6 (TurboMMC) then loading a rom from file using SRLOAD worked from real disk or an mmc card, but with MMFS as the enabled FS then the same command gave the Bad filing system error message. Same with both v1 and v2 of the Master Emulator ROM.
BBC Master 128, BBC Model B i7, Watford Electronics Solderless Sideways ROM board, PMS B2P-6502 2nd proc., PiTubeDirect (both internal and external), RetroClinic Multi-OS Selector, Sundby 256k RAM/ROM card, MMFS, ++

User avatar
hoglet
Posts: 7600
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Sat Jan 06, 2018 5:52 pm

mlouka wrote: Thanks, Dave. Am currently out of the house but will check a little when I get home and see if I can reproduce it in BeebEm.
I've managed to set up a system that reproduces the MER "Bad filing system name" issue, and I'm just looking in to it.

More later...

User avatar
hoglet
Posts: 7600
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Sat Jan 06, 2018 6:46 pm

Here's a trace of SRLOAD going wrong with a few comments (##):
mer_trace.zip
(36.28 KiB) Downloaded 12 times
(It was captured using Myelin's FX2 adapter board hanging off the Tube and using my 6502 decoder.)

MER intercepts OSCLI and tests for its commands first, which includes SRLOAD.

When SRLOAD is executed, the MER uses the current file system and successfully opens the file with OSFIND, then starts reading it with OSGBPB.

It's the first call to OSGBPB that fails. It looks like MER is trying to implement a file switch layer, like the master does. So the call to OSGBPB is intercepted by MER, which tests whether the right file system is selected for the file handle.

To do this it has a table of:
- *COMMAND to initialize file system (padded with spaces)
- lower bound of file handle from this file system
- upper bound of file handle from this file system
- file system number

Here's the actual table:

Code: Select all

000022d0: d0d2 a9ff 8dff 0960 6b63 6f6c 4343 4653  .......`kcolCCFS
000022e0: 2020 2020 2001 0201 5441 5045 2020 2020       ...TAPE    
000022f0: 0102 0152 4f4d 2020 2020 2003 0303 4449  ...ROM     ...DI
00002300: 5343 2020 2020 1115 0444 4953 4b20 2020  SC    ...DISK   
00002310: 2011 1504 4e45 5420 2020 2020 202f 0541   ...NET      /.A
00002320: 4446 5320 2020 2030 3908 5646 5320 2020  DFS    09.VFS   
00002330: 2020 5059 0a00 ade6 098d e709 60a9 8fa2    PY........`...
In its file switch implementation, MER uses the above table to try to identify the current file system, based on the value of the open handle.

If there is a match, it proceeds to compare the file system number in the table with what it thinks is the current file system. If they don't match, it issues a service call A=12 to select what it thinks should be the filesystem.

MMFS currently issues file handles in the range &51-&55, and unfortunately this matches the entry for VFS in the table (&50-&59)

So where it's breaking is that MER tries to select VDFS, which doesn't exist.

I can think of two ways to fix this:
a) Patch the table in MER to add MMFS in place of VDFS
b) Make MMFS use the same range of file handles as DFS (&11-&15)

I've just tried (b) and SRLOAD no longer fails.

Anyone you any thoughts on whether (b) is a bad thing?

MMFS and DFS already share the same file system number (&04) meaning they don't nicely coexist. This is done for compatibility with quite a few games that will only run on DFS (file system number &04). So my feeling is this won't break anything that's not already broken.

Dave

User avatar
hoglet
Posts: 7600
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Sat Jan 06, 2018 7:09 pm

I am starting to wonder if MMFS should have it's own file system number and handle range:
http://mdfs.net/Docs/Comp/BBC/Filing/FSNums
http://mdfs.net/Docs/Comp/BBC/Filing/Handles

This would allow it to co-exist with DFS, and in the Master (or a B with MER) files could be copied between the two.

The table in MER would still need to be amended to add MMFS.

Does anyone have any actual examples of games that would become incompatible if we did this?

Dave

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

Re: MMFS Development and Support

Post by jgharston » Sat Jan 06, 2018 8:30 pm

hoglet wrote:I can think of two ways to fix this:
...
b) Make MMFS use the same range of file handles as DFS (&11-&15)
Doing that will break it as trying to use file handle &11 will cause DFS to be called. The correct solution is to ensure MMFS uses its own unique set of handles. You need five handles, I'd suggest 91-95 (&5B-&5F).

Code: Select all

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

User avatar
hoglet
Posts: 7600
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Sat Jan 06, 2018 8:40 pm

jgharston wrote:
hoglet wrote:I can think of two ways to fix this:
...
b) Make MMFS use the same range of file handles as DFS (&11-&15)
Doing that will break it as trying to use file handle &11 will cause DFS to be called. The correct solution is to ensure MMFS uses its own unique set of handles. You need five handles, I'd suggest 91-95 (&5B-&5F).
Actually it won't be any more broken that it currently is.

MMFS (like many other SD file systems) tries to "be" DFS, by:
- using file system number 4
- responding to *DISK and *DISC (as well as *MMFS)

TurboMMC and SmartSPI also use file handles &11-&15

They are designed to replace DFS, with the goal of maximising compatibility with DFS disk image, some of which do bad things like select file system number 4.

If we give MMFS its own file system number (and handle range), we will break several games, which will generate more support requests. I'm not sure I want to go there....

Maybe it's possible to have the best of both worlds (see FSCLAIM in VDFS, which I think you wrote...)

Dave

P.S. And doing this would not fix the MER issue, due to the hard coded file system handle table.
Last edited by hoglet on Sat Jan 06, 2018 9:02 pm, edited 1 time in total.

User avatar
mlouka
Posts: 53
Joined: Wed Sep 27, 2017 3:57 pm
Location: Halden, Norway
Contact:

Re: MMFS Development and Support

Post by mlouka » Sat Jan 06, 2018 8:47 pm

hoglet wrote:I am starting to wonder if MMFS should have it's own file system number and handle range:
http://mdfs.net/Docs/Comp/BBC/Filing/FSNums
http://mdfs.net/Docs/Comp/BBC/Filing/Handles

This would allow it to co-exist with DFS, and in the Master (or a B with MER) files could be copied between the two.
Could an "own file system variant" be implemented as a build-variant of MMFS like your E, M, T, U variants? In theory, it would be really useful for file management and archiving work even if some games break when booting from it. The "DFS emulating" version could still be used for playing those games anyway. I understand the concern about that potentially leading to more support requests if people mix them up though...

Thanks,
Michael.
BBC Master 128, BBC Model B i7, Watford Electronics Solderless Sideways ROM board, PMS B2P-6502 2nd proc., PiTubeDirect (both internal and external), RetroClinic Multi-OS Selector, Sundby 256k RAM/ROM card, MMFS, ++

User avatar
mlouka
Posts: 53
Joined: Wed Sep 27, 2017 3:57 pm
Location: Halden, Norway
Contact:

Re: MMFS Development and Support

Post by mlouka » Sat Jan 06, 2018 8:50 pm

mlouka wrote: Could an "own file system variant" be implemented as a build-variant of MMFS like your E, M, T, U variants? In theory, it would be really useful for file management and archiving work even if some games break when booting from it. The "DFS emulating" version could still be used for playing those games anyway. I understand the concern about that potentially leading to more support requests if people mix them up though...
Thinking about this more, that would give four new major variants so probably not a good idea after all...

Michael.
BBC Master 128, BBC Model B i7, Watford Electronics Solderless Sideways ROM board, PMS B2P-6502 2nd proc., PiTubeDirect (both internal and external), RetroClinic Multi-OS Selector, Sundby 256k RAM/ROM card, MMFS, ++

User avatar
hoglet
Posts: 7600
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Sat Jan 06, 2018 8:54 pm

It would certainly be possible, but already many new users already manage to pick the wrong version.

It would be nice to have a definitive list of games that would break.

duikkie
Posts: 2887
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: MMFS Development and Support

Post by duikkie » Sun Jan 07, 2018 7:40 am

elite . is looking for filesystem 4
hoglet wrote:It would certainly be possible, but already many new users already manage to pick the wrong version.

It would be nice to have a definitive list of games that would break.

User avatar
hoglet
Posts: 7600
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Sun Jan 07, 2018 10:50 am

duikkie wrote:elite . is looking for filesystem 4
Thanks for that Duikkie. I've just tested this, and you are right.

If I change MMFS's file system number to a unique one, Elite no longer works.

There are probably many other tape-disk conversions that work in the same way.

Dave

Post Reply