MMFS Development and Support

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

MMFS Development and Support

Postby hoglet » Sun Jan 17, 2016 9:08 pm

Hi Guys,

MMFS is one of several ROMs that allow modern SD Cards to be used on a Beeb with minimal external hardware (others include the original SuperMMC, Steve Picton's TurboMMC and Duikkie's SmartSPI). MMFS was written by Martin Mather in 2012, but seems to have been forgotten about until it was rediscovered in 2015.

MMFS has the following features:
- it's built from simple text source files (BeebASM), rather than patching existing binaries with BBC Basic programs
- it's derived from DFS 2.x rather than DFS 0.9
- the Master and Beeb/Electron SWRAM versions result in PAGE at &E00
- it preserves the current drive on BREAK
- it now supports FAT32 (upto 8GB) as well as FAT16
- I'm motivated to fix any bugs that people find!

MMFS now has it's own github repository.
https://github.com/hoglet67/MMFS/commits/master

I''ve improved the build script, so it builds the following versions:
- Beeb ROM (MMFS)
- Beeb Sideways RAM (SWMMFS)
- Electron ROM (EMMFS)
- Electron Sideways RAM (ESWMMFS)
- Master (MAMMFS)
adds them to a .ssd file, and finally zips everything into a single release file.

Here's the current release (1.36):
https://github.com/hoglet67/MMFS/releases

For an explanation of the release structure, see:
https://github.com/hoglet67/MMFS/wiki/Release-structure

Other threads mentioning MMFS:

The DFS ROM source code thread, where Martin M published the initial version of MMFS.

The BeebFpga thread, where bug fix releases 1.01-1.07 were made.

The TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address thread, where version 1.08 fixed some OSWORD 7F Tube bugs.

The MMC Card Interface thread, where MMFS. SmartSPI and earlier ROMs are compared.

Please use this thread for feature requests and bug reports.

I'll publish new releases here as well.

Dave
Last edited by hoglet on Tue Apr 25, 2017 9:16 pm, edited 6 times in total.

PhilYoung
Posts: 192
Joined: Sun Jun 12, 2011 4:55 pm

Re: MMFS Development and Support

Postby PhilYoung » Sun Jan 17, 2016 10:16 pm

Hi,

how about adding a quick note listing the intended MMC/SD card to user port connections to help making up a cable - maybe a schematic would be useful as well ? Presumably the target is one of those 99p 'ebay' boards with the level shifters ?

Also, I gather that the IFEL Turbo MMC ROM has some sort of incompatability with Econet but I've not been able to discover in what way exactly. Does the MMFS version have the same problem ?

Thanks for all your work on this (and everything else)

Cheers,

Phil Young

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

Re: MMFS Development and Support

Postby hoglet » Sun Jan 17, 2016 10:40 pm

PhilYoung wrote:how about adding a quick note listing the intended MMC/SD card to user port connections to help making up a cable - maybe a schematic would be useful as well ? Presumably the target is one of those 99p 'ebay' boards with the level shifters ?

It's the same connections as the original, as detailed here:
http://swhs.home.xs4all.nl/bbc/mmbeeb/#mmchardware

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

Re: MMFS Development and Support

Postby hoglet » Sun Jan 17, 2016 10:44 pm

PhilYoung wrote:Also, I gather that the IFEL Turbo MMC ROM has some sort of incompatability with Econet but I've not been able to discover in what way exactly. Does the MMFS version have the same problem ?

Anyone know any more about this problem?

Dave

User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: MMFS Development and Support

Postby sweh » Sun Jan 17, 2016 11:10 pm

hoglet wrote:
PhilYoung wrote:Also, I gather that the IFEL Turbo MMC ROM has some sort of incompatability with Econet but I've not been able to discover in what way exactly. Does the MMFS version have the same problem ?

Anyone know any more about this problem?

I have two Model Bs (issue 4, issue 7) and a Master 128 all with TurboMMC all working with Econet just fine. (The other Master has a Retroclinic CF adapter and no MMC, and acts as the fileserver)
Rgds
Stephen

PhilYoung
Posts: 192
Joined: Sun Jun 12, 2011 4:55 pm

