Radius FPD/SE - Rotation Transform/HDMI Output via FPGA Project Board - CLAUDE SESSIONS

Trash80toG4

Active Tinkerer
Apr 1, 2022
1,472
470
83
Bermuda Triangle, NC USA
Good eye — that continuous line is real. Zooming into just the photo (no overlay), you can see the trace itself runs right through the ink stamp without interruption — the ink is sitting on top of the solder mask, so seeing copper trace geometry "through" it just confirms it's genuinely part of the board surface at that spot, not a stamp artifact.

But before jumping to a 4-layer buried-plane explanation, I'd want to rule out a much simpler one: U25 and U26 are unimplemented footprints — nothing ever gets soldered there. If Radius's layout software saw those two pad rings as dead space (no populated pins to keep clear of), running an ordinary 2-layer trace straight through the middle of that footprint costs nothing and avoids needing a jog around it. That would fully explain a trace visually "connecting" U25 and U26 without needing anything exotic — it's not really connecting the footprints at all, just happening to physically transit the space between their pads on its way somewhere else on the net.

A true 4-layer power/ground-plane implementation would be a bigger claim, and worth being skeptical of by default: 4-layer boards were meaningfully more expensive to fab in 1986-88, and would be an unusual choice for what's otherwise a fairly conventional double-sided accessory card — though the trace density you've been finding isn't nothing, so I wouldn't rule it out purely on cost grounds either.

A few ways to actually settle it rather than guess:
  1. Check where that line's endpoints actually go. Does it terminate at real component pins elsewhere (i.e., it's just one ordinary net passing through the dead footprint en route from A to B), or does it appear to dead-end at U25/U26 pads specifically with no other explanation for continuity between them? The former supports "ordinary trace through empty space"; the latter is more interesting.
  2. Cross-check against your component-side trace/thruhole layers at the same XY. If there's also a component-side trace at that same location forming part of the same apparent net, that's double-sided routing, not a buried layer — no exotic explanation needed.
  3. Physical test for real layer count, if you want to settle it conclusively: look at a via barrel or the raw board edge (if any is exposed/unmasked) under strong magnification and backlighting. A 2-layer board's via cross-section shows plating only at top and bottom; a 4-layer board shows an additional annular ring or copper reveal partway through the barrel. This is the only truly non-destructive way to confirm internal layers without buzzing things out blind.
If after tracing the endpoints it really does look like an isolated net that only makes sense through a plane, that'd be a genuinely notable find for a card of this vintage — just worth ruling out the boring explanation first given how well it fits (unimplemented footprint = free real estate to route through).

Graphics workstation, now a Mirror Drive Door G4 setup upgrade, is Neolithic 2004 tech along with my software. Like my hardware, I live in the Neolithic when it comes to this kind of thing as well. Taking a file to the edge of the board at a low angle exposes layers like a spectrum. I can determine the number of layers without fooling around with less radical, error prone conventional approaches. ;-)

Fair enough — that's a genuinely better answer than either of mine. A low-angle bevel file exposes the whole stackup at once as a visible cross-section, no probing, no blind buzzing, no hoping a via barrel happens to be visible at the right spot. Metallurgical prep labs call it a "bevel section" and it's exactly the technique used for real PCB failure analysis when someone needs to count layers with certainty — you're not roughing it, you're just skipping the expensive lab equipment version.

One small technique note in case it's useful: keep the bevel angle shallow and consistent (something like 5-10°) rather than steep — it stretches out the layer spacing so thin internal planes don't get lost in file-scratches, and a drop of oil or water on the exposed face while you inspect it under light will make the copper-vs-substrate contrast pop a lot better than looking at it dry.

Good luck with the U25/U26 net — genuinely curious whether it turns out to be the dead-footprint explanation or an actual plane. Either way you'll have a real answer instead of a guess.

Very shallow angle and liquid emulsion are my methods!

