VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 40 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Well, the 512MB limitation was imposed by the BIOS, not the IDE controller.
The 16-head limitation is caused by the IDE controller, however in CHS mode the sector field is 8 bits and the track field 16 bits.

So in CHS the drive could max out at C/H/S 65536/16/256 but then you would have problems with the INT 13h interface, so drives limit the sectors per track at 63. Finally, tracks are limited to 16384 for large drives for some reason.

I do know from experience that some REALLY OLD ide hard disks only decode 10 bits of the track field, but you'd have to go way back to ancient 50MB and 100MB drives to see that at all.

Reply 41 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

http://jon.nerdgrounds.com/doslib/1411/

IDE test program:
- CD-ROM read testing has been thoroughly tested and rewritten to work properly with all CD/DVD-ROM drives available for testing. The CD-ROM read test is now able to function properly in single-sector and multi-sector read modes on all test machines. It involves some rather funky details with the IDE ATAPI PACKET command that are not well documented, to carry out properly. read the source code comments for more details.
- A few bugs and typos were corrected in the hard disk read/write tests, one of which failed to actually use the LBA48 versions of the read/write commands when the menu implied that it did.
- A menu was added to allow for playing with the ATA "write uncorrectable sector" command. I have not yet found an IDE drive that implements the command, so I don't know if it works.
- ATA media lock/unlock/eject commands were added to the menu. But of course, none of the CD/DVD-ROM drives I've tested it on actually implement it. Go figure.

If you have some spare hardware with a hard disk who's contents you don't care about, feel free to test this program on it and let me know if you find any problems. What I've developed so far is now enough test code that I can begin adding IDE emulation to DOSBox.

Reply 42 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

DOSBox-x branch update:

Basic IDE emulation added. There is code for both ATA (hard disk) and ATAPI (CD-ROM) emulation. The ATA disk emulation does not fully work yet. ATAPI emulation is enough to satisfy MSCDEX.EXE and the OAK CD-ROM driver I have in the VM. For whatever reason, Windows 95 currently ignores the devices (I see it emit IDENTIFY DEVICE and then boot up without further conversation). There is debugging code active, prepare to see your console fill up with "ATAPI command" debug info when using the CD-ROM drive.

How to enable the emulation.

Add to your dosbox.conf:

[ide, primary]
enable=true

[ide, secondary]
enable=true

(and so on for 3rd and 4th controller if you like)

For ease of use I wrote the IDE emulation to tie into DOSBox's INT 13h and MSCDEX.EXE CD-ROM code and through the "imgmount" command. The way it's written now, if you use imgmount to attach hard drives or CD-ROM drives the command will automatically also attach it also to the IDE emulation as ATA and ATAPI device respectively. I added a "-ide" switch that allows you to specify exactly which IDE port to attach it to:

-ide 1m - Attach to primary IDE controller as master
-ide 1s - Attach to primary IDE controller as slave
-ide 2m - Attach to secondary IDE controller as master
-ide 2s - Attach to secondary IDE controller as slave
-ide auto - Attach to unused slot (default)
-ide none - Do not attach to IDE port

In my test environment, I boot to windows 95 like this:

[autoexec]
# floppy disk from DOSlib test code by ./make.sh and ./make.sh disk
imgmount 0 "/usr/src/dos/hw/ide/test.dsk" -t floppy -fs none
# C: drive for Win95
imgmount 2 "drive_c.hdd" -size 512,63,64,1023 -t hdd -fs none -ide 1m
# D: drive with Windows 95 install CD-ROM
imgmount 3 "win95-install-cdrom.iso" -t iso -fs iso -ide 2m
# Now start Win95
boot -l c

The emulation is enough to permit using OAKCDROM.SYS and MSCDEX.EXE to install Windows 95 straight from the CD-ROM drive. As usual, make sure you don't have S3 VGA enabled. Currently Windows 95 installs correctly, but will fall back on "MS-DOS compatibility mode" to talk to the hard disk using INT 13h and MSCDEX.EXE for CD-ROM access. But it's enough now that you can at least run and install things from CD-ROM in Win95.

The DOSlib source code has been updated to allow you to experiment with some ATAPI CD-ROM commands. The device reset now shows you the IDE registers after reset so you can see for yourself some of the "magic bytes" that ATAPI devices show to identify themselves.

Enjoy!

DOSBox-x
http://jon.nerdgrounds.com/dosbox-x/108

DOSlib
http://jon.nerdgrounds.com/doslib/1413

Reply 46 of 2397, by dosmax

User metadata
Rank Newbie
Rank
Newbie

A little hint for everyone else who wants to try this out: The above dosbox.conf [autoexec] section isn't entirely correct. The CD-ROM has to be mounted with a drive letter as first parameter like usual, not with the bus number. At least for me using the win32 build 😉 . Otherwise oakcdrom.sys (or any other CD-ROM driver I tried) refuses to find a drive.

My working [autoexec] section looks like this:

[autoexec]
# floppy disk from DOSlib test code by ./make.sh and ./make.sh disk imgmount 0 "path_to_floppyimage\disk.ima" -t floppy -fs none
# C: drive for Win95
imgmount 2 "path_to_hdd_image\hdd.img" -size 512,63,32,512 -t hdd -fs none -ide 1m
# D: drive with Windows 95 install CD-ROM
imgmount D "path_to_cd_image\cd.iso" -t iso -fs iso -ide 2m
# Now start Win95
boot -l c

On a sidenote: this looks very, very promising. A more than useful addition to Dosbox!

Last edited by dosmax on 2012-05-08, 23:57. Edited 1 time in total.

Reply 47 of 2397, by mr_bigmouth_502