Re: MMFS Development and Support

Postby PhilYoung » Mon Jan 18, 2016 7:44 am

hoglet wrote:
PhilYoung wrote:how about adding a quick note listing the intended MMC/SD card to user port connections to help making up a cable - maybe a schematic would be useful as well ? Presumably the target is one of those 99p 'ebay' boards with the level shifters ?

It's the same connections as the original, as detailed here:
http://swhs.home.xs4all.nl/bbc/mmbeeb/#mmchardware


Thanks,

Cheers,

Phil Young

PhilYoung
Posts: 192
Joined: Sun Jun 12, 2011 4:55 pm

Re: MMFS Development and Support

Postby PhilYoung » Mon Jan 18, 2016 7:46 am

hoglet wrote:
PhilYoung wrote:Also, I gather that the IFEL Turbo MMC ROM has some sort of incompatability with Econet but I've not been able to discover in what way exactly. Does the MMFS version have the same problem ?

Anyone know any more about this problem?

Dave


I'll see if I can find the reference, it was on here somewhere.....

Cheers,

Phil Young

User avatar
DutchAcorn
Posts: 1631
Joined: Fri Mar 21, 2014 9:56 am
Location: Maarn, Netherlands

Re: MMFS Development and Support

Postby DutchAcorn » Mon Jan 18, 2016 8:43 am

PhilYoung wrote:
hoglet wrote:
PhilYoung wrote:Also, I gather that the IFEL Turbo MMC ROM has some sort of incompatability with Econet but I've not been able to discover in what way exactly. Does the MMFS version have the same problem ?

Anyone know any more about this problem?

Dave


I'll see if I can find the reference, it was on here somewhere.....

Cheers,

Phil Young

It was discussed here. Stephen mentioned he got it to work, I could not. Duikkie changed Smart SPI to make it work with Econet. See discussion here.

MMFS works fine with Econet.

I have a tape-only Econet fitted model B, I will try to find some time this week to see if this one works with Econet and Turbo MMC.

Stephen did get this combo to work so it may need a little more digging.
Paul

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

Re: MMFS Development and Support

Postby hoglet » Mon Jan 18, 2016 9:19 am

Current release (1.08) added to the first post of this thread.

Dave

PhilYoung
Posts: 192
Joined: Sun Jun 12, 2011 4:55 pm

Re: MMFS Development and Support

Postby PhilYoung » Mon Jan 18, 2016 10:27 am

DutchAcorn wrote:
PhilYoung wrote:
hoglet wrote:Anyone know any more about this problem?

Dave


I'll see if I can find the reference, it was on here somewhere.....

Cheers,

Phil Young

It was discussed here. Stephen mentioned he got it to work, I could not. Duikkie changed Smart SPI to make it work with Econet. See discussion here.

MMFS works fine with Econet.

I have a tape-only Econet fitted model B, I will try to find some time this week to see if this one works with Econet and Turbo MMC.

Stephen did get this combo to work so it may need a little more digging.


Thanks for that, it's reassuring that I didn't imagine it. The problem is also mentioned a couple of times, for instance here:

http://stardot.org.uk/forums/viewtopic.php?f=26&t=8512&start=60#p92915

and earlier here:

http://stardot.org.uk/forums/viewtopic.php?t=6277#p60248 which I think was the thread I was thinking of in the first place.

But since you say Hoglets recent MMFS works correctly with an Econet equipped system, then it's probably a moot point,

Cheers,

Phil Young

User avatar
TheCorfiot
Posts: 648
Joined: Mon Jan 08, 2007 5:22 pm

Re: MMFS Development and Support

Postby TheCorfiot » Mon Jan 18, 2016 4:30 pm

Will MMFS work with Steve Pictons Turbo MMC hardware ?

thx :)

User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: MMFS Development and Support

Postby sweh » Mon Jan 18, 2016 4:32 pm

TheCorfiot wrote:Will MMFS work with Steve Pictons Turbo MMC hardware ?

Not at the moment, but cross-thread there are discussions on how it might be made to work with it.
Rgds
Stephen

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

Re: MMFS Development and Support

Postby hoglet » Mon Jan 18, 2016 5:58 pm

