Difference between revisions of "Talk:PC speaker sound effects"
From DoomWiki.org
(More info.) |
(→DMX formats 1 & 2: Confirms my suspicions) |
||
(One intermediate revision by one other user not shown) | |||
Line 281: | Line 281: | ||
:: On further research, that function is the function which does the actual output. It is invoked after setup code is run to initialize the global variables it accesses, which is in sub_4BD70. sub_4BD70 is invoked from SFX_PlayPatch when the DMX sample format byte is " < 1u" (DMX sample formats 1 and 2, which are unknown, are dispatched to sub_4C260; format 0x03, which we know to be the [[sound]] format, is dispatched to sub_48430, which I already did substantial reversing work on earlier). --[[User:Quasar|Quasar]] 07:21, 25 January 2014 (UTC) | :: On further research, that function is the function which does the actual output. It is invoked after setup code is run to initialize the global variables it accesses, which is in sub_4BD70. sub_4BD70 is invoked from SFX_PlayPatch when the DMX sample format byte is " < 1u" (DMX sample formats 1 and 2, which are unknown, are dispatched to sub_4C260; format 0x03, which we know to be the [[sound]] format, is dispatched to sub_48430, which I already did substantial reversing work on earlier). --[[User:Quasar|Quasar]] 07:21, 25 January 2014 (UTC) | ||
+ | |||
+ | == DMX formats 1 & 2 == | ||
+ | |||
+ | [https://github.com/chocolate-doom/chocolate-doom/issues/639 This] is an interesting discovery by Alexey Khokholov: DMX sample formats 1 and 2 correspond to MIDI data! --[[User:Gez|Gez]] ([[User talk:Gez|talk]]) 13:28, 10 November 2015 (CST) | ||
+ | |||
+ | : I knew at least one was considered as being for "AdLib" due to code that is present in the pre-beta, but I was never able to crack the DMX code doing the format reading for them because it devolved into a bunch of function pointer calls and a ton of data movement that I couldn't effectively trace. Interesting to have my suspicions confirmed. --[[User:Quasar|Quasar]] ([[User talk:Quasar|talk]]) 16:35, 10 November 2015 (CST) |
Latest revision as of 17:35, 10 November 2015
Hardcoded values[edit]
If you look at DOOM2.EXE v1.9 with a hex editor, you'll see at offset 0x89064 the beginning of a table of unsigned 16-bit LE values which correspond to the counter values.
|
|
|
|
After the 128th value, there are several null bytes. This really looks like the table containing all the counter values that get programmed into the 8253 chip. This also shows that there are valid values above 95 -- the doc included with Andrew Apted & Simon Howard's specifications said that it "is not known if higher values are supported" -- I think this shows that they most certainly are. --Gez 18:40, 24 January 2014 (UTC)
- On further research, that function is the function which does the actual output. It is invoked after setup code is run to initialize the global variables it accesses, which is in sub_4BD70. sub_4BD70 is invoked from SFX_PlayPatch when the DMX sample format byte is " < 1u" (DMX sample formats 1 and 2, which are unknown, are dispatched to sub_4C260; format 0x03, which we know to be the sound format, is dispatched to sub_48430, which I already did substantial reversing work on earlier). --Quasar 07:21, 25 January 2014 (UTC)
DMX formats 1 & 2[edit]
This is an interesting discovery by Alexey Khokholov: DMX sample formats 1 and 2 correspond to MIDI data! --Gez (talk) 13:28, 10 November 2015 (CST)
- I knew at least one was considered as being for "AdLib" due to code that is present in the pre-beta, but I was never able to crack the DMX code doing the format reading for them because it devolved into a bunch of function pointer calls and a ton of data movement that I couldn't effectively trace. Interesting to have my suspicions confirmed. --Quasar (talk) 16:35, 10 November 2015 (CST)