13

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

  • CLOAD/CSAVE
  • 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?

SF.
  • 7,095
  • 7
  • 30
  • 58
  • 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

1 Answers1

7

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.

Stephen Kitt
  • 121,835
  • 17
  • 505
  • 462
  • 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? – Maury Markowitz 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. – Jeremy J Starcher Apr 04 '19 at 05:43