Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles; site uokvax.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!ihnp4!inuxc!pur-ee!uiucdcs!parsec!ctvax!uokvax!emjej
From: emjej@uokvax.UUCP
Newsgroups: net.micro.6809
Subject: Re: OS9 cassette ???? - (nf)
Message-ID: <3500013@uokvax.UUCP>
Date: Tue, 15-Nov-83 11:44:00 EST
Article-I.D.: uokvax.3500013
Posted: Tue Nov 15 11:44:00 1983
Date-Received: Wed, 11-Apr-84 07:36:58 EST
References: <21600005@uicsl.UUCP>
Lines: 17
Nf-ID: #R:uicsl:21600005:uokvax:3500013:000:709
Nf-From: uokvax!emjej    Nov 15 10:44:00 1983

#R:uicsl:21600005:uokvax:3500013:000:709
uokvax!emjej    Nov 15 10:44:00 1983

It could be done--you'd need SBFMAN (sequential block file manager) to
live on top of the cassette device driver. I don't know if it's worthwhile,
though, for the following reason:

Radio Shack, in its design of the CoCo, did many, many things in software to
cut hardware corners. The spread of OS-9 for the CoCo is going to--heck, it
*has* (see the CompuServe CoCo SIG, which is *very* active and worth your
while)--show this corner-cutting rather severely. Piling the code that
generates the frequencies for the cassette on top of the keyboard scanning
and byte-at-a-time interrupts for disk I/O may be the straw that breaks etc.

Hardware folks, please comment and correct me if needed.

						James Jones