Search options (Page 28 of 137)

Try these places:

http://www.personal.triticom.com/~erm/GameBoy/
http://www.subport.org/gbc/

I might also consider making a GBC compatible version of Shitwave (that is, including the graphics) but it was all meant to be a half joke originally.

First of all, there's already http://iiichan.net/boards/music/

Random comments:

And secondly, which fiel types are allowed? It doesn't say anywhere, but I would expect that relevant file types like sav, lsdsng and various module format would be allowed.

I just joined the IRC channel, and it was empty. No good if you want to keep your ops.

Another thing. Looking at the rules, I found this: "No adult content, this is a SFW site." For a chan, I would personally phrase that differently. What about on-topic, but tangetially NSFW images? Say... discussions about Custer's Revenge or this Anamanaguchi gif which features bare breasts. Or just generally borderline on-topic art. Maybe a minor point, but nevertheless one I felt like bringing up.

I will answer the long due unanswered questions.

Nanoloop: I'm sorry that I have neglected this question. NL cartridge support is not yet ready, simply because I haven't gotten to it yet. I want to do a minor reorganization of the over-all code before getting to it, but when that's done I will add the NL support. NL cartridge support should not be problematic and is an expected feature, but I do not want to announce it as done until it's done and confirmed to be stable.

I have two older NL cartridges, that were generously donated by Bud Melvin and someone else whose name escapes me, as well as an NL One. At a later point, I may want to borrow other cartridges if they are significantly different in function from the ones that I have. It may also be possible to add support for this remotely, that is, to send a beta version of the software to someone owning a flasher and a Nanoloop cartridge and let them try it.

Mac OS X support: I have currently installed a Hackintosh setup to allow me to test the software on OS X, and so far it works well. The software is written in Python, and the hardware is using an FTDI virtual serial port chip, which should make the software very platform independent. Currently Windows, OS X and Linux are confirmed working platforms, but even something like BSD or even Solaris should be a problem if there is just an FTDI serial driver for those systems.

The only cloud on the horizon with regard to OS X support is a problem reported to affect Arduino users. This problem stems from the fact that Apple included their own driver for interfacing FTDI chips. I have a hunch that this problem may affect ALTANE as well, if the problem is what I think is. Unfortunately I don't have access to a Mavericks installation to confirm this. (I've only been able to install Snow Leopard, OS X 10.6 so far.) There are three possible outcomes:

1) There actually is no problem using ALTANE on Mavericks. (Hooray.)
2) The problem is what I think it is, and I will be able to work around it easily.
3) ALTANE is affected, and I can't figure out a way to solve the problem. In this case there is still a work-around that involves installing FTDI's original driver.

For now, I'm confident ALTANE will be able work on all (modern) versions of OS X, including Mavericks.

Reference: http://forum.arduino.cc/index.php?topic=198539.0

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