Steve, Where would you fit the Tandy Model 100 in here? Ultimately it supported a disk drive, ran basic and also sported an expansion box that included video support and a floppy.
-Ken On Fri, May 3, 2024 at 4:18 AM Steve Lewis via cctalk <cctalk@classiccmp.org> wrote: > Great discussions about BASIC. I talked about the IBM 5110 flavor of > BASIC last year (such as its FORM keyboard for quickly making structured > input forms), and recently "re-learned" that it defaults to running with > double-precision. But if you use "RUNS" instead of "RUN" then the same > code is run using single-precision (but I haven't verified yet if that > translates into an actual runtime speed difference). I think most of the > "street BASICs" used single precision (if they supported floats at all). > But speaking of Microsoft BASIC, I think Monte Davidoff is still around > and deserves a lot of credit for doing the floating point library in the > initial Microsoft BASIC (but it's a bit sad that history has lost the names > of individual contributors > > But what I mostly wanted to mention is that on the Commander X16 project, > one special thing we now have in its System ROM is a program called > BASLOAD. Unfortunately we couldn't come up with a cooler name -- it's not > a native compiler, like Blitz. I'm not sure what you'd categorize BASLOAD > as, a pre-parser of sorts? By license, we were stuck with the Commodore V2 > BASIC (that was derived from Microsoft BASIC, with the story being that > Gates wasn't so interested in a 6502 port of Microsoft BASIC, and just sold > BASIC source code to Commodore for a flat one time fee rather than a > license). One of the main limitations of that V2 BASIC is the two-letter > variable names. > > BASLOAD gives you a feel of being similar to QuickBASIC - in that you can > do regular "BASIC things" without using line numbers. You can have long > variable names (like THE.SOLUTION) and you can use symbol labels in > GOTO/GOSUB (GOTO PROCESS.MORE.DATA, where "." is used since standard > PETSCII doesn't have an underscore). All BASLOAD does is "convert" your > BASIC-source text file into a tokenized Commodore V2 BASIC input file. > Your long variables get "auto assigned" into available two-letter BASIC > variables, and it just keeps track of the line number targets of your > symbolic labels. Stefan Jakonson did the actual development of BASLOAD, > including making it "ROM-able" so that it is always available. > > Anyhow, BASLOAD has been a "game changer" to me - in that it would have > been great to have something like it back in the 80's. Not being > constrained by the two-letter variable, and using symbolic label > difference, while not dealing with line numbers at all (plus things like > similar to a #include to import other BASLOAD source files). > > > Couple more BASIC related comments: > > (1) > There was talk regarding BASIC as an operating system. While not fancy, I > actually do think in a way it counts as an operating system. Fundamentally > as a parser, BASIC is "just" stream in an input, and some output is > produced when you RUN. But to get that point, you need a kind of > "operating environment" wrapper around BASIC. In the very early days, > that was the line printer. But then CRTs started to become affordable > around 1970. Adapting that capability with a text-generator and a console > - you have things like the blinking cursor (between each blink, things like > time/clock interrupts, joystick polling), and the text-screen itself is > your editor (as a gateway to manipulate your program, one screen at a time > with no scrollback buffer). And similar to the line-printer days, when > you press CR (carriage return) the content on the current line is tokenized > and stored in memory (sort of - again on the IBM 5100 it will parse-check > upfront and won't let you ENTER/CR a syntactically invalid BASIC line; it > shows this arrow on what column the error is which has to be corrected > before the line can be committed into memory -- most "street BASIC" seem > more forgiving about that, probably just to conserve ROM space and fit in > under 8KB). And the BASIC manages access to hardware like printer, serial > port, and some file handles. > > > (2) > Microsoft BASIC appears on the 1979 NEC PC-8001, which includes disk drive > support (similar to the later additions to Commodore BASIC also around > 1980). But in the NEC PC-8001 manual about BASIC, it refers to a "FAT" > format used on disks. So I suspect Microsoft's early work in adding disk > drive support into BASIC did help them in maintaining that format when > packaging up QDOS later. > > > > > > > > > > > On Thu, May 2, 2024 at 10:38 PM CAREY SCHUG via cctalk < > cctalk@classiccmp.org> wrote: > > > compiled basics too longer to run and debug because of the compile time. > > > > Anything I did was limited to floppy disk, or later even hard disk speed, > > the greater speed from compiling could not be noticed. > > > > <pre>--Carey</pre> > > > > > On 05/02/2024 9:51 PM CDT Just Kant via cctalk <cctalk@classiccmp.org> > > wrote: > > > > > > > > > BASICs available at bootup were nice, but really were only useful with > 8 > > bit micros. IBM ROM BASIC was hobbled until you ran BASICA from disk. And > > if you had a floppy it only made sense to buy a cheap compiler (Quick > > Basic, Turbo Basic, etc.). Whatever you were missing by not dropping > 4-500$ > > for a full product probably wasn't worth the expense. > > > > > > ROM BASICs outlived their usefulness very quickly. Compiled Basic was > > an entrance into real world development. It wasn't a tool you could do > > everything with. But how many programmers sitting at home were creating > > apps that were even 64k in size. Compiled Basic was the schnitzel. There > > are also several 32/64 bit versions available for free. Carry on. > > > -- End of line JOB TERMINATED
