Search options (Page 12 of 22)

I don't think a bad battery would cause a burning smell... If the cart was failing it is possible for the GB to run code it is not supposed to and corrupt your data. Is the smell coming from the cart or the gameboy? Is either getting hot?

I'll take a look for you tonight. I remember it being defined in one of the modules if you want to take a look

Should be displayed in the Arduino 'terminal' or even open hyperterminal (Do they still ship that with the later windows releases?) and see it in there.

It may not even be printf... I just assume it is as its C based. I'll give it a Google.

I used an Arduino once for a project at work, I disliked everything about it, the syntax, the libraries, no branching, code size and the speed it executes your code at. It takes what is a competent microcontroller and reduces it down to a black box with a weak, slow and limited instruction set. Just my opinion.

Heard the ROM didn't work on the Derp, fixed up the ROM header so that should be all good now. Also removed a lot of the Pot code, just referenced to 3 ROM locations now. Once I get a sample of the 3 bytes the ArduinoBoy sends out I can finish off the serial handler routine to populate these three ROM locations and we'll have ourselves an external Pot controlled GB303 that will run from your average Flash Cart.

Latest Iteration here: www.bennvenn.com/GB303_Snapshot3.rar

Sorry, no github yet. I'm using what scraps of spare time I find to work on the coding.

Can anyone tell me the 3 bytes the Arduinoboy sends the gameboy on a CC instruction via the MIDI interface? Otherwise I need to order an arduino and throw one together - could take a few weeks from China...

Thank you both, completely get what you are saying, problem still being my XP and apparent non-compatibility with Github. I'll start editing code on my Win8 Laptop so you should see my code on Github soon enough. Until then, here is my latest iteration. Full SRAM port, Auto load, load and save both pattern and songs. www.bennvenn.com/GB303_Snapshot2.rar

There is still code in there I need to pull out and also code that needs updating.

Please test out the SRAM implementation and let me know if I have missed anything.

Next update will be MIDI control of the 3 pot controls.

OK, I'll read into it a little more. I might need to re-fork and apply my code changes again to satisfy the client.

How is it we can all work on the code at the same time and not step on each others toes? It seems the way Furrtek has coded the ROM a lot of modues are inter-connected and a change in one routine has consequences on others. We could leave the original code there and build around it but that would bloat the binary with unused routines and make it very confusing for new contributors.

I haven't worked in an environment where there are multiple contributors so this is new to me. I do comment almost every line or atleast function to make it easy for others to follow. In my mind, 2 people working blindly on one project will end in disaster. Ideas?

I was looking through the serial handler routine a few days ago and noticed no real frame reconstruction. As you may know, MIDI isn't one byte per instruction; it uses a series of bytes. Furrtek's code looks for the start byte (This is all from memory, could be a lil bit off) and then processes it if it satisfies its filter. This is likely why it takes a few consecutive midi strings to re-sync. Should be an easy fix - Had to implement something similar in my linker code.

I tried installing the WinXP Github program that was linked earlier but no good. The installer wants some service pack that I'm not running. I think I'll give up with the whole Github thing. It would be very usefull but isn't necessary.

We can discuss the code dev here?