Just a FYI, after making this video someone shared this schematic with me, which I think is similar to this board:
https://archive.org/details/turbo-xt-schematic
Please be aware that I didn't know about this until after the second video as well. 🙂

As others have said, the first step should have been to remove the one ROM and put the original ROM in place. The first step is always to eliminate any new or odd or unknown factors, to be sure you are not introducing a bug somehow. None of us can say for sure that the one ROM was causing the issue, but without removing it and going back to the original, we can't be sure that it's not causing a problem. It may not be the only problem, but it may be interfering with and or masking the real problem. Clone motherboards all had their own weird quirks and edge cases, and all it can take is a minor timing tweak for something to get set way off in the system to just stop working.

One thing I'm surprised you didn't try was just putting an actual ROM in there. The whole "it was working until shortly after I installed this new component" situation would make me at least somewhat suspicious; no idea whether it's going to turn out to be the culprit, but I would have started by ruling it out!

That sound blaster shirt is awesome!

Put the original bios back and confirm the error. Then inspect all your sockets

I have just completed my statistically oriented series of observations, and thus concluded that this man here....has a very consistent supply of positively nostalgic tshirts. This greatly contributes to the greatly positive experience delivered by this awesome channel. Thank You :)

The "weird" order of ram banks (0, 1, 3, 2) is related to gray code, where each increment of a value is equivalent to changing exactly one bit. See the binary values 00, 01, 11, 10. Here, though, an incremented sequence of gray code values is translated back to decimal representations of the "normal" binary encoding, hence the change of order.

Adrian... I have a dumb suggestion. Try plugging in a keyboard. It's dumb. But try it takes 2 seconds. Have a hunch that might be the difference.

I enjoy Adrian's videos, but when its advanced like this I feel like I am a dog tilting my head side to side whilst a human talks to me. I don't understand, but it sounds nice.

Loved the video where you analyzed lots of stuff because it leads to some information and scope shots that normally people will seldom get to see, so that's very cool. Since the XD bus is on one of the slots, possibly the XD bus transceiver got damaged by a card if some contention occurred. Even though this should not happen, the fact that the XD bus is on one slot makes the XD bus more vulnerable by being able to introduce parts onto that data bus. The /INTA signal is a CPU command signal similar to /MEMR and /MEMW, /IOR and /IOW. So when the CPU executes the /INTA command it wants to read the interrupt vector data from the interrupt controller. If there is some issue with the XD bus on some bits (which I seemed to see in your overview where some were floating) during reads, that would lead the CPU to some unknown area in memory to find an interrupt service routine, which could lead to freezing. Also, the XD bus is reversed by some logic gates where one may be malfunctioning due to age etc. So during /INTA the XD-bus should be reversed to enable the CPU to read the vector data. Also, the /INTA duration should be very short just like other CPU read cycles like /IOR or /MEMR, that is normal behavior. So either the XD bus transceiver or the logic controlling it would be my guess to merit some attention to make sure these are OK.

56:52, that's the section for a 8085 CPU, not a 8086/8088
AND then Adrian notices...

My theory on what's happening: the PIC is asserting the wrong interrupt vector when it triggers.

Why this sometimes carries on "working" (albeit crashed), and why it sometimes freezes the entire system: the 8086, and any later CPUs (including modern ones) in 8086 compatibility mode (called "real" mode) set up an interrupt vector table at address 0. If the PIC is triggering the wrong interrupt, for some BIOSes, they may not set up anything in the IVT other than the interrupt they're expecting (in this case IRQ0), which would effectively jump to a random place in memory and attempt to execute garbage, whereas others may set up the entire rest of the table with error handling routines.

The runt pulse interrupt code you were looking at would be a good example of a wrong interrupt, though without understanding the bus cycles more closely, I can't say for sure if that's what's getting asserted.

My Cat loves to watch your videos, it's the weirdest thing, when I watch them on my TV he sits and in lap and is just glued to the screen lol

Another reason an interrupt can happen is the NMI , which can trigger on hardware errors like io ports and parity error

Funny fact about the 18.2Hz of the timer interrupt: This had its effect very far down into the 2000s. Famously Microsoft Flight Simulator (which used to be SubLogic Flight Simulator) had an internal simulation rate of 18.2 Hz because it was tied onto the timer interrupt for its simulation logic. And further versions, even into the Windows era, almost did not change that code. So versions like Flight Simulator 2004 and FSX were still using the 18.2Hz for simulation logic (and I believe even MSFS used remnants of that code). The simulation rate was completely independent of your graphics frame rate.

Hello Adrian, the easiest test to do would be to rip out all the other Rom's you have installed on the board. it may well be one of them stuck high or low.

The buffered XD lines for slot 8 are because it was designed so that if you needed more slots, you put an extender card and cable to an external card cage into slot 8 on the motherboard to extend the ISA bus into the external card cage backplane...

I actually enjoyed the beep codes at 9:00. 😃

Obviously it wont boot because it wants to be YouTube Famous.

I love watching you go through stuff with the scope and trying to decipher those manuals, thanks for the video!