MMFS Development and Support

[CMcDougall]

2) *DFS seems to switch to the installed Solidisk 2.2M Issue 2 DFS and *. then catalogues the Floppy Dtive.
3) *CARD seems to hang. Should this be *MMFS?use the COP114 Utility with MMFS

As said before , put Solidisk in nearest bin

It should be *DISC when MMFS is current FS

COP114 is utter rubbish, it needs SWRAM to work, on the MMFS .ssd two files called DTOMC & MTOD (if I mind rightly)basic progs))do all that for you!!

[Ramtop]

With SRAM, how are you generating the OE and WE signals?

The SRAM setup is a bit complicated, it connects to the FPGA rather than the 6502 as it needs to be accessed by several different devices.

The 6502 interface in the FPGA pulls data from different sources - SRAM, BRAM, UFM - as required. I'm taking PHI0 from the expansion port and delaying it slightly (20ns I think, would need to check on that) to mimic PHI2. Reads and writes are gated to the pseudo PHI2, so the FPGA stays mum when the clock is low.

I suspect I'm messing something up here, just enough to cause greif, but finding it is proving to be miserably frustrating.

On the bright side, I'm using this as an opportunity to refine my memory test code until it can detect this annoying problem.

[Wheel_nut]

2) *DFS seems to switch to the installed Solidisk 2.2M Issue 2 DFS and *. then catalogues the Floppy Dtive.
3) *CARD seems to hang. Should this be *MMFS?use the COP114 Utility with MMFS

As said before , put Solidisk in nearest bin

It should be *DISC when MMFS is current FS

COP114 is utter rubbish, it needs SWRAM to work, on the MMFS .ssd two files called DTOMC & MTOD (if I mind rightly)basic progs))do all that for you!!

Why the downer on the Solidisk DFS2.2M2??? I have a 1770 Controller on one Beeb and an 8271 in the other and the Solidisk DFS 2.2M2 correctly identifies each and works with both. What do you suggest for each controller if I bin the Solidisk?

If MMFS is the current FS, I don't need to switch to it. It is after switching to the DFS using *DFS that I need to switch back to MMFS. What is the correct command for this?

OK, I see the IDTOM and IMTOD programs on the MMFS SSD. What is the correct syntax and attributes to execute these? e.g. CHAIN "IMTOD" 0 $.filename ? Does it allow wildcards e.g. CHAIN "IMTOD" 0 *.ROM* ?

[Coeus]

If MMFS is the current FS, I don't need to switch to it. It is after switching to the DFS using *DFS that I need to switch back to MMFS. What is the correct command for this?

*MMFS

[sweh]

Remember that the Z variants try to "automatically" load in SWR. If you're dealing with Solidisk and MMFS then you could just load the SWR version of MMFS (no Z) into SWRam.

Solidisk DFS even makes it easy (eg *LOAD filename B8000 will load into SWR block B).

In my case I converted all my Solidisk disks into SSD images, and then literally took out all the ROMs and upgrade kit, so only MMFS remained

[sweh]

Why the downer on the Solidisk DFS2.2M2???

Chris hates Solidisk (and a few other things) with a vengeance. He'll take every opportunity to knock them.

[sweh]

Dunno if it helps, but this is the code I wrote to image Solidisk disks. It'd handle single and double density disks and create "part files". On Unix you could then just "cat" the files together to create the original image. I did it this way 'cos a Solidisk double density image was 360K, which was too big for SSD!

[Elminster]

Why the downer on the Solidisk DFS2.2M2???

Chris hates Solidisk (and a few other things) with a vengeance. He'll take every opportunity to knock them.

E.g. Anything that isn't an Electron

[Wheel_nut]

Thank you Coeus, Sweh (Stephen) and Elminster, I shall disappear into my cave and play with MMFS ... I may be some time!

p.s. I fully understand CMcDougall's fervour. We in Scotland have no equivalent word for "ambivalence".

