On 2009-04-06, at 22:30, Marko Mäkelä wrote:

>> Yes. That was where everyone's interest was. The standard routines  
>> where
>> used only to bootstrap a "proper" (faster/more reliable) loader.
>
> I wouldn't call the Commodore format unreliable.

That's where I somewhat disagree. Or perhaps we use different frames  
of reference.

> I was able to resurrect
> some old tapes in the Commodore format, because each block is set  
> twice
> and because there are three different pulse widths in use, as  
> opposed to
> two.  It's easy to detect byte boundaries.  To decode these broken  
> tapes
> (mostly BASIC programs), I wrote a Perl script to decode the pulse  
> stream
> and edited the binary in GNU Emacs.

And now it seems clear that we indeed used different references. In  
theory this is all true but in practice AND on real hardware I  
experienced several times less ?LOAD ERRORs using turbos than using  
standard format for the same amount data transferred. Not to mention  
the (lack of) speed. I always used quality media so no chance of  
skewing the results due to poor media used for standard format.

I know that theoretically it should be the other way around but the  
practice showed very much otherwise. Then the choice was: to wait half  
an hour and see ?LOAD ERROR or wait three minutes and have it loaded.

Now, when I think about it - the reason can actually be that the usage  
of tape per load was multiple times higher with the standard, hence   
the possibility of hitting some form of lethal dropout for every  
loaded file was also multiple times higher... huh, who knows these  
days. I still have some of the old tapes but really don't feel like  
conducting systematic research on the subject that would require  
hundreds of hours to LOAD/VERIFY and so on ;-)

>   With the likes of Turbo Tape (no
> clear byte boundaries), this would have been hopeless.

Yeah - several things were sacrificed for the speed. Timing was  
important, not the markers (I remember fine tuning my "finaltape" to  
keep the speed and reliability high but still do something during  
load) but in practice it worked really well.

>
> If you want to see a slow format, try KIM-1. :-)  It's also  
> supported by
> the "c2n" program.
>

:-) Shall have to check this!

       Message was sent through the cbm-hackers mailing list