Commodore PET 2001

[ajgriff]

Agreed and I'll knock the dust off the Raspberry Pi.

Alan

[SiriusHardware]

I thought I might be able to encourage you to do that by telling you there is a PET emulator, called VICE, for Linux - I think Slothie mentioned it recently. It should be able to run on a Pi but I can't find VICE in the Raspbian repositories although that does not mean it is not there, my Linux-Fu is not up to much.

If it's really not in the repos (repositories) then you could get it from the developer's website here:-

https://vice-emu.sourceforge.io/

It looks like they expect you to download the 'tarball', unpack it into a folder and then compile it, which you may be OK with.

[ortek_service]

Originally Posted by ajgriff

Having carried out some further checks this morning with 'scope and meter I think it's worth summarising the evidence as I see it. Please bear in mind that the PET was fully operational using NivagSwerdna's 8k system RAM card until Sunday morning when the random character screen re-emerged.

>>
>>


PSU Rails - the 5V rail supplying the ROMs appears to be being pulled down by 0.1V.

My overall conclusion to this is that one of the system ROMs has failed (likely) or that one of the unsocketed logic/buffer chips has given up the ghost (less likely). Although I'd not originally envisaged spending much money on this little project I'm inclined to think in terms of buying a ROM/RAM emulator. All thoughts/suggestions welcome.

Alan

Have you tried the sometimes-useful 'finger-test' on top of the ROM's? i.e. Put your finger on each in turn, and see if one is running much hotter (Warning: If you end-up with a reverse-image of the part number burnt-into your finger, then it's definitely faulty!)

It seems Commodore / MOS ROM's often run rather-warm, so a relative-check may help pin-point the most suspect one. And so in the absence of having an IR thermal-imaging camera (that some / 'phone adaptors are now getting affordable), then seeing if anything is getting excessively hot by touch may be helpful.
There's also tricks with freezer spray, to see what melts quickest, but more for intermittent faults - I once had a Spectrum Z80A CPU that only worked for about the first 10secs, and cooled it with some liquid-butane from a cigarette-lighter refill to prove it was this as didn't have any freezer-spray.


A more scientific method would be to measure the supply current to each of the ROM's. And could do this by stacking a couple of IC sockets, but breaking the connection to the Vcc pin between the added sockets and inserting a DMM on mA range. You could then compare currents between these / might be some data on what they normally should be.

You could also do similar to the 7805 ROM's regulator input / output pin, but would have to desolder it to lift / cut leg and resolder afterwards (unless there's any series low-ohm resistors / suppressor inductors / ferrite beads). But you would need to know what expected current load is, if not given in service info. 4.96V is well within O/P voltage Spec. so wouldn't normally be suspicious, if it wasn't for it previously measuring higher.
I presume you measured between the same points both times, as can sometimes get quite a bit of voltage drop on the tracking / rise of ground-voltage due to this.

[ajgriff]

The small voltage discrepancy may well turn out to be a red herring and until I've got a more positive indication of ROM failure I'm not thinking of messing around with the main board. Temperature wise the ROMs do indeed run quite warm but no one chip seems to get appreciably hotter than the others judging by a basic finger test. We'll see what happens once the emulator is installed.

Alan

[SiriusHardware]

I would also expect that each otherwise identical PROM would draw a slightly different current due to their mask-programmed contents being different. (Bits which are programmed 'high' will draw a different amount of current to bits programmed 'low'). I think replacement / substitution / verification (by whatever means) is the decisive way to go.

[ajgriff]

Originally Posted by SiriusHardware

I thought I might be able to encourage you to do that by telling you there is a PET emulator, called VICE, for Linux ....

Before I consider venturing into the mysterious world of machine code, with all its unfamiliar acronyms and terminology, I'll carry on with the hardware approach until I've at least got the PET functional again (hopefully). However, your efforts are appreciated Sirius.

Alan

[ajgriff]

Does anyone think that there is some significance in the fact that the CPU's address lines are being held high?

Alan

[SiriusHardware]

There are a number of 'unofficial' opcodes which, if encountered, will 'stun' the 6502 and put it into an endless holding mode. In the normal scheme of things the processor would never encounter one of these instructions but if you have a ROM problem (for example) then it is possible that the CPU could be reading one of these instructions instead of the code it should be reading.

Try having your scope on the A0 output of the 6502 and observe what happens at switch-on or immediately following reset - does the A0 line go straight to the inactive state or is there a brief flurry of activity before the signal goes static? If so look for similar brief activity on A1, A2 out from the CPU.

If you do see a spurt of address line activity to begin with, that is probably the CPU operating normally until it hits one of these so called 'KIL' instructions.

[ajgriff]

