17th Feb 2021, 12:05 am | #141 |
Nonode
Join Date: May 2004
Location: Halifax, West Yorkshire, UK.
Posts: 2,587
|
Re: Commodore PET 2001
Agreed and I'll knock the dust off the Raspberry Pi.
Alan |
17th Feb 2021, 12:29 am | #142 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,556
|
Re: Commodore PET 2001
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. |
17th Feb 2021, 3:45 am | #143 | |
Octode
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,440
|
Re: Commodore PET 2001
Quote:
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. |
|
17th Feb 2021, 10:08 am | #144 |
Nonode
Join Date: May 2004
Location: Halifax, West Yorkshire, UK.
Posts: 2,587
|
Re: Commodore PET 2001
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 |
17th Feb 2021, 10:18 am | #145 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,556
|
Re: Commodore PET 2001
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.
|
17th Feb 2021, 10:22 am | #146 | |
Nonode
Join Date: May 2004
Location: Halifax, West Yorkshire, UK.
Posts: 2,587
|
Re: Commodore PET 2001
Quote:
Alan |
|
17th Feb 2021, 11:11 am | #147 |
Nonode
Join Date: May 2004
Location: Halifax, West Yorkshire, UK.
Posts: 2,587
|
Re: Commodore PET 2001
Does anyone think that there is some significance in the fact that the CPU's address lines are being held high?
Alan |
17th Feb 2021, 3:29 pm | #148 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,556
|
Re: Commodore PET 2001
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. |
17th Feb 2021, 5:26 pm | #149 | |
Nonode
Join Date: May 2004
Location: Halifax, West Yorkshire, UK.
Posts: 2,587
|
Re: Commodore PET 2001
Quote:
Alan |
|
17th Feb 2021, 6:00 pm | #150 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,556
|
Re: Commodore PET 2001
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.
|
17th Feb 2021, 7:49 pm | #151 |
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,294
|
Re: Commodore PET 2001
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 |
17th Feb 2021, 8:17 pm | #152 |
Nonode
Join Date: May 2004
Location: Halifax, West Yorkshire, UK.
Posts: 2,587
|
Re: Commodore PET 2001
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 |
17th Feb 2021, 10:32 pm | #153 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,556
|
Re: Commodore PET 2001
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. Last edited by SiriusHardware; 17th Feb 2021 at 10:37 pm. |
18th Feb 2021, 1:29 am | #154 |
Triode
Join Date: Feb 2021
Location: Kingston upon Thames, Greater London, UK.
Posts: 11
|
Re: Commodore PET 2001
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. |
18th Feb 2021, 12:43 pm | #155 | |
Nonode
Join Date: May 2004
Location: Halifax, West Yorkshire, UK.
Posts: 2,587
|
Re: Commodore PET 2001
Quote:
Alan |
|
18th Feb 2021, 12:47 pm | #156 | |
Octode
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,440
|
Re: Commodore PET 2001
Quote:
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. |
|
18th Feb 2021, 12:51 pm | #157 | ||
Octode
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,440
|
Re: Commodore PET 2001
Quote:
|
||
18th Feb 2021, 11:24 pm | #158 |
Nonode
Join Date: May 2004
Location: Halifax, West Yorkshire, UK.
Posts: 2,587
|
Re: Commodore PET 2001
|
19th Feb 2021, 1:57 pm | #159 |
Nonode
Join Date: May 2004
Location: Halifax, West Yorkshire, UK.
Posts: 2,587
|
Re: Commodore PET 2001
Just to show that I've not been entirely idle, here are before and after images of the scars on the datasette.
Alan |
19th Feb 2021, 3:14 pm | #160 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Commodore PET 2001
|