Jump to content

Photo

STAC (Software Tape turbo with error recovery) sources

tape turbo

15 replies to this topic

#1 ijor OFFLINE  

ijor

    River Patroller

  • 2,012 posts

Posted Tue Jul 4, 2017 9:17 PM

STAC is a custom tape system I designed in the mid 80's. It was very popular in South America and spawned a myriad of clones, mostly at Chile, where Atari was very strong. Note that most clones just reused the main concept, and not copied the actual implementation.

 

STAC stands for Super Turbo Auto Corrector in Spanish. Is has a software turbo. But I learned soon enough that the reliability of the turbo depends on many external factors. So STAC implements other features that I considered even more important.

 

The key feature in STAC was error recovery. The Atari tape system is slow enough that it is almost unbearable to wait until some software finishes loading. But worse than this was being very close to complete the loading and suddenly getting a load error. You had to rewind and start all over from the beginning. At this point what you really wanted is to throw the tape, the recorder, and even the computer out of the window.

 

To avoid this, STAC implements a simple error recovery. If the loader detects an error the user is prompted to rewind just a little bit. The loader then resyncs with the tape, hopefully this time the error is not repeated, and continues loading. Most errors are typically soft errors and the retry logic works very well.

 

STAC also implements a simple zero cost RLE compression. The data is decompressed on the flight while loading. I was amazed how much this saved in some cases.

 

Finally, although not strictly a STAC feature, I adapted for tape several titles that were available only on disk.


Edited by ijor, Tue Jul 4, 2017 9:17 PM.


#2 ijor OFFLINE  

ijor

    River Patroller

  • Topic Starter
  • 2,012 posts

Posted Tue Jul 4, 2017 9:20 PM

These are the original STAC sources. They include the original comments in mixed Spanish and English language. Sorry, but that's how I used to write the comments at the time. If I'll find the time I will try to expand and elaborate the comments. I'm not 100% sure this is the latest version. But if it is not, it should be very close. They assemble with AMAC (Atari Macro Assembler). Shouldn't be so difficult to adapt to other assemblers.

 

The source is for the STAC recorder, the software that writes using the custom tape system. The loader is embedded in the recorder.

 

STACAUT.ASM : Main recorder source

STPRES :  Main loader source

PANT.ASM : Load screen

TOS.ASM : Custom tape routines.

HIGH.ASM : SIO high speed xfer routines. Only for the recording system.

 

The recorder was distributed on disks that were optionally copy protected. The protection was not too sophisticated but the disks were recorded in enhanced density. The screen content was also protected to prevent changes. But of course, nothing is fool proof and I was aware about some cracks.

 

Attached Files



#3 ijor OFFLINE  

ijor

    River Patroller

  • Topic Starter
  • 2,012 posts

Posted Tue Jul 4, 2017 9:38 PM

Some CAS images on STAC system available here: http://atariage.com/...65-stac-images/

 



#4 vitoco OFFLINE  

vitoco

    Moonsweeper

  • 284 posts

Posted Wed Jul 5, 2017 8:10 AM

Wow! Impressive! Thank you!

 

I'm from Chile, and by the end of 1988 I was told about some games that were created using a "STAC system" that came from Argentina. The other turbo system at the time was the Injektor, which has similar features but required a modified tape unit (the Atari XL12-Injektor). As I didn't own a tape unit, I never paid enough attention to them. I even thought that both systems where the same.

 

A local game provider asked me if it was possible to create a similar system to his store, because the existing copiers were slow (compared to them) and some games could be loaded using some copiers but not with others. I had read somewhere about a simple way to change the tape recording speed, so I acceped the challenge. The result was SITRE, which I documented (English by Google Translate), updated and partially released last year.

 



#5 Franco Catrin OFFLINE  

Franco Catrin

    Star Raider

  • 56 posts
  • Location:Quilpué, Chile

Posted Wed Jul 5, 2017 8:28 PM

This is awesome in many levels!!!

 

I was behind a CAS with your loader for many years and I got one just a few days/weeks ago.  I reverse-engineered your loader when I was a kid and I always had trouble understanding a part that seemed like an alternative bitrate estimator to me. I haven't checked your code yet and I don't know if I should jump directly into it or I'll try to repeat the reverse-engineering, it was just too fun.

 

If that was a bitrate estimator, your loader is unique. All turbo/error recovery clones (including mine) didn't made that part, only tuned the SIO to use a faster bitrate at recording. 



#6 ijor OFFLINE  

ijor

    River Patroller

  • Topic Starter
  • 2,012 posts

Posted Thu Jul 6, 2017 11:44 AM

Some technical details for those interested. But please bear in mind that I didn't touch this stuff for about 30 years.

STAC uses a software turbo that by default it records at 990 bps. I experimented with higher values, and the software can be easily configured for other rates. As a matter of fact sometimes higher rates were actually used for recording. The loader extends and improves upon the OS auto baud detection. But the reliability of higher rates depend on some things that sometimes you couldn't control, including the recording system, the tape, and of course, the user's player.

The error recovery is straightforward and uses a simple mechanism. Each block is numbered. Whenever an error is detected the tape is stopped and the user is prompted to rewind a couple of blocks. Then the loader scans blocks until the expected block number is matched. At this point the loader resyncs and retries reading the block that previously failed.

The block size is a compromise between speed and reliability. Larger blocks load faster because there is a fixed overhead per block including the IRG (inter record gap). But larger blocks have more chances to get hit by an error and make the error recovery less efficient. STAC uses a block size of 200 bytes, about 50% larger than the standard Atari block size of 128 bytes. I'm afraid I don't remember how and why I decided for this exact size.

IRG (Inter Record Gap), the gap between blocks, is much smaller than the short standard one used by the OS. It can't be reduced much more because that would interfere with the resync logic that requires more than one byte time without transitions on the line to reliably detect the start of a block.

The loader uses RAM under the ROM for the purpose of leaving standard RAM to the loaded program as much as possible. This wasn't a significant limitation because computers with less than 64K RAM (400/800) were very rare at the region.

The recording system uses a simple custom disk file system. Each directory entry, besides the name of the software, size, and location on disk, included the load and run address, and a number of flags that modified some of the behavior of the loader. The actual file data must be already compressed and without any kind of headers. The recorder can't understand a file in standard Atari binary format.

Data is compressed with a simple RLE method and decompressed on the flight while loading. Compression was performed by a separate tool that so far I couldn't locate the source. As I recall there were a couple of generations of the compressor, and the latest one run on an Atari ST.

 



#7 ijor OFFLINE  

ijor

    River Patroller

  • Topic Starter
  • 2,012 posts

Posted Thu Jul 6, 2017 11:55 AM

I'm from Chile, and by the end of 1988 I was told about some games that were created using a "STAC system" that came from Argentina. The other turbo system at the time was the Injektor, which has similar features but required a modified tape unit (the Atari XL12-Injektor). As I didn't own a tape unit, I never paid enough attention to them. I even thought that both systems where the same.

 

Hi vitoco,

 

I'm afraid I don't know or remember all the clones that implemented a similar error recovery. I'm not sure, but I believe injektor was developed by Pedro, a friend of mine from your country, and his father. Pedro actually happened to be the first to release a STAC clone because I personally showed him my system very early. He and his team used to come to visit to my country rather frequently at the time. For me it was so great because at the time he was the only one I knew that I could sustain a high technical conversation about the Atari. I even told him how STAC works. Of course that he wrote his own implementation.

 

Congratulations for your work as well :)



#8 ijor OFFLINE  

ijor

    River Patroller

  • Topic Starter
  • 2,012 posts

Posted Thu Jul 6, 2017 12:07 PM

I reverse-engineered your loader when I was a kid and I always had trouble understanding a part that seemed like an alternative bitrate estimator to me. I haven't checked your code yet and I don't know if I should jump directly into it or I'll try to repeat the reverse-engineering, it was just too fun.

 

Hi Franco,

 

Yep, STAC has an auto baud detector similar in some ways than the one used by the OS. I seemed to remember that it uses tables again, as the OS, just extended for higher rates. But I can see in my own sources that it actually uses a formula. I think now I used tables in some earlier tests, but I'm afraid I don't remember too much about that. I haven't done anything with STAC for close than 30 years! LOL.

 

Btw, the bitrate detector counts frames and, of course, it checks if the system is PAL or NTSC to compute the bitrate from frames and scan lines. But this will fail if the computer happens to have a mixed ANTIC-GTIA pair, one PAL and the other NTSC. Don't remember either if I was aware at the time about the existence of those "hybrids".

 

Reserve engineering is sometimes too fun indeed. Glad you enjoyed reverse engineering my work. Really. I will post disks images with the STAC recorder on the other thread. Some of those disks have an earlier version than the source I posted. And I'm afraid I didn't use to keep all the historic versions as it is common practice nowadays. So reverse engineering might still find something not fully documented. LOL



