[Coco] Re: Why USB would be nice.

[L. Curtis Boyle]

    Just a note on FAT compatibility: aside from the PCDOS utility, there  
was a file manager for the older FAT-16 MSDOS that worked natively in  
OS-9... it was called MSF and worked with the enhanced floppy driver  
called SDISK (and later, for the Coco 3, SDISK3). I ran it for awhile,  
just before we got into Nitros9, and it ran quite well (Came with a bunch  
of wildcard capable utilities, like MSCOPY, which I used even after I no  
longer used MSF). So, yes, it can be done, and, to a certain extent, has.  
Even the CC3Disk driver in Nitros9 (and later versions for OS9) can read  
PC disks in a raw mode (512 byte sectors); it is not hard to write  
utilities to process the DOS/Windows directory structure using that (I had  
started fiddling with one that could partially handle Win9x long  
filenames, but never finished it before my TC-9 was shut down).
     I would like to see USB as well, for the reason that the one hardwrae  
interface can hook up to so many different devices, and it still being  
expanded on. All USB devices are backwards compatible to the older,  
slower, 1.1 standard, so if new USB devices came out that we haven't even  
thought of, we could still hook them up to a Coco (just need drivers to  
handle it, or specialized utilities).
     In the last version of the IDE driver I did (and Boisy has the  
source), I had just started trying to figure out how to make "generic"  
calls, so that one could write utilities to directly send ATA commands to  
the driver, that would remain compatible with the ever espeanding ATA  
spec, so that one could implement new utilities using new features,  
without having to recode the driver every time. If a USB driver was set up  
the same way, one could write programs to access certain types of hardware  
without having to make a new (either revision or replacement) driver  
everytime something gets added.
      On the flash card capacities for digital cameras, etc: The last IDE  
driver I did could do up to 4 GB on a single partition, and could  
partition multiple 4 GB partitions on a single drive, so you CAN use the  
whole 8 GB card. And processing image files that are large is not  
impossible; I have used VIEW and VIEWGIF to view GIF pictures far beyond  
the native Coco resolutions and colors; they process the original files in  
chunks, and convert them on the fly to something that the Coco can display  
(dithered, and/or page-flipping), and either scaled or get portions of the  
image. One could even save these color/resolution reduced versions for  
later viewing at much higher speeds than re-decoding the original image (I  
used this for GIF animation in VIEW 4.4a - I would decode the GIF images,  
save them in native OS9 get/put buffers, and use those to display the  
animation at the same (or close) speeds that the original GIF ran at).


On Fri, 02 Sep 2005 13:14:43 -0600, John R. Hogerhuis <jhoger at pobox.com>  
wrote:

> On Fri, 2005-09-02 at 11:32 -0700, Kevin Diggs wrote:
>> John R. Hogerhuis wrote:
>> > On Thu, 2005-09-01 at 21:19 -0500, George Ramsower wrote:
>> >
>> >> If I were to purchase the hypothetical USB card and the driver for  
>> OS-9,
>> >>would this do as I want or expect, such as.....
>> >>
>> Unless you are an idiot (or very, VERY patient), you can't expect a sub
>> 2MHz computer with a 64k address space to be able to do the same things
>> with a USB critter that a 3.0GHz machine with a 4G address space can.
>>
>
> I'm neither an idiot nor patient. Should I be offended by your remark? I
> choose not to be.
>
> In fact, I'm a firmware engineer. I deal with underpowered machines as
> my profession.
>
> It's hard to know at this point what will be possible and what will not.
> Storage I think is going to work just fine. It will be slower than on a
> desktop machine, that's a fact. WIll it be slower than Coco hooked to
> IDE? Probably.
>
> Plus, one still has to develop a FAT32 file system implementation. But
> if one wants to use flash as a sneakernet between machines, whether with
> SuperIDE or coco-usb or whatever, it's a necessary evil.
>
>
> That's one of the fun things about the coco... pushing it to do things
> everyone would say "you can't do that!"
>
> You certainly don't need a machine with 3GHZ and 4G of address space to
> be a USB host. The project banks on the fact that The embedded USB
> controller chip offloads a lot of work from the CPU.
>
>> 	As I understand it, USB is kinda similar to SCSI, at least for
>> semantics (not an english major - probably not the word I was looking
>> for) (There is a SCSI host adapter driver and drivers to support various
>> device types (disk, cdrom, tape drive, scanner)). "The driver that came
>> with the card" (port driver) would be analogous to the host adapter
>> driver. You would also need drivers for each type (class?) of device you
>> want to torture your tre with.
>
> Yes you would need drivers. I presume you would contruct a kernel with
> drivers only for the hardware you use though.
>
> I'm not sure what your definition of torture is, but it sounds like it
> differs from mine in important ways.
>
>>
>> 	Since USB is hot-pluggable, how would that be handled? Correct me if
>> I'm wrong, but OS9, while I think it can load drivers and descriptors
>> "on the fly", doesn't the text for each get a fresh page (i.e. can't
>> pack text on the tre)? Won't this fill up the system map quickly?
>>
>
> As I understand it, with level II you can pack multiple modules into an
> 8K block.
>
> Take a look at the drivers over at microusb.org . If you think of USB as
> some nightmare stack of code, you may be pleasantly surprised to see
> what the 6502 folks have done.
>
>
> -- John.
>
>



-- 
L. Curtis Boyle