My summer project: A colour Stacy

[JezC]

@derkom I'm sure that I have seen a few comments on this forum about problems with the floppy drive with a TF536 fitted...as well as the ACSI port.

I'm struggling to find a link on my phone but if you don't find them before I get home I will try and post a link.

Pretty sure that several users have seen it, though some think that reading is ok...
:shrug:

[derkom]

@derkom I'm sure that I have seen a few comments on this forum about problems with the floppy drive with a TF536 fitted...as well as the ACSI port.

I was recalling having seem some issues mentioned in the TF536 on ST thread, specifically in maprom situations, but I hadn't gone back to check specifically. Figured I'd just report symptoms regardless. :)

GEMBench has now been running for about six hours in 68030 mode, no problems. I'll let it run overnight, then hopefully declare victory on the CPU switcher and perhaps move back to working on the video, which was the point of this whole project in the first place. :D

[derkom]

Today I soldered a PATA-SATA adapter board onto the underside of the Lightning ST.

IMG_20200917_151958.jpg

IMG_20200917_154509.jpg

It fits perfectly between the Lightning and the Stacy RAM board. This is not a coincidence. :geek: The eventual plan is to snake the SATA cable and SATA power into the battery compartment, giving me easily swappable mass storage.

But, I've run into a problem that I suspected might rear its head, and that's that the Lightning's IDE controller is working only in 68000 mode. I imagine that when booting in 68030 mode, the TF536's controller is taking over and preventing the Lightning IDE controller from being usable.

@terriblefire, what's required to get the TF536 to disable the onboard IDE? Is it something I can tweak myself in the JED (or even in the hardware), or am I going to have to beg for a custom build? :?

[exxos]

And today's stacking award goes to...

Edit.. I guess a custom build would be the way to go.. I guess remove the ide file and recompile..

[derkom]

Ran into a pretty strange problem today. I'd noticed yesterday that I wasn't getting a reliable boot, but the system did boot when I moved the floppy drive out of the way, so I figured one of the feet on the drive cage must have been misaligned and was shorting something to ground. Cue my disappointment this morning when I discovered that it still wasn't booting reliably, and I had no good explanation.

I pulled all my switcher hardware out and stuck a 68000 directly in the socket, to no avail. I swapped all the socketed chips for known good ones. Nope. I noticed that a couple of my video connection wires to the ubeswitch had broken off during all the handling over the past month and a half, so I removed that whole connection. Still not booting reliably, but oddly it seemed like moving around the ubeswitch's reset wire (still connected to the motherboard) was affecting stability. I removed that wire as well. Still not booting.

I inspected the motherboard closely, and found nothing amiss. Just the same, I took it out and blew it all off with compressed air and put it back in. And it booted. Nay, success does not come so easily, for when I started running GEMBench, the really weird stuff started to happen. Every now and then, GEMBench would just freeze in its tracks, sit there for a while, and then suddenly unfreeze and continue as if nothing had gone wrong. A serious "wtf?" moment. Eventually it just crashed.

After a few tries, I convinced it to boot the diag software, and noticed the same freezing behaviour, as well as occasional errors, most often "Bad instruction fetch". Thinking that maybe I've cracked the motherboard in all the ins and outs on the CPU socket, I set the diag software off running the timing test repeatedly, because it gives frequent screen updates, and started poking around with my finger.

I did not find that poking things could cause the system to crash. On the contrary, I found that poking things could cause the system to uncrash, as in the diag software would freeze, and then unfreeze when I was poking at the CPU with my finger. I figured out that I didn't have to apply any pressure at all to unfreeze the system. Merely touching the right part of the CPU would unfreeze the system. Aha, this is electrical, not physical!

Holding one end of a wire and touching the other end to the pins on the 68000, I eventually isolated the magic unfreeze pin. It was pin 12, BGACK, which is one of the pins I've been switching on my switcher board. Surely my board hasn't done something to damage another component in the BGACK circuit?

At this point I pulled the 68000 back out for some very basic diagnostics. First thing I checked was the pullup resistance on BGACK. 350 kΩ. That's not right at all. That should be 2.2 kΩ. Pulled the board back out and checked the resistor. It's fine, of course. But the connection between BGACK and the resistor was gone. Seems all the pushing and pulling on the CPU socket over these months broke my solder connection on that pullup.

A quick reflow restored the connection, and to avoid the same problem in the future, I taped a scrap of 3D printer flotsam to the underside of the board, directly under the CPU, so it won't flex anymore. The Stacy now behaves normally once again.

Not quite how I expected to spend most of Saturday, but it was an interesting journey. :D

[Atarian Computing]

That read like a thriller novel :D Well done in finding out the prob.

[derkom]

That read like a thriller novel :D

It was supposed to. :lol:

[derkom]

Since this design works well at this point, and may be of some use for someone else, here's the KiCad files for the switcher board. The PCB layout itself is very specific to my build, but the electrical layout for the muxes should transition fine to any similar switching setup.

A couple of things to note:

- Muxes are TI CD74HC157s in 16-pin SOIC package

- Note that the muxes are switching signals to the right hand socket (this is for the TF536), but not to the left hand socket. The switched signals for the left hand CPU are provided via through hole connectors to which I've connected wires soldered directly to the CPU (see earlier photos in this thread). The reason for this is so that the left hand socket can house other expansions that may require these signals in both 68000 mode and 68030 mode. They only need to be switched for the 68000 itself, which sits on top of the stack. I realised quite late in the game that the Lightning, Cloudy, and Storm don't seem to be using the switched signals anyway, so I probably could have switched them at the socket, but by the time this occurred to me, I already had the boards, so this is what I'm using. :)

- I am switching all four of BG, BGACK, BR, and E for both CPUs, but in my testing it appeared that the 68000 did not require BGACK switched (but the TF did). I went ahead and switched all four to both CPUs anyway because I was running that signal through the mux anyway, and just in case I wasn't right about it not being needed, I figured what's wrong with one more flying wire?

Maybe this is of some use. Maybe it is not. Here it is regardless. :D

[PhilC]

@derkom thanks you very much

[derkom]

How have two months gone by since I last did any real work on this? :lol:

Here's what I put together today...

IMG_20201127_213556.jpg

Screen removed from OSSC and installed onto a little custom PCB that will be mounted inside the TOS door on the bottom of the Stacy. This way, if the OSD is ever turned off on the OSSC, or for any other reason I need to be able to see its screen, it'll be there.

The little PCB the screen is on will plug into the empty TOS sockets for mounting, and it even pulls a ground from there. :D

Edit: Another picture showing the back of both components.

IMG_20201127_214804.jpg