Did any microcomputers back in the day accelerate standard-cassette performance

Question

Many commonplace cassette recorders in the 1970s and 1980s were capable of reading or writing two tracks at once (stereo). While that wasn't universal (portable cassette recorders were often monaural, and probably used a single-coil record/playback head) stereo recorders were hardly rare. Further, at least one computer company (Atari) supplied a cassette recorder which used a stereo playback head. Additionally, one of the primary limiting factors for cassette data rates is that the tape only moves at 1.875"/second but the motor speed on many cassette drives could easily be increased merely by changing a resistor or other such component.

It would seem, then, that cassette drives that were customized for, and sold by, computer manufacturers should easily have been capable of handling data much faster than would be possible recording a single track at 1.875"/second, merely by adding some extra record/play electronics and by changing the value of a speed-control component. I know the Coleco Adam used a rather fancy and sophisticated tape drive, but from what I understand that didn't use standard cassettes. Were there any 1970s-1980s computers that used tape drives to record more than one data track, or record data at a speed faster than 1.875"/second?

even those computers that used proprietry compact casette(tm) drives used consumer tape transports running at normal speed, only customising the case and audio circuitry. — Jasen, May 14 '16 at 20:22
I deleted my answer as I realized that despite being an interesting examination of how data cassettes were implemented it didn't address your actual question. — mnem, May 14 '16 at 21:07
The ZX microdrive, of course, wasn't a compact cassette (it's design was apparently based on a miniaturized 8-track tape) but it did run the tape somewhat faster than a standard compact cassette did -- 76cm/s, allowing for a complete memory dump/load of the 48K spectrum in around 3 seconds. It was about as reliable as you'd expect from trying to make a cassette tape both smaller and over 10 times faster at the same time. :) — Jules, May 16 '16 at 20:07

score 23 · Answer 1 · edited Nov 02 '21 at 18:03

The Sprint cassette player/recorder, specially designed for the ZX Spectrum, allowed 4X load and save speeds.

It works by speeding up the tape four times the standard playing speed. It is meant to load programs originally recorded at the Spectrum ROM standard speed (1500 bps). It provides a shadow ROM that pages in when the CPU starts executing a SAVE or LOAD routine. The shadow ROM mimics the behaviour of a LOAD or SAVE, but using their own routines. Many units had an after-market modification, that allowed the Sprint to be disconnected from the bus in order to improve compatibility with other peripherals, like the Interface 1.

It doesn't use the audio connectors (EAR/MIC), but it talks directly to the CPU through the expansion port. Therefore, the Sprint has to have electronics to clean and digitize the signal, making a volume control not neccesary.

Here you have the disassembly of the 512 byte Sprint ROM.

http://www.zxprojects.com/images/stories/sprint/rom_sprint.html

To ease the disassembly process, I have assumed that the 512 byte block is present at address 0400h to 05FFh. This is because the starting points of the original SAVE and LOAD routines are at 04C2h and 0556h respectively, so they fall entirely into this 512-byte block (as expected).

There's a JP 4 instruction right at the beginning of the ROM (after an EI instruction). As this block is also at 0000h, the JP 4 instruction merely jumps to the next instruction, which outputs a 0 into port BFh. I think this unpages the Sprint ROM, and the next instruction executed, already from the main ROM, begins at 0008h, the ERROR restart.

By the way: this ROM (and thus, the device) uses these ports:

BFh. Write-only. The ROM only writes 00h here. I think it's for disabling the Sprint ROM
7Fh. Write-only. The ROM writes 00h or 80h here. It's the new "MIC" port, bit 7.
FFh. Read-only. "EAR" port, bit 7. Decoded bit value, bit 0

The internals of the Sprint seem to work according to patent number GB2164527A or "High speed cassette tape player"

The device actually decodes FSK, so the value at bit 7 of port FFh is not the current state of the "EAR" input, as in normal loaders, but the actual bit of the current loading byte.

So, as the patent states, there no need for tight loops, as the time measuring is performed by a monostable, which is reset to 0 on each positive edge of the incoming signal. The computer has to keep reading the monostable value while it waits until the next positive edge. A polarity correction circuit ensures that the edges are right regardless of the polarity the tape were recorded with.

The monostable is configured so it turns to '1' after a specific period of time. Time that is roughly 3/4 times the period of a '1' bit in FSK (remember that the '1' bit lasts double the time than a '0' bit). So if a '1' is currently playing, the monostable will switch to '1' and that will be the value read by the computer, but if a '0' is playing, the next positive edge will happen long before the monostable switchs to '1', hence a '0' will be read.