Stephen,

Would you be up for testing a version of MMFS that *might* be compatible with TurboMMC?

All it does is set PB[4:2] as outputs with values 010, which according to Duikkie's schematic should be all that's needed.

I haven't been able to test this as I don't have any TurboMMC hardware, so caveat emptor, and please don't try it on an SD Card containing any valuable data.

Here's the "highly experimental" ZIP:
mmfs_1_09_20160118_1744.zip
Edit: Deleted at it contains bugs that might cause output conflicts.

Anyone else, probably best stay away from this build for now. You have been warned!!! :shock:

Dave
Last edited by hoglet on Tue Jan 19, 2016 7:58 am, edited 1 time in total.

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

Re: MMFS Development and Support

Postby duikkie » Mon Jan 18, 2016 6:05 pm

look at the source of j.3-drv first , it is not only open the outputs. because there is output and input on the same line
so you can blow-up your via. therefor the buffer enables and disable with data in the program



hoglet wrote:Stephen,

Would you be up for testing a version of MMFS that *might* be compatible with TurboMMC?

All it does is set PB[4:2] as outputs with values 010, which according to Duikkie's schematic should be all that's needed.

I haven't been able to test this as I don't have any TurboMMC hardware, so caveat emptor, and please don't try it on an SD Card containing any valuable data.

Here's the "highly experimental" ZIP:
mmfs_1_09_20160118_1744.zip

Anyone else, probably best stay away from this build for now. You have been warned!!! :shock:

Dave

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

Re: MMFS Development and Support

Postby hoglet » Mon Jan 18, 2016 6:11 pm

duikkie wrote:look at the source of j.3-drv first , it is not only open the outputs. because there is output and input on the same line
so you can blow-up your via. therefor the buffer enables and disable with data in the program

Do you mean two outputs on the same line?

Is it PB1 and CB1, or something else?

I think even the original MMBEEB implementation connects PB1 and CB1, which with mis-programming could both be outputs.
viewtopic.php?f=3&t=1919&start=540#p129317

Dave

User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: MMFS Development and Support

Postby sweh » Mon Jan 18, 2016 6:21 pm

hoglet wrote:Would you be up for testing a version of MMFS that *might* be compatible with TurboMMC?

Ah, I love my UPURSFS code, it made this easy to test. Just unzip the file into the right tree then *UPURSFS followed by *SRLOAD MMFS 8000 F Q and it loads :-) I also *UNPLUG'd the TurboMMC ROM so your ROM was the only one that was trying to talk the card.

And it _seems_ to work. With the MMB file I'd created for the CPM tests I was able to *DCAT, *DIN 0 100 (an image that had the test program on), load and save files to that image. It worked with the copro on/off. I tested with MMFS and SWMMFS.

One oddity noted (that probably isn't TurboMMC related). SWMMFS on initial load gives "Bad sum" error; needs control-break to properly initialise. Then it worked.

I also tested SWMMFS with the Z80 copro. Pressing control-break didn't cause CPM to load properly. I got corrupted output and dropped to the * prompt. However from there I could run *CPM and it loaded fine, and inside CPM I could DIR and run BBCBASIC without issues. It's not clear to me why the first control-break failed; nothing showed up the indicate.
Rgds
Stephen

User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: MMFS Development and Support

Postby sweh » Mon Jan 18, 2016 6:23 pm

Side note: subjectively MMFS felt _slower_ than TurboMMC; eg the initial "*." after control-break seemed to take a fraction longer, and *DCAT definitely took longer to complete.
Rgds
Stephen

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

Re: MMFS Development and Support

Postby duikkie » Mon Jan 18, 2016 6:23 pm

look at the schema :
if you enable 4 and 3 at the same time your dout of your sd card is connected to your din.
edit:

if cb2 is output and pb0 is allso out , it is not good if all buffers are open( enabled)


hoglet wrote:
duikkie wrote:look at the source of j.3-drv first , it is not only open the outputs. because there is output and input on the same line
so you can blow-up your via. therefor the buffer enables and disable with data in the program

Do you mean two outputs on the same line?

Is it PB1 and CB1, or something else?

I think even the original MMBEEB implementation connects PB1 and CB1, which with mis-programming could both be outputs.
viewtopic.php?f=3&t=1919&start=540#p129317

Dave
Last edited by duikkie on Mon Jan 18, 2016 6:27 pm, edited 1 time in total.

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

Re: MMFS Development and Support

Postby hoglet » Mon Jan 18, 2016 6:27 pm

sweh wrote:
hoglet wrote:Would you be up for testing a version of MMFS that *might* be compatible with TurboMMC?

Ah, I love my UPURSFS code, it made this easy to test. Just unzip the file into the right tree then *UPURSFS followed by *SRLOAD MMFS 8000 F Q and it loads :-) I also *UNPLUG'd the TurboMMC ROM so your ROM was the only one that was trying to talk the card.

