Search options (Page 23 of 137)

You need to set the SRAM size in the header, as well as specify an MBC type that supports SRAM. For a regular flashcart, this doesn't matter since the hardware is the same no matter what, but an emulator has to rely on the ROM header to know what features the ROM wants to use. If a flash cart is using a multi ROM menu, it may also restrict the RAM size and other parameters based on the values in the header.

You can set these values for examples with rgbfix, which I'm assuming you're already using for fixing the header checksum. This is described in Pandocs, see the link below. 1B, MBC5+RAM+BATTERY is a good choice for the MBC type. Set the RAM size parameter as needed.

http://problemkaputt.de/pandocs.htm#thecartridgeheader

You may also want to check for the presence of actual SRAM before showing the save button. This helps it work better if someone decides to make a 32 kB cart of the ROM. You may also want to confirm the data that was written before deciding it worked. In the same vein, you may want to add a checksum or identifier for the data, so it can be validated when loaded, in case something else already exists in SRAM, like a game save, or an LSDj save.

RAM is not strictly necessary. If you're using a flash chip (which I'm assuming is the intention, rather than a one time programmable chip) you can store song data on the same chip, since teh chip is divided into sectors. As a matter of fact, I may be interested in getting 4 of those boards, bare. I once got the opportunity to pick chips from stuff that was going to be thrown away. Among those were 4 pieces of PA28F400 in a PSOP 44pin package. This is an Intel flash chip with a 16 bit bus, which I thought might come in handy one day. I wouldn't be surprised if the pinout and package type matches, in which case I would be interested in having 4 of those boards for use with those chips.

The cartridge connector pads on the end of the cartridge that goes into the gameboy are used by the Gameboy to control the flash chip etc in the cartridge. When you're flashing the cartridge, there's another controller chip in the cartridge that is also trying to control the flash chip etc. When both are connected in the same time, they may interfer.

Can you be more specific with what doesn't work means? Are you getting an error when flashing? Does the flasher program hang when you're trying to transfer LSDj in particular? Does it seems to work, but the cartridge starting up and showing the old ROM? Does it show a garbled logo? Does it crash on start? How does it look when it's crashing? "Doesn't work" is the least productive description for any kind of error report.

This thing seems like a polite and clever way of asking for donations while the user doesn't have to browse through the massive archive of GOTO80 tunage.

You have to run the specified commands from the Windows command line (start, run, cmd) not from the Python prompt. You also need to be in the right directory. Maybe I ought to make a GUi version...

That method can only be used for synths that will accept pulses. Any Gameboy will filter away any constant DC level, so if you use it for a gate, the gate will be extremely short if it works at all. And CV control, forget it. You may be able to bypass the coupling capacitors and get raw DC levels out of it, however, then you'll get extra DC offsets which may be undesirable. With this method, you could also do CV (pitch) control but likely in non-harmonic steps (whatever voltages the Gameboy happens to output.. I've been meaning to explore this at some point, but haven't gotten to it. (Hello Infradead.)