[Ramtop]

I've seen some very subtle / specific bugs that were caused by violated these rules.

It turns out you were spot on, Dave. I enabled writing to the FPGA's block RAM and sideways MMFS runs perfectly from there, so the villain of the piece is indeed my handling of the SRAM.

p.s. I fully understand CMcDougall's fervour. We in Scotland have no equivalent word for "ambivalence".

It's not something we're famous for, no

[Wheel_nut]

OK, I just had a bit of a (Data) disaster! I was trying to use IMTOD to add a few files from a SD Card Disc to a Floppy Disc and ended up overwriting the Floppy Disc with the SD Card Disc!

CMcDougall, Does IMTOD not facilitate the copying of individual files? MTOD on the COP114 allows single files, multiple filespec with wildcards and whole Discs. Not exactly "utter rubbish"

[CMcDougall]

Why the downer on the Solidisk DFS2.2M2???

Chris hates Solidisk (and a few other things) with a vengeance. He'll take every opportunity to knock them.

It's not Chris , stepven

All Solidisk disc controller cards are rubbish, been through them all (as said previously they work for first game, then say bad disc, when nothing wrong!), hence why MarkH /RetroClinic bins them all too as utter complete waste of time

[CMcDougall]

COP114 allows single files, multiple filespec with wildcards and whole Discs. Not exactly "utter rubbish"

It is rubbish, talk to people who tried to use it
You should go back to basics doing Tape to Disc, but doing Disc to MMFS & vice versa , so you get the hang of single files, the IMTOM is far quicker than doing 31 files individual ly

[Wheel_nut]

COP114 allows single files, multiple filespec with wildcards and whole Discs. Not exactly "utter rubbish"

It is rubbish, talk to people who tried to use it
You should go back to basics doing Tape to Disc, but doing Disc to MMFS & vice versa , so you get the hang of single files, the IMTOM is far quicker than doing 31 files individual ly

This is a futile discussion! I am able to use the COP114 utilities to copy Individual Files, Groups of Files and whole Discs from and to the SD Card when using the TurboSPI ROM from Steve Picton that it came with. I just had a (Data loss) disaster with IMTOD which overwrote my Floppy Disk with the SD Card disc when all I wanted was to copy a single file from the SD Card to the Floppy.

So can I ask for some factual answers from anybody who has experience of this situation:

I am using SWMMFS in ROM Bank 15.

1) Can IMTOD and IDTOM be used to copy INDIVIDUAL FILES? If so, HOW?
2) How do I Format a previously unused Disc location on the SD Card? There is no DFORM as on the TurboSPI.
3) Accepting your view that IMTOD is better, does the COP114 Utility work with MMFS? If so, are there any gotchas?
4) I am happy to read any documentation. Can anybody give me a pointer to where I can find this please.

Robin

[CMcDougall]

1) Can IMTOD and IDTOM be used to copy INDIVIDUAL FILES? If so, HOW?
2) How do I Format a previously unused Disc location on the SD Card? There is no DFORM as on the TurboSPI.
3) Accepting your view that IMTOD is better, does the COP114 Utility work with MMFS? If so, are there any gotchas?
4) I am happy to read any documentation. Can anybody give me a pointer to where I can find this please

thought you where the guy with a bad Solidisk, got mixed up with this guy : viewtopic.php?f=3&t=17524
anyways, he had same problem, so have I with 5+ machines that came with them, now all binned as S&^te
A1 no
A2 *FORM 80 0
A3 no, as craps with dice
A4 in this thread : viewtopic.php?f=3&t=10621&start=750#p238963

[Coeus]

1) Can IMTOD and IDTOM be used to copy INDIVIDUAL FILES? If so, HOW?

No. it's a BASIC program so looking at the source it copies the tracks, in groups of 8, from one medium to another and always copies the entire disc.

3) Accepting your view that IMTOD is better, does the COP114 Utility work with MMFS? If so, are there any gotchas?

