Programmers Guide to the AMIBIOS (1993) [pdf] | Hacker News Reader

Programmers Guide to the AMIBIOS (1993) [pdf]

bitsavers.org

69 points1vuio0pswjnm718 comments

Back in the day, there was a website called amihotornot.com, where people could post photos of themselves and others could vote on how good they look.

This spawned a variety of copycat sites, all using the amiXornot name template. My favourite was amibiosornot.com, which showed you a photo of a PC motherboard, and asked: AMI BIOS or not?

Phoenix CBIOS:

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 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

No, you could always access the hardware directly.

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.

I mostly agree with all this -- I remember the glee with which people would discover and report "undocumented" BIOS or DOS interrupt calls, and the feeling that Microsoft were holding back on documenting these calls for selfish reasons -- but I can't see how they caused the 640k limit. That limit was built into the segmented memory architecture of real mode 8086 and successor CPUs.

The limit wasn't insurmountable. With segmentation, the CPU had an address space of 1M, but video memory was in the middle of it somewhere, limiting the possible size of the contiguous address space usable by programs. There were some work-arounds, including machines that added a few more k, IIRC 786k.

Improving matters would have required some coordination among software vendors, or authority from the OS vendor, neither of which existed. Part of the reason for the "closed box" approach of the Apple Mac was to prevent this from happening. My friend described it thus: "If you break our rules, we will break you in the next OS release."

Today it seems like such a tiny amount of memory to squabble over. We waste that much memory without batting an eye.

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.

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 interrupts were used to call bios commands.

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

And since I listed all the books I used routinely I didn't know that.

Parent,

> I should know the answer to this, but was using the BIOS the only way to interact with hardware like disks, mice, and keyboard?

First link from your URL

> READ CHARACTER FROM STANDARD INPUT, WITH ECHO

Also drivers loaded via config.sys would extend MS-DOS, and be exposed via additional interrupts, e.g 0x33h for mices.

Now is interrupt 0x33h populated by MS-DOS, after loading a mouse driver configured in config.sys, still MS-DOS API or not?

Another great resource for DOS and BIOS programming is Ralph Brown’s interrupt list…

http://www.cs.cmu.edu/~ralf/files.html

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.

You can always ignore the BIOS routines and directly touch hardware registers/etc. so as long as you know precisely what hardware you are dealing with. Of course, this is what modern OSes do for most hardware after bootstrapping since calling back into BIOS isn't really an option.

BIOS routines are purely an abstraction layer, though the abstraction is somewhat leaky and my understanding is that most hardware was trying to be IBM compatible even when software skips the BIOS routines and directly touches hardware interfaces.

e.g. you can see documentation for the VGA card here: https://wiki.osdev.org/VGA_Hardware

The thing is, as far as I know you do not need to use the video BIOS routines even to set the video mode. After all, the video BIOS routines are also just routines that run on the CPU, the only advantage they really have is that of any abstraction, the fact that using it allows you to be compatible with any card that implements that software interface even if it doesn't implement the same exact hardware interface. But as far as I know, if you know you're dealing with a VGA compatible card, you can set the mode by directly flipping around CRTC registers and it should work just fine.

Same for disk controllers and etc.

However, since GPUs tended to vary widely when going beyond VGA modes (although I believe even the original VGA controller was capable of 800x600x4 with a suitably lenient autosync monitor), VESA VBE was introduced to make that much easier again.

Windows actually runs the VBIOS in an emulator / VM for switching modes with the default GPU driver.

You know, I thought UEFI actually was doing the same thing, but I am mistaken, at least for anything resembling modern UEFI.

Apparently, modern UEFI just doesn't bother supporting classic Video BIOS option ROMs at all, only supporting UEFI option ROMs. Then for those... you either need to hope your GPU has one for your host CPU architecture, or you can use X86EmulatorDxe, a Qemu-based LGPL module that can run AMD64 drivers on AArch64, which hasn't been updated in a few years, or Intel's MultiArchUefiPkg, a more modern solution using Unicorn Engine that supports both AArch64 and RISC-V. Which is also LGPL, but.. Unicorn Engine itself is GPL, which is obviously a potential licensing issue for any would-be users. And, Intel archived it (probably alongside tons of their other open source projects) earlier this year, so it is no longer being maintained by them. Or, finally, you can have an option ROM containing machine-independent EFI Byte Code... which is no longer required by the UEFI spec, was never really used (apparently, the primary toolchain was a proprietary Intel C compiler that is no longer updated.) So who knows how many UEFI implementations still support it. It was removed from EDK2 in 2023, so presumably newer firmwares won't handle it at all.

I'm sure most people don't care about the trainwreck that is UEFI, but I found this tangent to be surprisingly interesting. At this point, treating AMD64 as a lingua franca of PC-based computers might just be the best way forward rather than trying to invent virtual machines. If they wanted to go the VM route, they should've committed fully and only supported OpROMs that were architecture-independent from the gitgo.

All of this just so we can initialize the video card and display some messages at boot, huh.

you could use IO which BIOS also uses. BIOs provided basically some library or api to make it easier, and did some init of platform.

you can also program the vga outside of bios if its PCI. not sure about agp and older stuff tho as i never really got to play with it.

bios essentially is just some software running in CPL 0. it doesnt have special access or privileges.

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.

I thought this was something to do with the Amiga

Reply on news.ycombinator.com