aiden/Sony-rcp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

pcb

Browse Source
This commit is contained in:
Aiden
2026-05-13 23:11:50 +10:00
parent d4b5f4396e
commit 861b16118c
18 changed files with 1067 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
.gitattributes vendored
View File

@@ -1 +1,2 @@
*.pdf filter=lfs diff=lfs merge=lfs -text *.pdf filter=lfs diff=lfs merge=lfs -text
.png filter=lfs diff=lfs merge=lfs -text

28
captures/rcp-he33-90-644030-with-heartbeat.txt Normal file
View File

@@ -0,0 +1,28 @@
Sequence probe: 7 frames x 1 group(s) on COM5 at 38400 8N1
FRAME 1: 00 00 90 00 80 4A
FRAME 2: 00 00 90 00 80 4A
FRAME 3: 00 00 64 40 30 0E
FRAME 4: 00 00 00 00 80 DA
FRAME 5: 00 00 64 40 30 0E
FRAME 6: 00 00 00 00 80 DA
FRAME 7: 00 00 64 40 30 0E
BASELINE heartbeat-compatible RX: 6 bytes, offset 0, 1 frames + 0 bytes
BEGIN group 1/1
21:57:19.772 TX group=1 frame=1 len=006 00 00 90 00 80 4A
21:57:19.772 RX group=1 frame=1 no RX bytes
21:57:20.177 TX group=1 frame=2 len=006 00 00 90 00 80 4A
21:57:20.177 RX group=1 frame=2 ANOMALY 18 RX bytes; first mismatch at byte 6: got 07, heartbeat offset 0 expected 00
21:57:20.177 RX group=1 frame=2 raw 00 00 00 00 80 DA 07 80 64 40 30 C9 07 80 64 40 30 C9
21:57:20.613 TX group=1 frame=3 len=006 00 00 64 40 30 0E
21:57:20.613 RX group=1 frame=3 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 0 expected 00
21:57:20.613 RX group=1 frame=3 raw 07 80 64 40 30 C9 00 00 00 00 80 DA
21:57:21.047 TX group=1 frame=4 len=006 00 00 00 00 80 DA
21:57:21.047 RX group=1 frame=4 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:57:21.450 TX group=1 frame=5 len=006 00 00 64 40 30 0E
21:57:21.450 RX group=1 frame=5 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:57:21.854 TX group=1 frame=6 len=006 00 00 00 00 80 DA
21:57:21.854 RX group=1 frame=6 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:57:22.257 TX group=1 frame=7 len=006 00 00 64 40 30 0E
21:57:22.257 RX group=1 frame=7 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
GROUP 1 TAIL heartbeat-compatible RX: 54 bytes, offset 0, 9 frames + 0 bytes
Anomalies: 2

25
captures/rcp-he33-90-then-644030.txt Normal file
View File

@@ -0,0 +1,25 @@
Sequence probe: 6 frames x 1 group(s) on COM5 at 38400 8N1
FRAME 1: 00 00 90 00 80 4A
FRAME 2: 00 00 90 00 80 4A
FRAME 3: 00 00 64 40 30 0E
FRAME 4: 00 00 64 40 30 0E
FRAME 5: 00 00 64 40 30 0E
FRAME 6: 00 00 64 40 30 0E
BASELINE heartbeat-compatible RX: 6 bytes, offset 0, 1 frames + 0 bytes
BEGIN group 1/1
21:55:33.852 TX group=1 frame=1 len=006 00 00 90 00 80 4A
21:55:33.852 RX group=1 frame=1 no RX bytes
21:55:34.256 TX group=1 frame=2 len=006 00 00 90 00 80 4A
21:55:34.256 RX group=1 frame=2 ANOMALY 12 RX bytes; first mismatch at byte 6: got 07, heartbeat offset 0 expected 00
21:55:34.256 RX group=1 frame=2 raw 00 00 00 00 80 DA 07 80 64 40 30 C9
21:55:34.662 TX group=1 frame=3 len=006 00 00 64 40 30 0E
21:55:34.662 RX group=1 frame=3 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 0 expected 00
21:55:34.662 RX group=1 frame=3 raw 07 80 64 40 30 C9 00 00 00 00 80 DA
21:55:35.066 TX group=1 frame=4 len=006 00 00 64 40 30 0E
21:55:35.066 RX group=1 frame=4 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:55:35.500 TX group=1 frame=5 len=006 00 00 64 40 30 0E
21:55:35.500 RX group=1 frame=5 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:55:35.903 TX group=1 frame=6 len=006 00 00 64 40 30 0E
21:55:35.903 RX group=1 frame=6 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
GROUP 1 TAIL heartbeat-compatible RX: 48 bytes, offset 0, 8 frames + 0 bytes
Anomalies: 2

25
captures/rcp-he33-90-then-e44030.txt Normal file
View File

@@ -0,0 +1,25 @@
Sequence probe: 6 frames x 1 group(s) on COM5 at 38400 8N1
FRAME 1: 00 00 90 00 80 4A
FRAME 2: 00 00 90 00 80 4A
FRAME 3: 00 00 E4 40 30 8E
FRAME 4: 00 00 E4 40 30 8E
FRAME 5: 00 00 E4 40 30 8E
FRAME 6: 00 00 E4 40 30 8E
BASELINE heartbeat-compatible RX: 6 bytes, offset 0, 1 frames + 0 bytes
BEGIN group 1/1
21:55:54.727 TX group=1 frame=1 len=006 00 00 90 00 80 4A
21:55:54.727 RX group=1 frame=1 no RX bytes
21:55:55.130 TX group=1 frame=2 len=006 00 00 90 00 80 4A
21:55:55.130 RX group=1 frame=2 ANOMALY 12 RX bytes; first mismatch at byte 6: got 07, heartbeat offset 0 expected 00
21:55:55.130 RX group=1 frame=2 raw 00 00 00 00 80 DA 07 80 64 40 30 C9
21:55:55.565 TX group=1 frame=3 len=006 00 00 E4 40 30 8E
21:55:55.565 RX group=1 frame=3 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 0 expected 00
21:55:55.565 RX group=1 frame=3 raw 07 80 64 40 30 C9 00 00 00 00 80 DA
21:55:55.968 TX group=1 frame=4 len=006 00 00 E4 40 30 8E
21:55:55.968 RX group=1 frame=4 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:55:56.372 TX group=1 frame=5 len=006 00 00 E4 40 30 8E
21:55:56.372 RX group=1 frame=5 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:55:56.775 TX group=1 frame=6 len=006 00 00 E4 40 30 8E
21:55:56.775 RX group=1 frame=6 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
GROUP 1 TAIL heartbeat-compatible RX: 54 bytes, offset 0, 9 frames + 0 bytes
Anomalies: 2

27
captures/rcp-he33-a0-90-then-644030.txt Normal file
View File

@@ -0,0 +1,27 @@
Sequence probe: 7 frames x 1 group(s) on COM5 at 38400 8N1
FRAME 1: 00 00 A0 00 80 7A
FRAME 2: 00 00 90 00 80 4A
FRAME 3: 00 00 64 40 30 0E
FRAME 4: 00 00 64 40 30 0E
FRAME 5: 00 00 64 40 30 0E
FRAME 6: 00 00 00 00 80 DA
FRAME 7: 00 00 64 40 30 0E
BASELINE heartbeat-compatible RX: 6 bytes, offset 0, 1 frames + 0 bytes
BEGIN group 1/1
21:56:29.044 TX group=1 frame=1 len=006 00 00 A0 00 80 7A
21:56:29.044 RX group=1 frame=1 no RX bytes
21:56:29.448 TX group=1 frame=2 len=006 00 00 90 00 80 4A
21:56:29.448 RX group=1 frame=2 ANOMALY 6 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 3 expected 00
21:56:29.448 RX group=1 frame=2 raw 07 80 64 40 30 C9
21:56:29.853 TX group=1 frame=3 len=006 00 00 64 40 30 0E
21:56:29.853 RX group=1 frame=3 no RX bytes
21:56:30.255 TX group=1 frame=4 len=006 00 00 64 40 30 0E
21:56:30.255 RX group=1 frame=4 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:56:30.688 TX group=1 frame=5 len=006 00 00 64 40 30 0E
21:56:30.688 RX group=1 frame=5 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:56:31.092 TX group=1 frame=6 len=006 00 00 00 00 80 DA
21:56:31.092 RX group=1 frame=6 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:56:31.495 TX group=1 frame=7 len=006 00 00 64 40 30 0E
21:56:31.495 RX group=1 frame=7 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
GROUP 1 TAIL heartbeat-compatible RX: 48 bytes, offset 0, 8 frames + 0 bytes
Anomalies: 1

31
captures/rcp-he33-a0-af-then-0d04ab.txt Normal file
View File

@@ -0,0 +1,31 @@
Sequence probe: 7 frames x 1 group(s) on COM5 at 38400 8N1
FRAME 1: 00 00 A0 00 80 7A
FRAME 2: 00 00 AF 00 80 75
FRAME 3: 00 00 0D 04 AB F8
FRAME 4: 00 00 0D 04 AB F8
FRAME 5: 00 00 0D 04 AB F8
FRAME 6: 00 00 00 00 80 DA
FRAME 7: 00 00 0D 04 AB F8
BASELINE heartbeat-compatible RX: 6 bytes, offset 0, 1 frames + 0 bytes
BEGIN group 1/1
21:57:05.146 TX group=1 frame=1 len=006 00 00 A0 00 80 7A
21:57:05.146 RX group=1 frame=1 no RX bytes
21:57:05.557 TX group=1 frame=2 len=006 00 00 AF 00 80 75
21:57:05.557 RX group=1 frame=2 ANOMALY 18 RX bytes; first mismatch at byte 6: got 07, heartbeat offset 0 expected 00
21:57:05.557 RX group=1 frame=2 raw 00 00 00 00 80 DA 07 80 0D 04 AB 7F 07 80 0D 04 AB 7F
21:57:05.961 TX group=1 frame=3 len=006 00 00 0D 04 AB F8
21:57:05.961 RX group=1 frame=3 ANOMALY 6 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 3 expected 00
21:57:05.961 RX group=1 frame=3 raw 07 80 0D 04 AB 7F
21:57:06.394 TX group=1 frame=4 len=006 00 00 0D 04 AB F8
21:57:06.394 RX group=1 frame=4 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 3 expected 00
21:57:06.394 RX group=1 frame=4 raw 07 80 0D 04 AB 7F 07 80 0D 04 AB 7F
21:57:06.827 TX group=1 frame=5 len=006 00 00 0D 04 AB F8
21:57:06.827 RX group=1 frame=5 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 3 expected 00
21:57:06.827 RX group=1 frame=5 raw 07 80 0D 04 AB 7F 07 80 0D 04 AB 7F
21:57:07.231 TX group=1 frame=6 len=006 00 00 00 00 80 DA
21:57:07.231 RX group=1 frame=6 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 0 expected 00
21:57:07.231 RX group=1 frame=6 raw 07 80 0D 04 AB 7F 00 00 00 00 80 DA
21:57:07.635 TX group=1 frame=7 len=006 00 00 0D 04 AB F8
21:57:07.635 RX group=1 frame=7 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
GROUP 1 TAIL heartbeat-compatible RX: 42 bytes, offset 0, 7 frames + 0 bytes
Anomalies: 5

28
captures/rcp-he33-af-0d04eb-with-heartbeat.txt Normal file
View File

@@ -0,0 +1,28 @@
Sequence probe: 7 frames x 1 group(s) on COM5 at 38400 8N1
FRAME 1: 00 00 AF 00 80 75
FRAME 2: 00 00 AF 00 80 75
FRAME 3: 00 00 0D 04 EB B8
FRAME 4: 00 00 00 00 80 DA
FRAME 5: 00 00 0D 04 EB B8
FRAME 6: 00 00 00 00 80 DA
FRAME 7: 00 00 0D 04 EB B8
BASELINE heartbeat-compatible RX: 6 bytes, offset 0, 1 frames + 0 bytes
BEGIN group 1/1
21:57:34.136 TX group=1 frame=1 len=006 00 00 AF 00 80 75
21:57:34.136 RX group=1 frame=1 no RX bytes
21:57:34.539 TX group=1 frame=2 len=006 00 00 AF 00 80 75
21:57:34.539 RX group=1 frame=2 ANOMALY 12 RX bytes; first mismatch at byte 6: got 07, heartbeat offset 0 expected 00
21:57:34.539 RX group=1 frame=2 raw 00 00 00 00 80 DA 07 80 0D 04 AB 7F
21:57:34.945 TX group=1 frame=3 len=006 00 00 0D 04 EB B8
21:57:34.945 RX group=1 frame=3 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 0 expected 00
21:57:34.945 RX group=1 frame=3 raw 07 80 0D 04 AB 7F 00 00 00 00 80 DA
21:57:35.349 TX group=1 frame=4 len=006 00 00 00 00 80 DA
21:57:35.349 RX group=1 frame=4 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:57:35.782 TX group=1 frame=5 len=006 00 00 0D 04 EB B8
21:57:35.782 RX group=1 frame=5 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:57:36.185 TX group=1 frame=6 len=006 00 00 00 00 80 DA
21:57:36.185 RX group=1 frame=6 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:57:36.588 TX group=1 frame=7 len=006 00 00 0D 04 EB B8
21:57:36.588 RX group=1 frame=7 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
GROUP 1 TAIL heartbeat-compatible RX: 54 bytes, offset 0, 9 frames + 0 bytes
Anomalies: 2

25
captures/rcp-he33-af-then-0d04eb.txt Normal file
View File

@@ -0,0 +1,25 @@
Sequence probe: 6 frames x 1 group(s) on COM5 at 38400 8N1
FRAME 1: 00 00 AF 00 80 75
FRAME 2: 00 00 AF 00 80 75
FRAME 3: 00 00 0D 04 EB B8
FRAME 4: 00 00 0D 04 EB B8
FRAME 5: 00 00 0D 04 EB B8
FRAME 6: 00 00 0D 04 EB B8
BASELINE heartbeat-compatible RX: 6 bytes, offset 0, 1 frames + 0 bytes
BEGIN group 1/1
21:56:43.107 TX group=1 frame=1 len=006 00 00 AF 00 80 75
21:56:43.107 RX group=1 frame=1 no RX bytes
21:56:43.511 TX group=1 frame=2 len=006 00 00 AF 00 80 75
21:56:43.511 RX group=1 frame=2 ANOMALY 18 RX bytes; first mismatch at byte 6: got 07, heartbeat offset 0 expected 00
21:56:43.511 RX group=1 frame=2 raw 00 00 00 00 80 DA 07 80 0D 04 AB 7F 07 80 0D 04 AB 7F
21:56:43.916 TX group=1 frame=3 len=006 00 00 0D 04 EB B8
21:56:43.916 RX group=1 frame=3 ANOMALY 12 RX bytes; first mismatch at byte 0: got 07, heartbeat offset 0 expected 00
21:56:43.916 RX group=1 frame=3 raw 07 80 0D 04 AB 7F 00 00 00 00 80 DA
21:56:44.319 TX group=1 frame=4 len=006 00 00 0D 04 EB B8
21:56:44.319 RX group=1 frame=4 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:56:44.754 TX group=1 frame=5 len=006 00 00 0D 04 EB B8
21:56:44.754 RX group=1 frame=5 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
21:56:45.189 TX group=1 frame=6 len=006 00 00 0D 04 EB B8
21:56:45.189 RX group=1 frame=6 heartbeat-compatible RX: 12 bytes, offset 0, 2 frames + 0 bytes
GROUP 1 TAIL heartbeat-compatible RX: 54 bytes, offset 0, 9 frames + 0 bytes
Anomalies: 2

2
docs/README.md
View File

@@ -21,6 +21,8 @@ service information, diagrams, related devices, and compatibility notes.
- [PT2 State Map](pt2-state-map.md) - working protocol-state map showing current - [PT2 State Map](pt2-state-map.md) - working protocol-state map showing current
selector/context branches, downstream response families, and likely state selector/context branches, downstream response families, and likely state
transitions. transitions.
- [PCB Notes](pcb-notes.md) - board-level observations, identified components,
connector tracing leads, and hardware-side restoration notes.
## High-Value Starting Points ## High-Value Starting Points

254
docs/discovery-notes.md
View File

@@ -7686,6 +7686,260 @@ It may still require:
- a missing hardware/state signal on another wire - a missing hardware/state signal on another wire
- or a specific startup family we have touched indirectly but not yet maintained - or a specific startup family we have touched indirectly but not yet maintained
### HE33: Maintain The Startup-Beacon Families
Goal:
- Follow the strongest new HE32 clue directly.
- Treat the startup-beacon families as possible **maintained classes** rather
than merely one-shot opening responses.
Working idea:
- `90` and `AF` increasingly look like startup beacons or mode/class selectors.
- In HE32 we immediately switched from those beacon effects into `E8`/`EC` page
traffic.
- That may have been too eager.
- Instead, try:
- open `64 40 30 C9`, `E4 40 30 49`, `0D 04 AB 7F`, or `0D 04 EB 3F`
- then maintain **that class**
- and only optionally add heartbeat alongside it
What would count as a hit:
- the startup family reappears or stays reusable
- a new recurring non-heartbeat family appears later in the same run
- the panel visibly changes state
- `CONNECT NOT ACT` behavior changes while the maintained class is running
Checksums for host-shaped maintained-class frames:
- host `64 40 30` -> `00 00 64 40 30 0E`
- host `E4 40 30` -> `00 00 E4 40 30 8E`
- host `0D 04 AB` -> `00 00 0D 04 AB F8`
- host `0D 04 EB` -> `00 00 0D 04 EB B8`
#### HE33a: Repeated `90` beacon, then maintain `64 40 30`
Hypothesis:
- `64 40 30` may be the real maintained class after `90`, not an intermediate
page on the way to `E8`.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.5 --frame "00 00 90 00 80 4A" --frame "00 00 90 00 80 4A" --frame "00 00 64 40 30 0E" --frame "00 00 64 40 30 0E" --frame "00 00 64 40 30 0E" --frame "00 00 64 40 30 0E" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he33-90-then-644030.txt
```
#### HE33b: Repeated `90` beacon, then maintain `E4 40 30`
Hypothesis:
- The alternate `90` beacon branch may want `E4 40 30` as its maintained class.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.5 --frame "00 00 90 00 80 4A" --frame "00 00 90 00 80 4A" --frame "00 00 E4 40 30 8E" --frame "00 00 E4 40 30 8E" --frame "00 00 E4 40 30 8E" --frame "00 00 E4 40 30 8E" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he33-90-then-e44030.txt
```
#### HE33c: `A0 -> 90`, then maintain `64 40 30`
Hypothesis:
- `A0 -> 90` may be a more deterministic way to enter the `64 40 30` startup
family than bare repeated `90`.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.5 --frame "00 00 A0 00 80 7A" --frame "00 00 90 00 80 4A" --frame "00 00 64 40 30 0E" --frame "00 00 64 40 30 0E" --frame "00 00 64 40 30 0E" --frame "00 00 00 00 80 DA" --frame "00 00 64 40 30 0E" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he33-a0-90-then-644030.txt
```
#### HE33d: Repeated `AF` beacon, then maintain `0D 04 EB`
Hypothesis:
- The repeated-`AF` startup branch may want the `0D 04 EB` class maintained.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.5 --frame "00 00 AF 00 80 75" --frame "00 00 AF 00 80 75" --frame "00 00 0D 04 EB B8" --frame "00 00 0D 04 EB B8" --frame "00 00 0D 04 EB B8" --frame "00 00 0D 04 EB B8" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he33-af-then-0d04eb.txt
```
#### HE33e: `A0 -> AF`, then maintain `0D 04 AB`
Hypothesis:
- `A0 -> AF` may open a slightly different startup/status class than repeated
`AF`, and it may want `0D 04 AB` instead of `0D 04 EB`.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.5 --frame "00 00 A0 00 80 7A" --frame "00 00 AF 00 80 75" --frame "00 00 0D 04 AB F8" --frame "00 00 0D 04 AB F8" --frame "00 00 0D 04 AB F8" --frame "00 00 00 00 80 DA" --frame "00 00 0D 04 AB F8" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he33-a0-af-then-0d04ab.txt
```
#### HE33f: `90` startup family with heartbeat interleaved
Hypothesis:
- The maintained class may still need a low-rate host-presence heartbeat beside
it, even if the page-class itself is the important thing.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.5 --frame "00 00 90 00 80 4A" --frame "00 00 90 00 80 4A" --frame "00 00 64 40 30 0E" --frame "00 00 00 00 80 DA" --frame "00 00 64 40 30 0E" --frame "00 00 00 00 80 DA" --frame "00 00 64 40 30 0E" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he33-90-644030-with-heartbeat.txt
```
#### HE33g: `AF` startup family with heartbeat interleaved
Hypothesis:
- Same logic as above, but for the `AF`-derived startup family.
```powershell
python scripts/serial_sequence_probe.py --port COM5 --prompt --prompt-screen --pre-read 0.5 --frame "00 00 AF 00 80 75" --frame "00 00 AF 00 80 75" --frame "00 00 0D 04 EB B8" --frame "00 00 00 00 80 DA" --frame "00 00 0D 04 EB B8" --frame "00 00 00 00 80 DA" --frame "00 00 0D 04 EB B8" --read-after-frame 0.15 --frame-interval 0.25 --read-after-group 3.0 --log captures/rcp-he33-af-0d04eb-with-heartbeat.txt
```
Recommended order:
1. `HE33a` repeated `90`, then `64 40 30`
2. `HE33c` `A0 -> 90`, then `64 40 30`
3. `HE33d` repeated `AF`, then `0D 04 EB`
4. `HE33e` `A0 -> AF`, then `0D 04 AB`
5. `HE33f` `90` family with heartbeat
6. `HE33g` `AF` family with heartbeat
7. `HE33b` repeated `90`, then `E4 40 30`
Reasoning:
- `64 40 30` looks like the strongest `90`-side startup family so far.
- `0D 04 AB/EB` is the matching `AF`-side family.
- The cleanest question first is simply:
can maintaining those classes do anything at all?
### HE33 Results
Practical outcome:
- No visible panel wake-up.
- No useful LCD change beyond the already familiar inactive behavior.
- Maintaining the startup-beacon families did **not** turn them into live
reusable session classes.
Serial outcome:
- The beacon families themselves are real and reproducible.
- But once opened, host-shaped maintenance of those same families mostly just
drained the initial one-shot response and then fell back to
heartbeat-compatible traffic.
#### HE33a: repeated `90`, then maintain `64 40 30`
Observed:
- second `90` produced:
- `07 80 64 40 30 C9`
- first host `64 40 30` produced one more:
- `07 80 64 40 30 C9`
- later host `64 40 30` frames were heartbeat-compatible only
Interpretation:
- `64 40 30` is a real startup-family surface.
- But simply maintaining host `64 40 30` does not keep that branch open.
#### HE33b: repeated `90`, then maintain `E4 40 30`
Observed:
- repeated `90` still opened:
- `07 80 64 40 30 C9`
- host `E4 40 30` did **not** pivot it into a stable `E4`-maintained state
- later traffic was heartbeat-compatible only
Interpretation:
- The `90` beacon can still prefer `64` on this run.
- Host `E4 40 30` did not make the alternate `E4` startup family reusable.
#### HE33c: `A0 -> 90`, then maintain `64 40 30`
Observed:
- `A0 -> 90` produced:
- `07 80 64 40 30 C9`
- later host `64 40 30` frames were heartbeat-compatible only
Interpretation:
- `A0 -> 90` is still a clean opener for the `64` family.
- But, again, the family did not become maintainable as a live background
class.
#### HE33d: repeated `AF`, then maintain `0D 04 EB`
Observed:
- repeated `AF` produced:
- `07 80 0D 04 AB 7F`
- `07 80 0D 04 AB 7F`
- first host `0D 04 EB` drained one more:
- `07 80 0D 04 AB 7F`
- later host `0D 04 EB` frames were heartbeat-compatible only
Interpretation:
- On this run, repeated `AF` did **not** prefer the older `EB`-suffixed
startup family; it stayed on the `AB` family instead.
- That makes the `AF` startup side look more slippery than the `90` side.
#### HE33e: `A0 -> AF`, then maintain `0D 04 AB`
Observed:
- `A0 -> AF` produced repeated:
- `07 80 0D 04 AB 7F`
- host `0D 04 AB` continued to drain more `AB` responses briefly
- then the run collapsed back to heartbeat-compatible traffic
Interpretation:
- `A0 -> AF` remains the cleanest opener for the `AB` startup family.
- It is stronger than the bare repeated-`AF` case, but still not enough to
create a sustained live session layer.
#### HE33f: `90` family with heartbeat interleaved
Observed:
- repeated `90` produced:
- `07 80 64 40 30 C9`
- `07 80 64 40 30 C9`
- host `64 40 30` plus heartbeat still fell back to heartbeat-compatible
traffic after that
Interpretation:
- Interleaving heartbeat did not make the `64` family maintainable.
#### HE33g: `AF` family with heartbeat interleaved
Observed:
- repeated `AF` produced:
- `07 80 0D 04 AB 7F`
- host `0D 04 EB` plus heartbeat did not reopen a live `EB`/`AB` maintained
branch
Interpretation:
- Heartbeat beside the `AF` startup family also did not help.
HE33 conclusion:
- The `90`/`AF` startup-beacon families are real, but they still behave like
one-shot startup surfaces rather than the missing maintained wake/session
stream.
- `90` is the cleaner side:
- it repeatedly lands on `64 40 30`
- `AF` is the sloppier side:
- it can land on `AB` or `EB`, and on this pass it mostly preferred `AB`
- Maintaining those family classes directly did not wake the panel, did not
make later traffic reusable, and did not create a stable active state.
### 2026-05-13 CAM POWER Context Retests ### 2026-05-13 CAM POWER Context Retests
Goal: Goal:

573
docs/pcb-notes.md Normal file
View File

@@ -0,0 +1,573 @@
# RCP-TX7 PCB Notes
These notes track direct physical observations from inside the Sony RCP-TX7.
They are intentionally separate from the PT2 protocol notes, because the board
layout and component choices may explain what the serial experiments alone do
not.
## Current Physical Overview
- The RCP appears to be split into **two circuit boards**.
- One board looks like a **front-panel / operator interface board**:
- button matrix
- lamps / indicators
- LCD support
- mostly resistors and small logic
- many TI `HC595A`-family or similar shift-register-style chips
- That board connects through an intermediate link to a second board.
- The second board appears to be the **main logic / controller board**:
- single-sided
- carries the main digital devices
- appears to contain the actual control logic / firmware for the RCP
## Connector / Wiring Observations
- The main logic board has an **8-pin connector** associated with the external
10-pin plug/cable assembly.
- The **wire colors inside the RCP do not match** the cable color mapping noted
earlier from the cable itself.
- This means:
- internal color cannot be trusted as a one-to-one continuation of external
cable color
- the board-side harness should be mapped by continuity, not by color
## Identified Components
Observed on the main logic board:
- `Sanyo LC3564BM-10`
- `XICOR X20C05J-55 9926`
- `27C512 RCPTX7 V1.05 SONY98`
- socketed / clip-retained
- appears user-replaceable
- additional marking observed: `0047K`
- `H8/536 HD`
- full observed line-by-line marking on the main controller:
- small logo resembling a target / concentric mark
- `H8/536`
- `1B1 A`
- `HD`
- `6435368F 16`
- `W34 JAPAN`
- several smaller TI logic ICs with varying markings
## Firmware Cluster Photo Notes
From the close-up photo of the firmware area:
- the firmware device is an **ST** `M27C512-10F1` family EPROM/OTP-style part
carrying the Sony application label:
- `27C512`
- `RCPTX7`
- `V1.05`
- `©SONY98`
- the package-side marking also shows:
- `M27C512`
- `10F1`
- `58826`
- `0047K`
- `SINGAPORE`
- the ROM is installed in a **socket**, which strongly supports the idea that
the firmware can be removed and dumped without desoldering
- the `XICOR X20C05J-55` sits immediately beside the firmware device
- the `LC3564BM-10` sits directly above the firmware area
This creates a very plausible classic memory cluster:
- EPROM = program storage
- SRAM = working memory
- Xicor NVRAM/EEPROM = retained setup/configuration data
## Silkscreen Clarifications From Photo
The close-up suggests a couple of earlier markings may need cautious reading:
- the vertical marking beside the ROM socket still looks like
`CNI12` / `CN112`-like text and should be rechecked carefully from the board
itself
- `RV1` appears near an **unpopulated footprint** below the ROM area
rather than clearly identifying the ROM itself
So, for now:
- treat `RV1` as a likely local board reference near that empty footprint
- do not treat `RV1` as the firmware module identifier
## Additional Photo-Backed Board Observations
From the newer board photos:
### Internal Harness Connector
- the internal board connector is silked as **`CN1`**
- it is an **8-pin connector**
- the visible wire colors at this connector appear to be:
- red
- brown
- white
- orange
- yellow
- gray
- blue
- black
- this reinforces the earlier point that the internal harness color order does
**not** match the earlier external cable-color assumptions
Useful implication:
- `CN1` is now the strongest candidate for the board-side harness/IO connector
that should be traced against the external 10-pin cable assembly
### H8 / DIP Area
- the H8 marking is now clearly readable in-package as:
- `H8/536`
- `HD`
- `6435368F16`
- `W34 JAPAN`
- the DIP switches `S2` and `S3` are clearly visible above the H8
- the switches show an `ON` legend on one side, which will help keep bit
numbering consistent during testing
- the pin-number silkscreen around the H8 is clearly printed, which supports
the earlier observation that the DIP banks land in the `43-50` region
### Likely `S1` Footprint
- one photo shows an **unpopulated circular-pad footprint** labeled `S1`
- this is important because it suggests:
- `S1` was not "missing from our search" by accident
- it may be an intentionally unpopulated switch or selector position on this
board revision
- Sony may have designed this PCB for multiple variants/options
This makes the earlier "no visible `S1`" mystery much less mysterious.
### Board / Assembly Markings
- one photo shows a boxed marking:
- `A-8315`
- `-095-A`
- there is also a small sticker:
- `2A1`
Working interpretation:
- `A-8315-095-A` is very likely a Sony board or assembly identifier
- `2A1` may be an inspection, revision, or production tracking sticker
### Additional Logic / Glue Area
- one of the smaller TI chips in the photo area is marked `HC74A`
- this is consistent with ordinary glue logic / state / timing support around
the CPU rather than with a second major processor
- nearby resistor-network and option-footprint areas also fit the picture of a
configurable CPU/control board with variant population options
## Additional Silkscreen / Board Markings
Observed so far:
- possible connector / reference markings:
- `RV1`
- `CNI12`
- near the `H8/536`:
- `CNI50`
- DIP switches:
- `S2`
- `S3`
- board label:
- `EP-(GW+GN)`
- large board text:
- `CPU-345`
- board appears visually split into quadrants
- the main custom Sony chip appears to sit in:
- `B-2`
## Initial Interpretation
These are working interpretations, not yet final identifications.
- `27C512 RCPTX7 V1.05 SONY98`
- very likely the panel firmware EPROM
- the `V1.05` label strongly suggests a firmware revision
- the socketed mounting is very useful for restoration and dumping
- `H8/536 HD`
- likely the main microcontroller or one of the main controllers
- especially likely given that the DIP switches reportedly connect to it
- the full observed marking is consistent with a Hitachi `HD6435368F`
H8-family MCU
- `X20C05`
- likely nonvolatile storage for configuration / calibration / retained setup
- `LC3564BM-10`
- likely RAM or working memory associated with the controller/firmware
- TI `HC595A`-style parts on the front board
- consistent with lamp, display, or scanned front-panel I/O expansion
Additional interpretation from the newer markings:
- `0047K` on the EPROM may be:
- an internal Sony build/program label
- a batch/date/option code
- or a board/personality identifier tied to this firmware image
- `CPU-345` strongly suggests this board is treated by Sony as a CPU/control
board assembly rather than only an interface board
- `B-2` may be a board-coordinate locator, which could help if a service manual
or board overlay ever turns up
- `CNI12` and `CNI50` both look more like connector/reference designators than
component values
- `RV1` is ambiguous:
- often that would imply a variable resistor / trim pot
- but if the silkscreen is hard to read, it is worth re-checking because it
may instead be another connector or reference prefix
- the `H8/536` line-by-line marking strongly suggests the main CPU is not a
Sony custom controller but a member of the Hitachi H8 family, with Sony
firmware and surrounding glue logic providing the product-specific behavior
- the `16` suffix likely indicates a speed grade / variant marker rather than a
board reference
- the `JAPAN` marking fits an original Japanese-manufactured MCU package
## Cross-Equipment Clue
- The RM-M7G reportedly contains a chip with the same target-like logo and
`JAPAN` marking from the same apparent manufacturer family.
Why this matters:
- the RCP-TX7 and RM-M7G may share a similar controller platform philosophy
- they may use related H8-family firmware architecture even if the surrounding
hardware and protocol behavior differ
- this strengthens the idea that DIP-config, ROM content, and NVRAM content may
matter as much as the raw serial traffic itself
## DIP Switches
- There are **two 4-position DIP switches**
- All switches are currently **off**
- One side of each DIP bank appears tied together
- They appear to act as **ground sinks / pull-to-ground configuration inputs**
- They reportedly connect to the `H8/536`
- The DIP switch reference designators are:
- `S2`
- `S3`
- Based on the silkscreen tracing, the DIP switches connect to
**pins 43 through 50**
This makes them likely candidates for:
- panel address / ID selection
- mode or personality selection
- service / factory configuration
- communication mode selection
Notable oddity:
- no obvious `S1` has been found yet
That could mean:
- `S1` exists on another board
- `S1` is an unpopulated option on this revision
- `S1` is present but hidden/obscured
- Sony numbering simply did not start at `S1` on this assembly
Why the `43-50` range matters:
- eight switch positions feeding a contiguous pin range is exactly what you
would expect for a boot-time configuration byte or bitfield
- that makes `S2` + `S3` look less like analog trims and more like true digital
mode/config inputs
- if those really are `H8/536` pins, they may be read very early at reset or
power-up
Current best interpretation of the DIP banks:
- together they likely form an **8-bit configuration field**
- likely uses pull-ups or default highs on the MCU side
- each switch probably pulls its line low when turned on
- possible meanings still include:
- panel address
- model/personality select
- PT mode / CCU compatibility mode
- service / factory behavior bits
- test/diagnostic mode
## Missing / Unpopulated Components
- Several components look **intentionally unpopulated**
For now, assume these may be:
- factory options
- alternate hardware revisions
- model-variant population differences
- unused test or expansion circuitry
They should not be treated as damaged/missing until compared against:
- both PCB sides
- silk labels
- any service-manual board drawing
- other RCP-TX7 board photos, if found later
The newer photos strengthen this:
- `S1` now appears to be an intentionally unpopulated footprint
- there are at least two additional unpopulated IC footprints in the same area
- this board very likely supported multiple build options or derivatives
## Why This Matters
This hardware picture is encouraging because it suggests the RCP is not just a
"dumb front panel."
It likely contains:
- a real MCU (`H8/536`)
- local firmware (`27C512`)
- nonvolatile memory (`X20C05`)
- a front-panel scan / display subsystem
That means the panel may have:
- multiple boot/configuration modes
- stored setup or address data
- more internal state than the serial experiments alone reveal
It also makes a **firmware dump** or **DIP-switch mapping** potentially very
high-value later.
## Next Hardware Inspection Targets
Highest-value things to map next:
1. Exact full part markings on the `H8/536` package
2. Exact full part markings on the `LC3564BM-10`
3. Exact full part markings on each smaller TI logic IC near the I/O connector
4. Continuity from the external 10-pin pins to the main-board connector pins
- especially through `CN1`
5. Continuity from the serial pins (`4`, `7`, `9`, `10`) to their destination
chips/components
6. Whether any of the remaining wires land on:
- MCU GPIO
- analog conditioning
- optocouplers
- comparator/op-amp circuitry
- transceiver/interface ICs
7. Silk labels near the two DIP switch blocks
- including the exact orientation of the `ON` legend on `S2` and `S3`
8. Any test pads labeled for:
- `TX`
- `RX`
- `CLK`
- `DATA`
- `RST`
- `ROM`
- `RAM`
- `GND`
- `+5V`
- `+12V`
## Strong Next Leads
Based on the current findings, the best hardware-side leads are:
1. **Map the DIP switches**
- note silk labels
- test whether any switch changes startup behavior or serial responses
- specifically record the current `S2` / `S3` bit positions before touching
- if possible, determine whether the switches are read only at boot or also
during runtime
2. **Dump or at least photograph the EPROM label and socket area clearly**
- the socketed `27C512` is one of the most promising restoration clues
- include the `0047K` marking in the photo record
3. **Trace the 8-pin internal connector**
- identify which of those lines are serial, power, and "something else"
4. **Identify whether the 10-pin path includes a dedicated interface chip**
- if not, the extra lines may go directly into the MCU or surrounding logic
5. **Verify the likely connector references**
- confirm whether `CNI12` is the 8-pin internal cable header
- confirm whether `CNI50` refers to the H8 area, a nearby header, or another
assembly reference
- note that `CN1` is now the strongest observed silk for the internal
8-pin harness connector in the photos
6. **Compare the RM-M7G controller board if possible**
- look for the exact MCU family/part
- compare ROM / EEPROM / switch architecture
- note whether Sony reused the same CPU platform with different front-end
logic
## Open Questions
- Is the `H8/536` definitely the primary CPU, or is there another Sony custom
controller sharing that role?
- Is the socketed `27C512` the only firmware store?
- What exactly is stored in the `X20C05`?
- Do the DIP switches select mode, address, or board variant?
- Do `S2`/`S3` form a single boot configuration byte across MCU pins `43-50`?
- Do any of the non-serial wires carry required wake/session information?
- Is there a hardware reason the panel never fully leaves `CONNECT NOT ACT`
under our emulated PT2 traffic?
- What do `CPU-345`, `EP-(GW+GN)`, `CNI12`, and `CNI50` correspond to in Sony's
internal board naming?
- Is `A-8315-095-A` the specific board assembly number for this CPU board?
- Does the RM-M7G use the same H8-family controller and a similar ROM/NVRAM
arrangement?
## DIP Switch Experiment Ladder
Current known baseline:
- all 8 DIP positions are currently **off**
- switches are grouped as:
- `S2` = 4 positions
- `S3` = 4 positions
- together they likely feed MCU pins `43-50`
### Safety / Method
Use this method for every DIP test:
1. Photograph the current DIP positions before changing anything.
2. Change **one switch only**.
3. Reassemble only as much as needed for safe power-on.
4. Power up the panel.
5. Observe behavior **before connecting serial**.
6. Then run the normal serial baseline checks.
7. Power down fully before changing the next switch.
8. Return to the all-off baseline between non-adjacent tests.
Recommended observations for each run:
- LCD startup text
- whether the active light changes
- whether `CONNECT NOT ACT` appears, and when
- whether the idle heartbeat is still `00 00 00 00 80 DA`
- whether known probes still behave the same:
- `A0`
- `90`
- `AF`
- `E8`
- `EC`
- any new button behavior in idle state
- any change in baud-like behavior or complete silence
### Naming Convention
Use a simple notation in notes/logs:
- baseline = `S2=0000 S3=0000`
- example single change:
- `S2=1000 S3=0000`
- meaning only the first `S2` switch is changed from baseline
If the physical switch numbering is unclear, first label them visually as:
- `S2-1` .. `S2-4`
- `S3-1` .. `S3-4`
based on one fixed left-to-right or top-to-bottom convention, and stick to it.
### Phase 1: Single-Bit Sweep
Goal:
- find out whether any single DIP bit has an obvious effect on startup,
protocol, or front-panel behavior
Run these eight tests, always starting from all-off baseline:
1. `S2-1` on, all others off
2. `S2-2` on, all others off
3. `S2-3` on, all others off
4. `S2-4` on, all others off
5. `S3-1` on, all others off
6. `S3-2` on, all others off
7. `S3-3` on, all others off
8. `S3-4` on, all others off
For each test:
- power-cycle
- watch LCD/startup state
- check for idle heartbeat
- try one minimal probe set:
- idle listen
- `A0`
- `A0 -> 90`
- `A0 -> AF`
What would count as a hit:
- panel boots into a different visible mode
- panel no longer shows `CONNECT NOT ACT`
- heartbeat changes or disappears
- known startup families change:
- `64 40 30`
- `0D 04 AB`
- `0D 04 EB`
- `E4 40 30`
- buttons become active in idle
### Phase 2: Group Identity Test
Only do this after Phase 1.
Goal:
- see whether one whole DIP bank behaves like an address nibble or mode nibble
Run these four tests:
1. all `S2` on, `S3` all off
2. all `S2` off, all `S3` on
3. all `S2` on, all `S3` on
4. return to all off baseline and confirm behavior is restored
What this can reveal:
- one bank may control personality while the other controls address
- one bank may do nothing while the other changes the panel sharply
- all-on may expose service/test behavior that single-bit changes do not
### Phase 3: Follow-Up Only If A Bit Matters
If Phase 1 reveals a promising bit, branch carefully:
1. repeat that same switch setting twice to confirm reproducibility
2. test neighboring bits in the same bank
3. test that bit plus one neighboring bit
4. compare:
- startup text
- heartbeat
- `A0 -> 90`
- `A0 -> AF`
- `E8` / `EC` selector behavior
### Good First Serial Checks Per DIP Setting
Keep the serial side small at first.
Recommended order:
1. idle listen only
2. repeating heartbeat only
3. `A0`
4. `A0 -> 90`
5. `A0 -> AF`
Only if something changes meaningfully, then test:
- `E8`
- `E9`
- `EC`
- CALL synthetic trigger
### Strong Cautions
- Do not change multiple unknown DIP bits at once in the first pass.
- Do not assume "on" means logic high; it may actually pull the line low.
- Some switches may only be sampled at cold boot, not warm reset.
- A strange setting may stop normal serial output entirely; that is still a
useful result.
- If one setting produces a dramatically different boot state, stop and record
it before going wider.

