FUZIX项目在Z80-MBC2模拟器上的运行问题解析

问题背景

在尝试将FUZIX操作系统移植到Z80-MBC2硬件模拟器时，开发者遇到了一个启动时内核崩溃的问题。系统在启动过程中会显示"panic: invalid dev"错误，表明存在设备访问问题。最初怀疑是磁盘设备号不匹配导致的，但深入调查后发现实际原因是内存管理单元(MMU)实现存在缺陷。

问题现象

系统启动时会出现两种不同的错误情况：

1. 当磁盘镜像放在设备1时：

128kB total RAM, 64kB available to processes (15 processes max)
Enabling interrupts ... ok.
hda: bdwrite:
panic: invalid dev

2. 当磁盘镜像放在设备0时：

128kB total RAM, 64kB available to processes (15 processes max)
Enabling interrupts ... ok.
hda: hda1 (swap) hda2 bdwrite:
panic: invalid dev

问题分析

最初开发者认为问题出在磁盘设备号上，因为根据磁盘镜像文件名(DS0N01.DSK)的命名规则，系统应该从设备1启动。然而，内核实际上只尝试访问设备0，这表明问题可能不在磁盘设备号上。

进一步调查发现，虽然CP/M 2.2和CP/M 3系统在同一个模拟器上运行正常，但FUZIX系统需要更精确的内存管理单元(MMU)模拟。FUZIX内核在早期就会进行内存分页切换，如果MMU模拟不正确，就会导致系统崩溃。

解决方案

正确的Z80 MBC2 MMU实现应该如下：

fast_u8 Z80Machine::on_read(fast_u16 addr)
{
    uint32_t realAddress = 0;
    if (addr < 0x8000)
    {
        switch (mmuState)
        {
            case 0:
                realAddress = addr | 0x8000;
                break;
            case 1:
                realAddress = addr | 0x18000;
                break;
            case 2:
                realAddress = addr | 0x10000;
                break;
        }
    }
    else
    {
        realAddress = addr & 0x7fff;
    }
    return memory[realAddress];
}

这个实现正确处理了Z80 MBC2的内存分页机制，将16位地址空间映射到更大的物理内存空间。具体来说：

1. 对于地址小于0x8000的内存访问，根据MMU状态选择不同的内存区域：

   • 状态0：映射到0x8000-0xFFFF区域
   • 状态1：映射到0x18000-0x1FFFF区域
   • 状态2：映射到0x10000-0x17FFF区域

2. 对于地址大于等于0x8000的内存访问，直接映射到低32KB物理内存(0x0000-0x7FFF)

经验总结

这个案例展示了在模拟器开发中几个重要的经验：

1. 不同操作系统对硬件模拟的要求可能差异很大。CP/M系统能在不完整的模拟器上运行，不代表更复杂的操作系统如FUZIX也能运行。

2. 内存管理单元的正确模拟对于现代操作系统至关重要，因为这类系统通常依赖内存分页机制。

3. 表面现象(如设备访问错误)可能掩盖了真正的底层问题(如内存管理错误)。

4. 在嵌入式系统开发中，硬件模拟的精确性直接影响软件运行的稳定性。

通过修复MMU实现，FUZIX系统最终能够在Z80-MBC2模拟器上正常启动和运行。这个案例也提醒开发者在硬件模拟过程中需要全面考虑各种硬件组件的精确模拟。