Game Boy Cartridge plus Programmer

I played around with the code and a Game Boy Camera module, but it all was very weird. I was able to read the header once, and only after I unsucessfully read parts of RAM I was able to read the header again. I'm testing cartridges with RAM modules and different memory bank controllers. I should write down everything I learned about the Game Boy at some point.

Game Title: METROID2

Cartridge Type: 3 - MBC1+RAM+BATTERY

ROM Size: 3 - 256KByte (16 banks)

RAM Size: 2 - 8 Kbytes (1 Bank)

[UPDATE] Ha! Nevermind, they are the same, Hex Editor told me that I was missing a "00" - now everything "checks out". Checksum pun.

I've made it! I'm far from sharing anything, but I finally managed to read AND store a full game! Everything is based on the speedtest for the serial interface over USB and another file storing sample for C. I had to fiddle around with buffer sizes and remove a string in a hexfile editor, but it counts, the came works :) I get 4 times the same checksum for 4 cartridges, but somehow I get a different checksum for a downloaded ROM, and the files look very different.

- Anyways, probably best to go to bed now :)

[UPDATE] silkscreen and the upside-down side of things

An after midnight board, how classic [don't] [just] [don't]. I could have breadboarded this as well first, to check if it actually works. Damn. Now I'm hesitant to reorder, I should try it first. - Wait, what am I talking about?

This is a shield for the Wemos D1 mini, that features a TXB104D, a level-shifter with auto detection for direction. The picture seen here is the corrected version, after ordering the failed PCB. By accident I've mirrored the game boy connecter, because I tried to rotate it in my head. This version has numbered pins, to make it more easy to check. Otherwise I'm pretty proud of it. I can still use it as a breakout board for the TXB104D and check if the connector gets a clean cutout, even use the Wemos D1 mini to talk to 5V stuff.

There are "rumours" that the ESP is 5V tolerant and the Game Boy might be happy with 3V3 volts of the ESP, but I'm not eager to try. By rumours I mean, I thought I have read that somewhere.

Here is that ear worm you're trying to get rid off. Gremlins and ear worms, classic Dave.

I just received my Game Boy Pocket in Classic colors, a japan only release - and I'm in love :3 yellow backlight and bivert mod are on its way. The center one is an old silver game boy where I removed the silver, swapped the display and put in shapeway printed purple buttons. The yellow one is my first GBP.

So since the Teensy++ 2.0 bootloader is not available and I'm not feeling comfortable to learn all the bells and whistles of USB communications I was looking for other options. Googling "at90usb1287 arduino" I found this https://github.com/mattairtech/ArduinoCore-avr - I chose the AT90USB1287 deliberately because of the native USB and fast speeds and way too many IOs to work with, and got it to work with my board :)

https://www.mattairtech.com/index.php/development-boards/mt-db-u6.html

I basically had to add the link to the json file to my boards manager library in th Arduino IDE and download the bootloader from their page (burn bootloader from arduino didn't set the fuses right?). I started with turning lights on and off, because as always blink is a good point to start. I noticed that my register setting skills were non existing, because I always mix up port direction and pin setting, but in the end I found the right way to set the ports and blink the lights. Reading the data port was also easy, after testing and finding out that the JTAG on pins F4-F7 weren't deactivated like the mattairtech folks promised.

Anyway... boom. Single ROM bank cartridges, fear me! Here's the verbose header dump of one of my TETRIS cartridges. Bank switching and writing cartridges to be next. It's fast. Off to bed.

100: 0 - 
101: C3 - �
102: 50 - P
103: 1 - 

104: CE - �
105: ED - �
106: 66 - f
107: 66 - f
108: CC - �
109: D - 

10A: 0 - 
10B: B - 
10C: 3 - 
10D: 73 - s
10E: 0 - 
10F: 83 - �
110: 0 - 
111: C - 
112: 0 - 
113: D - 

114: 0 - 
115: 8 - 
116: 11 - 
117: 1F - 
118: 88 - �
119: 89 - �
11A: 0 - 
11B: E - 
11C: DC - �
11D: CC - �
11E: 6E - n
11F: E6 - �
120: DD - �
121: DD - �
122: D9 - �
123: 99 - �
124: BB - �
125: BB - �
126: 67 - g
127: 63 - c
128: 6E - n
129: E - 
12A: EC - �
12B: CC - �
12C: DD - �
12D: DC - �
12E: 99 - �
12F: 9F - �
130: BB - �
131: B9 - �
132: 33 - 3
133: 3E - >
134: 54 - T
135: 45 - E
136: 54 - T
137: 52 - R
138: 49 - I
139: 53 - S
13A: 0 - 
13B: 0 - 
13C: 0 - 
13D: 0 - 
13E: 0 - 
13F: 0 - 
140: 0 - 
141: 0 - 
142: 0 - 
143: 0 - 
144: 0 - 
145: 0 - 
146: 0 - 
147: 0 - 
148: 0 - 
149: 0 - 
14A: 0 - 
14B: 1 - 

14C: 1 - 

14D: A - 

14E: 16 - 
14F: BF - �

What a fantastic title for a link drop

• https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification
• https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.6.x-package_index.json-format-specification

I might want to program the programmer from arduino at some point

Once again I've put on the DFU USB bootloader onto the AVR AT90USB1287, after reading the bootloader PDF without any disctractions :D There I read that the chips need a full erase before you can program them over DFU. Did that. Than I also found out that I have to start the program I've burned ... oh well :) works! Awesome :) - now the actual programming can start :D

