DOS ain't dead

Hello,

the final Jemm v5.68 is now available at

http://www.japheth.de/Jemm.html

changes:
- new XDMA32 JLM with support for "legacy" and "native" PCI controllers
- updated XCDROM32 JLM with support for "legacy" and "native" PCI controllers

---
MS-DOS forever!

I saw somewhere you're looking for SATA CD for testing. I have a Dell PC at work with TS-H653A SATA DVD+-RW. I only tried gcdrom.sys which works wit it.

---
DOS gives me freedom to unlimited HW access.

> I saw somewhere you're looking for SATA CD for testing. I have a Dell PC at
> work with TS-H653A SATA DVD+-RW. I only tried gcdrom.sys which works wit
> it.

Yes. However, the real issue is not SATA vs PATA, it is "native" vs "legacy". The old CD-ROM drivers (XCDROM, QCDROM, ...) did support "legacy" IDE controllers only, while the newer ones (XCDROM32, UDVD, ...) should work with "native" ones as well. It's just that SATA devices are often attached to IDE controllers running in "native" mode.

---
MS-DOS forever!

> Yes. However, the real issue is not SATA vs PATA, it is "native" vs
> "legacy". The old CD-ROM drivers (XCDROM, QCDROM, ...) did support
> "legacy" IDE controllers only, while the newer ones (XCDROM32, UDVD, ...)
> should work with "native" ones as well. It's just that SATA devices are
> often attached to IDE controllers running in "native" mode.

Understand. Unfortunatelly this Dell BIOS doesn't have any additional option releated to mode. I can only enable/disable SATA channel. I can only say that this drive didn't worked with standard atapicd.sys but works with gcdrom.sys so I guess it's native not legacy.

