TD386/virtual 8086 causes reset

[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

[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.

[Octocontrabass]

It's 2 out of my 5 boards causing the reset, 3 are OK.

What kind of CPU is in each of these boards?

Anybody out there having some background on what might be the reason behind this?

CR4?

[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

[max77]

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?

[Octocontrabass]

So I took the CPU that is capable of running TD386 on one board and put it into the non-TD386-capable Shuttle

Which CPU?

Maybe chipset?

Maybe BIOS?

[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...

[max77]

ok so I just tested the Shuttle HOT-555 with two foreign BIOSes from:

• Gigabyte GA-586ATV

• Soyo SY-5VX

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)

• PCChips M537

• 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)

• Aopen A57 (added today)

• 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

[Octocontrabass]

tested with P54C 133MHz

Have you tested any non-Intel CPUs in the affected boards?

Either 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?

[max77]

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.

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:

Code: Select all

PROMPT $p$g
KEYB GR,,KEYBOARD.SYS

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:

Code: Select all

PROMPT $p$g

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"

[max77]

look at this, I think I found it - seems like

Code: Select all

DOS=HIGH

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 )

[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?

[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...

[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