[Coco] Preserving old CoCo diskettes...

[Roger Taylor]

Boisy, the entire pak and what it can do right smack out of the box 
speaks for itself and is not inferior to anything Cloud-9 makes.

When you compare apples and oranges yet give only a speed comparison 
between them and purposely leave out all the other good stuff, this 
can be seen as a bit below the belt.

I'll be posting demo videos over time that hopefully will help clear 
up some of these misunderstandings you guys seem to have and 
hopefully win back the confidence of (x) number of people whom you've 
tried to pursuade to look elsewhere for a modern CoCo storage solution.




over and out








At 11:31 PM 5/18/2010, you wrote:
>On May 18, 2010, at 10:43 PM, Roger Taylor wrote:
>
> > At 09:54 PM 5/18/2010, you wrote:
> >> > From: "Roger Taylor" <operator at coco3.com>
> >> > will cut that in half when I move to the deblocking scheme.  If I can
> >> > get the megaread (not really a good tool) down to 1:09 or so, I'm
> >> > happy with this, but I won't trade a single bit of quality or
> >> > stability just to meet somebody else's expectations of what a false
> >> > benchmark should show.
> >>
> >>
> >> Roger, speed is a very big deal. It seems all our I/O today 
> should be faster than the CoCo could keep up with. If modern 
> implementations can't be as fast as what I was running when I was 
> last using the CoCo full time fifteen years ago, I'm not sure what 
> to make of that.
> >>
> >> For more "real" benchmarks, I guess showing format time and 
> backup time might be decent. I know I will be backing up hundreds 
> of floppy disks to your SD device (and/or across DW serial link). 
> Speed will certainly matter for me ;-)
> >
> >
> > True, let's just benchmark every product across the board 
> starting with the case they're made with and how many historic CoCo 
> paks were butchered to aquire those cases, etc.  Then we can work 
> our way up to hanging around in DOS for a while running much faster 
> code, if the other paks actually work in DOS, that is.
>
>You keep reiterating the idea of going into DOS (and by this I 
>presume CoCoNet or HDB-DOS) to do benchmarking, but even in that 
>environment, the SuperIDE will be faster.
>
>I make this assertion based on my understanding of the design of the 
>Drive Pak vs. the SuperIDE.  As I understand it, Drive Pak uses a 
>6551 to talk to the SD card.  If this is correct, then it means that 
>Drive Pak's throughput is ultimately bound by the speed at which the 
>6551 talks to the SD card, which is either 115,200 or 230,400 
>bps.  For benefit, let's assume it is the latter. This means that at 
>a rate of 230,400 bps, the theoretical maximum throughput that you 
>can hope to achieve is:
>
>        230,400 bits per second / 8  = 28,800 bytes per second
>
>For comparison, consider the 22 second megaread on the SD card in 
>the SuperIDE:
>
>      1,048,576 bytes / 22 seconds = 47,663 bytes per second
>
>In this scenario, the SuperIDE 1.65X faster (47,663 / 28,800 = 1.65) 
>than the Drive Pak. With the above numbers, I've given you a wide 
>latitude by (a) assuming that you are talking to the 6551 at 230,400 
>bps; and (b) choosing the megaread benchmark as my time base, which 
>you seem to think is a flawed reading (by flawed, I presume you mean too slow).
>
>
>If you're talking to the 6551 at 115,200 bps, then:
>
>      115,200 bits per second / 8 = 14,400 bytes per second
>
>Using the SD card megaread above, the SuperIDE is now 3.3X faster 
>(47,663 / 14,400 = 3.30) than Drive Pak.
>
>If I want to stack the deck in my favor, I could compare the 
>megaread time of the CF:
>
>      1,048,576 bytes / 18 seconds = 58,254 bytes per second
>
>against talking to the 6551 at 115,200 bps, which makes the SuperIDE 
>now 4.04X (58,254 / 14,400 = 4.04) faster than the Drive Pak.
>
>
>Again, all of these numbers are moot if my understanding of how 
>Drive Pak is designed is incorrect.
>
> > The fact is, the Drive Pak is an extremely cool gadget that does 
> the most in the smallest space with the most memory of any other 
> pak I know of, and for this reason I think it is the best storage 
> solution for the CoCo, yet.  Part of this is because of the awesome 
> CoCoNet ROM.
>
>You certainly do have the SuperIDE beat on physical size.
>
> > Now, the MicroSD module has it's own command and packet response 
> time which is also based on the speed of the memory cards in use, etc.
>
>Granted. But that speed is independent of how fast the CoCo can read 
>and write the data, as I understand it.
>
> > Still, the Drive Pak runs much faster than a floppy system, but 
> if I decide to make it run twice as fast in DOS starting tomorrow, 
> a new ROM can be shipped to each customer.  Done.
>
>Unless my understanding of the design is incorrect (and I certainly 
>could be wrong), you are ultimately bound by the speed at which the 
>6551 talks to the SD card, so improvements to the routines can only 
>approach that speed.
>
>And of course, customers can program any of the four 16K Flash banks 
>right from the CoCo without the need of an EPROM burner.
>
>
>
>
>--
>Coco mailing list
>Coco at maltedmedia.com
>http://five.pairlist.net/mailman/listinfo/coco

-- 
~ Roger Taylor