Once you have that assembly listing, you can go through and examine it in detail. Last I looked, some parts of it were auto-commented. Either way, you have something very valuable. A high level, simplified representation, and a lower level assembly language one.
Not "auto-commented" exactly, but the compiled assembly listing does show the original batari Basic instructions as comments, followed by the assembly code that was generated for/from those batari Basic instructions. The assembly code itself doesn't contain comments, though, except any comments that Fred (batari) may have added into the code while he was writing it, and those would probably be more along the lines of "notes to self."
But being able to see the original batari Basic instructions with the assembly code they generated is invaluable if you're just learning assembly.
In fact, this presents a good reason for putting individual batari Basic instructions on their own program lines as much as possible, rather than using colons to cram dozens of batari Basic instructions into each program line. If you put four instructions on one line, the assembly listing will show all four instructions as a single comment, followed by the assembly language for all four of those instructions, which would make it harder to see which assembly code corresponds to which individual instruction.
Of course, sometimes you *have* to put multiple instructions on a single line, separated by colons, such as in the "then" or "else" portions of an "if-then-else" construct. And you can save bytes of ROM by putting similar assignment instructions together on a single line (e.g., A=1:B=1:C=1:D=1). But as for an "if-then-else," you can usually redesign it to use "goto" so you can break the "then" and "else" portions up into one-instruction-per-line code if you want to see how each instruction gets converted to assembly code. And as for putting similar assignment statements together on a line, that's actually a good thing, because in the assembly code you can see how the value was loaded into the accumulator just once and then stored into several memory locations, rather than having to reload the (same) value into the accumulator each time.
I don't know if someone else already explained this, but you had asked why there were so many files. The reason for all the files is because each one is a step along the way.
You begin by coding your program, either in assembly language or batari Basic.
Your program can "include" other files in it. These "include" files contain bits of code or other instructions (such as label assignments) that don't change from program to program, so it's more convenient to put them in reusable "include" files, rather than having to code them all over again from scratch each time you want to make a new program. If you're using batari Basic, the necessary "include" files will usually be added to your program automatically, although you can include additional files if you want, or even tell batari Basic to use a different set of "include" files than the ones it would have used by default. If you're programming in assembly, you need to specify the "include" files you want to use. Either way, you generally save your program code as a single file; the various "include" files are separate files, but you don't need to save them (unless you're writing new "include" files of your own), because they're already saved.
If you're programming in batari Basic, you'll need to compile your program using the batari Basic compiler. It consists of multiple files-- the compile batch file, the various executables used in the compile process, and the various "include" files-- but all you need to worry about is the command that compiles your program. If you're using an IDE (a special text editor used by programmers), you can set up the compile command so you can compile your program with just a mouse click. Visual bB is an IDE that's created just for batari Basic, and it includes various tools to help you create your program more easily. But you can also use a generic IDE, and set it up to compile, assemble, and run your programs.
Anyway, the compile process creates one or more intermediate files that contain the assembly language equivalent of your batari Basic code.
If you're programming in assembly, you don't need to compile your program, but you will need to assemble it using an assembler, such as DASM. The assembler takes the assembly code for your program and converts it into machine code that the Atari can understand. It also puts the machine code into the proper ROM format that the Atari uses. If you're programming in batari Basic, the compile batch will automatically assemble your program as the second phase of the overall compile process.
The result will be a single file that contains the ROM image for your program, which can then be played in an emulator, or transferred to a cart and played on an actual Atari.