MMFS Version 2

[Coeus]

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.

[hoglet]

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]

FEDC on the Master should be fine.

Ok, I have pushed a commit that implements that on the Master.

[hoglet]

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]

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.

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]

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]

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]

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.

[hoglet]

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]

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.

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.

[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.

[hoglet]

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

[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]

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]

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.

[hoglet]

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]

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]

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]

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