View Single Post
Old 5th Apr 2021, 11:11 pm   #1368
ortek_service
Heptode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 629
Default Re: Non-working Commodore PET 3016

Quote:
Originally Posted by ScottishColin View Post
Here you go - link to code and manual here.

https://drive.google.com/drive/folde...13&direction=a

Colin.
Thanks very much for this - I can see why it was so hard to find via Google search etc.!
I started off looking through the .a65 assembler code, as it is very well commented, to see what it was doing. But then had a look at the manual, as that did clear-up why he choose to put it in the Edit ROM (meaning the Kernal one had to be working OK), as well as having good screenshots and explanations.

What I couldn't understand to start with, was why if you were getting a counting PETSCII sequence appearing on the screen OK, then why it then didn't proceed to doing the Zero-page memory test, after a short delay - Which it should do, provided it reads back OK what it wrote to the screen RAM, otherwise it just keeps repeating the screen RAM Write/Read test forever, until it passes.

So I thought there may be an issue with the hardware, affecting reading back. And I couldn't see why you'd originally (in post #1301) got 2 different generated displays of characters. But then (after finding the PETSCII codes earlier, that I posted a link to) I noticed that although the second screenshot you'd originally posted looked correct (apart from that it seems to default to Alternate rather than Standard character set, as they don't seem to setup the 'GRAPHIC' latch), the first screen starts <Space> ! " etc. And crucially this is actually shifted-up by +32 (So was the previously identified 'D5' stuck high problem!)

And the random alternating between the 2 different displays was a result of this fault coming and going !
Now if the changing of the Kernal ROM socket appears to have fixed this issue, that was identified with the Slothie Kernal IC, I'm wondering how the daver2 PETTEST2KV04 would now run - I have discovered that not only does it display G or B for each byte in Page 0 and Page 1, it also displays '.' if Ok or the actual byte readback as a PETSCII character if bad (so you can then work out which datalines are at fault).


So I was going to suggest temporarily removing the current Slothie Diagnostic ROM Kernal replacement IC (may be able to leave extra tap-off wire, if all pins isolated), refitting the original Kernal one in its place. And then remove the Edit ROM, and fit the daver2 PETTEST2KV04. And see what you now get, if the screen RAM D5 issue has now gone away!
- However, it does appear you have done this in post #1350!

But it might be worth trying again a few times, and waiting a while to see if it does move onto the page-zero RAM test.

I'll take a close look at the screenshot you did get, and see if there might be an odd stuck video memory dataline issue, but it doesn't look like this is the first case at first glance. One of those cheap > 8 ch. logic analysers on the data and R/~W lines etc. may be useful,to see exactly what is being read back from the screen RAM and how it different to what is being written to it.

Last edited by ortek_service; 5th Apr 2021 at 11:25 pm.
ortek_service is offline   Reply With Quote