• Please review our updated Terms and Rules here

CBM PET 710 WITH BASIC PROBLEMS

And TRIG.ALT button. IN or OUT?

Can you post the manual then (if you have a scan of it)?

I am interested in the operation of the MODE switch.

>>> Time to move trigger probe on Gnd, isn't?

Why, this just displays a horizontal line... To what end?

>>> Need i buy a new digital scope

You cannot handle an analogue oscilloscope at the moment. Until you are able to do, buying a digital oscilloscope will confuse you even more.

If you can't drive a Fiat car correctly, there is no point in buying a Ferrari...

Dave
 
Ok this is the manual of my bad bad scope :(
 

Attachments

  • scope.pdf.zip
    6.5 MB · Views: 4
I would set the TRIGGER MODE switch to "NORM".

In this mode, if there is no trigger - the oscilloscope will NOT display anything UNTIL it gets a valid trigger signal.

In the AUTO mode, the oscilloscope will revert to 'free running' if it does not see a valid trigger signal. This can confuse you as you will get a trace whether the oscilloscope is synchronised to a trigger or not. If not, we are wasting our time...

Set the oscilloscope to single channel (on the channel that you are connecting the trigger input to) and adjust the TRIGGER LEVEL control until the channel triggers (i.e. you see a trace when in NORM mode).

Then switch the oscilloscope to dual channel mode and take your measurement with the second channel.

There is nothing wrong with your oscilloscope or the manual (Ok, it is not quite English - but it is better than other manuals I have seen)!

I started off with a very simple oscilloscope (single channel with no bells and whistles). That helped me repair numerous pieces of equipment (not a computer though).

Dave
 
Ok thanks Dave, now i have this trace
 

Attachments

  • 1711818894309..jpg
    1711818894309..jpg
    1.1 MB · Views: 4
  • 1711818908763..jpg
    1711818908763..jpg
    1.2 MB · Views: 3
In fact, if you study the manual, it contains a reasonable description of most of the oscilloscope controls and how they work...

What you need to do is to devote an hour a day (say half an hour of reading and theory - and half an hour of practice) to learn what each control does and how to use that facility facilities.

The only thing(s) I would change about the table on section 4.3 would be:

ALT/CHOP - pressed IN (CHOP).
VOLTS/DIV to 1 V/DIV (if working on digital logic circuits).
VOLTS/DIV to 5 V/DIV (if working on analogue circuits).

You can adjust the VOLTS/DIV based upon what you observe.

Dave
 
the tracks are always the same and terrible... either this Nop is no good or the CPU is really dead :(
 
Honestly, these traces are making me feel like I’ve been taking crazy pills. If I had any compatible ROMs at hand I’d be tempted to make a NOP ROM for my PET and see if I could get a decent trace off it, because this still feels like something is wrong with the triggering here. Putting the trigger on the highest address line *should* give you a reliable timebase; that is a reference that will complete a full cycle once per iteration, and regardless of whether you triggered on the high or low slope the instructions following that transition will consistently be 2-cycle NOPs. (Over 4000 of them after each transition.)

I chucked out the idea earlier of building a single-stepper, that’s sounding less dumb to me.

I believe what is messing up the expected regular pattern on the address signals is the DRAM refresh. If I understand the schematics on page 3 correctly, after each 20 clock cycles the CPU is halted for a refresh cycle by pulling the RDY line low. I am a bit hesitant to exchange the EPROMS in my CBM 720 for trying out your NOP eprom, but instead I connected a logic analyzer to the relevant signals on CN6 to monitor the boot process just after /PROCRES. You can see the reset vector being fetched, and the first instructions executed, interrupted by the refresh cycle.
 

Attachments

  • cbm720_boot_sequence.png
    cbm720_boot_sequence.png
    127.9 KB · Views: 3
Unfortunately you don't know whether it is the chicken or the egg...

If the CPU is faulty it will probably not execute the NOP EPROM correctly.

If the NOP EPROM is faulty, the CPU will not receive valid instructions.

Both the CPU and NOP EPROM could also be perfectly OK - and it is something else (a faulty or marginal piece of hardware) that is causing the problem.

I think this fault is currently way outside of your sphere of knowledge and test equipment to tackle.

I would have got out a very expensive piece of HP logic analyser by now and instrumented up the CPU with a whole load of probes to see exactly what it was doing on start-up.

An oscilloscope is not the piece of test equipment of choice for this fault I am afraid.

You have to know when to stop...

Dave
 
Unfortunately you don't know whether it is the chicken or the egg...

If the CPU is faulty it will probably not execute the NOP EPROM correctly.

If the NOP EPROM is faulty, the CPU will not receive valid instructions.

Both the CPU and NOP EPROM could also be perfectly OK - and it is something else (a faulty or marginal piece of hardware) that is causing the problem.

I think this fault is currently way outside of your sphere of knowledge and test equipment to tackle.

I would have got out a very expensive piece of HP logic analyser by now and instrumented up the CPU with a whole load of probes to see exactly what it was doing on start-up.

An oscilloscope is not the piece of test equipment of choice for this fault I am afraid.

You have to know when to stop...

Dave
You're right Dave, I don't think I can fix it. What I regret the most is that before deleting the EPROMs, it worked...

Maybe we can try with the last attempt? I remember that Eudi talked about programming an EPROM to activate the SID...
 
I believe what is messing up the expected regular pattern on the address signals is the DRAM refresh. If I understand the schematics on page 3 correctly, after each 20 clock cycles the CPU is halted for a refresh cycle by pulling the RDY line low.

I thought at some point we’d already scoped the RDY line and verified it wasn’t pulsing? A regular pulse on the ready line would be a smoking gun for DRAM-related baffoonery.

FWIW, I had noticed the DRAM circuitry *could* pull ready low, but I hadn’t dug into whether this condition would *always* be periodically happening, or if RDY would only go low if the CPU tried accessing DRAM during a refresh cycle. (The DRAM subsystem is behind a separate data buffer, so refresh activity behind that in theory at least wouldn’t have to wait the CPU if it’s just working away in bank 15.)
 
I would have said it was more sensible to program the 6526 user port at U11 and output a continuous counter from 00 to FF.

This will be a very short routine in the EPROM.

If it doesn't execute that we are in trouble...

Dave
 
Programming the SID to make a wavering scream should be pretty easy (need to have some kind of variation in it to make sure it’s not just turning on a tone and crashing). I just don’t think I’m the best choice to do it, as I know nothing about the SID and when I googled for simple assembly examples for it (which of course will need translation in terms of ports, etc, because they’re all for the C64) all I could find was the source for complex chiptune players. There’s a limit to how invested I can get here.
 
The commodore emulator VICE has a B-series emulator and there are complete 6502 cross-compiler suites like xa65 that make it “not that hard” to build and test diagnostic ROMs; this is how I built my first crude PET diagnostic ROM a decade ago, the Paleozoic ancestor to PET Tester. If you want to build a SID noisemaker ROM the tools are right there.

The problem at this point is almost nobody else has one of these machines (I sure don’t) so there is ultimately a limit to what we can tell you to do “blind”; if I spend a few hours myself making a SID noisemaker that works in VICE (which I don’t have time to do this weekend, for sure) I can’t make any absolute guarantee that it would work on a real machine.
 
... I'm sorry if that sounded a bit harsh, BTW. It just... is what it is.

I dug around in my digital basement and found that old PET testing code I wrote, if you want to take a break from this for a few days I'll see if, when I get a quiet moment or two to fiddle with it, if I can merge some of the bits from that with the stub of code I'd gotten to make the emulator at least make a sad "fwuop" noise and see if I can make it do something more sensible, like run up and down a scale.

There will be this perpetual gotchya here that unless someone's willing to try the same code on their known working B-series we can never be quite sure if it doesn't work if it's because yours is broken or because there are things VICE doesn't know about them and gets wrong.
 
Back
Top