5150CAXX

That’s right – the very first IBM Personal Computer, the IBM 5150 – a business-oriented machine and a hallmark platform that started it all, shipped along with an integrated cassette port. Too bad it could only be utilized through the cassette BASIC contained in ROM… Or shall we say thankfully? Yes, this interface was abandoned soon after, for obvious reasons. But let’s fast-forward 40 years: reviving this legendary machine today, why don’t we give the cassette interface a go… in DOS ?

5150CAXX under DOS 2.05150CAXX running under an emulated 64K IBM PC rev. A, with PC DOS 2.0
The command line options are pretty much self-explanatory.

Since DOS by itself lacked any support to go with the interface, as you can see, this utility allows you to access the IBM cassette port directly together with DOS, to read and write raw data: be it the original IBM BASIC apps, or whatever you give it, utilizing the cassette port in the IBM PC, right next to the keyboard connector. The program can also be used together with the infamous IBM PCjr… that is, if you can scavenge out of nowhere (or make yourself) a cable for their proprietary “C”-marked connector.
And even though the ROM BASIC had been included in the successors of the IBM PC, e.g. the PC/XT and PC/AT, the cassette port was not. As such, the program will fail to load on anything newer than an IBM PC, or PCjr, for that matter.

5150CAXX, IBM cassette port cable schematicCassette port interface cable schematic

So how would you use this contraption? Firstly, as the name implies, you need an original IBM 5150 PC or PCjr, with DOS (at least 2.0), and a cassette deck. Or a reel-to-reel tape recorder, like I have used below. Or any sound device capable of playback and recording, in general… like a modern computer, or even a smartphone.
With an IBM 5150, the application will also work with the very first “16-64KB” mainboards, provided that it has enough memory to run DOS and the application itself. So it’s a good idea to have all RAM chips populated up to 64K of RAM.
And then you need a proper cable. On the 5150, it’s easy according to the DIN pinout and schematic above, similar to a Tandy TRS-80 datacable. You then need to provide these signals to your sound device, either mono or to the left channel. Note that if your device does not have a line input, but a microphone input instead, you need to set the P4 jumper on a 5150 mainboard accordingly.
The pins 1 and 3 of the DIN connector on a 5150 are normally-open relay contacts. Before any I/O operation, this relay then actuates its contacts to switch the cassette motor on. If you don’t use these pins, either listen to the relay clicking and actuate your device accordingly, or use the /A command-line argument that asks and waits for you to press PLAY (or PLAY+RECORD).
With that in check, the application can be downloaded here. Or you can fetch it from my GitHub repository, although you will need the Turbo C compiler, TASM and TLINK to compile this (ideally through the BUILD.BAT batch script). Because the tape contents are loaded into the same segment as code for compatibility purposes, the application must be compiled into a flat DOS .COM binary.

5150CAXX on an IBM 5150 with a Tesla reel-to-reel tape recorder

Now, the command line options are easy to follow. You need to seek the tape to the desired place and then use the /R, /D or /X commands to read from the tape to save it to a file, dump it to the screen as raw ASCII or execute the read data as machine code, respectively. Whatever is read from the tape is not “parsed” in any way to preserve the interface, so there is no dedicated “LOAD” command to search for a custom application/data/whatever.
If you know how many bytes to read exactly, specify it after as an optional argument. Otherwise, 5150CAXX will continue reading until it reaches a “bad tape signal” or a CRC error, indicating end of data stream, and use whatever was read properly.
The /W command is used to load a given file from disk to memory, and then write it to the tape at the current tape position.
Use /A to make the application wait for your response, if you don’t use the relay tape motor actuator, for all commands.
Now, the /X option is kind of a specialty, as it interprets any read data as x86 machine code directly. Any illegal instructions read from the tape will crash the system, requiring reboot. Note that you cannot read BASIC applications this way: they need to be saved into a file first, and then interpreted either through IBM Disk Basic or Microsoft GW-BASIC, as they are not valid x86 instructions, but of a special, “tokenized BASIC” format.
An example of a “Hello world” code that can be written to the tape and read by the /X option, can be found here. The code runs in the very same code/data segment as 5150CAXX, so it must end with a NEAR RET instruction and must fit into the free memory space announced by the application within the 64K segment boundary (a limitation of real-mode addressing). It also needs to be “self-conscious” and get its instruction pointer to address itself, as it can be loaded practically anywhere in the RAM, practically like an old-school computer virus 🙂 Check the above example for details.

Reading the IBM Advanced Diagnostics from tape with 5150CAXX:

There’s not much of software that had been released for the IBM 5150 on a cassette tape.. apart from a few notable exceptions, such as the IBM PC Diagnostics, and later the IBM Advanced Diagnostics. Since the only way to launch any application for the 5150 that’s been stored on a tape is through the IBM ROM BASIC (well, until 5150CAXX had been developed, anyway), this Diagnostics bundle could be used to perform a quick check-up of the PC without being required to have any kind of a drive, or operating system, in the thing.
The Advanced Diagnostics cassette recording basically consists of three parts, all of them can be dumped with 5150CAXX to 3 files, using the /R command three times. The first two parts are created obligatorily by any application that has been written in IBM Cassette BASIC and then stored with the SAVE command, whilst the third part is a tad special:

  • The first file dump is basically a 256-byte header of the data stream that follows afterwards. It contains an eight byte application identifier (in this case, ‘ldcass‘, the name that you would usually pass to the BASIC LOAD command), then the type of the following data stream (tokenised BASIC) and memory location where to load it to.
  • The second file dump is a small BASIC stub that shows information about the Diagnostics tape being loaded. This BASIC program cannot be executed directly – you need to open it up in GW-BASIC or IBM BASIC. It ends with a special CALL instruction that executes the third part.
  • The third file dump is actually x86 machine code, the diagnostic application by itself. This can either be loaded directly with the /X option, or it can be saved to a file, and then – with a small DOS stub “helper” binary – made into a DOS-launchable application.
    Using FASM and BUILD.BAT and renaming the third file dump to CASSETTE.BIN, the result is a DOS-compatible Advanced Diagnostics application that can be downloaded from here. Just beware that the exit routine of this code is a reboot, as the application does not know it runs in DOS.

Leave a Reply

Your email address will not be published.