I'll edit in the other threads leading to this.
Spent a bit of time with Claude Code this evening, here's what Mr. Code laid out:
Spent a bit of time with Claude Code this evening, here's what Mr. Code laid out:
Last edited:
Radius FPD/SE clone with Rotation Transform and Output from HDMI of FPGA Project Board
- Thread starter Trash80toG4
- Start date
# Scanline Rotation Transform — Engineering Spec
## 0. Project Context: Cloning the 1986 Radius FPD (64/68Hz Board)
This project clones the original 1986 Radius Full Page Display card for the Macintosh SE — specifically the first-generation **64/68Hz board**, not the incompatible second-generation 1987 75Hz board (different signal timing, not interchangeable).
**Confirmed specs:**
- Resolution: **640 wide × 864 high**
- Color depth: **1 bit per pixel** (monochrome, black/white)
Because this is a clone of real vintage hardware (not a new design driven purely by a written spec), the project has an added prerequisite phase: **capturing and characterizing the actual analog signal timing from a real 64/68Hz card**, since the sync/blanking/porch timings are a product of 1986-era hardware design choices, not a standard later-era VESA mode. Guessing at "similar" timings risks producing a signal the original FPD monitor (or a monitor emulating it) won't lock onto.
### Phase 0 — Signal capture & characterization (new, precedes Phase 1)
**Decision: single fixed timing mode.** The clone targets **Crystal 1 (55.000 MHz)** only:
- Horizontal scan rate: 68.75 kHz
- Vertical refresh: 67.139 Hz
- Total pixels/line: 800 (640 active + 160 blanking)
- Total lines/frame: ~1024 (864 active + ~160 blanking)
This crystal is selected because its nominal rates resolve cleanly to round binary-friendly totals, consistent with straightforward TTL counter-based sync generation — the most likely candidate for the board's actual native/primary mode. Crystal 2 (dual-mode support) is out of scope for this clone.
**Action items (single-mode capture, simplified from prior dual-mode plan):**
- Capture real horizontal sync, vertical sync, and pixel clock timing from an actual 64/68Hz card operating in the 55.000 MHz / 68.75kHz / 67.139Hz mode, using a logic analyzer/oscilloscope
- Confirm exact horizontal blanking split (front porch / sync pulse / back porch, out of the 160-pixel blanking total) and vertical blanking split (out of the ~160-line total) — the 800×1024 totals are inferred from nominal rates, but the internal timing breakdown still requires direct measurement
- Document sync pulse widths and polarity (positive vs. negative sync)
- Deliverable: a single timing table (equivalent to one VESA mode entry) for this specific fixed mode, to drive the FPGA's sync generator
### Phase 0.5 — Physical tap point & interface identification (new)
Separate from signal *timing* characterization (Phase 0), this phase identifies *where* and *how* to physically divert the page buffer output from the original card to the FPGA, without disturbing the card's own display path.
**Hardware setup:**
- "Tested good" card: reference/baseline, kept intact and unmodified — used for continuity-verified schematic development and as a known-good comparison signal source
- Project-box spare card: used for invasive work (tapping, soldering, probing) since it's expendable
**Signals to identify at the display connector (TTL interface):**
- Serial pixel data (1-bit monochrome — likely single data line)
- Pixel clock (PCLK)
- Horizontal sync (HSYNC)
- Vertical sync (VSYNC)
- Possible blanking/display-enable line (BLANK/DE) — confirm whether this exists as a discrete signal or must be reconstructed from sync timing in the FPGA
**Key considerations:**
- **Logic levels:** confirm TTL voltage (likely 5V). If FPGA I/O is not 5V-tolerant, tapped signals need level-shifting (buffer IC recommended over a resistor divider, to avoid signal degradation)
- **Non-invasive tap:** use a high-impedance buffer (e.g., 74LVC245 or similar) to tap signals without loading the original circuit — needed since the original card should continue driving the FPD monitor unaffected, if that's still a project goal, while simultaneously feeding the FPGA
- **Tap point location:** identify the point after the page buffer's shift-register/serializer (where pixel data is already serial, sync'd to PCLK) rather than tapping earlier in the pipeline where data may still be in a different form
**Deliverable:** an annotated schematic (extending the continuity-tracing work already underway) identifying exact pin/trace locations for each signal, plus a level-shifting/buffering plan for the FPGA interface.
## 1. Problem Statement (updated)
The (cloned) video card outputs a portrait-orientation raster scan (row-major, top-to-bottom, left-to-right within each row) at 640×864, 1-bit monochrome, using the original 1986 Radius 64/68Hz board's native timing. The physical display panel is a landscape-native modern device (e.g., HDMI monitor), driven via the FPGA project board. A compensating 90° rotation must be applied between source and panel so the image displays right-side-up.
## 2. Confirmed Coordinate Transform
Verified against a worked 4×7 (W×H) example, pixel-by-pixel, against both terminal points (top-right and bottom-right source corners).
**Source (portrait):** width `W`, height `H`, pixel addressed `(x, y)`
- `x ∈ [0, W-1]` (column)
- `y ∈ [0, H-1]` (row)
- Scanned row-major, top to bottom
**Output (landscape buffer):** width `H`, height `W` (dimensions swap)
- Pixel addressed `(x', y')`
**Transform (rotation direction: clockwise):**
```
x' = (H - 1) - y
y' = x
```
### Worked example (W=4, H=7)
| Source (x,y) | Pixel # | Output (x',y') | Output # |
|---|---|---|---|
| (0,0) | p01 | (6,0) | x07 |
| (0,6) | p25 | (0,0) | x01 |
| (3,0) | p04 | (6,3) | x28 |
| (3,6) | p28 | (0,3) | x22 |
All four corners confirmed consistent with the formula above.
## 3. Buffering Requirement (Critical)
This is **not** a line-buffer-compatible transform. Output row `y'=0` requires the first pixel of *every* source row — i.e., the entire first source column — which isn't complete until the last source row has been received.
**Implication:** a full source frame must be buffered before any output row can be emitted.
- Minimum: 1 frame buffer (adds ~1 frame time of latency)
- Recommended: 2 frames (ping-pong / double buffer) to avoid tearing while the next frame is being written while the current one is being read out rotated
- Latency estimate: at 60 Hz, ~16.7 ms minimum (single buffer), ~33 ms typical (double buffer)
## 4. Generalization to Production Resolution
The formula is resolution-independent — substitute actual `H` (source height) for production use:
```
x' = (H_actual - 1) - y
y' = x
```
**Action item:** confirm actual production resolution and aspect ratio before implementation. The 4×7 example was a worked proof-of-concept only; do not hardcode `H=7` into production code.
## 5. Production Configuration: 640×864 Portrait → 1024×768 Landscape (Centered)
**Confirmed:** source is W=640 (wide) × H=864 (tall). Target panel is 1024×768, physically mounted rotated so the viewer sees a portrait image. Since the rotated source (864×640) is smaller than the panel's native landscape resolution (1024×768), it must be centered with a border.
### Step 1 — Rotate (CW)
Using the general formula from Section 4 with `H=864`:
```
x' = 863 - y
y' = x
```
Produces a rotated buffer of 864 (wide) × 640 (tall).
### Step 2 — Center in 1024×768
- Horizontal border: `(1024 - 864) / 2 = 80` px, left and right
- Vertical border: `(768 - 640) / 2 = 64` px, top and bottom
### Combined transform — source `(x, y)` → final panel address `(X, Y)`
```
X = 943 - y (= 863 - y + 80)
Y = x + 64
```
Valid for `x ∈ [0,639]`, `y ∈ [0,863]` → `X ∈ [80,943]`, `Y ∈ [64,703]`. Pixels outside this box are border and need an explicit fill value (e.g., black).
### FPGA Implementation Notes
- **Frame buffer sizing (confirmed 1-bit depth):** source frame = 640 × 864 = 552,960 pixels = 69,120 bytes (~68 KB) at 1 bpp. Double-buffered: ~135 KB total — very likely fits on-chip BRAM on most mid-size FPGA boards, avoiding external DRAM/memory controller complexity.
- **Clock domain crossing:** source pixel clock (native 1986 64/68Hz board timing — to be measured in Phase 0) and 1024×768 HDMI output clock (~65 MHz for standard 60 Hz XGA timing) are independent domains. The frame buffer must be implemented as a proper dual-clock RAM/FIFO, not a single-clock design, to avoid metastability.
- **Border fill:** decide and hardcode a fill value (black recommended) for the 80px/64px borders; gate output explicitly during border regions rather than leaving them undefined.
- **HDMI timing:** 1024×768 is a standard VESA mode with well-documented timing tables — confirm target refresh rate (60 Hz assumed) since it sets the pixel clock and output-side buffer read rate.
## 7. Target Display Selection
**Primary target (this spec): 1024×768** — 15" DVI panel already in hand, HDMI→DVI converted. This is the configuration detailed in Section 5 (centered, no scaling required).
**Considered alternative: 1280×1024** — inexpensive, widely available LCD panels. Deferred to a future phase for the following reason: centering the 864×640 rotated image alone leaves large unused borders (208px sides, 192px top/bottom), so a scaled-up image would be preferable — but scaling a 1-bit monochrome image cleanly requires nearest-neighbor pixel replication (no interpolation possible), and 864×640 doesn't scale by a clean integer factor into 1280×1024. This needs a Bresenham-style pixel-replication accumulator, added frame-buffer read bandwidth, and an extra pipeline stage — nontrivial additional scope.
**Recommendation:** build and validate the 1024×768 centered (no-scaling) pipeline first as the primary deliverable. Treat 1280×1024 (with scaling) as a follow-on enhancement once the core rotation/timing pipeline is proven, not a parallel initial target.
## 8. Open Items Before Implementation
- [x] Confirm production source resolution — **confirmed: 640×864 (W×H), 1986 Radius 64/68Hz board**
- [x] Confirm color depth — **confirmed: 1-bit monochrome**
- [x] Single vs. dual timing mode — **confirmed: single fixed timing, targeting the 55.000MHz/68.75kHz/67.139Hz crystal 1 mode**
- [x] Target display for initial build — **confirmed: 1024×768 15" panel, centered, no scaling (primary); 1280×1024 scaled deferred to future phase**
- [ ] Capture and document exact horizontal/vertical blanking breakdown (front porch/sync/back porch) for the fixed mode (Phase 0)
- [ ] Identify exact tap point for pixel data, PCLK, HSYNC, VSYNC (and BLANK/DE if present) on the display connector (Phase 0.5)
- [ ] Confirm TTL logic voltage and FPGA I/O compatibility; select level-shifting/buffering approach
- [ ] Decide whether original card must continue driving its own FPD monitor simultaneously (affects whether tap must be non-loading/high-impedance) or whether the original display path can be fully diverted
- [ ] Confirm target refresh rate for 1024×768 output (60 Hz assumed)
- [ ] Confirm frame buffer implementation: on-chip BRAM (now very likely sufficient at 1bpp) vs. external memory
- [ ] Confirm latency budget tolerates ~1–2 frames of added delay — flag if this is a touch/interactive/real-time application
- [ ] Verify rotation direction (CW, as derived here) against actual physical mount orientation on real hardware
- [ ] Decide and implement border fill value/logic for the 80px/64px letterbox regions
- [ ] Clarify what "64" and "86" refer to in the board's name (vertical refresh? horizontal scan rate? two distinct modes?) — relevant to Phase 0 timing capture
## 0. Project Context: Cloning the 1986 Radius FPD (64/68Hz Board)
This project clones the original 1986 Radius Full Page Display card for the Macintosh SE — specifically the first-generation **64/68Hz board**, not the incompatible second-generation 1987 75Hz board (different signal timing, not interchangeable).
**Confirmed specs:**
- Resolution: **640 wide × 864 high**
- Color depth: **1 bit per pixel** (monochrome, black/white)
Because this is a clone of real vintage hardware (not a new design driven purely by a written spec), the project has an added prerequisite phase: **capturing and characterizing the actual analog signal timing from a real 64/68Hz card**, since the sync/blanking/porch timings are a product of 1986-era hardware design choices, not a standard later-era VESA mode. Guessing at "similar" timings risks producing a signal the original FPD monitor (or a monitor emulating it) won't lock onto.
### Phase 0 — Signal capture & characterization (new, precedes Phase 1)
**Decision: single fixed timing mode.** The clone targets **Crystal 1 (55.000 MHz)** only:
- Horizontal scan rate: 68.75 kHz
- Vertical refresh: 67.139 Hz
- Total pixels/line: 800 (640 active + 160 blanking)
- Total lines/frame: ~1024 (864 active + ~160 blanking)
This crystal is selected because its nominal rates resolve cleanly to round binary-friendly totals, consistent with straightforward TTL counter-based sync generation — the most likely candidate for the board's actual native/primary mode. Crystal 2 (dual-mode support) is out of scope for this clone.
**Action items (single-mode capture, simplified from prior dual-mode plan):**
- Capture real horizontal sync, vertical sync, and pixel clock timing from an actual 64/68Hz card operating in the 55.000 MHz / 68.75kHz / 67.139Hz mode, using a logic analyzer/oscilloscope
- Confirm exact horizontal blanking split (front porch / sync pulse / back porch, out of the 160-pixel blanking total) and vertical blanking split (out of the ~160-line total) — the 800×1024 totals are inferred from nominal rates, but the internal timing breakdown still requires direct measurement
- Document sync pulse widths and polarity (positive vs. negative sync)
- Deliverable: a single timing table (equivalent to one VESA mode entry) for this specific fixed mode, to drive the FPGA's sync generator
### Phase 0.5 — Physical tap point & interface identification (new)
Separate from signal *timing* characterization (Phase 0), this phase identifies *where* and *how* to physically divert the page buffer output from the original card to the FPGA, without disturbing the card's own display path.
**Hardware setup:**
- "Tested good" card: reference/baseline, kept intact and unmodified — used for continuity-verified schematic development and as a known-good comparison signal source
- Project-box spare card: used for invasive work (tapping, soldering, probing) since it's expendable
**Signals to identify at the display connector (TTL interface):**
- Serial pixel data (1-bit monochrome — likely single data line)
- Pixel clock (PCLK)
- Horizontal sync (HSYNC)
- Vertical sync (VSYNC)
- Possible blanking/display-enable line (BLANK/DE) — confirm whether this exists as a discrete signal or must be reconstructed from sync timing in the FPGA
**Key considerations:**
- **Logic levels:** confirm TTL voltage (likely 5V). If FPGA I/O is not 5V-tolerant, tapped signals need level-shifting (buffer IC recommended over a resistor divider, to avoid signal degradation)
- **Non-invasive tap:** use a high-impedance buffer (e.g., 74LVC245 or similar) to tap signals without loading the original circuit — needed since the original card should continue driving the FPD monitor unaffected, if that's still a project goal, while simultaneously feeding the FPGA
- **Tap point location:** identify the point after the page buffer's shift-register/serializer (where pixel data is already serial, sync'd to PCLK) rather than tapping earlier in the pipeline where data may still be in a different form
**Deliverable:** an annotated schematic (extending the continuity-tracing work already underway) identifying exact pin/trace locations for each signal, plus a level-shifting/buffering plan for the FPGA interface.
## 1. Problem Statement (updated)
The (cloned) video card outputs a portrait-orientation raster scan (row-major, top-to-bottom, left-to-right within each row) at 640×864, 1-bit monochrome, using the original 1986 Radius 64/68Hz board's native timing. The physical display panel is a landscape-native modern device (e.g., HDMI monitor), driven via the FPGA project board. A compensating 90° rotation must be applied between source and panel so the image displays right-side-up.
## 2. Confirmed Coordinate Transform
Verified against a worked 4×7 (W×H) example, pixel-by-pixel, against both terminal points (top-right and bottom-right source corners).
**Source (portrait):** width `W`, height `H`, pixel addressed `(x, y)`
- `x ∈ [0, W-1]` (column)
- `y ∈ [0, H-1]` (row)
- Scanned row-major, top to bottom
**Output (landscape buffer):** width `H`, height `W` (dimensions swap)
- Pixel addressed `(x', y')`
**Transform (rotation direction: clockwise):**
```
x' = (H - 1) - y
y' = x
```
### Worked example (W=4, H=7)
| Source (x,y) | Pixel # | Output (x',y') | Output # |
|---|---|---|---|
| (0,0) | p01 | (6,0) | x07 |
| (0,6) | p25 | (0,0) | x01 |
| (3,0) | p04 | (6,3) | x28 |
| (3,6) | p28 | (0,3) | x22 |
All four corners confirmed consistent with the formula above.
## 3. Buffering Requirement (Critical)
This is **not** a line-buffer-compatible transform. Output row `y'=0` requires the first pixel of *every* source row — i.e., the entire first source column — which isn't complete until the last source row has been received.
**Implication:** a full source frame must be buffered before any output row can be emitted.
- Minimum: 1 frame buffer (adds ~1 frame time of latency)
- Recommended: 2 frames (ping-pong / double buffer) to avoid tearing while the next frame is being written while the current one is being read out rotated
- Latency estimate: at 60 Hz, ~16.7 ms minimum (single buffer), ~33 ms typical (double buffer)
## 4. Generalization to Production Resolution
The formula is resolution-independent — substitute actual `H` (source height) for production use:
```
x' = (H_actual - 1) - y
y' = x
```
**Action item:** confirm actual production resolution and aspect ratio before implementation. The 4×7 example was a worked proof-of-concept only; do not hardcode `H=7` into production code.
## 5. Production Configuration: 640×864 Portrait → 1024×768 Landscape (Centered)
**Confirmed:** source is W=640 (wide) × H=864 (tall). Target panel is 1024×768, physically mounted rotated so the viewer sees a portrait image. Since the rotated source (864×640) is smaller than the panel's native landscape resolution (1024×768), it must be centered with a border.
### Step 1 — Rotate (CW)
Using the general formula from Section 4 with `H=864`:
```
x' = 863 - y
y' = x
```
Produces a rotated buffer of 864 (wide) × 640 (tall).
### Step 2 — Center in 1024×768
- Horizontal border: `(1024 - 864) / 2 = 80` px, left and right
- Vertical border: `(768 - 640) / 2 = 64` px, top and bottom
### Combined transform — source `(x, y)` → final panel address `(X, Y)`
```
X = 943 - y (= 863 - y + 80)
Y = x + 64
```
Valid for `x ∈ [0,639]`, `y ∈ [0,863]` → `X ∈ [80,943]`, `Y ∈ [64,703]`. Pixels outside this box are border and need an explicit fill value (e.g., black).
### FPGA Implementation Notes
- **Frame buffer sizing (confirmed 1-bit depth):** source frame = 640 × 864 = 552,960 pixels = 69,120 bytes (~68 KB) at 1 bpp. Double-buffered: ~135 KB total — very likely fits on-chip BRAM on most mid-size FPGA boards, avoiding external DRAM/memory controller complexity.
- **Clock domain crossing:** source pixel clock (native 1986 64/68Hz board timing — to be measured in Phase 0) and 1024×768 HDMI output clock (~65 MHz for standard 60 Hz XGA timing) are independent domains. The frame buffer must be implemented as a proper dual-clock RAM/FIFO, not a single-clock design, to avoid metastability.
- **Border fill:** decide and hardcode a fill value (black recommended) for the 80px/64px borders; gate output explicitly during border regions rather than leaving them undefined.
- **HDMI timing:** 1024×768 is a standard VESA mode with well-documented timing tables — confirm target refresh rate (60 Hz assumed) since it sets the pixel clock and output-side buffer read rate.
## 7. Target Display Selection
**Primary target (this spec): 1024×768** — 15" DVI panel already in hand, HDMI→DVI converted. This is the configuration detailed in Section 5 (centered, no scaling required).
**Considered alternative: 1280×1024** — inexpensive, widely available LCD panels. Deferred to a future phase for the following reason: centering the 864×640 rotated image alone leaves large unused borders (208px sides, 192px top/bottom), so a scaled-up image would be preferable — but scaling a 1-bit monochrome image cleanly requires nearest-neighbor pixel replication (no interpolation possible), and 864×640 doesn't scale by a clean integer factor into 1280×1024. This needs a Bresenham-style pixel-replication accumulator, added frame-buffer read bandwidth, and an extra pipeline stage — nontrivial additional scope.
**Recommendation:** build and validate the 1024×768 centered (no-scaling) pipeline first as the primary deliverable. Treat 1280×1024 (with scaling) as a follow-on enhancement once the core rotation/timing pipeline is proven, not a parallel initial target.
## 8. Open Items Before Implementation
- [x] Confirm production source resolution — **confirmed: 640×864 (W×H), 1986 Radius 64/68Hz board**
- [x] Confirm color depth — **confirmed: 1-bit monochrome**
- [x] Single vs. dual timing mode — **confirmed: single fixed timing, targeting the 55.000MHz/68.75kHz/67.139Hz crystal 1 mode**
- [x] Target display for initial build — **confirmed: 1024×768 15" panel, centered, no scaling (primary); 1280×1024 scaled deferred to future phase**
- [ ] Capture and document exact horizontal/vertical blanking breakdown (front porch/sync/back porch) for the fixed mode (Phase 0)
- [ ] Identify exact tap point for pixel data, PCLK, HSYNC, VSYNC (and BLANK/DE if present) on the display connector (Phase 0.5)
- [ ] Confirm TTL logic voltage and FPGA I/O compatibility; select level-shifting/buffering approach
- [ ] Decide whether original card must continue driving its own FPD monitor simultaneously (affects whether tap must be non-loading/high-impedance) or whether the original display path can be fully diverted
- [ ] Confirm target refresh rate for 1024×768 output (60 Hz assumed)
- [ ] Confirm frame buffer implementation: on-chip BRAM (now very likely sufficient at 1bpp) vs. external memory
- [ ] Confirm latency budget tolerates ~1–2 frames of added delay — flag if this is a touch/interactive/real-time application
- [ ] Verify rotation direction (CW, as derived here) against actual physical mount orientation on real hardware
- [ ] Decide and implement border fill value/logic for the 80px/64px letterbox regions
- [ ] Clarify what "64" and "86" refer to in the board's name (vertical refresh? horizontal scan rate? two distinct modes?) — relevant to Phase 0 timing capture
Couldn't have explained this better mysel . . . that way at all! 
Hope this makes sense to the gang here.
Claude figured out the need for dual-buffering with a single frame delay before I could tell him. Maybe triple-buffering with a two frame delay will be required?
Here's my "Worked example (W=4, H=7)" image from the earlier threads:
I input the IF/Then parameters for the top row and left column of the Portrait setup which translated to the top row and right column of the "Standard Landscape Display" setup and it was a done deal! Extension to 640×864 transform is a done deal!
edit: never did fix that 75Hz error!
Hope this makes sense to the gang here.Claude figured out the need for dual-buffering with a single frame delay before I could tell him. Maybe triple-buffering with a two frame delay will be required?
Here's my "Worked example (W=4, H=7)" image from the earlier threads:
I input the IF/Then parameters for the top row and left column of the Portrait setup which translated to the top row and right column of the "Standard Landscape Display" setup and it was a done deal! Extension to 640×864 transform is a done deal!
edit: never did fix that 75Hz error!
Last edited:
Second interaction with Mr. Claude Code, thought it might be interesting:
______________________________________________________
Maybe make a new discussion specifically addressing the reverse engineering of the PCB
Saved memory
Saved memory
Good to know — that changes how I should hand you stuff. Since you're working visually in Illustrator (even v8, which is EPS/vector-native and predates a lot of "modern" export assumptions), let's lean into that for the PCB reverse-engineering work rather than dense prose or spreadsheets.
Concretely, that could mean:
Given that, want me to:
Ran a command
Ran a command
I don't actually see a PDF in this conversation yet — the uploads folder is empty on my end. It looks like it didn't attach, so could you try uploading it again?
To answer your two questions directly:
Can I view a PDF? Yes — once it's actually attached, I can open it, view pages as images, and comment on your progress (layout, traces, whatever's in it).
Can you upload a native Illustrator 8 file (.AI)? This chat interface accepts uploads, but heads up on what I can actually do with it:
take a look at this:?
I don't see a file attached to this message — the upload didn't come through on my end. Could you try attaching it again? Once it lands, I'll take a look right away.
https://tinkerdifferent.com/attachments/fpd-schematic-010-pdf.30088/
Fetched: https://tinkerdifferent.com/attachments/fpd-schematic-010-pdf.30088/
Fetched: https://tinkerdifferent.com/attachments/fpd-schematic-010-pdf.30088/
That link resolved, but it came back as raw binary data rather than something I can render or read directly — my fetch tool can't parse PDF content from an arbitrary URL like that (I can only truly "see" a PDF if it's uploaded directly into this chat, where it gets processed properly).
A couple options:
How do I upload a file?
In this chat interface, there should be a paperclip / "+" attachment icon near the message input box (usually bottom-left or left of the text field, depending on whether you're on desktop or mobile). Tapping/clicking that opens a file picker where you can select the PDF from wherever you saved it on your device, and it'll attach to your next message.
Quick steps:
Once it's attached, go ahead and ask me to take a look and I'll dig into the schematic with you.
____________
PDF
Ran 4 commands, viewed a file
Ran 4 commands, viewed a file
I can see it now — and this is genuinely useful. A few things worth calling out:
This is a solder-side PCB trace/placement drawing, not a logical schematic — and it's drawn natively in Illustrator (FPD-Schematic-010.AI8), traced from the physical board. Whoever made this did exactly the kind of vector board-tracing I mentioned earlier — good reference for your own workflow.
Let me pull a closer look at a couple of regions to read the labels more precisely before I summarize.
Ran 2 commands, viewed a file
Ran 2 commands, viewed a file
That's a great find — a few important details jump out:
Two selectable crystal oscillators, switched by jumper:
One more oddity worth noting: the 51.270MHz can's date code reads "89-09" (i.e., ~1989), which is later than your stated 1986 design date — meaning this particular populated board is likely a later production revision or later-manufactured unit, not an original first-run 1986 board, even if the design itself dates to 1986. Worth keeping in mind if exact timing/component sourcing matters for your clone.
Let me look at the rest of the board — the DRAM/GAL logic block and the bus edge connector.
Ran a command, viewed a file
Ran a command, viewed a file
Good — this confirms and extends the picture. Here's a consolidated read of what your PDF actually documents:
Want me to redraw this as a clean block/signal-flow diagram (SVG/EPS, so you can pull it into Illustrator alongside your own tracing) showing the U6→U7→U5→U2→U3/U4 timing chain hypothesis? That'd give you something concrete to verify pin-by-pin against the real trace colors.
WTF layer is unconfirmed first shot at buzzing connections. "Nancy's" would be traces I entered while visiting my girlfriend. I've done all work on project.
Good context to have — that explains both naming quirks:
I'll wait for the layer PDFs whenever you've got them ready.
I will also upload high resolution photos of both sides of the board. Will also upload the "reversed" mirror imaged photo of the component side I use for reference. OCR of silk screen layer notations will likely be a good check against text input in what I call my "AI Coloring Books".
Recalled memory
This is turning into a substantial project — let me split it into its own area file so the details don't get lost, and keep your general working-style notes separate.
Created and edited memory
That's a smart cross-check — OCR'ing the silkscreen text gives you an independent verification pass against whatever you've manually typed into your traced layers, so any transcription slip (a "U13" mistyped as "U18," say) gets caught by comparing two independently-derived sources rather than trusting one read-through.
A few thoughts on what'll make this most useful once everything's uploaded:
Excellent, Reverse Engineering of the board is indeed its own project.
Makes sense — treating the PCB reverse engineering as its own project, separate from the signal-timing capture and scanline rotation transform work, keeps each piece scoped and easier to verify independently. The RE work you're doing now (layer PDFs, board photos, OCR cross-check) stands on its own as "figure out exactly what this board is and how it's wired," while the timing-capture and transform-spec work builds on top of that once the RE side is solid.
Happy to keep working with you on either thread as it comes in — just let me know which hat I should have on when you send the next batch of files.
How do I pull up either of the two projects for further work?
That depends on what you mean — here in this conversation, both threads (the RE work and the timing/transform work) are already live, so you can just say "back to the RE thread" or reference specific files and I'll pick up where we left off.
If you mean starting a fresh conversation later and picking either project back up: I keep notes across our conversations, so you can just say something like "let's continue the Radius FPD clone" or "pick up the PCB reverse engineering" and I'll pull up what I have on file — the board specs, the layer names and what they mean, your naming conventions ("WTF?" layer, "Nancy's" layer, "AI Coloring Books"), and the general state of things. You won't need to re-explain the whole backstory each time.
One caveat worth knowing: I don't retain the actual files you've uploaded (the PDFs, EPS, AI8, photos) between conversations — only the facts and context I've written down. So if a new conversation needs to reference the actual schematic content again, you'll need to re-upload the file, but you won't need to re-explain what it is or why it matters.
That's great 1. open claude app 2. input text to pull up either project Upload all currently active files for each session as they're not stored on your end.
That's exactly right:
______________________________________________________
Maybe make a new discussion specifically addressing the reverse engineering of the PCB
Saved memory
Saved memory
Good to know — that changes how I should hand you stuff. Since you're working visually in Illustrator (even v8, which is EPS/vector-native and predates a lot of "modern" export assumptions), let's lean into that for the PCB reverse-engineering work rather than dense prose or spreadsheets.
Concretely, that could mean:
- Board maps as layered vector tracings — you photograph/scan the PCB top and bottom, place them as templates in Illustrator, and trace: traces on one layer, vias on another, component footprints on another, silkscreen reference on another. Classic RE workflow, and Illustrator handles it fine even at v8 (just watch out for spot-color / RGB vs CMYK defaults if this ever needs to go anywhere color-accurate).
- Functional block diagrams — instead of a schematic-capture tool, you draw the high-level blocks (VRAM, timing generator/PAL, bus interface, DAC/line driver) as boxes-and-arrows in Illustrator, which is often clearer for communicating "what talks to what" than a formal schematic anyway.
- Timing diagrams — HSYNC/VSYNC/blanking/porch waveforms as literal vector line art, which is actually a very natural fit for Illustrator and easier to annotate precisely than most scope software's export.
Given that, want me to:
- Draft the functional block diagram for the FPD card as a first visual piece (I can generate this as SVG/EPS now, even before you have the real board in hand — based on what's typical for this era/type of card), or
- Hold off on visuals until you've got board photos to work from, and instead keep building out the written RE spec section?
Ran a command
Ran a command
I don't actually see a PDF in this conversation yet — the uploads folder is empty on my end. It looks like it didn't attach, so could you try uploading it again?
To answer your two questions directly:
Can I view a PDF? Yes — once it's actually attached, I can open it, view pages as images, and comment on your progress (layout, traces, whatever's in it).
Can you upload a native Illustrator 8 file (.AI)? This chat interface accepts uploads, but heads up on what I can actually do with it:
- Old-format .ai files (v8 era) are essentially PostScript/EPS-flavored — I can inspect the file as text/binary and often extract path/structure info via script, but I can't open it in Illustrator itself or guarantee a clean re-render the way viewing a PDF or image does.
- If you export a PDF from Illustrator 8 (or even just save as PDF-compatible, which v8 supports as an option), that gives me the most reliable way to actually see it visually, layers or not.
- If it's genuinely unlayered already, that's fine — I can still look at it as a flat image/PDF, I just won't be able to toggle pieces on/off the way I could with a layered file.
take a look at this:?
I don't see a file attached to this message — the upload didn't come through on my end. Could you try attaching it again? Once it lands, I'll take a look right away.
https://tinkerdifferent.com/attachments/fpd-schematic-010-pdf.30088/
Fetched: https://tinkerdifferent.com/attachments/fpd-schematic-010-pdf.30088/
Fetched: https://tinkerdifferent.com/attachments/fpd-schematic-010-pdf.30088/
That link resolved, but it came back as raw binary data rather than something I can render or read directly — my fetch tool can't parse PDF content from an arbitrary URL like that (I can only truly "see" a PDF if it's uploaded directly into this chat, where it gets processed properly).
A couple options:
- Download it and upload the file here — grab the PDF from that link yourself, then attach it directly to this chat. That'll let me actually view the pages/schematic.
- Tell me what's on it / describe key parts — if you just want to talk through what you're seeing (IC part numbers, crystal frequency, block layout), I can work from your description in the meantime.
How do I upload a file?
In this chat interface, there should be a paperclip / "+" attachment icon near the message input box (usually bottom-left or left of the text field, depending on whether you're on desktop or mobile). Tapping/clicking that opens a file picker where you can select the PDF from wherever you saved it on your device, and it'll attach to your next message.
Quick steps:
- Download the PDF from that tinkerdifferent.com link to your device (if you haven't already)
- In this chat, click the attachment icon next to where you type
- Select the downloaded PDF file
- Send the message — I'll be able to open and view it once it's attached that way
Once it's attached, go ahead and ask me to take a look and I'll dig into the schematic with you.
____________
Ran 4 commands, viewed a file
Ran 4 commands, viewed a file
I can see it now — and this is genuinely useful. A few things worth calling out:
This is a solder-side PCB trace/placement drawing, not a logical schematic — and it's drawn natively in Illustrator (FPD-Schematic-010.AI8), traced from the physical board. Whoever made this did exactly the kind of vector board-tracing I mentioned earlier — good reference for your own workflow.
Let me pull a closer look at a couple of regions to read the labels more precisely before I summarize.
Ran 2 commands, viewed a file
Ran 2 commands, viewed a file
That's a great find — a few important details jump out:
Two selectable crystal oscillators, switched by jumper:
- JP1 → 55.000 MHz (marked TOYOCOM, part-ish "8853 JAPAN", "197.0556")
- JP2 → 51.270 MHz (marked "EC 1100", date code "89-09")
One more oddity worth noting: the 51.270MHz can's date code reads "89-09" (i.e., ~1989), which is later than your stated 1986 design date — meaning this particular populated board is likely a later production revision or later-manufactured unit, not an original first-run 1986 board, even if the design itself dates to 1986. Worth keeping in mind if exact timing/component sourcing matters for your clone.
Let me look at the rest of the board — the DRAM/GAL logic block and the bus edge connector.
Ran a command, viewed a file
Ran a command, viewed a file
Good — this confirms and extends the picture. Here's a consolidated read of what your PDF actually documents:
What this drawing shows
A solder-side PCB trace + placement map (per the title block: "Viewpoint = Solder Side, Light Blue Traces on Component Side") — i.e., you're looking at the bottom copper layer with the top layer's traces overlaid in a different color for reference. This is a two-layer board.Component inventory (confirmed from the drawing)
| Ref | Part | Likely function |
|---|---|---|
| U13, U8, U17, U22 | GAL20V8-25LP | Programmable logic — sync/timing/address decode glue |
| U9 | GAL20V8-25LNC | Same family, different package/spec — another logic block |
| U18, U19 | ROM (unlabeled part #) | Likely boot/init code or a lookup table (possibly gamma/pattern ROM) |
| U16, U15(?), U12, U11(?) | µPD41264C-15 | 64K×4 DRAM, 150ns — this is your video framebuffer |
| U2 | SN74F109N | Dual JK flip-flop — likely divides/shapes a clock edge |
| U3, U4 | SN74F166N | 8-bit parallel-in/serial-out shift register — this is almost certainly your pixel serializer, shifting framebuffer words out to the video line at pixel-clock rate |
| U5 | SN74F161N | 4-bit binary counter — candidate for pixel/horizontal counter |
| U6, U7 | SN74LS393N | Dual 4-bit binary counter — candidates for horizontal/vertical timing counters |
| CR1–CR5, R1–R3 | Diodes/resistors near J1 | Likely output clamping/termination on the video line to the monitor cable |
Timing generation — this is the big one for your Section 1/2 work
You now have a real counter chain to reverse-engineer instead of guessing: U6/U7 (393N counters) → U5 (161N counter) → U2 (109N flip-flop) → U3/U4 (166N shift registers) is a very plausible signal path from "raw oscillator" down to "serialized pixel data," with the GALs almost certainly generating HSYNC/VSYNC/blanking from taps off that same counter chain. Tracing the actual pin-to-pin connections (the colored traces) through this chain would let you derive H-total/V-total, and therefore blanking/porch, without needing a scope — a nice independent cross-check against your planned analog capture.Dual clock domain
Confirmed two crystal oscillators (55.000MHz / 51.270MHz) jumper-selected — strongly consistent with the "64/68Hz" dual-mode naming, pending verification of whether the silkscreen really says Hz or K.Want me to redraw this as a clean block/signal-flow diagram (SVG/EPS, so you can pull it into Illustrator alongside your own tracing) showing the U6→U7→U5→U2→U3/U4 timing chain hypothesis? That'd give you something concrete to verify pin-by-pin against the real trace colors.
WTF layer is unconfirmed first shot at buzzing connections. "Nancy's" would be traces I entered while visiting my girlfriend. I've done all work on project.
Good context to have — that explains both naming quirks:
- "Address & WTF?" = your first-pass continuity-testing guesses, unconfirmed, kept separate so they don't get mistaken for verified traces.
- "Nancy's" = just a session label (traces you added while visiting your girlfriend), not a second contributor or a separate methodology — so it's fully part of your own confirmed work, just named for when you did it rather than what it contains.
I'll wait for the layer PDFs whenever you've got them ready.
I will also upload high resolution photos of both sides of the board. Will also upload the "reversed" mirror imaged photo of the component side I use for reference. OCR of silk screen layer notations will likely be a good check against text input in what I call my "AI Coloring Books".
Recalled memory
This is turning into a substantial project — let me split it into its own area file so the details don't get lost, and keep your general working-style notes separate.
Created and edited memory
That's a smart cross-check — OCR'ing the silkscreen text gives you an independent verification pass against whatever you've manually typed into your traced layers, so any transcription slip (a "U13" mistyped as "U18," say) gets caught by comparing two independently-derived sources rather than trusting one read-through.
A few thoughts on what'll make this most useful once everything's uploaded:
- Board photos (both sides): I can inspect these directly and cross-reference IC part numbers, silkscreen text, and physical trace paths against what your traced layers show.
- Mirrored component-side photo: Good call keeping this — component-side photos need mirroring to compare directly against a solder-side trace view (since you're looking through the board from opposite sides), so having it pre-flipped means we're comparing like-to-like without me having to mentally flip coordinates.
- OCR cross-check: Once I have the photos, I can attempt my own read of the silkscreen text directly from the images and compare it against whatever text layer/labels you've entered in the AI8 file — that's a good three-way check (your typed labels, your traced positions, and an independent visual read).
Excellent, Reverse Engineering of the board is indeed its own project.
Makes sense — treating the PCB reverse engineering as its own project, separate from the signal-timing capture and scanline rotation transform work, keeps each piece scoped and easier to verify independently. The RE work you're doing now (layer PDFs, board photos, OCR cross-check) stands on its own as "figure out exactly what this board is and how it's wired," while the timing-capture and transform-spec work builds on top of that once the RE side is solid.
Happy to keep working with you on either thread as it comes in — just let me know which hat I should have on when you send the next batch of files.
How do I pull up either of the two projects for further work?
That depends on what you mean — here in this conversation, both threads (the RE work and the timing/transform work) are already live, so you can just say "back to the RE thread" or reference specific files and I'll pick up where we left off.
If you mean starting a fresh conversation later and picking either project back up: I keep notes across our conversations, so you can just say something like "let's continue the Radius FPD clone" or "pick up the PCB reverse engineering" and I'll pull up what I have on file — the board specs, the layer names and what they mean, your naming conventions ("WTF?" layer, "Nancy's" layer, "AI Coloring Books"), and the general state of things. You won't need to re-explain the whole backstory each time.
One caveat worth knowing: I don't retain the actual files you've uploaded (the PDFs, EPS, AI8, photos) between conversations — only the facts and context I've written down. So if a new conversation needs to reference the actual schematic content again, you'll need to re-upload the file, but you won't need to re-explain what it is or why it matters.
That's great 1. open claude app 2. input text to pull up either project Upload all currently active files for each session as they're not stored on your end.
That's exactly right:
- Open the Claude app, start a new conversation
- Say something like "pick up the Radius FPD clone" or "continue the PCB reverse engineering project" — I'll pull up what I have on file (specs, layer naming conventions, project status) automatically
- Re-upload whatever files are relevant to that session (schematic PDFs, photos, layer exports) since those don't persist between conversations — only the notes about them do
I started from the board connector to the VRAM ICs. First notion was to interface there in order to capture frame buffer, eliminating much of the upper section of the card. Found out that was too complicated for me to do so changed course. Will begin at the output cable header and work my way back to where we can identify where to tap the TTL Feed.
Thought for 8s
Thought for 8s
That's a sound pivot, and it actually lines up well with what we found in the schematic. Tapping at the VRAM ICs would have meant reconstructing address/timing logic just to make sense of raw pixel data mid-stream — a lot of complexity for not much payoff. Working backward from J1 instead means you're chasing a signal that's already been serialized and (mostly) cleaned up by the time it gets there.
A few things worth keeping in mind as you trace back from the connector:
Thought for 8s
Thought for 8s
That's a sound pivot, and it actually lines up well with what we found in the schematic. Tapping at the VRAM ICs would have meant reconstructing address/timing logic just to make sense of raw pixel data mid-stream — a lot of complexity for not much payoff. Working backward from J1 instead means you're chasing a signal that's already been serialized and (mostly) cleaned up by the time it gets there.
A few things worth keeping in mind as you trace back from the connector:
- U3 and U4 (the SN74F166N parallel-in/serial-out shift registers) we spotted earlier are strong candidates for exactly the stage you're looking for — they'd take parallel framebuffer words and shift them out serially, which is the natural "last digital stage before going analog/TTL-out" point. If tracing backward from J1 lands you at their outputs, that's a good sign you've found the right tap point.
- Just past that shift-register output is likely where CR1–CR5 (diodes) and R1–R3 (resistors) sit — the little cluster near J1 we saw on the board. Those are probably clamping/line-driving components between the clean digital TTL signal and whatever the monitor cable actually carries. You'll want to identify whether your tap point is before or after that cluster — before it should still be clean TTL logic levels; after it may already be shaped for the cable/monitor and less friendly to a logic analyzer.
- Don't forget HSYNC and VSYNC need separate identification alongside the serial pixel data — J1 almost certainly carries at least 3 signals (pixel data, HSYNC, VSYNC), possibly more depending on whether blanking is broken out separately.
Yep! It's wonderful to have a Reverse Engineering Partner who understands my "AI Coloring Books!"
edit: I usually wind up talking to myself in these kinds of threads. I'm running the play by play from Claude Code sessions. Thinking others might be interested in watching the progress and some folks digging down into Claude's interpretation of and expansion upon my progress.
Last edited: