• Please review our updated Terms and Rules here

Testimonies of using BASIC back in the day

"BASIC, FORTRAN, S-ALGOL, and PASCAL Benchmarks on microcomputers including the effects of floating point processor support" was published by Marcus Wigan in August of 1982 as mentioned earlier in this thread in a post by krebizfan:

Testimonies-of-using-BASIC-back-in-the-day post #39

Table 7 starting on page 14 showed results from running INTERFACE AGE benchmark BM9 using BASIC or BASIC compilers on a variety of microcomputers, and minicomputers.

I ran this benchmark on my Tektronix 4054A last night and got 310 seconds which put it in 12th place as my retyped table below shows.

...


Here is my updated table including a run made yesterday on a Tektronix 4051 with an 800KHz Motorola 6800 CPU, 8.2X slower than my Tektronix 4054A bit-slice CPU architecture with microcode floating point instructions.

The Tektronix 4054A microcomputer running BM9 with BASIC had the same performance as the Seattle Computer 8MHz 8086 system running MS BASIC and the terak 8510a LSI-11 running compiled BASIC.

The Seattle Computer 8MHz 8086 system running Compiled MS BASIC was 9x faster.
I guess I need to compile the program on my Tektronix 4054A - I suspect I should get much closer to the compiled MS BASIC performance on the Seattle Computer 8086 system.

CDC CYBER171.NOS 1.4BASIC5
IBM 3033.VS2-10RVYLStanford BASIC10
PRIME300.PRIMOSBASIC25
Seattle System 280868MS-DOSMsB(compiled)33
DECPDP11/70.kSTS/EBASIC45
PRIMEJul-01.PRIMOSBASIC V16.463
DECPDP10.TOPS-10BASIC65
IBM S/34.R-05BASIC129
Digital MicrosystemsHEX-296HOSTHBASIC_143
HP3000..BASIC250
4MHz Z80AZ804CP/M 2.2MsB(compiled)5.03277
Tektronix 4054AAMD290125.Tek 4050A ROM BASIC310
terak 8510a LSI-11CP1600.UCSD 1.5BASIC 1.5 Compiler310
Seattle System 280868MS-DOSBASIC310
Alpha Micro AM100TWWD163AMOS 4.3AAlphaBASIC317
Apple II+65022DOS 3.3Microsoft TASC325
DECPDP11/45..BASIC330
Apple II+65022DOS 3.3Expediter II compiler335
Data GeneralNOVA3.TimeshareBASIC 5.32517
BBC Micro6502.BBC BASICBBC Integer Basic523
SWTPC6800.Software DynCompiler B 1.2528
Alpha Micro AM100WD162AMOS 4.3AAlphaBASIC573
Technico SS-1699003DOSSuperBASIC3585
terak 8510a LSI-11CP1600.RT11 V0.38k BASIC596
BBC Micro65022BBC BASICBBC F/POINT BASIC596
Ohio C4-P65022OS65D 3.2Level I BASIC680
North Star FPZ804MS-DOSMS BASIC685
terak 8510a LSI-11CP1600.RT11 V0.3MUBASIC703
Apple II+65022DOSInteger BASIC722
ADDS Multivision80855NUONMBASIC 5.2877
4MHz Z80AZ804CP/M 2.2MBASIC 4.5.1966
Apple II+65022DOS 3.3APPLESOFT II970
Rexon RX3080865RECAPBusiness BASIC1020
CromemcoZ804CDOSExtended BASIC1196
North StarZ804NS-DOSNS BASIC1149
Processor Tech Sol-20..SolosAltair BASIC 8k1231
Exidy SorcererZ804.Microsoft BASIC1260
ISC Compucolor CC-II8080..BASIC1267
Apple II+65022CP/M 2GBASIC1284
Ohio C3-C65021OS65DLevel I BASIC1346
Commodore PET 20016502..Microsoft BASIC1374
ISC Compucolor 80518080.DOSBASIC 80011375
Hewlett-Packard HP85NMOS..BASIC1380
Basic/Four 6008080..BASIC1404
Micro V Microstar 180853StarDOSStarDOS BASIC1438
SinclairZ802.5.4k BASIC1514
Processor Tech Sol-20..SolosPT Extended BASIC1812
Heath H89Z80..Microsoft 4.7 BASIC1850
Zilog MCZ-1/70Z802RIOZilog BASIC1863
Tandy TRS Model 1Z802TRSDOSLevel II BASIC1929
IBM 5120...BASIC1956
4MHz Z80Z804CP/M 2.2CB80 v1.31988
4MHz Z80Z804CP/M 2.2BASIC-E(M9511 4M)2208
Vector MZZ80.MDOSMicropolis 8.5 BASIC2261
Digicomp P100-Z80Z803CP/M 2.2BASIC-E(M9511 4M)2322
Cromemco CS3Z804CDOSCBASIC-22245
Texas Instruments99/49900..TI BASIC2479
Tektronix 405168000.8.Tek 4050 ROM BASIC2535
Ortex MicroengineCP16002UCSD.H1BASIC 1.13017
4MHz Z80AZ804CP/M 2.2CBASIC v2.063100
Zenith H89Z80..Benton Harbor BASIC3550
Pocket TRS-802x4CMOS..BASIC55830
[tr]
 
Last edited:
My story is a bit of a strange one. While I started programming BASIC in 1981 on Commodore Pets, I did get a job programming BASIC in the late 90's. It was software for casinos to track and manage slot machines. The software was written in HP-BASIC and ran on AIX servers. And there was some spaghetti code in there for sure. One example was for loops, three deep, and right in the middle was a subroutine and a goto to jump over it. :) I even found some dead code that I was able to remove and refactor. The code base had been started in the late 70s and was still in use.

