DOS and the BIOS were exceptionally slow at text. Essentially one character at a time winding their way through DOS to the BIOS and back.
Direct access to the text mode segment (0xb800 if I remember correctly) was much faster. The fonts were blitted out by hardware for every scan line, so you just changed the few thousand bytes of video memory at hundreds of thousands of bytes per second.
I think the ISA bus was potentially capable of 9.5 megabytes per second on the original IBM PC 5150, but I don't think the processor could come close to that. But I wouldn't be surprised if it was over a megabyte per second, which would mean you could repaint a 4000-byte 80×25 screen in 4 milliseconds. Clone CGAs would give you snow if you did that, though, so you had to limit your updates to the HBIs and VBIs, slowing the update speed visibly. IBM's actual hardware used dual-ported VRAM to avoid this problem.
The 8-bit ISA bus was theoretically capable of 1.19MB/s. The bus architecture always took 4 cycles per transfer (enforced by the 8288 which had a 4-cycle state machine, iirc one cycle for address, one for data, and two wait states), transferred 8 bits per transfer, and ran at the 4.77MHz frequency.
The actual usable bandwidth was always much lower, somewhere between 80kB/s to a bit over 380kB/s, depending on how you were using the bus, because the cpu needed to fetch its instructions on the same bus. In a way, the bus was usually always running at 1.19MB/s though, because all the basic devices (ROM, RAM, common simple ISA cards) were able to always respond in the basic 4-cycle transfer, it's just that most cycles were spent fetching instructions instead of actual data.
Later machines made the bus faster by increasing width, increasing clocks, and dropping one mandatory wait state at AT for 5.55MB/s theoretical, and dropping the last wait state in the fast clones for 8.33MB/s theoretical.
IBM's BIOS blanked the screen during scrolling because its own CGA hardware had single ported RAM and produced snow. Later clones were usually better, not the other way around.
Always cool to see this come up. I really like the idea of "encoding" the video as... x86 machine instructions!
The hairsplitting nerd in me can't help but point out that the claim in the Part 2 article that the problem of combining deltas is NP hard isn't true. In fact you can solve this optimally in O(n^3) time with DP: Let g(i, j) be the minimum number of bytes needed to encode input deltas i..j as a single (i.e., combined) output delta. Given g(i, j), computing g(i, j+1) takes constant time, so we can compute all of this function's values in O(n^2) total time. Now let f(i, j) be the minimum number of bytes needed to encode input deltas i..j using any sequence of output deltas (combined or not). Note that any such sequence must consist of some number (possibly zero) of optimally encoded output deltas followed by an optimally encoded output delta that itself ends with input delta j. IOW, it must be that f(i, j) is equal to f(i, k) + g(k+1, j) for some k, and there are at most n values of k that we need to try, so we can compute each value of f() in O(n); there are O(n^2) values to compute, so O(n^3) time overall. f(1, n) is then the minimum number of bytes needed to encode the entire list of input deltas, and standard backtracing through the DP matrix can be used to recover the actual sequence of output deltas.
Having used these machines, this is mind boggling.
I remember literally seeing how text appears on the screen once you type "dir". Video? Colors? Are you joking?
Same. Then I switched from XT to AT (8086->286), the disk was faster too, so I was forced to learn /p parameter :)
DOS and the BIOS were exceptionally slow at text. Essentially one character at a time winding their way through DOS to the BIOS and back.
Direct access to the text mode segment (0xb800 if I remember correctly) was much faster. The fonts were blitted out by hardware for every scan line, so you just changed the few thousand bytes of video memory at hundreds of thousands of bytes per second.
I think the ISA bus was potentially capable of 9.5 megabytes per second on the original IBM PC 5150, but I don't think the processor could come close to that. But I wouldn't be surprised if it was over a megabyte per second, which would mean you could repaint a 4000-byte 80×25 screen in 4 milliseconds. Clone CGAs would give you snow if you did that, though, so you had to limit your updates to the HBIs and VBIs, slowing the update speed visibly. IBM's actual hardware used dual-ported VRAM to avoid this problem.
The 8-bit ISA bus was theoretically capable of 1.19MB/s. The bus architecture always took 4 cycles per transfer (enforced by the 8288 which had a 4-cycle state machine, iirc one cycle for address, one for data, and two wait states), transferred 8 bits per transfer, and ran at the 4.77MHz frequency.
The actual usable bandwidth was always much lower, somewhere between 80kB/s to a bit over 380kB/s, depending on how you were using the bus, because the cpu needed to fetch its instructions on the same bus. In a way, the bus was usually always running at 1.19MB/s though, because all the basic devices (ROM, RAM, common simple ISA cards) were able to always respond in the basic 4-cycle transfer, it's just that most cycles were spent fetching instructions instead of actual data.
Later machines made the bus faster by increasing width, increasing clocks, and dropping one mandatory wait state at AT for 5.55MB/s theoretical, and dropping the last wait state in the fast clones for 8.33MB/s theoretical.
Thank you; I didn't even realize that the RAM chips on the motherboard were physically connected to the actual ISA bus!
IBM's BIOS blanked the screen during scrolling because its own CGA hardware had single ported RAM and produced snow. Later clones were usually better, not the other way around.
I could be wrong about this, and I appreciate your knowledge. The CGA I had that suffered snow was a clone, for what it's worth.
Always cool to see this come up. I really like the idea of "encoding" the video as... x86 machine instructions!
The hairsplitting nerd in me can't help but point out that the claim in the Part 2 article that the problem of combining deltas is NP hard isn't true. In fact you can solve this optimally in O(n^3) time with DP: Let g(i, j) be the minimum number of bytes needed to encode input deltas i..j as a single (i.e., combined) output delta. Given g(i, j), computing g(i, j+1) takes constant time, so we can compute all of this function's values in O(n^2) total time. Now let f(i, j) be the minimum number of bytes needed to encode input deltas i..j using any sequence of output deltas (combined or not). Note that any such sequence must consist of some number (possibly zero) of optimally encoded output deltas followed by an optimally encoded output delta that itself ends with input delta j. IOW, it must be that f(i, j) is equal to f(i, k) + g(k+1, j) for some k, and there are at most n values of k that we need to try, so we can compute each value of f() in O(n); there are O(n^2) values to compute, so O(n^3) time overall. f(1, n) is then the minimum number of bytes needed to encode the entire list of input deltas, and standard backtracing through the DP matrix can be used to recover the actual sequence of output deltas.
The mindboggling part is when you compare hardware constraints against software.
([2014])
a more civilized time
Literally.
This qualifies as pure obscure wizardry. Hats off to the author.