Which classic computer had the better or best storage sub-system BITD.

[Keatah]

When comparing classic consoles and computers the main focus is always on the CPU or Graphics/Sound chips or sometimes even the amount of memory or bus architecture which ties it all together. Rarely is the disk or tape storage subsystem mentioned in such discussions.

 

I know little about the TRS-80 or Ti-99/4a floppy drives for example. But the Apple 2's DISK II was/is a model of simplicity and speed when compared against the hot and heavy Commodore 1541 or to a lesser extent the Atari 810.

 

And Apple II hard drives like the Sider maintained a complete parallel data path from the disk head shift register all the way till data got stuffed into main memory in the console. So there's another positive.

 

Discuss please.

[Rybags]

BBC was pretty good - onboard FDC controller which gives speed to match the likes of Apple II and the DOS is resident on bankable ROM so minimal intrustion into the 64K memory map and quick startup.

 

But the overall system suffered somewhat since 32K was the typical maximum RAM (disregarding expensive upgrades that use the Tube) - no idea if any HDD solutions were available.

 

Apple II suffers in similar fashion to Atari in that a DOS has to be booted although that's the case with most computers.

 

The C= model is good regarding keeping RAM free and quick startup but loses out a bit in programming flexibilty. The default slow speed of course is well known, so makes the whole disk subsystem a bit of a joke on their home machines.

 

Atari ST fares pretty well in that most of the OS is within ROM, to do much useful on the Amiga required booting Workbench from floppy or HDD.

 

The philosophy of having the drive controller built into the computer made adding disks less expensive but the initial base unit cost of the computer itself goes up.

 

Looking at it from the 80s perspective, it was justified for Atari and C= to do it their way to keep the initial system price down.

 

Best of all worlds though might have been having the controller and drive smarts in the first disk drive then have cheaper "dumb" drives tethered to the first one, although that'd drive the cost of the first drive up somewhat and add to the complexity of the system.

[Osgeld]

Apple II had hard disk solutions(for instance the profile), they were not cheap though

[JamesD]

Parallel interface drives were faster than the serial ones.

The Apple II series, TRS-80s, Plus/4 (if you have the right drive), etc... all had parallel interfaces.

I'm not sure who was fastest among those though.

That often had to do with how each disk was formatted (interleave) and where data was stored on a disk.

Several DOSes could also be modified with faster step rates if you attached a faster drive.

[Keatah]

I found the simplicity of the DISK II (boy am I biased or what?) rather confusing at my early age back in the day. It only had 12 simple chips and 8 of those chips were on the interface card, 4 in the drive. It did what other drives did without the expense and complexity of an onboard CPU, RAM, Firmware ROM, and huge-ass power transformer. BUT HOW?

 

