Month: May 2021

#0028: Game Boy Advance SP audio/power port analysis

Otto

#0028: Game Boy Advance SP audio/power port analysis

Preamble

This article consists of various labelled pinout diagrams. They specifically feature: the charge port, and accompanying plugs, of the Nintendo Game Boy Advance SP (GBA-SP) portable games console. These diagrams will also include annotations on various notable details regarding these pins and their functionality. Additionally I will also feature some of my personal commentary on the port in general.

It should be noted that the information gathered for these diagrams is collected first hand, without the use of any official reference materials. As such I can only discuss the functions of the various pins that I have personally identified and mapped out. Whether or not this port or any pins within have any additional functionality beyond this is unknown to me. Since I have only identified this port as being used for either power ingress, or audio output: I will henceforth reference it as the “audio/power port”.

GBA-SP

Note: I feature this image set in order to establish a basic reference for the GBA-SP: in the case that the reader is not familiar with this device. The GBA-SP only has two ports on it. These are the audio/power port (on the left of the images), and the COMMS (or communications) port (on the right). This article only features details on the audio/power port.

Notables:

  • The audio/power port has six pins within it. Four on the under side of the plastic support, and two above it.
  • The port also has a retaining spring that looks like a pin. This clip holds any inserted plugs in place. It is located between the two top pins, on the centre part of the plastic support, that juts out toward the inner wall of the socket.

GBA-SP charger and plug pinout

Notables:

  • There is a pinout diagram (or legend) of the charger’s plug on the charger’s plastic housing.
  • Despite the unique plug, the GBA-SP actually uses a very basic AC-DC power-supply that provides 5.2 volts DC @ 320mA.
  • 5.4 VDC is the charger’s measured open circuit output voltage. I assume it drops to ~5.2V once loaded.
  • The output power (both voltage and ampere) is within/around the USB standard. Nintendo could have arguably used a standard mini-USB port at the time (2002) to power the device instead.

GBA-SP audio cable plug pinout

Notables:

  • It is keyed for stereo sound, having two different audio channels that then share a return line.
  • The audio ground (or return, or drain) is not electrically connected to the device ground.
  • When inserted, the plug shorts the audio switch pin to ground
  • The only pin missing from the audio plug is the pin that corresponds the device’s V+ inlet pin.
  • Dedicated article: #0025: Modifying a pair of GBA-SP earphones into an aux audio dongle

GBA-SP audio/power port pinout

Notables:

  • Pin: Audio channel (right): carries the positive signal for the right channel (of stereo audio).
  • Pin: Audio channel (left): carries the positive signal for the left channel (of stereo audio).
  • Audio ground: functions as a return for both the right and left audio channels.
  • The GND pin, as well as the metal sheath of both the audio/power port and the adjacent communication port are all electrically connected.
  • The Audio switch pin has a floating voltage of 0.5 volts.
  • To activate the Audio switch: tie it to GND.
  • Pin: V+ is for the 5.2 VDC input from the charger.

Testing the audio switch on the GBA-SP

control test with an audio plug
test by manually shorting the audio pin

System freeze demonstration

While I was recording the testing of the audio/power port on the GBA-SP I came across a system freeze. Initially I placed it here because I thought it might be relevant to the audio/power port in some capacity. However after I had some time to think about what might have caused this system freeze, I have come to the conclusion that in all likelihood this freeze was caused by me putting pressure on the game cartridge as I inserted the audio plug into the console.

This likely then caused the cartridge to move slightly, but enough to break continuity between it’s pads and the console’s pins. Perhaps one or more of the GBA-SP’s pins moved onto a more insulated or corroded section of the cartridge’s pad(s). A section that is insulative enough that it either blocked or damaged the signal integrity beyond interpretation.

The main reason why I think this is the case, is because the audio/power port doesn’t deal with any data outside of audio signals. Certainly nothing that could cause a system freeze in my opinion. However what has caused multiple freezes in the past is tampering with the game cartridge while it is powered and in use.

Thoughts on Nintendo’s anti-consumer product design

In the previous GBA-SP dongle article I went on something of a rant on Nintendo’s anti-consumer design with regards to this particular product. In order to avoid rehashing those same points, I’ll keep my thoughts here concise, and offer them more as an addendum to that gassy rant.

To cut to the point. Yes I still think that the removal of the 3.5mm audio jack during the design iteration from the GBA to the GBA-SP was an anti-consumer gesture. Additionally I think this unique GBA-SP plug and socket design is woefully unnecessary; at least from a technical perspective.

As far as I can tell: Nintendo simply mashed together the functionality of the generic 3.5mm audio jack, and of the standard Mini-USB connector available at the time (~2002). They blended these two standards into their own bespoke plug and socket design. A proprietary design in which they can control the availability and price of. At least for the critical time period after the public product release, where there’d be the highest demand for accessories like this. Accessories, that they could then price gouge their customers on, with no competition (i.e. no legitimate alternatives).

The reason why I believe this to be the case, is that without the motivator of maximising profits: this design decision of creating proprietary alternative designs for already existing standard open designs makes little sense. Let us consider that if instead of this (immediate) profits driven motivator, the main motivator was to create a versatile and endearing product. One that will be usable long into the future due to the sheer availability of parts, and supporting accessories. Such as USB related componentry.

If they really wanted to make the best product they could for their customers: then I believe there is little reason not to use a Mini-USB port to power the device, and a 3.5mm audio socket for sound. This is especially evident due to the fact that the Mini-USB standard could already satisfy the GBA-SP’s power requirements of 5.2 volts at 300 milliamperes. Perhaps there were some licencing issues with regards to that idea that convinced them otherwise. It may even be the relative fragility of the Mini-USB socket that convinced them not to use it. I do believe that Nintendo’s proprietary port is more rugged than the Mini-USB port. I’ll give them that. I will also say that this is also one of the few instances where a “think of the children” argument may actually have some merit. Kids are generally destructive with toys. However I doubt that was the motivator here, at least not the main one.

Closing thoughts

I wanted to create this article initially for referential purposes, if not just for the sake of completeness. Prior to this, I wrote an article on creating a GBA-SP audio cable. This prior article featured a pinout diagram of this same port’s respective plug (audio version). However this diagram only featured labels relevant to the plug’s audio cable.

I didn’t even compare this information to their counterpart pins on the GBA-SP (or the charger’s plug). This is because I did not need to in order to achieve the stated goal of creating an audio adapter. If I did compare the pins, I would’ve found out that the lower “closed loop switch” pin (as I put it): is actually the main ground pin; and that “closing the loop” actually meant pulling the 0.5 volts from the top pin to ground. Although its essentially two different ways of saying the same thing: the latter method gives a more informed picture of what is actually going on. That is all this article is really for at the end of the day: to get a better idea of how that particular port works by using first hand experimentation and some deductive reasoning.

Anyway, I hope this article proves itself useful to you.

Thanks for reading.

Links, references, and further reading

https://www.tinkerersblog.net/0025-modifying-a-pair-of-game-boy-advance-sp-earphones-into-an-auxiliary-audio-dongle/
https://en.wikipedia.org/wiki/USB_hardware#Mini_connectors
https://en.wikipedia.org/wiki/Game_Boy_Advance_SP

#0027: Dominions 4: Thrones of Ascension map creation guide

Otto

#0027: Dominions 4: Thrones of Ascension map creation guide

Preamble

This is a quick bullet point style guide to how I create maps for IllWinter’s game: “Dominions 4: Thrones of Ascension”. Note: I will henceforth refer to the Dominions 4 game binary as “dom4”.

Map creation steps

Step 1: acquire or create a base image to use as the map.

I created an image using the GIMP image editor, and saved the multilayer project file (.xcf).

Step 2: use an image editor program to alter/create an image to conform to a standard that the dom4 executable can recognise.

Image specifics:

  • image must be in the Truevision TGA (.tga) or Silicon Graphics Image (.rgb) image format
  • minimum image size: 256×256 pixels
  • recommended image size: 1600×1200 pixels
  • image must be in 24 bit or 32 bit colour depth
  • image must be either uncompressed or using run-length encoded (RLE) compression
  • image must use a white single pixel as a province marker
  • white = HEX:#ffffff, RGB:(255,255,255)

Step 3: using the image editor, export a correctly formatted image.

I exported a TGA image file to specification, with a size of 256×256.

Example image file name: “tutorial_map_256x256.tga”.

Step 4: copy that image file to the dom4 working directory.

Working folder directory:

  • Linux: ~/.dominions4/
  • Mac: ~/.dominions4/
  • Windows: %APPDATA%\dominions4\

Step 5: boot up the dom4 game, and navigate to the game’s internal map editor.

Menu navigation: Game Tools > Map Editor > New map > (enter image file name)

This will automatically create a map. By populating it with provinces (one at each white pixel), then guess at the links between the different provinces.

Step 6: use the in game map editor to edit the map data.

This includes: mapping links between provinces, formatting link types (mountain, river, ground); terrain types (forest, farm, sea); throne sites, special sites, and so fourth. Its important at this stage to generate random names for each province, this is in order to populate within the .map file relevant code for the province names.

Example: #landname 1 “Deepmount”

  • example with no province markers
  • clean map
  • name edit
  • saving map name
  • example with imported image

Step 7: save the map. This will generate a .map file in your dom4 working folder.

tutorial_map_256x256(newly_created).mapDownload

Step 8: using a text editor: edit the .map file data such as the in-game map name, map description, and province names.

tutorial_map_256x256(customised).mapDownload

Step 9: test play the map, and troubleshoot errors.

If the dom4 program crashes as soon as you load up the map. Then it is indicative of a hard fault. For example, the tutorial map here crashes if you try to add more than 4 nations to it. Other crashes like this can be caused by the dom4 binary being unable to find a resource. E.g. the user renamed/edited resource files, then tried to load into a game that uses them.

Step 10: backup and archive your map

Example archive contents:

  • GIMP project file (.xcf)
  • original image file (.png)
  • processed image file (.tga)
  • map source code (.map)

Map files

tutorial_map_256x256Download

Closing thoughts

This method is probably the simplest way to actually create decent playable maps. By using the built in map creator tool, a user can bypass a lot of the tedium involved in coding. Such as learning the meanings of various symbols used for variables and game function, or learning the specific syntax used to generate a viable .map file. This is because the in-game visual editor automatically populates the .map file with viable code. All the user has to do is use the visual editor to assign all the functionality that they require for each province by checking menu boxes. Save the map. Then circle back to the .map file to fill in a couple of titles (in game text fields) after that.

Ultimately, I think that this quick guide provides a good framework. One that an aspirant map creator can build on further by reading IllWinter’s map making manual. Which in turn will allow them to gain further insight into the mechanics of map making; including the ability for more advanced functionality. In the mean time, just these simple steps will enable users to create perfectly playable maps. Ones that should satisfy most.

Thank you for reading.

Links, references, further reading

manual_mapeditDownload

http://www.illwinter.com/dom4/manual_mapedit.pdf <<< MAP MANUAL
http://www.illwinter.com/dom4/index.html
https://github.com/Narroe/Dominions_4_custom_maps
https://en.wikipedia.org/wiki/Truevision_TGA
https://en.wikipedia.org/wiki/Silicon_Graphics_Image
https://en.wikipedia.org/wiki/Run-length_encoding