Revisiting the NS32016

[bson]

In 86 or 87 I built a board around the NS32016 CPU, NS32201 TCU, NS32082 MMU, and NS32202 ICU.  (I didn't have an assembler so also wrote a very simple one for it to generate a bit of test code.  Hosted on a VAX and written in DEC macro assembler, which I was very familiar with.)  It also had two MC6850L UARTs.  I never wired up the SRAM, but it worked fine.  It had a socket for the NS32081 FPU, but I don't recall if I had that or not.  I got the chips from a friend at NS handing out samples.  The other day I found the board in the basement!!!  It was broken (veroboard is pretty fragile) but all the ICs seem fine...  It's mostly just 6MHz parts, so nothing fancy super fast.

So... I'm thinking just for the heck of it I'll reuse the chipset and whip up a simple board in KiCad.  I'll give one of the UARTs a VPC USB chip.  A simple interface to do 4-bit SDIO for storage.  4Mx16 3.3V PSRAM with level conversion buffers.  All the random stuff on the board will be SMT to save space, but I'll have two 32-pin EPROM sockets for a simple monitor and boot loader.

I do recall the MMU never worked right, and in hindsight it's probably just awfully buggy.  So I might just leave that out.  I'd only need that if I wanted to get some old version of NetBSD up and running on it... which frankly probably isn't worth the effort.

[woofy]

I used to drool over this processor when it was first announced and waited eagerly for samples. It had a wonderfully consistent architecture for the time.
Trouble was, NS could never make it work. By the time it was available it was too late, Sophie had designed the first ARM processor.

[DrG]

Nice. I barely have any memory of even hearing about them. Did a little bit of looking around and found:

https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:ns32000

and, especially, http://www.cpu-ns32k.net/index.html , appropriately titled, "The Web Site to Remember National Semiconductor's Series 32000 Family" You might want to check them out if you have not already.

[Ian.M]

The MMU's datasheet says it provides two hardware breakpoints, so I'd include it even if you don't need its MMU functionality.  If it proves to be excessively problematic you can always disable it by replacing it with a header in its socket, wired to jumper it out.

[bson]

It took a bit of searching, but all the datasheets could still be found.  I suspect the lack of decoupling might have been responsible for why it was flakey with the MMU enabled... The MMU datasheet specs a power dissipation of 1.5W max and an active supply current of 200-300mA!!!   I guess it's really 300mA*5V. No spec for the input capacitance so lord knows, but given the NMOS gate dimensions of this node I'm sure it's pretty major.  This is going to need resistors to keep signals from bouncing all over.

I think I saw on cpu-ns32k.net (or maybe somewhere else) that the minimum speed actually is 4MHz despite the datasheet saying 200kHz.  I only had a 2MHz scope at the time and ran it at very low speeds, so that may have had something to do with it as well.  Needless to say in the modern era that's not much of a problem!    In hindsight, looking at the datasheets and the very naive design I'm actually surprised it worked as far as executing code out of EPROM without the MMU enabled...

edit: the 4MHz speed is in the errata for the 32016.  The very, very long errata...

[Halcyon]

The copy-and-paste post by the user Camila has been noted and that person is being watched.

[woofy]

The copy-and-paste post by the user Camila has been noted and that person is being watched.

I used to run a forum and if I suspected a spammer trying to make their way in, I would take some text from their response and google entire sentences. I just did that for https://www.eevblog.com/forum/microcontrollers/attiny414-plus-small-oled-display/msg3545006/#msg3545006 and found this page http://www.technoblogy.com/show?WNM from 4 years ago.

[woofy]

And this https://www.eevblog.com/forum/microcontrollers/acer-battery-clear-pf-flag-using-raspberry-pi/msg3545009/#msg3545009
from a July 2014 post here https://www.raspberrypi.org/forums/viewtopic.php?t=82373

[Kleinstein]

AFAIK the Oberon system was also base on a 32K processor. So there may be an alternative, simpler OS available than netBSD.
A unix variant may require the MMU.

[SiliconWizard]

AFAIK the Oberon system was also base on a 32K processor. So there may be an alternative, simpler OS available than netBSD.
A unix variant may require the MMU.

Yes. I talked about it in a thread a while ago. The original Oberon system was running on the Ceres workstation (NS32032 CPU):
https://en.wikipedia.org/wiki/Oberon_(operating_system)
https://en.wikipedia.org/wiki/Ceres_(workstation)

Source code here: https://github.com/Project-Oberon/Source-Code

[bson]

Oberon looks interesting!  I didn't look at the source tree, but my concern would be the ability to cross build it without an existing Oberon system to host it.  And without building it's impossible to port to my board.  (During the design which I am reminded how many documentation bugs there are in the datasheets, like one datasheet referring to a pin on another chip, that was renamed after the first datasheet went to print...)

I'm also reminded how complicated the MMU makes the timing of the multiplexed bus... For example, the is a PAV# output for Physical Address Valid, indicating the MMU has place a PA on the AD bus.  But this can't be used alone for address decoding, since during a read or write cycle PAV# goes high and it's now a data bus.  If PAV# is used to drive the address decoder (I just used a 74AHC138) then in the middle of a read or write cycle when AD turns into a data bus the corresponding CS# would be lost.  Fun times.  So I leave the '138 always active, watching the high 3 bits of the latched physical addresses.  But the AHC propagation times are like what 10-15ns, while the transition times of the stone age NMOS can reach 50ns!  So tons of opportunities for glitching...  (I use AHC so the demuxed PA and D bus can be 3.3V to simplify interfacing with modern peripherals, just to keep size and complexity down.)

[jmelson]

In 1984 our university bought a Logical Microcomputer Co. 16032 computer running either Xenix or Genix.  Then, they upgraded to the other one.
I made a wire-wrapped clone of the machine, and while it worked, it was AMAZINGLY slow!  It took well over a wall-clock minute to bring up emacs.
I used a cast-off memory from an MRI scanner and made my own interface for it.  That might have been partly responsible for the slowness, but it
was not insanely slow memory.  Probably 650 ns at the Multibus, IIRC.

I did run this until 1986 when I had the oportunity to get a MicroVAX II, which was vastly faster and I was able to obtain more compilers for it.

I then built a 16032-based multiprocessor for our VAX 11/780 at work.  I had up to 7 Multibus Nat. Semi. boards in the same Multibus card cage
with Multibus memory and a DMA interface to the VAX Unibus.  I had to mod the Multibus interface on the Nat. Semi. boards as their hybrid bus interface module didn't have synchronizers for multi-master operation.  Nat. Semi. was good enough to get me schematics of the hybrid, and it
was immediately obvious why it didn't work.  I added several FFs in the patch area, and it worked like a charm!  I added a few instructions to the debug ROM so that if a certain Multibus memory location had a specific 32-bit value, the ROM code would copy a program from the Multibus memory to local memory and execute it.   But, the performance was not great.
With 7 16032's running, it was about twice as fast as the VAX.  That really wasn't worth the trouble of setting up the programs, and the lack of any way to debug the program when it was running.  We did write a journal paper on it, though.

Jon

[Kleinstein]

Oberon looks interesting!  I didn't look at the source tree, but my concern would be the ability to cross build it without an existing Oberon system to host it.  And without building it's impossible to port to my board. 

There is at least one free oberon compiler for the PC (windows). There may be some details from the compilers that may differ (there are at last original oberon and oberon 2), but a compiler should not be such special software using much special features.
The plans for Ceres workstation may be an inspiration in some parts, though it uses NS32032.

[SiliconWizard]

Oberon looks interesting!  I didn't look at the source tree, but my concern would be the ability to cross build it without an existing Oberon system to host it.  And without building it's impossible to port to my board. 

There is at least one free oberon compiler for the PC (windows). There may be some details from the compilers that may differ (there are at last original oberon and oberon 2), but a compiler should not be such special software using much special features.
The plans for Ceres workstation may be an inspiration in some parts, though it uses NS32032.

The OP's concern is definitely valid. I wouldn't know how to build the original Oberon from source at this point.
There is no cross-compiler for the Oberon language that could allow compiling for the NS32k from a PC, at least that I know of. Besides, the Oberon language has known several versions, and you'd need a compiler that supports the version that was used back then. The Oberon language dates back from the 80s originally and has seen a number of revisions, the latest in 2016!

Niklaus Wirth may be happy to help, but I'm not sure he would have any time for this. You may try to contact him: https://ethz.ch/en/the-eth-zurich/organisation/who-is-who/retired-professors/details.NzgxNDQ=.TGlzdC80MDEsMTk1NzY4MzcwOQ==.html

[Kleinstein]

One does not need a special cross compiler. It is enough if a PC based system can compile (and run) the Oberon code for the oberon compiler for the NS32K. The main part is about the language version. IFAIR the difference from the original oberon to oberon-2 were not that large, and I remember a compiler for Oberon 2. I have used is around 2002.

[Ian.M]

There's various contemporaneous PC versions of Oberon in the same archive that claim to run under DOS with a 386, 486 or Pentium processor, 4MB RAM and a VGA or SVGA card.  It shouldn't be *TOO* much trouble to get that running in a VM or emulator. https://github.com/Project-Oberon/DOSOberon
 


 

[neozeed]

I found this thread by accident trying to find my own stuff.  Anyways I thought you may be interested in my prior work:

I took a basic NS32016 emulator added in some basic char IO, and was able to build an Infocom Interpreter that runs standalone in the simulator.

All it needs is to run 100% from RAM, and a single byte port for input and another for output.


I know text links aren't all that interesting but it's 100% cross compiled from my PC and running!

The rest of the info is on my blog:
https://virtuallyfun.com/wordpress/2021/10/01/32016-stand-alone-planetfall/

[jmelson]

I cloned a Logical Microcomputer Systems 16032 Genix system in about 1984.  It worked, but was GLACIALLY slow.  I never really figured out why it was so slow, or did tests to figure out whether it was something in my copy or the original production design.
See :  http://pico-systems.com/stories/1982b.html  for more info on it.  I got a 512 KB memory unit out of an MRI scanner, and interfeaced it to the Multibus, maybe this was what made it slow.
I also put seven 16032 demo boards from NS on a VAX 11/780 as a co-processor, the 7 16032's gave about 2X the performance of the VAX.

Jon