TheGreatCodeholio wrote:

I am releasing the latest revision (build 1392) of the DOS source code library. This fixes some issues I found while testing the […]
Show full quote

I am releasing the latest revision (build 1392) of the DOS source code library. This fixes some issues I found while testing the source code against some new scenarios and while filming the code running on various hardware (I will be releasing a video when I have time on the 8042 keyboard controller and how it works, and what the DOS source code library does to interact with it).

http://jon.nerdgrounds.com/dosbox-x/1392/

Additions to the library:
- DOS "flavor" detection. The library is able to detect MS-DOS vs FreeDOS
- If FreeDOS, the code is able to obtain the kernel revision and revision string
- VGA library now contains detection for Amstrad 640x200x16 graphics mode and corresponding test program.

Bug fixes: 8042 keyboard library/test program
- The PS/2 mouse main menu no longer reprints the menu text on EVERY keypress. But if it scrolls off-screen, you can force a reprint by pressing "space"
- Exiting the PS/2 mouse menu now forces the 8042 to drain it's output. This resolves issues with an unresponsive keyboard when exiting the PS/2 mouse menu.

Bug fixes: DOS library
- Fixed 16-bit builds not detecting HIMEM.SYS when HIMEM.SYS is obviously loaded in memory.
- DOSBox and VirtualBox detection code seems to cause mystery GPF fault and DOS32a brainfuck when 32-bit builds are run under FreeDOS 1.0 (kernel version 0.0.36), code has been updated NOT to scan if that particular FreeDOS kernel is detected. FreeDOS 1.1 doesn't have this problem.

Bug fixes: Sound Blaster library
- The latest changes to the DOS library made building the 16-bit "compact" memory model version of the TEST program impossible (more than 64KB of code), the makefile has been modified to not compile the dos86c build.

Bug fixes: VGA library
- Direct linking within the makefile caused Watcom to produce a 386 32-bit binary that did NOT link properly to the C runtime and was effectively unusable. Rewritten to use wlink instead, like all other projects. FIXED.

Cleanup:
- All make files have been cleaned up and dependencies rewritten in a cleaner manner.

Additional code checked:
- Under "misc" the hexmem program (a program for browsing the contents of your computer's memory) has been updated to use the LLMEM library. This means that if you have a recent processor and your motherboard supports 4GB of RAM or more, you can look at memory at or above the 4GB memory boundary from DOS! The code has also been updated to enforce physical memory limits reported by CPUID to avoid crashes, as some CPUs (especially Intel Atom CPUs) will trigger a fault if you attempt to read beyond the limit. (obviously, you must be running in pure DOS mode with or without EMM386.EXE as such techniques are invalid within a Windows DOS box).

Have fun!

I'm confused. Are you running FreeDOS in DOSBox, or the other way around?

I'm also confused... Dosbox changes or what is "DOS source code library"?

From the readme included with the package:

This is a collection of source code intended for DOS and DOS-level use. It is intended to be used in other open source projects […]
Show full quote

This is a collection of source code intended for DOS and DOS-level
use. It is intended to be used in other open source projects as well
as a learning tool for programmers who may want to learn hardware
level programming and low level details of the MS-DOS PC platform.

This code is designed to work with almost any commodity IBM PC/XT/AT/etc.
hardware out there, though most of it is written primarily to work with
mid 1990's Pentium-class hardware, or older, all the way down to the
original 8088-based PCs.

Each major branch of this source tree has a README file to describe
exactly what is provided.

Errrrr.... you're right. Why did I put it under a subfolder named "dosbox-x"? I should have created a folder named "doslib" and put it under there.

It was 4 in the morning when I posted that... sorry for the confusion.

So far all FreeDOS testing is carried out within VirtualBox or on real hardware using a "Linux on a stick" USB pen drive. I can definitely say that FreeDOS 1.0 has it's share of weird quirks and components that don't work correctly. You wouldn't want to use LBACACHE under VirtualBox for example, unless you want stack overflow messages and random crashes just by typing "DIR" 😀 But I've never run FreeDOS under DOSBox before.

Wouldn't testing under Bochs be more useful than testing under VirtualBox or DOSBox? (Of course, if you want the code for the explicit purposes of doing something under VirtualBox, that's a different matter.)

