Timeline for Why have MS-DOS device drivers if the ROM BIOS provides access to the same devices already?
Current License: CC BY-SA 4.0
24 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 13, 2022 at 20:29 | comment | added | supercat | ...is to replace the normal text-mode blanking byte written to port 0x378 with a bit pattern that combines "medium resolution" and "blanking" functions. If the border color matches the dominant background color of the screen (e.g. the screen is mostly white on blue with a blue background) this will make the screen blanking far less ugly than would the black-rectangle-in-blue-field blanking the BIOS actually uses. | |
| Nov 13, 2022 at 20:26 | comment | added | supercat | @ThorbjørnRavnAndersen: Incidentally, there were a couple of missed opportunities to really improve the snow situation. The CGA allows host access on half of all memory cycles, and it happened to choose the half of the memory cycles that are used for attribute fetches. If it had used the half that serve character fetches, and only loaded the pixel shifter after unconflicted accesses, then conficting addresses would have allowed a character's background to show through but not been nearly as distracting as "snow". Another tweak which is--interestingly enough--available to software... | |
| May 18, 2022 at 20:14 | history | edited | user3840170 | CC BY-SA 4.0 | deleted 2 characters in body |
| May 17, 2022 at 16:15 | comment | added | Thorbjørn Ravn Andersen | @supercat Agreed. Seen in hindsight a lot of things could have been much better with very few changes. I have not looked into it, but is it "what do we need to support CP/M" mindset we see here? | |
| May 17, 2022 at 16:11 | comment | added | supercat | @ThorbjørnRavnAndersen: If the BIOS had included a functions to write up to two lines of text with a specified attribute, or with alternating character/attribute pairs, it could have output a full screen of text in 13 frames without needing to do anything particularly clever. Given that the best that can be achieved without snow would be about nine frames, and that even programs that use direct screen writes seldom achieve that speed, I don't think direct memory access would have to offer a particularly huge advantage over using BIOS routines that could write a bunch of data. | |
| May 17, 2022 at 14:57 | answer | added | AnoE | timeline score: 3 | |
| May 17, 2022 at 6:06 | comment | added | Thorbjørn Ravn Andersen | BIOS routines were not necessarily badly written, but direct memory access is just much, much faster. | |
| May 16, 2022 at 22:18 | comment | added | supercat | @Thomas: I doubt anyone involved in the design of MS-DOS would have imagined that anyone would ever want to be running it on a 32-bit CPU, so I doubt such notions would have had any significant design influence. While the PC-BIOS and MS-DOS were hardly examples of wonderfully efficient coding, achieving good performance would have required consolidating operations. | |
| May 16, 2022 at 21:16 | comment | added | Thomas | @supercat, this is true, all operations were stateless and had much overhead, but bus speed was also not the same: If I recall correctly access time was over 200ns during the 386 days but also the bios was accessible through an ISA bus, in 16 bits, even during the 32 bits era. So regardless of the API's inefficiency, there was a significant difference in hardware speed too. I miss the old computer days, but not the early PC days :) | |
| May 16, 2022 at 16:12 | comment | added | supercat | @Thomas: ...which meant that it was necessary to perform row address calculations for each individual byte to be written. Serial ports posed a different but related issue: many tasks require that serial communications be buffered, but some tasks require a larger buffer than others. Using a serial port driver (e.g. FOSSIL) makes it possible to buffer serial port data in a manner which is agnostic to the running application, and can thus allow buffers to be maintained even when switching applications. | |
| May 16, 2022 at 16:09 | comment | added | supercat | @Thomas: MS-DOS was written years before anyone would have imagined that access to BIOS ROM would be any slower than access to ROM. In many cases, the big problem with BIOS performance is that they had to perform each and every operation from scratch. If one wants to write a line of text to the screen, one could compute the address of the start of the line, build a buffer that interleaves the character codes with the attribute values, wait for vertical retrace, and then copy 160 bytes, writing 80 characters in one frame. BIOS routines, however, were limited to writing one byte at a time... | |
| May 15, 2022 at 21:37 | comment | added | Thomas | I want to point out that the routines in the BIOS weren't necessary written poorly nor slow, but access to the BIOS ROM itself was much slower than RAM. It wasn't a code issue. The concept of 'shadow ram' was created where parts of the bios were copied in ram for faster access speed (roughly 2x). | |
| May 15, 2022 at 10:01 | history | edited | Raffzahn | CC BY-SA 4.0 | Linkformating |
| May 15, 2022 at 7:12 | vote | accept | 9968 | ||
| May 14, 2022 at 21:58 | history | became hot network question | |||
| May 14, 2022 at 16:12 | history | edited | user3840170 | CC BY-SA 4.0 | deleted 97 characters in body; edited title |
| May 14, 2022 at 16:10 | answer | added | user3840170 | timeline score: 13 | |
| May 14, 2022 at 15:46 | answer | added | Raffzahn | timeline score: 39 | |
| May 14, 2022 at 15:35 | comment | added | Tommy | MS-DOS was available for many non-IBM PCs; Microsoft's original thinking was to become the 8086 equivalent of CP/M, and the BIOS was the only part of a PC that IBM had any intellectual property rights over. So best not to wed yourself to that. | |
| May 14, 2022 at 15:17 | answer | added | Justme | timeline score: 7 | |
| May 14, 2022 at 15:02 | comment | added | Jon Custer | Because stuff changes, and a new driver is needed for that new interface board that uses a different chip, etc. | |
| May 14, 2022 at 14:52 | history | edited | 9968 | CC BY-SA 4.0 | deleted 327 characters in body |
| S May 14, 2022 at 13:58 | review | First questions | |||
| May 14, 2022 at 14:35 | |||||
| S May 14, 2022 at 13:58 | history | asked | 9968 | CC BY-SA 4.0 |