• Please review our updated Terms and Rules here

Cbm 2001 Pet strange boot

Well, yes and no... Let me explain...

Piggybacking TTL devices will ONLY work of the faulty/stuck bits are a logic ‘1’.

If the faulty/stuck bits are logic ‘0’, then the piggybacking technique will not work.

So you may have a faulty 244 buffer pulling an output to logic ‘0’.

If you had a two channel oscilloscope with a bandwidth of at least 150 MHz with the capability for an external timebase trigger you can identify these sorts of problems quite easily. You trigger the oscilloscope off the appropriate buffer enable signal - and use the two input channels to monitor the input and output of each buffer gate in turn. The output should follow the input (for a non inverting buffer) and should be the opposite (for an inverting buffer). This takes all the guesswork out of diagnosing faults.

You are now repairing a significant number of computers (which is a good thing), but you need to invest in some better diagnostic tools.

If you plan to continue, looking at something like a 4 channel oscilloscope with either an 8 or 16 channel logic analyser (or the ability to be upgraded at some future date) would be the way to go.

Worth thinking about, along with spending some time reading up (and experimenting) on a known good machine to get to know how to use it.

Dave
 
daver2 said:
You’ll have to wait for Nivag to respond on that...
Click to expand...
a) No idea; my guess is that there is something that has failed since earlier testing or something intermittent.
b) The F800 version of PETTESTER is the same source with a little bit of extra conditional code to relocate it. The source is included in the earlier .zip in Post #201. It has identical behaviour except it checksums the E000-E7FF region as that should contain the edit ROM and also the F000-F7FF region because that potentially could contain the low kernel.

@daver2 is there any chance you could use github for pettester? I could fork and send you a pull-request.
 
Last edited:
>>> No idea; my guess is that there is something that has failed since earlier testing or something intermittent.

My guess would be the same - more leaning towards an intermittent problem. Usual suspect - check the soldering around the two devices I identified.

>>> is there any chance you could use github for pettester?

I will use github for V5.

Dave
 
Incidentally although there are now three versions of PETTESTER flying around in this thread it is still easy to tell them apart... The Kernel relocated version of PETTESTER shows an E= Checksum, the original does not.
The UD9.bin shows F=DD67 and the UD9_bodged.bin shows F=BA4E. When Kernel Version is UD9 and original PETTESTER version is in UD8 it should show E=75DD, when the correct edit-2-n.901447-24.bin is in UD8 it should show E=FDBF. Just sayin'
 
There is (was) another version as well. I did a bodged version of my standard EDIT PETTESTER to skip the video RAM test if it failed.

I am looking for a 'portable' way (across all PETs) to cause it to skip the video RAM test if desired for version 5.

This is why (I believe) we are all getting confused. Labelling the ROMs Alice, Bob, Charlie and Dave may help :) !

Dave
 
It can get confusing along the way if more faults crop up and paralysis sets in.

I think the best move at this point is to:

1) Make a standard set of ROMs that are known to work using the 2532 and 2716 types.

As pointed out here in this thread, the files for these are available on zimmers:


2) Replace all of the ROMs together, the Kernal ROM, the Edit ROM and the two BASIC ROMs and also replace the Character ROM.

(Don't try any hacked ROMs or ROM variants, just standard files from the Commodore originals for the Dynamic PET).

This way you can then be 100% sure you are not sitting on any residual ROM problems.

When that is done, take a fresh approach to fault finding the computer from scratch, as if it is a machine you are initially trying to repair.

Only after the computer is working, try to substitute originals ROM's or other ROMs back in, one at a time, to verify they are ok, or not.
 
Hugo Holden said:
It can get confusing along the way if more faults crop up and paralysis sets in.

I think the best move at this point is to:

1) Make a standard set of ROMs that are known to work using the 2532 and 2716 types.

As pointed out here in this thread, the files for these are available on zimmers:


2) Replace all of the ROMs together, the Kernal ROM, the Edit ROM and the two BASIC ROMs and also replace the Character ROM.

(Don't try any hacked ROMs or ROM variants, just standard files from the Commodore originals for the Dynamic PET).

This way you can then be 100% sure you are not sitting on any residual ROM problems.

When that is done, take a fresh approach to fault finding the computer from scratch, as if it is a machine you are initially trying to repair.

Only after the computer is working, try to substitute originals ROM's or other ROMs back in, one at a time, to verify they are ok, or not.
Click to expand...
Ok but Pettester can run also without other rom ics inserted, right?
Thanks
 
Dave_C78 said:
Ok but Pettester can run also without other rom ics inserted, right?
Thanks
Click to expand...
I'm not 100% sure but I think the Pettester requires at least a good Kernal ROM, but Daver2 would better answer this question.

At least, if you have a known good set of standard ROM's, it will simplify the fault finding.
 
My PETTESTER ROM lives at a base of $E000 (so it can replace the definitely socketed EDIT ROM). This does require the Kernel ROM (at a base of $F000) to be operational - or at least a small critical part of it.

Nivag has taken my source code and modified it to execute at a base of $F800 for his ROMulator product. He has provided this as a separate file.

My Version 5 release is going to support both $E000 (EDIT) and $F000 (KERNAL) ROM locations (via conditional assembly) and I will provide multiple downloads in the repository. In addition, I hope to add a 40 Column CRTC download as well - to save people the hassle of reassembling it themselves.

Hope this clarifies the position?

Dave
 
Hi guys my desperation will never have an end ... :(
I changed the two 244 but i have always same situation....
Daver.....this the most complicated jigsaw we've ever met....maybe time to white flag :(
 
This sometimes happens I am afraid.

The basic problem is (as I have mentioned in a previous post) that you have a very limited set of test equipment.

We are currently basing our direction upon the output from my PETTESTER, and the analysis of a logic probe.

This, in my opinion, is too limited for all faults. We have been relatively ‘lucky’ with some of your machines - but other faults (like this one) require a decent oscilloscope and/or logic analyser.

Perhaps you can probe around some of the devices with your logic probe and we get lucky?!

Perhaps do something completely different for a few days and see if we get some further inspiration before returning to the machine.

I am just designing a ROMulator for work at the moment. It will be able to support up to 128 sets of ROMs - each of 32KB (27256 EPROM replacement). This will be implemented in a Xilinx FPGA with block RAM and will be booted from an onboard SPI flash. I am just designing the ‘user interface’ - i.e. a set of rotary switches (x2) to select the desired set of emulated chips.

Dave
 
Ok Dave...at this point i do not know what to do..
MAybe i have bad Ud8 socket???
They could be some bad 244 maybe?
 
daver2 said:
I am just designing a ROMulator for work at the moment. It will be able to support up to 128 sets of ROMs - each of 32KB (27256 EPROM replacement). This will be implemented in a Xilinx FPGA with block RAM and will be booted from an onboard SPI flash. I am just designing the ‘user interface’ - i.e. a set of rotary switches (x2) to select the desired set of emulated chips.
Click to expand...
Great project!!
 
Very, very unlikely you have a bad UD8 socket. Forget this.

It is possible that you have purchased some faulty 244 devices. You have done this before...

I assume you put these in sockets on the board? If you did, this might help us?

The 244 device is a simple buffer, you can test it on a bit of breadboard to see if they are fully operational.

Dave
 
daver2 said:
The 244 device is a simple buffer, you can test it on a bit of breadboard to see if they are fully operational.
Click to expand...
Yes i have socketed these 244....i have always pulses on pins 1-19.... I don't think they are faulty but i'll try the others 2 :(
 
You must log in or register to reply here.
Back
Top