Commodore PET 4016

[julie_m]

While adapting my delay routine to make use of the newly-proven workspace (there's no stack yet, so we can't call subroutines using JSR and RTS; but we can poke JMP instructions into RAM) I found a bug causing it seriously to under-time. Anyway, that's fixed now, though the delay will have changed a bit.

The main change is that the stack and workspace test each other as well as themselves, to prove there are no address clashes between them. (An address clash between either of these areas and the workspace probably would crash the program.) For example, when writing &01 in location &0010, we check for all zeros not only in locations &0000 to &000F and &0011 to &00FF as before, but now also in locations &0100 to &01FF. Such a misread from the alternative block is indicated on the map by an "X". There is also another delay after the end of the stack test, before the zero page test starts, to allow time for photography.

Here's the obligatory screenshot, showing a deliberately-contrived failure:

(This was caused by not changing the alternative block in which to look for address clashes in page &00 instead of &01, while testing page &00.)

And of course, a ZIP file with the quick (i.e., no read-modify-write test on screen RAM) and full tests:
testrom_07.zip

[ScottishColin]

As I have a PET with some interstingly broken symptoms, I want to try Sven's diagnostic clip.

Only problem is the one I built before has failed. I have the relevant spare parts and a spare pcb so I'm going to build that to see what it makes of the current situation.

As it involves SMD soldering (which I hate and am not good at) I will be some time.

https://github.com/svenpetersen1965/PET-Diagnostic-Clip

Colin.

[ScottishColin]

I tried v 1.7 and I got some errors which I previously have not had. I popped v 1.6 back in and there were no errors.

Would you be able to decode these for me please?

Thanks very much.

Colin.

Originally Posted by julie_m

While adapting my delay routine to make use of the newly-proven workspace (there's no stack yet, so we can't call subroutines using JSR and RTS; but we can poke JMP instructions into RAM) I found a bug causing it seriously to under-time. Anyway, that's fixed now, though the delay will have changed a bit.

The main change is that the stack and workspace test each other as well as themselves, to prove there are no address clashes between them. (An address clash between either of these areas and the workspace probably would crash the program.) For example, when writing &01 in location &0010, we check for all zeros not only in locations &0000 to &000F and &0011 to &00FF as before, but now also in locations &0100 to &01FF. Such a misread from the alternative block is indicated on the map by an "X". There is also another delay after the end of the stack test, before the zero page test starts, to allow time for photography.

Here's the obligatory screenshot, showing a deliberately-contrived failure:
Attachment 314019
(This was caused by not changing the alternative block in which to look for address clashes in page &00 instead of &01, while testing page &00.)

And of course, a ZIP file with the quick (i.e., no read-modify-write test on screen RAM) and full tests:
Attachment 314018

[julie_m]

Originally Posted by ScottishColin

I tried v 1.7 and I got some errors which I previously have not had. I popped v 1.6 back in and there were no errors.

Would you be able to decode these for me please?

"v1_7 fail 1.jpg" is saying "misread 0040 as 60 with 01 in 01xx"; which means, while it was testing the stack, it read the value &60 in zero page location &0040 (where it was expecting to see zero) while writing &01 to location &01xx (which must have read back fine, otherwise you would have had a write failure). When this happens, it restores the location it was writing to &00 and moves on to write &01 in the next location. It will read each location up to 255 times in total, up to 8 times for each bit in the byte being written, but it always stops on the first misread with any write location.

"v1_7 fail 2.jpg" is saying something similar, with quite a few locations in page 1 reading as &40 where there should be &00.

I'd suspect noise on the power supply lines to the RAM chips, especially bits 6 and 5. (Does your 4032 pass?) Or maybe the tristate buffers coupling the RAM read signals to the CPU data bus. How are the RAS and CAS lines looking on all the 4116s? Is the one for the chip on D6 different from the others?

[SiriusHardware]

Or maybe the tristate buffers coupling the RAM read signals to the CPU data bus.

Surprisingly (it always surprises me, anyway) there are no intervening data buffers between the system RAM and the CPU in PETs. In fact the following elements of the system are usually connected to the CPU via the unbuffered data bus.

