Summer of '85: DOSBOS is rejected by ANALOG Computing

https://www.goto10retro.com/p/summer-of-85-dosbos-is-rejected-by

by ibobev • 2 months ago

59 19 2 months ago

somat• 2 months 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.

michalpleban• 2 months 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.

steve19772• 2 months ago

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

icedchai• 2 months ago

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

hakfoo• 2 months 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.

jandrese• 2 months 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.

xorcist• 2 months 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.

joblessjunkie• 2 months 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• 2 months 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.

fsckboy• 2 months 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.

tom_• 2 months 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.

ralferoo• 2 months 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].

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

Summer of '85: DOSBOS is rejected by ANALOG Computing

Related Stories