OSGetConsoleType is a function in the GameCube, Wii, and Wii U "OS" SDK library which obtains the "console type" of the currently running hardware. It is notable due to its inclusion of various prototype and special console types which are otherwise unknown, as well as discrepancies between the documentation for the function and the header files defining it.
Note: Most IDs mentioned therein do not have an accurate number of zeroes and cannot be directly searched within their original sources.
2000 Dolphin SDK
Note: The "2000 Dolphin SDK" is actually a small set of documents and header files found in the Official Dolphin Emulator 2.8 package dated to 2000; there is no full GameCube SDK which is this early publicly available. (GameCube SDK and Dolphin SDK are synonymous)
The GameCube SDK OSGetConsoleType documentation says that the leftmost bit distinguishes development and retail console types (1 being development and 0 being retail), with the rest being a "minor revision number". The console type for the Mac emulator (see Official Dolphin Emulator) is 100000, followed by the PC emulator which is 10000001. This signifies that the Mac emulator likely came before the PC emulator, also supported by OS_CONSOLE_EMULATOR being the identifier for the Mac emulator and OS_CONSOLE_PC_EMULATOR being the identifier for the PC emulator; this may be due to Macs being PPC-based at this point, making it easier to create an "emulator" for Macs due to the similar hardware architecture.
Next up is "Arthur", ID 1000002, described as a "PPC750 evaluation board". The PowerPC 750 is the CPU of which a variation is used in the GameCube and Wii. It can be assumed that the emulator was made first before any of the hardware was made to test out the API (hence how old the emulator is), then the first hardware was a board with a stock PPC750, this board being "Arthur".
Next up there's the "Minnow", which is described as a "prototype development system without graphics". It's unknown why Minnow didn't have graphics support, or if Arthur and the emulator (at this point) did or not; it can be assumed that the emulator probably had some basic graphics support, but the Arthur might not. It's worth noting that Minnows are baby dolphins, which might be a hint as to their intentions with this system. It's also possible that this system was made before the GPU specifications were defined and there was no graphics support in the emulator or Arthur, or that this system was made specifically to not have graphics support.
Next, there's the developer HW1 board, then the developer HW2 board. HW1 refers to the early prototype specification of the GameCube, whereas HW2 is the final one. Interestingly, retail-spec boards for both HW1 and HW2 are listed; since there was obviously never a retail HW1 board due to it being a prototype, this may signify the existence of a prototype retail-specification board, possibly with a beta IPL.
Next, looking at the header file for the OS library in the GameCube SDK, some items of interest can be found in the file's inline revision history. It is worth noting that Shiki Okasaka's name is attached to many of these revision entries. The "Gecko" platform (not Gekko, this was either a mistake or it was Gecko at one point) is mentioned in an entry from Dec 1998, so they had that name down early. It mentions adding definitions for Gecko, so presumably other platforms existed at this point as well.
In March 1999, the Arthur board was mentioned, specifically stating that some items in the file were only relevant to the header board; this provides the earliest date for when the Arthur board could have existed. It is stated that the PPC APIs are only relevant to the Arthur board, so it is likely that at this point only the Arthur board and the "emulators" existed; this matches the emulators being first ID-wise, followed by the Arthur board.
In April 1999, the OSGetConsoleType function itself was added. In May, PPC was changed to EPPC, signifying a change to the Embedded PowerPC series. Skipping forward to December 1999, there is a mention of Minnow (specifically adding clock speeds for Minnow); this signifies a large gap between Arthur and Minnow. It also mentions new core/bus speeds for "Gekko + Spruce". It is unknown what Spruce is; it may be a codename for a chip inside the GameCube, or it may have been an early board using the Gekko CPU protoype instead of the generic PPC750 which Arthur used, with Minnow being a version of Spruce.
In January 2000, there is a mention of "MINNOW_MARLIN"; "Marlin" is also used to refer to a component of the optical disc emulator system in GameCube devkits, and it is unknown what exactly MINNOW_MARLIN refers to. A couple hours later, this was changed to simply "MINNOW". In February 2000, HW1 was added, and then 15 days later they revised all the OSGetConsoleType definitions. In May 2000, they added clock configurations for the HW1_DRIP platform (an early HW1-based platform with low memory capacity), indicating that HW1_DRIP and HW1 likely coexisted.
In June, Minnow's clock speed definitions were rolled back for bootrom compatibility purposes. In September, they added HW2 definitions, followed by "RETAIL2" (retail board type) definitions, but there are no records of them adding RETAIL1. There are no mismatches between the header file and the documentation in this version of the SDK.
Later Dolphin SDK
This SDK is where some mysteries start to arise; DEVHW3, DEVHW4, RETAIL3 and RETAIL4 were added, but there is a notice stating that in software HW2 and later as well as RETAIL2 and later are identical. As such, it is unknown what the difference between them is; depending on when this SDK was created, it could refer to the later revisions of the system including DOL-101 and the revised DOL-001, however this is unclear.
Notably, in one part of the documentation, RETAIL3 and RETAIL4 are not listed. There is also no revision history included; however, there are no mismatches between the header file and the documentation, and it is otherwise identical to the prerelease GameCube SDK.
The header file revision history does not include the addition of RETAIL3 and RETAIL4, but it does include the addition of TDEV information and "etc." in early 2003, which may include RETAIL3/RETAIL4. This would indicate that RETAIL3 and 4 were planned at the same time, and may be related to TDEV.
Revolution SDK 2.1
In 2003, the TDEV platform was added. In February 2006, console types were updated. In May, clock values were updated. In July, the NDEV 2.1 was added. Oddly, the OSGetConsoleType page in the 2.1 SDK (which was built in August) had not been updated since the release of the SDK in March, and as such does not list the NDEV 2.1 (which was released in August) despite it being present in the header files. The documentation in this SDK has all of the finalized GameCube console type documentation, which raises an additional question due to the presence of a "TDEV HW1" platform; since the TDEV and HW1 did not coexist, it is unknown what this refers to exactly.
In this documentation, TDEV platforms now have their own number to separate them from development and retail in the IDs; it is unknown why this was done, as TDEVs are development units. One part of the documentation only mentions NDEV 1.0 and 1.1, but another part also mentions 2.0; it is possible that 1.2 was not yet planned at this stage and may have been released as a quick bugfix revision to the hardware. The NDEV IDs are 10000010 for 1.0 and 100000011 for 1.1, since this was before the release of 1.1 this appears to reaffirm that 1.1 was planned but 1.2 was not. 2.0's ID is listed as "????" (even though logically it would be 10000000020) as with the production version system ID.
All of the legacy GC console IDs are listed as "for compatibility purposes only", including the emulator and the TDEV hardware. Oddly, all of the HW1 listings are missing from this document (including the TDEV HW1 listing), as well as the PC_EMULATOR; these were likely removed due to being outdated, and as Nintendo did not release any Mac tools with the Wii SDK, it is possible that EMULATOR and PC_EMULATOR became the same thing making PC_EMULATOR unnecessary. It also states that console type info was undetermined as of SDK 1.0, reaffirming that this document had not been updated since RVL_SDK 1.0.
Looking at the header definitions reveals some interesting information. All the NDEV versions are specified including 1.2 and 2.1. The Wii (RVL) definitions are separated from the GameCube ones; RVL_RETAIL1-3 are listed as 0000021-000023. It is unclear what this means exactly, as at the time of the SDK release there should not have been more than one retail version of the Wii defined; as such, these may refer to unseen prototype retail boards. They may also correspond to NDEV versions, or have been used as identification for the RVT-R Reader and RVT-H Reader; it seems logical that the original retail unit would be RETAIL1, the RVT-R would be RETAIL2, and the RVT-H would be RETAIL3, as the RVT-R and RVT-H (particularly the former) were meant to somewhat simulate a retail environment. Since the RVT-H is much farther from a retail system than the RVT-R, it is possible that only the RVT-R was used as RETAIl2, and RETAIL3 was reserved for future use; this is completely unknown, however.
Similarly, there are the "PP" (pre-production) boards (See Pre-Production Boards). The disassembly in the section below reveals that these boards were pre-release retail units corresponding to NDEV versions.
In the separate section for legacy GC definitions, the Revolution Emulator is found with ID 1000008, which is the next ID from DEVHW4. It is unknown why it is considered to be a GameCube console type, however it is likely that the Revolution Emulator is not substantially different from the Official Dolphin Emulator, and since it was likely used very early in the Wii's development, this may be why it is considered to be a GC platform. It is also worth noting that the TDEV platforms actually start at an ID analogous to MINNOW rather than HW1, being (last digit of ID) 4-7. Overall, the biggest mystery here is the different RVL_RETAIL types and the PP boards.
Revolution SDK 3.1
In June 2007, OS_CONSOLE_RVA_PROD1 was added, the console type for the Revolution Arcade system.
Latest RVL_SDK OSGetConsoleType disassembly
The OSGetConsoleType function in the last released RVL_SDK version has been disassembled, revealing the following:
- Wii platform version identification is done primarily by the Hollywood revision. Hollywood revision 0 is NDEV 1.0/PP0, revision 1 is NDEV 1.1/PP1, revision 2 is NDEV 1.2/PP2-1, revision 16 is NDEV 2.0/PP2-2, and revision 17 is NDEV 2.1/final retail.
- The Pre-Production Boards correspond to each NDEV version. It is possible that the E3 2006 RVT-R Reader is classified as one of these boards. It is unknown where PP3 and "Pre-Product 4" lie in this, although it can be assumed that they are identified as the final retail unit.
- In the latest RVL_SDK, code for the GameCube return values and the RVL_EMU return value has been removed. RVA is also not present. However, for unknown reasons, the Arthur board return value is still present, and will be returned depending on a certain memory location's value. This code may have been repurposed as with other return values (the generic development value is repurposed from the EMULATOR value and the NDEV 2.0 value is repurposed from the generic TDEV value), so it may not be intended to identify the Arthur board.
Cafe SDK 1.7
The Cafe SDK 1.7 (from around August 2011)'s OSGetConsoleType documentation is notable for being very, very old; as with the RVL_SDK 2.1 definitions, they had not been updated since the first release of the SDK, and are dated back to August 2010; an extremely old date as far as Wii U development history goes.
The OSGetConsoleType documentation from this SDK is watermarked as a draft, and only lists the CAT-DEV 1.0, which has the very odd ID of 0x13000048. It is unknown how this ID was determined; "13" may be a continuation of the earlier GC/Wii IDs, and "48" could be an internal revision number for the CAT-DEV 1.0, revealing the existence of many internal versions earlier than the CAT-DEV 1.0 (which was released in late 2010). The document has the footer "CAFE-01-0001-001-A" at the bottom, indicating that it is one of the first documents for the Wii U SDK ever created (or at least released publicly); see Nintendo SDK Document IDs.
The Cafe SDK's OSGetConsoleType header files have not yet been found.
Cafe SDK Latest Version
Finally, the latest version of the Cafe SDK has seemingly quite incomplete OSGetConsoleType documentation, albeit still as useful for developers as it needs to be; it was last updated in 2013, but only as an "automated cleanup pass"; the actual last update was in March 2012 to add a new return value, and otherwise, the document is unchanged from the 1.7 version.
The new return value added is OS_CONSOLE_CAFE_1_0, ID 0x03000050, which is described as being for "CAFE or CAT-R"; it is unknown what "CAFE" refers to, but CAT-R is a type of Wii U development kit and it is logical that this ID would refer to it, although it is odd that the Wii SDK does not seem to have analogous console type values for the RVT-R Reader and RVT-H Reader; these could be related to some of the unknown values such as the later retail numbers or RVA_PROD1.
The CAFE_1_0 ID itself is quite unusual, and there are no clues whatsoever as to its origin. Interestingly, later in the document, it is stated that 0x0 for production systems is returned on CAT-R systems (which, as with RVT-R systems, are meant to be analogous to production systems), however this does not seem to match up with having a unique ID for the CAT-R (and "CAFE"); however, this could still refer to the ID starting with 0x0.
Overall, the main mysteries here are the mention of "CAFE", and the lack of updates since the original version.
Key Mysteries & Things which we have limited or no information about beyond OSGetConsoleType definitions:
- GameCube Retail and Dev units 3 & 4
- TDEV units 1, 3, & 4
- RVL Retail units 1-3
- The "CAFE" platform
- How RVT-R and RVT-H units were identified; could they have been RVL 2/3?
Overall, the OSGetConsoleType function documentation and definitions give us a glimpse into mysterious and unseen console and board types used during the early development of the GameCube & Wii consoles, and are the only reason we know about some of these console variants.