Commodore PET 4032/8050/3022

[SiriusHardware]

And, did you ever verify UD6 (Kernal ROM) from this 4032 machine against its equivalent file on Zimmers?

[SiriusHardware]

Something else I've just thought of - verify the health of the modified Daver2 EPROM you've made by trying it in the UD8 position in your 3016. Although it has a customised CRTC initialisation table in it, your 3016 will ignore any code which aims to set up the CRTC anyway. If it doesn't even work normally in the 3016 that would suggest that the modified Daver2 EPROM is somehow corrupt.

[ortek_service]

Originally Posted by ScottishColin

Just checking - although these are smaller - that they will do the job?

Colin.

Originally Posted by SiriusHardware

Modern capacitors of a given voltage and value are always smaller than the ones from 40 years ago, so provisionally yes, they will be OK to try. You'll need to replace the cooked resistors with any combination of new ones adding up to about 56R.

Fingers crossed, let's hope this was it.

Yes, more-recent ones are now often smaller (with people sometimes 're-stuffing' them inside the original one, to retain the vintage look - but mainly on larger date-coded 'cans' etc) than they were back then, with refinements in their design. As well as maybe other improvements in ESR etc.

However, many manufacturers do several different types, with a 'standard' type, and other-types usually optimised for at least one parameter - sometimes at the expense of another. So Longer Lifetime ones are often in slightly-larger case-sizes, than 'standard ones'. And 'Miniaturised' reduced-size ones might have higher ESR / lower ripple-current rating / shorter lifetime, compared to other types.

I thought I would check to see if these Elna ones were a special reduced-size type, but it seems Elna only did one +85C type in this capacitance and voltage - Luckily a 'Standard' (RE3-Series) type (which I later found 'RE3' was marked on the case of these - in the eBay listings photo of several, with some rotated to be able to see all round the case).

I found that Elna's +105degC RJx types did have a RJ4 'one-size smaller than RJ3' type (already a reduced size version of RJJ type that wasn't produced in high-voltages). But with 0.47uF, they were same size in RJ4 as RJ3 (and RE3 series). And 0.47uF 450V had the same ESR in RJ4 as RE3 type (Although ripple-current rating was a bit lower).
They didn't make 0.47uF 450V in RJ3 series, but did 0.47uF 350V & 315V (same as original C753) in an even-smaller case size, that had a lower ESR (Although strangely also lower ripple-current rating) than RJ3 / RE3 equivalents)

I also found that whilst Elna RJ3 & RJ4 +105C types, are guaranteed for 2000hrs at +105C, but only for 1000hrs (So = 4000hrs at +85C?) in the smaller case sizes of 0.47uF etc values.
Whereas with the RE3 +85C type. the whole series is guaranteed for 2000hrs at +85C, irrespective of case-size - Contrary to the eBay listing of the Elna 0.47uF 450V +85C, that whilst giving the detailed spec's of these only said 1000hrs life. Although the datasheet is a little confusing as it give a 1000hrs (at +85C) 'Shelf Life', but this seems to be in addition to their 2000hrs (at +85C) operating at full ripple-current 'Endurance' life. - See attached datasheet.

The ESR, at 847R, is quite high / Ripple-current rating at 18mA rather low (Although still higher than most other makes we'd looked at) compared to what you might expect of Electrolytics - But this seems typical of the low 0.47uF capacitance Electrolytics, which won't be used on significant-current power rails.


So these Elna RE3-type 0.47uF 450V type, should hopefully be rather more reliable than the part Commodore had originally fitted (I've only once had a high-voltage Electrolytic breakdown when normal high voltage was applied. But it was a much larger 47uF? 400V HT reservoir, and eventually failed short-circuit, so making it easier to find) - which seemed to have often failed in this manner, to burn-out R753 (and also eventually R752 it would seem?)
- Especially with this Elna RE3 type having both longer 2000hrs @+85C lifetime, and also much-higher 450V max. voltage rating.
(And most +105C ones wouldn't really have much better spec. - especially at +85C - due to limitations of small size electrolytics)

Plus do now also have some spares for it / other PET monitors (If they all use a similar circuit), which can be handy when they're not often listed by many distributors / values <1uF in 400V+ are not even made by many others.

[ortek_service]

Originally Posted by ScottishColin

And here we are on post 572.

Thanks for all your help again.

Now onto the peripherals and testing onboard ROM and RAM - this is with the Tynemouth board fitted and fully enabled.

Colin.

Great to see monitor appears to have been rather-more permanently fixed, by just replacing C753! (After also replacing R753 & R752, now they no longer seem to be burning-out).
- Proving to be a little easier, than fixing the main computer board!

And that you've also now got the correct displayed-video on it, after changing the two 2114's, which (both?) were faulty.

Quite a successful day!


Regarding the Keyboard, if some keys are giving the wrong codes, then I wonder if that could be a fault with the matrixing interface, as it doesn't sound like a problem with bad 'switches' which would normally give no / intermittent response.
And presumably why earlier attempts at typing something to get a response, didn't work, as I wouldn't expect faulty Video-RAM's to affect the rest (unless they were on a common-bus without (working) buffers)

It's a little strange that with (all contents verified OK?) ROM's fitted, and Tynemouth board set to use these (but its own 'known good' RAM), that these don't seem to work - When ROM's are straight on the bus without any buffers themselves?

Maybe an address-paging fault, (that the Tynemouth board overcomes with its own address decoding?). And worth checking UE12 74154 4-to-16 line decoder? or UE14 7425 gate?
- Which couldl also affect the main RAM on the PET's mainboard (and possibly the IEEE-488 etc. Interface, as seems unlikely for all lines to be faulty, across 3 buffers / the 6520 has been checked as OK).
So hopefully may not have to socket all eight of the lower-bank of 4116 DRAM's, at least, to run diagnostics on the mainboard / its upper bank

[SiriusHardware]

UE12 (The main address decoder) was already replaced although that proved to be a red herring - to do with one of the address lines of the NOP gen not making relaible contact with one of the input lines of UE12. I don't know if Colin has since put the original UE12 back in, maybe it is faulty after all?

UE14 - I can't remember whether this was already looked at but obviously this whole area is going to have to be revisited again to work out why onboard EPROMs are apparently not working.

I'll begin by asking the question: With all original ROMs in and the Tynemouth board fitted and supplying RAM, but not ROM, how far does it get on boot? Does it chirp? Does the CRTC get activated and wake up the monitor? Does it get to the BASIC PROMPT?

Bearing in mind that for some reason Commodore chose to number the ROM sockets in Descending address order (Kernel=UD6, EDIT=UD7, etc, on this machine, whereas on the 3016 Kernel = UD9, Edit=UD8, etc, are you certain that all ROMs, after socketing, were replaced in the right order / right sockets?

[ScottishColin]

Current state - known working 6520s and 6522 as they are from my 3016 (which is a bit strange that the test program reported all failures but I'm leaving that for now especially as the keyboard has signs of life and the cassette player works.

I have been removing and reseating ROMs and there's a bit of a change in that with the Tynemouth board installed with RAM enabled only, the 4032 now boots with the original ROM set.

If I remove the 3 x BASIC ROMs, leave the kernel ROM in place and install the modified DaveR2 EPROM, I get the attached screenshot and it does not move anywhere from there. The characters are actually fully formed so look a lot better than the photo, but a few of them flicker back and forth between characters.

So a half a step forwards I think.

Colin.

P.S. UE12 has been replaced with a new one.

[ScottishColin]

I believe that the test EPROM will not progress if there are problems with the video RAM?

Are we able to test that more thoroughly?

Colin.

[ScottishColin]

74145 replaced and the keyboard is much happier. I just need to clean it and get it back in place now.

However, to add to my theory re video RAM - see attached screenshot where I am getting spurious characters appearing on the screen during use.

I have checked continuity on all pins of the 2114s (UC4 and UC5) and they're all good.

Colin.

[ScottishColin]

More progress (ish).

Removal and reseated the 21142 and Saves EPROM now runs tests OK. However some of the characters on the screen are still flickering to other characters.

Colin.

[SiriusHardware]

Taking this last statement first and parking everything else for the time being, I think the compressed height of the displayed output from the DR2 test EPROM means that there are currently not enough CRT scan lines per character height to render the characters in full detail.

To roughly illustrate what I mean, imagine that a typical character is six pixel lines high and would normally be displayed over 6 CRT scan lines. If the characters are crushed into the height of only 5 scan lines then the CRT can no longer reliably show all 6 lines of the character, so you may get a situation where characters like 'H' are all missing their middle 'bar' across one or two of the displayed lines.

For this reason, I think it would be worth trying to fix the height output problem on your modified DR2 EPROM.

Can you post the .bin code file (as a zip) which you programmed that EPROM from?

If the DR2 code is consistently, reliably passing the video test stage now then the main suspect for your flickering characters is something between the video RAM and the video output, namely the video latch UB3, the character ROM, the parallel to serial converter UA2 or one of the connections between those three. Try putting some pressure on the character ROM.

[ScottishColin]

I think it's something to do with the video RAM sockets - if I push down on them, the flickering stops. I'll re-solder them.

In the meantime, attached is what I burnt (2 copies of the same 2K file added together).

Colin.

[SiriusHardware]

It sounds as though you are having a problem generally with sockets, ie, 'running from ROM' problems cleared up when you reseated the ROMs - shouldn't be necessary to have to do that but in the case of the ROMs I could understand it because they are old ICs with tarnished, short pins whereas the video RAMs are relatively new and the sockets are brand new.

On the plus side we should be duly amazed that the DR2 code actually passed all of the onboard RAM, or that is my understanding from what you were saying?

I'll take a look at the .bin file.

[SiriusHardware]

I'll assume you are in the process of trying to resolve the video RAM socket problem so I will let you get on with that.

There are differences between the CRTC initialisation table in your modified DR2 test EPROM and what I think should be there.

When you get a moment, read the original DR2 test code into your programmer and then replace the bytes from address 0005 to address 0016 inclusive with exactly these values below.

31 28 29 0F 31 00 19 25 00 07 00 00 10 00 00 00 00 00

The above table of CRTC initialisation values is one of the two which are present in the UD7 ROM, and the one which most closely matches online table values for 'graphic' 4032 CRTC PETs.

Remember of course to mirror the modified code twice in the EPROM, as you have already done before.

[ScottishColin]

Thanks very much - I made a right ricket of that ROM didn't I.

Photos attached of:

1. Dave's ROM now working correctly with the Tynemouth RAM enabled

2. Dave's ROM with the Tynemouth RAM disabled (i.e. it's testing the motherboard RAM).

On the upside, the keyboard is clean, all screwed and soldered back together and put back in place with every key tested and working.

Also, I have tested both Datasette port 1 and 2 and they both work, and we know that the User Port works (or at least I can get sound from it). So that's something.

I will work on the video issue tomorrow - I remembered that the character ROM is still in a white socket so I will remove/replace that tomorrow and update.

Colin.

Originally Posted by SiriusHardware

I'll assume you are in the process of trying to resolve the video RAM socket problem so I will let you get on with that.

There are differences between the CRTC initialisation table in your modified DR2 test EPROM and what I think should be there.

When you get a moment, read the original DR2 test code into your programmer and then replace the bytes from address 0005 to address 0016 inclusive with exactly these values below.

The above table of CRTC initialisation values is one of the two which are present in the UD7 ROM, and the one which most closely matches online table values for 'graphic' 4032 CRTC PETs.

Remember of course to mirror the modified code twice in the EPROM, as you have already done before.

[ScottishColin]

For future reference, I attach a .ZIP of the daver2 ROM file for 4032 CRTC machines with the graphics keyboard.

Colin.

[SiriusHardware]

Thanks for checking those values out, without actually trying it out I couldn't know for sure that that was the right table out of the two to use but it looks a lot better now.

Ref: The second image in #594, there do seem to be problems with the onboard RAM don't there? You've made more great progress today though, especially with the keyboard.

[SiriusHardware]

Not sure where you are up to at the moment, still chasing that intermittent character output problem? If so, need to sort that out properly before attempting to fix the onboard RAM problems.

One line of attack for the video output problems is to make a careful note of which characters are sometimes being displayed instead of the ones which should be displayed, and then compare the PETSCII codes of those two characters to see what the difference is - most likely there will only be a single bit different.

That in turn may lead you to the actual physical connection causing the problem.

[SiriusHardware]

For future reference for anyone, I attach a .ZIP of the daver2 ROM for a 4032 PET (ie 40 column PET with CRTC enabled).

Thanks for that, although we had better point out that it is specifically for 4032 CRTC machines with the graphics keyboard. If you needed it to work with machines having a 'business' keyboard then I think you would need to insert the other table found in the UD7 ROM. (The one underlined in red in the image in #386).

[ScottishColin]

Fixed it - it was one of the replacement 2114s that I recently bought. Swapped it for one from the 3016 and it's all stable now.

So this is the Daver2 screen I now get when I'm testing the on-board RAM. I'm guessing I need to replace some/all of the RAM?

Colin.

[SiriusHardware]

Just what you don't need, bad 'new' ICs. Will you be able to send the duds back, I wonder?

We can maybe get some insight by working out which Main RAM locations are returning 'bad' data (b) and which are returning 'good' (g). I'll have a look at that, if anyone else has any insight please let us know.

Let's be methodical again: On each of the main RAM ICs, check for

+12V on pin 8
+5V on pin 9
-5V on pin 1
0V on pin 16

Be careful not to slip and short pin 8 to pin 9 when making any of these measurements.

After that,

Refit the NOP generator. The display will go off, of course.

Dual trace mode on scope, SINGLE sweep mode, trigger from channel 1, falling edge, and put the channel 1 probe on UE12 pin 1.

Channel 2, probe each of the following pins in turn, triggering channel 1 from UE12 pin 1 as above, to get a general idea of what the D0-D7 data coming out of the RAMs looks like. Adjust time / DIV so that you capture only the first several data pulses coming out of the data pin (between about 5-10 data pulses spread across the screen).

UA19 pin 14
UA17 pin 14
UA15 pin 14
UA13 pin 14
UA11 pin 14
UA9 pin 14
UA7 pin 14
UA5 pin 14

Still with the channel 1 probe on UE12 pin 1 and using the same SINGLE triggering conditions, use channel 2 to capture the activity on the following points just after the falling edge on the signal from UE12 pin 1.

UA4 pin 15
UA5 pin 15
UA5 pin 4

For the above three measurements adjust the time / div until you are capturing one complete low pulse on UE12 pin 1 spread across the screeen and use channel 2 to capture what is happening on the above three lines in turn during that time.