Commodore PET 4016

[SiriusHardware]

I've just had another thought Julie - you may need to edit the CRTC controller setup data in your test code because this is a 40-column CRTC PET, and Dave's default setup values are for an 80-column PET, unless you have already noticed that and taken it into account?

The version of Pettester that Colin has in EPROM is probably a 40-column specific version which he customised a while ago.

[TonyDuell]

Originally Posted by SiriusHardware

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

The screen is not bitmapped. Each RAM location stores the PETSCII code of the character there. The code is read out repeatedly on each of the scan lines for that character, sent to the character generator ROM along wth the scan-line-in-the-character number (from the 6505). The character generator ROM outputs the appropriate row of the bitmap which is loaded into the video shift register, serialised, and sent to the video amplifier.

If there is a problem with one of the 2114s then most likely swapping them will cause a different glitch at the same location on the screen

[SiriusHardware]

..So noted. It might be quite hard to notice the difference.

[ScottishColin]

Evening. Postie has been ad I have the relevant number of chips now so I have a reference 4032 booting up OK and the 4016 fully populated too.

Current plan is for me to test all of the chips that can be removed from the 4016 in the 4032 to make sure they are all OK.

In terms of the 4016, with the new chips in, I still get the same front stuck screen on the PET Tester software but without the glitch that was noticed earlier so either that's gone as a result of the chips or it was a momentary artefact that was partially captured by the camera shot I took at the time. Whichever, it's not there.

In terms of the code Julie has created, which socket should it go in and are there any pre-reqs (eg the Kernel ROM being present)?

I'll get on with testing the chips as above and report back hopefully later on.

Colin.

[ScottishColin]

I didn't answer this - apologies.

The PET can be coaxed to boot to BASIC with the use of a ROM/RAM emulator, but because the video sub system has a problem somewhere, I can type individual lines of code but when I press enter, the PET does not recognise what I have typed.

See attached photo for an example of what happens when I press Enter.

Colin.

Originally Posted by ortek_service

I did later wonder about that.
But if only this test was a bit more-informative of exactly where it had detected an error and could try and report this rather than just stopping at this point (well after it has displayed all the characters rather than stopping at where it thinks there is a problem).
I presume Tynemouth Diag also does a read-back test on this area of memory, and may report actual error / location?

If it will actually boot into BASIC, and the keyboard does work (Maybe using a RAM/ROM replacement board, if still issues with the on-board memory), then it might be possible to write a small program to write & read-back screen RAM to try and find the fault that way.

[ScottishColin]

All swapped between 4032 and 4016 that I can swap and the ones that work in the 4032 are back in the 4016.

Just to give a quick updated with what is now socketed, it is the following:

All 40 pin chips - 6502, 2 x 6520, 6522 and HD46505

All 244s (9 of them)

Both 2114 video RAM chips

4032 PET Tester ROM and 901465-22 kernel ROM are socketed; all other ROMs are removed

Character ROM is socketed

Colin.

[SiriusHardware]

I expect that Julie has designed her test EPROM code in such a way that it can be inserted in place of the EDIT ROM / EPROM or Pettester - the CPU jumps briefly into the 'Kernal' ROM first at startup before being directed into the EDIT ROM or whatever is occupying its socket, so the Kernal ROM needs to be in its usual spot and the test EPROM, whether Pettester or Julie's Screen Ram Test, in the EDIT ROM position.

I still get the same front stuck screen on the PET Tester software but without the glitch that was noticed earlier so either that's gone as a result of the chips or it was a momentary artefact that was partially captured by the camera shot I took at the time. Whichever, it's not there.

OK - If and when you can get to that point, let's see what Julie's test code can tell us about the problem. Exciting stuff.

[TonyDuell]

A few quick thoughts:

Check that _all_ of the links are set for 40 columns, not 80 columns.

Given the poor conditon of the machine, is it possible that there are corroded traces on the PCB?

I'd next check the video address multiplexer (sheet 7 of the schematic I'm using, UC8, UC9, UC10

[ScottishColin]

Something else to be cautious of - the motherboard is a 8032079 as per page 21 of the attached file, but it does not have any other mods that are documented on p 20.

http://cini.classiccmp.org/pdf/Commodore/CBM%204016-4032%20Tech%20Ref.pdf

So I cannot be certain that the schematics are accurate for this motherboard..

The markings on the top of the board are:

80 Column CPU ASSY NO 8032080

The markings on the reverse of the board are:

FAB NO 8032079
ARTWORK NO: 8032078 REV A

Colin.

[ScottishColin]

Yes - already checked the 40 column links. While I was there, I noticed that one f the links has been moved but it is the one for 16K or 32K of RAM and has been moved to 32K which makes sense as all the RAM locations are now populated and it's clear from the underneath that they have been added later (but sadly not socketed).

Colin.

Originally Posted by TonyDuell

A few quick thoughts:

Check that _all_ of the links are set for 40 columns, not 80 columns.

Given the poor conditon of the machine, is it possible that there are corroded traces on the PCB?

I'd next check the video address multiplexer (sheet 7 of the schematic I'm using, UC8, UC9, UC10

[ScottishColin]

