• Please review our updated Terms and Rules here

Cbm 2001 Pet strange boot

Agree, please check again.

EDIT: But the CPU is executing instructions - yes (SYNC pin of CPU oscillating)?

The state you imply is that the CPU is executing code in RAM between $0000 and $0FFF - implying that the CPU is not obeying the instructions from ROM.

No, it doesn’t imply that the CPU is faulty either!

More likely there is an issue with the ROM, it’s address decoding (/CS line from UD2 pin 17 to UD9 pin 20) or the data bus is becoming corrupt.

What we need to do next (after checking for continuity from UD2/17 to UD9/20) is to look for signs of activity on UD9/20 just after a reset condition.

For that, we need to use our trusty scope...

But do the above first.

Dave
 
daver2 said:
What we need to do next (after checking for continuity from UD2/17 to UD9/20) is to look for signs of activity on UD9/20 just after a reset condition.
Click to expand...
I have continuity UD2/17 to UD9/20, if i put scope probe on UD9 pin 20 i see horizontal signal ( 4 V ), if i press reset button sometimes
i see also low signal 0,2 V and sometimes i see only 4V signal :(
 
The fact that you do see something on UD9/20 immediately after a reset sometimes IS encouraging my friend :)!

You may not see it always if you are not triggering the scope correctly. But the fact that you do see it occasionally is good...

So, we have a couple of options here as to what is wrong:

The address lines are not fully connected to the address bus. This is easily checked by performing a continuity test from each address pin on UD9 to the associated pin of the address buffers to which they should be connected to. You can also use the NOP generator to check that the correct frequencies are present on the address lines of UD9. Print the relevant schematics out of the ROMs and address buffers (the latter being on schematic sheet 1) and Mark each pin as you test it.

The data lines are not fully connected between the UD9 ROM and the CPU. Check for continuity between the data lines of the UD9 ROM and the corresponding pins of the CPU.

Also check that the 0V/GND pin of UD9 is really connected to 0V/GND and that the VCC pin of UD9 is really connected to +5 Volts. I would check for continuity between the pins of UD9 and the CPU. Check the device data sheets for the correct pins.

Thus leaves us with two further possibilities:

1. The ROM is not returning the correct bytes anymore for the given address.

2. The CPU data bus is being corrupted by some other means (possibly the data bus buffers to the RAM and memory expansion connector are being enabled when they shouldn't be. Let's address these last two if we need to later.

Dave
 
I have continuity between these pins:

UD9 PIN 8 UC3 PIN 18

UD9 PIN 7 UC3 PIN 3

UD9 PIN 6 UC3 PIN 16

UD9 PIN 5 UC3 PIN 5

UD9 PIN 4 UC3 PIN 14

UD9 PIN 3 UC3 PIN 7

UD9 PIN 2 UC3 PIN 12

UD9 PIN 1 UC3 PIN 9

UD9 PIN 23 UB3 PIN 18

UD9 PIN 22 UB3 PIN 3

UD9 PIN 19 UB3 PIN 16

UD9 PIN 18 UB3 PIN 5
 
daver2 said:
I’ll double check those after lunch.

Data lines next...

For example UD9/9 to UC4/33 (for data line 0).

Dave
Click to expand...
Also i have continuity between these :

UD9 PIN 9 UC4 33

UD9 PIN 10 UC4 32

UD9 PIN 11 UC4 31

UD9 PIN 13 UC4 30

UD9 PIN 14 UC4 29

UD9 PIN 15 UC4 28

UD9 PIN 16 UC4 27

UD9 PIN 17 UC4 26
 
What I will do is to post a very simple program for you to burn into a 2532 EPROM and to put into UD9 socket.

It will write $55 into the first character of the screen at address $8000 and then write $AA into the same location.

If this works, we should see activity on /SELF and /SEL8 of UD2 only. We should also be able to check the data bus out.

Dave
 
OK, so I concur with your continuity tests as described in posts #1,489 and #1,492.

Here is the listing of my simple test program:

Code: 
FFEE   A9 00        GO:       LDA   #$00  
FFF0   8D 00 80               STA   $8000  
FFF3   A9 FF                  LDA   #$FF  
FFF5   8D 00 80               STA   $8000  
FFF8   80 F4                  BRA   GO  
FFFA   EE FF                  DW    GO   ; NMI
FFFC   EE FF                  DW    GO   ; RESET
FFFE   EE FF                  DW    GO   ; IRQ/BRK

The code is designed to run starting at address $FFEE within EPROM UD9.

However, the 2532 EPROM is 4K, so spans addresses $0000 to $0FFF when in the EPROM programmer.

You need, therefore, to start entering the hexadecimal data bytes at offset $0FEE within your EPROM programmer buffer.

The above code is the listing file (produced from an assembler). You only have to enter the assembled data bytes themselves (e.g. A9, 00, 8D, ..., EE, FF.

The last 6 bytes (3 words) are the vectors covering the NMI interrupt, the RESET location and the IRQ/BRK interrupt/instruction. They all cause my test program to restart.

I changed the values that are written to the first screen location to be $00 (the '@' character) and $FF (the 'checkerboard' character). However, you will not be able to observe these individual characters as the CPU will be running too fast for that. We should, however, be able to 'see them' on the oscilloscope if we set it up correctly. However, that is for another post.

Burn a new 2532 EPROM with the contents above, pop it into UD9 and have a look (with the oscilloscope) to see what the outputs of UD2 look like again. Report back with the results.

Is the above clear before you start?

Dave
 
Thanks Dave, so must i burn only this code?

FFEE A9 00

FFF0 8D 00 80

FFF3 A9 FF

FFF5 8D 00 80

FFF8 80 F4

FFFA EE FF

FFFC EE FF

FFFE EE FF
 
You must log in or register to reply here.
Back
Top