Good — that tracks with knowing exactly what you're doing rather than winging it. Let me know what the bevel turns up on the U25/U26 net once you've had a look; genuinely curious which way it goes.
 
Last edited:
  • Like
Reactions: Froggy814

Trash80toG4

Active Tinkerer
Apr 1, 2022
1,472
470
83
Bermuda Triangle, NC USA
Here's the first pass, built on the confirmed J1/clamp-network subsystem — "half the data" as promised:

What it shows: the J1 header and its clamp network overlaid directly on the true-scale component-side photo (labels are legible there, unlike bare copper on the solder side), with a pinout sidebar breaking down what's confirmed for pins 2/3/6/7/9, plus notes on the Zener clamp network.

How I handled confirmed vs. unconfirmed, per what we agreed:
  • Green boxes/text = things you've actually buzzed out (J1 pin functions, the clamp network's populated parts).
  • Red dashed line = CR3, called out specifically as untraced.
  • Red text = the Zener common node's destination (a GAL pin 13, designator still TBD).
  • I deliberately left out any long lines running clear across the board to U22 or U2 — I don't have verified pixel coordinates for those ICs' exact locations, and drawing a line I haven't actually confirmed against the image felt like the wrong kind of "confident." Instead those two nets are just stated in the sidebar text (pin 7→U22 pin 7, pin 9→U22 pin 8, pin 3→U2 pin 7) as confirmed facts without a hand-drawn path backing them visually.
Once you've got the component-side buzz-out done, the natural next version would extend this same treatment out to U22 and U2 with real traced paths instead of sidebar text — happy to build that when you're there.

Got it! Thanks for giving me the little available. Understood that the vertical traces on the solder side offer little, if any, clues as to the web of connections between ICs on the board. Horizontal connections buzzed and annotated should tell the tale? Lots of work to do before getting close to there.

That tracks with what we've been seeing. If the solder side is running mostly vertical bus-style traces — signal comes down from an IC, travels a long straight run, and doesn't reveal on its own who it's actually talking to — then it's functioning more like a highway than an intersection. The real "who talks to whom" information lives at the horizontal jogs, which is exactly where a trace is doing the work of steering a signal from one column/IC to another.

Two things worth watching for as you buzz the horizontal runs:
  • Vias are the tell. Anywhere a vertical solder-side run ends and a horizontal component-side run picks up (or vice versa) is a layer change, and that's precisely the junction that decides connectivity. If you can spot and log via locations as you go, that gives you a skeleton of "decision points" even before every horizontal segment is fully buzzed.
  • Watch for false continuity at crossovers. Since the layers are perpendicular by convention, a vertical trace and horizontal trace crossing in the photo aren't connected unless there's a via right at that intersection — worth flagging in your notes explicitly (confirmed via vs. incidental crossing) so future-you doesn't second-guess it later.
Given that, the horizontal/component-side buzz-out is genuinely the higher-value half of the remaining work — the solder-side vertical traces you've already got mostly tell you that a net exists and roughly where it runs, not which IC pins it ultimately ties together. Real slog, but it's the part that actually builds the netlist.

Cool beans! Though not a programmer of note, I’ve heard of vibe coding, I’m thinking of this as vibe diving!

"Vibe diving" is a great name for it — no compiler to catch your mistakes, just a multimeter, a magnifying glass, and faith that the next trace goes where you think it does. Bad continuity reading is basically vibe coding's runtime error.

Enjoy the dive — ping me when you surface with more nets.

Will do. I've found your time stamped operations reports fascinating, could you provide a tight txt file of your processes as displayed while I wait for results. I think others will find it interesting.

Glad it was useful — good luck with the buzz-out, and enjoy the dive. Ping me whenever you want to pick this back up.
 

Attachments

  • Radius-FPD-J1-Annotated-Diagram.jpg
    Radius-FPD-J1-Annotated-Diagram.jpg
    454.5 KB · Views: 3
Last edited:

Trash80toG4

Active Tinkerer
Apr 1, 2022
1,472
470
83
Bermuda Triangle, NC USA
This one sort of stopped where I'd hoped it would begin, but still interesting I think?
_____________________________________________________________________________________________________________

RADIUS FPD (SE) CLONE PROJECT — CLAUDE PROCESSING LOG
Session date: 2026-08-30/31 (image pipeline) + 2026-09-10 (diagram build)
Tools: Python 3 / OpenCV / PIL / scikit-image / reportlab / poppler-utils

================================================================
PHASE 1 — PHOTO STRAIGHTENING & TRUE-SCALE CALIBRATION
================================================================
23:38:50 Rasterized FPD-Schematic-012.PDF (150dpi) to inspect vector
board-outline reference; confirmed it covers J1/crystal/
U2-U7/ROM area only, not full board.
23:39:50 Cropped silkscreen text regions on all 3 uploaded photos
(Solder-V, Component-V, Component-VM) to determine true
orientation by reading text forward/backward.
Result: Component-V and Component-VM both required 180
deg rotation; Solder-V was already correctly oriented.
23:40:32 Rendered 180-degree-corrected previews for visual QC.
23:42:12 Applied gross 180-deg flip + fine auto-detected skew
correction (OpenCV minAreaRect on board contour vs.
background mask) to all 3 photos. Residual skew found:
Solder-V +0.211 deg, Component-V +0.143 deg,
Component-VM -0.141 deg.
23:42:22 Cropped all 3 straightened images tight to board contour
bounding box (20px margin). Board bbox width consistent
across all three: 2732px -- confirms same camera distance
for all shots.
23:46:03 Saved final straightened/cropped outputs, generated
downscaled previews for visual verification.

================================================================
PHASE 2 — LIFE-SIZE CALIBRATION
================================================================
User-supplied reference measurement: PCB width = 123mm (calipers).
Calculation: 2732px / (123mm / 25.4) = 564.17 px/inch native.
Derived DPI tags: 1x = 564.2, 2x = 282.1, 4x = 141.0 dpi.
Applied as embedded JPEG DPI metadata (no pixel resampling) so
files print/place at correct real-world scale in any DPI-aware
app. Later regenerated as 8-bit (256-level) grayscale JPEGs at
same three DPI tiers to cut file size ~3x for period-correct
Illustrator 8 hardware (originally a 2004/5 PowerBook, later a
Mirror Drive Door Power Mac G4).

================================================================
PHASE 3 — AUTO-VECTORIZATION (TRACE + PAD EXTRACTION)
================================================================
23:57:00 HSV color-threshold segmentation of copper traces
(hue ~55-105, i.e. the teal exposed-copper color) and
through-hole pads (low-saturation/high-value, circular
blobs) on the solder-side image. Masked to board interior
to avoid background contamination.
23:58:07 Extracted 2,420 trace contours + 821 pad circles (solder
side); pickled intermediate geometry.
23:58:25 Built true-scale vector PDF (reportlab): board outline
(stroked), traces (filled teal polygons), pads (filled
gray circles). Page size set from the 123mm calibration.
23:58:30 Rasterized result at 300dpi for visual QC.
23:59:11 Repeated full pipeline for component-side image: 2,358
trace contours, 715 pads. Noted lower reliability here —
less color contrast around IC/ROM footprint silkscreen
boxes causes some non-trace fill artifacts.
00:00:22 Converted both vector PDFs to Level 2 EPS (poppler
pdftops -eps -level2) for native Illustrator 8
compatibility (AI8 predates Adobe's PDF-based file
format, introduced in Illustrator 9).

================================================================
PHASE 4 — ANNOTATED DIAGRAM (J1 / CLAMP NETWORK)
================================================================
01:38:14 Cropped candidate regions of the component-side photo
searching for the J1 header and clamp network by e
 
  • Like
Reactions: Froggy814