One of the comments here is great and something we should always keep in mind:
> The source code also illustrates a major problem with such code: It doesn’t explain what problem exactly it’s trying to solve. That means the next programmer can’t easily ditch such nonsensical looking code because they can’t be sure that it isn’t solving some relatively widespread and legitimate problem. Testing won’t help too much because it can not be assumed that the hardware in question is actually available for testing.
One of the tricks I discovered while trying to understand code like that is outb to an adress on the ISA bus takes a determintic amount of real time. This allows outb to somewhere same to replace a delay loop.
The way that code is described it does feel like someone lost the plot after a point. (Keep adding delays until the code works style). The basic operations it is using seem sane.
I'm kind of wondering if maybe they did all the pushes and pops because they didn't want to trust FWAIT to work properly?
It reminds me a bit of the hassle I had many many years ago now getting graphics to work on Haiku, where the Intel chipset would give me something like 400Hz vertical scan rate which my monitor Very Much Did Not Like and which turned out to be a flag bit in the chip that looked like it meant "setting the prescaler is now valid because the PLL is set", but actually meant "setting the prescaler now has an effect but you still need to wait for the PLL to lock".
I wonder if the author of the FPU interrupt ran into some similar nonsense?
⟩ it's still broken on my weitek coprocessor, please fix
• Thagomizing...
I'm trying to understand why the interrupt handler still isn't working for the user's Weitek 3167. It appears to be a timing bug. Maybe if I PUSH and POP AX a few dozen more times, the error trap will fall in the coprocessor's timing window?
One of the comments here is great and something we should always keep in mind:
> The source code also illustrates a major problem with such code: It doesn’t explain what problem exactly it’s trying to solve. That means the next programmer can’t easily ditch such nonsensical looking code because they can’t be sure that it isn’t solving some relatively widespread and legitimate problem. Testing won’t help too much because it can not be assumed that the hardware in question is actually available for testing.
One of the tricks I discovered while trying to understand code like that is outb to an adress on the ISA bus takes a determintic amount of real time. This allows outb to somewhere same to replace a delay loop.
The way that code is described it does feel like someone lost the plot after a point. (Keep adding delays until the code works style). The basic operations it is using seem sane.
I'm kind of wondering if maybe they did all the pushes and pops because they didn't want to trust FWAIT to work properly?
It reminds me a bit of the hassle I had many many years ago now getting graphics to work on Haiku, where the Intel chipset would give me something like 400Hz vertical scan rate which my monitor Very Much Did Not Like and which turned out to be a flag bit in the chip that looked like it meant "setting the prescaler is now valid because the PLL is set", but actually meant "setting the prescaler now has an effect but you still need to wait for the PLL to lock".
I wonder if the author of the FPU interrupt ran into some similar nonsense?
⟩ it's still broken on my weitek coprocessor, please fix
• Thagomizing...
I'm trying to understand why the interrupt handler still isn't working for the user's Weitek 3167. It appears to be a timing bug. Maybe if I PUSH and POP AX a few dozen more times, the error trap will fall in the coprocessor's timing window?