BTW I just have new mobo from Commell and also upgraded disk subsystem. Now I have attached 500GB SATA drive + 120GB PATA through small IDE/SATA adapter and everything works fine under DOS with IDE/combined and even enhanced mode.
I quickly measure transfer rate. Without any DMA tools I got poor 6MB/s but with UIDE.sys I got nice ~50MB/s :)
Before on ITE8211 I got ~25MB/s without DMA (any DMA tool didn't worked on it).

BTW how is possible that ITE controller had much faster transfer rate without enabling DMA than ICH7? I guess it depends on how BIOS will initialize the drives.

---
DOS gives me freedom to unlimited HW access.

> BTW how is possible that ITE controller had much faster transfer rate
> without enabling DMA than ICH7? I guess it depends on how BIOS will
> initialize the drives.

Maybe it already did DMA transfers via Int13h BIOS. Udo Kuhnt reported such behaviour for his Promise FastTrak Ultra133 TX2.

---
Forum admin

> Maybe it already did DMA transfers via Int13h BIOS. Udo Kuhnt reported
> such behaviour for his Promise FastTrak Ultra133 TX2.

Maybe, I also can see similar effect on Abit BX133 Raid with HPT370. Both this controllers have special BIOS with INT13h extensions which probably take care about DMA. But to be sure, how can I detect if INT13h services use DMA?

---
DOS gives me freedom to unlimited HW access.

> But to be sure, how can I detect if INT13h services use DMA?

That's tricky.

100% safe options are:

- reverse engineer BIOS
- write a JLM which traps IDE port access

Not 100% safe, but good guesses are:

- read the drive's config sector. There are some bits which tell if UDMA is activated and what UDMA mode is set.
- in v86-mode, the BIOS has to do VDS calls (int 4Bh) if it uses DMA, which can be trapped easily.

---
MS-DOS forever!

> > But to be sure, how can I detect if INT13h services use DMA?

if the speed is > 8MB/sec, it's using UDMA

most S-ATA BIOS's seem to use UDMA, but - according to Jack, some BIOS
disable UDMA in protected mode, so a protected mode aware driver is
a good idea for S-ATA, too.

> - in v86-mode, the BIOS has to do VDS calls (int 4Bh) if it uses DMA,
> which can be trapped easily.

not necessarily. They could reserve the top memory 64K for that; before
reporting the memory via int 15/E8xx. locking wouldn't be needed for that
memory (or does that not work since EMM386 has to set up pagetables for this region, too?)


Tom

> not necessarily. They could reserve the top memory 64K for that; before
> reporting the memory via int 15/E8xx. locking wouldn't be needed for that
> memory (or does that not work since EMM386 has to set up pagetables for
> this region, too?)

No, not for the DMA operation itself. You have to copy the bytes to/from this buffer, and THAT will require PTEs, but this is done inside Int 15h, ah=87h.

---
MS-DOS forever!

> Understand. Unfortunatelly this Dell BIOS doesn't have any additional
> option releated to mode. I can only enable/disable SATA channel. I can
> only say that this drive didn't worked with standard atapicd.sys but works
> with gcdrom.sys so I guess it's native not legacy.

Not sure if you really meant ATAPICDD.SYS here, but Eric (Auer) claims that it is unfinished, slow, and buggy (and no longer developed). He basically told me to avoid it at all costs. Just FYI.

> I quickly measure transfer rate. Without any DMA tools I got poor 6MB/s

To be more specific, here's result of my rawspeed at 1st FAT16 partition:

without UDMA

Writting average speed: 6.852 MB/s
Reading average speed: 7.157 MB/s

with UDMA.sys

Writting average speed: 56.135 MB/s
Reading average speed: 56.820 MB/s

Such speed boost is very significant...

---
DOS gives me freedom to unlimited HW access.

> without UDMA
>
> Writting average speed: 6.852 MB/s
> Reading average speed: 7.157 MB/s
>
> with UDMA.sys
>
> Writting average speed: 56.135 MB/s
> Reading average speed: 56.820 MB/s
>
> Such speed boost is very significant...

Yes. Might be one of the "El Cheapos". Does this difference occur in both v86-mode AND real-mode?

---
MS-DOS forever!

> Yes. Might be one of the "El Cheapos". Does this difference occur in both
> v86-mode AND real-mode?

Yes, the same gain for RM/QEMM/JEMM. BTW what means "El Cheapos"?

---
DOS gives me freedom to unlimited HW access.

> BTW what means "El Cheapos"?

Cheap junk

---
DOS-u-akbar!

> BTW what means "El Cheapos"?

Exactly that what your BIOS is!

---
MS-DOS forever!

> > BTW what means "El Cheapos"?
>
> Exactly that what your BIOS is!

OK, I cannot compare but isn't it common for other boards using ICHx?
Anyway I got better performance with UDMA than on ITE8211 or HPT370 without it.

---
DOS gives me freedom to unlimited HW access.

> OK, I cannot compare but isn't it common for other boards using ICHx?
> Anyway I got better performance with UDMA than on ITE8211 or HPT370
> without it.

I thought it's common nowadays that the BIOS supports UDMA for both real-mode and v86-mode. Your BIOS proves that I was wrong and even more, that it's not just v86-mode which is NOT "UDMA-supported".

---
MS-DOS forever!

> I thought it's common nowadays that the BIOS supports UDMA for both
> real-mode and v86-mode. Your BIOS proves that I was wrong and even more,
> that it's not just v86-mode which is NOT "UDMA-supported".

Can anybody else try it on other mobo with ICHx?

BTW maybe I can also try enhanced and RAID mode (raid use other BIOS). It works in DOS but it's not compatible with Win9x so I use combined mode (1 channel PATA + 2 SATA ports fully emulating standard IDE with usual IO base address, enhanced mode uses different IO base (higher value))

---
DOS gives me freedom to unlimited HW access.

> Can anybody else try it on other mobo with ICHx?

Try exactly what?

---
Forum admin

> > Can anybody else try it on other mobo with ICHx?
>
> Try exactly what?

If you got the same low disk transfer rate (in RM and VM) on your ICH controller like me. I wrote a simple tool for benchmarking years before...
http://www.volny.cz/rayer/programm/programe.htm#RAWSPEED

---
DOS gives me freedom to unlimited HW access.

> If you got the same low disk transfer rate (in RM and VM) on your ICH
> controller like me.

OK.

Btw: Will you ever release source code for eddinfo.exe?

---
Forum admin

> Btw: Will you ever release source code for eddinfo.exe?

Maybe...
It's not finished yet and I'll have to put some further work on it. But currently I'm busy with installing new MB, HDD and also saving data from dying CDs (after ~5 years) which I just found in my archive (Philips [Ritek] CD-R sucks!)

---
DOS gives me freedom to unlimited HW access.

- My experiments with Rawspeed (I think that it can be interesting)

* without Jemm (only HIMEMX), without UIDE, without XDMA32

writing: 4.697 MB/s
reading: 5.289 MB/s

* Jemm, without UIDE, without XDMA32

writing: 1.313 MB/s
reading: 2.066 MB/s

* Jemm, without UIDE, XDMA32

writing: 1.327 MB/s
reading: 2.432 MB/s

* Jemm, UIDE, without XDMA32

writing: 1.328 MB/s
reading: 2.387 MB/s

- Very poor benefit with XDMA32 and UIDE. Is this normal?

And the winner is...

* Windows XP (console)

writing: 12.261 MB/s
reading: 7.937 MB/s

My hard disk:
-------------

- FUJITSU MPF320AT
- When I boot: Pri. Master Disk 20496 MB, UDMA 2
- FAT32

CONFIG.SYS:
-----------

STACKS=0,0
!COUNTRY=001,858,C:\FDOS\BIN\COUNTRY.SYS
!SET lang=ES
!LASTDRIVE=Z
!BUFFERS=20
!FILES=40
!DOS=HIGH,UMB
!DOSDATA=UMB
!set dircmd=/ogn /4
!MENUCOLOR=7,0
MENUDEFAULT=1,5
MENU 1 - Load FreeDOS with JEMM386, no EMS (most UMBs), max RAM free
MENU 2 - Load FreeDOS with JEMM386+EMS
MENU 3 - Load FreeDOS including HIMEM XMS-memory driver
MENU 4 - Load FreeDOS with EMM386 (DOS 7.10)
MENU 5 - Load Freedos with EMM386 (Freedos 1.0)
1?DEVICE=C:\FDOS\UTIL\JEMM386\JEMMEX.EXE X=TEST NOHI NOEMS
2?DEVICE=C:\FDOS\UTIL\JEMM386\JEMMEX.EXE X=TEST NOHI
345?DEVICE=C:\FDOS\BIN\HIMEMX.EXE
12?DEVICEHIGH=C:\FDOS\UTIL\JEMM386\JLOAD.EXE C:\FDOS\UTIL\JEMM386\XDMA32.DLL /UF
12?DEVICEHIGH=C:\FDOS\UTIL\JEMM386\JLOAD.EXE C:\FDOS\UTIL\JEMM386\XCDROM32.DLL /D:FDCD0001 /UF
4?DEVICE=C:\FDOS\UTIL\DOS710\EMM386.EXE RAM HIGHSCAN
5?DEVICE=C:\FDOS\BIN\EMM386.EXE X=TEST
SHELLHIGH=C:\FDOS\bin\command.com C:\FDOS\bin /E:1024 /P=C:\autoexec.bat

AUTOEXEC.BAT
------------

@echo off
set PATH=c:\fdos\bin;c:\fdos\util\antiword;c:\fdos\util\hx\bin
set NLSPATH=c:\fdos\NLS
set HELPPATH=c:\fdos\HELP
set home=c:\fdos\util
set temp=f:
set tmp=f:
SET CFGFILE=C:\fdconfig.sys
LH DISPLAY CON=(EGA,,1)
LH FDAPM APMDOS
MODE CON CP PREP=((858) C:\FDOS\cpi\EGA.CPX)
LH MODE CON CP SEL=858
LH KEYB SP,,keyboard.sys
if not "%config%"=="3" set blaster=a220 i7 d1 h7 p330 t6
if not "%config%"=="3" set sbpci=c:\sbpci
if not "%config%"=="3" c:\sbpci\sbload
if not "%config%"=="3" c:\sbpci\sbinit
echo devload /h c:\fdos\util\drivers\uide.sys /b /d:fdcd0001
shcdx33c /D:FDCD0001
C:\FDOS\UTIL\XMSDSK\XMSDSK 60000 /Y
C:\FDOS\UTIL\CTM\CTMOUSE.EXE
lh c:\fdos\util\doslfn\doslfn c+
lh c:\fdos\util\at2400\at2400 0x60

Bye :)

