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 » Sun Jan 07, 2018 11:27 am

mlouka wrote: Thinking about this more, that would give four new major variants so probably not a good idea after all...
Would you like to give MMFS 1.40 a try:
https://github.com/hoglet67/MMFS/releases

This uses the same file handle range as DFS, so should now work with Master Emulation ROM.

BTW, if you have both MMFS and DFS in the system, it's probably best to ensure one of them is *UNPLUGed.

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 » Sun Jan 07, 2018 6:36 pm

Thanks, will test.

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, ++

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

Re: MMFS Development and Support

Post by crj » Sun Jan 07, 2018 9:39 pm

Out of interest, is anybody aware of anything with a similar hard-coded dependency on ADFS?

Back in the day, my experience was that anything which could run from ADFS could also run from, say, NFS.

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

Re: MMFS Development and Support

Post by Coeus » Sun Jan 07, 2018 10:07 pm

hoglet wrote: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
That table looks very similar to the one used on a proper Master except than on the proper Master this table is built up dynamically by issuing ROM service call &25 whereby each filing system ROM returns one or more 11-byte entries with exactly this information.
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.

The table in MER would still need to be amended to add MMFS.
And it would be good to implement call &25 for the case where it is plugged into a real Master.

It is a bit of a co-incidence this has come up now as a few days ago we were discussing what a programmer could do to use the filing systems workspace but then re-select the filing system to load an overlay in the programming forum.

It does seem to me a filing system having its own number and range of handles along with a switchable ability to masquerade as another filing system, usually DFS, is ideal if you can do it. VDFS does indeed do this and I think JGH may have worked out somewhere to store the flag to say if the masquerading is currently on or off.

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:30 pm

Coeus wrote: VDFS does indeed do this and I think JGH may have worked out somewhere to store the flag to say if the masquerading is currently on or off.
In MMFS there already is a bit of state (bit 6) in the private workspace byte (stored in &DF0-&DFF) to this effect.

It's manipulated by *OPT 5,N, but all it current does is enable/disable responding to *DISK/*DISC.

