Pi1MHz Software

[Mince]

OK - mystery solved. The card was 2GB and, indeed, formatted as FAT16 and not FAT32. I’ve substituted for a 32GB card and the formatted has chosen FAT32 for that and both MMFS and MMFS2 seem to be working fine with it on the Electron, doing a quick test (I haven’t tried *DIN on MMFS2 yet as I’m supposed to be cooking toad in the hole, but *DCAT lists directories and *DDIR changes into them OK).

Thanks for your help and sorry to muck you about! I don’t know if something subtle has happened but oddly this was working on the 2GB card with the previous releases, though - it’s not a problem to force FAT32 or just change the card, though.

As an aside here, does MMFS still directly access raw blocks on the card through the Pi1MHz, for both MMFS and MMFS2, or does the Pi1MHz code do any higher level interface? I was wondering if that could perform some of the heavy lifting, like making discs in MMFS2.

[dp11]

That's good news. I would if possible like to examine the layout of the 2G card as that should work with mmfs. Can you zip up the raw disk image? Pi1MHz just passes on raw accesses from mmfs to the SDcard. It was the easiest way to not change too much.

[Mince]

Here's a gzipped "dd if=/dev/disk2 ..." of the entire SD card (including partition table):

https://www.dropbox.com/scl/fi/rz8xxyth ... zy7lt&dl=0

[hoglet]

That's good news. I would if possible like to examine the layout of the 2G card as that should work with mmfs.

MMFSv1 supports both FAT16 and FAT32 but my understanding was that MMFSv2 only supports FAT32. See Martin's original post:
viewtopic.php?p=296454#p296454

So with this card I would expect a Card Format? error in MMFSv2 (not FAT32) and an Image? error in MMFSv1 (no BEEB.MMB file)

Note, as long as a card is 512MB or larger, it should be possible to format it with FAT32.

Dave

[dp11]

That's good news. I would if possible like to examine the layout of the 2G card as that should work with mmfs.

MMFSv1 supports both FAT16 and FAT32 but my understanding was that MMFSv2 only supports FAT32. See Martin's original post:
viewtopic.php?p=296454#p296454

So with this card I would expect a Card Format? error in MMFSv2 (not FAT32) and an Image? error in MMFSv1 (no BEEB.MMB file)

Note, as long as a card is 512MB or larger, it should be possible to format it with FAT32.

Dave

I think Mince reported that the FAT16 image didn't work with MMFS

[Mince]

So with this card I would expect a Card Format? error in MMFSv2 (not FAT32) and an Image? error in MMFSv1 (no BEEB.MMB file)

For MMFSv1, there IS a file BEEB.MMB (I think!), or have I made a typo on the filename, or got something else subtly wrong?

The error case with MMFSv2 is certainly consistent, though.

[hoglet]

The error case with MMFSv2 is certainly consistent, though.

And also expected, as I don't think MMFSv2 has ever supported FAT16.

For MMFSv1, there IS a file BEEB.MMB (I think!), or have I made a typo on the filename, or got something else subtly wrong?

Historically, MMFSv1 will only find a BEEB.MMB file if it's in the first 16 entries of the root directory. So with the latest official build of MMFSv1 (1.55 released Jan 6th) your card gives an "Image not found!" error and that's expected. Note: This is regardless of whether the format is FAT16 or FAT32, and regardless of the interface used to connect the SD Card.

Very recently (4 days ago) Dominic fixed this limitation in his fork:
https://github.com/dp111/MMFS/commit/1f ... 5eb1723022

(this is still called MMFS 1.55 which might be where the confusion is coming from)

If I use a build after this from Dominic's fork, then that limitation is removed, and your card image works. This fix will apply to all builds of MMFSv1, not just the Pi1MHz one.

As soon as Dominic is ready, I'll merge his form back into MMFS, bump the version number and make a new release.

I assume you have built your own ESWMMFS ROM from Dominic's fork. Can you check what commit your are on (git log will do this)?

Dave

[Mince]

The error case with MMFSv2 is certainly consistent, though.

And also expected, as I don't think MMFSv2 has ever supported FAT16.

Sorry — yes — by 'consistent' I meant 'expected'!

Historically, MMFSv1 will only find a BEEB.MMB file if it's in the first 16 entries of the root directory. So with the latest official build of MMFSv1 (1.55 released Jan 6th) your card gives an "Image not found!" error and that's expected. Note: This is regardless of whether the format is FAT16 or FAT32, and regardless of the interface used to connect the SD Card.

Very recently (4 days ago) Dominic fixed this limitation in his fork:
https://github.com/dp111/MMFS/commit/1f ... 5eb1723022

...

I'll check this evening — I thought was using the MMFS version Dominic attached to his post with the 20240430 release but maybe I'm accidentally using an old version. I certainly downloaded it, but maybe I copied the wrong (and old) mmfs.ssd onto the Electron to test it. If so, that explains everything and should clear this up — at least you've tried the SD card image and it works, so it's got to be something I've done wrong!

I suppose before some of the extra goodies were added to the Pi1MHz SD card, this wasn't an issue, but the extra files have probably tipped us over 16 files. I was aware of this problem but had also seen there was an updated version that fixed it so thought this shouldn't be an issue.

[Mince]

Hmmm, this is odd...

I WAS using the version of ESWMMFS MMFSv1 from this post on 30th April @ 19:10: https://www.stardot.org.uk/forums/viewt ... 92#p424092 — I'm still getting "Card format?" when I *DCAT with the 2GB FAT16 card. Swapping in the FAT32 card with the same version of Pi1MHz (from that post), using the same ESWMMFS version, it all works.

I've also pulled the latest version of the the master branch from git@github.com:dp111/MMFS.git, which is currently at commit a26ec00, and built it and get an identical ESWMMFS.rom file to the one in the post (and, just to confirm, it fails in the same way).

Given that you've tried an identical setup with the same 2GB card image, I don't know why it's failing for me. I don't know if it's worth spending any time on it when I can just format the card to FAT32 but I'm happy to try anything else, if you're interested!

[dp11]

Don't format it just yet. I'll try and see if I can reproduce it.

[hoglet]

Given that you've tried an identical setup with the same 2GB card image, I don't know why it's failing for me. I don't know if it's worth spending any time on it when I can just format the card to FAT32 but I'm happy to try anything else, if you're interested!

Thanks for continuing to persue this, there is obviously something not quite right here....

The only difference when I tested was I was using a larger (16GB card).

It's possible your 2GB card is SD rather than SDHC, which is another variable. If the card is SD then MMFS will send the command address in bytes rather than sectors, and that will confuse Pi1MHz if it's expecting sectors. Maybe Pi1MHz should always respond with a card type of SDHC if it only supports command addresses in sectors. Dominic?

I'll also double check I didn't make a mistake when testing....

Dave

Edit: Your disk image size is 1886MB, so it's likely this is SD (SDSC) rather than SDHC, and I'm now fairly sure this is a bug in Pi1MHz. Also, the initialization sequence you posted eariler includes CMD1/SEND_OP_COND (FF4100000000FF:00), which is only sent if the card type is SD. So I think this confirms it... By the way, this is my go-to reference on all things SD/SDHC.

[Mince]

The only difference when I tested was I was using a larger (16GB card).

It's possible your 2GB card is SD rather than SDHC, which is another variable. If the card is SD then MMFS will send the command address in bytes rather than sectors, and that will confuse Pi1MHz if it's expecting sectors. Maybe Pi1MHz should always respond with a card type of SDHC if it only supports command addresses in sectors. Dominic?

Certainly it's a 2GB one — I deliberately have a small bunch of them as I have some old things that don't support SDHC and I know that it's the maximum size before you get that.

It's a bit of a niche thing these days and getting hold of a 2GB card is really hard now (I think they tend to command a small bit of premium as people who want them tend to have this restriction), so if it's not easy to fix, it's not an issue.

[dp11]

I will investigate Pi1MHZ init sequence for smaller SDCARDs. I have a thought to what I have done wrong.

[hoglet]

I will investigate Pi1MHZ init sequence for smaller SDCARDs. I have a thought to what I have done wrong.

I think the issue is just that small SDSC cards (<=2GB) are addressed differently to SDHC cards. For SDSC the command address is in units of bytes. For SDHC it's in units of 512b sectors, allowing larger cards to be addressed. So MMFS generates the command address accordingly, based on the SD card type.

I think the Pi1MHz firmware (specifically FatFS) always interprets the command address as 512b sectors (see here), but for small cards MMFS will be sending a command address in bytes. The wrong part of this disc is then read, hence the Card Format? error.

I think the fix is easy: the emulation should always return a result of 1 (=SDHC) in response to command 0x48. This could be done either in the MMFS driver (MMC_Pi1MHz.asm) or in the Pi1MHz firmware.

Dave

[dp11]

It's a bit of a niche thing these days and getting hold of a 2GB card is really hard now (I think they tend to command a small bit of premium as people who want them tend to have this restriction), so if it's not easy to fix, it's not an issue.

I think I have fixed the issue. If you could give the attached a try , that would be great. I have increased the version number to 1.56.

[hoglet]

Dominic,

This looks wrong to me:
https://github.com/dp111/MMFS/blob/e4f3 ... C.asm#L103

Should that BNE be a BEQ?

Dave

[dp11]

Dominic,

This looks wrong to me:
https://github.com/dp111/MMFS/blob/e4f3 ... C.asm#L103

Should that BNE be a BEQ?

Dave

Yep.

[Mince]

Thanks for these — that tests OK with both MMFSv1 and MMFSv2 on my 2GB card formatted with FAT16. It also works fine with my 32GB card and FAT32.

MMFSv2 also works fine with the 2GB card formatted with FAT32. I get problems with MMFSv1 on a 2GB card formatted with FAT32 instead of FAT16, however — *DCAT works fine, but the individual discs are corrupted (e.g. I do a *. and get a catalogue listing that hangs after printing "Lib." and the title is "@" when it should be Scratch).

