I missed the basic era by a little but I always wonder why the BASIC roms never became the shell of the disk operating system when disks entered the pictured. Think analogous to the unix shell which is both the interactive command line and a scripting language. Get rid of the line numbers, add some directory access commands (list, mkdir, cd etc) and you would have a pretty good cli. but nobody appears to have done this. Instead you ended up with things cp/m and dos. fine enough I guess but their command interpreter sort of sucks in comparison to what basic could have brought to the table. And basic was already there.
BASIC had been aggressively trimmed down to fit into an 8K ROM on the first machines, and there just wasn’t room for much more than crude SAVE and LOAD commands unless we gave up something else. Expanded “disk basic” variants came later, but these were all non-standard.
CP/M and DOS were indeed pretty weak, but this was a time where being first to market with a minimum viable app was everything, and then compatibility with what had already shipped first stalled progress.
They sort of did this with BASIC 4.0 and later for Commodores. We had CATALOG for listing files, SCRATCH for deleting them, HEADER for formatting and so forth. These were standard BASIC commands, and could be used in programs as well as directly.
No, that was BASIC 2.0, and using any DOS commands was extremely awkward.
With the notable exception of listing the directory, which was pretty easy through a trick from the disk drive’s DOS which meant you could load the disk directory “as a program” with a special name, “$”, and then just LIST it. But you see, the drive’s DOS had to sort of go out of its way to make that simple.
If I recall correctly, for Commodores, the equivalent of the disk operating system was handled by the drive itself. If you wanted to do anything beyond a LOAD or a SAVE, you were effectively opening the device then sending a command to the device. The exception was getting a directory, which used the LOAD command (as described earlier) rather than a dedicated command. In my opinion, it is accurate to describe loading a special file in order to retrieve a directory listing as a trick.
Looking at the Apple II and Commodore 64, I think it is fair to say that while the BASIC environments supported varying degrees of disk command they were quite different from what we think of as command interpreters. With Unix shells, anything you can enter into a shell script can be executed from the command line, and vice versa. If memory serves me correctly, anything that could be done from the MS/PC-DOS command line could be done from a batch file (though I don't recall if the opposite is true).
That's .. pretty much how the home computers of the era worked? BASIC in ROM doubled as the shell on many (most?) systems. It's also how the file manager in the article works.
You only use line numbers in BASIC when typing in complete programs. If you type in commands interactively, the are without line numbers and executed immediately. How would you otherwise use commands like LIST to list the current program? BASIC only had one active program at a time.
So on BASIC machines with file systems you could list, load and store programs this way. Of course file systems only made sense once you had random access storage. Floppy disks were a lurury item in this space for a long time, and on tape you would manually position the tape before reading and writing. Most home computers at the time also didn't have the concept of folders, because storage was so small anyway, so file access wasn't that complicated.
There was sort of a conceptual firewall between "using the computer" and "programming the computer" for a lot of systems.
Some (various LISP and Smalltalk environments) had a much narrower wall between the two, but I could see the case for being able to say "Your secretary never has to know about programming" even if it left flexibility and value on the table.
Running your shell over top of the ROM BASIC? The reason nobody did this is because it would have cut your performance dramatically. ROM BASIC was always slow and usually quite cut down compared to something like GWBASIC. I do miss having the option to just boot into BASIC, but it was always more of a party trick than an practical mode of operation.
I missed the basic era by a little but I always wonder why the BASIC roms never became the shell of the disk operating system when disks entered the pictured. Think analogous to the unix shell which is both the interactive command line and a scripting language. Get rid of the line numbers, add some directory access commands (list, mkdir, cd etc) and you would have a pretty good cli. but nobody appears to have done this. Instead you ended up with things cp/m and dos. fine enough I guess but their command interpreter sort of sucks in comparison to what basic could have brought to the table. And basic was already there.
BASIC had been aggressively trimmed down to fit into an 8K ROM on the first machines, and there just wasn’t room for much more than crude SAVE and LOAD commands unless we gave up something else. Expanded “disk basic” variants came later, but these were all non-standard.
CP/M and DOS were indeed pretty weak, but this was a time where being first to market with a minimum viable app was everything, and then compatibility with what had already shipped first stalled progress.
They sort of did this with BASIC 4.0 and later for Commodores. We had CATALOG for listing files, SCRATCH for deleting them, HEADER for formatting and so forth. These were standard BASIC commands, and could be used in programs as well as directly.
Apple also did this with Apple II DOS and ProDOS. There was "cat", "catalog", "rename, "delete", etc. available from the BASIC prompt.
Yup, this basically what you booted into on a C64 for example.
No, that was BASIC 2.0, and using any DOS commands was extremely awkward.
With the notable exception of listing the directory, which was pretty easy through a trick from the disk drive’s DOS which meant you could load the disk directory “as a program” with a special name, “$”, and then just LIST it. But you see, the drive’s DOS had to sort of go out of its way to make that simple.
That's not a trick. It's just how you list files. Same awkwardness as any other disk command.
If I recall correctly, for Commodores, the equivalent of the disk operating system was handled by the drive itself. If you wanted to do anything beyond a LOAD or a SAVE, you were effectively opening the device then sending a command to the device. The exception was getting a directory, which used the LOAD command (as described earlier) rather than a dedicated command. In my opinion, it is accurate to describe loading a special file in order to retrieve a directory listing as a trick.
Looking at the Apple II and Commodore 64, I think it is fair to say that while the BASIC environments supported varying degrees of disk command they were quite different from what we think of as command interpreters. With Unix shells, anything you can enter into a shell script can be executed from the command line, and vice versa. If memory serves me correctly, anything that could be done from the MS/PC-DOS command line could be done from a batch file (though I don't recall if the opposite is true).
That's .. pretty much how the home computers of the era worked? BASIC in ROM doubled as the shell on many (most?) systems. It's also how the file manager in the article works.
You only use line numbers in BASIC when typing in complete programs. If you type in commands interactively, the are without line numbers and executed immediately. How would you otherwise use commands like LIST to list the current program? BASIC only had one active program at a time.
So on BASIC machines with file systems you could list, load and store programs this way. Of course file systems only made sense once you had random access storage. Floppy disks were a lurury item in this space for a long time, and on tape you would manually position the tape before reading and writing. Most home computers at the time also didn't have the concept of folders, because storage was so small anyway, so file access wasn't that complicated.
There was sort of a conceptual firewall between "using the computer" and "programming the computer" for a lot of systems.
Some (various LISP and Smalltalk environments) had a much narrower wall between the two, but I could see the case for being able to say "Your secretary never has to know about programming" even if it left flexibility and value on the table.
Running your shell over top of the ROM BASIC? The reason nobody did this is because it would have cut your performance dramatically. ROM BASIC was always slow and usually quite cut down compared to something like GWBASIC. I do miss having the option to just boot into BASIC, but it was always more of a party trick than an practical mode of operation.