Commodore PET 4016

[julie_m]

The display memory on the PET can be accessed separately by the processor and the video subsystem, each of which has its own set of tristate buffers on the address and data buses.

You could get the situation "bytes 256-511, 512-767 and 768-1023 display exactly like 0-255" if the video subsystem had lost address line A8 or A9 (or both) and was repeating a 256 or 512 byte block of the screen; and if there were also a faulty location within the video memory (in one of the parts being hidden by the address fault), this would give a false readback (to the CPU) that you wouldn't be able to see because the incorrect character was never being read by the video subsystem.

[SiriusHardware]

Per paragraph 2 above, that fault would not only result in the same block being tested twice but it would also result in a pass, since Pettester would be unaware, thanks to the nature of the fault, that it was testing a smaller 'good' subsection of the screen RAM twice.

Otherwise, it is certainly true that a video RAM fault could 'hide' from the test under those circumstances.

The video RAM can be ruled out as it has already been substituted, I think.

Incidentally Julie, good to have you back - you always used to comment on anything 6502 related but it seemed like you hadn't been around for a while.

[SiriusHardware]

...And as you are here, and I know you have a particular affinity for 6502, maybe you could look at the source code for Pettester V4...

https://drive.google.com/drive/folders/1fyLbr1kcG98a2FDOMo1H5pj9lIdJpHcx

...and consider ways to make a custom version which focuses on screen RAM only but gives a more informative report about any problems it finds?

I have considered trying to do this myself but the lack of a PET to test modified versions on is a bit of a problem for me - and my several attempts to get VICE (the Commodore emulator) to run have failed miserably.

Note that any such custom version has to follow the rule already set in Pettester... they can not attempt to use any system RAM, therefore things like subroutine calls (which require the use of a stack in RAM) can not be used.

[julie_m]

Originally Posted by SiriusHardware

Per paragraph 2 above, that fault would not only result in the same block being tested twice but it would also result in a pass, since Pettester would be unaware, thanks to the nature of the fault, that it was testing a smaller 'good' subsection of the screen RAM twice.

The video subsystem and the CPU each have their own sets of tristates to connect to the video RAM; and when PetTester reads back the values it has written, it will be seeing them via the CPU's bus connection to the video RAM. So it would be testing the whole of the memory, while the video circuits were displaying the same portion of it repeatedly; and an error in part of the video RAM that was not being displayed in favour of a copy of a different section would not be visible, but would show up to the test program.

0400 +----------+    SCREEN          REALLY
   D |          |    +------------+    +------------+
0300 +----------+    |AAAAAAAAAAAA|    |AAAAAAAAAAAA|
   C |  FAULTY  |    |ABBBBBBBBBBB|    |ABBBBBBBBBBB|
0200 +----------+    |BBCCCCCCCCCC|    |BBAAAAAAAAAA|
   B |          |    |CCCDDDDDDDDD|    |AAABBBBBBBBB|
0100 +----------+    +------------+    +------------+
   A |          |    A9 missing; A,B where C,D should be
0000 +----------+    25 * 40 chars = 1000 bytes + 24 not shown

Anyway, I'll have a look at that code and see if I can come up with a test that would pick up on my scenario. "No RAM" is certainly a fun little constraint to work with! And an unfamiliar assembler dialect to boot. Good job I likes me a challenge!

[SiriusHardware]

Thanks Julie - I get what you mean now.

The good thing is that we know, for our purposes, that the screen memory / video rendering circuit correctly displays anything written to the first 256 bytes, or at least we think it does, so any custom test you might devise should be able to write legible results to the screen...

And even if it doesn't, that may tell us something useful.

[ScottishColin]

Thanks both.

fyi, I've raided the 4032 for so many chips I'm waiting for a delivery from Cricklewood so I can get both the 4016 and the 4032 working at the same time so I can do some scope work if that becomes helpful.

Colin.

[julie_m]

Well, I've successfully downloaded VICE, got the ROMs, had it emulate a PET and run PetTester on it. So that's encouraging. Next step will be to see if I can make a ROM image with my own code .....

[SiriusHardware]

[julie_m]

Baby steps .....

The code, for what it's worth:
testrom_01.zip

[SiriusHardware]

Looking good, keep going

[Red to black]

Originally Posted by SiriusHardware

Now here's the problem: Attached below are the 'pass' screen for a 40-column PET and the screen which Colin's PET displays and holds. For this to be happening there must be at least one difference between these two screens. Can anyone see it? Because so far, I haven't been able to find it.

Yes, on the third row of normal characters down just under the capital I

[julie_m]

Some progress: I've got a test program together which tests the first 256 bytes of screen memory, by first filling with zeros and then working through each byte, setting each bit in turn (01-02-04-08-10-20-40-80), making sure we can read it back intact (so we know there is not a bit stuck at "0" or "1") and making sure no other byte in the range has a bit set (so we know there are no address clashes in this range).

Once this is done, we know we have 256 bytes of screen memory we can use for workspace and to display results. So we make use of the known-good screen memory to test the stack page at &0100 - &01FF and zero page &0000 - &00FF. If we get all the way through to the end of this, then we have a minimal system -- and we can safely use zero page and stack locations, though at this stage we don't know there are no address clashes between zero page and the stack. We do know neither of them clash with our workspace in display memory, which would have fatally affected their tests, so we can use zero page and stack locations as long as we don't use two locations exactly &100 apart. So we can start the stack pointer at &01FF and use zero page locations around &00.

Screenshot of a pass on an emulated 4016:

And the code:
testrom_02.zip
I've used up about a third of the available space, but the rest of the code can be written more compactly once this first stage of testing is done. More tests to come as I think of them .....

[SiriusHardware]

Red to black: Fantastic spot, if correct - apologies but I'm not in a position to be able to verify it at the moment - however if it is indeed correct then Colin, can you run the Pettest over and over and over again and verify whether:-

-The difference is always in the same place every time
-The difference is NOT always in the same place every time.

If it is always in the same place every time, swap the two 2114s over and see if the difference is then NOT in the same place as it consistently was before. If swapping the 2114s moves the location of the fault from one consistent fixed location to some other location then one of your 'new' 2114s may have a faulty byte.

Julie: Good work, thanks, and for this purpose it does not matter if the code is (in your own opinion) sloppily / wastefully written as long as it performs every screen test function you think it needs to and fits into a 2716 - it's absolutely fine for whatever you come up with to be a really thorough screen ram / display circuit tester and not have any other function beyond that.

Colin has an EPROM programmer and some 2716s and I'm sure he would be happy to run tests on his real hardware, once he's collected enough parts to be able to put his machines back together.

[SiriusHardware]

Red to Black: I've now had a chance to examine the area of difference which you mentioned and I think the difference, although visually present, can be explained in two ways:

The 'Pass' image from the Pettester manual is either shot from a Flat screen monitor or digitally generated, with two differences which distinguish it from Colin's off screen image from a real PET.

One, all vertical lines on characters and graphics are continuous / solid on the 'pass' image whereas on Colin's off-CRT screen shot they are comprised of horizontal bars or dots corresponding to scan lines.

Two, the 'pass' screen image seems to have been generated with a distinct space between each horizontal character line perhaps to make it easier to see the upper and lower edge limits of characters, especially graphics characters.

These two effects combined do make the section you identified look different, especially where the spindly line graphic characters below the 'I' are separated from the inverse text below by a gap on the 'pass' screen but join directly to them on Colin's off-screen shot.

But apart from that, I can not actually see a difference in that area, although I would be more than happy to be corrected.

[SiriusHardware]

Is anyone any good with AI tools? Maybe an AI engine would be able to spot the difference between the two original whole-screen images although it would have to be smart enough to ignore the distortion due to screen curvature plus the broken-up vertical lines on the off-CRT image.

[julie_m]

I think the discrepancy Red to Black spotted was in the third band of non-inverted characters, just below and to the right of the middle of the screen.

Which is extremely odd; because the PET has a character-mapped screen, and the character in that position appears actually malformed in terms of its bitmap. It's as though there was an issue with either the character generator ROM (though the same character appears fine elsewhere on screen) or the shift register clocking out the individual pixels.

Anyway, there's not really much more I can do until Colin manages to get my test code burned into a 2716 and running on his faulty PET. At least then I'll be able to decide whether to add another round of tests, or some better error reporting for early test failures!

[SiriusHardware]

Ah, I obviously misinterpreted Red to Black's map co-ordinates. I see it now, under the third non-inverse Captital 'I' encountered, if counting from the top down.

Red to Black, that was some incredible feat spotting that. I was at a local National Trust site on Good Friday and in their second hand book stall they had a pocket sized anthology of all of the 'Where's Wally' books. I nearly bought it for myself, but I should have bought it for you.

Going back to that strange 'cursory' one pixel high anomaly Colin was reporting earlier, I wonder if that is being continually inserted into / removed from the screen memory by some hardware or interrupt driven action, so that at any given time one of the screen bytes will be in an altered state, making it difficult / impossible for the screen RAM to pass the Pettester screen test. If so it could also have repercussions for Julie's test code.

Anyway yes, I agree it's there and so Colin, when you are in a position to do so, please let us know if that anomaly always occupies that position no matter how many times Pettester is run and if it does, swap the screen RAM 2114s over and see if it moves.

Julie: Yes, I think we need to wait until Colin is back with us, but many thanks for what you have done so far.

[TonyDuell]

Why would swapping the 2114s around change the location of the glitch?

On 40 column PETs, like this one, there is 1K bytes of video RAM, stored in a pair of 2114s. Each chip is 1k*4. One of them stores the top 4 bits of each character, the other the bottom 4 bits. So if there is a dubious location in one of the RAM chips, swappng them round will keep it at the same character location on the screen but it will affect the other 4 bits.

[SiriusHardware]

I would count a movement 4 pixels to the left or right as a change of location, but I see what you mean.

[SiriusHardware]

I'm not sure it's going to be that simple anyway - that anomaly which R2B spotted is very similar in size / shape to the cursor-like object which Colin has observed scanning across the screen.