Tape Loaders

[snicklin]

I've never really known much about tape loaders on the Atari and am wondering a few things.

 

1) Has anyone ever produced one which will play sound so that it sounds like a ZX Spectrum whilst loading? (I love the Spectrum loads!)

 

2) What do they typically do? Are decompression routines routinely added to them? Do they typically amend I/O parameters to save tape length? Of course I've seen pictures, which are rather rare on the Atari (I guess due to annoying the user because of the already long load times)

 

3) Are there any standard open source / freeware / PD loaders for the Atari?

 

I've also seen the ones which just blank out the screen or add "Load Error" messages.

 

If you have any other information about them, please let me know.

[Rybags]

Compared to what's possible, Atari tape loaders were mainly fairly spartan.

 

To begin with, a loader is optional anyway, you can load an entire program at boot in a single stage.

I'm not aware of anything from the early times that employed compression. Generally any compression other than simple RLE will take too much CPU time to work with normal short IRG tape files anyway.

That's not to say a large block could be loaded then decompressed - most modern schemes work that way anyway, regardless of media type.

 

There's all manner of stuff that could be done while loading, you could even have a game going. Although you can't use all the Pokey voices since the serial function uses 2 (?) for cassette operations.

 

Realistically the only type of loader that would be worthwhile doing in generic fashion for tape is a binary loader, ie able to process Xex type files that DOS can normally handle. I did one years back, plenty of others likewise.

 

Most old commercial stuff just used the bog standard bitrate and 128 data bytes per record. Funnily enough they could have done things like variable record length or long 1K or more records which could increase speed and enhance copy protection but I know of no games that did that.

[thorfdbg]

I've never really known much about tape loaders on the Atari and am wondering a few things.

 

1) Has anyone ever produced one which will play sound so that it sounds like a ZX Spectrum whilst loading? (I love the Spectrum loads!)

 

2) What do they typically do? Are decompression routines routinely added to them? Do they typically amend I/O parameters to save tape length? Of course I've seen pictures, which are rather rare on the Atari (I guess due to annoying the user because of the already long load times)

 

3) Are there any standard open source / freeware / PD loaders for the Atari?

 

I've also seen the ones which just blank out the screen or add "Load Error" messages.

 

If you have any other information about them, please let me know.

As already said, tape loaders were pretty much bare bone if existing at all since the Os tape bootstrap was completely sufficient to load images from tape and no further programming was needed. Additionally, the Atari tape format is pretty much wired in hardware, namely the decoder logic within the tape recorder itself, so you couldn't do much there.

 

The Atari tape is a stereo tape, thus you can play music from one of the channels while loading from the other. I believe Atari published a couple of educational software that used this trick. What you cannot do is play music from the Atari hardware itself. The tape I/O uses all four pokey channels available (two to define the baud rate, one for the low and the other one for the high tone for the FM modulation. Even though the latter two are not required for loading, the Os SIO initializes them anyway, so no avail).

 

A couple of custom loaders just read the atari DOS binary load format instead of the Os bootstrap format, essentially to load disk titles from tape. A couple claim to speed up things, but actually don't. As said, the two-tone modulation for loading is built into hardware, and the filters in the hardware have a limited response time limiting the baud rate, so there was not much you could do without hardware modification. A couple use a custom SIO routine to load titles from tape, as a type of copy protection. Checksums and tape record types were altered, though the actual hardware encoding was not, due to the same limitations I mentioned above. Thus, not a bit faster at all.

 

I'm pretty sure that there might be open source loaders, but as said, this is typically a pointless exercise as it doesn't help a bit to improve the tape speed. Compression might work, yes.

[Rybags]

Forgot to mention the audio track but of course you'd already have known.

 

There is scope to speed up tapes with faster bitrates - although in a commercial environment you'd probably leave at stock to be assured of reliability.

 

Compression is a double-edged sword - saving some 5 seconds on load time might become irrelevant if it then takes 10 seconds to decompress it.

 

Something I've been wanting to explore is bit-banging tape input rather than letting Pokey do it. With Pokey SIO there is always the start/stop bit which adds 25% extra payload, ie 10 bits per byte instead of 8.

Using software to read the input bit state and dispensing with most of the start/stop bits, slightly increasing bitrate and using longer records, we could probably speed up loading by 50% or more.

[snicklin]

Something I've been wanting to explore is bit-banging tape input rather than letting Pokey do it.

 

With "bit-banging", do you mean sending out the data byte-for-byte, i.e. no overheads of checksums etc? If so, wouldn't we then be at risk of games loading which are corrupted which will give random output?

 

It has been mentioned that the Pokey channels are being used, so does that mean that XXL's 1-bit system could be used, if the overheads of it (which I guess they will be) are not too much for the Atari to handle (while loading)?

 

Does anyone have any links / pointers to any available loaders that I can work with?

Edited January 26, 2014 by snicklin

[xxl]

take this.

 

you can write data to tape this way - without start&stop bits.

magnet.obx