Anyway, maybe we should split this thread..?

TheGreatCodeholio wrote:

Too late already started :) I've written low-level C and ASM code to work with IDE controllers before, so I have a fairly accura […]
Show full quote

Qbix wrote:

Don't bother with IDE emulation. That would be double work as that has been written before.
The tools you are writing sound pretty interesting.

Too late already started 😀 I've written low-level C and ASM code to work with IDE controllers before, so I have a fairly accurate idea what I/O and interrupt with them is like. The basic communication is easy, write the registers with the sector/head/etc. and command and wait for the controller to signal completion, wait for interrupt, transfer data as 16-bit reads/writes through the data port. Some other aspects like hard drive DMA are a little more difficult.

The only gotcha with IDE controller programming is that there is a lot of hardware out there with bugs in their IDE controller and quite a bit of variation. I know of one laptop for example, an old P66 laptop, who's IDE controller could hang the entire laptop if my code polled the IDE controller status bits too fast (the fix apparently was to halt and wait for interrupt).

If I have some spare time I might also add floppy controller emulation too.

I'm glad you're interested in the DOS reference code, I hope it serves as an example on how to write DOS programs. I will release the code on this forum when I'm ready.

Sweet. 😁 Maybe we'll finally get CDROM support under Win95! 😁 I understand that a lot of people would prefer to use VirtualPC or whatever for this sort of thing, but I myself prefer DosBox just because it's less bloated and better suited for gaming in general.

you can install daemon tools in dosbox for cdrom support in win95/98/Me

And how do you propose doing that during the install phase of Windows 95? Their installer doesn't exactly have a full Win32 environment open during the initial setup phase to run daemon tools 😀

In fact I once picked it apart to find that the installer is basically a Win16 app and the DOS stub runs it by creating a mini-Windows 3.1 installation somewhere on the hard drive. The files to do that are packed away in one of the CAB files---MINIWIN.CAB I think it's named.

Another reason for IDE emulation is that Windows 95 can talk directly to the IDE controller without having to use "DOS compatibility mode" i.e. thunking down to 16-bit virtual 8086 mode to call INT 13h for disk I/O. That might resolve some stability issues right there, and it enables CD-ROM access at the same time.

The final reason, is that I plan to add code to the DOS source library that demonstrates how to program the IDE controller.

TheGreatCodeholio wrote:

And how do you propose doing that during the install phase of Windows 95? Their installer doesn't exactly have a full Win32 environment open during the initial setup phase to run daemon tools 😀

You copy winsetup folder with content from cd to hdd and install from hdd.

I have plenty of reasons I want to use DOSBox's code base:

- VirtualBox: It's nice, it's (somewhat) user friendly, but compiling from source code is a F***ing pain in the ass not to mention a good half-hour compile. As it is, I have to be using specific versions of the Linux kernel to use it and can only use it on 32-bit Linux builds because the x86-64 build demands the 32-bit C library (which my homebrew Linux distro is unable to provide). I also know from programming experience that in the interest of getting things working VirtualBox makes no attempt at accuracy, only at emulating the hardware interfaces. If you wrote legacy DOS code against VirtualBox, you would be left with many false impressions that would probably break your code on actual hardware.

- QEMU: It works well enough. It does a great job running DOS and Windows all the way up to XP. I can compile it easily enough. Accuracy though is not it's strong point---again it only emulates the hardware I/O well enough to run the OS, and even then there are holes such as the bizarre problems QEMU floppy controller emulation has with Windows 95 and Windows 98.

- Bochs: I can see they have some very good CPU emulation code in there. Some of my first assembly language experiments with switching the processor into 64-bit long mode were debugged under Bochs when x86-64 emulation was added. When it comes to hardware accuracy though, it's not too good. Sound Blaster emulation is terrible. It's fast enough to run Windows 3.1 and Windows 95 comfortably enough but too slow for anything later.