I'm thinking this could be generalised to be enable DFS masquerading, which would include:
- responding to *DISK/*DISC
- using DFS's file system number (&04)
- using DFS's file handle range (&11-&15)
- using DFS's tube client identifier (&C1)

All the values above are currently hard coded constants. The challenge is making them dynamic, with as little code growth as possible.

Probably the default should be to enable masquerading.

Dave

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

Re: MMFS Development and Support

Post by crj » Sun Jan 07, 2018 10:50 pm

I'm also wondering about this for a project I'm working on. And I'm wondering how generic the mechanism would need to be.

I've got the strong suspicion that the only filing systems one really needs to emulate are DFS and Tape. I've never come across anything which depended on running from ADFS, for example, and only management tools which make no sense to run elsewhere ever cared about running from NFS.

Coincidentally, those are also the two which deviate significantly from the hierarchical filesystem model.

Catching *TAPE and/or OSBYTE 140 is a rather nastier proposition, alas, since the OS gets there first.

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

Re: MMFS Development and Support

Post by Coeus » Sun Jan 07, 2018 10:52 pm

hoglet wrote:I'm thinking this could be generalised to be enable DFS masquerading, which would include:
- responding to *DISK/*DISC
- using DFS's file system number (&04)
- using DFS's file handle range (&11-&15)
- using DFS's tube client identifier (&C1)
VDFS only does the first two of those. Not changing file handle range probably means VDFS won't work with the MER because of the hard-coded values in the MER's filing system table but I can't see that being much of an issue as VDFS is specifically for emulators and if you want a Master you'd select one and VDFS does respond to service call &25 to provide entries for the dynamic version of the table. I am not sure I know the effect of changing the tube client identifier.

But your suggestion seems good. Logically, MMHS should either pretend to be DFS or not. On is a good default. Anyone who doesn't like that can put MMFS in a lower priority slot. The one thing I would not bundle as part of that setting is the magic key on break to select the filing system.

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

Re: MMFS Development and Support

Post by crj » Sun Jan 07, 2018 11:00 pm

Coeus wrote:The one thing I would not bundle as part of that setting is the magic key on break to select the filing system.
Any particular reason why not? That would also be fine if you stuck your ROM in a lower-priority socket than DFS, and it seems curious to make an exception for it.

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

Re: MMFS Development and Support

Post by Coeus » Sun Jan 07, 2018 11:03 pm

crj wrote:I've got the strong suspicion that the only filing systems one really needs to emulate are DFS and Tape. I've never come across anything which depended on running from ADFS, for example, and only management tools which make no sense to run elsewhere ever cared about running from NFS.
I haven't either but then I have more experience of tinkering with the technology than actually using it. VDFS does masquerade as ADFS but, perhaps, it makes more sense there because VDFS is exposing (part of) the host filing system to be BBC and the host FS is also hierarchical so VDFS more nearly looks like ADFS than anything else. Perhaps JGH will be along to comment on his reasons.

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

Re: MMFS Development and Support

Post by Coeus » Sun Jan 07, 2018 11:06 pm

crj wrote:Any particular reason why not? That would also be fine if you stuck your ROM in a lower-priority socket than DFS, and it seems curious to make an exception for it.
i was thinking this would usually be a user action rather than something embedded in a game or the like so regardless of the setting of "masquerade as DFS" I would want to be able to do M-Break (assuming I remember that right - I have MMFS as the only filing system in my real BBC B so don't need it) for MMFS and D-Break for DFS.

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

Re: MMFS Development and Support

Post by Coeus » Mon Feb 05, 2018 8:22 pm

Is this a bug? In the code for the OSWORD calls there is this:

Code: Select all

.SERVICE08_unrec_OSWORD
{
	BP12K_NEST
	JSR RememberAXY

	LDY &EF				; Y = Osword call
	BMI exit			; Y > &7F
	CPY #&7D
	BCC exit			; Y < &7D

	JSR ReturnWithA0

	JSR FSisMMFS			; MMFS current fs?
	BNE exit
...
It looks like, if MMFS is not the current filing system but receives an OSWORD call in the range 7D-7F this will return to the OS with A=0 to say it has claimed the call but won't do anything, meaning that any other filing system of lower priority will not even see the call. Shouldn't it have the JSR ReturnWithA0 and the current filing system test the other way round, like this:

Code: Select all

	BP12K_NEST
	JSR RememberAXY

	LDY &EF				; Y = Osword call
	BMI exit			; Y > &7F
	CPY #&7D
	BCC exit			; Y < &7D

	JSR FSisMMFS			; MMFS current fs?
	BNE exit

	JSR ReturnWithA0

	LDX &F0				; Osword X reg
	STX &B0
...

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

Re: MMFS Development and Support

Post by hoglet » Mon Feb 05, 2018 8:43 pm

Coeus wrote:Is this a bug?
Yes, I think it probably is.

I've just created an issue:
https://github.com/hoglet67/MMFS/issues/8

Is this causing you an issue?

Dave

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

Re: MMFS Development and Support

Post by Coeus » Mon Feb 05, 2018 8:57 pm

hoglet wrote:
Coeus wrote:Is this a bug?
Yes, I think it probably is.

I've just created an issue:
https://github.com/hoglet67/MMFS/issues/8

Is this causing you an issue?

Dave
No, I was actually looking at that code because I wanted to try out JGH's HADFS filing system which piggy backs on other filing systems by using their sector I/O via OSWARD 7F, except that MMFS doesn't do OSWORD 7F if it is not the current filing system so I was looking to created a hacked version for my own purpose that just removes that check.

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

Re: MMFS Development and Support

Post by lurkio » Mon Apr 02, 2018 1:12 pm

I'm trying to get a TurboMMC- and Master-compatible version of the MMFS ROM to Chinny of the ChinnyVision channel on YouTube so that he can review Prince of Persia on his Master 128 with (I think) IFEL MultiOS.

Would anyone be up for blowing the T/MAMMFS (I think) version of MMFS to EPROM and sending it to him?

:?:

[Cross-posted here: viewtopic.php?f=57&t=14858&p=199586#p199586]

FelisSapien
Posts: 8
Joined: Sun Apr 15, 2018 4:17 pm
Location: UK
Contact:

Re: MMFS Development and Support

Post by FelisSapien » Wed Apr 25, 2018 7:32 am

Hi All, hoping someone can help me debug my situation... I'm entirely new to this (Acorn life) so the most likely issue is my process...

The short description is that *DCAT correctly lists the SSD images of the MMB file. I can *MMFS/*DISC to an image but if I then try to use the file system I get a 'Disc not formatted' error. The .mmb & .ssd files look to be okay when read with the mmb_utils commands.

Have tried a couple of cards (8GB and 16GB). Formatted with FAT and FAT32 from Linux, MacOS and Windows 10. The results are pretty consistent.

Have MMFS 1.36 ROM installed in my Model B. For now DFS has been removed. An SD card reader is connected to the USER port.

Any pointers on where to go next with this? I can provide more detail/info but am wary of flooding your thread with the obvious ramblings of an neophyte!

Many Thanks!

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 Apr 25, 2018 8:23 am

FelisSapien wrote: The short description is that *DCAT correctly lists the SSD images of the MMB file. I can *MMFS/*DISC to an image but if I then try to use the file system I get a 'Disc not formatted' error. The .mmb & .ssd files look to be okay when read with the mmb_utils commands.
This sounds quite an unusual issue.

You are using the *DIN command to "mount" an image?

What does the *DDRIVE command show before and after *DIN?

Dave

FelisSapien
Posts: 8
Joined: Sun Apr 15, 2018 4:17 pm
Location: UK
Contact:

Re: MMFS Development and Support

Post by FelisSapien » Wed Apr 25, 2018 9:39 am

Thanks Dave, outright stupidity looks to have been the problem... Somehow I'd become convinced that *MMFS or *DISC were the commands I needed to 'mount' a disk. It's amazing how quickly frustration can lead to narrow-sightedness.

Using *DIN is much more productive. Things are working as expected. I've also located the command reference.

Thanks!

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 Apr 25, 2018 9:45 am

No worries, glad it was that simple....

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

Re: MMFS Development and Support

Post by hoglet » Thu Jul 05, 2018 5:50 pm

Continued from here.
cmorley wrote: I found with MMFS there is some problems with the "Z" version of the MMFS ROM - the one that unpacks to SRAM.

It tramples the first SRAM it finds - regardless of if there is a ROM image in.
This is expected (if mildly annoying) as when the machine is powered up it's reasonable to expect all the SWRAM slots to be blank. But I guess adding a check would be straight forward, and I don't think the boot loader is tight for space.
cmorley wrote: It doesn't like to be in a lower priority slot than the SRAM - might crash on boot I can't quite remember.
This is not expected and sounds like a bug we should fix.
cmorley wrote: It doesn't play well with ADFS on init it seems. Crashes on boot if it is in a higer priority slot than ADFS IIRC - I can check again.
Yes, testing all the possible combinations of slot ordering is a bit of a nightmare.

As there are three ROMs to consider, I guess there are 6 possibilities:
- ZMMFS, SWRAM, ADFS
- ZMMFS, ADFS, SWRAM,
- SWRAM, ZMMFS, ADFS
- SWRAM, ADFS, ZMMFS
- ADFS, SWRAM, ZMMFS
- ADFS, ZMMFS, SWRAM

Combined with all the different BREAK types, it becomes a real pain.
cmorley wrote: Can't remember if I mentioned these to Dave or not. :?
No, I don't think you did, but thanks for doing so now. It's always good to get bug reports - it's the main way that things like this progress.

Dave

cmorley
Posts: 671
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: MMFS Development and Support

Post by cmorley » Thu Jul 05, 2018 6:22 pm

hoglet wrote:
Thu Jul 05, 2018 5:50 pm
cmorley wrote: I found with MMFS there is some problems with the "Z" version of the MMFS ROM - the one that unpacks to SRAM.
It tramples the first SRAM it finds - regardless of if there is a ROM image in.
This is expected (if mildly annoying) as when the machine is powered up it's reasonable to expect all the SWRAM slots to be blank. But I guess adding a check would be straight forward, and I don't think the boot loader is tight for space.
I found this out because I wanted to load the SRAM ADFS in a higher priority RAM bank. I had a quick look at the loader too.
hoglet wrote:
cmorley wrote: It doesn't like to be in a lower priority slot than the SRAM - might crash on boot I can't quite remember.
This is not expected and sounds like a bug we should fix.
IIRC it hangs on boot with a "comparison failed" or similar message.
hoglet wrote:
cmorley wrote: It doesn't play well with ADFS on init it seems. Crashes on boot if it is in a higer priority slot than ADFS IIRC - I can check again.
Yes, testing all the possible combinations of slot ordering is a bit of a nightmare.

As there are three ROMs to consider, I guess there are 6 possibilities:
- ZMMFS, SWRAM, ADFS...

Combined with all the different BREAK types, it becomes a real pain.
It was just ADFS and ZMMFS that was the problem because the other bug means ZMMFS>SRAM always. ADFS was 1.30. The SRAM MMFS if loaded manually works fine so it does seem to be the boot loader not MMFS itself.

I will check again and report back the exact order which hangs the machine on boot... flashing cursor before BBC banner.

I'll try a bit later tonight or tomorrow, document & post.

cmorley
Posts: 671
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: MMFS Development and Support

Post by cmorley » Thu Jul 05, 2018 7:16 pm

OK... I did some testing and here is what I think goes on.

If the boot loader<highest SRAM then the machine crashes on boot. Nothing you can do.

If the boot loader>(any?) filesystem then PAGE is wrong when BASIC loads. Sometimes UP sometimes DOWN depending on the exact order of ROMs. This causes grief as the workspaces are trampled by BASIC I assume & overlap . It isn't just ADFS I think... DFS 1.2 in the mix causes a problem too.

It seems like something isn't correct with the workspaces... perhaps returning the wrong value to the OS on init - so it works if last but messes things up if not last.

I have been testing on a real machine.

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

Re: MMFS Development and Support

Post by hoglet » Thu Jul 05, 2018 7:54 pm

Thanks for that Chris. I'll have a think about this over the weekend.

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 » Fri Jul 06, 2018 12:36 pm

Hi Chris,

I've fixed the issue where the system crashes/hangs if the SWRAM slot > Boot Loader slot.

I've also added checks to make sure the SWRAM slot is free before using it.

You can find these fixes in MMFS 1.41:
https://github.com/hoglet67/MMFS/releases
cmorley wrote:
Thu Jul 05, 2018 7:16 pm
If the boot loader>(any?) filesystem then PAGE is wrong when BASIC loads. Sometimes UP sometimes DOWN depending on the exact order of ROMs. This causes grief as the workspaces are trampled by BASIC I assume & overlap . It isn't just ADFS I think... DFS 1.2 in the mix causes a problem too.
I'm struggling to reproduce this.

For example, the following configuration seems to work fine:

Code: Select all

Rom 15: Basic
Rom 14: Empty
Rom 13: Ram (used by ZMMFS to load SWMMFS)
Rom 12: ZMMFS Bootstrap
Rom 11: Empty
Rom 10: Empty
Rom  9: Acorn ADFS 1.33 (the IDE version)
Rom  8: Empty
...
Rom  0: Empty
Page ends up at &1D00 which is the expected value and you can switch between MMFS and ADFS with no issues.

Could you possibly re-test with version 1.41?

The only issue I have encountered with version 1.41 is down to the self-write protection implemented by my RAM/ROM board, which prevents certain ROMS writing to themselves. I have one of Steve Picton's newer ROM/ROM boards that plugs into the 6502 socket. This "feature" is well documented in the manual, and affects 4 of the 8 RAM slots.

Dave
Last edited by hoglet on Fri Jul 06, 2018 12:38 pm, edited 2 times in total.

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

Re: MMFS Development and Support

Post by hoglet » Fri Jul 06, 2018 12:55 pm

On reflection, it is possible that the first of the above changes fixed the incorrect PAGE issue as well:
https://github.com/hoglet67/MMFS/commit ... df2da2eaf1

The bug would cause all ROMs between the ZMMFS boot loader and the SWRAM bank it uses to miss the "Absolute work claim" service call.

So if you had ZMMFS > ADFS > SWRAM, ADFS would miss the "Absolute work claim" service call.

This would result in PAGE being lower than expected, and ADFS would mess up.

I can't see how PAGE could end up higher than expected though.

Dave

cmorley
Posts: 671
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: MMFS Development and Support

Post by cmorley » Fri Jul 06, 2018 1:24 pm

1.41 seems to have fixed everything.

I can confirm that:
ZMMFS (1.41)<SRAM works
ZMMFS (1.41)>other filesystems works (no more crazy PAGE numbers)

I retried 1.40 and I can repeat crazy PAGE.

Code: Select all

15:BASIC
14,13:empty
12:ZMMFS140
11:DFS1.2
10-8:empty
7:EXMON2
6:empty
5:SRAM (MMFS)
4:empty
3:ADT2.00
2:empty
1:SRAM
0:empty
Gives me PAGE=&1200 on power up but it should be &1900 with DFS.

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

Re: MMFS Development and Support

Post by hoglet » Fri Jul 06, 2018 1:50 pm

That's great Chris, thanks.

User avatar
geraldholdsworth
Posts: 404
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: MMFS Development and Support

Post by geraldholdsworth » Fri Nov 02, 2018 8:56 pm

Hi all,

OK, finally got my internal IFEL dual userport installed, into the Econet connector, connected up the TurboMMC and then reprogrammed the MOS so that MMFS 1.41 is in place of ViewSheet (ROM 10, IIRC) - I'm also using a Retroclinic DualOS, so I just purchased another flash 2Mbit ROM, copied the original code off Mark's, overlaid it with the two ROMs I'd find more useful (i.e. MMFS and BASIC Editor) then programmed onto the new Flash ROM.

So, the new MOS works. MMFS 1.41 is there and can be selected. I used MAMMFS3 as this used FEA0 as the user port base address (which is what is required of the internal user port), but when I do a *DCAT I just get 'Card?'. So obviously the MMFS ROM is not talking to the internal userport.

Any ideas, or should I rebuild the MMFS after manually changing the userport base address to FEA0 in top_MAMMFS.asm and then use MAMMFS.rom?

Is there anyway of checking what the user port base address is on a particular built ROM? (or by looking at the log file)

At the moment, I've had to *UNPLUG the MMFS in the MOS, replug the TurboMMC into the external port, and insert the old MMFS ROM in (which is on an EPROM on a cartridge...can't remember the version of this though), which works fine...except I get 'Bad sum?' sometimes when I press BREAK.

Cheers,

Gerald.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

User avatar
geraldholdsworth
Posts: 404
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: MMFS Development and Support

Post by geraldholdsworth » Fri Nov 02, 2018 9:24 pm

Oh you silly bu**er...you know what I've done, don't you? Only gone and used the M/MAMMFS3 image and not the T/MAMMFS3 image!!!
D'OH!
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

User avatar
geraldholdsworth
Posts: 404
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: MMFS Development and Support

Post by geraldholdsworth » Sat Nov 03, 2018 9:14 pm

geraldholdsworth wrote:
Fri Nov 02, 2018 8:56 pm
except I get 'Bad sum?' sometimes when I press BREAK.
I am now able to repeat this problem:

Now I've got the correct ROM into the MOS ROM, as ROM number 10, and with the older version in the cartridge removed - if I type *UNPLUG 10, then press BREAK (or CTRL BREAK) I get the 'Bad sum?' error as the only thing on the screen, followed by the '*' prompt. If I press BREAK or CTRL-BREAK it still reports 'Bad sum?'. However, if I do a *FX200,2 and then do a CTRL-BREAK it works fine.
The same is then true if I do a *INSERT 10 followed by a BREAK or CTRL-BREAK.

This only happens with the MMFS ROM.

There are a few posts in this 'ere forum on Bad Sum errors, including one about the MMFS saying that it is it's workspace corrupted - but I can't see it being with this particular issue.

On the plus side, I won't be *UNPLUGging and *INSERTing the ROM very often...I hope!
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

Post Reply