(10 replies, posted in Nintendo Handhelds)

Feonaoh wrote:

I don’t think it’s technically possible to write save data straight to microSD for two reasons: flash memory is not random accessible and power off while writing can damage all the data on microSD. So the way it works seems very logical to me.

With the right microcontroller on the cartridge it wouldn't be unreasonable. You'd need to have reads and writes handled by the microcontroller. This device can already load save data from the SD card into a fast-access medium. I haven't seen the board, so I don't know if it's using a µc with on-chip ram or some sort of non-volatile ram/eeprom chip.

To get "real-time" saving to the SD card, a cartridge needs to handle read/swrites to the SRAM fast enough for the Game Boy but also perform buffered writes to the SD card. There are definitely microcontroller chips out there that could handle that but the additional development costs and even the per-chip cost would make for a more expensive product. At that point, you're better off designing something like the Drag'n'Derp, which is even simpler to use and more robust.


(10 replies, posted in Nintendo Handhelds)

Feonaoh wrote:

When you turn off your Gameboy, save is stored in battery powered RAM. When you turn Gameboy on, it asks to backup save to microSD, if not, it removes from RAM. Also you can choose auto backup on startup. The battery is also used for RTC.

That's neat, though. It's not quite as easy as having the data go straight to the SD card, but for a budget cart it's a hell of a lot better than having to rely entirely on battery-backed RAM.


(10 replies, posted in Nintendo Handhelds)

Since these use SD cards, I'm guessing the battery is fork the working ram in some way? Can you back up that working ram back to the SD card easily?


(15 replies, posted in Nintendo Handhelds)

soulgun16 wrote:

...I would be mostly unsure of how I would make the midi code communicate with the arduinoboy code directly since the midi controller code would be designed to output midi and the arduinoboy would be designed to be listening for input midi, and I'm not sure how to get them to talk together within the same code, I only plan to use mGB for this project though

Your Arduinoboy wouldn't be running a realtime operating system (RTOS), so it wouldn't be two programs that talk to each other through an OS but rather a single program that extends the Arduinoboy functionality to include your desired button-based inputs.

I don't think it would be on the easier side for someone who has not programmed embedded systems.


(15 replies, posted in Nintendo Handhelds)

soulgun16 wrote:

...essentially how feasible is it to connect my 8 or so buttons I was going to use as a midi controller to the existing arduinoboy and combine the programs into one?

I'm confident that this would be totally possible. Obviously, it depends a bit on the complexity of the functionality you want to add, but you could do a whole lot even within the limitations of a pretty basic atmel microcontroller.

soulgun16 wrote:

Would they clash too much or use the same ports making it impossible?

Most atmel chips, and therefore most Arduinos and Arduinoboys, have plenty of spare digital pins available for use as inputs and outputs.

soulgun16 wrote:

Is it more trouble than its worth? (especially for someone who knows nothing about programming)

If you know nothing about programming then this project is definitely well out of your grasp for now. Arduinos make great platforms for learning electronics and software engineering but this project would require a lot of time invested in building up those skills before you could even begin to tackle this particular project.

Whether it's worth your time or not, that's a different question. If you already want to learn these skills then I don't think it would be a bad idea spending a year or so working towards those goals. I think that with hard work it would be possible for someone, depending on their aptitude, to learn the necessary skills in even as little as a few months if they worked at it.

It may be that you're getting enough capacitance to have an effect. You could trying swapping in some various small capacitors to see if you can achieve a similar effect.

You could even get one of those little variable capacitors used for radios — really old radios really used "air capacitors" — and then you can tune it to see if you can get a similar sound.


(15 replies, posted in Nintendo Handhelds)

mesaphlin wrote:

… the first one is - https://www.retrotowers.co.uk/gb-gamebo … t-card-64m

Holy smokes that's expensive for a GB USB 64M. The prices seem to have gone up on these everywhere, eh? Is that just since they've been discontinued or has this been a gradual thing?


(2 replies, posted in Nintendo Consoles)

Noplanet wrote:

Anyone have an executable build of the SNES tracker to run on SNES?


Or any other native SNES music programs(other than OG mario paint, already got that)

I see song players and whatnot, looks like most stuff is composed on PC and compiled for playback on SNES.

The software you linked to works (sort of) but it runs on Linux, macOS and Windows, not on the SNES. It produces output that can be played back on real hardware or in an emulator.

A few people in the past have attempted to make native SNES music trackers but I haven't seen any released publicly. Since the SNES mostly just plays back samples people generally just use existing sample trackers and then use converters like XMSNES or SNESMOD to convert the track to be played on the SNES.


(19 replies, posted in Nintendo Handhelds)

nitro2k01 wrote:

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.

Yeah, it's not ideal for playback on original hardware. It's not in the title but OP clarified that they were looking for a way to play them on their computer.


(19 replies, posted in Nintendo Handhelds)

This would actually be pretty doable for songs prepared with lsdpack. Since the resulting data is recorded as a series of register writes there is no complicated logic involved and the playback routine is much, much simpler.

Unfortunately, an lsdpack-format player—hereafter referred to as a .lsdp player—won't play .lsdsng songs, but frankly .lsdp might make a better format for exporting playable songs anyway.

Aaron Johnson wrote:

Hello Forum,

I am new to this site and in the short time that I've been here I've found a couple of threads that have solved a few issues I've had with my Homebrew program.

However, I need to create a "score" for my RPG game and don't have the skill (or talent) to even know where to start.

The music as you might know has to be a .mod file and size is an issue for the Gameboy Classic. The AAA game Last of Us has such a iconic soundtrack and the Gameboy is a 4 channel tin-can and what I've heard some of the artists here do with it is impressive, so where do I begin or find help?


You're making a homebrew DMG game? As I'm sure you'll soon realize, with much of your CPU time being used for game logic and graphics you won't be able to mimic everything you hear from Game Boy songs written with LSDJ and the like.

Your first step really should be to implement your music and SFX routines. Until you do that, it'll be difficult to start diving deep into doing arrangements of your music.


(7 replies, posted in Bugs and Requests)

It'll happen on any browser that blocks flash by default.

pcm2pwm v0.8.1 fixes a bug that was affecting the quality of the output.

Grab it now and see for yourself how much better the results are!


Find it hard to find or make samples for HT2's awesome sample feature? So did I, until I added a feature to my pcm2pwm program!


jefftheworld wrote:

Version 0.8.1 is out! A few years ago I added support for outputting in Houston Tracker 2's inverted format for my own use but I never got around to releasing that feature.

Well, that's the only new feature in pcm2pwm v0.8.1! Enjoy!


Version 0.8 is out! A few years ago I added support for outputting in Houston Tracker 2's inverted format for my own use but I never got around to releasing that feature.

Well, that's the only new feature in pcm2pwm v0.8! Enjoy!



(10 replies, posted in General Discussion)

Orgia Mode wrote:

I'm looking for raw data to send to a PWM DAC, or R2R DAC. I have no clue on what these encoded formats are.
LIke this sine wave:


This has 64 bytes per period for example.

Even with a PWM resistor-ladder DAC you can store the data in a few different ways. It really depends on your playback routine. What is your playback routine like? How does it read data and how does it control your output pins?

If you're using a 1-bit routine that wants a simple differential PWM byte stream you can use my tool below to generate that from any 8-bit WAV file and the readme has a little detail on how the playback routine would work.