Atari 8-bit turbo loaders?

[sack-c0s]

Well my thoughts have turned to mastering again (which will no doubt cheer up TMR )

 

Did such a thing exist? or failing that can anyone suggest any tips or tricks for reliably speeding up a tape load?

 

10 mins is a bloody long time to be writing a loading tune for...

[carmel_andrews]

I believe that Rambit and Micro discout (derek Firn/Fern) who both distributed the Rambit turbo tape h/w upgrade, also released various turbo loaders for converting popular tape games over to turbo format

 

I believe that Bewesoft also has a program called bw tape, which is apparently a modd'd version of the famous czech turbo 2000 turbo loaders

Edited October 25, 2005 by carmel_andrews

[Rybags]

I think the semi-commercial tape turbo is called Turbo-XC12 (or similar).

 

I did a turbo-loader (well, saver actually) some years back. I had the Atari ASM cartridge on tape only, so I saved it with a 1 block loader, followed by 2 seconds gap, then the 8K cart image as 1 big block.

 

To speed up the baud rate, I just used a VBLANK which plugged the audio registers to make it faster.

 

I was going to do a system which used a similar technique to the Commodore Turbo loaders, but I don't think standard Atari tape drives permit it. I'm fairly sure that the conversion from tones to a bitstream is done by the tape drive and not the computer when loading.

 

For disks, I found that standard formatted floppies actually read a bit faster if you read them backwards (last sector on each track, through to the first). Some hardware upgrades allow optimized formatting which will read a little faster on un-modded drives.

 

For a tape only system these days, I'd suggest getting a pack/depack program, but it would involve doing a custom loader for each program. But, for 48K games you could put the loader/depacker in RAM under the OS ROMs.

[ijor]

I suppose you are talking about software turbo. If I’m wrong and you are asking about hardware mods, then please ignore this whole post

 

There is not much that you can really do the increase the load speed. I elaborate a little bit about this below; but the most important thing is very good packing/compressing.

 

Tape load is so slow that you can perform RLE decompression at real time on the fly. It is amazing that almost no commercial tapes are compressed. In most cases you can reduce the effective loading time by a huge amount.

 

Regarding increasing the actual transfer bit-rate. You can’t increase it too much and yet stay reliable. It is very simple to record at higher bit-rates if you want. There are several utilities to do that and even Omnimon has an integrated “poke” to set the bit-rate. The higher the bit-rate the less reliable it is. The actual results would depend a lot on which tape recorder the user would load (some models are much better than others).

 

For decent reliability you need a custom loader though. Custom loaders use their own routines, not the ROM ones, and usually implement a different recording method as well.

[ijor]

so I saved it with a 1 block loader, followed by 2 seconds gap, then the 8K cart image as 1 big block.

 

This is not a very good idea, huge blocks are very unreliable. There is a huge difference regarding the reliability when you record tapes for yourself or for somebody else. Recording on one tape, and then loading with the same one is always much more reliable.

 

I'm fairly sure that the conversion from tones to a bitstream is done by the tape drive and not the computer when loading.

 

Correct.

 

Some hardware upgrades allow optimized formatting which will read a little faster on un-modded drives.

 

Most drive enhancements don’t care at all about the sector interleaving because they use track buffering. The only notable exception is the USD, which indeed supports a custom interleave. But the different optimal interleave is a result of the higher transfer bit-rate.

[Rybags]

Re: hardware mods. I think most (if not all) turbo-loaders originated in Eastern Europe.

 

