Image Map Image Map
Page 1 of 3 123 LastLast
Results 1 to 10 of 24

Thread: NS32000 Series Family Thread (porting TDS to a NS32016 user wire-wrap board)

  1. #1

    Default NS32000 Series Family Thread (porting TDS to a NS32016 user wire-wrap board)

    I hope it's OK to start a new thread. I previously posted to a more specific NS32016 board (PD32) in another thread.

    I'm not exactly sure why, but my interest in the NS32000 family has been re-awakened recently. FYI, I worked for Nat Semi from 1982 to 1986 (in the UK), but spent the whole of 1985 at the headquarters in Silicon Valley. I worked on the test systems and did some characterisation work on the NS32016. Just for the record, at that time, the NS32016 (and family) were tested on the Genrad GR16 VLSI tester. I heard a rumour that Atari has considered using the NS32016 in the Atari ST. I am still gutted to this day that they chose the 68000!

    At the time I got my hands on a small number of parts. In 1986/7? I built a wire wrap board for a very basic NS32016 system, and wrote a simple boot loader. Ironically I used an Atari ST and wrote an asembler in Pascal. Otherwise I didn't move the project forward. Fast forward to 2019 when I got the old board out. I generated schematics in Kicad and disassembled the boot loader, only to find a bug caused by my old assembler. A second bug limited the amount of code to be loaded over the serial link (INS16450) to less than 255 bytes. I wrote a new assembler in Perl and played with a 2nd stage boot loader. I'm not sure but I think that the hardware was a little flaky, so again I didn't make much progress.

    I recently found the PD32 thread on this forum and it may have kick started some renewed interest. I also started playing with various tools recently found on the internet. I was able to get the DSI compilation tools to run and the code could be run on the NS32016 emulator. Now I have always wanted my board to run the TDS (Tiny Development System) software, but I have never found a ROM dump. I would have had to disassemble it, in order to change the UART code from the INS8251 to the INS8250/INS16450. So I tried to assemble the source code to TDS. This worked but I couldn't figure out how to link to a ROM binary. So I merged all 10 modules together, and started to modify my own Perl assembler to add support for the Genix assembler directives. I also modified the output listing format to be the same as the Definicon/Genix assembler. There were a number of issues to solve, such as module name clashes, but I was finally able to generate binaries and blow 27128 EPROMs with the code.

    I then took me about 10 iterations until I had something working. There were a mixture of hardware and software "bugs" to fix. My board had 2 x 6264 RAMs (8k x and 2 x 27128 EPROMS (16k x . The first code crashed. I used the 16 channel logic analyser on my scope to follow the code (using the AD bus for address and data, and CS for a scope channel) and found it crashed after a jump into high memory. The FF's were unexpected, but then I realised that I had tied off the upper ROM address bit so that only the first half of each EPROM could be accessed. Brought about due to using as LS139 to decode each 16k bank of memory (but the EPROM was 32k). So I ORed two of the LS139 outputs and wired up A14 to the EPROMs. Now the code ran and printed a sort of welcome banner. I forget everything I had to debug, but I had to write link tables for traps and module tables. I also found that "main" needed it's own module pointed to by SB otherwise on return from a SVC call, SB was loaded with random data!

    I added circuitry to single step using a Arduino Mega2560 as a bus master. This has been quite interesting, particularly when executing the more complicated instructions, which do things in a slightly different order to that documented. This has been vital in tracking down the various bugs for each of the ten ROM releases.

    Anyway after 30 odd years I can finally run TDS on my own hardware. I was able to type in the program from the user manual and get it to assemble, but the system crashed when trying to run the code and of course I lost all the source code. I intend to add a Flash EEPROM to use as "tape" storage, as a solution to losing source code on crashes.

    More information here.

    I'll post updated pictures to twitter and give a pointer.

  2. #2

    Default

    Hi ...

    you Link has a error

    better: www.cpu-ns32k.net/Gary.html

  3. #3

    Default

    Folklore suggest the the N32 series chips were buggy and flakey, and that was one consideration that vendors used to not select them. Do you (or anyone) know anything about that? How it was manifest? Was it a batch error for some specific chips, was it systemic, etc.? Did the chip ever get sorted out or just run over by history.

  4. #4
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    36,002
    Blog Entries
    18

    Default

    I think bugs were present only on the initial 16032/32016 chips, which were very late (I started talking about them to the NS guys in 1979).

    I think that the later chips, as used in laser printers (NS32CG16), etc. were pretty solid.

  5. #5

    Default

    I regularly search for "NS32016" just to see if any new information has appeared. I read somewhere a similar statement regarding reliability, but I have no idea where the source of that "rumour" came from.

    I did download a very useful errata document. My NS32016 CPUs are 1985 vintage rev "M". I was a little shocked at the length of the errata, but perhaps for such a complicated CPU we shouldn't be too surprised. Some issues sound like they stem from timing issues inside the chip. Nowadays there are very powerful STA (Static Timing Analysis) tools which can help find these issues well before tape-ship/tape-out.

    I do recall a rumour (1985) that 10MHz yield wasn't as high as would have been liked, and that it might have resulted from critical timing between the NS32201 TCU and the NS32016 CPU. At that time the CPU worked on 2 phase clocks (I worked on similar architecture chips at a different company a few years later) which introduce these critical internal timings. I've always wondered if skewing the various phi1/phi2 clock edges might eek a little more speed out of the CPU. Nowadays similar designs all use D-type flip flops clocked from a single rising edge (sometimes the neg-edge is also used but the quantity of these flops is a small percentage - at least on the products I recently worked on).

  6. #6

    Default

    Just stumbled across this thread. Since you worked for NS in the UK in the early/mid '80s, did you have any interactions with people at Whitechapel Computer Works?

    You might be able to shake hands with the Rev. N NS32016 in our WCW MG-1 if you visit port 31132 of mg-1.uk in your web browser (not linking to keep the spiders away). It all depends on whether the RasPi I'm using as a wifi bridge feels like talking to the home router. (Often it does not.) Even then, response time may be even slower than you'd expect, since right now I'm running disk I/O intensive jobs in order to help debug the MFM drive emulator we are using

  7. #7

    Default

    Quote Originally Posted by stepleton View Post
    Just stumbled across this thread. Since you worked for NS in the UK in the early/mid '80s, did you have any interactions with people at Whitechapel Computer Works?
    No. I had no contact with any customers because my job role was "test".

    BTW I did try to connect, but couldn't figure out the URL. There are pictures on Udo's website, and I tried the URL captured in the image, but still no luck.

  8. #8

    Default

    So I have been busy on NS32016 related projects.

    I have created a NS32016 CPU board, which implements my single-in-line connector for easy use in plug-in breadboards. I also generated a mk2 version of my RAM card, and I also made a backplane (since it was getting painful using wire links on a breadboard!). Pictures can be seen on my twitter account "migry_tech". I tried uploading a JPG but it was too big I will try to find a way to resize and post later.

    I am now playing around with the NS32016 GCC cross compiler. I will be posting some questions in the near future!

    Anyway over the weekend I debugged the CPU board. I was able to load some C code compiled with GCC into the SRAM and execute it on the NS32016.

    Just some background. Over the past 6 months I have been playing with the MC68000, since I have fond memories from my Atari ST ownership days. My interest was kicked off by the "Katy" project. I built up my own version on breadboards, but found the wiring up tedious. So I used Kicad in anger for the first time and made a single-in-line memory board PCB. I later followed this up with a MC68000 DIL and then a PLCC single-in-line board. I used breadboards to hold the boards and wired between them. So I have a CPU card and a memory card and also my own FPGA card (on which I have implemented video). I use an Arduino MEGA2560 as the bus master and it uses DMA (slowly) to load the binary into the RAM (there is no ROM). Using the Arduino I can run or single step, load memory from SD, and peek and poke. During tracing I disassemble the executed code. This allows me to see where I am in the C source.

    So the NS32016 board works in the same way. I implemented tristatability of the bus and the Arduino can put the CPU into HOLD, which tristates the address latches and databus buffers. The upper address is tristated by the CPU. I use a GAL to tristate ADS, HBE, RD and WR. The other GAL handles single stepping. Ironically I made a error soldering in two adjacent SMT resistors. I soldered them left/right instead of up/down. Once corrected I still had problems. I had wired RWEN to +5V instead of GND! Easily fixed however thanks to using a resistor rather than a hard tie. The bug tristated RD and WR, making me realise I could have eliminated the 2nd GAL (which essentially tristates a few signals from the edge connector bus).

    Today I hacked together a INS16450 UART board, which I am just about to test. I hope to then get my version of TDS to work on this new setup. It is already running on my wire wrap board.

    More later...

  9. #9

    Default

    Quote Originally Posted by migry View Post
    No. I had no contact with any customers because my job role was "test".
    I mean this question quite sincerely and not as a dig: given that the NS32016 had a reputation for bugs, at least in early revisions, did your test role have much to do with finding those errata or identifying workarounds for them?

    BTW I did try to connect, but couldn't figure out the URL. There are pictures on Udo's website, and I tried the URL captured in the image, but still no luck.
    I'm feeling bolder now, and the RasPi seems to be working okay: visit http://mg-1.uk:31132/

  10. #10

    Default

    Quote Originally Posted by stepleton View Post
    I mean this question quite sincerely and not as a dig: given that the NS32016 had a reputation for bugs, at least in early revisions, did your test role have much to do with finding those errata or identifying workarounds for them?
    Simple answer - no! I was new to Nat Semi, in fact it was my first job. I got to spend 6 months at the headquarters in Santa Clara (Silicon Valley), which was quite an experience, both good and bad. I worked on the VLSI testers, the machines that test each IC to confirm that it is not faulty, that is not the same as the validation function, which checks that the device operates against it specification. What the tester is able to do however, is to measure the AC parameters to confirm that the AC specifications on the datasheet are met. This includes FMAX. I recall that the test software first tested each CPU at 10MHz, then if any "patterns" failed, changed the timings to 6MHz (I don't recall) and re-ran all test patterns (known as speed binning). I was not privy to any detailed test issues, but I sort of recall that 10MHz yield was a major issue and had something to do with the timings of both the TCU and CPU.

    I think that the 32016 family was designed in Israel (but I was unaware of that at the time). The testing was certainly done in Santa Clara. As to where the silicon validation was done, I have no idea. Nevertheless the fact that even at that time the 32016 CPU rev was N, speaks to the number of silicon problems that must have been found. Also remember at that time CAD tools were primitive (if they existed at all) as compared with todays design flow. I am guessing that most if not all of the design must have been done by hand, including layout (no auto-routers back then AFAIK).

    Quote Originally Posted by stepleton View Post
    I'm feeling bolder now, and the RasPi seems to be working okay: visit http://mg-1.uk:31132/
    Thanks. This site is working.

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •