MMFS Version 2

bbc/electron apps, languages, utils, educational progs, demos + more
Coeus
Posts: 2249
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: MMFS Version 2

Post by Coeus »

hoglet wrote:
Tue Jan 12, 2021 1:58 pm
FE80 (Modem) and FEA0 (Econet) are the two addresses where people tend to place second user ports.
How about FEDC, then. That's in the space that would normally be decoded to the ADC on a model B but isn't the usual address for it (FEC0), which means if people load games that expect a model B and directly access the ADC they are unlikely to upset the MMC implementation.
User avatar
hoglet
Posts: 10351
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: MMFS Version 2

Post by hoglet »

Coeus wrote:
Tue Jan 12, 2021 2:05 pm
How about FEDC, then. That's in the space that would normally be decoded to the ADC on a model B but isn't the usual address for it (FEC0), which means if people load games that expect a model B and directly access the ADC they are unlikely to upset the MMC implementation.
FEDC on the Master should be fine.

Dave
Coeus
Posts: 2249
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: MMFS Version 2

Post by Coeus »

hoglet wrote:
Tue Jan 12, 2021 2:47 pm
FEDC on the Master should be fine.
Ok, I have pushed a commit that implements that on the Master.
User avatar
hoglet
Posts: 10351
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: MMFS Version 2

Post by hoglet »

Coeus wrote:
Tue Jan 12, 2021 3:15 pm
hoglet wrote:
Tue Jan 12, 2021 2:47 pm
FEDC on the Master should be fine.
Ok, I have pushed a commit that implements that on the Master.
As far as I can tell, that's all working.

I've pushed a new MMFS release (1.49) that uses &FEDC for the Master:
https://github.com/hoglet67/MMFS/releas ... mfs_1_49_0

This includes all the latest MMFS2 work, but I haven't yet tackled the proposed renaming of files/directories in the release ZIP.

A couple of minor things:

1. I can't get the B+ version to work (MMFS/M/SWMMFS+.rom).

The disks just appear empty, and *DCAT hangs.

This could be a regression in MMFS, or it could be a bug in B-Em's emulation of the B+

Any thoughts?

2. With MMFSv1 the "disc image" you load (with Load MMC Card) can be one of:
- a FAT16 formatted disk image containing a BEEB.MMB file (with or without a partition table)
- a FAT32 formatted disk image containing a BEEB.MMB file (with or without a partition table)
- a raw BEEB.MMB file (with no file system at all)

I don't know if that affects what you want call the menu item?

I guess I'm wondering how the user is mean to know to use Load MMB file for the built-in MMB/DFS support, and Load MMC Card for the hardware MMFS support?

BTW, the Menu items are currently called Load MMC Card and Eject MMC File.

I wonder if Load SD Image / Elect SD Image would be better?
Coeus
Posts: 2249
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: MMFS Version 2

Post by Coeus »

hoglet wrote:
Tue Jan 12, 2021 4:28 pm
1. I can't get the B+ version to work (MMFS/M/SWMMFS+.rom).
Trying *DCAT I can see it succeeding at the SHDC init and getting as far as setting the block size for the card then it hangs with no further activity on the card. Breaking into it with the debugger shows it exectuting a HLT instruction at location 0000, so not waiting on the card driver due to an unexpected status. I'll continue to investigate.
hoglet wrote:
Tue Jan 12, 2021 4:28 pm
I guess I'm wondering how the user is mean to know to use Load MMB file for the built-in MMB/DFS support, and Load MMC Card for the hardware MMFS support?
Yes, that menu is busy anyway now, and I was wondering if I should have more sub-menus or not. I am not really a UI person but having two very similarly named options on such a busy menu may well cause confusion. I have updated them.
Coeus
Posts: 2249
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: MMFS Version 2

Post by Coeus »

It's crashing at AD9D but that's because, when it comes to execute that, it isn't the code that should be there but seems to have been overwritten. What should be there is:

Code: Select all

.MMC_Sector_Reset
     AD9D   A2 0A      LDX #&0A
     AD9F   20 E9 AD   JSR &ADE9
.SelectImage
     ADA2   20 8D B3   JSR &B38D
     ADA5   8D ED A4   STA &A4ED
     ADA8   8C EC A4   STY &A4EC
What is actually tried executing:

Code: Select all

