Electronics > Projects, Designs, and Technical Stuff
Science of Cambridge (Sinclair) MK14 restoration
<< < (4/5) > >>
glarsson:
Ok.
MK14:

--- Quote from: glarsson on October 25, 2018, 12:21:51 pm ---If the trace was without PROM installed then the Z80 is reading the opcode FF, rst 38h, over and over again.

--- End quote ---

The MK14, uses a National Semiconductors, SC/MP cpu (SCAMP), there is no Z80, here.

https://en.wikipedia.org/wiki/National_Semiconductor_SC/MP
MK14:

--- Quote from: mpk on October 25, 2018, 03:45:21 pm ---(by the way - one interesting point is that I have no idea whatsoever if the PROM chips are the right way round as they were completely unmarked. I can easily work around that by swapping them over to check both combinations when debugging..)

--- End quote ---

I was going to suggest labeling them (PROMs) to you. But then thought I was being silly, and would just keep quiet, as you would realize and/or they were already marked differently (I hoped).

If you have got the hex dumps from the chips (via your Arduino project), you should be able to recognize valid instructions, values (stored numbers, e.g. via immediate instructions) and start addresses, contained in the dumps.
Hence be able to work out, which has the high nibble and which has the low nibble.

Or feel free to post the hex dumps here, and I/we can take a look.
MK14:

--- Quote from: mpk on October 25, 2018, 03:33:28 pm ---Here are some more traces. The first two are CS on PROM (yellow) vs D0 (purple) and the same for a RAM chip. The third (just a bit of fun, don't cha know) is chip select on PROM (purple) vs RAM (yellow).

--- End quote ---

Thanks!
Those traces look good. I can't immediately see major faults.

Can I suggest a, hopefully fairly quick experiment.
Take traces, just like you just did, with the same pins, setting etc.

Except, remember the first set of oscilloscope traces you posted, in this thread. Where the data line, seemed to have a bunch of data, then a long gap, then the same pattern was repeating, around three times, altogether.

It would be very interesting, to try and get, exactly (similar would be fine as well), the same trace (it may need repeated triggering, and/or messing with the triggering and/or changing the timebase etc), but have the extra chip select information on it as well. Maybe check out other signals, if you like to play around.
E.g. Check the reset pin, as well. Has it settled down, or is it changing, in alignment with the data pin ?

i.e. Like the first trace, in this post https://www.eevblog.com/forum/projects/science-of-cambridge-(sinclair)-mk14-restoration/msg1916483/#msg1916483 , but with the other channel, attempting to show more information about the possible fault. E.g. Chip select, Reset pins etc.

Please DON'T take what I just said as a rigid, firm set of test(s). Rather, feel free to play around and look at signals, and if you see any which look funny/suspicious/odd etc, feel free to post them.

tl;dr
Where you have bursts of databus activity, then apparently too long gaps, is very interesting, because it is likely to show faulty activity. Seeing other pins, can then help to pinpoint why, it is doing it.

Also, trying faster and slower timebase settings can help, because it can spot possibly faulty patterns in the signals.
MK14:
If I can make a suggestion. It is, that getting the PROMS, high and low nibbles, the right way round is the first priority (BEFORE taking further traces).
Because, otherwise, that alone could be why the earlier datatraces, looked suspicious/faulty.

I.e. As I think you know anyway, if they are the wrong way round. It will just crash all the time, and produce relatively nonsense traces. The traces would be understandable, but they would just show it haphazardly doing crazy things (i.e. crashing).
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod