Search options (Page 3 of 137)

bitwise: Just to be sure, did you also let the test run for at least one iteration to see if there was any problem detected with the ROM integrity?

Like I said though, they are almost always defective in some way, mostly the filter. So keep that in mind.

I believe the main issue with early GBC CPUs is with the length timer function. In LSDj that's the LEN setting in the instrument view. In asm, that's bit 6 of the NRx4 group of registers. If you activate that function at any point for a channel, and then write to the pitch register, there's a risk that the channel stops playing, as if the length timer expired. This is especially obvious during vibrato and other pitch effects that change the pitch often. I think if you never activate the length function you should be fine.

5th voice and GBVideoPlayer2 are not relying on hardware bugs per se, but on the correct implementation of DC offsets as well as fast/correctly timed sampling of register changes. DC offsets were sometimes not considered important among emulator authors because it requires precise hardware research, but the only benefit an emulator would get (before these tricks were invented) is that the little clicks when a channel starts playing or when settings are changed sound correct. Correct sampling of register changes means that the emulator would have to emulate aspects of the audio emulation at higher sample rates than the audio output. (Essentially 1 MHz vs the usual 44.1 kHz) It would, again, be a lot of effort for essentially no benefit before these tricks were invented. Which is way it wasn't really done in emulators until the era of accurate emulation that started about 10 years ago.But there's nothing to suggest that those things would be more likely to be incorrect on a hardware clone.

If you want to discuss GB audio programming, feel free to shoot me a message.

R1, R2 are wrong value (about 10x too high value). R5 is also wrong value (about 10x too low value). I can't see R7 so can't confirm the value of it.

New in BGB 1.5.8 (2020-03-17)

• Added mode where RTC stays at real time.

• Accuracy improvements.

• Improved speedrun mode.

• Fixed graphics not showing on some wine setups.

• Improved fullscreen pageflipped mode.

• Improvements to debugger.

• Fixed many bugs.

BGB homepage

This sounds curious. The save file is automatically written to disk about every 4th minute (or every 256 seconds to be exact). What exactly do you mean by crash? A bluescreen, or something less serious? Or only BGB crashing?

If you just load the ROM again immediately after the crash, you should with a high chance return to almost where you were without doing anything else.

The recovery save state is something different. It's a one-shot feature that protects against accidentally closing BGB or quickloading a savestate. The recovery save state is NOT saved periodically or if your computer crashes, however. If you loaded bgbrecovery.sna after a crash, chances are that you've overwritten your save data with old data from when you last closed BGB normally.

If you can send me bgbrecovery.sna as well as your sav file I can take a look to see if there's anything that can be recovered. My e-mail is my username followed by @gmail.com.

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.