daver2
10k Member
Ok, that's good.
What about UD2 pin 1? Got a pulse there?
Dave
What about UD2 pin 1? Got a pulse there?
Dave
- 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
Commodore pet 3032 screen full of lines
- Thread starter Desperado
- Start date
daver2
10k Member
Good. So, a few more:
UI11 pins 1 and 19 (74LS244).
UI10 pins 1 and 19 (74LS244).
These are the control signals for the bus buffers between the DRAM chips and the CPU data bus. Pin 1 is /READ and pin 19 is /WRITE.
UG1 pin 11 (74LS08). This is the /RAS line for the DRAM.
UG7 pin 12 (74LS10). This is the /CAS0 line for the lower bank of DRAM.
You should see pulses on all pins.
Dave
UI11 pins 1 and 19 (74LS244).
UI10 pins 1 and 19 (74LS244).
These are the control signals for the bus buffers between the DRAM chips and the CPU data bus. Pin 1 is /READ and pin 19 is /WRITE.
UG1 pin 11 (74LS08). This is the /RAS line for the DRAM.
UG7 pin 12 (74LS10). This is the /CAS0 line for the lower bank of DRAM.
You should see pulses on all pins.
Dave
Desperado
Veteran Member
- Joined
- Nov 25, 2017
- Messages
- 6,827
Ok thanks:
UI11 PIN1
ULSEUI11 PIN19:LOW PULSE
UI10 PIN1
ULSEUI10 PIN19:LOW PULSE
UG1 PIN11
ULSEUG7 PIN12
ULSE
daver2
10k Member
Excellent, so the control signals are being generated for the lower DRAM devices correctly.
Next, I want you to concentrate on DRAM UI2.
Can you probe around all of the pins on this IC *** EXCEPT *** pins 1, 8, 9 and 16. These are the power supply pins of the DRAM and some of the voltages could damage your logic probe.
Can you also probe on pin 2 of all the DRAMs UI2 to UI9.
We are going to check that we have address, data and control lines on the lower bank of DRAM.
Could I also suggest that you measure the power supply rails on UI2 with your multimeter if you haven't already.
Pin 8 VDD +12V.
Pin 9 VCC +5V.
Pin 1 VBB -5V.
Pin 16 VSS 0V.
If the DRAMs don't have the correct voltages, they won't work!
Dave
Next, I want you to concentrate on DRAM UI2.
Can you probe around all of the pins on this IC *** EXCEPT *** pins 1, 8, 9 and 16. These are the power supply pins of the DRAM and some of the voltages could damage your logic probe.
Can you also probe on pin 2 of all the DRAMs UI2 to UI9.
We are going to check that we have address, data and control lines on the lower bank of DRAM.
Could I also suggest that you measure the power supply rails on UI2 with your multimeter if you haven't already.
Pin 8 VDD +12V.
Pin 9 VCC +5V.
Pin 1 VBB -5V.
Pin 16 VSS 0V.
If the DRAMs don't have the correct voltages, they won't work!
Dave
daver2
10k Member
Excellent.
There doesn't seem to be any stuck signals (so that is good).
I need to go and check something in the source code - but I am in the middle of something at the moment so I will get back to you shortly.
The +12 V rail is a little high, but not enough to cause concern.
Dave
There doesn't seem to be any stuck signals (so that is good).
I need to go and check something in the source code - but I am in the middle of something at the moment so I will get back to you shortly.
The +12 V rail is a little high, but not enough to cause concern.
Dave
daver2
10k Member
Quick question. Which version of my PETTESTER are you using? Are you using version 4 (as I pointed you to back in post #27?).
Dave
Dave
Desperado
Veteran Member
- Joined
- Nov 25, 2017
- Messages
- 6,827
daver2
10k Member
Thanks.
OK, so you shouldn't get just that screen on startup.
Can you rig up a manual reset button to your PET please? Either connect a normally-open pushbutton (or switch) across C67 (1uF tantalum capacitor used in the reset circuit) or between pins 7 and 1 of UA2 (8-pin 555 timer IC).
With the PET turned on, and my test firmware running, can you record a video of the screen after depressing and releasing the reset button/switch. Set the video recording BEFORE operating the manual reset switch.
The firmware should first display all the characters from the character generator on the screen then verify that they can be read by the CPU.
The screen is then cleared.
The next test performs a byte test on the page 0 and 1 RAM.
The next test performs a 55/AA test on the page 0 and 1 RAM.
I would like to see how far it gets during its testing.
Between each test is a delay.
EDIT: I am just going out for a walk, so I will catch up with your posts when I get back. Also, to keep dave_m happy, I am working on the documentation for the diagnostic firmware...
Dave
OK, so you shouldn't get just that screen on startup.
Can you rig up a manual reset button to your PET please? Either connect a normally-open pushbutton (or switch) across C67 (1uF tantalum capacitor used in the reset circuit) or between pins 7 and 1 of UA2 (8-pin 555 timer IC).
With the PET turned on, and my test firmware running, can you record a video of the screen after depressing and releasing the reset button/switch. Set the video recording BEFORE operating the manual reset switch.
The firmware should first display all the characters from the character generator on the screen then verify that they can be read by the CPU.
The screen is then cleared.
The next test performs a byte test on the page 0 and 1 RAM.
The next test performs a 55/AA test on the page 0 and 1 RAM.
I would like to see how far it gets during its testing.
Between each test is a delay.
EDIT: I am just going out for a walk, so I will catch up with your posts when I get back. Also, to keep dave_m happy
, I am working on the documentation for the diagnostic firmware...Dave
Last edited:
dave_m
Veteran Member
Also, to keep dave_m happy
Dave,
Pettest V4 released and to be soon documented. Good boy! :D
-dave_m
daver2
10k Member
He he...
Documentation week I think.
Dave
Documentation week I think.
Dave
Desperado
Veteran Member
- Joined
- Nov 25, 2017
- Messages
- 6,827
Thanks.
OK, so you shouldn't get just that screen on startup.
Can you rig up a manual reset button to your PET please? Either connect a normally-open pushbutton (or switch) across C67 (1uF tantalum capacitor used in the reset circuit) or between pins 7 and 1 of UA2 (8-pin 555 timer IC).
With the PET turned on, and my test firmware running, can you record a video of the screen after depressing and releasing the reset button/switch. Set the video recording BEFORE operating the manual reset switch.
The firmware should first display all the characters from the character generator on the screen then verify that they can be read by the CPU.
The screen is then cleared.
The next test performs a byte test on the page 0 and 1 RAM.
The next test performs a 55/AA test on the page 0 and 1 RAM.
I would like to see how far it gets during its testing.
Between each test is a delay.
EDIT: I am just going out for a walk, so I will catch up with your posts when I get back. Also, to keep dave_m happy
Dave
Good morning,
ok i ve added button accross to 555 's pin 1 and 2.
This is little video test:
https://youtu.be/tSRnz_Z8lHA
Thanks
daver2
10k Member
Pin 1 and 2 for reset. Thanks for the correction.
I have a problem with the video in that it is not showing what my PETTEST V4 firmware actually does according to the source code...
The first thing that it should do (after a reset) is to fill the screen with copies of the full character set. This is not happening?
This could happen for one of three reasons:
1. My PETTEST firmware is not compatible with the version of kernal ROM you are using. What part number is on the kernal ROM you are using please? I should be able to duplicate your specific machine setup in VICE and check that it works.
2. You have a faulty kernal ROM (the first few instructions that execute following a reset are corrupt).
3. You haven't got the kernal ROM installed at all, but another variant of the PETTEST that runs in the kernal socket (as opposed to mine that runs in the EDIT ROM socket).
We need to find out which of the above three scenarios we have.
Dave
I have a problem with the video in that it is not showing what my PETTEST V4 firmware actually does according to the source code...
The first thing that it should do (after a reset) is to fill the screen with copies of the full character set. This is not happening?
This could happen for one of three reasons:
1. My PETTEST firmware is not compatible with the version of kernal ROM you are using. What part number is on the kernal ROM you are using please? I should be able to duplicate your specific machine setup in VICE and check that it works.
2. You have a faulty kernal ROM (the first few instructions that execute following a reset are corrupt).
3. You haven't got the kernal ROM installed at all, but another variant of the PETTEST that runs in the kernal socket (as opposed to mine that runs in the EDIT ROM socket).
We need to find out which of the above three scenarios we have.
Dave
Desperado
Veteran Member
- Joined
- Nov 25, 2017
- Messages
- 6,827
Hi dave,
no i can't see full char set in the screen after reset..
i have installated 901465-03 kernal ROM in Ud9...i ve tested and verified with eprom programmer and seems to be ok...
daver2
10k Member
I have configured VICE as follows:
-model 4016
-kernal ../kroms/kernal-2.901465-03.bin
-editor ../V04/PETTESTE2KV04.bin
On start-up, VICE tells me that the Kernel is for BASIC 2 based upon the ROM checksum.
My PETTEST code correctly starts up and displays the full character set.
The checksum I get for the kernel ROM is 7C98.
It seems to work.
Can you put the PETTEST EPROM into your EPROM programmer and post the first 8 bytes you find at offset $000 within the EPROM and (because you have made two copies of my code in a 2732) the 8 bytes at offset $800 within the EPROM please.
Something 'funny' is going on here...
Dave
-model 4016
-kernal ../kroms/kernal-2.901465-03.bin
-editor ../V04/PETTESTE2KV04.bin
On start-up, VICE tells me that the Kernel is for BASIC 2 based upon the ROM checksum.
My PETTEST code correctly starts up and displays the full character set.
The checksum I get for the kernel ROM is 7C98.
It seems to work.
Can you put the PETTEST EPROM into your EPROM programmer and post the first 8 bytes you find at offset $000 within the EPROM and (because you have made two copies of my code in a 2732) the 8 bytes at offset $800 within the EPROM please.
Something 'funny' is going on here...
Dave
Desperado
Veteran Member
- Joined
- Nov 25, 2017
- Messages
- 6,827
daver2
10k Member
I can't see anything wrong with that. As Alice would say "curiouser and curiouser"...
Next issue could be that your kernel ROM is (in some way) different to what I am expecting...
Each of the different variants of the kernel ROM (and the EDIT ROM) had a different entry point. I have configured my diagnostics to be compatible with all of the known variants of the Kernel ROM I know about. This included 901465-03 for BASIC 2.
My diagnostics were originally written for an 8032 with BASIC 4 and (if I remember correctly) a similar thing happened when people used the diagnostics with BASIC 1 and 2 (hence the reason I added the three different entry points into my diagnostic ROM).
Can you dump the kernel ROM out you are running please (in HEX) and post it so I can see where it enters the EDIT ROM please. The other option is to get your EPROM programmer to perform a 16-bit checksum on the contents of the ROM. It should match with $7C98.
Thanks.
I suppose the other problem is that we could have an address, data or ROM selection fault which is causing the diagnostic ROM not to execute correctly?
Dave
Next issue could be that your kernel ROM is (in some way) different to what I am expecting...
Each of the different variants of the kernel ROM (and the EDIT ROM) had a different entry point. I have configured my diagnostics to be compatible with all of the known variants of the Kernel ROM I know about. This included 901465-03 for BASIC 2.
My diagnostics were originally written for an 8032 with BASIC 4 and (if I remember correctly) a similar thing happened when people used the diagnostics with BASIC 1 and 2 (hence the reason I added the three different entry points into my diagnostic ROM).
Can you dump the kernel ROM out you are running please (in HEX) and post it so I can see where it enters the EDIT ROM please. The other option is to get your EPROM programmer to perform a 16-bit checksum on the contents of the ROM. It should match with $7C98.
Thanks.
I suppose the other problem is that we could have an address, data or ROM selection fault which is causing the diagnostic ROM not to execute correctly?
Dave