• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

Sad Mac SE: Glitchy Video

Snial

68000
Hi folks,

The flyback is fixed [https://68kmla.org/bb/index.php?threads/spot-the-bust-flyback-competition.47610/post-559192], but startup fails!

1744271686403.png
According to this TinkerDifferent page: https://tinkerdifferent.com/resources/sad-mac-error-codes.82/

The closest error appears to be:

$000E The Data Bus test failed. The Z field indicated the bad bit(s) as a 32-bit mask for bits 0-31, either a bad SIMM or a data bus failure.

To me it looks like the bottom row of digits are saying 0x9090B8D0 or something and it looks like the top nybble appears to have failed on every word. But also it looks like enough of at least some of the RAM is working so that the stack is set up and it can call some functions, because I guess drawing the sad Mac icon and the digits involves some subroutines? From my recollection of the Plus boot process it first sets the SP fairly low in memory and only after it's checked RAM it moves it to the top.

There are 4x 1MB SIMMs in that SE (let's call them A (Hi1), B (Lo1), C (Hi2), D (Lo2)). In theory, if there were at least 2 SIMMs that worked well enough. I might need to go through 6 combinations: AB, AC, AD, BC, BD, CD.

I'm a bit reluctant to open the SE and try them, because I understand the plastic clips on the sockets are pretty fragile. But given that one of the SIMMs has a lower byte that's good (B or D) I can cut the combinations:

AB, AD (if both of these are bad, then 'A' must be faulty) => CB (if still bad => DB is the only remaining one).

Still, 4 combinations is fairly involved. Maybe I can cut it down further, either A or C is certainly bad, but most likely 'C' (and D or B might be bad), so trying to

DB in slot Hi:Lo 1 (most likely to work: failing image will tell me if B or D has failed, so we'll call that x) => Ax/xA and if that fails, Cx/xC is the only remaining option. This involves removing 2 SIMMs; inserting 1 to 3 maximum. That could be tolerable.

However, I'm also puzzled by the vertical patterns. They repeat on each word fetch, but word fetches on an SE aren't independent; instead the hardware fetches a 2 word FPM burst once every 4 cycles. The second word burst is just another column fetch. But could a RAM failure be identical for a new column (same page)?

Actually, I think it points to a DRAM failure. Nybble errors appear in bursts, but they're not always there. If it was in the Logic board, I guess it'd be more consistently there. Bits 15 and 12 fail more commonly and together, Bits 14 and 13 fail together less commonly. Maybe that doesn't imply a RAM issue, but a dot-clock shift register issue. But I don't think that makes sense either, because if there's a shift register issue, it would tend to cause all the bits to fail from a given position, e.g. if bit 1 always shifts a 0 into bit 2, then the bottom 2 bits would always be white (or more likely to be white). Also, if it was a shift register issue, it wouldn't cause a Sad Mac (because a memory test wouldn't find it).

Does anyone have insights here?
 
Move the SIMMs around and see if the vertical corruption on the screen moves?
So, SIMM#1 is

1744278937978.png

So, SIMM#2:SIMM#1 is Hi(1):Lo(1) and SIMM#4:SIMM#3 is Hi(2):Lo(2). Video memory when you have 4MB is most likely at Hi(2):Lo(2), so Hi(2) (C) is the one that's most likely failed. I'll start by removing SIMM#2.. SIMM#4 and putting SIMM#3 in place of SIMM#1. This would give me a 2MB system if it works. Oh, actually, I can try just removing SIMM#3..SIMM#4 first, since I don't need to put SIMM#3 in SIMM#1 if that config works.
 
Clean the simm contacts with isopropyl. I was just having issues with my se and reseated memory and rom simms to fix my video issues
 
You are thinking about this too much. Just shuffle the buggers and see if anything changes :)
Clean the simm contacts with isopropyl. I was just having issues with my se and reseated memory and rom simms to fix my video issues
@cheesestraws , sorry I removed SIMMS 3 and 4 before seeing your message. @imactheknife , I did attempt to clean the contacts for the SIMMS I removed using surgical spirit and a cotton bud. I found that the Mac SE made just a click when I subsequently powered it on, without any display. I think this could be related to the fact that the resistors are set up to expect 4MB, but instead it's only got 2MB installed now. I suppose the next most complex thing to do is re-insert the SIMMs (but swap them first ... actually I didn't check which was which). But it might be a good idea to create a stripboard mod so that both memory size resistors can be jumpered in or out as needed (2 resistors of the right size+2 jumpers).
 
@cheesestraws , sorry I removed SIMMS 3 and 4 before seeing your message. @imactheknife , I did attempt to clean the contacts for the SIMMS I removed using surgical spirit and a cotton bud. I found that the Mac SE made just a click when I subsequently powered it on, without any display. I think this could be related to the fact that the resistors are set up to expect 4MB, but instead it's only got 2MB installed now. I suppose the next most complex thing to do is re-insert the SIMMs (but swap them first ... actually I didn't check which was which). But it might be a good idea to create a stripboard mod so that both memory size resistors can be jumpered in or out as needed (2 resistors of the right size+2 jumpers).
I've now tried SIMMs #3 and #4 both ways round and it's still generating similar video artefacts (and the Sad Mac). But they're not the same and I'm still almost certainly over-thinking it!

1744465357522.png
Sad Mac is still there with the same, or similar code. Actually, though it might not be a 90909890 code on the bottom, because the 9's could be 0s. You can see in this shot the stripes are more regular. Also, it's possible to see that the stripy pattern descends two pixels very 32 pixels (i.e. every video fetch cycle) read in the central part of the image. That section switches from mostly white with black dots in the centre to black with white dots in the centre. The height of each one repeats 4x where each repeat is, oddly, 11 pixels high. I haven't checked if the chips are nybble-wide, but I figure they can't be, because there's 8 of them per SIMM.

The next step I think (possibly tomorrow) is to add my veroboard and try 2MB of RAM instead. I need a 1x150R resistor for R36(?) which I can switch with a 3 position jumper for any possible configuration (much like the later logic boards).
 
For my next attempt, I wanted to be able to modify the memory configuration at will. Later Mac SEs had a jumper switch, so I decided to implement my own version on Veroboard™.

1744743629576.png
I used my Stripes.jar strip board Java app to design it, because I usually make a horrendous bunch of mistakes even on the simplest strip board projects. Even this one took a fair bit of iteration, but the genius bit was that I could feed the 150R resistor straight through the middle of the 3-pin header so it could select the top (1MB) or bottom (2MB/2.5MB) options. I have a whole load of basic series resistors I bought from Maplin about .. goodness.. 12 or more years ago now. I found 220R || 470R was the closest to 150R.

Apple's jumper-selectable Mac SE puzzles me, because they used two x 150R resistors when I only think they needed one as per my design.

1744744389508.png

+--[10K]---5V
ASIC.17 -+--/ --+
+-[150R]---GND
ASIC.19 -+--\ --+
+--[10K]---5V


Anyway, I managed to solder it up and test the SE, but it still shows the same error message. At least I didn't damage it further! Maybe the faulty SIMMs were in the first two? Next test will be to replace SIMM#2 with one of the SIMM#4:SIMM#3 Simms.
 
OK I've tried out the other SIMMs, and exactly the same problem remains with the highest nybble in each word corrupted. I had to swap both, because two of the SIMMs are Mitsubishi 100ns x 1MB each and the other two are Siemens 70ns x 1MB.

I think this implies, to my naïve thinking, that problem could well be in the ASIC rather than the RAM; though I don't know how an ASIC fault would cause a bus error while the system is working well enough to display the Sad Mac and Hex code, unless everything including return addresses is just stored in registers (apart from the Sad Mac Icon and digit bits, which would be in ROM).

Meanwhile @cheesestraws , a few posts ago you asked about why I thought the flyback had blown. It's because it has that massive gouge going along it (which I don't remember prior to the incident even though I'd opened it up before and I think I remember smoke coming out of that side of the Mac).

1744791849772.png

On the positive side, I should be able to try the 70ns RAM in my degrading LC II to check if it's my other RAM that was faulty or something else on the board!

-cheers from Julz
 
Meanwhile @cheesestraws , a few posts ago you asked about why I thought the flyback had blown. It's because it has that massive gouge going along it (which I don't remember prior to the incident even though I'd opened it up before and I think I remember smoke coming out of that side of the Mac).

@croissantking asked that, not me! But I'd tend to agree that 'having a large hole in it' is probably a good indication that perhaps it is not perfectly functional
 
OK I've tried out the other SIMMs, and exactly the same problem remains with the highest nybble in each word corrupted.
I know I've seen this issue before, but it's been 20+ years. I'll keep it floating around in my head and let you know if I recall what caused it (I'm pretty sure it wasn't the ASIC or the SIMMs but something that made perfect sense once it was explained to you - bad connection on one of the pads maybe?).
 
I know I've seen this issue before, but it's been 20+ years. I'll keep it floating around in my head and let you know if I recall what caused it (I'm pretty sure it wasn't the ASIC or the SIMMs but something that made perfect sense once it was explained to you - bad connection on one of the pads maybe?).
Hi @adespoton , thanks for that! If someone can figure it out and it turns out not to be the ASIC, nor DRAM, that's best IMHO. It's a bit of a puzzle to me how it seems to affect the high nybble (though mostly D<15> and D<12>) and yet it's stable, not predictable; yet different on subsequent reboots. If it was a marginal pull-down or pull-up, or a capacitor I'd expect it to have a random pattern or be in a continual state. It's clearly not the data lines themselves being pulled, because the ROM reads correctly (it wouldn't be able to run at all if D<15:12> exhibited that pattern there). All the ROMs and latches I can see attached to D<15:8> appear to be byte-wide.

In some ways it looks a little bit like address signals appearing on data lines. The major transitions between mostly white and mostly black happen every 3 or so x 11 pixels per sub-pattern = 33 pixels. That's 2112 bytes. So if it was 2048 bytes that could be whenever A11 flips, but really because RAM is 2x byte wide, and A0 isn't used; it's actually A10 on a SIMM.

Interestingly CAS is A1..A9 and AAS is A10..
 
Back
Top