TheGreatCodeholio wrote:New DOSBox-X release! I found some free time this weekend, including time to setup a Windows 7 + VS 2008 workstation and produce […] Show full quote
New DOSBox-X release! I found some free time this weekend, including time to setup a Windows 7 + VS 2008 workstation and produce a Win32 binary.
- CMOS memory size bugfixes (when mem size is less than 1MB)
- Alternative DOS kernel, VGA BIOS, and UMB allocation support. When selected, the VGA BIOS can shrink down to 12KB, the DOSBox "private area" can move down to conventional memory, and it is now possible for conventional + upper memory to total 820KB. Alternative mapping includes moving DOS segments down as low as 0x50 like MS-DOS does.
- Linewise mode is now default
- PIT hacks for some older Demoscene programs
1. Impact Studio's "Legend" demo will run at half framerate, hack restores full framerate (programmers are using the PC speaker as a timer??)
2. Impact Studio's "Project Angel" has buggy PIT 0 timing that causes the demo to hang at startup, or run at half framerate, or run with VGA tearlines
- Flat Big Real Mode (real mode with 32-bit limits AND the "B" big bit set for the code segment), incorporated from another patch on this forums, which allows "Project Angel" to run
- Visual Studio 2008 Win32 project makefiles including incorporation of libraries ZLIB, libpng, SDL, and SDL-net.
- DOSBox's private area is configurable: you can set it's size, and decide whether it is in upper memory at 0xC800 (like mainline DOSBox does) or down in conventional memory
- Many minor fixes I've already forgotten about
Tested the new CDROM support through the latest ykhwong build and I must say I'm very impressed by the work that's been done. I tried running Pitfall by mounting a CD image with compressed audio tracks (OGG) and it worked great. Great job TheGreatCodeholio!
I'm also very pleased with the minimal Windows 95 installation procedure proposed by truth5678. I've always experienced loads of General Protection faults and BSDs with my installations of Windows 95 under DosBox, but the latest one is pretty much rock solid. Thanks a lot.
I can't get the Voodoo card or the 360 pad recognized (oddly, I get a second display adapter detected, but of course it doesn't work) but I assume that's a problem with the current ykhwong's build.
(oddly, I get a second display adapter detected, but of course it doesn't work) but I assume that's a problem with the current ykhwong's build.
FYI, I reported this problem to Taewong as well. The 2nd adapter will show up even if you install Win95 from scratch. It doesn't happen with the vanilla DOSBox-X build TheGreatCodeholio provided so it must have something to do with Taewong's build.
By the way, I finally got the Voodoo emulation working. I had to ask the Device Manager to list Devices by connection an then the missing PCI adapter showed up (and It allowed me to install the Voodoo driver correctly). Tried Grim Fandango in D3D mode and worked suprisingly great.
The pad was also easy to get working. Turns out it was perfectly explained on the Windows 95 installation guide (Windows 9x DOSBox Guide (Not officially supported)).
for some reason, the 32-bit CDROM access is fine on Win98 on DOSBox Daum but not the 32-bit Hard Disk driver and command.com gives a blank window and of course, switching Audio CDs is fine, but not for Data CDs.
Just sorry for my english.
Do not know where else to write, so I write here.
Discovered a problem in DOSBox-X version 20140125
When you shut down Win95, when parameter.conf "apmbios = fase", DOSBox-X does not close as it was in previous versions, but remains on the screen, "Now turn off your computer."
And when parameter "apmbios = 1",if DOSBox-X works in full screen mode, when you exit from Win95, DOSBox-X closed with error.
Yup. I found time this weekend to do some more work on DOSBox-X.
- CD-ROM media change emulation on CTRL+F4. Works so far with both MSCDEX.EXE in DOS mode and Windows 95, though in both cases you have to hit refresh or type DIR to re-enumerate the drive for changes to appear.
- More work has been done to reduce the minimum DOS memory limit. It is now possible to emulate a DOS machine with as little as 16KB, or even 8KB and 4KB in some cases, of system RAM. All issues preventing that have been fixed, as described below.
- Bug fixes to the COM/EXE loading functions. The code assumed that COM type executables could just set the stack pointer to the top of the 64KB segment, which is OK, except when emulating machines with less than 72KB of RAM, where that assumption puts the stack pointer out into unmapped RAM and causes crashes, even when you run DOSBox's internal commands.
- The "BOOT" command for technical reasons now disallows booting a guest OS if the emulated RAM is less than 32KB (booting an OS requires that there is RAM at 0x0000:0x7C00). I looked into reports of early IBM PCs shipping with 16KB of RAM, and it is documented that those systems had only the BASIC interpreter and no floppy drives to boot from, so that limit was not an issue. There are additional notes in the source of testing such low-memory emulation with PC-DOS 1.x and 2.x and how little you can boot them with.
1commit 8b61f6a86707f26cf50a731759a204a9cd2b5457 2Author: Jonathan Campbell <firstname.lastname@example.org> 3Date: Mon Mar 24 00:53:19 2014 -0700 4 5 IDE ATAPI CD-ROM media change complete. If I do a CTRL+F4 to change CDs, 6 MSCDEX.EXE is able to pick up that the media changed and show fresh 7 contents. Windows 95 is able to see the change (not automatically, but 8 if you hit F5 (refresh) after the change the contents reflect CD media 9 change). 10 11commit 10eb4326f18c876a01f90f57ac6301eb22af60c7 12Author: Jonathan Campbell <email@example.com> 13Date: Sun Mar 23 23:47:03 2014 -0700 14 15 IDE ATAPI CD-ROM drive emulation now emulated spin up/down times, delays 16 commands for spinup, and returns appropriate TEST UNIT READY and sense 17 data for media change and first spinup. Win95 is happy, at least. 18 19commit afe1d0d3ed74718336c2986a92536b8431cbe5ea 20Author: Jonathan Campbell <firstname.lastname@example.org> 21Date: Sun Mar 23 22:59:22 2014 -0700 22 23 OK. great. my timer tick functions work. modified code to print debug 24 message ONLY if the event is fired late. 25 26commit ee361cea0421698284f830dea9d23d20965cec89 27Author: Jonathan Campbell <email@example.com> 28Date: Sun Mar 23 20:50:10 2014 -0700 29 30 add TODO and comments so far on how much RAM is needed to boot various 31 versions of PC/MS-DOS. 32 33commit 4802c37c6eb20b3e38b903b6df54eb51f2d82ffb 34Author: Jonathan Campbell <firstname.lastname@example.org> 35Date: Sun Mar 23 20:26:55 2014 -0700 36 37 update code to lower minimum to 4KB. 38 39commit 8c76696489ae541b91bff86a008c48a543c470f7 40Author: Jonathan Campbell <email@example.com> 41Date: Sun Mar 23 20:23:09 2014 -0700 42 43 added sanity check for "mainline compatible mapping" to make sure that 44 8KB of RAM is present first. Without that check, mainline DOSBox's fixed 45 segment assignments would reach beyond available memory (if less than 46 8KB) and crash. added option to specify that DOSBox should allocate all 47 kernel structures in the UMB private area, leaving as much lower system 48 RAM available as possible. Doing this makes it possible to set memsize=4 49 (4KB) and run very small DOS programs. 50 51commit e77d349baa0063672d67454f0ef373244f71f556 52Author: Jonathan Campbell <firstname.lastname@example.org> 53Date: Sun Mar 23 20:03:45 2014 -0700 54 55 whoops. forgot dynamic allocation sanity check for when dynamic 56 allocation is on, and private pool is NOT stored in UMB 57 58commit b6dedd76a4495d093d974590839191fb69656336 59Author: Jonathan Campbell <email@example.com> 60Date: Sun Mar 23 19:57:14 2014 -0700
…Show last 104 lines
61 62 BOOT: some modifications to stack value on setup. change hard-coded 63 0x7C00 offset to variable that is set to 0x7C00. Add code to refuse 64 booting a guest OS if less than 32KB of RAM is being emulated (the IBM 65 PC boot process requires 32KB of RAM). added TODO where the user should 66 be able to override that lockout if they feel adventerous. 67 68commit 7d297b2b3bc781435ae3fd9f5eb3487be7757cc1 69Author: Jonathan Campbell <firstname.lastname@example.org> 70Date: Sun Mar 23 19:30:52 2014 -0700 71 72 bugfix: calculation needs to subtract one paragraph NOT one page. 73 74commit 05735c0807c841e3881a0c3336b9325733da5169 75Author: Jonathan Campbell <email@example.com> 76Date: Sun Mar 23 19:28:36 2014 -0700 77 78 BOOT: pick a more appropriate segment value than simply assuming 0x7000 79 to ensure that it points to RAM. Prior to this fix, SS could point to 80 unassigned RAM if less than about 500KB was allocated for emulation. 81 82commit 654758ea5f89cf0896f302e67994a84d877ca60c 83Author: Jonathan Campbell <firstname.lastname@example.org> 84Date: Sun Mar 23 19:01:05 2014 -0700 85 86 allow 8KB minimum after all. 87 88commit d57b8e9ea328f77d5cbe72f08dde4f75e08f406d 89Author: Jonathan Campbell <email@example.com> 90Date: Sun Mar 23 18:44:03 2014 -0700 91 92 add debug code to show private area vs assignment. modified initial 93 dynamic private allocation to subtract 1 paragraph from memory total, 94 because some parts of the emulation use that for UMB linkage. added code 95 to error out in non-dynamic case if there is insufficient room for the 96 private area. this fixes cases where random crashes could result from 97 memsizekb=16 and private area size=16384, for example. 98 99commit 8320c362368be03573062bdb032d36c5103dfba5 100Author: Jonathan Campbell <firstname.lastname@example.org> 101Date: Sun Mar 23 18:21:37 2014 -0700 102 103 fix up DOS execute function to dynamically choose COM stack pointer 104 value rather than assume 0xFFFE. The choice is based on the size of the 105 memory block allocated for the image, which means that if there's plenty 106 of RAM, then SP=0xFFFE anyway, BUT, if the memory block is smaller, the 107 stack pointer is assigned the largest value (minus 2) that fits within 108 the memory block. Doing this resolves the random crashes that occured 109 with most DOS programs, including DOSBox's builtin commands, when less 110 than 72KB of RAM was assigned. Because of this fix, it is now possible 111 to assign as little as 16KB of RAM and run without crashing. Programs 112 that still fit work fine. Programs that are too large silently fail. 113 Programs that can load, but cannot allocate the memory they need, error 114 out fine without crashing. 115 116 Because of this fix, the check in the DOS memory setup code has been 117 modified to set the minimum to 16KB instead of 72KB. 118 119commit d8476654ad92dd883c06cccc3fdef3ead9ad3369 120Author: Jonathan Campbell <email@example.com> 121Date: Sun Mar 23 17:39:02 2014 -0700 122 123 add define to debug alloc/free memory allocation. also added code to 124 disable "minimum memory requirement" error if you do so. 125 126commit 99d57f1a0c3b4983e73b845e01a5d1f76099f7a3 127Author: Jonathan Campbell <firstname.lastname@example.org> 128Date: Sun Mar 23 16:57:07 2014 -0700 129 130 note DOSBox emulator instability below 72KB 131 132commit a6743deb4b09eb25b0c4bdf26cfa940377b324bc 133Author: Jonathan Campbell <email@example.com> 134Date: Sun Mar 23 16:44:29 2014 -0700 135 136 yikes! DOS kernel disable flag was set to TRUE by default! This 137 prevented the shell from operating. 138 139commit 064295696ef5c997567e3977575a45ef38ba851d 140Author: Jonathan Campbell <firstname.lastname@example.org> 141Date: Sun Mar 23 16:38:10 2014 -0700 142 143 reduce minimum memory size to 72KB, the lowest we can go before the 144 emulator is unable to boot anything at all. IBM PC-DOS 1.0 apparently 145 runs in that little memory with no trouble. 146 147commit 250371e11ae3db6d5a0864c9e494f7cb0d04d63d 148Author: Jonathan Campbell <email@example.com> 149Date: Sun Mar 23 16:30:50 2014 -0700 150 151 add "dos_kernel_disabled" flag. added code to "BOOT" command to set this 152 flag so that other parts of the program have a way to know the DOS 153 kernel is no longer in charge. Added code to Program::SetEnv() and other 154 environment block code to fail and print a BUG message if emulator code 155 attempts to modify the environment block if the DOS kernel is disabled, 156 since, once the guest OS boots, that environment block is probably long 157 gone by then and overwritten. This fixes a bug I found where if you set 158 the memory size to 246KB or less, boot PC-DOS 1.0, and then hit CTRL+F9 159 to terminate the emulator, the emulator will instead run through 160 thousands of "illegal memory read" messages as code within the emulator 161 does a string scan from what is obviously now unmapped or overwritten 162 memory. 163
Update: OK, with Windows 95 at least, hitting CTRL+F4 is halfway successful at triggering Windows 95's auto insert detection. It seems to work best if you have a Windows Explorer shell window open on the CD-ROM drive, and it only seems to work if the CD-ROM label changes.