By analysing the source code, it is likely that port FFh offers two things: the current state of the incoming signal, at bit 7, needed to track the pilot tone at the first part of the loading routine, and to detect edges in the second part. The current value of the monostable, that is, the bit after the FSK decoding process, seems to be at bit 0. The routine reads port FFh, stores bit 0 into the carry with a RRA instruction, some instructions after that, the routine retrieves the bit again into H using the instruction RL H.

ROM:0492 loc_492:
ROM:0492                 dec     l
ROM:0493                 jr      z, loc_4A8
ROM:0495                 in      a, (c)
ROM:0497                 jp      m, loc_492  
;loops while the pulse is high, so it exits 
;just after a positive to negative edge has ocurred
ROM:049A
ROM:049A loc_49A:
ROM:049A                 dec     l
ROM:049B                 jr      z, loc_4A8
ROM:049D                 rra
ROM:049E                 in      a, (c)
ROM:04A0                 jp      p, loc_49A

;loops while the pulse is low, so it exists just after 
;a negative to positive edge has ocurred. The carry
;bit holds the value of bit 0 read in the previous IN
;operation, as at the precise moment a falling edge
;happens, the monostable is reset to 0.
ROM:04A3                 rl      h  ;load the bit into the H register.
ROM:04A5                 jr      nc, loc_482

This explains why I have seen no tight loops, but some NOP's inside the saving and loading loop. The computer uses timming loops to detect the pilot tone, but the monostable for actual byte loading.

(the following paragraphs were written after a more careful read of the new LOAD routine was made)

Finally, I'd like to give some details of what I think it's the very heart of the loading routine, and the code that shows all the magic that the SPRINT cassette offers:

What this tape player implements is no more and no less than a converter from an asynchronous FSK coded signal to a synchronous 1-bit serial line. The DATA bit is the monostable bit (bit 0 of port FFh) and the CLOCK bit is what we have previously called the "signal" bit (bit 7 of port FFh, which gives us the actual pulses present into the tape). As we stated, the conversion is performed in hardware, and DATA is valid just before a negative to positive transition at CLOCK happens. The byte loading routine that follows, just have to wait for this situation, taking into account that the signal flow might be interrupted at any time, so timeouts have to be provided to not to hang the computer into an endless loop because of an interrupted operation.

;Registers used:
;C = 0FFh (for the IN instruction)
;BC' = 1601h. C is xored with B at each loop. The result is 
;outputted to FEh, so these two values provides visual
;and audio feedback of the loading process to the user.
;H = holds the byte that is being read from tape. First bit
;read is MSb.
;L = timeout value for waiting an edge.
;On "normal" exit: H = byte loaded from tape. Carry set.
ROM:0480 LoadOneByte:
ROM:0480                 ld      h, 1  ;Mark bit 0 with 1. When H is filled
                                       ;this '1' goes to the carry bit,
                                       ;signaling that the byte is completed.
ROM:0482 NextBit:
;--------------------------------------------------------------
; BREAK CHECKING
ROM:0482                 ld      a, 7Fh
ROM:0484                 in      a, (0FEh)  ;read SPACE.
ROM:0486                 rra
ROM:0487                 jr      nc, TotalExit  ;if pressed, early exit.
;--------------------------------------------------------------
; BORDER AND SPEAKER HANDLING
ROM:0489                 exx
ROM:048A                 ld      a, c
ROM:048B                 xor     b
ROM:048C                 ld      c, a
ROM:048D                 out     (0FEh), a
ROM:048F                 exx
ROM:0490                 ld      l, 1Eh  ;timeout for waiting for an edge.
;--------------------------------------------------------------
; LOOP FOR WAITING A POSITIVE TO NEGATIVE EDGE.
ROM:0492 WaitFor0:
ROM:0492                 dec     l  ;update timeout value
ROM:0493                 jr      z, TotalExit  ;if timeout, early exit.
ROM:0495                 in      a, (c)  ;reads clock and monostable
ROM:0497                 jp      m, WaitFor0  ;loops while clock is '1'
;--------------------------------------------------------------
; LOOP FOR WAITING A NEGATIVE TO POSITIVE EDGE.
ROM:049A WaitFor1:
ROM:049A                 dec     l

ROM:049B                 jr      z, TotalExit
ROM:049D                 rra   ;stores last monostable value read into carry.
ROM:049E                 in      a, (c)  ;reads clock and monostable
ROM:04A0                 jp      p, WaitFor1  ;loops while clock is '0'
;--------------------------------------------------------------
ROM:04A3                 rl      h  ;load monostable value into H
ROM:04A5                 jr      nc, NextBit  ;if H is not full, go 
                                              ;for the next bit.
ROM:04A7                 ret
ROM:0535 TotalExit:
ROM:0535                 pop     hl  ;discard return value for this routine
ROM:0536                 xor     h  ;clears carry?
ROM:0537                 ret  ;return to the caller of the main load routine.

Here you have a live demonstration of the Sprint, loading a copy of Jet Pac, previously recorded in a standard cassette at the ROM speed:

https://www.youtube.com/watch?v=ofBmvjuuIBg

(FINAL NOTE: this answer is a copy of an answer I gave at the WOS forums about 5 years ago. The pictures are from my own Sprint cassette. I've copied it for the sake of preservation, in case the forum vanishes or something. The link to my answer, along with comments from other fellow WOSers, is here: https://worldofspectrum.org/forums/discussion/comment/554708/#Comment_554708 )

That's pretty neat. I'm still curious if there's any particular reason computer manufacturers so seldom took any interest in cassette speed? Of course, Commodore didn't take any interest in their disk drive speed either, as evidenced by a Euro-demo tape which loads from cassette at a transfer rate faster than that of Commodore's disk drive, while showing a title screen and playing music. — supercat, May 14 '16 at 21:50
@supercat Fast, reliable, and cheap ... pick two. Its not really that they didn't "care" about speed, more just that they prioritized reliability and low cost. The slower speeds allowed for more robust, less error prone protocols to be used. In Commodore's case, they took that to the extreme by using PWM encoding instead of FSK, even though that required that they add specific electronics to their drives preventing the use of off the shelf standard tape recorders like other computers of the era could. — mnem, May 14 '16 at 22:16
@supercat As for the slowness of Commodore's 1541 series drives, that was for compatibility reasons. By using a serial interface with basically a full computer on the other end inside the disk drive they ensured that it could be hooked up to basically any Commodore computer with a serial port. They made faster drives for specific computers using other buses like the PET on an IEEE-488 interface. — mnem, May 14 '16 at 22:29
@mnem: Compatibility with what? When the C64 was introduced, there were two computers that used that style of port (the C64 and the VIC-20), and there only existing drive that used that style of port (the 1540) wasn't compatible with the C64. The C1541 was a tragically-bad rush job; it kinda sorta worked, but should have been way better. — supercat, May 14 '16 at 22:46
I recall having read an article which explains why the 1541 was so slow, and it seems like there was a mistake in the design of the CIA, and an operation that was meant to be handled by hardware had to be emulated by the CPU using bit banging, and hence, slower — mcleod_ideafix, May 15 '16 at 00:06
@mcleod_ideafix: What I remember was that original intention was to use the VIC-20's VIA, but that was defective, so a bit-bang protocol was used. I don't know where the PIA fits in. It's too bad nobody back then came up with I2C-style two-wire handshaking, since adding a handful of gates would have allowed fast speeds in cases where both ends could manage it, but still guarded against data loss or corruption if either end became momentarily unexpectedly busy. — supercat, May 16 '16 at 13:37
@mcleod_ideafix: [the basic idea with I2C is that for each bit the master device will momentarily assert the clock wire, and every slave will hold the clock wire low until it has processed the data and, if necessary, formulated a response]. — supercat, May 16 '16 at 13:39
@mnem: I find the choice of PWM encoding strange. Slower than FSK, and I can't see that it would have been particularly more reliable. Actually, I wonder why Manchester coding doesn't seem to have been used much, since it would be 50% faster on average than variable-speed FSK and twice as fast as fixed-speed FSK, while having a worst-case 2:1 long/sort ratio and maintaining DC balance +/-2, which is the same as 2:1 FSK. — supercat, May 16 '16 at 14:53
@supercat It should be noted that cassettes were an inherently unreliable media (especially for digital/data) and most of that unreliability (in the short term) came from tape stretch. Engaging the read/write heads while it was in FF/REV speeds would naturally exacerbate that problem. The only obvious way to compensate for this problem would be to use shorter tapes (both because shorter means less stretch and because shorter tapes could have thicker mylar) which would mean less data storage. Then there's the long-term problem of dropouts from coating wear, made much worse by hi-speed R/W. — RBarryYoung, May 16 '16 at 15:47
@RBarryYoung: Abuse of tapes could obviously cause trouble, but tapes were considered suitable media for music where a momentary 1% speed deviation would be quite noticeable. The only case I would think higher speed would make things worse would be when hitting the start/end of a tape, and if a tape had a suitable leader on the ends I wouldn't think the leader could take the brunt of that rather than the reset of the tape [indeed, I my understanding is that part of the purpose of the leader is to protect the rest of the tape]. — supercat, May 16 '16 at 15:54
@supercat You are conflating "tapes" with "cassettes", and during this period cassettes were considered the 2nd least reliable form of tape (after 8-tracks). As it happens I worked part-time as an audio engineer during this period (late 70's early 80's) and I can tell you that no professional studio or audio engineer would willingly rely on them until the late 80's when DAT and other super-high quality formats came along. I can also assure you that the problems I mentioned hi-speed R/W were very real and well know. It's why all normal cassette players disengage the R/W heads for FF/REV. — RBarryYoung, May 16 '16 at 16:08
@RBarryYoung: If starting and stopping cassettes routinely stretched them enough to cause a 1% speed variation I don't think they would have been a popular music format. Professional studios would use higher-quality equipment for mastering, but I don't think companies would have made high-end cassette equipment if nobody used it. — supercat, May 16 '16 at 16:15
@supercat You're still making a lot of bad assumptions. First, the technical term for the effect caused by this is called wow and flutter, you can google it, there are still many descriptions of what a big problem it was, esp. for cassettes. Modern cassettes & players can typically maintain about 0.08%, this was much worse back then. Because of the poor quality of home equipment, this was not typically noticeable by amateurs, but pros could, esp. w their better playback. ... — RBarryYoung, May 16 '16 at 17:55
@supercat ... All of which is moot, because you are talking about 4x faster R/W, and this definitely affects the quality in a myriad of ways, and it gets worse over time. The best recorders ($2000+) could deal with it, but what was in PCs was pretty close to retail grade because of the price points. The end result was that cassettes worked in home computers, but they were not reliable, especially long-term. And some did have hi-speed R/W, but this was even more unreliable. — RBarryYoung, May 16 '16 at 17:58
@supercat Here's the Wikipedia article which provides a very minimal description of some of this. As an engineer for a college radio station, our small budget, and of course our on-air personalities (college students) meant that we had to deal with these problems all the time. — RBarryYoung, May 16 '16 at 18:02
@RBarryYoung: By my understanding, wow is slow frequency modulation caused by things like a record sitting off-center; flutter is faster frequency modulation caused by things like non-uniform drive wheels; both of those are traits of a player. Tape stretching, however, would represent damage to the recording media. Obviously there's some speed where starting and stopping the tape would cause tape streching, but I wouldn't expect normal operating speed to be within 50% of that [I would expect more players could achieve 2x than 4x merely via resistor change]. — supercat, May 16 '16 at 18:14
@supercat The amount of tape stretch depends highly on the thickness of the backing used in the tape. Since the amount of space for tape inside the physical cassette is finite, shorter tapes would have more room for thicker backings, which is why cassettes advertised for data purposes were normally C10 or C15 (10 or 15 minute run time), as they could have the thickest backings and thus were prone to the least amount of stretch. Relying on the consumer to buy the correct tape to get good reliability isn't always the best path, especially when C60s were often the cheapest option available. — mnem, May 16 '16 at 18:41
@mnem: Many encodings allow synchronization on each bit, which should allow them to tolerate 5% stretching without any problem whatsoever (RS-232 communication only synchronizes once every ten bits and can tolerate up to 5% speed mismatch between sender/receiver). For many encodings, even arbitrarily lengthening or shrinking individual bits by up to 25% would have no effect. Why should data be more readily corruptible than music, where a transient pitch change of even 1% would be noticeable and 5% would be obvious? Did some playback routines count pulses without synchronizing on them? — supercat, May 16 '16 at 18:47
@supercat Basically, yes. FSK, as typically used on data cassettes of the era doesn't do any synchronization and relies on consistent tape speed to maintain readability. PWM as used on the Commodore data cassettes doesn't do any synchronization either, but since its encoding the data on the duty cycle it doesn't matter what the exact timing of the pulses is, only that a long and short pulse are proportional to each other. Although Commodore still recommended the use of quality C10 or C15 data tapes, PWM made it more reliable when the end user inevitably slapped a cheap C60 music tape in. — mnem, May 16 '16 at 19:00
@mnem: Why would an FSK receiver not be written to synchronize on the data stream? If each "1" represents some number of waves of one frequency, and each "0" represents some number of waves of another frequency, it should be easy to write code to time how long it takes for each pulse to arrive and build a data stream from that. What's the difficulty? I'm well aware that FSK modems for telephony typically used hardware frequency detection that would lack sync output, but that's in part because they needed to be full-duplex, and were attached to async serial ports anyway. — supercat, May 16 '16 at 19:12
@supercat I believe the difficulty would be that there is no communication from the computer to the player in a typical data cassette setup. You have a consumer tape recorder hooked up to the computer by an audio and mic line only. Its easy enough to detect when the incoming data has an error, but you have no way to correct for the problem other than to throw up an error. Even the Commodore datacassette which has some on board control logic is only capable of starting and stopping playback via the motor control line, it has no way to cue the tape back and reread a section. — mnem, May 16 '16 at 19:31
@mnem: Why would synchronization require rereading anything? If the audio from the cassette drives a simple comparator circuit which in turn feeds an I/O port (preferably, for 6502-based systems, one that reads as bit 7 of some address), I would think the easiest ways to decode FSK would also be self-synchronizing. — supercat, May 16 '16 at 19:37
@supercat Wow and flutter (they go together) represent audio deficiency attributes, they can be caused by many different things and can vary with both the media and equipment. For tapes, wow and flutter can indeed be caused by tape stretch. — RBarryYoung, May 17 '16 at 11:54
@mnem "no way to correct for the problem other than to throw up an error." FWIW some micros would (on detecting a CRC error on a block) prompt the user to "Rewind tape" (and then retry reading the block again). — psmears, Nov 02 '21 at 11:16

score 6 · Answer 2 · answered May 16 '16 at 17:45

You could consider the Coleco ADAM as one of the machines that did such tricks.

Though it has been 25+ years since I owned one of these machines, I do remember a few things about them. For starters, it used custom cassettes rather than normal consumer bought audio tapes despite being the same form factor; I do seem to recall that there was an extra hole in the cassette to prevent you from using consumer audio tapes, though you could defeat that with some power tools. I believe it was more than just being a CrO2 or Metal cassette in that they were more durable given the high speeds the drive would push: 20 ips (inches per second) for read/write, 80 ips for cue/rewind.

I believe the ADAM tapes were single-sided only, though I don't recall if the tape head was 2 or 4 tracks (I'll assume the latter because of the ease of getting parts). What was interesting about these tapes is that not only were they fast, but they had full seeking capabilities. In other words, just like how a floppy disk head will jump and sweep from track to track, the cassette would speed up to 80 ips to seek the tape and then drop down to 20 ips for read/write. Yes, the seek would go in either direction, though I think read/write ONLY went forwards. Assuming the 4-track configuration, I'd guess that one track was always position and the other three probably weren't that much different than typical disk sector data patterns.

