We have the technology: Paratrooper written and ran from cassette (J.Bogin Rocks!)

[voidstar78]

To celebrate the IBM PC's 40th - no, I didn't install 3x SLI 3090's rocking PCI Express 6.0 bus to run a real-time VR interactive rendering of Tron with spinning replays of Bad Apple animation textured in the virtual sky off an mSATA stick. You know, to demonstrate how far we've come.

Instead, I convinced J. Bogin to add the /WB option to 5150CAXX - and it works! Fresh update, yum.

5150caxx.exe /A /WB PARTROOP.COM 16400

RECORD+PLAY. Tape dial spins slowly from 90 to 110.

Remove disk. Reboot. Rewind dial to 90.

ROM-BASIC: LOAD " " (don't forget the space, that's important!)

PLAY.
Wait a few spins. "LIST". Aw shucks, a customer loader just for me!? TYVM. "RUN". Wait some more spins. BOOM, Paratrooper executes (loaded from TAPE, not disk!), flawless! I scored 13 No joystick port, keyboard mode of Paratrooper is brutal.

Is this the worlds THIRD (non-BASIC) program available on IBM PC Cassette? (after IBM Diagnostic and the elusive Typing Tutor?)


I'm thinking of using these tapes to store my crypto private keys, labeled as "Whale Songs".


Kudos to Greg Kuperberg, Mega-Thanks for J.Bogin, and Cheers to any IBM folks involved with that cassette port engineering. This is straight up using a CCR-81 TRS-80 cassette deck and corresponding cable (ok a little kudos to my home town Tandy Radio Shack too, even though the HQ sign is gone and the building a community college now).

 

[voidstar78]

BTW... In the process of all this, I narrowed down to the following under-64KB-exclusives: (I configured my machine back down to 64KB and booted PC-DOS 2.10)

ADODGE (AstroDodge)
BEAST
DIG_DUG
PARATROOPER
DHUNTER (my 32KB game)


The following should be <64KB, but don't have enough available memory to run even with PC-DOS 2.10 loaded: (with the machine configured as 64KB)
CAT
(Moon) PARTROL
Robotron
Sopwith 1 or 2.

I still had trouble working with the 160KB format used by PC-DOS 1.0 - I can boot to it, but still can't inject files into it (and it seems to have trouble accessing other disk formats). So I'm kind of giving up PC-DOS 1.0.

But anyhow - if this cassette loader can get DOS out of the way, it may be possible to load many of the above from cassette. That's the joy of the cassette: load some straight up x86 assembly and own the machine, forget DOS.


BEAST and DHUNTER have already failed, they apparently still use some DOS interrupts of some kind (my DHUNTER has no file I/O, so I'm not sure what it's using -- it's in C and the core library may be doing more than I realize -- can investigate when get time). And that's unfortunate about BEAST, since of these so far, BEAST was the only one that also supports MDA output (the rest all require CGA {or composite output, I suppose}).

But given a bit more time, I'll keep experimenting with the rest. Any other <64KB suggestions I am missing? (ROM-BASIC program buffer I think is limited to single segment, hence the ~64KB restriction). (ah MSPACMAN, I did forget that one)

 

[VERAULT]

This is great! Can you get Microsoft flight sim 1 to load from cassette? We need more stuff loaded from cassette. Maybe even an Early DOS 1.0/2.0 Bootstrapper to load DOS from Cassette!

 

[krebizfan]

blog/dt/bootingfromcassette at master · retrohun/blog · GitHub has a pair of games stored as WAV files that are intended to be loaded from cassette on the IBM PC.

There are more than 20 games that were converted to work on Soviet cassette PC compatibles. The loading technique differs so the cassette itself can't be loaded. I think most of those games should be amenable to being loaded from cassette by a 5150. The one I recognize as having an earlier English version was the 1986 Ocean Software The Great Escape. I think some of the others were quickly modified like the pacman clone or the frogger but I don't know which clone has the base code.

 

[deanimator]

Looks like you're having fun

64K is the maximum size of one 16-bit realmode segment. ROM BASIC runs in one segment, also DOS .COM files have their code and data in one segment, so that's where the 64K limit applies. Contrary to EXEs that contain relocation information to different segments, enabling them to grow past this boundary.
Besides, you wouldn't want to load more than 64K from tape... you'd need a multistage loader, and the app in question would have to support relocation. 64K takes some six minutes to load fully. Imagine loading a single-sided 180K floppy image into a ram drive from a tape, for almost 18 minutes, only to be stopped dead because of a signal dropout. I think that'd nicely qualify for a "i'm getting me mallet" moment.

The games that you're loading with 5150caxx are actually running outside the BASIC segment. The purpose of the stub loader that you see with the LIST command is only to be found with the LOAD command - as soon as you run it, the machine code takes BASIC out of the equation, sets new data and stack segments, continues with the binary load operation and then transfers control to the newly loaded executable. The stub also caps the BASIC data segment, still in memory, to 8K instead of full sixty four.

Now, bootstrapping DOS thru the cassette interface is of course possible. However, a much better experiment is to connect a record player to the cassette interface, and have a DOS boot vinyl ready. But I think you've already seen that, so I won't be going into detail.

 

[voidstar78]

re: Flight Sim. That'd be interesting, can one of those "non-dos" images possibly be <64KB ?

This technique is limited to basically any .COM program that is smaller than 64KB. (some EXE's might be possible - but if the EXE starts with "MZ" then most likely not, since "MZ" was the initials of some Microsoft programmer and the format was largely invented for DOS {per my understanding} -- so if you find an EXE that doesn't start with "MZ", then it's probably not a real EXE file -- it was probably a .COM that just got renamed into an EXE ). [but there are exceptions to everything, across all the myriad of development tools out there]


But this criteria isn't even full proof. I remember once having one of those huge books describing the many DOS interrupts. Hand assembled code could still exercise those, but a program that is essentially its own operating system would avoid depending on those. not sure if a Python script could be made to scan a file and try to autodetect that.


If the program references a bunch of other files (like Thexder.com is 3K, but references a ton of other .BIN files) -- it probably won't work (since most likely without DOS interrupts being available, it won't know how to reference the files it needs to run itself).


EDIT: And ofc this isn't limited to files - if you can get the right offset of some non-dos image mirrored into RAM, I do think it might be possible to get it loaded from cassette (but again, 64KB limited)

 

[VERAULT]

64kb? Shouldnt some interesting demos work perhaps?

 

[voidstar78]

Ah, there is an ORBIS.COM that is 4KB - I forgot about that, thanks will give it a shot. [but I'll have to put my VGA card back in --- I'm using the CGA for now, because I found that AstroDodge seemed to have a rendering issue with the VGA card] EDIT: Then again, just to enter VGA mode might be a DOS call? They don't have to do a DOS interrupt - just it's generally safer that way to "future proof" the executable to more modern versions of DOS.


BURGER and CAT are both EXEs - and 5150CAXX won't even try to write them (I'm not sure if it just scans file extensions, or actually scans the program content). So those are out. I think SOPWITH is an EXE also (makes sense if it has the network support, not sure if that's over serial port - like an early interlink?). So that's probably out.


Some DOS bootloader would be neat.


You think there are more cassette players in the world than disk drives? Any moving-parts thing will wear out eventually. I suppose there are more cassette players, since just go to Amazon - they're still being sold.

 

[krebizfan]

Under the current 5150CAXX, WB checks for extensions of COM or BIN. W uses a different routine to write binary files if the extension is COM but the standard tape writing routines is available for non COM files. Glance at 5150CAXX.H to see the technique. The code is easy to follow.

 

[VERAULT]

Ah, there is an ORBIS.COM that is 4KB - I forgot about that, thanks will give it a shot. [but I'll have to put my VGA card back in --- I'm using the CGA for now, because I found that AstroDodge seemed to have a rendering issue with the VGA card] EDIT: Then again, just to enter VGA mode might be a DOS call? They don't have to do a DOS interrupt - just it's generally safer that way to "future proof" the executable to more modern versions of DOS.


BURGER and CAT are both EXEs - and 5150CAXX won't even try to write them (I'm not sure if it just scans file extensions, or actually scans the program content). So those are out. I think SOPWITH is an EXE also (makes sense if it has the network support, not sure if that's over serial port - like an early interlink?). So that's probably out.


Some DOS bootloader would be neat.


You think there are more cassette players in the world than disk drives? Any moving-parts thing will wear out eventually. I suppose there are more cassette players, since just go to Amazon - they're still being sold.

All i know is they are making cassete systems again. It doesnt matter if they are good or not because they ar wbot making 5.25" floppy drives anymore.

And alot of us have expwrience with cassette drivea on trs 80s zx spectrums, and c64s... It would be interesting to see what could have been possible on the ibm pc... And to repair most cassette drivea all you need is a head cleaning and a belt and theyare making belts so i hope that is convi cing enough.

 

[voidstar78]

More success with PATROL, DIGDUG, ROBOTRON (I figured all the Atari booters would work - they effectively do have their own OS, Atari knew their hardware and wouldn't need El Microsoft holding their hands).

ADODGE didn't work. The initial instruction text screen appeared, but as soon as it switched to graphics, the game froze. Too bad, it's kind of a fun game (and works fine loaded from DOS). EDIT: I guess one thing to try is load this portion into a DOS file, and byte compare it to the original, as an extra sanity check that it got saved correctly.


ROBOTRON didn't load for me on the first try. And I tried reloading several times, thinking I had the counter misadjusted. I gave up and just saved it again and reloaded - which worked out, by then I was paying more attention to the timing of these saves and loads. [ but I mention this as a good reminder - don't assume your cassette save worked; I'm still not sure what happened in this case, but LOAD " " from ROM-BASIC never found any content and just timed out after awhile -- loading from the second attempt further on the tape worked just fine on the first go; it's a new {unused} tape, not old stock, but maybe something did fuzz up that section, IDK... ]


If anyone else tries these, here's the approximate numbers to expect - basically 160-170 BYTES per second read and write speed. And this is a stock 4.77mhz 8088 5150. I'm not sure if a V20 or some 8mhz machine would skew these results - what was the fastest IBM PC that still had a cassette port? (oh hey, fire up that "586" 5150 )

I was a little surprised, I thought the PC was up around 300 bytes per second on the tape.


So if you find a gutted 5150 with no drives, here's 4 titles you could try from a tape Brew some tea/coffee while loading.

 

[voidstar78]

a pair of games stored as WAV files that are intended to be loaded from cassette on the IBM PC.

So I just play them (the WAV) on my Win10 PC, and route the headphone into the microphone of the cassette recorder... And the WAV includes a self loader? Looks like so from the screenshot. Yeah, I'll try to give it a shot sometime this weekend.

 

[krebizfan]

The fastest PC compatible with a cassette port was a 486 rocking the parallel port to cassette port interface. It was designed to read/write at the same speed as the PC's port. The speed of the CPU is not the limiting factor of the cassette port; it is the ability of the tape recorder to distinguish frequencies. High speed routines to tape decks on other machines were no longer reliable at 4,000 to 5,000 bps or roughly 3 times as fast as the IBM PC's BIOS would go. A Spectrum did manage 20K bps with an MP3 player on the other end. Even with that, the floppy disk is 25 times faster with much better seeks.

No one has tried to write high speed cassette routines for the PC. The only samples of code trying to change the speed of the cassette port I know of are for BASICODE which was a slower protocol with a number of other limitations. Good luck to whoever tries it.

 

[Chuck(G)]

I fail to see the fascination. My old Altair 8800 had its serial port rigged to a Novation modem, modified so that "send" and "receive" tones were the same. I stored my stuff at 300 bps on a cheap portable cassette player. I later managed to get a Techtran dual cassette drive that had no problems running at 4800 bps. It even had a built-in "search" facility.

I think there was at least one vendor who could operate a QIC-80 tape drive as a (slow) disk drive.

 

[voidstar78]

It would be interesting to see what could have been possible on the ibm pc...

Yeah, would be fun to see some code loaded from tape and exercised some MIDI or SB. The MIDI should be "kinda easy". And I think this is fair - sure, it's unfortunate the PC didn't get a decent audio card until like 1988, but the 5150 ISA bus supports it (I play "MOD" audio on my 4.77, they sound decent @ 11khz). The architecture was there.

Maybe a stripped version of GLX/MODM, remove any file I/O, inline something like cyclo.mod ? 20K, leaving 20-30K for the player... Could be done

 

[voidstar78]

I fail to see the fascination.

NOBODY used the IBM PC cassette port for anything - until apparently ~2017.

There was like this huge brick wall between Cassette BASIC (in ROM) and PC/MS/DR-DOS. Cassette BASIC couldn't talk to disks, and PC/MS/DR-DOS couldn't talk to cassette - at least, out of the box they couldn't.


Yes, in Cassette (ROM) BASIC you could inline some assembly code (via data statements) that MIGHT list the directory of a disk or something. Which is crazy since even 1980 Commodore BASIC 4.0 had a DIRECTORY command from its ROM BASIC ("BASICA" I think has a FILES command).


But IBM nor Microsoft never provided any tool support for the cassette port from the DOS side. Enter 5150caxx - you can now develop under DOS (or environments that can get files into DOS), get that content conveniently writ to a tape (raw x86 instructions, but single segment) -- and have it available to the earliest and most basic of IBM PCs (no disk drive, 64KB RAM) using its own normal ROM BASIC (loaded in a two stage approach that's more efficient than just a sequence of data statements - one of my examples was 58K, darn near max capacity, while the data-statement approach would be limited to like ~12K).



Sure, it's a fairly moot thing. But now some long forgotten 5150 with no disks or no disk drives, you can prepare a tape and make it do stuff again. Just cause

 

[voidstar78]

a 486 rocking the parallel port to cassette port interface

Oh nice, although I meant fastest that still had ROM BASIC support - which I think was ditched with the IBM PC AT? Like I'd be curious if these same samples here could be loaded on a PCjr. (not curious enough to go get a PCjr tho haha).


So this parallel port/tape interface - you run some proprietary program under DOS, and can write basically any file? (like maybe a text file, that was over 64KB long?) But the content could only be loaded back on other machines that had this same parallel card? Maybe it could write to reels that had larger capacity. Being by 486 days, hope the program was like a TSR so it could record in the background?

 

[krebizfan]

Oh nice, although I meant fastest that still had ROM BASIC support - which I think was ditched with the IBM PC AT? Like I'd be curious if these same samples here could be loaded on a PCjr. (not curious enough to go get a PCjr tho haha).


So this parallel port/tape interface - you run some proprietary program under DOS, and can write basically any file? (like maybe a text file, that was over 64KB long?) But the content could only be loaded back on other machines that had this same parallel card? Maybe it could write to reels that had larger capacity. Being by 486 days, hope the program was like a TSR so it could record in the background?

Yes, this DOS software could permit faster machines with copies of IBM BASIC to output to cassette. It should also allow 5150CAXX to run on those machines. The design was limited to 64K but making a modification to split files into smaller chunks saved to tape that get recombined when restored to disk is fairly obvious. The result cassette was intended to be identical to one done on the 5150 so a 5150 or PCJr could read the cassette unless the cassette was written in BASICODE mode which allowed it to be read by lots of 8-bit computers. It does not access the cassette in the background; the timings seem too tight to permit that. This was a solution available in Europe; it never got any traction in the US.

There were two reinventions of the parallel port to cassette adapter.

BASICODE: Software was broadcast on the radio. Audio saved to cassette was then loaded on a computer. Modified cassette routines to handle the different format were offered for the 5150. Users of PC compatibles lacking cassette ports could get the parallel port adapter.

The code was written to hook on INT 15h. For the 5150, BASICODE functions were handled by new code while old functions were passed on to the BIOS. For machines with the parallel adapter, not only was there new code to handle new functions, there was code to handle the old BIOS functions. https://github.com/jacgoudsmit/Basicode look at the routines motor, read_ibm, and write_ibm in CAS3 which do the same thing that the IBM BIOS does.

Russian: Some of the Soviet PC compatibles only had cassette interfaces. Since no one wants years of work left behind, programs were devised to read those cassettes along with a parallel port adapter to make up for missing cassette ports on modern machines. These seem more all in one solutions having the cassette access routines in the same program that also reads or writes to disk.

The Soviet cassette BASIC used the same format for cassettes as the IBM PC because it was IBM's code with a few changes. There were added file types for COM and EXE programs so the load routines could load them at the correct address. Soviet PC compatibles lacked BASIC in ROM so couldn't rely on BASIC stub programs to do that. Unfortunately, that means that the 5150 can not load Soviet cassette games easily because there is no BASIC program to guide the loading.

 

[Timo W.]

This technique is limited to basically any .COM program that is smaller than 64KB.

COM files are limited to one segment, so they are always 64 KB max. anyway.

 

[Chuck(G)]

NOBODY used the IBM PC cassette port for anything - until apparently ~2017.

That's not true--there were a few early cassette games--and the cassette port itself was used to trigger external equipment via the start/stop relay.

Heck, even if you run the Supersoft diagnostics, the code will rattle the relay to indicate an error.

I was there--were you?