myne wrote on 2026-05-23, 14:54:

Congratulations! As I said in pm, I always knew this was possible, it's all 1s and 0s. It was always a question of how much effo […]
Show full quote

Congratulations!
As I said in pm, I always knew this was possible, it's all 1s and 0s. It was always a question of how much effort it took.

I haven't looked into your exact memory address scheme at the binary level, but it occurs to me that the pci space is likely to be broadly compatible. Iirc that's somewhere near 4gb.
We're talking kilobytes in a 32+gb world. Even if you incidentally reserve/block off an absurd size range, almost no one would notice or care.
Eg assuming the pci space is 1 bit below 4gb 01000000 00000000 xxxxxxxx xxxxxxxx
would map cleanly. No?
Then you just reserve the appropriate spare pci space and drop the first 16 bits. Modern and legacy both happy.

Thank you!

Yeah, I think the general idea is right; wasting a small alias/decode region is not really the problem on a modern machine. But we should make sure we are talking about the right address space. For the GUS path I'm using, this is mostly PCI/CPU side I/O port space, not normal MMIO near 4GB. The working model isn't really "reserve PCI memory near 4GB and drop upper bits" but rather "reserve/report an unused high I/O port alias and configure the bridge so the ISA side sees the legacy low port"

That said, the spirit of what you're saying matches what seems to work so far: the modern side can use a conflict free alias, while the legacy ISA card remains at its normal address. The address space cost is extremely tiny; the hard part is ensuring and making the bridge decode, DDMA, and IRQ behavior deterministically.

Tiny update: Current Status, ISA Bus Mastering and ISA Memory Windows.

There are four big transport classes: "PIO / port I/O", "ISA slave DMA / 8237 style DMA / DDMA", "ISA bus mastering", and finally "ISA memory windows / memory mapped ISA space". Here's what I have figured out so far:

1PIO: yes, works.
2slave DDMA: yes, works.
3ISA bus master: supported by IT8888, but untested. 
4ISA memory windows: supported by IT8888 positive memory decode, but untested.

I have a plausible sequence ready for testing for both Bus Master and Memory Windows. A 16bit ISA SCSI controller is probably the best candidate for Bus Master, and an ISA VGA card for Memory Windows.

If ISA bus mastering works, that opens up bus mastering SCSI controllers, some high performance NICs, storage adapters, acquisition cards, and other ISA devices that move data by taking control of the bus themselves instead of relying on ordinary 8237 slave DMA.

If ISA memory windows work, that opens up shared RAM NICs, option ROMs, dual port RAM cards, memory mapped industrial cards, framebufferish cards, and other devices that are not purely port IO.

You likely don't need to read these two quotes below, it's here for posterity sake and if you're curious/want to double check me on testing sequences.

ISA Bus Master Test Sequence and Expected Output: wrote:

ISA Bus Master Test Sequence: […]
Show full quote

ISA Bus Master Test Sequence:

Copy code to clipboard

1Allocate physically contiguous low memory, preferably below 16MiB if possible.
2Fill it with a known pattern.
3Configure IT8888 Cfg_50h so that the target memory range is forwarded to PCI.
4Configure the card's DMA/bus master channel.
5Let the ISA card bus master read from or write to that physical address.
6Verify the host buffer changed or was consumed correctly.
7Watch MASTER#, DREQ, DACK#, MEMR#/MEMW#, IOCHRDY, IREQ#/IGNT# on the logic analyzer.

Expected Signal States from ISA Bus Master Test Sequence:

Copy code to clipboard

1DRQn asserted
2DACKn# asserted
3MASTER# asserted by card
4SA/LA driven by card
5MEMR# or MEMW# driven by card
6IOCHRDY stretched by IT8888 if PCI side is not ready
7IREQ# asserted by IT8888
8IGNT# granted by PCI arbiter
9PCI memory cycle appears

ISA Memory Window / Memory-Mapped ISA Space Test Sequence and Expected Outputs / Failures wrote:

ISA Memory Window / Memory-Mapped ISA Space Test Sequence: […]
Show full quote

ISA Memory Window / Memory-Mapped ISA Space Test Sequence:

Copy code to clipboard

1Use an ISA card or test device that actually responds to ISA memory cycles.
2Configure one IT8888 positive memory decode window, Cfg_70h / 74h / 78h / 7Ch.
3Pick a host/PCI-side memory alias and a low ISA-side effective address.
4Map the host-side alias uncached in the Windows driver.
5Perform controlled 8-bit and/or 16-bit reads and writes through the mapped memory window.
6Verify that the ISA card sees MEMR#/MEMW#, not IOR#/IOW#.
7Verify that the ISA address lines match the expected low 24-bit ISA address.
8Verify readback data from a ROM/pattern device or write/read behavior from SRAM.
9Watch MEMR#, MEMW#, SA/LA, SD[15:0], MEMCS16#, IOCHRDY, and optionally NOWS# on the logic analyzer.

ISA Memory Window Setup:

Copy code to clipboard

1Host/PCI-side memory alias: 0xF3000000 - 0xF3003FFF
2Expected ISA-side memory address: 0x000D0000 - 0x000D3FFF
3Size: 16KiB
4Access type: uncached memory reads/writes from the Windows driver

Expected Software Behavior:

Copy code to clipboard

1Read host alias + 0x0000 -> ISA card returns pattern byte for ISA address 0xD0000
2Read host alias + 0x0001 -> ISA card returns pattern byte for ISA address 0xD0001
3Write host alias + 0x0100 = 0x44
4Read  host alias + 0x0100 -> returns 0x44, if using SRAM/test RAM
5
6Boundary test:
7Last byte inside window works.
8First byte outside window is not decoded or is rejected by the driver.

Expected Signal States from ISA Memory Window Test:

Copy code to clipboard

1For read:
2MEMR# asserted
3MEMW# inactive
4IOR#/IOW# inactive
5SA/LA = configured ISA base + offset
6ISA card drives SD[7:0] or SD[15:0]
7IOCHRDY may stretch cycle if needed
8
9For write:
10MEMW# asserted
11MEMR# inactive
12IOR#/IOW# inactive
13SA/LA = configured ISA base + offset
14IT8888 drives SD[7:0] or SD[15:0]
15IOCHRDY may stretch cycle if needed

For ISA memory windows, I need a card or test device that decodes MEMR#/MEMW# in memory space. A simple SRAM/ROM ISA test card might bethe simplest and cleanest proof but a VGA card is much more common.

Possible Failure Modes:

Copy code to clipboard

1Reads all 0xFF: nothing decoded the memory cycle, wrong base/window, or floating bus.
2Reads all 0x00: card not driving data, wrong decode, wrong width, or pull-down/floating behavior.
3IOR#/IOW# pulses instead of MEMR#/MEMW#: accidentally testing port I/O, not memory space.
4Wrong address on SA/LA: IT8888 memory decode register encoded wrong, or confusion between host alias and ISA low 24bit address.
5System hang/fault: host memory alias not reserved/mapped correctly, bridge did not claim the cycle, or PCI side rejected the access.

FWIW, I will likely build another card soon that utilizes my IT8888G to IT8888F adapter PCB. That way I can ensure the G variant works the same as the F variant and develop patches for G in case they differ. (Been working only with the F version so far). Fairly certain they are exactly the same and just in a different package/footprint. I think the next PCB revision will have both G and F footprints directly on the card and connected so there is no need for an extra adapter PCB. Electrically speaking both the G and F are exactly the same from what I remember, the G version is just BGA and requires a 4layer board for signal breakout, but the price per card difference of 2 to 4 layer is largely minimal now.

I just started the DOS version, I have an initial version setup and compiling, and it can execute in dosbox. I have not tested it on real hardware yet. It is not a TSR yet either it's just a testing application.

after DOSBox has a folder mounted with the exe in it, you can run "it8dos info" and it will respond with "IT8888 not found by vendor/device 1283:8888", if on real hardware in DOS "it8dos init" can be ran and DDMA probing should start finding the IT8888.

exe/source is in https://github.com/DartFrogTek/PCIe-PCI-ISA/t … /it8888vdma_dos

I soon would like to investigate patching DOSBox or DOSBox X for real hardware access. Firstly because it would make testing significantly easier on me as I could have a development machine with all of the hardware/software. Secondly it would be amazing to actually use hardware under an emulator. I will try and find out what is exactly needed for that. Ideally it should be as simple as a tiny passthrough modification and all the actual hard part/card stuff is in my driver/application. After some code investigation, It might not be as complicated or large of a patch as I initially thought.

I have not messed around with ISA bus master or ISA memory windows yet, nor have I worked on the new PCB yet.

I did get a chance to mess around with the current prototype card with more DDMA and Port IO testing and both PIO and DDMA seem solid enough to start testing on other cards that are not a PicoGUS. Basically I've done a ton of research and understand other kinds of ISA cards more now and have test sequences for other kinds of ISA cards.

FWIW; My wife has been in contact with several people about the project and we have a phone number for someone with multiple tool and die shops in my area who might be able to help me with access to functional CNC machines with ISA cards. I might have to stop working on the hobby side of the project for a small amount of time while I check out what will be required to support my CNC goal if that pans out. However I'm confident I already have everything needed for that area so I will continue to work on the native DOS side.

