Re: DOSBox-X branch

Posted on 2018-12-27, 18:55

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

Everything else looks correct for output=surface, it's only the highcolor modes. The way I fixed that in DOSBox-X (going off the top of my head) was to modify the LIN15/LIN16/LIN24/LIN32 VGA scanline rendering code so that in non-OpenGL output it would reverse the RGBA order to match the BGRA (32- …

---

Re: DOSBox-X branch

Posted on 2018-12-27, 18:51

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

Using hw\vesa\MODESET in DOSLIB, I can confirm highcolor/truecolor modes show up correctly in Mac OS X if you use the OpenGL output with the latest SVN commit. I can also confirm video update performance is poor with output=surface in OS X and very poor if the window is above 800x600 on a Retina …

---

Re: DOSBox-X branch

Posted on 2018-12-27, 18:39

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

I have a "mirror" of SVN here: https://github.com/joncampbell123/dosbox-svn I trans-planted the hacked SDL1 library from DOSBox-X to give DOSBox SVN something to compile against that displays on Mojave correctly. So far, it works.

---

Re: DOSBox-X branch

Posted on 2018-12-27, 18:10

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

Heh, well... the SDL 1.2.15 provided by Brew on Mac OS X isn't aware of Mojave's redraw issue. But SVN does compile on OS X 64-bit.

---

Re: DOSBox-X branch

Posted on 2018-12-27, 18:02

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

I've incorporated the Xorg 1.20.1 patch, though none of my systems are running that version of Xorg so I can't directly test it right now.

---

Re: DOSBox bug OS X regression

Posted on 2018-12-27, 08:10

by

by TheGreatCodeholio

in DOSBox Development

in DOSBox Development

I don't expect the SDL devs to spend any time on SDL1, they need to focus on SDL2. :) That's why DOSBox-X uses it's own heavily modified in-tree SDL1 library, it's easier to fix things that way. For Mojave the fix is to make OpenGL output the default, but if surface is needed, the blank window …

---

Re: Cannot (m)alloc 64k block for a VGA double buffer

Posted on 2018-12-27, 07:50

by

by TheGreatCodeholio

in DOSBox Development

in DOSBox Development

At least from my experience with the Open Watcom C compiler, malloc and _fmalloc() take a parameter that's only 16 bits wide on 16 bit targets. So the largest value possible is 65535. If you specify a value larger than that, the value will be truncated to 16 bits and you'll allocate (N % 65536) …

---

Re: DOSBox bug OS X regression

Posted on 2018-12-27, 07:45

by

by TheGreatCodeholio

in DOSBox Development

in DOSBox Development

I can definitely confirm here as well that on Mac OS X the SDL1 surface output is slower (and incurs more CPU load) than OpenGL. Note that the problem doesn't exist on SDL2 because SDL2 will use OpenGL or Metal on the backend for you automatically. Furthermore, OS X Mojave appears to prevent …

---

Re: Win9x audio is poor in dosbox

Posted on 2018-12-27, 07:22

by

by TheGreatCodeholio

in PC Emulation

in PC Emulation

However you might get better quality out of the game if you use the Sound Blaster 16 drivers for Windows 3.1, then configure Windows 3.1 to send the MIDI out to the UART and external port instead of the FM synthesizer. Then configure DOSBox / DOSBox-X to emulate a MPU-401 and send the MIDI on to …

---

Re: Win9x audio is poor in dosbox

Posted on 2018-12-27, 07:19

by

by TheGreatCodeholio

in PC Emulation

in PC Emulation

Yeah, I noticed DOSBox SVN has problems with Windows 3.1 and sound playback through Gravis Ultrasound. As far as I can tell, stock wave playback through the GUS drivers rely on setting a loop point where, instead of looping back, the card fires an interrupt and continues playing. The Windows 3.1 …

---

Re: DOSBox-X branch

Posted on 2018-12-27, 06:01

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

On the PC-98 side, emulation has improved enough that generally any game not using funky copy protection tricks, hardware-specific tricks, or hacky disk change detection will work fine now. It turns out the reason most games were hanging up or requiring you to move the mouse constantly is that, …

---

Re: DOSBox-X branch

Posted on 2018-12-27, 05:58

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

If your Mac OS X system has a high enough resolution display to enable "High DPI" mode, SDL1 builds of DOSBox-X now offer an option to enable "HighDPI" mode so that the window is scaled down to match the pixels on the retina display 1:1 (so you can use that extra resolution for some cool looking …

---

Re: DOSBox-X branch

Posted on 2018-12-27, 05:56

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

Latest development news: I've gotten DOSBox-X to show working menus on Mac OS X for both SDL1 and SDL2 builds, to show a few basic commands (mapper, configuration GUI, and pause) in the dock menu (the menu that you get when you command-click the application icon in the dock). I also managed to get …

---

Re: DOSBox-X branch

Posted on 2018-12-27, 05:52

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

FYI The patch in svn r4177 referenced from this other thread is also required for DosBox-X and works (tested on Fedora 29 x86_64). I haven't come across that, however I did fix a very similar and serious problem with Centos 7 and SDL1 where going fullscreen caused DOSBox-X to get stuck in an …

---

Re: DOSBox-X branch

Posted on 2018-12-07, 07:05

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

3Dfx: I was not aware Daum had a voodoomem option, perhaps that didn't make it. You may need to configure dosbox.conf to enable PCI emulation. DOSBox-X does not provide a glide2x.ovl, I've instead been using the real glide files from a 3Dfx install CD-ROM image which seems to work fine with DOSBox …

---

Re: DOSBox-X branch

Posted on 2018-12-07, 07:00

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

Vsync code has not been touched since borrowing from DOSBox SVN or incorporated from DOSBox Daum. I do not test that code, so I don't know if it works.

---

Re: DOSBox-X branch

Posted on 2018-12-07, 06:59

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

SDL2 builds are limited to "surface" output only. OpenGL support is not implemented and it's probably not a good idea to hack around the window for Direct3D the way the Daum code did with SDL1.

---

Re: DOSBox-X branch

Posted on 2018-12-07, 06:58

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

To explain FREECG98.bmp, DOSBox-X added support for NEC PC-98 emulation back in November 2017 (machine=pc98). The CG bitmap from ANEX86.BMP or the FONT.ROM files normally needed by emulators is copyrighted, but a contributor to the project generated a free replacement from fonts on his system. If …

---

Re: DOSBox-X branch

Posted on 2018-12-07, 06:54

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

DOSBox-X maintains both SDL2 support by request and a heavily modified in-tree version of SDL1. The in-tree modifications add support for things not originally supported by SDL1 and fix many annoying bugs. It also features a hack for Windows builds where the window frame message pump is in a …

---

Re: DOSBox-X branch

Posted on 2018-12-01, 21:52

by

by TheGreatCodeholio

in DOSBox Patches

in DOSBox Patches

New DOSBox-X release. https://github.com/joncampbell123/dosbox-x/re … sbox-x-v0.82.12

---