Testimonies of using BASIC back in the day

[krebizfan]

The exact opposite of almost all the code I dealt with; in the business world floating point was generally slower and less accurate because it tended to introduce rounding errors.

Alas, electron orbits do not lend themselves to easy decimal notations.

 

[MikeS]

Alas, electron orbits do not lend themselves to easy decimal notations.

Indeed; just pointing out that what's fast and accurate in your realm (science, games etc.) is slow and not necessarily accurate either in the (often ignored here) business realm.

...which is one of the reasons why spreadsheets initially implement decimal floating-point math--and why CBASIC did, for example.

'Precision as Displayed' is set by default in all my Excel sheets; it's disconcerting when 'IF A1=2' fails, or when FoxPro says that 1 + 1 = 1 for that matter...

 

[GeoffB17]

Surely that can be a problem with ANY computer language.

Over the years, I've had problems with various, including the C7 I've done most of my 'serious' work with. Where such things mattered, I always took the precaution of using a special rounding function on both sides of the comparison to make sure that if the two numbers were the same, then the computer recognised them as such. If I didn't, there was always a possibility that one number or the other might still have a stray (VERY 'stray') 0.000000000001 or such-like hanging in there!

Geoff

 

[Chuck(G)]

Note by "decimal", I don't necessarily mean that a number is expressed in, say, BCD, although that would make for convenience.

Simply maintaining the exponent as a power of 10 rather than 2 (or 16, as in S/360 floating point) is sufficient. While most have heard of IEEE 754 floating point, few are familiar with IEEE 854. At any rate, interest in decimal radix is very much alive. Somewhere, even recall reading about a decimal coprocessor done in FPGA.

Students studying numerical methods are often given a problem that involves trig functions near their limits usually expressed as a quotient. The naive learner simply codes the expression as stated and discovers that the result is pure garbage. It's an object lesson in not blindly trusting the computer to come up with the "right" answer.

 

[MikeS]

What Chuck said.

Quoting from his link:

"Most computers today support binary floating-point in hardware. While suitable for many purposes, binary floating-point arithmetic should not be used for financial, commercial, and user-centric applications or web services because the decimal data used in these applications cannot be represented exactly using binary floating-point".

As someone who spent 40 years or so with systems and software for the accounting and financial services markets, that's a truth I learned very early on... ;-)

 

[Chuck(G)]

I'm trying to remember an article from the HP Journal from years back. As best as I can recall, it was a way of doing decimal floating point by expressing the mantissa in groups of 20(?) bits, each group having the range from 0-999999 in binary, or something to that effect. The benefit was that you could get 6 digits of significance, where doing the same as BCD would only get you 5. Does anyone remember the article?

 

[Scali]

Students studying numerical methods are often given a problem that involves trig functions near their limits usually expressed as a quotient. The naive learner simply codes the expression as stated and discovers that the result is pure garbage. It's an object lesson in not blindly trusting the computer to come up with the "right" answer.

That reminds me of an issue that many raytracers have:
If you calculate the intersection of a ray and some surface (sphere, plane, cylinder, etc), then the intersection point is never exactly *on* the surface of course, due to the limited precision.
So your intersection point is either in front or behind the surface, depending on which way the rounding turned out.

Now, if you don't take this into account, and then proceed to reflect the ray at the intersection point, you will often find that your rendered surface will have 'holes': random black pixels.
Why? Simple: when you reflect your ray, you implicitly assume that it is bounced against the surface, so it should be on the 'outside'. But if due to rounding your intersection point was actually on the 'inside' of the surface, then the reflected ray will bounce back to the surface again, and the light may get 'trapped' inside the object for the remaining 'bounces' to be calculated. That's why you'll get those random black pixels.

Some implementations just leave it at that... Others try to use bruteforce to 'fix' it: Either they increase the supersampling to a level where the black pixels will 'blend in' with the correct neighbours, so the issue is not apparent. Or, they just use double precision floating point everywhere (or worse, if the FPU supports it). Neither gives correct results.

Smart coders can get it working fine without any supersampling, and just single precision. You can use one of these elegant solutions:
1) When you calculate the intersection point, step back along the ray by a certain epsilon value. With a well-chosen epsilon, the intersection point is now always on the correct side of the surface, you never 'overshoot' inside the object.
2) Keep track of what object your ray last bounced from. If it is the same object as the nearest intersection at the current bounce, then it is suspect. In that case, if the length of the ray (distance between the previous and current intersection point) is shorter than a given epsilon, discard this nearest intersection and take the next-nearest one instead, because you have likely bounced against the same surface again.

 

