• Please review our updated Terms and Rules here

Thoughts on minicomputer to microcomputer transition (PDP to Macintosh)

A couple of Canadian museums have some MCM/70s; you might want to ask them if web search turns up nothing. Given the limits of the 8008, it's remarkable that an APL interpreter could squeezed into it. I suspect that the tapes were ordinary Philips audio cassettes, but I can say for certain.
The systems are exceedingly rare.
 
For MCM/70: In terms of units, the only reference I see mentions "a few hundred being sold." (somewhere between $3k-$8k). And per a couple YT video demos of them, they seem quite slow. Very niche item.


@Eudimorphodon
Thought you might appreciate this "performance benchmark" I came across in a mid-1978 homebrew newsletter in San Carlos...

1664527234737.png

Even the cheap TRS-80 was doing floating point :D But also, this chart shows a sample of what systems they were even thinking about in 1978 (one West coast sample).


The lack of floating point in the early Apple's was apparently on purpose, since it was technically faster (for x/y screen cordinate stuff, like in simple games). But Woz did co-author a paper about implementing floating point for a 6502 ( http://www.6502.org/source/floats/wozfp1.txt ) in '76. Even Gates commissioned someone else (Monte Davidoff) to implement floating point (Math Package) in his BASIC.




Here's the benchmark program, if anyone interested. (I'm curious to try and repeat the IBM numbers; but not sure how they ran it on a PDP-8 -- I mean, which specific BASIC they used)

10 FOR 1=1000001 TO 1000003 STEP 2
20 FOR D=3 TO SQR(I) STEP 2
30 IF I/D=lNT(I/D) THEN 60
40 NEXT D
50 PRINT I
60 NEXT I
 
but not sure how they ran it on a PDP-8 -- I mean, which specific BASIC they used
I think there was one standard BASIC for TSS/8. https://tss8.sdf.org/docu/DEC-T8-KJZA-D-TSS-8_BASIC_8_Programming_Manual_Mar1969.pdf


PDP-8 isn't that slow so I tried it. About 12 seconds under TSS/8 running on my 8/E. OS/8 BASIC 4A was about 7 seconds. TSS/8 is a multiuser time sharing system so benchmark may have been run with other users on the system.


TSS/8.24+ JOB 01 [10,00] K00 01:02:42

WELCOME TO THE LCM+L TSS/8 SYSTEM.
.R BASIC

NEW OR OLD--OLD

OLD PROGRAM NAME--TEST


READY

LIST

10 FOR I=1000001 TO 1000003 STEP 2
20 FOR D=3 TO SQR(I) STEP 2
30 IF I/D=INT(I/D) THEN 60
40 NEXT D
50 PRINT I
60 NEXT I
70 END


READY

RUN


1.000003E+6


READY
 
There are differences in the speeds of the various PDP-8 BASICs but there were also noticeable performance differences between PDP-8 models. The PDP-8/S was the slowest by far being about 1/10th the performance of the original PDP-8. The PDP-8/A was a bit faster than the original PDP-8.

York University has the information of the MCM and MIL CPS-1 (the computer using a clone of the 4004). Emulators too. The MCM was a fascinating computer but MCM put so much effort in working around the problems of the 8008 that they ignored the newer cheaper chips that solved those same issues. The tape drive has the notch traditionally found in digital streaming tape so I would expect most of the characteristics to be the similar to the DEC TU-60 except that MCM has managed to store slightly more data.
 
Re: "TRS-80 Level I BASIC 'wasn't smart enough'", well, Level I BASIC was a pretty weird animal. It fit in only 4K of ROM, making it a TINY BASIC, but it was also selectively pumped up on steroids because for marketing reasons it only did single precision floating point instead of integer math. This made it maddeningly slow compared to an Integer BASIC, but for the specific niche of teaching rudimentary computer literacy it may have been the correct tradeoff...

But also because of the "fits in 4K of ROM" thing it also lacks advanced math functions like square root. There were subroutines in the back of the manual for implementing those, so it is technically incorrect to say it's "not smart enough", you can totally rewrite this little test to run under Level I. But since those routines were themselves written in BASIC... let's just say it's not going to make a very good showing on a floating point benchmark like this.

The performance spread between the PET and TRS-80 is about what I would expect given they're both running ports of the same BASIC and one is a 1mhz 6502 and the other's a 1.77mhz Z80. The Z80 is a more "featureful" CPU, by a mile, than the 6502, but its average instructions-per-clock is comparatively atrocious. There are some things a Z80 can do "better" than a 6502 and with less memory, but a general rule of thumb for simple instructions is a 1mhz 6502 is about equal to a 3-4mhz Z80.
 
Were there any 6502 CPUs corresponding to the Zilog Z84C00-20, which is, according my faulty memory the fastest 40-pin DIP pin-compatible-with-the-original version of the Z80? I don't count the ez80 because of lack of pin-compatibility.
 
Were there any 6502 CPUs corresponding to the Zilog Z84C00-20, which is, according my faulty memory the fastest 40-pin DIP pin-compatible-with-the-original version of the Z80? I don't count the ez80 because of lack of pin-compatibility.

The W65C02S, which is *almost* entirely compatible with the original(*), is rated up to 14Mhz.

(* off the top of my head the main difference is it uses an NC pin of the original 6502 to allow an external device to tri-state its address and control bus. Which is a handy change.)
 
FWIW, my IBM 5100 and 5110 are getting results consistent with these posted originals.

IBM 5100:
22.20 Sec
22.23 Sec
22.21 Sec

IBM 5110:
11.66 Sec
11.58 Sec
11.61 Sec

AFAIK, these have the same processor and clock, and so the 5110 improvement should just be its BASIC implementation (within its System/3 emulation).

Also, verified PET 4016 is consistent with those reported PET 2001 results:
6.76
6.66
6.81

(note: I always have to "unstuck" various keys on the PET when I bring it out, but the IBM keyboards are always ready to go!)