There was one cut track (see post 37) and a non-standard connection that looked very much like it was not done at the factory - I have removed the connection (it was UD4/11 to UC3/3 and reinstated the cut track.

I contacted the Supersoft owner and he said that they never shipped devices which needed the end user to cut tracks (as this device had the Supersoft High Resolution Graphics installed which I have removed) so it wasn't for that board.

The UD4/11 to UC3/3 connection - is there any sense in that having been there?

Colin.

Originally Posted by TonyDuell

A few quick thoughts:

Check that _all_ of the links are set for 40 columns, not 80 columns.

Given the poor conditon of the machine, is it possible that there are corroded traces on the PCB?

I'd next check the video address multiplexer (sheet 7 of the schematic I'm using, UC8, UC9, UC10

[TonyDuell]

Assuming the ICs are as on the schematic I'm working from, the that modification is not insane. It would change the timing of singals to the DRAM (the main 32K of RAM) by replacing phi_2 by a slightly delayed version of it.

I don't see how it could affect the video RAM though.

[ScottishColin]

OK - code burnt and run.

First screen (all OK) is the working 4032.

Second screen (all @) is the 4016

By the the looks of the screen, the code does need adapted to run on a CRTC enabled PET, but it ran.

My money is still on some poor soldering by me.

Colin.

[ScottishColin]

Thanks for taking a look.

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

Colin.

Originally Posted by TonyDuell

Assuming the ICs are as on the schematic I'm working from, the that modification is not insane. It would change the timing of singals to the DRAM (the main 32K of RAM) by replacing phi_2 by a slightly delayed version of it.

I don't see how it could affect the video RAM though.

[julie_m]

Hi Colin,

I was going to say the ROM with the test code needed to go in place of the edit ROM, but by the time I got my Mac booted up, you'd already run it! Thanks.

That failure screen is "readback error, location 8000". Unfortunately, the actual misread character is off the screen. If the CRTC parameters I used were incorrect for your machine, that won't have helped much .....

It wrote some value -- probably 1 -- to location &8000. It then EORed the value still in the accumulator with what it read back from that location. If the relevant bit of the relevant byte was working, the result would have been zero. The BEQ on line 136 fell through; so it wrote the contents of the Y register (0-7 for 1, 2, 4, 8, 16, 32,64, 128 respectively) to &8008, and filled &8009-&80FF with the address where the error occurred.

One possible cause for this might be failure of the tristate buffers coupling the video RAM data lines to the CPU data bus during read operations (R/W high). That memory could well be fine; the CPU seems to be able to write to it, and the CRTC can read from it. But if the CPU couldn't read back from it, that could certainly cause counter-intuitive behaviour.

I'll rework the error display routine to produce something that should be more informative as long as the display circuitry is behaving (and I think it is). If you can post a PetTester ROM that displays properly on your PETs, I ought to be able to find the CRTC initialisation sequence it's using and borrow that.

[SiriusHardware]

Julie: You may find this post from an earlier thread useful.

https://www.vintage-radio.net/forum/showpost.php?p=1578021&postcount=593

[julie_m]

Ah, that looks like the business I'll use those parameter values in my next version.

I've also thought of a new test I can add: read-modify-write on the first 256 bytes of screen memory. If I fill them all with zeros for @ signs and INC each byte in turn, 256 times; then, if the CPU is reading screen memory correctly, they should cycle through the full character set and back to @; whereas if the CPU is reading all 1's when it tries to read the screen memory, everything will change to "@" signs and stay like that. I'll waste a few million ticks to leave the result sitting on screen for a few seconds, then carry on with the workspace test.

[ScottishColin]

I amended the code so it initialises the CRTC correctly.

Attached is a screenshot of the working 4032 and the failing 4016. The only thing to note (I think) is that the failing screenshot has an inverse first character.

I attach the code in case anyone wants it.

Colin.

[SiriusHardware]

Interesting result - good that you were able to modify the CRTC initialisation table to make the result visible on the screen. That wasn't actually guaranteed to work, it depended on Julie having left the initialisation table in the exact same location in her test code, but apparently she has. Any future version of the test code will already have that table modified, I imagine.

It will be interesting to see what Julie makes of the result from this version even though she is already working on a more advanced version.

One thing Julie said earlier, I will pick up on:

One possible cause for this might be failure of the tristate buffers coupling the video RAM data lines to the CPU data bus during read operations (R/W high).

These would be the 244 buffers which are indeed often the cause of problems on these machines, however they have already been replaced in this case - but it is possible that whatever read / write signal should be toggling them between 'transmit' and 'receive' mode is missing.

[ScottishColin]

Yes - I checked the code in Dave's PETTESTER v4 code against the 4032 version I created before I made the changes to Julie's code.

Colin.

Originally Posted by SiriusHardware

Interesting result - good that you were able to modify the CRTC initialisation table to make the result visible on the screen. That wasn't actually guaranteed to work, it depended on Julie having left the initialisation table in the exact same location in her test code, but apparently she has. Any future version of the test code will already have that table modified, I imagine.

It will be interesting to see what Julie makes of the result from this version even though she is already working on a more advanced version.

One thing Julie said earlier, I will pick up on:

These would be the 244 buffers which are indeed often the cause of problems on these machines, however they have already been replaced in this case - but it is possible that whatever read / write signal should be toggling them between 'transmit' and 'receive' mode is missing.