- Microsoft Virtual PC: It's closed source. Emulation is OK. I lost this as an option though when I recently dumped Windows XP and switched to using Linux exclusively for my desktop. It doesn't work if you try running VPC under Windows XP inside VirtualBox, some conflict exists between them. I was also very unhappy with the way Windows 7 Ultimate dumbed down Virtual PC and essentially replaced the screen with a sort of forced "Windows XP over Remote Desktop" user experience. Yeah you can forcibly replace Ultimate's VPC with an actual usable one, if you're willing to ignore warnings about how doing so will is "incompatible with your system" (yeah MY ASS Microsoft).

Here's what DOSBox has that the others don't have:
- Accuracy in hardware. I can see a lot of thought has been put into making DOSBox accurately emulate the hardware where it matters to DOS games. The event-driven design I see in the code base helps a lot. DOSBox is the only emulator I've dealt with that can accurately emulate the VGA raster scan and refresh rate.
- Easy configurability. It's all in dosbox.conf. You can switch out CPU cores, display/machine emulation, and sound card emulation. DOSBox is the only emulator I know of that provides accurate Sound Blaster emulation AND allows you to select which of the Sound Blaster cards you want to use (while most emulators are stuck emulating a Pro or SB16 with obvious shortcuts in their code).
- Command prompt emulation AND emulation of a full OS boot. If I want to test and write DOS programs I have to deal with copying the code to test onto a bootable floppy and booting the virtual machine. With DOSBox I can do that, but I can also just mount the folder and run it directly.
- Easy to compile. It doesn't require my quad-core box to grind through it's source code for half an hour just to compile. It doesn't require me to compile 40MB or more of source code.
- Recording function. I'd like to see VirtualBox and QEMU do THAT with the same accuracy as DOSBox 😀 Ha!

Still think I should be using Bochs for my programming projects, then?

robertmo wrote:

TheGreatCodeholio wrote:

And how do you propose doing that during the install phase of Windows 95? Their installer doesn't exactly have a full Win32 environment open during the initial setup phase to run daemon tools 😀

You copy winsetup folder with content from cd to hdd and install from hdd.

I know, that's what I've been doing. My point is that Daemon Tools probably doesn't work during the install phase of Windows 95.

It's just that having to imgmount the hard drive, imgmount the ISO, copy onto the hard drive, unmount, then boot and install is kind of clumsy. I'd rather have the ability to imgmount drive #2 the hard drive and imgmount an ISO to drive #3 and then let Windows 95 install the way it would on actual hardware.

And then when Windows 95 is up and running, I'd like to be able to use the CD-ROM emulation to imgmount my copy of Red Alert and run the Windows 95 version straight off the ISO 😀

Bochs is just the standard recommendation if you require a better hardware emulation than Dosbox provides. Except the gaming relevant stuff like graphics card and soundblaster of course (as you wrote) 😉
CPU stuff is supposed to be more accurate with Bochs AFAIK.

I wouldn't mind a working CD emulation for Windows 9x for all the Windows9x games that require a CD... Mostly because I'm so happy with Dosbox for games 😉
Wine and Virtual Something doesn't cut it for me...

TheGreatCodeholio wrote:

It's just that having to imgmount the hard drive, imgmount the ISO, copy onto the hard drive, unmount, then boot and install is kind of clumsy. I'd rather have the ability to imgmount drive #2 the hard drive and imgmount an ISO to drive #3 and then let Windows 95 install the way it would on actual hardware.

I think you don't have to unmount.
Also it is always easier to copy files to image in some image editor, not in dosbox.
Anyway it is better to have it more like this:
one hdd image for C and second hdd image for D with winsetup folder.
Unlike WinXP, Win95 doesn't copy all its files to C during installation so it often asks for a cd(or location of winsetup files) when you want to install new drivers, new programs, etc. Sometimes it asks many times for the same thing (driver location, winsetup location, again driver location...). If you have winsetup folder in the same place you had during installation, it won't even ask you for the location of folder, it will just install everything without you knowing about it if you doesn't watch monitor closely. And that is what is definitely not clumsy compared to other ways 😀

Dominus wrote:

Bochs is just the standard recommendation if you require a better hardware emulation than Dosbox provides. Except the gaming rel […]
Show full quote

Bochs is just the standard recommendation if you require a better hardware emulation than Dosbox provides. Except the gaming relevant stuff like graphics card and soundblaster of course (as you wrote) 😉
CPU stuff is supposed to be more accurate with Bochs AFAIK.

I wouldn't mind a working CD emulation for Windows 9x for all the Windows9x games that require a CD... Mostly because I'm so happy with Dosbox for games 😉
Wine and Virtual Something doesn't cut it for me...

My thoughts exactly. Despite Bochs' overall better accuracy, it doesn't have the same sound or graphics capabilities that DosBox does, so if DosBox had working CDROM emulation under Win95, it would be quite awesome. 😁

I'd enjoy this IDE CDROM patch very much too! (when done). :yay!:

Dark Side of the Moon (6 discs) seems to be made for Win9x only. I'm sure Daemon Tools would be able to handle the disc swaps but it'd be more convenient to swap out native ISOs (rather than create a 4-8 GB FAT32 image to store the copy).

Tex Murphy Overseer (DVD) + Obsidian (5 disc homebrew -> DVD) take a lot of space too. I think I've got enough 3-5 disc games laying around here somewhere. :heh:

I'm glad there's DOS enthusiasts / specialists still around who know how the hardware is exactly supposed to work. 😉

DOS library build 1401.

Preliminary new code: hw/ide, IDE ATA/ATAPI test code. The preliminary code demonstrates how to detect the IDE controller and issue common commands to both hard disk and CD-ROM drives. It probably won't work 100% reliably on some hardware. So far though it is able to toy with the hard disk and eject/load/start/stop and read-test from the CD-ROM drive.

The IDE test program is part of the development process that will lead to working IDE emulation in DOS Box. The idea is to use the test program to take note of any and all quirks seen on real hardware so that the DOSBox-x emulation will be more realistic.

The program shows a prominent warning at the top of the screen. Please heed it: do not run the program on your computer if you value the hard drive's contents. It won't make the HDD explode or anything (that's impossible) but it could erase or overwrite data on the drive. You have been warned.

For best testing boot from a floppy disk or USB pen drive and test against a hard disk who's contents you don't care about.

The code only works with the ATA IDE interface. It will not work against the Serial ATA controller on newer hardware unless you configured your BIOS to emulate IDE from SATA.

Also: Minor updates to 8254 timer and 8250 PIC code. Cosmetic changes to hw/dos to work around bizarre Watcom C complaints about integer constant truncation.

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

Enjoy.

mr_bigmouth_502 wrote:

My thoughts exactly. Despite Bochs' overall better accuracy, it doesn't have the same sound or graphics capabilities that DosBox does

Gee. It kind of makes me wonder if anyone somewhere has looked into sticking the DOSBox SB emulation code into Bochs somehow. (It's probably not a priority for them.)

doslib release 1404

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

IDE test program updates:
- Hard disk read/write tests. Write tests include a big scary warning making it clear the test will erase whatever is on their hard disk
- HDD Read/Write tests demonstrate C/H/S, LBA, and LBA48 modes
- LBA48 test makes sure to read sector 0 and sector 0x1000000 to ensure LBA48 command method is latching upper and lower 8 bits of count/LBA
- Added flags to allow either polling-only or IRQ driven IDE command & response communication.
- "Sleep" command is now aware of the fact that drive will not signal "drive ready" until given a command to wake the device
- "Device reset' command acknowledges that the device may NOT fire an IRQ in response.
- Code confirmed to work properly on four test laptops:
1. Toshiba satellite pro with 2GB IDE, CD-ROM drive, Pentium Pro MMX CPU
2. Toshiba satellite pro with 80GB IDE drive and CD/DVD-ROM drive, Pentium 4.
3. Sagar laptop with 512MB IDE hard disk. The hard-lockup observed does not happen until the code attempts to read beyond the end of the hard drive? (hard disk stops responding). Pentium 90MHz
4. Fujitsu laptop with 40GB hard drive (which I had replaced with a 4GB CompactFlash card in an IDE-CF adapter) and CD/DVD-ROM drive. Pentium 4.

some old harddisk controller incapable accessing more than 16 heads in CHS mode.
That would lead to strange 512MB limitation.

a bit off topic:
Interrestingly, disk-images crated by bochs' bximage, also limit itself to max 16 heads (0 to 15).
And that usualy resulting many complaining that dosbox formating the wrong size, if the diskimage size were > 512 MB.