cpu core6502: Break at D:AD9D
D:AD9D: A2 0A       LDX #0A     >s
D:ADA0: E9 AD       SBC #AD     >s
D:ADA3: 8D B3 8D    STA 8DB3    >s
D:ADA6: ED A4 8C    SBC 8CA4    >s
D:ADA9: EC A4 A9    CPX A9A4    >s
D:ADAC: 00          BRK         >
Coeus
Posts: 2249
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: MMFS Version 2

Post by Coeus »

I have just noticed something weird about that - the code that actually there is the code that should be there with the JSR instruction codes, i.e. hex 20, omitted. That seems a bit of a strange co-incidence. Or maybe it's a bug in the debugger.
Coeus
Posts: 2249
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: MMFS Version 2

Post by Coeus »

So looking at that same memory with the 'm' debugger instruction, the 20 opcodes are there - it is advancing the PC by the wrong amount. Adding a debug message to the LDX immediate instruction suggests it is not executing the code the debugger is displaying, so maybe there is an issue with memory paging.
User avatar
hoglet
Posts: 10351
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: MMFS Version 2

Post by hoglet »

Coeus wrote:
Tue Jan 12, 2021 5:44 pm
I have just noticed something weird about that - the code that actually there is the code that should be there with the JSR instruction codes, i.e. hex 20, omitted. That seems a bit of a strange co-incidence. Or maybe it's a bug in the debugger.
It's even stranger than that....

Look at this trace:

Code: Select all

	D:8502: 20 8E AF    JSR AF8E     00 02 00 F8  V  ZC 8502
	D:AF8E: 20 0D B6    JSR B60D     00 02 00 F6  V  ZC AF8E
	D:AF91: 20 70 AE    JSR AE70     AF AF 00 F6 NV   C AF91 <<<<
	D:AF94: 20 13 B4    JSR B413     AF AF 00 F6 NV   C AF94
	D:AF97: A5 CD       LDA CD       AF AF 00 F6 NV   C AF97
	D:AF9A: 82 A4       NOP #A4      AF AF 00 F6 NV   C AF9A
	D:AF9D: 7A          NOP          AF AF 00 F6 NV   C AF9D
	D:AFA0: 04 A3       NOP A3       AF AF 00 F6 NV   C AFA0
	D:AFA3: F8          SED          AF AF 00 F6 NV   C AFA3
	D:AFA6: 8D 04 A3    STA A304     AF AF 00 F6 NV   C AFA6
	D:AFA9: D8          CLD          AF AF 00 F6 NV   C AFA9
	D:AFAC: B6 20       LDX 20,Y     AF AF 00 F6 NV   C AFAC
	D:AFAF: AE 20 00    LDX 0020     AF AF 00 F6 NV   C AFAF
	D:AFB2: AE 20 2A    LDX 2A20     AF AF 00 F6 NV   C AFB2
	D:AFB5: B4 4C       LDY 4C,X     AF AF 00 F6 NV   C AFB5
	D:AFB8: AF A5 B4    LAX B4A5     AF AF 00 F6 NV   C AFB8
	D:AFBB: D0 05       BNE AFC2     AF AF 00 F6 NV   C AFBB
	D:AFBE: CD 20 73    CMP 7320     AF AF 00 F6 NV   C AFBE
	D:AFC1: AE A9 05    LDX 05A9     AF AF 00 F6 NV   C AFC1
Why is the program counter value on the marked line not B60D?

The target of B60D is:

Code: Select all

.MMC_BEGIN1
     B60D   A2 09      LDX #&09
.begloop1
     B60F   B5 BC      LDA &BC,X
     B611   9D 90 A4   STA &A490,X
     B614   CA         DEX
     B615   10 F8      BPL &B60F
     B617   20 1E B1   JSR &B11E
It's almost as if the debugger is seeing code in the 8000-AFFF RAM overlay, but the main processor is executing code from elsewhere....

Dave
Coeus
Posts: 2249
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: MMFS Version 2

Post by Coeus »

hoglet wrote:
Tue Jan 12, 2021 6:18 pm
Why is the program counter value on the marked line not B60D?
Because the code it executed wasn't a JSR instruction but something else.
hoglet wrote:
Tue Jan 12, 2021 6:18 pm
It's almost as if the debugger is seeing code in the 8000-AFFF RAM overlay, but the main processor is executing code from elsewhere....
I think that's it, but the other way around. The CPU is executing from the overlay RAM and therefore the increments to the PC are for the instructions found there, but the debugger is disassembling the ROM at the same address.

So either MMFS has paged in the overlay RAM and forgotten page it out, or addresses have changed so what was safely above that overlay RAM no longer is, or B-Em has a bug with the overlay RAM paging.
Last edited by Coeus on Tue Jan 12, 2021 6:34 pm, edited 1 time in total.
Coeus
Posts: 2249
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: MMFS Version 2

Post by Coeus »

The last write to ROMSEL prior to the call to AD9D was with the value 8B. I am running with SWMMFS+ in ROM slot B. So this looks like calling into the lower part of the ROM that gets overlaid without cancelling the overlay.
User avatar
hoglet
Posts: 10351
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: MMFS Version 2

Post by hoglet »

Coeus wrote:
Tue Jan 12, 2021 6:30 pm
The last write to ROMSEL prior to the call to AD9D was with the value 8B. I am running with SWMMFS+ in ROM slot B. So this looks like calling into the lower part of the ROM that gets overlaid without cancelling the overlay.
As far as I remember, the B+ version of MMFS copies itself from ROM (8000-AFFF) into the RAM overlay (8000-AFFF) then mostly executes with the overlay enabled. The workspace is positioned somewhere in the middle of that chunk. This is so the bulk of the code can access the workspace directly without any bank switching.

So I think it's expected that you would see calls into the lower part of the ROM with the RAM overlay enabled.

The code that does the copy from ROM to RAM is called Init12K.

There is a assembly listing in the release package for each build.

Dave
User avatar
hoglet
Posts: 10351
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: MMFS Version 2

Post by hoglet »

I've also tested an older version (MMFS 1.36) where the B+ code was first included. This crashes in a similar way. I think this rules out a recent regression in MMFS.

There are known issues with the MMFSv2 B+ build, so I would ignore that for now, and concentrate on the MMFSv1 B+ build, which ought to work.

I don't known if anyone with a real B+ could confirm this?
Coeus
Posts: 2249
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: MMFS Version 2

Post by Coeus »

It is looking like reads from the overlay RAM are returning the top 8 bits of the address rather than the value actually written. That's almost certainly a bug in the way the memory map is being set up in B-Em.
Coeus
Posts: 2249
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: MMFS Version 2

Post by Coeus »

Fixed: https://github.com/stardot/b-em/commit/ ... 9fabfd1bdd also merged to mmccard branch.

So the 0x80 value in ram8k was being set in RAMBank and from there to vis20k and finally used as an index into memstat. That returned zero, which is a memory type of I/O (1 = ram, 2 = rom) but the address didn't match any I/O device so returned the top half of the address.
User avatar
hoglet
Posts: 10351
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: MMFS Version 2

Post by hoglet »

Coeus wrote:
Tue Jan 12, 2021 7:49 pm
Fixed: https://github.com/stardot/b-em/commit/ ... 9fabfd1bdd also merged to mmccard branch.
Excellent....

That sorts the issue with SWMMFS+

Looking at the code in 6502.c, could you check one more thing please.

I have a suspicion that when stepping through code running from the 8000-AFFF RAM overlay, that debugger might be displaying a disassembly from the ROM.

I think the possible culprit is:

Code: Select all

static inline uint32_t debug_addr(uint32_t addr)
{
    if (addr >= 0x8000 && addr < 0xC000)
        addr |= ram_fe30 << 28;
    return addr;
}
https://github.com/stardot/b-em/blob/ma ... 502.c#L308

This address eventually makes it's way to:

Code: Select all

static uint32_t dbg_do_readmem(uint32_t addr) {
    uint32_t romno = addr & 0xF0000000;
    addr = addr & 0xFFFF;
    if (romno && addr >= 0x8000 && addr < 0xC000) {
            return rom[(romno >> 14) + addr - 0x8000];
    }
    else
        return do_readmem(addr);
}
So, anything debugged from sideways ROM is going to be retrieved from rom.

Or have I got myself confused?

Dave
Coeus
Posts: 2249
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: MMFS Version 2

Post by Coeus »

hoglet wrote:
Tue Jan 12, 2021 8:19 pm
So, anything debugged from sideways ROM is going to be retrieved from rom.

Or have I got myself confused?

Dave
That's right. I am working on it. It comes from adding ROM-bank-specific breakpoints. The debugger works with 32bit addresses and therefore each CPU now has address parse and address print routines so 8 and 16bit processors can encode other information into the upper bits of the address.

But in the case of the I/O 6502 it doesn't fully encode all the options for paging things in/out.
Coeus
Posts: 2249
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: MMFS Version 2

Post by Coeus »

Ok, I have pushed a change to the mmccard branch that should address this - if the ROM number being read/written to is the current one it reverts to calling the normal read/write function that does take into account the state of the overlay RAM.
rharper
Posts: 572
Joined: Sat Sep 01, 2012 6:19 pm
Location: Dunstable, LU6 1BH
Contact:

Re: MMFS Version 2

Post by rharper »

I have produced a menu and a BBC+Electron file archive for use with MMFS2 here viewtopic.php?f=3&t=21511&p=304584#p304584
Ray
Raycomp
Relo
Posts: 6
Joined: Sat Oct 17, 2020 9:56 pm
Contact:

Re: MMFS Version 2

Post by Relo »

Can someone explain to me how to use it?

I believe I had it all working a month or so ago but seem to have completely forgotten how to use it, or maybe I've gotten issues since then. At any rate I can't seem to load anything. Currently almost anything I do results in either a "not found" error or "drive empty" error, including shift-break. While *DCAT shows all files on the SD. I do remember it working, but at this point I'm not even sure of that. :lol: Granted I'm not all to familiar with the Beeb seeing as I only owned one for half a year or so.

Also since last boot I did change some things, I removed the watford shadow RAM from my machine but I doubt that would affect anything. As it annoyed me opening up the case (mounted on the top shell) and I needed to turn it off for a lot of thing I did on the beeb anyway.
User avatar
BigEd
Posts: 4238
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

Re: MMFS Version 2

Post by BigEd »

If *DCAT shows all the disk images, that means something is working. You may still need a *DIN to select the particular disk image. Think of *DCAT as your box of floppies, and *DIN as selecting a floppy and putting it in the drive.

If you have a floppy in the drive, *CAT (or *.) will show the title, size, contents and boot mode of that floppy.

*EXEC !BOOT
will often do the same as shift-break. If not, probably
*/ !BOOT
will do it. Or *RUN !BOOT
rharper
Posts: 572
Joined: Sat Sep 01, 2012 6:19 pm
Location: Dunstable, LU6 1BH
Contact:

Re: MMFS Version 2

Post by rharper »

I have made an archive for BBC Roms on SSD images which can be used with MMFSv2:
viewtopic.php?f=3&t=22421
Also a couple of utilities - a 'MainMenu' and Desktop+Browser.
Ray
Raycomp
User avatar
richud
Posts: 37
Joined: Sat Aug 29, 2015 3:03 pm
Contact:

Re: MMFS Version 2

Post by richud »

Hi - Just upgraded from MMFS 1.28 where everything was working nicely to MMFS2 1.49, and shift-m-break no longer boots. I get 'Drive empty'
However if I do *CARD, then *DBOOT it boots the root boot menu (boot.ssd) up ok.
If I move the MMFS2 rom higher than DFS rom I get a long constant beeping noise (several seconds) but then it does come up ok,and shift-break will boot the menu.
(I have a standard BBC B issue 7, built and using MMFSV2/U/MMFS.rom)
Presumably shift-m-break should still work? Am I missing something?
Thanks :)
User avatar
sixedup
Posts: 49
Joined: Wed Feb 12, 2020 2:58 pm
Location: Southampton, United Kingdom
Contact:

Re: MMFS Version 2

Post by sixedup »

Hi, I've just got my old BBC A back in action after a 30-odd year hiatus. After that length of time I'm now essentially a complete novice regarding all things BBC Micro, but I have a background in electronics and software and I'm trying to learn quickly. As part of the renovation I've installed Steve Picton's (IFEL) MMC and ROM/RAM expansion boards and I've been doing some reading before trying to archive my old floppy collection onto SDCard. At this point I'm trying to get my head around the MMFSv1 / MMFSv2 situation before picking a side :)

Would appreciate validation or comments on this summary, along with anything you think I've missed:

MMFSv2 is a "fork" of MMFSv1, maintained by conditional compilation from the same source repository so much of the code in both versions of MMFS is common. Both are implementations of virtual floppies, backed by the SDCard hardware, and both support my "TurboSPI" MMC card. The major difference is how they represent data on the SDCard.

In MMFSv1 there is a single BEEB.mmb file, that is (essentially) a sequence of 512 floppy disk images concatenated together into a contiguous file in the root directory of a FAT formatted SDCard. Those images can be mounted (by numerical index) as virtual floppy disks in drives 0-3. There is no support for multiple .mmb files.

In MMFSv2 there is no .mmb file. Instead the individual disk images (.ssd/.dsd) are accessed directly from the FAT filesystem of the SDCard. Floppy images are mapped to virtual drives by selecting a combination of SDCard directory and floppy image filename. This removes the 512 floppy image limit. Floppy images can be assigned to drives 0 or 2. If the images are double sided they also (automatically) mount the appropriate data to drives 1/3. Otherwise drives 1/3 are not directly mountable.

SDCard media cannot be shared between the two versions without external processing of the data (to build / unpack the BEEB.mmb file).

Both filesystems can be run from my sideways RAM with PAGE set to &E000.

What did I miss?
Cheers
Richard
User avatar
tricky
Posts: 5681
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: MMFS Version 2

Post by tricky »

I'm no expert, but a few minor corrections.
MMFS has 511 disc images and a catalog where disc image 0 would be.
Double sided would be drive 0 and 2 (side 0 and 1 of physical drive 0).
The second physical drive is 1 and 3.
There is a version of v1 and I assume v2 that would put page at &0E00.

I do a menu (system) with the bbcmicro.co.uk archive on it for MMFS v1, v2 and GOTEKs if you want to try it viewtopic.php?f=2&t=16070
User avatar
sweh
Posts: 2469
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: MMFS Version 2

Post by sweh »

tricky wrote:
Wed Jul 21, 2021 2:37 pm
MMFS has 511 disc images and a catalog where disc image 0 would be.
Not quite. There is a catalogue but it's only 8K in size, so disk image 'n' starts at n*204800+8192 (n ranges from 0 to 510, so 511 images)
Rgds
Stephen
User avatar
tricky
Posts: 5681
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: MMFS Version 2

Post by tricky »

:oops:
and I write it out in my menu builder!
User avatar
sixedup
Posts: 49
Joined: Wed Feb 12, 2020 2:58 pm
Location: Southampton, United Kingdom
Contact:

Re: MMFS Version 2

Post by sixedup »

Ok, cool. So got the big picture right, but off on the details. I can live with that for now.

I like the idea of MMFSv2 at the moment, but a bit more reading to do regarding how to create new floppy (.ssd) images as I transfer my old physical floppies to SDCard before I take the leap. I really want to get this right first time in case my floppies don't survive more than one read pass ...
Cheers
Richard
User avatar
Mince
Posts: 154
Joined: Thu Sep 05, 2019 11:25 pm
Location: Cambridge, UK
Contact:

Re: MMFS Version 2

Post by Mince »

Just a note on v1 vs v2 — I use MMFS in two main ways:
  • On my B and Master, I do most of my stuff using a virtual hard disc (Pi1MHz w/ BeebSCSI on the B and GoSDC on the Master), so MMFS is just for shuffling stuff off and on the machines.
  • On my Electron, MMFS is the only thing I have.
For the Electron, I didn't like that I lost two drives as all my volumes are SSDs, so I find v1 best (which is good as that's what's in my ElkSD64 + ElkSD Plus1).

On the B and Master I tried out v2 as I thought it would avoid all the messing about with the BEEB.MMB file and I don't normally need more than one drive mounted. However, the inability to create a new, blank disc from the BBC annoyed me, so I went back to v1. (I also get the minor benefit that I can shift cards between the Electron and BBCs.)

Anyway, just my twopenneth: I'm sure other people will prefer v2 but I think it depends on your use case. Certainly I think bobbi did a good job of getting this working and it'll be a lot simpler for most people.

If you're imaging floppies to SSDs, the same file can be used with either, it's just that with v1 you have to muck about copying it into the BEEB.MMB file.
rharper
Posts: 572
Joined: Sat Sep 01, 2012 6:19 pm
Location: Dunstable, LU6 1BH
Contact:

Re: MMFS Version 2

Post by rharper »

Mince wrote:
Wed Jul 21, 2021 5:17 pm
However, the inability to create a new, blank disc from the BBC annoyed me, so I went back to v1.
Yes, assuming with v1 the 511 slots are not fully occupied you normally will have space for more images that can be created by unlocking and formatting.
I have v2 on one machine where I have loaded Blank1.ssd, Blank2.ssd, etc. in case I need new images.
An advantage of v2 is that you can structure your images into meaningful directories - Games, Utilities, ROMs, Assembler, etc.
Ray
Raycomp
Post Reply

Return to “8-bit acorn software: other”