AltairZ80: Please allow membase to be set beyond the first 64K, at least when CPU is 8086

[vbdasc2]

• Context

I'll be talking about AltairZ80. The function "set_membase" is too strict when checking its inputs for validity, IMHO. For example, it forbids setting membase to values over 0xFFFF. This is perfectly reasonable when the CPU is i8080 or Z80, but not when it's i8086. And yes, i8086 is compatible with MMIO devices, and to support them properly, the whole 1M address space of i8086 should be allowed.

More specifically, the MDSA floppy controller from Northstar uses memory-mapped IO. I want to try to boot some 86-DOS images for Northstar controllers which seem built for MDSA, but to be compatible with these images, the controller needs to be set to membase of 0xFE800, and the function "set_membase" considers this value to be invalid.

• the output of "sim> SHOW VERSION" while running the simulator which is having the issue

sim> show version Altair 8800 (Z80) simulator Open SIMH V4.1-0 Current Simulator Framework Capabilities: 32b data 32b addresses Idle/Throttling support is available Host Platform: Compiler: GCC 4.9.2 Simulator Compiled as C arch: x64 (Release Build) on Jul 18 2023 at 16:5 5:16 Build Tool: make Memory Access: Little Endian Memory Pointer Size: 64 bits Large File (>2GB) support No RegEx support for EXPECT commands OS clock resolution: 1ms Time taken by msleep(1): 1ms OS: Microsoft Windows [Version 6.1.7601] Architecture: AMD64, Processors: 2 Processor Id: Intel64 Family 6 Model 69 Stepping 1, GenuineIntel, Level: 6, Revision: 4501 Processor Name: Intel(R) Pentium(R) 3556U @ 1.70GHz git commit id: 10003052

• how you built the simulator or that you're using prebuilt binaries

Prebuilt binary from https://schorn.ch/cpm/zip/altairz80.zip .

The exact way it's built shouldn't matter, though. I can see the problem in the current source code. I just don't know how to properly fix it.

• the simulator configuration file (or commands) which were used when the problem occurred.

No config files. The following commands:

set cpu 8086
set mdsa enabled
set mdsa membase=fe800


• the expected behavior and the actual behavior

Expected: to work
Actual behaviour:

Invalid argument


• you may also need to provide specific pointers to data files that may be necessary to demonstrate the problem

No such data files

[deltecent]

I am curious how a disk controller with a 16-bit address bus could have a membase above 0xffff. The address decoder on the board has no access to the upper memory addresses and would see 0xfe800 and 0x0e800 as the same address.

[markpizz]

In theory, on such a system, the 'driver' for devices like that could merely perform all I/O to/from a buffer which exists in low memory and then moves the data to/from the appropriate buffer wherever that the transfer is intended.

[vbdasc2]

I am curious how a disk controller with a 16-bit address bus could have a membase above 0xffff.

This is an excellent question that deserves a well thought-out answer. So, let's see... How do we know that this controller has a 16-bit address bus? Northstar MDSA/MDSAD are S-100 controllers, and S-100 is a 24-bit address bus, although in the beginning it was indeed 16-bit. The only reference I could find about Northstar MDSA being 16-bit address is in a manual from 1977 (YMMV, of course), a date when the popular 16-bit CPUs hadn't been released yet. But you see, these Northstar controllers were long-lived, spanning well into the 1980s, and this particular one had several revisions. Later revisions could have 20 address lines or more (or not, but who knows); it would certainly make sense.

But all this is speculation. Let's lay down the facts we have. Seattle Computer Products (SCP for brevity) was a S-100 shop. Its hardware products were S-100 boards and computers made from them. They created a DOS, called 86-DOS, for use with their 8086-based S-100 CPU board. This 86-DOS supported standard SCP hardware, plus floppy controllers from third parties (originally, Cromemco and Tarbell). In late 1980, they also started supporting some "Northstar controller", as is evident from the available sources of the BIOS part of 86-DOS 1.0 and 1.1x. This S-100 controller used memory-mapped IO, in a way consistent with what MDSA does, and supported 5.25'' diskettes with 35x1x10 hard sectors, 256 bytes each. This is again consistent with MDSA. The only visible difference is that 86-DOS used a memory window at 0xFE800 to communicate with the controller, instead of MDSA's default 0xE800. It's easy to imagine that SCP used a late revision of the controller (or the MDSAD, although it doesn't really matter) that was made compatible to 8086 and had 20 address lines or more; else, why write 0xFE800 in the source instead of 0xE800?

The address decoder on the board has no access to the upper memory addresses and would see 0xfe800 and 0x0e800 as the same address.

But you see, the entire discussion above is irrelevant. Because it concerned the real MDSA, while I'm only interested in a virtual MDSA (as it's emulated right now by current AltairZ80), and it's not guaranteed that the emulation is 100% perfect. So, I started AltairZ80, put it in 8086 mode, and created a virtual MDSA at its default address of 0xE800. Then I examined the memory with the mem command. And guess what, the virtual MDSA did respond at me reading 0xE800, showing me its firmware, but it didn't respond when I probed the addresses 0x1E800, 0xFE800 and so on. It displayed only zeros. This means that the virtual MDSA can distinguish addresses 0xE800 and 0xFE800. It means that the virtual MDSA behaves like a real one that has at least 20 address lines. Meanwhile, "set_membase" behaves like the emulated S-100 boards have only 16 address lines. This is an inconsistency at best, and a pedantic one would say that it's a bug.

Anyway, be us pedantic or not, fixing this issue would help AltairZ80 boot several disk images hosted on Bitsavers that it currently can not, and it's an useful thing by itself.