My summer project: A colour Stacy

[derkom]

When I plugged in my first build of a relocator board the other day, it worked, but only for a while. GEMBench eventually crashed, and although I didn't catch the crash happening, I suspect/hope that it was a bus error caused by excessive bus loading, so now that the ubeswitch is installed and functional, my next step is to replace the bus pullup resistors with 2.2ks.

The Stacy schematics show (on page 20/21) that the CPU has 4.7k pullups on the address lines and miscellaneous, and 10k pullups on the data lines. This is different from the 1040ST, which has 4.7k on miscellaneous and 10k on both address and data lines.

Should I be swapping all of these out for 2.2ks? I searched around the other night, and found a few posts about replacing bus pullups with 2.2ks, but didn't find anything saying if that means all of them, or only address/data. I suspect the answer is "yes, all of them", but would like some confirmation on that.

[exxos]

Yes all the address and data bus

[derkom]

Yes all the address and data bus

Well that doesn't entirely answer my question. I am guessing that when you say "all", you also mean I should swap the pullups on AS, DTACK, etc? That was I was referring to as "miscellaneous". I think the answer here is yes, just want to be sure before I put the work in.

[exxos]

I can't remember offhand, but arnt they already 2.2k ? You would have to look at the schematics.

[derkom]

I can't remember offhand, but arnt they already 2.2k ? You would have to look at the schematics.

According to the schematics, those are all 4.7k. I haven't actually verified this on the board. It's a little tough to follow, split between pages 20 and 21 of the schematics. I'll verify on the actual board when I have it back on the desk, and if it's 4.7k, I'll replace it with a 2.2k.

[derkom]

I have replaced all the pullups with 2.2ks today, and at least it boots.

I'm going to let it run through GEMBench for a while with the CPU directly in the socket before I stick the relocator back in.

Didn't have quite enough 9-pin 2.2k SILs....

IMG_20200726_150953.jpg (67.98 KiB) Viewed 903 times

I've got more on the way, but not enough patience for that. (Yes, I have cleaned up that flux.)

[derkom]

Getting some quite strange behaviour now. The first thing I noticed when powering up is that it came up in colour mode, despite the fact that the ubeswitch is configured to default to mono. I ignored that and ran GEMBench in medium resolution. GEMBench ran fine for about 30 minutes and then crashed, but it crashed to this desktop:

IMG_20200726_192541.jpg (102.87 KiB) Viewed 892 times

And I'm finding that any time I use the button on the ubeswitch to swtich to mono, that's what I'm getting. TOS thinks its in mono, but the video output has colour timings. I plugged in a SM124 and get nothing on the screen, so it would seem nothing is coming out the mono line. It's basically behaving like part of the system thinks its in colour mode and part thinks it's in mono.

I don't particularly relish the idea of disconnecting the ubeswitch once again, but it may be a good idea, to get back to the basics.

[exxos]

Maybe clean up and resolder the MMU & GLUE chips ?

[derkom]

Maybe clean up and resolder the MMU & GLUE chips ?

Can always do that of course, but it's very strange that such a problem would suddenly pop up when I replace all the bus pullups. I keep staring at the schematic to see if there's anything that could make those things related, but nothing is popping out at me.

When I'm running in "mono" mode, there's about 45 Ω between mono detect on the ubeswitch and ground, which I would imagine is expected behaviour, and should make the MFP interpret that as a mono monitor.

I'll do as you suggest, although I might as well test those chips in another computer before I put much time into something like reflowing.

[derkom]

One thing that I'll point out as odd and probably relevant behaviour here is that when GEMBench is crashing in medium res, I'm ending up with the "confused high res" desktop, without the window open to the GB executable, which tells me the system is rebooting. I haven't caught it in the act yet, but it's done this twice (FWIW, once with a HC CPU and once with a "normal"). If something is causing mono detect to ground out, the reboot at least would be anticipated behaviour.