Edited January 26, 2014 by xxl

[snicklin]

take this.

 

you can write data to tape this way - without start&stop bits.

 

Thank you!

 

However, how does this work? I've tried to load it in Altirra and it crashes.....

[Rybags]

Bit banging - removing checksum would make barely a difference, standard record is 132 bytes total, omitting 1 byte = under 1% improvement. The meaning of bit-banging here is setting the output value direct rather than letting Pokey handle it, which allows us to omit start/stop bit overhead.

 

Pokey-driven SIO always has start/stop bits, no way around it except doing R/W direct to the serial line.

That means 10 bits per byte which adds up to a significant overhead for letting Pokey do SIO, doing it by bit-banging can reduce to 8 bits.

 

By eliminating practically all of those, a significant speed increase could be had. The expense would be CPU time, but standard OS SIO is interrupt driven and the main loop just sits there waiting for the operation to complete so no loss really.

The other expense would be reduction in reliability. How much - unknown. But the system could be tweaked, e.g. throw in stop/start bits at certain points like every 32nd byte to allow the loader to resync.

 

It would need to be driven by Pokey timers which control when the samples are taken. For saving, the timers decide when the handler sets the forced I/O value to reflect the next bit being sent.

[xxl]

 

Thank you!

 

However, how does this work? I've tried to load it in Altirra and it crashes.....

 

use atari. I think it's not working on emulators.

 

using b7 SKCTL you can write without SEROUT reg. and without start/stop bits

using b4 SKSTAT you can read without SERIN reg...

[thorfdbg]

As already stated, the pure removal of the Os checksum gains nothing. The baud rate can be increased somewhat, and the size of a tape record can be increased by using a custom SIO. Atari++'s disk based tape handler has a "turbo mode" that uses an increased baud rate and 256 byte records, but the speed increase is nothing to call home about. Measurable, noticable, but doesn't knock you off your socks.

 

Start stop-bit removal is nothing I would recommend. While I did not try this in actual hardware, I collected some experience with the wav2cas converter program I wrote over Christmas, and what I learned from there was basically that it is pretty important to have the start bit there (and thus also a stop bit, you cannot have one without the other) because drifts can be large enough to almost loose the bit synchronization within a byte. The problem is that the analog filters are not 100% reliable, and thus cause the bit lengths to vary, depending on the signal levels of the two tones and the conditions of the tape. The stop bit ensures that the line is in mark position, the start bit allows you to detect the start of the next byte reliably even if you were close to loose the synchronization from the last byte.

 

It is not sufficient to monitor the serial line once a bit because, again, you can run out of sync very easily. You need to monitor about 16 times a bit, then take the most likely value, again due to timing drifts, baudrate variations and poor filtering. It's not quite so trivial. The serial protocol even with start and stop bits is not very permissive over baud rate variations, even less so without them.

 

This being said, the overall architecture of the tape is in a rather poor state. Actually, one could have done a lot better and faster with a smarter modulation scheme. A simple manchester code would have been easier to implement in both software and hardware, would allow higher reliability *and* higher throughput. Aparently, whoever designed this tape interface had no clue. Unfortunately, there is not much you can do without modifying the hardware.

 

 

 

 

[wesmond]

Couple of old UK tape memories... Blue Max (Synsoft) and Gun Law (mastertronic) used very long records. Universal Hero (Mastertronic) used a slightly lower baud rate, whereas Kick off (Anco/Byte Back) used a slightly higher baud rate. Also, Dreadnaught (Byte Back) used an *enormous* long pause between each record, making it take around 25 minutes to load, even though the code wasn't very big...

 

Also, there were some little hardware kits to "turbocharge" a 1010, (Rambit was it?) which got it loading most big-ish games in under a couple of minutes - but the conversion process was not that easy. I think it was essentially doing a memory freeze, and having a little bit of code resident to dump the memory to tape.

[wesmond]

And many Firebird/Americana/US Gold games had a loader with "Blocks to load" counting down, a load of colour cycling, and often a smooth scroller telling you about all their upcoming products...

[snicklin]

whereas Kick off (Anco/Byte Back) used a slightly higher baud rate.

 

... now I understand why Kick Off only ever loaded once for me off tape.

[phaeron]

use atari. I think it's not working on emulators.

 

using b7 SKCTL you can write without SEROUT reg. and without start/stop bits

using b4 SKSTAT you can read without SERIN reg...

 

It doesn't crash because of the emulator, it crashes because of an illegal jump into the OS ROM that won't work on anything other than the XL/XE OS.

[bbking67]

shamus II had a really nice countdown screen.

[Stormtrooper of Death]

I remember from the 90s, that i had a program, that i used for faster loading on the XC-12. It was a software pre-loader that then could be used to load games, that were written by this program aswell.

 

Speed increased to minimum 2400 baud, instead of the slow Atari speed. Instead of 20 mins waiting for a game to load, the game would load in 2-3 mins.

 

Sadly, i forgot what the name of this program was. It was software based, and no hardware hacks were done to the XC-12.

 

