dartfrog wrote on 2025-04-27, 04:07:

I have the first pass of the schematic largely done. I have sourced all the symbols and footprints. I tried following the Costronic schematic as close as possible. I left out BCLK cap, FLASHROM, and ROMCS/NOGO jumpers for now. Other than that it's basically the same. I have yet to mess around with routing/placement of anything. I selected footprints/components that would be easy to hand solder, like 1808 caps and rest through hole components. You're welcome to critique and/or make changes. You can submit a pull request for the schematic/board via link in sig if you want. (ISA8888_KiCAD folder.)

A couple of thoughts for my intended use case (i.e. converting Pentium 4 or Athlon motherboards to use ISA, rather than the PCIe stuff) -

1. You haven't routed PPDREQ and PPDGNT, I assume those will eventually go to headers somewhere?

2. Related to 1. - I would suggest having a jumper option to route the REQ and GNT pins on the PCI port to PPDREQ and PPDGNT (instead of IREQ and IGNT). On ICH southbridges up to ICH4 there is a register that can change some of the GNT/REQ pins to act as PPDREQ/PPDGNT. This would mean that you wouldn't have to find PPDREQ and PPDGNT on the motherboard anywhere, but it would mean you'd have to find which PCI slot on the motherboard had the relevant signals (possibly just by trial and error).

rasteri wrote on 2025-04-29, 11:01:

