Image Map Image Map
Results 1 to 4 of 4

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. 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
    34,530
    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.

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
  •