145

(2 replies, posted in Nintendo Handhelds)

Hey!

Sorry, I haven't dropped by in a while.

OK, yes holding start will invoke the GB side transfer utility. You need to rename the file you want to send to the cart to SRAM.sav, then drag it over. You need to 'overwrite' the existing file for the transfer to take.

Let me know how you go!

146

(37 replies, posted in Trading Post)

He says they are still listed. Or you can head over to my store (shop.bennvenn.com) and grab one there.

Happy Friday everyone!

Now that the save stuff is pretty much done (there will be a bit more to come) progress will be on the MIDI and other bugs in which case all the work I do from here can be applied to the original ROM which will work on your original hardware. There may be fixes which can't be applied to both forks and as there are very few with the original hardare the focus will really be on the new fork of the code.

Do you have the hardware to flash your cart? (Given the WE pin mod)

148

(37 replies, posted in Trading Post)

A mate of mine (Dave) has taken up my BennVenn cart production and sales. He has a few available if anyone is interested. AUD$30 (256M Cart) with free shipping worldwide. He is happy to flash them with whatever ROM's you like (with proof of purchase of the ROM). A great way to test GB-303 on your gameboy alongside LSDJ.

His listing should be on eBay or just PM me for details.

Arduino and protoboards have arrived! (well I ordered two Arduino's and only one came...)

I'll smash together an arduinoboy this weekend and chase down the MIDI bugs. Also I'll be looking into the descrepencies between the ROM and the user manual on Furrtek's site. There are a few bits that don't seem to work quite right.

I'm also thinking about adding a whole new Load/Save screen. I won't bother with any compression like LSDJ does as GB303 doesn't stream data from RAM like LSDJ does and the entire workspace on GB303 is only a few kbytes.

Hope to have some progress uploaded soon!

Sounds good. I'll try fix the arduino code first though. I've ordered two arduino's, protoshields and other bits and pieces. Usually around 2 weeks delivery :-(

Catskull, my work gateway won't allow me access to most social areas of the internet (including your link above). Unfortunately the best time for development discussion is during my work hours...

My preference would be to build something that works for its purpose, a MIDI interface that doesn't glitch every few seconds. If we can do that with the original hardware so be it. Otherwise we should put the effort in to do this right.

Priorities would be:
1.Lowest possible latency between MIDI note being received and the GB responding
2.Reliable interface with no drop outs or re-transmit on error handshaking
3.Pots/Encoders to supplement the original GB-303 pots.

Maybe throw in an OLED display? In exchange of the LED's

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/

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.

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?

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?

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?

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

Well like I said earlier I cant smash out an entire program in Arduino like I can in Asm and even with the clean well written code of Arduinoboy there are still issues with latency and dropping bytes - mainly due to bitbanging the serial stream with interrupts enabled. Reports suggest this is not limited to mGB/303. Why not use the hardware SPI port!?!?!?!?!

Yes, testing MIDI in from my controller/keyboard as well as hardwired pots to the arduino.

Let me know if the loop 00+ issue is a code bug, I can at least work on that until I get my hardware together