This is obviously an odd situation and I'm not sure if you care about it, but I thought I'd give things a good workout.

[dp11]

This is obviously an odd situation and I'm not sure if you care about it, but I thought I'd give things a good workout.

Odd situations just cause support problems later on. Can I save an SDcard image again please? If been.mmb is fragmented it would cause this issue.

[hoglet]

I get problems with MMFSv1 on a 2GB card formatted with FAT32 instead of FAT16, however — *DCAT works fine, but the individual discs are corrupted (e.g. I do a *. and get a catalogue listing that hangs after printing "Lib." and the title is "@" when it should be Scratch).

Is it possible that your BEEB.MMB file has got fragmented? That would explain the symptoms. The only way I have found to guarantee it doesn't get fragmented is to copy that file onto the card first.

There is a tool on Linux called filefrag (part of the e2fsprogs package I think) that reports the number of "extents" in the file. If this is more than one, that will cause issues with MMFSv1.

Alternatively, as Dominic suggested, image tha card.

This is obviously an odd situation and I'm not sure if you care about it, but I thought I'd give things a good workout.

Not that odd; I use this all the time!

Dave

[Mince]

Is it possible that your BEEB.MMB file has got fragmented? That would explain the symptoms. The only way I have found to guarantee it doesn't get fragmented is to copy that file onto the card first.

There is a tool on Linux called filefrag (part of the e2fsprogs package I think) that reports the number of "extents" in the file. If this is more than one, that will cause issues with MMFSv1.

Thanks — that claims 1 extent for BEEB.MMB.

I've uploaded an image of this card here: https://www.dropbox.com/scl/fi/yaajkj0x ... kkvq4&dl=0

[hoglet]

Thanks — that claims 1 extent for BEEB.MMB.

I've uploaded an image of this card here: https://www.dropbox.com/scl/fi/yaajkj0x ... kkvq4&dl=0

Are you sure?

I'm seeing 10 extents...

Code: Select all

sudo dd if=PI1MHZ-2G-FAT32.dsk of=/dev/sdf bs=1M
...
sudo filefrag  /media/dmb/PI1MHZ-ELK/BEEB.MMB 
/media/dmb/PI1MHZ-ELK/BEEB.MMB: 10 extents found

And in a bit more detail:

Code: Select all

sudo filefrag -v /media/dmb/PI1MHZ-ELK/BEEB.MMB 
Filesystem type is: 4d44
File size of /media/dmb/PI1MHZ-ELK/BEEB.MMB is 104660992 (204416 blocks of 512 bytes)
Discontinuity: Block 16 is at 9334 (was 9326)
Discontinuity: Block 40 is at 9494 (was 9358)
Discontinuity: Block 144 is at 11030 (was 9598)
Discontinuity: Block 160 is at 14198 (was 11046)
Discontinuity: Block 168 is at 14214 (was 14206)
Discontinuity: Block 184 is at 14238 (was 14230)
Discontinuity: Block 200 is at 14278 (was 14254)
Discontinuity: Block 208 is at 14542 (was 14286)
/media/dmb/PI1MHZ-ELK/BEEB.MMB: 10 extents found

Dave

[Mince]

Dammit! Sorry — I looked at MMFS.SSD and not BEEB.MMB (I guess my brain was subconsciously thinking of MMFSv2 at the time)! Another mystery solved!

(I'm glad I still had the Terminal window open so I could see what I did, otherwise that would have confused me even more!)

[dp11]

Dammit! Sorry — I looked at MMFS.SSD and not BEEB.MMB (I guess my brain was subconsciously thinking of MMFSv2 at the time)! Another mystery solved!

I like solved mysteries!

[dp11]

On my machine, the reset which occurs after the SWR load is complete doesn't actually initialise the new ROM. I need to do a further BREAK for that to work. No major deal.

Hi Dominic,

I was having a look at some other reset code, and noticed the following does a harder reset:

Code: Select all

LDA #&97
LDX #&4E
LDY #&7F
JSR &FFF4
LDA #&C8
LDX #&03
JSR &FFF4
JMP(&FFFC)

Would it be possible to add that extra OSBYTE command to your reset routine, to see if that helps with initialisation?

Thanks.

Does any one know the correct way of starting a file system rom ?

On my MOS 3.20 * FX200,3 works . Ken says it doesn't work on his machine but adding ?&FE4E=&7E does work. But on MOS 3.5 that also clears the SWR that has just been loaded.

[Mince]

I have an odd problem in MMFS 1.56 with the Pi1MHz — if I *DIN a disc, I can *CAT it and *EXEC !BOOT to load it up OK.

If, however, I use *DBOOT on the same disc, I get "Wrong card" and then everything from there on gives that error (*CAT, *DCAT, *DIN, etc.). I also get the same thing if I push Shift+Break to boot it. A Ctrl+Break brings things back to working.

I don't get the same problem with the T build (for the BBC User Port) from the same version.

I'm building from source using commit 5c8373b and I'm using the SWMMFS version.