A couple of thoughts for my intended use case (i.e. converting Pentium 4 or Athlon motherboards to use ISA, rather than the PCIe […]
Show full quote

dartfrog wrote on 2025-04-27, 04:07:

I have the first pass of the schematic largely done. I have sourced all the symbols and footprints. I tried following the Costronic schematic as close as possible. I left out BCLK cap, FLASHROM, and ROMCS/NOGO jumpers for now. Other than that it's basically the same. I have yet to mess around with routing/placement of anything. I selected footprints/components that would be easy to hand solder, like 1808 caps and rest through hole components. You're welcome to critique and/or make changes. You can submit a pull request for the schematic/board via link in sig if you want. (ISA8888_KiCAD folder.)

A couple of thoughts for my intended use case (i.e. converting Pentium 4 or Athlon motherboards to use ISA, rather than the PCIe stuff) -

1. You haven't routed PPDREQ and PPDGNT, I assume those will eventually go to headers somewhere?

2. Related to 1. - I would suggest having a jumper option to route the REQ and GNT pins on the PCI port to PPDREQ and PPDGNT (instead of IREQ and IGNT). On ICH southbridges up to ICH4 there is a register that can change some of the GNT/REQ pins to act as PPDREQ/PPDGNT. This would mean that you wouldn't have to find PPDREQ and PPDGNT on the motherboard anywhere, but it would mean you'd have to find which PCI slot on the motherboard had the relevant signals (possibly just by trial and error).

1. Yes, on my local copy I've done exactly that.

2. That's interesting. Of course we can do that. Just to make sure I understand correctly.

The IT8888 has two different DMA mechanisms:

• DDMA (Distributed DMA) - uses IREQ#/IGNT#
• PC/PCI DMA (PPDMA) - uses PPDREQ#/PPDGNT#

Normal Operation (Both DDMA and PPDMA Available)

• The IT8888 has one pair of each: IGNT#/IREQ# and PPDGNT#/PPDREQ#.
• PCI slot GNT#/REQ# connects to IT8888 IGNT#/IREQ# for DDMA operations.
• Motherboard PPDGNT#/PPDREQ# connects to IT8888 PPDGNT#/PPDREQ# for PPDMA operations.

Alternative Operation (PPDMA via PCI Slot)

• PCI slot is configured to provide PPDGNT#/PPDREQ# signals instead of standard GNT#/REQ#.
• PCI slot PPDGNT#/PPDREQ# connect to IT8888 PPDGNT#/PPDREQ#.
• IT8888 IGNT#/IREQ# would be left unconnected, meaning DDMA functionality would not be available but allows for PPDMA via PCI Slot.

So you want a jumper configuration to remove IT8888 IGNT#/IREQ# connections to PCI slot's GNT#/REQ# and redirect the PCI slot's now PPDGNT#/PPDREQ# to IT8888 PPDGNT#/PPDREQ#?

~

I did a routing test of the ground, power rails and some signals. This is no means perfect or even final. I'll definitely be changing some footprints (like resistor networks, and some other stuff) and I'll likely re-organize the board to optimize trace routes. Just figured I'd keep you all up-to-date on the progress.

dartfrog wrote on 2025-04-29, 21:41:

The IT8888 has two different DMA mechanisms: […]
Show full quote

The IT8888 has two different DMA mechanisms:

• DDMA (Distributed DMA) - uses IREQ#/IGNT#
• PC/PCI DMA (PPDMA) - uses PPDREQ#/PPDGNT#

Normal Operation (Both DDMA and PPDMA Available)

• The IT8888 has one pair of each: IGNT#/IREQ# and PPDGNT#/PPDREQ#.
• PCI slot GNT#/REQ# connects to IT8888 IGNT#/IREQ# for DDMA operations.
• Motherboard PPDGNT#/PPDREQ# connects to IT8888 PPDGNT#/PPDREQ# for PPDMA operations.

Regarding DDMA mode, does the chipset itself also need to support that for it to work?

AFAIK ICH never supported that, and I don't remember seeing other chipsets of the AGP 8x/PCIe 1.x period ever advertised such support...

LSS10999 wrote on 2025-04-30, 03:40:

Regarding DDMA mode, does the chipset itself also need to support that for it to work?

AFAIK ICH never supported that, and I don't remember seeing other chipsets of the AGP 8x/PCIe 1.x period ever advertised such support...

We are basically operating on a theory at the moment until we can test it directly.

As I understand it, there is no need for DDMA support in the chipset itself. I asked someone with significant motherboard design experience, and they said, "not that I remember, all that should be needed is PCI Bus Mastering support." That matches what I assumed, but I still have some reservations, since no one has been able to confirm this with hard documentation or real world proof yet.

It was explained to me further that "DDMA's job is to make ISA DMA look like PCI bus mastering under the hood." Chipsets supporting DDMA required a DDMA controller integrated in the Southbridge/PCH. But in the case of the IT8888, the DDMA controller is embedded within the bridge chip itself. That implies the chipset doesn't need to be DDMA aware; the chipset just needs to support standard PCI bus mastering. This is a reasonable assumption, but again it's not been proven.

I mean... There's always the piggy-back mongrel I described a page or so back.
With your board and a pentium/p2 era board it should be possible to jump the pci slots together (solder wires to the slot pins from behind?), make sure there's power to the southbridge, and see if the southbridge can be detected at all. Just seeing the chipset in device manager would be enough for step 1.

If it can... Then we're cooking!

dartfrog wrote on 2025-04-29, 21:41:

So you want a jumper configuration to remove IT8888 IGNT#/IREQ# connections to PCI slot's GNT#/REQ# and redirect the PCI slot's now PPDGNT#/PPDREQ# to IT8888 PPDGNT#/PPDREQ#?

Exactly. It won't work for every motherboard, but it will hopefully make installation easier for those that happen to have the correct PCI pin configuration.

http://support.fccps.cz/download/adv/frr/PCI1 … CI104_case.html
That has some interesting technical details

myne wrote on 2025-04-30, 05:50:

I mean... There's always the piggy-back mongrel I described a page or so back.
With your board and a pentium/p2 era board it should be possible to jump the pci slots together (solder wires to the slot pins from behind?), make sure there's power to the southbridge, and see if the southbridge can be detected at all. Just seeing the chipset in device manager would be enough for step 1.

If it can... Then we're cooking!

If the card fails, at least we have another option via Piix4 to mess around with. However your post below is quite interesting!

myne wrote on 2025-04-30, 11:10:

http://support.fccps.cz/download/adv/frr/PCI1 … CI104_case.html
That has some interesting technical details

Hey that's awesome. From what I skimmed, this seems to actually confirm the theory about the chipset not needing DDMA! It doesn't outright say it, but with some deduction we can confirm the theory is valid.

"Note that the ICH8M provides 3 channels of REQ+GNT, but it would seem that 1 channel out of those 3 goes to the IT8888 - at least that bridge does have the corresponding pins. I'm not entirely sure they're mandatory, if the IT8888 isn't allowed to perform legacy ISA DMA anyway (the ICH south bridges from ICH5R above lack some further signals needed for that, PPDREQ+PPDGNT I guess)."

I'm not sure the author understood that the IT8888 has both DDMA(use of PCI REQ/GNT) and PPDMA(use of PPDREQ+PPDGNT), since they were confused by the REQ/GNT connections to IT8888. By the ICH8M not providing PPDREQ+PPDGNT, the IT8888 must have been using it's DDMA controller since the chipset did not contain a DDMA controller and is not providing PPDMA signals. We can confirm the IT8888 was using DDMA operation via this part:

"I also knew from the start that the two Realteks on the MIO-3130 would be unable to run DMA properly on just one set of REQ+GNT (or would they?) and just one IDSEL signal"

So how was DMA being used there if there's no other mechanism for DMA unless it's PCI Bus Mastering? Which is how the IT8888 works. It looks like DDMA (PCI Bus Mastering) from IT8888 will indeed work as theorized! 😀 Exciting stuff. (Hope I'm not misinterpreting, but it really does seem like this approach is valid.)

rasteri wrote on 2025-04-30, 09:41:

Exactly. It won't work for every motherboard, but it will hopefully make installation easier for those that happen to have the correct PCI pin configuration.

Awesome, I have included it. This is a very good addition. Between the three options the card should support a large number of boards. Even more boards with PEX811x PCI to PCIe card.

Took me a while to figure out some problems and get freerouter to run.

The extra blocks you added to the pci edge. Yeah... they gotta go. It spazzes out freerouter.
I did try, but then worked around the power with fill zones.
Added notional tracks and vias to every pin on the ite to help the program.
I notionally did a 4 layer, but made the middle 2 5x more 'expensive' so that the few traces that do need another layer can be bridged with a wire/0ohm

Anyway, take a look. It's not really the same as yours, but perhaps inspiration.

There's some very interesting information here, particularly the attached documents:
DDMA and PCPCI for Low IQ Individuals (Me included)

Also:

2.1.1.1 Distributed DMA […]
Show full quote

2.1.1.1 Distributed DMA

Distributed DMA is not supported in any of Intel’s I/O Controller Hub variants.

2.1.1.2 PC/PCI DMA

The PC/PCI DMA protocol is supported on all I/O Controller Hubs from ICH to ICH5
(excluding 6300ESB). These parts have dedicated Request and Grant signals –
REQ[A:B] and GNT[A:B] – to implement the hardware aspect of the protocol.

From ICH6 onwards these signals have been removed and, therefore, these devices
no longer support the PC/PCI protocol. As a result, it is no longer possible to support
ISA DMA or Bus Master transactions using a PCI/ISA bridge. A system designer should
be aware of this limitation before using such a bridge.

The ITE8888 can work in PC/PCI or DDMA mode. PC/PCI mode are the preferred method if the chipsets have support for it as no software needs to be changed.

Regarding DDMA,

I may be "worng" but I think the ITE8888 is not a "master DDMA agent" but a "slave DDMA controller". The ITE8888 can be configured to make its internal 8237s to become available somewhere in the IO address space and the "master agent" in the motherboard would then automatically trap and forward any access to the usual AT 8237s range to either the ITE8888 or any other slave controller in the system, maybe in some SuperIO chip.

In practice, very few motherboards have a DDMA host/master but, if the system is running DOS "inside" an extended memory manager, it should be possible to develop a driver that traps the accesses to the 00h~1Fh, C0h~DFh and 8Xh~9Xh ranges and forwards them to whatever address ranges are configured for the ITE8888. Similar to what SBEMU and other software does.

myne wrote on 2025-05-01, 14:56:

Took me a while to figure out some problems and get freerouter to run. […]
Show full quote

Took me a while to figure out some problems and get freerouter to run.

The extra blocks you added to the pci edge. Yeah... they gotta go. It spazzes out freerouter.
I did try, but then worked around the power with fill zones.
Added notional tracks and vias to every pin on the ite to help the program.
I notionally did a 4 layer, but made the middle 2 5x more 'expensive' so that the few traces that do need another layer can be bridged with a wire/0ohm

Anyway, take a look. It's not really the same as yours, but perhaps inspiration.

Yeah I was just messing around with powers and grounds, all that was going to be moved to the 2nd/3rd layer. Since I am going to change some stuff I was just going to redo everything. I just haven't gotten around to it yet.

Ideally the card would be a 6 layer board [signal, ground, (+3.3 +5), (+12 -12 -5), ground, signal], but 6 layer is just prohibitively expensive. It will likely be a 4 layer [signal, ground, power, signal]. I was toying with the idea of a 2 layer board but it would be so large (space for routing 364 traces) that the cost of jumping to a smaller 4 layer is actually cheaper (pcbway quote). Also there are space constraints with that large of a card too. I was thinking about making two smaller separate 2 layer boards and attach them together with pins/sockets. Which might be the cheapest option. If I did two separate 2 layer boards I could potentially CNC route it myself. CNC routing a prototype myself would also significantly reduce cost for me as I wouldn't have to pay out of pocket for pcbs yet (pcbs are the most significant cost). I've just never done QFP on the CNC and don't know if it's possible on mine.

What sucks is this card is going to be expensive no matter the way stack, route, or cut it. I am getting various quotes from US pcb manufacturers near me (I have like 6 different places that offer pcb services within 30 mins of me) and it's basically the same cost as pcbway/jlcpcb by the time you calculate shipping from china. So it's not a cheap board by any means (it's the size of the pcb that's the real cost inflator). I haven't decided anything yet, just trying to figure out how to make it as cheap as possible, and reduce the number of pcb revisions (like not making both a 2x2layer and 4 layer). FWIW It's possible to get all SMD assembled from pcb manufacturer, you just need to source the various SMD components and hand the component stock over. Only through hole would need to be added by hand. All of this kind of doesn't matter yet till I get the IT8888 in and can confirm the operation of it. I am just waiting on AT24C02N and IT8888 right now.

Thanks though, I will check it out.

EduBat wrote on 2025-05-01, 19:54:

There's some very interesting information here, particularly the attached documents: DDMA and PCPCI for Low IQ Individuals (Me i […]
Show full quote

There's some very interesting information here, particularly the attached documents:
DDMA and PCPCI for Low IQ Individuals (Me included)

Also:

2.1.1.1 Distributed DMA […]
Show full quote

2.1.1.1 Distributed DMA

Distributed DMA is not supported in any of Intel’s I/O Controller Hub variants.

2.1.1.2 PC/PCI DMA

The PC/PCI DMA protocol is supported on all I/O Controller Hubs from ICH to ICH5
(excluding 6300ESB). These parts have dedicated Request and Grant signals –
REQ[A:B] and GNT[A:B] – to implement the hardware aspect of the protocol.

From ICH6 onwards these signals have been removed and, therefore, these devices
no longer support the PC/PCI protocol. As a result, it is no longer possible to support
ISA DMA or Bus Master transactions using a PCI/ISA bridge. A system designer should
be aware of this limitation before using such a bridge.

The ITE8888 can work in PC/PCI or DDMA mode. PC/PCI mode are the preferred method if the chipsets have support for it as no software needs to be changed.

Regarding DDMA,

The attachment Screenshot_2025-05-01_19-48-43.png is no longer available

The attachment Screenshot_2025-05-01_20-13-48.png is no longer available

I may be "worng" but I think the ITE8888 is not a "master DDMA agent" but a "slave DDMA controller". The ITE8888 can be configured to make its internal 8237s to become available somewhere in the IO address space and the "master agent" in the motherboard would then automatically trap and forward any access to the usual AT 8237s range to either the ITE8888 or any other slave controller in the system, maybe in some SuperIO chip.

In practice, very few motherboards have a DDMA host/master but, if the system is running DOS "inside" an extended memory manager, it should be possible to develop a driver that traps the accesses to the 00h~1Fh, C0h~DFh and 8Xh~9Xh ranges and forwards them to whatever address ranges are configured for the ITE8888. Similar to what SBEMU and other software does.

I read that post, thanks for sharing it here.

I could be wrong, but I don't think it matters that the IT8888 has what the datasheet calls "slave" DMA controllers. While it's true that the chip includes 8237 compatible slave channels, I believe this just means they follow the classic ISA DMA protocol on the ISA side; not that they require an external "master DDMA agent" in the system to function. By the block diagram and the way IT8888 itself acts as a PCI bus master when handling DMA, it seems to be internally servicing the ISA DRQ/DACK requests and then initiating memory transfers using standard PCI bus mastering. From the host system's point of view, it's just a PCI device performing direct memory access. I'm not sure it needs to understand or be involved in DDMA, ISA, or 8237 behavior at all.

The only way to confirm this either way outside of testing the chip is potentially via the "Distributed DMA R6.0" spec, which is non-existent online as far as I can tell. If anyone has it, that would be insanely beneficial here, though I suspect it's from PCI-SIG, probably requires $$$ and can't be posted publicly.

dartfrog wrote on 2025-05-01, 22:25:

The only way to confirm this either way outside of testing the chip is potentially via the "Distributed DMA R6.0" spec, which is non-existent online as far as I can tell. If anyone has it, that would be insanely beneficial here, though I suspect it's from PCI-SIG, probably requires $$$ and can't be posted publicly.

This one? Posted by @furan in the topic I linked to?

download/file.php?id=130576

EduBat wrote on 2025-05-02, 00:24:

This one? Posted by @furan in the topic I linked to?

download/file.php?id=130576

Ah, very nice. Yes, and thank you! I haven't had a chance to read the entire thread yet, only your OP.

After reviewing the DDMA specification, the "master DDMA agent" appears to be required only in systems where legacy DMA I/O accesses must be centralized and routed to distributed DMA slave engines, as described in Section 3.2. The specification explicitly states that "When implementing this specification, there must always be at least one device in the system that supports the DMA Master function. It must translate all the PCI I/O reads and writes to the legacy DMA I/O addresses into DMA Slave I/O reads and writes." The specification further clarifies that "DMA Slave devices must only respond to the slave address assigned to them and not any legacy DMA address," which necessitates a master controller for translation. In contrast, devices like the IT8888 integrate both functions and eliminate the need for a separate master DDMA agent. The IT8888 provides "six I/O positively decode spaces" that allow it to directly claim legacy DMA addresses. It also "will issue PCI cycle for ISA bus master cycle and DDMA memory cycle if those accesses are forwarded to PCI bus," functioning as its own bus master.

According to the DDMA specification, a traditional DDMA system requires:

• DMA Slaves that cannot be PCI bus masters
• DMA Slaves that do not decode legacy I/O addresses
• A separate DMA Master to "take control this cycle by driving DEVSEL# active, driving its PCI REQ pin active, and issuing a PCI retry to terminate this cycle"

In contrast, the IT8888:

• Acts as a PCI bus master by asserting "IREQ# to PCI bus arbiter if the DACKn# source is DDMA"
• Uses "positively decode spaces" to claim legacy DMA addresses directly
• Drives DEVSEL# when it recognizes legacy DMA addresses on the PCI bus that it's configured to claim through positive decode.

The IT8888 does drive its REQ pin active during DMA operations. It doesn't need to issue a PCI retry in the same context as described for the DDMA Master in the spec, since it directly handles legacy I/O accesses rather than needing to retry and redistribute them to separate slave devices. I believe this confirms that the IT8888 handles both legacy I/O response and DMA execution internally without requiring the external master agent coordination described in the DDMA specification. Basically the IT8888's DDMA slave controller is only a "slave" in ISA protocol terms (that it responds to DRQ), but in PCI terms, it is a full bus master, and handles the entire DMA lifecycle, from I/O register mapping to memory access.

I think the key takeaway is that the IT8888 doesn't describe itself as a DDMA master since it doesn’t coordinate or redirect DMA requests to other devices. Instead, it is a self contained DDMA slave that also performs bus mastering, making the need for a separate master agent obsolete.

I could be wrong here, this is just how I'm understanding it.

Wait, how you suppose to catch DMA init (segment/offset/length/channel_no) ?

1OUT 0x01,al 

-like stuff.

Programs will try to access the legacy DMA range IO range to configure, for example, the DMA channels for the soundblaster (or compatible devices) in order to play sound. They will use out instructions, like the OUT 01,ah above. The "legacy DMA" ranges are 00h~1Fh, C0h~DFh and 8Xh~9Xh.

An IT8888 in a PCI card would live behind a PCI bridge, in a secondary bus. In my case, below, that would be the "PCI Bridge" and the IT8888 would be a device on bus 6.

The PCI bridge is in [Subtractive decode] mode which means, according to the datasheet of the ICH10:

Subtractively decode any 16-bit I/O address "not claimed by another agent". This would be the perfect solution as the accesses to the legacy range would be forwarded down bus 6 and would be seen by the IT8888.
However there is a big problem. The ISA bridge also has DMA controllers so it will claim those accesses. The PCI bridge will not forward them. I went up and down the datasheet but could not find any way to disable the DMA controllers in the ISA bridge.

One idea and possible solution would be to configure the PCI bridge to positively forward the legacy range to the secondary bus, in the hope that the IT8888 would respond faster, however that presents another problem:

You only have one window and the windows follow a 4K alignment. If you define a window starting at IO address 0000h, even if it's only 256 bytes to cover the whole legacy DMA range you would also pick up other devices, like the keyboard, the RTC and the interrupt controllers.

Assuming all of this is correct, the only solution I see would be something similar to SBEMU where some software would trap accesses to the legacy DMA range and send them over to some other address configured purposefully for the IT8888.

(This is how I see it, I may the wrong obviously, this is all a theoretical exercise for me, from reading the documentation...)

I would assume that any os/bios capable of recognising an isa device has the smarts to deal with that.
My assumption is that the entire first 16mb are basically blacklisted these days just to avoid any potential conflict. It's such a trivially small range to block any time after the roughly Win2k era.

EduBat wrote on 2025-05-02, 15:08:

The PCI bridge is in [Subtractive decode] mode which means, according to the datasheet of the ICH10:
Subtractively decode any 16-bit I/O address "not claimed by another agent".

I can't find any documents stating about 0x00-0xFF range substractive decoding rerouting, instead I saw directly opposite - those first 255 ports are hardwired to the PCH and only can be trapped in some undocumented way via SMM-voodoo (not counting VM-way).

vsharun wrote on 2025-05-02, 16:54:

EduBat wrote on 2025-05-02, 15:08:

The PCI bridge is in [Subtractive decode] mode which means, according to the datasheet of the ICH10:
Subtractively decode any 16-bit I/O address "not claimed by another agent".

I can't find any documents stating about 0x00-0xFF range substractive decoding rerouting, instead I saw directly opposite - those first 255 ports are hardwired to the PCH and only can be trapped in some undocumented way via SMM-voodoo (not counting VM-way).

Yes, correct, in the case of the ICH10 southbridge, the "first 255ports" are hardwired/claimed by the LPC Interface bridge where the legacy devices(DMA, RTC, Interrupt, APM controllers) reside.
Instead of "first 255ports", it's better to use the term Fixed I/O Address Ranges for which the datasheet says "positively decoded...in medium speed":

Regarding the need for SMM / Voodoo, it is not needed. Quoting from the SBEMU readme:

SBEMU is a protected mode TSR program/driver that aims to emulate the legacy ISA Sound Blaster hardware on PCI sound cards, it u […]
Show full quote

SBEMU is a protected mode TSR program/driver that aims to emulate the legacy ISA Sound Blaster hardware on PCI sound cards,
it uses the port trapping features of a v86 monitor & DPMI host to trap SB ports (i.e. 220h), and ISA DMA controller ports to
provide a 'virtual' SB devices for DOS programs.
.
.
.
Software:
a) MSDOS 6.22 or higher, or FreeDOS.
b) a v86 monitor - normally an Expanded Memory Manager(EMM like EMM386) that support port trapping, currently EMMs
that support port trapping and recognized by SBEMU:
Quarterdeck QEMM
JEMM386/JEMMEX with QEMM port trap emulation (QPIEMU.DLL)
c) a DPMI host that support port trapping, currently "HDPMI32i"

