[somat]

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.

[xorcist]

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.

[michalpleban]

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.

[icedchai]

Apple also did this with Apple II DOS and ProDOS. There was "cat", "catalog", "rename, "delete", etc. available from the BASIC prompt.

[steve1977]

Yup, this basically what you booted into on a C64 for example.

[anyfoo]

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.

[kid64]

That's not a trick. It's just how you list files. Same awkwardness as any other disk command.

[II2II]

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).

[anyfoo]

I did not mean it’s a trick users applied, I meant that the developers of the 1541 DOS implemented this very trick. You load a textual representation of the directory into memory as a BAISC program, that’s pretty funky.

And it was precisely done because the straightforward way, which would have been something like opening a sequential channel with a dedicated directory listing command and reading out from it, would have been immensely awkward under BASIC 2.0. Hence the magic “$” program.

[unnah]

It leads to the catch-22 that when saving a BASIC program you cannot tell which filenames are already in use, since you cannot get a directory listing without losing the current BASIC program in memory. All you can do is guess a filename that is probably free.

[Innittech]

Yes that was how it worked due to the limitations of the C64 but also the old BASIC that they were using. If you actually used your C64 as a "power user" you'd probably have ponied up for JiffyDOS which in addition to making the disks like 10x faster, had some QoL features like being able to list the disk contents without blowing away the low line numbers in BASIC. It was also extremely easy and common to make your own wedge (a new BASIC command). If you weren't going to use something like the tape drive for instance, you could even have it (or parts thereof) live in the memory where the tape would normally be. JiffyDOS does this, you can't use the tape drive with it at all.

[steve1977]

Good point actually, thx.

[hakfoo]

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.

[joblessjunkie]

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.

[trollbridge]

ROM BASIC on the IBM PC was humongous for its time (32KB). The ROM BIOS itself was only 8KB.

Considering DOS 1.0 was under 12KB, it would have probably been useful if they'd put disk I/O routines in the ROM... except it would have been rapidly obsolete since DOS 1.1 already had a different disk format (for double sided disks), and then DOS 2.0 changed it again (9 sectors per track instead of 8, and subdirectories).

Note that the BASIC interpreters on those early machines mostly used the ROM. The disk BASIC interpreter was only 10K (and an "advanced" version was 16K), so you could run DOS and BASIC with the ability to save files to disk on a machine with 32K of memory. Not that anyone back then ever bothered to do this, but RAM seemed expensive when they designed it in 1980.

DOS in ROM was an idea that kept being tried but never really caught on, even though with the right design it would make for a significantly faster system.

[jandrese]

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.

[tom_]

Depends on the system. Each thing did its own thing at the time.

8-bit Acorn systems did work kind of roughly as you describe. Handwaving a bit: there was no shell, but there was an OS call roughly corresponding to system(3), and add-on ROMs (e.g., the driver-type ROM that came with the disk interface) could extend the default (fairly limited) set of available commands.

With no shell, there was no standard UI for typing in a command and having it run, but this OS call was one of the main ways to interact with the OS, so the inbuilt BASIC made it very easy to do. For a lot of the stuff you'd use the DOS prompt for in MS-DOS, you'd do the equivalent from the BASIC prompt on the Acorn systems. In place of batch files, there were a couple of options, and one of them was that you'd write a BASIC program that contained the commands you wanted executed, in order.

[fsckboy]

CP/M was written to do what DEC's minicomputers did with PIP, the peripheral interchange program was designed to create a way for programs to interact with devices (printers, console, modem, etc.) in a generalized generic way. BASIC didn't do anything like that, it was designed to create the BASIC virtual machine and in order to do I?O you would need to know what type of device you were talking to and follow its control language, exactly what CP/M was trying to eliminate. The people sharing Digital minicomputers would be attracted to running on a microcomputer all to themselves, but the software they would want to bring was not written in BASIC.

MS-DOS was written to do what CP/M did.