[Coco] Preserving old CoCo diskettes...

Boisy G. Pitre boisy at tee-boy.com
Wed May 19 00:31:04 EDT 2010


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.






More information about the Coco mailing list