NOTE: EMM386.EXE also support port trapping, but the IO port cannot be below 100h, which makes SBEMU unable to
trap the DMA.

The software I'm proposing is a virtual DDMA Host (as per the "Distributed DMA Support for PCI Systems R6.0" definition.)
The SBEMU project shows that it would be possible.

This problem with one wide window I mentioned a page before. This is why I'm a bit pesiimistic this would work. In case the whole legacy low IO port range could be redirected to our own PCI device it may need to implement all the legacy stuff like KBC, timer, etc (maybe PIIX4 could hadle this) as those in PCH would be inaccessible then...

Ahhhh.
The chip was clearly designed to be placed at 45*.

Freerouting knocked out a 100% solution in minutes with some other trick settings instead of grinding along.

General settings:
Selection layers: All visible
Selectable Items: (all ticked)

Routing settings:
Snap angle: 45
Route mode: dynamic
Rule selection: auto
Checkboxes: All ticked except restrict pin exit directions
Rest of settings: default
Autorouter settings:
F.cu active, vertical
in1.cu active, horizontal
in2.cu active, vertical
b.cu active, horizontal
Vias allowed ticked
Fanout no
autorouting yes
optimization yes
via costs 50
powerplane vias 1
start pass 1
ripup 100
speed either
costs:
f 1, 1
in1 6, 6
in2 6,6
b 1,1

Result:

I also made it shorter.
Just needs the power and decoupling done/reworked.
There's bits I already see that aren't great - like the 12, -12v, but it's a quick and dirty result that's a decent startpoint for that.