On Thu, May 2, 2019 at 8:32 AM ZB <zbigniew2...@gmail.com> wrote: > On Wed, May 01, 2019 at 09:05:35PM -0500, Rugxulo wrote: > > N.B. The 8088 [sic] turns 40 this year. That's the one the original IBM PC > > used. > > The one "slower than Commodore 64" ;) > > https://trixter.oldskool.org/2011/06/04/at-a-disadvantage/ > > #v+ > Quick, without doing any research: What early 1980s computer was faster, > the IBM PC or the Commodore 64? The IBM PC ran an 8088 at nearly 5MHz, > whereas the C64 ran a 6502 variant at 1MHz. The PC cost thousands of > dollars, the C64 hundreds. The PC had a 1 megabyte address space; > the C64 only 64K. Is this a trick question? > > It is! The C64 was faster. The original IBM PC, despite appearances and > bias on the part of both consumers and marketing, was actually the slowest > popular personal computer on the market at the time of its release, even > compared to the Apple II and Atari 400. Here's why. > [..] > What took 6 cycles on the C64 takes 37 cycles on the IBM PC > #v-
Did you ever actually *use* a C64? I logged time on both the original IBM PC and the Commodore 64, and that answer is at best misleading. It was popular back in the day but depended on what you were measuring, and what you were trying to do with the machine. The C64 ran the 6510 variant of the 6502, It was designed to be a microprocessor to control things like refrigerators. 8 bit chip, and 64K total address space. There were tricks you could play. For instance, the C64 had 64K RAM and 16KB ROM. You could set bits that controlled what was mapped into the 64K address space. By defaalt, the top 8K was the kernel ROM, then 4K of RAM, and the the 8K Microsoft BASIC interpreter. Below that was RAM, and the bottom 1K was pointers to system routines. One bit of software I ran was a "wedge". Run it, and it flipped the ROMS out of the address space and loaded code and data into the 16K of RAM the ROMs normally appeared in, then mapped the ROMs back in. The usual way to reset the C64 was to press the Run/Stop and Restore keys simultaneously. The Restore key generated a non-maskable interrupt. By default, when you pressed it, the OS looked to see if you also pressed the Run/Stop key and did a warm start if so. If not, it was a no-op. The wedge installed in the 4K of RAM between the ROMs, and changed the standard system routine for dealing with the Restore key. Press the Restore key by itself, and it displayed a menu stashed under the kernel ROM. You could do things like run a machine language monitor that was also stashed under a ROM. You had to be carefully when using it that your programs didn't try to access kernel or BASIC routines while those ROMs were swapped out, but it worked fine, It was also possible to run the C64 at *2* mhz, but there were various limitations on when you could do it and what you could do when you did. The C64 was an interesting architecture hobbled by "design to cost". For instance, the 1541 floppy drive connected to the system over a *1200 baud* serial line. Start to load a big application, like GEOS, and go have coffee. By the time you were done, it might have finished loading. (Though there was a trick you could play there, too. The 1541 had a dedicated 6510 chip as drive controller with 2K local RAM. You could write machine code that could be downloaded and run asynchronously on the drive while the C64 did other things.) The C64 was a neat toy to play with, but there were reasons why 8bit machines based on the Intel 8080 and Zilog Z80 chip running CP/M were the original business productivity machines until the original IBM PC came along. You could do things on the Intel architecture you simply could not do on the C64, regardless of supposed speed advantage. The bit about the limitation imposed by the 8 bit data bus in the 8088 is open to a lot of question. The choice of the 8088 was also "design to cost". The big brother 8086 had a 16 bit bus, but the 8088 variant was cheaper, and in practice, the users never noticed. It was, after all, running at almost five times the clock speed of the 6510. And given that external storage on the C64 was either a tape drive or a floppy hobbled by an arthritic interface, the C64 tended to be a *lot* slower loading data. PCs also encouraged creativity to get around hardware limitations. One was writing directly to video RAM rather than using BIOS routines. A popular compatibility test for early PC clones was running Lotus 123 and MS Flight Simulator. If they ran successfully, the clone had a compatible BIOS. Many early clones did not, and the original Compaq PCs were the other choice besides genuine IBM gear *because* they had a compatible BIOS. The design of the 808X processor also allowed you to play games with the A20 address line, that let you access memory beyond the default 640KB limit by creating a 64K window in the 640K address space you could use to page in code and data stored above the 640K limit. I still have my original XT clone sitting on a shelf. I gave it a 10mhz motherboard with a NEC V20 CPU (which was about 5% faster than an 8088 because of better microcode. It had an add-on card with a megabyte of additional RAM, split between RAMdisk, disk cache, and EMS memory for programs that could use it. I gave it a Hercules graphics card to replace the CGA graphics, and two 20MB Seagate ST-225 MFM hard drives. I found a freeware utility that could map unused video RAM into standard address space. The Hercules card had 64K unused, so my machine booted to a 704K RAM system. My usual operating environment on the XT was the MKS Toolkit, which implemented all of the Unix commands that made sense on a single tasking OS, including a complete port of the Korn shell, with everything save asynchronous background processes. Booted into the Toolkit, you had to dig a bit to tell it *wasn't* an Honest-toGod Unix machine. (I had one of those, too, before I got the PC, and still have it.) > Zbigniew ______ Dennis _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
