mirror of
https://git.k-space.ee/arti/vt1200.git
synced 2026-10-30 12:03:54 +02:00
7.2 KiB
7.2 KiB
VT1200 firmware — address-space map (spike, 2026-10-16)
What external memory/register space the v2.2 firmware actually touches, derived by sweeping every scalar operand in the disassembled image plus the raw ROM images, and cross-checked against the MAME harness.
Conventions (read this first)
- The TMS34010 is bit-addressed. The firmware stores bit addresses.
A physical byte address is
bit >> 3; Ghidra byte address =0x07E40000 + file_offset. - This document gives bit addresses (the value the firmware actually stores) and,
in parentheses, the byte address (
bit>>3). - "harness unit" (the MAME driver's
BOARD_BASEand the access-log address) =bit >> 4= 2 bytes per unit. The four known windows are written0x5800000(bit) here, which is the driver's0x5800000too (leading-zero identical) — but the log prints them as0x0580000Dstyle (bit>>4). Do not mix the two. - Evidence codes: CONST = scalar-operand count from the Ghidra sweep (96,801
instructions / 1,177 distinct
@-targets); XREF = string/reference cross-check; LOG =harness/mame/board-4w.log/board-access.log; SG = service guide. - "Driver?" = does
harness/mame/vt1200.cppcurrently map it.
Region table
| # | bit range | byte range | what | evidence | driver? | conf. |
|---|---|---|---|---|---|---|
| 1 | 0x0000000–0x2000000 |
0x000000–0x400000 |
Main RAM 4 MiB | mem-test at 0x07EDFF22 walks SIMM regions at bit 0x800000/0x1000000… (byte 1 MiB/2 MiB); ~5 000 absolute globals; POST clears RAM; SG: 1 MiB onboard + 3×1 MiB SIMM |
yes (bit 0–0x1FFFFFF) |
HIGH |
| 2 | 0xC0000000–0xC00001FF |
(on-chip) | CPU on-chip registers (DPYCTL/DPYSTRT/DPYADR/CONTROL/…) | datasheet + MEMORY_MAP.md; 72 absolute operands |
internal | HIGH |
| 3 | 0x5000000 |
0xA00000 |
Memory-config / SIMM-presence input port. bits 0,1,2 = "SIMM 1/2/3 installed" | CONST 3 @ reads; XREF: 0x07E58FB2/0x07E58FCE/0x07E58FEA read bits 0/1/2 then print Not Present/SIMM n installed (strings @ file 0x0199BD…); also read at 0x07EDFF22 |
no | HIGH |
| 4 | 0x5600000 |
0xAC0000 |
Unidentified board register block — most-touched unmodelled region. Offsets +0x00 +0x10 +0x20 +0x30 +0x80 +0x100 +0x200 +0x380 |
CONST 110 @ accesses (2nd only to RAM/the known windows); writer at 0x07E6CB62, adjacent to X-server strings (no screens found) |
no | HIGH region / LOW identity |
| 5 | 0x5800000 |
0xB00000 |
DMA/board data port | CONST 10 @; LOG; paired with #6; firmware >>3s a bit address into it (byte-addressed device) |
yes | HIGH |
| 6 | 0x5900000 |
0xB20000 |
DMA/board command port | CONST 6 @; LOG (commands 0,1,2,4,0x42) |
yes | HIGH |
| 7 | 0x6000000 |
0xC00000 |
Candidate NVRAM. ~2 KiB user-settings copy writes here; sits in a 256 KiB device slot between #6 and #8 | CONST 2 (0x07E957F4, 0x07E95974 push it as the destination of a settings copy/metadata routine 0x07E966D0); XREF: adjacent Old user settings layout. / User settings invalid. |
no | MEDIUM-LOW |
| 8 | 0x6200000 |
0xC40000 |
Board window (STATUS +0x10, CMD +0x20, config +0xD0) |
CONST 26 @; LOG; BRINGUP_LOG.md |
yes | HIGH |
| 9 | 0x6400000 |
0xC80000 |
Board window incl. monitor-selection switch (bits 4–6 of +0xD0) |
CONST 24 @; LOG; BRINGUP_LOG.md |
yes | HIGH |
| 10 | 0x6800000 |
0xD00000 |
Ethernet MAC-address ROM | CONST 2 (0x07E46112); the 6-iteration byte-read loop 0x07E4611E–0x07E4613A copies 6 bytes (a MAC) from this base; SG level-1 "Ethernet address ROM test" |
no | HIGH |
| 11 | 0x4000000 |
0x800000 |
VRAM / framebuffer — candidate only | MOVI 0x4000000,B4 at 0x07E40AB0 in the reset-bank video init (video_regs_init); the B file holds bitmap bases |
no | LOW |
Notes on rows 3–7 (the peripheral map is regular)
The byte addresses 0xA00000, 0xAC0000, 0xB00000, 0xB20000, 0xC00000,
0xC40000, 0xC80000, 0xD00000 look like a decoded device map with a ~256 KiB
slot at the top end (0xC00000, 0xC40000, 0xC80000, 0xD00000 are exactly
0x40000 apart). That regularity is circumstantial evidence for rows 7 and 10.
What was ruled out (candidates that are NOT regions)
These appear constantly as large 32-bit constants but are not addresses:
| value (bit) | file offsets | why it is not an address |
|---|---|---|
0x112A880, 0x2DC6C0, 0x5B8D80, 0x927C0, 0x281F90, 0x3600400, 0x4000500 |
reset/POST bank | DSJS delay-loop counters (gate 2 in BRINGUP_LOG.md) and per-monitor display-format constants selected by the monitor switch (0x07E4089E–0x07E4090A) |
0x800000, 0x1000000 |
0x07EDFF2C… |
RAM region boundaries used by the SIMM memory test (byte 1 MiB / 2 MiB), not devices |
0x4000000 (all but one) |
49 aligned hits | bit-26 mask OR/AND, not an address |
byte 0x600000–0x7E40000 "buckets" |
whole image | code bytes / data tables. A naive raw scan of every 32-bit word is ~25 % false positives. The 0x5000000/0x6000000 "cluster" in bank 6 is unaligned byte noise inside sparse tables — re-scanning 16-bit-aligned collapses it. |
What remains unknown (stated plainly)
- Exact VRAM base and size. The framebuffer is not accessed by any absolute operand
(the
@-sweep finds it nowhere), so it is addressed indirectly — via theB-register file and/or theDPYADR(0xC00001E0) register, both set at runtime from a RAM screen descriptor. Row 11 is the only static hint and is weak. It is also possible the video DRAM sits behind the0x5800000/0x5900000DMA pair rather than being CPU-visible. - Identity of row 4 (
0x5600000). Heavy, display-adjacent, but I could not name the device. - NVRAM extent / exact base (row 7), and whether the MAC ROM (row 10) is 16-bit-wide (the read loop advances 2 bytes per MAC byte).
- Extent of each I/O block — only point accesses are observed, so sizes are guessed from slot spacing.
How to reproduce
# operand sweep (Ghidra, session required):
# iterate listing.getInstructions(True); for each Scalar operand >= 0x10000 and < 0x40000000,
# bucket by (value>>3)>>16. Filter to "@0x<value>" operands for true memory accesses.
python3 tools/ptr_constants.py vt1200_v22.bin # ROM-pointer subset
# raw aligned scan: 32-bit LE words whose (value>>3) lands in the region of interest
Durable Ghidra annotations added (project ghidra/vt1200, program vt1200_v22.bin)
- Memory blocks (with comments) created at each region byte base:
VRAM_800000_CAND,IO_50_SIMM_MEMCFG,IO_56_BOARD_REG,IO_58_DMA_DATA,IO_59_DMA_CMD,IO_60_NVRAM_CAND,IO_62_WIN2,IO_64_WIN3,IO_68_MACROM. - Functions created/named:
video_regs_init,io5600000_screen_init,nvr_user_settings_validate,io_settings_copy_expand,io_settings_copy_linear,io_settings_restore,io5800_5900_init,io5800_status_read,keyboard_mouse_irq_handler,led_control_1/2. - PRE comments at the key access sites (MAC read, SIMM read,
0x5600000write, settings copy, SIMM mem-test, video init,B4=0x4000000). - Program saved. Function count 8 → 19; memory blocks 1 → 10.