Commodore PET 4016

[Mark1960]

Originally Posted by ScottishColin

Thanks for taking a look.

For the record, I have removed that modification at the moment.

Colin.

I wonder if this is related to the additional 16k dram. Are they the same speed rating as the originals?

[ScottishColin]

The original 16k is made up of 8 chips marked as JAPAN 1F3 HM4716AP-4N

The added 16k is made up of
1 marked as ITT 8111 4116 3N
7 marked as NEC K14348-114 D416C-2

Colin.

[SiriusHardware]

After a brief look at the datasheets for all three types it looks like the two types used in the expanded memory are somewhat faster than the type used for the original 16K. This is very much what I expected, that the person fitting the expansion would err on the side of caution and use chips which were a little bit faster than necessary.

Probably, the oddball ITT one is a later replacement for an NEC one which failed at some point.

[julie_m]

OK, I've modified my test program as mentioned above.

Here's what it (still) looks like if it passes:

There is a new first test: a simple visual read-modify-write test. The first 256 locations in screen memory are all cycled through all possible values. This is done by increasing the value already stored in that location; so if the screen RAM is not reading back correctly, then this will look wrong (a bunch of "@" signs means nothing at all is being read back). After cycling through the character set, there will be a delay of about 5 seconds, and then the workspace test begins as per the previous test ROM.

