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.
Offline
Paris
Hi Benn,
Thanks for all your efforts. Very much appreciated.
Offline
This increased the range to FE when you turn the pot, but it still tops out around 2:00 with there still being more travel room in the pot.
It is consistent across all three pots, so I don't think it is a hardware issue. Still lots of fun now with the full range 
Offline
Unsubscribe
BennVenn wrote:
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.
The max a cc value can be is 7f.. I didnt test this yet but where is the scaling happening?
I tested it with a sequencer, and it seems it but not working all that well. Note triggers seems to drop notes on my setup and setting up cc automation feels kinda flaky. For example when i turn a knob to 127 on p1 i get 02, and if I turn it back to zero on the knob control its f8? And the note triggering behavior seems really hit or miss as well.
Last edited by herr_prof (Jul 9, 2015 10:01 pm)
Offline
Australia
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?
Offline
Australia
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?
Offline
Unsubscribe
Seems flaky in the og rom too. The turn to 127 issue seems to not always happen on boot, but once it "looses its place" it seems to stay flaky. It seems to happen eventually on every use. Im guessing its just a calibration issue.
Im using the latest firmware for the arduinoboy from the website on a scienceguy arduinoboy (Nothing special about it, it just has a FTDI to program it, so I could use a forked MGB firmware in a pinch).
Offline
Midi is unstable, I am not able to repeat any specific issue, but yes, random notes and missing notes are pretty common. I would say best would be 1 incident every 10 seconds, while worst would be 3 every 10 seconds.
The pots I am using are 0-5V using ground on one side and +5V on the other. I think the full range according to the display in gb303 is 00-FE. Can you confirm this?
Offline
Michigan
The ADC's voltage reference would not be set to 3.3v. That would require code modification and an actual 3v3 reference hooked up to the vref pin which is always hanging IIRC.
Offline
Australia
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?
Offline
mGB suffers from this too as I recall. It is not as bad as this, but it is there.
What would be your plan of attack on how to solve this problem?
Offline
Unsubscribe
To me, there are more glaring problems with the software besides midi input. Maybe someday down the road when you have a midi setup to test in your DEV environment you can circle back around to it.
Offline
Australia
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?
Offline
BennVenn wrote:
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.
I think the focus should be on this MIDI issue as without a reliable pot interface the original design of the GB303 is broken.
I would be willing to help and I agree the pot interface is integral to the gb303 rom.
I worked with the rom for a little while and from my experience it really is a performance synth and less of a tracker style like LSDJ.
Yes it has an LSDJ style screen and you can program a series of notes, but there is really a very nice set of features for live performance. Just my opinion.
Offline
Australia
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!
Offline
DSC wrote:
mGB suffers from this too as I recall.
You mean that mGB has sync issues? does it skip some incoming notes or sync bytes?
Do you know how LSDJ avoids these issues?