truth5678 wrote:

Is it worthwhile to condense this part? […]
Show full quote

Is it worthwhile to condense this part?

Copy code to clipboard

1	case M_TEXT:
2		vga.draw.address_add=vga.config.scan_len*(2<<vga.config.addr_shift);
3		break;
4	case M_CGA2:
5		vga.draw.address_add=vga.config.scan_len*(2<<vga.config.addr_shift);
6		break;
7	case M_CGA4:
8	case M_CGA16:
9	case M_AMSTRAD:	// Next line.
10		vga.draw.address_add=vga.config.scan_len*(2<<vga.config.addr_shift);
11		break;

to:

Copy code to clipboard

1	case M_TEXT:
2	case M_CGA2:
3	case M_CGA4:
4	case M_CGA16:
5	case M_AMSTRAD:	// Next line.
6		vga.draw.address_add=vga.config.scan_len*(2<<vga.config.addr_shift);
7		break;

Makes sense. Go ahead. I'll modify the code the same on my end and commit the change.

Sorry for the long delay guys, my week has been busy coding support for talking to a video routing/switcher unit over TCP/IP for a client.

Gui55 wrote:

Can someone tell me if the FDC-primary controller emulation is ready for 32-bit DA yet? For some reason I can't get the "int13fakev86io" to work yet in windows 9x. (This was in DOSBox-X 12-24-2014 code, tested with a regular 1.44MB image)

It's not. The "int13fakev86io" option is a placeholder at this time. I don't know how Windows 95 detects non-PNP FDC controllers. All I know at this time is that Windows 95 does detection somehow in a way that might involve INT 13h, and does not involve touching the I/O ports. I also need to finish FDC emulation.

Thank you for the additional emulation and for the updates! I also have an issue with keyboard cursor movement up/down which has lag in the EF2000 "setsound.exe" utility (may be an issue in other software, too). The issue originates from commit "271711e1".

Resolved by the following:

1--- dev_con-ORIG.h	2015-01-10 21:00:13 -0500
2+++ dev_con.h	2015-01-10 21:02:56 -0500
3@@ -521,7 +521,7 @@ bool device_CON::Close() {
4 }
5 
6 Bit16u device_CON::GetInformation(void) {
7-	if (true/*FIXME: make an option*/) {
8+	if (false/*FIXME: make an option*/) {
9 		Bit16u ret = 0x80D3; /* No Key Available */
10 
11 		/* DOSBox-X behavior: Use INT 16h AH=0x11 Query keyboard status/preview key.

It looks like you had already anticipated this issue and it could also be resolved by your recommendation of adding the dosbox configuration option. 😀

I isolated a midi bug which may be related to Ykhwong's midi issue. This refers to a 1/20/14 build of dosbox-x via mingw32; however, it may only be relevant to Ykhwong's build but not to current dosbox-x. In any case, if this issue occurs in the future, here is the post about it: Re: ykhwong's latest build?.

Edit: confirmed that the midi issue is not related to the linewise video emulation itself, but instead the menu items. Removed linewise menu items from January 2014 build of dosbox-x which seems to correct the midi issue where the midi frequently does not start playing. Also, have some verification from a January 2015 build, but in that case I removed all menu code since there is no linewise option.

Suggest having a definition line to avoid compiling any menu code during the build process. This may help debugging, especially if this result is confirmed. 😀

Edit2: isolated the midi bug in Ykhwong's build to the "cycles" setting. Running fixed cycles fixes the midi issue. It may be worth disabling menu and gui code if this problem occurs in the future, at least for testing.

Hello,

Could kekko's work on 3DFX emulation be included in DOSBox-X, pretty please ?

(I tried to do it quickly and it failed, seems like it will require at least some work since the patch is for DOSBox SVN)

My main motivation behind this is to run early Windows 9X 3D games I can't emulate right now like Interstate '76 or Resident Evil 2, among others, without having to build a Windows9X computer. Since DOSBox-X seems Win95 friendly, it would be the perfect combination.

Anyway, thanks soooo much for DOSBox-X ! 😀

truth5678 wrote:

but in that case I removed all menu code since there is no linewise option.

Hey Truth5678, would it be too much trouble for you to create a .diff patch that would remove the menu code in the most recent DOSBox-X source?

xcomcmdr wrote:

Could kekko's work on 3DFX emulation be included in DOSBox-X, pretty please?

It already is!

SedrynTyros wrote:

Hey Truth5678, would it be too much trouble for you to create a .diff patch that would remove the menu code in the most recent DOSBox-X source?

I actually made that patch already, but didn't post it. 😀 In addition to the menu, I would also test with the "cycles updating in menu bar" turned off.

truth5678 wrote:

xcomcmdr wrote:

Could kekko's work on 3DFX emulation be included in DOSBox-X, pretty please?

It already is!

Sweet ! Thanks !

Also, Codeholio has fixed bugs in the source code which impact the 3dfx emulation. 😀 There should be some posts about it in this thread, so you may find technical details in them.

do you know if latest Ykhwong build updated the code for mt32 emulation? Munt recently updated to 1.50 (changelog anyone?)

Myloch wrote:

do you know if latest Ykhwong build updated the code for mt32 emulation? Munt recently updated to 1.50 (changelog anyone?)

Munt changelog is located here:
https://github.com/munt/munt/blob/master/mt32emu/NEWS.txt

thanks dude. As a first impression, I doubt Taewoong already updated Munt code to 1.5.0. Anyone tested it? how the output sounds compared to older versions?

Is there a build ready to be tested? 😁 Progress looks excitingly delicious.

dosquest wrote:

Is there a build ready to be tested? 😁 Progress looks excitingly delicious.

I posted a win32 build of the latest commit (as of 2015-01-22) on Github. Enjoy.

Quick question while I consider changes from other branches:

I know ykhwong has a source tarball to download on his site. Does he have a svn or git repository I can read from? It helps to merge changes when I can go through the commits in the other branches one by one.

TheGreatCodeholio wrote:

Quick question while I consider changes from other branches:

I know ykhwong has a source tarball to download on his site. Does he have a svn or git repository I can read from? It helps to merge changes when I can go through the commits in the other branches one by one.

I don't think he does. You could try asking him by e-mailing (on requestemail address removed by Dominus) but he doesn't seem to be replying like he did in the past; at least to the couple of bug reports I e-mailed him about recently, he hasn't. He used to always at least respond.

He seems to be quite busy with real life nowadays but some days ago he replied to me via PM (he's a user here on vogons)

Myloch wrote:

He seems to be quite busy with real life nowadays but some days ago he replied to me via PM (he's a user here on vogons)

I just sent him a message. I'm not sure what to expect but I think DOSBox-X could benefit from code that goes both ways between his and mine branch, instead of only from mine.

Hi guys,

Taking into consideration what others on this forum have said, I'm going to be releasing Win32 builds more often now. I just posted one now that includes fixes and enhancements to the EMS/VCPI stuff and some new experimental (unstable) use of some code already there that runs the whole DOS system in virtual 8086 mode. I started doing it because of an old demo I found on scene.org that refuses to run unless it detects both expanded memory AND virtual 8086 mode (EMM386.EXE active using 386 protected mode to fake the EMS page frame, basically).

As always, if you have any changes or patches of your own you'd like me to incorporate, go ahead and post them. For best results, I recommend cloning my git repository and developing from your clone, then letting me know when to pull your changes and merge them back. I may have some questions or nitpicks about code quality or what the changes mean, but that's about it.

Enjoy!