Posted by surprisetalk 10/26/2025
Endless hours spent exploring VGA hardware registers and trying to apply them for cool visual effects. Learning how the then-new 32-bit Windows interacted with DOS extenders, and trying to make a homemade - very basic - operating system that could do it, too. The thrill of writing a Terminate and Stay Resident alarm clock, and having it finally not explode...
I have very fond memories of the Ralf Brown's Interrupt List.
It is actually quite puzzling why both the Intel designers and the AMD designers have been so incompetent in specifying a "syscall" instruction, when such instructions, but well designed, had been included in many other CPU ISAs for many decades.
When not using an established operating system, where the implementation for "syscall" has been tested for many years and hopefully all bugs have been removed, there may be a reason to use the "int" instruction to transition into the privileged mode, because it is relatively foolproof and it requires a minimum amount of code to be handled.
Now Intel has specified FRED, a new mechanism for handling interrupts, exceptions and system calls, which does not have any of the defects of "int", "syscall" and "sysenter".
The first CPU implementing FRED should be Intel Panther Lake, to be launched by the end of this year, but surprisingly, recently when Intel has made a presentation providing information about Panther Lake no word was said about FRED, even if this is expected to be the greatest innovation of Panther Lake.
I hope that the Panther Lake implementation of FRED is not buggy, which could have made Intel to disable it and postpone its introduction to a future CPU, like they have done many times in the past. For instance, the "sysenter" instruction was intended to be introduced in Intel Pentium Pro, by the end of 1995, but because of bugs it was disabled and not documented until Pentium II, in mid 1997, where it finally worked.
AMD's "syscall" corrects some defects of Intel's "sysenter", but unfortunately it introduces some new defects.
Details can be found in the Linux documentation, in comments by Linus Torvalds about the use of these instructions in the kernel.
* When updating the overscan region border color on some video cards DACs via direct port I/O, there would be random speckling of dots of previous and new colors like analog snow if synchronization to wait for the vertical blanking interval wasn't observed. This is the sort of shit emulation doesn't reproduce faithfully. It sometimes took having access to a lot of hardware to verify a program doing hardware-specific VGA tweaks worked correctly.
20 years later it is an excercize to find a device where loved EGA programming tricks work. Only unloved informatics remained
Our teachers didn't know much about this stuff in school. The origin of my username here (and elsewhere) is from those classes at school; I once submitted an assignment that, under certain conditions, used inline asm in Turbo Pascal to do "INT 19h". Had to explain it later, but thankfully that particular teacher was more amused than offended.
I think that has been one of the very first and largest information collection shared for free on the internet.
Kudos to Ralf Brown and whoever participated in keeping the list compete, accurate and timely.
Was that DOS emulation running some real DOS that though it was invoking BIOS calls?
According to a HN submission 3 years ago, evidently, Peter Norton once wrote a book on the 386i:
https://www.amazon.co.uk/exec/obidos/ASIN/0136616127/ref%3Dn...