I'm not that experienced with dos and learning as i go, are there any good utils or ways to show what program/rom/software is using conventional memory regions. Even a way in DOS to copy the first megabyte region of memory (0kb - 1024kb) to a file and examine it in a hex editor.
Like I said, I'm pretty sure debug is supposed to do that. (debug.com is a standard component of MS-DOS.) I'm just not sure what the syntax is.
I'm not that experienced with dos and learning as i go, are there any good utils or ways to show what program/rom/software is using conventional memory regions. Even a way in DOS to copy the first megabyte region of memory (0kb - 1024kb) to a file and examine it in a hex editor.
The conventional memory always starts at segment 0000 and has no holes, so it's easy to tell what region of memory is missing: It's the last 8 Kilobytes, that is 9E00:0..9E00:2000 (aka A000:0). If that memory is missing on a clean boot from floppy, it's unlikely a virus is taking up that memory. Also if you don't have any expansion cards installed (except for the graphics card), it's unlikely any of expansion card reserves 8K of conventional memory. I never heard of VGA cards doing that kind of stuff. So the by far most likely culprit is the mainboard BIOS itself, which might create an "extended BIOS data area" at that address. 8KB is unusually big, though. Typically, PS/2 mouse support needs the presence of an EBDA, but most BIOSes only reserve 1KB (that's the minimum amount). Another reasons for the BIOS to create an EBDA is that it wants to store other dynamic data (like hard drive parameters). BIOSes of that time usually patch themself in shadow RAM, so they don't need extra RAM for that. Some years earlier, you could lose some conventional memory when you disabled BIOS shadowing, but your board seems to be new enough that the BIOS itself is compressed inside the flash chip, and unpacks itself into shadow RAM, so it's impossible to run without BIOS shadowing.
To dump the last 8KB, try using Debug
1C:\>debug 2-d9E00:0 39E00:0000 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF .."3DUfw ........ 49E00:0010 ... 5 6-rcx 7CX=0000 82000 9-nLAST8K.BIN 10-w9E00:0 112000 bytes from 9E00:0 written to LAST8K.BIN 12-q
(debug dialog written from memory, might vary slightly in practice). Use "d" to dump memory to screen. You can continue the dump using "d" without an address. Use "w" to write to a file. The file size must be stored in CX (and BX if it is above 64KB), so use "rcx" before writing to set the size to 8 Kilobytes, which is 2000 in hex.
You can also use DosZip to browse the entire 1 megabyte of address space. Select File -> Memory Info from the menu, then just hit enter on any if the entries in the window. This allows you to browse the memory contents like a file, either in HEX mode or ASCII mode. Use the seek command to jump to a specific memory address.
I'm not that experienced with dos and learning as i go, are there any good utils or ways to show what program/rom/software is using conventional memory regions. Even a way in DOS to copy the first megabyte region of memory (0kb - 1024kb) to a file and examine it in a hex editor.
To dump the last 8KB, try using Debug
1C:\>debug 2-d9E00:0 39E00:0000 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF .."3DUfw ........ 49E00:0010 ... 5 6-rcx 7CX=0000 82000 9-nLAST8K.BIN 10-w9E00:0 112000 bytes from 9E00:0 written to LAST8K.BIN 12-q
(debug dialog written from memory, might vary slightly in practice). Use "d" to dump memory to screen. You can continue the dump using "d" without an address. Use "w" to write to a file. The file size must be stored in CX (and BX if it is above 64KB), so use "rcx" before writing to set the size to 8 Kilobytes, which is 2000 in hex.
I attached the file of the last 8kb of conventional memory. It seems to be 1KB EBDA repeated 8 times. Have no idea what it is, only that this board using a 430fx chipset has MW-DMA2 enabled without any driver loaded in real mode DOS (that can't disabled or enabled in bios).
I attached the file of the last 8kb of conventional memory. It seems to be 1KB EBDA repeated 8 times. Have no idea what it is, only that this board using a 430fx chipset has MW-DMA2 enabled without any driver loaded in real mode DOS (that can't disabled or enabled in bios).
1KB EBDA is normal on this kind of board. The EBDA "extended BIOS data area" is a memory area reserved by the BIOS to store data that goes beyond the data the original AT and EGA BIOS stored in the standard BIOS data area at the low end of the memory. The PS/2 mouse support in normal PC BIOS implementations stores the address of the mouse driver and the packet size of the mouse at that location, so if PS/2 mouse support is enabled (and a mouse connected) you usually get one(!) copy of the EBDA, and the conventional memory available to DOS is reduced to 639KB. 8 copies is definitely not normal. Do you have any extension cards, especially ones that support booting, installed? I'm mostly thinking about UDMA33 IDE controllers and network cards. There might be compatibility problems between boot-capable extension cards and your mainboard BIOS.
On usual 430FX boards, selecting MW-DMA2 does not make the BIOS use DMA for IDE transfers. But it configures the drive and the chipset to use MW-DMA2, so as soon as a DMA-capable driver is loaded, it can start using MW-DMA2 without needing to configure anything.
I believe I had a DOS laptop that did similar. Or was it a Win98SE tower? Maybe BIOS is loading some data there? BTW, I just noticed your last thread. I don't know what could be causing that. Try a tool that can write to that memory and see what happens.
Joseph Rose, a.k.a. Harry Potter
Working magic in the computer community
I attached the file of the last 8kb of conventional memory. It seems to be 1KB EBDA repeated 8 times. Have no idea what it is, only that this board using a 430fx chipset has MW-DMA2 enabled without any driver loaded in real mode DOS (that can't disabled or enabled in bios).
On usual 430FX boards, selecting MW-DMA2 does not make the BIOS use DMA for IDE transfers. But it configures the drive and the chipset to use MW-DMA2, so as soon as a DMA-capable driver is loaded, it can start using MW-DMA2 without needing to configure anything.
It is a setting called "PCI IDE BUSMASTER" in the bios menu. I have only seen it on AMI bioses, never on an Award bios. When you enable it, DMA mode is enabled on the onboard ide controller on the 430FX chipset. I don't think many people realize or know about this feature. It means in realmode dos you get dma without any dos driver (like triones) needed and even in Dos makes a noticeable difference in Quake 1 when loading sections between levels.
For example in Norton Ghost run from real mode dos, with PIO mode 4 using an SSD I get 328MB / a minute backing up. With PCI-IDE BUSMASTER enabled I get 959MB a minute.
In Win98 you get DMA ide transfers in safe mode and normal mode without any driver loaded or the tick box in device manager.
Difference is huge with an SSD. In PIO-4 mode on this motherboard I get 6-7MB max and around 90-99% cpu usage in Win98 when copying files. With PCI IDE Busmaster in bios enabled it uses MW-DMA2, constant 16MB/S and only 2-3% cpu usage copying files.
It is a bios driver that is loaded (like USB drive emulation in later bioses etc). https://www.techarp.com/bios-guide/ide-bus-master-support/
I presume it's loaded somewhere in conventional memory because when I enable this option in bios my memory is reduced by a further 1KB. I think this memory location could be copied from memory to a file and maybe this driver added as a module to award bioses with the 430fx or HX chipset.
It is a setting called "PCI IDE BUSMASTER" in the bios menu. I have only seen it on AMI bioses, never on an Award bios. When you enable it, DMA mode is enabled on the onboard ide controller on the 430FX chipset. I don't think many people realize or know about this feature. It means in realmode dos you get dma without any dos driver (like triones) needed and even in Dos makes a noticeable difference in Quake 1 when loading sections between levels.
Sounds like it is establishing double buffering so that they have a known memory region that will remain 1:1 mapped between virtual and physical addresses even if you end up loading something like EMM386.
Device=smartdrv.exe /double_buffer in DOS 6 (http://ps-2.kev009.com/pcpartnerinfo/ctstips/c932.htm) or dblbuff.sys in Win9x (http://manmrk.net/tutorials/DOS/msdos7/dblbuff.htm) does something similar. But in your case it's the BIOS itself, and the only way it can reserve that memory is to subtract it from the total conventional memory before DOS launches. If your BIOS failed to do this, you'd likely have to use one of these options instead.
Riikcakirdswrote on 2023-09-09, 20:04:It is a setting called "PCI IDE BUSMASTER" in the bios menu. I have only seen it on AMI bioses, never on an Award bios.
When you […] Show full quote
On usual 430FX boards, selecting MW-DMA2 does not make the BIOS use DMA for IDE transfers. But it configures the drive and the chipset to use MW-DMA2, so as soon as a DMA-capable driver is loaded, it can start using MW-DMA2 without needing to configure anything.
It is a setting called "PCI IDE BUSMASTER" in the bios menu. I have only seen it on AMI bioses, never on an Award bios.
When you enable it, DMA mode is enabled on the onboard ide controller on the 430FX chipset. I don't think many people realize or know about this feature. It means in realmode dos you get dma without any dos driver (like triones) needed and even in Dos makes a noticeable difference in Quake 1 when loading sections between levels.
For example in Norton Ghost run from real mode dos, with PIO mode 4 using an SSD I get 328MB / a minute backing up. With PCI-IDE BUSMASTER enabled I get 959MB a minute.
Oh, thank for for pointing this out. The "usual 430FX boards" I was thinking of all had Award BIOSes, so this seems to be in fact an AMI-only feature. Too bad that AMI died - they seem to have got this right. I only knew about using DOS drivers like the Triones driver, or the open source UDMA.SYS / XDMA.SYS drivers.
In Win98 you get DMA ide transfers in safe mode and normal mode without any driver loaded or the tick box in device manager.
I immediately believe you regarding safe mode, because in safe mode, Windows 98 is doing exactly what DOS is doing. As you already tested, DOS gets busmaster DMA, so safe mode gets it, too.
On the other hand, when you use the "PCI busmaster IDE controller (dual FIFO)" drive (as you usually do in normal mode), the BIOS has no longer any control about what Windows 98 is doing. The Windows driver decides on its own whether it sets up the busmaster engine and runs the "READ DMA" command, or it does not set up the busmaster engine and runs the "READ" or "READ MULTIPLE" (for IDE block mode) command. As I understand it, there is just no way the BIOS can cause the driver to use the "DMA" code path without the tick box "DMA" in the device manager. So I suspect that possibly the "PCI busmaster IDE controller" fails the BIOS compatibility check if the BIOS uses DMA mode, and Windows falls back to use the BIOS to access the disk. While this gets you DMA, it is expected that performance is (slightly?) lower than a native 32-bit Windows driver that uses DMA.
