For fun I started perusing the 'Transactor' newsletter/magazine from issue 1 in 1978. Of course these early issue concentrate on the CBM Pet computers, which as you might know had a built in cassette tape deck. I never realized that they also had a connection for a second cassette deck so you could have a 'data' tape and 'program' tape. It used same card edge connector used up through the Commodore 128.

Another interesting tidbit, the tape loading interacted with BASIC such that you could 'overlay' a loaded program over your current program. If you include the 'main' section of your code with each subsequent 'overlay' you could load in new functionality or subroutines based on user input, etc. A very clever idea I thought, I wonder how it actually got used though.

Anyhow, just thought I woudl share. I found the idea of dual cassette decks kind of novel.

Overlay is a reasonable idea if you have a disk-based filesystem or an automatic tape seek function. The cassette drives attached to home micros don't really fit that bill, so you could only sensibly load overlays in strict sequence - rather limiting the suitable applications. Tape drives on minicomputers and mainframes are another matter entirely.

I don't see how you could have done BASIC overlays without custom tooling.

Now, I'm going on a crass assumption that the image on the tape is, indeed, binary. I'm also assuming that it's effectively a core dump of the program area of the interpreter, rather than a "listing" that's reloaded. Which suggests that when loaded, it overwrites the entire program currently loaded. Now, I don't recall, I honestly never tested it, but I don't think I ever had a loaded program "overlay" a program in RAM already. I don't recall the instructions being "NEW" followed by "LOAD". We just loaded everything.

I can see a desire for a dual cassette deck for data processing, reading one while writing to another, though I don't know how well that would work. I guess as long as the channel is open and the tape recording, that some baseline carrier tone is being recorded if data is not being written yet?

When I played with it I know I could not "re-write" records on the tape. I tried.

Consumer tape decks were never designed for data storage, only music and speech. That machine-readable data could be encoded into sounds at all must be credited to the telecoms industry.

There was no facility for locating a particular location on the tape, except by playing the whole tape from the beginning at normal speed, or relying on the user to manually operate the fast-forward/reverse button while watching the rev counter. Even that rev counter was not rigorously standardised as to which reel it was referred to or how far it advanced, and its speed of advance tended to change with the position within the tape (so you couldn't use it as a block counter, no matter what block size you chose).

There was also no way to rapidly turn the deck around from playback to record, which would be necessary for pre-formatting the tape with regularly spaced block markers at which recording should begin. Instead, playback and recording were controlled by separate mechanical buttons under the user's control.

Proper tape decks for Real Computers™ had enough of these features to make them far more usable as mass-storage devices; even though seeking to a particular block still tended to take a long time, you could leave the computer to do it by itself, repeatedly, until it had finished performing the task you'd set. But they were too big, power-hungry and expensive to market to home users; cassette tapes, by contrast, were cheap and ubiquitous.

The underlying problem was, of course, solved by the floppy disk.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

My point was not so much about how good bad cassettes were w.r.t. other forms of storage, just that they built two cassette interfaces into the PET and the external interface lasted a long time (computer wise). Even without automatic control of the cassette mechanism you could prompt the user to advance/rewind the tape to the correct counter indication for a given section of data/code. Given that disk drives were a VERY expensive proposition in 1978 a second $100 tape deck would be an inexpensive alternative.

As an aside I can remember that my first exposure to computers in 1982 disk drives were still very expensive and a single 5.25" disk was close to $5/each. Or so my teacher claimed at the time, I can still remember him passing out a single floppy to each one of us, telling us they cost $5/each and it we damaged it he would cut that same sized chunk out of our hide! (One of my favorite teachers ever!)

W.R.T. program overlays, in Transactor 1-7 (+-1) there was a description on how to get it to work. Each subsequent chuck of BASIC program you loaded in could be no larger than the original. You would put the part of the code you wanted to keep at the end of the program and before loading in the new code you would need to jump to a subroutine that would find/save the address of the first line of the code you were saving. Then you loaded the new code and the first line of the code that was then executed used the address saved previously to fix out the 'end of program' pointer at the tail of the newly loaded code.

Beacuse the BASIC code built upwards in memory and the varables built down and each line of BASIC was sort fo like a linked list it all worked. It seems a lot of hassel but when 8K was a TON of memory you did what you had to do.

Two tapes is a different story, and matches the idea of the PET as a business machine: you can read from one, and update records and write to the other. Or indeed, have a program drive and a data drive.

The Hobbit drive did have computer-controlled transport, like a grown-up 9 track drive:
https://nascom.wordpress.com/other-stuff/the-hobbit/



My first two computers had cassette tape storage - it was very normal in the UK. (Only Apple had a relatively less expensive story for floppy drives, but the overall package was still very expensive. Until a little later, when I did get a dual floppy drive for my Beeb. The Beeb was another machine with control of the tape motor, which allowed the possibility of writing data records to a tape, say from a machine collecting data in a lab. The Beeb's cassette format was record-orientated, with inter-record gaps, so this worked well enough.)