Under the mode_sense function, changing a register value from 0x29 to 0x28 unlocks the tray, presumably a prerequisite to 95 ejecting a CD. However, changing this value to unlocked prevents the CD audio tracks from updating after switching the CD image; I would guess the fact that the locked tray allows for an updated TOC is caused by an artifact and not the way for 95 to detect a new CD.

Given the"eject" function is allowed, then the eject event(?) is generated by the start/stop unit command (0x1B; along with LoEj bit set). Bochs and qemu report values such as "ASC_MEDIUM_MAY_HAVE_CHANGED" (Additional Sense Code [28 or 3A] of Request Sense 0x03 command; bit 13) and "UNIT ATTENTION" (Sense Key 0x6 of 0x03 command; bit 2) which seem to be connected to 95 recognizing a new CD.

I recall that pressing "eject" inside 95 activates 0x1E and 0x1B, the Medium Removal and the Start/Stop commands. Perhaps these could generate a TOC update, but would 95 be able to detect the new CD information without further code? Instead, would 95 have to receive the above register values before Ctrl-F4 activates the media change? Would it help to recruit SetDevice or "CDROM_Interface_Image::LoadIsoFile"?

I also checked into the open source mscdex replacements, but these don't support CD audio, so changing their code would not easily help.

I updated some of the register values for ATAPI emulation. The bit is still active for the tray lock, but the other bits were cleared which correspond to unsupported features. I believe the edits will help the lag on the reported audio playback time.

1case 0x2A: /* CD-ROM mechanical status */
2			*write++ = 0x00;	/* reserved @+2 ?? */
3			*write++ = 0x00;	/* reserved @+3 ?? */
4			*write++ = 0x31;	/* multisession=0 mode2form2=1 mode2form=1 audioplay=1 */
5			*write++ = 0x00;	/* ISRC=1 UPC=1 C2=1 RWDeinterleave=1 RWSupported=1 CDDAAccurate=1 CDDASupported=1 */
6			*write++ = 0x01;	/* loading mechanism type=tray  eject=1  prevent jumper=0  lockstate=0  lock=1 */
7			*write++ = 0x03;	/* separate channel mute=1 separate channel volume levels=1 */
8			x = 176 * 8;		/* maximum speed supported: 8X */
9			*write++ = x>>8;
10			*write++ = x;
11			x = 256;		/* (?) */
12			*write++ = x>>8;
13			*write++ = x;
14			x = 0;		/* (?) */
15			*write++ = x>>8;
16			*write++ = x;

The changes also provide a possible "cd swap" function for the data portion. If Explorer is closed and CD audio player is open, and a CD is swapped with ctrl-F4, then eject; then Explorer is opened again, the files will sometimes be read correctly (disabled cache helped?). However, the CD disk name and file listing will/may not be updated. This may provide sufficient function to install across multiple CDs (in some cases) which do not detect the CD name, but instead just read the files. Even if not, it does show the "caching function" could be disabled to better test the atapi emulation.

I really appreciate your work, but can you do us two favours to help you in your endeavour to make a more accurate DOSBOX?

Please provide some binaries (Windows, Linux?) for your builds .... and put the *current* download links (alongside with other ones) on the thread starter post. It is really a hassle to sift through the whole thread for the current build ("Nice work! But where can I download and try out your new things? No download link? Grrr... *reading through the pages* looking at several download locations .. no new build ... giving up).

I think your version of DOSBOX has a great potential and it would help very much to provide easily accessible links on the first post 😀

dossabossa wrote:

I really appreciate your work, but can you do us two favours to help you in your endeavour to make a more accurate DOSBOX?

Please provide some binaries (Windows, Linux?) for your builds .... and put the *current* download links (alongside with other ones) on the thread starter post. It is really a hassle to sift through the whole thread for the current build ("Nice work! But where can I download and try out your new things? No download link? Grrr... *reading through the pages* looking at several download locations .. no new build ... giving up).

I think your version of DOSBOX has a great potential and it would help very much to provide easily accessible links on the first post 😀

This

dossabossa wrote:

I really appreciate your work, but can you do us two favours to help you in your endeavour to make a more accurate DOSBOX?

Please provide some binaries (Windows, Linux?) for your builds .... and put the *current* download links (alongside with other ones) on the thread starter post. It is really a hassle to sift through the whole thread for the current build ("Nice work! But where can I download and try out your new things? No download link? Grrr... *reading through the pages* looking at several download locations .. no new build ... giving up).

I think your version of DOSBOX has a great potential and it would help very much to provide easily accessible links on the first post 😀

Sorry about that....

General project page: http://www.hackipedia.org/Projects/DOSBox-X/

Latest version: http://www.hackipedia.org/Projects/DOSBox-X/d … 2a37-src.tar.xz

Thanks for the links, but as I said, you would attract more attention and comments, if you regularily put your newest release on the first post of the thread 😀

.. and provide a Windows binary (at least 😀, not everyone has the knowledge and/or the tools to compile the source.

Yeah, I quite agree! Do hopefully someday provide a Windows binary, I dare say it would be nice to have an alternative to ykhwong's builds for this stuff here. 😀
Anyway, I do also appreciate your work on DOSBox-X branch patch.

With a minimal installation of 95b and an additional modification, I haven't yet seen a page fault overrun with the IDE emulation. It requires further testing to be sure, but if this is true, then I don't know whether the fix is the removed 9x components or the modifications to the registry. The registry changes would be a good candidate since it is avoiding the newer multithreading model (apartment versus both). I had wondered whether the more aggressive multithreading of 9x was causing the pagefault overruns with 32-bit paging active.

I've just confirmed with Windows 98se that changing those registry values from "both" to "apartment" don't help with the pagefault overruns, so interestingly it must be the components.

Thanks for testing it. I'll continue to test the 95b example, especially with versions with and without the removable Windows components.

I am getting an error when I try to compile the latest version of DOSBox-X on my Arch Linux system. Here is the error produced:

1dma.cpp: In function ‘Bit8u POD_State_Find_DMA_Callback(Bit32u)’:
2dma.cpp:432:44: error: cast from ‘const void*’ to ‘Bit32u {aka unsigned int}’ loses precision [-fpermissive]
3   if( (Bit32u) dma_state_callback_table[lcv] == addr ) return lcv;
4                                            ^
5dma.cpp: In function ‘Bit32u POD_State_Index_DMA_Callback(Bit8u)’:
6dma.cpp:443:48: error: cast from ‘const void*’ to ‘Bit32u {aka unsigned int}’ loses precision [-fpermissive]
7  return (Bit32u) dma_state_callback_table[index];
8                                                ^

This seems like an excellent patch if I could only use it...

Happy New Years, DOSBox-X! 😀

Looking forward to Taewoong integrating the latest DOSBox-X branch into SVN Daum so I can try out the new CDDA support.

Yes, that's right! And knowing that those builds usually have almost every patch added it seems, there might always be more features added along with DOSBox-X 😁 (Although I'm not sure what that'd be)

Kinda of a bummer that there's still no Win32 DOSBox-x available for testing with the latest updates. I sincerely hope the Linux/Unix folks have enjoyed playing with the last patches; all four of you are probably having a blast!

RibShark wrote:

I am getting an error when I try to compile the latest version of DOSBox-X on my Arch Linux system. Here is the error produced: […]
Show full quote

I am getting an error when I try to compile the latest version of DOSBox-X on my Arch Linux system. Here is the error produced:

Copy code to clipboard

1dma.cpp: In function ‘Bit8u POD_State_Find_DMA_Callback(Bit32u)’:
2dma.cpp:432:44: error: cast from ‘const void*’ to ‘Bit32u {aka unsigned int}’ loses precision [-fpermissive]
3   if( (Bit32u) dma_state_callback_table[lcv] == addr ) return lcv;
4                                            ^
5dma.cpp: In function ‘Bit32u POD_State_Index_DMA_Callback(Bit8u)’:
6dma.cpp:443:48: error: cast from ‘const void*’ to ‘Bit32u {aka unsigned int}’ loses precision [-fpermissive]
7  return (Bit32u) dma_state_callback_table[index];
8                                                ^

This seems like an excellent patch if I could only use it...

That's a compile error you normally get when you typecast pointers to int for whatever reason (because it works on 32-bit!), and you compile for 64-bit targets. I'll look into that part of the code.

SedrynTyros wrote:

Kinda of a bummer that there's still no Win32 DOSBox-x available for testing with the latest updates. I sincerely hope the Linux/Unix folks have enjoyed playing with the last patches; all four of you are probably having a blast!

I think you'd be surprised how many people out there are developing for Linux 😀
I'll look into a Win32 build when i have more free time this month.

TheGreatCodeholio wrote:

I think you'd be surprised how many people out there are developing for Linux 😀
I'll look into a Win32 build when i have more free time this month.

You know, I'm sure that's true, so nevermind; it was silly to bring it up in the first place. If you have the free time in the future, a Win32 build would be helpful, but if not than I'm sure Taewoong will eventually add it to his project as he always does. 😀

*** This topic has been split and a discussion of why and why not a developer on linux should maintain a Windows build ***
*** see Pros and Cons of mainting a Windows built if you are a developer on Linux (was:DOSBox-X branch) for that discussion ***

New DOSBox SVN Daum build released this morning that includes the most updated DOSBox-X!!

http://ykhwong.x-y.net/

EDIT: Unfortunately, all of my Windows 95b images crash the emulator during the guest OS boot, so perhaps more work needs to be done on this Daum build. Oh well.

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

Project location: http://hackipedia.org/Projects/DOSBox-X

Source code: http://hackipedia.org/Projects/DOSBox-X/dosbo … 3e1c-src.tar.xz

Win32 build: http://hackipedia.org/Projects/DOSBox-X/dosbo … 83e1c-win32.zip