Thread 106016612

what kind of programs could you actually run on a cassette? if it's sequential read only, it must be super limited right?

>>106016612 (OP)
You're not limited by any of that; It's a ram issue. Look at computer rooms in the 70's running all sorts if things stored on tape.

>>106016612 (OP)
You read the data on the cassette into ram and then execute.

>>106016612 (OP)
> what kind
anything. it was primary distribution format until disk drives became affordable
> it must be super limited right?
only by the length of tape and memory. it's roughly 1500 bits per second for apple 2. quite a lot of shit can fit on one 60 minute tape.

>>106016676
>1500 b/s
what if you tried to speed up the motor in the tape reader to get more bandwidth?

>>106016709
The software would most likely fail to read correctly unless modified for the hack.

>>106016612 (OP)
4chan lan

>>106016709
i don't think the circuitry would understand it. what you can do is make the tape load faster by reducing the amount of information written to the tape, such as using compression or removing bloated error correction schemes and using your own custom loaders.

>>106016612 (OP)
The computer would read the contents of the cassette into her memory then she was free to move about. It's like how you can sing the chorus of a song you know on demand without singing the first verse, but you have to listen to the whole song first.

Most computers could use the 'remote' line of the cassette input to start and stop the tape under software control. This allowed for primitive forms of data swapping but because it couldn't fast forward or rewind, it could only replace loaded data with data later in the tape.
One interesting use, for the time, was interactive literature. Data would be loaded in, the student would see graphics on the screen to go along with audio being played from the cassette.
The Coleco Adam computer included a high speed tape deck that could ff and rwd, making it a simple form of random access data drive. Too bad they fucked up some other aspects of the computer, causing the tape drive to be destructive to data.

>>106016709
People bought the cheapest, shittiest quality, thin tapes to save money. As a result, the format had to be very fault tolerant. Even with that, it was common to lose data saved on cassettes. If you had a good quality tape deck and used only high quality cassettes, it worked pretty well. Some programmers would create their own custom loaders that could use data of much higher density but that only worked if you used quality materials.
I never saw one in person but apparently a few computer owners of that era hooked up reel-to-reel audio decks to their computer, giving them the ability to store tons of data in short segments of tape. This too required custom loaders to work.

>>106016612 (OP)
You're not going to be streaming data from the tape to the CPU for processing, no, but you can copy data into memory as needed.
Data on tape is also often referred to as "files" and have header data attached, so your program can "look for" the specific data it is after on the tape, though if you have a large tape (like a 30 minute per side one) just setting it playing and letting the program find the correct file would be very slow. You'd want the program to tell you what the next file is and have an idea where that is on the tape so you can seek to it.

>>106016676
Depending on the encoding format you use there can be a lot of overhead on tape data, though.
The format that Sharp used (a PWM based one) had something like 15 seconds of gap per "file" saved, 9 seconds before the header data and 4.5 seconds between the header and the file data itself. So you could easily have more time waiting in the gaps than spent reading the data itself.

>>106016709
The bitrate is more based on the code for reading/writing to the tape. It's agnostic for how fast the tape is running, though recording at one speed wouldn't read at another speed.
In many cases you can replace a tape recorder with any digital audio recorder.

>>106018440
old fag here. when I was a kid me and my Dad bought a TI-99/4a. We joined the local TI user group. They had a big repository of software on cassette tapes, and a nothing fancy tape duplicating machine, and we used to run off copies and copies of copies and they all seemed to work. None of it seemed very hi-fi.

thanks for listening, I'm off to change my incontinence pad now

>>106018505
The two biggest problems I saw were people using C-120 (or heaven help them, C-240) cassettes, which were so thin that they often get snagged into the cassette player's mechanisms or would simply break, while the other big problem was using a tape deck that they also used for playing music. Music cassettes got traded around, put in filthy decks, and would spread around all manner of gunk, magnetic and otherwise. That would damage the data cassettes played in those decks.
You probably saw some of pic related, where computer magazines sometimes would include a program on a thin vinyl record. While you could in theory hookup the turntable's output directly to the computer's audio input, those records would quickly wear out so it was best to transfer to a cassette first.