#9 Franco Catrin OFFLINE  

Franco Catrin

    Star Raider

  • 56 posts
  • Location:Quilpué, Chile

Posted Thu Jul 6, 2017 1:29 PM

May be you don't realize but you are some kind of God to us.  Your STAC inspired a lot of people here in Chile, I even got my first job thanks to a clone system that I did after reading your code (I was 14). Not to mention the users!! They just adore the turbo + error recovery system. Vitoco made another clone that was way more popular than mine, and I knew about him because of that.

 

I think I'll do the reverse engineering again and then compare my findings with your source, just for fun.



#10 José Pereira OFFLINE  

José Pereira

    River Patroller

  • 4,098 posts
  • Location:Lisbon - Portugal

Posted Thu Jul 6, 2017 7:34 PM

May be you don't realize but you are some kind of God to us.  Your STAC inspired a lot of people here in Chile, I even got my first job thanks to a clone system that I did after reading your code (I was 14). Not to mention the users!! They just adore the turbo + error recovery system. Vitoco made another clone that was way more popular than mine, and I knew about him because of that.
 
I think I'll do the reverse engineering again and then compare my findings with your source, just for fun.

Hi Franco. Nice to see you here again and hope that me, MrFish and you can talk soon ;)...
:thumbsup:

#11 Franco Catrin OFFLINE  

Franco Catrin

    Star Raider

  • 56 posts
  • Location:Quilpué, Chile

Posted Thu Jul 6, 2017 7:44 PM

Hi José!! We have to go back on track!



#12 Heaven/TQA ONLINE  

Heaven/TQA

    Quadrunner

  • 10,770 posts
  • Location:Baden-Württemberg, Germany

Posted Fri Jul 7, 2017 12:51 AM

never heard of such tape system... I was using 1010 standard tapes (still remember my first cassette with Blue Max / Dimension X piano loading music) and always was wondering why the damned VIC20 or c64 had "turbotape" ;)



#13 Faicuai OFFLINE  

Faicuai

    Dragonstomper

  • 759 posts
  • Location:Florida, U.S.A.

Posted Sun Jun 10, 2018 2:33 PM

Wow! Impressive! Thank you!
 
I'm from Chile, and by the end of 1988 I was told about some games that were created using a "STAC system" that came from Argentina. The other turbo system at the time was the Injektor, which has similar features but required a modified tape unit (the Atari XL12-Injektor). As I didn't own a tape unit, I never paid enough attention to them. I even thought that both systems where the same.
 
A local game provider asked me if it was possible to create a similar system to his store, because the existing copiers were slow (compared to them) and some games could be loaded using some copiers but not with others. I had read somewhere about a simple way to change the tape recording speed, so I acceped the challenge. The result was SITRE, which I documented (English by Google Translate), updated and partially released last year.


Had to recently check my barely used Japan-made 1010 (which I keep for a handful of titles that only run with Tape recorder), and had to replace the belts, which thank God I purchased a while ago, "just in case".

At this point, I decided to give SITRE a try, as a good workout for the 1010 (only tape recorder I would recommend), and... oh boy!!!!

What an AWESOME, KICK-ASS piece of work SITRE is!!!! I recorder Super Breakout, Yoomp, Full-title Zaxxon, Video Blitz demo, Ocean Detox and Matrix rain-demo (almost 200 Kbytez) in a single, dreadful 60mins tape... which it managed to read with ZERO (NONE) errors !!!That was better than my lifetime of tape-readings I managed to painfully extract from the worthless piece-of-shit 410 that I got with my first Atari 8bit (a 400).

Absolutely impressed!!!!

#14 rcgldr OFFLINE  

rcgldr

    Star Raider

  • 63 posts

Posted Sun Jun 10, 2018 5:00 PM

Probably too late now, but assuming bad reads didn't entirely stop the read process, then some type of ECC (error correction code) could have been used. The simplest scheme would be to XOR each block and put that XOR block at the end of the tape. This would work only if one of the blocks was bad, XOR'ing all the good blocks read would recreate the one black that wasn't read.  The next step would be to group the data on tape into groups of 16, 15 blocks of data, one XOR block, so that any one block bad out of the 16 could be recovered. Higher level ECC could be used, but the cpu time could be excessive, and probably not needed for a device with a relatively low error rate. Wiki article:

 

https://en.wikipedia...rror_correction


Edited by rcgldr, Sun Jun 10, 2018 5:01 PM.


