{"id":184,"date":"2009-05-12T00:01:13","date_gmt":"2009-05-12T08:01:13","guid":{"rendered":"http:\/\/www.pagetable.com\/?p=184"},"modified":"2009-05-12T00:01:13","modified_gmt":"2009-05-12T08:01:13","slug":"reverse-engineering-dos-10-ibmbiocom","status":"publish","type":"post","link":"https:\/\/www.pagetable.com\/?p=184","title":{"rendered":"Reverse-Engineering DOS 1.0 – Part 2: IBMBIO.COM"},"content":{"rendered":"

Update<\/i>: The source is available at github.com\/mist64\/msdos1<\/a><\/p>\n

My last post was about the internals of the DOS 1.0 bootsector<\/a>. This time, let’s look at the next stage of the DOS 1.0 boot process, the hardware abstraction library IBMBIO.COM.<\/p>\n

CP\/M and DOS History<\/h3>\n

Let us first look at the historical background: CP\/M was an 8 bit operating system that existed for virtually every computer with an 8080\/Z80 CPU. It consisted of the three core components: BIOS<\/a>, BDOS and CCP. BIOS was the machine abstraction layer that allowed CP\/M work on different platforms. BDOS was the platform agnostic core library code, and CCP the command line interpreter.<\/p>\n

86-DOS<\/a> by Seattle Computer Products was a clone of CP\/M intended for 8086 computers. It shared the architecture of CP\/M, having a separate machine abstraction layer (“DOSIO”). When Microsoft bought 86-DOS and ported it to the upcoming IBM PC (model 5150), they kept this architecture, although there was no need to implement custom drivers, since the IBM PC had all its drivers in its “BIOS” firmware. But IBM’s BIOS did not have the same interface as 86-DOS DOSIO, so PC-DOS 1.0 included a very small DOSIO which would just sit on top of BIOS and using its driver library (and work around some bugs).<\/p>\n

So DOS 1.0 for the IBM PC consisted of the three parts IBMBIO.COM (machine abstraction), IBMDOS.COM (DOS library) and COMMAND.COM (command line).<\/p>\n

Microsoft soon started licensing MS-DOS to other computer manufacturers that wanted to make IBM PC compatibles. Back then, IBM PC compatible meant being able to run DOS applications and not necessarily sharing the whole system design with the IBM PC, so for MS-DOS to run on other 8086-based systems, it was enough to adapt the hardware abstraction layer to these machines, and therefore Microsoft provided the source code of this part of MS-DOS to hardware vendors. In MS-DOS, the system files are called IO.SYS and MSDOS.SYS.<\/p>\n

But since MS-DOS only provided a rather narrow API that did not include, for example, access to bitmap graphics, soon many DOS programs accesses hardware directly, forcing clone makers to make their PC compatibles more and more similar to the IBM PC, eventually using the same support chips and a binary compatible firmware interface. The separation of the kernel in two parts was less and less necessary, so that starting with MS-DOS 5.0, Microsoft only provided a single version of IO.SYS, and in MS-DOS 7.0 (Windows 95), IO.SYS and MSDOS.SYS were merged into IO.SYS.<\/p>\n

IBMBIO<\/h3>\n

On DOS 1.0, IBMBIO.COM provides the following library functions to DOS (names taken from 86-DOS DOSIO source):<\/p>\n\n\n\n\n\n\n\n\n\n\n
STATUS<\/td>\ncheck for keypress<\/td>\n<\/tr>\n
INP<\/td>\nget key from keyboard<\/td>\n<\/tr>\n
OUTP<\/td>\nsend character to screen<\/td>\n<\/tr>\n
PRINT<\/td>\nsend character to printer<\/td>\n<\/tr>\n
AUXIN<\/td>\nget character from serial<\/td>\n<\/tr>\n
AUXOUT<\/td>\nsend character to serial<\/td>\n<\/tr>\n
READ<\/td>\nread sector(s) from disk<\/td>\n<\/tr>\n
WRITE<\/td>\nwrite sector(s) to disk<\/td>\n<\/tr>\n
DSKCHG<\/td>\ncheck for disk change<\/td>\n<\/tr>\n<\/table>\n

(READ and WRITE will be directly hooked up by DOS into the INT 0x25\/0x26 direct disk I\/O API later.)<\/p>\n

In addition to this, IBMBIO is the next step in the boot process after the bootloader and responsible for<\/p>\n