> - My experiments with Rawspeed (I think that it can be interesting)

Very poor results for an UDMA-2 disk. And it's also strange that v86-mode takes considerable time. The XP result is not comparable IMO, because most likely a WB cache is involved here.

Perhaps you should also try idecheck

I just recently have added support for "native" IDE controllers.

This tools allows to access HDs on the lowest level. There are options /PIO, /DMA and /I13, thus you can compare results achieved with "Int 13h", PIO and DMA. In your case it might be especially interesting if "idecheck 0 /DMA" also gives these poor results.

---
MS-DOS forever!

> > - My experiments with Rawspeed (I think that it can be interesting)
>
> Very poor results for an UDMA-2 disk.

ACK

> And it's also strange that v86-mode takes considerable time.

Could it be related to PM<>RM switch latency for data transfers?
In the past on slow computers (Pentium 1) RAWSPEED was of no help to me. I got much higher transfer rates using my own similar benchmark written in Turbo Pascal 6 (RM).

---
Forum admin

> - My experiments with Rawspeed (I think that it can be interesting)

You forgot to tell us about your machine specs. CPU? Clock speed?
see http://www.bttr-software.de/links/#sysinf for tools

---
Forum admin

> > - My experiments with Rawspeed (I think that it can be interesting)
>
> Very poor results for an UDMA-2 disk. And it's also strange that v86-mode
> takes considerable time. The XP result is not comparable IMO, because most
> likely a WB cache is involved here.
>
> Perhaps you should also try
> idecheck
>
> I just recently have added support for "native" IDE controllers.
>
> This tools allows to access HDs on the lowest level. There are options
> /PIO, /DMA and /I13, thus you can compare results achieved with "Int 13h",
> PIO and DMA. In your case it might be especially interesting if "idecheck 0
> /DMA" also gives these poor results.

* Idecheck 0 /PIO

10043 KB/sec ---> 9.807 MB/sec

* Idecheck 0 /I13

19274 KB/sec ---> 18.822 MB/sec

* Idecheck 0 /DMA

19308 KB/sec ---> 18.855 MB/sec

My computer is a Pentium III 600 MHz with 256 Mb of RAM

> > > - My experiments with Rawspeed (I think that it can be interesting)

Rawspeed (edited) is really slow, where ever you use it (e.g. it uses a buffersize of 20K only).

when measuring the I/O interface, you should use the fastest possible program, not the slowest.

> * Idecheck 0 /PIO
>
> 10043 KB/sec ---> 9.807 MB/sec
>
> * Idecheck 0 /I13
>
> 19274 KB/sec ---> 18.822 MB/sec
>
> * Idecheck 0 /DMA
>
> 19308 KB/sec ---> 18.855 MB/sec

so it looks like the BIOS is already using UDMA (and JEMM386 is as good, or as bad as the BIOS)

otoh, all of the above uses DPMI programs.

try rawread for a real mode program if that changes things.

try

RAWREAD 0 (does basically the same as Idecheck 0 /I13)

and (create a big file and)

RAWREAD C:\BIGFILE.DAT

which reads a large file for about 10 seconds.

> My computer is a Pentium III 600 MHz with 256 Mb of RAM

disk age (or disk size) would help as well; old hard disks just weren't faster then ~20 MB/sec

> * Idecheck 0 /PIO
>
> 10043 KB/sec ---> 9.807 MB/sec
>
> * Idecheck 0 /I13
>
> 19274 KB/sec ---> 18.822 MB/sec
>
> * Idecheck 0 /DMA
>
> 19308 KB/sec ---> 18.855 MB/sec
>
> My computer is a Pentium III 600 MHz with 256 Mb of RAM

the above results are achieved in v86 or real-mode? Is there still a significant difference in speed?

---
MS-DOS forever!

> > > > - My experiments with Rawspeed (I think that it can be interesting)
>
> Rawread is really slow, where ever you use it (e.g. it uses a buffersize

Rawread or Rawspeed?

> of 20K only).
>
> when measuring the I/O interface, you should use the fastest possible
> program, not the slowest.

Why should we use Rawread then?

> > My computer is a Pentium III 600 MHz with 256 Mb of RAM
>
> disk age (or disk size) would help as well; old hard disks just weren't
> faster then ~20 MB/sec

I guess, "FUJITSU MPF320AT" means MPF3204AT actually. Quite old. According to specs transfer rate should be around "21.5 to 37.7MB/s".

---
Forum admin

> Rawread or Rawspeed?

Sorry, my fault. RawSpeed is usually slow, RawRead is usually as fast as you can get

To japheth:

> the above results are achieved in v86 or real-mode? Is there still a
> significant difference in speed?

Before in v86, option 1 in config.sys

Now in Real-Mode, only HIMEMX, option 3 in config.sys:
------------------------------------------------------

* Idecheck 0 /PIO

10072 Kb/sec ---> 9.835 Mb/sec (9.807 Mb/sec before) (very similar)

* Idecheck 0 /I13

- Don´t run, error:
0 00 0 [command aborted ID not found] 00 device not ready error

Normal? I don´t know

* Idecheck 0 /DMA

19298 Kb/sec ---> 18.845 Mb/sec (18.855 Mb/sec before) (very similar)

To Tom:

* HIMEMX, without JEMM, without XDMA32, without UIDE

Rawread 0 ---> 9.5 Mb/sec
Rawread "bigfile" (70 Mbs) ---> 6.7 Mb/sec

* JEMM, without XDMA32, without UIDE

Rawread 0 ---> 9.4 Mb/sec
Rawread "bigfile" (70 Mbs) ---> 6.5 Mb/sec

* JEMM, XDMA32, without UIDE

Rawread 0 ---> 22.6 Mb/sec (better)
Rawread "bigfile" (70 Mbs) ---> 8.5 Mb/sec (better)

* JEMM, without XDMA32, UIDE

Rawread 0 ---> 22.3 Mb/sec
Rawread "bigfile" (70 Mbs) ---> 8.5 Mb/sec

- My hard disk is 7 years old (more or less), 20 Gb, only one partition, FAT32.

Goob bye

> Rawspeed (edited) is really slow, where ever you use it (e.g. it uses a
> buffersize of 20K only).

It's fast as DJGPP programs can be. Of course you can talk with disk at IO ports directly but only a few programs do it. Others uses INT13 or DOS services.
It can also be affected by VM/RM/PM stuffs as its a PM DPMI program.

---
DOS gives me freedom to unlimited HW access.

> Yes. Might be one of the "El Cheapos". Does this difference occur in both
> v86-mode AND real-mode?

Hey you Cheapo , I made some further tests. I tried all modes AHCI/RAID/IDE with and without UDMA.SYS. BTW I was surprised that even AHCI and RAID modes are still working in DOS, I though it's some kinda windoze or "need a driver" only.

Another surprise that in RAID mode I reached much higher speed without UDMA.SYS (but then UDMA.SYS cannot be used because don't understand the controller):

Writting average speed: 13.992 MB/s
Reading average speed: 31.270 MB/s

It's probably due to RAID BIOS ROM module with its own INT13h services is loaded instead built-in standard one and it uses DMA. It works also with JEMM.
I got similar result with ITE8211 under DOS. But who wants to let useless RAID BIOS to occupy UMB? Rather use smaller UDMA.SYS and IDE mode.

BTW I also did some benchmark with HDTune under XP and found that AHCI SATAII mode brings only very very small performance gain over IDE mode, in both cases I got ~85MB/s.

---
DOS gives me freedom to unlimited HW access.