OverviewIn most respects the PCjr is a PC compatible clone. It runs the same versions of DOS as the PC, it features a similar BIOS, and it has similar architecture. It differs in several respects:
Games written for the PC that "use the metal" are going to have the biggest problems. The most common problem was garbled video because standard BIOS calls were not used.
The last officially supported version of DOS for the
3.3. DOS 4.0 will run on the PCjr, but it was not
advertised. Besides, DOS
4.0 was not known as a stellar piece of software. DOS 5
the PCjr but it can be patched to run. DOS 6.x will also run if
patched. Patching instructions can be found in Patching_DOS_5_for_the_PCjr.pdf.
Each version of IBM DOS came with two versions of BASIC, one named BASIC and the other named BASICA. BASICA had a few more features and took up a little more space than BASIC. Both of these versions are known as "Disk BASIC" in contrast to the built in Cassette BASIC. Disk BASIC had additional support for accessing files on disk using DOS.
The PCjr had yet another version of BASIC that the PC and XT did not have. This version came on a cartridge as was known as "Cartridge BASIC." Cartridge BASIC supported all of the advanced features of the PCjr including its special graphics and enhanced sound. Cartridge BASIC could be used as a replacement for Cassette BASIC or used with DOS as a replacement for both versions of disk BASIC.
DOS was altered to always call Cartridge BASIC if the BASIC or BASICA commands were entered at the command line. This effectively made disk BASIC unavailable and forced you to purchase Cartridge BASIC if you wanted to use BASIC while running under DOS. You could get around this by renaming the disk BASIC files to a different name - the name check would then fail and disk BASIC would be loaded and run just like on a PC or XT. (The PC ID cartridge from Racore could be used to circumvent this check, allowing you to run BASIC and BASICA without Cartridge BASIC present.)
PCjr's with more than 128KB of memory had a unique problem running Cartridge BASIC. With more than 128KB of memory, the environment for Cartridge BASIC would not be set up correctly. To use Cartridge BASIC PCjr owners ran a small disk program called "JRBASIC" which fixed up the memory environment and then invoked Cartridge BASIC. They really didn't intend for this machine to be expandable!
All of these versions of BASIC were provided by Microsoft and they all were interpreters. A BASIC compiler that compiled this dialect of BASIC was available although it did not support the PCjr's enhanced sound and graphics.
Other versions of BASIC could be used on a PCjr as well. I heavily used Zedcor's Zbasic, which was a BASIC compiler featuring inline assembler, structures and functions.
Compiled BASIC was a great alternative to the BASIC interpreters. Compiled BASIC runs much faster than interpreted BASIC because all of the hard work is done up front by the compiler. IBM offered a BASIC compiler for its flavor of BASIC. Other companies offered compilers for different versions of BASIC. My favorite BASIC compiler was Zbasic by Zedcor; it was fast, it allowed inlined assembly code, and it provided some advanced functions that IBM's BASIC did not have. (Most notably, overlays. If you don't know what an overlay is, you are too young to be reading this.)
Sometimes a compiler would not run on the PCjr because it required more resources than what the PCjr could provide. (i.e.: Memory or disk space.) The executable results of the compiler could still be used on the PCjr though. In these cases the PCjr could not be used for code development but it could still run the resulting software. (Some machines are better targets than development platforms - the PCjr is one of those machines.) Most commercial software is created like this; the machine that the software is created on is far more capable than the average machine that runs the software.
A popular alternative to BASIC was PASCAL. Borland's Turbo PASCAL version 3.0 was a wonderful match for the PCjr. It was small, efficient, and it fit on a single floppy disk with room to spare. IBM also offered a PASCAL compiler.
I have heard that C compilers could run on the PCjr but they often required multiple diskettes which was a pain on a standard PCjr.
And of course, you could always program in assembler if you were really hardcore. As difficult as assembler is, it is the best way to squeeze the most performance out of the machine.
Cartridges in general have some serious drawbacks. The software on them is ROM which can not be changed if a bug is discovered. Cartridges are mechanical devices, subject to wear at the contact points. The implementation of the PCjr limited each cartridge slot to 64KB of ROM which was a fairly small amount of data.
Cartridges had some good points to them though. Software run from a cartridge loads faster because it is reading memory. Cartridge software may not require an operating system like DOS or a diskette drive. (You did not want to use cassettes.) Cartridges do not consume precious RAM memory. Cartridges are sturdy compared to floppy diskettes. And best of all, software companies love cartridges because the physical attributes of them make them harder to copy. (How many of your friends know how to use an EEPROM burner?)
Some titles available on cartridge:
The world of the PCjr is especially dependent on device drivers because of the way the memory is laid out. If you add memory past 128KB on a PCjr and you want it visible from DOS, you must use a device driver to setup DOS properly so that it can see the extra memory. No other machine calling itself even slightly PC compatible has this requirement.
If you purchased a memory sidecar for the PCjr it would come with a device driver allowing DOS to use the extra memory. Other device drivers were required for RAMdisk support, clock and calendar support, etc. One device driver worth noting is JrConfig by Larry Newcomb - I highly recommend it for your machine.
Cartridge BASIC had a small terminal emulator built into it. You could access it by typing "TERM." It was a crude program and not usable for anything serious, but you could look at the source to see how it worked.
Better terminal emulators were DOS programs such as CrossTalk, Qmodem, Procomm, PC-Talk, etc. These programs had file transfer capability, logging capability, and the ability to emulate multiple terminal types. They were also written in compiled languages so performance was far better.
The serial port setup on the PCjr was a source of confusion for many communications programs. When the internal modem was not installed the external serial I/O port was known as COM1. However it was wired to use the port address and IRQ normally associated with COM2. When the internal modem was installed it became COM1 and the external serial I/O port became COM2. Port addresses and IRQs always stayed constant despite the name changes.
PCjr owners who used external modems had to trick the machine to rename the external serial I/O port as COM2 so that software would not get confused about the ports and IRQs it was supposed to use. (Communications software that didn't strictly use BIOS calls to access the serial port could get confused.) This was done with a small utility called "COMSWAP."
IBM did not recommend using the keyboard when receiving data at 2400bps or higher. This is because the keyboard decode logic could hold off the serial port interrupt for a long time and possibly cause bytes to be missed. In practice I did not find this to be a problem; the NEC V20 in my PCjr may have helped the situation. (For a detailed discussion on keyboard handling and how it affected serial communications see "PCjr Keyboard Handling.")
IBM also warned against using the diskette drive when doing serial communications. This is because the processor had to devote its full attention to the floppy disk (due to the lack of a DMA controller), thus causing bytes coming in on the serial port to be lost. The solution to this was to download files to a RAM disk and transfer the files to a floppy disk later on.
October 2000, Last updated December 27th, 2020
(C)opyright Michael B. Brutman, mbbrutman at gmail.com
Return to Mike's IBM PCjr Page main page