-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
APU CH1 and CH2 volume envelope only work when AOI_MUX_2 cells have output inverted #77
Comments
Same goes for the volume envelope of CH4. It needs AO_MUX_2 cells instead of AOI_MUX_2 for The two AOI_MUX_4 cells on the same page (page 20) also need to be AO_MUX_4 for the noise generator to work. I'll explain why. Please see #79 first, so you don't get confused about the labels. I tested channel 4 on a real DMG CPU B Gameboy and in a simulation with Icarus using the following register configuration and compared the sound that came out of it: Because of these tests I strongly believe that all the AOI_MUX_n cells are actually AO_MUX_n, becuase they all look the same. They have two rows between the last input and their output at the bottom. This could be enough space for the inverter which would make them AO. |
Also on page 20, the AOI_MUX_2 |
I explained here why: furrtek/DMG-CPU-Inside#77
Fixes #114. Switching the LFSR width on the noise channel without retriggering the channel can cause our LFSR to run out of 1's, rendering the output silent until the channel is retriggered (using NR44 bit 7). This is due to the current implementation of the LFSR that differs from the Gameboy hardware; it moves the taps and provides only a single point of feedback whereas hardware keeps the taps in place and adds a second point of feedback near the middle of the LFSR (creating a "split-off" 7-bit-wide LFSR). cf. https://gbdev.gg8.se/wiki/articles/Gameboy_sound_hardware#Noise_Channel The schematic reverse engineered by @furrtek mostly supports this description, except the taps being XNOR'd, not XOR'd: https://github.com/furrtek/DMG-CPU-Inside/blob/master/Schematics/20_CHANNEL4.png However, implementing the LFSR strictly according to the schematic lead to a similar issue; there is reason to believe that the output of the "AOI_MUX_2" selecting the additional feedback point is actually non- inverting as opposed to the schematic: furrtek/DMG-CPU-Inside#77 (comment) Treating it as an AO_MUX_2 indeed yields correct-sounding output. We can also assume that the flip-flops composing the shift register are reset to 0 by their /RESET inputs; this also fits the XNOR tap well. Here is a before-after comparison of the initial LFSR state (wide mode): - old - - new - 111111111111111 000000000000000 011111111111111 100000000000000 001111111111111 110000000000000 [...] 000000000000011 111111111111100 000000000000001 111111111111110 100000000000000 011111111111111 [...] Due to 0 initialization and inverted tap output, the state is basically the inverse of the old version, up to the point of a width change. As a result the noise channel of most tracks (which do not expose the bug) is now inverted. Here is a before-after comparison of the LFSR state of previously incorrect playback, taken from Castlevania 2: - old - - new - 000001010101000 111110101010111 000000101010100 111111010101011 000000010101010 111111101010101 * at this point the game changes LFSR width to 7 000000001010101 011111110101010 000000000101010 001111110010101 000000000010101 000111110001010 000000000001010 000011110000101 000000000000101 000001110000010 000000000000010 000000110000001 000000000000001 000000010000000 000000000000000 100000001000000 000000000000000 110000001100000 And, indeed, the missing parts are now audible and akin to a real hardware recording.
I can't get the volume envelope function of APU channels 1&2 working without somehow inverting the clock that goes into the COUNT cells
HEVO
...HAFO
(CH1) andFENA
...FENO
(CH2). They are counting in the wrong direction. I checked the schematic with the die shot and can't find any wrong connections that could cause that. So I think one of the following things must be the case:When I modify the behavior of the COUNT cells in any way (or multiple ways at once), they are causing the APU to break everywhere else they are used. This is why I can only think of the AOI_MUX_2 cells being the culprit here. I haven't simulated everything yet, so I can't say if changing them to "AO without I" will break anything else.
It is also possible that silly me has a totally wrong understanding of the COUNT cells. I see them as flip-flops that toggle on a falling clock edge and can be asynchronously set to D whenever LOAD is high. At least this is how they work for me correctly in other places. Here's a truth table:
Please let me know if I misunderstood their function.
The text was updated successfully, but these errors were encountered: