[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SoftICE under DOS16, anybody? __/__ Re: [Qemu-devel] [PATCH] inten

From: Martin Bochnig
Subject: Re: SoftICE under DOS16, anybody? __/__ Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake
Date: Sat, 02 Dec 2006 00:43:14 +0100
User-agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041221

Martin Bochnig wrote:

>>Might something like that help SoftICE for DOS16 to run properly without
>>freezing the whole guest after one or two ^D's  (i.e. for setting
>>breakpoints and switching back to the dos command.com)?
>>WinICE (on DOS386 a.k.a. {win386.exe / chicago's dos386.exe, now called
>>vmm32.vxd}) does/did already work well, when I last tested this a year
>>ago, but SoftICE for real mode DOS would always hang the whole guest
>>when being run inside QEMU (emulation case, not yet tested in case of
>>x86_x_x86 virtualization).
>>The same happens when using the Insignia_SoftWindows Pentium-ISA-PC
>>Emulator on Solaris_sparc, running any version of (MS-/IBM) or DRDOS.
>>Bochs claims to provide a more accurate emulation than qemu (at the cost
>>of making it marginally slower), but doesn't fix the SoftICE issue either.
>>It does - on the other hand - work as expected inside any version of
>>SunPCi, which only emulates a bit of io and graphics, but uses a
>>physical x86 cpu, rather than emulating it (I think it doesn't even have
>>to virtualize it, because nobody else is using the cpu sitting on that
>>pci card).
>>Has onybody found a way to work around the SoftICE_for_DOS16
>>instabilities under qemu?
>>(btw, my problems *are* qemu-dependant, not caused by an incompatible
>>himem.sys or anything of that sort / identical diskimages tested under
>>SunPCi, SoftWindows and qemu_for_SolarisSPARC-Hosts).

I might some remote day invest a bit of effort into trying to find out
WHY exactly SoftICE_for_realmodeDOS hangs the emulation (under qemu,
bochs and SoftWindows/RealPC) :
Whether or not it freezes "somehow internally" because of  "actually
running", or, more specifically, whether it just has to do with
listening to the keyboard for "^D" sequences (int16h and int21h_AH==01 /
see Ralf Brown's grand Interrupt list) to activate the SoftICE UI.
If it is "just" the latter, then maybe due to a timing related problem,
or maybe because the SoftICE-TSR somehow interferes with COMMAND.COM (or
any shell like i.e. BASH_for_DOS or 4DOS.COM) that are concurrently
listening to kbd input and therefore actively issuing certains DOS-21h
and 16h interrupts permanently (with appropriate values in (E)AL, (E)AL,
or(E)AX, permanently requesting the keyboard, if it has new input in its
associated stdin buffer (not quite correct, simplified).

The issue applies to all major SoftICE_for_realmodeDOS releases/versions.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]