Battler wrote:

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.

Hm... are you aware though that scan code 0x59 on the PC is already associated with the right shift key in scan code set 2 and 3?

I see the '=' next to the zero key, yes. I'm unfamiliar though with how you type '=' with the 0 key verses typing ')' on that keyboard. ) is SHIFT+0 on US keyboards, what keys exactly do you press for slovenian to type the 0 key's = sign? Again, if you have to hold down shift, control, etc. to type it then it's not it's own keyboard key.

If you want me to implement it, someone here will need to plug in a Slovenian keyboard (to the PS/2 port NOT USB) and use the 8042 test program from DOSLIB in pure MS-DOS to dump the keyboard scan codes. You will need to go through the menus to select scan code sets 1, 2, and 3. I'm not going to add scan codes to keyboard.cpp that I'm not certain are correct. Again: DOSBox does not emulate USB keyboards it emulates PS/2 keyboards, use a PS/2 version of the 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.

I'll go ahead and implement F13-F24 then as Shift+F1-F12, since that's the common assignment.

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).

Already coded that, thanks.

I'll add the keyboard bindings to the mapper then for the extra Japanese keys and the scan codes to keyboard.cpp.

SA1988 wrote:

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

Haven't started floppy controller emulation. Adding code for that is tricky, because programming the floppy controller is tricky and a bit obscure, not to mention timing sensitive. More so than IDE.

I saw your original comment about the TVGA8900 and Windows 2.x. I have no problem with implementing that graphics card down the line. If I or anyone else here chooses to do it, all you need is the driver and Windows 2.x and time to write another SVGA emulation, bonus if you have an actual TVGA8900 card you can plug into a PC and play with the registers.

Dominus wrote:

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.

I'm fine with feature requests, it gives me ideas to work on with DOSBox-X, so long as people here understand I work on this in my spare time and I reserve the right to pick and choose which request to work on. And as always, it's open source and you're free to code it yourself as well and send in patches.

Maybe SA1988 just wants to see what early high-resolution SVGA modes looked like with Windows 2.x? I wouldn't make it high priority but that's like saying I should have never bothered with adding serial mouse emulation because there's no point in firing up Windows 1.01.

As I wrote your call and thanks for clarifying! I'll shut up now 😉

TheGreatCodeholio wrote:

Hm... are you aware though that scan code 0x59 on the PC is already associated with the right shift key in scan code set 2 and 3?

Well that's a different scan code set. The key I'm talking about is 0x0F in scan code set 2 and 3: http://www.win.tue.nl/~aeb/linux/kbd/scancode … -10.html#ss10.3 . This table here helps a lot with translating between the various scan code sets.

http://www.buypcsupplies.com/images/cat/38617_xlargenss_ndo4294.jpg […]
Show full quote

I see the '=' next to the zero key, yes. I'm unfamiliar though with how you type '=' with the 0 key verses typing ')' on that keyboard. ) is SHIFT+0 on US keyboards, what keys exactly do you press for slovenian to type the 0 key's = sign? Again, if you have to hold down shift, control, etc. to type it then it's not it's own keyboard key.

As I said, it's Shift+0, so it's not its own keyboard key on a Slovenian keyboard.

If you want me to implement it, someone here will need to plug in a Slovenian keyboard (to the PS/2 port NOT USB) and use the 8042 test program from DOSLIB in pure MS-DOS to dump the keyboard scan codes. You will need to go through the menus to select scan code sets 1, 2, and 3. I'm not going to add scan codes to keyboard.cpp that I'm not certain are correct. Again: DOSBox does not emulate USB keyboards it emulates PS/2 keyboards, use a PS/2 version of the keyboard.

I've used a PS/2 Slovenian keyboard too, the scan codes are the same as of the US keyboard, except for that key between left shift and Y which has scan code 0x56 make and 0xD6 break, which DOSBox-X already handles correctly.
But my point is, the Apple Keypad = keyboard (0x59 make, 0xD9 break) is on every Apple keyboard, Slovenian or not. It also tends to be present on Japanese keyboard produced by NEC, with the same function and scan code. So to the Keypad = key should generate scan code 0x59 make and 0xD9 break inside DOSBox-X.

Edit: The keyboard in your photo is just a US keyboard with Slovenian layout added on keycaps. It's even missing that key I mentioned above which has scan code 0x56 make and 0xD6 break.
This is a photo I just made of my Slovenian USB keyboard: http://imgur.com/SSpWbKI .