This is written in assembler so a little harder to see what it is doing. Looking at the screenshot from b-em of a *DUMP of COP114:

Starting at 0002B6 there is what look like a series of commands COP114 is issuing. If CARD was to be overwritten with MMFS that may be all that is required. I have not tried this, though, so don't blame me for any data loss.

[Wheel_nut]

1) Can IMTOD and IDTOM be used to copy INDIVIDUAL FILES? If so, HOW?
2) How do I Format a previously unused Disc location on the SD Card? There is no DFORM as on the TurboSPI.
3) Accepting your view that IMTOD is better, does the COP114 Utility work with MMFS? If so, are there any gotchas?
4) I am happy to read any documentation. Can anybody give me a pointer to where I can find this please

thought you where the guy with a bad Solidisk, got mixed up with this guy : viewtopic.php?f=3&t=17524
anyways, he had same problem, so have I with 5+ machines that came with them, now all binned as S&^te

That discussion was about using 3.5" Drives and the Solidisk DFS was NEVER specified to wok with 3.5" Drives. In my experience, the Solidisk DFS 2.2M Issue 2 works flawlessly with 5.25" drives and also seamlessly with both the 8271 and 1770 controllers. You are wrong to suggest that the Solidisk DFS is a flawed product and other users should save themselves the unnecessary cost of consigning it to the bin.

A1 no

I wish I had known! ... could have saved a few hours ...

A2 *FORM 80 0

OK. That works, BUT only if the ADT2.00 ROM is unplugged. I believe that there is a conflict with the ADT Form command (though not with the DFS2.2M2 Form Command. Dave (hoglet) may want to investigate this further and I woud be happy to do diagnostic tests.

A3 no, as craps with dice

I wish I had known! ...

A4 in this thread : viewtopic.php?f=3&t=10621&start=750#p238963

That was the point from which I started this conversation.

[CMcDougall]

1) Solidisk DFS was NEVER specified to wok with 3.5" Drives. In my experience, the Solidisk DFS 2.2M Issue 2 works flawlessly with 5.25" drives and also seamlessly with both the 8271 and 1770 controllers. You are wrong to suggest that the Solidisk DFS is a flawed product and other users should save themselves the unnecessary cost of consigning it to the bin

2)That works, BUT only if the ADT2.00 ROM is unplugged. I believe that there is a conflict with the ADT Form command (though not with the DFS2.2M2 Form Command. Dave (hoglet) may want to investigate this further and I woud be happy to do diagnostic tests

1) rubbish, 1770 was for 3/12" & ADFS try searching the forum , this for starts : viewtopic.php?f=3&t=6912&p=79132&hilit= ... err#p68777
2) waste of Dave's time as 99.9% of people with experience have put them all in the bin!

[hoglet]

I'm just catching up on this thread after having been out for the evening.

OK, I just had a bit of a (Data) disaster! I was trying to use IMTOD to add a few files from a SD Card Disc to a Floppy Disc and ended up overwriting the Floppy Disc with the SD Card Disc!

I'm sorry about this, I hope you didn't loose anything significant.

The names of the utilities IMTOD and IDTOM indicate the direction of data copy, so IMTOD copies from MMC to DISK.

Also the prompts given to the user, I thought, would have made the direction of copy unambiguous.

IMTOD should prompt with:

Code: Select all

MMFS (ROM x) to DFS (ROM y) Disk Imager
Enter source MMFS disk (0-511):
Enter dest DFS drive (0-3):

IDTOM should prompt with:

Code: Select all

DFS (ROM x) to MMFS (ROM y) Disk Imager"
Enter source DFS drive (0-3):
Enter dest MMFS disk (0-511): 

I'm not sure how I could be any clearer here.

As far as I understand, COP114 is commecial software written by Steve Picton (IFEL) for use with his Turbo MMC hardware and support ROM. I have never used this, but I expect when used as designed it will be very good. I have a pretty high opinion of Steve's products, and routinely use several others, but not TurboMMC. But I would also not expect it to work with any other file system.