Once the Atari took off there (in the mid-1980's) disk drives were fairly cheap elsewhere so most people weren't worried at all about tapes. Not to mention the arrival of the 16-bit machines.

 

From memory, my 8K loader was almost 100% reliable, but I only ever used it on one tape drive.

 

Doing 1/2K or 256 byte blocks + higher baud + compression could deliver a decent load time. But, maybe a little pointless since an old P200MMX PC+ APE interface can be had for well under $50.

[Curt Vendel]

Isn't one of those turbo loader also detailed with info on using a CD-ROM as well ?

 

 

 

Curt

 

Re:  hardware mods.  I think most (if not all) turbo-loaders originated in Eastern Europe.

 

Once the Atari took off there (in the mid-1980's) disk drives were fairly cheap elsewhere so most people weren't worried at all about tapes.  Not to mention the arrival of the 16-bit machines.

 

From memory, my 8K loader was almost 100% reliable, but I only ever used it on one tape drive.

 

Doing 1/2K or 256 byte blocks + higher baud + compression could deliver a decent load time.  But, maybe a little pointless since an old P200MMX PC+ APE interface can be had for well under $50.

954013[/snapback]

[pps]

Well my thoughts have turned to mastering again (which will no doubt cheer up TMR )

 

Did such a thing exist? or failing that can anyone suggest any tips or tricks for reliably speeding up a tape load?

 

10 mins is a bloody long time to be writing a loading tune for...

953940[/snapback]

 

I can remember the old days in GDR, when I only had a tape...

 

There has been a loader (with the long beep about 15 counters), which made the loading a bit faster on non modified tape - about half loading time.

 

The copyprogramme was named something like happy turtle copy...

 

On some disc I should have this tool. Have to look for.

 

When loaded turtle from DOS, you could directly copy easily from disc to "turbotape".

[Wrathchild]

I do recall having played "Galactic Chase" from cassette

which loaded fairly quickly on a stock 1010. It just seemed

that the bit rate had been ramped up and because the O/S

compensates for the baud/bit rate, it loaded OK.

[www.atarimania.com]

I could be completely wrong but doesn't Encounter! by Novagen Software use a special loader?

 

--

Atari Frog

http://www.atarimania.com

[ijor]

It just seemed that the bit rate had been ramped up and because the O/S compensates for the baud/bit rate, it loaded OK.

 

Yes, but again this is not very reliably if you increase the bit-rate too much. The compensation was designed for variations of the tape motor speed, not for turbo. It measures the load time of the block header, which has a known fixed pattern. And then it computes the actual Pokey divisor. The algorithm uses non-linear interpolation that is optimized for the nominal bit-rate. The more you deviate from the nominal, the less precise it is.

 

It is possible to improve on this. I implemented a software turbo that didn’t use the OS at all. The algorithm was then optimized for the new “turbo” speed. But perhaps what was most important is that it supported retries and error recovery. If there was an error the user was alerted. He would then rewind the tape a bit and the loader would resync automatically and continue loading. This allowed for a higher bit-rate with a good reliability.

 

Isn't one of those turbo loader also detailed with info on using a CD-ROM as well ?

 

I never used CDs on the A8, so this might be a stupid question (mine, not yours). But what's the relation with tapes and CDs?

[krupkaj]

Isn't one of those turbo loader also detailed with info on using a CD-ROM as well ?

 

Yes, it is called Mega CD. Jindroush has information about it on his web:

 

http://www2.asw.cz/~kubecj/aturbo.htm#megacd

[carmel_andrews]

Another solution would be the xl/xe hardware mod the O/S controller card initially imported in EU/UK by computerhouse/stocksoft

 

O/S controller card, amongst it's many features/options allowed you to modify the baud rate for tape loading and saving

[TMR]

Can i just point out that what Sack is talking about is tape mastering for general release through Cronosoft; that means no hardware mods because it has to work on any 64K A8 and any tape deck and do so relatively reliably. We've already got the load time down to ten minutes by compressing the file with Super Packer.

[Wrathchild]

Way back I studied the loader used on the C64 tape version of Impossible Mission.

IIRC this uses a two tone form of (what I think is called) 'Manchester' encoding.

As the atari drives permit you to do this (e.g. the 'marks' placed on the data tracks against audio that the code detects to move onto the next screen) then I thought something similar would be possible, but I never attempted to writing a 'save' routine in order to be able to test a loader. Might be worth digging up that stuff.

Also, and mentioned above, someone had told me that the tape unit would perform some kind of operation on the 'sound' when reading and so this could render any attempts as such an encoding method useless.

[ijor]

Can i just point out that what Sack is talking about is tape mastering for general release through Cronosoft; that means no hardware mods because it has to work on any 64K A8 and any tape deck and do so relatively reliably.  We've already got the load time down to ten minutes by compressing the file with Super Packer.

 

In such a case there is not much that you can do.

 

You can increase the bit-rate up, say, about 15%-20%. As I said, you can do this very easily if you have Omnimon. This won't require any custom loader.

 

With a custom loader you can increase the bit-rate a bit more, but not really too much if you want to stay reliable. Plus you can change the block size to 256 or 512 bytes (I wouldn't recommend a much bigger block size). By using bigger blocks you reduce the total number of blocks. And because each block has an overhead (header, checksum, gap), you reduce the overall load time.

 

C64 tape version of Impossible Mission.

IIRC this uses a two tone form of (what I think is called) 'Manchester' encoding.

 

Hmm, I'm not sure what you mean. The Atari tape system already uses a two tone encoding called FSK, not Manchester (Manchester is actually one of the names used for FM encoding, the one used in A8 single density disks).

 

And the translation from FSK to binary is already done by the tape unit using analog filters. So you can't change the low level recoding/encondig in any way.

 

Or you mean using the audio channel? You can't do anything at all with the audio channel. The CPU doesn't see the audio channel in anyway. It comes to the computer from the audio-in signal and it is mixed with the Pokey output (plus the speaker in XL/XE models).

[Rybags]

I remember there was once an addon for the C-64 that you hooked up to a VCR.

 

It could load/save games in a fraction of the time of even a disk drive (although not saying much against a standard 1541).

[www.atarimania.com]

With a custom loader you can increase the bit-rate a bit more, but not really too much if you want to stay reliable. Plus you can change the block size to 256 or  512 bytes (I wouldn't recommend a much bigger block size). By using bigger blocks you reduce the total number of blocks. And because each block has an overhead (header, checksum, gap), you reduce the overall load time.

Encounter! has something like forty blocks, is that the method Paul Woakes used?

 

--

Atari Frog

http://www.atarimania.com

[Wrathchild]

Hmm, I'm not sure what you mean. The Atari tape system already uses a two tone encoding called FSK, not Manchester (Manchester is actually one of the names used for FM encoding, the one used in A8 single density disks).

 

And the translation from FSK to binary is already done by the tape unit using analog filters. So you can't change the low level recoding/encondig in any way.

 

Or you mean using the audio channel? You can't do anything at all with the audio channel. The CPU doesn't see the audio channel in anyway. It comes to the computer from the audio-in signal and it is mixed with the Pokey output (plus the speaker in XL/XE models).

954657[/snapback]

Confusion comes from me using the phrase 'two tone' I guess,

a better way to think of it would be 'tone' , 'no tone'.

 

You are thinking in terms of the SIO code, i.e. the cassette is sending

a 128K block a byte at a time serially... so is still a binary transfer.

 

If you ignore this and just say "start cassette motor" and monitor the

bit that identifies a 'mark' then you can have your own Manchester

decoder routine detect the changes, i.e. sync the clock and then check

for the high/low or low/high transitions and make bytes out of them.

 

Obviously a loader is more simpler that a saver, and I don't think that

a saving routine on the A8 itself would be optimal - e.g. due to the

overheads of preparing the data - the resulting clock rate would be

larger. So it maybe better to have a faster machine produce the

file (e.g. as a wav) and then record it to tape.

 

Regards,

 

Mark

[ijor]

If you ignore this and just say "start cassette motor" and monitor the bit that identifies a 'mark' then you can have your own Manchester decoder routine detect the changes, i.e. sync the clock and then check for the high/low or low/high transitions and make bytes out of them.

 

 

Oh, I see now what you mean (or at least I think so). It is quite an interesting an idea, but I don’t see how you’ll speed-up the loading with this. On the contrary, I think you’ll make it slower.

 

Manchester encoding has a transition rate that is twice the data bit rate. For example, on A8 single density disks you record at 250,000 TPS (transitions per second) for a bit rate of 125 Kbps. In other words, when you decode from Manchester to binary you get half the bit rate. This means you’ll make it twice as slow.

 

To get any gain using encoding methods you need to use advanced techniques like RLL. However I’m not sure it is feasible to perform RLL decoding on the A8 at the necessary speed. If you want to use these kinds of encoding you can’t use Pokey for shifting the bits. You need to measure the time between transitions by software. So you won’t have much time left for any processing. And you of course loose the possibility of decompressing on the fly.

[ijor]

Encounter! has something like forty blocks, is that the method Paul Woakes used?

 

You are talking about the Synapse or the Novagen release?

 

It might be something like this, yes. But in most if not all cases, the custom loaders and blocks at that time were used for a mild protection, and not for turbo purposes. Of course no protection on tapes is really good against audio dubbing.

[Wrathchild]

Remember that the 600bps that the cassette decks give is quite an age per bit in terms of the CPU. If I have my (rushed) sums correct then that's around 750 instructions (avg being 4 cycles). That's plenty of scope for a simple decode to run in much less time. Of course you have blocks and IRGs whilst transferring data around but that's managable too. Therefore, in theory, it could be faster. Hence these C64 loaders.

 

But from I'm recalling, the accuracy of the 'state' bit wasn't so good.

Might be worth trying out on some real hardware.

 

Mark

[ijor]

Remember that the 600bps that the cassette decks give is quite an age per bit in terms of the CPU.

 

You have plenty of time, but you must monitor the SIO line frequently to measure the transitions with enough precision. And the more advanced the encoding method the more the precision you need. And unfortunately there are no interrupts for SIO transitions, so the decoding code might need to be interleaved with peeks to the Pokey register.

 

But may be you are right, and may be this is feasible. I honestly never attempted any SIO stuff bypassing Pokey. It is certainly a very interesting idea and might be worth exploring.

 

There is another interesting issue related to this concept. You don’t really need a faster bit-rate to decrease the actual load time. Bypassing Pokey and using any self-clocking method, you avoid the need of start and stop bits. This by itself is a significant gain.

 

Another possibility is just to increase the word size. Use, say, 10, 12 or 16 bit words.

 

Of course you have blocks and IRGs...

You don’t really need IRGs, they can be removed altogether when using a custom loader.

 

I still think that the most important gain is obtained by the compression. So may be the best idea is to find the best possible compression (which can obviously done on a fast modern computer) that can still be decompressed fast enough on the A8.

[Heaven/TQA]

i think Fox' Fastpacker is one of the fastest packers around on 800xk with avg decompression speed of 30kb/s...

[analmux]

I think cpu speed is not the problem here, even if you have to peek the pokey registers by software.

 

The main limitation may be the minimal time before the tapedrive detects a one or a zero from a certain tone on the tape. I don't know what exact frequencies are used for a 0 or a 1, but everytime the tapedeck measures a bit, that tone must last for a certain amount of time. At least one period of the soundwave. I think (not know for sure) that the frequencies are around 8khz, so maybe up to 8kbps is possible ???