Ah. I didn't know about the limitations on Carmageddon's demo. I had the full game and it supported glide. Sorry about that.

Well, seems to be working anyways. Good job.

TheGreatCodeholio wrote:

I see... it needs to act on the value written even if it doesn't change config bytes.

Just to confirm, writes to bytes 0x40, 0xC0, and 0xE0 trigger actions but do not change the value read back? Does anyone have a Voodoo card they can verify this on?

Also, looking over the SST write code, I think I see another issue that needs to be fixed: Writes to bytes 0x10-0x13 (the LFB base) are not being handled properly. All byte writes are being handled as if the upper 8 bits of the 32-bit LFB address. I will push another change I think is necessary to improve emulation.

I'm glad there are simple tests for the V1 emulation. I was using 95 and GLQuake. 😀 Also, thank you for the improvements to the V1 and PCI emulation! I'm looking forward to trying the 3dfx demos today. I'm sure your Pentium MSR additions and the LFB base will produce better accuracy and compatibility.

I don't own a V1 (they were costly on introduction, too), but I'm hopeful someone will chime in with a result. At worst, would it be worthwhile to add a code comment about whether those writes have those actions? The images of the console window I posted are probably less than ideal for making inferences since changes to the command register seemed to have an effect on the initial writes which were logged. I wish this source of information had the answer: http://darwin-3dfx.sourceforge.net/voodoo_graphics.pdf (pages 17, 72; 0x40 - InitEnable).

Also, the Voodoo 2 (V2) emulation is incomplete as reported by another. It must have originally been implemented so that the MAME project could run a subset of games even though they used just a portion of the V2 capabilities. It shouldn't affect the V1 emulation in removing the V2 specific code, especially in the reads and writes.

I finally got around to booting up Windows 7 and compiling another Win32 build of DOSBox-X, from the latest commit at this time (ignore msr).

https://github.com/joncampbell123/dosbox-x/releases

For a moment I thought you had booted W7 IN Dosbox-X 😉

What is this device? It appeared in revision 673. I've checked dosbox.conf and there's nothing using that IRQ.

Laucian wrote:

What is this device? It appeared in revision 673. I've checked dosbox.conf and there's nothing using that IRQ.

It's a test "just for the hell of it" device I added while fleshing out ISA PnP BIOS device enumeration. It was a test to make sure I was encoding I/O ports properly. I also thought that at sometime in the future I could make it a special "Windows 95 + DOSbox" integration device for things like mouse pointer integration or a system tray tool that triggers the CD-ROM swap function in DOSBox or something useful, kind of like what the Virtualbox guest additions drivers for Windows XP do.

I should probably make that an option that's off by default now that I think of it..

Dominus wrote:

For a moment I thought you had booted W7 IN Dosbox-X 😉

Oh, I wish... but that would be like trying to run Windows 7 on a Pentium anyway.

https://www.youtube.com/watch?v=kGXERfhe-Oo

great job! Also, just asking, any progress for a GUI to switch disks (either floppy or CD) anytime during emulation? 😀

Doesn't the menu patch in the Daum build already have that?

well, not with boot already enabled.

AFAIK the menu is Windows only and the Daum built hasn't been updated since January...

Tried my hands at compiling Dosbox-X on OS X and ran into some problems...

To comply with the -std=gnu++11 I needed to make sure to compile the 32bit code with clang since old gcc that I normally use for Dosbox snapshots can't handle that flag.

