Mac Plus 820-0174-A: pulsating vertical-line pattern, no bong, good sync — TSM and LAG cleared via custom PAL exerciser. Where next?
Hi all — long post, but I think it's worth the detail since I haven't found anyone documenting quite this deep on this specific symptom. Looking for ideas on where to go next, and hoping the methodology here is useful to someone else down the line too.The board and the symptom
820-0174-A Mac Plus logic board. Connected to a known-good analog board. On power-up:- No startup bong
- Display shows a stable, structured, pulsating pattern of vertical lines — not random noise, not a checkerboard, no Sad Mac
- HSYNC and VSYNC both present and correct on the scope
- Symptom is completely unaffected by RAM configuration — tested 4×256K, 2×1MB, 4×1MB, and 2.5MB (1MB+256K) configurations. Zero change in the video pattern in any case, including with RAM fully removed.
ROM ruled out
Dumped ROM-HI and ROM-LO and diffed against known-good V2 ROM images — clean match, byte for byte. Not a ROM content issue.68000 pin measurements
DMM/frequency counter readings at the CPU:| Pin | Reading |
|---|---|
| CLK | 7.81 MHz (correct — matches C16M/2) |
| DTACK | 6.24V avg, 1.96 MHz |
| HALT | 4.72V (high — not held) |
| RESET | 4.72V (high — not held) |
| BERR | 5.00V (high — inactive) |
| IPL2 | 4.96V (high — no pending interrupt) |
CLK ÷ DTACK ≈ 4:1, which lines up suspiciously well with the theoretical minimum 4-clock 68000 bus cycle (no wait states) — but on a real Mac Plus, bus cycles should show variable timing due to CPU/video RAM interleaving, not a rigid, unbroken 4-clock cadence regardless of what's actually being addressed. That pattern — combined with the CPU clearly not being held in reset — pointed at a PAL free-running or blindly asserting DTACK rather than the CPU being dead.
PAL architecture (for anyone following along who hasn't gone down this hole yet)
Board has 7 custom PALs (VLSI-fabbed HAL parts, 342-05xx Apple part numbers): BMU1, LAG, TSM, TSG, ASG, BMU2, CAS. Pin-level reverse-engineered pinouts and equations for all seven are documented at retro.co.za's Mac PAL reverse-engineering page, and compiled .jed GAL replacement files are hosted on the PLD Archive wiki — credit to Porchy, Hkz, and Bolle for that reverse-engineering work.TSM (PAL16R4) directly generates /DTACK (pin 19) among other signals, which made it the clear top suspect given the CPU-side evidence above.
LAG (PAL16R8) generates /LDPS — the signal that loads the video shift register — and also became a suspect since it explains the "sync fine, content garbage" video symptom directly. LAG's TC input comes from TSM's TC output, so a bad TSM could plausibly cascade into LAG-looking symptoms too, which was part of the reasoning for testing both.
Testing methodology
Couldn't get a straight fuse-map read off the original chips — confirmed the T48/XGPro device list has zero entries for any bipolar PAL16xx-family part under any manufacturer, and even if it did, the originals are almost certainly security-locked production HAL parts (unlike the unlocked prototype dumps the PLD Archive .jed files were sourced from).So: built a functional exerciser instead of relying on a fuse dump.
Hardware: Arduino Mega 2560, two dedicated 20-pin/24-pin DIP ZIF-style sockets wired to fixed Mega pins (soft pin-role mapping per chip in software, physical harness never changes). GND/Vcc always land on the same physical socket positions across all 20-pin parts by DIP convention, which kept the harness simple.
Method:
- Pull the suspect chip off the board, socket it in the tester.
- Full exhaustive static sweep of every independent input combination (128 vectors for TSM's 7 independent inputs, 256 for LAG's 8), sampling outputs at both clock-HIGH and clock-LOW for each of 4 clock pulses per vector.
- Track per-pin toggle activity across the whole sweep.
- Separately: burn the trusted PLD Archive .jed for the same chip onto a blank GAL16V8, run the identical sweep on it, and compare toggle counts pin-for-pin against the harvested original.
Results
TSM: harvested chip vs. reference GAL (burned from PLD Archive .jed) — matched almost exactly, including several outputs that stayed completely flat across the entire 128-vector sweep (turned out this was expected/reference behavior too, confirmed by testing the reference chip standalone first — not a fault signature, just a property of the static-sweep methodology not walking the chip through a realistic bus-cycle sequence).LAG: same result. 256-vector sweep, harvested vs. reference — six of eight outputs matched to the exact toggle count, one off by a single count (likely a sampling-boundary artifact), the remaining two stuck at 0% on both chips consistent with the reference baseline.
Then, since both sockets were already installed on the board: swapped in both freshly-burned reference GALs (TSM and LAG simultaneously) directly on the troubled board and powered up under real 15.667MHz dynamic operation — not just the slow static sweep. Zero change in symptom. Confirms TSM and LAG both function correctly under real bus loading, not just in the static test rig.
Where that leaves things
TSM and LAG are cleared, twice over (static exerciser + live in-circuit swap). ROM is verified good. RAM/RAM-config is ruled out as a variable. Fault is somewhere in BMU1, BMU2, TSG, ASG, or CAS, or possibly outside the PAL cluster entirely (address decode elsewhere, a RAM address multiplexer, a trace/via issue, etc.) — though the RAM-independence data argues fairly strongly against a mux-level RAM addressing fault specifically.Given the CPU-never-executes-ROM-code framing, my current leaning is BMU1 next — it does the primary address decode for ROM/RAM/IWM/SCC chip selects, so a bad BMU1 could prevent successful ROM fetches independently of TSM/LAG being fine. But genuinely open to other reasoning here.
Questions for the group
- Has anyone seen this exact signature — sync good, structured-not-random video garbage, no bong, completely RAM-config-independent — trace back to something other than TSM/LAG/ROM? Curious whether BMU1 is actually the right next move or if I'm missing something more likely.
- Anyone dealt with a bad BMU2, TSG, ASG, or CAS specifically and know what symptom signature that produced? Trying to prioritize which to test next rather than working through all four blind.
Thanks for reading this far. Let me know if you have any thoughts to resolve this issue.
litriSE
