DOSBox-X branch

Here you can discuss the development of patches.

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-12-31 @ 05:46

Added to Github issue tracker, noted.

Speaking of issues, there is one issue with Mac OS X I don't know how to resolve. It affects SDL1 builds IF you run it from the Terminal, but not if you run it from the icon (the .app bundle) in the Finder.

https://github.com/joncampbell123/dosbox-x/issues/708
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 625
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2018-12-31 @ 07:24

Never mind the previous question, I was able to solve the menu problem, and clean up OS X startup, by merging SDL2 OS X startup code with SDL1, since SDL2 doesn't seem to have any menu bar problems.

Also, SDL2 in OS X handles things a lot better in my opinion. It runs your SDL_main directly from main() instead of waiting for a certain event in the Cocoa framework and calling SDL_main from there, then exiting out.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 625
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-1-01 @ 13:21

DOSBox-X v0.82.14 is out.

This time many of the changes are GUI and cosmetic changes. Some of them may interest the main DOSBox (SVN) project. Comments welcome.

https://github.com/joncampbell123/dosbo ... x-v0.82.14
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 625
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-1-02 @ 02:37

I've been looking into the Apogee Duke Nukum PC speaker differences between SVN and X.

I was wrong about Duke Nukum rapidly gating the PC speaker, it's not gating at all (except when silencing the speaker). It's writing timer counts to PIT timer 2 at a fixed rapid speed, even if it's the same counter value as before.

Apparently the difference between a pure square wave and the "rough" buzzy sound made by that game is whether or not you are writing the PIT timer count.

Consider this test program: https://github.com/joncampbell123/dosli ... tpcrapi2.c

The same sound effect is made in two versions. The version that sets the same timeout at a constant rate has the same buzzy sound as Duke Nukem while the one that uses longer delays sounds less buzzy.

I confirmed the difference in sound on real hardware as well.
Last edited by TheGreatCodeholio on 2019-1-02 @ 02:48, edited 1 time in total.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 625
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-1-02 @ 02:41

I *think* what is happening is that the 8254 in mode 3 (square wave mode) is counting down by 2 for each half of the square wave, and reloading the counter value at the middle and end of one cycle. The output goes high, and counts down for the first half, then goes low and counts down for the second half.

Perhaps writing a new counter causes output to go high after reload regardless of the current state?

Could writing a new counter cause output to go high immediately?

DOSBox SVN assumes the square wave continues unmodified after writing a new timer count, which is why Duke Nukem's sound effects sound so plain compared to real hardware.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 625
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby Scali » 2019-1-02 @ 08:15

TheGreatCodeholio wrote:So then the emulation is wrong in src/hardware/vga_draw.cpp and src/hardware/vga_other.cpp concerning Hercules graphics emulation?


I'll verify on real hardware when I have time, and then I'll get back to you on that.
Scali
l33t
 
Posts: 3678
Joined: 2014-12-13 @ 14:24

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-1-03 @ 08:42

Following up with the 8254 square wave behavior, I've written some additional test code to examine mode 3 on the 8254. https://github.com/joncampbell123/dosli ... er/hw/8254

I think what's going on here is that the 8254 will generate a square wave in mode 3, but writing a new counter at any point causes the timer output to go HIGH. It still counts down the current counter before reloading at zero, but it does affect the output immediately as well as the opposite state when it reloads the counter.

If my test code is correct, it's possible to prevent the square wave from ever cycling by writing the counter at a rate faster than it can cycle, and it's possible to shorten the period of the LOW state by waiting one counter reload (half the square wave) then writing to the counter at a fixed interval after that.

I will check the test programs on real hardware to see if they sound like they do in DOSBox-X. I think this is key to better recreating what PC speaker sound effects actually sound like (i.e. Duke Nukem) instead of the pure square waves DOSBox SVN currently generates.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 625
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby Scali » 2019-1-03 @ 08:46

If you have a Sound Blaster Pro or similar card, you can connect the PC speaker from the motherboard to its mixer, and then you can record the PC speaker audio from the line-out.
If you use a decent modern recording device (eg a 192 KHz ADC), you should be able to very accurately determine how the timer behaves in square wave mode by just studying the high-resolution recording.
Scali
l33t
 
