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?

Improve this question
1
  • 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. Commented Apr 22, 2016 at 15:41

1 Answer 1

Reset to default
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.

Improve this answer
2
  • 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? Commented Mar 24, 2018 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. Commented Apr 4, 2019 at 5:43

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.