SC/MP (1977 microprocessor) architecture
Ralf Bayer
Hello,
does anyone remember the old National Semiconductor microprocessor
called SC/MP (aka INS8060)?
This was in the heart of my first computer 20 years ago.
Is any of the architecture information for this processor available
online?
Thank you for any help,
Ralf Bayer
--
Ralf Bayer
Motorola ECID E-mail: bay...@wies.ecid.cig.mot.com
Hagenauer Strasse 47 Phone: +49-611/3611166
D-65203 Wiesbaden, Germany FAX: +49-611/3611299
Mr Philip Arthur Riebold
bay...@otter.cig.mot.com (Ralf Bayer) writes:
>does anyone remember the old National Semiconductor microprocessor
>called SC/MP (aka INS8060)?
This was used in Clive Sinclair's MK14, the first computer I owned, as you
said about twenty years ago. If I remember correctly the architecture was
fairly clean and elegant however doing timing loops was a nightmare. Although
the SC/MP had a hardware delay instruction for cheapness the MK14 used a PAL
subcarrier crystal (4.43361925 MHz) as the frequency reference.
>Is any of the architecture information for this processor available
>online?
Have a look at the CPU Info Center
http://infopad.EECS.Berkeley.EDU/CIC/
The SC/MP (and a lot of other interesting CPUs) are mentioned in the 'History
of CPUs section.
--
Philip Riebold,
John Bayko
In article <bayerrl.876406671@otter>,
Ralf Bayer <bay...@otter.cig.mot.com> wrote:
>
>does anyone remember the old National Semiconductor microprocessor
>called SC/MP (aka INS8060)?
>
>
>online?
>
>Ralf Bayer
It's described briefly in the Great Microprocessors page,
available from various sites such as mine, or the CPU Info Centre at:
http://infopad.eecs.berkeley.edu/CIC/
It also has a couple links which might be helpful, but then might not
be...
----cut here----
Great Microprocessors of the Past and Present (V 9.9.4)
[...]
Section Two: Forgotten/Innovative Designs before the Great Dark Cloud
Part III: SC/MP, early advanced multiprocessing (April 1976) . . . .
The National Semiconductor SC/MP (Single Chip/Micro Processor,
nicknamed "Scamp") was a typical 8 bit processor intended for control
applications (a simple BASIC 2.5K ROM was added to one version). It
featured 16 bit addressing, with 12 address lines and 4 lines borrowed
from the data bus (it was common to borrow lines (sometimes all of
them) from the data bus for addressing - however only the lower 12
index register/PC bits were incremented (4K pages), special
instructions modified upper 4 bits). Internally, it included four
index registers (P1 to P3, plus the PC/P0) and two 8 bit registers. It
had no stack pointer or subroutine instructions (though they could be
emulated with index registers). During interrupts, the PC and P3 were
swapped. It was meant for embedded control, and many features were
omitted for cost reasons. It was also bit serial internally to keep it
cheap.
The unique feature was the ability to completely share a system bus
with other processors. Most processors of the time assumed they were
the only ones accessing memory or I/O devices. Multiple SC/MPs (as
well as other intelligent devices, such as DMA controllers) could be
hooked up to the bus. A control line (ENOUT (Enable Out) to ENIN)
could be chained along the processors to allow cooperative processing.
This was very advanced for the time, compared to other CPUs.
In addition to I/O ports like the 8080, the SC/MP also had
instructions and one pin for serial input and one for output.
National Semiconductor eventually replaced the SCMP with the COP4 (4
bit) and COP8 (8 bit) embedded controllers, with only two index
registers, but adding stack support.
_________________________________________________________________
National Semiconductor:
http://www.national.com/
National Semiconductor Microcontroller Technology:
http://www.national.com/appinfo/mcu/
----cut here----
--
John Bayko (Tau).
ba...@cs.uregina.ca
http://www.cs.uregina.ca/~bayko
David Boreham
Ralf Bayer wrote:
> does anyone remember the old National Semiconductor microprocessor
> called SC/MP (aka INS8060)?
From memory, the SC/MP was not the 8060.
One was PMOS and the other NMOS.
Other than that they shared the same architecture
and pinout (other than supplies, of which there
were more than one for the PMOS version).
How about the 8070, the successor to the 8060 ?
I have one somewhere in my parents' garage in
a system I built a long time ago.
Enough nostalgia for now...
Mike Albaugh
John Bayko (ba...@borealis.cs.uregina.ca) wrote:
: ----cut here----
: Great Microprocessors of the Past and Present (V 9.9.4)
: [...]
: Section Two: Forgotten/Innovative Designs before the Great Dark Cloud
: Part III: SC/MP, early advanced multiprocessing (April 1976) . . . .
: [...] meant for embedded control, and many features were
: omitted for cost reasons. It was also bit serial internally to keep it
: cheap.
Can anybody confirm this? I was told by a NatSemi designer
who should have known that the reason the Scamp was so slow was that
the microcode was essentially "conditionally executed" (Think of an
ARM with no, or few, branches), rather than that the ALU was bit-serial.
I'd have thought they would have learned a lesson from the PDP-8S,
but what am I thinking, CS _cultivates_ Technological Alzheimers... :-)
(as boo has shown in another thread :-)
: The unique feature was the ability to completely share a system bus
: with other processors. [...]
: could be chained along the processors to allow cooperative processing.
: This was very advanced for the time, compared to other CPUs.
Yeah, if your task was easily partioned, you could chain together
enough Scamps to _almost_ match a single, same price, 6502 :-)
Mike
| alb...@agames.com, speaking only for myself
Andrew Cruickshank
David Boreham wrote:
>
> Ralf Bayer wrote:
>
> > does anyone remember the old National Semiconductor microprocessor
> > called SC/MP (aka INS8060)?
>
> From memory, the SC/MP was not the 8060.
> One was PMOS and the other NMOS.
> Other than that they shared the same architecture
> and pinout (other than supplies, of which there
> were more than one for the PMOS version).
>
Yes:
SC/MP was PMOS.
SC/MP II was NMOS and also designated INS8060.
> How about the 8070, the successor to the 8060 ?
> I have one somewhere in my parents' garage in
> a system I built a long time ago.
>
> Enough nostalgia for now...
My distant and clouded memory recalls that the 8070 was
the 8060 SC/MP II with a 4K ROM on chip with the NIBL
Tiny BASIC interpreter.
---------------------------
Andrew Cruickshank.
Andrew Cruickshank
John Bayko wrote:
>
> ....
>
> The unique feature was the ability to completely share a system bus
> the only ones accessing memory or I/O devices. Multiple SC/MPs (as
> well as other intelligent devices, such as DMA controllers) could be
> hooked up to the bus. A control line (ENOUT (Enable Out) to ENIN)
> This was very advanced for the time, compared to other CPUs.
>
>
The bus sharing facility always looked cute and simple but I never
heard of anybody ever using it.
More significantly the SC/MP took so many cycles to do anything
with instructions being primarily register operations and taking
5 or 7 cycles even for simple things - with memory accesses taking
2 cycles that there was a lot of spare bus bandwidth to share with
a second and possibly even a third processor.
----------------------------
Andrew Cruickshank.
Mike Albaugh
Andrew Cruickshank (and...@openkast.demon.co.uk) wrote:
: The bus sharing facility always looked cute and simple but I never
: heard of anybody ever using it.
I did. One fellow made an organ out of twelve Scamps. Each
handled the synthesis of a single note, across several octaves.
Of course:
a) He worked for NatSemi, and got the parts for free.
b) It was a "one-off", so parts cost was nearly irrelevant.
c) It was an elaborate joke.
I also especially like the (internally circulated, but
seriously frowned upon) Application Note suggesting that the Scamp
would make a darn fine fishing-lure :-)
gast...@gmail.com
A few month ago I startet a project with a INS8060 processor. The idea was to "create" a running system based on this:
http://www.dos4ever.com/SCMP/SCMP.html
I made a KiCAD schematic and a pcb design. Unfortunately I don't have a chance to get the system running ....
I would be very happy to get some help!!!
Thomas
Bruce Hoult
http://www.oldcomputermuseum.com/mini_scamp.html
I remember reading all these articles at the time. If I'd had AU$100 (plus shipping to NZ) at the time I'd have probably got one. (I was 13)
http://messui.the-chronicles.org/comp/miniscamp.pdf
I remember thinking the instruction set looked pretty horrible, and maybe the Signetics 2650 would be better. EA had projects for that too
http://www.yesterdaystechnology.com/html/baby_2650.html
The 2650 supported 32 KB of RAM. 8 KB could be accessed directly, the rest only by using pairs of bytes in the base 8 KB as pointers. Any one of three 8 bit registers could be used an an index added to either an absolute address, or to the pointer stored at that absolute address. The index register could also be auto-incremented or decremented.
So global arrays or records or pointers to the could be use ok, including using them as a stack.
The main limitation was subroutine return addresses were kept in on-chip registers and there were only eight levels available.
Other than the very small hardware stack it was quite comparable the 6502 -- better in some ways, worse in others. The way that counted was the 6502 was cheaper, and more readily available.
Quadibloc
> Is any of the architecture information for this processor available
> online?
John Savard
Quadibloc
> SC/MP was PMOS.
Back in the days when PMOS was a thing, among the things made with it were
single-chip pocket calculators that did log and trig functions.
I would have thought that if you could put that on a single chip, a
microprogrammed implementation of a mainframe instruction set - say a System/360
with packed decimal, character, and floating-point instructions - would have
been possible, and that way a company could have made a microprocessor in the
8-bit era that instead had a 32-bit architecture that could then have remained
unchanged up to the era of the Pentium.
Meaning a *lot* of compatible software...
Why did it never happen that way?
John Savard
Bruce Hoult
A 1 MHz 6502 running native code using 32-bit variables would be approximately the same speed as the 360 Model 30, the slowest 360 sold (rated for 0.0345 MIPS). Adding interpretive emulation would slow it down at least to 0.01 MIPS, probably more. Maybe there would be some markets where this was acceptable. Quite a lot of commercial software was written for the UCSD P-Code system on the Apple ][. There's a lot more overhead to interpreting a hardware 32 bit instruction set with things like condition codes than to interpreting a stack-oriented bytecode with (mostly) 16 bit quantities.
Of course an Apple ][ cost an awful lot less than anything IBM sold in the 70s.
Could you have done better than that? Probably. IBM itself could have re-implemented the 360/30 using mid 70s technology. It was in fact an 8 bit CPU with very few registers, running on 2 us access time RAM. But there would be little incentive for IBM to do it, and they'd sue anyone else who tried. The market in IBM plug-compatible systems was I thin kin high end systems (??)
Walter Banks
and cost ~$8500 failed and that pretty much stopped that approach.
There were several tries at this, IM6100 for PDP8 ISA for example all
failed to do the obvious, take advantage of an established body of software.
For a while I had a PDP-11 and a handful of apple]['s and some early PC
all running UCSD pascal. That actually was a reasonable development
approach.
w..
Anne & Lynn Wheeler
Walter Banks <wal...@bytecraft.com> writes:
> The IBM 5100 was released 1975? could interpret a 360 instruction set
> and cost ~$8500 failed and that pretty much stopped that approach.
>
> There were several tries at this, IM6100 for PDP8 ISA for example all
> failed to do the obvious, take advantage of an established body of software.
>
> For a while I had a PDP-11 and a handful of apple]['s and some early PC
> all running UCSD pascal. That actually was a reasonable development
> approach.
https://en.wikipedia.org/wiki/IBM_5100
all low-end and mid-range 360s & 370s emulated the 360 instruction set
with various native CISC processor ... vertical microcode ... avg about
ten native instruction for every 360 instruction. I got roped into doing
a project to move the most highest used 6kbytes of 370 kernel code into
native microcode for 138 & 148 (followon to 135 & 145) with about 10:1
speedup. Old post with results of kernel pathlength studied ordered by
use ... 6kbyte cutoff was 79.55% kernel processing time (reduced to 8%
native)
http://www.garlic.com/~lynn/94.html#21
some of the people at Palo Alto Science Center responsible for 5100
helped with the 138/148 microcode effort
High end 360s & 370s were horizontal microcode machines.
801/risc from mid-70s ... circa 1980 there was effort to switch the
large number of different internal CISC processors to 801/risc,
controllers, low&mid-range 370s (aka 4361 & 4381 followon to 4331&4341),
followon to s/38, etc (a single family of 801/risc rather than never
ending number of one-off CISC processors). For various reasons, the
efforts failed, and saw some number of engineers leaving for risc
efforts at other vendors.
801/risc ROMP chip was suppose to be used for the followon the
Displaywriter ... when that was canceled they decided to use it for the
unix workstation market. They got the company that had done the AT&T
unix port to IBM/PC for PC/IX, to do one for ROMP ... resulting in
PC/RT and AIX. Later the academic unit did a port of USB BSD to ROMP for
"AOS". posts mentioning 801/risc, ROMP, RIOS, Fort Knox, etc
http://www.garlic.com/~lynn/subtopic.html#801
They then did 68k-based 370 which had a card/cable for PC/XT as XT/370,
Oct1983 (ran about 100kips)
https://en.wikipedia.org/wiki/PC-based_IBM-compatible_mainframes#Personal_Computer_XT.2F370
and then made available as PC/AT as AT/370.
https://en.wikipedia.org/wiki/PC-based_IBM-compatible_mainframes#Personal_Computer_AT.2F370
some of the pc/370 issues were 1) bloated mainframe software that page
thrashed in the original 384kbyte storage (I was blamed for delaying
release when I showed how bad page thrashing was in 384kbyte) ... so
they upgraded to 512kbytes before release (reducing some of the page
thrashing) 2) mainframe intensive page thrashing I/O and file system i/o
that were being simulated on 100ms access XT disk.
Then a group in POK did A74 ... old email with A74 details (about
350kips processor, 3.5 times pc/370)
http://www.garlic.com/~lynn/2000e.html#email880622
old post with part of the (infoworld) 7nov1988 article
http://www.garlic.com/~lynn/2002d.html#4
I was asked to do part of both the pc/370 and the A74 software,
old post with A74 kernel software updates I redid for A74
http://www.garlic.com/~lynn/2015d.html#35
big advantage of A74 (compared to PC/370) was 16mbyte real memory
(instead of 512kbytes) and much faster PC disk.
then S/390 processor card
https://en.wikipedia.org/wiki/PC-based_IBM-compatible_mainframes#S.2F390_Processor_Card
there was then vendor software developed that ran on intel and sparc
architectures that had lot of simularities to the microcode implementing
low&mid-range 360s & 370s:
https://en.wikipedia.org/wiki/PC-based_IBM-compatible_mainframes#z.2FArchitecture_and_today
Hercules
https://en.wikipedia.org/wiki/Hercules_(emulator)
--
virtualization experience starting Jan1968, online at home since Mar1970
Anne & Lynn Wheeler
> some of the people at Palo Alto Science Center responsible for 5100
> helped with the 138/148 microcode effort
APL microcode assist .... with the "assist", some amount of APL ran as
fast on 145 as it did on 370/168 (also about ten times speeed up).
spac...@gmail.com
> SC/MP was PMOS.
> SC/MP II was NMOS and also designated INS8060.
> My distant and clouded memory recalls that the 8070 was
> the 8060 SC/MP II with a 4K ROM on chip with the NIBL
> Tiny BASIC interpreter.
The INS8070 series had 2.5KB of masked ROM and 64 bytes of RAM on-chip. Unlike the INS8060, it used an unmultiplexed address bus. There were three marketed variants:
INS8070: masked ROM disabled
INS8072: custom masked ROM
INS8073: NIBL BASIC in masked ROM
Despite the common name, there appears to be little similarity between the INS8073 NIBL BASIC, and National's NIBL BASIC for the 8080 (derived from Livermore BASIC).
spac...@gmail.com
> with instructions being primarily register operations and taking
> 5 or 7 cycles even for simple things - with memory accesses taking
> 2 cycles that there was a lot of spare bus bandwidth to share with
> a second and possibly even a third processor.
spac...@gmail.com
> Back in the days when PMOS was a thing, among the things made with it were
> single-chip pocket calculators that did log and trig functions.
>
> I would have thought that if you could put that on a single chip, a
> microprogrammed implementation of a mainframe instruction set - say a System/360
> with packed decimal, character, and floating-point instructions - would have
> been possible, and that way a company could have made a microprocessor in the
> 8-bit era that instead had a 32-bit architecture that could then have remained
> unchanged up to the era of the Pentium.
>
> Meaning a *lot* of compatible software...
>
> Why did it never happen that way?
I've heard it claimed that Signetics designed a System/360 compatible microprocessor, though not in PMOS, but management was too afraid of IBM to bring it to market.
Anne & Lynn Wheeler
> In the heydey of PMOS, I don't think even a very small implementation
> of a System/360 processor would have fit on a single chip, but it
> could have been done with a small number of chips. While ROM and RAM
> are by nature quite regular and thus can be implemented quite densely,
> I don't think there were many PMOS chips with more than about 8000
> non-memory transistors. Even in NMOS it would have been fairly hard
> to do as a single chip much earlier than 1980.
>
> I've heard it claimed that Signetics designed a System/360 compatible
> microprocessor, though not in PMOS, but management was too afraid of
> IBM to bring it to market.
http://www.garlic.com/~lynn/2017c.html#9 SC/MP (1977 microprocessor) architecture
I help write the white paper that blocked using 801/risc (Illiad chip)
for 4361 & 4381 ... part was cisc chips had advanced to point where much
of 370 could be directly implemented (as opposed to traditional
emulation in microcode).
Boeblingen (IBM) in the mid-80s did 3chip set ("roman") that did 370 at
168-3 performance. Some non-IBM in Germany came into possession of copy
of detailed description ... somebody from Amdahl had learned of it
... took possession of the document and immediately sent it to me (since
it was illegal for them to have it).
SLAC&CERN did bitslice 370 subset ... problem state sufficient to run
fortran programs ... coupled to sensors all along line for intial data
reduction; first "168E" (i.e. 168 performance) and later "3081E" (3081
performance).
trivia: during 70s & 80s some amount of ibm mainframe technical people
(ibm, amdahl, signetics, tymshare, other customers, etc) use to have
monthly technical meetings at SLAC. later it was taken over to have IBM
marketing presentations (no longer held at SLAC).
I mentioned that when Iliad 801/risc strategy imploded ... some 801/risc
engineers left to go work on risc at other vendors. IBM may have sued
AMD for hiring one of the engineers for work on 29K.
Signetics had sister company 2pi ... which did small ibm compatible
mainframe ... original sold as NCSS 3200. NCSS was spun-off of cambridge
scientific center offering online (virtual machine based) CP67/CMS
commercial services ... 1978 NCSS 3200 reference here
https://www.amazon.com/National-Computer-System-Overwork-Print/dp/B007RC11RU
tymshare (with their virtual machine based online commercial service)
got into some competition with NCSS (using vm370/cms, followon to
cp67/cms), including 4th generation programming language
http://archive.computerhistory.org/resources/text/Oral_History/Clemens_Jack/Cohen_Gerald/Cohen_Gerald_1.oral_history.1986.102658228.pdf
Quadibloc
> I've heard it claimed that Signetics designed a System/360 compatible
> microprocessor, though not in PMOS, but management was too afraid of IBM to
> bring it to market.
architecture around with the owners of which a deal could have been done. Say
the Xerox Sigma architecture, for example.
But the technical reason would be that an 8-bit processor with an 8-bit
architecture would be more efficient than one emulating a bigger computer, at
least for many of the tasks for which it would be used. Microprocessors were
mainly sold as controllers, with desktop computers using them a small part of
the market - and people didn't anticipate how quickly Moores' Law would bear
fruit, to see the advantage of dominating the market *later*, with a chip that
had years of microcomputer software behind it because its ISA didn't need to
have been altered.
Texas Instruments, with the 9900, tried to be the first in the market with a
16-bit CPU with a good minicomputer architecture. But it intentionally crippled
the 99/4 home computer with slow memory, and in other ways failed to capitalize
on the lead it could have obtained.
John Savard
Walter Banks
that costs of a new product follow a known predictable curve for
reduction in a per unit costs. They wanted to get the volume up to get
down the curve faster and the sold earlier units at below cost. They
then discovered how experience curves really work. They had some power
supply fires but no records that would allow them identify potentially
defective units by serial number and TI component supplier. The recall
was very expensive.
The 9900 ISA wasn't outstanding but had significant potential in the
home market. They did a lot of things right in the 99/4 but needed a
Jack Tramiel type who understood the personal computing market.
w..
paul wallich
fairly well established, with programmers who were comfortable using the
assembly programming models of the 6502 and 8080/Z80. The rules for
getting the best possible performance out of the 99/4 in the least
possible space were different, and programmers who were already experts
in other machines didn't immediately dive into the details of the 9900.
(Albeit at least it wasn't the General Instruments CP1610, which was
pretty universally reviled among home-machine programmers.)
paul
Brian Cockburn
I am starting on the design phase of a SC/MP II (INS8060) project. I would be interested to share information with you.
Thanks, Brian.
JOHN SMITH
I've recently found my SC/MP KIT board, which has been tucked away in inaccessible storage for a decade. It was originally designed for use with the ISP-8/500 (SC/MP) but I see that I had applied the retrofit kit to upgrade it to a SC/MP II (ISP-8A/600N a.k.a. INS8060). Problem is that There is no CPU on the card, only the socketed MM5214 ROM. I found sources for the INS8060 but two of them took the order and then cancelled saying there was no stock available. I finally ordered 3 pieces from QUEST COMPONENTS for ~US$12 each (+ US$14 for shipping) and they have been shipped. Expecting them in Friday. I have taken the liberty to schematic capture the original design (from published paper source) with the retrofit modifications, into OrCAD. When the parts come in, I'll test it and make any schematic changes necessary. If you like, I can share the OrCAD design file with you ... or the PDF version of it. Keep in mind that my OrCAD version incorporates the INS8060 (5 volt only) modifications, which I've not seen published anywhere else online.
My goal is to design my own INS8060 PCB with 32KB RAM and 32KB EEPROM along with an 8255 PIO and 8251 UART. I'll have to make changes to the monitor code and the NIBLE BASIC code. I'll likely run it at 3.6864 MHz, so as to use it to derive the bit clock on the 8251.
Over the past few weeks, I've scoured the internet for references, manuals, etc., so I have a small collection.
I have in my personal stock, the INS8070 and INS8073. I designed a wire-wrap computer around the INS8073 back in the early 80's. At the time, I had befriended a REP (QXI) for NAT-SEMI, who gave me the SC/MP KIT and INS8073's. It seems that I am the only one on the net that has the “70-Series Microprocessor User’s Manual” (Publication #uPG-000001), which I is accessible under the "Developing software on the INS8073" section on my posted blog on the INS8073 computer at https://8073sbc.wordpress.com/.
Hope some of the info here helps you along your journey.
Peace and blessings,
JQ.
JOHN SMITH
JOHN SMITH
JQ