Posts: 3678
Joined: 2014-12-13 @ 14:24

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-1-03 @ 08:51

Scali wrote:If you have a Sound Blaster Pro or similar card, you can connect the PC speaker from the motherboard to its mixer, and then you can record the PC speaker audio from the line-out.
If you use a decent modern recording device (eg a 192 KHz ADC), you should be able to very accurately determine how the timer behaves in square wave mode by just studying the high-resolution recording.


That is true. However to make recording with common hardware possible (at 48KHz) the test does run the PC speaker at 18.2Hz for a good period of time.
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 625
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby Scali » 2019-1-03 @ 09:00

Anyway, the datasheet has this description of the behaviour in square wave mode:
http://www.scs.stanford.edu/10wi-cs140/ ... s/8254.pdf
"Writing a new count while counting does not affect the current counting sequence. If a trigger is received after writing a new count but before the end of the current half-cycle of the square wave, the Counter will be loaded with the new count on the next CLK pulse and counting will continue from the new count. Otherwise, the new count will be loaded at the end of the current half-cycle."

It does not specify anything about the state. So perhaps we are to assume that the state itself remains the same (as in cycling between high and low after every countdown to 0) until you actually reprogram the mode to reset it.
From what I gather, it updates the count at every 'half-cycle', so you can indeed shorten or lengthen the second part of the square wave by writing a new count during the first part.
And of course you can also change the first part again by writing another count during the second part.
Scali
l33t
 
Posts: 3678
Joined: 2014-12-13 @ 14:24

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-1-03 @ 09:05

What I'm saying is that there may be undocumented behavior here where the 8254 reverts to counting down as if the first half of the square wave if you write the counter, even if the same value.

Logging the PC speaker I/O of Duke Nukem shows that it writes the counter at a fixed rapid rate, even if the same frequency value and that rapid writing has something to do with the "rough" sound of the PC speaker sound effects of the game.

One of the test programs listed imitates the game's style of programming the PC speaker, which does seem to recreate the sound both in DOSBox-X and on real hardware that I've tested. The same program also attempts the same sound effect but writing the counter less (whenever it doesn't change) and the sound isn't so rough.

https://github.com/joncampbell123/dosli ... tpcrapi2.c
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 625
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Re: DOSBox-X branch

Postby Scali » 2019-1-03 @ 09:11

TheGreatCodeholio wrote:What I'm saying is that there may be undocumented behavior here where the 8254 reverts to counting down as if the first half of the square wave if you write the counter, even if the same value.


You might be right.
You could perhaps also try this with software. Namely, the square wave mode can also be used for timer interrupts (and is in fact the chosen mode in IBM's BIOSes). When the output goes high (or was it low?), an interrupt is triggered.
So you could craft an interrupt handler to see when the output state is reset or not.
Scali
l33t
 
Posts: 3678
Joined: 2014-12-13 @ 14:24

Re: DOSBox-X branch

Postby TheGreatCodeholio » 2019-1-03 @ 21:14

Scali wrote:
TheGreatCodeholio wrote:What I'm saying is that there may be undocumented behavior here where the 8254 reverts to counting down as if the first half of the square wave if you write the counter, even if the same value.


You might be right.
You could perhaps also try this with software. Namely, the square wave mode can also be used for timer interrupts (and is in fact the chosen mode in IBM's BIOSes). When the output goes high (or was it low?), an interrupt is triggered.
So you could craft an interrupt handler to see when the output state is reset or not.

That's a good idea.

I just ran the test code I linked to on real hardware, and it worked exactly as it does in DOSBox-X.

So the idea I have so far is that writing the counter brings the output back up HIGH right away. I don't think it interrupts the normal cycle otherwise, except bringing the output up HIGH right away.

EDIT: I will do a binary release of DOSLIB for anyone else who wants to run the code on real hardware: https://github.com/joncampbell123/dosli ... b-20190103
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.
User avatar
TheGreatCodeholio
Oldbie
 
Posts: 625
Joined: 2011-8-18 @ 20:15
Location: Seattle, WA

Previous

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 3 guests