I'm not entirely familiar with FreeDOS, but I would like to support both FreeDOS and regular DOS. If anyone has experience with both, is there anything I should know about or would a regular DOS TSR/application likely work on both with little to no changes?

If testing on CNC machines goes well, I will likely either setup a business plan with a bank for a business loan or maybe crowd fund further development that way I can hire people to help me out as my goals are finally exceeding my time. Ideally the plan is to work similar to other open source/open hardware companies. MIT for code and OSHWA-certified hardware designs. You should be able to source your own PCBs and parts, while also able to compile your own drivers/applications. I'm a big fan of old era companies like Tektronix when they had full schematics and full service manuals for their products. I want to mirror that in a modern way, but far more open on both hardware and software. I guess SparkFun/Adafruit would be a good analogy for what I'm aiming for.

I have also made a very rudimentary version of the ITE8888 in Verilog for an FPGA. I have not translated the code into bitstream, and I doubt it compiles but it's a decent enough start for me or someone to finish if and when it's needed at some point. This is the backup for when we inevitably run into ITE8888F/ITE8888G supply issues.

Anyways we are chugging along at full speed now.

Impressive.
I was of the understanding that the industrial cards didn't need dma or anything really and the existing bridges already worked. No?

myne wrote on Today, 02:49:

Impressive.
I was of the understanding that the industrial cards didn't need dma or anything really and the existing bridges already worked. No?

Some do, yes. It depends on what the card actually does.

For a lot of CNC machines and industrial control systems, the ISA card is just port I/O. In those cases, a simple bridge device can be enough, because the software is mostly reading and writing fixed I/O ports. But that is not universal. From people I have talked to in industry, there are several different requirements depending on the machine and the card. Most are port I/O, some require DMA/DDMA, a few require ISA memory windows, and a very small slice require ISA bus mastering.

For example, some plastic injection molding machines use ISA cards that require memory windows. There are other kinds of machines too like a scanning electron microscope. Those cards are not controlled only through I/O ports. These kinds of card expose RAM, ROM, buffers, framebuffers, or memory mapped device registers in ISA memory space. In that case, the CPU is expected to read and write memory located on the ISA card. That is different from DDMA or 8237 style DMA because the DMA engine is not moving the data; the CPU is directly accessing the card through the mapped memory range.

There are also industrial acquisition and control cards that require ISA bus mastering. These are usually more intelligent cards taking in data from sensors or external devices. Instead of the CPU or DMA controller moving every byte, the card takes control of the ISA bus and moves data to or from system memory itself. That is probably the hardest scenario to support behind a modern bridge, but is supported on the ITE8888 chip.

So yes, most only need simple port I/O. But that does not necessarily cover the whole industrial ISA ecosystem. To support the weird/high end/specialty cards, you also need to care about memory windows and in rare cases bus mastering.

An added benefit is that supporting ISA memory windows and ISA bus mastering extends compatibility beyond port I/O and DMA cards. It opens the door to all kinds of useful ISA hardware that people may still want to use on modern machines, including but not limited to: ISA graphics cards, SCSI controllers, IDE/storage controllers, shared memory network cards, frame grabbers, video capture cards, scanner interfaces, tape backup controllers, sound cards with onboard RAM or ROM windows, ROM/flash/EPROM programmer cards, data acquisition cards, logic analyzer interfaces, GPIB/IEEE-488 cards, serial/parallel expansion cards with advanced buffering, and other specialty ISA devices.

Some interesting cards I've heard about are:

An ISA card that attaches to a kind of camera which captures a frame of a CRT screen and is triggered by a few wires that actually connected to the CRT's blanking circuitry. It is used to take pictures of a CRT on a piece of test equipment very similar in principal to an oscilloscope camera. It would take a digitized picture and then send it off to the host PC as a buffer while the last picture is being sent by the host PC to another ISA device which controls a pen plotter that would print a hard copy.

A similarly rare ISA device was used as a kind of flat bed scanner which captured an image of a randomly selected paper after it's been printed on, this was used for quality control and the host PC would get a yes/no message with a dump of memory. Based on the yes or no, the host PC then sends that memory dump off to another ISA device which advanced the machine to let it print the next batch.

Both are very convoluted but oddly still in use today. Even weirder these cards used all 4 kinds of transport types (port i/o, dma, memory window, and bus mastering). I don't understand why they used all 4 transport types, but my guess is external hardware timing? Or I misunderstood the people talking about them and there are multiple ISA cards doing specific things and each has separate requirements. I'm unsure at this moment, however because of this industrial requirement the community gets access to any ISA card they might have.

Possibly a backwards compatibility thing?
Maybe the cards originally ran on 8 bit, and got upgraded to 16 +features?