derkom's doings

[PhilC]

Or at least don't turn them on until its the right way round

[derkom]

Another side project... I am working on diagnosing a dead Stacy board (nope, not my project board, worry not!). I've got it booting DiagROM and I'm a little confused by the output I'm seeing...

Screenshot 2020-10-31 at 15.22.50.png (723.55 KiB) Viewed 3949 times

At first glance, I thought "oh, some of the data lines are stuck low", but then I noticed when converting those hex strings to binary, it stops making sense...

Code: Select all

AAAAAAAA > 00A000A0
10101010101010101010101010101010
00000000101000000000000010100000

55555555 > 00500050
01010101010101010101010101010101
00000000010100000000000001010000

F0F0F0F0 > 00000000
11110000111100001111000011110000
00000000000000000000000000000000

0F0F0F0F > 00F000F0
00001111000011110000111100001111
00000000111100000000000011110000

It's not a simple case of some of the data lines being stuck low after all. Anyone have any thoughts on what could cause this behaviour? The CPU, MMU, GLUE, and RAM are all known good.

I had been considering hooking up the logic analyser to follow the individual bits through the LS244s and LS373s, to see if any of those are misbehaving, but now that I see this doesn't look like a case of individual bits not working, I'm wondering if there's some other diagnostic path I should be following.

[stephen_usher]

It's almost as if one nibble is being swapped and the other goes nowhere.

Something to do with /UDS and /LDS during writes? After all the ROM is working, which means that the data lines must be OK, at least to the ROM. /UDS and /LDS aren't used for reading, which again means that if they're bad then it doesn't affect the ROM.

[derkom]

It's almost as if one nibble is being swapped and the other goes nowhere.

Something to do with /UDS and /LDS during writes?

That's a good thought. I couldn't come up with any explanation for that bit-shifting/vanishing, but you may be onto something there. Gives me something to look into at least.

Edit: Can't really imagine anything is up with LDS/UDS. Those lines are present only on CPU, MMU, GLUE, cartridge port, and expansion connector, and everything seems fine. Both pulled up 2.2K (2.2K pullups on this board), 4.4K between them, and continuity on all the right pins of the three involved ICs.

[stephen_usher]

Actually, check the address lines going to memory, maybe the multiplexer. A4 going to memory being stuck may cause something like this thinking about it.

It's got to be beyond the ROMs otherwise the DiagROM couldn't boot. I'm trying to make sense of the schematics for the Stacy... Is the memory on a daughter board as it seems to be in the docs, with a header onto the RAM board. Bad connection on A4 or A5?

[derkom]

Actually, check the address lines going to memory, maybe the multiplexer. A4 going to memory being stuck may cause something like this thinking about it.

It's got to be beyond the ROMs otherwise the DiagROM couldn't boot. I'm trying to make sense of the schematics for the Stacy... Is the memory on a daughter board as it seems to be in the docs, with a header onto the RAM board. Bad connection on A4 or A5?

Yeah, the RAM, TOS, and keyboard controller are all on a daughterboard, which is known good, because it's my own and works fine in my Stacy.

This evening I pulled a bunch of logic data off each D line, plus /RDAT, /WDAT, and LATCH both on the bus side of the buffers and on the RAM side, and while I haven't dug terribly deep into the output, it all looks like it's behaving correctly at first glance.

I also pulled almost the entire data bus, D0-D14 (needed the remaining channel on my logic analyser to pull /WDAT for a trigger), and it looks like the system isn't even putting the right data on the bus to begin with. I can see it set up the whole bus with one of the wrong results and then assert /WDAT, presumably storing the wrong data for later retrieval.

When looking at the schematics again tonight, I realised that the MFP is also connected to /LDS, so I socketed it and stuck in a known good one, no change.

It actually did occur to me in the shower today that something amiss on the address bus could be responsible for some bit shifting, so I added that to my list of things to look at. Quite a while ago I checked continuity on the whole bus, including the address bus, but I have not yet connected the logic probe to see what's going on there. Figured I would get to that after I finished pulling data off the data bus, so perhaps tomorrow.

[derkom]

Problem solved! I decided to start rechecking continuity (most interested in address bus, but looking at everything really), and everything between the CPU and MMU was good, so I went ahead and started checking the rest of the MMU connections, and discovered that there was no continuity between the 744 buffer output for CAS2H and the RAM. It was a shoddy factory solder job that eventually just broke. A reflow on that buffer chip (which oddly isn't on the schematics) has the board up and running.

[stephen_usher]

Yay!

[derkom]

A slightly different kind of retro has fallen into my lap. A friend of mine found this in the attic of an old commercial building he bought...

srii-001.jpeg (92.96 KiB) Viewed 1715 times

It's an old 1970s vintage Bell & Howell SR-II microfiche reader. It looks like it's probably mostly just dirty and in need of a new lightbulb, but we shall see!

[rubber_jonnie]

A slightly different kind of retro has fallen into my lap. A friend of mine found this in the attic of an old commercial building he bought...


srii-001.jpeg


It's an old 1970s vintage Bell & Howell SR-II microfiche reader. It looks like it's probably mostly just dirty and in need of a new lightbulb, but we shall see!

Crikey, I remember using these things somewhere. Where though, is another matter!!