https://web.archive.org/web/20240606013759/https://original.sharpmz.org/mz-700/tapeproc.htm
Here, you can read about how data was stored on tape by the MZ-700.

>>106018459
seems like sharp went completely overkill with that format. if i recall correctly some c64 tapes loaded very slowly because they used commodore's rom, which adds as much error correction data as actual data. games developers and independent developers came up with much better solutions than commodore could have dreamed of at the time without any hardware modifications.

Stringy floppy master race represent!

https://www.youtube.com/watch?v=aymR-db0u3Y

>>106018655
Yeah, it is overkill. I assume part of it is to help the user seek to files (you can tell a long gap from a short gap even when seeking, if the recorder plays the sped up audio) and you can type/start the command to begin the load while the long gap is playing.
But, yeah, if you see in >>106018609 the format has two copies of the header data and two copies of the file data, both with checksums so it can verify integrity.
Family Basic mostly copied the format for its tape recorder functionality, but removed the duplicate data, changed up the lengths of the gaps/marks too.

>>106016612 (OP)
You could run any software you wanted. You could easily swap the cassette with another and save your data on different cassettes. It was very simple and intuitive, in fact.

The only limit was the computer ram

>>106018936
so in theory, if you had like, 128k ram in the apple ii, you could run a mouse/gui desktop environment off of tape?

>>106018960
You wouldn't even need a tape recorder to do that.

>>106018982
really? how would i run it? i thought these systems didn't have internal storage for an os so you have to run the loader and then run w/e you wanted.

>>106018992
Put it on a ROM chip.

>>106019006
ah i see, i didn't know that was an option. i thought rom was something that had to be factory set or it was off the table.

>>106018992
You could be like Woz and literally key it in by hand from memory during the club meeting.

>>106019013
Nothing's truly off the table, it just matters how much money, effort, design work, and time you're willing to spend.
You can have a light across the room illuminate a pv cell to change bits.

>>106016612 (OP)
They are read into RAM first, so there is no limitiation on the programs Structure.
My dad recorded C64 programs that were distributed over the radio in his youth.

>>106018440
Now I want to hook up my Revox B77 to my C64. Fuck you, that thing weighs almost 20 kilos.

>>106020469
That's a sweet piece of hardware. You should thank me for giving you an excuse to get some more enjoyment out of it.

>>106016612 (OP)
You had to buy special computer cassette tapes, because regular ones had dropouts which would fuck up the save/load. It was good practice to save the program more than once on the tape, in case it did fuck up.

>>106016672
Fat and dumpy Rin, huh? That's kinda hot.

>>106018440
>reel-to-reel
I've often thought about the effectiveness of getting really thick magnetic tape and really high speed reels and seeing how much you could store on them like in the modern day, I'm talking reels that spin so fast if one of them falls off it's going to like, put a hole in the wall

>>106016612 (OP)
the contents were loaded into ram and run from there

>>106020857
One thing most cassette purchased at Kmart and similar places had that were removed from data cassettes was the leader. More than once I saved something at the start of a cheap tape and didn't remember the tape had a leader on it that needed to be moved past before anything could be saved. But after the pain of doing it a couple of times, I learned to always check.
Pic related seemed to be in every computer magazine of the time. I don't see it mentioned in the ad but they were leaderless tapes. Ten minutes was more than enough for all but the longest programs full of data. Think the only time we ever went over was when we had a mail merge program for the church directory. That required flipping the cassette over.

>>106021030
I've seen videos of mainframe type tape drives like pic related going insanely fast but I have no idea how much data they were actually transferring. One of them coming off their hub probably wouldn't get through a wall but I bet it could leave a bruise if you tried to stop it with your bare hand.

>>106021124
I fucking love mainframe computers, imagine what you could do packing those cabinets with modern hardware or something