VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 1680 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 1681 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 1682 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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/dosbox-x/re … sbox-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.

Reply 1683 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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/doslib/blob … 8254/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-01-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.

Reply 1684 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 1685 of 2397, by Scali

User metadata
Rank l33t
Rank
l33t
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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 1686 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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/doslib/tree/master/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.

Reply 1687 of 2397, by Scali

User metadata
Rank l33t
Rank
l33t

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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 1688 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 1689 of 2397, by Scali

User metadata
Rank l33t
Rank
l33t

Anyway, the datasheet has this description of the behaviour in square wave mode:
http://www.scs.stanford.edu/10wi-cs140/pintos/specs/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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 1690 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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/doslib/blob … 8254/tpcrapi2.c

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1691 of 2397, by Scali

User metadata
Rank l33t
Rank
l33t
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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 1692 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Scali wrote:
You might be right. You could perhaps also try this with software. Namely, the square wave mode can also be used for timer inter […]
Show full quote
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/doslib/rele … doslib-20190103

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1693 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Update on the PC speaker discussion:

If you write port 43h and then the counter, the 8254 will reset the counter right away.

Recent test code in DOSLIB under hw\8254 confirms this.

Duke Nukem's rough sounding PC speaker effects are apparently caused by the game writing port 43h then PIT timer 2. The rough sound comes from interrupting the square wave to start the new counter value, it seems.

I'm going to write a little more test code in DOSLIB to see if it behaves differently if the code writes PIT timer 2 without writing port 43h first (writing port 43h once at startup).

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1694 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

I tested the latest DOSLIB code, here are my findings:

If you write port 43h then the counter, the counter loads the new value right away and begins counting down.

If you do NOT write port 43h, then write the counter, the new value takes effect only when the current value is finished.

This is very likely consistent across all three timers, not just the PC speaker, and very likely consistent across at least mode 2 and 3.

It's interesting to note that DOSBox-X and SVN both acknowledge this somewhat with the "new_mode" variable per-PIT in timer.cpp, though this behavior is only accurately emulated for PIT 0 (timer) in mode 2 at this time (with a comment mentioning DoWhackaDo).

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1695 of 2397, by Scali

User metadata
Rank l33t
Rank
l33t

Yes, you are correct. When you write to port 43, you 'reset' the counter, because you possibly change the mode the counter operates in. In that case, it will indeed wait for the counter register to update, and start the timer.
I wasn't aware that Duke Nukem wrote to port 43 before every PC speaker update. It's not that common to do so with PC speaker code, because it will give a rather harsh sound. Also, the sound will become somewhat CPU-depdendent, since slower CPUs take longer between the two writes.
Therefore most PC speaker routines only update the counter normally.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 1696 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

According to my test code, if Duke Nukem were to write the counter normally, it would lose the harsh buzz effect and sound more pure like it does now in DOSBox SVN.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1697 of 2397, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

Is PIT mode 3 used by any PC games or past demos? I recall there was discussion on your github site about its use in the PC-98, and that mode=3 is also available on the PC (accurate emulation).

Reply 1698 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
hail-to-the-ryzen wrote:

Is PIT mode 3 used by any PC games or past demos? I recall there was discussion on your github site about its use in the PC-98, and that mode=3 is also available on the PC (accurate emulation).

Mode 3 is the square wave mode of the 8254. All timers on the 8254 have the same selection of modes. What differs between them is what each timer is connected to.

Mode 3 is the default mode when making beeps with the PC speaker, other modes are the exception to the rule. Mode 0 is used with the PC speaker when games do "digitized speech" on the PC speaker for example.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1699 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
hail-to-the-ryzen wrote:

Is PIT mode 3 used by any PC games or past demos? I recall there was discussion on your github site about its use in the PC-98, and that mode=3 is also available on the PC (accurate emulation).

Timer 0, tied to IRQ0, is normally mode 2 but sometimes used in Mode 3. Either one works fine to fire IRQ0 periodically.

I found a PC-98 game, Steel Gun Nyan, that sets PIT0 into square wave mode 3, then polls the IRR register of the master PIC to wait one period of time.

In the demoscene, DoWhackaDo uses PIT0 as a one-shot interrupt (Mode 0) to schedule events.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.