exxos blog - random goings on

[czietz]

8 = 1000 so that must be the address. it gets back 1010 = 10. Even so it doesn't make sense. As if A0 is shorted to GND, then "1000" is still A0=0.. So it shouldn't have mattered anyway at that point.

When I interpret your photos above correctly, the short was on A0 of the RAMs, right? That does of course not match A0 on the system address bus. (Incidentally, the system address bus only starts at A1.)

It depends on the machine, the type of MCU and its configuration, but in your case the MCU mapped the address bits of the system as follows:

CPU A1 -> RAM A0
CPU A2 -> RAM A1
CPU A3 -> RAM A2
CPU A4 -> RAM A3
CPU A5 -> RAM A4
CPU A6 -> RAM A5
CPU A7 -> RAM A6
CPU A8 -> RAM A7
CPU A9 -> RAM A8
CPU A10 -> RAM A0
CPU A11 -> RAM A1
CPU A12 -> RAM A2
CPU A13 -> RAM A3
CPU A14 -> RAM A4
CPU A15 -> RAM A5
CPU A16 -> RAM A6
CPU A17 -> RAM A7
CPU A18 -> RAM A8

The RAM test puts 16 bits of the address as data into RAM:
always 0 -> data bit 0
CPU A1 -> RAM A0 -> data bit 1
CPU A2 -> RAM A1 -> data bit 2
CPU A3 -> RAM A2 -> data bit 3
CPU A4 -> RAM A3 -> data bit 4
CPU A5 -> RAM A4 -> data bit 5
CPU A6 -> RAM A5 -> data bit 6
CPU A7 -> RAM A6 -> data bit 7
CPU A8 -> RAM A7 -> data bit 8
CPU A9 -> RAM A8 -> data bit 9
CPU A10 -> RAM A0 -> data bit 10
CPU A11 -> RAM A1 -> data bit 11
CPU A12 -> RAM A2 -> data bit 12
CPU A13 -> RAM A3 -> data bit 13
CPU A14 -> RAM A4 -> data bit 14
CPU A15 -> RAM A5 -> data bit 15

With that knowledge you can see that the mismatch between 0000010000001010 and 0000000000001000, i.e. in data bits 1 and 10, clearly indicates RAM A0.

[exxos]

A cart that will work and report back, even on a dead board would be a great tool to add to the collection.

Yeah that what I'm thinking, because the DRAM fails, as you know, troubleshooting a completely dead machine is nothing short of a nightmare.

After realising there can be other strange RAM faults now, it would make a CPU based board a little bit rubbish in some respects. It could not detect a address fault I think, but of course those pins can be scoped out anyway.

In terms of the H4, because we have the Falcon RAM header there, that could be used as a diagnostic port along with the CPU socket. Though really thinking about 20 steps ahead with all this. Because at some point I want to aim towards being able to sell complete H4 boards.. the problem is, diagnosing a dead board could take a considerable amount of time. So I need some low level tests to make sure there's nothing shorted on the CPU bus as starters.

For example, the very first test board idea I had was to buffer most of the CPU pins, so I could drive a LED on each 68K pin. There would also be put switches on every pin to allow it to be pulsed low. The idea being, the very first power up, if one of the data pins is not lighting a LED, then it is not pulled high, and you have just found the fault. The switches allowing each pin to be pulsed, would allow signal to be traced with a scope to the MMU/GLUE etc. so if you are sat there pressing a switch on a data pin and it is not pulsing The MMU end etc then you found the fault again..If there is a short on the bus, 2LED's would switch.. again you found the fault.

The tricky part comes in diagnosing actual RAM faults, which is where I was thinking of using a couple of PLD's to emulate read and write cycles to the RAM in "single step mode".. Then you would have a bank of LED's latching what is written to the bus, and a bank of LED showing what was read from the bus. Regardless of what address is used, it would quickly allow to diagnose data bits faults that least.. But the diagnostic cartridge would take over that job around that point anyway. But a PLD the drive the bus in any number of different ways for various tests... It could for example just simply pulse every pin on the CPU (In turn or in sequence all at once etc) which would then allow you to quickly scope around the board to make sure each signal is getting to where it is supposed to be. We can repeatedly pulse ROM address so see if ROM _CE is working etc.. the possibilities are somewhat endless.

These are all basic ideas of what can be done. Really it is just trying to speed up diagnosing boards which will not even start reading ROM or trying to boot up. Main problem is that with so many projects on the go all the time, it will probably be another year before I can even start to seriously design this board

[exxos]

When I interpret your photos above correctly, the short was on A0 of the RAMs, right? That does of course not match A0 on the system address bus. (Incidentally, the system address bus only starts at A1.)

Yes A0 was shorted to GND on the DRAM board.. Of course like you say this is not the CPU bus A0 (there isn't a A0).

It depends on the machine, the type of MMU and its configuration, but in your case the MMU mapped the address bits of the system as follows:

CPU A1 -> RAM A0
...
CPU A10 -> RAM A0
CPU A11 -> RAM A1

With that knowledge you can see that the mismatch between 0000010000001010 and 0000000000001000, i.e. in data bits 1 and 10, clearly indicates RAM A0.

Thanks for the clear explanation. See the problem was I was assuming these were data bits errors, not address bits... But also because A10 = RAM A0 which I never considered..

The diagnostic test would have been a lot easier to understand if it just simply listed the actual address as on the MUU & DRAM (MAD1-MAD9) , What it was sending what it was getting back, as without the explanation above, I think it catches a lot of people out assuming that because there is 16 bits, it is data bits, not address bits...

Maybe one of the bored people out there could start correlating information such as above into a new "how to interpret the diagnostic cartridge" thread...

[rubber_jonnie]

@czietz Thanks for that awesome explanation!!

@exxos If I have time, I may try to correlate, have to see how it goes as I'm still working despite the lockdown.

[exxos]

Back to the non-existent plot..

Now I can test DRAM quickly and easily and I have already found a faulty chip..

Interestingly when the white line show on the screen, this correlates to a bit, you just don't know which one, so I did a naughty thing and just move the lever on the ZIF sockets to "isolate" that chip, and I get various other lines on screen... When I got to chip BIT 10,
is changed, so that was clearly the faulty chip, I replaced it, and now all is well again!

As I have a new batch of diagnostic cartridge, I can test RAM and carts at the same time!

IMG_5072.JPG (125.87 KiB) Viewed 3651 times

IMG_5074.JPG (80.8 KiB) Viewed 3651 times

[exxos]

A slight oops somewhere along the line..

The bottom row of chisp should have been the 4bit chips, so only 4 chips needed for 512K instead of 16 chips... Though the chips I actually found were TC511001AP which are 1bit 1mb chips, so I cannot actually test these in my board I'm not even sure what machine actually uses these chips..

[PhilC]

@exxos those chips are used in some Mega ST2 and 4s.

[exxos]

@exxos those chips are used in some Mega ST2 and 4s.

ah I guess I should design a new test board to test these chips out with then

[PhilC]

How many you got?

[exxos]

How many you got?

lots