continue the PCB reverse engineering project
Buzzed most of U22, the VIAs within its footprint and some long runs toward the top I wanted to get in the works. Interesting mess. Does anything come together at this very early point?
A few real threads are already visible, even this early — nothing like a system yet, but three things worth flagging (I read these off the actual embedded text, not the mirrored pixels, so pin numbers below are solid):
U22's low inputs tie into the resistor pack, and two of those lines also land on the VRAM. The 4-resistor pack up top feeds down into U22 pins 1–4 (I0/CLK, I1, I2, I3), and along the way, two of those runs are firm-connected at U15's pins 5 and 6 — I/O1 and I/O2, on the VRAM's random-access (parallel) port. That's worth keeping an eye on: if it holds up as more of U22 and the VRAMs get buzzed, it'd mean U22 is reading or gating part of the VRAM's data path rather than just routing past it physically. Could also turn out to be incidental crossing rather than a real shared node — too early to tell which, but it's exactly the kind of junction worth tracking now before more traces pile on top of it.
U9 feeds U10's clock. A clean, independent firm connection: U9 pin 9 (I8) runs straight to U10 pin 1 (I0/CLK). One GAL apparently driving another GAL's synchronous clock input — plausible if U9 is generating some derived strobe or gated clock that U10's logic runs on. Small, but a real GAL-to-GAL link, which is the kind of thing that starts making the "topology" argument from a couple sessions ago concrete.
The WTF one is probably a red herring, in a specific way. On U5 (SN74F161N), the four parallel-load data inputs plus ENP — pins 3 through 7 (A, B, C, D, ENP) — all show continuity down to pin 9 (LOAD‑bar). Tying data inputs directly to the load-control pin isn't a sensible logic net, so before chasing it as a real signal, I'd check whether there's a resistor pack sitting electrically between those pins and a bias rail (VCC or GND) — this board already has at least two other resistor packs doing exactly that kind of multi-pin pull elsewhere (the one feeding U22 above is one). If those five pins are all just riding the same pull-up/pull-down pack rather than talking to each other, that'd explain the continuity without it meaning anything about U5's actual function. Worth a quick continuity check against a known VCC or GND pin to settle it either way.
Nothing here contradicts any of the pinout data already verified, and that's really the right bar for "does it come together" at this stage — U22's thread (into the VRAM) is the one I'd keep pulling on next, since it's the closest thing to an actual functional link so far.
This is very tedious, thinking I might just desolder everything but the VRAM, U9 and maybe the ROM Sockets. So much easier and I can install wire wrap sockets for anything removed if I need to bodge a trace.
I get the appeal — pulling a chip turns "probe the mirrored solder-side view and hope the registration held" into "look straight down at bare pads from the top." That's not a marginal improvement, it removes the whole obscured-via problem for anything you socket. A couple of things I'd want settled before doing it wholesale, though, not to talk you out of it, just so it doesn't cost you something you can't get back.
The GALs are the one category where this isn't a "worst case, buy a replacement" situation. The 74-series logic (F161, F166, F109, LS393) is generic and cheap — if a leg snaps pulling one, you drop in a new one and you're not out anything but a part. The GAL20V8s and the GAL16V8 are different: they're programmed with Radius's actual logic equations, and that program only exists on this board. If one of those gets damaged coming off — a lifted pad, a cracked pin — whatever equations it held are gone for good, not "hard to find," just gone. So if "everything but VRAM/U9/ROM" includes the other four GALs (U22, U17, U13, U8, U10), I'd flip the order on those specifically: read each one's fuse map with a GAL programmer before it comes off the board, not after. That's not just risk mitigation either — pulling a GAL is the only way to read it in the first place, since that has to happen out-of-circuit in a programmer's socket. So there's a real upside hiding in the same step: if you've got access to a GAL programmer, desoldering the GALs is your one chance to archive their logic digitally, and once that's done the physical chip stops being irreplaceable — worst case after that, you've lost a socket, not the design.
Second thing, smaller: you were planning to find this board's layer count by filing the edge, and I don't think that's happened yet. Worth doing before a mass desolder session rather than after — a 2-layer board tolerates repeated reheating a lot better than a 4-layer one, where a buried via can get damaged without you ever seeing it happen. Cheap to check first, expensive to find out the hard way mid-desolder.
If it were me, I'd sequence it: pull the 74-series chips first — good practice for heat control on 40-year-old pads, using parts you can replace without a second thought — then decide on the GALs once you've got a feel for how the pads on this specific board behave, and only after their fuse maps are safely read out. VRAM and ROM staying put sounds right regardless; nothing to gain there and the VRAM pinout's already fully nailed down.
No big deal for removal as all GALs and ROMs are socketed on the board. The security fuses are blown, but “glitching” a readout of the formulas isn’t a big deal these days.
The TTL I’ll just lop off at the legs and desolder each pin individually, same with the socket legs. Afterward, wire wrap sockets installed and new TTL components installed.
That resolves the part I was actually worried about — sockets mean pulling the GALs and ROMs costs nothing, there's no pad or pin at risk either way, so "everything but VRAM/U9/ROM" is a much lower-stakes plan than I was picturing. And the security-fuse glitch readout is a legitimate, well-trodden technique at this point for exactly this situation (blown security bit on an old GAL/PAL), so that's not a real obstacle either — good to know it's already accounted for.
Lopping the legs at the body before desoldering pins individually is the right call on the TTL, too — that's the technique that avoids the actual failure mode (rocking a whole package under heat and lifting a pad), so I've got nothing to add there.
One small upside worth noting now that the GALs are risk-free to pull: there's no reason to wait on reading their fuse maps. Since unplugging them costs you nothing, you could dump all five GAL equations whenever it's convenient — before, during, or after the TTL rework — rather than treating it as a step that has to happen at a particular point in the sequence.
Haven’t got the equipment or know-how for the glitch approach to the things myself. I’ve got a friend who did that with the GALs of my Performer Accelerator. That’s been cloned 1:1 and reproduced for the SE. Something like three simplified variations have been developed by others. I’ll lean on him or another boffin for that end of things.
Good setup to have — someone with hands-on glitching experience on real hardware beats working from documentation alone, and it means that step isn't gated on your own timeline at all. You can keep moving on the desolder/socket work and the buzz-testing in parallel, and hand the GALs off whenever it's convenient for him rather than needing to sequence around it.
Yep, been planning that division of labor all along.
I may see if I can get a third card if I can find one? I need to get the SE set up to test both cards before doing any desoldering. That’ll require running the card’s outputs to the “RGB” inputs of my Extron Scaler to get its little image centered up on a 1080p HDMI panel.
Smart sequencing — confirming both cards actually work before anything gets desoldered means you'll know for certain any later problem is something you did, not something that was already wrong going in.
One thing worth checking before you wire it up: the FPD's output isn't RGB, it's monochrome TTL — a single video line plus separate H/V sync off J1 (pins 3, 7, 9 in your pinout), not three color channels. Most "RGB" inputs on scalers like the Extron are built for either analog RGBHV or genuine TTL digital RGB (the latter's common on scalers meant for CGA/EGA-era gear), so getting a picture usually means tying that one video line to all three color inputs rather than finding three signals that don't exist — worth confirming which mode your specific unit's RGB input actually expects before you build the cable. The other thing I'd check is the scaler's supported sync range: ~68.8kHz horizontal paired with ~67Hz vertical is an unusual combination (high line rate, non-standard low field rate), so auto-detect on some scalers can balk at it even when the electrical levels are otherwise fine — if the Extron has a manual timing entry mode, that's worth knowing about ahead of time rather than discovering it's needed after the picture won't lock.
On the third card — happy to poke around vintage-Mac channels beyond eBay (68kMLA, collector Discords/Facebook groups, etc.) if you want a hand watching for one; just say the
Tying the co-axial single bit output from my Radius Two Page Display card to RG&B inputs was the way I got it up and running on a modern LCD. That’s why I put RGB in quotes. It didn’t sync up correctly, but I took a shot at it with the Extron RGB-HDMI 300.
Dunno if you can get thru, they’ve set up a system to keep bots out as best they can.
https://68kmla.org/bb/threads/good-reasonable-hdmi-scaler-extron-rgb-hdmi-300-a.35750/
Couldn't get through to 68kMLA — you called it, their bot-blocking (Anubis) shuts out fetch tools same as it does most bots. Went to Extron's own spec sheet for the RGB-HDMI 300 A instead, which turned up something worth knowing before you try this again on the FPD card.
Documented specs: horizontal sync 30kHz–100kHz, vertical 24Hz–120Hz, sync input level 2.75–5.0Vpp, and it wants RGBHV, RGBS, or RGsB — analog video modes. The TPD/FPD's known sync rates (~68.8kHz H, ~67Hz V) sit comfortably inside that frequency window, so whatever kept it from locking on the TPD probably wasn't a frequency-range problem — the scaler is rated for faster and slower than what this card puts out.
Two more likely culprits, given that: sync polarity, and signal type on the color channels. TTL-level sync (Mac video sync is usually active-low, i.e. inverted from what some gear expects by default) trips up a lot of scalers that don't auto-detect polarity correctly — if the Extron has a sync-polarity setting or DIP switch, that's worth checking before anything else. Separately, "RGBHV" specifically means separate H and V sync lines feeding their own inputs, distinct from RGBS or RGsB where sync rides on the green channel or a combined line — if the coax video line went to R/G/B while H and V went to their own pins, that's the right mode in principle, but worth double-checking the scaler didn't default to expecting sync-on-green instead and just never found it on green (since green in your setup is carrying video, not sync). And separately from the sync question: that coax line is presumably a full 0–5V TTL swing, not the ~0.7Vpp an analog RGB input expects for video — that alone wouldn't stop sync from locking, but it would explain a blown-out or clipped image even once it does lock, so a simple resistor divider to knock the amplitude down before it hits R/G/B might be worth having on hand regardless.
Sources:
RGB-DVI 300 / RGB-HDMI 300 A Specifications
Didn’t do more than this first run at it w/o reading the documentation. It worked, I think that’s called a beat pattern? That was it for TPD playtime, not all that interested in it, unlike the FPD, it can’t be cloned.
Went on to getting the far superior SuperMac Spec/8 SI card up and running and got it almost perfectly dialed in. It’s for the Color Quickdraw capable Iisi and SE/30 030 PDS.
That striping is a good sign, oddly enough — it's exactly what you'd expect from a pixel-clock mismatch rather than a broken connection or a bad sync polarity guess. "Beat pattern" is a fair name for it: the scaler's ADC doesn't have a real pixel clock to lock to on a source like this, so it derives a sample clock by multiplying your H-sync frequency by an assumed pixel count per line. When that assumed count is off from what the TPD is actually putting out, the sampling grid slowly drifts against the real image and you get that repeating vertical interference — same underlying mechanism as a scan-rate converter beating against an odd source, just showing up as static bars instead of a rolling one since nothing's actually moving relative to itself.
The SuperMac card locking up clean on the same scaler is a nice confirmation, actually: it tells you the scaler and your wiring approach are both fine in general, and the TPD's stripes are specifically about it being a non-standard, no-pixel-clock-reference source rather than something wrong with the setup. Good thing to have banked before you get to the FPD, since it's the same era and same general TTL-mono heritage as the TPD — I'd expect the same striping on a first pass there too, for the same reason, not a sign anything's wired backward.
If you ever want a clean picture rather than just a synced one — on the FPD once you get there, since the TPD's not worth the effort — the usual fix for this exact symptom is a scaler with a manual clock/phase adjustment (sometimes called "dot clock" or just "clock" in the OSD), which lets you hand-tune the assumed pixels-per-line until the beating disappears. Worth checking whether the RGB-HDMI 300 A exposes that anywhere in its menu; not all of the fixed-function ones do, but it's the right thing to look for if it's there.
Getting FPD to show up ugly like that is all I need to do. No dialing in, just test them for function. FPD card’s output will be run through the FPGA Project Board for rotation transform and then sent out the card’s HDMI port.
That simplifies it a lot, then — the striping is irrelevant to what you actually need out of this step. If the picture shows up at all, ugly or not, that's sync locking and pixels moving, which is all a function test needs to prove: the card's alive, the crystal's running, and it's putting out valid video and sync. No reason to touch the scaler's tuning for that.
Good to have the endpoint confirmed too — the FPGA board doing the rotation transform and driving its own HDMI out means the Extron path is really just a bring-up tool, not anything that needs to survive into the final pipeline. Once you're tapping the TTL video/sync for real, it's headed to the FPGA board's input, not through a consumer scaler at all, so none of today's scaler quirks need to follow you there.
Yeah, no hobbyist level scaler or RGB-to-VGA thingie can do the image rotation, so heading into FPGA for basically everything was the plan.
For future consideration: the two FPGA Boffins on the forums had green lit my original VRAM capture approach which was insane in hind sight. Going at it this way is so much more direct. They were telling me I should really put the GALs/TTL in the FPGA. So wondering if the FPD card can be cut down to just the bits I’m not planning to desolder and let a more capable FPGA project board do the rest?
____
missed a step here
____
Yep, been thinking in terms of putting what's north of that “power conditioning divide” you identified on the FPGA and leaving everything south of it that’s attached to the PDS in a 1:1 clone of the original. IOW, the components I'm not planning to desolder.
Voltage leveling is a given. There are probably more line conditioning requirements I don’t have a clue about that will be necessary, but thats a fer piece down the road!
Planning to delete J1 output from the clone once HDMI output is established. May keep it there as a backup test route for a while though.
That's a sensible way to phase it out rather than committing to cutting it immediately — keeping J1 alive as a fallback means you've always got a way to sanity-check the card's TTL video/sync output directly (feeding the Extron scaler, same as your function tests) independent of whatever the FPGA is doing with rotation and HDMI. That's a cheap insurance policy while the FPGA side is still being bootstrapped and debugged, since it lets you isolate "is the card itself producing correct signals" from "is the FPGA correctly transforming them" — two very different failure modes that'd otherwise get tangled together if J1 were gone from day one.
Worth keeping in mind for whenever you do pull it: J1 is downstream of the Zener clamp network (CR3/CR4/CR5) and whatever's feeding it from the TTL side, so once those upstream chips get desoldered and replaced by FPGA-driven signals, J1 keeps working exactly as a test tap as long as the FPGA is also driving that same net at the same point in the topology — you're not lopping off a chip that only J1 depended on, you're just deciding when to stop tapping a signal you no longer need in parallel with HDMI.
Updated memory
Sounds like a solid plan — keep it as a diagnostic escape hatch until the FPGA/HDMI path has proven itself out, then retire it once you trust the new path more than you need the old I’ll probably play around with the buzzing a bit while getting the SE set up for testing. If you can locate another FPD card in the $40-$60 range let me know!one.
I’ll probably play around with the buzzing a bit while getting the SE set up for testing. If you can locate another FPD card in the $40-$60 range let me know!
____
No luck — I didn't find any current eBay listings for the actual SE-compatible FPD card (the PDS version yours is). What does turn up under "Radius Full Page Display" is either the incompatible NuBus version for the Mac II (Radius 630-0009), the standalone FPD
monitor being sold on its own, or unrelated vintage Mac bundles that happened to match the search terms loosely. Nothing in the $40-60 range, or really at any price, for the SE card itself.
That tracks with what you already knew — these are scarce enough that even a 68kMLA forum thread I turned up is literally titled "Does anyone have the Radius FPD Card for SE with rev. 4.4 ROMs on board?", which is a good sign of how thin the supply is. I can't get into the 68kMLA marketplace/classifieds myself since that site blocks fetching, so if a listing exists there, you'd need to check it directly — that's probably actually your best hunting ground given how niche this card is, more than eBay's general search.
I'll keep this in mind and can do another sweep later if you want, but for now there's nothing concrete to report. If you'd like, I can also check occasional Mac collector marketplaces (VCF forums, Tinkerdifferent classifieds) next pass.
Yeah, looked this week, but the only FPD card I saw was the proprietary ASIC ridden 75Hz board that can't be cloned.
Figures — the 75Hz ASIC board being the one that actually surfaces makes sense if it was the later/more common revision, while the 64/68Hz discrete-logic board you're working with was the shorter-lived original run. At least it confirms the search results I turned up weren't missing something obvious; the card you need really is that scarce right now.
Project Overview & Specs
Current Progress Report: How Close Is It?
95% Complete
60% Complete
10% Complete
Summary for Newcomers