I should know the answer to this, but was using the BIOS the only way to interact with hardware like disks, mice, and keyboard?
I remember copying code to make wrappers for those in C from books but can't remember if that was the only option or...
I know with VGA you had to use the BIOS to set modes but you could just write to the memory which was mapped at a certain address
invalidator · 8m ago
The BIOS was an abstraction layer. In the old days, not everything was 100% IBM PC compatible. There were lots of weird graphics cards. Some systems had incompatible disk and keyboard controllers.
There was no memory protection in Real Mode, so you could always poke the hardware yourself, but something written on a Tandy wasn't going to work on a Zenith unless you supported both, or ran everything through the BIOS.
Over time, the OS took over the HAL role, with the BIOS only being used until the OS could load native drivers. Now it's UEFI... same idea with a higher greater level of abstraction and modularity.
pjmlp · 57m ago
No, there were MS-DOS interrupts for those as well.
BIOS became more relevant for graphics programming as MS-DOS did not do graphics, only text mode.
DOS only did file system operations and a few date/time calls
analog31 · 1h ago
Sounds like you lived through this, but for the younger generation...
I think the way to compare this with a modern machine is that the the early machines had no memory management or protection, meaning that any program could access any byte of memory, or any i/o address. Whether it was a good idea or not was up to the programmer.
There were BIOS and OS calls for interacting with display memory, that were supposed to make code more portable across machines. Devs almost immediately started writing to hard-coded address regions directly, which pinned those addresses down. Use of "unofficial" addresses and entry points made it phenomenally difficult to update the hardware or BIOS. This was true in the Apple ][, but also on PC's. For instance it's what created the infamous 640k memory limit.
I had an MS-DOS machine but its memory mapping was not identical to the IBM PC. Thus it was not "PC compatible." Apps that used the official MS-DOS calls worked just fine. Thankfully, two of those apps were Word Perfect and Turbo Pascal. I didn't need much else.
It was the wild west. Today, you try POKEing around where you don't belong, and you get a protection fault.
userbinator · 1h ago
No, you could always access the hardware directly.
userbinator · 1h ago
I have the Phoenix version of this already. The Ralf Brown Interrupt List is also very relevant and vendor-neutral, as well as including some normally-undocumented stuff, if you're interested in low-level PC programming.
https://bitsavers.org/pdf/ibm/pc/ps2/bios/CBIOS_for_IBM_PS2_...
Phoenix ABIOS:
https://bitsavers.org/pdf/ibm/pc/ps2/bios/ABIOS_for_IBM_PS2_...
I remember copying code to make wrappers for those in C from books but can't remember if that was the only option or...
I know with VGA you had to use the BIOS to set modes but you could just write to the memory which was mapped at a certain address
There was no memory protection in Real Mode, so you could always poke the hardware yourself, but something written on a Tandy wasn't going to work on a Zenith unless you supported both, or ran everything through the BIOS.
Over time, the OS took over the HAL role, with the BIOS only being used until the OS could load native drivers. Now it's UEFI... same idea with a higher greater level of abstraction and modularity.
BIOS became more relevant for graphics programming as MS-DOS did not do graphics, only text mode.
These became my bibles of the time,
"PC assembly language step-by-step"
https://archive.org/details/pcassemblylangua0000hoff
"Advanced assembly language on the IBM PC"
https://archive.org/details/advancedassembly0000holz
"PC intern system programming : the encyclopedia of DOS programming know how"
https://archive.org/details/pcinternsystempr0000tisc
Last one is great, it has examples on Quick Basic, Turbo Pascal, Turbo C and C++, Microsoft C and C++, TASM and NASM.
The whole DOS was only a tiiiny line between the bios. In fact, I think it really was only “DISK” os.
Edit: https://mrszeto.net/CIT/interrupts.htm
DOS only did file system operations and a few date/time calls
I think the way to compare this with a modern machine is that the the early machines had no memory management or protection, meaning that any program could access any byte of memory, or any i/o address. Whether it was a good idea or not was up to the programmer.
There were BIOS and OS calls for interacting with display memory, that were supposed to make code more portable across machines. Devs almost immediately started writing to hard-coded address regions directly, which pinned those addresses down. Use of "unofficial" addresses and entry points made it phenomenally difficult to update the hardware or BIOS. This was true in the Apple ][, but also on PC's. For instance it's what created the infamous 640k memory limit.
I had an MS-DOS machine but its memory mapping was not identical to the IBM PC. Thus it was not "PC compatible." Apps that used the official MS-DOS calls worked just fine. Thankfully, two of those apps were Word Perfect and Turbo Pascal. I didn't need much else.
It was the wild west. Today, you try POKEing around where you don't belong, and you get a protection fault.