Rendered at 23:48:06 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
somat 4 days ago [-]
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 1 days ago [-]
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 1 days ago [-]
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 1 days ago [-]
Apple also did this with Apple II DOS and ProDOS. There was "cat", "catalog", "rename, "delete", etc. available from the BASIC prompt.
steve1977 1 days ago [-]
Yup, this basically what you booted into on a C64 for example.
anyfoo 1 days ago [-]
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.
Innittech 1 days ago [-]
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.
kid64 1 days ago [-]
That's not a trick. It's just how you list files. Same awkwardness as any other disk command.
anyfoo 1 hours ago [-]
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.
II2II 1 days ago [-]
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).
unnah 15 hours ago [-]
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.
hakfoo 1 days ago [-]
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 1 days ago [-]
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 21 hours ago [-]
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.
tom_ 21 hours ago [-]
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.
jandrese 1 days ago [-]
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.
fsckboy 21 hours ago [-]
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.
ralferoo 14 hours ago [-]
Another failed submission story here...
At some point Amstrad Action, probably around 1987 or 1988, printed a type-in that was able to load standard ZX Spectrum tape files, basically a simple port of the LD-BYTES routine [1]. (EDIT: thinking about it, the loader was probably published earlier, maybe 1985 or 1986, but I only found a use for it later when I found a friend with a Spectrum).
I was inspired by this as I had an Amstrad CPC and my friend had a Spectrum, and wanted to make a dual-format game with an Amstrad loader at the beginning with CPC specific stuff that loaded the Spectrum game and provided a different API via a jumpblock.
Of course, not wanting to have to use a Spectrum to write these files, I decided I needed to figure out how this Spectrum loader worked, so I disassembled it, borrowed the Spectrum ROM disassembly from the library [2] and figured out what they'd done to convert it. At that time, I had limited understanding of the CPC's handling of WAIT (which completely messed up my understanding of how T-states were different between ZX and CPC), but managed by sheer luck to get good enough timing in my port that it worked well and both Spectrum and Amstrad could read my tapes.
We got bored of writing the actual game shortly after, but I submitted my ZX saver as a type-in listing to the magazine, who replied back saying they didn't want to publish it.
As a coda to this story, a year or so later I sold the CPC to fund my purchase of an Amiga, and never touched a CPC again until 25 years later when I bought one on ebay. I never lost the love of tape loaders though, and later in 2014 wrote the demo "Breaking Baud" [3] which had all sorts of crazy features like realtime decompression whilst reading from tape, so had a nominal speed of 2688 baud, but in practice could read data much faster depending on compressibility - in the demo every time something is drawn over the top, it's actually reading an entire new screen of data but compressed using RLE and deltas to the previous contents. Lots of technical detail here in the readme [4].
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.
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.
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.
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).
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.
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.
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.
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.
MS-DOS was written to do what CP/M did.
At some point Amstrad Action, probably around 1987 or 1988, printed a type-in that was able to load standard ZX Spectrum tape files, basically a simple port of the LD-BYTES routine [1]. (EDIT: thinking about it, the loader was probably published earlier, maybe 1985 or 1986, but I only found a use for it later when I found a friend with a Spectrum).
I was inspired by this as I had an Amstrad CPC and my friend had a Spectrum, and wanted to make a dual-format game with an Amstrad loader at the beginning with CPC specific stuff that loaded the Spectrum game and provided a different API via a jumpblock.
Of course, not wanting to have to use a Spectrum to write these files, I decided I needed to figure out how this Spectrum loader worked, so I disassembled it, borrowed the Spectrum ROM disassembly from the library [2] and figured out what they'd done to convert it. At that time, I had limited understanding of the CPC's handling of WAIT (which completely messed up my understanding of how T-states were different between ZX and CPC), but managed by sheer luck to get good enough timing in my port that it worked well and both Spectrum and Amstrad could read my tapes.
We got bored of writing the actual game shortly after, but I submitted my ZX saver as a type-in listing to the magazine, who replied back saying they didn't want to publish it.
As a coda to this story, a year or so later I sold the CPC to fund my purchase of an Amiga, and never touched a CPC again until 25 years later when I bought one on ebay. I never lost the love of tape loaders though, and later in 2014 wrote the demo "Breaking Baud" [3] which had all sorts of crazy features like realtime decompression whilst reading from tape, so had a nominal speed of 2688 baud, but in practice could read data much faster depending on compressibility - in the demo every time something is drawn over the top, it's actually reading an entire new screen of data but compressed using RLE and deltas to the previous contents. Lots of technical detail here in the readme [4].
[1] Starting here https://github.com/ZXSpectrumVault/rom-disassemblies/blob/38...
[2] Page 15 (20 in the PDF) onwards from https://k1.spdns.de/Vintage/Sinclair/82/Sinclair%20ZX%20Spec...
[3] https://www.youtube.com/watch?v=D62jpqZ6TG4
[4] https://github.com/ralferoo/breaking-baud/blob/master/docs/t...