# If nothing works, try it with the force :D
sudo dfu-programmer at90usb1287 erase --force

# "Hexe" means witch, this is not witchcraft
sudo dfu-programmer at90usb1287 flash main.hex

# the bootreset fuse starts the bootloader after the reset
# so you won't start your program but restart the bootloader 
sudo dfu-programmer launch --no-reset

This board is way out of my Arduino comfort zone... so I'm writing down what I've managed to learn or am able to estimate. I was trying to get this code running http://www.ssalewski.de/AT90USB_firmware.html.en - and the way it was given to upload was via a program called dfu_programmer, that is probably best installed via homebrew for mac (my given machine).

brew install dfu_programmer

I tried and tried and couldn't figure out what I'm doing (wrong) until I've read someone writing in a forum that in a case of a flashed program there wouldn't be the generic dfu bootloader anymore. Luckily Atmel gives you the DFU hex files on the download page. Here is the datasheet for the bootloader: http://www.atmel.com/Images/doc7618.pdf

To activate the bootloader you have to have pulled down the HWE pin when releasing the RST pin, a state that my board is constantly set to, since I've copied the teensy design not knowing "better". At this point I'm not sure if this is working well with the bootloader, but I have my concerns since I can't flash anything, but see the devices as " AT90USB128 DFU" in my USB list.

I have to bodge some buttons and resistor / capacitor thingies together, like in the Hardware Guide of the AT90USBKEY http://www.atmel.com/Images/doc7627.pdf

The following link [http://www.engbedded.com/fusecalc/] is still pretty useful for getting the values for the fuse bytes to set the HWBE fuse and the Boot Reset fuse. They seem to be important. Also weird:

sudo dfu-programmer at90usb1287 getfuse 
target doesn't support fuse set operation.

And this is my log of failure, when trying to flash the Atmega1287. Another thing to do is looking up the Halfkey bootloader on the teensy.

dfu-programmer at90usb1287 flash main.hex --debug 100
     target: at90usb1287
    chip_id: 0x2ffb
  vendor_id: 0x03eb
    command: flash
      quiet: false
      debug: 100
device_type: AVR
------ command specific below ------
   validate: true
   hex file: main.hex

atmel.c:1153: atmel_flash( 0x7fff5d5b1b40, 0x7fff5d5b1a08, false, false )
intel_hex.c:673: intel_flash_prep_buffer( 0x7fff5d5b1a08 )
atmel.c:1193: Flash available from 0x0 to 0x1DFFF (64kB p. 0 to 1), 0x1E000 bytes.
atmel.c:1197: Data start @ 0x0: 64kB p 0; 128B p 0x0 + 0x0 offset.
atmel.c:1201: Data end @ 0x17F: 64kB p 0; 128B p 0x2 + 0x7F offset.
atmel.c:1206: Totals: 0x180 bytes, 3 128B pages, 1 64kB byte pages.
atmel.c:819: atmel_blank_check( 0x7fff5d5b1b40, 0x00000000, 0x0000017F )
atmel.c:927: atmel_select_memory_unit( 0x7fff5d5b1b40, 0 )
atmel.c:941: Ignore Select Memory Unit for non GRP_AVR32 device.
Checking memory from 0x0 to 0x17F...  
atmel.c:986: atmel_select_page( 0x7fff5d5b1b40, 0 )
atmel.c:1000: Selecting page 0, address 0x0.
atmel.c:752: __atmel_blank_page_check( 0x7fff5d5b1b40, 0x00000000, 0x0000017f )
atmel.c:784: Flash region from 0x0 to 0x17F is blank.
atmel.c:862: Flash blank from 0x0 to 0x17F.
Empty.
atmel.c:927: atmel_select_memory_unit( 0x7fff5d5b1b40, 0 )
atmel.c:941: Ignore Select Memory Unit for non GRP_AVR32 device.
Programming 0x180 bytes...
atmel.c:986: atmel_select_page( 0x7fff5d5b1b40, 0 )
atmel.c:1000: Selecting page 0, address 0x0.
atmel.c:1289: Program data block: 0x0 to 0x17F (p. 0), 0x180 bytes.
atmel.c:1424: __atmel_flash_block( 0x7fff5d5b1b40, 0x7fff5d5b1a08, false )
atmel.c:1386: atmel_flash_populate_header( 0x7fff5d5b14a0, 0x0, 0x17F, false )
atmel.c:1340: atmel_flash_populate_footer( 0x7fff5d5b14a0, 0x7fff5d5b1640, 65535, 65535, 65535 )
atmel.c:1485: atmel_flash: flash data dfu_download failed.
atmel.c:1487: Expected message length of 432, got -9.
atmel.c:1292: Error flashing the block: err -2.
ERROR
Memory write error, use debug for more info.
commands.c:514: Error writing memory data. (err -4)

;)

The LCD display board and the Socket board are both ordered, as well as a tiny QFN Attiny85 board.

All boards were upgraded to be send with "super swift" - so I'm looking forward to a 5x3 boards delivery :) :) :)

yo - @Stefan-Xp - here's a picture of the socket and the super game boy it's from: