I discovered some time ago that SB sound in Delirium and Internal Damage by EMF is not working in DOSBox due to the apparent need for mirroring of port 0x22e on port 0x22d. Furthermore, you get garbled sound in DOSBox if the port mirroring is implemented because both demos use decrementing DMA transfers that are not supported. However, the Covox/DAC sound in the demos works OK in DOSBox.

Follow up: The SB 2.0 I have doesn't seem to busy cycle, although the direct DAC output command is slow enough to require some polling in the test software.

ripsaw8080 wrote:

I discovered some time ago that SB sound in Delirium and Internal Damage by EMF is not working in DOSBox due to the apparent need for mirroring of port 0x22e on port 0x22d. Furthermore, you get garbled sound in DOSBox if the port mirroring is implemented because both demos use decrementing DMA transfers that are not supported. However, the Covox/DAC sound in the demos works OK in DOSBox.

Well, DOSBox-X has an option to enable SB 2.0 port mirroring now. The decrementing DMA thing would explain why once the demo gets SB support going the audio is all noise and trash instead of music. Looking at the 8237A datasheet it looks like address increment/decrement mode is chosen by one of the bits in the mode register. Assuming the DMA code isn't messy, I don't think it should be all that hard to implement address decrementing mode in DOSBox.

(why did they do the decrementing mode?? did they write music routines that way to somehow make them "faster" or some clever optimization?)

Edit: You got the port mirroring wrong. Port 22Ch on the SB 2.0 is mirrored on port 22Dh and port 22Eh is mirrored on port 22Fh. Think matching by binary, (port AND 0xE) where 0x22F AND 0xE = 0x22E, you lose the least significant bit.

I think you're right about how the ports should be mirrored, but the demos actually do work with it the way I described.

Dunno why EMF chose a decrementing transfer; maybe they came up with some cute way to fill the DMA buffer in reverse... In any case, implementing decrement transfers is certainly do-able, but not a cinch, and also not terribly rewarding for mainline DOSBox when no game is known to need it and the demos in question aren't particularly amazing and have seemingly adequate DAC sound.

ripsaw8080 wrote:

I think you're right about how the ports should be mirrored, but the demos actually do work with it the way I described.

Dunno why EMF chose a decrementing transfer; maybe they came up with some cute way to fill the DMA buffer in reverse... In any case, implementing decrement transfers is certainly do-able, but not a cinch, and also not terribly rewarding for mainline DOSBox when no game is known to need it and the demos in question aren't particularly amazing and have seemingly adequate DAC sound.

You were right about the decrementing DMA. I added code to support it (8-bit DMA reading from system memory, so far) and the music in Internal Damage through Sound Blaster works perfectly now.

http://jon.nerdgrounds.com/dl/emf_id_000.avi

Yep, back when I was looking at the demos I had implemented decrement transfers enough to get the SB music to sound right, but didn't deal with the DMA wrapping stuff because it wasn't a factor. BTW, the increment boolean in dma.cpp is erroneously inverted, but doesn't really matter because it's not used.

ripsaw8080 wrote:

Yep, back when I was looking at the demos I had implemented decrement transfers enough to get the SB music to sound right, but didn't deal with the DMA wrapping stuff because it wasn't a factor. BTW, the increment boolean in dma.cpp is erroneously inverted, but doesn't really matter because it's not used.

As long as you know the DMA controller transfers the byte/word and then decrements the address, you're fine. And that inversion of the bit was one of the first things I fixed. It's in the latest commit.

https://github.com/joncampbell123/dosbox-x/commits/master

Edit: It turns out adding decrement mode DMA also fixed Sound Blaster issues with Crystal Dream 2 http://www.pouet.net/prod.php?which=462. Prior to the fix Sound Blaster playback only gave loud static and the demo jumped forward in time uncontrollably. I know... I know... that demo has GUS support. I'd rather add in the accuracy needed for the Sound Blaster mode to work as well.

I just tested DOSBox-X, and it's basically perfect. I only have one small issue - certain keys are not passed at all. Specifically the following keys:
- [Apple] Keypad = (make code 0x59, break code 0xD9);
- [Apple] F13 (make code 0x64, break code 0xE4);
- [Apple] F14 (make code 0x65, break code 0xE5);
- [Apple] F15 (make code 0x66, break code 0xE6);
- [Apple] F16 (make code 0x67, break code 0xE7);
- [Japanese] Hiragana/Katakana (make code 0x70, break code 0xF0);
- [Japanese/Brazilian-ABNT] Slash/Underscore (make code 0x73, break code 0xF3);
- [Japanese] Henkan/Zenkouho (make code 0x79, break code 0xF9);
- [Japanese] Muhenkan (make code 0x7B, break code 0xFB);
- [Japanese] Yen/Vertical bar (make code 0x7D, break code 0xFD);
- [Brazilian-ABNT] Keypad thousands separator (make code 0x7E, break code 0xFE);
- [Korean] Hancha (make code 0xF1, no break code);
- [Korean] Han/Yeong (make code 0xF2, no break code).

At least for the Japanese keys, there might be DOS/V games that use them.

Battler wrote:

I just tested DOSBox-X, and it's basically perfect. I only have one small issue - certain keys are not passed at all. Specifical […]
Show full quote

I just tested DOSBox-X, and it's basically perfect. I only have one small issue - certain keys are not passed at all. Specifically the following keys:
- [Apple] Keypad = (make code 0x59, break code 0xD9);
- [Apple] F13 (make code 0x64, break code 0xE4);
- [Apple] F14 (make code 0x65, break code 0xE5);
- [Apple] F15 (make code 0x66, break code 0xE6);
- [Apple] F16 (make code 0x67, break code 0xE7);
- [Japanese] Hiragana/Katakana (make code 0x70, break code 0xF0);
- [Japanese/Brazilian-ABNT] Slash/Underscore (make code 0x73, break code 0xF3);
- [Japanese] Henkan/Zenkouho (make code 0x79, break code 0xF9);
- [Japanese] Muhenkan (make code 0x7B, break code 0xFB);
- [Japanese] Yen/Vertical bar (make code 0x7D, break code 0xFD);
- [Brazilian-ABNT] Keypad thousands separator (make code 0x7E, break code 0xFE);
- [Korean] Hancha (make code 0xF1, no break code);
- [Korean] Han/Yeong (make code 0xF2, no break code).

At least for the Japanese keys, there might be DOS/V games that use them.

I have some questions before I begin adding support:

- [Apple] Keypad = (make code 0x59, break code 0xD9);

Just to confirm this does the same thing on PCs as it does on Apple keyboards?

- [Apple] F13 (make code 0x64, break code 0xE4); - [Apple] F14 (make code 0x65, break code 0xE5); - [Apple] F15 (make code 0x66, […]
Show full quote

- [Apple] F13 (make code 0x64, break code 0xE4);
- [Apple] F14 (make code 0x65, break code 0xE5);
- [Apple] F15 (make code 0x66, break code 0xE6);
- [Apple] F16 (make code 0x67, break code 0xE7);

As far as I know the F13-F24 keys on PCs are not common. Are you certain those scan codes are consistent across PC keyboards that have it?

- [Japanese] Hiragana/Katakana (make code 0x70, break code 0xF0); - [Japanese/Brazilian-ABNT] Slash/Underscore (make code 0x73, […]
Show full quote

- [Japanese] Hiragana/Katakana (make code 0x70, break code 0xF0);
- [Japanese/Brazilian-ABNT] Slash/Underscore (make code 0x73, break code 0xF3);
- [Japanese] Henkan/Zenkouho (make code 0x79, break code 0xF9);
- [Japanese] Muhenkan (make code 0x7B, break code 0xFB);
- [Japanese] Yen/Vertical bar (make code 0x7D, break code 0xFD);
- [Brazilian-ABNT] Keypad thousands separator (make code 0x7E, break code 0xFE);
- [Korean] Hancha (make code 0xF1, no break code);
- [Korean] Han/Yeong (make code 0xF2, no break code).

I could add the keyboard codes but I don't have any of those keyboards to test on my own. Nor do I have any DOS/V type games to test it against to verify I'm doing it right.
Do you need DOSBox to just generate the scan codes? Or is there more to having those mode keys?

Also as far as I'm aware, aren't DOS/V games written more for PC98 and PC88 hardware, which isn't compatible with IBM PC hardware (especially memory layout and video hardware)?
It would be neat for DOSBox-X to have a machine=pc98 type mode, certainly, but at the moment, DOSBox and DOSBox-X focus more on IBM PC compatible hardware.

If you want to try adding it yourself you could modify src/hardware/keyboard.cpp and look for the function KEYBOARD_AddKey. Then, look for KEYBOARD_AddKey1, KEYBOARD_AddKey2, and KEYBOARD_AddKey3 and add the case statement for the KBD_KEYS value corresponding to those keys. You will also need to add enum values for those keys in include/keyboard.h, and code to recognize the SDL scan codes in GetKeyCode() under src/gui/sdl_mapper.cpp. If you're willing to wait, I'll get around to adding those in my branch.

DOS/V = Japanese DOS for IBM PC clones with VGA (1990-onwards)

Well, it's about getting the correct scan codes generated inside DOSBox-X, nothing else. Even on a real PC, any key will simply generate the appropriate scan code, and it's up to the OS and the installed drivers/TSR's to do something with them.
As for the F13-F16, I'm talking about the ones on an Apple keyboard. Not sure what scan codes those on other keyboards return.
But anyway, I just think DOSBox-X should pass all scan codes to whatever is running inside it. That way, whatever keyboard one has, it will be fully usable inside DOSBox-X too.

Thank you for the improved video emulation along with the recent improvements to the soundblaster!

In considering any DOS/V keycode request, you may be interested in first reading these assertive posts on the topic: PCEm. Another PC emulator..

Battler wrote:

Well, it's about getting the correct scan codes generated inside DOSBox-X, nothing else. Even on a real PC, any key will simply generate the appropriate scan code, and it's up to the OS and the installed drivers/TSR's to do something with them.
As for the F13-F16, I'm talking about the ones on an Apple keyboard. Not sure what scan codes those on other keyboards return.
But anyway, I just think DOSBox-X should pass all scan codes to whatever is running inside it. That way, whatever keyboard one has, it will be fully usable inside DOSBox-X too.

Alright, looking around, it looks like the IBM PC never had a numeric equals sign key (that I can find). In fact almost every IBM PC keyboard I can find has no equals key on the numeric keypad. Do you mind if I just go ahead and map that to the same handling as the normal equals key?

I'm still not sure what IBM PC scancodes F13-F24 would generate. The SDL library however does have SDL keycodes for F13 and up, so what I could do is modify the SDL mapper so that you can bind them to whatever you want. While I'm digging around in that part of the code, I've always wanted to add in the scan codes for DOSBox so that, on my Linux system, a Windows 95 virtual machine could respond to the Windows and Windows popup menu keys on my keyboard.

At the same time, what DOSBox can listen for from the keyboard is controlled by the OS. Even if the OS gave raw scancodes, the SDL library is already one layer of translation. Then, understand that USB keyboards (especially Apple) use a different scan code system, so, that's another translation layer. It's very difficult to just "pass scan codes in" because there are already plenty of layers of translation going on. For emulation to work, DOSBox needs to translate the SDL library key codes to something that DOS/Windows will understand, or at least make sure the scan code doesn't conflict with something that DOS/Windows understands, or it doesn't work.

Update: check the latest commit. There are bindings for F13-F24 though keyboard.cpp does not yet generate scan codes for them. And there are bindings in place now for numeric keypad =, Windows 95 keys, etc. I also found a copy of Windows 95 japanese locale which so far works fine in DOSBox-X though I don't understand a lot of the text. Looks like the DOS/V mode of Win 95 uses a driver that sacrifices the high bit of the attribute byte to use the 512-character mode of the VGA font RAM, since Scandisk and Edit lack the drop shadows you normally see in US versions.

As for Japanese keyboards, can you confirm this page is correct?

http://www.stanford.edu/class/cs140/projects/ … cancodes-7.html

I've noted that your innovative "dynamic core non-recursion" code, to avoid the pagefault overrun errors, also has circumvented an error in the normal core. Confirmed this by starting UT99 under the normal core. Your code comments suggest that the code was tested under the different cores, so your patch may work outside the dynamic core by design. 😀

Upon a closer look at the code, I noted a subroutine, void CALLBACK_RunRealInt_retcsip, which appears in callback.cpp and dos.cpp. However, I couldn't find any code which calls this function. Was this function utilized during testing but later found to be unnecessary to your patch? Thanks!

truth5678 wrote:

I've noted that your innovative "dynamic core non-recursion" code, to avoid the pagefault overrun errors, also has circumvented an error in the normal core. Confirmed this by starting UT99 under the normal core. Your code comments suggest that the code was tested under the different cores, so your patch may work outside the dynamic core by design. 😀

Upon a closer look at the code, I noted a subroutine, void CALLBACK_RunRealInt_retcsip, which appears in callback.cpp and dos.cpp. However, I couldn't find any code which calls this function. Was this function utilized during testing but later found to be unnecessary to your patch? Thanks!

That's probably a function that someone else wrote but never put to use. I've removed a few such unused functions as I find them in the past 6 months.

About the ET4000 video emulation, there's still the bug where, while entering a DOS session in Windows 3.x (3.0 and 3.1x) in Window mode, the whole screen of the guest becomes scretched horizontally.

TheGreatCodeholio wrote:

Alright, looking around, it looks like the IBM PC never had a numeric equals sign key (that I can find). In fact almost every IBM PC keyboard I can find has no equals key on the numeric keypad. Do you mind if I just go ahead and map that to the same handling as the normal equals key?

No, because I would like the correct scan code to be passed, and that's 0x59 make, and 0xD9 break. The normal equals key doesn't even have a fixed scan code (every keyboard layout places it elsewhere, the Slovenian keyboard layout has equals at Shift+0, for example), and in any case this isn't about the key returning an equals sign, but about the key generating the correct scan code.

I'm still not sure what IBM PC scancodes F13-F24 would generate. The SDL library however does have SDL keycodes for F13 and up, so what I could do is modify the SDL mapper so that you can bind them to whatever you want. While I'm digging around in that part of the code, I've always wanted to add in the scan codes for DOSBox so that, on my Linux system, a Windows 95 virtual machine could respond to the Windows and Windows popup menu keys on my keyboard.

Well, the Apple F13-F16 (I think no Apple keyboard has F17-F24) keys generate 0x64/0xE4, 0x65/0xE5, 0x66/0xE6, and 0x67/0xE7.
As for the IBM ones, F13 is Shift+F1, F14 is Shift+F2, and so on, so basically the scan code would be 0x2A (0xAA for break) followed by the appropriate F1-F12 key code.

Edit: The scan codes for the Windows etc. keys: left Windows is 0xE0 0x5B (make) and 0xE0 0xDB (break), right Windows is 0xE0 0x5C (make) and 0xE0 0xDC (break), and Windows Popup Menu is 0xE0 0x5D (make) and 0xE0 0xDD (break).

At the same time, what DOSBox can listen for from the keyboard is controlled by the OS. Even if the OS gave raw scancodes, the SDL library is already one layer of translation. Then, understand that USB keyboards (especially Apple) use a different scan code system, so, that's another translation layer. It's very difficult to just "pass scan codes in" because there are already plenty of layers of translation going on. For emulation to work, DOSBox needs to translate the SDL library key codes to something that DOS/Windows will understand, or at least make sure the scan code doesn't conflict with something that DOS/Windows understands, or it doesn't work.

Well, I know Windows has the raw input messages, not sure if SDL implements that, though. Do you have any documentation about SDL that I could read to understand more about how SDL's keyboardh andling works?

Update: check the latest commit. There are bindings for F13-F24 though keyboard.cpp does not yet generate scan codes for them. And there are bindings in place now for numeric keypad =, Windows 95 keys, etc. I also found a copy of Windows 95 japanese locale which so far works fine in DOSBox-X though I don't understand a lot of the text. Looks like the DOS/V mode of Win 95 uses a driver that sacrifices the high bit of the attribute byte to use the 512-character mode of the VGA font RAM, since Scandisk and Edit lack the drop shadows you normally see in US versions.

Nope, the DOS/V display driver uses a VGA graphic mode where certain character combinations yield double-width Japanese characters, of which about 10000 (yes, that's ten thousand) or so are defined. All 16 colors are available. The 512-character mode is still not by far enough to write in Japanese, given the thousands of characters the Japanese language uses (of which 2000 are common usage, plus thousands minor characters used in personal and place names, and so on).

As for Japanese keyboards, can you confirm this page is correct?

http://www.stanford.edu/class/cs140/projects/ … cancodes-7.html

Yep, that page is correct.

what's the status for the floppy controller ports?
Edit: TVGA8900 being out of question.

What's with the feature request explosion? It's definitely not my call to make but why add another graphics card emulation just to fire up Windows 2 in high resolution (and since it's really useless probably just to see it once in that res)? Or the Apple keyboard scancodes...

I can see the sense in making Windows 9x work better, all others are beyond my, perhaps limited, understanding (running linux with wine to run win32 games sounds fun but IMHO a bit strange.

SA1988 wrote:

About the ET4000 video emulation, there's still the bug where, while entering a DOS session in Windows 3.x (3.0 and 3.1x) in Window mode, the whole screen of the guest becomes scretched horizontally.

There's currently a whole raft of bugs with Windows 3.1/95 DOS boxes I'll admit, yes. I'm curious for example what prevents the Windows 95 startup screen from loading/saving the VGA text screen properly. I'll see what I can do. I think there are also a few cases where INT 10h emulation fails to work 100% properly in a DOS box because of some shortcuts taken.