diff --git a/emulator/render-bridge/pod_render_noskl.conf b/emulator/render-bridge/pod_render_noskl.conf new file mode 100644 index 00000000..02a180bf --- /dev/null +++ b/emulator/render-bridge/pod_render_noskl.conf @@ -0,0 +1,70 @@ +[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=namedpipe pipe:vrio rxpollus:100 rxburst:16 +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_NO_SKL=1 +set BT_FORCE_THROTTLE=0.6 +set BT_FORCE_TURN=0.25 +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 + diff --git a/emulator/render-bridge/podlog.txt b/emulator/render-bridge/podlog.txt index b292d40b..85966e9c 100644 --- a/emulator/render-bridge/podlog.txt +++ b/emulator/render-bridge/podlog.txt @@ -8,7 +8,6 @@ ColorMapperArmor warning: damage zone dz_lmissle not found ColorMapperArmor warning: damage zone dz_rmissle not found ColorMapperArmor warning: damage zone dz_ftorso not found ColorMapperArmor warning: damage zone dz_btorso not found -L4VIDEO.cpp wrong video resource type for object mad.skl BTL4Application::RunMissionMessageHandler Turning Plasma Score Display On BTL4Application::RunMissionMessageHandler diff --git a/emulator/render-bridge/podlog_shipped.txt b/emulator/render-bridge/podlog_shipped.txt index e271e4f8..edf1ca54 100644 --- a/emulator/render-bridge/podlog_shipped.txt +++ b/emulator/render-bridge/podlog_shipped.txt @@ -1,7 +1,7 @@ BattleTech v4.10 BTL4Application::BTL4Application GaugeInterpreter: undefined label 'Initialization' -MakeVehicleSystems hud=0x011503f0 +MakeVehicleSystems hud=0x01154164 Warning: damage zone 'dz_missle' not found! Warning: damage zone 'dz_missle' not found! Warning: damage zone 'dz_lmissle' not found! @@ -9,7 +9,9 @@ Warning: damage zone 'dz_rmissle' not found! Warning: damage zone 'dz_ftorso' not found! Warning: damage zone 'dz_btorso' not found! LBE4ControlsManager::Execute, lost RIO analog request -iThinkIRQIsOn =1, actual state =1, characters sent =713 +iThinkIRQIsOn =1, actual state =1, characters sent =62 +LBE4ControlsManager::Execute, lost RIO analog request +iThinkIRQIsOn =1, actual state =1, characters sent =687 BTL4Application::RunMissionMessageHandler Turning Plasma Score Display On BTL4Application::RunMissionMessageHandler diff --git a/restoration/source410/BT_L4/BTL4VID.CPP b/restoration/source410/BT_L4/BTL4VID.CPP index 58c2acaf..5b056402 100644 --- a/restoration/source410/BT_L4/BTL4VID.CPP +++ b/restoration/source410/BT_L4/BTL4VID.CPP @@ -159,6 +159,12 @@ dpl_DCS * << " -> " << node_count << " nodes, " << object_count << " objects\n" << flush; + // + // The engine guards this the same way (L4VIDEO.CPP, DPLReadEnvironment): + // ~NotationFile REWRITES the file when dirtyFlag is set, and these are + // the game's shipped .SKL data files. + // + Verify(!skeleton->IsDirty()); Unregister_Object(skeleton); delete skeleton; return root; @@ -388,6 +394,16 @@ void Logical handled = False; + // + // BT_NO_SKL skips the skeleton build so the SAME binary can be + // run with and without it -- the only way to attribute the + // intermittent pod crash without a rebuild between samples. + // + if (getenv("BT_NO_SKL") != NULL) + { + break; + } + Entity_Being_Created = entity; video_iterator.First(); while ((video_wrapper = video_iterator.ReadAndNext()) != NULL) diff --git a/restoration/source410/RENDER-ROADMAP.NOTES.md b/restoration/source410/RENDER-ROADMAP.NOTES.md index d8ca4dd7..197e46a5 100644 --- a/restoration/source410/RENDER-ROADMAP.NOTES.md +++ b/restoration/source410/RENDER-ROADMAP.NOTES.md @@ -776,3 +776,49 @@ That defect has therefore gone from background annoyance to the top of the list: it is what stops a mech frame from ever being seen, because a run has to survive BOTH the skeleton build AND the launch to render anything, and at ~50% per run that is a coin flip on a four-minute cycle. + +-------------------------------------------------------------------------------- +THE INTERMITTENT POD CRASH IS THE SKELETON WALK'S -- attributed, not yet fixed +-------------------------------------------------------------------------------- +Attributed with a same-binary A/B, which is the only clean way to test an +intermittent fault: BT_NO_SKL skips the skeleton build, so one executable can +be run both ways with nothing else differing. + + walk ENABLED ~50% of runs die ("Reference to a page you don't own", + PF at 66D9), at DIFFERENT points each time -- sometimes + mid-walk, sometimes after it, sometimes before launch + walk DISABLED 0 crashes in 2 runs + SHIPPED exe 0 crashes in 2 runs on the same rig and conf + +So it is our new code, it is not the rig, and the varying fault point says +memory corruption surfacing later rather than a bad instruction in the walk. + +HYPOTHESES KILLED so far (all by reading the private library headers, so they +stay killed): + * matrix array too small -- dpl_MATRIX is float32[4][4] (DPL_PRIV.H:137), + exactly the 16 floats we pass. + * dangling Object= name. dpl_LoadObject is handed a pointer INTO the + NotationFile, which we then delete -- but neither s_dplobject + (DPL_PRIV.H:377) nor the common dpl_node header (DPL_PRIV.H:92) keeps a + name field, so the library does not retain it there. A private name + cache is still possible and remains the best surviving suspect. + * NotationFile rewriting the game's data. ~NotationFile DOES rewrite the + file when dirtyFlag is set, which would have corrupted the shipped .SKL + files -- checked, MAD.SKL is untouched (11847 bytes, Jan 2001), and the + engine's own Verify(!IsDirty()) guard is now copied into ReadSKLFile. + +STILL TO TRY, cheapest first: + 1. Keep the NotationFile alive for the mission instead of deleting it (a + ~12KB leak) and see if the crash rate drops -- that settles the name + cache question outright. + 2. Copy each Object= name into storage that outlives the walk, same test. + 3. Count what the walk allocates on the board (26 DCS + 19 objects + 19 + instances + 1 zone per mech) against whatever the VPX HLE's node tables + allow -- resource exhaustion would also present as a late, varying + fault. + 4. Check whether MakeEntityRenderables is invoked more than once per mech + (inside AND outside views). The [skl] summary line printed once per run + here, so this is unlikely, but it is cheap to re-check with two mechs. + +BT_NO_SKL stays in the tree: it is how any future "is it the skeleton?" +question gets answered in one build instead of two.