Pretty sure these caching controllers offer MMIO: https://theretroweb.com/expansioncards?cardEx … itemsPerPage=24

But they:

1. are hard to find and expensive to buy
2. frequently have firmware limited with the common CHS limitations
3. they can be out-performed by a standard ISA card when accessing data that isn't in the cache ( cards that support "read-ahead" caching do a little better)

I agree it would be pretty cool to see how a JR-IDE would perform if it was adapted to an AT bus and XT-IDE was enhanced to work with it, but that's a lot of work.

FreddyV's 8bit USB storage driver and his Picomem project do MMIO on an 8 bit bus. A couple years ago, I asked FreddyV about doing a 16 bit card and his response was it would require adding extra wait states for the pi-pico to keep up with the AT bus and the net result would only be added cost, not added performance.

Ah I understand. Sounds like this idea would remain a „dream“. A pity

Marco wrote on 2025-11-28, 17:06:

Ah I understand. Sounds like this idea would remain a „dream“. A pity

Since we are dreaming, it would be really interesting to make an ISA card that uses a CF in "Memory Mode" instead of "True IDE Mode".

Problems:

• Need some sort glue logic to do bank switching, since the CF is going to be larger than your UMB buffer
• Need some sort glue logic to do flow control, because the CF wouldn't necessarily always be faster than the ISA bus
• Some fancy device driver programming added to XTide to make the device visible in DOS
• Getting it to work with a protected mode operating system would be harder still
• Crashing programs could corrupt storage if they overwrite the buffer area

Memory mapped I/O is only faster on 8088/8086 CPU:s which is why the Silicon Valley Computer ADP50(L) is the fastest controller available for XT class machines with those CPU:s. The same can probably be said about the JR-IDE/ISA but those are more or less vaporware (I've never seen anyone mentioning owning/having one of these other than Aitotat when he added support for it in XUB). I added support for the SVC ADP50L but it took five and a half years before someone tested it and could confirm that it works. Patience is a virtue, I guess. 😀

Once you have a CPU supporting string I/O instructions (V20/V30 and 80188/80186 and higher) there is no longer any performance advantage with using memory mapped I/O. Also keep in mind that the memory mapped I/O window takes up valuable address space and must not be cached or very bad things will happen.

Thanks a lot. It’s really interesting to hear different views here in this topic. If this is correct then the message given in another thread (Isa busmaster ide Controller), that when you reach ~3-4mb/s read throuput with Pio you will reach 5mb with MMIO based controllers.

Pls keep in mind that marketing on isa cache controller packages (I think it was BT510) is exactly stating this: 2,5mb linear and 5mb throuput for cached data.

Marco wrote on 2025-11-29, 14:19:

Thanks a lot. It’s really interesting to hear different views here in this topic. If this is correct then the message given in another thread (Isa busmaster ide Controller), that when you reach ~3-4mb/s read throuput with Pio you will reach 5mb with MMIO based controllers.

Pls keep in mind that marketing on isa cache controller packages (I think it was BT510) is exactly stating this: 2,5mb linear and 5mb throuput for cached data.

I had just assumed that it was MMIO because it matched the MMIO performance of video cards and was higher than controllers that I knew were PIO. Sounds like I could be wrong.

You might be right at all. I don’t know. What would speak for MMIO also is that you shouldn’t shadow Isa Cache Controllers. Same as here.

To add another angle, if you're going for max performance, there's also Random Read/Write speeds and file allocation chunk sizes (4k - 64k).

Some high performance applications use random read/write more than sequential... other applications such as video/music/image streaming use linear read/write.

For random read/write, a modern CF card can resolve a lot of the bottleneck.

For linear read/write, changing file allocation chunk sizes from 4KB (default) to 32KB can give more performance. Windows NT may support 64KB chunk sizes.

_Krille_ wrote on 2025-11-29, 13:28:

Once you have a CPU supporting string I/O instructions (V20/V30 and 80188/80186 and higher) there is no longer any performance advantage with using memory mapped I/O. Also keep in mind that the memory mapped I/O window takes up valuable address space and must not be cached or very bad things will happen.

Programmatically, what you write makes sense to me. The 8086 was definitely handicapped when doing PIO. Missing instructions.

I did some additional reading and there might be some advantages on a 486 that were not present earlier--

• Some motherboard chipsets might have fewer ISA wait states when doing MMIO compared to PIO .
• Even though MMIO cannot be cached, a 486 might be able to buffer & burst MMIO writes which it cannot do with PIO requests
• MMIO operations are less disruptive to the 486 CPU instruction pipeline compared to PIO

That said, I have not found any "smoking gun MMIO " code in any of the BIOS files for those ISA caching controllers, so I got no proof that they use MMIO.

And much of the MMIO benefit seems to be for writes, not reads. Makes sense because at the time, the main bottleneck was with "write heavy" VGA drawing patterns, not "read heavy" storage patterns.

Thank you. Happy to continue learning about possible benefits

douglar wrote on 2025-11-30, 17:51:

That said, I have not found any "smoking gun MMIO " code in any of the BIOS files for those ISA caching controllers, so I got no proof that they use MMIO.

If they did, wouldn't they take additional upper memory space beyond that used for their option ROM?

Thinking about ISA shared memory (some ethernet cards) versus bus mastering (some SCSI cards)... it seems the shared memory advantage is the ethernet driver's interrupt handler has random access to the buffer, so it can schedule which incoming packet to service first? Versus with a disk, scheduling is done at the time of issuing requests to the disk, and arrive in-order from the disk.

If we are talking about an IDE disk, they are only doing one command at a time. Queuing only became a thing with native mode sata.

Scsi, on the other hand, can do command queuing and the commands are not necessarily executed and responded to in the order they were issued.

douglar wrote on 2025-11-30, 17:51:

• MMIO operations are less disruptive to the 486 CPU instruction pipeline compared to PIO

This is not true, unless you compare memory mapped I/O with the way port I/O is done on the 808x CPU:s. The 808x CPU:s, lacking string I/O instructions, can only do a single BYTE or WORD I/O at a time and must fetch the instructions to load/store the data together with the actual I/O instructions repeatedly in a loop. This is why it's so slow on these CPU:s. You can reduce this slowness somewhat by unrolling the loop at the cost of increased memory usage but this only reduces the time spent on executing the loop instruction. The instruction fetches still takes time and is, as you put it, disruptive to the instruction pipeline.

When you have string I/O instructions the instruction is only fetched once and it does the load/store together with the I/O operation. You still have a loop but it's all done in hardware using the 'rep' prefix. Just like when you copy a range of memory from one place to another (e.g. memory mapped I/O).