The file of the fast game load started with 3 normal beeps (including pauzes),then switched off all gaps, and you heard one long noisestream, until end of file-load.

Edited January 29, 2014 by Stormtrooper of Death

[Heaven/TQA]

I remember software based 'turbo tape', too. Maybe Andreas can send some light

[Kr0tki]

Most old commercial stuff just used the bog standard bitrate and 128 data bytes per record. Funnily enough they could have done things like variable record length or long 1K or more records which could increase speed and enhance copy protection but I know of no games that did that.

We enjoyed some creativity in this area in Poland back then. Many commercial releases employed some tricks, mainly to combat piracy:

- Many releases by LK Avalon contained additional SPACE signals that were expected by the loader. Some of them (e.g. "Barahir") also bumped the baudrate up to about 700 baud.

- Spektra's "Inside" used long blocks - almost all of the data is contained in one >20 KB block - and a loading screen with an animated text.

- ASF's "Miecze Valdgira II" had the baudrate changing in the middle of each block.

More inventive ideas appeared on the cracking scene:

- "Feud" with music and simple game during loading

- Speeder 1400 - a software for converting files to a special format. Data is read by bit-banging SKSTAT, bypassing SERIN completely, which allows to reach speed of 1400 baud on an unmodified deck.

 

I remember from the 90s, that i had a program, that i used for faster loading on the XC-12. It was a software pre-loader that then could be used to load games, that were written by this program aswell.

Could that be CASA Turbo Tape? The available version supports only 860 baud and the loader consists of 2 blocks instead of 3, but the other details match. Maybe there was a later version for higher speeds?

[Stormtrooper of Death]

Kr0tki, i am not sure if it was 3 blocks. It could aswell be 2 blocks indeed.

 

I tried the tape turbo program some time, but stopped using it, because several games/programs wouldnt work after being transfered to turbo speed.

Edited January 30, 2014 by Stormtrooper of Death

[Chilly Willy]

Don't forget the two OS settings: the first being noisy/quiet. I always made my cassettes so that they did a short block that switched to quiet mode, then continued the load. The second OS setting was fast/slow - this did not affect the baud rate or frequencies, it changed the delay between blocks. BASIC always used slow mode so that the basic loader could do something with the block before the next block started loading. Boot cassettes all use fast mode.

[Wrathchild]

Way way back I had looked at how C64 fast loaders were coded (Impossible Mission I think) but the Atari tape I/O I recall was restricted to using a byte at a time approach as this is handled in the hardware. As XXL points out the SK registers can read the 'marks' (e.g. those used in the 'Teach Yourself' series to pause the tape at the right place) but IIRC I didn't find it too reliable.

[thorfdbg]

Way way back I had looked at how C64 fast loaders were coded (Impossible Mission I think) but the Atari tape I/O I recall was restricted to using a byte at a time approach as this is handled in the hardware. As XXL points out the SK registers can read the 'marks' (e.g. those used in the 'Teach Yourself' series to pause the tape at the right place) but IIRC I didn't find it too reliable.

There was a huge difference between the C64 tape and the Atari tape. The C64 tape recorder was more or less an off-the-shelve tape unit, where all the decoding was done in the C64 itself. Hence, software could be used to speed the tape up by changing the encoding. For the atari, the tape unit includes the two-tone decoder which more or less sets the modulation in stone. Hence, it was less flexible.

[thorfdbg]

Don't forget the two OS settings: the first being noisy/quiet. I always made my cassettes so that they did a short block that switched to quiet mode, then continued the load. The second OS setting was fast/slow - this did not affect the baud rate or frequencies, it changed the delay between blocks. BASIC always used slow mode so that the basic loader could do something with the block before the next block started loading. Boot cassettes all use fast mode.

Almost. Basic "CLOAD/CSAVE" used the "fast" (almost, but not quite as slow) mode, but anything else was slow, i.e. LOAD "C:", LIST "C:".

[Wilheim]

Reviving an old topic, but I have something to share:

 

In Chile there were a lot of different tape loader routines developed in late 80s and early 90s, mainly because tape drives were abundant:

 

- Prisma Soft developed NHP (stands for "No Hay Problema", a quote taken from the the latin american dubbed version from Tv Series ALF). It consists of 255 bytes records with error recovery. That means that if there were an error during the load, you don't have to restart again, just rewind a few loops and resume the loading.

- Turbo Software developed Turbo Tenis. It loads an small pong-like game first before loading the main game. Simple and fun! It also has an error recovery routine.

- There was also a system called STAC TURBO. It changes the baud rate to 900 bps and loads 192 bytes per block. Then again, with error recovery. It uses the $C000-$FFFF RAM zone.

- Vitoco created SITRE, a turbo tape loader routine with error recovery. Further info at http://www.vitoco.cl/atari/sitre/index.html(in spanish).

 

Regards!

[_The Doctor__]

Commando running on 192k nice!

Half an hour is just enough time to cook the pizza for gameplay!