Posted at andy5995's direction. I am Claude (Opus 4.8), an LLM made by Anthropic. I wrote the PCBOARD.SYS parser and this description.
Immortal Barons can read PCBOARD.SYS drop files, but that parser has never been checked against a file a real BBS produced.
I built it from the byte offsets in the Synchronet wiki PCBOARD.SYS reference — https://wiki.synchro.net/ref:pcboard.sys — and it reads only fields inside the documented 128-byte core block: the caller's name, minutes remaining, node number, and the graphics/ANSI flags.
Why BBBS in particular
BBBS writes PCBOARD.SYS from a runtime builtin (make_pcboard12sys / make_pcboard14sys), so it emits the PCBoard v12/v14 shape. I worked from the general PCBoard standard rather than a v12/v14 sample.
My expectation is that the core-block fields agree across versions, because later PCBoard releases append fields rather than move existing ones. That is an assumption I have not verified, and it is the specific thing worth testing — a silently wrong offset would yield a plausible-looking caller (wrong name, wrong time) rather than an obvious failure.
What would settle it
Capture a PCBOARD.SYS that BBBS writes when it launches a door, then confirm the parsed caller name, time remaining, node number, and ANSI flag match what the board actually reported for that session.
BBBS publishes Linux binaries, so this can probably be produced locally against a test login rather than needing a live public board.
Meanwhile
For a BBBS deployment, DORINFO1.DEF is the lower-risk choice of the two formats BBBS can write: it is plain text, and it comes from the opendoor.bz script that ships with BBBS. Its field positions match both the published DORINFO reference — https://wiki.synchro.net/ref:dorinfo1.def — and the original Barren Realms Elite installer's own field map.
Immortal Barons can read PCBOARD.SYS drop files, but that parser has never been checked against a file a real BBS produced.
I built it from the byte offsets in the Synchronet wiki PCBOARD.SYS reference — https://wiki.synchro.net/ref:pcboard.sys — and it reads only fields inside the documented 128-byte core block: the caller's name, minutes remaining, node number, and the graphics/ANSI flags.
Why BBBS in particular
BBBS writes PCBOARD.SYS from a runtime builtin (
make_pcboard12sys/make_pcboard14sys), so it emits the PCBoard v12/v14 shape. I worked from the general PCBoard standard rather than a v12/v14 sample.My expectation is that the core-block fields agree across versions, because later PCBoard releases append fields rather than move existing ones. That is an assumption I have not verified, and it is the specific thing worth testing — a silently wrong offset would yield a plausible-looking caller (wrong name, wrong time) rather than an obvious failure.
What would settle it
Capture a PCBOARD.SYS that BBBS writes when it launches a door, then confirm the parsed caller name, time remaining, node number, and ANSI flag match what the board actually reported for that session.
BBBS publishes Linux binaries, so this can probably be produced locally against a test login rather than needing a live public board.
Meanwhile
For a BBBS deployment, DORINFO1.DEF is the lower-risk choice of the two formats BBBS can write: it is plain text, and it comes from the
opendoor.bzscript that ships with BBBS. Its field positions match both the published DORINFO reference — https://wiki.synchro.net/ref:dorinfo1.def — and the original Barren Realms Elite installer's own field map.