nitro2k01 wrote:
BennVenn wrote:

You can drop in a $4 boost converter and won't have to worry about battery quality/charge.

Are you sure? The GBP (like all GBs) has a switching voltage converter built-in. If the voltage cut-off of Nintendo's converter is set too high, it may stop batteries from working before they're fully discharged, and then a boost converter would help. But I thought the problem with the EMS cart was that it's using excessive power, so that it both drains the battery faster, and is using more power than a typical AAA battery can deliver when partially discharged due to ESR. In that case, no boost converter in the world would help.

curtinparloe wrote:

In other news, I had a spare Li-ion 3.7V, 810mAh/2.997Wh which I jumpered up to the Pocket's terminals and it worked better than I expected. Is there a reason I can't/shouldn't put a single Li-ion AAA size cell with a dummy cell in the back?

That should work, better than using AAA batteries in fact. One thing to keep in mind: If it doesn't have protection circuitry built-in, you may want to be careful not to over-discharge it, or accidentally short it.

Yup, the GBP has a flyback converter, like the rest of the them. Flyback converters are designed with a target output current. Exceed this and the inductor saturates. I can give the tech details if you like, basically if you push the converter too hard, they go from around 85% efficiency to around 10%. Batteries rapidly discharge, 5v isn't maintained and the whole lot goes to custard.

The greater difference between input and output voltage puts more stress on the converter which is why fresh alkalines work OK and it rapidly gets worse as they discharge. ESR of an AAA alkaline is in the mOhm region, this is not the source of the problem, it is the converter.

Find any 5v output boost converter with an input of say 2-5v and wire it in. Pololu sell some high quality, cheap and tiny modules. They are more efficient than the original and battery life will actually increase.

This has been tested on the DMG with earlier revision PCB's when installing my VGA modues (~15ma additional plus another ~15ma for the flash cart). Even this 30ma additional load causes the converter to run extremely hot. You can feel the heat from outside the gb case. Adding the pololu buck/boost converter made everything happy again. Not a problem with the PIL versions.

With the Lipo, as nitro says if there is no protection circuit, don't do it or it won't recharge once its flat.

You can drop in a $4 boost converter and won't have to worry about battery quality/charge.


(43 replies, posted in Nintendo Handhelds)

BryDesu wrote:

Bump on this Does anyone know what to do with the DMGs that the lcd  doesn't work it on anymore?
Been trying to figure out if I can connect to an external display with it.

Any comments or suggestions

Just asking

You could turn it into a stand alone TV console with my DES board (NES controller input), or add my VGA module to give the DMG a vga port to connect to a TV... You can also fit a GBA LCD to the DMG with my SP-Converter board, both backlit, frontlit and original LCD. These are just some of the available options.

My SD cart can have hundreds of .sav's on the cart, conveniently loaded/saved to a micro SD card. ~2 seconds to swap out an entire 128k save file from the SD card. No reason not to backup your work, it's only a button press away when you turn your GB on so the flat battery argument isn't really valid anymore. Swapping out ROM's is just as easy.

Here's my V1.5 SD cart

And an early revision of my V2 SD cart (Far left)

I've got a few more carts I'll add here when I get some good pics of them (FRAM based cart, 2mb multi-rom cart, MBC3 RTC equipped cart)

OK, I just read though the whole thread.

If you want a non FPGA/CPLD approach, use a maple/maple mini. The STM32F103 has enough processing speed to read the video data and send it straight to its USB FIFO buffer, It is the PC's responsibility to read the data out fast enough. It even has enough ram to buffer a few frames to make it all go a lot smoother.

I have clocked the stm32f103 at a reliable 400kbytes/second (There can not be any other peripherals attached to the USB host and best if it is not via a hub) Latency is 1ms on USB high speed which means no handshaking, it'll be a one way street with CRC incorporated.

Reconstructing the video in real time on the PC is beyond me. I tried in Python but i cannot do it fast enough with Tkiniter. PyGame library would help but I found converting from 2bit to a RGB value takes too long.

If capturing is what you want, AV is what you need. a USBCAP chinese thing is only a couple of dollars. A CPLD and buffer to do the frame conversion will be under $10.


Yeah its VGA, wouldn't be hard to output composite instead (I've prototyped it though the consensus was VGA instead). Even easier and more accurate would be pure digital into a PC.

There isn't a schematic and it uses a CPLD and lots of ram to buffer/sync the images.

You would need a fast and reliable method of getting data into your PC. 160x144x2bitsx60 frames a second = 2.764800 million bits per second, that is without any packet overhead. This is not something your arduino can do over a serial connection.

