Commodore PET 4016

[ScottishColin]

All of the RAM chips are soldered direct but I don't think we can assume that many if any are working.

I'll try Sirius' suggestion in post 191 but I think I'm looking at buying a few 4116s (I have 3 spare here right now).

Colin.

Originally Posted by julie_m

Location &0120 is in main RAM -- the 6502 stack is at locations &0100-&01FF, so this is the second page tested. Once we have a stack, we can use JSR and RTS. Zero page (&0000-&00FF) is tested last -- we don't desperately need the indirect addressing modes; as long as we have RAM somewhere, we can build up instructions and execute them there. (That's what's going on with the top line of the screen.)

I'm going to improve the error reporting -- I've seen a better way of doing this and giving a visual handle on everything, now I can be confident that the display is good -- and I'll be back with a new test ROM image soon.

[SiriusHardware]

Julie's code reporting an error in page one backs up Pettester (and Tynemouth Diags) assertion that there are major system RAM problems. At least in that respect it seems to be a unanimous vote.

Tynemouth Diag's insistence that there are still problems in the video RAM is a mystery though - Pettester thinks it is now good to go and the small subset of video RAM that Julie currently tests must seem OK for it to get past there to the point of testing page 1, perhaps we'll know more once it is able to test the whole of the screen RAM.

I am going to suggest we set aside the TD screen RAM fault report until we run into some problem which leads us to look at it again - although I hope Julie will continue to hone and refine that aspect of her test code because it's now clear that the screen RAM test in Pettester needs 'hardening'. While she's working on that maybe we should focus now on getting the main RAM working.

I agree that you are probably going to need a few extra RAM ICs.

[SiriusHardware]