It was totally lost on me (and I didn't give a shit) that the Apple II console itself temporarily took the place of that "expense and complexity". The console "became" the other half of the controller. And during that time of disk access, your programs couldn't do Jack. But I/O was fast enough that I didn't care; thanks to being raised on cassette tapes and type-in material.

 

What I found fascinating was that you could load DOS into hi-memory, the upper 16k block afforded us by the "Language Card". When I was writing doors and modules for my BBS, adding spinning cursors, time and date stamps, and other stuff, the ability to put DOS into that memory was a godsend. It gave us an extra 10-12K of usable memory! Magic!

 

In the days leading up to me getting a Sider 10MB drive, I was on a quest for speed and would stop at nothing! One time I'd copy all the logs (and parts of the BBS itself) into ram. And in between calls we'd sync the data back to floppy. And we got even smarter. When the user would have a lull in activity, perhaps he/she was playing with themselves, or getting a soda, there'd be time right then and there to sync the ramdisks and perform other housekeeping I/O.

 

We also had a fast-online feature. This is how it worked. It was typical in the early days (single tasking systems) for the sysop to play games or do other shit while waiting for an incoming BBS call. A user'd call in and the system wouldn't be anywhere near ready. So what to do? We could whistle to throw off the other modem, this would give us time to get the BBS booted and going. The caller's modem would think it's a bad connection and redial or keep trying to connect, and hopefully we'd have the BBS booted and ready in 30 seconds. That didn't always work well. Other times we'd just yell into phone, in hopes the user had a modem with a speaker (the Hayes MicroModem II and some others do not), and that they'd hear us and call right back. None of these solutions were ideal. So I came up with this fast-online feature. A feature that allowed us, in 4 seconds, to give the caller a short line of text saying that "SYSTEM MAINTENANCE is in progress. Please wait while the BBS is made ready." We'd load Tiny-DOS, about 1 track in size, and it's sole function was to load an Applesoft program (a handful of tokenized bytes consuming 1 or 2 SECTORS at best) which answered the phone immediately and presented the caller with that message saying, "SYSTEM MAINTENANCE in progress. Please wait while the BBS is made ready." Now the caller knew to just hang on for a moment. The system then proceeded to load a complete DOS, and the full entire BBS code of about 40K or more, and all the logs, and then parse them and all the other stuff BBS' do to "get ready". This whole fast-online feature could have me playing a game like Dig-Dug or Flight Simulator A2-FS1 one moment, and via Control-Reset, have the user being given a message no more than 4 seconds later. While they were reading it and contemplating it, at 300 baud, the system was already self-rebooted and on it's way to loading the whole BBS for real.

 

So basically what I had going was a way to stop whatever it was I was doing, and get a message to the caller immediately, then proceed to load the BBS. Only problem was I lost my work or game progress and would have to start over.

 

And after that, we went a step further, and divided up the 128K of the //e into two separate machines. I made a toggle switch and a series of latches that would literally give me two machine states in one.

(1) BBS at the ready

(2) My gaming session or other work in progress project

Flipping the switch was like having another computer. And we could go back and forth instantly as if we were KVM switching 2 modern PC's. There was no way I could have afforded another $1,500 system - so this would have to do.

 

There were many other cool things. But I also liked that all of the code for DOS was loaded straight away at power up and there was no need to get stuff from the disk for OS and I/O purposes. The 2-3 seconds it took to do this was inconsequential. Barely longer than it took to reach over and grab the joystick. A DOS that was 100% loaded from a disk provided extraordinary flexibility, you could mod it for speed, or hi-mem, or additional commands like TLIST - for reading text files, or even display track/sector/read/write/disk# on the bottom of the screen, even caching a few key tracks like VTOC on $11 in a ramdisk. All of that and more! Think Hyper-DOS, Diversi-DOS, David-DOS, or Pronto-DOS.

 

This is not to say that other classic systems couldn't do similar tricks. I (we) just found it so much more easily accessible, customizable, and compatible across thousands of games and applications, as long as the software was cracked. And yes these special DOS' were totally compatible with the Sider 10MB HDD. It just worked. I recall having 9 kinds of DOS, and CP/M, Forth, Pascal, Cobol, Fortran, Pilot, and Logo going, all through a stupid simple 0-9, A-Z menu.

 

It was the simple and spartan Disk II that made all of this possible. I never quite thought about it, but at the time we were hacking and programming the other side of the storage subsystem. The real controller part, the console hardware itself.

Edited July 12, 2014 by Keatah

[JamesD]

One thing the CoCo did right was it used vectors for callable ROM routines and that included it's DOS.

As long as programs followed the rule of using the ROM vectors, about any replacement DOS could be used.

This is how Drivewire, IDE, Compact Flash and SD interfaced are able to work so well with most programs.

Sadly, a few people didn't follow the rules so a handful of games are not compatible and the only way to play them is to emulate a drive at the hardware level.

[Keatah]

I don't recall the absolute maximum a Disk II can transfer bits, but it's right around 120,000 baud to use an old-school term. I remember dumping the entire contents of a floppy into a RamWorks card in as little as 9 seconds using the FastCopier from the Locksmith Disk. I also remember adjusting the interleave on a couple of 528-sector volumes on the Sider HDD. It went stupid-fast! About 4 seconds.

 

We're talking near Ramdisk speeds. For it was the Apple II bus which was the limiting factor in storage subsystem speeds.

 

I also fondly recall the magic of using a Ramdisk for the first time. It was a small one, affording us about 12K bytes of space, or about 60-sectors in DOS 3.3 parlance, and we were simply flabbergasted at being able to load and save things instantly. The HyperDOS track/sector indicator was no more than flash! Little did we know that in a couple years' time we'd see HDD with 10 MILLION bytes of space at about the same speed. Little did we know we were PIONEERING the future SSD. Right then and there!

 

I remember staying up all night, looking for games less than 60 sectors in size (more or less) and just transferring them back and forth between the real disk and the Ramdisk. And then loading stuff from it just for fun. And it was real fun! Not fun had out of boredom, but real discovery-like fun.

 

And then with the //e we got another 64k to play with, and set up another Ramdisk. This one over 200 sectors big! For fun we'd use FID to copy files back and forth between the two fake disks with no real intent other than to do something. All day long, all night long. It was a single minded crazy-schism. This fuge went on for several days before we got back to playing normal games again. Before the novelty wore off we did time trials and everything. We made charts about what games copied the fastest or slowest. After like 3 hours of testing we discovered they all transferred at the same speed. Fathom that!

Edited July 12, 2014 by Keatah

[John_L]

I seem to recall that as far as disk systems went most were all about the same with the exception of C64 with it's lame serial interface. Those were horrible. TRS-80 Model I & 3 both had HD controllers and hard drives you could buy if you could afford to pay the price of a good used car for it. James has a good point about the CoCo. A CoCo with a Super IDE cartridge can store on SD cards, which is a very modern storage medium.

[JamesD]

I seem to recall that as far as disk systems went most were all about the same with the exception of C64 with it's lame serial interface. Those were horrible. TRS-80 Model I & 3 both had HD controllers and hard drives you could buy if you could afford to pay the price of a good used car for it. James has a good point about the CoCo. A CoCo with a Super IDE cartridge can store on SD cards, which is a very modern storage medium.

Doesn't the Super IDE use CF cards?

[JamesD]

The CoCo stored around 145K on a disk if I remember right.

Almost all DOSs where the drive was directly interfaced to the host CPU used a temporary buffer instead of reading directly to the RAM the program was using.

That slows down disk access because you are copying to RAM and then copying from RAM to RAM.

On top of that the DOS would often have to sync to the start of a track to start reading data.
I still remember copying programs from one disk to another so the programs would be stored on consecutive sectors and tracks of the disk for faster access.

If you used a disk cacheing program, DOS would just copy any cached data directly from RAM with no waiting.

On the Apple II, storage space and speed depended on what DOS you were using.
Early versions stored less than later versions and ProDOS was much faster than earlier versions.

[Keatah]

I always had a hard time going to ProDos. I didn't like the "systems" and module approach. I found the filename restrictions too restricting and dumb. And to a kid in diapers the whole directory/path concept seemed unnecessary and in-the-way.

 

What I did enjoy was discovering that many Apple II drives could access track $23 and thus gain (to a kid) loads more storage space. I was green enough to enjoy the MAGIC that software could do. I envisioned some cloud of smoke in the drive doing something with the molecules and stuff and making new hardware out of old.

 

And then there were the Rana Systems Elite series, I think these got up to 600K or something? IDK, I never had one BITD, but have them now, and yet to experiment and play with them.

 

I also remember hussing and fussing over file placement and would verify locations of "critical" games and text files with the COPY II PLUS utility.

[potatohead]

In terms of "best", I would rate my experiences as:

 

1. Apple ][

 

The disk could be handled as a track and sector device on a basic level. One didn't really need a filesystem, if the disk was going to be used for some specific storage task, such as for a game, or within one's own programs. It was fast and flexible. I liked PRODOS, for the speed and volume/directory support, but I liked 3.3 better. Long file names, and low hassle, reasonable speed. The whole "put a CTRL-D" into a program method of triggering DOS almost puts Apple at #2. This was goofy, but documentation was good. I liked the file type system.

 

In terms of being robust, I would rate this one high too, right along with the CoCo. Never had data loss troubles on either machine that were not totally my fault and I didn't have trouble working across various drives.

 

Drive hardware was good. On early machines you had to get the connections right, or break things. Never used cassette. I think it rates fairly low with Atari in that respect.

 

Got to use a hard disk, and it was a 5Mb Corvis something or other. It was fast, had tons of room, and under PRODOS, rocked pretty hard. Did some fairly large writing / graphics projects on an Apple for a proof of concept business type project that ended up getting done on a PC a few years later.

 

Being able to use long, descriptive file names on DOS 3.3 was something I valued and missed for years, until the PC finally got back around to resolving it all, and today we know they Microsoft basically cloned the Atari ST way of doing things. This and the lower level being wide open to learn on and make use of puts the old Apple on top, but not by much, and only in the early times. Otherwise...

 

2. Early PC.

 

5 1/4" disks were great! They worked, I didn't have trouble, were fast, and fairly cheap. Also got to use a "Hard Card" drop in hard disk that was amazing to me after working with the Corvis on the Apple. A whole 10Mb of space at speeds much quicker than any floppy, or the hard disk on the Apple. Never used cassette on a PC.

 

The only reason the PC isn't #1 is due to how unique the Apple ][ was in using software and such a simple controller. Learning higher level things about storage happened on a PC, but the lower level understanding came from the Apple ][.

 

Storage sizes were double or more what I found in 8 bit land, but programs were bigger too. This turned out to be mostly a wash, but for storing my own data. Larger writing projects made sense on a PC. Add some graphics, etc... and multiple floppies were less of a concern overall.

 

Of course, the PC grew rapidly, and it's storage options grew too, exceeding the classic machines. I'm putting early ('85 ish?) experience here for reference.

 

Using two drives was easy. Never did anything else.

 

I didn't do hardly any 16 bit computing, so I can't really compare things like the Amiga, ST, etc... Sort of which I had. But I made the jump to PC land, and it mattered for employment. Since I went into manufacturing, Apple ][ computers with custom cards saw some use, which I really enjoyed, as did the PC, which ended up driving CNC machines, running terminal emulations, CAD. I actually did some of those things on the Apple ][, which is kind of amazing really.

 

On both the Apple and the PC, I had a love hate affair with 3.5" disks. Never lost so much data in my life! Those things were just crappy. Hate 'em. Ended up using 5.25" disks in their various formats way longer than most people just because I had such ugly experiences with 3.5" disks. And that caused me to go right for hard disks as soon as I could afford them too.

 

On early Apple machines, hooking up two drives was fairly easy. Same problem as one. Get it right, or send in for repairs. I never botched this, but I knew plenty of people who did.

 

Drive slots and numbers were more of a PITA than drive letters are, but PRODOS just went with named volumes, which made a lot of sense to me.

 

3. CoCo

 

It stored amounts comparable to the Apple, and it was fast. Cassette had file names, and they actually worked. Transition to disk was easy. Didn't like the goofy cartridge sticking out, but oh well. Drive hardware was good. I never tinkered with the DOS much, like turning verify off. It was just fast enough I didn't care. Disk commands from BASIC were simple and easy to use. The ribbon cable and sort of out in the open nature of it was interesting, but largely a negative to me.

 

Cassette was flat out awesome! The stock setup was comparable to C64 disk access in some cases. Was easy to patch 'n go at the higher clock speed to get even faster. I wrote some fairly large programs in assembly language and BASIC using just cassette and it was nice enough to really use.

 

Never used more than one disk drive on my own systems. Other users obtained drives, made their own cables, power supplies and hooked them up to their CoCo's. I think that's cool.

 

3. Atari, and it's sort of tied with the CoCo. Didn't get as much storage space, but then again, I never used some of the later DOS software either. I liked SIO a lot, and I liked that I could hear the sector transfers. One of my first lame hacks to get around copy protection for Ultima II was listening for the 23, or was it 19 beeps in to the loading, so I could open the door, trigger an error, close it and carry on with the game. They just checked for an error, not so much a specific one. (thanks guys) Verified writes took a long time it seemed. Turned these off, from time to time, depending.

 

Hooking up multiple drives was easy. And the drive number thing was cake.

 

For the above three, writing things like a sector editor wasn't too difficult, and I enjoyed messing with things on the disks I had, copying, etc...

 

Cassette had file names, but the system didn't really do anything with them, but your program could. Cassette was SLOW. But it was also reasonable. I had few problems. Liked the ability to put music, or audio on a tape. The speed was a killer. Used cassette for archives and basic programs, but that's it.

 

4. C64

 

I liked the no boot DOS, but I didn't like the speed, nor the bulk of the drive itself. The whole thing seemed clunky, and I did run into hardware trouble as well as disk trouble. Got into this one late in the game, and the clunky nature of it meant not really using the disk system as much as I did the others. Total bias there I'm happy to own up to. I did really like the disk tricks, such as have the drive do stuff, and the nice ability to have a program doing things while using the disk is pretty great.

 

Hooking up multiple disks was easy.

 

Never used cassette.

[Keatah]

The bare innards and "get it right or blow it up" nature of the Apple II taught me a healthy respect for the getting it right part. Especially when I blew up my //e motherboard. I had pulled a card out with the power on, and it wasn't straight up. Poof! It was out of commission for nearly 2 or 3 weeks while the Apple tech worked on it in his spare time. I couldn't afford much then, except maybe parts. I think to myself the warez I lost out on! And I always check for the red led!

 

By the time I had the opportunity to get into the CoCo my days of 8-bit computing were trying to come to an end. I was trying to embrace the 16-bit market full-on and in doing so I let my Apple //e rot under bed or in the shed or someplace. But that was a mistake, a fiasco. When the Amiga failed to meet my needs I went back to the Apple //e right away and continued on till the PC started going full-tilt.

Edited July 14, 2014 by Keatah

[JamesD]

FWIW, I believe the CoCo DOS has calls for reading individual track/sectors.

[potatohead]

Very cool. I don't know enough about the various OSes and DOSes for CoCo. Wouldn't surprise me. Most software for that machine is pretty smart, well designed stuff.

 

OS/9 or NitrOS9 is a lot of fun. Need to use it more. But then again, I need a 512K machine too.

[MarkO]

The CoCo stored around 145K on a disk if I remember right.

160K, Apple Disk ][ is 140K

 

Almost all DOSs where the drive was directly interfaced to the host CPU used a temporary buffer instead of reading directly to the RAM the program was using.

That slows down disk access because you are copying to RAM and then copying from RAM to RAM.

On top of that the DOS would often have to sync to the start of a track to start reading data.

I still remember copying programs from one disk to another so the programs would be stored on consecutive sectors and tracks of the disk for faster access.

If you used a disk cacheing program, DOS would just copy any cached data directly from RAM with no waiting.

Apple DOS 3.x was very Bad about this.. That is why Pronto-DOS, Diversi-DOS, David-DOS, etc. were developed to Speed things Up... Nothing was better than Wolfenstine, Converted to DOS 3.3 and then have Pronto-DOS added to the Disk..

 

 

On the Apple II, storage space and speed depended on what DOS you were using.

Early versions stored less than later versions and ProDOS was much faster than earlier versions.

Removing DOS 3.3 or ProDOS helped with Disk Space.. Also if you only had Machine Language Programs on your ProDOS Disk, you could remove BASIC.SYSTEM from the disk.. The Aztec Compiler even had its Own ( UNIX Like ) Shell..

 

FWIW, I believe the CoCo DOS has calls for reading individual track/sectors.

From BASIC, DSKI$ for Input and DSKO$ for Output. You can Read or Write 256 Bytes, held in Two 128 Byte Character Strings, to any Formatted Track/Sector. ( I got the Color Computer Disk System manual with my last FD-500 )

Edited July 17, 2014 by MarkO

[atarian63]

Atari St, all in rom equals EASY

 

Atari 800 et al easy,nice dos,sparta dos even better

[MarkO]

I always had a hard time going to ProDos. I didn't like the "systems" and module approach. I found the filename restrictions too restricting and dumb. And to a kid in diapers the whole directory/path concept seemed unnecessary and in-the-way.

I saw the Value of ProDOS, but I found DOS 3.3 More Comfortable to work with and less restrictions too..

 

I had ProDOS Disks with v1.0.0 and v1.0.1 and was surprised many years later to see there was many, many updates to it..

 

What I did enjoy was discovering that many Apple II drives could access track $23 and thus gain (to a kid) loads more storage space. I was green enough to enjoy the MAGIC that software could do. I envisioned some cloud of smoke in the drive doing something with the molecules and stuff and making new hardware out of old.

Have you seen this Apple Disk ][ Story???

 

And then there were the Rana Systems Elite series, I think these got up to 600K or something? IDK, I never had one BITD, but have them now, and yet to experiment and play with them.

I have one Drive... But no Controller.. I didn't realize they were such a special Drive...

 

I also remember hussing and fussing over file placement and would verify locations of "critical" games and text files with the COPY II PLUS utility.

Well, I never went that far... Pronto-DOS performed miracles on Disk Access Times...

 

MarkO

Edited July 17, 2014 by MarkO

[MarkO]

The bare innards and "get it right or blow it up" nature of the Apple II taught me a healthy respect for the getting it right part. Especially when I blew up my //e motherboard. I had pulled a card out with the power on, and it wasn't straight up. Poof! It was out of commission for nearly 2 or 3 weeks while the Apple tech worked on it in his spare time. I couldn't afford much then, except maybe parts. I think to myself the warez I lost out on! And I always check for the red led!

I blew up my Disk ][ by connecting the Disk Drive to the Wrong Pin on the Disk ][ Controller Card... I think it was only $65.00 ( USD in 1986 ) to get it fixed..

 

Even today, with the Original Disk ][ Controller Cards, I remove the Card from the Computer, Turn it Upside Down to see that ALL the Pins on the Board go into ALL the correct sockets on the Drive Cable, and then Re-Insert the Card into the Apple ][...

 

By the time I had the opportunity to get into the CoCo my days of 8-bit computing were trying to come to an end. I was trying to embrace the 16-bit market full-on and in doing so I let my Apple //e rot under bed or in the shed or someplace. But that was a mistake, a fiasco. When the Amiga failed to meet my needs I went back to the Apple //e right away and continued on till the PC started going full-tilt.

I jumped to the IBM PC, because I could see in 1987 that there was a much bigger market to sell software into.... Only in the last few years have I got back into the old Apple ]['s, my SX-64 and Sinclairs and now the Tandy CoCo...

 

MarkO

[The Usotsuki]

I use RDOS for some of my game compilations... no fragmentation, lightning loads.

 

Generally for larger stuff I target ProDOS 8 v1.8.

[MarkO]

Very cool. I don't know enough about the various OSes and DOSes for CoCo. Wouldn't surprise me. Most software for that machine is pretty smart, well designed stuff.

 

OS/9 or NitrOS9 is a lot of fun. Need to use it more. But then again, I need a 512K machine too.

There is actually quite a few Tandy CoCo DOS.

 

I have my EPROM Burner up and Working, and some MCM68766C35 EPROMs on the way.. I am thinking of trying Art's ADOS and ADOS3.. And maybe rebuilding the CoCo 3 ROM to include HDB-DOS for Drive Wire. I still need some 4 Pin DIN Plugs.....

[JamesD]

 

160K, Apple Disk ][ is 140K

 

Hmmm... something stored about 145K. Maybe I'm thinking of after directory and allocation tables.

[MarkO]

Hmmm... something stored about 145K. Maybe I'm thinking of after directory and allocation tables.

Tandy RS-DOS looks a lot like Apple DOS 3.3, except Apple has 16, 256 Byte Sectors per track, Tandy has 18, 256 Byte Sectors per track.. Each natively support 35 Tracks.. Both Machines can be modified to Add a Track or so...

 

Both have the Catalog ( Directory ) in the Center of the Disk, Removing 4096 Bytes from the Apple Storage and 4608 Bytes from the Tandy Storage. Apple DOS is On the Disk, Tandy is in ROM.

 

The Programmer that Finished the Apple DOS, Paul Laughton worked for IBM, and used IBM Terminology like VTOC ( Volume, Table of Contents ) and CATALOG. Tandy DOS was written by Micro-Soft and Used CP/M Terminology like Directory and DIR..

 

MarkO

[Keatah]

I knew about the Shugart story and how and why Woz replaced their electronics. But I didn't really know that Shugart tried to undermine the process by sending rejects.

 

The beauty part of the whole Disk II subsystem was that it was simple enough for a kid to understand. Unlike this mess of 60 chips!

 

 

http://dvq.com/index.html

[Keatah]

I think this PDP-6 disk runs away with "The Biggest, The Baddest, The Best" title in no uncertain terms.

 

That's for real and not advertising ridiculousness. The drive that this come out of looks like this:

 

And here are some of the specifications:

Storage Capacity of about 48M bytes or 10 DSLR jpegs

Spinup time of 5 minutes

Startup current 300 amps

Weighs more than 5,000 pounds without the platters

The control electronics add another 2,000 pounds

The don't say how much each platter weighs, but I would guess nearly 1,000 pounds or more, because the platters are just shy of 1" thick.

And each track has it's own head! You can't get more parallel than that!

 

Later on smaller versions were made to be used as real-time display memories (early framebuffers), and as working memory for on-board ship computers and other uses like delay lines. Think of these as mechanical rotating memories and not actually long-term storage.