~350kbytes/sec is quite fast. You can drop frames and get a teensy to send data to the PC pretty easily but how many dropped frames is acceptable?

I think eBay has VGA video capture boxes, or even VGA to composite adaptors.

Or use some kind of compression, RLE would compress the data stream failry efficiently. Then how would you go about decompressing and reconstructing the video on the PC side?

If you want to record, the easiest solution is a hardware GB to AV out module.

Sorry guys! Super busy. Here is what I have on my work PC

Known Routines:

$097D - "Delay_1" This is a delay routine, value passed via BC
$03AD - "LCD_Turn_Off" No variables passed
$0462 - "Zero_RAM"    Start location passed in HL, number of bytes to zero in BC
$03E2 - "DMA_Routine_2_HRAM" , No Variables, moves a 10 byte program into HRAM, the DMA routine.
$092A - "Init_OAM_Buffer"    ;Sets the OAM buffer ($D400) to 0xF0
$0914 - "Clear_Tile_Map0"    ;sets $9800-9BFF to $FF
$091F - "Clear_Tile_Map1"     ;sets $9C00-9FFF to $FF
$2B25 - "Init_Snd"        ;Turns sound registers on, volume, channels, clears DD00-DF00
$1DEC -
$1DE0 - "Delay_2" , No variables Passed.

Known Memory Locations:
$FF9B - Current Memory Bank selected
$D400 - D49F - DMA Start address (Buffer?)
$DD00-DF00 - Suspected Sound buffers?

$0101: Jp Main

    Ld sp, $FFFE         ;Initialise Stack
    Di            ;disable interrupts
    Xor a            ;clear a
    Ldh [$FF0F], a    ;Dissable all IRQ’s
    Ldh a,[$FF40]        ;Get LCDC
    Bit 7,a            ;Test bit 7 – Display Enabled?
    Jr zn, LCD_Enabled    ;Conditional Jump ()
    Set 7,a            ;set bit 7
    Ldh [$FF40],a        ;Store LCDC

    Ld bc, $0002        ;pass $0002 to Function $097D
    Call Delay_1         ;Jazz, Please watch this in the emulator to find the delay length?
                ;Best guess is the delay is necessary to initialise the cart MCU

    Ldh a,[FF44]        ;Waiting for a V-Blank…
    Cp a,$91
    Jr c,VblankWait

    Ld a,$80
    Ldh [$FF40],a ;Enable LCD – Did I make a mistake with the above routines? Jazz?
    Xor a         ;Clear A
    Ldh [$FF47],a     ;Clear Pallete Data
    Ldh [$FF48],a     ;Clear Pallete Data
    Ldh [$FF49],a     ;Clear Pallete Data

    Ld bc, $0002        ;pass $0002 to Function $097D
    Call Delay_1         ;Jazz, Please watch this in the emulator to find the delay length?
    Call  Turn_LCD_Off   

    ld hl,$C000        ;Load HL with Work RAM location
    ld BC,$1FFF        ;Load BC with 1FFF
    Call Zero_RAM        ;Zero BC number of bytes, from location HL


    ld   a,$00        ;Why do they zero A this way, and not XOR A like other routines???
    ld   [$0000],a        ;Disable Cartridge Save RAM
    ld   a,$01        ;
    ld   [$2000],a        ;Set ROM bank 1
    ld   a,$00       
    ld   [$4000],a        ;Set Ram bank 0
    ld   a,$01
    ldh  [$FF9B],a        ;Store 1 into FF9B - Perhaps a buffer to keep track of bank numbers?
    ld   sp,$DFFF        ;Move stack pointer to $DFFF
    ld   hl,$FF80        ;Load $FF80 into HL
    ld   bc,$007E        ;Load $007E into BC
    Call Zero_RAM        ;Clear the HRAM

    Call DMA_Routine_2_HRAM ;move the DMA routine to HRAM

    Call Init_OAM_Buffer    ;Sets the OAM buffer ($D400) to 0xF0

    Call Clear_Tile_Map0

    Call Clear_Tile_Map1

    xor a    ;Clear A
    ld   [$D520],a    ;Zero all these important registers...
    ld   [$D521],a
    ld   [$D522],a
    ldh  [$FFC5],a
    ldh  [$FFC6],a
    ldh  [$FFD0],a
    ldh  [$FFD4],a
    ld   [$DC41],a
    ld   [$D523],a
    ldh  [$FFC4],a

    ld   hl,$FFAB
    xor  a
    ldi  [hl],a    ;Zero from  FFAB - FFB2
    ldi  [hl],a
    ldi  [hl],a
    ldi  [hl],a
    ldi  [hl],a
    ldi  [hl],a
    ldi  [hl],a
    ldi  [hl],a
    ld   a,$8F
    ldi  [hl],a    ;$8F into FFB3
    ld   a,$A6
    ldi  [hl],    ;$A6 into FFB4

    Call Init_Snd    ;

    Call $1DEC    ;

    ld   a,$0B
    ld   hl,$4010
    call $1D95

    call Delay_2

    ldh  a,[$FF00]
    and  a,$03
    cp   a,$03
    jr   nz,$1E3A
    ld   a,$20
    ldh  [$FF00],a
    ldh  a,[$FF00]
    ldh  a,[$FF00]
    ld   a,$30
    ldh  [$FF00],a
    ld   a,$10
    ldh  [$FF00],a
    ldh  a,[$FF00]
    ldh  a,[$FF00]
    ldh  a,[$FF00]
    ldh  a,[$FF00]
    ldh  a,[$FF00]
    ldh  a,[$FF00]
    ld   a,$30
    ldh  [$FF00],a
    ldh  a,[$FF00]
    ldh  a,[$FF00]
    ldh  a,[$FF00]
    ldh  a,[$FF00]
    and  a,$03
    cp   a,$03
    jr   nz,$1E3A
    ld   a,$0B
    ld   hl,$4000
    call $1D95
    call $1DE0
    and  a
    ld   a,$0B
    ld   hl,$4000
    call $1D95
    call Delay_2