Dave

[Coeus]

4) I am happy to read any documentation. Can anybody give me a pointer to where I can find this please

So you asked about documentation. In order to find the COP114 program I looked at the CD that came with my Turbo MMC and on the root of that CD is "Using MMC.pdf" which includes the documentation for the COP114 program. It also mentions problems with formatting programs in toolkits, though the problem it was dealing with was the inability to format a real magnetic floppy. What happens is that the toolkit formatting command issues track format calls to OSWORD 7F but, because the MMC filing system is in a higher priority ROM slot that the real DFS, the MMC filing system intercepts that call.

[Wheel_nut]

I'm just catching up on this thread after having been out for the evening.

OK, I just had a bit of a (Data) disaster! I was trying to use IMTOD to add a few files from a SD Card Disc to a Floppy Disc and ended up overwriting the Floppy Disc with the SD Card Disc!

I'm sorry about this, I hope you didn't loose anything significant.

Sorry Dave, I wasn't suggesting that there was anything wrong with the Program. It was my error in expecting to be able to provide the filespec for the Copy operation and in my impetuousness, I hit the button and copied the SD Disc over the Floppy Data! It hadn't occurred to me that the IMTOD only copied the whole Disc and not a selection of files. No, I didn't lose any data as I have everything archived.

As far as I understand, COP114 is commecial software written by Steve Picton (IFEL) for use with his Turbo MMC hardware and support ROM. I have never used this, but I expect when used as designed it will be very good. I have a pretty high opinion of Steve's products, and routinely use several others, but not TurboMMC. But I would also not expect it to work with any other file system.

Dave

By coincidence, I received an email from Steve Picton with whom I had had a discussion about using MMFS with his TurboSPI Hardware. Steve provides the MMFS Images on Disc 308 of his SD Card and a very detailed PDF document on how to use the various flavours and options. In particular, Steve suggested that the DFS should be ABOVE the MMFS in the Sideways order to avoid a clash of the *DISC and *CARD commands among others. I will follow up on those and your suggestions tomorrow when the sun comes up.

Robin

[Wheel_nut]

4) I am happy to read any documentation. Can anybody give me a pointer to where I can find this please

So you asked about documentation. In order to find the COP114 program I looked at the CD that came with my Turbo MMC and on the root of that CD is "Using MMC.pdf" which includes the documentation for the COP114 program. It also mentions problems with formatting programs in toolkits, though the problem it was dealing with was the inability to format a real magnetic floppy. What happens is that the toolkit formatting command issues track format calls to OSWORD 7F but, because the MMC filing system is in a higher priority ROM slot that the real DFS, the MMC filing system intercepts that call.

I wasn't ignoring your two posts ... I was distracted by children needing more urgent attention....

I am in discussion with Steve Picton who has suggested using the variants of MMFS in the C. directory of Disc 308 on his SD Card. I have had success with both the C.MMFS and C.SWMMFS variants which are co-existing with my DFS2.2M2 and ADT and UVP1.1 .... but not (yet) tested with GREX which I found to be problematical with other ROMS. Also, I can switch to DFS with *Disk and back to SD Card with *MMFS and the COP114 Utility works perfectly!

I still don't know what the difference is between Dave's ZMMFS and Steve's SWMMFSBL bootloading ROMs or indeed the difference between the V1.41 files in Dave's release and Steve's Disk308 on the SD Card.

Robin

[hoglet]

I still don't know what the difference is between Dave's ZMMFS and Steve's SWMMFSBL bootloading ROMs or indeed the difference between the V1.41 files in Dave's release and Steve's Disk308 on the SD Card.

Can you tell us the MMFS version Steve has included on Disk 308. You can find this out by typing *HELP.

Dave

[Wheel_nut]

