Page 1 of 1
TD386/virtual 8086 causes reset
Posted: Mon Feb 03, 2025 11:18 am
by max77
Hi all,
just recently came across an issue trying to debug some old school code with TD386 in virtual 8086 mode (that is, using TDH386.SYS). For some reason the debugger resets the whole system (just like hitting the reset button), and I absolutely don't know why. Same happens trying to use SOFTICE (the DOS version), no matter the BIOS settings or patch level. The reset happens right after loading the debugger, without any user interface being drawn. The rig in question is as follows:
* Shuttle HOT 555 socket 7 mainboard
* Pentium P54C 133MHz (two different CPUs tested)
* 16 or 48 MB of RAM
The very same system however runs perfectly fine with all the sorts of DOS real mode / protected mode applications, even Win 95 is stable.
I tested with other boards as well, and most of them are capable of running TD386 without any issus - from the very same boot disk! It's 2 out of my 5 boards causing the reset, 3 are OK. That's totally bugging me. As far as my testing goes I might already rule out RAM, the CPU itself and even the power supply.
Anybody out there having some background on what might be the reason behind this? I know that this is about almost forgotten technology, and for sure life will go on even with this issue unsolved. But heck, it's just the every now and then retro hours that drew me into this...
Thanks & BR
- Maximilian
Re: TD386/virtual 8086 causes reset
Posted: Mon Feb 03, 2025 2:34 pm
by rdos
I think TD386 might be a DOS extender application that either switches to protected mode or uses VCPI or DPMI to switch to protected mode. If you have no VCPI or DPMI interface, it will likely try to swíitch to protected mode itself, and if you have no guards against this, this could cause a triple fault and a reboot.
Re: TD386/virtual 8086 causes reset
Posted: Mon Feb 03, 2025 4:49 pm
by Octocontrabass
max77 wrote: ↑Mon Feb 03, 2025 11:18 amIt's 2 out of my 5 boards causing the reset, 3 are OK.
What kind of CPU is in each of these boards?
max77 wrote: ↑Mon Feb 03, 2025 11:18 amAnybody out there having some background on what might be the reason behind this?
CR4?
Re: TD386/virtual 8086 causes reset
Posted: Tue Feb 04, 2025 2:56 am
by max77
There are different CPUs on these boards (Intel P54C, P55C, AMD K5, K6, Cyrix), that's true. So one of my first thoughts also was - maybe some CPU type or (un)known errata is causing this behaviour? As they are stable otherwise, I don't think they are faulty, but who knows for sure without testing. So I took the CPU that is capable of running TD386 on one board and put it into the non-TD386-capable Shuttle - and still TD386 wouldn't start over there. So, I guess it's not so much the CPU, at least not the CPU alone.
Maybe chipset? Well, the Shuttle board is based on Intel 430VX... a common pattern? But no, turned out that another 430VX based board has no issues with TD386. Both boards were setup with 16MB of RAM (2x8MB SIMM) at that point.
I know there was a patch (tdg16m.sys) to allow for 16+MB RAM with TD386, already tested that as well, but made no difference.
That is so strange:
TD386 -> Enter -> TD386 Virtual driver greeting line -> blank screen -> beep -> BIOS POST. No error message, no further hints.
On working boards as one would expect:
TD386 -> Enter -> TD386 Virtual driver greeting line -> TD386 start and showing UI, ready to go
Anyway, let's see if I can norrow it down a bit further. I certainly won't need to ask the vendors for analysis right
- Maximilian
Re: TD386/virtual 8086 causes reset
Posted: Tue Feb 04, 2025 3:03 am
by max77
rdos wrote: ↑Mon Feb 03, 2025 2:34 pm
If you have no VCPI or DPMI interface
might that be possible on socket 7 (=mid/late 90s) boards being booted from the very same boot disks?
Re: TD386/virtual 8086 causes reset
Posted: Tue Feb 04, 2025 8:06 pm
by Octocontrabass
max77 wrote: ↑Tue Feb 04, 2025 2:56 amSo I took the CPU that is capable of running TD386 on one board and put it into the non-TD386-capable Shuttle
Which CPU?
max77 wrote: ↑Tue Feb 04, 2025 2:56 amMaybe chipset?
Maybe BIOS?
Re: TD386/virtual 8086 causes reset
Posted: Wed Feb 05, 2025 2:35 am
by max77
Which CPU?
tested with P54C 133MHz
Maybe BIOS?
already tried different patch levels for that board, just in case. Did not make any difference, though. BIOS on all boards tested is based on the very common Award 4.51PG, btw.
But yes, sure, might be some missing "feature" with board-specific BIOSes, for whatever is causing the TD386 reset while everything else (including EMM386) is working fine. Question is how to test. I'll try to find two boards (one with TD386 working and the other one failing)with as similar characteristics as possible, maybe they will boot with the BIOS chip swapped. Never did this, but should be safe to try I guess.
Maybe there is even an AMI BIOS available for one of them, would be interesting to compare...
Re: TD386/virtual 8086 causes reset
Posted: Wed Feb 05, 2025 1:05 pm
by max77
ok so I just tested the Shuttle HOT-555 with two foreign BIOSes from:
As they all share the same chipset (430VX) and super I/O (UM8669F) I was willing to give that a try.
And, surprise, it really booted up without any notable issues, however TD386 still wouldn't cooperate :/
Either those BIOSes also share the same sort of "bug" (or whatever) or it's just something else...
I can't see any pattern between my working boards and the non working ones. Just. Weird. Here some details:
Capable of starting TD386:
- PCChips M530 (however exiting TD386 did hang, but might be something else)
- San Li SL-586VT-II (added today)
- Lucky Star 5V-1A (the one with the hidden 8MHz FSB mode )
And the non compatible:
- Shuttle HOT-555 (the one in my retro rig)
- Ford Lian TX-5IB2 (with the ALi M5135 natively supporting FM floppy disks!)
Aaah, well... maybe I should just use one of the working boards for my debug session and stop worrying about that. It's a vintage only issue anyway, and I might as well use DOSBOX Debugger on a more modern machine.
But if, by any chance, someone reads this thread && encountered that issue somewhere in the past && has some details to share, I would still be very interested
- Maximilian
Re: TD386/virtual 8086 causes reset
Posted: Wed Feb 05, 2025 8:20 pm
by Octocontrabass
max77 wrote: ↑Wed Feb 05, 2025 2:35 amtested with P54C 133MHz
Have you tested any non-Intel CPUs in the affected boards?
max77 wrote: ↑Wed Feb 05, 2025 1:05 pmEither those BIOSes also share the same sort of "bug" (or whatever) or it's just something else...
They might share the same bug, if the BIOS vendor provided the same chipset support code to different OEMs.
It also could be something else. Are you loading any other drivers before or after TDH386.SYS?
Re: TD386/virtual 8086 causes reset
Posted: Thu Feb 06, 2025 2:55 am
by max77
Octocontrabass wrote: ↑Wed Feb 05, 2025 8:20 pm
Have you tested any non-Intel CPUs in the affected boards?
not yet in the Shuttle board, however the TX-5IB2 is affected and equipped with an AMD K6 (clocked at 300Mhz, ignoring potential div by zero for now). As the Shuttle did not even run TD386 with a known-to-work P54C (from another board) I did not further investigate in that direction.
Octocontrabass wrote: ↑Wed Feb 05, 2025 8:20 pm
It also could be something else. Are you loading any other drivers before or after TDH386.SYS?
I first ran into this while using FreeDOS with all the usual suspects loaded. As it's sometimes the little things that might break old software, I created a vanilla MS-DOS 5 boot disk to compare with the original bits and bugs of that era. The disk I used for testing had CONFIG.SYS:
Code: Select all
FILES=40
DEVICE=TDG16M.SYS
DEVICE=TDH386.SYS
DEVICE=HIMEM.SYS
DOS=HIGH
COUNTRY=049,850,COUNTRY.SYS
DEVICEHIGH=ramdrive.sys 4000 /e
and AUTOEXEC.BAT:
so nothing special so far I thought - and worked on most of the boards.
!!!! BUT !!!! just after I read your question about other drivers being loaded I tried to further reduce the setup, just because. I removed everything not indispensable so CONFIG.SYS now contains no more than:
Code: Select all
DEVICE=TDG16M.SYS
DEVICE=TDH386.SYS
and AUTOEXEC.BAT just a little bit of convenience:
And guess what - TD386 now fires up in virtual 8086 on the Shuttle, virtually smiling at me as if nothing happened. Who would have thought. I still don't know what part exactly is to blame, but that should be a matter of simple trial&error now.
I'll update this thread as soon as I figured it out. But thanks a lot for the hint. Proves to always "exprect the unexpected"
Re: TD386/virtual 8086 causes reset
Posted: Thu Feb 06, 2025 4:40 am
by max77
look at this, I think I found it - seems like
in config.sys is acting as sort of a kill switch here. Oh man, what a relief. Finally able to set hardware breakpoints based on I/O patterns without switching boards, yay!
I can keep everything else including HIMEM.SYS and the ramdrive as is, TD386 is working fine in virtual 8086 mode as long as DOS=HIGH is
not in place. Tried to find any reference in the documentation, however it just states:
On 80386- and 80486-based systems, at least 640K of extended memory to use the optional TD386 supervisor for debugging programs and running TD in virtual 8086 machines. (The TDH386.SYS device driver must also be installed.)
I'm still a bit puzzled as to why other boards seem to be totally fine with DOS=HIGH here, but whatever (at least, for now
)
Re: TD386/virtual 8086 causes reset
Posted: Thu Feb 06, 2025 11:14 am
by Octocontrabass
You're loading two drivers that control the A20 gate. Are they aware of each other? What does HIMEM.SYS display in verbose mode? What happens if you load HIMEM.SYS first?
Re: TD386/virtual 8086 causes reset
Posted: Thu Feb 06, 2025 12:49 pm
by max77
Hm, good point, always thought HIMEM.SYS was at least known to TD386/TDH386 as the documentation mentions both of them. However the chapter is not very clear on this topic, they basically just state "add TDH386.SYS to your CONFIG.SYS". They do, however, advise not to use anything like QEMM along with it, which makes sense.
DOS 5.0 himem.sys does not seem to support verbose mode (/V switch)... might try with 6.22 again tomorrow.
If I place HIMEM.SYS first then TDG16M.SYS (which was documented to just limit int 15h/func 88h reported memory size by hooking into it) tells that zero extended memory would be available. TD386 starts if DOS=HIGH is NOT set and again fails otherwise.
If HIMEM.SYS is placed last then TDG16M tells me that it limits the board's 48MB memory to a size compatible with TD386... and works on the Shuttle as long as I skip DOS=HIGH...
Re: TD386/virtual 8086 causes reset
Posted: Thu Feb 06, 2025 3:39 pm
by max77
out of urgent curiosity I put HIMEM.SYS 3.10 (the one bundled with MSDOS 6.22) onto the boot disk and gave it thorough try loading first and loading last (on the Shuttle board):
HIMEM.SYS loaded first with DOS=HIGH
HIMEM /V shows "Installed A20 handler number 1", no errors
TDG16M shows "Extended memory found: 000h Kilobytes, no conversion needed" <= suspicious!
TD386 fails
HIMEM.SYS loaded first without DOS=HIGH
HIMEM shows "Installed A20 handler number 1", no errors
TDG16M shows "Extended memory found: BC00h Kilobytes, converting to 3B80h Kilobytes"
TD386 works
HIMEM.SYS loaded last with DOS=HIGH
TDG16M shows "Extended memory found: BC00h Kilobytes, converting to 3B80h Kilobytes"
HIMEM /V shows "Installed A20 handler number 1", no errors
TD386 fails
HIMEM.SYS loaded last without DOS=HIGH
TDG16M shows "Extended memory found: BC00h Kilobytes, converting to 3B80h Kilobytes"
HIMEM /V shows "Installed A20 handler number 1", no errors
TD386 works
So, in the end, I think MSDOS 5's HIMEM.SYS behaves like MSDOS 6.22's HIMEM.SYS in this regards, no matter if loaded first or last. To my knowledge "handler number 1" is correct as it tells the machine type being recognized as "IBM AT or 100% compatible".
Why DOS=HIGH works on some boards and not on others still is a mystery to me, might be some "undefined" side effect as well. I think just not to use HMA for TD386 is a good enough solution for me, and better even skip HIMEM.SYS to avoid any potential A20 collisions, once again thanks for that hint.
- Maximilian