#15 vitoco OFFLINE  

vitoco

    Moonsweeper

  • 284 posts

Posted Tue Jun 12, 2018 8:06 AM

Had to recently check my barely used Japan-made 1010 (which I keep for a handful of titles that only run with Tape recorder), and had to replace the belts, which thank God I purchased a while ago, "just in case".

At this point, I decided to give SITRE a try, as a good workout for the 1010 (only tape recorder I would recommend), and... oh boy!!!!

What an AWESOME, KICK-ASS piece of work SITRE is!!!! I recorder Super Breakout, Yoomp, Full-title Zaxxon, Video Blitz demo, Ocean Detox and Matrix rain-demo (almost 200 Kbytez) in a single, dreadful 60mins tape... which it managed to read with ZERO (NONE) errors !!!That was better than my lifetime of tape-readings I managed to painfully extract from the worthless piece-of-shit 410 that I got with my first Atari 8bit (a 400).

Absolutely impressed!!!!

 

I'm glad that you've found SITRE useful.

 

 

Probably too late now, but assuming bad reads didn't entirely stop the read process, then some type of ECC (error correction code) could have been used. The simplest scheme would be to XOR each block and put that XOR block at the end of the tape. This would work only if one of the blocks was bad, XOR'ing all the good blocks read would recreate the one black that wasn't read.  The next step would be to group the data on tape into groups of 16, 15 blocks of data, one XOR block, so that any one block bad out of the 16 could be recovered. Higher level ECC could be used, but the cpu time could be excessive, and probably not needed for a device with a relatively low error rate. Wiki article:

 

https://en.wikipedia...rror_correction

 

ECC could not be used by these tape loaders for many reasons:

 

- Data has a XEX structure, with headers, ponters and so. It is not just a huge memory data sliced in blocks, where you could go back and fix the identified bad block in memory using the checksum data. Bytes have to be processed sequentialy to know where to load the next chunk, where to stop the tape device to run an initialization routine in the computer and then to resume, etc....

 

- The calculation of the timming parameters to read a block of data from tape is made at the begining of each block, identifying some control bits at the beginning of the block. An error in that calculation makes the loader to read more tape to fill the block of data, reading beyond the real end of the physical block in the tape... then, the next block couldn't be available to be read.

 

- When there is a problem with the tape (bad quality, overuse, whatever), some bits might be weak, resulting in a bad block. As these loaders have some checksum data in every block, the most simple way to recover a block is to read it again immediatelly, thus the "rewind the tape 3 numbers of the counter" and then retry. If it fails again, and again, it's better to discard the tape.

 

So, the way that tapes are used in the Atari makes impossible to apply ECC even inside every single block.



#16 ijor OFFLINE  

ijor

    River Patroller

  • Topic Starter
  • 2,012 posts

Posted Tue Jun 12, 2018 7:59 PM

ECC could not be used by these tape loaders for many reasons:


Beg to differ. I think it can be used. If it is efficient or not is another issue, but certainly it can be used.
 

- Data has a XEX structure, with headers, ponters and so. It is not just a huge memory data sliced in blocks, where you could go back and fix the identified bad block in memory using the checksum data ...


Not always it's a XEX structure with blocks. My loader doesn't use binary file blocks. So may be you can't use this in every case, but in many cases you can.
 

- The calculation of the timming parameters to read a block of data from tape is made at the begining of each block, identifying some control bits at the beginning of the block. An error in that calculation makes the loader to read more tape to fill the block of data, reading beyond the real end of the physical block in the tape... then, the next block couldn't be available to be read.


I don't see this as a problem at all. If you compute a wrong bit rate then you would likely hit a framing error early on. And in the worst case, you have the IRG to always be able to detect the physical end of the block.
 

- When there is a problem with the tape (bad quality, overuse, whatever), some bits might be weak, resulting in a bad block. As these loaders have some checksum data in every block, the most simple way to recover a block is to read it again immediatelly, thus the "rewind the tape 3 numbers of the counter" and then retry. If it fails again, and again, it's better to discard the tape.


Sometimes retrying helps, sometimes it doesn't and it always fails. And the user typically has a single copy and many times it can't discard it and get another recorded tape. Error correction might be useful in that situation.

 

Again, not so sure ECC is a very efficient method here. It is certainly not efficient using a single block at the end of the tape because errors on multiple blocks are quite common. But it is IMHO a valid idea.

 







Also tagged with one or more of these keywords: tape, turbo

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users