Eventually (either compiling in 32 or 64bit, I ran into this:

1disney.cpp:186:7: error: case value evaluates to -72, which cannot be narrowed
2      to type 'unsigned long' [-Wc++11-narrowing]
3        case 0x330-DISNEY_BASE:
4             ^

Commenting the case 0x330-DISNEY_BASE: line made compile continue until it hit

1dosbox.cpp:110:2: error: use of undeclared identifier 'cpuid'
2        cpuid(1, a, b, c, d);
3        ^
41 error generated.

I guess I need some help 😀

Edit: fixed some problems I had in compiling this in 32bit, thus edited the whole problem a bit 😀

Dominus wrote:

Tried my hands at compiling Dosbox-X on OS X and ran into some problems... […]
Show full quote

Tried my hands at compiling Dosbox-X on OS X and ran into some problems...

To comply with the -std=gnu++11 I needed to make sure to compile the 32bit code with clang since old gcc that I normally use for Dosbox snapshots can't handle that flag.

Eventually (either compiling in 32 or 64bit, I ran into this:

Copy code to clipboard

1disney.cpp:186:7: error: case value evaluates to -72, which cannot be narrowed
2      to type 'unsigned long' [-Wc++11-narrowing]
3        case 0x330-DISNEY_BASE:
4             ^

Commenting the case 0x330-DISNEY_BASE: line made compile continue until it hit

Copy code to clipboard

1dosbox.cpp:110:2: error: use of undeclared identifier 'cpuid'
2        cpuid(1, a, b, c, d);
3        ^
41 error generated.

I guess I need some help 😀

Edit: fixed some problems I had in compiling this in 32bit, thus edited the whole problem a bit 😀

Well the 0x330-DISNEY_BASE compare... wait.. what? (checks code) Where did that come from?? Who thought that the Disney Sound Source should appear on port 0x330, in conflict with the MPU401?
Whatever, that line is deleted, problem solved.

As for cpuid(), that is a CPU intrinsic function that compiles down to the Pentium/486 CPUID instruction. I don't know the details of clang/LLVM but you might try compiling with -march=pentium or any more recent CPU to enable that intrinsic function.

For anything older than GCC 4.7 I think, you can replace -std=gnu++11 with -std=gnu++0x (at the time, C++11 not yet finalized).

Thanks, I'll try to tinker more tonight. Quick search shows there is a cpuid.h somewhere in clang stuff, don't know if that works on OS X...

The FreeDOS edit 0.9a runs into an error when trying to edit (view) a text file that is approximately 102kb in size. It says the file is too large. If it helps its a file that is two folders deep within an ISO image that is mounted as drive F. It's DOOM.FAQ from the Doom thy flesh consumed shareware disc 1

That version of edit doesn't support large file sizes. Confirmed this by a simple test of running it on the host.

Hey ho TheGreatCodeholio,

fixed the culprit of my dosbox.cpp + SSE problem.
First of all the error "dosbox.cpp:110:2: error: use of undeclared identifier 'cpuid'" was actually revealing enough after looking at it in a more awake state. Just a little earlier you removed Apple when you defined cpuid (#if !defined(__APPLE__)), so of course the error was bound to happen in line 110 since cpuid wasn't defined here 😀

Removing the #if !defined(__APPLE__) and the corresponding #endif /* !defined(__APPLE) */ fixed compilation for me...
Now need to prepare it for a proper download 😀

Edit: made my first pull request on github 😀

Edit2: for some bizarre reason the app bundle does not work while the compiled binary does work. Will need to investigate...

Edit3: this is driving me nuts the app bundle works when started from the terminal but not when started via double click... Seems I will have to do regression testing...

grrrr, d-r-i-v-i-n-g-m-e-n-u-t-s!!!
going over all your git commits I eventually narrowed it down to between 4fdcba9(good) and aca0491 (bad). Since I have to butcher too much to get anywhere in compiling that stuff, I'm taking an educated guess that something in Daum's code broke the app bundle...

Probably something in SDLmain but that is so changed to the original DOSBox...

ESS 688/1887 Sound Blaster coding experiments in DOSLIB:

https://www.youtube.com/watch?v=AnQDjGOChoc

Thank you for the tutorial on ESS audio and doslib! It was very interesting, especially the one card's ability to go beyond the 48k sample rate. 😀 Likewise for the mapping and emulation of the stock card's registers.