Image Map Image Map
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 24

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

  1. #11


    Just a heads up to anyone who might be looking for either some NS32000 family ICs or a complete system, on Ebay UK (might actually be Ebay De) there is a German seller who has listed "National Seminconductor NS32032E, mit 32081, 32082, 32201, 32202, 10 Mhz, 32 Bit"


    It's a buy it now price of around $100 (postage extra). Seems a reasonable price to me. FWIW the CPU is the NS32032E-10 rev H. There's a TCU, FPU, MMU and ICU all rated at 10MHz.

    Some research might show whether it is a known board on Udo's excellent web site.

    Of course the other seller who lists NS32000 series parts on Ebay UK is a company called Little-Diode, whose selection of old devices is impressive, however whose prices are sky high, often 10x the normal going rate (as compared to other sellers).

    I also recently found that some of the "newer" devices such as the NS32FX16V can be found on the UTSource website at reasonable cost. I've never ordered from here, but a friend has and suggested to me that he trusts this site more than Ebay or AliExpress (having ordered via this site).

  2. #12


    I got fake HD63C09 (blacktopped), MC6820 and 2n5109 from UtSource, same quality as Ebay or Aliexpress
    It isn't a reliable supplier (like all Chinese) and it is very difficult to get a refund, you need to send the products back to China and it costs a fortune from France.
    68K Resources :
    French magazines and documentation:

  3. #13


    Regarding viability of the NS32xxx chips, Sequent Computer Systems made their first SMP machines using these (while they waited for Intel to get the 80386 working). I don't know the total number of customers or machines, but they sold them for several years. NASA Ames had one. Many years later Sequent donated their last one to the Smithsonian.
    - Doug

  4. #14


    It's been a while since I last posted. I have been working on some NS32016 software, debugging it using the available emulator (plus my own additions). Soon I would like to try running the software on my hardware which is a set of boards: CPU (NS32016+NS32201); memory (4M bytes organised as x 16); UART (INS16450), with code loaded using DMA controlled by a Arduino MEGA. The board currently runs my hacked version of TDS.

    A short while ago (couple of months?) I installed a NS32202 ICU and updated TDS to do simple initialisation to display a pattern of 0x55 on a LED bar. During this time I discovered a wiring mistake for the ICU databus and added hack wires to fix. I updated the TDS ICU init code to put the device into 32 bit counter mode and I saw a square wave on COUT.

    I want to debug interrupts in order to port my big project code. So a few days ago I fired up the "system". I added a LED on the COUT pin. At some point I noticed that the LED bar was not lit up. I also had problems with the sytem doing random crashes, possibly after it had been on for some time. Note that I currently run the NS32016D-10 (rev N) at 4MHz, and I was using a 6MHz TCU (which got very hot). I swapped this for a 10MHz TCU part and added a small copper heatsink. The system now seems reliable, although the TCU copper heatsink gets too hot to touch. FWIW the CPU is hot and the ICU is warm. I recall reading something about the NS32016 having a minimum operating speed. No idea if this is related to my problems. The ICU is still not displaying the pattern on the LEDs, so I decided to investigate. What a rabbit hole!

    I use a GAL16V8 to decode A23, A22 and A21 to decode 0b111 and connect this to the ICU because it needs to be addressable at 0xFFFE00. The UART decodes A23, A22 and A21 using the 3 chip selects to decode 0b110 putting it at address 0xC00000.

    When I scoped the ICU CS (chip select) I saw some horrid noise. What puzzled me is that I was sitting in a loop (in TDS) waiting for a character to become available on the serial input (connect via a serial to USB adapter and using TeraTerm for I/O at 19200 baud). The ICU CS should have been inactive.

    ICU CS and A21 noise.png

    I sort of figured out what was going on. The UART status register was being accessed in a wait loop. Address bit A21 (bottom trace) was doing something strange and the top address bits 0b110 with a strange A21 were being decoded by the GAL as 0x111 and so generating the horrid ICU CS. I still don't really know why there is the horrible oscillation.

    I found that poking around with my fingers and touching the upper address pins, I could get ICU CS to stay high. WTF!!! I scoped the upper address bits and they were all suspicious as if they were being tristated and were starting to float high. However I use DMA for loading the RAM and I checked that the "HOLD" control from the Arduino was solidly high. Now I do not have a MMU installed so DS/FLT is a data strobe output and not a float bus input. So I as far as I am concerned, and checking the databook, A16 to A23 should always drive. Just for a check I scoped ICU CS and FLT.

    ICU CS and FLT.png

    The traces were a little suspicious. The blips on A21 (not shown) corresponded to the gaps where FLT is high. But it is clearly a data strobe output and can't possibly be floating the upper address bus. So I experimented with adding a 10k resistor to A21 and either GND or VCC. This seemed to confirm that A21 was being tristated. WTF(2)! The next scope trace shows TSO (more or less the same gaps as FLT) against A21 with a 10k pull-up to VCC.

    ICU CS with pullup and TSO.png

    So what on earth is going on? I know that A16 to A23 can be tristated, but if there is no MMU and HOLD is inactive, I would have expected these pins to always drive. Clearly this is not happening.

    What is strange is that a month or so ago, the ICU appeared to be working correctly. The only thing I recall doing was to wire a spare LED in the LED bar via a resistor to COUT, such that if a programmed a large divider value I could see it pulsing slowing and use this as a test interrupt.

    Also FYI, when I single step the intialisation code, I see the 3 writes to the ICU which configure the 8 bit I/O port and I see the LEDs display 0x55, but as soon as I step further and write to the ICU_MCTL register to stop the counter, the LEDs go off and the I/O port seems to go back to tristate. Although the databook is not clear, this register seems unrelated. However after the next few writes I do see a 1MHz waveform on COUT. If I go into "run" mode, and leave the pull-up in place to fix A23(?), there is no waveform. If I edit the ICU registers in TDS (using the cmb command) then I do not see the LEDs lighting. I suspect I still am getting ICU CS when it should be inactive and this is corrupting the ICU registers.

    Any ideas why the upper address bus is going tristate when the CPU is not accessing the bus?

  5. #15


    Much of what you've written is over my head, and I'm not sure this helps, but this collection of bug sheets says that the minimum clock speed for the NS32016-10 is 6MHz (PDF page 16, among other places).

  6. #16


    I don't know the NS32000 CPUs at all, but I'm not sure you can make any assumptions about the state of address lines in between the various control signals going active. There's typically a guaranteed address setup time where they will be valid before the RD/WR, but otherwise I don't think you can assume anything. Are you saying that your GAL activates a peripheral chip select without getting an actual RD/WR or least IORQ signal from the CPU?
    - Doug

  7. #17


    Quote Originally Posted by durgadas311 View Post
    I don't know the NS32000 CPUs at all, but I'm not sure you can make any assumptions about the state of address lines in between the various control signals going active. There's typically a guaranteed address setup time where they will be valid before the RD/WR, but otherwise I don't think you can assume anything. Are you saying that your GAL activates a peripheral chip select without getting an actual RD/WR or least IORQ signal from the CPU?
    I had the same thought. According to pages 17-18 in this PDF there is an address strobe line /ADS which goes low to indicate a valid address. I imagine that would need to tie into the chip select logic.

  8. #18


    Quote Originally Posted by bakemono View Post
    I had the same thought. According to pages 17-18 in this PDF there is an address strobe line /ADS which goes low to indicate a valid address. I imagine that would need to tie into the chip select logic.
    Ah, yes, enlightening. So it's actually a multiplexed data/address bus and one can *only* assume the address is valid while /ADS is active.
    - Doug

  9. #19


    Thank you for the replies. I will answer the items raised shortly.

    Posting to this thread made me think about the problem, just like explaining a bug to a colleague at work. You often see the reason for the bug before your colleague does!

    I now understand the problem with the ICU not working, however the apparent tristate behaviour of the upper address bits is still puzzling.

    For non NS32000 family people, I should have explained that the ICU is the NS32000 family "Interrupt Control Unit". The NS32000 CPU family have an INT (active low interrupt pin) which can be used in a simple way, or as part of a vectored interrupt feature (sort of like the MC68000). The ICU supports the vectored interrupt feature and has 8 (or 16) interrupt inputs, either edge triggered or level sensitive. It can be wired to the CPU in either 8 bit mode or 16 bit mode. In 8 bit mode 8 pins are freed up and can be used as an 8 pin general purpose I/O port. This is what I have done and these 8 I/O pins connect to a LED bar. The ICU also includes some timers, which can be configured as 2 16 bit timers or combined as a single 32 bit timer (this is the mode I am currently using).

    I am puzzled as to why National gave the user two options as I don't see a big advantage of the 16 bit interface over the 8 bit. OK some of the counter registers in the ICU are 16 bit so can be accessed a little easier/faster. I am also puzzled why they didn't take advantage of the AD15-0 (combined address/data) bus which would have saved the 5 address inputs. As compared to other timer/interrupt ICs, I always found this device a little confusing, perhaps not helped by the datasheet.

    The mis-behaviour of the ICU and non lighting of the LEDs was caused by a software bug. My bad! In the very original ICU code I simply wrote to the I/O port. The default/reset mode of the chip is 8 bit.

                                      9784  ;
                                      9785  ;  I C U   R E G.
                                      9786  ;
                                      9787  ICUBASE:  .EQU   H'FFFE00        ; ICU REGISTER  0 ADDRESS
                                      9788  ICU_MCTL: .EQU   ICUBASE+16*2    ; ICU REG 16
                                      9789  ICU_PDAT: .EQU   ICUBASE+19*2    ; ICU REG 19
                                      9790  ICU_IPS:  .EQU   ICUBASE+20*2    ; ICU REG 20
                                      9791  ICU_PDIR: .EQU   ICUBASE+21*2    ; ICU REG 21
                                      9792  ICU_CCTL: .EQU   ICUBASE+22*2    ; ICU REG 22
                                      9793  ICU_LCSV: .EQU   ICUBASE+24*2    ; ICU REG 24
                                      9794  ICU_HCSV: .EQU   ICUBASE+26*2    ; ICU REG 26
                                      9795  ICU_LCCV: .EQU   ICUBASE+28*2    ; ICU REG 28
                                      9796  ICU_HCCV: .EQU   ICUBASE+30*2    ; ICU REG 30
                                      9885  ;;;;;;;;;;;
                                      9886  ; NS32202 ;
                                      9887  ;;;;;;;;;;;
    00004252 PC                       9888          .ALIGN 2
                                      9889  INITICU:
    00004254 PC 54a500c0fffe28        9890          MOVB    0x00,@ICU_IPS               ; ports are I/O
    0000425b PC 54a500c0fffe2a        9891          MOVB    0x00,@ICU_PDIR              ; ports are all output
    00004262 PC 54a555c0fffe26        9892          MOVB    0x55,@ICU_PDAT              ; initial pattern
    This is what I recall working.

    Nevertheless in investigating this problem I discovered the strange upper address bus anomoly and the horrid unexpected ICU chip select.

    Poster @durgadas311 is correct when mentioning the importance of /RD and /WR. I forgot to explain that at the same time I saw the horrid ICU CS, both /WR and /RD were high/inative. So there should have been NO access of the ICU regardless of the chip select to the ICU. I (wrongly) assumed that this was causing the ICU to misbehave when it was a simple PEBCAK software bug. Nevertheless I don't feel comfortable having that waveform of chip select in my system.

    I later added more code to configure the 32 bit timer. In doing so I wrote a '1' to a bit in the register which enables 16 bit databus mode! Further writes are interpreted differently as a consequence and the ICU registers are essentially corrupted. Simply changing this bit to zero resulted in the LED bar lighting and a nice squarewave being seen on the COUT pin.

    00004269 PC 54a502c0fffe20        9893          MOVB    0x03,@ICU_MCTL              ; 8 BITS INTERFACE,COUT OUTPUT,SQUARE WAVE,COUNTER OUTPUT TO PIN COUT
    The MOVB value 0x03 should be 0x02 for 8 bit databus mode. 0x03 selects 16 bit databus mode.

    As to /ADS. This signal is used to latch the address from the multiplexed AD15-0 pins into (usually) 74LS373 8 bit latches. It is generated by the TCU and indicates the start of any read or write cycle. It doesn't need to go into any chip select logic. In this case simply decoding the upper address pins to generate one or more chip selects is perfectly valid, and in fact I see this was done in a National application note for the NS32CG16. Any decoded chip enable also needs the /RD or /WR to be active in order to enable the selected chip/memory.

    As to the comment "I don't know the NS32000 CPUs at all, but I'm not sure you can make any assumptions about the state of address lines in between the various control signals going active" this information is usually well documented in any CPU datasheet, and the behaviour of all pins, as to their input or output state is very well documented. This is particularly critical of any CPU databus, which by it's use switches between input/output/tristate/inactive modes. Since the NS32000 CPUs support various pins being tristated (using the /HOLD input) the behaviour of all affected pins is well documented. There is an added complication for the NS32016 if used with the NS32082 MMU, where the MMU used the CPUs /FLT input to tristate the CPU address in order to put its own translated address onto the main address bus (A24-A16 and AD15-0). In the case of no MMU the /FLT pin is actually an output called /DS (data strobe) and goes low whenever there is a read or write, sort of like the /TSO output from the TCU.

    According to my interpretation of the datasheet, the upper address pins A23-A16 can be tristated, either when /HOLD goes low, or when the CPU is used with a MMU and the MMU forces /FLT low.

    I checked with the scope, and I am seeing the suspicious rising level on the A23-A16 pins when the CPU status from ST3-0 is '0000', which according to the datasheet "0000 - idle CPU inactive on Bus". Hmmm, which bus? AD0-15 bus? AD23-16 bus?

    Wow who would have thought? Perhaps in the idle status cycle ('0000') all data and address pins are really tristated? If this is really true then it isn't clearly documented in the datasheet. I have never seen it mentioned in any NS32000 documenation.

    So poster @durgadas311 IS 100% correct with his statement "I'm not sure you can make any assumptions about the state of address lines in between the various control signals going active". I would have put money on the upper address bits always driving, even with the bus idle. I had assumed that the upper address bits would always drive (even during idle cycles) as this is what I have observed on other micros. Wow! Colour me embarrased!

    I think that this now explains the upper address bit behaviour, and I need to consider adding pull-ups/downs, as a floating address bus is never a good thing.

    Thank you for helping me think more clearly!

  10. #20


    I noted the reply from @bakemono , which caused me to look at the NS32C032 datasheet. The PDF was searchable and I searched for idle and found some interesting references I hadn't previously noted in my paper NS32016 databook. So I then moved to the more applicable NS32C016 PDF which was also searchable.

    It's still not 100% clear to me, but there are mention of idle states, both in reference to going into tristate after asserting /HOLD (this idle seems to be called Ti) and also as a result of the MMU asserting /FLT (this idle seems to be called Tf). I'm not sure if Ti and Tf are the same thing. Again I assume(!) that these idle states are the same as when I saw the ST3-0 pins as "0000" on the scope.

    I now have found in the paper databook, figure 4.6 (figure 4.7 in the PDF) "Floating by /HOLD Timing (CPU initially idle)" where it shows a couple of Ti states, both AD0-15 and A16-23 are clearly shown as "FLOATING".

    This does appear to confirm that when the CPU is in the idle state, the upper address bits are tristated. This really surprises me!

    [NOTE: I am still under moderation. Yesterdays posting was posted immediately, todays earlier reply told me that it needed to be moderated, so not clear whether this reply will appear before today's earlier posting, which will help this posting make more sense.]

Tags for this Thread


Posting Permissions

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