3 条评论
- somat 3天前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.
- ralferoo 16小时前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].
[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...
- Innittech 1天前[dead]
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.