$1D95:    ;Variables passed, A and HL

    ldh  [$FF9D],a        ;put variable A into FF9D - Temp bank buffer 2?
    ldh  a,[BankBuffer]    ;Get current bank
    push af            ;Store it on the stack
    ldh  a,[$FF9D]        ;Get that variable buffer
    ldh  [BankBuffer],a    ;Update the current bank register
    ld   [$2000],a        ;Set the bank
    ld   a,[hl]        ;Load first byte of passed variable HL
    and  a,$07        ;cmp with $07
    jr   z,Label1        ;if something, then end routine.....

    ld   b,a        ;otherwise,  multiply it by 0xFF, and put it in BC
    ld   c,$00
    push bc            ;push BC onto the stack
    ld   a,$00       
    ld   [$ff00+c],a    ;Clear keypad latch
    ld   a,$30
    ld   [$ff00+c],a    ;Set P14+15 high
    ld   b,$10        ;load B with $10
Label4:    ld   e,$08        ;Load E with $08
    ldi  a,[hl]       
    ld   d,a
Label3:    bit  0,d
    ld   a,$10
    jr   nz,Label2
    ld   a,$20
Label2:    ld   [$ff00+c],a
    ld   a,$30
    ld   [$ff00+c],a
    rr   d
    dec  e
    jr   nz,Label3
    dec  b
    jr   nz,Label4
    ld   a,$20
    ld   [$ff00+c],a
    ld   a,$30
    ld   [$ff00+c],a
    pop  bc
    dec  b
    jr   z,Label1
    call Delay_2
    jr   $1DA9
Label1:    pop  af
    ldh  [BankBuffer],a
    ld   [$2000],a

    ld   de,$1B58
.Loop    nop 
    dec  de
    ld   a,d
    or   e
    jr   nz,.Loop

Init_Snd: ;Set bank 1F, execute code at $7FF6, Restore previous bank.
    ldh  a,[$FF9B] ;Store the current ROM bank
    push af
    ld   a,$1F    ;Change to ROM Bank 1F
    ldh  [$FF9B],a    ;Update the bank buffer
    ld   [$2000],a    ;Switch bank 1F
    call $7FF6    ;Turn on Sound registers, Zero DD00-DF00 - Sound buffers???
    pop  af        ;Restore the current rom bank
    ldh  [$FF9B],a    ;
    d   [$2000],a    ;Set the current rom bank.

        1F:7FF6 > jumps to :5343
            ld   a,$80
            ldh  [$FF26],a    ;Enable all sound channels
            ld   a,$77
            ldh  [$FF24],a  ;Max volume
            ld   a,$FF
            ldh  [$FF25],a    ;Sound output to all terminals
            ld   hl,$DD00
        .Loop    ld   [hl],$00    ;Zero DD00-DF00
            inc  l
            jr   nz,.Loop
            inc  h
            ld   a,h
            cp   a,$DF
            jr   nz,.Loop

    ld   a,$FF
    ld   hl,$9800
    ldi  [hl],a
    bit  2,h
    jr   z,$0919

    ld   a,$FF
    ld   hl,$9C00
    ldi  [hl],a
    bit  5,h
    jr   z,$0924

Init_OAM_Buffer: ;Set OAM buffer to 0xF0, all of it.
    ld   hl,$D400
    ld   b,$A0
    ld   a,$F0
    ldi  [hl],a
    dec  b
    jr   nz,$0931
    xor  a
    ldh  [$FF9A],a

DMA_Routine_2_HRAM: ;Move the DMA transfer routine into HRAM
    ld   c,$80
    ld   b,$0A
    ld   hl,DMA_Routine   
    ldi  a,[hl]    ;
    ld   [$ff00+c],a
    inc  c
    dec  b
    jr   nz,$03E9

DMA_Routine:    ;This routine is placed into HRAM via DMA_Routine_2_HRAM
    ld a,$D4        ;Start address = $D400, Destination is FE00
    ldh [$FF46],a
    ld a,$28
    dec a
    jr nz,$03F6

    xor  a
    ldi  [hl],a
    dec  bc
    ld   a,c
    or   b
    jr   nz,$0462

    Ldh a,[$FF40]     ; get LCDC
    Bit 7,a        ;Disabled?
    Ret z        ;return with zero flag carried
    Ldh a,[$FFFF]    ;Get Interrupt Status
    Push AF        ;push it to the stack
    And A,$FC    ;Clear bits 0+1 – Vblank int, and LCD Stat int.
    Ldh [$FFFF],A    ;Update the interrupt status

    Ld a,[FF44]
    Cp a,$91
Jr nz, .Wait4V
    Ldh a,[$FFAB]    ;FFAB is a buffer register of LCDC
    Res 7,a
    ldh [$FF40],a    ;store in LCDC
    ldh [$FFAB],a   ;Update LCDC buffer register   
    pop af
    ldh [$FFFF],a    ;restore the Interupt register

Delay_1 : ;Data passed in via Register BC
    Ld de,$06D6        ;Delay loop pre-set
    Dec de            ;
    Ld a,d            ;
    Or e            ;
    Jr nz, Delay_Inner_Loop: ;Loop $06D6 times
    Dec BC
    Ld a,b
    Or c
    Jr nz, Delay_1: ;Loop the above loop, BC times.

There is more on my home PC


(4 replies, posted in Nintendo Handhelds)

HK, I think its $50 for the 101 lcd plus the board


(4 replies, posted in Nintendo Handhelds)

Brightness is not adjusted by the 'contrast' wheel. Brightness is determined by the current going into your backlight. You'll need to cut a trace on the pcb before you wire in your backlight driver too.

There is a seller on aliexpress that sell both the LCD and driver and have a good guide how to make it work.


(2 replies, posted in Other Hardware)

You'll be able to pick up one of my SD Flash Carts for under $50. If you are in the US/Canada will have them available very soon, If you are in the UK, head to Deadpan Robot (EU customers too). Or if you are closer to Australia/Pacific, send me an email and I'll help you out.


(6 replies, posted in Nintendo Handhelds)

You could always drop a GBASP LCD in there...

Did anyone ever get this project off the ground?

Thor17 had the right idea with the stack memory though MOQ was in the order of 1,000pcs and required a 4 layer board due to the BGA footprint... Adding support for all those mappers means a rather large CPLD/FPGA is required, increasing the price and power consumption, not to mention there is a very slim chance of the average Joe successfully soldering a pb-free bga package at home.

Then the equipment to initially program the CPLD and Bootloader... All this makes this project very DIY unfriendly.

zemzelett wrote:

Ben, are you planning to put these projects open source to a certain extent?

Which projects in particular?

I can document my mapper in my SD carts if you like, I am not the most tallented GB coder and I know others can improve my GUI/Code

As for the schematics/Gerbers/VHDL, No I'll be keeping them to myself. A LOT of time and money has gone into prototype boards and revisions of all these devices and I'd like to keep what little profit there is to be made on them. It is hard to find a good example where open sourcing has led to positive development of a product. Especially in such a niche market with specific coding/hardware constraints.

Zemzelett, the SP adaptor board is your best chance of fitting a non standard LCD to the GB. I have a replacement front DMG PCB in the works which uses a cheap chinese LCD.

To program the CPLD you'll need an 'Altera USB Blaster' - the chinese clones are just as good as the real thing.

Large FIFO buffer captures the D0 and D1 data as the GB spits it out (CPLD to fix up signaling, DRAM refresh constraints etc) then the CPLD generates the v and h sync and the timebase for the FIFO to stream it out.

I'm using 2 buffers to capture the data then replay them in odd and even frames to upscale the video. I'm slowing the pixel clock by 2 or 3 to upscale in the horizontal plane.

I can upscale to 3 times with the third line interlaced, 4 times is too big for a 640x480 frame.