8-bit Atari Basic had three different formats of storing programs on tape.

  • LOAD "C:"/SAVE "C:"
  • ENTER "C:"/LIST "C:"

I understand the specifics of the last one - it behaved as if the contents of the file were typed from keyboard; with some rather simple hack you could save something else than the program in memory; a common one was appending RUN at the end of saved program making it autorun upon loading, as the command was executed as soon as the program was loaded.

I understand LOAD could take other handlers, like D: for disk. I've long and fruitfully used it with T: for tape in Turbo mode provided by cartridge.

But I completely fail to see the point behind CLOAD. Did it provide anything LOAD C: didn't? The two save methods were incompatible, you couldn't perform CLOAD on what you saved with SAVE C: so it wasn't just syntactic sugar. What was its purpose and difference "behind the scenes"? Saving typing "C:" seems pointless?

  • 2
    This page says that CLOAD is faster, but doesn't explain why. Probably it has something to do with how much processing is done to the data before it is saved/after it is loaded.
    – Konamiman
    Apr 22 '16 at 15:41

The three commands correspond to three different storage formats.

  • CSAVE drives the cassette recorder directly, and stores tokenized files using short inter-record gaps. This is the fastest mode (both when writing and reading) since it uses a compact representation and doesn't need to wait for the tape.
  • SAVE "C:" uses the cassette tape driver, and stores tokenized files in the standard tape format with long inter-record gaps.
  • LIST "C:" again uses the cassette tape driver, but it stores text files containing the BASIC listing in ATASCII. This is the slowest mode since it uses a verbose representation.

LIST "C:" provides the best compatibility, since any program which can read text files can load the listing. It also avoids the Rev. B BASIC bug which causes programs to grow by 16 bytes every time they're loaded.

  • 1
    This begs the question though, why didn't the C: driver simply use smaller inter-record gaps for all LOAD/SAVE operations? Was there any need for a second format? Mar 24 '18 at 20:40
  • Can't speak for the original developers, but I found the long intra-record gaps gave more processing time to deal with incoming data. Not useful in the context of BASIC, but when doing other I/O. Apr 4 '19 at 5:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.