I still don't know what the difference is between Dave's ZMMFS and Steve's SWMMFSBL bootloading ROMs or indeed the difference between the V1.41 files in Dave's release and Steve's Disk308 on the SD Card.

Can you tell us the MMFS version Steve has included on Disk 308. You can find this out by typing *HELP.

Dave

Hi Dave, *HELP reports MMFS V1.41. ... but there are two versions of each ROM Image provided in Disc 308. In the Root Directory are MMFS, SWMMFS(Sideways RAM), MAMMFS(Master) and SWMMFSBL(Bootloader). In the C. Directory are MMFS, MAMMFS and SWMMFS but thesee are doctored so that they do not conflict with the DFS commands, even if the DFS is in a lower order SWRom slot. Steve has not (yet) created a Bootloader version of the C.SWMMFS so I am testing it by booting with NO MMFS to Floppy disk and then using *RLOAD to load C.SWMMFS into SWRam bank F. My DFS is in Slot 6 and ADT is in Slot 2.

I have had this running all afternoon and it has not required the Big Black Switch treatment at all

[hoglet]

In the C. Directory are MMFS, MAMMFS and SWMMFS but thesee are doctored so that they do not conflict with the DFS commands, even if the DFS is in a lower order SWRom slot.

OK, I understand.

Do be aware there is a trade off here....

In these versions, Steve has manually edited the *DISK and *DISC command names to something else. That will indeed have the desired effect of improving compatibility with some versions of DFS. But it will cause several games in the STH archive to fail, as it's quite common for games to include the *DISK command in their loader. That's why MMFS (and many other MMC file systems) work as they do.

Dave

[Wheel_nut]

OK, I understand.

Do be aware there is a trade off here....

In these versions, Steve has manually edited the *DISK and *DISC command names to something else. That will indeed have the desired effect of improving compatibility with some versions of DFS. But it will cause several games in the STH archive to fail, as it's quite common for games to include the *DISK command in their loader. That's why MMFS (and many other MMC file systems) work as they do.

Dave

Dave, It would seem that the simplest way to avoid conflicts if using the standard MMFS versions would be to have the DFS higher than the MMFS in the Sideways heirarchy. This raises some questions:
1) Do you have a preferred DFS which is least likely to conflict with MMFS?
2) Since ZMMFS automatically loads to the highest available Sideways RAM bank (in my case Bank F), how do I get the DFS above it?

Robin

[hoglet]

1) Do you have a preferred DFS which is least likely to conflict with MMFS?

There are bugs I think in Acorn DFS 0.9 and 1.2 that cause workspace problems when switching between file systems. I think those were fixed in Acorn DFS 2.26, but that is for the 1770 disc controller only. So it depends on what disc controller your Beeb has, and what you are trying to achieve.

2) Since ZMMFS automatically loads to the highest available Sideways RAM bank (in my case Bank F), how do I get the DFS above it?

The only way I can thing of would be to rebuild the ZMMFS boot loader, with a change to start the RAM search at a lower bank number.

It's this line that would change.
https://github.com/hoglet67/MMFS/blob/m ... p.asm#L173

As it's a one byte change, you could just patch the binary.

Dave

[Coeus]

There are bugs I think in Acorn DFS 0.9 and 1.2 that cause workspace problems when switching between file systems. I think those were fixed in Acorn DFS 2.26, but that is for the 1770 disc controller only. So it depends on what disc controller your Beeb has, and what you are trying to achieve.

Now that's interesting. I did a quick trace of what the COP114 program is doing so what, if anything, means it would only work with the supplied Turbo MMC rather than with MMFS. So I tried executing:

Code: Select all

*dtom 0 vdfs/txt

and here's what it did

