This 8254 mention made me curious. Does anyone know which other parts of the original PC hardware are still present in modern machines for compatibility? (Real mode in CPUs, A20, ...)
Back when I made that post I thought it was an 8253. But I checked the sources for the function that Beep.Sys uses to program the timer and it claims that it’s an 8254 so I went with the source code.
How hard would it be to use the chip? Not hard but now that Win7 has shipped, the number of machines with an 8254 that’s actually wired to something is going to dwindle to around 0. The machines will still have an 8254 (it’s on the SuperIo chip in every PC) but it won’t be connected to any hardware.
[1] nowadays the 8042 is mostly emulated in SMM because it needs to convert USB to PS/2.
I guess no v86 mode still makes it a dealbreaker for NTVDM type applications. Nobody wants to go back to a windows 95 style OS where a 16bit application runs unprotected and can stomp over anything and bring the machine to a halt. (For example, in win95 you could run debug.com and overwrite the first blocks of physical memory with zeros, which would immediately crash everything since that's where interrupt vectors like the IRQ timer is stored)
Would it be possible to bounce from 64bit long mode to 16bit real mode with some trusted code that bounces on to a mini kernel in 32bit protected mode that hosts v86 16bit applications, and then back again?
As far as I know it's possible to do all that and have a very-mixed OS.
Haswell?
I think what you mean is the vm86 mode is not available in 64-bit protected mode (no hardware task switching and 64-bit IRET ignores EFLAGS.VM).
But you can jump into real mode from 64-bit protected mode by clearing PE and PG at the same time. There are a couple more chores to do (clear EFER.LME and CR4.PAE) if you want the real mode code to be able to enter 16- or 32-bit protected mode. This[1] is an example.
[1] https://github.com/tianocore/edk2/blob/master/MdePkg/Library...
The beeper using ancient interface is also long gone. Nowadays, the HDA chip handles it most of the time. There is no reason except ancient compatibility to call into the beeper via the ancient interface.
j/k... but I hope a Hero Will Rise
[1] https://www.amazon.com/SANOXY-PS2-Keyboard-USB-Adapter/dp/B0...
The motherboards that do come with PS/2 usually implement their chipset.
Also PS/2 stopped being electrically compatible a while ago around about the same time that the combo Keyboard/Mouse PS/2 ports became available.
It offers pretty low current only about 250ma so you might have issues with older AT keyboards even if the chipset is still AT command compatible.
For Intel system super I/O was eaten by the ICH which initially kept compatibility with most Super I/O functions.
By ICH 6 or 7 which is around the mid 2000's most of those legacy features were all gone.
By 2008-9 the ICH was also gone and replaced by the PCH which doesn't have almost any compatibility or features with the Super I/O architecture.
Frankly, I'm a little surprised at the hate for the couple thousand or so transistors required to support the set of 8253/8259/8250/8042/etc chips that form the basis of the original XT/AT. Especially given the love for all things ARM, which tend to implement their peripherals in a very 1980's way with simple fixed MMIO ports punched into the address map, but without the standardization that form the basis of PC/AT hardware.
And just to stay on topic, almost every single decent ATX/ITX board I've used in the last decade has a 4 pin PC speaker port. Including the skylake machine I built last night. Same thing goes for RS232 ports, which are still on the vast majority of decent PC hardware even if they don't have headers soldered on. The X99 in that review actually had the headers, and I owning the older version of the board actually have a cable plugged into it which I attach to assorted hardware for firmware/etc work.
Isn't that a source of flexibility, though? The fact that that stuff is not standardized and is instead hidden behind a hardware abstraction layer (the OS kernel) means that ARM systems get the freedom to drop the legacy interfaces and centralize the hardware abstraction where it belongs: in the kernel.
However, for that you need:
1) a specific kernel for specific hardware, there's no universal kernel like for PC and
2) lot of hope that the maintenance or support of that specific kernel is not going to be dropped as soon as the hardware ships out of the gates (which is the fate of many routers or android phones, which cannot be updated to newer OS releases).
As someone who works on embedded systems, the serial port is really useful for debugging when nothing else works.
In a modern PC, almost none of these are used - why would anyone want to use the crummy old AT 24-bit DMA controller when you can use PCIe bus mastering - but they're there if want to boot into an old real-mode OS.