Search options (Page 5 of 137)

I have not moved on, even though I haven't had time to work on LittleFM for a long time now. But I have thought about the exact thing you mentioned. The technical issues are as follows:

1) Accessing the flash from the GB side. Some of these carts don't have the /wr pin hooked up as catskull alluded to. But many do actually have it available, but with scrambled address bits, so A0 and A1 might be swapped for example. This is absolutely no problem to add support for though. Worst case, you'd need to do a small solder mod to connect the /wr pin, which is something that the carts often add the facility to do, because...

2) Some carts being sold actually don't have a battery. Instead, they modify the ROM so that it writes SRAM to flash when saving, and then restores it when the game is started again. This works ok enough for games, except that you get a one second or so delay after saving the game. But these particular cartridges are problematic for LSDj use since they won't retain SRAM contents on power-down.

3) Some carts come with 3.3 V or even 1.8 V flash operated at the Gameboy's 5 V, which is a gross voltage overload. In practice, it often works ok for a $5 product (if you're willing to risk that the cartridge might stop working at any time) as long as you're only READING from the flash. On writing, the flash chip will error out because of the overvoltage. This can often be solved by putting a diode in series with the supply to drop the supply voltage a little, again with the caveat that the cart could stop working at any time. So this might, again, require a hardware modification of the cart.

4) Flash chips are by their nature sector devices. You can write to a certain byte once, but you can't write to the same byte again unless you erase a bigger area called a sector, which are often 32-128 kB big on the devices in question. LittleFM was really a quick hack which took the path of least resistance and saved data corresponding to 1-2 sectors at once. If the sectors are 128 kB big, you might choose to either waste the remaining 96 kB, or do something more tricky like saving multiple copies of the same song, or saving different songs in the same sector and defragmenting the file system every now and then or something like that.

One solution that solves both 2 and 4 simultaneously, would be to implement support for something like a file system that saves every modification to the song to flash sequentially, as an address being changed and what byte was written. This would work very well, except that it would require a lot of modifications to LSDj. At that point I might as well write my own GB tracker. While that's actually a tempting idea, it would take a LOT of work.

If the kick is a sample (kit) then this may be a side effect of the antispike fix I suggested that Johan should add a couple of years ago. This makes kits less noisy, and in particular makes them usable at all on GBA, which would otherwise have sounded horrible.

I suggest you record in live mode instead, which lets you literally only play one channel at a time, rather than playing all channels and soloing one channel.

Aluminium is heavier than plastic, assuming the same structure. The heat dissipation advantage really only holds true if the heat-producing components are thermally bonded with the case. A Gameboy shouldn't need the extra heat sinking anyway. Also, as I've repeated everywhere I've had the opportunity, I'm 95% sure that's not actually aluminium, but regular ABS plastic with a silver finish. Think the original Nintendo DS's silver finish as an example, and of course any number of random products. Maybe I will have to eat my words when the thing comes out, though...

New version released.

New in BGB 1.5.5 (2017-11-27) - Added support for GUI display scaling. Improved input lag on 120 Hz display mode. Improvements to debug messages. A number of bug fixes and small improvements.

Roni, I've replied to your PM.

One common cause of this type of fault is that you might've briefly shorted two adjacent pins on the ribbon cable while inserting or removing it. In particular, the LCD drive voltage (-19 V) and the combined line used for reading the state of the left and B buttons. For this reason, you should NEVER insert or remove that ribbon while the power is on.

If this is the case, booth left and B have been permanently fried, and the CPU is basically unusable, unless you find an application where missing those buttons is acceptable. (Maybe external MIDI control?) If the B button is still functional you know that this is NOT the fault though, and you should look for a place where something connected to ground is shorted to something else.

Have you checked continuity between the two pin 13's with a meter or only through visual inspection? Something like micro-crack in the trace, or a dry solder joint that has separated from the surface can be hard to detect visually.

If you look at the SID datasheet page 3, you'll see that voice 1 and 2 are in the lower half of the memory map, where A4=0. So it seems like for whatever reason, the second chip is not reacting to writes to the top half of its memory map. This could be because the A4 line is broken on the SID2SID. (If it was broken elsewhere, the same problem would affect both chips equally, even without the SID2SID.) It could also be because the IO1 pin doesn't decode correctly when A4=1 for whatever reason, which could be an issue with the machine itself.