- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Cbm 2001 Pet strange boot
- Thread starter Desperado
- Start date
daver2
10k Member
I have been reviewing posts #288, #308 and #320.
At one stage we seemed to have the correct characters being displayed on the VDU screen - but the PETTESTER 'jammed' on that test - implying that the CPU was misreading the screen memory.
We then had the monitor shutting down issue and then we started discussing using my modified version of PETTESTER I created specifically for analysing the same problem with your previous PET.
We then seemed to have problems running the firmware and switched to Nivag's 4K firmware in the Kernal ROM socket (UD9).
Let's go back to Nivag's 4K version and see if that works - I will assume that whatever we have done in the meantime has fixed the problem if it works...
Dave
At one stage we seemed to have the correct characters being displayed on the VDU screen - but the PETTESTER 'jammed' on that test - implying that the CPU was misreading the screen memory.
We then had the monitor shutting down issue and then we started discussing using my modified version of PETTESTER I created specifically for analysing the same problem with your previous PET.
We then seemed to have problems running the firmware and switched to Nivag's 4K firmware in the Kernal ROM socket (UD9).
Let's go back to Nivag's 4K version and see if that works - I will assume that whatever we have done in the meantime has fixed the problem if it works...
Dave
Desperado
Veteran Member
- Joined
- Nov 25, 2017
- Messages
- 6,827
Ok thank so i burn again pettester 4k for ud9!
daver2
10k Member
And...
Dave
Dave
daver2
10k Member
If it works it works...
I now understand why the 'f' ROM returns the incorrect checksum - the Kernal ROM has been replaced by Nivag's code.
Can you put the kernal ROM (that you removed to put in Nivag's PETTESTER) into socket UD5 please. This socket should be empty on your machine.
The "b=" ROM display should now give you the correct checksum for the Kernal ROM for BASIC 2 (from my documentation). We have moved the ROM from socket UD9 to UD5. The correct checksum being 7c98.
If this is correct, put the original PET ROMs in the correct sockets and give the machine a run...
Dave
I now understand why the 'f' ROM returns the incorrect checksum - the Kernal ROM has been replaced by Nivag's code.
Can you put the kernal ROM (that you removed to put in Nivag's PETTESTER) into socket UD5 please. This socket should be empty on your machine.
The "b=" ROM display should now give you the correct checksum for the Kernal ROM for BASIC 2 (from my documentation). We have moved the ROM from socket UD9 to UD5. The correct checksum being 7c98.
If this is correct, put the original PET ROMs in the correct sockets and give the machine a run...
Dave
Desperado
Veteran Member
- Joined
- Nov 25, 2017
- Messages
- 6,827
Ok with Original Ud9 Rom on UD5 i have this pettester s'screen:
Attachments
daver2
10k Member
OK, pull Nivag's PETTESTER ROM out of UD9 and put the Kernal ROM back from UD5 into UD9 and give the PET a test 
!
Dave
!Dave
daver2
10k Member
I am going out now. I was hoping to see a working PET before I went though!
What is in the EDIT ROM socket out of interest, and is CPU pin 7 (SYNC) pulsing?
Dave
What is in the EDIT ROM socket out of interest, and is CPU pin 7 (SYNC) pulsing?
Dave
Desperado
Veteran Member
- Joined
- Nov 25, 2017
- Messages
- 6,827
daver2
10k Member
All I can suggest until tomorrow is to put Nivag’s ROM back into UD9 and to fully run the PETTESTER diagnostics through a number of memory test passes (the more the better) just to flush out any DRAM faults.
In the meantime I will have a think. I have no way to checkout the EDIT ROM code in UD8 though. If that is faulty then the PET will do exactly what you are observing.
One possibility is to download the code from the Zimmer’s site for the 901447-24 ROM and to burn that into a 2K ROM for UD8 and then try that in place of the ROM you have in there. Check the e= checksum both before replacing it and after replacing it for equivalence.
If the checksums differ, then either the ROM was faulty or the code you have just burnt into the EPROM was duff.
Either way, put the Commodore Kernel ROM back into UD9 in place of Nivag’s and try again to see what happens.
Dave
In the meantime I will have a think. I have no way to checkout the EDIT ROM code in UD8 though. If that is faulty then the PET will do exactly what you are observing.
One possibility is to download the code from the Zimmer’s site for the 901447-24 ROM and to burn that into a 2K ROM for UD8 and then try that in place of the ROM you have in there. Check the e= checksum both before replacing it and after replacing it for equivalence.
If the checksums differ, then either the ROM was faulty or the code you have just burnt into the EPROM was duff.
Either way, put the Commodore Kernel ROM back into UD9 in place of Nivag’s and try again to see what happens.
Dave
Nivag Swerdna
Veteran Member
Catching up...
Post #368 shows... A good F000-FFFF ROM in D5 (really should live in D9), A good C000-CFFF ROM in D6, A good D000-DFFF ROM in D7, an unknown ROM in E000-E7FF in D8, and the PETTESTE2KF04.bin in F000-F7FF (also in F800-FFFF) in D9.
edit-2-n.901447-24.bin should have checksum FDBF
Looks like either the Editor ROM is bad or the decoding of the Editor ROM is problem? We see 1c00 checksum!?!
Probably worth removing the editor ROM, cleaning its legs etc, spray a bit of de-oxit etc. and seeing if the checksum changes.
Aside:
From the schematic I see that socket D8 can hold a 2K or a 4K ROM... I presume that we have a 2K ROM in play here.. how does the decoding work in the case where a 4K ROM is fitted? I presume the peripherals move in the address space in that scenario?
PS
We could bodge the tester to only check the first 2K of the B000-BFFF address space and then test the editor ROM in socket D5?
If using the earlier supplied UD9.bin if you change the value found at offsets 027D and 0A7D from F0 to B0 then the calculated checksum for the B ROM (i.e. what is put in D5) will be top 2K only.
Post #368 shows... A good F000-FFFF ROM in D5 (really should live in D9), A good C000-CFFF ROM in D6, A good D000-DFFF ROM in D7, an unknown ROM in E000-E7FF in D8, and the PETTESTE2KF04.bin in F000-F7FF (also in F800-FFFF) in D9.
edit-2-n.901447-24.bin should have checksum FDBF
Looks like either the Editor ROM is bad or the decoding of the Editor ROM is problem? We see 1c00 checksum!?!
Probably worth removing the editor ROM, cleaning its legs etc, spray a bit of de-oxit etc. and seeing if the checksum changes.
Aside:
From the schematic I see that socket D8 can hold a 2K or a 4K ROM... I presume that we have a 2K ROM in play here.. how does the decoding work in the case where a 4K ROM is fitted? I presume the peripherals move in the address space in that scenario?
PS
We could bodge the tester to only check the first 2K of the B000-BFFF address space and then test the editor ROM in socket D5?
If using the earlier supplied UD9.bin if you change the value found at offsets 027D and 0A7D from F0 to B0 then the calculated checksum for the B ROM (i.e. what is put in D5) will be top 2K only.
Last edited:
Desperado
Veteran Member
- Joined
- Nov 25, 2017
- Messages
- 6,827
Thanks Nivag, maybe i have a bad rom on ud8.... unfortunately i have only one 2716 eprom but i can't erase completely with uv light...
Can i try to burn double 2k edit bin file on 2732 eprom for Ud8 socket?
This afternoon when i come back from my job i'll try to clean eprom s' legs !
daver2
10k Member
>>> Can i try to burn double 2k edit bin file on 2732 eprom for Ud8 socket?
No.
The 4K ROM would overlay the same address space as the PIAs and VIA so your PET won’t work...
You can only use a 2K device for the EDIT ROM.
You could, though, add an external chip to disable the 4K ROM so it only appears as a 2K ROM...
Dave
No.
The 4K ROM would overlay the same address space as the PIAs and VIA so your PET won’t work...
You can only use a 2K device for the EDIT ROM.
You could, though, add an external chip to disable the 4K ROM so it only appears as a 2K ROM...
Dave
Nivag Swerdna
Veteran Member
The UD9_bodge file above (#374) is 4K and should be burnt into a 2732 and placed in UD9. Then place the original editor ROM (901447-24) in UD5 and tell us what you see.
Also order some 2716s
Also order some 2716s
Desperado
Veteran Member
- Joined
- Nov 25, 2017
- Messages
- 6,827
i did as you said but the pettester is stuck on this screen
I am desperate.... i burned also 901447-24 on 2716 eprom and i inserted on UD8 (with original Ud9 inserted) but i have always scrambled screen on startup....Attachments
daver2
10k Member
No need to unsolder the sockets.
This is the test screen I was talking about previously that wasn't passing.
IF the video characters that are present on the screen are correct (to my PETTESTER documentation) THEN this indicates that the 6502 CPU can't (correctly) readback the characters that were put onto the screen (i.e. written into the video RAM).
The issue is likely to be one (or more) of the data bus buffers between the CPU and the video RAM.
That data was written correctly - but (presumably) can't be read correctly.
I am currently on my way out of the office now...
Dave
This is the test screen I was talking about previously that wasn't passing.
IF the video characters that are present on the screen are correct (to my PETTESTER documentation) THEN this indicates that the 6502 CPU can't (correctly) readback the characters that were put onto the screen (i.e. written into the video RAM).
The issue is likely to be one (or more) of the data bus buffers between the CPU and the video RAM.
That data was written correctly - but (presumably) can't be read correctly.
I am currently on my way out of the office now...
Dave