Jason
 
When I started my first system administrator gig back in '95 the plastics thermoforming company where I was hired had a 10K line GWBASIC program that estimated costs for new forming jobs. The software was written by the owners son and I was not allowed to touch it (nor did I want to, not enough sauce for that spaghetti). It was actually an amazing piece of software that calculated everything from tooling to die and forming. When I left in 2000 they were still using it (probably are to this day).

The full company accounting package was also custom written in GWBASIC which I did end up rewriting in a combination of QuickBASIC 4.5, Visual Basic for DOS 1.0 using ISAM database, and Visual Basic for Windows. BASIC allowed me to write software quickly. They used my software until the mid 2000's when they switched over to a PeachTree accounting solution (the sysadmin that took over for me used to work for PeachTree, so makes sense).

Sure I could have used Pascal or C but compiled BASIC was plenty fast enough. Also, revisiting your BASIC code months, or even years, later for revisions was much easier as well.

In fact, I still enjoy writing code in BASIC to this day in a modern 64bit version of QuickBASIC called QB64 ( www.qb64.org ).
 
I used BASIC on a TRS-80 Color Computer II . BASIC had a form of inline assembly, with those DATA statements and POKING those values into RAM. As I recall, the smallest BASIC interpreter was maybe 2K - allowing it to fit nicely within a ROM, which was probably why it ever became so popular. Later BASICs were larger, but "in the beginning" (circa 1977) recall the base prices of new PCs was for like 4K to 16K RAM systems. Those machines were like glorified digital calculators (with much larger screens) - turn it on, compute a few things, turn it off.

Then they got more elaborate with the tape drives, which were like 50 to 300 characters per second load times. I saved a lot of programs on tape, marking the index number on the labels ("30-38 circle program" "50-65 ball bounce program" etc). Those index numbers weren't always reliable (such as when the tape drive started wearing out, or swapping between tape drives). The old Dungeons of Daggorath game is the oldest thing I can remember that let you save your game to tape (ZSAVE, and you could name your "file", like "ZSAVE LEVEL1"). There are probably earlier programs, but much of the actual mechanism to do the saving of data was available in the ROM of the system (that's how Daggorath did relatively so much for just being a 16KB game - lots of capability delegated to the "BIOS" in ROM).

If you had to spend like 5 minutes loading a (C, Pascal, Fortran) compiler from a tape, then where do you store your program that is to be compiled? I never had such a compiler (in the early days), so I'm not entirely sure of the sequence (maybe they could compile and run from an in-memory buffer). But I imagine, once you compiled it, it had to saved somewhere, then clear the compiler out of memory, load your program, try it out, etc. That'd be way too tedious for most home consumers, and raw assembly itself would have a similar workflow - the assembly has to assembled (into where, memory? a "file", when you had no disk drive?) Then load the assembled result and run that, and repeat? Some intermediate solution was needed, and BASIC filled that need.


Yes, disk drives were available, but still relatively expensive and not so reliable (like don't dare open the drive door while disk is spinning, don't power up while disk are inserted - those late 70s disk systems each had their own quirks {"flip disk to continue"} and gotchas, and various formats - plus, as mentioned, expensive). So BASIC was also "successful" due to that lack of disk drives in the very early days, and that it could fit in a ROM. I suppose any "serious developer" in those days would have a disk drive - anyone who wanted to craft a program for other people to use.


I can't remember when last used BASIC - maybe 1986, where yes then I got introduced to Turbo Pascal (and finally had some disk drives available on an early IBM PC).


Floating Point handling: floating point is pretty hard to implement and consumes a lot of code. Remember code-size itself competes with your available RAM space, since the program has to be loaded into RAM in order to be executed (something we tend to take for granted these days - a lot of my 64-bit compiled modern programs are like 30-40 *megabytes*, which is just all the linked together resulting code, and all that has to get loaded across the bus and into RAM, just like back in those days). VisiCalc as an example: if it takes 27KB to load, that leaves only about 5K to enter data (on a 32K system). Anyway, Apple INTEGER BASIC ROM didn't have floating point support. Implementing your own cost a lot of code space. In Commodore world, they got Microsoft's BASIC that had floating point support (story on how that came about is interesting to me, Bill hired help on that "math package"; but independently I found an old paper co-authored by Woz in implementing floating point -- published before he released INTEGER BASIC -- so he could have prepared his own "math package", but probably just ran out of time relative to everything else going on in the race to market {plus a "game machine" then didn't have much need for floating point, when drawing on fixed grid of pixels}). Anyway, point is, if a program did need floating point, they could save code-space by jumping directly into the BASIC ROM code that already implemented floating point (rather than wasting their own code space to duplicate that functionality). That's not exactly a trivial thing (prepping zeropage and contriving BASIC to invoke that portion of the interpreter), but certainly possible.


Disk drives certainly made life so much easier. Schools had to save money and couldn't buy lots of disk drives - so lots of the inexpensive machines with built in BASIC were in schools, maybe as late as about 1986. Just turn them on and start coding some stuff. BASIC served a good niche purpose for its day, helping to save cost by allowing a small ROM substitute the need for an expensive disk system - allowing the machine to be immediately useful by a wider population. As disks became more affordable, available, and reliable (over the next decade), there was less need for BASIC.

But think it's interesting that the idea of an interpreted language is semi-useful. For astro-image processing I use PixInsight, and I think it is one of the best examples of merging the best of compiled code and then using interpreted JavaScript. The main GUI portion of the application is in C++/QT, but many of the image processing modules are in JavaScript - so the user community can help refine those scripts to improve the "business logic" of multi-channel image processing, without having to have all the overhead of compiler tools and build times.
 
Last edited:
Back
Top