Is the IBM 360 result probably right? (compiled Waterloo FORTRAN IV?) Or is possibly a mis-type and they meant 12 seconds? (they used "ms" units earlier in the list, so wasn't sure if they meant 0.12 Sec for the 360 or not)


In the PDP-8 entry, is that what they meant by "load unknown"? User-load?
 
Re: S/360-67--probably correct; 120 msec. On the big mainframes, it gets harder to be precise, because the times are so short.
Also note that this is a floating-point benchmark and FP implementations are all over the place. The S/360-67 uses 32-bit floating point with ~~20 bit precision, while the CDC 6600 uses 60-bit floating point with 48 bit precision.
Also note that mainframe FORTRANs have aggressive optimization that can be turned on--no mention was made if this is the case.

I was fond of misquoting Disraeli by saying "There are lies, damned lies and benchmarks."
Benchmarks can make or break the success of an RFQ response. Used to be that in the big iron days, there were groups devoted to getting customer-submitted benchmarks to run fast. And then there were outfits that decided to make their hardware tailored to certain benchmarks--e.g. Saxpy Computer, where the name comes from one of the Linpack suite.
 
Last edited:
The W65C02S, which is *almost* entirely compatible with the original(*), is rated up to 14Mhz.

Is that the one from the Western Design Center? Are there any designs where page 0 RAM is internalized as 0-wait on-chip RAM?
 
Is that the one from the Western Design Center?

Yep, that's the one.
Are there any designs where page 0 RAM is internalized as 0-wait on-chip RAM?

Not that I know of off the top of my head, outside of microcontroller implementations. WDC, for instance, has the W65C134S which would roughly fall into that category; it's kind of like a 6502 glued to an internal RRIOT+VIA+extra pickles.
 
these have the same processor and clock, and so the 5110 improvement should just be its BASIC implementation (within its System/3 emulation).
I noticed this too, but I think there could be additional possibilities. It could be the System/3 emulation itself, too.

I was going to suggest that deep down, maybe the System/3 and System/3[67]0 emulation for APL both make use of shared PALM-native code for floating point arithmetic --- an improvement to something like that would have made the 5110 faster for number-crunching. (I know both emulators share some code for things like accessing the tape drive, for example.) But then I noticed that System/3 didn't have a floating point capability per Wikipedia.
 
In the subsequent newsletter, a write in from Jeff Raskin mentions the AppleSoft... where he proudly gets 6.3 seconds.

1664596449522.png

Which is interesting, because isn't the AppleSoft disabling the internal 6502, taking over the bus, and running a Z80?


In that same newsletter is a note about the HUH Electronics S-100 adapter for the Commodore PET (same group that made the PETUNIA "sound card"). I didn't realize any such adapter was ever available.

Also mentioned is the CBBS "Community BBS", which is perhaps the 2nd BBS installation after the "Computerized BBS" over in Chicago? All based on an IMASI 8080, CP/M, written in assembly (source as of 1980 is still available) and uses 24K.
 

Attachments

  • 1664595244044.png
    1664595244044.png
    278 KB · Views: 1
Which is interesting, because isn't the AppleSoft disabling the internal 6502, taking over the bus, and running a Z80?

No, you’re thinking of the Z-80 Softcard. Applesoft is the port of Microsoft BASIC that’s been in ROM on Apple IIs since the Apple II+. (It was also sold briefly on a cassette you can load on a machine with Integer Basic ROMs, which I assume is what was in play here.) It is based on the same source code as Commodore PET BASIC and should run at nearly exactly the same speed which, well, it does. (6.3 vs. 6.5 seconds, if that’s even accurate, is nothing. The two machines don’t run at precisely the same speed, and the Commodore has a more elaborate OS kernel with a 60Hz clock interrupt it handles, so, yeah, 3% more overhead probably adds up.)

When I say they’re based on the same source I mean that literally. There is a GitHub repo I’m too lazy to look up right now where someone has reconstructed the MS 6502 BASIC source code such you can build binary-identical respins of about a dozen different versions, including PET, Apple, and OSI BASICs, and even customize your own.
 
Here's an 8085 BASIC that I designed ca. 1978
Multi-user type, which is kind of difficult to do on the 8080 platform. Since almost everything on the system was written in this BASIC, we went the compiled route. Beat the pants off of BillG's BASCOM at the time. I didn't write the manual, so I apologize if it's a little vague in parts. A port to Xenix was made sometime around 1983 and was still in use in some places well into the 1990s.
I don't know if we ever benchmarked it. I suppose I could fire up one of the old systems and see how it does.
 
Regarding the 5100's, I'd be interested in an APL-version of this same program (some results did a FORTRAN version, so fair to also try an APL version) and see the runtime results. I'm assuming they'd be about the same as the BASIC version, on that system; but maybe we'd be surprised. Note, the 5100's BASIC (like its APL counterpart) has support for matrix operations - I'm not sure if any of the later micros had a BASIC that supported that (in ROM). And also a set of built in constants like PI, E, and some unit conversion constants (INCM, LBKG, GALI).

If we ever get that 5100 emulator going, that'd reveal the difference :) Someday!
 
Ah thanks, I do get the SoftCard and AppleSoft mixed up - I never used that Z80 card and never had to deal with integer BASIC. But I do remember seeing those cassette tapes of BASIC (like for the Altair 680 also).



I was reading thru that STAR BASIC manual - "CALL WIZARD" was a real command :D Nice.
 
I'm not sure if any of the later micros had a BASIC that supported that (in ROM). And also a set of built in constants like PI, E, and some unit conversion constants (INCM, LBKG, GALI).
ECMA-116 includes matrix operations and constants like PI. The most common implementation of it was in True BASIC which was not shipped on ROM AFAIK. BBC BASIC got a set of matrix functions in the RISC version which also didn't fit in ROM. Nicholas Higham has an article describing how to add assembly routines that handle matrix functions to a number of micros with BASIC in ROM. https://nhigham.com/miscellaneous-papers/

The Z-80 system with a BASIC in ROM that supported matrix functions was the TI-83/84.
 
It occurred to me, why wasn't any Wang model not also in the benchmark test? I mean, sure, they just tested a few systems that they had available (which did also include several non-microprocessor examples, like the Interdata 7/16, 5100, PDP). Just of all those very nice systems (including some HP systems), but they had no Wang model also?
EDIT: In a 1980 Computerworld article, the Wang 2200VP model got decent benchmark rankings against other office-computers (like the TRS-80 Model II or some higher-end HP and TI systems). I guess maybe the main point of the 1978 article was showing that you had some sub-$1k systems being very competitive against $10k+ systems (which is a valid point, but of course there is more to the cost/benefit-of-ownership than raw performance)

I ran this benchmark on the Wang 2200B emulator, to at least verify that it was capable of running this correctly -- which it did, taking about 15 seconds on my system (not sure how representative that is of real hardware -- the emulator probably throttles to a semi-realistic timing, but point is its BASIC interpreter was fully FP capable even in '73). But by '78, there was the 8080-based Wang 1200 WPS (or IOS). Lots of BASIC's out there before Bill's "open letter" (but sure, his maybe was the first one ported to the 8080, thanks to a certain emulator and various file editors) :D
 
Last edited:
Note that some of the big differences in performance had little to do with raw processor speed, but the implementation of floating point. Those systems with hardware floating point did quite well. Since the IEEE 754 standard wasn't ratified until 1985, implementations and precision were all over the place. Some used decimal, others binary. Precision could be only a few digits (5-6) to many more.

Compiled (either to native code or p-code) or interpreted (either tokenized or raw) also had performance consequences. JIT compilation wasn't a thing yet.

All that could be really compared here was the same BASIC running on the same or similar hardware.

Lies, damned lies and benchmarks.
 
Back
Top