• Please review our updated Terms and Rules here

CMB PET 3032 ( 2001N BOARD )

daver2 said:
The results we have obtained from swapping the two banks of 16K over are completely inconsistent.

With the 'I' bank we get one good page and one completely bad page (the value returned is always $2E for this page). This would imply a multiplexer or an address line.

However, the 'J' bank exhibits a completely different fault scenario.

If it was a multiplexer, or an address/data buffer, then I would expect that fault to be applicable to both banks of RAM - as it is external to the RAM. But it isn't.

I must admit that the fault does imply that the DRAM is at fault...

Now, you did check the power supply rails for both high and low frequency noise didn't you @Desperado? If we have noise on the power rails (especially the +12V and/or -5V) then we are chasing ghosts!

The other possibility is a timing fault in the signals driving the multiplexers. We haven't checked these yet, and they should be a simple check with the oscilloscope.

I am also not happy why my little test program didn't seem to work. Did you take the signal measurements I asked for or not?

Dave
Click to expand...
I haven't checked them anymore because the characters weren't the ones you indicated...
 
>>> I haven't checked them anymore because the characters weren't the ones you indicated...

The reason I wanted you to check the signals I asked for are to gain an understanding of WHY we were not getting the characters we were expecting.

Is the CPU executing instructions or not? Is the CPU accessing the correct things or not?

Dave
 
daver2 said:
>>> I haven't checked them anymore because the characters weren't the ones you indicated...

The reason I wanted you to check the signals I asked for are to gain an understanding of WHY we were not getting the characters we were expecting.

Is the CPU executing instructions or not? Is the CPU accessing the correct things or not?

Dave
Click to expand...
Ok this evening i'll check these signals.....do you suspect bad ram ics again??
 
>>> But if we have good rams and good multiplexer, where could the fault come from?

When we are using Nivag's RAM (on the ROMulator) then the PETs DRAMs and multiplexers are irrelevant.

What I want to know is whether my test software has failed for some reason (i.e. I have written it incorrectly).

If may be why the first two characters on the screen are not what we are expecting - because the software is not actually running correctly!

We will only get what we are expecting if the software is doing what it should...

This is why we need the measurements...

At the moment I am not looking for a PET fault. I am trying to work out why the test is not working correctly as it should...

Dave
 
Please sir Dave, i re inserted eprom with your program in ud9....need i set allo Rom links to OFF and Ram ON before take measures?
 
I am suspicious there is another problem present too, aside from the DRAM because Daver2's program didn't work properly with the Romulator's RAM. It is important to find out why that is.

( In the system I use which also makes the DRAM & multiplexers irrelevant, for the lower 2k of memory range, it becomes obvious if there is any other problem in the computer, other than DRAM faults, because the computer should boot to BASIC and run small programs. If it doesn't, then whatever is causing that needs to be remedied first before examining the DRAM because whatever that is would prevent proper examination of the DRAM).
 
>>> I am suspicious there is another problem present too, aside from the DRAM because Daver2's program didn't work properly with the Romulator's RAM. It is important to find out why that is.

That is exactly what I am thinking. Great minds think alike.

We have had a few 'strange' events happen during this repair - with none of them being diagnosed fully. They came, we all got desperate, and they disappeared just as quickly on their own...

Dave
 
daver2 said:
>>> I am suspicious there is another problem present too, aside from the DRAM because Daver2's program didn't work properly with the Romulator's RAM. It is important to find out why that is.

That is exactly what I am thinking. Great minds think alike.

We have had a few 'strange' events happen during this repair - with none of them being diagnosed fully. They came, we all got desperate, and they disappeared just as quickly on their own...

Dave
Click to expand...
I wonder if putting something like a delay loop in the program would help say to "see the program running" on the screen. For example plot the first two characters, wait half a second, clear the screen, wait another half second, re-plot the characters etc etc. So it would be obvious that the program is looping and whether or not the two characters were stable each time they were plotted ?

I think desperado said they were changing ?
 
>>> I think desperado said they were changing ?

He stated that they were different every time he turned on the PET - implying that this entire screen is just the initial power-on random screen.

If this is the case, my firmware is not even running.

CPU pin 7 (SYNC) and UD8 / UD9 pin 20 will tell us this.

CPU pin 7 will tell us the CPU is (still) fetching and executing instructions.

UD9 pin 20 will tell us the CPU is executing my firmware (in the kernal ROM socket).

UD8 pin 20 will tell us my firmware is doing something sensible! I use a dummy read from the ROM in UD8 to trigger the oscilloscope from - so we should see pulses on this pin if the firmware is working correctly.

If all of the above looks good - we should be able to check for video RAM writes and DRAM reads and writes (although Nivag's RAM is being used in reality).

It is amazing what you can learn from a few bytes of program!

I used to write test code for our operational machines... These were core store machines, with a 2 MB hard disk that was 1m in diameter with 100 fixed heads and a very beautiful head switching unit (I am led to believe this is still under the computer room false floor). This was all hardware to select the correct disk unit, track, hard sector and DMA the data into (or out of) the core.

Likewise the vector graphics units used core store to store both the graphics commands and the character set vectors. They were a digital/analogue hybrid - so had operational amplifiers to draw circles! You would have liked the electronics :)! I wish I had the foresight to have saved all of this equipment though... It was all replaced - although I do know where there are some units still in existence - I saw one on Tuesday when I went to a supplier's premises.

Dave
 
Last edited:
Is this the case when you press the reset button on Nivag's board - or do you observe a quick set of pulses before it dies?

Dave
 
daver2 said:
I have done this work before :)!

Dave
Click to expand...
Not dissimilar to my sort of hardware equivalent of this, where I made an address decoder with a ROM, to decode the entire PET address range for ROMs, RAM etc, and stuck that as an add on to my NOP board. That way I could trigger the scope and look at things happening with the other scope channel in the specific address range.
 
daver2 said:
Can you use your logic probe please. That is a better tool for this. It stretches the pulses so you can see them...

Dave
Click to expand...
Yes, with logic probe i see one little pulse ( yellow led ) when i press reset button
 
You must log in or register to reply here.
Back
Top