As stated earlier in the thread, several manufacturers sold boards with parallel port headers (and some still do). ECP mode ports requires DMA 3, so these newer chipsets might have some capability.

I realise that modern "southbridge" chipsets don't support it, but what are the hard technical limits that would prevent something like a pico/fpga connected to pcie from achieving full dma support?

How exactly is dma prevented from working?
How does lpc allow it given that "southbridges" are connected via a slightly customised pcie?

Did anyone detail this in the thread?

RayeR wrote on 2025-04-20, 01:03:

Interesting findings. Further stap maybe dump/download UEFI flashrom image, unpack, try to find SMI handler module and disassemble it to see if it interacts with detected IO ports... Maybe intel implemented this with intention but UEFI writers didn't implemented it then as it would be low priority feature that most users don't need.

Yeah that's a great idea. A bit outside my wheelhouse but I can attempt it, though I wouldn't expect anything from this as im not that well versed in reverse engineering.

myne wrote on 2025-04-20, 03:16:

Did anyone detail this in the thread?

Probably, i don't remember, but I'll type up something.

myne wrote on 2025-04-20, 03:16:

I realise that modern "southbridge" chipsets don't support it, but what are the hard technical limits that would prevent something like a pico/fpga connected to pcie from achieving full dma support?

For the pico, an additional interface that acts as a bridge between the Pico/Pico2 and PCIe would be needed. For a Pico approach, you would essentially be using the Pico to control another piece of hardware that has PCIe capabilities, the Pico itself cannot directly implement PCIe. Interestingly the 2018 SD Express adapts the existing SD card and microSD card standard to include PCI Express connectivity. There is a pico powered DaMAgeCard that attacks system memory. I don't see this as directly relevant since requires SD Express but interesting stuff. https://swarm.ptsecurity.com/new-dog-old-tric … sd-card-reader/

In reference to FPGA:
The core challenge is that a FPGA would need to gain access to system memory through PCIe transactions to act as the intermediary between an ISA card and system memory. This requires a ton of knowledge and experience. This is everything I could think of that atm that would need to be done. Start with basic PCIe endpoint design, gradually add I/O operations, implement DMA channels, develop drivers, and build up to full 8237 DMA functionality. Develop core components lioke the PCIe interface block, ISA bus controller, DMA controller simulation, and memory management system. The architecture would need PCIe endpoint core, request translation layer, 8237 DMA controller emulation, and interrupt controller implementation. The main technical challenges is the timing synchronization between fast PCIe and slow ISA buses, DMA memory access limitations (16MB), bus mastering support, and interrupt translation. On top of all this the required hardware design would need a PCIe-capable FPGA, adapter hardware with level shifters, and a well designed pcb.

You'd need a well designed PCIe IP too, which most of the time the ones you'd want to use are cost prohibitive and can't be exposed to an opensource project. I know PCIe IP is free from Xilinx and Intel, but I don't know if they have everything needed or would have to purchase a PCIe core that did. There is also OpenCores and LitePCIe, which might do the trick, again idk haven't looked at them. IMO the real problem is that FPGAs are kind of expensive and PCIe FPGA boards are generally very expensive. It's totally possible though and would be the most future proof. Though once you pick a vendor like say Intel or Xilinx and they stop supplying that fpga or you wanted to swap vendors, it's not as simple as selecting a new one and porting/using it, there's significant work that would need to be done. So you're kind of stuck using a specific device or family of devices from a single vendor. Which isn't that big of a problem just something to know.

That's a massive project btw, this isn't like a weekend warrior project, it's more like full time for 3 to 6 months for a functional prototype, full time for 6 to 12 months for a polished and reliable implementation for an experienced person. If you were just starting out in FPGA development, I could absolutely see this taking someone multiple years of full time development.

myne wrote on 2025-04-20, 03:16:

How exactly is dma prevented from working?
How does lpc allow it given that "southbridges" are connected via a slightly customised pcie?

Modern southbridges (Platform Controller Hubs / PCHs) don't prevent DMA inherently. They simply don't include hardware dedicated to the legacy 8237 DMA controller architecture. This is a design decision rather than a hard technical limitation. Reasons for removal are things like silicon area optimization (removing unused legacy components), power efficiency (fewer components drawing power), and architectural simplification (modern buses use their own DMA methods). LPC bus supports DMA despite connecting to modern chipsets because earlier Intel chipsets specifically retained the LDRQ# (LPC DMA Request) signal line in their design and the LPC bus specification includes explicit mechanisms for signaling DMA operations. The chipset's internal DMA controllers could still respond to these requests.

