ld a,[hl] ; A reg has high 3 bits.
set 7,a ; when set, sound restarts.you can do
ld a,$80
or [hl]to save another 4 cycles 
If you reorganize the whole block to set HL first, you can save another 8 cycles because you'll need to set A=$80 only once.
irrlichtproject wrote:You need an opcode table that lists instruction timings. I used this one: http://www.pastraiser.com/cpu/gameboy/g … codes.html
Not the best but it does the job. The timings are listed below the opcode names; the number to the left is the instruction size in bytes, and the one to the right is the cycle count.That is very helpful. I think I came across that page ears ago, but didn't need it at the time. Thanks!
Can anyone elaborate on these bullet points:
source>>If the wave channel is enabled, accessing any byte from $FF30-$FF3F is equivalent to accessing the current byte selected by the waveform position. Further, on the DMG accesses will only work in this manner if made within a couple of clocks of the wave channel accessing wave RAM; if made at any other time, reads return $FF and writes have no effect.
>>Triggering the wave channel on the DMG while it reads a sample byte will alter the first four bytes of wave RAM. If the channel was reading one of the first four bytes, the only first byte will be rewritten with the byte being read. If the channel was reading one of the later 12 bytes, the first FOUR bytes of wave RAM will be rewritten with the four aligned bytes that the read was from (bytes 4-7, 8-11, or 12-15); for example if it were reading byte 9 when it was retriggered, the first four bytes would be rewritten with the contents of bytes 8-11. To avoid this corruption you should stop the wave by writing 0 then $80 to NR30 before triggering it again. The game Duck Tales encounters this issue part way through most songs.
Alright, I think I figured it out.
When I reload $FF30 - $FF3F, have to turn it off, then load it and then re-enable it and then re-start the wave form, like so:
updateWaveSample:
; check if a new sample was selected, other wise skip it.
.tstOldWave:
ld a, [AUD3wave_RAM]
ld hl, AUD3wave_RAMold
cp [hl]
jp z, .noWaveUpdate ; skip if they are exactly the same
; otherwise, choose which sample to load
ld h, waveTables>>8 ; its currently at $3200
ld a, [AUD3wave_RAM] ; $00-$FF
and %11110000 ; clear lower 4-bits, leaving 16 values for the user to select.
ld l,a ; hl now points to the selected sample.
ld a,$30
ld c,a ; C is the counter
xor a
ld [rAUD3ENA],a ; disable the wave channel here... test
.waveLoad:
ld a,[hl+] ; load the first byte sample, then increment the pointer
ld [c],a ; Put A into address $FF00 + C
inc bc ; c = $30,31 ... 3F
ld a,c
cp ($3F+1)
jp nz,.waveLoad
ld a, $80
ld [rAUD3ENA],a ; re-enable the wave channel here... test
; also need to re-start the wave channel with rAUD3HIGH bit 7
; get the current upper 3-bits of the frequency again. (it cannot simply be read from the register.)
ld h, expoTable>>8
ld a, [AUD3freq_RAM]
ld l,a
ld a,[hl] ; A reg has high 3 bits.
set 7,a ; when set, sound restarts.
ld [rAUD3HIGH],a
; waveLoading finished when $3F is loaded
ld a, [AUD3wave_RAM]
ld [AUD3wave_RAMold],a ; update the old user's input for wave ram selection
.noWaveUpdate:; other irrelevant stuff removed for brevity
ret
it seems to test correctly in several emulators, simulating a variety of CPU's.
]]>You need an opcode table that lists instruction timings. I used this one: http://www.pastraiser.com/cpu/gameboy/g … codes.html
Not the best but it does the job. The timings are listed below the opcode names; the number to the left is the instruction size in bytes, and the one to the right is the cycle count.
That is very helpful. I think I came across that page ears ago, but didn't need it at the time. Thanks!
Can anyone elaborate on these bullet points:
source
>>If the wave channel is enabled, accessing any byte from $FF30-$FF3F is equivalent to accessing the current byte selected by the waveform position. Further, on the DMG accesses will only work in this manner if made within a couple of clocks of the wave channel accessing wave RAM; if made at any other time, reads return $FF and writes have no effect.
>>Triggering the wave channel on the DMG while it reads a sample byte will alter the first four bytes of wave RAM. If the channel was reading one of the first four bytes, the only first byte will be rewritten with the byte being read. If the channel was reading one of the later 12 bytes, the first FOUR bytes of wave RAM will be rewritten with the four aligned bytes that the read was from (bytes 4-7, 8-11, or 12-15); for example if it were reading byte 9 when it was retriggered, the first four bytes would be rewritten with the contents of bytes 8-11. To avoid this corruption you should stop the wave by writing 0 then $80 to NR30 before triggering it again. The game Duck Tales encounters this issue part way through most songs.
]]>Hey hey, how did you calculate the cycles saved?
]]>As I stated before, I was taking a number between 0 and 255 and assigning a frequency value, but the gameboy needs an 11-bit number for the registers AUD1LOW and AUD1HIGH (and others). So I then took my frequency table and converted it BACK into a digital value with x=2048-(131072/Hz).
expoTable EQU $3000
SECTION "expotable",HOME[$3000]
;expoTable ; 512 bytes (256 integers)
; This table is not perfect by any means. I'll make the final "tuning" adjustments later.
DW 44, 98, 150, 201, 250, 299, 346, 391, 436, 479, 521, 562, 602, 641, 678, 715, 751, 786, 819, 852, 884, 916, 946, 976, 1004, 1032, 1060, 1086, 1112, 1137, 1161, 1185, 1208, 1231, 1253, 1274, 1295, 1315, 1335, 1354, 1372, 1391, 1408, 1425, 1442, 1458, 1474, 1489, 1504, 1519, 1533, 1547, 1560, 1574, 1586, 1599, 1611, 1622, 1634, 1645, 1656, 1666, 1676, 1686, 1696, 1706, 1715, 1724, 1732, 1741, 1749, 1757, 1765, 1773, 1780, 1787, 1794, 1801, 1808, 1814, 1820, 1826, 1832, 1838, 1844, 1849, 1855, 1860, 1865, 1870, 1874, 1879, 1884, 1888, 1892, 1897, 1901, 1905, 1908, 1912, 1916, 1919, 1923, 1926, 1929, 1933, 1936, 1939, 1942, 1944, 1947, 1950, 1953, 1955, 1958, 1960, 1962, 1965, 1967, 1969, 1971, 1973, 1975, 1977, 1979, 1981, 1983, 1985, 1986, 1988, 1989, 1991, 1993, 1994, 1996, 1997, 1998, 2000, 2001, 2002, 2003, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2018, 2019, 2020, 2021, 2021, 2022, 2023, 2023, 2024, 2025, 2025, 2026, 2027, 2027, 2028, 2028, 2029, 2029, 2030, 2030, 2031, 2031, 2032, 2032, 2033, 2033, 2033, 2034, 2034, 2035, 2035, 2035, 2036, 2036, 2036, 2037, 2037, 2037, 2037, 2038, 2038, 2038, 2039, 2039, 2039, 2039, 2040, 2040, 2040, 2040, 2040, 2041, 2041, 2041, 2041, 2041, 2042, 2042, 2042, 2042, 2042, 2042, 2043, 2043, 2043, 2043, 2043, 2043, 2043, 2043, 2044, 2044, 2044, 2044, 2044, 2044, 2044, 2044, 2044, 2045, 2045, 2045, 2045, 2045, 2045, 2045, 2045, 2045, 2045, 2045, 2045, 2046, 2046, 2046, 2046, 2046, 2046, 2046, 2046, 2046, 2046
Then to grab a number in my update code:
updateFreq12:
ld hl, expoTable
ld a, [AUD1freq_RAM] ; the 8-bit number from 0-255; located at $D00x for the record
ld l,a
ld a,[hl+] ; A reg has high 3 bits. HL points to lower 8 now
ld [rAUD1HIGH],a
ld a,[hl]
ld [rAUD1LOW],a
ret
Alternatively, I can get the 16-bit number from my table and shift the top 3 bits into AUD1HIGH, then load the remaining number into AUD1LOW. This process more closesly answers my original question. 
I'll code it up and see which compiles to the fewest lines.
Thanks so much for your help, guys!
]]>@nitro, is that what shit wave does? Just inject horseshit into the polynomial counter?
Nope. Shitwave is actually using the wave channel and the shift register it's using is all software.
EDIT: Shower thought, why is NR20 unused while NR10 (sweep) is present? The corresponding bytes in I/O are simply ignored, along with several other bytes, but this one in particular seems to have been planned ahead. A missed opportunity.
That would be to save silicon space on the chip. Though I'm not sure how much difference it would have made.
]]>I have primed all of the registers to be ready for user input and found that the noise channel is the most fun to play with!
Most noteable the AUD4POLY register. The broad range sund taht it can produce is outstanding.
@nitro, is that what shit wave does? Just inject horseshit into the polynomial counter?
EDIT: Shower thought, why is NR20 unused while NR10 (sweep) is present? The corresponding bytes in I/O are simply ignored, along with several other bytes, but this one in particular seems to have been planned ahead. A missed opportunity.
]]>Text wall:
EDIT: Crap...I did taht wrong. I have to translate an 8-bit number to an 11 bit number, not 11 to 11. 
I am just about to the point in code to begin using the lookup table.
]]>For example Imagine that every third value (0,3,6,9...) is a semitone, and the other values are pitches in-between. This gives about 256/3=85 available semitones, ranging from C3 to C#10 (~8.7 kHz) and 2 additional untuned values between each semitone.
Example Python code:
import math
# MIDI index to frequency
def m2f(m):
return 440*math.pow(2,(m-69)/12.)
# Frequency in Hz to GB pitch value
def f2g(f):
return 2048-(131072./f)
# GB pitch value to frequency in Hz
def g2f(g):
return 131072./(2048-g)
print ("Oct\tNote\tFreq (Hz)\tGB value")
# Print example data for human consumption
for i in range(256):
print "{0}\t{1}\t{2}\t{3}".format(i/3/12, ((i/3)%12)+1, m2f(36+i/3.), int(round(f2g(m2f(36+i/3.)))))
# Print assembly data
for i in range(256):
print "\tdw\t{0}".format(int(round(f2g(m2f(36+i/3.))))) ld h,table_base_lo_bytes>>8
ld l,a ; set index
ld c,(hl) ; load lo-byte
ld h,table_base_hi_bytes>>8 ; or just inc h if hi-byte lut follows on next page
ld b,(hl) ; load hi-byte, frequency divider now in BCWhat exactly do you want to do? Sounds like you're trying to generate note frequency dividers. If that's the case I'd definately recommend using a lookup table. It's gonna cost you 512 bytes at most.
Otherwise, just ld a,n, add a,a, rotate the carry into another register, rinse and repeat.
Thanks for the reply!
I am trying to receive serial data and convert it to a frequency, yes.
Now that I think about the size of a lookup table in actual quantized bytes, it may not be as large as I had originally thought. Since I have to worry about two registers, one 8-bits and one 3-bits (11-bits in total) that can equate to 256+8 numbers, so 512 was a very generous guess.
Now the next question: which method would require the fewest cpu cycles?
Once I get to this point in the code, I will write up both routines and add up the cpu cycles for each.
Again, thanks for the input!
-Cheers,
-Fox
Otherwise, just ld a,n, add a,a, rotate the carry into another register, rinse and repeat.
]]>