I'll go ahead and implement F13-F24 then as Shift+F1-F12, since that's the common assignment.

How is that the common assignment when that assignment hasn't been used since the 1980's? And again, IBM's F13-F24 keys would be interpreted by SDL as Shift+F1 to Shift+F12, not as F13 to F24, so to assign F13 to F24 as those makes no sense. F13 to F16 should be 0x64 to 0x67 make and 0xE4 to 0xE7 break.

Already coded that, thanks.

I'll add the keyboard bindings to the mapper then for the extra Japanese keys and the scan codes to keyboard.cpp.

What about the Korean keys?
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-9.html - scan codes F1 make, and F2 make, respectively, and no break.

Battler wrote:

Well that's a different scan code set. The key I'm talking about is 0x0F in scan code set 2 and 3: http://www.win.tue.nl/~aeb/linux/kbd/scancode … -10.html#ss10.3 . This table here helps a lot with translating between the various scan code sets.

I see. So it's possible to implement without conflicting with the US based scan codes that DOSBox generates. To confirm then, keypad = should be:

Scan code set 1: 0x59
Scan code set 2: 0x0F
Scan code set 3: 0x0F

Right?

Edit: Also is the scan code extended or not. Is the scancode in set 1 transmitted as 0x59 or as 0xE0 0x59?

How is that the common assignment when that assignment hasn't been used since the 1980's? And again, IBM's F13-F24 keys would be interpreted by SDL as Shift+F1 to Shift+F12, not as F13 to F24, so to assign F13 to F24 as those makes no sense. F13 to F16 should be 0x64 to 0x67 make and 0xE4 to 0xE7 break.

Well, it was common. It was probably more common than the other keyboard manufacturers. Even if it wasn't, it's what IBM did when they provided that keyboard layout, so, why not code it that way?
Whether SDL sees Shift+F1 or F13 is really up to the OS and the interface that SDL reads keyboard input from. It may be possible that the OS will actually recognize F13-F24 and provide that to SDL, in which case, no, SDL will see keyboard scan codes for F13-F24 and not shift+F1-12. The SDL library has enum values for F13-F24, so there's that possibility.

The code I added to the SDL mapper at least ensures that if you want to bind something on your normal keyboard to F13 on the DOSBox keyboard, you can do that too.

What about the Korean keys?
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-9.html - scan codes F1 make, and F2 make, respectively, and no break.

One thing at a time. I'll get keypad = to generate those scan codes, then I'll get the Japanese ones done, then I'll worry about the Korean ones.

TheGreatCodeholio wrote:

I saw your original comment about the TVGA8900 and Windows 2.x. I have no problem with implementing that graphics card down the line. If I or anyone else here chooses to do it, all you need is the driver and Windows 2.x and time to write another SVGA emulation, bonus if you have an actual TVGA8900 card you can plug into a PC and play with the registers.

I have ModeTest v1.01 for the TVGA8900. Just uploaded it yesterday for DOSGuy in the IRC channel. In case someone need it to write the SVGA emulation then here it is. Haven't been able to find this online, and it came from my old backups.

Sorry, Battler is right, DOS/V's "text" mode is VGA graphics. But it appears to "lie" to DOS applications by setting the active mode byte at 0x40:0x49 to 3 as if 80x25 text.

P4R4D0X wrote:

TheGreatCodeholio wrote:

I saw your original comment about the TVGA8900 and Windows 2.x. I have no problem with implementing that graphics card down the line. If I or anyone else here chooses to do it, all you need is the driver and Windows 2.x and time to write another SVGA emulation, bonus if you have an actual TVGA8900 card you can plug into a PC and play with the registers.

I have ModeTest v1.01 for the TVGA8900. Just uploaded it yesterday for DOSGuy in the IRC channel. In case someone need it to write the SVGA emulation then here it is. Haven't been able to find this online, and it came from my old backups.

modetest_000.png

Awesome. Do you have that specific card's datasheet anywhere? Both the driver and datasheet would help in implementing emulation.

Edit: Sweeeet I even found a TVGA8900 on Ebay

TheGreatCodeholio wrote:

P4R4D0X wrote:

TheGreatCodeholio wrote:

I saw your original comment about the TVGA8900 and Windows 2.x. I have no problem with implementing that graphics card down the line. If I or anyone else here chooses to do it, all you need is the driver and Windows 2.x and time to write another SVGA emulation, bonus if you have an actual TVGA8900 card you can plug into a PC and play with the registers.

I have ModeTest v1.01 for the TVGA8900. Just uploaded it yesterday for DOSGuy in the IRC channel. In case someone need it to write the SVGA emulation then here it is. Haven't been able to find this online, and it came from my old backups.

modetest_000.png

Awesome. Do you have that specific card's datasheet anywhere? Both the driver and datasheet would help in implementing emulation.

Edit: Sweeeet I even found a TVGA8900 on Ebay

nice!

TheGreatCodeholio wrote:

Awesome. Do you have that specific card's datasheet anywhere? Both the driver and datasheet would help in implementing emulation.

MODESET.EXE came from TVGA8900C Utility Disk and I was able to dig up the drivers as well. As for the datasheet for this specific card I can't really find it. However I see you have some datasheets for TVGA8900D on your server. Not sure if that's the full one, I see scanned photocopied pages.

Link: http://hackipedia.org/Platform/x86/VGA/Triden … 0Controller.pdf

It's done.

- Numeric keypad =
- F13-F24 as shifted F1-F12
- Japanese keyboard keys
- Korean keyboard keys

The mapper is built so that if you have a US english keyboard like mine you can still bind some of your keys to the Japanese/Korean ones to test regardless.

NOTE: For Japanese Windows 95, the installer will assume a normal 101-key keyboard. You have to go into the control panel, open the "keyboard" icon, and change the keyboard to tell Win95 that it's a 106-key keyboard with the henkan/kanji/etc keys before the hankaku/muhenkan/etc. keys will work the way they should.

TheGreatCodeholio wrote:

It's done. […]
Show full quote

It's done.

- Numeric keypad =
- F13-F24 as shifted F1-F12
- Japanese keyboard keys
- Korean keyboard keys

The mapper is built so that if you have a US english keyboard like mine you can still bind some of your keys to the Japanese/Korean ones to test regardless.

NOTE: For Japanese Windows 95, the installer will assume a normal 101-key keyboard. You have to go into the control panel, open the "keyboard" icon, and change the keyboard to tell Win95 that it's a 106-key keyboard with the henkan/kanji/etc keys before the hankaku/muhenkan/etc. keys will work the way they should.

Thank you very much! Also no, the keypad = is not an extended keycode, so no 0xE0 there.
Though, one small correction: If you install Japanese Windows 95 from either its own DOS or from a previous Japanese DOS version, and you have JKEYB.SYS loaded in CONFIG.SYS, you will be asked to press a key to determine what keyboard you have. The key you need to press for 106-key mode is to the left of 1, labeled as ~` on a US keyboard, but Hankaku/Zenkaku on a Japanese keyboard. Then it will set up the 106-key keyboard driver, which Windows will also see when installing.

Also, one last thing, what about the Brazilian-specific keypad key which produces scan code 0x7E make and 0xFE break?

Edit: And for F13, etc., well, I don't think any of those old IBM keyboards even works on a computer capable of running DOSBox-X. So assuming someone is going to use such a keyboard with DOSBox-X is not a good idea, IMHO. I think most keyboards with F13 and so on keys used on computers running DOSBox-X are going to be Apple keyboards, rather than 30-year-old IBM keyboards. And they use 0x64 to 0x67 make (0xE4 to 0xE7 break) for F13-F16. Again, I just think that what should be considered is what is the most common scan codes to be expected for those keys on computers capable of running DOSBox-X, not what is the most common in general.
But, let me attempt a compromise - what about making those keys remappable in DOSBox.conf? That way anyone can decide what they want F13-F24 to generate in the guest.

For some reason, when I try to install NT 3.1 with the Aztech IDE CD-ROM Driver (actually compatible on your branch) and directly from CD, in the GUI setup, it doesn't copy the files.

Thank you for the CGA fix. 😀 However, dosbox-x must have been built upon dosbox with an older CGA patch not committed to dosbox SVN. In the SVN version of dosbox, the CGA lines end in these parameters: _EGA_HALF_CLOCK | _EGA_LINE_DOUBLE, not in "_EGA_HALF_CLOCK | _DOUBLESCAN | _REPEAT1". I wonder if the SVN version of dosbox with _EGA_LINE_DOUBLE is already showing the correct refresh rate.

Also, the dosbox developers have been frequently patching their SVN code: http://sourceforge.net/p/dosbox/code-0/3868/log/?path=. They added changes to SDL_SetVideoMode, to the cpu core and a few others. Probably the first page in that list of committed changes is the more relevant to your work.

I also have been testing your non-recursion core while core=normal. It seems slower, although it works well, than the modified normal core I posted previously. I believe the cause may be related to the exception handling in the non-recursion core. Is it possible to use another means to handle the exception without using "throw"? It may be worthwhile to test with "setjmp" (C version of the try/catch/throw) to see if the performance is better! 😀

In addition, I have been testing dosbox-x with the newest dosbox SVN patches. The dosbox developers added a patch with generates a log of fpu overflow and underflow errors. I noted the generation of one of these overflow errors in 95 with your core active. This I would have difficulty confirming, but my belief is that the overflow errors are sometimes related to the FPU exception errors you noted previously in 98 (and possibly 95).

I tried to swap the exception handling in the non-recursion core with setjmp/longjmp. I didn't implement it well, but it did seem to provide some speed advantages in the normal core. It's attached as a diff file.

It's been a busy week!

To answer some questions:

Yes, I will add a keybinding for the Brazilian key to generate that scancode. I'm also up for adding a configuration option in DOSBox on what to do with F13-F24.

The TVGA8900 just arrived at my place according to Ebay, so I might get around to checking to make sure the card works and testing it this weekend.

I'm not sure I implemented the Read Capacity command correctly, because documentation is so sparse on the internet. It might be best at this point to add a test routine in DOSLIB's IDE utility to use the command and see what happens. Not sure if that has anything to do with NT and CD-ROM.

At this time there's no such _EGA_LINE_DOUBLE constant in DOSBox-X, I'll see what differs between DOSBox-X and DOSBox SVN. Expect the two projects' VGA emulation to diverge quite a bit because I think there's a lot about DOSBox's VGA raster emulation that needs to be cleaned up.

The problem with setjmp/longjmp is that if you jump out of a function using C++ objects on the stack those objects are not given a chance to free (unless you jump back). Using setjmp/longjmp with C++ is not a good idea. At the same time I would agree some of the throw/catch stuff is not quite the right way to do things, and I need to clean that up. There needs to be a way for the CPU to decode instructions according to virtual memory with potential for page misses, without page faults and recursion interrupting CPU instructions out of the blue. I think that if CPU instruction decoding were written to be restartable, while using variations of mem_readb() that could return boolean false instead of going through with a page fault, that might allow better design, then the page fault mode would not need to throw an exception the way it does.

Thank you for the cga/vga updates and the interesting reply. 😀 I appreciate the improvements to the video and audio, especially for increased compatibility. I looked at pcem and qemu and their ide emulation doesn't appear to have the "read capacity" ata command. With it commented out, I would think it wouldn't prevent booting the NT systems under most scenarios.

Also, your ideas on emulating the page misses is very hopeful! It would be ideal to have a normal core which mimics the dynamic core in its compatibility in 9x, especially for debugging problems inside the dynamic core. If both the normal and dynamic cores display the same error, then it should be easier to debug it under the normal core with the benefit of solving the dynamic core problem in one step. 😀

Hal mentioned the possibility of "video memory slowdown" to help with unsteady frame rates. I don't think there is source for the vga case, but I believe this is for cga:

1class VGA_Slow_CGA_Handler : public PageHandler {
2public:
3	VGA_Slow_CGA_Handler() {
4		flags=PFLAG_NOCODE;
5	}
6	void delay() {
7		Bits delaycyc = CPU_CycleMax/((Bit32u)(1024/2.80));
8		if(GCC_UNLIKELY(CPU_Cycles < 3*delaycyc)) delaycyc=0;
9		CPU_Cycles -= delaycyc;
10		CPU_IODelayRemoved += delaycyc;
11	}
12
13	Bitu readb(PhysPt addr) {
14		delay();
15		return vga.tandy.mem_base[addr - 0xb8000];
16	}
17	void writeb(PhysPt addr,Bitu val){
18		delay();
19		vga.tandy.mem_base[addr - 0xb8000] = (Bit8u) val;
20	}
21};

I believe vga mode is handled by the VGA_Map_Handler, at least by default. I have wondered whether a video memory slowdown in the vga handler would help with the unsteady frame rate problem, such as in Wing Commander. I don't know the proper value for "delaycyc" in that case. I came across this while surveying your expanding vga emulation code. 😀