If a failure occurs when reading back a value already written to memory, and if the display system is working (and Colin's seems to be), then it will display the address at which the fault occurred, the value it was trying to write there and the value it actually read back, clear of the block of memory under test, something like this: A00W01R00 means address &8000, tried to write &01, read back &00.

If the value written to memory is read back successfully, then every other location of the 256 under test -- which should all contain &00 -- will be read and checked for spurious ones (due to stuck bits, or address clashes). If anything other than &00 is read, it will (try to) display the address at which the fault occurred and the value it read, something like this: A40 R01 means address &8040, read back &01.

And I have inserted what I hope are the right CRTC initialisation values for Colin's PET.

Here is the ROM image: (For the benefit of anyone discovering this thread in future, it goes in a 2716 and replaces the editor ROM.)
testrom_03.zip
If the read-modify-write test seems wrong, I can make a new version with that test slowed down, or have it running for more passes, to make it a bit easier to spot anything going wrong.

[SiriusHardware]

Thanks Julie, it will be good to (hopefully) understand just what it is that's making Daver's Pettester halt on the screen RAM test.

[ScottishColin]

Screenshots of the failing 4016 attached; I haven't attached the 4032 success screens as they are just working as designed but it's still useful for me to have a reference device.

The error message is a00w01r80 which at least relates to the screen as it is an inverse @ which is hex 80 in Graphics mode.

As you and Sirius said, would it be useful to repeatedly run the tests so I can start to probe devices?

Colin.

[SiriusHardware]

+1 to that, can it be made so that on failure of a particular test the code will go into a tight loop where it continually re-attempts the failed test? (In this case, write 01 to 8000, read back from 8000). That would allow us to try to scope the data on both sides of one of the intervening buffers and also the relevant read / write signals of course.

Because it's easy to do, swap the 2 x 2114s over and see if that changes the 'wrong' number returned from 80H to something else.

[julie_m]

Originally Posted by ScottishColin

Screenshots of the failing 4016 attached; I haven't attached the 4032 success screens as they are just working as designed but it's still useful for me to have a reference device.

Oh, yes. See also, how a stereo amplifier with a fault on one channel is often an easy fix because you basically have another, working one .....

Originally Posted by ScottishColin

The error message is a00w01r80 which at least relates to the screen as it is an inverse @ which is hex 80 in Graphics mode.

I see the read-modify-write test ended up as a block of inverse "a" characters (&81).

Did it start off very briefly (perhaps even too briefly to be seen) as non-inverted "@" signs and then stick at all inverse "a" ?

Because that would be absolutely consistent with every location in screen memory reading back to the CPU as &80. Though I'm not sure how it's ended up displaying inverse @ in location &8000 where it was writing &01.

Originally Posted by ScottishColin

As you and Sirius said, would it be useful to repeatedly run the tests so I can start to probe devices?

That will be my next move, I think.

(Side comment: Does your PET have the built-in machine language monitor?)

[SiriusHardware]

The built-in machine code monitor can be invoked by holding the DIAG line low at power-on - however it is unlikely to restrain itself from trying to use system RAM which for the moment we can't assume is working.

Nor do we know whether all the keys on the keyboard are working - traditionally the keyboard is the last or second last thing you have to fix on these.

There would be no harm in trying it though.

[SiriusHardware]

I'm puzzled by one thing: When Pettester stalls on the screen RAM test section the second group of 256 characters - that is, the ones read back from the first 256 screen locations and then written back out to the second 256 locations - look perfect, exactly like the first 256 characters.

In particular, none of the first 128 characters in the second block of 256 have been made inverse.

So why this difference? Is Pettester still behaving the same way / giving the same result as in image #2, post #93? Or has that changed now?

[ScottishColin]

I've fitted a reset switch so I can power off and on without using the mains switch - it starts at inverse a and does not cycle through any other characters. After about 5 seconds, the first character changes to inverse @ and the error message appears.

The 4032 does have the built in monitor but if (as Sirius suggested) it depends on internal RAM working then I'm not sure it'll work.

I have tried the monitor but for whatever reason with only the kernel and the test ROM fitted, it doesn't drop into the monitor but starts the test in the TEST ROM UD7; I'm not sure whether all ROMs need to be fitted?

Colin.


Colin.

Originally Posted by julie_m

Oh, yes. See also, how a stereo amplifier with a fault on one channel is often an easy fix because you basically have another, working one .....

I see the read-modify-write test ended up as a block of inverse "a" characters (&81).

Did it start off very briefly (perhaps even too briefly to be seen) as non-inverted "@" signs and then stick at all inverse "a" ?

Because that would be absolutely consistent with every location in screen memory reading back to the CPU as &80. Though I'm not sure how it's ended up displaying inverse @ in location &8000 where it was writing &01.

That will be my next move, I think.

(Side comment: Does your PET have the built-in machine language monitor?)

[ScottishColin]

The keyboard is mostly working - I've had a quick once over clean of it using my rubbing-the-pads-with-a-bit-of-paper method which has cleared up most keys but there are a few which need another go.

Colin.

Originally Posted by SiriusHardware

The built-in machine code monitor can be invoked by holding the DIAG line low at power-on - however it is unlikely to restrain itself from trying to use system RAM which for the moment we can't assume is working.

Nor do we know whether all the keys on the keyboard are working - traditionally the keyboard is the last or second last thing you have to fix on these.

There would be no harm in trying it though.

[ScottishColin]

Now I'm confused. I've popped the PETTESTER ROM back in and it's the same as image 2 on post 93 which is the same as the 40 column image on P4 of the manual?

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

Colin.

Originally Posted by SiriusHardware

I'm puzzled by one thing: When Pettester stalls on the screen RAM test section the second group of 256 characters - that is, the ones read back from the first 256 screen locations and then written back out to the second 256 locations - look perfect, exactly like the first 256 characters.

In particular, none of the first 128 characters in the second block of 256 have been made inverse.

So why this difference? Is Pettester still behaving the same way / giving the same result as in image #2, post #93? Or has that changed now?

[SiriusHardware]

Now I'm confused. I've popped the PETTESTER ROM back in and it's the same as image 2 on post 93 which is the same as the 40 column image on P4 of the manual?

That's been the problem all along - Pettester halts on the screen RAM test as though it has found a fault but there is no visual evidence of a fault in its results output - apart from that blip that Red To Black found. Julie suggested one possible way this can happen - if, due to a fault, the video output hardware was displaying the first half of the screen memory -twice- and never scanning the second half of the screen memory which also had a legitimate fault in it for Pettester to find, Pettester would halt with a perfect no-faults results display.

That's why we have called in the cavalry (Julie) to get an alternative analysis of the screen RAM. Julie's code is trying to do a more robust test which takes the possibility of that sort of fault into account.

Now we just have to work out why that test code is giving the results it is.

[ScottishColin]

This all feels like progress to me. And if we can get the test to continue ad infinitum on both PETs at the same time, then I can start to take a good look guided by you.

I still wonder about the lack of factory fitted changes that are documented in the Technical Reference manual, but PETs don't always confirm to the schematics as we have found before.

Colin.

[SiriusHardware]

I'm not sure whether all ROMs need to be fitted?

The monitor could have been in the Kernel ROM (that would certainly be a reasonable place for it to be) but as it doesn't work with only that one original ROM in we have to assume that the whole of its code is either in the EDIT ROM (which isn't there at the moment because it is displaced by Pettester and Julie), or could be spread across other ROMs.

[SiriusHardware]

I've looked around a bit and find, as Colin possibly already knew, that the internal monitor can also be entered via a keyboard command

The PET of the CBM series 20xx/30xx/40xx/80xx and CBM-II
series PCs integrates a machine code monitor called TIM (short
for Terminal Interface Monitor).

TIM can be started using one of these commands, although the exact one to use seems to depend on the machine in question.

SYS 4 (normally in PETs)
SYS 1024
SYS 64785 (only CBM series 20xx/30xx)
SYS 54386 (only CBM series 40xx/80xx)
SYS 60950 (only CBM-II series: CBM 500/600/700 series)

Of course the entire BASIC / Command input infrastructure would have to be working in order for this to work, which is probably why the hardware method of entry to the monitor is also provided.

No doubt Colin can try this out on his reference machine, and Julie on her fully working VICE emulated PET.

What I can't find for definite is where the monitor code resides. I had a dissasembly of the BASIC 4 ROMs somewhere but of course I can't find it now.

[SiriusHardware]

By the way Colin, did you try swapping the 2114s to see if that makes Julie's code return a different error? Should only take a minute.

[ScottishColin]

2114s swapped - same outcome.

Colin.

[SiriusHardware]

Fair enough - I know those 2114s are new or otherwise considered good but they needed to be ruled out.