65

(46 replies, posted in Nintendo Handhelds)

So multiple button combinations can be used without triggering on each button press

The project got stalled when I lost most of my data with a hdd crash. I'll set the dev environment back up and crack on with it if someone wants to point me in the right direction to develop this further?

A solid design strategy is more helpful than 'make it like LSDJ' etc...

67

(46 replies, posted in Nintendo Handhelds)

MaxDolensky, if a keyOn command is sent on the release of a button, how would a keyOff command be sent? Happy to develop this with you.

Adzetko,  I selected the Stm brand for a couple of reasons, the development suite is free for code size under 32k, the programming hardware is cheap and clones are available and last, it is the most common ARM brand found in cheap eBay crap which opens up a world of hacking options.

I chose the STM32F103 because it was used in the 32bit arduino clones which provides a devkit at a very low price. It has an enormous set of inbuilt peripherals including a hadware USB engine.

Im using this same MCU to run my beetles engine management.  Very powerful and versatile.

It is mostly 5v tolerant which is rare on a 32bit mcu, runs at 72mhz and is stable overclocked to 107mhz and it is cheap!

If you want one suitable for development, I'd suggest the itead maple. It is cheap and has the same footprint as an arduino which seems popular here. Get a Stlink from eBay to program it.

68

(46 replies, posted in Nintendo Handhelds)

Adzetko, are you after where to buy the ARM for this project, or just a general question for future projects?

69

(46 replies, posted in Nintendo Handhelds)

It works just as good on a GBC/GBA. MIDI out? Is there nothing that already does this?

Not sure if you've ever held a Chinese clone controller, they are far from 'nice'. Flexible body, sharp edges on the buttons. You really need that 2 decades of finger mashing to round those edges. Or a legitimate dogbone controller which are rare in these parts.

I had a sync issue last night so it looks like I'll need to do some kind of handshaking. This shouldn't slow the response down at all as both the GB and ARM run at a higher rate than the USB packet request.

Back to the MIDI thing, just one note per key, polyphonic?

70

(46 replies, posted in Nintendo Handhelds)

OK, I've got the ARM firmware reading the 8 bits from the gameboy then reading a 9th bit just to be safe. This means worst case we loose a bit and everything gets messed up, it will only be that way for 1 USB frame (~1ms) until we're back in sync. Worst case on startup, that is first powering up the gameboy, we'll have to wait 8ms for a complete new re-sync. I can live with that!

After playing flappy bird for about 5 minutes I didn't get one mis-sync so I guess that's robust enough.

https://youtu.be/f8kUAH45abc

Again sorry for the poor video quality, We live about 25km from the nearest phone tower, over a set of hills. We're completely off-grid which means no more broadband :-( Only nice slow 3G.

I'll post pics of the hardware and the firmware in the morning.


The second photo is the same ARM microcontroller used in an 'ST-Link Programmer' these are only a couple of dollars on eBay. (This particular one controlls an array of wireless power outlets) Only a couple of pins are available and I've modified the code to use these pins.

I'll add a kit to my store, You'll get a pre-programmed board, a 3d printed enclosure. You'll need to BYO link cable. $10 with free shipping worldwide.

I'll post the firmware this afternoon

71

(28 replies, posted in Trading Post)

I thought I saw a smartboy cart up for sale last week...

72

(46 replies, posted in Nintendo Handhelds)

herr_prof wrote:

why not just use a nes to usb type controller?
http://www.amazon.com/Classic-USB-NES-C … B002YVD3KM

We're after the authenticity of the real gb interface. Plus most of us have a flash cart to run the software required and the soldering is dead simple. 4 wires into a through hole board.

73

(46 replies, posted in Nintendo Handhelds)

Adzetko wrote:
BennVenn wrote:

The gameboy could never support USB, it just doesn't have the bandwidth or IO to generate USB compatible signaling. All USB cables must have a protocol translator within.

Personally, I'm not a programmer, but a friend of mine (a data scientist), when I've send him a link to this topic, said to me that, apparently, the gameboy can handle USB, then he linked me this, and said the gameboy can handle a serial link of about 9600bps (I don't really know what this means), and then he tells me USB can largely handle this.
I've tell him to create an account for cm.org, but actually he's at work.

Also, he talked about a cable, Link to USB, he had when he was young, to replace a Gameboy Printer by a normal USB serial printer. He had this with his Pokémon Gold collector edition.

Happy to discuss this with your friend. The main 2 reasons it can't work are the electrical interface - USB uses a differential data pair. These are both inputs and outputs. This requires the gameboy to have total control over 2 io pins. The gameboy has a primitive shift register and only one input and output pin.

Second is timing. The USB spec is very timing sensitive and you have a very small window to acknowledge a token/request/reset. This cannot ever be achieved at 9600bps. Ever. Even on the GBC it doesnt have the speed.

Then there is the frame construction, crc, error handling, address handling. These are all usually handled in a hardware usb engine due to the speed they must run at.

Then we get Into the software layer which is a little easier and given the rom space we could have datastreams ready to shift out so the gameboy doesnt have to think.

Small avr's have managed a software only usb engine but they are very primitive and can really only shift a byte back and forward at very slow speed and not do much else.

His cable is likely the madcatz LPT cable. It isn't usb. The later versions are usb and have a usb micro in the cable.

Happy to be proven wrong on this. Its amazing what people get old hardware to do.

74

(46 replies, posted in Nintendo Handhelds)

Just wrote a very simple GB ROM. It disables the LCD, reads the keypad, sends the data to the Link port, waits patiently until something clocks the data out of the GB then reads the keypad again etc....

No error correction or synchronization but lucky for us the USB code in the ARM runs around 100 times faster than the GB and can flush the Link port of any missed bits before the gameboy finishes its previous instruction.


Main:
    di ; disable interrupts
    ld    hl,$c200 ; we want a stack
    ld    sp,hl

ScreenOff:    
    ldh    a,[rLY]        ;load a with Current Y co-ordinate (144-153 represents VBLANK)
    cp    144        ;copmare with 144
    jr    nz,ScreenOff    ;not equal? then jmp to wait
    ld    a,0        ;equal? then load a with 0
    ldh    [rLCDC],a    ;load a into LCDC - Display off, BG off, Spr off etc

MainLoop:    
    call JoyPadRead
    call TRX_Byte
jp MainLoop

TRX_Byte:
    ld  [$FF01],a
    ld   a,$80
    ld  [$FF02],a
ByteNotSent:
    ld a,[$FF02]
    cp $FE
    jr z, ByteNotSent
    ld a,[$FF01]
    ret

JoyPadRead:
        ; Routine finding which buttons were pressed since the last check
        LD A,$20    ; Set 0 at the output line P14
        LD [$FF00],A ; 
        LD A,[$FF00] ; Read JOYPAD several times to accomodate the noise
        LD A,[$FF00] ;
        LD A,[$FF00] ;
        LD A,[$FF00] ;
        CPL          ; Bits 0-3 are now 1s if corresponding buttons pressed
        AND $0F      ; Extract lower 4 bits carrying button status...
        SWAP A       ; ...and move them into upper four bits
        LD B,A       ; At this point: B = START.SELECT.B.A.x.x.x.x
        LD A,$10     ; Set 0 at the output line P15
        LD [$FF00],A ;
        LD A,[$FF00] ; Read JOYPAD several times to accomodate the noise
        LD A,[$FF00] ;
        LD A,[$FF00];
        LD A,[$FF00] ;
        LD A,[$FF00] ;
        LD A,[$FF00] ;
        CPL          ; Bits 0-3 are now 1s if corresponding buttons pressed
        AND $0F      ; Extract lower 4 bits carrying buttons' status...
        OR B         ; ...and combine them with 4 other button status bits
        LD D,A       ; At this point: D = START.SELECT.B.A.DOWN.UP.LEFT.RIGHT
    
        LD A,$30     ; Set 1s at both P14 and P15 lines
        LD [$FF00],A ; [probably to reset the circuitry]
        ld A,D
        ret

I'm tidying up the ARM code and I'll post the hex/bin/ben too. Oh and the wiring diagram.

Hardware wise, you need a Link cable (only half of it...) and an STM32F103 MCU with supporting components. You can get these in a variety of forms from the 'Leaf labs maple', the itead clone of the original, a STM8/32 programmer from ebay, a chinese knock off of the original etc... You'd be surprised where you can find them. I'll put a few links up too.

75

(46 replies, posted in Nintendo Handhelds)

Adzetko wrote:

The Nanoloop link PCB I was talking about is nothing more than a basic "re-wireing" to adapt a male link port into a male USB port. The communication is made between Nanoloop and the computer only with the Nanoloop software (PC side and GB side). But the hardware is really simple, so I think it is possible to hack it with any interfacing ROM and software.

The gameboy could never support USB, it just doesn't have the bandwidth or IO to generate USB compatible signaling. All USB cables must have a protocol translator within.

76

(46 replies, posted in Nintendo Handhelds)

Very cool!

I think I'd prefer to use an unmodified gameboy. Seems simpler and more portable. I'll throw one together tonight and post a few pics.

I'll post the schematic and source too for those that want to play along at home.

77

(46 replies, posted in Nintendo Handhelds)

I thought a custom ROM and Linkport to USB bridge would be most convenient? Adzetko mentioned the Nanoloop USB cable may be able to do it?

My appologies, it's not within the scope of the OP's thread.

79

(46 replies, posted in Nintendo Handhelds)

A place to discuss the use of a Gameboy as a USB Controller, for PC emulators.

Is there a current solution for this?

My LSDJ linker could be flashed to do it, but im using a custom board at the moment