Offline
Unsubscribe

I feel like I'm just missing something obvious but no matter what patterns I put on the song screen it just plays pattern zero notes.

Offline
Australia

Hold down select+start on the song screen, the code indicates it does something special...

Yeah, it cycles through your patterns. Setting a () seems to stop playback. Managed to corrupt my patterns fiddling but a reset restores them.

Might need to add empty pattern detection to stop the thing crashing

Last edited by BennVenn (Jul 12, 2015 3:42 am)

Offline

Thank you Ben for offering your time and resources to work on this.  I imagine many here are very appreciative as well.
No rush on any of this and I am excited to hear what progress you find/invent!

Offline

Regarding the loop 0+, read the 4th post here:
http://chipmusic.org/forums/topic/16324 … 3/page/14/

Offline
Michigan

I think a stripped down and streamlined arduinoboy should be designed for mgb and gb303. The LEDs are not particularly essential and the arduino does have a dedicated spi port. I do think it should still use an arduino though, considering the price and availability. 

One mode, no button, four LEDs, spi connected to link port with timers and interrupts.

Offline
Australia

Happy for it to be coded in assembly? Arduino uses the STK500v1 protocol which means it can be updated via avrdude and makes it hard to brick. Also means it can be updated through any system that has the IDE installed, mac's etc...

Four LED's?

Is the current arduinoboy built with a custom shield? or is it just point to point wiring?

Offline
Michigan
BennVenn wrote:

Happy for it to be coded in assembly? Arduino uses the STK500v1 protocol which means it can be updated via avrdude and makes it hard to brick. Also means it can be updated through any system that has the IDE installed, mac's etc...

Four LED's?

Is the current arduinoboy built with a custom shield? or is it just point to point wiring?

No shield needed. Each led, button and link port are connected to one gpio each. Thwy don't even need ftdi chips (unless you want to use avrdude and bitbang).
The one I am sending you is the bare minimum setup.


If I get board of my videogame I'll draw up a new pinout for the ideal ARboy. It would be lovely to have one coded in asm.

Last edited by Jazzmarazz (Jul 12, 2015 10:09 pm)

Offline
Australia

The USB port on an arduino is a USB-serial bridge, no matter which chip they decide to use. The Arduino has a serial bootloader which runs for about a second after a reset which waits for a STK500 query, if it doesn't get one it jumps to the users executable and runs it. FTDI bit banging is a work around for ISP programming. Most people are using arduino boards so should this be the design I work on? But if we are going to start again with a reliable protocol we should go with something more like your board.

Your MIDI board looks AMAZING! Are you using the SPI port or is it running the arduino code?

Offline
NUMBSKULL

Benn, if you ever get to a point where you'd like to make another beta (or alpha) release, let me know and I'll update the code on my github repo and create a release with an attached .gb file for downloading.

Offline
Michigan
BennVenn wrote:

The USB port on an arduino is a USB-serial bridge, no matter which chip they decide to use. The Arduino has a serial bootloader which runs for about a second after a reset which waits for a STK500 query, if it doesn't get one it jumps to the users executable and runs it. FTDI bit banging is a work around for ISP programming. Most people are using arduino boards so should this be the design I work on? But if we are going to start again with a reliable protocol we should go with something more like your board.

Your MIDI board looks AMAZING! Are you using the SPI port or is it running the arduino code?

The above is running the standard ARboy code.
Below is a mock up design of a new arduinoboy.

The new ARboy 'would' have:
DIN midi-in.
Two buttons, both with internal pull up resistors and with falling-edge interrupts.
6 LED's.
8 analog inputs.
Link port connected to SPI bus.


I would like to play with tri-state buffers and the Slave Select pin. This could have potential for wiring up more than one gameboy to the SPI bus. I do not know how to wire this up though, because I do not know which pins to enable and disable. Pic three has a theoretical SPI bus using Slave Select pin. I do not know what will happen if SCK is disabled though.

Another idea is that the new arduino boy could control only one gameboy, have 8 leds and use 8 pots an 8-step gameboy sequencer.

Last edited by Jazzmarazz (Jul 13, 2015 5:42 pm)

Offline
NUMBSKULL

Simple project landing site is up at http://catskull.net/GB303 (hosted on github pages). If everyone hates it I'll take it down. I just thought it could be easier for people than digging through a huge thread and downloading a zip.

Last edited by catskull (Jul 13, 2015 5:57 pm)

Offline
Australia

Jazz, would be nice to break out the RX+TX for save file dumping/restoring via PC? add a little capacitance to the buttons so software debounce isn't required. I've emailed you re: the buffers.

How about rotary encoders instead of pots? They'll use two I/O pins instead of the one ADC but there is no need for digital noise filtering on the input, no adc latency, can store and restore all values in eeprom and an infinite resoution. Makes sense from a software viewpoint if you can afford the IO.

Looks good catskull, I was going to work on the Load/Save stuff tonight. I'll post it here when I start to make progress on it. For now I'm thinking of a single Load & Save button which will write all patterns and your current song instead of individually saving patterns (Is that even what it does!? - seems pretty inconsistent)

I'm convinced the MIDI issue is inside the Arduinoboy. For those with the hardware at home, do you want to have a play with the delays inbetween the gameboy serial writes in the sketch and see what you need to increase them too to stop the glitching?

Offline
Unsubscribe

I think most musical gear has a problem with rotary encoders because they are more expensive, have a higher failure rate, and aren't as tactily pleasurable as a real pot. You can google about dave smith rotary encoders to read loads of complaints about people having trouble with them.

Offline
Australia

I think just about every rotary knob in a modern car uses a rotary encoder, same with AV receivers, radios etc... Price wise, they are around 1:1. Haven't seen any reports on failure, I'll google dave smith and have a read.

Offline
Michigan

I was looking at some prices for encoders and they are just as affordable as pots.
If this were an analog application, I would have to suggest pots, but seeing as every sound register for the gameboy is digital and quite small, encoders may be ideal.

Offline
Australia

Makes sense, we can even scale the encoders according to the resolution of the register. 256 positions on a 4bit register will have 16 dead 'clicks' between value changes. Or we could do things a little different and send increase or decrease value commands to the gameboy. A massive decrease in data througput, less latency, less buggy. Some bench testing will be required to see what is the best option

Herr_prof, was this the link you were talking about http://www.davesmithinstruments.com/not … er-issues/