Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Turbo Tape, how does it work?
2008-12-06 10:31
johncl

Registered: Aug 2007
Posts: 37
Turbo Tape, how does it work?

I have always been curious about how turbo tape really worked. I know that the tape drive originally could only read 50 bytes per second which would take a whopping 21 minutes to fill up the whole memory. I was always under the impression that games used compression to speed up tape loading (Just did a test with Giana Sisters which took 4 minutes to load).

Did Turbo Tape fiddle with the speed that data was written and read to the tape? I didnt think that was possible (only thought that was how they sped up disk reading/writing). If anyone got a good resource at how e.g. the well known Turbo Tape works, please post a linky here.
 
... 34 posts hidden. Click here to view all posts....
 
2008-12-07 16:38
tlr

Registered: Sep 2003
Posts: 1790
Quote: As did I. It's just that a GCR encoded byte needs two extra bits, so a worst-case turbo-tape with 50% ones should just about break even with it.
At least, I think that's how it works out..


Hmm, yes you are right.
I assumed a '1'-bit was twice as long as a '0'-bit, but now I realize the difference is much less.
2008-12-07 16:56
enthusi

Registered: May 2004
Posts: 677
check neoload for a error-correction loader.
The most complex there is so far.
Neoload
2008-12-07 17:51
tlr

Registered: Sep 2003
Posts: 1790
Yes, noted that before. Very cool!
The discussion about GCR was an attempt to propose a faster loader than turbo tape though.
Perhaps it is already close to max? Very cool in that case as it is from 1983. :)
2008-12-08 00:48
Frantic

Registered: Mar 2003
Posts: 1648
The loader in Deep Throat by Durex uses four pulse lenghts corresponding to 00, 01, 10, and 11. This minimizes the constant minimal length you always need to have in a pulse. I think there was also a fifth pulse length, signalling "syncrhonization point", since you can ffwd and rewind the tape while the demo is playing, but still resync at regular intervalls...

Greetings too Krill! (...and greetings to everyone from the Polish/German border..;)
2008-12-08 06:19
johncl

Registered: Aug 2007
Posts: 37
Ahh, thanks for clearing that out. I didnt know you had such a low level access to the tape read/write mechanisms that enables you to actually time pulses.

So to further discuss this, what did most commercial games use? For example Novaload which I know a number of distributors used. I guess they couldnt squeeze it as low as Turbo Tape as that would probably have ended up with the game not working on some tape drives (and couldnt handle any kind of error).

You see, I am quite surprised at the fact that close to 100% of the old tapes I have tried still load perfectly after 20-25 years of storage (and I mean all sorts of storage since these are bought from around the world). In fact, only one tape has bugged out on me in which the tape drive was not even able pull the tape after 3 count ticks into the tape start. :)
2008-12-08 07:24
Martin Piper

Registered: Nov 2007
Posts: 722
Cyberload/Novaload etc don't handle the potential for the really slow or fast tape drive wobblyness so I suppose it was never much of an issue. Basically, don't bother writing code to calibrate the timings because they're not that much of an issue compared to the cycle timing wobbles you can get when displaying a picture during loading.

Unless you have the screen turned off and want to make a really fast loader. But in my experience the time differences you can get on a real C2N during loading change due to the amount of tape on each spool. Or if the pet dog walks past the C2N. :)
2008-12-08 10:51
Graham
Account closed

Registered: Dec 2002
Posts: 990
I believe that much faster turbo tape formats are possible. The main problem with the existing fast tape stuff is, that those routines always use hardcoded thresholds for 0 and 1. This causes problems if you move from one tape drive to the next so the threshold has to be chosen in such a way that the 0 and 1 ranges are quite big. If you manage to measure the tape drive speed first, you might be able to use much smaller pulse lengths -> faster loading + more data on a tape.
2008-12-08 11:08
algorithm

Registered: May 2002
Posts: 705
There was the SuperTurbo format which was used in the Action Replay Cartridge which i believe was nearly twice as fast as Turbotape. I dont think there was any other loader which would load data this fast commercially but that is understandable as it could have caused more possibility of error
2008-12-08 11:32
Martin Piper

Registered: Nov 2007
Posts: 722
Re: Action Replay super turbo. If the assumption is made that the C2N doing the saving is going to be the C2N that will be doing the loading then it's possible to make the bit rate quicker without any fancy timing calibration. :)
2008-12-08 11:33
johncl

Registered: Aug 2007
Posts: 37
Hm, did any of these fast loaders/savers do real time compression/decompression of data? E.g. RLE compression?
Previous - 1 | 2 | 3 | 4 | 5 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
CreaMD/React
Guests online: 104
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 X-Mas Demo 2024  (9.5)
7 Dawnfall V1.1  (9.5)
8 Rainbow Connection  (9.5)
9 Onscreen 5k  (9.5)
10 Morph  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Crackers
1 Mr. Z  (9.9)
2 Antitrack  (9.8)
3 OTD  (9.8)
4 Fungus  (9.8)
5 S!R  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.048 sec.