33 Reply by nitro2k01

(7 replies, posted in Commodore Computers)

To be the bearer of bad news, they are indeed almost certainly fake or at least remarked. As documented by Kevtris back in 2008, that specific date code was known to be sold by the same seller that sold him fakes. It's otherwise a good read on the topic. If you wipe the chip with acetone, the top layer will likely come off and reveal a 6581 chip. The "fakes" are not actually fake, but rebranded SID chips that are real but defective. Typically it's the filter that goes while the oscillators are still working.

http://kevtris.org/Projects/sid/remarked_sids.html

I'm kind of torn on the issue morally speaking. Imo, it would be a waste of rare SID chips to throw away something that's almost working. Individually testing them and selling them with an honest description of any defects might be an option, but on the other hand that wouldn't stop the next person from passing them on as 100% working and making a big profit. Using them in a personal project might be an option instead, or maybe contacting Look Mum No Computer and suggest the idea of a mega SID machine consisting of only fake SIDs.

Go to forum: Commodore Computers

34 Reply by nitro2k01

(3 replies, posted in General Discussion)

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.

Go to forum: General Discussion

35 Reply by nitro2k01

(54 replies, posted in Nintendo Handhelds)

That sounds like version differences in LSDj. LSDj recently overhauled its vibrato/pitch bend code among other things.

Go to forum: Nintendo Handhelds

36 Reply by nitro2k01

(9 replies, posted in Other Hardware)

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.

Go to forum: Other Hardware

37 Reply by nitro2k01

(8 replies, posted in Bugs and Requests)

jefftheworld wrote:

This site is probably small enough to fly under the radar, but technically it's a requirement that citizens of EU states are able to delete or request deletion of their data.

That is an EU law. Chipmusic.org is owned and operated by Tim, who's in the US. Big corporations and news sites have to care about GDPR because they either have local offices in the EU, or rely on advertising shown by ad agencies in the EU. But it would be difficult to motivate why a 100% US run site would have to abide by EU laws, when it doesn't have any business (as in local branches or money exchanging hands) anywhere in the EU.

However, the policy to not delete accounts on CM.O of course has nothing to do with mining data for profit, but is there to preserve useful information and history about the chip scene. It came about as a reaction to 8bc at the time, where users with in some case thousands of posts asked to have their accounts deleted, which created a large loss of information.

I've discussed this privately with hermit, and we've reached a solution.

Go to forum: Bugs and Requests

38 Reply by nitro2k01

(54 replies, posted in Nintendo Handhelds)

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

Go to forum: Nintendo Handhelds

39 Reply by nitro2k01

(30 replies, posted in General Discussion)

I have it on good authority that LSDj was called FuckTracker before it was released publicly.

Go to forum: General Discussion

40 Reply by nitro2k01

(54 replies, posted in Nintendo Handhelds)

.exe wrote:

How do you use the recovery save state? My computer crashed while using LSDj and I lost my song. Too late now but I'd like it to not happen again.

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.

Go to forum: Nintendo Handhelds

41 Reply by nitro2k01

(3 replies, posted in Nintendo Handhelds)

Try using the latest version of the LSDPatcher. Older versions didn't fix the ROM checksum but newer versions do.

Go to forum: Nintendo Handhelds

42 Reply by nitro2k01

(16 replies, posted in General Discussion)

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.

Go to forum: General Discussion

43 Reply by nitro2k01

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

Go to forum: Nintendo Handhelds

44 Reply by nitro2k01

(18 replies, posted in Nintendo Handhelds)

Coinpusher, you have e-mail.

Go to forum: Nintendo Handhelds

45 Reply by nitro2k01

(2 replies, posted in LittleGPTracker)

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.

Go to forum: LittleGPTracker

46 Reply by nitro2k01

(7 replies, posted in Nintendo Handhelds)

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.

Go to forum: Nintendo Handhelds

47 Reply by nitro2k01

(11 replies, posted in Trading Post)

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.

Go to forum: Trading Post

48 Reply by nitro2k01

(18 replies, posted in Nintendo Handhelds)

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.

Go to forum: Nintendo Handhelds