Hmm.
On the more crazy end of the scale: pcie>pci bridge + pii3x/pii4x.
Would that work in theory?

Pii#x is a pci connected device with very few dual-purpose pins.
It would be much simpler to prototype.
Since pci is a plain shared bus topology, in theory a working bx era board could be physically joined via a pci slot with cables to the pcie bridge and probably only the southbridge enable pin jumped. (no CPU, no ram).
From there, presuming it is detected, the boards isa slots should be accessible for testing.
Probably best to use a CPU-direct pcie lane to remove the modem southbridge from the equation.

If there are no other hard limitations, in theory, the full pii#x capabilities including isa would simply work once configured with standard chipset drivers.

Yes? No?

Let's assume for a minute that this abomination works, there are register compatible emulations of that chipset, so... Would that make an fpga implementation easier? I'm presuming that the emulation has fully virtualised the entire logic - which to me, means that it should be far easier to convert that back into hardware.

Yes? No?

Fintek F85526 update: The PCI-E to ISA chip was finalized and is being manufactured but unfortunately doesn't support DMA or bus mastering. My friend claims that DMA and bus mastering were desired by others too but Fintek didn't bother with them. Guess not enough people/companies needed DMA for it to be worth it. Which does track because not much needs DMA in industrial applications. Shame though.

myne wrote on 2025-04-20, 06:32:

Hmm.
On the more crazy end of the scale: pcie>pci bridge + pii3x/pii4x.
Would that work in theory?

Do you mean like a Modern Motherboard -> PCIe Slot -> PCIe-to-PCI Bridge -> PCI Bus -> Southbridge -> ISA Slots -> ISA Cards?
Anyone know if southbridge chips can be used standalone like that? I thought they needed to be connected to a northbridge. If they need a northbridge It would be quite wild to use ISA -> southbridge -> northbridge -> PCIe. I don't know if north/south bridges can even be used like that. It's basically building a motherboard.

myne wrote on 2025-04-20, 06:32:

Pii#x is a pci connected device with very few dual-purpose pins. It would be much simpler to prototype. Since pci is a plain sha […]
Show full quote

Pii#x is a pci connected device with very few dual-purpose pins.
It would be much simpler to prototype.
Since pci is a plain shared bus topology, in theory a working bx era board could be physically joined via a pci slot with cables to the pcie bridge and probably only the southbridge enable pin jumped. (no CPU, no ram).
From there, presuming it is detected, the boards isa slots should be accessible for testing.
Probably best to use a CPU-direct pcie lane to remove the modem southbridge from the equation.

If there are no other hard limitations, in theory, the full pii#x capabilities including isa would simply work once configured with standard chipset drivers.

Yes? No?

Interesting idea. I have no clue to be honest.

myne wrote on 2025-04-20, 06:32:

Let's assume for a minute that this abomination works, there are register compatible emulations of that chipset, so... Would that make an fpga implementation easier? I'm presuming that the emulation has fully virtualised the entire logic - which to me, means that it should be far easier to convert that back into hardware.

Yes? No?

I don't think it would make it easier, just different.

~

I think PCIe to PCI bridge (maybe PEX8114?) -> PCI to ISA (PC87200/ITE IT8888) would be the most promising? I can't remember if PCIe to PCI bridge -> PCI to ISA bridge was brought up before.

The PC87200 provides everything for ISA to PCI with DMA, and PEX8114 should provide everything for PCI to PCIe. If the PEX8114 was used, it would be relatively low manpower cost to add PCIX too.
Otherwise it might be better to use a regular PCIe to PCI bridge like ITE IT8892E/ITE IT8893E/ASM1083/PI7C9X118SL/XIO2001. This obviously relies on sourcing old chips and finding proper documentation.

PEX8114: https://docs.broadcom.com/doc/pci8114-ba-deta … technical-specs
PC87200: https://www.versalogic.com/wp-content/themes/ … pdf/PC87200.pdf (3.5 PC/PCI DMA Interface Support)
ITE IT8888: https://www.versalogic.com/wp-content/themes/ … ecification.pdf

IT8892E/ITE IT8893E: https://theretroweb.com/chip/documentation/it … b9907145577.pdf
ASM1083: http://www.bitsavers.org/components/asmedia/A … Bridge_2008.pdf
PI7C9X118SL: https://www.mouser.com/datasheet/2/115/PI7C9X … 8SL-1140649.pdf
XIO2001: https://www.ti.com/lit/ds/symlink/xio2001.pdf

Yes. Exactly that.
The pii4x and earlier are simply pci devices.
The northbridge provides the pci and the southbridge is practically an io card in a slot.

It would be: (modern board) CPU > pcie slot > pcie2pci bridge >cable > (old board) pci slot > southbridge >isa.

Basically, the old board for testing purposes would BE the "io card".

myne, dartfrog,

I doubt using a piix4 will work based on me looking into using a VIA 686 a while ago.
While it seems to be perfect to use at first glance, a deeper look showed that some signals needed to come from the northbridge, AFAICR.

I haven't looked deeply at it in a while, but I'm pretty sure this is accurate

myne wrote on 2025-04-21, 09:48:

I haven't looked deeply at it in a while, but I'm pretty sure this is accurate

It is possible that none of the 'CPU Interface signals' page 26 & 27 are actually required.
Someone with more knowledge about the matter might know.
If that is the case then usage of a VIA 82C686A/B could also be possible.

Hmm.

A20m no longer exists
cpurst probably comes from the KB controller or similar (eg alt ctrl del, power management)
ferr and ignne iirc weren't even used by most bx boards
slp, stopclk meh sleep.

intr, nmi, smi are question marks

Anyone bored enough and capable of jerry-rigging the setup (including the critical enable pin) I detailed above?

myne wrote on 2025-04-21, 10:38:

Hmm. […]
Show full quote

Hmm.

A20m no longer exists
cpurst probably comes from the KB controller or similar (eg alt ctrl del, power management)
ferr and ignne iirc weren't even used by most bx boards
slp, stopclk meh sleep.

intr, nmi, smi are question marks

Anyone bored enough and capable of jerry-rigging the setup (including the critical enable pin) I detailed above?

While a one off prototype could likely easily be made to verify if it works.
The biggest problem will likely be finding a source for these components which are no longer produced.
Unless you have already found a source for these chips ?

Sources exist, but I detailed a non-destructive way to join 2 boards for testing.

I'm skeptical to this bridge chaining approach. There are already boards with PCIe2PCI and PCI2ISA bridges without ISA DMA. I think if they can they would already implement it to bridges.

One minor point: those use the southbridge lanes. I'm suggesting cpu lanes.

dartfrog wrote on 2025-04-18, 04:37:

Since no one is selling boards (Unless im wrong, would love a link), It might be worth it to add a dISAppointment shared project on PCBWay/JLCPCB and/or electromaker for ease of purchase for anyone attempting who's not familiar with ordering pcbs from fabs. I doubt they would have the components for assembly, but would make it easier for pcb acquisition.

I was originally planning to do something like this, but I decided not to for four main reasons.

1. The design isn't finalized - I haven't tested the version currently on github, and the previous version requires modification to function correctly.

2. I regularly have people email me asking how to use disappointment boards with their expensive industrial tools and the answer is always DON'T, buy a PICMG setup from someone like Advantech. If I make it too easy to order one then I know I'll get 100x more emails complaining my board broke their 100K$ CNC lathe or whatever.

3. Building a disappointment PC is a terrible idea in general 🤣. I don't want to create the impression that these ridiculous hacked together PCs are in any way useful for actual gaming or productivity.

4. Assembling and installing a disappointment on most motherboards is a huge pain in the arse - if you can figure out all that you can definitely figure out how to order a PCB yourself haha.

I hope my reasons make sense. I might change my mind once we have a bigger database of working motherboards, or we figure out AMD compatibility, etc.

myne wrote on 2025-04-21, 03:23:

Yes. Exactly that. The pii4x and earlier are simply pci devices. The northbridge provides the pci and the southbridge is practic […]
Show full quote

Yes. Exactly that.
The pii4x and earlier are simply pci devices.
The northbridge provides the pci and the southbridge is practically an io card in a slot.

It would be: (modern board) CPU > pcie slot > pcie2pci bridge >cable > (old board) pci slot > southbridge >isa.

Basically, the old board for testing purposes would BE the "io card".

Interesting idea for sure.

weedeewee wrote on 2025-04-21, 07:34:

myne, dartfrog,

I doubt using a piix4 will work based on me looking into using a VIA 686 a while ago.
While it seems to be perfect to use at first glance, a deeper look showed that some signals needed to come from the northbridge, AFAICR.

That's what I thought too about northbridge, but if the piix4 and earlier are really simply pci devices as myne said, it might be possible.

RayeR wrote on 2025-04-21, 13:02:

I'm skeptical to this bridge chaining approach. There are already boards with PCIe2PCI and PCI2ISA bridges without ISA DMA. I think if they can they would already implement it to bridges.

I'm also skeptical, but I attempted to look into it today. While I was searching for PCI to ISA bridge chips, I could only find two (PC87200 and IT8888) that actually claim DMA support, many bridges just don't support DMA. I couldn't find any boards with the PC87200, the IT8888 seems to had a better and longer life. Since the IT8888 has been used quite a bit and with most hardly needing DMA it does make sense why they don't support it. I really think the reason is it simply just costs less to exclude dev time on it and leave it out or use chips that don't even support it. Like why bother implementing something if there is little to no consumer need.

Below is a bunch of research from today trying to validate this PCIe/PCI/ISA bridge theory. I'd love some feedback here, I probably got some stuff wrong. Sorry in advance if I did.

Here's an interesting link I was handed to from my friend. https://www.costronic.com/Ev72p.htm (there's some other info on this costronic site too)

PS: Connect motherboard PPDREQ#, PPDGNT#, SERIRQ signals to PCI-to-ISA bridge card for ISA bus DMA function

This is in reference to a "SH72Pv2 PCI to ISA Bridge Card" using an IT8888. The IT8888's PPDREQ#, PPDGNT# and PC87200's PCPCIREQ#, PCPCIGNT# are what would connect to the PCI's arbitration signals REQ# and GNT# for the PEX8114 (PCIe to PCI bridge). SERIRQ output pin connects to the appropriate INTx pin on the PEX8114 based on its device number (INTA if it's the only or primary device). This basically ties up all the loose end signals that would be required from motherboard.

I see mentioned on the CV72P-ISA PCI to ISA Bridge Card section on that costronic site:

* PS2: motherboard BIOS must support ITE8888, otherwise ISA bus Add-On card can't work, if your BIOS do not support, can use "Device Program" from boot to work, but you must study Specification and to write "Device Program" or SM-boot ROM(24C16) value for yourself.

Since were not directly connecting these PCI to ISA bridges to the host PC via PCI but rather another bridge, it won't be necessary that we would need bios support for IT8888 at all. Yes, IT8888 would require an eeprom for configuration, so it's not as simple as just routing traces from PCIe sockets to PCIe/PCI bridge to PCI/ISA bridge to ISA socket. The PC87200 seems to be configured by using hardware based configuration through strapping pins and has specific configuration pins that need to be pulled high or low during power up. I think this suggests we should try to use the IT8888 instead of the PC87200?

The costronic site also talks about a combination of a W83628F + W83629D which W83628F and W83629D together form a complete set for the PCI-to-ISA bridge. The datasheet claims DMA support. However, W83628F is a PCI to ISA bus conversion IC. W83629D is a condensed centralizer IC for IRQ and DMA control. This is a more complicated setup but worth knowing about.
W83628F + W83629D: https://www.costronic.com/W83628_W83629.PDF

Some extra information about PCIe/PCI/ISA bridging with PEX8114, PC87200, and IT8888:
We'd need to use the Forward Bridge of the PEX8114, since we want an ISA card to be routed to the PCIe on host. (Reverse bridge would be like adding PCIe card to ISA host and not what we want.) All three devices are designed for 33 MHz PCI, so that simplifies clock domain concerns. ISA bus will need a stable clock and can be provided by the PEX8114 in PCI clock master mode. Both PC87200 and IT8888 support subtractive decode. This means unclaimed PCI cycles (legacy ISA I/O or memory mapped) can be passed down to the ISA bridge. Essentially without subtractive decode ISA devices would never receive I/O or memory accesses coming from the CPU via the PCI/PCIe hierarchy. So an ISA I/O read like inb(0x3F8) gets: Sent from the CPU down the PCIe root complex is routed via PEX8114, ignored by PCI devices, subtractive decode kicks in and forwarded by IT8888/PC87200 to the ISA bus.

There's probably something I'm missing here, but on the surface the PCIe/PCI/ISA bridging seems possible. It's likely the IT8888 is better since it supports PC/PCI DMA and Distributed DMA (DDMA), where the PC87200 only supports PC/PCI DMA. So with the configuration setup of these PCI/ISA bridges and DDMA, I'd say it's probably worth further pursuing IT8888 and PEX8114 by reading the docs more closely.

rasteri wrote on 2025-04-21, 15:14:

I was originally planning to do something like this, but I decided not to for four main reasons. […]
Show full quote

I was originally planning to do something like this, but I decided not to for four main reasons.

1. The design isn't finalized - I haven't tested the version currently on github, and the previous version requires modification to function correctly.

2. I regularly have people email me asking how to use disappointment boards with their expensive industrial tools and the answer is always DON'T, buy a PICMG setup from someone like Advantech. If I make it too easy to order one then I know I'll get 100x more emails complaining my board broke their 100K$ CNC lathe or whatever.

3. Building a disappointment PC is a terrible idea in general 🤣. I don't want to create the impression that these ridiculous hacked together PCs are in any way useful for actual gaming or productivity.