• Check the current filing system is no. 4
• Check a signature at the end of the current filing system ROM "B8 3A 7E 3F"
• Save the NMI area and 2F bytes at A0 to it's own sideways RAM bank.
• OSCLI *DISC
• OSCLI *DRIVE 0
• OSCLI *DIR $
• OSGBPB A=08 read filenames. This is repeated up for to 3F filenames. These are stored again in its own RAM bank and presumably from there it applies the pattern patching against the supplied filename - I didn't trace the pattern match.
• OSFILE A=05 get file attributes. I didn't trace what it did with the attributes but I very much suspect this is check of whether the file fits in memory between OSHWM and HIMEM and thus whether to adopt an OSFILE strategy or OSGBPB.
• OSFILE A=FF load file, load address OSHWM
• OSFILE A=05 get file attributes, this time to set reload/exec addresses ready for save.
• OSCLI *CARD
• Restore NMI area and A0 from S/W RAM.
• OSFILE A=00, save file.

I should note I was running this in b-em and fiddling some of the tests to make it continue when otherwise it would have given up. Presumably if I had supplied a pattern that matched more than one file the steps from the first OSFILE A=05 would have been repeated for each matched file.

There are two, maybe three, trivial changes that could be made to pass the initial checks which would then mean this program would at least try to work with MMFS as the card filing system:

• Have MMFS use filing system number 4 if it doesn't already.
• Finish the MMFS ROM with the signature "B8 3A 7E 3F" at BFFC to BFFF
• Accept *CARD as a means of selecting MMFS.

That means the only area of doubt is whether the save/restore of the NMI area and the filing system zero page area at A0 would upset MMFS. At a guess this is intended to save/restore which image within the BEEB.MMB file is the current virtual disc as well as which drive is selected with the card filing system.

[CMcDougall]

Accept *CARD as a means of selecting MMFS

that would be easy, just patch *DISK to *CARD, as it should be spelt DISC anyways

[Wheel_nut]

There are two, maybe three, trivial changes that could be made to pass the initial checks which would then mean this program would at least try to work with MMFS as the card filing system:

• Have MMFS use filing system number 4 if it doesn't already.
• Finish the MMFS ROM with the signature "B8 3A 7E 3F" at BFFC to BFFF
• Accept *CARD as a means of selecting MMFS.

That means the only area of doubt is whether the save/restore of the NMI area and the filing system zero page area at A0 would upset MMFS. At a guess this is intended to save/restore which image within the BEEB.MMB file is the current virtual disc as well as which drive is selected with the card filing system.

As Dave said earlier, there is a trade-off to changing the *DISK and *DISC commands because some of the games on the STH compendium use these commands. *DISK and *DISC would need to be re-directed to *MMFS rather than just dummied out.

Here are some of the behaviours that I noticed when trying to find a solution to the conundrum:
1) The obvious solution seemed to be to put the DFS in a higher order slot than the MMFS to let DFS intercept any calls to *DISK. However, this created the immediate problem that the system boots (and Breaks) to DFS rather than boot the MMFS Menu.

2) Because I want to use the file copying flexibility afforded by the COP114 Utility, I can't use the out-of-the-box MMFS (T/MMFS, T/SWMMFS or T/ZMMFS) and have only had success with Steve Picton's variants C.MMFS, C.SWMMFS. These work for me but with the only constraint that I cannot use them in Sideways RAM to keep Page at 0E00. I also accept Dave's concern that these variants "may" cause problems with some STH games. It would be nice for me if Steve released a Bootloader version of the C.Variants (pretty please )

3) I can switch to DFS using *DFS and back to MMFS using *MMFS. This seems to work reliably and BREAK goes back to the Default MMFS.

4) I have found that the Graphics Extension ROM interferes with the operation of my DFS and MMFS installation.

5) ADT2.00 and HELP1.2C seem to co-exist with all of the above implementations though I put ADT in a low order socket.

I realise that my need for flexible manipulation of files between Floppy Disk and SD Card may not be a high priority requirement for everybody, I hope that this helps to save your time if you are experimenting with your Beeb.

Thanks to Coeus and Dave and Steve Picton(off-line) for indulging me with their time. ... Robin