[RobertLM78]

It's been mentioned a few times, but I discovered FreeBASIC a couple years ago. Sweet language there - and compiled too. It is far from a toy and probably the most capable modern dialect of BASIC I've come across.

 

[GeoffB17]

Yes, FreeBasic.

A massive project. Very interesting.

The base of the system is the old MS QuickBasic, and at one level, the language follows the syntax of QB. You can use the system as supplied as a console (command prompt) system just like QB.

But, there are a PILE of libraries included, all based around gcc (i.e. 'C') which underlies the compilation process, that can be easily invoked. Plus, you can operate as windows, generating full windows applications.

I've used the system to create a couple of small windows utilities, using my own simple code plus some windows features (like a full windows looking file-list browse/open process), also done a number of progs to provide access to MySQL databases (can do same for SQL if required) - these latter staying as console mode.

Fair number of demo progs to follow/copy/tweak. Compile/link options set to run from Batch file, great list of options, many of which I do NOT understand, so I've used just a few, but it worked fine, pretty much as installed 'out-of-the-box' (which nowadays should be 'as-downloaded').

Geoff

 

[RobertLM78]

Yes, FreeBasic.

A massive project. Very interesting.

The base of the system is the old MS QuickBasic, and at one level, the language follows the syntax of QB. You can use the system as supplied as a console (command prompt) system just like QB.

Geoff

I would add that coding FreeBASIC in a QB fashion (like using the -lang qb option) doesn't take advantage of the language's full ability. It's better off to just adapt your existing QB code to a more FreeBASIC style.

 

[CameronB]

My first language in college was FORTRAN using punch card decks in batch mode. Junior year (1972) I passed a room full of teletypes in the ME building. They were open for use, no login or account required. It turned out to be a BASIC time sharing system running on a PDP-8. After that I spent a lot of time there including some skipped economics classes. The only way to save and reload programs was the paper tape punch/reader on the teletypes. One of the programs (not written by me) would punch text onto paper tape. I had tried something similar with asterisk graphics in FORTRAN but the system operators didn't give me the printout and wrote NO! on my deck. That's one reason I appreciated the Basic system, the other being it was interactive and not batch mode.

In 1977 I worked on an automated test system for a guided missile. It used a lot of HP test equipment connected by HPIB to an HP minicomputer. The test code was Basic. I represented the missile electronics not the test system but I did have to read the code for individual test steps.

After that I used Basic on various microcomputers at home and a tiny bit at work. Most of my professional coding was in assembly language and C.

 

[CP/M User]

I grew up using Locomotive BASIC 1.0 on an Amstrad CPC464, though now days I have an Amstrad CPC6128 with Locomotive BASIC 1.1 though I regularly code in LB1.0 to have it running on all the CPC systems.

For me personally originally it was about going to the Newsagents, purchasing some Magazines each month and type-in the programmes, I tried creating my own odd programme back then, though there were gaps and would based some of the code from other people's work, I particularly know that I didn't have much understanding on Array's, which looked more like a Mathematical problem.

These days I look at it a bit differently, for example I might look at some game coded in BASIC and think how would it look if it were like this or this and improve the coding of it. A couple of years ago I had some old 10-Liner riddled with issues, which I dissected with notes running through what it did. Some of the underlining issues were still present until I started focusing on having a Main Loop with some Structured programming put into play. By the end I had something which hardly looked like a 10-Liner, but was able to expose where there were flaws in the original code and fix them which is where I get a great deal of satisfaction.

But I have to be somewhat thankful that Pascal exists, by setting rules up for Structured Programming has helped me improve in BASIC, though BASIC seems to have tricks of it's own. BASIC can have a structured look to it which makes for easy reading, though with some clever coding skills it almost seems there's a whole other level in LB which I haven't progressed to and reading the source code to that seems like reading gibberish.

It's difficult to say where I draw the Line with GOTO because if misused, the programme becomes hard to read, this Dragon Curve example on Rosetta Code for the ZX Spectrum presents an unusually complex Loop to determine the Path of the Line. Eventually I had something up and running in Pascal, though for that BASIC example, it had a clever way of freeing up memory which I couldn't produce in Pascal unless, I could exit the Procedure, which I did by forcing an end of a Loop and then call the whole routine again with another Colour.

 

