daver2
10k Member
Well,
I think I am calling this repair I am afraid...
We seemed to be getting inconsistent results previously (with different data on the data bus of the EPROM and it differing on the data pins of the CPU socket) - and this didn't seem to be helped by an EPROM not returning the correct data for some reason either when it should have been.
I still suspect something is causing the selected data requested by the CPU not to be read correctly by the CPU - causing the unpredictable results. Sometimes, this can 'work' statically (i.e. by doing what we have done and replaced the CPU by wire links on the address bus) but they can also fail in a 'dynamic' mode (and this was what we were trying to check with the oscilloscope).
Unfortunately, I don't think your oscilloscope skills are that advanced yet.
I think this is a relatively simple problem - it is just there are still too many variables.
The one that most concerns me is that the test firmware that you have should be considered a 'tool' and they shouldn't be just programmed on the fly. You should only be using tools that are known to work correctly. If you need to program a new tool - you should (ideally) ensure that it works on a known good PET before using it on an unknown machine. This (of course) is the 'ideal' solution.
Hopefully, your friend will be able to provide some useful input to this fault. Let us know if you get it repaired and what was wrong.
Dave
I think I am calling this repair I am afraid...
We seemed to be getting inconsistent results previously (with different data on the data bus of the EPROM and it differing on the data pins of the CPU socket) - and this didn't seem to be helped by an EPROM not returning the correct data for some reason either when it should have been.
I still suspect something is causing the selected data requested by the CPU not to be read correctly by the CPU - causing the unpredictable results. Sometimes, this can 'work' statically (i.e. by doing what we have done and replaced the CPU by wire links on the address bus) but they can also fail in a 'dynamic' mode (and this was what we were trying to check with the oscilloscope).
Unfortunately, I don't think your oscilloscope skills are that advanced yet.
I think this is a relatively simple problem - it is just there are still too many variables.
The one that most concerns me is that the test firmware that you have should be considered a 'tool' and they shouldn't be just programmed on the fly. You should only be using tools that are known to work correctly. If you need to program a new tool - you should (ideally) ensure that it works on a known good PET before using it on an unknown machine. This (of course) is the 'ideal' solution.
Hopefully, your friend will be able to provide some useful input to this fault. Let us know if you get it repaired and what was wrong.
Dave