Originally Posted by SiriusHardware

Try having your scope on the A0 output of the 6502 and observe what happens at switch-on or immediately following reset - does the A0 line go straight to the inactive state or is there a brief flurry of activity before the signal goes static? If so look for similar brief activity on A1, A2 out from the CPU.

Intriguingly it isn't consistent in its behaviour. Sometimes it behaves exactly in the manner you've described but on other occasions all the address lines show continued 'normal' activity rather than entering a static state. Still displays the random character screen though.

Alan

[SiriusHardware]

This may just indicate a degree of randomness in the 'wrong' data which is being read by the CPU. Only certain specific opcodes cause the 'lockup' effect, other random opcodes will appear to be legitimate ones so the CPU will continue to try to execute them even if the 'program' it is trying to work its way through makes no actual sense.

[Mark1960]

It would probably be worthwhile to verify the address and data buffers as described in this other recent thread.

https://www.vintage-radio.net/forum/...d.php?t=174829

[ajgriff]

Yes the buffers could be the next port of call if the emulator doesn't resolve the issue. Will be a day or two before it's likely to arrive.

Alan

[SiriusHardware]

I inserted a ULN2803A in between my test EPROM's data pins and the Pi to act as a 5V - > 3V level shifter and (eventually) had some success once I got all the flying jumper pin leads to connect all at the same time. If I was going to use this on a regular basis I'd have to build it properly because the pin jumper connections are just too unreliable, it was a world of pain to get it to work in lash-up form, due to numerous slack connections.

I did manage to get these comparison shots showing that it does work, first with a screenshot showing the end of a binary file loaded into a file viewer, the second shot is the same portion of the same file which I have programmed into a 2732 EPROM and then read out with a Raspberry Pi.

The apparent differences in the ASCII readout portions are just due to the different ASCII encoding systems used by the two display methods, I should have switched HxD (The file viewer) to render the ASCII in a more similar mode to that used by the Pi - the important thing is that the byte readouts match byte for byte, as confirmed by the identical checksums.

I don't want to hijack aj's thread so I will start another thread about this once I have it tidied up a bit, but suffice to say it can and does work.

[NivagSwerdna]

FYI Although the 6540s in a PET 2001-8 have lots of CS pins (and theoretically their polarity can be changed when the mask is made) the reality is much simpler...

In the sockets H1..H7...

pin 20 (nCS1) is always attached to the region select e.g. nSELC, ..., nSELF
pin 18 is always BA11

So only those 2 pins are required to decode.

I'm also unconvinced by the need for pin 16; although this is used for a 6540 to latch the address I don't think it is strictly speaking required for more modern devices.

Just my 2p worth.

Reading them is easy... just set the address, +ve edge on PHI2, read data -ve edge on PHI2 repeat.

[ajgriff]

Originally Posted by SiriusHardware

I don't want to hijack aj's thread so I will start another thread about this once I have it tidied up a bit, but suffice to say it can and does work.

Hijacking's not a concern for me but a separate thread would be a better reference point for those interested in this very useful Raspberry Pi ROM reading work in the future.

Alan

[ortek_service]

Originally Posted by SiriusHardware

I inserted a ULN2803A in between my test EPROM's data pins and the Pi to act as a 5V - > 3V level shifter and (eventually) had some success
>>
>>

Presumably you could just use resistor potential dividers, to drop down from 5V levels to 3.3V of RPi GPIO.
I presume for address inputs, you're just feeding 3.3V GPIO Outputs into these, which maybe OK if TTL compatible with 2.1V threshold, but a bit more marginal if requiring CMOS levels, so might want a 74HCTxx series etc. buffer to level-convert up to 5V supply levels.

[ortek_service]

Originally Posted by ajgriff

Intriguingly it isn't consistent in its behaviour. Sometimes it behaves exactly in the manner you've described but on other occasions all the address lines show continued 'normal' activity rather than entering a static state. Still displays the random character screen though.

Alan

It could be dataline(s) is 'floating' , due to a device not working, so you'll get different values each time. The random characters on the screen are what normally happens to start with, as RAM contents is random at power-up, until CPU+ROM(s) have run the start-up initialisation code to clear this.

[ajgriff]

Originally Posted by ortek_service

It could be a dataline(s) is 'floating' , due to a device not working, so you'll get different values each time.

I'm sure you're right. Hopefully I will eventually be able to figure out which device has failed.

Alan

[ajgriff]

Just to show that I've not been entirely idle, here are before and after images of the scars on the datasette.

Alan

[Slothie]

Originally Posted by ajgriff

Just to show that I've not been entirely idle, here are before and after images of the scars on the datasette.

Alan

Wow! How did you do that?