vwemirror/TeslaRel410
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

BT410 5.3.133: the brownout that never was -- a percent stored 1:1 had every watcher in the mech crying undervoltage on a full bus

Browse Source 
The question left open by 5.3.132 turned out to be neither of the causes
being weighed.  One diagnostic line printed the whole comparison:

  'Gyroscope' watched='Avionics' level=4 minVoltage=50
              measured=10000 rated=10000 brownout=1

The bus is Ready and at FULL rated voltage, so there was never a real
brownout.  The trip value was 50, and the test measured <= minVoltage *
rated reads 10000 <= 50 * 10000 -- true for any voltage at all.

The field is named minVoltagePercent.  It is a percent, and we stored it
1:1; our own comment had flagged the missing scale as "a tuning value
(stored 1:1 here until located)".  The authored data admits no other
reading -- bhk1 gives the Gyroscope and HUD 50 and the Searchlight 10,
round percents and absurd as raw fractions.  Divided by 100 the gyro
trips below 5000V of a 10000V bus, and the Searchlight tolerates far
more sag before complaining, which is the right ordering for a light
versus a gyro.

The whole chain is now verified live in a single run: watcher bound ->
watchdog reads its target's real state (4, Ready) -> impaired false for
the entire run (31 samples, none impaired) -> the gyro sways on
percentageOnNormal instead of its destruction-grade base.  Zero faults.

Provenance recorded honestly in the notes: the binary's scale SITE was
not located in code, so the /100 is inferred from the field name plus
unambiguous authored data, not claimed as a byte-verified decode.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-08-10 09:04:59 -05:00
co-authored by Claude Fable 5
parent 453fa0ecee
commit b1e9a09a6e
4 changed files with 242 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
emulator/render-bridge/pod_render_both.conf
+88
View File
@@ -0,0 +1,88 @@
# pod_render_norio.conf -- pod_render_rec with the RIO serial port OFF.
#
# The emulator log shows a steady stream of serial1 RX OVERRUN errors on
# the RIO pipe, and controls post their events at HighEventPriority
# UNCONDITIONALLY (CONTROLS.HPP:250) -- so a chattering RIO port would
# flood a priority the background pump always serves first, starving the
# priority-0 renderer events the load gate waits on. This conf tests that
# by removing the port entirely. Everything else is identical to the rec
# conf, so a launch here and a hang there isolates the RIO.
#
[sdl]
output=opengl
# higher,higher not highest: HIGH_PRIORITY_CLASS starved the host desktop;
# with the retry patches a rare dropout self-recovers (see gauge_rio.conf).
priority=higher,higher
[dosbox]
memsize=32
machine=svga_s3
[cpu]
core=dynamic
cputype=pentium
cycles=max
[sblaster]
sbtype=sb16
sbbase=220
irq=5
dma=1
hdma=5
[mixer]
# match the EMU8000s' native rate (no resample) and buffer ~60ms so brief
# emulation-thread stalls (RIO retry recovery) don't audibly chop
rate=44100
blocksize=1024
prebuffer=60
[serial]
# RIO on COM1 with the low-latency options (rxpollus/rxburst) so the board's
# few-ms ACK deadline is met; plasma display on COM2 (real pod has both).
# VWE fork namedpipe backend (com0com/realport retired -- COM1/COM2 gone):
# DOSBox = pipe client (retry), vRIO/vPLASMA apps = servers; an unconnected
# pipe behaves as an unplugged cable so the mission still runs. serialnamedpipe.h
serial1=disabled
serial2=namedpipe pipe:vplasma
# live UNBUFFERED game output: DOS char devices are not buffered, so
# redirecting stdout to COM3 lands every line immediately. A normal
# '> file' redirect stays 0 bytes until the process exits, which hides
# all progress on a run that does NOT crash.
serial3=file file:C:\VWE\TeslaRel410\emulator\render-bridge\podlog.txt
[autoexec]
mount c "C:\VWE\TeslaRel410\ALPHA_1"
c:
cd \REL410\BT
set VIDEOFORMAT=svga
rem production pod card init (PARAMETR.BAT:181-186): DIAGNOSE + AWEUTIL per
rem card -- AWEUTIL /S does the EMU8000 bring-up and DRAM detect the HMI SOS
rem driver relies on; skipping it left the cards uninitialized (silent).
rem aweutil /s SKIPPED for now: it verifies the AWE32 GM ROM, which the
rem emulated cards lack (hangs in a retry loop) -- restore once the ROM is
rem dumped from a real card. diagnose /s kept (passes, sets mixer config).
set BLASTER=A220 I5 D1 H5 P330 T6
c:\sb16\diagnose /s
set BLASTER=A240 I7 D3 H6 P300 T6
c:\sb16\diagnose /s
set BLASTER=A220 I5 D1 H5 P330 T6
set TEMP=c:\
rem arena1 city mission (TESTARN.EGG: map=arena1, time=day) with the RIO
rem attached; stdout redirected so mission-load progress survives kills.
set BT_JOINTS=1
set L4VIEWEXT=1
set BT_STACK_LOG=1
set BT_MECH_LOG=1
set BT_SUPERSTOP_SOAK=1
set BT_WATCH_LOG=1
set BT_SWAY_LOG=1
set BT_GAUGE_LOG=1
set BT_FORCE_TURN=0
set HEAPSIZE=15000000
set L4GAUGE=640x480x16
call setenv.bat r s n p
32rtm.exe -x
BTL4REC.EXE -egg testarn.egg > COM3
echo GAME-RC=%errorlevel% >> RC.TXT
32rtm.exe -u
echo ALPHA1-RUN-DONE
pause
emulator/render-bridge/pod_render_watch.conf
+87
View File
@@ -0,0 +1,87 @@
# pod_render_norio.conf -- pod_render_rec with the RIO serial port OFF.
#
# The emulator log shows a steady stream of serial1 RX OVERRUN errors on
# the RIO pipe, and controls post their events at HighEventPriority
# UNCONDITIONALLY (CONTROLS.HPP:250) -- so a chattering RIO port would
# flood a priority the background pump always serves first, starving the
# priority-0 renderer events the load gate waits on. This conf tests that
# by removing the port entirely. Everything else is identical to the rec
# conf, so a launch here and a hang there isolates the RIO.
#
[sdl]
output=opengl
# higher,higher not highest: HIGH_PRIORITY_CLASS starved the host desktop;
# with the retry patches a rare dropout self-recovers (see gauge_rio.conf).
priority=higher,higher
[dosbox]
memsize=32
machine=svga_s3
[cpu]
core=dynamic
cputype=pentium
cycles=max
[sblaster]
sbtype=sb16
sbbase=220
irq=5
dma=1
hdma=5
[mixer]
# match the EMU8000s' native rate (no resample) and buffer ~60ms so brief
# emulation-thread stalls (RIO retry recovery) don't audibly chop
rate=44100
blocksize=1024
prebuffer=60
[serial]
# RIO on COM1 with the low-latency options (rxpollus/rxburst) so the board's
# few-ms ACK deadline is met; plasma display on COM2 (real pod has both).
# VWE fork namedpipe backend (com0com/realport retired -- COM1/COM2 gone):
# DOSBox = pipe client (retry), vRIO/vPLASMA apps = servers; an unconnected
# pipe behaves as an unplugged cable so the mission still runs. serialnamedpipe.h
serial1=disabled
serial2=namedpipe pipe:vplasma
# live UNBUFFERED game output: DOS char devices are not buffered, so
# redirecting stdout to COM3 lands every line immediately. A normal
# '> file' redirect stays 0 bytes until the process exits, which hides
# all progress on a run that does NOT crash.
serial3=file file:C:\VWE\TeslaRel410\emulator\render-bridge\podlog.txt
[autoexec]
mount c "C:\VWE\TeslaRel410\ALPHA_1"
c:
cd \REL410\BT
set VIDEOFORMAT=svga
rem production pod card init (PARAMETR.BAT:181-186): DIAGNOSE + AWEUTIL per
rem card -- AWEUTIL /S does the EMU8000 bring-up and DRAM detect the HMI SOS
rem driver relies on; skipping it left the cards uninitialized (silent).
rem aweutil /s SKIPPED for now: it verifies the AWE32 GM ROM, which the
rem emulated cards lack (hangs in a retry loop) -- restore once the ROM is
rem dumped from a real card. diagnose /s kept (passes, sets mixer config).
set BLASTER=A220 I5 D1 H5 P330 T6
c:\sb16\diagnose /s
set BLASTER=A240 I7 D3 H6 P300 T6
c:\sb16\diagnose /s
set BLASTER=A220 I5 D1 H5 P330 T6
set TEMP=c:\
rem arena1 city mission (TESTARN.EGG: map=arena1, time=day) with the RIO
rem attached; stdout redirected so mission-load progress survives kills.
set BT_JOINTS=1
set L4VIEWEXT=1
set BT_STACK_LOG=1
set BT_MECH_LOG=1
set BT_SUPERSTOP_SOAK=1
set BT_WATCH_LOG=1
set BT_GAUGE_LOG=1
set BT_FORCE_TURN=0
set HEAPSIZE=15000000
set L4GAUGE=640x480x16
call setenv.bat r s n p
32rtm.exe -x
BTL4REC.EXE -egg testarn.egg > COM3
echo GAME-RC=%errorlevel% >> RC.TXT
32rtm.exe -u
echo ALPHA1-RUN-DONE
pause
restoration/source410/BT/MECH4.NOTES.md
+34
View File
@@ -557,3 +557,37 @@ these watchers, or is the reconstructed generator genuinely sitting at the
brownout threshold? Log the watched level and the measured/rated pair
side by side to separate them -- do not adjust a threshold to make an
alarm quiet.
## 5.3.133 -- THE BROWNOUT WAS A UNIT BUG (chain closed end to end)
The question posed in 5.3.132 is answered, and it was neither of the
guesses being weighed -- it was arithmetic. `BT_WATCH_LOG` printed the
whole comparison in one line:
'Gyroscope' watched='Avionics' level=4 minVoltage=50
measured=10000 rated=10000 brownout=1
Every term is legible there. The bus is READY and at FULL rated voltage
(10000 of 10000) -- so there was never a real brownout. The trip value
was 50, and the test `measured <= minVoltage * rated` reads
`10000 <= 50 * 10000`, which is true for any voltage whatsoever.
The field is called `minVoltagePercent`. It is a PERCENT, and we stored
it 1:1 -- our own comment had flagged the missing scale as "a tuning
value (stored 1:1 here until located)". The authored data admits no
other reading: bhk1 gives the Gyroscope and HUD 50 and the Searchlight
10, round percents that are absurd as raw fractions (5000% / 1000%).
Divided by 100 the gyro trips below 5000V of a 10000V bus, which is a
sane undervoltage threshold, and the Searchlight -- a light -- tolerates
far more sag before complaining, which is exactly the right ordering.
CHAIN NOW CLOSED, all four links verified live in one run:
watcher bound (5.3.132) -> watchdog reads the target's REAL state (4,
Ready) -> impaired FALSE for the entire run (31 samples, none impaired)
-> the gyro sways on `percentageOnNormal` instead of its
destruction-grade base.
NOTE ON PROVENANCE: the binary's own scale SITE was not located in code;
the /100 is inferred from the field name plus authored data that is
unambiguous. Recorded as such rather than claimed as a byte-verified
decode.
restoration/source410/BT/POWERSUB.CPP
+33 -6
View File
@@ -804,10 +804,19 @@ PowerWatcher::PowerWatcher(
Check(owner);
Check_Pointer(subsystem_resource);
//
// minVoltage is a scaled fraction of the watched supply; the exact scale
// constant is a tuning value (stored 1:1 here until located).
// THE SCALE, LOCATED (5.3.133). The field is a PERCENT, exactly as its
// name says, and storing it 1:1 made the brownout test
// `measured <= minVoltage * rated` unconditionally true -- so every
// PowerWatcher in the mech reported a permanent brownout on a bus
// sitting at full rated voltage.
//
minVoltage = subsystem_resource->minVoltagePercent;
// The authored data leaves no other reading: bhk1 gives the Gyroscope
// and HUD 50 and the Searchlight 10 -- round percents, absurd as raw
// fractions (5000% / 1000%) -- against a bus measuring 10000 of 10000
// rated. At 50% the gyro complains below 5000V, which is a sane
// undervoltage trip.
//
minVoltage = subsystem_resource->minVoltagePercent / 100.0f;
//
// Install the per-frame watchdog on the master instance.
//
@@ -889,14 +898,32 @@ void
Generator
*source = (Generator *)watched->ResolveVoltageSource();
if (
Logical brownout =
level == PoweredSubsystem::Ready &&
source != NULL &&
source->MeasuredVoltage() <= minVoltage * source->RatedVoltageOf()
)
source->MeasuredVoltage() <= minVoltage * source->RatedVoltageOf();
if (brownout)
{
watchdogAlarm.SetLevel(1); // the brownout
}
if (getenv("BT_WATCH_LOG"))
{
static int s_shown = 0;
if (s_shown < 24)
{
++s_shown;
DEBUG_STREAM << "[watchdog] '" << GetName()
<< "' watched='" << watched->GetName()
<< "' level=" << level
<< " minVoltage=" << minVoltage
<< " measured="
<< ((source != NULL) ? source->MeasuredVoltage() : -1.0f)
<< " rated="
<< ((source != NULL) ? source->RatedVoltageOf() : -1.0f)
<< " brownout=" << (int)brownout << endl << flush;
}
}
}
void