| |
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. |
|
| |
ice00
Registered: Apr 2002 Posts: 54 |
C64 format:
2 copies of program are stored in sequence
20 bits are used for one byte of data to store
~ 1000 microsecond for a bit
Turbo format:
1 copy of program stored
8 or 9 bit for one byte of data to store
~ 550 microsecond for a bit
|
| |
Krill
Registered: Apr 2002 Posts: 2980 |
Generally, apart from storing only 1 copy, the lengths of short and long pulses for either bit are shorter, and some loaders also introduce a middle pulse, so two lengths would be ones and zeros, and the third would swap the meaning of the other two so the total length is minimized. |
| |
Martin Piper
Registered: Nov 2007 Posts: 722 |
A good explanation of how a turbo works is here in "rant 8": http://codebase64.org/doku.php?id=base:irq-tape_loader
Then to get your turbo loader to autoboot: http://codebase64.org/doku.php?id=base:autoboot_tape_turbo_load..
The autoboot sources also include an improvement from the method used in "rant 8" to use a CIA timer while saving instead of having to carefully count cycles in the save code. |
| |
enthusi
Registered: May 2004 Posts: 677 |
check http://enthusi.de
:)
edit:
also what other mentioned.
Main speedup: data not written twice.
CBM load uses 3 pulse-lengths (1 "pulse" = 2 signals, one "positive", one "negative" - the c64 detects downflanks).
CBM load uses 2 pulses for one bit!
TT uses 1 pulse = 1 bit.
Pulselengths are much shorter for TurboTape.
I illustrated some details in the link above some time ago.
TT is kind of the limit. Closer pulselength would get unreliable on different datasettes. Their speed varies slightly. Also the signal gets less clean when the head gets slightly twisted in respect to the tape itself...
I tried that alot :) cant really improve speed further without making it a lottery for the user.
CBM load aligns itself to tapespeed though! very efficient actually. TurboTape simply fails on significantly faster/slower datasettes. |
| |
doynax Account closed
Registered: Oct 2004 Posts: 212 |
Interesting. I never did have a datassette to play with and only vaguely remember a friend and I clocking a load at 15+ minutes for one of his C64 games. Still, if the speeds discussed here are accurate then you could squeeze an astonishing two megabytes onto a 90 minute tape.
Anyone care to explain how the physical encoding works and what the low-level limitations are, as opposed to, say, the magnetic coding on a floppy drive?
I mean why is a pulse scheme with flexible lengths preferred/required as opposed to something like GCR or MFM coding? And if differing tape speeds is the main obstacle then why isn't it possible to dynamically calibrate the loader? |
| |
Mace
Registered: May 2002 Posts: 1799 |
To add to Doynax's questions: what's the differences between those proprietary loaders like Cyberload? |
| |
tlr
Registered: Sep 2003 Posts: 1790 |
Quote: Interesting. I never did have a datassette to play with and only vaguely remember a friend and I clocking a load at 15+ minutes for one of his C64 games. Still, if the speeds discussed here are accurate then you could squeeze an astonishing two megabytes onto a 90 minute tape.
Anyone care to explain how the physical encoding works and what the low-level limitations are, as opposed to, say, the magnetic coding on a floppy drive?
I mean why is a pulse scheme with flexible lengths preferred/required as opposed to something like GCR or MFM coding? And if differing tape speeds is the main obstacle then why isn't it possible to dynamically calibrate the loader?
I guess pulse widths are prefered because every bit is a transition then, i.e safer/simpler.
Calibration should be possible, enthusi mentions it is done by the kernal cbm loader.
Also using GCR should be possible. That could be used to make a byte the length of 10 '0'-bits.
I'm not sure how safe it would be. Depends on how much/fast the tape speed varies _during_ loading.
Perhaps calibration could be made on the fly? |
| |
doynax Account closed
Registered: Oct 2004 Posts: 212 |
Come to think of it, if the cycle counts for a turbo-tape one-bit is half again as long as a zero then a GCR (5-to-4 bits) wouldn't really win anything unless you had more than fifty percent ones (which you shouldn't, since you can always invert all the data to get less than 50%.)
You'd be better off interleaving a Huffman-coder weighted towards zeroes with the loader instead. |
| |
tlr
Registered: Sep 2003 Posts: 1790 |
In my GCR suggestion I assumed '0' was the shorter bit. For GCR only short bits are required.
In GCR a missing bit means 0, and a bit (=transition) means '1'. |
| |
doynax Account closed
Registered: Oct 2004 Posts: 212 |
Quote: In my GCR suggestion I assumed '0' was the shorter bit. For GCR only short bits are required.
In GCR a missing bit means 0, and a bit (=transition) means '1'.
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.. |
... 34 posts hidden. Click here to view all posts.... |
Previous - 1 | 2 | 3 | 4 | 5 - Next |