Setting up all the I/O pins would be one of the first things done in the program after the oscillator has started and /RESET has gone high.

Pin 16 input is used only for the clock and for checking whether the mains power has disappeared when it tries to do a properly sequenced close down if it's active.

The program was definitely written in assembler but I doubt if the source code still exists. For some information about the development of the Beomaster 6000 have a look at:

https://beomicro.wordpress.com/beomaster-6000/

Also have a look at Appendix 8 and 9 on the same site.

 

 

Thank you for the link to the BeoMicro webpage. I've read a few of the pages so far and find the site very interesting. I expect that I'll eventually read the entire site.

Regarding the BM6000 start-up, what the pins do at start-up may depend on how the CPU was configured when ordered. There were multiple options as shown in the diagram below from the CPU data sheet. Interestingly, on the Appendix 9 page of the BeoMicro site, the engineer comments on this topic.

Login to view image

I assume that CPU was configured with the standard or direct-drive output due to lack of external pull-up resistors (needed for the open drains) on the BM6000 board.

At this point in time, I'm just trying to figure out if I have a functional CPU versus a working CPU that is being faulted by something not working right on the board.

My latest experiment is to run the CPU on its own connected to a logic analyzer to see if I can learn anything from how the signals initialize or change. I would expect that direct-drive outputs controlled by the assembly code to behave slightly different than standard outputs. I may not learn anything from the experiment, but I'm not sure what else to try.

Glitch

 

 

I think I've been able to convince myself that the CPU is bad. I ran the logic analyzer test and the results were inconsistent. I expected that with a clean and simple test setup that the CPU behavior would be very repeatable. It wasn't.

Below are a few scope captures with just power and ground connected and the various outputs monitored. The capture was triggered on the 5v power signal rising.

Most of the time I saw this...

Login to view image

However, other times I saw different behavior

Login to view image

Login to view image

Login to view image

The only consistent thing I noted was, at some (random) time, all of the signals would simultaneously go to zero.

I repeated the test with a 50/60 and TimeBase signals provided by a waveform generator. These results were also inconsistent.

Login to view image Login to view image

I saw many other signal combinations. The only trends noted were that signals would not change after some (random) period of time and the outputs seemed to change in groups of four.

I also ran some traces to see if I could identify the output configuration type.

Login to view image

I think this plot tells me that the outputs are the direct output type and initialized by the software. I would expect the standard output type to all initialize simultaneously with the power signal.

Unless I get any more suggestions, I will give up on the CPU and move on to "plan B" for the BM6000

Thanks again to all that provided suggestions,

Glitch

Did you have a crystal oscillator on pins 1 and 2? The /Reset signal shouldn't really be pulled high until after the 5V and XO are stable. It looks as if Reset goes high just before 5V, but perhaps that is deceptive.

Since the 3870 has no instructions for individually addressing the port pins it's normal for all pins on the same port to be set at the same time.

I have an unused sample of the CPU but don't have the means or equipment to set it up and test it. And I don't have a Beomaster 6000 to compare signals, either.

I have tried running this latest set of tests both with and without the crystal. I removed the crystal and capacitor from the BM6000 board and used this for the external test. I have some reservations about running this in a breadboard setup, but it is what it is.

My logic may be flawed, but running without the crystal should give an indication of how the I/O initializes from purely a electrical circuit standpoint. With the crystal, I would expect to get an indication of what the software is doing. I don't really know what happens in the grey area in-between the two, or if there is a grey area. My recollection is that microprocessors of this era just started running whatever op codes were stored at address 0x0000 when powered on.

In the traces posted earlier, the reset signal is simply tied to the power signal. I know that this is not the ideal situation. I would have rather been able to generate a delayed signal that was triggered from the power signal, but I don't think that it is possible with the test equipment that I'm using. If the RESET signal looks early, it is likely an anomaly related to how the test equipment scans or displays the signal.

I did a quick test by manually changing the reset signal (plugging in a jumper on the breadboard).

Login to view image

Except for the FreqCount signal, all of the signals usually remained unchanged. The FreqCount typically goes high for a random period of time, then returns to zero. I'm not sure what to surmise from this behavior.

I expected to see the outputs update as a group (of 8), but not all of the bits being the same value. For example, in the Data Strobe set of signals, I expected to see something other than 0 or 7 (all zeros or ones), which would indicate that the software was polling the keyboard or setting a particular LED display.

I don't have any real experience with trying to debug a faulty CPU. Typically, at work, if a circuit/CPU was acting flaky, we trashed it and replaced it with a new one, or sent it back to the hardware group that likely did the same.

I didn't expect my bench test to produce the behavior of a properly functioning CPU in a BM6000. It would be a very difficult to replicate the exact timing of all of the signals such that the diagnostics were happy. I did expect that the results from a given test would be fairly repeatable.

It seems like the CPU is running random assembly code. So far, it has not hit a HCF opcode, but it feels like it is just a matter of time ;-).

Glitch

 

Since there's really nothing happening on the outputs after /Reset goes high it would seem that the program code is not running at all.

Sorry, I'm out of ideas for things to try.

I'm also out of ideas of what to try relative to the CPU. I've been able to test (most of) the rest of the receiver and aside from a few LEDs being dead, it still works pretty well. It has been a long time since I've listened to this piece of equipment. I forgot how nice it sounds, with a smooth, mellow quality that is hard to describe.

Can anyone comment on the availability of replacement CPUs?

My assumption is that they are generally unobtainable and the best bet is picking up a microprocessor  board from a unit that is being parted out (that may or may not have a similar problem).

Did you ever figure out if the CPU was dead on your 6000? Mine exhibits the exact same symptoms, unfortunately.

quattttro:  I think I was able to prove to myself that the CPU was indeed dead. I ended up swapping the bad CPU into another BM6000 and the main issue followed the CPU. I still have a mystery to solve since the original machine does not work properly with the "good CPU" from the other machine.

Have you checked the 5v-cpu and 5v voltages on Board 2?  Have you replaced 2R89 and readjusted the RESET circuit?

Glitch

yes, 5v CPU (pin 39, iirc) and the other voltages are all exactly as noted in the service manual. I did try to adjust the reset circuit, but I get 0V across R92. I'm not really sure why that is.