User metadata
Rank Oldbie
Rank
Oldbie

I just wonder though, will this work with Win98? I don't actually have a copy of 95. 🤣 I know that 95 will probably work better, but I'm just wondering.

Reply 48 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
mr_bigmouth_502 wrote:

I just wonder though, will this work with Win98? I don't actually have a copy of 95. 🤣 I know that 95 will probably work better, but I'm just wondering.

Have you tried the P***** Bay? 😉 Well plenty of people had their copy up the last time I checked. The copies I test from though are actual CD-ROM copies that were legitimately bought back in the day, don't worry 😀

Anyway, I managed to get Windows 98 to boot in DOSBox-X. Unless you have core=dynamic and cputype=486_slow and more than 24MB of RAM in the DOS Box, Windows 98 will crash at random inside DOSBox. Windows 98 SE has the same problem if you have less than 32MB of RAM.

To answer your question, Windows 98/98SE treats my ATA/ATAPI emulation the same way Windows 95 does: CD-ROM emulation works, and (for whatever bizarre reason) IDE hard drives are completely ignored. And where Windows 95 flags the IDE controller as malfunctioning when hard disks are attached, Windows 98SE just flat outright ignores the IDE controller. There are some pretty rude comments in the latest revision of the DOSBox-x source code over these shenanigans, I'll give you fair warning 😀

Last edited by TheGreatCodeholio on 2012-05-10, 01:53. Edited 1 time in total.

Reply 49 of 2397, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Please don't point at the bay

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 50 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:

Please don't point at the bay

I was just joking about it. I don't recommend getting it from the bay either 😀

Reply 51 of 2397, by Joey_sw

User metadata
Rank Oldbie
Rank
Oldbie

unpatched win9x has weird 28 bits LBA, instead of full 48 bits.
is your LBA implementation support the 28 bits mode that win9x uses?

all these years, i'm curious why win9x choose to works with 28 bits LBA?
on real life, unpatched win9x might having trouble with HDD with more than 2^28 sectors.
MS never release any patch for this matter, probably to force win9x users to migrate to NT5 (one of MS infamous forced obselescene tricks?).

-fffuuu

Reply 52 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Joey_sw wrote:
unpatched win9x has weird 28 bits LBA, instead of full 48 bits. is your LBA implementation support the 28 bits mode that win9x u […]
Show full quote

unpatched win9x has weird 28 bits LBA, instead of full 48 bits.
is your LBA implementation support the 28 bits mode that win9x uses?

all these years, i'm curious why win9x choose to works with 28 bits LBA?
on real life, unpatched win9x might having trouble with HDD with more than 2^28 sectors.
MS never release any patch for this matter, probably to force win9x users to migrate to NT5 (one of MS infamous forced obselescene tricks?).

So far the ATA mode is 28 bits. I have the code written to eventually support LBA48, which is why the registers in the IDEDevice base class are 16-bit wide, not 8. Windows 95/98/ME as far as I know don't implement LBA48, Windows 2000 does (with a service pack).

The way DOSBox is written right now, it can't handle hard disk images 2GB or larger (using fseek on 32-bit systems where integers are involved----planning on rewriting that part to remove the limit), so there's not yet any point to adding LBA48.

The problem is that for whatever reason, I see Windows 95 carry out a DEVICE RESET (08h) then an IDENTIFY DEVICE, and then I see no more communication by Windows 95 to the hard disk. Or, if DOSBox's CMOS emulation convinces Windows 95 that there are hard drives, I see Windows 95 do a device reset, then issue a C/H/S read to track=0, head=0, sector=1, and then Window 95 turns around and claims the IDE controller is bad. I have absolutely no idea what malice Windows 95 could ever read from a successful 512-byte read from the boot sector to claim bullshit like that. I have both CHS and LBA READ commands implemented. Since Windows 95 fails to attempt any other commands, those commands are all the only ones implemented so far. In other words, Windows 95 isn't even TRYING to talk to the hard drive directly. All I know so far is that the test IDE program I wrote is able to work with it.

Reply 53 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Joey_sw wrote:
unpatched win9x has weird 28 bits LBA, instead of full 48 bits. is your LBA implementation support the 28 bits mode that win9x u […]
Show full quote

unpatched win9x has weird 28 bits LBA, instead of full 48 bits.
is your LBA implementation support the 28 bits mode that win9x uses?

all these years, i'm curious why win9x choose to works with 28 bits LBA?
on real life, unpatched win9x might having trouble with HDD with more than 2^28 sectors.
MS never release any patch for this matter, probably to force win9x users to migrate to NT5 (one of MS infamous forced obselescene tricks?).

You also have to understand that LBA48 was not standardized until ATA-6 in 2000. Since Windows 98 pre-dates the ATA-6 standard it makes sense they do not support the LBA48 mode. It is possible though to use a third party driver that does support LBA48.

Reply 55 of 2397, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

Didn't someone post a link to How To Please WDCTRL a while back? Of course, that's regarding 32-bit disk access in Windows 3.1, but maybe some of the wackiness involved held over to Windows 95. (Maybe a C/H/S read to 0,0,1 immediately following a device reset is supposed to fail or something.)

Reply 58 of 2397, by Joey_sw

User metadata
Rank Oldbie
Rank
Oldbie

coincidently, the esdi_506.pdr is the file that unofficialy patched to allow LBA48 under win9x without using 3rd party drivers.

probably esdi_506.pdr requires certain handshake to determine if the IDE controller is OK.

how about using 3rd party dirvers like Intel AA, would it still saying the the IDE controller implementation is 'bad' ?

When i use IAA in real win98SE, the hardware manager doesn't report that esdi_506.pdr being used.

-fffuuu