FamiTracker? It ticks both boxes. Authentic (produces modules that can play back on a real NES) and libre (GPL). But it's of course a chip tracker with the limitations of the NES sound circuit, and not a generic sample based tracker so maybe not what you want.

2

(19 replies, posted in Nintendo Handhelds)

The downside with lsdpack is that the files can become pretty enormous, to the point that a 1 MB ROM might fit just one song.

3

(18 replies, posted in Nintendo Handhelds)

Coinpusher, you have e-mail.

Nope, that won't work.

Some devices (like LittleBits) do use a 3.5 mm plug for MIDI just because it's a smaller plug, and then would need an adapter. However, even for those devices, that cable WON'T work because the wires are connected to the wrong pins for that use. You'd need a different cable in that case.

CGB_SOUND is a test for GBC and it should fail exactly like that on a DMG. This is expected so no problem there. INTERRUPT_TIME again is a GBC only test ROM, and although I haven't confirmed it, it should likely fail on DMG as well. DMG_SOUND failing is suspicious, but ultimately probably unrelated since the test that failed relates to the wave channel and the glitch affected channel 1 as you said.

Do you have a recording of the startup sound or something else that showcases the bug?

I may be interested in acquiring this 'boy for research.

The rules for the trading post are laid out here. The 4th rule clearly states that a seller needs to indicate the price of the items being sold.
https://chipmusic.org/forums/topic/4040 … ost-rules/

And for the record, e.s.c. (as well as me) is a moderator. While this is not explicitly shown as a user title next to the post, you can click view forum moderators at the bottom of the page to confirm it.

e.s.c. wrote:

When in doubt on things like this, always trust nitro, even over college professors. Dude knows his stuff

To be fair, he's technically correct. (The best kind of correct as some people say.) But the use of the word ROM is colloquially acceptable in the context, and arguing that it's absolutely wrong, in my opinion becomes pretty much a hypercorrection.

Here's the deal with the checksum check: The check is done whenever LSDj detects an incorrect signature in the save data under the assumption that this also means that the cartridge is being used for the first time. But this also means that the check is performed if the save RAM got corrupted. And it also means that if you write a working save file to SRAM, LSDj considers the cartridge to already be initialized and skips the check. So it's possible both to get false negatives and false positives compared to the intended outcome of the test.

But what's more, the checks relies on a particular behavior in the memory mapper (MBC) on the cartridge. A typical Gameboy cartridge ill expose two 16k areas, one that will always be bank 0, and one where the program can select any ROM bank. However older MBCs (MBC1-3) would select 1 if you asked it to select bank 0, because selecting bank 0 would mean that the same ROM bank is visible in two different places in the memory map. The newer MBC5 does not have this behavior, and selects bank 0 when asked to. LSDj's checksum relies on the fact that bank 0 is selected when writing bank 0, which is the newer MBC5 behavior.

Some emulators, as well as some flashcarts, implement the MBC1-3 behavior, which also causes this error. The latest version of LSDj should fix this so it works on either type of cartridge, so upgrading might be a good idea.

So the question is, which type does your EMS64 cart behave as? Here's a ROM for testing this. It will also test the whole ROM image for corruption, but that's not what's interesting here. You're looking for what it says after MBC type. Could you please write this to your cartridge and see what it says after MBC type? If it says MBC1/3 that explains the mystery. If it says MBC5, then it truly is a mystery.

http://www.gg8.se/temp/verifyrom-mbctest.zip

Btw, if you thought to make a backup of the RAM data before writing new data to the cartridge, I might be able to recover the songs that were ost.

martin_demsky wrote:

but formulation is not accurate, because ROM cannot be rewritten, maybe eprom or these flash nand technologies.

In context, it's correct usage. Even though the flash memory can be rewritten, it works as a ROM for the most of the time. Even EPROM means electrically programmable read-only memory, which is an apparent oxymoron. But the point is that it fills the function that a ROM would normally fill, and is only seldom updated.

9

(4 replies, posted in Nintendo Consoles)

Orgia Mode wrote:

Ugh, interrupts are such a headache for me, but if anyone can help it is nitro. I will be keeping an eye on the progress of this.

It's not me in this case. I haven't coded for the NES at all, so I can only give general advice. GB is my console. I'd recommend asking for help in the NESdev forums or wait for one of the NES gurus to come around.

10

(4 replies, posted in Nintendo Consoles)

All the writes happen within microseconds of each other, and only the last (or should I say current) write is in effect. You would need to write a sequencer which writes a new value (for example) every frame in the NMI interrupt handler. So you would need to store a variable somewhere, and maybe a list of volume values in ROM that you would be reading one by one and writing to $4000.

NES is not the platform I program for, but I can still speculate a little.

When you're saying no audio playback, do you mean completely silent, or no PCM samples?

For NMIs to be triggered, you need to set bit 7 in PPU1 (register $2000). The example code does this for you. However the reference document Everynes suggests that writes to this register during the first frame after reset are ignored. Maybe you need to wait 1-2 frames, or wait for VBlank, after the call to init, but before the write to $2000.

RAM contains random data at power-on. Maybe Deflemask expects RAM to be cleared before calling init, but Nerdtracker's init initializes all the RAM it's using so that's why it works.

Might be obvious, but check whether Deflemask's manual has an example player routine.

Try running your silent ROM in a debugger like no$nes and see if you can figure it out by single-stepping the ROM to figure out what it does.

Check whether the file that's exported is NSF or NSFe or NSF2 and check with documentation whether that might matter. (I leave that work to you. wink )

Useful links:
http://problemkaputt.de/nes.htm
https://wiki.nesdev.com/w/index.php/NSF

12

(2 replies, posted in Nintendo Handhelds)

If you're able to make a backup of the save RAM and send it to me, I can restore the song. Do not save any new songs, as that might overwrite what's left of the deleted song.

13

(15 replies, posted in Nintendo Handhelds)

Orgia Mode wrote:

@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.

Orgia Mode wrote:

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.

14

(15 replies, posted in Nintendo Handhelds)

What's the goal here? Are you trying to build something that is musically useful? If so, you may wish to make it tunable to the standard ET12 (equal temperament, 12 tone) scale. Gameboy has about 6 octaves of useful range. Lower than C3, and the hardware can't reproduce it. Higher than octave 8, an the pitch precision becomes so low that you can no longer produce pure tones. That gives you about 70 notes that you'd want to hit, and then you can fill in the rest of the values between those, and/or extend the scale upward.

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.)))))

New in BGB 1.5.7 (2018-09-14)

  • Greatly improved accuracy, including pinball deluxe/fantasies, japanese crystal, koro dice, and many test roms

  • added speedrun mode (can be enabled as setting)

  • recovery save state

  • mappable button to start/stop recording audio/video

  • setting to not break on invalid opcode, instead hang as in reality

  • Made available a 64 bits version

  • MBC1 multicart (MBC1M) support

  • Improvements to debugger, including undo rom edits, ctrl+tab changes active control.

  • Fixed many bugs

PM'd