Going back to the Tynemouth Diag output (second attachment in #190) it looks like only bits 0 and 4 are dud in the first half of system memory, so potentially only two chips needed to get that bank fully working.

Maybe go for those first, and if you can sort that out the machine should boot as a functional 16K machine?

[ortek_service]

Originally Posted by 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.

Thanks for the info on what it is doing here - I've only just had chance to catch up with this thread.

However, video sub-system issues shouldn't really be causing syntax errors.
So assuming the keyboard is actually providing the right key codes, then it would seem there are main RAM (or possibly one of the ROM's) issues (Could also be buffers etc. rather than the Memory IC's themselves, or maybe refreshing of the main DRAM's is not working properly?).
Is it possible to use the RAM/ROM from one of the Tynemouth etc boards, to replace the internal memory, to see if that the does respond to type BASIC commands OK?

[SiriusHardware]

Is it possible to use the RAM/ROM from one of the Tynemouth etc boards, to replace the internal memory, to see if that the does respond to type BASIC commands OK?

It is, and I believe Colin tried this a few posts ago - it's a fast moving thread so easy to miss details when speed reading a couple of days worth.

I put a ROM/RAM emulator in set to use the ROM and RAM from the device (not from the PET motherboard) and it boots up fine.

We are fairly sure there are problems with the machine's own system RAM, three different testing methods all say so so I think fixing that will be the next major job on this machine.

This is very much par for the course with these machines, you fix one problem only to run straight into the next one. It's very, very rare for them to have just one thing wrong with them.

[ortek_service]

Originally Posted by SiriusHardware

It is, and I believe Colin tried this a few posts ago - it's a fast moving thread so easy to miss details when speed reading a couple of days worth.

We are fairly sure there are problems with the machine's own system RAM, three different testing methods all say so so I think fixing that will be the next major job on this machine.

>>

I think I've not got through all the pages of posts in the last few days!

As I understand it, it was also booting into BASIC OK with the on-board memory - But this didn't respond to BASIC commands correctly.

So although it was booting into BASIC OK with the ROM/RAM board, I wondered if BASIC commands would actually work OK with that?
(if it seems it is most-likely that corrupt workspace / the 6502 stack in main RAM could be causing the syntax error problem?)

I'm not sure if the now found (& now fixed! - by replacing the UD15 7417) problem with READ_EVEN would affect this, if that is just used for the screen RAM access by the 6502.
But maybe every little helps in diagnostic tests running correctly (especially if they are reliant upon the screen RAM reading back OK to the 6502)

[ortek_service]

Originally Posted by SiriusHardware

Julie's code reporting an error in page one backs up Pettester (and Tynemouth Diags) assertion that there are major system RAM problems. At least in that respect it seems to be a unanimous vote.

Tynemouth Diag's insistence that there are still problems in the video RAM is a mystery though - Pettester thinks it is now good to go and the small subset of video RAM that Julie currently tests must seem OK for it to get past there to the point of testing page 1, perhaps we'll know more once it is able to test the whole of the screen RAM.

I am going to suggest we set aside the TD screen RAM fault report until we run into some problem which leads us to look at it again - although I hope Julie will continue to hone and refine that aspect of her test code because it's now clear that the screen RAM test in Pettester needs 'hardening'. While she's working on that maybe we should focus now on getting the main RAM working.

I agree that you are probably going to need a few extra RAM ICs.

I wonder if TD thinking there are still video RAM errors is due to it being reliant upon other memory areas working correctly - like the 6502 stack etc?
I did think it tried to avoid the use of main RAM, but maybe it has done a simple test first, and determined it might be safe to use a part of this to hold a copy of data being stored to screen RAM for comparison / a counter etc local variable there ?

Maybe, if the screen-RAM is even-more prone to failure than the main-RAM, then can't usually rely on using that. But fortunately this has been found to be OK (for writing to to start with), for Julie's code to work using that
- Although I seem to remember that Colin had already changed these 2x 2114's nut can't recall if the original ones were actually faulty or just suspected to be (as often are!), due to the rather strange fault symptoms that the display-side had been giving.

[ortek_service]

Originally Posted by SiriusHardware

Going back to the Tynemouth Diag output (second attachment in #190) it looks like only bits 0 and 4 are dud in the first half of system memory, so potentially only two chips needed to get that bank fully working.

Maybe go for those first, and if you can sort that out the machine should boot as a functional 16K machine?

Yes, might as well go for the suspect ones - one at a time, socketing these and verifying that the removed IC was really faulty in the working 4032 (Which could also be used as a temporary donor for the 4016, assuming the 4032 does have a few of the 4116's socketed?).

It would be useful to know exactly how many 4116's are required to fix the 4016, before ordering any, to save having to re-order more. Although it's probably not a bad idea to get a good stock of these, for future use, if you find a good-priced in moderate quantities source for these.

Luckily these widely-used 4116's still seem to be available at reasonable prices, compared to some other much-rarer RAM types. IIRC, I picked up many tubes of these at a Rally years ago, that I mainly used for fixing Spectrums, although I don't often see that many RAM IC's like this at Rallies anymore.

[ScottishColin]

OK - I have reinstated the cut track on UC3/3 and removed the link to UD4/11.

While the RAM errors still exist, the Tynemouth Video RAM errors have gone.

Onto the RAM.

Colin.

[ScottishColin]

I had both ROM and RAM enabled on board the Romulator so it wasn't using any of the motherboard ROM (mostly absent right now - not tested yet) or RAM.

Colin.

Originally Posted by ortek_service

I think I've not got through all the pages of posts in the last few days!

As I understand it, it was also booting into BASIC OK with the on-board memory - But this didn't respond to BASIC commands correctly.

So although it was booting into BASIC OK with the ROM/RAM board, I wondered if BASIC commands would actually work OK with that?
(if it seems it is most-likely that corrupt workspace / the 6502 stack in main RAM could be causing the syntax error problem?)

I'm not sure if the now found (& now fixed! - by replacing the UD15 7417) problem with READ_EVEN would affect this, if that is just used for the screen RAM access by the 6502.
But maybe every little helps in diagnostic tests running correctly (especially if they are reliant upon the screen RAM reading back OK to the 6502)

[ScottishColin]

OK - UA11 and UA19 replaced and the lower bank now passes the Tynemouth diags.

I'll turn it into a 16k machine and see what happens next.

Colin.

[ScottishColin]

OK - we now have a PET that will boot into Dave's PET Tester and run the RAM tests - I haven't let it go yet to see what it finds.

It passes the RAM test o the lower bank of the Tynemouth board.

Interestingly when I use the other Tynemouth ROM/RAM emulator and set it to use the RAM off the motherboard, it boots fine but only reports 7224 bytes free instead of 16k.

I'll let a soak test of Dave's memory tester run later on today and report back.

Colin.

[ScottishColin]

It also passes Julie's v3 testing all ok now too with the 16k jumper installed.

Dave's testing running now for a while.

As an aside, I found out what happens if you plug in a 4116 the wrong way round:

1. it gets hot
2. it actually affected the display in that the Tynemouth diagnostics board runs but the screen is corrupt.

Colin.

[ScottishColin]

OK - it won't run Dave's test as it gets stuck on the first memory test and will not progress.

I've re-run the Tynemouth diagnostic and it now claims a further memory chip has failed in the 16k so I'll replace that one and see what happens.

I think some of these chips are on the edge and I may end up replacing a lot of them.

Colin.

[SiriusHardware]

OK - I have reinstated the cut track on UC3/3 and removed the link to UD4/11.
While the RAM errors still exist, the Tynemouth Video RAM errors have gone.

What the...? Never mind, we'll accept that gratefully.

I'm glad I nagged you to try changing it again, although I only had a vague notion that it might help. I can't help but imagine that cut track + wire link was something to do with the add on board, even though the OEM said their gear never required track cuts.

It would be surprising if the 4116 which was in the wrong way / got hot survived completely unscathed to be honest, as it will have hard 12V applied to a pin which should never see that sort of voltage. I would usually assume that a chip which has been inserted 180 out and powered up will have some degree of damage.

Apart from that you seem to be generally moving forwards and doing well. I guess you're mainly now waiting for some more RAM.

[ScottishColin]

I've ordered some more RAM but in the meantime we've had another interesting failure.

The screen started to wobble then lost all characters to be replaced with an unusual 'fizzing' type noise from the monitor and a collapsed screen display which swiftly got turned off.

I've taken a look at HSync and VSync on the CRTC chip (page 10 of 11 the schematic) and they both have signals and what I think are the correct frequencies - 50Hz VSync and 20KHz on HSync.

I've then gone to pin 4 and pin 1 of UC2 (same page of schematics) which is marked as F7486PC QM7948 and I can see those waves/frequencies there. What I can't see is them coming out of UC2 on pins 6 and 3 - should I see those waves and frequencies there too?

I have removed the montor plug from J7 while I'm doing all of this testing.

Colin.

[TonyDuell]

Yes, you should see similar waveforms on pins 6 and 3 of UC2.

UC2 is a 7486 (that's the important bit of the marking). It's 4 XOR gates. An XOR (Exclusive OR) gate has the following truth table :

Input Input Output
0 0 0
1 0 1
0 1 1
1 1 0

In other words it's like an OR gate but it excludes the 'both true' case. A look at the truth table shows that if you XOR a signal with 0 then it is unchanged. If you XOR it with 1 then it's inverted. That's what is done here. One input of each gate is either tied low (0) or high (1) by a link. So the output is either the sync signal from the CRTC or its inverse (I think the links were set differently for different types of monitor PCB).

[SiriusHardware]

And it was going so well!

As I'm sure you know, your logical, methodical process of tracing appears to have revealed a failure of the monitor-facing outputs of UC2. It will also be worth looking to see if you still have video-out on UC2 pin 8 - that output may be damaged as well.

It's mildly worrying that this has happened and I wonder if it was triggered by something else - for example if the 0V connection between the mainboard and the monitor, which runs on 12V, failed high resistance, that could lead to out-of-limit voltages being fed back to the other still connected connections.

Order a replacement 7486 but, as per your usual cautious habit, order at least two and check carefully for cracked joints and bad connections on the pins and plugs at both ends of the monitor connection cable.

Edit: crossed with Tony.

[ScottishColin]

Thanks Tony/Sirius.

It's a fighter this one.

Two ordered.

Colin.

[ScottishColin]

In the meantime, I read this in post #187:

"I mean to circuit 0V, which may or may not be GND as well, depending on how you define GND."

As you know, I'm a complete idiot electronically.

Could someone educate me regarding my confusion between 0v and earth/ground please?

Thanks.

Colin.