14
docs/pt2-protocol-summary.md
View File

@@ -395,6 +395,20 @@ Current caution:
- That makes `90` and `AF` look increasingly like startup beacons or mode/class - That makes `90` and `AF` look increasingly like startup beacons or mode/class
selectors, but still not sufficient to activate the panel or make later page selectors, but still not sufficient to activate the panel or make later page
feeds become live. feeds become live.
- HE33 followed that clue directly by maintaining the startup-family classes
themselves instead of switching immediately to `E8` / `EC` page traffic.
- That still did not wake the panel.
- The `90` side remained the cleaner startup surface:
- repeated `90` or `A0 -> 90` reliably opened `07 80 64 40 30 C9`
- host maintenance of `64 40 30` then fell back to heartbeat-compatible
traffic
- The `AF` side remained sloppier:
- `A0 -> AF` cleanly opened `07 80 0D 04 AB 7F`
- repeated `AF` sometimes preferred `AB` rather than the earlier `EB` family
- host maintenance of `0D 04 AB` or `0D 04 EB` still did not create a live
maintained session class
- Interleaving heartbeat beside these startup-family maintenance frames also did
not help.
## What We Do Not Know ## What We Do Not Know

34
docs/pt2-state-map.md
View File

@@ -472,6 +472,40 @@ So, on the map, these now look like:
- separate from the later selector/page layer - separate from the later selector/page layer
- still not sufficient to produce full wake/session activation - still not sufficient to produce full wake/session activation
## HE33 Maintained Startup-Class Follow-Up
HE33 tested the next obvious question:
once a startup-beacon family opens, can the host maintain that same class as a
live background stream?
What happened:
- `90 -> 64 40 30` stayed real, but did not become maintainable
- `A0 -> 90 -> 64 40 30` behaved the same way
- `90 -> E4 40 30` did not pivot into a stable `E4`-maintained state
- `A0 -> AF -> 0D 04 AB` could briefly drain more `AB` responses, then fell
back to heartbeat
- repeated `AF` plus host `0D 04 EB` was slippery and often still returned the
`AB` family instead
- adding heartbeat beside these startup classes did not help
What this means on the map:
- the startup-beacon layer is probably **real but shallow**
- it can bias or open a startup family
- but those families still do not behave like the maintained session stream the
panel needs in order to wake fully
Refined startup-layer view:
| Startup opener | Family observed | Maintainable as a live class? |
| --- | --- | --- |
| repeated `90` | `07 80 64 40 30 C9` | no |
| `A0 -> 90` | `07 80 64 40 30 C9` | no |
| repeated `90` alternate branch | `07 80 E4 40 30 49` | not confirmed as maintainable |
| repeated `AF` | `07 80 0D 04 AB 7F` or `07 80 0D 04 EB 3F` | no |
| `A0 -> AF` | `07 80 0D 04 AB 7F` | no |
## Best Next Uses Of This Map ## Best Next Uses Of This Map
This map is meant to help us ask sharper questions, for example: This map is meant to help us ask sharper questions, for example:

BIN
images/image.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.4 MiB

BIN
images/image2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 582 KiB

BIN
images/image3.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 938 KiB

BIN
images/image4.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 814 KiB

BIN
images/image5.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 726 KiB