| |
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.. |
| |
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.
|
| |
enthusi
Registered: May 2004
Posts: 677 |
check neoload for a error-correction loader.
The most complex there is so far.
Neoload |
| |
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. :) |
| |
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..;) |
| |
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. :) |
| |
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. :) |
| |
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.
|
| |
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 |
| |
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. :) |
| |
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? |
| |
enthusi
Registered: May 2004
Posts: 677 |
There is also supertape format.
3600 baud used in Input64 tape-mag.
It has the option to save/load in high speed mode as well.
7200 baud. Would make it hellish fast too but too unreliable to be called a proper load/save I"d say.
Same goes for that AR-Superturbo. Even the manual says: dont use it when you need your data.
About graham: yeah, the ROM-load sets the thresholds according to sync-signal. TurboTapes SHOULD/could really do that too.
Maybe you dont have to wait all too long to see it done :) |
| |
johncl
Registered: Aug 2007
Posts: 37 |
Hehe at 7200 baud you could do a tape movie playback that updated a 7x7 charset image at 2 frames per second! Imagine the quality video you could have (and a few errors here and there wouldnt be too annoying). |
| |
algorithm
Registered: May 2002
Posts: 705 |
Quote: 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. :)
Yes certainly. Infact the data could be saved with more density. Superturbo was just below 1k a second if i remember rightly. |
| |
enthusi
Registered: May 2004
Posts: 677 |
@johncl the problem with tape loaders is not flipped bits.
That wouldnt hurt and would be rather simple to correct, but MISSING bits. (or extra bits)
Those are pure evil hell to deal with... |
| |
algorithm
Registered: May 2002
Posts: 705 |
For fast loading speed, simply pack the data as efficiently as possible before saving. I remember most of the games available in the stone ages (ie vendetta) that would load nearly the full 60k of data or so when the load time could have easily halved if the data was packed beforehand |
| |
iAN CooG
Registered: May 2002
Posts: 3197 |
Quote: For fast loading speed, simply pack the data as efficiently as possible before saving. I remember most of the games available in the stone ages (ie vendetta) that would load nearly the full 60k of data or so when the load time could have easily halved if the data was packed beforehand
mainly because there were nearly no packers at that time, at least before 1985 =) |
| |
Mace
Registered: May 2002
Posts: 1799 |
Vendetta (c) 1990 |
| |
algorithm
Registered: May 2002
Posts: 705 |
Quote: Vendetta (c) 1990
And a tonne more of others. If data took long to load, would have also been a good idea to play music, show a picture while next part was loading or even let the user interact in some way (eg subgame - shinobi) etc. Would not make a difference in the complexity of tape mastering as the tape loading would be under priority with everything else running in the background.
|
| |
johncl
Registered: Aug 2007
Posts: 37 |
Well, there are some Mastertronic tape titles that does have a minigame in front of it. Invade-A-Load was one of them and I remember its on the Rogue game at least. What I find interesting is that many games had fullscreen bitmap pictures that you could see while it was drawing on the screen, basically adding another 20-30 second to the loading time. :)
Of course it was cool back then as you got tired of staring at a blank screen. When loaders came with Galway music pumping out the mono speakers we never wanted to go back. :) |
| |
algorithm
Registered: May 2002
Posts: 705 |
Ahh yes, the memories of the rambo music with the picture appearing gradually as the tape was loading the data.. ahhhh |
| |
algorithm
Registered: May 2002
Posts: 705 |
Quote: Well, there are some Mastertronic tape titles that does have a minigame in front of it. Invade-A-Load was one of them and I remember its on the Rogue game at least. What I find interesting is that many games had fullscreen bitmap pictures that you could see while it was drawing on the screen, basically adding another 20-30 second to the loading time. :)
Of course it was cool back then as you got tired of staring at a blank screen. When loaders came with Galway music pumping out the mono speakers we never wanted to go back. :)
Just surprising that more was not done with it. After all. the IRQ is responsible for the loading and outside of this, it would have been possible for anything to run without distracting the loading at all unless you wanted solid rasters which would mean more complex tape mastering |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: Just surprising that more was not done with it. After all. the IRQ is responsible for the loading and outside of this, it would have been possible for anything to run without distracting the loading at all unless you wanted solid rasters which would mean more complex tape mastering
The reason is simple - 1541 came ;) But actually Datassette is one of interesting devices because it's capabilities to store huge amount of data (comparing to 1541) and technical details has been almost forgotten even if it looks simple. There are very few technical documents regarding this device unfortunately. I've learned a lot about it studying Cyberload. |
| |
algorithm
Registered: May 2002
Posts: 705 |
Tape mastering (eg saving/loading) is very simple. just precise timing and writing values to a location at precise intervals ( i think its memory location 01?) then the loader can be interrupt driven (provided it runs at full priority) to pick up the bits of data saved to tape. The secret is how to place the 0's and 1's. as well as delay timing. As long as the interrupt routine reads all the data, then exits (to allow main loop to execute whatever) and gets back to the interrupt before the next bit appears on tape etc. Anything can occur in the main loop
Although sprites and the screen on can cause problems if the data is more densely packed |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Multiplexor while tape loading... Hmm...
|
| |
enthusi
Registered: May 2004
Posts: 677 |
check this for precise timing on IRQ tape load :)
A Load of TAP
...what a nice thread... :) |
| |
johncl
Registered: Aug 2007
Posts: 37 |
Yeah, thats a pretty nice demo showing tape-streaming. I am quite sure there are lots of cool things one could do with it. Still, a scroller is pretty cpu consuming so obviously perfect timing is necessary to be able to use this for example a game or something. Although I guess one would be bored at rewinding the tape for every time one wanted to play again. :)
|
| |
Mace
Registered: May 2002
Posts: 1799 |
Quote:Although I guess one would be bored at rewinding the tape for every time one wanted to play again. :) That is easily fixed by putting the demo on both sides of the tape ;) |
| |
algorithm
Registered: May 2002
Posts: 705 |
Quote: Quote:Although I guess one would be bored at rewinding the tape for every time one wanted to play again. :) That is easily fixed by putting the demo on both sides of the tape ;)
Or make the demo two sided :-} |
| |
johncl
Registered: Aug 2007
Posts: 37 |
What I find strange is that they didnt see the potential of the tape drive better. For example, from what I have understood, these tape drives only recorded one track, while most heads actually supported stereo tracks. Why didnt they record on both tracks which could bring the saving/loading down to half. And while they were at it they could have recorded both "sides" at the same time which would make it 4 times faster. Although that would require the user to always put the tape on the correct side since they would still use the standard tape drive.
I guess it was because they could reuse existing hardware to make it as cheap as possible and once it was established there was no way they could change it. Sad really, imagine tape games loading 4 times faster. |
| |
algorithm
Registered: May 2002
Posts: 705 |
Quote: What I find strange is that they didnt see the potential of the tape drive better. For example, from what I have understood, these tape drives only recorded one track, while most heads actually supported stereo tracks. Why didnt they record on both tracks which could bring the saving/loading down to half. And while they were at it they could have recorded both "sides" at the same time which would make it 4 times faster. Although that would require the user to always put the tape on the correct side since they would still use the standard tape drive.
I guess it was because they could reuse existing hardware to make it as cheap as possible and once it was established there was no way they could change it. Sad really, imagine tape games loading 4 times faster.
Thats almost the same question as asking why VIC II did not have 16 sprites rather than 8. I suppose a mono signal is more reliable and 'lasts' longer. Besides if the tape drive had the facility along with the rest of the circuitry for the C64 to be able to read two signals, not many people would have purchased the 1541 (Although Random Access is always great)
The only advantage in the tape drive was its storage capacity in comparison to the disk as well as the cheap price. |
| |
johncl
Registered: Aug 2007
Posts: 37 |
Well, I wouldnt say thats a fair comparison. The VIC chip took quite a bit of research and work to be created. Stereo tape drives had been around for a long time, even 8 tracks had been around so the technology for storing data on the whole tape was already there. And the C64 was only recording pulses, not an accurate analogue stream. Its really a technology that was under-estimated or dumbed down for other reasons.
But your marketing point holds valid, the faster the tape drive, the less motivation to buy the 1541. :) |
| |
algorithm
Registered: May 2002
Posts: 705 |
I dont think any tape device connected to a computer at that time would be able to save/load two channel streams at once. The signal would have been less reliable without a doubt in comparison to the mono signal.
The Kernal should have had a fastload/save facility. Saving full memory contents in less than 5 minutes and loading would have still been very reliable rather than the ridiculous twice saving of data.
It was too late at the time I suppose. The Kernal was already created just the same as the C2N was created and the tape connector did not have the facility to receive/transmit two signals hence would have to have been userport/cartridge based (perhaps also joyport?)
If you remember later on in the years there was a Rainbow Arts CD with special interface which would load data at a decent speed
Regarding the speed in comparison to 1541 The Turbotape (Particularly Superturbo) was actually faster than 1541 (Without a disk fastload obviously) |
| |
algorithm
Registered: May 2002
Posts: 705 |
Unfinished Demo 1
The above is a c64 demo created around 14 years ago or so by me. (Please excuse the lame coding and scrolltext) Had no motivation to finish it at the time (What do you expect when coding the entire thing using AR monitor and Tape!)
It was originally part of a multitape demo which contains an IRQ loader. Press space after the demo which starts off the tape loader. Scrolltext, Fading logos and music, although has potential of full demo parts running while data is being pulled off from tape at around the same speed as turbotape. Although solid rasters are not possible using this method |
| |
Zer0-X
Account closed
Registered: Aug 2008
Posts: 78 |
En example for a bedtime read:
http://oms.wmhost.com/TAP/loaders/SLC_Flimbo's_Quest.txt
|
