Could standard cassette use stereo tracks to double data density ?

[catmeows]

Perhaps it is stupid question, but I will ask anyway. I read some articles about ZX Microdive and I noticed that microdrive used two tracks for data. So I wonder, in general, could home computers use stereo recording to double data density (and halve loading times) ? And is it really as simple as adding data lines for second track or are there some technical problems ?

[TMD2003]

I used to own a four-track recorder - which is most likely what would be needed for this. A standard stereo tape deck, when recording, erases both tracks before then recording both at the same time, so it'd need to be modified to leave one track alone while erasing and recording the other. Any cheap model with a permanent magnet as the erase head will be a dead loss for this purpose. But, in theory, a four-track or eight-track recorder could do this straight out the box. I have no way of testing it these days.

I'd considered trying this with a CD-R - if there are two programs with equal (or just about equal) loading times, one could be on the left track and one on the right, though it would also require a modern-ish (post-1990s) PC with some editing software and an audio CD burning program to make it work. When it's done, feed either the left or the right channel from the CD player into the EAR socket and that should work.

[1024MAK]

A normal compact audio cassette tape can actually have four tracks in total. Two (for stereo) for each direction of the tape. In theory, there is no good reason why all four tracks could be used for one just a single direction (but you could not use the tape in the opposite direction).

In regards to your specific question, yes, it’s possible. And yes, loading times could be halved approximately. But there are a number of issues.

The first is that at the time most home computers were deliberately designed to use low cost mono cassette tape decks. Yes, at the time stereo cassette tape recorders were available, but cost significantly more.

The next problem is that the ULA already uses all of its chip pins. Adding an extra tape (audio) input channel means either another ULA function being dropped, or a larger (more expensive) chip.

Finally, most of the Speccy cassette LOADing system is software (firmware) in the ROM. It’s the Z80 running this (or an alternative) software that works out what (if anything) the tape signal means. And we all know what happens when it goes wrong. Adding a second track and channel would significantly increase the complexity of the system.

Are there other solutions to the above problems? Yes, but they all require more hardware, and hence would cost more.

Mark

[1024MAK]

Of course, if you have a stereo cassette recorder and two Spectrums, with the right recording and a suitable lead, you could load two different games from one tape onto your two Spectrums

Mark

[Wall_Axe]

I think someone on youtube may have mocked up a tape recorder that simply played its track faster, and loaded the games quicker -lol

I wouldnt know how to search for that on youtube but ill give it a try.

[TMD2003]

I think someone on youtube may have mocked up a tape recorder that simply played its track faster, and loaded the games quicker -lol

That does work, because I've tried it before - a standard ROM loader can be sped up to around 15% faster than usual before the Spectrum has a fit. All that needed was a WAV, Audacity and a tape adapter to get the sound into my +2B.

[Wall_Axe]

This bloke sez ten times faster

[Mpk]

Could you load two different games on 2 Spectrums at the same time? From one tape?

Just imagine how useful that would be.

[SNG]

I think someone on youtube may have mocked up a tape recorder that simply played its track faster, and loaded the games quicker -lol

I wouldnt know how to search for that on youtube but ill give it a try.

The SAM cassette loader (ROM source freely available) adjusts to the relative speed of the CPU and player. If your cassette recorder is variable speed (like Bruce Gordon’s) it will tapes load reliably at whatever speed you play them. And it takes advantage of that by also allowing the speed of SAVE to be selectable.

This could run just the same way on any 48K or 128K Spectrum (in uncontended RAM of course) or on Next. The upper limit is determined by the external drive and media, I reckon about 9000 baud to/from DAT or Minidisc.

This similar to the Codemasters CD compilation which loaded ZX games via a connection between any CD headphone output and a joystick interface. That could’ve been twice as fast by using both stereo channels and two joystick bits, but at 3.5 MHz the software timing gets tricky so it wasn’t. Loading 48K in around half a minute was good enough.

As regards stereo input, the ULA only has one tape input pin so No that wouldn’t ever work.

[Old-User]

I think someone on youtube may have mocked up a tape recorder that simply played its track faster, and loaded the games quicker -lol

I wouldnt know how to search for that on youtube but ill give it a try.

The Philips D6350 player did just that with regular tapes.

[flange]

A normal compact audio cassette tape can actually have four tracks in total. Two (for stereo) for each direction of the tape. In theory, there is no good reason why all four tracks could be used for one just a single direction (but you could not use the tape in the opposite direction).



Mark

Tascam and Fostex porta-studio home recording devices used a four track head for recording/playback and as you describe was unidirectional, with track bouncing you could layer ten tracks but not sure if that would be useful in this application.

[1024MAK]

The upper limit is determined by the external drive and media, I reckon about 9000 baud to/from DAT or Minidisc.

To be clear, the Ear input circuit for ZX Spectrums contains a network of resistors and capacitors, this will limit the range of frequencies and hence the maximum practical loading speed via the Ear input socket.

However, if you use another input, then much higher speeds are possible. Such as using a joystick port or a bit bashed serial port (the RS232 port on the Interface 1 or on the 128K models).

Exactly like the Codemasters CD did.

Mark

[winston]

One thing that surprises me is that no one back in the day used phase shift keying, all the loaders I've seen were basically variations of the ROM FSK (frequency shift keying) loader (where a 0 was a short low-high pulse, and a 1 was a long low-high pulse, meaning a 1 took longer than a 0).

Phase shift keying could have made the 0 and 1 the same length without requiring more bandwidth, and still having an edge per bit (allowing for easy timing recovery, and the wide variability of tape recorder speeds). e.g. you encode a 0 as a low to high, and a 1 as a high to low of the same length. (The sync pulse can be used to determine the polarity). Better still, you could combine FSK and PSK encoding two btis per symbol speeding things up significantly without requring more bandwidth from the tape recorder/EAR circuit.

[MonkZy]

The cost of a four track tape deck would diminish the return of using less C-15's for your data. The difference in cost of a C-15 to a C-60 is minimal. It should have been adopted though, because of conservation of resources. Commodore and later Amstrad/Sinclairs shipped with dedicated tape decks..a tape saving opportunity missed.

[PROSM]

Phase shift keying could have made the 0 and 1 the same length without requiring more bandwidth, and still having an edge per bit (allowing for easy timing recovery, and the wide variability of tape recorder speeds). e.g. you encode a 0 as a low to high, and a 1 as a high to low of the same length. (The sync pulse can be used to determine the polarity).

If I understand correctly, what you're suggesting is essentially Manchester coding? If so, I can get my head around it, and that part of using the sync pulse for polarity detection is quite clever. What I'm having trouble with is this bit:

Better still, you could combine FSK and PSK encoding two btis per symbol speeding things up significantly without requring more bandwidth from the tape recorder/EAR circuit.

To my mind, this means something like this:



But then that means if we have a code like 00 11, we now have the signal being high for 3 clocks, which surely is a bit too much for reliably detecting the timing?

Deciding if it's one or two clocks between transitions works obviously, but would things hold up if the choice was 1, 2 or 3? Though I guess we already know what the 00 code is as soon as we see its low-high transition, so then we just run a delay loop until approximately one clock has passed (to get to the 00 symbol's end), then sample the tape input to see if a transition has taken place, then sample it again one clock later to see if this a high frequency symbol or low frequency symbol?

Apologies if I've mangled things here, I'm just writing my thoughts as they come. It's a very interesting idea, but I can't quite visualise how you'd go about writing the loader to account for speed variations in the tape deck.

[zx64]

Another option is MFM modulation, like in floppies and early hard drives. It would double the speed.

[cj7hawk]

They even made a video camera that used audio cassettes, so cassette bandwidth is actually pretty impressive if pushed to the limits.

https://www.popularmechanics.com/techno ... cassettes/

[cj7hawk]

Another option is MFM modulation, like in floppies and early hard drives. It would double the speed.

Or RLL...

But the challenge is doing it in software. At some point external hardware is required to support the solution and recover the clock.

Even the Spectrum software based solution can be improved, but they did at least opt for a variable length encoding system that meant some data was twice as efficient as other data. A custom solution that recognizes this would be optimal.

And given the audio nature of the signal, quadrature encoding would be possible also - that is, encoding data in phase and amplitude like Wifi does

[equinox]

My father was into ciné-film, and some of the formats had separate picture and audio that needed to be synchronised. So that's how they did those fancy C64 music loaders.

[berarma]

Perhaps it is stupid question, but I will ask anyway. I read some articles about ZX Microdive and I noticed that microdrive used two tracks for data. So I wonder, in general, could home computers use stereo recording to double data density (and halve loading times) ? And is it really as simple as adding data lines for second track or are there some technical problems ?

I guess there could be issues with cross-talk between channels both in the cassette player and computer electronics. It would have added another source for errors and more hardware complexity.

[catmeows]

They even made a video camera that used audio cassettes, so cassette bandwidth is actually pretty impressive if pushed to the limits.

https://www.popularmechanics.com/techno ... cassettes/

Yeah, i know about PXL camera. It Is such obscure toy hardware I cannot decide it Is awesome or just crap.
There was also SPRINT tape recorder that used 4x tape speed to shorten loading (https://spectrumcomputing.co.uk/entry/1 ... nge_Sprint).
All together, it is fascinating how both Atari and Commodore failed to provide good tape hardware even when they provided custom tape unit.
In late 90, when CD was a thing but cassete was still relevant as portable audio I had a walkman that could play both sides of cassete in infinite loop. It could even find gaps between songs during fast forward operation. I just thought that a cassete player with bidirectional play, 4x speed and using two tracks would offer loading times similar to wafadrive.
Another obscure thing was QuickDisk which used custom floppy format but instead of concentric tracks on floppy it had a single spiral track (no need for a step motor I guess).
Stiil, Apple Disk Ii is the most fascinating piece of hardware as they were able to manufacture units under $100 (And sell for $500).
From that point of view Microdrive was quite achievement as it offered experience comparable to floppy for fraction of floppy price.

[winston]

But then that means if we have a code like 00 11, we now have the signal being high for 3 clocks, which surely is a bit too much for reliably detecting the timing?

I would imagine it's still good enough unless the tape recorder is *really* awful.