Loading tape games - FAST

[lynwen]

Is this any faster than loading from disk? I have no idea having never owned a disk drive only loading from tapes
Looks like they convert to wav then speed up when playing?

Fast loading for Amstrad CPC

[Ace]

...it's fast, but seems not faster than disk loading.

[Gryzor]

Yes, but for a tape it's super fast.


Am I alone in thinking this had been posted before? Can't find it...

[AMSDOS]

I remember using JL-Copy to copy my original Harrier Attack into an unusual Format JL-Copy, it was saving the file into a format which could simply be

Code Select Expand

Run" though would kind of end up like a Headerless file with a long space of Data being loaded in for Block 2. It was saving at the Baud Speed of 3600 which is about as fast as you can go with Tapes which is typically faster than a

Code Select Expand

Speed Write 1 which gives you 2000 Baud. The result with Harrier Attack was it loaded very quickly, the size of the game is 9k, though I've had it load from Disc, and I think Disc is probably still faster for even that small game, though the tape was still pretty good.

It might have an interesting result though if the game is only 1k or 2k, the key would be to have the file ready to go with all the information about it, and you load it in as a Headerless File which is saved at 3600, that may just beat the Disc Drive, cause you know you always have to

Code Select Expand

CAT with discs.    You need to have your Tape Deck calibrated properly though so it will happily load 3600, usually you know that if some Speedlock game isn't loading.

[trocoloco]

That's the OTLA project that can load tapes at speeds of 12000 bauds and even more, but using such speeds it will only work when loaded from a digital format. You can find  it at otla - Tool for loading programs into vintage computers via their cassette with some examples included to download and try 4 urself, good luck!

[TFM]

Is this any faster than loading from disk?

No way, this loader makes about 1.5 KB per second - which is really good! But with a disc drive you can load up to 20 KB per second (this is a measured value, not theoretical  ).


There is a table in the wiki which shows disc speed, please here the link:

Speedcheck - CPCWiki

[AMSDOS]

No way, this loader makes about 1.5 KB per second - which is really good! But with a disc drive you can load up to 20 KB per second (this is a measured value, not theoretical  ).


There is a table in the wiki which shows disc speed, please here the link:

Speedcheck - CPCWiki

I'm assuming those results are taken using FutureOS, which doesn't support Tapes?


The article is good, though it has a little problem measuring what those values means, so I'm assuming the values are seconds. If that's the case, AMSDOS spends 9 seconds loading an 40k file. I don't know if you can simply half that so a 20k file takes 4.5 seconds. 10k would be 2.25 and so on until you get to a 1.25kb I'm unsure if 0.28 of a second would hold true given the fiddley nature of the file and the Disc Drive grunting away through that whole 178k disc to find it.   
It just has me wondering how a small program could compare to the disc, if all the details about the file was ready to go and it was saved at a faster rate.    Probably a no win. 

[ralferoo]

But with a disc drive you can load up to 20 KB per second (this is a measured value, not theoretical  ).

I'm not sure if things like HxC emulate floppy speed exactly, but the theoretical limit of the 765 chip used to control the floppy is about 35KB per second. The majority of the "wasted" time is spent seeking the drive head; actual data transfer has to be pretty close to 26us per byte. There's about 2% overhead with the commands per sector compared to the data transfer on a 512 byte sector.

So, there's definitely scope to build a dedicated floppy emulator for the fastest possible load times...

[fano]

So, there's definitely scope to build a dedicated floppy emulator for the fastest possible load times...

I am not sure that would be so usefull as with correct FDC code data decompressing is slower than the data loading itself 

[TFM]

... so I'm assuming the values are seconds. If that's the case, AMSDOS spends 9 seconds loading an 40k file. I don't know if you can simply half that so a 20k file takes 4.5 seconds. 10k would be 2.25 and so on until you get to a 1.25kb I'm unsure if 0.28 of a second would hold true given the fiddley nature of the file and ...

Yes, the given values are seconds, the indicated programs / OS have been used. And for the 'fiddling' different file sizes or numbers of files have been used.

You can do it for all file sizes, but then you will get a table way to long. But feel free to contribute.

... The majority of the "wasted" time is spent seeking the drive head...

Actually all DOS / OS (except FutureOS) waste the most time for the interleave. The step rate is in the range of 4-12 ms, while the 'quickest read' of a track still takes about 200-400 ms. So forget about the 10% you gain with better step rate. The interleave is the key to succes.

[TFM]

Offtopic: The HxC is different again, with some smart parameters set, a data transfer-rate of 75.1 KB / second can be reached. But this needs to create a disc image file which is heavy specialized in a couple of parameters, first the bit rate itself. Further the CPC side need quick read routines.

I never ever did try to write to such a format to be honest.