4. Assembling and installing a disappointment on most motherboards is a huge pain in the arse - if you can figure out all that you can definitely figure out how to order a PCB yourself haha.

I hope my reasons make sense. I might change my mind once we have a bigger database of working motherboards, or we figure out AMD compatibility, etc.

1 and 4: Ah this makes more sense.

2: This is a big reason why I'm interested in this project, I know the industrial sector is interested in something like this and it would be a massive opportunity to provide a hobbyist solution to a decently large problem. Not that I agree any person in industry should be using something like this, as like you said it's better to use PICMG devices for them. However there is a non-insignificant amount of hobbyists who have cnc machines and random esoteric ISA cards from the secondary market. When reviving these second hand cnc machines that have ISA DMA, having a potential solution is a good intentioned idea. A lot of times, they end up completely gutting them and just rebuild them from the ground up, which tends to be more expensive than the old machine itself. Not to mention sometimes they just end up being scrapped because of limited solutions and the scope/cost of rebuilding from scratch. To me, that's just heart breaking, I love cnc and hand writing gcode was one of my first jobs, so this is close to home for me. So if we could revive already dead machines cost effectively, it's a two birds one stone kind of thing. On the esoteric ISA card topic, them potentially only having to develop a driver for their device makes the usage plausible in a modern system. This is a triple kill scenario and imo all this combined makes it worth it to pursue.

3: Lol I totally agree it's a terrible idea, but it's so interesting it's even remotely possible. A long time ago, modifying your PC was something a lot just did like wire wrapping custom ISA cards, this really harkens back to that era.

Yes the reasons absolutely do , thanks for expanding on this.

Intel are in a tight spot right now.
I don't know any they refuse to make a legacy soc.
It's all ip they already own.

myne wrote on 2025-04-22, 03:23:

Intel are in a tight spot right now.
I don't know any they refuse to make a legacy soc.
It's all ip they already own.

Their tight spot isn't really going to be solved by spinning up a fab to make niche SOCs

dartfrog wrote on 2025-04-22, 03:10:

2: This is a big reason why I'm interested in this project, I know the industrial sector is interested in something like this and it would be a massive opportunity to provide a hobbyist solution to a decently large problem. Not that I agree any person in industry should be using something like this, as like you said it's better to use PICMG devices for them. However there is a non-insignificant amount of hobbyists who have cnc machines and random esoteric ISA cards from the secondary market. When reviving these second hand cnc machines that have ISA DMA, having a potential solution is a good intentioned idea. A lot of times, they end up completely gutting them and just rebuild them from the ground up, which tends to be more expensive than the old machine itself. Not to mention sometimes they just end up being scrapped because of limited solutions and the scope/cost of rebuilding from scratch. To me, that's just heart breaking, I love cnc and hand writing gcode was one of my first jobs, so this is close to home for me. So if we could revive already dead machines cost effectively, it's a two birds one stone kind of thing. On the esoteric ISA card topic, them potentially only having to develop a driver for their device makes the usage plausible in a modern system. This is a triple kill scenario and imo all this combined makes it worth it to pursue.

I hear you - I understand that the PICMG/PC104/whatever route can be expensive for hobbyists.

Personally, I feel like if I was in that situation I'd probably go down the route of building an old PC specifically to run the machine. Socket A and Socket 370 motherboards with ISA slots are cheap and plentiful, and even if you have to run DOS you can still use FTP/MS network client to transfer gcode files over network from your modern PC.

But I totally get the appeal of wanting to run old hardware on new PCs - I mean that's why I started this project in the first place 😀

BTW I have been looking into making an IT8888-based PCI-to-ISA adapter card. It would be more aimed at pre-ICH5 (I think?) motherboards that still have the PPDREQ (etc) signals though.

rasteri wrote on 2025-04-22, 16:07:

BTW I have been looking into making an IT8888-based PCI-to-ISA adapter card. It would be more aimed at pre-ICH5 (I think?) motherboards that still have the PPDREQ (etc) signals though.

I see this being a better idea and approach than outright building a full PCIe to PCI to ISA chain device for now.

If we can create a PCI to ISA adapter card that can do DMA with IT8888, ideally without bios support using the IT8888 eeprom configuration; then it's possible that using a PCIe/PCI adapter card like the StarTech PEX1PCI1 might allow the custom PCI/ISA card to work since both the IT8888 and PEX1PCI1 provides bus mastering support.

Even if it didn't work with a PCIe/PCI card, building a solid IT8888 PCI/ISA card first would provide exceptional strides into making a full PCIe to PCI to ISA chain device ourselves.

I say we go for it.