Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

QEMM 8.xx and Linux

56 views
Skip to first unread message

Enrique Baraibar

unread,
Nov 18, 2001, 8:56:05 PM11/18/01
to
I have used QEMM 8.03 without any problems for some time. On my
machine coexist DRDOS 7.03 and Linux, booting DOS and switching to
Linux via loadlin when necessary.
Thus I used SuSE Linux 6.0 (kernels 2.0.36 and 2.2.5), and 6.3 (kernel
2.2.13) without a glitch.
Recently I upgraded to 7.1 (kernel 2.2.18) and Linux refused to load:
it simply hung.
After several days of despair, I downgraded QEMM to 7.04 and Linux
booted happily forever after. I suspect kernel 2.2.18 must be bigger
and so collide somehow with QEMM 8.03.
Hope this helps someone.

Enrique Baraibar

buck

unread,
Nov 19, 2001, 1:16:15 AM11/19/01
to
On 18 Nov 2001 17:56:05 -0800, enr...@linuxfreemail.com (Enrique
Baraibar) wrote:

Could you give us the non-working QEMM8 CONFIG.SYS, please?

My recollection is that either DOSDATA or DOS-UP hates boot loaders.

Did LOADLIN make _anything_ happen?

buck

Enrique Baraibar

unread,
Nov 19, 2001, 8:22:44 PM11/19/01
to
buck <bu...@private.mil> wrote in message news:<kj8hvt0io2e6rctbl...@4ax.com>...

> On 18 Nov 2001 17:56:05 -0800, enr...@linuxfreemail.com (Enrique
> Baraibar) wrote:

> snip

> >After several days of despair, I downgraded QEMM to 7.04 and Linux
> >booted happily forever after. I suspect kernel 2.2.18 must be bigger
> >and so collide somehow with QEMM 8.03.
> >Hope this helps someone.
> >
> >Enrique Baraibar
>
> Could you give us the non-working QEMM8 CONFIG.SYS, please?
>
> My recollection is that either DOSDATA or DOS-UP hates boot loaders.
>
> Did LOADLIN make _anything_ happen?
>
> buck

As far as I can remember, I didn't touch config.sys. I simply
installed QEMM7 to c:\qemm7 and then renamed c:\QEMM to c:\QEMM8 and
c:\QEMM7 to c:\QEMM.
I can be wrong, but I doubt config.sys had anything to do with it.
With QEMM 8.03, loadlin started O.K. until the point when the kernel
is uncompressed from the ramdisk image. There it simply hung without
further ado.
After the switch to QEMM 7.04 all was well, the kernel uncompressed
finely and I had again a running Linux system.

Anyway, here follows my config.sys:

>> start config.sys

:: DEVICE=C:\DRDOS7\VDISK.SYS 3072 512 64 /E:8
:: device=C:\QEMM\QEMM386.SYS DBF:2 RAM ST:F BE:N I=DC00-DFFF
I=FC00-FCFF X=EFF0-EFFF XSTI:1A XSTI:13 XSTI:76 SRBP:N R:1

device=C:\QEMM\QEMM386.SYS DBF:2 RAM ST:F I=DC00-DFFF X=EFF0-EFFF
XSTI:1A XSTI:13 XSTI:76 R:1

:: DEVICE=C:\DRDOS7\EMM386.EXE /auto /exclude=E000-FFFF
DEVICE=C:\DRDOS7\DPMS.EXE
:: DEVICE=C:\QEMM8\LOADHI.SYS /R:1 /SIZE=22704 C:\DRDOS7\SETVER.EXE
SHELL=C:\COMMAND.COM C:\ /E:512 /P /MX
BREAK=ON
FILES=50
HIBUFFERS=15
FCBS=0,0
HISTORY=ON,512,OFF
COUNTRY=34,,C:\DRDOS7\COUNTRY.SYS
DOS=LOW,UMB
:: DOS=HIGH,UMB
:: device=C:\DRDOS7\KEYB.COM SP+
LASTDRIVE=O
DEVICE=C:\SB16\CTCM.EXE
DEVICE=C:\QEMM\LOADHI.SYS /R:1 /SIZE=10624 C:\SB16\DRV\CTMMSYS.SYS
DEVICE=C:\QEMM\LOADHI.SYS /R:2 /SIZE=19632 C:\SCSI\ASPI2DOS.SYS /z /c
/d

:: HIDEVICE=C:\SCSI\ASPI2DOS.SYS /z /d
DEVICE=C:\QEMM\LOADHI.SYS /R:2 /SIZE=15360 C:\SCSI\ASPIDISK.SYS /d
:: HIDEVICE=C:\SCSI\ASPIDISK.SYS /d
:: DEVICE=D:\QEMM_8\LOADHI.SYS /R:2 /SIZE=9776 C:\DRDOS7\ANSI.SYS
:: HIDEVICE=C:\SCSI\SJIIX.SYS
rem *****PHILIPS PCA65IDE Y SCSICD
TIMEOUT 5
?"沃saremos la grabadora de CD (y/n)? "GOTO SCSICD
DEVICE=C:\QEMM\LOADHI.SYS /R:2 /SIZE=26144 C:\PHILIPS\PCA65IDE.SYS
/D:DRCD001 /P:1F0s /I:14 /V

:: HIDEVICE=C:\PHILIPS\PCA65IDE.SYS /D:DRCD001 /P1F0s /I:14 /V
GOTO GO_ON
:SCSICD
Device=C:\QEMM\LOADHI.SYS c:\scsi\aspicd.sys /d:drcd001
:GO_ON
rem *****PHILIPS PCA65IDE ( 14-Jun-96 )
REM HIDEVICE = C:\WINDOWS\SMARTDRV.EXE
:?"沃saremos el scanner (y/n)? "HIDEVICE=C:\TOOLKIT\SCAN\HHSCAND.SYS
/A=280/I=4/D=3/W=105

TIMEOUT 0
:DEVICE = C:\WINDOWS\IFSHLP.SYS
:DEVICE = C:\IOMEGA\ASPIPPM1.SYS FILE=NIBBLE.ILM SPEED=10
:DEVICE = C:\IOMEGA\SCSICFG.EXE /V
:DEVICE = C:\IOMEGA\SCSIDRVR.SYS
REM ********** Added by UMAX Setup **********
:DEVICEHIGH=D:\VSTASCAN\ASPI3191.SYS
REM ********** Added by UMAX Setup **********
:DEVICEHIGH=D:\VSTASCAN\ASPI671X.SYS

>> end config.sys

BTW, other than this I didn't notice any difference after switching to
QEMM 7.04.
I haven't the slightest idea what DOSDATA is for. Could you please
explain?
TIA

Enrique Baraibar

buck

unread,
Nov 20, 2001, 1:43:20 AM11/20/01
to
On 19 Nov 2001 17:22:44 -0800, enr...@linuxfreemail.com (Enrique
Baraibar) wrote:
---- cut ---

>BTW, other than this I didn't notice any difference after switching to
>QEMM 7.04.
>I haven't the slightest idea what DOSDATA is for. Could you please
>explain?
>TIA
>
>Enrique Baraibar

DOSDATA.SYS loads the information that normally loads into 40:0 and
70:0 (segment:offset) into high memory. Lastdrive, FCBS, Etc (not
Buffers).

I bet the problem was with all those "Stealthed interrupts". You hung
trying to access bzImage off the hard drive, or trying to read the
boot sector.

FWIW, DOS-UP and DOSDATA work best with M$ DOS and do little or
nothing with other DOSes. M$ DOS versions newer than 6.22 also fall
into that "no help" category.

Want to try QEMM 7.53? (evil grin)

buck

Enrique Baraibar

unread,
Nov 20, 2001, 9:25:55 PM11/20/01
to
buck <bu...@private.mil> wrote in message news:<ueujvtchrh5p690qu...@4ax.com>...

>
> I bet the problem was with all those "Stealthed interrupts". You hung
> trying to access bzImage off the hard drive, or trying to read the
> boot sector.
>

buck, I don't know, remember that 2.0.36, 2.2.5 and 2.2.13 booted
nicely. But surely I am no expert, and anyway all is well now.

> Want to try QEMM 7.53? (evil grin)
>
> buck

Now, you ARE a wicked person. Sure, out of curiosity I will try it,
but all on due time. Watch this space.

Enrique Baraibar

Matthias Paul

unread,
Nov 28, 2001, 12:04:11 AM11/28/01
to
On 2001-11-20, Enrique Baraibar wrote:

> I can be wrong, but I doubt config.sys had anything to do with it.
> With QEMM 8.03, loadlin started O.K. until the point when the kernel
> is uncompressed from the ramdisk image. There it simply hung without
> further ado.

Difficult to guess from here... I would have tried to unload one driver
after the other in order to possibly isolate a culprit. It could have
well been a compatibility issue with QEMM´s rather aggressive memory
utilization and one of the drivers loaded - sometimes such issues only
show up in certain rare situations.

That the hang occurs only after the Linux image was uncompressed would
indicate some kind of "boot problem" here, unfortunately there are many
possible causes for this and I cannot help you further here without
analysing your system.

> After the switch to QEMM 7.04 all was well, the kernel uncompressed
> finely and I had again a running Linux system.

> Anyway, here follows my config.sys:

Since you posted your DR-DOS CONFIG.SYS, I had a look. It should work
fine in general, although there a few tricks how you could squeeze out
more memory (at least if you´d let DR-DOS use the HMA).

> :: DEVICE=C:\DRDOS7\VDISK.SYS 3072 512 64 /E:8

You can find a faster and smaller runtime-reconfigurable RAM disk
driver named TDSK 2.42 (still BETA, but very stable!) at:

ftp://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ramdisk/

(The driver was originally developed by Ciriaco García de Celis.
However, feature suggestions and reports are best directed to me now,
please, I have took over development and further enhanced issues
are already in my queue... ;-)

If you´d move the RAM disk DEVICE line further down, you can also
load it high.

> :: device=C:\QEMM\QEMM386.SYS DBF:2 RAM ST:F BE:N I=DC00-DFFF
> I=FC00-FCFF X=EFF0-EFFF XSTI:1A XSTI:13 XSTI:76 SRBP:N R:1
>
> device=C:\QEMM\QEMM386.SYS DBF:2 RAM ST:F I=DC00-DFFF X=EFF0-EFFF
> XSTI:1A XSTI:13 XSTI:76 R:1

> :: DEVICE=C:\DRDOS7\EMM386.EXE /auto /exclude=E000-FFFF

I haven´t used QEMM for a long while now, as the use of the
DR-DOS EMM386 with manually fine-tuned configuration files
gave better results for me. However, I guess readers in this
forum will probably not want to fade out QEMM because they
use DESQview.

Well, since I´m here already, I´d like to point out two small
issues with DR-DOS 7.02+ and QEMM, which you should know about:

- The memory arrangement of the handle structures (MEM /A HANDLES=)
changed with the introduction of the FILESHIGH= and FCBSHIGH=
[D]CONFIG.SYS directives in order to free up to several more Kb
of conventional memory under DR-DOS (depends on the count of
handles (FILES+FCBS) on your system). They are now grouped in
3 chunks while they were arranged in 2 chunks previously.

The change should not have caused problems for QEMM because this
is completely valid in terms of DOS standards, however, QEMM´s
DOS-UP feature does not expect this, and its sanity checks keep
it from loading the DOS structures high. This results in ca. 1 Kb
less conventional memory than the theoretical possible maximum
under QEMM. (Maybe, there´s an undocumented QEMM configuration
directive to override this sanity check, but I don´t know about
any such directive...) Unfortunately, Quarterdeck stopped working
on QEMM before they could incorporate this really minor correction
on their party, so you will have to live with it.

However, I once wrote a patch (a DEBUG script named IBMBIO85.SCR)
for the DR-DOS kernel which will reenable the old handle memory
layout. This will free even more conventional memory under
DR-DOS, but causes serious compatibility problems with Windows 3.xx
when the FILESHIGH=, FCBSHIGH=, or DOS=AUTO directives are used
at the same time, because it will leave only 5 handles in low
memory in contrast to the 8 handles which are required for
Windows to work properly due to an extremely dangerous hack
on Microsoft´s side to determine the size of the DOS internal
SFT structures (this is known as "CON CON CON CON CON" hack
because Windows opens CON five times and then scans the first
512 Kb of memory for the "CON" string to measure the displacement
between these strings, something that could be easily fooled by
just placing some "CON" strings in the DOS memory image with
incorrect offsets from each other - with fatal consequences for
the running system).

For your convenience, here is the script again:

; -------------------------------------------------------------------
; Copyright (C) 1997,2001 by Matthias Paul. All rights reserved.
;
; This is provided "AS IS" without warranties or support of any kind!
; Use at your own risk! Improper use may cause serious loss of data!
;
; -------------------------------------------------------------------
;
; Description: Caldera DR-OpenDOS 7.02+ DEBUG R1.50+ script to patch
; the DR-OpenDOS 7.02+ IBMBIO.COM (1997-12) file to
; allocate only 5 instead of 8 file handles during
; [D]CONFIG.SYS.
;
; Sympthom: Quarterdeck's QEMM 8 DOS-UP refuses to relocate
; DOS sub-structures on DR-OpenDOS 7.02+ and later,
; resulting in about 1 Kb less free total Conventional
; Memory.
;
; Synopsis: Due to the introduction of new FILESHIGH=/HIFILES=
; and FCBSHIGH=/HIFCBS= [D]CONFIG.SYS directives,
; the chunking of handles has slightly changed with
; DR-OpenDOS 7.02+. For unknown reasons, DOS-UP
; refuses to work with this changed layout.
;
; Solution: A patch should be made available by Quarterdeck
; for QEMM, but at present none seems to be available.
; Please keep asking them for a solution to this
; problem, as a fix is a simple two-liner for them
; and besides would also improve general DOS
; compatibility in their product.
;
; Workaround: A temporary solution is to apply this patch
; (IBMBIO85.SCR) to the IBMBIO.COM file. The patch also
; gives about 150 bytes more conventional memory on
; systems, where handles are loaded into UMBs using
; the new FILESHIGH=/HIFILES= or FCBSHIGH=/HIFCBS=
; directives.
;
; Requirements: 1. DEBUG R1.50+ (since DR-OpenDOS 7.02 and
; DR-DOS 7.02+).
; 2. IBMBIO.COM as of Caldera DR-OpenDOS 7.02 and
; DR-DOS 7.02+.
; Tested with IBMBIO.COM up to DR-DOS 7.04/7.05
; (1999-08-19).
;
; Hints: - Never try to apply this patch with other issues of
; DEBUG or to other IBMBIO.COM files then those listed
; above.
; - It is not garanteed that this patch will continue to
; work with future issues of DR-DOS, although it will
; hardly become broken, as the script will attempt to
; synchronize with new issues automatically.
; - You can query the file version number by
; toggling Scrollock on when the "Starting Caldera
; DR-DOS..." message is shown at startup, or by
; issueing "VERSION IBMBIO.COM" at the C:\ prompt.
;
; Restrictions: - Microsoft Windows 3.xx will probably not run after
; applying this patch to IBMBIO.COM. Instead, it
; will display: "Unsupported version of MS-DOS" on
; startup, especially with handles loaded into
; UMBs. Note, that at least Microsoft Windows for
; Workgroups 3.11 still runs OK. If you have success
; running a different version of MS Windows after
; applying this patch, I would appreciate your
; feedback, just for the records.
;
; How To: C:
; SYS A: Make a backup boot
floppy
; ATTRIB -R -H -S C:\IBMBIO.COM Strip off attributes
; COPY C:\IBMBIO.COM C:\TEMP\IBMBIO.COM Backup the BIOS file
; CD C:\TEMP
; DEBUG < IBMBIO85.SCR Apply the patch
; COPY C:\TEMP\IBMBIO.COM C:\IBMBIO.COM Update system if OK
; ATTRIB +R +H +S C:\IBMBIO.COM Restore attributes
;
; Version : 1.06
; Last edit : 2001-11-28 MPAUL
;
/X ; Enter extended DEBUG mode
Nibmbio.com ; Name & load the BIOS from disk
; (+100h)
L
R ax=cx ; Save file length
R cx=0 ; Search for 1st match and store
; location in CX
-S cs:100 L ax+100 "IBMDOS",20,20
R dx=cx ; Store location in DX (0 if not
; found)
R cx=0 ; Search for 1st match and store
; location in CX
-S cs:dx-A L 1 4
;-S cs:dx-A L 1 1 ; [To revert the patch modify above
; line!]
; If CX is zero, the correct
; DEF_NUM_FILES value (4) was not
; found, hence the patch does not
; alter the file (it's directed
; into a dummy PSP at offset +0h).
; Otherwise DEF_NUM_FILES is
; altered from 4 to 1.
E cs:cx 1
;E cs:cx 4 ; [To revert the patch modify above
; line!]
R cx=ax ; Restore file length
; Write the BIOS back to disk
W
Q ; Quit DEBUG
;

- The other issue is QEMM´s Stealth feature which may conflict
with the new DR-DOS 7.02+ YEAR2000=ON [D]CONFIG.SYS directive.

Either use YEAR2000=OFF before you load QEMM (requires a ROM BIOS
which does not have Y2K bugs, or a 3rd party Y2K-fixing TSR
instead of DR-DOS´ built-in fix), or use QEMM´s EXCLUDESTEALTHINT=1A.

Your DEVICE line contains XSTI=1A already, so this should be
no problem for you any more.

> SHELL=C:\COMMAND.COM C:\ /E:512 /P /MX

This is wrong syntax. COMMAND.COM does not support a /MX option.

To load the resident portion into the HMA, you need to specify
/MH. Also, the /P[:filename] or the /C or /K options should always
be the last options in the parameter line, some tools require them
to be in this order. So change this to:

SHELL=c:\command.com c:\ /E:512 /MH /P

If you have problems to load the shell into the HMA (MEM /F), try
playing with the SHELLHIGH SIZE=xxxx ... option, where xxxx is
the reserved area for the shell at the start of the HMA in hex bytes.

This should work without problems with DR-DOS 7.03, but you may need
to play with that SIZE parameter under 7.02. Judging from the rest
of your CONFIG.SYS you should have vast amounts of free memory left
in the HMA (ca. 20-25 Kb), even if you´d have used DOS=HIGH,UMB,
and even more with the sub-optimal DOS=LOW,UMB.

If for some reasons you cannot load it into the HMA you can still
use /MU to load it into UMBs, but this would certainly require
re-optimizing your current UMB utilization.

> FILES=50

I guess you use QEMM´s FILES.COM later on to load high the handle
structures, otherwise try DR-DOS´ own FILESHIGH=50 to load that
stuff into UMBs. This will free quite some conventional memory.

> DOS=LOW,UMB
> :: DOS=HIGH,UMB

Probably because you use QEMM or DV, but mind that if you do not
actually need to keep the HMA free for DV or so, I strongly suggest
to use DOS=HIGH,UMB

Well, not very specific to the original problem with QEMM and Linux,
but I hope it helps, still...

Greetings,

Matthias

--

<mailto:Matthi...@post.rwth-aachen.de>; <mailto:mp...@drdos.org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org


0 new messages