-ROMs
-System RAM
-Large peripheral ICs inc. CRTC, where fitted.

The only significant part of the system which passes data to and from the CPU through intervening buffers is the display RAM, although the data connections at the expansion connector - not normally populated / connected, are also on the buffered databus.

The DRAM RAS, CAS and 'ADDR' signals do pass to and from the system RAM via intervening bidirectional buffers but like nearly all of the 244 buffers, those were already replaced at an early stage in this thread.

One useful dodge for checking 244 buffers so you don't have to buy too many is to socket the two 244 buffers used to buffer the address bus so you can test other 244 buffers in the address buffer sockets: All 16 of the elements of those two buffers are permanently enabled and a NOP test will result in nice stable squarewaves on BA0-BA15 with frequencies halving each time - unless one or more elements in the buffers being tested are faulty.

244 buffers from anywhere else in the machine can be unsoldered and swapped into the address buffer positions and tested in this way, although a purist might say that because the enables for the address buffers are hardwired on, the enable pins of each buffer IC (specifically, their ability to disable the buffers) are not tested.

Of course none of this applies if you have a known working PET which has already socketed 244 buffers in it - you can just test the suspect buffers in that.

[ScottishColin]

I concede defeat withy SMD soldering skills..I'm so ham fisted at that scale.

I'll make a start with the above suggestion tomorrow.

Colin.

[julie_m]

Ah, OK, so there are no buffers to blame this time. Noise on one of the power lines would be the next most likely culprit, then. Also make sure there are no glitches on R/W, D6 (UA7 pins 2 and 14; you may want CAS0 on the other channel for an idea when the RAM is in play), RAS and CAS0. Maybe CAS1 if you're desperate for something to probe onto, but it's more likely to be something mentioned earlier.

What I think is happening is, RAM contents are changing, not immediately but after they have been written. The test ROM is obviously reading correctly, and the screen memory writes and reads back correctly, so that points to the RAM. Version 6 wipes out the stack to all zeros, goes through setting one bit at a time to a one and making sure it reads back as a one and everything else is still zero. It's passing because it's only testing recently-cleared memory. Version 7 wipes out the stack and zero page to all zeros quite early on, wipes out the stack to all zeros again, goes through setting one bit at a time to a one and making sure it reads back as a one, everything else is still zero and all of zero page is still zero. When it does it the other way around to test zero page, it wipes that page but relies on the stack having passed its test and still containing all zeros -- which, again, was several seconds ago. If the contents of memory change during this time, misreads will occur.

I'll craft a new version of my test program to cycle through a page at a time of RAM, testing for readback / stuck zeros and clashes within page / stuck ones, using the page most recently tested for the alternate block address clash / stuck one test this time. I'll do this still by executing code from the display static RAM, which appears sound, as zero page and the stack cannot be trusted. I can even chop out the screen memory test if I really need the space. It's the main, dynamic RAM where the "interesting" stuff is happening, and it would be nice to see how much else is affected and maybe get some sort of a handle on what is going on.

[SiriusHardware]

If space is a problem then I can't see any reason not to have separate specialised screen memory tester and specialised very thorough main system memory testers as separate EPROM utilities.

If each of those far exceeds the thoroughness of anything else which currently tests the same areas then it will be well worth the minor inconvenience of having to keep two EPROMs handy, rather than just a single swiss-army-EPROM.

Colin's last PET revival had an interesting final fault on the system RAM, where the PET's own write 55 / read back / write AA / read back system memory test was passing the RAM, as was the system RAM test on the Tynemouth Diagnostic gadget. However the 'march-C' portion of Pettester's system RAM test was finding a problem which wouldn't go away until the chip being pointed to by Pettester was replaced.

[ortek_service]

Originally Posted by ScottishColin

I concede defeat withy SMD soldering skills..I'm so ham fisted at that scale.

I'll make a start with the above suggestion tomorrow.

Colin.

