Search options (Page 28 of 137)

If you are able to get sav file off the cartridge and send it to me, I may be able to recover it. nitro2k01 att gmail dott com.

There is no fundamental reason why this couldn't work. The SRAM chip is 128 kiB, which is what is needed for LSDj. Maybe, maybe, the cartridge is using some or all of the extra space (over 32 kiB) for temporary storage when transferring data to/from the SD card, which would make it unavailable to LSDj for save files. If I had an Everdrive GB myself I could investigate this myself. But the first avenue would be to discuss this with Krikzz himself. I think I will do so, actually. Another possible option, which kind of sucks but should work, is to use one copy of the ROM per song.

Try this ROM:

http://blog.gg8.se/gameboyprojects/week04/bgblogo.zip

It shows you which buttons are being pressed. Maybe the problem is not that the D-pad doesn't work, but that something else happens, like pressing the D-pad at all, makes all buttons register as pressed, or there is a stuck button.

Did you attach all screws for the LCD board? When closing the case, are you noticing any tension anywhere?

Can you explain what "when i push it at the very bottom" means exactly? Does the D-pad stop registering when you're pushing the case at the bottom? Does the D-pad stop registering when you press it as hard as you can? Is the D-pad dead and doesn't even  register when pressed as hard as you can?

And a general warning, never attach or detach the ribbon cable while the Gameboy is powered on. Doing so may short two of the pins in a way that permanently destroys the left and B buttons.

This is in itself another possibility. You could use say a Saleae USB logic analyzer and their API for getting data. As long as you are able to record and convert the logic stream uninterrupted on the PC, you have recording right there.

Nailed it. The advantage is the predictability. Once you know display data is about to come, you can send CPU clock pulses and blindly scoop in the data at the correct intervals until the end of the line. I'm claiming this to be doable with, not a 96, but with a 24 or maaaybe even 12 MHz AVR, and I'd be up for the challenge, if I can be bothered.

Details: Back of the envelope calculation of the data rate: 160*144*60*2=2764800 bits per second. An FT232 can handle up to 3 Mbaud communcation. Accounting for 1 start bit and 1 stop bit, that becomes 3000000*8/10=2400000 bits per second actual transfer rate. Too slow, darn. So the choices are to underclock the CPU to 87% of it's regular speed, or come up with some form of compression. RLE compression should work well enough to most situations, as a typical game screen will contain at least 13% repeated data. (That is, the same tile repeated multiple times vertically.) This leaves one problem, though, which is that the screen data isn't sent at the same rate from the GB CPU. It's done in bursts, one line at that time, and then takes a break in the HBlank and VBlank periods, so you would need a serial data ring buffer. But meh, should be easy enough. (Famous last words.)

As for the teensy code. I'm not familiar wiuth how it works, but mostly likely the CPU will be busy for a short while, while the USB processing code is running. In that period, you're missing display data. And also, please don't use interrupts for this. Interrupts are great when you need the CPU to do something else, and still have the ability to be interrupted, but each interrupt does have an overhead which means that they're not suitable for this project. Use a polling loop instead. (For example.)

In theory, yes. A USB bleepbloop is no different from a non-USB bleepbloop, looking form the cartridge side. However, that of course assumes that the cart isn't otherwise broken, which might prevent the cart from being flashed.

Since I pretty much lack personality, I was wondering what someone would come up with to sneak me in.