I don't remember much else about the drives, but they weren't as fast as an IBM / Apple II disk but certainly faster than normal cassettes.

I remember another machine (Teletype replacement) that used those same "data" cassettes. It was in my high-school's math lab. And yeah. We used to file a notch in the top of an audio cassette to make it fit. And it would work just fine. — Solomon Slow, Nov 02 '21 at 21:36
IIRC, the Adam tapes were formatted though. The "full seeking capabilities" depended on that, and the formatting could only be done at the factory. They did not provide any software to run on the Adam that could format a new tape. — Solomon Slow, Nov 02 '21 at 21:37
@SolomonSlow interesting bit about the formatting. Maybe if you had a dual cassette player, you could just duplicate an existing Adam cassette on to a non-Adam one and get the formatting that way..? Off to the internet FAQs I suppose :) — bjb, Nov 02 '21 at 22:06

mcleod_ideafix · Answer 3 · 2016-05-15T11:48:41.353

Not really a cassette improvement, but audio anyway: the CD Games Collection from Codemasters came with an adapter that meant to be connected to the joystick port of the computer and the headphones out of a CD Player. The games were recorded with a custom loading scheme, much faster than standard loaders, thanks to the absence of background noise, wow and flutter.

Theorically, the game would be recorded using both left and right tracks, as the audio plug is a stereo 3.5'' jack and the joystick connector seem to have two pins wired. A simple audio analysis shows that it isn't true, and both tracks carried the same signal. Besides, and according to Jose Leandro's research, the loader routine listened to only one pin from the joystick connector. He inferred how the inside circuit would look like:

So it seems that the recording and the loader routine were made after the cable was designed, and they were in a hurry to release this collection, so they couldn't debug it enough and decided to go with a mono signal version and a more reliable, although slower loader.

More about this in Jose Leandro's hardware page: http://trastero.speccy.org/cosas/JL/CableCD/CableCD.html

And speaking of loading through the joystick port. Long time ago I tried to do something similar (although I didn't hear about the CD Games Pack until years after). My approach is to use 5 pins from the joystick port to carry a parallel 4-bit digital signal (using the direction pins), and a clock (using the trigger pin). I could even make it DDR, i.e. accepting data on both the rising and the falling edge of the clock signal. With this approach, I achieved about 155kbps.

Details about this experiment can be found on my website: http://www.zxprojects.com/index.php/external-ultra-high-loader-for-the-zx-spectrum/14-proof-of-concept-alchemist

This is a demonstration of such technique. I use a microcontroller to store the program I want to load, along with the bit banging code that converts it into a series of nibbles to be sent over the joystick cable. The routine at the computer end merely needs to wait until a clock edge happens and then, read the data present in direction pins, store it and when the second half is read, assemble a byte and store in memory. I think the technique can be extrapolated to any computer that has a digital joystick port, and the microcontroller part can be changed for a PC with a FTDI chip with assist from software to do the bit-banging part, loading a program from USB.

https://www.youtube.com/watch?v=i8Sv9riKVwg

I wrote a boot loader in 1994 to fetch Atari 2600 code from a PC serial port plugged into the joystick port (via adapter) after I bought Harry Dodgson's monitor cartridge. His monitor included such functionality in 7800 mode, but I think he only used 2400 baud. I forget what I used, but was probably at least 19200. Even 57600 baud should be achievable without difficulty if code is doing nothing but waiting for incoming bits. — supercat, May 15 '16 at 20:02
I believe the reason for a mono instead of stereo signal was that some cheapo CD players of the era only had one DAC, and "faked" stereo by decoding only one channel at a time. The human ear couldn't tell the difference, but your Spectrum could - so they fell back to using mono. — KenD, Mar 18 '21 at 15:43

score 3 · Answer 4 · answered May 14 '16 at 17:03

3

The Philips P2000's mini-cassette drives were 10x speed. Do mini-cassettes count?

Otherwise, there were tape recorder mods like the RamBIT for higher speeds. And on various computers you could POKE values or use special software to load and save at higher baud rates, usually up to 2400 baud (600 baud was standard), depending on the quality of the tape and what speed you've set your recorder to.

And here is software that allows a Spectrum to load from the cassette port at up to 27,428 baud.

answered May 14 '16 at 17:03

snips-n-snails

17,548
3
63
120

Do you know anything about how the Philips worked? My primary interest was in whether any machines used simple means to increase the fastest speed the hardware could support (I know some software pushed speeds well beyond what the built-in loaders could handle, but I would think simple hardware mods would allow speeds to be pushed higher still. – supercat May 14 '16 at 20:21
Of course, pushing hardware speeds would only be relevant for manufacturers that tried to push software toward the upper limits of hardware, which many manufacturers--from what I can tell--didn't. – supercat May 14 '16 at 20:23

score 2 · Answer 5 · answered May 16 '16 at 13:29

The Commodore 64 had many different tape loaders. Game publishers often included them, especially in Europe, as the C64 had on average more memory to fill and the standard tape routines weren't very fast. The exact same tape routines exist in the PET, VIC20, C64, and C128 because when Chuck Peddle wrote them and he left Commodore, the secrets of the logic of the routines left with him.

score 2 · Answer 6 · answered May 16 '16 at 20:25

Digital Group offered a 5x-speed (as I recall) tape drive called Phi-Deck. This was around 1978. It was a poor man's floppy disk, because it supported a file system, and a primitive operating system, PhiMon.

Some details are here: http://bytecollector.com/dg_phideck.htm

score 0 · Answer 7 · answered Nov 07 '21 at 22:19

The Commodore PET, VIC-20 and 64 had a third-party solution, the Rabbit cartridge by Eastern House Software. Rather than speeding up the cassette player motor, though, it made a second connection from the cartridge to the cassette audio line by using a jumper, which you folded over the connector to the C2N tape player. Here's a picture from eBay:

On the 64, the cartridge reimplemented load, save and verify routines, added additional commands, and had an empty socket for additional software — none of which ever came, that I know of.

Here's an ad describing the Rabbit:

On the Commodore 64, the Rabbit used 4K of RAM (leaving you with 34815 basic bytes free).

Did any microcomputers back in the day accelerate standard-cassette performance

7 Answers7