Not sure if you have a Digital etc. Microscope (they can be obtained from around £50 upwards) / maybe a variable-magnification USB microscope with stand or a good-magnification illuminated magnifier (/ a jewellers eye piece 'lube' around 4x magnification taped onto the side of one) as these are very-useful for SMD work to very-fine pitches.
Also useful is very-fine solder (>= 26swg like 34swg etc), the smallest size ('0' or '00' etc)) desolder braid, if solder shorts across pins, and smallest soldering-iron tip. Plus some non-magnetic precision fine point t/ angled-flats tweezers.
It should then be much-easier to work with most SMD's (especially the larger ones, that you may get away without magnification with the good close-up eyesight / glasses).

[ortek_service]

Originally Posted by ScottishColin

Based on nothing other than my recollection, I would have the following spares if I were a PET engineer:

244 (always at least one fail on each PET so far)
2114 (always at least one fail on each PET so far)
3446 (always at least one fail on each PET so far)
4116 (mostly at least one fail on each PET so far)
6520 (mostly at least one fail on each PET so far)

I have a few of most of those except for 6520s which I'm going to need a couple of to finally fix this PET.

Colin.
>>
>>

It's surprising that all the other 'Logic' IC's have been quite-random across the various PET's and not failed on all / most. But if particular ones have failed on >= 2 PET's you have, then they are probably worth always keeping at least one of for a possible replacement use in the future.
.

[SiriusHardware]

I concede defeat withy SMD soldering skills..I'm so ham fisted at that scale.

I work on SMD all the time, if you want to whizz the relevant PCBs / components down to me I will turn them around as quickly as I can (but if you do, time them to arrive early in the week so I can do it at work where I have better working conditions).

[ScottishColin]

I do have all of the below, but sadly I think the issue is me. I have a slight shake on my hands when I'm trying to solder that isn't an issue with through hole soldering but is for SMD.

I have asked Sven if he'd be so kind as to look at his design to remove the SMD devices and replace them with through hole and await an answer.

The project is licensed under GNU General Public License v3.0 terms and the Eagle and Gerber files are there if anyone who understands pcb design wants to have a go.

https://github.com/svenpetersen1965/PET-Diagnostic-Clip

Colin.

Originally Posted by ortek_service

Not sure if you have a Digital etc. Microscope (they can be obtained from around £50 upwards) / maybe a variable-magnification USB microscope with stand or a good-magnification illuminated magnifier (/ a jewellers eye piece 'lube' around 4x magnification taped onto the side of one) as these are very-useful for SMD work to very-fine pitches.
Also useful is very-fine solder (>= 26swg like 34swg etc), the smallest size ('0' or '00' etc)) desolder braid, if solder shorts across pins, and smallest soldering-iron tip. Plus some non-magnetic precision fine point t/ angled-flats tweezers.
It should then be much-easier to work with most SMD's (especially the larger ones, that you may get away without magnification with the good close-up eyesight / glasses).

[ScottishColin]

That's very kind (again). Thanks very much.

I'll pull them together over the next couple of days.

Colin.

Originally Posted by SiriusHardware

I work on SMD all the time, if you want to whizz the relevant PCBs / components down to me I will turn them around as quickly as I can (but if you do, time them to arrive early in the week so I can do it at work where I have better working conditions).

[ScottishColin]

Thanks so much for all the time you're putting into this.

fyi the 4032 motherboard passes just fine.

This is perhaps too much of an ask, but when you have a settled codebase, would it be possible to put together a manual/guide document as well (told you it was cheeky).

For example in your post #324, how did you get to D6 and D5 from those error messages?

Thanks again.

Colin.

Originally Posted by julie_m

Ah, OK, so there are no buffers to blame this time. Noise on one of the power lines would be the next most likely culprit, then. Also make sure there are no glitches on R/W, D6 (UA7 pins 2 and 14; you may want CAS0 on the other channel for an idea when the RAM is in play), RAS and CAS0. Maybe CAS1 if you're desperate for something to probe onto, but it's more likely to be something mentioned earlier.