[nikola-wan]

Tangentially related, some months ago I started a benchmarking project for 8-bit home micro BASIC systems, calculating prime numbers by trial division (the goal was not to have an efficient way of finding prime numbers, but to have some consistent unit of work that could be expressed simply and therefore be implementable regardless of limitations in any particular system's BASIC).

At some point I thought I'd try my hand at an APL version to compare the speeds of BASIC and APL in my IBM 5100, and the project started spiraling out of control from there.

ZBasic, Dartmouth True BASIC (on the Macintosh), various Microsoft BASICs, even Atari 2600 BASIC are all represented (that last one was a challenging port).

It's pretty clear to see that Microsoft BASICs were all pretty slow, that Woz's Integer BASIC is pretty tidy, and Acorn's BBC BASIC is a masterwork.

I still have a few more language ports up my sleeves in various unfinished stages, a structural mistake in the DRI Personal BASIC version (which has also snuck into a couple other ports) that causes it to do more work after finding the last prime, which I need to correct both in the source and the published results, and a long list of results to gather using software and hardware I've already collected with ports I've already written.

Mostly the micro results are in the bottom half.

http://www.typewritten.org/Articles/Benchmarks/primes.html

bear,

Thanks for your benchmark.

I ported the Commodore 64 program to my early 1980's Tektronix 4054A computer and got 21.27 seconds for n=100 last night:

Benchmark PRIMES
Start: 04-JAN-20 09:47:03.97 PM
End:             09:47:27.11 PM
Benchmark PRIMES (secs)= 21.27
END

The Tektronix 4052A and 4054A computers were the last generation of a series started in 1975 with the 4051 using a 6800 CPU running at 833KHz. http://w140.com/tekwiki/wiki/4051
These computers were designed for scientific and engineering markets with remarkable graphics resolution of 1024x780 on the 4051 in 1975 based on Tektronix storage tube technology using vectors.
The 4051 entry price was $5995 with 32KB of BASIC ROM and 8KB of DRAM. Memory could be upgraded to a max of 32KB of DRAM.

The 4052 and 4054 were introduced in the late '70's to support demand for higher performance, and were a custom AMD 2901 bit-slice design with a 16-bit data bus, 128KB of total memory, with over 64KB of BASIC ROM and up to 64KB of DRAM. This architecture also provided 6800 8-bit instructions with new opcodes including micro-coded floating point instructions.

These hardware floating point instructions showed great performance (for the '80s) in the prime results above.

The 4052 and 4054 bit-slice microcoded CPU clock rate was 25MHz.

The 4052 had the same 12" Tektronix flat storage CRT and resolution as the 4051.
The 4054 and 4054A had a Tektronix 19" storage tube like the Tektronix 4114 terminal with 4096x3072 resolution! Still state of the art today :D

The 4052A and 4054A were introduced in the early 1980's, and the series was discontinued in the late 1980's.
The A-series added structured BASIC commands and other firmware enhancements including an assembly language CALL "EXEC", along with an assembler and documentation for the microcode instruction set and BASIC ROM entry points.

Here is my port of your prime program in Tektronix 4050 BASIC.
I have a Transera Real Time Clock ROMPACK plugged into the 4054A that provided the timing in HH,MM,SS,and hundredths of a second in a single CALL "!TIME" with numeric output parameters.

Tek BASIC arrays do not support a ZERO index, so I adjusted the program accordingly.
Also I created this one after typing in the nine BM benchmarks, which I will show results in a separate post. I changed the A variable to X in your prime program.
The output for the benchmark timing used separate 4800 baud serial printout to a laptop computer.

The serial port is accessed with the PRINT @40: statements. These Tektronix computers had optional serial interfaces and embedded GPIB interfaces. The @#: syntax allowed PRINT, READ, WRITE and byte commands to be addressed to any GPIB device or serial device.

I printed each computed prime to the screen during the benchmark - to match the other computers.

The formatted start/end printing and serial printing is outside the benchmark time measurement, which is why the total start/end time is slightly longer than the run.

1 GOSUB 900
2 CALL "!TIME",A0,B0,C0,D0
3 GO TO 10
5 X=X+1
6 GO TO 50
10 DIM P(100)
15 P=0
20 P(1)=2
25 PRINT P(1)
30 X=3
40 FOR F=2 TO 100
50 FOR I=1 TO F-1
60 V=X/P(I)
65 IF V=INT(V) THEN 5
70 NEXT I
80 PRINT X;
90 P(F)=X
100 X=X+1
110 NEXT F
120 CALL "!TIME",A1,B1,C1,D1
130 GO TO 1010
900 REM    PRIMES
910 C$="PRIMES"
920 CALL "!DATETIME",A$
930 PRINT "Benchmark ";C$;"Start: ";A$
940 PRINT @40:"Benchmark ";C$
950 PRINT @40:"Start: ";A$
960 RETURN 
1010 CALL "!TIME",B$
1020 PRINT "End:             ";B$
1030 PRINT @40:"End:             ";B$
1040 S0=A0*3600+B0*60+C0+D0/100
1050 S1=A1*3600+B1*60+C1+D1/100
1060 S=S1-S0
1070 PRINT "Benchmark ";C$;"(secs)= ";S
1080 PRINT @40:"Benchmark ";C$;" (secs)= ";S
1090 PRINT "END"
1100 PRINT @40:"END"
1110 END 
1120 RETURN

 

[nikola-wan]

I forgot to mention, Tektronix 4050 BASIC had no integer variables, all numeric variables were 14 digit floating point +/-8.998E+/-307 (8 bytes plus variable name overhead).

The 4054A/4054A ALU board used a multiplexed 16-bit address/data bus and extended the 6800 limited register space to sixteen 16-bit registers, which could hold two floating point numbers to speed up the floating point.

The 'A' and 'B' registers were also extended to take advantage of 16-bit addressing and data operations.

Here is a 4052/4054 ALU block diagram from the Tekscope 1979 Vol 11 No 3 magazine:

 

[nikola-wan]

Tektronix 4051 computer was my first 'personal' computer in my first job after college in the mid 1970's.

I loved the instant access of Tektronix 4050 BASIC a couple of seconds after powering on the computer, and I wrote dozens of programs - for work and for play in the late 1970's, and had the foresight to keep hard copies of all my programs.

I also made extensive use of the 4050 BASIC graphics, plus the I/O addressing capability, which provided access not only to the internal DC300 tape storage, but also the GPIB access to the 4907 external floppy drive system and a large rear-projected digitizing tablet.

I had no formal software training in college - and 4050 BASIC was very easy to use, and included several capabilities for debugging, like a SET TRACE command, which prints executed line numbers while running the program. In addition, 4050 BASIC allows quick access to value of any variable by just typing the variable name, and provides calculator capability on the command line.

I later worked at Compaq Computer in the mid-1980's on the Deskpro 286/386/486 hardware design team - and lamented that Microsoft BASIC did not have many of the capabilities in 4050 BASIC, so I couldn't port many of my 4050 programs.
Same goes for the early PC CGA graphics. Even VGA graphics 640x480 was about 1/4 of the resolution of the Tektronix 4051 more than ten years prior.

 

[Chuck(G)]

I forgot to mention, Tektronix 4050 BASIC had no integer variables, all numeric variables were 14 digit floating point +/-8.998E+/-307 (8 bytes plus variable name overhead).

That's not unsual--original BASIC didn't have typed variables. When we did our version, we left out numeric typing as well.

We did keep string variables and allowed implied conversion between string and numeric; i.e. A$=B$+3 We stored floating point variables in "compressed" as literals. Saved quite a bit of space.

 

[krebizfan]

Same goes for the early PC CGA graphics. Even VGA graphics 640x480 was about 1/4 of the resolution of the Tektronix 4051 more than ten years prior.

There were third party card and monitor combinations capable of 1024 x 768 or better resolutions in the mid-80s. The Vermont Microsystems doing 1024 x 800 with 256 colors cost about $6,000.

 

[nikola-wan]

Interface age bm9 basic benchmark from all sources

Interface age bm9 basic benchmark from all sources

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


[table="width: 1000, class: grid, align: left"]
[tr]
[td]System[/td]
[td]CPU[/td]
[td]MHz[/td]
[td]O/S[/td]
[td]Language[/td]
[td]RUN Time[/td]
[/tr]
[tr]
[td]CDC CYBER[/td]
[td]171[/td]
[td].[/td]
[td]NOS 1.4[/td]
[td]BASIC[/td]
[td]5[/td]
[/tr]
[tr]
[td]IBM [/td]
[td]3033[/td]
[td].[/td]
[td]VS2-10RVYL[/td]
[td]Stanford BASIC[/td]
[td]10[/td]
[/tr]
[tr]
[td]PRIME[/td]
[td]300[/td]
[td].[/td]
[td]PRIMOS[/td]
[td]BASIC[/td]
[td]25[/td]
[/tr]
[tr]
[td]Seattle System 2[/td]
[td]8086[/td]
[td]8[/td]
[td]MS-DOS[/td]
[td]MsB(compiled)[/td]
[td]33[/td]
[/tr]
[tr]
[td]DEC[/td]
[td]PDP11/70[/td]
[td].[/td]
[td]kSTS/E[/td]
[td]BASIC[/td]
[td]45[/td]
[/tr]
[tr]
[td]PRIME[/td]
[td]Jul-01[/td]
[td].[/td]
[td]PRIMOS[/td]
[td]BASIC V16.4[/td]
[td]63[/td]
[/tr]
[tr]
[td]DEC[/td]
[td]PDP10[/td]
[td].[/td]
[td]TOPS-10[/td]
[td]BASIC[/td]
[td]65[/td]
[/tr]
[tr]
[td]IBM [/td]
[td]S/34[/td]
[td].[/td]
[td]R-05[/td]
[td]BASIC[/td]
[td]129[/td]
[/tr]
[tr]
[td]Digital Microsystems[/td]
[td]HEX-29[/td]
[td]6[/td]
[td]HOST[/td]
[td]HBASIC_[/td]
[td]143[/td]
[/tr]
[tr]
[td]HP[/td]
[td]3000[/td]
[td].[/td]
[td].[/td]
[td]BASIC[/td]
[td]250[/td]
[/tr]
[tr]
[td]4MHz Z80A[/td]
[td]Z80[/td]
[td]4[/td]
[td]CP/M 2.2[/td]
[td]MsB(compiled)5.03[/td]
[td]277[/td]
[/tr]
[tr]
[td]Tektronix 4054A[/td]
[td]AMD2901[/td]
[td]25[/td]
[td].[/td]
[td]4050A ROM BASIC[/td]
[td]310[/td]
[/tr]
[tr]
[td]terak 8510a LSI-11[/td]
[td]CP1600[/td]
[td].[/td]
[td]UCSD 1.5[/td]
[td]BASIC 1.5 Compiler[/td]
[td]310[/td]
[/tr]
[tr]
[td]Seattle System 2[/td]
[td]8086[/td]
[td]8[/td]
[td]MS-DOS[/td]
[td]BASIC[/td]
[td]310[/td]
[/tr]
[tr]
[td]Alpha Micro AM100T[/td]
[td]WWD16[/td]
[td]3[/td]
[td]AMOS 4.3A[/td]
[td]AlphaBASIC[/td]
[td]317[/td]
[/tr]
[tr]
[td]Apple II+[/td]
[td]6502[/td]
[td]2[/td]
[td]DOS 3.3[/td]
[td]Microsoft TASC[/td]
[td]325[/td]
[/tr]
[tr]
[td]DEC[/td]
[td]PDP11/45[/td]
[td].[/td]
[td].[/td]
[td]BASIC[/td]
[td]330[/td]
[/tr]
[tr]
[td]Apple II+[/td]
[td]6502[/td]
[td]2[/td]
[td]DOS 3.3[/td]
[td]Expediter II compiler[/td]
[td]335[/td]
[/tr]
[tr]
[td]Data General[/td]
[td]NOVA3[/td]
[td].[/td]
[td]Timeshare[/td]
[td]BASIC 5.32[/td]
[td]517[/td]
[/tr]
[tr]
[td]BBC Micro[/td]
[td]6502[/td]
[td].[/td]
[td]BBC BASIC[/td]
[td]BBC Integer Basic[/td]
[td]523[/td]
[/tr]
[tr]
[td]SWTPC[/td]
[td]6800[/td]
[td].[/td]
[td]Software Dyn[/td]
[td]Compiler B 1.2[/td]
[td]528[/td]
[/tr]
[tr]
[td]Alpha Micro AM100[/td]
[td]WD16[/td]
[td]2[/td]
[td]AMOS 4.3A[/td]
[td]AlphaBASIC[/td]
[td]573[/td]
[/tr]
[tr]
[td]Technico SS-16[/td]
[td]9900[/td]
[td]3[/td]
[td]DOS[/td]
[td]SuperBASIC3[/td]
[td]585[/td]
[/tr]
[tr]
[td]terak 8510a LSI-11[/td]
[td]CP1600[/td]
[td].[/td]
[td]RT11 V0.3[/td]
[td]8k BASIC[/td]
[td]596[/td]
[/tr]
[tr]
[td]BBC Micro[/td]
[td]6502[/td]
[td]2[/td]
[td]BBC BASIC[/td]
[td]BBC F/POINT BASIC[/td]
[td]596[/td]
[/tr]
[tr]
[td]Ohio C4-P[/td]
[td]6502[/td]
[td]2[/td]
[td]OS65D 3.2[/td]
[td]Level I BASIC[/td]
[td]680[/td]
[/tr]
[tr]
[td]North Star FP[/td]
[td]Z80[/td]
[td]4[/td]
[td]MS-DOS[/td]
[td]MS BASIC[/td]
[td]685[/td]
[/tr]
[tr]
[td]terak 8510a LSI-11[/td]
[td]CP1600[/td]
[td].[/td]
[td]RT11 V0.3[/td]
[td]MUBASIC[/td]
[td]703[/td]
[/tr]
[tr]
[td]Apple II+[/td]
[td]6502[/td]
[td]2[/td]
[td]DOS[/td]
[td]Integer BASIC[/td]
[td]722[/td]
[/tr]
[tr]
[td]ADDS Multivision[/td]
[td]8085[/td]
[td]5[/td]
[td]NUON[/td]
[td]MBASIC 5.2[/td]
[td]877[/td]
[/tr]
[tr]
[td]4MHz Z80A[/td]
[td]Z80[/td]
[td]4[/td]
[td]CP/M 2.2[/td]
[td]MBASIC 4.5.1[/td]
[td]966[/td]
[/tr]
[tr]
[td]Apple II+[/td]
[td]6502[/td]
[td]2[/td]
[td]DOS 3.3[/td]
[td]APPLESOFT II[/td]
[td]970[/td]
[/tr]
[tr]
[td]Rexon RX30[/td]
[td]8086[/td]
[td]5[/td]
[td]RECAP[/td]
[td]Business BASIC[/td]
[td]1020[/td]
[/tr]
[tr]
[td]Cromemco[/td]
[td]Z80[/td]
[td]4[/td]
[td]CDOS[/td]
[td]Extended BASIC[/td]
[td]1196[/td]
[/tr]
[tr]
[td]North Star[/td]
[td]Z80[/td]
[td]4[/td]
[td]NS-DOS[/td]
[td]NS BASIC[/td]
[td]1149[/td]
[/tr]
[tr]
[td]Processor Tech Sol-20[/td]
[td].[/td]
[td].[/td]
[td]Solos[/td]
[td]Altair BASIC 8k[/td]
[td]1231[/td]
[/tr]
[tr]
[td]Exidy Sorcerer[/td]
[td]Z80[/td]
[td]4[/td]
[td].[/td]
[td]Microsoft BASIC[/td]
[td]1260[/td]
[/tr]
[tr]
[td]ISC Compucolor CC-II[/td]
[td]8080[/td]
[td].[/td]
[td].[/td]
[td]BASIC[/td]
[td]1267[/td]
[/tr]
[tr]
[td]Apple II+[/td]
[td]6502[/td]
[td]2[/td]
[td]CP/M 2[/td]
[td]GBASIC[/td]
[td]1284[/td]
[/tr]
[tr]
[td]Ohio C3-C[/td]
[td]6502[/td]
[td]1[/td]
[td]OS65D[/td]
[td]Level I BASIC[/td]
[td]1346[/td]
[/tr]
[tr]
[td]Commodore PET 2001[/td]
[td]6502[/td]
[td].[/td]
[td].[/td]
[td]Microsoft BASIC[/td]
[td]1374[/td]
[/tr]
[tr]
[td]ISC Compucolor 8051[/td]
[td]8080[/td]
[td].[/td]
[td]DOS[/td]
[td]BASIC 8001[/td]
[td]1375[/td]
[/tr]
[tr]
[td]Hewlett-Packard HP85[/td]
[td]NMOS[/td]
[td].[/td]
[td].[/td]
[td]BASIC[/td]
[td]1380[/td]
[/tr]
[tr]
[td]Basic/Four 600[/td]
[td]8080[/td]
[td].[/td]
[td].[/td]
[td]BASIC[/td]
[td]1404[/td]
[/tr]
[tr]
[td]Micro V Microstar 1[/td]
[td]8085[/td]
[td]3[/td]
[td]StarDOS[/td]
[td]StarDOS BASIC[/td]
[td]1438[/td]
[/tr]
[tr]
[td]Sinclair[/td]
[td]Z80[/td]
[td]2.5[/td]
[td].[/td]
[td]4k BASIC[/td]
[td]1514[/td]
[/tr]
[tr]
[td]Processor Tech Sol-20[/td]
[td].[/td]
[td].[/td]
[td]Solos[/td]
[td]PT Extended BASIC[/td]
[td]1812[/td]
[/tr]
[tr]
[td]Heath H89[/td]
[td]Z80[/td]
[td].[/td]
[td].[/td]
[td]Microsoft 4.7 BASIC[/td]
[td]1850[/td]
[/tr]
[tr]
[td]Zilog MCZ-1/70[/td]
[td]Z80[/td]
[td]2[/td]
[td]RIO[/td]
[td]Zilog BASIC[/td]
[td]1863[/td]
[/tr]
[tr]
[td]Tandy TRS Model 1[/td]
[td]Z80[/td]
[td]2[/td]
[td]TRSDOS[/td]
[td]Level II BASIC[/td]
[td]1929[/td]
[/tr]
[tr]
[td]IBM 5120[/td]
[td].[/td]
[td].[/td]
[td].[/td]
[td]BASIC[/td]
[td]1956[/td]
[/tr]
[tr]
[td]4MHz Z80[/td]
[td]Z80[/td]
[td]4[/td]
[td]CP/M 2.2[/td]
[td]CB80 v1.3[/td]
[td]1988[/td]
[/tr]
[tr]
[td]4MHz Z80[/td]
[td]Z80[/td]
[td]4[/td]
[td]CP/M 2.2[/td]
[td]BASIC-E(M9511 4M)[/td]
[td]2208[/td]
[/tr]
[tr]
[td]Vector MZ[/td]
[td]Z80[/td]
[td].[/td]
[td]MDOS[/td]
[td]Micropolis 8.5 BASIC[/td]
[td]2261[/td]
[/tr]
[tr]
[td]Digicomp P100-Z80[/td]
[td]Z80[/td]
[td]3[/td]
[td]CP/M 2.2[/td]
[td]BASIC-E(M9511 4M)[/td]
[td]2322[/td]
[/tr]
[tr]
[td]Cromemco CS3[/td]
[td]Z80[/td]
[td]4[/td]
[td]CDOS[/td]
[td]CBASIC-2[/td]
[td]2245[/td]
[/tr]
[tr]
[td]Texas Instruments99/4[/td]
[td]9900[/td]
[td].[/td]
[td].[/td]
[td]TI BASIC[/td]
[td]2479[/td]
[/tr]
[tr]
[td]Ortex Microengine[/td]
[td]CP1600[/td]
[td]2[/td]
[td]UCSD.H1[/td]
[td]BASIC 1.1[/td]
[td]3017[/td]
[/tr]
[tr]
[td]4MHz Z80A[/td]
[td]Z80[/td]
[td]4[/td]
[td]CP/M 2.2[/td]
[td]CBASIC v2.06[/td]
[td]3100[/td]
[/tr]
[tr]
[td]Zenith H89[/td]
[td]Z80[/td]
[td].[/td]
[td].[/td]
[td]Benton Harbor BASIC[/td]
[td]3550[/td]
[/tr]
[tr]
[td]Pocket TRS-80[/td]
[td]2x4CMOS[/td]
[td].[/td]
[td].[/td]
[td]BASIC[/td]
[td]55830[/td]
[/tr]
[/table]

 

[Chuck(G)]

Even VGA graphics 640x480 was about 1/4 of the resolution of the Tektronix 4051 more than ten years prior.

Apples and oranges. The Tek used a storage tube display and was monochrome only. I've never seen a Tek storage tube display in larger sizes (e.g. 20-24"); they might have existed. If you want early, consider the Digigraph 270, circa 1964. 22" CRT with a 1000x1000 resolution. To be fair, this was a vector-mode display.

 

[Dwight Elvey]

The Nicolet 1080 BASIC used 20 bit integer but one could load the floating point package, that I have but never tried. It also does a number of matrix operations. I can't run the BASIC on it right now as I'm not able to access the disk now. I hope to trouble shoot it in the month or so. I believe it runs an instruction in 1 or two usec, depending on the instruction. It has hardware assist for multiply and divide.
Dwight