• Please review our updated Terms and Rules here

Cbm 2001 Pet strange boot

I've been occupied elsewhere... what is the current state?

I don't have a dynamic PET, mine is much simpler using static RAM, so I don't have direct experience but one observation is that DRAM will lose a value if it is not refreshed... accessing a DRAM address is effectively a refresh so in the absence of refresh a DRAM will appear to work if you address it frequently enough. Maybe we need to follow through the refresh logic?

PS
A ROM/RAM replacement board doesn't really help in isolating RAM faults since it merely hides them by substitution.
 
Dave_C78 said:
just for clarity, do I have to lift one leg of the resistors and join the raised pins together?
Click to expand...
It is just a matter of crossing (swapping) the two signals which come via those resistors to the DRAM, so the lifted leg of one resistor connects to where the other resistor was lifted from (or previously connected to on the board). You do not want to connect the two resistors together.
 
Hugo Holden said:
It is just a matter of crossing (swapping) the two signals which come via those resistors to the DRAM, so the lifted leg of one resistor connects to where the other resistor was lifted from (or previously connected to on the board). You do not want to connect the two resistors together.
Click to expand...
I am desperate, i swapped R40 and R41 leg but
the situation seems to have worsened, I put the resistances back as before!

 
daver2 said:
As a result, (a) nothing should generate a maskable interrupt and (b) if anything did, it shouldn't be responded to by the 6502 CPU.


Dave
Click to expand...
I was reading about the keyboard scanning and the fact that whenever the interrupt line goes low, the processor finishes its current instruction and saves the next instruction at an address in DRAM, and goes to the top two bytes of the ROM (Kernal ROM) to get the interrupt vector. And that the keyboard control in the PET is all done via subroutines called by interrupts at a continuous rate of 60Hz. It wasn't clear if the interrupt was initiated by a key press, but it was suggested that "The operating system software tests the keyboard 60 times per second" and that the subroutines that do this are called by an interrupt. So I checked with the scope and indeed there is a 60Hz continuous pulse on the CPU's /IRQ pin the PET. So this means that the low DRAM is being constantly used by the CPU, unless that could be disabled.

That makes me think a defect in low DRAM could send the CPU to no man's land since normally at least the CPU is constantly receiving return address from these at a rate of 60Hz. This would stop any of the PETTESTERs, if the design of them allowed the keyboard to still be working while using them, because of those frequent interrupts if low DRAM was defective. The only PETTESTER I am familiar with at all is your one, which tests the keyboard, so presumably it doesn't stop those 60Hz interrupts and/or would have to have an interrupt of some kind for the keyboard to work if it uses a different keyboard interrupt subroutine ?
 
Last edited:
Dave_C78 said:
I am desperate, i swapped R40 and R41 leg but
the situation seems to have worsened, I put the resistances back as before!

Click to expand...
If anything changed (worsened or got better) with that test, it indicates the two DRAM banks are not behaving the same way, which they would if all the RAM IC's were 100% good, ...swapping those lines would have no effect at all if all the DRAM was 100% normal. So the test suggests that probably some of the DRAM IC's, in both banks are faulty.

Or possibly, there is an issue affecting both banks in the refresh system. Did you check that there are pulses on the /Q outputs of both the flip flops I mentioned in post #820 ?
 
Last edited:
Hugo Holden said:
If anything changed (worsened or got better) with that test, it indicates the two DRAM banks are not behaving the same way, which they would if all the RAM IC's were 100% good, ...swapping those lines would have no effect at all if all the DRAM was 100% normal. So the test suggests that probably some of the DRAM IC's, in both banks are faulty.

Or possibly, there is an issue affecting both banks in the refresh system. Did you check that there are pulses on the /Q outputs of both the flip flops I mentioned in post #820 ?
Click to expand...
G1 and H1 pin 4?
 
Dave_C78 said:
Maybe time to change every ram ics???
Click to expand...

Although I wouldn't recommend it if you decide to socket and replace the RAM at least reconfigure the PET for 8 chip operation for the purposes of testing. That way you at least limit the amount of risky desoldering/soldering in the first instance anyway.

Alan
 
ajgriff said:
Although I wouldn't recommend it if you decide to socket and replace the RAM at least reconfigure the PET for 8 chip operation for the purposes of testing. That way you at least limit the amount of risky desoldering/soldering in the first instance anyway.

Alan
Click to expand...
how can i do please?
 
@daver2 now, sometimes when i turn on i see this strange screen!!
Maybe can it help to understand where the problem is coming from?
Thanks so much sir!

 
Hugo Holden said:
I was reading about the keyboard scanning...
Click to expand...
Firstly I think PETTESTE2KV04.a65 doesn't use interrupts at all. I think the operation is along the lines of...

I'm going to assume Basic4 but the variants are similar in this respect...

RESET Vector FFFC which points to FD16

; - Power-Up RESET Entry

FD16 LDX #$FF
FD18 SEI
FD19 TXS
FD1A CLD
FD1B JSR $E000 ; cint Initialize Editor & Screen

The JSR will push a return address (Note: TXS initialised the stack) but that doesn't matter as transfer is passed to the tester at E000

Note that SEI inhibits interrupts

When not using PETTESTER the IRQ routine is something like...

; - Main IRQ Entry Point

E442 iE442 PHA
E443 TXA
E444 PHA
E445 TYA
E446 PHA
E447 TSX
E448 LDA $0104,X
E44B AND #$10
E44D BEQ $E452
E44F JMP ($0092) ; Vector: BRK Instr. Interrupt [3: FD17, 4: D478]
E452 iE452 JMP ($0090) ; Vector: Hardware Interrupt [3: E62E, 4: E455]

Notice the indirect jump through page zero. This is a handy point to wire your favourite key logger etc. A dodgy zero page RAM would wreak havoc with that.

Share & Enjoy,

ref: http://www.zimmers.net/anonftp/pub/cbm/src/pet/pet_rom4_disassembly.txt
 
Dave_C78 said:
Yes Dave, this is a random fault... Why????
Click to expand...
That is interesting.

It looks like the image is also right to left reversed too, looking at the number 7 at the bottom right, not only is it upside down , but left right reversed. This would be seen, say if the deflection yoke on the CRT was mechanically rotated 180 degrees, (or is wires reversed).

The bottom of the screen occurs later in time that the top, and the right of the screen later than the left, due to the scanning process.

It is hard to imagine how this could happen as a fault in the video generation circuit. It would require a complete flip of the video memory map or addresses generation to swap all of the pixel positions.

When the computer initially booted, was everything correct, and then it flipped around after that ?
 
Dave_C78 said:
Yes, when i booted computer i saw petester screen and after it flipped around!
Click to expand...
We need to look at the video address generation circuit. Most likely the CPU put the data values, that correspond to the characters, into the correct places in the video memory map, or likely it would not be so orderly, but somehow the addresses which read them out of the video memory and clock them out of the shift register, have got flipped and the map (addresses) are being scanned out out in reverse, something like an up/down capable counter running in reverse........I'll look at the circuit. (This must be one of the more interesting faults ever reported in a PET and beats the pants off the recent "Ghost Writer" fault I had in a PET board which was due to a defective PIA)
 
You must log in or register to reply here.
Back
Top