What I think is happening is, RAM contents are changing, not immediately but after they have been written. The test ROM is obviously reading correctly, and the screen memory writes and reads back correctly, so that points to the RAM. Version 6 wipes out the stack to all zeros, goes through setting one bit at a time to a one and making sure it reads back as a one and everything else is still zero. It's passing because it's only testing recently-cleared memory. Version 7 wipes out the stack and zero page to all zeros quite early on, wipes out the stack to all zeros again, goes through setting one bit at a time to a one and making sure it reads back as a one, everything else is still zero and all of zero page is still zero. When it does it the other way around to test zero page, it wipes that page but relies on the stack having passed its test and still containing all zeros -- which, again, was several seconds ago. If the contents of memory change during this time, misreads will occur.

I'll craft a new version of my test program to cycle through a page at a time of RAM, testing for readback / stuck zeros and clashes within page / stuck ones, using the page most recently tested for the alternate block address clash / stuck one test this time. I'll do this still by executing code from the display static RAM, which appears sound, as zero page and the stack cannot be trusted. I can even chop out the screen memory test if I really need the space. It's the main, dynamic RAM where the "interesting" stuff is happening, and it would be nice to see how much else is affected and maybe get some sort of a handle on what is going on.

[ScottishColin]

For whatever reason the Tynemouth diagnostics board is now reporting an error in low RAM for D6 so I think that's the place to start.

Colin.

[julie_m]

Originally Posted by ScottishColin

Thanks so much for all the time you're putting into this.

fyi the 4032 motherboard passes just fine.

That's fine. I just wanted a bit of reassurance therwe was not some quirk of VICE causing it to pass a test a real PET would fail. I was sure a real PET should never have passed in that state, but it's nice to have confirmation!

Originally Posted by ScottishColin

This is perhaps too much of an ask, but when you have a settled codebase, would it be possible to put together a manual/guide document as well (told you it was cheeky).

For example in your post #324, how did you get to D6 and D5 from those error messages?

For sure -- I'm planning to start a GitHub repository for it, and that will include some documentation.

To answer the immediate question first, I got D6 from the misread hex value 40.

D0 is the "units" bits of the data bus, D1 is the "twos" and so forth up to D7 which is the "128s" -- or 80 hex, as this table shows:

DATA BIT | DECIMAL | HEX
---------+---------+-----
D0       |       1 |  01
D1       |       2 |  02
D2       |       4 |  04
D3       |       8 |  08
D4       |      16 |  10
D5       |      32 |  20
D6       |      64 |  40
D7       |     128 |  80

Reading back hex 40 means D6 was high when it should have been low. There were also some 60s in the first test, which indicates D5 was high when it should have been low.

New test program should be ready to go tonight.

[ScottishColin]

So let me make sure I have this straight.

40h is 01000000 in binary which means that bit 6 is is error.

60h is 01100000 in binary which means that bit 6 and bit 5 are in error.

Do I have that right?

Colin.

Originally Posted by julie_m

Reading back hex 40 means D6 was high when it should have been low. There were also some 60s in the first test, which indicates D5 was high when it should have been low.

New test program should be ready to go tonight.

[ScottishColin]

I've replaced UA7 and it now passes Julie's tests (v 1.) ok.

However it still freezes during the PETTESTER memory test and also when I boot with onboard RAM enabled, I now get 7216 bytes free (which is different from before).

Off to replace UA9 now.

Colin.

[julie_m]

Originally Posted by ScottishColin

So let me make sure I have this straight.

40h is 01000000 in binary which means that bit 6 is is error.

60h is 01100000 in binary which means that bit 6 and bit 5 are in error.

Do I have that right?

Colin.

Yes, that's right. Apologies for forgetting converting between binary, hex and decimal doesn't come as naturally to everyone!

[ScottishColin]

OK - we now have a functioning 16K PET reporting 15359 bytes free which is correct.

Interestingly it doesn't pass PETTESTER as it still freezes.

I'll wait for a new release of Julie's code before I progress - I know I have lots of 4116s to put in into the upper bank (at least 6 I think) so I still have some known errors to test with. I'll also need to change the jumper to 32k. I bet I forget that first time and wonder why it still passes at 16k.

Colin.