herr_prof wrote:

Midi clock data and note on/ofs are MUCH LESS data than someone tweaking a knob in realtime. I wouldnt be surprised if we are hitting a bottleneck on the gb serial port here, and it will need some sort of filter to cut down the bits we are bangin'.

DSC's arduinoboy code is pretty advanced in terms of digital filtering on the ADC inputs to prevent spurious MIDI CC's so the problem is not there, it would be the same effect from a midi controller. The issue as mentioned above is the data rate from knob tweaking in combination with no handshaking or error detection/correction. I'll find the refresh rate the original hardware used and limit the arduino code to that level. I know every iteration of the 'ReadPot' only read the value of one pot, changing every time it was called so I don't think the refresh rate on the original hardware was as fast as what could be achieved via MIDI.

The gameboy's serial port can sustain very high speeds. The bottle neck there is not the serial port but the speed the gameboy CPU can process the data. This has been tested in an experimental linker hardware where I can flash my flash cart in a very short time via the link port. 8mbytes transferred with zero errors in the bitstream. This makes me think the arduino is at fault. The serial stream is generated in software and perhaps an interrupt routine is not preserving registers at it should. In theory if the serial stream was out of sync, it would not get back into sync until 7 more errors occur in the bitstream and from the reports on here, it seems only 1 in a handful of MIDI commands are missed, supporting the theory that the error is generated in the arduino.

I have a MIDI keyboard/controller that I purchased for another MIDI project that I was working on so no need to crowdfund anything. I have an arduino in one of the many boxes I've packed (moving house) I just need to dig it out.

As for donations, DSC has been very generous in his contributions - not just via paypal but offering his own code he had developed and lessons learnt along the way. I am open to accept donations (Who doesn't like money!) but please understand that my real work takes me away from my computer (and often country) for weeks/months at a time. There are also unplanned commitments that I'm bound to at work and these take priority. I say this because I don't want to take anyone's money and not deliver. Any donations should be for the work that has been done or is in progress, not for promises etc... I hope you understand!

In other news, I've left my laptop, gameboy, flash cart, Joey Squinson and about 10 parcels I planned to post at my new house (3hrs drive away...) This really throws a spanner in the works. Wont be able to get down there till the weekend :-( I'll continue work via MGB and my GBC.

I'll try build the arduinoboy tonight, if the errors persist I'll re-write the code (arduino) from scratch in asm. You wont loose your bootloader so you can revert at any time and hopefully you'll loose all the bugs.

Yes, I don't intend on recreating LSDJ. Instead I want to reproduce the missing hardware externally and MIDI seems to be the best way to do it. I'd like to keep this software as the author intended, without the bugs and maybe add a rich set of custom wave tables / instruments etc. Flash carts have an enormous amount of storage, might as well use some of it!

Jazz, You're right, internal vref is only 1.1v otherwise it is referenced to avcc or aref which will be 5v.

DSC, if the option to modify the arduino source is there, I'd add code to check a test byte the GB will send every time the arduino sends a byte. If the byte is not aligned it will indicate a bad sync condition and can then strobe the clock line without data until the sync byte is correct. The GB will always return a byte as one is incoming so there would be no performance loss in the GB, the arduino will have to clear the bad sync which will take a couple of hundred microseconds then resend the Midi instruction.

As herr_prof says, this may have to wait until I get the hardware to test with. Or I can post test code up here for others to try. I've got a bit of code I can inject into the ROM to dump the ring buffer to SRAM then as you get a MIDI glitch you can dump the SRAM and we'll see what caused it. Might just be a timing issue in the Arduino.

I think the focus should be on this MIDI issue as without a reliable pot interface the original design of the GB303 is broken.

Herr_prof, what did you have in mind?

Mega328's (from memory - i'll confirm when i get access to a datasheet) have a register to select either internal vref(3.3v,2.5v etc) or external vref... Or, you are using logarithmic pots instead of linear? There are a few places to look for the problem with being unable to use the full range of the pot.

I've had a look through the 303 serial hander code and it works by dumping each byte into a ring buffer until a threshold is met, then it searches through it looking for the 8th bit being set (which indicates the start of a MIDI command) which makes it very robust assuming the bytes get into the gameboy. This is where I think the sync issue is. Arduinoboy is miss-matched in speed to the GB or perhaps the GB303's vblank interrupt is too slow delaying servicing of the serial handler and it is falling out of sync.

Another artifact of the serial port on the game boy is there is no method to re-sync as a slave. Data is clocked in one bit at a time, if one bit gets out of sync all the data becomes corrupt as the bytes are shifted effectively multiplying or dividing them by 2 and adding bits from other bytes. Its one big mess! And it won't fix itself. My Linker code gets around this by setting the GB as a host, sending out a dummy byte which re-syncs the internal serial clock then reverting back to slave mode. It also has two way communication to keep everything in sync. This is missing in the arduinoboy, there is no error detection, attempt to resync or even a handshake.

Should this be the next area I focus my attention on?

Herr_prof,

Could I please get you to test the MIDI control on Furrtek's original ROM? On page 1 of this thread it was reported that the original hardware had this same issue, sketchy MIDI interface.

Does the pot issue (turn to 127, results in 02 etc..) happen every time? Or is it only occasional?

What firmware are you using in your arduinoboy?

DSC, do you get the same results in your firmware version?

Thanks Biere,

I've scaled it right before the data is saved in the POTnV RAM location in Serial.asm. So 0-127 comes in, and is saved as 0-254

The 2.00 max out is inside your arduino sketch. I haven't seen the hardware but I assume you are feeding your pots 5v and the internal ADC is set up to sample 0-3.3v which will only give you 66% of the pot before it maxes out. Not sure if you can change the ADC ref voltage in arduino but you could just change the voltage going to the pot. Or it could be the scaling/debounce code in the arduino. I'll take a look into it today

Do you get the same effect when using a MIDI controller?

Happy Friday everyone!

CC Value multiplied by two: www.bennvenn.com/GB303_Snapshot5.rar Range is now 0-254. That might give better range in the ROM.

No code or script, just added a breakpoint to the serial interrupt vector then stepped through the code and modified the accumulator to steer the code where I wanted. Did this a few times while on the pot screen to see the values change.

All 3 pots? Is 0-127 enough range?

Compiled, let me know how it goes. Could only test it via simulating 3 bytes coming in (in BGB), being 0xB0,0x01,0x35 which set pot 1 to value 0x35.

www.bennvenn.com/GB303_Snapshot4.rar

Yeah, I'll need to look at the ADC function to see what it was expecting. I know the pots are all scaled down, some as much as 32 times depending on the register it is manipulating. Maybe an option to accept 8 bit values to make full use of 8bit registers. Doesn't conform to the spec but to give the same performance of the original 303 hardware it would be required.

I didn't get anything done last night, I think I'm coming down with a cold. I emailed myself the serial handler routine so I can work on it at work and I think I've just finished it. I'll compile as soon as I get home and post it for anyone to try. CC Channel 1,2 and 3 for Pots 1,2 and 3. Not sure if the pot value could originally be 0-255 or 0-127, I didn't email myself that part of the code. The code I just finished assumes its 0-127, if the range is half what is expected I'll just double it in software.

Both game boys though, common point between the two is the cart...

Maybe time for a new cart

Maybe wait to see if anyone else has a similar setup to yours, could be that the mods plus flash cart are using more than the power supply can produce. Unless this has only just started happening?

Any mods on the GB? Backlight?

very unusual problem. Sounds like something is up with the cart