And it _seems_ to work. With the MMB file I'd created for the CPM tests I was able to *DCAT, *DIN 0 100 (an image that had the test program on), load and save files to that image. It worked with the copro on/off. I tested with MMFS and SWMMFS.

Excellent, and slightly surprising.

How much slower is it than TurboMMC?
sweh wrote:One oddity noted (that probably isn't TurboMMC related). SWMMFS on initial load gives "Bad sum" error; needs control-break to properly initialise. Then it worked.

I've seen that error before. I thought I had fixed it:
https://github.com/hoglet67/MMFS/commit ... e648403aeb

sweh wrote:I also tested SWMMFS with the Z80 copro. Pressing control-break didn't cause CPM to load properly. I got corrupted output and dropped to the * prompt. However from there I could run *CPM and it loaded fine, and inside CPM I could DIR and run BBCBASIC without issues. It's not clear to me why the first control-break failed; nothing showed up the indicate.

Control-break will reset the drive mappings. Are your CPM images on DIN 0/2?

Dave

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

Re: MMFS Development and Support

Postby duikkie » Mon Jan 18, 2016 6:30 pm

look at page 409/410 in the big book , how fast or slow SRMODE 0 is and SRMODE2 and SRMODE 6

User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: MMFS Development and Support

Postby sweh » Mon Jan 18, 2016 6:37 pm

hoglet wrote:How much slower is it than TurboMMC?

Unscientific test...

Code: Select all

10TIME=0
20*SAVE TST 1000+7000
30PRINT TIME

TurboMMC: 78. MMFS: 381

So a LOT slower.
sweh wrote:I also tested SWMMFS with the Z80 copro. Pressing control-break didn't cause CPM to load properly. I got corrupted output and dropped to the * prompt. However from there I could run *CPM and it loaded fine, and inside CPM I could DIR and run BBCBASIC without issues. It's not clear to me why the first control-break failed; nothing showed up the indicate.

Control-break will reset the drive mappings. Are your CPM images on DIN 0/2?

Yes, 0 and 2. I did a bit more testing and I think it may be another initialisation issue...

control-break gives an error. At the * prompt I did *CPM and it hung. Repeated this 3 times. Then instead I did "*." followed by '*CPM" and it worked. So I wonder if calling OS7F before any "traditional" data transfer isn't initialising some data properly somewhere.
Rgds
Stephen

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

Re: MMFS Development and Support

Postby hoglet » Mon Jan 18, 2016 6:41 pm

duikkie wrote:look at the schema :
if you enable 4 and 3 at the same time your dout of your sd card is connected to your din.

I'm not enabling PB3 and PB4 at the same time.

All MMFS is doing is making sure that at all times:
- PB2 = 0
- PB3 = 1
- PB4 = 0

The result being that things are connected exactly as they would for the original MMBEEB hardware.
duikkie wrote:edit:
if cb2 is output and pb0 is allso out , it is not good if all buffers are open( enabled)

In MMFS, CB2 is never set as an output, so I think we are safe.

Dave

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

Re: MMFS Development and Support

Postby hoglet » Mon Jan 18, 2016 6:48 pm

sweh wrote:
hoglet wrote:How much slower is it than TurboMMC?

Unscientific test...

Code: Select all

10TIME=0
20*SAVE TST 1000+7000
30PRINT TIME

TurboMMC: 78. MMFS: 381

So a LOT slower.

Interesting, and not unexpected, as there is ~6 instructions per bit.

MMFS for the none TurboMMC is slightly faster (271).

Could you do a similar test for LOADing?
sweh wrote:Yes, 0 and 2. I did a bit more testing and I think it may be another initialisation issue...

control-break gives an error. At the * prompt I did *CPM and it hung. Repeated this 3 times. Then instead I did "*." followed by '*CPM" and it worked. So I wonder if calling OS7F before any "traditional" data transfer isn't initialising some data properly somewhere.

Ah, that's very interesting. I'll see if I can reproduce.

Dave
Last edited by hoglet on Mon Jan 18, 2016 6:52 pm, edited 1 time in total.

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

Re: MMFS Development and Support

Postby hoglet » Mon Jan 18, 2016 6:51 pm

duikkie wrote:look at page 409/410 in the big book , how fast or slow SRMODE 0 is and SRMODE2 and SRMODE 6

Yes, I see the difference. Thanks.

My initial target was just getting it working in the same way the original MMBEEB worked. i.e. no Turbo mode.

Dave

User avatar
sweh
Posts: 1847
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: MMFS Development and Support

Postby sweh » Mon Jan 18, 2016 6:56 pm

hoglet wrote:Could you do a similar test for LOADing?

(write protection enabled on the SWR bank)

Code: Select all

TIME=0:OSCLI "LOAD TST 2000":CLS:PRINT TIME

TuboMMC 67 vs MMFS 204
Rgds
Stephen

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

Re: MMFS Development and Support

Postby duikkie » Mon Jan 18, 2016 6:59 pm

if you do it right you can read as fast as turbo can read :) , SMART spi is a little slower because it calculates every time with pb lines to use not standaard pb0/pb1.

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

Re: MMFS Development and Support

Postby hoglet » Mon Jan 18, 2016 7:03 pm

duikkie wrote:if you do it right you can read as fast as turbo can read :) , SMART spi is a little slower because it calculates every time with pb lines to use not standaard pb0/pb1.

But only with TurboMMC hardware, right?

I'll need to try to get hold of a TurboMMC board I think.

Dave

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

Re: MMFS Development and Support

Postby duikkie » Mon Jan 18, 2016 7:11 pm

no no :) , you don't need a turboboard (hardware) , i am not sure anymore but SRMODE2 is allso possible without a TURBO board. , that why SMART spi is fast in reading.
the only thing you need to do is use SRMODE2 to read, but you can't lose the hole SRMODE0 , it is all there in the source of smart spi (j.3-drv) , was a puzzle when to use SRMODE 0 /SRmode 2 and SRMODE 6 , you have to check if buffer is there then you can use SRMODE6 .

hoglet wrote:
duikkie wrote:if you do it right you can read as fast as turbo can read :) , SMART spi is a little slower because it calculates every time with pb lines to use not standaard pb0/pb1.

But only with TurboMMC hardware, right?

I'll need to try to get hold of a TurboMMC board I think.

Dave

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

Re: MMFS Development and Support

Postby duikkie » Mon Jan 18, 2016 7:16 pm

look at 3-drv and learn dutch :D

viewtopic.php?f=2&t=9913

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

Re: MMFS Development and Support

Postby hoglet » Mon Jan 18, 2016 7:20 pm

duikkie wrote:no no :) , you don't need a turboboard (hardware) , i am not sure anymore but SRMODE2 is allso possible without a TURBO board. , that why SMART spi is fast in reading.
the only thing you need to do is use SRMODE2 to read, but you can't lose the hole SRMODE0 , it is all there in the source of smart spi (j.3-drv) , was a puzzle when to use SRMODE 0 /SRmode 2 and SRMODE 6 , you have to check if buffer is there then you can use SRMODE6 .

OK, I agree now that all current hardware should be able to use SRMODE2 for "turbo" reading.

So the only benefit of the TurboMMC hardware is being able to use SRMODE6 for "turbo" writing, by reconfiguring the buffers.

So I think I'll have a play with SRMODE2 tomorrow. I'll also try to do it without learning dutch!

Thanks!

Dave


Return to “hardware”

Who is online

Users browsing this forum: cmorley and 10 guests