Uploaded July 2017 | Updated September 2026, 2 weeks ago
The 486 is easily my favorite microprocessor of all time. There's bit fade, so the video description awaits your perusal.
Here's a long look at a Digital PC compatible or "clone" from the early 1990s. While low end when new, someone has upgraded it considerably. They even added a 128KB L2 cache. (The board is said to be capable of handling a 50 MHz base clock. My previous example of this computer had a 50 MHz processor, but it was a clock doubler. There is even the suggestion floating around that it'd run a 486DX4 (usually a clock tripler at a 33 MHz base clock) on a doubled 50 MHz clock.)
Some stuff from magazines:
books.google.com/books?id=RVEEAAAAMBAJ&pg=PA36
books.google.com/books?id=18wFKrkDdM0C&pg=PA62
The *factory* service manual: manx-docs.org/collections/mds-199909/cd2/pc/sd000021.pdf
MS-DOS 6.1: It had been a while since I searched against this, and things have changed. While I can't be sure if it was a typo, someone did indicate the existence of an MS-DOS 6.1 for the Asian market. I know for a fact it wasn't PC-DOS, DR-DOS or any other variant. It was Microsoft DOS.
The commentary about BIOS services deserves some clarification and expansion. With the original PC, IBM intended for programmers to utilize BIOS services and not to touch the underlying hardware directly. This was great if you didn't mind the BIOS imposing a speed penalty as compared to working with the hardware directly. It didn't take too long for programmers to realize this. Sometimes a programmer would also want to utilize the hardware in ways that the BIOS services were not designed to facilitate. So it didn't take too long before programmers, especially game developers, started working with the hardware directly.
It's here that PC compatible "clones" often ran into trouble when running certain programs that bypassed the BIOS services and worked with the underlying hardware directly. Such computers were supposed to be 100% compatible on the BIOS level, but differed in hardware implementation from IBM's PC. Certain computer programs, such as Microsoft's Flight Simulator, were excellent tests for true PC compatibility.
Windows 95 offered the first hardware/display driver agnostic version of mouse pointer trails. This didn't land in Windows NT family products until Windows XP.
My explanation of UUen/decoding, while not perfectly correct, does accurately describe why it was used and what problem it solved, despite being rather inefficient. One of the details I had wrong was the number of bits used in the encoding process. (In my defense, I never UUen/decoded anything.) Base64 encoding was a competing method of solving the same problem and is still fairly widely used today. yEnc was a later and more efficient binary to text encoding scheme that appeared during the end (for most people) of Usenet's time in the sun.
Recorded between 06/30 and 7/17/2017.
The 486 is easily my favorite microprocessor of all time. There's bit fade, so the video description awaits your perusal.
Here's a long look at a Digital PC compatible or "clone" from the early 1990s. While low end when new, someone has upgraded it considerably. They even added a 128KB L2 cache. (The board is said to be capable of handling a 50 MHz base clock. My previous example of this computer had a 50 MHz processor, but it was a clock doubler. There is even the suggestion floating around that it'd run a 486DX4 (usually a clock tripler at a 33 MHz base clock) on a doubled 50 MHz clock.)
Some stuff from magazines:
books.google.com/books?id=RVEEAAAAMBAJ&pg=PA36
books.google.com/books?id=18wFKrkDdM0C&pg=PA62
The *factory* service manual: manx-docs.org/collections/mds-199909/cd2/pc/sd000021.pdf
MS-DOS 6.1: It had been a while since I searched against this, and things have changed. While I can't be sure if it was a typo, someone did indicate the existence of an MS-DOS 6.1 for the Asian market. I know for a fact it wasn't PC-DOS, DR-DOS or any other variant. It was Microsoft DOS.
The commentary about BIOS services deserves some clarification and expansion. With the original PC, IBM intended for programmers to utilize BIOS services and not to touch the underlying hardware directly. This was great if you didn't mind the BIOS imposing a speed penalty as compared to working with the hardware directly. It didn't take too long for programmers to realize this. Sometimes a programmer would also want to utilize the hardware in ways that the BIOS services were not designed to facilitate. So it didn't take too long before programmers, especially game developers, started working with the hardware directly.
It's here that PC compatible "clones" often ran into trouble when running certain programs that bypassed the BIOS services and worked with the underlying hardware directly. Such computers were supposed to be 100% compatible on the BIOS level, but differed in hardware implementation from IBM's PC. Certain computer programs, such as Microsoft's Flight Simulator, were excellent tests for true PC compatibility.
Windows 95 offered the first hardware/display driver agnostic version of mouse pointer trails. This didn't land in Windows NT family products until Windows XP.
My explanation of UUen/decoding, while not perfectly correct, does accurately describe why it was used and what problem it solved, despite being rather inefficient. One of the details I had wrong was the number of bits used in the encoding process. (In my defense, I never UUen/decoded anything.) Base64 encoding was a competing method of solving the same problem and is still fairly widely used today. yEnc was a later and more efficient binary to text encoding scheme that appeared during the end (for most people) of Usenet's time in the sun.
Recorded between 06/30 and 7/17/2017.
