The bulk of such problems were caused by using cartridges that were not certified for digital data storage (DDS). Despite appearances, DAT is not the same as DDS. Unfortunately, the original DDS standard had no provisions for distinguishing between a genuine DDS cartridge and a DAT. As DAT cartridges were cheaper than DDS ones, people would try to use DAT instead DDS to save a few bucks, euros, kroner, etc. Many DAT cartridges could not reliably record the much higher data density used in DDS, which resulted in unrecoverable errors.

Starting with DDS-2, medium recognition was added to the tape format, which would not be present on a DAT cartridge. Hence the latter cannot be loaded into a DDS-2 or later mechanism—the DAT will be immediately ejected. This feature also prevents, for example, loading a DDS-3 cartridge into a DDS-2 mechanism, but allows a DDS-2 cartridge to be loaded into a DDS-3 mechanism.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Seth has a nice write-up of his cassette interface adventure here:

http://www.loomcom.com/blog/category/re ... ge/page/4/

I didn't realize until now that Woz used -5V in his zero-crossing detector, making the schematic look almost trivial.

Mike B.

When I wrote DAT I really meant DDS. I know the difference - I still have my Sony DAT recorder somewhere - and I would never try to use those tapes for digital storage. The tapes I used, and found unreliable, were genuine DDS tapes, these were from work and the sysadm always got the best he could find of media, whatever the type.
It's just that in Norway we always called them DAT, never DDS (DAT audio was never used much, I was an exception in that regard, I bought my recorder on a foreign travel). It didn't occur to me that it could be different elsewhere. [Edit: What I meant to say, I wasn't aware that maybe not everyone would call DDS tapes 'DAT'. My fault.]
There are still some DDS4 drives in some IBM computers at work, we call them DAT..
I should mention that we say DAT, not dee-ay-tee, so DDS is a much clumsier word to use [which is why I don't say DDS - can't speak it as a word]. (We don't pronunce LED ell-ee-dee either, we say it as a word. Approximately as the word 'lead' (the metal). So I would write 'a LED', not 'an LED'.)

To this day I consider [DDS] unreliable. I still have to use it now and then, on those aforementioned IBM computers.

I had to look up "DDS," because to me it's "direct digital synthesis" which obviously was not what you were talking about.
https://en.wikipedia.org/wiki/Digital_Data_Storage

_________________
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?

Up until very recently, most of my clients were using DDS for system backup purposes, with almost no reported problems, even after years of usage. I have switched most of them to LTO due to increased capacity needs. The smallest LTO cartridge (LTO-1, which is now considered obsolete) has more capacity than DDS-160. Almost all of my clients on LTO are using LTO-3, which has a raw capacity of 400GB and a theoretical capacity with hardware compression of 800GB. Transfer rate on a system with SCSI U320 hardware, such as one of my Linux servers, is upwards of 27MB per second streaming to the tape, which is slightly better than the performance of a typical SATA hard disk in a PC.

Of those clients who are not on LTO, two are on DDS-160, one is still on DDS-4 (an old Windows box acting like a lame file server) and one client is using RDX as the backup device. The smallest capacity RDX cartridge currently in distribution holds 500GB, with sizes going up to 3TB.

DDS cartridges have a reliable life expectancy of around 100 full passes, and the drives need to be cleaned regularly. It is the overuse of cartridges and failure to clean the drive when needed that contribute to the majority of DDS read/write errors. The brand of cartridge being used and the way in which cartridges are handled and stored can contribute to failures. There are only a few brands that I trust: Imation, H-P and Tandberg, in that order.

That said, I have no reservations about implementing DDS in situations where the limited capacity (by today's standards) is adequate.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I worked on some code to read and write Basicode on the original IBM PC (through the official cassette interface) and the XT (through the printer port). I think Basicode was 1200/2400 Hz, one cycle per bit regardless of value. The 8253 timer chip made it possible to set a timeout that was halfway between the short and long wave length, and made it possible to read data from tape very reliably, even on crappy tape with lots of dropouts. I think I still have the code somewhere but I never released it to the world. There was already another way to read/write Basicode on the IBM PC and though my software appeared to work better, I wanted to add some more features like automatic merging of the Basicode library (with machine specific subroutines to do things like clear the screen). I never finished those features and simply lost interest.

===Jac

(

I had the idea that both are derived from Motorola's reference design, although the Tandy machine was a couple of years earlier. It seems Tandy declined to start legal action in the UK and Dragon felt free to sell into the US. More at this page.
)

Interesting link. Thanks Ed. I liked the Dragon, except for the cassette storage unreliability.. I had some experience with a Color Computer (version 1) from before and liked the Dragon better. The 6809 is a nice chip. I have somehow managed to acquire more 6809 CPUs than I will be able to use, I think, but we'll see.

There must be a multiprocessing 6809 project to use them up!

(Dave/Hoglet has recently added a 6809 core to the Pi copro, so anyone with a Beeb can now run a 6809 system. I think it's at about 16MHz now.)