[ {} ,{ "title": "007 Agent Under Fire for Nintendo Gamecube Reverse Engineering", "url": "/007-agent-under-fire", "content": "IntroductionWelcome to our page dedicated to the technical details of the Gamecube game 007 Agent Under Fire! If you’re a fan of this classic first-person shooter game, you might be interested in learning more about the technical aspects that make it all possible.On this page, we’ll dive into the inner workings of “007 Agent Under Fire” and explore the hardware architecture of the Gamecube console, the game’s software code, and the various algorithms and techniques used to create the game’s immersive gameplay and stunning graphics. Whether you’re a seasoned game developer or just a curious enthusiast, you’ll find a wealth of information and insights here that will deepen your understanding and appreciation of this iconic game.So grab your controller and let’s take a deep dive into the technical details of Agent Under Fire!Game EngineThe game actually used two complete different engines to make up the complete game, one engine for the First Person Shooter part and the other for the Dirivng missions: Action Engine: ID Tech 3 engine Driving Engine: Believed to be the Need for Speed engineIDTech EngineThe FPS part of the game is using the id Tech 3 engine with ÜberTools, for more information about this engine checkout the following sources: History of ID Tech Engine - https://youtu.be/00S64bc-QBE Information about IDTech3 - https://en.wikipedia.org/wiki/Id_Tech_3 IDTech3 was open sourced - https://github.com/id-Software/Quake-III-Arena UberTools - http://www.ritualistic.com/content.php/games/uber/features.php http://ritualistic.chrissstrahl.de/games/ef2/gdkdocs/start.htmlEmulator Compatibilityhttps://wiki.dolphin-emu.org/index.php?title=007%3A_Agent_Under_FireGame Mods007: Agent Under Fire ReloadedMod for the gamecube version of 007 Agent Under Fire that fixes a few multiplayer balancing issues: https://www.romhacking.net/hacks/3731/ https://www.youtube.com/watch?v=sdloBZ-NYwU007 Agent Under fire Gamecube ExploitExploit to run unsigned DOL executable from memory card from Agent Under Fire on the Gamecube: https://github.com/FIX94/007-exploit-gc", "excerpt": "Introduction Welcome to our page dedicated to the technical details of the Gamecube game 007 Agent Under Fire! If you’re a fan of this classic first-person shooter game, you might be interested in learning more about the technical aspects that make it all possible. On this page, we’ll dive into...", "tags": ["gamecube","symbols","debug","reverseengineering","games"], "image": "/public/images/gamecube/007 Agent Under Fire.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Retro Reversing 2020 review and future plans", "url": "/retro-reversing-2020", "content": "Review of 2020In late 2019 when we set out the goals for 2020 we focused on what we thought would be the biggest drivers in terms of user engagement, however 2020 has other plans.For 2020:* create pages on all the major consoles devkits* create first youtube documentary* increase the quality of all existing pages* Refactor N64RE to use libRetroRevering* Pokemon Mini content and Reversing emulator* double twitter followers from 30 to 60 https://t.co/TGqZbv3zUn— RetroReversing.com - Reverse Retro Games (@RetroReversing) January 1, 2020We smashed the twitter follower goal thanks to all of you, which has meant an increase in traffic to new posts on the site, allowing us to experiment with new content and find out what users want next.The goal to increase quality of all existing pages was a bit vague and more work than a year would allow when factoring in new content, but we made great strides on this front including merging smaller pages and removing content which does not meet quality standards.The Youtube documentary didn’t pan out but was started multiple times throughout the year but never managed to meet our expectations.Pokemon Mini content was created along with a reversing emulator core, currently not stable enough to release and a few changes to libRetroReversing will have broken it after adding Game Boy and Game Gear support in 2020. However releasing this along with a few other cores will be top priority for 2021.We also did not manage to refactor N64RE to use libRetroReversing but again this will be covered as part of our Reversing Emulator work in 2021!Now onwards to what we actually archived this year..Development HardwareIn 2019 one of our most popular posts was on the Playstation One development hardware, this was helped greatly by the leaked PS5 development kit images that were circulating at the time. Official PlayStation 1 Development Kit (Hardware) For more information on PS1 Development Hardware check out this post. Development hardware is close to our hearts as a rare glimpse into what it was like developing for consoles back in the day. It is also hard to find good sources of information, with much of the information scattered around the net on twitter or old AssemblerGames posts.This gave us an opportunity to collate all the information from around the net that we can find and put it in a single place for anyone interested in getting a brief overview of all the development kit options, including 3rd party and consumer development kits.The most interesting in-depth posts we created this year were on the NES and SNES development kits and these tool a while to create due to lack of information. SNES (Super Famicom) Development Kit Hardware For more information on SNES Development Hardware check out this post. The most disappointing was the attempt to create a post for the SEGA Master System as there was pretty much no information we could gather about 1at or 3rd party development kits.Although we did manage to get some details together about the Game Gear devkits, and it is likely that developers used the same hardware due to the similarity of the two systems. Sega Game Gear Development Hardware For more information on GameGear Development Hardware check out this post. Disassembly & DecompilationIn May 2020 Ars Technica created an excellent post about the Mario 64 decompilation project, this not only linked to our site but also raised interest in people searching google for how to decompile N64 games, many of which ended up on our site.Ars Technica - Beyond EmulationThis was great at getting users in to the site but we will admit our content for N64 decompilation is severely lacking, this is something we want to fix in 2021 which also ties into the N64 Reversing Emulator.We also used this as an opportunity to create a post on all the known decompilation/disassembly projects for retail console games, as far as we could tell there was no list of this nature available online. Decompiled Retail Console Games Check out the post here Reversing EmulatorsThis is a big part of the site that people don’t see, yet anyway. We spent time in 2020 building out libRetroReversing and adding support for Game Boy, Pokemon Mini, Game Gear and the Sega Saturn. Game Boy (DMG/GBC) Reversing Emulator Check out a few details about the upcoming GB Reversing emulator in the post here These are not ready to be released in 2020 and still require a lot of work before being released.However when they are they will play a big part in the “reversing” part of the site, such as tutorials and projects.This will allow us to create content to introduce complete beginners into romhacking and decompilation and hopefully grow the community of passionate reverse engineers.Nintendo LeaksWe can’t talk about 2020 without mentioning the Nintendo leaks, from January all the way to December there was a leak almost every month. All Nintendo Leaks Check out details about the main Nintendo Leaks in this post The biggest leak in terms of content that is interesting to use was the Gigaleak 1 and 2 as these contained the original source code for SNES, GB and Nintendo 64 games! Gigaleak 2 Electric Boogaloo - N64 Source Code Leak Check out details about the N64 Gigaleak in this post We have created overview posts on all of these leaks, but we need to revisit this in 2021 to go more in depth in what was contained in each leak and how to compile the source code.The Nintendo leak posts were by far the most popular on the site in 2020. The approach we took was to give an overview of each archive to explain what the content was and why it is interesting. This allows readers to decide which parts of the leak they are interesting in downloading from other websites, as we will never host any leaked material.We realise many users download the leaks and have no idea what they are looking at, so we try to keep the post as beginner-friendly as possible so people can learn how games were developed by Nintendo.Capcom LeaksNintendo wasn’t the only Japanese game company to have a data breach and source code leaked in 2020. Capcom had a huge amount of data stolen and some of the data was uploaded to the dark web.Unfortunately it wasn’t just source code leaked and in fact employee personal information was also uploaded.However we took care to only document source code for what we consider to be retro consoles: The Misadventures of Tron Bonne (PS1) Devil May Cry 2 (Ps2) Resident Evil Umbrella Chronicles (Wii) Capcom Leaks Check out details about the Capcom Source Code leaks in this post </p> </div> </blockquote></a></div>2021 & aheadLike most site we want to increase engagement in the new year with a focus on introductory reverse engineering posts and our reversing emulators.Goals for 2021 Release pre-compiled Reversing emulator with at least Pokemon Mini and Game Boy core included Twitter followers to 500 (from 365) Create a video tutorial for GB Reversing Emulator Create posts on SDKs such as GBA and N64 Create the remaining development hardware postsThe focus on producing a stable version of our Reversing Emulators will shift focus from creating posts to programming and learning about the hardware details, but this will pay off in the long run in terms of content.Development Hardware PostsWe aim to add new posts to cover some of the consoles we have not yet covered the development hardware for: Wii & WiiU DS & 3DS Vita Xbox & Xbox 360 Introduction to Development Kits (Hardware) click here to see the existing development kit posts we have </p> </div> </blockquote></a></div>Cleanup & QualityWe aim to cleanup some of the older posts, including removing posts that are no longer up to the same quality of the newer content.Since writing some of the posts other sites have covered the same topic in a much better way. For example copetti.org has added some excellent console hardware architecture posts in 2020 which we should link to instead of having our own inferior pages on the hardware architecture.We are after all just trying to give users a list of the best content available no matter which site it is on. The initial aim of the site was to create an “awesome list” for reverse engineering retro games and we still intend to do that, only providing our own posts for content that is not available elsewhere or we believe we can give a different perspective on.Thank youThank you everyone for making this year special, despite all the difficulties of 2020 the community has been incredibly supportive.Hopefully you will all have a happy 2021 and let us know if there is anything you would like us to cover this year.", "excerpt": "Review of 2020 In late 2019 when we set out the goals for 2020 we focused on what we thought would be the biggest drivers in terms of user engagement, however 2020 has other plans. For 2020:* create pages on all the major consoles devkits* create first youtube documentary* increase...", "tags": ["news"], "image": "/public/Articles/2020.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo 3DS (Citrus) Development Kit Hardware", "url": "/nintendo-3ds-development-kit", "content": "Official Development kitsNintendo’s official 3DS development hardware was created in collaboration with Intelligent Systems (IS) and Kyoto Microcomputer Co..CTR-TEG2 - CTR Target Board - Prototype Hardware The earliest known 3DS dev kit was a bare-bones prototype board used during development before the final 3DS hardware was ready, which has a resemblance to the prototype board that was leaked for the DS. An FCC filing in 2010 revealed a Nintendo CTR Target Board test kit consisting of two attached screens (a widescreen 3D top panel and a 4:3 bottom panel) mounted on a circuit board 1. This board included a Nintendo DS cartridge slot and SD card slot, indicating backward compatibility and storage, and was used to validate new components like the Wi-Fi module prior to the 3DS’s release 2. This early dev hardware made it clear that only the top screen would have Sharp’s auto-stereoscopic 3D capability, while the bottom screen was a standard LCD 1. The CTR Target Board allowed first-party developers to begin building 3DS software on prototype hardware months before the retail units were finalized, but as far as we know it was never used outside of Nintendo. IS-CTR-BOX Development Unit Nintendo initially produced a large “big box” 3DS dev kit known as the IS-CTR-BOX, designed by Intelligent Systems. The photo on the left is by SimonMK7 on twitter 3. This kit consists of a teal-blue external unit (“the box”) and a tethered 3DS-like controller. Notably, in this early design the handheld controller contained the main 3DS hardware (CPU/GPU), while the external box acted primarily as a “card emulator” for loading game code. The IS-CTR-BOX couldn’t operate with the controller unplugged because the “brains” were inside the handheld, unlike later units where the box housed the processing hardware. But the controller could be used without plugging it into the IS-CTR-BOX allowing for more portable testing! This dev kit was released around 2011 in limited quantities (estimated only a few hundred) before Nintendo quickly phased it out in favor of the Partner-CTR series, which offered greater functionality and a more standard setup 4. Looks like this finally arrived today. This is the IS-CTR-Debugger. Created by Intelligent Systems, this piece of hardware was used to help developers test & debug their games for the Nintendo 3DS. It includes the IS-CTR-Box, the SPR for Emulator unit & a Wii ac adaptor + cables. pic.twitter.com/SX1VWcMfHs— SimonMK7 (@SimonOrtizBrian) November 26, 2021Partner-CTR-Debugger by KMCNintendo’s main development kit for the 3DS became the Partner-CTR-Debugger, manufactured by Kyoto Microcomputer (KMC) in partnership with Nintendo.This system uses a two-unit design: a dev console (code-named CTR-001(-02), often called the Partner CTR Controller) which looks like a 3DS handheld, and a debugger host unit (the Partner-CTR) that contains the core hardware and interfaces.The handheld portion connects to the debugger box via a pair of proprietary high-bandwidth cables that plug into the base of the unit (occupying the game card slot area).The tethered 3DS serves as the input controller and display, allowing developers to interact using the real 3DS buttons and touch screen while their code runs on the dev kit hardware in the external box.The Partner-CTR Debugger box features USB connectivity to the development PC for deploying games and debugging, as well as connectors for the wired controller and other I/O (front panel slots exist for dev cartridges and SD cards, plus indicator LEDs and an IR port).This kit enables setting breakpoints, inspecting memory, and other runtime debugging on actual 3DS hardware.The Partner-CTR Debugger initially retailed for about $2,620 USD as a complete set according to an early leak from Planet3DS 5. This is the table they had on their now defunct website 5: Part # Item Price 73056 PARTNER-CTR DEBUGGER $2,620 73058 PARTNER-CTR DEBUGGER/CAPTURE (Dual Functionality) $3,950 73065 Nintendo 3DS (Development only) “Panda” USA $324 73066 Nintendo 3DS (Development only) “Panda” EU $324 73067 Nintendo 3DS (Development only) “Panda” AUS $324 73062 Flash Card, 16 Gbits (2 GBytes) CTR $85 73063 Backup Memory, 1Mbit (128 KBytes) Flash CTR $8.35 73064 Backup Memory, 4Mbits (512 KBytes) Flash CTR $10.65 It is hard to find good images for the non-capture version of the Partner-CTR-Debugger online but here is a video:Partner-CTR Capture Unit The Partner-CTR Capture device is a variant of the dev kit focused on video output and capture for testing or demonstration. It adds high-resolution video output capabilities, allowing the 3DS’s dual screens to be displayed on external monitors or capture equipment. The capture unit’s external box provides multiple output ports: two DVI-D outputs (one for each screen) for digital display A Nintendo Wii AV multi-out for analog video (composite/component). It also includes a USB output interface for direct capture to a PC. Using these, developers or QA staff could mirror the 3DS screens on large displays (up to 720p signal for each screen) or record gameplay footage, which was invaluable for preview events and creating game trailers. The tethered 3DS controller remains wired to the capture box, so a tester can play normally on the handheld while others view the action on big screens. Internally, the Capture unit is similar to the Debugger but with additional video encoder hardware. Nintendo offered a combined Partner-CTR Debugger/Capture kit at a higher price (~$3,905 USD for the dual-function model). These capture-enabled kits were rare and typically reserved for larger studios and events due to their cost and Nintendo’s strict licensing. Linus Tech Tips has a video showing the Partner-CTR Debugger/Capture kit in detail:The Photo below was posted by moreretrograde on Reddit:CTR-001-02 Partner-CTR Tethered Controller (Wired 3DS) The Partner-CTR development kits all use a special modified 3DS unit (model CTR-001-02) as the input device 6. Instead of a functional game cartridge slot, the unit has a panel with two locked cable connectors that attach to the dev kit box. Through these cables, the handheld’s screens and input are linked to the main dev hardware (video data is sent to the monitors/PC, and input is sent back to the game). The handheld itself is a dummy terminal containing only the LCD displays, speakers, and input controls – most processing and storage are handled by the external Partner box. This design lets developers experience the game on an actual 3DS form-factor (e.g. to test 3D effect using the real screen and to use the touch interface) while still benefiting from debugging and capture features in the host unit. The wired controller has a reduced internal board and is lighter, since many components (CPU, RAM, etc.) are relocated to the dev kit box. Nintendo continued this approach of a wired dev-unit controller from the DS era (e.g. the IS-NITRO-Emulator’s DS controller) because it effectively emulates the user experience while enabling full debugging on the PC. CTR-001-01 - Panda Development Consoles In addition to the full debugger boxes, Nintendo provided simpler development consoles, nicknamed Panda units, for teams to test games in a more portable, retail-like environment. A Panda unit is essentially a modified 3DS handheld that can run unsigned code and dev cartridges but lacks advanced debugging or video-out capabilities. Panda units use a unique colored shell (often white, silver or black mixes) and contain special boot ROMs and NAND software (Dev Menu, etc.), but otherwise are similar in specs to a retail 3DS. They can boot games from any region and from SD card or dev flashcards, bypassing the normal Home Menu for direct launch of software under development. However, they will not run standard retail cartridges (the keys differ) and cannot access online services like eShop in retail mode. These units were relatively inexpensive (~$324 USD each) compared to the full debugger kits, so studios would buy multiple Panda consoles for QA testers and developers to multiplayer test or continue work off-site. Elliot from The Retro Future has a video showing off the Panda Development Console:Aside from the case color and a “NOT FOR RESALE” type markings, they look nearly identical to a normal 3DS. (Notably, the term “Panda” was also used for the DSi debug units, continuing the animal-themed dev kit nicknames.)Rewritable 3DS Development Cartridges Like past Nintendo systems, the 3DS uses special re-writable flash cartridges to load in-development games. The official CTR flash cards resemble slightly thicker 3DS game cards with generic labels. One common model has a 16 Gbit (2 GB) capacity, and larger versions up to 4 GB (32 Gbit) were produced as well. These dev carts have no region lock and are reprogrammable – developers can flash their compiled game builds onto the cart and run them on Panda units or Partner-CTR kits. The cartridges do not have the physical write-protect notch that retail game cards have, and they are usually colored dark gray or other non-standard colors to avoid confusion with retail games. Inside, they contain flash memory for game content and no built-in save memory, unlike retail carts. Instead, the dev cartridges support external backup memory modules for game save data. The flash media can be erased and written thousands of times; developers noted they were “easily re-flashed… allowing for easy re-use” during the iteration process. Some flash carts used by Nintendo at trade shows were shorter (the size of a normal cart) and preloaded with specific demo software, but the taller official dev cartridges (approximately double height) allow inserting different capacity backup-memory boards and possibly contained additional debugging interfaces. Known Product IDs: E203344 - CTR FLASH CARD 16GbitBackup Save Memory ModulesTo accommodate various save sizes and types during development, Nintendo provided removable save flash chips for the dev cartridges instead of fixed internal save RAM. These are similar to how Sub Cards worked on the official Nintendo DS flash cards.These were often referred to as Backup Memory (Flash) for CTR and came in at least two sizes: 1 Mbit (128 KB) and 4 Mbit (512 KB), corresponding to the typical save sizes of retail 3DS games. Developers could purchase these backup flash modules for only a few dollars each and use them in conjunction with the dev cart.The tall CTR dev cartridge has a compartment or socket to insert the backup flash (similar in concept to the DS “sub card” system). This design let teams test their game’s save behavior with different memory sizes or technologies ( EEPROM vs. flash ) by swapping the backup chip.If a game needed, say, 512KB of save data, the corresponding 4Mbit module could be used to ensure the game functioned within that limit. Save Data Filer tools in the 3DS SDK allowed managing the contents of this save memory during testing. (On dev units, saves could also optionally be redirected to the SD card for convenience, but the physical backup flash was used to mimic the exact retail scenario.)Other Hardware AccessoriesThe 3DS development kits largely did not require the elaborate “gang writers” of older systems, since the Partner-CTR hardware and PC software could directly flash dev cartridges over USB.For example, the Host I/O (HIO) feature in the dev menu allowed installing game builds to a connected dev kit without manual cartridge writing. However, a few miscellaneous hardware tools were used in the 3DS dev pipeline: Debug and Link Cables: The Partner-CTR kits shipped with proprietary dual-cables for the controller hookup, as well as USB cables for PC connectivity and optionally extension cables for video output. Standard Wii AV cables could be used in the multi-out port of the capture unit for analog output. The dev kits did not use normal Wi-Fi for debugging; instead, they relied on USB or wired links for stability. Power Supplies: The Partner-CTR and IS-CTR-BOX units use external power adapters rather than the small 3DS AC adapter. In fact, similar to earlier dev kits, the IS-CTR-BOX was reported to use a GameCube-style 12V power supply, and the Partner-CTR may use a custom PSU (development units often had robust power requirements). Some kiosk demo 3DS units (CTR-001-05) even used a modified HDMI-like power cable for security in retail displays, but those were not used in development labs. Firmware Update Tools: To keep dev hardware updated with the latest system software and SDK, Nintendo provided development unit system updater cartridges/applications. Specifically, a “CTR System Updater” (CSU) was used for original 3DS-based units, and a “SNAKE System Updater” for New 3DS units, which install the latest dev firmware, OS, and tools onto the device. These updater programs (distributed as encrypted CIAs or carts) would bring a Panda unit’s system software in line with the SDK version target. Developers would run these periodically, as the dev OS included debug versions of the Home Menu, DevMenu, and other system applets with extra logging and features (for example, the dev Home Menu can display CPU/GPU usage and allows screenshot capture).Gyro Sensor Calibration CTRThe 3DS Gyro Sensor Calibration CTR hardware refers to a specialized software and hardware setup used during the manufacturing process of Nintendo 3DS systems, specifically at Foxconn. This calibration tool ensures the correct operation of the gyroscope sensor within the 3DS units.The calibration process involves measuring the gyroscope’s zero-rate offset, which is the sensor’s output when it is stationary and should ideally be zero. This offset arises due to manufacturing variances and sensor imperfections. The calibration software collects multiple readings to determine this offset and adjust the sensor’s output accordingly, ensuring accurate motion sensing during normal use.New 3DS Snake Dev KitsWhen the New Nintendo 3DS was introduced (with upgraded CPU, additional RAM, and new functions), Nintendo also updated the dev hardware. Revised development kits code-named SNAKE were offered, incorporating the New 3DS’s improved specs.These were essentially Partner-CTR Debugger/Capture devices with upgraded internals to match the new model’s faster processor and added features. For instance, the SNAKE kits allowed testing the extra CPU core and extended memory mode available to New 3DS titles.The overall form and function remained the same (tethered New 3DS unit and dev box). This ensured backward compatibility while enabling development of exclusive New 3DS software and performance tuning on the new hardware revision. The SNAKE name appears in update tools and documentation, but the hardware was still generally referred to under the CTR Partner branding by developers.By late in the 3DS’s life, tools like Unity and other middleware also supported the hardware, but these were software-side improvements.Third-Party and Partner Development ToolsUnlike the DS era, no separate third-party commercial dev kit (such as SN Systems’ ProDG) came to market for the 3DS – the Partner-CTR series effectively was the standard. (SN Systems had announced DS support years prior, but by the 3DS launch SN Systems was owned by Sony and did not provide a 3DS solution.)Instead, licensed developers all used Nintendo’s provided SDK and hardware kits. The SDK included compiler toolchains, debugger software for the Partner-CTR, and even a Visual Studio 2010 integration plugin for coding on 3DS. Some studios did employ additional tools in their pipeline: for example, Proprietary analyzers and profilers (like SN Systems Tuner or homegrown performance tools) could be used on the output from the dev kit to optimize code.But the core development and debugging always revolved around the Nintendo-provided hardware. Nintendo also had an online platform (NintendoWare/NW4C) for developers to download sample code, libraries, and documentation throughout the 3DS’s life. In summary, the 3DS did not see any alternative dev units from third parties; the official Partner-CTR debugger/capture and Panda units were the universal solution for 3DS game development.One notable third-party contribution was the middleware and engine support that grew later in the 3DS lifecycle. For instance, Unity for New 3DS was released as an add-on, allowing developers to use the Unity engine and deploy to 3DS hardware. Similarly, other engines (Unreal Engine variants, etc.) and tools (like audio and physics libraries) were made compatible with Nintendo’s hardware, but those were purely software.On the hardware side, companies like Kyoto Microcomputer were essentially acting as a contractor for Nintendo – the Partner-CTR units are sometimes branded with KMC’s logo and they handled distribution in some regions. Nintendo’s close control over 3DS development meant unofficial hardware was not really seen in studios.References IQGamer: 3DS Development / Test Hardware Revealed? ↩ ↩2 CTR-TEG2 (3DS Devkit from 2009) - All Known Media - Internet Archive ↩ SimonMK7 on X: Here are some images of the IS-CTR-Box/Debugger ↩ Nintendo 3DS IS-CTR-BOX - Consolevariations ↩ Planet 3DS - Exclusive: Nintendo 3DS Dev Kit prices leaked ↩ ↩2 3DS Hardware ↩ ", "excerpt": "Official Development kits Nintendo’s official 3DS development hardware was created in collaboration with Intelligent Systems (IS) and Kyoto Microcomputer Co.. CTR-TEG2 - CTR Target Board - Prototype Hardware The earliest known 3DS dev kit was a bare-bones prototype board used during development before the final 3DS hardware was ready, which...", "tags": ["3ds","devkit","hardware"], "image": "/public/generated/placeholders/nintendo-3ds-development-kit.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo 3DS File Formats", "url": "/3DSFileFormats", "content": "The Nintendo 3DS (Codename CITRUS) utilises a number of different file formats either created by Nintendo or third party. If you are interested in reverse engineering a 3DS game then you will most likely come across these formats, so it is a good idea to have at least some knowledge of how they work.The main file formats used in Nintendo 3DS games are outlined in the table below, with further detail in the sections of this post. Extension Description .3ds Unofficial format used for dumping 3DS Game Cards .cci Nintendo Official file format for dumping 3DS game cards .csu 3DS Update file .cxi Citrus Executable Image - archive that contains executable game code .app Another name for .cxi files .cfa Citrus File Archive - compressed file that doesn’t contain executable code e.g for Game Manuals .cia Citrus Installable Archive - used for games that get installed to the 3ds memory NCSD FormatsNintendo Citrus Standard formats are used for game cards and system updates.There are three different extensions for the same file format: .3ds/.cci and .csu.They all basically just contains NCCH format files such as (.cxi/.cfa/.app/.caa)1 which are documented in the NCCH section..3ds (3DS Game cards)The .3ds format is commonly used unofficially to represent what Nintendo calls .cci files. They are Game cards for the Nintendo 3DS.You can extract with:3dstool -xvt017f cci 0.cxi 1.cfa 7.cfa input.3ds --header ncsdheader.binThis will create the following files: ncsdheader.bin 0.cxi 1.cfa 7.cfaNote that CXI and CFA files are NCCH formats that are covered in a section below..cci (Citrus Card Image)The CCI format is exactly the same as the .3ds extension, it is the official file extension that Nintendo uses for 3DS game cards..csu (Citrus Sytem Update)Nintendo 3DS (Citus) System Update files have the extension .csu but are exactly the same as any other NCSD format in that they are just an archive that contains NCCH-based files.NCCH FormatsNCCH files are always wrapped in a NCSD format as mentioned above, but there are two different types based on if they have executable ARM11 code in them. or not.Check out 3DBrew for a nice guide to NCCH file formats:NCCH - 3dbrew.cxi/.app (Citrus eXecutable Image)These are files that contain executable ARM11 codeYou can extract the files with:# extract cxi without encryption3dstool -xvtf cxi 0.cxi --header ncchheader.bin --exh exh.bin --logo logo.bcma.lz --plain plain.bin --exefs exefs.bin --romfs romfs.binThis will create the exefs.bin which holds the executable ARM code and a romfs.bin which contains other data.ExeFS (Executable File System)NCCH files can contains executable file system partitions (ExeFS), these are ARM code that run on the 3DS processors.Convert ExeFs to ELFHere is a useful tool to convert ExeFS into the standard ELF format, loadable in other reverse engineering software such as Ghidra or IDA Pro.archshift/ctr-elf: Converts a 3DS program’s EXEFS to an (IDA-loadable) ELF–.cfa (Citrus File Archive)Citrus File Archives are NCCH files that do not contain Executable code, so they contain other things such as electronic manuals.References .3DS vs .CCI ROM File Formats? - General - Citra Community ↩ ", "excerpt": "The Nintendo 3DS (Codename CITRUS) utilises a number of different file formats either created by Nintendo or third party. If you are interested in reverse engineering a 3DS game then you will most likely come across these formats, so it is a good idea to have at least some knowledge...", "tags": ["3ds","fileformats"], "image": "/public/images/3ds/Nintendo 3DS File Formats.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "3D Software used in Retro-era Game Development", "url": "/3d-software", "content": "IntroductionThis post will focus on 3D software used to produce commercial video games in the 90s up until the 2010s due to the focus of this site being retro game development.The table below shows some of the most popular 3D software for the games industry along with who made them and the price they sold for: Name Company Price Notes Visual Reality 2.0 Visual Software very little information on this after 1996 (website in 1999 doesn’t mention it: Wayback Machine)   LightWave 3D 4.0 DPS £816.63 1995 How Were 3D Game Cut Scenes Developed?Before game engines were capable enough to be used for in-game cut scenes, game development studios would need to use software to render video files that would play back inside the game.Studios would either contract the job out to third-party animation studios, which normally did animation for TV and movies, or work on them in-house with specialized artists. These teams would be given the same concept art as the game artists but would have much more polygons and computing power to work with due to not having the limitations of real-time rendering.What 3D Software Was Used to Create Cut Scenes in Retro Games?The most popular 3D software for developing retro game cutscenes included: 3D Studio Max Maya SoftImageWhat Compositing Software Was Used to Create Retro Game Cut Scenes?Most of the compositing software used for the VFX and animation industries was also used for game cut scenes. A few of these are listed below: Combustion by Discreet Logic (Autodesk) Henry by Quantel After Effects by Adobe Nuke by Foundry Blackmagic Design’s FusionWhat Animation Software was used? morpheme by Natural Motion (PS3, Xbox 360, PC)Popular 3D Art SoftwareThe software in this section are used by hundreds if not thousands of games and could be considered the industry standard.3D Studio (Max)3D Studio (later 3D Studio Max) is an incredibly popular 3D modeling software in the games industry and it is still going strong today (as of 2025).We have a separate post on 3D Studio Max which you can find below: 3D Studio (Max) For more information on 3D Studio check out this post. LightwaveLightwave used by Team17 for WORMS on the AmigaRetro Recipes has an incredible video about discovering and exploring the original development Amiga 4000 used to create the classic game Worms. The video documents the process of recovering data from the aging hard drives, revealing original Lightwave 3D animation files, FMV assets, and even unreleased artwork, guided by the original developer, Chris Blythe.Obscure 3D Art SoftwareThe software in this section are more obscure and may have only been used for a handful of games, but they were viable choices for smaller studios due to their cheaper price.3D-Brush (Later 3DCoat)At only $70 3D-Brush was a very cheap alternative to ZBrush and Mudbox and was developed by Dmitriy Yanev, who was the former lead coder from the Ukraine based game development studio GSC Gameworld (Cossacks game series).It was later rebranded to 3D-Coat in early 2008 and it is still a viable product in 2025! However it is unclear which commercial games, if any, used this during the development process.Here is a screenshot from the old 3d-brush.com website showing the 1.82 Beta version interface:References", "excerpt": "Introduction This post will focus on 3D software used to produce commercial video games in the 90s up until the 2010s due to the focus of this site being retro game development. The table below shows some of the most popular 3D software for the games industry along with who...", "tags": ["3d","software","tools"], "image": "/public/generated/placeholders/3d-software.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "3D Studio (Max)", "url": "/3d-studio-max", "content": "Introduction3D Studio started life as a prototype called MODEL created by Tom Hudson for Yost Group back in 1988 and evolved to become one of the most used 3D Modeling programs in the games industry.Version HistoryThere is an excellent article on BeforeAndAfters about the history of 3DS (Max) which is available here:https://beforesandafters.com/2020/06/04/a-visual-history-of-3ds-max/This section will guide you through the main releases of 3D Studio by year so you can get an idea of what it was like for game artists at a certain period in time.3D Studio Prototype (Nov 1988)Tom Hudon released a video on Vimeo where he goes back to his earliest prototype version that he had access to, runs it in dosBox and provides interesting commentary on how it all works 1.Many of the menu items, especially under the Program menu were not yet implemented such as the Materials/Lighting/Camera but are in the menu to show off what it aims to do in the future.3D Studio Release 1 (1991)Edward Clay has uploaded a video 2 that shows off the first release of 3D Studio, it was created for a NAB conference in 1991 and shows 3D animation and stills created in 3D Studio, which are very impressive for the time.3D Studio Release 2 (1992)Advertising such new features as Boolean sculpting and postscript font support the Demo Reel created by AutoDesk was uploaded to YouTube and you can view it below 3:World Creating ToolkitShipped along with the main product is what AutoDesk call the “World Creating Toolkit” which was about 500MB of royalty free 3D models and other resources. Or in their own words: The World-Creating Toolkit on CD-ROM, included with 3D Studio, provides more than 500 MB of prebuilt objects, meshes, fonts, animations, and backgrounds–all royalty-free.There is a CD on Archive.org for “Autodesk 3D Studio Release 2 World-Creating Toolkit” , you can find it here: Autodesk 3D Studio Release 2 World-Creating Toolkit : Autodesk, Inc. : Internet Archive.3D Studio Release 3 (1994)Requiring MS DOS 3.3 or Later, the third version of 3D Studio was released in 1994 and cost a whopping $2,995, you can view a demo that AutoDesk created for R3 below:It goes through and shows all of the main features, if you are interested in what it was like for early 3D artists this is the best video to watch, thanks to DOS Nostalgia for uploading it!The Video covers: The 3D Editor and the 4 different views, Top/Front/Left and User The 2D Shaper - create 2D shapes in a Vector like tool using basic shapes and boolean operators such as Union The 3D Lefter - take the 2D shapes and make them 3D Camera placement and lighting Materials EditorYou can also read more information about 3D Studio Release 3 in Game Developer Magazine June 1994.3D Studio Release 4 (1994)The software was becoming much more mainstream by Release 4 and even has a few books published about it: Inside 3D Studio Release 4 - New Riders Publishing - CD: Inside 3D Studio Release 4 - CD : Internet ArchiveA user called GansVFX 4 has uploaded a video of him running Release 4 in DOSBox which you can view below:3D Studio Max (1996)In 1996 3D Studio was rebranded to add the Max suffix to represent the move to Windows 95+ and started the numbering all over again.You can view a product demo created by AutoDesk in 1996 5 below:The video even shows Character Studio which is a tool to help create 3D animated characters and has built in animations for common walk cycles.3D Studio Max 4 (2000)3D Studio Max 4 was advertised at GDC 2001 including was a brief interview with Lance Alameda the Field Operations Manager at Discreet in the TV Show Electric Playground (Season 6 Episode 8) 6:Retro Games that used 3DS MaxGame Studios don’t tend to advertise which 3D modeling program they used for the creation of specific games, and models tend to be compressed into game specific formats when released. So it can be hard to tell what games used 3D Studio (Max) but the games we know about will be placed in the table below. Game Name Game Developer Notes Monopoly CD-ROM Westwood Studios Article from 1996 issue of CGW confirms this CGW: Feature: New Tools for 3D Gamers (12.96) LEGO Racers High Voltage Software Found 3d files that use the .max extension LEGO Research Realm MechWarrior Quantum Factory Electric Playground (Season 6 Episode 8) Metal Gear Solid Konami Electric Playground (Season 6 Episode 8) Premier Manager (PS2) Runecraft Issue 20 of PSi2 Magazine shows very low resolution screenshots of 3d modelling the statium which looks very similar to 3ds Max. Tomb Raider Core Design Electric Playground (Season 6 Episode 8) If you know any games that used 3D Studio for asset creation and have a source to back it up, please contribute by editing this page!Premier Manager and other games by RunecraftBased on issue 20 of PSi2 Magazine it looks like they use 3ds max for 3d modelling along with photoshop.Retro Movies that used 3DS MaxMovies are even harder to tell what software was used to create them as there are no left over artifacts available in the retail product. But occasionally an interview with an artist who worked on a movie will surface and confirm the tools that were used. Movie Name Studio Notes Jurassic Park: the Lost World DreamWorks Article from 1996 issue of CGW confirms this CGW: Feature: New Tools for 3D Gamers (12.96) References 3D Studio DOS Early Prototype.mp4 - YouTube ↩ 3D Studio Release 1 NAB Demo Reel (1991) - YouTube ↩ Autodesk 3-D Studio Release 2 Demo Reel (1992) - YouTube ↩ 3D Studio 1994 - YouTube ↩ 3D STUDIO MAX KINETIX DEMO 1996 - YouTube ↩ Electric Playground (Season 6 Episode 8) ↩ ", "excerpt": "Introduction 3D Studio started life as a prototype called MODEL created by Tom Hudson for Yost Group back in 1988 and evolved to become one of the most used 3D Modeling programs in the games industry. Version History There is an excellent article on BeforeAndAfters about the history of 3DS...", "tags": ["3d","tools"], "image": "/public/generated/placeholders/3d-studio-max.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "3DO Interactive Multiplayer", "url": "/3do", "content": "IntroductionThe 3DO Interactive Multiplayer, commonly known as the 3DO, was developed by The 3DO Company, which was founded by Trip Hawkins. Trip Hawkins is also a co-founder of Electronic Arts (EA). The 3DO was a multimedia gaming console released in the early 1990s and was known for its advanced hardware specifications and its open platform approach, allowing multiple manufacturers to produce 3DO consoles.Development HardwareThe 3DO offers a comprehensive development environment, even incorporating snippets from the extensive Time Warner movie library. It’s designed to be user-friendly, particularly welcoming to those without extensive programming experience. The entire setup, including the Apple Quadra it operates on, comes to about $15,000 in cost 1.Apple QuadraThe Apple Quadra was a series of personal computers produced by Apple Inc. during the late 1980s and early 1990s. These computers were part of Apple’s Macintosh line and were known for their advanced features, processing power, and expansion options at the time. The “Quadra” name was used to indicate the 68040 processor that many of these computers were equipped with.The Apple Quadra series included various models with different specifications and capabilities. These computers were used for a wide range of tasks, including desktop publishing, graphic design, and software development. The Quadra series was part of Apple’s efforts to provide high-performance computers to professional and power users.References Game Developer Magazine issue 1 ↩ ", "excerpt": "Introduction The 3DO Interactive Multiplayer, commonly known as the 3DO, was developed by The 3DO Company, which was founded by Trip Hawkins. Trip Hawkins is also a co-founder of Electronic Arts (EA). The 3DO was a multimedia gaming console released in the early 1990s and was known for its advanced...", "tags": ["3do"], "image": "/public/generated/placeholders/3do.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo 3DS (Citrus/CTR)", "url": "/3ds", "content": "IntroductionWelcome to our page dedicated to Nintendo 3DS reverse engineering! The Nintendo 3DS is a popular handheld gaming console that was released in 2011, and has since become a favorite of gamers around the world. If you’re interested in learning more about the technical aspects of this console and how it works, you’re in the right place!On this page, we’ve compiled a list of links to other pages that cover various topics related to Nintendo 3DS reverse engineering. Whether you’re interested in understanding the hardware architecture of the console, analyzing game code, or modding your favorite games, you’ll find a wealth of resources and information on the pages we’ve linked to.So sit back, grab your Nintendo 3DS, and get ready to dive into the exciting world of Nintendo 3DS reverse engineering!Project Citrus (CTR)During development the Nintendo 3DS has the codename Project Citrus (CTR) which was the follow up to Nintendo’s very popular DS (NITRO) and DSi (TWL) handheld video game consoles. It was fairly successful in the market but became their last handheld-only console as they switched to the hybrid model for the Nintendo Switch.Early Days Of 3DS HackingThe Youtube channel Tech Rules has made an excellent video explaining how the Nintendo 3DS was initially jailbroken, using a “terrible game”.HardwareIf you’re interested in reverse engineering Nintendo 3DS software, it’s essential to have a solid understanding of the hardware that powers the handheld console. By understanding the inner workings of the 3DS hardware, you can better comprehend how the software interacts with the hardware and how you can potentially modify or improve it.In this section of our guide, we will provide you with detailed information and resources on the hardware of the Nintendo 3DS, including retail, prototype, and development hardware.Retail Nintendo 3DS HardwareIf you’re interested in learning more about the hardware architecture of the Nintendo 3DS, we highly recommend checking out the post on Copetti.org. This website is dedicated to exploring the technical details of the Nintendo 3DS hardware, including the CPU, GPU, and other components that make up the handheld console. You’ll find in-depth explanations of how each component works, as well as detailed schematics and diagrams that help illustrate the inner workings of the Nintendo 3DS. Nintendo 3DS Architecture - A Practical Analysis Copetti.org has an excellent tear down of the Nintendo 3DS Hardware and how it works Nintendo 3DS Development Kit HardwareAll Posts Nintendo 3DS (Citrus) Development Kit Hardware Official Development kits Nintendo’s official 3DS development hardware was created in collaboration with Intelligent Systems (IS) and Kyoto Microcomputer Co.. CTR-TEG2 - CTR Target Board - Prototype Hardware The earliest... ... Read More 3ds devkit hardware Nintendo 3DS File Formats The Nintendo 3DS (Codename CITRUS) utilises a number of different file formats either created by Nintendo or third party. If you are interested in reverse engineering a 3DS game then... ... Read More 3ds fileformats Nintendo Ninja Leak The Ninja leak occurred on the 22nd December 2020 and is named after the contents containing information that prove the long-standing Nintendo “Ninja” myth. Including stalking and intimidation of a... ... Read More leak ds 3ds All Nintendo Leaks Nintendo has has many data leaks in the past, but none as huge as the original Oman Archive of the late 90s or the Gigaleaks of 2020. This post is... ... Read More leak nintendo 3ds gba Nintendo Paladin Leak The Paladin leak occurred on the 30th of September 2020 and included about 2.4GB of content related to the Nintendo IRIS and Pokemon spinoffs. This was the third Nintendo leak... ... Read More leak ds 3ds gba How does Twitch Play Pokemon? (Emulation through Twitch) Have you ever seen Twitch Plays Pokemon (TPP) and wondered how it actually works? How does typing comments in a twitch stream result in the player moving in the original... ... Read More introduction gameboy 3ds ", "excerpt": "Introduction Welcome to our page dedicated to Nintendo 3DS reverse engineering! The Nintendo 3DS is a popular handheld gaming console that was released in 2011, and has since become a favorite of gamers around the world. If you’re interested in learning more about the technical aspects of this console and...", "tags": ["3ds"], "image": "/public/generated/placeholders/3ds.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "The 6502 Microprocessor - Gaming's Unsung Hero", "url": "/6502", "content": "The 6502 MicroprocessorThe 6502 microprocessor was an 8-bit microprocessor that was incredibly popular for 8-bit home computers (e.g Apple II) and consoles (e.g NES) due to its low cost.Released by MOS Technology in 1975, the 6502 was designed by Chuck Peddle as an affordable alternative to the more expensive microprocessors of its time (such as the $300 Motorola 6800 that he also worked on) 1.History of the 6502The Apple Wiki provides a technical and historical profile of the MOS Technology 6502, the 8-bit microprocessor that powered the Apple I, Apple II, and Apple III. The entry details the chip’s architecture, including its registers and instruction set, and explains how its low price point enabled the mass market success of Apple’s early hardware. MOS 6502 - Apple Wiki The Apple Wiki details the specifications and history of the MOS 6502, the CPU behind the Apple I, II, and III. Usage in 8-bit Consoles and Home computersThe 6502 family shaped early commercial game development through its low cost, simple bus architecture, and efficient instruction set.Its derivatives powered many influential consoles and computers, enabling designers to allocate more silicon to graphics and audio subsystems while retaining sufficient compute for real time game logic: Apple II (6502) - Leveraged the base 6502 in combination with soft switches and an open expansion architecture that fostered rapid growth in commercial and hobbyist game development 1. Atari 8 bit Family (6502) - Combined with ANTIC and GTIA coprocessors, the 6502 enabled hardware assisted scrolling, sprites, and display list interrupts, introducing a more advanced rendering model. Atari 2600 (6507 variant) - Used a variant of the 6502, the MOS 6507 with no frame buffer and relies on cycle precise CPU involvement in video generation through the TIA. The programming model is fundamentally “racing the beam”. Atari Lynx (65SC02) - Used custom CMOS chip called “Mikey” (65SC02) which is a 6502 variant running at up to 4 MHz with hardware scaling, sprite engines, and coprocessor assisted rendering processor 2. BBC Micro (6502) - Provided high performance for its class with deterministic memory timing and a clean system architecture that supported both educational and commercial game software. Commodore 64 (6510) - A 6502 derivative with an integrated I/O port for bank switching, allowing flexible memory layouts and tight coordination with the VIC-II and SID chips 3. Nintendo Entertainment System (Ricoh 2A03/2A07) - A customized 6502 core without decimal mode, integrating the APU and I/O. Its deterministic CPU-PPU-DMA timing enabled the characteristic NES game pipeline.Nintendo Entertainment System (NES)The Nintendo Entertainment System (known as the Famicom in Japan) is an 8-bit console that revolutionized home gaming, powered by a 6502-based Ricoh 2A03 CPU. Our page serves as a comprehensive hub for reverse engineering the hardware, detailing the unique architecture of the Picture Processing Unit (PPU), the Audio Processing Unit (APU), and the system’s memory map. It also collects essential resources, tutorials, and tools for emulator developers and homebrew enthusiasts. Reverse Engineering NES Games - Uncovering the Secrets of Classic Gaming Welcome to our in-depth guide to Nintendo Entertainment System (NES) reverse engineering! This page serves two roles. It groups all of our posts related to reverse engineering for the system,... Reverse Engineering the MOS 6502 CPUIn this detailed technical presentation from the 27th Chaos Communication Congress, Michael Steil explores the inner workings of the MOS 6502 processor, the chip powering iconic systems like the Apple II, NES, and Commodore 64.The talk breaks down the reverse engineering process into three distinct approaches: top-down (analyzing the instruction set and quirks), bottom-up (using acid decapping and high-resolution die shots to vectorize the transistor netlist), and inside-out (simulating the logic to understand undocumented behaviors and illegal opcodes). This work culminated in the Visual 6502 project, a transistor-perfect simulation of the hardware.Dotnet6502: .NET 6502 Emulator LibraryDotnet6502 is a C# library designed to emulate the MOS 6502 microprocessor within the .NET ecosystem. Developed by KallDrexx, this project provides a managed-code implementation of the CPU architecture, suitable for serving as the core component in custom emulator projects or retro-computing tools. It leverages .NET Core to offer cross-platform compatibility for developers building 6502-based systems. Dotnet6502: .NET 6502 Implementation KallDrexx has released Dotnet6502, a C# library for emulating the MOS 6502 CPU within the .NET ecosystem, facilitating the creation of custom emulators and tools. DeiMOS: A Superoptimizer for the MOS 6502Aransentin has a write-up about DeiMOS, a superoptimizer designed specifically for the 8-bit MOS 6502 microprocessor. It covers how the tool differs from traditional compilers by exhaustively searching the entire space of possible instruction sequences to generate the provably shortest or fastest possible machine code for a given computational task. DeiMOS Aransentin details DeiMOS, a superoptimizer tool that generates optimal machine code sequences for the MOS 6502 by exhaustively analyzing instruction combinations. 6502 in Popular CultureThe Truth About Bender’s Brain: The 6502 ConnectionIEEE Spectrum investigates the famous Futurama easter egg that identifies Bender’s CPU as a MOS Technology 6502 microprocessor. The article features an interview with head writer David X. Cohen, who explains that the choice was a deliberate homage to his own teenage years spent coding 6502 assembly language for the Apple II. The Truth About Bender's Brain IEEE Spectrum explores the history behind the Futurama joke revealing Bender's brain is a 6502 chip, confirming the canon details with creator David X. Cohen. The 65C816 - The evolution of the 6502 into the 16-bit eraThe 65C816 represented a significant leap forward in the 6502 lineage. It was designed and produced by Western Design Center (WDC) as an extended version of the original 6502.Enhancements over the 6502This new microprocessor retained compatibility with existing 6502 software while introducing several key improvements: 16-bit Architecture: The most notable enhancement was the transition from an 8-bit to a 16-bit architecture. This upgrade allowed the 65C816 to address larger memory spaces and work with 16-bit data, enabling more powerful and feature-rich applications. Additional Instructions: The 65C816 introduced a range of new instructions, further expanding its capabilities. These instructions included support for 16-bit arithmetic, improved stack manipulation, and enhanced memory access modes. Enhanced Addressing Modes: The 65C816 introduced new addressing capabilities, including true 24-bit modes such as Absolute Long and Long Indirect, as well as additional forms like Stack Relative and Stack Relative Indirect that expand how programs access memory and structure data.Usage of the 65C816The 65C816 found its way into various gaming platforms and computers, where its improved capabilities became instrumental in delivering richer gaming experiences: Super Nintendo Entertainment System (SNES): The 65C816 CPU powered the SNES, a beloved gaming console that offered a plethora of iconic titles. Its 16-bit architecture and enhanced instructions allowed for more complex and visually impressive games. Apple IIGS: The Apple IIGS, an enhanced version of the Apple II series, also utilized the 65C816. This computer system brought arcade-quality graphics and sound to gamers, setting new standards for home computing.Super Nintendo’s Ricoh 5A22 CPUSnesLab provides a technical overview of the 65c816, the 16-bit microprocessor developed by WDC that serves as the core of the Super Nintendo’s Ricoh 5A22 CPU. The page details the processor’s relationship to the 8-bit 6502, explaining its “emulation mode” for backward compatibility and its role in executing the code for SNES games like Super Mario World. 65c816 - SnesLab SnesLab details the specifications and history of the 65c816 CPU, explaining its instruction set, 6502 compatibility, and its implementation in the SNES. Apple IIGSThe Apple Wiki entry profiles the WDC 65C816 (also known as the 65816), the 16-bit microprocessor developed by Western Design Center that powers the Apple IIGS. It explains how the chip maintains backward compatibility with the MOS 6502 via an “emulation mode” while offering a “native mode” with 24-bit addressing and 16-bit registers, effectively bridging the gap between 8-bit and 16-bit computing eras. WDC 65C816 - Apple Wiki The Apple Wiki details the technical specifications and history of the WDC 65C816, the 16-bit CPU used in the Apple IIGS that features full 6502 backward compatibility. Building a 65C816 Test BoardMike’s Software Blog details the design and assembly of a custom 4-layer PCB test board for the WDC 65C816 microprocessor. The project moves away from unreliable breadboard prototypes to a stable platform featuring extensive test points, a MIC2775 reset controller, and PLD-based address decoding. The post documents the transition to KiCad 6, various assembly challenges like clock signal routing errors, and the successful validation of the hardware. Building a 65C816 Test Board Mike's Software Blog documents the creation of a reliable 4-layer PCB for the 65C816 CPU, covering schematic design in KiCad, assembly debugging, and improved system stability. References MOS 6502 - Apple Wiki Fandom ↩ ↩2 Atari Lynx Specifications - Atari Lynx Vault ↩ MOS Technology 6510 - C64-Wiki ↩ ", "excerpt": "The 6502 Microprocessor The 6502 microprocessor was an 8-bit microprocessor that was incredibly popular for 8-bit home computers (e.g Apple II) and consoles (e.g NES) due to its low cost. Released by MOS Technology in 1975, the 6502 was designed by Chuck Peddle as an affordable alternative to the more...", "tags": ["hardware","nes","snes","cpu"], "image": "/public/images/hardware/6502.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "The Motorola 68000 - Powering the Gaming Revolution", "url": "/68k", "content": "The Motorola 68000 - Powering the Gaming RevolutionIntroductionThe video game industry has witnessed remarkable technological advancements throughout its history, with one pivotal component that played a significant role in shaping the industry as we know it today: the Motorola 68000 microprocessor. This powerful and versatile CPU, initially released in the late 1970s, made its mark by powering some of the most iconic and beloved games in the 1980s and 1990s. In this article, we will delve into the evolution and impact of the Motorola 68000 in the games industry.The Birth of the Motorola 68000The Motorola 68000, often referred to simply as the “68000” or “68k”, was first introduced in 1979 as a 16/32-bit microprocessor. It quickly gained recognition for its capabilities, combining a high clock speed with a rich set of instructions, and ease of programming. This made it an ideal choice for various applications, but its true potential became evident when it found its way into the emerging video game market.The Arcade RevolutionIn the early 1980s, arcade games were at the forefront of the gaming industry. These games required powerful hardware to deliver engaging and immersive experiences. The Motorola 68000 found its home in many arcade machines, such as Sega’s “OutRun” and Capcom’s “Street Fighter II”. Its processing power and flexibility allowed developers to create visually stunning and fast-paced games that captured the hearts of players worldwide.The 68000’s architecture allowed for smooth and fluid animations, enhancing the gameplay experience. This capability was particularly evident in titles like “Street Fighter II”, where characters moved gracefully, delivering a level of detail and realism previously unattainable in arcade games.Home ConsolesThe success of the 68000 in arcade machines led to its adoption in the home console market. Sega, for instance, utilized the 68000 CPU in the Sega Genesis (known as the Sega Mega Drive outside North America), which played a pivotal role in the console wars of the early 1990s. The Sega Genesis showcased the 68000’s capabilities, providing home gamers with arcade-quality experiences in their living rooms.Home ComputersAnother notable example is the Atari ST, a personal computer that was also powered by the 68000. Although not a dedicated gaming platform, the ST’s processing power and graphical capabilities attracted game developers and brought several popular games, like “Another World” and “The Secret of Monkey Island”, to the platform.Mac Classic II ROM: The Invalid 68030 InstructionDowntown Doug Brown investigates a critical bug in the Mac Classic II ROM where an out-of-bounds jump causes the execution of unintended code bytes (0C EC ...). These bytes form a technically invalid CAS instruction that the 68030 processor executes in an undocumented manner, miraculously fixing a corrupted register (A1) and preventing the system crash that occurs in emulators like MAME. The Invalid 68030 Instruction in Mac Classic II Doug Brown details how a jump table error in the Mac Classic II ROM leads to the execution of an undefined 68030 instruction, which accidentally corrects a register value and allows the machine to boot. Versatility and LongevityWhat set the Motorola 68000 apart was its versatility. The CPU was adaptable, making it suitable for a wide range of gaming platforms, from arcade machines to home consoles and personal computers. This versatility contributed to its long-lasting presence in the industry, as it continued to power games well into the 1990s and beyond.Even as more powerful CPUs emerged, the 68000 remained relevant. In fact, some game developers chose to stick with the 68000 for its ease of programming and proven performance. The 68k’s continued use in consoles like the Sega Saturn and the Neo Geo showcased its enduring legacy.Porting From AMIGA to MEGA DRIVE - with Stoo Cambridgeonaretrotip has an excellent interview with Stoo Cambridge about porting Amiga games like Megalomania and Sensible Soccer to the Sega Mega Drive. It covers the technical similarities (shared 68000 CPU) and differences (bitmap vs. tile-based graphics), as well as specific tricks used to overcome the Mega Drive’s color limitations, such as overlaying playfields to simulate 32-color intro screens.ConclusionThe Motorola 68000 played an indispensable role in the evolution of the video game industry. Its powerful architecture, smooth animation capabilities, and adaptability made it the go-to choice for game developers, both in arcades and home consoles. It helped define the gaming experiences of a generation and left a lasting impact on the industry.Today, as modern gaming consoles and PCs push the boundaries of technology, it’s essential to remember the humble 68000, the CPU that powered the games that started it all. Its legacy lives on in the hearts of gamers and the history of an industry that continues to innovate and thrive.", "excerpt": "The Motorola 68000 - Powering the Gaming Revolution Introduction The video game industry has witnessed remarkable technological advancements throughout its history, with one pivotal component that played a significant role in shaping the industry as we know it today: the Motorola 68000 microprocessor. This powerful and versatile CPU, initially released...", "tags": ["hardware","megadrive","atari","cpu"], "image": "/public/generated/placeholders/68k.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Why Reverse Engineer Retro games? - About RetroReversing.com", "url": "/why-reverse-retro-games", "content": "If you have arrived at this page you may have a few questions such as why does RetroReversing.com even exist?Well, let us try to answer this question, starting with the problem we are trying to solve.Problem: The difficulty curve of going from a player of a game to being able to reverse engineer, modify or decompile it is too damn high.This is especially true of console games, where without a knowledge of assembly and how the hardware actually works it can be very tricky to started without giving up in frustration.Why bother?But why learn how to reverse engineer an old game? Surely there are better uses of your time than that, right? right?!There are multiple answer to this question but we feel the most important is simple: It is fun.Other reasons include game preservation, knowledge and even just enjoying participating in a community of people with the same interests.Why not just play the game for fun instead?Play the game, multiple times, play all the DLC, enjoy it, have fun. Now what if that game could be improved, what feature would you add to it?Whole new levels, characters, stories and game mechanics?! Cool! I bet there would be tons of people who would love to play your modified version of the game.Thats too hard for me, I don’t even know X, Y, Z…Ignore what you don’t know, these will come gradually in time, don’t worry about learning anything before hand.Learn just what you need when you need it and apply it straight away. This way everything you learn will stick and you save yourself waiting time memorizing concepts you may never even need.But where would I even start?That really depends on what you want to accomplish, but start at smallest most basic step and make each subsequent step as small as possible.Let’s say you want to modify the Nintendo 64 game “Mario Kart 64” to give it 8 player online play support.Thats quite a goal but just take a few small steps and learn everything along the way, for example: Find out how Mario Kart takes controller input in 4 player mode. Find out how the emulator sends input to the running game. How does the key presses impact the memory of the game? Can you swap player 1 so that it controls player 3, or even a NPC? Can you send button presses over TCP so that it controls an emulator on a different system? How does the game display 4 different cameras on screen, could this be increased to 8? or decreased to 1…This is not the fastest way to learn everything about the low level N64 defaults but it is a fun way to learn about some low level N64 details that you never knew before.Even if you give up after the first few steps you will have learned more than you knew before and your next project is sure to get further!If that all still sounds out of reach then don’t worry the main aim of this site is to help everyone learn the basics so we can bring these possibilities within reach.Why learn Reverse Engineering?Reverse engineering has been an integral part of the game industry from the very start, whether it was game developers reverse engineering the console to rival companies reversing each other games, reversing was a vital skill.Retrogame ArcheologyRetrogame Archeology is a term coined by Associate Professor John Aycokc from the University of Calgary.He highlights the benefits of looking under the hood of old games in this excellent video:Site specificThis section aims to answer questions as to why the site is setup the way it is, what content should be included in the site and what is out of scope or better covered on other websites.Differences to other sitesThis site has a much more technical focus, focusing on knowledge and tutorials for stuff like modding, hacking and reverse engineering. Example how a game works, how the code works, how to modify the graphics or sound or other assets.How were the games made, what development kits, what 3D modelling tools, what 2D artist tools etc.This is a site for: Development kits (both software and hardware) Source Code analysis and walkthroughs How specific game mechanics were implemented How to extract and replace game assets (modding) How to change game behaviour Development history of a game and the tools the developers usedThis is not a site for: Game reviews (plenty of sites for that) Unused assets (use The Cutting Room Floor) Prototype and Beta content (use Forbidden Palace)Site Architecture AdvantagesWe are taking advantage of a few of Github’s features such as being able to edit in a web browser without checking out the code and live preview before submitting.The advantages are: Decentralised (anyone can fork and download a local copy of the entire website)Examples of content not to postUnused AssetsDo not post unused content, that is the domain of The Cutting Room Floor, a link should be made on each game page to link to this, and any content found should be posted to TCRF page.", "excerpt": "If you have arrived at this page you may have a few questions such as why does RetroReversing.com even exist? Well, let us try to answer this question, starting with the problem we are trying to solve. Problem: The difficulty curve of going from a player of a game to...", "tags": ["introduction"], "image": "/public/Articles/Why Reverse Engineer Games retroreversing.com.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Amiga Reverse Engineering", "url": "/Amiga", "content": "Welcome to our in-depth guide to Amiga reverse engineering! This page serves two roles. It groups all of our posts related to Amiga reverse engineering, and it aggregates high quality sources from the web into create a unified reference.The content starts high level, outlining the system, its history, and its official game development process, then moves into low level details with a focus on reverse engineering and homebrew development.Introduction to the AmigaNostalgia Nerd has an excellent two part series about the development and technical architecture of the Amiga computer. It covers the creation of the custom chipset (Agnes, Denise, Paula), the engineering challenges faced by Jay Miner’s team, and the hardware evolution from the Amiga 1000 to the 500:Amiga Engineers Panel: Amiga 40th Anniversary at VCF 2025The BIOSJERBIL YouTube channel documents a gathering of original Amiga engineers, including Dale Luck, at the Amiga 40th anniversary celebration held during the Vintage Computer Festival 2025.The engineers on the panel, listed in the order they were introduced or spoke: Dale Luck - Amiga Software Engineer Dale wrote a “Blitter emulator” in software to visualize and verify the hardware functions before the actual chips were available. He also added the physics and “bounce” to the famous Boing Ball demo (improving on Sam Dicker’s spinning ball). Don Reisinger - Director of Marketing (Sales & Marketing) Don joined Amiga from Tonka Toys (where he worked with Dave Morse). He was responsible for selling the Amiga concept to dealers and investors (“selling water in the desert”) and organizing the initial trade show exhibits, such as the 1984 CES booth. Ron Nicholson - Director of Hardware Development Ron worked on the system architecture and wire-wrapped the original prototype motherboards (building 2 or 3 of them). He mentioned being influenced by Apple’s Bill Atkinson to implement a hardware “blitter” for graphics performance. Glenn Keller - Hardware Engineer Glenn was responsible for the Porsche chip (which became Paula), handling the audio, disk controller, and UART. He shared a famous story about fixing a fatal flaw in the disk controller chip by physically cutting a microscopic wire on the silicon die with an “X-Acto” knife and a microscope. Sam Dicker - Software Engineer A former Williams Electronics employee (Defender, Sinistar), he worked on entertainment software and sound drivers. He created the original spinning ball demo (using color cycling to simulate rotation) and the sound effects for the Boing Ball demo (recorded by hitting a garage door with a foam bat). Mike Slifcak - Manager of Software QA Mike was responsible for testing hardware and software, including “torture testing” floppy drives (e.g., inserting disks upside down). He also wrote early graphics algorithms (like Bresenham line drawing) in C before the hardware Blitter was ready. R.J. Mical - Software Engineer (Intuition/User Interface) In the video, he focuses on the “folklore” of the Amiga team, recounting stories like the “mystery wire” on a wire-wrap board that seemed essential for the system to work despite not being connected to anything, and the team’s intense work ethic (sleeping in the office) leading up to CES. How many games were released for Amiga?According to MobyGames There are 3,930 video games for the Amiga 1 but the number would be much larger if Public Domain/shareware and other more indie titles are included.MobyGames - Amiga games listAll Commodore Amiga Games CompilationAll Games presents a massive seven-hour video compilation documenting the extensive library of the Commodore Amiga. This visual archive serves as a comprehensive reference for the platform’s software history, showcasing the graphical and auditory evolution across thousands of titles.The 150 Essential AMIGA GamesitsaPIXELthing has created a video compilation showcasing 150 essential titles for the Commodore Amiga. It covers a vast array of genres and gameplay styles, serving as a comprehensive visual reference for the platform’s graphical capabilities and software history.What does it mean to reverse engineer a game?Reverse engineering is a process that can help uncover the inner workings of these games and reveal how they were programmed, designed, and even uncover hidden easter eggs.For more information on the basics and benefits of reverse engineering games in general check out our introductory guide: Beginners Guide to Reverse Engineering (Retro Games) This guide is for all beginners who are interested in learning more about the technical details of their favourite consoles and games. The guide aims to be as console-agnostic as... Amiga MagazinesThe Rise and Fall of Amiga Format (1989-2000)The video from The Retro Collective documents the history of the influential UK magazine Amiga Format from its start in 1989 to its closure in 2000. It highlights how the magazine guided the Amiga community, transitioning users from gaming into deeper technical subjects. The content covered important retro-computing topics such as hardware upgrades (e.g., A590 hard disk), programming tutorials using AMOS and Blitz Basic, and creative applications like the OctaMED music tracker and 3D rendering with Vista. The video chronicles the platform’s peak popularity and the community’s attempts to keep the Amiga ecosystem alive after Commodore’s bankruptcy.Preserving Amiga History: A New Software ArchiveAmiga Love has a video about their new project to preserve and archive rare Amiga software, specifically focusing on disk magazines, user group discs, and obscure shareware. The video covers the technical challenges of digitizing these aging floppy disks and demonstrates a workflow using ChatGPT to OCR text and metadata, creating a searchable, browser-based library where users can explore file contents without needing to download ADF images.HardwareIn this section, we’ll explore the hardware that powers the Amiga. Understanding the hardware that drives the system is key to unlocking its potential and gaining a deeper appreciation for the games that were developed for it.The Amiga Development SystemBefore the Amiga 1000 was commercially released, Commodore provided special Amiga Development Systems (often in tower or rack-style enclosures) to game and software houses. These units typically used early revisions of the custom chips and were meant specifically for developers to start writing and testing Amiga software ahead of launch 2.Developmer Edition Amiga 1000Amiga Love showcases an ultra-rare “Developer Edition” Amiga 1000, one of less than 700 units sent to companies like Hewlett-Packard in 1985 before the computer’s retail launch. This specific unit features a glossy plastic case, a “Commodore” logo instead of the Amiga checkmark, and early custom chips (Daphne/Portia) on a motherboard layout that bridges the gap between the known “Velvet” prototype and the final retail version.The video details the physical and technical differences, such as the reversed power switch and lack of signatures inside the case, and demonstrates the machine booting up with a user-installed QuickStart ROM upgrade.What was the standard hardware was used to develop Amiga games?For most of the commercial life of the platform, a normal Amiga (commonly an A2000 or later A3000/A4000) plus the official Amiga Developer Kit (software, documentation, and example code) functioned as the primary dev kit.Developers often added hardware like hard drives, memory expansions, and sometimes accelerator cards to create a more capable development machine.Team17’s WORMS developer Amiga 4000Retro Recipes has an incredible video about discovering and exploring the original development Amiga 4000 used to create the classic game Worms. The video documents the process of recovering data from the aging hard drives, revealing original Lightwave 3D animation files, FMV assets, and even unreleased artwork, guided by the original developer, Chris Blythe.What consoles used the Amiga for game development?Some console dev kits actually used Amigas as the host hardware, such as the Atari Lynx (originally Epyx Handy) development setup that ran on an Amiga 2000 with attached debugging hardware 3. Many Sega Mega Drive games were also developed as ports of Amiga games due to the similar CPU.Retail Amiga HardwareThe Ultimate Amiga 500 Talk - Amiga Hardware Design And Programming8-Bit Relics presents a technical deep dive into the architecture of the Amiga 500, delivered by speaker Raara. The talk details the interplay between the Motorola 68000 CPU and the custom chips (Paula, Agnus, Denise), explaining the roles of the Copper and Blitter co-processors, DMA channels, and the unique memory map that defined the system’s capabilities.Core custom chips in the retail AmigaOn the classic Amiga machines (like the Amiga 1000, 500, and 2000), the core custom chips were named Agnus, Denise, and Paula, alongside the Motorola 68000 CPU.Agnus (Address GeNerator Unit) Custom ChipAgnus was the master DMA controller that arbitrates access to chip RAM and contains the blitter (block image transfer engine) and Copper (video-synced coprocessor)The Big Book of Amiga Hardware has an excellent write up about Agnus, it covers the chip’s role in managing DMA channels and Chip RAM addressing, as well as its integration of the Blitter and Copper co-processors. Agnus - Commodore The Big Book of Amiga Hardware provides technical specifications, pin-out details, and revision history for the Commodore Agnus chip, highlighting its functions in video generation and memory management. Bit Blit Algorithm (Agnes)Computerphile has an explainer video about the Bit Blit (Bit Block Transfer) algorithm, famously implemented in the Amiga’s Agnes chip. It covers the history of the algorithm from Xerox PARC, the technical details of manipulating bitmaps in memory using boolean logic (AND, OR, NOT), and why hardware implementations provided significant performance gains over software by handling bit-shifting and memory masking efficiently.Denise Video ChipDenise was the primary video chip handling bitplane graphics, sprites, playfields, and display modes.The Big Book of Amiga Hardware provides a detailed technical profile of the Denise custom chip (MOS 8362/8373). It outlines the chip’s critical role in Amiga graphics, including sprite management, bitplane operations, and color palette handling (supporting HAM-6 and Extra Half-Brite modes), while listing specific part numbers and revisions for compatibility with OCS and ECS systems. Denise - Commodore The Big Book of Amiga Hardware offers technical specifications, revision history, and compatibility details for the Denise chip, the component responsible for the Amiga's advanced video output and sprite capabilities. Paula (MOS 8364) - The Amiga Sound ChipThe Paula custom chip (MOS 8364) is a core component of the Amiga’s Original Chip Set (OCS), known for handling multiple crucial peripheral functions. Its primary role is providing the Amiga’s native audio, featuring 4-channel 8-bit sound in conjunction with Agnus DMA.Additionally, Paula functions as the floppy drive controller, manages the UART for the serial port, and provides the interface for mouse and joystick inputs. Different revisions (R4 and R7) were used across various Amiga models, including the A1000, A500+, A2000, A3000, A600, and A4000. Paula - Commodore The Big Book of Amiga Hardware details the Paula chip, the Amiga's multi-function I/O and audio controller, including its various part numbers and the Amiga models it was used in. Interview with Glenn Keller: Designer of the Amiga Paula ChipThe Guru Meditation has an interview with Glenn Keller, the engineer responsible for the Amiga’s custom Paula chip. The discussion covers the manual chip design process of the 1980s, the decision to integrate audio, floppy disk control, and UART I/O into a single chip, and Keller’s experience working under Jay Miner to create the Amiga’s distinct sound architecture.Third Party Amiga HardwareAmiga 2000 Action Replay ControllerRobSmithDev has an excellent video about reverse engineering the pinout for a rare Amiga 2000 Action Replay card to rebuild its missing controller. It covers tracing the PCB to identify the freeze and slow-motion logic, comparing the circuitry to the Amiga 500 model, and designing a custom 3D-printed housing for the replacement unit.Amiga Retro Joypad From 1994 Reverse EngineeringHappy Little Diodes has an excellent video about reverse engineering a vintage 1994 Amiga joypad. It covers disassembling the controller, analyzing the discrete transistor-based turbo fire circuit, simulating the oscillator, and modifying component values to optimize the auto-fire frequency for better gameplay compatibility.Amiga Software DevelopmentOfficial Game Software Development for AmigaIs there any official source code for Amiga?If you are interested to see officially released or leaked source code, for Amiga check out our other post: Retail Console Game Source code (C/C++) For the official source code check out this post. The Story of Another World on the Amiga: Technical Deep DiveModern Vintage Gamer provides a deep technical analysis of the 1991 cinematic platformer Another World on the Commodore Amiga. The video details how creator Eric Chahi achieved its unique 2D polygonal aesthetic by utilizing the Amiga’s Blitter co-processor for line drawing and area filling, rather than traditional sprites [00:06:45].It explores the clever optimization techniques, such as background caching with four frame buffers, which allowed the game to maintain a smooth frame rate despite drawing hundreds of polygons on a 7MHz processor [00:09:31]. The discussion also covers the game’s virtual machine architecture that facilitated easy porting [00:11:29].The Polygons of Another World: A Retrospective on 90s Graphics HardwareFabien Sanglard presents a comprehensive retrospective on the technical implementation of the 1991 game Another World (also known as Out of This World), focusing on how its vector-based graphics were rendered across various early 90s hardware platforms. The article series introduces the game’s core architecture as a simple virtual machine (VM) with only 29 opcodes, 256 variables, 64 threads, and four framebuffers. This approach enabled high portability and resource efficiency. It delves into platform-specific optimization tricks, such as the use of background buffers and special palette manipulations for translucency effects. The polygons of Another World - Fabien Sanglard Fabien Sanglard provides an in-depth reverse engineering analysis of the Another World game engine, detailing its bytecode virtual machine, framebuffer manipulation, and platform-specific graphics optimizations across systems like the Amiga, Atari ST, and IBM PC. Classic Game Postmortem - Another World (GDC 2011)This video is a GDC 2011 talk delivered by Eric Chahi, the original creator of the groundbreaking 1991 cinematic platformer Another World (known as Out of This World in North America). Chahi provides a deep retrospective on his development process, covering the game’s innovative vector-based graphics engine, its virtual machine architecture that allowed for easy porting, and the unique challenges of developing the narrative and animation entirely on his own. This talk serves as a historical and technical account of how he single-handedly created one of the most influential games of the early 90s.Porting From AMIGA to MEGA DRIVE - with Stoo Cambridgeonaretrotip has an excellent interview with Stoo Cambridge about porting Amiga games like Megalomania and Sensible Soccer to the Sega Mega Drive. It covers the technical similarities (shared 68000 CPU) and differences (bitmap vs. tile-based graphics), as well as specific tricks used to overcome the Mega Drive’s color limitations, such as overlaying playfields to simulate 32-color intro screens.Modern Game Development for the AmigaZippy Race Amiga PortBuilding Games for Old Retro 1985 Hardware - Zippy Race Amiga Port - YouTubeAmiga TechDutch Retro Guy’s “Amiga Tech” playlist offers a deep dive into advanced graphical programming on the Commodore Amiga, focusing on assembly language and custom hardware manipulation. The series details technical implementations of visual effects like free-form sprite layers and dual playfields, explaining how to leverage the Copper and Blitter chips to push the system’s limits. Amiga Tech Playlist Dutch Retro Guy explores high-level Amiga programming techniques, demonstrating how to create complex graphical effects using assembly and the system's custom chipset. Reverse Engineering Amiga gamesAre there any Amiga Reverse Engineered games or active projects?Before diving in its best to check if there are any existing reversing projects for the Amiga that you can contribute to, check out our other post specifically on this topic: Decompiled Retail Console Games For the list of decompiled games check out this post. Menace Amiga CodeDave Poo 2 has an excellent playlist about reverse engineering the Amiga game Menace. It covers the detailed analysis of the source code originally published in Amiga Format, walking through the 68000 assembly to understand game logic, fix bugs, and explore the engine’s design.File FormatsWhen reversing Amiga games you will come across a variety of file formats, this section will try to cover all of the most common formats you will encounter.Game Modding and ROM Hacking for Amiga gamesBy modifying the code, graphics, or sound of an Amiga game, you can create new levels, characters, or even entirely new games that build upon the classic gameplay and aesthetics of the original.Additionally, modding games can be a great way to learn more about the technical aspects of game development and programming.Amiga X-Copy: The Full Story!RobSmithDev has an excellent video about the history and reverse engineering of the iconic Amiga disk copier, X-Copy. It covers the technical evolution of the software, analyzes the “Cyclone” hardware dongles used to bypass copy protection by treating digital data as analog signals, and includes an interview with a former Cachet employee regarding the company’s legacy and modern software preservation.Essential Guide: The History of TrackersMusicTech provides a comprehensive history of music trackers, starting with Karsten Obarski’s Ultimate Soundtracker on the Amiga and evolving through the demoscene to PC tools like FastTracker II and Impulse Tracker. The article details the technical limitations that shaped the unique “tracker sound”-such as the vertical timeline and hexadecimal commands-and discusses their lasting legacy in modern production tools like Renoise. Essential Guide: History of Trackers MusicTech chronicles the rise of music trackers, from the Amiga's 4-channel MOD format to the sophisticated multi-channel tools of the DOS era and their influence on modern DAWs. All Posts References MobyGames - Amiga games list ↩ The Amiga Development System - YouTube ↩ Handy Devkit files - English Amiga Board ↩ ", "excerpt": "Welcome to our in-depth guide to Amiga reverse engineering! This page serves two roles. It groups all of our posts related to Amiga reverse engineering, and it aggregates high quality sources from the web into create a unified reference. The content starts high level, outlining the system, its history, and...", "tags": ["amiga"], "image": "/public/generated/placeholders/amiga.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Android", "url": "/Android", "content": "Reverse Engineering Android GamesJADX: Dex to Java DecompilerThe skylot project hosts JADX, the premier open-source tool for reverse engineering Android applications by converting Dalvik bytecode (DEX/APK) back into readable Java source code.It is available as a powerful command-line utility and a feature-rich graphical user interface (GUI) that supports syntax highlighting, cross-reference navigation, and full-text search. The decompiler includes an effective deobfuscator and is essential for deep static analysis of compiled Android binaries. skylot/jadx: Dex to Java decompiler skylot's JADX project provides robust command-line and GUI tools for decompiling Android DEX/APK files back into readable Java code, complete with an integrated deobfuscator. jadx-magic-strings PluginThe jadx-magic-strings project by 0rShemesh is a highly valuable JADX plugin designed to enhance the decompilation and analysis of Android DEX files.It operates automatically after decompilation to extract and analyze “magic strings,” which include method names, class references, and source file paths (like .java or .kt), from string constants found in the code. jadx-magic-strings: JADX plugin for extracting metadata from strings 0rShemesh's JADX plugin automatically extracts source file references, method name candidates, and other structural information from string constants in decompiled Android code, aiding reverse engineering. Android File FormatsAPK-Info: Full-Featured APK Parser (Rust/Python)The APK parser apk-info is designed for efficient forensic and security analysis, offering comprehensive extraction of crucial metadata from Android packages, including main activities, minimum SDK versions, and intricate details from the AXML (Binary XML) and ARSC (Resource) formats. Crucially, it fully supports parsing various APK Signature Block 42 schemes (v1, v2, v3, v3.1), making it a powerful read-only utility for large-scale Android reverse engineering and malware analysis. delvinru/apk-info: APK full-featured parser delvinru's apk-info is a full-featured, malware-friendly APK parser in Rust with Python bindings, capable of high-speed extraction of metadata and analysis of complex signature schemes. ", "excerpt": "Reverse Engineering Android Games JADX: Dex to Java Decompiler The skylot project hosts JADX, the premier open-source tool for reverse engineering Android applications by converting Dalvik bytecode (DEX/APK) back into readable Java source code. It is available as a powerful command-line utility and a feature-rich graphical user interface (GUI) that...", "tags": ["android"], "image": "/public/generated/placeholders/android.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Arcade - How retro arcade games were made", "url": "/arcade", "content": "What was the first Arcade Video Game?Computer Space released in 1971 by Nolan Bushnell and Ted Dabney is widely considered the first arcade game. While it wasn’t a massive commercial hit, it proved that money could be made from creating video games and the authors went on to found Atari to take the concept to the next level with Pong 1.It has a unique fiberglass design that aimed to appear futuristic and still makes it look unique to this day compared to the wooden arcade cabinates that followed it.Despite its name it is not actually a “computer” as microchips were too expensive in 1971 so it used TTL (Transistor-Transistor Logic) which meant that the “code” was actually the series of wires and switches that connected to each other. So to change the functinality or fix a bug it meant actually physically resoldering the connections.Development of Arcade GamesWhat programming languages were used to create Arcade games?Early arcade games didn’t use a programming language at all with all the game logic built at the hardware level. So to change the game it meant literally rewiring the hardware components and modding involved adding new hardware components which bypassed the original behavior.As for later arcade games that had a microprocessor the programming language used can depend on the power of the system, some less powerful boards used pure assembly to write the game code and others used a higher level language such as C.For example the 1990 game Klax was written in C according to Greg Omi who was sent the source code for his Atari Lynx port of the game 2.This is further confirmed in a 1990 interview with original designer of Klax Mark Stephen Pierce3: “All Atari coin‑ops today are written in C ‑ that’s the most popular language with the programmers here, I guess. The actual programming work is carried out on standard terminals, and then transferred into our VAX machines where it’s compiled and compressed. Finally it’s downloaded from there through an EPROM burner and onto the hardware for the game that the engineer has put together. Every coin‑op’s hardware is different partly because each game is different, and partly as a form of copy protection.What tools were used to create the art for Arcade games?In the 1990 interview with Mark Stephen Pierce the following was published (in “The One” magazine) 3: Mark’s graphics are produced on a PC ‑ but using Atari’s own specially written utility: RAD (Rendering and Animation Design). “It’s basically a standard paint tool with some animation facilities. I design and draw on the PC before uploading everything to the VAX to be compressed.”What did a Typical Arcade Game Development Team Look Like?In the early days of arcade gaming, development teams needed to be highly specialized. Unlike today’s streamlined development environments, both hardware and software had to be built from scratch for each new game. This required expertise across a wide range of disciplines, from custom chip design to game logic and audiovisual presentation.As arcade hardware evolved and became more standardized-often borrowing from or influencing console architectures-the hardware workload decreased slightly. However, the software and design demands increased, calling for larger, more diverse teams to handle game mechanics, visual design, sound, and player experience.A great example is Taito’s groundbreaking 1987 arcade title, Darius, which employed a team with clearly defined roles: Sound Designer – Yasuhiko Tanaka Composer – Hisayoshi “OGR” Ogura Cabinet Designer – Natsuki Hirosawa Game Designer – Junji Yarita Planner – Akira Fujita Programmer – Toru Sagawara Hardware Engineer – Takeki NakamuraFor a deeper look into the development of Darius, check out this excellent translated interview on shmuplations:Darius I & II – 1986/89 Developer Interviews – shmuplations.comHow long did it take to develop an Arcade game?In 1990 Atari developer Mark Stephen Pierce had the following to say about the length of time for developing an Arcade game: An Atari game takes, on average, around a year to produce ‑ but then an average can come from two extremes, which is certainly in Mark’s case - Escape took over two years to put together, whereas Klax was written in just four months!How were Arcade games tested?The challenge with Arcade games is they are expensive to produce and need to be visually appealing, easy to grasp, and have a carefully balanced difficulty level. Challenging enough to be engaging but not so hard that it drives players away or so easy that it allows endless play on a single coin.So prototype Arcade games were placed into various arcades and player behaviour was closely monitored to strike the right balance of difficulty and engagement. The Atari games even had a video recorder built in so that the development team could watch how players played the game, along with a computer that tracked the money made for the game 3.Arcade Development HardwareGame Development at TaitoTaito put together a 250-page Hardware Manual for new developers who joined the team to learn how to create an Arcade game from scratch using RAM/ROM/CPU chips and a standard TV. This was before the internet and even before there were many books on the topic when the industry was very new and companies didn’t want to share their “trade secrets”.With the Taito Hardware Manual for reference, new engineers were sent out to Akihabara to get some ROM and RAM chips and a CPU, solder them all together onto a test PCB, then write a brick breaker game.https://t.co/huXblA0rv4https://t.co/CXlnKUPHkH pic.twitter.com/Yip45KbLIE— Taito Corporation (@TaitoCorp) January 19, 2024They used an In-Circuit Emulator to debug the programs they were creating as can be seen in this diagram:Development of RoboTron (1981)At GDC 2014 Eugene Jarvis gives an excellent presentation about the development of Robotron:They used the Gimix 6809 as their development system:As for the software side, they had to write their own text editor and assembler, they didn’t comment or use tabs as every byte that was used in memory was precious:In Retro Gamer 28 there is an excellent article from Archer Maclean where he went to a presentation by Eugene Jarvis and this is what he had to say 4: He went on to describe that his code spilled over into multiple files on morethan one floppy, and yet there were no multi-floppy code-linkers so he devised the exact same bizarre jump vector solution I had devised to allow non-linked blocks of code to communicate.Then he described how he had to write ‘utilities’ to edit tiny bitmaps drawn on graph paper and entered as hex,and how to get around the one hour compile times by editing memory directly and disassembling in your head,and how to make interesting sounds from 30 bytes of data, and how to write ultra-tight optimised machine code to move small bitmaps around a screen fast, and off course, cram it all into a 32k ROM.Arcade Game Source CodeDefender (1981 by Williams Electronics)The source code for the classic arcade game from 1981 Defender has been released on Github:mwenge/defender: Defender(1981) by Eugene Jarvis and Sam DickerIt is written in a variant of the Assembly language specifically for the Motorola 6809 CPU 5.The physical board had 11 ROM chips on it that would need to be flashed with the assembled result of that source code 5.Defender was developed by Eugene Jarvis and Larry DeMar two programmers who utilized algorithms to great effect rather than relying on artists, one such example is the classic explosion particle effect. Defender became one of the highest grossing arcade games in history 6.The first issue of the Magazine Wireframe contains a python (pygame) code snippet to re-create the classic particle explosion from Defender 6. You can find that code on github too: https://github.com/Wireframe-Magazine/Wireframe-1/blob/master/explosion.pySpeed Up KitsSpeed-up kits, also known as enhancement kits, were aftermarket hardware modifications designed to alter the behavior of arcade games. These kits typically increased game speed, introduced new features, or adjusted difficulty levels. By modifying the original game code or hardware, speed-up kits aimed to rejuvenate player interest and extend the commercial lifespan of arcade cabinets.Purpose and Impact of Speed Up KitsThe primary motivations for implementing speed-up kits included: Increased Revenue: Faster gameplay reduced session times, allowing more players per hour and increasing coin drop rates. Extended Cabinet Life: By refreshing game mechanics, operators could delay purchasing new machines. Enhanced Player Engagement: New challenges and features kept experienced players interested.For example, the original Asteroids game allowed skilled players to play indefinitely on a single credit. A speed-up kit made the game more challenging, thereby reducing playtime per credit and increasing revenue .Notable ExamplesSome of the most famous examples of speed up kits are: Super Missile Attack: Developed by General Computer Corporation (GCC), this kit modified Atari’s Missile Command, adding new enemies and increasing difficulty. Its success led to legal action from Atari, which was eventually settled when Atari hired GCC to develop games . Ms Pac Man: Another GCC project, this kit transformed Namco’s Pac-Man into Crazy Otto, introducing new mazes and improved AI. Midway licensed and released it as an official sequel called Ms Pac Man 7.How were Speed Up Kits implemented?Speed-up kits were typically implemented through reverse engineering the original game and modifying it using: Daughterboards: Additional circuit boards that modified signals or data paths. ROM Replacements: Swapping out original ROM chips with modified versions containing new code. Clock Modifications: Altering the system clock to increase CPU speed, thus speeding up gameplay .Legal and Ethical ConsiderationsWhile speed-up kits offered benefits to arcade operators, they raised legal and ethical questions: Intellectual Property: Modifying and distributing altered versions of games without permission infringed on the original developers’ rights. Quality Control: Unauthorized modifications could lead to inconsistent gameplay experiences and potential hardware issues.The legal dispute between Atari and GCC over Super Missile Attack highlighted these concerns. The settlement resulted in GCC ceasing unauthorized modifications and instead developing licensed content resulting in Ms Pac Man 7.Legacy of Speed Up KitsSpeed-up kits played a significant role in the arcade industry’s evolution: Innovation Catalyst: They demonstrated the demand for game enhancements, influencing official sequels and updates. Technical Advancement: The reverse engineering skills developed during kit creation contributed to advancements in game development and hardware understanding. Preservation Challenges: Today, original speed-up kits are valuable to collectors and historians but pose challenges for preservation due to their unofficial nature.MAME: The Multiple Arcade Machine EmulatorMAME (Multiple Arcade Machine Emulator) is a free and open-source project that emulates the hardware of arcade systems, allowing classic games to run on modern platforms. Its primary goal is to preserve decades of software history by accurately documenting and replicating the behavior of original arcade hardware.History of MAMEMAME version 0.1 was released on February 5, 1997, by Italian programmer Nicola Salmoria. This first version was a command-line application for MS-DOS and supported five games:   Pac-Man Pengo Phoenix Pleiads FroggerTo run a game, you would use the DOS prompt like so:mame pacmanAll of the first games used a Z80 CPU, the first non-z80 game was Centipede which was released in version 0.10\ton the 13th March 1997 8.For a full release history of MAME check out: MAME Release Dates - Retro Arcade Guides1997 July - MAME32 first releaseThe first release of MAME32 occurred on July 18, 1997, with version 0.26.1 8. This marked the debut of a Windows-based version of MAME, featuring a graphical user interface (GUI) that simplified the process of loading and managing arcade ROMs.Developed by Chris Kirmse, MAME32 made arcade emulation more accessible to a broader audience by eliminating the need for command-line operations required in the original MS-DOS version of MAME.2014 - The Internet ArcadeThe Internet Arcade was first launched in early November 2014, it enables users to play classic arcade games directly in their web browser by leveraging JSMESS, a JavaScript port of the MAME emulator 9.JSMESS was created by cross-compiling the original C/C++ codebase into JavaScript using Emscripten, a toolchain that translates C/C++ code into asm.js or WebAssembly for high-performance execution in browsers.The original source code for JSMESS, is still available on JSMESS original Github. But please note that it has now been integrated into the main MAME repository, so this repository is now archived and no longer actively maintained, but the source remains accessible for historical and reference purposes.For an up-to-date build of JSMESS you can follow the Emscripten part of the guide here: Compiling MAME - MAME Documentation 0.278 documentation2015 - MAME merges with MESSIn 2015, MAME merged with MESS (Multi Emulator Super System), expanding its scope to include home consoles, computers, and calculators.2016 - CppCon The MAME story: From C to Modern C++At CppCon 2016 Miodrag Milanović gave a fantastic talk about how MAME moved from C to modern C++, which helped with better compatibility, portability, and overall better code, you can watch it on youtube below:MAME in the PressMAME was first mentioned in issue 45 of EDGE magazine back in May 1997, only a few months after the first release, ever since then it has been mentioned in hundreds of magazines, books and newspapers.It wasn’t just western media either, as far back as June 2000 MAME was being advertised in Japanese magazines (Arcadia Issue 1):MAME was again featured in EDGE magazine in October 2002, where it was described as “by far the greatest and most important piece of video gaming code ever written”10.Unreleased Arcade GamesRare’s Razz BoardThe RAZZ is a 1988-era custom arcade board from Rare that used a unique Hitachi Z80-based “DMA hijacking” technique to enable high-speed sprite rendering and an extensive color palette, serving as the technical foundation for unreleased projects like the flight simulator ‘Fokker’ and the ‘Playboy’ handheld prototype.Fokker (Unreleased Arcade Game)Rare Gamer provides a technical overview of Fokker, a cancelled 1988 arcade flight simulator that was intended to be Rare’s first coin-op release. The link details the game’s development on the proprietary “Razz” arcade board, which enabled 3D bi-plane dogfighting and bombing runs through early hardware-accelerated rendering techniques. Lead programmer Simon Hallam managed a five-month development cycle before the project was cancelled, leaving behind a functional prototype that serves as a significant milestone in Rare’s early technical history. Fokker - Rare Gamer Rare Gamer explores the history and technical implementation of Fokker, a cancelled 1988 arcade flight simulator that utilized Rare's custom Razz board. References Before Pong, There Was Computer Space - The MIT Press Reader ↩ Retro Gamer Issue 97 page 57 ↩ Inside Atari Games (“The One” Magazine 1990) and on http://www.atari-explorer.com/articles/articles-atari-games.html ↩ ↩2 ↩3 Retro Gamer Issue 28 ↩ mwenge/defender: Defender(1981) by Eugene Jarvis and Sam Dicker ↩ ↩2 Wireframe Issue 01 page 33 ↩ ↩2 Upgrade kits, lawsuits and Lite-Brite: How Ms. Pac-Man was made ↩ ↩2 MAME Release Dates - Retro Arcade Guides ↩ ↩2 The Internet Arcade – Internet Archive Help Center ↩ MAME Over ↩ ", "excerpt": "What was the first Arcade Video Game? Computer Space released in 1971 by Nolan Bushnell and Ted Dabney is widely considered the first arcade game. While it wasn’t a massive commercial hit, it proved that money could be made from creating video games and the authors went on to found...", "tags": ["arcade","introduction","hardware"], "image": "/public/generated/placeholders/arcade.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Atari 2600 VCS Reverse Engineering", "url": "/atari2600", "content": "IntroductionWelcome to our page dedicated to Atari 2600 reverse engineering! The Atari 2600 is a classic video game console that was first released in 1977 and has since become an iconic symbol of the golden age of gaming.If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to the right place. On this page, we’ve compiled a list of links to other pages that cover various topics related to Atari 2600 reverse engineering.Whether you’re interested in understanding the hardware architecture of the console, analyzing game code, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to. So grab your joystick, fire up your Atari 2600, and get ready to dive into the exciting world of Atari 2600 reverse engineering!HardwareIf you’re interested in reverse engineering Atari 2600 software, it’s crucial to have a solid understanding of the hardware that powers this classic gaming console. By understanding the inner workings of the Atari 2600 hardware, you can better comprehend how the software interacts with the hardware and how you can potentially modify or improve it.In this section of our guide, we will provide you with detailed information and resources on the hardware of the Atari 2600, including its CPU, RAM, ROM, and other components that make up the console. We’ll explore how each component works together to create the classic gaming experience that the Atari 2600 is known for, as well as provide links to other pages that go into greater detail about each component.Development KitJOLT The first games for the Atari 2600 were developed on the JOLT which was a low-cost 6502 computer, in fact the original prototype for the Atari 2600 was based on a Jolt computer with hand wired modification and joysticks from the arcade version of the TANK arcade game 1. For more information about the JOLT check out this page:Jolt – Retro Computing US Gold Atari 7800 Development kitIn the UK magazine Zero issue 7 there is an interview with the game developer US Gold where it mentions they are working on Atari 7800 games such as Gauntlet and it gives a brief description of the Development Kit they are using: The 7800 development kit comprises the following: a Mega ST running Atari’s proprietary combination 6502/68000 assembler, lead from ST to 7800 RAM cartridge and downloading software 2.Sluggo ROM emulator development kitVCF Southwest features a talk by legendary programmer Rebecca Heineman, who details how she reverse-engineered the Atari 2600 using an Apple II in the late 1970s. She explains the technical process of creating the “Sluggo” ROM emulator development kits, disassembling cartridges like Combat to map the system’s registers, and her subsequent work at companies like Avalon Hill and Interplay.Reverse Engineering Atari 2600 GamesAre there any Atari Reverse Engineered games or active projects?Before diving in its best to check if there are any existing reversing projects for the Atari 2600 that you can contribute to, check out our other post specifically on this topic: Decompiled Retail Console Games For the list of disassembled games check out this post. Haunted House Disassemblybrandonrobertz provides a commented disassembly of the classic Atari 2600 game Haunted House, often cited as one of the first survival horror titles. The repository includes the reverse-engineered 6502 assembly source code compatible with the DASM assembler, allowing developers to analyze the game’s logic or rebuild the ROM from scratch. Haunted House Disassembly This repository hosts a work-in-progress commented disassembly of the Atari 2600 game Haunted House, including a Makefile for building the ROM with **DASM**. References Jolt – Retro Computing ↩ Zero - Issue 07 - Stay A While… - Articles - SMS Power ↩ ", "excerpt": "Introduction Welcome to our page dedicated to Atari 2600 reverse engineering! The Atari 2600 is a classic video game console that was first released in 1977 and has since become an iconic symbol of the golden age of gaming. If you’re interested in learning more about the technical aspects of...", "tags": ["atari"], "image": "/public/generated/placeholders/atari2600.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Atari Jaguar Reverse Engineering", "url": "/jaguar", "content": "IntroductionWelcome to our page dedicated to Atari Jaguar reverse engineering! The Atari Jaguar is a classic video game console that was first released in North America during November 1993.If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to the right place. On this page, we’ve compiled a list of links to other pages that cover various topics related to Atari Jaguar reverse engineering.Whether you’re interested in understanding the hardware architecture of the console, analyzing game code, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to. So grab your controller, fire up your Atari Jaguar, and get ready to dive into the exciting world of Atari Jaguar reverse engineering!Development KitHardware used for Alien vs predatorIn an interview for Wireframe magazine1 Jane Whittaker talks about all the hardware sent over to her parents house in Yorkshire which gives us an insight into the hardware required to make Atari Jaguar games.They (Jane and Mike Beaton) moved from Atari’s San Fransisco office back to the UK due to home sickness and Atari supported this by sending development hardware all the way to the UK to set up a make shift office in Jane’s parents house.They got sent Atari TT machines and monitors, prototype Atari Jaguars, a couple of PCs and presumably all the cables to fit everything together 1.This was how they developed Alien vs Predator for the Atari Jaguar.Official Atari Jaguar Development ManualThe official “Atari Jaguar Development Manual” is available over on archive.org with thanks to Lars Hannig (Starcat Developments) for obtaining, scanning and organising the hundreds of pages.It comes with: M68000 8-/16-/32-Bit Microprocessors User’s Manual Ninth Edition written by MOTOROLA in 1993 ALN Linker - 11 pages of linker documentation from 5th June 1995 Appendix A - Frequently AskedQuestions About Jaguar Appendix B - Programming Guidelines Appendix D - Jaguar Development Standards Appendir E - Jaguar Software Experience Approved Manufacturer Production Guidelines Appendix F - Additional Documentation - just mentioned DB the Atari debugger. The Jaguar CD-ROM - 40 pages Cinepak For Jaguar - 37 pages DB: The Atari Debugger - 84 pages Getting Started - 8 pages Hardware Bugs & Warnings - 6 pages Libraries - 65 pages Madmac Macro Assembler - 39 pages QSound For Jaguar - 8 pages Jaguar Sample Programs - 13 pages Software Reference Manual - Tom & Jerry - 103 Pages from 7th June 1995 Software Reference Manual - Tom & Jerry Revision 8 - 141 Pages from 28th February 2001 Overview of Jaguar Hardware & Architecture - 15 pagea Technical Reference - 31 pages Tools - 21 pages Atari Jaguar Voice Modem - 22 pages Jaguar Workshop Series - 22 pagesFile FormatsThe table below lists common Atari Jaguar file formats encountered when developing software for the platform: Extension Description .3DS A 3D Object file for Autodesk 3D-Studio. Use the 3DS2JAG toolt o convert into sourcecode compatible with the Jaguar 3-D Graphics library. .ABS DRI/Alcon format absolute location executable program file. Output from ALN Linker. .ASC ASCII version of Jaguar Synth sound patch. This is a MADMAC sourcecode file that is typically included by one of the source code files used with the Jaguar Synth and Music driver. .AVI Microsoft Video For Windows filmfile. .BIN Binary data. This could be a binary image of program code, data, a picture, or whatever. The LTXCONV utility used with the GASM assembler creates .BIN files containing the combined TEXT &DATA sections of the assembledfile(s). .BPG BPEG Compressed image file. BPEG is the current flavor of JPEG used with the Jaguar. .С sourcecodefile .CCR Chunky-format 16-bit CRY Cinepak film .СМР Compressed sound sample, created from a raw 16-bit (stereo or mono) sound sample file using the SNDCMP utility. .COF Common Object File absolute location executable program file. Output from ALN Linker .CRG Chunky-format 16-bit RGB Cinepak film .CRY Madmac source code file for a CRY-format graphics image, typically converted from Targa format using the TGA2CRY utility. .DAS DSP assembly lanquage source. This extension is used for files that contain source exclusively for the DSP, to be assembled by either MADMAC or GASM. .DB Debugger script file .DTA Binary image of program DATA segment. Created by FILEFIX utility .ENV Envelope definition file. Used by the Jaguar Synth & Music driver .GAS GPU assembly language source. This extension is used for files that contain source exclusively for the GPU, to be assembled by either MADMAC or GASM. .INC Madmac/GASM include file. Typically used to contain equartes and macro definitions. .J3D 3D object data in MADMAC assembler source format. Output from the 3DS2JAG utility. Must be compiled by MADMAC. .JAG Jaguar JPEG compressed graphics image. Created by the JAGPEG utilities. Note that JAGPEG has been replaced by the BPEG package. Also, the 3DS2JAG utility that converts Autodesk 3D Studio into source code format for the Jaguar 3D libraries once also used the .JAG extension (it has since beenchanged to use .J3D). .LTX GASM assembler output file. The GASM assembler does not output files that are compatible with the ALN linker, so LTX files must be converted using the LTXCONV utility. .LZJ LZSS Compressed data file. This is a binary file containing raw LZsS-compressed data. It ix created by the LZJAG utility. This is linked into your program, and then decompressed using the DELZJAG routines. .MID MIDI score file. This is a MIDI file output by a MIDI sequencer. You feed these files to the PARSE utility to create a musicscore usable by the Jaguar Synth & Music driver .O 68000/mixed object module. Object file created after assembling a .S file with MADMAC. Some of the conversion utilities create MADMAC source code files that don’t always end in filename extensions of .S, and they may also use the O. filename extension after being assembled. .OJ DSP (JERRY) object module. Object file created after assembling a.DAS file with MADMAC (Note that GASM does not create standard object modules) .OD Some older projects have used an extension of .OD for DSP object code. However, the .OJ extension is preferred. .OT GPU (TOM) object code. Object file created after assembling a .GAS file with MADMAC (Note that GASM does not create standard object modules.) .OG Some older projects have used an extension of .OG for GPU object code. However, the .OG extension is preferred. .OUT Parsed MIDI file, output by the PARSE and MERGE utilities.This is really a MADMAC source code file which is normally assembled into an object file using a .SCR extension .PTC Jaguar Sound Tool Patch File. These are the binary patch files used by the Jaguar Sound Tool and the Jaguar Synth. .ROM Alpine Board / ROM Image File. Created by FILEFIX utility, or saved from Alpine board using the debugger. .S 68000/mixed assembly language source. This extension is used for files that contain source either exclusively for the 68000 or mixed source for any combination of 68000, GPU, and/or DSP. .SCR Compiled MIDI score file. This is an object file, the same as .O files, except with a different extension to highlight the idea that they contain MUSIC score information. Files with an .SCR extension are to .MID files as .S files are to .O files. This file extension is also used for some Cinepak Movie Files (Smooth CRY-format) .SRG Smooth format 16-bit RGB Cinepak film .SYM Symbol Table File. Created by FILEFIX utility. This is the same basic format as an executable program file, except with empty TEXT and DATA sections. Only the symbol table has information in it. .TGA Targa picture file. The Targa format is a popular format for 16-bit and 24-bit RGB true color graphics images. Can be converted into Jaguar CRY-format using the TGA2CRY utility. .TX/.TXT Binary image of a program’s TEXT segment. Created by the FILEFIX utility. The current version of FILEFIX produces files with a “TX” extension. However, older versions created files with the .”TXT” extension. Because the TXT extension is also used for ASCII text files, this was changed to avoid conflicts. .WAV Waveform definition. Used by the Jaguar Synth & Music driver. References Wireframe issue 2 Page 26 ↩ ↩2 ", "excerpt": "Introduction Welcome to our page dedicated to Atari Jaguar reverse engineering! The Atari Jaguar is a classic video game console that was first released in North America during November 1993. If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to...", "tags": ["atari","jaguar"], "image": "/public/generated/placeholders/jaguar.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "ATI Low Level Wii SDK", "url": "/ati-low-level-wii-sdk", "content": "IntroductionIn 2020 and 2021 numerous secret files have been leaked from Nintendo thanks to Zammis Clark. Included in these files were source code for a variety of Wii internal applications such as a Diagnostic tool known as DIAG4.This post will cover the Low Level Wii SDK created by ATI/ArtX for the Wii/Gamecube which was included as part of the DIAG4 source code.What is the ATI Low Level Wii SDK?In order to develop the Wii Operating System (IOS) and other internal diagnostic tools (e.g DIAG4) an SDK was created to abstract the low level hardware in a C/C++ library.Where did it come from?In the 2021 Nintendo Leak an archive was released called DIAG4RVL.7Z, if you extract this archive and go to the path DIAG/includeIn here you will find a folder for each version artx and ati.What was it used for?It was used internally at Nintendo to make it easier to write hardware diagnostic tests for use in the DIAG4 tool. It was presumably also used for development of the Wii Operating System known as IOS.What is the difference between the ArtX and ATI versions?The ArtX version is the original and was created for the Gamecube and used in the Diagnostics tool for Gamecube and potentially the Gamecube Operating System.The ATI version is a fork of the ArtX version which has been updated for the Wii console.Artx (/include/artx) /include/artx This folder contains Gamecube header files provided by the Company ArtX, the company later changed its name to ATI during the development of the wii. This folder is provided for use in the Gamecube DIAG tests and there is an updated version of this folder with Wii support in the ati folder. Since most of the files in this folder have a more up to date version in the ati folder, they will not be documented here as it would be very repetitive. So check out the section on the ATI folder below instead. For more information you can take a diff of the two folders if you are especially interested in the differences but overall it is not of much interest to most users. ATI low level SDK (/include/ati) /include/ati This folder contains the C header files that provide low level access to the wii hardware. This library was originally written for the gamecube and then updated for the Wii, it was created by ATI (formally ArtX). This library was not provided to third party developers in the official SDK and so was only used for internal tools and software such as the Wii Operating system known as IOS. Most of the include files are at the top level but there are also a few sub-directories: bfm750 - only contains one file but nothing is defined in it diag - Low level PowerPC register access functions export - unknown purpose, seems to be just a subset of gx folder files fdl - low level C header files generated from fiddle .fdl files gx - Graphics header files gxu - Graphics Utility header files helper - Compiler related constants private - Internal debug functions for ATI We have provided descriptions for the files at the root level of this folder in the table below: File Name Extension Description acr .h Include file for declaring ? aes .h Include file for declaring ? aesreg .h Include file for declaring a few AES pre-processor constants such as AES_BASE_REG it was written by BroadOn ahb .h Include file for declaring a few functions for accessing the AHB (Advanced High-performance Bus) bus ahbdbg .h Include file for declaring a debug AHB function called ahbdbgInit ai .h Include file for declaring a function to initialise the Audio Interface aiInit ar_priv .h Include file for declaring ARAM pre-processor constants aram .h Include file for declaring ARAM related functions such as __ARReadDMA arch .h Include file for declaring constants related to the hardware architecture it is running on ORCA/NDEV/DRIP such as BUSSPEED_DEFAULT args .h Include file for declaring ? assert .h Include file for declaring a simple assert function for debugging ati_usb .h Include file for declaring low level USB interface functions atidiag .h Include file for including lots of other header files for hardware components such as ai.h ax_types .h Include file for declaring common standard types for ArtX code such as AXint8 ax_ver .h Include file for declaring constants for the different hardware versions e.g DOLPHIN_REV_A axdbg .h Include file for declaring a few debug functions axmc .h Include file for declaring ? big_endian .h Include file for declaring macros that convert to big endian format boot .h Include file for declaring two strings BOOT_BLK and AUTOBOOT_BLK busclient .h Include file for declaring ? casm .inc   crc .h Include file for declaring ? dbg_viai_setup .h Include file for declaring ? dbgcomm .h Include file for declaring dbgint .h Include file for declaring dcbz_basic .h Include file for declaring di .h Include file for declaring diag .h Include file for declaring diagerr .h Include file for declaring dma_basic .h Include file for declaring dolcnt .h Include file for declaring dsp .h Include file for declaring dspfix .h Include file for declaring dspmxic .h Include file for declaring dvd .h Include file for declaring dvdfs .h Include file for declaring ehci .h Include file for declaring ehci-hcd .h Include file for declaring ela .h Include file for declaring exi .h Include file for declaring eximdm .h Include file for declaring fifo .h Include file for declaring filerand .h Include file for declaring filerandom .h Include file for declaring flash .h Include file for declaring font .h Include file for declaring gecko_dma .h Include file for declaring generic .h Include file for declaring getopt .h Include file for declaring gfxbu .h Include file for declaring gfxoldbu .h Include file for declaring gpioexi .h Include file for declaring hcd .h Include file for declaring hidutil .h Include file for declaring hub .h Include file for declaring i2c .h Include file for declaring irq .h Include file for declaring lib .h Include file for declaring little_endian .h Include file for declaring lomem .h Include file for declaring mc .h Include file for declaring mem .h Include file for declaring ml .h Include file for declaring mrexi .h Include file for declaring n64cnt .h Include file for declaring ntd_regs .h Include file for declaring nvram .h Include file for declaring os .h Include file for declaring reset .h Include file for declaring sdi .h Include file for declaring serrx .h Include file for declaring sfx .h Include file for declaring sha .h Include file for declaring si .h Include file for declaring snake .h Include file for declaring standio .h Include file for declaring swab .h Include file for declaring types .h Include file for declaring usb .h Include file for declaring usb-ohci .h Include file for declaring usb_bitops .h Include file for declaring usb_input .h Include file for declaring usb_list .h Include file for declaring usb_mem .h Include file for declaring usb_other .h Include file for declaring usb_scsi .h Include file for declaring usb_spin .h Include file for declaring usb_timer .h Include file for declaring usb_wait .h Include file for declaring util .h Include file for declaring vi .h Include file for declaring vi_conexant .h Include file for declaring video .h Include file for declaring Interestingly the file arch.h mentions a platform called DRIP along with NDEV and ORCA. NDEV is the Wii development kit hardware and ORCA is the Gamecube one but not sure what DRIP is.The file boot.h refers to two BLK files used at boot time, but not sure what they are used for: boot.blk autoboot.blkThe file generic.h is actually from the Linux Kernel (linux/byteorder_generic.h), so technically if this is linked into any distributed Wii software it could be a GPL violation.Code Files acr.h void set_AIP_address_space(int whether) int get_AIP_address_space(void) int use_AIP_address_space(void) void set_AHB_IO_MEM(int value) int get_AHB_IO_MEM(void) int use_AHB_IO_MEM(void) void set_DI_NODVDRD_EN(int value) int get_DI_NODVDRD_EN(void) u32 get_ACRIOINTPPC(void) u32 set_ACRIOINTPPC(u32 which,u32 value) u32 sendIOPMsg(u32 msg) void set_ACRARBCFGDMA_DELAYEN(int value) int get_ACRARBCFGDMA_DELAYEN(void) void set_ACRARBCFGDMA_DELAYCNT(u32 value) u32 get_ACRARBCFGDMA_DELAYCNT(void) void set_ACRARBCFGCPU_DELAY(int value) 16 0 31 aes.h int AES_Busy(void) void AES_Dma(u32 srcAddr,u32 dstAddr,u32 numBlocks,u32 intrEnable) void AES_Clear(void) int _AES_Setup(u32 srcAddr,u32 dstAddr) int _AES_StartDma(u32 numBlocks,u32 intrEnable) 5 0 16 ahb.h void ahbMemFlush(enum memAhbFlushGroup_e) void ahbMemRBInvalidate(enum memAhbReadBuffer_e) unsigned int busRdAHMReg(unsigned int a) unsigned int busRdMEMReg(unsigned int a) int arbInit(char *s) 5 0 51 ahbdbg.h int ahbdbgInit(void(*_Cb)(void),int mask) 1 0 15 ai.h AiStatus aiInit(void(*_tranCb)(void)) 1 0 35 aram.h void __ARWaitForDMA(void) void __ARWriteDMA(u32 mmem_addr,u32 aram_addr,u32 length) void __ARReadDMA(u32 mmem_addr,u32 aram_addr,u32 length) u32 __ARChecksize(void) 4 0 28 arch.h u32 BUSSPEED void calibrateBusspeed(void) 1 1 70 args.h u32 _argc char _argv[] u32 argInit(void) u32 argCntGet(void) char argGet(u32 i) u32 argCache(u32 *,char ***) 4 2 52 assert.h void _assert(const char *,const char *,int) 1 0 35 axdbg.h void DbgCreateTX(GXMCObj *info,u32 width,u32 height) void DbgRenderAndStretch(GXMCObj *info,u32 x,u32 y,u32 width,u32 height) void DbgRenderRefToEFB(GXMCObj *info,GXMCReferencePicture type,u32 x,u32 y,u32 plane) void DbgStub(GXMCObj *info) void DbgPrintMotionInfo(struct MacroblockDetails *mb) void DbgPrintDPCM(struct MacroblockDetails *mb) void DbgPrintMotionVector(GXMCMotionVector *mv) SigTrap SigTrap 7 2 107 axmc.h void SetView(void) MCError AllocateCmdFifos(GXMCObj *mpgObj) MCError AllocatePingPongBuffers(GXMCObj *mpgObj) MCError AllocateRefrenceFrameBuffers(GXMCObj *mpgObj) MCError AllocateTexMemory(GXMCObj *info) GXBool AllocateFutureBuffers(GXMCObj *mpgObj) GXBool AllocatePastBuffers(GXMCObj *mpgObj) MCError AllocateBPictureBuffers(GXMCObj *mpgObj) void InitQueueHandler(GXMCObj *mpgObj) void MCErrorHandler(GXMCObj *mpgObj,MCError error) GXBool GXMCSelectDBuffer(GXMCObj *info,u32 bufferId) void CreateD0Texture(GXMCObj *mpgObj,u32 bufferId,u32 width,u32 height) void CreateD1Texture(GXMCObj *mpgObj,u32 bufferId,u32 width,u32 height) void PerformRenderSetup(TevType type) void SetupTevStages(TevType type) void RenderImage(GXMCObj *mpgInfo,u32 width,u32 height) void CopyEFBToMemory(GXMCObj *mpgObj,GXCopyType copyType,void *destBase) void CreateFrameFromFields(GXMCObj *mpgInfo,PictureType frameType) void GXReset(GXMCObj *mpgObj) void MarkBufferBusy(GXMCObj *info,u32 id) void ProcessBlocks(GXMCObj *info) void CreateQueue(GXMCMotionVector *srcMV,GXMCMotionVector *dstMV[],GXMCMacroBlockType mbType,u32 count,u32 totalMV) void SwapBuffers(GXMCObj *mcInfo) void InterlaceRenderUV(GXMCObj *mcInfo,PictureType fType,void *dstBase) u32 GXConvertLinearToTile(unsigned x,unsigned y,unsigned stride) void DestroyPingPongBuffers(GXMCObj *mpgObj) void ResetCounters(GXMCObj *mpgObj) void FreeAndReallocate(GXMCObj *mpgObj,GXBool newBuffer) 28 0 78 busclient.h void busPrintf(const char *fmt,...) void busDbg(const char *fmt,...) u32 busGetTime(void) 3 0 51 crc.h u32 CRCCompute(void *buf,u32 nbytes) u32 CRCAppend(void *buf,u32 nbytes,u32 init) u32 CRCComputeMasked(void *buf,u32 nbytes) 3 0 41 dbg_viai_setup.h void dbg_viai_setup(int compatB) void dbg_aipll_init(int compatB) 2 0 6 dbgcomm.h DbgHandle dbgOpen(const char *filename,const char *mode) u32 dbgWrite(DbgHandle handle,const void *buf,u32 len) u32 dbgRead(DbgHandle handle,void *buf,u32 len) u32 dbgClose(DbgHandle handle) u8 dbgGets(u8 *buf,u32 blockFlag) 5 0 48 dbgint.h u32 dbgintInit(void(*dbgIrqCb)(void)) 1 0 34 dcbz_basic.h void lc_allocate(void *LC_addr,unsigned int bfsize) void set_HID_G(unsigned int mask) 2 0 9 di.h DiStatus diInit(void(*_tranCb)(u32 err),void(*_doorCb)(void)) DiStatus diImm(u32 *pkt,u32 *data,u32 isRead) DiStatus diDma(u32 *pkt,u32 *data,u32 len,u32 isRead) DiStatus diSync(void) DiStatus diBrk(void) void diReset(void) void _diSync(u32 iSr) diRegisters_t diReadRegisters(diRegisters_t *diRegs) void diPrintRegisters(diRegisters_t *diRegs,const char *comment) void diClobberRegisters(u32 value) u32 diStraps(void) 11 0 117 diag.h u32 mcrGet(Mcr *mp) u32 mcrPut(Mcr *mp) u32 dcrGet(Dcr *dp) u32 dcrPut(Dcr *dp) u32 _dcrmcrGet(DcrMcr *dmp) u32 _dcrmcrPut(DcrMcr *dmp) void diagStart(void) void diagStop(u32 status) 8 0 105 dma_basic.h void dma_load(unsigned int *inDataBlock,unsigned int *inBuffer,unsigned int inDataSize) void dma_wait(unsigned int i) void dma_store(unsigned int *outDataBlock,unsigned int *outBuffer,unsigned int outDataSize) 3 0 11 dolcnt.h u32 dolcntData(u32 chan,u32 *datah,u32 *datal) u32 dolcntInit(void) u32 dolcntInitV(int) void dolcntRumbleOn(u32 chan) void dolcntRumbleOff(u32 chan) 5 0 117 dsp.h u32 dspAi(u32 *memPtr,u32 len) u32 dspAram(u32 *memPtr,u32 *aramPtr,u32 isRead,u32 len) void dspSyncAi(void) void dspSyncAram(void) u32 dspWrtMbox(u32 value,u32 doIrq) u32 dspRdMbox(u32 *value) void dspInit(void(*_dspCb)(void),void(*_aiCb)(void),void(*_aramCb)(void)) void dspAramStable(void) 8 0 45 dspfix.h void dspFix(void) 1 0 2 dspmxic.h u32 dspReset(u32 cdcr) u32 dspBoot(u32 *memPtr,u32 len) u32 dspBootDma(u32 *memPtr,u32 dspa,u32 dscr,u32 dsbl) u32 dspSyncDma(u32 delay) u32 dspSendMail(u32 mail,u32 doIrq) u32 dspWaitMail(u32 *mailPtr) u32 dspMemRamp(u32 *memAddr,u32 len,u32 val) 7 0 93 dvd.h u32 dvdStopMotor(u32 setting,u32 *response) u32 dvdRead(u32 addr,u32 len,u32 *mem) void dvdSetNdevFS(u32 offset) u32 dvdReadBuf(u32 addr,u32 len,u32 *dest) u32 dvdReadDVD(u32 startSector,u32 numberOfSectors,u32 *mem) u32 dvdWriteBuf(u32 addr,u32 len,u32 *src) u32 dvdSync(void) u32 dvdErrSet(u32 len) u32 dvdBrk(void) u32 dvdInit(void(*tranCb)(u32 err),void(*doorCb)(void)) u32 dvdErrReq(u32 *retErr) u32 dvdAsStart(u32 addr,u32 sz) u32 dvdAsStop(void) u32 dvdDoor(u32 open) u32 dvdInquiry(u32 *inq) u32 dvdReadID(u32 *id) u32 dvdAsBuffer(u32 onOff,u32 pages,u32 *status) u32 dvdRequestDiskStatus(u32 *diskStatus) u32 dvdRequestError(u32 *response) void dvdPrintPacket(dvd_u *pkt) void _dvdFlush(u32 enable) u16 deviceCode u32 releaseDate u32 padding[2] dvdInquiry_t void dvdPrintInquiry(const char *comment,dvdInquiry_t *s) 22 4 121 dvdfs.h u32 dvdFsInit(void) u32 dvdFsDeToInd(DirEntry *de) DirEntry dvdFsFind(const char *path) DirEntry dvdFsIndToDe(u32 ind) void fileLoad(const char *file,u32 *rLen) char lineGet(char *buf,u32 bLen) 6 0 51 ehci-hcd.h int ehci_start(struct usb_hcd *hcd) 1 0 12 ela.h void init_ELA(p_ela_init_reg) void post_ELA(int wrap_cnt) void log_ELA(int) 3 0 94 exi.h ExiStatus exiInit(void(*extDetachCb)(u32 chan),void(*extIrqCb)(u32 chan),void(*tranCb)(u32 chan)) ExiStatus exiCustomInit(void(*extDetachCb)(u32 chan),void(*extIrqCb)(u32 chan),void(*tranCb)(u32 chan)) ExiStatus exiSelect(u32 chan,u32 dev,u32 freq) ExiStatus exiDeselect(u32 chan) ExiStatus exiDma(u32 chan,u8 *buf,u32 len,u32 type) ExiStatus exiImm(u32 chan,u8 *buf,u32 len,u32 type) ExiStatus exiSync(u32 chan) u32 exiPresent(u32 chan) void exi32Enable(void) void exi32Disable(void) void exiPrint(char *buf,int len) u32 exiGetID(u32 chan,u32 dev) 12 0 85 eximdm.h u32 mdmInit(u32 mdmDev,u32 mdmCsel) u32 mdmRegRd(u32 reg,u8 *buf,u32 len) u32 mdmRegWrt(u32 reg,u8 *buf,u32 len) 3 0 40 fifo.h void fifoCreate(const char *name,Fifo *fp,u32 *list,u32 size) u32 fifoGetExt(Fifo *fp,u32 *valp,u32 flags) u32 fifoGet(Fifo *fp) u32 fifoPutExt(Fifo *fp,u32 val,u32 flags) void fifoPut(Fifo *fp,u32 val) u32 fifoCnt(Fifo *fp) void EnableWriteCombine() 7 0 61 filerand.h void sfilerand(unsigned long seed) unsigned short filerand() 2 0 11 filerandom.h void sfilerandom(unsigned long seed) unsigned long filerandom() 2 0 11 flash.h u32 flashReadSeg(u32 chan,u32 src,u32 dst,u32 len) u32 flashRead(u32 chan,u32 src,u32 dst,u32 len) u32 flashWritePage(u32 chan,u32 src,u32 dst,u32 len) u32 flashWrite(u32 chan,u32 src,u32 dst,u32 len) u32 flashStatGet(u32 chan,u32 *ret) u32 flashStatClr(u32 chan) u32 flashErase(u32 chan) u32 flashEraseSec(u32 chan,u32 addr) u32 flashSleep(u32 chan) u32 flashWake(u32 chan) u32 flashIdRd(u32 chan,u32 *ret) 11 0 53 font.h void fontInit(u32 addr,u32 vidMode) void cls(void) void fgSet(u32 y,u32 u,u32 v) void bgSet(u32 y,u32 u,u32 v) void cursorSet(u32 x,u32 y) void pixSet(u32 x,u32 y) void pixClear(u32 x,u32 y) void putChar(u32 cc) void putStr(const char *str) void fontPut(const char *str,u32 len) u32 fontColsGet(void) u32 fontRowsGet(void) void fontOff(void) void fontOn(void) void fontCursSet(u32 x,u32 y) void gfxBltCpy(u32 *src,u32 cols,u32 rows,u32 x,u32 y) void gfxRectDraw(u32 x,u32 y,u32 cols,u32 rows) u8 gfxChkppmfmt(u8 *ppm,u32 *cols,u32 *rows) u8 gfxChkbmpfmt(u8 *cp,u32 *xsize,u32 *ysize,u8 **pStart,u8 **pEnd) u8 gfxCvrtbmp2rgb(u8 *pEnd,u8 *pStart,u32 width,u32 height) void gfxCvrtrgb2yuv(u8 *data,u32 cols,u32 rows) void gfxCvrt444to422(u8 *src,u32 cols,u32 rows,u8 *dest) void gfxCvrt444to422Stride(u8 *src,u32 cols,u32 rows,u8 *dest,u32 stride) u32 scrColsGet(void) u32 scrRowsGet(void) void xLMarginSet(u32 xLMargin) 26 0 60 gecko_dma.h asm DMAStatus dmaEnable() asm DMAStatus dmaDisable() asm DMAStatus dmaErrorStatus() asm DMAStatus dmaQueueLen() asm DMAStatus dmaFlush() asm DMAStatus dmaAlloc(register unsigned long,register unsigned long) asm DMAStatus dmaRead(register unsigned long,register unsigned long,register unsigned long) asm DMAStatus dmaWrite(register unsigned long,register unsigned long,register unsigned long) 8 0 84 getopt.h char optarg int optind int getopt(int ac,char *av[],char *opts) 1 2 36 gfxbu.h void gfxbuInit() u32 gfxbuFinish() 2 0 42 gfxoldbu.h void gfxoldbuInit(char *testName) void gfxoldbuDisplay u32 gfxoldbuUpdate() u32 gfxoldbuFinish() u32 gfxoldbuFinishAA() void gfxSetClearColor(u8 red,u8 green,u8 blue,u8 alpha) 5 1 84 gpioexi.h void initGpioExi(void) void setVideoReset(int value) void setI2CEnable(int value) 3 0 10 hcd.h struct usb_hcd __attribute__((aligned(32))) struct hcd_dev __attribute__((aligned(32))) struct hcd_timeout __attribute__((aligned(32))) struct hc_driver __attribute__((aligned(32))) int usb_hcd_pci_probe(int *dev,int *id) void usb_hcd_pci_remove(struct pci_dev *dev) int usb_hcd_pci_suspend(struct pci_dev *dev,u32 state) int usb_hcd_pci_resume(struct pci_dev *dev) void usb_claim_bandwidth(struct usb_device *dev,struct urb *urb,int bustime,int isoc) void usb_release_bandwidth(struct usb_device *dev,struct urb *urb,int isoc) int usb_check_bandwidth(struct usb_device *dev,struct urb *urb) long usb_calc_bus_time(int speed,int is_input,int isoc,int bytecount) inline struct usb_bus hcd_to_bus(struct usb_hcd *hcd){return hcd->bus 13 0 298 hidutil.h void sethid2(unsigned int hid2_value) unsigned int gethid0(void) void sethid0(unsigned int) 3 0 11 hub.h struct usb_driver hub_probe(struct usb_device *dev,unsigned int i,const struct usb_device_id *id) 1 0 152 i2c.h int sendI2CData(u8 slaveAddr,u8 *pData,int nBytes) int rcvI2CData(u8 slaveAddr,u8 *pData,int maxBytes) int getI2CError() void initI2C() void initI2CExi(void) void setSCL(int) void setSDA(int) int getSCL(void) int getSDA(void) 9 0 51 irq.h void irqHandler(void) void irqCbAddPI(void(*irqCb)(),u32 mask) void irqACRHandler(void) void irqCbAddACR(void(*irqCb)(),u32 mask) u32 irqDisable(void) void irqEnable(u32 oldMask) void irqInit(void(*intCb)(void)) void clkInit(void(*intCb)(void),u32 decVal) void _clkHndlr(void) void _irqHndlr(void) 10 0 90 lib.h u16 bRd16(u32 src) u32 bRd32(u32 src) void busWrt16(u32 address,u16 data) void busWrt32(u32 address,u32 data) u16 busRd16(u32 address) u32 busRd32(u32 address) void bWrt16(u32 address,u32 data) void bWrt32(u32 address,u32 data) void _dcWb(u32 addr,u32 off) void _dcWbInv(u32 addr,u32 off) void _dcInv(u32 addr,u32 off) void dcWb(u32 addr,u32 len) void dcWbInv(u32 addr,u32 len) void dcInv(u32 addr,u32 len) u32 rand32(void) double drand48(void) double erand48(unsigned short xsubi[3]) long int mrand48(void) int lrand48(void) int nrand48(unsigned short xsubi[3]) int jrand48(unsigned short xsubi[3]) void srand48(int seedval) unsigned short seed48(unsigned short seed16v[3]) void lcong48(unsigned short param[7]) void tbRead(u32 *) void tbWrite(u32 *) void udelay(u32 delay) void busDelay(u32 count) u32 timeGet(void) void halt(void) void ppcL2Enable(void) void ppcL1Enable(void) void ppcL1Disable(void) void ppcL1Flush(void) void ppcPSLSQEnable(void) void ppcDARSet(u32 val) u32 ppcDARGet(void) void ppcHID0Set(u32 val) u32 ppcHID0Get(void) u32 ppcHID1Get(void) void ppcHID2Set(u32 val) u32 ppcHID2Get(void) void ppcHID4Set(u32 val) u32 ppcHID4Get(void) u32 ppcECID0Get(void) u32 ppcECID1Get(void) u32 ppcECID2Get(void) void ppcL2CRSet(u32 val) u32 ppcL2CRGet(void) void ppcWPARSet(u32 val) u32 ppcWPARGet(void) void ppcDecSet(u32 val) void ppcMsrSet(u32 val) u32 ppcMsrGet(void) void ppcTBUSet(u32 val) u32 ppcTBUGet(void) void ppcTBLSet(u32 val) u32 ppcTBLGet(void) u32 ppcPVRGet(void) u32 ppcSPRG0Get(void) u32 ppcSPRG1Get(void) u32 ppcSPRG2Get(void) u32 ppcSPRG3Get(void) u32 ppcSPRG0Set(u32 val) u32 ppcSPRG1Set(u32 val) u32 ppcSPRG2Set(u32 val) u32 ppcSPRG3Set(u32 val) u32 ppcDBAT0UGet(void) u32 ppcDBAT0LGet(void) u32 ppcDBAT1UGet(void) u32 ppcDBAT1LGet(void) u32 ppcDBAT2UGet(void) u32 ppcDBAT2LGet(void) u32 ppcDBAT3UGet(void) u32 ppcDBAT3LGet(void) u32 ppcDBAT4UGet(void) u32 ppcDBAT4LGet(void) u32 ppcDBAT5UGet(void) u32 ppcDBAT5LGet(void) u32 ppcDBAT6UGet(void) u32 ppcDBAT6LGet(void) u32 ppcDBAT7UGet(void) u32 ppcDBAT7LGet(void) u32 ppcIBAT0UGet(void) u32 ppcIBAT0LGet(void) u32 ppcIBAT1UGet(void) u32 ppcIBAT1LGet(void) u32 ppcIBAT2UGet(void) u32 ppcIBAT2LGet(void) u32 ppcIBAT3UGet(void) u32 ppcIBAT3LGet(void) u32 ppcIBAT4UGet(void) u32 ppcIBAT4LGet(void) u32 ppcIBAT5UGet(void) u32 ppcIBAT5LGet(void) u32 ppcIBAT6UGet(void) u32 ppcIBAT6LGet(void) u32 ppcIBAT7UGet(void) u32 ppcIBAT7LGet(void) void ppcDBAT0USet(u32 val) void ppcDBAT0LSet(u32 val) void ppcDBAT1USet(u32 val) void ppcDBAT1LSet(u32 val) void ppcDBAT2USet(u32 val) void ppcDBAT2LSet(u32 val) void ppcDBAT3USet(u32 val) void ppcDBAT3LSet(u32 val) void ppcDBAT4USet(u32 val) void ppcDBAT4LSet(u32 val) void ppcDBAT5USet(u32 val) void ppcDBAT5LSet(u32 val) void ppcDBAT6USet(u32 val) void ppcDBAT6LSet(u32 val) void ppcDBAT7USet(u32 val) void ppcDBAT7LSet(u32 val) void ppcIBAT0USet(u32 val) void ppcIBAT0LSet(u32 val) void ppcIBAT1USet(u32 val) void ppcIBAT1LSet(u32 val) void ppcIBAT2USet(u32 val) void ppcIBAT2LSet(u32 val) void ppcIBAT3USet(u32 val) void ppcIBAT3LSet(u32 val) void ppcIBAT4USet(u32 val) void ppcIBAT4LSet(u32 val) void ppcIBAT5USet(u32 val) void ppcIBAT5LSet(u32 val) void ppcIBAT6USet(u32 val) void ppcIBAT6LSet(u32 val) void ppcIBAT7USet(u32 val) void ppcIBAT7LSet(u32 val) void setIrqHndlr(void(*hndlr)()) void ppcEARSet(u32 val) u32 ppcEARGet() void __ecowx(u32 addr,u32 val) u32 __eciwx(u32 addr) void __dcbi(u32 *,u32) void __icbi(u32 *,u32) u32 __lwarx(u32) void __stwcx(u32,u32) void _ctxSw(void *newCtx) void _irqCtxSw(void *newCtx) void ppcSync(void) void ppcEieio(void) void ppcEeieo(void) u32 ppcStackPtrGet() void ppcStackPtrSet(u32 val) void rwbuzz(void) int strcasecmp(const char *s1,const char *s2) int strncasecmp(const char *s1,const char *s2,u32 c) void memcpy32(void *s1,const void *s2,u32 n) void memset32(void *s,u32 c,u32 n) int memcmp32(const void *s1,const void *s2,u32 n) int atoh(const char *str) s32 ntoi(const char *str,u32 base,u32 *val) void serInit2(u32 dev,u32 csel) void serInit(void) void serOn(void) void serOff(void) int serHwFlow(u32 enable) u8 serVersion(u32 dev,u32 csel) int serRdQLen(void) int serRdUart(u8 *,int) u8 serRdgetkey(void) u32 serRdkbhit(void) void diagManualStop(void *fb) void dprintf(const char *fmt,...) void dsprintf(char *str,const char *fmt,...) void printfv(u32 verLev,const char *fmt,...) void printf0(const char *fmt,...) void printf1(const char *fmt,...) u32 tolower(u32 cc) int atiIsNdev(void) int atiIsOrca(void) void initBootMode(void) u32 getBootMode(void) 176 0 309 mc.h void GXMCGFXInit() GXBool GXMCInit(GXMCObj *mcObj,u32 width,u32 height,u32 bufferCount) void GXMCBeginPicture(GXMCObj *mcObj,PictureType pType) void GXMCRenderMB(GXMCObj *mcObj,GXMCMacroBlockType mbType,GXMCMotionVector mv[4][2]) void GXMCEndPicture(GXMCObj *mcObj,GXCopyType copyType,void *dest) void GXMCSetChromaSample(GXMCObj *mcObj,GXMCSampleMode mode) void GXMCFinish(GXMCObj *mcObj) GXBool GXMCBufferBusy(GXMCObj *mcObj,u32 bufferId) GXBool GXSelectDBuffer(GXMCObj *mcObj,u32 bufferId) u8 GXMCGetD0YAddress(GXMCObj *mcObj,u32 bufferId) u8 GXMCGetD1YAddress(GXMCObj *mcObj,u32 bufferId) u8 GXMCGetD0UAddress(GXMCObj *mcObj,u32 bufferId) u8 GXMCGetD1UAddress(GXMCObj *mcObj,u32 bufferId) u8 GXMCGetD0VAddress(GXMCObj *mcObj,u32 bufferId) u8 GXMCGetD1VAddress(GXMCObj *mcObj,u32 bufferId) 15 0 313 mem.h const heap_t MEM_NAPA_HEAP const heap_t MEM_DDR_HEAP void memInit(u32 totMem) void memAlloc(u32 len) void memFree(void *addr,u32 len) void memSetHeap(heap_t) heap_t memGetHeap(void) void memAllocHeap(u32 len,heap_t heap) u32 memGetSize(void) void memRefreshInit(u32 *freq_array) void memRefreshHandler(void) void memRefreshHelper(u32,u32) void memRefreshThread() void memRefreshThreadInit(u32 *freq_array,u32 priority) u32 readDirectMemReg(u32) u32 readDDRMemReg(u32) u32 readSeqMemReg(u32) u32 readBistMemReg(u32) u32 readPerfMemReg(u32) void writeDirectMemReg(u32,u32) void writeDDRMemReg(u32,u32) void writeSeqMemReg(u32,u32) void writeBistMemReg(u32,u32) void writePerfMemReg(u32,u32) 22 2 72 ml.h void mlStart(char *FileName,u32 memSize,u32 memStart) void mlAlloc(u32 nbytes,MLMemType type,MLByteGrouping grouping) void mlAllocForce(u32 addr,u32 nbytes,MLMemType type,MLByteGrouping grouping) u32 mlGetAddr(void *ptr) void mlGetCPtr(u32 addr) void mlFlush() void mlFree(void *ptr) void mlReverseBytes(void *ptr,u32 bytes) void mlSetCustomByteSwappingFunction(MLByteGrouping grouping,MLByteSwappingFunction function,u32 stride) 9 0 101 mrexi.h int mrExiSerInit(void) void mrExiPrint(char *buf,int len) int mrExiProbe(void) 3 0 63 n64cnt.h u32 joyStatus(u32 chan,u32 *stData) u32 joyReset(u32 chan,u32 *stData) u32 joyData(u32 chan,u32 *data) u16 joyAddrCrc(u16 address) u32 joyEERead(u32 chan,u16 addr,u8 *data) u32 joyEEWrite(u32 chan,u16 addr,u8 *data) void joyDelay(u32 delay) 7 0 85 ntd_regs.h u16 __DSPRegs u32 __AIRegs void init_ntd_regs(void) 1 2 36 nvram.h u32 nvRamWrite(u32 addr,u8 *buf,u32 len) u32 nvRamRead(u32 addr,u8 *buf,u32 len) 2 0 41 os.h u32 lbolt u32 tmIrqTot Thread _tIdle void osInit(void) u32 threadCreate(Thread *tp,const char *name,void *stack,u32 stackLen,void(*entry)(void *data),void *data,u32 pri) void threadSetFPEnable(Thread *tp,u32 val) void threadDestroy(Thread *tp) void threadStart(Thread *tp) void threadStop(Thread *tp) void threadYield(void) void threadSuspend(Thread *tp) void threadResume(Thread *tp) void threadPriSet(Thread *tp,u32 pri) u32 threadPriGet(Thread *tp) Thread threadCurGet(void) void threadDelay(u32 ticks) void semaInit(Sema *sp,s32 cnt) void semaP(Sema *sp) void semaV(Sema *sp) u32 semaTest(Sema *sp) void condVarInit(CondVar *cp,const char *name) void condVarWait(CondVar *cp,Sema *sp) void condVarSignal(CondVar *cp) void panic(Context *,u32) 21 3 113 reset.h void resetSys(void) 1 0 32 sdi.h void sdi_init_intr(void(*irqCb)(void)) void sdi_init(void(*irqCb)(void)) sdi_slot_t sdi_handle(u32 ctrl,u32 slot) void sdi_set_debug(u32 debug) u32 sdi_rd_reg(sdi_slot_t sp,u32 offset) void sdi_wr_reg(sdi_slot_t sp,u32 offset,u32 val) void sdi_wr_reg16(sdi_slot_t sp,u32 offset,u32 val) u32 sdi_verif_reg(sdi_slot_t sp,u32 offset,u32 expected) void sdi_reg_intr(sdi_slot_t sp,u32 intr,void(*irq)(sdi_slot_t,void *),void *closure) void sdi_intr(void) u32 sdi_get_istat(sdi_slot_t sp) void sdi_clear_istat(sdi_slot_t sp,u32 ibits) u32 sdi_wait_istat(sdi_slot_t sp,u32 ibits,u32 bail_on_abort) void sdi_wr_host_ctrl(sdi_slot_t sp,u32 in_data) void sdi_int_regs_en(sdi_slot_t sp) void sdi_wr_nor_int_sts_en(sdi_slot_t sp,u32 en) void sdi_wr_err_int_sts_en(sdi_slot_t sp,u32 en) void sdi_err_int_recover(sdi_slot_t sp) u32 sdi_cmd(sdi_slot_t sp,u32 sysaddr,u32 blkszcnt,u32 arg,u32 tmdcmd) u32 sdi_io_cmd(sdi_slot_t sp,u32 sysaddr,u32 blkszcnt,u32 arg,u32 tmdcmd,u32 blk_size,u32 blk_cnt,u32 dma,u32 wr) void sdi_read_io_coherency(sdi_slot_t sp) void sdi_write_io_coherency(sdi_slot_t sp) u32 sdi_resp_type_cal(sdi_slot_t sp,u32 cmd_index,u32 resp_with_busy) u32 sdi_mem_cmd(sdi_slot_t sp,u32 cmd_index,u32 arg,u32 resp_with_busy) u32 sdi_mem_cmd_data(sdi_slot_t sp,u32 sysaddr,u32 cmd_index,u32 blk_size,u32 blk_cnt,u32 data_addr,u32 dma,u32 wr,u32 auto_cmd12,u32 resp_with_busy) u32 sdi_cmd0(sdi_slot_t sp) u32 sdi_cmd2(sdi_slot_t sp) u32 sdi_cmd3(sdi_slot_t sp) u32 sdi_cmd7(sdi_slot_t sp,u32 rca) u32 sdi_cmd9(sdi_slot_t sp) u32 sdi_cmd12(sdi_slot_t sp) u32 sdi_cmd13(sdi_slot_t sp) u32 sdi_cmd16(sdi_slot_t sp,u32 dflt_blk_size) u32 sdi_cmd17(sdi_slot_t sp,u32 data_addr,u32 dma,u32 resp_with_busy) u32 sdi_cmd18(sdi_slot_t sp,u32 blk_cnt,u32 data_addr,u32 dma,u32 auto_cmd12,u32 resp_with_busy) u32 sdi_cmd23(sdi_slot_t sp,u32 blk_cnt) u32 sdi_cmd24(sdi_slot_t sp,u32 data_addr,u32 dma,u32 resp_with_busy) u32 sdi_cmd25(sdi_slot_t sp,u32 blk_cnt,u32 data_addr,u32 dma,u32 auto_cmd12,u32 resp_with_busy) u32 sdi_cmd32(sdi_slot_t sp,u32 start_blk_addr) u32 sdi_cmd33(sdi_slot_t sp,u32 end_blk_addr) u32 sdi_cmd38(sdi_slot_t sp,u32 resp_with_busy) u32 sdi_cmd52(sdi_slot_t sp,u32 reg_addr,u32 sd_wr_data,u32 fn_no,u32 raw,u32 wr,u32 resp_with_busy) u32 sdi_cmd53(sdi_slot_t sp,u32 byte_blk_cnt,u32 wr,u32 fn_no,u32 blk_mode,u32 opcode,u32 reg_addr,u32 dma,u32 infinite,u32 resp_with_busy) u32 sdi_cmd55(sdi_slot_t sp) u32 sdi_acmd6(sdi_slot_t sp,u32 buswidth) u32 sdi_dma_done(sdi_slot_t sp) u32 sdi_abort(sdi_slot_t sp) u32 sdi_suspend(sdi_slot_t sp) u32 sdi_resume(sdi_slot_t sp) void sdi_set_async_mode(sdi_slot_t sp,u32 mode) void sdi_wr_clk_ctrl(sdi_slot_t sp,u32 clk_ctrl) void sdi_wr_blk_gap_ctrl(sdi_slot_t sp,u32 bgap_ctrl) void sdi_wr_timeout_reg(sdi_slot_t sp,u32 timeout_cnt) void sdi_set_bus_width(sdi_slot_t sp,u32 buswidth) void sdi_rd_sd_hc_capabilities(sdi_slot_t sp) void sdi_clock_supply(sdi_slot_t sp,u32 div) void sdi_clock_stop(sdi_slot_t sp) void sdi_clock_change(sdi_slot_t sp,u32 div) void sdi_bus_power(sdi_slot_t sp) u32 sdi_validate_ocr(sdi_slot_t sp,u32 ocr_data,u32 mem,u32 mmc) u32 sdi_card_insertion(sdi_slot_t sp) u32 sdi_io_card_init(sdi_slot_t sp) u32 sdi_mem_card_init(sdi_slot_t sp) void sdi_mmc_card_init(sdi_slot_t sp) u32 sdiSwapBytes4(u32 value) u32 checkErrorInt(sdi_slot_t sp) u32 sdiCardDetect(sdi_slot_t sp) u32 sdiFindCard(sdi_slot_t sp) u32 waitTransferComplete(sdi_slot_t sp) void sdiGoIdle(sdi_slot_t sp) void sdiIoReset(sdi_slot_t sp) void sdiSoftReset(sdi_slot_t sp) u32 sendCmd(sdi_slot_t sp,u32 arg,u32 tmdcmd) u32 sdiSendStatus(sdi_slot_t sp) u32 sdiSendOpCondition(sdi_slot_t sp) u32 sdiAllSendCid(sdi_slot_t sp) u32 sdiSendRca(sdi_slot_t sp) u32 sdiSendCsd(sdi_slot_t sp) u32 sdiSelectCard(sdi_slot_t sp) u32 sdiSetBlockLength(sdi_slot_t sp,u32 blksiz) u32 sdiSetBusWidth(sdi_slot_t sp,u32 buswidth) u32 sdiAsyncAbort(sdi_slot_t sp) u32 sdiSyncAbort(sdi_slot_t sp) void updateDmaPointer(sdi_slot_t sp) u32 sdiReadSingleBlock(sdi_slot_t sp,u32 arg,u32 *rdbuf,u32 dma) u32 sdiWriteSingleBlock(sdi_slot_t sp,u32 arg,u32 *wrbuf,u32 dma) u32 sdiReadBlock(sdi_slot_t sp,u32 arg,u32 blkcnt,u32 dma,u32 auto_cmd12,u32 infinite) u32 sdiWriteBlock(sdi_slot_t sp,u32 arg,u32 blkcnt,u32 dma,u32 auto_cmd12,u32 infinite) u32 sdiReadMultipleBlock(sdi_slot_t sp,u32 arg,u32 blkcnt,u32 auto_cmd12,u32 dma) u32 sdiWriteMultipleBlock(sdi_slot_t sp,u32 arg,u32 blkcnt,u32 auto_cmd12,u32 dma) u32 sdiReadInfiniteBlock(sdi_slot_t sp,u32 arg,u32 blkcnt) u32 sdiWriteInfiniteBlock(sdi_slot_t sp,u32 arg,u32 blkcnt) u32 sdioByteRead(sdi_slot_t sp,u32 fn_no,u32 reg_addr,u32 resp_with_busy) u32 sdioByteWrite(sdi_slot_t sp,u32 fn_no,u32 reg_addr,u32 wr_data,u32 raw,u32 resp_with_busy) u32 sdioExtRead(sdi_slot_t sp,u32 byte_blk_cnt,u32 fn_no,u32 blk_mode,u32 opcode,u32 reg_addr,u32 dma,u32 infinite,u32 resp_with_busy) u32 sdioExtWrite(sdi_slot_t sp,u32 byte_blk_cnt,u32 fn_no,u32 blk_mode,u32 opcode,u32 reg_addr,u32 dma,u32 infinite,u32 resp_with_busy) 96 0 263 serrx.h int serRxInit(u32 hwFlowEnable) u8 serRxgetkey(void) u32 serRxkbhit(void) int serRxInitParam(u32 chan,u32 cs,u32 hwFlowEnable) 4 0 35 sfx.h void sfxPlay(u32 sound) void sfxInit(void) 2 0 37 sha.h int SHA_Busy(void) void SHA_Calc(u32 Addr,u32 numBlocks,u32 intrEnable) void SHA_Result(u32 *result) int SHA_Match(u32 *a,u32 *b) void SHA_Clear(void) 5 0 14 si.h u32 siInit(void(*comCb)(u32 sisr),void(*pollCb)(u32 sisr)) void siChanOutSet(u32 *chanData) u32 siChansRead(u32 *chanData) void siPollRegSet(u32 x,u32 y,u32 enMask,u32 vbCpyMask) void siPollRegGet(u32 *x,u32 *y,u32 *enMask,u32 *vbCpyMask) u32 siComm(u32 chanNo,u32 *out,u32 oLen,u32 iLen) u32 siSync(void) void siPollWait(u32 chanMask) void siComDataGet(u32 *in,u32 cnt) 9 0 57 snake.h void Line(int x,int y,int x2,int y2,unsigned char c,unsigned char u,unsigned char v) void Circle(int xc,int yc,int r,unsigned char c,unsigned char u,unsigned char v) u32 GameOver(PLAYER *snake) void ExplodeSnake(int player_num,PLAYER *snake) void PrintScore(PLAYER *snake) void Delay(u32 delay_value) 6 0 117 standio.h int ioInit(void) int open(const char *path,int oflag) int close(int fd) ssize_t read(int fd,void *buf,size_t nbytes) off_t lseek(int fd,off_t offset,int whence) off_t tell(int fd) FILE fopen(const char *filename,const char *mode) int fclose(FILE *fp) size_t fread(void *ptr,size_t size,size_t nitems,FILE *fp) int fgetc(FILE *stream) int getc(FILE *stream) 11 0 59 swab.h __inline__ __const__ u16 __fswab16(u16 x){return __arch__swab16(x) __inline__ u16 __swab16p(u16 *x){return __arch__swab16p(x) __inline__ void __swab16s(u16 *addr){__arch__swab16s(addr) __inline__ __const__ u32 __fswab32(u32 x){return __arch__swab32(x) __inline__ u32 __swab32p(u32 *x){return __arch__swab32p(x) __inline__ void __swab32s(u32 *addr){__arch__swab32s(addr) u32 h u32 l return(((u64)__swab32(l)) return __arch__swab64(x) __inline__ u64 __swab64p(u64 *x){return __arch__swab64p(x) __inline__ void __swab64s(u64 *addr){__arch__swab64s(addr) 10 2 159 usb.h void usbInit() void writeDescriptor(u32 addr,u32 dw0,u32 dw1,u32 dw2,u32 dw3) void writeFmInt(u32 dw) void writeBulkHeadList(u32 dw) void setBulkListEn() void setTDFound() void setOperational() void writePort1Stat(u32 dw) void writePort2Stat(u32 dw) void writeFmRem(u32 dw) void writeOH1FmInt(u32 dw) void writeOH1BulkHeadList(u32 dw) void setOH1BulkListEn() void setOH1TDFound() void setOH1Operational() void writeOH1Port1Stat(u32 dw) void writeOH1Port2Stat(u32 dw) void writeOH1FmRem(u32 dw) void oh0Init(void(*_Cb)(void),int mask) void oh1Init(void(*_Cb)(void),int mask) void ehcInit(void(*_Cb)(void),int mask) void( usb_udelay_function)(u32 delay) 22 0 39 usb_input.h void input_register_device(struct input_dev *) void input_unregister_device(struct input_dev *) void input_register_handler(struct input_handler *) void input_unregister_handler(struct input_handler *) int input_open_device(struct input_handle *) void input_close_device(struct input_handle *) void input_event(struct input_dev *dev,unsigned int type,unsigned int code,int value) 7 0 747 usb_mem.h void usb_malloc_dma(u32 len,u32 *dma_addr) struct usb_pool usb_pool_create(u32 size,u32 uncached) dma_addr_t usb_map_single(void *transfer_buffer,int data_len,int dir) void usb_unmap_single(u32 dma_addr,int len,int dir) void usb_pool_alloc(struct usb_pool *ppool,u32 *dma_addr) void usb_pool_free(struct usb_pool *ppool,void *pobj,u32 dma_addr) void usb_pool_destroy(struct usb_pool *ppool) void usb_malloc(u32 len) void usb_free(void *p,u32 len) void usb_memset(void *cp,u32 val,int size) void usb_memscan(void *addr,int c,size_t size) u32 usb_check_payload(u32 StartValue,u32 IncrBy,u32 BufferLength,u32 *pBuffer,u32 *next_value) u32 usb_fill_payload(u32 StartValue,u32 IncrBy,u32 BufferLength,u32 *pBuffer) 13 0 35 usb_spin.h void spin_lock_irqsave(spinlock_t *sp_lock,int flags) void spin_unlock_irqrestore(spinlock_t *sp_lock,int flags) 2 0 34 usb_timer.h void mod_timer(struct timer_list *tlist,u32 val) void del_timer_sync(struct timer_list *tlist) u32 timer_pending(struct timer_list *tlist) void add_timer(struct timer_list *wh) void init_timer(struct timer_list *wh) void del_timer(struct timer_list *wh) int time_after(u32 jiff,int timeout) 7 0 25 util.h u32 swapBytes4(u32 input) void swapBytesPtr(void *ptr,int byteCount) void swapByteGroupingsPtr(void *ptr,int groupSize,int groupCount) 3 0 20 vi.h vireg viRegs[] const encoder_type_t VI_ENCODER_ROHM const encoder_type_t VI_ENCODER_CONXT void viNtsc(void) void viSetFormat(viFormat fmat,u32 xoff,u32 yoff,u32 height,u32 width) void viSetFieldSrc(viBase field,u32 addr,u32 width,u32 stride) void viEnable(u32 e) void viLoad(void) void viLoadSync(void) void fire_gun1(int duration) void fire_gun0(int duration) int mon_tstgun0clr(void) int mon_tstgun1clr(void) int confirm_gun0(void) int confirm_gun1(void) int confirm_notgun0(void) int confirm_notgun1(void) int chk_int(int int_num) void clr_int(int int_num,u32 vct,u32 enb) void viNtsc(void) u16 __VIRegs(int index) void printVIRegs(void) void SetVIInt(int int_num,int int_enb,u16 hct,u16 vct) void ClrVIInt(int int_num) void __VISet3in1Output(VIBool enable) void GPIOInit(void) void outputLed(int value) BOOL __VISetSCL(u32 value) BOOL __VISetSDA(u32 value) void __VIOpenI2C(void) void __VICloseI2C(void) void __VISet3in1Output(VIBool enable) void __VISetVolume(u8 volumeL,u8 volumeR) void YUVSolidColor(u8 y,u8 u,u8 v,u8 enable) void vipll_init(void) void ViLcdInit(void) void vi_setcnxt_reg(u8 addr,u8 data) void viHd1080i(void) void viHd720p(void) BOOL __VIRelSCL(u32 value) BOOL __VIDisSDA(u32 value) u8 VIGetSDA(void) u8 vi_getcnxt_reg(u8 addr,u8 data) s32 __VIGetI2CData(u8 slaveAddr,u8 *pData,s32 nBytes) s32 __VIsetI2CAddress(u8 slaveAddr,u8 *pData,s32 nBytes) void set_current_vi_encoder(encoder_type_t enc_type) void vi_init_hd(void) 44 3 169 vi_conexant.h void read_print(u8 addr) void conexant_set_hdtv_mode(HdFormat hdtv_mode) int i2c_writereg(unsigned char theSlave,unsigned char theReg,unsigned char theValue) unsigned char i2c_readreg(unsigned char theSlave,unsigned char theReg) void i2c_gpioinit(void) void vi_init_hd(void) 6 0 15 video.h void videoInit(void *fb,int format) void videoSwapBuffers(void *fb) void videoUseISR4Swap(void) int videoGetEncoderType(void) void viDump(void) 5 0 71 Diag (ati/diag) /diag This folder contains interfaces for direct access to PowerPC registers, including Broadway specific ones. Judging by the name of this folder it is maily for testing that the PowerPC CPU is correctly handling the different register values in tests written for DIAG4RVL. File Name Extension Description PPCArch .h Include file for declaring pre-processor constants for PowerPC such as IBAT4U which is a Broadway register model/unshared .h Include file for declaring a bunch of powerPX functions for getting and setting register values such as ppcHID0Set Code Files unshared.h void halt(void) void ppcL1Enable(void) void ppcL2Enable(void) void ppcHID0Set(u32 val) u32 ppcHID0Get(void) void ppcHID2Set(u32 val) u32 ppcHID2Get(void) void ppcHID4Set(u32 val) u32 ppcHID4Get(void) void ppcL2CRSet(u32 val) u32 ppcL2CRGet(void) void ppcWPARSet(u32 val) u32 ppcWPARGet(void) void ppcDecSet(u32 val) void ppcMsrSet(u32 val) u32 ppcMsrGet(void) void ppcTBUSet(u32 val) u32 ppcTBUGet(void) void ppcTBLSet(u32 val) u32 ppcTBLGet(void) u32 ppcPVRGet(void) void setIrqHndlr(void(*hndlr)()) void __dcbi(u32 *,u32) void __icbi(u32 *,u32) u32 __lwarx(u32) void __stwcx(u32,u32) void _ctxSw(void *newCtx) void _irqCtxSw(void *newCtx) void ppcSync(void) void ppcEeieo(void) 30 0 76 Export (ati/export) /export This folder contains a subset of the header files copied from the GX folder, basically identical copies without the gxreg.h file. No idea why these would be used instead of the standard ones under the GX folder.. Check the next section for the description of the GX files for information on them, no point in duplicating the descriptions in this section. Fiddle (FDL) Generated Headers (ati/fdl) /fdl This folder contains C header files automatically generated from a tool called fiddle that takes in Field description language .fdl files and returns a C header file with lots of pre-processor constants. The original fiddle files have already been documented in the Emerald leak, so if you are interested check out our page on that leak. Nintendo Emerald Leak For more information on the Emerald leak check out this post. File Name Extension Description ahb_fdl_defs .h Include file for declaring ? bp_reg .h Include file for declaring Blitting Processor details cp_reg .h Include file for declaring Command processor details dsp_reg .h Include file for declaring Digital Signal Processor details gen_if .h Include file for declaring ? gen_reg .h Include file for declaring ? io_reg .h Include file for declaring ? mem_reg .h Include file for declaring ? pe_misc .h Include file for declaring Pixel engine details pe_reg .h Include file for declaring Pixel engine register details pi_reg .h Include file for declaring Processor Interface ra_gen .h Include file for declaring ? ras2_tev_if .h Include file for declaring ? ras_reg .h Include file for declaring ? su_reg .h Include file for declaring Setup Unit details tev_reg .h Include file for declaring Texture Color Combiner details tx_reg .h Include file for declaring Texture registers vi_reg .h Include file for declaring Video Interface registers xf_cmds .h Include file for declaring XF (Transform unit) commands xf_mem .h Include file for declaring ? xf_state .h Include file for declaring ? xf_ucode .h Include file for declaring ? Not exactly sure what the Gamecube/Wii XF hardware is but seems to be able to read commands and microcode (ucode).Gx (ati/gx) /gx This folder contains the C-Header files used for Graphics development using the Gamecube/Wii GPU known as Flipper/Broadway. File Name Extension Description gx .h Include file for declaring all the Graphics related structures and functions such as GXInitTexObj gxfifo .h Include file for declaring a simulation of the Graphics FIFO pipeline in software gxreg .h Include file for declaring a simulation of the Graphics hardware Registers in software vertex .h Include file for declaring pre-processor defines related to vertices such as GXTexCoord2bv Code Files gx.h void memset32(void *,u32,u32) void memcpy32(void *,const void *,u32) int memcmp32(const void *,const void *,u32) void GXSetVtxDesc(GXAttr Attr,GXAttrType Type) void GXSetVtxDescv(GXVtxDescList *AttrPtr) void GXGetVtxDesc(GXAttr Attr,GXAttrType *TypePtr) void GXClearVtxDesc(void) void GXSetVtxAttrFmt(GXVtxFmtID Idx,GXAttr Attr,GXCompCnt CompCnt,GXCompType CompType,u8 Shift) void GXSetVtxAttrFmtv(GXVtxFmtID Idx,GXVtxFmtList *AttrPtr) void GXGetVtxAttrFmt(GXVtxFmtID Idx,GXAttr Attr,GXCompCnt *CompCnt,GXCompType *CompType,u8 *Shift) void GXSetArray(GXAttr Attr,u32 Base,u8 Stride) void GXGetArray(GXAttr Attr,u32 *Base,u8 *Stride) void GXSetTexCoordGen(GXTexCoord Coord,GXTexGenType Type,u8 MatIdx) void GXGetTexCoordGen(GXTexCoord Coord,GXTexGenType *Type,u8 *MatIdx) void GXSetTexCoordGen2(GXTexCoord Coord,GXTexGenFunc Func,GXTexGenSrc Source,u8 MatIdx) void GXSetTexCoordWrap(GXTexCoord Coord,GXBool CylWrapS,GXBool CylWrapT,GXBool BiasS,GXBool BiasT,GXBool LineOffset,GXBool PointOffset) void GXSetBumpSource(GXTexCoord Coord,GXTexCoord SrcCoord,GXLightID SrcLight) void GXGetBumpSource(GXTexCoord Coord,GXTexCoord *SrcCoord,GXLightID *SrcLight) void GXSetTexCoordTrans(GXTexCoord Coord,GXMtxName MtxIdx,GXBool Normalize) void GXSetDualTexTrans(GXBool Enable) void GXSetCCConstColor(GXCCRegID CCReg,GXColor Color) void GXGetCCConstColor(GXCCRegID CCReg,GXColor *Color) void GXSetCCConstSelect(GXCCStageID CCStageId,GXCCColSelect ConstSelect) void GXGetCCConstSelect(GXCCStageID CCStageId,GXCCColSelect *ConstSelect) void GXSetACConstSelect(GXCCStageID CCStageId,GXCCColSelect ConstSelect) void GXGetACConstSelect(GXCCStageID CCStageId,GXCCColSelect *ConstSelect) void GXSetCCSwapModeTableEntry(GXCCSwSelect CCSwapId,GXCCChannel Red,GXCCChannel Green,GXCCChannel Blue,GXCCChannel Alpha) void GXGetCCSwapModeTableEntry(GXCCSwSelect CCSwapId,GXCCChannel *Red,GXCCChannel *Green,GXCCChannel *Blue,GXCCChannel *Alpha) void GXSetCCSwapMode(GXCCStageID CCStageId,GXCCSwSelect TextureSwap,GXCCSwSelect RasterSwap) void GXGetCCSwapMode(GXCCStageID CCStageId,GXCCSwSelect *TextureSwap,GXCCSwSelect *RasterSwap) void GXClearVertexCache(void) void GXGetVertexCacheStatus(u32 *CheckCnt,u32 *MissCnt,u32 *StallCnt) void GXBeginPrimitive(GXPrimitive Type,GXVtxFmtID VatIdx,u16 Nverts) void GXBeginPrimitive2(GXPrimitive Type,GXVtxFmtID VatIdx,u16 Nverts) void GXEndPrimitive(void) void GXSetLineWidth(u8 Width,GXTexOffsets Offset) void GXGetLineWidth(u8 *Width,GXTexOffsets *Offset) void GXSetPointSize(u8 PointSize,GXTexOffsets Offset) void GXGetPointSize(u8 *PointSize,GXTexOffsets *Offset) void GXSetShadeMode(GXShadeModes Mode) void GXGetShadeMode(GXShadeModes *Mode) void GXSetAntiAliasing(GXBool Mode,u8 SamplePts[4][3][2]) void GXGetAntiAliasing(GXBool *Mode,u8 SamplePts[4][3][2]) void GXSetCoPlanar(GXBool Enable) void GXGetCoPlanar(GXBool *Enable) void GXSetFieldMode(GXBool texLod,GXBool linewd) void GXSetProjection(f32 Matrix[4][4],GXProjMtxType type) void GXLoadPosMatrixIndx(u32 ArrayIdx,GXMtxName MatName) void GXLoadNormMatrixIndx(u32 ArrayIdx,GXMtxName MatName) void GXLoadTexMatrixIndx(u32 ArrayIdx,GXMtxName MatName,GXMtxType Type) void GXLoadPosMatrixImm(f32 *MatrixPtr,GXMtxName MatName) void GXLoadNormMatrixImm(f32 *MatrixPtr,GXMtxName MatName) void GXLoadTexMatrixImm(f32 *MatrixPtr,GXMtxName MatName,GXMtxType Type) void GXSetDefaultMatrix(GXMtxName MatName) void GXGetDefaultMatrix(GXMtxName *MatName) void GXSetViewport(s16 Left,s16 Top,u16 Width,u16 Height,f32 Near,f32 Far) void GXGetViewport(s16 *Left,s16 *Top,u16 *Width,u16 *Height,f32 *Near,f32 *Far) void GXSetScissor(u16 Left,u16 Top,u16 Width,u16 Height) void GXGetScissor(u16 *Left,u16 *Top,u16 *Width,u16 *Height) void GXSetCullMode(GXCullModes Mode) void GXGetCullMode(GXCullModes *Mode) void GXInitLightAttn(GXLightObj *ptr,f32 A0,f32 A1,f32 A2,f32 K0,f32 K1,f32 K2) void GXInitShininess(GXLightObj *ptr,f32 Shininess) void GXInitLightPos(GXLightObj *ptr,f32 X,f32 Y,f32 Z) void GXInitLightDir(GXLightObj *ptr,f32 X,f32 Y,f32 Z) void GXInitLightColor(GXLightObj *ptr,GXColor LightColor) void GXLoadLightStateImm(GXLightObj *ptr,GXLightID LightId) void GXLoadLightStateIndx(u32 LightObjIdx,GXLightID LightId) void GXSetAmbientColor(GXColorID ColorId,GXColor AmbColor) void GXGetAmbientColor(GXColorID ColorId,GXColor *AmbColor) void GXSetMaterialColor(GXColorID ColorId,GXColor MatColor) void GXGetMaterialColor(GXColorID ColorId,GXColor *MatColor) void GXSetLightCtrl(GXColorID ColorId,GXBool Enable,GXColorSrc AmbSource,GXColorSrc MatSource,GXLightID LightMask,GXDiffuseFn DiffFunc,GXAttnFn AttnFunc) void GXGetLightCtrl(GXColorID ColorId,GXBool *Enable,GXColorSrc *AmbSource,GXColorSrc *MatSource,GXLightID *LightMask,GXDiffuseFn *DiffFunc,GXAttnFn *AttnFunc) void GXInitTexObj(GXTexObj *TexObjPtr,void *ImagePtr,u16 Width,u16 Height,GXTexFormats Format,GXTexWrapModes WrapS,GXTexWrapModes WrapT,GXTexFilters MinFilt,GXTexFilters MagFilt,f32 MinLod,f32 MaxLod,f32 LodBias,GXBool doEdgeLod) void GXInitTexObj2(GXTexObj *TexObjPtr,GXBool LodClamp,GXTexAnisotropy MaxAniso,GXBool FieldPredict,GXBool BilinearRound) void GXInitTlutObj(GXTlutObj *TlutObjPtr,void *LutPtr,u16 NumEntries,GXTlutFormats Format) void GXInitTexRegion(GXTexRegion *TexRegionPtr,GXBool IsCached,void *TmemEvenPtr,u8 WidthEven,u8 HeightEven,void *TmemOddPtr,u8 WidthOdd,u8 HeightOdd) void GXInitTlutRegion(GXTlutRegion *TlutRegionPtr,void *TmemPtr) void GXPreLoadTexture(GXTexObj *TexObjPtr,GXTexRegion *TexRegionPtr) void GXLoadTlut(GXTlutObj *TlutObjPtr,GXTlutRegion *TlutRegionPtr) void GXLoadTexState(GXTexMapID TexId,GXTexObj *TexObjPtr,GXTexRegion *TexRegionPtr) void GXLoadTlutState(GXTexMapID TexId,GXTlutObj *TlutObjPtr,GXTlutRegion *TlutRegionPtr) void GXClearTexRegion(GXTexObj *TexObjPtr,GXTexRegion *TexRegionPtr) void GXFlushTextureState(void) void GXInitIndirectTexture(GXCCStageID CCStageId,GXIndTexMapID TexId,GXIndTexFormats Fmt,GXIndTexBias Bias,GXIndTexAlphaSel AlphaSel,GXIndTexMtxID MatrixSel,GXIndTexWrap WrapS,GXIndTexWrap WrapT,GXBool IndLOD,GXBool AddPrev) void GXSetIndTexMtx(GXIndTexMtxID MtxId,f32 OffsetMatrix[3][2],u8 ScaleExp) void GXSetIndTexScale(GXIndTexMapID IndTexId,GXIndTexScale ScaleS,GXIndTexScale ScaleT) void GXSetIndTexOrder(u8 NumIndTex,GXIndTexMapID IndTexId[],GXTexMapID TexId[],GXTexCoord TexCoord[]) void GXSetCCOp(GXCCStageID CCStageId,GXCCOps ColorOp,GXCCArgs Arg1,GXCCArgs Arg2,GXCCArgs Arg3,GXCCArgs Arg4) void GXGetCCOp(GXCCStageID CCStageId,GXCCOps *ColorOp,GXCCArgs *Arg1,GXCCArgs *Arg2,GXCCArgs *Arg3,GXCCArgs *Arg4) void GXSetACOp(GXCCStageID CCStageId,GXCCOps ColorOp,GXCCArgs Arg1,GXCCArgs Arg2,GXCCArgs Arg3,GXCCArgs Arg4) void GXGetACOp(GXCCStageID CCStageId,GXCCOps *ColorOp,GXCCArgs *Arg1,GXCCArgs *Arg2,GXCCArgs *Arg3,GXCCArgs *Arg4) void GXSetCCOutput(GXCCStageID CCStageId,GXCCScale Scale,GXCCBias AddBias,GXCCClamp Clamp,GXCCRegID CCReg) void GXGetCCOutput(GXCCStageID CCStageId,GXCCScale *Scale,GXCCBias *AddBias,GXCCClamp *Clamp,GXCCRegID *CCReg) void GXSetACOutput(GXCCStageID CCStageId,GXCCScale Scale,GXCCBias AddBias,GXCCClamp Clamp,GXCCRegID CCReg) void GXGetACOutput(GXCCStageID CCStageId,GXCCScale *Scale,GXCCBias *AddBias,GXCCClamp *Clamp,GXCCRegID *CCReg) void GXSetCCColor(GXCCRegID CCReg,GXColor Color) void GXSetCCColor2(GXCCRegID CCReg,s16 red,s16 grn,s16 blu,s16 alp) void GXGetCCColor(GXCCRegID CCReg,GXColor *Color) void GXSetCCOrder(u8 NumStages,GXTexMapID TexId[],GXTexCoord TexCoord[],GXColorID ColorId[]) void GXGetCCOrder(u8 *NumStages,GXTexMapID TexId[],GXTexCoord TexCoord[],GXColorID ColorId[]) void GXSyncSuTsRegs(void) void GXGetSuTexSize(GXTexCoord coord,u32 *w,u32 *h) void GXSetRange(f32 NearZ,f32 SideX) void GXSetFog(GXFogTypes Type,GXBool Proj,GXBool Range,f32 StartZ,f32 EndZ,f32 NearZ,f32 FarZ,f32 SideX,GXColor Color) void GXGetFog(GXFogTypes *Type,GXBool *Proj,GXBool *Range,f32 *StartZ,f32 *EndZ,f32 *NearZ,f32 *FarZ,f32 *SideX,GXColor *Color) void GXSetColorMode(GXColorModes Ops,GXBlendModes SrcFactor,GXBlendModes DstFactor,GXLogicOps logicOp,GXBool Dither) void GXGetColorMode(GXColorModes *Ops,GXBlendModes *SrcFactor,GXBlendModes *DstFactor,GXLogicOps *logicOp,GXBool *Dither) void GXSetBlendOp(GXBlendOps op) void GXSetDestAlpha(GXBool Enable,u8 Alpha) void GXGetDestAlpha(GXBool *Enable,u8 *Alpha) void GXSetZMode(GXBool CompareEnable,GXBool UpdateEnable,GXCompare Func) void GXGetZMode(GXBool *CompareEnable,GXBool *UpdateEnable,GXCompare *Func) void GXSetZTexture(GXZTexOp op,GXZTexFormat fmt,f32 zBias) void GXGetZTexture(GXZTexOp *op,GXZTexFormat *fmt,f32 *zBias) void GXSetAlphaFunc(GXAlphaLogic AlphaLogic,GXCompare Func0,GXCompare Func1,u8 RefValue0,u8 RefValue1) void GXGetAlphaFunc(GXAlphaLogic *AlphaLogic,GXCompare *Func0,GXCompare *Func1,u8 *RefValue0,u8 *RefValue1) void GXSetPixelFormat(GXPixelFormats Format,GXZCmprFormats ZCmpr,GXBool ZTop) void GXGetPixelFormat(GXPixelFormats *Format,GXZCmprFormats *ZCmpr,GXBool *ZTop) void GXSetColorMask(GXBool ColorMask,GXBool AlphaMask) void GXSetMotionComp(GXBool OddMask,GXBool EvenMask) void GXGetMotionComp(GXBool *OddMask,GXBool *EvenMask) void GXBeginDisplayList(void *BasePtr,u32 nBytes) u32 GXEndDisplayList(void) void GXCallDisplayList(void *BasePtr,u32 nBytes) void GXSetCopyControl(GXFbClamps ClampFlags,GXTexFormats TexFormat,GXFbInterlace Interlaced,GXGamma Gamma,u16 VertScale,GXBool MipFilter) void GXSetCopyColorConv(GXCCV ccvFlag) void GXSetAAFilter(u8 Coefficients[7]) void GXGetAAFilter(u8 Coefficients[7]) void GXCopyFBToDisplay(u16 SrcLeft,u16 SrcTop,u16 SrcWidth,u16 SrcHeight,void *DstBasePtr,u16 DstStride,GXBool Clear) void GXHDOffset(u16 PrevSrcHeight,void *DstBasePtr,u16 DstStride,GXBool RstEnable,GXBool HFilter) void GXSetHD(u16 AlphaRst,u16 ScaleRst,GXBool RstEnable,GXBool HFilter) void GXCopyFBToDisplay16(u16 SrcLeft,u16 SrcTop,u16 SrcWidth,u16 SrcHeight,void *DstBasePtr,u16 DstStride,GXBool Clear) void GXCopyFBToDisplay32(u16 SrcLeft,u16 SrcTop,u16 SrcWidth,u16 SrcHeight,void *DstBasePtr,u16 DstStride,GXBool Clear) void GXCopyFBToTexture(u16 SrcLeft,u16 SrcTop,u16 SrcWidth,u16 SrcHeight,void *DstBasePtr,u16 DstStride,GXBool Clear) void GXSetClear(GXColor ClearColor,u32 ClearZ) void GXGetClear(GXColor *ClearColor,u32 *ClearZ) void GXClearBoundingBox(void) void GXGetBoundingBox(u16 *Left,u16 *Right,u16 *Top,u16 *Bottom) void GXSetQuadOffset(u16 left,u16 top) u32 GXReadPixelColorAlpha(u16 x,u16 y) u32 GXReadPixelColor(u16 x,u16 y) void GXWritePixelColor(u16 x,u16 y,u32 color) u32 GXGetPerfMetric(GXPerf perf) void GXInitPerfCounters(GXPerfBlock blockA,u32 valA,GXPerfBlock blockB,u32 valB,GXPerfBlock blockC,u32 valC,GXPerfBlock blockD,u32 valD) void GXInitPEPerfCounters(GXBool pe0,GXBool pe1,GXBool pe2,GXBool pe3,GXBool pe4,GXBool pe5) void GXDisplayPerfCounters(void) void GXSetFifoBase(u32 BasePtr,u32 Size,GXBool SetDefaults) void GXSetFifoLimits(u32 HiWaterMark,u32 LoWaterMark,u32 RdBreakMark) void GXSetInterrupts(GXBool Underflow,GXBool Overflow,GXBool BreakPoint) void GXClearInterrupts(GXBool Underflow,GXBool Overflow,GXBool BreakPoint) void GXSetFifoPtrs(u32 WritePtr,u32 ReadPtr) void GXGetFifoPtrs(u32 *WritePtrPtr,u32 *ReadPtrPtr) void GXGetFifoStatusFull(GXBool *Underflow,GXBool *Overflow,GXBool *Break,GXBool *RDIdle,GXBool *CPIdle) void GXGetFifoStatus(GXBool *Underflow,GXBool *Overflow,GXBool *Break) void GXDisplayFifoStatus(void) void GXGetFifoCount(u32 *FifoCount) void GXSetFifoEnable(GXBool Read,GXBool WrPtrInc) void GXInit(void) void GXInit2(void) void GXInitB(u32 revNo) void GXSetPERefresh(u32 peRefresh) void GXSetTXRefresh(u32 txRefresh) void GXAbortFrame(void) void GXSetDrawSync(u16 Token) void GXGetDrawSync(u16 *Token) GXBool GXDrawDone(void) GXBool GXDrawDoneSafe(void) void GXFlush(void) void GXHWSync(u8 Token) void GXBypass(u32 regData) 172 0 1513 gxfifo.h void gxFifoWrite(u32 d,u32 sz) void GXResetCacheAlignment() void GXSimStart(char *fileName) void GXSimEnd(void) void GXSimEnd(void) 5 0 172 gxreg.h void gxRegWrite16(u32 addr,u16 data) void gxRegWrite32(u32 addr,u32 data) u16 gxRegRead16(u32 addr,u32 cpIdleFlag) u32 gxRegRead32(u32 addr) void simSync(void) void GXWriteXFRegs(u32 addr,u8 Count,u32 *data) void GXWriteXFRegDirect(u32 addr,u32 data) void GXReadXFReg(u32 addr,u32 *data) void GXWriteCPReg(u8 addr,u16 data) void GXReadCPReg(u8 addr,u16 *data) void GXWritePIReg(u8 addr,u32 data) void GXReadPIReg(u8 addr,u32 *data) void GXWritePEReg(u8 addr,u16 data) void GXReadPEReg(u8 addr,u16 *data) void GXSUBypassCmd(u8 cmd,u32 data) void GXLoadCPReg(u8 reg,u32 data) 16 0 174 Gxu Library Headers (ati/gxu) /gxu This folder contains the header file for the GXU library which is similar to GLU if you have ever used OpenGL, it contains Graphical utility functions for reading textures and setting up view Matrices. File Name Extension Description gxu .h Include file for declaring all the Utility functions provided by the GXU library Code Files gxu.h void gxuGetFrustum(float l,float r,float b,float t,float n,float f,float m[3][4]) void gxuGetLightFrustum(float l,float r,float b,float t,float n,float sS,float tS,float sT,float tT,float m[3][4]) void gxuGetOrtho(float l,float r,float b,float t,float n,float f,float m[3][4]) void gxuGetPerspective(float fov,float aspect,float n,float f,float m[3][4]) void gxuGetRotate(float deg,float x,float y,float z,float m[3][4]) void gxuGetTranslate(float x,float y,float z,float m[3][4]) void gxuGetScale(float x,float y,float z,float m[3][4]) void gxuGetIdentity(float m[3][4]) u32 gxuGetInverse(float mat[3][4],float inv[3][4]) void gxuGetTranspose(float mat[3][4],float xPose[3][4]) void gxuMultMatrix(float current[3][4],float mat[3][4]) void gxuMultVec(float vec[3],float mat[3][4]) AXuint32 gxuGetPPMFileSize(char *FileName,AXuint32 *width,AXuint32 *height) AXuint32 gxuGetImageFileSize(char *FileName,AXuint32 *width,AXuint32 *height) AXuint32 gxuReadBitmapFile(char *FileName,AXuint32 *width,AXuint32 *height,GXColor **bImage) AXuint32 gxuWriteBitmapFile(char *FileName,AXuint32 w,AXuint32 h,GXTexFormats format,void *bImage) AXuint32 gxuReadPPMFile(char *FileName,AXuint32 *width,AXuint32 *height,GXColor **bImage) AXuint32 gxuWritePPMFile(char *FileName,AXuint32 w,AXuint32 h,GXTexFormats format,void *bImage) AXuint32 gxuReadDDSFile(char *FileName,AXuint32 *width,AXuint32 *height,AXuint32 *numLod,void **bImage) void gxuGenImage(GXUImageType iType,AXuint32 width,AXuint32 height,GXUColorType color,GXColor *bImage) void gxuConvertImage(AXuint32 imageW,AXuint32 imageH,GXColor *rgbImage,GXTexFormats texFmt,GXBool generateLut,GXTlutFormats tlutFmt,void *lut,void *image) void gxuGetIndexedImage(GXUImageType iType,GXUColorType color,AXuint32 imageW,AXuint32 imageH,GXColor *planarImage,GXTlutFormats tlutFmt,AXuint32 numEntries,void *lutPtr) void gxuRandomImage(AXuint32 imageW,AXuint32 imageH,GXBool mipMapped,GXTexFormats texFmt,GXTlutFormats tlutFmt,void *lut,void *image) AXuint32 gxuGetNumLevels(AXuint32 width,AXuint32 height) void gxuGetTiledImage(GXColor *planarImage,AXuint32 width,AXuint32 height,GXBool mipMapped,GXTexFormats tilefmt,void *tiledImage) void gxuGetBorderedTiledImage(GXColor *planarImage,GXColor border,AXuint32 width,AXuint32 height,GXBool mipMapped,GXTexFormats tilefmt,void *tiledImage) void gxuFormatImage(GXColor *planarImage,AXuint32 width,AXuint32 height,GXBool mipMapped,GXTexFormats tilefmt,GXTlutFormats tlutFmt,void *lut,void *tiledImage) AXuint32 gxuGetTiledSize(GXBool mipMapped,GXTexFormats tilefmt,AXuint32 width,AXuint32 height) void gxuTexPreloadAlloc(GXUMipMapType mipMapped,GXTexFormats fmt,AXuint32 width,AXuint32 height,AXuint32 *EvenPtr,AXuint32 *OddPtr) void gxuTexPreloadAllocL(GXUMipMapType mipMapped,GXTexFormats fmt,AXuint32 width,AXuint32 height,AXuint32 *ptr) void gxuTexPreloadAllocH(GXUMipMapType mipMapped,GXTexFormats fmt,AXuint32 width,AXuint32 height,AXuint32 *ptr) void gxuTexAllocTlut(GXTlutFormats fmt,AXuint32 nEntries,AXuint32 *ptr) void gxuTexAllocTlut2(GXTlutFormats fmt,AXuint32 nEntries,AXuint32 *ptr) void gxuTexCachedAlloc(GXUMipMapType mipMapped,GXTexFormats fmt,AXuint8 cacheWidth,AXuint8 cacheHeight,AXuint32 *EvenPtr,AXuint32 *OddPtr) void gxuTexCachedAllocL(GXUMipMapType mipMapped,GXTexFormats fmt,AXuint8 cacheWidth,AXuint8 cacheHeight,AXuint32 *ptr) void gxuTexCachedAllocH(GXUMipMapType mipMapped,GXTexFormats fmt,AXuint8 cacheWidth,AXuint8 cacheHeight,AXuint32 *ptr) void gxuTexCachedAlloc2(GXUMipMapType mipMapped,GXTexFormats fmt,AXuint8 cacheWidth,AXuint8 cacheHeight,AXuint32 *EvenPtr,AXuint32 *OddPtr) void gxuTexCachedAllocL2(GXUMipMapType mipMapped,GXTexFormats fmt,AXuint8 cacheWidth,AXuint8 cacheHeight,AXuint32 *ptr) void gxuTexCachedAllocH2(GXUMipMapType mipMapped,GXTexFormats fmt,AXuint8 cacheWidth,AXuint8 cacheHeight,AXuint32 *ptr) void gxuTexCacheFree(AXuint32 EvenPtr,AXuint32 OddPtr) void gxuTexMemFree(AXuint32 Ptr) void gxuBumpInit(AXuint32 nStages) void gxuInitRasterState(char *fileName) void gxuInitEFB(u32 col,u32 z,u32 left,u32 top,u32 width,u32 height,GXPixelFormats fmt) void gxuCopyOut(u32 left,u32 top,u32 width,u32 height) void gxuBUDInit(int argc,char **argv,u32 left,u32 top,u32 width,u32 height) void gxuBUDInitB(u32 revNo,int argc,char **argv,u32 left,u32 top,u32 width,u32 height) void gxuBUDFinish(int argc,char **argv,u32 left,u32 top,u32 width,u32 height) int width int height GXColor pixels gxuCachedImage gxuCachedImage gxuCachedImages[] 48 5 317 Helper (ati/helper) /helper This folder only contains one file called compiler.h which defines certain pre-processor constants based on which compiler has been used. Compilers supported are: ATI GNU Compiler GNU C Compiler Watcom C Compiler The pre-processor constants defined are used for purposes such as calling conventions (AX_CDECL) or to mark certain arguments or variables as unused in the code (ATI_VARIABLE_NOT_USED). Private (ati/private) /private This folder contains miscellaneous files related to debugging the low level hardware components, presumably this was just meant for internal use at ATI themselves. File Name Extension Description common .h Include file for including all the other files in the private folder fdl_assert .h Include file for declaring the FDL_ASSERT macro gxdebug .h Include file for declaring a few pre-processor based Graphic Debug functions such as DbgPrintf gxreg .h Include file for declaring low level graphics hardware debug functions such as GXWriteXFRegs gxtypes .h Include file for declaring useful graphical stuctures and functions such as __GXTexRegionInt_struct Code Files gxreg.h void gxRegWrite16(u32 addr,u16 data) void gxRegWrite32(u32 addr,u32 data) u16 gxRegRead16(u32 addr,u32 cpIdleFlag) u32 gxRegRead32(u32 addr) void simSync(void) void GXWriteXFRegs(u32 addr,u8 Count,u32 *data) void GXWriteXFRegDirect(u32 addr,u32 data) void GXReadXFReg(u32 addr,u32 *data) void GXWriteCPReg(u8 addr,u16 data) void GXReadCPReg(u8 addr,u16 *data) void GXWritePIReg(u8 addr,u32 data) void GXReadPIReg(u8 addr,u32 *data) void GXWritePEReg(u8 addr,u16 data) void GXReadPEReg(u8 addr,u16 *data) void GXSUBypassCmd(u8 cmd,u32 data) void GXLoadCPReg(u8 reg,u32 data) 16 0 174 gxtypes.h GXData gx GXBool fifoInit u32 Color f32 a[3] f32 k[3] f32 lpos[3] f32 ldir[3] GXLightObjInt u32 mode1 u32 image0 u32 image3 u32 loadImage0 u32 loadImage3 GXTexObjInt void gxLoadSuTsRegs(void) void gxXfVtxSpecs(u32 vatIdx) void gxSetMatrixIndex(GXAttr matIdxAttr) 3 14 281 ", "excerpt": "Introduction In 2020 and 2021 numerous secret files have been leaked from Nintendo thanks to Zammis Clark. Included in these files were source code for a variety of Wii internal applications such as a Diagnostic tool known as DIAG4. This post will cover the Low Level Wii SDK created by...", "tags": ["wii","sdk","leak","gamecube"], "image": "/public/images/wii/ATI Low Level Wii SDK.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "2D & 3D Graphics Techniques", "url": "/2d-graphics", "content": "This is a Work in progress page to list interesting articles on 2D graphics techniques to create cool effects.2D Graphics effectsHow Doom’s Melting Screen WorksThe YouTuber decino has created an excellent video explaining how the 2d melting screen transition works in the original Doom. It is well worth a watch!Pseudo 3d RoadsFor information on how to create 2D games that look pseudo 3d (e.g outrun) Check out:Lou’s Pseudo 3d Page3D Graphics effectsSonic R’s “Impossible” Fading transparencyThe video by GameHut provides a technical breakdown of a challenging graphical achievement on the Sega Saturn: implementing transparent object fading despite the hardware’s limitations.The Saturn’s sprite-based polygon rendering caused transparency corruption when polygons were distorted, leading to objects popping in, as seen in Daytona. The solution involved a clever two-step process called “twelve layer transparency”: first, stripping away the polygon’s Gouraud shading by storing and calculating three additional sets of lighting data [03:43], and then using the Saturn’s eight available color calculation ratio hardware registers to fade the now-unlit texture over the background [04:07].", "excerpt": "This is a Work in progress page to list interesting articles on 2D graphics techniques to create cool effects. 2D Graphics effects How Doom’s Melting Screen Works The YouTuber decino has created an excellent video explaining how the 2d melting screen transition works in the original Doom. It is well...", "tags": ["2d","3d","introduction"], "image": "/public/generated/placeholders/2d-graphics.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Batman Forever - The Arcade Game (1996)", "url": "/batman-forever", "content": "As the name suggests Batman Forever is originally an Arcade Game that got ported to MS-DOS, the Playstation 1 and Sega Saturn by Iguana Entertainment (Acclaim Published).The original arcade release was for the ST-V (Sega Titan Video Game System) arcade hardware which is what would eventually become the foundation of the 32X/Sega Saturn hardware 1.This article will cover interesting finding from both the original arcade version and the various home ports.Game DetailsBefore getting into the technical side of reverse engineering we will cover a few important game details so that its easier to understand the files that we are reverse engineering.Enemies Guesser Robot Feather Thug Tassel Boss Spice Sugar Two Face Thugs Voice from the Sky Sabouter Blade ZapperSource filesFrom the Sega Saturn version of the game we can find a few full source file paths: /BATMAN/GAME/ENEMYAI.C /BATMAN/GAME/EPROM/ATTRACT.S /batman/game/levels/hotel.c /batman/game/enemy.h /batman/game/enemyai.h /batman/game/game.h /batman/game/particle.h /batman/game/script.h /batman/game/objects.h /batman/gfx/particle/global.h /batman/gfx/particle/level1a.h Saturn Game Disc /BATMAN_COINOP/0 /BATMAN_COINOP/0FLOOR.BIN /BATMAN_COINOP/0WALL.BIN /BATMAN_COINOP/ALA_BACK.BIN /BATMAN_COINOP/ALLGFX.BIN /BATMAN_COINOP/ALLYAGFX.BIN /BATMAN_COINOP/ALLYBGFX.BIN /BATMAN_COINOP/ALTHUG.ANM /BATMAN_COINOP/ALTHUG.COD /BATMAN_COINOP/ALTH_GFX.BIN /BATMAN_COINOP/BACK /BATMAN_COINOP/BACK/ALLEYA.BIN /BATMAN_COINOP/BACK/ALLEYA.LVS /BATMAN_COINOP/BACK/ALLEYA.PAL /BATMAN_COINOP/BACK/ALLEYB.BIN /BATMAN_COINOP/BACK/ALLEYB.LVS /BATMAN_COINOP/BACK/ALLEYB.PAL /BATMAN_COINOP/BACK/BATCAVE.BIN /BATMAN_COINOP/BACK/BATCAVE.LVS /BATMAN_COINOP/BACK/BATCAVE.PAL /BATMAN_COINOP/BACK/HOTEL.BIN /BATMAN_COINOP/BACK/HOTEL.LVS /BATMAN_COINOP/BACK/HOTEL.PAL /BATMAN_COINOP/BACK/LEVEL1A.BIN /BATMAN_COINOP/BACK/LEVEL1A.LVS /BATMAN_COINOP/BACK/LEVEL1A.PAL /BATMAN_COINOP/BACK/LEVEL1B.BIN /BATMAN_COINOP/BACK/LEVEL1B.LVS /BATMAN_COINOP/BACK/LEVEL1B.PAL /BATMAN_COINOP/BACK/LEVEL1C.BIN /BATMAN_COINOP/BACK/LEVEL1C.LVS /BATMAN_COINOP/BACK/LEVEL1C.PAL /BATMAN_COINOP/BACK/LEVEL1D.BIN /BATMAN_COINOP/BACK/LEVEL1D.LVS /BATMAN_COINOP/BACK/LEVEL1D.PAL /BATMAN_COINOP/BACK/LOWCAVE.BIN /BATMAN_COINOP/BACK/LOWCAVE.LVS /BATMAN_COINOP/BACK/LOWCAVE.PAL /BATMAN_COINOP/BACK/LSUBWAY.BIN /BATMAN_COINOP/BACK/LSUBWAY.LVS /BATMAN_COINOP/BACK/LSUBWAY.PAL /BATMAN_COINOP/BACK/TWOFACE.BIN /BATMAN_COINOP/BACK/TWOFACE.LVS /BATMAN_COINOP/BACK/TWOFACE.PAL /BATMAN_COINOP/BACK/USUBWAY.BIN /BATMAN_COINOP/BACK/USUBWAY.LVS /BATMAN_COINOP/BACK/USUBWAY.PAL /BATMAN_COINOP/BACK1D.BIN /BATMAN_COINOP/BANK1.COD /BATMAN_COINOP/BANK10.COD /BATMAN_COINOP/BANK11.COD /BATMAN_COINOP/BANK12.COD /BATMAN_COINOP/BANK13.COD /BATMAN_COINOP/BANK14.COD /BATMAN_COINOP/BANK2.COD /BATMAN_COINOP/BANK3.COD /BATMAN_COINOP/BANK4.COD /BATMAN_COINOP/BANK5.COD /BATMAN_COINOP/BANK6.COD /BATMAN_COINOP/BANK7.COD /BATMAN_COINOP/BANK8.COD /BATMAN_COINOP/BANK9.COD /BATMAN_COINOP/BATBOSS.BIN /BATMAN_COINOP/BATBOSS.COD /BATMAN_COINOP/BATSIG.DAT /BATMAN_COINOP/BONUS.BIN /BATMAN_COINOP/BONUS.COD /BATMAN_COINOP/BONUSPAL.BIN /BATMAN_COINOP/CAVEBACK.BIN /BATMAN_COINOP/CAVE_GFX.BIN /BATMAN_COINOP/CDDA1 /BATMAN_COINOP/COMBO.DAT /BATMAN_COINOP/DOMIN.DAT /BATMAN_COINOP/FEATHER.ANM /BATMAN_COINOP/FEATHER.BIN /BATMAN_COINOP/FEATHER.COD /BATMAN_COINOP/FRONTEND /BATMAN_COINOP/FRONTEND/ACCLAIM.HI /BATMAN_COINOP/FRONTEND/BATFLC.BIN /BATMAN_COINOP/FRONTEND/BATHIGH.HI /BATMAN_COINOP/FRONTEND/BATLOGOA.HI /BATMAN_COINOP/FRONTEND/BATLOGOB.HI /BATMAN_COINOP/FRONTEND/BATM8.256 /BATMAN_COINOP/FRONTEND/BATOP8.256 /BATMAN_COINOP/FRONTEND/BATSIGNL.HI /BATMAN_COINOP/FRONTEND/CITY.HI /BATMAN_COINOP/FRONTEND/COMBO.HI /BATMAN_COINOP/FRONTEND/DCCOMIC.HI /BATMAN_COINOP/FRONTEND/DOM.HI /BATMAN_COINOP/FRONTEND/DRUGS2.HI /BATMAN_COINOP/FRONTEND/ENDGUYS.FLC /BATMAN_COINOP/FRONTEND/FOREVER2.FLC /BATMAN_COINOP/FRONTEND/GOTH.HI /BATMAN_COINOP/FRONTEND/IGUANA.HI /BATMAN_COINOP/FRONTEND/KO.HI /BATMAN_COINOP/FRONTEND/LEGAL.HI /BATMAN_COINOP/FRONTEND/LICENSE.HI /BATMAN_COINOP/FRONTEND/LOGO1.HI /BATMAN_COINOP/FRONTEND/MOBILE2.HI /BATMAN_COINOP/FRONTEND/MULTKOS.HI /BATMAN_COINOP/FRONTEND/OPT1.HI /BATMAN_COINOP/FRONTEND/OPT2.HI /BATMAN_COINOP/FRONTEND/OPT3.HI /BATMAN_COINOP/FRONTEND/OPT4.HI /BATMAN_COINOP/FRONTEND/PIC02.HI /BATMAN_COINOP/FRONTEND/RIBS8.256 /BATMAN_COINOP/FRONTEND/ROBFLC.BIN /BATMAN_COINOP/FRONTEND/ROBHIGH.HI /BATMAN_COINOP/FRONTEND/SKYBACK.HI /BATMAN_COINOP/FRONTEND/TAIL.HI /BATMAN_COINOP/FRONTEND/THING.HI /BATMAN_COINOP/FRONTEND/TITGFX.BIN /BATMAN_COINOP/FRONTEND/VAULT.HI /BATMAN_COINOP/FRONTEND/WBROS.HI /BATMAN_COINOP/FRONTEND/WHEEL8.256 /BATMAN_COINOP/FRONTEND/WING8.256 /BATMAN_COINOP/FRONTEND.BIN /BATMAN_COINOP/GAME.BIN /BATMAN_COINOP/GUESS.BIN /BATMAN_COINOP/GUESSER.ANM /BATMAN_COINOP/GUESSER.COD /BATMAN_COINOP/HERO.DAT /BATMAN_COINOP/HOTELGFX.BIN /BATMAN_COINOP/INTRO1A.BIN /BATMAN_COINOP/LEVEL10.COD /BATMAN_COINOP/LEVEL1A.COD /BATMAN_COINOP/LEVEL1B.COD /BATMAN_COINOP/LEVEL1C.COD /BATMAN_COINOP/LEVEL1D.COD /BATMAN_COINOP/LEVEL2.COD /BATMAN_COINOP/LEVEL3.COD /BATMAN_COINOP/LEVEL4.COD /BATMAN_COINOP/LEVEL5.COD /BATMAN_COINOP/LEVEL6.COD /BATMAN_COINOP/LEVEL7.COD /BATMAN_COINOP/LEVEL8.COD /BATMAN_COINOP/LEVEL9.COD /BATMAN_COINOP/LV1B_GFX.BIN /BATMAN_COINOP/LV1D_GFX.BIN /BATMAN_COINOP/LVBC_BCK.BIN /BATMAN_COINOP/LVBC_GFX.BIN /BATMAN_COINOP/LVBC_MSC.BIN /BATMAN_COINOP/MASKS /BATMAN_COINOP/MASKS/1BMSK1.RAW /BATMAN_COINOP/MASKS/1BMSK2.RAW /BATMAN_COINOP/MASKS/1BMSK3.RAW /BATMAN_COINOP/MASKS/1BMSK4.RAW /BATMAN_COINOP/MASKS/HTMSK1.RAW /BATMAN_COINOP/MASKS/HTMSK2.RAW /BATMAN_COINOP/MASKS/NEWBTUBE.RAW /BATMAN_COINOP/MASKS/NEWFTUBE.RAW /BATMAN_COINOP/MASKS/NEWLITE.RAW /BATMAN_COINOP/NMEGFX.BIN /BATMAN_COINOP/RIDDLER.DAT /BATMAN_COINOP/RIDLEV.BIN /BATMAN_COINOP/SAB.ANM /BATMAN_COINOP/SAB.COD /BATMAN_COINOP/SAB_GFX.BIN /BATMAN_COINOP/SAFE.TEX /BATMAN_COINOP/SCORE.DAT /BATMAN_COINOP/SFX /BATMAN_COINOP/SFX/2FACE.SFX /BATMAN_COINOP/SFX/2FACEFG.SFX /BATMAN_COINOP/SFX/ALEYASEQ.SEQ /BATMAN_COINOP/SFX/ALEYASEQ.SFX /BATMAN_COINOP/SFX/ALLEYA.SFX /BATMAN_COINOP/SFX/ALLEYB.SFX /BATMAN_COINOP/SFX/ALWAYS1.SFX /BATMAN_COINOP/SFX/BACKEND1.SEQ /BATMAN_COINOP/SFX/BACKEND1.SFX /BATMAN_COINOP/SFX/BACKEND2.SEQ /BATMAN_COINOP/SFX/BACKEND2.SFX /BATMAN_COINOP/SFX/BATARANG.SFX /BATMAN_COINOP/SFX/BATBOLA.SFX /BATMAN_COINOP/SFX/BATCALL.SFX /BATMAN_COINOP/SFX/BONUS.SFX /BATMAN_COINOP/SFX/CAVESEQ.SEQ /BATMAN_COINOP/SFX/CAVESEQ.SFX /BATMAN_COINOP/SFX/COIN.SFX /BATMAN_COINOP/SFX/FEATHER.SFX /BATMAN_COINOP/SFX/FRONTEND.SFX /BATMAN_COINOP/SFX/GRAPPLE2.SFX /BATMAN_COINOP/SFX/GRENADE.SFX /BATMAN_COINOP/SFX/GUESSER.SFX /BATMAN_COINOP/SFX/HOTEL.SFX /BATMAN_COINOP/SFX/HOTELSEQ.SEQ /BATMAN_COINOP/SFX/HOTELSEQ.SFX /BATMAN_COINOP/SFX/LBATCAVE.SFX /BATMAN_COINOP/SFX/LEV1ASEQ.SEQ /BATMAN_COINOP/SFX/LEV1ASEQ.SFX /BATMAN_COINOP/SFX/LEV1BSEQ.SEQ /BATMAN_COINOP/SFX/LEV1BSEQ.SFX /BATMAN_COINOP/SFX/LEV1DSEQ.SEQ /BATMAN_COINOP/SFX/LEV1DSEQ.SFX /BATMAN_COINOP/SFX/LEVEL1A.SFX /BATMAN_COINOP/SFX/LEVEL1B.SFX /BATMAN_COINOP/SFX/LEVEL1C.SFX /BATMAN_COINOP/SFX/LEVEL1D.SFX /BATMAN_COINOP/SFX/RIDDSEQ.SEQ /BATMAN_COINOP/SFX/RIDDSEQ.SFX /BATMAN_COINOP/SFX/RIDLRPAD.SFX /BATMAN_COINOP/SFX/SABOTEUR.SFX /BATMAN_COINOP/SFX/SDDRVS.TSK /BATMAN_COINOP/SFX/SELECT.SEQ /BATMAN_COINOP/SFX/SELECT.SFX /BATMAN_COINOP/SFX/SPICE.SFX /BATMAN_COINOP/SFX/SUGAR.SFX /BATMAN_COINOP/SFX/TASER.SFX /BATMAN_COINOP/SFX/TASSLE.SFX /BATMAN_COINOP/SFX/TFACESEQ.SEQ /BATMAN_COINOP/SFX/TFACESEQ.SFX /BATMAN_COINOP/SFX/THEME.SEQ /BATMAN_COINOP/SFX/THEME.SFX /BATMAN_COINOP/SFX/THUG.SFX /BATMAN_COINOP/SFX/UBATCAVE.SFX /BATMAN_COINOP/SFX/USUBWAY.SFX /BATMAN_COINOP/SMP_ABS.TXT /BATMAN_COINOP/SMP_BIB.TXT /BATMAN_COINOP/SMP_CPY.TXT /BATMAN_COINOP/SPACE.DAT /BATMAN_COINOP/SPI_GFX.BIN /BATMAN_COINOP/STOLEN.DAT /BATMAN_COINOP/SUGAR.ANM /BATMAN_COINOP/SUGAR.COD /BATMAN_COINOP/SUG_GFX.BIN /BATMAN_COINOP/TASSLE.ANM /BATMAN_COINOP/TASSLE.BIN /BATMAN_COINOP/TASSLE.COD /BATMAN_COINOP/TFACENME.ANM /BATMAN_COINOP/TFACENME.COD /BATMAN_COINOP/TFGFX.BIN /BATMAN_COINOP/TWO2_GFX.BIN /BATMAN_COINOP/YINYANG.DAT Object Files (Compiled C or ASM)From the Sega Saturn port of the game there are a few references to the original names for some of the compiled object files: Name Notes 3dbat.obj   enemy.obj   enemyai.obj   eprom\\anims1.obj   eprom\\anims2.obj   eprom\\anims3.obj   eprom\\anims4.obj   eprom\\anims5.obj   eprom\\anims6.obj   eprom\\anims7.obj   levels\\alleya.obj   levels\\alleyb.obj   levels\\batcave.obj   levels\\hotel.obj   levels\\level1a.obj   levels\\level1b.obj   levels\\level1c.obj   levels\\level1d.obj   levels\\lowcave.obj   levels\\lsubway.obj   levels\\riddcont.obj   levels\\twoface.obj   levels\\usubway.obj   sound.obj   Sega Saturn LibrariesAlso from the Sega Saturn version of the game we can see what libraries were linked into the main executable: c:\\saturn\\lib\\libgcc.lib c:\\saturn\\lib\\libc.lib c:\\igsatlib\\libiguan.lib eprom\\libeprom.lib <- This looks like a custom library for this game based on the eprom folder above c:\\saturn\\lib\\libsn.lib c:\\saturn\\segalib\\lib\\libgfs.lib c:\\saturn\\segalib\\lib\\libcdc.lib c:\\saturn\\segalib\\lib\\libdma.lib c:\\saturn\\segalib\\lib\\libcsh.lib c:\\saturn\\segalib\\lib\\libsnd.liblibIguan.lib (Iguana Entertainment custom library)The Sega Saturn version of the game has a reference to a library file created by Iguana Entertainment (the developers of the port) called c:\\\\igsatlib\\\\libiguan.lib, it has the following symbols: Symbol Notes __SinCosP_D   byteMemcpy   DefaultHBLInterrupt   DMAListPtrs   EndOfDrawInterrupt   FreeDMAListPtrs   FuckTheSlavedd   ie_AddBitmap   ie_AddDeComp   ie_AddGlobalParticleBitmap   ie_AddGouraudPolygon   ie_AddGouraudSprite   ie_AddGouraudTexturePolygon   ie_AddLevelBitmap   ie_AddLevelParticleBitmap   ie_AddLinep   ie_AddNormalSprite   ie_AddPolygon   ie_AddPolyline   ie_AddScaleSprite   ie_AddSprite   ie_AddTexturePolygon   ie_AddToFrontPolygon_B   ie_AddToFrontScaleSprite   ie_AddToFrontTexturePolygon   ie_AddToList   ie_AllocateBitmap   ie_AppendNode   ie_ChecksumBattery   ie_ClearVDP1CmdLists   ie_CopyDMA   ie_CopyVDP1CmdListh   ie_CopyVDP1CmdListhie_AddLevelBitmap   ie_DecodePad   ie_DeleteFromList   ie_EmptyDMAList   ie_FlushDeCompList   ie_FlushDMAList   ie_InitHardware   ie_InitializeBitmapList   ie_InitializeBookKeepingVars   ie_InitializeDeComp   ie_InitializeDMA   ie_InitializeEngine   ie_InitializeList   ie_InitInterrupts   ie_InitSound   ie_InitVDP1CmdList   ie_InsertAfter   ie_InsertBeforeiddH   ie_LoadFromBattery   ie_ParallelOut   ie_PlaySound   ie_PrependNode   ie_Random   ie_RandomRange   ie_RandomRange32   ie_RandomUnsignedRange   ie_ReadCreditStatus   ie_RemoveNode   ie_RequestStart5   ie_ResetSystemClipping   ie_ResetUserClipping   ie_ReturnPlayerCreditStatusl_B   ie_SaveToBattery   ie_SetBatteryChecksumB   ie_SetStartContinue   ie_SetSystemClippingob   ie_SetupSlaveList   ie_SetUser   ie_UpdateBookKeeping   ie_WaitVBL   InitDMA   InitializeListd   LongCopyobL   longMemcpy   ProductAP_   SetupHBL   SlaveDecomp   SMPA_SwInit   uncrunchtbl   UpdatePlayerBookKeepingz   VBLInInterrupt V-Blank Interrupt VBLInUserFunction   VBLOutInterruptAP_   VBLOutUserFunctiond   wordMemcpy   ie_DecodeRLE   Sega Saturn Memory SymbolsThe table below lists the relevant entries. Address Symbol Notes 060FC770 FEATHER2_Stats   060FC7CC FEATHER2_AIScript   060FC7F8 FEATHER2_InfoTable   060FC808 FEATHER3_ComboSet1   060FC818 FEATHER3_ComboSet2   060FC828 FEATHER3_ComboSet3   060FC838 FEATHER3_ComboSet4   060FC848 FEATHER3_ComboSet5   060FC858 FEATHER3_ComboSet6   060FC868 FEATHER3_ComboSet7   060FC878 FEATHER3_Stats   060FC8D4 FEATHER3_AIScript   060FC928 FEATHER3_InfoTable   060FC938 FeatherBoundBoxes   060FC954 FeatherModeTable   060FCC94 GuesserBitList   060FCD44 ExplodeGuesserOffsetScript   060FCD78 GuesserHeadBox   060FD014 FeatherAngles   060FD02C FeatherAttackBox   060F8??? SabSetupPUNCHA   060F871E SabSetupPUNCHB   060F8728 SugarSetupEXITKISS   060F8728 SabCodePUNCH   060F8732 SugarCodeEXITKISS   060F873C TassleHitPlayer   060F8750 SugarHitPlayer   060F875C SabSetupTHROWBOMBWAIT   060F876C TwoFaceSetupCOMBO   060F87C8 TwoFaceEvilSetupSHOOTGUN   060F87E4 SabCodeTHROWBOMBWAIT   060F880C SabSetupTHROWBOMB   060F8838 SabCodeTHROWBOMB   060F883C TwoFaceEvilCodeSHOOTGUN   060F88E8 TwoFaceEvilSetupEXITSHOOTGUN   060F88F2 TwoFaceEvilCodeEXITSHOOTGUN   060F890C EnemyFire_DrawLips   060F8910 TwoFaceEvilSetupVERTKNIFESLASH   060F8924 EnemyFire_UpdateLips   060F8940 TwoFaceEvilCodeVERTKNIFESLASH   060F89BC TASSLE_C1_PunchA   060F89C6 TASSLE_C1_PunchB   060F89D0 TASSLE_C1_KickA   060F89D8 SabSetupPLACEBOMB   060F89DA TASSLE_C1_JumpKick   060F89E4 TASSLE_C1_SpinKick   060F89EE TASSLE_C2_DoublePunch   060F89F8 TASSLE_C2_PunchAThenB   060F8A04 TASSLE_C2_DoubleKick   060F8A04 SabCodePLACEBOMB   060F8A0E TASSLE_C2_KickAndSpin   060F8A1A TASSLE_C3_DPunchSpinKick   060F8A26 TASSLE_C3_DPunchAndKick   060F8A32 TASSLE_C3_DKickSpin   060F8A40 TASSLE_C3_DKickJump   060F8A4E TASSLE_C3_JagoJump   060F8A54 TwoFaceEvilSetupHORIZKNIFESLASH   060F8A5C TASSLE_C4_DDPunch   060F8A68 TASSLE_C4_PunchEnd   060F8A76 TASSLE_C4_SpinKicks   060F8A84 TwoFaceEvilCodeHORIZKNIFESLASH   060F8A86 TASSLE_C4_JumpKickEnd   060F8A96 TASSLE_C5_SpinPunchEnd   060F8AA4 TASSLE_C5_JumpKickEnd   060F8AB6 TASSLE_C6_MadPunch   060F8ACA TASSLE_C6_SpinKicksCity   060F8ADA TASSLE_C10_NeillsCombo   060F8AF2 TASSLE_SFX_BatmanBlockRetal   060F8B04 TASSLE_SFX_RobinBlockRetal   060F8B04 SabSetupTRIPLEROUNDHOUSE   060F8B16 TASSLE_SFX_BatmanTaunt   060F8B30 SabCodeTRIPLEROUNDHOUSE   060F8B34 TASSLE_SFX_RobinTaunt   060F8B52 TASSLE_SFX_EndOfBeingComboedByBatman   060F8B6A TASSLE_SFX_EndOfBeingComboedByRobin   060F8B82 TASSLE_SFX_EndOfComboingPlayer   060F8B94 Tassle1FxPalette   060F8B98 TwoFaceGoodSetupDOUBLEGUNSHOOT   060F8BA4 Tassle2FxPalette   060F8BB4 TassleSetupTable   060F8BE8 TASSLE_Combo1   060F8BF6 TASSLE_Combo2   060F8C0C TwoFaceGoodCodeDOUBLEGUNSHOOT   060F8C0C TASSLE_Combo3   060F8C26 TASSLE_Combo4   060F8C3E TASSLE_Combo5   060F8C5C TASSLE_ComboSet1   060F8C68 SabHitPlayer   060F8C6C TASSLE_ComboSet2   060F8C7C TASSLE_ComboSet3   060F8C8C TASSLE_ComboSet4   060F8C9C TASSLE_ComboSet5   060F8CA8 EnemyFire_LipsHitPlayer   060F8CAC TASSLE1_Stats   060F8CB8 TwoFaceGoodSetupEXITDOUBLEGUNSHOOT   060F8CC2 TwoFaceGoodCodeEXITDOUBLEGUNSHOOT   060F8CE0 TwoFaceGoodSetupTHROWKNIFE   060F8D08 TASSLE1_AIScript   060F8D34 TwoFaceGoodCodeTHROWKNIFE   060F8D50 StartLips   060F8D60 TASSLE1_InfoTable   060F8D70 TASSLE2_Combo1   060F8D7E TASSLE2_Combo2   060F8D94 TASSLE2_Combo3   060F8DAE TASSLE2_Combo4   060F8DB4 TwoFaceGoodSetupKNIFELUNGE   060F8DC6 TASSLE2_Combo5   060F8DE4 TwoFaceGoodCodeKNIFELUNGE   060F8DE4 TASSLE2_ComboSet1   060F8DF4 TASSLE2_ComboSet2   060F8E04 TASSLE2_ComboSet3   060F8E14 TASSLE2_ComboSet4   060F8E24 TASSLE2_ComboSet5   060F8E34 TASSLE2_Stats   060F8E74 SAB_C1_PunchAndRoundHouse   060F8E90 TASSLE2_AIScript   060F8E90 SAB_C1_PunchA   060F8E9A SAB_C1_PunchB   060F8EA4 SAB_C1_ThrowBomb   060F8EAE SAB_C1_PlaceBomb   060F8EB8 SAB_C1_TripleRoundHouse   060F8EC2 SAB_C2_Punches   060F8ECE SAB_C3_Punches   060F8EDC SAB_C4_Punches   060F8EE8 TASSLE2_InfoTable   060F8EEC SAB_C5_Punches   060F8EF8 TwoFaceHitPlayer   060F8EF8 TassleBoundBoxes   060F8EFE SAB_C6_Punches   060F8F12 SAB_SFX_BlockRetal   060F8F14 TassleModeTable   060F8F2C Sab1FxPalette   060F8F3C Sab2FxPalette   060F8F4C Sab3FxPalette   060F8F5C SabSetupTable   060F8F60 SugarBlkPrpFxPalette   060F8F70 SugarBlkRdPrpFxPalette   060F8F80 SugarBluBlkFxPalette   060F8F90 SugarChrmPrpFxPalette   060F8F90 SAB1_ComboSet2   060F8FA0 SugarGrnYloFxPalette   060F8FA0 SAB1_ComboSet3   060F8FB0 SugarRedBlkFxPalette   060F8FB0 SAB1_ComboSet4   060F8FC0 SugarUVFxPalette   060F8FC0 SAB1_ComboSet9   060F8FD0 SugarWhtRedFxPalette   060F8FD0 SAB1_Stats   060F8FE0 NewSugarFxPalette   060F8FF0 SUGAR_C1_SingleSlap   060F8FFE SUGAR_C1_MultiSlap   060F900C SUGAR_C1_SpinKick   060F901C SUGAR_C1_Mace   060F9028 SUGAR_C1_Kiss   060F902C SAB1_AIScript   060F9042 SUGAR_C1_FastKiss   060F905A SUGAR_SFX_BatmanBlockRetal   060F9060 SAB1_InfoTable   060F906C SUGAR_SFX_RobinBlockRetal   060F9070 SAB2_ComboSet1   060F907E SUGAR_SFX_BatmanTaunt   060F9080 SAB2_ComboSet3   060F908C SetupBazookaMissile   060F9090 SAB2_ComboSet4   060F9096 SUGAR_SFX_RobinTaunt   060F9098 BazookaMissileCodeFIRE   060F90A0 SAB2_ComboSet9   060F90AE SUGAR_SFX_EndOfBeingComboedByBatman   060F90B0 SAB2_Stats   060F90CC SUGAR_SFX_EndOfBeingComboedByRobin   060F90EA SUGAR_SFX_EndOfComboingBatman   060F9102 SUGAR_SFX_EndOfComboingRobin   060F910C SAB2_AIScript   060F911C SugarSetupTable   060F9150 SUGAR1_ComboSet1   060F9154 SAB2_InfoTable   060F9160 SUGAR1_ComboSet2   060F9164 SAB3_ComboSet1   060F9170 SUGAR1_Stats   060F9174 SAB3_ComboSet2   060F9184 SAB3_ComboSet3   060F9194 SAB3_ComboSet4   060F91A4 SAB3_ComboSet9   060F91B4 SAB3_Stats   060F91CC SUGAR1_AIScript   060F91D0 SubwayTwoFacePosition   060F91E4 SUGAR1_InfoTable   060F91F4 SUGAR2_ComboSet1   060F9204 SUGAR2_ComboSet2   060F9210 SAB3_AIScript   060F9214 SUGAR2_ComboSet3   060F9218 SetupSubwayLTwoFace   060F9224 SUGAR2_Stats   060F9248 SetupSubwayRTwoFace   060F9264 SAB3_InfoTable   060F9274 SubwayTwoFaceCodeSLIDEON   060F9274 SabBoundBoxes   060F9280 SUGAR2_AIScript   060F9290 SabModeTable   060F92A0 SUGAR2_InfoTable   060F92B0 SUGAR3_ComboSet1   060F92B8 SubwayTwoFaceCodeFIRE   060F92C0 SUGAR3_ComboSet2   060F92D0 SUGAR3_ComboSet3   060F92E0 SUGAR3_ComboSet4   060F92F0 SUGAR3_Stats   060F934C SUGAR3_AIScript   060F9378 SUGAR3_InfoTable   060F9388 SUGAR4_ComboSet1   060F9398 SUGAR4_ComboSet2   060F93A8 SUGAR4_ComboSet3   060F93B8 SUGAR4_ComboSet4   060F93C8 SUGAR4_ComboSet5   060F93D8 SUGAR4_ComboSet6   060F93E8 SUGAR4_Stats   060F9418 SubwayTwoFaceCodeLAUGH   060F9444 SUGAR4_AIScript   060F9454 SubwayTwoFaceCodeEXITLAUGH   060F947C SubwayTwoFaceCodeSLIDEOFF   060F947C SUGAR4_InfoTable   060F948C SugarBoundBoxes   060F94A8 SugarModeTable   060F94BC SubwayTwoFaceCodeFALL   060F94EC TwoFace1FxPalette   060F94FC TwoFaceFlinchSounds   060F9508 TwoFaceSetupTable   060F953C TWOFACE_C_GunAttack   060F9558 TWOFACE_C_KnifeAttack   060F958C TWOFACE_ComboSet1   060F959C TWOFACE_ComboSet2   060F95AC TWOFACE_SFX_Taunt   060F95C4 TWOFACE_SFX_EndOfComboingPlayers   060F95E4 TWOFACE_Stats   060F9640 TWOFACE_AIScript   060F965C TWOFACE_InfoTable   060F966C TwoFaceBoundBoxes   060F9688 TwoFaceEvilModeTable   060F9A78 LipsAttackBox   060F9D18 TwoFaceGoodModeTable   060FA3A8 BazookaMissileFIREFrame   060FA3C0 BazookaMissileModeTable   060FA3D0 SubwayTwoFaceBoundBoxes   060FA3EC SubwayTwoFaceSLIDEONFrame   060FA404 SubwayTwoFaceFIREFrame   060FA4A0 SubwayTwoFaceLAUGHFrame   060FA4F4 SubwayTwoFaceEXITLAUGHFrame   060FA524 SubwayTwoFaceSLIDEOFFFrame   060FA53C SubwayTwoFaceFALLFrame   060FA5B4 SubwayTwoFaceModeTable   060FA618 GuesserFlinchFunction   060FA618 FeatherFlinchFunction   060FA618 AlthugFlinchFunction   060FA620 SetupAlthug   060FA620 DrawFeather   060FA628 UpdateGuesser   060FA62C AlThugSetupBLOCK   060FA64C DrawAlthugChain   060FA654 ClipFeather   060FA664 FeatherBlockLoFunction   060FA694 UpdateFeather   060FA6E0 AnimateFeather   060FA744 SetupFeather   060FA770 DrawGuesser   060FA7EC FeatherCheckForBlock   060FA8CC FeatherSetupTOBLOCK   060FA90C FeatherCodeTOBLOCK   060FA928 FeatherSetupBLOCK   060FA932 FeatherCodeBLOCK   060FA94E FeatherSetupGETUP   060FA96C FeatherSetupTHROWFEATHERS   060FA9A4 DrawAlthugChainToPlayer   060FAA00 FeatherCodeTHROWFEATHERS   060FAA4C AnimateGuesser   060FAAA4 SetupGuesser   060FAAF4 GuesserCodeWALK   060FAAF8 DrawAlthug   060FAB50 GuesserCodeFLINCH   060FAB64 GuesserHitByPlayerOnGrapple   060FAB98 GuesserCodeEXPLODE   060FABBE UpdateGuesserParticle   060FAC10 FeatherSetupTOSPINSTICKIDLE   060FAC7C FeatherCodeTOSPINSTICKIDLE   060FACA0 FeatherSetupSPINSTICKIDLE   060FACB4 DrawPulledAlthug   060FACD8 FeatherCodeSPINSTICKIDLE   060FACF8 FeatherCodeEXITSPINSTICK   060FAD1C GuesserSetupEXPLODE   060FAD20 FeatherSetupTOLAUNCHSTICK   060FAD50 FeatherCodeLAUNCHSPINSTICK   060FAD70 FeatherSetupLAUNCHSTICK   060FAD7A FeatherCodeLAUNCHSTICK   060FADA0 FeatherSetupGETSTICKBACK   060FADC4 FeatherCodeGETSTICKBACK   060FADE0 FeatherSetupHANDSLAP   060FADEC AlThugSetupPUNCHA   060FADF6 AlThugCodePUNCHA   060FAE04 FeatherCodeHANDSLAP   060FAE14 AlThugSetupHEADBUTT   060FAE24 AlThugCodeHEADBUTT   060FAE70 FeatherSetupSLIDESLAP   060FAE8C AlThugSetupKICKA   060FAE96 AlThugCodeKICKA   060FAE9C FeatherCodeSLIDESLAP   060FAEB4 AlThugSetupDSPINKICK   060FAEDC AlThugCodeDSPINKICK   060FAF54 AlThugSetupTOCHAIN   060FAFC8 GuesserSetupLAUNCHFIST   060FAFCC FeatherSetupEXITSLIDESLAP   060FAFF0 FeatherCodeEXITSLIDESLAP   060FB00C FeatherSetupELBOWSLAM   060FB014 GuesserSetupELECLAUNCHFIST   060FB030 GuesserSetupGRABLAUNCHFIST   060FB030 FeatherCodeELBOWSLAM   060FB04C GuesserCodeLAUNCHFIST   060FB04C FeatherSetupELBOWSLAMFLY   060FB064 AlThugCodeSWINGCHAIN   060FB070 GuesserSetupFIREFISTOUT   060FB086 GuesserSetupELECFIREFISTOUT   060FB0A0 GuesserSetupGRABFIREFISTOUT   060FB0BC GuesserCodeFIREFISTOUT   060FB10C FeatherCodeELBOWSLAMFLY   060FB124 GuesserCodeGETFISTBACK   060FB150 FeatherSetupELBOWSLAMLAND   060FB1C8 FeatherCodeELBOWSLAMLAND   060FB220 GuesserSetupEXITLAUNCHFIST   060FB220 AlThugSetupTHROWCHAIN   060FB22A GuesserCodeEXITLAUNCHFIST   060FB248 GuesserSetupELECPLAYER   060FB250 FeatherSetupEXITELBOWSLAM   060FB25A GuesserCodeELECPLAYER   060FB26C FeatherCodeEXITELBOWSLAM   060FB288 FeatherSetupSWINGSTICK   060FB292 FeatherCodeSWINGSTICK   060FB2B0 FeatherSetupPREPAREFLIP   060FB2D4 FeatherCodePREPAREFLIP   060FB2F0 FeatherSetupFLIP   060FB314 AlThugCodeTHROWCHAIN   060FB340 FeatherCodeFLIP   060FB350 GuesserSetupPUNCHA   060FB360 FeatherSetupFLIPLAND   060FB368 GuesserSetupPUNCHB   060FB36A FeatherCodeFLIPLAND   060FB380 GuesserCodePUNCH   060FB388 FeatherSetupPREPARECARJUMP   060FB3AC PopGuesserHeadOff   060FB3AC FeatherCodePREPARECARJUMP   060FB3C8 FeatherSetupCARJUMP   060FB3F8 AlThugCodeEXITCHAIN   060FB400 GuesserSetupHEADPOP   060FB414 AlThugSetupPLAYERPULLCHAIN   060FB424 DrawGuesserHead   060FB428 FeatherCodeCARJUMP   060FB448 FeatherSetupCARJUMPLAND   060FB452 FeatherCodeCARJUMPLAND   060FB454 GuesserCodeHEADPOP   060FB470 FeatherHitPlayer   060FB488 AlThugCodePLAYERPULLCHAIN   060FB574 GuesserSetupNOHEADIDLE   060FB586 GuesserCodeNOHEADIDLE   060FB5A4 AlthugGrabbedPlayerChecks   060FB5A8 GuesserCodeTORNADOIN   060FB5C4 GuesserSetupTORNADO   060FB618 AlThugSetupRUSH   Game ProgrammersThe list of programmers credited for both the Playstaion and Saturn port of Batman is quite short: Carl Wade (Lead Programmer & Tools Programmer) Stephen Broumley (Lead Programmer & Tools Programmer) Craig Galley (Tools Programmer) David Crummack (Presentation) Richard Cowie (Riddler Control Room)Sadly Carl Wade passed away in 2011 at the young age of 40, a fond memory of him by his friend and co-worker Stephen Broumley was a function he added to batman called TheWholeKitAndCaboodle when the player completed the game 2.It just goes to show the importance of preserving the development of these games, just like all art it is an outlet for the creators to show off their unique personalities and humour.PS1 VersionThe PS1 version has no references to “PSYQ” at all and all the file extensions are completely different, so it looks like a rewrite of the game rather than a port.The main game executable SLES_005.25 contains 318 functions when disassembling.MS-DOS VersionContains a few different executables: BM1.EXE (2677 functions) - Main game? DOS4GW.EXE - DOS memory extender FRONTEND.EXE - Batman Menu? (780 functions) I.EXE - Game InstallerNote for FrontEnd.exe you need to set IDA Pro to MS-DOS executable (Not the default LinearExecutable and Pentium 4 processor). But for BM1.EXE stick to LinearExecutable.References Batman Forever sega st-v cart. by Acclaim Coin-Operated Ent., Inc. (1996) ↩ Gamasutra - Obituary: Game Programming Veteran Carl Wade ↩ ", "excerpt": "As the name suggests Batman Forever is originally an Arcade Game that got ported to MS-DOS, the Playstation 1 and Sega Saturn by Iguana Entertainment (Acclaim Published). The original arcade release was for the ST-V (Sega Titan Video Game System) arcade hardware which is what would eventually become the foundation...", "tags": ["saturn","sega","ps1","games"], "image": "https://i.ytimg.com/vi/WWz2nScv22g/hqdefault.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Bookazines (Games Industry)", "url": "/bookazines", "content": "What do you call a product that collects articles from monthly magazines into a single yearly publication? The publishers came up with the term “Bookazine” to cover this concept of a very large magazine related to a specific topic.Many of these were published with topics related to the Games Industry such as 3D Modelling, Animation, Photoshop, Programming or even just Games themselves.Programming BookazinesThe table below lists the relevant entries. Title Publisher Notes Coding Academy 2016 Future Publishing   Coding for Kids Scratch Dennis Publishing   The Hackers Manual 2012 Future Publishing Contains articles from Linux Format The Hackers Manual 2016 Future Publishing   The Python Book Future Publishing   The Responsive Web Design Handbook Future Publishing   The Ultimate Guide to Web Design Future Publishing   The Ultimate Python Coding Manual Papercut Limited   The Web Design Annual Future Publishing   The Web Design Book Future Publishing   Web Design Tips, Tricks & Fixes Future Publishing   Web Design For Beginners Future Publishing   You can make an App Future Publishing   Gaming BookazinesBookazines dedicated just to gaming also exist and can contain some articles relavent to Game Development and the history of the industry as a whole. Title Publisher Notes 100 Games to Play before you Die Future Publishing Articles from Retro Gamer magazine EDGE File Volume 1-3 Future Publishing Articles from the first 36 issues of EDGE Magazine (2006-2007) Ninteno Archives Future Publishing   Retro Gamer Collection Future Publishing At least 7 Volumes Retro Micro Games Action Imagine Publishing, Future Publishing At least 10 Volumes from GamesTM Retro sections SEGA Archives Future Publishing   SNES The Complete Manual Future Publishing   The Atari Book Future Publishing At least 2 editions available, Articles from Retro Gamer magazine The Book of Mario Future Publishing Articles from Retro Gamer magazine The N64 Book Future Publishing   The NES Book Future Publishing Articles from Retro Gamer magazine The Playstation Book Future Publishing   The Ultimate Guide to indie Games Future Publishing Contains articles from PC Gamer Magazine The ZX Spectrum Book Future Publishing Articles from Retro Gamer magazine Videogames Hardware Handbook Future Publishing Articles from Retro Gamer magazine Retro Micro Games ActionThe UK Magazine GamesTM had a section dedicated to retro games every month, while it was only a small part of the magazine it had a wealth of interesting information, especially interesting for the topic of this site is the interviews with developers. While its sister magazine Retro Gamer focussed on much earlier retro gaming, the Retro section of GamesTM would go all the way up to PS2 and even PS3!There were 10 volumes published from 2011 until 2021.Behind The ScenesThe table below lists the relevant entries. Game Platform Issue # Notes Robotron: 2084 Arcade 2 Interview with Eugene Jarvis Shadow of the Beast Amiga 2   Xybots Arcade 2   MDK DOS, Windows and PS1 9   Icewind Dale   9   System Shock 2   9   Duke Nukem 64   9   Star Trek Voyager Elite Force   9   Ghostbusters 2   9   InterviewsThe table below lists the relevant entries. Name Company Issue Notes Steve Turner Graftgold co-founder 1 Apparently SEGA systems used the same assemblers as the Amiga?! Maybe custom devkit? Raff Cecco   2 Spectrum games such as Cybernoid, Stormlord Geoff Crammond Firebird, Microprose 2 BBC Micro titles such as Aviator, C64, AMIGA, ATARI ST and PC David Braben Frontier Developments 2   Ben Daglish W.E.M.U.S.I.C. 2 Musician for games such as The Last Ninja The Pickford Brothers Zippo, Rare Manchester, Software Creations 2 Worked on Wetrix for N64, Solstice 2 for NES and many many more David Anderson Platinum Productions 2 Worked on tons of Spectrum conversions! Tom Kalinske CEO SEGA of America 9   Jas Austin   9   Ninh Le   9   Dave Grossman   9   Stuart Copeland   9   Tom Kalinske InterviewOne of the most interesting interviews is with former SEGA of America CEO Tom Kalinske who was in charge when EA reverse-engineered the Sega Mega Drive. He was furious and famously said: “Trip [Hawkins], didn’t your mother ever teach you the difference between right and wrong?”This may have got the meeting off to a rough start but in the end SEGA got John Madden football and EA got favoured licensing rights.Pickford Brothers InterviewThe interview with the Pickford Brothers was also fascinating and mentioned that they were one of the first studios to get NES development kits outside of Japan and one of the first Game Boy developers outside of Japan. I wonder which development kits they were given for NES and Game Boy… it would have been great to ask them more details about the development kits.They also managed to play around with one of the first SNES development kits in Europe when they worked at Software Creations. It would have been great to ask them what they remember about these development kits!Digital Art BookazinesThe table below lists the relevant entries. Title Publisher Notes 3D Art & Design Imagine Publishing From the makers of 3D Artist, 2010-2011, replaced by “The 3D Art & Design Book” Flash Essentials Future Publishing Articles from .net magazine Get Started in 3D Future Publishing Articles from 3D World magazine (2014-2021) Illustrate with Photoshop Genius Guide Future Publishing At least 6 editions ImagineFX Annual Future Publishing   The 3D Art & Design Annual Imagine Publishing & Future Publishing (from 2017) From the makers of: 3D Artist, 6 known volumes available The 3D Art & Design Book Imagine Publishing From 2012 to 2014) it replaces 3D “Art & Design” and is further replaced by “The 3D Art & Design Annual” The Sci-fi & Fantasy Art Book Future Publishing at least 4 editions published The Ultimate Guide to Graphic Design Dennis Publishing contains articles from MacUser magazine Get Started in 3D (2014-2021)First published in 2014 by Future this Bookazine has been republished at least 4 times with almost identical content. It contains 180 pages of pure content with no Advertisements, honestly if you can find a copy in your local newsagents then I would reccomend picking it up as it is well worth the money.Contents of Get Started in 3DThe Bookazine is split into the following sections: Showcase - Shows off 10 fantastic pieces of 3D Art Fundamentals - 19 Articles by Mike Griggs Theory - 5 Articles on theory by Denis Kozlov Tutorials - 14 articles written for specific softwareShowcaseThe table below shows the pieces features in the Bookazine along with their artists and the software used to create them. Name of Piece Artist Name Software used Dog Caetano Silva ZBrush, Modo, Cinema 4D, Photoshop Hades, God Of The Underworld Elena Bespalova Maya, ZBrush, Keyshot Deathstroke’s Revenge Alessandro Baldasseroni 3ds Max, ZBrush, Mudbox, V-Ray, Photoshop Miyamoto Chu With His Super Car Hsun-Chun Chuang Maya, mental ray, Photoshop, After Effects Cybernetic Organism Artemis AA 3057 Sengjoon Song Maya, Mari, Photoshop, nDo, Headus UVLayout, V-Ray BingBing Nianzu Zhang 3ds Max 2012, ZBrush, Photoshop, mental ray, Hairfarm Red-eyed Tree Frog Gordon Goane ZBrush, Maya, TopoGun, KeyShot, Photoshop Baby Rock 2.0 - Alessio Rossi Alessio Rossi 3ds Max, V-Ray, Mudbox, Photoshop Valhalla Rudolf Herczog Cinema 4D, Maxwell Render, Photoshop The Pirate Pietro Licini Maya, ZBrush, Mudbox, Arnold, Photoshop FundamentalsThe Fundamentals section is a series of 19 articles all written by Mike Griggs and previously featured in the monthly 3D World Magazine, the table below lists the articles along with the original magazine they were featured in (if known). Name Tag Line Original Issue MODELS FOR GAME ENGINES Learn core skills with this easy introduction Issue 177 (Jan 2014) TRIMMING POLYS Removing unnecessary polys is key for workflow Issue 169 (June 2013) MESH SMOOTHING Smoothing is an essential basic for modellers Issue 175 (December 2013) UV MAPS The basics of using UV maps Issue 171 (August 2013) LEARN HOW TO USE RIGGING An essential skill for animation   UNDERSTAND RIGID DYNAMICS Physics-based dynamics explained   UNDERSTAND SOFT DYNAMICS Use these to create movement in your scenes   UNDERSTAND YOUR CAMERA Create realistic viewpoints by looking down a lens Issue 179 (March 2014) USING HDR TO LIGHT SCENES Use image-based lighting to maximum effect Issue 170 (July 2013) HAIR AND FUR Learn how to bring hair and fur to life Issue 174 (November 2013) GREAT CREATURE DESIGN Key steps for cracking creatures Issue 167 (April 2013) METAL SURFACES What you need to know to render metal surfaces   TILED TEXTURES Discover seamless textures for improved workflow Issue 166 (March 2013) INSTANCING Control objects with intelligent cloning Issue 173 (October 2013) URBAN ENVIRONMENTS Design realistic cities in no time Issue 178 (Feb 2014) STUNNING SIMULATIONS Explore the features and uses of particle effects   FLUID DYNAMICS Understand fluid dynamics systems   SUB-SURFACE SCATTERING Create convincing interactions with this technique Issue 172 (September 2013) MEDICAL GRAPHICS This niche world can really influence your work   TheoryThe Theory section contains an in-depth look at the theoretical concepts that make 3D graphics work, all written by Denis Kozlov. Name Tag Line Original issue VIRTUAL LENSES Create faultless renders with virtual lenses   PIXEL PERSPECTIVE Think of pixels as data and not colours   PARTICLE SYSTEMS: PART 1 Part one of two looking at particle systems   PARTICLE SYSTEMS: PART 2 Further advice on particle systems   DEPTH OF COLOUR The basics of colour depth of raster images   TutorialsThe Tutorials section contains 14 articles written for specific software such as 3ds Max, Photoshop and ZBrush. The later editions have replaced some of the older tutorials with newer tutorials from the 3DWorld magazine, the table below contains both the older and newer content found in the first three editions. Name Tag Line Author Original issue ANATOMY: PART 1 Sculpting the torso Dan Crossland   ANATOMY: PART 2 Sculpting the masses Dan Crossland   ANATOMY: PART 3 Sculpting the muscles Dan Crossland   ANATOMY: PART 4 Creating a master model Dan Crossland   HANDS Detailed hands in ZBrush Titouan Olive   UNWRAPPING UVS Master this core skill Rob Redman   BIG SCREEN CREATURES Cinematic creatures in 10 easy steps Tyler Bolyard   LIGHT AND TEXTURE Apply texture and light to a complex character Daniele Scerra   RIG-READY CREATURES Get to grips with retopology tools Adam Dewhirst   CHARACTER CONCEPTS Successful character concepts in 15 stages Dan Mason   12 CAR RENDER TIPS Use 3ds Max and V-Ray for perfect car rendering Dave Cox Issue 170 (July 2013) SCI-FI RACING Create futurist racing machines in 3ds Max 2015 Al Brady   REALISTIC ENVIRONMENTS Build your own cityscape in fantastic detail (3ds max, photoshop) Anthony Eftekhari   PHOTOSHOP TEXTURES 10 top tips for better textures in Photoshop Leigh van der Byl Issue 167 (April 2013) Model Characters Design and Model a Video Game Character Marat “Flamm” Latypov Issue 229 (Jan 2018) ArtStation - ReY Shoot Like You Mean It A primer of Film Grammar Dora R. Fitzgerald Issue 231 (March 2018) Q&AThe Questions and Answers section contains 6 of the most popular Q&A sections from the monthly magazine. Name Tag Line Original Issue QUESTIONS AND ANSWERS 1 Your problems solved by our experts   QUESTIONS AND ANSWERS 2 More 3D problems solved   QUESTIONS AND ANSWERS 3 Modelling dinosaurs and more!   QUESTIONS AND ANSWERS 4 Includes a mech design masterclass   QUESTIONS AND ANSWERS 5 Global illumination in C4D and more   QUESTIONS AND ANSWERS 6 Includes how to create realistic materials   PORTFOLIOS The pro’s guide to building a better portfolio by Andrew Gordon   PUT YOURSELF IN THE FRAME Follow these tips to land your dream job by Ian Dean   ", "excerpt": "What do you call a product that collects articles from monthly magazines into a single yearly publication? The publishers came up with the term “Bookazine” to cover this concept of a very large magazine related to a specific topic. Many of these were published with topics related to the Games...", "tags": ["bookazines","magazines","books","industry"], "image": "/public/images/categories/Games Industry Bookazines.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Books (Games Industry)", "url": "/books", "content": "One of the best ways to get an insight into the games industry is to look at the books that were available to developers at the time, both game-specific books, programming books and digital/creative books have a wealth of information.As this is a site about retro games, we are mainly aiming to add books that were published around the time of retro consoles or books about retro game development.This page is split into the following categories: Books published around the same time as retro games Books about Retro Game Development with Modern ToolsBooks published around the same time as retro gamesThis section will cover books available at the time when retro games were being created, for added context this section is broken down by year.The list of books in this section is not an exhaustive list and mainly includes books that would have been notable at the time. We only list the book based on its first edition date in order to keep the lists a bit cleaner.Notable PublishersSome of the most note-worthy publishers for game development related books on this list are: A. K. Peters Ltd - Textbooks related to Computer Graphics and ran from 1992 to 2010 before being bought by CRC Press CRC Press - Started Game development books in 2003 and still running until present day Charles River Media - Game Development series ran from 2002 to 2009 Jones and Bartlett Publishers - Books on C++ from 2001 then bought Wordware in 2008 and started Game development books such as the Game Engine gems series Morgan Kaufmann - The Morgan Kaufmann Series in Computer Graphics ran from 1989-2018 New Riders Games (NRG) - From 2003 to 2014 Premier Press - From 2001 until they became Thomson Course Technology PTR in October 2003 1 Prima Tech2 - Becomes Premier Press in 2001 3 Sams - Famous for the Sams teach yourself series but not many game specific books (1988-Present) Thomson Course Technology PTR - Becomes Cengage Learning in July 2007 Waite Group Press - Published the Black art of game programming series of books and early books on 3D graphics 4 Wordware Game Developer’s Library - From 1999 to 2009 (Becomes Jones and Bartlett Publishers)Notable AuthorsSome of the most prolific authors in the game development genre are: Andre LaMothe - Celebrated author and editor for the entire Prima Tech/Premier Press Game Development Book Series. Jonathan S. Harbour - Authored over 20 programming books. Worked on the Sega Mega Drive version of “Wayne Gretzky Hockey” using a scripting language and Motorola 68K Assembly Language. Mark DeLoura - Author of the first two Game Programming Gems books (along with the Best of version) and editor of Game Developer magazine. Steve Rabin - Specializes in Game AI books such as the Game AI Wisdom series. Wolfgang Engel - Specializes in game graphics, specifically shader development, writing books such as the ShaderX series.Notable SeriesSome publishers will group related books into a series which makes it easier to find titles that are of interest to a particular field. Some of the notable series of books include: Advances in computer graphics and game development by Charles River Media contained books on game programming Graphics series by Charles River Media contained books on 3D software such as Maya and Lightwave Programming Series by Charles River Media contained books on more general programming and AIGame Programming Starter KitWe have a separate post on the excellent “Game Programming Starter Kit” series. It was a very successful way to provide professional PC development software along with industry-standard books to amateur developers. It even included Visual Studio and, later on, some other software such as Dark Basic. Game Programming Starter Kit For more information about the Game Programming Starter Kit series check out this post. Published in 1976This section will cover books related to game development published in the year 1976, the year when the home game console market was just starting to take off with the release of the Channel F. It was also the year that Zilog would launch their Z80 microchip which would be used in many consoles and home computers in the future. Cover Title Author Software Notes F8 Guide to Programming Fairchild F8 Assembly Official guide to programming the F8 cpu used in the Fairchild Channel F Zilog Z80-CPU Technical Manual Zilog Z80 Assembly   Fairchild Channel F This was the year the Fairchild Channel F was released, the first ever games console with interchangeable cartridges (ROMs) and the first to be based on a microprocessor (Fairchild F8). Fairchild released a development kit which came with a book titled F8 Guide to Programming, if you were a developer at the time who wanted to write games for the Channel F then this would be the go-to book! Zilog Z80 We start with the Z80-CPU Technical Manual from Zilog as it was used in so many early games consoles and home computers, it was very likely that you would have an iteration of this book if you were a developer for any of the following: Game Boy Master System/Game Gear AmstradCPC MSX ZX Spectrum. Of course by the time those consoles came out there were newer editions of the book and a few people had written their own Z80 textbooks but it remains a very important book int he history of game development. Published in 1978This section will cover books related to game development published in the year 1978.The Apple II and Atari 2600 VCS had just been released in the previous year (September 1977) which was using a variant of the popular 6502 CPU (6507) and books were starting to spring up on the topic of programming for this family of chips. Cover Title Author Software Notes Programming the 6502 Zaks, Rodnay     The C programming language Brian W. Kernighan, Dennis M. Ritchie C Programming   The Z-80 Microcomputer Handbook William J. Barden     The book Programming the 6502 was perfect for any new programmers who wanted to tap into the full potential of their Apple II or Atari 2600 as it introduced basic programming concepts and binary formats (e.g Two’s compliment) in a very easy to understand way. It also contained a full reference for all of the assembly instructions and even diagrams explaining how they worked. If you are looking for a book to learn 6502 assembly in the same way most early game developers did then this is the book to choose.Published in 1979This section will cover books related to game development published in the year 1979. This was the year that the Intellivision was released from Mattel which used the CP-1600 CPU from General Instrument.The Intellivision was the only production use for the CP-1600 CPU and thus as far as we can tell no books were released on developing for the Intellivision or its CPU. Although there were a few strategy books about playing Intellivision games and a few modern books have been released about Intellivision game development. Cover Title Author Software Notes 6502 Assembly language programming Lance A. Leventhal     Electronic games: design, programming and troubleshooting WALTER H. BUCHSBAUM 8080 Assembly   The book titled Electronic games: design, programming and troubleshooting is an absolute gem, it explains how all the components of a typical 1970s game console/arcade machine works, including how to interface with standard Color and B/W Televisions and an extensive section on microprocessors. It is a very low level book focusing on the elexctronics hardware and would still be worth reading today, sure some parts are out of date but the concepts are the same.It contains a section on programming and even although this book was published in 1979 the representation of an assembly program will still be very familiar to fellow reverse engineers:Published in 1981This section will cover books related to game development published in the year 1981. This was the year that the SINCLAIR ZX81 was released which used the Zilog Z80 microprocessor. It was the go to choice for bedroom programmers as it was very cheap and games could be written to cassette tapes and distributed. Towards the end of the year the BBC MICRO was released in the UK and became hugely successful and was one of the first computers for many future programmers in the UK Games Industry. Cover Title Author Software Notes 68000 assembly language programming Osborne McGraw-Hill Assembly   Build your own Z80 computer: design guidelines and application notes Steve Ciarcia. Assembly and Hardware   The Dr. Watson book of assembly-language programming for Commodore PET Peter Holmes Assembly language   A Practical Introduction to Computer Graphics Ian O. Angell FORTRAN Good introduction to the mathematics behind creating graphics using simple lines Published in 1982This section will cover books related to game development published in the year 1982. The year that Sinclair released the ZX spectrum, CBM released the Commodore 64 along with the Dragon 32 which came with Microsoft BASIC. Cover Title Author Software Notes Apple Graphics & Arcade Game Design Jeffrey Stanton     Fundamentals of Interactive Computer Graphics James D. Foley and A.Van Dam Pascal Uses Core System of standard graphics subroutines from ACM SIGGRAPH Games for the Atari 400/800: or how to program your own games S. Roberts Atari BASIC and 6502 Assembly Only has one game in assembly called Gunfight which requires the Atari Editor/Assembler cartridge Understanding Atari Graphics Michael Boom Atari BASIC   Published in 1983This section will cover books related to game development published in the year 1983, the year that the Vectrex was released worldwide based on the Motorola 6809 cpu.It was also a big year for Japan with the release of the MSX which for many was their first experience having a programmable home computer. With a Zilog Z80 cpu and a variant of BASIC (MSX BASIC) it was ideal for bedroom game development in Japan.As for consoles it was also the year that Nintendo released their Famicom based on a 6502 CPU, but Nintendo has strict licensing agreements which limited third-party development. Despite this famous developers such as Satoshi Tajiri of Pokemon fame cobbled together his own Famicom development kit from old circuit boards obtained in Akihabara junk shops 5. Cover Title Author Software Notes Advanced programming techniques for your Atari including Graphics & Voice programs Linda M. Schreiber BASIC   Compute!’s first book of Atari games Compute! Publications, Inc BASIC, MLX Machine language   Compute!’s Second Book of Atari Graphics COMPUTE     Designs from your mind with ATARI graphics Tom Rowley BASIC   Dr. C. Wacko’s miracle guide to designing and programming David L Heller, John F Johnson, Robert Kurcina BASIC   Instant arcade games for the Dragon 32 Jean Frost BASIC   Invent And Write Games Programs For The Spectrum Noel Williams BASIC   Microcomputer Graphics: Techniques and Applications Donald Hearn     Programming the Dragon for games and graphics Geoff Phillips BASIC For the Dragon series of systems Z80 assembly language subroutines Lance A. Leventhal, Winthrop Saville Z80 Assembly   Published in 1984This section will cover books related to game development published in the year 1984. This was the year that we started to see books about programming the Commodore 64 which was the second best selling console worldwide in 1984. Cover Title Author Software Notes Art of computer game design Chris Crawford Game Design One of the all time great books on game design Assembly language for arcade games and other fast Spectrum programs Stuart Nicholls Z80 Assembly   Commodore 64 assembly language Bruce Smith 6502 Assembly language   Commodore 64 game construction kit William L. Rupp, Patricia A. Hartman Commodore BASIC   Creating Arcade Games on the Ti-99-4A Seth McEvoy BASIC   Games programming Eric Solomon Assembly languages, Pascal, Fortran Lots of good game programming concepts Getting started with 8080, 8085, Z80 and 6800 microprocessor systems James W. Coffron Assembly   Programming Tricks and Skills Lisa Watts and Les Howarth BASIC   Published in 1985This section will cover books related to game development published in the year 1985. This year the Sega Mark III was released in Japan which used a Zilog Z80A CPU. Cover Title Author Software Notes 48K Spectrum and Spectrum+: Assembly language course M E Thompson Z80 Assembly language Spectrum & Spectrum+ Assembly Language Course at Spectrum Computing - Sinclair ZX Spectrum games, software and hardware 6502 assembly-language programming for Apple, Commodore, and Atari computers Christopher Lampton 6502 Assembly   Assembly language programming on the BBC and Acorn Electron R B Coats Assembly   Commodore 64 assembly language arcade game programming Steve Bress 6510 Assembly Language   Macintosh Game Animation Ron Person Microsoft BASIC, Macintosh BASIC, Macintosh Pascal   Published in 1986This section will cover books related to game development published in the year 1986. It is notable for one of the first books on the C++ programming language, even although C++ wouldn’t be used in the games industry until nearly a decade later. Cover Title Author Software Notes Computer Graphics Donald Hearn, M. Pauline Baker     Peter Norton’s Assembly Language Book for the IBM PC Peter Norton Assembly language   Programming in C on the Amstrad Ian Sinclair C Programming   The C++ programming language Bjarne Stroustrup C++ Programming   The Magic Of Macintosh Programming Graphics and Sound William B Twitty Pascal and QuickDraw   Published in 1987This section will cover books related to game development published in the year 1987. Cover Title Author Software Notes Advanced Graphics in C Nelson Johnson C Programming   Learning C: programming graphics on the Amiga and Atari ST Marc B. Sugiyama and Christopher D. Metcalf C Programming   Computer graphics - a programming approach Steven Harrington Language Independent (Pascal, C, Fortran) Very good introduction to drawing lines etc Techniques for computer graphics David F Rogers, Rae A. Earnshaw     Published in 1988This section will cover books related to game development published in the year 1988. Cover Title Author Software Notes Graphics Programming in C Roger T. Stevens C Programming CGA, EGA, and VGA Microprocessor programming, troubleshooting and interfacing: the Z80, 8080 and 8085 James W. Coffron Assembly Language   Published in 1989This section will cover books related to game development published in the year 1989. Cover Title Author Software Notes Advanced MS-DOS programming: the Microsoft guide for assembly language and C programmers Ray Duncan Assembly and C The DOS programming bible Fractal programming in C Roger T., Stevens C Programming on MS-DOS   Graphics programming with Turbo C 2.0 Ben Ezzell Turbo C   SIGGRAPH 1989 Conference Proceedings: Computer Graphics Annual Conference Series ACM     Published in 1990This section will cover books related to game development published in the year 1990. Cover Title Author Software Notes Graphics programming with Microsoft C and Microsoft Quick C Kris Jamsa Microsoft C   High-resolution computer graphics using C Ian O. Angell C Programming   The game maker’s manual : Atari ST and STOS BASIC Stephen Hill BASIC   Published in 1991This section will cover books related to game development published in the year 1991. Cover Title Author Software Notes Advanced graphics programming in C and C++ Roger T. Stevens and Christopher D. Watkins C/C++ TurboC++, VGA graphics for IBM PC Graphics programming with Microsoft C 6 Mark Mallett C Programming   The data compression book: featuring fast, efficient data compression techniques in C Mark Nelson C Programming   マシン語ゲーム・プログラミング : PC-9801シリーズ (Machine language game programming: PC-9801 series) Manabu Aoyama, Tooru Hidaka Assembly Programming for PC-98 Japanese Book (Available on Archive.org) マシン語ゲームグラフィックス : PC-9801シリーズ (Machine language game graphics: PC-9801 series) Tooru Hidaka; Manabu Aoyama PC-98 GDC and EGC Programming Japanese Book (Available on Archive.org) Published in 1992This section will cover books related to game development published in the year 1992. Cover Title Author Software Notes Archimedes game maker’s manual Terry Blunt Archimedes BASIC   Sound Blaster the Official Book   Sound Blaster   Visual basic game programming for Windows Michael J. Young Visual BASIC   Published in 1993This section will cover books related to game development published in the year 1993. Cover Title Author Software Notes Flights of Fantasy: Programming 3D Video Games in C++ Christopher Lampton Borland C++   Programming games for beginners Christopher A Howard Visual Basic   Programming Windows games with Borland C++ Nabajyoti Barkakati Borland C++   Ray Tracing Creations: Generate Photorealistic Images on the PC Drew Wells, Chris Young     The Commercial Games Programmer’s Guide: Guide to Working for the Games Industry as Either an Artist, Musician, Designer or Programmer David Gibbon     QBasic games and more! Fred Sexton Jr QBasic   Published in 1994This section will cover books related to game development published in the year 1994 when C and Assembly language were king.In books it was the year of Andre LaMothe who published multiple books that would become must-read for MS-DOS game programmers. Cover Title Author Software Notes 3D Modeling Lab - Create Beautiful 3D Photorealistic Models On Your PC Philip Shaddock Imagine 3D Modeller   Animation how-to CD Jeff Bowermaster MS-DOS   Arcade games programming (for IBM compatible PC’s) Shaun Herd MS-DOS Very little information about this book on the web Graphics Gems Andrew S. Glassne C Programming   Game Programming Starter Kit Sams Publishing Visual C++ Contains the eBooks Teach yourself Game Programming in 21 Days and Teach Yourself Visual C++ in 21 Days along with a 2D Game engine and a copy of Visual C++ 1.0 Gardens of imagination: Programming 3D Maze Games in C/C++ C/C++     Modeling the Dream Cd: Walkthroughs and Flybys II Phil Shatz Autodesk 3d studio   PC game programming explorer Dave Roberts C Programming for VGA   Teach yourself Game Programming in 21 days Andre LaMothe C Programming for MS-DOS lagdotcom/tygpi21d: Teach Yourself Game Programming in 21 Days Texturing and Modeling: A Procedural Approach David Ebert, Ken Perlin et al Renderman Shading Language   The Revolutionary Guide to Bit Mapped Graphics Efin Podvoisky and Julian Dobson     Tricks of the Game Programming Gurus Andre LaMothe C & x86 Assembly for MS-DOS Tricks of the Game-Programming Gurus - The Doom Wiki at DoomWiki.org Zen of Graphics Michael Abrash     Published in 1995This section will cover books related to game development published in the year 1995, which is the year the Virtual Boy was released in Japan and the Saturn and Playstation were released in the US & Europe.On the Windows front, for graphics programming the API WinG was released by Microsoft in 1994 so in 1995 we started to see our first books about programming games in this API. Although the API was short lived as it was replaced by the Windows Games SDK in 1995 and later renamed to DirectX. Cover Title Author Software Notes Assembly language master class Wrox Press Intel Assembly (Pentium)   Black Art of 3D Game Programming Andre LaMothè C Programming   Black Art of Visual Basic Game Programming Mark Pruett Visual Basic   Black Art of Windows Game Programming Eric R. Lyons C/C++, WinG and Cartoon Engine Has chapters on WinToon and OpenGL! (Windows 3.1, Windows NT and Windows 95) Building a 3D game engine in C++ Brian Hook (@HookTM) Borland/Watcom C++ and AST3D library Also contains Thrust Master drivers programming information C++ games programming Al Stevens, Stan Trujillo C++, MS-DOS and Theatrix   The Doom game editor Joe Pantuso DOOM Editor Software: https://doom.fandom.com/wiki/The_Doom_Game_Editor CD: https://archive.org/details/cdrom-doom-game-editor Dungeons of Discovery: Writing Dazzling Windows Games With WinG Clayton Walnum WinG API   Engines of Creation - Programming Virtual Reality on the Macintosh Jonathan Blossom REND386, C programming   Game Graphics in C++ Len Dorfman Borland C++ (DOS VGA) Free to Borrow on Archive.org Graphics Gems V Alan W. Paeth   Two editions available one for Mac and other other for IBM PC NetWarriors in C: programming 3D multi-player games in C Joe Gradecki C Programming Very little info about this book online More Tricks of the Game Programming Gurus Andre LaMothe C & x86 Assembly for MS-DOS   Tricks of the Doom Programming Gurus Brunl Benner     Tricks of the Mac Game Programming Gurus Jamie McCornack Mac Game development   Dungeons of Discovery Imagine being a book author during this time frame when WinG was only really applicable for about a year, replaced with the Windows Game SDK which was then renamed to DirectX. This happened to the author Clayton Walnum who released Dungeons of Discovery: Writing Dazzling Windows Games With WinG in 1995 only for it to be deprecated. He then released Windows 95 Game Sdk Strategy Guide just as it got renamed to DirectX, how unfortunate! How well do you remember your 90s Windows game programming books? pic.twitter.com/k2LRpzLDkN— 𝔸𝕟𝕒𝕥𝕠𝕝𝕪 𝕊𝕙𝕒𝕤𝕙𝕜𝕚𝕟💾 (@dosnostalgic) February 3, 2022Black Art of 3D Game Programming“Black Art of 3D Game Programming,” authored by André LaMothe, is a seminal book in the field of game development, first published in 1995. It provides a comprehensive guide to the principles and techniques of 3D game programming, covering both theoretical concepts and practical implementation.The book is notable for its thorough exploration of the mathematical foundations required for 3D graphics, including vector and matrix operations, transformations, and perspective projections. It delves into the intricacies of 3D engines, discussing topics such as rendering pipelines, shading models, and texture mapping.You can find the source code ported to a modern toolchain (SDL + MacOS) here: ciciplusplus/black_art_3d_revival: Ported source code from book “Black Art of 3D Game Programming”Published in 1996This section will cover books related to game development published in the year 1996, which is the year the Nintendo 64 was released.There were some excellent books released by Waite Group Press 4 such as the Black Art of Macintosh Game Programming and the OpenGL SuperBible which were both cutting-edge at the time.Also the author Joe Gradecki released two books this year in the NetWarriors series, one an update to his book last year but this time in C++ and the other a guide to online resources, which would be very interesting to read nowadays, although most links would now be long dead. Cover Title Author Software Notes 3D game Alchemy for Doom, Doom II, Heretic and Hexen Steve Benner, et al. Doom Level Editor Available on RetroMags.com Black art of Java game programming Joel Fan, Eric Ries, Calin Tenitchi. Java   Black art of Macintosh game programming Kevin Tieskoetter Macintosh C   Build your own Flight Simulator in C++ Michael Radtke, Chris Lampton, Andrè LaMothe C++   Build your own PC game in seven easy steps using Visual BASIC Scott Palmer Visual BASIC   Developing games that learn Leonard Dorfman, Narendra K. Ghosh. C Programming   Inside electronic game design Arnie Katz with Laurie Yates Game Design   The Duke Nukem 3D level design handbook Matt Tagliaferri. Duke Nukem 3D level Editor   Teach yourself Internet game programming with Java in 21 days Michael Morrison Java Applets Very early book excited about the world of Java Applets for Game development NetWarriors in C++: programming multi-player games for Windows Joe Gradecki     NetWarriors Online: The game developer’s guide to online resources Joe Gradecki   Very little information about this online OpenGL SuperBible Richard S. Wright, Jr. Michael Sweet OpenGL API Spells of fury: building Windows 95 games using DirectX 2 Michael J. Norton VC++ 4.0 and DirectX   Win95 graphics programming Mathias Rasch WinG API   Windows 95 Game Sdk Strategy Guide Clayton Walnum Windows 95 Game SDK (DirectX)   Published in 1997This section will cover books related to game development published in the year 1997. Cover Title Author Publisher Software Notes 3D Graphics and Animation: From Starting Up to Standing Out Mark Giambruno New Riders     Developing Java entertainment applets John Withers   Java   OpenGL Reference Manual Dave Shreiner   OpenGL API   Published in 1998This section will cover books related to game development published in the year 1998. Cover Title Author Software Notes Visual C++ Programming Starter Kit Macmillan Software Visual C++   Published in 1999This section will cover books related to game development published in the year 1999.This year kicked off the Wordware Game Developer’s Library with the release of Real Time Strategy Game Programming Using DirectX which lasted all the way up to the last book published in the series in 2009. Cover Title Author Software Notes 3D Studio MAX 3 Fundamentals Michael Todd Peterson and Steve Burke 3D Studio Max 3   3D Studio MAX 3 Media Animation John P. Chismar and John Chismar 3D Studio Max 3   AI for computer games and animation: a cognitive modeling approach John David Funge.     Computer Graphics & Geometric Modeling       Developers guide to computer game design John Scott Lewinski     Game design: secrets of the sages Marc Saltzman Game Design   Inside TrueSpace 4 Frank Rivera Truespace 4   Real-Time Rendering Tomas Akenine-Möller, Eric Haines     Real Time Strategy Game Programming Using DirectX Mickey Kawick C++ and DirectX 6.0   Tricks of the Windows Game Programming Gurus Andre LaMothe C & C++   Understanding Motion Capture for Computer Animation and Video Games Albert Menache     Published in 2000This section will cover books related to game development published in the year 2000.This year started to see books covering Direct X 7.0 and it would also be the start of the very successful Game Programming Gems series of books which would result in 8 sequels! Cover Title Author Software Notes 3D Graphics programming: Games and beyond Sergei Savchenko C Programming and 3Dgpl   3D Game programming with C++ John De Goes C++ Programming and Direct3D   3D Game Engine Design: A Practical Approach to Real-Time Computer Graphics David H. Eberly Maths, Pseudo code   3D Games: Real-time Rendering and Software Technology, Volume 1 Alan Watt, Fabio Policarpo C++ and OpenGL Fly3D Game Engine, shows how to use SIMD instructions for Maths Advanced 3-D Game Programming With Directx 7.0 Adrian Perez, Dan Royer DirectX 7.0   Delphi graphics and game programming exposed! with DirectX for versions 5.0-7.0 John Ayres Delphi and DirectX   Designing Arcade Computer Game Graphics Ari Feldman Pixel Art   Developer’s guide to computer game design John Scott Lewinski Game Design   Learn Computer Game Programming with Directx 7.0 Ian Parberry DirectX 7.0   Game Architecture and Design Andrew Rollings, Dave Morris Game Design   Game Programming Gems Mark A. DeLoura C/C++ Programming   3D Games: Real-time Rendering and Software Technology There were a few books on 3D game programming released in 2000, one of the best has to be 3D Games: Real-time Rendering and Software Technology. Although not an easy read and fairly Maths heavy, it is very in-depth and shows some very advanced concepts, even shows SIMD assembly programming in the first chapter. The book is split up into 6 sections each with their own chapters: Modeling and foundation maths - This section deals with the basic mathematics required to handle objects in three-dimensional space and the theory of object representation. Classical 3D graphics - Although much of the material in this section has migrated onto hardware, it is still necessary to have an appreciation of whatthe hardware does to be able to use it effectively. Real-time rendering - This section deals with the technology developed by the games industry and the virtual reality industry which enables complex scenes to be rendered, to a reasonably high quality, in real time on a low-cost graphics processor. Control of objects - Mainstream techniques used to control the movement of objects are described in this section. This ranges from simple low-level control through to behavioural animation using Al technology. The material on Al is in the form of a debate concerning the potential use of the technology in the future. 2D technology - A potentially important solution to the complexity problem in 3D graphics, in terms of both the creation cost and the rendering cost, is the use of image-based rendering techniques. Software technology - This section deals with the techniques needed to write a multi-player game using the currently popular first-person shooter genre as an example. We examine the software architecture of a games engine and look at the design of the engine. Finally a comprehensive reference manual for the engine is given. Although part of the book is taken up by the Fly3D SDK reference which was also on the CD (pages 617-749), this might have been useful as a physical reference in the past but not useful nowadays. The Appendices have some tutorials for how to use the FlySDK including building levels with 3D Studio Max and exporting to the BSP format used by the engine. These appendices end with you having a controllable 3D model space ship driving around a map, they are the easiest to understand and the most enjoyable section of the book. Published in 2001This section will cover books related to game development published in the year 2001.This year Prima Tech released tons of very specialised game development books all aimed at Indie game developers. They were so successful that in August 2001 3 they got sold and changed their name to Premier Press and thankfully continued to churn out book after book on game development!This year started to see books covering DirectX 8.0. Cover Title Author Software Notes 3D Game Creation Luke Ahearn The Games Factory, Pie 3D Game Creation System   3DS Max 4: From Objects to Animation Boris Kulagin 3ds Max 4.0   Advanced 3D Game Programming using DirectX 8.0 Peter Walsh and Adrian Perez DirectX 8.0   Advanced Linux 3D Graphics Programming Norman Lin     Beginning Direct3D game programming Wolfgang F. Engel, Amir Geva Direct3D   Computer Game Design: Theory and Practice Richard Rouse III     Designing 3D Games that Sell! Luke Ahearn Game Design   Developer’s Guide to Multiplayer Games Andrew Mulholland, Teijo Hakala     Game Design: The Art & Business of creating games Bob Bates Game Design   Game Developer’s Guide to Cybiko Ernest Pazera     Game Modeling Using Low Polygon Techniques Chad Walker and Eric Walker     Game Programming Gems 2 Mark Deloura C++   Infinite Game Universe: Mathematical Techniques Guy W. Lecky-Thompson     Inside Lightwave 7 Dan Ablan Lightwave 7   Introduction to Computer Game Programming with DirectX 8.0 Ian Parberry DirectX 8.0   Isometric Game Programming with Directx 7.0 Ernest Pazera C++ and DirectX 7.0   Java 2 game programming Thomas Petchel Java   Linux game programming Mark “Nurgle” Collins C and OpenGL   Macromedia director game development from concept to creation Epic Software Macromedia Director   Mathematics for 3D Game Programming & Computer Graphics Eric Lengyel     Modeling a Character in 3DS Max Paul Steed 3DS Max   Multiplayer game programming Todd Barron Visual C++ and Direct X 8   Practical Algorithms for 3D Computer Graphics R. Stuart Ferguson OpenGL   OpenGL game programming Kevin Hawkins and Dave Astle OpenGL   Practical Algorithms for Three-Dimensional Computer Graphics R. Stuart Ferguson Visual C++   Pocket PC game programming Jonathan S. Harbour Windows CE for Pocket PC Compiles for MIPS, SH3 and ARM Swords & circuitry: a designer’s guide to computer role playing games Neal Halford, Jana Halford Game Design   The zen of Direct3D game programming Peter Walsh Direct3D   Published in 2002This section will cover books related to game development published in the year 2002. Cover Title Author Software Notes 2D Artwork and 3D Modeling for Game Artists David Franson 3DStudio Max and trueSpace   3D Math Primer for Graphics and Game Development Fletcher Dunn     AI Game Programming Wisdom Steve Rabin     AI techniques for Game Programming Mat Buckland   Genetic Algorithms and Neural Networks Andrew Glassner’s Other Notebook Andrew Glassner     Animating Real-Time Game Characters Paul Steed 3ds Max   Direct3D ShaderX: Vertex and Pixel Shader Tips and Tricks Wolfgang Engel DirectX   ShaderX2: Introduction and tutorials with DirectX 9.0 Wolfgang Engel DirectX 9.0   Focus on 2D in Direct3D Ernest Pazera Direct3D   Focus on Mod programming for Quake III arena Shawn Holmes C/C++   Infinite Game Universe: Level Design, Terrain, And Sound Guy W. Lecky-Thompson C++   Focus on photon mapping Marlon John C++   Focus on SDL Ernest Pazera C++, SDL   Game Audio Programming James Boer C++ DirectX   Game Development and Production Erik Bethke     Game Programming All in one Bruno Miguel Teixeira de Sousa. C++ and DirectX   Game Programming Gems 3 Dante Treglia     Game Programming tricks of the trade Lorenzo D. Phillips C++, DirectX and OpenGL   Game Scripting Mastery Alex Varanese     Get in the Game!: Careers in the Game Industry Marc Mencher     Lightwave 3D 7 Character Animation Timothy Albee Lightwave 3D 7.0   Mac Game Programming Mark Szymczyk C++ and QuickDraw   Micro Java game development David Fox and Roman Verhovsek J2ME MIDP   Microsoft Visual Basic game programming with DirectX Jonathan S. Harbour Visual Basic   Modeling Digital Dinosaurs Ken Brilliant     Non-Photorealistic Computer Graphics: Modeling, Rendering, and Animation Thomas Strothotte, Stefan Schlechtweg     Online Game Interactivity Theory Markus Friedl Game Design   Palm OS game programming Nicholas Pleis C PalmOS API and CodeWarrior IDE   Pause & Effect: The Art of Interactive Narrative Mark Stephen Meadows Game Design   Practical Parallel Rendering Alan Chalmers, Timothy Davis, Erik Reinhard Maths   Programming Dynamic Character Animation David Paull C++, DirectX, OpenGL   Programming role-playing games with DirectX Jim Adams C++ and DirectX   Real-time rendering tricks and techniques in DirectX Kelly Dempski C++ and DirectX   Real Sound Synthesis for Interactive Applications Perry R. Cook Maths   Special effects Game Programming with DirectX Mason McCuskey C++ and DirectX   Vector Game Math Processors James Leiterman     Visual Basic Game Programming with DirectX Jonathan S. Harbour Visual Basic, DirectX   Published in 2003This section will cover books related to game development published in the year 2003.In the year 2003 started to see a lot more game development books focussed on non-programming related topics such as production and Business.The year 2003 was the start of New Riders Games (NRG) a subset of New Riders Publishing purely focussed on Game Development topics. While New Riders Pub had dabbled with a game development book in the form of Get in the Game! from 2002 along with previous books on software such as Photoshop and 3D Studio, this year they jumped all in with a series that would last more than a decade until 2014! Cover Title Author Software Notes Advanced 3D Game Programming with DirectX 9.0 Peter Walsh DirectX 9.0   Advanced Global Illumination Philip Dutré, Philippe Bekaert, Kavita Bala Maths   Ai Game Development: Synthetic Creatures With Learning and Reactive Behaviors Alex J. Champandard C++   AI Game Programming Wisdom 2 Steve Rabin     Andrew Rollings and Ernest Adams on Game Design Andrew Rollings and Ernest Adams Game Design   Beginner’s Guide to DarkBASIC Game Programming Jonathan S. Harbour and Joshua Smith DarkBASIC   Chris Crawford on Game Design Chris Crawford Game Design   Collision Detection in Interactive 3D Environments Gino van den Bergen C++   Core Techniques and Algorithms in Game Programming Daniel Sanchez-Crespo Dalmau C++ with OpenGL and DirectX   C# and Game Programming: A Beginners Guide Salvatore Buono C#   C++ For Game Programmers Noel Llopis C++   Complete Maya Programming: An Extensive Guide to MEL and C++ API David Gould MEL, C++   Creating Emotion in Games: The Craft and Art of Emotioneering David Freeman and Will Wright Game Design   Data structures for game programmers Ron Penton C++   Designing Virtual Worlds Richard A. Bartle Game Design   Developing Games in Java David Brackeen, Bret Barker , et al. Java   Developing Online Games: An Insiders Guide Jessica Mulligan and Bridgette Patrovsky Game Design   DirectX 9 Audio Exposed Todd Fay Direct X 9.0   Elementary Game Programming & Simulations Using Jamagic Sergio Perez Jamagic game creation software   Essential Lightwave 3D 7.5 Timothy Albee Lightwave 3D 7.5   Focus on curves and surfaces Kelly Dempski C++   Introduction to 3D Game Programming with DirectX 9.0 Frank D. Luna DirectX 9.0   Introduction to Level Design for PC Games Andrew Charles Clayton gMax, Photoshop   The Indie game development survival guide David Michael Soft Skills   Game Coding Complete Mike McShaffry C++ DirectX   Game Design Foundations Roger E. Pedersen Game Design   Game development and production Erik Bethke Project Management   Game Programming Gems 3 Dante Treglia     Game Programming With Python Sean Riley Python   Games That Sell! Mark Walker Game Design   Java 1.4 Game Programming Andrew Mulholland and Glenn Murphy Java 1.4   Learn Vertex & Pixel Shader programming with DirectX James Leiterman Direct X   Lightwave 3D 7.5 Lighting Nicholas Boughen Lightwave 7.5 Re-released as LightWave 3D 8 Lighting in 2004 and LightWave V9 Lighting in 2007 Massively multiplayer Game Development Thor Alexander C++ and Python Borrow on Archive.org Mel Companion: Maya Scripting for 3D Artists David Stripinis Maya, MEL   Online game interactivity theory Friedl, Markus Game Design   Postmortems from Game developer Austin Grossman     Real-Time Shader Programming Ron Fosner DirectX 9.0   Real-time 3D terrain engines using C++ and DirectX 9 Greg Snook C++ DirectX 9   Secrets of the Game Business François Dominic Laramée Soft Skills   Strategy Game Programming With DirectX 9.0 Todd Barron DirectX 9.0   The Fat Man on Game Audio: Tasty Morsels of Sonic Goodness George “Fat Man” Sanger Audio/Music   The gmax Handbook Clayton E Crooks gMax   Wireless game development in C/C++ with BREW Ralph Barbagallo C/C++ and BREW   Published in 2004This section will cover books related to game development published in the year 2004. Cover Title Author Software Notes 3D game engine programming Stefan Zerbst with Oliver Düvel     Advergaming developer’s guide: using Macromedia Flash MX 2004 and Director MX Rod Afshar, Duke Banerjee, Clifford Jones     Advanced Lighting and Materials with Shaders Kelly Dempski, Emmanuel Viale     AI game development: synthetic creatures with learning and reactive behaviors Alex J. Champandard     AI Game Engine Programming Brian Schwab     Artificial Intelligence for Computer Games: An Introduction John David Funge     Awesome 3D game development: no programming required Clayton E. Crooks II Multimedia Fusion, The 3D GameMaker and MilkShape 3D   Beginning C++ Game Programming (Game Development Series) Michael Dawson C++   Beginning Game Boy Advance Programming Jonathan Harbour C Programming, GBA   Beginning Math and Physics for Game Programmers Wendy Stahler , Dustin Clingman, et al. C++   Beginning OpenGL Game Programming Dave Astle, Kevin Hawkins OpenGL   Character development and storytelling for games Lee Sheldon     Creating the Art of the Game Matthew Omernick Maya, 3ds Max   DirectX 9 User Interfaces: Design and Implementation Alan Thorn DirectX 9.0   Game Console Hacking: Xbox, PlayStation, Nintendo, Game Boy, Atari and Sega Joe Grand, Albert Yarusso Hardware   Game Character Development with Maya Antony Ward Maya   Game Development essentials: An Introduction Jeannie Novak     Game Development with Lua Paul Schuytema, Mark Manyen Lua   Game Programming Golden Rules Martin Brownlow C++   Game Programming with Python Sean Riley Python   Game Programming Gems 4 Andrew Kirmse     Introduction to Game Development Steve Rabin     LightWave 3D 8 Texturing Leigh Van Der Byl LightWave 3D 8.0 Re-released as LightWave V9 Texturing in 2007 LightWave 3D 8 Cartoon Character Creation: Modeling and Texturing Jonny Gorden LightWave 3D 8.0   LightWave 3D 8 Cartoon Character Creation: Rigging and Animation Jonny Gorden LightWave 3D 8.0   Macromedia Flash MX 2004 Game Development Glen Rhodes Flash MX 2004   Macromedia Flash MX 2004 Game Programming Craig S. Murray, Justin Everett-Church Flash MX 2004   Massively Multiplayer Game Development 2 Thor Alexander     Mobile device game development Clayton E. Crooks II     Object-oriented game development Julian Gold     Official Butterfly.Net Game Developer’s Guide Mulholland, Andrew     OpenGL Game Development Chris Seddon OpenGL   OpenGL ES game development Dave Astle, Dave Durnil. OpenGL ES   Patterns In Game Design Staffan Bjork and Jussi Holopainen Game Design   Physics modeling for game programmers David Conger     Practical Java Game Programming Dustin Clingman, Shawn Kendall, Syrus Mesdaghi Java   Programming Game AI by Example Mat Buckland     Programming Multiplayer FPS Direct X Vaughan Young C++, DirectX   Programming Multiplayer Games Andrew Mulholland and Teijo Hakala     Programming Believable Characters for Computer Games Penny Ballie-De Byl     Real-Time Shader Programming Ron Fosner DirectX 8/9   ShaderX3 Advanced Rendering with DirectX and OpenGL Wolfgang Engel DirectX, OpenGL   The animator’s motion capture guide: organizing, managing, and editing Matthew Liverman     The Dark Side of Game Texturing David Franson     The Game Localization Handbook Heather Chandler Localization   Wireless game development in Java with MIDP 2.0 Ralph Barbagallo Java and MIDP 2.0   Published in 2005This section will cover books related to game development published in the year 2005. Cover Title Author Software Notes 3ds Max 7 Fundamentals Ted Boardman 3ds Max 7 Re-released as 3ds Max 8 Fundamentals in 2008 Advanced game development with programmable graphics hardware Alan Watt, Fabio Policarpo     Advanced Graphics Programming Using OpenGL Tom McReynolds, David Blythe OpenGL   Beginning game graphics Harry J Evry Caligari gameSpace   Chris Crawford On Interactive Storytelling Chris Crawford Game Design   Complete Maya Programming Volume II: An In-depth Guide to 3D Fundamentals, Geometry, and Modeling: Volume 2 David Gould MEL, C++   Cross-platform game programming Steven Goodwin     Design First for 3D Artists Geoffrey Kater     Director MX 2004 games: game development with Director Nik Lever     Game art: creation, direction, and careers Riccard Linde     Game development essentials: video game art Todd Gantzler     Game Development With Lua Paul Schuytema and Mark Manyen Lua   Game level design Ed Byrne     Game Programming Gems 5 Kim Pallister     Implementing a digital asset management system: for animation, computer games, and web development Jens Jacobsen, Tilman Schlenker, and Lisa Edwards     Introduction to Game Development Steve Rabin     Make Amazing Games in Minutes Jason Darby The Games Factory 2.0   Making a game demo: from concept to demo gold Chad Walker     MEL Scripting for Maya Animators Mark R. Wilkins Maya, MEL   OpenGL Game Development Chris Seddon OpenGL   Open source game development: QT games for KDE, PDAs, and Windows Martin Heni, Andreas Beckermann C++   Patterns in Game Design Staffan Bjork, Jussi Holopainen     Polygonal Modeling: Basic and Advanced Techniques Mario Russo 3DS Max and Maya   Real-time cinematography for games Brian Hawkins     Real-Time Collision Detection Christer Ericson C++   The complete guide to game development, art and design David McCarthy, Ste Curran and Simon Byron     The game artist’s guide to Maya McKinley, Michael (Michael T.) Maya   The game localization handbook Heather Maxwell Chandler     Published in 2006This section will cover books related to game development published in the year 2006. Cover Title Author Software Notes AI Game Programming Wisdom 3 Steve Rabin     Artificial Life Possibilities: A Star Trek Perspective Penny Baillie-de Byl     Basic Game Design & Creation for Fun & Learning Nanu Swamy and Naveena Swamy GameMaker 6.1   Business & Legal Primer for Game Development S. Gregory Boyd and Brian Green     COLLADA - sailing the gulf of 3D digital content creation Rémi Arnaud, Mark C Barnes COLLADA (XML)   Developing Serious Games Bryan Bergeron Game Design   Game Design: A Practical Approach Paul Schuytema Game Design   Game Developer’s Open Source Handbook Steven Goodwin SDL, ODE   Game Engine Toolset Development Graham Wihlidal C#   Game Production Handbook Heather M Chandler     Game Programming in C++: Start to Finish Erik Yuzwa C++, SDL, OpenGL   Game Programming Gems 6 Mike Dickheiser     The Game Programmer’s Guide to Torque Edward F. Maurina III Torque Game Engine   Geometric Data Structures for Computer Graphics Elmar Langetepe, Gabriel Zachmann     Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach Frank D. Luna DirectX 9.0c   Learn C++ By Making Games Erik Yuzwa and Francois Dominic Laramee C++, SDL   Level Design for Games: Creating Compelling Game Experiences Phil Co Game Design   Macromedia Flash Professional 8 game development Glen Rhodes Flash 8.0   Macromedia Flash Professional 8 Game Graphics Robert Firebaugh     Modeling, UV Mapping, and Texturing 3D Game Weapons Christian Chang Maya   Programming an RTS Game with Direct3D Carl Granberg DirectX   ShaderX4: Advanced Rendering Techniques Wolfgang Engel DirectX   Published in 2007This section will cover books related to game development published in the year 2007. Cover Title Author Software Notes Computer Animation: Algorithms and Techniques Rick Parent Maya, C++   Creating Game Art for 3D Engines Brad Strong 3ds Max   Creating Games In C++: A Step-By-Step Guide David Conger and Ron Little C++ and LlamaWorks2D   Creating Casual Games for Profit and Fun Allen Partridge     Data Structures and Algorithms for Game Developers Allen Sherrod     Designing Character-Based Console Games Mark Davies Game Design   Emergence in Games Penny Sweetser Game Design   Fundamentals of Game Design Ernest Adams, Andrew Rollings Game Design   Game development essentials: Game interface design Kevin Saunders, Jeannie Novak     Game development essentials: Game Project Management John Hight, Jeannie Novak     Game Physics Engine Development Ian Millington     Game Writing handbook Rafael Chandler     Game writing: narrative skills for videogames Chris Bateman     Introduction to Game Programming with C++ Alan Thorn C++   Microsoft XNA Game Studio Express creator’s guide: an introduction to XNA game programming Stephen Cawood and Pat McGee XNA   Mobile 3D Game Development: From Start to Market Carlos Morales and David Nelson JavaME   ShaderX5: Advanced Rendering Techniques Wolfgang Engel     Video Game Design Revealed Guy W. Lecky-Thompson Game Design   Published in 2008This section will cover books related to game development published in the year 2008. Cover Title Author Software Notes 3D Games Programming: Using Directx 10 and Open GL Pierre Rautenbach DirectX, OpenGL   3ds Max Modeling: Bots, Mechs and Droids Jon Weimer 3DS Max   Advanced 3D Game Programming with DirectX 10.0 Peter Walsh DirectX 10.0   AI and Artificial Life in Video Games Guy W. Lecky-Thompson     AI Game Programming Wisdom 4 Steve Rabin     Best of Game Programming Gems Mark DeLoura     Cross Platform Game Development: Make PC Games for Windows, Linux and Mac Alan Thorn C, SDL, Director, Novashell, Ogre3D   Emergence in games Penny Sweetser     Essential XNA Game Studio 2.0 Programming Jim Perry XNA   Essential Zbrush Wayne Robson Zbrush   Fundamentals of Network Game Development Guy W. Lecky-Thompson     Game character development Antony Ward     Game design workshop: a playcentric approach to creating innovative games Tracy Fullerton     Game Graphics Programming Allen Sherrod C++, DirectX 9/10, HLSL, OpenGL, GLSL   Games on Symbian OS : a handbook for mobile development Fadi Chehimi     Game Programming Gems 7 Scott Jacobs     Introduction to 3D Game Programming with Direct 3D 10: A Shader Approach Frank D. Luna DirectX 10.0   Multiplayer Gaming and Engine Coding for the Torque Game Engine Edward F. Maurina III Torque Game Engine   Nintendo Wii Flash Game Creator’s Guide: Design, Develop, and Share Your Games Online Todd Perkins Flash   ShaderX6: Advanced Rendering Techniques Wolfgang Engel     The Complete Guide to Torque X John Kanalakis XNA, Torque Game Engine   Published in 2009This section will cover books related to game development published in the year 2009. Cover Title Author Software Notes 3D game development with Microsoft Silverlight 3: beginner’s guide Gastón C. Hillar   creating real-time responsive online 3D games in Siliverlight 3 using C#, XBAP WPF, XAML, Balder, and Farseer Physics Engine ActionScript for Multiplayer Games and Virtual Worlds Jobe Makar Flash   Artificial intelligence for games Ian Millington and John Funge     Character Animation With Direct3D Carl Granberg DirectX   Collaborative Online Game Creation Nanu Swamy and Naveena Swamy Flash   David Perry on Game Design: A Brainstorming ToolBox David Perry and Rusel DeMaria Game Design   Game audio development Aaron Marks, Jeannie Novak     Game Design Foundations Roger Pedersen     Game engine architecture Jason Gregory     Microsoft XNA game studio creator’s guide Stephen Cawood, Pat McGee     RPG Programming with XNA Game Studio 3.0 Jim Perry XNA   ShaderX7: Advanced Rendering Techniques Wolfgang Engel     Ultimate Game Programming with DirectX Allen Sherrod     Unity game development essentials Will Goldstone Unity   Books about Retro Game Development with Modern ToolsWe tend to only cover retro games on this site and although the term retro means different things to different people, we have decided not to list game development books from 2010 and beyond. However we would like to list books published after 2010 if they are about Retro Game Development, that is what this section is for.Most of these books employ modern tools to create games for retro hardware such as the ZX Spectrum or Commodore 64 through emulators which is a lot more accessible than using hardware and software from the time period.This section will cover: Retro Game Dev - Commodore 64 The Making of Karateka - 2012 You: A Novel - 2012 (Fiction) Programming the Nintendo Game Boy Advance - 2012 Behind the Scenes at Sega: The Making of a Video Game - 2015 ZX Spectrum Games Code Club: Twenty fun games to code and learn - 2015 Making Games for the Atari 2600 - 2016 I Am Error: The Nintendo Family Computer / Entertainment System Platform - 2017 Programming Games for Intellivision - 2018 Code the Classics - 2019 Candid Conversations in Code The Making of Prince of Persia - 2020 Modern MSX BASIC Game Development: Build retro games in MSX BASIC using modern tools - 2021 Bare-Metal Amiga Programming: For OCS, ECS and AGA - 2021 Advanced Game Programming for Intellivision - 2021 Game Boy Coding Adventure: A complete, practical, timeless programming guide - 2022Candid Conversations in Code (2020)In Ethan Johnson’s excellent book Candid Conversations in Code he interviews eight talented game programmer from the 1970s; Gregory Cox - Programmer for Cyan Engineering March 4 1974 to August 16 1974 David Shepperd - Programmer for Atari, Inc. and Atari Games 1976-2003 Rich Moore - Programmer and Manager for Atari, Inc. and Atari Games 1978-1993 Tom McHugh - Programmer for Dave Nutting Associates 1975-1982 and Action Graphics 1982-1985 Jamie Fenton - Programmer for Dave Nutting Associates 1975-1982 Mark Lesser - Programmer for Rockwell 1976-1978, Mattel 1978-1982, Parker Brothers 1982-1984, Microsmiths 1987-1992, Electronic Arts 1992-2000 Vic Tolomei - Programmer and Game Designer for Exidy Inc. 1979-1987References Course PTR - Welcome! ↩ prima-tech.com: ↩ Prima Tech Becomes Premier Press, Inc ↩ ↩2 Waite Group Press Subject Room ↩ ↩2 Videogames Hardware Handbook Volume 1 (2016) - Page 100 ↩ ", "excerpt": "One of the best ways to get an insight into the games industry is to look at the books that were available to developers at the time, both game-specific books, programming books and digital/creative books have a wealth of information. As this is a site about retro games, we are...", "tags": ["industry"], "image": "/public/images/categories/Games Industry Books.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "BroadOn Archive - Nintendo May 2020 Leak (4Chan)", "url": "/broadon-archive", "content": "In early May 2020 a leak of Nintendo Source Code hit the popular image board 4chan. The material contained in this leak was obtained by a young hacker known as Zammis Clark. One of these was the BroadOn Archive a file simply called unsorted.zip which contained material from the company BroadOn.BroadOn was a third-party hardware and software company contracted by Nintendo, particularly involved during the era of the Wii console. BroadOn specialized in advanced technology development, and Nintendo engaged them for significant work on hardware and software components such as the iQue.More content was later uploaded throughout 2020 such as the Gigaleak which contained source code for many popular Nintendo classics. Gigaleak - SNES Source Code Leak For more information on the original Gigaleak check out this post. This page details the contents of the BroadOn ArchiveThe UploadsThe material itself was uploaded twice, the first upload was named unsorted.zip. The problem with this archive was that it contained many files with the extension ,v (comma intentional).The archive was then re-uploaded with the CVS files fixed and called it unsorted-nocvs.zip.What are CVS FilesConcurrent Versions System or CVS is a version control system which predates both Git and SVN and was based on the Revision Control System (RCS).When the files were downloaded from the Nintendo server they were in a CVS repository.A CVS repository is file-based, where the version history, file contents and commit messages are stored in a ,v file.Thus the original leak of the files were not the raw files. Each file was wrapped in a container that had the additional version control information.In order to view the actual file you would need to use a VCS or RCS command to get the latest version of the file.To CVS or not to CVS?If you are just interested in browsing the files then it is highly recommended you download the noCVS version as it is not just a case of removing the ,v from the filename, you need to use CVS or RCS commands to fix the files.However the advantage of the CVS version is that it contains the commit history of the files which can be very interesting!Contents of the ArchiveWhether you have the original or the NOCVS fixed version you will get 3 different tar files in the archive: rvl-factory.tar (111.3MB) - (Not affected by CVS) depot.tar (2.9GB) - iQue specifications by RouteFree depotrvl.tar 533.9MBDepot.tar - iQue specifications by RouteFreeThe name depot may be related to the network functionality of the iQue known as the iQue Depot 1 which you can find more information on over at iQue Depot - iQueBrew.The iQue Depot is the service that was later enhanced and used for the Nintendo Wii.CVSROOT FolderAs the name implies this folder is for the configuration of the Concurrent Versions System. You can think of this folder as similar to the .git folder in more modern projects. Nothing interesting to see here.HW Folder - Kilopass XPM hardware Verilog SourceThe HW folder contains hardware specifications for the Kilopass Super Permanent Memory or XPM. This is kept operate from the rest of the source as it is 3rd party technology licensed from Kilopass.This is presumable the hardware used in the iQue Player to enable storing code and data on the chip in a way that makes it harder for reverse engineers to access the data.There is basic Verilog source code in this folder along with official specifications all from Kilopass themselves.Data SheetsThe DataSheets folder contains three pdf files: KPS13_DS_V031605.pdf - DS013T (version 2005-03-17) Datasheet TMDG013T_V1.3.pdf - Testing Methodology Design Guidelines xpm_integration_guideline_RevF-06APR2005.pdf - Kilopass XPM IP Integration GuidelineGDS FolderThe gds folder contains more Verilog source files, such as the TSMC layout layer mapping (Virtuoso_0.13um_Ver2.1a.1.map) along with the GDS files used to describe it in a graphical form.Models FolderThe models folder contains the timing library Verilog source code in both ascii (.lib) and binary compiled form (.db). This also contains the Verilog source file kp13ts64_r01w01_70c3p.v which is the main code for the Kilopass 32kx8 XPM.Netlist FolderThe netlist folder contains the netlist specification in the CDL file format, this is a plain text document that specifies what each node is connected to in the circuit.RF Folder - Project BBNot sure why this man directory is called rf but it contains most of the files for the iQue Player (also known as Project BB during development). This includes hardware source code (Verilog), software source, SDK and Documentation.This folder contains two files at the root called BBdefs and BBrules, these are both common Make definitions that get included into Makefiles in the child folders.There is also an empty sub folder called ecad and it is unclear what this folder could be been used for but it is likely that it is hardware related and would stand for electronic computer-aided design.DOC folder - DocumentationThe iQue player was codenamed the “BB” project (possibly reference to something in Chinese?) so much of the documentation references the system as the BB or BB Player.HW folder - iQue Player HardwareThis folder contains the Verilog source code and a bunch of software source code that is used to help verify that the hardware is working correctly.SW folder - iQue Software (SDK etc)This folder contains the source code for software related to the iQue Player such as the SDK.The top level of this folder is a bash script called mklinks which simply creates symbolic links to common folders so they can be used easily after they have been built.BBPlayer folderLinux Dev Root - iQue development environment for Linuxexport_headers folderThis folder just contains C header files that are all for the iQue specific features such as security and Network features. Header File Name Description aes.h Defines functions such as aes_HwKeyExpand, aes_SwEncrypt and aes_SwDecrypt aes_api.h Defines structors and preprocessor directives along with functions such as aesMakeKey bbcert.h Project BB Certificate structures and preprocessor defines bbticket.h BbTicket structure which is used to verify a user owns a game bbtoolsapi.h Handy tool functions such as generateUnsignedBbCert bbmetadata.h Metadata structors to hold data such as SHA has of games bbreg.h BB Player User Registration Data Structure bbtypes.h Common types for BB Player software ultratypes.h Standard N64 types from the Official N64 SDK It also contains libcryptoX86.a which is the result of compiling the BBPlayer libcrypto library on X86 hardware and is used for the server code.The executable pkgbootrl is whats called the “Bundle tool” and the source code is located in rf/sw/bbplayer/tools/crls.Kits folder - Software Development KitsThe N64 Sound Tools folder holds the content distributed to Musicians as an addon to the official N64 SDK. N64 Sound and Music You can find out more about the N64 Sound Tools here. The n64kit folder partially contains the Japanese version of the N64 Developers Kit Version 5.1 from 2000/02/10. A newer more complete version of this development kit is available on ultra64.ca so the contents won’t be mentioned here. Official Nintendo 64 SDK For more information about the n64kit view this post. For some reason it only contains the nusys, nustd and misc folders of the n64kit.n64os20I folder - Internal N64 development toolsThis folder contains the final version of the internal N64 development tools from SGI, an earlier version of this content was released as part of the “Oman Archive”, so only the changes will be listed here. Oman Archive - N64 Leak by SGI employee To view details about the files released in the oman archive check out this post. Verification folder - AES encyption/decryptionThe Verification folder contains the source code for a tool called aes which is simply code to do simple Advanced Encryption Standard (AES) encryption and decryption.For security the iQue Player only allows running signed and encrypted code, AES Cipher block Chaining (CBC) is the encryption algorithm used for this. This tool specifically is used to test the encryption and decryption of binary content.In fact this folder comes with two pre-compiled Windows executables: test_dec.exe - Test decryption test_enc.exe - Test encryptionThe source code for these too executables are test_dec.c and test_enc.c respectively.The AES algorithms is also known as rijndael which is why most of the source code files start with that name as a prefix. These files come from the AES reference implementation by Paulo Barreto and Vincent Rijmen. AES Reference Implementation You can find the AES Reference implementation code on Github. The folder also contains *.bin files that can be used to test the algorithm, when you feed in input.bin into test_dec then output.bin and deciphered.bin should match exactly.Java folder - Apache Ant version 1.4.1This folder is pretty boring in that it just contains a standard distribution of Apache Ant version 1.4.1. Apache Ant is basically a task runner written in Java, but it is unclear what they were using it for in the iQue project.Nothing is customised so we will not cover the contents here.LIB folder - BCP PLI library codeThe Library folder contains the source code for two very similar libraries: RCP PLI (Reality Co-Processor PLI) - version 1.1 BCP PLI (BB Co-Processor PLI) - version 1.2PLI stands for Programming Language Interface and refers to the Verilog PLI as these libraries are used to communicate with the verily models of the Reality Co-processor (RCP or BCP).The RCP version is presumably from SGI as part of the original Ultra 64 project, but it was not previously released in the “Oman Archive”. It requires an SGI IRIX workstation to compile.The code in these libraries seems to be related to interprocess communication (IPC) for managing shared data in the system.The BCP version of the library is a fork of the RCP library with added support to be able to compile on linux. Each version contains a .tab file (rcppli.tab and bcppli.tab) which is a verilog file 2 and has the form:$my_function_name call=CalledByThis size=32 maxargs=1 roparm=ffffffff nocallback If you build the libraries you will get a static library output (libbcppli.a and librcppli.a).Both the resulting library files and tab files are used in the the Behavioural Simulator code (located in rf/hw/chip).References iQue Depot - iQueBrew ↩ Principles of Verilog PLI By Swapnajit Mittra page 6 ↩ ", "excerpt": "In early May 2020 a leak of Nintendo Source Code hit the popular image board 4chan. The material contained in this leak was obtained by a young hacker known as Zammis Clark. One of these was the BroadOn Archive a file simply called unsorted.zip which contained material from the company...", "tags": ["wii","n64","sdk","leak","ique"], "image": "/public/Wii/Nintendo Wii May 2020 Source Code Leak.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Commodore 64 Reverse Engineering", "url": "/C64", "content": "Gamesmm-explained: Maniac Mansion C64 Disassemblypditincho has produced a reconstructed and fully commented disassembly of the Commodore 64 implementation of Maniac Mansion. This project documents the inner workings of the engine’s C64 iteration, covering 6502 assembly routines, specialized disk loaders, and hardware-level interactions with the VIC-II and SID chips. It provides a detailed technical breakdown of game entities such as rooms, costumes, and scripts, serving as a comprehensive resource for understanding the game’s original architecture. GitHub - pditincho/mm-explained: Maniac Mansion C64 explained pditincho has released mm-explained, a comprehensive disassembly and technical documentation of the C64 version of Maniac Mansion, detailing its assembly logic and engine structure. Freeload: The Ocean Loader Technical RetrospectivePaulie Hughes provides a detailed technical breakdown of “Freeload,” the iconic Commodore 64 turbo loader used by Ocean Software. The page explores the evolution of the loader’s design, including its signature raster bars, the integration of loading music by composers like Martin Galway, and the various anti-piracy encryption methods implemented toward the end of the C64’s lifecycle. Crucially, it discusses the transition from standard loading routines to more advanced techniques, such as loading data directly into the stack to execute games via a manual stack pointer manipulation. Freeload - The Ocean Loader by Paulie Hughes Original developer Paul Hughes shares the history and 6502 assembly source code for Freeload, the legendary Ocean Loader used for C64 titles. ", "excerpt": "Games mm-explained: Maniac Mansion C64 Disassembly pditincho has produced a reconstructed and fully commented disassembly of the Commodore 64 implementation of Maniac Mansion. This project documents the inner workings of the engine’s C64 iteration, covering 6502 assembly routines, specialized disk loaders, and hardware-level interactions with the VIC-II and SID chips....", "tags": ["c64"], "image": "/public/generated/placeholders/c64.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": "c64" } ,{ "title": "Guide to contributing to RetroReversing", "url": "/contributing", "content": "Thank you for your interest in contributing to RetroReversing! This guide explains some of the formatting guidelines and features you can use to make the posts on the page more engaging.Site PrinciplesThe following are the main principles of the site and can help decide not only how to write the posts but also if content is applicable to this site or would be better suited to a different wiki.Audience👥The target audience for the site are technically literate readers who likely already know how to program with modern programming languages but may be beginners when it comes to reverse engineering or programming in older languages and environments such as DOS. Bear this in mind when writing posts and try to reference any sources to back up claims.The ContentThe content of the site focuses on the development process and technology of video games from the 1980s until around 2010, with reverse engineering as a core aspect of the site, being the cornerstone of digital archaeology.Types of content we want✅We want content related specifically to the game development process, this can include programming, development environments, artist software and general information about working in a retro game development studio.This can include: Delving deep into a specific game or game engine - looking at the game files and decompiling the executable code Development Software - General articles about a piece of software and its use in retro game development - e.g. 3D Studio Max, Deluxe Paint, Software Development Kits Development hardware - e.g. console development kits, arcade hardware, cheat devices, and even how retail hardware works Tutorials - on reverse engineering or writing emulators Research material related to the game industry - e.g. content of game industry conferences, programming/software books, game industry magazines, or even just game magazines from the past that contain interviews with game developersTypes of content we don’t want❌We don’t want to duplicate the content of other sites; we aim to contribute to them where possible. We specifically focus on the more technical aspects of retro game development - there may be a better home for certain content.Although there are exceptions to these rules, the kind of content we aim to avoid on this site includes: Content about cut content in games - please contribute to the excellent The Cutting Room Floor and then link where applicable insteadLink to High-quality website articles rather than duplicate🔗Please try to link out to other sites that have high-quality information on a particular topic rather than rewriting the same content here. Content on this site should either link together sources from multiple places on the web into a cohesive article or include content not available elsewhere online.However, please provide at least a brief description of the page you are linking to and its content before the reference so readers understand the relevance. The page here should still form a cohesive narrative even without the reader following the external links. If an external page is critical, tell the user to read it before continuing.Reference when possible📚We want to avoid spreading misinformation as much as possible, which can be tricky when researching old software tools since there can be conflicting information. Please reference sources so readers can verify whether the information is correct. You may use Wikipedia as a source but only as a last resort if no other websites have the information.Formatting GuidelinesPosts are written in GitHub Flavored Markdown but also support additional Jekyll includes that can be used for more advanced components.Writing Style Rules🔤For the writing style, think of each article as a technical handbook with references, not a blog post.Some general rules are below: Avoid over-explaining - Introduce only the key concept first, then provide practical examples or lists. Use short paragraphs - Break up long text with additional elements such as images, subheadings, lists, code blocks, or other features. Avoid giant sentences - Keep use of commas and semicolons to a minimum. Focus on short, readable sentences. Add newlines after sentences to break them up. Tone: Technically detailed, slightly conversational, but not casual. Avoid corporate, sales, or overly enthusiastic tones. You may include mild enthusiasm or analogies when they aid understanding but always return to clear, factual language. Non-linear order - Never assume the reader will follow a linear order. Each section should be standalone so they can read only the parts they are interested in. Present then explain - Present terminology as factual first, then justify or contextualize (“What is it?” then “Why is it useful?”). Encourage hands-on experimentation - Suggest trying tools, running commands, or inspecting files.Character Rules🔤When copying and pasting between programs, ASCII/UTF characters can sometimes change from source to destination.We try to maintain consistent characters here are the main rules: Quotes - Never use the slanted “ instead use the standard \" for quotes. Dashes - For dashes, always use - and never — (em dash). Standards only - Don’t use characters that are not on standard keyboards.SpellingWe have automated spell checking with cspell but sometimes debug symbols and other technical terms may need to be excluded, if there is a big block of them you can you the following:<!-- cspell:disable -->debug symbols that are not spelled correctly but we want to keep for accuracy<!-- cspell:enable -->Table of Contents Do not generate your own table of contents as tyhis will be done at runtime based on the H1/H2/H3 etc elements. But DO make sure to use the full range of headings from H1->H5Markdown RulesOur pages tend to be broken up into different sections based on headings, headings are used for the table of contents and can be treated as distinct sections.Here are some of the markdown rules: Don’t bold headings - In Markdown, never use ** to make the text bold in H1–H5 headings, as CSS handles this. Don’t use emoji’s in headings - Don’t use emojis in headings themselves Don’t use backticks in headings - Keep headings plain text and move inline code formatting into the paragraph below instead Use HR before major sections - Add a Markdown HR (---) when starting a new major section, such as before an H1 or H2’s that are not the first subheading under a H2, same for H3 etc. Use HR when jumping back up the heading hierarchy - If a section ends at a deeper heading level and the next heading jumps back up, add a Markdown HR (---) immediately before the higher-level heading. For example, if an H4 section is followed by a new H1, place --- directly before the H1. No line between HR and Heading - the next line after a HR (---) should be the heading itself No line between heading and first paragraph - the next line after a heading should always be the first paragraph of the section Short inline code - If the code is short, wrap it with backticks (e.g. eax, 0x00). Don’t mix bold and inline code - Avoid **\\literal`**` styling. Use backticks for literals (commands, file names, extensions) and bold for emphasis, but not both at the same time. HR before H2/H3 - Have an HR before HR/H3 but only if its not the first sub heading under a headingList Rules🔹Rules for lists: Lists can improve readability when used appropriately but should only be used when the context makes sense, don’t overuse lists. Never use numbered lists - Just use * for all unordered lists. Always have a sentence before the list explaining the list, never just have a list after a heading. The sentence should normally end with a colon : and there should not be a blank line between the colon and the first list elementIf using a list, we have a preferred format for lists where each list item has a short bold part followed by a dash (-) and more information:First we always have a short sentence introducing the list:* **Item title in bold** - More information about the itemHowever, if the list is too long (e.g. more than 10 items), use a Markdown table instead. The site supports searching within Markdown tables, which is not useful for short lists but ideal for long ones.Table Rules Always have a sentence before a table - Tables should be introduced by a short sentence that explains what the reader is looking at, rather than appearing immediately after a heading with no context. Avoid excessive spacing - Keep table rows compact so the markdown stays easy to scan and edit. Do not pad table rows with extra spaces - Keep Markdown tables compact so they stay easy to scan and edit. Do not wrap tables in pipe characters - Rows should not start with | because Markdown handles that automatically.Glossary Rules Add a glossary for acronym-heavy pages - If a page uses many technical acronyms or specialist terms, add a short glossary near the top. Link first mention per section - For glossary terms, link the first meaningful mention in each section to the glossary definition; avoid linking every occurrence. Use stable glossary anchors - Add explicit HTML anchors for glossary entries (for example <a id=\"glossary-cop\"></a>) so in-page links remain predictable.Here is an example of a good glossary section (it should be near the top of the page):---## Glossary of Key TermsIf you are new to low-level SNES development terms, this quick glossary should help:* <a id=\"glossary-cop\"></a>**COP** - A 65c816 software-interrupt instruction used here as the SFX-DOS service call gateway.* <a id=\"glossary-irq\"></a>**IRQ** - A normal hardware interrupt used for routine device events.Frontmatter RulesThe frontmatter at the top of each page should follow the current site pattern rather than copying older pages blindly.Use this as the standard shape for new pages:---layout: posttags:- gameboy- leaktitle: Example Page Titlecategory: gameboy# category can also be a list when a page belongs to multiple areas:# category:# - gameboy# - leakimage: /public/images/example.jpgpermalink: /example-pagebreadcrumbs: - name: Home url: / - name: Example Section url: /example - name: Example Page Title url: #recommend:- gameboy- leakeditlink: /path/to/file.mdupdatedAt: '2026-03-29'---These are the main fields and what they are for: Field Purpose layout Usually post for normal RetroReversing pages tags Search/discovery tags for the page, and the values other pages match against in their recommend lists, only use valid tags from valid-tags.json title Full page title shown in the page header and metadata (do not use colons! as it messes with the yaml frontmatter) category Main site grouping such as the games console name or others such as leak, introduction, gameengines, maths, or another section-specific category. This can be a single value (category: leak) or a list (category: [leak, snes]) when a page belongs to multiple categories. image Optional main preview image used by the page and site cards, if there is not a unique one leave it blank and it will be generated based on the category and title, for new pages leave blank (don’t include) placeholderimages Optional list of local repo image paths to blend into the generated placeholder/social image when image and twitterimage are omitted twitterimage Absolute URL version of the preview image for social sharing, leave blank and it will be generated, if in doubt leave blank (avoid using but don’t remove) permalink Final public path for the page (do not end with a trailing /; that is legacy format we are moving away from) breadcrumbs Breadcrumb trail shown at the top of the page recommend Related-topic tags used to build the recommended sidebar and card labels; these should usually be chosen from tags already used elsewhere on the site, only use valid tags from valid-tags.json editlink Repo-relative path used for the “Edit on GitHub” link updatedAt Last meaningful content update date for the page excerpt Optional short summary for pages that need it hidden Optional flag for pages that should not appear in normal discovery videocarousel Optional list used only on pages that embed the video header carousel (avoid using) Some frontmatter keys are now legacy or optional: Only add optional keys when they are actually needed - Avoid copying large frontmatter blocks from unrelated pages tags and recommend do different jobs - tags are the canonical topic labels on a page, while recommend tells the site which tag groups to pull related content from recommend now falls back to tags when it is missing - If you omit recommend, the recommended sidebar and card label will use the page’s tags Only set recommend when you want something more specific - In many cases tags are enough, but recommend is useful when a page should point readers toward a narrower set of related topicsWhen creating a new page, it is better to start from the modern minimal pattern above than to clone an old page with stale fields.Referencing Format📚We use the footnote Markdown format for references, all references should be at the end of the page under a H1 References heading. Each reference is numbered and can be references in multiple places throughout the page using that number like so: [^1].When a footnote appears at the end of a sentence, put the reference before the final period, like text [^1]., not . [^1]If it’s a link, ensure it’s a valid Markdown link so it’s clickable:---# References[^1]: [Reference Name](https://...)[^2]: Page X of Book YExternal links vs citationsFootnotes are for sources backing up claims (dates, attribution, technical assertions, quotes, etc). Not every link on a page needs to be a footnote, especially when the link is there as “further reading” that you want the reader to click.If you include an external link inline as part of a sentence, keep it as a normal Markdown link and only add a footnote if the link is acting as evidence for a specific claim.If an external link is presented on its own line / paragraph or end of a sentence (not inline in a table, list, or middle of a sentence), ALWAYS use the link-to-other-site.html include so it renders consistently and includes a short description:{% include link-to-other-site.html title=\"Example external article title\" url=\"https://example.com/article\" description=\"1-2 sentences describing why this link is relevant.\" %}Linking to other RetroReversing pages🔗You don’t need to reference posts from RetroReversing.com. Instead, just link to the relevant page using the handy include (the permalink must match the post exactly or it will not display):{% include_cached link-to-other-post.html post=\"/permalink-goes-here\" %}Rules for Code ExamplesFor code that could be useful to run interactively in the browser, provide the example in TypeScript. Otherwise, use Python for any scripts intended to run locally.Keep code examples in the standard Markdown format, using backticks with the language name to apply syntax highlighting.For assembly language use nasm to get the correct syntax highlighting.Mermaid DiagramsMermaid can be useful for visualising build flows, folder relationships, or how source files connect together.When using Mermaid: Use it sparingly - Only add a diagram when it makes the structure easier to understand than a paragraph or table would. Bold the first line in each node - If a node has a title and a second explanatory line, make the top line bold so the eye can separate the label from the explanation. Keep labels short - Treat Mermaid like a visual summary, not a paragraph block.Example:flowchart LR A[\"<b>MIFES</b><br>edit source modules\"] --> B[\"<b>ISDMG</b><br>assemble sgb_main\"] B --> C[\"<b>ISLINK</b><br>link sample image\"]Interactive CodeSandpack can be used to run react/typescript:<rr-sandpack template=\"react-ts\" app=\"/public/js/sandpack/examples/SnesRomHeaderViewer.tsx\"></rr-sandpack>Binary ParserSee ../tools/n64RomViewer.htmlfile-parse.html includeFolder listingsWhen a section is listing folder contents, prefer the existing includes over raw HTML or plain bullet dumps: Use connected-folder-tree.html when showing folders with subfolders or a nested directory structurefolder should be the short display name and path should be the longer location, for example folder=\"trunk\" and path=\"agb_bootrom/trunk\"Example:## The FZERO Source code directory (/src/FZERO)The FZERO folder si where the main source code live and it contains the following sub-directories:<div class=\"rr-connected-folder-tree\"> <div class=\"rr-connected-folder-tree__header\"> <div class=\"css-folder css-folder-left rr-connected-folder-tree__folder\" title=\"/src/FZERO\">FZERO</div> <div class=\"rr-post-markdown rr-connected-folder-tree__body\"> <p>The archive is split very neatly into the game itself and the DOS-side tools used to generate its content.</p> </div> </div> <div class=\"rr-connected-folder-tree__children\"> <div class=\"rr-changelog-category rr-folder-tree rr-folder-tree--connected\"> <div> <!-- <div class=\"css-folder css-folder-left wow slideInLeft postImage\" title=\"\"></div> --> <!-- <div class=\"rr-changelog-version\">/</div> --> <!-- <div class=\"rr-changelog-date\"></div> --> </div> <ul class=\"rr-changelog-more\"> <div class=\"rr-changelog rr-changelog-success rr-changelog--connected rr-changelog--first\"> <div class=\"rr-folder-tree-connector\" aria-hidden=\"true\"></div> <div class=\"rr-changelog-badge\">📁 Game</div> <div class=\"rr-changelog-info\">Assembly source code for the game</div> </div> <div class=\"rr-changelog rr-changelog-success rr-changelog--connected rr-changelog--last\"> <div class=\"rr-folder-tree-connector\" aria-hidden=\"true\"></div> <div class=\"rr-changelog-badge\">📁 Tools</div> <div class=\"rr-changelog-info\">C source code for the tools used to make the game</div> </div> </ul></div> </div> </div>Tips for making the pages more visually engaging and readable💡The last thing we want is for our pages to be boring or a chore to read. We are writing about games so it should be fun and visual! This section lists components you can use to ensure posts are not giant walls of text.For sections about a specific game K.C. Munchkin! (1981) - Odyssey 2 When a section is about a specific video game, try to find an image of the box art (e.g. from MobyGames) and use the format below to make it more visually appealing. It includes a link to MobyGames for more information when clicking the caption:## Section related to a Game<figure> <img src=\"https://www.mobygames.com/images/covers/l/84474-k-c-munchkin-odyssey-2-front-cover.jpg\" alt=\"K.C. Munchkin! Odyssey 2 Cover\"> <figcaption> <a href=\"https://www.mobygames.com/game/27443/kc-munchkin/\">K.C. Munchkin! (1981) - Odyssey 2</a> </figcaption></figure>Text for the section...This saves hosting all the images in this Git repository and links back to MobyGames, whose bandwidth we are using for the images.Emoji on left after heading💡If there is a relevant emoji to represent the section covered by the heading you can use it like so:## Heading for your section<div class=\"emoji\">📂</div>Introduction to your sectionCommon emojis that can be used in H4/H5: Comment - 💬 sections that are mainly commentary on a topic Idea - 💡 sections that suggest ideas Tool - 🔧 sections that talk about a tool (e.g IDE, compiler etc) Component / Modular - 🧩 sections talking about libraries or other components Success - ✅ e.g a successful step in a tutorial Warning - ⚠️ Section that warns the reader Error / Stop - ❌ Section that talks about a particular error message Announcement - 📢 - Can be used when a section covers a specific announcement from a company or developer Other site - 🔗 If the section is only talking about another site Time-related section - 🕒Emojis that can be used in any heading but for specific purpose: Contents of a folder - 📂 Used to highlight that this section talks about a specific folder Contents of a file - 📄,🖼️,🎧 Used for sections that talk about a specific file Contents of a archive - 🗜️ Used for sections talking about zip/rar/7z etc archives Contents of physical media - 💾,💿 Used for sections talking about floppy,cd,bluray etc (try to use a real image of the cd,floppy, game cartridge if you have one)Sticker Text STK You can use stickers to break up long sections that don’t have relevant images, but keep them short and use them after headings, mainly useful for sections that introduce a file format or acronym, or short company name:{% include sticker-text.html text=\"STK\" color1=\"#ef548f\" color2=\"#ef8b6d\" %}{% include sticker-text.html text=\"GIF\" color1=\"#0085b6\" %}{% include sticker-text.html text=\"SNK\" color1=\"#ef548f\" %}TabsYou can use tabs to show different variations of the same content, for example if the post has a programming example you could have the Typescript source code example in one Tab and a Python source code example in another. Don’t use it to contain important post information.This is how you use tabs:{% capture tab_1_content %}Contents of Tab 1{% endcapture %}{% capture tab_2_content %}Contents of Tab 2{% endcapture %}{% capture example_tabs %}{% include rr-tab.html title=\"Tab 1 Title\" default=true content=tab_1_content %}{% include rr-tab.html title=\"Tab 2 Title\" content=tab_2_content %}{% endcapture %}{% include rr-tabs.html group=\"example-group\" tabs=example_tabs %}Tab content now defaults to a vertically scrollable area with max-height: 50vh.The maxHeight argument is optional when you want to override that default, for example maxHeight=\"50vw\".Here is an example of what it will render:{% capture c_code_example %}HeadingDefault - C Code would be heresleep(1);{% endcapture %}{% capture asm_code_example %}Assembly code would be here{% endcapture %}{% capture code_example_tabs %}{% include rr-tab.html title=”C Code Example” default=true content=c_code_example %}{% include rr-tab.html title=”Assembly Code” content=asm_code_example %}{% endcapture %}{% include rr-tabs.html group=”example-group” tabs=code_example_tabs %}Code CardsWhen referencing a real source file: Use source-code-card.html and/or source-code-card-grid.html when you are actually showing the contents of a source file, such as its functions, variables, structs, or other internal symbols Its best to float the code card to the side of the text with the rr-code-card-aside class and use it in sections talking about that source file. Don’t have the exact same code card in multiple sections of the same article Do not use code cards just to summarize what a file is for or what companion files sit beside it - use a table or normal prose for that instead The functions, variables, and lines fields on code cards must be exact numeric counts taken from the file contents, not descriptive text or estimates If the exact counts are not known yet, leave the card out until the file has been inspected properly enough to count them In a code-card item like type::name::extra, the final extra field is for function arguments only For variables and other non-function symbols, leave the final field blankWrong: - function::SAVE_FILE1::save wrapper for the first editor familyFunction: - void::SAVE_FILE1::()Variable: - int::Log_Format_2HD Prefer these includes over hand-written decorative HTML so the styling stays consistent across the siteExample floating Code card<div class=\"rr-code-card-aside\" markdown=\"1\"> <div class=\"rr-file-card rr-file-card-aside\"> <img class=\"geopattern\" data-title=\"sfxdos.asm\" /> <h3>sfxdos.asm</h3> <ul> <li> <span>void</span> press_slit<span class=\"rr-func-args\">(FILE *rp, FILE *wp)</span> </li> <li> <span>int</span> fgetw<span class=\"rr-func-args\">(FILE *fp)</span> </li> <li> <span>struct STACK</span> bomb[MAXBOMB] </li> <li> <span>int</span> bomb_count </li> </ul> <div class=\"rr-file-stats\"> <div class=\"rr-file-stat rr-file-stats-functions\">4</div> <div class=\"rr-file-stat rr-file-stats-variables\">8</div> <div class=\"rr-file-stat rr-file-stats-lines\">400</div> </div></div> <div class=\"rr-code-card-aside-content\" markdown=\"1\"> The heart of the stack is `sfxdos.asm`. Its header calls it a `Super Famicom Disk Operation System special version`, programmed by **Y. Nishida** on **29 October 1991**. </div></div>Technical implementationThis section is for lower level programming details about how some of the features on the site work._includes folder📁The _includes folder contains useful components that can be used in posts, this section talks about the style guides for contributing to them.Using comments📝Use comments using the liquid syntax rather than html comments to describe how to use an include as the html include will be added to every page but this one won’t.{% comment %} The comment will not appear in the generated html {% endcomment %}<!-- This comment will appear in generated html -->Image Lazy LoadingTo improve performance, this site uses a custom JavaScript-based lazy loading system for images.Lazy loading ensures that images are only loaded when they are about to enter the viewport, reducing initial page load time.How it works⚙️Any <img> element with the class lazy-load and a data-image-full attribute will be lazy loaded.The src attribute is set dynamically by JavaScript when the image is about to come into view.You can use it like so:<img class=\"lazy-load\" data-image-full=\"/images/highres.jpg\" alt=\"Description\">You may set a low-res or placeholder src if desired, or leave it blank.When the image scrolls into view, the script will set src to the value of data-image-full.Lightbox GalleryThe site uses a jQuery-based lightbox plugin (public/js/lightbox.js) to display images in a modal overlay with optional gallery navigation.How it works⚙️Any image wrapped in an <a> tag with a data-lightbox attribute will trigger the lightbox when clicked.By default, all images with the class postImage are automatically wrapped in such a link by a script in _includes/footer.html.The lightbox supports galleries: images with the same gallery value in their data-lightbox attribute are grouped together for navigation.How to use📝Automatic (for images with postImage class):<img class=\"postImage\" src=\"/images/example.jpg\" alt=\"Example\">These will be auto-wrapped and grouped in a gallery.Custom GalleriesYou can alson have custom galleries with just specific images like so:<a href=\"/images/photo1.jpg\" data-lightbox='{\"gallery\": \"holiday2024\"}'> <img src=\"/images/thumb1.jpg\" alt=\"Photo 1\"></a><a href=\"/images/photo2.jpg\" data-lightbox='{\"gallery\": \"holiday2024\"}'> <img src=\"/images/thumb2.jpg\" alt=\"Photo 2\"></a>", "excerpt": "Thank you for your interest in contributing to RetroReversing! This guide explains some of the formatting guidelines and features you can use to make the posts on the page more engaging. Site Principles The following are the main principles of the site and can help decide not only how to...", "tags": null, "image": "/public/images/RetroReversingLogoSmall.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Capcom Leaks", "url": "/capcomleaks", "content": "On 1st November 2020 CAPCOM was targeted by known hacker group RagnarLeaks and some source code and private data was leaked to the dark web. This post will only cover source code that was found in the leak, we only support the preservation of old PlayStation source code.Information on the RAGNAR malware, that was responsible for compromising Capcom's servers:https://t.co/oZDDbKMQNz— /PPG/ (@pokeprotos) November 16, 2020Files leakedThere were four archives leaked, and due to size were split into multiple 7Zip parts. CAPCOMinr1.7z - No source code (please avoid downloading if you see this file uploaded) CAPCOMPart2ID.7z - Umbrella Chronicles source code (21.1GB in 3 parts) Capcom3ID451.7z - Devil May Cry 2 Source code ( 11.2GB in 2 parts) CAPCOM4_ID442.7z - The Misadventures of Tron Bonne PS1 source code (1.38GB)The archives released after these (5-7) do not contain any source code unfortunately, so will not be covered in this post.Archive 8 contains source code for unreleased Resident Evil games and thus are not considered retro and will not be covered here.Resident Evil Umbrella ChroniclesWhen the archives have been extracted it creates a folder called Wii_バイオハザード アンブレラクロニクルズ which translates roughly to Wii_ Biohazard Umbrella Chronicles. Biohazard is the Japanese name for Resident Evil.The source code for Resident Evil Umbrella Chronicles has many empty folders inside it, it is unclear why this is the case, they could have been removed due to space constraints or maybe a copy job was only part way through before it was stopped.The empty folders will be listed here with their translations just to make you aware of what may have been contained within at some point in time.The way the files are laid out suggest that this was stored on some sort of external hard drive due to the inclusion of $RECYCLE.BIN and System Volume Information folders.Folders at the top Level are: $RECYCLE.BIN - created by Windows OS to hold deleted items (Empty folder) Recycled - Unsure of purpose but empty System Volume Information - contains empty restore folders, probably due to unexpected hard drive disconnect causing corrupted files UC使用フォント - UC fonts used bioUCリビルド手順 - build environment tutorial design - design documents for the game (level layouts etc) サウンド - Sound (Empty folder structure) バイオ納品 - Bio delivery (Source code folder structure) 企画 - Planning (Empty folder structure) 韓国版 - Korean versionUC fonts used (/UC使用フォント)As expected by the name this folder contains fonts used in the development of the game i TTF and TTC formats.It is unclear if these were just used for the game box and manual or if they were also converted to textures for inside the game too.The fonts included in this folder are: CHELSEXR.TTF - Chelsey Extended COMMAEXR.TTF - Commador Extended DF-ReiSho-W6.ttc - Collection of fonts EGGOWN__.TTF - Eggo Wide MLSAX.TTF - Prestige MLSGW.TTF - Architect VOGEB___.TTF - Vogel WKWCHJO.TTF - WKWChongjoUC build procedure (/bioUCリビルド手順)This folder contains a tutorial for how to setup a development environment, including Wii SDK, CodeWarrior and CRI SDK for building the source code to Resident Evil Umbrella Chronicles!Got to hand it to them, the developers of Resident Evil Umbrella Chronicles had good documentation for how to get setup with the codebase. Including installing the Wii SDK, CodeWarrior and the CRI SDK Nice job! #capcomleaks #capcom #wii pic.twitter.com/ntSm1fp4dz— RetroReversing.com (@RetroReversing) November 18, 2020Design documents (/design)The design folder contains a bunch of game design document for Umbrella Chronicles!This includes top down drawings of each of the maps with all the areas of interest mapped such as where to collect items. These files are named like so:bioUC_scenario*_*_* // e.g bioUC_scenario0_0_1This folder also contains some interesting files with the following file formats: .EMDL - AutoDesk Softimage Export Model .RMDL - Revolution Model (Wii 3D Model) .RTSA - Revolution Texture Animation (Wii) .RTEX - Revolution Texture format .SCN (Scene format) .BRRES - Common archive format for Wii assets (models etc)Some of these file formats are covered in our Wii file formats page: Wii File Formats For more information on other Wii File formats check out this post. The Scenes folder looks like it used to contain Softimage XSI assets, but not all the files were copied over so much of the folders are sadly empty.Game Designers at CAPCOM made some excellent documents for Umbrella Chronicles on the Nintendo Wii! #capcomleaks #capcom #wii #ResidentEvil pic.twitter.com/GYcj4ItoxD— RetroReversing.com (@RetroReversing) November 18, 2020Korean version files (/韓国版)This folder contains the following sub folders inside it: BioUC_2D_Kor - 2D assets RECYCLER - empty tree bioUCリビルド手順 - tutorial for setting up development environment (the same content as the folder at the root level) bioUC韓国版テキスト - bioUC Korean version text バイオ納品 - Source code2D Assets (/韓国版/BioUC_2D_Kor)This folder mostly contains TGA images for all the textures and images in the game.The assets are organised into a number of folders: atract - Wii warning messages and starting screens (abstract?) binary - contains tpl, brlan and brlyt format files dialog - tga/rlan/rlyt image assets for dialogs doc - spreadsheets of text for localisation game - empty tree gameover - empty tree icon_banner_kr - empty tree option - empty tree pause - empty tree result - empty tree saveload - empty tree select - empty tree title - empty treeFile formats for 2D assets include: BRLAN (Binary Revolution Layout AnimatioN) - Wii format for title animations (Binary) BRLYT (Binary Revolution LaYouT) - Wii format for layout TPL (Texture Palette Library) - Wii format for texture palettes (colours) RLAN (Revolution Layout AnimatioN) - Wii format for title animations (XML) RLYT (Binary Revolution LaYouT) - Wii format for layout (XML)It looks like this folder was half way through copying when it stopped, as it was probably copying alphabetically, as soon as it got to the doc folder it stopped copying, so the rest of the folders are empty trees.Korean version text (/韓国版/bioUC韓国版テキスト)This folder contains fonts and text messages used throughout the game to be localised from Japanese into Korean.The only file with messages to be translated is called mes_ko.xls and contains thousands of messages (2000+) in Japanese with their Korean counterparts. if you have ever wondered how games get localised into other languages then this is the document you should check out.The fonts are separated into two of folders: Ksマッピング - KS mapping (Korean) WKBGHYSO.TTF WKLYESO.TTF WKWCHJO.TTF WKYESO.TTF S-jisマッピング - S-JIS mapping (Japanese) CGBGHyso.ttf CGLYeso.TTF CGWCHJO.TTF CGYESO.TTF Korean Source code (/韓国版/バイオ納品)For an overview of the Source code folder see the next section as the only source code we have is for the Korean version, for some reason the other versions were never copied over in the leak.Source Code (/バイオ納品 and /韓国版/バイオ納品)The folder name roughly translates to Bio Deliverables and should contain the source code and tools developed for the game.However there is one important point about this folder, it is located in two places in the leak, one is mainly just the empty folder structure and the other is the real deal.The strange thing is the one with the actual content is actually in the Korean version folder (/韓国版/バイオ納品).In the root version it is mainly an empty folder structure but the buildtool does contain some files.Files only in the Root version (/バイオ納品)There are a few files that are only located in the /バイオ納品 folder despite the majority of it being an empty folder structure. They are all located in /バイオ納品/buildtool/buildtool/ and have the following folders: CRI_SDK - CRI Middleware SDK CodeWarrior - CodeWarrior + Plugins + License DevelopmentTools - Wii Development tools MasteringTools - Tools for Wii game publishing NintendoWareForRevolution - NintendoWare tools and runtime libraries for Wii RevolutionSDK - Wii SDKThese are all official software development kit files from Nintendo and CRIware used in many 1st & 3rd party Wii games.Since these are not Capcom specific they will be covered in a future post.Korean version source code (/韓国版/バイオ納品)The rest of this section will discuss the korean version of the source code. It contains the following files and folders: bioUC - C/C++ source code bioUCscript - Game script files (lua etc) buildtool - Nintendo SDK Tools readme.txt - Japanese document outlining the structor of the source code tool - custom tools created by Capcom 北米著作権登録 - North American copyright registrationNorth American copyright registration (北米著作権登録)This is a very strange folder indeed, the translated name might make you think of some sort of legal documents to the North American copyright office.However there are two files in this folder and they are not what I would expect at all: ending.doc title.docJust judging by the names you might think it is the story of the game, but if you actually open the documents you will see they are both C/C++ source code files in MS Word format.Who knows why these exist in this format, very odd indeed!Nintendo SDK Tools (/韓国版/バイオ納品/buildtool)As expected this folder contains all the Software development kits and tools from outside of Capcom. It is split into a number of folders: CRI_SDK - CRIware SDK CodeWarrior - Metrowerks Codewarrior DevelopmentTools - Wii tools created by Nintendo MasteringTools - Wii Mastering tools created by Nintendo NintendoWareForRevolution - NintendoWare tools and runtime libraries for Wii RevolutionSDK - Official Wii SDKTools By Capcom (/韓国版/バイオ納品/tool)This folder contains pre-compiled versions of the tools made for the game by Capcom employees.Some of the tools include: BGObjConv - Background Object converter for object placed in rooms BGObjCreater - Creates background objects from BGObj models BulletHoleVolume - Tool for putting bullet holes in 3d models CharaConv CollisionTool - Converts Collision data Doc FontConv - Convert Font data FontConvLocal - Font localisation FontConvLocal_Multi FontConv_Multi IconBanner - Tool for creating Wii banner ItemModel - Uploads 3D model data to asset server ItemParam - Uploads item parameter data to asset server LayoutConv - converts the output of the LayoutEditor into binary and packs it into an arc archive MakeBRFNT_Tool - Create BRFNT font file from your own images PlayerBulletModel - Converts 3d models for Bullets PlayerWeaponParam - Upload the players weapon parameters to the asset server StageViewer - Creates background data for stagesLua/Ruby/BioForth scripting (bioUCscript)The game uses the LUA scripting language and the Ruby scripting language along with a custom implementation of the Forth language known as BioForth for its game design scripts.The folders contained are: binary - empty tree but would have contained binary compiled versions of the scripts camera - Camera script in EMT format include - C include files used for Lua system - tools used for scripting (e.g lua interpreter) zai - Zombie AI scripts (Ruby) omake - special stage scripts r_alpha - opening cutscene lua script r_alpha_saveload saving and loading Lua script r_biouc - main game management r_e3 - E3 demo script r_halfalpha r_leipzig - Leipzig GC Developers Conference demo r_prepro r_privateshow r_tgs s00c1 - Stage 0.0 Chapter 1 s00c2 - Stage 0.0 Chapter 2 s00c3 - Stage 0.0 Chapter 3 s01c1 - Stage 0.1 Chapter 1 s01c2 - Stage 0.1 Chapter 2 s10c1 - Stage 1.0 Chapter 1 s10c2 - Stage 1.0 Chapter 2 s10c3 - Stage 1.0 Chapter 3 s11c1 - Stage 1.1 Chapter 1 s11c2 - Stage 1.1 Chapter 2 s12c1 - Stage 1.2 Chapter 1 s12c2 - Stage 1.2 Chapter 2 s20c1 - Stage 2.0 Chapter 1 s20c1_e3 - E3 version of Stage 2.0 Chapter 1 s20c2 - Stage 2.0 Chapter 2 s20c3 - Stage 2.0 Chapter 3 s21c1 - Stage 2.1 Chapter 1 s22c1 - Stage 2.2 Chapter 1 s23c1 - Stage 2.3 Chapter 1 s30c1 - Stage 3.0 Chapter 1 s30c2 - Stage 3.0 Chapter 2 s30c3 - Stage 3.0 Chapter 3 s31c1 - Stage 3.1 Chapter 1 s31c2 - Stage 3.1 Chapter 2 s31c3 - Stage 3.1 Chapter 3The scripting file formats used are: .EMT - Custom binary format .LUA - LUA script .H - Standard C/C++ header file .RB - Ruby Script .AI - Zombie AI - Compiled version of (SAI) .SAI - Source Zombie AI scripts in BioForth .CONF - Plain text config .TRAP - traps (custom binary format)C/C++ Source Code (/bioUC)This folder contains: Doc - Documentation for the source code DvdRoot - Contents from the retail disc Project - project build scripts Src - contains the actual source code update_data.bat - batch script to update directory from the main build serverSource Code documentation (/bioUC/Doc)This folder contains documentation for the source code completely in japanese: aiscript.txt - Documentation for the custom scripting language for AI based on Forth ode_script.txt - Documentation for the scripts they use of Open Dynamic Engine objects takahashis - Collision system ゆれもの仕様.doc - WiiMote controller Shake specifications エフェクトについて.txt - Effects such as Blur/Glare/Shadows etc カウンターアクションコマンドについて - Counter action commands カメラ／ライト／フォグについて.txt - About camera / light / fog システム周りについて.txt - About the system スクリーンショット撮影について.txt - About screenshot ability デバッグ支援について.txt - Debugging support データ型について.txt - About Data Types バイオハザードにおけるIK処理負荷.doc - Inver Kinematics (IK) processing load in biohazard パッドについて.txt - Controller Pad プロジェクトの構築方法について.txt - How to build the project フォルダ構成について.txt - About folder structure メモリ確保について.txt - About memory allocation 噛み付きについて - About Zombie Bites 振動エディタ - Vibration editor 描画周りについて.txt - About drawing 音周り - SoundThe file aiscript.txt is fascinating, it describes the custom scripting language they implemented for the movement of the AI characters. It is based on the Forth programming language and they called it bioForth. It is well worth a read if you can translate it.Following on from aiscript.txt you should also read ode_script.txt as it is based on the same custom scripting language. In this case it is used for Open Dynamic Engine physics object creation!Source Code files (/bioUC/Src)Note that the actual development team was outside of Capcom in a company called Cavia so you will see the Cavia copyright at the top of most source files.This folder contains: Common - common code used for multiple games Game - main game code specific to this game Test - test code for collisions/sounds etc Tool - source code to the custom tools they createdTool Source code (/bioUC/Src/Tool)The Tool folder is split into 3 different categories depending where the tool is run: Wii - Tools that are run on the Wii itself Win32 - Windows tools Plugin - Plugin for Softimage XSI 3D modelling toolThere is only one plugin for Softimage XSI and it is for exporting collision data from a Softimage scene. it is aptly named CollisionDataExporter and contains the full Visual Studio project.The Wii Tools that were created by Capcom are: AgingTask BgObjViewer CollisionViewer ColorBar DebugPlayer EventViewer ItemEdit JimakuViewer LightEdit MoterEditor MoveActionEdit MovieViewer ODEEditor PWeaponEditThe Windows based tool that were created by Capcom are: BGObjCreateTool Coll2bin CollDataCnvUtil EnumWindows FontChange FontConv MotorConv bgobjpack bio_txtres convconv csvtbl damageReactionTable damageratetable expression luac_customized nw4r_Conv seqconv sndeffcv uniparam yuvtobmpTest Source code (/bioUC/Src/Test)The Test folder is organised into folders based on the programmer that created the tool: andot (Tomoyuki Ando) - 3D model Viewer test tool hinoy ikedat - Inverse Kinematics test? izawah - Fill rate/Layout and ODE tests izawah2 - same as izawah folder satoud (Daisuke Sato) takahashis - Collision and ODE tests tsukizakis (S.Tsukizaki) yanagisawan - Sound tests yokozawakCommon Source code (/bioUC/Src/Common)This folder contains the C/C++ common across multiple games that Cavia created.It contains the following files and folders: CRI_MW CameraUtil CharaLight Collision Debug Effect Emt Font GXUtil HomeButton Layout MenuTask Model MotionSeq Motor NWSystem Nand ODE Override Pad PrimitiveManager ScreenShot Script Sound Thread Util math movie task_manager wlCommon.hMain Game Source code (/bioUC/Src/Game)This can be seen as the most interesting folder in the entire project as it contains the game specific code in C/C++.This folder is organised into the following files and folders: Actor Boss BulletHole CallbackDRAW Camera Collision EHitAttribute Effect Event GameTask Item KeyConfig Layout Light Main ModelModify Movie Player SaveData SaveLoad SceneAnm Script Stage SubScreen Thunder Vibration bioConfig.h bioDebugTimer.h bioMemoryTag.h bioMenuPage.h bioPrimitivePriority.h bioScnObjPriority.h soundDevil May Cry 2 Source code (Capcom3ID451.7z)When the archive is extracted you get a folder called “02_デビルメイクライシリーズ” which simply translates to “02_Devil May Cry Series”, this folder contains two children: PS2_デビルメイクライ2 - PS2_Devil May Cry 2 マスター画像 - Master image (empty folder)Looking into the one non-empty folder you will find a few files and folders: PS2_デビルメイクライ2【収納されていたパッケージ画像2】.pdf - Photo of the top of the storage box that contained the builds PS2_デビルメイクライ2【収納されていたパッケージ画像3.pdf - Photo of the side of the storage box that contained the builds PS2_デビルメイクライ2【最終バックアップディスク1】.ISO - Final Backup Disc 1 PS2_デビルメイクライ2【最終バックアップディスク1】.html - Final Backup Disc 1 PS2_デビルメイクライ2【最終バックアップディスク1】.pdf - Final Backup Disc 1 PS2_デビルメイクライ2【最終バックアップディスク2】.ISO - Final Backup Disc 2 PS2_デビルメイクライ2【最終バックアップディスク2】.html - Final Backup Disc 2 PS2_デビルメイクライ2【最終バックアップディスク3】.ISO - Final Backup Disc 3 PS2_デビルメイクライ2【最終バックアップディスク3】.pdf - Final Backup Disc 3 PS2_デビルメイクライ2【最終バックアップディスク4】.ISO - Final Backup Disc 4 PS2_デビルメイクライ2【最終バックアップディスク4】.html - Final Backup Disc 4 マスター画像 - Master Image (empty folder)Note the naming of the files might be a little confusing, there are four unique discs (ISO files) here. Rather than 4 different versions of the same disc as I initially thought when viewing the folder.A really cool but unexpected fact about this folder is the inclusion of the photos of where the builds were stored, including the cardboard box which has DMC2 images stuck to it.They are all stored in PDF format for some reason even although they only contain one image. Also contained in pdf format is photos of the CD inside the jewel case.The HTML files in this folder are also quite interesting, they seem to be a list of differences between what is presumably the Master Image and the specific backup discs.This leaves the ISO image files which is exactly where you will find the source code for the game, so lets dive in!A backup of a disk containing DMC2 code was found in the leak. Original is probably in cold storage, sitting at some undisclosed location.The disk contains all software and data needed to compile and run the game. pic.twitter.com/AVd17xjJvc— /PPG/ (@pokeprotos) November 16, 2020Each disc contains a subset of a single large build, this is due to the limited storage size of DVD discs.So there is a readme.txt file at the root of each DVD which lists the final build structure when you merge all the discs together.Disc 1 - PS2 SDKs and 3rd party librariesWhen Disc 1 has been mounted it has the following contents: china - library for Chinese version cri - CRI middleware (ADX/Sofdec/MWSFD) cw - CodeWarrior 3.03J cygwin - cygwin 1.1.x readme.txt - details about the contents of all theDVDs sce - Official PS2 SDK si - SoftImage XSI dataDisc 2 - Source CodeWhen Disc 2 has been mounted it has the following contents: blood_type.txt - Blood Type Meta Data data - data for mastering the DVD disc of the game devil2.bat - just sets environment variables for building the game dipsw.dat - Maybe something to do with DIP switches on the dev hardware? effect.txt - Notes about the player and the enemy’s flying sand smoke effect enemy.txt - some sort of meta data related to player and enemies filename.txt - this looks like a template for creating new files inst.bat - install batch script that copies and deletes data keepflag.txt - meta data about bonus orbs makefile - the main makefile for the project makerom.txt - notes about creating the ISO image module.lst - list of IOP modules (IRX files) mwlib - CRI middleware library files pack.bat pget.bat - batch script for copying data then packing it probar.txt - notes about the loading processing bar prog - C/C++ source code project - CodeWarrior project files data roma.bat - Copy files for America romc.bat - Copy files for China rome.bat - Copy files for Europe romj.bat - Copy files for Japan romk.bat - Copy files for Korea scrchpad.txt - scratchpad memory notes setting.bat - possibly copies ELF file to dev hardware uninst.bat - deletes AutoModelista files (probably copied from that games project files and forgotten to be updated)One surprisingly interesting file is probar.txt which lists the different colours the loading progress bar has and what it is actually doing when it has that colour!Disc 3 - MiscWhen Disc 2 has been mounted it has the following contents: camera - Camera intermediate data ccz - For creating the ISO IMAGE char - Textures - TIM2, IPU data demo - content used for Demo Disc version doc - Text files for localisation movie - contains movie files that wouldn’t fit on Disc 4 orb - Set orb intermediate data set - Enemy set intermediate data sound - Sound data stage - Terrain intermediate data tools - ToolsDisc 4 - Movie filesThis DVD only contained the movie files which would have been located at /devil2/movie in the original build.The contents of the movie folder are as follows: Jiware512.zip billboss512.zip cg_00d.mcj - op/dante video metadata cg_00l.mcj - op/lucia video metadata cg_01.mcj - matihe512 video metadata cg_02.mcj - billboss512 video metadata cg_03.mcj - hliport512 video metadata cg_04.mcj - tower512 video metadata cg_05.mcj - gisiki512 video metadata cg_06.mcj - mon512 video metadata cg_07.mcj - Jiware512 video metadata cg_08.mcj - staff video metadata cg_09d.mcj - next dante video metadata cg_09l.mcj - next lucia video metadata devil2.mcl - INI file containing paths for all the .MCJ files gisiki512.zip hliport512.zip matihe512.zip mon512.zip movie.lst - seems to contain meta data describing the .mdj files next.zip staff.zip - Ending credits video of the game tower512.zipThe .MCJ files seem to have been created by CRI Sofdec CRAFT, these are video files in the CRI Sofdec format. The sofdec format is based on MPEG-2 but has support for CRI’s ADX audio codec.These files are all brought together in the plain text ini files called devil2.mcl.The zip files contain bitmap (BMP) files for each frame of the video! As you would expect these vip files are huge because of it.Note that Disc 3 also contains 3 Movie archives which couldn’t fit on the Disc 4 folder: op/dante.zip op/lucia.zip op/国別512.zip - Country?The Misadventures of Tron Bonne (CAPCOM4_ID442.7z)The root folder is called PS_トロンにコブン which is the Japanese name for the game plus the PS_ prefix for Playstation. It contains three sub folders inside it: 北米版 - North American Edition PAL版 - PAL version (Europe) 国内版 - Domestic version (Japan)Plus the source code of "The Misadventures of Tron Bonne" (screenshot not mine): pic.twitter.com/eutXjxgjel— WaluigiBSOD (@WaluigiBSOD) November 16, 2020PAL Version (/PAL版)There are three folders in the PAL version: ﾏｽﾀｰﾛﾑｲﾒｰｼﾞ - Master ROM image TRON_CD1 - PAL Source Code TRON_CD2 - PAL Toolsﾏｽﾀｰﾛﾑｲﾒｰｼﾞ- Master ROM imageThe Master ROM image folder contains an .img/.cue file combo that is the disc they pressed for PAL regions, you should be able to play this in the PS1 emulator of your choice.It is unconfirmed if there are any minor differences between this and the retail disc that players would buy, but it is unlikely.North American Version (/北米版)There are four folders in the North American version: ﾏｽﾀｰﾛﾑｲﾒｰｼﾞ - Master ROM image disc1 - NA Source Code disc2 - Tools developed by matsuda and shingaki disc3 - NA Toolsﾏｽﾀｰﾛﾑｲﾒｰｼﾞ - Master ROM imageThe Master ROM image folder contains an .img/.cue file combo that is the disc they pressed for North America, you should be able to play this in the PS1 emulator of your choice.It is unconfirmed if there are any minor differences between this and the retail disc that players would buy, but it is unlikely.Japanese Version (/国内版)The Japanese version contains more folders than the other two due to it containing some development tools. tools - tools developed by each member of the development team library - development software such as Multi-ICE ﾏｽﾀｰﾛﾑﾃﾞｰﾀ - Master ROM data pocket - Pocketstation source code psx - PS1 source code and assetsTools (/国内版/tools)Each folder belongs to a member of the development team: ito - Souichi Itou? matsuda - Kouetsu Matsuda misawa - Tsuyoshi Misawa nucky - ? sakano - Mitsunori Sakano shingaki - Hidekazu Shingaki tuji - ?", "excerpt": "On 1st November 2020 CAPCOM was targeted by known hacker group RagnarLeaks and some source code and private data was leaked to the dark web. This post will only cover source code that was found in the leak, we only support the preservation of old PlayStation source code. Information on...", "tags": ["leak","ps1","ps2","wii"], "image": "/public/images/leaks/Capcom Leaks.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Central Point Backup Format Visualiser (CPBACKUP.001,.002..)", "url": "/centralPointBackup", "content": "Central Point Backup RestoringRecently I was sent some really interesting files that are known to contain Spiderman Sega mega drive source assets, they were ripped from floppy disks. However instead of using the normal FAT format it just has 1 file per disk, CPBACKUP.001, CPBACKUP.002 and CPBACKUP.003. These are Central Point Backup files created either from a version of DOS or a really early version of windows, as the files have a timestamp of 1993.Unfortunately Central Point stopped making the software after getting bought out and so there is no version for anything above Windows 3.1.Drop a CPBackup.001 format file such as .001 in the box below to see a breakdown of what each byte means, if you have a .002 or onwards file try concatinating it with the .001 in order: Drop 001 files here to view # References[^1]: http://www.os2museum.com/wp/the-central-point-backup-floppy-format/[^2]: https://www.pcjs.org/disks/pcx86/dos/ibm/5.00/ ", "excerpt": "Central Point Backup Restoring Recently I was sent some really interesting files that are known to contain Spiderman Sega mega drive source assets, they were ripped from floppy disks. However instead of using the normal FAT format it just has 1 file per disk, CPBACKUP.001, CPBACKUP.002 and CPBACKUP.003. These are...", "tags": ["tools","fileformats"], "image": "/public/images/RetroReversingLogoSmall.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Cheat Cartridges & Discs", "url": "/hardware/cheatcartridge", "content": "Action Replay (Datel)Datel first developed their Action Replay cartridges for the Commodore 64 in 1986 1. The Action Replay line then went on to include products for the NES, Super Nitendo, Nintendo 64, Playstation and various handheld consoles.Since Datel have produced many chat cartidges and other custom unlicensed console hardware we have split this section into its own page: Datel Introduction Datel Design & Development Ltd., commonly known as Datel, was founded in 1980. They are known for producing unlicenced video game peripherals, cheat devices, homebrew enablers and other gaming... Multiface (Romantic Robot) (1986)Romantic Robot released their Multiface One for the ZX Spectrum in 1986 2 which allowed Memory Dumps similar to save states in modern emulators, cheats could then be applied to these memory dumps with the POKE command.Vintage Sinclair Archive provides a comprehensive directory of technical resources for the Multiface series (I, 128, and +3). The archive includes essential reverse engineering data such as ROM dumps, hardware schematics, and original user manuals for these legendary NMI-based hardware debuggers and snapshot devices used on the ZX Spectrum. Multiface I, 128, and +3 Archive A file repository containing firmware ROMs, circuit diagrams, and documentation for the Romantic Robot Multiface series, a critical tool for early hardware-level debugging and backup creation on Sinclair systems. Romantic Robot Multiface 128 Re-CreationLost Retro Tapes has a detailed write-up about reverse engineering and re-creating the Romantic Robot Multiface 128 for the Sinclair Spectrum.The author outlines the painstaking process of photographing the original PCB, tracing all component connections and vias with a multimeter to generate a complete KiCad schematic, and then designing a modern, compact PCB layout for fabrication. This recreation provides a fully functional version of the classic game-hacking tool. Romantic Robot Multiface 128 Re-Creation Lost Retro Tapes documents the full hardware reverse engineering and KiCad re-creation process for the iconic Sinclair Spectrum Multiface 128 cartridge. Game Genie (Codemasters)The Game Genie was one of the first Cheat Code cartridges to be developed for home consoles as they realised their first version for the Nintendo Entertainment System (NES) in 1990.Game Genie: History and FunctionalityGaming Historian presents a detailed history of the Game Genie, a popular cheat device originally developed by Codemasters. The video covers the legal battles between Nintendo and Galoob (the US distributor) over copyright infringement and derivative works, eventually establishing important precedents for fair use in gaming.It also briefly explains the technical method of operation: the device intercepts and modifies data signals between the game cartridge and the console (e.g., preventing the “lives” counter from decrementing) to enable cheats like infinite lives.Legal Court Cases against NintendoNintendo feared that this would either cause harm to their brand or make game piracy even easier and thus decided to sue Galoob Toys and Camerica.Both companies eventually won the court case after four long years and got a nice bonus out of it: $140 million! This cash injection more than covered their court fees and allowed Codemasters to expand and develop more games 3.Lewis Galoob Toys, Inc. v. Nintendo of America, Inc.Justia hosts the full text of the landmark 1991 U.S. District Court decision that validated the legality of the Game Genie.The court ruled that the device, which temporarily modifies game data to enable cheats (like infinite lives), does not create an infringing “derivative work” because the changes are not permanent. Furthermore, it established that a consumer’s private use of the device to alter their own purchased games constitutes fair use, setting a vital precedent for reverse engineering and aftermarket software tools. Legal Ruling: Galoob v. Nintendo (Game Genie) The official 1991 ruling in Lewis Galoob Toys, Inc. v. Nintendo of America, Inc. confirmed that the Game Genie's temporary data alteration was fair use and not copyright infringement. How was the Game Genie cartridge developed?In an interview with GSHI (a now defunct website) Richard Aplin who worked on the Game Genie line of products as a hardware engineer had the following to say 4: We had no way to get any info on the hardware or software of the consoles (and we had a very litigious relationship w/Nintendo) , so we did it “the hard way” by reverse-engineering them - by literally going to a store, buying a few systems, tearing them apart, and attaching a logic analyser to them. A logic analyser is basically like a digital oscilloscope (shows you what high-speed signals are doing in real time) but typically has lots of separate channels (32-48).You connect each channel to signals/chip pins that look “interesting” inside your console, run the analyzer, then spend some time figuring out what all the signals are doing and what the hell is going on. Once you’ve got the basic signals figured out (typically you want to figure out the pinout of the cartridge connector) - found the address and data bus of the CPU and the basic control lines (Read, Write, etc) then you’ve got to the point where you can typically build a ‘dev board’.He then goes on to explain the contents of the dev board: We’d build a PCB (with suitable cartridge edge connector on it) that contained an EPROM, an FPGA, a bunch of SRAM, a high-speed parallel port, and typically for fun a 2-line LCD display and some lights.The eprom contained whatever boot code was required to get the console booted, then it entered a monitor program where you could remotely view/change the console memory using the parallel port on the board.The parallel port always used the ubiquitous “PDS” style interface (PDS= Programmers Development System, at the time a very widely used - and very fast - PC-based cross-assembling system by Andrew Glaister and others) so everything was fairly standard.How were Game Genie Codes created officially?In the same interview Richard Aplin explains that they created custom hardware and software running on a Commodore 644: We usually used a custom PCB that had (typically) a parallel port, a passthru connector for the original cart, and basic byte-replacement hardware. Also a few simple tools running (I think) on a Commodore 64.This software was presumably very similar to how Cheat Engine works, take a dump of memory, loose a life in the game, then take another dump and compare the memory addresses that have changed.For the ROM level cheats it would be harder, presumably they would take a full ROM dump and run it through a disassembler as best they could, then see what the program counter’s value is at when it writes to the memory address you are interested in and find that in the disassembly.The CodemeistersAlso I love this quote from the same interview, it shows just how time consuming it would be to support a whole book of codes for the NES library 4: They had teams of people making codes (a guy called Graham Rigby was the main Codemeister - he lived in a room full of nothing but shelves and racks of NES games - he had every NES game in every territory I think)Presumably they has similar rooms with Game Boy, Game Gear and Sega Mega Drive games stacked high, I wonder what happened to all those games!ReferencesAll Posts tagged with Cheat Cartridges Datel Action Replay Professional (N64) Datel Action Replay Professional V-Ram functionality You could press a “Freeze button” on the Action Replay to “see images not normally visible during playing of the game”. The video seems... ... Read More n64 memory cheatcartridge datel Action Replay - ReplayResources ↩ Sinclair User Magazine Issue 047 : Internet Archive ↩ Retro Volume 1 (Page 54) ↩ Richard Aplin (Game Genie Developer) - Hackers of Lore Q&A; - GSHI ↩ ↩2 ↩3 ", "excerpt": "Action Replay (Datel) Datel first developed their Action Replay cartridges for the Commodore 64 in 1986 1. The Action Replay line then went on to include products for the NES, Super Nitendo, Nintendo 64, Playstation and various handheld consoles. Since Datel have produced many chat cartidges and other custom unlicensed...", "tags": ["hardware"], "image": "/public/generated/placeholders/hardware-cheatcartridge.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Chicken Run Source Code", "url": "/Chicken-Run-Source-Code", "content": "Developed by Blitz Games (formerly known as Interactive Studios Limited) in 2000 as a cross platform action adventure game based on the movie with the same name.Throughout the engine you will find referenced to the acronym isl (Interactive Studios Limited) e.g islfile, islfont etc.Act (Level) DataOn Dreamcast each act has its own folder each with its own .BFF and .SPT and some containing region specific .SBB/.SBH files.On PC each act also has its own folder plus the addition of .WAB files accompaning the .BFF and .SPT files.On PS1 the layout is completely different, presumably the data is compressed in CRTEST.DAT. it also contains a file called DUMMY which just contains padding 00 bytes.BFF files (Big file format?)There is a very helpful comment at the top of the bff_load.c file which explains what BFF files are:Quickie guide to BFF files:- A BFF is, simply, a collection of data segments, prefixed by a TYPE, a SIZE, and an ID (the CRC of a name)Data of many different types can just be shoved together into one file.After loading, the program scans through the list, checks the type of each segment, and calls a \"link\" routinefor that type, which basically fills in any required pointers. Then there's a little routine saying \"find a bff segment of \"such&such type, with this name-CRC\"In the header file it also mentions: // All the types of object that you stick into a BFF need to start with a standard header// which allows the BFF routines to seek out specific objects on request.// \"id\" is long something like \"PSA0\" or \"COL1\" for PSA and collision data,// for identifying the TYPE of the block it is.// \"len\" is the length of the block, including the header.// \"crc\" is the CRC of the name of this specific entry, to distinguish it from any// other blocks of the same type.typedef struct BFF_HeaderTag{\tunsigned long id;\tunsigned long len;\tunsigned long crc;}BFF_Header;SPT FilesUsed for File streaming, seems to be used for both texture and sound streaming.CRTEST.DAT (PlayStation 1)This is where the Chicken Run game data is stored on the PS1 version instead of the folder based layout of the PC and Dreamcast.It has a magic number of FLA2, not sure why, did they ever have a FLA1, what does FLA even stand for?static char FILEIO_CDINDEX[64] = \"\\\\CRTEST.DAT;1\"; //\t\"\\\\MYGAME.DAT;1\"#define FLA_MAGIC\t\t\t0x32414c46\t\t\t// Magic number 'FLA2' INTELGames Referenced in the Source codeDevelopers tend to reuse the same engine or parts of the same engine for multiple games across a wide range of platforms (one of the beenfits of writing in cross-patform C), which means there are other games that will share many of the same source files used in chicken run. Here is a list of games that have been referenced in the source code: Glover Action Man 2 Frogger 2Dreamcast EngineMost of the Dreamcast specific code has a DCK_ prefix, presumable short for Dreamcast Katana (Katana was the code name for the Dreamcast).Some example: DCK_System DCK_TexturePresumably there were versions of this code with N64 and PS1 prefix used at ISL but they weren’t released with this source code unfortunately. As most of the game code is cross platform but these files contain the very platform specific code for the Dreamcast.Compiling for PlayStation 1 with PSYQSo although it was originally compiled for PS1, all the sourcecode has been modified for the Dreamcast version so it will need some modifications in order to compile for the PlayStation.The following files won’t compile to PS1 without modification: types.cHowever the root/cr/source folder contails a makefile.mak which is for psyq and build the PS1 version.There are a 2 linker files crtest.lnk and crdemo.lnk which are for the PS1 development tool PSYLINK.EXE you can find out more about there files here: http://www.retroreversing.com/ps1-psylinkThese files are vital for piecing together the PS1 source code as it contains the exact specifications for the object files and libraries that were linked in to get the final and demo executables for the PlayStation.Missing FilesAs with most leaked source code there are some missing files these are: shinobi.h (Dreamcast SDK) sg_syhw.h (Dreamcast SDK) km*.h (Dreamcast SDK)C Game Source CodeSome of the source code for the game Chicken Run has been available to the internet as part of a “Dreamcast source code” bundle. After extracting the archive we are presented with two folders, “simple model shell” and “cr”.Presumably cr stands for chicken run and the simple model shell is a tool to display some of the 3D models as they would appear in the game engine.Simple Model ShellThis tool would have been very useful for artists when exporting their models from their modelling software such as 3ds max or maya, as it will show what optimizations need to be made to the model. Filename Description Category DCK_Maths.c     DCK_Maths.h     DCK_System.c     DCK_System.h     DCK_Texture.c Texture handler routines   DCK_Texture.h     DCK_Types.h     actor2.c     actor2.h     bff_load.c     bff_load.h     crc32.c     crc32.h     fixed.c     fixed.h     gte.c Gte PlayStation emulation routines and structures   include.h     islfile.c     islfont.c font support - AM2 PS (c) 1999-2001 ISL (AM2 = Action Man 2 Destruction X for PS1)   isltex.c Texture and VRAM management   islutil.c ISL PSX LIBRARY\t(c) 1999 Interactive Studios Ltd.   islutil.h     layout.c     layout.h     main.c Main core routine and system initialisation - This file is part of Frogger II, Copyright 2000 Interactive Studios Ltd   main.h     makefile     maths.c This file is part of Frogger2, (c) 1999 Interactive Studios Ltd.   maths.h     newpsx.c     newpsx.h     psi.c PlayStation Model (i) Handler - PSX CORE (c) 1999 ISL   psi.h     psiactor.c     psiactor.h Skinned model control routines   psitypes.h ISL PSX LIBRARY\t(c) 1999 Interactive Studios Ltd.   quatern.c     quatern.h PSX CORE (c) 1999 ISL   sbinit.c Copyright (C) 2000, Sega of America Dreamcast   shell.c     shell.h     sonylibs.h     sprite.c This file is part of Frogger2, (c) 1999 Interactive Studios Ltd.   sprite.h     types.c     types.h     ultra64.h n64 header (Copyright (C) 1994, Silicon Graphics, Inc.)   CR (Chicken run source)We actually have multiple versions of the chicken run source code: the main cr folder source folder under cr (ps1 makefile so guessing ps1) “Copy of Source” folder under cr (?)This was very common before good version control software such as git came along, so developers would work in separate folders and merge changes, or keep different console ports in different folders.The main files in cr are: Filename Category Description DCK_Maths.c     DCK_Maths.h     DCK_System.c     DCK_System.h     DCK_Texture.c     DCK_Texture.h     DCK_Types.h     DC_TIM.c     DC_TIM.h     DISPSTR.C     DISPSTR.H     PSX_PC.h     USR.H     Usr.c     actor.c     actor.h     actor2.c     actor2.h     adxtest.c     adxtest.h     anim.c     anim.h     backup.c     backup.h     bff_load.c     bff_load.h     bpacsetup.c     bpacsetup.h     bpamsetup.c     bpamsetup.h     camera.c     camera.h     card.c     card.h     catapult.c     catapult.h     charactr.c     charactr.h     chase.c     chase.h     chicken.scr     chickenrun.cpj     cntrscn.c     cntrscreen.c     collide.c     collide.h     construct.c     construct.h     cr     cr.dsp     cr.dsw     cr.ncb     cr.opt     crate.c Animation Chase sequence featuring Mrs Tweedy hanging from the airplane crate.h     crc32.c     crc32.h     credits.c     credits.h     curtains.c     curtains.h     cus_anim.c     cus_dyn.c     cus_full.c     custom.c     custom.h     custom2.c     dc_timer.c     dc_timer.h     dctext.xls     debris.c     debris.h     demo.c     demo.h     deth.c     deth.h     dogchase.c     dogchase.h     dualshock.c     dualshock.h     ectsmenu.c     ectsmenu.h     egglaying.c     egglaying.h     empty.c     empty.h     enemies.c     enemies.h     engine.c     engine.h     error.h     fireworks.c     fireworks.h     fixed.c     fixed.h     fma.c     fma.h     fx.c     fx.h     fxtest.c     fxtest.h     gallery.c     gallery.h     gametext.h     gametext.txt     global.h     gte.c     help.c     help.h     incbn     include.h     includeps     inventory.c     inventory.h     islcard.c     islfile.c     islfont.c     isllocal.c     islpad.c     islsfx2.c     isltex.c     islutil.c     islvideo.c     islxa.c     language.c     language.h     layout.c     layout.h     lcdicons.h     lev_flow.c     lev_flow.h     lights.c     lights.h     loading.h     loadlnd.h     loadsnd.c     loadsnd.h     main.c     main.h     makefile     map.c     map.h     map_draw.c     map_draw.h     map_play.c     map_play.h     map_view.c     map_view.h     maths.c     maths.h     menu.c     menu.h     mssccprj.scc     newpsx.c     newpsx.h     nme_dogs.c     nme_mrst.c     ok.h     options.c     options.h     overlay.h     overlay1.c     overlay2.c     overlays.c     overlays.h     pad.c     pad.h     particle.c     particle.h     pause.c     pause.h     platcoll.c     platform.c     platform.h     powerbar.c     powerbar.h     psi.c     psi.h     psiactor.c     psiactor.h     psitypes.h     puzzles.c     puzzles.h     quatern.c     quatern.h     ranges.h     route.c     route.h     saveicon.h     saving.h     sbinit.c     scenics.c     scenics.h     seesaw.c     seesaw.h     sfxtest.c     sfxtest.h     shell.c     shell.h     snapshot.c     snapshot.h     sonylibs.h     sound.c     sound.h     source     sprite.c     sprite.h     sprouts.c     sprouts.h     sptstream.c     sptstream.h     startup.c     startup.h     station.c     station.h     stilts.c     stilts.h     subgame.c     subgame.h     test.c     text_ids.h     timer.c     timer.h     types.c     types.h     ultra64.h     viewer.c     viewer.h     vmucheck.c     vmucheck.h     vssver.scc     wings.c     wings.h     Data Structures Name Category Description A2TS_STATEREF     A4TS_STATEREF     ACTORLIST     ACTOR_SHADOW     AM2_STREETSTR     ANIMATION     ANIM_ANIMATION     ANIM_DATA     ANIM_SEGMENT     BACKUPINFO     BFF_HeaderTag     BMP_HeaderInfoType     BMP_HeaderType     BMP_RGBType     BOUNDINGBOX     BOX     BYTEVECTOR     CARDSTR     CARD_HEADERSTR     CARD_SAVE_STR     CASEDATA     CASERECORD     CHARACTERINFO     CHARACTERVARSTR     COLLIDEBOUNDSTR     COLLSPHERE     COLL_PLAT_CACHE     COLOUR     CONSTRUCT_DATA     CONTROLMAP     CON_CAMERA     CON_CHICKEN     CON_MRTWEEDY_CAM     CON_RYTHM_DISPLAY     CricketScore     CurrentData     D2M_TMD_P_FG3I     D2M_TMD_P_FG4I     D2M_TMD_P_FT3I     D2M_TMD_P_FT4I     D2M_TMD_P_GT3I     D2M_TMD_P_GT4I     D2M_TMD_P_SP4I     DCKBYTEVECTOR     DCKFLOAT2DVECTOR     DCKSBYTEVECTOR     DCKSHORT2DVECTOR     DCKSHORTVECTOR     DCKVECTOR     DCTIMER     DEBRISSTR     DIRECT2MESH     DISPLAYABLETEXT     DUELVECTOR     EGGLAYING_CTRL     EL_CHICKEN     EL_EGG     EL_PANEL     ENEMYBFFLIST     ENEMYDEF     ENEMYGLOBALS     ENGINECTRL     FIREWORK_DATA     FIREWORK_SPARKS     FMA4_GT3     FMA4_GT4     FMACTRL     FMADATA     FMAOBJECT     FMAPLAYEDSTATUS     FMASTATUS     FMA_G3     FMA_G4     FMA_GT3     FMA_GT4     FMA_MESH_HEADER     FMA_WORLD     FMA_WORLD2     FOG     FRAMELIST     FVECTOR     FX_PARTICLE     FX_PARTICLE_SYS     GETMATSTR     GamePlayDataType     GameSaveDataType     IQUATERNION     KEYFRAME     KEYFRAMESHORT     LCOORD     LEVINFO     LIGHT_MOBILESTR     LIGHT_MOVEPOINT     LVERT     MAPDRAW_CLIPCHECKSTR     MATRIXI     MENUDATAFMA     MOVEDATA     MRT_TORCH_STR     NAMEVALUE     OBJECTSPRITE     OPTIONDATASTR     PATROLDOGSTR     PLANE     PLATFORM_BIG_DUMMY_DEFSTR     PLATFORM_CONVEY_DEFSTR     PLATFORM_CONVEY_WORKSTR     PLATFORM_POINTTAG     PLATFORM_POINTX_TAG     PLATFORM_PUSHABLE_DEFSTR     PLATFORM_PUSHABLE_WORKSTR     PLATFORM_ROTATING_DEFSTR     PLATFORM_SAVESTR     POINT2D     POSMARK     PSITEXTURES     PUZZLEVARSSTR     QUATERNION     QUATERNIONSHORT     RAILDATA     RAILRECORD     RGBCD     ROUTEBOX     ROUTEBOX_VECTOR     ROUTEFIND_STR     ROUTE_BOXISECT_STR     SCENICSTR     SCENIC_BFF     SFX     SHORT2DVECTOR     SHORTQUAT     SHORTXY     SKEYFRAME     SKINVTX     SLERPSTR     SOUNDTRIGGERLIST     SOUND_BFF     SOUND_TRIGGER     SPECIALLEVEL_SWITCHSTR     SPOT_SFX     SPRITELIST     SPRITE_ANIMATION     SPRITE_ANIMATION_TEMPLATE     SPROUTMANAGER     SPROUTSTR     TAGACTION     TAGACTION_FIVESHLONGS     TAGACTION_FOURSHORTS     TAGACTION_GOTO_LEVEL     TAGACTION_LEAD_ACTION     TAGACTION_OBJECT_USABLE     TAGACTION_PLAY_SAMPLE     TAGACTION_SETOBJECTPARAMETER     TAGACTION_SETVAR     TAGACTION_SET_SCENIC_ANIM     TAGACTION_TASK_COMPLETED     TAGACTION_VECTOR     TAGACTOR2     TAGCONDITION     TAGCONDITION_BUTTON_PRESSED     TAGCONDITION_IN_BOX     TAGCONDITION_NEAR_POINT     TAGCONDITION_OBJECTPARAMETER     TAGCONDITION_TASK_COMPLETED     TAGCONDITION_VARIABLE     TAGLEVEL_VISUAL_DATA     TAGPLANE2     TAGPOLY     TAGPUZZLE     TAGPUZZLIST     TAGRGBCD     TAGSPRITE     TAGWORLD_VISUAL_DATA     TAG_MALLOC_LIST_TYPE     TAG_MALLOC_TYPE     TEXANIM     TEXANIMFRAME     TEXANIMHEADER     TEXANIMLIST     TEXINSTANCE     TEXTCTRL     TEXTURE_ANIMATION     TMD_P_FG3I     TMD_P_FG4I     TMD_P_FT3I     TMD_P_FT4I     TMD_P_GT3I     TMD_P_GT4I     TPOINT     TVECTOR     UBYTEVECTOR     VECTOR2D     VKEYFRAME     WINGCTRL     WM_BARS     WM_CHICKEN     WM_PROGRESS     WORLD_MESH_INSTANCE     XA_INDEX_STR     XYSHORT     _ACTOR     _CAMVARS     _DCKMATRIX     _DCKOBJECT     _DCKPOLYGON     _DCKQUATERNION     _DCKVERTEX     _DEBRIS_FLAG_SUB_TYPE     _DEBRIS_FLAG_TYPE     _DSHOCK_EVENT     _EXLIGHT_DATA_TYPE     _EXLIGHT_RGB     _EXLIGHT_TYPE     _FileIODataType     _LanguageDataType     _PadDataType2     _PadPacket     _Point2DType     _Point3DType     _RAILDATA     _TIM_HEADER     _TIM_PIXELDATA     _VMUCHECK     _XADataType     _displayPageType     animation     catDeviceStr     catDroneStr     catFloaterStr     catStr     controlType     countDownTimerStr     deviceStr     dogType     dogchaseChickenType     doorType     dustType     fireDrone     fireFlap     gametimerType     inventoryType     light     link     mattressStr     optionsScreenType     seesawDroneStr     seesawStr     soundType     spotliteDrawScratch     stiltsStr     tagBMPHeaderType     tagCAMINFO     tagCHARACTER     tagCHARACTERLIST     tagCOLLBOX     tagCOLLDATA     tagCOLL_BFF     tagDEMOFRAME     tagENEMY     tagENEMYINFO     tagENEMYLIST     tagENEMYPOINT     tagFMAINFO     tagMAPCAMDATATYPE     tagMAPDATA     tagOVERRIDE     tagPARTICLE     tagPARTICLEFX     tagPARTICLEFXLIST     tagPLATFORMDEF     tagPLATFORMWORK     tagRAMPHEADER     tagREBDATA     tagTXTATTRIB     tag_VENT     u162DVECTOR     u16VECTOR     PlayStation 1PS1 GameShark cheatsThe table below lists the relevant entries. Name Code Max Eggs 800AA1D0 0063 1 Have All Map Pieces (GS 2.2 or Higher Needed) 50000901 0000 300AA1F1 00011 Game Credits Fred Williams (Lead Programmer) - https://twitter.com/RFredW // I'll do these things for platforms, with a view to copying 'em into the main collision code// when it's free. Luv, Fred. Tom Drummond (Programmer) David Harries (Programmer) - https://www.linkedin.com/in/david-harries-92a56213/ Barry Peterson (Programmer) Chris Wilson (Programmer) James Steele (Tools Programming) - https://www.linkedin.com/in/james-steele-0a62791/ c// Since Fred insists on being such a clever bugger and using in-line assembler, this file contains a load of macros so that the custom.c, custom2.c and map_draw.c compile and work on the PC as well as the PSX without me having to write a whole load of PC draw routines.// James Steele Chris Wilson (Tools Programming) /*\tCurtains.c - by Chris WilsonIt's curtains for you, my lad!*/ Ian Bird (Additional Programming) - https://www.linkedin.com/in/ian-bird-19358780/ Steve Bond (Additional Programming) - https://www.linkedin.com/in/steve-bond-b21ba9/ Scott Lamb (Additional Programming) - https://www.linkedin.com/in/scottjameslamb/ (SL: in comments) Andy Sidwell (Additional Programming) John Whigham (Additional Programming) - https://www.linkedin.com/in/john-whigham-b8524834/ Richard Hackett (Compression Technology) - https://www.linkedin.com/in/richard-hackett-4324531Also thanks to Phillip and Andrew Oliver who founded Blitz Games - http://www.olivertwins.comReferences http://www.cheatcc.com/psx/codes/chickenr.html#ixzz5RAbHltbW ↩ ↩2 ", "excerpt": "Developed by Blitz Games (formerly known as Interactive Studios Limited) in 2000 as a cross platform action adventure game based on the movie with the same name. Throughout the engine you will find referenced to the acronym isl (Interactive Studios Limited) e.g islfile, islfont etc. Act (Level) Data On Dreamcast...", "tags": ["dreamcast","ps1","pc","games","sourcecode"], "image": "https://img.youtube.com/vi/thRXO3YwOCg/0.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Codemasters (Creator of the Game Genie)", "url": "/companies/codemasters", "content": "History of CodemastersCodemasters is a British video game developer and publisher known for its long history in the gaming industry.It was founded by brothers Richard and David Darling in 1986.The company initially began by developing and publishing games for home computers of the era, such as the Commodore 64, ZX Spectrum, and Amstrad CPC.HardwareGame GenieGame Genie was a series of video game enhancement devices developed by Codemasters and distributed by Galoob (later acquired by Hasbro). It was first released in 1990 for various gaming consoles, including the Nintendo Entertainment System (NES), Sega Genesis/Mega Drive, Super Nintendo Entertainment System (SNES), Game Boy, and Sega Game Gear.The Game Genie allowed players to input special codes, known as “cheat codes,” which modified the behavior of games. These codes could enable features like unlimited lives, infinite ammunition, invincibility, and other gameplay enhancements that were not normally available in the game. Players could enter these codes through a simple interface before starting their game, and the effects would take place during gameplay.CD-ROM for the Nintendo Entertainment SystemIn issue 1 of the UK Magazine GamesX the following was printed:Sadly this was just the company Camerica jumping the gun to announce a product that hadn’t even began development (no prototype or even designs) as confirmed by David Darling himself 1.Software (Games)Here is a list of the games codemasters are most famous for: Micro Machines - NES, Sega Mega Drive/Genesis, Super NES, Game Boy, PlayStation, Microsoft Windows Colin McRae Rally - PlayStation, Microsoft Windows, Game Boy Color, Game Boy Advance, PlayStation 2, Xbox, Nintendo DS, iOS, Android TOCA Touring Car (later became Race Driver series) - PlayStation, Microsoft Windows, Game Boy Color, PlayStation 2, Xbox, PlayStation Portable, Nintendo DS Operation Flashpoint - Microsoft Windows, Xbox, PlayStation 2, Xbox 360 Dizzy - Various home computer platforms including ZX Spectrum, Commodore 64, Amstrad CPC, NES DiRT - PlayStation 3, Xbox 360, Microsoft Windows, PlayStation 4, Xbox One, macOS, Linux F1 - PlayStation, Microsoft Windows, PlayStation 2, PlayStation 3, PlayStation 4, Xbox, Xbox 360, Xbox One, macOS GRID - PlayStation 3, Xbox 360, Microsoft Windows, PlayStation 4, Xbox One, Stadia Overlord - Microsoft Windows, Xbox 360, PlayStation 3 Bodycount - PlayStation 3, Xbox 360References Codemasters Was Supposed To Make A NES CD Drive, But It Never Happened - Time Extension ↩ ", "excerpt": "History of Codemasters Codemasters is a British video game developer and publisher known for its long history in the gaming industry. It was founded by brothers Richard and David Darling in 1986. The company initially began by developing and publishing games for home computers of the era, such as the...", "tags": ["companies","industry"], "image": "/public/generated/placeholders/companies-codemasters.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "C/C++ Compiler Toolchains (Console & PC)", "url": "/compilers", "content": "When reverse engineering commercial console binaries built from C/C++, the first question is often which toolchain produced the code as it can make your job reverse engineering a game so much easier.On 1990s–2000s consoles you will encounter both GCC-derived compilers and a wide variety of proprietary compilers such as: MIPSpro CodeWarrior Hitachi SHC ARM SDT/ADS Microsoft VC++ (including WinCE for dreamcast)What is a Compiler Toolchain?Compiler toolchain here means the C/C++ compiler front end plus the assembler, linker, C runtime, and some low-level runtime libraries shipped in an official SDK.Each platform had an official prefferred compiler toolchain but this does not mean that the game you are reversing was compiled by it! Some of the main compiler toolchains for each console platform are listed in the table below: Platform Primary official compilers (high-level) Notes PlayStation (PS1) GCC-based flow in PSY-Q feeding SN Systems assembler/linker Later PS1 builds also saw 2.8.x-based drops. 1 Sega Saturn Hitachi SHC and a bundled GNU SH-2 (GNUSH) in PSY-Q Teams used either; both target the same ABI. Nintendo 64 SGI MIPSpro on IRIX as baseline Windows-based Partner-N64PC and SN Systems kits provided GCC-based options based on 2.7.2; many studios used these, but IRIX MIPSpro remained the reference SDK. [^3] Sega Dreamcast Hitachi SHC via Katana; Microsoft VC++ for the WinCE path Sega also licensed CodeWarrior late-gen; all official, non-GCC. 3DO ARM SDT / ARM C++ (proprietary) ARM toolchains predate GBA/DS era use. PlayStation 2 ee-gcc 2.95.2, iop-gcc 2.95.x (Sony/SN builds) GCC-based official cross tools for EE/IOP. GameCube Metrowerks CodeWarrior Official Nintendo SDK path. PSP SNC (SN Systems) Official compiler; GCC commonly seen only in homebrew. PlayStation 3 SNC and SCE GCC (PPU/SPU) Two official compilers shipped side-by-side. Homebrew toolchains (devkitX family, etc.) are intentionally excluded from the table above.Why is knowing the Compiler useful when reverse engineering?Knowing the likely toolchain helps you interpret calling conventions, codegen idioms, and debug-stub artifacts.How can I detect which compiler was used?Specific toolchains leave stable fingerprints: stack frame layout, prologue/epilogue shapes, switch lowering, delay-slot policy, PIC setup, section naming, and archive formats. These let you move faster when mapping unknown functions.GNU Compiler Collection (GCC)GCC Releases by YearThe following table will list the first major version released on the specific year, this can be useful to see what versions would have been in use in a certain date period 2. Year Version Notes (GCC forks / console SDKs) 1987 1.0 Initial GNU C release. 1988 1.21   1989 1.35   1990 1.37.1   1991 1.39   1992 1.41   1993 2.4.x   1994 2.5.8 Saturn: Sega/SN shipped a GNU C (SH-2) compiler with Psy-Q; Hitachi SH assembler also included. Jaguar: GCC was used in the Atari Jaguar SDK, specifically version 2.5.x 1995 2.7.0 PS1: PSY-Q used a GNU C/C++–derived backend plus SN assemblers/linker (mid-90s). 1996 2.7.2 Saturn: Cygnus GCC 2.7 build (Sep 1996) in circulation. 1997 2.7.2.2 N64 Partner-N64PC based on GCC 2.7.2 released by SNSystems. Net Yaroze: DJGPP-based GCC 2.7.2 toolchain (released mid-90s, kits shipped 1996–97). 1998 2.8.0 PS1: SN Systems also distributed experimental GCC 2.8.0/2.8.1 builds. 1999 2.95 PS2: IOP toolchain (iop-gcc) based on GCC 2.95.x. 2000 2.95.2 PS2: EE toolchain (ee-gcc 2.95.2) in official SDKs. 2001 3.0   2002 3.1 Homebrew GBA toolchains (devkitadv) used GCC; official GBA dev favoured ARM tools. 2003 3.3 Early DS homebrew starts settling on GCC; official tools still CodeWarrior. 2004 3.4 DS/Nitro: some SDK packages also exposed GCC via Cygwin. 2005 4.0 PSP: official SNC compiler (non-GCC); homebrew psptoolchain used GCC 4.x. 2006 4.1 PS3: official SDKs shipped SNC and SCE GCC (ppu-gcc/spu-gcc). IBM Cell SDK on Linux used GCC too. 2007 4.2   2008 4.3 Wii homebrew (devkitPPC) widely GCC-based 2009 4.4   PS1 PSY-Q - GCC 2.7/2.8PSY-Q shipped with a customized GCC front end that emitted the original 32-bit MIPS I assembly consumed by SN Systems’ assembler/linker to produce a PS-X EXE PlayStation 1 executable. 1MIPS I o32 Application Binary Interface (ABI)The o32 ABI is the convention used by classic MIPS I CPUs like the PlayStation 1’s R3000A, defining things like argument passing, stack layout, and binary object file format. It ensures that the assembly and binaries produced by the compiler/toolchain match what the hardware and system expect.Here are some of the rules in the o32 ABI that the compiler needs to follow: Args in a0..a3, return in v0 (and v1 if needed) Callee-saved: s0..s7, sp, ra Typical 16-byte outgoing arg area reserved in framesPartner-N64PC - GCC Compiler for N64 (2.7.2)Nintendo’s Partner-N64PC packages shipped with a GCC bundle (e.g., Debugger v1.08D + GCC v1.2), used in Windows-hosted workflows that still linked against Nintendo’s libraries. Although bare in mind the v1.2 doesn’t match to the official GNU releases in this case it was their own versioning system for their port of GCC.A leaked version of the SDK was released, distributed as GNUN6432.zip (GNU N64 for 32bit Windows) which contained the toolchain, they were compiled on 19th February 1997 based based on version 2.7.2 of GCC (2.7.2.SN32.3.7 Build 0001).These are the files it contains: CC1N64.exe (1.4MB) - The GNU C Compiler based on version 2.7.2for Nintendo 64 CC1PLN64.exe (1.8MB) - The GNU C++ Compiler based on version 2.7.2 for Nintendo 64 CPPN64.exe (115KB) - The The C Preprocessor (GNU CPP) based on version 2.7.2 for Nintendo 64There are possible other versions of the GCC compilers for N64 made by SN systems that are based on a GCC build earlier that 2.7.2, but we have yet to find any.For more information check out our post on this SDK: SN64 - Nintendo 64 Software Development Kit (SDK) SN64 was a software development kit for the Nintendo 64 created by SN Systems and was especially popular with 3rd party game developers. Introduction Sn Systems are a company that... Cygnus Experimental compiler (1998) - PS1 and N64The Cygnus Experimental compiler, often associated with the EGCS (Experimental/Enhanced GNU Compiler System) project, was a fork of the GNU Compiler Collection (GCC) initiated and maintained by Cygnus Solutions in the mid-1990s.As part of their PSY-Q SDK SN Systems released versions 2.8.0 and 2.8.1 for the Sony Playstation 1 sometime in 1998: 1 Version 2.8.1 of the compiler is now available for download, offering improved compile times over 2.8.0. PSX and N64 versions of the Cygnus Experimental compiler are also available.We don’t know the precise date since the page was first archived on 23rd May 1998, but not sure if any other versions of GNU GCC were released for the PS1.Cygnus 2.7 Sega SATURN Compiler Toolchain (1996)Version 2.7 of the GNU Compiler Collection was built in September 1996 specifically for the Sega Saturn.References SN Systems site from 23rd May 1998 ↩ ↩2 ↩3 GCC Releases - GNU Project - Free Software Foundation (FSF) ↩ ", "excerpt": "When reverse engineering commercial console binaries built from C/C++, the first question is often which toolchain produced the code as it can make your job reverse engineering a game so much easier. On 1990s–2000s consoles you will encounter both GCC-derived compilers and a wide variety of proprietary compilers such as:...", "tags": ["sdk","tools"], "image": "/public/generated/placeholders/compilers.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game Industry Conferences", "url": "/conferences", "content": "Introduction to Retro Games Industry conferencesWhen taking a historical look at the Games Industry one of the most important sources of information are the Conferences that were held to share information before the mainstream internet.This page will talk about the main Game-related conferences that took place over the period of time that we classify as “Retro”, they roughly fit into two distinct categories: Development - Conferences for Sharing Game Development Information (SIGGRAPH, GDC, Develop) Showcase - Conferences for Showing off the latest Games and Gaming Hardware (CES, E3)This table below lists all the conferences that we are aware about taking place up until 2007: Conference Dates Category Notes 32XPOSED November 10th 1994 Development SEGA 32X Developer’s Conference 3DO Developer Conference 1992-1994 Development   Gamer Developers Conference (GDC) 1988-Ongoing Development   CES 1967-Ongoing Showcase   Develop 2006-Ongoing Development UK Game development Conference D.I.C.E. Summit 2002-Ongoing Development Stands for: “Design, Innovate, Communicate, Entertain”, mainly game design and business topics, not programming or 3D content creation Dreamcast Developer’s Conference 1999 Development Dreamcast Developer’s Conference - Sega Retro Saturn Developer’s Conference May 1994 Development DTS: The SEGA Developer’s ‘Game Mag’ – SHIRO Media Group Sega DevCon 1995-1996 Development First one in March 14-17 1995 E3 1995-Ongoing Showcase   Digital World Conference 1990-1995? Development   Intertainment 1988-1993? Showcase ACE Issue 40 covers the November 1990 Intertainment Conference xFest Aug 21st-23rd 2000 Development Microsoft Xbox Developer Conference Quakecon 1996-Ongoing Development ID Software Unite 2007-Ongoing Development Unity Technologies In the sections below we will try to list any audio or video recordings we can find for the sessions, but bare in mind many of the early sessions will now be regarded as lost media.GDC - Game Developer’s ConferenceGDC stands for the “Game Developers Conference”, which is an annual event held for professionals in the video game industry. GDC serves as a hub for game developers, publishers, artists, programmers, designers, and other industry experts to come together to discuss, share, and learn about the latest trends, technologies, and practices in game development. The event includes a wide range of sessions, panels, workshops, and networking opportunities.We have so much content on the GDC that we had to split this section out into its own post you can find it below: Game Developers Conference (GDC) - Full list of historical sessions For more information about the Game Developers Conference check out this post. SIGGRAPHSIGGRAPH stands for “Special Interest Group on Computer Graphics and Interactive Techniques.” It is an annual conference and organization that focuses on computer graphics, interactive technology, and various related fields. SIGGRAPH is highly regarded in the computer graphics and interactive technology industry and is known for its conferences and publications.SIGGRAPH is an interdisciplinary platform that covers a wide range of topics, including computer graphics, visual effects, gaming, virtual reality, computer-aided design, art, and more.The conference features technical paper presentations where researchers and experts share their latest findings and innovations in the field.SIGGRAPH publishes research papers, proceedings, and a variety of resources that contribute to the advancement of computer graphics and interactive techniques.The SIGGRAPH conference has a long history, dating back to the 1970s, and it continues to be a vital forum for sharing knowledge, showcasing innovations, and connecting professionals in the field of computer graphics and interactive technology.They are not always related to game development but many real time rendering techniques used in modern games were first presented at SIGGRAPH.SIGGRAPH 2000The website Gamasutra (now Game Developer) posted an article about the 2000 version of the conference from a game developer perspective, you can read it online here: Siggraph 2000 From a Game Development Perspective.It discusses the new hardware and software for game development shown off at SIGGRAPH 2000 such as Sony’s GScube and the Xbox. Improv Technologies also demoed their new products, Orchestrate3D and Catalyst. The conference also featured presentations on new shading languages and rendering techniques.D.I.C.E SummitD.I.C.E stands for “Design, Innovate, Communicate, Entertain” and was first held from February 28th to March 1st, 2002 in the Hard Rock Hotel Las Vegas 1. The main focus is game design topics along with business rather than game programming or asset creation.It is part of the Academy of Interactive Arts and Sciences and they record the presentations which they would sell footage on DVD, but the modern conferences host the videos online for free.D.I.C.E 2002The first ever D.I.C.E Summit was held from February 28th to March 1st, 2002 in the Hard Rock Hotel Las Vegas 1.The presentations that took place are listed in the table below: Name Presenter Notes “Laughing Matters” Lorne Lanning - President & Creative Director, Oddworld Inhabitants   “Planning, Scheduling and Other Bad Habits of Game Development” Mark Cerny - President, Cerny Games   “The Games People Play…For Money” Joe Kaminkow - Vice President, Engineering and Design, IGT   “Differentiate and Innovate, Don’t Imitate” Bruce Shelley - Senior Designer, Ensemble Games   “The DINO Project: Three Glorious Failures” Sid Meier - Chairman and Director of Creative Development, Firaxis Games   “Attack of the Killer Sequels” Richard Garriott - CCO & Executive Producer, Destination Games   “Designing for the Mass Market” Jason Rubin - President & Co-Founder, Naughty Dog   “Invoking Emotions through Gameplay - The Present and the Future” David Freeman - Writer/Producer   “Audience Developed Products - How to Involve the World” Will Wright - Chief Designer, Maxis   “Can Music Make or Break Your Game?” Michael Giacchino - Edgewater Park Music   “Games for the Rest of the World” (Roundtable) Bruno Bonnell, CEO, Infogrames; Larry Probst, CEO, Electronic Arts; and Brian Farrell, CEO, THQ   “Is Corporate Creativity an Oxymoron?” (Roundtable) Cliff Bleszinski, Chief Designer, Epic Games; Louis Castle, General Manager, Westwood Studios; and American McGee, Chief Creative Officer, Carbon6 Entertainment   The 2002 D.I.C.E. Summit DVD set was available for $250 to Academy members and $450 to non-members. The DVD was produced by Ziff Davis Media (who publish the GMR magazine).Here is an Advert for the DICE Summit DVD from issue 1 of the US magazine GMR from February 2003, it has 4 DVDs which has 9 hours of presentations:Develop (Brighton)The Develop conference, which is held in Brighton, UK, had its inaugural event in 2006. The conference focuses on the video game development industry and covers various aspects of game development, including programming, design, audio, and business. Since its inception, the Develop conference has become an annual event, providing a platform for professionals in the gaming industry to exchange ideas, share knowledge, and network.Develop 2006The first ever Develop conference was split into the following tracks: Coding Design Production Business Art Audio The Next WaveThe sessions from Develop 2006 that we know about are listed in the table below: Title Presenter Track Notes Advance Programming Techniques on PlayStation Portable Igor Makaruks, Sony Computer Entertainment Europe Coding   Animating Emotion Ken Perlin Coding   Connected mobile gaming on Java Matt Levy, SNAP Mobile & Markus Huttunen, SNAP Mobile Manager Coding   Developing with PSSG, a PlayStation 3 optimised cross platform engine Richard Forster, Sony Computer Entertainment Europe Coding   DirectX 10 for Techies Nick Thibieroz, ATI Coding   Lost in translation: The coder’s guide to team communication Jonathan Shaw & Tak Fung, Lionhead Studios Coding   New Techniques for Lighting: From Theory to Practical Implementation Chris Doran, Geomerics Coding   Next Generation Games with Direct3D10 Miguel Sainz, Nvidia Coding   Optimize Your GPU with the Latest NVIDIA Performance Tools Raúl Aguaviva, NVIDIA Developer Tools Engineer Coding   PlayStation 3: A Parallel Universe István Fábián, Sony Computer Entertainment Europe Coding   Profiling and Debugging Your Game with PIX on Xbox 360 Bruce Dawson, Microsoft Game Technology Group Coding   Pros and Cons of Developing Your Own Middleware Andrew Oliver, Blitz Games Coding   Shaders: The Sky is the Limit Sébastien Dominé, NVIDIA & Richard Stenson, Sony Computer Entertainment America Coding   Software engineering: Games programming for large scale projects Jeremy Chatelaine, Electronic Arts Coding   Xbox Live: Now and in the Future Jeff Sullivan, Microsoft Game Technology Group Coding   ARG: immersive gaming for the mass market Adam Martin, MindCandy Game Design   Design by democracy: How to keep your vision - while taking on board everyone else’s Peter Molyneux, Lionhead Studios Game Design   Design DNA: 10 new game designs ideas from the past 12 months worth stealing Margaret Robertson, Edge magazine Game Design   Designing new kinds of games for the masses David Amor, Paulina Bozek, Rob Kay, Michael French Game Design   Everything you know is wrong: four new developments that will turn the MMOG world upside down Janus Anderson & Thomas Bidaux Game Design   Games design room 101: Four designers each consign a game design horror to the dustbin Mike Goldsmit, Jonathan Smith, Simon Byron, Barringon Harvey, Peter Molyneux Game Design   Hacking Through the Jungle: Interactive Storytelling Made Easy and Profitable Ernest Adams Game Design   How to win battles and influence publishers Chris Deering & Jamie Macdonald Business   Genre: dirty word or developer’s friend? Clive Fencott & Jo Clay, Strange Agency Business   Global Directions: A Holistic View of Game Development Jason Della Rocca, IGDA Business   I’m with the brand: Developers as the stars Alison Beasley, Miles Jacobson, Chris Lee, Mark Ward Business   Leveling the Playing Field William Latham, Games Audit Business   Money for Non-Suits Jonathan Smith, TT Games Publishing & Nicholas Lovell, GameShadow Business   The Next Generation of Mobile Gaming Kay Gruenwoldt, Nokia Multimedia Business   Sega - UK’s new Games Powerhouse Mike Simpson, The Creative Assembly, Guy Wilday, Racing Studio, Miles Jacobson, Sports Interactive Business   Towards an industry standard publishing agreement: the TIGA Model Contract Vincent Scheurer Business   Which Ferrari should I drive to work today? Andrew Eades, Relentless Software Business   Why good online games go bad Frank Puranik, Director, Itheon Networks Business   Audio Programming, Tools & Techniques For NexGen AAA Games John Broomhall, Andy Mucho, Nick Wiswell, Nick Laviers Audio   Black: A Case Study Steve Root, Electronic Arts UK Audio   Buy now, pay later! Dave Ranyard, Sony Computer Entertainment Europe, Sergio Pimentel, Sony Computer Entertainment Europe Audio   The Future of Audio in Interactive Entertainment: A Personal Vision Marty O’Donnell Audio   PS3 Audio: Meet The Team Jason Page, Oliver Hume, Nik Kennedy, Paul Scargill, Sony Computer Entertainment Europe Audio   Recreating Reality Kenny Young, Sony Computer Entertainment Europe Audio   Talking Sense: Raising The Bar For Speech In Games Nick Laviers, Electronic Arts UK Audio   Creativity led production: How to bring new ideas into line Tetsuya Mizuguchi, Q Entertainment Next Wave   Lights, Camera… Where Movies and Videogames Meet Rob Fahey, GamesIndustry.biz & Andrew McDonald, DNA Films Next Wave   The Opinion Jam: Twelve speakers. Three minutes each. One winner. Ste Curran, Rob Kay, Ernest Adams, Ken Perlin, Dan Bardino Next Wave   Buy now, pay later! Dave Ranyard, Sony Computer Entertainment Europe, Sergio Pimentel, Sony Computer Entertainment Europe Production   Gotham Racing 3: A Post Mortem on developing a XBOX 360 launch title Gareth Wilson, Bizarre Creations Production   Working with Hollywood: The Storytelling Professionals Mark Green & Katie Ellwood, Sony Computer Entertainment Europe Production     Animating characters within Maya & showcasing the real-time workflow within MotionBuilder along with FBX Nick Jovic, Autodesk Art   Bridging the Uncanny Valley: Style versus Realism in future games Cumron Ashtiani, Steve Boxer, Susie Green Ben Lee Art   Masterclass: Character Animation Nick Jovic & Kevin Booth, Autodesk Art   Motion synthesis and unique game moments Torsten Reil, NaturalMotion Art   Showcasing the interoperability between 3ds Max, Maya and MotionBuilder Kevin Booth, Autodesk Art   Consumer Electronics Show (CES)CES stands for the “Consumer Electronics Show”. It is an annual trade show and convention that serves as a showcase for the latest consumer electronics and technology products. CES is one of the most significant and influential tech events globally, and it’s where many companies, including industry giants and startups, unveil and demonstrate their innovative products and technologies.CES is known for its extensive exhibition of consumer electronics and technology products, ranging from smartphones and televisions to smart home devices, automotive technology, gaming hardware, and more.CES attracts a large number of journalists, bloggers, and media outlets from around the world, generating extensive press coverage and reviews of the showcased products.CES has played a crucial role in unveiling groundbreaking technologies and products that have subsequently shaped the consumer electronics and technology industries. It is a significant annual event for both industry professionals and tech enthusiasts interested in the latest advancements in the world of electronics and innovation.The first Consumer Electronics Show (CES) took place in 1967. CES was initially held in New York City and later moved to Las Vegas, Nevada. Although it features gaming products they have always brushed the games industry aside in favour of more mainstream consumer electronics.Electronic Entertainment Expo (E3)E3, which stands for the “Electronic Entertainment Expo,” was one of the most prominent and anticipated events in the video game industry. It served as a showcase for the latest video games, gaming hardware, and interactive entertainment. E3 brought together game developers, publishers, hardware manufacturers, and gamers to unveil and celebrate upcoming titles and innovations in the world of gaming.The last E3 took place in 2021. After cancellations of the E3 in 2022 and 2023, the discontinuation was announced.Creation of E3SEGA was instrumental to setting up E3, in an interview with Tom Kalinske (former CEO of SEGA America) he had this to say about the formation of E3: In the early Nineties, CES was huge but it treated the gaming industry poorly.We were put in the back, past the new gadgets, computers and stereos and TVs.One year, we were in a tent and it was raining. Out Genesis machines got wet and I said,“That’s it, we’re not coming Back”.We set out to form our own show with favoured third-parties. It became E3.2E3 1995 - The First E3E3 1995 marked the first E3 event, created as an alternative to the Consumer Electronics Show (CES) where the gaming industry was often overlooked.At E3 1995, the gaming industry was undergoing significant changes, with the Super Nintendo still the most popular console in North America but with new hardware on the horizon, such as Sega Saturn, Sony PlayStation, and the yet-to-be-released Ultra 64 (later Nintendo 64). This event was mainly focused on the Sega-Sony rivalry, with Nintendo’s console release delayed until the following year.E3 1995 consisted of exhibits and presentations, but unlike modern E3 events, there were no livestreams, special guest stars, or musical performances. The target audience was gaming industry professionals, retailers, developers, marketing teams, investors, and journalists, rather than gamers. As a result, these early E3 conferences were more subdued and focused on industry announcements rather than generating excitement among gamers.Nintendo Space World (Shoshinkai) (1989-2001)Nintendo Space World (originally known as Shoshinkai) was Nintendo’s annual trade show held in Japan, running from 1989 to 2001. The event was a major showcase for Nintendo’s upcoming hardware and software, often featuring world premieres, tech demos, and exclusive reveals.Notable highlights include the first public showings of the Nintendo 64, GameCube, and Game Boy Advance, as well as prototype games and hardware that sometimes never saw official release. Space World became legendary in the retro gaming and reverse engineering communities due to the early builds, beta content, and rare hardware exhibited-some of which have since surfaced in the form of leaked ROMs and development documents.1989 – Shoshinkai DebutOn the 28th July 1989 Nintendo launched its first ever in-house trade show called Shoshinkai in Kyoto, it was a private in-house event for members of the Japanese press 3. It was an early look at the Super Famicom as it would be released in November 1990, over a year away at this point.The magazines Famitsu and Famimaga published photos taken from the projector screen showing an early version of Super Mario World for the SNES.For more information check out Chris Covell’s excellent page on the 1989 conference: Japanese Secrets!QuakeConQuakeCon is an annual convention and gaming event that primarily focuses on the Quake series of video games, as well as other titles developed by id Software, the company behind Quake. The event has been held since 1996 and is known for its emphasis on competitive gaming, LAN parties, and the celebration of the gaming community.QuakeCon typically features a variety of activities, including tournaments, panel discussions, exhibitor booths, and opportunities for fans to meet and interact with game developers. It has become a significant event in the gaming calendar, attracting thousands of attendees from around the world.While QuakeCon started with a primary focus on the Quake series, it has expanded over the years to include other games, including those from Bethesda Softworks, which acquired id Software. The convention has also been a platform for showcasing new game releases, updates, and announcements, making it an exciting gathering for both fans and industry professionals.Quakecon 2004John Carmack gave the Keynote speech at Quakecon 2004 where he reflects on Doom 3 Engine Decisions, you can watch it on youtube below:The key points from Keynote are as are as follows: Evaluation of Doom 3 Engine Decisions: He reflects on decisions made for the Doom 3 renderer over four years ago. Acknowledges some flaws, such as seams on character heads due to mirroring repeat in texturing. Specularity and Lighting Improvements: Talks about limitations in skin tone realism due to a single level of specularity. Introduces new technology for specular maps, allowing control over the breadth of specular highlights. Addresses issues with specularity on broad surfaces and introduces reflection vector calculation for more accurate highlights. Discusses the use of cubic environment maps and normalization for better quality highlights. Anti-Aliasing Challenges: Highlights the aliasing challenges in surfaces with normal maps and specular highlights. Mentions ongoing work to combat aliasing, considering the analysis of surface normals and specularity factors. Multi-Channel Texture Considerations: Discusses the complexity introduced when combining multiple maps (normal, diffuse, specular, etc.) and the need for coordinated adjustments. Notes potential challenges in scaling and rotating independent maps. Quality Improvement through Renormalization: Describes the benefits of renormalization of normal maps before lighting calculations for improved surface quality. Addresses the issue of denormalization in cases where normal vectors deviate significantly. General Improvements and Considerations: Mentions the need for reevaluation and development of a new rendering engine based on current hardware capabilities. Indicates ongoing efforts to enhance the Doom 3 graphics engine, considering issues like aliasing, specularity, and normal map quality. Overall, he outlines the evolution of the Doom 3 graphics engine, addressing past limitations and describing efforts to improve realism, lighting, and overall graphical quality in the context of current and future hardware capabilities.3D Design ConferenceThe US magazine 3D Design played an active role in the 3D graphics community during the 1990s. Miller Freeman leveraged the magazine’s brand to host the annual 3D Design Conference & Exhibition in San Francisco (starting in 1996). By 1997–98, this event offered “the most targeted technical education available for advanced graphics professionals” and included four days of intensive classes on animation, modeling, lighting, and more​The conference featured top instructors and an expo of 3D hardware/software vendors, and it culminated with the “Big Kahuna Awards” honoring excellence in 3D design​. It is unclear if they also hosted one in 2001.3D Design Conference 1997 Presentation ScheduleThe table below lists all presentations from the 3D Design Conference (June 3–5, 1997) with their title, presenter, a summary of content, and the experience level, thanks to the wayback machine for archiving the old website (3dshow.com): Presentation Name Author Description Level Advanced Animation in Extreme 3D Gerard Chateauvieux Techniques to streamline the animation process in Extreme 3D, covering vertex animation, animation cycles, spline-based motion paths, and use of the score for time-based animation. Prerequisites: Basic understanding of 3D concepts and animation. Intermediate to advanced Optimizing Palettes for the Web, CD-ROMs, and Video Sherri Sheridan Delves into optimizing 8-bit color palettes for professional-looking websites, multimedia CD-ROMs, and video. Demonstrations include Photoshop and Netscape for web graphics, Shockwave optimization, Director and Debabilizer for CD-ROM, and After Effects/Movie Cleaner for QuickTime. Also covers NTSC video output issues with examples of good vs. bad palette techniques. No prerequisites. Intermediate Introduction to Rhino Scot Tumlin Functional overview of Rhino, a new NURBS-based 3D modeler (one of the first inexpensive tools for creating NURBS geometry). Unlike polygon modelers, Rhino’s models are NURBS for easy manipulation of organic shapes. Introduces Rhino’s interface and powerful modeling tools. Prerequisites: Some experience with 3D modeling applications. All levels Getting the Job You Want in Digital Animation (Part 1) Peter Plantec First of a two-part course on preparing a portfolio for the digital realm. Discusses what to include (demo reel, resume, stills) and common mistakes. Tips on distinguishing bad vs. good vs. great demo reels, with critiques of actual demo tapes by the instructor and studio recruiters. Superb for newcomers to learn the ropes quickly and make connections. No prerequisites. All levels Enhancing 3D Animation with After Effects Nathan Vogel Explores numerous ways to use Adobe After Effects to enhance 3D animations through compositing. Covers adding effects like fog, starfields; multiframe textures; displacement mapping; color correction; rendering 3D in layers for special compositing; and effects like explosions, flares, smoke, dust. Demonstrates third-party plug-ins (DigiEffects suite, MetaTools, Knoll Lens Flare). No prerequisites. Intermediate to advanced Character Drawing Brian Wade Covers essentials of character drawing: character requirements, development, expression. Includes free-form design (drawing with the non-dominant hand), proportion, drawing and shading techniques. Prerequisites: Basic drawing skills. Intermediate Character Animation in 3D Studio MAX Ben de Leeuw Focuses on animating characters using Kinetix 3D Studio MAX. Explores strategies for efficiently creating compelling characters with MAX’s tools, with some plugin demonstrations. Topics include keyframing, animation controllers, and general character animation techniques. Prerequisite: Working knowledge of 3D Studio MAX. Intermediate Getting the Job You Want in Digital Animation (Part 2) Peter Plantec Continuation of Part 1 (session 014). Covers developing great ideas for your demo reel, where and how to send your materials, and how to ace the interview. Includes critiques of demo tapes (collected over years) by instructor and studio recruiters. Great opportunity for newcomers to network. Prerequisite: It’s recommended to have attended Part 1 for maximum benefit. Intermediate Building Faces: Strategies for Animating Facial Expressions George Maestri Discusses the complexity of facial animation – “the face is a mirror to the soul.” Covers techniques from modeling through setup and animation to create believable facial expressions. Emphasizes understanding facial anatomy and expression basics, with tips for expressive eyes, lip sync, and conveying emotion/mood. Prerequisite: Basic understanding of facial animation. Intermediate Advanced Modeling Techniques with Extreme 3D Gerard Chateauvieux Designed for animators using (or wanting to use) Extreme 3D in production. Covers techniques for using construction geometry, layers, and linking to improve modeling efficiency and ease. Prerequisite: Basic understanding of 3D concepts and animation. Intermediate to advanced Videotape Output from Start to Finish Gregory Pyros Step-by-step class on outputting computer animations to videotape, emphasizing 3D Studio MAX. Covers various output devices, methods, and techniques, from quick in-house methods to full broadcast-quality output. Also discusses using proxy clips to speed up editing without image degradation. No prerequisites. All levels Tornadoes, F16’s, and Mars Attacks: Special Effects in 3D Studio MAX Frank Delise Reveals techniques behind spectacular Hollywood FX as seen in Twister, Independence Day, Mars Attacks, etc. Teaches 3D Studio MAX tips and tricks to create dazzling special effects (e.g. tornadoes, jets, explosions) seen on-screen. Prerequisite: Knowledge of 3D Studio MAX. Intermediate to advanced Camera Animation Chris Tome Teaches basic cinematographic concepts in a 3D context. Students learn to keyframe and adjust virtual cameras for various cinematic shots. Topics include panning, zooming, lens effects, depth of field, and more. No prerequisites. Beginning to intermediate Bringing Your Character to Life Using Softimage Shape Animation Annesa Hartman How to bend, stretch, mold, and morph characters using Softimage 3D’s Extreme Shape and Cluster Animation tools. Covers techniques to animate an entire mesh or parts of it, including shrink-wrap and quick-stretch effects. Prerequisite: Basic familiarity with the Softimage interface and some 3D animation experience. Intermediate to advanced Composing 3D Graphics for Music Videos Nathan Vogel Shows how to combine music and visuals so they sync to each beat. Explores secret techniques to compose animations tightly integrated with music. Includes examples of successful music-synced animations and demonstrations of software techniques used to achieve those effects. No prerequisites. Intermediate to advanced Sculpting with Clay Brian Wade Covers the complete process of creating a finished sculpture, from building an armature to final touches. Topics include developing the concept, pose, gesture; understanding form, proportion, symmetry, rhythm; working with various clays; and finishing techniques. Prerequisite: Basic sculpting skill. Intermediate to advanced Walking: Techniques for Creating Biped and Multilegged Character Walks George Maestri Examines how a character’s walk conveys personality. Covers tools supporting forward/inverse kinematics and automatic walk cycles (e.g. Softimage’s Multiped, Kinetix’s Biped) and emphasizes that animators must understand walking fundamentals beyond the software. Presents techniques (tool-agnostic) for making characters walk, hop, skip, jump – both bipeds and creatures with more than two legs. Prerequisite: Familiarity with animation. Intermediate to advanced Animation Behaviors Peter Plantec With the rise of digital characters, animators must understand character behavior. Draws from principles of animal behavior (as used in classical animation) to inform digital character acting. Discusses conveying thoughts, emotions, and motivations through body language and creating the illusion of mass in weightless digital models. Shows why automatic tools (like Character Studio) can’t replace an animator’s artistic touch. Prerequisite: Some knowledge of animation. Intermediate Using Expressions in Alias (or Using Math to Animate!) Scot Tumlin Demystifies using mathematical expressions in Alias PowerAnimator to drive animations (a feature often intimidating to artists). Shows how to animate objects via math formulas, with examples of animations created with expressions and a step-by-step method to develop your own. Prerequisites: Experience with Alias PowerAnimator 7.5 or higher, and familiarity with the Alias Action Window. Intermediate to advanced Lighting Design Donald Grahame Focuses on creating striking CG imagery through effective lighting. Reviews world-class 3D animation examples across major software (LightWave, 3D Studio/MAX, Softimage, Alias, Lightscape, Extreme 3D, RenderMan) to compare renderer qualities. Covers practical techniques for dramatic or realistic lighting. Prerequisite: Basic knowledge of 3D modeling and rendering. Intermediate Compositing 3D Elements in LightWave Ace Miles Basics of compositing 3D animation into real-world background footage using NewTek LightWave. Topics include creating digital matte paintings, using background fog, matching lighting, and using LightWave’s Front Projection with “shadow alpha” for realistic integration. Also covers Worley Labs’ new “Gaffer” lighting plug-in for composite shots. Prerequisites: Intermediate knowledge of LightWave 3D and basic 3D experience. Intermediate to advanced Advanced Modeling Decisions for Game Developers Troy Dunniway Clarifies differences between polygonal, NURBS, and metaball modeling, and how each benefits game artists. Demonstrates when to use various modelers or plug-ins on Windows NT to model faster and better. Examples include modeling a low-poly real-time game character vs. a high-res cut-scene character, and integrating tools with 3D Studio MAX, LightWave, and Softimage. Wide variety of software discussed (MAX, Sculptor NT, Rhino 3D, form*Z, MetaReyes, Clay Studio, etc.). Prerequisite: Experience with 3D Studio MAX or another modeling package. Advanced to expert Expressions in LightWave Brad Peebler (No level given) Advanced techniques for using LightWave 3D’s particle and effects tools to create organic explosions, flames, exhaust, and other effects. Focuses on native LightWave tools and plug-ins like Particle Storm, sharing tricks learned from Hollywood animators at studios like Digital Domain and Foundation Imaging. Level: (Not specified) N/A Modeling and Texturing for Games Brian Levy In-depth course on efficient, organized modeling and texturing for pre-rendered game environments. Using Alias PowerAnimator, demonstrates ensuring models and textured environments animate quickly and render fast. Discusses modeling and rigging techniques for characters and environments under tight budgets and schedules. Real-world tips provided for productivity. Prerequisite: Knowledge of current modeling and texturing methods. Beginning to advanced Authoring for Artists with Macromedia Director Marabeth Harding Helps artists understand how their artwork is integrated into multimedia productions. Discusses the process of creating finished multimedia (especially in Macromedia Director) and how to prepare digital art for CD-ROM or web delivery. Topics include proper file formats, naming conventions, when to use movie files vs. Director animations, working within playback limitations, designing with reduced color palettes for faster display. Prerequisite: Experience creating multimedia. Intermediate Forensic Animation Andrew Reese Covers creating and presenting animation for courtroom use. Acquaints design professionals with the legal foundations for forensic animation, where it’s useful, its benefits and potential for misuse. Discusses practical aspects of working with attorneys, special techniques and limitations in creating accurate reconstructions, pitfalls when testifying, and considerations for hardware, software, and gory content. Extensive use of videotaped case examples. No suggested prerequisites. All levels Monsters, Creatures, and Bugs – Modeling Them (Part 1) Sanford Kennedy Overview of using 3D Studio MAX, Clay Studio, and Character Studio to create aggressive or threatening monsters, creatures, and insects. These models are staples of action films and TV sci-fi. Discusses careful planning, artistic skill, and modeling techniques needed for realism – proper proportions, balance, weight, and detailed features (hair, scales, skin, fluids, etc.). Prerequisite: Knowledge of 3D Studio MAX or basic modeling principles. Intermediate to advanced Particle Systems and Volume Effects for 3D Studio Josh Nelson Covers using particle systems in 3D Studio (v4 and MAX) to create effects like explosions, smoke, gases, flames, fireworks, sprays, vapor, etc. Also discusses advanced third-party particle systems (e.g. SandBlaster and Combustion for 3D Studio MAX). Shows sample animations from each software. Prerequisite: Experience with 3D Studio. Intermediate Integrating a 2D Video Editor with 3D Stills and Animation: Adobe Premiere Chris Manners Shows why every 3D animator/multimedia developer should use a video-editing app like Adobe Premiere. Focuses on compositing multiple video and 3D layers with alpha channels, chroma-key, and mattes, plus adding effects via plug-ins. Discusses integrating 2D motion captures, stills, and 3D animations using Premiere’s motion controls, transitions, and the trade-offs between compression and quality. Also covers using proxy (“miniature”) clips for faster editing, mixing multiple audio layers, outputting to video, and using Premiere projects in other multimedia. No prerequisites. Intermediate Modeling in LightWave: Metaform and MetaNURBS (Part 1) Ace Miles Shares secrets of modeling with LightWave 3D’s two unique tools: Metaform and MetaNURBS. Topics include differences between metaforms vs. MetaNURBS, when to use each, and their pros/cons relative to other Modeler tools. Demonstrates using LightWave’s other tools (Bevel, Smooth Shift, Drag, Magnet, etc.) in conjunction with MetaNURBS. Prerequisites: Basic knowledge of LightWave Modeler and general 3D modeling experience. Intermediate to advanced Monsters, Creatures, and Bugs – Animating Them (Part 2) Sanford Kennedy Continuation of Part 1, focusing on character animation of monsters/insects in 3D Studio MAX with Character Studio. Shows techniques for animating aggressive and violent behaviors common in action films and TV. Includes multiple-legged walk cycles, fight choreography for creatures, and ensuring realistic motion (with reference clips of animals/insects fighting – not for the squeamish). Prerequisite: Knowledge of 3D Studio MAX or animation principles. (Students should attend Part 1 for best results.) Intermediate to advanced 3D for Print Henk Dawson Explains the advantages of using 3D graphics in print projects. Demonstrates real project examples to show how 3D can generate derivative works, texture variations, and interactive compositions for client presentations. Covers preparing 3D images for press, including managing polygon count, image resolution, color correction, and final output settings. Prerequisite: Some experience using 3D for print media. Intermediate Production Techniques for Large-Scale Animation Projects Brian Levy Introduces tools and techniques from Alias/Wavefront’s latest software release that aid large animation productions. In-depth review of the SoundSync tool for character lip-sync and unlimited animation setup. Gives an overview of optimal modeling/texturing workflows to keep production on schedule, including file-size management for efficiency. Ideal for game/animation production staff seeking maximum “bang for the buck.” Prerequisite: Basic familiarity with current game production techniques. Beginning to advanced Project Management Donald Grahame Emphasizes that organization is key to large projects. Taught by an instructor who navigated every pitfall during The Last Express (a complex interactive CD-ROM). Covers how to start projects right, work with publishers and subcontractors, manage large teams, and even “manage your managers.” Helps you conquer major organizational challenges in multifaceted projects. No prerequisites. Intermediate Modeling in LightWave: Organic Shapes (Part 2) Ace Miles In-depth look at modeling organic characters in LightWave Modeler. Covers tools like MetaNURBS, MetaformPlus, and spline patching to create organic forms. Discusses modeling with future animation in mind – using LightWave’s bones, Metamation, and external plug-ins (Puppet Master, Morph Gizmo) effectively. Prerequisites: Recommended to have attended Part 1 (session 072); intermediate modeling knowledge required. Advanced 3D Paint Troy Dunniway General overview of 3D paint technologies and tools. Introduces 4D Paint (4D Vision), MeshPaint 3D (Positron), and Detailer (Fractal Design). Explains why 3D paint is invaluable in production. Second part demonstrates using 4D Paint with Photoshop and 3D Studio MAX to easily create complex texture and bump maps on organic models. Prerequisite: Basic understanding of Photoshop and 3D Studio MAX (recommended). All levels Nurbs Modeling Brian Levy In-depth course on speeding up NURBS modeling for production. Covers thought processes and techniques for efficient NURBS modeling that yields animation-friendly models. Emphasizes creating models that are both efficient and easy to animate, focusing on character and environment modeling. Demos Alias PowerAnimator tools in depth and techniques for a more free-form approach. Must-have for production artists aiming to boost speed and productivity. Prerequisite: Knowledge of NURBS-based modeling. Intermediate Intermediate Texture Mapping (Part 1) Alex Lindsay Covers the fundamentals of creating and using texture maps to blur the line between CG and reality. Discusses how to start: making tileable textures from photos, creating believable surfaces from scratch, etc. Prerequisite: Intermediate understanding of Adobe Photoshop. Intermediate Animating Your Avatar Robert W. Saint John Introduces the basics of animation in VRML 2.0 and applies them to building avatars for multi-user VRML worlds. Topics include optimizing 3D models for VRML, using world-building and traditional 3D tools to speed up development, adding behaviors to avatars, and an overview of efforts to standardize “living” worlds and avatars in VRML. Prerequisites: Familiarity with VRML, 3D modeling, and animation. All levels Creating Fantasy Worlds Eni Oken Walks through creating believable fantasy environments with 3D graphics. Topics include choosing a concept, designing and executing ideas, plus textures, colors, and lighting techniques. Demonstrations use 3D Studio, but techniques apply to any 3D software. Prerequisite: Basic knowledge of any 3D modeling software. Intermediate Advanced Techniques with 3D Studio MAX David Anthony Examines advanced modeling methods in 3D Studio MAX such as Boolean operations, lofting, and deformation curves to create a complex shape. Shows a real-time rotation of a textured and mapped model. Prerequisite: Experience with 3D Studio MAX. Advanced Art Directing 3D for Interactive Media Isaac Victor Kerlow Examines the daily realities of art directing 3D projects for interactive media (CD-ROMs, cartridges, online). Topics include translating an artistic vision into a timely, technically feasible product; balancing artistic goals with technical constraints; defining pipelines to achieve art goals; and communication between art, technical, and production staff. No prerequisites. Intermediate Intermediate Texture Mapping (Part 2) Alex Lindsay Continues from Part 1 (session 091). Explores creating advanced maps for unique surface effects that can’t be modeled easily. Subjects include animated textures, bump maps, specular maps, displacement maps, luminance maps. Prerequisites: Intermediate Photoshop, basic texture mapping knowledge. (Students should attend Part 1 for full benefit.) Intermediate to advanced Graphic Compression and Techniques for Web Animation Dave Friedel Covers the latest Internet solutions for web animation and emerging 3D web tech. Topics include compression techniques, custom control options, animated GIF and JPEG solutions. Demonstrations of technologies like Superscape, DirectX, Flash, and others to showcase new methods for web animation and 3D. Prerequisites: Basic video/animation experience and some understanding of internet programming, Director, or related software. Intermediate to advanced Creating Effective Architectural Walkthroughs Jeff Hester Shows how to use 3D visualization tools to communicate architectural designs under tight budgets and schedules. Provides tips and tricks for on-time, on-budget walkthroughs – from storyboarding to delivery. Uses 3D Studio, AutoCAD, and MAX for demos, but concepts apply to any visualization tool. Prerequisite: Familiarity with architectural visualization tools. Intermediate Ultimate Space Battle Chris Tome Focuses on how to create a dramatic space battle animation. Starts with scripting and storyboarding, then covers model and scene creation, special effects, and particle systems, through to final rendering. Prerequisite: Some animation experience. Intermediate to advanced The Art of Convincing Landscapes – Tips & Techniques for Bryce 2.1 Susan A. Kitchens Explores creating convincing landscapes in Bryce 2.1 (Mac/Win). Covers two main areas: 1) geometry – using Edit/Replication controls and expert terrain manipulation in the Terrain Editor; 2) scene appearance – controlling environment settings (sky, fog) for mood and realism, and tweaking object surfaces in the Materials Composer. By session end, students have a solid Bryce foundation and tips for more realistic scenes. Prerequisite: Familiarity with basic Bryce 2.1 features. Advanced-beginner to intermediate Advanced Particle Animation Chris Tome Demonstrates using various particle systems to create more interesting flying logos, realistic particle simulations, and special effects. Uses a range of software including Softimage Particles, SandBlaster for MAX, Particle Type for LightWave. Topics include particle collision, flocking behaviors, object replacement, and more. Prerequisite: Animation experience. Intermediate to advanced Facial Animation Benjamin Harrison Tackles the complexity of animating faces, one of 3D’s final frontiers. Begins with discussing modeling methods that allow flexibility for animation (splines, patches, NURBS, polygons, metaballs, etc.). Then covers preparing a neutral face for speech and expression, demonstrating basic lip-sync techniques and subtler facial movements to bring characters to life. Tips are product-agnostic, applicable in many software packages. Prerequisite: Experience in modeling and animation. Intermediate to advanced Methods for Integrating Art and Technology in Game Development Edward Kilham Focuses on streamlining the integration of art and technology during interactive game development from a design perspective. Discusses methods for improving communication between artists and programmers, tool development, data pipelines from content creation to implementation, and other relevant topics. Addresses common development problems in human communication and data sharing, and how to design the development process to mitigate them. Prerequisite: Experience in designing medium-to-large-scale projects. Intermediate to advanced Modeling for VRML Using Softimage Anthony Rossano Explores tools for exporting VRML 1.0 geometry, materials, and textures from Softimage 3D Extreme. Provides the inside track on which polygonal structures work best in VRML and how to avoid pitfalls/bugs in Softimage’s VRML exporter. Shows how to create materials that look good in a VRML browser and how to create effective texture maps bound to polygon vertices. Prerequisite: Understanding of polygonal geometry. Intermediate The Procedural Mecca – Bryce’s Deep Texture Editor Susan A. Kitchens A thorough introduction to Bryce’s powerful but undocumented Deep Texture Editor (DTE), the heart of its procedural textures and natural landscapes. The DTE is an “Easter egg” for power users – this session demystifies it. Covers all DTE features and builds some textures from scratch. Attendees are encouraged to bring questions. Prerequisite: Familiarity with Bryce 2.1 (Mac/Win), especially the Materials Composer, or some DTE experience. Intermediate to advanced Creating Profitable Web Pages Nancy Fulton Addresses the business side of web design: how to design and develop web pages that are good business investments, not just novelties. Discusses maintaining company interest and investment in web publications, attracting new clients, and upselling features to existing clients. Covers designing pages that directly increase profitability. No prerequisites. Intermediate 3D: The Ultimate Cost Saving Design Tool? Jeff Hester Counters the perception that 3D visualization is an expensive luxury by showing how real design teams use tools like AutoCAD and 3D Studio during conceptual design to save money. Walks through an actual design process from a case study, outlining cost savings achieved by integrating 3D early. No prerequisites. Intermediate Advanced Lighting using Gaffer and LightWave Grant Boucher Covers advanced lighting and surfacing techniques using Worley Labs’ Gaffer plugin with NewTek LightWave 3D. This combo represents state-of-the-art digital lighting, exceeding even some capabilities of RenderMan or Mental Ray. (Gaffer was co-developed with Digital Domain, and the instructor’s team helped create it.) Prerequisite: Familiarity with general lighting techniques. Advanced Character Maquettes for Animation Simone Raclin Covers how to build physical character maquettes to aid animation. Includes armature construction, sculpting, and finishing techniques. Discusses anatomy, character posing, and exaggerating forms for effect. Features a step-by-step demo from model sheets to a rough maquette, followed by discussion of different types of maquettes and their use in production. Participants can bring their own projects for troubleshooting. No prerequisites. Intermediate References D.I.C.E. Summit - February 28 March 1, 2002 ↩ ↩2 Tom Kalinske in RETRO volume 9 (page 25) ↩ Japanese Secrets! ↩ ", "excerpt": "Introduction to Retro Games Industry conferences When taking a historical look at the Games Industry one of the most important sources of information are the Conferences that were held to share information before the mainstream internet. This page will talk about the main Game-related conferences that took place over the...", "tags": ["industry"], "image": "/public/images/categories/Games Industry Conferences.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Copyright Infringement in the games industry", "url": "/copyright", "content": "The practice of game cloning in arcades and consoles goes back to the industry’s origins – to take a quote from a 2001 issue of the Japanese CONTINUE magazine 1: “the entire game industry itself began with copyright infringement, ever since Space Invaders..”This timeline charts key instances of companies reverse-engineering or copying each other’s video games from the 1980s through the 2000s, focusing on arcade and home console titles. Each entry highlights notable clones, imitation games, and legal/technological battles that shaped industry norms.Late 1970s–Early 1980s: The Dawn of Arcade Clones1978–1979: Taito’s hit Space Invaders (1978) sparks a wave of imitators Space Fever (1979) - Arcade Even Nintendo entered the fray, releasing Space Fever in 1979 – a clear Space Invaders clone – to capitalize on the alien-shooting craze 2.Such copying was common in the young arcade industry, with many companies producing their own versions of successful games.1980–1981: Pac-Man Clones Pac-Man (1980) - Commodore 64 Cover Pac-Man (Namco, 1980) becomes a global phenomenon, and an explosion of unauthorized clones follows.Small manufacturers hacked or re-skinned Pac-Man into games like Mighty Mouth and Piranha, which were nearly identical in maze layout and character design. By 1981, dozens of Pac-Man knock-offs appeared across arcades and home systems.This prompted Pac-Man’s U.S. distributor, Midway, and rights-holder Atari to aggressively defend the IP in court.In one case, a judge described Mighty Mouth as “for all practical purposes, identical” to Pac-Man 3, leading Midway to win a 1983 summary judgment for copyright and trademark infringement.1981–1982: K.C. Munchkin (Philips) sued by Atari K.C. Munchkin! (1981) - Odyssey 2 K.C. Munchkin! for the Odyssey² console (Philips) became a landmark in clone litigation.The maze-chase game was so similar to Pac-Man that Atari (which had console rights to Pac-Man) sued.In 1982, the U.S. Seventh Circuit court ruled that K.C. Munchkin! infringed Pac-Man’s copyrighted characters and maze design, ordering the clone off the market 4.This case – Atari, Inc. v. Philips – was among the first to affirm that a video game’s audiovisual “look and feel” could be protected by copyright law.1982: Ms. Pac-Man – From Bootleg to Blockbuster Ms. Pac-Man (1982) - Atari 2600 One of the era’s most famous clones actually became an official sequel. Ms. Pac-Man began as an unauthorized enhancement kit called Crazy Otto, created by General Computer Corp. (GCC), a group of MIT dropouts who hacked existing arcade games 5.Before Crazy Otto GCC had made a business of reverse engineering popular games and selling upgrade kits, they modded Atari’s Missile Command into Super Missile Attack and made $250k in profit!.They used expensive hardware such as the GenRad 6502 microprocessor emulator from their dorm rooms in MIT and manually typed each screen of assembly that they got from the disassembler on to their TRS-80.After a brief legal enounter with Atari over their Super Missile Attack upgrade kit, they agreed a settlement where Atari would pay GCC $50k per month over two years for them to make games for Atari. They agreed not to market arcade enhancement kits without the original manufacturer’s approval.So next they started on the most popular game in arcades - Pac Man, which was based on a Z80 microprocessor so they bought a Tektronix 8550 as it has a Z80 emulator and a line printer to print the disassembled code 6.After the previous legal pressure from Atari, GCC decided to pitch Crazy Otto to Midway (Namco’s American partner) instead of releasing it illicitly.Midway enthusiastically bought the project as a way to quickly follow up Pac-Man’s success.Working with Namco, they reskinned the characters and released it as Ms. Pac-Man.The game – built on Pac-Man’s underlying code – became a smash hit!Ms. Pac-Man’s unusual origin blurs the line between cloning and innovation: a bootleg mod was absorbed into official canon when the rights holders saw its value.References Ikari Warriors, Guerilla War, and The SNK Golden Age - shmuplations.com ↩ Space Fever Color - Space Invaders Wiki - Fandom ↩ Midway Mfg. Co. v. Dirkschneider, 543 F. Supp. 466 (D. Neb. 1981) :: Justia ↩ Atari, Inc. v. North American Philips Consumer Electronics Corp., 672 F.2d 607 (7th Cir. 1982) :: Justia ↩ How an arcade classic broke all the rules - Polygon ↩ Classic Game Postmortem: Ms. Pac-Man - YouTube ↩ ", "excerpt": "The practice of game cloning in arcades and consoles goes back to the industry’s origins – to take a quote from a 2001 issue of the Japanese CONTINUE magazine 1: “the entire game industry itself began with copyright infringement, ever since Space Invaders..” This timeline charts key instances of companies...", "tags": ["industry","legal","copyright"], "image": "/public/generated/placeholders/copyright.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Crash Bandicoot", "url": "/crash-bandicoot", "content": "Introduction to Crash BandicootCrash Bandicoot was one of the first 3D Platform games that managed to deliver both quality gameplay and impressive graphics for its time. It was developed Naughty Dog for release on the original Playstation console with the aim for it to become the Mascot character for the console, this aim paid off for the creators.Development TeamNaughty Dog started development of Crash Bandicoot with just Andy Gavin and Jason Rubin and later introduced the programmer Dave Baggett and Universal VP Mark Cerny.They were one of the few developers to sign an agreement directly with Sony, most of the time it was the publisher who signed this agreement. This agreement was known as the “developers agreement” and was notoriously harsh on the developers as Sony wanted to keep strict control over who had access to develop for the platform 1.Development ToolsThe team paid $35k for a development kit in 1994 which likely was the original prototype development kit known as the MW.3, this predated the PC-based SN Systems PSY-Q Development Kit that used an ISA card that plugged directly into a development PC. Official PlayStation 1 Development Kit (Hardware) For more information on the MW.3 and other official development kits please check out this post. Assets3D ModelsTechnical limitations of the Sony Playstation 1 hardware and the limited small CRT’s used to play games were a big part in shaping the game we know and love today.Crash’s Design limitationsThe design of Crash Bandicoot was described by Rubin as 51% technical and visual necessity and 49% inspiration. As for the technical reasons, his colours were chosen based on what would look good on a 90s CRT television and the choice of bright orange meant that lava levels could not be present in the game as it would be too similar to the players colour 2.Use of Untextured Polygons for CrashIt also turned out that the PlayStation was particularly good at rendering untextured but shaded polygons because of this it was decided that crash would be untextured which was a high enough polygon count that the details could be shown using just the colors of the polygons as well as rendering faster this had other advantages.The bright colors of Crash would pop out on the screen and this also avoided the Playstations lack of texture perspective correction. This also helped with the cartoon vibe that the game was going for 3.3D WorldLevel Design LimitationsThe game was designed around the Playstation’s limitations and so levels needed to be planned accordingly to fit in the limited memory and processing power the Playstation had available.The levels ensured that there was never too much being shown on screen at once, if a polygon was obscured by something like a fern or a bush the game engine was smart enough to ignore that polygon entirely.So if the developers ever had too many polygons on the screen they could actually just add in a bush to fix the problem 4!The PlayStation could not handle showing many enemies on the screen at one time as they were composed of too manypolygons so lots of woompa fruit was added as they are in fact 2D sprites so many of these could be rendered at once to make the levels a bit more interesting.The Crates were also relatively low in terms of polygon count (6 if you only render what is facing the camera) so many could be added to make the levels feel more fleshed out 4.Use of Fixed Camera OptimisationsThe in-game camera moves on a fixed path through each level so a lot of things could be pre-calculated before putting the game on the disc.3D games need to calculate the correct order in which to render polygons on the fly, but the PlayStation had no easy way to do that.So to optimise this Crash Bandicoot could pre-calculate the order as it would always be the same thanks to the fixed camera 4.3D Animation The characters were also animated differently to most games, rather than giving a character bones and moving them around Naughty Dog’s animators instead moved individual vertices around to create Crashes exaggerated expressions. This was in an era where bone animations in games were primitive and characters were low poly, so this made Crash stand out from the crowd as an emotive cartoon character. Naughty Dog would use its technique to even greater effect later on in Jak and Daxter 4. ModdingCrashEdit - Level EditorCrashEdit is a modding tool developed by cbhacks to edit levels for the first 3 PS1 Crash Bandicoot games. It is being replaced by another tool called DRNSF but currently it has some features which are not available in the new tool yet. CrashEdit - Level Editor To find out more about the level editor check out the projects Github page Coding SecretsAvoiding Playstation RAM limitationsOne of the main technical limitations was taking many megabytes of data and placing it in the Playstation’s limited RAM (2MB). To do this many parts of the level were pre-calculated. In fact some of these pre-calculations were so complex that it would take several hours for a single level to process even when that was being distributed over eight computers 4!These techniques managed to compress levels that were 128 megabytes in size down to a measly 12 megabytes. While that is impressive, the levels however would then need to be dynamically loaded to fit into the Playstation’s two megabytes of RAM.This would have to be done seamlessly to keep the framerate stable and the developers even went as far as controlling the physical layout of the bytes on the CD-ROM a large file exists in the game that serves no purpose but to push the game’s data to the outside of the disk since this area of the disk moves faster data here could be read quicker so that everything could be loaded by the time Crash ended up in those levels.Other optimisations such as re-using the same variables to save individual bytes in memory were used to great effect and in the end Crash Bandicoot used up almost all of the 2MB of RAM but with just four bytes to spare 4. More Memory Optimisations for Crash See Dave Baggett's excellent post on more optimisations made to Crash Bandicoot! Secret Code from Sony?Crash Bandicoot was a technical marvel boasting visuals so impressive that Naughty Dog were accused of being given secret libraries of code from Sony to make their game perform better than others 4!However this was not true, Naughty Dog would often break Sony’s recommended development process by not using their provided libraries and instead program their own bespoke more efficient libraries to push the hardware to its limits.Unused contentAs with most games that have a rushed development cycle, there are assets available on the disc which are never actually used in the retail game. For Crash Bandicoot this includes a full level known as Stormy Ascent which was deemed too hard and too time consuming to fix up before the release date. Crash Bandicoot - The Cutting Room Floor The Cutting Room Floor has a very detailed page listing all of the unused assets available in the game and is highly recommended to check out. Other GamesCrash 2 DecompilationThe developer known as ughman has created a Crash 2 mini-decompilation project which converts the original assembly for the PS1 version of Crash 2 into C code which is structured like assembly. So it is up to the developer to take it further and re-create all the loops and function calls 5. Crash 2 in C Github project for the decompilation of Crash 2 for PS1 Crash Team Racing Modding ToolsAnother excellent Crash-based game for the Playstation 1 was Crash Team Racing, there are a few projects which have managed to create modding tools for this game, the most complete is known as CTR-tools. CTR-tools Github project for the Crash Team Racing (PS1) tools References Making Crash Bandicoot – part 1 :: All Things Andy Gavin ↩ Making Crash Bandicoot – part 2 :: All Things Andy Gavin ↩ Making Crash Bandicoot – part 3 « All Things Andy Gavin ↩ Crash Bandicoots Design and Technical Achievement - Behind The Screens - YouTube ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ughman/c2c: Crash 2 in C ↩ ", "excerpt": "Introduction to Crash Bandicoot Crash Bandicoot was one of the first 3D Platform games that managed to deliver both quality gameplay and impressive graphics for its time. It was developed Naughty Dog for release on the original Playstation console with the aim for it to become the Mascot character for...", "tags": ["ps1","games"], "image": "https://img.youtube.com/vi/0HwvAjELuuM/hqdefault.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Creating a LibRetro Frontend in Rust", "url": "/CreateALibRetroFrontEndInRust", "content": "Welcome to this comprehensive tutorial on creating a LibRetro Frontend using Rust! If you’re passionate about retro gaming and interested in creating your very own emulation frontend from scratch, you’ve come to the right place. Rust, with its strong safety guarantees, performance, and concurrency support, makes it an ideal choice for developing such applications.In this tutorial, we will walk you through the process of building a fully-functional LibRetro frontend from the ground up. We will start by introducing you to the basics of creating a graphical Rust application and the LibRetro API, then delve into essential concepts such as handling input, video, and audio. By the end of this tutorial, you’ll have a solid understanding of the inner workings of a LibRetro frontend and the knowledge to create your own customized version to relive your favorite gaming memories.Step 1 - Setup MiniFBThe first step was just to get a window where we can draw pixels and respond to user input, we want it to be very simple and cross-platform so we can use the minifb library.use minifb::{Key, Window, WindowOptions};const WIDTH: usize = 640;const HEIGHT: usize = 480;fn main() { let mut buffer: Vec<u32> = vec![0; WIDTH * HEIGHT]; let mut window = Window::new( \"Rust Game\", WIDTH, HEIGHT, WindowOptions::default(), ).unwrap_or_else(|e| { panic!(\"{}\", e); }); window.limit_update_rate(Some(std::time::Duration::from_micros(16600))); // ~60fps let mut x: usize = 0; let mut y: usize = 0; while window.is_open() && !window.is_key_down(Key::Escape) { // Move the pixel when the arrow keys are pressed if window.is_key_down(Key::Left) && x > 0 { x -= 1; } if window.is_key_down(Key::Right) && x < WIDTH - 1 { x += 1; } if window.is_key_down(Key::Up) && y > 0 { y -= 1; } if window.is_key_down(Key::Down) && y < HEIGHT - 1 { y += 1; } // Set the pixel to blue buffer[y * WIDTH + x] = 0x0000FFFF; // Update the window buffer and display the changes window.update_with_buffer(&buffer, WIDTH, HEIGHT).unwrap(); }}The result of this is that it draws a blue pixel at an x,y position and you can move it around with the arrow keys, note that we don’t clear the frame buffer every frame so it keeps all the previous positions as blue pixels too. The end result is you can draw blue lines on the screen.Step 2 - Clear the screen every frameThe line effect is cool but we should clear the screen to black every frame so that the player can just move the individual pixel around the screen, you can do this by adding the following code to the start of the loop:// Clear the buffer to blackfor pixel in &mut buffer { *pixel = 0x00000000;}Step 3 - Display the Frames per secondThat looks great but is it efficinet to loop through the whole array every frame (60 times a second) to set every pixel to black? Probably not, but it would be good to have a way to measure this, lets display the frames per second and we can compare the speed of future changes.To display the fps, you can use the Instant type from the std::time module to measure the time between frames. Here’s an updated version of your code that displays the fps in the window title:use minifb::{Key, Window, WindowOptions};use std::time::{Duration, Instant};const WIDTH: usize = 640;const HEIGHT: usize = 480;fn main() { let mut buffer: Vec<u32> = vec![0; WIDTH * HEIGHT]; let mut window = Window::new( \"Rust Game\", WIDTH, HEIGHT, WindowOptions::default(), ).unwrap_or_else(|e| { panic!(\"{}\", e); }); // window.limit_update_rate(Some(std::time::Duration::from_micros(16600))); // ~60fps (commented out to get over 60fps) let mut x: usize = 0; let mut y: usize = 0; let mut fps_timer = Instant::now(); let mut fps_counter = 0; while window.is_open() && !window.is_key_down(Key::Escape) { // Clear the buffer to black for pixel in &mut buffer { *pixel = 0x00000000; } // Calculate fps fps_counter += 1; let elapsed = fps_timer.elapsed(); if elapsed >= Duration::from_secs(1) { let fps = fps_counter as f64 / elapsed.as_secs_f64(); window.set_title(&format!(\"Rust Game (FPS: {:.2})\", fps)); fps_counter = 0; fps_timer = Instant::now(); } // Move the pixel when the arrow keys are pressed if window.is_key_down(Key::Left) && x > 0 { x -= 1; } if window.is_key_down(Key::Right) && x < WIDTH - 1 { x += 1; } if window.is_key_down(Key::Up) && y > 0 { y -= 1; } if window.is_key_down(Key::Down) && y < HEIGHT - 1 { y += 1; } // Set the current pixel to blue buffer[y * WIDTH + x] = 0x0000FFFF; // Update the window buffer and display the changes window.update_with_buffer(&buffer, WIDTH, HEIGHT).unwrap(); }}In this updated code, we use an Instant timer to measure the elapsed time between frames. We keep track of the number of frames rendered (fps_counter) and the time elapsed since the last fps update (fps_timer). When a second has passed, we calculate the fps and update the window title using the Window::set_title() method. Finally, we reset the fps counter and timer.Step 4 - Using buffer.fill instead of looping through arrayNow that we can measure the frames per second we can test to see if using buffer.fill is more efficinet that looping through each pixel and setting to black, so replace the loop with:buffer.fill(0x00000000);I get slightly higher FPS with buffer.fill, but at the end of the day it is still looping over each pixel, one way we could fix this is to just set the previous pixel to black each frame at the start of the loop, like so:while window.is_open() && !window.is_key_down(Key::Escape) { // Clear the previous pixel to black buffer[y * WIDTH + x] = 0x00000000;This gets a much higher fps, of course this is not particularly useful right now as when creating a game it is unlikely that we will just update a single pixel per frame, but it is good to keep in mind for future optimizations, the less pixels we update per frame the more efficient we can be.Step 5 - Load a Dynamic Library (dll/dylib) from the codeAll libRetro cores are compiled into platform-specific dynamic libraries (dylib on MacOSX and dll on Windows), we want to be able to call one of these functions from our code in order to get our frontend to do anything.In order to do this we need to add the libloading crate as a dependency inside the Cargo.toml file like so:[dependencies]libloading = \"0.7.0\"Then import the crate at the top of the file like so:extern crate libloading;We will create a function to load the dynamic library like so:fn load_core() { unsafe { let lib = Library::new(\"my_library.dylib\").expect(\"Failed to load Core\"); }}You should call the load_core function before the main game loop and if you have my_library.dylib in your current directory it will load it, otherwise it will print the string “Failed to load Core” and exit.Note if you are on Windows make sure your core ends with .dll, on Linux .so and on MacOSX .dylib, the above example is for MacOSX.You can download cores for your platform using the LibRetro BuildBot available here: LibRetro Nightly Builds.Step 6 - Calling a function from the Core (Dynamic Library)As an example lets call the function retro_init as it is one of the simplest functions (it doesn’t require any parameters).fn load_core() { unsafe { let core = Library::new(\"gambatte_libretro.dylib\").expect(\"Failed to load Core\"); let retro_init: unsafe extern \"C\" fn() = *(core.get(b\"retro_init\").unwrap()); retro_init(); }}When running this may actually cause a Segmentation fault depending on which core you use as the function retro_init expects a few things to be set before executing. The fact that it caused a segmentation fault in the first place is a good sign in this case and we will fix this in the next step by providing the callback functions that it requires.For more information about retro-init and the callback functions it requires you can checkout the guide: Developing Cores for LibRetro.Step 7 - Retrieving a response from the CoreBefore we call the setup functions we should make sure that the core is written using a version of the LibRetro API that is compatible with what we expect.The function retro_api_version is used for this purpose and at the time of current written just returns the number 1, we can call this function from the core and retrieve its value and print it to the console like so:const EXPECTED_LIB_RETRO_VERSION: u32 = 1;fn load_core() { unsafe { let core = Library::new(\"gambatte_libretro.dylib\").expect(\"Failed to load Core\"); let retro_init: unsafe extern \"C\" fn() = *(core.get(b\"retro_init\").unwrap()); let retro_api_version: unsafe extern \"C\" fn() -> libc::c_uint = *(core.get(b\"retro_api_version\").unwrap()); let api_version = retro_api_version(); println!(\"API Version: {}\", api_version); if (api_version != EXPECTED_LIB_RETRO_VERSION) { panic!(\"The Core has been compiled with a LibRetro API that is unexpected, we expected version to be: {} but it was: {}\", EXPECTED_LIB_RETRO_VERSION, api_version) } }}Step 8 - Setting up the environment for the CoreNow to fix that segmentation fault error when calling retro_init, all we need to do it set whats called an **Environment Callback** function and pass it to the core. The Environment Callback function is used to allow the core to call back to the frontend to request information.The information they can request comes in the form of a Command ID and is passed back to the core using a data buffer, so the Environment Callback takes in those two paramaters, we can implement this like so:pub type EnvironmentCallback = unsafe extern \"C\" fn(command: libc::c_uint, data: *mut libc::c_void) -> bool;unsafe extern \"C\" fn libretro_environment_callback(command: u32, data: *mut c_void) -> bool { println!(\"libretro_environment_callbac Called with command: {}\", command); false}fn load_core() { unsafe { let core = Library::new(\"gambatte_libretro.dylib\").expect(\"Failed to load Core\"); let retro_init: unsafe extern \"C\" fn() = *(core.get(b\"retro_init\").unwrap()); let retro_api_version: unsafe extern \"C\" fn() -> libc::c_uint = *(core.get(b\"retro_api_version\").unwrap()); let retro_set_environment: unsafe extern \"C\" fn(callback: EnvironmentCallback) = *(core.get(b\"retro_set_environment\").unwrap()); let api_version = retro_api_version(); println!(\"API Version: {}\", api_version); if (api_version != EXPECTED_LIB_RETRO_VERSION) { panic!(\"The Core has been compiled with a LibRetro API that is unexpected, we expected version to be: {} but it was: {}\", EXPECTED_LIB_RETRO_VERSION, api_version) } retro_set_environment(libretro_environment_callback); retro_init(); }}If all goes well, when you run the program you will now not get a Segmentation fault (I didn’t with the gameboy gambatte core) but it will also print out each call to the environment callback like so:API Version: 1callback_environment Called with command: 52callback_environment Called with command: 16callback_environment Called with command: 69callback_environment Called with command: 65581callback_environment Called with command: 27callback_environment Called with command: 8callback_environment Called with command: 70callback_environment Called with command: 59callback_environment Called with command: 39callback_environment Called with command: 15callback_environment Called with command: 65587callback_environment Called with command: 64All those integers you see in the output are Command IDs and you can see a full list of them if you go to the LibRetro.h Header File, they start with RETRO_ENVIRONMENT_.For example you can see that the first value 52 is called RETRO_ENVIRONMENT_GET_CORE_OPTIONS_VERSION which is requesting the version of the LibRetro API that we expect future calls to be using.We could define all these constants outselves, but after a quick google search you can see that there is already a rust library with these defined called libretro-sys that we can use instead.Step 9 - Using the types from libretro-sys cargoWe can now add the following to our Cargo.toml file:libretro-sys = \"0.1.1\"Now that we are using the libretro-sys library we can refactor the function a bit to use the CoreAPI type provided the the library and implement the rest of the functions, to look like this:use libretro_sys::CoreAPI;fn load_core() -> (Library, CoreAPI) { unsafe { let dylib = Library::new(\"gambatte_libretro.dylib\").expect(\"Failed to load Core\"); let core_api = CoreAPI { retro_set_environment: *(dylib.get(b\"retro_set_environment\").unwrap()), retro_set_video_refresh: *(dylib.get(b\"retro_set_video_refresh\").unwrap()), retro_set_audio_sample: *(dylib.get(b\"retro_set_audio_sample\").unwrap()), retro_set_audio_sample_batch: *(dylib.get(b\"retro_set_audio_sample_batch\").unwrap()), retro_set_input_poll: *(dylib.get(b\"retro_set_input_poll\").unwrap()), retro_set_input_state: *(dylib.get(b\"retro_set_input_state\").unwrap()), retro_init: *(dylib.get(b\"retro_init\").unwrap()), retro_deinit: *(dylib.get(b\"retro_deinit\").unwrap()), retro_api_version: *(dylib.get(b\"retro_api_version\").unwrap()), retro_get_system_info: *(dylib.get(b\"retro_get_system_info\").unwrap()), retro_get_system_av_info: *(dylib.get(b\"retro_get_system_av_info\").unwrap()), retro_set_controller_port_device: *(dylib.get(b\"retro_set_controller_port_device\").unwrap()), retro_reset: *(dylib.get(b\"retro_reset\").unwrap()), retro_run: *(dylib.get(b\"retro_run\").unwrap()), retro_serialize_size: *(dylib.get(b\"retro_serialize_size\").unwrap()), retro_serialize: *(dylib.get(b\"retro_serialize\").unwrap()), retro_unserialize: *(dylib.get(b\"retro_unserialize\").unwrap()), retro_cheat_reset: *(dylib.get(b\"retro_cheat_reset\").unwrap()), retro_cheat_set: *(dylib.get(b\"retro_cheat_set\").unwrap()), retro_load_game: *(dylib.get(b\"retro_load_game\").unwrap()), retro_load_game_special: *(dylib.get(b\"retro_load_game_special\").unwrap()), retro_unload_game: *(dylib.get(b\"retro_unload_game\").unwrap()), retro_get_region: *(dylib.get(b\"retro_get_region\").unwrap()), retro_get_memory_data: *(dylib.get(b\"retro_get_memory_data\").unwrap()), retro_get_memory_size: *(dylib.get(b\"retro_get_memory_size\").unwrap()), }; let api_version = (core_api.retro_api_version)(); println!(\"API Version: {}\", api_version); if (api_version != EXPECTED_LIB_RETRO_VERSION) { panic!(\"The Core has been compiled with a LibRetro API that is unexpected, we expected version to be: {} but it was: {}\", EXPECTED_LIB_RETRO_VERSION, api_version) } (core_api.retro_set_environment)(libretro_environment_callback); (core_api.retro_init)(); return (dylib, core_api); }I return the CoreAPI so we can call the functions in the rest of the code as it will be useful to call retro_run to render every frame inside the loop where we currently draw the blue pixel.Here is an example of how we can call and use this new structure:unsafe { let (dylib, core_api) = load_core(); (core_api.retro_init)(); }If I am honest I only returned the dylib as I have not yet figured out Rust memory-management and if I don’t return it then the library memory will be cleaned up causing the retro_init call to cause a Segmentation Fault. I could have passed in the dylib object to the function instead but I wanted to keep the dylib logic out of the main function. I will come back to this when I know more about Rust.Since this basically leaks memory already we could change it to: let dylib = Box::leak(Box::new(Library::new(\"gambatte_libretro.dylib\").expect(\"Failed to load Core\")));Then it will not need to be returned and will not cause a segmentation fault.Although this is just temporary, in the future we will move all this into its own data structure with additional settings, if/when we add the ability to change cores on the fly.Step 10 - Read Command Line arguments for ROM to loadCurrently we have hard-coded the dynamic library into the code but now we can write code to read both the core to load and the ROM name to load from the command line arguments.In order to be a drop-in replacement for RetroArch we should try to use the same command Line options, which are available on their website here.The use the prefix -L to specify the core to load and the default parameter is the ROM file to play.To do this lets first create a new structure to hold the current emulator state such as the rom that is loaded and the core to use:struct EmulatorState { rom_name: String, library_name: String,}Now lets write a function using the clap crate to parse the command line arguments and return them in our brand new structure:fn parse_command_line_arguments() -> EmulatorState { let matches = App::new(\"RustroArch\") .arg( Arg::with_name(\"rom_name\") .help(\"Sets the path to the ROM file to load\") .required(true) .index(1), ) .arg( Arg::with_name(\"library_name\") .help(\"Sets the path to the libRetro core to use\") .short(\"L\") .takes_value(true), ) .get_matches(); let rom_name = matches.value_of(\"rom_name\").unwrap(); let library_name = matches.value_of(\"library_name\").unwrap_or(\"default_library\"); println!(\"ROM name: {}\", rom_name); println!(\"Core Library name: {}\", library_name); return EmulatorState { rom_name: rom_name.to_string(), core_name: library_name.to_string() } }You now need to pass a ROM file to the program in order to get past the argument parsing logic like so: cargo build --release && ./target/release/rustro_arch Tetris.gb -L ./gambatte_libretro.dylibStep 11 - Loading the ROM fileNow that we have the path of the ROM file to load we need to pass it to our core using the retro_load_game function. The function takes in a structure which the Rust libretro-sys crate calls GameInfo.Lets look at the definition of the GameInfo struct:pub struct GameInfo { // Path to game, UTF-8 encoded. Usually used as a reference. May be NULL if rom // was loaded from stdin or similar. retro_system_info::need_fullpath guaranteed // that this path is valid. pub path: *const libc::c_char, // Memory buffer of loaded game. Will be NULL if need_fullpath was set. pub data: *const libc::c_void, // Size of memory buffer. pub size: libc::size_t, // String of implementation specific meta-data. pub meta: *const libc::c_char,}To populate this we need to convert our Rust rom_name string into a *const libc::c_char and also open copy all the bytes from the ROM file and put it im a buffer that we can pass to the data field.For the first part we can use Foreign Function Interface (FFI) crate, specifically the std::ffi::CString type to convert to a C pointer like so:use std::ffi::{c_void, CString};let rom_name_cptr = CString::new(rom_name).expect(\"Failed to create CString\").as_ptr();Now to load the ROM file and put all its bytes into a *const libc::c_void buffer, you can use the std::fs::read function to read the file into a Vec <u8>, and then use the as_ptr() method to obtain a pointer to the underlying bytes.So lets create a function to load the ROM and pass it to the libRetro core:unsafe fn load_rom_file(core_api: CoreAPI, rom_name: String) { let rom_name_cptr = CString::new(rom_name.clone()).expect(\"Failed to create CString\").as_ptr(); let contents = fs::read(rom_name).expect(\"Failed to read file\"); let data: *const c_void = contents.as_ptr() as *const c_void; let game_info = GameInfo { path: rom_name_cptr, data, size: contents.len(), meta: ptr::null(), }; (core_api.retro_load_game)(&game_info);}We can call this function just before the main game loop:unsafe { let core_api = load_core(emulator_state.core_name); (core_api.retro_init)(); println!(\"About to load ROM: {}\", emulator_state.rom_name); load_rom_file(core_api, emulator_state.rom_name);}Note that when running the Tetris ROM with gambatte core it now prints out:[Gambatte] Cannot dupe frames!Looking in the Gambatte source code for this statement we find: This codebool retro_load_game(const struct retro_game_info *info){ bool can_dupe = false; environ_cb(RETRO_ENVIRONMENT_GET_CAN_DUPE, &can_dupe); if (!can_dupe) { gambatte_log(RETRO_LOG_ERROR, \"Cannot dupe frames!\\n\"); return false; }Which highlights two things, one is that retro_load_game returns a boolean whether or not it succcessfully loads the ROM or not and also that we need to properly implemnent the enivironment callback so that we can return true for RETRO_ENVIRONMENT_GET_CAN_DUPE to get past this logic.For the boolean return value lets read the value and exit if it was not successful:unsafe fn load_rom_file(core_api: &CoreAPI, rom_name: String) -> bool { let rom_name_cptr = CString::new(rom_name.clone()).expect(\"Failed to create CString\").as_ptr(); let contents = fs::read(rom_name).expect(\"Failed to read file\"); let data: *const c_void = contents.as_ptr() as *const c_void; let game_info = GameInfo { path: rom_name_cptr, data, size: contents.len(), meta: ptr::null(), }; let was_load_successful = (core_api.retro_load_game)(&game_info); if (!was_load_successful) { panic!(\"Rom Load was not successful\"); } return was_load_successful;}Now lets support RETRO_ENVIRONMENT_GET_CAN_DUPEby changing our libretro_environment_callback function to check if the command is ENVIRONMENT_GET_CAN_DUPE, this is a good use for the rust match statement:unsafe extern \"C\" fn libretro_environment_callback(command: u32, return_data: *mut c_void) -> bool { match command { ENVIRONMENT_GET_CAN_DUPE => println!(\"ENVIRONMENT_GET_CAN_DUPE\"), _ => println!(\"libretro_environment_callback Called with command: {}\", command) } false}This will print ENVIRONMENT_GET_CAN_DUPE when the command comes in but it will still not get past the logic in Gambatte as we need to return the value true into the return_data buffer. To do this we can use the c-like syn tax to set the dereferenced pointer to the boolean true value like so:*(return_data as *mut bool) = true; // Set the return_data to the value trueOn a side note I have not yet found out what exactly RETRO_ENVIRONMENT_GET_CAN_DUPE is for, apparently GameBoy generates two identical frames back-to-back, so apparently the frontend needs to support being able to duplicate the same frame in order to maintain timing.So we now have the environment callback function like so:unsafe extern \"C\" fn libretro_environment_callback(command: u32, return_data: *mut c_void) -> bool { match command { ENVIRONMENT_GET_CAN_DUPE => { *(return_data as *mut bool) = true; // Set the return_data to the value true println!(\"Set ENVIRONMENT_GET_CAN_DUPE to true\"); }, _ => println!(\"libretro_environment_callback Called with command: {}\", command) } false}This gets past the dupe frames error but still fails on ROM load with the message:[Gambatte] RGB565 is not supported.Again looking at the Gambatte source code we can find out where it fails here so we need to implement the RETRO_ENVIRONMENT_SET_PIXEL_FORMAT command too, returning true is enough to get past this check for now, but in the near future we will need to save the pixel format when we want to draw the buffer to the screen:unsafe extern \"C\" fn libretro_environment_callback(command: u32, return_data: *mut c_void) -> bool { match command { libretro_sys::ENVIRONMENT_GET_CAN_DUPE => { *(return_data as *mut bool) = true; // Set the return_data to the value true println!(\"Set ENVIRONMENT_GET_CAN_DUPE to true\"); }, libretro_sys::ENVIRONMENT_SET_PIXEL_FORMAT => { println!(\"TODO: Handle ENVIRONMENT_SET_PIXEL_FORMAT when we start drawing the the screen buffer\"); return true; } _ => println!(\"libretro_environment_callback Called with command: {}\", command) } false}After this change Gambatte gets pretty far in loading the ROM which we can see by looking at the console messages:TODO: Set ENVIRONMENT_SET_PIXEL_FORMAT to somethinglibretro_environment_callback Called with command: 9[Gambatte] No system directory defined, unable to look for 'gbc_bios.bin'.libretro_environment_callback Called with command: 15[Gambatte] Plain ROM loaded.[Gambatte] rambanks: 0[Gambatte] rombanks: 2[Gambatte] Got internal game name: TETRIS.libretro_environment_callback Called with command: 15libretro_environment_callback Called with command: 65578I am going to ignore the gbc_bios.bin error message for now, Tetris isn’t a GBC game and I believe the BIOS is optional for this emulator anyway.Step 12 - Running the core with retro_runLets now see what happens when we request the core to run a whole frame of emulation, we can do this with the retro_run function like so: unsafe { let core_api = load_core(emulator_state.core_name); (core_api.retro_init)(); println!(\"About to load ROM: {}\", emulator_state.rom_name); load_rom_file(&core_api, emulator_state.rom_name); (core_api.retro_run)(); }Unfortunately this causes a segmentation fault as soon as we call it without printing anything new to the console:ROM was successfully loaded[1] 63265 segmentation fault ./target/release/rustro_arch Tetris.gb -L ./gambatte_libretro.dylibBare in mind that so far we have been implementing the bare minimum of the libRetro API to get to this point, so it is likely it is requesting something we have not yet implemented. So lets have a look at what libretro.h says is guarantted to be called before retro_run:/* Sets callbacks. retro_set_environment() is guaranteed to be called * before retro_init(). * * The rest of the set_* functions are guaranteed to have been called * before the first call to retro_run() is made. */RETRO_API void retro_set_environment(retro_environment_t);RETRO_API void retro_set_video_refresh(retro_video_refresh_t);RETRO_API void retro_set_audio_sample(retro_audio_sample_t);RETRO_API void retro_set_audio_sample_batch(retro_audio_sample_batch_t);RETRO_API void retro_set_input_poll(retro_input_poll_t);RETRO_API void retro_set_input_state(retro_input_state_t);We have already implemented the environment callback, but lets create dummy implementations for each of the others so we can be sure that it isn’t one of these missing functions causing the segmentation fault.First create the dummy callback functions at the top of the file:unsafe extern \"C\" fn libretro_set_video_refresh_callback(data: *const libc::c_void, width: libc::c_uint, height: libc::c_uint, pitch: libc::size_t) { println!(\"libretro_set_video_refresh_callback\")}unsafe extern \"C\" fn libretro_set_input_poll_callback() { println!(\"libretro_set_input_poll_callback\")}unsafe extern \"C\" fn libretro_set_input_state_callback(port: libc::c_uint, device: libc::c_uint, index: libc::c_uint, id: libc::c_uint) -> i16 { println!(\"libretro_set_input_state_callback\"); return 0; // Hard coded 0 for now means nothing is pressed}unsafe extern \"C\" fn libretro_set_audio_sample_callback(left: i16, right: i16) { println!(\"libretro_set_audio_sample_callback\");}unsafe extern \"C\" fn libretro_set_audio_sample_batch_callback(data: *const i16, frames: libc::size_t) -> libc::size_t { println!(\"libretro_set_audio_sample_batch_callback\"); return 1;}As these are dummy functions we just print the function name that was called and if it requires a return value we just return the number 0, we will find out what we need to implement these later on.Now pass them to the core after the call to retro_init like so:(core_api.retro_init)();(core_api.retro_set_video_refresh)(libretro_set_video_refresh_callback);(core_api.retro_set_input_poll)(libretro_set_input_poll_callback);(core_api.retro_set_input_state)(libretro_set_input_state_callback);(core_api.retro_set_audio_sample)(libretro_set_audio_sample_callback);(core_api.retro_set_audio_sample_batch)(libretro_set_audio_sample_batch_callback);Now run the program and success it doesn’t cause a segmentation fault! Lets now move the retro_run call into the main game loop so it calls the core every frame: unsafe { let core_api = load_core(emulator_state.core_name); (core_api.retro_init)(); println!(\"About to load ROM: {}\", emulator_state.rom_name); load_rom_file(&core_api, emulator_state.rom_name); } window.limit_update_rate(Some(std::time::Duration::from_micros(16600))); // Limit to ~60fps while window.is_open() && !window.is_key_down(Key::Escape) { // Call the libRetro core every frame unsafe { (core_api.retro_run)(); }Excellent so we can now run the core every frame and you will see a lot of lines printed to the console where it calls our callback functions such as:libretro_set_audio_sample_batch_callbacklibretro_environment_callback Called with command: 17libretro_set_input_poll_callbacklibretro_set_input_state_callbackStep 13 - Get the pixel buffer from the coreNow that we have the core running it would be nice to actually see what the emulator is doing, for that we need to get the pixel buffer and display it instead of our moving blue pixel.To get the pixel buffer from the libretro core we need to properly implement the libretro_set_video_refresh_callback we just created a dummy for as it is called every frame when the core has finished writing all the pixels to the frame buffer.The width and height parameter will be useful as it is the size of the frame in pixels, but I need to find out what the pitch variable is used for. You can print out the values every frame like so:unsafe extern \"C\" fn libretro_set_video_refresh_callback(frame_buffer_data: *const libc::c_void, width: libc::c_uint, height: libc::c_uint, pitch: libc::size_t) { println!(\"libretro_set_video_refresh_callback, width: {}, height: {}, pitch: {}\", width, height, pitch)}For the gambatte core it is currently printing this out every frame:libretro_set_video_refresh_callback, width: 160, height: 144, pitch: 512So the width and height look correct but lets quickly find out what pitch is and why it is set to 512, I decided to do the mordern thing ans asked ChatGPT, we got the following response: In the context of libretro, pitch refers to the number of bytes between two vertically adjacent pixels in an image. It is also sometimes called the “stride” or “line stride”. The pitch value is important because many image processing algorithms and hardware acceleration APIs require that images be stored in memory in a specific format with a specific pitch value. If an image’s pitch value does not match the expected value, it can cause visual artifacts or errors in processing.It gave a better explanation than my google seach, but 512 pixels between two vertical pixels seems like quite a lot, we will come back to this soon, but lets at least see what the frame_buffer looks like.The frame_buffer_data parameter contains all the pixel data to display, so lets at least print it out to the console to see what we are dealing with:unsafe extern \"C\" fn libretro_set_video_refresh_callback(frame_buffer_data: *const libc::c_void, width: libc::c_uint, height: libc::c_uint, pitch: libc::size_t) { println!(\"libretro_set_video_refresh_callback, width: {}, height: {}, pitch: {}\", width, height, pitch); let length_of_frame_buffer = width*height; let slice = std::slice::from_raw_parts(frame_buffer_data as *const u8, length_of_frame_buffer as usize); println!(\"Frame Buffer: {:?}\", slice);}This runs for a little bit and then causes a segmentation fault, if we remove the println then it will run successfully, so presumably either the frame buffer memory is being deleted while we are printing it or the frame_buffer_data is being passed as a null pointer, both could cause the segmentation fault.First lets check if frame_buffer_data is a null pointer and return if it is:unsafe extern \"C\" fn libretro_set_video_refresh_callback(frame_buffer_data: *const libc::c_void, width: libc::c_uint, height: libc::c_uint, pitch: libc::size_t) { if (frame_buffer_data == ptr::null()) { println!(\"frame_buffer_data was null\"); return; } println!(\"libretro_set_video_refresh_callback, width: {}, height: {}, pitch: {}\", width, height, pitch); let length_of_frame_buffer = width*height; let slice = std::slice::from_raw_parts(frame_buffer_data as *const u8, length_of_frame_buffer as usize); println!(\"Frame Buffer: {:?}\", slice);}This fixes the segmentation fault and highlights a piece of useful information, that the frame_buffer_data is sometimes null, this could be related to the dupe frames mentioned earlier, maybe if it is null it expects the frontend to just display the previous frame?Step 14 - Displaying the Pixel Buffer to the screenNow we have a buffer of pixels from the core, we need to figure out how we can display them to the screen, we have two problems to solve: We got the buffer of pixels in our callback function but how do we get that data into the main game loop to draw to our screen? We need to figure out the format that the pixel buffer is in, e.g how many bytes represent red, green, blue etc and is there alpha (transparency) information in the format?For the first problem all I can think of is creating a global variable which we can access in both the callback function and in the main game loop, there is probably a much better way to do this in rust as global variables are generally bad practise but it will do for now. Maybe at the end of this project when I know more rust I can go back and refactor the code with explanations of why.We can use our existing struct called EmulatorState for the global variable and add an optional frame buffer into the definiton, in rust you can create an optional field like so:struct EmulatorState { rom_name: String, core_name: String, frame_buffer: Option<Vec<u8>>,}static mut CURRENT_EMULATOR_STATE: EmulatorState = EmulatorState { rom_name: String::new(), core_name: String::new(), frame_buffer: None,}Now before we initialise the core lets set this global variable to have the current rom name and core name and an empty frame_buffer so lets change this previous line: let emulator_state = parse_command_line_arguments();To instead use the global variable:unsafe { CURRENT_EMULATOR_STATE = parse_command_line_arguments() };Note that the unsafe block is required as we are modifying global state, which is not thread safe, exactly why we shouldn’t be using a global variable, maybe we could put the libRetro callback as a closure inside the main function along with the variable, but that wouldn’t work as the callback needs to be marked as extern for the core to call it, anyway lets see if we can get the pixel buffer from the callback first.Lets set the frame_buffer on our global variable:unsafe extern \"C\" fn libretro_set_video_refresh_callback(frame_buffer_data: *const libc::c_void, width: libc::c_uint, height: libc::c_uint, pitch: libc::size_t) { if (frame_buffer_data == ptr::null()) { println!(\"frame_buffer_data was null\"); return; } println!(\"libretro_set_video_refresh_callback, width: {}, height: {}, pitch: {}\", width, height, pitch); let length_of_frame_buffer = width*height; let buffer_slice = std::slice::from_raw_parts(frame_buffer_data as *const u8, length_of_frame_buffer as usize); // Create a Vec<u8> from the slice let buffer_vec = Vec::from(buffer_slice); // Wrap the Vec<u8> in a Some Option and assign it to the frame_buffer field CURRENT_EMULATOR_STATE.frame_buffer = Some(buffer_vec); println!(\"Frame Buffer: {:?}\", CURRENT_EMULATOR_STATE.frame_buffer);}Excellent so the frame_buffer has been successfully set on the global variable we should be able to access it from the main game loop!So lets replace the old code that we were using to display the moving blue pixel example, from this:window.update_with_buffer(&buffer, WIDTH, HEIGHT).unwrap();To this:unsafe { match &CURRENT_EMULATOR_STATE.frame_buffer { Some(buffer) => { // Do something with buffer let slice_u32: &[u32] = unsafe { std::slice::from_raw_parts(buffer.as_ptr() as *const u32, buffer.len()) }; // convert to &[u32] slice reference window.update_with_buffer(slice_u32, WIDTH, HEIGHT).unwrap(); } None => { // Handle the case where frame_buffer is None println!(\"We don't have a buffer to display\"); } } }Since the frame_buffer is optional we need to handle that using the common rust patten of using a match statement.The update_with_buffer functionneed to take a u32 array but our buffer was a u8 array so we convert it and then pass it to the function.Bare in mind we are just presuming (incorrectly) that the pixel format returned by the core will match exactly what the minifb library expects. So we are expecting this to put nonsense on the screen until we convert the pixel format from the core to match what minifb expects.But first lets run and we realise that we get this error:Update failed because input buffer is too small. Required size for 640 (640 stride) x 480 buffer is 1228800\\n bytes but the size of the input buffer has the size 23040 bytesWe are only passing 23040 bytes because we multipiled the width and height together and presumed that each pixel was a single byte which is of course incorrect.But just to get something to display on the screen based on this frame buffer lets do a little hack and just fill up the rest of the buffer with the value 0x0000FFFF (blue) like so:unsafe { match &CURRENT_EMULATOR_STATE.frame_buffer { Some(buffer) => { // Do something with buffer let slice_u32: &[u32] = unsafe { std::slice::from_raw_parts(buffer.as_ptr() as *const u32, buffer.len()) }; // convert to &[u32] slice reference // Temporary hack jhust to display SOMETHING on the screen let mut vec: Vec<u32> = slice_u32.to_vec(); vec.resize( WIDTH*HEIGHT*4, 0x0000FFFF) window.update_with_buffer(&vec, WIDTH, HEIGHT).unwrap(); } None => { // Handle the case where frame_buffer is None println!(\"We don't have a buffer to display\"); } } }Step 15 - Handling the core Pixel FormatOk lets finally handle the Pixel format correctly, do you remember this dummy code block we created earlier:libretro_sys::ENVIRONMENT_SET_PIXEL_FORMAT => { println!(\"TODO: Handle ENVIRONMENT_SET_PIXEL_FORMAT when we start drawing the the screen buffer\"); true },This is where the core tells us the format it will write the Pixel buffer in, different cores will write in different pixel formats so we need to be able to handle the following formats which we can see in libretro.h: RETRO_PIXEL_FORMAT_0RGB1555 You can read this as 0,Red,Green,Blue 1 bit at the start that is always zero 5 bits for red 5 bits for green 5 bits for blue 16 bits total (2 bytes per pixel) RETRO_PIXEL_FORMAT_XRGB8888 You can read this as Nothing,Red,Green,Blue 8 bits at the start that are unused (X) 8 bits for red 8 bits for green 8 bits for blue 32 bits total (4 bytes per pixel) RETRO_PIXEL_FORMAT_RGB565 You can read this as Red,Green,Blue 5 bits for red 6 bits for green (Humans are better at seeing moire shades of green than red/blue) 5 bits for blue 16 bits total (2 bytes per pixel)) RETRO_PIXEL_FORMAT_UNKNOWN No idea how to handle this apart from just displaying and error and exiting So which format does our minifb library use to display its buffer? Well a quick look at the documentation comes up with this statement: Updates the window with a 32-bit pixel buffer. The encoding for each pixel is 0RGB: The upper 8-bits are ignored, the next 8-bits are for the red channel, the next 8-bits afterwards for the green channel, and the lower 8-bits for the blue channel.Which is the same as RETRO_PIXEL_FORMAT_XRGB8888, so the good news is that cores that give us the pixel buffer in this format will be slightly more efficient as we won’t need to convert it to this format every frame!Lets first find out what pixel format we get with the Gambatte emulator core by modifying the ENVIRONMENT_SET_PIXEL_FORMAT match case statement:libretro_sys::ENVIRONMENT_SET_PIXEL_FORMAT => { let pixel_format = *(return_data as *const u32); println!(\"Set ENVIRONMENT_SET_PIXEL_FORMAT to: {}\", pixel_format); true },For the Gambatte core this prints out:Set ENVIRONMENT_SET_PIXEL_FORMAT to: 2What does 2 mean? Well we can check the libretro-sys library to see if there is a nice ENUM name for the values and then print it out using a match statement:libretro_sys::ENVIRONMENT_SET_PIXEL_FORMAT => { let pixel_format = *(return_data as *const u32); let pixel_format_as_enum = PixelFormat::from_uint(pixel_format).unwrap(); match pixel_format_as_enum { PixelFormat::ARGB1555 => println!(\"Core will send us pixel data in the RETRO_PIXEL_FORMAT_0RGB1555 format\"), PixelFormat::RGB565 => println!(\"Core will send us pixel data in the RETRO_PIXEL_FORMAT_RGB565 format\"), PixelFormat::ARGB8888 => println!(\"Core will send us pixel data in the RETRO_PIXEL_FORMAT_XRGB8888 format\"), _ => panic!(\"Core is trying to use an Unknown Pixel Format\") } true },Now when we run this code with the Gambatte core it prints out:Core will send us pixel data in the RGB565 formatThis is a bit of a shame as if it was RETRO_PIXEL_FORMAT_XRGB8888 we could pass it directly to minifb and be done, note that we will need to find some libRetro cores that use RETRO_PIXEL_FORMAT_XRGB8888 and another that uses RETRO_PIXEL_FORMAT_0RGB1555 in order to make sure our frontend can support all the known pixel foprmats that a core can use.We will need to save the pixel format in our global variable so we can reference it later when we need to convert the frame buffer between the formats, so lets add a new field to the struct:struct EmulatorState { rom_name: String, core_name: String, frame_buffer: Option<Vec<u8>>, pixel_format: PixelFormat}static mut CURRENT_EMULATOR_STATE: EmulatorState = EmulatorState { rom_name: String::new(), core_name: String::new(), frame_buffer: None, pixel_format: PixelFormat::ARGB8888};I set the default value to the 32 byte version as minifb uses that but it should always be overridden by the core anyway.Step 16 - Converting one Pixel Format to anotherNow that we have saved the pixel format into the global variable we can use it to convert the buffer from the core’s pixel format into the minifb pixel format.So lets have a look at the video refresh callback function again:unsafe extern \"C\" fn libretro_set_video_refresh_callback(frame_buffer_data: *const libc::c_void, width: libc::c_uint, height: libc::c_uint, pitch: libc::size_t) { if (frame_buffer_data == ptr::null()) { println!(\"frame_buffer_data was null\"); return; } // println!(\"libretro_set_video_refresh_callback, width: {}, height: {}, pitch: {}\", width, height, pitch); let length_of_frame_buffer = width*height; let buffer_slice = std::slice::from_raw_parts(frame_buffer_data as *const u8, length_of_frame_buffer as usize); // Create a Vec<u8> from the slice let buffer_vec = Vec::from(buffer_slice); // Wrap the Vec<u8> in an Some Option and assign it to the frame_buffer field CURRENT_EMULATOR_STATE.frame_buffer = Some(buffer_vec); // println!(\"Frame Buffer: {:?}\", CURRENT_EMULATOR_STATE.frame_buffer);}Note that we set the length_of_frame_buffer variable to the width multiplied by the height, but that would only be correct if it was one byte per pixel, now that we know the core’s Pixel Format we can implement this correctly.We need to also multiply it by the number of bytes-per-pixel, as far as I can see there is nowhere in libretro-sys to get the number of bits/bytes from the PixelFormat. So I manually mapped it using a match statement and added it as another field on the global variable:struct EmulatorState { rom_name: String, core_name: String, frame_buffer: Option<Vec<u8>>, pixel_format: PixelFormat, bytes_per_pixel: u8 // its only either 2 or 4 bytes per pixel in libretro}static mut CURRENT_EMULATOR_STATE: EmulatorState = EmulatorState { rom_name: String::new(), core_name: String::new(), frame_buffer: None, pixel_format: PixelFormat::ARGB8888, bytes_per_pixel: 4};We can now calculate this value and save it into the global like so:libretro_sys::ENVIRONMENT_SET_PIXEL_FORMAT => { let pixel_format = *(return_data as *const u32); let pixel_format_as_enum = PixelFormat::from_uint(pixel_format).unwrap(); CURRENT_EMULATOR_STATE.pixel_format = pixel_format_as_enum; match pixel_format_as_enum { PixelFormat::ARGB1555 => { println!(\"Core will send us pixel data in the RETRO_PIXEL_FORMAT_0RGB1555 format\"); CURRENT_EMULATOR_STATE.bytes_per_pixel = 2; }, PixelFormat::RGB565 => { println!(\"Core will send us pixel data in the RETRO_PIXEL_FORMAT_RGB565 format\"); CURRENT_EMULATOR_STATE.bytes_per_pixel = 2; } PixelFormat::ARGB8888 => { println!(\"Core will send us pixel data in the RETRO_PIXEL_FORMAT_XRGB8888 format\"); CURRENT_EMULATOR_STATE.bytes_per_pixel = 4; }, _ => { panic!(\"Core is trying to use an Unknown Pixel Format\") } } true },Now we need to be able to convert the RGB565 format to the format that minifb expects so lets create a function that does just that:fn convert_pixel_array_from_rgb565_to_xrgb8888(color_array: &[u8]) -> Box<[u32]> { let bytes_per_pixel = 2; assert_eq!(color_array.len() % bytes_per_pixel, 0, \"color_array length must be a multiple of 2 (16-bits per pixel)\"); let num_pixels = color_array.len() / bytes_per_pixel; let mut result = vec![0u32; num_pixels]; for i in 0..num_pixels { // This Rust code is decoding a 16-bit color value, represented by two bytes of data, into its corresponding red, green, and blue components. let first_byte = color_array[bytes_per_pixel*i]; let second_byte = color_array[(bytes_per_pixel*i)+1]; // First extract the red component from the first byte. The first byte contains the most significant 8 bits of the 16-bit color value. The & operator performs a bitwise AND operation on first_byte and 0b1111_1000, which extracts the 5 most significant bits of the byte. The >> operator then shifts the extracted bits to the right by 3 positions, effectively dividing by 8, to get the value of the red component on a scale of 0-31. let red = (first_byte & 0b1111_1000) >> 3; // Next extract the green component from both bytes. The first part of the expression ((first_byte & 0b0000_0111) << 3) extracts the 3 least significant bits of first_byte and shifts them to the left by 3 positions, effectively multiplying by 8. The second part of the expression ((second_byte & 0b1110_0000) >> 5) extracts the 3 most significant bits of second_byte and shifts them to the right by 5 positions, effectively dividing by 32. The two parts are then added together to get the value of the green component on a scale of 0-63. let green = ((first_byte & 0b0000_0111) << 3) + ((second_byte & 0b1110_0000) >> 5); // Next extract the blue component from the second byte. The & operator performs a bitwise AND operation on second_byte and 0b0001_1111, which extracts the 5 least significant bits of the byte. This gives the value of the blue component on a scale of 0-31. let blue = second_byte & 0b0001_1111; // Use high bits for empty low bits as we have more bits available in XRGB8888 let red = (red << 3) | (red >> 2); let green = (green << 2) | (green >> 3); let blue = (blue << 3) | (blue >> 2); // Finally save the pixel data in the result array as an XRGB8888 value result[i] = ((red as u32) << 16) | ((green as u32) << 8) | (blue as u32); } result.into_boxed_slice()}Now lets convert the buffer when it comes in from the emulator:unsafe extern \"C\" fn libretro_set_video_refresh_callback(frame_buffer_data: *const libc::c_void, width: libc::c_uint, height: libc::c_uint, pitch: libc::size_t) { if (frame_buffer_data == ptr::null()) { println!(\"frame_buffer_data was null\"); return; } let length_of_frame_buffer = ((pitch as u32) * height) * CURRENT_EMULATOR_STATE.bytes_per_pixel as u32; let buffer_slice = std::slice::from_raw_parts(frame_buffer_data as *const u8, length_of_frame_buffer as usize); let result = convert_pixel_array_from_rgb565_to_xrgb8888(buffer_slice); // Create a Vec<u8> from the slice let buffer_vec = Vec::from(result); // Wrap the Vec<u8> in an Some Option and assign it to the frame_buffer field CURRENT_EMULATOR_STATE.frame_buffer = Some(buffer_vec);}If you run the program now you will get something that looks like this:Step 17 - Fixing display issuesRemember the pitch parameter that the core sends us? Yeah turns out it is very important as it is basically the width of the frame buffer, with width parameter is the part of the pitch that is actually used for the gameboy screen and the rest of the pixels are black. So we can actually make this a lot better by just changing the WIDTH and HEIGHT to the following values:const WIDTH: usize = 256;const HEIGHT: usize = 140;Which will result in Tetris looking much nicer:The 140 height is set to the height of the Game Boy screen, but the width is actually set to the pitch divded by 2, as the pitch value that comes back is actually the number of bytes for each row of pixels (not the number of actual pixels).The WIDTH and HEIGHT variables are hard-coded and will only work for this Game Boy core as the 140 pixels in height would not be applicable for other cores like NES or SNES. Lets move these variables to our global variable so we can adapt them, based on the values the cores give us:struct EmulatorState { rom_name: String, core_name: String, frame_buffer: Option<Vec<u32>>, pixel_format: PixelFormat, bytes_per_pixel: u8, // its only either 2 or 4 bytes per pixel in libretro screen_pitch: u32, screen_width: u32, screen_height: u32,}static mut CURRENT_EMULATOR_STATE: EmulatorState = EmulatorState { rom_name: String::new(), core_name: String::new(), frame_buffer: None, pixel_format: PixelFormat::ARGB8888, bytes_per_pixel: 4, screen_pitch: 0, screen_width: 0, screen_height: 0};Now lets set the values after we set the frame buffer:CURRENT_EMULATOR_STATE.frame_buffer = Some(buffer_vec);CURRENT_EMULATOR_STATE.screen_height = height;CURRENT_EMULATOR_STATE.screen_width = width;CURRENT_EMULATOR_STATE.screen_pitch = pitch as u32;Finally lets use the new global variables when updating the minifb frame buffer:unsafe { match &CURRENT_EMULATOR_STATE.frame_buffer { Some(buffer) => { let width = (CURRENT_EMULATOR_STATE.screen_pitch / CURRENT_EMULATOR_STATE.bytes_per_pixel as u32) as usize; let height = CURRENT_EMULATOR_STATE.screen_height as usize; let slice_of_pixel_buffer: &[u32] = std::slice::from_raw_parts(buffer.as_ptr() as *const u32, buffer.len()); // convert to &[u32] slice reference if slice_of_pixel_buffer.len() < width*height*4 { // The frame buffer isn't big enough so lets add additional pixels just so we can display it let mut vec: Vec<u32> = slice_of_pixel_buffer.to_vec(); vec.resize( (width*height*4) as usize, 0x0000FFFF); // Add any missing pixels with colour blue window.update_with_buffer(&vec, width, height).unwrap(); } else { window.update_with_buffer(&slice_of_pixel_buffer, width, height).unwrap(); } } None => { println!(\"We don't have a buffer to display\"); } } }Step 18 - Input HandlingThe ROM will load, get the the main menu and then if you wait long enough it will show a brief demo of the gameplay before going back to the menu and repeating. This is cool but it would be better if we could actually play the game. We already have logic that checks the state of the arrow keys for when we had the blue pixel moving on screen so lets see if we can pass that information to the core and start moving Tetris pieces in the game.First of all how does the core request from the frontend which buttons are pressed? It uses the input state callback which we created a dummy for previously, if we modify it slightly to print out the parameters that the core are passing in like so:unsafe extern \"C\" fn libretro_set_input_state_callback(port: libc::c_uint, device: libc::c_uint, index: libc::c_uint, id: libc::c_uint) -> i16 { println!(\"libretro_set_input_state_callback port: {} device: {} index: {} id: {}\", port, device, index, id); return 0; // Hard coded 0 for now means nothing is pressed}We see that Gambatte is constantly requesting the same port/device/index and only changing the id:libretro_set_input_state_callback port: 0 device: 1 index: 0 id: 9libretro_set_input_state_callback port: 0 device: 1 index: 0 id: 1libretro_set_input_state_callback port: 0 device: 1 index: 0 id: 8libretro_set_input_state_callback port: 0 device: 1 index: 0 id: 0libretro_set_input_state_callback port: 0 device: 1 index: 0 id: 2libretro_set_input_state_callback port: 0 device: 1 index: 0 id: 3libretro_set_input_state_callback port: 0 device: 1 index: 0 id: 7libretro_set_input_state_callback port: 0 device: 1 index: 0 id: 6libretro_set_input_state_callback port: 0 device: 1 index: 0 id: 4libretro_set_input_state_callback port: 0 device: 1 index: 0 id: 5libretro_set_input_state_callback port: 0 device: 1 index: 0 id: 9Looking up the documentation the four parameters are: port: the controller port number. Each controller is associated with a specific port number. device: the device type. This specifies which type of input device the input state is being retrieved for, such as a gamepad, mouse, keyboard, etc. index: the index of the input device. This parameter is used to distinguish between multiple input devices of the same type connected to the same port. id: the input ID or button. This parameter is used to retrieve the current state of a specific button or input on the input device.We only care about 1 player games at the moment, so we just need to map what id values (0-9) should be maped to which keyboard keys, if we look up the libretro-sys library again we can see they have defined some nice constants for us:pub const DEVICE_ID_JOYPAD_B: libc::c_uint = 0;pub const DEVICE_ID_JOYPAD_Y: libc::c_uint = 1;pub const DEVICE_ID_JOYPAD_SELECT: libc::c_uint = 2;pub const DEVICE_ID_JOYPAD_START: libc::c_uint = 3;pub const DEVICE_ID_JOYPAD_UP: libc::c_uint = 4;pub const DEVICE_ID_JOYPAD_DOWN: libc::c_uint = 5;pub const DEVICE_ID_JOYPAD_LEFT: libc::c_uint = 6;pub const DEVICE_ID_JOYPAD_RIGHT: libc::c_uint = 7;pub const DEVICE_ID_JOYPAD_A: libc::c_uint = 8;pub const DEVICE_ID_JOYPAD_X: libc::c_uint = 9;First lets see if we can get past the main menu of Tetris by making the Start button always be pressed:unsafe extern \"C\" fn libretro_set_input_state_callback(port: libc::c_uint, device: libc::c_uint, index: libc::c_uint, id: libc::c_uint) -> i16 { println!(\"libretro_set_input_state_callback port: {} device: {} index: {} id: {}\", port, device, index, id); return match id { libretro_sys::DEVICE_ID_JOYPAD_START => 1, _ => 0 // We don't know this key so mark it as not pressed }}This doesn’t actually work, presumably because the core or ROM is looking for the start button to change state at some point rather than constantly being pressed down. We can hack a solution using a random number generator so it will randomly press the start button constantly:unsafe extern \"C\" fn libretro_set_input_state_callback(port: libc::c_uint, device: libc::c_uint, index: libc::c_uint, id: libc::c_uint) -> i16 { println!(\"libretro_set_input_state_callback port: {} device: {} index: {} id: {}\", port, device, index, id); let mut rng = rand::thread_rng(); let random_number: u8 = rng.gen_range(0..2); return match id { libretro_sys::DEVICE_ID_JOYPAD_START => random_number.into(), _ => 0 // We don't know this key so mark it as not pressed }}Note for this to work you need to add the rand package to your Cargo file:rand = \"0.8.4\"Success we now get past the main menu and since it is constantly pressing the start button on and off it will this constantly keep pausing and unpausing the game:Ok now we know the callback works lets properly handle the input, for this we need to get the list of minifb buttons that are currently pressed down, there is a nice example of this in their documentation:window.get_keys_pressed(KeyRepeat::No).iter().for_each(|key| match key { Key::W => println!(\"pressed w\"), Key::T => println!(\"pressed t\"), _ => (), } );However we need to pass this information so the we can access it in our callback function, we can do this using the global variable we created and just constantly update the variable every frame like so:struct EmulatorState { rom_name: String, core_name: String, frame_buffer: Option<Vec<u32>>, pixel_format: PixelFormat, bytes_per_pixel: u8, // its only either 2 or 4 bytes per pixel in libretro screen_pitch: u32, screen_width: u32, screen_height: u32, buttons_pressed: Option<Vec<i16>>}static mut CURRENT_EMULATOR_STATE: EmulatorState = EmulatorState { rom_name: String::new(), core_name: String::new(), frame_buffer: None, pixel_format: PixelFormat::ARGB8888, bytes_per_pixel: 4, screen_pitch: 0, screen_width: 0, screen_height: 0, buttons_pressed: None};I made it optional to save creating a blank i16 array for the default state, I used the type i16 since that is what the call back function returns but it is really just a boolean in our cases (presumably it is an i16 for input such as game controller analog sticks).Since the callback function is called multiple times a frame, the most efficient way to implement this is to convert the minifb input to the libretro format in the main game loop (once per frame) and save it in our global state variable, rather than saving the minifb input state and converting it every time the callback function is called (multiple times per frame).So lets do that in the main loop like so: let mut this_frames_pressed_buttons = vec![0; 16]; let mini_fb_keys = window.get_keys_pressed(KeyRepeat::No).unwrap(); for key in mini_fb_keys { match key { Key::Enter => {this_frames_pressed_buttons[libretro_sys::DEVICE_ID_JOYPAD_START as usize] = 1;}, Key::Right => {this_frames_pressed_buttons[libretro_sys::DEVICE_ID_JOYPAD_RIGHT as usize] = 1;}, Key::Left => {this_frames_pressed_buttons[libretro_sys::DEVICE_ID_JOYPAD_LEFT as usize] = 1;}, Key::Up => {this_frames_pressed_buttons[libretro_sys::DEVICE_ID_JOYPAD_UP as usize] = 1;}, Key::Down => {this_frames_pressed_buttons[libretro_sys::DEVICE_ID_JOYPAD_DOWN as usize] = 1;}, Key::A => {this_frames_pressed_buttons[libretro_sys::DEVICE_ID_JOYPAD_A as usize] = 1;}, Key::S => {this_frames_pressed_buttons[libretro_sys::DEVICE_ID_JOYPAD_B as usize] = 1;}, _ => {println!(\"Unhandled Key Pressed: {:?}\", key);} } } unsafe { CURRENT_EMULATOR_STATE.buttons_pressed = Some(this_frames_pressed_buttons);Finally we can handle this in the callback function like so:unsafe extern \"C\" fn libretro_set_input_state_callback(port: libc::c_uint, device: libc::c_uint, index: libc::c_uint, id: libc::c_uint) -> i16 { // println!(\"libretro_set_input_state_callback port: {} device: {} index: {} id: {}\", port, device, index, id); let is_pressed = match &CURRENT_EMULATOR_STATE.buttons_pressed { Some(buttons_pressed) => buttons_pressed[id as usize], None => 0 }; return is_pressed;}Now run the program and we can play the full game of Tetris!Step 19 - Mapping the input buttonsThis is great but there are a few limitations, for one we only mapped the buttons for the Game Boy and this wouldn’t work on cores that use more buttons and second it doesn’t allow the users to configure which buttons do what.Since we are a aiming to be a lightweight drop-in-replacement for RetroArch lets find out if RetroArch has a common config format for this purpose so users will be able to use their existing configuration.Lets check to see if ChatGPT knows the answer, it gives us this response: RetroArch stores button mapping in a configuration file format called “RetroPad” or “RetroPad w/Analog”. RetroPad is a JSON-based configuration format used for mapping controllers, while RetroPad w/Analog is an extension of the format that supports analog sticks. The configuration files are typically named “retroarch.cfg” and stored in the RetroArch configuration directory. The file can be edited manually or modified through the RetroArch interface.So first we need to get the location of the RetroArch configuration directory, which varies per Operating System, judging by the documentation this should work but it has only been tested on MacOSX so far:fn get_retroarch_config_path() -> PathBuf { return match std::env::consts::OS { \"windows\" => PathBuf::from(env::var(\"APPDATA\").ok().unwrap()).join(\"retroarch\"), \"macos\" => PathBuf::from(env::var(\"HOME\").ok().unwrap()).join(\"Library/Application Support/RetroArch\"), _ => PathBuf::from(env::var(\"XDG_CONFIG_HOME\").ok().unwrap()).join(\"retroarch\"), };}Now that we can get the location of the file we just need code that can parse the format, which although according to ChatGPT was JSON-based, it is not (could be very loosely javascript based) as it is basically just a key and value on each line separated by an equals symbol, such as:input_player1_a = \"x\"input_player1_a_axis = \"nul\"input_player1_a_btn = \"nul\"input_player1_a_mbtn = \"nul\"input_player1_analog_dpad_mode = \"0\"input_player1_b = \"z\"So we can write a simple function to parse this format into an easy to use HashMap like so:fn parse_retroarch_config(config_file: &Path) -> Result<HashMap<String, String>, String> { let file = File::open(config_file).map_err(|e| format!(\"Failed to open file: {}\", e))?; let reader = BufReader::new(file); let mut config_map = HashMap::new(); for line in reader.lines() { let line = line.map_err(|e| format!(\"Failed to read line: {}\", e))?; if let Some((key, value)) = line.split_once(\"=\") { config_map.insert(key.trim().to_string(), value.trim().replace(\"\\\"\", \"\").to_string()); } } Ok(config_map)}Now lets use these new functions so that we can get the key mappings, lets create a new function that returns the config:fn setup_config() -> Result<HashMap<String, String>, String> { let retro_arch_config_path = get_retroarch_config_path(); let config = parse_retroarch_config(&retro_arch_config_path.join(\"config/retroarch.cfg\")); println!(\"retro_arch_config_path: {} config: {:?}\", retro_arch_config_path.join(\"config/retroarch.cfg\").display(), config); config}I created this as a separate function to the parse_retroarch_config as we will want to add support for users to use our own config file if they don’t want to use the same settings as they use for their RetroArch.We can then call this function like so:let config = setup_config().unwrap();println!(\"Key for Player 1 A button: {}\", config[\"input_player1_a\"]);This is great but the problem with this is the result is a string of the keyboard letter pressed and we need to map it to the correct minifb Key enum type in order to use it.let config = setup_config().unwrap();let key_device_map = HashMap::from([ (&config[\"input_player1_a\"], libretro_sys::DEVICE_ID_JOYPAD_A as usize), (&config[\"input_player1_b\"], libretro_sys::DEVICE_ID_JOYPAD_B as usize), (&config[\"input_player1_x\"], libretro_sys::DEVICE_ID_JOYPAD_X as usize), (&config[\"input_player1_y\"], libretro_sys::DEVICE_ID_JOYPAD_Y as usize), (&config[\"input_player1_l\"], libretro_sys::DEVICE_ID_JOYPAD_L as usize), (&config[\"input_player1_r\"], libretro_sys::DEVICE_ID_JOYPAD_R as usize), (&config[\"input_player1_down\"], libretro_sys::DEVICE_ID_JOYPAD_DOWN as usize), (&config[\"input_player1_up\"], libretro_sys::DEVICE_ID_JOYPAD_UP as usize), (&config[\"input_player1_right\"], libretro_sys::DEVICE_ID_JOYPAD_RIGHT as usize), (&config[\"input_player1_left\"], libretro_sys::DEVICE_ID_JOYPAD_LEFT as usize), (&config[\"input_player1_start\"], libretro_sys::DEVICE_ID_JOYPAD_START as usize), (&config[\"input_player1_select\"], libretro_sys::DEVICE_ID_JOYPAD_SELECT as usize), ]);Now we can rewrite our input handling logic to look like this: let mut this_frames_pressed_buttons = vec![0; 16]; let mini_fb_keys = window.get_keys_pressed(KeyRepeat::Yes).unwrap(); for key in mini_fb_keys { let key_as_string = format!(\"{:?}\", key).to_ascii_lowercase(); if let Some(device_id) = key_device_map.get(&key_as_string) { this_frames_pressed_buttons[*device_id] = 1; } else { println!(\"Unhandled Key Pressed: {} input_player1_a: {}\", key_as_string, config[\"input_player1_a\"]); } } This is great but we shouldn’t expect the user to have RetroArch installed and have a valid config, and we need to support the case where they might want different settings for out frontend compared to their RetroArch, so lets set up some default values and allow users to override them if they have a file called rustroarch.cfg.To do this we can refactor the setup_config function like so:fn setup_config() -> Result<HashMap<String, String>, String> { let retro_arch_config_path = get_retroarch_config_path(); let our_config = parse_retroarch_config(Path::new(\"./rustroarch.cfg\")); let retro_arch_config = parse_retroarch_config(&retro_arch_config_path.join(\"config/retroarch.cfg\")); let mut merged_config: HashMap<String, String> = HashMap::from([ (\"input_player1_a\", \"a\"), (\"input_player1_b\", \"s\"), (\"input_player1_x\", \"z\"), (\"input_player1_y\", \"x\"), (\"input_player1_l\", \"q\"), (\"input_player1_r\", \"w\"), (\"input_player1_down\", \"down\"), (\"input_player1_up\", \"up\"), (\"input_player1_left\", \"left\"), (\"input_player1_right\", \"right\"), (\"input_player1_select\", \"space\"), (\"input_player1_start\", \"enter\"), (\"input_reset\", \"h\"), (\"input_save_state\", \"f2\"), (\"input_load_state\", \"f4\"), (\"input_screenshot\", \"f8\"), (\"savestate_directory\", \"./states\"), ]).iter() .map(|(k, v)| (k.to_string(), v.to_string())) .collect(); match retro_arch_config { Ok(config) => merged_config.extend(config), _ => println!(\"We don't have RetroArch config\") } match our_config { Ok(config) => merged_config.extend(config), _ => println!(\"We don't have RustroArch config\",) } // println!(\"retro_arch_config_path: {} merged_config: {:?}\", retro_arch_config_path.join(\"config/retroarch.cfg\").display(), merged_config); Ok(merged_config)}In this code first we setup some default config values, mainly for input handling but I also added some related to save states as that is what we will work on in the next step. The default values means users don’t need any config files to use the frontend, as long as they like the defaults. It then checks if we have RetroArch config and overrides the defaults with these settings if they exist. FInally we check for a rustroarch.cfg file and if so it will override the values with the values in that file.Lets start keeping track of the size of the executable, I should have done this from the start but here we go: Size of executable so far: 1.1MBStep 20 - Saving and Loading stateWe are doing well but we still haven’t implemented one of my favourite features of emulators, save states. In the config file we have two settings for the buttons used to trigger saving and loading states: input_save_state input_load_stateSo lets first check if the user has pressed either of those buttons and if so print a message to the command line: // Input Handling for the keys pressed in minifb cargo for key in mini_fb_keys { let key_as_string = format!(\"{:?}\", key).to_ascii_lowercase(); if let Some(libretro_button_id) = key_device_map.get(&key_as_string) { this_frames_pressed_buttons[*libretro_button_id] = 1; continue; } if &key_as_string == &config[\"input_save_state\"] { println!(\"Save state called\"); continue; } if &key_as_string == &config[\"input_load_state\"] { println!(\"Load state called\"); continue; } println!(\"Unhandled Key Pressed: {} \", key_as_string); }So now when we press the buttons it will at least write the message to the console, so the next question is how do we call the core to create a save state?LibRetro has a function called retro_serialize which has the following signature:pub retro_serialize: unsafe extern \"C\" fn(data: *mut libc::c_void, size: libc::size_t)So we need to pass in a mutable buffer that the core can put all the save data in, along with the size of that buffer.But how do we know how large the buffer should be, well libRetro also has us covered there with this function:pub retro_serialize_size: unsafe extern \"C\" fn() -> libc::size_t,We can put all this logic in its own function and use the builtin rust library to write it to a file like so:unsafe fn save_state(core_api: &CoreAPI) { let save_state_buffer_size = (core_api.retro_serialize_size)(); let mut state_buffer: Vec<u8> = vec![0; save_state_buffer_size]; // Call retro_serialize to create the save state (core_api.retro_serialize)(state_buffer.as_mut_ptr() as *mut c_void, save_state_buffer_size); let file_path = \"./save_state.state\"; std::fs::write(file_path, &state_buffer).unwrap(); println!(\"Save state saved to: {} with size: {}\", file_path, save_state_buffer_size);}This will save the state into the current directory with the hardcoded name save_state.state but the problem is this same file will be overriden no matter what ROM you load, ideally it would be good to save a different file based on the game you are playing.After saving a file using RetroArch itself it seems to save with both the ROM name and also a save state index (which can be incremented/decremented by the user) and it also replaces any invalid characters (such as spaces) with the _ character, this is quite a bit of logic in itself and we will need this logic in both saving and loading of state so lets create a new function for this purpose:fn get_save_state_path(save_directory: &String, game_file_name: &str, save_state_index: u32) -> Option<PathBuf> { // Create a subdirectory named \"saves\" in the current working directory let saves_dir = PathBuf::from(save_directory); if !saves_dir.exists() { match std::fs::create_dir(&saves_dir) { Ok(_) => {} Err(err) => panic!(\"Failed to create save directory: {:?} Error: {}\", &saves_dir, err), } } // Generate the save state filename let game_name = Path::new(game_file_name) .file_stem() .unwrap_or_default() .to_string_lossy() .replace(\" \", \"_\"); let save_state_file_name = format!(\"{}_{}.state\", game_name, save_state_index); // Combine the saves directory and the save state filename to create the full path let save_state_path = saves_dir.join(save_state_file_name); Some(save_state_path)}We also added creation of the directory if it doesn’t already exist, you can call this function from the save_state function like so:let file_path = get_save_state_path(save_directory, &CURRENT_EMULATOR_STATE.rom_name, 0).unwrap(); // hard coded save_slot to 0 for now std::fs::write(&file_path, &state_buffer).unwrap(); println!(\"Save state saved to: {} with size: {}\", &file_path.display(), save_state_buffer_size);Saving states are useless if we can’t load them back again, to do that we can pretty much just do the opposite of saving, by calling the retro_unserialize libRetro function:pub retro_unserialize: unsafe extern \"C\" fn(data: *const libc::c_void, size: libc::size_t) -> bool,So the load_state function can now look like this:unsafe fn load_state(core_api: &CoreAPI, save_directory: &String) { let file_path = get_save_state_path(save_directory, &CURRENT_EMULATOR_STATE.rom_name, 0).unwrap(); // Hard coded the save_slot to 0 for now let mut state_buffer = Vec::new(); match File::open(&file_path) { Ok(mut file) => { // Read the save state file into a buffer match file.read_to_end(&mut state_buffer) { Ok(_) => { // Call retro_unserialize to apply the save state let result = (core_api.retro_unserialize)(state_buffer.as_mut_ptr() as *mut c_void, state_buffer.len() as usize); if result { println!(\"Save state loaded from: {}\", &file_path.display()); } else { println!(\"Failed to load save state: error code {}\", result); } } Err(err) => println!(\"Error reading save state file: {}\", err), } } Err(_) => println!(\"Save state file not found\"), }}And we can call it similar to how we call save_state: if &key_as_string == &config[\"input_save_state\"] { unsafe { save_state(&core_api, &config[\"savestate_directory\"]); } continue; } if &key_as_string == &config[\"input_load_state\"] { unsafe { load_state(&core_api, &config[\"savestate_directory\"]); } continue; } Step 21 - Supporting save slotsYou will notice that we hard coded the save_slot_index to 0, we can now store the current save slot index in our global variable and then allow the user to increment and decrement the current save slot, allowing them to have different save states for the same game.First lets add another field to our global to keep track of the current slot:struct EmulatorState { rom_name: String, core_name: String, frame_buffer: Option<Vec<u32>>, pixel_format: PixelFormat, bytes_per_pixel: u8, // its only either 2 or 4 bytes per pixel in libretro screen_pitch: u32, screen_width: u32, screen_height: u32, buttons_pressed: Option<Vec<i16>>, current_save_slot: u8}Made it a u8 as 255 values should be more than enough for a single game, but if its not enough for your needs feel free to change the type.We can now use this variable by modifying the save and load state functions when calling the get_save_state_path function: let file_path = get_save_state_path(save_directory, &CURRENT_EMULATOR_STATE.rom_name, CURRENT_EMULATOR_STATE.current_save_slot).unwrap();There are two config variables for allowing the player to change the current save slot selected: input_save_slot_decrease input_save_slot_increaseLets add the default values to the config:(\"input_state_slot_decrease\", \"f6\"),(\"input_state_slot_increase\", \"f7\"),And now read them from out input handling code: if &key_as_string == &config[\"input_state_slot_increase\"] { if CURRENT_EMULATOR_STATE.current_save_slot != 255 { CURRENT_EMULATOR_STATE.current_save_slot+=1; println!(\"Current save slot increased to: {}\", CURRENT_EMULATOR_STATE.current_save_slot) } continue; } if &key_as_string == &config[\"input_state_slot_decrease\"] { if CURRENT_EMULATOR_STATE.current_save_slot != 0 { CURRENT_EMULATOR_STATE.current_save_slot-=1; println!(\"Current save slot decreased to: {}\", CURRENT_EMULATOR_STATE.current_save_slot) } continue; } Now if you run the program you can incfrease and decrease the save slots and it will allow you to have multiple saves for the same game.Step 22 - Audio SupportSo far the game is playable but rather… quiet, lets change that by adding audio support!We already implemented the two audio callbacks as dummy functions before to prevent the core from causing a segmentation fault but they don’t do anything yet:unsafe extern \"C\" fn libretro_set_audio_sample_callback(left: i16, right: i16) { println!(\"libretro_set_audio_sample_callback left channel: {} right: {}\", left, right);unsafe extern \"C\" fn libretro_set_audio_sample_batch_callback( data: *const i16, frames: libc::size_t,) -> libc::size_t { // println!(\"libretro_set_audio_sample_batch_callback\"); return 1;}The first function libretro_set_audio_sample_callback doesn’t seem to be used by the Gambate core that I am using for testing so we will need to come back to this when we find a core that requires it.So libretro_set_audio_sample_batch_callback seems to have two parameters, one is a data buffer that contains both the left and right audio channel dataper frame and the other is the number of frames that are in the buffer.Before we can use this data we first need to figure out how we can play audio in rust across all the major Operating Systems. So after a quick google search the first result was the rodio crate, so lets add it to our Cargo project:cargo add rodioNow lets try to get the main example from the Rodio documentation to work:use std::fs::File;use std::io::BufReader;use std::time::Duration;use rodio::{Decoder, OutputStream, Sink};use rodio::source::{SineWave, Source};fn play_audio() { let (_stream, stream_handle) = OutputStream::try_default().unwrap(); let sink = Sink::try_new(&stream_handle).unwrap(); // Add a dummy source of the sake of the example. let source = SineWave::new(440.0).take_duration(Duration::from_secs_f32(0.25)).amplify(0.20); sink.append(source); // The sound plays in a separate thread. This call will block the current thread until the sink // has finished playing all its queued sounds. sink.sleep_until_end();}Now call play_audio somewhere in the main game loop for example:unsafe { (core_api.retro_run)(); } play_audio();If all went well you will get an annoying sound while the game is playing, but how do we convert the buffer that the callback gives us into something that rodio can play?First lets add an audio_data buffer to our global variable so that we can pass it between the callback and the play_audio function:struct EmulatorState { rom_name: String, core_name: String, frame_buffer: Option<Vec<u32>>, audio_data: Option<Vec<i16>>,Now lets update the callback so that it sets the global variables value every time its called:const AUDIO_CHANNELS: usize = 2; // left and rightunsafe extern \"C\" fn libretro_set_audio_sample_batch_callback( audio_data: *const i16, frames: libc::size_t,) -> libc::size_t { let audio_slice = std::slice::from_raw_parts(audio_data, frames * AUDIO_CHANNELS); CURRENT_EMULATOR_STATE.audio_data = Some(audio_slice.to_vec()); return frames;}We need to be able to take that audio_data and play it back inside Rodeo, for this Rodeo provides a SamplesBuffer that we can use as a source: match &CURRENT_EMULATOR_STATE.audio_data { Some(data) => { if sink.empty() { let audio_slice = std::slice::from_raw_parts(data.as_ptr() as *const i16, data.len()); let source = SamplesBuffer::new(2, 32768, audio_slice); sink.append(source); sink.play(); sink.sleep_until_end(); } }, None => {}, };If you run the program now you will notice that it starts to play audio, but in a very slow manner, turns out audio processing is very cpu time consuming.You will also notice a massive dip in the frame rate, this is because we are setting up a brand new audio sink every frame, lets move this logic out ibefore the main loop and pass the Sink in to the play_audio function:let core_api; let (_stream, stream_handle) = OutputStream::try_default().unwrap(); let sink = Sink::try_new(&stream_handle).unwrap();Now just pass it into the call to play_audio like so:play_audio(&sink);You will notice that this has helped the frame rate a bit (around 30 fps on my machine) but its still half of what it was before we added audio support, in the next step we can sort this. Size of executable so far: 1.4MBStep 23 - Creating an Audio ThreadAudio processing is very cpu intensive and so far we have done all our logic in a single thread, this is now affecting the frame rate of games being played in our frontend. One solution for this is to put the audio processing in its own thread and just pass the audio data between the threads.Lets first modify the Audio setup so that iut creates a new thread and creates the Rodeo Sink inside that thread like so:// Audio Setup let (_stream, stream_handle) = OutputStream::try_default().unwrap(); // Create a channel for passing audio samples from the main thread to the audio thread let (sender, receiver) = channel(); // Spawn a new thread to play back audio let audio_thread = thread::spawn(move || { let sink = Sink::try_new(&stream_handle).unwrap(); loop { // Receive the next set of audio samples from the channel let audio_samples = receiver.recv().unwrap(); unsafe { play_audio(&sink, audio_samples); } // pass the audio samples to the play_audio function } });In this example, we create a channel using the channel function from the std::sync::mpsc module. The sender and receiver variables are used to send and receive audio samples between the main thread and the audio thread, respectively.Since we don’t want to directly use the same variable in both threads we need to create a new function to send the audio data over ever frame:unsafe fn send_audio_to_thread(sender: &Sender<&Vec<i16>>) { // Send the audio samples to the audio thread using the channel match &CURRENT_EMULATOR_STATE.audio_data { Some(data) => { sender.send(data).unwrap(); }, None => {}, }; }Now we modify the play_audio function so that we can have the audio samples passed in from the thread:unsafe fn play_audio( sink: &Sink, audio_samples: &Vec<i16>) { if sink.empty() { let audio_slice = std::slice::from_raw_parts(audio_samples.as_ptr() as *const i16, audio_samples.len()); let source = SamplesBuffer::new(2, 32768, audio_slice); sink.append(source); sink.play(); sink.sleep_until_end(); }Now in the main game loop lets replace the call to play_audio with a call to send_audio instead:send_audio_to_thread(&sender);Run the program and you will notice that we not only have audio but we are again running at full frame rate, multi-threading for the win!Although sometimes when you exist the program you will get the following error:thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError'Step 24 - Get Audio/Video Data from the coreYou will notice that in the previous step we hard coded the audio sample rate at 32768, while this is correct for the Game Boy, it won;’t be correct for other cores, so it would be ideal to be able to allow each core to specify its own sample rate. This is where the libRetro function retro_get_system_av_info comes in.So just after the call to retro_init we can call it and print the result we get back like so:let mut av_info = SystemAvInfo { geometry: GameGeometry { base_width: 0, base_height: 0, max_width: 0, max_height: 0, aspect_ratio: 0.0, }, timing: SystemTiming { fps: 0.0, sample_rate: 0.0, }, }; (core_api.retro_get_system_av_info)(&mut av_info); println!(\"AV Info: {:?}\", &av_info);Now we just need to save this information in our global variable so we can refer to the sample_rate from out audio code, lets modify the definition of EmulatorState to add av_info:struct EmulatorState { rom_name: String, core_name: String, frame_buffer: Option<Vec<u32>>, audio_data: Option<Vec<i16>>, pixel_format: PixelFormat, bytes_per_pixel: u8, // its only either 2 or 4 bytes per pixel in libretro screen_pitch: u32, screen_width: u32, screen_height: u32, buttons_pressed: Option<Vec<i16>>, current_save_slot: u8, av_info: Option<SystemAvInfo>}static mut CURRENT_EMULATOR_STATE: EmulatorState = EmulatorState { rom_name: String::new(), core_name: String::new(), frame_buffer: None, audio_data: None, pixel_format: PixelFormat::ARGB8888, bytes_per_pixel: 4, screen_pitch: 0, screen_width: 0, screen_height: 0, buttons_pressed: None, current_save_slot: 0, av_info: None};Now modify the code after the call to retro_get_system_av_info to set the global variable:(core_api.retro_get_system_av_info)(&mut av_info); println!(\"AV Info: {:?}\", &av_info); CURRENT_EMULATOR_STATE.av_info = Some(av_info);We can now update the play_audio function to n ow take in the sample_rate:unsafe fn play_audio( sink: &Sink, audio_samples: &Vec<i16>, sample_rate: u32) { if sink.empty() { let audio_slice = std::slice::from_raw_parts(audio_samples.as_ptr() as *const i16, audio_samples.len()); let source = SamplesBuffer::new(2, sample_rate, audio_slice); sink.append(source); sink.play(); sink.sleep_until_end(); }}And to get the global sample rate and padd it to play audio we need to change the audio thread code to the following:let audio_thread = thread::spawn(move || { println!(\"Audio Thread Started\"); let sample_rate = unsafe { match &CURRENT_EMULATOR_STATE.av_info { Some(av_info) => av_info.timing.sample_rate, None => 0.0 } }; let (_stream, stream_handle) = OutputStream::try_default().unwrap(); let sink = Sink::try_new(&stream_handle).unwrap(); loop { // Receive the next set of audio samples from the channel let audio_samples = receiver.recv().unwrap(); unsafe { play_audio(&sink, audio_samples, sample_rate as u32); } } });Now we should be able to support more cores in the future!Step 25 - Game Controller supportLets add the gilrs cargo to our rust project:cargo add gilrsAnd import it at the top of our file:use gilrs::{Gilrs, Button, Event};Similaer to how we did the keyboard input mapping from minifb we need to create a map from the gilrs::Button to the libRetro button id, as this code will be quite long lets put it in its own function:fn setup_joypad_device_map() -> HashMap<Button, usize> { return HashMap::from([ ( Button::South, libretro_sys::DEVICE_ID_JOYPAD_A as usize, ), ( Button::East, libretro_sys::DEVICE_ID_JOYPAD_B as usize, ), ( Button::West, libretro_sys::DEVICE_ID_JOYPAD_X as usize, ), ( Button::North, libretro_sys::DEVICE_ID_JOYPAD_Y as usize, ), ( Button::LeftTrigger, libretro_sys::DEVICE_ID_JOYPAD_L as usize, ), ( Button::LeftTrigger2, libretro_sys::DEVICE_ID_JOYPAD_L2 as usize, ), ( Button::RightTrigger, libretro_sys::DEVICE_ID_JOYPAD_R as usize, ), ( Button::RightTrigger2, libretro_sys::DEVICE_ID_JOYPAD_R2 as usize, ), ( Button::DPadDown, libretro_sys::DEVICE_ID_JOYPAD_DOWN as usize, ), ( Button::DPadUp, libretro_sys::DEVICE_ID_JOYPAD_UP as usize, ), ( Button::DPadRight, libretro_sys::DEVICE_ID_JOYPAD_RIGHT as usize, ), ( Button::DPadLeft, libretro_sys::DEVICE_ID_JOYPAD_LEFT as usize, ), ( Button::Start, libretro_sys::DEVICE_ID_JOYPAD_START as usize, ), ( Button::Select, libretro_sys::DEVICE_ID_JOYPAD_SELECT as usize, ), ]);}We now need to call this function under where we setup the keyboard mapping like so:let joypad_device_map = setup_joypad_device_map();Now before the code to load the libRetro lets do some initialisation that is required for gilrs:println!(\"Gamepad Setup\"); let mut gilrs = Gilrs::new().unwrap(); let mut active_gamepad = None;This code should only be executed once as it creates the Gilrs object and creates a variable that will store the active gamepad. We need this variable as multiple gamepads can be connected and we need to know which one to poll for input.Now in the main game loop we need to listen for events to see which gamepad is currently being used by the user: // Gamepad input Handling // Examine new events to check which gamepad is currently being used while let Some(Event { id, event, time }) = gilrs.next_event() { // println!(\"{:?} New event from {}: {:?}\", time, id, event); active_gamepad = Some(id); }Just after this code we can use that active_gamepad variable to check if any buttons are pressed on that controller: // Now Lets check what buttons are pressed and map them to the libRetro buttons if let Some(gamepad) = active_gamepad.map(|id| gilrs.gamepad(id)) { for button in [Button::South, Button::North, Button::East, Button::West, Button::Start, Button::Select, Button::DPadDown, Button::DPadUp, Button::DPadLeft, Button::DPadRight, Button::LeftTrigger, Button::LeftTrigger2, Button::RightTrigger, Button::RightTrigger2] { if gamepad.is_pressed(button) { println!(\"Button Pressed: {:?}\", button); let libretro_button = joypad_device_map.get(&button).unwrap(); this_frames_pressed_buttons[*libretro_button] = 1; } } }Now if you run the program you will be able to control your Game Boy ROM with a plugged in game controller. However I personally had problems with a few controllers that I own while running this on MacOSX: Controller from PS1 Mini - D-pad issues where the only d-pad button that works is RIGHT, it thinks DOWN is up and UP/LEFT don’t do anything. RetroBit Sega Saturn Controller - Same issues as aboveI am not sure if its the gilrs library or a MacOSX issue, or it could be my controllers.I will need to test on other platforms and with other controllers to figure out what is going wrong. I tried in RetroArch but it didn’t auto-detect these controllers, but I could go into settings to configure them manually and the D-pad was fine. Size of executable is now 1.8MB due to the added Gilrs cargo", "excerpt": "Welcome to this comprehensive tutorial on creating a LibRetro Frontend using Rust! If you’re passionate about retro gaming and interested in creating your very own emulation frontend from scratch, you’ve come to the right place. Rust, with its strong safety guarantees, performance, and concurrency support, makes it an ideal choice...", "tags": ["introduction","tutorial","tools"], "image": "/public/images/tutorials/Creating a LibRetro Frontend in Rust.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Creating a new reversing emulator", "url": "/create-reversing-emulator", "content": "Step by step guide for how to create a Reversing emulator for your console of choice.Note that you may not need this guide if someone has already created a Reversing emulator for your console.Step 1 - Initial Repository SetupFork an emulator for your consoleSince the libRetroReversing library is based on libRetro it is easier to find an existing libRetro based emulator and fork it as the basis of your new project.You can find the emulators here:libretro Emulator RepositoriesFind the repository most suited for your project, as there can be multiple emulators for your target console, do some research to find out which one you personally prefer.In this example we chose the Sega Saturn emulator from libretro and clicked fork, resulting in our own forked version of the repository here: https://github.com/RetroReversing/yabauseAdd LibRetroReversing as a submoduleFirst checkout your newly forked repository to your local machine and then open a new terminal in the root of the repository.Now run the following command:git submodule add https://github.com/RetroReversing/libRetroReversing.gitThis should run and when finished you will see a new folder called libRetroReversing in that root directory.Now to make sure it is correct lets run git status like so:git statusThe output should look something like this:On branch masterYour branch is up to date with 'origin/master'.Changes to be committed: (use \"git restore --staged <file>...\" to unstage)\tnew file: ../.gitmodules\tnew file: ../libRetroReversingCommit the initial changesRun the following in the same terminal you have been using previously:git commit -m \"First step in creating a Reversing emulator\"Push the changes to githubThat should create your first commit and now to make sure you don’t loose your precious work lets push back to github:git push origin masterStep 2 - Building the EmulatorThis is where it will get a little bit different depending on the emulator (libretro core) you are trying to build.2.1 Find the MakefileYou need to look for a file called Makefile.libretro OR one simply called Makefile, the letter case doesn’t matter.If you can’t find it but you have a file called CMakeLists.txt then you have an extra step before going to step 2.2.2.1a Generate the Makefile with CMakeThis step is only required if you don’t have a Makefile already generated.You need to go to the directory of your CMakeLists.txt file in your terminal and run the following command:cmake .After this has succeeded then you should get a “Makefile” file generated. If you don’t then please ask in the comments below and we should be able to help.2.2 Running the MakefileBefore making changes to the Makefile its important that we can successfully run it.So now that you are in the folder with the Makefile you simply need to run:make2.2a Missing FilesThe problem with some of the libretro cores is that they sometimes reference system files that you don’t have, so when running make you may encounter issues such as:#include <SDL2/SDL.h>Depending on your system you may have to install SDL2 from a package manager, e.g on Macos:brew install SDL2In my case I already had it installed but it still wasn’t finding it so I got the path to the file using the locate command like so:locate SDL.hIt came up with a few paths including the one I want to use /usr/local/Cellar/sdl2/2.0.9_1/include/SDL2/SDL.h.So I added the following to my environment:export C_INCLUDE_PATH=/usr/local/Cellar/sdl2/2.0.9_1/include/Step 3 - Running the EmulatorNow that you have successfully compiled the library into a binary (with an extension such as .dylib, .dll or .so), you are ready to run it!Try running from command lineYou can run the library you built through the terminal like so:/Applications/RetroArch.app/Contents/MacOS/RetroArch -L mednafen_saturn_libretro.dylib \"/Saturn/Games/Awesome Game.cue\" -vNote that for consoles that require a BIOS make sure it is located in the System directory of RetroArch. Mine was ~/Documents/RetroArch/system.Step 4 - Modifying the Makefile to include libRetroReversing4.1 Add include to MakefileFind the main Makefile for your core, for example it may be called Makefile.libretro.Find the line that imports the common makefile:include $(BUILD_DIR)/Makefile.commonAdd the following line after it, chaning ConsoleName to the name of the console (you will need this name later):libRetroReversingConsole = ConsoleNameinclude ./libRetroReversing/Makefile.retroreversingFor example in the emulator SameBoy the Makefile for libretro is in its own libretro folder as you can see in the screenshot below:4.2 Re-makeNow that you have included the libRetroReversing source files, re-run make the same way you did earlier and then make sure the emulator still works, you can do all this with the one liner below.make && /Applications/RetroArch.app/Contents/MacOS/RetroArch -L mednafen_saturn_libretro.dylib \"/Saturn/Games/Awesome Game.cue\" -vAdd specific functions for your consoleIn the libRetroReversing submodule duplicate a file called ./console/DummyConsole.cpp and name it after your console e.g Saturn.cpp. This needs to match the ConsoleName exactly as you defined it earlier in step 4.1.This file will be the main interface that will hold the custom code for your specific emulator.There are a couple of functions you will need to implement:Step 5 - Source Modifications5.1 Add Include to top of libretro.cFind either libretro.c or libretro.cpp and add the following include to the top of the file:#include \"libRetroReversing/include/libRR.h\"5.2 Add Logging of InputFinding where to put this function call is tricky as it depends where input is handled in the core you are modifying, but try to find a function that uses retro_input_state_t and add the following call, which will modify the input based on if we are in playback mode or recording mode//libRR start retro_input_state_t input_cb = libRR_handle_input(original_input_state_cb); // libRR end5.2.1 Add Input DescriptorsFind code like the following:environ_cb( RETRO_ENVIRONMENT_SET_INPUT_DESCRIPTORS, desc );And add the following code under it, note that whatever was in the second parameter slot (desc in thsi case) should be passed as the first parameter:libRR_setInputDescriptor(desc, 21);5.3 Allow libRR to pause the gameFind the retro_run function and add the following code to the top of it:// libRR start bool should_continue = libRR_run_frame(); if (!should_continue) { return; } // libRR end5.4 Override the Video Callback functionFind any calls to the function video_cb and replace them with calls to libRR_video_cb.5.5 Hook into retro_load_gameFind the definition of the retro_load_game function and add code like the following:// libRR startlibRR_handle_load_game(info, environ_cb);// libRR end", "excerpt": "Step by step guide for how to create a Reversing emulator for your console of choice. Note that you may not need this guide if someone has already created a Reversing emulator for your console. Step 1 - Initial Repository Setup Fork an emulator for your console Since the libRetroReversing...", "tags": ["reversingEmulator","introduction"], "image": "/public/Articles/Creating a new Reversing Emulator.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Awesome list of DOS Game Development and Reverse Engineering information", "url": "/dos", "content": "IntroductionWelcome to our page dedicated to DOS reverse engineering! PCs are some of the most versatile and widely-used computing platforms in the world, and there’s no shortage of interesting and challenging reverse engineering topics to explore. If you’re interested in learning more about the technical aspects of PCs and how they work, you’ve come to the right place.On this page, we’ve compiled a list of links to other pages that cover various topics related to DOS reverse engineering. Whether you’re interested in understanding the hardware architecture of retro CPUs and GPUs, analyzing software at the binary level, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to.So grab your keyboard and mouse, and get ready to dive into the exciting world of DOS reverse engineering!Windows PC Game ReversingNote that if you are interested in reversing Windows bases PC games we have a separate post on that topic: Awesome list of Windows 3.x+ Reverse Engineering and Game Development information For more information on Windows PC game reversing check out this post. MSX Game ReversingNote that if you are interested in the MSX PC we have a separate post on that topic: MSX For more information on the MSX check out this post. Glossary of Key TermsIf you are unfamiliar with the technical specifications of late 80s and early 90s PC hardware, this glossary provides context for the techniques mentioned: Mode 13h - A standard VGA graphics mode providing 320x200 resolution with 256 colors from a palette of 262,144. PIT - The Programmable Interval Timer (Intel 8253/8254), used for system timing and generating precise hardware interrupts. IRQ0 - The highest priority hardware interrupt on the PC, typically mapped to the system timer. Open Watcom - A C/C++ compiler suite famous for its high-performance code generation for DOS extenders.DOS-era PC HardwareGame PortsUnlike modern PCs it was fairly common to have Game ports (15-pin DA-15 connectors) which could be used for both joysticks and game controllersDOS-era Graphics HardwareFor DOS games, the video card ports and expansion bus types evolved over time, with ISA dominating early DOS gaming through the 80s and early 90s.Here’s a chronological overview of the common video card ports used for DOS gaming graphics and their associated buses: Bus / Port Type Time Period Notes & Relation to DOS Gaming ISA (Industry Standard Architecture) 1981 to mid-1990s The dominant bus for early DOS graphics cards like CGA, EGA, and VGA cards. ISA ran at 8 MHz (later 16-bit at 8-10 MHz) and was the standard for most DOS expansion cards initially. VESA Local Bus (VLB) Early 1990s (~1992 to 1994) A 32-bit local bus designed to increase throughput for VGA/SVGA cards by connecting directly to the CPU bus at 33 MHz. VLB cards were used briefly in DOS gaming to allow faster graphics and higher resolutions. Mostly on 486 systems. PCI (Peripheral Component Interconnect) Mid 1990s onwards (from ~1993) PCI replaced VLB and ISA for most expansions. PCI introduced a separate clock and 32-bit or 64-bit data width with higher throughput, becoming common in late DOS era and Windows 95 gaming. Many late DOS and early Windows 3.x/95 games used PCI graphics cards. Here are what the ports looked like for anyone curious to build a retro PC using original hardware:ISA 16-Bit:ISA 8-Bit:VESA Local Bus (VLB): There were many motherboards that supported multiple different ports at once such as ISA 16-bit, 8-bit and VLB, thanks to Juan Linietsky on Twitter!How does the industry make sure there is compatibility between different manufactures of Graphics hardware?This is where the The Video Electronics Standards Association (VESA) comes in, VESA’s primary mission is to develop and promote open standards for the display industry, ensuring interoperability and enhancing the user experience across various devices. Without their standards your PC wouldn’t even boot if it wasn’t compatible with the motherboard.DOS Game Reverse EngineeringReversing DOS games with CicoParserCicoParser is a tool that helps convert old DOS programs to run on modern computers. Instead of emulating the entire DOS system, it translates the program’s assembly code into C code. This makes the program run much faster and allows for easier modification and improvement of the original application.You can find it on Github:Education/2021/CicoParser at master · gabonator/EducationHere is a video from the author:Reverse Engineering Strike CommanderFabien Sanglard has an excellent series of articles on how he reverse engineered the classic flight simulator Strike Commander:Reverse Engineering Strike CommanderCarmageddonThanks to debug symbols being found in the Carmageddon Splat Pack expansion and the amazing work of the community there is now a reversing project for Carmageddon called Dethrace.dethrace-labs/dethrace: Reverse engineering the 1997 game “Carmageddon”How Pizza Tycoon Simulated TrafficPizza Legacy features a technical write-up on reverse engineering the traffic simulation system from the 1994 DOS game Pizza Tycoon. The post covers the specific algorithms and engine optimizations the original developers used to route dozens of cars through a city on a strict 25 MHz CPU budget. These structural insights directly support the ongoing open-source C++ reimplementation of the game. How Pizza Tycoon simulated traffic on a 25 MHz CPU The Pizza Legacy blog explores the reverse engineering of Pizza Tycoon's 1994 traffic engine, detailing how developers managed city-wide vehicle simulation with minimal CPU overhead. DOS Game DevelopmentPorting Retro City Rampage to MS-DOSGDC hosted this technical presentation by Brian Provinciano, the creator of Retro City Rampage. The talk details the process of back-porting a modern game to the constraints of a 1990s MS-DOS environment, specifically targeting 486-class hardware with strict memory and storage limitations.Technical Constraints and GoalsThe porting process was defined by the need to shrink a modern codebase into a footprint compatible with legacy hardware: Target Hardware - Minimum requirement of a 486 DX IBM PC compatible with 4MB of RAM. Operating System - Designed for MS-DOS 3.3 or higher. Storage Limit - The entire game, including assets, was required to fit on a single 1.44MB 3.5” high-density floppy disk. Graphics Architecture - Utilized a simple 1-byte-per-pixel buffer to map directly to VGA memory for performance.Optimization StrategiesProvinciano discusses several low-level techniques used to achieve real-time performance on the 486: Reprogramming PIT - The system timer was reprogrammed to increase precision beyond the default 55ms tick, allowing for synchronized audio and video. Inline Assembly - Used for performance-critical sections such as hiding the mouse cursor via int 33h and custom tile-drawing routines. Asset Compression - Implemented a two-stage compression pipeline: RLE (Run-Length Encoding) for fast runtime rendering and zlib for minimizing executable size on disk. Data Generation - To save disk space, pathfinding navigation data and car collision objects were generated procedurally from world collision data rather than being stored as distinct files. Memory Management - Aggressive use of #ifdef blocks to strip out modern engine features while maintaining a shared codebase between PS4 and DOS versions.DOS Gaming Aspect Ratio - 320x200The Youtuber Displaced Gamers has an excellent video explaining the common DOS aspect ratio:32-bit DOS ApplicationsThe video discusses the 640k memory limitation of DOS and why many DOS games require more than 1MB of memory. The 16-bit x86 architecture used a trick to address up to one megabyte of memory, which became a limitation as software became more complicated. DOS extenders were developed to allow 32-bit memory access with almost no performance penalty, enabling 32-bit games to run on 16-bit MS-DOS. DOS extenders were based on the DPMI specification, providing larger memory access and multitasking capabilities. Developers only needed to know how to use the correct DOS external functions when mode switching was necessary. The use of DOS extenders extended the lifespan of MS-DOS and its legacy is engraved into the memory of classic DOS games, which shaped the video game industry.Real ModeReal mode is a processor mode in the x86 architecture where the CPU can directly access the first 1MB of memory. In real mode, the CPU uses 16-bit registers and addresses memory using 20-bit addresses that are formed by combining a 16-bit segment address with a 16-bit offset address. Real mode is the default mode of operation for the x86 CPU, and it was used in early versions of MS-DOS.Protected ModeProtected mode is another processor mode in the x86 architecture that allows the CPU to access more than 1MB of memory, up to 4GB. Protected mode uses a different memory addressing scheme, called linear addressing, where memory is addressed using 32-bit addresses. Protected mode also provides hardware-based memory protection and multitasking capabilities, which make it suitable for modern operating systems like Windows and Linux. Protected mode is used by modern operating systems, and it requires a transition from real mode to enter this mode of operation.DOS ExtendersDOS extenders work by extending the 16-bit real mode of the x86 architecture to allow 32-bit applications to run on the platform. In real mode, applications can only access up to 1MB of memory. DOS extenders enable applications to access more memory by running in protected mode, which allows them to use up to 4GB of memory.DOS extenders operate by adding an additional layer between the application and the operating system. This layer intercepts certain system calls made by the application and provides additional functionality. The extender provides a set of APIs that allow the application to access memory beyond the 1MB limit and other system services that are not available in real mode.The DOS extender typically consists of a small loader program and a runtime library that is linked with the application. When the application is launched, the loader program loads the extender and initializes it. The extender then sets up a protected mode environment and transfers control back to the application, which can now use 32-bit instructions and access more memory.The use of DOS extenders allows applications to take full advantage of the capabilities of the x86 architecture, and it played a crucial role in the development of early PC games. DOS extenders were particularly important for games that required a lot of memory and high-performance graphics, as they allowed developers to create games that pushed the limits of the platform.DPMI - DOS Protected Mode InterfaceDPMI stands for “DOS Protected Mode Interface” It is a specification that provides a way for DOS applications to run in protected mode, which allows them to access more memory and run more efficiently. DPMI was developed in the late 1980s and early 1990s, during a time when the transition from 16-bit to 32-bit computing was taking place. DPMI provides a set of services that allow DOS applications to run in a protected environment, including virtual memory management, task switching, and interrupt handling. It was used extensively in the development of DOS extenders, which allowed 32-bit applications to run on DOS systems. The DPMI specification was widely adopted and helped to extend the life of the DOS platform well into the 1990s.DPMI was created by Microsoft in the late 1980s as part of their work on the Windows 3.0 operating system. It was developed to standardize the use of DOS extenders and allow applications using them to run under the protected mode environment of Windows 3.0.Popular DOS ExtendersSome popular DOS extenders include: DOS4GW - bundled with the Watcom C/C++ compiler, and used by many popular games such as Doom and Duke Nukem 3D. CauseWay - an open-source extender that was designed to be small and fast. CWSDPMI - a DPMI implementation for use with the DJGPP compiler. DOS/32A - an extender designed for use with the Borland C/C++ compiler. DOS/4G - a commercial extender used by many games and applications.DOS Game ModdingDOS Game CorruptionIf You are using a browser-based DOSBox emulator to run your games you can add this bookmarklet to your browser for it to automatically corrupt random memory addresses inside the DOS game:jsRTC/jsRTC_for_js-dosbox.txt at master · redscientistlabs/jsRTCReferencesAll Posts Planet X3 (2019 MS-DOS game) Introduction PlanetX3 is a brand new game developed by YouTube 8-bit guy for MS-DOS and released in early 2019. The game was developed using crowd funding through Kickstarter 1. The... ... Read More dos pc dos sourcecode games ", "excerpt": "Introduction Welcome to our page dedicated to DOS reverse engineering! PCs are some of the most versatile and widely-used computing platforms in the world, and there’s no shortage of interesting and challenging reverse engineering topics to explore. If you’re interested in learning more about the technical aspects of PCs and...", "tags": ["dos","pc"], "image": "/public/generated/placeholders/dos.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo DS (NDS) Reverse Engineering", "url": "/ds", "content": "Nintendo DS Reverse EngineeringWelcome to our page dedicated to DS reverse engineering! The Nintendo DS was a popular handheld gaming console that was released on November 21st 2004, and has since become a favorite of gamers around the world.If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to the right place. On this page, we’ve compiled a list of links to other pages that cover various topics related to DS reverse engineering.Whether you’re interested in understanding the hardware architecture of the console, analyzing game code, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to.So grab your DS, and get ready to dive into the exciting world of DS reverse engineering!Reverse EngineeringIntroduction to Nintendo DS ROM HackingJonko the ROM Hacker has an excellent introduction to ROM hacking NDS games where he hacks Suzumiya Haruhi no Chokuretsu 1:Tinke DS File ExplorerTinke is an open source application that can be used to open Nintendo DS games and the various file formats that are inside. You can view and edit textures, sound files, compressed archives and even a few game specific formats, it is well worth a look! Tinke - NDS File Viewer and Editor Check out the Tinke DS file viewer and editor Hardware ArchitectureCopetti.org has an excellent page on the hardware Architecture of the DS it is also a great introduction to the system: Game Boy Advance Architecture - A Practical Analysis Check out this excellent introduction to the DS hardware Development Kits (Hardware) Nintendo DS (Nitro) Development Kit Hardware For more information on the NDS Development Kit hardware check out this post. Software Development Kits (SDK)Official SDK Nintendo DS SDK (NITRO) For more information on the Official DS SDK check out this post. File Formats Nintendo DS File Formats For more information on the DS File formats check out this post. HomebrewWe have a separate post on Homebrew developed for the Nintendo DS which you can find here: Nintendo DS Homebrew For more information on DS Homebrew check out this post. ReferencesAll Posts Tagged with DS Nintendo DS (Nitro) Development Kit Hardware Official Development kits This section will cover the official development kit hardware sold by Nintendo and developed by Intelligent Systems. The Nintendo DS was initially codenamed IRIS during development and... ... Read More ds devkit hardware snsystems Nintendo DS File Formats The Nintendo DS (Codename NITRO) utilises a number of different file formats either created by Nintendo or a third party developer. If you are interested in reverse engineering a DS... ... Read More ds fileformats Nintendo DS Homebrew The Nintendo DS has had a very talented homebrew scene right from the very start thanks to the popularity of DS Flash carts such as the R4. This page will... ... Read More ds homebrew Nintendo DS SDK (NITRO) The NITRO SDK was previously known as the IRIS SDK, but got renamed sometime before April 2004 (release 1.0 of NITRO-SDK). Much of the structure and files remain from the... ... Read More ds sdk Nintendo DsiWare Leak As part of the Platinum Leak on the 9th of September 2020 a ton of DsiWare titles were leaked, including debug versions of games like Legend of Zelda Four Swords... ... Read More ds leak debug Matrices (Maths for Game Developers) Introduction to Matrices A matrix is a table of numbers, but in game code the important part is what that table does 1. Matrices let engines package translation, rotation, scale,... ... Read More maths psp ds Nintendo Ninja Leak The Ninja leak occurred on the 22nd December 2020 and is named after the contents containing information that prove the long-standing Nintendo “Ninja” myth. Including stalking and intimidation of a... ... Read More leak ds 3ds Nintendo Paladin Leak The Paladin leak occurred on the 30th of September 2020 and included about 2.4GB of content related to the Nintendo IRIS and Pokemon spinoffs. This was the third Nintendo leak... ... Read More leak ds 3ds gba Nintendo Platinum Leak The Platinum leak occurred on the 9th of September 2020 and included gigabytes of content, hence why some call it GigaLeak 3. {% include_cached link-to-other-post.html post=”/gigaleak” description=”For more information on... ... Read More ds leak sourcecode Quaternions (Maths for Game Developers) Introduction to Quaternions A quaternion is a four-number rotation representation, usually written as { x, y, z, w } or as a vector part plus a scalar part 1. In... ... Read More maths psp ds Serially Loopy: ROM Hacking from the Ground Up - YouTube ↩ ", "excerpt": "Nintendo DS Reverse Engineering Welcome to our page dedicated to DS reverse engineering! The Nintendo DS was a popular handheld gaming console that was released on November 21st 2004, and has since become a favorite of gamers around the world. If you’re interested in learning more about the technical aspects...", "tags": ["ds"], "image": "/public/generated/placeholders/ds.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo DS (Nitro) Development Kit Hardware", "url": "/nintendo-ds-development-kit", "content": "Official Development kitsThis section will cover the official development kit hardware sold by Nintendo and developed by Intelligent Systems.The Nintendo DS was initially codenamed IRIS during development and this later changed to NITRO which is why most of the development kits have the prefix IS-NITRO (IS is for Intelligent Systems).Prototype Development Kit The first ever Nintendo DS development kit simply consisted of two GBA screens connected with a custom SNES-like controller. The image on the left is the unit that Nintendo gave to Alpha Dream very early in the DS lifecycle so that they would work on Partners in Time. IS-NITRO-Emulator The Nintendo GameBoy has the IS-DMG-Emulator, the GameBoy Advance has the IS-AGB-Emulator and thus the DS/NITRO required its own IS-NITRO-EMULATOR. This piece of hardware has a GBA slot but does not allow playing of retail games. Some models support Video Out to allow gameplay to be shown on a much larger screen that the DS. The video on the left by Hard4Games shows off the hardware in great detail 1. You can view the video output in action in this tweet by Andrew Borman:Testing the IS-Nitro-Emulator with the unreleased Tetris DS that @CuttingRoomWiki released pic.twitter.com/yQMruabbiK— Andrew Borman (@Borman18) December 11, 2017For more information and a tear down visit: The NSMB Hacking Domain » Nintendo DS dev hardware! IS-NITRO-EMULATOR & co.IS-NITRO-DEBUGGER The IS-NITRO-DEBUGGER is just a standard IS-NITRO-EMULATOR with additional software for a few debugging features such as breakpoints and memory watchers for programmers to debug their code on the real hardware. IS-NITRO-EMULATOR Controller The controller for the IS-NITRO-EMULATOR is just a standard Nintendo DS with an un-pluggable cable in the back instead of the game card slot. This allows developers to use all the functionality of the DS such as the touch screen and still debug the code via their main PC. IS-NITRO-Capture The IS-NITRO-Capture is hardware that can play DS and GBA games on a monitor or PC via USB. You have multiple options such as using two monitors, one for each of the DS screens or just displaying both DS screens on the same monitor. this is controlled by the value of the DIP switches on the back of the unit. This is very useful for QA teams to avoid eye strain and for Game journalists to take screenshots of Nintendo DS games. When connected to a PC it can even capture video footage, perfect for showcasing games at conventions! Note that it did not support original GB and GBC games unlike the retail Nintendo DS 2. IS-NITRO-HUB The IS-NITRO-HUB is a piece of development hardware that was used to connect multiple development units (e.g IS-NITRO-EMULATOR) together using standard ethernet cables. This was very useful for testing multi-player games or software that communicated with other devices such as Pictochat. IS-NITRO-VIDEO The IS-NITRO-VIDEO is a piece of development hardware that was used to output video from a prototype DS game to multiple monitors, this was used for demos and events where Nintendo would showcase their games. The connected DS was used as a controller, this allowed the players to use the touch screen and other event attendees would see the result on large monitors on the show floor. IS-NITRO-UIC (MIDI) The IS-NITRO-UIC is a piece of development hardware that was used to test MIDI sound on the Nintendo DS, the Image to the left shows the MIDI version which has 2 ports one for USB and the other a MIDI port. It slots in the GBA port at the bottom of the Nintendo DS, and also requires a DS Rewritable development Cartridge with the NITRO-PLAYER software installed on it. There is another version without the MIDI interface which relies on sending all the data via USB but this would be slower as you would need the MIDI files instead of just using a MIDI instrument to hear the sounds instantly. The hardware would be connected to a developer’s PC via USB, and using the provided software the sound engineer could send MIDI files that would play back on the device’s speakers. Here is a view from the side showing the USB and the MIDI ports: The MIDI version of this hardware could also be connected to any MIDI instrument directly via the MIDI interface which can be seen in the diagram below. Also here is an image from Behind The Code with Gerry as to what it looks like when a DS is running the software and waiting for messages: Thank you to @DarkainMX for tracking down both the information and photo of this rare piece of hardware! IS-NITRO-Writer The IS-NITRO-Writer is used to flash a ROM image to multiple flash cartridges at once! intelligent Systems developed one of these units for most Nintendo consoles including the Nintendo 64 and Game Boy. One of the slots holds the master game card that will be copied to all the 7 other rewritable flash game cards. Alternatively it can connect to the PC via USB and take a ROM from the PC and flash to 8 cards at once (the Master slot is used to flash an extra one). It has a bunch of DIP switches for configuration, a USB type-B port and uses the same power supply as a Nintendo Gamecube! Ahhh, now there's a devkit for a platform I knew inside and out... Great memories developing the first few LEGO games on this. Next to it the eight slot gang burner for programming test cartridges. pic.twitter.com/PzgzULWWA7— Paul Hughes (@PaulieHughes) December 7, 2020There was Nintendo Dev kits for sale on ebay. This is a "Nitro" writer (the codename for the DS). Notice it takes a Gamecube power port. pic.twitter.com/MUIzuCGIMT— Kuromi Bunny in Boston (@KuromiBunnyGirl) March 5, 2017For more information about the Writer and a teardown: The NSMB Hacking Domain » Nintendo DS dev hardware! IS-NITRO-EMULATOR & co.DS Rewritable development Card Similar to most console development kits, there are official development flash card for the DS. These are similar to the standard game card but are re-writeable and thus can be used for any game. Many of these have the japanese text written on them: DSフラッシュカードSP512M. Which translates to DS Flash Card SP512M, 512M being the size in Megabytes. They also have Part numbers of the form: (E202650) E4, the E4 at the end may indicate a revision or version code. Then the label mentions the Slide‑switch settings, which can be in one of two positions On (A) and Off (B). Which I originally believed allows two pieces of software to be installed on the same card and switched between easily without having to constantly rewrite the card. However the documentation appears to contradict this by saying it is setup during programming and debugging and it should be kept to the ON value. The rest of the text is standard warnings, so the translation would be: * Do not use with the cover open.* If you touch the circuit board directly with your hands, be careful of static electricity.* To avoid damage, switch the slide‑switch using tweezers or similar tools. So how does the Rom get written to the cartridge? The answer is above you, well above you on this page, the IS-NITRO-EMULATOR and the IS-NITRO-WRITER can both write to these game cards. Although only specific versions of these supported specific cards as is mentioned in the brief documentation paper that comes with the cards: About the switchSwitches the CARD-ID value. It can be confirmed during programming or debugging. Normally, please keep it set to ON.About capacity settingsWhen operating, the DS Flash Card emulates the device capacity based on the recorded data. Always select the “device capacity” according to the registered data in the ROM.About IS-NITRO-WRITERUse version 1.12 or later of IS-NITRO-WRITER.For [flash memory], select [automatic] for [type].About IS-NITRO-DEBUGGERUse version 1.59 or later of IS-NITRO-DEBUGGER. Known part numbers: E202809 - 512M E202668 - 1G There was also these ones which were very long:Reminder: These Nintendo DS development cartridges really existed. pic.twitter.com/Tp8A0tGvL6— Forest of Illusion (@forestillusion) December 12, 2020NTR-SUB02-1 - DS Sub Cards (Save Game Cards) But what about saved game data? Not all retail cartridges have the same amount of Save RAM on them and so the development cartridges should have a configurable amount of Save RAM right? This was achieved using Sub Cards which you can get access to and swap out very easily by opening the top half of the main card. This allows game developers to test their games with the exact right amount of Save RAM and the specific type of Save RAM (EEPROM or FLASH) 3. Here is an photo of the board of a Sub Card, note the part ID which was NTR-SUB02-1 4: And the connection on the main cartridge 4: Both Images are thanks to Dirbaio’s post on the The NSMB Hacking Domain here Nintendo DS dev hardware! IS-NITRO-EMULATOR & co. The Sub Cards have part numbers in brackets but I am not sure if it is the actual part number of the subcard or if its the main card its compatible with, as I have seen a cartridge with ID E202809 which is the same as the main card.Known part numbers: E202387 - DS Sub Card 4K EEPROM E202650 - DS Sub Card 64K EEPROM1 E202809 - DS Sub Card 64K EEPROM1 (Note: This may be wrong as it is the same as the main card) Note some are EEPROM and others are EEPROM1, not sure what the difference was, but the EEPROM1 also have E4 in the bottom right hand corner. IS-TWL-DEBUGGER The IS-TWL-DEBUGGER development kit is a newer version of the IS-NITRO-DEBUGGER but with added support for the features of the DSI which was codenamed Twilight (TWL) during development. On the front it has slots for both an SD card and a standard DS cartridge. It has 32MB of main memory, twice that of the retail Nintendo DSi, this allows developers to use that memory for debugging overlays etc. For wireless communication it includes its own antenna! Similar to the IS-NITRO-Emulator it uses the gamecube power supply and has a USB port for interfacing with the developers PC. IS-TWL-DEBUGGER Controller Keeping the tradition with its DS predecessor the controller is a modified retail Unit, but instead of the cartridge port it had wires connecting it to the main unit itself 5. IS-TWL-CAPTURE Again Keeping the tradition with its DS predecessor the IS-TWL-CAPTURE is the equivalent of the IS-NITRO-CAPTURE but with the added ability to support DSi functions. IS-TWL-VSAThe IS-TWL-VSA is a Visual Studio 2005 Add On meant to aid in DSi development, it was distributed in Japanese and English, however, only the Japanese version is known to still exist. it was briefly mentioned in a 2015 recruitment document and described as a “Integrated Development environment add in” 6. The IS-TWL-VSA was meant as a way for developers to move away from CodeWarrior and over to Visual Studio. It is capable of starting Nitro, Twilight, and Hybrid projects.IS-TWL-MIDINoone has taken any photos of the IS-TWL-VSA but it was briefly mentioned in a 2015 Intelligent Systems recruitment document and described as a “Sound Development System” 6. It is presumably just a more up-to-date version of the IS-NITRO-UIC.TWL-DEV-EUR (PANDA) Nintendo DSi Development Unit The DSi development unit was similar to its retail counterpart but had the ability to read development cartridges and install *.TAD files. TAD files are the equivalent of Wii’s WAD file format but for Twilight (DSi). Today's arrival : a boxer Nintendo DSI panda (dev console) with a development box ! (Where usually all box actually know for those panda was just no name white box).And I also got two cards, including one of the four Nintendo factory devcart that was recently found. pic.twitter.com/w4O188jCx8— Michel Gaschet (@Michel_Gaschet) October 13, 2020Third party Development KitsIn addition to the official development kits put out by Nintendo, there was a third party development kit from SN-Systems.Sn Systems Pro-DG for Nintendo DS (DSDEV)SN Systems have a long history of creating 3rd party development kits for Nintendo consoles and the Nintendo DS was no exception, or was it?!You see before the console was released SN Systems announced a collaboration with Hudson soft to add Nintendo DS support to their ProDG line of development kits 7.However it is unclear if it actually materialised or if any game developers used it to create a retail game, as all mention of it was scrubbed from their official website after 2005.Consumer Development KitsA consumer development kit for the DS? Of course Nintendo would never allow Homebrew on their console officially but there was an attempt by Datel to allow users to write Apps for the DS using a special cartridge.Datel Games n MusicDatel are a very talented company when to comes to by-passing security and doing things people didn’t think possible. One project they sold in stores was called Games n’ Music and allowed users to create their own mini Apps.Datel once released a multimedia cartridge for DS which allowed playing music, images, and user made apps. It was essentially a flash cart without a ROM loader. These were actually on store shelves in America?? It's how I got into piracy and homebrew on my DS at age like, 11... pic.twitter.com/a7kDkDo7LW— Kaitlyn Molinas (@orcastraw) October 18, 2020 Game Boy Advance (AGB) Development Kit Hardware Since you have got this far you might be interested in Nintendo’s previous generation of handheld development hardware, if so check out this post. References Nintendo DS Development Unit! - IS Nitro Emulator - H4G - YouTube ↩ Nintendo DS on your television, the IS-Nitro-Capture a developers tool - YouTube ↩ The NSMB Hacking Domain » Nintendo DS dev hardware! IS-NITRO-EMULATOR & co. ↩ The NSMB Hacking Domain » Nintendo DS dev hardware! IS-NITRO-EMULATOR & co. ↩ ↩2 Nintendo DS IS TWL Debugger from Retrogames ↩ Intelligent Systems Recruitment 2015 ↩ ↩2 Gamasutra - SN Systems and Hudson Announce DS Tools Project ↩ ", "excerpt": "Official Development kits This section will cover the official development kit hardware sold by Nintendo and developed by Intelligent Systems. The Nintendo DS was initially codenamed IRIS during development and this later changed to NITRO which is why most of the development kits have the prefix IS-NITRO (IS is for...", "tags": ["ds","devkit","hardware","snsystems"], "image": "/public/images/ds/Nintendo DS Development Kit Hardware.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo DS File Formats", "url": "/DSFileFormats", "content": "The Nintendo DS (Codename NITRO) utilises a number of different file formats either created by Nintendo or a third party developer. If you are interested in reverse engineering a DS game then you will most likely come across these formats, so it is a good idea to have at least some knowledge of how they work.The main file formats used in Nintendo DS games are outlined in the table below, with further detail in the sections of this post. Extension Description .tad Installable application for Nintendo Dsi (similar to the WAD format on Wii) .nds Dump of a Nintendo DS Game Card (unofficial) .srl Official Dump of a Nintendo DS Game Card TAD (similar to a Wii WAD)TAD files are installable applications for the Nintendo DSi, similar in function to the WAD file for the Wii console.Creation of TAD filesDevelopers would create these files by converting an SRL ROM to TAD format with a tool called maketad.It is not common to see TAD files out in the wild as they tend to be used by developers. However in the Platinum leak there was a huge archive of DSi applications in TAD format. Some of these are even debug versions so may contain full debug symbols useful for reverse engineering.Usage of TAD filesDevelopers would use an application called TwlNmenu to install TAD files on their DSi hardware.However there doesn’t seem to be a tool capable of installing TAD files on a modified DSi as of September 2020. However you can use the details in the next section to extract a DS ROM file (SRL) from the TAD file.Extracting TAD file contentUsing the split_tad_console script (from twToolsRed) one can extract the Nintendo DSi ROM (SRL) file from a TAD file 1. This has been tested with The Legend of Zelda 4 Swords Tad file available in the Platinum Leak.There is also an alternative python script from a user on 4chan: #This is for Python 2from Crypto.Cipher import AES #pycrypto. If on windows, h - Pastebin.comOne can then use the steps in the SRL section below to mount the SRL to a directory and view its contents.From the sounds of it on a 3DS you can use GodMode9 to convert the SRL to a CIA, or on preview, install the SRL directly.NO$GBA should be able to launch it too once it’s in SRL format 1.Re-signing a TAD fileInterestingly it is possible to resign a TAD file using the Wii resigning tools, but it won’t be able to be installed on a modified DSi due to anti-tampering methods 2.TwlNmenu on 3DS?!Do not run TwlNmenu on 3DS unless you have backed up your TWLN partition and you find a way to get valid certificates. In theory if you got valid certificates you would be able to install the TAD files but noone has yet managed to do it.You can see a video of running TwlNmenu on a 3DS below:SRL FormatSRL is the extension Nintendo uses for Nintendo DS ROMS and is the same as the NDS format. You can rename .srl files to .nds and they should play in an emulator 3.Also it seems that on the Wii U Nintendo used the .srl file extension for their Nintendo DS emulated ROMs.Extracting SRL contentTo extract the content of a SRL ROM file you can use the ninfs tool to mount the SRL to a directory and then view its contents, like so 1:mount_srl swords.srl ~/mnt_srlTMD Format (Title metadata)A TMD file is simply just a meta data file that stores information about an App such as the contents and SHA1 hashes for verification. The format is also used for 3DS and Wii titles.For more information check out the DSiBrew page:Title metadata - DSiBrewNLF Format (NitroROM List File)The .NLF file is interesting as it is a NitroROM List File as it seems to list the contents of the DS SRL file. It is believed these are generated by a tool in the SDK and are used by developers to make it easier to see the contents of what is in the ROM.References TAD Format - Extra details · Issue #38 · RetroReversing/retroReversing ↩ ↩2 ↩3 TwlNmenu - RGDWiki ↩ How do you convert Nintendo DS .SRL into decrypted .NDS? ↩ ", "excerpt": "The Nintendo DS (Codename NITRO) utilises a number of different file formats either created by Nintendo or a third party developer. If you are interested in reverse engineering a DS game then you will most likely come across these formats, so it is a good idea to have at least...", "tags": ["ds","fileformats"], "image": "/public/generated/placeholders/dsfileformats.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo DS Homebrew", "url": "/nintendo-ds-homebrew", "content": "The Nintendo DS has had a very talented homebrew scene right from the very start thanks to the popularity of DS Flash carts such as the R4. This page will list just a few of the amazing homebrew apps developed by the scene.Full list of all homebrewIf you are interested in browsing a full list of all DS homebrew developed then you should visit the GameBrew wiki page for this: List of DS homebrew applications - GameBrew - a wiki dedicated to Video Game Homebrew.Original HomebrewDS-DSLR: Homebrew Nintendo DS remote for Canon DSLR Steve Chapman from Panocamera.com has built a very impressive homebrew application and hardware interface to connect his DSLR camera to his Nintendo DS 1. The story goes that he grew tired of lugging around his heavycumbersome energy-hungry laptop whenusing his DSLR camera and wanted to find a lighter solution 2. It uses the Game Boy Advance cartridge slot to connect to the camera so has presumably created his own circuit board to convert the two data interfaces. He has even managed to add voice recognition support to take a photo when he says a word, saving hundreds of dollars on buying a retail solution for the task 2. Moonshell Multimedia PlayerThe Moonshell multimedia player allows you to play Movies right from your DS! This was pretty huge in 2007 when having a portable way to watch videos was much less common 2.DSTwitter - Twitter client DSTwitter was a very simple twitter client for the Nintendo DS, it worked very well to read and even reply to tweets. Unfortunately as it only ever has support for basic Twitter authentication and no OAuth support, it no longer works as twitter removed basic auth in 2009 3. Original GamesStill Alive DSStill Alive DS is a nice puzzle platformer that borrows concepts from Portal.LoneWolfDSLoneWolfDS is a very unique homebrew game in that it takes one of the physical adventure gamebooks written by Joe Denver and converts it into an interactive story with RPG like elements 4.EmulatorsThe DS has fairly limited hardware so full speed emulation of SNES and Mega Drive games are pushing the machine to its very limits. However there are a few excellent emulations for the DS, especially for more limited systems such as the original Game Boy/GBC and the Sega Master System.You can view a full list of emulations available for DS over on GameBrew: List of DS homebrew emulators - GameBrew - a wiki dedicated to Video Game Homebrew.Wiimmfi - DS WiFi server emulationThe Nintendo DS WiFi Connection or WFC was a way to play Nintendo DS games online, however Nintendo shut down their servers in 2014.Thankfully some smart developers have spent their time creating an open source replacement for the game servers, managing to bring back most of the functionality including leaderboards and matchmaking [^].References DS-DSLR: Homebrew Nintendo DS remote for Canon DSLR – Boing Boing Gadgets ↩ Nintendo DS Piracy & Hacking - Did You Know Gaming? Feat. Remix - YouTube ↩ ↩2 ↩3 DS Twitter - GameBrew - a wiki dedicated to Video Game Homebrew. ↩ LoneWolfDS - GameBrew - a wiki dedicated to Video Game Homebrew. ↩ ", "excerpt": "The Nintendo DS has had a very talented homebrew scene right from the very start thanks to the popularity of DS Flash carts such as the R4. This page will list just a few of the amazing homebrew apps developed by the scene. Full list of all homebrew If you...", "tags": ["ds","homebrew"], "image": "https://i.ytimg.com/vi/UPNffwjMdLQ/sddefault.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo DS SDK (NITRO)", "url": "/DS-NITRO-SDK", "content": "The NITRO SDK was previously known as the IRIS SDK, but got renamed sometime before April 2004 (release 1.0 of NITRO-SDK). Much of the structure and files remain from the IRIS SDK but most files have been renamed to NITRO.Even although the SDK was renamed to NITRO in version 1.0 it still distributed the release notes for the three IRIS SDK versions that started the project. Although in the 4.2 SDK leak these were removed ands the release notes just start from 1.0.When the Nintendo DSi was released the SDK was once again renamed to the twilight (TWL) SDK.Leaked Versions of the SDKKnown Leaked versions: NITRO-SDK 3.0 (Unknown Leak) NITRO-SDK 4.2+ Patch (Pokemon Platinum Source code Leak) TWL-SDK 5.5 (Unknown Leak) - This is the DSi version of the SDKKnown VersionsThese are the versions that have been known to exist and their release dates: SDK Version Name Release Date irisSDK-snapshot-031203 3rd December 2003 irisSDK-snapshot-031212 12th December 2003 irisSDK-snapshot-040120 20th January 2004 NITRO-SDK 1.0 5th April 2004 NITRO-SDK 1.2 16th June 2004 NITRO-SDK 2.0 11th March 2005 (First in english) NITRO-SDK 2.1 9th May 2005 NITRO-SDK 2.2 22nd August 2005 NITRO-SDK 3.0 25th January 2006 NITRO-SDK 3.1 2nd May 2006 NITRO-SDK 3.2 28th August 2006 NITRO-SDK 4.0 15th February 2007 NITRO-SDK 4.1 10th July 2007 NITRO-SDK 4.2 10th December 2007 NITRO-SDK 4.2 + Patch 18th January 2008 TWL-SDK 5.0 23rd October 2008 TWL-SDK 5.1 27th February 2009 TWL-SDK 5.2 10th June 2009 TWL-SDK 5.3 7th August 2009 TWL-SDK 5.4 20th November 2009 TWL-SDK 5.5 12th July 2010 All three IRIS SDK version were leaked as part of the Paladin Leak on the 30th September 2020.Note that there was also something called the “TWLwrap SDK” for DSi that was leaked but it is very different to these so it presumably wasn’t a consumer SDK.Root Files (/) Makefile Readme-NitroSDK-3_0-060125.txt SrcTreeMap.txt bin build cache components data docs - Documentation include - C/C++ Header files for SDK libraries lib - Static libraries for the SDK man - Manual for Functions tools - SDK Tools such as elftobin and makeromManual (/man)Contents: a-z.html alphabet.html alphabet_index.html card categories.html changelog-oldver.html changelog.html changelog2.2branch.html cht contents.html cp css ctrdg demos env ext fs functions.html fx gx icons.html index.html information main.html math mb mi os pad prc romfiles rtc sdk_logo.gif snd spi std svc tools wbt wm wm_changes_041006.txt wvrTools (/tools)Contents: bin elftobin lib makeromPre-compiled Header Cache (/cache)The Cache folder only contains one file: ./cache/include/Don’tDeleteMe.txtBin (/bin)Contents: ./bin/ARM9-TS/Release/mb_child_simple.srl ./bin/ARM9-TS/Rom/mb_child.srl ./bin/ARM9-TS/Rom/WMTestTool.srl ./bin/ARM9-TS/Rom/mb_child_simple.srlC/C++ Header files (/include)the table below lists all the C++ header files available to use when developing Nintendo DS games. Name Description nitro_win32.h   nitro_sp.h   nitro_wl   nitro_wl/common   nitro_wl/common/version_wl.h   nitro.h   nitro   nitro/gx.h   nitro/init   nitro/init/crt0.h   nitro/env.h   nitro/wvr   nitro/wvr/common   nitro/wvr/common/wvr_common.h   nitro/wvr/ARM9   nitro/wvr/ARM9/wvr.h   nitro/cht   nitro/cht/ARM9   nitro/cht/ARM9/pictocatch.h   nitro/version.h   nitro/parent_begin.h   nitro/mi.h   nitro/dtcm_begin.h   nitro/card   nitro/card/eeprom.h   nitro/card/rom.h   nitro/card/backup.h   nitro/card/pullOut.h   nitro/card/common.h   nitro/card/fram.h   nitro/card/flash.h   nitro/snd.h   nitro/wvr.h   nitro/exi.h   nitro/hw   nitro/hw/common   nitro/hw/common/mmap_shared.h   nitro/hw/common/lcd.h   nitro/hw/common/armArch.h   ARM7 HeadersThe table below lists the relevant entries. Name Description nitro/hw/ARM7/ioreg_PAD.h   nitro/hw/ARM7/mmap_global.h   nitro/hw/ARM7/ioreg_OS.h   nitro/hw/ARM7/ioreg.h   nitro/hw/ARM7/mmap_wram.h   nitro/hw/ARM7/mmap_main.h   nitro/hw/ARM7/ioreg_MI.h   nitro/hw/ARM7/ioreg_PXI.h   nitro/hw/ARM7/ioreg_SND.h   nitro/hw/ARM7/ioreg_EXI.h   nitro/hw/ARM7/ioreg_GX.h   nitro/hw/ARM7/ioreg_SPI.h   ARM9 HeadersThe table below lists the relevant entries. Name Description nitro/hw/ARM9/ioreg_PAD.h   nitro/hw/ARM9/ioreg_G3X.h   nitro/hw/ARM9/mmap_global.h   nitro/hw/ARM9/ioreg_G3.h   nitro/hw/ARM9/ioreg_OS.h   nitro/hw/ARM9/ioreg.h   nitro/hw/ARM9/mmap_main.h   nitro/hw/ARM9/ioreg_MI.h   nitro/hw/ARM9/ioreg_PXI.h   nitro/hw/ARM9/mmap_vram.h   nitro/hw/ARM9/ioreg_EXI.h   nitro/hw/ARM9/ioreg_GX.h   nitro/hw/ARM9/ioreg_GXS.h   nitro/hw/ARM9/mmap_tcm.h   nitro/hw/ARM9/ioreg_CP.h   nitro/hw/ARM9/ioreg_G2.h   nitro/hw/ARM9/ioreg_G2S.h   Memory Interface (MI)The memory interface includes were used to produce functions for accessing specific areas of the hardwares memory and were located in the nitro/mi folder. Name Description nitro/mi/wram.h   nitro/mi/dma.h   nitro/mi/card.h   nitro/mi/uncomp_stream.h   nitro/mi/byteAccess.h   nitro/mi/swap.h   nitro/mi/stream.h   nitro/mi/compress.h   nitro/mi/memory.h   nitro/mi/uncompress.h   nitro/mi/init.h   nitro/mi/exMemory.h   Misc HeadersThe table below lists the relevant entries.Name | Description—|—nitro/itcm_begin.h |nitro/pxi.h |nitro/wbt.h |nitro/pxi |nitro/pxi/common |nitro/pxi/common/fifo.h |nitro/pxi/common/regname.h |nitro/pxi/common/compparam.h |nitro/pxi/common/init.h |nitro/card.h |nitro/itcm_end.h |nitro/code32.h |nitro/types.h |nitro/misc.h |nitro/ioreg.h |nitro/specfiles |nitro/specfiles/ARM7-TEG.lcf |nitro/specfiles/ROM-TS.rsf |nitro/specfiles/ARM9-TS-cloneboot-C.lcf.template |nitro/specfiles/ARM9-TS.lsf |nitro/specfiles/ARM9-TEG.lsf |nitro/specfiles/ARM9-TEG-C.lcf.template |nitro/specfiles/ARM7-TS.lsf |nitro/specfiles/ARM9-TEG.lcf |nitro/specfiles/ARM9-TEG.lcf.template |nitro/specfiles/ARM9-TS.lcf |nitro/specfiles/ARM7-TS.lcf.template |nitro/specfiles/ARM7-TS.lcf |nitro/specfiles/ARM9-TS-C.lcf.template |nitro/specfiles/ndsld.response.template |nitro/specfiles/default.bnr |nitro/specfiles/mwldarm.response.template |nitro/specfiles/ARM7-TEG.lsf |nitro/specfiles/ARM9-TS.lcf.template |nitro/specfiles/2.x |nitro/specfiles/2.x/ARM9-TS-cloneboot-C.lcf.template |nitro/specfiles/2.x/ARM9-TEG-C.lcf.template |nitro/specfiles/2.x/ARM9-TEG.lcf.template |nitro/specfiles/2.x/ARM9-TS-C.lcf.template |nitro/specfiles/2.x/ARM9-TS.lcf.template |nitro/specfiles/ARM7-TEG.lcf.template |nitro/specfiles/ROM-TEG.rsf |nitro/dtcm_end.h |nitro/fx |nitro/fx/fx.h |nitro/fx/fx_mtx33.h |nitro/fx/fx_trig.h |nitro/fx/fx_mtx22.h |nitro/fx/fx_mtx43.h |nitro/fx/fx_cp.h |nitro/fx/fx_mtx44.h |nitro/fx/fx_mtx.h |nitro/fx/fx_const.h |nitro/fx/fx_vec.h |nitro/exi |nitro/exi/ARM7 |nitro/exi/ARM7/genPort.h |nitro/os.h |nitro/utest.h |nitro/parent_end.h |nitro/ext |nitro/ext/ext_scrntest.h |nitro/ext/ext_keycontrol.h |nitro/pad.h |nitro/cht.h |nitro/codereset.h |nitro/wm |nitro/wm/common |nitro/wm/common/wm.h |nitro/wm/ARM9 |nitro/wm/ARM9/wm_api.h |nitro/memorymap_sp.h |nitro/std |nitro/std/string.h |nitro/section.h |nitro/prc.h |nitro/version_end.h |nitro/ctrdg.h |nitro/math |nitro/math/fft.h |nitro/math/dgt.h |nitro/math/crc.h |nitro/math/rand.h |nitro/math/math.h |nitro/math/qsort.h |nitro/math/checksum.h |nitro/pad |nitro/pad/common |nitro/pad/common/pad.h |nitro/pad/ARM7 |nitro/pad/ARM7/xyButton.h |nitro/env |nitro/env/env_system.hnitro/spec.hnitro/version_begin.hnitro/componentsnitro/spinitro/spi/commonnitro/spi/common/type.hnitro/spi/common/userInfo_teg.hnitro/spi/common/config.hnitro/spi/common/pm_common.hnitro/spi/common/userInfo_ts_300.hnitro/spi/common/userInfo_ts_0.hnitro/spi/common/userInfo_ts_200.hnitro/spi/ARM7nitro/spi/ARM7/pm.hnitro/spi/ARM7/spi.hnitro/spi/ARM9nitro/spi/ARM9/pm.hnitro/spi/ARM9/mic.hnitro/spi/ARM9/tp.hnitro/memorymap.hnitro/wram_end.hnitro/cp.hnitro/mbnitro/mb/mb_child.hnitro/mb/mb_gameinfo.hnitro/mb/mb.hnitro/mb/mb_fake_child.hnitro/wram_begin.hnitro/rtcnitro/rtc/commonnitro/rtc/common/type.hnitro/rtc/common/fifo.hnitro/rtc/ARM9nitro/rtc/ARM9/api.hnitro/rtc/ARM9/convert.hnitro/rtc.hnitro/spi.hnitro/gxnitro/gx/gx.hnitro/gx/struct_2d.hnitro/gx/g3c.hnitro/gx/g3x.hnitro/gx/g3.hnitro/gx/gx_sp.hnitro/gx/g2_oam.hnitro/gx/gxcommon.hnitro/gx/gx_vramcnt.hnitro/gx/g2.hnitro/gx/gx_load.hnitro/gx/g3imm.hnitro/gx/g3_util.hnitro/gx/gx_capture.hnitro/gx/g3b.hnitro/gx/gx_bgcnt.hnitro/prcnitro/prc/resample.hnitro/prc/types.hnitro/prc/algo_superfine.hnitro/prc/algo_common.hnitro/prc/common.hnitro/prc/algo_standard.hnitro/prc/algo_light.hnitro/prc/algo_fine.hnitro/math.hnitro/sndnitro/snd/commonnitro/snd/common/main.hnitro/snd/common/capture.hnitro/snd/common/channel.hnitro/snd/common/seq.hnitro/snd/common/alarm.hnitro/snd/common/midiplayer.hnitro/snd/common/work.hnitro/snd/common/data.hnitro/snd/common/global.hnitro/snd/common/mml.hnitro/snd/common/exchannel.hnitro/snd/common/util.hnitro/snd/common/command.hnitro/snd/common/bank.hnitro/snd/ARM9nitro/snd/ARM9/interface.hnitro/osnitro/os/commonnitro/os/common/callTrace.hnitro/os/common/spinLock.hnitro/os/common/profile.hnitro/os/common/alarm.hnitro/os/common/tick.hnitro/os/common/valarm.hnitro/os/common/context.hnitro/os/common/message.hnitro/os/common/ownerInfo.hnitro/os/common/entropy.hnitro/os/common/emulator.hnitro/os/common/systemCall.hnitro/os/common/timer.hnitro/os/common/thread.hnitro/os/common/printf.hnitro/os/common/interrupt.hnitro/os/common/system.hnitro/os/common/mutex.hnitro/os/common/init.hnitro/os/common/exception.hnitro/os/common/arena.hnitro/os/common/reset.hnitro/os/common/alloc.hnitro/os/common/functionCost.hnitro/os/ARM9nitro/os/ARM9/argument.hnitro/os/ARM9/protectionUnit.hnitro/os/ARM9/vramExclusive.hnitro/os/ARM9/cache.hnitro/os/ARM9/protectionRegion.hnitro/os/ARM9/china.hnitro/os/ARM9/tcm.hnitro/dgtnitro/dgt/dgt.hnitro/dgt/common.hnitro/cpnitro/cp/sqrt.hnitro/cp/context.hnitro/cp/divider.hnitro/os_sp.hnitro/ext.hnitro/snd_sp.hnitro/fsnitro/fs/archive.hnitro/fs/file.hnitro/fs/overlay.hnitro/mb.hnitro/wm.hnitro/ctrdgnitro/ctrdg/commonnitro/ctrdg/common/ctrdg_common.hnitro/sinit.hnitro/fs.hnitro/code16.hnitro/std.hDocumentation (/docs)Contents: README SDKHowTo SDKRules SDKTools TechnicalNotesSDK How Tos (/docs/SDKHowTo) SDKHowTo/HowToMakeMyVRamBankType.txt SDKHowTo/HowToBuildSDKTree.pdf SDKHowTo/HowToJoinAGBDevEnv.txtSDK Rules (/docs/SDKRules) SDKRules/Rule-Defines.html SDKRules/NitroSDKStandard.css SDKRules/Rule-NameSpace.htmlREADMEs (/docs/README) README/ReleaseNotes-3.0.pdf README/history/ReleaseNotes-2.2.pdf README/history/ReleaseNotes-2.0.pdf README/history/ReleaseNotes-2.1.pdf README/history/ReleaseNotes-031212.pdf README/history/ReleaseNotes-1.2.pdf README/history/ReleaseNotes-031203.pdf README/history/ReleaseNotes-1.0.pdf README/history/ReleaseNotes-040120.pdf README/QuickStartForSDK.pdfTechnical Notes (/docs/TechnicalNotes) TechnicalNotes/AboutWirelessManager.pdf TechnicalNotes/AboutSound.pdf TechnicalNotes/AboutPatternRecognition.pdf TechnicalNotes/NitroRomFormat.pdf TechnicalNotes/AboutFileSystem.pdf TechnicalNotes/WmTutorial.pdf TechnicalNotes/AboutMultiBoot.pdf TechnicalNotes/AboutThreadInfo.pdf TechnicalNotes/AboutComponents.pdf TechnicalNotes/MechanismOfProfiler.pdf SDKTools SDKTools/CygwinPackageList.pdfComponents (/components)Contents: ichneumon mongoose racoon (DSi) ferret (DSi)Static Libraries (/lib)the table below lists all the Static Libraries that a Nintendo DS game can link to to provide useful functionality. There are normally two versions of a static Library, one compiled with the standard toolchain and another compiled for Thumb. Name Thumb Description libsyscall.a N/A   crt0.o N/A   libcard.a libcard.thumb.a   libcht.a libcht.thumb.a   libcp.a libcp.thumb.a   libctrdg.a libctrdg.thumb.a   libdgt.a libdgt.thumb.a   libe3s.a libe3s.thumb.a   libenv.a libenv.thumb.a   libext.a libext.thumb.a   libfs.a libfs.thumb.a   libfx.a libfx.thumb.a   libgx.a libgx.thumb.a   libmath.a libmath.thumb.a   libmb.a libmb.thumb.a   libmi.a libmi.thumb.a   libos.CALLTRACE.a libos.CALLTRACE.thumb.a   libos.FUNCTIONCOST.a ibos.FUNCTIONCOST.thumb.a   libos.a libos.thumb.a   libos_TS0.a libos_TS0.thumb.a   libos_TS100.a libos_TS100.thumb.a   libos_TS200.a libos_TS200.thumb.a   libprc.a libprc.thumb.a   libpxi.a libpxi.thumb.a   librtc.a librtc.thumb.a   libsnd.a libsnd.thumb.a   libspi.a libspi.thumb.a   libspi_TS0.a libspi_TS0.thumb.a   libspi_TS100.a libspi_TS100.thumb.a   libspi_TS200.a libspi_TS200.thumb.a   libstd.a libstd.thumb.a   libstubscw.a libstubscw.thumb.a   libstubsisd.a libstubsisd.thumb.a   libutest.a libutest.thumb.a   libwbt.a libwbt.thumb.a   libwfs.a libwfs.thumb.a   libwm.a libwm.thumb.a   libwvr.a libwvr.thumb.a   Source Code (/build)Contents: Makefile buildsetup buildtools demos libraries toolsData (/data)Contents: cht_data for_china wl_icons", "excerpt": "The NITRO SDK was previously known as the IRIS SDK, but got renamed sometime before April 2004 (release 1.0 of NITRO-SDK). Much of the structure and files remain from the IRIS SDK but most files have been renamed to NITRO. Even although the SDK was renamed to NITRO in version...", "tags": ["ds","sdk"], "image": "/public/generated/placeholders/ds-nitro-sdk.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Datel Action Replay Professional (N64)", "url": "/datel-action-replay-professional", "content": "Datel Action Replay ProfessionalV-Ram functionalityYou could press a “Freeze button” on the Action Replay to “see images not normally visible during playing of the game”. The video seems to be showing different render frames from the game Top Gear Overdrive.Not sure why this would be useful apart from taking screenshots for magazines or just to see inside the renderer.Code GeneratorAction Replay has a Code Generator which is very similar to other tools in the cheat cartridge/engine world. For example if you have ever used the tool Cheat Engine on PC and used the search/sub-search feature you will be right at home.If not you might want to read up on how Cheat Engine works and the basics of Memory and hexadecimal notation.Action Replay Code FormatAn action replay code is made up of 2 parts, the address and the value. In the screenshot above you can see that the address is highlighted in yellow.The address is just the Hexadecimal representation of the memory position of the lives variable.The value on the right is the value we want to put into the lives variable, in this case 2.Tutorial - Finding a cheat in Duke Nukem 64First press the freeze button on the AR device to access the in-game menu. And go to Code Generator.Known Value SearchSince we know the value of Duke Nukem’s bullets we enter the “Known Value Search” option. This will allow us to search for the value of bullets (48) in memory.Now go Back to the game and fire a bullet, your bullets should now equal 47 since you just fired one bullet. Now press Freeze and you will be back in the Known Value Search screen, enter 47 as the new value.Initially there was 10555 possibilities for the memory address, but now after the second search it is down to just 2!Now select “View Search Results” and the 2 codes we have found are displayed on the left.Now select one to make it active by pressing the ‘A’ button and go back to the game. The game should now have unlimited bullets! :)Tutorial - Mortal Kombat TrilogyUnknown Value SearchA health bar is the perfect example of an Unknown value since it doesn’t display the exact number of health you have just a big green bar.Choose ‘Start’ to start the Action Replay search system, now return to the game and loose some health.Now press the Freeze button on the AR and select “Less than Last” since we reduced health.Now just repeat the process until you get around 20 options and test out each one until you find one that doesn’t allow the player to lose any health.Full VideoLink to the video on YouTube is here: https://www.youtube.com/watch?v=Gq8VQBKBKqI", "excerpt": "Datel Action Replay Professional V-Ram functionality You could press a “Freeze button” on the Action Replay to “see images not normally visible during playing of the game”. The video seems to be showing different render frames from the game Top Gear Overdrive. Not sure why this would be useful apart...", "tags": ["n64","memory","cheatcartridge","datel"], "image": "/public/images/actionreplay/ActionReplayViewer.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Debug Symbols in Retail Games (Console & PC)", "url": "/symbols", "content": "Introduction to Debug SymbolsFinding Debug Symbols when reverse engineering a game is the equivalent of buying a Strategy Guide, all the secrets are unlocked which is awesome but it also removes part of the fun of discovering what each part of the game does.Where do debug symbols come from?Debug symbols are an artifact of compiling a game from a higher level language (e.g. C/C++) down to a lower level language such as Assembly code. They are similar to source maps in modern web development when using a language like typescript that compiles down to javascript, but instead of typescript think C or C++ and instead of javascript think raw machine code or assembly.What are debug symbols used for?They are used by developers to allow them to attach a debugger to the game and debug the code line-by-line with all the function and variable names intact. So you can think of debug symbols as meta data that maps the high level language to each assembly instruction so that developers can add breakpoints in their high level language and the system will know what to do.They are also incredibly valuable in diagnosing a crash as the stack trace would simply be a list of meaningless memory offsets without the debug symbols explaining what functions were called on the way to the crash site.Why are debug symbols only in some games?Developers should remove the debug symbols before the release of the game, a process called stripping executables, but due to the high pressures of development and last-minute bugs they can be left in.Which games are likely to contain debug symbols?Since these are artifacts of compilation it is very unlikely for a game on a platform earlier than the Playstation 1 to contain debug symbols as they tended to be hand written in assembly code.Also some platforms that used compiled code but were to be released on a small storage medium such as cartridge needed all the bytes they could get so it is very unlikely to get debug symbols on platforms such as Nintendo 64 or Game Boy Advance.Games by Platform with debug symbolsSony ConsolesSony consoles have the highest likelihood of shipping with debug symbols, specifically due to the rather relaxed checking of Playstation 2 binaries based on version 2 of the official SDK, but there are also games for PS1 and PSP that have been released with debug symbols in tact.Sony Playstation 1We have a post specifically listing all the debug symbols for the PS1 here:Playstation 1 Games with Debug SymbolsSony Playstation 2We have a post specifically listing all the debug symbols for the PS2 Demos here:PS2 Demo DiscsPlenty of retail games also has their debug symbols:PS2 Retail GamesSony Playstation PortablePlaystation Portable Games with Debug SymbolsNintendo consolesFinding debug symbols on Nintendo consoles was like finding a needle in a haystack, one that did not even have a needle, occasionally you would find some of the developers memory left over in a SNES game, but that all changes with the Gamecube and its large storage space on the disc. Now it became common for developers to loose a tiny few MB file on a large 1GB disc, this trend continued into both the Wii and Wii U era too, with debug symbols even being found in modern switch games!Nintendo 64You will not find any debug symbols left in retail Nintendo 64 games due to limitations of cart size, developers has to squeeze out every last byte to avoid the more expensive cartridges so debug symbols were the first to go.But we do have part of the Turok source code which contains them: Turok 64 Official Source Code AnalysisThere has also been a number of Nintendo leaks, leaking the full source code for multiple Nintendo 64 games. Not to forget the excellent work the community is doing on reversing N64 games even without any symbols present!Nintendo GameCubeNintendo Gamecube Games with Debug SymbolsNintendo WiiWii Games with Debug SymbolsNintendo Wii UWii U Games with Debug SymbolsSEGA consolesWe have never been able to find any Sega Saturn games that actually have debug symbols left on the disc! Sega must have been a little more strict on game developers before the dreamcast, so if you do find any games with debug symbols then please let us know.Sega DreamcastSega Dreamcast Games with Debug SymbolsDebug symbols on Microsoft consolesMicrosoft XboxOriginal Xbox Games with Debug SymbolsThere are also a few platforms that may have games with debug symbols but it is currently unknown: 3DO Cybiko GP32/GP2X/Pandora N-Gage Neo Geo X Sega CD/Sega 32X 007 Agent Under Fire for Nintendo Gamecube Reverse Engineering Introduction Welcome to our page dedicated to the technical details of the Gamecube game 007 Agent Under Fire! If you’re a fan of this classic first-person shooter game, you might... ... Read More gamecube symbols debug reverseengineering games Sega Dreamcast Games with Debug Symbols Debug symbols pretty much open a game wide open to budding verse engineers. These files make reverse engineering almost a piece of cake, giving useful names to each of the... ... Read More sega dreamcast symbols debug Nintendo Gamecube Games with Debug Symbols If you are interested in reverse engineering a Gamecube game, the first step is to find out if the game has its debug symbols available, this makes it much easier... ... Read More gamecube symbols debug reverseengineering Playstation 1 Games with Debug Symbols I have never seen a PS1 executable bigger than 2mb, normally if they require more code they split it into multiple executables. With memory being so precious it would be... ... Read More ps1 reverseengineering symbols Official Sony PS1 Libraries Note that the order of the externals defined in this list will not reflect the order in the final linked executable, as the order here is just the order that... ... Read More ps1 sdk symbols PS2 Demo Disks with Debug Symbols This page is dedicated to listing Playstation 2 Demo Discs that contain developer debug symbols, either embedded inside the executable or as separate .map or .sym files. It was much... ... Read More ps2 symbols games PS2 Official Software Development Kit (SDK) PS2 Official Software development Kit by Sony Last known version: 3.1.0 1 First known version: 0.3.0 2 Updates were provided to licenced PlayStation developers on ps2-pro.com, where the update contained... ... Read More ps2 symbols sdk Playstation Portable Games with Debug Symbols The Sony Playstation portable used encrypted executables known as EBOOT.BIN, these are basically just an encrypted ELF file and it is possible to decrypt them with the correct tools. Some... ... Read More psp symbols games PS2 Games with Debug Symbols (UnStripped Binaries) Debug symbols are normally a rare treasure sought by reverse engineers from prototypes and beta versions of games, however in the early years of the PS2 it was common for... ... Read More ps2 symbols games Wii Games with Debug Symbols Retail Wii Games with Debug Symbols The following table has all the known Wii games that have debug symbols in them, if you find any more please let us know!... ... Read More wii symbols games Wii U Games with Debug symbols (UnStripped Binaries) Wii U games with debug symbols A list of all the WiiU games that are known to have debug symbols are listed in the table below, eventually we want to... ... Read More wiiu symbols games Original Xbox Games with Debug Symbols Debug symbols left in games make reverse engineering almost a piece of cake, giving useful names to each of the functions in an executable and sometimes even full local variable... ... Read More xbox symbols debug games ", "excerpt": "Introduction to Debug Symbols Finding Debug Symbols when reverse engineering a game is the equivalent of buying a Strategy Guide, all the secrets are unlocked which is awesome but it also removes part of the fun of discovering what each part of the game does. Where do debug symbols come...", "tags": ["symbols","debug","games"], "image": "/public/generated/placeholders/symbols.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Decompiling Playstation Mobile Games", "url": "/decompiling-playstation-mobile-games", "content": "Playstation Mobile games are all build using C# and the Mono Runtime environment and thus are trivial to reverse engineer with standard .NET decompilers in many cases with full debug symbols in tact.Reverse Engineering PSMobile GamesThe first step to reverse engineering a Playstation Mobile game is to decrypt the files on the device and find the application executable.Decrypting PS Mobile GamesThis section will cover how to extract and decrypt Playstation Mobile games using a Jailbroken Playstation Vita.First of all you need to have the PS Mobile game installed on your Vita and playable.When installed the contents will be extracted to the folder: /psm/TitleID folder/However all of these files are encrypted with PSSE DRM so if you try to open any of the files including text files they will be un-openable.So in order to decrypt the contents you will need to install the plugin FuckPSSE on your vita, the easiest way is to use AutoPlugin.When the plugin is installed open the game you want to reverse engineer and it will simply show a red screen now, that means its started decrypting! When finished the screen will turn green, when that happens you can safely close the game and disable the plugin.The contents of the Application will have been extracted to the folder: /psm/TitleID folder/RW/TempYou can now find the application executables (app.exe) and libraries (.dll) in this folder, you should then copy these executables to your PC and now you are ready to decompile them in the next step.Decompile the exe with Rider (Win/Mac/Linux)The most cross-platform way to decompile the executables or dlls is to use the IDE by JetBrains called Rider.An alternative if you use Windows is dotPeek which has the same result but this post will cover Rider as it also works on MacOSX and Linux.In Rider you need to open the Folder that your executables are in (File->Open) and it will show all the files in the left pane File System. You can now right click and select View in Assembly Explorer.You can now view all the classes and when you double click them you will see the full C# source code, which is pretty much everything from the original code apart from the comments (which get stripped by the compiler).Extracted ContentThis section will cover the folders and files that you will often find in a decrypted/extracted Playstation Mobile game.Read Only Folder (/RO)The RO folder is where all the application and license files that don’t need to be editable by the game/application reside.Application FolderSome common files that are in this folder: app.exe - The main game executable - decompile this to understand how the game logic works app.info - Binary file with PSMA file header, presumably meta data about the application edata.list - Plain text file of all the files in the Application folder osc.cfg - YAML file containing mapping information for which buttons can be used psse.list - seems to be the same as edata.listThis folder also contains DLL files, which are libraries of shared code that get loaded at runtime, these are also .NET based and you can find a list of the most common in the section below entitled Common Dynamically Linked Libraries.License FolderThis is where you will find the RIF licenses, you won’t need to do anything with these files they are just used to decrypt the content.Read Write Folder (/RW)The RW contains any files that need to be changed by the game/application such as save data or temporary files.Documents FolderThe /RW/Documents folder is used to store files such as Save Games.System FolderThe /RW/System folder is normally used for files such as crash dumps and commonly contains: content_id pm.datTemp (Created by FuckPSSE)The Temp folder is not a standard folder for PS Mobile titles it is created when the FuckPSSE is installed and the game is run, it then puts all the extracted files from the /RO/Application folder.Common FilesThis section contains a list of some of the most common files you will find when looking into the contents of Playstation Mobile games.Mono Debug files (.mdb)Mono Debug files are created by the Mono compiler toolchain when the DLLs or executables are compiled from source code. Name Description AdventureLibPSM.dll.mdb   AscentPSM.dll.mdb   CandyPSM.dll.mdb   Microsoft.Xna.Framework.dll.mdb   MonoGame.Framework.dll.mdb   library_SharePreferences.dll.mdb   Lidgren.Network.dll.mdb   MathTestsLib.dll.mdb   PixelEnginePSM.dll.mdb   PixelEnginePSM2.dll.mdb   PSMHelper.dll.mdb   SpriteEngine.dll.mdb   TileLibPSM.dll.mdb   VitaUnit.dll.mdb   Common Dynamically Linked Libraries (*.DLLS)This section has a list of all the dynamic libraries that are used in most if not all of the Playstation Mobile games. Name Description Microsoft.Xna.Framework.dll Some games are build with Microsofts XNA framework and require this DLL MonoGame.Framework.dll   MonoGame.Framework.PSMobile.dll   Sce.PlayStation.HighLevel.GameEngine2D.dll   Sce.PlayStation.HighLevel.Model.dll   Sce.PlayStation.HighLevel.JsonHelper.dll   Sce.PlayStation.HighLevel.Physics2D.dll   Sce.PlayStation.HighLevel.UI.dll   Sce.Pss.HighLevel.GameEngine2D.dll   System.Core.dll   System.Json.dll   System.Runtime.Serialization.dll   System.ServiceModel.dll   System.ServiceModel.Web.dll   System.Web.Services.dll   System.Xml.dll   System.Xml.Linq.dll   Developers can also make their own DLL files so you can find many more that are custom to a particular game or developer, such as SampleLib.dll. Name Description AdventureLibPSM.dll   AlonePSM.dll   AqualibriumLevelData.dll   AscentPSM.dll   audio.dll   Base.dll   BeatSlider.dll   BitMiracle.LibJpeg.NET.dll   Box2D.dll   CandyPSM.dll   CloudSyncPSM.dll   Cobalt.NET.dll   Comic.dll   Core.dll   cr.dll   DragonPSM.dll   Engine.dll   EngineD.dll   Eruption.dll   fonts/freetype.dll   fonts/zlib1.dll   FractPSM.dll   GameRuntime.dll   GameV.dll   gpu.dll   GUI.dll   Hammock.dll   HenchLua-PSM.dll   HoundPSM.dll   I18N.CJK.dll   I18N.dll   iAppli.dll   ICSharpCode.SharpZipLib.dll   Ingots.dll   ionEngine.dll   Ionic.Zlib.CF.dll   Ionic.ZLib.dll   Irisium.dll   JLib.dll   karman_psm_lib.dll   KungFuFIGHTPSM.dll   kvm.dll   library_SharePreferences.dll   Lidgren.Network.dll   Lidgren.Network.PSMobile.dll   MandoGame.dll   MapsPSM.dll   MathTestsLib.dll   MitLibrary.dll   Moco.dll   Motor2D.dll   MotorAudio.dll   MotorEntrada.dll   Music.dll   Nereid.dll   Newtonsoft.Json.dll   Online.dll   OxygenEngine.dll   PixelEnginePSM.dll   PixelEnginePSM2.dll   Polenter.SharpSerializer.Compact.dll   PSM_Pygmy_Lib.dll   psmGameLib.dll   PSMHelper.dll   PSSCommon.dll   PSSLib.dll   Rat.dll   Resources.dll   rLib.dll   SampleLib.dll   Sanford.Multimedia.Midi.dll   Sanford.Threading.dll   SharpCompress.dll   snippets_psm.dll   SoundEngine.dll   SoundEnginePSM.dll   SpriteEngine.dll   SpriteEnginePSM.dll   TileLibPSM.dll   Tipper.dll   TutoLib.dll   tweetsharp.dll   TwoDeePSM.dll   UnityShim.dll   VacationPSM.dll   VitaUnit.dll   wtlGameEngine.dll   XNATrivial.dll   XRpgLibrary.dll   ysalut.dll   ysgl.dll   ysglut.dll   ysinput.dll   ysut.dll   Unity Specific DLLSThe following table has all of the DLLs used by Unity games on the Playstation Mobile store. Name Description runtime/managed/Boo.Lang.dll   runtime/managed/I18N.CJK.dll   runtime/managed/I18N.dll   runtime/managed/mscorlib.dll   runtime/managed/System.Core.dll   runtime/managed/System.dll   runtime/managed/System.Runtime.Serialization.dll   runtime/managed/System.ServiceModel.dll   runtime/managed/System.ServiceModel.Web.dll   runtime/managed/System.Web.Services.dll   runtime/managed/System.Xml.dll   runtime/managed/System.Xml.Linq.dll   runtime/managed/UnityEngine.dll   runtime/managed/UnityScript.dll   runtime/managed/UnityScript.Lang.dll   Data/Managed/App42_Unity3D_SDK_2.9.1.dll   Data/Managed/Assembly-Boo.dll   Data/Managed/Assembly-CSharp-firstpass.dll   Data/Managed/Assembly-CSharp.dll   Data/Managed/Assembly-UnityScript-firstpass.dll   Data/Managed/Assembly-UnityScript.dll   Data/Managed/BehaviorDesignerRuntime.dll   Data/Managed/clipper_library.dll   Data/Managed/FacebookWinPhone8.dll   Data/Managed/GameDraw.dll   Data/Managed/GPGSUtils.dll   Data/Managed/IFacebook.dll   Data/Managed/JsonFx.Json.dll   Data/Managed/KGFUtils.Settings.dll   Data/Managed/MadCommons.dll   Data/Managed/P31RestKit.dll   Data/Managed/PlayMaker.dll   Data/Managed/Poly2Tri.dll   Data/Managed/ProCore.dll   Data/Managed/SixBySeven.dll   Data/Managed/TDx.TDxInput.dll   Data/Managed/TileSystem.Runtime.dll   Data/Managed/UnityAdMobPlugin.dll   Data/Managed/UnityEngine.Cloud.Analytics.dll   Data/Managed/UnityEngine.Cloud.Analytics.Util.dll   Data/Managed/UnityInAppPurchasePlugin.dll   Data/Managed/UnityLanguagePlugin.dll   Data/Managed/UnityMarketplacePlugin.dll   Data/Managed/UnityPubCenterPlugin.dll   Data/Managed/UnityWindowsStorePlugin.dll   Data/Managed/XInputDotNetPure.dll   Instant Dungeon! - NPNA00174The Playstation Mobile game Instant Dungeon! is an interesting game as it is built with a custom in-house engine called the WithTheLove engine or WTL and it includes a C# interpreter inside it and uses the following 2 DLLs to support it: Name Description Mono.CSharp.dll Only One game is known to have included this (Instant Dungeon! - NPNA00174) Used for a C# Interpreter 1 Microsoft.CSharp.dll Only One game is known to have included this (Instant Dungeon! - NPNA00174) Used for the Dynamic Keyword in C# 2 The Mono.CSharp.dll contains a full C# interpreter allowing scripts to be interpreted on the fly rather than having pre-compiled C# scripts, so the user could potentially modify these scripts to customize the game. The Microsoft.CSharp.dll is used to support the dynamic keyword which allows variables to be a non-static type, useful for languages such as python of javascript which are dynamically typed. For more information about the dynamic keyword checkout: [Using type dynamic - C# Programming Guide Microsoft Docs](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/using-type-dynamic). The game’s engine code is contained in the library wtlGameEngine.dll and this seems to be the only Playstation Mobile game that uses it.This all points to the game supporting a custom scripting language that could be used to mod the game!References c# - How do I use the Mono.CSharp interpreter in Microsoft.NET - Stack Overflow ↩ visual studio 2010 - What is Microsoft.csharp.dll in .NET 4.0 - Stack Overflow ↩ ", "excerpt": "Playstation Mobile games are all build using C# and the Mono Runtime environment and thus are trivial to reverse engineer with standard .NET decompilers in many cases with full debug symbols in tact. Reverse Engineering PSMobile Games The first step to reverse engineering a Playstation Mobile game is to decrypt...", "tags": ["vita","android"], "image": "/public/consoles/Sony PSVita.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Decompiled Retail Console Games", "url": "/source-code/decompiled-retail-console-games", "content": "This post contains either decompiled or disassembled source code projects for console games that were sold at retail stores.If you are interested to see officially released or leaked source code check out this other post: Retail Console Game Source code (C/C++) For the official source code check out this post. To be included in this list the project must have decompiled or disassembled at least 10% of the course code, in order to not pollute the post with hundreds of unfinished projects. An exemption to this rule can be made for consoles with very few reversing projects.Nintendo SystemsNintendo systems are by far the most popular for reverse engineering projects, especially related to 1st party titles such as Mario, Zelda and Pokemon.Nintendo Entertainment System (NES)The table below lists the relevant entries. Name Project Type Mapper Status Balloon Fight Disassembly NROM   Battle City Disassembly NROM   Contra Disassembly UNROM Documented Crystalis Disassembly     Danny Sullivan’s Indy Heat Disassembly     Donald Land Disassembly MMC1   Donkey Kong Disassembly NROM   Double Dragon II: The Revenge (Japanese) Disassembly     Dr. Mario Disassembly MMC1   Dragon Warrior Disassembly MMC1 N/A and Documented Excitebike Disassembly NROM   Final Fantasy I Disassembly MMC1 N/A and Documented Final Fantasy II Disassembly MMC1   Final Fantasy III Disassembly     Game Genie (Cheat Cartridge) Disassembly NROM   Ice Climber (Japanese) Disassembly NROM   Kunio-kun no Nekketsu Soccer League Disassembly     Mappy (Japanese) Disassembly NROM   Mario Bros. Disassembly     Mega Man 3 Disassembly     Mega Man 4 Disassembly     Mega Man 5 Disassembly     Metroid Disassembly     Mike Tyson’s Punch-Out!! Disassembly MMC2   Nuts & Milk (Japanese) Disassembly NROM   Pac-Man (Japanese) Disassembly NROM   Solstice: The Quest for the Staff of Demnos Disassembly     SonSon Disassembly NROM   Super C Disassembly MMC3 Documented Super Mario Bros. Disassembly NROM   Super Mario Bros. 2 The Lost Levels (Japanese) Disassembly     Super Mario Bros. 3 Disassembly     Tecmo World Cup Soccer (Japanese) Disassembly     Tennis Disassembly NROM   Tetris Disassembly MMC1   The Bugs Bunny Crazy Castle Disassembly MMC1   The Legend of Zelda Disassembly MMC1 N/A and Documented Transformers: Mystery of Convoy Disassembly   N/A and Documented Yie Ar Kung Fu Disassembly NROM   Super Nintendo (SNES)The table below lists the relevant entries. Name Project Type   Demon’s Crest Disassembly   Donkey Kong Country Disassembly   Donkey Kong Country 2 Disassembly   Donkey Kong Country 3 Disassembly   Earthbound / Mother 2 Disassembly   Final Fantasy IV Disassembly   Final Fantasy V Disassembly   Final Fantasy VI Disassembly Active Goof Troop Disassembly   Super Bomberman Disassembly   Super Ghouls ‘n Ghosts Disassembly   Super Mario RPG Disassembly   Super Mario World Disassembly   Super Mario World 2: Yoshi’s Island Disassembly   Super Metroid Disassembly   Super Punch-Out!! Disassembly   The Legend of Zelda: A Link to the Past Reimplementation, PC Port Active Nintendo 64Recently, mainly in thanks to the huge success of the Super Mario 64 project, there has been revived interest in Nintendo 64 Decompilation. While most projects are still in very early stages, there are a few that meet the criteria for this list. Name Project Type Status AeroGauge Decompilation Active Aidyn Chronicles: The First Mage Decompilation Active Banjo-Kazooie Decompilation Completed Banjo-Tooie Decompilation Active, 12% Done Blast Corps Decompilation Inactive Body Harvest Decompilation Active Bomberman 64 Decompilation Active Bomberman 64: The Second Attack! Decompilation Active Bomberman Hero Decompilation Active Castlevania 64 Decompilation Active Chameleon Twist Decompilation Active, 44% Done Chameleon Twist 2 Decompilation Active, 3% Done Conker’s Bad Fur Day Decompilation Active, 4% Done Dark Rift Decompilation Active, 70% Done Diddy Kong Racing Decompilation Active, 97% Done Dinosaur Planet Decompilation Active, 18% Done Donkey Kong 64 Decompilation Active, 57% Done Doom 64 Decompilation Completed Doraemon: Nobita to Mittsu no Seireiseki Decompilation Active Dōbutsu no Mori Decompilation Active, 18% Done Dr. Mario 64 Decompilation Active, 98% Done Duke Nukem 64 Decompilation Active Duke Nukem: Zero Hour Decompilation Completed F-Zero X Decompilation Active, 95% Done F-Zero X Expansion Kit Decompilation Active, 97% Done Gauntlet Legends Decompilation Inactive Gex 64: Enter the Gecko Decompilation Active Glover Decompilation Active Goemon’s Great Adventure Decompilation Inaccessible GoldenEye 007 Decompilation Active, 71% Done Harvest Moon 64 Decompilation Active, 80% Done Jet Force Gemini Decompilation Active Kirby 64: The Crystal Shards Decompilation Active, 12% Done Lego Racers Decompilation Active Mario Golf Decompilation Active Mario Kart 64 Decompilation Completed Mario Party Decompilation Active Mario Party 2 Decompilation Active Mario Party 3 Decompilation Active Mario Tennis Decompilation Active Mischief Makers Decompilation Active, 3% Done Mystical Ninja Starring Goemon Decompilation Active Neon Genesis Evangelion Decompilation Active Onegai Monsters Decompilation Active Paper Mario Decompilation Completed Perfect Dark Decompilation Completed Pokemon Puzzle League Decompilation Active, 43% Done Pokemon Snap Decompilation Active, 96% Done Pokemon Stadium Decompilation Active Pokemon Stadium 2 Decompilation Active Quest 64 Decompilation Active Rocket: Robot on Wheels Decompilation Inactive Shadowgate 64 Decompilation Inactive Snowboard Kids 2 Decompilation Active, 69% Done Space Station Silicon Valley Decompilation Active, 77% Done Star Fox 64 Decompilation Active, 99% Done Star Wars: Shadows of the Empire Decompilation Active Super Mario 64 Decompilation Completed Super Smash Bros. Decompilation Active Superman 64 Decompilation Inactive The Legend of Zelda: Ocarina of Time Decompilation Completed The Legend of Zelda: Majora’s Mask Decompilation Completed The New Tetris Decompilation Active Turok 3: Shadow of Oblivion Decompilation Inactive Virtual Pool 64 Decompilation Inactive Virtual Pro Wrestling 2: Ōdō Keishō Decompilation Active Wave Race 64 Decompilation Active, 49% Done Yoshi’s Story Decompilation Active, 13% Done Nintendo GameCubeThe table below lists the relevant entries. Name Project Type Status Animal Crossing Decompilation Active, 99% Done Chibi-Robo! Plug Into Adventure! Decompilation Active Doshin the Giant Decompilation Active Dōbutsu no Mori e+ Decompilation Active Harvest Moon: A Wonderful Life Decompilation Inactive Homeland Decompilation Inactive Kirby Air Ride Decompilation Inactive Luigi’s Mansion Decompilation Inactive Mario Kart: Double Dash!! Decompilation Active, 42% Done Mario Party 4 Decompilation Completed Mario Party 5 Decompilation Active, 16% Done Mario Party 6 Decompilation Active Mario Party 7 Decompilation Active Mario Superstar Baseball Decompilation Active, 9% Done Metroid Prime Decompilation Active, 24% Done Metroid Prime 2: Echoes Decompilation Active, 1% Done Need for Speed: Most Wanted Decompilation Active, 1% Done Need for Speed: Underground Decompilation Active Naruto: Gekitō Ninja Taisen! 4 Decompilation Inactive Paper Mario: The Thousand-Year Door Decompilation Active, 14% Done Pikmin Decompilation Active, 99% Done Pikmin 2 Decompilation Active, 86% Done Ratatouille Decompilation Active, 2% Done Skies of Arcadia Legends Decompilation Active Sonic Adventure DX Decompilation Inactive Sonic Riders Decompilation Inactive SpongeBob SquarePants: Battle for Bikini Bottom Decompilation Active, 35% Done Star Fox Adventures Decompilation Active Summoner: A Goddess Reborn Decompilation Active, 10% Done Super Mario Strikers Decompilation Active, 21% Done Super Mario Sunshine Decompilation Active, 25% Done Super Monkey Ball Decompilation Inactive, 59% Done Super Smash Bros. Melee Decompilation Active, 47% Done The Incredibles Decompilation Inactive The Legend of Zelda: The Wind Waker Decompilation Active, 56% Done The Legend of Zelda: Twilight Princess Decompilation Completed The SpongeBob SquarePants Movie Decompilation Active, 5% Done Ty the Tasmanian Tiger Decompilation Active, 24% Done Nintendo WiiThe table below lists the relevant entries. Name Project Type Status Inazuma Eleven Strikers Decompilation Active Kirby’s Epic Yarn Decompilation Active Mario Kart Wii Decompilation Active, 11% Mario Party 8 Decompilation Inactive Mario Party 9 Decompilation Active Pokemon Battle Revolution Decompilation Active, 1% Done Pokepark Wii: Pikachu’s Adventure Decompilation Active, 1% Done Rock_Band_3 Decompilation Active, 50% Done Sonic Riders: Zero Gravity Decompilation Active Super Mario Galaxy (Korean) Decompilation Active, 23% Done Super Mario Galaxy 2 Decompilation Active, 1% Done Super Paper Mario Decompilation Active, 2% Done Super Smash Bros. Brawl Decompilation Active, 1% Done The Legend of Zelda: Ocarina of Time (Virtual Console) Decompilation Active, 31% Done The Legend of Zelda: Skyward Sword Decompilation Active, 11% Done The Sims 2: Castaway Decompilation Inactive Wii Sports Decompilation Active, 22% Done Xenoblade Chronicles Decompilation Active, 7% Done Nintendo SwitchSuper Mario 3D World + Bowser’s Fury A decompilation of Super Mario 3D World + Bowser's Fury Active, 3% Done Super Mario Odyssey A decompilation of Super Mario Odyssey Active, 15% Done The Legend of Zelda: Breath of the Wild A decompilation of The Legend of Zelda: Breath of the Wild Active, 17% Done Nintendo HandheldsGame BoyThe following table presents the latest updates on ongoing Game Boy reverse engineering projects. Name Project Type     Donkey Kong ‘94 Disassembly   Kirby’s Dream Land Disassembly   Metroid II: Return of Samus Disassembly   Mole Mania Disassembly   Pokemon Red & Blue Disassembly   Pokemon Yellow Disassembly   Super Mario Land Disassembly   Super Mario Land 2: Six Golden Coins Disassembly   Super Mario Land 3: Wario Land Disassembly   Tetris Disassembly Game Boy ColorThe table below lists the relevant entries. Name Project Type     Dragon Warrior Monsters (German) Disassembly   Looney Tunes: Carrot Crazy Disassembly   Pokemon Gold & Silver Disassembly   Pokemon Crystal Disassembly   Pokemon Pinball Disassembly   Pokemon Trading Card Game Disassembly   Pokémon Puzzle Challenge Disassembly   Wario Land 3 Disassembly   The Legend of Zelda Links Awakening DX Disassembly   The Legend of Zelda Oracle of Ages & Seasons Disassembly Game Boy AdvanceThe table below lists the relevant entries. Name Project Type Status Banjo-Kazooie: Grunty’s Revenge Decompilation Active, 32% Done Breath of Fire Decompilation Inactive Fire Emblem: The Binding Blade Decompilations Active Fire Emblem: The Sacred Stones Decompilations Active Harvest Moon: Friends of Mineral Town Decompilations Active Kirby & The Amazing Mirror Decompilations Active Mario & Luigi: Superstar Saga Disassembly Inactive Mario VS Donkey Kong Decompilation Inactive Metroid: Zero Mission Decompilation Active, 98% Done Mother 1+2 (Japan) Decompilation Inactive Pokemon Ruby & Sapphire Decompilation Active Pokemon Emerald Decompilation Active Pokemon FireRed & LeafGreen Decompilation Active Pokémon Mystery Dungeon: Red Rescue Team Decompilation Active Pokémon Pinball: Ruby & Sapphire Decompilation Active Sonic Advance 2 Decompilation Active, 67% Done Summon Night Swordcraft Story 3 Decompilation Active Super Mario Advance 2: Super Mario World Decompilation Active The Legend of Zelda: The Minish Cap Decompilation Completed Yu-Gi-Oh! Reshef of Destruction Decompilation Active Nintendo DSCastlevania: Order of Ecclesia Decompilation of Castlevania: Order of Ecclesia This is a decompilation of Castlevania: Order of Ecclesia. Dragon Quest IX Decompilation of Dragon Quest IX This is a decompilation of Dragon Quest IX. Mario & Luigi - Partners in Time Decompilation of Mario & Luigi - Partners in Time This is a decompilation of Mario & Luigi - Partners in Time. Mario Party DS Decompilation of Mario Party DS This is a decompilation of Mario Party DS. Pokemon Diamond and Pearl Decompilation of Pokémon Diamond/Pearl This is a decompilation of Pokémon Diamond/Pearl. Pokemon HeartGold and SoulSilver Decompilation of Pokémon HeartGold/SoulSilver This is a decompilation of Pokémon HeartGold/SoulSilver. Rhythm Heaven (Gold) Decompilation of Rhythm Heaven This is a decompilation of Rhythm Heaven. The Legend of Zelda: Phantom Hourglass Decompilation of The Legend of Zelda: Phantom Hourglass This is a decompilation of The Legend of Zelda: Phantom Hourglass. The Legend of Zelda: Spirit Tracks Decompilation of The Legend of Zelda: Spirit Tracks This is a decompilation of The Legend of Zelda: Spirit Tracks. Nintendo 3DSPaper Mario: Sticker Star Paper Mario: Sticker Star Decompilation This is a decompilation of Paper Mario: Sticker Star. Super Mario 3D Land (EU) Super Mario 3D Land EU Decompilation This is a decompilation of the EU version of Super Mario 3D Land. The Legend of Zelda: Ocarina of Time 3D The Legend of Zelda: Ocarina of Time 3D Decompilation This is a decompilation of The Legend of Zelda: Ocarina of Time 3D. Sega SystemsSega is similar to Nintendo in that most of the games that people are interested in reverse engineering are 1st party titles such as Sonic and Phantasy Star.32XKnuckles Chaotix Knuckles Chaotix Knuckles Chaotix Sega CDShining Force CD A disassembly of the game Shining Force CD . Sega Master SystemAlthough the Sega Master System was hugely popular in Europe, it can’t compete with the NES for number of disassembled projects created so far.Phantasy Star Phantasy Star Disassembly Incomplete Phantasy Star Disassembly for Sega Master System from SonicRetro. It uses the wla-z80 assembler to build the ROM Sonic 2 Sonic 2 SMS Disassembly Sonic 2 for the Sega Master System Incomplete Disassembly from SonicRetro. It uses the wla-z80 assembler to build the ROM. Sega Mega DriveThe Sega Mega Drive was Sega’s most popular console in terms of games developed, and as such it also seems to be the most popular for reverse engineering projects too. Name Project Type     Kid Chameleon Disassembly   Knuckles the Echidna in Sonic the Hedgehog 2 Disassembly   Phantasy Star II Disassembly   Phantasy Star III Disassembly   Phantasy Star IV Disassembly   Ristar Disassembly   Sonic the Hedgehog Disassembly   Sonic the Hedgehog 2 Disassembly   Sonic the Hedgehog 3 Disassembly   Sonic & Knuckles Disassembly   Sonic 3D Blast Disassembly   Sonic Spinball Disassembly Sega Game Gear (GG)Sonic 1 A work in progress split disassembly of Sonic The Hedgehog on the Sega Game Gear Sega Dreamcast (DC)Sonic Adventure Sonic Adventure (DC) Disassembly Very early disassembly of Sonic Adventure for the Dreamcast. Tokyo Bus Guide Tokyo Bus Guide Decompilation This is a decompilation of Tokyo Bus Guide for the Dreamcast. Sega Model 2 ArcadeSonic the Fighters Sonic the Fighters Disassembly Sony SystemsCompared to the other systems, Sony doesn’t have many decompilation projects, mainly due to the higher complexity of the games developed by the PS1 era, requiring much larger teams to create the games in the first place.PlayStation 1The table below lists the relevant entries. Name Project Type Status Castlevania: Symphony of the Night Decompilation Active Crash Bandicoot Decompilation Active, 78% functional Crash Bandicoot 2: Cortex Strikes Back Decompilation Inactive Crash Team Racing Decompilation Active, 73% Done Croc: Legend of the Gobbos Decompilation Inactive Driver 2 Decompilation N/A, Fully Playable on PC Final Fantasy VII Decompilation Active Frogger: He’s Back! Decompilation Inactive Legacy of Kain: Soul Reaver Decompilation Active, 80% Done Legend of Dragoon Decompilation Active, 90% Done (First Disk Playable) Legend of Legaia Decompilation Active LSD Dream Emulator Decompilation Active Lunar 2: Eternal Blue Decompilation Inactive, 12% Done MediEvil Decompilation Inactive Metal Gear Solid Decompilation Active, SLPM_862.47, SLPM_862.48 and SLPM_862.49 Completed Need for Speed: High Stakes Decompilation Inactive Need for Speed 1-6 Game Engine Reimplementation Inactive PSX DOOM Decompilation Completed Shin Megami Tensei Decompilation Active Silent Hill Decompilation Active, 26% Done Spyro the Dragon Decompilation Active, 58% Done Tomb Raider Reimplementation PC Port Fully Playable Tomb Raider II Reimplementation Active - v0.8.2 release Tomb Raider: Chronicles Decompilation Inactive Tomb Raider 1-5 Game Engine Reimplementation First Game Fully Playable Tomba! Decompilation Active, 35% Done Twisted Metal Decompilation Active Vandal Hearts Decompilation Active Vagrant Story Decompilation Active, 16% Done Xenogears Decompilation Active, 15% Done PlayStation 2Dark Cloud Decompilation project for Dark Cloud for the PS2 Decompilation project for Dark Cloud. Fatal Frame 1 Decompilation project for Fatal Frame 1 for the PS2 Decompilation project for Fatal Frame 1. Fatal Frame 2 Decompilation project for Fatal Frame 2: Crimson Butterfly for the PS2 Decompilation project for Fatal Frame 2. Ico Decompilation project for Ico for the PS2 This is a decompilation project for Ico for the PS2. Jak & Daxter 1-2 Jak Project: Reviving the language that brought us the Jak & Daxter Series This project is to port Jak 1 (NTSC, 'black label' version) to PC. Over 98% of this game is written in GOAL, a custom Lisp language developed by Naughty Dog. Kingdom Hearts Decompilation of the first japanese version of Kingdom Hearts for PS2 We're currently just targeting the main game executable, which is an elf file SLPS_251.05 with sha1 9dabbf867a7ec2a030df99ba1ed969f2deef0488. Klonoa 2: Lunatea’s Veil Decompilation project for Klonoa 2: Lunatea's Veil for the PS2 Targeting SLUS_201.51. Structs, classes, and function names are taken from decompiling the C# assembly of Klonoa Phantasy Reverie Series. Metal Gear Solid 2: Sons of Liberty Decompilation project for Metal Gear Solid 2: Sons of Liberty for the PS2 Decompilation project for Metal Gear Solid 2: Sons of Liberty for the PS2. PaRappa the Rapper 2 Decompilation project for PaRappa the Rapper 2 for the PS2 Decompilation project for PaRappa the Rapper 2 (NTSC-J). Resident Evil - Code: Veronica X Decompilation project for Resident Evil - Code: Veronica X for the PS2 Decompilation project for Resident Evil - Code: Veronica X for the PS2. Sly Cooper and the Thievius Raccoonus Decompilation of Sly Cooper and the Thievius Raccoonus for the PS2 This is a work-in-progress, experimental decompilation of Sly Cooper and the Thievius Raccoonus for the PlayStation 2. It is based on the NTSC-U version of the game (SCUS-971.98) Street Fighter III: 3rd Strike Completed decompilation project for Street Fighter III: 3rd Strike for the PS2 This is a completed decompilation project for Street Fighter III: 3rd Strike for the PS2. Twisted Metal: Black Decompilation project for Twisted Metal: Black for the PS2 This is a decompilation project for Twisted Metal: Black for the PS2. Xenosaga Episode 1 - Der Wille zur Macht Decompilation project for Xenosaga Episode 1 - Der Wille zur Macht for the PS2. This is a decompilation project for Xenosaga Episode 1 - Der Wille zur Macht for the PS2. Yakuza Decompilation project for Yakuza for the PS2 This is a decompilation project for Yakuza for the PS2. Microsoft SystemsThere are only a handful of reverse engineered games for Microsoft game consoles.MSXMetal Gear (1987) Fully annotated disassembly of the original Metal Gear game This repository contains the fully annotated disassembly of the original Metal Gear game, released by Konami for MSX2 in 1987 with code RC750. XboxHalo: Combat Evolved Halo: Combat Evolved Decompilation Research Project The goal of this project is to study and create a free, open-source re-implementation of the original Xbox launch title Halo: Combat Evolved. Xbox 360Sonic Unleashed Static Recompilationhedge-dev has released UnleashedRecomp, a project that statically recompiles the Xbox 360 version of Sonic Unleashed to run natively on PC. By translating the original PowerPC instructions and Xenos shaders into native C++ and HLSL, this tool bypasses traditional emulation overhead, enabling features like arbitrary resolutions, high frame rates, and deep modding support on Windows and Linux. UnleashedRecomp: Native PC Port of Sonic Unleashed hedge-dev has released UnleashedRecomp, a static recompilation tool that allows Sonic Unleashed to run natively on PC with performance enhancements and modding support. Terraria Broken Decompiled Terraria Xbox 360 Edition source code Since Terraria is based on XNA which is a C# library, it is possible to decompile back into C# source code. This project is still very early but has some interesting results. PC (Windows)The table below lists the relevant entries. Name Project Type Status Cave Story Decompilation Taken down by DMCA Cosmo’s Cosmic Adventure Decompilation Active Deus Ex: Human Revolution Decompilation Active Diablo Decompilation N/A Diablo II Decompilation Active, >50% Duck Game Decompilation Completed Duke Nukem II (DOS) Reimplementation N/A Lego Island Decompilation Active, 98% Accuracy Oddworld 1-2 Game Engine Reimplementation Active, Playable Oregon Trail II Decompilation Active Plants vs. Zombies GOTY Edition Decompilation Active SkiFree Decompilation Completed Sonic CD (2011) Decompilation Active Sonic Mania Decompilation Active ShortLine railroad (DOS) Decompilation Completed Touhou Koumakyou: The Embodiment of Scarlet Devil Decompilation Active Twisted Metal 2 Decompilation Inactive Atari SystemsAtari 2600 Disassemblies of original Atari 2600 games Various disassembled Atari 2600 games Donkey Kong Donkey Kong (Atari 2600) ColecoVisionDonkey Kong Donkey Kong for ColecoVision Disassembly NEC SystemsPC-9801Touhou Project 1-5 (1997-1998) The Touhou PC-98 Restoration Project This project aims to perfectly reconstruct the source code of the first five Touhou Project games by ZUN Soft (now Team Shanghai Alice), which were originally released exclusively for the NEC PC-9801 system. Mobile gamesMobile games are a special case that weren’t initially going to be included, but we have included a few games that are based on console games.Java 2 Mobile Edition (J2ME)Sonic 1 J2ME Decompile of the 2005 mobile port of Sonic 1 A decompilation of the 2005 Java mobile port of Sonic the Hedgehog (1991). This decompilation focuses on the 240x320 resolution version, of part 1 as it uses the original game's graphics. However, there are lower resolutions that function similarily. And part 2 consists of the largest available resolution; 208x208. Part 1 was created by iFone, and 2 by Glu. AndroidSonic 1 & 2 Classic (2013) A complete decompilation of Sonic 1 & Sonic 2 (2013) & Retro Engine (v4) Sonic Advance A Monkey port of decompiled Java from Sonic Advance (Mobile) Sonic GBA is a fan developed reinterpretation of decompiled Java output from the Android version of Sonic Advance. Windows PhonePlants vs. Zombies (2011) A port of Plants vs. Zombies Windows Phone version to various platforms powered by MonoGame. ", "excerpt": "This post contains either decompiled or disassembled source code projects for console games that were sold at retail stores. If you are interested to see officially released or leaked source code check out this other post: Retail Console Game Source code (C/C++) For the official source code check out this...", "tags": ["sourcecode","games"], "image": "/public/images/Decompiled Retail Console Games.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Develop (UK) Game Development Magazine/Journal", "url": "/develop-magazine", "content": "DevelopDevelop was a UK magazine dedicated to game developers in the industry similar to the US magazine Game Developer, it published 11 issues a year, one a month except December and January where there was one issue for both months.After 188 issues it was merged with its sister title MCV to become MCV/Develop but it kept the MCV issue numbering.As of 2025 MCV/Develop is still being published and is free online, go and show your support: MCV/DEVELOP - Video games industry news, events, research and jobsContentsFor most of its run the magazine was divided into the following 3 sections: Alpha - News and views on game development Beta - Development features, Interviews, essays and more Build - The latest tools news, tech updates and tutorialsOther subsections included: Develop Jobs - Your monthly guide to the best career opportunities in games development worldwide Directory - The world’s premier listing of games development studios, tools, outsourcing specialists, services and coursesCirculation informationThe information we have about the circulation (number of magazines sold) are listed below: In 2001 it was 5,000 In 2004 it was 8,263Most of the information above came from their Media packs that they used to send to advertising agencies. Most adverts published in the magazine were highly targeted for Games industry professionals, such as for game engines, middleware, jobs and more, so it blended in well with the rest of the content.PublishersDuring its run it went through a number of different publishers: Intent Media - 1996-1998 - Also Published MCV, ToyNews, PC Retail and Mobile Entertainment magazines MCV Media - 1998-2012 - Rebrand of Intent Media 1, but some titles continued to use the Intent Media brand New Bay Media - 2012-2017 - Acquired Intent Media in 2012 including all their titles 2 Future Publishing - 2018-Present - Acquired New Bay Media (This was after Develop merged with MCV)Note that since all the Publisher changes were acquisitions, the magazine continued to use the previous publisher name on the cover.Beta ArticlesBeta was the main section that contained interviews with industry professionals about specific topics related to the games industry as a whole.In 2007 some of the interviews from the magazine were also posted on the website, for those we will provide a link in the table below of all the interviews we know about: Issue Number Interview Name Description 075 John Romero Design Doc - Emotion in games 075 Gordon Hall Michael French talks to Rockstar Leeds boss Gordon Hall to find out more about the Develop Award-winning team’s first ten years of business, and plans for the future. 076 Torsten Reil Michael French speaks to NaturalMotion CEO Torsten Reil about the company’s decision to move into full game production and how procedural content is helping its small development team build a new IP… 076 Chris Ambler QA teams across the industry need to focus on professionalism, says Electronic Arts UK’s testing boss Chris Ambler… 076 Serkan Hassan Black Rock Studio’s Serkan Hassan provides an invaluable glimpse into how the team behind critically-praised franchise MotoGP recently aimed to please both casual and hardcore players with its latest release… 077 David Edery With Xbox Live Arcade’s three-year anniversary nearing, Michael French spoke to the platform’s Worldwide Games Portfolio Planner, David Edery, to get an update on what the service can offer developers… 077 Tony Beckwith A year after acquisition, how is Black Rock Studio changing under the guidance of Disney and how does that play into House of Mouse’s plans for games? Michael French spoke to Tony Beckwith, studio chief, and Disney’s VP of European production Ed Bainbridge to find out… 077 Keita Takahashi In this extract from his book Inside Game Design, Iain Simons talks to Katamari Damacy creator Keita Takahashi about his work ethic, how he comes up with ideas, and his thoughts on the video games medium… 077 Paul Sheppard ITI Techmedia’s Paul Sheppard says that developers need to improve their game design process at pre-production stage and offers a up a more methodological approach… 078 Harold Ryan Ed Fear spoke to Bungie’s studio manager Harold Ryan to find out why the team has gone solo… 078 Jim Bambra, Alex McLean Managing director Jim Bambra and technical director Alex McLean talk to Michael French about what’s changed for Pivotal in its year’s as an internal team and as it works on a next-gen title… 079 Mick Morris, Richard Scott, Andy Emery Develop caught up with the heads of three service companies to talk about recent changes in the field and how developers should approach the outsourcing process… 079 Gavin Cheshire, Adrian Bolton Codemasters has been a mainstay of the UK development scene, but now it has big plans for the future focused around new technology, new IP, and new talent. Michael French paid the exec team a visit to find out more… 163 Sam Barlow Following the runaway success of his first indie release Her Story, Sam Barlow discusses why he left triple-A to develop on his unique vision for the game Build ArticlesThe Build section of the magazine is the most relevant to the purpose of this site as it covers the technology of how games were made at the time and covered a wide range to technical topics such as game AI, audio and game engine development. Issue Article Topic Description 075 Rethinking game AI AI What are the implications of AI.implant’s new no-costing licensing model? 075 MMO Engine Round-Up Engine When it comes to MMOGs, at least there’s plenty of middleware to choose from 075 Arcade Fire Indie Stainless Games’ Ben Gunstone offers up some key advice on making games for Xbox Live Arcade… 075 Heard About: Heavenly Sword Audio John Broomhall talks to Ninja Theory’s Tom Colvin and SCEE’s Garry Taylor about the audio production of a PlayStation 3 epic… 075 Epic Diaries Unreal Another fantastic E3 for Unreal Engine 3 075 Championship Management Production Managing a next-gen project can feel like trying to tame Godzilla, but there are software solutions and fashionable paradigms that claim to make your life easier, discovers Ed Fear. 076 Emergent emerges Engine The final pieces of Emergent’s online game technology puzzle are soon to be announced, but that’s not all… 076 Heard About: Harry Potter and the Order of the Phoenix Audio John Broomhall talks to Electronic Arts UK’s Adele Cutting about the audio production for Harry Potter and the Order of the Pheonix 076 Life in the engine room Engine More and more studios are looking towards licensing existing technology to help them produce their game. But, asks Ed Fear, how do you choose which engine, and is it really the panacea it may seem? 076 The door is OpenKODE Mobile Mobile developers now have a way to sidestep tricky platform fragmentation, says Ideaworks3D’s Tim Closs… 077 Lets get connected Networking Most games offer some sort of online features but, surprisingly, there’s less traditional networking middleware available than ever before, discovers Jon Jordan 077 Parallel Lines Hardware Multicore architectures are everywhere but it’s proving difficult to make them sing. Scottish middleware company Codeplay has an idea 077 Virtual Heroes are Serious about games Unreal Mark Rein profiles a new Unreal Engine 3 customer… 077 Heard About: Sega Rally - www.developmag.com Audio John Broomhall talks to audio director Tim Bartlett on the rebirth of Sega’s racer… 077 Poetry in motion Motion Capture It might have been around for a relatively long time, but that doesn’t necessarily mean that the motion capture industry is slowing down as it reaches maturity. Ed Fear takes a look at the latest movements in the field… 078 Locked and bloated DRM Nothing’s completely secure, but in a digital, connected world, it’s well worth ensuring your content is as protected as possible, says Jon Jordan 078 The Emergence of Emergent Engine Piece by piece, Emergent Game Technologies is building the next generation of middleware, Jon Jordan discovers… 078 EPIC’S UE3-BASED PC GAMES ALMOST GOLDEN Unreal Your monthly update on what’s new in the world of Unreal Engine… 078 Heard About: The Club Audio John Broomhall talks to Bizarre Creations’ lead audio designer Mathias Grunwaldt about the sound production on a new IP for Sega… 078 The Brain Drain AI Ed Fear looks at the field and sees what today’s consoles can do to train our games’ brains… 079 MULTITALENTED Programming Ed Fear looks at how the increasingly contradictory nature of development – with studios asked to make one game for a variety of different machines – has impacted the industry… 079 All part of the process Production As projects get bigger, more complex and distributed around the globe, making sure your production and asset management tools are as sharp as possible is becoming critically important, says Jon Jordan… 079 Out-the-box town planning Engine French middleware company Gamr7 is aiming for automatic city generation… 079 HDFILMS signs UE3 for animated series Unreal HDFilms has selected Unreal Engine 3 to develop Chadam, its new short- form 3D animated Web series to be distributed by Studio 2.0 079 Heard About: 2008 – BRING IT ON Audio John Broomhall toasts the past year of game audio and looks forward to 2008… 079 Killer Characters Art Develop offers an overview of the character animation tool market 163 AI’s next frontier AI With all the advances already made in video games AI, where is there left to go? Craig Chapple asks the experts where the technology goes next 163 Creating Believable AI AI Experts pitch in with their top tips, tricks and things to consider when creating AI 163 Keeping your game on track Production Developing a video game is no small endeavour, and tracking its progress is essential. We find out how version management tools can help 163 DAW of a new era Audio With 2015.1, Wwise is striving to bridge the gap between video games and digital audio workstations 163 The sound of No Man’s Sky Audio John Broomhall speaks to Earcom’s Paul Weir about the excitement surrounding Hello Games’ intriguing title 163 Preparing for Windows 10 Engine We look at how Marmalade has worked with Microsoft to introduce Windows 10 support to its popular tools 163 Unreal Engine 4 mods take off Unreal Million-selling indie game Ark: Survival Evolved opens up new commercial opportunities for modders. Epic Games tells us more 163 A recipe for greatness Unity We catch up with Bossa Studios to find out the origins of its wacky new IP, I Am Bread (Unity) Recurring journalists include: John Broomhall has a monthly section called Heard About specifically about Game Audio Ed Fear writes multiple articles about a wide range of topics from motion capture to AI Jon Jordan writes a wide range of articles from project management software to DRMDirectory ArticlesTools SpotlightEvery month in the directory section of the magazine one specific tool is given a brief review, in this section we will list the tool covered in each issue of the magazines we have access to. Issue Tool Description 075 Autodesk Mentions 3D Studio Max 9, Maya 8, MotionBuilder 7, HumanIK 076 PROFX Described simply, ProFX is a middleware solution for generating and rendering procedural textures – but such a description belies the technology that powers it. 077 SILO 2.0 Organic sculpting applications are all the rage these days, but it’s fair to say that few can offer the value-for-money that Silo does at $150 078 TECHEXCEL DEVTRACK DevTrack is TechExcel’s project issue-tracking tool, comprehensively managing issues as far reaching as: new features, QA reports and IT activities. (Clients include Activision, Electronic Arts, Sammy Studios, Sony Online Entertainment, Vivendi Universal) 163 Haxe Game Engine Studio SpotlightEvery month a game development studio is profiled with interviews and photos, giving an excellent insight into both AAA and indie studios! Issue Studio Location Games 075 3D CREATION STUDIO UK Project Gotham Racing 4 (Bizarre Creations), The Club (Bizarre Creations) 076 SIDE UK Heavenly Sword, Dragon Quest VIII 077 LOCALSOFT Marbella, Spain WiiSports (Wii), Final Fantasy IV (GBA) 078 MILESTONE Milan, Italy Evolution GT (PS2, PC), SCAR - Squadra Corse Alfa Romeo (Xbox, PC, PS2) 078 SPECIALMOVE Glasgow, UK Recruiter 079 PEPPERMINT P Surrey UK PR agency for studios: Firebrand Games, Rovio Mobile, Rockpool Games 163 Roll7 UK OlliOlli 2, Not A Hero Game Dev Family TreeOne of the sections I love about the magazine was the interesting “Family Tree” diagrams that focussed on one city every month, here is an example of Liverpool:It was either sponsored by Amiqus or just an entire advert by them, but either way it provided very interesting information as the games industry is full of mergers, acquisitions and new studios being formed by former employees of other studios.The Develop Industry Excellence AwardsDevelop hosted an annual game development awards ceremony which was highly coveted in the industry, especially in europe but was also known worldwide. From 2003 until the present day the awards were judged by a panel of 50+ industry professionals across a large number of categories (18 in 2005) 3.It is held in London every year and the first was at the Royal Garden Hotel in Kensington on August 27th 2003 4.The WebsiteFrom 2001 Develop had a website at the url http://www.developmag.com which later changed to http://www.develop-online.net/ in July 2009.It was initially (2001-2004) a very basic website with a very brief description of the main articles, circulation information and a media pack containing circulation information to attract advertisers.In July 2005 they redesigned their website to include much more information including news which mostly linked to gamasutra articles before switching briefly to Next generation and then eventually posting news articles of their own. A PDF download of the latest issue was available but only after filling in a form to get it emailed to you.Cover ArtThe Develop magazine had some great cover art throughout the years, we will list a couple of our favourites below. We don’t have all the issues so apologies if your favourite is missing.Issue 37 advertises “Vivarin” a game development supplement to help with Game Crunches (for PS2, Xbox or Gamecube developers):Issue 40 shows the dream ‘Superstar developer” who makes millions:References MCV MEDIA UK LIMITED overview GOV.UK ↩ Intent Media acquired ↩ Develop Industry Excellence Awards Announced ↩ Climax Nominated For Five Develop Industry Excellence Awards - IGN ↩ ", "excerpt": "Develop Develop was a UK magazine dedicated to game developers in the industry similar to the US magazine Game Developer, it published 11 issues a year, one a month except December and January where there was one issue for both months. After 188 issues it was merged with its sister...", "tags": ["industry","magazines"], "image": "/public/images/magazines/Develop UK Magazine.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Disassemblers - A Deep Dive", "url": "/disassemblers", "content": "Understanding How Disassemblers Work: A Deep DiveIn the world of retro gaming, reverse engineering, and software development, disassemblers are essential tools.They provide a bridge between binary code and human-readable assembly language, allowing developers and enthusiasts to analyze and understand software at a fundamental level.This post delves into how disassemblers work, their significance, and why they’re indispensable for anyone interested in reverse engineering or low-level programming.What is a Disassembler?A disassembler is a tool that converts machine code-binary instructions executed by a CPU-back into assembly language.What is Assembly Language?Assembly language is a low-level programming language that is closely related to machine code but is easier for humans to read and understand.Each CPU architecture (e.g., x86, ARM, MIPS) has its own set of instructions and corresponding assembly language.Why use a Disassembler?Disassemblers are used primarily in reverse engineering, debugging, and analyzing how a program operates internally.They provide insights into the logic and flow of a program without requiring access to the original source code.Challenges in DisassemblyWhile disassemblers are powerful tools, they face several challenges:Obfuscation and Anti-Reverse Engineering TechniquesMany programs use obfuscation techniques to make disassembly difficult. This can include instruction reordering, encrypted code sections, and junk code insertion, all of which confuse linear disassembly methods.Instruction AmbiguityIn some cases, it’s challenging to distinguish between code and data, especially when a binary intermixes the two. This can lead to incorrect disassembly if the wrong bytes are interpreted as instructions.Lack of Symbols and Debugging InformationWhen binaries are stripped of symbols and debugging information, the disassembler must rely on pattern recognition and heuristics to name functions and variables. This can result in less meaningful disassembly output, making analysis more difficult.Static Disassembly - Step-by-StepTo understand how disassemblers work, it’s essential to break down the disassembly process into key steps:Step 1 - Loading the BinaryThe first step in disassembly is loading the binary file into the disassembler.This binary file is typically an executable or a compiled program that contains the machine code.The disassembler reads this file byte by byte, interpreting each byte as part of an instruction.Step 2 - Identifying Instruction BoundariesCPUs execute instructions in sequence, with each instruction typically consisting of an operation code (opcode) and operands.However, machine code is just a stream of bytes, so the disassembler must identify where each instruction begins and ends.This can be challenging because instruction lengths can vary depending on the CPU architecture.Disassemblers use several techniques to identify instruction boundaries: Linear Sweep - The disassembler starts at the entry point of the program and reads instructions sequentially. Recursive Descent - Starting at the entry point, the disassembler follows control flow instructions (like jumps and calls) to identify the next instructions to decode.Linear SweepThe disassembler starts at the entry point of the program and reads instructions sequentially.This method assumes that all instructions are valid and contiguous, which is not always the case, especially with data interleaved in the code or with obfuscation techniques.A Javascript example of Linear sweep for a Z80 disassembler is shown below, it only has a few opcodes to show the main ideas:// Z80 opcode map (simplified)const z80Instructions = { 0x00: { mnemonic: 'NOP', size: 1 }, 0x3E: { mnemonic: 'LD A,', size: 2 }, // 2-byte instruction 0x06: { mnemonic: 'LD B,', size: 2 }, // 2-byte instruction 0x0E: { mnemonic: 'LD C,', size: 2 }, // 2-byte instruction 0x76: { mnemonic: 'HALT', size: 1 }, // Add more opcodes as needed};// Sample Z80 binary data (machine code)const binaryData = new Uint8Array([0x3E, 0x12, 0x06, 0x34, 0x00, 0x76]);function disassembleZ80(binary) { let pc = 0; // Program counter while (pc < binary.length) { const opcode = binary[pc]; const instruction = z80Instructions[opcode]; if (!instruction) { console.log(`Unknown opcode: 0x${opcode.toString(16).toUpperCase()}`); pc += 1; continue; } const { mnemonic, size } = instruction; let assemblyLine = mnemonic; // Handle any additional bytes (operands) if (size > 1) { const operand = binary.slice(pc + 1, pc + size); const operandHex = Array.from(operand).map(byte => `0x${byte.toString(16).toUpperCase()}`); assemblyLine += operandHex.join(', '); } console.log(`0x${pc.toString(16).toUpperCase()}: ${assemblyLine}`); pc += size; }}disassembleZ80(binaryData);Recursive DescentRecursive Descent is a more sophisticated disassembly technique than Linear Sweep.Instead of just reading the binary sequentially, it follows the flow of execution by interpreting control flow instructions like jumps and calls.This approach allows it to handle non-linear code paths better and avoid disassembling data that might be interleaved with code.This method is more accurate for complex binaries with non-linear control flow but requires more computational effort.Here’s a simple JavaScript example demonstrating Recursive Descent disassembly for a Z80 CPU.// Simplified Z80 opcode mapconst z80Instructions = { 0x00: { mnemonic: 'NOP', size: 1 }, 0x3E: { mnemonic: 'LD A,', size: 2 }, // 2-byte instruction 0x06: { mnemonic: 'LD B,', size: 2 }, // 2-byte instruction 0x0E: { mnemonic: 'LD C,', size: 2 }, // 2-byte instruction 0xC3: { mnemonic: 'JP', size: 3 }, // Unconditional jump (3 bytes) 0x76: { mnemonic: 'HALT', size: 1 }, // Add more opcodes as needed};// Sample Z80 binary data (machine code)const binaryData = new Uint8Array([0x3E, 0x12, 0xC3, 0x08, 0x00, 0x00, 0x76, 0x00, 0x06, 0x34]);// To keep track of visited addressesconst visitedAddresses = new Set();function disassembleZ80Recursive(binary, pc = 0) { while (pc < binary.length) { if (visitedAddresses.has(pc)) { return; // Already disassembled this part, avoid infinite loops } visitedAddresses.add(pc); const opcode = binary[pc]; const instruction = z80Instructions[opcode]; if (!instruction) { console.log(`Unknown opcode: 0x${opcode.toString(16).toUpperCase()} at address 0x${pc.toString(16).toUpperCase()}`); pc += 1; continue; } const { mnemonic, size } = instruction; let assemblyLine = mnemonic; // Handle any additional bytes (operands) let operands = []; if (size > 1) { operands = binary.slice(pc + 1, pc + size); const operandHex = Array.from(operands).map(byte => `0x${byte.toString(16).toUpperCase()}`); assemblyLine += operandHex.join(', '); } console.log(`0x${pc.toString(16).toUpperCase()}: ${assemblyLine}`); if (opcode === 0xC3) { // JP (unconditional jump) const jumpAddress = operands[1] << 8 | operands[0]; disassembleZ80Recursive(binary, jumpAddress); // Follow the jump return; // Stop linear disassembly and follow the jump } pc += size; }}disassembleZ80Recursive(binaryData);Step 3 - Decoding InstructionsOnce instruction boundaries are identified, the disassembler decodes the opcode and operands.Each opcode corresponds to a specific operation (like MOV, ADD, or JMP), and the operands specify the data or addresses involved in the operation.The disassembler uses a CPU-specific instruction set to interpret the opcodes and operands.For example, the x86 architecture has a different set of opcodes compared to ARM, and the disassembler must know the specific architecture to decode the instructions correctly.Step 4 - Mapping Addresses to SymbolsIf available, the disassembler will map memory addresses to symbolic names (e.g., function names, variable names).This process involves cross-referencing the binary with debugging symbols (if they exist) or creating symbols based on patterns identified in the code.Function SignaturesFor example, common library functions may be recognized by their binary signature, even if symbols are stripped from the binary:Disassemblers can use known function signatures (e.g., common library functions) to identify parts of the code. For instance, a call to a printf function might help the disassembler understand that the following bytes are format strings or arguments.Function Prologue and EpilogueDisassemblers often rely on function prologues and epilogues as key indicators for identifying the boundaries of functions within a binary. These patterns help the disassembler understand where functions start and end, allowing it to organize the disassembled code into coherent blocks. Here’s how disassemblers use these elements:Function PrologueThe prologue is the sequence of instructions at the beginning of a function that prepares the stack and registers for the function’s execution.It typically includes saving the return address, preserving the base pointer (if used), and allocating space on the stack for local variables.Example (x86 Architecture): push ebp ; Save the old base pointer mov ebp, esp ; Set up the new base pointer sub esp, 0x10 ; Allocate 16 bytes of stack space for local variablesFunction EpilogueThe epilogue is the sequence of instructions at the end of a function that cleans up the stack and restores the saved registers. It usually includes restoring the base pointer and the stack pointer, and then returning control to the caller.Example (x86 Architecture): mov esp, ebp ; Restore the stack pointer pop ebp ; Restore the base pointer ret ; Return to the callerHow Disassemblers Use Function Prologue Prologue Signatures: Disassemblers use the common patterns found in function prologues as signatures to identify the start of functions. For instance, in x86 architecture, the sequence push ebp followed by mov ebp, esp is a strong indicator that a function begins at that point. Pattern Matching: The disassembler scans through the binary looking for these common sequences of instructions. When it identifies a prologue, it marks the address as the start of a new function. Heuristics: Some advanced disassemblers use heuristics to deal with variations in prologues. For example, compilers might optimize or slightly modify prologues, so the disassembler uses a combination of pattern matching and heuristics to accurately detect function starts. Dealing with Variations: In cases where code is obfuscated or uses unconventional prologues (e.g., custom calling conventions, hand-optimized assembly), disassemblers might struggle to identify functions based on the prologue alone. In these situations, they might rely on additional information, such as function pointers or jump tables, to infer function boundaries.How Disassemblers Use Function Epilogue Epilogue Patterns: Like prologues, epilogues have typical patterns that disassemblers recognize. The presence of a mov esp, ebp followed by a pop ebp and ret is a strong indicator of the end of a function. Multiple Return Points: Functions can have multiple exit points (e.g., due to early returns), so disassemblers look for any ret instructions within the function and consider them potential function ends. The disassembler might map multiple epilogues to the same function start, recognizing them as different branches of the same function. Verifying Function Boundaries: By detecting epilogues, the disassembler can more accurately delineate where one function ends and another begins. This reduces the risk of incorrectly interpreting code sequences as part of the same function. Control Flow Graph (CFG) Construction: Identifying epilogues helps in constructing accurate control flow graphs, as it allows the disassembler to correctly map out all the possible paths through a function, including all return points. Function Signature Matching: Once a disassembler identifies function prologues and epilogues, it can match these functions against a database of known functions (e.g., from standard libraries). This is helpful in reverse engineering to recognize standard library functions or well-known algorithms. Manual Disassembly and Correction: In interactive disassemblers, users can manually adjust function boundaries if the disassembler’s automatic analysis fails, using their knowledge of prologue and epilogue patterns. Challenges with using Function Prologue and Epilogue Custom Calling Conventions: In some cases, especially in hand-written assembly or highly optimized code, functions may not follow standard prologue/epilogue patterns. Disassemblers must use more sophisticated analysis, such as analyzing control flow or function call patterns, to identify these functions. Optimizations and Inlining: Modern compilers often optimize code in ways that can obscure traditional prologue and epilogue patterns. For instance, a function might be inlined, meaning its code is inserted directly into the calling function without any prologue or epilogue. Disassemblers need to handle these cases carefully, often relying on other indicators to identify function boundaries. Inline Functions: When functions are inlined by the compiler, the typical prologue and epilogue patterns are absent. Disassemblers need to recognize that certain code blocks belong to an inlined function, even if they lack the usual signatures. Tail Call Optimization (TCO): In TCO, the compiler replaces a function’s epilogue with a jump to another function, eliminating the ret instruction. Disassemblers must recognize this pattern to correctly identify the function boundary.Step 5 - Handling Data SectionsIn addition to code, binaries contain data sections that store constants, strings, and other non-executable data.The disassembler must distinguish between code and data sections to avoid misinterpreting data as code. This distinction is critical in producing accurate assembly output.Advanced disassemblers use heuristics and pattern matching to identify common data structures, such as strings, arrays, and tables, ensuring they are correctly interpreted.Heuristics in DisassemblyHeuristics in disassembly refer to the use of rule-based methods and educated guesses to make decisions when the disassembler is not entirely sure about how to interpret a segment of code or data. These heuristics help in: Differentiating Code and Data: In many binaries, code and data are intermixed. Heuristics help determine whether a sequence of bytes represents executable instructions or data. For example, if a segment of bytes doesn’t match known instruction patterns, it might be data. Identifying Data Structures: Heuristics can analyze patterns to identify common data structures, like strings, arrays, or tables, by looking for sequences of bytes that match known characteristics (e.g., null-terminated strings).Pattern Matching for Data StructuresStrings Null-Terminated Strings: Many disassemblers use pattern matching to identify strings by searching for sequences of printable ASCII characters followed by a null byte (0x00). For example, the bytes 0x48 0x65 0x6C 0x6C 0x6F 0x00 can be recognized as the string \"Hello\". Length-Prefixed Strings: Some strings are stored with a length prefix (e.g., Pascal strings). Disassemblers can be programmed to recognize a common length prefix followed by a sequence of characters.Arrays Homogeneous Arrays: An array of integers or floats often appears as a sequence of similarly sized elements. Disassemblers can identify these patterns by looking for repeated sequences of bytes with the same size and spacing. Pattern Recognition: In more advanced scenarios, disassemblers might recognize arrays by the access patterns in the code (e.g., loops that iterate over a sequence of memory addresses).Tables Jump Tables: In compiled code, jump tables are often used for switch-case statements. These are sequences of addresses that the program jumps to based on a value. Disassemblers can identify these by looking for tables of addresses and recognizing the code that accesses them. Function Pointer Tables: Similar to jump tables, function pointer tables are arrays of addresses where each entry points to a function. These are common in object-oriented code (e.g., virtual function tables in C++).Type PropagationSome disassemblers use type propagation, where they infer the type of variables and structures based on how they are used. For example, if a certain memory address is accessed as a string in one part of the code, the disassembler might propagate this type information to other accesses of the same address.Data Structure SignaturesCertain data structures have known memory layouts (e.g., a struct with specific offsets for fields). Disassemblers use these patterns to recognize and label data structures in the binary.User Interaction and Annotations User-Assisted Analysis: Advanced disassemblers like Ghidra and IDA Pro allow users to interactively mark sections of the binary as code or data. They can also allow users to define custom data structures and apply them to memory regions. Annotations and Comments: Users can add comments and annotations that help guide the disassembler in future analysis. For example, if a user recognizes a specific data structure, they can annotate it, and the disassembler may use this information to identify similar structures elsewhere in the binary.Pattern Recognition with AISome cutting-edge disassemblers are beginning to use machine learning models to recognize patterns in binaries. These models can be trained on large datasets of known binaries to improve their ability to recognize data structures and code patterns, even in obfuscated or packed executables.Step 6 - Reconstructing Control FlowDisassemblers often reconstruct the program’s control flow to present a clearer picture of the program’s logic.This involves analyzing jump and call instructions to determine how different parts of the program interact.Some disassemblers can generate control flow graphs (CFGs) that visually represent the paths through the code.Control Flow AnalysisDisassemblers analyze the control flow of the program to understand how different parts of the code are executed. By understanding loops, conditional branches, and jumps, they can predict which areas of the code are likely data and which are executable code.Step 7 - Generating Human-Readable Assembly CodeThe final step is to output the assembly code in a human-readable format.The disassembler converts the decoded instructions, mapped symbols, and reconstructed control flow into assembly code that closely mirrors the original source code (if it were written in assembly).This code can then be reviewed, analyzed, or modified by the user.Dynamic DisassemblersA dynamic disassembler is a type of disassembler that analyzes the machine code of a program during its execution. Unlike static disassemblers, which analyze code without executing it, dynamic disassemblers observe the actual runtime behavior of the program, providing a real-time view of how instructions are executed, which code paths are taken, and how data is manipulated.This approach allows the disassembler to handle dynamic code and provides insights into runtime behavior, like changes in control flow and data.However, it requires running the program, which might be risky if the program is malicious.How Dynamic Disassemblers WorkDynamic disassemblers function by instrumenting the program as it runs. This can be done in several ways: Binary Instrumentation: The disassembler inserts additional code (probes) into the binary to monitor the execution of instructions. This method allows the disassembler to collect data such as which instructions are executed, how often they are run, and how they interact with memory and registers. Emulation: In some cases, dynamic disassemblers use emulation to simulate the execution of the program in a controlled environment. The disassembler steps through the instructions as they would execute on the actual hardware, allowing for detailed observation of the program’s behavior. Debugging Interface: Some dynamic disassemblers leverage the debugging APIs provided by operating systems. By attaching to a running process or launching a program in a debug mode, the disassembler can intercept and analyze instructions as they are executed.Advantages of Dynamic DisassemblersDynamic Disassemblers have the following advantages: Accurate Code Coverage: Dynamic disassemblers provide a precise view of which parts of the code are actually executed. This is particularly useful for identifying which parts of a binary are dead code (never executed) and which are critical paths. Handling Obfuscated Code: Dynamic disassembly is especially effective against obfuscated binaries, where code might be encrypted or packed (compressed) and only revealed at runtime. Since the disassembler observes the code as it executes, it can bypass many obfuscation techniques that would stump a static analysis. Real-Time Data: By observing the program in action, dynamic disassemblers can provide insights into how data flows through the program, what inputs lead to specific outputs, and how memory is allocated and accessed. This real-time analysis is invaluable for understanding complex behaviors like dynamic code generation or self-modifying code. Bypassing Anti-Analysis Techniques: Some binaries include anti-analysis techniques such as anti-debugging or anti-disassembly measures. Dynamic disassemblers can sometimes bypass these defenses by observing the program after these protections have been deactivated or circumvented at runtime.Challenges of Dynamic DisassemblersDynamic Disassemblers have the following challenges: Performance Overhead: Because dynamic disassembly involves running the program and monitoring its behavior, it often incurs significant performance overhead. The process can be much slower than static analysis, especially if instrumentation or emulation is used. Partial Coverage: Dynamic disassembly is dependent on the execution paths taken during analysis. If certain parts of the code are not triggered during the monitored execution, they will not be disassembled. This makes it crucial to ensure comprehensive coverage during analysis, which can be challenging. Complex Setup: Setting up a dynamic disassembler can be more complex than using a static disassembler. It often requires a controlled environment, such as a sandbox, and careful management of the execution context to avoid unwanted side effects.Tools for Dynamic DisassemblySeveral tools offer dynamic disassembly capabilities, often integrating these features with other forms of analysis: Intel PIN: A dynamic binary instrumentation framework that allows users to write custom tools (called “pintools”) to analyze programs as they run. DynamoRIO: Another dynamic instrumentation framework similar to PIN, allowing for the creation of custom analysis tools. OllyDbg: A popular debugger with dynamic analysis capabilities, commonly used for reverse engineering. Ghidra: While primarily a static disassembler, Ghidra can be integrated with dynamic analysis tools and debuggers to provide dynamic disassembly capabilities. QEMU: An open-source processor emulator that can be used for dynamic analysis by simulating the execution of binaries on various CPU architectures.Interactive DisassemblersInteractive disassemblers are tools that allow users to engage directly with the disassembly process, offering a blend of automatic disassembly with extensive user control and customization.Tools like Ghidra and IDA Pro fall into this category. They combine static and dynamic disassembly features, allowing users to interactively explore the code, modify the disassembly, and even execute the code in a controlled environment.What is an Interactive Disassembler?An interactive disassembler is a software tool that converts machine code (binary) into human-readable assembly code and allows the user to interact with and manipulate the disassembly. Unlike purely static disassemblers that automatically generate an assembly listing without much user intervention, interactive disassemblers provide users with the ability to: Correct disassembly errors. Annotate and comment on the disassembled code. Explore different execution paths and data flows. Rename functions, variables, and labels for better understanding. Analyze and modify the binary more effectively by applying personal insights.Key Features of Interactive DisassemblersInteractive Code Exploration Control Flow Graphs (CFGs): Interactive disassemblers often generate visual representations of a program’s control flow, showing how different functions and loops interact. Users can click on different nodes and edges to explore these paths more thoroughly. Jump and Call References: Users can easily see where functions are called from or where jump instructions lead, making it easier to trace the flow of execution.Manual Adjustments Marking Code and Data: Users can manually specify whether a section of the binary is code or data, which is particularly useful in binaries where the boundaries between code and data are not clear. Renaming and Commenting: Functions, variables, and memory locations can be renamed to more meaningful names, and users can add comments to help document the disassembly. Defining Data Structures: Users can define and apply custom data structures to areas of memory, improving the clarity of complex data segments.Scripting and Automation Scripting Support: Many interactive disassemblers support scripting languages like Python or JavaScript, allowing users to automate repetitive tasks, write custom analyses, or extend the functionality of the disassembler. Macros and Plugins: Users can create or import plugins and macros to add new features, such as custom decoders for specific binary formats or automated analysis routines.Cross-ReferencingUsers can quickly identify all the places where a specific function or variable is used, aiding in understanding dependencies and interactions within the code.Advantages of Interactive DisassemblersThe main advantages of Interactive Disassemblers over static and dynamic are: Precision and Flexibility: Users have the power to correct inaccuracies and fine-tune the disassembly, resulting in a more accurate and understandable output. Comprehensive Analysis: By manually exploring different parts of the binary, users can uncover hidden or obfuscated code that might be missed by automated disassembly.Challenges of Interactive Disassemblers Steeper Learning Curve: The extensive features and capabilities can be overwhelming for beginners. Understanding how to effectively use all the tools requires time and experience. Manual Effort: While automation is possible, interactive disassemblers often require significant manual input, especially when dealing with large and complex binaries. Cost: Some of the most powerful interactive disassemblers can be expensive, although there are free and open-source options available.Popular Interactive DisassemblersIDA Pro IDA Pro (Interactive DisAssembler) is one of the most well-known and widely used interactive disassemblers. It supports a vast array of processors and file formats and is renowned for its extensive feature set, including a powerful decompiler, scripting support, and an active plugin community. Features: IDA Pro offers interactive graph views, scripting with IDC, Python, and other languages, and a rich plugin ecosystem that extends its capabilities.Ghidra Ghidra is a free and open-source interactive disassembler developed by the NSA. It offers many of the features found in IDA Pro, including decompilation, scripting, and interactive code exploration. Features: Ghidra is known for its collaborative features, allowing multiple users to work on the same project simultaneously. It also has a user-friendly GUI and supports a wide range of architectures.Radare2 (r2) Radare2 is an open-source framework for reverse engineering that includes an interactive disassembler, among many other tools. It’s highly customizable and scriptable, but it has a steeper learning curve than some other tools. Features: Radare2 is known for its command-line interface, extensive scripting capabilities, and support for many file formats and architectures.Binary Ninja Binary Ninja is another interactive disassembler that focuses on providing a modern, user-friendly interface with powerful analysis features. It is designed to be both accessible to beginners and powerful for advanced users. Features: Binary Ninja offers a highly interactive and customizable interface, with strong support for Python scripting and plugins.", "excerpt": "Understanding How Disassemblers Work: A Deep Dive In the world of retro gaming, reverse engineering, and software development, disassemblers are essential tools. They provide a bridge between binary code and human-readable assembly language, allowing developers and enthusiasts to analyze and understand software at a fundamental level. This post delves into...", "tags": ["disassemblers","tools","software"], "image": "/public/generated/placeholders/disassemblers.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Sega Dreamcast", "url": "/dreamcast", "content": "Introduction to Hacking/Reversing the SEGA DreamcastWelcome to our page dedicated to SEGA Dreamcast reverse engineering! The SEGA Dreamcast was a beloved gaming console that was first released in 1998, and has since gained a cult following among retro gaming enthusiasts.If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to the right place. On this page, we’ve compiled a list of links to other pages that cover various topics related to SEGA Dreamcast reverse engineering.Whether you’re interested in understanding the hardware architecture of the console, analyzing game code, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to.So grab your VMU, fire up your Dreamcast, and get ready to dive into the exciting world of SEGA Dreamcast reverse engineering!History of Dreamcast HackingNeperos hosts an article (originally from Retro Revival magazine) that chronicles the rise of the Sega Dreamcast homebrew scene. The piece details how the “MIL-CD” exploit and the release of the Utopia Boot Disc bypassed the console’s copy protection, paving the way for homebrew development tools like KallistiOS and the porting of emulators and media players such as DCDivX and ScummVM. History of Dreamcast Homebrew A retrospective on the technical origins of the Dreamcast homebrew scene, covering the discovery of the MIL-CD backdoor, the release of the Utopia bootloader, and the evolution of open-source development kits. Bleemcasting: An Interview With Bleemcast! Developer Randy LindenThe Dreamcast Junkyard speaks with Randy Linden, the core developer behind the Bleemcast! emulator. The interview covers the technical challenges of porting the PC emulator to the Dreamcast’s SH-4 architecture, the reverse engineering of the MIL-CD format to bypass Sega’s licensing, and the history behind the unreleased “BleemPod” hardware. Bleemcasting: Interview With Randy Linden Randy Linden shares insights into the development of Bleemcast!, discussing the low-level optimizations required for the Dreamcast hardware, the legal pressures from Sony, and the unreleased peripherals intended for the system. How the Dreamcast’s Security was Hacked (MIL-CD)This article debunks the common myth that the Dreamcast lacked security, explaining instead how the “MIL-CD” format-intended for interactive music albums-became the system’s Achilles’ heel. We detail how hackers exploited this oversight to bypass GD-ROM authenticity checks, allowing modified game ISOs to run on standard CD-Rs despite the console’s built-in copy protection mechanisms. How the Dreamcast’s Security was Hacked (MIL-CD) History of Dreamcast Hacking Neperos hosts an article (originally from Retro Revival magazine) that chronicles the rise of the Sega Dreamcast homebrew scene. The piece details how the “MIL-CD” exploit... HardwareIf you’re keen on reverse engineering SEGA Dreamcast games, it’s crucial to possess a strong comprehension of the hardware that fuels the gaming console. This knowledge will aid in understanding how the software interacts with the hardware and how you can potentially modify or enhance it.This segment of our guide furnishes you with comprehensive insights and resources on SEGA Dreamcast hardware, encompassing retail, prototype, and development hardware.Retail Hardware ArchitectureCopetti presents a comprehensive “practical analysis” of the Sega Dreamcast’s internal architecture, authored by Rodrigo Copetti. The article provides a deep technical breakdown of the system’s components, including the Hitachi SH-4 CPU’s superscalar pipeline, the PowerVR2’s tile-based deferred rendering GPU, and the AICA sound processor, while also discussing the “MIL-CD” backdoor that enabled the homebrew and piracy scene. Dreamcast Architecture | A Practical Analysis Rodrigo Copetti examines the technical design of the Sega Dreamcast, detailing the SH-4 CPU, PowerVR2 GPU, and AICA audio system, alongside an analysis of the console's memory management and anti-piracy flaws. Development HardwareThe Dreamcast arguably had the best development kit that SEGA had ever sold for their consoles, it is just a shame the lifespan of the Dreamcast was cut short. Sega Dreamcast Katana Development Kit Hardware For information about SEGA’s Dreamcast development hardware check out this post. Unofficial HardwareTreamcast - Chinese Pirate Sega Dreamcast System OverviewAdam Koralik reviews the “Treamcast,” an unauthorized portable clone of the Sega Dreamcast manufactured in China in 2003. The overview highlights the system’s built-in LCD screen, internal region-free modification, and peculiar hardware quirks, such as the need to manually spin the disc to initiate reading.Game Software DevelopmentOfficial Dreamcast Windows CE SDK Sega Dreamcast Microsoft Windows CE SDK For information about SEGA’s Dreamcast Windows CE SDK check out this post. GD Workshop GD Workshop (GD-R Burner/Virtualiser) For information about the Dreamcast GD Workshop check out this post. GamesChicken RunThe full source code for the Dreamcast port of Chicken Run was released and we have a separate post covering the code: Chicken Run Source Code For information about Chicken Run source code check out this post. Official Retail Dreamcast Game Source CodeIf you are interested in officially released or leaked source code for the Dreamcast check out our other post: Retail Console Game Source code (C/C++) For the official source code check out this post. Dreamcast games with Debug Symbols Sega Dreamcast Games with Debug Symbols For a list of dreamcast games with debug symbols check out this post. Games exclusive to the DreamcastWikipedia maintains a list of Dreamcast exclusives - Dreamcast-only games - WikipediaReverse EngineeringReverse Engineering Ecco the Dolphin with GhidraThere is an excellent article by Rings of Saturn on reverse engineering Ecco the Dolphin for the Dreamcast, specifically how the cheat codes work via save names:Under the microscope: Ecco the Dolphin - Defender of the FutureCastlevania: Resurrection Dreamcast Reverse EngineeringSega Dreamcast Info provides a deep dive into the reverse engineering of the unreleased Castlevania: Resurrection E3 1999 prototype. The write-up details the discovery of plain text scripting for AI and level data, the extraction of hidden assets like music and textures, and the technical work required to create playable GDI and CDI images for modern hardware. Castlevania: Resurrection Reverse Engineering Sega Dreamcast Info analyzes the unreleased Castlevania: Resurrection prototype, breaking down its script-based engine, file formats, and the process of making the E3 demo playable on retail consoles. Agartha Dreamcast Reverse EngineeringSega Dreamcast Info details the extensive reverse engineering efforts behind Agartha, an unreleased survival horror game by No Cliché. The write-up explains the technical analysis of the proprietary AGARTHA.PAK file structure, the extraction of hidden assets like the 15-minute video and script files, and the methods used to re-enable debug menus and free camera modes to make the prototypes playable. Agartha Dreamcast Reverse Engineering Sega Dreamcast Info breaks down the unreleased Agartha prototype, covering the file system analysis, asset extraction, and the technical restoration that allows users to explore the unfinished world of this cancelled survival horror title. All Posts tagged with Dreamcast Chicken Run Source Code Developed by Blitz Games (formerly known as Interactive Studios Limited) in 2000 as a cross platform action adventure game based on the movie with the same name. Throughout the engine... ... Read More dreamcast ps1 pc games sourcecode GD Workshop (GD-R Burner/Virtualiser) GD Workshop was developed by CrossProducts as a tool to not only burn GD-Rs but also to create virtual GDROM images for use on the DEV.BOX development hardware. Running GD... ... Read More sega dreamcast sdk Sega Dreamcast Games with Debug Symbols Debug symbols pretty much open a game wide open to budding verse engineers. These files make reverse engineering almost a piece of cake, giving useful names to each of the... ... Read More sega dreamcast symbols debug Sega Dreamcast Microsoft Windows CE SDK Originally called the Dragon SDK and planned to be the full Operating System (OS) of the dreamcast. However SEGA decided to go with their own limited BIOS with the Dreamcast... ... Read More sega dreamcast sdk How the Dreamcast's Security was Hacked (MIL-CD) History of Dreamcast Hacking Neperos hosts an article (originally from Retro Revival magazine) that chronicles the rise of the Sega Dreamcast homebrew scene. The piece details how the “MIL-CD” exploit... ... Read More dreamcast hardware cracking sega Sega Dreamcast Katana Development Kit Hardware Official Sega Development hardware In Sega’s internal model numbering system for the Dreamcast, the prefix “HKT” is consistently used across various hardware components and peripherals. While the exact meaning of... ... Read More dreamcast hardware devkit sega ", "excerpt": "Introduction to Hacking/Reversing the SEGA Dreamcast Welcome to our page dedicated to SEGA Dreamcast reverse engineering! The SEGA Dreamcast was a beloved gaming console that was first released in 1998, and has since gained a cult following among retro gaming enthusiasts. If you’re interested in learning more about the technical...", "tags": ["dreamcast"], "image": "/public/generated/placeholders/dreamcast.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "GD Workshop (GD-R Burner/Virtualiser)", "url": "/sega-dreamcast-gd-workshop", "content": " GD Workshop was developed by CrossProducts as a tool to not only burn GD-Rs but also to create virtual GDROM images for use on the DEV.BOX development hardware. Running GD WorkshopAlthough the Katana development kit Dev.BOX is basically a windows PC with a GD-ROM drive, it cannot run on standard PCs without being patched.Burning GD-RsIt normally takes around 1-hour to burn a physical GD-R disc so this wasn’t a quick process. So an alternative is to Emulate the GD-ROM disc so it can be booted straight away.GD Workshop InterfaceGD Workshop is a fairly simple program with an interface similar to old fashioned CD-burning software. You chose what data will go where on the disc image, the only difference is that there are 2 ‘sessions’ on a GD-ROM disc, known as the High and Low density sessions.GD-ROM ContentsIt is important to put the correct content on the correct session otherwise not only will the game not be optimised it will not be able to find the main bootable piece of code.This section will briefly cover the main areas of a GD-ROM which is important for proper use of the GD Workshop to burn a bootable GD-R.Session 1 (Low Density)The first session is the lowest density area of the GD-ROM disc.CDDA TracksRaw Audio files where each file is its own audio track. These tracks can be played if you pop your dreamcast disc into a normal CD Player.Mode1 TracksSome Game information is on this track, but it is more like a table of contents of the game information on the other Session of the disc.If you place your GD-ROM disc into the PC you will see the following files, which makes it look like the start of an acacemic paper: Bibliogr.txt Abstract.txt Copyrigh.txtSession 2 (High Density)The second session is the High Density area of the GD-ROM disc. This tends to contain 2 Mode1 Data tracks of game information, a buffer track and at least one CDDA Audio track.Session 2- Mode1 tracksTwo Mode-1 tracks are present in the high density region of the disc (known as session 2), these contain all the game information including the executables and assets used to play the game.The last Mode1 Track is the outermost ring of the physical GD-ROM disc and it contains the main game executable (1st_read.bin).IP.BIN and IP0000.BINIt also contains IP.BIN/IP0000.BIN which need to be the first file loading by the dreamcast. These files are customised for each game and contains information such as the game name, version and the file name of the game executable which is normally 1st_read.bin.Session 2 - CDDA TracksAdditional CDDA Audio tracks can be placed in Session 2 but they will not be played by a CD-player.Playing Burned GD-RsYou need the System Disc 2 to play a burned GD-R, which you would put in your Dreamcast before your game then switch it out with your GD-R. Sega Dreamcast Katana Development Kit Hardware You can find out about the System Disc 2 in this main katana development kit post. ", "excerpt": "GD Workshop was developed by CrossProducts as a tool to not only burn GD-Rs but also to create virtual GDROM images for use on the DEV.BOX development hardware. Running GD Workshop Although the Katana development kit Dev.BOX is basically a windows PC with a GD-ROM drive, it cannot run on...", "tags": ["sega","dreamcast","sdk"], "image": "/public/images/dreamcast/Dreamcast-GD-Workshop.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Sega Dreamcast Games with Debug Symbols", "url": "/sega-dreamcast-game-debug-symbols", "content": " Debug symbols pretty much open a game wide open to budding verse engineers. These files make reverse engineering almost a piece of cake, giving useful names to each of the functions in an executable and sometimes even full local variable naming and source code references. However most developers are very careful not to leak any debug symbols, especially into retail releases, so most games will not have publicly available debug symbols. But if you look very hard you might be able to find a game or two compiled for a console that have debug symbols left in by mistake. The Dreamcast is no different, although unlike the Sega Saturn before it, the games that have symbols are much harder to find and very rare. Also it is further complicated due to the fact that there were actually two official Software Development Kits (SDKs) available for the dreamcast. One was the standard Katana SDK that used custom libraries written by Sega and the other was the Windows CE SDK written by Microsoft with added dreamcast functions. The Windows CE SDK was built to make porting from PC to dreamcast easier but required the game to ship with Windows CE libraries and to be compiled by the Microsoft C Compiler/Assembler suite. PDB files for WinCE executablesThe debug symbols for games using the WinCE SDK tend to be put in Program Database files (.PDB) and are external to the game executable. Sadly very few games shipped with these full PDB files in tact on the retail disc, but there are a few games that accidentally contained some incomplete PDB files.Although these PDB files don’t cover the entire source code for the games it can be a useful start when reversing one of these games.Taxi 2 - Le JeuThe french game Taxi 2 contained the PDB files for all the libraries provided by the WindowsCE runtime environment for dreamcast. Also of note is that the NTSC release of Armada also contained the PDB files for the same libraries but they have different MD5 hashes so likely from different versions of the Windows CE runtime environment. Sega Dreamcast Microsoft Windows CE SDK For the full list of PDB files found in Taxi 2 click here. However it doesn’t seem to have the actual .pdb file from the Taxi2 game itself sadly.Unstripped ELF filesUnstripped ELF files are a rare gem, very rare and they pretty much crack the game wide open with their debug symbols.Very few dreamcast games included the ELF executable on the retail disc, only one game has been found which is the Dragons Blood in Europe.It is believed that this would be compiled with the GNU toolchain provided with the Dreamcast SDK but this has not been confirmed.Normally dreamcast executables are converted from ELF to BIN before being put on GD-ROM so this must have been a mistake and is not actually used by the game.Dragons Blood (European version of Draconus: Cult of the Wyrm)Dragons Blood contains a very useful file left over on its disc: RELEASE.ELF, this is a valid ELF executable that is a fairly large 13.8MB. Executables that just contains code are not normally this large.The output of running the file command on the RELEASE.ELF file is:RELEASE.ELF: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), statically linked, not strippedNot that it says ‘not stripped’, this is excellent news it means that all the function names are intact inside the ELF file and can be viewed using your favourite reverse engineering tool (Radare2, Binary Ninja, IDA Pro etc).There are a total of 7,735 debug symbols in the executable.A post specifically investigating this game will come in the near future.Judging by the symbols the game was written in C++ so it must have used the GNU C++ compiler as the Hitachi compilers were only C-based.South Park Rally v1.001 (2000)(Acclaim)(NTSC)(US)This game includes a file called CDIMAGE.ELF but it does not seem to be a valid ELF executable and it doesn’t contain debug symbols as far as I can tell.Linker .map filesDuring the build process for games the source code gets compiled and then linked into a final executable, in the dreamcast case it becomes the 1st_read.bin.In order to help developers debug their games when they have been fully compiled the assembler generated a .map file that contains the function names and their location in the final executable.Normally these files would remain on the development kits and not appear on the final retail discs, however there are a couple of cases where these files were accidentally put on the retail game disc. The most notable being NFL 2K Japanese version which contained full debug symbols!NFL 2K v1.002 (JP)In the original Japanese version of NFL 2K for the Sega Dreamcast, the Linker Map file is included on the disc by mistake. It was removed in the further versions of the Japanese release and the US/PAL releases.The MAP file contains all the function names and even the original source file names (the compiled .obj version).Urban Chaos v1.000 (WindowsCE)The Urban Chaos disc contains a file called NKSCIFKD.MAP which is a linker map file for a Windows CE executable also called NKSCIFKD.EXE. But it is not very useful in terms of reversing the game itself.Armada v1.000 (US) (WindowsCE)The US version of Armada contains the linker map file for the WSEGACD windows CE library. You can find out more about this library in our post about the Windows CE SDK. Sega Dreamcast Microsoft Windows CE SDK For the full list of Dreamcase Windows CE libraries check out this post. The Next Tetris (WindowsCE)The online edition of ‘The Next Tetris’ was built using the Dreamcast Windows CE SDK and has accidentally placed 2 windowsCE libraries on the retail disc: CHATCE.LIB (Chat library for windowsCE) SOUNDLIBWCE.LIB (Sound library for windowsCE)These are the files that are used during the build process to create the final executable and they have the function names inside and can technically be used and linked into your own games if you need a chat or sound library. It would be interesting to find out the differences between this sound library and the one that comes with the Windows CE SDK.Rune Jade v1.027 (JP) (WIndowsCE)The Japanese only online role playing game Rune Jade has a few linker map files for their windows CE online networking engine called IWNETENGINE. The rest of the game does not contain any debug symbols.Games with Uncompiled ScriptingResident Evil 3/ Biohazard 3The dreamcast version of Resident Evil 3 is unique in that it contains a folder of uncompiled BioScript files. The scripting language is very similar to C, including header files and they have the extension .SCT.These can be modified to easily make mods for the game, you can find out more about Resident Evil Modding here: Resident Evil 3 (1999) - Resident Evil 1 2 3 - Modding ForumOther interesting contentMarionette CompanyThe following strings inside the Marionette Company main executable suggests that the Windows CE SDK for dreamcast was called dragon, and this is confirmed by the SegaRetro wiki 1. d:\\dragon11\\platform\\KATANA\\target\\SHx\\SH4\\CE\\retail\\segamidi.dlld:\\dragon11\\platform\\KATANA\\target\\SHx\\SH4\\CE\\retail\\segamidi.pdbThis shows that they were using version 1.1 of the windows CE (i.e “Dragon”) SDK.This also confirms that there was a SegaMidi dynamic library (.dll) that came as part of the Dreamcast version of the WindowsCE SDK.Makefile in Prince of Persia Arabian NightsA full Makefile is available on the retail US release of the game Prince of Persia Arabian Nights. It seems to use the tool k2atosom to convert *.dm to *.cm using .lst files.It is unknown what LevelRIP tool is, could be an internal tool.#----- File generated by LEVELRIP -----DISP_OPTIONS = -NOSORT -ONETEX -NOMERGE -SLIGHTS 0.100000%.dm: %.k2a k2atosom $*.k2a $(DISP_OPTIONS) -OFILE $*.dm -MTF rooftex.lstCOLL_OPTIONS = -NOSORT -NOTEX -NOMERGE %.cm: %.k2a k2atosom $*.k2a $(COLL_OPTIONS) -LFILE $*.lst -OFILE $*.cm roof.wld: roof1_1a.dm \\roof1_1b.dm \\roof1_1c.dm \\roof1_1d.dm \\roof1_1e.dm \\roof1_1f.dm \\roof1_1g.dm \\roof1_1h.dm \\roof1_1i.dm \\roof1_1j.dm \\roof1_2a.dm \\roof1_2b.dm \\roof1_2c.dm \\roof1_2d.dm \\roof1_2e.dm \\roof1_3a.dm \\roof1_3b.dm \\roof1_3c.dm \\roof1_3d.dm \\roof1_3e.dm \\roof1_3f.dm \\roof1_3g.dm \\roof1_4a.dm \\roof1_4b.dm \\roof1_4c.dm \\roof1_4d.dm \\roof1_4e.dm \\roof1_5a.dm \\roof1_5b.dm \\roof1_5b1.dm \\roof1_5c.dm \\roof1_5d.dm \\roof1_5e.dm \\roof1_5f.dm \\roof1_6a.dm \\roof1_6b.dm \\roof1_6c.dm \\roof1_6d.dm \\roof1_7a.dm \\roof1_7b.dm \\roof1_7c.dm \\roof1_7d.dm \\roof1_7e.dm \\roof1_8.dm \\roof1_9a.dm \\roof1_9b.dm \\roof1_9c.dm \\roof1_10.dm \\RoofSkybox.dm Largest Dreamcast ExecutablesNormally the largest executables for a given console tend to contain the most debug information, unfortunately due to the high use of external debug symbol files, the dreamcast executables tend to be quite small and lacking in symbols.This section will list the largest executables but sadly none of them seem to contain debug symbols as far as we can see, this is just hear for those curious about the laegest dreamcast executables.Largest Katana 1st_read.bin executableThe largest game compiled with the standard (non-winCE) SDK was Street Fighter III - 3rd Strike at 14.3MB with Toy Story 2 - Buzz Lightyear to the Rescue at 13.6MB coming in second.Looking at the size of the executables you would be excused for presuming that these would contain debug symbols. But no, well as far as we can tell it just includes code. Thats a lot of code!Largest WindowsCE ExecutableSadly all the Windows CE Dreamcast games were built with an external debug symbol file (.PDB).So the largest Windows CE game comes in at only 3.8MB which is ‘SPACESTATION.EXE’ from “Historical Mystery Adventure TROIA 1186 B.C. v1.002 (JP)” or more bizarley the pool game “Jimmy White’s 2 - Cueball v1.100 (1999)(Virgin)(PAL)”.Games smaller than that are unlikely to contain debug symbols as they tend to be stored as uncompressed strings and dreamcast development tended to include a lot of symbols with long names which add up to MBs of symbols.References History of the Sega Dreamcast/Development - Sega Retro ↩ ", "excerpt": "Debug symbols pretty much open a game wide open to budding verse engineers. These files make reverse engineering almost a piece of cake, giving useful names to each of the functions in an executable and sometimes even full local variable naming and source code references. However most developers are very...", "tags": ["sega","dreamcast","symbols","debug"], "image": "/public/images/dreamcast/Dreamcast-Games-With-Debug-Symbols.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Sega Dreamcast Microsoft Windows CE SDK", "url": "/dreamcast-windows-ce", "content": " Originally called the Dragon SDK and planned to be the full Operating System (OS) of the dreamcast. However SEGA decided to go with their own limited BIOS with the Dreamcast instead of a fully functional OS. So to use WindowsCE on the Dreamcast game developers would have to bundle the entire Windows CE OS on the game disc 1. This means that in order to run the game the dreamcast would first boot into the file 0WINCEOS.BIN on the GD-ROM disc and then it would load the game. This had a performance impact, reducing the resources the developers would have for the game, so lower memory, longer loading times and less performance for the actual game. So why would developers use the Windows CE SDK instead of the more powerful Katana SDK? The answer mainly comes down to the ease of porting PC games to the platform and the developers can use their prior windows knowledge instead of learning a completely new platform from scratch 2. This reduces development cost as much of the code from the PC version could be used with some modification and it would take less developer time to learn the Application programming Interfaces (API). So it was a trade-off that worked for less performance demanding games as they could be developed much quicker from a PC port 2. One example of a studio doing just that is a presentation from D. Michael Traub from Acclaim on porting the Quagmire engine to the Dreamcast, they used the WinCE SDK to port to the dreamcast and they found that it worked very well, claiming that it only took a month to port the engine thanks to the SDK. Porting issues from PC to DCEven although the Windows CE SDK’s main focus is to make it easy to port your game from Standard windows Direct X over to embedded platforms such as the Dreamcast, there were a few important compatibility issues that developers needed to take into account when porting their games.Windows CE is Unicode only, so the game needs to be changed from ASCII.Executable formatUnlike the standard Katana SDK the game executables for dreamcast windows CE were actually in PE executable format. The game executable could be called anything with a .EXE extension but many games simply call it GAME.EXE which may have been the default.These executable files are able to be opened in IDA Pro and radare2 for reverse engineering but most don’t contain any debug symbols. Sega Dreamcast Games with Debug Symbols For games with debug symbols check out this post. Tools ProvidedThe Windows CE SDK for dreamcast came with a tools folder which contains a few GUI-based programs for developers to help debug and optimise their games.GD Workshop GD Workshop (GD-R Burner/Virtualiser) For information about GD Workshop check out this post. Dreamcast Tool (dctool.exe) The dreamcast Tool is a useful program to connect from a PC to a dreamcast development system allowing you to do tasks such as boot an executable image, run Dtrace, show textures etc. Dreamcast Trace Tool (Dtrace) (dtview.exe)DreamcastTrace or DTrace is a performance monitoring tool to allow developers to optimise their games to be as efficient as possible. It is unrelated to the well-known standard DTrace tool by Sun Microsystems.Image Configuration Tool (config.exe) Unlike its name it does not relate to graphic images, instead it refers to Operating system images. This allows you to configure which modules will be included in your games version of the Windows CE Operating system. IP Maker Tool (ipmaker.exe)This is a tool for creating the boot loader for the disc (IP) called ip_drago.bin since the codename for the Win CE SDK is dragon.You give it the name of your main game executable (*.exe) and it will run that on playing the GD-ROM disc in a dreamcast.Profiler Tool (profcvt.exe)The profiler is a tool to debug performance issues in your game executable’s functions. This tool is vital to make a playable dreamcast game that also pushes the hardware limits without going below 30fps.Synthesizer Author Tool (SynthAuthor) (synthauthor.exe) The Synthesizer Author Tool is a program for sounds engineers to create a collection of instruments for use in the game music. Windows Debugger Tool (Windbg.exe)This is a standard source-level debugger supporting breakpoint and variable value watching.Also the file NknoDbg.exe is on the retail disc of a few retail games such as Sega Rally 2. But it is unconfirmed what this executable is and how it differs from the standard Windbg.exe tool.Utilities ProvidedThe Utilities differ from the tools as they all tend to be Command Line oriented and would normally be scripted and used as part of a automated build process.Audio UtilitiesThe following are tools used by sound engineers to convert between sound formats for use on the Dreamcast.DLS to Dreamcast ToneBank Converter Utility(dls2tb.exe)Converts .DLS files to the dreamcast specific .TB (Tonebank) files format.DLS to Sega ToneBank Converter Utility (dls2dcs.exe) What is the difference between this and the .TB converter?Wave Converter Utility (wavcon.exe) (Audio)Converts 16-bit PCM wave files to 4-bit ADPCM files for playing on the dreamcast.Debugging UtilitiesCheck RES Utility (checkres.exe)Check resource files to look for duplicates or problems with resource files.Debug Adapter Check (dacheck.exe)Used to debug connection issues with the debug adapter.Dump Register Utility (dumpreg.exe)Used for debugging it transfers the dreamcast CPU registers to your PC for debugging low-level assembly code.Profile Conversion Utility (profcvt.exe)This tool is used for converting the output of the function profiler tool into a human-readable text file.Windows CE OS Image Management UtilitiesMake Image Utility (makeimg.exe)A command line version of the image config tool, it allows you to build an Windows CE OS image and choose which modules are included.ROM Image Builder Utility (romimage.exe) Not sure the difference between this and makeimg.exeRegistry Compression Utility (regcomp.exe)Just like standard Windows on the Desktop, windowsCE also includes a Registry to save keys and values.This tool converts the human readable and easily editable ini file RegInit.ini into the compressed Default.fdf which is placed inside the WinCE OS image.Other UtilitiesBinary Generator Utility (bingen.exe) (CLI)Command line utility to convert an executable into a binary file. Seems to take a language in as a parameter, not sure why.Dreamcast Copy (dccopy.exe)This utility is simply a convenient tool to copy the newly built executable from the Build directory into the Release directory.Dump NK Utility (dumpnk.exe)This file dumps NK-ROM image files to a binary file. But what is a NK-ROM file?Flash Utility (flash.exe)Use this tool to upgrade the firmware of the Dreamcast development DEV.BOX.File Merge Utility (fmerge.exe)Moves configuration files to multiple directories, not sure the purpose.Mycat Utility (mycat.exe)Seems to concatinate some binary files to StandardOut and strips out some data but not sure the purpose.NLS Compression Utility (cenlscmp.exe) What is Natural Language Support Compression?PowerVR Converter Utility (prconv.exe) (CLI)Rebaseic Utility (rebaseic.exe)Removes duplicate icons from resource (.RES) files.Resource to Executable Utility (res2exe.exe)Text to Unicode Utility (txt2ucde.exe)Since windows CE only supports Unicode strings, for PC ports ASCII would need to be converted to Unicode which is where this utility comes in useful.Txt2vmi Utility (txt2vmi.exe)Converts VMU text files to VMI images.VC5 to VC6 Converter Utility (vc5tovc6.exe)Simply converts Visual C++ 5.0 projects to Visual C++ 6.0 project files.LibrariesDebugMem Tool (DEBUGMEM.LIB)The DebugMem tool is actually a library and programming interface that developers use to debug memory issues such as memory leaks.Games that were built for WindowsCEYou can find out if your favourite game was built using the Windows CE SDK by inserting the disc and looking for the file 0WINCEOS.BIN in the root of the GD-ROM.Here is A list of Windows CE games that I have found so far: Game Additional Notes 4X4 EVO v1.001 (2000)(GOD)(NTSC)(US)   Armada v1.000 (1999)(Metro3D)(NTSC)(US)   Atari Anniversary Edition v1.001 (2001)(Infogrames)(NTSC)(US)   Biohazard 2 Value Plus v1.005 (1999)(Capcom)(NTSC)(JP)(en)   Bust-A-Move 4 v1.001 (2000)(Acclaim)(NTSC)(US)   Bust-A-Move 4 v1.001 (2000)(Acclaim)(PAL)   Caesars Palace 2000 - Millennium Gold Edition v1.000 (2000)(Interplay)(PAL)   Caesars Palace 2000 - Millennium Gold Edition v1.011 (2000)(Interplay)(NTSC)(US)   Championship Surfer v1.002 (2000)(Mattel)(NTSC)(US)   Championship Surfer v1.002 (2001)(GAME Studios)(PAL)(M5)   Ducati World - Racing Challenge v1.000 (2001)(Acclaim)(NTSC)(US)   Ducati World v1.001 (2001)(Acclaim)(PAL)(M4)   For Symphony - With all one’s Heart v0.800 (2003)(Takuyo)(NTSC)(JP)   GET!! Colonies v1.000 (2000)(Sega)(NTSC)(JP)   GK - Giant Killers v1.400 (2001)(AAA Game)(PAL)   Happy Lesson v1.002 (2001)(Datam Polystar)(NTSC)(JP)   Hello Kitty - Lovely Fruit Park v1.004 (1999)(Sega)(NTSC)(JP)   Hello Kitty - Magical Block v1.001 (2000)(Sega)(NTSC)(JP)   Hidden & Dangerous v1.001 (2000)(Take 2)(PAL)(M4)   Hidden & Dangerous v1.100 (2000)(Take 2)(NTSC)(US)   Historical Mystery Adventure TROIA 1186 B.C. v1.002 (1999)(Hitachi - TBS)(NTSC)(JP)   Hoyle Casino v1.001 (2000)(Sierra)(NTSC)(US)   Hundred Swords v1.005 (2000)(Sega)(NTSC)(JP)   Jimmy White’s 2 - Cueball v1.100 (1999)(Virgin)(PAL)   Kaitou Apricot v1.006 (2003)(Takuyo)(NTSC)(JP)   KISS Psycho Circus - The Nightmare Child v1.000 (2000)(Take 2)(NTSC)(US)   KISS Psycho Circus - The Nightmare Child v1.100 (2000)(Take 2)(PAL)(M3)   Kita He - White Illumination v2.002 (1999)(Hudson)(NTSC)(JP)   Kitahei Gold v1.007 (1999)(Net Village)(NTSC)(JP)   Marionette Company 2 v1.001 (2000)(Microcabin)(NTSC)(JP)   Marionette Company v1.001 (1999)(Microcabin)(NTSC)(JP)   Maximum Pool v1.004 (2000)(Sierra)(NTSC)(US)   Midway’s Greatest Arcade Hits Volume 1 v1.000 (2000)(Midway)(PAL)   Midway’s Greatest Arcade Hits Volume 1 v1.001 (2000)(Midway)(NTSC)(US)   Midway’s Greatest Arcade Hits Volume 2 v1.001 (2001)(Midway)(NTSC)(US)   Miss Moonlight v1.006 (2001)(Naxat)(NTSC)(JP)   Morita no Saikyou Reversi v1.003 (1999)(Random House)(NTSC)(JP)   Morita no Saikyou Shougi v1.003 (1999)(Random House)(NTSC)(JP)   Net De Para v1.007 (2000)(Takyuo)(NTSC)(JP)   Next Tetris, The - On-line Edition v1.100 (2000)(Crave)(NTSC)(US)   Next Tetris, The v1.003 (2001)(Crave)(PAL)   Nightmare Creatures II v1.000 (2000)(Konami)(NTSC)(US)   Nightmare Creatures II v1.004 (2000)(Konami)(PAL)(M4)   Plus Plumb v1.073 (1999)(Takuyo)(NTSC)(JP)   Puzzle Bobble 4 v1.000 (2000)(Cyberfront - Taito)(NTSC)(JP)   Q-bert v1.003 (2000)(Majesco)(NTSC)(US)   Railroad Tycoon II - Gold Edition v1.004 (2000)(GOD)(NTSC)(US)   Railroad Tycoon II v1.002 (2000)(Take 2)(PAL)(M3)   Resident Evil 2 v1.000 (2000)(Virgin)(PAL)(en-fr)   Resident Evil 2 v1.001 (2000)(Capcom)(NTSC)(US)   Rune Jade v1.027 (2000)(Hudson)(NTSC)(JP)   Sega Rally 2 v1.000 (1999)(Sega)(PAL)   Sega Rally 2 v1.003 (1999)(Sega)(NTSC)(US)   Sega Rally 2 v1.04 (1999)(Sega)(NTSC)(JP)(en)   Sega Rally 2 v1.04 (1999)(Sega)(NTSC)(JP)(en)   Sega Rally 2 v1.04 (1999)(Sega)(NTSC)(JP)(en)   Sega Smashpack Volume 1 v1.002 (2000)(Sega)(NTSC)(US)[7S 51146]   Shinseiki Evangelion - Typing E Keikaku v1.001 (2001)(Gainax)(NTSC)(JP)   SnoCross - Championship Racing v1.000 (2000)(Crave - Ubi Soft)(PAL)(M3)   SnoCross - Championship Racing v1.000 (2000)(Crave)(NTSC)(US)   Soukou no Kihei - Space Griffon v1.001 (1999)(Panther)(NTSC)(JP)   South Park - Chef’s Luv Shack v1.000 (1999)(Acclaim)(NTSC)(US)   South Park - Chef’s Luv Shack v1.000 (1999)(Acclaim)(NTSC)(US)   South Park - Chef’s Luv Shack v1.000 (1999)(Acclaim)(NTSC)(US)   South Park - Chef’s Luv Shack v1.000 (1999)(Acclaim)(PAL)   Spirit of Speed 1937 v1.001 (2000)(LJN)(NTSC)(US)   Spirit of Speed 1937 v1.002 (2000)(Acclaim)(PAL)(M4)   StarLancer v1.002 (2000)(Crave)(NTSC)(US)   StarLancer v1.003 (2000)(Crave - Ubi Soft)(PAL)   Super Producers - Mezase Show Biz Kai v1.001 (1999)(Hudson)(NTSC)(JP)   Super Runabout - San Francisco Edition v1.005 (2000)(Interplay)(NTSC)(US)   Super Runabout v1.002 (2000)(Virgin)(PAL)   Super Runabout v1.003 (2000)(Climax Entertainment)(NTSC)(JP)   Taxi 2 - Le Jeu v1.000 (2000)(Ubi Soft)(PAL)(FR)   Tom Clancy’s Rainbow Six incl. Eagle Watch Missions v1.001 (2000)(Red Storm - Swing!)(PAL)(DE)   Tom Clancy’s Rainbow Six incl. Eagle Watch Missions v1.002 (2000)(Red Storm - Swing!)(PAL)   Tom Clancy’s Rainbow Six incl. Eagle Watch Missions v1.002 (2000)(Red Storm - Swing!)(PAL)(FR)   Tom Clancy’s Rainbow Six v1.004 (2000)(Majesco - Red Storm)(NTSC)(US)   Tomb Raider - Die Chronik v1.001 (2000)(EIDOS)(PAL)(DE)   Tomb Raider - La Revelation Finale v1.000 (2000)(EIDOS)(PAL)(FR)   Tomb Raider - The Last Revelation v1.000 (2000)(EIDOS)(PAL)   Tomb Raider - The Last Revelation v1.000 (2000)(EIDOS)(PAL)(IT)   Tomb Raider - The Last Revelation v1.001 (2000)(EIDOS)(NTSC)(US)   Tomb Raider Chronicles - La Leggenda di Lara Croft v1.000 (2000)(EIDOS)(PAL)(IT)   Tomb Raider Chronicles v1.000 (2000)(EIDOS)(NTSC)(US)   Tomb Raider Chronicles v1.002 (2000)(EIDOS)(PAL)   Tomb Raider IV - The Last Revelation v1.000 (2000)(Capcom)(NTSC)(JP)   Tomb Raider IV - The Last Revelation v1.000 (2000)(EIDOS)(PAL)(DE)   Tsuushin Taisen Logic Battle Daisessen v1.000 (2000)(Fortyfive)(NTSC)(JP)   UnderCover 2025 AD Kei v1.005 (1999)(Pulse Interactive)(NTSC)(JP)   Urban Chaos v1.000 (2000)(EIDOS)(NTSC)(US)(en-fr)   Urban Chaos v1.001 (2000)(EIDOS)(PAL)(en-fr)   Virtua Cop 2 v1.011 (2000)(Sega)(NTSC)(JP)(en)   Who Wants to Beat Up a Millionaire v1.004 (2000)(Simon & Schuster)(NTSC)(US)   Wild Metal v1.003 (2000)(Rockstar - Take 2)(NTSC)(US)(M6)   Wild Metal v1.003 (2000)(Take 2)(PAL)(M6)   World Neverland Plus - Olerud Oukoku Monogatari v1.008 (1999)(Riverhillsoft)(NTSC)(JP)   Worms Armageddon v1.001 (1999)(Hasbro - Team17)(PAL)(M8)   Worms Armageddon v1.001 (1999)(MicroProse)(NTSC)(US)   Worms World Party v1.001 (2001)(Titus)(NTSC)(US)(M9)   Worms World Party v1.002 (2001)(Virgin)(PAL)(M9)   Yoshia no Oka De Nekoronde… v1.001 (2001)(Mesa - Naxat)(NTSC)(JP)   Yuki Gatari v1.004 (2002)(Takuyo)(NTSC)(JP)   Even more games?SegaRetro wiki has a list of even more games that were created with the WindowsCE SDK but I have been unable to verify if they have WINCE on the disc yet, you can find the list here: Windows CE - Sega Retro.Also I haven’t checked Demo discs or prototype games either, so please contribute if you know of some that should be added to the list.Armada (US)The US version of Armada contains the linker map file for the WSEGACD windows CE library. This contains all the function names provided by the library.The Next Tetris (WindowsCE)The online edition of ‘The Next Tetris’ was built using the Dreamcast Windows CE SDK and has accidentally placed 2 windowsCE libraries on the retail disc: CHATCE.LIB (Chat library for windowsCE) SOUNDLIBWCE.LIB (Sound library for windowsCE)Note that The Next Tetris is the only dreamcast game that includes these two libraries.The game includes TETRISDC.EXE which is a SH-4 PE executable but it does not contain any debug symbols.Taxi 2 - Le Jeu (contains WinCE PDB files)The french game Taxi 2 contained the PDB files for all the libraries provided by the WindowsCE runtime environment for dreamcast. Also of note is that the NTSC release of Armada also contained the PDB files for the same libraries but they have different md5 hashes so likely from different versions of the Windows CE runtime environment. PDB File Md5 Hash Notes WINCE/IMEJPPUI.PDB 6f5aac1bf15ed29bac2bde7f20c09abd Japanese Input Method Editor (IME) WINCE/NETFLASH.PDB 2f0c91d6349f0180ef2a432887f9ee78   WINCE/DDI.PDB 7a0475d3944db3fdb04c35c6efe955c6 Display Driver 3 WINCE/DPMODEMX.PDB ef1c6043e93adf89832f400b06ae1f70   WINCE/MRASENTRY.PDB b00d54787d2501208db1adc44a269532 MRASENTRY is a utility to create a RAS entry based on a file description of the entry WINCE/SERIAL.PDB be068a5cc2d9251615c907595f8ab2d4 Serial Communication Driver /WINCE/MPPP.PDB ffa4e1d4e53e3f50c8b51f168e253cb7 Microsoft Point-to-Point Protocol /WINCE/JSCRIPT.PDB 1922e087c3d14125a6bfe261b7023ae5 ECMAScript (Web Browser Lib) /WINCE/URLMON.PDB 848491a8ff3ad6c424e108a6f1b20b44 Url Moniker Services (Web Browser Lib) /WINCE/TIMER.PDB 01da19d9a794d9a80f812dd163aeefb3 High/low resolution Timer library /WINCE/DMUSIC.PDB 7ba57234ca02b601d8206bacb4bbfc3d Direct Music /WINCE/WDMLIB.PDB 4e6baf98669347559c3f3f6e7e3148af Windows Driver Model (WDM) Library /WINCE/AMSTREAM.PDB d2649a8ba34a15c0787ee02088d66669 DirectShow multimedia stream interfaces /WINCE/MRASDIAL.PDB 37fc61f89f96f045122f5579f409b0db RAS (Remote access service) dial connection /WINCE/DDHAL.PDB cb7980ce0aa02fce0ac8df35678317a0 Direct Dreamcast Hardware library for graphics /WINCE/DMLOADER.PDB b10343666d5367efa606999dea08871c Direct music loader /WINCE/SENDKEY.PDB 39673bbc3b9868200cc9eb2ce879402a   /WINCE/DINPUTX.PDB 80f2f681f0ec52fee0d83642d2adc65b Direct Input /WINCE/SH4SER.PDB e6d83904b4cec7f27dabacf63b48bf5b SH4 cpu serial interface /WINCE/MAPLE.PDB 7024df629207f9d2933882e8b57ba3dd Maple is the hardware bus that connects external devices to the Dreamcast console and enables the console to communicate with them. /WINCE/MSHTML.PDB 98f0da4a152625b9233b4e2036ac3683 HTML library (Browser) /WINCE/WSEGACD.PDB 6d80b4857534df779563c7d81305ff1e   /WINCE/TOOLHELP.PDB c1bfd3d289271ec0c188eb2955373fcf   /WINCE/TANKANJI.PDB 96f6185994890346efab2204a9a42076   /WINCE/DBG.PDB 8c68aa19ca867f16fb44fa69a45429e0   /WINCE/IECEUI.PDB f822550d3217de63f15905a092695943   /WINCE/DPLAYX.PDB 1f20a4dbe4008b00cab5d2bee01fb1bd   /WINCE/MEMTOOL.PDB 342c579283dea04da50635d843e7475d   /WINCE/SHELL.PDB 29818f5057786e277b3876dbbe8cc5bf   /WINCE/SHLWAPI.PDB 8c10158ffeb2effd328e2fe5d8302fd5   /WINCE/DMBAND.PDB 1ac4d18f288e223387517930a1c66637   /WINCE/MSADPCM.PDB 03046a5031844eac7cc569515a070196   /WINCE/MICROSTK.PDB b6d52beeff2376bdfffb88d958d7b2ce   /WINCE/ICCVID.PDB d0b252d5cdf97b8eae841bc0031a0d3d   /WINCE/CEMM.PDB 1a4386d0c114637768825d88d14c78ab   /WINCE/DMIME.PDB 99a5cc3a058800d13c811f54c61bba79   /WINCE/CEGSM.PDB d0e5a9d213fa27765533e3b343bed706   /WINCE/MMTIMER.PDB 73df42ae62e3e519c450ced1b3e7a260   /WINCE/SERF.PDB 49bcc93e670c830ed6140e3612253970   /WINCE/MAPLEDEV.PDB e4a4c08660fff95f396a1b76e2a5eb06 Sega Dreamcast External Device Interface called Maple (Dreamcast Exclusive) /WINCE/PROFDLL.PDB b726b6e700577ac031276137ee409c46   /WINCE/MLANG.PDB 608461596ee74a63c534f2fc6b085acf   /WINCE/ICM.PDB 21f88d3b1ed893675c4a39850eeae05f   /WINCE/DMSTYLE.PDB ea4f688ba564b80143a8b7eb6f7f8f06   /WINCE/DPWSOCKX.PDB 7bf36df6cf92fe82f86ef37f1e321a96   /WINCE/DPLDPLAY.PDB 3757ab16452c0cadd1f545c431774d62   /WINCE/LOADDBG.PDB 2a8f6653f30f4c224922cde229739baa   /WINCE/MSRLE32.PDB 45ef2dd47c31f31b5a5a5bfbe2924f41   /WINCE/SHDOCVW.PDB 3beabcae6acac63ab1e3d5110aa5504b   /WINCE/SEGAMIDI.PDB d9bdf522cb01ef00a9c3c55a06deabc8 Sega MIDI Audio Library (Dreamcast Exclusive) /WINCE/DTRACE.PDB 261dc62ed89e60a174fd8782a173e027   /WINCE/PLATUTIL.PDB 4d5f3442b63da62dfdb2afbc383ec9bc   /WINCE/PCMCONV.PDB 10bb816afe70b89776ad2cff11cd4d44   /WINCE/WDEVICE.PDB e608d2a64e7c5b846a80f1fa0e9d2d4a   /WINCE/DSOUND.PDB c1b58163abc63a62ec02f23108581a84 DirectSound /WINCE/PHONETIC.PDB b3423caa3f865fd854dd24c2a462f834   /WINCE/WDMOEM.PDB f0c97921378e026fdf80dd620cb5addf   /WINCE/GETHINFO.PDB f42c92cf802716be223aac7ae8460080   /WINCE/IMGUTIL.PDB 25bf03f1816625bdeb06359e74fefb02   /WINCE/WINSOCK.PDB f3bbb266d7db9dcd8bbc6cd38d7ce2a6 BSD Socket API /WINCE/QUARTZ.PDB b6beee41e50066fbcd1023efd0ae721d   /WINCE/VKEYBD.PDB 2c4c7ec9d10ccc94f191fb2061f40c01   /WINCE/MSCHATPR.PDB d3fff1f7db4170f83a7845dc34e741c6   /WINCE/SYSSTART.PDB ac0667e3c5cd6e60a41e2dbbefed87b4   /WINCE/WININET.PDB 5b897f635c639fbd01634f666adb850b   /WINCE/VMUPROTO.PDB b9416a7b18e24cba80d81b3da598631c   /WINCE/DMCOMPOS.PDB b6bc29fc907956015f93e88360fef80e   /WINCE/IMAADPCM.PDB e3b5db45278bf750f60d04117385bef2 ADPCM Audio /WINCE/IMEJPP.PDB ae1960bea798a07a2d124e75a1f7e0ec Japanese Text /WINCE/OLEAUT32.PDB 5cabc49947ab6c80ea46459c21d3bbbf Automation Type Library Registration (HTML) /WINCE/PNGFILT.PDB 8a594e11f1b590b447842a4caa9042ac PNG image filter /WINCE/SECUR32.PDB c2a3331bd80c7117b92db9d8ed120f5a Security (Not needed for Dreamcast?) 4 /WINCE/VMIMIME.PDB b386e6121076488d918bd571580cb37a VMU library (Dreamcast Specific) /WINCE/SEG_ROCK.PDB 453bd7c35f93e56c8c7a64dd215b2d45 Dial Up library? /WINCE/MSG711.PDB 4bb4ec3ff7f0bab234e4764e49ccfbba   /WINCE/IECEEXT.PDB 69f3b3c4ece400917f3058bcde26f356 HTML Core /WINCE/SNDCORE.PDB 45b095dad4466c4af848cf2f1aa7edf8 DirectX Sound Driver /WINCE/SCHANNEL.PDB 05ac9c6c854f3c7a59f0152cb4ac1977 Security /WINCE/MSACMCE.PDB 415c1bf169f661a86f5e3775361d66a0 Audio Compression Manager /WINCE/D3DIM.PDB dc101a1f68d59818921cff9fa0859ad8 Direct3D Immediate Mode /WINCE/DDRAW.PDB f7f1a6ad153bcb8bd4a2e5dfe4015e79 Direct Draw Games that contained un-linked Library filesIt was very rare for games to include library files on the disc, these would serve no purpose as the game can’t load static libraries at runtime (they would have to be dynamic link libraries .dll).These are somewhat interesting as they do contain function names but they are just a small part of each game. Library Game Additional Notes SOUNDLIBWCE.LIB The Next Tetris Sound CHATCE.LIB The Next Tetris Chat networking CARCE.LIB Spirit of Speed 1937   CEFRONTLIB.LIB Spirit of Speed 1937   ARCHIVE.LIB Spirit of Speed 1937   BORIS2CE.LIB Spirit of Speed 1937   GRAPHICSLIB.LIB Spirit of Speed 1937   ERRORLIB.LIB Spirit of Speed 1937   MAPLEDEV.LIB Taxi 2 - Le Jeu See the Maple library section MFSTDLIBDC.LIB Urban Chaos   DDLIBDC.LIB Urban Chaos   DDENGDC.LIB Urban Chaos   WIndows CE Platform SDKThe Windows CE Platform SDK itself was available free from the Microsoft website and was used for programming for a range of embedded devices. However this only included the CE libraries and headers, in order to actually compile for the Dreamcast you would need to pay for the full Katana development platform 5.Windows CE Dreamcast Specific LibrariesThese are the libraries that were unique to the Dreamcast Windows CE SDK and were not standard as part of the normal Win CE SDK.MapleMaple is the name of the library that allows the Windows CE SDK to connect to external devices such as Light-Guns, keyboards and more.WSEGACDThe WSEGACD library was developed by Sega for control of the GD-ROM drive. So developers could read data or even stream data from the disc. Presumably the ‘W’ stands for windows as a different library was developed for the Katana SDK.VMIMIME (VMU)The VMIMIME library is used to connect between the main game code and the VMU unit in the back of the controller.GlossaryThe table below lists the relevant entries. Name Meaning WDM Windows Device Model References Windows CE - Sega Retro ↩ The Dreamcast Junkyard: Windows CE is Best OS and Dreamcast is Best PC? ↩ ↩2 Windows CE OS GUI (Shell) Is Possible ↩ Needles files in the WinCE folder of QDC! - DCEmulation ↩ Gamasutra - Games to Go: Windows CE ↩ ", "excerpt": "Originally called the Dragon SDK and planned to be the full Operating System (OS) of the dreamcast. However SEGA decided to go with their own limited BIOS with the Dreamcast instead of a fully functional OS. So to use WindowsCE on the Dreamcast game developers would have to bundle the...", "tags": ["sega","dreamcast","sdk"], "image": "/public/images/dreamcast/Dreamcast-WIndows-CE-SDK.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo DsiWare Leak", "url": "/dsiwareleak", "content": "As part of the Platinum Leak on the 9th of September 2020 a ton of DsiWare titles were leaked, including debug versions of games like Legend of Zelda Four Swords remaster. Nintendo Platinum Leak For more information on the rest of the Platinum check out this post. The Platinum leak contained an archive called generic.7z it is inside this that you will find the DSiWareROM.rar archive covered in this postDSiWare ROMS (DSiWareROM.rar)The DSiWareROM.rar archive contains a ton of DSiWare ROMS in TAD format. The repository is split into folders based on the date, presumably from when Nintendo sent the data to iQue.Apparently TAD files are DSIWare applications that have been exported to the SD card 1.All of the ROM files have the prefix SPD which is Nintendos Software Planning Devision 2, which is where these DsiWare titles were sent from to iQue.You can use the TWL-DW_data.xls from previous leaks to look up the 4 character code of the game (e.g KEJJ).The folders are: 20090722 - contains Japanese DsiWare such as ELECTROPLANKTON™ Marine-Crystals (KEJJ_SPD-02817.tad) 20090925 - contains even more Japanese DsiWare such as Sleep record alarm clock (KMZJ_SPD-03107.tad) 20091223 - unknown DsiWare such as SPD-03408_chample0923f.tad 20100120 - two unknown DsiWare including SPD-03482_TKA2J00.tad 20100127 - just contains SPD-03521_SikakuDSi_1015.tad 20100203 - two unknown DsiWare including blocker_dsi_TwlRomSymbol_2009_1008_1040_r27659.tad 20100215 - Two different versions of Starship Starship_TwlRomSymbol_2009_1028_1122_r28723.tad 20100302 - Unknown DsiWare SPD-03623_TKSRE00.tad 20100310 - Contains Pinball and Rittango 20100324 - Debug version of Kaite Oboeru: Shashin Tango and Kaite Oboeru: Eitango Chou from Intelligent Systems 20100405 - Debug version of SPD-03723_KKR1009_1D.tad 20100427 - Contains two unknown DsiWare such as SPD-03776_TK3LJ00.tad 20100603 - Contains FacePilot and DigiQ 20100607 - Contains DsiGolf and another unknown title 20100930 - Contains Karuta 20110922 - Contains a debug version of Knife (SPD-05577_KQ9J_DEBUG_2011_0915_1547.tad) and debug documentation for itDSiWare Titles includedThe DSiWare included in both 20090722 and 20090925 folders are listed in the table below along with their name in both Japanese and English. FileName DSiWare Name KAAJ_SPD-02799.tad AQUARIO (Art Style シリーズ) KADJ_SPD-02799.tad DECODE (Art Style シリーズ) KAGJ_SPD-02808.tad あつめる笑顔帳 (Collecting smile books?!) KAHJ_SPD-02799.tad HACOLIFE (Art Style シリーズ) KAKJ_SPD-02799.tad nalaku (Art Style シリーズ) KAPJ_SPD-02799.tad PiCOPiCT (Art Style シリーズ) KASJ_SPD-02799.tad SOMNIUM (Art Style シリーズ) KAVJ_SPD-02799.tad DIGIDRIVE (Art Style シリーズ) KBGJ_SPD-02803.tad ちょっとDS文学全集 世界の文学20 (World literature 20) KBRJ_SPD-02807.tad フォトスタンド付き バンブラDXラジオ (Bumbra DX Radio with Photo Stand) KCPJ_SPD-02799.tad できすぎチンクルパック (Too much tingle pack) KD9J_SPD-02803.tad ちょっとDr.MARIO KDNJ_NWD-00151.tad ほぼ日路線図 2009 (Hobonichi Route Map 2009) KE3J_SPD-02799.tad あそべる絵本　マインドテン (Picture book to play with Mind Ten) KEAJ_SPD-02817.tad エレクトロプランクトン　トレーピー (Electroplankton trappy) KEBJ_SPD-02817.tad エレクトロプランクトン　ハネンボン (Electroplankton Hanenbon) KECJ_SPD-02817.tad エレクトロプランクトン　ルミナリアン (Electroplankton Luminarian) KEDJ_SPD-02817.tad エレクトロプランクトン　タイヨウチュウ (Electroplankton Heliozoa) KEEJ_SPD-02817.tad エレクトロプランクトン　レックレック (Electroplankton Reclek) KEFJ_SPD-02817.tad エレクトロプランクトン　ナノカープ (Electroplankton nanocarp) KEGJ_SPD-02817.tad エレクトロプランクトン　ヒカリノワ (Electroplankton Hikarinova) KEHJ_SPD-02817.tad エレクトロプランクトン　マリンスノー (Electroplankton marine snow) KEIJ_SPD-02817.tad エレクトロプランクトン　ツリガネムシ (Electroplankton Vorticella) KEJJ_SPD-02817.tad エレクトロプランクトン　ボルボイス (Electroplankton Volvois) KGBJ_SPD-02803.tad ゲーム＆ウオッチ ボール (Games & Watch Balls) KGCJ_SPD-02803.tad ゲーム＆ウオッチ シェフ (Game & Watch Chef) KGDJ_SPD-02803.tad ゲーム＆ウオッチ ドンキーコングJR. (Game&Watch DONKEY KONG JR.) KGFJ_SPD-02803.tad ゲーム＆ウオッチ マリオズセメントファクトリー (Game&Watch MARIO’S Cement Factory) KGGJ_SPD-02803.tad ゲーム＆ウオッチ フラッグマン (Game&Watch FLAGMAN) KGHJ_SPD-02803.tad ゲーム＆ウオッチ ヘルメット(Game&Watch HELMET) KGJJ_SPD-02803.tad ゲーム＆ウオッチ ジャッジ (Game&Watch JUDGE) KGMJ_SPD-02803.tad ゲーム＆ウオッチ マンホール (Game&Watch MANHOLE) KGVJ_SPD-02803.tad ゲーム＆ウオッチ バーミン (Game&Watch VERMIN) KHDJ_SPD-02803.tad いつでもプリクラ☆キラデコプレミアム (Anytime Purikura ☆ Kiradeco Premium) KJEJ_SPD-02807.tad リズムで鍛える新しいえいご漬け　ネイティブ会話編 (New English Training) KK4J_SPD-02816.tad 囲んで消して ワクグミの時間 (Wakugumi: Monochrome Puzzle) KKDJ_SPD-02803.tad がんばる私のおさいふ応援団 (Household account book) KM9J_SPD-02817.tad ちょっとマジック大全 恐ろしい数字 (A Little Bit of… Magic Made Fun: Deep Psyche) KMDJ_SPD-02817.tad ちょっとマジック大全 デート占い (A Little Bit of… Magic Made Fun: Matchmaker) KMFJ_SPD-02817.tad ちょっとマジック大全 ファニーフェイス (A Little Bit of… Magic Made Fun: Funny Face) KMIJ_SPD-02817.tad ちょっとマジック大全 スキ·キライ発見器 (A Little Bit of… Magic Made Fun: Mind Probe) KMNJ_SPD-02817.tad ちょっとマジック大全 念写カメラ (A Little Bit of… Magic Made Fun: Psychic Camera) KMSJ_SPD-02817.tad ちょっとマジック大全 3つのシャッフルゲーム(A Little Bit of… Magic Made Fun: Shuffle Games) KN9J_SPD-02807.tad ちょっと脳を鍛える大人のDSiトレーニング 数独編 (Brain Age Express: Sudoku) KNDJ_SPD-02807.tad ちょっと脳を鍛える大人のDSiトレーニング 文系編 (Brain Age Express: Arts & Letters) KNKJ_SPD-02803.tad 井出洋介の健康麻将DSi (Yosuke Ide’s Health Asahi DSi) KNRJ_SPD-02807.tad ちょっと脳を鍛える大人のDSiトレーニング 理系編 (Brain Age Express: Math) KPNJ_SPD-02803.tad ちょっとパネルでポン (Puzzle League Express) KQ6J_SPD-02803.tad くるくるアクション くるパチ６ (Spin 6) KR2J_NWD-00151.tad ポケットるるぶ京都 (Pocket Rurubu Kyoto) KRIJ_NWD-00151.tad ポケットるるぶ東京 (Pocket Rurubu Tokyo) KSEJ_SPD-02807.tad リズムで鍛える新しいえいご漬け　やさしい会話編 (New English Training) KSLJ_SPD-02807.tad ソリティアDSi (Touch Solitaire) KSUJ_SPD-02816.tad ちょっと数陣タイセン (Number Battle) KTBJ_SPD-02816.tad ちょっとアソビ大全 おなじみテーブル (A Little Bit of… All-Time Classics: Strategy Games) KTPJ_SPD-02816.tad ちょっとアソビ大全 おてがるトランプ (A Little Bit of… All-Time Classics: Family Games) KTRJ_SPD-02816.tad ちょっとアソビ大全 じっくりトランプ (A Little Bit of… All-Time Classics: Card Classics) KUWJ_SPD-02808.tad うつすメイドインワリオ (WarioWare: Snapped!) KWBJ_SPD-02807.tad ニンテンドーDSi時計 ファミコンマリオタイプ (Mario Clock) KWCJ_SPD-02807.tad ニンテンドーDSi時計 どうぶつの森タイプ (Animal Crossing Clock) KWDJ_SPD-02807.tad ニンテンドーDSi時計 フォトスタンドタイプ (Photo Clock) KWFJ_SPD-02807.tad ニンテンドーDSi電卓 ファミコンマリオタイプ (Mario Calculator) KWGJ_SPD-02807.tad ニンテンドーDSi電卓 どうぶつの森タイプ (Animal Crossing Calculator) KX7J_SPD-02803.tad パズルいろいろ　月刊クロスワードハウス　Vol.1 (Various puzzles Monthly Crossword House Vol.1) K59J_SPD-03093.tad あぁ無情 刹那 (Metal Torrent) KA2E_SPD-03100.tad Art Academy: Second Semester (European ROM) KAIE_SPD-03100.tad Art Academy: First Semester (European ROM) KCDJ_SPD-03107.tad Word KCHJ_SPD-03097.tad カードヒーロー スピードバトルカスタム (Card Hero Speed Battle Custom) KDMJ_SPD-03100.tad Minis (Mario vs. Donkey Kong: Minis March Again!) KMTJ_SPD-03097.tad ニンテンドーDSi メトロノーム (Nintendo DSi Metronome) KMZJ_SPD-03107.tad 睡眠記録 めざまし時計 (Sleep Clock) KOAJ_SPD-03097.tad 今日からはじめるフェイスニング顔トレミニ①すっきり小顔コース (Face training) KOBJ_SPD-03097.tad 今日からはじめるフェイスニング顔トレミニ②ステキな笑顔コース (Face training 2) KOCJ_SPD-03097.tad 今日からはじめるフェイスニング顔トレミニ③若々しい顔コース (Face training 3) KODJ_SPD-03097.tad 今日からはじめるフェイスニング顔トレミニ④目と口の健康コース (Face training 4) KOEJ_SPD-03097.tad 今日からはじめるフェイスニング顔トレミニ⑤顔のリフレッシュコース (Face Training 5) KPTJ_SPD-03100.tad パネル連結　３分ロケット (Pata) KSPJ_SPD-03100.tad ねらってスポっと！ (Spot!) KTUJ_SPD-03097.tad ニンテンドーDSi 楽器チューナー (Nintendo DSi Instrument Tuner) Electroplankton Series (エレクトロプランクトン)In the list above you will notice a lot of games in the Electroplankton series, Electroplankton was originally a DS game and then split up into sub-games and sold on the DSi Store for 200 points each 3.The ID for the games all start with KE then the letter of the sub-game from A to J and finally followed by the region, for the leak they are all Japanese so have the letter J.The ROMs leaked for Electroplankton are: KEAJ_SPD-02817.tad - エレクトロプランクトン　トレーピー (Electroplankton trappy) KEBJ_SPD-02817.tad - エレクトロプランクトン　ハネンボン (Electroplankton Hanenbon) KECJ_SPD-02817.tad - エレクトロプランクトン　ルミナリアン (Electroplankton Luminarian) KEDJ_SPD-02817.tad - エレクトロプランクトン　タイヨウチュウ (Electroplankton Heliozoa) KEEJ_SPD-02817.tad - エレクトロプランクトン　レックレック (Electroplankton Reclek) KEFJ_SPD-02817.tad - エレクトロプランクトン　ナノカープ (Electroplankton nanocarp) KEGJ_SPD-02817.tad - エレクトロプランクトン　ヒカリノワ (Electroplankton Hikarinova) KEHJ_SPD-02817.tad - エレクトロプランクトン　マリンスノー (Electroplankton marine snow) KEIJ_SPD-02817.tad - エレクトロプランクトン　ツリガネムシ (Electroplankton Vorticella) KEJJ_SPD-02817.tad - エレクトロプランクトン　ボルボイス (Electroplankton Volvois)Game & Watch Series (ゲーム＆ウオッチ)Nintendo released remakes of some of their classic Game & Watch handheld systems as downloadable DSiWare available for both the DSi and 3DS.The ID for the games all start with KG followed by the letter of the individual game and watch game, the letters represent the first letter of the game, e.g B for Balls and V for Vermin, so not all Letters are used.The ROMs leaked in the Game & Watch series are: KGBJ_SPD-02803.tad - ゲーム＆ウオッチ ボール (Games & Watch Balls) KGCJ_SPD-02803.tad - ゲーム＆ウオッチ シェフ (Game & Watch Chef) KGDJ_SPD-02803.tad - ゲーム＆ウオッチ ドンキーコングJR. (Game&Watch DONKEY KONG JR.) KGFJ_SPD-02803.tad - ゲーム＆ウオッチ マリオズセメントファクトリー (Game&Watch MARIO’S Cement Factory) KGGJ_SPD-02803.tad - ゲーム＆ウオッチ フラッグマン (Game&Watch FLAGMAN) KGHJ_SPD-02803.tad - ゲーム＆ウオッチ ヘルメット(Game&Watch HELMET) KGJJ_SPD-02803.tad - ゲーム＆ウオッチ ジャッジ (Game&Watch JUDGE) KGMJ_SPD-02803.tad - ゲーム＆ウオッチ マンホール (Game&Watch MANHOLE) KGVJ_SPD-02803.tad - ゲーム＆ウオッチ バーミン (Game&Watch VERMIN)Art Academy Series (Art Style シリーズ)The ROMs leaked in the Art Academy Series are: KA2E_SPD-03100.tad - Art Academy: Second Semester (European ROM) KAIE_SPD-03100.tad - Art Academy: First Semester (European ROM) KAAJ_SPD-02799.tad - AQUARIO (Art Style シリーズ) KADJ_SPD-02799.tad - DECODE (Art Style シリーズ) KAGJ_SPD-02808.tad - あつめる笑顔帳 (Collecting smile books?!) KAHJ_SPD-02799.tad - HACOLIFE (Art Style シリーズ) KAKJ_SPD-02799.tad - nalaku (Art Style シリーズ) KAPJ_SPD-02799.tad - PiCOPiCT (Art Style シリーズ) KASJ_SPD-02799.tad - SOMNIUM (Art Style シリーズ) KAVJ_SPD-02799.tad - DIGIDRIVE (Art Style シリーズ)Unknown & Test ROMsThe ROMs in the first two folders (20090722 and 20090925) are fairly easy to identify the name of. However the other folders don’t seem to have ROMs using the standard naming convention.Some are missing the product code which is the easiest way to identify the ROMs. So if you know what any of the ROMs in the list below are then please let us know.The Unknown ROMs are: SPD-03408_chample0923f.tad - Chample? (never heard of it) SPD-03521_SikakuDSi_1015.tad - Sikaku? (mistransliteration of “Shikaku” 4) blocker_dsi_TwlRomSymbol_2009_1008_1040_r27659.tad - Blocker? Starship_TwlRomJapan_2009_1028_1125_r28723.tad - Starship? (maybe Starship Patrol / Defender? 4) Starship_TwlRomSymbol_2009_1028_1122_r28723.tad - Starship(?) with debug symbols SPD-03654_Zodiac_Pinball_Cheat_2009_08_26_1205.tad - Pinball Pulse: The Ancients Beckon 4 Presumably with build in cheats SPD-03649_AttaColleda_RomForShot100204.tad - Unknown SPD-03776_20100127_2D.tad - Attakoreda, JP title of Tales in a Box x_dsi_TwlRomSymbol_2010_0204_1646_r32157.tad - Unknown SPD-03878_R13948_DSRL.tad SPD-03878_artest100215_2105_R13948_DSFN.tad - Augmented Reality test?Some of these ROMs do have the product code after the letter T which presumably means it is a test version and not a retail release.The Testing ROMs are: SPD-03394_TKAVJ01.tad - DIGIDRIVE (Art Style Series) SPD-03396_TKPAJ00.tad - Leader SPD-03400_pbat.KPBJ.F.0907.2660.tad - P-Bat SPD-03482_TKA2J00.tad - Art Academy: Second Semester SPD-03483_TKAIJ00.tad - Art Academy: First Semester TKDZJ10.tad - DigiQ-z SPD-03623_TKSRE00.tad - Project Sky SPD-03654_TKZPE01.tad - Pinball Pulse The Ancients Beckon SPD-03649_TWL-KRGJ091201.tad - Looksley’s Line Up K8PJ_SVN4990_rel.tad - Mtan P (release?) K8PJ_SVN4990_rom.tad - Mtan P (debug?) K8EJ_SVN4989_rel.tad - Mtan E (release?) K8EJ_SVN4989_rom.tad - Mtan E (debug?) SPD-03723_KKR1009_1D.tad - Flip The Core? (Guess based on KKR) SPD-03776_TK3LJ00.tad - さるバンド (仮) (Monkey band (provisional)) TKDXJ00.tad - DigiQ-x SPD-03895_DSiGolf_us20091204d.tad - DsiGolf SPD-03895_TK72E00.tad - DsiGolf SPD-05577_KQ9J_DEBUG_2011_0915_1547.tad - Knife (Zelda 4 swords?)References DSi CID Discovered - Next Generation Emulation ↩ Nintendo Software Planning & Development - Wikipedia ↩ Electroplankton - Wikipedia ↩ Gingerbread Man on Twitter: “@RetroReversing @orcastraw Zodiac Pinball I guess is Pinball Pulse: The Ancients Beckon, made by Fuse Games. It’s based on Greek mythology. It was never released in Japan, so Zodiac Pinball was likely its planned JP title (or working title). Starship: maybe Starship Patrol / Defender?” / Twitter ↩ ↩2 ↩3 ", "excerpt": "As part of the Platinum Leak on the 9th of September 2020 a ton of DsiWare titles were leaked, including debug versions of games like Legend of Zelda Four Swords remaster. Nintendo Platinum Leak For more information on the rest of the Platinum check out this post. The Platinum leak...", "tags": ["ds","leak","debug"], "image": "/public/images/leaks/DsiWareLeak.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Static Libraries (.A) for Playstation 2 Emotion Engine", "url": "/static-libraries-ps2", "content": "This post will cover the programming libraries that were provided by the Official PS2 SDK for the Emotion Engine (the main processor for the PS2).Main Emotion Engine SDK librariesThese are the essential libraries that games could not function without: Name Description base64.a   libatok.a   libc_export.a   libcdvd.a   libcheck.a   libdbc.a   libdev.a   libdma.a   libeenet.a   liberx.a   libeyetoy.a   libgcc_2.9-ee-991111-01_export.a   libgcc_2.96-ee-001003-1_export.a   libgcc_3.2-beta2-ee-030210_export.a   libgcc_3.2-ee-030926_export.a   libgcc_3.2-ee-040921_export.a   libgcc_common_export.a   libgp.a Graphics Processing library libgraph.a Used to control the Graphics Synthesizer (GS) libhig.a High level Graphics library libhip.a Graphic plugin library for HIG libipu.a Low level library for controlling the Image data Processor (IPU) libkernl.a   liblout.a   libm_export.a   libmc.a   libmc2.a   libmcx.a   libmpeg.a Library for playback of MPEG2 Video libmrpc.a   libmsin.a   libmtap.a   libpad.a   libpad2.a   libpc.a   libpkt.a   libqp.a   libscf.a   libsdr.a   libsein.a   libsk.a   libspu2m.a   libssyn.a   libtimer.a   libusbkb.a   libusbpspcm.a   libvib.a Used for controlling the vibration of a controller libvu0.a   Networking EE LibrariesThese libraries were only used for Playstation 2 games that conntected to the internet for online play. Name Description bnnetcnf.a BB Navigator Network Configuration Library, used for reading the network configuration. eenet46.a HTTP TCP/IP stack for networking eenetctl.a Library for setting up the network ent_dump.a   ent_eth.a Ethernet interface driver paired with ent_eth.irx ent_ppp.a Modem driver paired with ent_ppp.irx ent_smap.a Network interface driver paired with ent_smap.irx entctl46.a   libinsck.a Socket library based on libnet libhttp.a Library for HTTP calls libhttps.a Library for HTTPS calls libnet.a Controls the IOP networking INET library libnetif.a   netcnfif.a Common Network Configuration Interface Library netglue_eenet.a General Purpose Network Wrapper API netglue_insck.a   netifmc2.a   ntgui2.a GUI library for managing Network Configuration Demo Disc Libraries./Demo Disc SDK/sdk/philmsg/philmsg.a./Demo Disc SDK/sdk/libscedemo/libscedemo.a./Demo Disc SDK/sdk/online_lib/online.aEmotion Engine Sample Libraries./ee/sample/atok/softkb/utf8/libccc/lib/libccc.a./ee/sample/atok/softkb/libpfont/lib/libpfont.a./ee/sample/inet/ntgui2/utf8/libccc/lib/libccc.a./ee/sample/inet/ntgui2/libpfont/lib/libpfont.aGCC Emotion Engine Libraries./ee/gcc/ee/lib/libidt.a./ee/gcc/ee/lib/libiberty.a./ee/gcc/ee/lib/soft-float/libidt.a./ee/gcc/ee/lib/soft-float/libiberty.a./ee/gcc/ee/lib/soft-float/libsupc++.a./ee/gcc/ee/lib/soft-float/libnosys.a./ee/gcc/ee/lib/soft-float/libm.a./ee/gcc/ee/lib/soft-float/libg.a./ee/gcc/ee/lib/soft-float/libc.a./ee/gcc/ee/lib/soft-float/libstdc++.a./ee/gcc/ee/lib/libsupc++.a./ee/gcc/ee/lib/libnosys.a./ee/gcc/ee/lib/libm.a./ee/gcc/ee/lib/libg.a./ee/gcc/ee/lib/libc.a./ee/gcc/ee/lib/libstdc++.a./ee/gcc/lib/libtk8.0.a./ee/gcc/lib/libopcodes.a./ee/gcc/lib/libiberty.a./ee/gcc/lib/libtix4.1.8.0.a./ee/gcc/lib/gcc-lib/ee/3.2-ee-040921/soft-float/libgcc.a./ee/gcc/lib/gcc-lib/ee/3.2-ee-040921/libgcc.a./ee/gcc/lib/libitk3.0.a./ee/gcc/lib/libmmalloc.a./ee/gcc/lib/libfl.a./ee/gcc/lib/libbfd.a./ee/gcc/lib/libitcl3.0.a./ee/gcc/lib/libtcl8.0.a./ee/gcc/lib/libexpect5.26.aGCC I/O Processor Libraries./iop/gcc/lib/libopcodes.a./iop/gcc/lib/libiberty.a./iop/gcc/lib/gcc-lib/mipsel-scei-elfl/2.8.1/libgcc.a./iop/gcc/lib/libbfd.aDeprecated (old) LibrariesLibSPU2 and LibSND2 seems to have been deprecated.. or maybe just these compiled versions are old, not sure.../ee/lib/Old/librspu2.a./iop/install/lib/Old/libspu2.a./iop/install/lib/Old/libsnd2.a./iop/lib/Old/libspu2.a./iop/lib/Old/libsnd2.a./iop/gcc/mipsel-scei-elfl/lib/Old/libspu2.a./iop/gcc/mipsel-scei-elfl/lib/Old/libsnd2.aUsing radare2 to print functions listr2 -qc 'is~FUNC' objectname.o", "excerpt": "This post will cover the programming libraries that were provided by the Official PS2 SDK for the Emotion Engine (the main processor for the PS2). Main Emotion Engine SDK libraries These are the essential libraries that games could not function without: Name Description base64.a   libatok.a   libc_export.a   libcdvd.a...", "tags": ["ps2","sdk"], "image": "https://www.retroreversing.com/public/images/ps2/PS2 Emotion Engine Static Libraries.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo Emerald Leak", "url": "/emeraldleak", "content": "The Emerald leak occurred on the 2nd of September 2020 and included about 700MB of content related to the Wii and gamecube. So this would not quite qualify as a “Gigaleak” but it was definitely from the same source as the Gigaleak. Gigaleak - SNES Source Code Leak For more information on the original Gigaleak check out this post. Most notably it contains the ATI Wii Verilog files for Vegas (part of the Hollywood graphics chip) and of course the source code to Pokemon Emerald.Files Leaked emeralds.7z (742MB)Contents of emeralds.7zWhen extracted the emerald archive has the following sub archives inside it: BOOT-DIAG.7z - Nintendo Wii software for Boot Diagnosis RVL-FFWP.7z - Wii VC - Donkey Kong: Original Edition (PAL) RVL-RAAE.7z - Wii Startup Disc RVL-WTester.7z - Wii Wifi Tester application pm_eme_ose.7z - Pokemon Emerald source code tako_main_052306.tgz - ATI Verilog files & Build environment for the Hollywood Graphics chip (Vegas/Tako)Nintendo Wii Boot Diagnostic Application (emeralds.7z/BOOT-DIAG.7z)When extracted the files and folders contained are: for246 - contains BOOT_DIAG v0 for system menu version 246 for4 - contains BOOT_DIAG v0 for system menu version 4 properties - Meta Data for the BOOT_DIAG app v100 - empty folder v193 - Just contains systemmenu.rvl.116.3.wad v0 - Version 0 of BOOT_DIAG app v2 - Version 2 of BOOT_DIAG appThe folders beginning with “for” are referring to the System Menu version, so “for4” folder contains the BOOT-DIAG- files for version 4 of the System menu (systemmenu.rvl.116.4.wad).System menu WAD files included: systemmenu.rvl.116.3.wad systemmenu.rvl.116.4.wad systemmenu.rvl.116.246.wadThere are two different versions of the BOOT-DIAG application, v0 and v2, no idea what happened to v1 but it wasn’t included.Files included: BOOT-DIAG-v0.cls - Actually a zip file BOOT-DIAG-v0.wad.out BOOT-DIAG-v2.cls BOOT-DIAG-v2.wad.outDonkey Kong: Original Edition (emeralds.7z/RVL-FFWP.7z)This archive only contains 2 files in it: FFWP000.wad - non-working WAD file (at least in dolphin) RVL-FFWP-v0.wad.out - working WAD fileThe name FFWP is the product ID for the NES Virtual Console game Donkey Kong: Original Edition.The strange thing is that the .wad file doesn’t load in dolphin but if you rename the .out file to .wad it works fine in Dolphin!It would be interest to check if this WAD file contains anything that is not in the retail release.Wii Startup Disc (emeralds.7z/RVL-RAAE.7z)This archive contains a few files related to the Wii Startup Disc.Contains the following files: RVL-RAAE-v0.cls RVL-RAAE-v0.prod_part main-sync.dev_partHonestly not sure what these files are exactly, but the product code “RVL-RAAE” matches the code for the Wii Startup Disc.For More information about the Wii Startup Disc check out the page on WiiBrew: Wii Startup Disc - WiiBrewAlthough to be honest these files aren’t as interesting as the Wii Startup Disc dump in the Platinum leak which contains the full .gcm file. Nintendo Platinum Leak For more information on the Platinum Leak check out this post. WifiTester (emeralds.7z/RVL-WTester.7z)The contents of this archive are as follows: RVL-WTester-v0.cls RVL-WTester-v0.wad.out WTester.3.wad forIOS36 - same files as above but for IOS version 36This doesn’t seem to install in Dolphin so it can’t be confirmed if it is a WifiTester application. But it is definitely an application for the Wii.Vegas/Tako (Hollywood) (emeralds.7z/tako_main_052306.tgz)The archive tako_main_052306.tgz has been created by ATI, another company responsible for working on the Nintendo Wii. We already have leaked Verilog files from the company BroadOn previously, so when joined with these files you have a more complete picture of the entire Wii Verilog source code. BroadOn Archive - Nintendo May 2020 Leak (4Chan) For more information on the BroadOn Verilog files check out this post. This archive contains the hardware Verilog source code for the ArtX (ATI) Hollywood graphics processor. Specifically the Vegas portion which is the core of the Chip, note that the project was previously called Tako (after the sushi), the name change is noted in the index.html file in the web documentation.Other sources are calling Tako a portable Gamecube project, however this is incorrect, there are a few documents talking about a hybrid portable gamecube however this was under the NNGC or GC Portable name and not related to Tako (apart from Tako being encluded as the Graphics processor).For more information about the Portable Gamecube see the section later on in this page.This is similar to the previously leaked verilog files for the Nintendo 64 as it contains much of the same tools, even includes a C simulator (csim) version of the verilog hardware.When the archive has been extracted it has the following folders: bw - broadway source files doc - documentation for the project hdk - Hardware development kit hw - Hardware spec files (verilog) test - C source code and scripts to test the hardware specsnote that this folder seems to be missing the sw sub folder which is referenced in some of the documentation such as the buildNTDGX.txt file, which states that the Nintendo Gamecube Graphics Library (NTDGX) is in that folder.BothWare header files and tools (tako_main_052306.tgz/bw)This folder potentially contains header files and tools related to Bothware, presumably bothware is content that is used by both the hardware and software folders such as the fdl include files.The contents of the bw folder is as follows: Makefile - Main makefile that builds the sub directories env - perl scripts to setup the environment fdl - contains .fdl scripts for use with the fiddle tool fdl_legacy - old legacy fiddle scripts include - C header files generated by the fiddle scripts in the fdl folder lib - contains 3 libraries axpli, axsplit and axtoken make - bash and perl scripts used in Makefiles mcpp - .mcp files used for a tool called mcpp tools - C/C++ source code for tools such as fiddle and mcpp xfcode - Verilog source code for something known as XFThe fiddle tool compiles .fdl (Field Description Language) files into C header files, the fdl files describe bit fields such as registers and commands.Documentation (tako_main_052306.tgz/doc)The Doc folder contains some very interesting documentation, this is where the news sources got their headline for the Portable Gamecube (specifically in the proj sub directory).The contents of this folder are as follows: cmn - Common documentation related to building the project dummy.txt - dummy text file with nothing of importance in it hw - Hardware Documentation index.html - root index.html that redirects to the index of the web directory proj - Project documentation spec_legacy - Gamecube flipper hardware documentation sw - software documentation (Broadon and Nintendo sections are empty but ATI has docs) test - test plan spreadsheets web - web based documentation including Wiki backupCommon Documentation (doc/cmn)The files in the folder are as follows: buildEnv.txt - How to setup the build environment (e.g environment variables) buildInternals.txt - Coming Soon - so nothing of interest buildNTDGX.txt - how to build the Nintendo Graphics API (NTDGX) used for Gamecube codeAndMakefiles.txt - pretty detailed guide for how to write better C/C++ and Makefiles log.gz - just contains a log file with the results of all the builds passingThe most interesting file in this is probably the log file, although not exactly gripping reading material it can be nice to see the result of the build system running successfully.The next most interesting is the codeAndMakefiles.txt file which describes what they learned from the messy Dolphin (Gamecube) codebase. So they decided to treat all compiler errors as warnings and avoid the use of undefined compiler-specific code. Good advice that still holds to C/C++ developers today!Also of interest is the uncertainty of what Nintendo was planning, they wanted to support the NTDGX API for backwards compatibility with Gamecube but they were not sure if it would still be used by the Wii.Software Documentation (doc/sw)This folder contains three folders but sadly the nintendo and broadon folders are empty, the only folder with content is the ati folder.The contests of the ati folder are as follows: c_style_guide.html - C coding style guide cygwin_install.html - How to install the cygwin toolchain on Windows labpc_setup.html - How to setup the internal lab PCs readme.txt - just a note reminding to add ATI document in this folder sshd_setup.html - how to setup the OpenSSH daemon on Windows stand_setup.html - how to setup a standalone build environment test - Bring upo Test PlansThe most interesting document in this folder is actually the gfx_bringup.html document inside the test folder.Test Plan Documentation (doc/test)As expected this folder just contains spreadsheets for the Test plans for each hardware component and the current progress of testing.The files in this folder are: ahb.txt - Notes for the Advanced High-performance Bus (AHB) ahb.xls - test plan progress spreadsheet for AHB ahbmon.doc - list of monitors for measuring performance of AHB ahm.txt - Advanced High-performance Memory? ahm.xls - test plan progress spreadsheet for AHM ahm_direct.doc - Test for AHM registers ai.xls - Audio Interface test plan progress spreadsheet arb_direct.doc - Tests for AHB Arbiter busy.README - Describes memory testing and stuff like .dv files busy.txt - Notes on busy client/master setup crs_test_plan.xls - Test plan for a chip called CRS di0.xls - Disk Interface Test Plan exi.xls - EXI Device Bus test plan mem_test.xls - Plan for testing Memory pe_expaddr.xls - expanded address testing si.xls - Serial Interface test plan tst_test_plan.xls - JTAG test planPlease note we are not sure what CRS stands for and AHB and AHM are unconfirmed.Hardware Development Kit (HDK) (tako_main_052306.tgz/hdk)The Hardware development kit contains two versions, one for Linux and another for windows, they are separated into two different directories: intel_i686_linux_2.4.9-13smp - Linux based GNU toolchain - but doesn’t contain actual files win32 - PC tools used for development such as CodewarriroThe Linux version is very strange as its literally just the folder structure and nothing more, so no actual files are included, so you can’t do anything with this folder at all.The Windows version is much more complete on the other hand and even contains content for the 3.0 Alpha 3 version of CodeWarrior for Gamecube. Although doesn’t seem to contain the main executables to actually run CodeWarrior.It also contains cygwin GCC executables that can be used to compile the C-source code tests on Windows PCs.Hardware Verilog source code (tako_main_052306.tgz/hw)Contains: Makefile - main makefile to build all the Verilog and C source code chip chip_common chip_legacy diag doc dump lib models models_legacy pad pcb pll_test_chip ras run run.dma run_legacy su sys sys_common sys_legacy tools usbphytest (tako_main_052306.tgz/test)The test folder as you might expect contains scripts and code used to test the project. it contains the following content: Makefile - calls the sub make files of all the sub folders bin - perl scripts to run tests lib - libraries used for the test code in sys streams - empty folder sys - main test code in C sys_legacy - legacy tests tools - a couple of tools used for converting file formatsefb2crc (tools/efb2crc)A tool created by ArtX Inc, the company behind the Flipper Gamecube graphics chip, to calculate the CRC value of an Embedded Frame Buffer (EFB) dump.ppm2mem (tools/ppm2mem)Converts a PPM Image to whatever the output of the function gxuGetTiledImage is.Gamecube PortableThe GC portable was mentioned in a 2003 presentation, note that this is 3 years before the Wii was released on to the market.There was plans to make a console much more powerful than what became the Wii and there was also to be a portable version with a dock similar to the Nintendo Switch.The Dock would even have a place to plug in Gamecube controllers and standard Gamecube Memory cards.References", "excerpt": "The Emerald leak occurred on the 2nd of September 2020 and included about 700MB of content related to the Wii and gamecube. So this would not quite qualify as a “Gigaleak” but it was definitely from the same source as the Gigaleak. Gigaleak - SNES Source Code Leak For more...", "tags": ["wii","leak"], "image": "/public/images/leaks/EmeraldLeak.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Exclusive Sega Saturn Games & Re-releases", "url": "/sega-saturn-exclusives", "content": "If you are interested in reversing a Sega Saturn game it can be useful to see what other platforms the game was released for, however if you don’t have a game in mind then this list can help you choose a game that is not available elsewhere.By reverse engineering these games you are helping to preserve games that are only playable on Sega Saturn, so you can understand how these games work and then help improve emulators to run these games.Games that have never been re-releasedThese are games that are still only available on the Sega Saturn. Some of them may have also been in the arcade using the STV hardware which was based on the Sega Saturn so they are still included in this list 1.Games: Albert Odyssey Astal Battle Monsters Black Fire Burning Rangers Clockwork Knight Clockwork Knight 2 Crimewave Cyber Speedway Dark Savior Deep Fear F-1 Challenge Fighters Megamix Ghen War Golden Axe: The Duel GunGriffon Hang-On GP ‘96 Heir of Zendor High Velocity: Mountain Racing Challenge Highway 2000 International Victory Goal Iron Storm Keio Flying Squadron 2 Mr. Bones Magic Knight Rayheart Mystaria - The Realms of Lore Panzer Dragoon Zwei Panzer Dragoon Saga Robotica Saturn Bomberman Scud: The Disposable Assassin Sega Worldwide Soccer ‘98 Club Edition Shining Force III Shining the Holy Ark Shining Wisdom Shinobi-X Steep Slope Sliders The Story of Thor 2 Torico Valora Valley Golf Victory Boxing Virtua Fighter Remix Virtua Fighter Kids Virtual Casino Virtual Hydlide Virtual Open Tennis Wing Arms Winter Heat World Series Baseball World Series Baseball IIGames that were re-released Athlete Kings (PS2) D&D Collection (PS3) Daytona USA (PS3, X360) Die Hard Arcade (PS2, PS3) Dragon Force (PS2) Fighting Vipers (PS2, PS3, X360) Galactic Attack (iOS & Android) Guardian Heroes (X360) Nights Into Dreams… (PS3, X360) Last Bronx (PS2) Panzer Dragoon (PS2) Radiant Silvergun (X360) Sega Rally Championship (PS2) Virtua Cop (PS2) Virtua Cop 2 (Dreamcast, PS2) Virtua Fighter 2 (PS2 3D Ages)Games that were also on PCThese games are exclusive to the Saturn in terms of games consoles but were also released on PC: Amok Baku Baku Bug! Bug Too! Congo the Movie: The Lost City of Zinj Daytona USA CCE Enemy Zero Frankenstein Galactic Attack Nights Into Dreams… Manx TT Super Bike Virtual-On - Cyber Troopers Last Bronx Panzer Dragoon Scorcher Sega Rally Championship Sega Touring Car Championship Sega Worldwide Soccer ‘97 Sky Target Sonic R The House of the Dead Three Dirty Dwarves Virtua Cop Virtua Cop 2 Virtua Fighter 2Japanese ExclusivesThis post only covers the English exclusive Sega Saturn games, the Saturn was much more popular in Japan so you can view a list of Japan Sega Saturn Exclusives here: List of Sega Saturn Exclusives The Sega Saturn Forum - セガサターン - SegaSaturn.co.ukReferences List of Sega Saturn Exclusives The Sega Saturn Forum - セガサターン - SegaSaturn.co.uk ↩ ", "excerpt": "If you are interested in reversing a Sega Saturn game it can be useful to see what other platforms the game was released for, however if you don’t have a game in mind then this list can help you choose a game that is not available elsewhere. By reverse engineering...", "tags": ["saturn","sega","games"], "image": "/public/images/saturn/Sega Saturn Exclusive Games.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "FMOD Sound Middleware", "url": "/fmod-middleware", "content": "The FMOD audio engine is a very common middleware used in modern games, starting with the PS1 generation of consoles. It was developed by Firelight Technologies and the first release was on 6th March 1995. It is still commonly used in the industry to this very day and has become an industry standard for audio.In Uk magazine Develop issue 79 they give a short review of FMOD back in 2007:You can download the FMOD source code for yourself here but note that it is not open source so it requires a license to use commercially: https://www.fmod.com/downloadGames using FMODFMOD is used in so many games that creating comprehensive a list would be a time consuming process, but some of the major titles include: Guitar Hero III BioShock Metroid Prime 3 Heavenly Sword Call of Duty 4 Starcraft IIWe have also created a list of the Xbox games we know are using FMOD for sound:Xbox Games using FMOD · RetroReversingReverse Engineering games with FMODIf you know your game uses FMOD for audio then it can make the job a lot easier as you have the source code available to you.Plus any reversing work you make on another games fmod module you can apply to your game.Each platform that FMOD supports uses a slightly different implementation tailored to that platform so this post will try to list what we know about fmod compiled for other platforms such as different games consoles.Known Files used on XboxThese files are listed as leftover strings in xbox compiled binaries:, it means that they are being used by Xbox games:fmod\\\\src\\\\sound_software.cfmod\\\\src\\\\system_file.cfmod\\\\src\\\\system_thread.cfmod\\\\src\\\\system_memory.cfmod\\\\src\\\\fsound.cfmod\\\\src\\\\fsound_dsp.cfmod\\\\src\\\\fsound_dsp_fft.cfmod\\\\src\\\\fsound_sample.cfmod\\\\src\\\\fsound_stream.cfmod\\\\src\\\\fsound_tag.cfmod\\\\src\\\\fmusic.cfmod\\\\src\\\\music_formatmod.cfmod\\\\src\\\\music_formatit.cfmod\\\\src\\\\music_formatxm.cfmod\\\\src\\\\music_formats3m.cfmod\\\\src\\\\music_formatfsb.cfmod\\\\src\\\\format_oggvorbis.cfmod\\\\src\\\\format_it.cfmod\\\\src\\\\format_mpeg.cfmod\\\\src\\\\format_fsb.cfmod\\\\src\\\\format_wav.cfmod\\\\ogg_vorbis\\\\ogg\\\\src\\\\framing.cfmod\\\\ogg_vorbis\\\\vorbis\\\\lib\\\\vorbisfile.cfmod\\\\ogg_vorbis\\\\vorbis\\\\lib\\\\info.cfmod\\\\ogg_vorbis\\\\vorbis\\\\lib\\\\block.cfmod\\\\ogg_vorbis\\\\vorbis\\\\lib\\\\psy.cfmod\\\\ogg_vorbis\\\\vorbis\\\\lib\\\\sharedbook.cfmod\\\\ogg_vorbis\\\\vorbis\\\\lib\\\\codebook.cfmod\\\\ogg_vorbis\\\\vorbis\\\\lib\\\\mdct.cfmod\\\\ogg_vorbis\\\\vorbis\\\\lib\\\\smallft.cfmod\\\\ogg_vorbis\\\\vorbis\\\\lib\\\\envelope.cfmod\\\\ogg_vorbis\\\\vorbis\\\\lib\\\\mapping0.cfmod\\\\ogg_vorbis\\\\vorbis\\\\lib\\\\res0.cfmod\\\\ogg_vorbis\\\\vorbis\\\\lib\\\\floor1.cfmod\\\\ogg_vorbis\\\\vorbis\\\\lib\\\\floor0.cReferences", "excerpt": "The FMOD audio engine is a very common middleware used in modern games, starting with the PS1 generation of consoles. It was developed by Firelight Technologies and the first release was on 6th March 1995. It is still commonly used in the industry to this very day and has become...", "tags": ["middleware","gameengines"], "image": "/public/images/middleware/FMOD Sound Middleware.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Original F-Zero Source Code (Gigaleak)", "url": "/f-zero-source-code", "content": "The Nintendo Gigaleak preserves a small but unusually useful F-Zero source archive under other/SFC/ソースデータ/FZERO.This is not just a loose dump of assembly files.It preserves the main game code, a dated title page, multiple regional build variants, and a whole suite of C tools that converted maps, panels, characters, rivals, bombs, and perspective data into the formats the game actually used. Gigaleak - SNES Source Code Leak For more information on the rest of the Gigaleak check out this post. At a GlanceThis archive is especially useful because it preserves both halves of the project at once: the game-side 65C816 assembly for the shipped SNES codebase the PC-side asset pipeline used to build tracks, screen layouts, background data, and sprite graphicsIt also preserves some genuinely nice historical details: TITLE.DOC dates the original program to 1 April 1989 - 1 September 1990 the SNES revision is dated 27 February 1991 - 14 May 1991 the credited programmers are Y. Nishida, M. Kimura, and S. Yamashiro most of the tools still identify the project by the older internal name CAR RACE the build scripts show a mixed regional codebase rather than a single clean PAL branchRoot directory (SFC.7z/ソースデータ/FZERO)When the Gigaleak SFC.7z archive is extracted it contains the source for several Super Famicom projects.This post covers everything in the FZERO directory.This folder contains the following sub-directories: FZERO The archive is split very neatly into the game itself and the DOS-side tools used to generate its content. 📁 Game Assembly source code for the game 📁 Tools C source code for the tools used to make the game That split is one of the best things about this leak.It means the page can show not only what the F-Zero source code looked like, but also how Nintendo’s team prepared the maps, screen data, sprite characters, and compressed background assets that fed into it.How Complete This LooksThis archive looks much closer to a real working source snapshot than a token sample.The strongest signs in its favour are: the Game folder has the main program modules, headers, data files, regional variants, and makefiles the Tools folder preserves the PC-side content pipeline rather than just the final game code the makefiles name a coherent set of source modules and a standard build flow using as65c, link, load, and inspThat said, it is still safer to call this a near-complete source snapshot than a guaranteed fully self-contained rebuild package.What is still missing or uncertain: the actual Nintendo assembler, linker, loader, and symbol tools are not included here the folder does not preserve built .rel, .map, .sym, or .hex outputs some SDK-level environment details may still have lived outside this copied folderSo the important distinction is:the archive appears to preserve most of the real F-Zero source and tooling, but the leak page should not claim with full confidence that every last dependency needed for a clean rebuild is present unless the code has actually been rebuilt successfully.There is one extra provenance detail worth noting here.The same Game and Tools tree also survives under other/NEWS/FZERO, and that NEWS copy appears twice because the archive contains both NEWS/FZERO and NEWS/FZERO/FZERO.Content-wise though, that does not currently change the picture.The NEWS Game and Tools folders match the other/SFC/ソースデータ/FZERO copy exactly, so it looks like a duplicated workstation-side copy of the same source snapshot rather than a separate branch with extra code.Game (/Game) /Game This folder contains the main 65C816 assembly source for F-Zero on the SNES.Internally the project is still often called CAR RACE, which makes the archive feel much closer to a live development tree than a cleaned-up release package. What TITLE.DOC RevealsTITLE.DOC is much better than a generic metadata note.It gives a compact project history for the codebase: Field Value Title F-ZERO Author Nintendo Co., Ltd. Completion year 1990, 1991 Original program April 01, 1989 - September 01, 1990 Revision for SNS February 27, 1991 - May 14, 1991 Programmers Y. Nishida, M. Kimura, S. Yamashiro That is an unusually nice preservation detail because it shows the SNES release as a revision of an older codebase, not a project that simply appeared fully formed in 1991.How the SNES Build WorksThe build scripts make the toolchain very clear.Both makefile and fzero_pal.make assemble every .asm file with as65c, then link the resulting .rel files with link, convert the linked image with load, and finally produce a symbol file with insp. Output Role .rel Assembled object output for each source file .map Linker map .sym Symbol file generated by insp .hex Final linked output image The regional split is more interesting than the old page suggested.The main makefile produces fzero_usa2.hex, while fzero_pal.make produces fzero_pal.hex.The PAL build is not a completely separate source tree.It mixes fzero_main.asm with play_main_pal.asm, but still pulls in several *_usa modules such as title_main_usa, calculate_usa, set_bg2_usa, and game_over_usa.That makes the archive look more like a branch stack of targeted patches than a set of fully isolated regional folders.Interesting Game-Side DetailsSeveral files are much more revealing than their names make them sound: fzero_main.asm is the real entry module and main mode dispatcher, with a four-state Mode_vector for title, select, gameplay, and game-over flow fzero_main_usa2.asm contains an explicit BUG routine and extra bug-fix logic not present in the base file control_data.asm is a huge tuning/data file for car handling, speed, friction, damage, turbo jet positions, credits text, and prerecorded demo stick input data-5.asm is not just “track data” in the abstract - it explicitly lays out Course_address, Free_address, and Map_data_number tables for the main cups and free-run/ending sequences game_over.asm includes the full staff roll flow and reads directly from Staff_roll_data title_main.asm and play_main.asm still preserve commented debug code and developer-only scene-selection hooksOne especially neat detail is set_back.The folder contains both set_back.asm and a second older set_back file with no extension.The extensionless file still carries the older 1990 copyright block and only credits Y. Nishida, so it looks like an earlier source snapshot that was kept alongside the later SNES revision.The files in this folder are described in the table below: File Name Extension Description ALPHA N/A Header/include file defining the encoded letter tokens used throughout text and credits data ALPHA2 N/A Secondary encoded text/character constants ANK N/A ANK character font graphics in assembly format ANK8 N/A Additional text/character constants BUFFER N/A Main runtime buffer definitions for gameplay state RP5A22_ N/A 65C816 / SNES CPU register definitions RP5C77_ N/A SNES PPU register definitions TITLE .DOC Full project title sheet with development dates and programmer credits VARIABLE N/A Main gameplay variable definitions WORK N/A Work RAM layout definitions calculate .asm Scoring, lap, and prerecorded demo-stick logic calculate_usa .asm Regional variant with a different Demo_stick_data location car_control .asm Car movement, drift, and jump/control behaviour control_data .asm Core tuning data: acceleration, top speed, grip, damage, credits text, and demo input tables data-5 .asm Course tables, start points, and cup/free-run map assignments data-6 .asm Rival and AI-related tuning data effect .asm Visual effects such as shadows, lasers, and other race feedback en-check .asm Enemy visibility and state checks en-data-1 .asm Enemy object/OAM data en-data-2 .asm Additional enemy object/OAM data en-drive .asm Rival driving logic and AI speed/acceleration handling en-init-1 .asm Enemy initialization routines en-init-3 .asm Course/open-drive setup tied to Course_address en-init-4 .asm Additional enemy initialization routines fzero_main .asm Main entry module and top-level mode dispatcher fzero_main_pal .asm PAL startup variant with PPU mode changes fzero_main_usa2 .asm USA revision with explicit bug-fix code fzero_pal .make PAL build script game_over .asm Game-over flow, pause logic, and staff roll handling game_over_usa .asm USA variant with changed roll data makefile N/A Main USA2 build script play_main .asm Gameplay state setup and main loop support play_main_pal .asm PAL gameplay variant with 50 Hz timing adjustments player .asm Player car logic including crashes and edge-case fixes set-obj .asm Object setup routines for smoke, explosions, and race objects set_back N/A Older no-extension copy of the background-screen setup module set_back .asm Background and HUD/screen setup module set_bg1 .asm World/slit transfer and BG data handling set_bg2 .asm Perspective/background calculation set_bg2_usa .asm USA variant with altered title/background data sound .asm Race music and sound-effect logic title_main .asm Title screen and car-select flow title_main_usa .asm USA title-screen variant with changed cursor/title data Tools (/Tools) /Tools This folder is the real production pipeline for F-Zero.It contains the DOS-side C programs and helper assembly routines used to turn editable map, panel, screen, and graphics data into the game-ready formats consumed by the SNES code. What the Toolchain ShowsNearly every tool still calls the project CAR RACE and most of them were written by Y. Nishida between 1989 and 1990.That makes this folder one of the clearest preserved examples of Nintendo’s early SNES content pipeline in the leak. Tool Version/date in source header What it does carmap.c version 1.01 - May.18, 1989 Early map generator from .TBL and .SCR chrar.c version 1.01 - Mar.27, 1989 Character data archiver for CAR RACE II enemy.c version 1.02 - Jul.21, 1989 OBJ character archiver for enemy graphics mkback.c version 1.00 - Feb.08, 1990 Background-screen compressor mkpers.c version 1.00 - Feb.09, 1990 Demo perspective-data compressor mkpanel.c version 1.10 - Apr.10, 1990 Panel generator producing .PCK and .PNL setbomb.c version 1.21 - Apr.20, 1990 Bomb-placement generator from map/panel/slit/world data mkmap.c version 3.20 - May.10, 1990 Much later map generator for a 32*16 world mkspchr.c version 1.20 - May.21, 1990 OBJ character compressor slitpress.c version 1.00 - May.28, 1990 Slit-data compressor producing .SLT2 mkbgchr.c Jun.06, 1989 Converts 8-bit source graphics into Mode 7-ready character data armap.c version 1.20 - Jun.25, 1990 Packs map data into archived output That version spread is useful because it shows the tooling matured alongside the game.carmap.c is an early 1989 generator, while mkmap.c is a much later 1990 rework for a larger world layout.Likely Asset PipelineThe file extensions make much more sense once the tools are viewed together as one workflow: Extension Likely role in the pipeline .SCR Per-screen source layout input .TBL Character/tile lookup or source-table input .PCK Packed panel data .PNL Panel-layout data .WTB World table input .WLD Generated world data output .SLT Slit data used by the perspective/road system .SLT2 Compressed slit-data output .MAP Generated or archived map package .CHR Character/tile graphics .OBJ Object/sprite source graphics .CGX 8-bit graphics source converted into SNES-ready character data mkmap.c is especially revealing here.It reads a .PCK panel file and a .WTB world-table file, then generates .SLT and .WLD outputs.It even prints Map data generator for CAR RACE version 3.20 ( 32*16 world ), which is a very direct clue about the map format it expects.The files in this folder are described in the table below: File Name Extension Description armap .c Map-data archiver that packs .MTB input into .MAP output carmap .c Early map generator that reads .TBL and .SCR data and emits .MAP chrar .c Character-data archiver used to pack CHR resources cmpbuf .s Assembly source file containing an efficient buffer comparison routine cmppnl .s Helper routine for comparing candidate panels against the panel buffer enemy .c OBJ character-data archiver for enemy sprite graphics mkback .c Background-screen compressor mkbgchr .c Converts .CGX 8-bit source art into screen/Mode 7 .CHR data mkenemy .c Enemy-car character-data archiver mkmap .c Later map generator that turns .PCK and .WTB into .SLT and .WLD mkpanel .c Panel generator that turns .TBL input into .PCK and .PNL mkpers .c Demo perspective-data compressor mkrival .c Rival-car character-data archiver mkselect .c Car-select screen compressor mkspchr .c OBJ character compressor that creates OBJECT.CHR schpnl .s Panel-search helper used by the panel generation path setbomb .c Bomb-placement generator using .PNL, .WLD, and .SLT slitpress .c Slit-data compressor that turns .SLT into .SLT2 The cards below are easier to follow when grouped by role.Taken together they look like a rough production pipeline for building F-Zero’s race worlds and visual assets.Map and World ToolsThese are the top-level world-building tools.They generate or archive the main race data, assemble world layouts, and place gameplay objects such as bombs.Map and World Tools armap.c unshort pointer[32] unshort length[32] int counter int address int datasize main(int argc, char* argv) set_mapname(char* ss) archive(char* fname, FILE wp) save_pointer(char* fname) 4 7 136 carmap.c arptr sltptr[MAXSLT] unchar pnlbuf[MAXPNL][4] unshort sltbuf[MAXSLT][16] unshort rombuf[MAXROM][16] unshort wldbuf[WLDLNY][WLDLNX] unshort sltofs[MAXSLT] int pnlcnt int sltcnt int romcnt int wldcnt int sltlen int clrcode main(int argc, char* argv) set_sname(char* ss) makemap(int nn, char fname) chkclr(unchar *buf) setpnl(unchar *pnl) setslt(unshort *slt) setroom(unshort *rom) setwld(unshort wld) memcmp(register unchar *s1, register unchar *s2, register intnn) memcpy(register unchar *dd, register unchar *ss, register int) arslit() fit_slit(int ln, int sc) int_slpt() st_slofs() genmap(char *fname) genpnl(FILE *wp, int ad) genslt(FILE *wp, int ad) genrom(FILE *wp, int ad) genwld(FILE *wp, int ad) 19 20 500 mkmap.c arptr sltptr[MAXSLT] unshort sltofs[MAXSLT] unshort pnlofs[MAXPNL] unchar pnlbuf[MAXPNL *4] unshort sltbuf[MAXSLT][16] unshort rombuf[MAXROM][16] unshort wldbuf[WLDLNY][WLDLNX] int pnlcnt int sltcnt int romcnt int wldcnt int pnllen int sltlen int errcnt int slttop int clrcode main(int argc, char* argv) set_sname(char* ss) int getaddr(char* str) readpnl(char* fname) makemap(int nn, char fname) chkclr(unchar *buf) chkpnl(unchar *pnl) setslt(unshort *slt) setroom(unshort *rom) setwld(unshort wld) prsslt() fit_slit(int ln, int sc) int_slpt() st_slofs() genmap(char* wld_name, char* slt_name) genslt(FILE *wp) genrom(FILE *wp) genwld(FILE *wp) 18 18 475 setbomb.c unchar pnlbuf[MAXPNL] unchar sltbuf[MAXSLT] unchar wldbuf[MAXWLD] unchar rombuf[MAXROM] struct STACK bomb[MAXBOMB] int bombct int romcnt int romptr int sltptr int pnlptr int sltofs main(int argc, char* argv) set_bomb() push_pos() search(int loc_x, int loc_y) sch_room(int loc_x, int loc_y) int getaddr(char *str) readpnl(char *fname) readwld(char *fname) readslt(char *fname) makewld(char *fname) 10 12 291 Panel and Slit ProcessingThese are the bridge tools between raw screen data and the final world/map outputs.They handle packed panel data and compressed slit data for the road/perspective system.Panel and Slit Processing mkpanel.c arptr pnlptr[MAXPNL] unshort pnlofs[MAXPNL] unchar pnlbuf[MAXPNL][4] int pnllen int pnlcnt int clrcode main(int argc, char* argv) set_sname(char* ss) mkpanel(int nn, char fname) chkclr(unchar *buf) setpnl(unchar *pnl) prspnl() fit_panel(int ln, int sc) int_pnpt() st_pnofs() genpck(char *fname) genpnl(char *fname) 11 8 325 slitpress.c main(int argc, char* argv) void press_slit(FILE *rp, FILE *wp) void fputw(int data, FILE fp) int fgetw(FILE *fp) 4 2 97 Character and Sprite ToolsThese are the asset-packaging tools for vehicles, objects, and SNES-ready character graphics.Character and Sprite Tools chrar.c int chrlen[6] int chralc[6][40] char chrbuf[DSIZE][32] main(int argc, char* argv) archive(int mo,FILE *tp, FILE *wp) flip(unchar *dat, *buf, int len) getnum(FILE *fp) readchar(int argc,char **argv, buf) 5 7 156 enemy.c struct patndata pat[12] short patn00[24] short patn01[20] short patn02[12] short patn03[9] short patn04[6] short patn05[4] short patn06[2] short patn07[1] short patn08[12] short patn09[6] short patn10[4] short patn11[2] unchar chrbuf[DSIZE][32] int chrcnt int total main(int argc, char* argv) init_ptr() set_cname(char* ss) archive(FILE *wp, char dat) getnum(char* dat) readchar(char* fname) 6 18 221 mkbgchr.c unchar chrdat[DATSIZE] unchar chrbuf[BUFSIZE] main(int argc, char * argv) chread(char *fname,*buff, int size) chwrite(char *fname,*buff, int size) convert(unchar *data,int size) archive(unchar *data,*buff,int size) getbnk(unchar *data) 6 7 150 mkenemy.c struct patndata pat[10] short patn00[24] short patn01[15] short patn02[12] short patn03[6] short patn04[4] short patn05[1] short patn06[12] short patn07[6] short patn08[2] short patn09[9] unchar chrbuf[DSIZE][32] int chrcnt int total main(int argc, char* argv) init_ptr() set_cname(char* ss) archive(FILE *wp, char dat) getnum(char* dat)char *dat readchar(char* fname) 6 16 212 mkrival.c struct patndata pat[10] short patn00[24] short patn01[15] short patn02[12] short patn03[6] short patn04[4] short patn05[1] short patn06[12] short patn07[6] short patn08[2] short patn09[9] unchar chrbuf[DSIZE][32] int chrcnt int total main(int argc, char * argv) init_ptr() set_cname(char* ss) archive(FILE *wp, char dat) getnum(dat)char *dat readchar(fname)char *fname 6 16 209 mkspchr.c struct data header[34] unchar chrbuf[DSIZE][32] int chrcnt int bincnt main(int argc, char* argv) void make_data(FILE *fp) int make1(FILE *fp, int code, int cnum, int leng) int make2(FILE *fp,int code, int cnum, int leng) int make3(FILE *fp, int code,int cnum, int leng) int make4(FILE *fp, int code,int cnum, int leng) int wthalf(char *buff, FILE fp) int read_char(char* fname, int code, int size) 8 11 234 Compression and Screen-Specific ToolsThese are the smaller helper tools for particular presentation tasks such as background compression, demo perspective data, and the car-select screen.Compression and Screen-Specific Tools mkback.c int bincnt int norcnt int comcnt2 int comcnt3 int nulcnt main(int argc, char * argv) void make_data(FILE *rp,*wp) write_data(int code, int cnt, FILE wp) 3 7 127 mkpers.c int bincnt main(int argc, char* argv) void make_data(FILE *rp,*wp) fgetnum(unshort *num, FILE rp) fputnum(int num, FILE wp) 4 4 98 mkselect.c int bincnt int norcnt int chrcnt int atrcnt main(argc,argv)int argc char * argv void make_data(FILE *rp,*wp) int write_char(FILE *wp, int len) int write_attr(FILE *wp, int len, unchar buf) 4 8 120 ", "excerpt": "The Nintendo Gigaleak preserves a small but unusually useful F-Zero source archive under other/SFC/ソースデータ/FZERO. This is not just a loose dump of assembly files. It preserves the main game code, a dated title page, multiple regional build variants, and a whole suite of C tools that converted maps, panels, characters,...", "tags": ["snes","leak","sourcecode"], "image": "/public/images/snes/SNES F-Zero Source Code.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Fairchild Channel F Reverse Engineering", "url": "/fairchild-channel-f", "content": "Introduction to Fairchild Channel FWelcome to our page dedicated to Fairchild Channel F reverse engineering! The Fairchild Channel F was the first video game console to use programmable cartridges, and was released in 1976.If you’re interested in learning more about the technical aspects of this groundbreaking console and how it works, you’ve come to the right place. On this page, we’ve compiled a list of links to other pages that cover various topics related to Fairchild Channel F reverse engineering.Whether you’re interested in understanding the hardware architecture of the console, analyzing game code, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to. So grab your joystick and get ready to dive into the exciting world of Fairchild Channel F reverse engineering!HardwareIf you’re interested in reverse engineering software for the Fairchild Channel F console, it’s crucial to have a thorough understanding of the hardware that powers it. By comprehending the inner workings of the Channel F hardware, you can better comprehend how the software interacts with the hardware and how you can potentially modify or improve it.In this section of our guide, we will provide you with comprehensive information and resources on the hardware of the Fairchild Channel F, including retail, prototype, and development hardware.Development Kit Hardware Fairchild released a development kit which came with a book titled F8 Guide to Programming, if you were a developer at the time who wanted to write games for the Channel F then this would be the go-to book! ", "excerpt": "Introduction to Fairchild Channel F Welcome to our page dedicated to Fairchild Channel F reverse engineering! The Fairchild Channel F was the first video game console to use programmable cartridges, and was released in 1976. If you’re interested in learning more about the technical aspects of this groundbreaking console and...", "tags": ["console"], "image": "/public/generated/placeholders/fairchild-channel-f.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Introduction to Game File Formats", "url": "/games/fileformats", "content": "Introduction to Game File FormatsWith the advent of Disc-based video games, developers were free to separate games into multiple files, such as audio, textures, sprites, 3d models etc.Before disc based games, games used to all be on a single rom chip which could be thought of as a single file with all the assets and game code in one large binary file.What are the benefits of external files?It was much easier for artists or sound designers to modify the game and test on hardware if all they needed to do was replace a single file, instead of the old days when everything needed to be compiled into one.It is also more efficient in terms of memory as it only needs to load certain files at certain times, although as it is disc-based it adds loading times to the game.Another benefit is that it makes it much easier for modding of the game if you are only interested in changing music/textures/models/text then it can be as simple as finding the correct file.But what about performance?There is a performance issue with loading hundreds of small files from a cd so games tended to create their own binary blobs of concatenated (and sometimes compressed) smaller files.This makes some games similar to ROMS in that everything is packed in a single file, this makes loading from disc faster in theory but the bigger the data file the slower it will be.Are game formats standard?Some are and some are custom formats created by the developers for efficiency, in more modern games you will get files like .mp3, .dds, .png etc.Some are from middleware providers such as .bik files which play using the Bink video middleware.Game Formats by PlatformAlthough game formats can be used across multiple games consoles or platforms, we have separated the file formats by platform to make it easier to see the files a developer would be working with when developing for a specific platform. Platform Name Game Engine List Nintendo Gamecube Nintendo Gamecube (Dolphin) File Formats Nintendo WiiU Wii U File Formats Sony Playstation 1 Playstation 1 File Formats Reversing File FormatsReverse Engineering the .car File Format (Compiled Asset Catalogs)The Timac blog features an excellent write-up about reverse engineering the .car (Compiled Asset Record) file format used by Apple in iOS and macOS applications.The analysis reveals the undocumented binary structure, identifying it as a specialized BOM (Bill of Materials) file comprised of distinct blocks (CARHEADER, KEYFORMAT) and trees (RENDITIONS, FACETKEYS). The post includes source code for a tool (CARParser) built using private Bom.framework APIs to extract asset data, such as images, colors, and their metadata. Reverse engineering the .car file format (compiled Asset Catalogs) Timac's blog details the reverse engineering of Apple's undocumented .car file format, explaining its BOM structure, header blocks, and how to programmatically parse Asset Catalog data. Reverse Engineering Casio’s .CR5 File FormatAtharva’s Website features an excellent write-up detailing the reverse engineering of Casio’s proprietary .CR5 file format, used by the CTK-810IN keyboard for storing registration memory setups. The author performed differential analysis and hexdumping to determine the file structure, identifying the 12-byte header and the 32 repeating 22-byte setup structures. The process culminated in a Python script capable of parsing the binary data and displaying human-readable settings, successfully laying the groundwork for a custom Casio SMF converter. Reverse Engineering Casio's .CR5 File Format Atharva Vaidya provides a detailed guide on reverse engineering the Casio .CR5 binary file format, including differential analysis, identifying big-endian structures, and the final Python parsing script. ", "excerpt": "Introduction to Game File Formats With the advent of Disc-based video games, developers were free to separate games into multiple files, such as audio, textures, sprites, 3d models etc. Before disc based games, games used to all be on a single rom chip which could be thought of as a...", "tags": ["fileformats"], "image": "/public/generated/placeholders/games-fileformats.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game Boy Advance (AGB) Development Kit Hardware", "url": "/game-boy-advance-development-kit", "content": "Official Development Kit HardwareThe Game Boy Advance official development kits were incredibly similar to the original Game Boy and Game Boy Color devkits. In fact they reused the same dev kits and added support for the GBA.Early Prototype Development kit (Target Board TS2) This is as bare-bones as development kits get, before the GBA was even released to the public a select few developers were sent these kits. It uses a Super Nintendo controller as input and has a small LCD screen attached to the board 1. You can see a modified original Game Boy cartridge with the sticker saying AGB Only plugged into the cartridge slot and acting as an interface to the developers PC. So presumably they would send ROM images to the board from their PC’s development environment. Presumably it also had a connection to be able to display it on a larger screen for development but there is no obvious connector for that. There are references in the Software Development Kit to Target Board TS2 which we believe is this development kit, not sure what TS2 stands for but there is also a TS4, (Testing Station?). Nintendo Game Boy Advance Wide-Boy Similar to the Wide-Boy for the original and Color Game Boys, Intelligent systems created one for the Game Boy Advance that plugged into the Nintendo 64 2. Just as with previous systems all the GBA hardware is packed inside the cartridge and it comes with a GBA shell that is purely used as a controller. This device was used for play testing and demoing games internally along with it being used by press outlets for most of the GBA screenshots that were printed in magazines and books. IS-AGB-EMULATOR (IS-AGB-DEBUGGER) The IS-AGB-EMULATOR is the next iteration of the IS-CGB-EMULATOR with support for Game Boy Advance games, just like its parent generation it is used as the main development kit for GBA. If the IS-AGB-DEBUGGER label is checked on the unit then it also contains support for programmers to use debugging features such as breakpoints and tracing. A custom GBA controller is attacted to the IS-AGB-EMULATOR to play the games, one of which has been documented by Developer Jeff on his Twitter:Prototype Nintendo Gameboy Advanced in unreleased Lemon Yellow! This system went with the IS CGB/AGB Emulator kit ver.1 and works as an controller unit for the device. More photos & a teardown coming soon of this unique rarity including its emulator box so stay tuned!-Jeff pic.twitter.com/B8F5zFOokc— Developer Jeff 🕹️ (@OfficialDevJeff) January 22, 2021IS-AGB-MIDI For sound developers, Intelligent Systems created the IS-AGB-MIDI which is a cartridge that plugs into the IS-AGB-EMULATOR 3, not the GBA cartridge itself 4. You then connect the cartridge to a MIDI device such as a keyboard via the 5-PIN DIN connector MIDI port, and you have the ability to test sounds and music to hear what they would sound like on real GBA hardware! All of the information and images related to IS-AGB-MIDI are thanks to long term friend of the site, Gerry who runs his own website with all sorts of retro game development goodness https://www.behindthecode.ca/is-agb-midi-music-dev-cart/. If you are interested in more information about game development hardware, his site is a must visit! Gerry also shows the device in his excellent video about the IS-AGB-EMULATOR below: IS-AGB-CAPTURE Similar to the WideBoy64 and also created by Intelligent Systems comes the IS-AGB-CAPTURE. Its main purpose is to display the GBA game on a big screen for easy capturing of screenshots. Presumably the only advantage this has over the Wide Boy is that it doesn’t; t require an N64 to function. The screenshot on the left is from Andrew Borman on Twitter 5. IS-AGB-CHARACTER In order for artist to view and create pixel art optimized for the Gameboy Advance screen, Intelligent Systems create the IS-AGB-CHARACTER development hardware. The Cartridge looks like a standard Gameboy Color cartridge with a ribbon cable sticking out that connects to a standard PC parallel port. It was also bundled with software for Windows XP that you can see in this tweet from BehindTheCode:Check this out!This is the \"IS-AGB-CHARACTER\" a dev cartridge by Intelligent-Systems for #Gameboy Advance.Unit interfaces to a dev PC using a parallel LPT port & is used in tandem with an IS-AGB-EMULATOR for editing Color pallets, textures and OBJ animation files. #RETROGAMING pic.twitter.com/Fzvq6yQtuZ— BehindTheCode (@GerryRobotics) March 4, 2021AGB FLASH GANG WRITER Again similar to the Game boy DMG & Color development kits they provide a Gang writer for flashing multiple EPROM cartridges at once, very useful for sending out multiple copies to all the press outlets 6. Not only are they similar to the original gang writers Intelligent Systems actually refurbished old DMG Flash Gang writers into GBA flash gang writers! Third Party Development kits (Devkits)The official Development kits offered by Intelligent Systems through Nintendo were very costly so many smaller third party development studios had cheaper alternatives.Flash cartridges (Flash2Advance & others)A surprisingly common method of development was to use unlicensed Flash cards which were often used for piracy along with an emulator on PC such as no$gba.Many retail games were developed using this very cheap method including big names such as Hot Wheels Stunt Track Driver and Matchbox Emergency Patrol 7.Sn Systems Pro-DG SN Systems released their Pro-DG development kit for Game Boy Advance in March 2001 the same month that the retail GBA hit store shelves in Japan 8. It cost £1,700 but the development kit is only sold to developers who are licensed by Nintendo so consumers could not buy these development kits 9. According to the official product sheet the development kit consists of the following hardware: Development GBA console 32MB Cartridge emulator (custom cartridge) SCSI card for connecting to the PC View the official Pro-DG GBA product sheet on the Wayback Machine Although the GBA is listed as a development version it seems to just be a retail console with a slight modification of the power source 10. ProDG connects to the developers PC running Visual Studio through a SCSI cable that connects to the custom cartridge. The photos on the left are by Nicholas Cottrill who has an excellent Flickr account full of cool development kit photographs 11! SN Systems Flash ROM Cartridge for Game Boy Advance Although it says SN Systems on it, it was not available as part of their ProDG development kit and was actually a completely separate product. Although it looks like a standard DMG cartridge it actually had a Game Boy Advance ROM on it and had a microUSB port in the top of the cartridge for connecting to a developers PC. One cool feature of the cartridge for development was that it saved game states of crashed games that could be copied over to PC to debug further, they called this feature Post-Mortem Debugging 12. References Game Boy Advance Development Kit Revealed - IGN ↩ Nintendo Game Boy Advance Wide-Boy (for N64) ↩ Game Boy Advance TS Board - ASSEMbler Games Archive ↩ Behind The Code with Gerry IS-AGB-MIDI  ↩ Andrew Borman on Twitter: “People talk about the best ways to play Game Boy games. They talk about Super Game Boys, Game Boy Players (with or without mods), and even some development equipment like the Wideboy. But rarely does the IS-AGB-Capture come up. https://t.co/i4xJUycSaz” / Twitter ↩ Project Pokemon Forums ↩ Writing a Game Boy Advance Game - Hacker News ↩ Gamasutra - SN Systems Releases ProDG for GameCube and Game Boy Advance ↩ GameBoy Advance Dev’rs - Hardware ↩ Nintendo Game Boy Advance ProDG Development Kit ↩ Prodg Gameboy Advance - Nicholas Cottrill ↩ Flash ROM Cartridge for Game Boy Advance ↩ ", "excerpt": "Official Development Kit Hardware The Game Boy Advance official development kits were incredibly similar to the original Game Boy and Game Boy Color devkits. In fact they reused the same dev kits and added support for the GBA. Early Prototype Development kit (Target Board TS2) This is as bare-bones as...", "tags": ["gba","devkit","hardware","snsystems"], "image": "/public/images/gba/Game Boy Advance Development Kit Hardware.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game Boy Advance Software Development Kit (SDK)", "url": "/game-boy-advance-sdk", "content": "Introduction This page covers release 3.0 of the english software development kit, but the other versions are very similar to this. It is unclear if this was the last release of the development kit. In the documentation Nintendo calls this SDK the GameBoy Advance Developers Kit 2000 presumably due to using the millennium/2000 was very trendy at the time. This was distributed to developers as a windows installer called AGBSetup.exe which would by default install it into a folder called /agb for Advanced Game Boy, so when upgrading the SDK it tells developers to delete the contents of the /agb directory before updating. Japanese SDKAs Nintendo is a Japanese company the SDK was originally created in Japanese and localised to English, however there are a few differences between the development kits.The Japanese version also includes the Mobile System GB SDK which was a Japanese only accessory to link gameboys together via a mobile phone interface.Tools (/bin folder)This folder contains useful command lines tools for GBA development compiled for Microsoft Windows. File Name Extension Description AGBLOAD .exe Tool to load ROM into the IS-AGB-EMULATOR hardware NRDC .exe Calculates the CRC checksum for a GBA ROM (for more info see AGB_CRC.txt in /docs) act2agb .exe Converts an Adobe Photoshop .ACT (Adobe Color Table) file to a GBA Palette in C source code form agbcomp .exe Compresses binary data using either LZ77 or Huffman encoding agbparts .exe Converts a bitmap image into 8x8 pixel parts useful for an optimized tileset or even sprites bin2h .exe generates a C header file from the Binary result of objcopy bmp2agb .exe Converts BMP images to either binary or text with optional compression bmp2bin .exe Converts BMP files to binary formats .imb (Image Binary) and .plb (Palette Binary) bmp2map .exe Converts BMP files to C-source code based on 8x8 pixel tiles bmpgrid .exe Splits up a Bitmap into tiles/partitions based on input width/height (minimum 8x8) bmpred .exe, .sh Reduces the colors of a BMP image using a specified palette sgi2bmp .exe Converts an SGI format image into a BMP format image Documentation (/doc folder)This folder contains all the documentation provides for the various tools and libraries provided in the Game Boy Advance SDK. File Name Extension Description AGB_CRC .txt Describes usage of the tool nrdc.exe for calculating the CRC checksum for a GBA ROM CompilerBugFix .txt This text file lists the differences in a patch applied to the cygwin toolchain (for 000512 -> 000513) (2001/2/6) relnotes_rel3 .txt List of changes in version 3.0 of the SDK relnotes_us .txt Notes the differences between the English US SDK and the Japanese version toolsSetup .txt Instructions for installing the SDK and connecting to the development kit hardware AGB Programming Manual AGB Programming Manual The AGB programming manual is available in both PDF format (AGBProgramming Manual.PDF) and HTML format (/AllManual/program). It is 163 pages explaining pretty much everything you need to know to start programming for the GBA hardware: Memory Map Background rendering (Both Character and Binary modes) Playing sounds DMA Joypad input Interrupts Communication interfaces AGB Backup Library Manual Backup Library Manual The AGB Backup Library manual is available in both PDF format (AGBBackupLibraryManual.PDF) and HTML format (/AllManual/backup) and covers the Save RAM (SRAM) available built in to certain cartridges. This documents the use of the libagbbackup.a static library which MUST be used to communicate with the different Save Game Backup chips on the cartridge, as Nintendo forbids not using this library to access the data (presumably for Save Game Safety). The available SRAM chips on the GBA cartridges were: 256kbit SRAM 512kbit FLASH ROM 4kbit EEPROMThey had also planned support for 1Mbit DACS but this was never released.Each type of backup chip had its own set of functions and their own header files as listed below: SRAM - AgbSram.h and AgbSramFast.h FLASH ROM - AgbFlash.h EEPROM - AgbEeprom.hSRAM LibraryThe difference between the two header files comes down to memory vs cpu optimization, the Fast version is more efficient on the CPU but uses 300 extra bytes of Work RAM (WRAM). Apart from the difference in memory usage they are identical.AGB System Call Reference System Call Reference The AGB System Call Reference manual is available in both PDF format (AGB System Call Reference.PDF) and HTML format (/AllManual/syscall). This is a 35 page document listing all of the system calls available from the Syscall (libagbsyscall) library to use in your application, such as functions like BgAffineSet or CpuFastSet. it is standard API documentation giving an explanation all the parameters and return type and a little about what the functions achieve. AGB Register List Register List The AGB Register List is available in both PDF format (AGBRegList.PDF) and HTML format (/AllManual/register). It contains a large table of all the addresses of hardware registers, their names and what each bit does. This is an extremely helpful document when reverse engineering GBA games as games will often need to read or right to these registers to access the hardware features of the device. These hardware Registers are used for many things including: Reading Game Pad buttons Communication over Link cable Sprite Management Sound Management Direct Memory Access (DMA)AGB Data Format Data Format The AGB programming manual is available in both PDF format (AGBDataFormat.PDF) and HTML format (/AllManual/dataformat) and contains the format that data should be in for certain parts of memory, especially related to graphics. There are a few areas of memory that need to be in a specific format: Pallette RAM (5 bits for Red, 5 for Green and 5 for Blue) Background Data (Different format for Character mode vs Bitmap mode) Sprite Data/OAM - X/Y position of sprites and the image to show If you are creating a GBA game you need to follow these Data Formats otherwise the screen will look corrupt, most emulators will be able to help you out with their VRAM viewer windows. ARM7TDMI Reference Manual by ARM ARM7 TDMI The ARM7TDMI Reference Manual is a PDF specification (/AllManual/arm/ARM7TDMI_Ref_man.pdf) provided by ARM that has 275 pages of pretty much everything you would ever want to know about the CPU used in the Game Boy Advance. As this is a reference I wouldn’t recommend reading it and instead just refer to it if you are looking into how a particular feature of the CPU works. You can reverse and create games without ever having opened this manual but when anytime you wonder about the Coprocessor or assembly instruction timings then this is a great reference. AGB IR Communication Library Manual IR Communication Library The AGB IR Communication Library manual is available in both PDF format (AGBIRCommLibraryMan1.0.PDF) and HTML format (/AllManual/ir) and covers the very low level technology details of how the IR interface works at the hardware level. For using the IR communication library in a game see the AGB Infrared Comm Programming Guide instead. AGB Infrared Communication Programming Guide IR Programming Guide The AGB Infrared Communication Programming guide is available in both PDF format (AGBInfraredCommProgGuide.PDF) and HTML format (/AllManual/ir) and covers programming for use with the Infrared Adapter. The GBA Infrared Adapter (AGB-006) was an accessory that was released 2 years after the GBA and only ever used in 1 Japanese game called Cyber Drive Zoids. As the hardware is now quite rare and it was only ever used for one game this documentation will most likely not be useful to anyone reverse engineering or creating a new GBA game.However Shonumi has written an excellent Edge of Emulation article on implementing an emulated version of the Infrared adaptor and even created a virtual Zoid (Robot): Edge of Emulation: GBA Infrared Adapter Check out the Edge of Emulation article on emulating the GBA Infrared Adapter Frequently Asked Questions (/AllManual/faq) /faq This folder contains Frequently asked questions in HTML format for Game Boy Advance Development split into the following categories: General - Questions about GBA development that don’t belong to a specific category Graphics - Questions about drawing sprites (Objs) and Backgrounds Sound - Questions related to playing sound and the IS-AGB-MIDI hardware Communication - Questions about Linking Game Boy Advance consoles together with Link Cables Backup - Questions about Save Data GNU Tool - Questions related to the Compiler/Assembler/Linker provided by Cygnus GNUPro Toolkit GNU Documentation (/AllManual/gnu) /gnu This folder contains HTML documentation provided by Cygnus for their GNUPro Toolkit product which was a suite of compilers based on GCC but with official support from Cygnus (later RedHat) for compiling to ARM assembly. This is the same as any GCC documentation you can find freely on the web and is not customized to the GBA so it will not be covered here. Header Documentation (/AllManual/header) /header This folder contains the exact same files as the include directory but with a .TXT extension, this was provided just so the developer could access the files easily in their web browser when the have the documentation pages loaded up. This is not particularly useful as most IDEs nowadays provide easy ways to check on the source code for the include files without leaving the editor. Music Player Documentation (/AllManual/musicplayer) /musicplayer This folder contains documentation for the MusicPlayerAGB2000 library, it is split into two different files, one for each of the different types of users: Sound Developer’s Manual - For the sound engineer Programmer’s Manual - For the game programmer Sound Developer’s ManualThe Sound developer’s Manual is HTML-based documentation found in the /AllManual/musicplayer/sound_dev folder and is tailored towards the sound engineer.The documentation for the Sound and Music library is covered in its own post specifically for this functionality, it is recommended you read it here: M4A Music Library for Game Boy Advance (GBA) For more information about the GBA Music Library check out this post. Other Documentation (/AllManual/others) /others This folder contains the following subsections: Converter - Documentation for the agbcomp and bmp2agb tools Converter (old) - Documentation for the tools: act2agb, agbparts, bin2h, bmp2bin, bmpgrid, bmpred and sgi2bmp Function Sample - Documentation for the sample projects in the src folder that show off certain functions such as Alpha Blending Sample Demo - Documentation for the two demo games: Yoshi and Dolphin Iruka (Dolphin) Demo Documentation (/AllManual/others/demo/Iruka)This folder contains documentation for the demo Dolphin game included in the /src folder and even includes UML-like Flow diagrams for the main game logic!Yoshi Demo Documentation (/AllManual/others/demo/yoshi)This folder contains documentation for the Yoshi Demo project including the basics of how to play and the technology involved in its creation. Game Boy Advance SDK Demos For more information about the GBA SDK Demos check out this post. Function Sample Documentation (/AllManual/others/func_sample) /func_sample This folder contains basic documentation for each of the samples provided in the /src directory that show off certain graphical features of the GBA hardware. File Name Extension Description alphasm .htm Alpha Blending demo code bg_rsm .htm Background demo code showing rotating, scaling and moving backgrounds bmpmode .htm Background Bitmap mode example code coleffsm .htm Special Color effects sample code obj_rsm .htm Object (Sprite) demo code showing rotating, scaling and moving sprites swinsm .htm Example code showing off the different Window modes API Headers (/include folder)This folder contains both C header include files (.h) and assembly headers (.s) that declare all the functions and macros used in the GBA SDK libraries. File Name Extension Description Agb .h Include file for importing all the common header files such as AgbTypes.h AgbDefine .h, .s Include file for declaring common macros such as LCD_WIDTH AgbDefineArm .s Assembly include file for declaring common macros such as SYSTEM_CLOCK AgbIr .h Include file for declaring the functions in the Infrared Communication library AgbMacro .h, .s   AgbMacroArm .s   AgbMemoryMap .h, .s   AgbMemoryMapArm .s   AgbMultiBoot .h Include file for declaring the types used for the Multi-player download functionality with one cartridge AgbSound .h Include file for declaring AgbSyscallDefine .s   AgbSyscallDefineArm .s   AgbSystemCall .h Include file for declaring AgbTypes .h Include file for declaring IsAgbPrint .h Include file for declaring the functions in the Debug Print to terminal library API Header Files AgbDefine.h ON 1 OFF 0 ENABLE 1 DISABLE 0 TRUE 1 FALSE 0 LCD_WIDTH 240 /* Screen Width*/ LCD_HEIGHT 160 /* Screen Height*/ SYSTEM_CLOCK (16 * 1024 * 1024) /* System Clock*/ RESET_ALL_FLAG 0xff /* Reset all*/ RESET_ALL_REG_FLAG 0xe0 /* Reset all registers*/ RESET_REG_FLAG 0x80 /* Reset registers */ RESET_REG_SOUND_FLAG 0x40 /* Reset sound register*/ RESET_REG_SIO_FLAG 0x20 /* Reset SIO register*/ RESET_ALL_RAM_FLAG 0x1f /* Clear the entire RAM*/ RESET_EX_WRAM_FLAG 0x01 /* Clear CPU external RAM*/ RESET_CPU_WRAM_FLAG 0x02 /* Clear CPU internal RAM*/ RESET_PLTT_FLAG 0x04 /* Clear palette*/ RESET_VRAM_FLAG 0x08 /* Clear VRAM*/ RESET_OAM_FLAG 0x10 /* Clear OAM*/ BG_SC_CHAR_NO_MASK 0x03ff /* Character No*/ BG_SC_FLIP_MASK 0x0c00 /* Flip*/ BG_SC_PLTT_MASK 0xf000 /* Color Palette No*/ BG_SC_CHAR_NO_SHIFT 0 BG_SC_FLIP_SHIFT 10 BG_SC_PLTT_SHIFT 12 BG_SC_H_FLIP 0x0400 /* H Flip*/ BG_SC_V_FLIP 0x0800 /* V Flip*/ SIN_SHIFT 14 AFFINE_DIV_SHIFT 8 AFFINE_REG_SHIFT 8 AFFINE_CAL_SHIFT (SIN_SHIFT + AFFINE_DIV_SHIFT - AFFINE_REG_SHIFT) OAM_V_POS_MASK 0x000000ff /* OBJ X Coordinate*/ OAM_H_POS_MASK 0x01ff0000 /* OBJ Y Coordinate*/ OAM_SHAPE_MASK 0x0000c000 /* OBJ shape*/ OAM_SIZE_MASK 0xc0000000 /* OBJ size*/ OAM_OBJ_MODE_MASK 0x00000c00 /* OBJ Mode*/ OAM_AFFINE_MODE_MASK 0x00000300 /* Affine Mode*/ OAM_AFFINE_NO_MASK 0x3e000000 /* Affine Parameter No*/ OAM_FLIP_MASK 0x30000000 /* Flip*/ OAM_CHAR_NO_MASK 0x000003ff /* Character No*/ OAM_PRIORITY_MASK 0x00000c00 /* BG Relative Priority*/ OAM_PLTT_MASK 0x0000f000 /* Color Palette No*/ OAM_AFFINE_PARAM_MASK 0xffff0000 /* Affine Parameter*/ OAM_V_POS_SHIFT 0 OAM_H_POS_SHIFT 16 OAM_SHAPE_SHIFT 14 OAM_SIZE_SHIFT 30 OAM_AFFINE_MODE_SHIFT 8 OAM_OBJ_MODE_SHIFT 10 OAM_AFFINE_NO_SHIFT 25 OAM_FLIP_SHIFT 28 OAM_CHAR_NO_SHIFT 0 OAM_PRIORITY_SHIFT 10 OAM_PLTT_SHIFT 12 OAM_AFFINE_PARAM_SHIFT 16 OAM_OBJ_ON 0x00000000 /* OBJ ON*/ OAM_OBJ_OFF 0x00000200 /* OBJ OFF*/ OAM_OBJ_NORMAL 0x00000000 /* OBJ Normal Mode*/ OAM_OBJ_BLEND 0x00000400 /* OBJ Semi-transparent Mode*/ OAM_OBJ_WINDOW 0x00000800 /* OBJ Window Mode*/ OAM_AFFINE_NONE 0x00000000 /* Affine Invalid Mode*/ OAM_AFFINE_NORMAL 0x00000100 /* Affine Normal Mode*/ OAM_AFFINE_TWICE 0x00000300 /* Affine Double-size Mode*/ OAM_AFFINE_ERASE 0x00000200 /* Affine non-display Mode*/ OAM_MOS_ON 0x00001000 /* Mosaic ON*/ OAM_MOS_OFF 0x00000000 /* Mosaic OFF*/ OAM_COLOR_16 0x00000000 /* Select 16*/ OAM_COLOR_256 0x00002000 /* Select 256 colors*/ OAM_H_FLIP 0x10000000 /* H Flip*/ OAM_V_FLIP 0x20000000 /* V Flip*/ OAM_SQUARE 0x00000000 /* Square OBJ*/ OAM_H_RECTANGLE 0x00004000 /* Horizontally-oriented rectangle OBJ*/ OAM_V_RECTANGLE 0x00008000 /* Vertically-oriented rectangle OBJ*/ OAM_SIZE_NO_0 0x00000000 /* OBJ size No 0*/ OAM_SIZE_NO_1 0x40000000 /* OBJ size No 1*/ OAM_SIZE_NO_2 0x80000000 /* OBJ size No 2*/ OAM_SIZE_NO_3 0xc0000000 /* OBJ size No 3*/ OAM_SIZE_8x8 0x00000000 /* OBJ 8 x 8 dot*/ OAM_SIZE_16x16 0x40000000 /* OBJ 16 x 16 dot*/ OAM_SIZE_32x32 0x80000000 /* OBJ 32 x 32 dot*/ OAM_SIZE_64x64 0xc0000000 /* OBJ 64 x 64 dot*/ OAM_SIZE_16x8 0x00004000 /* OBJ 16 x 8 dot*/ OAM_SIZE_32x8 0x40004000 /* OBJ 32 x 8 dot*/ OAM_SIZE_32x16 0x80004000 /* OBJ 32 x 16 dot*/ OAM_SIZE_64x32 0xc0004000 /* OBJ 64 x 32 dot*/ OAM_SIZE_8x16 0x00008000 /* OBJ 8 x 16 dot*/ OAM_SIZE_8x32 0x40008000 /* OBJ 8 x 32 dot*/ OAM_SIZE_16x32 0x80008000 /* OBJ 16 x 32 dot*/ OAM_SIZE_32x64 0xc0008000 /* OBJ 32 x 64 dot*/ PLTT_RED_MASK 0x001f /* Red*/ PLTT_GREEN_MASK 0x03e0 /* Green*/ PLTT_BLUE_MASK 0x7c00 /* Blue*/ PLTT_RED_SHIFT 0 PLTT_GREEN_SHIFT 5 PLTT_BLUE_SHIFT 10 PSR_CPU_MODE_MASK 0x1f /* CPU Mode*/ PSR_USER_MODE 0x10 /* User*/ PSR_FIQ_MODE 0x11 /* FIQ*/ PSR_IRQ_MODE 0x12 /* IRQ*/ PSR_SVC_MODE 0x13 /* Supervisor*/ PSR_ABORT_MODE 0x17 /* Abort (Prefetch/Data)*/ PSR_UNDEF_MODE 0x1b /* Undefined Command*/ PSR_SYS_MODE 0x1f /* System*/ PSR_THUMB_STATE 0x20 /* THUMB State*/ PSR_FIQ_DISABLE 0x40 /* FIQ Disable*/ PSR_IRQ_DISABLE 0x80 /* IRQ Disable*/ PSR_IRQ_FIQ_DISABLE 0xc0 /* IRQ & FIQ Disable*/ PSR_V_FLAG 0x10000000 /* Overflow*/ PSR_C_FLAG 0x20000000 /* Carry/Borrow/Extend*/ PSR_Z_FLAG 0x40000000 /* Zero*/ PSR_N_FLAG 0x80000000 /* Negative/Less Than*/ V_BLANK_INTR_FLAG 0x0001 /* V Blank Interrupt*/ H_BLANK_INTR_FLAG 0x0002 /* H Blank Interrupt*/ V_COUNT_INTR_FLAG 0x0004 /* V Counter Corresponding Interrupt*/ TIMER0_INTR_FLAG 0x0008 /* Timer 0 Interrupt*/ TIMER1_INTR_FLAG 0x0010 /* Timer 1 Interrupt*/ TIMER2_INTR_FLAG 0x0020 /* Timer 2 Interrupt*/ TIMER3_INTR_FLAG 0x0040 /* Timer 3 Interrupt*/ SIO_INTR_FLAG 0x0080 /* Serial Communication Interrupt*/ DMA0_INTR_FLAG 0x0100 /* DMA0 Interrupt*/ DMA1_INTR_FLAG 0x0200 /* DMA1 Interrupt*/ DMA2_INTR_FLAG 0x0400 /* DMA2 Interrupt*/ DMA3_INTR_FLAG 0x0800 /* DMA3 Interrupt*/ KEY_INTR_FLAG 0x1000 /* Key Interrupt*/ CASSETTE_INTR_FLAG 0x2000 /* Game Pak Interrupt*/ DISP_BG_MODE_MASK 0x0007 /* BG Mode*/ DISP_ON_MASK 0x1f00 /* OBJ BG ON*/ DISP_WIN_MASK 0x6000 /* Window ON*/ DISP_BG_MODE_SHIFT 0 DISP_ON_SHIFT 8 DISP_WIN_SHIFT 13 DISP_MODE_0 0x0000 /* BG Mode 0*/ DISP_MODE_1 0x0001 /* BG Mode 1*/ DISP_MODE_2 0x0002 /* BG Mode 2*/ DISP_MODE_3 0x0003 /* BG Mode 3*/ DISP_MODE_4 0x0004 /* BG Mode 4*/ DISP_MODE_5 0x0005 /* BG Mode 5*/ DISP_BMP_FRAME_NO 0x0010 /* Bitmap Mode Display Frame*/ DISP_OBJ_HOFF 0x0020 /* OBJ Processing in H Blank OFF*/ DISP_OBJ_CHAR_2D_MAP 0x0000 /* OBJ Character Data 2D Mapping*/ DISP_OBJ_CHAR_1D_MAP 0x0040 /* OBJ Character Data 1D Mapping*/ DISP_LCDC_OFF 0x0080 /* LCDC OFF*/ DISP_BG0_ON 0x0100 /* BG0 ON*/ DISP_BG1_ON 0x0200 /* BG1 ON*/ DISP_BG2_ON 0x0400 /* BG2 ON*/ DISP_BG3_ON 0x0800 /* BG3 ON*/ DISP_BG_ALL_ON 0x0f00 /* All BG ON*/ DISP_OBJ_ON 0x1000 /* OBJ ON*/ DISP_OBJ_BG_ALL_ON 0x1f00 /* All OBJ/BG ON*/ DISP_WIN0_ON 0x2000 /* Window 0 ON*/ DISP_WIN1_ON 0x4000 /* Window 1 ON*/ DISP_WIN01_ON 0x6000 /* Window 0,1 ON*/ DISP_OBJWIN_ON 0x8000 /* OBJ Window ON*/ DISP_WIN_ALL_ON 0xe000 /* All Window ON*/ DISP_ALL_ON 0x7f00 /* All ON*/ STAT_VCOUNT_CMP_MASK 0xff00 /* V Counter Compare Value*/ STAT_VCOUNT_CMP_SHIFT 8 STAT_V_BLANK 0x0001 /* During V Blank*/ STAT_H_BLANK 0x0002 /* During H Blank*/ STAT_V_COUNT 0x0004 /* Matching with V Counter*/ STAT_V_BLANK_IF_ENABLE 0x0008 /* V Blank Interrupt Request, Enable*/ STAT_H_BLANK_IF_ENABLE 0x0010 /* H Blank Interrupt Request, Enable*/ STAT_V_COUNT_IF_ENABLE 0x0020 /* V Counter Corresponding */ BG_PRIORITY_MASK 0x0003 /* BG Priority*/ BG_CHAR_BASE_MASK 0x000c /* Character Base Address*/ BG_SCREEN_BASE_MASK 0x1f00 /* Screen Base Address*/ BG_SCREEN_SIZE_MASK 0xc000 /* Screen Size (256/512)*/ BG_PRIORITY_SHIFT 0 BG_CHAR_BASE_SHIFT 2 BG_SCREEN_BASE_SHIFT 8 BG_SCREEN_SIZE_SHIFT 14 BG_PRIORITY_0 0x0000 /* BG 0 Priority*/ BG_PRIORITY_1 0x0001 /* BG 1 Priority*/ BG_PRIORITY_2 0x0002 /* BG 2 Priority*/ BG_PRIORITY_3 0x0003 /* BG 3 Priority*/ BG_MOS_ON 0x0040 /* Mosaic ON*/ BG_MOS_OFF 0x0000 /* Mosaic OFF*/ BG_COLOR_16 0x0000 /* Select 16 colors*/ BG_COLOR_256 0x0080 /* Select 256 colors*/ BG_LOOP_ON 0x2000 /* Loop ON*/ BG_LOOP_OFF 0x0000 /* Loop OFF*/ BG_SCREEN_SIZE_0 0x0000 /* Screen Size (256x256)*/ BG_SCREEN_SIZE_1 0x4000 /* Screen Size (512x256)*/ BG_SCREEN_SIZE_2 0x8000 /* Screen Size (256x512)*/ BG_SCREEN_SIZE_3 0xc000 /* Screen Size (512x512)*/ WIN_END_POS_MASK 0x00ff /* Window End Position*/ WIN_START_POS_MASK 0xff00 /* Window Start Position*/ WIN_END_POS_SHIFT 0 WIN_START_POS_SHIFT 8 WIN_BG0_ON 0x0001 /* BG0 ON*/ WIN_BG1_ON 0x0002 /* BG1 ON*/ WIN_BG2_ON 0x0004 /* BG2 ON*/ WIN_BG3_ON 0x0008 /* BG3 ON*/ WIN_OBJ_ON 0x0010 /* OBJ ON*/ WIN_BLEND_ON 0x0020 /* Blend ON*/ WIN_ALL_ON 0x003f /* All ON*/ MOS_H_SIZE_MASK 0x000f /* Mosaic Height*/ MOS_V_SIZE_MASK 0x00f0 /* Mosaic Width*/ MOS_BG_H_SIZE_MASK 0x000f /* BG Mosaic Height*/ MOS_BG_V_SIZE_MASK 0x00f0 /* BG Mosaic Width*/ MOS_OBJ_H_SIZE_MASK 0x000f /* OBJ Mosaic Height*/ MOS_OBJ_V_SIZE_MASK 0x00f0 /* OBJ Mosaic Width*/ MOS_H_SIZE_SHIFT 0 MOS_V_SIZE_SHIFT 4 MOS_BG_H_SIZE_SHIFT 0 MOS_BG_V_SIZE_SHIFT 4 MOS_OBJ_H_SIZE_SHIFT 8 MOS_OBJ_V_SIZE_SHIFT 12 BLD_PIXEL_MASK 0x003f /* Select Pixel*/ BLD_1ST_PIXEL_MASK 0x003f /* Select 1st Pixel*/ BLD_MODE_MASK 0x00c0 /* Blend Mode*/ BLD_2ND_PIXEL_MASK 0x3f00 /* Select 2nd Pixel*/ BLD_1ST_PIXEL_SHIFT 0 BLD_MODE_SHIFT 6 BLD_2ND_PIXEL_SHIFT 8 BLD_BG0 0x0001 /* Select BG0 Pixel*/ BLD_BG1 0x0002 /* Select BG1 Pixel*/ BLD_BG2 0x0004 /* Select BG2 Pixel*/ BLD_BG3 0x0008 /* Select BG3 Pixel*/ BLD_OBJ 0x0010 /* Select OBJ Pixel*/ BLD_BD 0x0020 /* Select Background Color Pixel*/ BLD_ALL 0x003f /* Select All Pixels*/ BLD_BG0_1ST 0x0001 /* Select BG0 1st Pixel*/ BLD_BG1_1ST 0x0002 /* Select BG1 1st Pixel*/ BLD_BG2_1ST 0x0004 /* Select BG2 1st Pixel*/ BLD_BG3_1ST 0x0008 /* Select BG3 1st Pixel*/ BLD_OBJ_1ST 0x0010 /* Select OBJ 1st Pixel*/ BLD_BD_1ST 0x0020 /* Select Background Color 1st Pixel*/ BLD_1ST_ALL 0x003f /* Select All 1st Pixel*/ BLD_NORMAL_MODE 0x0000 /* Normal Mode*/ BLD_A_BLEND_MODE 0x0040 /* Semi-transparent Mode*/ BLD_UP_MODE 0x0080 /* Brightness UP Mode*/ BLD_DOWN_MODE 0x00c0 /* Brightness DOWN Mode*/ BLD_BG0_2ND 0x0100 /* Select BG0 2nd Pixel*/ BLD_BG1_2ND 0x0200 /* Select BG1 2nd Pixel*/ BLD_BG2_2ND 0x0400 /* Select BG2 2nd Pixel*/ BLD_BG3_2ND 0x0800 /* Select BG3 2nd Pixel*/ BLD_OBJ_2ND 0x1000 /* Select OBJ 2nd Pixel*/ BLD_BD_2ND 0x2000 /* Select Background color 2nd Pixel*/ BLD_2ND_ALL 0x3f00 /* Select All 2nd Pixel*/ BLD_A_MASK 0x001f /* Blend Variable A*/ BLD_B_MASK 0x1f00 /* Blend Variable B*/ BLD_Y_MASK 0x001f /* Blend Variable Y*/ BLD_A_SHIFT 16 BLD_B_SHIFT 24 BLD_Y_SHIFT 0 SOUND_SO1_LEVEL_MASK 0x03 /* S01 Output Level*/ SOUND_SO2_LEVEL_MASK 0x30 /* S02 Output Level*/ SOUND_DMG_SO1_ON_MASK 0x0f /* DMG Compatible Sound->S01 ON*/ SOUND_DMG_SO2_ON_MASK 0xf0 /* DMG Compatible Sound->S02 ON*/ SOUND_SWEEP_SHIFT_MASK 0x03 /* Sweep Shift Number*/ SOUND_SWEEP_TIME_MASK 0x30 /* Sweep Time*/ SOUND_COUNTS_MASK 0x3f /* Sound Length (Count Number)*/ SOUND_DUTY_MASK 0xc0 /* Waveform Duty*/ SOUND_ENV_STEPS_MASK 0x03 /* Envelope Step Number*/ SOUND_ENV_INIT_MASK 0xf0 /* Envelope Initial-Value*/ SOUND_FREQUENCY_MASK 0x03ff /* Frequency*/ SOUND_FREQUENCY_L_MASK 0xff SOUND_FREQUENCY_H_MASK 0x03 SOUND_3_COUNTS_MASK 0xff /* Sound 3 Length (Count Number)*/ SOUND_3_LEVEL_MASK 0xe0 /* Output Level*/ SOUND_4_PRESCALER_MASK 0x03 /* Sound 4 Prescaler Select*/ SOUND_4_POLYSHIFT_MASK 0xf0 /* Polynomial Counter Shift Number*/ SOUND_SO1_LEVEL_SHIFT 0 SOUND_SO2_LEVEL_SHIFT 4 SOUND_DMG_SO1_ON_SHIFT 0 SOUND_DMG_SO2_ON_SHIFT 4 SOUND_SWEEP_SHIFT_SHIFT 0 SOUND_SWEEP_TIME_SHIFT 4 SOUND_COUNTS_SHIFT 0 SOUND_DUTY_SHIFT 6 SOUND_ENV_STEPS_SHIFT 0 SOUND_ENV_INIT_SHIFT 4 SOUND_FREQUENCY_SHIFT 0 SOUND_FREQUENCY_L_SHIFT 0 SOUND_FREQUENCY_H_SHIFT 8 SOUND_3_COUNTS_SHIFT 0 SOUND_3_LEVEL_SHIFT 5 SOUND_4_PRESCALER_SHIFT 0 SOUND_4_POLYSHIFT_SHIFT 4 SOUND_1_ON 0x01 /* Sound 1 ON*/ SOUND_2_ON 0x02 /* Sound 2 ON*/ SOUND_3_ON 0x04 /* Sound 3 ON*/ SOUND_4_ON 0x08 /* Sound 4 ON*/ SOUND_DMG_ON 0x80 /* DMG Compatible Sound ON*/ SOUND_1_SO1_ON 0x01 /* Sound 1 -> S01 ON*/ SOUND_2_SO1_ON 0x02 /* Sound 2 -> S01 ON*/ SOUND_3_SO1_ON 0x04 /* Sound 3 -> S01 ON*/ SOUND_4_SO1_ON 0x08 /* Sound 4 -> S01 ON*/ SOUND_1_SO2_ON 0x10 /* Sound 1 -> S02 ON*/ SOUND_2_SO2_ON 0x20 /* Sound 2 -> S02 ON*/ SOUND_3_SO2_ON 0x40 /* Sound 3 -> S02 ON*/ SOUND_4_SO2_ON 0x80 /* Sound 4 -> S02 ON*/ SOUND_DMG_ALL_SO1_ON 0x0f /* DMG Compatible Sound -> S01 ON*/ SOUND_DMG_ALL_SO2_ON 0xf0 /* DMG Compatible Sound -> S02 ON*/ SOUND_DMG_ALL_SO_ON 0xff /* DMG Compatible Sound -> S01/2 ON*/ SOUND_VIN_SO1_ON 0x80 /* Vin -> S01 ON*/ SOUND_VIN_SO2_ON 0x08 /* Vin -> S02 ON*/ SOUND_VIN_SO_ON 0x08 /* Vin -> S01/2 ON*/ SOUND_A_SO1_ON 0x01 /* Direct Sound A -> S01 ON*/ SOUND_A_SO2_ON 0x02 /* Direct Sound A -> S02 ON*/ SOUND_B_SO1_ON 0x10 /* Direct Sound B -> S01 ON*/ SOUND_B_SO2_ON 0x20 /* Direct Sound B -> S02 ON*/ SOUND_A_ALL_SO_ON 0x03 /* Direct Sound A -> S01/2 ON*/ SOUND_B_ALL_SO_ON 0x30 /* Direct Sound B -> S01/2 ON*/ SOUND_DIRECT_ALL_SO1_ON 0x11 /* Direct Sound A/B -> S01 ON*/ SOUND_DIRECT_ALL_SO2_ON 0x22 /* Direct Sound A/B -> S02 ON*/ SOUND_DIRECT_ALL_SO_ON 0x33 /* Direct Sound A/B -> S01/2 ON*/ SOUND_A_TIMER_0 0x00 /* Timer 0 -> Direct Sound A*/ SOUND_A_TIMER_1 0x04 /* Timer 1 -> Direct Sound A*/ SOUND_B_TIMER_0 0x00 /* Timer 0 -> Direct Sound B*/ SOUND_B_TIMER_1 0x40 /* Timer 1 -> Direct Sound B*/ SOUND_A_FIFO_RESET 0x08 /* Direct Sound A FIFO Reset*/ SOUND_B_FIFO_RESET 0x80 /* Direct Sound B FIFO Reset*/ SOUND_DMG_MIX_1_4 0x00 /* DMG Compatible Sound Mix Ratio 1/4*/ SOUND_DMG_MIX_2_4 0x01 /* 2/4*/ SOUND_DMG_MIX_FULL 0x02 /* Full Range*/ SOUND_A_MIX_1_2 0x00 /* Direct Sound A Mix Ratio 1/2*/ SOUND_A_MIX_FULL 0x04 /* Full Range*/ SOUND_B_MIX_1_2 0x00 /* Direct Sound B Mix Ratio 1/2*/ SOUND_B_MIX_FULL 0x08 /* Full Range*/ SOUND_ALL_MIX_FULL 0x0e /* All Sound Mix Ratio Full Range*/ SOUND_INIT_ON 0x80 /* Initial ON*/ SOUND_INIT_OFF 0x00 /* Initial ON*/ SOUND_COUNTER_ON 0x40 /* Counter ON*/ SOUND_COUNTER_OFF 0x00 /* Counter OFF*/ SOUND_SWEEP_UP 0x00 /* Sweep Addition*/ SOUND_SWEEP_DOWN 0x08 /* Subtraction*/ SOUND_DUTY_1_8 0x00 /* Waveform Duty 1/8*/ SOUND_DUTY_2_8 0x40 /* 2/8*/ SOUND_DUTY_4_8 0x80 /* 4/8*/ SOUND_DUTY_6_8 0xc0 /* 6/8*/ SOUND_ENV_UP 0x08 /* Envelope UP*/ SOUND_ENV_DOWN 0x00 /* DOWN*/ SOUND_3_LOCAL_ON 0x80 /* Sound 3 ON*/ SOUND_3_WAVE_BANK_0 0x00 /* Sound 3 Waveform RAM Bank 0*/ SOUND_3_WAVE_BANK_1 0x40 /* Bank 1*/ SOUND_3_WAVE_CONNECT 0x20 /* Sound 3 Waveform RAM Connect*/ SOUND_3_WAVE_DISCONNECT 0x00 /* Disconnect*/ SOUND_3_LEVEL_0_4 0x00 /* Sound 3 Output None*/ SOUND_3_LEVEL_FULL 0x20 /* 4/4*/ SOUND_3_LEVEL_2_4 0x40 /* 2/4*/ SOUND_3_LEVEL_1_4 0x60 /* 1/4*/ SOUND_3_LEVEL_3_4 0x80 /* 3/4*/ SOUND_4_POLYSTEP_15 0x00 /* Sound 4 Polynomial Counter 15 step*/ SOUND_4_POLYSTEP_7 0x08 /* 7 step*/ SIO_MODE_MASK 0x3000 /* Communication mode*/ SIO_BAUD_RATE_MASK 0x0003 /* Baud rate*/ SIO_ID_NO_MASK 0x0030 /* Communication ID*/ SIO_MODE_SHIFT 12 SIO_BAUD_RATE_SHIFT 0 SIO_ID_NO_SHIFT 4 SIO_8BIT_MODE 0x0000 /* Normal 8-bit communication mode*/ SIO_32BIT_MODE 0x1000 /* Normal 32-bit communication mode*/ SIO_MULTI_MODE 0x2000 /* Multi-play communication mode*/ SIO_UART_MODE 0x3000 /* UART communication mode*/ SIO_SCK_OUT 0x0000 /* Select external clock*/ SIO_SCK_IN 0x0001 /* Select internal clock*/ SIO_IN_SCK_256K 0x0000 /* Select internal clock 256KHz*/ SIO_IN_SCK_2M 0x0002 /* Select 2MHz*/ SIO_ACK_RECV 0x0004 /* Request transfer*/ SIO_ACK_SEND 0x0008 /* Enable transfer*/ SIO_9600_BPS 0x0000 /* Baud rate 9600 bps*/ SIO_38400_BPS 0x0001 /* 38400 bps*/ SIO_57600_BPS 0x0002 /* 57600 bps*/ SIO_115200_BPS 0x0003 /* 115200 bps*/ SIO_MULTI_CONNECT 0x0004 /* Connecting multi-play communication*/ SIO_MULTI_DISCONNECT 0x0000 /* Disconnect*/ SIO_MULTI_PARENT 0x0008 /* Multi-play communication Connect master*/ SIO_MULTI_CHILD 0x0000 /* Connect slave*/ SIO_MULTI_SI 0x0004 /* Multi-play communication SI terminal*/ SIO_MULTI_SD 0x0008 /* SD terminal*/ SIO_MULTI_BUSY 0x0080 /* Multi-play communicating*/ SIO_CTS_ENABLE 0x0004 /* Enable UART send enable signal*/ SIO_UART_7BIT 0x0000 /* UART communication data length 7 bit*/ SIO_UART_8BIT 0x0080 /* 8 bit*/ SIO_ERROR 0x0040 /* Detect error*/ SIO_START 0x0080 /* Start transfer*/ SIO_ENABLE 0x0080 /* Enable SIO*/ SIO_FIFO_ENABLE 0x0100 /* Enable FIFO*/ SIO_PARITY_ENABLE 0x0200 /* Enable parity*/ SIO_PARITY_EVEN 0x0000 /* Even parity*/ SIO_PARITY_ODD 0x0008 /* Odd parity*/ SIO_TRANS_ENABLE 0x0400 /* Enable transmitter*/ SIO_TRANS_DATA_FULL 0x0010 /* Transmitted data full */ SIO_RECV_ENABLE 0x0800 /* Enable receiver*/ SIO_RECV_DATA_EMPTY 0x0020 /* No data received*/ SIO_IF_ENABLE 0x4000 /* Enable interrupt request*/ JOY_IF_RESET 0x01 /* Interrupt request of JOY bus reset */ JOY_IF_RECV 0x02 /* Interrupt request of JOY bus receive completion*/ JOY_IF_SEND 0x04 /* Interrupt request of JOY bus send completion*/ JOY_IF_ENABLE 0x40 /* Enable interrupt request*/ JSTAT_FLAGS_MASK 0x30 /* General flag*/ JSTAT_FLAGS_SHIFT 4 JSTAT_RECV 0x02 /* Receive status*/ JSTAT_SEND 0x08 /* Send status*/ R_SIO_MODE_MASTER_MASK 0xc000 /* SIO mode master*/ R_SIO_MODE_MASTER_SHIFT 14 R_SIO_MASTER_MODE 0x0000 /* SIO master mode*/ R_DIRECT_MODE 0x8000 /* General input/output */ R_JOY_MODE 0xc000 /* JOY communication mode*/ R_SC 0x0001 /* Data*/ R_SD 0x0002 R_SI 0x0004 R_SO 0x0008 R_SC_I_O 0x0010 /* Select I/O*/ R_SD_I_O 0x0020 R_SI_I_O 0x0040 R_SO_I_O 0x0080 R_SC_IN 0x0000 /* Input setting*/ R_SD_IN 0x0000 R_SI_IN 0x0000 R_SO_IN 0x0000 R_SC_OUT 0x0010 /* Output setting*/ R_SD_OUT 0x0020 R_SI_OUT 0x0040 R_SO_OUT 0x0080 R_IF_ENABLE 0x0100 /* Enable interrupt request*/ DMA_TIMMING_MASK 0x30000000 /* Start Timing*/ DMA_COUNT_MASK 0x0000ffff /* Transmission Count*/ DMA_TIMMING_SHIFT 30 DMA_COUNT_SHIFT 0 DMA_ENABLE 0x80000000 /* DMA Enable*/ DMA_IF_ENABLE 0x40000000 /* Interrupt Request Enable*/ DMA_TIMMING_IMM 0x00000000 /* Run Immediately*/ DMA_TIMMING_V_BLANK 0x10000000 /* Run V Blank*/ DMA_TIMMING_H_BLANK 0x20000000 /* Run H Blank*/ DMA_TIMMING_DISP 0x30000000 /* Run Display*/ DMA_TIMMING_SOUND 0x30000000 /* Run Sound FIFO Request*/ DMA_DREQ_ON 0x08000000 /* Data Request Synchronize Mode ON*/ DMA_16BIT_BUS 0x00000000 /* Select Bus Size 16Bit*/ DMA_32BIT_BUS 0x04000000 /* Select Bus Size 32Bit*/ DMA_CONTINUOUS_ON 0x02000000 /* Continuous Mode ON*/ DMA_SRC_INC 0x00000000 /* Select Source Increment*/ DMA_SRC_DEC 0x00800000 /* Select Source Decrement*/ DMA_SRC_FIX 0x01000000 /* Select Source Fixed*/ DMA_DEST_INC 0x00000000 /* Select Destination Increment*/ DMA_DEST_DEC 0x00200000 /* Select Destination Decrement*/ DMA_DEST_FIX 0x00400000 /* Select Destination Fixed*/ DMA_DEST_RELOAD 0x00600000 /* Select Destination */ TMR_PRESCALER_MASK 0x00030000 /* Prescaler Clock*/ TMR_PRESCALER_SHIFT 16 TMR_PRESCALER_1CK 0x00000000 /* Prescaler 1 Clock*/ TMR_PRESCALER_64CK 0x00010000 /* 64 clocks*/ TMR_PRESCALER_256CK 0x00020000 /* 256 clocks*/ TMR_PRESCALER_1024CK 0x00030000 /* 1024 clocks*/ TMR_IF_ENABLE 0x00400000 /* Interrupt Request Enable*/ TMR_ENABLE 0x00800000 /* Run Timer*/ BUTTON_MASK 0x030f /* Button*/ PLUS_KEY_MASK 0x00f0 /* +Control Pad*/ ALL_KEY_MASK 0x03ff /* All Key*/ A_BUTTON 0x0001 /* A Button*/ B_BUTTON 0x0002 /* B Button*/ SELECT_BUTTON 0x0004 /* SELECT*/ START_BUTTON 0x0008 /* START*/ R_KEY 0x0010 /* Right Button*/ L_KEY 0x0020 /* Left Button*/ U_KEY 0x0040 /* Up Button*/ D_KEY 0x0080 /* Down Button*/ R_BUTTON 0x0100 /* R Button*/ L_BUTTON 0x0200 /* L Button*/ KEY_IF_ENABLE 0x4000 /* Interrupt Request Enable*/ KEY_OR_INTR 0x0000 /* Normal Key Interrupt*/ KEY_AND_INTR 0x8000 /* AND Key Interrupt*/ CST_SRAM_4WAIT 0x0000 /* SRAM 4 wait*/ CST_SRAM_3WAIT 0x0001 /* 3 wait*/ CST_SRAM_2WAIT 0x0002 /* 2 wait*/ CST_SRAM_8WAIT 0x0003 /* 8 wait*/ CST_ROM0_1ST_4WAIT 0x0000 /* ROM0 1st 4 wait*/ CST_ROM0_1ST_3WAIT 0x0004 /* 3 wait*/ CST_ROM0_1ST_2WAIT 0x0008 /* 2 wait*/ CST_ROM0_1ST_8WAIT 0x000c /* 8 wait*/ CST_ROM0_2ND_2WAIT 0x0000 /* 2nd 2 wait*/ CST_ROM0_2ND_1WAIT 0x0010 /* 1 wait*/ CST_ROM1_1ST_4WAIT 0x0000 /* ROM 1 1st 4 wait*/ CST_ROM1_1ST_3WAIT 0x0020 /* 3 wait*/ CST_ROM1_1ST_2WAIT 0x0040 /* 2 wait*/ CST_ROM1_1ST_8WAIT 0x0060 /* 8 wait*/ CST_ROM1_2ND_4WAIT 0x0000 /* 2nd 4 wait*/ CST_ROM1_2ND_1WAIT 0x0080 /* 1 wait*/ CST_ROM2_1ST_4WAIT 0x0000 /* ROM 2 1st 4 wait*/ CST_ROM2_1ST_3WAIT 0x0100 /* 3 wait*/ CST_ROM2_1ST_2WAIT 0x0200 /* 2 wait*/ CST_ROM2_1ST_8WAIT 0x0300 /* 8 wait*/ CST_ROM2_2ND_8WAIT 0x0000 /* 2nd 8 wait*/ CST_ROM2_2ND_1WAIT 0x0400 /* 1 wait*/ CST_PHI_OUT_NONE 0x0000 /* terminal output clock fixed Lo*/ CST_PHI_OUT_4MCK 0x0800 /* 4MHz*/ CST_PHI_OUT_8MCK 0x1000 /* 8MHz*/ CST_PHI_OUT_16MCK 0x1800 /* 16MHz*/ CST_PREFETCH_ENABLE 0x4000 /* Enable prefetch buffer*/ CST_AGB 0x0000 /* AGB Game Pak*/ CST_CGB 0x8000 /* CGB Game Pak*/ 0 0 710 AgbIr.h void irBegin(int,irResult*,int) void irEnd() int irSendConnect(int) int irRecvConnect(int) void irInit() int irSendPacket(int*,int) int irRecvPacket(int*,int) void irMountThumbCore() void irMountArmCore(int*,int*) void irRamCopy(int*,int*) void irEnable() void irDisable() int irDetection() IR_SHUTDOWN 0x00 IR_DISCONNECT 0xff IR_NORMAL 0x8b /*Normal Value*/ IR_PULSE_ERR 0x01 /*When received pulse error*/ IR_BYTES_ERR 0x02 /*When received send request for more */ IR_CODE_ERR 0x04 /*Header Code Error*/ IR_SUM_ERR 0x08 /*Checksum Error*/ IR_RECEIVER 0x01 /*Receiver*/ IR_SENDER 0x02 /*Sender*/ IR_UNDEFINED 0x03 /*Undefined*/ IR_DATA_RAW 0x5a /*Sent as part of header*/ IR_SUCCESS 1 /*Success Notification*/ IR_FAILURE 0 /*Failure Notification*/ IR_ARM_SEND_CORE_SIZE 182 /*Words(728Bytes)*/ IR_ARM_RECV_CORE_SIZE 169 /*Words(676Bytes)*/ IR_40kbps_RATE 0x1A3 /*Cartridge ROM (4-2 Wait):40000bps*/ IR_47kbps_RATE 0x161 /* Same (3-1 Wait):47530bps*/ IR_104kbps_RATE 0x0A1 /*Internal RAM:104000bps*/ 13 0 251 AgbMemoryMap.h BOOT_ROM 0x00000000 /* Boot ROM*/ BOOT_ROM_END (BOOT_ROM + 0x4000) EX_WRAM 0x02000000 /* CPU External Work RAM*/ EX_WRAM_END (EX_WRAM + 0x40000) CPU_WRAM 0x03000000 /* CPU Internal Work RAM*/ CPU_WRAM_END (CPU_WRAM + 0x8000) WRAM EX_WRAM /* Entire Work RAM*/ WRAM_END CPU_WRAM_END SOUND_AREA_ADDR_BUF (CPU_WRAM_END - 0x10)/*Sound Driver Work Address*/ INTR_CHECK_BUF (CPU_WRAM_END - 0x8)/* Interrupt Check*/ SOFT_RESET_DIRECT_BUF (CPU_WRAM_END - 0x6)/* SoftReset() Specify Return to*/ INTR_VECTOR_BUF (CPU_WRAM_END - 0x4)/* Interrupt Branch Address*/ REG_BASE 0x04000000 /* Registers*/ REG_END (REG_BASE + 0x300) PLTT 0x05000000 /* Palette RAM*/ PLTT_END (PLTT + 0x400) BG_PLTT (PLTT + 0x0) /* BG Palette RAM*/ BG_PLTT_END (PLTT + 0x200) OBJ_PLTT (PLTT + 0x200) /* OBJ Palette RAM*/ OBJ_PLTT_END (PLTT + 0x400) VRAM 0x06000000 /* VRAM*/ VRAM_END (VRAM + 0x18000) BG_VRAM (VRAM + 0x0) /* BG Character/Screen RAM*/ BG_BITMAP0_VRAM (VRAM + 0x0) /* BG Bitmap 0 RAM*/ BG_BITMAP1_VRAM (VRAM + 0xa000) /* BG Bitmap 1 RAM*/ OBJ_MODE0_VRAM (VRAM + 0x10000) /* OBJ Character RAM*/ OBJ_MODE1_VRAM (VRAM + 0x10000) OBJ_MODE2_VRAM (VRAM + 0x10000) OBJ_MODE3_VRAM (VRAM + 0x14000) OBJ_MODE4_VRAM (VRAM + 0x14000) OBJ_MODE5_VRAM (VRAM + 0x14000) OBJ_VRAM_END (VRAM + 0x18000) OAM 0x07000000 /* OAM*/ OAM_END (OAM + 0x400) ROM_BANK0 0x08000000 /* ROM Bank 0*/ ROM_BANK0_END 0x0a000000 ROM_BANK1 0x0a000000 /* ROM Bank 1*/ ROM_BANK1_END 0x0c000000 ROM_BANK2 0x0c000000 /* ROM Bank 2*/ ROM_BANK2_END 0x0e000000 RAM_BANK 0x0c000000 /* RAM Bank*/ RAM_BANK_END 0x10000000 FLASH_1M 0x09fe0000 /* 1M Flash Memory*/ FLASH_1M_END 0x0a000000 BOOT_ROM_SIZE 0x4000 /* Boot ROM*/ EX_WRAM_SIZE 0x40000 /* CPU External Work RAM*/ CPU_WRAM_SIZE 0x8000 /* CPU Internal Work RAM*/ WRAM_SIZE 0x48000 /* Entire Work RAM*/ PLTT_SIZE (2*256*2) /* Palette RAM*/ BG_PLTT_SIZE (2*256) /* BG Palette RAM*/ OBJ_PLTT_SIZE (2*256) /* OBJ Palette RAM*/ VRAM_SIZE 0x18000 /* VRAM*/ BG_MODE0_VRAM_SIZE 0x10000 /* BG Character/Screen*/ BG_MODE1_VRAM_SIZE 0x10000 BG_MODE2_VRAM_SIZE 0x10000 BG_MODE3_VRAM_SIZE 0x14000 /* BG Bitmap*/ BG_MODE4_VRAM_SIZE 0x0a000 BG_MODE5_VRAM_SIZE 0x0a000 OBJ_MODE0_VRAM_SIZE 0x08000 /* OBJ Character*/ OBJ_MODE1_VRAM_SIZE 0x08000 OBJ_MODE2_VRAM_SIZE 0x08000 OBJ_MODE3_VRAM_SIZE 0x04000 OBJ_MODE4_VRAM_SIZE 0x04000 OBJ_MODE5_VRAM_SIZE 0x04000 OAM_SIZE (8*128) /* OAM*/ ROM_BANK_SIZE 0x02000000 /* ROM Bank*/ ROM_BANK0_SIZE 0x02000000 /* ROM Bank 0*/ ROM_BANK1_SIZE 0x02000000 /* ROM Bank 1*/ ROM_BANK2_SIZE 0x02000000 /* ROM Bank 2*/ RAM_BANK_SIZE 0x02000000 /* RAM Bank*/ FLASH_1M_SIZE 0x20000 /* 1M Flash Memory*/ REG_IME (REG_BASE + 0x208) /* Interrupt Master Enable*/ REG_IE (REG_BASE + 0x200) /* Interrupt Enable*/ REG_IF (REG_BASE + 0x202) /* Interrupt Request*/ REG_WAITCNT (REG_BASE + 0x204) /* Game Pak Wait Control*/ REG_DISPCNT (REG_BASE + 0x0) /* Display Control*/ REG_STAT (REG_BASE + 0x4) /* Status*/ REG_VCOUNT (REG_BASE + 0x6) /* V Counter*/ REG_MOSAIC (REG_BASE + 0x4c) /* Mosaic Size*/ REG_BLDCNT (REG_BASE + 0x50) /* Blend Mode Control*/ REG_BLDALPHA (REG_BASE + 0x52) /* Semi-transparent Parameter*/ REG_BLDY (REG_BASE + 0x54) /* Brightness Change Parameter*/ REG_WINCNT (REG_BASE + 0x40) /* Window Control*/ REG_WIN0H (REG_BASE + 0x40) /* Window 0 Horizontal Area*/ REG_WIN1H (REG_BASE + 0x42) /* Window 1 Horizontal Area*/ REG_WIN0V (REG_BASE + 0x44) /* Window 0 Vertical Area*/ REG_WIN1V (REG_BASE + 0x46) /* WIndow 1 Vertical Area*/ REG_WININ (REG_BASE + 0x48) /* Internal Window Control*/ REG_WIN0 (REG_BASE + 0x48) /* Window 0 Control*/ REG_WIN1 (REG_BASE + 0x49) /* Window 1 Control*/ REG_WINOUT (REG_BASE + 0x4a) /* External Window Control*/ REG_OBJWIN (REG_BASE + 0x4b) /* OBJ Window Control*/ REG_BGCNT (REG_BASE + 0x8) /* BG Control*/ REG_BG0CNT (REG_BASE + 0x8) /* BG 0 Control*/ REG_BG1CNT (REG_BASE + 0xa) /* BG 1 Control*/ REG_BG2CNT (REG_BASE + 0xc) /* BG 2 Control*/ REG_BG3CNT (REG_BASE + 0xe) /* BG 3 Control*/ REG_BGOFS (REG_BASE + 0x10) /* BG Offset*/ REG_BG0HOFS (REG_BASE + 0x10) /* BG 0 H Offset*/ REG_BG0VOFS (REG_BASE + 0x12) /* BG 0 V Offset*/ REG_BG1HOFS (REG_BASE + 0x14) /* BG 1 H Offset*/ REG_BG1VOFS (REG_BASE + 0x16) /* BG 1 V Offset*/ REG_BG2HOFS (REG_BASE + 0x18) /* BG 2 H Offset*/ REG_BG2VOFS (REG_BASE + 0x1a) /* BG 2 V Offset*/ REG_BG3HOFS (REG_BASE + 0x1c) /* BG 3 H Offset*/ REG_BG3VOFS (REG_BASE + 0x1e) /* BG 3 V Offset*/ REG_BG2AFFINE (REG_BASE + 0x20) /* BG 2 Affin Transformation Parameters*/ REG_BG2PA (REG_BASE + 0x20) /* BG 2 Line Direction X Coordinate Difference*/ REG_BG2PB (REG_BASE + 0x22) /* BG 3 Vertical Direction X Coordinate Difference*/ REG_BG2PC (REG_BASE + 0x24) /* BG 2 Line Direction Y coordinate Difference*/ REG_BG2PD (REG_BASE + 0x26) /* BG 2 Vertical Direction Y Coordinate Difference*/ REG_BG2X (REG_BASE + 0x28) /* BG 2 Start X Coordinate*/ REG_BG2X_L (REG_BASE + 0x28) REG_BG2X_H (REG_BASE + 0x2a) REG_BG2Y (REG_BASE + 0x2c) /* BG 2 Start Y Coordinate*/ REG_BG2Y_L (REG_BASE + 0x2c) REG_BG2Y_H (REG_BASE + 0x2e) REG_BG3AFFINE (REG_BASE + 0x30) /* BG 3 Affin Transformation Parameters*/ REG_BG3PA (REG_BASE + 0x30) /* BG 3 Line Direction X Coordinate Difference*/ REG_BG3PB (REG_BASE + 0x32) /* BG 3 Vertical Direction X Coordinate Difference*/ REG_BG3PC (REG_BASE + 0x34) /* BG 3 Line Direction Y Coordinate Difference*/ REG_BG3PD (REG_BASE + 0x36) /* BG 3 Vertical Direction Y Coordinate Difference*/ REG_BG3X (REG_BASE + 0x38) /* BG 3 Start X Coordinate*/ REG_BG3X_L (REG_BASE + 0x38) REG_BG3X_H (REG_BASE + 0x3a) REG_BG3Y (REG_BASE + 0x3c) /* BG 3 Start Y Coordinate*/ REG_BG3Y_L (REG_BASE + 0x3c) REG_BG3Y_H (REG_BASE + 0x3e) REG_SOUNDCNT (REG_BASE + 0x80) /* Sound Control*/ REG_SOUNDCNT_L (REG_BASE + 0x80) REG_SOUNDCNT_H (REG_BASE + 0x82) REG_SOUNDCNT_X (REG_BASE + 0x84) REG_SOUNDBIAS (REG_BASE + 0x88) /* Sound BIAS*/ REG_SOUND1CNT (REG_BASE + 0x60) /* Sound 1 Control*/ REG_SOUND1CNT_L (REG_BASE + 0x60) REG_SOUND1CNT_H (REG_BASE + 0x62) REG_SOUND1CNT_X (REG_BASE + 0x64) REG_SOUND2CNT (REG_BASE + 0x68) /* Sound 2 Control*/ REG_SOUND2CNT_L (REG_BASE + 0x68) REG_SOUND2CNT_H (REG_BASE + 0x6c) REG_SOUND3CNT (REG_BASE + 0x70) /* Sound 3 Control*/ REG_SOUND3CNT_L (REG_BASE + 0x70) REG_SOUND3CNT_H (REG_BASE + 0x72) REG_SOUND3CNT_X (REG_BASE + 0x74) REG_SOUND4CNT (REG_BASE + 0x78) /* Sound 4 Control*/ REG_SOUND4CNT_L (REG_BASE + 0x78) REG_SOUND4CNT_H (REG_BASE + 0x7c) REG_WAVE_RAM (REG_BASE + 0x90) /* Sound 3 Waveform RAM*/ REG_WAVE_RAM0 (REG_BASE + 0x90) REG_WAVE_RAM0_L (REG_BASE + 0x90) REG_WAVE_RAM0_H (REG_BASE + 0x92) REG_WAVE_RAM1 (REG_BASE + 0x94) REG_WAVE_RAM1_L (REG_BASE + 0x94) REG_WAVE_RAM1_H (REG_BASE + 0x96) REG_WAVE_RAM2 (REG_BASE + 0x98) REG_WAVE_RAM2_L (REG_BASE + 0x98) REG_WAVE_RAM2_H (REG_BASE + 0x9a) REG_WAVE_RAM3 (REG_BASE + 0x9c) REG_WAVE_RAM3_L (REG_BASE + 0x9c) REG_WAVE_RAM3_H (REG_BASE + 0x9e) REG_FIFO (REG_BASE + 0xa0) /* Sound FIFO*/ REG_FIFO_A (REG_BASE + 0xa0) REG_FIFO_A_L (REG_BASE + 0xa0) REG_FIFO_A_H (REG_BASE + 0xa2) REG_FIFO_B (REG_BASE + 0xa4) REG_FIFO_B_L (REG_BASE + 0xa4) REG_FIFO_B_H (REG_BASE + 0xa6) REG_DMA0 (REG_BASE + 0xb0) /* DMA 0*/ REG_DMA0SAD (REG_BASE + 0xb0) /* (Internal Memory -> */ REG_DMA0SAD_L (REG_BASE + 0xb0) REG_DMA0SAD_H (REG_BASE + 0xb2) REG_DMA0DAD (REG_BASE + 0xb4) REG_DMA0DAD_L (REG_BASE + 0xb4) REG_DMA0DAD_H (REG_BASE + 0xb6) REG_DMA0CNT (REG_BASE + 0xb8) REG_DMA0CNT_L (REG_BASE + 0xb8) REG_DMA0CNT_H (REG_BASE + 0xba) REG_DMA1 (REG_BASE + 0xbc) /* DMA 1*/ REG_DMA1SAD (REG_BASE + 0xbc) /* (Internal Memory -> Sound */ REG_DMA1SAD_L (REG_BASE + 0xbc) REG_DMA1SAD_H (REG_BASE + 0xbe) REG_DMA1DAD (REG_BASE + 0xc0) REG_DMA1DAD_L (REG_BASE + 0xc0) REG_DMA1DAD_H (REG_BASE + 0xc2) REG_DMA1CNT (REG_BASE + 0xc4) REG_DMA1CNT_L (REG_BASE + 0xc4) REG_DMA1CNT_H (REG_BASE + 0xc6) REG_DMA2 (REG_BASE + 0xc8) /* DMA 2*/ REG_DMA2SAD (REG_BASE + 0xc8) /* (Internal Memory -> Sound */ REG_DMA2SAD_L (REG_BASE + 0xc8) REG_DMA2SAD_H (REG_BASE + 0xca) REG_DMA2DAD (REG_BASE + 0xcc) REG_DMA2DAD_L (REG_BASE + 0xcc) REG_DMA2DAD_H (REG_BASE + 0xce) REG_DMA2CNT (REG_BASE + 0xd0) REG_DMA2CNT_L (REG_BASE + 0xd0) REG_DMA2CNT_H (REG_BASE + 0xd2) REG_DMA3 (REG_BASE + 0xd4) /* DMA 3*/ REG_DMA3SAD (REG_BASE + 0xd4) /* (Game Pak/Internal Memory */ REG_DMA3SAD_L (REG_BASE + 0xd4) REG_DMA3SAD_H (REG_BASE + 0xd6) REG_DMA3DAD (REG_BASE + 0xd8) REG_DMA3DAD_L (REG_BASE + 0xd8) REG_DMA3DAD_H (REG_BASE + 0xda) REG_DMA3CNT (REG_BASE + 0xdc) REG_DMA3CNT_L (REG_BASE + 0xdc) REG_DMA3CNT_H (REG_BASE + 0xde) REG_TM0CNT (REG_BASE + 0x100) /* Timer 0*/ REG_TM0CNT_L (REG_BASE + 0x100) REG_TM0CNT_H (REG_BASE + 0x102) REG_TM1CNT (REG_BASE + 0x104) /* Timer 1*/ REG_TM1CNT_L (REG_BASE + 0x104) REG_TM1CNT_H (REG_BASE + 0x106) REG_TM2CNT (REG_BASE + 0x108) /* Timer 2*/ REG_TM2CNT_L (REG_BASE + 0x108) REG_TM2CNT_H (REG_BASE + 0x10a) REG_TM3CNT (REG_BASE + 0x10c) /* Timer 3*/ REG_TM3CNT_L (REG_BASE + 0x10c) REG_TM3CNT_H (REG_BASE + 0x10e) REG_RCNT (REG_BASE + 0x134) /* General Input/Output Control*/ REG_SIOCNT (REG_BASE + 0x128) /* Serial Communication Control*/ REG_SIODATA8 (REG_BASE + 0x12a) /* 8bit Serial Communication Data*/ REG_SIODATA32 (REG_BASE + 0x120) /* 32bit Serial Communication Data*/ REG_SIOMLT_SEND (REG_BASE + 0x12a) /* Multi-play SIO Send Data*/ REG_SIOMLT_RECV (REG_BASE + 0x120) /* Multi-play SIO Receive Data*/ REG_SIOMULTI0 (REG_BASE + 0x120) REG_SIOMULTI1 (REG_BASE + 0x122) REG_SIOMULTI2 (REG_BASE + 0x124) REG_SIOMULTI3 (REG_BASE + 0x126) REG_JOYCNT (REG_BASE + 0x140) /* JOY Bus Communication Control*/ REG_JOYSTAT (REG_BASE + 0x158) /* JOY Bus Status*/ REG_JOY_RECV (REG_BASE + 0x150) /* JOY Bus Receive Data*/ REG_JOY_RECV_L (REG_BASE + 0x150) REG_JOY_RECV_H (REG_BASE + 0x152) REG_JOY_TRANS (REG_BASE + 0x154) /* JOY Bus Send Data*/ REG_JOY_TRANS_L (REG_BASE + 0x154) REG_JOY_TRANS_H (REG_BASE + 0x156) REG_KEYINPUT (REG_BASE + 0x130) /* Key Input*/ REG_KEYCNT (REG_BASE + 0x132) /* Key Control*/ OFFSET_REG_IME 0x208 /* Interrupt Master Enable*/ OFFSET_REG_IE 0x200 /* Interrupt Enable*/ OFFSET_REG_IF 0x202 /* Interrupt Request*/ OFFSET_REG_WAITCNT 0x204 /* Game Pak Wait Control*/ OFFSET_REG_DISPCNT 0x0 /* Display Control*/ OFFSET_REG_STAT 0x4 /* Status*/ OFFSET_REG_VCOUNT 0x6 /* V Counter*/ OFFSET_REG_MOSAIC 0x4c /* Mosaic Size*/ OFFSET_REG_BLDCNT 0x50 /* Blend Mode Control*/ OFFSET_REG_BLDALPHA 0x52 /* Semi-trams[aremt Parameter*/ OFFSET_REG_BLDY 0x54 /* Brightness Change Parameter*/ OFFSET_REG_WINCNT 0x40 /* Window Control*/ OFFSET_REG_WIN0H 0x40 /* Window 0 Horizontal Area*/ OFFSET_REG_WIN1H 0x42 /* Window 1 Horizontal Area*/ OFFSET_REG_WIN0V 0x44 /* Window 0 Vertical Area*/ OFFSET_REG_WIN1V 0x46 /* Window 1 Vertical Area*/ OFFSET_REG_WININ 0x48 /* Internal Window Control*/ OFFSET_REG_WIN0 0x48 /* Window 0 Control*/ OFFSET_REG_WIN1 0x49 /* Window 1 Control*/ OFFSET_REG_WINOUT 0x4a /* External Window Control*/ OFFSET_REG_OBJWIN 0x4b /* OBJ Window Control*/ OFFSET_REG_BGCNT 0x8 /* BG Control*/ OFFSET_REG_BG0CNT 0x8 /* BG 0 Control*/ OFFSET_REG_BG1CNT 0xa /* BG 1 Control*/ OFFSET_REG_BG2CNT 0xc /* BG 2 Control*/ OFFSET_REG_BG3CNT 0xe /* BG 3 Control*/ OFFSET_REG_BGOFS 0x10 /* BG Offset*/ OFFSET_REG_BG0HOFS 0x10 /* BG 0 H Offset*/ OFFSET_REG_BG0VOFS 0x12 /* BG 0 V Offset*/ OFFSET_REG_BG1HOFS 0x14 /* BG 1 H Offset*/ OFFSET_REG_BG1VOFS 0x16 /* BG 1 V Offset*/ OFFSET_REG_BG2HOFS 0x18 /* BG 2 H Offset*/ OFFSET_REG_BG2VOFS 0x1a /* BG 2 V Offset*/ OFFSET_REG_BG3HOFS 0x1c /* BG 3 H Offset*/ OFFSET_REG_BG3VOFS 0x1e /* BG 3 V Offset*/ OFFSET_REG_BG2AFFINE 0x20 /* BG 2 Affin Transformation Parameters*/ OFFSET_REG_BG2PA 0x20 /* BG 2 Line Direction X Coordinate Difference*/ OFFSET_REG_BG2PB 0x22 /* BG 2 Vertical Direction X Coordinate Difference*/ OFFSET_REG_BG2PC 0x24 /* BG 2 Line Direction Y Coordinate Difference*/ OFFSET_REG_BG2PD 0x26 /* BG 2 Vertical Direction Y Coordinate Difference*/ OFFSET_REG_BG2X 0x28 /* BG 2 Start X Coordinate*/ OFFSET_REG_BG2X_L 0x28 OFFSET_REG_BG2X_H 0x2a OFFSET_REG_BG2Y 0x2c /* BG 2 Start Y Coordinate*/ OFFSET_REG_BG2Y_L 0x2c OFFSET_REG_BG2Y_H 0x2e OFFSET_REG_BG3AFFINE 0x30 /* BG 3 Affin Transformation Parameters*/ OFFSET_REG_BG3PA 0x30 /* BG 3 Line Direction X Coordinate Difference*/ OFFSET_REG_BG3PB 0x32 /* BG 3 Vertical Direction X Coordinate Difference*/ OFFSET_REG_BG3PC 0x34 /* BG 3 Line Direction Y Coordinate Difference*/ OFFSET_REG_BG3PD 0x36 /* BG 3 Vertical Direction Y Coordinate Difference*/ OFFSET_REG_BG3X 0x38 /* BG 3 Start X Coordinate*/ OFFSET_REG_BG3X_L 0x38 OFFSET_REG_BG3X_H 0x3a OFFSET_REG_BG3Y 0x3c /* BG 3 Start Y Coordinate*/ OFFSET_REG_BG3Y_L 0x3c OFFSET_REG_BG3Y_H 0x3e OFFSET_REG_SOUNDCNT 0x80 /* Sound Control*/ OFFSET_REG_SOUNDCNT_L 0x80 OFFSET_REG_SOUNDCNT_H 0x82 OFFSET_REG_SOUNDCNT_X 0x84 OFFSET_REG_SOUNDBIAS 0x88 /* Sound BIAS*/ OFFSET_REG_SOUND1CNT 0x60 /* Sound 1 Control*/ OFFSET_REG_SOUND1CNT_L 0x60 OFFSET_REG_SOUND1CNT_H 0x62 OFFSET_REG_SOUND1CNT_X 0x64 OFFSET_REG_SOUND2CNT 0x68 /* Sound 2 Control*/ OFFSET_REG_SOUND2CNT_L 0x68 OFFSET_REG_SOUND2CNT_H 0x6c OFFSET_REG_SOUND3CNT 0x70 /* Sound 3 Control*/ OFFSET_REG_SOUND3CNT_L 0x70 OFFSET_REG_SOUND3CNT_H 0x72 OFFSET_REG_SOUND3CNT_X 0x74 OFFSET_REG_SOUND4CNT 0x78 /* Sound 4 Control*/ OFFSET_REG_SOUND4CNT_L 0x78 OFFSET_REG_SOUND4CNT_H 0x7c OFFSET_REG_WAVE_RAM 0x90 /* Sound 3 Waveform RAM*/ OFFSET_REG_WAVE_RAM0 0x90 OFFSET_REG_WAVE_RAM0_L 0x90 OFFSET_REG_WAVE_RAM0_H 0x92 OFFSET_REG_WAVE_RAM1 0x94 OFFSET_REG_WAVE_RAM1_L 0x94 OFFSET_REG_WAVE_RAM1_H 0x96 OFFSET_REG_WAVE_RAM2 0x98 OFFSET_REG_WAVE_RAM2_L 0x98 OFFSET_REG_WAVE_RAM2_H 0x9a OFFSET_REG_WAVE_RAM3 0x9c OFFSET_REG_WAVE_RAM3_L 0x9c OFFSET_REG_WAVE_RAM3_H 0x9e OFFSET_REG_FIFO 0xa0 /* Sound FIFO*/ OFFSET_REG_FIFO_A 0xa0 OFFSET_REG_FIFO_A_L 0xa0 OFFSET_REG_FIFO_A_H 0xa2 OFFSET_REG_FIFO_B 0xa4 OFFSET_REG_FIFO_B_L 0xa4 OFFSET_REG_FIFO_B_H 0xa6 OFFSET_REG_DMA0 0xb0 /* DMA 0*/ OFFSET_REG_DMA0SAD 0xb0 /* (Internal Memory -> Internal */ OFFSET_REG_DMA0SAD_L 0xb0 OFFSET_REG_DMA0SAD_H 0xb2 OFFSET_REG_DMA0DAD 0xb4 OFFSET_REG_DMA0DAD_L 0xb4 OFFSET_REG_DMA0DAD_H 0xb6 OFFSET_REG_DMA0CNT 0xb8 OFFSET_REG_DMA0CNT_L 0xb8 OFFSET_REG_DMA0CNT_H 0xba OFFSET_REG_DMA1 0xbc /* DMA 1*/ OFFSET_REG_DMA1SAD 0xbc /* (Internal Memory -> Sound */ OFFSET_REG_DMA1SAD_L 0xbc OFFSET_REG_DMA1SAD_H 0xbe OFFSET_REG_DMA1DAD 0xc0 OFFSET_REG_DMA1DAD_L 0xc0 OFFSET_REG_DMA1DAD_H 0xc2 OFFSET_REG_DMA1CNT 0xc4 OFFSET_REG_DMA1CNT_L 0xc4 OFFSET_REG_DMA1CNT_H 0xc6 OFFSET_REG_DMA2 0xc8 /* DMA 2*/ OFFSET_REG_DMA2SAD 0xc8 /* (Internal Memory -> Sound */ OFFSET_REG_DMA2SAD_L 0xc8 OFFSET_REG_DMA2SAD_H 0xca OFFSET_REG_DMA2DAD 0xcc OFFSET_REG_DMA2DAD_L 0xcc OFFSET_REG_DMA2DAD_H 0xce OFFSET_REG_DMA2CNT 0xd0 OFFSET_REG_DMA2CNT_L 0xd0 OFFSET_REG_DMA2CNT_H 0xd2 OFFSET_REG_DMA3 0xd4 /* DMA 3*/ OFFSET_REG_DMA3SAD 0xd4 /* (Game Pak/Internal Memory */ OFFSET_REG_DMA3SAD_L 0xd4 OFFSET_REG_DMA3SAD_H 0xd6 OFFSET_REG_DMA3DAD 0xd8 OFFSET_REG_DMA3DAD_L 0xd8 OFFSET_REG_DMA3DAD_H 0xda OFFSET_REG_DMA3CNT 0xdc OFFSET_REG_DMA3CNT_L 0xdc OFFSET_REG_DMA3CNT_H 0xde OFFSET_REG_TM0CNT 0x100 /* Timer 0*/ OFFSET_REG_TM0CNT_L 0x100 OFFSET_REG_TM0CNT_H 0x102 OFFSET_REG_TM1CNT 0x104 /* Timer 1*/ OFFSET_REG_TM1CNT_L 0x104 OFFSET_REG_TM1CNT_H 0x106 OFFSET_REG_TM2CNT 0x108 /* Timer 2*/ OFFSET_REG_TM2CNT_L 0x108 OFFSET_REG_TM2CNT_H 0x10a OFFSET_REG_TM3CNT 0x10c /* Timer 3*/ OFFSET_REG_TM3CNT_L 0x10c OFFSET_REG_TM3CNT_H 0x10e OFFSET_REG_RCNT 0x134 /* General Input/Output Control*/ OFFSET_REG_SIOCNT 0x128 /* Serial Communication Control*/ OFFSET_REG_SIODATA8 0x12a /* 8 bit Serial Communication Data*/ OFFSET_REG_SIODATA32 0x120 /* 32 bit Serial Communication Data*/ OFFSET_REG_SIOMLT_SEND 0x12a /* Multi-play SIO Send Data*/ OFFSET_REG_SIOMLT_RECV 0x120 /* Multi-play SIO Receive Data*/ OFFSET_REG_SIOMULTI0 0x120 OFFSET_REG_SIOMULTI1 0x122 OFFSET_REG_SIOMULTI2 0x124 OFFSET_REG_SIOMULTI3 0x126 OFFSET_REG_JOYCNT 0x140 /* JOY Bus Communication Control*/ OFFSET_REG_JOYSTAT 0x158 /* JOY Bus Status*/ OFFSET_REG_JOY_RECV 0x150 /* JOY Bus Receive Data*/ OFFSET_REG_JOY_RECV_L 0x150 OFFSET_REG_JOY_RECV_H 0x152 OFFSET_REG_JOY_TRANS 0x154 /* JOY Bus Send Data*/ OFFSET_REG_JOY_TRANS_L 0x154 OFFSET_REG_JOY_TRANS_H 0x156 OFFSET_REG_KEYINPUT 0x130 /* Key Input*/ OFFSET_REG_KEYCNT 0x132 /* Key Control*/ 0 0 509 AgbMultiBoot.h MULTIBOOT_NCHILD 3 /* Maximum number of slaves*/ MULTIBOOT_HEADER_SIZE 0xc0 /* Header size*/ MULTIBOOT_SEND_SIZE_MIN 0x100 /* Minimum transmission size*/ MULTIBOOT_SEND_SIZE_MAX 0x40000 /* Maximum transmission size*/ MULTIBOOT_ERROR_04 0x04 MULTIBOOT_ERROR_08 0x08 MULTIBOOT_ERROR_0c 0x0c MULTIBOOT_ERROR_40 0x40 MULTIBOOT_ERROR_44 0x44 MULTIBOOT_ERROR_48 0x48 MULTIBOOT_ERROR_4c 0x4c MULTIBOOT_ERROR_80 0x80 MULTIBOOT_ERROR_84 0x84 MULTIBOOT_ERROR_88 0x88 MULTIBOOT_ERROR_8c 0x8c MULTIBOOT_ERROR_NO_PROBE_TARGET 0x50 MULTIBOOT_ERROR_NO_DLREADY 0x60 MULTIBOOT_ERROR_BOOT_FAILURE 0x70 MULTIBOOT_ERROR_HANDSHAKE_FAILURE 0x71 MULTIBOOT_CONNECTION_CHECK_WAIT 15 MULTIBOOT_SERVER_TYPE_NORMAL 0 MULTIBOOT_SERVER_TYPE_QUICK 1 MULTIBOOT_HANDSHAKE_TIMEOUT 400 0 0 126 AgbTypes.h vl volatile ST_PSR_USER_MODE 0x10 /* User*/ ST_PSR_FIQ_MODE 0x11 /* FIQ*/ ST_PSR_IRQ_MODE 0x12 /* IRQ*/ ST_PSR_SVC_MODE 0x13 /* Supervisor*/ ST_PSR_ABORT_MODE 0x17 /* Abort (pre-fetch/data)*/ ST_PSR_UNDEF_MODE 0x1b /* Undefined command*/ ST_PSR_SYS_MODE 0x1f /* System*/ ST_DISP_OBJ_CHAR_2D_MAP 0 /* OBJ character data 2D mapping*/ ST_DISP_OBJ_CHAR_1D_MAP 1 /* OBJ character data 1D mapping*/ ST_BLD_NORMAL_MODE 0 /* Normal mode*/ ST_BLD_A_BLEND_MODE 1 /* Translucent mode*/ ST_BLD_UP_MODE 2 /* Brighness UP mode*/ ST_BLD_DOWN_MODE 3 /* Brightness DOWN mode*/ ST_BG_COLOR_16 0 /* Select 16 colors*/ ST_BG_COLOR_256 1 /* Select 256 colors*/ ST_OAM_OBJ_NORMAL 0 /* OBJ normal mode*/ ST_OAM_OBJ_BLEND 1 /* OBJ translucent mode*/ ST_OAM_OBJ_WINDOW 2 /* OBJ window mode*/ ST_OAM_AFFINE_NONE 0 /* Affine invalid mode*/ ST_OAM_AFFINE_NORMAL 1 /* Affine normal mode*/ ST_OAM_AFFINE_TWICE 3 /* Affine double angle mode*/ ST_OAM_AFFINE_ERASE 2 /* Affine non-display mode*/ ST_OAM_COLOR_16 0 /* Select 16 colors*/ ST_OAM_COLOR_256 1 /* Select 256 colors*/ ST_OAM_SQUARE 0 /* Square OBJ*/ ST_OAM_H_RECTANGLE 1 /* Horizontally-oriented rectangle OBJ*/ ST_OAM_V_RECTANGLE 2 /* Vertically-oriented rectangle OBJ*/ ST_SOUND_DMG_MIX_1_4 0 /* DMG compatible sound mixing ratio 1/4*/ ST_SOUND_DMG_MIX_2_4 1 /* 2/4*/ ST_SOUND_DMG_MIX_FULL 2 /* full range*/ ST_SOUND_DIRECT_MIX_1_2 0 /* Direct sound mixing ratio 1/2*/ ST_SOUND_DIRECT_MIX_FULL 1 /* full range*/ ST_SOUND_SWEEP_UP 0 /* Sweep addition*/ ST_SOUND_SWEEP_DOWN 1 /* subtraction*/ ST_SOUND_DUTY_1_8 0 /* Waveform duty 1/8*/ ST_SOUND_DUTY_2_8 1 /* 2/8*/ ST_SOUND_DUTY_4_8 2 /* 4/8*/ ST_SOUND_DUTY_6_8 3 /* 6/8*/ ST_SOUND_ENV_UP 1 /* Envelope UP*/ ST_SOUND_ENV_DOWN 0 /* DOWN*/ ST_SOUND_3_LEVEL_0_4 0 /* No sound 3 output*/ ST_SOUND_3_LEVEL_FULL 1 /* 4/4*/ ST_SOUND_3_LEVEL_2_4 2 /* 2/4*/ ST_SOUND_3_LEVEL_1_4 3 /* 1/4*/ ST_SOUND_3_LEVEL_3_4 4 /* 3/4*/ ST_SOUND_4_POLYSTEP_15 0 /* Sound 4 polynomical counter 15 steps*/ ST_SOUND_4_POLYSTEP_7 1 /* 7 steps*/ ST_SIO_8BIT_MODE 0 /* Normal 8-bit communication mode*/ ST_SIO_32BIT_MODE 1 /* Normal 32-bit communication mode*/ ST_SIO_SCK_OUT 0 /* Select external clock*/ ST_SIO_SCK_IN 1 /* Select internal clock*/ ST_SIO_IN_SCK_256K 0 /* Select internal clock 256KHz*/ ST_SIO_IN_SCK_2M 1 /* Select 2MHz */ ST_SIO_MULTI_MODE 2 /* Multi-play communication mode*/ ST_SIO_9600_BPS 0 /* Baud rate 9600 bps*/ ST_SIO_38400_BPS 1 /* 38400 bps*/ ST_SIO_57600_BPS 2 /* 57600 bps*/ ST_SIO_115200_BPS 3 /* 115200 bps*/ ST_SIO_MULTI_PARENT 1 /* Multi-play communication Connect master*/ ST_SIO_MULTI_CHILD 0 /* Connect slave*/ ST_SIO_UART_MODE 3 /* UART communication mode*/ ST_SIO_UART_7BIT 0 /* UART communication data length 7 bits*/ ST_SIO_UART_8BIT 1 /* 8 bits*/ ST_SIO_PARITY_EVEN 0 /* Even parity*/ ST_SIO_PARITY_ODD 1 /* Odd parity*/ ST_R_SIO_MASTER_MODE 0 /* SIO master mode*/ ST_R_DIRECT_MODE 2 /* General input/output communication mode*/ ST_R_JOY_MODE 3 /* JOY communication mode*/ ST_R_IN 0 /* Select input*/ ST_R_OUT 1 /* Select output*/ ST_DMA_TIMMING_IMM 0 /* Start immediately*/ ST_DMA_TIMMING_V_BLANK 1 /* Start V blank*/ ST_DMA_TIMMING_H_BLANK 2 /* Start H blank*/ ST_DMA_TIMMING_DISP 3 /* Start display*/ ST_DMA_TIMMING_SOUND 3 /* Start sound FIFO request*/ ST_DMA_16BIT_BUS 0 /* Select bus size 16 bits*/ ST_DMA_32BIT_BUS 1 /* Select bus size 32 bits*/ ST_DMA_INC 0 /* Select address increment*/ ST_DMA_DEC 1 /* Select address decrement*/ ST_DMA_FIX 2 /* Select address fix*/ ST_DMA_RELOAD 3 /* Select address increment/reload*/ ST_TMR_PRESCALER_1CK 0 /* Prescaler 1 clock*/ ST_TMR_PRESCALER_64CK 1 /* 64 clocks*/ ST_TMR_PRESCALER_256CK 2 /* 256 clocks*/ ST_TMR_PRESCALER_1024CK 3 /* 1024 clocks*/ ST_KEY_OR_INTR 0 /* Normal key interrupt*/ ST_KEY_AND_INTR 1 /* AND key interrupt*/ ST_CST_SRAM_4WAIT 0 /* SRAM 4 wait*/ ST_CST_SRAM_3WAIT 1 /* 3 wait*/ ST_CST_SRAM_2WAIT 2 /* 2 wait*/ ST_CST_SRAM_8WAIT 3 /* 8 wait*/ ST_CST_ROM_1ST_4WAIT 0 /* ROM 1st 4 wait*/ ST_CST_ROM_1ST_3WAIT 1 /* 3 wait*/ ST_CST_ROM_1ST_2WAIT 2 /* 2 wait*/ ST_CST_ROM_1ST_8WAIT 3 /* 8 wait*/ ST_CST_ROM0_2ND_2WAIT 0 /* ROM 0 2nd 2 wait*/ ST_CST_ROM0_2ND_1WAIT 1 /* 1 wait*/ ST_CST_ROM1_2ND_4WAIT 0 /* ROM 1 2nd 4 wait*/ ST_CST_ROM1_2ND_1WAIT 1 /* 1 wait*/ ST_CST_ROM2_2ND_8WAIT 0 /* ROM 2 2nd 8 wait*/ ST_CST_ROM2_2ND_1WAIT 1 /* 1 wait*/ ST_CST_PHI_OUT_NONE 0 /* terminal output clock Lo fix*/ ST_CST_PHI_OUT_4MCK 1 /* 4MHz*/ ST_CST_PHI_OUT_8MCK 2 /* 8MHz*/ ST_CST_PHI_OUT_16MCK 3 /* 16MHz*/ ST_CST_AGB 0 /* AGB game pak*/ ST_CST_CGB 1 /* CGB game pak*/ 0 0 729 IsAgbPrint.h void AGBPrintInit() void AGBPutc(char const) void AGBPrint(char const*) void AGBPrintf(char const*,...) void AGBPrintFlush1Block() void AGBPrintFlush() void AGBAssert(char const*,int,char const*,int) AGB_ASSERT() (exp) ? ((void*)0) : AGBAssert(__FILE__, __LINE__, #exp, 1); AGB_WARNING() (exp) ? ((void*)0) : AGBAssert(__FILE__, __LINE__, #exp, 0); 7 0 161 Backup Library Headers (/backup)This folder contains all the C include files for accessing Save Data on the cartridge for all the supported types of Backup chip (Flash/SRAM/EEPROM) File Name Extension Description AgbDacs .h Include file for declaring the unused DACS reading/writing functions such as ReadDacs AgbEeprom .h Include file for declaring EEPROM reading/writing functions such as ReadEepromDword AgbFlash .h Include file for declaring FLASH chip reading/writing functions such as EraseFlashSector AgbSram .h Include file for declaring the slower (but uses less WRAM) SRAM reading/writing functions such as ReadSram AgbSramFast .h Include file for declaring the faster (but more memory intensive) SRAM reading/writing functions such as ReadSramFast Backup Library Header Files AgbDacs.h dacsType const* dacs u32 dacs_remainder u16 IdentifyDacs() u16 SetDacsTimerIntr(u8,void(**)()) u32 ExchangeSectorToPhysAdr(u16) u32 ExchangePhysAdrToSector(u32) void ReadDacs(u16,u32,u16*,u32) u16 EraseDacsChip() u16 EraseDacsSector(u16) u16 ProgramDacs_NE(u16,u32,u16*,u32) u16 ProgramDacsSector(u16,u16*) u32 VerifyDacs(u16,u16,u16*,u32) u32 VerifyDacsSector(u16,u16*) 11 2 364 AgbSram.h void ReadSram(u8*,u8*,u32) void WriteSram(u8*,u8*,u32) u32 VerifySram(u8*,u8*,u32) SRAM_ADR 0x0e000000 /* SRAM Start Address*/ SRAM_SIZE_256K 0x00008000 /* 256KSRAM*/ SRAM_SIZE_512K 0x00010000 /* 512KSRAM */ 3 0 87 AgbSramFast.h void SetSramFastFunc() void(*)(u8*,u8*,u32) ReadSramFast void WriteSramFast(u8*,u8*,u32) u32(*)(u8*,u8*,u32) VerifySramFast SRAM_ADR 0x0e000000 /* SRAM Start Address*/ SRAM_SIZE_256K 0x00008000 /* 256KSRAM*/ SRAM_SIZE_512K 0x00010000 /* 512KSRAM*/ 2 2 103 API Libraries (/lib folder) /lib This folder contains all the libraries that a developer can link into their GBA game, they contains some useful functions for using system calls, game saves and IR communication. There are two types of library in this folder *.a and *.alf. The libraries included are as follows: libagbsyscall.a - System Call Library libagbsyscall_arm.alf - System Call Library (ARM version) libagbbackup.a - Save Game library libagbbackup_arm.alf - Save Game library (ARM version) libagbir.a - IR communication library libagbir_arm.alf - IR communication library (ARM version) libisagbprn.s - Assembly source code for the libisagbprn.a library libisagbprn.a - Debug library for Printing messages to console libisagbprn_arm.alf - Debug library for Printing messages to console (ARM version) Source code (/src folder)The source folder contains all the C and assembly source code for: Two demo games (Dolphin and Yoshi) 13 samples of GBA functionality The System Call library source code in ARM assembly Source code for all of the tools in the bin directoryDemo Source Code (src/demos)The GBA SDK comes with source code for 2 demo games: Yoshi - A demo using sprites from the N64 game Yoshi’s story Dolphin - A demo similar to ecco the dolphinFor more details on the two demos we have a separate post covering the details: Game Boy Advance SDK Demos For more information about the GBA SDK Demos check out this post. SysCall Library Source Code (src/lib/syscall)The Assembly source code for the SysCall library is available in the src/lib/syscall folder of the GBA SDK and is available in two different formats: GNU - GNU Assembler (GAS) format assembly code ARM - ARMASM format assembly codeThe source code is not particularly interesting as all it does is act as a wrapper around the 42 GBA Software Interrupts which you can find a full list of here:Tonc: Software InterruptsThey all follow the same format so here is an example:@********************************************************************@* AgbSysArcTan.s *@* AGB System Call Functions (for GAS) *@* *@* Copyright (C) 1999-2000 NINTENDO Co.,Ltd. *@********************************************************************\t\t.INCLUDE\t\"AgbDefine.s\"\t\t.INCLUDE\t\"AgbMemoryMap.s\"\t\t.TEXT\t\t.CODE 16@--------------------------------------------------------------------@-\t\tArc Tangent \t\t\t\t\t -@--------------------------------------------------------------------\t\t.GLOBAL\tArcTan\t\t.THUMB_FUNCArcTan:\t\t\tswi\t\t9 // This calls software interupt number 9\t\t\t\tbx\t\tlr // return and switch instruction set to THUMB if Least Significant Bit is 1 otherwise switch to ARM\t\t.ENDSample Source Code (src/samples)The SDK also comes with 13 sample projects, each showing off a different feature of the GBA hardware, this section would be huge if we went into detail on this page, so we have split it out into its own page. Game Boy Advance Software Development Kit Samples For more information about the Samples provided by the SDK check out this post. Tool Source Code (src/bin)The Tool Source Code folder holds the source code for most of the standard GBA development tools that deal with image conversion, the pre-compiled tools are available in the /bin directory.If you are interested in going in depth into the source code for how these tools works then we have a separate post covering just that: Game Boy Advance Tool Source Code For more information about the GBA SDK Tool Source Code check out this post. GBA CompilersThe compilers provided for the GBA were a modified version of GNU GCC distributed by Cygnus Solutions (Cygwin) for the ARM architecture. They provided an installed called AGBSetup2.exe on the AGB Developers ToolKit CD which installed the programs to C:\\Program files\\cygnus.The version of GCC shipped with the SDK is 2.95.1 which is handy to know when decompiling the games back to C source code, about 90% of games were compiled with this version including the Pokemon series of games.There is a RAR file called gba_compilers.rar that is an archive that contains the following files inside it: armelf-000512.zip - All the pre-compiled tools such as compilers and linkers thumb_patch03-OCT-03.zip - contains an updated version of the THUMB C compilers (cc1.exe and cc1plus.exe) src_patch021206.zip - Patch for arm-000512 from 2006 GNUPro021206.zip - Contains Setup.exe for installing the compiler toolchainIn the leaked version there is also a armelf-000512 folder which is not the contents of armelf-000512.zip but it looks like it is the GNU source code for the tools provided in that zip.", "excerpt": "Introduction This page covers release 3.0 of the english software development kit, but the other versions are very similar to this. It is unclear if this was the last release of the development kit. In the documentation Nintendo calls this SDK the GameBoy Advance Developers Kit 2000 presumably due to...", "tags": ["gba","sdk"], "image": "/public/images/gba/Game Boy Advance SDK.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game Boy Advance SDK Demos", "url": "/game-boy-advance-sdk-demos", "content": "Version 3.0 of the Game Boy Advance Software Development Kit (SDK) was leaked on to the internet for everyone to enjoy.There are some very interesting findings in this SDK, but this post will cover something particularly interesting, the demo games developed by Nintendo to show off the power of the GBA to developers.If you look in the src/demos folder you will find two pretty cool GBA game source code projects. One is a Yoshi’s Story example and the other is called Dolphin featuring Ricky the Dolphin!.Dolphin DemoDolphin is a demo game for the Game Boy Advance with very strong similarities to the Ecco the Dolphin series. You control a Dolphin called Ricky and can move through the water and go through rings. It is simple but a very nice tech demo for the possibilities of the GBA hardware.You can see it in action in the video below:This folder contains the main source code and build scripts required to compile the Dolphin example into a working GBA ROM. File Name Extension Description Agb_c2_s .bat Window Batch script to use Cygwin GCC to compile main.c Gasdepend N/A Lists dependencies for the GNU assembler to know when to reassemble crt0.s Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Main Makefile used to build the project bg .c, .h, .o Code for drawing Background images, such as water and coral floor crt0 .o, .s Implements the start function and bootstraps the program, all GBA games need this as it sets up the interrupts and jumps to the main function dolphin .bin, .elf, .map The generated game in both ELF and .bin (GBA ROM) formats, along with the linker map file containing all the final locations of code inside the game dolphin_readme .txt A Brief introduction to the game and how to play it enemy .c, .h, .o Main enemy logic such as drawing and hit detection enemy_dat .c, .o Enemy animation data (references images for each frame) game_dat .c, .o Just contains pre-computer sin and cos tables gdbrc N/A Configuration for the GNU debugger for debugging the game hitcheck .c, .h, .o Main collision detection logic main .c, .h, .o This contains the AgbMain function which starts the game along with the other main game logic player .c, .h, .o Main player logic such as drawing and moving player_dat .c, .o Just contains player animation data, references to each of the images used and the delay of each frame ring .c, .h, .o Contains all the logic for the rings, including drawing them and what happens when the dolphin moves through them rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs Code Files bg.c BgAnmPat[4] wave2nd_pat Bg Light Bg Coral Bg OceanA Bg OceanB Bg Sky u16[1024] UmiA_ScreenDat u16[1024] Bg2_ScreenDat u16[1024] Sky_ScreenDat u16[1024] Sango_ScreenDat s32 ocean_xPos s32 sora_xPos u8 DisplayArea BgAnm wave2nd void initwave2nd(BgAnm*) void Anm_wave2nd(BgAnm*) void InitBg() void BgProc(s32,s32) void Change_Bg_VRAM(s32,s32) void UpdateBg(s32,s32) void InitSky() void Init_Sky_ScreenDat() void DrawSky(s32,s32) void DeleteSky(s32,s32) void SoraRight() void SoraLeft() void InitCoral() void InitCoralScreenDat() void DrawCoral(s32,s32) void DeleteCoral(s32,s32) void CoralRight() void CoralLeft() void CoralUpDown() void InitLight() void InitLightScreenDat() void DrawLight(s32,s32) void DeleteLight(s32,s32) void InitOceanA() void InitOceanAScreenDat() void OceanA_Idle(Bg*,s32,s32) void DrawOceanA(s32,s32) void DeleteOceanA(s32,s32) void OceanA_Up(Bg*) void OceanA_Down(Bg*) void InitOceanB() void InitOceanBScreenDat() void DrawOceanB(s32,s32) void DeleteOceanB(s32,s32) void OceanB_Up() void OceanB_Down() 36 14 790 enemy.c Enemy[10] dEnemy Awa[16] awa Fukiya[4] fukiya u32 const[1][2] Oam_def u32 const[1][2] Oam_32x32dot u32 const[1][2] Oam_16x16dot u32 const[1][2] Oam_8x8dot u8[12] anm_state void InitEnemy() void EnemyProc() void CreateTeki(Enemy*,CharMapData*) void HitCheck_Enemy(Enemy*) void HitEnemy(Enemy*) void DeadCheckEnemy(Enemy*) void ControlEnemyMove(Enemy*) void MoveShell1(Enemy*,u8) void MoveShell2(Enemy*,u8) void ShellAttackMove(Enemy*,u8) void DeadMove(Enemy*,u8) void LcdCheckEnemy(Enemy*,Player*) void ShellAnim(Enemy*) void ShellBaseAnim(Enemy*) void ShellAttackAnim(Enemy*) void ShellDamageAnim(Enemy*) void ShellDeadAnim(Enemy*) void DrawEnemy(OamData*,Enemy*) void EraseEnemy(OamData*,Enemy*) void InitAwa() void AwaProc() void CreateAwa(Enemy*) void AwaMove(Awa*) void DrawAwa(OamData*,Awa*) void InitFukiya() void FukiyaProc() void CreateFukiya(Fukiya*,Enemy*) void FukiyaMove(Fukiya*) void DrawFukiya(OamData*,Fukiya*) 29 8 733 enemy_dat.c u8 const*[10] shell_base_pix_tbl Anmpat[10] shell_base_anm_pat u8 const*[21] shell_attack_pix_tbl Anmpat[13] shell_attack_anm_pat u8 const*[21] shell_yarare_pix_tbl Anmpat[21] shell_yarare_anm_pat CharMapData[12] shell_map_dat Enemy_Oam_Data[10] enemy_Oam_Data 0 8 143 game_dat.c u32 const[1][2] Oam_16x8dot u32 const[1][2] OamData_Sample short[256] sin_tbl short[256] cos_tbl u8[256] sintable 0 5 112 hitcheck.c void Fukiya2Dolphin(Player*,Fukiya*) void Dolphin2Enemy(Player*,Enemy*) void Ring2Dolphin(Ring*,Player*) u8 RingPass(Ring*,Player*) 4 0 201 main.c vu16 IntrCheck u16 Cont u16 Trg u32[512] IntrMainBuf ObjBuf Oam u8[256] rasttable u8 v_phase s8 amp_r s8 hz u8 state s16 counter u8 offset void(*[2])() pGame_func_tbl IntrFuncp const[15] IntrTable void AgbMain() void VBlankIntr() void HBlankIntr() void VCountIntr() void IntrDammy() void KeyRead() void GameInit() void GameMain() void GameOver() 9 14 325 player_dat.c u8 const*[6] r_kihon_pixel_tbl u8 const*[8] r_kihon_idle_pixel_tbl u8 const*[6] r_attack_pixel_tbl u8 const*[9] r_down_pixel_tbl u8 const*[29] r_up_down_pixel_tbl u8 const*[19] r_jump_pixel_tbl AnmTable2[7] rick_normal_move_pat AnmTable2[8] rick_kihon_idle_pat AnmTable2[19] rick_jump_anm_pat AnmTable[6] rick_attack_pat AnmTable[11] rick_kihon_fast_pat AnmTable[25] rick_jump_pat 0 12 270 player.c Player player Player_Awa[4] player_awa void InitPlayer() void PlayerProc() void DrawPlayer() void RestrictPlayerPosition(Player*) void PlayerActionControl() void Chang_Dir(Player*) void MovePlayer() void ChangeWaterSpeed() void Action1() void JumpPlayer() void Action3() void InitPlayerAnim() void PlayerAnim() void Player_kihon_anm() void Player_kihon_idle_anm() void Player_updown_anm() void Player_jump_anm() void Player_idle_anm() void Player_attack_anm() void Player_move_rl_anm() void Player_head_attack_anm() void Ajust_Light_Reflection(Player*) void BlinkPlayer(Player*) void InitPlayer_Awa() void Player_AwaProc() void CreatePlayer_Awa(Player_Awa*,Player*) void Player_AwaMove(Player_Awa*,Player*) void DrawPlayer_Awa(OamData*,Player_Awa*) 28 2 852 ring.c Ring[20] ring RingMapData[30] ring_map_dat u32 const[1][2] Oam_32x64dot void InitRing() void RingProc() void RingStateControl(Ring*) void CreateRing(Player*) void DrawRing(Ring*) void RingNormal(Ring*,u8) void RingPassed(Ring*,u8) void RingHit(Ring*,u8) 8 3 260 Dolphin/DocThis folder contains a brief document describing the Dolphin demo and the features it shows off.The document is simply called DemoProgramDolphin.doc, it is only 2 pages long and mainly contains details about how to play the game.However there are a few interesting parts including a very basic UML diagram for the game flow created in Microsoft Word.The document mentions a few key features of the demo: Usage of light reflections for the dolphin underwater Character animation via DMA transfer to VRAM H-Blank raster scroll processingIt’s funny how in the game source code the Dolphin’s name is Ricky but they only refer to him a “Dolphin” in the document, why give him a name like Ricky in the first place?Bg_parts (dolphin/bg_parts)This folder contains each part of the Background that makes up the game, in the original BMP format and the converted C source code equivalent and its compiled object.The BMP files are the only files of interest here as they would be fed to a tool called bmp2map that automatically converts it to a C-file (basically just encodes each byte of the BMP as an element of an array in C). The generated C files would then be compiled using the standard GBA toolchain compilers (GCC) and the object file (.o) would be created as the result.These object files would then be linked with the rest of the game code to generate the final ELF executable of the game, which would then be converted to a valid GBA ROM, whew! File Name Extension Description light4 .bmp, .c, .o A texture used to map on to Ricky when he is swimming under water to mimic underwater light sango1024x256 .bmp, .c, .o The Coral right at the bottom of the sea sora .bmp, .c, .o The sky image umiA_ .bmp, .c, .o water image umi_ab_256x512 .bmp, .c, .o Contains the water and sea floor wave2nd1 .bmp, .c, .o Wave image used for animating at the top of the water wave2nd2 .bmp, .c, .o Wave image used for animating at the top of the water wave2nd3 .bmp, .c, .o Wave image used for animating at the top of the water Images (dolphin/img)This folder contains all the sprite images used in the game. In the foot folder we have a few Misc sprites such as a bubble and the ring sprites, most of the other sprites are in the Oumgai and Ricky folders. File Name Extension Description awa .bmp Bubble sprite ring_32_64_left .bmp left sprite of the ring ring_32_64_right .bmp right sprite of the ring Oumgai sprites (dolphin/img/Oumgai)In the Oumgai folder we have tons of animation frames for a sea creature known as a Nautilus in English and Oumgai in Japanese.These are all in BMP but the resulting .c and .o files are in the dolphin/Obj folder. File Name Extension Description /Oumgai/O_fukiya .bmp A pink japanese Blowgun?! /Oumgai/O_kihon/O_kihon00(0-10) .bmp Normal animation frames /Oumgai/O_kougeki/O_kougeki000(0-20) .bmp Animation frames of movement /Oumgai/O_yarare/O_yarare0(0-20) .bmp Animation frames of movement Ricky sprites (dolphin/img/Ricky)In the Ricky folder we have tons of animation frames for the Ricky sprite, moving up/down/jumping etc.These are all in BMP but the resulting .c and .o files are in the dolphin/Obj folder. File Name Extension Description /Ricky/R_attack/R_attack(0-7) .bmp This folder contains animation frame of Ricky’s right attack /Ricky/R_down/R_down(0-8) .bmp This folder contains animation frames of Ricky looking down. /Ricky/R_up/R_up(0-8) .bmp This folder contains animation frames of Ricky looking up. /Ricky/R_go_down/R_go_down(0-7) .bmp This folder contains animation frames of Ricky moving down /Ricky/R_go_up/R_go_up(0-7) .bmp This folder contains animation frames of Ricky moving up /Ricky/R_jump/R_jump(0-10) .bmp This folder contains animation frames of Ricky jumping /Ricky/small/r_small(0-7) .bmp This folder contains small images of Ricky, not currently sure why /Ricky/R_kihon/R_kihon(0-7) .bmp This folder contains animation frames of Ricky moving forward Obj (dolphin/obj)This folder contains the generated output of all the image folder’s BMP files, the GBA SDK tends to refer to Sprites as Objects hence the name of this folder.These were generated by a tool called bmp2agb and then compiled from .c to .o in order to be linked into the final game.There is no point in listing these files as they are exactly the same as the BMP files listed in the IMG folder.Yoshi (/yoshi)This folder contains a demo game based on the Nintendo 64 title Yoshi’s story, this was a very impressive example running on the GBA hardware.You can see it in action in the video below:All the source code is here to build the example yourself and it makes an excellent project to learn how to reverse GBA games as you can see the original source code. File Name Extension Description Gasdepend N/A Lists dependencies for the GNU assembler to know when to reassemble crt0.s Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Main Makefile used to build the project Readme .txt Fairly detailed instructions for the game and how to build it bg_proc .c, .o Logic for drawing the background layers crt0 .o, .s Implements the start function and bootstraps the program, all GBA games need this as it sets up the interrupts and jumps to the main function etc_bmp .h Include file that just exports pointers to each of the bmp images gdbrc N/A Configuration for the GNU debugger for debugging the game isle_bmp .h Include file for declaring pointers to every image of the rotating island sprite ldscript .x Ld script that tells the Linker where to place data in the resulting ELF menu .c, .o   menu_bmp .h Include file for declaring pointers to every image of the menu menu_dat .c, .h, .o   oam_proc .c, .h, .o   reverbpatch .o   rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs soundpatch .o   yos_anm .c, .h, .o   yos_bmp .h Include file for declaring pointers to every image of the main game sprites yos_game .c, .ext, .h, .o   yos_game_dat .c, .h, .o   yos_game_mov .c, .h, .o   yos_game_pr .c, .h, .o   yos_game_sub .c, .h, .o   yos_main .c, .ext, .h, .o   yos_main_dat .c, .h, .o Just contains pre-generated sin/cos tables yos_sound .h Include file for declaring a few preprocessor macros used for sound effects yos_type .h Include file for declaring a few custom coordinate types such as xyPos_tag yoshi .bin, .elf, .map The main game executable in ELF format and the converted GBA rom file (.bin) along with the symbol MAP which shows where the code is inside the game It is worth reading the Readme.txt file in this directory, most of the time Readmes are not that interesting but in this case you would be worse off not reading it. It provides an excellent overview of what the demo is showcasing and how it all works.BMP images (yoshi/bmp/*)This folder contains images used in the game in bmp format and the compiled versions in .c and .o formats (created with bmp2map). File Name Extension Description */Makefile N/A Makefile to convert .bmp files into .o files by running bmp2map */bmpfiles N/A List of all the BMP files to convert (read from the Makefile) islebmp/libislebmp .a Static Library archive of all the island animation images islebmp/yoshi_island_9909070(1-60) .bmp, .o Each image is a frame in an animation of the island spinning around menubmp/grade .bmp, .o Gradient image used for the menu menubmp/kumo .bmp, .o Static-like texture used for the menu menubmp/libmenubmp .a Static Library archive of all the menu images menubmp/umi64 .bmp, .o Water image used for the menu yosbgbmp/bg1 .bmp, .c, .o, .plb The background image used for the platforms/path that Yoshi walks on yosbgbmp/bg2 .bmp, .c, .o The background image used for the hills in the background yosbgbmp/bg2_5 .bmp The background image used for the hills in the background but with a texture applied to it yosbgbmp/bg3 .bmp, .c, .o The background image used for the Sky (says made in japan on it) yosbgbmp/libyosbgbmp .a Static Library archive of all the background images used in the level yosbgbmp/tmp .bmp I think this is a tileset image? What is the bg1.plb file and what is it used for? Possibly collision detection?Yosbmp (yoshi/bmp/yosbmp)This folder contains sprites used in the Yoshi level including all the animation frames.This folder contains .imb files which are the result of calling bmp2bin on the BMP images and .o files which are the result of calling objcopy on the same images. File Name Extension Description CCCC_A .bmp, .imb, .o   CCCC_B .bmp, .imb, .o   CCCC_C .bmp, .imb, .o   DDDD_A .bmp, .imb, .o   DDDD_B .bmp, .imb, .o   DDDD_C .bmp, .imb, .o   HANABIRA1 .bmp, .imb, .o   HANABIRA2 .bmp, .imb, .o   HANABIRA3 .bmp, .imb, .o   HANABIRAn_1 .bmp, .imb, .o   HANABIRAn_2 .bmp, .imb, .o   HANABIRAn_3 .bmp, .imb, .o   HANABIRAy_1 .bmp, .imb, .o   HANABIRAy_2 .bmp, .imb, .o   HANABIRAy_3 .bmp, .imb, .o   HEIHO929_001 .bmp, .imb, .o   HEIHO929_001_b .bmp, .imb, .o   HEIHO929_001_g .bmp, .imb, .o   HEIHO929_001_y .bmp, .imb, .o   HEIHO929_003 .bmp, .imb, .o   HEIHO929_003_b .bmp, .imb, .o   HEIHO929_003_g .bmp, .imb, .o   HEIHO929_003_y .bmp, .imb, .o   HEIHO929_005 .bmp, .imb, .o   HEIHO929_005_b .bmp, .imb, .o   HEIHO929_005_g .bmp, .imb, .o   HEIHO929_005_y .bmp, .imb, .o   HEIHO929_007 .bmp, .imb, .o   HEIHO929_007_b .bmp, .imb, .o   HEIHO929_007_g .bmp, .imb, .o   HEIHO929_007_y .bmp, .imb, .o   HEIHO929_009 .bmp, .imb, .o   HEIHO929_009_b .bmp, .imb, .o   HEIHO929_009_g .bmp, .imb, .o   HEIHO929_009_y .bmp, .imb, .o   HEIHO929_011 .bmp, .imb, .o   HEIHO929_011_b .bmp, .imb, .o   HEIHO929_011_g .bmp, .imb, .o   HEIHO929_011_y .bmp, .imb, .o   HEIHO929_013 .bmp, .imb, .o   HEIHO929_013_b .bmp, .imb, .o   HEIHO929_013_g .bmp, .imb, .o   HEIHO929_013_y .bmp, .imb, .o   HEIHO929_015 .bmp, .imb, .o   HEIHO929_015_b .bmp, .imb, .o   HEIHO929_015_g .bmp, .imb, .o   HEIHO929_015_y .bmp, .imb, .o   HEIHO_l_001 .bmp, .imb, .o   HEIHO_l_003 .bmp, .imb, .o   HEIHO_l_005 .bmp, .imb, .o   HEIHO_l_007 .bmp, .imb, .o   HEIHO_l_009 .bmp, .imb, .o   HEIHO_l_011 .bmp, .imb, .o   HEIHO_l_013 .bmp, .imb, .o   HEIHO_l_015 .bmp, .imb, .o   HEIHO_l_turn_002 .bmp, .imb, .o   HEIHO_l_turn_003 .bmp, .imb, .o   HEIHO_normal_walk_turn_002 .bmp, .imb, .o   HEIHO_normal_walk_turn_002_b .bmp, .imb, .o   HEIHO_normal_walk_turn_002_g .bmp, .imb, .o   HEIHO_normal_walk_turn_002_y .bmp, .imb, .o   HEIHO_normal_walk_turn_003 .bmp, .imb, .o   HEIHO_normal_walk_turn_003_b .bmp, .imb, .o   HEIHO_normal_walk_turn_003_g .bmp, .imb, .o   HEIHO_normal_walk_turn_003_y .bmp, .imb, .o   Makefile N/A   NNNN_A .bmp, .imb, .o   NNNN_B .bmp, .o   NNNN_C .bmp, .o   PS_MEPACHI_B2 .bmp, .o   PS_MEPACHI_B3 .bmp, .o   PS_MEPACHI_B4 .bmp, .o   PS_MEPACHI_B5 .bmp, .o   PS_MEPACHI_B6 .bmp, .o   PS_MEPACHI_M2 .bmp, .o   PS_MEPACHI_M3 .bmp, .o   PS_MEPACHI_M4 .bmp, .o   PS_MEPACHI_M5 .bmp, .o   PS_MEPACHI_M6 .bmp, .o   PS_MEPACHI_Y2 .bmp, .o   PS_MEPACHI_Y3 .bmp, .o   PS_MEPACHI_Y4 .bmp, .o   PS_MEPACHI_Y5 .bmp, .o   PS_MEPACHI_Y6 .bmp, .o   PS_U_turn1 .bmp, .o   PS_U_turn2 .bmp, .o   PS_U_turn3 .bmp, .o   PS_U_turn4 .bmp, .o   PS_U_turn5 .bmp, .o   PS_U_turn6 .bmp, .o   PS_U_turn7 .bmp, .o   PS_U_turn8 .bmp, .o   PS_hey1 .bmp, .o   PS_hey2 .bmp, .o   PS_hey3 .bmp, .o   PS_hey4 .bmp, .o   PS_hey5 .bmp, .o   PS_hey6 .bmp, .o   PS_hey7 .bmp, .o   PS_hey8 .bmp, .o   PS_jump1 .bmp, .o   PS_jump2 .bmp, .o   PS_jump3 .bmp, .o   PS_jump4 .bmp, .o   PS_jump5 .bmp, .o   PS_jump6 .bmp, .o   PS_jump7 .bmp, .o   PS_jump8 .bmp, .o   PS_kihon_M .bmp, .o   PS_kihon_Y .bmp, .o   PS_kyoro_B .bmp, .o   PS_kyoro_B10 .bmp, .o   PS_kyoro_B11 .bmp, .o   PS_kyoro_B2 .bmp, .o   PS_kyoro_B3 .bmp, .o   PS_kyoro_B4 .bmp, .o   PS_kyoro_B5 .bmp, .o   PS_kyoro_B6 .bmp, .o   PS_kyoro_B7 .bmp, .o   PS_kyoro_B8 .bmp, .o   PS_kyoro_B9 .bmp, .o   PS_kyoro_M10 .bmp, .o   PS_kyoro_M11 .bmp, .o   PS_kyoro_M2 .bmp, .o   PS_kyoro_M3 .bmp, .o   PS_kyoro_M4 .bmp, .o   PS_kyoro_M5 .bmp, .o   PS_kyoro_M6 .bmp, .o   PS_kyoro_M7 .bmp, .o   PS_kyoro_M8 .bmp, .o   PS_kyoro_M9 .bmp, .o   PS_kyoro_Y10 .bmp, .o   PS_kyoro_Y11 .bmp, .o   PS_kyoro_Y2 .bmp, .o   PS_kyoro_Y3 .bmp, .o   PS_kyoro_Y4 .bmp, .o   PS_kyoro_Y5 .bmp, .o   PS_kyoro_Y6 .bmp, .o   PS_kyoro_Y7 .bmp, .o   PS_kyoro_Y8 .bmp, .o   PS_kyoro_Y9 .bmp, .o   PS_kyoro_YR10 .bmp, .o   PS_kyoro_YR11 .bmp, .o   PS_kyoro_YR2 .bmp, .o   PS_kyoro_YR3 .bmp, .o   PS_kyoro_YR4 .bmp, .o   PS_kyoro_YR5 .bmp, .o   PS_kyoro_YR6 .bmp, .o   PS_kyoro_YR7 .bmp, .o   PS_kyoro_YR8 .bmp, .o   PS_kyoro_YR9 .bmp, .o   PS_turn1 .bmp, .o   PS_turn2 .bmp, .o   PS_turn3 .bmp, .o   PS_turn4 .bmp, .o   PS_turn5 .bmp, .o   PS_turn6 .bmp, .o   PS_turn7 .bmp, .o   PS_turn_L1 .bmp, .o   PS_turn_L2 .bmp, .o   PS_turn_L3 .bmp, .o   PS_turn_L4 .bmp, .o   PS_turn_L5 .bmp, .o   PS_turn_L6 .bmp, .o   PS_turn_L7 .bmp, .o   PS_turn_back1 .bmp, .o   PS_turn_back2 .bmp, .o   PS_turn_back3 .bmp, .o   PS_turn_back4 .bmp, .o   PS_turn_back5 .bmp, .o   PS_turn_back6 .bmp, .o   PS_turn_back7 .bmp, .o   PS_turn_mae1 .bmp, .o   PS_turn_mae2 .bmp, .o   PS_turn_mae3 .bmp, .o   PS_turn_mae4 .bmp, .o   PS_turn_mae5 .bmp, .o   PS_turn_mae6 .bmp, .o   PS_turn_mae7 .bmp, .o   PS_walk_B1 .bmp, .o   PS_walk_B10 .bmp, .o   PS_walk_B11 .bmp, .o   PS_walk_B12 .bmp, .o   PS_walk_B13 .bmp, .o   PS_walk_B14 .bmp, .o   PS_walk_B15 .bmp, .o   PS_walk_B16 .bmp, .o   PS_walk_B2 .bmp, .o   PS_walk_B3 .bmp, .o   PS_walk_B4 .bmp, .o   PS_walk_B5 .bmp, .o   PS_walk_B6 .bmp, .o   PS_walk_B7 .bmp, .o   PS_walk_B8 .bmp, .o   PS_walk_B9 .bmp, .o   PS_walk_M1 .bmp, .o   PS_walk_M10 .bmp, .o   PS_walk_M11 .bmp, .o   PS_walk_M12 .bmp, .o   PS_walk_M13 .bmp, .o   PS_walk_M14 .bmp, .o   PS_walk_M15 .bmp, .o   PS_walk_M16 .bmp, .o   PS_walk_M2 .bmp, .o   PS_walk_M3 .bmp, .o   PS_walk_M4 .bmp, .o   PS_walk_M5 .bmp, .o   PS_walk_M6 .bmp, .o   PS_walk_M7 .bmp, .o   PS_walk_M8 .bmp, .o   PS_walk_M9 .bmp, .o   PS_walk_Y1 .bmp, .o   PS_walk_Y10 .bmp, .o   PS_walk_Y11 .bmp, .o   PS_walk_Y12 .bmp, .o   PS_walk_Y13 .bmp, .o   PS_walk_Y14 .bmp, .o   PS_walk_Y15 .bmp, .o   PS_walk_Y16 .bmp, .o   PS_walk_Y2 .bmp, .o   PS_walk_Y3 .bmp, .o   PS_walk_Y4 .bmp, .o   PS_walk_Y5 .bmp, .o   PS_walk_Y6 .bmp, .o   PS_walk_Y7 .bmp, .o   PS_walk_Y8 .bmp, .o   PS_walk_Y9 .bmp, .o   SSSS_A .bmp, .o   SSSS_B .bmp, .o   SSSS_C .bmp, .o   balloon .bmp, .o   balloon01 .bmp, .o   balloon02 .bmp, .o   balloon03 .bmp, .o   balloon04 .bmp, .o   balloon05 .bmp, .o   balloon06 .bmp, .o   balloon07 .bmp, .o   balloon08 .bmp, .o   balloon09 .bmp, .o   balloon10 .bmp, .o   balloon11 .bmp, .o   balloon12 .bmp, .o   balloon13 .bmp, .o   batabata1 .bmp, .o   batabata2 .bmp, .o   batabata3 .bmp, .o   batabata4 .bmp, .o   batabata5 .bmp, .o   batabata6 .bmp, .o   batabata7 .bmp, .o   batabata8 .bmp, .o   bmpfiles N/A   bomb_1 .bmp, .o   bomb_2 .bmp, .o   bomb_3 .bmp, .o   bomb_4 .bmp, .o   bomb_5 .bmp, .o   casle1 .bmp, .o   casle1p .bmp, .o   casle3 .bmp, .o   casle3p .bmp, .o   casle4 .bmp, .o   casle4p .bmp, .o   casle5 .bmp, .o   casle5p .bmp, .o   casle6 .bmp, .o   casle6p .bmp, .o   casle7 .bmp, .o   casle7p .bmp, .o   dokan .bmp, .o   egg .bmp, .o   hana .bmp, .o   hosi1 .bmp, .o   hosi2 .bmp, .o   hosi3 .bmp, .o   hosi4 .bmp, .o   hosi5 .bmp, .o   hosi6 .bmp, .o   hosi7 .bmp, .o   hosi8 .bmp, .o   kage0 .bmp, .o   kagel .bmp, .o   killer_l1 .bmp, .o   killer_l2 .bmp, .o   killer_l3 .bmp, .o   killer_lA .bmp, .o   killer_lAA .bmp, .o   killer_lB .bmp, .o   killer_lC .bmp, .o   killer_lD .bmp, .o   killer_lE .bmp, .o   killer_s1 .bmp, .o   killer_s2 .bmp, .o   killer_s3 .bmp, .o   killer_sA .bmp, .o   killer_sAA .bmp, .o   killer_sB .bmp, .o   killer_sC .bmp, .o   killer_sD .bmp, .o   killer_sE .bmp, .o   kokamek_a .bmp, .o   kokamek_c .bmp, .o   kokamek_d .bmp, .o   kokamek_e .bmp, .o   koumori .bmp, .o   kuki .bmp, .o   kumo_nuki_l .bmp, .o   kumo_nuki_r .bmp, .o   kururi1 .bmp, .o   kururi2 .bmp, .o   kururi3 .bmp, .o   kururi4 .bmp, .o   kururi5 .bmp, .o   kururi6 .bmp, .o   kururi7 .bmp, .o   kururi8 .bmp, .o   libyosbmp .a   mBOX1 .bmp, .o   mBOX2 .bmp, .o   omori5t .bmp, .o   sPPPP_A .bmp, .o   sPPPP_B .bmp, .o   sPPPP_C .bmp, .o   toge .bmp, .o   Sound (yoshi/sound)Just as the name might imply this folder contains the sounds used in the demo, it is using a GBA Sound library library called m4alib which you can find out more about in our other post. M4A Music Library for Game Boy Advance (GBA) For more information about the M4A Sound library check out this post. This folder only contains the pre-compiled object files, presumably these have been converted from a sound format and compiled into these for easy linking with the rest of the game.Sadly the original sound files don’t seem to exist. File Name Extension Description SoundDat .o   Soundfiles N/A List of all sound object files to link to the game, used by the Makefile bm_atri .o   c_gaonn .o   e_derup .o   e_onpp1 .o   e_torup .o   ht_atar .o   ht_ware .o   i_b_sx .o   i_bell .o   i_bscl .o   i_drm1 .o   i_drm2 .o   i_elsn .o   i_mari .o   i_strg .o   i_timp .o   i_vb_t .o   i_vibe .o   ki_sid2 .o   km_ukuu .o   m4aLib .h, .o   m5t_dsin .o   mc_gaonn .o   me_derup .o   me_onpp1 .o   me_onpp2 .o   me_onpp3 .o   me_torup .o   mh_kaitn .o   mht_apir .o   mht_atar .o   mht_ware .o   mki_sid1 .o   mki_sid2 .o   mkm_ukuu .o   mm_1game .o   mm_gover .o   mm_title .o   mov_arra .o   mtg_raka .o   mtp_stat .o   my_dmgn1 .o   my_dmgn2 .o   my_dwnau .o   my_hipha .o   my_hipkr .o   my_jmpfm .o   my_jmph1 .o   my_jmpst .o   my_jmpy1 .o   my_pakon .o   my_stph1 .o   my_stpn1 .o   my_tont1 .o   my_tont2 .o   my_upup .o   ov_arra .o   ov_basa .o   ov_hkob .o   ov_konn .o   ov_shaa .o   ov_sir2 .o   t5_dsin .o   t5_undr .o   tg_raka .o   y_dmgn1 .o   y_dmgn2 .o   y_dwnau .o   y_hipha .o   y_hipkr .o   y_jmpfm .o   y_jmph1 .o   y_jmpst .o   y_jmpy1 .o   y_pakon .o   y_runtn .o   y_stph1 .o   y_stpn1 .o   y_stpqu .o   y_tont1 .o   y_tont2 .o   y_upup .o   y_ywiha .o   Zelda 2 Tech demoA long-rumored Zelda II tech demo for GBA has finally surfaced, ROM and source code included!It's a included as reference in the GBA SDK, found on a Spongebob GBA dev disc uploaded by @JacobLenstar.ROM + Source:https://t.co/p9aCkSF8Q1Full archive:https://t.co/7hquBy9lnX pic.twitter.com/mrvtbkudJ8— MrTalida (@MrTalida) December 22, 2019", "excerpt": "Version 3.0 of the Game Boy Advance Software Development Kit (SDK) was leaked on to the internet for everyone to enjoy. There are some very interesting findings in this SDK, but this post will cover something particularly interesting, the demo games developed by Nintendo to show off the power of...", "tags": ["gba","sdk"], "image": "/public/images/gba/Game Boy Advance SDK Demos.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "M4A Music Library for Game Boy Advance (GBA)", "url": "/game-boy-advance-sdk-m4a", "content": "IntroductionWhat is the M4A Library?The M4A library otherwise known as Make SoundCodes for AGB (MKS4AGB) is used to play sound on the Game Boy Advance.Where can I get the M4A Library?Version 3.0 of the Game Boy Advance SDK includes a folder called MusicPlayerAGB2000, this contains the documentation and some pre-compiled object files which the documentation calls sound object file groups.How does it work?The documentation for the library mentions that the pre-compiled sound object files are normally provided by the sound engineer on the team.These are then linked to the program and the programmer can then use pre-build API functions to play them on the Game Boy Advance.What are sound object file groups?These are the result of converting standard Sound formats (AIFF & MIDI) into a format that can be given to a programmer to link directly into the game.This allows the programmer to directly take the resulting sound object files and add them to their standard Makefile and play the sounds using the M4A API.How do I convert sounds into sound objects?There are a number of useful executables in the mp2000 folder: aif2agb.exe - Convert AIFF format files to assembly code (*.s) mid2agb.exe - Convert MIDI format files to assembly code (*.s) mks4agb.exe - main application that calls the other two based on the .ini file configuration for whole folders of sound filesHow were the sound objects created?The library is built to make it as easy as possible for both the sound engineer and the game programmers to inject sound into their game.On the sound engineer front all they need to do is create their standard AIFF and MIDI files, put them in a folder and run a program to automatically convert them to a format the programmer can use.It does this by looping through the files configured in mks4agb.ini and calling either aif2agb.exe or mid2agb.exe depending on the file format.This then generates Assembly sound code which represents the data.For example if you have a MIDI file called bgm_title3.mid and run it through the converter you will get bgm_title3.s as output.This assembly file can then be modified if required and assembled with the GNU Assembler (GAS) to produce the sound object files to give to the programmer.How are the sound objects used?There are a number of files that are required in order to bring the M4A library into your Game Boy Advance project, they are: MusicPlayDef.s - Assembly code used for sony data mks4agbLib.o - Compiled library functionality mks4agbLib.h - Header file for using the library in a game m4aLibOD1.o - Compiled code for use when Only DMA 1 mode is active m4aLibUSC.o - Compiled code for use when System ROM mode is selectedCan a sound engineer test the music without building the main game?Yes! When the tool is run it also outputs a file called SoundMon.elf this is an executable GBA program that can be loaded into the IS-AGB-EMULATOR and provides a simple menu for playing back the sounds converted using mks4agb.exe.What is Direct Sound and Compatible Sound?Compatible sound is 4 channels of Mono sounds which is backwards compatible with the Game Boy Color. Direct Sound is 12 channel Stereo and only for GBA games.Both Direct Sound and Compatible Sound can be used at the same time in Game Boy Advance games to provide some excellent music!Sound Developer’s Tutorial (/AllManual/musicplayer/sound_dev/Tutorial)As part of the documentation Nintendo provided a demo of both AIFF and MIDI music playing on the GBA. The demo shows Wario flying in a plane around while the background music plays and has a few sound effects too.The table below shows all the the Data required to follow the tutorial, including the ROM file that can be played in any GBA emulator. File Name Extension Description AiffFiles .ZIP The sample AIFF music files used in the Demo game IniFile .zip This provides the sample mks4agb.ini that is created during the tutorial MidiFiles .zip The sample MIDI music files used in the Demo game m_Sample .zip The modified sample Assembly code used in the tutorial mp2kdemo .zip This contains the mp2kdemo.bin GBA ROM with Wario flying around with sounds Reverse EngineeringHow can I tell if a game is using the M4A library?If you use radare2 or IDA pro you can run these FLAIR signatures on your game to find out:laqieer/gba_lib_func_sig: Game Boy Advance Library Function Signature for Reverse EngineeringIf it matches any of the m4aLib functions then you know your game uses it.What are the main functions in the M4A LibraryYou can view the main exports in the mks4agbLib.h header file below: mks4agbLib.h u8 const[] __sound_mode_i u8 const[] __total_mplay_n u8 const[] __total_song_n SoundArea m4a_sound MPlayTable const[] mplay_table SongTable const[] song_table u8[] m4a_memacc_area void m4aSoundInit() void SoundMode_rev01(u32) void m4aSoundMain() void SoundVSync_rev01() void SoundVSyncOff_rev01() void SoundVSyncOn_rev01() void MPlayStart_rev01(MusicPlayerArea*,SongHeader*) void m4aSongNumStart(u16) void m4aSongNumStartOrChange(u16) void m4aSongNumStartOrContinue(u16) void m4aMPlayImmInit(MusicPlayerArea*) void MPlayStop_rev01(MusicPlayerArea*) void m4aSongNumStop(u16) void m4aMPlayAllStop() void m4aMPlayContinue(MusicPlayerArea*) void m4aSongNumContinue(u16) void m4aMPlayAllContinue() void m4aMPlayFadeOut(MusicPlayerArea*,u16) void MPlayTempoControl(MusicPlayerArea*,u16) void MPlayVolumeControl(MusicPlayerArea*,u16,u16) void MPlayPitchControl(MusicPlayerArea*,u16,s16) void MPlayPanpotControl(MusicPlayerArea*,u16,s8) void MPlayModDepthSet(MusicPlayerArea*,u16,u8) void MPlayLFOSpeedSet(MusicPlayerArea*,u16,u8) 24 7 125 ", "excerpt": "Introduction What is the M4A Library? The M4A library otherwise known as Make SoundCodes for AGB (MKS4AGB) is used to play sound on the Game Boy Advance. Where can I get the M4A Library? Version 3.0 of the Game Boy Advance SDK includes a folder called MusicPlayerAGB2000, this contains the...", "tags": ["gba","sdk"], "image": "/public/images/gba/Game Boy Advance SDK M4A.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game Boy Advance Software Development Kit Samples", "url": "/game-boy-advance-sdk-samples", "content": "Blib sample (/blib_sample)This folder contains File Name Extension Description DacsTest .c, .o   Data .c, .o   EepromTest .c, .o   FlashTest .c, .o   Main .c, .h, .o   Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) MemDump .c, .o   SramTest .c, .o   blib_sample .bin, .elf, .map   crt0 .o, .s Implements the start function and bootstraps the program, all games need this as it sets up the interrupts and jumps to the main function crt0_arm .s Assembly source file containing dummy .c   gasDepend N/A Lists dependencies to tell the GNU Assembler (GAS) when to re-assemble files gdbrc N/A Configuration for the GNU debugger for debugging the game history .txt   isdwdcmd .dat   isdwdsym .dat   rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs rom_header_arm .s Assembly source file containing Code Files Data.c u16 const[16][16] textPaletteData u16 const[6144] mychar 0 2 791 dummy.c void DummyFlash() 1 0 4 Mylib (/blib_sample/mylib)This folder contains File Name Extension Description bg .h Include file for declaring isdwdcmd .dat   isdwdsym .dat   libmyfunc .a Static Library archive of myTypes .h Include file for declaring mylib .h Include file for declaring obj .h Include file for declaring stdSub .h Include file for declaring Code Files bg.h void InitBg() void SetBgMode(u16) u16 GetBgMode() void SetBgxBuffer(u8,u16*,u32) void SetBgxBuffRenewal(u8,bool) buffer* GetBgxBuffer(u8) u16* GetBgxBuffPointer(u8) u32 GetBgxBuffSize(u8) void ClearBgxBuffer(u8,u16) void DmaBgxBuffer(u8) void DmaAllBgxBuffer() void TrmScreenDataToBgxBufferByFunc(u8,void(*)(u16*,u32)) void TrmScreenDataToBgxBuffer(u8,u16 const*,u32) void ClearBgxScreenRect(u8,u16,u8,u8) void SetFlameBuff(u8,u16*) u16* GetFlameBuff(u8) void SetScreenSize(u8,u16) u16 GetScreenSize(u8) void SetBgxScreenBaseBlock(u8,u16) u16 GetBgxScreenBaseBlock(u8) void SetBgxScreenBaseAdr(u8,u32) u32 GetBgxScreenBaseAdr(u8) void SetMosaicEnable(u8) void SetBgxMosaicEnable(u8,u16) u16 GetBgxMosaicEnable(u8) void SetBgxColorMode(u8,u16) u16 GetBgxColorMode(u8) void SetBgxCharBaseBlock(u8,u16) u16 GetBgxCharBaseBlock(u8) void SetBgxCharBaseAdr(u8,u32) u32 GetBgxCharBaseAdr(u8) void SetBgxPriority(u8,u16) u16 GetBgxPriority(u8) void SetBgxAreaOver(u8,u16) u16 GetBgxAreaOver(u8) void SetBgxPosX(u8,u16) u16 GetBgxPosX(u8) void RelativeScrollBgxPosX(u8,u16) void SetBgxPosY(u8,u16) u16 GetBgxPosY(u8) void RelativeScrollBgxPosY(u8,u16) void SetRbgxHVflip(u8,bool,bool) void CalcRbgxAffineValue(u8,s16,s16,u8) void CalcRbgxReferenceStartPos(u8,pos_2d,pos_2d) void RotateZoomRbgx(u8) void RevBgxAffineValue(u8,u8) void SetParagraph(bool,u8,u16) u16 DrawAsciiCharOnBgx(u8,u16,u16,u8 const*,u8) u16 DrawAsciiStringOnBgx(u8,u16,u16,u8 const*) u16 DrawHexOnBgx(u8,u16,u16,void const*,u8) u16 DrawHalfByteHexOnBgx(u8,u16,u16,void const*,u8) u16 DrawUIntOnBgx(u8,u16,u16,void const*,u8,u8) u16 DrawSIntOnBgx(u8,u16,u16,void const*,u8,u8) 53 0 127 myTypes.h NULL 0x00000000 BG_PLTT_WHITE ( 8 BG_PLTT_ORANGE ( 9 BG_PLTT_RED (10 BG_PLTT_BLUE (11 BG_PLTT_YELLOW (12 BG_PLTT_GREEN (13 BG_PLTT_PURPLE (14 OBJ_PLTT_WHITE 8 OBJ_PLTT_ORANGE 9 OBJ_PLTT_RED 10 OBJ_PLTT_BLUE 11 OBJ_PLTT_YELLOW 12 OBJ_PLTT_GREEN 13 OBJ_PLTT_PURPLE 14 false 0 true 1 AGING_STATE_INITIAL 0 AGING_STATE_EXECUTE 1 AGING_STATE_COMPLETE 2 AGING_STATE_BREAK 3 AGING_STATE_ERROR 4 DEVICE_DACS 0 DEVICE_EEPROM 1 DEVICE_FLASH 2 DEVICE_SRAM 3 DEVICE_EMPTY 7 0 0 100 mylib.h 0 0 16 obj.h OBJ_V_SIZE_64 0xc000 OBJ_V_SIZE_32 0x8000 OBJ_V_SIZE_16 0x4000 OBJ_V_SIZE_8 0x0000 OBJ_COLOR_256 0x2000 OBJ_COLOR_16 0x0000 OBJ_MOSAIC_ON 0x1000 OBJ_MOSAIC_OFF 0x0000 OBJ_MODE_WINDOW 0x0800 OBJ_MODE_BLEND 0x0400 OBJ_MODE_NORMAL 0x0000 OBJ_AFFINE_X2 0x0300 OBJ_AFFINE_X1 0x0100 OBJ_AFFINE_OFF 0x0000 OBJ_Y 0x00ff OBJ_H_SIZE_64 0xc000 OBJ_H_SIZE_32 0x8000 OBJ_H_SIZE_16 0x4000 OBJ_H_SIZE_8 0x0000 OBJ_HV_FLIP 0x3000 OBJ_V_FLIP 0x2000 OBJ_H_FLIP 0x1000 OBJ_AFFINE_NO 0x3e00 OBJ_X 0x01ff OBJ_PLTT_NO 0xf000 OBJ_PRIORITY_1 0x0000 OBJ_PRIORITY_2 0x0400 OBJ_PRIORITY_3 0x0800 OBJ_PRIORITY_4 0x0c00 OBJ_CHAR_NO 0x03ff void SetOamBuffer(u16*,u32) void DmaOamBuffer() void SetOamBufferRenewal(bool) void SetCursorStatus(csrDefine const*,u8) void SetCursorChar(u16,u16) void DeleteCursor() u16 GetCurosrPosOnBg(u8) void CheckCursorPos(u8*) void CheckCursorPosRange(u8*,u8,u8) void MoveAndAnimeCursor(u8) 10 0 114 stdSub.h keyStatus key void WaitHblank() void WaitPressKey(u8,u16) void SetKeyRapidEnable(bool) void AddRapidKey(u16) void SubRapidKey(u16) void SetKeyRapid(u16,u8,u8,u8) void ReadKeyPlus() void ReadKey() void ChangeTask(u8,void(*)(u8),void(*)()) void ExecuteTask() void CalcAffineValue(s16,s16,u8,affine*) u8 ClearWram(u32,u32,u16) u8 ClearVram(u32,u32,u16) u8 ClearOam(u32,u32,u32) u8 ClearPalette(selObjBg,u16) u8 TrmCharData(selObjBg,u16 const*,u32,u8) u8 TrmPaletteData(selObjBg,u16 const*,u16,u16) void SetInputHexData(inputHexDef const*) u8 InputHexData(u16*) u8 SelectStrings(u16*) void DrawNowSelectString(u8,selStrDef const*) u8 ToggleSwitch(u16*) void DrawNowToggleSwitchChar(u8,toggleSwDef const*) void DrawNowToggleSwitchString(u8,toggleSwDef const*) u8 ClearNowAllSetting(u16*) void InitSetFunc(u8,setFuncTable const*) void DrawNowAllSetting(u16,setFuncTable const*) 27 1 131 Sound (/blib_sample/sound)This folder contains File Name Extension Description SoundDat .o   Soundfiles N/A   brassc3 .o   cutgtg3 .o   m4aLib .h, .o   mutetpc4 .o   revcym .o   sawg3 .o   sinec3 .o   synbsc2 .o   wario .o   Code Files m4aLib.h _M4A_LIB_VER 105 CGB1_P12 ((WaveData *)0) CGB1_P25 ((WaveData *)1) CGB1_P50 ((WaveData *)2) CGB1_P75 ((WaveData *)3) CGB2_P12 CGB1_P12 CGB2_P25 CGB1_P25 CGB2_P50 CGB1_P50 CGB2_P75 CGB1_P75 CGB4_C15 ((WaveData *)0) CGB4_C07 ((WaveData *)1) u8 const[] __sound_mode_i sound_mode_i ((u32)__sound_mode_i) u8 const[] __total_mplay_n total_mplay_n ((u16)__total_mplay_n) u8 const[] __total_song_n total_song_n ((u16)__total_song_n) SoundArea m4a_sound MPlayTable const[] mplay_table SongTable const[] song_table u8[] m4a_memacc_area void m4aSoundInit() m4aSoundMode() SoundMode_rev01(P1) void SoundMode_rev01(u32) void m4aSoundMain() m4aSoundVSync() SoundVSync_rev01() void SoundVSync_rev01() m4aSoundVSyncOff() SoundVSyncOff_rev01() void SoundVSyncOff_rev01() m4aSoundVSyncOn() SoundVSyncOn_rev01() void SoundVSyncOn_rev01() m4aMPlayStart() MPlayStart_rev01(P1,P2) void MPlayStart_rev01(MusicPlayerArea*,SongHeader*) void m4aSongNumStart(u16) void m4aSongNumStartOrChange(u16) void m4aSongNumStartOrContinue(u16) void m4aMPlayImmInit(MusicPlayerArea*) m4aMPlayStop() MPlayStop_rev01(P1) void MPlayStop_rev01(MusicPlayerArea*) void m4aSongNumStop(u16) void m4aMPlayAllStop() void m4aMPlayContinue(MusicPlayerArea*) void m4aSongNumContinue(u16) void m4aMPlayAllContinue() void m4aMPlayFadeOut(MusicPlayerArea*,u16) m4aMPlayTempoControl() MPlayTempoControl(P1,P2) void MPlayTempoControl(MusicPlayerArea*,u16) m4aMPlayVolumeControl() MPlayVolumeControl(P1,P2,P3) void MPlayVolumeControl(MusicPlayerArea*,u16,u16) m4aMPlayPitchControl() MPlayPitchControl(P1,P2,P3) void MPlayPitchControl(MusicPlayerArea*,u16,s16) m4aMPlayPampotControl() MPlayPanpotControl(P1,P2,P3) m4aMPlayPanpotControl() MPlayPanpotControl(P1,P2,P3) void MPlayPanpotControl(MusicPlayerArea*,u16,s8) m4aMPlayModDepthSet() MPlayModDepthSet(P1,P2,P3) void MPlayModDepthSet(MusicPlayerArea*,u16,u8) m4aMPlayLFOSpeedSet() MPlayLFOSpeedSet(P1,P2,P3) void MPlayLFOSpeedSet(MusicPlayerArea*,u16,u8) MusicPlayerArea m4a_mplay000 MusicPlayerArea m4a_mplay001 MusicPlayerArea m4a_mplay002 MusicPlayerArea m4a_mplay003 SongHeader wario 24 12 134 Font_sample (/font_sample)This folder contains File Name Extension Description Gasdepend N/A Lists dependencies to tell the GNU Assembler (GAS) when to re-assemble files Ld937728 .dat, .o   Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) agb_c2s .bat Windows Batch file for running crt0 .o, .s Implements the start function and bootstraps the program, all games need this as it sets up the interrupts and jumps to the main function crt0_arm .s Assembly source file containing data .c, .h, .o   font_sample .bin, .elf, .map   gdbrc N/A Configuration for the GNU debugger for debugging the game main .c, .o   readme .txt   rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs rom_header_arm .s Assembly source file containing Code Files data.c u16 const[640] BgScData_Sample u16 const[16][16] PlttData_Sample 0 2 57 main.c u16 Cont u16 Trg u32[512] IntrMainBuf u16[1024] BgBak OamData[128] OamBak IntrFuncp const[13] IntrTable void AgbMain() void VBlankIntr() void IntrDummy() void KeyRead() void FontSpread(u32,u32) void FontDisplay() 6 6 188 Lcfont (/font_sample/lcfont)This folder contains File Name Extension Description LCFONT4 .ini   LCFont4 .exe   LD937707 .DAT   LD937714 .DAT   LD937721 .DAT   LD937728 .DAT   LD937735 .DAT   LD937742 .DAT   LD937749 .DAT   LD937756 .DAT   man .zip   readme .txt   readme_eng .txt   Functional_sample (/functional_sample)This folder contains File Name Extension Description Gasdepend N/A Lists dependencies to tell the GNU Assembler (GAS) when to re-assemble files Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) crt0 .o, .s Implements the start function and bootstraps the program, all games need this as it sets up the interrupts and jumps to the main function crt0_arm .s Assembly source file containing fncsample .bin, .elf, .map   gdbrc N/A Configuration for the GNU debugger for debugging the game libalphasm .a Static Library archive of libbg_rsm .a Static Library archive of libbmpmode .a Static Library archive of libcoleffsm .a Static Library archive of libfontprn .a Static Library archive of libobj_rsm .a Static Library archive of libswinsm .a Static Library archive of main .c, .o   menu .c, .h, .o   menuitem .c, .h, .o   rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs rom_header_arm .s Assembly source file containing share .c, .h, .o   Code Files main.c void AgbMain() 1 0 56 menu.c int menu_cursor_pos int menu_prev_cursor_pos int menu_old_cursor_pos int menu_page int menu_prev_page void MenuInit() int Menu() void menu_v_sync_fnc() int menu_exit() int menu_init_param() int menu_to_prev_page() int menu_to_next_page() int menu_to_prev_item() int menu_to_next_item() int menu_control() int menu_strlen(char const*) void menu_print_expl() void menu_print_title() void menu_print() 14 5 351 menuitem.c MenuItem const[] mitem 0 1 81 share.c s16 const[320] sin_cos_table void ClearRamAll() void ClearWorkRam() void ClearGraphicRam() void ClearVram() void ClearOamRam() void ClearPaletteRam() s16 fix_mul(s16,s16) s16 fix_div(s16,s16) s16 fix_inverse(s16) vu16 IntrCheck IntrFuncp v_blank_fnc u32[512] IntrMainBuf IntrFuncp const[14] IntrTable void InitVBlank() void SetVBlankFunc(IntrFuncp) void VBlankFunc() void dummy() void V_Intr_Clear() void V_Intr_Set() void V_Wait() vu16 Cont vu16 Trg void KeyInit() void KeyRead() 18 7 278 Alphasm (/functional_sample/alphasm)This folder contains File Name Extension Description Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) alexpl .c, .o   alpha .c, .o   alpha_data .c, .o   ap_PS_hey5 .bmp, .c, .o   ap_bg0 .bmp, .c, .o   ap_bg1 .bmp, .c, .o   ap_bg2 .bmp, .c, .o   Code Files alexpl.c char const* ap_title_str char const* ap_expl_str0 char const**[] ap_expl_str_array 0 3 30 alpha.c char*[4] ap_eff_tbl u16[1024] ap_BgBak OamData[128] ap_OamBak s16 ap_eff_type s16 ap_obj_alpha s16 ap_eva s16 ap_evb void apMain() void ap_v_blank_intr() void ap_ObjMove() void ap_moji_pr(s16,s16,char*) void ap_suji_pr(s16,s16,s32,s16) 5 7 265 alpha_data.c u32 const[1][2] ap_OamData_Sample u32[296] ap_moji_Character 0 2 87 Background RSM (/functional_sample/bg_rsm)This folder contains File Name Extension Description Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) ball .BMP, .c, .o   bg_map .BMP, .c, .o   bg_map_map .c, .o   bgexpl .c, .o   bgmain .c, .o   cl0 .bmp, .c, .o   Code Files bg_map_map.c u16 const[1024] map_data_front u16 const[1024] map_data_back 0 2 74 bgexpl.c char const* bg_title_str char const* bg_expl_str0 char const**[] bg_expl_str_array 0 3 34 bgmain.c vu32[4][2] bg_oam_buffer vu16 bg_ball_anim_count vu16 bg_ball_anim_count_change_mode s16 bg_pos_x s16 bg_pos_y vu16 bg_screen_back_x u16 bg_mosaic u16 bg_scale_x u16 bg_scale_y u16 bg_rotate s16 bg_pa s16 bg_pb s16 bg_pc s16 bg_pd s32 bg_start_x s32 bg_start_y void bgMain() void bg_v_blank_intr() void bg_init_param() void bg_init_oam() int bg_key_control() void bg_create_data() void bg_increment_anim_count() void bg_exit_clear_register() 8 16 385 BMP mode (/functional_sample/bmpmode)This folder contains File Name Extension Description Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) bitmap .c, .o   bmexpl .c, .o   img24bit .bmp, .c, .o   img24bit2 .bmp, .c, .o   umiB .bmp, .c, .o   Code Files bitmap.c u8 bm_Bgmode u32 Zoom s32 start_x s32 start_y u16 bg2pa u16 bg2pb u16 bg2pc u16 bg2pd vs32 bg2_center_x vs32 bg2_center_y vu16 rotate_value void bm_Main() void bm_v_blank_inter() void bm_init() int bm_key() void bm_mode_change(u8) void bm_rotate(s32) void bm_Bgmode3_Test() void bm_Bgmode4_Test() void bm_Bgmode5_Test() 9 11 202 bmexpl.c char const* bm_title_str char const* bm_expl_str0 char const**[] bm_expl_str_array 0 3 35 Coleffsm (/functional_sample/coleffsm)This folder contains File Name Extension Description Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) ReadMe .txt   c_effect .c, .o   ce_PS_hey5 .bmp, .c, .o   ce_bg1 .bmp, .c, .o   ce_bg3 .bmp, .c, .o   ce_dat .h Include file for declaring ce_data .c, .o   ceexpl .c, .o   col .ACT   Code Files c_effect.c OamData[128] ce_OamBak s16 ce_EVY_rate s16 ce_eff_type s16 ce_EVA_rate s16 ce_EVB_rate u16[1024] ce_BgBak s16 ce_obj_mode void ceMain() void ce_v_blank_intr() void ce_ObjMove() void ce_suji_pr(s16,s16,s32,s16) void ce_moji_pr(s16,s16,char*) 5 7 289 ce_dat.h int const[1][2] ce_OamData_Sample char*[] ce_type_tbl int const[256] ce_bg1_Palette int const[3584] ce_bg1_Character int const[640] ce_bg1_Map int const[9152] ce_bg3_Character int const[640] ce_bg3_Map int const[256] ce_PS_hey5_Palette int const[2048] ce_PS_hey5_Char int[296] ce_moji_Character 0 10 22 ce_data.c u32 const[1][2] ce_OamData_Sample char*[4] ce_type_tbl u32[296] ce_moji_Character 0 3 102 ceexpl.c char const* ce_title_str char const* ce_expl_str0 char const**[] ce_expl_str_array 0 3 33 Font prn (/functional_sample/fontprn)This folder contains File Name Extension Description Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) font8 .h Include file for declaring fontprn .c, .h, .o   Code Files font8.h int[15][1792] font8 0 1 6858 fontprn.c u32 const[1][2] fontOamData fpData fpdata void FontPrintInit(u8,u8,u8,u8,u32,u8) void FontPalletLoad(u8) void FontColor(u8) void FontPrint(u8,u8,u8*) void NumPrint(u8,u8,s16,s16) void put_font_1d(u8,u8,u8*,u16) void put_font_2d(u8,u8,u8*,u16) void FontPrintC(u8,u8,u8,u8*) void NumPrintC(u8,u8,u8,s16,s16) void FontPrintCls() void FontPrintSync() char* fp_itoa(int,char*,int) char* _toa(unsigned int,char*,int) int _power(int,int) 14 2 503 Obj_rsm (/functional_sample/obj_rsm)This folder contains File Name Extension Description Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) hey2 .bmp, .c, .o   obexpl .c, .o   obmain .c, .o   Code Files obexpl.c char const* ob_title_str char const* ob_expl_str0 char const**[] ob_expl_str_array 0 3 35 obmain.c s16 ob_pos_x s16 ob_pos_y u16 ob_affine u16 ob_mosaic u16 ob_scale_x u16 ob_scale_y u16 ob_rotate u16[16] ob_oam_buffer void obMain() void ob_v_blank_intr() void ob_init_param() void ob_init_oam() int ob_key_control() void ob_create_oam() 6 8 272 Swinsm (/functional_sample/swinsm)This folder contains File Name Extension Description Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) ReadMe .txt   sw_PS_hey5 .bmp, .c, .o   sw_bg0 .bmp, .c, .o   sw_bg1 .bmp, .c, .o   sw_bg2 .bmp, .c, .o   sw_bg3 .bmp, .c, .o   sw_dat .h Include file for declaring swexpl .c, .o   window .c, .o   Code Files sw_dat.h u16 const[256] sw_PS_hey5_Palette u8 const[2048] sw_PS_hey5_Char u16 const[10] sw_bg0_Palette u8 const[1120] sw_bg0_Character u16 const[640] sw_bg0_Map u8 const[384] sw_bg1_Character u16 const[640] sw_bg1_Map u8 const[384] sw_bg2_Character u16 const[640] sw_bg2_Map u8 const[384] sw_bg3_Character u16 const[640] sw_bg3_Map 0 11 23 swexpl.c char const* sw_title_str char const* sw_expl_str0 char const**[] sw_expl_str_array 0 3 28 window.c u32 const[1][2] sw_OamData_Sample OamData[128] sw_OamBak void swMain() void sw_v_blank_intr() void sw_ObjMove() 3 2 149 Infrared sample (/ir_sample)This folder contains File Name Extension Description Explanation .txt   Gasdepend N/A Lists dependencies to tell the GNU Assembler (GAS) when to re-assemble files Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) crt0 .o, .s Implements the start function and bootstraps the program, all games need this as it sets up the interrupts and jumps to the main function crt0_arm .s Assembly source file containing data .c, .h, .o   ir_sample .bin, .elf, .h, .map   main .c, .o   rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs rom_header_arm .s Assembly source file containing utility .c, .h, .o   Code Files data.c u16 const[640] BgScData_Sample u32 const[1][2] OamData_Sample u16 const[16][16] PlttData_Sample u32 const[1792] CharData_Sample 0 4 514 utility.c u8 const[16] hexdata void DispCharSet8(OamData*,vu8*) void CharSet8BG(vu8*,vu8*) 2 1 40 Multi Boot (/multi_boot)This folder contains File Name Extension Description Gasdepend N/A Lists dependencies to tell the GNU Assembler (GAS) when to re-assemble files GasdependClient N/A   GasdependDemo N/A   Makefile N/A Used to build the source code in the folder (run make) MakefileClient N/A   MakefileDemo N/A   MultiBoot .c, .h, .o, .txt   MultiSio .c, .h, .o   MultiSioAsm .o, .s   MultiSioAsmArm .s Assembly source file containing MultiSioDefine .s Assembly source file containing MultiSioDefineArm .s Assembly source file containing agb_c2s .bat Windows Batch file for running client .bin, .elf, .map, .o   crt0 .o, .s Implements the start function and bootstraps the program, all games need this as it sets up the interrupts and jumps to the main function crt0_arm .s Assembly source file containing crt0_demo .o, .s   crt0_demo_arm .s Assembly source file containing crt0_multi_boot .o, .s   crt0_multi_boot_arm .s Assembly source file containing data .c, .h, .o   demo .bin, .dep, .elf, .map   demo_LZ .bin, .o   demo_main .c, .o   gdbrc N/A Configuration for the GNU debugger for debugging the game main .c, .o   multi_boot .bin, .dep, .elf, .map   multi_sio_asm .o   rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs rom_header_arm .s Assembly source file containing types .h Include file for declaring Code Files MultiBoot.c u16[3] MultiBoot_required_data void MultiBootInit(MultiBootParam*) int MultiBootMain(MultiBootParam*) int MultiBootSend(MultiBootParam*,u16) void MultiBootStartProbe(MultiBootParam*) void MultiBootStartMaster(MultiBootParam*,u8*,int,u8,s8) int MultiBootCheckComplete(MultiBootParam*) int MultiBootHandShake(MultiBootParam*) void MultiBootWaitCycles(u32) void MultiBootWaitSendDone() 9 1 653 MultiSio.c MultiSioArea Ms u32[16] RecvFuncBuf u32[72] IntrFuncBuf u8 const[15] MultiSioLib_Var void MultiSioInit() void MultiSioStart() void MultiSioStop() u32 MultiSioMain(void*,void*) void MultiSioSendDataSet(void*) u32 MultiSioRecvDataCheck(void*) 6 4 291 data.c u16 const[640] BgScData_Sample u32 const[4][2] OamData_Sample u16 const[16][16] PlttData_Sample u32 const[1792] CharData_Sample 0 4 536 demo_main.c u16 Cont u16 Trg u32[256] IntrMainBuf u16[1024] BgBak OamData[128] OamBak u16[4][2] HPos u16[4][2] VPos u16[8] UsrSendBuf u16[4][8] UsrRecvBuf u32 SioFlags u32 SioFlagsBak u8 SioStartFlag IntrFuncp const[13] IntrTable IntrFuncp[14] IntrTableBuf void DemoMain() void VBlankIntr() void IntrDummy() void KeyRead() void BgScSet(u8*,u16*,u8) 5 14 229 main.c MultiBootParam multiboot_status u8* demo_bin_start u32 demo_bin_length int frame_retval u8 const* const[] BgScDatap_ID void AgbMain() 1 5 148 Multi boot sync (/multi_boot_sync)This folder contains File Name Extension Description Gasdepend N/A Lists dependencies to tell the GNU Assembler (GAS) when to re-assemble files GasdependClient N/A   GasdependDemo N/A   Makefile N/A Used to build the source code in the folder (run make) MakefileClient N/A   MakefileDemo N/A   MultiBoot .c, .h, .o, .txt   MultiSio .c, .h, .o   MultiSioAsm .o, .s   MultiSioAsmArm .s Assembly source file containing MultiSioDefine .s Assembly source file containing MultiSioDefineArm .s Assembly source file containing agb_c2s .bat Windows Batch file for running client .bin, .elf, .map, .o   crt0 .o, .s Implements the start function and bootstraps the program, all games need this as it sets up the interrupts and jumps to the main function crt0_arm .s Assembly source file containing crt0_demo .o, .s   crt0_demo_arm .s Assembly source file containing crt0_multi_boot .o, .s   crt0_multi_boot_arm .s Assembly source file containing data .c, .h, .o   demo .bin, .dep, .elf, .map   demo_LZ .bin, .o   demo_main .c, .o   gdbrc N/A Configuration for the GNU debugger for debugging the game main .c, .o   multi_boot .bin, .dep, .elf, .map   multi_sio_asm .o   rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs rom_header_arm .s Assembly source file containing types .h Include file for declaring Code Files MultiBoot.c u16[3] MultiBoot_required_data void MultiBootInit(MultiBootParam*) int MultiBootMain(MultiBootParam*) int MultiBootSend(MultiBootParam*,u16) void MultiBootStartProbe(MultiBootParam*) void MultiBootStartMaster(MultiBootParam*,u8*,int,u8,s8) int MultiBootCheckComplete(MultiBootParam*) int MultiBootHandShake(MultiBootParam*) void MultiBootWaitCycles(u32) void MultiBootWaitSendDone() 9 1 653 MultiSio.c MultiSioArea Ms u32[16] RecvFuncBuf u32[64] IntrFuncBuf u8 const[19] MultiSioLib_Var void MultiSioInit() void MultiSioStart() void MultiSioStop() u32 MultiSioMain(void*,void*) void MultiSioSendDataSet(void*) u32 MultiSioRecvDataCheck(void*) void MultiSioVSync() void MultiSioIntr() 8 4 289 data.c u16 const[640] BgScData_Sample u32 const[4][2] OamData_Sample u16 const[16][16] PlttData_Sample u32 const[1792] CharData_Sample 0 4 536 demo_main.c u16 Cont u16 Trg u32[256] IntrMainBuf u16[1024] BgBak OamData[128] OamBak u16[8] UsrSendBuf u16[4][8] UsrRecvBuf u32 SioFlags u8 SioStartFlag IntrFuncp const[13] IntrTable IntrFuncp[14] IntrTableBuf void DemoMain() void VBlankIntr() void IntrDummy() void KeyRead() void BgScSet(u8*,u16*,u8) 5 11 217 main.c MultiBootParam multiboot_status u8* demo_bin_start u32 demo_bin_length int frame_retval u8 const* const[] BgScDatap_ID void AgbMain() 1 5 154 types.h 0 0 18 Multi sio (/multi_sio)This folder contains File Name Extension Description Gasdepend N/A Lists dependencies to tell the GNU Assembler (GAS) when to re-assemble files Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) MultiSio .c, .h, .o   MultiSioAsm .o, .s   MultiSioAsmArm .s Assembly source file containing MultiSioDefine .s Assembly source file containing MultiSioDefineArm .s Assembly source file containing agb_c2s .bat Windows Batch file for running crt0 .o, .s Implements the start function and bootstraps the program, all games need this as it sets up the interrupts and jumps to the main function crt0_arm .s Assembly source file containing data .c, .h, .o   gdbrc N/A Configuration for the GNU debugger for debugging the game main .c, .o   multi_sio .bin, .elf, .map   rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs rom_header_arm .s Assembly source file containing Code Files MultiSio.c MultiSioArea Ms u32[16] RecvFuncBuf u32[72] IntrFuncBuf u8 const[15] MultiSioLib_Var void MultiSioInit() void MultiSioStart() void MultiSioStop() u32 MultiSioMain(void*,void*) void MultiSioSendDataSet(void*) u32 MultiSioRecvDataCheck(void*) 6 4 291 data.c u16 const[640] BgScData_Sample u32 const[4][2] OamData_Sample u16 const[16][16] PlttData_Sample u32 const[1792] CharData_Sample 0 4 536 main.c u16 Cont u16 Trg u32[256] IntrMainBuf u16[1024] BgBak OamData[128] OamBak u16[4][2] HPos u16[4][2] VPos u16[8] UsrSendBuf u16[4][8] UsrRecvBuf u32 SioFlags u32 SioFlagsBak u8 SioStartFlag IntrFuncp const[13] IntrTable IntrFuncp[14] IntrTableBuf void AgbMain() void VBlankIntr() void IntrDummy() void KeyRead() void BgScSet(u8*,u16*,u8) 5 14 226 Multi sio sync (/multi_sio_sync)This folder contains File Name Extension Description Gasdepend N/A Lists dependencies to tell the GNU Assembler (GAS) when to re-assemble files Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) MultiSio .c, .h, .o   MultiSioAsm .o, .s   MultiSioAsmArm .s Assembly source file containing MultiSioDefine .s Assembly source file containing MultiSioDefineArm .s Assembly source file containing agb_c2s .bat Windows Batch file for running crt0 .o, .s Implements the start function and bootstraps the program, all games need this as it sets up the interrupts and jumps to the main function crt0_arm .s Assembly source file containing data .c, .h, .o   gdbrc N/A Configuration for the GNU debugger for debugging the game main .c, .o   multi_sio .bin, .elf, .map   rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs rom_header_arm .s Assembly source file containing Code Files MultiSio.c MultiSioArea Ms u32[16] RecvFuncBuf u32[64] IntrFuncBuf u8 const[19] MultiSioLib_Var void MultiSioInit() void MultiSioStart() void MultiSioStop() u32 MultiSioMain(void*,void*) void MultiSioSendDataSet(void*) u32 MultiSioRecvDataCheck(void*) void MultiSioVSync() void MultiSioIntr() 8 4 291 data.c u16 const[640] BgScData_Sample u32 const[4][2] OamData_Sample u16 const[16][16] PlttData_Sample u32 const[1792] CharData_Sample 0 4 536 main.c u16 Cont u16 Trg u32[256] IntrMainBuf u16[1024] BgBak OamData[128] OamBak u16[8] UsrSendBuf u16[4][8] UsrRecvBuf u32 SioFlags u8 SioStartFlag IntrFuncp const[13] IntrTable IntrFuncp[14] IntrTableBuf void AgbMain() void VBlankIntr() void IntrDummy() void KeyRead() void BgScSet(u8*,u16*,u8) 5 11 218 Overlay (/overlay)This folder contains File Name Extension Description Gasdepend N/A Lists dependencies to tell the GNU Assembler (GAS) when to re-assemble files Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) agb_c2s .bat Windows Batch file for running bgmove .c, .o   crt0 .o, .s Implements the start function and bootstraps the program, all games need this as it sets up the interrupts and jumps to the main function crt0_arm .s Assembly source file containing data .c, .h, .o   gdbrc N/A Configuration for the GNU debugger for debugging the game ldscript .x Ld script that tells the Linker where to place data in the resulting ELF main .c, .o   objmove .c, .o   overlay .bin, .elf, .h, .map   rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs rom_header_arm .s Assembly source file containing sub .c, .h, .o   title .c, .o   types .h Include file for declaring Code Files bgmove.c IntrFuncp const[13] BgMoveIntrTable BgOffsetCnt[4] BgMoveOffsetBak u16[4][1024] BgMoveBgBak u8 BgMove() void BgMoveVBlankIntr() void BgSnakeMove() 3 3 118 data.c LinkData const[2] LinkData_Title u16 const[16][16] PlttData_Sample u32 const[1][2] OamData_Sample u16 const[640] BgScData_Title u16 const[640] BgScData_ObjMove u16 const[640] BgScData_BgMove0 u16 const[640] BgScData_BgMove1 u16 const[640] BgScData_BgMove2 u16 const[640] BgScData_BgMove3 u32 const[1792] CharData_Sample 0 10 636 main.c u8 SceneNo u16 Cont u16 Trg IntrFuncp[13] IntrTableBuf u32[512] IntrMainBuf s32[4] DataSecDummy void AgbMain() 1 6 82 objmove.c IntrFuncp const[13] ObjMoveIntrTable OamData[128] ObjMoveOamBak u16[1024] ObjMoveBgBak u8 ObjMove() void ObjMoveVBlankIntr() void ObjSnakeMove() 3 3 119 sub.c void IntrDummy() void KeyRead() void ObjCursolMove(OamData*,LinkData*,u8*) 3 0 76 title.c IntrFuncp const[13] TitleIntrTable u16[1024] TitleBgBak OamData[128] TitleOamBak u8 Cursolp u8 Title() void TitleVBlankIntr() 2 4 82 types.h 0 0 27 Reintr (/reintr)This folder contains File Name Extension Description Gasdepend N/A Lists dependencies to tell the GNU Assembler (GAS) when to re-assemble files Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) agb_c2s .bat Windows Batch file for running crt0 .o, .s Implements the start function and bootstraps the program, all games need this as it sets up the interrupts and jumps to the main function crt0_arm .s Assembly source file containing data .c, .h, .o   gdbrc N/A Configuration for the GNU debugger for debugging the game main .c, .o   reintr .bin, .elf, .map   rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs rom_header_arm .s Assembly source file containing Code Files data.c u16 const[640] BgScData_Sample u32 const[1][2] OamData_Sample u16 const[16][16] PlttData_Sample u32 const[1792] CharData_Sample 0 4 514 main.c u16 Cont u16 Trg u32[512] IntrMainBuf u16[1024] BgBak OamData[128] OamBak IntrFuncp const[13] IntrTable void AgbMain() void VBlankIntr() void KeyRead() void IntrDummy() void ObjSnakeMove() 5 6 179 Simple (/simple)This folder contains File Name Extension Description Gasdepend N/A Lists dependencies to tell the GNU Assembler (GAS) when to re-assemble files Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code in the folder (run make) agb_c2s .bat Windows Batch file for running crt0 .o, .s Implements the start function and bootstraps the program, all games need this as it sets up the interrupts and jumps to the main function crt0_arm .s Assembly source file containing data .c, .h, .o   gdbrc N/A Configuration for the GNU debugger for debugging the game main .c, .o   rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs rom_header_arm .s Assembly source file containing simple .bin, .elf, .map   Code Files data.c u16 const[640] BgScData_Sample u32 const[1][2] OamData_Sample u16 const[16][16] PlttData_Sample u32 const[1792] CharData_Sample 0 4 514 main.c u16 Cont u16 Trg u32[512] IntrMainBuf u16[1024] BgBak OamData[128] OamBak IntrFuncp const[13] IntrTable void AgbMain() void VBlankIntr() void IntrDummy() void KeyRead() void ObjSnakeMove() 5 6 174 Sio32 multi-load (/sio32_multi_load)This folder contains File Name Extension Description Gasdepend N/A Lists dependencies to tell the GNU Assembler (GAS) when to re-assemble files GasdependClient N/A   GasdependDemo N/A   GasdependLoader N/A   Makefile N/A Used to build the source code in the folder (run make) MakefileClient N/A   MakefileDemo N/A   MakefileLoader N/A   MultiBoot .c, .h, .o, .txt   MultiSio .c, .h, .o   MultiSioAsm .o, .s   MultiSioAsmArm .s Assembly source file containing MultiSioDefine .s Assembly source file containing MultiSioDefineArm .s Assembly source file containing Sio32MultiLoad .c, .h, .o   agb_c2s .bat Windows Batch file for running bss .c, .h, .o   client .bin, .elf, .map, .o   crt0 .o, .s Implements the start function and bootstraps the program, all games need this as it sets up the interrupts and jumps to the main function crt0_arm .s Assembly source file containing crt0_demo .o, .s   crt0_demo_arm .s Assembly source file containing crt0_loader .o, .s   crt0_loader_arm .s Assembly source file containing crt0_multi_boot .o, .s   crt0_multi_boot_arm .s Assembly source file containing data .c, .h, .o   demo .bin, .dep, .elf, .map, .o   demo_main .c, .o   gdbrc N/A Configuration for the GNU debugger for debugging the game intr_main .o, .s   intr_main_arm .s Assembly source file containing intr_table .c, .h, .o   load_table_dest .c, .o   load_table_src .c, .o   loader .bin, .dep, .elf, .map   loader_LZ .bin, .o   loader_main .c, .o   main .c, .o   rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs rom_header_arm .s Assembly source file containing sio32_multi_load .bin, .dep, .elf, .h, .map   sub .c, .h, .o   types .h Include file for declaring Code Files MultiBoot.c u16[3] MultiBoot_required_data void MultiBootInit(MultiBootParam*) int MultiBootMain(MultiBootParam*) int MultiBootSend(MultiBootParam*,u16) void MultiBootStartProbe(MultiBootParam*) void MultiBootStartMaster(MultiBootParam*,u8*,int,u8,s8) int MultiBootCheckComplete(MultiBootParam*) int MultiBootHandShake(MultiBootParam*) void MultiBootWaitCycles(u32) void MultiBootWaitSendDone() 9 1 653 MultiSio.c MultiSioArea Ms u32[16] RecvFuncBuf u32[72] IntrFuncBuf u8 const[25] MultiSioLib_Var void MultiSioInit(u32) void MultiSioStart() void MultiSioStop() u32 MultiSioMain(void*,void*,u32) void MultiSioSendDataSet(void*,u32) u32 MultiSioRecvDataCheck(void*) 6 4 316 Sio32MultiLoad.c Sio32MultiLoadArea S32ml u8 const[21] MultiSioLib_Var void Sio32MultiLoadInit(u32,void*) u32 Sio32MultiLoadMain(u32*) void Sio32MultiLoadIntr() 3 2 213 bss.c u16 Cont u16 Trg u32[256] IntrMainBuf u16[1024] BgBak OamData[128] OamBak u16[8] UsrSendBuf u16[4][8] UsrRecvBuf u32 SioFlags u32 SioFlagsBak u8 SioStartFlag 0 10 29 data.c u16 const[640] BgScData_Sample u32 const[4][2] OamData_Sample u16 const[16][16] PlttData_Sample u32 const[1792] CharData_Sample 0 4 536 demo_main.c u16[4][2] HPos u16[4][2] VPos void DemoMain() 1 2 135 intr_table.c IntrFuncp[13] IntrTableBuf IntrFuncp const[13] IntrTable 0 2 32 load_table_dest.c u8 const* const[4] LoadTable 0 1 19 load_table_src.c u8 const* const[4] LoadTable 0 1 20 loader_main.c u8* LoadCounterp u8 RecvLoadCounter u8 BurstLoad u32 ProgressCounter void LoaderMain() 1 4 190 main.c MultiBootParam multiboot_status u8* demo_bin_start u32 demo_bin_length int frame_retval u8 const* const[] BgScDatap_ID void AgbMain() 1 5 134 sub.c void VBlankIntr() void IntrDummy() void KeyRead() void BgScSet(u8*,u16*,u8) void Data2BgSc(u32,u16*,u8,u8) 5 0 77 Sio32_multi_load_sync (/sio32_multi_load_sync)This folder contains File Name Extension Description Gasdepend N/A Lists dependencies to tell the GNU Assembler (GAS) when to re-assemble files GasdependClient N/A   GasdependDemo N/A   GasdependLoader N/A   Makefile N/A Used to build the source code in the folder (run make) MakefileClient N/A   MakefileDemo N/A   MakefileLoader N/A   MultiBoot .c, .h, .o, .txt   MultiSio .c, .h, .o   MultiSioAsm .o, .s   MultiSioAsmArm .s Assembly source file containing MultiSioDefine .s Assembly source file containing MultiSioDefineArm .s Assembly source file containing Sio32MultiLoad .c, .h, .o   agb_c2s .bat Windows Batch file for running bss .c, .h, .o   client .bin, .elf, .map, .o   crt0 .o, .s Implements the start function and bootstraps the program, all games need this as it sets up the interrupts and jumps to the main function crt0_arm .s Assembly source file containing crt0_demo .o, .s   crt0_demo_arm .s Assembly source file containing crt0_loader .o, .s   crt0_loader_arm .s Assembly source file containing crt0_multi_boot .o, .s   crt0_multi_boot_arm .s Assembly source file containing data .c, .h, .o   demo .bin, .dep, .elf, .map, .o   demo_main .c, .o   gdbrc N/A Configuration for the GNU debugger for debugging the game intr_main .o, .s   intr_main_arm .s Assembly source file containing intr_table .c, .h, .o   load_table_dest .c, .o   load_table_src .c, .o   loader .bin, .dep, .elf, .map   loader_LZ .bin, .o   loader_main .c, .o   main .c, .o   rom_header .s Assembly code that implements the common GBA ROM reader required of all GBA ROMs rom_header_arm .s Assembly source file containing sio32_multi_load .bin, .dep, .elf, .h, .map   sub .c, .h, .o   types .h Include file for declaring Code Files MultiBoot.c u16[3] MultiBoot_required_data void MultiBootInit(MultiBootParam*) int MultiBootMain(MultiBootParam*) int MultiBootSend(MultiBootParam*,u16) void MultiBootStartProbe(MultiBootParam*) void MultiBootStartMaster(MultiBootParam*,u8*,int,u8,s8) int MultiBootCheckComplete(MultiBootParam*) int MultiBootHandShake(MultiBootParam*) void MultiBootWaitCycles(u32) void MultiBootWaitSendDone() 9 1 653 MultiSio.c MultiSioArea Ms u32[16] RecvFuncBuf u32[64] IntrFuncBuf u8 const[29] MultiSioLib_Var void MultiSioInit(u32) void MultiSioStart() void MultiSioStop() u32 MultiSioMain(void*,void*,u32) void MultiSioSendDataSet(void*,u32) u32 MultiSioRecvDataCheck(void*) void MultiSioVSync() void MultiSioIntr() 8 4 317 Sio32MultiLoad.c Sio32MultiLoadArea S32ml u8 const[21] MultiSioLib_Var void Sio32MultiLoadInit(u32,void*) u32 Sio32MultiLoadMain(u32*) void Sio32MultiLoadIntr() 3 2 215 bss.c u16 Cont u16 Trg u32[256] IntrMainBuf u16[1024] BgBak OamData[128] OamBak u16[8] UsrSendBuf u16[4][8] UsrRecvBuf u32 SioState u32 SioFlags u32 SioFlagsBak u8 SioStartFlag 0 11 30 data.c u16 const[640] BgScData_Sample u32 const[4][2] OamData_Sample u16 const[16][16] PlttData_Sample u32 const[1792] CharData_Sample 0 4 536 demo_main.c void DemoMain() 1 0 112 intr_table.c IntrFuncp[13] IntrTableBuf IntrFuncp const[13] IntrTable 0 2 32 load_table_dest.c u8 const* const[4] LoadTable 0 1 19 load_table_src.c u8 const* const[4] LoadTable 0 1 20 loader_main.c u8* LoadCounterp u8 RecvLoadCounter u8 BurstLoad u32 ProgressCounter void LoaderMain() 1 4 192 main.c MultiBootParam multiboot_status u8* demo_bin_start u32 demo_bin_length int frame_retval u8 const* const[] BgScDatap_ID void AgbMain() 1 5 136 sub.c void VBlankIntr() void IntrDummy() void KeyRead() void BgScSet(u8*,u16*,u8) void Data2BgSc(u32,u16*,u8,u8) 5 0 88 ", "excerpt": "Blib sample (/blib_sample) This folder contains File Name Extension Description DacsTest .c, .o   Data .c, .o   EepromTest .c, .o   FlashTest .c, .o   Main .c, .h, .o   Makedepend N/A Lists dependencies to tell Make when to re-compile files Makefile N/A Used to build the source code...", "tags": ["gba","sdk"], "image": "/public/generated/placeholders/game-boy-advance-sdk-samples.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game Boy Advance Tool Source Code", "url": "/game-boy-advance-tool-source-code", "content": "IntroductionIn the Game Boy Advance SDK Version 3.0 the source code for a variety of tools are available to learn from and modify. These tools all have a command line interface (CLI) and are targeted for the Windows Operating System. They even come with Visual C++ 5.0 project files to make it really easy to build and extend, if you can still find a working version of VC++ 5.0 for your PC.What tools have source code available?The GBA development tools with source code available are: Tool Name Description act2agb Converts an Adobe Photoshop .ACT (Adobe Color Table) file to a GBA Palette in C source code form agbparts Converts a bitmap image into 8x8 pixel parts useful for an optimized tileset or even sprites bin2h generates a C header file from the Binary result of objcopy bmp2agb Converts BMP images to either binary or text with optional compression bmp2bin Converts BMP files to binary formats .imb (Image Binary) and .plb (Palette Binary) bmp2map Converts BMP files to C-source code based on 8x8 pixel tiles bmpgrid Splits up a Bitmap into tiles/partitions based on input width/height (minimum 8x8) bmpred Reduces the colors of a BMP image using a specified palette sgi2bmp Converts an SGI format image into a BMP format image What other information is included?Along with a directory for each of the tools mentioned above, there are also a few files and directories that provide further information: doc - Three text documents that provide information about the tools etc - Empty folder include - Contains the C-header files for the common tool library (libmagbx) lib - contains the pre-build library libmagbx.lib libsrc - contains the source code for libmagbx readme.txt - brief notes on how to setup Visual C++ to build the toolsWhat is libMagbX?It seems to be a library containing common functionality used across multiple development tools for GBA development, as most of the tools operate on images there is common code to read and write image formats.Why is the library called libmagbX?So the first 3 letters lib is a common prefix for statically compiled libraries, the next letter M is unknown but it could be short for iMage since this library mainly handles image conversions. The next 3 letters AGB stands for Advanced Game Boy but the last letter X is unknown.Tool Source CodeEach individual tool has its own source code folder, however the interesting logic is all in the common library known as libmagbX, all the folders contain are Visual C++ project files and a main.cpp file that calls the functionality from the common library.Common files in each tool folderSince each tool has its own Visual C++ project, there are a few common files that you will see across the codebase: *.dsp - Microsoft Developer Studio Project File *.dsw - Microsoft Developer Studio Workspace File *.ncb - Non-compiled Browse file - contains debug symbols used by Intellisense *.plg - Most recent Project Build Log in HTML format *.rc - Resource Script - contains information embedded in the tool executableact2agbThis folder contains contains the source code for the tool that converts Adobe Photoshop Palette files into GBA compatible palette files.There is not much of interest here as all the main.cpp source file itself does is: Usage Information printing to Command Line Parsing of command line arguments Calling of Palette.LoadACT from the libmagbX library writing out the result to a C source fileSo the actual processing of the ACT file format and the conversion to GBA format is all in the Palette class of the libmagbX library. File Name Extension Description act2agb .dsp, .dsw, .ncb, .opt, .plg, .rc see common files section for description of the files main .cpp Just contains main function that shows the usage information, parses the arguments and calls the library functions resource .h Include file for declaring the default macros from Visual C++ 5.0 (Nothing added by Nintendo) Agbparts (agbparts)This folder contains File Name Extension Description agbparts .dsp, .dsw, .ncb, .opt, .plg, .rc see common files section for description of the files main .cpp   resource .h Include file for declaring the default macros from Visual C++ 5.0 (Nothing added by Nintendo) Bin2h (bin2h)This folder contains File Name Extension Description bin2h .dsp, .dsw, .ncb, .opt, .plg, .rc see common files section for description of the files main .cpp   resource .h Include file for declaring the default macros from Visual C++ 5.0 (Nothing added by Nintendo) BMP to bin (bmp2bin)This folder contains the source code to bmp2bin which is a simple tool that converts a single BMP image into a binary .IMB file that can be included inside a GBA ROM. File Name Extension Description bmp2bin .aps, .dsp, .dsw, .ncb, .opt, .plg, .rc see common files section for description of the files main .cpp   resource .h Include file for declaring the default macros from Visual C++ 5.0 (Nothing added by Nintendo) BMP to map (bmp2map)This folder contains the source code for bmp2map which converts a BMP image into a C Source code file that can be compiled into a GBA ROM. It splits the single BMP image into 8x8 tiles that can be drawn using GBA functions. File Name Extension Description bmp2map .dsp, .dsw, .ncb, .opt, .plg, .rc see common files section for description of the files main .cpp   resource .h Include file for declaring the default macros from Visual C++ 5.0 (Nothing added by Nintendo) Split BMP into grid of images (bmpgrid)This folder contains the source code for bmpgrid a command line tool that converts a single BMP into multiple images based on the width and height of a tile. File Name Extension Description BmpGrid .dsp, .dsw, .ncb, .opt, .plg, .rc see common files section for description of the files main .cpp   resource .h Include file for declaring the default macros from Visual C++ 5.0 (Nothing added by Nintendo) Bmp color reducer (bmpred)This folder contains the source code for a Command Line tool known as bmpred that reduces the number of unique colors inside a BMP image, useful for getting the BMP into a good state to display on the GBA. File Name Extension Description bmpred .dsp, .dsw, .ncb, .opt, .plg see common files section for description of the files colorspace .cpp, .h   main .cpp   reduction .cpp   res .rc   resource .h Include file for declaring the default macros from Visual C++ 5.0 (Nothing added by Nintendo) Code Files colorspace.cpp u32 GetNearestPalette(const Palette&_Pal,const Color&_C,u16 offset) 1 0 294 main.cpp Picture CreateReductionPicture(const HPicture&_Hpic,const Palette&_Pal,u16 offset) void usage() __USING__MAGBX 2 1 397 reduction.cpp __USING__MAGBX u32 GetNearestPalette(const Palette&_Pal,const Color&_C,u16 offset) Picture CreateReductionPicture(const HPicture&_Hpic,const Palette&_Pal,u16 offset) 2 0 86 SGI to BMP converter (sgi2bmp)This folder contains the source code for a tool that converts images from the SGI Image format to a standard BMP image format. This tool can be quite useful for any GBA or N64 development that was done on SGI machines which used the SGI image format. File Name Extension Description GlobalFnc .cpp, .h   RgbLoader .cpp, .h   main .cpp   pic_create .cpp, .h   resource .h Include file for declaring the default macros from Visual C++ 5.0 (Nothing added by Nintendo) sgi2bmp .dsp, .dsw, .ncb, .opt, .plg, .rc see common files section for description of the files Code Files GlobalFnc.cpp void setByte(u8,u8**) void setWord(u16,u8**) void setDword(u32,u8**) void getByte(u8*,u8**) void getChar(char*,u8**) void getWord(u16*,u8**) void getShort(short*,u8**) void getDword(u32*,u8**) void getLong(long*,u8**) 9 0 82 RgbLoader.cpp DELIVER sgiCreateDeliver(unsigned long width,unsigned long height) bool LoadHeader(IMAGEHEADER *pimh,MCFile *pfile) BOOL sgiCreateImage(DELIVER *pdlv,IMAGEHEADER *pimh,unsigned char *pSrc) BOOL WINAPI tvIsExtension(const char *pchExt) DELIVER *WINAPI tvImageToTexture(const char *pchFileName) BOOL sgiCreateImage(DELIVER *pdlv,IMAGEHEADER *pimh,unsigned char *pSrc) DELIVER sgiCreateDeliver(unsigned long width,unsigned long height) bool LoadHeader(IMAGEHEADER *pimh,MCFile *pfile) 8 0 414 main.cpp void usage() 1 0 105 pic_create.cpp __USING__MAGBX bool sgiLoadHeader(IMAGEHEADER&imh,std::ifstream&in) bool sgiCreateImage(HPicture&pic,IMAGEHEADER&imh,unsigned char *pSrc,char flag,short tp,Color&color) HPicture sgiImageLoad(FileName&filename,char flag,short tp,Color&color) static bool sgiCreateImage(HPicture&pic,IMAGEHEADER&imh,unsigned char *pSrc,char flag,short tp,Color&bkcolor) 4 1 335 Documentation (doc)This folder contains three text documents that describe the source code for all the tools, including the shared library and the use of the Standard Template Library (STL)The three text files are as follows: library.txt - prevcl.txt - tools.txt -C Header files for libMagbX (include)This folder contains all the C header files used by each of the tools in order to describe the functionality of the common library. This allows each tool to use common functions from the libMagbX, reducing the need for duplicate code in each tool. File Name Extension Description agbtypes .h Include file for declaring angle .h Include file for declaring bmpstruct .h Include file for declaring buffer .h Include file for declaring char16set .h Include file for declaring char256set .h Include file for declaring character .h Include file for declaring character16 .h Include file for declaring character256 .h Include file for declaring charset .h Include file for declaring color .h Include file for declaring filename .h Include file for declaring hpicture .h Include file for declaring image .h Include file for declaring map .h Include file for declaring map16 .h Include file for declaring map256 .h Include file for declaring mapsrimage .h Include file for declaring maptextimage .h Include file for declaring maptextunit .h Include file for declaring palette .h Include file for declaring pathname .h Include file for declaring picture .h Include file for declaring util .h Include file for declaring Code Files agbtypes.h 0 0 154 angle.h _AGB_ANGLE_PIE (3.14159265359f) double const m_rad2agb double const m_agb2rad 0 2 62 bmpstruct.h BMP_COMP_RGB (0) BMP_COMP_RLE8 (1) BMP_COMP_RLE4 (2) BMP_COMP_BITFIELDS (3) 0 0 60 buffer.h 0 0 81 char16set.h 0 0 49 char256set.h 0 0 50 character.h 0 0 138 character16.h 0 0 40 character256.h 0 0 25 charset.h 0 0 73 color.h bool operator==(Color const&,Color const&) bool operator!=(Color const&,Color const&) 2 0 60 hpicture.h 0 0 108 map.h 0 0 78 map16.h 0 0 52 map256.h 0 0 49 mapsrimage.h 0 0 45 maptextimage.h 0 0 96 maptextunit.h MT_NONE_FLIP (0) MT_H_FLIP (1) MT_V_FLIP (2) MT_HV_FLIP (3) bool operator==(MapTextUnit const&,MapTextUnit const&) bool operator!=(MapTextUnit const&,MapTextUnit const&) bool operator<(MapTextUnit const&,MapTextUnit const&) bool operator>(MapTextUnit const&,MapTextUnit const&) bool operator<=(MapTextUnit const&,MapTextUnit const&) bool operator>=(MapTextUnit const&,MapTextUnit const&) 6 0 57 palette.h 0 0 101 picture.h 0 0 128 util.h void _itoa_c_hex(char val,char *str) inline _Ty Min(const _Ty&_L,const _Ty&_R){ return (_L inline _Ty Max(const _Ty&_L,const _Ty&_R){ return (_L > _R )? _L : _R ; } 3 0 154 Library Source code (libmagbX)This folder contains the actual C++ source code for the libMagbX library that is used by each of the development tools listed at the start of this page. Most of the functionality of this library is Image manipulation. File Name Extension Description angle .cpp   buffer .cpp   char16set .cpp   char256set .cpp   character .cpp   character16 .cpp   charset .cpp   color .cpp   filename .cpp   hpicture .cpp   image .cpp   libsrc .dep, .dsp, .dsw, .ncb, .opt, .plg see common files section for description of the files map .cpp   map16 .cpp   map256 .cpp   mapsrimage .cpp   maptextimage .cpp   maptextunit .cpp   palette .cpp Contains functions to parse Adobe ACT files and convert to GBA format palettes pathname .cpp   picture .cpp   util .cpp   Code Files color.cpp bool operator==(const Color&_L,const Color&_R) bool operator! 1 1 74 filename.cpp FileName operator+(const PathName&_L,const FileName&_R) 1 0 256 image.cpp __USING__MAGBX u8 create_data_array_from_image4b(const Image&image) u8 create_data_array_from_image8b(const Image&image) u16 create_data_array_from_image16b(const Image&image) u32 create_data_array_from_image32b(const Image&image) u32 get_array_count_4b(const Image&image) u32 get_array_count_8b(const Image&image) u32 get_array_count_16b(const Image&image) u32 get_array_count_32b(const Image&image) u8 create_data_array_from_image4b(const Image&image) u8 create_data_array_from_image8b(const Image&image) u16 create_data_array_from_image16b(const Image&image) u32 create_data_array_from_image32b(const Image&image) u32 get_array_count_4b(const Image&image) u32 get_array_count_8b(const Image&image) u32 get_array_count_16b(const Image&image) u32 get_array_count_32b(const Image&image) 16 0 161 maptextunit.cpp bool operator==(const MapTextUnit&_L,const MapTextUnit&_R) bool operator! 1 1 93 util.cpp void _itoa_c_hex(char val,char *str) 1 0 208 ", "excerpt": "Introduction In the Game Boy Advance SDK Version 3.0 the source code for a variety of tools are available to learn from and modify. These tools all have a command line interface (CLI) and are targeted for the Windows Operating System. They even come with Visual C++ 5.0 project files...", "tags": ["gba","sdk"], "image": "/public/generated/placeholders/game-boy-advance-tool-source-code.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo Gamecube (Dolphin) Development Kit Hardware", "url": "/gamecube-development-kit-hardware", "content": "AMC Dolphin Development Hardware (DDH) The earliest Gamecube development hardware available to game developers was known as the Dolphin Development Hardware or simply DDH for short. This system was sold before the other development kits were finalised, allowing game developers to get a head start on Gamecube development 1. It was built by Applied Microsystems Corp (AMC) and just looked like a standard light grey PC tower with dolphin logo on the front and some Gamecube controller ports. The systems seems to have been distributed with software called the gameOptix DVD Development Kit by AMC, presumably this was used to send the game data to the hardware 2. Prototype AMC DDH The Prototype version of the DDH has RJ-11 ports instead of gamecube ports and apparently the system runs at 3/4 the speed of a retail Nintendo Gamecube 3, which isn’t exactly ideal for development but would be fine if just used for debugging non-performance related issues. NPDP Development KitsAccording to leaked Nintendo internal documentation NPDP standard for Nintendo Pseudo Disc Pack 4 which are a suite of development tools that used a cartridge to read/write gamecube games.These cartridges were basically hard disk drives used as game cartridges for developers to write games to them and allowed faster load times than reading from a physical disc.NPDP cartridges (GCT-0300) The cartridge consists of a Toshiba IDE Hard Disk Drive (HDD) along with a PATA connector which slots into one of the NPDP development tools or Flash Writers. NPDP-GDEV - Development Solution The GDEV unit was built using an Orca board, which was the name of the board used for very early prototype Gamecube development 5. It has four standard Gamecube ports on the front, a cartridge slot for NPDP cartridges and DIP switches which control the region (PAL/NTSC-J etc). As the NPDP cartridges could store up to 3 different games there is buttons. to control which game will be inserted, including a small LED panel displaying the number of the current game. It is aimed at programmers directly and allowed standard debugging features such as breakpoints and memory editing. The main benefit of this unit was the built in NPDP-ODEM companion card, this allowed it to connect to a PC with the NPDP-ODEM PCI card and stream game data directly from the PC instead of using the NPDP cartridge. This was much faster for development as there was no need to write a cartridge every single time and updates could be fairly quick. Prototype NPDP-GDEVDeveloper Jeff managed to find an extremely rare prototype NPDP-GDEV which would only have been sent to a select few developers in the early stages of the Gamecube. It did not run at full speed initially, but this unit was upgrades to run at full Gamecube speed later down the line.So heres a bit better quality image of the elusive Nintendo Gamecube GDEV Prototype "Beta Release" With Beta ODEM & Beta USB Adapter Module. If you have any questions, thoughts, or conerns please drop them below.!Thanks and all the best. -Jeff pic.twitter.com/oGPiGzIadZ— Developer Jeff 🕹️ (@OfficialDevJeff) March 26, 2021NPDP-ODEM PCI card - Optical Disk Emulation via PC The Optical Disk Emulator (ODEM) PCI card was used to send game data to the NPDP-GDEV development kit, instead of using a NPDP cartridge, as it was generally easier for developers to connect directly from PC than to write a NPDP cartridge every time they wanted to run the games. NPDP-GBOX - Testing Solution The GBOX was very similar to the GDEV unit but instead of being focussed for programmers it has more of a focus on testing. The main feature it lacks compared to the NPDP-GDEV is the lack of connecting to the Optical Disk Emulator (ODEM) PCI card 6, so it could only test games from the physical NPDP cartridges that had been written using one of the NPDP Writers (NPDP-GW/NPDP-SW). NPDP Reader Console Later on in the Gamecube’s lifespan a much cheaper option for testing NPDP cartridges became available called the NPDP Reader. it was very similar to a retail Gamecube apart from the giant NPDP cartridge reader on the top instead of the optical drive. In fact for you take the NRDP cartridge reader part away from the rest of the console and hook it up to a retail Gamecube and it would work just fine, in fact this is commonly used for dumping NRDP cartridges 7. This mostly replaced the need for a NPDP-GBOX and was much cheaper due to it being a modified retail Gamecube system with the Optical Disc drive being replaced with a NPDP interface slot. However it lacked any method of communicating with a developers PC, which is where the IS-DOL-VIEWER would come in. IS-DOL-VIEWER (Intelligent Systems Dolphin Viewer) Intelligent Systems have a history of creating IS-Viewer cartridges for Nintendo consoles such as the Nintendo 64 and the Gamecube was no different. It connected to the bottom of the NPDP Reader console and enabled communication with a development PC over a RS-232 cable, making it similar to the NPDP-GBOX. The main purpose of this unit however was for Assert creators (Graphics artists, Sound engineers, 3D Animators etc) to preview how their game assets would look (or sound) when played on real Gamecube hardware. This has the advantage of being a cheaper solution than buying asset creators their own NPDP-GBOX and so they didn’t need to share time with other programmers and Testers on the team. It provided a High Speed USB 2.0 interface to connect to the Developers PC which allowed very fast transfer of Game assets for previewing on the Gamecube hardware 8. It also boasts about being the only Gamecube development hardware that natively supports the Apple Macintosh, which was a popular platform for content creators at the time. According to the official Intelligent Systems Website it also provided a connector to the NPDP-GDEV and AMC DDH development units by using an optional connector called the IS-DOL-VIEWER MEMORY CARD SLOT I / F kit 8. The main advantage of this would be to use the Intelligent Systems previewing tools and Macintosh support. NPDP-GW (Flash Gang Writer) The NPDP Gang Writer (NPDP-GW) for Gamecube had 8 slots available to place blank NPDP cartridges in and it will write the same game to all 8. This would be especially useful when sending out prototypes to a team of QA engineers, as far as we know it was never used to send to Journalists as they would not have the equipment available to read the NPDP cartridge. NPDP-SW (Single Writer) The little brother of the NPDP-GW is the NPDP Single Writer (NPDP-SW) which has the same function but only one port for writing to a single NPDP cartridge. This was much more convenient for sharing individual game builds throughout the team. NPDP-WIF (Writer InterFace) PCI card (GCP-3000) This PCI cart connected to the Gang/Single NPDP writers and is required for them to be able to write any data. it also comes with software for the PC which contained the device drivers and also an application called NPDP-Writer which was used to burn NPDP cartridges. NR Development KitsThe NR-based development kits came out at the same time as the NPDP kits and had the advantage of using fairly cheap DVD-Rs, known as NR Discs to store games. The downside is that a new CDR would need to be burned for each build, meaning it was a lot more wasteful than the NPDP development options.NR Disc (DOT-003) The Gamecube NR Discs are a small 8cm DVD-R that developers would write to using an NR-Writer and could only be played back on specific gamecube hardware called the NR-Reader. NR Disc were mainly used as a convenient testing solution as they could be easily burnt and given to a team of game testers to play on their NR-Reader consoles. NR Reader The Gamecube NR-Reader was a slightly modified retail Gamecube unit that could only play burned development NR discs, so it doesn’t play any retail game discs. Its purpose was to get as close to testing on a retail machine as possible, so no debugging features were present on these consoles. The main modification to the hardware other than the optical disc reader is that it has a switch on the side to switch between different regions (PAL/NTSC) 9. 𝘿𝙚𝙫𝙚𝙡𝙤𝙥𝙚𝙧𝙨 𝙆𝙞𝙩 𝙤𝙛 𝙩𝙝𝙚 𝙙𝙖𝙮If you're wondering why this #Gamecube has such an odd color, that's because it's a devkit. This is called an NR- reader. It only reads NR discs. #gaming #nintendo #gamersunite pic.twitter.com/rXA20vuTnc— 🕹 ᄃӨᄂӨПΣᄂ FΛᄂᄃӨП 🕹 (@ColonelFalcon) December 1, 2018NR-Writer The Gamecube NR Writer connects to a developer’s PC via a SCSI port and allows burning of Game Cube Image files (GCM) to NR discs. According to Nintendo this would only take about 20 minutes and you could even daisy chain multiple NR-Writers together to write up to 4 images at once! This gave it a similar functionality to the Gang Writer for NPDP cartridges. According to a post on AssemblerGames these writers are not unique to Nintendo and were used outside the games industry, but Nintendo got special permission from Panasonic to write custom firmwares for these drives to produce NR discs 9 USB-EXI USB Adapter (GCP-2000) The GCP-2000 USB Adapter connects via a Gamecube’s memory card slot and has a usb port allowing communication between a developer’s PC and the Gamecube hardware. The EXI bus on a Gamecube is used to connect external peripherals including the memory card and so this hardware just provides an interface between that EXI Bus and USB. SN Systems Development KitsSN Systems are very well known for their quality third party development kit hardware and SDKs and the gamecube was one of the last non-Sony platforms that they supported after being bought out by Sony. SN Systems (Creator of Development Tools) For more information on SN Systems check out this post. SN Systems Tiny Development Kit (SN-TDEV) The SN Systems Tiny Development Kit or SN-TDEV for short was a cheaper alternative to the other development kits and was very popular in Universities teaching game development along with smaller third party game developers. They require a license to use which apparently only lasted a single semester so the University would need to keep renewing them from SN Systems every term that they wanted to run the course 9. It cannot play regular retail games, only Burned NR-discs, but it also has a fast USB 2.0 connector which can be used to emulate the Disc drive on a developers PC, skipping the need to burn NR Discs. It provided double the amount of RAM (48MB) as a standard Nintendo Gamecube which allowed the ability to send compiled ELF executables to the system to debug and run 10. The SN-TDEV unit supports the SN Systems SDK known as PRO-DG, including the performance optimiser known as Tuner 10.𝘿𝙚𝙫𝙚𝙡𝙤𝙥𝙚𝙧𝙨 𝙆𝙞𝙩 𝙤𝙛 𝙩𝙝𝙚 𝙙𝙖𝙮This is a chocolate brown #Nintendo #Gamecube TDEV. It's a devkit that was also used in Universities. It does not play regular games, only NR discs. (Found at https://t.co/RfI4EsLWv6) #retrogaming pic.twitter.com/W7uVfQBGfP— 🕹 ᄃӨᄂӨПΣᄂ FΛᄂᄃӨП 🕹 (@ColonelFalcon) January 5, 2018SN Systems ProDG Devlink The SN Systems ProDG Devlink was hardware supplied with the SN Systems ProDG SDK known as ProView, which is similar in function to the IS-DOL-VIEWER in that it targeted asset creators rather than programmers 11. It connects to the NPDP Reader or NR Reader consoles and provides a USB interface to allow content creators to send assets to the Gamecube quickly. The image on the left was kindly provided by Shane Battye over on his twitter 12. Here is an image of the Pro-DG SDK package that was sold to developers, looks beautiful but it was very expensive for only 150mb of data:Interesting little tool for NR-Readers and GameCube dev - this is an SN Systems ProDG devlink kit pic.twitter.com/KClW9Br2DB— Shane Battye 🎮 (@shanebattye) August 25, 2019 Nintendo 64 (Ultra 64) Development Kit Hardware (Official & Unofficial) Since you have got this far you might be interested in Nintendo’s previous generation of console development hardware, if so check out this post. References Applied Microsystems - Guide - Nintendo World Report ↩ Nintendo Gamecube SDK Documentation ↩ https://www.youtube.com/embed/04uII-sb4cQ ↩ ANEMONE2.DOC from the BB2 Nintendo Leak ↩ GDEV - RGDWiki ↩ NDPD - ASSEMbler Games Archive ↩ Dumping a NPDP cart? - ASSEMbler Games Archive ↩ INTELLIGENT SYSTEMS 開発ツール ↩ ↩2 Comprehensive list of Gamecube dev stuff? - ASSEMbler - Home of the obscure ↩ ↩2 ↩3 SN-TDEV for Nintendo GameCube ↩ ↩2 ProView for Nintendo GameCube ↩ Shane Battye 🎮 on Twitter: “Interesting little tool for NR-Readers and GameCube dev - this is an SN Systems ProDG devlink kit ↩ ", "excerpt": "AMC Dolphin Development Hardware (DDH) The earliest Gamecube development hardware available to game developers was known as the Dolphin Development Hardware or simply DDH for short. This system was sold before the other development kits were finalised, allowing game developers to get a head start on Gamecube development 1. It...", "tags": ["gamecube","devkit","hardware"], "image": "/public/images/gc/Gamecube Development Kit Hardware.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Reversing with GDB (GNU Debugger)", "url": "/tutorials/gdb-reversing", "content": "IntroductionWhat is GDB?The GNU Debugger or GDB for short is a command line tool that allows you to disassemble and understand the code execution of a program.If you have ever used a debugger built into an IDE then you should be familiar with breakpoints, watch points and code stepping.GDB provides this functionality and is often used to implement the debugging features of IDEs.GDB For Reverse EngineeringGDB can thus be useful for reverse engineering as it can show and dynamically change the flow of the program, showing all state changes and code executed.One of the key benefits lies in GDB’s ability to dynamically analyze the execution of retro game code. With GDB, reverse engineers can run retro games within the debugger, observing the program’s behavior, and gaining insights into memory usage, register values, and the flow of execution.Breakpoint support in GDB is particularly advantageous for reverse engineers dissecting retro games. By strategically placing breakpoints at critical points in the code, such as game state transitions, collision detection routines, or graphics rendering functions, analysts can pause the game at specific moments and meticulously inspect the program’s state. This aids in understanding game mechanics, identifying graphical rendering processes, and uncovering the underlying algorithms governing gameplay.GDB CheatSheetHere’s a table format for some of the most commonly used GDB commands: Command Abbreviation Description run r Start program execution from the beginning. break b Set a breakpoint at a specified location. continue c Continue program execution until the next breakpoint. step s Execute the current line and stop at the first instruction of called functions. next n Execute the current line and stop at the next line in the same function. finish   Execute remaining lines of the current function and stop when the function returns. list l Display source code around the current line. info breakpoints   Display information about set breakpoints. print p Print the value of a variable or expression. backtrace bt Display a backtrace of the call stack. info locals   Display values of local variables in the current stack frame. info registers   Display values of CPU registers. set variable   Set the value of a variable during debugging. display   Display the value of an expression after each debugger command. delete   Delete a specific breakpoint or all breakpoints. watch   Set a watchpoint on a variable. info threads   Display information about threads in a multithreaded program. thread   Switch between threads in a multithreaded program. set pagination off   Disable pagination, allowing GDB to display long output without pausing. quit q Exit GDB. Simple License Check ExampleIn this video tutorial from LiveOverflow it gives a brief introduction on how to understand a simple license check application 1.You can download the files used in the tutorial from LiveOverflows Github page: liveoverflow_youtube/0x05_simple_crackme_intro_assembler at master · LiveOverflow/liveoverflow_youtube · GitHubIt is a linux executable that can be run either on a linux distribution or in Docker.Running the example without GDBYou can simply execute the provided example on a linux machine like so:./license_1 TEST-KEY-1234It will check to see if the argument is a valid license key, in this case TEST-KEY-1234 is not a valid license key so it prints the string “WRONG!”Running the example with GDBIt is just as simple to run the example through GDB, it just has a few extra steps before execution. You can run the executable through gdb like so:gdb license_1Notice that it won’t start execution straight away and instead give a command line prompt for you to execute a command into.The commands you can type into here are known as GDB commands and provide options for setting breakpoints, disassembling and much more.Disassemble the main functionAs this is a program compiled from C it has a main function, you can disassemble this function with GDB like so:disassemble mainHow easy is that? You can now see a full assembly listing of the main function! This is all the code that the CPU will execute when running your executable.Switching Disassembly Syntax from AT&T to IntelSome people prefer the intel syntax for disassembled code and you can set this with the following GDB command:set disassembly-flavor intelCreate a new breakpointTo create a breakpoint it is very simple you just use the command break along with the function name or address you want to break execution flow on. So for example:break mainRunning the programTo start execution so that we can reach our breakpoint simply type the command:runNote that you can also pass in arguments to the program as parameters to the run command so for out example we can pass a license key to the executable like so:run TEST-KEY-1234Also notice that if you use run when a program is already running it asks if you want to restart it, if you are looking to just go to the next breakpoint then use the continue command instead.View Register valuesRegisters are small pieces of memory that store values inside the CPU, assembly code works with registers to provide most of the logic. You can view their current values at the current breakpoint like so:info registersStepping to the next instructionYou have a few commands to step to the next instruction “ni” (next instruction) and “si” (step instruction. The difference is that ni doesn’t not step into function calls but si does.ni ; step over function callssi ; step into function callsChanging the value of registersYou can dynamically alter the values of registers with GDB too like so:set $eax=0This will set the EAX register to 0, but you can set it to any value you want.GDB for Console Game Development and ReversingOne thing to keep in mind is that you can’t just use any GDB executable, it needs to match the target CPU architecture, for example here is one for Z80: Z80 - legumbre/gdb-z80: GDB with Z80 target supportAlso some emulators have GDB support out of the box: GBA - mgba (use -g flag) mgba-emu/mgba: mGBA Game Boy Advance Emulator GBA/GB - vba-m (use -G flag) visualboyadvance-m/visualboyadvance-m: The continuing development of the legendary VBA gameboy advance emulator.gdb-multiarchgdb-multiarch is a variant of the GNU Debugger (GDB) designed to support multiple architectures, making it more convenient to work with executables targeting different instruction sets or CPU architectures within the same GDB instance.The primary motivation for using gdb-multiarch arises in situations where you need to debug binaries compiled for architectures other than the one on which GDB is running. It provides a single interface to handle debugging sessions for multiple architectures, allowing you to seamlessly switch between them without restarting GDB.This is very useful for connecting to game console emulator’s that already contain a GDB Stub (covered in a future section).Where to get gdb-multiarchOn systems that support package managers, you can typically install gdb-multiarch alongside the standard GDB. For example, on Debian-based systems: bash sudo apt-get install gdb-multiarch For MacOS we have created a custom homebrew tap for easy installation available hereYou can use it like so:brew tap RetroReversing/gdb-multiarchbrew install gdb-multiarch/usr/local/Cellar/gdb-multiarch/15.1/bin/gdb-multiarchHow to use gdb-multiarchOnce installed, you can use gdb-multiarch similarly to the standard gdb. The key difference is that gdb-multiarch allows you to specify the target architecture when loading an executable. bash gdb-multiarch -q -tui -ex \"target sim\" -ex \"load\" -ex \"run\" -ex \"quit\" my_program.elf How to see what architectures are availableYou can see what target architectures are available simply by using the following command in gdb:set architectureIt will print out something like this if it really is gdb-multiarch:Requires an argument. Valid arguments are i386, i386:x86-64, i386:x64-32, i8086, i386:intel, i386:x86-64:intel, i386:x64-32:intel, i386:nacl, i386:x86-64:nacl, i386:x64-32:nacl, aarch64, aarch64:ilp32, arm, armv2, armv2a, armv3, armv3m, armv4, armv4t, armv5, armv5t, armv5te, xscale, ep9312, iwmmxt, iwmmxt2, armv5tej, armv6, armv6kz, armv6t2, armv6k, armv7, armv6-m, armv6s-m, armv7e-m, armv8-a, armv8-r, armv8-m.base, armv8-m.main, arm_any, alpha, alpha:ev4, alpha:ev5, alpha:ev6, hppa1.0, ia64-elf64, ia64-elf32, m68k, m68k:68000, m68k:68008, m68k:68010, m68k:68020, m68k:68030, m68k:68040, m68k:68060, m68k:cpu32, m68k:fido, m68k:isa-a:nodiv, m68k:isa-a, m68k:isa-a:mac, m68k:isa-a:emac, m68k:isa-aplus, m68k:isa-aplus:mac, m68k:isa-aplus:emac, m68k:isa-b:nousp, m68k:isa-b:nousp:mac, m68k:isa-b:nousp:emac, m68k:isa-b, m68k:isa-b:mac, m68k:isa-b:emac, m68k:isa-b:float, m68k:isa-b:float:mac, m68k:isa-b:float:emac, m68k:isa-c, m68k:isa-c:mac, m68k:isa-c:emac, m68k:isa-c:nodiv, m68k:isa-c:nodiv:mac, m68k:isa-c:nodiv:emac, m68k:5200, m68k:5206e, m68k:5307, m68k:5407, m68k:528x, m68k:521x, m68k:5249, m68k:547x, m68k:548x, m68k:cfv4e, mips, mips:3000, mips:3900, mips:4000, mips:4010, mips:4100, mips:4111, mips:4120, mips:4300, mips:4400, mips:4600, mips:4650, mips:5000, mips:5400, mips:5500, mips:5900, mips:6000, mips:7000, mips:8000, mips:9000, mips:10000, mips:12000, mips:14000, mips:16000, mips:16, mips:mips5, mips:isa32, mips:isa32r2, mips:isa32r3, mips:isa32r5, mips:isa32r6, mips:isa64, mips:isa64r2, mips:isa64r3, mips:isa64r5, mips:isa64r6, mips:sb1, mips:loongson_2e, mips:loongson_2f, mips:loongson_3a, mips:octeon, mips:octeon+, mips:octeon2, mips:octeon3, mips:xlr, mips:interaptiv-mr2, mips:micromips, rs6000:6000, rs6000:rs1, rs6000:rsc, rs6000:rs2, powerpc:common64, powerpc:common, powerpc:603, powerpc:EC603e, powerpc:604, powerpc:403, powerpc:601, powerpc:620, powerpc:630, powerpc:a35, powerpc:rs64ii, powerpc:rs64iii, powerpc:7400, powerpc:e500, powerpc:e500mc, powerpc:e500mc64, powerpc:MPC8XX, powerpc:750, powerpc:titan, powerpc:vle, powerpc:e5500, powerpc:e6500, riscv, riscv:rv64, riscv:rv32, s390:64-bit, s390:31-bit, sh, sh2, sh2e, sh-dsp, sh3, sh3-nommu, sh3-dsp, sh3e, sh4, sh4a, sh4al-dsp, sh4-nofpu, sh4-nommu-nofpu, sh4a-nofpu, sh2a, sh2a-nofpu, sh2a-nofpu-or-sh4-nommu-nofpu, sh2a-nofpu-or-sh3-nommu, sh2a-or-sh4, sh2a-or-sh3e, sparc, sparc:sparclet, sparc:sparclite, sparc:v8plus, sparc:v8plusa, sparc:sparclite_le, sparc:v9, sparc:v9a, sparc:v8plusb, sparc:v9b, sparc:v8plusc, sparc:v9c, sparc:v8plusd, sparc:v9d, sparc:v8pluse, sparc:v9e, sparc:v8plusv, sparc:v9v, sparc:v8plusm, sparc:v9m, sparc:v8plusm8, sparc:v9m8, m32r, m32rx, m32r2, auto.Most useful for games consoles would be: arm - Nintendo GBA/DS (mGBA has a GDB stub) mips:4300 - Nintendo 64 mips:3000 - Playstation 1 mips:5900 - Playstation 2 powerpc - Gamecube/Wii/ps3 m68k - Sega Mega Drive sh2 - Sega Saturn sh4 - Sega DreamcastYou will notice that there is no good options for 6502 or Z80 variants in GDB as these systems tend to be too old to have official GDB support.How to change target architectureYou can change the target architecture within the GDB session using the set architecture command. bash set architecture arm This flexibility is particularly useful when working with cross-compilation environments or when dealing with software that supports multiple architectures.GDB FrontendsGDB frontends are graphical or text-based interfaces that provide a user-friendly way to interact with the GNU Debugger (GDB). These frontends simplify the debugging process by offering features like syntax highlighting, variable inspection, and breakpoint management. Here are some popular GDB frontends: GDBGUI - gdbgui DDD - DDD - Data Display Debugger - GNU Project - Free Software Foundation (FSF)GDBGUIGDBGUI is a modern and browser-based graphical interface for GDB, providing a convenient way to interact with the GNU Debugger. It allows developers to debug programs through a web-based interface, offering features like source code visualization, variable inspection, and breakpoint management.DDD (Data Display Debugger)DDD is a popular graphical debugger front-end for GDB. It provides a visual representation of data structures, making it easier to inspect variables. DDD supports multiple programming languages and includes features such as source code highlighting, breakpoints, and a powerful interface for interacting with GDB.GhidraNewer versions of Ghidra also support GDB debugging, here is an article explaining how to set it up for Game Boy Advance: A first look at Ghidra’s Debugger - Game Boy Advance Edition | Wrongbaud’s BlogIt uses the mGBA emulator as it provides a GDB stub which can be connected to Ghidra (through gdb-multiarch). The next session will explain what GDB stubs are and what they are used for.GDB StubsGDB Stubs are components embedded within target programs to enable remote debugging, they form a crucial link between the GDB debugger and the running program, facilitating communication, control, and inspection of the target’s runtime behavior.What do GDB Stubs do?GDB Stubs interpret commands received from the GDB debugger, executing actions within the target program accordingly. Commands may include setting breakpoints, stepping through code, inspecting memory, and altering the program’s state.GDB Stubs, developers gain fine-grained control over the execution of the target program. Breakpoints can be set, and program execution can be paused, allowing for detailed inspection and analysis of the program’s runtime behavior.How does it compare to using regular GDB on an executable?Regular GDB runs on the same system as the program being debugged, GDB Stubs however communicate over a network connection enabling bidirectional communication between the debugger and the target program running on another system. This remote connectivity is especially valuable in scenarios where physical access to the running program is limited.This is great for debugging software that don’t have a debugging environment such as games consoles and other embedded systems.What exactly are GDB stubs?GDB Stubs consist of a lightweight set of code seamlessly integrated into the binary of the target program. This embedded code is responsible for establishing a communication channel between the running program and the GDB debugger.How does the stub communicate with the GDB debugger?Communication between the GDB debugger and GDB Stubs follows the GDB Remote Serial Protocol. This protocol defines a standardized format for messages exchanged between the debugger and the stub, allowing for coherent interaction during debugging sessions.You can find out more about the GDB Remote Serial Protocol on the official documentation website: Remote Protocol (Debugging with GDB)Security ImplicationsAs GDB Stubs provide a pathway for remote interaction with a program, developers must consider security implications and ensure proper safeguards to prevent unauthorized access. Software should not be released with the GDB stub embedded inside and proper network hygiene is required between the two remote systems to prevent Man in the Middle attacks.Adding GDB to existing emulators/softwareNot all emulators have support for GDB out of the box, which is a shame as it is an incredibly useful feature for reverse engineering. Luckily most good emulators are open source so we can in theory add GDB support ourselves!Using Rust and rust-gdb-remote-protocolMarcin Mikołajczyk has a good tutorial on how to add GDB support to a dummy MIPS CPU emulator using Rust and specifically the rust-gdb-remote-protocol available to read online here.Note that if you are using MacOS you will need to get the MIPS compiler mipsel-unknown-linux-gnu using the folowing custom homebrew tap:brew tap messense/macos-cross-toolchainsbrew install mipsel-unknown-linux-gnuIt will install to a path similar to /usr/local/Cellar/mipsel-unknown-linux-gnu/13.3.0/bin which you can either add to PATH or just run directly:/usr/local/Cellar/mipsel-unknown-linux-gnu/13.3.0/bin/mipsel-unknown-linux-gnu-gcc --version/usr/local/Cellar/mipsel-unknown-linux-gnu/13.3.0/bin/mipsel-unknown-linux-gnu-gcc -nostdlib -march=r3000 -Wl,--section-start=.text=0xbfc00000 hello_mips.c/usr/local/Cellar/mipsel-unknown-linux-gnu/13.3.0/bin/mipsel-linux-gnu-objcopy -O binary -j .text a.out a.binThis will give you a.out to use with the emulatorTo run the rust program itself you can simple do:cargo buildcargo run a.binInitially it give the output:thread 'main' panicked at 'index out of bounds: the len is 80 but the index is 384', src/cpu.rs:28:19note: run with `RUST_BACKTRACE=1` environment variable to display a backtraceWhich may or may not be intentional to start the tutorial. However switching to the final branch did at least listen for gdb on port 2424.If you load up standard GDB and type the following command in:target remote localhost:2424The GDB server will output the following:Listening on port 2424Got connectionConnection closedThis is probably because GDB only has the target architecture that your CPU has (probably either x64 or arm) but requires mips support. This is where gdb-multiarch comes in useful as it is a build of GDB with all the architectures enabled. However the problem is there doesn’t seem to be any release of it for MacOS, so if you are on Linux you should be fine but for MacOS we will need to build GDB ourselves.References Reversing and Cracking first simple Program - bin 0x05 - YouTube ↩ ", "excerpt": "Introduction What is GDB? The GNU Debugger or GDB for short is a command line tool that allows you to disassemble and understand the code execution of a program. If you have ever used a debugger built into an IDE then you should be familiar with breakpoints, watch points and...", "tags": ["introduction","gdb"], "image": "/public/images/tools/ReversingWithGDB.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game Developers Conference (GDC) - Full list of historical sessions", "url": "/gdc", "content": "GDC stands for the “Game Developers Conference”, which is an annual event held for professionals in the video game industry.Originally it was called the Computer Game Developers Conference but the Computer was dropped to focus on video games as a whole rather than just “Computer Games”.GDC serves as a hub for game developers, publishers, artists, programmers, designers, and other industry experts to come together to discuss, share, and learn about the latest trends, technologies, and practices in game development.The event includes a wide range of sessions, panels, workshops, and networking opportunities.CGDC 1988The first Computer Game Developers Conference (CGDC) was held in 1988. It was founded by Chris Crawford, a well-known game designer and developer, and it took place in his living room in San Jose, California. This initial gathering was relatively small (27) and informal compared to the later iterations of GDC, but it marked the beginning of what would become one of the most significant annual events in the video game industry.Since that modest start, GDC has grown in size and importance, attracting game developers and industry professionals from around the world.The best source of information about the first few CGDC events is to watch this excellent documentary by GamersGlobal available below:CGDC 2 - September 18th/19th 1988The second Computer Game Developers Conference (CGDC) was held later in the same year, on September 18th and 19th 1988. It was sponsored by Computer Gaming World and would be the first GDC with a pre-planned agenda. It had about 150 attendees, a whole five times larger than the previous conference hosted earlier the same year.You can find the main talks and their authors in the table below: Title Presenter Notes Interactive Story Making Brian Moriarty Creator of Loom Art and Animation Panel Willie Aguilar, Paul Reiche III Star Control creator Creativity and Game Design Chris Crawford   Legal Issues Susan Nycum Lawyer who specialises in computer security and intellectual property issues Playtesting and Q.A. Dan Bunten, Cem Kaner, Dave Menconi   Developing for the Macintosh David Feldman Shadowgate programmer? Game Idea to Game Design Kellyn Beeck Game Designer for Rocket Ranger Sound and Music panel Chris Grigg, David Thiel, Dave Warhol   Fantasy Role Playing Games Brian Fargo Founder of Interplay and InXile PR for Developers Ed Niehaus   Brining Characters to Life panel Chris Crawford, David Graves, Brenda Laurel   Market Trends panel Bob Lindstrom, Scott Mace   Simulations panel Ned Lerner, Gilman Loule, Gordon Walton   From Proposal to Contract Stephen J. Friedman Worked on Impossible Mission II Self-Publishing Pete Antoniak Templates of Doom creator? (edutainment) Developing for MS-DOS Evan and Nicky Robinson Star Control developers Sports and Action Games panel Jordan Mechner, Scott Orr   New Techniques in Theft Protection Jeff Johannigman Producer on games such as Ultima Worlds As far as we know all the content for these presentations have been lost to time, but please let us know if any slides or notes are available somewhere on the internet.The conference did not become an annual event until a few years later.Developing for MS-DOSFrom a programming perspective the session Developing for MS-DOS would have been one of the highlights of the conference. Evan and Nicky Robinson were both programmers on hit games Star Control and Mail Order Monsters. So to hear their perspective on developing games for MS-DOS would have been incredible!In the Journal for Computer Game Development December 1988 issue Eric Goldberg wrote the following about the session: Evan and Nicky Robinson’s “Developing for MS-DOS” was praised by many attendees. While no one professed a desire to grapple with an operating system universally regarded as clunky, the Robinsons were given full marks for a concise explanation of how to get through the odious task of supporting all four of the CGA, EGA, VGA, and Hercules graphics standards. The IBM PC and clone family is clearly where the most money is to be made in games.1CGDC 3 - 1989Not much is known about the third version of the Computer Game Developers Conference (CGDC) hosted in Sunnyvale California sometime in 1989 and managed to double the previous attendance from 150 to 300. Title Presenter Notes Story vs Game: The Battle of Interactive Fiction Doug Sharp Notes from the Talk If you know of any sessions that took place in the 1989 Computer Game Developer Conference then please let us know!CGDC 1990 - April 1st-2ndFor a brief insight into the fourth version of CGDC you can read Bill Pirkle’s observations in the June 1990 issue of Journal of Computer Game Design here: Volume 3 Number 5. June 1990 It was hosted in Le Baron Hotel in San Jose and was attended by over 470 people.We only know of a few talks that took place at this conference: The Artistic C by Jim Gasperini (Recording) Artificial Opponent by Dave Menconi A Competitive Analysis of Publishers by Stephen Friedman (Recording) Arcade Games: Their Promise and Their Failure by Ed Rotberg (Recording) Contracts: An Improvised Negotiation by Stephen Friedman and Nick Le Febre (Recording) Self Publishing by Jeff Braun and Jeff Tunnell (Recording)The Artistic CThe earliest known recording of a Game Developer Conference talk is called The Artistic C by Jim Gasperini.This was when he was a creative director for Maxis while working on the simulation game SimCity. He talks about Computer Games as Art and how he believes it will evolve over time.You can listen to it online on Archive.org: CGDC 90 Jim Gasperini - GDC Jim GasperiniCGDC 1991 - MarchThe Fifth CGDC was the first to have been directed by Ernest Adams just before his move to Electronic Arts where he would work on titles such as John Madden Football 2. It was again hosted in San Jose this time in the Hyatt Hotel and received 550 attendees.We only know of a few talks that took place at this conference: Intelligent Behavior Without AI: An Evolutionary Approach by Neil Kirby Cyberspace: Lessons of Lucasfilm’s Habitat by F. Randall Farmer, Chip Morningstar (CGDC91-003) 3 Evolution of Taste by Chris CrawfordOnly the Cyberspace talk was recorded on Audio cassette by the KNOW-IT-ALL Audiovisual Library 3.For a review of what it was like to go to the 1991 CGDC check out Chris Crawford’s perspective: Volume 4, Number 4, March 1991 - Interactive Storytelling Tools for Writers - Chris CrawfordCGDC 1992 - April 25th-26thHosted in the DoubleTree Hotel in Santa Clara California, the sixth CGDC was attended by over 600 game industry professionals.We only know of a few talks that took place at this conference: Artificial Personality by Jon Freeman (CGDC92-026) Making It Real: Story & Characters by Ellen Guon, Katherine Lawrence (CGDC92-014) Music, Art, and the Blue Sword of Gralfarniblurt by The Fat Man Lessons From Patton Strikes Back by Chris Crawford Analytical history of a critical phase in the development of the cinema by Brian Moriarty (Actual title unknown) Virtual Reality Update by Brenda Laurel Battle of the Multimedia Platforms by Stewart Bonn, John Baker, Kelly Flock, and Bill Davis Roundtable by Sid MeierThis list is incomplete, if you know of any more talks that took place at GDC 1992 then please let us know!.For a review of what it was like to go to the 1992 CGDC check out Chris Crawford’s perspective: 1992 CGDC Report - Interactive Storytelling Tools for Writers - Chris CrawfordChris Crawford’s Dragon SpeechCGDC 1993Again hosted in Santa Clara California but this time reaching 900 attendees, the seventh CGDC was becoming incredibly well known within the industry.All the talks that were recorded by The KNOW-IT-ALL Audiovisual Library are listed in the table below 4.Note that each session was given a unique ID in the form of CGDC93-0XX which will be provided in the table if know. This is mainly useful for finding missing sessions that were not recorded. Title Presenter Type Notes Asset Acquisition Clarke-Willson, Shane, San Lecture CGDC93-025 Distribution Realities and Workarounds Gordon Walton Lecture CGDC93-003 Game Development for Windows Sandige & Stafford Lecture CGDC93-018 How We Almost Didn’t Make The Seventh Guest Graeme Devine Lecture Similar Article CGDC93-006 I Had A Dream Chris Crawford Lecture CGDC93-002 Imitating Life: Perception, Evolution & Complexity Wright, Rob Tow, Bergman, Brenda Laurel Lecture CGDC93-026 Interactive Entertainment Industry Report Lee Isgur Lecture CGDC93-004 Interactive Multimedia: Revolution or Crock? Baltcom & Walton Lecture CGDC93-023 Is A Picture Worth A Thousand Words? Paul Reiche Lecture CGDC93-001 ISDN Looms On The Horizon Bob Alexander Lecture CGDC93-008 Making It Real 2: Characters Katherine Lawrence Lecture CGDC93-020 The New Ergonomics: Design Beyond the Hardware Goldberg & Fox Lecture CGDC93-024 The New Jagged Edge: Multimedia & The Law Mark Radcliffe Lecture CGDC93-022 Paintbrushes to Pixels Johnson, McCaig, Michaud Lecture CGDC93-009 Please Don’t Let Me Be Misunderstood Steve Cooke Lecture CGDC93-010 Producing Music with The Fat Man George Sanger Lecture CGDC93-027 Project Artificial Intelligence Baldwin & Rakosky Lecture CGDC93-019 3DO and the Future of Interactive Entertainment Bill Duvall, Bob Faber, David Maynard Lecture CGDC93-007 The Viability of Different CD Formats Koffler & Wilmunder Lecture CGDC93-021 Where Have All the Chickens Gone? David Walker Lecture CGDC93-005 Adding Modem Play to Your Game Rakosky & Baldwin Seminar CGDC93-036 Algorithmic Music David Rosenbloom Seminar CGDC93-031 The Art of Game Balancing, Part II Roe Adams Seminar CGDC93-039 Designing Multi-Player Games Dani Bunten Seminar CGDC93-034 Designing the Puzzle: A Hands-On Seminar Bob Bates Seminar CGDC93-047 From Linear to Non-Linear: Game Scripting Christy Marx Seminar CGDC93-038 Hex, Bugs & Rock ‘n’ Roll: Powerful Debugging Dan Hite Seminar CGDC93-017 Lite Gaming and the Mass Market Jeff Johannigman Seminar CGDC93-033 Mystic Wisdom of the East Evan Robinson Seminar CGDC93-035 New Software Methods for Sound Compression Brad Stewart Seminar CGDC93-012 No C++ Required: Breaking In for Non-Techs Ellen Guon Seminar CGDC93-016 Not Just Kid Stuff: Late Learning Software Marylyn Rosenblum Seminar CGDC93-015 Object-Oriented Programming Neil Kirby, Glenn Tenney Seminar CGDC93-014 Realistic Behavior for Animated Characters David Joiner Seminar CGDC93-029 Rubbing the Lamp Robert Leyland Seminar CGDC93-011 Smart, But Not Rich? Find Out Why! Ernest Adams Seminar CGDC93-037 Stress Management for Game Designers Diane Escoffon Seminar CGDC93-028 A Technical Overview of the Sega Genesis Dan Chang Seminar CGDC93-030 13 Million Can’t Be Wrong: Windows Games Neil Kirby Seminar CGDC93-046 32-bit Programming: The Misunderstood Grail John Miles Seminar CGDC93-032 Who Designed This Cover, Anyway? Davld Kessler Seminar CGDC93-013 Adventure Game Design Roundtable R.J. Berg Roundtable CGDC93-041 Audio Issues for Game Developers Tom Rettig Roundtable CGDC93-052 Breaking In: the Wannabee Roundtable Guon & Robinson Roundtable CGDC93-050 Educational Software for Kids Under Ten Leslie Grimm Roundtable CGDC93-051 The Ethics of Game Design Corey Cole & Lori Cole Roundtable CGDC93-053 For Art’s Sake: A Roundtable Chris Crawford Roundtable CGDC93-043 From the Dustbin of Game History Noah Falstein Roundtable CGDC93-042 IBM PC & VGA Platform Issues Brengle & Robinson Roundtable CGDC93-054 RPG Design Roundtable George MacDonald Roundtable CGDC93-049 Skill & Action Game Design Roundtable Gregg Tavares Roundtable CGDC93-040 Sports Game Roundtable Richard Hilleman Roundtable CGDC93-045 Vehicle Simulations Roundtable Edward Lerner Roundtable CGDC93-048 Wargame Design Roundtable Dave Menconi Roundtable CGDC93-044 Which Company Should I Work For? Ernest Adams Roundtable CGDC93-055 Potentially not officially recorded were the following talks: Legal Trends Affecting Computer Game Development by Alisa Baker No Wine Before Its Time? by Michael CrickCGDC 1994Another hosted in Santa Clara California but this time reaching over the one thousand mark with 1250 attendees, it was the eighth CGDC.Google Books claims to have the proceesings of the Eighth Annual Computer Game Developers Conference Proceedings but it doesn’t seem to be possible to read: Eighth Annual Computer Game Developers Conference Proceedings: April 23 … - Google BooksA user over at archive.org managed to upload audio recordings of the 1994 conference, some of the titles match the above but others do not, they are available in the table below:There were at least 130 talks at CGDC 1994 that we know about, thanks to The KNOW-IT-ALL Audiovisual Library website, they are listed in the table below: Title Presenter Type Notes 3DO, Cable, RBOCs: Who Wins? Bob Alexander Lecture CGDC94-001 Alternative Marketing Methods Diana Gruber Lecture CGDC94-004 Approaches to Funding Games Steve Shannon Lecture CGDC94-005 Audio Community Forum Tom Rettig Lecture CGDC94-007 Believable Interactive Characters Joseph Bates Lecture CGDC94-011 Audio Slides Business Plans for Multimedia Company Gina Frye, John Kalb, Alison Ross Lecture CGDC94-013 Audio C++ Light: OOP is a Four- Letter Word Stephen Beeman Lecture CGDC94-028 CD-ROM Programming for the PC Mark Manyen Lecture CGDC94-014 Celluloid to Silicon: A Sermon Ernest Adams Lecture CGDC94-016 Audio Slides Code Optimization for Intel Pentium Gary Carleton Lecture CGDC94-017 Contract Negotiations: Issues & Strategy Jeff O’Connell Lecture CGDC94-021 Audio Distribution Realities (and Workarounds) Gordon Walton Lecture CGDC94-026 Effective Quality Assurance Tom Czarnik Lecture CGDC94-027 Fantasy to Reality and Back Again Michele Em Lecture CGDC94-030 Fine Art of Data- Wrangler Paul Reiche, Scott A. H. Ruggels Lecture CGDC94-031 Games for Megamathematics Michael Fellows Lecture CGDC94-033 Getting a Job (For Technical Wannabes) Kay Sloan Lecture CGDC94-034 Hard Lessons in Program Design John Miles Lecture CGDC94-036 How the Other Half Plays Barbara Lanza Lecture CGDC94-038 Audio Human Animation Techniques Kendra Lammas Lecture CGDC94-041 Industry Overview for Wannabes Tim Brengle, Greg Johnson, Mark Voorsanger Lecture CGDC94-043 Interactive Directing Noah Falstein Lecture CGDC94-045 Audio Interactive Music: Why, How and Where Donald S. Griffin Lecture CGDC94-046 Interactivity Revolution, and Pain Chris Crawford Lecture CGDC94-047 Audio Interface is the Game William Volk Lecture CGDC94-048 Kid Friendly: Educational Games Annie Fox, Ken Goldstein, Gano Haine, Ellen Guon Lecture CGDC94-049 Audio Live Action Role Playing Walt Freitag Lecture CGDC94-051 Audio Making Interactive Games for Both Genders Heidi Dangelmaier Lecture CGDC94-052 Meet the Press Bob Lindstrom, Wes Nihei, Gina Smith, Johnny L. Wilson, Susan W. Lee-Merrow Lecture CGDC94-054 Audio Multimedia Versus Game Design Chris Crawford, Sid Meier, Greg Roach Lecture CGDC94-057 Music: The Heart of Interactivity The Fat Man Lecture CGDC94-103 Online Multiplayer Games Carrie Washburn, Richard Mulligan Lecture CGDC94-059 Audio Overview of the Jaguar Game Machine Bill Rehbock Lecture CGDC94-060 PLACEHOLDER: Real Bodies in Virtual Worlds Brenda Laurel, Rob Tow Lecture CGDC94-062 Audio Pixel Envy Jenny Martin Lecture CGDC94-064 Practical 3D Implementation (CGDC94-066) Robert Zdybel Lecture CGDC94-066 Programming for Commercial Virtual Reality Devices (CGDC94- 069) David Whatley Lecture CGDC94-069 Programming the VESA Audio Interface (CGDC94-071) Doug Cody Lecture CGDC94-071 Protecting the Intellectual Property in your Interactive Software (CGDC94-072) Scott Pink Lecture CGDC94-072 Puzzle Games and How to Design Them (CGDC94-074) Scott Kim Lecture CGDC94-074 Rapid Prototyping (CGDC94-075) Nicole Lazzaro Lecture CGDC94-075 Real AI, Part I: Game- Tree Search (CGDC94-076) W. Bryan Stout Lecture CGDC94-076 Software Ratings John (Jack) W. Heistand, Dr. Barbara Simons, Johnny L. Wilson, Steve Peterson Lecture CGDC94-085 Speech Technology Gary Davenport Lecture CGDC94-087 Status of the Interactive Entertainment Industry, 1994 Lee S. Isgur Lecture CGDC94-089 Audio Storybuilding: Creating Story & Character Ellen Guon Lecture CGDC94-090 Audio Surviving a Long Distance Relationship Bobby Prince Lecture CGDC94-091 Trends in Game Software Sales Ann Stephens Lecture CGDC94-094 Audio Tricks for Designing Game Music Rob Wallace Lecture CGDC94-095 Using Attorneys & Accountants Bruce Maximov, Paul J. Heiselmann Lecture CGDC94-096 Windows Programming: A Beginner’s View Nicky Robinson, Stephen Beeman Lecture CGDC94-092 WinG: A DLL for Graphics Chris Hecker Lecture CGDC94-101 Add Speech Recognition Dragon Systems Sponsored Session CGDC94-002 Autodesk Autodesk Sponsored Session CGDC94-009 DOS/4G: The Ideal Games Platform Rational Systems Sponsored Session CGDC94-023 Convergence, Consolidation, Confusion? Frost Capital Partners Sponsored Session CGDC94-022 Exploiting Logitech’s Cheap 3D Device Logitech Sponsored Session CGDC94-029 High-End Authoring Tools Wavefront Technologies Sponsored Session CGDC94-037 How to Get Your Program/Project Published by Ablesoft Ablesoft Sponsored Session CGDC94-039 How to Place Your Game on Shelves of 15,000 Retail Stores Expert Software Sponsored Session CGDC94-040 IBM Continuous Speech IBM Sponsored Session CGDC94-042 Intel’s New 3D Graphics Interface Intel Sponsored Session CGDC94-044 Media Vision Media Vision Sponsored Session CGDC94-053 OS/2 and the Home Market Place IBM Sponsored Session CGDC94-058 PC - The Platform of Choice for the Emerging Games Industry Intel Sponsored Session CGDC94-061 Phillips Interactive Media Philips Interactive Sponsored Session CGDC94-063 Audio Playing on the Information Highway Microsoft Sponsored Session CGDC94-065 Shifting Trends of Music and Sound Advanced Gravis Sponsored Session CGDC94-081 Adventure Game Design George MacDonald Roundtable CGDC94-003 Art and Craft of Games Margot Comstock Roundtable CGDC94-006 Audio Technical Issues David Warhol Roundtable CGDC94-008 Board Games Hal Bogner Roundtable CGDC94-012 Casino Gaming and Wagering Lee Cannon, Kevin Furry Roundtable CGDC94-015 Coin-Op Design Mark Pierce Roundtable CGDC94-018 Computer Gaming in Russia Alex Fedorov Roundtable CGDC94-019 Computer Players Dave Menconi Roundtable CGDC94-020 Defining Music for Interactivity The Fat Man Roundtable CGDC94-024 Different Approaches to Animation Kirk Henderson Roundtable CGDC94-025 Financing Your Company/Product Goncher, Shannon Roundtable CGDC94-031 Graphic Design Susan Manley Roundtable CGDC94-035 Letter Feedback ? Roundtable CGDC94-102 Little Guys Chris Crawford Roundtable CGDC94-050 Modem Game Design Dan Hite Roundtable CGDC94-055 Multimedia Meets Game Design Eric Goldberg Roundtable CGDC94-056 Primary Education Software Jeff Haas Roundtable CGDC94-067 Process Simulation Will Wright Roundtable CGDC94-068 Puzzle Game Design Bob Bates Roundtable CGDC94-073 Role-Playing Game Design George MacDonald Roundtable CGDC94-078 Secondary Education Software Joyce Hakansson Roundtable CGDC94-079 Sexual Themes Dr. Cat Roundtable CGDC94-080 So, Ya Wannabe in the Industry MacDevitt, Nakagawa Roundtable CGDC94-083 Software Ratings: Threat or Menance Steve Peterson Roundtable CGDC94-086 Sports Games Keith Francart Roundtable CGDC94-088 Vehicle Simulation John Wheeler Roundtable CGDC94-097 Violence in Interactive Entertainment Johnny L. Wilson Roundtable CGDC94-098 Wargame Design Roger Keating Roundtable CGDC94-099 When Teams Work, When Teams Break Don Daglow Roundtable CGDC94-100 One of the most notable talks from this conference was WinG: A DLL for Graphics, this was the introduction to what would become DirectX. Microsoft finally taking Game Development seriously and allowing full screen fast graphics rendering without having to go into MS-DOS!Reception of CGDC 1994You can read Ross Erickson’s review of this experience at CGDC 1994 in his article published in the Game Bytes Magazine online here: THE 1994 COMPUTER GAMES DEVELOPERS CONFERENCE. He mentions his disappointment at some of the talks and where he was pleasantly surprised.CGDC 1995There were so many talks in CGDC 1995 year that the conference was split into a number of specialist “Tracks”: Audio Business Edutainment/Education General Interest Management Online/Network Special Interest Technical Visual ArtsThere were at least 128 talks at CGDC 1995 that to The KNOW-IT-ALL Audiovisual Library page on the audio recordings, they are listed in the table below: Title Presenter Track Notes Adding a New Dimension: Moving from 2D to 3D Animation Vance Gloster Visual Arts CGDC95-001 Ages, Stages, and Living Pages: Designing for Interactivity Mark Schlichting Edutainment/Education CGDC95-002 The Answer Is Money Noah Falstein General Interest CGDC95-003 Audio Community Forum Tom Rettig, Bob Safir Audio CGDC95-004 Beyond Bootstrapping & Royalty Advances: Financing Alternatives Dean Gloster, Mark Gorenberg Business CGDC95-005 CD-ROM Multimedia: Lessons & Issues from the Performing Arts David Rosenbloom General Interest CGDC95-006 Can You Believe Families Hate Games? Fred M. Abaroa Business CGDC95-007 The Challenge of the Interactive Movie Ernest Adams General Interest CGDC95-008 Creating Interactive Drama for CD-ROM Using Outside Techniques Pamela Douglas, John Spencer General Interest CGDC95-010 Cross-Platform Development: the 10 Key Criteria for Success Sandy Montenegro, Don Rogal Technical CGDC95-011 Deal Breakers: The Most Critical Provisions in Your Contracts Jeffrey A. O’Connell (Business) CGDC95-012 Design Documents that Work: Topiary for Fun and Profit Matthew Stibbe Special Interest CGDC95-013 Designing a Space Camel: Exploring the Development of Alien Legacy Michael Moore Management CGDC95-014 Developing Children’s Educational Multimedia: Practical Tips Debra Lieberman, Lynn Rosener Edutainment/Education CGDC95-015 Developing Digital Sets and Creative Animations (3D Studio) Verin G. Lewis Visual Arts CGDC95-016 Developing Games Based on Licensed Properties David Mullich (Business) CGDC95-017 Developing for the Sony Playstation Mark Wozniak (Business) CGDC95-018 The Development Process: What Nobody Seems to Know David Walker Management CGDC95-019 Directed Improvisation: A New Paradigm for Computer Games Dr. Barbara Hayes-Roth Special Interest CGDC95-020 Educational Software Design: A Developmental Psychologist’s View C. Brannon, A.J. Lehrer Edutainment/Education CGDC95-022 Effective Software Testing v1.2 Tom MacDevitt Special Interest CGDC95-023 Family Games: Something for the Rest of Us Fabrice Florin, Peter Maresca General Interest CGDC95-024 Film & Video Production for Interactive Entertainment Mark Day Management CGDC95-025 From Zork to Zillions: How to Fund, Value, and Sell a Company Dean Frost, Ian Berman Business CGDC95-026 The Fun Factor Lori and Corey Cole General Interest CGDC95-027 Game Trademarks: A Secret Weapon Charles B. Kramer Business CGDC95-028 Gaming on the Internet Glen Tenney Online/Network CGDC95-029 Gender Ghettos Margy Hillman, Joanne Odenthal General Interest CGDC95-030 Graphics, Video, & Sound: An Overview of the Technologies Eric Klein Technical CGDC95-031 Hot Content: Dealing with Controversial Material in Games Daniel Greenberg General Interest CGDC95-032 Humor in Game Design Steve Meretzky General Interest CGDC95-033 Intelligent Tutors & the Internet Frederic Vincent Bien Online/Network CGDC95-034 The Interactive Story: Can It Work? Jonathan Knight General Interest CGDC95-035 Interactive Storytelling Chris Crawford General Interest CGDC95-036 Interfaces, Agents, and Game Design Denis Dyack General Interest CGDC95-037 Machines of Loving Grace Talin General Interest CGDC95-038 Making Music Motivate (without Sacrificing Your Soul or Sanity) Judy Munsen General Interest CGDC95-039 Manhattan Graphic Engine Eric Engstrom, Craig Eisler Technical CGDC95-040 Maximizing Windows Game Performance Chris Hecker Technical CGDC95-041 Metaphor Design: A Case Study Ken Kahn General Interest CGDC95-042 The Microsoft Speech API Mike Rozak Audio CGDC95-043 Nine Routes to Climax: the Bases of Interactive Storytelling Lawrence Schick General Interest CGDC95-045 Online vs. the Superhighway Richard Mulligan Online/Network CGDC95-046 Pencils vs. Pixels: 2D Animation for Multimedia Bridget Erdmann Visual Arts CGDC95-047 Programming the Sega 32X Jesse Taylor Technical CGDC95-048 Programming the 3DO (Opera) Al Chang Technical CGDC95-049 The Quest for Realism Ned Lerner General Interest CGDC95-050 Realtime 3D on the PC: When? Rob Glidden Technical CGDC95-051 Shoestring Marketing: Hard-Won Lessons Mike Dornbrook Business CGDC95-052 Should I Design for ITV? Sam Palahnuk General Interest CGDC95-053 Software Development Models Leo Hourvitz Management CGDC95-054 The Status of the Industry: 1995 & 1996 Lee Isgur Business CGDC95-056 3D Hardware Acceleration Standards Michael Abrash Technical CGDC95-057 Traditional Animators in Game Industry: How to Find & Use Them Pamela Kleibrink Thompson Management CGDC95-058 Treasures & Quagmires: The Internet as a Developer’s Resource Phillip King Online/Network CGDC95-059 Using DCI 2.0 for Fast Game Performance Ken Rhodes Technical CGDC95-060 Using Illusion and Deception in Game Design Walt Freitag General Interest CGDC95-061 Using the RSAC Rating System Rec. Software Advisory Council Special Interest CGDC95-062 VR Development for Head-Mounted Displays Joanna Alexander, Mark Long Technical CGDC95-063 Wannabe Seminar: Getting Inside while Staying Alive on the Outside Neil Kirby Special Interest CGDC95-064 War Stories: The Making of Shock Wave Michael Becker General Interest CGDC95-065 What the Hollywood Model Doesn’t Tell Us about Interactive Video Philip Bouchard General Interest CGDC95-066 When Teams Work, When Teams Break Don Daglow Management CGDC95-067 Working with Talent Unions Carol Contes Business CGDC95-068 The Writers’ Panel C. Marx, Michele Em, K. Lawrence General Interest CGDC95-069 Writing Great Windows 95 Games A.St. John, G.Dahl, M.Van Flandern Technical CGDC95-070 Alias PowerPlay for Game Developers Alias Technical CGDC95-071 The Battle beyond the Bits and Polygons Trip Hawkins, 3DO General Interest CGDC95-072 BRender: The Realtime 3D Rendering System for Games Jez San, Argonaut Technologies Technical CGDC95-073 BtV Multimedia Chipset from Brooktree Brooktree Corporation Technical CGDC95-074 The Business of Macintosh Games Eric Klein, Apple Business CGDC95-075 Create Windows Games under the Microsoft Home Brand Stuart Moulder, Microsoft Business CGDC95-076 Developing and Debugging with the Windows 95 Game SDK ATI Technologies Technical CGDC95-077 Developing Killer Games for PowerMacintosh Eric Klein, Apple Technical CGDC95-078 Enhancing Audio: No Longer an Afterthought Intel Corporation Audio CGDC95-079 Fast 3D Graphics on the PC Dave Clark, Intel Corporation Technical CGDC95-080 Full-Screen Video on the PC Intel Corporation Technical CGDC95-081 GamePC Consortium Meeting: the Windows 95 Game SDK ATI Technologies Special Interest CGDC95-082 Hear the Difference! ESS Technology, Inc. Audio CGDC95-083 High-End Computer Graphics Tools: Going Beyond Asset Creation Wavefront Technologies Technical CGDC95-084 IBM Speech Recognition: How Does It Work? IBM Technical CGDC95-085 IBM Speech Recognition: What Is It? IBM Audio CGDC95-086 Interfacing to Virtual Reality Devices on the PC Forte Technical CGDC95-087 An Introduction to Programming 3D Games Criterion Software Technical CGDC95-088 Multimedia Technology from Yamaha Yamaha Technical CGDC95-089 Network Gaming Catapult Entertainment Online/Network CGDC95-090 Next-Generation Game Controllers Advanced Gravis Technical CGDC95-092 Origin: Not Just Ultima and Wing Commander Origin Systems General Interest CGDC95-093 OS/2 as a Viable PC Games Platform: Part 1 IBM Business CGDC95-094 OS/2 as a Viable PC Games Platform: Part 2 IBM Technical CGDC95-095 Realtime 3D Graphics Development on Multiple Platforms Gemini Technology Corporation Technical CGDC95-096 Storytelling for the 21st Century Silicon Studio, Inc. Technical CGDC95-097 3D Studio: The Latest Developments Autodesk, Inc. Visual Arts CGDC95-099 Windows 95 and the Consumer Entertainment Market Microsoft Business CGDC95-100 Windows 95 DirectSound APIs Microsoft Audio CGDC95-101 Writing Network Games for Windows 95 Microsoft Online/Network CGDC95-102 Adventure Games Hal Barwood Special Interest CGDC95-103 Caught between Two Shores B. Bates, C. Cole, L. Cole Management CGDC95-104 Coin-Ops John Salwitz Special Interest CGDC95-105 Designing by Committee Raymond Benson Management CGDC95-106 Digitizing Video: Technical Issues Jerry L. Newton Technical CGDC95-107 Fantasy Roleplaying Games Cathryn Mataga Special Interest CGDC95-108 Geeks vs. Suits, Round 1 Anthony L. Farmer General Interest CGDC95-109 Legal Problems Charles Kramer Business CGDC95-110 MUDs (MultiUser Dungeons) Dr. Cat Online/Network CGDC95-111 Multiplayer & Family Games Danielle Berry General Interest CGDC95-112 Multiplayer Modem Games Dan Hite Special Interest CGDC95-113 On-Line Multiplayer Games Carrie Washburn Online/Network CGDC95-114 Primary Education Software Karen Crowther Edutainment/Education CGDC95-115 Programming the 3DO (Opera) Neil Cormia Technical CGDC95-116 Puzzle Games Michael Sandige Special Interest CGDC95-117 Secondary Education Software Rob Harris Edutainment/Education CGDC95-118 Sex & Violence Johnny Wilson General Interest CGDC95-119 Simulations & Simulators Gordon Walton Special Interest CGDC95-120 Social Responsibility Steve Peterson General Interest CGDC95-121 Sports Games Happy Keller Special Interest CGDC95-122 Successful Game A. I. Jon Freeman Special Interest CGDC95-123 3D Modeling Josh White Visual Arts CGDC95-124 Too Valuable to Promote? Kevin Furry Management CGDC95-125 The Wannabe Roundtable Neil Kirby Special Interest CGDC95-126 Wargames Don Griffin Special Interest CGDC95-127 The Writers’ Roundtable C. Marx, Michele Em, K. Lawrence General Interest CGDC95-128 This years show even had IBM trying to get people to write games for OS/2 with their sponsored “OS/2 as a Viable PC Games Platform” sessions, I wonder how many developers were convinced because it certainly did not become a viable PC Games Platform and was competing with Windows 95 DirectX talks. I would love to see what content was presented at that, fantastic bit of game development history, what APIs were even shown off for OS/2?CGDC 1996This is the last year before it was sold to Miller Freeman for about 3 million dollars, now being run by a company many developers could feel the change in the conference becoming more corporate 5. So this will be the last conference with a presentation by Chris Crawford.Google Books claims to have the proceedings of the 1996 Computer Game Developers Conference in its library but it doesn’t seem to be possible to access its contents: Computer Game Developers’ Conference Conference Proceedings: March 30-April … - Google BooksThere were at least 234 talks at CGDC 1996 that to The KNOW-IT-ALL Audiovisual Library page on the audio recordings, they are listed in the table below: Title Presenter Notes Don’t Flip the Bozo Bit…and other Principles of Shipping Great Software on Time Jim McCarthy CGDC96-001 “Show, Don’t Tell”: Fundamentals of Interactive Design Noah Falstein  CGDC96-002 Design Errors of the Rich and Famous and How to Fix Them Barbara A. Lanza  CGDC96-003 Real AI, the Sequel: Pathfinding Bryan Stout  CGDC96-004 Legal Basics for the Game Development Business Gene K. Landy  CGDC96-005 Modern Development Strategies for On-line Gaming James M. Turner  CGDC96-006 Mathematics: The Soul of Puzzling in Games for Education and Exploration Michael Fellows  CGDC96-007 Hardware Innovation under DirectSound Campbell Stras  CGDC96-008 Software and Compatibility Testing Megan Quattrocchi & Jeanne Collins  CGDC96-009 The Hiring Process: How to Hire or be Hired Kay Sloan  CGDC96-010 Geeks vs. Suits Anthony Farmer  CGDC96-011 3D Art Tools Josh White  CGDC96-012 Developing Multilingual Products Aric Wilmunder  CGDC96-013 Voodoo Graphics by 3Dfx Interactive: Use the Hottest 3D Technology… Andy Keane, 3Dfx  CGDC96-014 Writing Applications for the Architecture Intel  CGDC96-015 Interactive 3D Audio: Coming to a PC Near You! Tim Bratton & Bill Windsor, Spatializer  CGDC96-016 The Point Is: The Social and Ontological Ramifications of the Web Brian Moriarty  CGDC96-017 Developing for the Sony Playstation Steve Ackroyd  CGDC96-018 The Basics of Interactive Drama Ben Calica  CGDC96-019 Improvisational Puppets, Actors, and Avatars Barbara Hayes-Roth  CGDC96-020 Software Maturity: Do Game Developers Really Need It? Larry Constantine  CGDC96-021 Strategies for Truly Interactive Animation Production Mark Netter & Nicole Tostevin  CGDC96-022 Managing the Complexity of the Interactive Entertainment Design Document Jared Freedman  CGDC96-023 Designing for Social Interaction Danielle Berry  CGDC96-024 The Changing Face of 3D Programming Brian Hook  CGDC96-025 Windows 95 Debate Michael Sandige  CGDC96-026 Product Development is from Jupiter, Marketing is from Uranus Steve Peterson  CGDC96-027 AI in Strategy & Military Games Phil Steinmeyer  CGDC96-028 Music Roundtable Donald Griffin  CGDC96-029 Multiplayer Games Brian Hammerstein  CGDC96-030 3D StudioMax: The Next Generation of Modeling & Animation Tools Philp Miller, Autodesk  CGDC96-031 Writing Applications for the Intel Architecture: Audio Intel  CGDC96-032 Animation Master Jeff Bunker, Hash Inc.  CGDC96-033 Windows Programming Fundamentals   CGDC96-034 Artificial Gossip Chris Crawford  CGDC96-035 Real AI for Real Games, Part 1: Technical Tutorial and Design Practice Dr. Walter Alden Tackett  CGDC96-036 Creating Dazzling Sound Effects Rob Wallace  CGDC96-037 The Emerging Design Grammar of VR Games Mark Long & Joanna Alexander  CGDC96-038 When Teams Work, When Teams Break Don L. Daglow  CGDC96-039 Riding the Speeding Train: Controlling the Design Process Amanda Crispel  CGDC96-040 Living in a 256 World Merrill Nix  CGDC96-041 Big Brother in the 21st Century Kevin Cheung  CGDC96-042 Financing Alternatives Dean Gloster  CGDC96-043 Developing for New Technologies Theodore Beale & Andrew Lunstad  CGDC96-044 Edutainment Design Tom Guthery  CGDC96-045 Writing Workshops for Computer Games Katherine Lawrence  CGDC96-046 Story vs. Gameplay Raymond Benson  CGDC96-047 DirectPlay: Protocol Independent Multiplayer Games Donna Scott & G. Eric Engstrom, Microsoft  CGDC96-048 Analog Devices   CGDC96-049 Writing Applications for the Intel Architecture: Video Intel  CGDC96-050 Using COM to Develop Games in Delphi and Borland C++ Charles Calvert & Lar Mader, Borland Int  CGDC96-051 Diamond Developer Relations Program Gary Kinsey, Diamond Multimedia  CGDC96-052 The Making of the 11th Hour Robert Stein III & David Wheeler  CGDC96-053 Video Current Issues in Licensing & Royalty Rates Brian Napper  CGDC96-054 Real AI for Real Games, Part 2: Design Practice and Demonstrations Dr. Walter Alden Tackett  CGDC96-055 The Nine Act Story Structure, Part 1 David Siegel  CGDC96-056 Female is a Six-letter Word Laura Groppe  CGDC96-057 Win 32 Game Development Under Win 95, Part 1 Ed Averill  CGDC96-058 Interactive Audio on the Bleeding Edge Donald S. Griffin  CGDC96-059 The Future of the Gaming Industry Eric Pinnell  CGDC96-060 Coin-Ops Mark Pierce  CGDC96-061 Strategic Business Models for Development on the Internet Christopher Dean  CGDC96-062 Adventure Building for On-line RPGs Don McClure  CGDC96-063 Pre-Production Art Prep Arlin Robins  CGDC96-064 Adventure Games Hal Barwood  CGDC96-065 DirectSound: Low-latency Sound Mixing for Windows Bob Heddle & G. Eric Engstrom, Microsoft  CGDC96-066 Writing Applications for the Intel Architecture:3D Intel  CGDC96-067 Transforming the PC Ken Comstock, Diamond Multimedia  CGDC96-068 In Praise of Sex and Violence Ernest Adams  CGDC96-069 Producing Compelling Film/Video for Interactive Products Mark W. Day  CGDC96-070 From Concept to Contract: Making A Successful Product Pitch David Mullich  CGDC96-071 The Nine Act Story Structure, Part 2 David Siegel  CGDC96-072 The Implications of Live-Action for On-line Interactive Games John O’Neil  CGDC96-073 Win 32 Game Development Under Win 95, Part 2 Ed Averill  CGDC96-074 Surviving as a Full-Time Freelancer Mike Breault  CGDC96-075 Collaborating in Game Design Noah Falstein & David Fox  CGDC96-076 Legal Problems Charles Kramer  CGDC96-077 Working with Hollywood Talent Jim Bloom  CGDC96-078 Audio Forum Dominic Milano  CGDC96-079 Managing Programmers and Game Development Evan Robinson  CGDC96-080 Authoring Tools Hits and Misses Jamie Siglar  CGDC96-081 Primary Education Ann McCormick  CGDC96-082 SoftImage for NT: Imaging Power on the Desktop PC Microsoft  CGDC96-083 GrIP - Stop Playing with Yourself John Smith, Advanced Gravis  CGDC96-084 Writing Applications for the Intel Architecture: Optmizing Apps Intel  CGDC96-085 The Mirage Universal CD Emulator Guy Carpenter, Cross Products Ltd  CGDC96-086 Developing Great Windows 95 Game with Diamond Jon Burgstrom & Panel, Diamond Multimedia  CGDC96-087 “Psychic Detective” Solves the Mystery of Making the Interactive Film into a Game Michael Kaplan, John Sanborn & Jim Simmons  CGDC96-088 Owning and Protecting Intellectual Property Bruce Maximov  CGDC96-089 General MIDI Sound Cards? OK, Let’s Talk. George Alistair Sanger  CGDC96-090 3D & Video Asset Management: Establishing and Maintaining a Digital Prop Department Mark Peasley  CGDC96-091 Writing Bug-Free Games David Thielen  CGDC96-092 Marketing Slime: What Do They Want? Rick Reynolds & Robin Harper  CGDC96-093 Focused On-line Environments: The Next Experience Hans Bukow  CGDC96-094 Click-Smart: Some Considerations for the Design of Click-Ons in Educational Games Marv Westrom & Doug Super  CGDC96-095 Story vs. Gameplay Raymond Benson  CGDC96-096 Adventure Games Hal Barwood  CGDC96-097 Coin-Ops Mark Pierce  CGDC96-098 Developing for New Technologies Theodore Beale & Andrew Lunstad  CGDC96-099 Multiplayer Games Brian Hammerstein  CGDC96-100 Developing Multilingual Products Aric Wilmunder  CGDC96-101 Apple Game SDK, Part 1 - Intro, Overview and Future Directions Ben Calica, Apple  CGDC96-102 Advanced 3D-Interaction with the Spaceball Avenger (and Avenger II!) Adam Bosnian, Spacetec IMC Corp.  CGDC96-103 How to Bring your Games to the Internet, Via TEN William Lipa, Dave King & Greg Harper  CGDC96-104 3D Graphics - The Only Game in Town Steve Mosher, Creative Labs  CGDC96-105 Floating Point Performance Programming Techniques Chris Hecker  CGDC96-106 Building an On-line Gaming Service G. Eric Engstrom  CGDC96-107 Representing Human Characters in Interactive Games Greg Pisanich & Michael Prevost  CGDC96-108 Pixel Production: Pleasure or Pain? Steve Snyder  CGDC96-109 Keep ‘em Laughin’ AND Thinkin’: How to Design Great Kids’ Games Annie Fox  CGDC96-110 The Contractor-Publisher Relationship, From Both Sides Ellen Guon & Gano Haine  CGDC96-111 Developing Immersive Interfaces: Lessons Learned Outside of Games David G. Shaw  CGDC96-112 Designing for Social Interaction Danielle Berry  CGDC96-113 Strategic Alliances Judy Lange  CGDC96-114 3D Art Tools Josh White  CGDC96-115 Music Roundtable Donald Griffin  CGDC96-116 Geeks vs. Suits Anthony Farmer  CGDC96-117 Alternative Financing Theodore Beale & Andrew Lunstad  CGDC96-118 Managing Programmers and Game Development Evan Robinson  CGDC96-119 Apple Game SDK, Part 2 - RAVE Mike Kelley, Apple  CGDC96-120 Voodoo Graphics by 3Dfx Interactive: Use the Industry’s Hottest 3D Technology… Andy Keane, 3Dfx  CGDC96-121 How to Bring your Games to the Internet, Via TEN William Lipa, Dave King & Greg Harper  CGDC96-122 PC Audio in the 90’s What to Listen For Dave Rossum & Eric Larsen, Creative Labs  CGDC96-123 The Invasion of the Hollywood Talent Pool Roger Holzberg & Howard Burkons  CGDC96-124 How to Appeal to the On-line Gamer Daniel Goldman  CGDC96-125 The Expanding Job of the Game Artist Leslie Pardew  CGDC96-126 Developing for the PC CD Guy Wright  CGDC96-127 Exploring New Worlds with QuickTime VR Peter Mackey  CGDC96-128 Successful Planning to Get Your Business Funded Gina Frye & Ann Winblad  CGDC96-129 Hard-won Lessons of a Veteran Game Marketer Michael Dornbrook  CGDC96-130 El Mariachi on the Mac: Game Development on a Shoestring Roger Kemper & Tom Kemper  CGDC96-131 Writing Workshops for Computer Games Katherine Lawrence  CGDC96-132 AI in Strategy & Military Games Phil Steinmeyer  CGDC96-133 Edutainment Design Tom Guthery  CGDC96-134 The Changing Face of 3D Programming Brian Hook  CGDC96-135 Audio Forum Dominic Milano  CGDC96-136 Authoring Tools Hits and Misses Jamie Siglar  CGDC96-137 Apple Game SDK, Part 3 - PowerPlug, PowerAmp and Speech Input Michael Evens & Dan Venolia, Apple  CGDC96-138 Building the Game of the Future ATI Technologies  CGDC96-139 Activation - Real-time 3D Graphics Software for Game Prototyping Bruce Sinclair, Coryphaeus  CGDC96-140 PowerVR: A Revolution in 3D Graphics Technology NEC Electronics  CGDC96-141 Statistics and Predictions for the Interactive Entertainment Industry Ruthann Quindlen  CGDC96-142 Writing Multiplayer Games for the Internet Jeffrey Rothschild  CGDC96-143 Choice, Control, and Consequence in Interactive Comedy Walter Freitag  CGDC96-144 Software Project Management C. Gordon Walton, Jr.  CGDC96-145 Virtual Sets: Creating High Quality Video/3D Composites Mark Giambruno  CGDC96-146 Four Ways to Play: Piaget’s Analysis of Common Childhood Games Erik Strommen  CGDC96-147 Getting the Most Out of 3D Accelerators Robert Mullis  CGDC96-148 Interactive 3D Audio: A New Dimension for Game Development Toni Schneider  CGDC96-149 The Hiring Process: How to Hire or be Hired Kay Sloan  CGDC96-150 Legal Problems Charles Kramer  CGDC96-151 Pre-Production Art Prep Arlin Robins  CGDC96-152 Financing Alternatives Dean Gloster  CGDC96-153 Software and Compatibility Testing Megan Quattrocchi & Jeanne Collins  CGDC96-154 Windows 95 Debate Michael Sandige  CGDC96-155 Apple Game SDK, Part 4 PowerPlay and PowerShow Jamie Osborne & Cary Farrier, Apple  CGDC96-156 Feel the RAGE: Experience ATI’s New Mach64-based 3D Accelerator ATI Technologies  CGDC96-157 The Quake Graphics Engine Michael Abrash  CGDC96-158 Developing for the Sega Saturn Marty Franz  CGDC96-159 The Breakthroughs and Pitfalls of Developing Interactive Drama Dexter Chow, Haney Armstrong & Ken Golfstein  CGDC96-160 Seven Ways to Avoid Getting Screwed Edward de Jong  CGDC96-161 2D Animation in 3D Worlds John Gaffey & Ray Manabe  CGDC96-162 Digital Joystick Protocols and Gaming Devices   CGDC96-163 Distribution Options for Today’s Market Bryan Neider  CGDC96-164 Some Design and Industry Pointers for Wannabe Coin-Op Developers Jeff Brown  CGDC96-165 Big Brother in the 21st Century Kevin Cheung  CGDC96-166 Adventure Building for On-line RPGs Don McClure  CGDC96-167 Product Development is from Jupiter, Marketing is from Uranus Steve Peterson  CGDC96-168 Working with Hollywood Talent Jim Bloom  CGDC96-169 Sports Games Kevin Hogan  CGDC96-170 Developing Multilingual Products Aric Wilmunder  CGDC96-171 The Business of Mac Games Mark Gavini, Apple  CGDC96-172 Firewalker Authoring System - Invent New Levels of 3D Interactivity Jeff Benrey & Sheila Ward, Silicon Studio  CGDC96-173 What Game Developers Need to Know About the New 3D Audio Paradigms Win Craft, David Bates & Dales Gulick, Spatializer  CGDC96-174 Interactive Movies Debate: Hot New Genre or Marketing Fluff? Ernest Adams & Jim Simmons  CGDC96-175 DOS Games in a Windows World David Thielen  CGDC96-176 Play & Learning: A Battle for Mindshare? Ann McCormick  CGDC96-177 Developing Windows Games for the Japanese Market James Spahn  CGDC96-178 Technical Aspects of On-line Development Kevin Cheung  CGDC96-179 Moving Mountains: Getting Animation and 3D Data into the Game Box Peter Ryce  CGDC96-180 Programming the M2 David Maynard  CGDC96-181 Audio Forum Dominic Milano  CGDC96-182 Sports Games Kevin Hogan  CGDC96-183 AI in Strategy & Military Games Phil Steinmeyer  CGDC96-184 Pre-Production Art Prep Arlin Robins  CGDC96-185 Geeks vs. Suits Anthony Farmer  CGDC96-186 Coin-Ops Mark Pierce  CGDC96-187 Voodoo Graphics by 3Dfx Interactive - Use the Industry’s Hottest 3D Technology Andy Keane, 3Dfx  CGDC96-188 Thexder Meets Win 95 or Writing Great Games in the Win 95 Environment Cheryl Makovsky  CGDC96-189 PC Network Games for Nearly Everyone Neil Kirby  CGDC96-190 Aristotle’s Dramatic Principles in the Interactive Medium Jim Simmons  CGDC96-191 Maximizing Shareware Success Karen Crowther  CGDC96-192 The Responsibility of the Author in Developing Storytelling Games Bob Bates  CGDC96-193 Breaking the Mold in Edutainment Design David Katzner  CGDC96-194 Tricks and Techniques for Sound Effect Design Bobby Prince  CGDC96-195 “Wargames Don’t Sell” or How to Actually Write Successful Wargames Mark Baldwin  CGDC96-196 Strategic Business Models for Development on the Internet Christopher Dean  CGDC96-197 3D Art Tools Josh White  CGDC96-198 Edutainment Design Tom Guthery  CGDC96-199 Managing Programmers and Game Development Evan Robinson  CGDC96-200 The Changing Face of 3D Programming Brian Hook  CGDC96-201 Legal Problems Charles Kramer  CGDC96-202 Multi-Player On-Line Gaming - Who? What? Where? Why? How? When? Konstantin Othmer, Catapult  CGDC96-203 Building Games for ATI’s 3D Rage ATI Technologies  CGDC96-204 Direct 3D: Device Independent Acceleration Servan Keondjian & G. Eric Engstrom, Microsoft  CGDC96-205 What is Interactive? A Rigorous Definition Stuart Moulder  CGDC96-206 Motion Capture: Replicating Reality Ken Kline  CGDC96-207 20th Century Scoring for Next Century Entertainment: A Call for Interactive Audio Design Dave Javelosa  CGDC96-208 Real-time 3D Modeling Josh White  CGDC96-209 The Art of the Deal Dean M. Gloster  CGDC96-210 Design Issues for On-line Virtual Communities and Playgrounds Ben Calica  CGDC96-211 A Nuts and Bolts Seminar on How To Direct and Help Actors Jeanne Hartman  CGDC96-212 Writing Workshops for Computer Games Katherine Lawrence  CGDC96-213 Adventure Building for On-line FRPGs Don McClure  CGDC96-214 Multiplayer Games Brian Hammerstein  CGDC96-215 Story vs. Gameplay Raymond Benson  CGDC96-216 Authoring Tools Hits and Misses Jamie Siglar  CGDC96-217 Working with Hollywood Talent Jim Bloom  CGDC96-218 Exporting Object and Animation Data to Multiple Platforms Dave Aronson, Nichimen Graphics  CGDC96-219 Optimizing Games for 3D Hardware 3D Labs  CGDC96-220 Five Simple Steps to the Perfect Model Jonathan Houston, Faro Technologies  CGDC96-221 DirectDraw: Highspeed BLTing in Windows Craig Eisler & G. Eric Engstrom, Microsoft  CGDC96-222 Developing a Cross-Platform Product Strategy John Kavanagh  CGDC96-223 3D Graphics and Animation for Real Time Games Gregory Hammond  CGDC96-224 The Evolving Internet: A Gaming Perspective Phillip King  CGDC96-225 A Story Wrapped Inside a Puzzle Wrapped Inside an Enigma: Designing Adventure Games Steven Meretzky  CGDC96-226 Utilizing Lawyers in Today’s Deal-making Environment Alisa Baker  CGDC96-227 How to Make Your Games Sell Overseas Juergen Egeling  CGDC96-228 Use of Voice in Interactive Products Wally Fields & Mike Bailey  CGDC96-229 Windows95 Debate Michael Sandige  CGDC96-230 Product Development is from Jupiter, Marketing is from Uranus Steve Peterson  CGDC96-231 Big Brother in the 21st Century Kevin Cheung  CGDC96-232 Adventure Games Hal Barwood  CGDC96-233 Software and Compatibility Testing Megan Quattrocchi & Jeanne Collins  CGDC96-234 Music Roundtable Donald Griffin  CGDC96-235 BRender: The Real-time 3D Rendering System for Games Jez San & Rich Seidner, Argonaut Technologies  CGDC96-236 Demystifying Motion Editing Bart Gawboy, Nichimen Graphics  CGDC96-237 Banquet Speaker Peter Bergman, Firesign Theatre  CGDC96-238 Here are the talks that have slides available online: The Quake Graphics Engine by Michael Abrash (Slides: CGDC Quake Talk) 1996 Computer Game Developer Conference The Making of the 11th Hour R. Stein and D. WeelerMaking of the 11th HourOn Archive.org a video recording of the session The Making of the 11th Hour by R. Stein and D. Weeler is available to watch here.It mentioned they were in the beta program for 3D Studio 3.0 which allowed them to do dual texture maps to add dirt to the textures, the video shows footage from 3D Studio 3.0.CGDC 1997 - April 25th-29thThe 1997 Computer Game Developers Conference was hosted in the Santa Clara Conference Center in Washington, D.C. It was much larger in scope than the previous years and in fact took five days instead of the usual two.The first 2 days introduced two new sub-conferences: Managing Game Development Conference (25th/26th) Game Marketing and Distribution Conference (25th/26th)The Classic CGDC Conference would then take the next three days (27th-29th).The overall attendees was estimated to be over 6,300 by the July 1997 issue of Next Generation Magazine.Two Day TutorialsThis conference introduced what they called the Two Day Tutorials which were tutorials on various software that would take up the full first two days of the conference, presumably for those uninterested in the other two sub-conferences going on at the same time.There were four of them but no other details apart from their name remain online: Softimage Game Development Tools and Techniques Object Oriented Game Design in Lingo 3D Studio Max Creating Online Games with JavaOne Day TutorialsThese tutorials only took a day to complete and were all on the 26th of April, they were: Modeling, Texturing, and Animating in Alias Poweranimator for Real-Time Applications The Producer’s Tutorial: Bringing it All Together Programming Games Under Windows Writing for an Interactive Age Using DeBabilizer for Processing Video Game Graphics Writing Games with OpenGLSadly the website didn’t list who actually presented these tutorials but if you know please submit a Pull Request or leave a comment below.Game Marketing and Distribution ConferenceThe first day talks were: Going Global: Worldwide Strategies for International Markets Breaking Into the Chinese Market: Market Entry, Publishing and Distribution of CD-Rom Titles in China Distribution Standards for the Game Industry Internet Entertainment: The Profits and the Pitfalls Packaging Licensing How To Win At Distribution The State of the Post-Christmas Game Market Online Marketing Strategies Games for Promotional Purposes: The Business of Business Games Leveraging 3D in Your Marketing Plan Building on SuccessThe second day talks were: Market Research Boot Camp How to Create Branded Products That Cover Multiple Media Educating the Retailer Distribution Options For Today’s Market Legal Issues In Online Distribution: Warnings About Unresolved Issues Strategic Pricing Maximizing Your Online Presence Working With Developers Breaking into Latin American Markets Retailers Talk Back Brand Management: CD-ROM into Film Changing the Face of Interactive Entertainment Shaping the Interactive Software Market for the New MilleniumPretty much nothing is available online about who gave these talks or what they contained.Managing Game Development ConferenceThe first day talks were: Team == Software Lucid Ignorance Bullshit Management Meetings That Don’t Suck Enrapturing the Customer Building That “Shared Vision Thing”The Day 2 talks were: Facing the Black Hats: Strategies for dealing with Management Being the Black Hats: Managing People Who Give a Shit Where Am I: Finding Yourself in Software The Deeper Problem: Breaking the Loop of Failure Thinking Fishbowl Creativity Shop: A Kick in Your Mental Ass Leading a Quality JihadPretty much nothing is available online about who gave these talks or what they contained.Classic CGDC ConferenceThe Classic CGDC Conference had 200+ different sessions split up into the following four types: Lectures - Typical Conference presentation format with Powerpoint Slides Seminars - More hands on than Lectures Roundtables - Panel of experts talking about a specific talking and maybe answering audience questions Sponsored Sessions - Presumably lectures that were not voted on but instead paid to presentAll the talks from the two days of the “Classic” Computer Developers Conference are in the table below. If you know of any links to videos, slides, reviews or even notes from any of the sessions please add them to the Notes column in the table. Title Presenter Type Notes The Creative Role of the Producer: Lessons from Linear Media David Brownstein Lecture   Internet Based Client/Server Network Traffic Reduction Bernt Habermeier Lecture   Listen! The Potential of Shared Hallucinations Brian Moriarty Lecture   Making Things Fun to Learn: Principles of Edutainment Design Craig Brannon Lecture   Opening the Box; 3D Toolkits John Gwinner Lecture   Real AI, Part III: Planning Bryan Stout Lecture   Strategic Pricing Phil Adam Lecture   Understanding the Process of Art Production Phil Trumbo Seminar   More Ways to Avoid Getting Screwed Edward de Jong Seminar   Downloadable Sounds: The Next Wave in Multimedia Audio Delivery Tom White Seminar   Ask the Publisher Ken Goldstein Roundtable   Choosing an Authoring Tool Jamie Siglar Roundtable   Designing and Building Multiplayer Action Titles for Internet Play Harald Seely Roundtable   Designing Games to Use 3D Audio Brian Schmidt Roundtable   How to Screw Up a Perfectly Good Production Heather Chirtea Roundtable   Multiplayer Online Games Carrie Washburn Roundtable   Original Content: R&D For The Breakthrough Title Larry Tuch Roundtable   Shared Virtual Environments David Rosenbloom Roundtable   What Do Female Game Players Really Want? Annie Fox Roundtable   What Makes Software Educational? Channah Horst Roundtable   Whither (or Wither) War Games Mark Baldwin Roundtable   Windows 95: Stories from the Trenches Jack Thornton Roundtable   A3D: Interactive 3D Audio Workshop Aureal Semiconductor Sponsored Session   Leveraging the Voodoo Platform in Next Generation Game Development 3Dfx Interactive, Inc. Sponsored Session   DirectPlay Microsoft Sponsored Session   Application of Motion Capture to Interactive Entertainment Paul Lewis Lecture   Better Audio Sells More Product James Grunke Lecture   Coin-Op Arcade Videogames: An overview of the Coin-Op Industry Mark Pierce Lecture   Cross Promotion and Product Placement in Video Games Rich Shane Lecture   Event Based Design: An Action Adventure Game Approach Jared Freedman Lecture   Interactive Playmates in Real Time or Why Online Games Suck Dani Bunten Berry Lecture   Optimizing Direct3D Graphics Performance Miriam Sedman Lecture   Pixel Production: Pleasure or Pain? Steve Snyder Lecture   Surviving the Bloodbath: Perspectives on our Industry’s Cycles Michael Dornbrook Lecture   Inside NHL Powerplay 96: What Are They Thinking? David Roberts Seminar   When Teams Work, When Teams Break Don Daglow Seminar   Art in Computer Games: Tools and Techniques Denis Loubet Roundtable   Designing Online Puzzle Games Scott Kim Roundtable   Directors Roundtable: What Do They Mean? What Do They Want? Jeanne Hartman Roundtable   Discussion on Artificial Intelligence in Computer Games (Section 1) Steve Woodcock Roundtable   Discussion on Artificial Intelligence in Computer Games (Section 2) Eric Dybsand Roundtable   Discussion on Artificial Intelligence in Computer Games (Section 3) Neil Kirby Roundtable   Environment vs. the Game: Is the Medium or the Content? What Keeps Them? Susan Manley, Jim Stern Roundtable   The Future of Strategy Games Phil Steinmeyer Roundtable   Geeks vs. Suits 3.0 Anthony Farmer Roundtable   Good, Clean and Fun: How Can They All Go Together? Brad Andrews Roundtable   New World, New Paradigms: The Frontier of Multiplayer Non Zero-Sum Entertainmen Sean Patrick Fannon Roundtable   Puzzles in Adventure Games Hal Barwood Roundtable   Testing Roundtable Jeanne Collins , Megan Quattrocchi Roundtable   Visceral Gaming: Should We Be Afraid? Paul Schuytema Roundtable   Developing Game Content for Multiple Platforms Nichimen Graphics Sponsored Session   Leveraging the Voodoo Platform in Next Generation Game Development 3Dfx Interactive, Inc. Sponsored Session   DirectInput Microsoft Sponsored Session   The Art Of The Pitch Heather Chirtea , Ken Goldstein , Stefanie Henning Lecture   Autonomous Agents: A Matter of Life and Death Peter de Bourcier Lecture   Avatars and Chat: Improving Immersive Interfaces David Shaw Lecture   How to Write Interactive Fiction Howard Burkons , Michelle Em , Rick Tiberi Lecture   Interactive Soap Operas: Crafting Environments for Multiuser Interaction Reid Hoffman Lecture   The Jack Principles: Change the Way You Think About Interactive Design Harry Gottlieb Lecture   Optimizing Code with MMX Mike Schmit Lecture   Real-Time 3D Animation Greg Hammond Lecture   State of the Industry Lee Isgur Lecture   Writing Bug-Free Games Dave Thielen Lecture   Writing by Design: The Critical Path to Great Gameplay Roger Holzberg, Larry Tuch, Terry Borst, Howard Cushnir, Ted Elliot, Adam Wolff Lecture   Entertainment Quality Comes of Age Diannah Morgan Seminar   Interactive Soundworlds Daniel Bernstein Seminar   3D Acceleration, One Year After Brian Hook Roundtable   Business Models for Maximizing Revenue from Online Games Kirk Owen Roundtable   Database Development for Real-Time 3D Games Gjon Camaj Roundtable   Designing and Building Multiplayer Action Titles for Internet Play Harald Seely Roundtable   Designing Multiplayer Games Kevin Bentley Roundtable   Developing for New Technologies Theodore Beale , Andrew Lunstad Roundtable   Discussion of Real-Time 3D Modeling Evan Fisher , Jordi Davis Roundtable   The Interactive Storytelling Problem W alt Freitag Roundtable   Multiplayer Online Games Carrie Washburn Roundtable   The Real Design: From Design Spec to Product Christopher Thompson Roundtable   Real-Time Audience Feedback: What Should We Do With It? Dr. Cat Roundtable   “Relevant” Music Scoring for Next Generation Games Rich Goldman Roundtable   Force Feedback - How to Add Another Dimension to Your Games by Microsoft Sidewinder Group Microsoft (HW) Sponsored Session   Internet Business Opportunities for Multiplayer Games Mpath Sponsored Session   High-End Graphics Delivered on Real-Time Platforms Alias Wavefront Sponsored Session   Advanced Real-Time 3D Modeling Josh White Lecture   Bringing Design to Software Terry Winograd Lecture   Cinematic Direction in Interactive Products Lawrence Guterman Lecture   Client/Server Design for Online Games Andrew Kirmse Lecture   Designing the Puzzle Bob Bates Lecture   Fair Use: Technology and Content Marc Brown, Simon Frankel Lecture   Government Report 97: Impact on Game Developers Daniel Greenberg Lecture   Mass Market Interactive Entertainment: The New Art Form Hal Barwood , Roger Holzberg , Kendall Lockhart, Richard Hilleman, Brett Sperry Lecture   Multiplayer Web Games on a Shoestring James Abbott Lecture   Music on Computers: A 5 Year Projection from the “Project Bar-B-Q” Think Tank George Alistair Sanger Lecture   On Time and Under Budget William Volk Lecture   Taking Maximum Advantage of 3D Hardware Accelerators Mike Newhall Lecture   OO Is So Good Glenn Mandelkern Seminar   Artists vs. Programmers Dave Menconi Roundtable   Designing for Community: How to Handle the Problem Children of the Online World Dave Weinstein Roundtable   The Future of Sports Game Development Michael Meischeid Roundtable   Game Worlds: Slouching Toward a True Mass Audience Jeff Gomez Roundtable   Getting Into the Game Industry Darren Reid Roundtable   Localization Aric Wilmunder Roundtable   What Do Female Game Players Really Want? Annie Fox Roundtable   “Why Won’t They Tell Me What They Want!” Real World Communication Between Musician and Producer David Schultz Roundtable   Wavetable: Ubiquitous Platform?!? Creative Labs Sponsored Session   Creating Your Own Private Branded Online Gaming Service Around Your Content Mpath Interactive Sponsored Session   Working with Microsoft “In The Zone” Microsoft (HW) Sponsored Session   Total Exposure: Reaching Millions via One Company Partner The ImagiNation Network Sponsored Session   The Best Kept Secrets of Digital Art Dale Mauk, Patricia Pearson Lecture   Humor in Game Design Steven Meretzky Lecture   Into the Grey Zone and Beyond: Protecting Your Legal Interests in the New Multimedia Environment Alisa Baker Lecture   Merc 101: Sim Game Design - Features and Research Arnold Hendrick Lecture   A Very Geeky Overview of TCP/IP Protocols Zachary Simpson Lecture   VRML for Games? Alan Wooton Lecture   Writing a Successful Business Plan Anne Winblad Lecture   The Dirt on DVD Guy Wright Seminar   Getting Started in Interactive Audio Donald S. Griffin Seminar   How Not to do Videocompositing and Effects Mark Christiansen Seminar   Mass Participation Games on the Web: Delivering Web Games that Support Thousands Leonard Quam Seminar   Rules to Live By: Mantras for Software Producers Martin Streicher Seminar   Art in Computer Games: Tools and Techniques Denis Loubet Roundtable   Database Development for Real-Time 3D Games Gjon Camaj Roundtable   Designing Multiplayer Games Kevin Bentley Roundtable   Localization Aric Wilmunder Roundtable   Getting Into the Game Industry Darren Reid Roundtable   Puzzles in Adventure Games Hal Barwood Roundtable   Real-Time Audience Feedback: What Should We Do With It? Dr. Cat Roundtable   “Relevant” Music Scoring for Next Generation Games Rich Goldman Roundtable   Programming for 3Dfx Interactive Voodoo 3Dfx Interactive, Inc. Sponsored Session   QMixer: A Highly Efficient 3D Audio SDK for Direct X and MacOS QSound Labs Sponsored Session   Optimizing 3D Geometry and Lighting Performance of PC’s Intel Corporation Sponsored Session   Force Feedback - How to Add Another Dimension to Your Games by Microsoft Sidewinder Group Microsoft (HW) Sponsored Session   c:\\media\\games\\online\\bizmodels.exe or Online Games: Multiple Business Models TEN Sponsored Session   Metrowerks Game Programming Tools Metrowerks Corporation Sponsored Session   Cinematic Audio for Video Tim Clarke , Christopher Stevens Lecture   The Little Four: Panel Discussion with Low Latency Gaming Networks Dean Frost , Jack Heistand , Jeff Leibowitz , Paul Matteucci , John Taylor Lecture   Maintaining Developer-Media Relations through the Development Cycle Mark Shander Lecture   Merc 201: Sim Game Design - Nuts and Bolts Arnold Hendrick Lecture   Ritual Reality: The Social Aspects of Designing an Online Gaming Environment Amy Jo Kim Lecture   Strategic Alliances Jude Lange Lecture   The Talkies Are Coming! William DeSmedt Lecture   Adding Extensible Custom Languages to Game Engines Robert Huebner Seminar   Art Direction For Games Isaac Kerlow Seminar   Cyberlife: A Biologically Inspired Architecture for Games Toby Simpson Seminar   Physical Animation of Humans and Other Articulated Forms Seamus Blackley Seminar   3D Acceleration, One Year After Brian Hook Roundtable   Ask the Publisher Ken Goldstein Roundtable   Directors Roundtable: What Do They Mean? What Do They Want? Jeanne Hartman Roundtable   The Integration of Cinematic Elements Into Interactive Games Jim Bloom Roundtable   The Interactive Storytelling Problem Walt Freitag Roundtable   The Real Design: From Design Spec to Product Christopher Thompson Roundtable   What Do Female Game Players Really Want? Annie Fox Roundtable   What Makes Software Educational? Channah Horst Roundtable   Windows 95: Stories from the Trenches Jack Thornton Roundtable   Programming for 3Dfx Interactive Voodoo 3Dfx Interactive, Inc. Sponsored Session   Qsound 3D Audio Processing Tools Schmidt Entertainment Technologies, Inc. Sponsored Session   Scaleable 3D Sound Using MMX Technology Intel Corporation Sponsored Session   Working with Microsoft “In The Zone” Microsoft (HW) Sponsored Session   Implementing Compelling 3D Audio Today and Tomorrow VLSI Technology, Inc. Sponsored Session   Creating a Multiplayer Gaming Success HEAT Sponsored Session   Adapting Licensed Products to the Computer Medium Micah Jackson Lecture   Communication Models for Internet Games Jeffrey Rothschild Lecture   Distribution Options For Today’s Market Brian Neider Lecture   The Magic of Writing Kids’ Games Matthew Costello, Tony Perutz, Meryl Perutz, Deborah Todd Lecture   Making 3D Work for Social Environments Rusty Dawe Lecture   Quake: A Post-Mortem and a Glimpse Into the Future Michael Abrash Lecture   Raising the Bar Leslie Pardew Seminar   Women In Interactive Entertainment Deborah Cook, Annie Fox , Julie Marsh, Margo Nanny, Hilary Nation, Solange Van Der Moer Seminar   Business Models for Maximizing Revenue from Online Games Kirk Owen Roundtable   Designing and Building Multiplayer Action Titles for Internet Play Harald Seely Roundtable   Designing for Community: How to Handle the Problem Children of the Online World Dave Weinstein Roundtable   Designing Games to Use 3D Audio Brian Schmidt Roundtable   Directors Roundtable: What Do They Mean? What Do They Want? Jeanne Hartman Roundtable   Environment vs. the Game: Is the Medium or the Content? What Keeps Them? Susan Manley, Jim Stern Roundtable   Good, Clean and Fun: How Can They All Go Together? Brad Andrews Roundtable   Multiplayer Online Games Carrie Washburn Roundtable   Original Content: R&D For The Breakthrough Title Larry Tuch Roundtable   Shared Virtual Environments David Rosenbloom Roundtable   Visceral Gaming: Should We Be Afraid? Paul Schuytema Roundtable   Whither (or Wither) War Games Mark Baldwin Roundtable   The Benefits of 3D Graphics By Using MMX Technology Intel Corporation Sponsored Session   Benchmarks: Do They Do Justice? 3Dfx Interactive, Inc. Sponsored Session   DirectDraw in DX5 Microsoft Sponsored Session   Video Reality Reality GC: Creating Navigable Feature Film Environments SouthPeak Interactive Sponsored Session   Quicktime for Windows as a Media Delivery Engine for Games Apple Computer Sponsored Session   Creating a Multiplayer Gaming Success HEAT Sponsored Session   Achieving New Levels of Realism with Image Based Modeling and Rendering Paul Debevec Lecture   The Alchemy of Addiction: Creating Games that Keep People Playing Mike Sellers Lecture   Color Reduction TBA Lecture Did this go ahead? Who did it? Foundations and Empires Mark Baldwin Lecture   Recovery Mode: Taking Control of an Out of Control Project Evan Robinson Lecture   Revenue Models for Net-Based Games Gene DeRose Lecture   Writing First Person Engines for 3D Hardware Gary McTaggart Lecture   Dirty Little Programs: Installing and Removing Your Product Andrew Megowan Seminar   Music Construction for Interactive Media Donald S. Griffin Seminar   Designing Online Puzzle Games Scott Kim Roundtable   Developing for New Technologies Theodore Beale , Andrew Lunstad Roundtable   Discussion of Real-Time 3D Modeling Josh White Roundtable   Discussion on Artificial Intelligence in Computer Games (Section 1) Steve Woodcock Roundtable   Discussion on Artificial Intelligence in Computer Games (Section 2) Eric Dybsand Roundtable   Discussion on Artificial Intelligence in Computer Games (Section 3) Neil Kirby Roundtable   The Future of Strategy Games Phil Steinmeyer Roundtable   How to Screw Up a Perfectly Good Production Heather Chirtea Roundtable   New World, New Paradigms: The Frontier of Multiplayer Non Zero-Sum Entertainment Sean Patrick Fannon Roundtable   Testing Roundtable Jeanne Collins , Megan Quattrocchi Roundtable   Software Interfacing Techniques for Accelerated Graphics Port Intel Corporation Sponsored Session   Next Generation PC Platforms: How to Leverage the Transition Cirrus Logic Sponsored Session   Direct3D Microsoft Sponsored Session   A3D: Interactive 3D Audio Workshop Aureal Semiconductor Sponsored Session   POW! Adding Force-Feedback to Your Applications Immersion Corp Sponsored Session   Implementing AGP Using ATI’s RAGE PRO Graphics Chip ATI Technologies Sponsored Session   Collaborating in Game Design Noah Falstein, David Fox Lecture   From Spelling To Surfing: The Evolution of the Edutainment Industry Joe Durrett , Dean Frost , Steve McBeth , Kevin O’Leary , Charlotte Walker Lecture   Grass Isn’t <0,255,0>: Better Living Through Color Theory John Edel Lecture   A Guided Tour through Hard Core Game Physics Chris Hecker Lecture   Negotiating a Great Game Publishing or Distribution Deal Dean Gloster Lecture   Worldwide Licensing and Funding of Titles Jack Ghoulian Lecture   Designing for the Universal 2nd Grader Michael Wyman Seminar   Forcing Interactions: How to? How much Richard Aronson Seminar   User Intention as a Design Tool Doug Church Seminar   Artists vs. Programmers Dave Menconi Roundtable   Choosing an Authoring Tool Jamie Siglar Roundtable   Coin Ops Roundtable Mark Pierce Roundtable   The Future of Sports Game Development Michael Meischeid Roundtable   Game Worlds: Slouching Toward a True Mass Audience Jeff Gomez Roundtable   What Ever Happened to Role-Playing Games? Anthony Farmer Roundtable   “Why Won’t They Tell Me What They Want!” Real World Communication Between Musician and Producer David Schultz Roundtable   How To Build Internet Hybrid Games Intel Corporation Sponsored Session   Catering to the Sound Sense: How to Use DirectSound3D to Enhance a 2D or 3D Game Cirrus Logic Sponsored Session   DirectSound Microsoft Sponsored Session   Memory Efficient Color Mapping Techniques for Game Development Nichimen Graphics Sponsored Session   ATI’s Hi-Volume RAGE PRO Graphics Chip ATI Technologies Sponsored Session   For me some of the most interesting sessions from this day were the Sponsored Sessions presented by Industry Heavyweights that are still household gaming names today and others who have fallen by the wayside (Nichimen Graphics, I am looking at you!).Microsoft DirectX SessionsMicrosoft had sessions advertising their DirectX technology (DirectPlay, DirectSound, Direct3D and DirectDraw) and even from their hardware division (Sidewinder Group).Apple back in the games industry in 1998?There was even a session by Apple on using Quicktime for Windows Game Development! Would love to get a hold of what was presented at that session.GDC 1998 - May 4th-8thThe 1998 Computer Game Developers Conference was hosted in Long Beach Convention Center on Long Beach, California. This would be the last one under the CGDC name as it was now rebranded to just GDC 6.Playstation Underground had a brief 3 minute look at CGDC 1998, it interviews Jennifer Pahlka who was a female director of the GDC, you can watch on Youtube:The talks we know that were held at CGDC 1998 are in the table below: Title Presenter Track Type Notes “A Formula Is Worth a Thousand Keyframes” Mathematically Derived Real Time Character Animation Peter Akemann Programming Lecture   3D Controllers One Year Later: What Have Learned? What Have We Earned? Tom Cmajdalka, Frank Evers, Jon Peddie, Jay Eishenlohr, Scott Sellers Programming Lecture   Blazing Fast Code Jon Bentley Programming Keynote   Bringing Engineering Discipline to Entertainment Development Gordon Walton Programming Seminar   Bringing Your Code Up to Speed Ron Fosner Programming Lecture   Building a Better Mouse: AI Lessons From Artificial Life Robert Huebner Programming Lecture   Building Advanced Autonomous AI Systems for Large Scale Real-Time Simulations John Laird Programming Lecture   Building Commercial Games in Java: How We Did It Garner Halloran Programming Lecture Tom Clancy’s Politika Coding the Ideal Direct3D Game Richard Huddy Programming Sponsored   Collecting Money on the Internet: Gameplay by the Click Russ Jones Programming Sponsored   Collision Detection in Pacman Ghost Zone: Collision Techniques in a 3D Environment for Man and Camera Gilbert Colgate Programming Lecture   Creating Realistic Effects with OpenGL Simon Hui Programming Lecture   Cross Platform Development : Easier and Harder Than You Think Eric Klein Programming Lecture   Curved Surfaces vs. Discrete Multiresolution Models Murali Sundaresan Programming Lecture   Database Development for Real-Time 3D Games: A View From Both Sides Gjon Camaj Programming Lecture   Development Tools: Shines & Whines David Gill Programming Sponsored   DirectAnimation Pablo Fernicola Programming Sponsored   DirectShow Kevin Larkin Programming Sponsored   Display List Rendering Marc Pinter-Krainer Programming Sponsored   Efficient System Memory Texturing Architecture for Games John Brothers, Ray Koduri Programming Sponsored   Engine Scalability and 3D Hardware Charlie Brown, Gary McTaggart Programming Lecture   Exploiting Parallelism in 3D Games Using a Multithreaded Game Application Framework Feng Xie Programming Sponsored   Gaming and Multimedia Graphics on Windows CE: A Case Study David Gould Programming Sponsored   Getting the Most Out of 3D Accelerators Greg Corson Programming Lecture   Hardcore AI for the Computer Games of Tomorrow John Funge Programming Lecture   High Color, High Res: Graphics Programming in a Non-Palletized World Wade Brainerd Programming Lecture   High Performance Game Programming in C++ Paul Pedriana Programming Lecture   How Bout Dem Bones: Creating a Bones-Based Animation System Andrew Lunstad Programming Lecture   How Shadows of the Empire Used the Force Gary Brubaker Programming Lecture   Improving Graphics Performance Using iPEAK Herb Marsales Programming Sponsored iPeak Intel740 Graphics Accelerator Performance Tuning Theodore Omtzigt, Jay Sturges Sponsored     Lies, Damn Lies, and ASR Statistics: A Voice Processing Primer Neil Kirby Programming Seminar Slides on CD Low Cost 3D Graphics for Independent Game Developers Caligari Programming Sponsored truespace4 Making the Play: Team Cooperation in Microsoft Baseball 3D Steve Rabin Programming Lecture   Maximizing Real-Time Game Performance Robert “Dwango Bob” Huntley Programming Sponsored   Messiah: What You May or May Not Believe Michael “Saxs” Perrson, David Perry Programming Plenary   Motivate - Intelligent Digital Actor System Yotto Koga Programming Sponsored Motion Factory Multiplayer Game Development: Networking SimCity Jason Shankel Programming Lecture   Multiresolution Meshes: A Solution for Creating Scalable 3D Games Stephen Junkins Programming Sponsored   Natural Language Processing in 55 Minutes or Less John O’Neil Programming Lecture   Next Generation BSP Trees Bruce Naylor Programming Lecture   Next Generation Effects Using Multi-texture, Multi-pass Triangles David Kirk Programming Lecture Direct3D Optimizing 3D Performance with Direct3D David Kirk Programming Sponsored   Optimizing Games for the Real 3D Starfighter with Intel740 Hadden Hoppert, Jeff Potter, Andy Thompson Programming Sponsored Real3D Performance Tuning for Pentium II Processors with VTune 3.0 Gary Carleton Programming Sponsored by Intel Pentium II processor tuning Physical Modeling for Games Michael Shantz Programming Lecture   Physics Q&A Chris Hecker, David Wu Programming Seminar   Porting Flight Sim ‘98 to Direct3D: Dragging a 15 Year Old Graphics Engine Into the 90s Todd Laney Programming Lecture   PowerVR II Technology Overview John Smith Programming Sponsored Dreamcast and PC GPU Programming for PC-based Coin-Op and Arcade Games Mark Atkins Programming Sponsored   Programming with Glide 3Dfx Interactive Programming Sponsored   Project AI Mark Baldwin Programming Lecture Used in Games: The Perfect General, Empire Deluxe and Empire II Quake2: A Study in Using OpenGL and Hardware Acceleration for the PC Platform Brian Hook Programming Lecture   Real-Time Procedural Texturing Haim Barad Programming Sponsored MMX, fractional Brownian motion State of the Art in 3D Real-Time Characters Jeff Lander Programming Lecture   Texture Caching Jonathan Blow Programming Roundtable Artistic styles in computer games The Art of Force Feedback: Adding Realism To Your Applications Using Force Feedback Sticks, Wheels, and Mice Dean Chang Programming Sponsored DirectInput The Future of Coin-Op Games John Fowler, John Latta, Matt Saettler, Albert Teng, Tom Petit, Jeff Walker Programming Plenary   The Physics of Baseball 3D Miguel Gomez Programming Lecture Microsoft Baseball 3D Tips & Tricks of PowerVR’s First & Second Generation Kevin Kralian Programming Sponsored Gremlin, Kalisto, Ion Storm, Acclaim, and others. Triangle Strip Generation for Real-Time 3D Games Programming Michael Rosenzweig Sponsored   Vector Quantization Texture Compression, Hardware Bump Mapping, and Generalized Modifier Volumes Programming Mark Butler Sponsored   VR-1 Conductor: Creating a Standard Technology Platform for Online Gaming Mark Vange Programming Sponsored VR-1 Conductor SDK 3D Character Modeling for Animation Stefan Henry-Biskup Visual Arts Lecture Spline-based modeling techniques Art Skills to Produce Superior Figurative Game Art Don Seegmiller Visual Arts Lecture   Artists And Game Design Documents: From Interpretation To Implementation Joshua Gordon Visual Arts Lecture   Building Tight Real-Time Models Ocean Quigley Visual Arts Lecture   Directing an Art Department Glen Schofield Visual Arts Lecture   Game Developer Magazine’s Animation Confrontation Sponsored by Game Developer Visual Arts Plenary Participants include Kinetix, NewTek, and Softimage How to Break in as an Artist Carrie Galbraith Visual Arts Seminar   Killer Games with SOFTIMAGE3D Softimage Visual Arts Sponsored SOFTIMAGE GDK, Tantrum Entertainment Picture Imperfect: Common 3D Rendering Flaws Brad Cain Visual Arts Lecture   Planning and Directing Motion Capture for Games Melianthe Kines Visual Arts Seminar   Real-Time 3D Art Ideas from Online Applications Stasia McGehee Visual Arts Lecture Web-based low-poly 3D applications The Art of Low-Poly Paul Steed Visual Arts Lecture Quake II The Need for Renaissance Men and Women in this Digital Age of Art Cyrus Lum Visual Arts Keynote 3D Artist scripting languages You Want What? Scaleable Character Approaches for 3D Real-Time Paul Lewis Visual Arts Lecture   Sponsored SessionsThis year had Sponsored sessions showing off how to program for the newly released Intel740 GPU and a session from 3dfx Interactive on Programming with Glide for their Voodoo 2 hardware.Arcade Game programming with PC HardwareIn the session Programming for PC-based Coin-Op and Arcade Games by Mark Atkins, he proposes that arcade machines of the future will be PCs connected to esoteric input devices like motion chairs and thus will allow easy porting between arcade and home computer when using technologies like DirectX.He was not the only developer to propose a PC-based arcade as there was another session called The Future of Coin-Op Games by the Open Arcade Architecture (OAA) forum members who share their insights on what makes a great arcade game, understanding the differences in creating hit arcade games and hit home games, making money in the arcade market, and how to use arcade as a first-run theater for titles headed for the home.Game Development in Java in 1998?!There is even a session this year on building games in Java, which was not seen as a viable programming language for game development at the time due to it being an interpreted language with limited APIs for hardware acceleration. Garner Halloran talks about developing the game Tom Clancy’s Politika in Java which was a virtual board game similar to Risk.GDC 1999 - March 15th-19thThe 1999 GDC had more than 9,500 attendees 7 and had Shigeru Miyamoto as a keynote speaker along with other keynotes from Sega and Sony.GDC 1999 was split into six different tracks: Audio Business & Legal Game Design Production Programming Visual ArtsThe sessions that we know about are listed in the table below: Title Presenter Track Type Notes Changing for the Better: Redefining Game and Hardware Development through Evolution (Sega’s Console Keynote) Bernie Stolar All Keynote   The Secret to Consistently Delivering Hit Titles Louis Castle Production Keynote Westwood Studios Surviving 15 Years on the Frontlines of the War Brian Fargo Business & Legal Keynote   The Future of Interactive Entertainment (Sony’s Console Keynote) Phil Harrison All Keynote   New Players, New Games Brenda Laurel Game Design Keynote Diversity How To Render The World Andrew Glassner Programming Keynote Shading techniques, from direct illumination to ray-tracing and radiosity Music in Video Games: The Art of the Deal (How to Make Tons of Cash Writing Video Game Music!) Tommy Tallarico Audio Keynote   Conference Keynote: Shigeru Miyamoto Shigeru Miyamoto All Keynote   The Reality of Fantasy Syd Mead Visual Arts Keynote   Developing Environments for the Creation of Entertainment Software Juan Carlos Arevalo-Baeza and Edward Kilham Visual Arts Lecture 3301 Glory and Shame Jonathan Baron Programming Lecture 3205 The Freelance Life Ellen Beeman Business & Legal Lecture 5110 Using DirectMusic Daniel Bernstein, Guy Whitmore, David Yackley and Jon Laff Audio Lecture 4111 Basics of Dynamic Audio Generation Jonathan Blow Audio Lecture   Back to Basics: Better 3D through 2D Adrian Bourne Programming Lecture 5507 Loading and Saving Game Objects: A Persistent Reusable Format Michael Braley and Sandeep Kharkar Programming Lecture 5502 Can Educational Be Fun? Amy Bruckman Game Design Lecture 3106 Advanced Multitexture Effects with Direct3D and OpenGL Jim Bushnell and Jason L. Mitchell Programming Lecture 5201 Visual Level Design: Designing Machines for Playing In Steve Chen Game Design Lecture 5404 Don’t Be a Vidiot: What Computer Game Designers Can Learn from Paper Games Greg Costikyan Game Design Lecture 5505 Win32 for Games Tony Cox Programming Lecture 4203 Schedules That Mean Something Don Daglow Business & Legal Lecture 5401 Virtual Virtuality: Cheap Tricks for Immersive Worlds Graeme Davis Visual Arts Lecture 3506 Designing Al Engines with Built-in Machine Learning Capabilities Zhimin Ding Programming Lecture 5303 Making Packages Fun Again Mike Dornbrook and Steve Meretzky Programming Lecture 3110 Building an LBE Attraction: Hercules in the Underworld, A Case Study Noah Dudley and Joe Shochet Programming Lecture 4305 Console Audio Programming Thomas Engel Audio Lecture 3402 A Grand Unified Game Theory Noah Falstein Game Design Lecture 3105 Licensing Ins and Outs For Developers Frederick U. Fierst Business & Legal Lecture 4207 How to Keep Internet Hackers Far, Far Away Andrew Finkenstadt Programming Lecture 4303 Every Byte Counts: Graphic Design for Online Games Tracy Fullerton Visual Arts Lecture 5208 Teaching an Old Dog New Bits: How Are Console Developers are Able to Improve Performance When Hardware Hasn’t Changed Andy Gavin and Stephen White Programming Lecture 3202 Painting with Light Reid Gershbein Programming Lecture 3507 Arcade Game Psychology Michael C. Getlan Game Design Lecture 5306 Tales from the Trenches of Coin-Op Audio Chris Granner Audio Lecture 5509 The Gamer’s Eye View Charles D. Gray Game Design Lecture 5305 Negotiating a Great Advance and Royalty Deal Dean Gloster Programming Lecture 3310 Networking Coin-Op Arcade Games: Technology and Economics Michael J. Hanson Programming Lecture 5109 Creating Character Animation Assets Jeff Hayes Visual Arts Lecture 4107 Manuals: They Can Be Good Arnold Hendrick Visual Arts Lecture 5304 Controlling Simulated Characters Jessica K. Hodgins and W.L. Wooten Programming Lecture 3403 Using Java as an Embedded Game Scripting Language Robert Huebner Programming Lecture 3501 What’s Love Got to Do With It? Exploring Consumers’ Emotional Attachments to Products Christopher Ireland Game Design Lecture 4310 C++ Optimization Strategies and Techniques Peter Isensee Programming Lecture 4103 Distributed Liability: Emerging Legal Issues Curtis Karnow Programming Lecture   Creating Reflections and Shadows Using Stencil Buffers Mark Kilgard Programming Lecture 5102 The Art of Puzzle Game Design Scott Kim Game Design Lecture 4407 Directing Motion Capture Talent Melianthe Kines Visual Arts Lecture 3107 Client/Server Design For Online Games Andrew Kirmse Programming Lecture 4104 A Conversation about Alliances Stuart Kliman Business & Legal Lecture 3109 File I/O Optimization: The Hidden Win Eric Klein, John Newlin and Jason Regier Programming Lecture 4404 Developing an Artificial Intelligence Engine John Laird and Michael van Lent Programming Lecture 5503 Reinventing the Wheel: Build 3D Tools or Buy Them Jeff Lander Programming Lecture 3201 Rapid Prototyping: From The Pitch through Design to Final Sale Nicole Lazzaro Programming Lecture 3104 Fast Collision Detection for Interactive Games Ming C. Lin Programming Lecture 3102 The Internet Sucks: What I Learned Coding X-Wing vs. TIE Fighter Peter Lincroft Programming Lecture 3303 Inspiration for the Design of Game Characters and Settings Linda Lubken Game Design Lecture 5108 Don’t Starve that CPU! Making the Best of Memory Bandwidth Herbert Marselas Programming Lecture 5103 Principles of Believable 3D Character Animation Chris Mead Visual Arts Lecture 3508 Applying the Technology of Distributed Training Simulations to Gaming Larry Mellon and Jesse Aronson Programming Lecture 5504 Asset Management: Taming the Complexity Daniel Miller Visual Arts Lecture 5510 Tools for Giant Robots: An Evolution from 1994 to 1999 Tim Morten Programming Lecture 3101 What It Costs to Make a Game Dr. Ray Muzyka Business & Legal Lecture 4110 Color Theory and Designing with Color Schemes Eni Oken Visual Arts Lecture 3307 and 3408 Polygon Character Design Under Technical Constraints Walter Park Visual Arts Lecture 4109 Funding Your Next Title Set: Choices, Not Guesses Bruce Poitevin Business & Legal Lecture 4208 After the Shoot: Motion Capture Data Greg Pyros Visual Arts Lecture 3207 The “Designed for Microsoft Windows” Logo Program: What it Means to Game Developers Len Rehard Business & Legal Lecture 3410 Steering Behaviors for Autonomous Characters Craig Reynolds Programming Lecture 5101 Designing Web-Based Games Gary Rosenzweig Game Design Lecture 5506 The Game Developer’s Legal Guide To Web Commerce Ira Rothken Business & Legal Lecture 4411 Working with a Big Publisher Matt Saettler Business & Legal Lecture 3209 Outcast: Programming Towards a Design Aesthetic Franck Sauer, Olivier Masclef, Yann Robert, and Pierre Deltour Programming Lecture 4405 Empowering Constraint: Lessons from Industrial Design Phil Saunders Game Design Lecture 3108 Introduction to Parametric Surfaces Brian Sharp Programming Lecture 3103 Writing a Game Site in Java: Write Once, Test Everywhere Matt Shea and Michael Bayne Programming Lecture 5204 Fundamental Principles of Modeling and Simulation Roger Smith Programming Lecture 3203 Optimizing 3D Art: Less is Best Paul Steed Visual Arts Lecture 4408 Extreme Detail Graphics Jan Svarovsky Programming Lecture 5501 Getting Your Design Down on Paper Chris Taylor Game Design Lecture 4306 Performance Optimization, Windows 2000, and DirectX Phillip Taylor Programming Lecture 3404 How to Draw Monkeys the LucasArts Way: An Analysis of The Funny Pictures in the Curse of Monkey Island William Tiller Visual Arts Lecture 5207 Optimizing Game Applications for the MIPS RISC Architecture Michael Uhler Programming Lecture 4205 Top 10 Things Every Producer Should Know about Programming and Programmers Gordon Walton Business & Legal Lecture 3412 Human Factors Engineering for Game Interface Design Robert Warren Programming Lecture 5402 Designing Around Pitfalls of Game Al Douglas Whatley Game Design Lecture 5206 Making the Message Fun: The LBE in Theme Parks and Trade Shows. Todd Williams Game Design Lecture 4206 Shigeru Miyamoto’s 1999 GDC KeynoteShigeru Miyamoto discusses his creation of such worldwide recognized characters as Mario, Donkey Kong, Link, and Zelda. He also shares his vision of The Legend of Zelda: Ocarina of Time, the fastest-selling game in history, and looks into what the future holds for game developers in the new millennium.Sega’s 1999 GDC KeynoteIn this speech, Bernard Stolar, president and COO of Sega of America, addresses how the company is preparing for the new marketplace with its Dreamcast video game system. Dreamcast’s unique architecture creates a machine that is up to 15 times more powerful than current consoles and can actually change and grow with the gamer. Stolar discusses the benefits of creating games for a platform that will actually evolve, not just with simple peripheral add-ons, but with significant technologies that keep the machine as fresh, current and competitive as the day it was purchased.GDC 2000 - March 8th-12thThe 2000 GDC ticked off on March 8th with the tagline “Take your place in game history”, it was attended by ? games industry professionals.There were so many talks that it was split into seven different tracks: Programming Game Design Business & Legal Production Audio Visual Arts Level DesignThe sessions that we know about are listed in the table below: Title Presenter Track Notes   Making Fun for the Masses: We’ve Just Scraped the Surface! Tom Dusenberry Business & Legal     Mainting Your Vision and Consistency through the Hell of Production Lorne Lanning Production     PlayStation Keynote Phil Harrison All     Using the Evolution of Black & White As an Example of Next Generation Development Ethos Peter Molyneux Game Design     New Pioneers at the Graphics Frontier Kurt Akeley Programming     Conference Keynote Danny Hillis All     The Role of Reality in Epic Game Creation Yu Suzuki Game Design     Designing Sound for Media and Designing Media for Sound Randy Thom Audio     The Designs of Star Wars: Episode One Doug Chiang Visual Arts     AI in Computer Games Roundtable Eric Dybsand, Steven Woodcock and Neil Kirby Programming     The Benefits of a Microprogramable Graphics Architecture Dominic Mallinson Programming     BOPS: Conquering the Geometry Pipeline Marco Jacobs, Ivan Greenberg and Mike Strauss Programming Sponsored Session   Building Control Systems for Robot Locomotion Jessica Hodgins Programming     Digital Scent: Revolution of the Senses Jason Herskowitz, Ralph Cooksey Thomas Programming Sponsored Session   Fast Proximity Queries for Large Game Environments Ming Lin Programming     Half-Life and TeamFortress Networking: Closing the Loop on Scaleable Network Gaming Backend Services Yahn Bernier Programming     The Heroes III Random Map Generator Gus Smedstad Programming     Hidden Surface Reduction and Collision Detection Based on Oct Trees Brent Pease Programming     How to Simulate a Ponytail: Implementing Open Loop Chains Chris Hecker Programming     Open Architecture for Free Internet Gaming David Wright and Bryan Gibson-Winge Programming     Interaction with Groups of Autonomous Characters Craig Reynolds Programming     It’s Great To Be Back! Fast Code, Game Programming, and Other Thoughts From 20 (Minus 2) Years in the Trenches Mike Abrash Programming     It’s Still Loading? Scott Bilas Programming     Metrics for Level of Detail Dave Eberly Programming     NetZ ­ Multiplayer Architecture for Online Games Carl Dionne, Martin Lavoie, Kenneth Trueman Programming     Pawn Captures Wyvern: How Computer Chess Can Improve Your Pathfinding Mark Brockington Programming     PC vs Console vs Embedded Game Development Greg Corson Programming     Real-Time Cloth Jason Weber Programming     Real-Time Continuous Level of Detail (LOD) for PCs and Consoles Louis Castle, Jonathan Lanier, James McNeill Programming     Real-Time Statistics and In-Game Debugging, or How to Deal with Insubordinate Tools John Olsen Programming     Run-Time Skin Deformation Jason Weber Programming     Subdividing Reality: Employing Subdivision Surfaces for Real Time Scalable Photorealism Stephen Junkins Programming     Taking Tiger Woods Java Golf Online Robert Burnett, Phil Sorger Programming     Terrain Analysis for Realtime Strategy Games Dave Pottinger Programming     The Tribes Engine Network Architecture Mark Frohnmayer, Tim Gift Programming     Two Advanced Terrain Rendering Systems Jonathan Blow, Seumas McNally Programming     Using Technology to Create Believable 3D Characters Jeff Lander Programming     Vehicle Dynamics for Racing Games Ted Zuvich Programming     Writing Portable Code Didier Malenfant Programming     The Art of Empires: Lessons Learned from Age of Empires Brad Crow, Mark Terrano, Scott Winsett Visual Arts     Cutting to the Chase: Cinematic Construction for Gamers Hal Barwood Visual Arts     Digital Figure Painting Don Seegmiller Visual Arts     From Aquilaris to Malastare, Making Worlds for Star Wars: Episode One Racer Duncan Brown Visual Arts     Motion Editing: Principles and Practice Susan Van Baerle Visual Arts     On the Future of Real-time Characters Joby Otero Visual Arts     Pattern Reduction in Massively Tiled Scenes Jason Waskey Visual Arts     Visual Storytelling through Lighting Sudeep Rangaswamy Visual Arts     Advancing 3D Audio Through Acoustic Geometry Interface Edward Riegelsberger, Micah Mason, and Suneil Mishra Audio Slides   A Roadmap: Moving Beyond the Big Audio API¹s (Interactive Audio with Configurable Components) Chris Grigg Audio     The Future of Interactive 3d Audio Brian Schmidt and Conrad Maxwell Audio     Implementing ZoomFX 3D Objects in 3D-space using DS3D Mike Percy Audio Slides   Proposal for IA-SIG 3D Audio Rendering Guideline Level 3 (13DL3) Jean-Marc Jot Audio Slides   Retained Mode 3D Audio Bo Gehring Audio     Top Down Bottom Up Game Audio: What I Learned from Ken Griffey Baseball Michelle Sorger Audio     Asset Management: Problems and Solutions Katy Franz Production Roundtable Production The Brain Behind the Game: Media Asset Management For Your Project Gregor vom Scheidt and Pascal Jarry Production Sponsored Session   Data Wizards and Wands: Making Better Games More Quickly with Tools and Tool Experts Steve Taylor Production     Developing Leadership and Management Skills in the Game Industry Robert White Production     The Fourth Thread: Effectively Integrating Audio and New Audio Technology into the Game Development Cycle Brett, Heather Sowards Production     A Monster in the Making: Creating Baldur’s Gate Ray Muzyka Production     New Tools for Task Communication Torgier Hagland Production     Project Prototyping oster? Production Roundtable   Prototyping for Fun and Profit Ed Nanale, Michael Wyman Production     Quantifying QA: A Stitch in Time Patricia Pizer Production     Rollcage: A Post-Mortem of the Porting Process Fred Gill Production     Schedules that Mean Something Don Daglow Production     Working With Brands: A Post-mortem of Dune 2000 and LEGO Loco Matthew Stibbe Production     Write is Might: Making Documentation Your Friend Graeme Davis Production     Commencing the Developer/Publisher Relationship: Experiences in Pitching Summoner Mike Kulas Business & Legal     European Market Opportunities Torsten Oppermann Business & Legal     Internet Business Models: New Options for Game Developers Scott Draker Business & Legal     Localizing for Japan: Wildroid 9 Case Study Stuart Roch Business & Legal     The New Principles of Marketing Christopher Ireland Business & Legal     Publishers Speak! What it Really Takes to Land a Publishing Deal Dan Rogers Business & Legal     Taking the Mystery out of Starting Your Own Company Stacy Hering Astor Business & Legal     Working with Licensors Louis Castle Business & Legal     Your Ass, My Foot: Management Styles for the Next Century Dave Timoney Business & Legal     The Art and Science of Level Design Cliff Bleszinski Game Design     Children¹s Software: Past, Present and Future Ken Kahn Game Design     Designing Web-Based Games Gary Rosenzweig Game Design     Developing Software For Girls Jesyca Durchin Game Design     Eurostylin¹: An American Game Designer in Europe Ernest Adams Game Design     Everything But the Words: A Dramatic Writing Primer for Gamers Hal Barwood Game Design     The Future of Strategy Games Phil Steinmeyer Game Design     Game Character Creation Paul Douglas, Toby Gard Game Design     Heat into Light: Community Generating Conflict in Online Multiplayer Games Jonathan Baron Game Design     The In-Game Economics of Ultima Online Zack Simpson Game Design     Interactive Toys: The Child as Programmer Jonathon Ackley, Mike Dooley Game Design     Level Designers Brainstorm David Chang Game Design     The Many Face of a Winning Design Team: Which Face is Yours? Larry Hodgson Game Design     Metagames Richard Garfield Game Design     Mostly Armless: Grabbing the 3D World David Rees Game Design     Myth Adventures: How Games, Myth and Movies Team Up on the Path of Heroes Christopher Vogler Game Design     Puzzle Game Design Scott Kim, Alexey Pajitnov Game Design     The “Rules” Of Making Massively Multiplayer Persistent Worlds Raph Koster, Rich Vogel Game Design     Smart Toys: Benefits of Technology-Enhanced Play Amy Francetic, Helen Shwe Game Design     Storytelling in Action Bob Bates Game Design     Microsoft DirectX Developer Day (March 8th)It included a “Microsoft DirectX Developer Day” on the 8th of March held by Microsoft who presented multiple lectures explaining how to use the new functions of the DirectX 8 SDK. The knowledge about DirectX 8 was so cutting-edge that it required a Non-Disclosure Agreement (NDA) to be signed to even attend 8! But you would walk out not just having the knowledge of DirectX 8 but also an early build exclusive to attendees.It began with a speech by Chris Jones, about the current state and future of Windows games. Next, Brian Moran, program manager of the company’s Windows Division, held a session on precautions in the production of Windows 2000 compatible game software.The lectures prepared at Microsoft DirectX Developer Day are divided into three areas: Graphics (DirectDraw, Direct3D) Audio and Streaming (DirectSound, DirectShow) Network and input (DirectPlay, DirectInput)There were 5 lectures for 1 hour in each field, so a total of 15 sessions were held.From the original website it looks like the sessions were roughly the following: DirectX 8.0 Graphics Architecture - Faster and easier than ever! Direct3D 8.0 Base Functionality - Where it all starts Direct3D 8.0 Vertex Processing - Look what you can do with vertices now! Direct3D 8.0 Pixel Processing - And you thought the vertex operations were cool… High level technologies - Making things even easier to use DirectX 8.0 Audio Architecture - Closer integration of DirectSound and DirectMusic for maximum flexibility DirectX 8.0 Audio FX - Enrich your game audio environment DirectX 8.0 Audio Scripting - Enable post-authoring of your game audio environment DirectShow 8.0 - Movies, video editing, and using the new DirectX plug-in architecture DirectPlay 8.0 Architecture - Designed for massive multiplayer online games DirectPlay Voice - Take your online game to the next level! DirectInput Mapper - Easily add device optimized support to your game DirectInput Mapper CPL - How to use and customize to match your game UI Application Manager - Turn your game into a drop-n-play experience!Note that although we don’t have much details on the contents of each of the talks, there is a physical Binder available at the Museum of Play: Microsoft DirectX Developer Day binder, 2000 - The StrongMicrosoft Keynote (Xbox Unveiling)GDC 2001Electric Playground is a Canadian television show and digital media platform focused on video games, technology, and the gaming industry.They had a whole episode where they visted the 2001 Game Developer’s Conference which you can watch on youtube below:The sessions that we know about are listed in the table below: Title Presenter Track Notes “1,500 Archers on a 28.8: Network Programming in Age of Empires and Beyond” Bettner, Terrano Programming   Advanced Character Physics Jakobsen Programming   Anybody Seen that Transform Node? Strategies to Better Link Animation Data in Games Engel Programming   The Basics of Team AI Gibson, O’Brien Programming   Bringing Dr. Jones to the Infernal Machine — Dealing with Memory Constraints Sauer Programming   BSP Collision Detection As Used In MDK2 and NeverWinter Nights Melax Programming   Camera Techniques for Complex Environments James Programming   Creature Smarts: The Art and Architecture of a Virtual Brain Burke, Isla Programming   Experiences in Programming Maya 3.0 Giberson Programming   FuBi: Automatic Function Exporting for Scripting and Networking Bilas Programming   Game Boy Advance Resource Management Baptista Programming   Implementing Multicolored Volumetric Fog without Using Up Texture Stages Arevalo, Baeza Programming   Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization Bernier Programming   Lessons Learned from a Year with Xbox Abrash Programming   Linux in Game Development Strauss, Kreimeier, Vance, Packard, Lantinga Programming Tutorial Content Optimization Techniques for Hardware Transformation and Lighting Pipelines Ratcliff Programming   Practical Implementation Techniques for Multiresolution Subdivision Surfaces Brickhill Programming   Procedural Rendering on PlayStation 2 Green Programming Content Proximity Queries and Penetration Depth Computations on 3D Game Objects van den Bergen Programming   Real-Time Full Scene Antialiasing for PCs and Consoles Mitchell Programming   Real-Time Photorealism via Procedural Shaders Baker, Boyd Programming   Real-Time Photorealistic Terrain Lighting Hoffman, Mitchell Programming   Real-Time Shadows Haines, Moller Programming   A Robot Soccer Simulator: A Case Study for Rigid-Body Contact Larsen Programming   Shading Languages for Graphics Hardware Mark, Proudfoot Programming   Simulation Level-Of-Detail and Culling Chenney Programming   Stable Rigid-Body Physics Rhodes Programming   Technology Five Years from Now Braben Programming   Terrain Reasoning for 3D Action Games van der Sterren Programming   Using Windows To Create Palm Games Magerkurth Programming Audio What Happened to My Colors? Displaying Console Computer Graphics on a Television Dawson Programming   Designing for the Internet Gamer Gordon Business & Legal Keynote Financing a Game Development Company in Today’s Market Foster, Karlov, Kay, Thoma Business & Legal   Fun and Games in the Online Medium: Insights from the World’s Largest Online Service MacLean, Mills, Opas Business & Legal Panel Getting to the Next Level: All the Cheats on Employee Nirvana Hering Astor, Rose Business & Legal   “How to Market in Korea: Small Country, Large Market for PC Games” Park Business & Legal   Independent Development and Publishing: Case Study Quirk Business & Legal   Publisher Contracts That Protect Your Title and Team Powell Business & Legal   Publishers Speak Rogers Business & Legal   Why Cheating Matters Davis Business & Legal   “Baldur’s Gate II and Sequels: The Good, the Bad, and the Ugly” Muzyka Production   Console Development Crash Course Taylor Production   Designing Your Company Culture: Westwood Studios over 15 Years Castle Production   Don’t Ship it Yet: Why You Need Hardcore QA Bryant Production   Effective Project Management Angle, Dwyer Production   How to Kill Feature Creep Without Ever Saying No Crabtree Production   Leveraging Middleware Wofford Production   “Maintaining Your Budget by Organizing, Defining Milestones and Staying on Schedule” Daglow Production   “Managing 40,000 Assets per Game (Hey, Where’d it Go? It was Just Here!)” Marselas Production   The Mysteries of Multiplatform: Developing on Console and PC Falkner, Zeschuk Production   The Architecture of Level Design Brown, Chen Level Design   Content Acquisition for Levels in The Getaway: London Wasn’t Built in a Day Coates Level Design   Current Architecture and Potential Approaches to Level Design Brown Level Design   A Better Understanding of Audio and the Technical Design Process Hubbard Audio   Beyond the Library: Applying Film Post-Production Techniques to Game Sound Design Peck Audio   Diablo II Case Study Uelmen Audio   Implementing an Audio Engine Using DirectX 8 Geist Audio   Interactive Music Sequencer Design Patterson Audio   The 12 Principles of Classic Character Animation Kerlow Visual Arts   Aesthetics Beyond Technology: Nonphotorealistic Rendering Art Styles Snyder Visual Arts   Art Creation for a PlayStation 2 Launch Title - The Ups and Downs of Summoner Pletcher Visual Arts   Art Management for Artists Oglesby Visual Arts Roundtable Conceptual Design: Understanding and Communicating Form Saunders Visual Arts   Dealing with Artistic Limitations as a 3D Game Artist. PC vs. Consoles Isaac Visual Arts   Exorcising Satan’s Rotoscope: Motion Capture from an Animator’s Perspective Stripinis Visual Arts   From PC to TV Nichols Visual Arts   Questions Artists Should Ask Programmers Lubken Visual Arts   Realistic Inverse Kinematics: Set-Up and Techniques Coven Visual Arts   Scripting for Artists Versluis Visual Arts   Taking the Mental out of Environmental: Building a Beautiful World Without Going Crazy Duvall Visual Arts   That Extra Dimension: Differences in Thinking Between 2D and 3D Animators Bradrick Visual Arts   Tools of the Trade: The Changing Nature of Design Tools Barry Visual Arts   Fusing Traditional Computer Graphics with Game Development: ACM SIGGRAPH’s Outreach to the Game Developer Community Scott Owen, Theresa-Marie Rhyne, Alyn Rockwood IGDA   “The Demo Scene, an Introduction” Foo, Vincent Scheib Special Session   AI in Computer Games: AI for Beginners Discussion Dybsand, Kirby, Woodcock Game Design Roundtable AI Roundtable Report Woodcock Game Design Roundtable Analyzing and Learning from Great Games Falstein Game Design Tutorial Applying Behavioral Psychology to Game Design Tucker Game Design   Creating Emotional Involvement in Interactive Entertainment Barrett Game Design Roundtable Designing Interactive Theme Park Rides: Lessons Learned Creating Disney’s Pirates of the Caribbean: Battle for the Buccaneer Gold Schell, Shochet Game Design   Designing Mobile Games for WAP Seppanen Game Design   Designing Web Games that Make Business Sense Kim Game Design   Shockwave Tutorial: Building Web Games in Flash Kim Game Design Tutorial How to Balance a Real-Time Strategy Game: Lessons from the Age of Empires Series Kidd, Petersen, Street Game Design   Interaction Design for Immersive Public Entertainment Spaces Kaufman, Kline Game Design   Oddfellows: Character Design the Oddworld Way O’Connor, Ulm, Varahramyan Game Design Panel Principles for Designing Successful Games Shelley Game Design   Story: Writing Skills for Game Developers Bates Game Design   Using Video Input for Games Marks Game Design   The Demo Scene, an IntroductionThere was a special session that didn’t appear in the conference proceedings book which was presented by Vincent Scheib and another unknown author simply known as Foo (surname or programming joke?). It is unclear if this session actually took place, it was listen on the GDC Website: Game Developers Conference - Archives - 2001- Special Sessions Proceedings with a Word document that was never backed up the the Wayback Machine.This may be the same session also presented by Scheib at SIGGRAPH 2002 called The Demo Scene.If this session did take place, it is a great example of game developers reaching out to the hobbiest Demoscene for very talented graphics programmers.GDC 2002An American TV show called Extended Play had some brief coverage of GDC 2002 which is available to watch below:There is also coverage on the GameDev.net archive, which has everything from lectures to “booth babes”: Inside the 2002 Game Developers ConferenceThere was a CD produced that had 65 papers and presentations from the 2002 Game Developers Conference on one CD-ROM.The sessions that we know about are listed in the table below: Title Presenter Notes Art Direction: The Employee, the Critique and the Axe Reid   Creating Characters with Dimension and Depth Bates   Effective Team Communication Kelley   Game Audio Network Guild Panel     Hardware-Accelerated Procedural Texture Animation James   How to Get Positive Coverage for Your Company Bohle   My Adventures With Inverse Kinematics Hecker   Optimizing Memory Bandwidth Wall   Scripting for Artists: Beyond the Basics Versluis   Why We Shouldn’t Make Games Adams   American Mc Gee’s Alice a Postmorten: Lessons Learned Mc Gee   Art Directors Panel Herring, Lubken, Lum, Mauk & Petty   Battling Level Design in Hardcore Genres for a Casual Audience Longo   Episodic Entertainment: Viva-La Evolution Young   Hardcore Character Modeling and Animation Steed   Mobile Phone Games: Where Are They Now and Where Are They Going? Baverstock   Of Internet Servers and SQL Databases:Designing the Backend for Power and Performance Hallenberg   Parappa 2 and Vib Ribbon 2: Conflicts and Problems in Creating Sequels Matsuura   Rainbow Connection DeSimmone & Lapin   Taming a Wild River: 3D Fluid Simulation Lander   The Complete 5.1 Audio Experience for Video Games Panel Allen, Kirschner, Staats & Tallarico   The Visual Engineering of SSX Rayner   Xbox Launch: Lessons Learned Isensee   Sony Computer Entertainment Research & Development Okamoto   Crossing Over to Film and Back Again Chan   Genre Specific World Building Methodology in SSX & SSX Tricky Karolic   Global IP Protection and Anti-Piracy Techniques Chapin   How to Manage a Large-Scale Online Gaming Community Koster, Vogel   Maintaining an Edge in this Increasingly Competitive Field Schmidt   Preproduction Spector   Pros and Cons of the Organic Design Process Carter   Real-Time Cloud Rendering for Games Harris   Real-Time Strategy Game Balance Browder   Social Activities: Implementing Wittgenstein Barnet-Lamb & Evans   Using a Webcam as a Game Controller Blow   What Worked: 10 Detailed Examples of Successful Character Action Design Cerny   “The More Things Change…” Colcord   Character Animation for Videogames Friedman   Creating Great Games Within a Large Organization Goodman   In-Game Special Effects and Lighting Arce & Wloka   Innovation on Demand Bachus   Quality or Death: How the Business Model and Player Psychology Collide in For-Pay Online Games Todd   Realistic Deformation O’Brien   The Hook(s) of the Game Perry   The Player With a Thousand Faces: Measuring Fun and Adapting Difficulty Arey & Wells   UI Case Study: This is Football 2002 Hamilton & Ranyard   Virtually Limitless: Virtual Memory on Nintendo GameCube Engel   A Data-Driven Game Object System Bilas   Beyond Psychological Theory: Getting Data that Improves Games Fulton   How to Organize and Run an IGDA Chapter Meretzky   Image-Based Rendering for Computer Games Chen & Grzeszczuk   Manhattan as Muse: New York City as a Conceptual Tool Brown   Nintendo GameCube Programming 101 Ravanpey & Treglia   Redefining the Business of Game Development Newell   Rez: The Synesthesia that Games Invite Mizuguchi   The Necessity of Character Design in Game Development Rafei   The Power of the High Pass Filter Hajba   Using a Live Orchestra in Game Soundtracks Giacchino, Soule, Tallarico, Thomas & Wall   Vector Units and Quaternions VanVerth   Academia and Video Games: How to Build and Maintain a Relationship Between Two Different Worlds Buchanan   Incredibly Dense Meshes Brickhill   Interviewing Techniques Baker   Kids Communities: What Works, What Doesn’t Schell & Shochet   Level Design in an Outdoor Environment Leonard   Online Anarchy: Massively Multiplayer from a Design and Architectural Point of View Strand   Stories You Can’t Tell Crawford   The Employment Lifecycle: Your Best Investment Longoria   The Physics that Brought Cel Damage to Life: A Case Study Wu   The Role of Technical Director at LucasArts Brew   Xbox Audio Selfon   22 Secrets for Creating Realistic Dialogue and Scene Flow Freeman   Afterthoughts - The Audio of Star Wars: Rogue Leader Engel   Another Five Years from Now: Future Technologies Braben   Fur Using Shells and Fins Lengyel   Games with Collectible Components Garfield   IGDA Whitepaper on Online Games Estanislao, Ford, Jarett, MacLean, Vechey, Walton, Welch   In-Depth 3D Exporter Design and Implementation Muratori   Intellectual Property: The Current Game of Swords and Shields Rubin   Modern Techniques in Creating Tile-Based Graphics for Game Boy Advance Bala   Next Generation Console Development and Production in the Global Market: Opportunities and Challenges Yoshida   Systemic Level Design for Emergent Gameplay Smith   The Making of Shrek Walker   When Maps Collide: A Conversation with Will Wright and Scott McCloud Mcloud & Wright Adapting Cinematic Filmscores For Games Abernethy & Adams Advancing a Franchise Through Design Yamauchi   Defense Against Service Theft, Internet Cheating and Denial of Service Gray Digital Imagery and Level Design Maatta Game Scripting in Python Dawson   Modeling Lush and Expansive External Environments Dixon & Lovett   Negotiating Contracts: Getting Developers What They Need While Giving Publishers What They Want Camps   PlayStation 2 Geometry Transform and Clipping Using Vector Unit Microprogramming Hughes   Rendering Outdoor Light Scattering in Real-Time Hoffman & Preetham   Toss it in the Blender: Non Linear Animation for Games Theodore   Tracking Assets in the Production of Final Fantasy: The Spirits Within Kawai   Cinematic Lighting for 3D Graphics Birn   Dynamic Range in Games: An Overview for Sound Creators Hays   Examining the Production Process for the No One Lives Forever Franchise Ryan   High Dynamic Range Imagery and Image-Based Lighting Debevec   Maximizing DMA Bandwidth on the PlayStation 2 Omi   More of the 400: Discovering Design Rules Barwood & Falstein   Online Game Design for Mobile Phones Imai & Shimizu   Realistic Expectations in Developer/Publisher Relations Blackman, Frisina, Goodman, Keighley, Moulder, Raffel & Wilbur   State Based System of Animation: Artfully Blending Animation with AI Hirschmann & Thankamushy   The Relationship Between Background and Interface Design Procedures in Video Game Development Nagoshi   This is Not a Game: A Discussion on the Creation of the AI Web Experience Lee & Weisman   Building a Third-Generation Online Persistent World Game Koster, Lawrence, Mulligan & Walton   Complexity Demons: They’re All Around Us Leker   Console Audio Panel Engel, Schmidt & Vawter   Distributed Area Lighting Boyd   Flight Simulator X-Plane - A Postmortem: Profiting on the Web Meyer   Getting Cinematic Quality from In-Game Cutscenes without a Hollywood Budget Hancock   Inverse Kinematics: Setup and Techniques Coven   Level-of-Detail Rigid Body Physics Golding   Sound Propagation in 3D Environments Carollo   Startup Horror Stories Morten   Business and Creative Aspects of Sequels Muzyka, Smith, Smith, Spector & Zeschuk   Creating Stars and Planets in Earth and Beyond Wang   Fundamentals of Lighting and Perception: The Rendering of Physically Accurate Images Dutre, Pattanaik & Yee   Game Boy Advance Networking Mataga   Multi-Scale Community Design for Games Kim   Publishers Speak 2002: What it Really Takes to Get a Publishing Deal Rogers & Summers   Seaman: Creating an Eccentric Title Saito   So Many Polys, So Little Time: Modeling and Texturing Rogue Leader Hoppe,Topolos&Wagner   Staying on Time and on Budget: Processes, Milestones and Schedules Daglow   The Audio Production for Halo O’Donnell   Cloth Simulation in Final Fantasy: The Spirits Within for PlayStation 2 Banel   Design Fundamentals of Stealth Gameplay in the Thief Series Smith   Fun and Games Conway   Creating the Illusion of Intelligence: Where AI and Level Design Overlap in Halo’s AI Butcher & Griesemer   Moving to Multiple Projects Muzyka & Zeschuk   MultiStream: Design and Implementation Page   Storytelling in the Online Medium Koster & Vogel   The Quest for Pure Motion Capture Washburn   Two Dozen Ways to Screw Up a Perfectly Good Project Rohrl   Venture Capital Bootcamp for Game Startups Long   3D Performance and Optimizations for the ARM Architecture Kolli Slides Action-Based Discretization for AI Search Neller   Building a Data-Driven Game Engine: A Case Study from Age of Mythology Fermier   Creating 3D Assets that Perform Well on 3D Hardware Penttinen   Game Audio Production: Process and Strategy Bajakian   Know Your Audience: Writing Design Documents That Get Read Upton   Managing Large-Volume Text Translations in Computer Games Christou & Moar   May Time Be with You: Level Designing Rogue Leader Chen & Klie   The Cultural Study of Games: More than Just Games Southern   The Secret Of Psalm 46 Moriarty   Creating Useful Technical Design Documents Taylor   Enter the Dragon: The Chinese Game Industry Ye   Negotiating the Best Deal Possible Powell   Polygon Soup for the Programmer’s Soul: 3D Pathfinding Hjelstrom & Smith   Race Against Time: How to Build a Driving Game Gabell   Real-Time Hatching Cebenoyan, Domine & Rege   Supporting Scalability as Artists Bradley, Burke & Seitz   The Evolution of the Fantasy Role: Playing Genre using Project Ego as an Example Molyneux   Why They Won’t Let You Make Great Online Games Baron   GDC 2003The sessions that we know about are listed in the table below: Title Presenter Notes 10 Great Reasons You Don’t Want to Make a Massively Multiplayer Game! Gordon Walton Business and Legal 20/20 Design Vision Andrew Leker (Electrified Games, Inc.) Game Design 34 Ways to Create Emotions in Games David Freeman Game Design A Review of Current and Future Animation Issues Paul Steed Visual Arts A Review of Funding Models for the Independent Developer and Their Impli… Jeff Hilbert Business and Legal Advanced Real-Time Illumination Techniques Nathaniel Hoffman Programming Advanced Techniques in Creating Tile-Based Graphics for GameBoy Advance Karthik Bala Visual Arts Animation Blending: Achieving Inverse Kinematics and More Programming   Animation System Implementation: What Works and What Doesn’t Jake Simpson Programming Applying the Lessons Learned from Korea and Lineage to Today’s and Tomorrow’s Online Games Business and Legal   Art Directors Panel: Aesthetics and the Almighty Dollar Cyrus Lum Visual Arts Audio Programming for Very Large Projects David Ranyard (Sony) Audio Aural Subjectivity: A Personal Perspective   Audio Automated Testing of Massively Multiplayer Games: Lessons Learned from The Sims Online Larry Mellon Programming Beyond Bouncing Boxes: The Physics of Things That Bend and Break John O’Brien Programming Bossy Behavior: Patterns and Techniques in Boss Design Luis Barriga Game Design Breaking the Rules of a Game Katie Salen Game Design Building AI Sensory Systems Tom Leonard Programming Building An Object System: Features, Tradeoffs, and Pitfalls Programming   Casual Games Panel John Vechey (PopCap Games) Game Design Character Rigging and Animation: Parts 1 & 2 Martin Coven Visual Arts Completion Bonding for Game Development Projects   Business and Legal Composing, Producing and Implementing an Interactive Music Soundtrack for a Video Game Chuck Doud Audio Control Where it Belongs: Latest Generation Audio Development for Xbox Scott Selfon (Microsoft) Audio Crack Character Creation: The Mad Puffer Fish Panel Scott Campbell Visual Arts Creating a Cinematic Game Experience   Game Design Creating Aesthetic 3D Organic Volumes and Using the Right Tools for the Project   Visual Arts Creating Character Models: A Review of Current Techniques Stefan Henry-Biskup Visual Arts Creating the Worlds of Dungeon Siege   Game Design Custom STL Memory Allocators   Programming Deathmatch: Ted Price vs. Jason Rubin Ted Price (Insomniac Games) Game Design Design With Music In Mind: Integrating an Immersive Game Score With Your… Guy Whitmore (PopCap) Audio Designing a Portable Shader Library for Current and Future APIs Alex Vlachos (Valve) Programming Designing a Ratchet & Clank Level Brian Allgeier Game Design Designing Original Games Based on Licensed Properties Chris Charla (Microsoft Game Studios) Game Design Designing Power-Ups for Action Games: Parts 1 & 2 Randy Smith Game Design Developing Wireless Games: From Idea to the Marketplace Oliver Miao (Pixelberry Studios) Business and Legal Displacement Mapping Tom Forsyth Programming Does Melody Matter? Rod Abernethy (Rednote Audio) Audio Doing Business with the Telecom Industry: Understanding their Deal Terms… Dan Scherlis (Sonamine) Business and Legal Dynamics for Designers Will Wright (Stupid Fun Club) Game Design Enabling Data Driven Design Tuning via Existing Tools Programming   Episodic Content: Here, Now & Next Month Too Chris Foster (Harmonix Music Systems) Game Design Exploring the Fringes: Interactive Entertainment for the 21st Century Ernest Adams (International Hobo) Game Design Extreme Character Rigging: When Less is More Steve Theodore (Undead Labs) Visual Arts Facial Animation For Game Characters   Visual Arts Fast Proximity Queries for Large Game Environments Ming Lin Programming FilmGame: Adapting Lord of the Rings Neil Young Game Design Findings of IGDA’s 2002/2003 Online Games Whitepaper Jeferson Valadares (Playfish) IGDA Five Physics Simulators for a Human Body Chris Hecker Programming Fooling All of the People All of the Time Bill Kroyer Visual Arts Frame Buffer Postprocessing Effects in DOUBLE-S.T.E.A.L (Wreckless): Par… Programming   Freedom of Expression: Dealing with the Threat of Censorship Jason Della Rocca IGDA Game Audio : Coding Vs. Aesthetics Leonard Paul Audio Game Design Patterns   Game Design Geometric Algebra: The Framework for Geometric Computations   Programming Geometric Modeling of Sound Propagation   Audio Going Global: Effective Strategies for Protecting Intellectual Property …   Business and Legal Great Game Graphics… Who Cares? Jason Rubin (Naughty Dog) Game Design Halo: Development Evolved Marty O’Donnell (Bungie) Game Design Hardware Shaders for the Artist John Versluis Visual Arts High Dynamic Range Imagery and Image-Based Lighting   Programming Highly Detailed Continuous Worlds: Streaming Game Resources From Slow M…   Programming How to Build a Better Cutscene   Visual Arts How to Make Your Game Successful in Japan Rio Hasegawa (Sony) Game Design How to Mix Discrete Surround Sound for PlayStation 2 Jason Page (SCEE R&D) Audio How to Take Your Mobile Game to Market John Chasey (FinBlade Ltd) Business and Legal How to Write Good “Bad Dialogue”: Cramming Storytelling Into an Action Game Ryan Kaufman (Telltale Games) Game Design Interactive Mixing Scott Gershin (Soundelux Design Music Group) Audio Korea, Where Multiplayer Gaming is King Won Il Sue Business and Legal Little to Big: What Changes? Frederick Brooks, Jr. Programming Living in a Procedural World: Growing a Virtual Forest   Programming Making Games More Fun: Methods for Playtesting Games Bill Fulton Game Design Making Sound Designers Independent: Techniques to Integrate Audio into G…   Programming Memory Optimization Christer Ericson Programming Mobile Games: Japan and the Future David Collier Business and Legal Negotiating the Best Deal Possible Jay Powell Business and Legal Neverwinter Nights Client/Server Postmortem Mark Brockington Programming Old School: Arcade Games in the Golden Age Mark Cerny Game Design On All Levels Dustin Browder (Blizzard) Game Design Optimized Stenciled Shadow Volumes Cass Everitt Programming Orthogonal Unit Design Harvey Smith Game Design Pathematics: Routing for Autonomous Agents Alex Champandard (AiGameDev.com) Programming PC to Console: Bringing Star Wars Jedi Knight II: Jedi Outcast to Xbox a… Karthik Bala Game Design Physics and Animation, Blending Kinetics and Kinematics in a 3rd Person … David Wu Programming Physics-Based Synthesis of Sound Effects   Audio Porting a PlayStation 2-Centric Game to the Xbox: A Case Study of State …   Programming Preserving the Past - The Panel Greg Costikyan IGDA Producing Orchestral Scores for Games Daniel Irish (Threewave Software) Audio Product Success in Online Software Distribution John Vechey (PopCap Games) Business and Legal Profiling the Female Gamer: A Look at How She Buys and Plays Clarinda Merripen (Cryptic Studios Game Design Proven Strategies for Self-Publishing on the Internet: Real-Life Storie… John Vechey (PopCap Games) Business and Legal Real-Time Fluid Dynamics for Games   Programming Relinquishing Control: Giving Programmers Control of Your Animation Assets David Stripinis Visual Arts Representational AI Planning Techniques   Programming Reputation Systems: Saving Your Service   Game Design Sandbox Strategy Learning in Sports Games   Programming Scaling the Software Development Process: Lessons Learned From The Sims … Larry Mellon Programming Sequels and Adaptations: Design Innovation in a Risk-Averse World Warren Spector (Ion Storm) Game Design Show Me The Money! Revenue Models for Massively Multiplayer Online Games Brian Green Business and Legal Simulation and Animation with Hardware-Accelerated Procedural Textures Mark Harris (NVIDIA) Programming Small Worlds: Competitive and Cooperative Structures in Online Worlds Raph Koster Game Design Smartly Define and Use Your Audio Budget   Audio SOCOM: Bringing a Console Game Online   Game Design Spherical Harmonic Lighting: The Gritty Details Robin Green (Microsoft) Programming Squeezing Every Last Drop Out of the PlayStation 2   Programming State of the Art: Building 3D Environments and Models Review Panel Chris Williams (PlayFirst) Visual Arts Stepping Away From the Pack: Resources and Methods for Developing Art St… David Rose (Neversoft) Visual Arts Story and Gameplay Are One Jesse Schell Game Design Story Summit Patricia Pizer Game Design Temptation and Consequence: Dilemmas in Videogames Steve Bocska (Pug Pharm Productions Inc. Game Design The 12 Principles of Traditional Character Animation Applied to 3D Compu… Visual Arts   The Continuous World of Dungeon Siege Scott Bilas Programming The Good and the Bad: A Second Chance Peter Molyneux (Lionhead Studios) Game Design The Intellectual Property Realm: New Challenges for the Developer Stephen Rubin (Law Office of Stephen Rubin) Business and Legal The Puzzlemaker’s Survival Kit: Principles, Case Studies and Design Process Scott Kim Game Design The Seven Secrets of Voiceover Production   Audio The Social Significance of Games: Killing our Monsters   IGDA The Technology of Jak & Daxter: Our Techniques for Realizing a Massively… Stephen White Programming Three Great Mobile Games Matthew Bellows Game Design Toward Massively Responsive Conversations Sheldon Pacotti Game Design Towards Building a Fully Realized Interactive Drama Andrew Stern Game Design U.S. Immigration Issues for Game Developers   Business and Legal What It Takes To Run a Successful Game Studio Todd Hollenshead (ID SOFTWARE) Business and Legal When the Site Hits the Fan: Wrangling Community Fansites Elonka Dunin Business and Legal GDC 2004 - EvolveThe 2004 Game Developers Conference had the theme “Evolve”, emphasizing the industry’s shift towards middleware and robust production processes. The dominance of licensed titles and sequels was noted, with Dave Perry discussing these trends in his keynote.A session on building big licensed games highlighted the industry’s evolution from smaller teams to larger projects with 25 to 75 people and budgets ranging from $3 to $40 million. The need for well-organized processes and formal development procedures was emphasized, posing a non-technical challenge of integrating these without stifling creativity.GDC 2004 highlights included: Programming Keynote by John Carmack on bleeding-edge engine development. Visual Arts Keynote by John Gaeta called From Visual Anti-Establishment to Ubiquity and Back. Sony showcased the PSP as a powerful, easy-to-develop-for device. Microsoft unveiled XNA, a development framework for future platforms.Many of these sessions are freely available on the GDC Vault. However, bear in mind that some of the metadata such as presenters are incorrect on their site and we have a cleaned up version in the table below: Title Presenter Track Notes “Port” is a Four-Letter Word: The Challenges of Redesigning The Sims fo… Michael Perry (Electronic Arts, Inc.) Game Design   10 Tricks from Psychology for Making Better Characters Katherine Isbister Game Design   14 Ways of Drawing Players in with an Opening Cinematic David Freeman Game Design   Island Thunder and Raven Shield : Creating Believable Stories for Realistic Games Richard Dansky (Red Storm Entertainment/Ubisoft) Game Design   Republic : Lessons Learned Dave Dixon Production   The Hobbit : A Case Study Christopher Michael Audio   Wallace and Gromit in Project Zoo: A Postmortem of a Licensed, Cross-Platform Game Warren Kruse Production   A Candid Look at the Issues and Rewards of Bleeding Edge Engine Development Tom Peltier Programming   A Peek Behind the Shoji: Japan’s Videogame Market Today Rio Hasegawa (Sony Computer Entertainment Japan) Game Design   A Road Map for Peace: Redefining the Publisher-Developer Relationship Joe Minton Business and Legal   Accurate Prediction and Other Organizational Myths Starr Long Production   Acting for Animators Douglas Conorich Visual Arts   Adding Spherical Harmonic Lighting to the Sushi Engine Leander Hasty Programming   Advanced Real-Time Reflectance Thomas Peltier Programming   Adventures in Character Design Tim Schafer Game Design   AI and Design: How AI Enables Designers Rishi Bhattacharya Programming   AI: Gameplay & Design: A Marriage of Heaven or Hell? Michael Corby Programming   Anatomy of a 2D Side-Scroller Michael Rasmussen Game Design   Artificial Potential Fields for the Control of Navigation and Animation Paula Moore Programming   Artist Management in a Small Games Company Production     ArtModJam Seth Fogie Game Design   Audio Asset Management for Large Projects David Chan (Hinterland Studios) Audio   Audio Director to the Rescue Andrew Boyd Audio   Audio for Mobile Panel James Doyle Audio   Automation Recipes: Automation Ideas to Save Project Time and Money Jennifer Boespflug Production   Behavioral Game Design John Hopson (Bungie Inc.) Audio   Beyond Finite State Machines: Managing Complex, Intermixing Behavior Hierarchies Joseph W. Popinski III Programming   Beyond Fun: Setting Aesthetic Goals and Sticking toThem Tim Stellmach (Harmonix) Game Design   Building a Million Particle System Cheryl Jackson Programming   Building Big Licensed Games with Big Teams Don Daglow (Daglow Entertainment LLC) Production   Building Value in Your Company: One Small Studio’s Approach Business and Legal     Character Rigger’s Cookbook Steve Theodore (Undead Labs) Visual Arts   Common C++ Performance Mistakes in Games Pete Isensee Programming Xbox Creating Water and Fluid Effects For Video Games Cyrus Peikari Visual Arts   Creating a Monster RPG: The Light and the Dark Side of Development on St… William Murray Production   Creating the Right Mix of Static Versus Dynamic Content in a Massively… Scott Anderson Game Design   Cross Platform User Interface Development Tim Stellmach (Harmonix) Game Design   Cross-Platform Audio Using Interactive XMF Jessica Bayliss Audio   Deferred Shading on DX9 Class Hardware and the Xbox Matt Pritchard Programming   Designing an Interactive Music System Jason Booth (Harmonix Music Systems) Audio   Designing Games for Coin-Op and Internet Gambling   Game Design   Destruction on a Diet Paul Lindberg Programming   Developing and Mastering 36 Different Sku’s of One Title Simultaneously for the PS2 & Xbox Michael Corby Production   Developing Wireless Location-Based Games Programming     Digital Painting, and The Narrowing Gap between Games and Film Paula Moore Visual Arts   Doing Business with Europe: A Survivor’s Guide Vincent Scheurer Business and Legal   Encouraging Innovation in Game Development Rebecca Herold General Interest   Entering the World: Cognitive Dissonance and Immersion in Electronic Games Hal Barwood (Finite Arts) Game Design   Entertainment Experience First, Videogame Second: The Making of The Return of the King Scott Baker Game Design   ESRB Explained: Behind the Ratings Robert Richardson IGDA   Everything You Need to Know to Make Money in Coin-Op   Business and Legal   Experimental Gameplay Workshop Daniel VanBelleghem Game Design   Fast Yet Realistic Deformation and Fracture James O’Brien Programming   Follow The Money: Understanding Console Publishers   Business and Legal   Four at a Time: Techniques for Maximizing Enemy and Object Placement Chris Cross Game Design   From Script to Joystick: World-Building 101 Sharon Ruckman Game Design   From Visual Anti-Establishment to Ubiquity and Back John_Gaeta Visual Arts   Game Design Challenge: The Love Story David Lynas Game Design   Game Design Methods of ICO Eamon Neary Game Design   Game Design: Risk and Return Masahiro Sakurai (Sora Ltd.) Game Design   Game Development Modeling with 3ds Max Fred Trickery Visual Arts   Game Mobility Requires Code Portability Guido Henkel Programming   Game Narrative: What Would Aristotle Do? Tim McCarthy Game Design   Game Prototyping with 3ds Max Zoe Strickland Visual Arts   Game Soundtracks: Structuring Your Deal Like the Movies Fred Tompkins Audio   GDC Programming Keynote: John Carmack John Carmack (iD Software) Programming   Great Games in 50k: Three Addictive Mobile Phone Titles Thomas Peltier Game Design   Growing a Dedicated Tools Programming Team: From Baldur’s Gate to S… Production     Hi Res Modeling for Consoles in Maya Wendi Rafferty Visual Arts   High Dynamic Range Lighting John O’Leary Programming   How to Budget Audio: ‘What Am I Forgetting?’ Terry Gudaitis Audio   How to Get More Coverage for Your Company and Titles Sue Bohle Business and Legal   HR in the Studio   Business and Legal   IGDA Quality of Life White Paper Unveiling Gregory Abrenio IGDA   Immigration for Foreign Games Professionals in the Age of Homeland Sec… Kevin Kingdon Business and Legal   Industry & Government: Working Together Rishi Bhattacharya Business and Legal   Integrating Physics into a Modern Game Engine Rishi Bhattacharya Programming   Interfacing With Hollywood: Challenges and Opportunities Harvey Smith Business and Legal   Jak’s Makeover for JakII : Why the Dramatic New Look for a Sequel?   Visual Arts   Learning by Design: Games as Learning Machines Mark O’Neill IGDA   Lemke’s Algorithm, The Hammer In Your Math Toolbox? Chris Hecker (Formerly Technology Fellow at Maxis) Programming   Light Scattering: Oh, that Looks Cool! Can we Have it in the Game, Real … Derek Palmer Programming   Make Better Criticism: A Mature Form of Cultural Analysis J.R. Reagan IGDA   Managing the Hydra: Successfully Running Multiple Projects in a Videog… Michael Corby Production   Master Your Game’s Domain: Data-Driven Asset Management Warren Kruse Production   Maya for Games - Tools & Pipelines in Maya Matthew Luallen Visual Arts   Minefields in Videogame Intellectual Property Protection Stephen Rubin (Law Office of Stephen Rubin) Business and Legal   Mixing and Mastering Music and Sound for Games Scott Gershin (Soundelux Design Music Group) Audio   Mobile Games: Lessons from Online Games Dan Scherlis (Sonamine) Business and Legal   Motion Capture-driven Simulation for Characters Lisa Schlosser Programming   Motion Synthesis Terri Curran Programming   Music Licensing for Videogames: How Popular Music and Artists Can Make … Victor Rodriguez (THQ) Business and Legal   Music Publishing: A Primer for Game Developers and Composers Douglas Conorich Business and Legal   Open Spaces and How to Find Them in New Game Ideas Thomas Peltier Game Design   Outdoor Jungle Vegetation: Battlefield Vietnam Rishi Bhattacharya Visual Arts   Pitching an Original IP: Notes from the Field Chris Charla (Microsoft Game Studios) Business and Legal   Practical Implementation of High Dynamic Range Rendering John Williams Programming   Practical Physics for Articulated Characters Rishi Bhattacharya Programming   Practical Shadows: Out of the Demo and Into the Engine Tom Forsyth Programming   Prepping for the Transition: Will You Be Ready? John Schappert (Zynga) Business and Legal   Procedural Shaders: A Feature Animation Perspective Arcot Preetham (ATI) Programming   Producing Motion Capture and Animation Paul Immo Production   Producing Orchestral Scores for Games John O’Leary Audio   Producing Programmers: Strategies for Managing Technical Staff Pierre-Luc REFALO Production   Producing the Characters and Creatures of Ultima X Odyssey Brenda Brathwaite Visual Arts   Through Collaboration: Escalating Demands on the Producer Dave Perry Production   Programming the PlayStation Portable (PSP) Bryan Fletcher Programming   Re-awakening a Classic: Prince of Persia: A Case Study   Production   Real World Multi-Threading in PC Games Arron Coday (Intel) Programming   Real-Time Global Illumination Eskil Steenberg Programming   Real-Time Translucent Animated Objects Fred Trickery Programming   Realistic and Fast Cloud Rendering in Computer Games   Programming   Requirements for a Next Generation Massively Multiplayer Online Game Gordon Walton Production   Reusing Shading for Interactive Global Illumination Programming     Revisiting the Standard Joint Hierarchy: Improving Realistic Modeling of…   Programming   SciFi MMPs: Lessons from Star Wars Galaxies and Earth and Beyond Raph Koster (Independent) Game Design   Seven Years of Max Payne   Production   SOCOM II: Creating a Compelling Online Console Game Richard Murphy Game Design   Sound Design: Strategies for Success Thomas Rude Audio   Spare No Expense: Starbucks and Aeron Chairs for Everyone Business and Legal     Starting a New Studio John Hayes Business and Legal   State of the Art: Anatomy of 3D Level Design Herve Schmidt Game Design   Storytellers vs. Puzzle-Makers: New Traits of Successful Games Kevin Bachus (Nival Interactive) Business and Legal   Storytelling in Earth & Beyond   Game Design   The Civilization Series: How to Maintain a Successful Franchise Soren Johnson (Mohawk Games) Game Design   The Full Spectrum Warrior Camera System Thomas Peltier Programming   The Collection and Applications of Metrics in an MMP Game: Lessons Lea… Larry Mellon Programming   The Easy Route To Console Online Thomas Peltier Production   The Emotional Heart of Art Direction   Visual Arts   The End Game: How Top Developers Sold Their Studios Dan Rogers Business and Legal   The Evolution of a Franchise: The Legend of Zelda Eiji Aonuma (Nintendo Co., Ltd.) Game Design   The History of Animation Paul Hormis Visual Arts   The I-Spy Book of Developer Contract Law   Business and Legal   The Impact of Middleware Technologies on Your Game Development Thomas Peltier Production   The Interesting Thing About Bishops: Simulation Boundaries in Splinter Cell Clint Hocking Game Design   The Interface: How to Create an Effective Audio Schedule Troy Larson Production   The Making of the Official Counter-Strike Bot Michael Booth (Valve) Programming   The Negotiation Tom Buscaglia (Dev Biz, Inc.) Business and Legal   The Philosophical Roots of Computer Game Design Ernest Adams (International Hobo) Game Design   The Physics-Sound System of Deus Ex: Invisible War and Thief 3 Brian Sharp (Bungie, LLC) Programming   The Secret of Pac-Man ‘s Success: Making Fun First Chris Cook Game Design   The Sound Design Methodology of Medal of Honor Frank Butler Audio   The State of Non-Linear Audio for Interactive Media Pete Garza Audio   The State of the Web and Downloadable Games Industry: A 2004 IGDA Online… Derrick Morton (FlowPlay) Business and Legal   The Virtual and Mixed Media Orchestra for Game Music   Audio   The Well-Fed Freelancer: A Survival Guide in 24 Easy Lessons Francois Dominic Laram’e Business and Legal   Tips & Tricks for UV Mapping Keith Self-Ballard Visual Arts   Tips and Tricks for 3ds max 6 in Games Phillip Hallam-Baker Visual Arts   Towards Relevant Research: Collaboration 101 Stephen Gantz IGDA   Triangulation: A Schizophrenic Approach to Game Design Will Wright (Stupid Fun Club) Game Design   True Crime: Streets of L.A.-Bringing Crime to the City of Angels Rishi Bhattacharya Programming   Turning Innovation into Impact J Allard Audio   Understanding the Elements of Employee Compensation   Business and Legal   User-testing in a Hostile Environment: Overcoming Apathy and Resistance … William Stackpole Production   Using External Contractors Effectively Jessica Bayliss Production   Using Verlet Integration and Constraints in a Six Degree of Freedom Rigi… Programming     Visualizing Sly Cooper Brad Smith Visual Arts   What Got Left out of Battlefield 1942 Dennis Brixius Game Design   What Lies Ahead in the Ever-evolving Interactive Entertainment Industry? Tim McCarthy Game Design   What to Do When it All Goes to Hell: Lessons Learned Shutting Down a G… Cody Northrop Business and Legal   Why We Play Games: The Four Keys to Player Experience Nicole Lazzaro (XEODesign) Game Design   Winning the Race Against Pirates And Crackers: Next Generation Copy Pr… Jeff Orkin Production   Workflow Convergence: How Motion Picture Pipelines Are Merging With Game… Robert J. Thornberry Jr Visual Arts   Would the Real Emergent Gameplay Please Stand Up? Todd Fitzgerald Game Design   Zoological Gardens: The Science of Creature Design Greg Gabet Game Design   John Carmack KeynoteIn his 2004 Game Developers Conference (GDC) keynote speech, John Carmack discussed the history of video games, the progress that has been made in the industry, and his predictions for the future.Carmack started by talking about his own experiences, recalling his first computer, a VIC-20 with 4 KB of RAM and a 1 MHz processor. He mentioned that the first commercial program he sold was developed on an Apple IIc with 128 KB of RAM and 8 KB of video memory.Carmack noted the progress in the video game industry since he started, with a factor of a million difference in power between the VIC-20 and today’s computers. He also said that early computer games were very niche, while now we have things that can appeal to a wider audience.For the future, Carmack said he is confident that there will be more progress and hopes that there will be a place for innovative and exciting new things in the industry.Carmack concluded his speech by saying that he is very excited about the future of video games. He believes that the industry has the potential to do great things, and he is looking forward to seeing what the future holds.One Day Tutorial - OpenGL (Tuesday 23rd March 2004)Sponsored by both NVIDIA and ATI was a full day tutorial on OpenGL graphics programming, all the slides are available on NVIDIA’s website - GDC 2004 - NVIDIA Developer and you can see the schedule below: Time Session Name 10:00 - 10:10 Introduction – Simon Green 10:10 - 11:00 OpenGL Shading Language Overview – Bill Licea-Kane 11:00 - 11:15 Break 11:15 – 11:30 OpenGL Shading Language (continued) 11:30 - 11:45 NVIDIA OpenGL SL implementation + demos – Simon Green 11:45 - 12:30 OpenGL 2.0 proposed extensions – Cass Everrit 12:30 - 2:00 Lunch 2:00 - 2:45 New ATI extensions (“Uber” buffers) – Rob Mace 2:45 - 3:30 New NVIDIA extensions + demos – Simon Green 3:30 - 4:00 Tools and Libraries – Sebastien Domine, Evan Hart 4:00 - 4:15 Break 4:15 - 5:00 Performance Optimization – Evan Hart 5:00 - 5:45 General Purpose Computation for Games in OpenGL – Mark Harris 5:45 - 6:00 Conclusion, Q&A One Day Tutorial - DirectX (Monday 22nd March 2004)We don’t have the schedule for the DirectX sessions that were sponsored by a number of companies (Microsoft, Nvidia, Valve, ATI, Sony and Climax) but we do have some of the slides available on Nvidia’s website - GDC 2004 - NVIDIA Developer.One Day Tutorial - Professional Java Game Development Techniques (Tuesday 23rd March 2004)Although there are no slides or videos available from this tutorial day, the exact same authors (Dustin Clingman, Shawn Kendall, Syrus Mesdaghi) wrote the book Practical Java Game Development (Game Development Series) which was published in 2004, so it is very likely that all the content used at this tutorial is available in the book.GDC 2005+GDC 2005 was the first to be hosted in San Francisco and brought in a record 12,000 attendees 2.Thankfully all the sessions for 2005 and onwards seems to have audio recordings (and some videos!) freely available on the GDC Vault: GDC VaultSatoru Iwata Keynote - Heart of a GamerSatoru Iwata was the president of Nintendo at the time of the 2005 Keynote, his speech titled “Heart of a Gamer” was about the history of Nintendo and his own experiences as a game developer.Iwata begins by talking about his first experience with video games, playing Pong as a child. He then talks about his early days as a game developer, creating games for the Nintendo Entertainment System (NES). He discusses the importance of creating games that are fun and challenging for all players, regardless of their skill level.Iwata also talks about the importance of innovation in the video game industry. He discusses Nintendo’s efforts to create new and innovative gaming experiences, such as the Wii console and the Nintendo DS handheld system. He also talks about the importance of supporting third-party developers in order to create a diverse and vibrant gaming industry.Finally, Iwata talks about his own personal philosophy as a game developer. He says that he believes that the most important thing is to create games that are fun and that bring joy to players. He also says that he believes that game developers should always be striving to create new and innovative experiences.Overall, the video is a reflection on the history of Nintendo and the importance of innovation in the video game industry. It is also a personal story about Iwata’s own experiences as a game developer.References JCGD Volume 2 Issue 1 ↩ Game Developers Conference (Concept) - Giant Bomb ↩ ↩2 Computer Game Developers Conference 1991 audiotape catalog ↩ ↩2 Computer Game Developers Conference 1993 audiotape catalog ↩ The History of Game Developers Conference (documentary, 2019/2020) - YouTube ↩ Game Developers Conference Online - Press Area ↩ GDC 2000 - GameSpot ↩ Game Developers Conference 2000: Special Events ↩ ", "excerpt": "GDC stands for the “Game Developers Conference”, which is an annual event held for professionals in the video game industry. Originally it was called the Computer Game Developers Conference but the Computer was dropped to focus on video games as a whole rather than just “Computer Games”. GDC serves as...", "tags": ["industry"], "image": "https://github.com/user-attachments/assets/d3665255-3b43-4787-819f-92a49fcd1030", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Tiger Game (dot) com Reverse Engineering", "url": "/gamecom", "content": "IntroductionWelcome to our page dedicated to Tiger Game(dot)com reverse engineering! The Tiger Game com was a handheld gaming console that was released in 1997, and was notable for being one of the first gaming consoles to feature a touchscreen interface.If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to the right place. On this page, we’ve compiled a list of links to other pages that cover various topics related to Game(dot)com reverse engineering.Whether you’re interested in understanding the hardware architecture of the console, analyzing game code, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to.So grab your Game(dot)com and get ready to dive into the exciting world of Game com reverse engineering!GamesCastlevania Symphony of the NightOne of the best games, if not THE best game for the Tiger Game com was Castlevania SotN but unfortunately it was cancelled before official retail release. Luckily a prototype was dumped in 2022 and it is fully playable. If you are looking for a game to reverse for the Tiger Game(dot)com this one is probably the most interesting!HardwareIf you’re interested in reverse engineering software for the Tiger Game(dot)com handheld console, it’s important to have a strong understanding of the hardware that powers it. By comprehending the inner workings of the Game(dot)com hardware, you can better understand how the software interacts with the hardware and how you can potentially modify or enhance it.This section of our guide will provide you with detailed information and resources on the hardware of the Tiger Game(dot)com, including retail, prototype, and development hardware.Development Kit HardwareThe only reference I can find about Tiger(dot)com development hardware is on the following page: Tiger Game.com 101: A Beginner’s Guide - RetroGaming with RacketboyIt says: Matt Scott, the owner of Byte-Size Sound, was hired as a subcontractor to create audio for specific Game(dot)com games. He later sold his development kit and software for around $700 on eBay in 2006.The buyer was Brandon Cobb who has an excellent website on the Game com: The end of the game.com.But sadly no images of this development kit seem to be available on the site and the eBay link will be long gone by now.", "excerpt": "Introduction Welcome to our page dedicated to Tiger Game(dot)com reverse engineering! The Tiger Game com was a handheld gaming console that was released in 1997, and was notable for being one of the first gaming consoles to feature a touchscreen interface. If you’re interested in learning more about the technical...", "tags": ["handhelds"], "image": "/public/generated/placeholders/gamecom.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "How MAME Emulates Game & Watch", "url": "/game-and-watch-emulation", "content": "How MAME Emulates Game & WatchGame & Watch emulation in MAME is hardware emulation, not game reimplementation.The actual machine code dumped from original Nintendo microcontroller chips runs unmodified.MAME replicates the Sharp SM5xx CPU, the LCD segment controller, multiplexed inputs, and piezo buzzer - the game logic follows automatically.Glossary of Key TermsIf you are new to the hardware involved, this quick glossary explains the key terms used throughout: MCU - Microcontroller Unit. A self-contained chip combining CPU, RAM, ROM, and I/O peripherals. Each Game & Watch unit contains one Sharp SM5xx MCU. LCD - Liquid Crystal Display. The segment-based screen used in G&W games. Individual segments switch on or off; they do not form pixels. ROM - Read-Only Memory. The game program, permanently baked into the MCU die. ACL - All Clear. The reset button found on every G&W unit, tied directly to the MCU reset line. SVG - Scalable Vector Graphics. The format MAME uses to describe LCD panel geometry, with each segment as a named vector shape. LFSR - Linear Feedback Shift Register. A shift register whose output feeds back as input, producing a pseudo-random sequence. The SM5xx uses a 6-bit LFSR as a program counter within each ROM page. LUT - Look-Up Table. A precomputed array used in the SM511 melody controller to translate tone commands into duty cycle counts. BL/BM - The lower and upper halves of the SM5xx RAM address register. Together they select the current 4-bit RAM nibble.The Sharp SM5xx CPU Family🧩Nintendo used a family of 4-bit Sharp microcontrollers across the Game & Watch product line.Each variant differs in ROM capacity, RAM layout, and peripheral features.All variants share a common instruction set and are emulated through a single inheritance hierarchy in src/devices/cpu/sm510/.The table below covers the main variants you will encounter when exploring MAME drivers: Name ROM RAM Notes SM5A 1.8 KB 5x13x4 nibbles Oldest series, ~1980 SM510 2.7 KB 128x4 nibbles Standard series, non-contiguous ROM map SM511 4 KB 128x4 nibbles Adds dedicated melody controller SM512 4 KB 160x4 nibbles SM511 with extended LCD RAM SM530 2 KB Varies Later variant, used in select titles The Soviet Union manufactured licensed clones of these chips, renaming them to КБ1013ВК1-2 (SM5A), КБ1013ВК4-2 (SM510), and КБ1013ВК7-2 (SM511).MAME supports Soviet Elektronika G&W clones through the same driver.MAME’s shared SM5xx core source header also cites Sharp semiconductor data books as background documentation for the implementation 1 2. sm510base.h auto read_k() auto write_segs() auto write_r() virtual void execute_one() = 0 virtual bool op_argument() u16 get_lcd_row(int column, u8* ram) virtual void lcd_update() virtual void clock_melody() virtual void increment_pc() virtual void execute_run() void do_interrupt() u16 m_pc u8 m_acc u8 m_bl u8 m_bm u8 m_c bool m_skip bool m_halt u16 m_div u8 m_gamma 95 55 250 The sm510_base_device class defines the complete SM5xx interface.It declares 95 virtual methods - the majority being opcode handlers (op_tl, op_add11, op_cend, etc.) that subclasses override for variant-specific behaviour.The 55 member variables cover CPU registers, LCD state, the divider, melody controller state, and I/O callbacks.Relevant interface definition 3. CPU Architecture⚙️All SM5xx variants are 4-bit processors with a Harvard architecture.The core registers are:The following registers make up the CPU core state, accessed during every instruction: ACC (m_acc) - 4-bit accumulator. All arithmetic and logic operations pass through here. BL/BM (m_bl, m_bm) - RAM address register. BL holds the lower 4 bits, BM the upper bits. Together they index into the 4-bit RAM array. PC (m_pc) - 12-bit program counter. Advances via LFSR rather than simple increment. C (m_c) - 1-bit carry flag. Set or cleared by arithmetic operations, testable by TC (skip-if-no-carry). Skip (m_skip) - When set, the next fetched instruction is discarded as a NOP. Used to implement conditional branches. Halt (m_halt) - Puts the MCU into low-power standby. The CPU stays halted until an external K input or the gamma timer wakes it. W (m_w) - 8-bit output shift register. The WR/WS opcodes shift 0 or 1 into this register. PTW latches the value to the S output port. DIV (m_div) - 15-bit free-running divider. Increments every crystal tick. Provides time references for the LCD refresh, melody controller, and the gamma interrupt.The execute loop is the heart of the emulation.It runs until the instruction count budget (m_icount) is exhausted.void sm510_base_device::execute_run(){ while (m_icount > 0) { // in halt mode, wake up after gamma signal or K input if (m_halt) { if (m_ext_wakeup || m_gamma) do_interrupt(); else { debugger_wait_hook(); m_icount = 0; return; } } m_icount--; m_prev_op = m_op; m_prev_pc = m_pc; if (!m_skip) debugger_instruction_hook(m_pc); m_op = m_program->read_byte(m_pc); increment_pc(); // 2-byte opcodes if (op_argument()) { m_icount--; m_param = m_program->read_byte(m_pc); increment_pc(); } // handle opcode if it's not skipped if (m_skip) { m_skip = false; m_op = 0; // fake nop } else execute_one(); }}Relevant source 4.Two-byte opcodes (such as TL xyz long jump and TML xyz long call) consume an extra cycle and read a second byte as m_param.If the skip flag is set, the fetched opcode is replaced with a fake 0x00 NOP rather than branching away - this means the 2-byte instruction is still consumed.Address Space and ROM LayoutThe SM510 and SM511 differ in how they map their program ROM into the address space.The SM510 uses a non-contiguous map across a 12-bit address space.The 704-byte pages are placed at specific offsets and the gaps in between are unmapped:void sm510_device::program_2_7k(address_map &map){ map(0x0000, 0x02bf).rom(); map(0x0400, 0x06bf).rom(); map(0x0800, 0x0abf).rom(); map(0x0c00, 0x0ebf).rom();}Relevant source 5.The SM511 uses a contiguous 4 KB region starting at address 0:void sm511_device::program_4k(address_map &map){ map(0x0000, 0x0fff).rom();}Relevant source 6.The data address map is identical between SM510 and SM511.The lower 96 bytes (0x00-0x5F) are general-purpose RAM.The upper 32 bytes (0x60-0x7F) are shared with the LCD controller as lcd_ram_a and lcd_ram_b.The SM512 adds a third shared region (lcd_ram_c) at 0x50-0x5F.void sm511_device::data_96_32x4(address_map &map){ map(0x00, 0x5f).ram(); map(0x60, 0x6f).ram().share(\"lcd_ram_a\"); map(0x70, 0x7f).ram().share(\"lcd_ram_b\");}Relevant source 6.The program counter advances within each 64-instruction page using a 6-bit LFSR rather than a plain counter.The LFSR produces a non-sequential order of addresses within the page - the game’s ROM must be placed at exactly the addresses the hardware would visit.void sm510_base_device::increment_pc(){ // PL(program counter low 6 bits) is a simple LFSR: newbit = (bit0==bit1) int msb = m_pagemask >> 1 ^ m_pagemask; int feed = ((m_pc >> 1 ^ m_pc) & 1) ? 0 : msb; m_pc = feed | (m_pc >> 1 & m_pagemask >> 1) | (m_pc & ~m_pagemask);}Relevant source 4.The upper bits of m_pc (PM and PU) select the page, while PL (the lower 6 bits) steps through the LFSR sequence.The Instruction Set📄The SM510 instruction set is compact and purpose-built for the G&W use case.Most opcodes are one byte. Long jumps and calls use two bytes. sm510op.cpp void op_tl() void op_tml() void op_rtn0() void op_t() void op_kta() void op_atl() void op_atx() void op_wr() void op_ws() void op_ptw() void op_add11() void op_rot() void op_cend() void op_pre() void op_tmel() 64 455 All 64 opcode handlers are defined here as methods of sm510_base_device.They cover five categories: RAM address manipulation, ROM address/control flow, data transfer and I/O, arithmetic and test, and melody control.Each opcode handler is a tiny function, typically 2-5 lines. The following examples show the key instruction categories, with their exact C++ implementations.Control FlowTL xyz performs a long jump to an absolute 12-bit address.The target is assembled from the 4-bit opcode low nibble and the full second byte:void sm510_base_device::op_tl(){ // TL xyz: long jump do_branch(m_param >> 6 & 3, m_op & 0xf, m_param & 0x3f);}TML xyz is the call variant - it pushes the return address onto the stack first:void sm510_base_device::op_tml(){ // TML xyz: long call push_stack(); do_branch(m_param >> 6 & 3, m_op & 3, m_param & 0x3f);}RTN0 returns from a subroutine by popping the stack:void sm510_base_device::op_rtn0(){ // RTN0: return from subroutine pop_stack();}Relevant source 7.I/O and LCD InstructionsThe game reads buttons via KTA (K-to-ACC).This is the primary way the game logic checks which buttons are pressed:void sm510_base_device::op_kta(){ // KTA: input K to ACC m_acc = m_read_k() & 0xf;}The WR/WS opcodes build up the S strobe output one bit at a time.WR shifts a 0 into the shift register W; WS shifts a 1.After building the desired strobe pattern, PTW latches it to the output port:void sm510_base_device::op_wr(){ // WR: shift 0 into W m_w = m_w << 1 | 0; update_w_latch();}void sm510_base_device::op_ws(){ // WS: shift 1 into W m_w = m_w << 1 | 1; update_w_latch();}ATL and ATX write the accumulator into the LCD control registers L and X.These affect which segments blink and which LCD common lines are active:void sm510_base_device::op_atl(){ // ATL: output ACC to L m_l = m_acc;}void sm510_base_device::op_atx(){ // ATX: output ACC to X m_x = m_acc;}Relevant source 7.ArithmeticADD11 is the carry-propagating add instruction.It adds RAM, ACC, and carry together, sets carry on overflow, and skips the next instruction if carry is set:void sm510_base_device::op_add11(){ // ADD11: add RAM and carry to ACC and carry, skip next on carry m_acc += ram_r() + m_c; m_c = m_acc >> 4 & 1; m_skip = (m_c == 1); m_acc &= 0xf;}ROT rotates the 4-bit accumulator right through carry.This provides a simple way to inspect individual bits:void sm510_base_device::op_rot(){ // ROT: rotate ACC right through carry u8 c = m_acc & 1; m_acc = m_acc >> 1 | m_c << 3; m_c = c;}Relevant source 7.HaltCEND stops the CPU clock and enters low-power mode.Games use this to idle between frames.The CPU remains halted until an external K input or the divider gamma signal fires:void sm510_base_device::op_cend(){ // CEND: stop clock (halt the cpu and go into low-power mode) m_halt = true;}Relevant source 7.ROM Data💾Each Game & Watch driver in src/mame/handheld/hh_sm510.cpp defines three categories of ROM data.The simplest example is Ball (AC-01), the very first Game & Watch game.It uses the SM5A and has a single LCD screen:ROM_START( gnw_ball ) ROM_REGION( 0x800, \"maincpu\", 0 ) ROM_LOAD( \"ac-01\", 0x0000, 0x0740, CRC(ac94e6e4) SHA1(8270cb61f9fbff252eafec411b4c67f0171f8687) ) ROM_REGION( 71748, \"screen\", 0) ROM_LOAD( \"gnw_ball.svg\", 0, 71748, CRC(7c116eaf) SHA1(578882af492b8a9f1eb72e06a547c8b574255fb9) )ROM_ENDRelevant source 8.The three ROM types are: Program ROM - The machine code dump from the MCU, placed at the program address space. ac-01 here is 0x0740 (1856) bytes of actual SM5A instructions. SVG file - A vector graphics description of the LCD panel. The \"screen\" region holds the entire SVG as raw binary data. MAME’s SVG renderer reads this at startup. Melody ROM - Only present on SM511 and SM512 games. A 256-byte region tagged \"maincpu:melody\" containing tone commands for the melody controller.Donkey Kong (DK-52) uses the SM510 with a dual vertical screen layout.It has 4 KB of program ROM and two separate SVG files:ROM_START( gnw_dkong ) ROM_REGION( 0x1000, \"maincpu\", 0 ) ROM_LOAD( \"dk-52\", 0x0000, 0x1000, CRC(5180cbf8) SHA1(5174570a8d6a601226f51e972bac6735535fe11d) ) ROM_REGION( 176843, \"screen_top\", 0) ROM_LOAD( \"gnw_dkong_top.svg\", 0, 176843, CRC(16c16b84) SHA1(fa2e54c04366a30b51de024296b9f94c1cb76d68) ) ROM_REGION( 145516, \"screen_bottom\", 0) ROM_LOAD( \"gnw_dkong_bottom.svg\", 0, 145516, CRC(2b711e9d) SHA1(0e263020cbe0e8b88bb68e3176630639b518935e) )ROM_ENDRelevant source 8.Notice that the SVG region sizes are exact byte counts, treated like any other ROM dump.Checksums (CRC and SHA1) verify the SVG file integrity the same way they verify a program ROM.The LCD Driver📄The LCD controller lives inside the CPU device itself, not in the driver.The CPU device exposes a write_segs() callback that fires once per LCD refresh cycle.The driver connects this callback to its own display processing pipeline. sm510base.cpp void device_start() void device_reset() u16 get_lcd_row(int column, u8* ram) void lcd_update() void lcd_timer_cb() void init_lcd_driver() TIMER_CB div_timer_cb() void init_divider() void execute_set_input(int line, int state) void do_interrupt() void increment_pc() void execute_run() 14 329 sm510base.cpp implements the shared infrastructure: startup, reset, the LCD controller, the divider timer, interrupt handling, PC advancement, and the main execution loop.Device-specific behaviour (opcode dispatch, ROM address maps) lives in the per-variant files. The init_lcd_driver() function creates a timer that fires at approximately 1 kHz.This matches the real hardware behaviour where the LCD is strobed once per 32 divider ticks:void sm510_base_device::init_lcd_driver(){ // note: in reality, this timer runs at high frequency off the main divider, // strobing one segment at a time m_lcd_timer = timer_alloc(FUNC(sm510_base_device::lcd_timer_cb), this); attotime period = attotime::from_ticks(0x20, unscaled_clock()); // default 1kHz m_lcd_timer->adjust(period, 0, period);}Relevant source 4.Each timer tick calls lcd_update().This function reads four columns of LCD data out of lcd_ram_a, lcd_ram_b, and lcd_ram_c, then fires the write_segs() callback for each:void sm510_base_device::lcd_update(){ // 4 columns for (int h = 0; h < 4; h++) { // 16 segments per row from upper part of RAM m_write_segs(h | SM510_PORT_SEGA, get_lcd_row(h, m_lcd_ram_a)); m_write_segs(h | SM510_PORT_SEGB, get_lcd_row(h, m_lcd_ram_b)); m_write_segs(h | SM510_PORT_SEGC, get_lcd_row(h, m_lcd_ram_c)); // bs output from L/X and Y regs u8 blink = (m_div & 0x4000) ? m_y : 0; u8 bs = ((m_l & ~blink) >> h & 1) | ((m_x*2) >> h & 2); m_write_segs(h | SM510_PORT_SEGBS, (m_bc || !(m_bp & 1)) ? 0 : bs); }}Relevant source 4.The helper get_lcd_row() assembles a 16-bit word from one column of LCD RAM.It returns zero immediately if the LCD backplate (m_bp) or bleeder (m_bc) is in the off state:inline u16 sm510_base_device::get_lcd_row(int column, u8* ram){ if (ram == nullptr || m_bc || !(m_bp & 1)) return 0; u16 rowdata = 0; for (int i = 0; i < 0x10; i++) rowdata |= (ram[i] >> column & 1) << i; return rowdata;}Relevant source 4.The BS (blinking segment) column deserves special mention.The m_div bit 14 (the F1 divider flag) controls blink timing.When this bit is set, the Y register masks specific L bits, making those segments blink at a low frequency without any CPU intervention.The Display System🖼️The LCD driver inside the CPU device fires the write_segs() callback, but that callback lands in hh_sm510_state inside hh_sm510.cpp.This is where the CPU output is converted into named screen outputs that the SVG renderer can read. hh_sm510.h void update_display() void sm510_lcd_segment_w(offs_t offset, u16 data) void sm500_lcd_segment_w(offs_t offset, u16 data) void set_display_size(u8 x, u8 y, u8 z) TIMER_CB display_decay_tick() u8 read_inputs(int columns, int fixed) void update_k_line() void input_r() void input_w(u8 data) void piezo_r1_w(u8 data) void piezo_input_w(u8 data) void sm5a_common(machine_config &config, u16 w, u16 h) void sm510_common(machine_config &config, u16 w, u16 h) void sm511_common(machine_config &config, u16 w, u16 h) void sm510_dualh(machine_config &config, ...) void sm510_dualv(machine_config &config, ...) int m_decay_pivot int m_decay_len u32 m_display_state[0x20] u8 m_display_decay[0x20][0x20] 41 20 118 hh_sm510_state is the base class for all ~200 Game & Watch drivers.It bridges the CPU device output to MAME’s screen and output systems.The 20 member variables cover display geometry, decay simulation state, input multiplexer state, and audio output.Relevant state definition 9. Segment DimensionsThe SM510 series and the SM500/SM5A series use different LCD geometries.set_display_size() tells the display system which dimensions to use:void hh_sm510_state::set_display_size(u8 x, u8 y, u8 z){ // x = groups(in bits) // y = number of segments per group // z = commons(in bits) m_display_x_len = x; m_display_y_len = y; m_display_z_len = z;}The segment write callbacks call this before storing the segment data:void hh_sm510_state::sm510_lcd_segment_w(offs_t offset, u16 data){ set_display_size(2, 16, 2); m_display_state[offset] = data;}void hh_sm510_state::sm500_lcd_segment_w(offs_t offset, u16 data){ set_display_size(4, 4, 1); m_display_state[offset] = data;}Relevant source 8.For the SM510 family, the segment space is organised as: x - 2 bits = 4 groups (a, b, bs, c) y - 16 segments per group (bits 0-15 in the 16-bit data word) z - 2 bits = 4 commons (H1 to H4)For SM500/SM5A, the space is smaller: x - 4 bits = up to 16 O groups y - 4 segments per group z - 1 bit = 2 commons (H1 and H2)The older SM500-family display and opcode behaviour is implemented in a separate source file from the SM510 family core 10.LCD Decay Simulation💡A naive implementation would turn LCD segments on and off as the CPU writes to LCD RAM.Real LCD panels do not behave this way.Physical LCD cells take a few milliseconds to fully activate and deactivate.MAME simulates this persistence using a per-segment decay counter.The decay system is driven by a second independent 1024 Hz timer, created in machine_start():m_display_decay_timer = timer_alloc(FUNC(hh_sm510_state::display_decay_tick), this);m_display_decay_timer->adjust(attotime::from_hz(1024), 0, attotime::from_hz(1024));Relevant source 8.Each tick calls update_display().This is the full implementation:void hh_sm510_state::update_display(){ u8 z_mask = (1 << m_display_z_len) - 1; u8 zx_len = 1 << (m_display_x_len + m_display_z_len); for (int zx = 0; zx < zx_len; zx++) { for (int y = 0; y < m_display_y_len; y++) { // delay lcd segment on/off state if (m_display_state[zx] >> y & 1) { if (m_display_decay[y][zx] < (m_decay_pivot + m_decay_len)) m_display_decay[y][zx]++; } else if (m_display_decay[y][zx] > 0) m_display_decay[y][zx]--; u8 active_state = (m_display_decay[y][zx] < m_decay_pivot) ? 0 : 1; // SM510 series: output to x.y.z, where: // x = group a/b/bs/c (0/1/2/3) // y = segment 1-16 (0-15) // z = common H1-H4 (0-3) // SM500/SM530 series: output to x.y.z, where: // x = O group (0-*) // y = O segment 1-4 (0-3) // z = common H1/H2 (0/1) m_out_x[zx >> m_display_z_len][y][zx & z_mask] = active_state; } }}Relevant source 8.The decay logic works as follows.Each segment has a counter in m_display_decay[y][zx].When the segment data is 1 (on), the counter increments each tick up to a ceiling of m_decay_pivot + m_decay_len.When the data is 0 (off), it decrements toward zero.The output is set active only when the counter is at or above m_decay_pivot.This produces two distinct visual effects.On DelayA segment that was off and turns on does not appear until the counter reaches m_decay_pivot.With the default of 8 ticks at 1024 Hz, that is about 8 ms of activation lag.This prevents very brief CPU writes from producing a visible flash.PersistenceA segment that turns off continues to appear until the counter drains below m_decay_pivot.With the default m_decay_len of 17 ticks, that gives about 17 ms of afterglow.This is what makes G&W segments look solid rather than flickering as the CPU scans through them.Per-Game TuningThe defaults work well for most games.Some games need different values.Turtle Bridge (TL-28), for example, has segments that incorrectly activate at default settings.Its constructor increases both parameters:gnw_tbridge_state(const machine_config &mconfig, device_type type, const char *tag) : hh_sm510_state(mconfig, type, tag){ // increase lcd decay: unwanted segments light up m_decay_pivot = 25; m_decay_len = 25;}Relevant source 8.The higher m_decay_pivot means a segment must receive a full 25 ticks of data before appearing.Short spurious pulses from the real hardware (which on Turtle Bridge accidentally activate neighbouring segments) are filtered out because they never accumulate enough ticks to cross the threshold.Segment-to-Screen MappingThe final line of update_display() writes to m_out_x:m_out_x[zx >> m_display_z_len][y][zx & z_mask] = active_state;m_out_x is declared as output_finder<16, 16, 4> with the format string \"%u.%u.%u\".MAME expands this into named output values like \"0.0.0\", \"0.1.0\", \"1.3.2\", and so on.The SVG file must use those exact strings as element IDs.When m_out_x[0][3][1] is 1, MAME looks for an SVG element with ID \"0.3.1\" and makes it visible.This is the complete rendering pipeline: CPU writes nibbles to LCD RAM, the LCD driver assembles them into 16-bit words per column, the segment callback stores them into m_display_state, the decay timer updates the visibility state, and the named output system maps that state into SVG element visibility.SVG Rendering Pipeline🖼️MAME’s SVG screen type renders vector artwork that changes dynamically based on named output values.Each SVG element whose id matches an output name is shown when that output is 1 and hidden when it is 0.The SVG describes the exact shape, position, and colour of every LCD segment on the physical panel.The mcfg_svg_screen() helper configures one screen device per display:void hh_sm510_state::mcfg_svg_screen(machine_config &config, u16 width, u16 height, const char *tag){ if (width == 0 || height == 0) return; screen_device &screen(SCREEN(config, tag, SCREEN_TYPE_SVG)); screen.set_refresh_hz(60); screen.set_size(width, height); screen.set_visarea_full(); config.set_default_layout(layout_hh_sm510_single);}Relevant source 8.The width and height values come from the individual game driver.Ball, for example, passes 1671 and 1080.These are the pixel dimensions used for the SVG viewport.The layout file (hh_sm510_single.lh, or hh_sm510_dualv.lh etc.) is a compressed MAME artwork file included at compile time.It positions the screen within the MAME window.The four layout variants are included at the top of the driver file:#include \"hh_sm510_single.lh\"#include \"hh_sm510_dualv.lh\"#include \"hh_sm510_dualh.lh\"#include \"hh_sm510_tripleh.lh\"Relevant source 8.Multi-Screen GamesDual-screen and triple-screen G&W games simply add more screen devices.Each screen gets its own SVG ROM region and its own named output namespace.For a dual vertical layout (top/bottom, like Donkey Kong), sm510_dualv() creates two screens:void hh_sm510_state::sm510_dualv(machine_config &config, u16 topwidth, u16 topheight, u16 botwidth, u16 botheight){ mcfg_cpu_sm510(config); mcfg_sound_r1(config); mcfg_svg_screen(config, topwidth, topheight, \"screen_top\"); mcfg_svg_screen(config, botwidth, botheight, \"screen_bottom\"); config.set_default_layout(layout_hh_sm510_dualv);}The Donkey Kong driver calls it with the screen dimensions halved from the SVG file natural size:void gnw_dkong_state::gnw_dkong(machine_config &config){ sm510_dualv(config, 1920/2, 1266/2, 1920/2, 1266/2);}Relevant source 8.For a dual horizontal layout (left/right, like Mario Bros), sm510_dualh() creates \"screen_left\" and \"screen_right\".For triple horizontal (like Zelda), sm511_tripleh() creates left, middle, and right screens.In each case, the CPU’s LCD output is split between the screens based on which output names appear in which SVG file.Input Handling🔧The SM5xx input system uses multiplexing.The CPU writes a strobe pattern to the S output port using the W shift register.The driver reads the K, BA, and B input pins in response to that strobe.This allows more buttons than the CPU has input pins.The Input Functionsread_inputs() scans the active input rows based on the current multiplexer mask m_inp_mux:u8 hh_sm510_state::read_inputs(int columns, int fixed){ u8 ret = 0; // read selected input rows for (int i = 0; i < columns; i++) if (BIT(m_inp_mux, i)) ret |= m_inputs[i]->read(); if (fixed >= 0) ret |= m_inputs[fixed]->read(); return ret;}input_r() is the callback the CPU calls when reading the K port.It delegates to read_inputs() with the configured column count and fixed line:u8 hh_sm510_state::input_r(){ return read_inputs(m_inp_lines, m_inp_fixed);}Relevant source 8.update_k_line() feeds the current input state directly to the MCU interrupt line.This allows the CPU to wake from halt mode when a button is pressed:void hh_sm510_state::update_k_line(){ // this is necessary because the MCU can wake up on K input activity m_maincpu->set_input_line(0, input_r() ? ASSERT_LINE : CLEAR_LINE);}Relevant source 8.Input Port DefinitionsSimple games like Ball use only the BA and B input pins directly.The CPU reads them as single bits without any strobe:static INPUT_PORTS_START( gnw_ball ) PORT_START(\"IN.0\") PORT_BIT( 0x01, IP_ACTIVE_HIGH, IPT_SELECT ) PORT_CHANGED_CB(input_changed) PORT_NAME(\"Time\") PORT_BIT( 0x02, IP_ACTIVE_HIGH, IPT_START2 ) PORT_CHANGED_CB(input_changed) PORT_NAME(\"Game B\") PORT_BIT( 0x04, IP_ACTIVE_HIGH, IPT_START1 ) PORT_CHANGED_CB(input_changed) PORT_NAME(\"Game A\") PORT_CONFNAME( 0x08, 0x00, \"Invincibility (Cheat)\" ) PORT_CONFSETTING( 0x00, DEF_STR( Off ) ) PORT_CONFSETTING( 0x08, DEF_STR( On ) ) PORT_START(\"BA\") PORT_BIT( 0x01, IP_ACTIVE_LOW, IPT_JOYSTICK_RIGHT ) PORT_CHANGED_CB(input_changed) PORT_16WAY PORT_START(\"B\") PORT_BIT( 0x01, IP_ACTIVE_LOW, IPT_JOYSTICK_LEFT ) PORT_CHANGED_CB(input_changed) PORT_16WAY PORT_START(\"ACL\") PORT_BIT( 0x01, IP_ACTIVE_HIGH, IPT_SERVICE1 ) PORT_CHANGED_CB(acl_button) PORT_NAME(\"ACL\")INPUT_PORTS_ENDDonkey Kong uses three multiplexed strobe rows (S1, S2, S3), accessed by the CPU as \"IN.0\", \"IN.1\", \"IN.2\":static INPUT_PORTS_START( gnw_dkong ) PORT_START(\"IN.0\") // S1 PORT_BIT( 0x07, IP_ACTIVE_HIGH, IPT_UNUSED ) PORT_BIT( 0x08, IP_ACTIVE_HIGH, IPT_BUTTON1 ) PORT_CHANGED_CB(input_changed) // Jump PORT_START(\"IN.1\") // S2 PORT_BIT( 0x01, IP_ACTIVE_HIGH, IPT_JOYSTICK_RIGHT ) PORT_CHANGED_CB(input_changed) PORT_BIT( 0x02, IP_ACTIVE_HIGH, IPT_JOYSTICK_UP ) PORT_CHANGED_CB(input_changed) PORT_BIT( 0x04, IP_ACTIVE_HIGH, IPT_JOYSTICK_LEFT ) PORT_CHANGED_CB(input_changed) PORT_BIT( 0x08, IP_ACTIVE_HIGH, IPT_JOYSTICK_DOWN ) PORT_CHANGED_CB(input_changed) PORT_START(\"IN.2\") // S3 PORT_BIT( 0x01, IP_ACTIVE_HIGH, IPT_SELECT ) PORT_CHANGED_CB(input_changed) PORT_NAME(\"Time\") PORT_BIT( 0x02, IP_ACTIVE_HIGH, IPT_START2 ) PORT_CHANGED_CB(input_changed) PORT_NAME(\"Game B\") PORT_BIT( 0x04, IP_ACTIVE_HIGH, IPT_START1 ) PORT_CHANGED_CB(input_changed) PORT_NAME(\"Game A\") PORT_BIT( 0x08, IP_ACTIVE_HIGH, IPT_SERVICE2 ) PORT_CHANGED_CB(input_changed) PORT_NAME(\"Alarm\") PORT_START(\"ACL\") PORT_BIT( 0x01, IP_ACTIVE_HIGH, IPT_SERVICE1 ) PORT_CHANGED_CB(acl_button) PORT_NAME(\"ACL\")INPUT_PORTS_ENDRelevant source 8.The game code writes different values to the S port to select which row it wants to read, then reads K to get the button state for that row.This is the same technique used in keyboard matrix scanning.Sound🎧Game & Watch sound is simple by modern standards.A piezoelectric buzzer produces tones from a 1-bit or 2-bit digital output.The SM511 and SM512 added a dedicated melody controller with a 256-byte tone ROM.1-bit Piezo (SM510 and SM5A)The simplest configuration routes the R port directly to a speaker_sound_device.mcfg_sound_r1() sets this up:void hh_sm510_state::mcfg_sound_r1(machine_config &config){ SPEAKER(config, \"mono\").front_center(); SPEAKER_SOUND(config, m_speaker); m_speaker->add_route(ALL_OUTPUTS, \"mono\", 0.25); m_maincpu->write_r().set(FUNC(hh_sm510_state::piezo_r1_w));}The callback simply writes the low bit of the R output to the speaker level:void hh_sm510_state::piezo_r1_w(u8 data){ // R1 to piezo (SM511 R pin is melody output) m_speaker->level_w(data & 1);}Relevant source 8.The SM510 clock_melody() method controls tone frequency via a divider mask.When m_r_mask_option is RMASK_DIRECT, the raw R register bits drive the speaker.When set to a divider bit index, the divider free-runs and the CPU only gates the output on or off.This is how the SM510 produces alarm tones without needing to toggle a bit at audio frequency.The SM5A complicates this slightly.On the SM5A, the R port serves double duty for both sound and input multiplexing.The sm5a_common() config overrides the default R callback with piezo_input_w, which handles both functions from a single write:void hh_sm510_state::piezo_input_w(u8 data){ // R1 to piezo, other to input mux piezo_r1_w(data & 1); input_w(data >> 1);}Relevant source 8.Bit 0 goes to the speaker, higher bits go to the input multiplexer.Melody ROM (SM511 and SM512)🎼The SM511 adds a dedicated 256-byte melody ROM and a hardware melody controller.The CPU program does not need to toggle the R pin at audio frequency.Instead, it writes a melody address via the PRE opcode and enables playback via SME.The hardware automatically advances through the melody data and generates tones.Tone Command FormatThe tone cycle table is a 64-entry LUT embedded in the emulator.It maps each combination of tone command (0-15) and duty cycle index (0-3) to a tick count:static const u8 lut_tone_cycles[4*16] ={ 0, 0, 7, 8, 8, 9, 9, 10, 11, 11, 12, 13, 14, 14, 0, 0, 0, 0, 8, 8, 9, 9, 10, 11, 11, 12, 13, 13, 14, 15, 0, 0, 0, 0, 8, 8, 9, 9, 10, 10, 11, 12, 12, 13, 14, 15, 0, 0, 0, 0, 8, 9, 9, 10, 10, 11, 11, 12, 13, 14, 14, 15, 0, 0,};Commands 0 and 1 are rest and stop respectively.Commands 2-13 produce tones.Commands 14-15 are illegal.The OCT bit (bit 4 of the command byte) shifts the cycle count left by 1, halving the frequency - this is the octave selector.Playback and Note AdvancementThe complete clock_melody() function runs on every divider tick:void sm511_device::clock_melody(){ if (!m_melody_rom) return; u8 cmd = m_melody_rom[m_melody_address] & 0x3f; u8 out = 0; // clock duty cycle if tone is active if ((cmd & 0xf) >= 2 && (cmd & 0xf) <= 13) { out = m_melody_duty_index & m_melody_rd & 1; m_melody_duty_count++; int index = m_melody_duty_index << 4 | (cmd & 0xf); int shift = ~cmd >> 4 & 1; // OCT if (m_melody_duty_count >= (lut_tone_cycles[index] << shift)) { m_melody_duty_count = 0; m_melody_duty_index = (m_melody_duty_index + 1) & 3; } } else if ((cmd & 0xf) == 1) { // set melody stop flag m_melody_rd |= 2; } // clock time base on divider F7/F8 if ((m_div & melody_step_mask()) == 0) { u8 mask = (cmd & 0x20) ? 0x1f : 0x0f; m_melody_step_count = (m_melody_step_count + 1) & mask; if (m_melody_step_count == 0) m_melody_address++; } // output to R pin if (out != m_r_out) { m_write_r(out); m_r_out = out; }}Relevant source 6.The duty cycle index cycles through 0-3.The output bit is m_melody_duty_index & m_melody_rd & 1.This means only when both the duty index is odd and melody is enabled does the output go high.The result is a square-wave-like pattern whose frequency is set by how quickly the duty counter fills to the LUT threshold.The melody address advances whenever the lower divider bits (melody_step_mask()) wrap around to zero.The duration field at bits 5-4 of the ROM byte doubles or quadruples the note length by widening the step counter mask.The SM511 also resets its clock divider to 4 rather than 2, halving the effective CPU instruction rate from 16384 Hz to 8192 Hz.This is set in device_reset():void sm511_device::device_reset(){ sm510_base_device::device_reset(); m_melody_rd &= ~1; m_clk_div = 4; // 8kHz notify_clock_changed();}Relevant source 6.A melody ROM region in the driver provides the tune data.The region tag \"maincpu:melody\" is how the CPU device locates it at runtime.The verifier in init_melody() checks every byte and logs a warning if any byte has illegal bits set.References 1986 Sharp Semiconductor Data Book (referenced in sm510base.cpp source header) ↩ 1990 Sharp Microcomputers Data Book (referenced in sm510base.cpp source header) ↩ src/devices/cpu/sm510/sm510base.h - SM5xx base class and opcode declarations ↩ src/devices/cpu/sm510/sm510base.cpp - SM5xx shared CPU implementation ↩ ↩2 ↩3 ↩4 ↩5 src/devices/cpu/sm510/sm510.cpp - SM510 device, ROM maps, buzzer controller ↩ src/devices/cpu/sm510/sm511.cpp - SM511/SM512 device, melody controller ↩ ↩2 ↩3 ↩4 src/devices/cpu/sm510/sm510op.cpp - SM510 opcode handler implementations ↩ ↩2 ↩3 ↩4 src/mame/handheld/hh_sm510.cpp - Main Game & Watch driver, ~200 games ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 src/mame/handheld/hh_sm510.h - Driver state class definition ↩ src/devices/cpu/sm510/sm500op.cpp - SM500 opcode handlers (shift-register display ops) ↩ ", "excerpt": "How MAME Emulates Game & Watch Game & Watch emulation in MAME is hardware emulation, not game reimplementation. The actual machine code dumped from original Nintendo microcontroller chips runs unmodified. MAME replicates the Sharp SM5xx CPU, the LCD segment controller, multiplexed inputs, and piezo buzzer - the game logic follows...", "tags": ["sourcecode","emulation","handhelds"], "image": "/public/images/RetroReversingLogoSmall.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game Architecture - How games are structured", "url": "/game-architecture", "content": "IntroductionGame architecture refers to the overall design and structure of a video game. It encompasses the organization and management of various components that make up a game, including the game engine, graphics, audio, input handling, physics, artificial intelligence (AI), networking, and more.Why should a Reverse Engineer about Game Architecture?Knowing the most common game architecture patterns is useful for both reversing and building games, these patterns have been built up over many years and incorporated lessons learned from many failed projects. It is likely that any game you want to reverse will use some variation of these standard game architecture patterns.When should a Reverse Engineer about Game Architecture?If you are reversing a 8-bit or 16-bit game it is unlikely that these patterns will have been used as there was very little knowledge sharing in the early industry and projects were relatively short involving only a handful of developers.However from 32-bit and beyond these patterns become very valuable as many games used variations of these and knowing that its a common pattern can save you some time understanding how the game works.Architecture in off-the-Shelf Game EnginesMany game engines are built with a very specific architecture in mind (ECS for Unity, OOP for Unreal Engine), so knowing why these architectures were chosen and their many benefits and drawback is very useful when choosing a game engine.Basic Game ArchitectureWhen we talk about basic game architecture we are talking about the bare minimum set of components that make up a game, it is natural for all games to have the following parts: Game Engine: The core software that provides the basic framework for a game. It typically includes components for rendering graphics, managing audio, handling input, and more. Game engines simplify the development process by providing pre-built functionality. Graphics Engine: Manages the rendering of images and graphics in the game. This includes handling 3D models, textures, lighting, and special effects. Audio Engine: Manages the generation and playback of sound effects and music in the game. It includes features such as spatial audio to create a more immersive experience. Input Handling: Manages user input from devices such as keyboards, mice, controllers, or touchscreens. This component translates user actions into in-game events. Physics Engine: Simulates realistic physical interactions within the game world, such as gravity, collisions, and object movement. Artificial Intelligence (AI): Implements the behavior of non-player characters (NPCs) and other entities in the game. AI is responsible for making decisions and reacting to the player’s actions. Networking: Manages communication between different game clients in a multiplayer environment. This includes features like player synchronization, data transfer, and server-client interactions. Game Logic: Implements the rules and mechanics of the game. It includes the overall game flow, scoring, win/lose conditions, and other gameplay-related features. User Interface (UI): Handles the display of information to the player, including menus, HUD (heads-up display), and other graphical elements.These are just the standard building blocks of a game and it is likely any game that you want to reverse engineer has separated their game code into distinct blocks of each of these. Whether the blocks are entire modules (e.g dlls) or simply just different code files (e.g .cpp), it is likely that when the code has been compiled into the final executable the functions for each category are close to each other. Of course sometimes compilers move code around for optimization purposes, but in general if you find a function that does audio handling, it is likely that the function before and after it will also be related to audio handling.Higher Level Game Architecture PatternsExtending from the basic game architecture mentioned in the previous section there are also higher level architecture patterns that a game may be built using.Some Examples are: Monolithic Architecture: Definition: In a monolithic architecture, the entire game is built as a single, self-contained application. All game-related functionalities, such as rendering, physics, and AI, are bundled together in a single codebase. Example: Many early video games, especially those developed for consoles and arcade machines, followed a monolithic architecture. The entire game logic, graphics rendering, and input handling were typically tightly integrated. Entity-Component-System (ECS) Architecture: Definition: ECS is a design pattern where the game entities are represented as collections of components, and systems process these entities based on their components. This architecture promotes composition over inheritance and is often used in game development for flexibility and performance. Example: Unity’s game engine utilizes an ECS architecture. Entities are defined by their components (e.g., position, rendering, behavior), and systems operate on entities with specific components to update the game state. Component-Based Architecture: Definition: This architecture organizes the game code around reusable and modular components. Game objects are composed of different components that define their behavior, and these components can be mixed and matched to create diverse entities. Example: The Unreal Engine uses a component-based architecture. Game objects are entities composed of components (e.g., mesh, physics, script) that can be added or removed to customize the behavior and appearance of the object. These examples illustrate the diversity of game architectures, and often, game developers use a combination of these approaches to meet the specific requirements of their projects. The choice of architecture depends on factors such as the type of game, development team size, performance considerations, and scalability needs.Online Multiplayer Game Architecture PatternsWhen reverse engineering or building an online multiplayer game it is likely that you will need to understand some common patterns used when developing online services.Note that it is much harder to understand what the server-side architecture is of a online game as you don’t have the actual code running locally on your PC, so you may never find out if the online services are a Microservice or a Monolith. However it is important to know good architecture practises if you want to develop an open source replacement to a vendors game server.Here are a few examples: Client-Server Architecture: Definition: In a client-server architecture, the game is split between a client (user interface, input handling) and a server (game logic, data storage, networking). This is common in multiplayer games, where the server manages the authoritative game state. Example: Many online multiplayer games, like MMORPGs or first-person shooters, use a client-server architecture. The client handles rendering and user input, while the server manages the game world, enforces rules, and synchronizes information between clients. Microservices Architecture: Definition: Microservices architecture involves breaking down the game into small, independent services that communicate with each other. Each service handles a specific aspect of the game, and they can be developed and deployed independently. Example: In a multiplayer game, you might have separate microservices for player authentication, matchmaking, leaderboards, and game sessions. Each of these services can be updated or scaled independently. ", "excerpt": "Introduction Game architecture refers to the overall design and structure of a video game. It encompasses the organization and management of various components that make up a game, including the game engine, graphics, audio, input handling, physics, artificial intelligence (AI), networking, and more. Why should a Reverse Engineer about Game...", "tags": ["introduction"], "image": "/public/generated/placeholders/game-architecture.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo Game Boy Reverse Engineering", "url": "/gameboy", "content": "IntroductionThe original Game Boy (DMG) and Game Boy Color (GBC) are good reverse-engineering targets because the software stack is still small enough to reason about directly, while the hardware is rich in cartridge mappers, boot-time behaviour, audio quirks, and late-1990s toolchains. They sit at a useful midpoint between 8-bit home consoles and later handhelds, so platform details are still visible instead of disappearing behind large SDKs and operating systems.This page serves two roles. It groups the RetroReversing posts related to the Game Boy family, and it curates a set of external references that are worth keeping close while you work through ROMs, schematics, tools, or source code.Quick Technical ReferenceThe quick reference below is useful when choosing an emulator, debugger, or disassembly target: Property Notes CPU Sharp LR35902, an 8-bit CPU with i8080 and Z80 ancestry Display 160x144 LCD with tile- and sprite-based graphics RAM DMG has 8 KB work RAM and 8 KB VRAM; GBC expands the memory available to software Audio Four hardware sound channels Cartridges Commonly include ROM plus mapper hardware such as MBC controllers, battery-backed RAM, or RTC logic HardwareUnderstanding the platform before opening a ROM saves time. The Game Boy family is simple enough to study at board-level, but it still has enough cartridge and accessory variation that hardware context matters.Hardware ArchitectureIf you want a broad architectural overview before going deeper, Copetti’s write-up is one of the best starting points: Game Boy Architecture - A Practical Analysis Rodrigo Copetti provides a practical architectural overview of the Game Boy, covering the CPU, memory layout, graphics pipeline, audio system, and cartridge hardware. Boot ROMThe boot ROM is one of the first platform-specific code paths worth understanding. It establishes initial hardware state, checks cartridge header data, and controls the startup sequence: A Look At The Game Boy Bootstrap A practical breakdown of the original Game Boy bootstrap process, useful when studying cartridge headers, reset state, and emulator accuracy. Sharp LR35902 MicroprocessorThe Sharp LR35902 is close enough to Z80-family code to feel familiar, but different enough that you should treat it as its own target architecture. In practice it sits somewhere between the i8080 and the Z80 and is not binary-compatible with either: The Z80 Microprocessor - Pioneering Gaming and Beyond Background on the Z80 family and why the Game Boy CPU looks familiar while still requiring Game Boy specific handling. SchematicsIf you want to work from recreated board-level documentation, Gekkio’s schematic set is a strong reference for the Pocket hardware revision: Game Boy Pocket Hardware Schematics Recreated schematics for the Game Boy Pocket CPU board, useful for tracing signals and understanding hardware level behaviour. The Ultimate Game Boy TalkThe video below is still one of the best broad introductions to the hardware and the programming model, especially if you want one long-form overview before drilling into specific subsystems:The Game Boy, a hardware autopsyThese two videos are worth keeping together because they focus on the physical hardware itself rather than the higher-level architectural write-ups above:DevelopmentUnderstanding the official toolchain helps when you encounter build artifacts, linker conventions, or assembly layout in old projects.Development Kit HardwareNintendo sold dedicated development hardware for Game Boy projects, and the physical setup explains a lot about how teams built, tested, and flashed handheld software in the early 1990s: Gameboy (DMG & GBC) Development Kit Hardware An overview of the official Game Boy development hardware and how it fit into commercial production workflows. Software Development KitAlongside the hardware, Nintendo also shipped a software development kit with assemblers, linkers, and related utilities: Game Boy Software Development Kits Notes on the official Game Boy SDK, including the tools and file types that appear in retail era development setups. Assembly LanguageThe Game Boy CPU uses its own instruction set variant, so it helps to keep a Game Boy specific opcode reference nearby instead of assuming normal Z80 compatibility: Game Boy Assembly Programming A beginner friendly but detailed introduction to Game Boy assembly programming, with examples of the instruction set and platform specific quirks. Reverse EngineeringIf you want to begin with projects that already expose structure, build systems, or platform specific research, start with the material below.Pokemon Red and BlueThe Pokemon Reverse Engineering Team (PRET) reconstructed Pokemon Red and Blue into retail matching assembly, making it one of the most useful Game Boy case studies for understanding large commercial codebases: Reversing Pokemon Red and Blue (Game Boy) Coverage of the PRET disassembly project and why it matters for rebuildable Game Boy reverse engineering. Link’s AwakeningThe Link’s Awakening disassembly effort produced a steady stream of technical write-ups that are still useful when you want to see how a polished commercial Game Boy title is structured internally: Disassembling Link's Awakening A long-running series on disassembling Link's Awakening, with practical explanations of systems, data formats, and game logic. Looney Tunes Carrot CrazyIf you want a more focused example of reversing a single Game Boy Color title, this write-up is a good smaller target: Reverse Engineering Carrot Crazy A practical reverse engineering walk-through for Looney Tunes Carrot Crazy on the Game Boy Color. Exclusive Games as Research TargetsPlatform exclusives are often better long-term preservation targets because they are less likely to have cleaner ports or modern rereleases. These two category pages are simple discovery lists rather than technical references, but they are useful when you need candidate ROMs to investigate: Original Game Boy Exclusive Games A discovery list of original DMG exclusives that can help you find titles which still depend on original Game Boy hardware. Game Boy Color Exclusive Games A discovery list of Game Boy Color exclusives, useful when you want GBC specific software targets rather than DMG compatible games. Source CodeOfficial or near-official source releases are especially valuable on Game Boy because they expose real memory layouts, tool conventions, and cartridge assumptions that decompilation alone can hide.Mr Do! for Original Game BoyThe released source code for Mr Do! is a useful reference point for how a commercial Game Boy project was organised in 1990: Mr Do! Source Code (Game Boy) Coverage of the Mr Do! source release and the structure of a retail era Game Boy codebase. GamesSome game-specific anecdotes are worth keeping because they point to development constraints, unusual implementation tricks, or particularly good analysis material.Alien 3Alien 3 is a useful reminder of how compressed licensed handheld schedules could be. Jas Austin has said the Game Boy version was written in about five weeks 1.Fastest commercial game I've ever written? That would have been Alien3 on Game Boy. Done in about 5 weeks :) with @recluse_games #gamedev— Jas Austin (@IamXERO) February 1, 2013R-TypeAccording to Jas Austin, the Game Boy version of R-Type was largely built from memory after arcade research trips rather than from shared code or art assets 2.He also described being hired after showing a one-week demo to B.I.T.S, which is a useful glimpse into how quickly Game Boy contract work could move in that era 2.I agree, it's amazing some of the lengths we have to go to when we didn't have code or assets. For R-Type I did most of it from memory after visits to the Trocadero in London. And I didn't live in London.— Jas Austin (@IamXERO) April 18, 2020The company B.I.T.S obtained the license to develop the Game Boy version of the game but required a programmer to work on the title. Jas Austin heard about this through his agency and travelled to London to meet up, he impressed them so much that he was given a development kit and a deadline of a week to come up with a demo. He did such a good job he got a permanent job at B.I.T.S 2.I hid a version of John Conway's game of Life in R-Type on the Game Boy.— Jas Austin (@IamXERO) April 5, 2021Austin later mentioned hiding an implementation of John Conway’s Game of Life inside the cartridge 3, and also shared source graphics for the level 3 ship by Mark Jones 4.Source graphics for Game Boy R-Type Lv3 ship. By Mark Jones... #ScreenshotSaturday24YearsAgo pic.twitter.com/RsKlc0rQOE— Jas Austin (@IamXERO) April 25, 2015How Pokemon Gold & Silver Work (Tribute to Satoru Iwata)TheHappieCat explains the technical wizardry Satoru Iwata employed to fit the Kanto region into Pokémon Gold & Silver. The video provides a primer on low-level assembly programming and memory alignment, illustrating how efficient data packing and optimization allowed for the game’s massive scope on the limited Game Boy Color hardware.Peripherals and AccessoriesThe wider Game Boy ecosystem matters for reverse engineering because several accessories introduce their own protocols, bootstrap behaviour, or unusual cartridge side hardware.Mobile Adapter GBNintendo released a Japanese accessory called the Mobile Adapter GB which connected a Game Boy Color to a mobile phone. Only a small set of games used it, making it a good example of an obscure platform feature that remained dormant for years: Tetsuji - Remote Code Execution on a Game Boy Colour 22 Years Later TheXcellerator explains how the Mobile Adapter GB works and how it was turned into a route for running custom code years after release. Super Game BoyThe video below explains how the Super Game Boy embeds Game Boy hardware inside a Super Nintendo cartridge, creating a hybrid environment with its own timing and presentation quirks: Super Game Boy Overview A video overview of the Super Game Boy hardware and how Nintendo adapted the handheld for television output. Wide Boy 64The video below covers the Wide Boy 64, an official but non-retail device used by developers and press to run Game Boy and Game Boy Advance software through an N64 based setup: Wide Boy 64 Overview An overview of the Wide Boy 64 and why it matters as a rare Nintendo evaluation and capture device. Game Boy PrinterThe Game Boy Printer is relevant because it exposes another side of the accessory protocol stack, and because several games shipped explicit printing features rather than treating it as a camera-only novelty. Pokemon Yellow, Pokemon Gold, and Pokemon Silver all used it for game-specific output such as Pokedex stickers 5.GB BoosterThe GB Booster was an unlicensed Nintendo 64 accessory in the same broad space as the Super Game Boy, but built outside Nintendo’s official hardware ecosystem. Two short references are useful if you want to document it further: Chris McCovell - Notes and photos covering the hardware and behaviour of the device. GameHacking.org Wiki - A general reference page for the accessory.Datel Game Booster and GameStudioThe video below shows Datel’s PlayStation Game Booster:The Image below shows the later GameStudio accessory for PlayStation 2 also by Datel:Dance Dance Revolution Controller for GBCKonami’s Dance Dance Revolution controller for the Game Boy Color is a useful example of how far the accessory ecosystem stretched beyond normal link cable peripherals:SoundThe audio hardware is one of the most technically interesting parts of the platform, especially once you move beyond music drivers and start looking at the analogue side.Game Boy Color Audio Chip ReversingKen Shirriff’s reverse engineering of the Game Boy Color audio amplifier chip is one of the best examples of taking the handheld beyond emulator level understanding and into silicon level analysis. The chip contains three power op-amps for the speaker and headphone paths, so the article is useful if you want analogue details rather than just register level behaviour:I reverse-engineered the audio chip in the #Nintendo Game Boy Color. It contains three power op-amps for the speaker and headphone channels. This 1998 chip is built from about 100 NPN and PNP transistors. Die photo from @johndmcmaster. Article & schematic:https://t.co/EhsVogAJPl pic.twitter.com/J6CYPsOdaz— Ken Shirriff (@kenshirriff) May 2, 2020 Reverse Engineering the Audio Amplifier Chip in the Nintendo Game Boy Color A transistor level analysis of the Game Boy Color audio amplifier chip, including die photos, schematic reconstruction, and analogue behaviour. SynthicSynthic played a large set of Game Boy games in a custom headless emulator and tracked the audio registers into a text format. That data was then used to train a machine learning model to generate new Game Boy music: Synthic A project that records Game Boy audio register activity from emulated play sessions and uses that data to generate new music. Tools and File FormatsIf you are tracing ROM headers, cartridge metadata, or patch formats, the material below is worth keeping close.File FormatsStart here if you want a broader survey of Game Boy file structures before drilling into specific ROM hacks or tools: Game Boy File Formats (DMG, GBC) An overview of Game Boy file formats, cartridge related structures, and common file handling topics. gbtoolsidWhen dealing with homebrew or unlabeled ROM sets, gbtoolsid is a practical first pass because it can often identify the toolchain used to build a Game Boy ROM: gbtoolsid A command line utility for identifying which tools or engines were likely used to build a Game Boy ROM. DMG-palette-patcherMrBlinky has released a Python tool for patching Original Game Boy (DMG) ROMs to use specific color palettes when played on a Game Boy Color. The script works by modifying the ROM’s header-specifically the license code and title checksum-to trick the Game Boy Color’s boot ROM into automatically selecting one of 45 built-in color palettes, such as the classic grey theme, rather than the default blue-greenish hues. DMG-palette-patcher by MrBlinky MrBlinky has released DMG-palette-patcher, a tool that modifies Game Boy ROM headers to trigger specific built-in color palettes on the Game Boy Color. gb-save-statesgb-save-states is interesting because it applies patch based save state support to commercial games running on original hardware, which makes it a good example of practical ROM level instrumentation: gb-save-states A collection of patches that add save state support to Game Boy and Game Boy Color titles on original hardware. Blem! PlayStation Emulator for the GBBlem! was a prank ROM that pretended to boot a PlayStation emulator on the Game Boy. The joke was a reference to the Bleem! PlayStation emulator, and it was notable enough to show up in GBX issue 3 in a short discussion of Game Boy emulation on PC and Mac 6. It is not technically important in the same way as the tools above, but it is a useful reminder that handheld homebrew culture also produced jokes, hoaxes, and magazine folklore around emulation.All Posts Gigaleak - Game Boy Advance Boot ROM Repository The Nintendo Gigaleak preserves the AGB boot ROM material in two useful forms. Inside other/agb_bootrom it survives as a real Subversion repository, and separately the leak also includes agb_bootrom_trunk.zip, an... ... Read More gameboy gba leak sourcecode Gigaleak - Game Boy Color Boot ROM Repository The Nintendo Gigaleak preserves the CGB boot ROM material in two useful forms. Inside other/agb_bootrom it survives as a compact SVN repository, and separately the leak also includes cgb_bootrom_trunk.zip, an... ... Read More gameboy leak sourcecode Game Boy File Formats (DMG, GBC) Find out about the most common Game Boy File formats in this post ... Read More gameboy fileformats Game Boy (DMG/GBC) Reversing Emulator Introduction The Game Boy Reversing Emulator (RE) is a fork of the libRetro Same Boy emulator tailored for reverse engineering. The main aim is to generate information that will be... ... Read More gameboy reversingEmulator Game Boy Software Development Kits Official Game Boy Software Development Kit (by Intelligent Systems) The official Game Boy development kit was developed by Intelligent systems and sold with their development kit hardware such as the... ... Read More gameboy sdk Gameboy (DMG & GBC) Development Kit Hardware This post covers all the hardware developers used to create games for the original Dot Matrix Game Boy (DMG) and Game Boy Color (GBC) and some were even used for... ... Read More gameboy nintendo devkit hardware Handheld Consoles Reverse Engineering Awesome list of Obscure Handheld Game Development and Reverse Engineering information ... Read More gba gameboy gamecom gamegear handhelds Mr Do! Source Code (Game Boy) Introduction This page documents the official release of the assembly source for Ocean Software’s Mr Do! port to the Game Boy. It focuses on what the code is doing (maps,... ... Read More gameboy games sourcecode NES Sprite Tile Editing Sprite Tile editing with Tile Layer Pro If you have ever wondered how graphical rom hacks are made this is for you! This should work for most early games such... ... Read More nes gameboy introduction Pokemon Original Source Code Leak On the 11th April 2020 the source code to the original generation of Pokemon games was released to 4chan as osrc.zip. This zip archive contained a password protected zip file... ... Read More leak gameboy Reversing Pokemon Red and Blue (Game Boy) Introduction The Pokemon Reverse Engineering Team (PRET) have managed to pull off a marvellous achievement, they have fully reverse engineered Pokemon Red and Blue back into Z80 assembly code 1.... ... Read More gameboy games assembly Super Game Boy SDK Sample and BIOS Files Super Game Boy SDK Sample and BIOS Files This page covers the sgb folder preserved in the Nintendo Gigaleak inside: other/CGB AZL__ゼルダの伝説 夢を見る島DX Source/Disk1/ゼルダの伝説_JP3_US3_EU2/DEMO_zelda/sgb Although it was found inside the... ... Read More gameboy sdk leak sourcecode How does Twitch Play Pokemon? (Emulation through Twitch) Have you ever seen Twitch Plays Pokemon (TPP) and wondered how it actually works? How does typing comments in a twitch stream result in the player moving in the original... ... Read More introduction gameboy 3ds Gigaleak - Original Zelda Links Awakening Source Code (DMG) The Zelda Links Awakening source code was released in the original Gigaleak inside dmg.7z, itself stored inside Other.7z. This part of the leak contains much more than a single source... ... Read More gameboy leak sourcecode The Legend of Zelda Link's Awakening - 2D Art Workspace (NEWS_04 Archive) Archive Source This article analyzes the Link’s Awakening 2D art and graphics workspace preserved in the Gigaleak - specifically from the NEWS_04 archive, a 96 MB Nintendo NEWS workstation backup.... ... Read More gameboy leak Zelda Links Awakening DX Source Code (CGB) The CGB.7z section of the Nintendo Gigaleak preserves Game Boy Color-era material for two projects: The Legend of Zelda: Link’s Awakening DX and Hamtaro 2. For Zelda, this archive is... ... Read More gameboy leak sourcecode The Z80 Microprocessor - Pioneering Gaming and Beyond The Z80 Microprocessor: Pioneering Gaming and Beyond The history of the Z80 microprocessor is a tale of innovation and influence that left an indelible mark on the world of computing... ... Read More hardware gameboy mastersystem cpu References Jas Austin on Alien 3 for Game Boy taking about five weeks - Twitter/X ↩ Terminator 2, R-Type, Altered Beast with Jas Austin - The Retro Hour EP320 - YouTube ↩ ↩2 ↩3 Jas Austin on hiding Conway’s Game of Life inside R-Type - Twitter/X ↩ Jas Austin sharing R-Type source graphics by Mark Jones - Twitter/X ↩ Game Boy Printer - Bulbapedia ↩ GBX issue 3 (September 2001) page 11 ↩ ", "excerpt": "Introduction The original Game Boy (DMG) and Game Boy Color (GBC) are good reverse-engineering targets because the software stack is still small enough to reason about directly, while the hardware is rich in cartridge mappers, boot-time behaviour, audio quirks, and late-1990s toolchains. They sit at a useful midpoint between 8-bit...", "tags": ["gameboy","introduction"], "image": "/public/generated/placeholders/gameboy.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo Game Boy Advance (GBA) Reverse Engineering", "url": "/gba", "content": "Nintendo Game Boy Advance Reverse EngineeringWelcome to our page dedicated to Game Boy Advance reverse engineering! The Game Boy Advance was a popular handheld gaming console that was released in 2001, and has since become a favorite of gamers around the world.If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to the right place. On this page, we’ve compiled a list of links to other pages that cover various topics related to Game Boy Advance reverse engineering.Whether you’re interested in understanding the hardware architecture of the console, analyzing game code, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to.So grab your Game Boy Advance, and get ready to dive into the exciting world of Game Boy Advance reverse engineering!Hardware ArchitectureCopetti.org has an excellent page on the hardware Architecture of the Game Boy Advance, it is also a great introduction to the system: Game Boy Advance Architecture - A Practical Analysis Check out this excellent introduction to the GBA hardware GBA AGS-CPU-11 Hardware SchematicsThe GameBoy Advance uses a 32-bit RISC CPU (ARM7TDMI) running at 16.78 MHz known as the AGS-CPU-11, for really low level detail for how this CPU works at a hardware level check out the Schematics:gb-schematics/AGS-CPU-11.pdf at master · Gekkio/gb-schematics · GitHubDevelopment Kits (Hardware) Game Boy Advance (AGB) Development Kit Hardware For more information on the GBA Development Kit hardware check out this post. Software Development Kits (SDK)Official SDK Game Boy Advance Software Development Kit (SDK) For more information on the Official GBA SDK check out this post. Music Library (M4A) M4A Music Library for Game Boy Advance (GBA) For more information on the GBA Music SDK check out this post. SDK Demos Game Boy Advance SDK Demos For more information on the GBA SDK Demo games check out this post. EmulationMuch to the annoyance of Nintendo, Game Boy Advance emulators were released before the console was even launched! Developers managed to get their hands on early development kits and managed to build and release the first known GBA emulator known as GBAEmu in September 2000 1! It was able to play the official SDK Demo’s such as Yoshi’s Island 2.Nowadays GBA emulators have such high compatibility that pretty much all commercial games work without much trouble even on low end hardware.Reverse EngineeringReverse Engineering a Gameboy Advance Game: KlonoaBruno Macabeus has an excellent write up about reverse engineering the GBA game Klonoa: Empire of Dreams. The comprehensive guide covers the GBA architecture and ARM assembly, detailing the process of locating level data to build a custom level editor. Reverse Engineering a Game Boy Advance Game: Complete Guide Bruno Macabeus details the complete process of reverse engineering Klonoa on the GBA, from understanding the hardware to creating a functional level editor. Reverse Engineering a GBA Game: Pokémon Mystery DungeonStar Cube Labs has an excellent write up about reverse engineering the Game Boy Advance title Pokémon Mystery Dungeon: Red Rescue Team. It covers the fundamentals of the ARM and Thumb instruction sets, setting up a Ghidra workflow for static analysis, and using emulator debugging features to trace game logic and memory values. Reverse Engineering a GBA Game Star Cube Labs provides a comprehensive, beginner-friendly tutorial on reverse engineering GBA games, using Pokémon Mystery Dungeon as a case study to teach assembly analysis and debugging strategies. Figuring out an E-Reader FunctionMatt Greer’s Blog has an excellent write up about reverse engineering the Nintendo e-Reader’s internal compression routines. It covers locating the DecompressVPKorNonVPK function within the ERAPI table, analyzing the ARM assembly to decipher parameter requirements, and utilizing the built-in VPK0 decompression to optimize storage for homebrew projects. Figuring out an E-Reader Function Matt Greer details the reverse engineering of the Nintendo e-Reader's **ERAPI** to access internal VPK0 decompression, allowing for greater data density on homebrew cards. All Posts Tagged with GBA Game Boy Advance (AGB) Development Kit Hardware Official Development Kit Hardware The Game Boy Advance official development kits were incredibly similar to the original Game Boy and Game Boy Color devkits. In fact they reused the same... ... Read More gba devkit hardware snsystems Game Boy Advance Software Development Kit (SDK) Introduction This page covers release 3.0 of the english software development kit, but the other versions are very similar to this. It is unclear if this was the last release... ... Read More gba sdk Game Boy Advance SDK Demos Version 3.0 of the Game Boy Advance Software Development Kit (SDK) was leaked on to the internet for everyone to enjoy. There are some very interesting findings in this SDK,... ... Read More gba sdk M4A Music Library for Game Boy Advance (GBA) Introduction What is the M4A Library? The M4A library otherwise known as Make SoundCodes for AGB (MKS4AGB) is used to play sound on the Game Boy Advance. Where can I... ... Read More gba sdk Game Boy Advance Software Development Kit Samples Blib sample (/blib_sample) This folder contains File Name Extension Description DacsTest .c, .o   Data .c, .o   EepromTest .c, .o   FlashTest .c, .o   Main .c, .h, .o... ... Read More gba sdk Game Boy Advance Tool Source Code Introduction In the Game Boy Advance SDK Version 3.0 the source code for a variety of tools are available to learn from and modify. These tools all have a command... ... Read More gba sdk Gigaleak - Game Boy Advance Boot ROM Repository The Nintendo Gigaleak preserves the AGB boot ROM material in two useful forms. Inside other/agb_bootrom it survives as a real Subversion repository, and separately the leak also includes agb_bootrom_trunk.zip, an... ... Read More gameboy gba leak sourcecode Handheld Consoles Reverse Engineering Awesome list of Obscure Handheld Game Development and Reverse Engineering information ... Read More gba gameboy gamecom gamegear handhelds Netcard - Cancelled GBA Online Peripheral The netcard folder from the Gigaleak contains the documentation, SDKs, and design specifications for an officially scoped but ultimately cancelled online gaming peripheral for the Game Boy Advance. {% capture... ... Read More gba leak pokemon All Nintendo Leaks Nintendo has has many data leaks in the past, but none as huge as the original Oman Archive of the late 90s or the Gigaleaks of 2020. This post is... ... Read More leak nintendo 3ds gba Nintendo Paladin Leak The Paladin leak occurred on the 30th of September 2020 and included about 2.4GB of content related to the Nintendo IRIS and Pokemon spinoffs. This was the third Nintendo leak... ... Read More leak ds 3ds gba References Retro Gamer Issue 01 page 62 ↩ emulator ↩ ", "excerpt": "Nintendo Game Boy Advance Reverse Engineering Welcome to our page dedicated to Game Boy Advance reverse engineering! The Game Boy Advance was a popular handheld gaming console that was released in 2001, and has since become a favorite of gamers around the world. If you’re interested in learning more about...", "tags": ["gba"], "image": "/public/generated/placeholders/gba.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Gigaleak - Game Boy Advance Boot ROM Repository", "url": "/game-boy-advance-boot-rom-repository", "content": "The Nintendo Gigaleak preserves the AGB boot ROM material in two useful forms.Inside other/agb_bootrom it survives as a real Subversion repository, and separately the leak also includes agb_bootrom_trunk.zip, an extracted working tree that makes the source much easier to inspect. Gigaleak - SNES Source Code Leak For the wider Nintendo Gigaleak overview, including the other major archives, check out this post. At a GlanceThe AGB repository preserves: a real SVN history rather than just a loose source dump a compiled monitor binary at the trunk root monitor, startup, sound, and helper source under build shared headers, memory maps, and support libraries later PC-side tools like AgbComp and Bmp2Agb internal docs covering stack layout, joyboot, multiboot, and monitor behaviour Repository Revisions on disk Earliest date Latest date Visible author agb_bootrom 7 revisions (0 to 6) 24 April 2009 9 October 2009 nakasima What the Revision History ShowsThe visible revision sequence is unusually useful here because it shows how the repository was assembled: Revision Date Author Log message 1 2009-04-24 01:45:30 UTC nakasima empty 2 2009-04-24 02:04:18 UTC nakasima empty 3 2009-10-08 07:08:52 UTC nakasima AgbComp追加。 4 2009-10-09 04:12:15 UTC nakasima AgbCompバイナリ追加。 5 2009-10-09 04:16:09 UTC nakasima Bmp2Agb追加。 6 2009-10-09 04:19:45 UTC nakasima HTMLリファレンスをAgbSDKからコピー。 That gives the repository two clear phases.Revision 2 looks like the main import of the low-level AGB working tree, while revisions 3 to 6 look more like an archival cleanup pass that added tools, binaries, and copied HTML reference material from AgbSDK.Trunk Structure trunk The AGB repository is easiest to read as one compiled monitor binary at the top, plus a build tree for source, libraries, and tools, and a doc tree for internal notes and SDK-related reference material. 💾 AgbMnTs3_000605.bin Compiled AGB monitor-side binary 📁 build Main low-level source and build tree 📁 build/AgbInclude Hardware headers, macros, memory maps, and shared definitions 📁 build/AgbLib Prebuilt syscall and print support libraries 📁 build/tools Graphics and compression support tools 📁 doc Internal notes, stack docs, and joyboot-related reference files The separate agb_bootrom_trunk.zip export makes this repository much easier to work with because it preserves the extracted working tree directly.That means the monitor, startup, and tool sources can be read as normal files instead of being reconstructed from raw Subversion storage.How the AGB Tree Fits TogetherOnce the file groups are laid out side by side, the AGB repository reads like a compact low-level development environment with four main layers: startup and runtime entry code in the crt0* files monitor logic in the AgbMon* source set reusable platform support in AgbInclude and AgbLib asset and preparation tools in build/toolsflowchart TD A[\"<b>crt0 startup files</b><br>entry point, key addresses, common ARM setup\"] --> B[\"<b>AgbMon monitor code</b><br>main monitor logic, data, helpers, filters\"] B --> C[\"<b>AgbInclude</b><br>memory map, sound, multiboot, print, macros\"] B --> D[\"<b>AgbLib</b><br>syscall and print support libraries\"] C --> E[\"<b>AgbComp and Bmp2Agb</b><br>prepare graphics and compressed asset data\"] D --> E B --> F[\"<b>AgbMnTs3_000605.bin</b><br>compiled monitor-side binary\"]That reading also lines up well with the preserved Arm.map and ArmDebug.map files in the extracted build tree.The repository is not just storing source files in isolation.It preserves the pieces you would expect around a real buildable monitor environment: startup code, monitor code, libraries, map output, and the tools needed to prepare some of the input data. build Inside build, the repository splits into a broad support layout: include files, libraries, tools, and the main monitor/startup source files all sitting together in one low-level working tree. 📁 AgbInclude Shared hardware headers, memory maps, and macros 📁 AgbLib Prebuilt syscall and print libraries 📁 tools PC-side graphics and compression tools 📄 AgbMon.c Main monitor implementation 📄 AgbMonData.c Monitor-side data tables 📄 AGBモニタ履歴.txt Internal monitor version history 📄 AGBデバッガ対応方法.txt Debugger hookup note 📄 AgbMnTs3_000605_Sum.txt Checksum file for the preserved binary 📄 Arm.map Main link map 📄 ArmDebug.map Debug-oriented link map 📄 AgbSound.c Sound support source 📄 AgbMPlay.c Music or playback support source 📄 crt0Arm.s Primary ARM startup file 📄 crt0IncludeArm.s Shared startup include layer 📄 crt0KeyAddr.s Key address definitions Core Source FilesThe extracted working tree makes the key AGB files much more concrete: File What survives with it What it appears to represent AgbMon.c AgbMon.h, AgbMonData.c, AgbMonSub16.c, AgbMonSub32.c, AgbMonUncompFilt16.c, AgbMonUncompFilt32.c The main monitor-side runtime and helper layer crt0Arm.s crt0ArmCst.s, crt0IncludeArm.s, crt0KeyAddr.s, crt0subArm.s, crt0subArmCommon.s, crt0subArmCst.s, crt0SinTable.s The ARM startup and bring-up path AgbComp.cpp AgbComp.h, AgbComp.bpr, read_me.txt, later agbcomp.htm and AgbComp.exe A PC-side AGB data compression and filtering tool Bmp2Agb.cpp Bmp2Agb.h, Bmp2Agb.bpr, Bmp2Agb.exe, later bmp2agb.htm A PC-side bitmap and palette conversion tool AgbMon and Its Helper FilesThe extracted AgbMon.c file shows that the monitor was doing much more than exposing a bare debug loop.It brings together RAM reset, pause handling, VBlank setup, joypad input, sound, music playback, logo data, and cartridge-type-dependent setup in one place.AgbMon.c Internals AgbMon.c function AgbMonMain() global demomusic global demotrack[DEMO_TRACK_N] global demomusic2 global demotrack2[DEMO_TRACK_SE_N] global demosound[2] table LogoDY[] extern sd_logo extern sd_piron extern sd_ok extern sd_cut extern sd_cancel 1 11 341 The visible globals are strongly multimedia-oriented, with demomusic, demotrack, demomusic2, demotrack2, demosound, and LogoDY all sitting near the top of the file.So the monitor preserved here looks more like a small AGB bring-up environment with a built-in demo and support layer than a bare serial shell.The actual AgbMonMain() body makes that much clearer.It is not a simple “show logo and jump” routine.The function resets RAM, enables the pause register, ramps sound bias, configures VBlank interrupts, checks for a CGB cartridge, initializes affine background state, sets up joypad/SIO handling, opens music players, then spends most of its runtime animating the GAME BOY logo with OAM, affine transforms, blending, and palette effects.The later part of the function is just as revealing: it starts sd_logo and sd_piron during the title sequence it watches for START + SELECT as a cancel path on header failure, it does not simply hang forever; it stays in a loop that keeps joypad, sound, VBlank, and SIO-related state alive after the sequence finishes, it resets RAM again with different flags depending on whether it is returning to cartridge boot or preserving external RAM and SIO state for a downloaded programThat lines up with the monitor spec much better than the old “debug shell” mental model.This is really a small boot presentation and handoff environment with serial-download support layered into it.What the Helper Files AddThe helper sources explain why AgbMon.c can be so high level.The monitor is surrounded by its own small support layer rather than relying only on opaque external libraries. Helper file What is visible in the extracted tree Why it matters AgbMonData.c OamMonData and other fixed monitor-side graphic data Hardcoded logo/object layout for the animated boot presentation AgbMonSub.h RomHeaderCheck, NintendoLogoSet, JoyMain_Init, JoyMain_Frame, RamInit, Agb2Cgb, PlttLinerSet, and many BIOS-like helpers Shows the monitor had its own private runtime layer around logo checks, input, memory, affine setup, and palette effects AgbMonSub16.c NinLogoBak, OamBak, CharTmpBuf, WaveDataBuf, LogoCounter, LogoPosition, and LogoAffineSrc Preserves the working buffers and state for the logo animation and Nintendo-logo validation path AgbMonUncompFilt16.c RLUnComp8, RLUnComp16, DiffUnFilter8_8, DiffUnFilter8_16, DiffUnFilter16_16 Reimplements decompression and differential-filter helpers locally when syscall wrappers are not used AgbMonUncompFilt32.c BitUnPack32, LZ77UnComp8, LZ77UnComp16, HuffUnComp32 Confirms the monitor-side code could unpack the same compression formats used by Nintendo’s toolchain The helper layer is concrete enough to show directly from the extracted files.It preserves fixed logo-layout data, runtime state buffers, affine helpers, and local decompression or filter routines side by side.Helper File Internals AgbMonData.c table OamMonData[10][2] 0 1 97 AgbMonSub16.c variable DacsCheck variable Cont variable Trg variable NinLogoBak[256] variable OamBak[128] variable LogoCounter[7] variable LogoPosition[7] variable LogoAffineSrc[7] function Agb2Cgb(void) function PlttLinerSet(s32 DataIndex, s32 LinerParam, s32 PlttStart) function NinLogoCopy(s32 BlockNo) function RegDataCheck(void) function GetSumData(u8 StartNo, u8 *Srcp, s32 Count) 17 18 440 AgbMonSub32.c function OamSortSet16(u16 *Srcp, u16 *Destp, OamSortSetParam *Paramp) function BgAffineSet32(BgAffineSrcData *AffineSrcp, BgAffineDestData *AffineDestp, s32 ArrayNum) function ObjAffineSet32(ObjAffineSrcData *AffineSrcp, s8 *AffineDestp, s32 ArrayNum, u32 ParamAddrOffset) 3 0 122 AgbMonUncompFilt16.c function CpuSet16_32(u8 *Srcp, u8 *Destp, u32 DmaCntData) function RLUnComp8(u8 *Srcp, u8 *Destp) function RLUnComp16(u8 *Srcp, u16 *Destp) function DiffUnFilter8_8(u8 *Srcp, u8 *Destp) function DiffUnFilter8_16(u8 *Srcp, u16 *Destp) function DiffUnFilter16_16(u16 *Srcp, u16 *Destp) 6 0 165 AgbMonUncompFilt32.c function BitUnPack32(u8 *Srcp, u32 *Destp, BitUnPackParam *BitUnPackParamp) function LZ77UnComp8(u8 *Srcp, u8 *Destp) function LZ77UnComp16(u8 *Srcp, u16 *Destp) function HuffUnComp32(u32 *Srcp, u32 *Destp) 4 0 178 One easy-to-miss point in those files is that much of the implementation sits inside #if 0 blocks.So the tree is preserving local fallback or reference implementations of logo-copy, affine, checksum, decompression, and differential-filter routines even when the active build can route the same operations through the shared syscall layer instead.The smaller helper headers fill in another useful part of the picture.AgbMonTypes.h defines PosData, AccelData, VectorData, BgScIncSetParam, and ObjAffineFuncParam, which is a good match for the monitor’s pseudo-3D logo movement and affine setup code.AgbMonMacro.h then wraps CpuSet16_32, CpuFastSet32, trigonometric table access through Sin256Tbl, and a MonRom2Ram() macro that copies the boot image from address 0x00000000 to 0x00800000 before flipping REG_ROMMAP.That is a strong hint that the monitor codebase was designed around both direct boot-ROM execution and an internal ROM-to-RAM execution path, even though the actual MonRom2Ram() call is commented out in AgbMon.c.One subtle detail in AgbMonSub.h is especially useful.The file can either map many of these helpers onto BIOS syscalls with #define wrappers, or compile local replacements instead.That means the repository preserves both the API shape and the fallback implementation strategy.The crt0 Startup PathThe extracted crt0Arm.s source makes the startup path much clearer than the raw repository strings alone.It contains vector entries, SWI dispatch, mode-specific stack setup, and the handoff into AgbMonMain.crt0Arm.s Symbols crt0Arm.s label start_v label fiq_v label start_m label irq_m label swi_m global swi_return global agb2cgb global halt global stop table sys_table stack usr_sp stack irq_sp stack svc_sp stack fiq_sp 22 6 307 crt0Arm.s Externs extern AgbMonMain extern intr_main extern RegisterRamReset32 extern CpuSet16_32 extern CpuFastSet32 extern LZ77UnComp8 extern LZ77UnComp16 extern HuffUnComp32 extern RLUnComp8 extern RLUnComp16 extern DiffUnFilter8_8 extern DiffUnFilter8_16 extern DiffUnFilter16_16 extern SoundInit extern MPlayOpen extern MPlayStart extern MultiBootMain 40 0 307 The cards below highlight the most useful startup symbols and externs to read first.Their footer counts reflect the full totals in crt0Arm.s, not only the smaller subset shown on the cards.The visible startup code includes: the vector entries start_v, undef_v, swi_v, irq_v, and fiq_v a start_m path that disables interrupts, initializes stack state, stores intr_main, and branches into AgbMonMain explicit SWI dispatch through sys_table agb2cgb, halt, and stop system-call handlers stack pointers for user, IRQ, SVC, and FIQ modesflowchart TD A[\"<b>Reset vectors</b><br>start_v branches into start_m\"] --> B[\"<b>Interrupts off</b><br>disable IRQ and FIQ when needed\"] B --> C[\"<b>Mode stacks</b><br>set SVC, IRQ, SYS, and FIQ stack pointers\"] C --> D[\"<b>Clear stack area</b><br>clear the monitor's stack buffer in WRAM\"] D --> E[\"<b>Install intr_main</b><br>write interrupt handler into INTR_VECTOR_BUF\"] E --> F[\"<b>Branch to AgbMonMain</b><br>enter the main monitor runtime\"] F --> G[\"<b>Return path</b><br>usr_reset reinitializes state and jumps back into WRAM or ROM\"]The actual vector table is more revealing than a generic “startup file” label suggests: Vector Branch target What that means in practice start_v start_m Reset entry goes straight into the main startup path undef_v fiq_v Undefined instructions are funneled into the same monitor-side exception path swi_v swi_m Software interrupts are decoded through the syscall table code_abort_v fiq_v Prefetch aborts are redirected into the monitor exception path data_abort_v fiq_v Data aborts are redirected the same way reserve_v fiq_v Reserved vector is handled by the same monitor trap path irq_v irq_m IRQs jump through the monitor’s interrupt trampoline That is a useful clue about the role of the file.This is not a tiny retail-only boot stub.It is a monitor-oriented bring-up layer that wants control of almost every exception class.The stack and interrupt setup are also explicit in the source.start_m and bankreg_init_stack_clear switch through SVC, IRQ, and SYS modes, assign dedicated stack pointers, clear the stack area in WRAM, disable IME, and install intr_main into INTR_VECTOR_BUF at the top of CPU WRAM.That matches the shared memory-map headers cleanly: INTR_CHECK_BUF is defined as CPU_WRAM_END - 0x8 INTR_VECTOR_BUF is defined as CPU_WRAM_END - 0x4 usr_sp, irq_sp, svc_sp, and fiq_sp are all anchored relative to WRAM_ENDSo the startup path is not only initializing the CPU.It is also laying out a small resident monitor workspace at the very top of internal WRAM for interrupt state and exception return handling.The sys_table is especially rich.It preserves 43 entries, which makes the file feel much closer to a BIOS-style service layer than a one-purpose loader. Service range Examples visible in sys_table Why it matters Reset and control usr_reset, RegisterRamReset32, halt, stop, restart_v, pause_reg_h_set The monitor exposes reset and pause control directly through SWI dispatch Interrupt wait Intr_Wait, VBlankIntr_Wait Wait-for-interrupt behaviour is part of the system layer, not a game-side helper Math DivS32, __16__rt_sdiv, SqrtU32, ArcTanS32, ArcTanS32_2 The monitor bundles fixed math helpers alongside boot/runtime code Graphics and transforms CpuSet16_32, CpuFastSet32, BgAffineSet32, ObjAffineSet32, BitUnPack32 Core copy, unpack, and affine helpers are wired into the same service table Decompression and filters LZ77UnComp8, LZ77UnComp16, HuffUnComp32, RLUnComp8, RLUnComp16, DiffUnFilter8_8, DiffUnFilter8_16, DiffUnFilter16_16, MonCheckSum32 The boot monitor is directly tied to the same asset-processing formats seen elsewhere in the repo Sound and music SoundBiasChange16, SoundInit, SoundMode, SoundMain, SoundVSync, SoundClearAll, SoundVSyncOff, SoundVSyncOn, MidiKey2fr, MPlayOpen, MPlayStart, MPlayStop, MPlayContinue, MPlayFadeOut, MPlyJmpTblCopy Audio bring-up and playback are treated as system services, not just app code Link boot MultiBootMain Multiboot support is built into the same low-level runtime surface The split across crt0Arm.s, crt0ArmCst.s, crt0IncludeArm.s, crt0KeyAddr.s, crt0subArm.s, crt0subArmCommon.s, and crt0subArmCst.s points to a maintained startup framework with shared constants, include fragments, helper routines, and table data rather than one single bootstrap file.That split is also visible in the responsibilities of the nearby files: crt0IncludeArm.s carries a full GBA ROM header template, including the Nintendo logo block, maker code, device type byte, and header checksum field crt0subArmCommon.s contains the shared interrupt, wait, checksum, math, and decompression helpers crt0subArm.s and crt0subArmCst.s both preserve an Agb2Cgb routine, with the fuller version fading a bitmap-style screen and then calling the agb2cgb service crt0KeyAddr.s preserves a dense table of key-address words whose exact role still needs more decoding, but which clearly belongs to the startup support layer rather than user codeThere are a few especially useful low-level details in that startup cluster: crt0IncludeArm.s embeds a full GBA cartridge header template, including the standard Nintendo logo bytes and fixed header fields at 0x080000A0 onward crt0Arm.s clears and lays out separate user, IRQ, SVC, and FIQ stack regions inside CPU WRAM before entering the monitor crt0subArmCommon.s installs intr_main, routes SIO interrupts to JoyIntCommon, and routes VBlank interrupts to SoundVSync the same file also preserves software implementations of division, square root, arctangent, interrupt wait, and checksum helpers crt0subArm.s contains Agb2Cgb, which builds a simple background/palette effect before branching into the lower-level agb2cgb routineThat makes the AGB side feel broader than the CGB package.It is not only a boot monitor.It is also carrying a real startup framework, interrupt framework, and a small library of low-level math and decompression support.AgbComp in More DetailAgbComp.cpp is a self-contained Windows-side conversion utility with explicit file IO, option parsing, multiple compression back ends, and output-format handling.AgbComp.cpp Internals AgbComp.cpp function usage(void) function argCheck(int argc, char *argv[]) function optionCheck(int argc, char *argv[]) function infileOpen(int argc, char *argv[]) function outfileOpen() function imageReadWrite(FILE *fpi) function RawWriteBin(u8 **Srcpp, u32 SrcNum) function DiffFiltWrite(u8 **Srcpp, u32 SrcNum, u8 **Destpp) function RLCompWrite(u8 **Srcpp, u32 SrcNum, u8 **Destpp) function LZCompWrite(u8 **Srcpp, u32 SrcNum, u8 **Destpp) function HuffCompWrite(u8 **Srcpp, u32 SrcNum, u8 **Destpp) function MakeBinTree(u32 TableNo, u32 Bit, u32 CheckNodes) global outfileNamep global labelNamep global outFileType global lzSearchOffset global huffBitSize global diffBitSize 29 17 1057 Its usage text and source show support for binary output, raw headers, differential filters, run-length encoding, LZ77, and Huffman packing.That makes it look like a general AGB data-preparation utility rather than a one-purpose compressor.Bmp2Agb in More DetailBmp2Agb.cpp has its own argument parser, bitmap readers, output-path logic, and the same broad family of compression back ends seen in AgbComp.Bmp2Agb.cpp Internals Bmp2Agb.cpp function usage(void) function argCheck(int argc, char *argv[]) function optionCheck(int argc, char *argv[]) function infileOpen(int argc, char *argv[]) function infileParamsRead() function bmpParamRead(FILE *fp, s32 offset, int whence, void *ptr, size_t size) function paletteReadWrite() function bmp24bto16b(FILE *fpi) function IndexImage2Char(FILE *fpi) function IndexImage2Screen(FILE *fpi) function RGBImage2RawScreen(FILE *fpi) function DiffFiltWrite(u8 **Srcpp, u32 SrcNum, u8 **Destpp) function RLCompWrite(u8 **Srcpp, u32 SrcNum, u8 **Destpp) function LZCompWrite(u8 **Srcpp, u32 SrcNum, u8 **Destpp) function HuffCompWrite(u8 **Srcpp, u32 SrcNum, u8 **Destpp) global labelName global paletteName global indexFlipFlag global paletteWriteFlag global outType global outIndexOffset 44 15 1651 The source and usage text show: -bi binary output, -bm bitmap mode, and -c character mode -f flip, -np no palette, and -o offset image shifting options bitmap readers and converters like bmpParamRead(), bmp24bto16b(), IndexImage2Char(), IndexImage2Screen(), and RGBImage2RawScreen() the same differential, run-length, LZ77, and Huffman back ends used elsewhere in the toolchainSo Bmp2Agb looks like the graphics-side companion to AgbComp, handling the conversion of PC bitmap data into AGB-friendly tile, screen, and palette resources.Headers, Libraries, and DocsThe AgbInclude directory is worth treating as its own layer rather than just a list of filenames.It is effectively a compact low-level SDK surface that the startup and monitor code both depend on. AgbInclude AgbInclude is an umbrella include layer rather than one single header dump.It bundles the memory map, system-call prototypes, multiboot declarations, sound interfaces, print-debug hooks, and both C and assembly forms of the shared constants and macros. 📄 Agb.h Umbrella include that pulls in the main AGB header set 📄 AgbDefine.h Shared C constants and register bitfields 📄 AgbDefine.s Shared assembly constants 📄 AgbDefineArm.s ARMASM constants and bitfield definitions 📄 AgbMacro.h C helper macros 📄 AgbMacro.s Assembly helper macros 📄 AgbMacroArm.s ARMASM helper macros 📄 AgbMemoryMap.h C memory-map layout 📄 AgbMemoryMap.s Assembly memory-map layout 📄 AgbMemoryMapArm.s ARMASM memory-map layout 📄 AgbMultiBoot.h Multiboot structures and limits 📄 AgbSound.h Sound interfaces 📄 AgbSystemCall.h SWI-facing system-call declarations 📄 AgbTypes.h Shared type definitions 📄 IsAgbPrint.h IS-AGB-EMULATOR print-debug interface The top-level Agb.h file makes that intent explicit.It is an umbrella include that pulls in AgbTypes.h, AgbDefine.h, AgbMemoryMap.h, AgbMacro.h, AgbSystemCall.h, AgbSound.h, AgbMultiBoot.h, and IsAgbPrint.h.So the monitor code is sitting on top of a deliberate shared platform layer, not just ad hoc local headers.A few of those include files are especially informative: Header or include What it contributes Why it matters AgbMemoryMap.h and AgbMemoryMapArm.s BOOT_ROM, EX_WRAM, CPU_WRAM, PLTT, VRAM, OAM, ROM bank ranges, INTR_CHECK_BUF, INTR_VECTOR_BUF, and many hardware registers Confirms the startup and monitor code are using a formal shared memory-map definition rather than magic addresses AgbSystemCall.h SoftReset, RegisterRamReset, Halt, Stop, IntrWait, VBlankIntrWait, math helpers, copy helpers, decompression helpers, and sound interfaces Matches the services exported through crt0Arm.s sys_table AgbMultiBoot.h MultiBootParam, MULTIBOOT_NCHILD = 3, header size 0xc0, and transfer-size limits from 0x100 to 0x40000 Shows multiboot support was part of the same shared low-level environment IsAgbPrint.h Intelligent Systems IS-AGB-EMULATOR print-debug API using a buffer at 0x08fd0000 to 0x08fdffff Ties the repo directly to emulator-side debug tooling rather than only target-hardware code IsAgbPrint.h is especially nice context because it is not just a generic logging stub.It explicitly identifies itself as an IS-AGB-EMULATOR print debug library from Intelligent Systems, warns against using it inside tight main loops, and documents a dedicated host-visible print buffer range.That gives the whole AGB repository a much clearer development-hardware flavor.AgbMemoryMap.s is especially useful because it shows the monitor’s expected global layout very plainly: boot ROM at 0x00000000 external WRAM at 0x02000000 CPU WRAM at 0x03000000 palette RAM at 0x05000000 VRAM at 0x06000000 OAM at 0x07000000 cartridge ROM banks from 0x08000000It also fixes the internal stack and system-buffer layout that the startup code is using, including INTR_CHECK_BUF and INTR_VECTOR_BUF near the top of CPU WRAM.AgbMultiBoot.h is another strong clue about scope.It preserves the full MultiBootParam structure, constants for the child-count and transfer-size limits, and named multiboot error codes.So the serial-download path described by the monitor spec was not a vague idea.The tree still contains the actual parameter structure Nintendo expected that path to use.The AgbLib folder preserves several prebuilt libraries and associated .alf outputs: libagbsyscall.a libagbsyscall154.a libagbsyscall98r2.a libisagbprn.a libagbsyscall_arm.alf libagbsyscall_arm154.alf libagbsyscall_arm99r1p2.alf libisagbprn_arm.alfThe naming suggests reusable system-call and print-support layers, with multiple variants preserved for different toolchain or SDK revisions.The doc tree adds useful workflow context through files like AgbStack.txt, joyboot images, multiboot notes, and GNUPro migration notes. doc The doc folder is one of the most useful context dumps in the AGB tree because it mixes formal monitor specs, stack-layout notes, serial-boot material, and later workflow docs in one place. 📄 AGB－CPUモニタプログラム仕様書_000317.doc Formal AGB CPU monitor specification created on 17 March 2000 📄 AgbStack.txt CPU WRAM stack layout and interrupt-stack notes 📄 AGBシリアルブートマニュアル.doc Serial boot manual 🖼️ 000209-agbマルチブート状態遷移図.jpg Multiboot state-transition diagram 🖼️ joyboot-a.gif Joyboot reference image 🖼️ joyboot-b.gif Joyboot reference image 📄 AGB_ROM内登録データ案_040907.xls Proposed ROM registration-data sheet 📄 AGB_ROM内登録データ (秘)_040907.xls Internal ROM registration-data sheet 📄 拡張モジュール判別手順.txt Expanded module identification procedure 📄 GNUPro-98r2→GNUPro-99r1対応方法.txt GNUPro migration note The March 2000 monitor spec is especially useful because it confirms the overall boot design in plain language.It says the program performs initialization, displays the GAMEBOY / Nintendo logo, checks cartridge registration data, and then starts the game.It also explicitly says the monitor can launch software downloaded over serial communication, not just normal cartridge software.The flowchart text in that same document matches the source closely: initialize RAM and registers ramp sound bias from 0 to 0x200 switch into CGB compatibility mode if a CGB cartridge is detected expand the logo display data into VRAM initialize SIO boot handling run the demo display while also accepting serial downloads continue SIO processing even if the cartridge checks fail start cartridge code from 0x08000000 start downloaded external-WRAM code from 0x02000000Stack Layout and Monitor Save ConventionsAgbStack.txt is more than a rough memory sketch.It documents how the monitor expected CPU WRAM to be partitioned during startup, IRQ handling, and nested system calls. Address Role in AgbStack.txt Why it matters 3007F00h SP_usr Top of the user stack area 3007FA0h SP_irq Dedicated IRQ stack start 3007FE0h SP_svc Supervisor or system-call stack start 3007FF4h sound buffer address Confirms a fixed WRAM slot for sound-side state 3007FFAh interrupt check flag Matches the interrupt bookkeeping described in startup code 3007FFBh SoftReset() return target Shows soft reset was expected to return through a fixed CPU-WRAM slot 3007FFCh interrupt handler address The monitor calls the user interrupt routine through this saved vector The same note also explains the monitor’s save conventions.Normal IRQ handling pushes R0 to R3, R12, and LR_irq on the IRQ stack before branching through the handler slot at 3007FFCh.Nested IRQ handling then saves SPSR_irq, switches back into system mode, and continues on the user stack.System calls use a parallel pattern on the SVC stack, saving SPSR_svc, R11, R12, and LR_svc before switching back to the user stack for the rest of the work.That level of detail matters because it confirms the AGB monitor was designed as a resident runtime layer with documented stack discipline, not just a one-shot boot stub.Serial Boot and One-Cartridge PlayThe separate AGBシリアルブートマニュアル.doc pushes the download side much further than the monitor spec alone.It is version 1.0, dated 9 April 2001, and explains serial boot as a supported way to launch code on a GBA even with no cartridge inserted by downloading a program into external WRAM over the six-pin serial port.The manual also makes the intended scale explicit: the maximum downloaded program size is 2 Mbit, or 256 KB the parent unit can boot up to three child units the same system was used for 1 cartridge play, where only the parent needs the full game cartridgeThat lines up neatly with the source-side definitions in AgbMultiBoot.h, where MULTIBOOT_NCHILD is 3, the header size is 0xc0, and the allowed transfer size ranges from 0x100 to 0x40000.The manual is especially useful because it explains what a downloaded child program had to do differently from a normal cartridge build: use crt0_multi_boot.s instead of the normal crt0.s place the text section at 0x02000000 instead of 0x08000000 avoid clearing the external-WRAM area that already contains the downloaded program still link a ROM-style registration header so the monitor can validate the imageThe parent-side workflow is also described in enough detail to connect it back to the low-level monitor and syscall layer:flowchart TD A[\"<b>Prepare header</b><br>set masterp and server_type\"] --> B[\"<b>Initialize</b><br>call MultiBootInit()\"] B --> C[\"<b>Probe children</b><br>call MultiBootMain() every frame\"] C --> D[\"<b>Check state</b><br>wait for probe_count == 0 and client_bit != 0\"] D --> E[\"<b>Start transfer</b><br>call MultiBootStartMaster()\"] E --> F[\"<b>Continue polling</b><br>keep calling MultiBootMain()\"] F --> G[\"<b>Transfer core</b><br>system call MultiBoot() runs internally\"] G --> H[\"<b>Success check</b><br>MultiBootCheckComplete() becomes non-zero\"]The same manual warns about a couple of failure cases that also help explain why this repository carries both monitor code and toolchain support around the feature: DMA must be stopped during transfer, including direct sound DMA an invalid source address or transfer size will fail the boot MultiBootMain() can return 0 even when nothing is connected, so the caller still has to inspect client_bitTaken together, the manual, the monitor spec, the startup sys_table, and AgbMultiBoot.h all point to the same conclusion.The AGB boot ROM repository is not only preserving the boot monitor itself.It is also preserving Nintendo’s intended software model for serial download and one-cartridge multiplayer boot.Build-Side NotesTwo of the most useful explanatory text files are actually in build, not doc: AGBモニタ履歴.txt and AGBデバッガ対応方法.txt.Together they show how the monitor changed over time and how it was expected to cooperate with TS-era debugger setups.The monitor history file is dense enough that a few milestones are worth pulling out directly: Version Visible change Why it matters V0.30 provisional title demo and a sound BIAS set or reset system call Shows the monitor started life with explicit demo and audio bring-up behaviour V1.00 provisional demo sound, provisional sound driver, system calls moved into assembler Confirms the monitor and low-level service layer were being built together V1.20 stack and system area moved into internal WRAM, with explicit SP_usr, SP_irq, SP_svc, and SP_fiq addresses Lines up directly with AgbStack.txt and the crt0 startup code V1.30 inserted-cartridge identification flag flipped to CGB=0 and AGB=1 Shows that cartridge-type detection was still being actively revised V1.54 CGB compatibility-mode amplitude setting and register or RAM reset system call added Ties the AGB monitor back to cross-generation compatibility handling V2.02 forced SIO boot added with START + SELECT Explains why the monitor spec and runtime keep talking about serial downloads V2.10 debugger jump destinations changed for 1M-DACS, 8M-DACS, and no-DACS setups Gives the debugger note more concrete historical context V5.00 gamma correction, pause-register timing change, and Game Boy logo palette creation routine added Shows the later monitor still had an active presentation layer, not just debug plumbing V5.11 immediate jump to cartridge for Sharp evaluation use A nice example of a hardware or testing-specific branch in the changelog The debugger note is equally concrete once broken into steps: Debugger step What the note says Why it matters Setup place debugger registration data at 8000000h and write a 32-bit undefined instruction there The debugger path is entered deliberately through an exception setup Flagging change 800009Ch to A5h Marks the cartridge image so the monitor knows to jump into debugger space Exception save save SPSR_*, CPSR_*, R12_*, and LR_* at 3007FE0h onward Matches the stack and WRAM conventions preserved elsewhere in the tree Debugger jump jump to 9FFC000h or 9FE2000h depending on the d7 flag at 80000B4h Shows the monitor was built to support more than one debug-memory layout Writable state only R12_* and SP_* are modifiable by default because LR_* already stores the return path Makes the debugger environment feel very controlled rather than ad hoc That is enough to show the AGB package was not only a boot monitor plus tools.It also preserves a fairly mature debugger-facing monitor environment with documented entry conditions and saved-state conventions.Project and Map ArtefactsThe extracted build tree also preserves the glue around the source code itself.AgbMon.apj is a project file full of readable configuration strings, while Arm.map and ArmDebug.map preserve the linked image layout down to the symbol level.The map file is especially concrete.It identifies the built image as D:\\Agb\\AgbMonArm\\Release\\AgbMon.axf, places the Init area from crt0Arm.o at base 0x00000000, and then lays out the rest of the monitor image in order: crt0subArm.o and crt0subArmCommon.o as the startup and service core AgbMPlay.o, AgbSound.o, and AgbMon.o as the main runtime code AgbSoundAsmArm.o, multi18_Arm.o, and the sd_*_arm.o files as assembly-side support and audio assets AgbLogoData.o and AgbMonData.o as the fixed read-only monitor data zero-initialized runtime state for AgbMonSub16.o and AgbMon.o in CPU WRAMArmDebug.map goes even further by exposing the final linked addresses of the monitor services.It shows start_v at 0x008000, AgbMonMain at 0x0099f4, MultiBootMain at 0x00aa82, sys_table at 0x0081c8, and DacsCheck at 0x03000000.That is a very useful cross-check against the prose in the page because it confirms the monitor’s reset entry, runtime core, multiboot support, service table, and WRAM state are all present in the final linked image.AgbMon.apj ties those files together as a real build workspace rather than a loose dump.Its strings describe a Thumb-ARM Interworking Image, reference AgbMon.axf, include Debug, DebugRel, and Release configurations, and list the same crt0, AgbMon, AgbSound, AgbMPlay, helper, and sd_* sources seen in the extracted tree.It also preserves linker options such as -ro-base#0x8000, -rw-base#0x02000000, -map, and -first#crt0Arm.o(Init).The Preserved Monitor BinaryThe repository also keeps the built output itself at the trunk root as AgbMnTs3_000605.bin.That file is exactly 16,384 bytes, which is the expected 16 KB size for the GBA boot ROM region defined in AgbMemoryMap.h.The nearby AgbMnTs3_000605_Sum.txt file makes that output more useful because it preserves explicit checksum values for the built binary: Checksum type Value Little-endian 8bit Check 0x0018f23a Little-endian 16bit Check 0x0da3ccc7 Little-endian 32bit Check 0xbaae187f Big-endian 8bit Check 0x0018f23a Big-endian 16bit Check 0x0b675f73 Big-endian 32bit Check 0xe5447ff5 That small text file matters because it shows the binary was being tracked as a concrete build artifact, not just left as an orphaned output with no validation data around it.It also lines up neatly with the monitor history, where the NITRO-V0.01 note explicitly calls out a checksum change from baae187f to baae1880.What the AGB Side PreservesTaken together, the AGB repository preserves a fairly complete low-level handheld support package rather than one narrow boot ROM source drop.The pieces on disk point to: a real startup path a monitor program and its helper code shared hardware headers and macros versioned support libraries internal graphics and compression tools documentation tied to stack layout, joyboot, and SDK or toolchain context Gigaleak - Game Boy Color Boot ROM Repository For the smaller and older-style CGB monitor build package, check out the Game Boy Color boot ROM page. </p> </div> </blockquote></a></div>", "excerpt": "The Nintendo Gigaleak preserves the AGB boot ROM material in two useful forms. Inside other/agb_bootrom it survives as a real Subversion repository, and separately the leak also includes agb_bootrom_trunk.zip, an extracted working tree that makes the source much easier to inspect. Gigaleak - SNES Source Code Leak For the wider...", "tags": ["gameboy","gba","leak","sourcecode"], "image": "/public/generated/placeholders/game-boy-advance-boot-rom-repository.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Gigaleak - Game Boy Color Boot ROM Repository", "url": "/game-boy-color-boot-rom-repository", "content": "The Nintendo Gigaleak preserves the CGB boot ROM material in two useful forms.Inside other/agb_bootrom it survives as a compact SVN repository, and separately the leak also includes cgb_bootrom_trunk.zip, an extracted working tree that exposes the actual DMG-format source files directly. Gigaleak - SNES Source Code Leak For the wider Nintendo Gigaleak overview, including the other major archives, check out this post. Here, monitor means a small low-level boot control program, not the handheld’s physical screen.So when this page says boot monitor binary, it means a compiled startup/control program that initializes hardware, runs checks, and then hands off to the cartridge code.At a GlanceThe CGB repository preserves: a compact SVN history rather than a single loose boot ROM dump two built boot monitor binaries at the root a tiny DMG-era build package with plaintext source files a batch wrapper that still preserves the old ISDMG and ISLINK flow two dated boot monitor specification documents from 1998Glossary of Key TermsIf you are new to CGB boot-ROM and toolchain terms, this quick glossary should help: CGB - Game Boy Color platform terminology. DMG - Original Game Boy generation and naming used in tools/source formats. ES2 - Likely Engineering Sample 2, a specific pre-release hardware revision target. SVN - Subversion version-control repository format. VRAM - Video RAM used for tile and background display data. WRAM - Work RAM used for runtime state and scratch memory. OAM - Object Attribute Memory used for sprite attributes. Shift-JIS - Japanese text encoding used in comments/strings. VBlank - Vertical blank interval used for safe display updates. SGB - Super Game Boy compatibility path/check logic. NMI - Non-maskable interrupt path used for timing-critical behavior. Boot monitor binary - Compiled startup/control program that “monitors” boot-time state (hardware init, cartridge header/checksum validity, mode flags, and palette-selection state) before handing off to game code.What the Revision History ShowsIts visible revision metadata shows a short one-shot import window rather than a later tool-enrichment phase. Revision What it appears to do Why it matters 1 Creates the basic SVN layout with trunk, branches, and tags Shows this was preserved as a real repository rather than a loose file dump 2 Imports the useful CGB working tree in one pass Brings in the .com outputs, build folder, and dated boot monitor spec docs together Repository Revisions on disk Earliest date Latest date Visible author cgb_bootrom 3 revisions (0 to 2) 24 April 2009 24 April 2009 nakasima Of course 2009 is far too late for the CGB boot ROM to have been developed in this way (The GBA was released in 2001!), so it is likely that this repository was created as a compact backup package rather than a real-time development repository.Trunk Structure trunk The CGB repository contains two built boot monitor binaries at the root, a very small build folder with DMG-format source inputs and a batch script, and two dated documents in doc. ⚙️ AgbCgbMn2_1.com Built AGB/CGB boot monitor output ⚙️ CgbEs2Mn.com Alternate [ES2](#glossary-es2)-targeted boot monitor output 📁 build Small DMG-era build package 📄 build/agb_cgb.dmg Main assembler input 🖥️ build/asmagbcgb.bat Batch wrapper for the build 📄 build/cgb_es2.dmg Alternate ES2 source branch 📄 build/cgbw6def.dmg Smaller definitions/configuration source 📁 doc Dated CGB notes from 1998 📄 doc/CGB－CPUモニタープログラム仕様書_980403.doc Internal spec with filename `980403` and an internal creation date of 26 March 1998 📄 doc/CGB－CPUモニタープログラム仕様書_980615.doc Internal document dated 15 June 1998 Build StructureThe repository is compact enough that the whole build package fits into one simple workflow:flowchart LR A[\"<b>asmagbcgb.bat</b><br>batch wrapper\"] --> B[\"<b>ISDMG AGB_CGB</b><br>assemble main DMG-format source\"] B --> C[\"<b>ISLINK @LINKAGCG.LNK</b><br>link boot monitor image\"] C --> D[\"<b>AgbCgbMn2_1.com</b><br>AGB/CGB boot monitor output\"] C --> E[\"<b>CgbEs2Mn.com</b><br>ES2 boot monitor output\"] build The CGB build folder is small enough to read almost as one batch-driven package: one wrapper script, two main DMG-format source inputs, and one smaller definitions file. 🖥️ asmagbcgb.bat Batch wrapper for the DMG assembler and linker flow 📄 agb_cgb.dmg Main assembler input 📄 cgb_es2.dmg Alternate ES2 source branch 📄 cgbw6def.dmg Smaller definitions/configuration source The Batch Build Wrapperasmagbcgb.bat is only four lines long: ISDMG AGB_CGB ISLINK @LINKAGCG.LNK PAUSE cvt.batThat small script is still very useful because it proves the package was built around one named main source file, one named linker command file, and a final conversion step.The one obvious missing build artifact is LINKAGCG.LNK itself.It is referenced directly by asmagbcgb.bat, but it does not survive in the extracted cgb_bootrom_trunk tree or the compact other/agb_bootrom repository snapshot.So the overall build flow is preserved, but the exact linker command file still appears to be absent from the leaked CGB package.The Source FilesThe extracted CGB working tree shows that all three build inputs are plaintext source files rather than opaque binary artifacts.The Main Boot Monitor Sourceagb_cgb.dmg is a human-readable assembly source file at 1428 lines.Its own header names it monitor, which is where this page’s “boot monitor” terminology comes from. agb_cgb.dmg function init_rom function vram_clear function ram_clear function cp_hl2de function vblk_wait function set_cgb_pltt function init_sound function fade_out function cgb_sub function maker_check function select_palette function cpu_mode_change table hdma_data table title_key2pltt table nin_data table rdata table set_ninbg_soft 12 5 1428 The opening lines place all of the code into the first ROM bank (BANK0 GROUP 0), pull in the CGB hardware register definitions from cgb_reg, and pull in the shared memory-layout and palette constants from cgbw6def (the definitions file covered later on this page). This is much more than a tiny jump into a final boot image.The visible labels and data blocks show Nintendo logo and title-screen data, VRAM and OAM clearing paths, sound initialization, title sound timing, palette generation, maker checks, SGB checks, and CPU-mode changes. The header comments are also especially revealing.Unlike cgb_es2.dmg, this file carries later maintenance notes dated 21 August 1999 and 30 March 2000, which makes it look like a maintained later branch built on top of the older monitor source. What the Boot Monitor Actually DoesReading through agb_cgb.dmg makes the overall flow much clearer than the filename alone would suggest.The monitor is not just a minimal boot shim.It spends most of its time on a staged logo, title, palette, and handoff sequence.The top-level flow looks like this: set the stack and enter init_rom clear VRAM, WRAM, and OAM copy and double the Nintendo logo data into character memory compare the copied logo against the expected nin_data table run the header checksum switch into the title sequence with sound and palette updates detect cartridge metadata and choose a palette group switch into either the DMG compatibility path or the cartridge’s color-capable mode and hand off to the inserted gameflowchart TD A[\"<b>init_rom</b><br>set stack and initialize registers\"] --> B[\"<b>Clear memory</b><br>VRAM, work RAM, and OAM\"] B --> C[\"<b>Expand logo data</b><br>copy and double Nintendo logo tiles\"] C --> D[\"<b>Validate cartridge</b><br>compare logo and run header checksum\"] D --> E[\"<b>Title sequence</b><br>show logo, sound, and palette updates\"] E --> F[\"<b>Select palette</b><br>identify cartridge and choose palette group\"] F --> G[\"<b>cpu_mode_change</b><br>switch DMG or CGB mode\"] G --> H[\"<b>Game start</b><br>jump to cartridge code at 0100H\"]That is a useful distinction for readers expecting the retail CGB boot ROM to be “just the Nintendo logo plus a jump.”The source preserved here is very much a monitor-oriented implementation of that process, with a fair amount of staging, bookkeeping, and palette logic wrapped around it.The Compatibility DatabaseThe later half of agb_cgb.dmg is especially revealing because it preserves a fairly large built-in compatibility database rather than a single hardcoded palette table.At the source level, that database breaks down into: SINGLE_SOFT_NUM = 64 + 1 PLURAL_SOFT_NUM = 14 SOFT_SUM_NUM = 93 + 1 soft_check_single as the main table of one-to-one title checks soft_check_plural and soft_check_plural_data for titles that need one more level of disambiguation pltt_index_group_index as the bridge from game identity to palette group pltt_index_group as the grouped OBJ0, OBJ1, and BG palette layout pltt_data as the actual color words used to build the final CGB palette buffersThat is a lot more structure than a simple “default palette” feature.It shows Nintendo had turned the boot monitor into a small compatibility database that classifies cartridge headers before handing them off to the later palette-group and color-data stages.The source comments also make the database much easier to read once the file is decoded as Shift-JIS.Some of the visible title abbreviations in soft_check_single and soft_check_plural_data include: 役満 (Yakuman) テニス (Tennis) テトリス (Tetris) ドクマリ (Dr. Mario) カービィ (Kirby) ゼルタ (Zelda) ドンキー (Donkey Kong) ポケ赤 (Pokemon Red) ポケ緑 (Pokemon Green) ポケ青 (Pokemon Blue) ポケ黄 (Pokemon Yellow) KIRBY CHESS INVAD ASTRO WARI2 SOCCR PKBOM G&W (Game and Watch)That list is only partial, but it is already enough to show what the table was doing in practice.This was not a generic “DMG cartridge” palette system.It was explicitly trying to recognize a long list of Nintendo-published or Nintendo-relevant games and attach a more suitable palette profile to each one.A few especially recognizable entries line up like this: Title label Likely game Checksum byte Packed selector Palette no. Group type 役満 Yakuman $16 0*$20+18 18 0 テニス Tennis $D1 5*$20+2 2 5 テトリス Tetris $DB 0*$20+7 7 0 ドクマリ Dr. Mario $3C 2*$20+11 11 2 カービィ Kirby $5C 5*$20+8 8 5 ゼルタ Zelda $70 5*$20+17 17 5 ドンキー Donkey Kong $19 3*$20+6 6 3 ポケ赤 Pokemon Red $14 1*$20+16 16 1 ポケ緑 Pokemon Green $AA 1*$20+28 28 1 ポケ黄 Pokemon Yellow $15 0*$20+7 7 0 The interpretation is straightforward up to that point.The checksum byte and packed selector are direct evidence from the source.The later sections on palette groups and pltt_data explain what those selectors expand into visually.The plural tables are just as revealing.They preserve shorter secondary title fragments such as ポケ青 (Pokemon Blue), WARI2 (Wario Land 2), SOCCR (Soccer), PKBOM (Pocket Bomberman), G&W (Game & Watch), メトロ2 (Metroid II), TET2 (Tetris 2), TETAT (Tetris Attack), ドンL (Donkey Land), and ドンL2 (Donkey Land 2).That makes the lookup logic much easier to interpret.The monitor was not only matching one checksum to one palette entry.It also had a second-stage disambiguation path for collisions, where one checksum bucket could be split again by title fragment before the final selector was chosen.So the compatibility logic looks like a three-step chain: check the cartridge header checksum fall back to a plural-title disambiguation table when needed unpack the final selector into palette number and palette-group typeflowchart LR A[\"<b>Cartridge header</b><br>read title and checksum bytes\"] --> B[\"<b>name_sum</b><br>compute title checksum\"] B --> C[\"<b>soft_check_single</b><br>try direct game match\"] B --> D[\"<b>soft_check_plural</b><br>enter collision bucket\"] D --> E[\"<b>soft_check_plural_data</b><br>disambiguate by title fragment\"] C --> F[\"<b>pltt_index_group_index</b><br>packed selector\"] E --> F F --> G[\"<b>Split selector</b><br>palette no. and group type\"] G --> H[\"<b>pltt_index_group</b><br>OBJ0 / OBJ1 / BG group\"] H --> I[\"<b>pltt_data</b><br>expand to 15-bit CGB colors\"] I --> J[\"<b>Palette upload</b><br>apply final CGB palette buffers\"]The Earlier ES2 Sourcecgb_es2.dmg is another full plaintext source file at 1423 lines.Its structure is almost the same, but the header is much simpler and only carries a 21 July 1998 date line. cgb_es2.dmg function init_rom function vram_clear function ram_clear function cp_hl2de function vblk_wait function set_cgb_pltt function init_sound function fade_out function cgb_sub function maker_check function select_palette function cpu_mode_change table hdma_data table title_key2pltt table nin_data table rdata table set_ninbg_soft 12 5 1423 A quick diff between the two sources is revealing.Most of the monitor is the same, but agb_cgb.dmg adds the later maintenance comment block, changes the flow around init_rom2game, inserts an extra inc b flag-setting step, and swaps one small-logo copy path from ex_nindata to $ff80. So the best reading here is not “two totally different monitor programs.”It is “one older ES2-era source snapshot and one later maintained branch built on almost exactly the same codebase.” Title, Logo, and Fade SequenceOne of the most interesting parts of the source is how much work goes into the title presentation itself.The monitor does not just throw a fixed image at the screen.It builds the title sequence out of several small helpers: cp_nindata, cp_rdata, and chr2double prepare the Nintendo logo and R mark character data cp_ninbg, cp_cgblogo0_bg, and cp_cgblogo1_bg populate the background tilemaps init_sound and on_sound0_title handle the short title audio path fade_out and fade_out_sub gradually walk the palette data toward white before clearing the title backgroundThat makes the monitor feel much more like a small presentation program than a raw bootstrap.It has a proper sequence of character conversion, tilemap writes, sound timing, per-frame waits, and palette fading.The fade_out path is especially telling.It loops for 19*2 steps, repeatedly calling fade_out_sub, waiting for VBlank, and re-uploading the updated title palette.So even this small monitor source is doing a frame-by-frame effect, not just toggling a few registers once.Hardcoded Presentation DataThe title sequence is not only control flow.It also depends on a small set of fixed data blocks and timing constants that survive directly in the source and definitions file. Source item What it appears to hold Why it matters nin_data Expected Nintendo logo registration data Used for the cartridge-logo comparison check rdata Small R mark or related title graphic data Shows the title display was assembled from more than one graphic block hdma_data Small transfer setup block Suggests a dedicated transfer setup for title or palette staging TITLE_SOUND_TIMING 22 Controls when the title sound event is triggered TITLE_SOUND_COUNT_NUM 100 - TITLE_SOUND_TIMING Title-sequence sound counter setup TITLE_TIME_COUNT_NUM 68 Overall title display timing constant That is a nice reminder that the monitor is not just “logic plus a jump.”It also bundles fixed logo data, sound timing, and presentation-state constants for how the boot sequence should look and feel.The Definitions Filecgbw6def.dmg is only 103 lines, but it is a real source dependency rather than a mystery helper file. cgbw6def.dmg constant ex_nindata constant cpu_mode_data constant cgb_vram constant cgb_work_ram0 constant cgb_work_ram1 constant oam constant stack constant cgb_stack global name_sum global sel_pltt_flg global key_counter global pltt_grp_type 0 12 103 The top half defines the monitor’s memory layout, including VRAM, work RAM banks, OAM, CPU work RAM, stack positions, and palette-buffer scratch areas.The lower half defines palette IDs and small state bytes used while the monitor decides how to color the title sequence. That second half is especially interesting because the palette constants name built-in presets like CI_ZELDA_OBJ, CI_TETRIS, CI_METROID_OBJ, CI_CAMERA, CI_KIRBY_OBJ, and CI_GAMEWATCH_GB.So cgbw6def.dmg is also a compact data dictionary for the Game Boy Color boot monitor’s built-in palette-selection system. The Working Memory Layoutcgbw6def.dmg is also the clearest place to see how the monitor expected to use CGB memory while it was running. Region or buffer Address Role in the monitor ex_nindata $0104 Cartridge-side Nintendo logo registration data cpu_mode_data $0143 Cartridge CPU mode byte used during the final handoff cgb_vram $8000 VRAM base used for logo tiles, backgrounds, and palette staging cgb_work_ram0 $C000 Main work RAM bank 0 cgb_work_ram1 $D000 Switchable work RAM bank region oam $FE00 Sprite attribute memory cpu_work_ram $FF80 CPU work RAM cpu_work_dma_proc $FFC0 OAM DMA transfer routine area stack $FFFE Initial stack pointer cgb_stack $DFFE Expanded monitor stack position oam_bak $D100 OAM build buffer bg_bak $D600 Background build buffer ocpd_bak $D800 OBJ palette buffer bcpd_bak $D840 BG palette buffer bcpd_win $D8E0 Window-specific BG palette area pltt_id_grp_mem $D900 Palette index-group buffer cgb_24Bpltt_mem $DA00 Expanded palette data cgb_24Bpltt_all_mem $DD00 Larger full palette expansion area That layout makes the monitor feel very deliberate rather than improvised.It has dedicated staging space for sprite data, background data, palette groups, expanded palette words, and even a DMA routine area inside CPU RAM.Named Palette PresetsThe palette IDs in cgbw6def.dmg are easier to browse once they are grouped by the kind of job they appear to do. Preset type Examples What they suggest Generic tonal themes CI_SEPIA_4A, CI_SEPIA_4B, CI_BLUE_4A, CI_BLUE_4B, CI_GREEN_4A, CI_RED_4, CI_GRAY_4, CI_YELLOW_4 Reusable fallback palettes for broad categories of monochrome games Series and game-specific entries CI_ZELDA_OBJ, CI_TETRIS, CI_METROID_OBJ, CI_KIRBY_OBJ, CI_DONKEY_OBJ, CI_DONKEY_BG, CI_TENNIS_BG, CI_BASEBALL_BG, CI_PANEPON, CI_GAMEWATCH_GB, CI_RPG_BG, CI_CAMERA, CI_SPACE, CI_COOKIE Named presets for specific Nintendo properties and individual games, rather than only broad fallback palettes That mix is one of the clearest hints that Nintendo was tuning the CGB boot monitor for appearance, not just compatibility.The monitor had room for broad fallback color themes, but it also carried hand-labeled presets for specific games and well-known Nintendo properties.The Palette Selection SystemBy this point the overall shape of the palette system is clear: the compatibility tables identify the game, and the remaining logic decides which grouped palette preset to apply or whether to use the manual override path instead.The source also preserves a manual override path.KEY_CHECK_NUM is 12, and key2pltt_table maps those checks to palette choices, which lines up neatly with the four directional inputs multiplied across three button combinations.So this is not only an automatic per-game palette system.It also preserves the user-facing palette switcher Nintendo exposed on real hardware.The table itself is compact enough to summarize directly.Each entry stores one input code and one packed palette selection value, where the low 5 bits are the palette number and the high 3 bits are the palette-group type: Input code Palette selector Palette no. Group type $40 0*$20+18 18 0 $41 5*$20+16 16 5 $42 3*$20+25 25 3 $20 5*$20+24 24 5 $21 5*$20+13 13 5 $22 0*$20+22 22 0 $80 0*$20+23 23 0 $81 0*$20+7 7 0 $82 5*$20+26 26 5 $10 0*$20+5 5 0 $11 3*$20+28 28 3 $12 0*$20+19 19 0 Even without resolving every Japanese input comment perfectly, the structure is clear.The manual selector is not choosing from arbitrary colors.It is choosing from the same grouped palette system the automatic compatibility database uses.With the Shift-JIS comments decoded, the inputs are clearer too: $40, $41, $42 are Up, Up+A, and Up+B $20, $21, $22 are Left, Left+A, and Left+B $80, $81, $82 are Down, Down+A, and Down+B $10, $11, $12 are Right, Right+A, and Right+BSo the manual palette switcher really is a compact 12-way menu built out of d-pad direction plus optional A or B.Cartridge Checks and DMG or CGB HandoffThe maker_check, sgb_check, select_palette, and cpu_mode_change cluster shows how the monitor decides what to do with the inserted cartridge, including SGB-related checks.At a high level it: reads cartridge header bytes around $0143, $0144, and $014B checks for the newer maker-code path versus the older style computes a title checksum into name_sum searches the single-title and plural-title tables for a palette match updates curr_pltt_no and pltt_grp_type waits for VBlank and then switches into either CGB or DMG modeThat is the logic that ties the header constants, compatibility tables, and palette variables together.The monitor is effectively doing a small cartridge-identification pass before it decides how the boot sequence should look.One subtle detail in the source makes the handoff logic even clearer.During the title loop, select_palette is only called when bit 7 of cpu_mode_data is clear.Then cpu_mode_change checks the same byte again: if bit 7 is set, it writes the cartridge’s mode byte straight into KEY0 and follows the non-DMG path if bit 7 is clear, it forces DMG mode, adjusts OPRI, uploads the prepared CGB palette data for display, and conditionally resets the Nintendo backgroundSo the manual palette selector is really a DMG-compatibility feature sitting inside the broader CGB monitor flow.The source is not treating every cartridge the same way.It branches early between “native color-capable cartridge” and “older monochrome cartridge that may need a compatibility palette.”Palette Groups and Actual Color DataThe last stage of the palette system is where the earlier selectors become actual display colors.Once the decoded comments in cgbw6def.dmg and agb_cgb.dmg are lined up with the tables, that final expansion path is much easier to follow.At the symbolic level, the monitor knows about palette entries such as: CI_SEPIA_4A CI_SEPIA_4B CI_BLUE_4A CI_BLUE_4B CI_GREEN_4A CI_RED_4 CI_GRAY_4 CI_YELLOW_4 CI_GAMEWATCH_GB CI_RPG_BG CI_ZELDA_OBJ CI_TETRIS CI_METROID_OBJ CI_CAMERAWith the comments decoded, a few of those names are much clearer in plain Japanese too: セピア4A and セピア4B (Sepia 4A and Sepia 4B) ブルー4A and ブルー4B (Blue 4A and Blue 4B) グリーン4A (Green 4A) ゲームウォッチBG (Game & Watch BG) ゼルダOBJ (Zelda OBJ) テトリス (Tetris) メトロイドOBJ (Metroid OBJ) デバガメ (Camera) 宇宙 (Space)Then pltt_index_group combines those symbolic entries into 30 grouped presets for OBJ0, OBJ1, and BG.For example: Group OBJ0 OBJ1 BG 0 CI_MOGURA_OBJ CI_FLASH_1 CI_RPG_BG 7 CI_BLUE_4A CI_FLASH_1 CI_TETRIS 17 CI_ZELDA_OBJ CI_BLUE_4A CI_RED_4 20 CI_METROID_OBJ CI_GREEN_4A CI_BLUE_4A 26 CI_CAMERA CI_CAMERA CI_CAMERA That is one of the nicest low-level details in the whole source.Nintendo was not only choosing one palette per game.It was often choosing coordinated object and background palette triples.The final pltt_data table then resolves those symbolic names into actual 15-bit CGB color words.A few examples: Palette entry Sample color words セピア4A $7fff, $32bf, $00d0, $0000 ブルー4B $7fff, $6e31, $454a, $0000 ゼルダOBJ $7fff, $03e0, $0206, $0120 テトリス $7fff, $03ff, $001f, $0000 メトロイドOBJ $03ff, $001f, $000c, $0000 デバガメ $7fff, $033f, $0193, $0000 So the palette pipeline has three clear layers: identify a game map it to an OBJ0 and OBJ1 and BG group expand that group into concrete 15-bit CGB colorsHere are a few representative swatches generated from the actual pltt_data words: Palette entry Swatches Direct evidence セピア4A Converted directly from $7FFF, $32BF, $00D0, $0000 ブルー4B Converted directly from $7FFF, $6E31, $454A, $0000 ゼルダOBJ Converted directly from $7FFF, $03E0, $0206, $0120 テトリス Converted directly from $7FFF, $03FF, $001F, $0000 メトロイドOBJ Converted directly from $03FF, $001F, $000C, $0000 デバガメ Converted directly from $7FFF, $033F, $0193, $0000 That makes the palette story easier to grasp at a glance.The source is preserving the exact 15-bit color sets the monitor uploaded into CGB palette memory, not just symbolic names.Why the AGB_CGB Branch MattersOne subtle but useful detail is that the later agb_cgb.dmg branch is not only carrying the same broad logic as cgb_es2.dmg.It also contains a few maintenance-era clues that make it feel like a live follow-on version of the same monitor: later header notes dated 1999-08-21 and 2000-03-30 a small init_rom2game flow change with three inserted nop instructions an extra inc b flag-setting step before rombank_change one small Nintendo-logo copy change from ex_nindata to $ff80Those are all small edits, but together they make the relationship between the two source files easier to understand.cgb_es2.dmg looks like the older baseline, while agb_cgb.dmg looks like a carefully carried-forward branch rather than a rewrite.The actual source diff is also small enough to summarize cleanly: Change area cgb_es2.dmg agb_cgb.dmg Header block single 1998-7-21 line later 1999-8-21 and 2000-3-30 maintenance notes Post-fade_out flow direct jr init_rom2game three nop instructions, then fall through init_rom2game no extra flag write adds inc b Small Nintendo logo copy ld de, ex_nindata ld de, $ff80 So the later branch changes are real, but still very tightly scoped.They look like maintenance edits to a stable monitor rather than a substantial redesign.Outputs and DocumentsThe filenames at the root still tell a useful story.AgbCgbMn2_1.com appears to combine AGB, CGB, and Mn, which likely stands for monitor.CgbEs2Mn.com looks more specialized, with Es2 strongly suggesting a hardware revision, engineering sample stage, or internal target variant.The built outputs are also remarkably close to each other.Both AgbCgbMn2_1.com and CgbEs2Mn.com are exactly 2304 bytes, and a byte-level comparison only shows 11 differing positions.That fits very well with the source-level picture from agb_cgb.dmg and cgb_es2.dmg: these are two extremely closely related boot monitor builds rather than radically different binaries.Those binary differences are tightly clustered too: Offset AgbCgbMn2_1.com CgbEs2Mn.com 0x0F3 00 18 0x0F4 00 02 0x0F6 to 0x0FC seven-byte changed block seven-byte changed block 0x40A 80 04 0x40B FF 01 That clustering matches the source-level story nicely.Most of the binary is identical, with only one small early block and one tiny late block changing between the two boot monitor builds.The doc folder survives as two files: CGB－CPUモニタープログラム仕様書_980403.doc CGB－CPUモニタープログラム仕様書_980615.doc doc The doc folder is tiny, but it matters because both files are formal monitor specifications rather than loose notes.Together they show how Nintendo’s documented understanding of the CGB monitor changed between March and June 1998. 📄 CGB－CPUモニタープログラム仕様書_980403.doc Earlier monitor specification with filename `980403` and an internal creation date of 26 March 1998 📄 CGB－CPUモニタープログラム仕様書_980615.doc Revised monitor specification dated 15 June 1998 Those filenames translate naturally as CGB CPU Monitor Program Specification.So the docs are not stray notes.They are formal specification documents for the monitor package itself. Document Stored filename Meaning File size on disk 26 March 1998 initial version CGB－CPUモニタープログラム仕様書_980403.doc Earlier specification snapshot; filename still carries 980403 261,120 bytes 15 June 1998 initial version CGB－CPUモニタープログラム仕様書_980615.doc Later revised specification snapshot 111,616 bytes They survive as old Word documents, but textutil can still pull the main text out cleanly.That makes them much more useful than raw metadata alone.Both files identify themselves as Microsoft Word for Windows 95 documents, both preserve the path C:\\Word Documents\\cgb\\CGB, and the later 980615 revision still carries update-field names such as UPDATETITLE, UPDATEITEMNAME, UPDATEMODELNUMBER, and UPDATEREEDITDAY.That confirms a few practical details before even getting into the actual monitor design: the spec docs were being edited in a mid-1990s Windows Word environment they appear to come from a project directory literally named cgb the later revision was structured enough to preserve formal update fields rather than being an informal note dumpThe most useful improvement here is that the documents can now be read as real text rather than only metadata, which means the specifications can confirm several major behaviours directly.The 980403 document describes a six-part structure: overview memory map bit layout initialization program flowchart color-palette selection program start flowchart color-palette selection operationIts overview states that the program handles initialization, displays the Nintendo logo, checks the cartridge registration data, starts the game, and allows color-palette changes when a DMG cartridge is inserted.The later 980615 document is even more revealing.It reduces the contents to: overview memory map bit layout flowchartMore importantly, the flow description now matches the source very closely: clear OAM and VRAM banks 0 and 1 expand GAMEBOY and NINTENDO logo data into VRAM initialize the logo display palettes identify the inserted cartridge and set palette parameters allow palette-parameter changes during the logo display support 12 palette choices using d-pad plus A or B clear VRAM except for the Nintendo-logo character data switch CPU mode and start the game from 0100HThat is a strong confirmation that the source has been interpreted in the right direction.The specification and the extracted assembly are clearly describing the same system.The March and June revisions also show a real design shift rather than a cosmetic document refresh: Revision March 980403 June 980615 Structure six-part document four-part document Palette-selection model separate palette-selection startup flow and operation section folded into one unified boot flow Runtime behavior describes a dedicated palette-selection window and NMI path during gameplay describes palette changes during the boot-logo display only Extra staging details expands palette-window character data into VRAM bank 1 and builds palette-panel data emphasizes OAM clear, logo expansion, palette changes during logo display, then VRAM clear except logo tiles Overall feel monitor-style palette utility layered on top of boot logic closer to the familiar retail CGB logo-and-handoff flow The March wording is especially revealing because it still documents a much more monitor-like palette system.It describes a カラーパレット選択ウィンドウ (color palette selection window) overlay appearing on top of the running game, a palette-selection NMI path, and resuming play after the window closes.By June that has been simplified into the now-familiar boot-time behavior: palette changes happen during logo display the player can choose from 12 combinations using the d-pad with A or B the chosen colors are reflected immediately in the logo display after header validation, the monitor clears VRAM except the Nintendo-logo tiles, switches CPU mode, and starts the gameflowchart LR subgraph M[\"<b>March 1998 spec</b><br>980403\"] M1[\"<b>Boot and logo</b><br>initialization and cartridge checks\"] --> M2[\"<b>Palette window path</b><br>separate startup flow\"] M2 --> M3[\"<b>NMI during gameplay</b><br>pause game and open overlay window\"] M3 --> M4[\"<b>Resume play</b><br>close window and continue game\"] end subgraph J[\"<b>June 1998 spec</b><br>980615\"] J1[\"<b>Boot and logo</b><br>initialization and cartridge checks\"] --> J2[\"<b>Logo-time palette choice</b><br>12 d-pad plus A/B combinations\"] J2 --> J3[\"<b>CPU mode change</b><br>set final mode and palette state\"] J3 --> J4[\"<b>Game start</b><br>jump to 0100H\"] endWhat the CGB Side PreservesTaken together, the CGB repository preserves a compact low-level monitor package rather than a broad SDK-like environment.The pieces on disk point to: two closely related monitor source snapshots a small DMG-era assembler and linker flow built .com monitor outputs a definitions file covering memory layout and palette IDs dated formal monitor specification documents from 1998What This Reveals About the Real CGB Boot ProcessAt this point the most useful overall conclusion is that the preserved CGB material is not just a dead boot ROM listing.It is a monitor-oriented implementation of the real color-boot compatibility strategy Nintendo was using in the late Game Boy era.The source, binaries, and specs all point to the same picture: the boot sequence was presentation-heavy, with staged logo display, sound timing, and palette fades the colorization path was data-driven, with a real compatibility database for many DMG titles Nintendo supported both automatic game-specific palette choice and a 12-way manual override the later agb_cgb.dmg branch was a maintenance pass on an already-stable monitor rather than a redesignSo the leak is valuable for more than just preserving one boot binary.It shows how Nintendo structured the logic behind Game Boy Color boot-time palette compatibility at a very low level.Now you might be interested in our post on the Game Boy Advance Boot ROM: Gigaleak - Game Boy Advance Boot ROM Repository For the larger AGB monitor, startup, library, and tooling environment, check out the Game Boy Advance boot ROM page. ", "excerpt": "The Nintendo Gigaleak preserves the CGB boot ROM material in two useful forms. Inside other/agb_bootrom it survives as a compact SVN repository, and separately the leak also includes cgb_bootrom_trunk.zip, an extracted working tree that exposes the actual DMG-format source files directly. Gigaleak - SNES Source Code Leak For the wider...", "tags": ["gameboy","leak","sourcecode"], "image": "/public/generated/placeholders/game-boy-color-boot-rom-repository.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game Boy File Formats (DMG, GBC)", "url": "/game-boy-file-formats", "content": "Game Boy File FormatsThis page covers the main file formats that show up in official Nintendo Game Boy and Game Boy Color development material.After looking through the Zelda DX source leak and the Super Game Boy sample package, we can now describe several of these formats much more confidently. Super Game Boy SDK Sample and BIOS Files For a compact sample project that shows many of these formats in practice, see the Super Game Boy SDK sample preserved in the Nintendo leak. ROM and Debug ImagesThe most visible Game Boy output formats are the built ROM images and the debugger-ready images used inside Nintendo’s Intelligent Systems toolchain. Extension What it usually is What we now know .GB Standard monochrome Game Boy ROM image The raw cartridge ROM image without the extra debugger metadata carried by Nintendo’s internal formats .GBC Standard Game Boy Color ROM image Same idea as .GB, but usually used for color-aware retail dumps and emulator ROMs .ISX Intelligent Systems debugger-ready image Not just a plain ROM. In leaked Nintendo projects it sits beside .map, .prn, and isdwd*.dat files, which suggests it was meant to be loaded by the debugger or ICE environment with symbol/debug context available .COM Generic binary output used by Nintendo build workflows This one is more overloaded than older writeups suggested. In some folders it does look like a built executable or ROM-style output, but in the Super Game Boy sample CHRDAT.COM is an 8 KB graphics/tile payload loaded into bank 2, not the main program image .RAM Emulator or debugger RAM snapshot Seen in some regional Zelda DX outputs such as c_d.ram, suggesting saved runtime memory for testing or debugging rather than source data If you dump your own cartridges you will normally get .GB or .GBC.The more interesting internal format is .ISX, because it belongs to the official Nintendo development flow rather than the retail cartridge image alone.The emulator SameBoy recently added support to play ISX files due to the 2020 Nintendo Leaks:Following the... uh... recent events, I've added ISX file format support to SameBoy, including symbol support pic.twitter.com/Ba28bA2ARu— Lior Halphon (@LIJI32) April 25, 2020Source and Build FilesThe source tree itself uses a mixture of older DMG-era file types and later Color-era ones. Extension What it usually is What we now know .DMG DMG-era assembly source module Plain text assembly source for the original monochrome Game Boy workflow. Files like ZMA.DMG, LIBDMG.DMG, and SGB_MAIN.DMG are source code, not assembled outputs .S Later assembly source module The newer source form used heavily in Color-era projects and later refreshes of older packages. In the SGB sample, the 1998 .s files are extremely close to the 1994 .DMG sources, suggesting a syntax or workflow refresh rather than a full rewrite .O Assembled object file Built output from .DMG or .s source modules before final link .PRN Assembler listing file A very useful debugging and archaeology format. It preserves the assembled listing and helps tie source lines to the built output .BAT DOS build or helper script Used to edit, assemble, link, convert, or launch debugger sessions. Examples include GAL.BAT, cgal.bat, C.BAT, and E.BAT .MAP Linker map file Shows where code and data landed in the linked image .PIF Project or debugger configuration file Seen in regional Zelda DX branches such as C_USA.PIF, likely carrying project or debugger session settings .CVT Conversion script or conversion input Used with Nintendo conversion tools such as FCV .X65 6502-family assembly source More common in other Nintendo projects than Game Boy itself, but it appears in the wider leak ecosystem One of the more useful lessons from the leaked folders is that Nintendo did not keep source, objects, maps, listings, and debugger files neatly separated.Real project folders often mix them together in the same working directory.Graphics, Audio, and Data FilesThe asset side of the Game Boy workflow is just as revealing as the code side.The Zelda DX folders are especially useful here because they preserve active art, layout, and map work rather than just final ROMs.The newer DMG Zelda art folders are helpful too, because they preserve matching CGX, COL, and SCR sets like end-demo-A.*, end-demo-B.*, and wak.* rather than only loose graphics banks. Extension What it usually is What we now know .CHR Character/tile graphics Standard 2bpp tile graphics used by the Game Boy family. Files like C1.CHR through C8.CHR appear repeatedly in both DMG and CGB branches .CGX Graphics resource file Much closer to a raw tile bank than older writeups implied. In both DMG and CGB workspaces these hold title graphics, event graphics, room graphics, and UI assets. DMG-targeted folders such as z-dmg-zelda show that .CGX is not automatically “color graphics”: many of those banks are still plain 2bpp Game Boy tile data, just stored under the CAD-style .CGX extension rather than .CHR .HEX Plain text or assembler-friendly data blob In Nintendo Game Boy projects this is often audio-related rather than generic random data. Zelda DX uses BGM_1.HEX, BGM_2.HEX, BGM_1F.HEX, and SE.HEX for music and sound effect content .BIN Raw binary data blob A generic binary payload. In Zelda DX, folders like New_sound contain binary exports such as bgm_1.bin, bgm_2.bin, and se.bin .CDT Color definition or color-layout data The Zelda DX COLOR and COLOR2 folders make this much firmer than before. Large banks of .CDT files sit beside graphics and map resources, which strongly suggests editor-side color definitions or color-layout tables rather than code .COL Color or palette-related data The DMG Zelda art folders make this much less vague than it used to be. Files such as end-demo-A.COL, end-demo-B.COL, end-demo-C.COL, and wak.COL sit directly beside matching .CGX and .SCR files, which supports the idea that .COL was the color or palette companion to a specific graphics/layout set rather than a random standalone blob .SCR Screen or layout resource Not just a vague “screen file”. In Zelda DX these appear as room and menu layout resources such as ROOM20.SCR, ROOM20c.SCR, name_1.scr, and TEST1.SCR, while the DMG Zelda art folders preserve same-name .SCR companions for files like end-demo-A, end-demo-B, and wak. That makes the broad layering much clearer: .CGX stores the tile graphics, .COL stores the matching color data when needed, and .SCR stores the composed screen or layout side .MDT Map data file Seen concretely in Zelda DX as zel_map1.MDT and zel_map2.MDT, which strongly supports the idea that it is editable map data .PDT Panel or attribute-related data Found beside .PNL files in ATR and ATR2, suggesting layout or attribute resources rather than code .PNL Panel or attribute layout resource The Zelda DX ATR2 folders make this much less mysterious than before. These look like editor-produced panel or attribute files used alongside other layout resources The broad pattern is that Nintendo’s Game Boy projects often kept graphics, color definitions, maps, and layout files as their own editable layers rather than baking everything directly into the source code.The most important refinement now is that the extension alone does not tell you whether a graphics bank is monochrome or color.A .CGX file in a DMG-targeted workspace can still be ordinary 2bpp Game Boy tile data, while the matching .SCR and .COL files tell you how that bank was actually being laid out or colored inside the editor pipeline.IS-CGB-CAD data formatsThe IS-SUPPORT leak material includes an IS-CGB-CAD tool distribution with a small set of internal file formats documented in Japanese as DCG, DSC, DOB, and DCL.These are useful because they spell out the exact bit packing for Game Boy Color tile data, per-tile attributes, and object layout.The formats line up closely with what the hardware expects on CGB.They also clarify why the same project can carry both SNES-like CAD extensions (CGX, COL, SCR) and more directly named Game Boy specific blobs in the same workflow.DCG format - Tile DataDCG is a tile + attribute + color bundle used by the CAD tool. Range Size Meaning 0x0000-0x17FF 0x1800 Character (tile) data 0x1800-0x197F 0x0180 Attributes (palette info in IS-CGB-CAD) 0x1980-0x19FF 0x0080 Color data The character data is classic Game Boy 2bpp tiles: 16 bytes per 8x8 tile, with 2 bytes per row (low bitplane byte then high bitplane byte).This plays the same role as SNES CGX (a raw tile bank), but the packing is different: Game Boy uses 2bpp row pairs, while SNES CGX is planar bitplanes (commonly 4bpp).DSC format - Screen DataDSC is a background screen map in the same split form that the CGB hardware uses: one byte of tile index per cell and one byte of attributes per cell. Range Size Meaning 0x0000-0x03FF 0x0400 Character code (tile index) 0x0400-0x07FF 0x0400 Attribute byte The attribute byte is documented with this bit layout: Bits Meaning 0-2 CGB palette index 3 character bank select 4 unused (but used inside IS-CGB-CAD) 5 horizontal flip 6 vertical flip 7 priority (0: follow OBJ-side priority, 1: BG highest priority) This plays the same role as SNES SCR (a background tilemap), but the storage model differs: SNES packs tile index and attributes into 16-bit words, while CGB splits the tile index and attributes into separate byte arrays.DCL format - Palette dataDCL is a small palette block. It stores 2 bytes per color with 5 bits each for R, G, and B.DOB format - Object DataDOB is a chunked object and animation container with tagged blocks like \"CGB \", \"ANIM\", \"GRP \", \"SIZE\", \"LINK\", \"VER \", and \"END \".Unlike many SNES CAD blobs that are fixed-size record regions, DOB is explicitly variable-length and carries its own version and filename link table.If you are comparing this to the SNES CAD families, DSC is closest to SCR (BG tilemap), while DOB is closer to OBJ/OBX (object placement plus animation-related data).ICE and Debugger Support FilesSome of the strangest extensions in the leak make more sense once you look at the debugger workflow rather than the game code alone. Extension What it usually is What we now know .ICE ICE helper script or opaque debugger-related binary This extension is overloaded. In the SGB sample, START.ICE is a tiny text startup script that tells the debugger what to load. In Zelda DX, files like RZ.ICE, RZ1.ICE, and rchr.ICE look more like binary blobs or packed data tied to the same broader toolchain .DAT Debugger sidecar data Files such as isdwdcmd.dat, isdwdrng.dat, and isdwdsym.dat were generated alongside builds and appear to hold debugger command, range, and symbol information .ISX Debugger image with symbol/debug context Worth repeating here because it sits at the boundary between ROM output and debugger workflow .RAM Runtime memory snapshot Useful for preserving machine state during debugging or test runs The SGB sample is especially useful because it shows how these pieces fit together.C.BAT assembles and links the sample, isd launches the debugger, and START.ICE tells it to load SGB_MAIN plus the CHRDAT.COM graphics bank at the right address.That is also why the Zelda DX folders are full of isdwd*.dat files.They are part of the debugger-facing side of Nintendo’s Intelligent Systems development environment. Zelda Links Awakening DX Source Code (CGB) To see a real-world production workspace, see the Zelda Link’s Awakening DX source archive. Quick Notes on the ToolchainThe file formats only really make sense when viewed as part of the wider Game Boy development flow. Tool Role MIFES Source editor used in older DOS-era workflows ISDMG Older assembler used with .DMG source modules ISLINK Linker used in the older DMG workflow isas32 Later assembler used heavily in Color-era branches islk32 Later linker used with the newer assembler flow isd Debugger front end used with ICE startup scripts and debugger images ", "excerpt": "Game Boy File Formats This page covers the main file formats that show up in official Nintendo Game Boy and Game Boy Color development material. After looking through the Zelda DX source leak and the Super Game Boy sample package, we can now describe several of these formats much more...", "tags": ["gameboy","fileformats"], "image": "/public/images/GameBoy/GameBoy File Formats.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game Boy (DMG/GBC) Reversing Emulator", "url": "/GameBoy-Reversing-Emulator", "content": "Introduction The Game Boy Reversing Emulator (RE) is a fork of the libRetro Same Boy emulator tailored for reverse engineering. The main aim is to generate information that will be useful for the disassembling and exploration of your chosen game. It does this by tracing and logging information about asm instructions, functions, memory addresses, DMAs etc as the user plays the game. Uses LibRetro & LibRetroReversingThe emulator is built on the libRetro core of the SameBoy emulator, the reasons for this include: Users can choose their own frontend (e.g RetroArch) Standard libRetro functions can be shared among multiple reversing emulators.The reversing functionality is contained in a library called LibRetroReversing which itself is based on LibRetro which encompasses common reverse engineering functionality that is shared among multiple Reversing Emulators.This allows for new features and bug fixes to be easily ported across multiple games consoles. For example the Tool-Assisted-Superplay features are available across all libRetroReversing cores.Cross Platform Web-based UIThere is no better cross-platform UI kit than the web itself, it is highly likely you have a web browser on your system and so if your computer can browse Facebook then you can reverse games with our UI!FeaturesThe emulator contains all the functionality of a standard Game Boy Color emulator but adds additional features for helping reverse engineer the game back into compatible source code.Log Input and playback with logging One very important feature of the reversing emulator is the ability to record all the button presses made during a playthrough. This allows you to play the game at full speed but then later playback the same button presses with full logging enabled. This is an effective way to log a games functionality without having to play at unbearable framerates. Edit Input Playback for TASing Since we have the functionality to record all the player input and replay it back on demand, this allows us to add Tool-Assisted-Superplay (TAS) features. We provide a UI to edit the user input on a frame-by-frame basis, including functionality to preview a section of the game in a loop so you can optimize the input as much as possible. Named Save States and Frame Usage logging Once a playthrough has been completed the user has the ability to playback the input states and create named save states for interesting parts of the game. The name of the save state and the frame number it was saved at are used to give the reverser a hint as to where a function or chunk of memory was used. For example if a save state was created and called “Start of Level 2” then any function that first gets called in Level 2 will be labelled as such. ", "excerpt": "Introduction The Game Boy Reversing Emulator (RE) is a fork of the libRetro Same Boy emulator tailored for reverse engineering. The main aim is to generate information that will be useful for the disassembling and exploration of your chosen game. It does this by tracing and logging information about asm...", "tags": ["gameboy","reversingEmulator"], "image": "/public/images/gameboy/Game Boy Reversing Emulator.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game Boy Software Development Kits", "url": "/official-gameboy-software-dev-kit", "content": "Official Game Boy Software Development Kit (by Intelligent Systems)The official Game Boy development kit was developed by Intelligent systems and sold with their development kit hardware such as the DMG-ICE. It evolved over time and added support for the Game Boy Color, eventually becoming the SDK shipped with the IS-CGB-EMULATOR hardware. Gameboy (DMG & GBC) Development Kit Hardware For more information on the development hardware check out this post. Using the SDKIf you are interested in using the SDK to develop homebrew or to help reverse engineer a game that used the Official SDK then this section will guide you through some of the basics.Download the Official Game Boy Color SDKYou can download the Japanese version of the Game Boy Color SDK from emuparadise here: Game Boy Color SDKDocumentationThe official manual for the Software Development Kit was uploaded to archive.org and is available here: Game Boy Development Manual V1.1 : Nintendo : Free Download, Borrow, and Streaming : Internet ArchiveTools in the SDKJust before the Intelligent Systems development FTP server was shut down, someone managed to backup the contents of the Game Boy color sdk and the files that were saved are as follows: IS-CGB-SDK.7z - Software development kit (libraries etc) IS-CGB-EMULATOR.7z - Color Game Boy Emulator IS-CGB-DEBUGGER.7z - Game Boy debugger IS-CGB-CAD.7z - Character/Graphics development tool IS-CGB-CHARACTER.7z - Character/Graphics development tool IS-CGB-CHARACTER Documentation.7z - Documentation for the CAD graphics toolIntelligent Systems Assembler (ISAS)To assemble your GameBoy source code into Z80 machine code you could use the official Nintendo (Intelligent Systems) assembler and linker, ISAS and ISLK respectively.Last Known Version: ISAS 1.26 / ISLK 1.26 (1999/10/26)Intelligent Systems eXecutable - ISX and CVTISXISX is the format that the Assembler (ISAS) compiles the programs into, it is a compressed version of the rom, to convert it into a standard Game Boy rom you need to run it through CVTISX (ConvertISX).Intelligent Systems CAD Tool (IS-CGB-CAD or DMG-CAD)The archive only seems to contains the IS-CGB-CAD tool, which is a CAD (COmputer Aided Design) tool for graphics, sprites and Tiles, which are known as are known as “characters” for the GameBoy. Its known as a Character development system.Based on the IS-CGB-CHARACTER-000703jp.exe installer found in the IS-SUPPORT leak material, the CAD tool payload includes the following notable files: Path in installer What it is Program Executable Files\\\\ISCGBCAD.exe Main Win32 CAD editor executable Program Executable Files\\\\Iscgbcad.com 12 KB companion program (purpose unclear without deeper RE) Shared DLLs\\\\ISCGB.DLL Main shared DLL shipped with the tool Help Files (Japanese)\\\\FORMAT.TXT Japanese format notes (documents DCG, DSC, DOB, DCL) Help Files (Japanese)\\\\help\\\\*.html Japanese HTML help set for the editor UI Example Files\\\\O2T.C Small C example shipped with the installer The FORMAT.TXT file is especially valuable because it gives concrete byte layouts and bitfields: DCG - a combined tile + attributes + color bundle (2bpp tile data plus palette metadata) DSC - a screen map with one byte of tile index plus one byte of attributes per cell (the split map model used by CGB) DOB - a chunked object and animation container with tagged blocks like \"CGB \", \"ANIM\", \"GRP \", \"SIZE\", \"LINK\", \"VER \", and \"END \" DCL - a small packed RGB555 palette block (2 bytes per color)The executable payload also reveals how the editor talks to Nintendo’s emulator / hardware layer. Editor component What it does ISCGBCAD.exe The Windows GUI editor. It loads iscgb.dll at runtime and resolves the CGB* API via GetProcAddress. ISCGB.DLL A shared DLL that exports the CGB* API used by the editor. Iscgbcad.com Despite the .com extension, this is a small CGB ROM image with the title IS-CGB-CAD PIC. The Windows editor looks for it and shows an error if it is missing. The ISCGB.DLL export table includes these named entry points: Export name Likely role CGBOpen Open a connection / session CGBClose Close a connection / session CGBRead Read from the target CGBWrite Write to the target CGBSetMBC Configure MBC state (banking) for transfers CGBGo Start / run (or resume) execution CGBFindFirst / CGBFindNext / CGBFindClose Enumeration helpers used by the editor UI The editor also looks up two unnamed exports by ordinal (8324 and 16345) in addition to the named ones.At the strings-and-API level, ISCGB.DLL looks like it can use low-level SCSI-style device paths (for example \\\\\\\\.\\\\SCSI%d:), and it references WNASPI32.DLL, which suggests an ASPI-based transport path for talking to the emulator hardware.In other words, ISCGB.DLL is not just a random dependency: it is the CAD tool’s device and transfer layer.The Windows GUI editor resolves these CGB* entry points at runtime and uses them to enumerate available targets, set bank state, and move data to and from the emulator/hardware environment.When reverse engineering these binaries you will also see a lot of MFC plumbing.For example, AfxGetModuleState is an internal MFC helper that returns a module state pointer (AFX_MODULE_STATE) used for resource loading and per-module bookkeeping in MFC-based EXEs, DLLs, and ActiveX controls.Other shipped components in the installer are also worth calling out, because they hint at the UI layer and the Windows 9x-era driver stack the tool expected: Component Where it appears Notes VxD driver Shared DLLs\\\\CGBVIEW.VXD Windows 9x-style VxD, likely used by the viewer / emulator transport path SYS companion Shared Sys\\\\Cgbview.sys Small .sys file shipped alongside the VxD OCX UI controls Program DLLs\\\\PathBox.ocx, Program DLLs\\\\SolidPalette.ocx ActiveX controls likely used for path picking and palette preview UI Version notes Help Files (Japanese)\\\\version.txt Shipped version/change notes for the tool Bundled runtime DLLs Shared DLLs\\\\Mfc42.dll, Msvcrt.dll, Oleaut32.dll, Olepro32.dll, msvcirt.dll Redistributed Microsoft runtime components typical of the era Original Game Boy DMG SDK (Contained in Gigaleak archive called Other.7z)In the first Nintendo Gigaleak the source code for the original Zelda Links Awakening for the DMG Game Boy was included which contained what is believed to be the full Software Development Kit used both in-house at Nintendo and a few partners such as Systems Research and Development (SRD).The files included in the Original DMG SDK are described in the table below: File Name Extension Description A .EXE DMG Relocatable Macro Assembler Version 1.00 ASMB .EXE 6502 Assembler Version 1.10 (Famicom tool created in 1987) ASMD .EXE DMG Macro Assembler Version 1.01 ASMDMG .EXE DMG Macro Assembler Version 1.01 (Identical to ASMD.EXE) CGE2DMG .EXE Converts either CGE or DCG Character graphics to source code (.DMG) CGEDCG .BAT Batch file for running FCV with the DCG2BYT script DCG2BYT .CVT FCV Script to convert DCG Character Graphics files to assembly code (.DMG) DCGDMG .BAT Batch file for character file conversion of a .DCG file to a .DMG source file DMGFUNC .TB0 Custom binary format possibly used by ISD debugger tool contains the string “SENGOKU” at the start FCV .EXE File Convert Program Version 1.03 (Reads in .CVT files) FDT .EXE FMS Debugger Version 2.02 (Famicom Tool?) GENBYTE .CVT FCV Script to convert a .COM file to a NES/SNES .X65 source file HDT .EXE MMC/HVC Debugger Version 03.05 (Famicom/NES Debugger) IS65 .EXE 6502,65816 Relocatable Macro Assembler version 1.00 (Why is there a SNES assembler in here?) ISD .EXE I.S. Debugger Version 1.00c ISDMG .EXE DMG Relocatable Macro Assembler Version 1.00 ISLINK .EXE ISASM Linker Version 1.00 L .EXE ISASM Linker Version 1.00 (Presumably just copied to have a shorter name) PW .EXE P-ROM Support Program Version 1.26 PW2 .EXE, .TB0 P-ROM Support Program Version 2.02d6 SCR2DMG .COM MS-DOS Command File Executable for converting .scr files to .DMG files for assembling SHL .COM, .KEY MS-DOS Command File Executable but not sure what it is for SHVC .EXE SHVC Debugger Version 1.00a VRAMTR .CVT VRAM Transfer script that converts a .SCR screen file to either a NES or SNES .X65 file VUP .EXE Version UP Program Version 2.09 Game Boy SDK File FormatsThis SDK seems to use a number of different file formats, but it is not clear what exactly is the purpose of each: .DMG - Assembly source code for the Dot Matrix Game (Game Boy) .CGE - Character Graphics data (For Famicom?) .DCG - Character Graphics data (for DMG Game Boy?) .CVT - Custom Conversion scripts that can be executed with FCV .SCR - Screen file maybe containing location of character tiles in a level? .X65 - Either Famicom or Super Famicom source code .COM - Unsure if this is a Windows Command File or something elseNES/Famicom SDK FilesOne interesting file is that HDT.EXE is included here which is the NES/Famicom Debugger, as far as I know this is the first time a file from the Famicom SDK has ever been leaked. As no other official NES/Famicom SDK had been leaked this is quite remarkable. It was written by Intelligent Systems between 1986-1989 and seems to read in three file formats: CHR (Character/Tile Data), SCR (Screen data? or Source Data?) and CGD (No Idea, maybe Character Graphic Designer?).SNES/Super Famicom SDK FilesAnother interesting file is that IS65.EXE is included here which is the Official Super Nintendo Entertainment System assembler created by Intelligent Systems in 1990. It seems to have been written by the developer Toshio Sengoku.The file VRAMTR.CVT which is a script in a custom programming language that is parsed by the FCV program. The comments at the beginning of the file indicate that it takes an input file with a “.SCR” extension and outputs a file with a “.X65” extension.File Convert ProgramThe File Convert Program (FCV) tool was created in 1987 by Intelligent Systems so it is likely it was also part of the Famicom Software Development Kit.The commands in the script appear to be performing various operations related to transferring data to VRAM. For example, the “VRAD=$2000” command sets the screen address, and the “DTPT=0” command initializes the data pointer. The script also includes commands for writing screen data and attribute data to VRAM.Character Graphics conversionThe Bash script DCGDMG.BAT is used to convert a file with the extension “.DCG” (presumably containing character graphics) from the FM-R50 system (a Japanese computer system from the 80s) to a source code file with the extension “.DMG”.The script assumes that the FM-R50 file is inserted into Drive A of the computer. The script then uses the FCV tool to do the conversion.This potentially means that developers for Nintendo were using the Fujitsu FM-R50 or a compatible system to develop Game Boy games and possibly NES and SNES games too.Third Party SDKsMany third party game developers to create their own set of development libraries and even assemblers, emulators and debuggers to make Game Boy development easier.AZ40 Game Boy Assembler Kit (Gremlin)This is a very old Game Boy assembler kit created around 1991 by Gremlin Graphics Software. Included in the kit the assembler, macros, debugger and Amiga to Game Boy sample converter, Game Boy file clipper, set memory application and a restart application 1.The SDK can be downloaded from Romhacking.net - Utilities - AZ40 GameBoy Assembler Kit.Executables includedThere are a few executables that can be used in DOS for assembling, debugging and a few sound tools. Name Description ATG.EXE “AMIGA TO GAME BOY SAMPLE CONVERTER (by R.H.C.)” AZ40.EXE Game Boy Assembler (Game Boy Esprit Turbo Assembler) DZ40.EXE Game Boy Debugger (Copyright 1991 Gremlin Graphics Software Ltd.) CUTFILE.EXE GAME BOY FILE CLIPPER (by R.H.C.) RESTART.EXE Seems to connect to a Game Boy (to restart it?) Along with the release on RomHacking.net there was another release of Game Boy source code that included it in a zip file called BarryLeitch.zip. It seems to have the source code for the music for the Amiga game called “The Humans” along with Game Boy specific source code and the SDK.Unanswered questionsWho or what was R.H.C?In the Gremlin SDK it mentions that a lot of tools were by R.H.C, but it is unclear who or what this is.It could be the initials of an employee who wrote the software or it could be a company. They seem to have written both ATG.EXE and CUTFILE.EXE.R.H.C was possibly Richard Hutchison as that was a college of Barry and worked on a few titles together, but this is unconfirmed? 2.References Romhacking.net - Utilities - AZ40 GameBoy Assembler Kit ↩ Barry Leitch - Video Game Music Preservation Foundation Wiki ↩ ", "excerpt": "Official Game Boy Software Development Kit (by Intelligent Systems) The official Game Boy development kit was developed by Intelligent systems and sold with their development kit hardware such as the DMG-ICE. It evolved over time and added support for the Game Boy Color, eventually becoming the SDK shipped with the...", "tags": ["gameboy","sdk"], "image": "/public/images/GameBoy/Game Boy SDK.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game Cracking Software used back in the day", "url": "/cracking-software", "content": "Introduction to Retro Game Cracking SoftwareIn the early days of personal computing and video gaming, a subculture emerged that sought to unravel the mysteries hidden within the code of beloved games. This subculture, often operating on the fringes of legality and ethical boundaries, birthed a variety of software tools designed for a singular purpose – game cracking. These tools, wielded by a community of enthusiasts, hackers, and curious minds, played a pivotal role in the evolution of software piracy, digital rights activism, and the broader landscape of digital entertainment.This article delves into the realm of such software, uncovering the notorious and groundbreaking tools that defined an era. From the humble beginnings of the video game revolution to the rise of sophisticated copy protection mechanisms, these software applications were wielded as virtual crowbars, unlocking the secrets embedded within the binary fabric of video game code.As we explore the historical landscape, we will encounter iconic names such as SoftICE, W32Dasm, and OllyDbg, each leaving an indelible mark on the annals of software history. This article aims to provide a nuanced and informative perspective on the motivations, methods, and consequences associated with the use of game cracking software, while acknowledging the cultural impact and the ongoing debates surrounding software ethics.Join us on a journey through the digital past, where lines between curiosity, piracy, and digital freedom blurred, and the tools highlighted here played a role in shaping the discourse on intellectual property, fair use, and the rights of gamers and developers alike.SoftICESoftICE was a powerful kernel-mode debugger for DOS and Windows up to Windows XP. It was designed to run underneath Windows, so that the operating system was unaware of its presence and could be debugged thoroughly. Unlike an application debugger, SoftICE was capable of suspending all operations in Windows when instructed. This made it an invaluable tool for low-level debugging, reverse engineering, and software cracking.SoftICE was developed by NuMega and was first released in 1987 for DOS and in the 1990s a Windows version was released called SoftICE/W1. It quickly became a popular tool among software developers and security researchers. In 1997, NuMega was acquired by Compuware, which continued to develop and support SoftICE. In 2009, Compuware sold the property to Micro Focus, which currently owns the source code and patents, but is not actively maintaining SoftICE.SoftICE was a commercial product, but there was a freeware version available with limited functionality. It is no longer actively maintained, but it remains a valuable tool for those who need to debug low-level code.# W32Dasm W32Dasm was created by URsoftware in the late 1990s, it is unknown when the first version was released but we know that the second version was released in 1996 2. The software was initially released as shareware, but it later became freeware. W32Dasm 8 was the last known version.W32Dasm was used for cracking early PC games. It was a valuable tool for reverse engineers who wanted to understand how the games worked and to find ways to bypass their copy protection. It was a particularly powerful tool because it was specifically designed for disassembling 32-bit Windows executables.OllyDbgOllyDbg was a 32-bit debugger for Microsoft Windows that was designed for analyzing and reverse engineering binary code. It was initially developed by Oleh Yuschuk and first released in 2002 3. OllyDbg quickly gained popularity among security professionals and enthusiasts due to its user-friendly interface, extensive feature set, and active community support.Sources SoftICE - Wikipedia ↩ W32Dasm Demo V2.0 ↩ OllyDbg v1.10 ↩ ", "excerpt": "Introduction to Retro Game Cracking Software In the early days of personal computing and video gaming, a subculture emerged that sought to unravel the mysteries hidden within the code of beloved games. This subculture, often operating on the fringes of legality and ethical boundaries, birthed a variety of software tools...", "tags": ["software","industry"], "image": "/public/generated/placeholders/cracking-software.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Introduction to Game Engines & Middleware", "url": "/games/engines", "content": "Introduction to Game Engines & MiddlewareGame Engines are the foundation in which games are built, they contain all the logic to be able to show graphics, play audio, compute input, etc. without having any of the game specific assets such as sprites or music files.Middleware on the other hand has one specific goal in mind, for example an audio middleware just plays sounds and you would not be able to display graphics with it.So you can think of game engines as the combination of middleware.Who develops game engines?There are two types of game engines based on who developed them or rather who has access to them: In-house game engines - Only available to one game development studio. Retail game engine - Engines that are normally sold as a product and used by multiple game development studios.How much did game engines cost?This really depends on the engine, it could have been anywhere between a licensing fee per game sold or a one time fee of thousands of dollars for console games.This was due to the limited audience of game engines at the time, you would have to pay an entire development team to work on a game engine (not cheap) and you would only be able to sell to about a dozen companies.However with the Indie game revolution a number of free or cheap game engines became available but tended still to charge much more for console development.Commercial Game EnginesInstinct StudioInstinct Studio was a rather obscure a software suite by the Ireland based company Instinct Technology. It claimed to combine a complete set of game development tools with an array of ‘best in class’ middleware plug-ins, giving game developers the power and flexibility to create state-of-the-art productions within realistic budgets.As far as we know it wasn’t used in any commercial games but it a custom version of the engine was created specifically for the University of Abertay in Scotland. Also they had a playable demo of a game called Dreadnought on their website in 2007.The website was “http://www.instinct-tech.com/”, it was created in 2006 and lasted until 2009.The website had a screenshot of what the editor interface was like, it is very mid-2000s Microsoft:It was also featured in EDGE magazine issue 169 in their CodeShop Section:UnityUnless you have been living under a rock you will have heard about Unity3D, it was originally released the 8th of June 2005 as a MacOSX only engine. However, over its lifetime it has grown to support not just PC but also many games consoles (Wii, Xbox 360, PS3) and mobile platforms (iOS, Android). It was developed by the Danish vendor OTEE.Key milestones include: Unity 1.0 first version that even included a full version of the physics engine Ageia PhysX (8th June 2005). Unity 1.1 introduced Windows deployment support on August 23rd 2005, but there was no support for editing on Windows yet. Unity 1.5 introduced the cross platform web-player via the The Unity Web Player browser plugin (June 16th 2006). Unity 2.0 introduced new features like the Terrain Rendering Engine, DirectX 9 Renderer for Windows, Built-in Networked Multiplayer Support, Web Player Streaming and Improved Web Player Compression. Along with a new companion product, the Unity Asset Server! Unity 2.5 introduced Windows support for the Unity development environment so games can be created on both Windows and Mac OS X. Unity iPhone was introduced on October 22, 2008.The first ever Unity developer conference Unite was held in the two days between October 10-12th 2007.Game MakerGame Maker is a popular 2D game development tool originally called Animo and developed by Professor Mark Overmars.Version 1.0 was built some time in 1998-1999 and never released publicly but on the 15th November 1999 Game Maker was officially released to the public with version 1.1.We have so much content on Game Maker that we had to split this section out into its own post you can find it below: Game Maker - History and Technology behind the engine For more information about the Game Maker check out this post. Game Engines by PlatformAlthough game engines can be used across multiple games consoles or platforms, we have separated the game engines by platform to make it easier to compare the features between engines of a given console generation. Platform Name Game Engine List Microsoft Xbox Original Xbox Game Engines Nintendo Wii U Wii U eShop Game Engines Unity Game Engine Games on Wii U eShop Wii U Nintendo Web Framework Commercial MiddlewareAgeia PhysX SDKOriginally known as NovodeX (by Swiss company of the same name) the technology was bought by Ageia in 2004 and rebranded to PhysX. Later in 2008, Nvidia bought Ageia and continued to support the SDK even releasing it as open source in December 2018.Although the source code was technically available for free before that as long as you registered on the Nvidia website (2015-2017).PhysX under Ageia allowed the SDK binaries to be offered royalty free but access to the source code is $50,000 per application.Unity announced that they would be including the full version of Ageia PhysX on March 4th 2005 which was before version 1.0 was released, which means many Unity games are using the SDK.Menus Master (by omegame)Menus Master was a middleware specifically for creating game menu interfaces it was first released April 15th 2005 1. It has an interface to create the menus along with a C++ SDK that is compatible with the PS2, Xbox, GameCube, and PC.It was used by Delphine Software in the Moto Racer series to great success!References FMOD Sound Middleware The FMOD audio engine is a very common middleware used in modern games, starting with the PS1 generation of consoles. It was developed by Firelight Technologies and the first release... ... Read More middleware gameengines Game Maker - History and Technology behind the engine Game Maker is a popular 2D game development tool originally called Animo and developed by Professor Mark Overmars. Version 1.0 was built some time in 1998-1999 but never released publicly... ... Read More gameengines middleware Krome Studios Merkury Engine The Merkury engine is a proprietary game engine developed by Krome Studios since at least 2001, known to run on PS2, PSP, Wii and with version 3 of the engine... ... Read More middleware gameengines Zeno and Zed - LucasArts & ILM's Unified Production Pipeline Introduction to Zeno and the Zed Game Editor Back in 2004/2005 engineers at LucasArts were on a mission to find the best technology for the new “next-generation” consoles (Xbox 360,... ... Read More middleware gameengines Nintendo Switch Game Engines When reverse engineering games, one of the first things to find out is which engine the game is based on, this will save a considerable amount of time if it... ... Read More switch gameengines middleware UDK Ultimate The Unreal Development Kit (UDK) was a free game engine based on Unreal Engine 3. It has now been deprecated and replaced by Unreal Engine 4, however there is one... ... Read More middleware gameengines Unity3d - History and Technology behind the engine Unity 1.x Historical Overview (2005-2006) Unity 1.x represents the earliest iterations of the Unity game engine, laying the foundation for its editor-centric workflow and multi-platform capabilities. Each minor release in... ... Read More gameengines middleware unity3d WiiU eShop Game Engines 3rd Party Game Engines Most games nowadays are developed using a 3rd party game engine instead of building their own in-house game engine from scratch due to time and budget... ... Read More wiiu gameengines Wii U Nintendo Web Framework Introduction Nintendo introduced the Nintendo Web Framework or NWF in the 2013 Game Developers Conference. You can view the announcement on the GDC Vault: GDC Vault - Nintendo Wii U... ... Read More wiiu middleware gameengines Unity Game Engine Games on wiiU eShop Introduction to Unity on the Wii U Unity3d was the only 3rd party game engine to be officially endorsed by Nintendo 1. This helped make it by far the most... ... Read More wiiu gameengines unity3d Original Xbox Game Engines Introduction When the Xbox came out in 2001 most game developers were still getting used to the new layer of abstractions and code re-use provided by the superior hardware of... ... Read More xbox gameengines middleware Omegame unveils Menus Master, the game user interface authoring solution that free your creativity and save your money! - GamesIndustry.biz ↩ ", "excerpt": "Introduction to Game Engines & Middleware Game Engines are the foundation in which games are built, they contain all the logic to be able to show graphics, play audio, compute input, etc. without having any of the game specific assets such as sprites or music files. Middleware on the other...", "tags": ["gameengines","middleware","introduction","sdk"], "image": "/public/generated/placeholders/games-engines.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Sega Game Gear Reverse Engineering", "url": "/gamegear", "content": "IntroductionWelcome to our page dedicated to Game Gear reverse engineering! The Game Gear was a handheld gaming console that was released by SEGA in 1990, and was notable for its full-color backlit screen and library of classic SEGA games. If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to the right place.On this page, we’ve compiled a list of links to other pages that cover various topics related to Game Gear reverse engineering.How were sound and music created for the GameGear?In an interview with Paul Hutchinson he states that he used an Amiga 2000HD with the software Pro-Tracker. He wrote a DOS program in Turbo-C++ to convert the Pro-Tracker MIDI export format directly to a format that the Game Gear sound routines could easily use 1.This method was used for Chakan then later for X-Men he wrote a program to convert MOD to MIDI which then would be passed through the previously created MIDI to GG converter 1.What Software was used to create Game gear games?We know that Paul Hutchinson used the following software when developing Game Gear games such as X-Men 1 & 2 (and likely also Chakan and Spiderman vs the kingpin): Avocet Z80 Assembler - Z80 Assembly programming Turbo C++ - writing utilities such as converters for file formats Deluxe Paint - Artwork Pro-Tracker - Sound & Music TUME (The Ultimate Map Editor) - Map creation, created by Dan ChangWhat assemblers were used for Game Gear Z80 code?We know of two confirmed assemblers that were used for Game Gear programming: Avocet Z80 Assembler - Used on games such as X-Men 1 & 2, Chakan and Spiderman vs the Kingpin Microtech Research ASM80 - Used for the Barbie Game Gear gameHow was the final ROM built?Normally it was up to the main programmer to put everything together, all the images, sounds, music and other assets into the final game ROM that would be sent to Sega.Developers such as Paul Hutchinson wrote programs with Turbo C++ to convert the asset data into assembler files (Define Byte (.DB), Define Word (.DW) etc statements) 2. Then an assembler is used to put everything together into a single file that can then be burned onto an EPROM using hardware such as Needham’s Electronics EPROM programmer.The EPROM was then inserted on to a development cartridge and tested on the retail system before finally sending to Sega via their Bullitin Board System (BBS) 2.HardwareIf you’re interested in reverse engineering software for the Sega Game Gear handheld console, it’s crucial to have a solid understanding of the hardware that powers it. By comprehending the inner workings of the Game Gear hardware, you can better understand how the software interacts with the hardware and how you can potentially modify or enhance it.This section of our guide will provide you with comprehensive information and resources on the hardware of the Sega Game Gear, including retail, prototype, and development hardware.Official Development HardwareWe have a specific post all about the known Game Gear development hardware such as the development board and the ZAX-ICE ERX308 that was used: Sega Game Gear Development Hardware For information about SEGA’s Game Gear development hardware check out this post. Sega Digitizer SystemThe Sega Digitizer System was a development kit specifically for creating sprites and background tiles officially inside SEGA. It is unclear if they ever sold the system to third party developers.You can see Pitfall II from 1985 in the photo above. It had a rudimentary touch screen with a pen allowing artists to “draw” pixels directly on the screen.This was not exclusive to Game Gear development, it was also used in early sega arcade games, system 1 and system 16 (1986) and all the way up to Mega Drive (it had 3 different versions).You can find out more including lots of images on Video Games Densetsu: The Sega Digitizer System, a tool used by graphic…Third Party Development HardwareThere is one known third party development kit called Krisalis which we have a separate post about: Krisalis Development Kit (Sega Master System/Game Gear) For information about the Krisalis 3rd party development hardware check out this post. Software Development KitUp until recently it was not known if SEGA ever released a software development kit for the Game Gear, as previous consoles such as the SEGA Master System only had a documentation manual of the hardware but no actual official SDK.So it was up to developers to “roll their own” software development kits for the Game Gear.However thanks to the source code leak of the unreleased Game Gear game Barbie Super Model on both Romhacking.net: Romhacking.net - Documents - Barbie Super Model Source Code and SMS Power: Barbie Super Model - Development - SMS Power!. We now have at least some of the files that were sent out to Game Gear developers as an official SDK from SEGA. It is not clear who leaked the source code for the game, potentially an old Hi-Tech Expressions employee.ASM80In the Barbie source code there is a folder called ASM80 this is the assembler toolchain which is made by Microtech Research from 1991-1994, it is likely this is the recommended official SEGA Game Gear SDK, the main executables are listed in the table below: Name Description ASM80.exe Assembler for z80 by Microtech Bin2Hex.exe BIN2HEX Rev 1.00, copyright (c) 1989 by Lex Computer Services Lib80.exe Executable librarian program (manages static libraries) - Copyright (c) 1985-1991 Microtec Research, Inc. Lnk180.exe Linker by Microtec for Zilog Z180 (Version 6.0 from 1994) LnkZ80.exe Linker by Microtec for standard Zilog Z80 MIDI2GG.exe Convert MIDI Music files to Game Gear format PP.exe PROPACK Copyright (c) 1991,92 Rob Northen Computing - used for file compression PPV.exe Maybe ProPack Verify? The assembler toolchain is made by Microtech Research from 1991 and supported the standard Z80 and also the Hitachi 64180 processor (which is a Zilog Z180 processor). The Game Gear used the standard Z80 so the Z180 functionality was unused.This folder also contains pre-compiled executables known as the GGUtils which were written by Paul Hutchinson with the source code available, they are in the table below: Name Description Bin2Page.exe Creates Intel Hex .HEX 16k pages from a binary file BinToHex.exe Creates an Intel Hex .HEX file from a binary file DB.exe Creates a DB statement .ASM file from a binary file DW.exe Creates a DW statement .ASM file from a binary file HexToBin.exe Creates a binary file from an Intel Hex .HEX file JoinBin.exe Creates one binary file from two binary files The source code is also available under /SEGA/GGUTILS in the Barbie source code leak./ZAXBIN - ZAX Z80 ICE ExecutablesBinary executables for communicating with the ZAX Z80 In-Circuit-Emulator (ICE), specifically the ERX308 for Z80 Version 2.21 from February 19, 1993. Name Description CVTZ80.exe Converts Microtec ASMZ80 symbol/absolute file (.ABS) to the emulator standard symbol/absolute file. ERXZ80.exe ZAX ERX Symbolic Debug Package - Sends commands to the ZAX ICE - Copyright (c) Zax Corporation 1990 - 1993 HLLDZ80.CMD High Level Language Debugger - useful for C programming, not likely used in much Game Gear Development /GG - Game Gear Character EditorIn order to help developers manage sprites and tiles for Game Gear games SEGA developed the Game Gear Character Editor, which is similar to tools available for Nintendo Game Boy development (CAD). The version leaked is 2.04\tfrom October 30, 1991. Note that the Character Editor also contains the Game Gear Animation Editor useful for creating animating sprites in the .ANM format. Name Description GG.EXE The main program, you need to pass the parallel port number of the connected Game Gear as an argument. GGO.EXE Basically the same as GGO.EXE but seems to have been modified slightly not sure if this is an official change or not. INSERT.CMD CUSTOM command whose purpose is to EASE the process of downloading sprites overtop of the background. Custom.inc X86 Assembly file that can be assembled with MASM or TASM for communicating with GG.EXE in custom tools. - Copyright Sega Of America 1991 /SEGA - Sega provided executablesSega provided a few applications to make working with tiled graphics and other formats easier, they are in the table below: Name Description Tile.exe Background tiling utility version 1.1 (c) 1992 Sega of America TilePic.exe Image cutting & tiling utility v1.3 (07APR93) - (c) 1993 Sega of America Iff2Bin AIFF to raw binary converter IFF2BIN v1.2 (26MAR93) - (C) 1992 Sega of America, Inc File FormatsThe table below lists the relevant entries. Name Description .CMD Emulator Command file used with ERXZ80.exe .MAC Macro File used with ERXZ80.exe .ABS Object file (compile output of a source file) .PAL Palette files used for graphics .GG Game Gear file - saved and loaded by the GG.EXE Character Editor .CFG Binary file containing ? .LBM Deluxe Paint Bitmap .ANM Animated sprites .SRC Assembly source code Key of interesting terms that you will find in the SDK (and barbie source code) is available in the table below: Name Description MCH Short for Matthew C. Harmon a developer at Tahoe Software Productions Tahoe Software Productions Development company working on Barbie for the Game Gear Hi-Tech Expressions Development company working on Barbie for the Game Gear Bill Oliver Developer at Tahoe Software Productions Joe Moses Programmer at Tahoe Software Productions Joel Gressel Developer at Tahoe Software Productions (Art?) Paul Hutchinson Sega of America, sound subroutines developer Joergen Bech Sega of America, sound subroutines developer Rational Systems Developed the DOS/16M Extender used in the DOS SDK executables (not related to Game Gear development) erxz80 A program that takes in erx files but not sure what it does CTG Possible someones name? Or a company Has written files for the GG Character Editor All Posts Sega Game Gear Development Hardware Official Sega Development Hardware The SEGA Game Gear was released in a time where official development kits were fairly rare and many third parties instead made their own using their... ... Read More gamegear sega devkit Handheld Consoles Reverse Engineering Awesome list of Obscure Handheld Game Development and Reverse Engineering information ... Read More gba gameboy gamecom gamegear handhelds Krisalis Development Kit (Sega Master System/Game Gear) Krisalis Development Kit In the early to mid 1990s Krisalis Software Ltd created their own in-house sega Game Gear and Master System Development Kit. Shaun Hollingworth and Matt Furniss are... ... Read More devkit hardware gamegear mastersystem sega References GST♥: Part 2: A Discovery with Paul Hutchinson ↩ ↩2 GST♥: Part 1: A Chat with Paul Hutchinson ↩ ↩2 ", "excerpt": "Introduction Welcome to our page dedicated to Game Gear reverse engineering! The Game Gear was a handheld gaming console that was released by SEGA in 1990, and was notable for its full-color backlit screen and library of classic SEGA games. If you’re interested in learning more about the technical aspects...", "tags": ["gamegear","sega","handhelds"], "image": "/public/generated/placeholders/gamegear.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Sega Game Gear Development Hardware", "url": "/sega-game-gear-devkit", "content": "Official Sega Development HardwareThe SEGA Game Gear was released in a time where official development kits were fairly rare and many third parties instead made their own using their existing Z80 knowledge and hardware. However a few official development kits have been found!Sega Game Gear Development Board The Game Gear development board was most likely distributed to SEGA first party developers, and some select third party developers such as Paul Hutchinson 1. It is incredibly rare and this is the only one that we know that exists. The image on the left is from the excellent Andrew Earley (@AndrewEarley7). Find of the week! Sega Game Gear Development Board!! There's a lot of mystery with this board because there's little to no info if it online and the cartridge port is for Master System carts. I'll be mailing this to @GerryRobotics to replace capacitors and get the unit working! pic.twitter.com/SsV8OXdCs6— Andrew (@AndrewEarley7) May 28, 2020In a Game SoundTracks interview with Paul Hutchinson, he references a Game Gear Development board which I believe is the same as the image above 1: The Game Gear had a special development board, into which the ZAX-ICE plugged, it looked nothing like an actual Game Gear.He got it directly from Sega of America after leaving Innerprise while working on the Sega Master System version of Spider-Man vs. The Kingpin 1.Sega Game Gear with built-in Parallel PortAlthough no photo of this kit exists it is mentioned in the source code to the Game Gear Game Barbie Super Model. In the INSTRUCT.DOC file describing the Game Gear Character editor it states: At the DOS PROMPT, type “GG nt”, where ‘n’ is the number\tof the parallel port connected to the download cable of \t\tyour GameGear. (e.g. “GG 2” specifies parallel port 2\t\tas the download port.) And ‘t’ is 0 if you are using\t\ta link cable and GameGear with a ROM card, or 1 if\t\tyou are using the development GameGear with built in\t\tparallel port.This also mentions another Game Gear development method which is a ROM cartridge and sending data with “a link cable”.Note that it is possible the development Game Gear they are talking about is just the Sega Game Gear Development Board but it is hard to tell.ZAX ICE Z80 Although the original eBay link was never archived, there was a ZAX-ICE on sale that was used for Game Gear development 2. Sega also distributed these for Sega Mega Drive development due to the sound chip being a Z80 processor. In fact in an interview with Paul Hutchinson he states that Sega of America sent him two ZAX- ICE units worth $50,000 each, one for the Game Gear and another for Sega Master System 1.Wide Gear Similar to the Nintendo Wide Boy, this was custom Game Gear hardware that could output to a standard television. This was distributed to magazines and other media producers so that they could get good screenshot from the hardware. This would also have been used to create screenshots for Box Art and Manuals provided with the game. It may also have been used by developers and QA to make it easier to test the game on original hardware. The hardware was featured in the American magazine Electronic Gaming Monthly (EGM) issue 27 3. Sega Game Gear 1 MB EPROM cartridge Developers would burn EPROM chips and attach them to the space in the flash cartridge. This would allow them to test their games on retail hardware. Apparently this cartridge could support either 1 MB or 256 KB games 4. The image to the left is from the excellent HandHeldMuseum.com website 4. Some pretty sweet Sega GameGear development EEPROM carts shown in this article...Nice! 😎👌 https://t.co/mWmhQWM098 pic.twitter.com/Nw2vKvvHP6— BehindTheCode (@GerryRobotics) May 1, 2020Third Party Development HardwareAs official SEGA development kits were pretty expensive for the average game development studio, many third parties created their own custom Game Gear development kits.Krisalis Development KitWe have an entire page covering the Krisalis Development Kit which was used for both Game Gear development along with Sega Master System development. Krisalis Development Kit (Sega Master System/Game Gear) For more information on the Krisalis Development Kit check out this post. Realtime / Riverrun development board for Game Gear There is very little information on the internet about this development board or even who “Realtime” or “riverrun” were. If you have any more information please let us know! There was a post about this board on SMS power and user TmEE believes it is a variant of the Romulator 5. You can find more information about the Romulator in the SNES development section but this is unconfirmed and looks pretty different to the SNES Romulator. References GST♥: Part 1: A Chat with Paul Hutchinson ↩ ↩2 ↩3 ↩4 View topic - Gamegear dev kit - Forums - SMS Power! ↩ Page 32 of Electronic Gaming Monthly (EGM) issue 27 ↩ Sega Game Gear 1 MB EPROM Cartridge ↩ ↩2 View topic - Realtime / Riverrun development board for Game Gear & Super Ni**do - Forums - SMS Power! ↩ ", "excerpt": "Official Sega Development Hardware The SEGA Game Gear was released in a time where official development kits were fairly rare and many third parties instead made their own using their existing Z80 knowledge and hardware. However a few official development kits have been found! Sega Game Gear Development Board The...", "tags": ["gamegear","sega","devkit"], "image": "/public/images/gamegear/Sega GameGear Devkit Hardware.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game Maker - History and Technology behind the engine", "url": "/game-maker", "content": "Game Maker is a popular 2D game development tool originally called Animo and developed by Professor Mark Overmars.Version 1.0 was built some time in 1998-1999 but never released publicly but on the 15th November 1999 Game Maker was officially released to the public with version 1.1. Game Maker is still alive today in the form of the newly rebranded GameMaker Studio series.This post will cover the history and technology of the pre-studio versions of Game Maker with a focus on more low level details such as decompiling and how the technology worked.Technology behind Game MakerThe technology behind Game Maker is really interested from a reverse engineering point of view, specifically how games were “compiled” into executables and how the game runner technology worked.You can think of Game Maker as being made up of two main parts: Game Maker IDE - This is where the games are made, with editors for sprites, sounds, objects, rooms and for programming scripts using the Game Maker language (GML) Game Maker Runner - This is the engine that takes the data exported by the IDE and allows it to be playable as a standard windows executable (and later on PSP, MacOS and others)Original Source CodeOnly a few details are known about the source code behind Game Maker, but over the years Mark Overmars has hinted at a few things.Both the IDE and runner were written in Delphi, initially Version 5 1 but that changed to Version 7 in 2004 2 2003 - Delphi version 5. The IDE was slightly over 25,000 lines of code in 2003 with the runner part similar in size 1. 2004 - Delphi version 7. The IDE source code is now over 40,000 lines of code. The source code for the runner part is similar in size 2It was later rewritten by YoYoGames with the runner now being written in C++ and the IDE in C#.Game RunnerEarly versions of game maker (1.1->3.3) exported games in .gmr format that required the Game Maker Runner to execute, later versions (4.0+) allowed exporting directly as .exe files (the exe files technically just appended the gmr file data to the end of the actual runner executable).Game Maker Executable Decompilers (.exe into gmd/gm6/gmk)Ever since Game Maker first allowed exporting of games into executables (.exe) files, people have searched for a way to convert the game back to an editable format!Up until the newer rebrand of Game Maker into GameMaker Studio it has always stored the full editable game data, including comments and unused resources, as encrypted data inside the executables.Thus when a decompiler is made available, everyone has access to be able to read the code and create game mods for any game made in the compatible versions of game maker.There were a few decompilers released for specific versions of Game Maker created executables (*.exe): Game Maker 4.0 -> 4.3 Decompiler - Python 3 version of gm4dec.py Game Maker 4.3 -> 5.3a Decompiler - VBGAMER45/GMD-Recovery: A gamemaker decompiler for versions 5.3a and less Game Maker 5.3a -> 7.0 Decompiler - GM Decompiler v2.1 (For GM5.3A-7.0 Games) Game Maker 8.0 -> 8.1 Decompiler - WastedMeerkat/gm81decompiler: GameMaker 8.1 DecompilerWhen each of these decompilers were released to the public they created quite a stir in the community, e.g: First person caught using Game Maker Decompiler? - GameMakerBlogThere is currently no decompiler for versions 4.0 -> 4.2, although games made in these versions are incredibly rare as it was a short period between summer 2001 and end of the same year. Many games who may have started development in these versions would have upgraded to 4.3+.For GameMaker Studio decompilation there are a number of tools such as UndertaleModTool which will be covered in another post.GMD-Recovery - Game Maker 4.3 -> 5.3a DecompilerThe first Game Maker Decompiler was created by VBGamer45 in Visual Basic 6.0. It worked by allowing you to select a Game maker executable, it would then run the executable and you were prompted to choose the process that was run. It would then dump the memory of that process and try to brute force the decryption key from it.After Game Maker 5.3a it was not updated to support the changes in that version so can only be used to decompile games made between 4.3 and 5.3a. But later on a new decompiler would be released which supported from 5.3a all the way up to 7.0.The source code for GMD-Recovery is available on Github: VBGAMER45/GMD-Recovery: A gamemaker decompiler for versions 5.3a and lessGMDecompiler - Game Maker 5.3a -> 7.0 DecompilerGMDecompiler (gmdecompiler_v2_1.jar) was a closed source Game Maker decompiler written in Java that supported Game Maker games made between versions 5.3a and 7.0. It is unknown who created the decompiler, only that it was leaked at some point during the Game Maker 7.0 timeframe (2007-2008).Executable ConvertersNew versions of Windows have occasionally broken Game Maker executables, these converters are used to upgrade old Game Maker executable files to run on newer versions of windows: GM6Vista: Patches for GameMaker 6 to run on Modern versions of Microsoft Windows (Vista to 11) GM Convert Game by Mark Overmars - Official tool by Mark Overmars to fix games on Windows VistaG-Java - Java Game Maker RunnerG-Java was an attempt to create a Game Maker Runner in Java to provide cross platform game development and embedded games inside Java Applets. It was never finished and ended up becoming Abandonware.G-Java was created some time before October 2004 according to the old G-java.uni.cc Website, it later changed to G-Java.com in November 2006. There seems to have also been a G-Java.tk but it was never archived on the Wayback machine.It was originally written in Visual Basic 6 on top of a GMD parser implemented by VBGamer45 (best known for creating the first Game Maker Decompiler), but the source code for that was apparently lost.GMbed - Embedded Game Maker ExecutablesGMbed was software which embedded Game maker executables in websites using windows specific features to embed a window handle (hwnd) into a Java Applet.Originally it would split apart the Runner part of the executable from the game data part, but this was quickly put a stop to at a request from Mark Overmars 3.A website was created to make the process as easy as possible GMbed.com which was later hacked by an Indonesian hacking group.File FormatsOver the years there have been multiple different file formats used by Game Maker, as the tool was enhanced it required expansions of the format, here are editable formats used in each version: .GMF - Game Maker File (1.1->3.x) .GMD - Game Maker Design (4.x->5.x) .GM6 - Game Maker 6 editable (6.x) .GMK - Encrypted Game Maker file (7.x->8.x) - Encrypted to prevent tools such as G-Java and LateralGM.For the runner formats, it started with .GMR and then moved to a proper executable (.exe) file in Game Maker 4.0+.Other formats created for Game Maker include: .GEX - Game Maker Extension format .LIB - Game Maker Drag and Drop Library formatFile Format ParsingIf you are interested in parsing some of the older Game maker files formats, there are a few Github projects that may be of interest: node-gmk-parser: Node.js based Game Maker file parser Javascript .GMK parser Gmk: C++ GMK Api C++ .GMK parser LibMaker/org/lateralgm/libmaker/file/LibReader.java - Java .LIB parserFile Format ConvertersWhenever a new version of Game Maker was released there would always be people wanting to continue using a previous version, this was especially the case when Game Maker started charging for more advanced features which were free in the previous version (GM 6.x, GM 7.x), so a few converters were created by the community: GM6 to GMD converter - 1.0 Released 26th July 2005 with the final version 2.1 being released 29th December 2005.Companion SoftwareMark Overmars also released some companion software to Game Maker: Background Maker 1.0 - Tool for combining tiles into a single background image (7th December 2000) Image Maker 1.0 - Tool for creating animated GIFs for Game MakerMark Overmars also released some software unrelated to Game Maker: Child Proof 1.0 - Sandbox environment for children using PCs Drawing for Children - Drawing programCommunity additions to Game MakerOver the years there have been many open source projects that aimed to enhance Game maker in a certain way, from cross platform IDEs such as LateralGM, software to convert games to Java (G-Java) and even multiple open source re-implementations of the Game Maker Runner (ENIGMA).Many of these projects are available on Github via the GameMaker Engineering Archive - GitHubGame Maker Version History (Versions 1.1 through 8.0)Game Maker versions 1.1 through 8.0 trace the evolution of a simple 2D game design program into a robust game development engine. Over the course of a decade (1999–2009), features like a full scripting language (GML), DirectX-powered graphics (2D and basic 3D), networking, file I/O, extensibility, and improved editors were introduced step by step.The software’s version numbering skipped a non-public 1.0 (due to its origins as “Animo”), and each subsequent release brought meaningful enhancements – from the foundational changes in 4.0 to the quality-of-life improvements in 8.0.Version 1.0 (Unreleased “Animo”)Mark Overmars originally developed Game Maker as a program called Animo in 1999, intended for creating 2D animations. This version 1.0 was never publicly released – the software was renamed and first launched publicly as Game Maker 1.1 later that year 1. In other words, there is no public Game Maker 1.0; Overmars skipped directly to 1.1 for the debut, reflecting the shift in focus from a simple animation tool to a game creation software 1.Version 1.1 (November 15th 1999) – First Public ReleaseInformation on the main IDE executable (Game Maker.exe): File size - 658.5KB Compiler - Borland Delphi 3 Enterprise Linker - Turbo Linker 2.25Released on November 15th, 1999, Game Maker 1.1 was the first version available to the public 4. Despite being primitive by later standards, it laid the groundwork for Game Maker’s drag-and-drop game creation approach and included a built-in scripting language (later known as GML) for added flexibility 1. Notable characteristics of version 1.1 include:Basic Game Creation InterfaceProvided an event-driven framework with objects and actions that could be added via an easy GUI. All the initial drag-and-drop action icons fit onto a single panel in the Object Editor window 5. This made it simple for beginners, though the range of actions was limited compared to later versions.Introductory Scripting (GML)Even at 1.1, users could edit underlying code. The built-in scripting language was rudimentary (not as complex as in later releases) but allowed manual code editing for more complex game logic 1.No DirectX or Stand-alone ExportVersion 1.1 did not use DirectX for graphics – rendering was done with basic Windows APIs. It also lacked any separate runtime or compiler for games. This meant you could not create a stand-alone EXE for your game in 1.1; games had to be run from within the Game Maker environment itself (in the editor’s main window) 6.Included example games and demoaGame Maker 1.3 provided a few games and non-interactive demos to both showcase the functionality and to teach how to use the software, there are: DEMO Creating Stars - An example of an object that can create other objects (stars) every 15 game frames, using an alarm. GAME Falling Balls - An example of how gravity can be used in Game Maker by increase the vertical speed in every step by a small amount. When the ball hits the bottom wall, we set the vertical speed to -vspeed*0.9. As a result the direction changes (the speed becomes negative) and becomes slightly less such that the motion become slower with each bounce. GAME Breakout GAME Catch the Dog GAME Pacman GAME Peg Game GAME Sokoban - Sokoban is an old Japanse games. The goal is to move the objects (the balls) to the goal positions (the blue holes). You operate the mover using the arrow keys on your keyboard. You can only push a ball to the next position if that position is empty. You have solved the puzzle when all balls lie on holes.After version 1.1 the game Sokoban seems to have been removed from all future releases of Game Maker, it is unclear why, although we are not sure if it is in 1.2 as it is currently lost media.How were games stored?Games were saved into a specific folder “C:\\Program Files\\Game_Maker\\Games”, with each game having its own sub folder. Inside the game specific folder all the game resources were available: Images as .BMP files, named like so: image1.bmp, image2.bmp Audio as .WAV files, named with free text so *.wav Help documentation is saved as HELP.RTF Objects - Object data stored as plain text Rooms - Metadata Sounds - Plain text file just called sounds with no file extension that maps the sound name to the .wav file on the file system.Sounds file formatThe sounds file stores metadata to map the name of the sound in the game to the .wav file on the filesystem, the format is plain text and it is pretty straightforward:1 // number of sounds in filecreate // name of the soundbleep11.wav // filename of the sound0 // number of sounds leftObjects file formatObjects are stored in a plain text format which is fairly easy to read, with helpful comments about each section.Here is an example objects file for the Creating Stars Demo in the Game Maker 1.1 format, annotations have been added in the form of comments (//) to the end of each line but note these are not part of the format:3 // Total Number of Objects (3)=== OBJECT === // Start of an Objectcreator // Name of object (creator) 0 1 // Solid=False, Active=True=== CREATE ACTIONS // Start of Create Event1 // Number of actions in event (1) 201 -1 1 // actionID = 201 (Set Alarm); appliesTo = -1 (self); numberOfParameters = 15 // Set alarm clock to 50 // Number of actions in left in event (0)=== DESTROY ACTIONS // Start of Destroy event0 // Number of actions in event (0)=== ALARM ACTIONS // Start of Alarm event3 // Number of actions in event (3) 311 -1 1 // actionID = 311 (Create instance at postion); appliesTo = -1 (self); numberOfParameters = 10 // X = 00 // Y = 02 // Number of actions left in event (2) 401 -1 1 // actionID = 401(Play a sound); appliesTo = -1 (self); numberOfParameters = 11 // sound ID to play: 11 // Number of actions left in event (1) 201 -1 1 // actionID = 201 (Set Alarm); appliesTo = -1 (self); numberOfParameters = 115 // Set alarm clock to 150 // Number of actions in left in event (0)=== STEP ACTIONSNote that this format is more verbose than later formats by explicitly saying which event it is defining in the text file alone with including events that have 0 actions, this will be optimized in future versions to be less verbose and only include events that are being used.Rooms file formatSimilar to Objects and Sounds files, the rooms data is stored in plain text and can be easily understood when matched against the room editor.It follows the same format of counting down the rooms until the end of the file, it splits up the room into a specific Cell Size, to define the specific rows and columns in the room, so you can’t have instances of objects at an arbitrary x,y coordinate, it has to be a specific row,column position.Here is a snippet from the Creating Stars example:1 // Number of Rooms in the fileCreating Stars // Name of the Room255 // Possibly background color?Back3.bmp // Background Image1 // Tiled background image?0 15 15 // Width (15) and Height (15)32 // Cell Size (32 pixels)57 // Number of object instances in the room 0 0 3 // row=0; column=0; objectId=3 (wall)Emulating Game Maker 1.1The installer for Game Maker 1.1 is available through the WayBackMachine but it will not run on modern Windows.One way to run it is you can use a browser based Windows 95 Emulator such as v86 Windows 95 - v86 and create a CD Rom image ISO of the extracted gmaker11.zip setup files and mount it in the emulator as a CD.To create a CD ISO that works in Windows 95 from MacOS you can run:hdiutil makehybrid -o ~/Desktop/gmaker11.iso ./gmaker11 -iso -jolietReaching 1k downloadsBy early 2000, Game Maker 1.1 had attracted a small user base (reaching about 1000 downloads by February 2000) and demonstrated the potential of Overmars’s approach 7.Version 1.2 (2000) – Early ImprovementsGame Maker 1.2 was released shortly after 1.1 (as a “quick” follow-up update) and brought a number of important improvements and new features while keeping the same basic interface 8.Performance and Language EnhancementsGame compilation speed was roughly doubled on low-end computers, and the engine allowed longer code segments, making the GML scripting more practical for larger projects 9. New built-in constants/variables were introduced (e.g. pi, roomwidth, roomheight, and several back_... variables for backgrounds) to give developers more control over game properties 9. Variable naming was also made more flexible (uppercase letters became allowed in variable names) and other minor GML syntax tweaks were applied for consistency.Backgrounds and Sound ControlScrolling backgrounds were now supported, allowing developers to have moving background images in their games (a feature not present in 1.1) 8. Additionally, an action to stop a currently playing sound was added, which was especially useful for stopping background music or looping sounds via code or drag-and-drop 8.Editing and Interface FeaturesGame Maker 1.2 made the editor more user-friendly. It became possible to copy or duplicate resources – for example, you could duplicate objects, rooms, and sounds – streamlining development 9. A new “object clipboard” was introduced, allowing users to copy and paste sets of actions between objects, which made reusing logic easier 8. Also, keyboard shortcuts were added for common run-time actions (to quickly start, pause, or stop the game during testing) 9.Miscellaneous FixesVersion 1.2 also fixed numerous bugs from 1.1. For example, it increased the maximum room speed and the number of objects a room could contain, corrected issues with background image memory handling (small BMP images were now given transparent backgrounds properly), fixed the lastkeypressed value, and resolved cut-and-paste problems in the sprite/image editor 8.Lost MediaHowever Game Maker 1.2 is currently considered Lost Media as no versions have been archived so the above details are based on the Changes.txt file in version 1.3 of Game Maker which is available online. Mark Overmars used to keep historical versions on his site but only ever included 1.1 and 1.4 of the 1.x series, so it is possible he doesn’t have version 1.2 10.Version 1.3 (2000) – Minor EnhancementsGame Maker 1.3 was another incremental update on the 7th January 2000, focused on refining the software further.Information on the main IDE executable (Game Maker.exe): File size - 850KB Compiler - Borland Delphi 5 Professional Linker - Turbo Linker 2.25Version 1.3 brought additional minor improvements and bug fixes to ensure stability: Enhanced image loading, allowing arbitrary sized images (also large ones) for the objects Support for Animated GIFS Now possible to draw shapes rather than just images Ability to export a game as a zip file and re-imported for sharing editable games online forall statement introduced to GML programming language (can execute a piece of code for all instances of a particular object) Internals have been refactored to be more efficient, use less memory and no more limits on the number of objects or variablesImportantly, Game Maker 1.3 still operated under the same technical constraints as its predecessors – it did not yet include DirectX support for graphics, nor did it provide a separate game runner or the ability to create stand-alone executables 11.Games created in 1.3 were still run from within the Game Maker environment, and rendering remained in software mode. In essence, version 1.3 was a maintenance release that smoothed out the 1.x line in preparation for more significant changes to come in the next major version.Included example games and demosGame Maker 1.3 introduced a new space game, renamed Falling Balls to be a Demo and also removed the Sokoban game: DEMO Falling Balls - An example of how gravity can be used in Game Maker by increase the vertical speed in every step by a small amount. When the ball hits the bottom wall, we set the vertical speed to -vspeed*0.9. As a result the direction changes (the speed becomes negative) and becomes slightly less such that the motion become slower with each bounce. GAME Space TripHow were games stored?Games were stored in the same location as previous versions of Game Maker (“C:\\Program Files\\Game_Maker\\Games”), but the format of the plain text metadata (e.g objects) changed to be a little more cryptic. Also images were now saved as GIF instead of BMP format to allow for animated sprites to be stored in a single file.Inside the game specific folder all the game resources were available: Images as .GIF files, named like so: image1.gif, image2.gif Audio as .WAV files, named with free text so *.wav Help documentation is saved as HELP.RTF Objects - Object data stored as plain text Rooms - Metadata Sounds - MetadataObject formatA few notes about the format: Newline separated - Uses the DOS/Windows standard newline sequence for separation which consists of a carriage return (CR 0D) + line feed (LF 0A) pair. Values on the same line seem to be separated by 4 spaces The number 1 is used for true (e.g checkbox on in the IDE) and 0 for false. We know we are at the end of a Object by the -------------------------------------------- string.Here is an example Objects file for the Creating Stars Demo, the comments at the end are not part of the format they have been added for annotation, note that the annotations are incomplete:version 1.3 // Version of Game Maker this was saved in3 // Number of Objects (3)creator // Name of Object \"creator\" 0 1 // Solid=False, Active=True 2 3 // eventID = 2 (Alarm event); numberOfActions = 3 311 -1 1 // actionID = 311 (Create instance at postion); appliesTo = -1 (self); numberOfParameters = 10 // X coordinate of instance0 // Y Coordinate of instance2 // Object ID of instance to create (or is this the actionsLeft?) if so where is the objectID stored 401 -1 1 // actionID = 401 (Play a sound); appliesTo = -1 (self); numberOfParameters = 11 // SoundID to play // Newline to signify end of action?1 // actionsLeft = 1 201 -1 1 // actionID = 201 (Set Alarm); appliesTo = -1 (self); numberOfParameters = 115 // Set alarm clock to 15 // Newline to signify end of action?0 // 0 to signify end of event? 0 1 // eventId = 0 (Create); numberOfActions = 1 201 -1 1 // actionID = 201 (Set Alarm); appliesTo = -1 (self); numberOfParameters = 15 // Set alarm clock to 5 // Newline to signify end of action0 // 0 to signify end of event-1-------------------------------------------- // Signifies end of Objectstar // Object name \"star\" 0 1 // Solid=False, Active=True 142 1 // eventID = 142 (?); numberOfActions = 1 101 -1 1 // actionID = 101 (\"Set direction of motion\") action; appliesTo = -1 (self); numberOfParameters = 1111101111 // Directions in \"Set direction of motion\" action // Newline to signify end of action?0 // 0 to signify end of event? 4 1 // eventId = 4 (Collision); numberOfActions = 1 101 -1 1 // actionID = 101 (\"Set direction of motion\") action; appliesTo = -1 (self); numberOfParameters = 1 111101111 // Directions in \"Set direction of motion\" action // Newline to signify end of action0 // 0 to signify end of event 0 1 // eventId=0 (Create); numberOfActions = 1 101 -1 1 // actionID = 101 (\"Set direction of motion\") action; appliesTo = -1 (self); numberOfParameters = 1111101111 // Directions in \"Set direction of motion\" action // Newline to signify end of action0 // 0 to signify end of event-1-------------------------------------------- // End of Objectmuur // Object name \"muur\" (muur is the dutch for wall) 1 0 // Solid=True; Active=False-------------------------------------------- // End of Object (no events on the muur/wall object since its not Active)The annotations above are incomplete: it is unclear currently if 0 signifies the end of the event or if it just counts down to how many actions are left to parse. numberOfParameters looks to be incorrect as it is always 1 even for the “Create instance at postion” action.Version 1.4 (2000) – Final 1.x ReleaseVersion 1.4 was the last update of the 1.x series, released toward the end of 2000. Like version 1.3, it was primarily aimed at final polishing and stability. According to community recollections, 1.4 fixed remaining bugs and fine-tuned the features introduced in 1.2/1.3. There were no major new features added in 1.4 – instead, Overmars ensured that the existing features (objects, events, basic GML, etc.) all worked as expected in preparation for a major overhaul with version 2.0.Version 1.4 can be seen as the stable culmination of the initial Game Maker prototype-by this point, the software was relatively robust in its original feature domain, and the user base was primed for the more “substantial new features” promised in the next major version 6.Version 2.0 (2000) – Interface Overhaul and Growing PopularityReleased on the 8th September 2000, Game Maker 2.0 was the first major version number change for the software. This update brought a redesigned interface and significant usability improvements, making game development easier and more powerful for users who had outgrown the 1.x features. Key aspects of version 2.0 include:Improved UI and WorkflowMark Overmars refined the Game Maker IDE in 2.0, reorganizing how resources (sprites, sounds, rooms, etc.) were managed. The interface became more intuitive than the 1.x series, addressing some limitations of the earlier design. According to later retrospectives, each major release around this time introduced a new file format or layout; Game Maker 2.0 was no exception, likely switching to a new project file structure as part of the overhaul 5. The overall look-and-feel moved closer to what modern Game Maker versions would use, with more dialogs and organizational panels for different resource types.More Actions and FunctionsVersion 2.0 added many new drag-and-drop actions to broaden the range of possible game mechanics without coding 5.Users now had access to more pre-built actions for things like advanced object movement, basic drawing, and control structures, which reduced the need to write GML for common tasks. This expansion of the drag-and-drop system made Game Maker more accessible to beginners and allowed more complex games to be made visually.Continued Script Language SupportThe GML scripting language was further developed, although still not as sophisticated as it would eventually become. Version 2.0 improved file handling functions, more sound control functions, ability to rotate text and more control over the way images are displayed, etc. GML script was still only available in the Object Editor as an action so stand alone “scripts” were not available until a later version.First DirectX support (DirectSound)This was the first version to introduce functionality based on the DirectX SDK, specifically DirectSound, Game Maker would check if DirectX 5.0 or higher is installed on the target PC and if so would allow higher quality audio playback and introduced sound effects.Importantly, Game Maker 2.0 still did not introduce DirectX acceleration for graphics this would come in the next version (3.0).The rendering engine remained software-based (using the Windows GDI), and games were run through the editor or a bundled interpreter rather than truly independent programs 6.System RequirementsAccording to the Game Maker 2.0 installer the system requirements for 2.0 were as follows: A modern PC (preferably a Pentium) running Windows’95,’98, 2000 or NT 4 is required.After installation the program uses about 3 MB disk space.The program requires at least 65000 colors (high color, 16-bit).It requires at least 800x600 screen resolution.Included example games and demosGame Maker 2.0 provided a few games and non-interactive demos to both showcase the functionality and to teach how to use the software, they are the same as 1.3 listed above but with the additoon of: GAME MazeSharp rise in Game Maker’s popularityDuring the year 2000, Game Maker’s popularity started to rise rapidly.By the end of that year, the program had been downloaded tens of thousands of times by hobbyist developers worldwide, thanks in part to the enhancements in version 2.0 and positive word of mouth in online communities 5.In summary, Game Maker 2.0 modernized the tool’s interface and expanded its feature set, making it a more robust platform for game creation. It set the foundation upon which the crucial technical upgrades of versions 3 and 4 would soon build.Version 3.0 (2001) – First Use of DirectXOn the 23rd November 2001, Overmars released Game Maker 3.0, which was a milestone for the software’s graphics and performance. The hallmark of version 3.0 was the introduction of DirectX rendering support for the first time 6. This had several important effects: Hardware-Accelerated Graphics: By leveraging Microsoft DirectX (likely DirectDraw at this stage), Game Maker could now render graphics more efficiently. Games ran faster and could use full-screen modes and graphical effects that were not feasible under the old software-based renderer. This was a significant step up in capability, as it unlocked the potential for smoother animations and richer visuals. Same Feature Set, But Faster: Other than the new DirectX-powered renderer, version 3.0 did not radically change the game creation features introduced in 2.0. The user interface and workflow remained similar, but everything was generally more polished and performant. For instance, operations that previously might have lagged (like drawing many sprites) could now benefit from DirectX’s blitting capabilities. In essence, 3.0 “implemented DirectX for the first time” to boost graphics handling 6, while maintaining the drag-and-drop and GML systems as they were. No Stand-alone Executable Yet: It’s worth noting that even with DirectX, Game Maker 3.0 still lacked an independent runtime or compilation to EXE. Games were executed via the Game Maker environment (or a packaged interpreter). The ability to create a true stand-alone game file was still not present at this stage, coming a bit later. Minor 3.x Updates: Following 3.0, a few minor revisions (3.1, 3.2, and 3.3) were released in 2001 to fix bugs and add minor improvements. These updates improved stability and further increased DirectX support, such as verison 3.1 which removed Exclusive mode in favour of DirectX in windowed mode (3.0 was only DirectX in fullscreen mode). Version 3.2 added new room options: more background options, multiple views, and transitions between roomsOverall, Game Maker 3.x dramatically improved the engine’s under-the-hood performance. The use of DirectX was a turning point that allowed users to create more complex and graphically intense games than before 6.This helped Game Maker’s community grow even more, as the quality and smoothness of games made in GM started to increase. Version 3.0’s success set the stage for an even more comprehensive overhaul in the next major release.Version 4.0 (2001) – Major Rewrite and New CapabilitiesGame Maker 4.0, released on the 16th July 2001, was a complete overhaul of the software. Mark Overmars rewrote large portions of Game Maker from scratch for this version 6, making sweeping changes to the interface, architecture, and capabilities. Important highlights of version 4.0 include: Entirely New Interface: The IDE in Game Maker 4 was significantly redesigned. The layout and organization of resources were improved, giving the tool a more professional and user-friendly feel. In fact, the Game Maker 4.3 interface (the final revision of this line) looks very familiar even to users of much later versions – it established the general design paradigm that persisted in subsequent releases 5. This means that by 4.x, Game Maker had a resource tree, event selectors, and editors that resemble those used for years to come. Introduction of Multiplayer Functions: Version 4.0 was the first to include built-in support for basic multiplayer/networking features. A set of MPlay networking functions was added, allowing simple multi-computer play over a network or the internet. This was a notable expansion of Game Maker’s capabilities beyond single-player games. Although the networking system was rudimentary (suitable for simple games or turn-based exchanges), it demonstrated Overmars’s intent to broaden the engine’s scope. Standalone Executables (EXE) Export: For the first time, Game Maker could compile games into independent executable files. With version 4, developers were no longer confined to sharing editable project files; they could create a stand-alone Windows EXE for their game and distribute it to others who didn’t have Game Maker. Under the hood, this worked by bundling the game’s resources with a runner program. The new feature was transformative - games made in GM4 could be run like any other Windows program 12. (This capability coincided with the introduction of a separate “game runner” module in the architecture). The addition of EXE output in 4.0 greatly increased Game Maker’s appeal, as creators could publish their games more easily. Continued DirectX Support: Building on version 3, Game Maker 4 fully embraced DirectX for rendering. The rewrite likely optimized the use of DirectDraw and related technologies even further, making 2D drawing faster and enabling things like smooth sprite rotations and better transparency handling by default. The combination of DirectX acceleration and stand-alone export made GM4-generated games much closer to “real” indie games of the time. New Icon/Branding: Game Maker 4 introduced a new program icon (a red gear/hammer icon), replacing the icon used in versions 1–3 13. This visually signaled a new era for the software. The red icon design continued to be used through versions 5, 6, and 7 13, indicating that GM4 set a branding precedent as well. Game Maker 4.x Updates: After 4.0’s release, Overmars issued a few updates (4.1, 4.2 and 4.3) in 2001–2002 to refine the new system. By Game Maker 4.3b (released in 2002), the software was very stable and feature-rich for its generation 5. This period saw frequent updates, a growing library of user-made examples, and even the launch of the first community-made Game Maker magazine 5. The 4.x series firmly established Game Maker’s core design; many long-time users started with version 4.2 or 4.3 and found the experience recognizable even in later versions.In summary, Game Maker 4.0 was a landmark release. It delivered a modernized, rewritten IDE, support for networking play, and the much-demanded ability to compile games into executables 6 12. The engine had matured considerably, and by the end of the 4.x cycle Game Maker was a robust tool for 2D game development. These changes propelled Game Maker into the “prominence” phase – the user community greatly expanded around this time, thanks in part to the newfound ease of sharing completed games.Version 5.0 (2003) – Extensions and Paid RegistrationReleased in April 2003, Game Maker 5.0 built upon the solid foundation of the 4.x series and introduced a couple of notable new features. It also marked a shift in Game Maker’s distribution model from freeware to a shareware/registration model. Key points for version 5.0 include: External Files and Custom Data: Game Maker 5 added support for using external files in games 6. This meant games could read and write files (such as saving custom data, configurations, or high scores to an external text file) more easily, and could include external resources. This opened the door for more complex game behavior (for example, loading level data from files, or modifiable content). Essentially, GM5 introduced new functions to handle files and perhaps binary data, giving developers more flexibility beyond the fixed resources in the editor. Timelines: Another major feature in 5.0 was the introduction of Timelines as a resource type 6. A timeline in Game Maker allows the creator to schedule actions to occur at specific steps (moments) during game execution. This is useful for coordinating sequences of events (for instance, scripting a cutscene or orchestrating waves of enemies in a shooter). The timeline editor let users create a list of actions indexed by time without writing code, which was a powerful addition to the drag-and-drop toolkit. General Improvements: Version 5 continued to improve overall stability and added smaller features. For example, there were likely new actions and functions (taking advantage of the external file capability), and quality-of-life improvements in the IDE. It also kept all the important features from 4.x: DirectX graphics, EXE output, etc., refining them further. By this time, Game Maker was quite feature-rich in 2D game mechanics, so 5.0’s main innovations were about data and structure (files and timelines). Registration System Introduced: Game Maker 5.0 was the first version that was not completely free. Mark Overmars introduced a registration fee of $15 USD for the software 5. The initial approach was that Game Maker 5 could be downloaded for free, but it would run in a limited mode (with certain advanced features disabled and a nag screen at startup reminding users to register). Users could pay $15 to unlock the full “registered” version. This change was made to support ongoing development, as Overmars had previously only asked for voluntary donations 5. The nag screen (displayed when running the GM5 IDE or when launching games made with the unregistered version) became famous – it showed the Game Maker logo and a request to register 5. Once registered, Game Maker 5 allowed access to all features, which included things like using DLLs and other advanced functions (some of these pro-only features were added in minor updates or were present but locked for unregistered users). Community Growth: Alongside GM5’s release, 2003 also saw the launch of the official Game Maker Community forums in their modern form 5. This greatly helped users share knowledge, and a surge of new users joined around this time, drawn by Game Maker’s expanding capabilities. Many high-quality example games and tutorials from the community began appearing on the official site during the GM5 era 5.In essence, Game Maker 5.0 was an evolutionary update that extended the engine’s functionality into new areas like file I/O and event scheduling (timelines) 6. It also marked Game Maker’s transition to a partly commercial product with the introduction of a registration fee 5. Despite some initial community resistance to paying for previously free software, the modest price and the promise of continued improvements kept Game Maker’s user base growing. GM5’s enhancements were particularly welcomed by more advanced users, as they allowed for games with persistent data and more complex scripted sequences.Version 6.0 (2004) – New 3D Graphics EngineGame Maker 6.0 was released in October 2004 and represented another major technological upgrade for the engine. The most significant change was a completely rewritten graphics engine using Direct3D (part of DirectX) as the new backend 6. This brought substantial new graphical capabilities to Game Maker: 3D Graphics Functions: For the first time, Game Maker had built-in support for 3D graphics. Using Direct3D allowed Overmars to expose functions for drawing 3D primitives, textured shapes, and basic 3D models. Version 6 introduced a set of GML functions (and possibly drag-and-drop actions) that let users create simple 3D scenes – for example, drawing 3D boxes, floors, walls, and even applying textures to them 5. This was a big change; while GM6 was still primarily a 2D game engine, adventurous users could now experiment with 3D (for instance, making simple first-person or 3D racing games). Many users remember seeing demo projects of 3D spinning cubes and primitive 3D engines soon after GM6’s release. Enhanced 2D Drawing: Even for 2D games, the switch to Direct3D brought benefits. It made advanced effects easier – alpha transparency (translucency) was supported more smoothly, and sprite rotation and scaling became hardware-accelerated operations 6. Under the previous DirectDraw system, rotations and alpha blending were either not possible or had to be done via slow software routines. In GM6, one could rotate sprites or set their transparency and have Direct3D handle it efficiently, which opened the door to better visual effects in 2D games (like smooth object rotations, fading objects, particle effects, etc.). Performance Improvements: The use of Direct3D generally improved rendering performance across the board. Games that might have struggled with many objects on screen in GM5 could run faster in GM6 if they took advantage of the new graphics pipeline. Full-screen mode and resolution handling were also improved through Direct3D. Minor Changes and Fixes: Aside from graphics, GM6 continued to refine other aspects. It likely fixed bugs from GM5 and could have introduced minor features or adjustments in response to the community (for example, improvements to the sound engine or timeline system). The overall workflow of Game Maker remained consistent; the big differences were under the hood. File Format and Compatibility: Game Maker 6 used a new file format (.gm6) for saved projects, reflecting the engine changes. Notably, games made in GM6 were not backward-compatible with GM5 due to the new features. Overmars included a converter for GM5 -> GM6 projects, but once a project was in GM6 format, it couldn’t be opened in older versions. This was a common pattern with each major release.Game Maker 6.0’s introduction of Direct3D and 3D capabilities was a headline change widely discussed in the community 56. Although the typical user base continued to make 2D games, they benefited from the enhanced visuals and effects made possible in this version. The inclusion of 3D functions was somewhat experimental but showcased Game Maker’s flexibility. As a contemporary note, 2006 (during the GM6 era) also saw the publication of “The Game Maker’s Apprentice” (a book by Mark Overmars and Jacob Habgood) which used Game Maker 6 to teach game development 5. This further boosted GM6’s profile as an educational and hobbyist tool.(Game Maker 6 had a lifespan through 2005-2006 with a few minor updates/bugfixes, but no version 6.1 introduced major changes. By late 2006, attention turned to the next version as Overmars began collaborating with a new company to expand Game Maker’s reach.)Version 7.0 (2007) – Extensions and YoYo Games EraGame Maker 7.0 was released on February 28, 2007, and it marked the beginning of the YoYo Games era 6. This version was the first published under a partnership with YoYo Games Ltd., a UK-based startup co-founded by Sandy Duncan, which Overmars joined to help expand Game Maker’s development and global presence 5. Version 7.0 introduced new features and changes both in functionality and in how the product was managed: Extension Packages: The most touted new feature of GM7 was the ability to extend Game Maker’s functionality through extensions 6. Overmars added a system where users could create and use Extension Packages (.gex files), which bundled custom GML scripts, actions, and resources into a reusable form. This meant that advanced users or third parties could add new libraries of functions to Game Maker without needing built-in support from Overmars. For example, one could create an extension to provide physics engine functions, new particle effects, or integration with external APIs, and then import that into Game Maker. This greatly increased the flexibility of the tool. Essentially, Game Maker became somewhat modular – features could be added via extensions, and Mark didn’t have to hard-code every new idea into the main program. (In practice, many popular community-made extensions emerged after GM7’s release.) Resource Library Changes: In prior versions, users could create their own drag-and-drop action libraries using a separate program (Library Maker). With GM7 and the extension mechanism, the way custom actions were handled changed. It integrated more smoothly to allow extended D&D actions via packages 6. Changes in Asset Storage: Game Maker 7 introduced a new format for saving projects (.gmk). One notable change was that sprites, sounds, and other resources could optionally be stored externally (to avoid bloating the main file). Also, GM7 used an encrypted format for its resource packages to deter easy decompilation of game files (starting with version 7.0’s release candidates, game data was encrypted due to concerns over people creating other tools to import .gm6 files (G-Java, LateralGM)) 6. YoYo Games Integration: With YoYo Games involved, GM7 began tying into online features. YoYo Games launched a website for sharing Game Maker games (the “Sandbox”), and Game Maker 7 had menu links and features that integrated with this service. For instance, it offered easy uploading of games to the YoYo Games website. Additionally, the registration system changed: YoYo Games handled selling license keys, and the software required an internet connection to activate a license (a shift from the old offline registration of GM6). This was a significant change in how Game Maker was delivered – it reflected a more commercial, multi-platform ambition under YoYo Games. Minor Feature Additions: Besides extensions, GM7 added some other smaller improvements. For example, there were improvements to the sprite and image editors, new actions for particle systems, and better sound format support (GM7 introduced support for .ogg audio files for background music). It also improved the reliability of the new graphics engine introduced in GM6. However, no major changes to the core engine (rendering or physics) were made – GM7’s games ran similarly to GM6’s, with 2D and basic 3D via Direct3D. The emphasis was on extensibility and preparing for future platform support. Platform and Community Notes: Game Maker 7 was the last version that ran on Windows only (a separate port of GM7 for Mac was eventually created by YoYo Games in 2008, but that was a parallel product). The release of GM7 via the YoYo Games website also coincided with an expanding international user base, since YoYo’s involvement brought marketing and more visibility. Mark Overmars was still the lead developer of Game Maker 7, but now backed by a team.In summary, Game Maker 7.0 didn’t radically change what you could make with Game Maker in terms of game genre or engine power, but it expanded the software’s openness and infrastructure. With extension support, advanced users could push Game Maker further than before by adding new capabilities on their own 6. And with YoYo Games taking over distribution, Game Maker began evolving from a one-man project into a more professional product. This version set the stage for multi-platform targets and a larger community engagement that would fully manifest with subsequent versions. (Notably, there was a longer gap after 7.0 – it would be about two and a half years before the next version, as YoYo Games focused on community features and planning Game Maker’s future5.)Version 8.0 (2009) – Last Classic Version with Editor OverhaulsGame Maker 8.0 (often just called Game Maker 8) was released on December 22, 2009 6. It was the last major version of the “classic” Game Maker line developed with Mark Overmars’s direct involvement. GM8 came after a lengthy gap and delivered numerous improvements to the user experience, though it didn’t drastically change the engine’s underpinnings. Notable features and changes in Game Maker 8.0 include: Revamped Script Editor: One of the headline enhancements was a completely revamped code editor window for GML scripting 6. The new script editor had better syntax highlighting, auto-indentation, and a more user-friendly interface for writing code. This was a welcome improvement for users who wrote a lot of GML, making the coding experience smoother and more akin to standard programming IDEs. It included line numbers, find/replace functionality, and other conveniences that were lacking or rudimentary in previous versions. Improved Image/Sprite Editor: Game Maker 8 introduced a significantly improved built-in image editor for creating and editing sprites. The sprite editor got new tools and a better UI – for example, support for alpha transparency editing (RGBA), more drawing tools, and perhaps onion-skinning for subimages/animation previews. This meant users could do more pixel art and image touch-ups directly in Game Maker without needing an external graphics program. The overhaul made it easier to create higher-quality sprites and tiles within the IDE 6. Import/Export of Resources: GM8 added the ability to import and export resources (sprites, objects, scripts, etc.) between project files 6. This was implemented through a mechanism to save individual resources or groups of resources to an external file and then load them into another project. It greatly facilitated sharing and reusing code or assets. For instance, a user could export a monster object or a script from one game and import it into another without recreating it from scratch. This feature made Game Maker more modular and collaborative. New Default Font and Minor UI Tweaks: The appearance of the IDE was refreshed slightly – for example, GM8 used a different default font (Calibri) in the interface, which gave it a more modern look compared to the older versions that used MS Sans Serif. There were also new icons for some actions and minor layout adjustments. Overall, the IDE looked cleaner and more up-to-date in GM8. (This version also infamously introduced a new logo for Game Maker – a green circular “G” icon – chosen via a community contest, replacing the long-standing red ball icon 13. The logo change stirred some controversy in the community, but it was purely cosmetic and did not affect functionality.) Removed Legacy Features: In moving to GM8, some very old/obsolete features were pruned. For example, support for really outdated Windows versions was dropped and certain deprecated functions were removed or changed. This was part of cleaning up the codebase for the future. Bug Fixes and Stability: After the significant architectural changes in GM7 (with extensions and new file I/O) and the long development cycle, GM8 focused on stability. Many bugs from GM7 were fixed. The extension mechanism was still present, but more integrated. The game runner and executables produced were more stable on modern Windows OSes. Additionally, game performance saw minor improvements in some areas (though the engine was largely the same as GM7’s, aside from the editor upgrades). Monetization and Editions: Game Maker 8.0 continued the paid registration model. In fact, YoYo Games adjusted the pricing around this time (GM8 Standard was priced around $25). There was still a Lite version available for free with certain features (like 3D and extensions) disabled, and a Pro/registered version that unlocked full capabilities 6. Activation was handled online via YoYo Games accounts.As the final version developed under Mark Overmars, Game Maker 8.0 was a polished and user-friendly culmination of a decade of development. It did not radically change the types of games one could make (the engine was still 2D-focused with optional simple 3D, and used Direct3D8 for rendering just like GM7). However, it significantly refined the development experience - coding, painting sprites, and managing game assets became easier and more efficient in GM8 6. The community received GM8 very positively; it became a stable workhorse for many hobbyist and educational projects in the early 2010s. (An update Game Maker 8.1 would later be released in 2011 by YoYo Games, primarily to improve Windows Vista/7 compatibility and add minor features, but 8.0 was the last version where Overmars was deeply involved in the design.)The GM8.2 ProjectThe GM 8.2 Project is an open-source community-driven fork of Game Maker 8.0, aiming to enhance and extend the original software’s capabilities. Hosted on GitHub, the project encompasses multiple repositories focusing on various improvements and new features.​One of the core components is gm82core, a quality-of-life extension that introduces helper functions, precise timing, global variables, and utility constants to Game Maker 8.2. This extension serves as a foundation for many other modules within the GM 8.2 ecosystem.GITHUBOther notable modules include gm82room, a revamped Room Editor module, and gm82dx9, which provides a DirectX9 interface extension, enhancing the graphical capabilities of Game Maker 8.2.By building upon the original Game Maker 8.0, the GM 8.2 Project aims to modernize the software, incorporating new features and improvements that cater to the evolving needs of game developers without switching to GameMaker Studio line of products.​Find out more on the official website:GM 8.2 ProjectGame Maker CommunityOne of the strongest parts of Game Maker was its community, first started on 9th November 2000 and simply called Game Maker Forum (gamemaking.community.everyone.net)14.Key milestones for the GMC: Image Host Description None gamemaking.community.everyone.net Single board simply called Game Maker Forum pub58.ezboard.com/bgamemakercommunity It then moved to EZboard on the 16th March 2001 gmcommunity.edgehost.com/forums/ Invision Power Board v 1.1 on 6th October 2002 but it only lasted until 8th January 2003 due to server problems (so they went back to Ezboard). forums.gamemaker.nl Started on 26th October 2003 another self-hosted Invision Power Board v1.3 this one was much more successful and they never went back to Ezboard gmc.yoyogames.com Started 8th May 2007 The Game Maker Community has now lasted over 25 years!References Game Maker History 2002 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 Game Maker Facts 2004 ↩ ↩2 Dreamland: Home of Josh ↩ Version 1 - Game Maker - Fandom ↩ Ten Years of Game Maker 1999-2009 - GameMakerBlog ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 Gamemaker - Everything for computers Wiki - Fandom ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25 Game Maker Histories - GameMaker Community ↩ GameMaker Versions - GameMaker Wiki ↩ ↩2 ↩3 ↩4 ↩5 Game Maker 1.2:軟體介紹,改善列表,修正列表,產生背景,主要功能,影_中文百科全書 ↩ ↩2 ↩3 ↩4 Game Maker Pages Old Downloads ↩ Game Maker 1.3 ↩ RMA Games Collection by Alamantus GameDev ↩ ↩2 New Game Maker Logo Revealed - GameMakerBlog ↩ ↩2 ↩3 Game Maker Pages 2001 ↩ ", "excerpt": "Game Maker is a popular 2D game development tool originally called Animo and developed by Professor Mark Overmars. Version 1.0 was built some time in 1998-1999 but never released publicly but on the 15th November 1999 Game Maker was officially released to the public with version 1.1. Game Maker is...", "tags": ["gameengines","middleware"], "image": "/public/generated/placeholders/game-maker.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "GameMaker (UK) Game Development Magazine", "url": "/gamemaker-magazine", "content": "GameMaker was a unique magazine first published by Future PLC in the UK in October 2003. It was a game development and modding magazine targeted at the general public!It had the tagline “The world’s only dedicated game modding magazine” and featured interviews with prominent members of the PC game modding scene along with industry professionals.Short RunSadly, the topic was deemed too niche and only one standalone issue was ever published before it became a section of PC Format magazine for two issues (159 & 160), and then a separate supplement distributed with the magazine for a further three issues, until it was replaced in issue 165 by a Doom 3 supplement instead.GameMaker Magazine Index of ArticlesBelow is a table of all the articles known to have been included in GameMaker magazine’s short run. This includes when it was a standalone issue (1), when it was a section of PC Format (2–3), and when it was a separate supplement included with PC Format (4–7). Issue Name Description 1 WARCRAFT 3 The basics of creating a map in the Warcraft 3 Map Editor with a hero (Hercules), an enemy (Hydra), and victory conditions 1 UNREAL TOURNAMENT 2003 Introduction to Unreal Editor 3.0, using brushes to carve out maps, adding textures, lighting, and even creating moving platforms 1 MAKE A MOD General advice from Kieron Gillen about modding games, including project scope and how to recruit other modders 1 NEVERWINTER NIGHTS Introduction to the BioWare Neverwinter Nights Toolset for creating a simple adventure game, including scripting and adding factions 1 ADVENTURE GAME STUDIO Introduction to AGS for creating a simple point-and-click graphic adventure game with scripts and background music 1 THE SIMS Covers tools like SimShow, Facelift, HomeCrafter, Transmogrifier, Blueprint, Career Creator, and how to replace the radio station MP3 files 1 HALF-LIFE/COUNTER-STRIKE Brief introduction to the Valve Hammer Editor 1 THE GAME FACTORY PRO Create a simple snowboarding game (similar to SkiFree) in The Game Factory Pro 1 HISTORY OF MODDING Covers the history of game modding, such as “Adventure”, “Ms Pac-Man”, “Castle Smurfenstein”, “Team Fortress”, etc. 1 GRAND THEFT AUTO: VICE CITY Introduction to modding GTA Vice City using tools such as CROA, ZModeler, CarEd 1.4, IMG Tool 1.3, and ViceTXD 1 RAILROAD TYCOON 3 Create a simple map in Railroad Tycoon 3 with the built-in editor, including adding a volcano with the Paint Terrain tools 1 3DS MAX AND UNREAL ED Tutorial for getting a 3D Studio Max model into UT2003, including fixing textures with Photoshop, rigging with Character Studio 3, and exporting with ActorX 1 FLIGHT SIMULATOR 2004 Using GMax to create custom aircraft and scenery for Flight Simulator 2004 1 NVIDIA CHARACTER DESIGN Article by Daniel Hornick, Hubert Nguyen, and Curtis Beeson from Nvidia 1 MILKSHAPE Tutorial for creating a 3D man with a gun that can be imported into Unreal Tournament 1 QUAKE III Detailed guide on how to create a level in Quake 3 using Q3Map2Toolz 1 Low Poly Modelling Creating a low-poly model of a cartoon character in 3D Studio Max 5 7 Heart of Battle Interview with Mike Domenighin, part of the 9-man team behind Heart of Battle, a mod for Call of Duty 7 Ground Control II Tutorial for creating a map with the official XEd level editor released by Massive Entertainment 7 Advanced Techniques in Battlecraft Part 2 of the tutorial on the modding tool for Battlefield 1942 and Battlefield Vietnam 7 The Sims 2 Body Shop Try your hand at genetics and start creating life for The Sims 2, months before the game’s release 7 Call of Duty Mapping (Part 1)   7 What the Blender Saw (Part 2) Interactive fiction 7 Homeworld 2 The Basics (Part 1) Homeworld 2 Random Map Editor 7 In Hindsight Interview with the developer of A Tale in the Desert (eGenesis) Issue 7 started tutorials Call of Duty Mapping and Homeworld 2 The Basics, but there was never an issue 8, so it’s unclear if Part 2 of these tutorials was ever published.It appeared that a GameMaker issue 8 was planned, as it was advertised at the end of issue 7, although issue 165 instead came with a Doom 3 supplement:Odd Mods - Weird PC Game ModsFrom issues 4 to 7, there was a one-page section at the back of the magazine where Mark Holtham explored the weird PC game mods available at the time. For anyone looking to discover unusual old game mods, the mods he covered are listed in the table below, along with URLs that will likely need to be accessed via the Wayback Machine: Issue Mod Name Game its a mod for Description URL 4 Sweet Dreams Unreal Tournament 2003 A surreal, psychedelic third-person mod inspired by Rayman, featuring bizarre environments and an interactive start sequence set in the player’s bedroom. gamestudies.oslo.org/~sdreams 4 Jupiter Effect Unreal Tournament 2003 A futuristic city combat mod reminiscent of Sega’s Virtua On and Macross, featuring light-hearted deathmatch gameplay and destructible environments. www.planetunreal.com/jei 4 Air Buccaneer Unreal Tournament 2003 A pirate-themed aerial combat mod focusing on teamwork and airship battles, combining fantasy and steampunk aesthetics. ludocraft.oulu.fi/airbuccaneers 4 BiTurbo Battlefield 1942 A high-speed vehicle mod adding jet-like acceleration, visual effects, and new skins for planes and jeeps, designed for chaotic, fun LAN play. www.hsilan.de/biturbo 5 Earth Special Forces Half-Life A third-person anime combat mod based on Dragonball Z, featuring playable characters like Goku with powerful energy attacks and team-based gameplay. www.esforces.com 5 Mr. Pants Excessive Overkill Unreal Tournament 2003 A high-intensity mutator adding extreme weapon power and chaos to Unreal Tournament 2003, emphasizing fast-paced, large-map carnage. www.planetquake.com/excessive/q3.shtml 5 Colosseum Jedi Knight 2: Outcast A gladiatorial combat mod featuring hand-to-hand melee fighting with cinematic execution and Roman-inspired arenas. www.jakekeating.com/thesis/ 5 Battlefield Pirates Battlefield 1942 A naval combat mod replacing armies with pirates, featuring ship-based battles, sea galleons, and humorous physics-driven pirate antics. www.internempire.com/bfpirates 6 Resident Evil: The Awakening Part 1 Half-Life A survival-horror mod inspired by the console version of Resident Evil, featuring slow-paced gameplay, puzzles, and cooperative play via Sven Coop. www.retheawakening.tk 6 Bumper Cars Unreal Tournament 2003 A humorous mod recreating fairground bumper car chaos where players slide and collide across multiple maps for light-hearted fun. www.planethalflife.com/bumpercars/index.asp 6 Duffers Golf Unreal Tournament 2004 A golf simulation mod blending sports mechanics with Unreal combat physics, featuring a power bar, club selection, and bunkers. duffers.beyondunreal.com 6 Fraghouse Invasion Unreal Tournament 2004 A large-scale Invasion mod focusing on cooperative play against waves of mutant enemies with vehicles and expansive custom maps. fraghous.beyondunreal.com 7 Alien Swarm Unreal Tournament 2004 A top-down cooperative multiplayer mod inspired by Gauntlet, featuring class-based gameplay and team-based bug extermination missions. www.blackcatgames.com/swarm 7 Hydro Racer Battlefield 1942 A water-based racing mod featuring boats with missiles, torpedoes, and machine guns for competitive and entertaining gameplay. www.bf1942hq.com/hydroracers 7 Matrix Mod Quake III A slow-motion “Bullet Time” mod inspired by The Matrix, allowing cinematic firefights with realistic physics and time manipulation. www.planetquake.com/matrixq3 7 Code Red Quake III / Freeware A single-player and freeware total conversion featuring Mars Attacks-inspired levels, alien enemies, and large-scale combat environments. www.planetquake.com/codered ", "excerpt": "GameMaker was a unique magazine first published by Future PLC in the UK in October 2003. It was a game development and modding magazine targeted at the general public! It had the tagline “The world’s only dedicated game modding magazine” and featured interviews with prominent members of the PC game...", "tags": ["industry","magazines"], "image": "/public/generated/placeholders/gamemaker-magazine.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game Programming Starter Kit", "url": "/GameProgrammingStarterKit", "content": "Game Programming Starter KitThe Game Programming Starter Kit was software that was released in 6 different versions by 2 different publishers (Sams and then McMillan). It was one of the best ways for new developers to learn game development with industry standard technologies. It is one of the few products that could almost guarantee to put students on the right path for the games industry.Version 1.0The first version was released in 1994 by Andre LaMothe and published by Sams, it consisted of 2 CDs and a full 900 page physical copy of Teach Yourself Game Programming in 21 Days.Not only that but it contained the full retail version of Microsoft Visual C++ 1.0 along with the eBook version of Teach Yourself Visual C++ in 21 Days.It also claims to have a full 2D DOS game engine on the CDs but we don’t know much information about it.The Book - Teach Yourself Visual C++ in 21 DaysTeach Yourself Game Programming in 21 Days is a comprehensive guide authored by André LaMothe, published in 1994. This book is designed to introduce readers to the fundamentals of game development, particularly within a DOS environment using the C programming language.The Book is split into 21 Chapters, one for each of the days, you can see the table of contents in the table below: Day Description Day 01 Today you learn about all the components that make up a complete video game-and probably get a workout lifting this book! Day 02 Today you see a complete game called Mech War and learn what went into making it. Day 03 Today you learn everything you ever wanted to know about the VGA card. You also learn about the 320x200 256-color mode. Day 04 Today you learn about little elven creatures called sprites and how to force them to participate in your games. Day 05 Today is a long one. The world of polygon-based graphics and all its related math is laid out in gruesome detail. Day 06 Today you learn about advanced topics in bitmapped animation and graphics, and how a video-game display is rendered flicker-free! Day 07 Today you learn how all the input devices, such as the keyboard, joystick, and mouse, really work. Day 08 Today moves really fast because it’s about optimization techniques. So, put on some hard rock music and get moving. Day 09 Today you’re introduced to computer sound and music. You learn how to play digitized FX with the Sound Blaster, and more. Day 10 Today you learn how to implement synthetic intelligence algorithms for video games. Day 11 Today the mystery behind interrupts, real-time programming, and multitasking are uncovered, and a complete multitasking kernel is presented for DOS. Day 12 Today you learn about all the different ways the virtual game universe can be represented in the computer. Day 13 Today you learn about physics modeling, which is very useful when you try to simulate the motion and interactions between game objects. Day 14 Today you see all the tools used by a video-game programmer, as well as some of the price tags for them! Day 15 Today you learn gaming details, such as scoring, introductions, saving the game, and demo modes. Day 16 Today things start getting fun. You get to play and analyze the first full game you make, called Sea Shark. Day 17 Today you take a look at a more complex adventure game named Venture. It has scrolling, cool creatures, and a real plot! Day 18 Today I hope you’re hungry because you play Sim-Pizza-a pizza delivery simulator-that teaches that crime doesn’t pay! Day 19 Today the book changes gears and covers text-based games, and the basic parsing techniques and data structures used to create them. Day 20 Today you learn about the world of 3-D games, ray casting, polygon engines, and voxel graphics. Day 21 Today it’s time to make some money. You learn how to market and distribute your games. The eBook - Teach Yourself Visual C++ in 21 DaysAuthored by Namir Clement Shammas, this edition introduces readers to C++ and Windows application programming using Visual C++.It follows the “Teach Yourself in 21 Days” format, covering the complete Visual C++ environment and providing an overview of object-oriented programmingThis is the original Version 1.0 of the book, but I can only find details of version 1.5 of the book online, not even the cover is available.Version 2.0The Second version was released in 1997 by Macmillan Digital Publishing but I have never seen a copy to be able to detail what it contained and information online is severely lacking.Version 3.0The Third version was released in 1999 by Macmillan Digital Publishing and consisted of 3 CDs and the full physical copy of Game Design Secrets of the Sages!It also includes the DirectX 6.1 SDK and an SDK called Genesis 3D but only included the Introductory Edition of Visual C++ 6.0. Genesis 3D did come with its own level editor which supported Direct3D and 3Dfx Glide drivers.This time it contained three ebooks on the CDs: C++ Unleashed Teach Yourself Visual C++ 6 in 21 Days - Davis Chapman Using Visual C++ 6 (Special Edition) - Kate GregoryThe CDsThe first CD contains Genesis3D along with the 3 ebooks.The Second CD contains Introductory Edition of Visual C++ 6.0.The third CD contains DirectX 6.1 SDK.You can download the contents of the three CDs on Archive.orgVersion 4.0The Fourth version was released in 2000 by Macmillan Software and only consisted of 2 CDs this time.On those 2 CDs was the same Introductory Edition of Visual C++ 6.0 as the previous version and version 3.1 of the Genesis 3D SDK. The DirectX SDK was updated to version 7.0 and it came with a new 3D animation tool called Shadow Realm Model Animator.This time it only contained two ebooks but they were arguably better for game development as it now includes DirectX: Teach Yourself Visual C++ 6 in 21 Days Teach Yourself DirectX 7 in 24 HoursThe physical book that was included this time was the Second Edition of Game Design Secrets of the Sages by Marc Saltzman which is a really interesting book published by BradyGames.Version 5.0The Fifth version was released in 2001 by Pearson Software and thanks to someone scanning and uploading the User Manual for version 5.0 we know what was on the three CDs 1: Microsoft Visual C++ Introductory Edition 6 Microsoft DirectX 8 SDK 3D GameStudio Standard version 5.12 2We know that one of the eBooks included on the CDs was: Tricks of the Windows Game Programming GurusWe do know however that the physical book that was included this time was the Third Edition of Game Design Secrets of the Sages by Marc Saltzman. This books seems to be rather rare as I have never seen it for sale outside of this bundle.Version 6.0The mythical sixth version may have released in 2002 but there is no photos of it existing at all online. One source claims it included DarkBASIC SE which is a large departure from the standard Visual C++ and DirectX combo of the previous versions.Did it include a Fourth edition of Game Design Secrets of the Sages? Who Knows?References Starter Kit 5.0 user Manual ↩ Game Programming Starter 5.0 ↩ ", "excerpt": "Game Programming Starter Kit The Game Programming Starter Kit was software that was released in 6 different versions by 2 different publishers (Sams and then McMillan). It was one of the best ways for new developers to learn game development with industry standard technologies. It is one of the few...", "tags": ["tools","books"], "image": "/public/images/tools/Game Programming Starter Kit.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Gameboy (DMG & GBC) Development Kit Hardware", "url": "/gameboy-development-kit-hardware", "content": "This post covers all the hardware developers used to create games for the original Dot Matrix Game Boy (DMG) and Game Boy Color (GBC) and some were even used for early Game Boy Advance development. Developers used both official Nintendo development kits and some unofficial 3rd party devices to create retail games for the Game Boy and Game Boy Color.Official Programming ToolsThe Official programming development kit for the Gameboy consisted of the Debugger that cost 4,000 USD and the Emulator (ICE) which cost 3,000 USD and were both developed by the Nintendo owned company called Intelligent Systems 1.They both connect to a developer workstation such as an IBM-PC via the SCSI port and offer a few software tools for communication between the IBM-PC and the Intelligent systems hardware.DMG-ICE (Debugger + Emulator) The Integrated Circuit Emulator or ICE was developed for the original Gameboy (DMG) and allowed developers to debug issues effecting their games, set breakpoints and inspect memory. This may also have been known as the Program development system (confirmation needed) but this information is unconfirmed. A Practical DMG-ICE WorkflowThe clearest preserved example comes from the Super Game Boy sample package in the Nintendo Gigaleak.Its batch files and debugger script make the older workflow unusually legible: MIFES was used to edit the source files on the workstation ISDMG assembled the main program ISLINK linked the image isd launched the debugger session START.ICE told the debugger to load SGB_MAIN, map CHRDAT.COM into bank 2 at $4000, and then run against the DMG ICE environment Super Game Boy SDK Sample and BIOS Files For a concrete preserved example of the DMG ICE workflow in action, see the Super Game Boy sample package. </p> </div> </blockquote></a></div>Game Boy Color Prototype BoardBrett Weiss provides a technical demonstration of a rare Game Boy Color prototype board, which was originally distributed to developers for pre-launch software testing. The video explores the unique hardware configuration of this “work-in-progress” unit, noting its reliance on a Super Famicom power adapter and its integration of core handheld components such as the IR sensor and microswitch buttons.IS-CGB-EMU (Nintendo Game Boy Color Emulator) The IS-CGB-EMU (Intelligent Systems Color Game Boy Emulator) was hardware that allowed developers to download their games to try on the actual hardware and even communication between an IBM-PC and the gameboy hardware itself to execute and check operations. Developers that bought this would also be given discs with the Inteligent Systems Assembler/Linker and other software development tools. If the IS-CGB-DEBUGGER label is ticked on the bottom of the unit then it also supported debugging options such as setting breakpoints, tracing, inspecting memory etc and is likely an ICE (Similar to DMG-ICE) 2. The Later units also had support for the AGB (Advanced GameBoy or Gameboy Advance) built into the hardware. The Zelda DX source tree from the Nintendo Gigaleak gives this a bit more texture.Its Color-era build folders still preserve debugger-ready .ISX outputs, .prn listings, .map files, and isdwd*.dat metadata right beside the source, which fits a workstation-plus-debugger workflow rather than a simple cartridge downloader alone. The Super Game Boy sample package and the Zelda DX source leak preserve the PC-side tools and debugger metadata that would have been used with this hardware in practice. Game Boy File Formats (DMG, GBC) For the file formats used by this toolchain, including .ISX, .ICE, .PRN, and the debugger sidecar files, see this post. I picked up a cool GBC dev kit. The IS-CGB-Emulator. I love the cartridge and cable that connects the handheld to the unit. Does anyone else have one of these or even the GBA version? Please post photos of your kit. I'd love to see it :) pic.twitter.com/NDhShaEToK— Andrew (@AndrewEarley7) December 6, 2020 Handheld Museum - IS-CGB-EMU The Handheld Museum website has an excellent page on the IS-CGB-EMU DMG-CAD & IS-CGB-CHARACTER (Gameboy tile/sprite editing hardware) The DMG-CAD (Character Development System) allowed designers/artists to preview pixel art on the gameboy hardware without using the more programmer specific hardware such as the DMG-ICE. Not much information is known about it other than a brief mention on the Intelligent systems website back in 1998 2. There is also the IS-CGB-CHARACTER which is a similar system but updated for the Gameboy Color, the photos on the left are from that system but it only shows the Gameboy screen and wires coming out the back, it is unclear where the wires went. There was one sold on Japanese Yahoo Auctions but the link was never archived in the wayback machine (“http://page.auctions.yahoo.co.jp/jp/auction/181784286”). Presentation/Demo ToolsDemonstration tools are hardware that allowed publishers or the press to present gameboy games on a larger screen, useful for demos and to create screenshots for magazines.Famicom Wide Boy (DMG) The WideBoy was used to present Game Boy games on a bigger screen such as a TV, to do this it contained Famicom (NES) hardware with a custom program written to an EPROM and connected directly to the Famicom board. It was developed by Intelligent Systems and only sold to Game developers and Press outlets by Nintendo themselves. This was commonly used by developers and testers to make it much easier on their eyes than constantly looking at the non-backlit original Game Boy screens 3. Nintendo WideBoy Chris M Covell has an excellent page on the WideBoy N64 Wide Boy (Wide-Boy64 or WideBoy64) (DMG & CGB) An updated version of the Wide Boy was released as a cartridge for the Nintendo 64 that supported GameBoy Color games 4. Later they released a new version of the Wide-Boy64 that could play Game Boy Advance games known as the AGB model. During development of the Pokemon Gold/Silver/Crystal games the WideBoy64 was used to take screenshots of visual artifacts by the QA team and sent to the developers. The development team used WideBoy64 screen captures to document graphical bugs in Pokemon! https://t.co/WsYV7pKFCh— 🕹 RetroReversing.com - Reverse Retro Games 🕹 (@RetroReversing) April 25, 2020 Demo Boy II (DemoVision) The Demo Boy was an alternative to the Wide Boy that allowed displaying two Game Boy screens at once on a single TV. It used similar hardware that was based on the Famicom (NES) with a custom ROM image for loading the data from the two Game Boys attached via cable and displaying the result on the screen. It is an ideal way to develop and test link-cable games on a much larger display. There exists multiple versions of this under a variety of names starting with the Demo Boy then Demo Boy 2 and finally the Demo Vision 5. Nintendo Demo Vision **Chris M Covell** has an excellent page on the DemoVision unit which seems like a newer version of the Demo Boy Cartridge ToolsGameboy Cartridge tools are used to write to writable cartridges known as flash carts or to check the cartridges for problems.Prototype Gameboy Cartridges As Gameboy cartridges contained the game on a ROM chip which is read-only by its nature, in order to create prototype cartridges you can replace the ROM chip with an rewritable data chip such as EEPROM and you have a cartridge ideal for testing! Nintendo sold boards with EPROM sockets that could be used for exactly this purpose, it was a standard gameboy cartridge but with a slot where the EPROM chip could be easily removed for re-programming, there was also a piece of hardware called a GANG writer that could write to multiple of these cartridges at once. It was also very common for developers to just create these themselves from retail games. DMG-MBC5-32M-R-FLASH (32Mb Rumble Flash cartidge) Nintendo sold special flash cartridges which had rumble support along with Memory Bank Controller 5 (MBC5) which were used for games such as Looney Tunes Collector: Martian Alert. Thank you to both @forestillusion and @Altomare3 for these excellent images of both the outide and inside of the cartridges.Enjoy! pic.twitter.com/pYSsMY0Eyp— Altomare (@Altomare3) July 17, 2021DMG-MBC1 MULTI CHECKER CARTRIDGE (DMG-Checker) The DMG-MBC1 Multichecker cartridge was the earliest of the official prototype cartridges sold by Nintendo and only supported Memory Bank Controller version 1 (MBC1) so it was limited to games that were under 2 MB of ROM and 32 KB of RAM, Dig Dug is one game that was developed using this cartridge 6. DMG FLASH GANG WRITER Rather the writing to the prototype cartridges one-by-one, which would be too time consuming as developers tended to send out multiple copies to the press (magazines etc) there was a tool known as the FLASH GANG WRITER where you could place the cartridges in and write the same ROM image to all of them. Duck (Dmg Universal ChecKer) The DMG Universal Checker or aptly named DUCK is a unit for quality control (QA) of the cartridges during the manufacturing process, a Game Boy cartridge is inserted into the socket and the machine calculates and compares the checksum of the ROM with a test cartridge, it also tests saving and loading from SRAM to check for any corruption errors 7. Third Party Development kitsGB Smart Development kit The GB Smart Development kit could be used by small studios or even individual developers to create games for the original Game Boy. However it was likely mainly used for piracy when sold to individual people and the development kit name was used very lightly. The development cartridge was known as the Smart Card which was 16 Mbit in size and not only contained standard chips such as Save Ram (SRAM) but also had the Rumble feature used in a small amount of games such as Pokemon Pinball 8. The files that were distributed with the development kit have been kindly uploaded by JakobAir here: GitHub - JakobAir/GB-Smart-Development-Kit: Files for the Gameboy Smart Development Kit will be placed here. I claim no authorization of these files. The manual has never been scanned so if you find one then please help the community and share a pdf if you have the ability! Codemasters OracEx-Codemasters employee DrTune posted his custom FPGA based Game Boy devkit used in 1992 to his twitter:Ha just came across pic of my \"Orac\" Game Boy dev board from 1992, used for all Codemasters GB games; 256K SRAM, PC interface. Old school FPGA. Big connector is optional logic analyzer port. Acid house smiley face b/c we did more than just hack hardware. pic.twitter.com/1zHhvED1fC— DrTune (@drtune) December 28, 2020Doctor GB XchangerThe Doctor GB Xchanger was primarily sold as a piracy device but could be used by consumers or even some small studios as a cheaper alternative to the official development kit. Game Boy Xchanger The wiki **videogamedevelopmentdevices.fandom.com** has an excellent page on the Doctor GB Xchanger References GB DEV FAQs ↩ IS CGB tool ↩ ↩2 WideBoy ↩ Wide Boy 64 ↩ Demo Vision ↩ DMG-MBC1 MULTI CHECKER CARTRIDGE ↩ Game Boy “DUCK” DMG Universal Dev ↩ GB SMART DEVELOPMENT KIT ↩ ", "excerpt": "This post covers all the hardware developers used to create games for the original Dot Matrix Game Boy (DMG) and Game Boy Color (GBC) and some were even used for early Game Boy Advance development. Developers used both official Nintendo development kits and some unofficial 3rd party devices to create...", "tags": ["gameboy","nintendo","devkit","hardware"], "image": "/public/images/GameBoy/Game Boy Development Hardware Devkit.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo Gamecube (Dolphin) Reverse Engineering", "url": "/gamecube", "content": "Welcome to our page dedicated to Gamecube reverse engineering! The Gamecube was a popular gaming console released by Nintendo in 2001, and has since become a beloved classic of the gaming world. If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to the right place.On this page, we’ve compiled a list of links to other pages that cover various topics related to Gamecube reverse engineering. Whether you’re interested in understanding the hardware architecture of the console, analyzing game code, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to.So grab your Gamecube controller, and get ready to dive into the exciting world of Gamecube reverse engineering!HardwareThe Nintendo Gamecube has fairly sophisticated hardware for the time, this was when Nintendo was still trying to compete with raw processing power. The hardware would then be used as a basis of both the Wii and Wii U consoles in the future.Retail HardwareRodrigo Copetti has an excellent in-depth article about the hardware architecture of the Nintendo Gamecube, it is a must read for anyone wanting to reverse engineer Gamecube games as you will need to know all about the low level architecture. Rodrigo Copetti's Gamecube Hardware Architecture The website by Rodrigo Copetti is required reading for any information you want to know about the Gamecube console hardware architecture. Development Hardware Nintendo Gamecube (Dolphin) Development Kit Hardware For information about Nintendo’s Dolphin development hardware check out this post. Unreleased HardwareIn China there were plans to release a version of the Gamecube with DVD playback functionality and additional security. This was to be a sequel to the iQue Player which was a Chinese only Nintendo 64 plug and play device. However half way through development the resources were moved to work on the Nintendo Wii instead. iQue Gamecube Leak (BB2) For information about iQue/BroadOn’s prototype Chinese Gamecube hardware check out this post. Gamecube GamesThe Nintendo Gamecube has an excellent library of games just begging to be reverse engineered, it is always a good idea to do some research before you start, this is where this section comes in as it deals with specific games.Games with Debug SymbolsIf you are interested in reverse engineering a Gamecube game, the first step is to find out if the game has its debug symbols available, this makes it much easier to reverse as all the functions will have nice friendly human readable names. Nintendo Gamecube Games with Debug Symbols Check out this post for a list of Gamecube games with debug symbols. Gamecube ExclusivesThe most valuable reverse engineering projects tend to be the platform exclusives that have never been re-released as these are the games that can benefit the most from enhancements on modern hardware.Wikipedia maintains a list of Gamecube exclusives - GameCube-only games - WikipediaPrototype GamesPrototype games are ideal targets for reverse engineering as many of them contain developer information inside them and some games never got a retail release, making them even more interesting! List of Nintendo Gamecube Prototypes - Hidden Palace Hidden Palace has the most complete list of released Gamecube Prototypes and Demos, check it out here. Games with Emulators ON GamecubeA few Gamecube games have emulator code built into them either as bonus content (Animal Crossing, Fight Night Round 2) or as the main game (Sonic Mega Collection).Here is a list of known games that have emulators built in: Fight Night Round 2 (uses an emulator called SNESticle to play Super Punch Out, ROM file is called SNS4Q0.471 on the Disc, same filename as seen in Nintendo Lot-Check Leaks)Fight Night Round 2The Gamecube game Fight Night Round 2 has a playable version of the SNES game Super Punch Out on the Disc called SNS4Q0.471. This file must have come from Nintendo as it matches the Nintendo Lot-check naming scheme that Nintendo uses internally.The cool thing about this is that the emulator was written by Icer Addis who was the co-creator of one of the first ever NES emulators known as NESticle. An easter egg of sorts can be found when looking at the strings inside the executable, they called the SNES emulator for gamecube SNESticle!Not only that but a project was launched to try to get other SNES ROMS to work with the emulator known as the The SNESticle Liberation Project which consisted of a Multi-ROM menu SNES Rom and a Python script to inject ROMS and put everything together (fn22snesticle.py).The devlog is a very good read and is available here: Devlog - The SNESticle Liberation ProjectThis drew the attention of Icer who decided to release the full source code for SNESticle (PS2 & Dreamcast):iaddis/SNESticle: SNESticle source code (circa ~2004)Game Engines for the Nintendo GameCubeBefore Unity and the modern Unreal Engine dominated the scene it was common for developers to create their own in-house game engine, or license a third party engine.Merkury engine by Krome Studios (in-house)Krome Studios used the Merkury Engine for many of its own titles, particularly on the GameCube and other last-generation systems. A programmer for Krome Studios, Tony Ball managed to get the engine running on the GameCube hardware only took a couple of weeks, with development running simultaneously with the PlayStation 2 version.Here are the games that used the Merkury Engine for the GameCube: Ty the Tasmanian Tiger (2002) - The first in the franchise and a flagship Merkury title. The Adventures of Jimmy Neutron: Jet Fusion (2003) - Also released on PS2. Ty the Tasmanian Tiger 2: Bush Rescue (2004) King Arthur (2004) Ty the Tasmanian Tiger 3: Night of the Quinkan (2005) The Legend of Spyro: A New Beginning (2006) - Developed by Krome for the GameCube, PS2, Xbox, and GBA.If you are interested in learning more we have a specific post about the Merkury engine: Krome Studios Merkury Engine The Merkury engine is a proprietary game engine developed by Krome Studios since at least 2001, known to run on PS2, PSP, Wii and with version 3 of the engine... Reverse EngineeringGameCube specific File FormatsWe have a specific post that covers all the file formats that can be found in gamecube games (or file formats used to store gamecube games) here: Nintendo Gamecube (Dolphin) File Formats Check out this post for a list of Gamecube file formats. All Posts 007 Agent Under Fire for Nintendo Gamecube Reverse Engineering Introduction Welcome to our page dedicated to the technical details of the Gamecube game 007 Agent Under Fire! If you’re a fan of this classic first-person shooter game, you might... ... Read More gamecube symbols debug reverseengineering games ATI Low Level Wii SDK Introduction In 2020 and 2021 numerous secret files have been leaked from Nintendo thanks to Zammis Clark. Included in these files were source code for a variety of Wii internal... ... Read More wii sdk leak gamecube Nintendo Gamecube (Dolphin) Development Kit Hardware AMC Dolphin Development Hardware (DDH) The earliest Gamecube development hardware available to game developers was known as the Dolphin Development Hardware or simply DDH for short. This system was sold... ... Read More gamecube devkit hardware Nintendo Gamecube Games with Debug Symbols If you are interested in reverse engineering a Gamecube game, the first step is to find out if the game has its debug symbols available, this makes it much easier... ... Read More gamecube symbols debug reverseengineering Nintendo Gamecube (Dolphin) File Formats Emulation File Formats The table below lists the relevant entries. Extension Description rvz Compressed ISO Format (Dolphin) iso Disc Image (Uncompressed) Formats Used on Disc The table below lists the... ... Read More gamecube fileformats The Simpsons Hit & Run Source Code Leak Introduction On the 21st August 2021 the full source code to the classic GTA clone staring The Simpsons was released online. This included both the C++ source code plus the... ... Read More ps2 xbox gamecube leak The Unexpected 2021 Nintendo Leak On the 20th July 2021 the Nintendo Leaks (aka Gigaleaks) continued after a long hiatus, the content was obtained by Zammis Clark and then leaked online by anonymous individuals. Files... ... Read More leak wii gamecube Nintendo Wii Diagnostic Disc Source Code In the Nintendo leak on 20th July 2021 an archive called DIAG4RVL.7z was released to the internet, this archive contains a CVS repository containing 3 different software development kits for... ... Read More wii sdk leak gamecube iQue Gamecube Leak (BB2) Introduction In 2020 and 2021 numerous secret files have been leaked from Nintendo thanks to Zammis Clark. Included in these files were documentation and source code for an unreleased console... ... Read More gamecube leak ", "excerpt": "Welcome to our page dedicated to Gamecube reverse engineering! The Gamecube was a popular gaming console released by Nintendo in 2001, and has since become a beloved classic of the gaming world. If you’re interested in learning more about the technical aspects of this console and how it works, you’ve...", "tags": ["gamecube"], "image": "/public/generated/placeholders/gamecube.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo Gamecube Games with Debug Symbols", "url": "/gamecube-debug-symbols", "content": "If you are interested in reverse engineering a Gamecube game, the first step is to find out if the game has its debug symbols available, this makes it much easier to reverse as all the functions will have nice friendly human readable names.Gamecube game executable can come in a number of different formats, one is the standard .DOL file (short for dolphin) and the other is the ELF which is a standard format for Unix based systems.If a Gamecube game disc has the elf file available then it is possible that it will have debug information embedded inside it, the easiest way to check is to look at the size or run the strings command on it.ELF FilesELF files can contain many debug symbols such as the function, variable and sometimes even file names.You can normally see the symbols by opening in a dissasembler such as Radare2 or IDA Pro.ELF Executables with Debug SymbolsThe following table lists all the known Gamecube games that contain ELF files with debug symbols embedded inside. Game Name Elf File Number of Symbols Genre Youtube 007 - Agent Under Fire Bond.elf 8,519 Action   007 - Everything or Nothing boot.elf 822 Action   Backyard Sports - Baseball 2007 (USA) Mpe.Gcn.Release.elf 4,702 Sport   Bakuten Shoot Beyblade 2002 - Nettou! Magne Tag Battle! (Japan) main.elf 1,921 Action   Beyblade VForce - Super Tournament Battle main.elf 2,207 Action   Big Air Freestyle LoadAndParseELF.elf 5,456 Sport   Black & Bruised GCNDefault.elf 3,762 ?   BloodRayne (United Kingdom) Bloodrayne.elf 4,340 Action   Blowout (USA) Blowout.elf 4,151 ?   Bratz - Rock Angelz (France) Bratz_NGC_M.elf 15,275 ?   Crash Bandicoot - The Wrath of Cortex (USA) crashwoc.elf 2,685 Platformer   Crash Bandicoot 4 - Sakuretsu! Majin Power (Japan) crashwoc.elf 2,684 Platformer   Cubix Robots for Everyone - Showdown (USA) CubixGameCube.elf 5,433 ?   Dark Summit (USA) mob2gr.elf 11,459 ?   Densetsu no Quiz Ou Ketteisen (Japan) main.elf 3,674 ?   Disney-Pixar Cars (USA) CarsGCN.elf 12,973 ?   Disney-Pixar Finding Nemo (USA) (v1.00) GCNemo.elf 5,562 ?   Disney-Pixar Ratatouille (France) ratsgc_m.elf 10,581 ?   Disney-Pixar The Incredibles - Rise of the Underminer in2gc_m.elf 13,876 Action   Disney-Pixar The Incredibles (USA) ingc_m.elf 13,931     Disney-Pixar Die Unglaublichen (The Incredibles) (Germany) (Disc 1) ingc_m.elf 13,931 Action   Disney’s Piglet’s Big Game (United Kingdom) Piglet.elf 7,951 Action   Disney’s PK - Out of the Shadows (USA) (En,Fr,De,It) RM_DLL.elf 7,372 ?   Disney’s Winnie the Pooh’s Rumbly Tumbly Adventure (USA) (En,Fr,Es) winnie.elf 8,392     Doshin the Giant DolphinDefault.elf 3,047 God Game   Duel Masters Nettou! Battle Arena (Japan) main.elf 2,306     Fairly OddParents, The - Breakin’ da Rules (USA) Gamecube.elf 13,828     Finding Nemo (United Kingdom) GCNemo.elf 5,600     Freedom Fighters (United Kingdom) startup_release.elf 16,664 Third-person shooter   Freestyle Metal X (USA) FMX_CUBE_Publisher.elf 5,836     Frogger Beyond Frogger.elf 4,561 Action https://www.youtube.com/watch?v=t0DptiBTWPI GoldenEye - Rogue Agent (USA) (Disc 1) GE2RDVD.ELF 20,654 FPS   Harry Potter and the Goblet of Fire (United Kingdom) gof_f.elf 19,843 (200MB!) Action   Hot Wheels - Velocity X (USA) HotWheels.elf 2,363     Hudson Selection Vol. 4 - Takahashi-Meijin no Boukenjima (Japan) huos.elf 2,298     Intellivision Lives! (USA) GCNDefault.elf 1,991     Interactive Multi-Game Demo Disk - July 2004 GCNDefaultD.elf 2,636 Demo   Jeremy McGrath Supercross World (USA) sx2002.elf 4,186 Sport   Kao the Kangaroo - Round 2 (USA) kao2gcnF.elf 8,201 Platformer   King Arthur (USA) Arthur.elf 8,259     Legend of Spyro, The - A New Beginning spyro06.elf 12,813 Platformer   Lemony Snicket’s A Series of Unfortunate Events (United Kingdom) main.elf 10,416 Platformer   Mario Smash Football MarioSoccerP.elf 7,879 Sport   Medal of Honor - European Assault (Germany) MOH4RDVD.ELF 17,815 FPS   Medal of Honor - Frontline (United Kingdom) Moh2UK.elf 4,778 FPS   Medal of Honor - Rising Sun MOH3RDVD.elf 9,941 FPS   Men in Black II - Alien Escape MiiB_GCN_rtl.elf 5,821 Action   Mission - Impossible - Operation Surma IMF_GC-Final.elf 17,258 Action   Monopoly - Mezase!! Daifugou Jinsei!! (Japan) GRMJ0001.elf 2,903 Board   Mortal Kombat - Deadly Alliance mk5gc_release.elf 5,864 Fighting   Namco Museum 50th Anniversary ffe.elf 4,979 Retro   Need for Speed - Underground (Player’s Choice) (United Kingdom) Speed.elf 10,162 Racing   Need for Speed - Underground 2 Speed.elf 13,870 Racing   Nickelodeon SpongeBob SquarePants - Creature from the Krusty Krab (United Kingdom) SpongeBob_ngc_mfb.elf 16,884 Action   Nickelodeon SpongeBob SquarePants - The Movie (United Kingdom) sb04gc_nm.elf 8,005 Action   Nickelodeon SpongeBob SquarePants in - Battle for Bikini Bottom sbpeM.elf 9,296 Action   Nickelodeon Tak 2 - Der Stab der Traeume (Germany) (Disc 2) BobTak2_German_Disc2.elf 1,187     Nickelodeon The Adventures of Jimmy Neutron - Boy Genius (United Kingdom) Jimmy.elf 8,375     Pac-Man World 3 (USA) PMA_GC_M.elf 16,619 Platfomer   Peter Jackson’s King Kong - The Official Game of the Movie jadegc_ia2cr.elf 6,033 Action   Scooby-Doo! Mystery Mayhem (United Kingdom) engine_ret.elf 5,849     Scooby-Doo! Unmasked engine_ret.elf 6,066     Spider-Man (Japan) SMGDevS.elf 9,711 Action   Star Wars - The Clone Wars Clonewars.elf 8,173 Action   Super Mario Strikers (Japan) MarioSoccerR.elf 8,350 Sport   SX Superstar Supercross.elf 7,552 Sport   Terminator 3 - The Redemption t3game_gc.elf 11,758 Action   Tetris Worlds (Japan) TWgr.elf 7,252 Puzzle   Top Gun - Ace of the Sky (Japan) GCNDefault.elf 2,866 Action   Top Gun - Combat Zones (USA) GCNDefault.elf 2,866 Action   TY the Tasmanian Tiger (USA) TY_REL.elf 7,701 Platformer   TY the Tasmanian Tiger 2 - Bush Rescue (USA) Ty2.elf 15,792 Platformer   TY the Tasmanian Tiger - Night of the Quinkan (USA) Ty3.elf 16,618 Platformer   UFC - Throwdown GCNDefault.elf 2,648 Fighting   UFC2 Tapout Final Spec (Japan) GCNDefault.elf 2,682 Sport   ZooCube (Japan) ZooCube.elf 8,167 ?   Link Maps (.MAP files)Many Interactive Demo Discs contain link maps which are files that the linker generates and contains the function names. Also in retail games such as Animal Crossing and Final Fantasy Crystal Chronicals.One good way of finding these is to do a string search of the GCM ISO files for “.text section layout”. Game Name Map File Number of Symbols Genre Youtube Animal Crossing (Australia) foresta.map and static.map ??? RPG   Bratz - Forever Diamondz (United Kingdom) Bratz_Gamecube Master Fast Build.MAP ??? ???   FIFA Football 2005 (United Kingdom) fifa_z.map ??? Sport   Final Fantasy - Crystal Chronicles dvd/map/stg009/game.MAP ? RPG   Hot Wheels - World Race (United Kingdom) HotwheelsFCDpal.MAP ? Racing   Jeremy McGrath Supercross World sx2002.MAP ? Sport   Legend of Zelda, The - The Wind Waker (Korea) f_pc_profile_lst.MAP plus others ?? Action   Mario Kart - Double Dash!! debugInfoS.MAP ?? Racing   Mario Smash Football MarioSoccerD.MAP, MarioSoccerP.MAP, MarioSoccerR.MAP, MarioSoccerZ.MAP ?? Sport   Nickelodeon Tak 2 - Der Stab der Traeume (Germany) (Disc 2) BobTak2_German_Disc2.MAP ?? ?   Pikmin build.MAP ?? God Game   Pikmin 2 demo in Multi-Game Kiosk Demo Disc 17 (USA) pikmin2?P.MAP ?? God Game   Scooby-Doo! Mystery Mayhem (United Kingdom) engine_ret.MAP ?? Action   Super Mario Sunshine marioEU.MAP ?? Platformer   Sims 2, The (USA) u2_ngc_debug.map ?? Simulation   UEFA Champions League 2004-2005 (United Kingdom) fifa_z.MAP ?? Sport   Ultimate Spider-Man symbolgc-final.MAP ?? Action   Zelda no Densetsu - Twilight Princess (Japan) frameworkF.MAP ?? Action   Prototype Games with Debug SymbolsPrototype games are even more likely to contain debug symbols as they are intended for either testing or journalistic usage, thus having the symbols available would help the developers fix bugs before the final retail release. The table below is an incomplete list of prototypes that have debug symbols, if you know any more please let us know! Game Name Map File Number of Symbols Genre Notes NFS Underground (Preview 10-09-2003 Console+ 26669 - 010) Speed.elf 9,604 Racing Uses SNSystems Library + Debugger Resident Evil 4 (Debug Build) Bio4.*.SYM 10,380+ Action Contains SYM files for the main executable & the REL overlay files (some RELs are stored inside DRS containers) - unknown what created the SYM files, but a parser is available. Other NotesThis section contains notes about other games not listed above.Pikmin 2Thanks to Nikki (@NWPlayer123) on Twitter we now know that the pikmin2?P.MAP file in the retail Pikmin 2 release is full of junk data, as Nintendo had a tool to scrub the debug map file but the file entry on the disk still remained.The good news is that there are 2 Demo Discs of Pikmin that contain a valid Pikmin 2 symbol map, as mentioned in this twitter thread by Nikki:note to self: the demo disc with the Pikmin 2 US symbol map is D78E01, matches about 96% of retail pic.twitter.com/Sbr05XKQvl— Nikki™ 🌹 (@NWPlayer123) July 13, 2021Nintendo Puzzle CollectionNintendo Puzzle Collection (Japan) contains an ARM executable for running on the GBA that has developer symbols in it called: ponagb2m_client.elf (Panel de Pon game?).", "excerpt": "If you are interested in reverse engineering a Gamecube game, the first step is to find out if the game has its debug symbols available, this makes it much easier to reverse as all the functions will have nice friendly human readable names. Gamecube game executable can come in a...", "tags": ["gamecube","symbols","debug","reverseengineering"], "image": "/public/N64/Gamecube games with debug symbols.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo Gamecube (Dolphin) File Formats", "url": "/gamecube-file-formats", "content": "Emulation File FormatsThe table below lists the relevant entries. Extension Description rvz Compressed ISO Format (Dolphin) iso Disc Image (Uncompressed) Formats Used on DiscThe table below lists the relevant entries. Extension Description .GSF Sound File .SNI Sound Include file (Source file) (007 Agent Under Fire) .ZSD Sound File .h4m Movie File .thp Movie File .mpc Movie File (007 Agent Under Fire) .bmd 3D Model .tgc Demo/Embedded GCM file .TGC File FormatDocumentation:Games which have TGC files (Mostly demos):The table below lists the relevant entries. Game Description Animal Crossing orest_Eng_Final_PAL50.tgc - Whats the purpose? Interactive Multi-Game Demo Disk - [September 2002-April 2006] Each demo is in its own .TGC file Resident Evil 4 Samplers Contains demos of other games such as zz_metroidprime2.tgc Star Wars - Rogue Squadron III - Rebel Strike (Demo) Contains demos of other games e.g 0_gladius_video.pal.tgc, zz_r3_kiosk.pal.tgc Pokémon Colosseum Bonus Disc (US Version) Contains pokedownload.tgc for sending the Wishmaker Jirachi. .FPK (FPack) File FormatMore information: http://www.emutalk.net/threads/33945-Naruto-fpk-formatGames which have FPK files:The table below lists the relevant entries. Game Description Bloody Roar - Primal Fury Many FPK files in a fpack directory Naruto http://www.emutalk.net/threads/33945-Naruto-fpk-format ", "excerpt": "Emulation File Formats The table below lists the relevant entries. Extension Description rvz Compressed ISO Format (Dolphin) iso Disc Image (Uncompressed) Formats Used on Disc The table below lists the relevant entries. Extension Description .GSF Sound File .SNI Sound Include file (Source file) (007 Agent Under Fire) .ZSD Sound File...", "tags": ["gamecube","fileformats"], "image": "/public/N64/Gamecube File Formats.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Game-specific reverse engineering posts", "url": "/games", "content": "This page collects all the posts that are related to reverse engineering a specific game rather than an entire console or platform.It starts with a curated set of notable game pages grouped by platform, then points to a few external deep dives that are worth studying, and finally ends with an automatically generated index of broader tagged pages.This makes it easier to browse the highlights first without losing the wider archive.Decompiled Retail Console GamesThis page maintains a comprehensive, curated list of retail console games that have been successfully reverse engineered and decompiled back into compilable source code (C/C++). It tracks the progress of major community projects across platforms like the Nintendo 64, GameCube, and PlayStation, including high-profile achievements such as Super Mario 64, The Legend of Zelda: Ocarina of Time, and Jak and Daxter. We have a specific post all about it here: Decompiled Retail Console Games This post contains either decompiled or disassembled source code projects for console games that were sold at retail stores. If you are interested to see officially released or leaked source... Retail Console Game Source code (C/C++)We have a specific page that serves as a directory for officially released or leaked source code of retail console games, specifically focusing on the official source code rather than disassemblies and decompilations: Retail Console Game Source code (C/C++) It is very rare that a commercial game releases its source code to the public, it is even rarer for that to be a console game, but there have been... Game Engines & MiddlewareGame engines provide the foundational logic for graphics, audio, and input, while middleware focuses on specific subsystems like physics (PhysX) or sound (FMOD). Our page explores the evolution of these tools, from proprietary in-house engines to commercial giants like Unity and Game Maker, and categorizes them by platform to aid in reverse engineering efforts. Introduction to Game Engines & Middleware Introduction to Game Engines & Middleware Game Engines are the foundation in which games are built, they contain all the logic to be able to show graphics, play audio, compute... Games with Debug SymbolsWe have a specific post that aggregates all our posts on games with debug symbols separated by console platform here: Debug Symbols in Retail Games (Console & PC) Introduction to Debug Symbols Finding Debug Symbols when reverse engineering a game is the equivalent of buying a Strategy Guide, all the secrets are unlocked which is awesome but it... Arcade GamesThis section collects our arcade game-specific posts:Batman Forever - The Arcade GameThis post covers the arcade version of Batman Forever, focusing on the game itself rather than the wider Midway arcade hardware family. Batman Forever - The Arcade Game (1996) As the name suggests Batman Forever is originally an Arcade Game that got ported to MS-DOS, the Playstation 1 and Sega Saturn by Iguana Entertainment (Acclaim Published). The original arcade... NES GamesThis section collects our NES game-specific posts and source code investigations:Super Mario BrosThis post covers reverse engineering work on the original Super Mario Bros for the NES, including analysis and tooling around one of the most studied 8-bit platformers. Let’s reverse Super Mario Bros (NES) Introduction This page will give a brief overview of how Super Mario Bros for the Nintendo Entertainment System (NES) works. This page wouldn’t have been possible without the excellent work... Home Alone 2This post covers the recovered Home Alone 2 NES source code and explains what survives in the archive for researchers interested in late-era commercial NES development. Home Alone 2 NES Source Code Home Alone 2 NES Source Code The Source Code for “Home Alone 2” was kindly released by Frank Cifaldi from GameHistoryorg (@frankcifald). Games on the same engine The same Game... External Deep DivesThis section highlights external reverse engineering breakdowns for specific games that are useful companion material alongside the internal posts above:The Final Fantasy Battle Engine: A Dissection of Physical AttacksDisplaced Gamers has an excellent video dissecting the underlying code, hidden math, and bugs governing physical attacks in the original NES Final Fantasy. The video explores how battle stats like accuracy, critical hit rates, and elemental weaknesses are processed in Assembly, revealing several programming oversights that heavily impact gameplay. It provides a fascinating look into early RPG mechanics and console game reverse engineering.Core Architecture: System Scope: Analysis of the physical attack mechanics within the Final Fantasy (NES/Famicom) battle engine. Code Footprint: The execution logic for a single physical attack consists of 781 total bytes (excluding called subroutines), responsible for animation, damage calculation, and variable reporting.Critical Engine Bugs & Logic Errors: Critical Hit Memory Fetch Error: When querying the ROM table for a weapon’s stored critical hit rate, the engine skips the instruction to load the stat. Instead, it writes the weapon’s index array ID into RAM. Consequently, later-game weapons (higher index table values) yield artificially high crit rates regardless of intended design. Ailment Application on Misses: Ailments run against 100 - Defender Magic Defense and an RNG check. However, the logic utilizes a non-resetting running tally of connected hits to permit ailment rolls. If hit #1 connects, the flag turns non-zero; if hit #2 misses completely, the engine still executes the ailment roll against the player because the flag remains non-zero. Elemental Weakness Inversion: When an enemy executes a physical attack carrying a status effect (e.g., Poison), the engine erroneously cross-references the player’s resistances against the enemy’s innate elemental weaknesses rather than the status type. (Example: Resisting Poison from a Scum enemy requires equipping Fire/Ice resistance, as the Scum is weak to Fire/Ice). Player Element Nullification: Weapons with elemental attributes (e.g., Flame Sword) fail to trigger elemental damage bonuses because the combat routine queries the player character’s element variable (which is nonexistent/null) instead of the equipped weapon’s variable. Stun/Sleep Accuracy Omission: When an attack target is under Stun or Sleep status, the attacker correctly receives a +25% attack power bonus. However, the logic jump bypasses the instruction to apply the attacker’s accuracy stat entirely, locking the base hit chance at a fixed 84% (168 base / 200).Game Boy GamesThis section collects our Game Boy game-specific posts and source code investigations:Pokemon Red and BlueThis post covers reverse engineering Pokemon Red and Blue on the Game Boy, including community reconstruction work and related historical material about the games’ development. Reversing Pokemon Red and Blue (Game Boy) Introduction The Pokemon Reverse Engineering Team (PRET) have managed to pull off a marvellous achievement, they have fully reverse engineered Pokemon Red and Blue back into Z80 assembly code 1.... Pokemon Original Source Code LeakThis post covers the leaked original Pokemon source material and explains what it reveals about the early Game Boy-era codebase and development process. Pokemon Original Source Code Leak On the 11th April 2020 the source code to the original generation of Pokemon games was released to 4chan as osrc.zip. This zip archive contained a password protected zip file... Zelda Link’s AwakeningThis post covers the leaked original The Legend of Zelda: Link’s Awakening Game Boy source code and the value of the archive for studying Nintendo’s handheld development workflow. Gigaleak - Original Zelda Links Awakening Source Code (DMG) The Zelda Links Awakening source code was released in the original Gigaleak inside dmg.7z, itself stored inside Other.7z. This part of the leak contains much more than a single source... Game Boy Color GamesThis section collects our Game Boy Color game-specific posts:Zelda Link’s Awakening DXThis post covers the Link’s Awakening DX source code materials, showing how the Game Boy Color revision differs from the earlier monochrome release. Zelda Links Awakening DX Source Code (CGB) The CGB.7z section of the Nintendo Gigaleak preserves Game Boy Color-era material for two projects: The Legend of Zelda: Link’s Awakening DX and Hamtaro 2. For Zelda, this archive is... Super Nintendo GamesThis section collects our Super Nintendo game-specific posts and source code investigations:F-ZeroThis post covers the leaked F-Zero source code and what it shows about early Super Famicom launch-era game development. Original F-Zero Source Code (Gigaleak) The Nintendo Gigaleak preserves a small but unusually useful F-Zero source archive under other/SFC/ソースデータ/FZERO. This is not just a loose dump of assembly files. It preserves the main game code,... Super Mario KartThis post covers the leaked Super Mario Kart source code and the surrounding development files that help document Nintendo’s Mode 7 racing workflow. Original Super Mario Kart Source Code (Gigaleak) The Nintendo Gigaleak preserves a very substantial Super Mario Kart source archive under other/SFC/ソースデータ/MarioKart. Unlike the F-Zero leak, this is not neatly split into Game and Tools. It looks much... Super Mario Collection / All-StarsThis post covers the source archive for Super Mario Collection / Super Mario All-Stars, including how Nintendo adapted earlier NES titles for the Super Nintendo. Original Super Mario Collection / All-Stars Source Code (Gigaleak) The Nintendo Gigaleak preserves a compact but unusually revealing Super Mario Collection source archive under other/SFC/ソースデータ/srd13-SFCマリオコレクション. This is the Japanese Super Famicom release better known in the West as Super... Star FoxThis post covers the leaked original Star Fox source code and the technical context around Nintendo and Argonaut’s early polygon pipeline. Original Star Fox Source Code (Gigaleak) The Nintendo Gigaleak preserves a compact but very revealing Star Fox source drop under other/SFC/ソースデータ/StarFox. Unlike the F-Zero leak, this one is not laid out as loose source folders from... Star Fox 2This post covers the leaked Star Fox 2 source code and the unfinished but historically important state of the project. Original Star Fox 2 Source Code (Gigaleak) The Nintendo Gigaleak preserves a much larger and messier Star Fox 2 workspace under other/SFC/ソースデータ/StarFox2. Unlike the original Star Fox drop, this one is not just a compact source archive.... Wild Trax / Stunt Race FXThis post covers the leaked source code for Wild Trax / Stunt Race FX, a useful case study for Super FX-powered racing technology on the SNES. Original Wild Trax / Stunt Race FX Source Code (Gigaleak) The Nintendo Gigaleak preserves a large Super Famicom source tree under other/SFC/ソースデータ/ワイルドトラックス. This is the Japanese Wild Trax project, better known in the west as Stunt Race FX. What makes... Yoshi’s IslandThis post covers the leaked Yoshi’s Island source code and the implementation details behind one of Nintendo’s most visually distinctive 2D platformers. Original Yoshi’s Island Source Code (Gigaleak) The Nintendo Gigaleak preserves a very large Yoshi’s Island archive under other/SFC/ソースデータ/ヨッシーアイランド. This is the Super Famicom codebase for Super Mario World 2: Yoshi’s Island, and it survives in a... The Legend of Zelda - A Link to the PastThis post covers the leaked A Link to the Past source code and its importance for understanding large-scale first-party Super Nintendo game development. Original The Legend of Zelda - A Link to the Past Source Code (Gigaleak) The Nintendo Gigaleak preserves a large Super Famicom Zelda source archive under other/SFC/ソースデータ/ゼルダの伝説神々のトライフォース. This is the Japanese game better known in the West as The Legend of Zelda: A Link... Development Art ArchivesThis section collects game-specific archive pages that focus more on art workspaces, asset pipelines, and development materials than on full source code releases:Pilotwings 2D Art WorkspaceThis post covers a recovered Pilotwings 2D art workspace, which is useful for studying Nintendo’s internal art production flow rather than the gameplay code itself. Pilotwings 2D Art Workspace (fly/flyman) The Nintendo Gigaleak preserves a separate Super Mario Kart art workspace under other/NEWS/テープリストア/NEWS_04/home/sugiyama/fly and home/sugiyama/flyman/, from Nintendo artist Tadashi Sugiyama. These directories are almost entirely art-side production material from the... SimCity SNES 2D Art WorkspaceThis post covers the SimCity SNES art workspace files, giving a narrower look at how project assets were organized during development. SimCity SNES 2D Art Workspace (SIM) The Nintendo Gigaleak preserves a separate SimCity SNES art workspace under other/NEWS/テープリストア/NEWS_04/home/sugiyama/SIM. Compared with the much broader Mario Kart CAR folder, SIM is smaller and more focused. It is almost... Star Fox 2 2D Art WorkspaceThis post covers a Star Fox 2 art workspace archive that complements the source-code page by showing more of the project’s asset-side workflow. Star Fox 2 - 2D Art Workspace (NEWS_04 Archive) Archive Source This article analyzes the Star Fox 2 2D art and graphics workspace preserved in the Gigaleak - specifically from the NEWS_04 archive, a 96 MB Nintendo NEWS workstation... Stunt Race FX 2D Art WorkspaceThis post covers a Stunt Race FX / Wild Trax art workspace archive, which helps document the content pipeline around a Super FX title. Stunt Race FX 2D Art Workspace (FX2) Archive Source This page is based on Gigaleak NEWS_04 home/sugiyama/FX2/ (41 files), from Tadashi Sugiyama’s workspace. Glossary FX2 - Wild Trax / Stunt Race FX UI-art folder. cpt - Cup/captain... Super Mario Kart 2D Art WorkspaceThis post covers the Super Mario Kart art workspace files, which are useful for understanding track and sprite production outside the main game code. Super Mario Kart 2D Art Workspace (CAR) The Nintendo Gigaleak preserves a separate Super Mario Kart art workspace under other/NEWS/テープリストア/NEWS_04/home/sugiyama/CAR. Unlike the main source tree, this directory is almost entirely art-side production material. It is a flat... Zelda Link’s Awakening 2D Art WorkspaceThis post covers the Link’s Awakening art workspace archive and adds asset-side context to the related Game Boy source code material. The Legend of Zelda Link’s Awakening - 2D Art Workspace (NEWS_04 Archive) Archive Source This article analyzes the Link’s Awakening 2D art and graphics workspace preserved in the Gigaleak - specifically from the NEWS_04 archive, a 96 MB Nintendo NEWS workstation backup.... GameCube GamesThis section collects our GameCube game-specific posts:007 Agent Under FireThis post covers reverse engineering work on the GameCube version of 007 Agent Under Fire, with attention to the game’s own binaries and assets. 007 Agent Under Fire for Nintendo Gamecube Reverse Engineering Introduction Welcome to our page dedicated to the technical details of the Gamecube game 007 Agent Under Fire! If you’re a fan of this classic first-person shooter game, you might... Nintendo 64 GamesThis section collects our Nintendo 64 game-specific posts and source code investigations:Super Mario 64This post covers Super Mario 64 reverse engineering, including tools, level work, and analysis tied to the best-known N64 decompilation effort. Super Mario 64 Introduction to Super Mario 64 Reversing & Modding The Game was made by Nintendo EAD and was released in Europe on March 1st, 1997. The development team consisted of 2... Mario Kart 64This post covers Mario Kart 64 specifically, gathering reverse engineering material around the game’s code, assets, and mechanics. Mario Kart 64 Introduction to Mario Kart 64 The Game was made by Nintendo EAD and was released in Europe on June 24th, 1997. The development team consisted of 8 programmers under the... Turok 64This post covers the official Turok Nintendo 64 source code archive and explains what it reveals about a major commercial western N64 production. Turok 64 Official Source Code Analysis Introduction to Turok 64 Game was made by Iguana Entertainment under Acclaim and released on March 4th 1997. The development team consisted of 9 programmers under the lead of Rob... PlayStation 1 GamesThis section collects our PlayStation 1 game-specific posts:Crash BandicootThis post covers the original Crash Bandicoot on PlayStation 1, including reverse engineering notes and development context around Naughty Dog’s early PS1 technology. Crash Bandicoot Introduction to Crash Bandicoot Crash Bandicoot was one of the first 3D Platform games that managed to deliver both quality gameplay and impressive graphics for its time. It was developed... Dreamcast GamesThis section collects our Dreamcast game-specific posts and source code investigations:Chicken RunThis post covers the recovered Chicken Run Dreamcast source code and what it shows about licensed late-era Dreamcast game production. Chicken Run Source Code Developed by Blitz Games (formerly known as Interactive Studios Limited) in 2000 as a cross platform action adventure game based on the movie with the same name. Throughout the engine... PlayStation Portable GamesThis section collects our PSP game-specific posts:Saints Row UndercoverThis post covers the PSP prototype of Saints Row Undercover, including its unusual release history and what can be learned from the surviving build. PSP Saints Row Undercover Officially Released Prototype Saints Row Undercover Also known as Saint Row - The Fall earlier in development, this is one of the rare few prototype games released by the developers themselves, in this... Multi-platform GamesThis section collects game-specific posts that span multiple retail platforms:The Simpsons Hit & RunThis post covers the Simpsons Hit & Run source code leak, which is relevant across multiple released platforms rather than belonging to a single console family. The Simpsons Hit & Run Source Code Leak Introduction On the 21st August 2021 the full source code to the classic GTA clone staring The Simpsons was released online. This included both the C++ source code plus the... PC GamesThis section collects our PC game-specific posts and source code investigations:Planet X3This post covers Planet X3, a modern MS-DOS strategy game whose tooling and technical design make it relevant to retro PC development research. Planet X3 (2019 MS-DOS game) Introduction PlanetX3 is a brand new game developed by YouTube 8-bit guy for MS-DOS and released in early 2019. The game was developed using crowd funding through Kickstarter 1. The... External Deep DivesThis section highlights external reverse engineering breakdowns for specific PC games that are useful companion material alongside the internal posts above:Deponia Magnet Puzzle Soft-Lock FixNathan Baggs has a detailed video breakdown about reverse engineering a persistent, game-breaking bug in the point-and-click adventure game Deponia. The investigation covers diagnosing a magnet puzzle soft-lock using tools like Ghidra, x64dbg, and RenderDoc to analyze memory and engine behavior. By discovering an embedded Lua debugger (mobdebug) and decompiling the game’s bytecode (LuaJit), the root cause-a failure to initialize condition states upon reloading-is identified and resolved via custom Lua code injection.Automatically Listed Game PagesThis final section is generated from site tags, so it acts as a wider catch-all index beyond the curated platform sections above: 007 Agent Under Fire for Nintendo Gamecube Reverse Engineering Introduction Welcome to our page dedicated to the technical details of the Gamecube game 007 Agent Under Fire! If you’re a fan of this classic first-person shooter game, you might... ... Read More gamecube symbols debug reverseengineering games Batman Forever - The Arcade Game (1996) As the name suggests Batman Forever is originally an Arcade Game that got ported to MS-DOS, the Playstation 1 and Sega Saturn by Iguana Entertainment (Acclaim Published). The original arcade... ... Read More saturn sega ps1 games Chicken Run Source Code Developed by Blitz Games (formerly known as Interactive Studios Limited) in 2000 as a cross platform action adventure game based on the movie with the same name. Throughout the engine... ... Read More dreamcast ps1 pc games sourcecode Crash Bandicoot Introduction to Crash Bandicoot Crash Bandicoot was one of the first 3D Platform games that managed to deliver both quality gameplay and impressive graphics for its time. It was developed... ... Read More ps1 games Debug Symbols in Retail Games (Console & PC) Introduction to Debug Symbols Finding Debug Symbols when reverse engineering a game is the equivalent of buying a Strategy Guide, all the secrets are unlocked which is awesome but it... ... Read More symbols debug games Decompiled Retail Console Games This post contains either decompiled or disassembled source code projects for console games that were sold at retail stores. If you are interested to see officially released or leaked source... ... Read More sourcecode games Exclusive Sega Saturn Games & Re-releases If you are interested in reversing a Sega Saturn game it can be useful to see what other platforms the game was released for, however if you don’t have a... ... Read More saturn sega games Home Alone 2 NES Source Code Home Alone 2 NES Source Code The Source Code for “Home Alone 2” was kindly released by Frank Cifaldi from GameHistoryorg (@frankcifald). Games on the same engine The same Game... ... Read More nes games sourcecode Behind the Scenes (Making Of) Playstation Games in PlayStation Underground PlayStation Underground List of known issues (CD-ROMs): PlayStation Underground Volume 1.1 - Making of the Twisted Metal 2 Commercial - Making of NFL Game Day 97 PlayStation Underground Volume 1.2... ... Read More documentary ps1 games Mario Kart 64 Introduction to Mario Kart 64 The Game was made by Nintendo EAD and was released in Europe on June 24th, 1997. The development team consisted of 8 programmers under the... ... Read More n64 games Mr Do! Source Code (Game Boy) Introduction This page documents the official release of the assembly source for Ocean Software’s Mr Do! port to the Game Boy. It focuses on what the code is doing (maps,... ... Read More gameboy games sourcecode PS2 Demo Disks with Debug Symbols This page is dedicated to listing Playstation 2 Demo Discs that contain developer debug symbols, either embedded inside the executable or as separate .map or .sym files. It was much... ... Read More ps2 symbols games PSP Saints Row Undercover Officially Released Prototype Saints Row Undercover Also known as Saint Row - The Fall earlier in development, this is one of the rare few prototype games released by the developers themselves, in this... ... Read More psp games Playstation Portable Games with Debug Symbols The Sony Playstation portable used encrypted executables known as EBOOT.BIN, these are basically just an encrypted ELF file and it is possible to decrypt them with the correct tools. Some... ... Read More psp symbols games Planet X3 (2019 MS-DOS game) Introduction PlanetX3 is a brand new game developed by YouTube 8-bit guy for MS-DOS and released in early 2019. The game was developed using crowd funding through Kickstarter 1. The... ... Read More dos pc dos sourcecode games Reversing Pokemon Red and Blue (Game Boy) Introduction The Pokemon Reverse Engineering Team (PRET) have managed to pull off a marvellous achievement, they have fully reverse engineered Pokemon Red and Blue back into Z80 assembly code 1.... ... Read More gameboy games assembly PS2 Games with Debug Symbols (UnStripped Binaries) Debug symbols are normally a rare treasure sought by reverse engineers from prototypes and beta versions of games, however in the early years of the PS2 it was common for... ... Read More ps2 symbols games Retail Console Game Source code (C/C++) Find out about leaked real retail game source code in this post ... Read More sourcecode games Let's reverse Super Mario Bros (NES) Introduction This page will give a brief overview of how Super Mario Bros for the Nintendo Entertainment System (NES) works. This page wouldn’t have been possible without the excellent work... ... Read More nes games Super Mario 64 Introduction to Super Mario 64 Reversing & Modding The Game was made by Nintendo EAD and was released in Europe on March 1st, 1997. The development team consisted of 2... ... Read More n64 games Turok 64 Official Source Code Analysis Introduction to Turok 64 Game was made by Iguana Entertainment under Acclaim and released on March 4th 1997. The development team consisted of 9 programmers under the lead of Rob... ... Read More n64 games sourcecode Wii Games with Debug Symbols Retail Wii Games with Debug Symbols The following table has all the known Wii games that have debug symbols in them, if you find any more please let us know!... ... Read More wii symbols games Wii U Games with Debug symbols (UnStripped Binaries) Wii U games with debug symbols A list of all the WiiU games that are known to have debug symbols are listed in the table below, eventually we want to... ... Read More wiiu symbols games Original Xbox Games with Debug Symbols Debug symbols left in games make reverse engineering almost a piece of cake, giving useful names to each of the functions in an executable and sometimes even full local variable... ... Read More xbox symbols debug games ", "excerpt": "This page collects all the posts that are related to reverse engineering a specific game rather than an entire console or platform. It starts with a curated set of notable game pages grouped by platform, then points to a few external deep dives that are worth studying, and finally ends...", "tags": ["games"], "image": "/public/generated/placeholders/games.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Ghidra Decompiler & Disassembler - Awesome List", "url": "/ghidra", "content": "Ghidra is the most advanced reverse engineering tool on the market, and best of all it is completely free and open source! Most of the content on RetroReversing will be using Ghidra going forward due to it being much more accessible than competitors such as IDA Pro.Introduction to GhidraThere is no better way to start out the hobby reverse engineering than learning Ghidra, it is an essential tool that takes much of the headaches out of reversing. Introduction to Decompiling C++ with Ghidra For a good introduction to decompiling with Ghidra check out this post. Console PluginsNintendo Game BoyDownload the Ghidra plugin from GithubNintendo Game Boy AdvanceDownload the Ghidra plugin from GithubAn excellent guide for decompiling GBA games using Ghidra and mGBA is available on StarcubelabsAnother excellent guide is on wrongbaudNintendo DSDownload the Ghidra plugin from GithubNintendo Entertainment SystemDownload the Ghidra plugin from GithubIt even has multiple builds setup for each Ghidra version via Github Workflows!Note that there was another older Ghidra plugin called Ghidra-Nes-Rom-Decompiler-Plugin however it failed to build against latest Ghidra (11.1.2).Super NintendoThere is only one Ghidra plugin for SNES but it is currently not under active development you can get it from GithubNintendo 64Nintendo 64 games can be slightly harder to reverse due to everything being bundles as one large ROM image containing all the code and assets used in the game. Luckily there are a few tools that can help, such as the Reversing Emulator and a N64 Loader for Ghidra. N64 Decompiling with Ghidra If you are interested in Decompiling a Nintendo 64 game with Ghidra check out this post. GamecubeDownload the Ghidra plugin from GithubNote that to build the GameCubeLoader you will need to have gradle version 7 or below installed otherwise you will get an error similar to:FAILURE: Build failed with an exception.* Where:Build file './Ghidra-GameCube-Loader/build.gradle' line: 63* What went wrong:A problem occurred evaluating root project 'GameCubeLoader'.> Adding a Configuration as a dependency is no longer allowed as of Gradle 8.0.On Mac OSX you can install an older version of Gradle using brew:brew install gradle@7WiiA guide for using Ghidra on Wii games is available on WiiBrewSega Master System/Game gearDownload the Ghidra plugin from GithubSega Mega Drive/GenesisDownload the Ghidra plugin from GithubSega SaturnDownload the Ghidra plugin from GithubSega DreamcastDownload the Ghidra plugin from GithubAlso for GDI support in Ghidra: GithubOriginal XboxDownload the Ghidra plugin from GithubXbox 360Download the Ghidra plugin from GithubPlayStation 1Download the Ghidra plugin from GithubAlso for a guide for using Ghidra for PS1 reversing: tokimeki-memorialPlayStation 2Download the Ghidra plugin from GithubPlayStation 3There are a few useful script for working with PS3 executables on GithubIntroduction to Ghidra: Modding and Reverse Engineering PS3 Gamesbordplate provides an in-depth introduction to using Ghidra for game reverse engineering, demonstrating the process by adding multiplayer to the PS3 port of Ratchet & Clank.The video covers setting up Ghidra for PowerPC architecture, identifying game functions like spawnMoby through string analysis, and injecting custom C++ code to hook game logic and implement networking.PlayStation PortableDownload the Ghidra plugin from GithubRecommended PluginsWhile Ghidra has a large number of features built in, there are a number of features missing that are thankfully available due to community plugins, this section will cover some of the most useful for game reversing.CodeCutCodeCut allows a user to assign functions to object files in Ghidra, and then interact with the binary at the object file level. Functions are assigned to object files by setting the Namespace field in the Ghidra database. DeepCut attempts to establish initial object file boundaries which the user can then adjust using the CodeCut Table window.https://github.com/jhuapl/codecutGhidrAssist Project: LLM Integration for GhidraGhidrAssist is a powerful extension that integrates Large Language Models (LLMs) directly into the Ghidra reverse engineering workflow. The tool supports both local and cloud-based AI providers (such as OpenAI and Ollama) to facilitate tasks like code explanation, refactoring, and vulnerability detection. Uniquely, it features an ‘Agentic Mode’ utilizing the ReAct pattern, allowing the AI to autonomously plan and execute investigation steps within the binary. GhidrAssist: AI Assistance for Ghidra GhidrAssist is a comprehensive Ghidra extension that leverages LLMs for tasks like code explanation, interactive chat, and autonomous binary analysis using agentic reasoning. Ghidra decompiler macrosWHen using the decompiler Ghidra spits out code which uses a number of macros which are not immediately obvious of their function, we provide some of these below with our recommendation of an easier to read version.CONCAT11(x, y)In Ghidra, the CONCAT11(x, y) operation combines two 8-bit values (x and y) into a single 16-bit value. The operation is defined as:#define CONCAT11(x, y) = (((uint16_t)x) << 8) | ((uint8_t)y)When cleaning up the decompiled code we suggest using the following replacement as it is more explicit about the purpose:// MergeBytesTo16Bit - combines high and low bytes into a single 16bit value#define MergeBytesTo16Bit(highByte, lowByte) = (((uint16_t)highByte) << 8) | ((uint8_t)lowByte)All Ghidra Posts Introduction to Decompiling C++ with Ghidra Introduction This tutorial series will guide you through the basics of decompiling a C++ executable, from setup all the way to reversing C++ classes. The video tutorial is created by... ... Read More introduction ghidra N64 Decompiling with Ghidra Importing a Nintendo 64 ROM Download and Install Ghidra Before following the steps on this post please make sure you have a working Ghidra environment setup. So you should be... ... Read More introduction tutorial n64 ghidra Reversing Engineering a NES Game With Ghidra Introduction This page walks you through using Ghidra to reverse engineer NES ROMs using the Ghidra-Nes-Rom-Decompiler-Plugin. This plugin currently only supports a handful of the most common mappers but it... ... Read More nes ghidra ", "excerpt": "Ghidra is the most advanced reverse engineering tool on the market, and best of all it is completely free and open source! Most of the content on RetroReversing will be using Ghidra going forward due to it being much more accessible than competitors such as IDA Pro. Introduction to Ghidra...", "tags": ["ghidra","tools"], "image": "/public/generated/placeholders/ghidra.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Introduction to Decompiling C++ with Ghidra", "url": "/intro-decompiling-with-ghidra", "content": "IntroductionThis tutorial series will guide you through the basics of decompiling a C++ executable, from setup all the way to reversing C++ classes.The video tutorial is created by James Tate over on his excellent YouTube channel, and it is highly recommended that you subscribe here: James Tate - YouTube.Download and Run GhidraThe first step, of course, is to download Ghidra if you haven’t already, which you can do from the official site: Download Ghidra Download Ghidra from the Official Site At the time of writing this tutorial, the version of Ghidra was 10.2.3.You will also need a Java Development Kit (JDK) version 17+, which you can download from the AdoptOpenSDK official site: AdoptOpenJDK - Open source, prebuilt OpenJDK binaries.You can now run Ghidra from the extracted folder by running the main script from bash (or double-clicking on it):./ghidraRunIt may ask you for your JDK path. Enter where you installed your OpenJDK 1 like so:******************************************************************JDK 17+ (64-bit) could not be found and must be manually chosen!******************************************************************Enter path to JDK home directory: If you already hava Java installed and just need to find the JDK home directory you can execute the following:> which javac # returns location of the java compiler> javac -version # returns the version of the java compilerNote that on MacOSX it installed to: /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/HomeCreate a New ProjectFirst of all, you need a project to start reverse-engineering a binary executable. To do this, use File -> New Project.Select Non-Shared project, give it a name such as Example and click Finish.Obtaining Your Binary Executable to ReverseTo follow along in this tutorial, you can either compile the sample code provided or download the pre-compiled executables.Both are available on James’s GitHub repository: GitHub - james-tate/ghidraExampleSource.Note that there are two pre-compiled executables in this repository: one is stripped (which means it doesn’t have any debug symbols) and the other is standard.You can use the compiler of your choice as long as it supports C++. So, if you have a special compiler for PS2/Dreamcast/Xbox/Gamecube, etc., feel free to use that. But bear in mind that importing executables for those systems will require a third-party plugin known as a loader.Import Your Binary ExecutableYou can import a file into Ghidra very simply with: File -> Import File. Find your executable file that you built with your C++ compiler.This will open the import dialog. In this tutorial, we also want to load in the external libraries. This makes it easier to reverse engineer, as you can swap between the main executable and the libraries really easily in Ghidra. 2To do this, click “Options” and set the Library Paths in the dialog.It will show the Import Results dialog with a lot of interesting information it found about the binary.Now finally double click on the example executable to unleash the Ghidra!It will now start importing the file and ask you if you want to analyze it. Select “Yes” and keep the default settings.How to Find the Main FunctionIf you have symbols, you can use the Navigation -> Go To... menu and type “main”. But if you don’t have symbols (e.g you used the stripped version), then we will need to find it ourselves.To find it manually, go to the .text section, and it will take you to the entry function. If you are using the same example as the video tutorial, then you will have a __libc_start_main function, and its first parameter is a function pointer to the main function.If you are using a different executable or compiled with a different compiler, this can be set up differently. But entry will call main somewhere, so it may require a bit of debugging with a debugger such as gdb or an emulator’s built-in debugger.When you have found what you believe to be the main method, right-click on the auto-generated function name, and select “Rename Function”.Decompile the Main FunctionOne of the main advantages of Ghidra is its free out of the box decompiler, now that you have found the main function it is easy to decompile it by going to Window -> Decompile.If you have debug symbols in the executable then it will look very similar to the original source:Using Structures in GhidraIn this section, we will learn how to use structures in Ghidra by applying them to data and navigating through the program using cross-references. We will also learn how to change the function signature to improve data presentation and how to create an array and apply it to a global offset 3.Setting Up Structures in GhidraBefore we can use structures in Ghidra, we need to set them up. To do this, we can follow these steps: Open the program in Ghidra and go to the Data Type Manager: Create a new structure and name it: Add fields to the structure and set their data types and offsets. Save the structure. Once we have set up the structure, we can apply it to data by following these steps: Highlight the data and right-click. Choose “Data Type” and select the structure we created. Click “Apply” to apply the structure to the data.Note that if you get something similar to:yourStructName.field0x4._0_1_Then this means that at offset 0x4 in the struct we have an undefined field for the structure.There is also a short cut for doing this directly from the decompile view by right clicking and selecting “Auto Create Structure”.Creating Arrays and Changing Function SignaturesNavigating through the Program with Cross-ReferencesTo see where the global structure or function is being used, we can go to the listing view and look at the cross-references. The cross-references show us everywhere in the program that is referencing that particular global variable. We can double-click on the cross-reference to quickly navigate to that location in the program.To navigate through the program using cross-references, we can follow these steps: Go to the listing view and look for the cross-references. Click on the cross-reference to go directly to the function. Note the ‘R’ or ‘W’ beside the Cross Reference indicating whether the function Reads or Writes to it.Changing Function Signatures and NamingTo change the function signature in Ghidra, we can follow these steps: Highlight the function and right-click. Choose “Edit Function Signature”. Change the data type to the correct type (in this case, a global structure pointer). Click “OK” to save the changes.Creating ArraysWe can also use Ghidra to create arrays. To do this, we first need to identify the size of the elements in the array. In our example, we can see that the size of each element is 4 bytes. We can then right-click on the global variable and select “Create Array”. We can then specify the number of elements we want to create, making sure not to create too many and overwrite existing data.To create an array in Ghidra, we can follow these steps: Highlight the data and right-click. Choose “Data Type” and select “Create Array”. Choose the number of elements and the data type. Click “OK” to create the array.Analyzing and Identifying C++ Classes in GhidraFollow these easy steps to analyze and identify classes in Ghidra.Step 1: Identify C++ Instance creation logicIn the video the instructor show this code in the decompile window:ppcVar1 = operator.new(0x14);FUN_000111f4(ppcVar1);(***ppcVar1)(ppcVar1, ranNum);(**(*ppcVar1 + 0xc)) (ppcVar1, ranNum & Oxffff);Take a close look at the code and try to identify the class constructor and virtual function calls. This will help you understand the class structure better.The variable ppcVar1 can be renamed to this as it represents the this pointer of the class that was created with operator.new.Note that operator.new only appears if you have added the external libC library that it was compiled with to the project.The line FUN_000111f4(ppcVar1); is most likely a constructor call as it comes directly after the new call and also takes in the this pointer.Step 2: Create a class in GhidraNow that you have a better understanding of the code, let’s create a class in Ghidra: Edit the constructor function signature and select the calling convention as thiscall and save. Now when you right-click on the first parameter to the constructor function you can choose “Auto Create Class” to create the class. Give the auto-generated class a more meaningful name.Step 3: Give your class members meaningful namesTake some time to identify the data types of the class members. Once you know what each member is, update their names to make your code easier to understand.Step 4: Set up the virtual table for the base classYou will notice that the constructor calls a function at the start, this is the constructor for the base class.If you click on the PTR___cxa_pure_virtual_000117ec it will take you to the listing view where it shows three other virtual functions:It’s time to create a structure to represent the VTable for the Base class: Create a new structure (New -> Structure) called “BaseVtable” with a virtual function. Add the other virtual functions in the same way (func *) Now do the same for the Derived class as it will override some of the virtual functionsIf you click on PTR_FUN_000112a8+1_000117c you will be taken to the listing view with 6 functions listed:You can change these all to __thiscall as they are all the functions that will go into the VTable.DestructorsIn this tutorial, we will learn how to analyze a derived class in C++ and rename its functions for better understanding. We will start by setting up the derived class and then analyze its functions one by one.Detecting DestructorsIf we go through all of our virtual functions in the VTable you will eventually find the Destructor for the class, which calls operator.delete (if you have the libc library). Set it to a __thiscall Rename them to a suitable deconstructor name ~ClassNameDestructorDerived Class ConstructorsIn this tutorial, we’ll explore a derived class constructor and its associated members. We’ll also create a virtual table pointer for better understanding of the virtual function calls.Analyzing the Derived Class ConstructorThe derived class has the following decompilation after setting most of the variable names:/* DISPLAY WARNING Type casts are NOT being printed */void __thiscall Nest::Nest(Nest *this){ bool bVar1; char *pcVar2; bool bVar3; char *pcVar4; char *local_10; char *local_c; *&this-vptr = &NestVtable; pcVar2 = malloc(0x20); this->hashsub1 = pcVar2; pcVar2 = malloc(0x20); this->hashSub2 = pcVar2; puts(\"Creating Nest Object\"); this->0x1337 = 0x1337; this->hash = \"8689d701c21f91c4085f08d9a411c629\"; local_18 = this->hashsub2; local_c = this->hashsub1; bVar3 = false; while (bar1 = bVar3, *this->hash != '\\0') { pcVar4 = this->hash; this->hash = pcVar4 + 0x1; pcVar2 = local_c + 0x1; *local_c = *pcVar4; bVar3 = bVar1 ^ 0x1; local_c = pcVar2; if (bVar1) { *local_10 = *this->hash; local_10 = local_10 + 0x1; local_c = peVar2; } } return;)C++ Classes Stack and Global ClassesGlobal classes are setup before the main function is even called in a function called init.Ghidra Shared Library Scripting and Headless AnalysisReverse engineering on shared libraries can be a time-consuming task, especially when dealing with embedded systems. In this tutorial, we will explore the tools and capabilities available in native Linux, as well as the scripting interface and headless analysis tool that Ghidra offers. We will use a nonsensical example to show how to use Ghidra’s headless analysis tool to scan multiple shared libraries in order to speed up your analysis.PrerequisitesBefore starting, make sure that you have the following tools installed on your system: ldd - to list shared library dependencies objdump - to display information about object files GhidraYou will also need a set of shared libraries to work with. You can download the example libraries from the author’s GitHub page.Analyzing Shared LibrariesUsing ldd and objdumpWe can use the ldd command to list the shared library dependencies for a given binary. For example, running ldd <binary> will show which shared libraries the binary will try to pull in to execute.We can also use objdump to display information about object files. For example, running objdump -T <binary> will show the exported symbols from the binary.Using GhidraTo use Ghidra for reverse engineering shared libraries, we first need to load the shared libraries into the project. We can do this by selecting “File > Import > External Libraries” and then selecting the shared libraries we want to load.We can then use Ghidra to analyze the shared libraries. For example, we can click on a function in the binary and Ghidra will automatically switch to the location of where that function lives inside of the shared library.However, if we have hundreds of binaries or shared libraries to analyze, this process can be time-consuming. In such cases, we can use Ghidra’ headless analysis tool and scripting interface.Using Ghidra’ Headless Analysis Tool and Scripting InterfaceTo use Ghidra’ headless analysis tool, we need to create a python script using the python Ghidra FlatProgramAPI to perform our analysis. Here, we will create a script to extract the names of objects created by calling the setname function:instructions = currentProgram.getListing().getInstructions(1)for instruction in instructions:\tmnemonic = instruction.getMnemonicString()\tif mnemonic == \"CALL\":\t\tfuncAddress = instruction.getOpObjects(0)[0]\t\tfunc = getFunctionContaining(toAddr(funcAddress.getOffset()))\t\tcallingFunc = getFunctionContaining(instruction.getAddress())\t\tif func is not None:\t\t\tif func.getName() == \"setName\":\t\t\t\tinst = instruction.getPrevious()\t\t\t\tinstAddr = inst.getAddress()\t\t\t\twhile(getFunctionContaining(instAddr) == callingFunc ):\t\t\t\t\tnumOps = getInstructionAt(instAddr).getNumOperands()\t\t\t\t\tfor i in range(numOps):\t\t\t\t\t\tfor op in getInstructionAt(instAddr).getOperandReferences(i):\t\t\t\t\t\t\tif op.getReferenceType().isData():\t\t\t\t\t\t\t\tdata = getDataAt(op.getToAddress())\t\t\t\t\t\t\t\tif data is not None:\t\t\t\t\t\t\t\t\tif data.getDataType().toString() == \"string\":\t\t\t\t\t\t\t\t\t\tprint \"Found name of the {}() to be {} in {}\".format(\t\t\t\t\t\t\t\t\t\t\tcallingFunc, \t\t\t\t\t\t\t\t\t\t\tdata,\t\t\t\t\t\t\t\t\t\t\tcurrentProgram)\t\t\t\t\tinst = inst.getPrevious()\t\t\t\t\tinstAddr = inst.getAddress()This script gets a list of all the instructions starting at the first instruction, then goes through each of those instructions and gets the mnemonic string. We only want it to print out the string whenever it’s a CALL. We then get the address in which we are making a call to and walk backward from this call to get each instruction until we find an instruction that is loading a string. We print out that string value.You can execute this script by importing it in the Ghidra Script Manager.We also use this script with the analyzeHeadless tool to automate our analysis. For example, we can run the following command:./analyzeHeadless $(pwd) names --import $(pwd)/*.so -recursive -postScript my_script.pyBinary Diffing with GhidraReferences Software Reverse Engineering with Ghidra – Setup and Installation - YouTube ↩ Software Reverse Engineering with Ghidra – How to import files and get started - YouTube ↩ Software Reverse Engineering with Ghidra – Creating Structures - YouTube ↩ ", "excerpt": "Introduction This tutorial series will guide you through the basics of decompiling a C++ executable, from setup all the way to reversing C++ classes. The video tutorial is created by James Tate over on his excellent YouTube channel, and it is highly recommended that you subscribe here: James Tate -...", "tags": ["introduction","ghidra"], "image": "https://i.ytimg.com/vi/4v8WkHmSFUU/sddefault.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "N64 Decompiling with Ghidra", "url": "/n64-decompiling", "content": "Importing a Nintendo 64 ROMDownload and Install GhidraBefore following the steps on this post please make sure you have a working Ghidra environment setup.So you should be able to run the script ghidraRun (contains .bat on windows) and it should start up Ghidra.Download the LoaderGhidra doesn’t support Nintendo 64 ROMS out of the box, presumably because not a lot of malware was written for the N64 and thus the NSA would never need one.Luckily a user known as Warranty Voider has created a loader module which enables us to import N64 ROMS like any other executable 1.You can find it here:GitHub - zeroKilo/N64LoaderWV: Ghidra Loader Module for N64 ROMsOn the GitHub page you need to either select clone or Download as zip, we would suggest just downloading the zip for now.You only need to clone if you are planning on contributing, but even then you would probably fork first and then clone.Import a ROM fileFind a .z64 file and import it into the project, it should come up as “N64 Loader by Warranty Voider”, but if it comes up as “binary” then it has not been installed correctly.If the N64 Loader option doesn’t appear for you then you probably don’t have JDK 12 or higher, you can either install JDK12 or build the plugin yourself on jdk11 which is what I did and works just fine :)Detecting N64 API signaturesAfter importing the game into Ghidra you will notice that all the functions have default names that start with: FUN_.These names are not very helpful and we know that the games were compiled with a version of the Official Nintendo 64 SDK, so if we could find those libraries in the binary then we can give them useful names and help start solving the puzzle.Downloading pre-generated Signature filesOver on AssemblerGames there is a pack of Signature Files for N64 SDK libraries. You can think of these as a sort of regular expression for compiled function code. It is not always accurate but it is a great start, you can download them from assembler games HereUsing IDA Pro’s Signature files with ApplySigAfter downloading you will notice that these were created for the competing Disassembler called IDA Pro. So in order to open them in Ghidra we need a plugin, the plugin we are looking for is called ApplySig.py.However currently the plugin ApplySig.py doesn’t work with the N64 Loader due to the addresses as it gives the following error:java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: Invalid address 0x80000450LIn order to get ApplySig to work you need a patch to ApplySig from user celophi  which is available here: Update ApplySig.py by celophi · Pull Request #7 · NWMonster/ApplySig · GitHubTo run it you need to put the script in your home/ghidra_scripts folder and run the “Script Manager” tool, select the checkbox beside ApplySig then click the green run icon.It will then ask for the *.sig file to open, make sure to select one of the sig files that you downloaded earlier 2.Importing N64 TypesIf you have a version of the N64 SDK then you can use the Parse C Source feature of Ghidra to automatically import structs/classes/defines etc from C Header files. This can save a lot of time from creating them all manually.If there are any errors with the parsing of the C files then you will need to locate the generated file called: CParserPlugin.out. Normally it is generated in the current users home directory so you can run:```cat ~/CParserPlugin.out—References N64 ROM Decompiling With Ghidra - N64LoaderWV - YouTube ↩ Assembler Games N64 Signatures (Wayback Machine) ↩ ", "excerpt": "Importing a Nintendo 64 ROM Download and Install Ghidra Before following the steps on this post please make sure you have a working Ghidra environment setup. So you should be able to run the script ghidraRun (contains .bat on windows) and it should start up Ghidra. Download the Loader Ghidra...", "tags": ["introduction","tutorial","n64","ghidra"], "image": "https://i.ytimg.com/vi/3d3a39LuCwc/hqdefault.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Gigaleak - SNES Source Code Leak", "url": "/gigaleak", "content": "On 24 July 2020, a large Nintendo archive was uploaded online and quickly became known as the Gigaleak.It was not one single neat source drop.It was a mixed archive of ROMs, source trees, boot ROM repositories, internal tools, and later CVS/Subversion backups.Uploaded FilesThese were the archive files uploaded on 4chan /g/ on 24 July 2020, the day the Gigaleak was leaked: other.7z - The broadest archive, containing DMG, CGB, SFC, lot-check, and boot ROM material agb_bootrom_trunk.zip - Extracted latest trunk snapshot of the AGB boot ROM repository cgb_bootrom_trunk.zip - Extracted latest trunk snapshot of the CGB boot ROM repository pokemon-checkout.7z - Pokemon-related source/material netcard.7z - Material for a cancelled Game Boy Advance peripheral 20100713cvs_backup.tar.7z - CVS repository backup with later Nintendo projectsThis page will cover each of these files, linking out to specific posts for each to dive into the details.The next day its sequel, often called Gigaleak 2, followed with much more Nintendo 64 material.Other (other.7z)The archive mysteriously named other.7z is one of the most interesting parts of the leak because it mixes game source trees with internal repositories and support material.It contains these major sub-archives: agb_bootrom.zip - Subversion repositories for both the Game Boy Advance and Game Boy Color boot ROM projects CGB.7z - Game Boy Color Source Code for Zelda and a build of Hamtaro 2 dmg.7z - Original Game Boy Source Code for Zelda Famicom_NES.7z - Full set of official JP/USA Famicom/NES ROMS (Lot Check) NEWS.7z - A smaller archive with SFC-adjacent material and logs SFC.7z - SNES Source CodeOriginal Game Boy Source Code for The Legend of Zelda Links Awakening (dmg.7z)The archive dmg.7z contains the source code for the original version of The Legend of Zelda Links Awakening. Gigaleak - Original Zelda Links Awakening Source Code (DMG) For more information check out this post. Game Boy Color Source Code for The Legend of Zelda Links Awakening DX (CGB.7z)The archive CGB.7z contains the source code for the Game Boy Color game The Legend of Zelda Links Awakening DX and pre-build ROM images of Hamtaro 2. Zelda Links Awakening DX Source Code (CGB) For more information check out this post. Famicom (NES) Lot Check ROMS (Famicom_NES.7z)We have a post covering the Full set of official JP/USA Famicom/NES ROMS released in the Famicom_NES.7z archive along with other LotCheck releases: Nintendo Lot Check ROM Leak For more information on the Famicom Lot Check ROMS check out this post. Super Nintendo Source Code (SFC.7z/ソースデータ)Contains the uncompiled raw source code for a number of Super Famicom (SNES) titles. In the leak, this codebase is preserved both as the SFC.7z archive and as a fully unzipped other/SFC/ソースデータ (Source Data) working directory.We have dedicated deep-dives exploring the leaked source code and assets for each of these massive titles: Original Star Fox Source Code (Gigaleak) Explore the Star Fox 1 & 2 internal source code and 3D tooling here. Original Yoshi’s Island Source Code (Gigaleak) Explore the Yoshi’s Island (ヨッシーアイランド) source code here. Original The Legend of Zelda - A Link to the Past Source Code (Gigaleak) Explore the Legend of Zelda: A Link to the Past (ゼルダの伝説神々のトライフォース) source code here. Original Super Mario Kart Source Code (Gigaleak) Explore the Super Mario Kart source code and original level editor here. Original Wild Trax / Stunt Race FX Source Code (Gigaleak) Explore the Stunt Race FX / Wild Trax (ワイルドトラックス) source code here. Original F-Zero Source Code (Gigaleak) Explore the F-Zero prototype source code here. Original Super Mario Collection / All-Stars Source Code (Gigaleak) Explore the Super Mario All-Stars (マリオコレクション) source code here. One small provenance detail is easy to miss here.While the primary unzipped source directories live under other/SFC/ソースデータ, three of these source trees-F-Zero, Star Fox 2, and Super Mario Collection (srd13-SFCマリオコレクション)-also survive duplicated inside other/NEWS.So far this NEWS material looks identical to the other/SFC/ソースデータ/ versions rather than a different branch, but it is still useful because it shows these exact snapshots were also present concurrently in a Sony NEWS-side working environment.NEWS Workstation Material (other/NEWS)The NEWS.7z archive is smaller and messier than SFC.7z, but it still preserves some useful workstation-side context.As mentioned above, the F-Zero, Star Fox 2, and Super Mario Collection source trees also appear again here as exact copies, confirming they shared the same workstation environment snapshot. Inside other/NEWS/FZERO, the Game and Tools folders reappear, and the folder is even duplicated as other/NEWS/FZERO/FZERO. That does not currently seem to add any new F-Zero content, but serves as an additional preserved copy of the same archive.Beyond the source trees, the NEWS.7z archive also contains a テープリストア (tape-restore) directory holding seven workstation backup snapshots in .tar format, plus a manifest file. These appear to be uncompressed mid-development system backups from around 2014:Tape Archive Backups (テープリストア)The table below lists the relevant entries. Archive Size Entries Contents NEWS_02.tar 12M 187 System logs and user configs (.net, .cshrc, .login, .logout, mail profiles) and some compressed ROMs inside emails NEWS_04.tar 96M 5,309 Mixed graphics workstation: 2,297 .BAK, 991 .SCR, 876 .CGX, 431 .COL, 266 .OBJ, 108 .MAP; includes late Star Fox 2 art, Zelda/GB-Zelda branches, confirmed Super Mario Kart assets, and a likely Pilotwings-era prototype NEWS_05.tar 109M 3,831 Star Fox 2 3D CAD Pipeline & Development Toolkit: 628 .txt, 500 .cad 3D models, 371 .anm animations, 307 .nca Nintendo CAD files, 268 .c C source files NEWS_09.tar 34M 1,374 SNES sprite/level assets: 502 .BAK backups, 213 .CGX, 128 .COL, 117 .OBJ, 56 .SCR, 52 .PNL panels - Yoshi-related content NEWS_11.tar 127M 5,401 Largest dump: 921 .CGX, 709 .OBJ, 648 .SCR, 526 .COL, 391 .BAK, 336 .cgx - primarily Yoshi’s Island production artwork and sprite objects NEWS_17.tar 4.0K 2 Stub: Backup.info only NEWS_41.tar 4.0K 2 Stub: Backup.info only These tars represent raw workstation snapshots rather than organized source archives. The bulk of the data (NEWS_04, NEWS_05, NEWS_09, NEWS_11) consists of SNES development assets - heavily weighted toward graphics files (.CGX/.COL color palettes and screens), object definitions (.OBJ/.OBZ 3D/sprite data), and map data (.MAP and .SCR). Notably, NEWS_05 also preserves CAD files and animation source, suggesting multi-disciplinary workstation backups captured during active development cycles. Gigaleak NEWS_05 - Star Fox 2 3D CAD Pipeline & Development Toolkit For the Star Fox 2 CAD, animation, and 3D toolchain workstation snapshot, see the NEWS_05 deep-dive. NEWS_02 - Email Attachments and ROM PayloadsNEWS_02.tar is mostly system/user environment data, but it also preserves email payloads with attached ROM files.For extracting those attachments, use this NEWS_02 email extraction script.Make sure to use the correct key for each email and put them in quotes e.g:## eng/Mail/inboxpython3 decode.py -i '/usr01/eng/Mail/inbox/1' -k 'nishi\\0' # sromchk.lzh - SROMCHK.EXE (ROM CHECKER for SHVC/SNES Version 0.02)python3 decode.py -i '/usr01/eng/Mail/inbox/2' -k 'is\\0' # SNES Audio/Music Tooling from 12th March 1993 (containing SGE.ENV SGE.EXE SGE.OVR SME.EXE SME.OVR SWM.EXE SWM.OVR)python3 decode.py -i '/usr01/eng/Mail/inbox/3' -k 'isw\\0' # 15th March 1993 isw.lzh - Only ISW.COM and ISW.EXEpython3 decode.py -i '/usr01/eng/Mail/inbox/4' -k 'is\\0' # SNES SDK Binaries from March 1993 - ISASMN.lzh (IS65.EXE, ISLINK.EXE, ISSND.EXE), ISW0318.LZH (ISW.COM, ISWASM.BAT, ISWREQ.COM, TEST2.X65 ISW.EXE, ISWEDIT.BAT TEST1.X65, TEST3.X65)python3 decode.py -i '/usr01/eng/Mail/inbox/5' -k 'newscad\\0' # mario-4.lzh (containing CHIJO.COL, M-POSE.CGX, M-POSE.OBJ, RUN.OBJ, YOSHI.CGX, YOSHI.OBJ)## Nintendo of America (NOA)python3 decode.py -i '/usr01/noa/Mail/inbox/1' -k 'angry\\0' # neskr.lzh containing PRG.ROM from 11th March 1993python3 decode.py -i '/usr01/noa/Mail/inbox/#2' -k 'antepaenultima\\0' # mar19th.lzh containing DMGJCX00.PRG## Research and Development 1 (RD1)python3 decode.py -i '/usr01/rd1/Mail/inbox/1' -k 'izushi\\0' # MINES.LZH - Containing Windows Minesweeperpython3 decode.py -i '/usr01/uji/Mail/inbox/#1' -k 'pmdawn\\0' # The Great Waldo Search (SGW05) and Bubsy (SUY02)python3 decode.py -i '/usr01/uji/Mail/inbox/1' -k 'sickboy\\0' # Wayne's World (SWW07-0.COM and SWW07-1.COM) from Feb 17thpython3 decode.py -i '/usr01/uji/Mail/inbox/2' -k 'starwing\\0' # SFRG-FO - German Star Foxpython3 decode.py -i '/usr01/uji/Mail/inbox/3' -k 'toomanygames\\0' # 5 games (NHI02, NU803, SHX01, SMU00, STX02)The recovered ROM groups include the following 1: From the “5 games” email: NHI02 (single file) and NU803 (split) - do not currently load in bsnes; from size these are likely NES-side builds SHX01 (split) - Super High Impact SMU00 (split) - Mario is Missing STX02 (split) - TAZ-MANIA From the “bubsy and waldo” email: SGW05 - The Great Waldo Search SUY02 (split) - first Bubsy NEWS_04 - Nintendo Graphics Workstation BackupNEWS_04.tar is a 96 MB Nintendo backup from one of their Sony NEWS workstations that preserves a large amount of graphics-side production material rather than source code.Where NEWS_05 captures the Star Fox 2 3D toolchain, NEWS_04 captures the more traditional 2D side of console production: character banks, palettes, screen layouts, object definitions, maps, and a huge number of backup revisions.The archive is especially useful because it is not a clean, single-project handoff.It is a live multi-user workstation snapshot with three home directories, several different projects, and visible evidence of iterative art work.At a GlanceNEWS_04 is best understood as a mixed graphics workstation backup.It preserves: 5,309 archive entries under three user homes: arimoto (Masanao Arimoto), sugiyama (Tadashi Sugiyama), and kakui 2,297 .BAK files, showing heavy iteration and local backup habits 991 .SCR files, making screen and scene layout one of the dominant data types 876 .CGX files and 431 .COL files, pointing to SNES/GB graphics-bank and palette work 266 .OBJ files and 108 .MAP files, showing object/layout and map-side asset organization One especially important late Star Fox 2 art workspace under home/arimoto/SF2 Older Zelda and Game Boy Zelda art workspaces under home/arimoto/zelda and home/arimoto/GB-zelda A second artist-style workspace under home/sugiyama with fly, flyman, CAR, SIM, MARIO, and FX2Unlike NEWS_05, this archive contains almost no conventional program source.Its value comes from file naming, layout formats, revision backups, and the way several projects coexist on one machine.The Main Story: Masanao Arimoto’s WorkspaceArimoto’s home directory is the most important part of the archive.It combines one late and unusually dense SF2 workspace with several older Zelda-related branches. Project Files Dominant types Date range Reading SF2 1236 .BAK, .CGX, .SCR, .COL, .OBJ, .OBX 1993-07-01 to 1995-09-19 The late, most active branch and the real centerpiece of NEWS_04 GB-zelda 824 .BAK, .OBJ, .CGX, .MAP, .SCR, .PNL 1991-11-27 to 1994-08-02 Game Boy Zelda visual and layout work, with stronger map/object emphasis zelda 545 .BAK, .CGX, .SCR, .COL, .MAP, .PNL 1991-05-23 to 1994-07-25 Earlier Zelda screen/map art branch DELDA 213 .BAK, .CGX, .SCR, .COL 1991-05-23 to 1991-10-24 Small early Zelda-related branch or internal variant Star Fox 2 - 2D Art Workspace (NEWS_04 Archive) For the dedicated Star Fox 2 2D art workspace deep-dive, see this page. The Legend of Zelda Link’s Awakening - 2D Art Workspace (NEWS_04 Archive) For the dedicated Link’s Awakening / GB-zelda art workspace deep-dive, see this page. Tadashi Sugiyama’s Mixed Graphics WorkspaceSugiyama’s home is the second major component of NEWS_04.It is older than Arimoto’s, broader in scope, and reads like a workstation that served multiple productions over five years rather than one focused project. Project Files Dominant types Date range Likely game flyman 429 SCR 286, BAK 139 1989-10-13 → 1991-05-07 Pilotwings-era prototype (unconfirmed) fly 388 BAK 137, CGX 102, SCR 78, COL 69 1989-10-13 → 1994-03-18 Pilotwings-era prototype (art side; 1994 date = tape restore) CAR 415 BAK 198, SCR 148, CGX 38, MD7 3 1991-04-05 → 1994-03-18 Super Mario Kart ✓ SIM 85 top-level + is/ SCR, CGX, OBJ, SFX, BAK 1990-11-27 → 1993-01-22 SimCity SNES (probable) MARIO 77 CGX, SCR, COL, BAK 1993-04-08 → 1993-06-21 Super Mario Collection front-end/menu branch (probable) FX2 41 CGX, SCR, COL, BAK 1993-07-06 → 1993-12-08 Wild Trax / Stunt Race FX ✓ Sugiyama RootOne useful thing about Sugiyama’s home is that the project folders are not the whole story.The root of home/sugiyama also preserves the shared workstation and CAD-tool layer that sat above those game directories.The loose files split into a few clear groups: Sony NEWS user-environment files like .cshrc, .login, .profile, .Xdefaults, .sxsession, and sj2usr.dic generic CAD/sample art assets like X.CGX, X.SCR, X0.SCR to X3.SCR, 256.CGX, PATTERN.SCR, and cad.CGX sfx_main sample manifests like SAMPLE.sfx_main.LST, run.sfx_main.LST, and their matching .DAT files a large set of tiny .cbm files named after editor actions such as pencil, paint, line, circle, zoom, rotation, priority, map-open, scr-open, and chr-openThose .cbm files are especially useful.There are 31 of them, every one is exactly 206 bytes, and the names read like UI commands rather than game data.The safest interpretation is that they are compact command or button definitions for Nintendo’s SNES graphics tools, not per-game assets.The sfx_main files point in the same direction.Their .LST contents reference paths like /usr/local/srd/cad/sfc/sfx_main.hex, which makes the root of Sugiyama’s home look like a real SRD CAD workstation environment rather than just a pile of extracted game folders.fly and flymanfly and flyman are complementary art/layout directories for an early SNES flight-game branch, likely connected to a Pilotwings-era prototype path. Pilotwings 2D Art Workspace (fly/flyman) For the full fly/flyman analysis, see the dedicated Pilotwings 2D art page. CARCAR preserves unambiguous Super Mario Kart production assets (MARIO-CAR, JUGEM, DOKAN, POLE, SLOT) and Mode 7 track-map work. Super Mario Kart 2D Art Workspace (CAR) For the full CAR analysis, see the dedicated Super Mario Kart 2D art page. SIMSIM preserves SimCity SNES menu/UI structures (SELECT-SCENARIO, MAP-SELECT, TOWN, LEVEL, INPUT) and a distinctive .SFX pairing workflow tied to an S-CG-CAD tool signature. SimCity SNES 2D Art Workspace (SIM) For the full SIM analysis, see the dedicated SimCity SNES 2D art page. One important extra detail at the NEWS_04 level is that Sugiyama’s root directory also preserves shared CAD-tool resources above the project folders themselves, including generic sample screens, sfx_main manifests, and thirty-one tiny .cbm files that look like editor command or button definitions for Nintendo’s graphics tools.MARIOMARIO is a short, menu-heavy branch centered on GAMESELECT.*, MA-ROGO-OBJ.CGX, and 2PR-S1.*, currently read as probable Super Mario Collection / All-Stars front-end work.FX2FX2 preserves Wild Trax / Stunt Race FX selection-screen assets, including lower-case naming patterns (cpt, p-select) that differ from earlier Sugiyama branches. Stunt Race FX 2D Art Workspace (FX2) For the full FX2 analysis, see the dedicated Stunt Race FX 2D art page. NEWS_04 Timeline SnapshotThe table below lists the relevant entries. Period Project Status 1989-10-13 fly + flyman open together Early SNES flight game begins 1990-11-27 SIM opens SimCity SNES UI/art phase begins 1991-04-05 CAR opens Super Mario Kart development begins 1991-05-23 DELDA + zelda open Early SNES Zelda graphics phases begin 1991-11-27 GB-zelda opens Game Boy Zelda branch begins 1993-04-08 MARIO opens Probable All-Stars front-end branch begins 1993-07-06 FX2 opens Wild Trax UI art begins 1994-03-18 Tape snapshot fly/CAR share restore-date timestamps 1995-09-19 SF2 latest files Late Star Fox 2 art branch remains active Practical 2D Workflow Pattern Preserved in NEWS_04flowchart LR A[\"<b>Graphics Bank</b><br>CGX character or tile art\"] --> B[\"<b>Palette</b><br>COL color set\"] B --> C[\"<b>Screen Layout</b><br>SCR assembles the scene\"] C --> D[\"<b>Object / Map Side</b><br>OBJ, OBX, MAP, PNL\"] D --> E[\"<b>Revision Loop</b><br>BAK copy preserved before next edit\"]That pattern appears repeatedly across both Arimoto and Sugiyama workspaces.Super Famicom Built ROMs (other/SFC/ROM)The other/SFC/ROM folder contains an unexpected subset of built Super Famicom binaries and a utility executable rather than source code. Specifically, it holds what appears to be a build of Star Fox 2, multi-disc split ROMs for Super Mario RPG in both Japanese and US localizations, and a checksum application.At a GlanceThe other/SFC/ROM directory preserves: a single 1MB build path for the officially unreleased Star Fox 2 Japanese and US builds of the 4MB Super Mario RPG, split perfectly into 1MB “Discs” a Windows/DOS executable tool for calculating ROM checksums ROM The folder structure is organized by game and region, revealing how large 4MB SNES games (like Super Mario RPG) were handled in 1MB chunks, along with an English test build of Star Fox 2. ⚙️ CheckSumHVC.exe A command-line utility for calculating or validating ROM checksums 📁 StarFox2 Directory for Star Fox 2 builds ⚙️ StarFox2/usa/SXJ03.COM A built 1MB executable ROM image for Star Fox 2 (USA) 📁 SuperMarioRPG Directory for Super Mario RPG (SA-1) 📁 SuperMarioRPG/JP Japanese localization (ARWJ) 📄 SuperMarioRPG/JP/Disc0/ARWJ02-0.SFC 1MB chunk 0 of the 4MB ROM 📄 SuperMarioRPG/JP/Disc1/ARWJ02-1.SFC 1MB chunk 1 of the 4MB ROM 📄 SuperMarioRPG/JP/Disc2/ARWJ02-2.SFC 1MB chunk 2 of the 4MB ROM 📄 SuperMarioRPG/JP/Disc3/ARWJ02-3.SFC 1MB chunk 3 of the 4MB ROM 📁 SuperMarioRPG/US US localization (ARWE) 📄 SuperMarioRPG/US/Disc0/ARWE00-0.SFC 1MB chunk 0 of the 4MB ROM 📄 SuperMarioRPG/US/Disc1/ARWE00-1.SFC 1MB chunk 1 of the 4MB ROM 📄 SuperMarioRPG/US/Disc2/ARWE00-2.SFC 1MB chunk 2 of the 4MB ROM 📄 SuperMarioRPG/US/Disc3/ARWE00-3.SFC 1MB chunk 3 of the 4MB ROM The EPROM Split StructureThe 4MB Super Mario RPG Japanese (ARWJ) and US (ARWE) ROMs are interesting because they are systematically cut into four 1048576 byte (1MB) files, sorted into Disc0 through Disc3.This division isn’t an indicator of multi-disc gameplay like the PlayStation. Instead, it demonstrates the physical realities of development and testing at the time.This is how the real SNES SA-1 prototype boards were burned physically, but emulator software won’t recognize them out of the box until they are merged back into a single binary file.Burning a full 4MB (32Mbit) game for testing meant dividing the binary across multiple 1MB EPROM chips. These folders explicitly preserve that file-splitting step before a physical board was flashed.To play the builds on modern emulators, the split 1MB files just need to be rejoined in binary order. Because SNES games are flat binaries, a short Python script can safely merge them back into a working 4MB .sfc image:import osbase_path = './SuperMarioRPG/US'output_path = './SuperMarioRPG-US-Merged.sfc'chunks = [ os.path.join(base_path, 'Disc0', 'ARWE00-0.SFC'), os.path.join(base_path, 'Disc1', 'ARWE00-1.SFC'), os.path.join(base_path, 'Disc2', 'ARWE00-2.SFC'), os.path.join(base_path, 'Disc3', 'ARWE00-3.SFC')]with open(output_path, 'wb') as outfile: for chunk in chunks: with open(chunk, 'rb') as infile: outfile.write(infile.read()) print(f'Successfully stitched 4MB ROM to: {output_path}')Once stitched together, running a cryptographic hash (like shasum -a 1) on the resulting SuperMarioRPG-US-Merged.sfc file returns a4f7539054c359fe3f360b0e6b72e394439fe9df. This exact SHA-1 hash is heavily documented by ROM hacking and preservation communities (such as No-Intro) as being the bit-for-bit identical match to the final, unmodified commercial release of Super Mario RPG: Legend of the Seven Stars (USA). This confirms the Gigaleak repository was holding the absolute final code rather than a beta or localization candidate!Star Fox 2 (USA)SXJ03.COM is preserved as a 1MB file for the US version of Star Fox 2 (usa). The .COM extension is notable in Nintendo’s development environments - it is identically sized to a standard 1MB SFC ROM dump and represents the direct compiled output, sharing conventions with the .com monitor artifacts seen in the Game Boy boot ROM repositories. Finding it packaged under the SFC/ROM directory provides a direct glimpse into the internal naming conventions for the project prior to its original cancellation.By extracting the 64-byte block starting at 0x7FC0, we can reveal the internal SNES ROM header embedded right inside the SXJ03.COM executable. The raw binary output exposes the title, layout, and makeup of the cartridge:00007fc0 53 54 41 52 46 4f 58 32 20 20 20 20 20 20 20 20 |STARFOX2 |00007fd0 20 20 20 20 20 20 15 0a 00 01 33 00 d8 71 27 8e | ....3..q'.|When decoded against the official SNES header specification, the metadata breaks down elegantly: Internal Title: STARFOX2 (exactly 21 characters padded with spaces) Map Mode (0x15): Identifies the ROM layout Cartridge Type (0x0A): Typically indicates ROM + Battery + Coprocessor, directly signaling the presence of the Argonaut Super FX chip needed rendering the 3D polygons! ROM Size (0x00): Curiously, the ROM size field is left completely blank (0), confirming that this .COM executable was a raw testing dump and not yet parsed through Nintendo’s final master validation tool.Internal Tool: CheckSumHVC.exeA string analysis of the CheckSumHVC.exe binary reveals it is a multi-platform command-line utility used internally by Nintendo. Despite having HVC in the name (Home Video Computer, the internal family code for the Famicom), this tool was used for validating lot-check checksums across multiple console generations.The internal strings reveal its command-line flags: [/?] - show help (this text) [/Q] - show only SUM result [/L] - show SUM result in lower-case [/C] - set SUM to clip board [/0] - DMG Mode: check as addresses 0x014E, 0x014F data are 0x00The /0 DMG flag is particularly interesting. In the original Game Boy (DMG) cartridge header architecture, addresses 0x014E and 0x014F hold the Global Checksum of the ROM. The /C clipboard flag also provides a glimpse into the developer workflow, allowing engineers to quickly copy-paste generated checksums into their assembly configuration files before a final build.Additionally, because the tool was compiled via MSVC for Windows, it inadvertently preserved the exact hard drive path of the Nintendo developer who originally built the executable: D:\\n2633\\Documents\\Code\\CheckSumHVC\\CheckSumHVC\\Release\\CheckSumHVC.pdbThe n2633 directory is almost certainly a Nintendo internal employee or machine ID.Boot ROM Repositories (other/agb_bootrom)The other/agb_bootrom folder is much richer than the filename suggests.On disk it survives as two full Subversion repositories, one for agb_bootrom and one for cgb_bootrom, complete with revision history, trunk/branches/tags, and surrounding build material.It is best thought of as two related but quite different archives: the AGB side is a broader monitor, startup, library, and tooling environment the CGB side is a tighter DMG-era monitor build package with spec documentsIf you don’t have subversion tooling installed the full trunk versions of both were released as separate archives agb_bootrom_trunk.zip and cgb_bootrom_trunk.zip.Gameboy Color Boot ROM (cgb_bootrom_trunk.zip)The cgb_bootrom_trunk.zip archive is best understood as an exported working copy from the cgb_bootrom Subversion repository preserved inside other/agb_bootrom. Gigaleak - Game Boy Color Boot ROM Repository For the repository layout, build flow, and surviving CGB trunk files, check out this post. Game Boy Advance Boot ROM (agb_bootrom_trunk.zip)The agb_bootrom_trunk.zip archive is the extracted latest working copy from the much larger agb_bootrom Subversion repository found inside other/agb_bootrom. Gigaleak - Game Boy Advance Boot ROM Repository For the wider AGB repository contents, including the monitor code, include files, libraries, docs, and later tools like AgbComp and Bmp2Agb, check out this post. Netcard & Online Pokémon ProjectWe have a dedicated page delving deep into the BroadOn design documents regarding this cancelled Game Boy Advance online peripheral and the planned 3rd Floor of the Pokémon Center! Netcard - Cancelled GBA Online Peripheral Read all about the cancelled 2004 GBA Netcard and ambitious Pokemon WAN project. CVS Repository Dump (20100713cvs_backup.tar.7z)The CVS Repository dump is from the 20th of October 2007 and mainly contains projects related to the WII Virtual console, such as emulators for Game Boy and DS, along with a few other small projects by individual developers.Checking out the latest versionStep 1 - Extracting the tarThe first step after extracting the 7Zip file to to extract the tar archive, you can do this like so:tar -xvf 20100713cvs_backup.tarStep 2 - Installing CVS and checking out filesYou will need to first have the CVS command line utilities installed if you haven’t already then you can install like so: Mac OSX: brew install cvs Ubuntu Linux: apt-get install cvsNow run the command in a folder that you want to extract the files:cvs -d ~/extract_path/usr/local/cvsrepo/ensata checkout .Note that the path has to be the FULL absolute path or it will complain about not being able to find the host.It is a very large repository so expect it to take a while to complete.Ensata (DS Emulator)ensata is one of the most substantial projects in the CVS dump.Rather than a single binary release, the leak preserves what looks like the full CVS repository for Nintendo’s internal Nintendo DS emulator, including source code, Windows build projects, help files, plugin interfaces, debugger integrations, and UI artwork.At the top level the repository contains: a standard CVSROOT one main module called gbeThe gbe module is the real project.Across the whole repository there are roughly 1,214 files, with the dominant types being: Type Count Reading .h,v 319 C/C++ headers .cpp,v 261 core implementation files .txt,v 172 documentation and logs .gif,v + .bmp,v + .ico,v 151 combined UI, help, skin, and debugger artwork .vcproj,v + .sln,v + .bpr,v + .bpf,v 56 combined Visual Studio and Borland project files .html,v + .chm,v + .hhc,v + .hhp,v 72 combined built help and help-project material So this is not just emulator engine code.It is a fairly complete internal Windows application repository.Repository StructureThe main gbe module splits into several clear components: Directory Files Reading WIN 646 main Windows-side emulator, debugger, and engine code @log 150 CVS branch/thread history files HelpProject 114 Japanese and US help documentation projects PluginSDK 91 plugin interface headers and related support files ext_control 91 external-control integrations materials 53 BMP/PSD UI skins and interface artwork DOL 11 build/test material unreg 7 unregister or activation-side utility ini_edit 5 configuration editor tool rc_edit 3 resource-editing support tool That shape makes Ensata look like a full emulator product line rather than a tiny developer test harness.The Main Windows ApplicationMost of the actual emulator appears to live under gbe/WIN/iris.That branch includes: the main application shell UI and frame code like LcdFrame, LcdGDIFrame, and LcdD3DFrame input handling through DInput.cpp ROM loading helpers like ReadNitroRom a large engine subtree with files like arm9_biu, arm9_io_manager, backup_ram, boot_image, card, cartridge, dma, and engine_control an engine_subp subtree with ARM7-side components like rtc, touch_panel, subp_spi, subp_card, and sound_wrapperEven from filenames alone, that is much more than a superficial launcher.The repository clearly preserves real DS hardware-emulation subsystems, including ARM7 and ARM9 support, cartridge and backup handling, LCD paths, timers, DMA, touch input, and sound wrappers.Debugger, Plugin, and Tooling HooksEnsata also looks unusually extensible for an internal emulator.The leak preserves: PluginSDK/plugin_sdk.h WIN/agbdeb debugger-side code WIN/iris/debug_tools/cw_debugger.dll and cw_debugger.exe ext_control integrations for cw_debugger, is_chara, nitro_viewer, pro_dg, and sample WIN/iris/builder_plugin code helper tools like ini_edit and rc_editThat makes the repository especially interesting historically.It was not just being used as a standalone emulator for running ROMs.It was also being wired into a broader Nintendo DS development environment with debugger and external-control support.UI, Localization, and Packaging MaterialOne of the nicest surprises in the repository is how much application-side packaging survived.The materials folder keeps interface art such as: activation.bmp backupmenu.bmp DebugPrint.bmp MemoryDump.bmp NintendoLogotype.bmp nitrosoft.bmp popupmenu.bmp key_config.bmp lcd_target.bmp Photoshop sources like buttons.psd, default_skin.psd, dirkey.psd, and iris_logo.psdSome of those assets also survive in Japanese-specific variants like _jp.bmp or _jp.psd.That lines up with HelpProject/jp, HelpProject/us, and WIN/iris/dlls/StrRes_eng.dll, suggesting Ensata was being maintained as a localized internal tool rather than one single-language prototype.Version History and BranchingThe CVS metadata is also unusually revealing.The @log directory contains 150 branch-history files, and the RCS symbol names across the repository show a long development arc: early numbered versions from late 2003 and early 2004 version-1-3c-20041203 version-1-4-20050324 version-1-4a-20050401 version-1-4b-20051003 version-1-4c-20060320 version-1-4d-20060711 version-1-4e-20070316 version-1-4f-20080312 version-1-4g-20080523 version-1-4h-20081007 version-1-4i-20091001There are also several named side branches: external-control-for-cw-debugger external-control-for-is-chara version-stream-feedback-control version-d-input version-speed-up-test version_for_pokemon version_for_pokemon2 version-nse-tentativeThat branching pattern matters.It shows Ensata was not just a frozen emulator that got occasional bug fixes.It was being actively adapted for debugger integration, performance work, input changes, stream feedback, and at least some Pokemon-specific internal branches.What This MeansThe leak does not just confirm that Nintendo had an internal DS emulator.It preserves a large slice of Ensata as a maintained software product: emulator core Windows UI shell debugger hooks plugin SDK help system localization assets version and branch history from 2003 to 2009That makes Ensata one of the highest-value parts of the CVS dump, especially for understanding how Nintendo’s DS development environment fit together beyond the hardware devkits themselves.imatakeThis folder contains two projects by someone known as Imatake who presumably worked at Nintendo 13 years ago (2007). One is a disassembler for original Game Boy ROMs and the other is a tool to support Korean Hangul characters in the Pokemon Font.dmgdasmThis is a disassembler for Original DMG Game boy ROMs written in C++, presumably used to test the Virtual Console Game Boy emulator in the turnout folder.dpk_fontconv (Hangul Korean Font Converter)This is a font converter used to generate the Pokemon front for the Korean writing system known as Hangul.muratestmuratest is small, but it is a real cluster of low-level test projects rather than one random scratch folder.It contains four compact branches: dlltest, test2, test4, and test5.The code mix is very light: C and C++ source small include sets with headers like ipaddress.h and osreport.h simple makefile + readme.txt pairs in each projectThat makes it look much more like a set of SDK or middleware experiments than a game repository.The most complete branch is dlltest, which has both C and C++ source files (a.cpp, b.cpp, osreport.c, static.c) plus shared support headers.test2, test4, and test5 look like follow-on stripped-down experiments built around the same support layer.So the safest reading is that muratest preserves small GameCube/Wii-era development tests by Teruki Murakawa, probably used to try out build setups, reporting, IP/network support, and basic runtime behavior rather than ship any end-user software.noriproj (Misc Tools)noriproj really does split into two unrelated utility projects, but both are clearer from the file tree than the old summary made them sound.Virtual Console Uploader (vc)The vc branch is a small PHP web application rather than a one-off script.It includes: front-end pages like index.php, search.php, navigate.php, and table.php helper code like for_narrow_search.php and for_pear.php an admin/ backend with upload, revise, and delete actions a parallel vc_rev/ copy of the same appSo this looks less like a tiny uploader script and more like an internal web UI for browsing and managing Virtual Console or Wii Shop content records.WallPaperPasswordMakerWallPaperPasswordMaker is a small C# Windows Forms application rather than just an algorithm dump.It includes: Form1.cs and Form1.Designer.cs a project file, icon, and resources a standard Properties/ tree with settings and assembly metadataThis matches the idea that it was an operator-facing utility used to generate Pokemon Box wallpaper passwords in a simple GUI rather than by hand.It generates 4 passwords for a user based on a word list with an algorithm that takes into account the trainer ID and whatever wallpaper the user wants for their Box.There is an unofficial version available on PokeWiki.de here: Secret Code Generator - PokéWikiturnout (Game Boy emulator for Wii VC)turnout is much smaller than ensata, but it is also much cleaner.The leak preserves a compact CVS repository for a Wii-side Game Boy emulator called gbemu_rvl, which looks very much like a Virtual Console support project rather than a general-purpose emulator product.At the repository root there is one main module: gbemu_rvlAcross the whole tree there are only 28 files, dominated by emulator source and headers: Type Count Reading .cpp,v 10 core implementation files .hpp,v 9 main emulator class interfaces .h,v 3 lower-level headers .rom,v 4 monitor ROMs for different Game Boy models Makefile,v 1 Revolution SDK build entry point .bat,v 1 helper script That makes turnout look much more like a focused embedded emulator module than a full standalone tool with skins, plugins, and help projects.What the Project ContainsThe gbemu_rvl module is split into three obvious parts: include/ for the public emulator classes src/ for the implementation data/ for bundled monitor ROMsThe class names are very direct: GBCpu GBEmulator GBGraphics GBRomImage GBSound GBSramImage GBSuperGameboy SaveBanner FontManagerThat gives a pretty good high-level map of the feature set.This was not just a CPU core with a blitter attached.It includes explicit ROM-image, SRAM, graphics, sound, Super Game Boy, and Wii save-banner handling.It Was Built as a Wii ProjectThe Makefile makes the platform explicit.It includes: $(REVOLUTION_SDK_ROOT) build rules a module name of gbemu_rvl conditional defines for ROM and SRAM filenamesSo this is very clearly a Wii-era Nintendo build, not an older desktop-side Game Boy emulator.The naming also matches that role nicely: rvl points to Revolution / Wii SaveBanner fits Wii save-data presentationThe Monitor ROM Set Is a Nice DetailThe data/ directory is tiny but historically useful.It preserves four different monitor ROM files: File Size Reading MonitorDmg.rom 714 bytes DMG monitor MonitorMgb.rom 714 bytes Game Boy Pocket / MGB monitor MonitorSgb.rom 457 bytes Super Game Boy monitor MonitorCgb.rom 2,771 bytes Game Boy Color monitor That is a strong clue that the emulator was explicitly modeling multiple Game Boy hardware families rather than treating “Game Boy” as one flat target.The Branch Names Show What the Team Was Working OnEven though the repository is small, the CVS symbols are surprisingly informative.The main branch history in files like Makefile, main.cpp, GBEmulator.cpp, and GBSuperGameboy.cpp includes: imatake-070905-ShirenGB2Playable imatake-070906-GraphicsRenderingOptimized imatake-070910-GraphicsSynchronized imatake-070913-BeforeSgbImplementation imatake-071002-SgbFramePilot imatake-071004-SgbScreenAdjustedThat tells a nice story in only a few weeks of 2007: first getting a real game, Shiren GB2, into a playable state then optimizing and synchronizing graphics then adding or refining Super Game Boy support then adjusting SGB framing and screen behaviorSo while turnout is much smaller than ensata, it is not just a toy sample.It looks like a targeted emulator branch being actively tuned for compatibility and presentation inside Nintendo’s Wii Virtual Console environment.pokemonThe pokemon repository is one of the largest projects in the CVS dump, with roughly 52,619 files spread across game build trees, tools, and localization work areas.The strongest through-line is Pokemon Diamond and Pearl.The leak preserves two main DS build trees, a very large work area full of message/font/localization snapshots, and a smaller set of supporting tools.The Main Project LayoutAt the top level the repository breaks down into four major areas: Directory Files Reading pm_dp_ose 37,451 main Diamond/Pearl branch with strong Korean and localization history pokemon_dp 11,234 Diamond/Pearl build tree with Diamond/Pearl split resources yama_work 3,561 message, font, spreadsheet, and regional localization workspace poketool 337 smaller utility and memory/debug tools That means the repo is not just raw game code.It also preserves a lot of the production and localization machinery around the DS games.Diamond and Pearl Build TreesBoth pokemon_dp and pm_dp_ose look like real Nintendo DS project trees rather than random file dumps.They contain: Makefile commondefs.GF modulerules.GF .rsf and .lsf build/config files overlay_files overlaytool.rb make_g3_files make_prog_files diamond_rs and pearl_rs subtrees include, src, resource, and convert directoriesThat structure strongly suggests a Game Freak DS build environment with overlay management and separate Diamond/Pearl resource outputs.The pokemon_dp tree looks like the base Diamond/Pearl project, while pm_dp_ose looks like a later or more specialized branch layered on top of it.pm_dp_ose Looks Especially Localization-FocusedThe version history in pm_dp_ose is particularly revealing.Its CVS symbols include: MASTER_ADAK00_APAK00 MASTER_ADAK00_APAK00-DemoVersion-branch a long run of KR-* branch names through late 2007 imatake-080421-HangulCompressRate imatake-080425-KoreanDemoBeta imatake-080904-PostmanFixFunction imatake-071012-GTSProfileSetting imatake-071015-BTProfileSetting imatake-070920-KoreanMonthsInNumber imatake-070920-RedNamesFixedThat is a very strong hint that pm_dp_ose is not just a normal gameplay branch.It looks heavily tied to Korean release work, demo-version handling, and late localization-specific fixes.Even the file set supports that reading: localize_readme.txt bugfix.h localize.h overlay_files pokemon_DS.bnrSo this part of the leak is especially useful for understanding how Diamond/Pearl was being adapted and maintained across regions.yama_work Preserves the Localization PipelineIf pm_dp_ose is the build side, yama_work is the production-workflow side.It preserves a huge number of dated work folders and conversion scripts centered on text, fonts, and regional deliveries.A few of the strongest signals are: dated snapshot folders like DP0110, DP0122, DP0205, DP0219, DP0221, DP1204, DP1211_fixed, and DP1226+28 many .gmm message files such as scenario1.gmm, scenario2.gmm, menu_msg1.gmm, fight_msg.gmm, pokedex.gmm, poketch.gmm, townmap.gmm, and wifi.gmm many .xls workbooks like DP_Items.xls, DP_Moves.xls, DP_Pokedex.xls, DP_Trainers.xls, and DP_US_ver2.xls font files like font_button.nftr, font_num.nftr, font_system.nftr, font_talk.nftr, and font_unknown.nftr conversion and glossary tooling under convert, msggrep, modify, glossary, xlsdiff, and japanese_to_usa regional exchange folders like fromNOE* and toNOE*, plus koreaThat makes yama_work one of the clearest localization-production artifacts in the whole CVS dump.It is not only a text archive.It preserves the spreadsheets, message banks, font resources, and helper scripts used to move Diamond/Pearl text across regions and revisions.poketool Adds Smaller Support UtilitiesThe poketool branch is much smaller, but still interesting.It contains: vtags, a source-analysis or symbol/navigation tool MemSnatcher MemSend marumiX, including DS_VRAM_Viewer database files and RAM-transfer codeSo even the smaller side of the repo points back toward DS debugging and content-inspection workflows rather than only game assets.What This MeansThe pokemon repository is best understood as a mixed Diamond/Pearl production dump rather than a single neat game-source checkout.Its value comes from three layers surviving together: the DS build trees in pokemon_dp and pm_dp_ose the heavy regional and Korean-branch history in pm_dp_ose the message/font/spreadsheet workflow in yama_workThat makes it one of the most useful repositories in the CVS leak for studying how Nintendo and Game Freak handled DS-era localization, font production, overlays, and release-specific branch management.References Another Nintendo leak uploaded online, features betas and source code for many SNES games - Page 7 - GBAtemp.net ↩ ", "excerpt": "On 24 July 2020, a large Nintendo archive was uploaded online and quickly became known as the Gigaleak. It was not one single neat source drop. It was a mixed archive of ROMs, source trees, boot ROM repositories, internal tools, and later CVS/Subversion backups. Uploaded Files These were the archive...", "tags": ["snes","leak","sourcecode"], "image": "/public/images/snes/Gigaleak.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Gigaleak 2 Electric Boogaloo - N64 Source Code Leak", "url": "/gigaleak2", "content": "On the 25th of July 2020, the day after the Gigaleak, its sequel Gigaleak 2 was uploaded to a thread on 4chan. This is a continuation of the leaks that were obtained from a iQue/BroadOn/Routefree hack earlier in the year.Uploaded FilesThis leak contained files for a Version Control Repository (CVS) owned by the creators of the Chinese iQue Player (Routefree). It mainly focussed on Nintendo 64 source code but also contained a few Gameboy Advance (AGB) files too. Note that this was sent from Nintendo to iQue for the purpose of creating a Chinese localised version of the main N64 games such as: 1080 snowboarding Animal Crossing/Forest Dr Mario 64 F-Zero X Super Mario 64 Mario Kart 64 Wave Race 64 Zelda (MM & OOT).Files Leaked: bbgames.7z (just contains bbgames.tar)Step 1 - Extracting the tarThe first step after extracting the 7Zip file to to extract the tar archive, you can do this like so:tar -xvf bbgames.tarIf you get an error such as “Cannot open: Invalid argument” it is due to some of the file names containing characters that are invalid on a FAT* based File System. So you will need to extract on a different file system such as NTSC 1.Step 2 - Installing CVS and checking out filesYou will need to first have the CVS command line utilities installed if you haven’t already then you can install like so: Mac OSX: brew install cvs Ubuntu Linux: apt-get install cvsNow run the command in a folder that you want to extract the files:cvs -d path/to/download/d1/routefree/bbgames/depot checkout .It is a very large repository so expect it to take a while to complete.Root directory (d1/routefree/bbgames/depot)This section will give you an overview of all the main folder contained at the root directory of the extracted leak.The table below gives a brief description of what is in each folder, most of the folder are game specific: Folder Name Description 1080 Source code to 1080 Snowboarding TFC Source code for the Famicom emulator for NES used in Animal Crossing cba Source code for “Kobe Bryant in NBA Courtside” cba2 Source code for “NBA Courtside 2: Featuring Kobe Bryant” certs Certificates for iQue Player? club Source code for the iQue Club application devkit N64 Dev Kit 5.0 (both pc & sgi) & Sound Tools devsys Partner N64 Development Kit dm64 Dr Mario 64 Source code f0x Source code for F-Zero X forest Source code to Animal Crossing game_manuals Contains the Adobe Postscript files for the physical game manuals marioAGB Source code for Super Mario Advance mk64 Source code for Mario Kart 64 os20l N64 SDK OS Library Version 2.0L ostrees Contains versions (2.0E, 2.0F, 2.0G) of the SGI versions of the SDK release Compiled release versions of the source codes in rom format sf64 Source code for Star Fox 64 sm64 Source code for Super Mario 64 tex_viewer Source code for the N64 Texture viewer 2 tools A bunch of Python and Perl tools to convert and compress various formats wario4land_gba_ique Source code for “Wario land 4” for the GBA wr64 Source code for Wave Race 64 yoshi Source code for Yoshi’s Story z_majora Source code for Zelda Majora’s Mask z_ocarina Source code for Zelda OOT z_ocarina2 Source code for Master Quest (Ura Zelda) 1080 Snowboarding (1080 folder)The 1080 folder contains two main subfolders apps and lib, the apps folder is where the main source code and assets are contained and the lib folder just contains a single static library known as libgdl_u64.aGDL Static Library (libgdl_u64.a)It is not clear what the purpose of the GDL static library is yet or if it was used in any other games, but we do know it was created by Giles Goddard due to this line in the Makefile:/usr/people/giles/src/stl/latestThere is also reference to a tool called GDEDIT in the same Makefile so it could be linked to this library or it could be that Giles just prefixed GD to the start of any tool he created.There doesn’t seem to be any source code in the leaks for this library but since a static library is just an archive, we can list the contents with the following command:ar t libgdl_u64.aThe files contained in the library will be listed in the table below along with any descriptions that help identify the purpose of the objects: File Name Description acos.o   actor.o   alloc.o   animate.o   animateio.o   app.o   asin.o   atan.o   binmgr.o   boot.o   callback.o   camera.o   clay.o   collide.o   colours.o   console.o   control.o   dl.o   dnode.o   env64x32_l1.o   env64x32_l2.o   env64x32a.o   env64x32b.o   env64x32c.o   euler.o   forcestick.o   fricstick.o   funcptr.o   gel.o   gfxlib.o   hair.o   hand1_tex.o   hand2_tex.o   hostio.o   ik.o   isstream.o   item.o   math.o   mblur.o   memory.o   memtrack.o   message.o   moji4b.o   mouse.o   node.o   nodelist.o   nus_mark_tex.o   parameter.o   particle.o   phong_ia8.o   printfault.o   qnode.o   ramp32x32_tex.o   rcpmgr.o   shadow.o   shadowc_tex.o   shape.o   skin.o   spot1_tex.o   spot2_tex.o   spot3_tex.o   spot4_tex.o   spotlight.o   spring.o   star_env_tex.o   stdgfx.o   stdio.o   stdobjs.o   stdsys.o   sun_64x32_tex.o   syslib.o   terrain.o   text.o   timer.o   u64cont.o   vrbox.o   water.o   widget.o   window.o   Main Source Code (apps/ski folder)The main source code is neatly organised into a bunch of sub folders, this makes it one of the tidiest source code folders in the leak. Ski Main source code folder. 📁 data Contains asset data such as player animations, maps, and effects 📁 flow Game flow code, seems to be the main game code 📁 gui The main game GUI 📁 snow Code for snow effects, including board spray and trail 📁 u64 Contains the standard build toolchain such as makefiles, boot code, and ROM specs 📁 world World editor pre-compiled code Unfortunately there is no uncompiled source code for 1080 snowboarding, so don’t expect any *.c or *.h files here, but the precompiled ELF objects *.o can be very interesting indeed.If anyone is interested in a full rundown of what each of the pre-compiled objects contains and how they are related to the final ROM then let us know and we can create a new page for this purpose.Dr Mario 64 (dm64 folder)The full complete source code to Dr Mario 64 has been successfully compiled! #n64 #nintendoleak https://t.co/y66ryCOmgJ— RetroReversing.com (@RetroReversing) July 27, 2020F-Zero X (f0x folder)The source code for F-Zero X is nowhere near as well organised as the 1080 Snowboarding code, BUT it actually has source code and not just pre-compiled object files!Also this is not just the code to the N64 version but also contains the 64DD course editor! F0X Main source code folder. 📁 audio Pre-compiled audio code 📁 CAD Contains sprites in RGB format 📁 cheat Cheat-related data 📁 cheat_code Same as cheat folder 📁 i10n Localisation (text used for translations) 📁 IMAGES Texture files 📁 metadata Metadata information for iQue Player 📁 MOJI Alphabet textures 📁 sound Audio data The source files seem to be named after the developer that was responsible for them, this was common practise in the early days of software development before good quality source control.The table below covers the most common prefixes found in the F-Zero source code. Prefix Description dai_ Written by daisuke tsujimura ko_ Written by keizo ohta kn_ Written by masahiro kawano? mo_ Written by shiro mouri ? ot_ Written by tsutomu kaneshige? sot_ Written by hiroki sotoike Source Code FilesThe following table below just contains the uncompiled source code files present in the root directory of the F-Zero X source code. Name Description dai_autoline.h   dai_camera.h   dai_e_steng.h   dai_ending.h   dai_engine.h   dai_fireworks.h   dai_letter.c   dai_letter.h   dai_m_size.h   dai_machine.h   dai_me_size.h   dai_ssletter.c   dai_ssletter.h   dai_ssletter2.c   dai_ssletter2.h   dai_ssletter3.c   dai_ssletter3.h   dai_steng.h   dai_traveling.c   dai_traveling.h   debug.h   kn_backedit.h   kn_backinit.c   kn_backup.c   kn_backup.h   kn_camera.h   kn_cameraedit.h   kn_common.h   kn_disk.h   kn_dlsub.h   kn_endgp.c   kn_endgp.h   kn_font.h   kn_option.c   kn_option.h   kn_record.c   kn_record.h   kn_recordsub.c   kn_ssrecord.c   kn_suidashi.h   kn_window.h   kn_wipe.h   kn_world.h   kn_worldobj.h   ko_abc.c   ko_abc.h   ko_block.h   ko_csel.c   ko_csel.h   ko_define.h   ko_dtabc.c   ko_dtcsel.c   ko_dtgsel.c   ko_dtmsel.h   ko_dtmsel2.c   ko_dttitle.c   ko_dtwin.c   ko_gsel.c   ko_gsel.h   ko_gsub.h   ko_language.h   ko_main.h   ko_memory.h   ko_msel.c   ko_msel.h   ko_pcgraph.h   ko_pctask.h   ko_protect.h   ko_ramman.h   ko_select.c   ko_select.h   ko_title.c   ko_title.h   ko_win.c   ko_win.h   l_math.h   l_static.h   mo_color.h   mo_commonprg.c   mo_commonstatic.h   mo_controller.h   mo_declare.h   mo_diskproc.h   mo_drawkanji.c   mo_drawkanji.h   mo_editor.c   mo_editor.h   mo_kbuffer.c   mo_kbuffer.h   mo_machinemenu.c   mo_macro.h   mo_macro2.h   mo_main.h   mo_message.c   mo_printerr.c   mo_printerr.h   mo_reaction.h   mo_rom.c   mo_rom.h   mo_romkbuf.c   mo_setting.h   mo_setupkanji.c   mo_sseditor.c   mo_sseditor.h   mo_ssmachine.h   mo_ssmenutex.c   mo_ssmenutex.h   mo_sssetting.c   mo_static.h   n64dd.h   ot_course.h   ot_editcar.h   ot_effect.h   ot_header.h   ot_letter.h   ot_machine.h   ot_menu.h   ot_pcaudio.h   ot_race.h   ot_sseffect.c   ot_sseffect2.c   ot_sub.h   ot_system.h   person.h   sot_buffer.h   sot_buffer8m.h   sot_camera.h   sot_code.h   sot_course.h   sot_cpuletter.h   sot_crsobj.h   sot_define.h   sot_disk.c   sot_disk.h   sot_diskproc.h   sot_disksys.c   sot_disksys.h   sot_draw.c   sot_draw.h   sot_dynamic.h   sot_editbuf.h   sot_efect.h   sot_entry.c   sot_entry.h   sot_error.h   sot_filelist.c   sot_filelist.h   sot_ghost.h   sot_help.c   sot_help.h   sot_kanji.h   sot_leo.c   sot_letter.c   sot_letter.h   sot_main.h   sot_mapselect.h   sot_math.h   sot_matrix.h   sot_menu.c   sot_menu.h   sot_menudata.c   sot_mesdata.c   sot_message.c   sot_message.h   sot_minimap.h   sot_nameinput.h   sot_pack.h   sot_pad.h   sot_rominfo.h   sot_sscrsedit.c   sot_sseditor.c   sot_ssletter.c   sot_ssletter.h   sot_ssletter2.c   sot_static.h   sot_string.c   sot_string.h   sot_sub.h   sot_system.h   sotleo.c   ucode_f.h   Textures (IMAGES folder)There are some interesting images in the F-Zero X source code, including an image of Beavis from Beavis and Butthead.I FOUND THIS IN THE F-ZERO X TEXTURES pic.twitter.com/tlu1I2Tv9c— Zeether (@Zeether77) July 26, 2020Animal Crossing (forest folder)Animal Forest (Animal Crossing in the west) source code was initially based on the Zelda source code and thus has a few similar files to the OOT source also present in the leak. Forest Main source code folder. 📁 data Assets (3D models) 📁 flash Flash library (pre-compiled) 📁 forest_audio Pre-compiled sound files 📁 forest_lib Pre-compiled source code for F3DZEX2 and Famicom emulator 📁 lib Libraries for N64DD (leo) and N64 Master Data Utility 📁 rtcsrc Source code for the real-time clock library (`librtc.a`) 📁 src Header files and a few C source files from the main game 📁 tarball Tar archives sent from Nintendo 📁 zelda_tool_copy Command line tools (probably copied from Zelda but not specific to Zelda) Assets (data folder)TIL: Noesis has an ELF loader! #nintendoleaks https://t.co/WVxpLS3qjB— RetroReversing.com (@RetroReversing) August 1, 2020CLI Tools (zelda_tool_copy folder)The zelda_tool_copy founds far more interesting than it actually is, it is really just a subset of command line tools provided in the N64 and iQue sdks and none of them are zelda specific, these tools were used to create most games.Note that if you are interest in the source code for any of these tools then you can find it in “BroadOn Leak”. BroadOn Archive - Nintendo May 2020 Leak (4Chan) For more information about the BroadOn N64 Leak. Name Description romalign Align a ROM file to a certain boundary romfill Source code for this tool in BroadOn leak romaddress Possibly new version of the romaddress perl script from the N64 OS SDK romdivide ? rommap Prints out a map of the ROM, similar to the rommap perl script from the N64 OS SDK rommap_new Modified version of rommap slidec SLI decompressor decompresses a szp or szs file (Version 1.0) slicnv SLI converter, converts szpfile to szsfile (Version 1.0) sliencV11 SLI compressor (Version 1.1) What is interesting about the tools above is that it uses the SZS extension for compression, so Nintendo have been using this format from at least the N64 until present day Switch titles!Mario Kart 64 (mk64 folder)The source code for Mario Kart 64 seems to be missing most of the game engins source code, and appears to be mainly the game assets and code for screens that are heavily localized such as the Menus and End screens of the game. mk64 Main source code folder. 📁 audio Pre-compiled audio data 📁 enemy_source Enemy AI C source code in one massive C file 📁 i10n Tools for localisation and data in both Chinese and English 📁 image Images stored in C files as byte arrays 📁 include C header files for the game logic 📁 KT_data Track data 📁 map Track drawing data 📁 metadata iQue metadata for the game 📁 mkartDiffSource Contains USA and JP source code differences 📁 object Drawing data for 2D sprites such as banana power-up 📁 player Player kart sprites 📁 RESULT Race result ending data and credits 📁 select Player selection screen and title at start of game AssetsThis F1 car is found in a few Mario Kart 64 source folders. There is a version stored in the same format as Super FX models (GEO/3DG1), and a version converted to N64 source code. It was probably used in early tests and does not mean that MK64 was to be a F1 racing game. pic.twitter.com/hsi0ULrM8W— Starxxon (@vl_tone) August 1, 2020Release Folder (Compiled ROM files)The /release folder contains the result of compiling the source code for each game in this leak, in both english and Chinese ROM files.References filenames - What is tar error message “ Cannot open: Invalid argument” - Unix & Linux Stack Exchange ↩ Multi Texture Viewer Manual ↩ ", "excerpt": "On the 25th of July 2020, the day after the Gigaleak, its sequel Gigaleak 2 was uploaded to a thread on 4chan. This is a continuation of the leaks that were obtained from a iQue/BroadOn/Routefree hack earlier in the year. Uploaded Files This leak contained files for a Version Control...", "tags": ["n64","sdk","leak"], "image": "/public/N64/N64 Gigaleak2.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Gigaleak NEWS_05 - Star Fox 2 3D CAD Pipeline & Development Toolkit", "url": "/gigaleak-news-05", "content": "NEWS_05.tar is a 109 MB workstation backup snapshot from a Nintendo developer’s machine, dated around May 1995. Unlike the structured source-code drops elsewhere in the Gigaleak, NEWS_05 captures raw mid-development working directories from two prolific engineers: one focused on 3D asset production, the other on development tools and infrastructure.With 3,831 total files, NEWS_05 reveals the actual development process behind SNES 3D game creation-not the final code, but the tools that made it, the assets in progress, and the workflows that developers used. Gigaleak - SNES Source Code Leak For the broader Gigaleak context and other major archives, see the main Gigaleak overview. At a GlanceThis archive is the most process-oriented snapshot in the tape-restore collection: 3,831 files spanning 1992–1995 1,549 Star Fox 2 3D production assets in hierarchical stage folders with models, animations, and compiled binaries 26,000+ lines of CAD tool source code (40 C/H files) – the complete tool that created the 3D geometry 85 C source utilities for graphics conversion, ROM building, 3D math, and sound processing Hierarchical animation system with keyframe interpolation and skeletal transforms Workstation backup capturing developer workflows, naming conventions, and iteration patternsThe archive preserves two distinct working environments: Tsuyoshi Watanabe (3D artist) – 1,549 AAfundoshi files, CAD tool source, historical projects Kimura (tools engineer) – 665 utility files, graphics converters, ROM builders, 3D librariesGlossary of Key TermsIf you are new to SNES 3D development and Nintendo’s internal tool ecosystem, this glossary will help: CAD - Computer-Aided Design. Here, a proprietary 3D modeling and animation tool built by Nintendo for creating polygon geometry and animation keyframes on X11 workstations. NCA - Nintendo CAD Animation binary format. Compiled output from the CAD tool, optimized for SNES hardware execution. Contains both geometry and animation keyframes in a compact binary layout. ANM - Animation timeline source format. Text-readable keyframe data defining how 3D geometry transforms over time (skeletal animation, vertex morphing). CAD Source - .cad and .txt files containing 3D model definitions. The .txt format is ASCII vertex lists; .cad is the compiled binary model. Transfer Protocol - Mechanism for sending compiled models and animations from the Unix workstation to SNES development hardware via serial link or Ethernet. Fundoshi - Likely a Nintendo-internal CPU optimization variant. Represents SNES-specific compiled binaries and math libraries optimized for the 65C816 processor. IBM Variant - PC-compatible version of Kimura’s utilities, allowing asset preview and testing on standard DOS/Windows workstations before final SNES compilation. VRAM - Video RAM used on SNES for tile data, background maps, and sprite attributes. Extremely limited (64 KB total), requiring careful asset management. WRAM - Work RAM (128 KB on SNES). Used for game state, sprite data, and runtime animation state. EPROM - Erasable Programmable Read-Only Memory. SNES development boards used 1MB EPROM chips; large games like SF2 required multiple chips. partition.c managed splitting ROM images across these boundaries. Z-Buffer - Depth buffer for 3D rendering. SNES has no hardware Z-buffer, so depth.c implements painter’s algorithm (sorting polygons by depth). X11 - Network-capable graphical display system used on Unix workstations. The CAD tool uses X11 for its GUI. Skeletal Animation - Animation system where a 3D model is defined by bones/joints in a hierarchy. Transformations (translation, rotation, scale) are applied to bones, and geometry deforms based on bone positions. Keyframe Interpolation - Smooth transitions between animation poses. Animators define key poses at certain frames; the system automatically tweens intermediate frames. Painter’s Algorithm - Rendering technique that sorts polygons by depth and draws them back-to-front. Used on SNES because hardware Z-buffering is unavailable. Mode 7 - SNES background rotation/scaling capability. Used in F-Zero for the track perspective effect. cnvmode7.c converts graphics to Mode 7 format.Contents at a GlanceThe table below lists the relevant entries. Directory Purpose Key Files home/watanabe/AAfundoshi Star Fox 2 3D assets (1,549 files) 296 .anm, 253 .nca, 428 .cad, CAD source (26 C/H files) home/watanabe/FX2 Stunt Race FX graphics 42 .cgx, 36 .bak, 16 .scr, 15 .col home/watanabe/3DCAD CAD tool UI/demo Graphics, menus, viewport renders home/kimura/util SNES development toolkit 85 .c source + 200+ compiled utilities home/watanabe/{ZELDA,PO,INDY,SG-1} Earlier/misc projects Asset prototypes, design docs Total file breakdown: 627 .txt (documentation, specs, notes) 500 .cad (CAD model source files) 371 .anm (animation keyframes/timelines) 307 .nca (compiled Nintendo CAD binaries) 268 .c (C source code) 183+ C graphics/asset files (.cgx, .col, .scr, .obj)Tsuyoshi Watanabe’s Star Fox 2 3D Pipeline (AAfundoshi)The AAfundoshi folder is the crown jewel-a complete snapshot of Star Fox 2’s 3D asset production system.The name likely refers to a project codename (fundoshi = traditional loincloth, possibly a team reference or humorous internal nickname).Before diving into individual components, it is essential to understand the complete workflow that NEWS_05 preserves.This is where the significance becomes clear: we see not just code or assets, but the entire system used to create 3D content for the SNES.End-to-End Asset Creationflowchart TD A[\"<b>3D Artist</b><br>Watanabe opens CAD tool\"] --> B[\"<b>Modeling</b><br>Creates .cad geometry<br/>Vertex coordinates, face indices\"] B --> C[\"<b>Animation</b><br>Sets up skeleton/bones<br/>Creates .anm keyframes\"] C --> D[\"<b>Preview</b><br>transanm.c interpolates<br/>PolyDraw.c renders on X11\"] D --> E{Looks good?} E -->|No| B E -->|Yes| F[\"<b>Compile</b><br>transfer.c packs .cad + .anm<br/>Output: .nca binary\"] F --> G[\"<b>Transfer</b><br>Serial/Ethernet to SNES board<br/>Load .nca into VRAM\"] G --> H[\"<b>Hardware Test</b><br>65C816 renders at 60 FPS<br/>Visual feedback via composite video\"] H --> I{Animation<br/>plays right?} I -->|No| C I -->|Yes| J[\"<b>Asset Complete</b><br>.nca committed to stage folder<br/>Ready for ROM build\"]This workflow reveals several critical insights:1. Iteration is Tight Artists get immediate feedback via X11 preview Then real SNES hardware testing for final verification The feedback loop is measured in minutes, not hours2. Non-Destructive Original .cad and .anm source files are preserved .nca binary is regenerated on each compile Bugs in compilation don’t destroy source art3. Collaborative Watanabe (artist) owns .cad/.anm creation Kimura (engineer) owns the tools and compilation Clear separation of artistic and technical concernsThe sheer volume of .nca files (307 total) relative to source .cad (500) and .anm (371) shows this workflow was highly iterative-artists were regularly recompiling and testing.Directory Structure and OrganizationAAfundoshi/├── sf2-1/ through sf2-9/ # Stage/boss asset folders├── sf-myship1/ and sf-myship2/ # Player ship variants├── CAD/ # CAD tool source (26 C files)├── color/ # Shared color palette resources├── sos/ # Sound Output System resources├── test*.cad # Reference/test models├── demo.hex and demo2.hex # Test ROM builds└── cadfun.c # Root CAD integration layerThe presence of test builds (demo.hex, demo2.hex) alongside source assets is telling-this is a working directory, not an archived project.It captures assets mid-development.Stage Folders (sf2-1 through sf2-9) – Detailed BreakdownEach stage folder represents a complete level or boss encounter, with self-contained assets and animations.Stage-by-Stage BreakdownThe table below lists the relevant entries. Stage Files .anm .nca .cad .txt Purpose sf2-1 186 26 23 15 45 Opening/intro stage sf2-2 218 43 32 18 61 Level with enemies sf2-3 126 26 12 14 31 Boss encounter sf2-4 220 26 28 19 58 Mid-game stage sf2-5 210 21 24 17 54 Complex geometry sf2-6 132 16 11 10 29 Late-game stage sf2-7 3 0 0 3 0 Stub/unused sf2-8 13 6 0 0 5 Minimal/test sf2-9 60 9 6 4 15 Final/credits? Total 1,168 173 136 100 298 All stages Sample Asset Naming (from sf2-1)Enemy/Boss Models: ar_walk.nca / ar_wa.anm – “Andross walk” (enemy/boss walking) ar_wa_0.nca, ar_wa_1.nca – Variants (different idle poses) ar_swim.nca / ar_swim.anm – Enemy swimming behavior ar_ro.nca – Enemy rolling/rotating bu_dummy.nca – Dummy collision object (no visual, just hit detection)Player/Ally: my_body.txt – Player ship body definition wa_tu_l.nca – “Wa tu left” (Arwing turret left) walk_l.nca – Player walking animation (left variant) otachi_r.anm – Standing right idle poseLevel Geometry: font_l.cad, font_n.cad, font_o.cad – Text/signage models kabe_ta.cad – Wall tile (kabe = wall, ta = tile) kusa.cad – Grass/foliage Level features (doors, lifts, platforms) – Named lift_0.cad, etc.Resource Notes (.txt metadata): my_body.txt content sample: 3DG1 # Format identifier9 # 9 vertices0 12 14 # Vertex 0 (X=0, Y=12, Z=14)-8 4 08 4 0-5 0 -16... This is a simple vertex list format (text-based 3D model representation). Animation DistributionHigh-animation stages: sf2-2 (43 .anm) and sf2-1 (26 .anm) Likely action-heavy levels with many enemies, bosses Many unique animation statesLower-animation stages: sf2-6 (16 .anm), sf2-9 (9 .anm) Possibly boss battles or cutscenes (fewer diverse enemies) Or test/stub stagesAnimation Sparsity: sf2-7 (0 .anm) is completely empty-likely a placeholder or unused stage cut from final game.Stage Asset PipelineThe presence of .txt, .cad, .nca, and .anm together shows the workflow per stage: Modeling → *.cad (artist creates 3D model in CAD tool) Animation → *.anm (animator sets keyframes in timeline) Compilation → *.nca (transfer.c compiles CAD + ANM → hardware binary) Metadata → *.txt (documentation, parameter notes, engineer comments)Each stage can be built independently, then linked into the final ROM.Deep-Dive: Stage Asset Distribution PatternsThe stage-by-stage file counts tell a story about development priorities and technical constraints.High-Asset Stages (220+ files)sf2-4 (220 files) and sf2-2 (218 files) were the most labor-intensive stages.This suggests either: Complex geometry – many unique 3D models for props, enemies, terrain Long levels – more variation and visual variety requires more assets Gameplay complexity – many enemy types and interactionsThe peak of 43 .anm files in sf2-2 suggests this was an action-heavy stage with many animated characters.Low-Asset Stages (13–60 files)sf2-7 (3 files) is a stub-almost certainly a placeholder or cut stage.The complete absence of .anm files (0 animations) confirms it was never populated.sf2-8 (13 files) is also nearly empty but contains 6 animations, suggesting it may have been a bonus stage or test environment that never shipped.sf2-9 (60 files) with only 9 animations suggests a credits sequence or final cutscene rather than a playable level.Analysis: Why These Distributions?Stage | Files | .anm | Interpretation-----|-------|------|----------------sf2-1 | 186 | 26 | Intro stage: moderate assets, many animations (walking, greeting)sf2-2 | 218 | 43 | Action stage: dense enemies/bossessf2-3 | 126 | 26 | Boss fight: simple geometry, many attack animationssf2-4 | 220 | 26 | Complex stage: varied terrain/props, fewer animation statessf2-5 | 210 | 21 | Mid-game: established asset library, reuses modelssf2-6 | 132 | 16 | Late-game: simpler, more reusesf2-7 | 3 | 0 | STUB: unused, never populatedsf2-8 | 13 | 6 | Test/bonus: minimal, experimentalsf2-9 | 60 | 9 | Credits/finale: sparse, narrative focusThe distribution suggests sf2-4 was the reference stage-the most complete and polished-with later stages optimizing asset reuse.Advanced Analysis: Naming Conventions Reveal Development ProcessNaming Patterns by Asset TypeEnemy/Boss Models: ar_ prefix = Andross-related (main boss) walk, swim, ro = animation states (walk, swim, rotate) _0, _1, _l, _r = variants (left/right, pose 0/1)Example progression: ar_wa.anm → ar_wa_0.nca → ar_wa_1.nca Suggests animation state machine (walking has multiple sub-poses for smooth animation)Level Geometry: font_ prefix = text/signage (font = design element) kabe_ prefix = wall (kabe = Japanese “wall”) kusa_ prefix = grass/foliage (kusa = Japanese “grass”) _ta suffix = tile variant (ta = Japanese “tile”)Collision/Utility: bu_dummy.nca = “collision dummy” (visual shape for hit detection) plane_*.nca = flat geometry for occlusion culling or collision planesWhat This RevealsThe consistent naming convention across 1,168 stage files shows: Established asset pipeline – clear taxonomy of asset types Multiple developers – naming conventions prevent conflicts Japanese team – Japanese suffixes (kabe, kusa) suggest monolingual Japanese developers Reusable components – naming allows assets to be swapped/versionedVariant Numbering StrategyThe presence of multiple variants (ar_wa_0, ar_wa_1, ar_wa_l, ar_wa_r) suggests: 0/1 variants = different animation poses (standing vs. attacking) l/r variants = mirrored geometry (left-facing vs. right-facing) _0a, _0b, _0c = fine-grained iteration (pose refinements)This is optimization: instead of modeling both left AND right, the tool likely mirrors the left model at runtime.Stage Asset PipelineThe presence of .txt, .cad, .nca, and .anm together shows the workflow per stage: Modeling → *.cad (artist creates 3D model in CAD tool) Animation → *.anm (animator sets keyframes in timeline) Compilation → *.nca (CAD + ANM compiled to hardware binary via transfer.c) Metadata → *.txt (documentation, parameter notes, engineer comments)Each stage can be built independently, then linked into the final ROM.3D CAD Tool Source (AAfundoshi/CAD/)The CAD directory preserves complete source code for Nintendo’s proprietary in-house 3D modeling and animation tool, written in C with X11 GUI.This is not a fragment-it is the full source tree, 26 C/H files totaling ~26,000 lines of code.This is remarkable for a simple reason: most game development tools are lost to history.Nintendo’s internal tools almost never surface publicly.NEWS_05 captures the entire architecture of a professional 3D tool used in actual game production.Core Architecture OverviewThe tool is cleanly layered: X11 Frontend – main.c, window.c, menu.c handle user interaction 3D Engine – PolyMain.c, PolyDraw.c manage geometry and rendering Animation System – anim.c, transanm.c handle keyframe-based skeletal animation File I/O – txtfile.c parses source formats, transfer.c compiles to SNES binary Utilities – color.c, screen.c, design.c provide specialized featuresComplete Module Roster CAD Tool Source (40 files) function main - X11 display init and event loop function CheckQuit - Modal quit confirmation with Japanese UI function transfer - Serialize models and animations to SNES format function ParseCADFile - Load `.cad` source into polygon database function ParseTextFile - Load `.txt` vertex lists function PolyCreate - Create/manipulate 3D polygons function AnimPlayback - Timeline scrubbing and frame interpolation function TransformAnimation - Skeletal keyframe interpolation function WindowCreate - X11 subwindow management function MenuDispatch - Route menu selections to handlers variable ToolState - Global tool mode and selection state variable ViewportConfig - Multi-view layout and camera parameters 10 2 26174 The source is cleanly organized around functional domains.Each module handles one major subsystem: UI, 3D geometry, animation, file I/O, or hardware communication. Header files reveal the architecture: ToolBox.h (514 lines) – Widget abstractions and UI components External.h (188 lines) – Global state and data structures Prototype.h (200 lines) – Function declarations MenuRes.h (154 lines) – Menu layout and text resources (in Japanese) This structure matches professional software from the era, with clear separation of concerns. Module Detailstransfer.c (2,373 lines) – The most critical hardware module.Handles the bridge from X11 workstation to SNES development hardware: Serialization of polygon data (vertices, normals, face indices) Animation frame packing (keyframes compressed for 65C816 execution) Hardware communication protocol (likely RS-232 or Ethernet) Error recovery and retry logic Format conversion (.cad + .anm → .nca binary)Historical Curiosity: transfer.c, sos.c, and sos2.c in this directory are all exactly 2,373 lines of code long, despite having distinct contents and purposes!PolyMain.c and PolyDraw.c (825 lines combined) – 3D geometry engine.PolyMain.c (436 lines) manages: Polygon database (vertex arrays, face lists) Mesh manipulation (extrude, scale, rotate, subdivide) Hierarchical transforms (parent-child bone relationships)PolyDraw.c (389 lines) implements: Perspective projection (3D → 2D screen coordinates) Z-sorting (painter’s algorithm for depth ordering) Rasterization (drawing polygons to X11 drawable) Wireframe + shaded rendering modesanim.c and transanm.c (1,396 lines combined) – Animation system.anim.c (1,098 lines) provides: Timeline editor with frame-by-frame playback Keyframe insertion, deletion, modification Smooth interpolation between poses Real-time animation preview in viewporttransanm.c (298 lines) implements: Hierarchical skeletal animation (bones with parent-child relationships) Transform tracks – separate keyframe sequences for translation, rotation, scale per bone Interpolation curves – likely linear, ease-in, ease-out modesThis architecture mirrors modern tools like Maya, suggesting sophisticated animation capabilities.winfile.c (874 lines) – File browser and dialog.Unusual for its size, suggesting: Detailed directory navigation UI File preview/metadata display Multiple file format support (.cad, .txt, .anm) Remember recent fileswindow.c (560 lines) – X11 window management.Handles: Subwindow creation and layout Multi-viewport configuration (top, front, side, perspective views) Resizing and reflow logic Focus and event routingThis level of detail suggests a multi-paned UI, similar to modern 3D software.Build SystemThe build instructions are preserved in an 80-line makefile. Along with the presence of 20+ .o relocatable object files and compiled binaries (3dcad, caduser), the environment clearly involved: Active compilation and linking Multiple build targets (main tool, user variants) Makefile-based builds with dependency tracking directly inside the workspaceKey Discovery: Japanese UI Stringsextern void CheckQuit(MItemPtr item) { char *quitMessage = \"終了してもよろしいでしょうか?\"; // \"Quit OK?\" if (AlertDialog(...) == 1) { /* exit */ }}The presence of Japanese UI strings reveals: Monolingual development team (Japanese developers at Nintendo Japan) X11 message dialogs with modal behavior Localization awareness (strings externalized, not hardcoded)This small detail confirms the tool was built in-house at Nintendo Japan for Japanese developers, not ported from elsewhere.Hardware Communication Protocol (transfer.c Deep-Dive)The 2,373-line transfer.c module deserves its own analysis because it represents the bridge between creative tool and consumer hardware-a critical and complex component.Likely Protocol Structure:Workstation (CAD Tool) ↓ ↓ transfer.c serializes: ↓ - Polygon vertex data (3D coordinates) ↓ - Face indices and normals ↓ - Animation keyframes (time + transform) ↓ - Color palette data ↓ ↓ (RS-232 or Ethernet) ↓SNES Dev Board ↓ ↓ Receives binary .nca format ↓ (Loads into VRAM/WRAM) ↓ ↓ 65C816 executes: ↓ - Model rendering at 60 FPS ↓ - Animation playback ↓Display output for artist feedbackThe massive size (2,373 lines) reflects several complexities: Data compression (models must fit in SNES memory) Error recovery (transmission over serial is unreliable) Format translation (workstation floating-point → SNES fixed-point) Incremental updates (send only changed geometry, not entire model) Hardware quirks (SNES memory bank switching, VRAM paging)This is not a trivial serialization layer; it is a sophisticated communication protocol.Viewport Architecture (screen.c + PolyDraw.c)The multi-viewport system is critical for 3D asset creation. Modern tools use quad-view (top, front, side, perspective); Nintendo’s tool likely did too.screen.c (~250 lines) provides: View configuration – 2×2 quad layout, single view, custom splits Camera control – pan, zoom, rotate per viewport Coordinate system management – orthographic (top/front/side) vs. perspective (camera) Selection highlighting – visual feedback for selected polygons across all viewsPolyDraw.c (~600 lines) implements: Perspective transformation – 3D coordinates → 2D screen projection Painter’s algorithm – Z-sorting polygons from back to front (SNES has no hardware Z-buffer) Rasterization – filling polygons with solid color or texture Shading modes – wireframe (edges only), flat (solid color), gouraud (interpolated lighting) Clipping – culling off-screen polygons to save rendering timeThe painter’s algorithm detail is important: it means the tool must sort all polygons by depth before drawing. This is computationally expensive on a 1990s workstation, suggesting the tool was optimized for interactive performance.Skeletal Animation Deep-Dive (transanm.c + anim.c)The animation system is hierarchical, suggesting bone-based rigging similar to modern tools:Hierarchy Example (Hypothetical Character):Root├── Body (translate/rotate)│ ├── Head (rotate)│ │ └── Eyes (rotate)│ ├── Left Arm (rotate)│ │ └── Left Hand (rotate)│ └── Right Arm (rotate)│ └── Right Hand (rotate)└── Legs ├── Left Leg (rotate) └── Right Leg (rotate)Keyframe Storage (Inferred from transanm.c):Each bone stores separate tracks for: Translation (X, Y, Z) – position in 3D space Rotation (X, Y, Z) – three-axis rotation (Euler angles) Scale (X, Y, Z) – optional geometry scalingAt each keyframe:Frame 0: Root: Translate(0,0,0) Rotate(0,0,0) Scale(1,1,1) Head: Translate(0,5,0) Rotate(0,0,0) Scale(1,1,1) LeftArm: Translate(-2,2,0) Rotate(0,0,0) Scale(1,1,1)Frame 10: Root: Translate(0,0,0) Rotate(0,0,0) Scale(1,1,1) Head: Translate(0,4.8,0) Rotate(15,0,0) Scale(1,1,1) ← Head nods LeftArm: Translate(-2,1.5,0) Rotate(-30,0,0) Scale(1,1,1) ← Arm liftsFrame 20: Head: Translate(0,5,0) Rotate(0,0,0) Scale(1,1,1) ← Back to rest LeftArm: Translate(-2,2,0) Rotate(0,0,0) Scale(1,1,1)Interpolation (anim.c):Between keyframes, the system smoothly tweens:Frame 5 (halfway between 0 and 10): Head: Rotate(7.5,0,0) ← Linear interpolation LeftArm: Rotate(-15,0,0)More sophisticated versions support: Ease-in curves (slow start, fast finish) Ease-out curves (fast start, slow finish) Custom curves (user-defined interpolation)This architecture allows complex character animations with minimal file size (only keyframes stored, not every frame).Animation FrameworkThe .anm and .nca file pairs represent a timeline-based animation system: .cad = Model definition (geometry, materials) .nca = Compiled model + animation keyframes (runtime format) .anm = Animation source (timelines, transforms, possibly higher-level definitions)The presence of animation-specific files like transanm.c suggests the tool supported: Skeletal/bone animation (implied by “transform animation”) Keyframe interpolation (smooth tweening between poses) Multiple animation states (walk, idle, attack, etc. per character)File Format Dissection: From Source to Hardware BinaryThe transformation pipeline .txt → .cad → .anm → .nca reveals sophisticated format design.Each layer serves a specific purpose in the production workflow.Format Layer 1: .txt Vertex Lists (Human-Readable)The simplest format, used for documentation and version control.Sample from sf2-1/my_body.txt:3DG1 # Format ID: \"3D Geometry v1\"9 # Vertex count: 9 vertices0 12 14 # Vertex 0: X=0, Y=12, Z=14-8 4 0 # Vertex 1: X=-8, Y=4, Z=08 4 0 # Vertex 2: X=8, Y=4, Z=0-5 0 -16 # Vertex 34 0 -16 # Vertex 4-16 0 0 # Vertex 516 0 0 # Vertex 60 -8 0 # Vertex 70 16 0 # Vertex 8Format Analysis: 3DG1 signature – allows version detection (future tools could support 3DG2, 3DG3) No face/polygon data – stored separately (likely in a companion file or generated procedurally) Signed 16-bit coordinates – range from -32768 to 32767 Likely units – Game space coordinates, possibly 1/16th pixel or 1/256th world unitWhy text format? Version control – diffs reveal exactly what changed between iterations Human-editable – artists/engineers could tweak coordinates manually if needed Portable – works on any platform (Unix, MS-DOS, etc.) Debuggable – easy to verify correctnessDrawback: High storage overhead (each coordinate takes ~8 bytes as text vs. 2 bytes in binary).This is why .cad files exist.Format Layer 2: .cad Binary Model FilesCompiled from .txt, the binary format optimizes for storage and loading speed.Likely structure:Header (16 bytes): 4 bytes: \"CAD1\" signature 2 bytes: Vertex count 2 bytes: Face count 2 bytes: Bone count (for skeletal animation) 2 bytes: Texture map count 2 bytes: ReservedVertex Array (vertex_count * 6 bytes): 2 bytes: X (signed 16-bit fixed-point) 2 bytes: Y 2 bytes: ZFace Array (face_count * 6 bytes): 2 bytes: Vertex index 0 2 bytes: Vertex index 1 2 bytes: Vertex index 2Normals (optional, vertex_count * 3 bytes): 1 byte: X normal (-128 to 127, as fixed-point) 1 byte: Y normal 1 byte: Z normalAdvantages over .txt: 100× smaller – binary is compact, 6 bytes per vertex vs. 30+ bytes as text Fast I/O – direct memory mapping (no parsing needed) Hardware-friendly – can be DMA’d directly to SNES VRAMFormat Layer 3: .anm Animation Keyframes (Source)Text-readable animation timeline, likely structured as:# StarFox2 Animation: Standing Idle (ar_idle.anm)# Skeleton: Root > Body > Head > LeftArm > RightArmFrame | Bone | TranslateX | TranslateY | TranslateZ | RotX | RotY | RotZ------|-----------|------------|------------|------------|------|------|------0 | Root | 0 | 0 | 0 | 0 | 0 | 00 | Body | 0 | 0 | 0 | 0 | 0 | 00 | Head | 0 | 5 | 0 | 0 | 0 | 00 | LeftArm | -3 | 2 | 0 | 0 | 0 | 00 | RightArm | 3 | 2 | 0 | 0 | 0 | 0# Frame 30 - Slight head nod30 | Head | 0 | 4.8 | 0 | 10 | 0 | 030 | LeftArm | -3 | 2.2 | 0 | 5 | 0 | 030 | RightArm | 3 | 2.2 | 0 | -5 | 0 | 0# Frame 60 - Back to rest60 | Head | 0 | 5 | 0 | 0 | 0 | 060 | LeftArm | -3 | 2 | 0 | 0 | 0 | 060 | RightArm | 3 | 2 | 0 | 0 | 0 | 0Key observations: Sparse keyframe format – only specified frames stored, rest interpolated Per-bone transforms – each bone has independent translation + rotation Frame numbers can skip – 0→30→60 vs. 0→1→2→…→59→60 Floating-point values – precise control (4.8 units, not rounded)Interpolation (anim.c applies):Between frame 0 and 30, the system linearly interpolates Head position: Frame 0: HeadY = 5 Frame 15: HeadY = 4.9 (halfway) Frame 30: HeadY = 4.8If using ease-in curve: Frames 0-10: HeadY = 5 → 4.96 (slow) Frames 10-20: HeadY = 4.96 → 4.82 (fast) Frames 20-30: HeadY = 4.82 → 4.8 (slow)This mimics real-world motion (slow start, fast middle, slow end).Format Layer 4: .nca Compiled Binary (Hardware Format)The final hardware-ready format, output by transfer.c.Inferred structure (based on SNES constraints):Header (32 bytes): 4 bytes: \"NCA1\" or \"NCA2\" signature 2 bytes: Frame count (max 256 frames per animation) 2 bytes: Bone count 2 bytes: Vertex count 2 bytes: Face count 1 byte: Flags (has_normals, has_textures, etc.) ... reserved/paddingKeyframe Data (compressed): For each keyframe: - Packed bone transforms (translation + rotation) - Delta-encoded (only store differences from previous frame) - 16-bit fixed-point (saves space vs. 32-bit float)Vertex/Face Data (static, shared across frames): - Indexed vertex array - Face index list - Normals (if present)Palette References: - Indices into shared color palettes (sf2-1/color/*.col)Compression techniques (likely): Delta encoding – store frame N as delta from frame N-1 Fixed-point math – 16-bit instead of 32-bit floating-point Bone skip – only store bones that change in a given frame Run-length encoding – identical frames compressed to single entryResult: A typical character animation compressed from ~50 KB (.anm text) to ~8-10 KB (.nca binary).Cross-Format ValidationThe presence of all three formats (.txt, .cad, .anm) suggests: Backup protection – if .cad gets corrupted, re-parse .txt Format evolution – tools could auto-convert old .txt to new .cad format Debugging – engineers could inspect .txt to verify .cad correctness Distribution – source assets (.txt/.anm) separate from binaries (.cad/.nca)This is professional software engineering: multiple representations for safety and flexibility.Kimura’s SNES Development Toolkit – Complete InventoryWhile Watanabe focused on 3D assets, Kimura maintained a comprehensive collection of SNES development utilities and support libraries. His workspace is a Swiss Army knife of tools: ~665 files total, 85 C source files, plus compiled binaries across multiple CPU architectures.Utility ArchitectureKimura’s toolkit is organized into specialized subdirectories and CPU-specific variants:kimura/├── util/ # Core utilities (108 files, 51 C source)│ ├── fundoshi/ # CPU-specific (6 C files)│ ├── ibm/ # IBM PC ports (5 C files) │ └── lha/ # LHA compression library├── xl/ # XL project (360 files, 25 C)├── exp/ # Experiments (47 files, 8 C)├── old/ # Legacy code (44 files, 4 C)├── msdos/ # MS-DOS executables (39 files)└── kart/, dummy/, etc. # Other projects (35 files)Utility Breakdown by CategoryGraphics & Asset Encoding (15 utilities)Color/Format Conversion: font2bit.c – Convert font bitmap → 1-bit SNES format (monochrome text) cnv3bit.c – Convert 3-bit indexed color (8-color palette) cnvmode7.c – Convert to Mode 7 rotation/scaling format (used in F-Zero, Kart) cnvbin.c – Generic binary format conversion cnvmode7 – Compiled mode 7 converter (binary)Bitmap/Sprite Tools: bit1.c – 1-bit plane operations bitmap utilities – Manage .cgx (SNES graphics) and .bmp (Windows format) filesROM & Kernel Management (8 utilities)ROM Building: mkrom1.c – Primary ROM builder (creates .hex ROM images from assembled code) mkrom1 – Compiled binary of mkrom1.c Test ROMs: mario.rom, mkart.rom, demo.hex (in AAfundoshi directory)Kernel/Bootloader: ispk0.c, ispk1.c – “Insert SNES Program Kernel” Inserts bootloader stub into ROM Likely for development board initialization Two versions for different ROM layouts Partition Management: partition.c – Manages 1MB ROM chip boundaries (SNES SA-1 boards use multiple EPROMS) parth.bin, partition – Pre-built partitionerSound/Audio Tools (5 utilities)Sound Effects: sfxdmp.c – “SFX Dumper” – extracts sound effects from ROM sfxlst.c – “SFX List” – generates list of SFX from SFX bank sfxdmp – Compiled dumper (binary) sfxlst – Compiled list generatorSound System: sos.c, sos2.c (in AAfundoshi/CAD) – Sound Output System driver Likely SNES audio hardware interface3D & Math Utilities (9 utilities across fundoshi + ibm)Fundoshi Variant (Nintendo-specific CPU optimization?): fundoshi/light.c – 3D lighting calculations fundoshi/depth.c – Depth sorting for painter’s algorithm fundoshi/3d_id.c – 3D object ID generation/tracking fundoshi/anime.c – Animation playback engine fundoshi/stdscr.c – Standard screen buffer management fundoshi/label.c – Label/name assignmentIBM PC Variant (development/preview): ibm/light.c, ibm/depth.c, ibm/3d_id.c, ibm/anime.c, ibm/stdscr.c Identical implementations for PC-based preview/testingStandalone 3D: depth, light, anime, 3d_id, stdscr – Compiled binaries depth.asm, light.asm – Assembly-optimized versions (for hardware performance)This dual-platform approach allowed: Quick asset preview on IBM PC workstations Final optimization and testing on SNES hardware (fundoshi variant) Single C source tree, CPU-specific compilation targetsFile Utilities (10+ utilities)Comparison & Diff: fcmp.c – File comparison (binary or text) cvsource.c – Likely CVS integration (version control)Format Conversion: hex2bin.c, hex2bin – Intel HEX → raw binary u2dos.c, u2dos – Unix → MS-DOS line endings unix2dos.c, unix2msdos.c – Line ending conversion dos2unix.c, ms2unix.c – Reverse conversion mscnv.c, mscnv – MS-DOS to Unix conversionText/Code: tab2spc.c, tab2spc – Tab → space conversion tab8spc.c – Tab → 8 spaces source.c – Source code formatting/processing type.c – File type detectorData Manipulation: cut.c – Binary/text cutting (like Unix cut utility) sum8.c – 8-bit checksum calculator label.c – Label generationHex/Binary Editors (3 utilities) hxed.c – Hex editor source hxed2.c – Hex editor variant hxed, hxed2 – Compiled binariesUsed for low-level binary patching and ROM inspection.Miscellaneous Tools (10 utilities) calc.c – Calculation utilities (possibly for coordinate/parameter computation) getch.c – Character input handler pr201.c – Likely printer driver (NEC PR-201) partition.c – Disk partitioning arrenge.c – Likely “arrange” – data organization utility jisclr.c – Japanese character/JIS handling id.c – ID generation/assignment LHA compression library (7+ files) – Archive/compress assetsXL Project (360 files, 25 C source)Largest sub-project, possibly: An audio/music toolchain (given many audio-related binaries: xlbgm*.bin, xleng*.bin, xlsnd*.bin) Or a comprehensive game development frameworkFile inventory includes: Music/BGM: 24 BGM files (xlbgm01.bin through xlbgm24.bin) Engine: 9 engine modules (xleng01 through xleng09) Sound: 2 sound modules (xlsound.bin, xlsnd01 through xlsnd04) Graphics: Demo/test graphics and palettesCompiled Tool DistributionBeyond source, Kimura’s directory contains 200+ compiled binaries and test ROMs: Standalone tool executables: hxed, fcmp, partition, sfxdmp Test data: Mario, Kart, F-Zero demo ROMs Firmware binaries: tan_table, rp5c77, rp5a22 (likely SNES chip microcode) Audio files: Various .wav, .sfx samples Graphics: Demo palettes, sprite sheets, test imagesBuild EvidenceCompiled artifacts suggest active iteration: Multiple versions of same tools (hxed, hxed2, hex2bin, hexbin) Test data and debug binaries scattered throughout Object files (.o, .rel) indicating in-progress compilation Makefile in root (likely orchestrating all builds)This suggests Kimura’s toolkit was actively maintained and distributed across the development team.Deep-Dive: Kimura’s Dual-Platform ArchitectureOne of the most revealing aspects of Kimura’s 665-file toolkit is the explicit dual-platform design.Nearly every major utility exists in two variants: fundoshi (Nintendo-specific) and IBM (PC-compatible).The Dual-Platform PhilosophyThis architecture solves a critical problem in 1990s game development: iteration speed.Problem: Testing on SNES hardware is slow (serial transfer, compilation, physical board reset) Artists need fast feedback to remain productive But SNES-specific optimizations can’t be previewed on generic hardwareSolution: Two-tier developmentTier 1: IBM PC (Fast Iteration) - Asset import/preview runs instantly - Debugging is interactive - No hardware transfer overhead - Limitations: Can't verify SNES CPU constraints, no hardware renderingTier 2: SNES Hardware (Final Validation) - Real-time performance verification (60 FPS?) - Actual memory usage measurement (VRAM/WRAM budgets) - Hardware rendering behavior (Z-sorting, palette handling) - Pixel-perfect output verificationWorkflow:Artist creates asset → ibm/converter.c tests on PC (1 second) → Looks good? → YES → fundoshi/converter.c optimizes for SNES → transfer.c compiles to .nca → Ship to dev board → Real hardware test (30 seconds) → Bugs? → Loop back to artistry → OK → Commit to stage folderThis is DevOps before it had a name: rapid iteration on cheap hardware (PC), final validation on target hardware (SNES).Detailed Comparison: fundoshi vs. IBM Variants3D Math Libraries (The Core Differentiator)fundoshi variants (fundoshi/light.c, fundoshi/depth.c, etc.): 65C816 assembly optimization Fixed-point arithmetic (no FPU on SNES) Minimal memory footprint Hardware-aware algorithms (e.g., SNES Z-buffer constraints)Example: fundoshi/depth.c likely implements:// SNES fixed-point depth sort// Uses integer-only arithmetic for 65C816void SortPolygonsByDepth(Polygon *polys, int count) { // No floating-point operations // Fixed-point: depth = z << 8 (multiply by 256 for sub-pixel precision) // Bubble sort (fast enough for < 200 polygons per frame)}IBM variants (ibm/light.c, ibm/depth.c, etc.): x86 floating-point math Full precision (IEEE 754 32-bit float) Larger working sets (OK on PC) Direct OpenGL/X11 renderingExample: ibm/depth.c uses:// PC floating-point depth sortvoid SortPolygonsByDepth(Polygon *polys, int count) { // Uses IEEE 754 floats // C library qsort() (generic, not optimized) // Precise depth calculations}Key Insight: The same algorithm implemented twice: Once for precision and correctness (IBM) Once for speed and hardware efficiency (fundoshi)This allows engineers to: Develop algorithm on PC (fast feedback) Profile and optimize for SNES (hardware constraints) Compare outputs to verify correctness (“did optimization break anything?”)Animation Playback: fundoshi/anime.c vs. ibm/anime.cfundoshi/anime.c (SNES version): Fixed timestep (60 FPS, ~16 ms per frame) DMA transfers to update VRAM each frame Sprite attribute writes synchronized to VBlank Lightweight frame cache (only keep 2-3 frames in memory)ibm/anime.c (PC version): Flexible timestep (run at monitor refresh rate, could be 50/60/75+ Hz) Bitmap blitting to framebuffer No VBlank synchronization (X11 is async) Full frame storage (can load entire animation into RAM)Practical result: PC version lets animators scrub through timelines and preview smoothly SNES version ensures exact behavior on target hardwareXL Project: The Audio InfrastructureKimura’s 360-file XL subdirectory deserves special attention.The 24 BGM modules (xlbgm01.bin through xlbgm24.bin) suggest this was a complete audio toolkit.Likely components: Audio Engine (xleng01 through xleng09) APU communication layer (SNES has a separate audio processor) Sound effect playback BGM sequencing Real-time mixing/volume control Sound Effects Library (xlsound.bin, xlsnd01 through xlsnd04) Compiled SFX banks (weapon fire, explosions, footsteps) Indexed by game state (which SFX to play for which action) BGM Database (24 × musical pieces) Titles, composers, loop points Orchestration (which instruments active in each section) Potentially the complete Star Fox 2 soundtrack Historical Context:Star Fox 2’s music is orchestral and complex (arranged by Hiroshi Shibuya, Shoji Maekawa).The SNES APU could play only 8 channels of 16-bit PCM.XL likely managed: Channel allocation per instrument Real-time mixing/layering Tempo synchronization with gameplayCross-Project Asset ManagementThe preservation of experimental, legacy, and multi-project code reveals how Kimura managed a growing codebase.Directory structure shows evolution:util/ # Current/stable utilitiesxl/ # Latest audio projectexp/ # Active experimentsold/ # Legacy code (but kept for reference)kart/ # Specific game (Mario Kart work?)msdos/ # MS-DOS variantsPatterns: Old code is preserved, not deleted – indicates version control awareness (can’t delete what others might need) Experiments are isolated (exp/) – allows risky refactoring without affecting stable code Project-specific folders (kart/) – suggests shared toolkit, project-customized variants Platform support (msdos/) – tools existed in multiple versionsBuild Dependencies: The Compilation GraphThe presence of compiled binaries alongside source code reveals the build strategy.Inference from file types:Source files (.c): 85 files → Each compilable independentlyObject files (.o): 40+ files → Intermediate artifactsLibrary archives (.a): Not visible (inferred)Executables: 20+ utilities (hxed, partition, sfxdmp, etc.)Test data: Mario.rom, mkart.rom, demo.hexMakefiles: At least 1 root makefileBuild system inference:$ make # Recompile all tools → gcc -c util/*.c -o util/*.o → ar rcs libutil.a util/*.o → gcc -c fundoshi/*.c -o fundoshi/*.o → ar rcs libfundoshi.a fundoshi/*.o → gcc hxed.c -o hxed -L. -lutil → gcc partition.c -o partition -L. -lutil → ... (repeat for each tool)$ make test # Verify tools work on test data → ./partition Mario.rom → ./sfxdmp Mario.rom > sfx_list.txt → ... (verify output)This is a mature, professional build system-not ad-hoc, but systematic.Other ProjectsFX2 (Stunt Race FX)A 2.8 MB graphics asset dump for Stunt Race FX (Wild Trax): 42 .cgx graphics files 36 .bak backups 16 .scr screen layouts 15 .col color palettesLikely stage/track graphics and UI elements.3DCADCAD tool UI and demo assets: Screen layouts (.SCR) Color palettes (.COL) Graphics/icons (.CGX) Demo renders of 3D objectsHistorical ProjectsWatanabe’s earlier work preserved on the backup: ZELDA – Early Zelda prototype assets (.MAP, .SCR, .CGX, .COL) PO – 146 directories of miscellaneous material (design docs, prototypes) SG-1 – 82 directories (unknown project) INDY – Small project folder (6 directories)These suggest Watanabe was a long-term developer working across multiple titles, with 3D asset creation becoming a focus by 1995.Technical Deep-Dive: The SF2 3D Pipeline in ActionWorkflow ReconstructionBased on the preserved files and tool structure, here’s the likely development workflow for Star Fox 2:Step 1: Asset Modeling (Artist → Watanabe)Artist creates 3D model in CAD tool ↓ ↓ (CAD/PolyMain.c manipulates geometry) ↓Model saved as .cad file (ASCII vertex list + face definitions)Evidence: aaa.cad, font_l.cad, kabe_ta.cad in AAfundoshi top-level are test/reference models.Step 2: Animation Production (Animator → Watanabe)Animator imports model into CAD tool ↓ ↓ (anim.c timeline editor) ↓Creates keyframes for walk, idle, attack, etc. ↓ ↓ (transanm.c interpolates between keys) ↓Exports as .anm timeline fileEvidence: 173 .anm files total (43 in sf2-2 alone) represent complete character animation sets.Step 3: Compilation (Tool → Hardware)transfer.c (2,373 lines) reads: - .cad file (model geometry) - .anm file (animation timeline) ↓ ↓ (Compiles to binary format) ↓Outputs .nca file (Nintendo CAD Animation binary) ↓ ↓ (Optimizes for SNES CPU/GPU) ↓Transfers via RS-232 serial to SF2 dev boardEvidence: Each stage has ~136 .nca files (compiled binaries) mirroring .cad/.anm pairs.Step 4: Testing (Hardware → Developer)SNES dev board executes .nca binary ↓ ↓ (Renders 3D geometry at 60 FPS) ↓Display on dev board monitor ↓ ↓ (If bug/iteration needed) ↓LOOP back to Step 1The presence of Mario.hex, demo.hex, demo2.hex in AAfundoshi suggests iterative testing builds.Hardware Constraints Visible in DesignMulti-EPROM ROM BoardsThe partition.c tool and mkrom1.c builder show SF2 was targeted at 1MB EPROM chips. With Star Fox 2’s graphics-heavy nature, likely needed: 4 × 1MB EPROM chips (4 MB total ROM) Each stage assets stored in separate memory banks partition.c managed boundaries between banksSNES CPU/GPU LimitationsThe fundoshi-specific 3D library variants suggest optimization for SNES hardware: depth.c – Z-sorting (SNES has no HW Z-buffer, must sort polygons) light.c – Lighting calculations (likely precalculated vertex colors, not real-time) anime.c – Fixed-timestep animation (60 FPS on SNES clock)Memory BudgetThe .nca binary format (compiled CAD + animation) was optimized for 64 KB SNES VRAM and 128 KB WRAM: Likely packed geometry as vertex indices Animation stored as delta-compressed keyframes Color data quantized to 256-entry palettes (.col files)Display ResolutionSNES native resolution is 256×224 (PAL: 256×240). The screen.c viewport manager and stdscr.c (standard screen) utilities managed this constraint.Data Format Analysis.txt (Vertex List Format)Sample from sf2-1/my_body.txt:3DG1 # Signature: 3D Geometry 19 # 9 vertices0 12 14 # Vertex 0: (X=0, Y=12, Z=14)-8 4 0 # Vertex 1: (X=-8, Y=4, Z=0)8 4 0 # Vertex 2: (X=8, Y=4, Z=0)-5 0 -164 0 -16-16 0 016 0 00 -8 0This is a simple ASCII format for 3D point clouds, likely human-editable: No face/polygon information (stored separately) Coordinates in signed 16-bit integers (range: -32768 to 32767) Likely in units of 1/16th pixel or game space units.cad (Model Binary)Compiled form of .txt, likely contains: Vertex array (compacted binary) Face index list Normals (for lighting) Texture coordinates (if applicable).anm (Animation Timeline)Text-readable animation keyframe format, probably:# Frame : Bone : Rotation X : Rotation Y : Rotation Z : Scale : ...0 : head : 0 : 0 : 0 : 1.0 : ...10 : head : 15 : 0 : 0 : 1.0 : ... # Head tilts 15° by frame 1020 : head : 0 : 0 : 0 : 1.0 : ... # Back to 0°Interpolation between keyframes creates smooth animation..nca (Compiled Binary)Final binary format for SNES, likely: Compressed vertex data Pre-calculated transforms Animation frame deltas (only store differences) Palette indices (pointer to shared color palette)Cross-Project Asset SharingThe .txt, .cad, .anm pattern reappears in other watanabe projects (ZELDA, FX2, PO): Project Assets Likely Purpose ZELDA 101 folders of .MAP, .SCR, .CGX Early dungeon prototyping FX2 (Stunt Race FX) 122 folders with race tracks, cars Track/car graphics PO 146 folders of mixed content Design documents, prototypes SG-1 82 folders Unknown project Watanabe likely reused the CAD pipeline across multiple Nintendo SNES projects.Version Control & IterationEvidence of ongoing iteration: .BAK files (backups) scattered throughout Multiple demos (demo.hex, demo2.hex, demo01.cgx through demo24.cgx) .bak versions of models (moji.CGX.BAK → moji.CGX was edited) Multiple naming variants (ar_wa_0.nca, ar_wa_1.nca, ar_wa_l.nca) = testing different posesThis suggests active asset refinement rather than one-shot creation.File StatisticsTop File Types: Extension Count Purpose .txt 627 Documentation, specs, notes .cad 500 CAD model source .anm 371 Animation keyframes .nca 307 Compiled CAD animations .c 268 C source code .cgx 184 Graphics (4-bit indexed color) .col 78 Color palettes .scr 69 Screen layouts .bak 156 Backup/versioning Comparison to Main GigaleakThe table below lists the relevant entries. Aspect Main SFC.7z NEWS_05.tar Type Structured source archive Raw workstation backup Focus Final/compilable code In-progress assets + tools Scope Multi-game (Mario, Zelda, SF1, etc.) Star Fox 2 focus + toolkit Insight What was shipped How it was made Files Source trees (.asm, .c, .h) CAD models, animations, tool source NEWS_05 fills a crucial gap: the development tooling and 3D asset creation process that enabled Star Fox 2’s complex geometry.Preserved Timestamps & Development TimelineChronological AnalysisAll files are dated 1992–1995, clustered around key project phases:Early Phase: 1992 (March–June) PO project – 146 folders, design documents and prototypes ZELDA project – Early dungeon prototyping kanji folder – Japanese character support (34 folders, 2.6 MB) Kimura’s early utilities and experimentsAssessment: Foundation-laying, proof-of-concept phase.Middle Phase: 1993–1994 (March–August) WATANABE/3DCAD – CAD tool UI/demo (March 1994) SG-1 project – 82 folders of unknown project (September 1994) Kimura’s core utilities stabilizing FX2 (Stunt Race FX) graphics assets (August 1995)Assessment: Tool development, experimentation with 3D pipeline.Late Phase: 1995 (Jan–May) - SF2 Crunch Time AAfundoshi – Most recent modifications: May 1995 cadfun executable demo.hex, demo2.hex test builds All 9 stage folders at peak content FX2 – Updated to August 1995 Kimura’s utilities at feature-complete stateTimeline Reconstruction:1992 Q1-Q2: Prototype phase (ZELDA, PO design) ↓1993-1994 Q3: Tool development (CAD framework, 3D lib) ↓1994 Q4: Asset production ramps (all SF2 stages active) ↓1995 Q1-Q2: FINAL PUSH (May updates, demo builds) ↓1995 Q3: Transition to FX2 (August timestamps) ↓NEWS_05 snapshot created (date estimate: ~May-June 1995)Context: SF2 Release & DevelopmentStar Fox 2 was never commercially released on SNES in Japan or USA. Planned release: Announced late 1994 Supposed Q4 1995 launch Cancelled in spring 1995 due to Nintendo 64 shiftNEWS_05 captures SF2 in final development stage (beta/RC phase) before cancellation. The May 1995 timestamps mean this backup was made during or just after the cancellation decision.This adds poignancy: the 1,549 AAfundoshi files represent 3+ years of work that never shipped.Comparison to Main Gigaleak ArchivesNEWS_05 vs. SFC.7z (Main Source Code)The table below lists the relevant entries. Aspect SFC.7z (Organized) NEWS_05 (Raw Backup) Focus Finalized source trees In-progress workspaces Content .asm game code .cad models, .anm animations, tool source Scope 7+ major games (Mario, Zelda, Kart, SF1, SF2, Yoshi, F-Zero) Primarily SF2 (+ toolkit + misc projects) File Organization Hierarchical, well-structured Flat artist/engineer directories Metadata Build scripts, documentation .txt metadata, .BAK iterations Insight What shipped How it was made Complementary Value: SFC.7z = Final game logic (ROM code that shipped or was ready to ship) NEWS_05 = Development process (tools, assets, iteration cycles)Together, they provide unprecedented visibility into SNES game development at Nintendo.Historical SignificanceNintendo’s In-House CAD System (Unique Source)The CAD tool source (26 C/H files, ~26 KLOC) is the only publicly available Nintendo proprietary CAD tool source. This reveals: Architecture choices: X11 GUI (Unix), modular design, transfer protocol Animation system: Hierarchical transforms, keyframe interpolation Hardware bridge: Direct SNES board communication via transfer.c Development process: Artist-friendly (Japanese UI) vs. engineer-friendly (code)This fills a massive gap in game development history-most tool source is lost or proprietary.Complete SF2 3D Asset Pipeline (Second Source of SF2)SF2 source code exists in SFC.7z (asm game logic), but NEWS_05 provides: All 173 animation definitions (walk, idle, attack, death, etc.) 3D models for enemies, bosses, stage geometry CAD workflow that produced the models Stage-by-stage asset inventory (9 stages, 1,168 files)Enables potential: 3D model extraction and recreation Animation analysis Asset re-purposing for ROM hacking/mods Historical recreation of SF2 developmentDeveloper Toolkit Snapshot (Kimura’s Utilities)Kimura’s 85-file C source toolkit is a time capsule of 1990s SNES development tools: Binary format converters (hex, dos, mode 7) ROM builders and partitioners (1MB EPROM management) 3D math libraries (lighting, depth, animation) Sound tools (SFX extraction) Cross-platform variants (PC preview, SNES hardware)This shows the practical engineering behind making SF2-not just the art, but the technical infrastructure.Workstation Snapshot (Institutional Knowledge)The raw directory structure, naming conventions, and file organization reveal: Development team structure (Watanabe = 3D, Kimura = tools, others = system) Workflow conventions (.cad → .anm → .nca pipeline) Iteration patterns (.BAK files, multiple demo builds) Project timeline (1992 prototype → 1995 beta)This is nearly impossible to reconstruct from code alone.What This Archive EnablesFor Preservation: Complete SF2 asset recovery (can reconstruct 3D models from .cad + .anm) Tool reconstruction (CAD tool can be recompiled for emulation/study) Development history (timeline and process documentation)For Research: SNES 3D techniques (how Nintendo solved Z-buffer constraints) Animation systems (keyframe hierarchy and interpolation) Tool design (X11 CAD interface for console development) Hardware optimization (CPU-specific library variants)For Enthusiasts: ROM hacking (use CAD tool to create/modify SF2 content) Asset ripping (extract models, textures, animations) Tool emulation (run CAD tool on modern X11, interface with SNES emulators) Reverse-engineering (study 3D rendering pipeline)Research Implications & Technical OpportunitiesNEWS_05 is not just historical artifact-it is a live research platform with immediate applications.Complete CAD Tool ReconstructionCurrent Status: 26 C/H source files exist, compilable with 1990s-era Unix toolchain X11 dependencies are well-documented and portable No proprietary libraries (tool is self-contained)Reconstruction Path: Install X11 development headers on modern system (Linux, BSD, macOS) Obtain 1990s-compatible C compiler (gcc 2.7 or later works) Compile CAD tool from source Interface with SNES emulator (via mock transfer.c) Recreate Watanabe’s workflow on modern hardwareResearch Value: HCI study – How did 1990s console developers interact with tools? Comparative analysis – How does this tool compare to contemporary tools (Lightwave 3D, Softimage 3D)? Preservation – Tool runs again, software death is avertedChallenge: X11 GUI is outdated; modern equivalent would require Qt or GTK port.Star Fox 2 Asset Extraction & RecreationFeasible outcomes: 3D model extraction – Convert .cad files to Wavefront OBJ or FBX for modern tools Animation extraction – Export .anm keyframes to BVH (Biovision Hierarchy) format Texture recovery – Extract .cgx sprite assets and reconstruct 3D surface textures Complete stage reconstruction – Rebuild all 9 stages in modern engine (Unreal, Unity)Technical hurdles: .cad format is proprietary (needs reverse-engineering from transfer.c behavior) .anm skeleton hierarchy must be inferred from animation names and bone relationships Texture mapping is implicit (need to study how .cgx palettes are applied) Collision geometry may be separate or derived from visible geometryPath forward: Use transfer.c as specification – trace through serialization logic to understand .cad layout Compare extracted 3D models against known SF2 screenshots Iteratively refine extraction until models match visuallySNES 3D Graphics ResearchInsights from NEWS_05:Problem 1: No Hardware Z-Buffer Solution: Painter’s algorithm (sort polygons, draw back-to-front) depth.c implements efficient sorting for this Research question: How does performance scale? (Game had ~200 polygons/frame?)Problem 2: Limited VRAM (64 KB) Solution: Aggressive LOD (Level-of-Detail) system Stage folders show varying geometry complexity across stages Research question: Were assets dynamically streamed or pre-loaded?Problem 3: No Floating-Point Hardware Solution: Fixed-point math throughout fundoshi/ variants show optimization strategies Research question: What precision (bits) was used for transform matrices?Research Framework:Take extracted SF2 3D model ↓Import into research engine ↓Test different Z-sorting strategies ↓Measure frame-time (target: 60 FPS on 3.58 MHz 65C816) ↓Determine feasible polygon count and LOD strategy ↓Publish results: \"How Nintendo Made 3D Work on SNES\"Tool Design & HCI StudyQuestions the CAD tool source answers: How many clicks to create a character model? (menu structure in source) What keyframe formats supported? (anim.c shows capabilities) How did artists manage complexity? (file organization, naming conventions) What was user feedback? (menu item names, dialog wordings)Historical comparison: 1995 Nintendo CAD (NEWS_05) vs. 1995 Lightwave 3D vs. 1995 Softimage 3D vs. 2024 Blender (modern baseline)Metrics to compare: Code complexity (LOC) Feature set (skeletal animation, LOD, collision modeling) Rendering quality (shading algorithms) Export formats (how many output targets)Hardware Optimization Case StudyThe fundoshi vs. IBM parallel implementations offer a unique research opportunity.Controlled Comparison:Take ibm/depth.c (reference, optimized for correctness)Take fundoshi/depth.c (optimized for 65C816)1. Verify they produce identical results (with rounding tolerance)2. Measure performance difference on modern CPU3. Analyze which optimizations had biggest impact: - Fixed-point math - Loop unrolling - SIMD instructions (if present) - Memory layout optimization4. Determine speedup factor5. Apply learnings to other SNES gamesResearch contribution: “Porting Game Algorithms from 65C816 to x86: Lessons from 1990s Development”ROM Hacking & Modding CommunityImmediate applications: Stage Editor Reconstruction Compile CAD tool Modify transfer.c to output SF2-compatible .nca format Create new stages or modify existing stages Build custom ROM with replacement assets Character Model Swaps Extract .cad files from stages Modify geometry (smooth, sharpen, enlarge) Recompile and test in emulator Example: Create “Giant Andross” mod Animation Editing Parse .anm keyframe format Create custom animation editor Blend animations (walk + run hybrid) Slow-motion or speed-up effects Palette Hacking Extract .col color palettes Create new color schemes Apply to all stage assets systematically Community tools that could be built: SF2 Asset Extractor – Command-line tool to dump all models/animations SF2 Model Viewer – 3D preview with animation playback SF2 Stage Editor – Visual editor for stage geometry, enemy placement SF2 Animation Mixer – Blend animations, create new movesComparative Game Development StudyUsing NEWS_05 as primary source:Compare Star Fox 2 (cancelled, NEWS_05) to Star Fox 1 (shipped, source in SFC.7z): Aspect SF1 (SFC.7z) SF2 (NEWS_05) Difference 3D polygon count ? ~200/frame inferred SF2 more ambitious? Animation system Hand-crafted code Skeletal + keyframes SF2 more sophisticated Asset pipeline Unclear Clear (CAD → NCA) SF2 had tool support Development time ? 3+ years (1992-1995) Long iteration cycle Team size ? At least 2 (Watanabe + Kimura) Specialized roles Cancellation impact Shipped Cancelled spring 1995 Development cost wasted Research narrative: “Why Star Fox 2 Failed: Development Process Analysis” SF2 was more ambitious than SF1 (more 3D detail, better animation) But development cycle was longer (3+ years vs. SF1’s likely 18-24 months) Shift to N64 caused cancellation before completion Prototype tool chain was mature, but assets incompletePreservation Challenges & OpportunitiesCurrent StateAll files in NEWS_05 are binary and text-readable, but: .nca format is undocumented – requires reverse-engineering .cad format is proprietary – no public specification .col palette format is implicit – must infer from usage Hardware transfer protocol is unknown – transfer.c would reveal itPreservation Tasks (Priority Order)High Priority: Reverse-engineer .cad format (use txtfile.c as reference) Document .anm keyframe format Extract complete SF2 3D models Catalog all 307 .nca files and their source .cad/.anm pairsMedium Priority: Compile and run CAD tool in emulated Unix environment Document hardware transfer protocol (read transfer.c in detail) Create model extraction tools (CAD → OBJ, ANM → BVH) Compare NEWS_05 assets against final SF2 development ROM (if discovered)Low Priority: Port CAD tool to modern GUI framework Create web viewer for 3D models Analyze XL audio toolkit in detail Study historical art/animation iteration (via .BAK files)", "excerpt": "NEWS_05.tar is a 109 MB workstation backup snapshot from a Nintendo developer’s machine, dated around May 1995. Unlike the structured source-code drops elsewhere in the Gigaleak, NEWS_05 captures raw mid-development working directories from two prolific engineers: one focused on 3D asset production, the other on development tools and infrastructure. With...", "tags": ["snes","leak","sourcecode","tools"], "image": "/public/generated/placeholders/gigaleak-news-05.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Gigaleak - NEWS_11 Workstation Restore (Hino)", "url": "/gigaleak-news-11", "content": "Gigaleak - NEWS_11 Workstation Restore (Hino)NEWS_11 is a restored workstation snapshot centered on a user home directory called hino.It is mostly art and tool data, not game source code.The high-signal thing it preserves is the workflow split: palettes in COL tiles in CGX screen composition in SCR sprite and object layout in OBJ and OBX CAD-side metadata in SFXIf you want the decoding details, these two pages cover the formats directly: Super Famicom / SNES File Formats SNES workstation formats: COL, CGX, SCR, OBJ/OBX, SFX, and related tooling. Game Boy File Formats (DMG, GBC) Game Boy workstation formats, including DMG-style 2bpp tile banks in CGX. Root DirectoryAt the top level, NEWS_11 is just a tarball and one extracted home tree. Path Notes NEWS_11.tar the original archived restore hino/ extracted workstation home directory What Is Inside hinoThis restore is large enough that file counts are useful.Across the full tree there are 3,487 files.The most common file types are exactly the SNES CAD formats: Extension Count CGX 1,281 OBJ 917 SCR 873 COL 781 PNL 487 BAK 442 And the largest project workspaces under hino/ are: Folder Files Notes yoshi/ 2,271 huge SNES art workspace with dense backups hati-toru/ 761 another large art workspace split into many subfolders z-mario-4/ 704 SNES Mario project art workspace dominated by SCR/CGX/OBJ/COL z-sword/ 433 Zelda-like art workspace with MAP and panel resources NEW-CHR/ 245 panel-heavy PNL workspace with many backups z-dmg-zelda/ 73 DMG-style Zelda art data stored in the same CAD family Major WorkspacesThe top-level layout is flat, but it clusters into a few obvious projects. z-dmg-zeldaThis folder is small, but it is one of the most interesting.It preserves DMG-style Zelda art stored in the same workstation container formats as the SNES projects.The contents are a tight set of: end-demo-* screen and object assets (CGX, SCR, OBJ, COL) wak.* and kihon.* base assets and palettes a single kihon.SFX metadata sidecar rendered PNG previews beside some screensThis is also where the 2bpp vs 4bpp distinction becomes visible in practice.Several SCR files reference tile ranges that only fit if their paired CGX is decoded as 2bpp.yoshiyoshi/ is the largest subtree by far.It looks like a long-lived SNES art workspace with real iteration history: hundreds of BAK backups dense CGX, COL, SCR, and OBJ banks large runs of panel resources (PNL) and compressed object banks (OBZ) many subfolders that read like specific scenes, map variants, or asset groups (ENDING, SPR, V-RAM, NEW-MAP, KOOPA-FINAL)This is the folder that best shows how the pipeline worked day-to-day, because it keeps so much intermediate state and backup material.z-mario-4This is a high-density SNES art workspace dominated by: SCR screen composition files CGX graphics banks OBJ object and sprite layout COL palette banksIt also carries a small cluster of SFX sidecars.So it is a good place to study the full COL + CGX + SCR + OBJ layer stack for menu-like or UI-heavy assets.z-swordz-sword/ is a strong “everything in one place” art workspace.Compared with z-mario-4, it adds: MAP resources lots of PNL panel files a more even mix of OBJ, CGX, SCR, and COLIt also has stock folders (BG-stock, CHR-stock, COL-stock, V-RAM) that look like shared banks or staging areas.SRD Tools and CAD SupportThe srd/ folder is unusually valuable because it is not a project asset tree.It looks like a tool and documentation bundle: srd/bin/ includes binaries like cad, cad_chk, and obj_tool_chk srd/cad/sfc/ includes sfx_main.hex, obj_tool.hex, and related ADD files srd/cad/bin/ includes transfer and print utilities like pr_scr_*, pr_col_*, pr_obj_*, pr_chr_* srd/doc/ contains tool documentation (README.doc, cad helpers, arc, taraka, sf, srd)If you are trying to understand how these formats were produced and moved around, this is the most directly “tooling shaped” part of the restore.What SRD MeansIn this tree, srd clearly acts like a shared tools prefix, with references to /usr/local/srd/bin and /usr/local/srd/doc.SRD is Systems Research & Development, the name used by the long-running Nintendo partner company SRD Co., Ltd.SRD is also known for having operated a CAD software division for decades.That matters here because NEWS_11 preserves not just project assets, but what reads like an installable CAD tool bundle with dedicated output and transfer utilities for CHR (CGX), COL, SCR, OBJ, PNL, and MAP.So the practical reading here is: srd/ is a shared internal tool bundle the tools and docs are installed and managed under /usr/local/srd the same name aligns with the SRD organization that historically shipped tooling and development support around Nintendo projectsThe Host Machine and RuntimeSeveral of the core tools are compiled MIPS big-endian executables in ECOFF format: srd/bin/azrael srd/bin/emln srd/bin/taraka srd/bin/lpf_xwdpr801ymc srd/cad/bin/cad and the pr_* print utilitiesThat points to an IRIX-era MIPS workstation environment.The srd/bin folder also mixes in small shell scripts that act as wrappers and checks./usr/local/srd As a “Command Registry”The Japanese srd/doc/README.doc describes the intent of /usr/local/srd/bin: commands registered there are free to use if you need to modify one, you copy it into your own directory first every command requires a matching *.doc description under /usr/local/srd/doc new commands must be general-purpose, not project-private the directory is managed by the superuserThe srd command itself is documented as a tool that prints the list of registered commands.It also notes there were separate CISC and RISC variants with different registered command sets.CAD Tool BundleThe srd/cad/ subtree is the closest thing to a packaged CAD distribution in NEWS_11.It has three layers: srd/cad/bin/: the main cad binary and a matching set of print utilities srd/cad/options/: CAD option and helper config files (sfx_main.OPT, obj_tool, cad_clear) srd/cad/sfc/: Super Famicom-side hex payloads and their ADD sidecarsThe srd/cad/bin/readme.doc file lists the required binaries, and the names line up perfectly with the formats seen elsewhere in NEWS_11: pr_chr_* prints character banks (CGX) pr_col_* prints palettes (COL) pr_scr_* prints screen composition (SCR) pr_obj__ prints objects (OBJ) pr_obj_Q prints object sequences (OBJ SEQ) pr_pnl__ prints panels (PNL) pr_map__ prints maps (MAP)That is a very direct confirmation that these extensions are not just “game blobs”.They are first-class CAD layers with dedicated output paths.Super Famicom PayloadsThe srd/cad/sfc/ folder includes the tool-side payloads that match the CAD metadata formats: File Size Notes sfx_main.hex 130,690 bytes the main CAD SFX support payload sfx_main.ADD 3,414 bytes sidecar associated with sfx_main obj_tool.hex 4,680 bytes object tooling payload sfx_clear.hex 514 bytes small helper payload color_change.hex 331,062 bytes large color-change payload plus color_change.ADD The important point is not that these are “ROMs”, but that they are tooling-side payloads sitting directly beside the CAD environment.They help explain why formats like SFX exist at all: they are part of a tool pipeline, not a game runtime format.Example Tool DocsTwo of the srd/doc/*.doc files are especially revealing: arc is a simple archiver that bundles multiple files into one and compresses them azrael edits MAP files and checks overlap and bank overflow across multiple map inputs, marking issues per-line and returning status 1 on failureThose descriptions line up neatly with the rest of the restore:NEWS_11 is full of intermediate CAD assets, and srd/ preserves the “plumbing” used to validate, print, transfer, and manage them.", "excerpt": "Gigaleak - NEWS_11 Workstation Restore (Hino) NEWS_11 is a restored workstation snapshot centered on a user home directory called hino. It is mostly art and tool data, not game source code. The high-signal thing it preserves is the workflow split: palettes in COL tiles in CGX screen composition in SCR...", "tags": ["nintendo","gigaleak"], "image": "/public/generated/placeholders/gigaleak-news-11.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Hacking", "url": "/hacking", "content": "Hacking History1988 - MORRIS: Earth’s First Computer WormDisrupt has published a retrospective on the Morris Worm, detailing the specific vectors exploited by the 99 lines of code written by Robert Tappan Morris (RTM) to map the early internet, and how a mathematical error led to global system overloads.Technical Details & Exploitation Vectors: Buffer Overflow (Finger Protocol): The vulnerability was a classic stack-based buffer overflow. The fingerd daemon used the C standard library function gets(), which reads input without checking buffer boundaries. The worm sent a single, carefully crafted 536-byte string (including shellcode) that overflowed the 512-byte buffer. This overwrote the return address on the stack, redirecting the execution flow to the worm’s malicious code. Sendmail Debug Mode: The worm exploited a known DEBUG mode in the sendmail program, which was often left enabled on production systems. By issuing the DEBUG command, the worm could directly execute arbitrary shell commands. It used this to pipe a small C script to the shell, which then compiled itself and fetched the main worm binaries.. Socket Creation: Upon entering a machine, it establishes a socket (described as a PO box) to receive data. Payload Delivery: It sends three packages to the established socket: a Sun-3 binary version of the worm, a VAX version, and the source code, ensuring compatibility with the recipient machine. The original worm then eliminates itself. Propagation Mechanism (The 1-in-7 Bug): To prevent system admins from using a false flag to stop the worm, Morris programmed it to disregard the “already infected” flag 1 out of every 7 times. This caused the worm to repeatedly infect and overload systems rather than just acting as a background measuring stick.Mitigation & Legacy: Patches: Berkeley faculty released patches 1 and 2 to stop sendmail from accepting the debug command and compiling with the worm. Patch 3 altered finger so it now uses fgets instead, patching the buffer overflow. Legal Precedent: The author was the first person in U.S. history indicted under the newly defined Computer Fraud and Abuse Act.2000 - ILOVEYOU Virus: Technical Breakdown and DemonstrationNationSquid features a technical overview and demonstration of the ILOVEYOU worm, focusing on its VBScript architecture and rapid propagation through the MAPI interface. The video details how the malware manipulated files and utilized social engineering to achieve widespread system infections and data loss.2005 - Samy Worm: The Myspace XSS ExploitMotherboard features an interview with Samy Kamkar detailing the infamous 2005 “Samy Worm” that took down Myspace. Kamkar explains the technical mechanics of the Cross-Site Scripting (XSS) vulnerability that allowed the worm to exponentially propagate by automatically adding him as a friend and infecting visiting profiles. The video also covers the aftermath, including the site-wide outage and the legal repercussions that led to a three-year ban from computer use.Hacking Random NumbersHow hackers reverse Math.random()Zanzlanz has a video that explores the mechanics and vulnerabilities of pseudo-random number generators (PRNGs), focusing on Linear Congruential Generators (LCGs) and Xorshift algorithms. It demonstrates practical techniques for reverse engineering these functions to predict future values and recover previous states, illustrated by exploiting Flash-based games like Minesweeper.", "excerpt": "Hacking History 1988 - MORRIS: Earth’s First Computer Worm Disrupt has published a retrospective on the Morris Worm, detailing the specific vectors exploited by the 99 lines of code written by Robert Tappan Morris (RTM) to map the early internet, and how a mathematical error led to global system overloads....", "tags": ["industry","hacking"], "image": "/public/generated/placeholders/hacking.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Handheld Consoles Reverse Engineering", "url": "/handhelds", "content": "IntroductionHandheld consoles have been a significant part of the gaming industry for decades, offering portable gaming experiences that allow players to enjoy their favorite games on the go. These devices have evolved considerably over time, from simple LCD-based systems to sophisticated multimedia platforms.This page will cover not the obscure commerical handheld consoles that many people may have forgotten about.Game.com (Tiger Electronics)The Game.com (pronounced “game com”) was a handheld game console released by Tiger Electronics in 1997. It was designed to compete with other handheld gaming devices of its time, such as the Nintendo Game Boy and the Sega Game Gear. However, despite some innovative features, the Game.com ultimately struggled to gain traction in the market. Tiger Game (dot) com Reverse Engineering For more information about the Game.com check out this post. GP32 (Game Park Holdings)The GP32 is a handheld gaming console developed by the South Korean company Game Park Holdings. It was released in November 2001. One of the notable features of the GP32 was its open architecture, which allowed independent developers to create and distribute their own games and applications for the platform without the need for official licensing or approval.The GP32 was powered by a 133 MHz ARM 920T (32-bit RISC) processor and featured a 320x240 pixel LCD screen. It utilized SmartMedia cards for game storage, allowing users to easily swap out games and applications. The device also had built-in support for MP3 playback and electronic books, expanding its functionality beyond gaming.Although the GP32 did not achieve the same level of commercial success as some of its competitors, such as the Nintendo Game Boy Advance, it gained a dedicated following among enthusiasts and indie developers due to its open nature and potential for homebrew development.GP32 GamesThere were 28 commercial games released for the GP32, Wikipedia has a page listing them all:List of commercial GP32 games - WikipediaGP2X (Game Park Holdings)The GP2X is a handheld gaming console developed by the South Korean company GamePark Holdings. It was released in 2005 as the successor to the GP32. The GP2X was notable for its open architecture and support for homebrew software, much like its predecessor.The GP2X ran on a Linux-based operating system, which provided a stable and customizable platform for developersPokemon Mini (Nintendo)The Pokemon Mini was a low profile handheld games console developed by Nintendo’s System Development Division (SDD) in partnership with Jupiter Corporation and released in Japan on December 14th 2001. Pokemon Mini For more information about the Pokemon Mini check out this post. Wonderswan (Bandai)The Wonderswan is a classic video game console that was only ever released in Japan (on 4th March 1999). Wonderswan Reverse Engineering For more information about the Bandai Wonderswan check out this post. Lynx (Atari)The Atari Lynx is a handheld gaming console released by Atari Corporation in September 1989. One of the most significant features of the Atari Lynx was its color LCD screen compared to the Game Boy’s monochrome screen.Game Gear (SEGA)The Game Gear was a handheld gaming console that was released by SEGA in 1990, and was notable for its full-color backlit screen and library of classic SEGA games. Sega Game Gear Reverse Engineering For more information about the Sega Game Gear check out this post. ", "excerpt": "Introduction Handheld consoles have been a significant part of the gaming industry for decades, offering portable gaming experiences that allow players to enjoy their favorite games on the go. These devices have evolved considerably over time, from simple LCD-based systems to sophisticated multimedia platforms. This page will cover not the...", "tags": ["gba","gameboy","gamecom","gamegear","handhelds"], "image": "/public/generated/placeholders/handhelds.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo Hidemaru Mail Leak", "url": "/nintendo-hidemaru-mail-leak", "content": "IntroductionIn 2020 and 2021 numerous secret files have been leaked from Nintendo thanks to Zammis Clark. Included in these files were the Corporate Emails inbox of an employee called Murakawa Tsushin.Note that this post is under construction, there are thousands of emails to go through, if you have any time then please consider contributing by editing this page in github.What was leakedThe archive teru-sama_mail_2006.7z was leaked to 4chan on the 20th July 2021, it is a dump of Murakawa Tsushin’s emails from the Hidemaru Mail client.Who is Murakawa?Murakawa was in charge of localisation from Japanese to Korean/English and lots of European languages. This is probably why Zammis Clark targeted him as he is a huge Pokemon fan and couldn’t wait for the English release of the games.He worked in the Planning and Development Department for Nintendo of Japan.What is Hidemaru Mail?HidemaruMail is a Japanese application for managing email similar to the function of Microsoft Outlook. It just so happens a Nintendo employee used this software in 2006 and his email archive was downloaded by Zammis Clark and later released online for all to see.Hidemaru Mail (/hidemaruMail) hidemaruMail This folder contains backup copies of the users address book along with the main sub directories: mail.nintendo.co.jp - all emails that were sent to this user TempMail 0 - empty folder Files in this folder are described in the table below. File Name Extension Description AdrBook .bk0, .bk1, .bk2, .bk3, .bk4, .bk5, .bk6, .bk7, .bk8, .bk9, .txt Employee’s address book with everyone that worked at Nintendo at the time subdir .bin Presumably some meta-data that HidemaruMail email client creates, literally just contains the string mail.nintendo.co.jp The Address Book backup files are pretty much identical if you compare them so if you are interested in seeing everyone who worked at Nintendo in 2006 then just use the standard AdrBook.txt.Mail.nintendo.co.jp (/mail.nintendo.co.jp) mail.nintendo.co.jp This folder contains the following sub folders: Remote - Empty folder User - Empty folder ゴミ箱 - Trash Can 受信 - Inbox 受信HTML - HTML inbox 受信ログ - Inbox Log 受信添付 - Attachments received 未送信 - Unsent (Empty) 草稿 - Draft (Empty) 送信ログ - Transmission log 送信添付 - Attachments sent 送信済み - Sent box Files in this folder are described in the table below. File Name Extension Description UIDL .bin Unique ID Listing file used by the POP3 email client account .bin encrypted user account file account.bak .bin backup of user account file filter .bk0, .bk1, .bk2, .bk3, .bk4, .bk5, .bk6, .bk7, .bk8, .bk9, .txt Filter list, so if an email matches a pattern it will go into a specific folder, all backups are the same file The only file that might be mildly interesting is filter.txt as if you are looking for emails for a specific project this can give a hint as to what folder it is in, or what email addresses to look for.Murakawa’s newsletter (/mail.nintendo.co.jp/User/村川通信) User/村川通信 This folder contains all the emails sent out by Murakawa for his Newsletter called the Murakawa Tsushin. He seems to send out some sort of newsletter with random, sometime games related content. File Name Extension Description 村川通信200506 .txt Comparison of wireless communication functions between Nintendo DS and PSP 村川通信200507 .txt News about Dark basic (3D game programming language with BASIC syntax) 村川通信200508 .txt Not much news as he is preparing for a wedding 村川通信200509 .txt Talk about the PocketMod which is a printable PDA apparently.. (http://www.pocketmod.com/) 村川通信200510 .txt Shares a link talking about Nintendo DS Homebrew! 村川通信200511 .txt Links to a yahoo headline about the Cell Architecture in the PS3 村川通信200512 .txt Compares the price of Apple products with Nintendo 村川通信200601 .txt Links to article talking about Pixar being acquired by Disney 村川通信200602 .txt Links to a book called “Sony Chronicle 2006” which has thousands of pictures of Sony products through the ages 村川通信200603 .txt Has a link to Review-C an application by NEC that statically analysis C code to find problems 村川通信200604 .txt Link to a Japanese book on how to write your own CPU in 30 days by Hidemi Kawai (looks like a really interesting book) 村川通信200612 .txt Links to a page selling a little wiimote key ring, looks very cute The Homebrew Nintendo DS link that he has shared in one of his newsletters is no longer available but it has been archived by the wayback machine: hereOne very interesting Japanese website that is commonly linked in the newsletter for programmers is Game Watch: Graphics course for 3D game fansPast Log Chats (/mail.nintendo.co.jp/User/過去ログ/雑談) /mail.nintendo.co.jp/User/過去ログ/雑談 This folder contains general chat about video games and the industry, mildly interesting but don’t go out of your way to read it. File Name Extension Description 雑談200506 .txt Talking about Space Channel 5, Jet Set Radio Future, C programming question and more 雑談200509 .txt Talking about Xavix using images of Jackie Chan to promote their wii Fit like product 雑談200510 .txt Talking about gambling machines? 雑談200601 .txt Talk about a GPS based-game for DS, suggests Pokemon Go like functionality (10 years before that was a thing) 雑談200602 .txt Joke about hexadecimal representation (I think..) 雑談200603 .txt Organising a drinking party 雑談200605 .txt Talk about the new Sony VAIO mobile phone 雑談200609 .txt Talk about aquariums and PS3 launch Trash Can (/mail.nintendo.co.jp/ゴミ箱) /mail.nintendo.co.jp/ゴミ箱 This folder contains deleted emails, you probably could have guessed that, nothing of value is in here. File Name Extension Description ゴミ箱200611 .txt Spam mail about flowers ゴミ箱200612 .txt Games industry emails such as DICE, lots of overtime requests for Pokemon and Localization from his employees Inbox (/mail.nintendo.co.jp/受信) /mail.nintendo.co.jp/受信 This folder contains the following sub directories: CW for NintendoDS - Discussion between Metrowerks and Nintendo on the CodeWarior for Nintendo DS product DS Socket Lib - Mailing list discussing the Nintendo DS netwokring SDK NOA Doc NOK関連 NintendoDS Pokemon emerald for Euro Revolution SPD ALL SPD GM SPD TI Wi-Fiガイドライン ML dea-5p-sup ML dea-sup アカウント関連 サーバ管理 ポケモン 人事関連 会議のスケジュール 部内技術サポート The files in the root of this directory are described in the table below. File Name Extension Description 受信200505 .txt   受信200506 .txt   受信200506_92 .txt   受信200507 .txt   受信200507_55 .txt   受信200508 .txt   受信200509 .txt   受信200510 .txt   受信200511 .txt   受信200512 .txt   受信200601 .txt   受信200602 .txt   受信200603 .txt   受信200603_01 .txt   受信200604 .txt   受信200604_03 .txt   受信200604_07 .txt   受信200605 .txt   受信200606 .txt   受信200607 .txt   受信200608 .txt   受信200609 .txt   受信200609_02 .txt   受信200610 .txt   受信200610_01 .txt   受信200610_02 .txt   受信200611 .txt   受信200611_01 .txt   受信200612 .txt   受信200612_01 .txt   受信200612_02 .txt   受信200612_03 .txt   受信200612_04 .txt   CodeWarrior for Nintendo DS (/mail.nintendo.co.jp/受信/CW for NintendoDS) CW for NintendoDS This folder contains communication between Metrowerks (who develop the CodeWarrior IDE) and Nintendo. Specifically for the Nintendo DS version of CodeWarrior. As you can imagine when creating a compiler and IDE for the Nintendo DS, there were lots of messages between Nintendo and Metrowerks clarifying points and discussing bugs. Emails in this folder contain mentions of Ensata which is an in-house developed Nintendo DS emulator. Note that during 2005 Metrowerks became part of Freescale Semiconductor, so many of the emails mention Freescale but they are still talking about the same Metrowerks CodeWarrior IDE. File Name Extension Description CW for DintendoDS200510 .txt Talk about the Ensata emulator version 1.4 CW for DintendoDS200511 .txt Talk about Nitro SDK 3.0 CW for DintendoDS200512 .txt Talk about Debugger patch for CodeWarrior for NINTENDO DS 1.2 SP3 (2005/12/13) CW for DintendoDS200601 .txt Talk about Code Overlays for the Nintendo DS CW for DintendoDS200602 .txt Talk about CW for DS 2.0 compiler (Version 3.0) CW for DintendoDS200603 .txt Talk about CodeWarrior for NINTENDO DS 2.0 FC version CW for DintendoDS200604 .txt Official release of CW for NDS 2.0 to developers CW for DintendoDS200605 .txt Release of the Nintendo DS SDK 3.1 CW for DintendoDS200606 .txt Compiler patch for CodeWarrior for NINTENDO DS 2.0 (2006/6/16) CW for DintendoDS200607 .txt Release Ver. 1.4d of the Ensata DS Emulator CW for DintendoDS200608 .txt CodeWarrior for NINTENDO DS Version 2.0 Service Pack 1 Announcement CW for DintendoDS200609 .txt Details about the .NEF (Nintendo Elf Format) used for DS executables CW for DintendoDS200610 .txt Metrowerks moved from their eSupport system to Radix Live CW for DintendoDS200611 .txt Release of CodeWarrior for NINTENDO DS 2.0 SP1 Build Tool Patch 2 Nintendo DS Socket Library (/mail.nintendo.co.jp/受信/DS Socket Lib) DS Socket Lib This folder contains discussions talking about the networking (socket) SDK for the Nintendo DS. So bugs and other issues are discussed in this mailing list, but of the emails we have none are particularly interesting. File Name Extension Description DS Socket Lib200506 .txt Just talks about a new internal page being setup called the “Nintendo Wi-Fi Connection Support Page” DS Socket Lib200507 .txt Just a notice saying that “Nintendo Wi-Fi Connection Planning Study Material (2005/06/22 version)” has been uploaded DS Socket Lib200508 .txt Notice of a bug in the function SO_SendTo returning SO_ENOBUFS DS Socket Lib200509 .txt Notice of infinite loop in OS_LoadContext which gets fixed in a new release of the SDK DS Socket Lib200510 .txt Just contains a list of the email addresses of the people that subscribe to the mailing list Nintendo of Amercia documents (/mail.nintendo.co.jp/受信/NOA Doc) NOA Doc This folder contains… File Name Extension Description NOA Doc200601 .txt   NOA Doc200602 .txt   NOA Doc200603 .txt   NOA Doc200604 .txt   NOA Doc200605 .txt   NOA Doc200606 .txt   NOA Doc200607 .txt   NOA Doc200608 .txt   NOA Doc200609 .txt   NOA Doc200610 .txt   NOA Doc200611 .txt   NOA Doc200612 .txt   Nintendo of Korea (/mail.nintendo.co.jp/受信/NOK関連) NOK関連 This folder contains… File Name Extension Description NOK関連200607 .txt   NOK関連200608 .txt   NOK関連200609 .txt   NOK関連200610 .txt   NOK関連200611 .txt   NOK関連200612 .txt   Nintendo of Korea Mailing Lists (/mail.nintendo.co.jp/受信/NOK関連/NOK ML) NOK ML This folder contains… File Name Extension Description NOK ML200609 .txt   NOK ML200610 .txt   NOK ML200611 .txt   NOK ML200612 .txt   Korean version Mailing list (/mail.nintendo.co.jp/受信/NOK関連/えいご漬け韓国語版 ML) えいご漬け韓国語版 ML This folder contains… File Name Extension Description えいご漬け韓国語版 ML200610 .txt   えいご漬け韓国語版 ML200611 .txt   えいご漬け韓国語版 ML200612 .txt   Nintendo DS Mailing list (/mail.nintendo.co.jp/受信/NintendoDS) NintendoDS This folder contains… File Name Extension Description 似顔絵 ML200606 .txt   似顔絵 ML200607 .txt   似顔絵 ML200608 .txt   似顔絵 ML200609 .txt   似顔絵 ML200610 .txt   似顔絵 ML200611 .txt   Pokemon emerald for euro (/mail.nintendo.co.jp/受信/Pokemon emerald for Euro) Pokemon emerald for Euro This folder contains… File Name Extension Description Pokemon emerald for Euro200505 .txt   Pokemon emerald for Euro200506 .txt   Pokemon emerald for Euro200507 .txt   Pokemon emerald for Euro200512 .txt   Wii (/mail.nintendo.co.jp/受信/Revolution) Revolution This folder contains… File Name Extension Description Revolution200604 .txt   Revolution200605 .txt   Revolution200606 .txt   Revolution200607 .txt   Revolution200608 .txt   Revolution200609 .txt   Revolution200610 .txt   Revolution200611 .txt   Wii E3 (/mail.nintendo.co.jp/受信/Revolution/E3) E3 This folder contains emails sent to everyone preparing for E3 2006 such as playble demo guidelines and due dates. File Name Extension Description E3200604 .txt Talks about the deadlines for E3 deliverables such as playable demos and video content E3200605 .txt Contains branding instructions for what logo to use and information for travelling to E3 Opera browser Mailing List (/mail.nintendo.co.jp/受信/Revolution/Opera browser ML) Opera browser ML This folder contains… File Name Extension Description Opera browser ML200607 .txt   Opera browser ML200608 .txt   Opera browser ML200609 .txt   Opera browser ML200610 .txt   Opera browser ML200611 .txt   Opera browser ML200612 .txt   Wii homemenu by Intelligent systems (/mail.nintendo.co.jp/受信/Revolution/REVO_HomeMenuintsyscojp) REVO_HomeMenuintsyscojp This folder contains… File Name Extension Description REVO_HomeMenuintsyscojp200608 .txt   REVO_HomeMenuintsyscojp200609 .txt   REVO_HomeMenuintsyscojp200610 .txt   Rvlネットワーク関連 (/mail.nintendo.co.jp/受信/Revolution/RVLネットワーク関連) RVLネットワーク関連 This folder contains… File Name Extension Description RVLネットワーク関連200604 .txt   RVLネットワーク関連200605 .txt   RVLネットワーク関連200606 .txt   RVLネットワーク関連200607 .txt   RVLネットワーク関連200608 .txt   RVLネットワーク関連200609 .txt   RVLネットワーク関連200610 .txt   Wii preview関連 (/mail.nintendo.co.jp/受信/Revolution/Wii Preview関連) Wii Preview関連 This folder contains… File Name Extension Description Wii Preview関連200608 .txt   Wii Preview関連200609 .txt   Wii Lot Check Mailing List (/mail.nintendo.co.jp/受信/Revolution/Wii lotcheck ML) Wii lotcheck ML This folder contains… File Name Extension Description Wii lotcheck ML200608 .txt   Wii lotcheck ML200609 .txt   Wii lotcheck ML200610 .txt   Wii lotcheck ML200611 .txt   Wii lotcheck ML200612 .txt   Wiiツール輸出規制 ml (/mail.nintendo.co.jp/受信/Revolution/Wiiツール輸出規制 ML) Wiiツール輸出規制 ML This folder contains… File Name Extension Description Wiiツール輸出規制 ML200606 .txt   Wiiツール輸出規制 ML200607 .txt   Wiiツール輸出規制 ML200608 .txt   Ml-revo-info (/mail.nintendo.co.jp/受信/Revolution/ml-revo-info) ml-revo-info This folder contains… File Name Extension Description NNGC ML200509 .txt   NNGC ML200510 .txt   NNGC ML200511 .txt   NNGC ML200512 .txt   NNGC ML200601 .txt   NNGC ML200602 .txt   NNGC ML200603 .txt   NNGC ML200604 .txt   NNGC ML200605 .txt   NNGC ML200606 .txt   NNGC ML200608 .txt   NNGC ML200610 .txt   Wii-shared1 ml (/mail.nintendo.co.jp/受信/Revolution/wii-shared1 ML) wii-shared1 ML This folder contains… File Name Extension Description wii-shared1 ML200609 .txt   wii-shared1 ML200610 .txt   wii-shared1 ML200611 .txt   wii-shared1 ML200612 .txt   ゲームリモコン (/mail.nintendo.co.jp/受信/Revolution/ゲームリモコン) ゲームリモコン This folder contains… File Name Extension Description ゲームリモコン200603 .txt   ゲームリモコン200604 .txt   ゲームリモコン200605 .txt   ゲームリモコン200606 .txt   Miw_sup ml (/mail.nintendo.co.jp/受信/Revolution/ゲームリモコン/miw_sup ML) miw_sup ML This folder contains… File Name Extension Description miw_sup ML200511 .txt   miw_sup ML200601 .txt   miw_sup ML200602 .txt   miw_sup ML200604 .txt   Ml-rvlcon (/mail.nintendo.co.jp/受信/Revolution/ゲームリモコン/ml-rvlcon) ml-rvlcon This folder contains… File Name Extension Description ml-rvlcon200604 .txt   ml-rvlcon200605 .txt   ml-rvlcon200606 .txt   ml-rvlcon200607 .txt   ml-rvlcon200608 .txt   ml-rvlcon200609 .txt   Sora_sup (/mail.nintendo.co.jp/受信/Revolution/ソラ/SORA_SUP) SORA_SUP This folder contains… File Name Extension Description SORA_SUP200604 .txt   SORA_SUP200606 .txt   Sky mailing list (/mail.nintendo.co.jp/受信/Revolution/ソラ/ソラ ML) ソラ ML This folder contains… File Name Extension Description ソラ ML200511 .txt   ソラ ML200512 .txt   ソラ ML200601 .txt   ソラ ML200602 .txt   ソラ ML200603 .txt   ソラ ML200604 .txt   ソラ ML200605 .txt   ソラ ML200606 .txt   ソラ ML200607 .txt   ソラ ML200608 .txt   ソラ ML200609 .txt   ソラ ML200610 .txt   ソラ ML200611 .txt   ソラ ML200612 .txt   Virtual Console (/mail.nintendo.co.jp/受信/Revolution/バーチャルコンソール) バーチャルコンソール This folder contains… File Name Extension Description バーチャルコンソール200602 .txt   バーチャルコンソール200603 .txt   バーチャルコンソール200604 .txt   バーチャルコンソール200605 .txt   バーチャルコンソール200606 .txt   バーチャルコンソール200607 .txt   バーチャルコンソール200608 .txt   バーチャルコンソール200609 .txt   バーチャルコンソール200609_01 .txt   バーチャルコンソール200609_02 .txt   バーチャルコンソール200610 .txt   バーチャルコンソール200612 .txt   Intelligent Systems Virtual Console Mailing List (/mail.nintendo.co.jp/受信/Revolution/バーチャルコンソール/IS VirtualConsole ML) バーチャルコンソール/IS VirtualConsole ML This folder contains… File Name Extension Description IS VirtualConsole ML200602 .txt   IS VirtualConsole ML200603 .txt   IS VirtualConsole ML200604 .txt   IS VirtualConsole ML200605 .txt   IS VirtualConsole ML200606 .txt   IS VirtualConsole ML200607 .txt   IS VirtualConsole ML200608 .txt   IS VirtualConsole ML200609 .txt   IS VirtualConsole ML200610 .txt   IS VirtualConsole ML200611 .txt   IS VirtualConsole ML200611_01 .txt   IS VirtualConsole ML200612 .txt   Intelligent Systems Virtual Console Debug Mailing List(/mail.nintendo.co.jp/受信/Revolution/バーチャルコンソール/IS VirtualConsole_Debug ML) バーチャルコンソール/IS VirtualConsole_Debug ML This folder contains… File Name Extension Description IS VirtualConsole_Debug ML200607 .txt   IS VirtualConsole_Debug ML200608 .txt   IS VirtualConsole_Debug ML200609 .txt   IS VirtualConsole_Debug ML200610 .txt   IS VirtualConsole_Debug ML200611 .txt   IS VirtualConsole_Debug ML200612 .txt   Is virtualconsole_debug(noa) ml (/mail.nintendo.co.jp/受信/Revolution/バーチャルコンソール/IS VirtualConsole_Debug(NOA) ML) バーチャルコンソール/IS VirtualConsole_Debug(NOA) ML This folder contains… File Name Extension Description IS VirtualConsole_Debug(NOA) ML200612 .txt   似顔絵 ml (/mail.nintendo.co.jp/受信/Revolution/似顔絵 ML) 似顔絵 ML This folder contains… File Name Extension Description 似顔絵 ML200606 .txt   似顔絵 ML200607 .txt   似顔絵 ML200608 .txt   似顔絵 ML200609 .txt   似顔絵 ML200610 .txt   似顔絵 ML200611 .txt   似顔絵 ML200612 .txt   Spd all (/mail.nintendo.co.jp/受信/SPD ALL) SPD ALL This folder contains… File Name Extension Description SPD ALL200506 .txt   SPD ALL200507 .txt   SPD ALL200508 .txt   SPD ALL200509 .txt   SPD ALL200510 .txt   SPD ALL200511 .txt   SPD ALL200512 .txt   SPD ALL200601 .txt   SPD ALL200602 .txt   SPD ALL200603 .txt   SPD ALL200604 .txt   SPD ALL200605 .txt   SPD ALL200606 .txt   SPD ALL200607 .txt   SPD ALL200608 .txt   SPD ALL200609 .txt   SPD ALL200610 .txt   SPD ALL200611 .txt   SPD ALL200612 .txt   Spd gm (/mail.nintendo.co.jp/受信/SPD GM) SPD GM This folder contains… File Name Extension Description SPD GM200506 .txt   SPD GM200507 .txt   SPD GM200508 .txt   SPD GM200509 .txt   SPD GM200510 .txt   SPD GM200511 .txt   SPD GM200512 .txt   SPD GM200601 .txt   SPD GM200602 .txt   SPD GM200603 .txt   SPD GM200604 .txt   SPD GM200605 .txt   SPD GM200606 .txt   SPD GM200607 .txt   SPD GM200608 .txt   SPD GM200609 .txt   SPD GM200610 .txt   SPD GM200611 .txt   SPD GM200612 .txt   Spd ti (/mail.nintendo.co.jp/受信/SPD TI) SPD TI This folder contains… File Name Extension Description SPD TI200506 .txt   SPD TI200507 .txt   SPD TI200508 .txt   SPD TI200509 .txt   SPD TI200510 .txt   SPD TI200511 .txt   SPD TI200512 .txt   SPD TI200601 .txt   SPD TI200602 .txt   SPD TI200603 .txt   SPD TI200604 .txt   SPD TI200605 .txt   SPD TI200606 .txt   SPD TI200607 .txt   SPD TI200608 .txt   SPD TI200609 .txt   SPD TI200610 .txt   SPD TI200611 .txt   SPD TI200612 .txt   Wi-fiガイドライン ml (/mail.nintendo.co.jp/受信/Wi-Fiガイドライン ML) Wi-Fiガイドライン ML This folder contains… File Name Extension Description Wi-Fiガイドライン ML200602 .txt   Wi-Fiガイドライン ML200603 .txt   Wi-Fiガイドライン ML200604 .txt   Wi-Fiガイドライン ML200605 .txt   Wi-Fiガイドライン ML200606 .txt   Wi-Fiガイドライン ML200607 .txt   Wi-Fiガイドライン ML200608 .txt   Wi-Fiガイドライン ML200609 .txt   Wi-Fiガイドライン ML200610 .txt   Wi-Fiガイドライン ML200611 .txt   Wi-Fiガイドライン ML200612 .txt   Dea-5p-sup ml (/mail.nintendo.co.jp/受信/dea-5p-sup ML) /dea-5p-sup ML This folder contains… File Name Extension Description dea-5p-sup ML200511 .txt   dea-5p-sup ML200607 .txt   dea-5p-sup ML200608 .txt   dea-5p-sup ML200612 .txt   Dea-sup (/mail.nintendo.co.jp/受信/dea-sup) dea-sup This folder contains… File Name Extension Description dea-sup200505 .txt   dea-sup200506 .txt   アカウント関連 (/mail.nintendo.co.jp/受信/アカウント関連) アカウント関連 This folder contains… File Name Extension Description アカウント関連200607 .txt   アカウント関連200611 .txt   アカウント関連200612 .txt   サーバ管理 (/mail.nintendo.co.jp/受信/サーバ管理) サーバ管理 This folder contains… File Name Extension Description サーバ管理200506 .txt   サーバ管理200507 .txt   サーバ管理200508 .txt   サーバ管理200509 .txt   サーバ管理200510 .txt   サーバ管理200512 .txt   サーバ管理200602 .txt   サーバ管理200603 .txt   サーバ管理200604 .txt   サーバ管理200605 .txt   サーバ管理200606 .txt   サーバ管理200607 .txt   サーバ管理200608 .txt   サーバ管理200609 .txt   ポケモン (/mail.nintendo.co.jp/受信/ポケモン) ポケモン This folder contains… File Name Extension Description ポケモン200603 .txt   ポケモン200604 .txt   ポケモン200605 .txt   ポケモン200606 .txt   ポケモン200607 .txt   ポケモン200608 .txt   ポケモン200609 .txt   ポケモン200610 .txt   ポケモン200611 .txt   ポケモン200612 .txt   ゲームフリーク (/mail.nintendo.co.jp/受信/ポケモン/ゲームフリーク) ゲームフリーク This folder contains… File Name Extension Description ゲームフリーク200512 .txt   ゲームフリーク200601 .txt   ゲームフリーク200602 .txt   ゲームフリーク200603 .txt   ゲームフリーク200604 .txt   ゲームフリーク200605 .txt   ゲームフリーク200606 .txt   ゲームフリーク200607 .txt   ゲームフリーク200608 .txt   ゲームフリーク200609 .txt   ゲームフリーク200611 .txt   ゲームフリーク200612 .txt   三津原さん (/mail.nintendo.co.jp/受信/ポケモン/三津原さん) 三津原さん This folder contains… File Name Extension Description 三津原さん200601 .txt   三津原さん200602 .txt   三津原さん200603 .txt   人事関連 (/mail.nintendo.co.jp/受信/人事関連) 人事関連 This folder contains… File Name Extension Description 人事関連200506 .txt   人事関連200603 .txt   人事関連200604 .txt   人事関連200606 .txt   人事関連200608 .txt   人事関連200612 .txt   キャリアシート (/mail.nintendo.co.jp/受信/人事関連/キャリアシート) キャリアシート This folder contains… File Name Extension Description キャリアシート200612 .txt   中途採用 (/mail.nintendo.co.jp/受信/人事関連/中途採用) 中途採用 This folder contains… File Name Extension Description 中途採用200602 .txt   中途採用200604 .txt   中途採用200606 .txt   採用試験 (/mail.nintendo.co.jp/受信/人事関連/採用試験) 採用試験 This folder contains… File Name Extension Description 採用試験200605 .txt   採用試験200606 .txt   新人研修 (/mail.nintendo.co.jp/受信/人事関連/新人研修) 新人研修 This folder contains… File Name Extension Description 新人研修200602 .txt   新人研修200603 .txt   新人研修200604 .txt   新人研修200605 .txt   新人研修200606 .txt   新人研修 ml (/mail.nintendo.co.jp/受信/人事関連/新人研修 ML) 新人研修 ML This folder contains… File Name Extension Description 新人研修 ML200605 .txt   新人研修 ML200606 .txt   新卒面接 (/mail.nintendo.co.jp/受信/人事関連/新卒面接) 新卒面接 This folder contains… File Name Extension Description 新卒面接200602 .txt   新卒面接200603 .txt   新卒面接200604 .txt   新卒面接200605 .txt   新卒面接200606 .txt   新卒面接200608 .txt   申請・承認関連 (/mail.nintendo.co.jp/受信/人事関連/申請・承認関連) 申請・承認関連 This folder contains… File Name Extension Description 申請・承認関連200611 .txt   申請・承認関連200612 .txt   評価 (/mail.nintendo.co.jp/受信/人事関連/評価) 人事関連/評価 This folder contains… File Name Extension Description 評価200603 .txt   評価200604 .txt   評価200606 .txt   評価200609 .txt   評価200610 .txt   評価200611 .txt   Meeting schedule (/mail.nintendo.co.jp/受信/会議のスケジュール) 会議のスケジュール This folder contains… File Name Extension Description 会議のsukejyu-ru200608 .txt   会議のsukejyu-ru200609 .txt   会議のsukejyu-ru200610 .txt   会議のsukejyu-ru200611 .txt   会議のsukejyu-ru200612 .txt   Internal technical support (/mail.nintendo.co.jp/受信/部内技術サポート) 部内技術サポート This folder contains… File Name Extension Description 部内技術サポート200505 .txt   部内技術サポート200506 .txt   部内技術サポート200507 .txt   部内技術サポート200508 .txt   部内技術サポート200509 .txt   部内技術サポート200510 .txt   部内技術サポート200511 .txt   部内技術サポート200512 .txt   部内技術サポート200601 .txt   部内技術サポート200602 .txt   部内技術サポート200603 .txt   部内技術サポート200604 .txt   部内技術サポート200605 .txt   部内技術サポート200606 .txt   部内技術サポート200607 .txt   部内技術サポート200608 .txt   部内技術サポート200609 .txt   部内技術サポート200610 .txt   部内技術サポート200611 .txt   部内技術サポート200612 .txt   HTML Inbox (/mail.nintendo.co.jp/受信HTML) 受信HTML This folder contains… The earliest email is from May 19th 2005 and the last is from 21st December 2006. Email that are just notices of a sent file or a boring trivial message are not in the table below as there is so many non-interesting emails it would be a waste of space documenting them. Many of them are daily translation files from each of the languages translators (german, italian, french, spanish) so it gets very repetitive. File Name Extension Description 050519_01 Just talk about sending a report   050523_00 Notice of Upload of Pokemon Emerald ROM for EURO translation (debug-2005-05-23-A-EURO.exe)   050524_06 Mario Club bug log?   050527_00     050530_00     050530_01     050530_03     050530_04     050530_05     050530_06     050530_07     050530_08     050531_00 Talk about changes in French and italian locale (using a period after EXP)   050531_06 email address of Game Freak employees   050601_00     050601_01     050601_02     050601_03     050601_04     050601_05     050601_06     050601_07     050601_08     050601_09     050601_10     050602_00     050602_01     050602_02     050602_03     050602_04     050602_05     050602_06     050602_07     050602_08     050606_00     050606_01     050606_02     050606_03     050606_04     050606_05     050606_07     050606_08     050606_09     050606_10     050606_11     050606_12     050606_16     050606_17     050606_18     050606_19     050607_00     050607_01     050607_02     050607_03     050607_04     050607_05     050607_06     050607_07     050608_00     050608_01     050608_02     050608_03     050608_04     050608_05     050608_07     050608_08     050609_00     050609_01     050609_02     050609_03     050609_04     050609_05     050609_06     050610_00     050610_01     050610_02     050610_03     050610_04     050610_05     050610_06     050610_07     050613_00     050613_01     050613_02     050613_03     050613_04     050613_06     050613_07     050613_08     050614_00     050614_01     050614_02     050614_03     050614_04     050614_05     050615_00     050615_01     050615_02     050615_03     050615_04     050615_05     050615_06     050615_07     050616_00     050616_01     050616_02     050616_03     050616_04     050616_05     050620_00     050620_01     050620_02     050620_03     050620_04     050620_06     050620_07     050620_08     050620_09     050620_10     050620_11     050620_14     050621_00     050621_01     050621_02     050621_03     050621_04     050621_05     050621_07     050621_08     050622_00     050622_01     050622_02     050622_03     050622_04     050622_05     050623_00     050623_01     050623_02     050623_03     050623_04     050623_05     050623_07     050623_08     050623_09     050624_00     050624_01     050624_02     050624_03     050624_04     050624_05     050627_00     050627_01     050627_02     050627_03     050627_04     050627_05     050627_06     050627_08     050628_00     050628_01     050628_02     050628_03     050628_05     050629_00     050629_01     050629_02     050629_03     050630_01     050630_02     050630_03     050630_04     050630_05     050701_01     050701_02     050701_03     050704_00     050704_01     050705_00     050705_01     050706_00     050706_01     050706_02     050707_01     050707_03     050707_04     050708_00     050708_01     050711_00     050711_02     050711_03     050712_00     050712_01     050713_00     050713_02     050713_03     050714_00     050714_02     050715_00     050715_01     050719_04     050720_00     050720_01     050721_00     050722_00     050722_01     050804_00     060105_00     060106_00     060110_01     060123_01     060126_00     060201_02     060228_00     060519_00     060601_00     060606_00     060706_01     060706_02     060706_03     060706_04     060707_00     060707_01     060707_02     060707_03     060711_00     060711_01     060719_00     060720_00     060802_00     060901_00     060925_00     060929_00     061002_00     061002_01     061002_02     061006_00     061006_01     061010_00     061016_01     061016_02     061016_03     061016_04     061023_00     061025_00     061027_00     061031_00     061128_00     061129_00     061129_01     061130_00     061204_00     061206_00     061206_01     061208_00     061211_00     061220_00     061221_00     Received Log (/mail.nintendo.co.jp/受信ログ) 受信ログ This folder contains… File Name Extension Description 受信ログ200610_22 .txt   受信ログ200610_23 .txt   受信ログ200610_24 .txt   受信ログ200610_25 .txt   受信ログ200610_26 .txt   受信ログ200610_27 .txt   受信ログ200610_28 .txt   受信ログ200610_29 .txt   受信ログ200610_30 .txt   受信ログ200610_31 .txt   受信ログ200610_32 .txt   受信ログ200610_33 .txt   受信ログ200610_34 .txt   受信ログ200610_35 .txt   受信ログ200610_36 .txt   受信ログ200610_37 .txt   受信ログ200611 .txt   受信ログ200611_01 .txt   受信ログ200611_02 .txt   受信ログ200611_03 .txt   受信ログ200611_04 .txt   受信ログ200611_05 .txt   受信ログ200611_06 .txt   受信ログ200611_07 .txt   受信ログ200611_08 .txt   受信ログ200611_09 .txt   受信ログ200611_10 .txt   受信ログ200611_11 .txt   受信ログ200611_12 .txt   受信ログ200611_13 .txt   受信ログ200611_14 .txt   受信ログ200611_15 .txt   受信ログ200611_16 .txt   受信ログ200611_17 .txt   受信ログ200611_18 .txt   受信ログ200611_19 .txt   受信ログ200611_20 .txt   受信ログ200611_21 .txt   受信ログ200611_22 .txt   受信ログ200611_23 .txt   受信ログ200611_24 .txt   受信ログ200611_25 .txt   受信ログ200611_26 .txt   受信ログ200611_27 .txt   受信ログ200611_28 .txt   受信ログ200611_29 .txt   受信ログ200611_30 .txt   受信ログ200611_31 .txt   受信ログ200611_32 .txt   受信ログ200611_33 .txt   受信ログ200611_34 .txt   受信ログ200612 .txt   受信ログ200612_01 .txt   受信ログ200612_02 .txt   受信ログ200612_03 .txt   受信ログ200612_04 .txt   受信ログ200612_05 .txt   受信ログ200612_06 .txt   受信ログ200612_07 .txt   受信ログ200612_08 .txt   受信ログ200612_09 .txt   受信ログ200612_10 .txt   受信ログ200612_11 .txt   受信ログ200612_12 .txt   受信ログ200612_13 .txt   受信ログ200612_14 .txt   受信ログ200612_15 .txt   受信ログ200612_16 .txt   受信ログ200612_17 .txt   受信ログ200612_18 .txt   受信ログ200612_19 .txt   受信ログ200612_20 .txt   受信ログ200612_21 .txt   受信ログ200612_22 .txt   受信ログ200612_23 .txt   Received Attachments (/mail.nintendo.co.jp/受信添付) 受信添付 This folder contains… File Name Extension Description Re_ ハンタ－ズ Wifi状況の件.eml     Re_ ハンタ－ズ Wifi状況の件(2).eml     _Block.pdf     _DPD Specj.jpg     _NNGC全体日程表.xls     !福栄食堂アンケート0508.xls     (NOEUpdated)Work_Flow061016.xls     (改定提案)安全設計関連標準.pdf     (田原)20050929NintendoWiFiConnectin機能説明資料.zip     [External-hokkaido] Build 1038-40.eml     [External-hokkaido] build-1038-30.eml.eml     [External-hokkaido] build-1038-51.eml     [External-hokkaido] build-1038-53.eml     [External-hokkaido] build-1038-71.eml     [External-hokkaido] Component 2 Build 1038-74.eml     [External-hokkaido] Opera Component 2 - Build 1038-29.eml.eml     [External-hokkaido] Release Build Opera Component 2.eml     [External-hokkaido] Release Note - Build 114.eml     [External-hokkaido] Release Note Build 1007.eml.eml     [External-hokkaido] Release Note Build 116.eml     [External-hokkaido] Release Note Build 121.eml     [External-hokkaido] Release Note Opera Component 2 - Build 1038-23.eml.eml.eml     [External-hokkaido] Release Note Opera Component 2 Build 1038-2.eml.eml     [External-hokkaido] Release Notes Build 1035.eml     [External-hokkaido] Release Notes Build 117.eml     [External-hokkaido] Release Notes Build 119.eml.eml     [External-hokkaido] Release Notes Opera Component 2 - Build 1038-2.eml     [External-hokkaido] Release Notes Opera Component 2 Build 1038-27.eml.eml     JavaScript and JSPlugin error.eml     [ml-wii-shared1_1] ML Open.eml     [ml-wii-shared110] Re HomeButtonMenu のリソースについて.eml     [ml-wii-shared111] Re Shared1関連の検証にて気が付いた点について.eml     [ml-wii-shared112] Re Shared1関連の検証にて気が付いた点について.eml     [ml-wii-shared113] Re Shared1関連の検証にて気が付いた点について.eml     [ml-wii-shared114] Re Shared1関連の検証にて気が付いた点について.eml     [ml-wii-shared115] Re HomeButtonMenu のリソースについて.eml     [ml-wii-shared1_16] System NAND application 開発者向けドキュメント(さらに添付ファイルを含むらしい).eml     [ml-wii-shared117] Re System NAND application 開発者向けドキュメント.eml     [ml-wii-shared118] Re System NAND application 開発者向けドキュメント.eml     [ml-wii-shared119] Re System NAND application 開発者向けドキュメント.eml     [ml-wii-shared1_2] Shared1コンテンツの確認方法について.eml     [ml-wii-shared120] Re System NAND application 開発者向けドキュメント.eml     [ml-wii-shared121] Re System NAND application 開発者向けドキュメント.eml     [ml-wii-shared122] Re System NAND application 開発者向けドキュメント.eml     [ml-wii-shared123] Re System NAND application 開発者向けドキュメント.eml     [ml-wii-shared124] Re System NAND application 開発者向けドキュメント(さらに添付ファイルを含むらしい).eml     [ml-wii-shared1_25] 共有リソースの同一性のチェック.eml     [ml-wii-shared1_26] CNTSeek関数のoffset引数について.eml     [ml-wii-shared127] Re CNTSeek関数のoffset引数について.eml     [ml-wii-shared1_28] MLメンバー追加.eml     [ml-wii-shared129] Re System NAND application 開発者向けドキュメント(さらに添付ファイルを含むらしい).eml     [ml-wii-shared13] Re Shared1コンテンツの確認方法について.eml     [ml-wii-shared14] Re Shared1コンテンツの確認方法について.eml     [ml-wii-shared1_5] Nメニューからwadファイルをインポートする際のエラーについて.eml     [ml-wii-shared1_6] Shared1関連の検証にて気が付いた点について.eml     [ml-wii-shared17] Re Shared1関連の検証にて気が付いた点について.eml     [ml-wii-shared18] Re Shared1関連の検証にて気が付いた点について.eml     [ml-wii-shared1_9] HomeButtonMenu のリソースについて.eml     [REVO_VirtualConsole_ 01283] 【至急】NESタイトルのRVL_SDK2.3化.eml     [RVL-sup_00082] Revolution多国語対応について(さらに添付ファイルを含むらしい).eml     『キャリアシート　上司用』説明資料.pdf | 【E32006研修】総括レポート(雛形).doc | 【E32006研修】総括レポー木梨.doc | 【ＶＣソフトチェック】20061209.xls | 【まとめ】ＮＣＬ社員用連絡室（Ｒ５１０）0426ver.xls | 【緊急】ホームボタンメニュー周りの不具合について.eml | ＜中村秀和＞2006.doc | 01.ポートメッセ-10.27.pdf | 04_小澤_FTPアクセス許可設定依頼書_社内.doc | 051205 ネットワーク接続実験のレポート.txt | 051227-USG１・２カートリッジロットチェック結果NTRdata20051115USG1207.xls | 05年後半イベント全体日程.xls | 060221.exe | 060614_VCバナー相談.txt | 060912.jpg | 0620-2006 VC Licensee Re-Vamp.xls | 0718：ローカライズ計画案.xls | 1-12.26.01.apc | 1-12.28.29.apc | 1-20.18.29.apc | 1-20.19.00.apc | 1-20.31.40.apc | 1-20.34.20.apc | 1-20.35.19.apc | 1-20.53.33.apc | 1-21.06.49.apc | 1.bmp | １プロ.txt | 2.bmp | 2005.6流通説明会.xls | 2005.zip | 20051019_NITRO1.2SP2_CompilerLinker_Patch.jp.txt | 20051024_eval_30ThreadAutoDetect.zip | 20051025_eval_NITRO_Linker_v2.0_b77.zip | 20051121商標セミナー参加者リスト.xls | 20051130商標セミナー参加者リスト.xls | 20051213_cw_ds_1.2_sp3_debuggerPatch.jp.txt | 2005年10月度議事次第.txt | 2005年11月度議事次第.txt | 2005年12月度議事次第.txt | 2005年7月度GM会議議事次第.txt | 2005年7月度GM会議議事次第(最終).txt | 2005年8月度議事次第.txt | 2005年9月度議事次第.txt | 2006_02_16_本体フレンドリスト.ppt | 2006_0222_kuroda_01.mb | 2006_0615_kuroda_mayaPlugin縺ョ蝣エ蜷・lzh | 2006-11-15-Virtual Console - EU.xls | 2006-11-15-Virtual Console(HBM) - EU.xls | 2006-11-16-Virtual Console_JP_NESP_SNESP.xls | 2006-11-21-Virtual Console - EU .xls | 2006-11-22-VirtualConsole-EUTest-NES-SNES.xls | 2006-11-28-Virtual Console - EU.xls | 2006-11-29-Virtual Console-EU-NCL.xls | 2006-12-01-Virtual Console - EU.xls | 2006-12-13-Virtual Console - EU.xls | 2006-12-19-Virtual Console - EU_JP.xls | 2006-12-19-Virtual-Console-NCL.xls | 20060125_RVL打合せ_01.txt | 20060315_RVL打合せ(第1部)_01.txt | 20060315_RVL打合せ(第1部)_02.txt | 20060328_cw_ds_2.0_F-38F-39_sample.zip | 20060522_cw_ds_1.2_sp4_Linker_Patch.jp.txt | 20060602_cw_ds_2.0_Buildtools_Patch.jp.txt | 20060616_cw_ds_2.0_Buildtools_Patch2.jp.txt | 20060616_cw_ds_2.0_Compiler_Patch.jp.txt | 20060705_cw_ds_2.0_Buildtools_Patch3.jp.txt | 20060811_cw_ds_2.0_Buildtools_Patch4.jp.txt | 20060829_cw_ds_2.0_sp1_Buildtools_Patch.jp.txt | 20061122_cw_ds_2.0_sp1_Buildtools_Patch2.jp.txt | 20061206_RFL_Library_Guidelines.doc | 20061207_RFL_Library_Guidelines_EAD.doc | 20061211_RFL_Library_Guidelines_EAD.doc | 20061221_RFL_Overview_EAD.doc | 2006入社試験問題情報系Ａ_0322.doc | 2006入社試験問題情報系B_0322.doc | 2006入社試験問題情報系C.doc | 2006入社試験問題情報系C（解答付）.doc | 2006年10月度議事次第.txt | 2006年11月度議事次第.txt | 2006年12月度議事次第.txt | 2006年3月度議事次第.txt | 2006年4月度議事次第.txt | 2006年5月度議事次第.txt | 2006年6月度議事次第.txt | 2006年7月度議事次第.txt | 2006年8月度議事次第.txt | 2006年9月度議事次第.txt | 2006年新入社員技術研修参加者一覧.xls | 2006技術系新入社員研修スケジュール（確定）.xls | 2006新入社員開発メールアドレス.xls | 2006新卒採用ミーティング（理工）.doc | 200万人の漢検_5W_061120.pdf | 21968-YoshisIslandDS-FR_1.doc | 22275 - Super Castlevania IV - FR.doc | 22291 - R-Type 3 The Third Lightning - FR.pdf | 253881Eigo-kr_061013.doc | 253881Eigo-kr_061013.pdf | 254156指示原稿.pdf | ２プロ.txt | 300-M00027-00 ポケモン青の救助隊データ消えの件.doc | 300-M00028-00 対処記録案.doc | 3Dmaxプラグインβ版コメントYsk0627.pdf | 3dsmax_ifl_sample2.zip | 3D研修課題.doc | ３プロ.txt | ３月２９日定性情報まとめ.doc | 4F配線ルート.pdf | ４プロ.txt | 56S0497（WS380）.pdf | 56S0497（構成）.pdf | 56S0660（FX3450構成）.pdf | 56S0660（NVS285構成）.pdf | 56S0660（WS390）.pdf | ５ＰＧ住所録.xls | ５プロ.txt | 9.15-1.xls | ABC.pdf | AboutVoiceChat_en_060807.zip | AboutVoiceChat_jp.zip | AboutVoiceChat_田原修生.zip | AboutWXC.pdf | ActimagineLogo.zip | ADPCM2PCM.txt | after.txt | AGBSpecSheet-NOE.doc | AGBソフト一覧.xls | Animal Crossing_Language issues.zip | apiman-101-110.diff | AP接続エラー確認資料(仮).xls | AP設置箇所.gif | arctools.zip | ARM9-TS-C.lcf.template | ARM9-TS.lcf.template | ARMLinker.dll.b-3670.20060501.190135A.dump | Assistance to Ubisoft.txt | Audio Problems.eml | AWKEE1_Log.cap | ax.zip | ax2.zip | axsimple.cpp | AXライブラリ質問.txt | ayame-kagemai.zip | BackToolForNDEV.zip | BackToolForNDEV104.zip | BackToolForRVTR.zip | BAKR_liptouching_061024.xls | Banner_english.xls | Banner_virtual.32.bns | Banner16color_KO_A.bmp | battlefieldLearnig.txt | before.txt | bench.zip | BMS Business Server Upload Reports(EU12052006).pdf | BMS Business Server Upload Reports(EU12062006).pdf | BMS Business Server Upload Reports(EU12082006).pdf | BMS Business Server Upload Reports(EU12112006).pdf | BMS Business Server Upload Reports(EU12132006).pdf | BMS Business Server Upload Reports(EU12152006).pdf | BMS Business Server Upload Reports(EU12192006).pdf | BMS Business Server Upload Reports(EU12202006).pdf | BMS Business Server Upload Reports(US12052006).pdf | BMS Business Server Upload Reports(US12112006).pdf | BMS Business Server Upload Reports(US12132006).pdf | BMS Business Server Upload Reports(US12142006).pdf | BMS Business Server Upload Reports(US12152006).pdf | BMS Business Server Upload Reports(US12192006).pdf | BMS商用サーバーアップロード連絡書(JP20061207).pdf | BMS商用サーバーアップロード連絡書(JP20061213).pdf | BMS商用サーバーアップロード連絡書(JP20061215).pdf | BMS商用サーバーアップロード連絡書(JP20061219).pdf | BOMBERMAN93(US).bmp | BOMBERMAN94(JP).bmp | BONKS.bmp | Brain Ageからの脳トレ韓国版における仕様変更点.xls | BrainAge_kr_061020_ed.pdf | BrainAge_kr_061020_ed.rtf | BrainTrain_NormalText_shuusei061116.xls | BrainTrain_Text_1020.zip | BTに関わるゲームリモコンの仕様.pdf | BTに関わるゲームリモコンの仕様.txt | BTに関わるゲームリモコンの仕様.vin | BTに関わるゲームリモコンの仕様20060318.txt | BT問答集.xls | bug_fp_sz20060301.lzh | buglog_EME_NOE.xls | build-1017におけるフォントの直接参照について.txt | Bunpou_tag_English.xls | bytecopy_core.s | bytecopy.c | bytecopy.h | cap.zip | car_sample.zip | CEDEC2006レポートPS3ネットワーク.ppt | CERO倫理規程060223.pdf | changedesign_2.zip | changedesign.zip | channel_1030.vsd | ChannelIcon.zip | Check_menu_sample.zip | Classic Controller revised NC 1.pdf | Classic Controller revised NCL | Classic Controller revised NCL.pdf | Classic Controller revised NCL.vsd | Classic Controller revised v200 | Classic Controller revised v2002.vsd | Classic Controller v2002.vsd | cloud.zip | clrbars7.BMP | color.jpg | ColorBar.elf | ColorBarPAL.elf | Comments on Filtering Software(NOA&Outside Council)doc.doc | cont_number_re_0920.sit | cont_number_re_PDF_0920.zip | cont_number_re.pdf | cont_number_re.sit | cont_ope_0817.jpg | cont_ope_0817.jpg | Content_Licensing_Ser_jp.txt | Content_Licensing_Ser.pdf | Controller Messages_061027.xls | Controller Messages_061101.xls | Controller Messages_061102NOE.xls | Controller Messages_061103_NOE.xls | Controller Messages_NOE_061025.xls | Controller Messages_NOE_061025(2).xls | Controller Messages.xls | Controller Messages1017.xls | Controller Messages1018.xls | Controller Messages1019_NOE.xls | Controller Messages1023_NOE.xls | Controller Messages1023a_NOE.xls | Controller Messages1025_NOE.xls | controller_e3_2006_ver2.zip | controller_e3_2006.zip | controller_illust_0905.zip | controller_illust.zip | controller.c | CrashReport.lzh | cw_check[dev1203]_060302.lzh | CW_DS2.0_F39_SPEC_v2.txt | CW_DS2.0_F39_SPEC.txt | cw2_0fc_switch1_20060315.lzh | CW3Report2.jpg | D-abcd.pdf | DEA-SUP修正点0519.xls | Debug_controllerscan.xls | debug_document.zip | debuginfo.JPG | DebugQuickSave_Ver100_評価版_061129.doc | DebugQuickSave_Ver100_評価版_061130.doc | demand_for_NigaoeLibraly.xls | DesignStatement_Wi-FiConnection_060705_B.doc | DesignStatement_Wi-FiConnection_060705_C.doc | DesignStatement_Wi-FiConnection_060921_A.doc | DesignStatement_Wi-FiConnection_A_051110.doc | DesignStatement_Wi-FiConnection_A_051212.lzh | DesignStatement_Wi-FiConnection_A_20050123AsobiTaizenOnline_1.doc | DesignStatement_Wi-FiConnection_B_051110.doc | DesignStatement_Wi-FiConnection_C_051110.doc | DesignStatement_Wi-FiConnection_D_051110.doc | Diamond_ALL_jp.xls | Diamond.xls | Diamond.zip | diff.txt | document-20060321.zip | DownloadProgrammingManual.zip | dp_font_word060531.zip | dp_font060615.zip | DP_fusigi_operation060131.xls | DP_fusigi_overview060131.doc | DP_Ranger_Manaphy.xls | DP_schedule.xls | DP_submission.zip | DP_WorldTradeImage051220.doc | DPfont060112.zip | DS Lite意見.xls | DS-Master_Docs_WiFi_Pack_20051109_J.zip | DS-Master_Docs_WiFi_Pack_20060630_J.zip | DS2.0pragma.jp.xls | ＤＳカンファレンス春出席申込.xls | DSすれ違い通信中継所プログラム運営050913.ppt | DS献立全集_1W_061210.pdf | DS電子認証メンバー.xls | DS電子認証概要説明資料(企開).doc | dummy.lzh | dump.LZH | Dvd_Guide.jp.pdf | dwc3.log | E3 2006 業務出張者一覧（部署名）.xls | E3 2006 研修出張者一覧（企画開発部）.xls | E3 2006 研修出張者一覧（企画開発部）324.xls | E3 2006 研修出張者一覧（企画開発部）a.xls | E3 2006 研修出張者一覧（企画開発部）訂.xls | E3 2006 研修出張者一覧（企画開発部）訂a.xls | E3 2006 研修出張者一覧（部署名）.xls | E3 2006出張 業務派遣申請書（氏名）.doc | E3 2006出張 研修派遣本人希望申込・上司推薦書（木梨玲）.doc | E3 2006出張 研修派遣本人希望申込・上司推薦書（氏名）.doc | E3 EVENT - IS.xls | E3 EVENT.xls | E3_2006_kanri_5PG.xls | E3_2006_kanri.xls | E3_VC_MENU_N64.jpg | E3_VC_MENU_N64(2).jpg | E3_VC_MENU_NES.jpg | E3_VC_MENU_NES(2).jpg | E3_VC_MENU_SNES.jpg | E3_VC_MENU_SNES(2).jpg | E3_VC_OPERATION_N64.jpg | E3_VC_OPERATION_N64(2).jpg | E3_VC_OPERATION_NES.jpg | E3_VC_OPERATION_NES(2).jpg | E3_VC_OPERATION_SNES.jpg | E3_VC_OPERATION_SNES(2).jpg | E3(06)TitleList_SPD_060303.xls | E32006【E3研修】ＭＢ現地速報レポート（雛形）.doc | E3ショーバージョンガイドライン_02.txt | E3ショーバージョンガイドライン_03.txt | E3ショーバージョンガイドライン_04.txt | E3ショーバージョンガイドライン_05.txt | E3ショーバージョンガイドライン_060322.txt | E3ショーバージョンガイドライン(任天堂タイトル向け)_060413.doc | E3ショーバージョンガイドライン(任天堂タイトル向け)_060417.doc | E3ショーバージョンガイドライン(任天堂タイトル向け)_DS_060418.doc | E3ショーバージョンガイドライン(任天堂タイトル向け)_RVL_060501.doc | E3デバグ060410.txt | E３映像作成環境比較2005_11_08ver.xls | E3用仕様書.doc | E3用仕様書060412.doc | E3用補足資料060412.doc | E3用解説.txt | Ｅ３研修出張報告.doc | Ｅ３研修出張報告概要.doc | E3確認リスト.xls | EADFont_UserName.zip | ecco_title.bmp | EchoCancel_flow.ppt | EchoCancel.doc | eeprom_scripts.zip | effectInterfaceDocs.zip | EffectMaker実装希望優先順位.txt | Effect会議議事録2006-01-17.txt | eigoKO_buglist_113021.zip | eigoKO_buglist_120123.zip | eigoKO_buglist_120420.zip | eigoKO_buglist_120609.zip | eigoKO_buglist_120619.zip | eigoKO_buglist_120717.zip | eigoKO_buglist_120819.zip | ELE-C | ELE-P | ELF_Format.pdf | EMAIL_BUG_REPORT_FORM.TXT | EME_EUR_010605.xls | EME_EUR_020605.xls | EME_EUR_030605.xls | EME_EUR_060605.xls | EME_EUR_070605.xls | EME_EUR_080605.xls | EME_EUR_090605.xls | EME_EUR_100605.xls | EME_EUR_130605.xls | EME_EUR_140605.xls | EME_EUR_150605.xls | EME_EUR_160605.xls | EME_EUR_170605.xls | EME_EUR_200505.xls | EME_EUR_200605.xls | EME_EUR_210605.xls | EME_EUR_220605.xls | EME_EUR_230505.xls | EME_EUR_230605.xls | EME_EUR_240505.xls | EME_EUR_250505.xls | EME_EUR_260505.xls | EME_EUR_300505.xls | EME_EUR_310505.xls | EME_EUR.xls | EME_Trainers.xls | en_US_docs.zip | ensata_1_4b.zip | ensata_1_4c.zip | enumsalwaysint.png | err.txt | error_check.xls | error_message.txt | errorlog.txt | Errors_Solutions1102_1_revised_Robert_B.xls | esapi.doc | ESP_RevTrainers_revised_0608.xls | ESP_RevTrainers.xls | ESRB Pertinent Content Chart in Japanese Revised.doc | ESRB Pertinent Content Chart New.doc | EugeneMail.txt | Euro_specialcharacter_21Jun04_JP.xls | FACT_Wii Channel Menu_VER1和訳.doc | FAKJ_01.zip | FAMCOMMARIO.zip | firefox認証局登録.JPG | FixedIssuesList - DS 1.2 SP3 Debugger Patch 20051213.txt | FixedIssuesList - DS 1.2 SP3.txt | FixedIssuesList - DS 1.2 SP4.txt | FixedIssuesList - DS 2.0 SP1.txt | Flow Chart JP 2006-01-29.zip | flow_diskupdate_sys1.pdf | font_DP_GF060710.xls | font_DP.xls | font_system.bmp | font_test.lzh | font.doc | for_Wii_manu_pic_PSD.zip | frbcopy.cpp | frienddata_log.txt | FSL_ARM_specific bindings.txt | Fwd NSTからのWi-Fiに関するミーティング依頼.eml | GAME STATION 24 x 36 (1) (1)1.pdf | GamersSummit2005_リリース情報.xls | Gamespy支払条件.xls | ganbare goemon(SHVC).1.sav | ganbare goemon(SHVC).2.sav | GC_511H2_1800_A.xml | GFCVS.pdf | Global Community Pet Game GoPets! - Shell bought_1.pdf | GMマネージメント研修キックオフ.pdf | GMマネージメント研修期別参加者一覧.pdf | ＧＭ研修アンケート.doc | GM研修シート(1).xls | GoPets.zip | gpu_test.zip | Guidelin+ErrorList.zip | gunstar_title.bmp | HBMを中心とした状態遷移図.doc | HBMを中心とした状態遷移図060908_2.doc | HBMを中心とした状態遷移図060908.doc | HBMを中心とした状態遷移図060911.doc | Helakles3.sram | hero.r3es.txt | Hollywood修正履歴.xls | homebutton_20060902.txt | HomeButtonMenu_Reference.zip | HomeButtonMenu_Specification.pdf | homeButtonSample.zip | HOMEボタンメニューの種類.zip | How to make a disc needed to im | How to make a disc needed to import a wad file.txt | HowtoUseMemory.txt | html.arc | HTTP_ERROR.xls | HttpTest.zip | HVC_SHVC_ボタン割り当て.ppt | IBM Optical Mouse Patents-JP.pdf | Icon-HomeButtonMenu_is_not_available_060901.zip | IE証明書登録.JPG | ImageMetrics_Japanese.mov | init.c | InstalledVersionCheck.xls | InstancePool.h | INTSYS_CRASHREP_ISND.zip | INTSYS_CRASHREP_ISND012.zip | IS-NITRO開発ツール評価.xls | JAAJ_dbg_061017.ddf | Japanese Introduction v1.7.ppt | JFiler.zip | Jp_NOA Lot Check Precheck Issues.doc | kage.pdf | KAGECHR.BIN | KAGEPRG.BIN | kankyo.xls | Karaktris_1_1_0.zip | kemuri.zip | kensyu_kadai.txt | keybind_MD_0817.jpg | keybind_MD_0817.jpg | kikakukaihatsu.xls | kirbydance_error.zip | klistdp060410.zip | KOR_eigo_schedule3.pdf | KOR_eigo_schedule5.pdf | KOR_mario_schedule3.pdf | KOR_mario_schedule5.pdf | KOR_nou_schedule3.pdf | KOR_nou_schedule5.pdf | Korean_localize_schedule.xls | Korean_sample.txt | KPAD_051011.lzh | KPAD_051014.lzh | KPAD_051020.lzh | KPADSample_051025.lzh | KPADSample_051027.lzh | KPADSample_051028.lzh | KRC運用・管理について11.6ver.pdf | ＫＲＣ運用・管理について12.1ver..xls | Launch_Title.xls | Launch_Title060816.xls | Launch_Title060818.xls | Launch_Title060822.xls | Launch_Title060912.xls | Launch_Title060914.xls | Launch_Title060923.xls | Launch_Title060928NOE_edit_Oct11.xls | Launch_Title061002.xls | Launch_Title061006_smc.xls | Launch_Title061007 English.xls | Launch_Title061007.xls | Launch_Title061011.xls | Launch_Title061021.xls | Launch_Title061023a.xls | layout_0527_NOE.zip | layout_NOE_0531.zip | layout_NOE_0601.zip | layout.xls | LED-makiwari.xls | LED-tennnis.xls | left.zip | libagbbackup.zip | libbackup_draft20060224.zip | Licensing_Server_Oper_jp.txt | Licensing_Server_Oper.pdf | Linker_b7703_engineeringBuild.zip | Linker_b82E_engineeringBuild.zip | LinkerBuild7703_forLinkerCrash.txt | LinkerBuild82E_forLinkerCrash.txt | linkerror.JPG | LinkErrorLog.txt | LiveMove_EULA_jp.doc | LiveMoveダウンロード手順.txt | LiveMove配布手順書（企画開発部用）.txt | load_balance.xls | load_balance2.xls | load_balance3.xls | log.bmp | log.txt | log061213.txt | main.c | main.lzh | main.patch | make_Debug_log_CW4DS2.0Beta2.txt | make_log_CW4DS1.2SP3.txt | make_log_CW4DS2.0Beta2.txt | make-ref.zip | Makefile | makelcf.html | makeo_050520.zip | makeromtools.tar.gz | makeWad.html | manual.zip | map.gif | maplcf.LZH | MARIO BROS.zip | mario64_banner101806.zip | mario64_banner102406.zip | mario64_banner110106.zip | MarioVSDK.zip | mastereditor.JPG | match_lan_061011_1205_log.txt | match_lan_061011_1205_main.c | match_serverclient_061011_1424_log.txt | match_serverclient_061011_1424_main.c | MBC5【振動】説明書(1998-11).doc | mcs_err.txt | mem3011.dpf | message_delivery-status.txt | MessageEditerTest.zip | MessageEditor.zip | MessageTag.xls | MiddlewareGuideline_for_Wii_060525.zip | Mii使用文字.xls | ML2Banner_EU.bsf | modeling.htm | Monitor_Ver説明.txt | Monsname.xls | motion_0000_fix.zip | motto_no-19.11.17.apc | motto_no-19.14.58.apc | motto_no-19.19.43.apc | motto_no-19.22.17.apc | MPEG-1.2 AudioLayerIII.doc | MPH-credits-manual.txt | mpsimple.zip | MP通信ガイドラインforWii_061109.zip | msgenc.c | MT060710_01.gif | MT060710_02.gif | ＭＴＳデモ説明.doc | MysteryGift.doc | N64 ROM List.xls | N64_E3.zip | N64_Super_Mario_64_b.zip | N64EmulatorText.zip | N64Text.zip | N64タイトル.xls | name1.h | nami_nuki_test_fix.zip | nami_nuki_test.lzh | Nancy innovative.gif | NAND Application Development Kit JP.doc | NAND Application Development Kit.doc | NAND Application Development May 29 2006.doc | NAND Application Development May 29 2006JP.doc | NAND application development.doc | nand_start_sequence(v.0.1).xls | nand.zip | NANDCheck使用方法の間違いによる不具合リスト061107.xls | NANDCheck使用方法の間違いによる不具合リスト061108.xls | NANDPackage-beta060927.zip | NANDアプリ開発に関する問題点.doc | NAND構造2006-08-26.xls | ＮＣＬ社員用連絡室（Ｒ５１０）0421ver.xls | ＮＣＬ社員用連絡室（Ｒ５１０）0421ver(企開）.xls | NDEV_2_0割り当て一覧.xls | NDEV-Firmware-5_0_0-USB_Ether-060719_jp.zip | ndev823.log | NDEVOutput.txt | ＮＤＥＶ各バージョンの概要.xls | NDEV日程050725.xls | NDEV日程050803.xls | NDEV生産.xls | NDSカンファレンス2005秋.pdf | NDSカンファレンスSpeechOct05Rev3.doc | NES_TEXT.zip | New_Super_Mario_Bros_Cover_Scan.PDF | New_Super_Mario_Bros_Cover.doc | NewAccountDetailsPTD1-VC.xls | NewAccountDetailsPTD1.xls | Newマリオ敵リストＡＬＬ_ver10(最新）.xls | Newマリオ敵リストＡＬＬ_ver10(翻訳）.xls | Ｎｅｗマリオ韓国語翻訳リスト.zip | Nigaoe_me.png | ninten_hikaritest.lzh | Nintendo Wi-Fi Connection_プログラミングガイドライン_ver.1.0.0.pdf | NINTENDO Wi-Fi Connection_プログラミングガイドライン_ver.1.1.1_060131.zip | NINTENDO Wi-Fi Connection_プログラミングガイドラインver1.1.1_20060302.zip | NINTENDO Wi-Fi Connection_プログラミングガイドラインver1.1.1_20060308.zip | NINTENDO Wi-Fi Connection_プログラミングガイドラインver1.1.1_20060310.zip | NINTENDO Wi-Fi Connection_企画検討用ガイドライン_060310.zip | NINTENDO Wi-Fi Connection_企画検討用ガイドライン_060313.zip | NINTENDO Wi-Fi Connection_企画検討用ガイドライン_ver1.1.0_060215-2.zip | NINTENDO Wi-Fi Connection_企画検討用ガイドライン_ver1.1.0_060215.zip | NINTENDO Wi-Fi Connection_企画検討用ガイドライン_ver1.zip | NINTENDO Wi-Fi Connection_開発運用手順書_ver0.1.0_051129.doc | Nintendo Wi-Fi Connection212.zip | Nintendo Wi-Fi Connection213.zip | nintendo_kr_060919暫定版.doc | nintendo_kr_1012.doc | nintendo_kr_1012.pdf | nintendo_logo_e3_2006_060331.zip | nintendo_logo_e3_2006_060406.zip | nintendo_logo_e3_2006.zip | Nintendo_Wi-Fi_Connection_Mes 1.xls | Nintendo_Wi-Fi_Connection_MessageList_050210.xls | Nintendo_Wi-Fi_Connection_MessageList_060210-2.zip | Nintendo_Wi-Fi_Connection_MessageList_060210.xls | Nintendo_Wi-Fi_Connection_MessageList_ForConfigulation.xls | Nintendo_Wi-Fi_Connection_MessageList_ForTranslation_060216.xls | Nintendo_WiFi_Connection_MessageList_Ver110_060531.zip | Nintendo_WiFi_Connection_MessageList_Ver114_061204.xls | Nintendo_WiFi_Connection_MessageList_Ver114_061206.xls | Nintendo_WiFi_Connection_NITRO-DWC_ProgrammingManual_Download_Ver090_060531.zip | Nintendo_WiFi_Connection_NITRO-DWC_ProgrammingManual_Ranking_Ver100_060531.zip | Nintendo_WiFi_Connection_NITRO-DWC_ProgrammingManual_Ranking_Ver100.zip | Nintendo_WiFi_Connection_Overview_Ver018.pdf | Nintendo_WiFi_Connection_Overview_Ver020.zip | Nintendo_WiFi_Connection_ProgrammingGuideline_Ver120_060531.zip | Nintendo_WiFi_Connection_ProgrammingGuideline_Ver120_060609.zip | Nintendo_WiFi_Connection_ProgrammingGuideline_Ver130_060704.zip | Nintendo_WiFi_Connection_ProgrammingGuideline_Ver130_060706.zip | Nintendo_WiFi_Connection_ProgrammingGuideline_Ver130_060714_2.zip | Nintendo_WiFi_Connection_ProgrammingGuideline_Ver130_060714.zip | Nintendo_WiFi_Connection_ProgrammingGuideline_Ver131_061113.zip | Nintendo_WiFi_Connection_ProgrammingGuideline_Wii.zip | Nintendo_World_2006バージョン制作ガイドライン(任天堂タイトル向け)_Ver.1.0_061020.doc | Nintendo_World-061024.zip | nintendo_world2006.pdf | Nintendo_World企画開発部.xls | Nintendo_World企画開発部(変更）.xls | Nintendo_World企画開発部(追加）.xls | NintendoWare2006_12_26版３Ｄ関連試用レポート.txt | NintendoWare３／６ver協議用情報.txt | nintenpo.ddo.jp.der | nintenpo.nintendo.co.jp.der | NitroCrypt-1_0rc2-050106.zip | NitroDWC_to_RVL_2.pdf | NitroDWC-1[1].0pr2-050930-2223-private.zip | NitroMiddleware-libPEDM-alpha-061013.zip | NitroSDK-WXC-050922.zip | NitroSDK-WXC-051011.zip | NitroSDK／優先通信.mht | nitroSoundMaker_Fig3_8.JPG | NNGCツール060224.xls | NNGC基本日程表060418.xls | NNGC開発ツール　会議メモVer.2.doc | No_touch_Debug_061014.xls | No_touch_Debug.xls | NOA Lot Check Precheck Issues_1.doc | NOA LOT CHECK.doc | NOA VC Launch-Feb Release Schedule.xls | NOA VC Release Schedule 2007 112106.xls | NOA VC Release Schedule 2007 112906.xls | NOA VC Release Schedule 2007 121306.xls | NOAからのメール原文.txt | NOAローカライゼーションのNCL訪問時打合せ希望について.eml | NOA用ソフト開発状況_050823.xls | NOA用ソフト開発状況_050824_01.xls | NOA用ソフト開発状況_050824.xls | NOA用ソフト開発状況_051024.xls | NOA用ソフト開発状況051128.xls | NOA用ソフト開発状況060327.xls | NOE_Localization_12Oct06.xls | NOE_Localization_26Oct06.xls | NOE_TS_04.doc | NOE用ソフト開発状況060519.xls | NOE用ソフト開発状況0611.xls | NOKmoji.doc | ＮＯＫ業務委託連絡書（企画開発）.doc | ＮＯＫ業務委託連絡書（環境制作）.doc | nou_tore_shuusei20061018.doc | nou_tore_shuusei20061024.doc | NSTからのWi-Fiに関するミーティング依頼.eml | NSTとNintendoWare絡みのミーティング.eml | NTR_ryouri_buglist0607.xls | NTRMEM.exe | NTRMEM103.EXE | nuki_situmon.lzh | nukitest_fix.rmdl | nukitest_setumei.zip | nukitest.lzh | NW4R3DEditor.jpg | nware_S20051107.doc | NWWiiタイトルリスト技術確認用.xls | NW説明員・企画開発部.xls | Ocarina_epilepsycheck.xls | OdemError.jpg | OnAccessScanLog.txt | Online RCF Reporting _ Results from 11_18_2006 to 12_1_2006.eml | Online RCF Reporting _ Results from 12_1_2006 to 12_7_2006.eml | online_QA.xls | online_QA回答.xls | Opera Component - File and installation - 0.77.doc | opera.ini | opera.zip | Opera060801議事録.txt | Opera060803電話会議.txt | Opera060822議事録.txt | Opera060829議事録.txt | Opera060905議事録.txt | Opera060912議事録.txt | Opera060926議事録.txt | Opera061010議事録.txt | operaskin.zip | ot_kpad.h | Output.pdf | ParentalControlAll.jp.doc | particle.zip | passby050627.doc | passby050627.zip | PcmCache.txt | PDM経営会議上程資料09252006-1.doc | Pearl.zip | pedometer.srl | Pegi Ratings_update_September_25th_2006.xls | PERIPHERAL_DEVICES.xls | PET商品ラインナップ.pdf | PG1_wii.xls | PG2_wii.xls | PG4_wii_re.xls | PkdstaffList_NOE_060703.xls | PKMNEM_FR_0523.zip | PKMNEM_FR_0524.zip | PKMNEM_FR_0525.zip | PKMNEM_FR_0527.zip | PKMNEM_FR_0530.zip | PKMNEM_FR_0531.zip | PKMNEM_FR_0601.zip | PKMNEM_FR_0602.zip | PKMNEM_FR_0603.zip | PKMNEM_FR_0606.zip | PKMNEM_FR_0607.zip | PKMNEM_FR_0608.zip | PKMNEM_FR_0609.zip | PKMNEM_FR_0610.zip | PKMNEM_FR_0613.zip | PKMNEM_FR_0614.zip | PKMNEM_FR_0615.zip | PKMNEM_FR_0616.zip | PKMNEM_FR_0617.zip | PKMNEM_FR_0620.zip | PKMNEM_FR_0621.zip | PKMNEM_FR_0622.zip | PKMNEM_FR_0623.zip | PKMNEM_FR_0627.zip | PKMNEM_FR_0628.zip | PKMNEM_GE_0523.zip | PKMNEM_GE_0524.zip | PKMNEM_GE_0525.zip | PKMNEM_GE_0527.zip | PKMNEM_GE_0530.zip | PKMNEM_GE_0531.zip | PKMNEM_GE_0601.zip | PKMNEM_GE_0602.zip | PKMNEM_GE_0603.zip | PKMNEM_GE_0606.zip | PKMNEM_GE_0607.zip | PKMNEM_GE_0608.zip | PKMNEM_GE_0609.zip | PKMNEM_GE_0610.zip | PKMNEM_GE_0613.zip | PKMNEM_GE_0614.zip | PKMNEM_GE_0615.zip | PKMNEM_GE_0616.zip | PKMNEM_GE_0617.zip | PKMNEM_GE_0620.zip | PKMNEM_GE_0621.zip | PKMNEM_GE_0622.zip | PKMNEM_GE_0623.zip | PKMNEM_GE_0624.zip | PKMNEM_GE_0627.zip | PKMNEM_GE_0628.zip | PKMNEM_GE_0629.zip | PKMNEM_GE_0630.zip | PKMNEM_GE_0701.zip | PKMNEM_GE_0704.zip | PKMNEM_GE_0706.zip | PKMNEM_IT_0523.zip | PKMNEM_IT_0524.zip | PKMNEM_IT_0525.zip | PKMNEM_IT_0527.zip | PKMNEM_IT_0530.zip | PKMNEM_IT_0531.zip | PKMNEM_IT_0601.zip | PKMNEM_IT_0602.zip | PKMNEM_IT_0603.zip | PKMNEM_IT_0606.zip | PKMNEM_IT_0607.zip | PKMNEM_IT_0608.zip | PKMNEM_IT_0609.zip | PKMNEM_IT_0610.zip | PKMNEM_IT_0613.zip | PKMNEM_IT_0614.zip | PKMNEM_IT_0615.zip | PKMNEM_IT_0616.zip | PKMNEM_IT_0617.zip | PKMNEM_IT_0620.zip | PKMNEM_IT_0621.zip | PKMNEM_IT_0622.zip | PKMNEM_IT_0623.zip | PKMNEM_IT_0624.zip | PKMNEM_IT_0627.zip | PKMNEM_IT_0628.zip | PKMNEM_IT_0629.zip | PKMNEM_IT_0630.zip | PKMNEM_IT_0701.zip | PKMNEM_SP_0523.zip | PKMNEM_SP_0524.zip | PKMNEM_SP_0525.zip | PKMNEM_SP_0527.zip | PKMNEM_SP_0530.zip | PKMNEM_SP_0531.zip | PKMNEM_SP_0601.zip | PKMNEM_SP_0602.zip | PKMNEM_SP_0603.zip | PKMNEM_SP_0606.zip | PKMNEM_SP_0607.zip | PKMNEM_SP_0608.zip | PKMNEM_SP_0609.zip | PKMNEM_SP_0610.zip | PKMNEM_SP_0613.zip | PKMNEM_SP_0614.zip | PKMNEM_SP_0615.zip | PKMNEM_SP_0616.zip | PKMNEM_SP_0617.zip | PKMNEM_SP_0620.zip | PKMNEM_SP_0621.zip | PKMNEM_SP_0622.zip | PKMNEM_SP_0623.zip | PKMNEM_SP_0624.zip | PKMNEM_SP_0628.zip | PKMNEM_SP_0629.zip | PKMNEM_SPnames_0607.zip | PKMNNEM_SP_0627.zip | PKNNEM_FR_0624.zip | poke-doc.txt | Pokemon Emerald.doc | Ports platforms.gif | Preview_GuideLine.pdf | ProgrammingGuideline.pdf | Project Munchkin - Nintendo Wi-Fi 2006-06-20_jp.ppt | pruefergebnisse_1.xls | q_20060706.txt | q_20060908.zip | q_20061115.zip | QandA20060323.txt | Qestion from Ubisoft.doc | QFC_microphone.txt | Question.txt | QuickSave.doc | rakubiki-12.20.03.apc | rakubiki-12.21.30.apc | rakubiki-12.24.13.apc | rakubiki-12.25.56.apc | rakubiki-13.26.10.apc | rakubiki.txt | rare.gif | Re [REVO_VirtualConsole_NOA_00046] Re_ VC Launch Titles(PAL)NOA Report (11_28).eml | Re ＤＰ発売に関して(さらに添付ファイルを含むらしい).eml | Re_ NSTからのWi-Fiに関するミーティング依頼.eml | Re_ NSTからのWi-Fiに関するミーティング依頼2.eml | Re_ VoiceChatSDKに関する要望と質問について.eml | Re_ VoiceChatSDKに関する要望と質問について(2).eml | Re_ Wii （欧州）について.eml | Re_ ツールの優先出荷先.eml | Re_ ハンタ－ズ Wifi 状況の件.eml | Re_ ボイスチャット　今後の進め方の相談.eml | Re_ ボイスチャット　今後の進め方の相談(2).eml | Re_ ボイスチャット　今後の進め方の相談(3).eml | Re_ メトロイドプライムハンターの件.eml | RE_ 英国ゲーム関係通商使節団の件(さらに添付ファイルを含むらしい).eml | re.txt | Readme_en_Ver06.txt | Readme_en.txt | Readme_jp_Ver06.txt | Readme_jp.txt | README_SDK30_check_20060202.zip | readme-homebuttonLib_060913_en.txt | readme-homebuttonLib_060913.txt | Readme-NitroMiddleware-libVCT-1_0_0-060516.txt | readme-RVL_SDK-2_2-patch_jp.txt | readme.txt | Readme.txt | README.txt | readme1st.txt | ReadmeENG.txt | ReadmeJP.txt | recommend.html | ReleaseNote_jp.html | ReleaseNotes-1.1.zip | ReleaseNotes-1.2.zip | rendermode.txt | rendermodeHVC.txt | report_20060922.zip | report_20061124.txt | report.doc | report.zip | Request from Developer(さらに添付ファイルを含むらしい).eml | request_060916.txt | requestedschedule.xls | resume.zip | Revolution_controller_hardware_overview-j.pdf | Revolution_controller_hardware_overview.zip | Revolution_controller_ver_3_setup-j.pdf | Revolution_question-0112.xls | REVOLUTIONネットワークサポートページ.htm | Revoプレゼンセカンド用・2005年10月21日.ppt | REVネットワーク進捗報告会(060911).ppt | REVネットワーク進捗報告会(061018).ppt | REVネットワーク開発の進め方.ppt | REVネットワーク開発の進め方(060206).ppt | REVネットワーク開発の進め方(060207).ppt | REV必要作業一覧060417.xls | REV必要作業一覧表(060124 田原).xls | REV必要作業一覧表(060124)_島田.xls | REV必要作業一覧表(060124).xls | REV必要作業一覧表(060126環境制作).xls | REV必要作業一覧表(機能別)060207-1.xls | REV必要作業一覧表(環境制作G060126).xls | REV必要作業一覧表(部署別)060203.xls | REV必要作業一覧表(部署別)060207_3.xls | REV必要作業一覧表(高橋修正版）)060207_3.xls | REV必要作業一覧表060130-2.xls | REV必要作業一覧表060130-3.xls | REV必要作業一覧表060130.xls | REV必要作業一覧表060131-1.xls | REV必要作業一覧表060131.xls | REV必要作業一覧表060201_3.xls | REV必要作業一覧表060201.xls | REV必要作業一覧表060202_2.xls | rfc822-headers.txt | RFL_Library_Guidelines_20061214_EAD.doc | RFL_Library_Guidelines_20061214_EAD.pdf | RFL_Res.zip | Rimg9086.jpg | robo_s.wmv | ROM_info060525.txt | ROM一覧060906.xls | ＲＯＭ入手状況0828.xls | RP Nintendo BPED00 Pokemon Smaragd.pdf | RP Nintendo BPEF00 Pkmn Emeraude.pdf | RP NINTENDO BPEI00 Pokemon smeraldo.pdf | RP Nintendo BPES00 Pokemon Emerald.pdf | RP Nintendo FAAP2 Donkey Kong_J.pdf | RTYPE1.bmp | RVL_Banner_Gudeline_060720.zip | RVL_demo_info_E3-2006_SPD5_060501.xls | RVL_KPAD_SDK20051122alpha.zip | RVL_KPAD_SDK20051124rc1.zip | RVL_KPAD_SDK20051125.zip | RVL_KPAD_SDK20051128.zip | RVL_MasterDataCheckSheetJp.htm | RVL_MasterEditorForNANDAPP-061106_vc.zip | RVL_MasteringTools-beta-060706_jp.ZIP | RVL_MasteringTools-E3-RC1-060410.zip | RVL_MasteringTools-E3-RC2-060410.zip | RVL_MasteringTools-E3-RC3-060410.zip | RVL_NADK-060808.zip | RVL_SDK-2_2-060907_jp_RC1_diff.zip | RVL_SO_SDK-060629.zip | RVL_VC_CheckList061006.xls | RVL_VC_CheckList061010.xls | RVL_VC_CheckList061011_en.xls | RVL_VC_CheckList061011.xls | RVL_VC_CheckList061019nakai.xls | RVL_VC_CheckList061020.xls | RVL_VC_CheckList061023.xls | RVL_VC_CheckList061024_en.xls | RVL_VC_CheckList061024.xls | RVL_VC_CheckList061024a_en.xls | RVL_VC_CheckList061031_en_1.xls | RVL_VC_CheckList061031_jp.xls | RVL_VC_Debug_jp_Ver100.doc | RVL_VC_Debug_jp_Ver101.doc | RVL_VC_Doc060919.zip | RVL_VC_Guideline_jp_Ver100.doc | RVL_VC_Guideline_jp_Ver101.doc | RVL_VC_Guideline_jp_Ver102.doc | RVL_VC_Guideline_jp_Ver103.doc | RVL_VC_Guideline_jp_Ver104.doc | RVL_VC_Guideline_jp_Ver105_評価版_061113.doc | RVL_VC_Guideline_jp_Ver106_061118.doc | RVL_VC_Overview_jp_Ver100.doc | RVL_VC_Overview_jp_Ver101.doc | RVL_VC_Overview_jp_Ver102.doc | RVL_VC_Overview_jp_Ver103.doc | RVL_VC_Specifications_jp_Ver100.doc | RVL_VC_Specifications_jp_Ver101.doc | RVL_VC_Specifications_jp_Ver102.doc | RVL_VC_Specifications_jp_Ver103.doc | RVL_VC_Specifications_jp_Ver104.doc | RVL_VC_Specifications_jp_Ver105.doc | RVL_VC_Specifications_jp_Ver109.doc | RVL_VC_Specifications_jp_Ver113_061118.doc | RVL_VCEM_FXXJ_JPN_O.arc | RVL_VCEM_FXXJ_JPN_O.zip | RVL_VCMV_SDK-1_2-VerboseLibs.zip | RVL_VCMV_SDK-1_4-061101 Patch1 Readme_en.txt | RVL_VCMV_SDK-1_4-061101_patch1.zip | RVL_VCMV_SDK-1_4-061101_Patch3.zip | RVL_WPAD_SDK20051122alpha.zip | RVL_WPAD_SDK20051124rc1.zip | RVL_WPAD_SDK20051125.zip | RVL-NADK-Nmenu_patch-061102_jp_RC1.zip | RVL-VC_JP+US_051222_rev.xls | RVL3連ボタンアンケート結果.xls | RVLFaceLibraryAlpha3_0926.zip | RVLコントローラ0728資料.pdf | RVLコントローラ送付.mm | RVLソフト設定規則.pdf | ＲＶＬデバッグ機材必要数.xls | RVLネーミング案_2（部署名_提出日）.xls | RVLネーミング案（部署名_提出日）.xls | RVLネーミング案（集計_0809_1800）.xls | RVLネーミング案（集計_0810_1700）.xls | RVLプログラミング注意事項検討資料_060529.xls | RVLマリオ64_光過敏_060407.pdf | RVL用語集 E3 Ver社内（VC担当者専用）用 01版.lzh | RVL用語集-E3 Ver社内用 02x版.xls | RVL用語集-E3 Ver社内用（VC専用） 02版.lzh | RVL用語集-E3 Ver社内用（VC専用） 02版.xls | RVL用語集0603xx-E3用.xls | RVL開発環境.pdf | RVL開発環境調査結果.txt | RVT ライティングソフトウェアリリース通知_1.0.0.2.zip | RVT-H_manual_20061013.doc | rvtwriter1002.ZIP | sagyosizisyo061106.xls | sample_txt.lzh | sample.cpp | sample.ddf | sample.zip | sample1.cpp | sample2.cpp | SampleViewer_src1226.zip | SANYO_512kFLASHコマンド.tif | save_banner.pdf | save.png | Schedule-Machiuke(060425).pdf | Schedule-NWC(060428).pdf | Schedule-VC(060419v2).pdf | ScnRfl.zip | screenshot_N64.bmp | Screenshot_Tool_20060328.zip | Screenshot_Tool_20060329.zip | screenshot.lzh | scroll_bar_test.jpg | SDK30_DS20ipaFile_Compiler-b109.xls | SDK30_DS20ipaFile.xls | sequence.html | Server schedule(10302006).xls | sharedコンテンツ一覧_061120.xls | Shinseisyo.xls | ShinseisyoRevSample.xls | ShinseisyoRevSample051128.xls | showlist.128.elf | showlist.64.elf | showversion_RVL.doc | showversion.doc | SHVC_Game2HBM.jpg | SHVC_SOUND_マリクラ試算.xls | SHVC-EM-FilterTestSav1.crd | SHVC-SC-sram | SimCity.sram | simple.zip | SlowTest.zip | Smario64_1a.JPG | SMC-BTS概要.ppt | SMPTE75%ColorBar_Spec.jpg | SMPTE75%ColorBar.jpg | sndarc_stream.c | sockets_test.zip | software_arch_special.pdf | software_arch.pdf | spatnav_TC.zip | spd_network_vision.xls | spec_20060926_2.zip | spec_20060926_3.zip | spec_20060926_4.zip | spec_20060926.zip | spec.pdf | spec.txt | spec.zip | spec2.pdf | Special characters lacking at present.xls | Special Characters Others_Examples_JP.rtf | spl.zip | SPRArchiver.zip | ss.lzh | ST2-modify1.lzh | StaffCredit_061010.xls | StaffCredit_061010①.xls | StaffCredit060929.xls | StaffCredit061031.xls | StaffCredit追加061030.xls | staffrol_0705noa.xls | start.png | startup.html | Stationery_for_SDK3.0.zip | std_skin.zip | steperr_prj.LZH | steperr.lzh | strap_060908.zip | strap_640x480_jp.bmp | strap_640x480_us.bmp | strap.doc | suspend.png | swfdump.ZIP | swing20060118.tif | System Menu Development.doc | System menu における NAND 空き容量チェック.doc | System Update Procedure.doc | System Update.doc | TCB.bmp | TDEV+CW+DVDETH.txt | TDEVでのデバッグ方法.txt | Test environment.jpg | test_06_kuroda_compress.mb | test_dev-01238.png | test_opt.zip | test.lzh | test.txt | test.zip | testcube.imd | testD6.lzh | TestData2.lzh | testfont.html | testProg.zip | tetrisrank060111.zip | TFT-051005企開出展候補.xls | TGS2005基調講演Outline.doc | TGS2005基調講演Outline(2).doc | title.met | Tony Hawk changes.doc | Tony Hawk Downhill Jamに関するアクティビジョンからのリクエスト.doc | Tony_Hawk_Downhill_Jam.doc | TouchGenerations.pdf | Turbografx schedule 1128.xls | Turbografx schedule1213.xls | tuusin.bmp | Ufo4Nintendo.xls | ufoSecSize.lst | UIツールver3.1E配付数量打合せ_20060413.xls | UI会議アンケート050614.doc | UPS Country Regulations.url | US Manual issues 111206.xls | US12042006UploadReport.pdf | userManual.pdf | USG-KORmanual0921.doc | USG-KORmanual0925(修正済み).doc | USG-KORmanual0929.doc | USGManual_Change.doc | ＵＳＧ韓国発売スケジュール0920-1.xls | ＵＳＧ韓国発売スケジュール1024.xls | uvtest_20060314.zip | uvtest.lzh | vad.c | VC 2 Bug Log 1204.xls | VC 2 Bug Log 1205.xls | VC 2 Bug Log 1208_NCL.xls | VC 2 Bug Log 1208.xls | VC 2 Bug Log 1212_IS.xls | VC 2 Bug Log 1212.xls | VC 2 Bug Log 1213.xls | VC 2 Bug Log 1218.xls | VC 2 Bug Log 1219.xls | VC 2 Bug Log 1220.xls | VC 2 PAL Bug Log 1212.xls | VC Launch Bug Log PAL 1127_IS.xls | VC Launch Bug Log PAL 1127.xls | VC Launch Bug Log_1031_NCL記入.xls | VC Launch Bug Log_1101_from_NCL.xls | VC Launch Bug Log_1102_from_NCL.xls | VC Launch Bug Log_1102.xls | VC Launch Bug Log_1103_from_NCL.xls | VC Launch Bug Log_1106_fromNCL.xls | VC Launch Bug Log_1107_fromNCL.xls | VC Launch Bug Log_1107.xls | VC Launch Bug Log_1108_fromNCL.xls | VC Launch Bug Log_1109.xls | VC Launch Bug Log_1110_fromNCL.xls | VC Launch Bug Log_1110.xls | VC Launch Bug Log_1113_NCL_comments.xls | VC Launch Bug Log_1114_fromNCL.xls | VC Launch Bug Log_1114_NCL_IS.xls | VC Launch Bug Log_1114.xls | VC Launch Bug Log_1115.xls | VC Launch Bug Log_1116.xls | VC Launch PAL Bug Log 1129.xls | VC Launch PAL Bug Log 1130-NCL.xls | VC Launch PAL Bug Log 1130-NCL2.xls | VC Launch PAL Bug Log 1130.xls | VC Localization.eml | VC Progress Chart1.4.xls | VC TV Problems.xls | VC_2_games_US_SpecSheet_061212.zip | VC_Contents_Progress060816.pdf | vc_debugfiles_20061114.xls | vc_debugfiles_20061115.xls | vc_debugfiles_20061117.xls | vc_debugfiles_20061121.xls | vc_debugfiles_for_NOA20061208.xls | vc_debugfiles_for_NOA20061212.xls | vc_debugfiles_for_NOA20061213.xls | vc_debugfiles_for_NOA20061219.xls | VC_DonkeyKong_lotcheck.zip | vc_euro_debugfiles_20061127_2.xls | vc_euro_debugfiles_20061127_3.xls | vc_euro_debugfiles_20061127_4.xls | vc_euro_debugfiles_20061127_5.xls | vc_euro_debugfiles_20061128_2.xls | vc_euro_debugfiles_20061128.xls | vc_euro_debugfiles_20061129.xls | vc_euro_debugfiles_20061201.xls | vc_euro_debugfiles_20061206.xls | vc_euro_debugfiles_20061207_2.xls | vc_euro_debugfiles_20061207.xls | vc_euro_debugfiles_20061215.xls | vc_euro_debugfiles_20061218_2.xls | vc_euro_debugfiles_20061220.xls | VC_HVC_guide_0908.zip | VC_info.zip | VC_manual_061104.xls | VC_manual_061122a.xls | VC_Mario64_NOE_1111.zip | VC_MD_guide_0908.zip | VC_N64_guide_0908.zip | VC_NCL.part2.rar | VC_NCL.part3.rar | VC_NOE_1130.zip | VC_NOE_1206.zip | VC_NOEManuals_1128.zip | VC_PCE_guide_0908.zip | VC_save_banner_リリース版.xls | VC_SHVC_guide_0908.zip | VC_Title_code1214返信.xls | VC_Title_List.xls | VC_Title_List061028a.xls | VC_Title_List061101.xls | VC_Title_List061107a.xls | VC_Title_List061108.xls | VC_Title_List061113a.zip | VC_Title_List061114.xls | VC_Title_List061114.zip | VC_Title_List061114a_IS.xls | VC_Title_List061114a.xls | VC_Title_List061115a.xls | VC_Title_List061117b English.xls | VC_Title_List061118.xls | VC_Title_List061212.xls | VC_Title_List061212.zip | VC_Title_List061214IS.xls | VC_Title_List061218.xls | VC_Title_List061219IS.xls | VC_Title_ListEnglish.xls | VC_Work_Flow061117.xls | VC_タイトルリスト061127.xls | VC-contents-detail060822.pdf | VC-contents060822.pdf | VC-contents060913.pdf | VC-Schedule061118.pdf | vc.txt | vc64_banner.zip | VCAWスケジュール0607.pdf | VCAWスケジュール0719.pdf | VCAWスケジュール0720.pdf | VCAW日割り0607_全体.pdf | VCAW日割り0719_全体.pdf | VCAW日割り0724_全体.pdf | VCAW日割り0821_全体.pdf | VCAW日割り0906_全体.pdf | VCAW日割り1115_全体.pdf | vcm64_start_sequence(v.0.2).xls | vcm64_start_sequence(v.0.3).xls | vcm64_start_sequence(v.0.4).xls | vcmv_skin.zip | vcmv_test.c | vcmv_test.cpp | vcmv.h | VCMV.zip | vcmvlib.zip | VcmvTest.mcp | VCSchedule_0906.xls | VCWGimage0703.pdf | VCアートワーク用提出データ_20060718.pdf | VCアートワーク用貸出サンプル20060718.pdf | VCオーバービュー060918.doc | VCガイドライン.doc | VCガイドライン060810.doc | VCガイドライン060814.doc | VCガイドライン060815.doc | VCガイドライン060816.doc | VCガイドライン060817.doc | VCガイドライン060818.doc | VCガイドライン060822.doc | VCガイドライン060824.doc | VCガイドライン060829.doc | VCガイドライン060830.doc | VCガイドライン060831.doc | VCガイドライン060901.doc | VCガイドライン060913.doc | VCガイドライン060914.doc | VCガイドライン060915.doc | VCガイドライン060918.doc | VCコントローラ割り当て手順060913.doc | VCコントローラ割り当て手順060914.doc | VCコントローラ割り当て手順060915.doc | VCスケジュール20060919A.xls | VCスケジュール20060921.xls | VCタイトル属性20060807.xls | VCタイトル属性20060818.xls | VCフロー_re0322.pdf | VCフロー_re0322(2).pdf | VCフロー_re0411.pdf | VCフロー_re0411(2).pdf | VCフロー_re0412_2.pdf | VCフロー_re0412_2(2).pdf | VCフロー_re0412.pdf | VCフロー_re0412(2).pdf | VCフロー.pdf | VCフロー(2).pdf | VCマリオ６４：バナーデータ更新.eml | VCマリオ６４：バナーとセーブファイルアイコンについて.eml | VCリスト060523.txt | VCロンチタイトル権利表記060726.xls | ＶＣ休日出勤アンケート1208～1215.xls | ＶＣ候補タイトル20060522.xls | ＶＣ候補タイトル20060524.xls | VC基本スケジュール.pdf | VC状態遷移図.doc | VC状態遷移図060713.xls | VC状態遷移図060721.xls | VC用印刷物サンプル収集070306.xls | ＶＣ画面遷移フロー解説.doc | ＶＣ画面遷移フロー解説と作業.doc | VC見積り1.jpg | VC見積り2.jpg | Ｖｅｒ１．２（新）のログ.txt | Ｖｅｒ１．２（旧）のログ.txt | Virtual Console_NOE_1129.zip | Virtual Console_RVTUnit | Virtual Console_RVTUnit.zip | Virtual Console_RVTUnit/RTV_2_Reader_1.jpg | Virtual Console_RVTUnit/RTV_2_Reader_2.jpg | Virtual Console_RVTUnit/Thumbs.db | VirtualConsolArchitect20060620.ppt | VirtualConsole20060509.txt | VirtualConsole20060529.txt | VirtualConsoleArchitect20060711.ppt | VirtualConsoleContoroller案.ppt | VirtualConsoleFileFormat.xls | VirtualConsoleFileFormat060923.xls | VirtualConsoleFileFormat060925.xls | VirtualConsoleFileFormat060928.xls | VirtualConsoleFileFormat060929.xls | VirtualConsoleFileFormat061211.xls | VirtualConsoleSchedule.xls | VirtualConsoleSchedule20060424.xls | VirtualConsoleScheduleForManual.txt | vol31案.txt | Vsense.pdf | VX_test.xls | WAD Format.doc | wadscript | wadscriptD | warning.jpg | we.gif | WhitePaper_jp.pdf | Ｗｉ－Ｆｉ connection 対応ソフト運用案マスター9_30_1.ppt | WI-Fi_BattleTower060130.doc | Wi-Fi_Error_Code(050926).xls | Wi-Fi_Error_Code(051201).xls | Wi-Fi_Error_Code(051201).xls 2.xls | Wi-Fi_Error_Code(051202).xls | Wi-Fi用語集(02版).xls | Wi-Fi用語集(03版).xls | Wi-Fi用語集(Ver00)0727.xls | Wide.xls | WiFi_Connection_userinfo.zip | WiFi.zip | WiFiPause.zip | wifiに関する連絡フロー.xls | WiFi専用ロットチェック説明資料003_050926.zip | Wii manual-Virtual Console 061007.pdf | Wii_Conference_20060829.zip | Wii_Conference_Guideline.jp.txt | Wii_Conference_Guideline.us.t 1 | Wii_Conference_Guideline.us.t 2 | Wii_Conference_Guideline.us.txt | Wii_demo_info_WP-2006_060901.xls | Wii_demo_info_WP-2006_060905.xls | Wii_Guidelines_v0_98.pdf | Wii_Guidelines_v0.94.pdf | Wii_Guidelines_v0.95.pdf | Wii_Guidelines_v0.96.pdf | Wii_Guidelines_v0.97.pdf | Wii_Guidelines_v0.98.pdf | Wii_Guidelines_v1.00.pdf | Wii_MessageList_0.10.xls | Wii_MessageList_0.11.xls | Wii_MessageList_0.12.xls | Wii_MessageList_0.13.xls | Wii_MessageList_0.131.xls | Wii_MessageList_0.131（修正入）.xls | Wii_MessageList_0.14b_en.xls | Wii_MessageList_0.14b_eur.xls | Wii_MessageList_0.14c_en.xls | Wii_MessageList_0.14c_en.zip | Wii_MessageList_0.14c_eur.xls | Wii_MessageList_0.15_en.xls | Wii_MessageList_0.15_eur_edit_NOE_1207.xls | Wii_MessageList_0.15_eur.xls | Wii_MessageList_0.15_eur.zip | Wii_MessageList_0.15a_eur.xls | Wii_MessageList_v0_15.xls | Wii_MessageList.xls | wii_nintendo_logo_e3_2006_060428.zip | Wii_Nintendo_WiFi_Connection_Docs_061107.zip | Wii_Nintendo_WiFi_Connection_Docs_061109.zip | Wii_Nintendo_WiFi_Connection_Docs_061109b.zip | Wii_Nintendo_WiFi_Connection_Docs_061110.zip | Wii_Nintendo_WiFi_Connection_MessageList.xls | Wii_ProgrammingGuidelines_V1.01_MessageList_v0.14_2006_1006.zip | Wii_ProgrammingGuidelines.zip | Wii_shop_message_1012 EDITED version 6.xls | wii_shop_message_1024.xls | wii_shop_message_1026 EDITED.xls | wii_shop_message_1030 EDITED.xls | wii_shop_stuff_list.xls | Wii_SystemMenu_schedule_2006_0921.pdf | Wii_SystemMenu_schedule_2006_1017_1530.pdf | Wii_SystemMenu_schedule.pdf | Wii_ワイド画面対応.xls | Wii-VirtualConsole_Specifications_CheckSheet_J.doc | Wii(NAND)-CheckSheet_Description_1_00_J.pdf | Wii(NAND)-VirtualConsole_CheckSheet_1_00_J.doc | WiiConnect24オーバービュー_060526.doc | WiiPreview_VerList_060908NOA.xls | WiiPreview_VerList_060908_NOE.xls | WiiPreview_VerList_060909_NOA.xls | WiiPreview_VerList_060909_NOE.xls | WiiPreview_VerList_060910_NOA.xls | WiiPreview_VerList_060910_NOE.xls | WiiPreview_VerList_060911_NOA.xls | WiiPreview_VerList_060911_NOE.xls | WiiPreview_VerList_060913_NOA.xls | WiiPreview_VerList_060913_NOE.xls | WiiPrevie構成v1.pdf | WiiRemote_Strap.jpg | WiiSaveDataBanner.pdf | WiiSaveDataGuideline_jp_060919.pdf | WiiTitle_PG1.xls | WiiTitle_PG2.xls | WiiTitle_PG3_0704.xls | WiiTitle_PG4.xls | WiiWide_TVWide.zip | Wiiカンファレンス0609バージョンガイドライン_Ver.0.9_060831.doc | Wiiカンファレンス0609バージョンガイドライン(任天堂タイトル向け)_Ver.0.8_060828.doc | Wiiカンファレンス0609バージョンガイドライン(任天堂ディスクタイトル向け)_Ver.0.9_060830.doc | Wiiショッピングch作業概要.xls | Wiiショッピングチャンネル議事録061011.txt | Wiiツール関係情報まとめ_060712.xls | Wiiネットワーク全体スケジュール(060707).xls | Wiiネットワーク全体スケジュール(060818).xls | Wiiネットワーク全体スケジュール(060824).xls | Wiiプログラミングガイドラインv0.91α.zip | Wiiプログラミングガイドラインv0.92α.zip | Wiiプログラミングガイドラインv0.93α.zip | Wiiプログラミングガイドラインv0.94.zip | Wiiプログラミングガイドラインv0.94.zip | Wiiプログラミングガイドラインv0.95.zip | Wiiプログラミングガイドラインv0.96.zip | Wiiプログラミングガイドラインv0.97.zip | Wiiプログラミングガイドラインv0.9α.zip | Wiiプログラミングガイドライン検討資料20060626.xls | Wiiホームボタンメニューに付いて.doc | Wiiリモコンミーティング議事録20060531.txt | Wii取説.pdf | Wii取説で気づいたこと.txt | Wii向け外字リスト_060818.xls | Wii日程092501.xls | Wii本体取説-社内回覧060907.pdf | Wii本体取説（準備編 改訂1）.pdf | Wii本体取説チェック依頼.pdf | Wii本体機能ROM出しスケジュール20061120.pdf | Wii本体機能ROM出しスケジュール20061120.xls | Wii本体機能応援デバッグ部屋割り.xls | Wii本体機能開発スケジュール20061116.pdf | Wii機材各種対応リスト_20060817.xls | Wii機材各種対応リスト_20060821.xls | Wii機材各種対応リスト_20060904.xls | Wii用語集-00（社内用）.xls | Wii開発環境.xls | WlIntr.c | Work_Flow.xls | Work_Flow060816.xls | Work_Flow060822.xls | Work_Flow060911.xls | Work_Flow061002.xls | Work_Flow061007.xls | Work_Flow061007Bilingual.xls | Work_Flow061011.xls | Work_Flow061028 English.xls | Work_Flow061028.xls | Work_Flow061107.xls | Work_Flow061114.xls | wpad_tool.elf.eml | wpad_toolD.elf.eml | www.h | XFB.zip | Zelda no Densetsu.sram | アートワーク.txt | アウトラインフォント：試用フォント２つを試した結果.eml | アンケート.pdf | アンケートシート.xls | アンケートメッセージ.doc | イベント企画Gamestation Summer conference 2005.doc | イベント企画Post Leipzig Tour 2005.doc | イベント企画Toys’R’US Meeting 2005.doc | エッジマーキング.lzh | エメ欧州プリロット用データ一覧.xls | エメ欧州プリロット用データ基地.xls | エラーサーバ利用手順.doc | オシャレ魔女ラブandベリー_1W_061126.pdf | カウントダウン.xls | カウントダウンUS.xls | かなハングル対照表061107.xls | キャリアインタビュー(車座)　グループ編成一覧.xls | キャリアインタビュー(車座)　グループ編成一覧(7.14ver.).xls | キャリアインタビュー(車座)　スケジュール表.xls | キャリアインタビューでの質問事項.doc | キャリアインタビュー車座の運営メモ.doc | キャリアインタビュー面談予定表企画開発部.xls | キャリアシート統合(企画開発部第5P).pdf | キャリア車座イベントについての報告とお願い.doc | キャンペーン：救声主セット.pdf | クラシック貸出.xls | クラブニンテンドーレポート061203.lzh | クラブニンテンドーレポートⅠ.lzh | クラブニンテンドーレポートⅡ.lzh | グループ別テーマ(6.29).doc | グループ別テーマ(組織改革).doc | グレード変更推薦書.doc | クレーム.pdf | ゲームセミナー2006企画書.doc | ゲームデータ取扱GL050531改定.doc | ゲームデータ取扱ガイドライン060801.doc | ゲームリモコン＆クラシックコントローラボタン名称検討.xls | ゲーム物内容情報表示規定（案）.doc | コピーNewマリオ基本用語（韓国翻訳用)0925翻訳.xls | コピーREV必要作業一覧表(060124).xls | コピーバグリスト【ＶＣソフトチェック】_開発記入20061108.xls | コピー契約社員.xls | コピー敵リストＡＬＬ_ver10(翻訳）.xls | コントローラUI画面.jpg | コントローラスキャン060927a.xls | コントローラスキャン060928.xls | コントローラスキャン060929.xls | コントローラスキャン中井さん案.doc | コントローラに関して_3.doc | コントローラに関して_3.doc 2.doc | コントローラに関して.doc | コントローラポート割り当てルール案.doc | コントローラポート割り当てルール案060906.doc | コントローラボタン比較.xls | コントローラ配布数.xls | コンプライアンス５～８年.pdf | コンプライアンスセミナー5～8年目出席者.xls | サウンド.txt | サムネールとバナーについて0720.doc | サンプル必要数（２００５年１０月１２日版）.xls | サンプル必要数（２００５年９月２２日版）.xls | シャープ岡田様　講演アジェンダ060119.doc | シャープ技術提案会.xls | シャープ技術提案会ご案内.pdf | ジャンプアルティメットスターズ_1W_061126.pdf | スクロールバーについて.txt | スターフォックス６４光過敏ビ%_1.xls | スペシャリスト職の説明.pdf | スマブラ検討.xls | セカンドパーティからの受注フロー.pdf | ソースリスト表紙.xls | ソフトウェア使用許諾条件.pdf | ソフト別研修会&全体説明会会スケジュール.xls | ソフト品質管理部からの要望051124.doc | ソフト品質管理部への要望0504その後.doc | ソフト品質管理部要望会議060523.doc | ソフト品質管理部要望聞き取り会議061121.doc | ソフト資料20060526.xls | ダイアログ仕様書v10.pdf | ダイアログ仕様書v10.ppt | ダイアログ仕様書v11.pdf | ダイアログ仕様書v12.pdf | ダイアログ仕様書v121.pdf | タイトル名20060727.xls | タイトル情報詳細.xls | チャンネル名称プレゼン資料.pdf | チャンネル名称プレゼン資料(2).pdf | ディスカッション結果.txt | デバッグ参加者.xls | トラップリスト(韓国翻訳用)_061005.xls | ニンテンドーWi-Fiコネクション_ファーストガイドDS0713.zip | ニンテンドーWi-Fiコネクション_ファーストガイドWii0713.zip | ニンテンドーWi-Fiコネクション_企画検討用ガイドラインWii1213.zip | ネーミングキーワード.xls | バーチャルコンソール オーバービュー060825.doc | バーチャルコンソールアプリケーションガイド.zip | バーチャルコンソールアプリケーションガイド20060721.pdf | ハード・ソフト比較表7～10.xls | バグリスト【ＶＣソフトチェック】_20060914.xls | バグリスト【ＶＣソフトチェック】_20060915.xls | バグリスト【ＶＣソフトチェック】_20060926.xls | バグリスト【ＶＣソフトチェック】_20061002.xls | バグリスト【ＶＣソフトチェック】_20061003.xls | バグリスト【ＶＣソフトチェック】_20061005.xls | バグリスト【ＶＣソフトチェック】_20061010.xls | バグリスト【ＶＣソフトチェック】_20061011.xls | バグリスト【ＶＣソフトチェック】_20061012.xls | バグリスト【ＶＣソフトチェック】_20061016.xls | バグリスト【ＶＣソフトチェック】_20061017.xls | バグリスト【ＶＣソフトチェック】_20061018.xls | バグリスト【ＶＣソフトチェック】_20061019.xls | バグリスト【ＶＣソフトチェック】_20061020.xls | バグリスト【ＶＣソフトチェック】_20061023.xls | バグリスト【ＶＣソフトチェック】_20061024.xls | バグリスト【ＶＣソフトチェック】_20061025.xls | バグリスト【ＶＣソフトチェック】_20061026.xls | バグリスト【ＶＣソフトチェック】_20061026a.xls | バグリスト【ＶＣソフトチェック】_20061027.xls | バグリスト【ＶＣソフトチェック】_20061030.xls | バグリスト【ＶＣソフトチェック】_20061031.xls | バグリスト【ＶＣソフトチェック】_20061101.xls | バグリスト【ＶＣソフトチェック】_20061102_2.xls | バグリスト【ＶＣソフトチェック】_20061102.xls | バグリスト【ＶＣソフトチェック】_20061106.xls | バグリスト【ＶＣソフトチェック】_20061107_返信.xls | バグリスト【ＶＣソフトチェック】_20061107.xls | バグリスト【ＶＣソフトチェック】_20061108.xls | バグリスト【ＶＣソフトチェック】_20061109.xls | バグリスト【ＶＣソフトチェック】_20061113.xls | バグリスト【ＶＣソフトチェック】_20061115.xls | バグリスト【ＶＣソフトチェック】_20061120.xls | バグリスト【ＶＣソフトチェック】_20061121.xls | バグリスト【ＶＣソフトチェック】_20061122.xls | バグリスト【ＶＣソフトチェック】_20061122返信.xls | バグリスト【ＶＣソフトチェック】_20061123.xls | バグリスト【ＶＣソフトチェック】_20061124.xls | バグリスト【ＶＣソフトチェック】_20061125.xls | バグリスト【ＶＣソフトチェック】_20061127.xls | バグリスト【ＶＣソフトチェック】_20061128.xls | バグリスト【ＶＣソフトチェック】_20061129.xls | バグリスト【ＶＣソフトチェック】_20061130.xls | バグリスト【ＶＣソフトチェック】_20061201.xls | バグリスト【ＶＣソフトチェック】_20061204_抜粋.xls | バグリスト【ＶＣソフトチェック】_20061204.xls | バグリスト【ＶＣソフトチェック】_20061205_返信.xls | バグリスト【ＶＣソフトチェック】_20061205.xls | バグリスト【ＶＣソフトチェック】_20061206.xls | バグリスト【ＶＣソフトチェック】_20061207_IS.xls | バグリスト【ＶＣソフトチェック】_20061207.xls | バグリスト【ＶＣソフトチェック】_20061208.xls | バグリスト【ＶＣソフトチェック】_20061212.xls | バグリスト【ＶＣソフトチェック】_20061213.xls | バグリスト【ＶＣソフトチェック】_20061214.xls | バグリスト【ＶＣソフトチェック】_20061215.xls | バグリスト【ＶＣソフトチェック】_20061219.xls | バグリスト【ＶＣソフトチェック】_20061220.xls | バグリスト【ＶＣソフトチェック】_20061221.xls | バグリスト【ＶＣソフトチェック】_開発記入20061104.xls | バグリスト【ＶＣソフトチェック】.xls | バグリスト【ＶＣソフトチェック】060913.xls | バグリスト【ＶＣソフトチェック】20060915.xls | バグリスト【ＶＣソフトチェック】20060921.xls | バグリスト【ＶＣソフトチェック】20060922.xls | バグリスト【ＶＣソフトチェック】20060928.xls | バグリスト【ＶＣマリオ64】20060927.xls | バグリスト060821.xls | バグリスト060821追記.xls | バグリスト20061026【ＶＣマリオ64】ＮＳＴ.xls | バグリスト20061027【ＶＣマリオ64】ＮＳＴ.xls | バグリスト20061030【ＶＣマリオ64】NST.xls | バグリスト20061108【VCマリオ6 1.xls | バグリスト20061114【VCマリオ６４】.xls | バックアップデータメモリマップ例.txt | バナーについて_060815.zip | ハングル語入力システムのフローチャート.doc | ハンタ－ズ Wifi 状況の件.eml | ひな型.xls | ファミコン-P.lzh | フィールドテスト勤怠.doc | フランクフルトオフィス拡張の提案（短縮版）_27Mar2006.ppt | プログラム問題3.zip | ポール君ToDo061006_2.txt | ポール君ToDo061006.txt | ポケモンDP応援リスト.xls | ポケモンダンジョンQ&A.doc | ポケモンプログラム改善のためのアドバイス.doc | ボタンアサイン原案.xls | マリオ６４光過敏ビデオ追加分_06.xls | マリオカート６４光過敏ビデオ_06.xls | マリオ操作一覧(韓国翻訳用)_061005.xls | マリパ８miiサンプル.jpg | メッセージローカライズ.xls | メニュー画面案_GENE.tga | メニュー画面案_GENE(2).tga | メニュー画面案_PC.tga | メニュー画面案_PC(2).tga | もっと脳_jp.txt | ライセンシータイトル.gif | ライセンシー確認済タイトル.xls | リモートアクセス案内・申請書.doc | リモコンの扱い.xls | リモコン操作不能検証.txt | リモコン操作名称.txt | レイアウト2006south.pdf | レヴォ本体機能会議.txt | レボリューション（NintendoWare）描画系機能確認-NW.txt | レボリューション（NintendoWare）描画系機能確認.txt | レボ本体搭載機能検討～第1回.pdf | ローカライズまとめ060825.xls | ローンチタイトル_リスト_20060414.xls | ローンチタイトル.xls | ワイドテレビの画面モードの調査.xls | 一次面接評価票(050707).xls | 上付き文字使用例.xls | 上司用career06(第5フ゜ロダクションG).atc | 上司用マニュアル2007年版.pdf | 上司用記入説明.pdf | 不具合報告 20060828.xls | 不具合報告 20060829.xls | 不具合報告 20060830.xls | 不具合報告 20060831.xls | 不具合報告 20060901.xls | 不具合報告 20060904.xls | 不具合報告 2006822～2006825.xls | 井上萌_TGS2006.doc | 京都RC運用管理について.pdf | 人員計画インタビュー内容.doc | 人材開発プロジェクト_ＧＭ各位.pdf | 人材開発プロジェクト_管理職各位_.pdf | 人材開発プロジェクトガイダンス..pdf | 今回評価のスケジュール.pdf | 任天ポーＳＴＥＰ２概算見積り.zip | 任天ポーサーバ環境設定.ppt | 任天堂タイトル2005.xls | 任天堂研修内容＆DPプログラム方針について-4版.doc | 任天堂研修内容＆DPプログラム方針について.doc | 任天堂社内ライブラリについて.doc | 企画検討用ガイドライン_060411.zip | 企画開発待ち受け案.txt | 企画開発本部.xls | 企画開発本部出席申込.xls | 企画開発部.xls | 企画開発部DSカンファレンス秋出席者.xls | 企画開発部会社説明会参加者１.pdf | 企画開発部会社説明会参加者２.pdf | 企画開発部会社説明会参加者３.pdf | 企画開発部出席申込.xls | 企画開発部第5ＰG.xls | 企開ポケモンDP応援リスト12.12ver.xls | 企開総開BT問答集20060320.pdf | 伊藤明日香_TGS2006.doc | 会社説明会　企画開発部.pdf | 似顔絵チャンネルNAND構造.xls | 似顔絵ライブラリオーバービュー.txt | 似顔絵ライブラリオーバービュー061215.txt | 似顔絵問題.txt | 作業項目一覧表(060127).lzh | 修正0829.xls | 光回線図面11.7.pdf | 光過敏_ゼルダオカリナ.pdf | 内部統制強化プロジェクト.pdf | 出席申込.xls | 出席者リスト.xls | 出席者リスト（企画開発部）.xls | 勤務時間.pdf | 参考情報.doc | 取扱_使用説明書_韓国語訳.doc | 古い日本語.doc | 古い日本語に対応していると思われる英語.doc | 各試作におけるHollywoodのバージョン.xls | 唇音チェック項目（061030）.doc | 唇音数字.xls | 唇音数字②.xls | 商標出願依頼者_届出手順（暫定版）.pdf | 商標権更新確認_2006.7.xls | 問題.txt | 問題文(センテンス).lzh | 回答１.txt | 回答２.txt | 回答３.txt | 国内VC発売スケジュール_061026.xls | 国内タイトル061116.xls | 国内更新問合せ20050801-20060731x.xls | 報_中村_東京ゲームショー2006050925.pdf | 報_内監「ゲームデータ取り扱い」に関する内部監査報告書_060921.pdf | 売り込み.pdf | 売込みがあったソフトウエアキーボードの内容.pdf | 契約社員（尹、061027）.xls | 契約社員（尹、061031）.xls | 契約社員（阿久根さん）.xls | 定性情報まとめ0500527.doc | 定性情報まとめ0500531.doc | 定性情報まとめ050621.doc | 定性情報まとめ050628.doc | 定性情報まとめ050712.doc | 定性情報まとめ050719.doc | 定性情報まとめ050726.doc | 定性情報まとめ050802.doc | 定性情報まとめ050809.doc | 定性情報まとめ050818.doc | 定性情報まとめ050823.doc | 定性情報まとめ050830.doc | 定性情報まとめ050906.doc | 定性情報まとめ050913.doc | 定性情報まとめ050920.doc | 定性情報まとめ051004.doc | 定性情報まとめ051012.doc | 定性情報まとめ051018.doc | 定性情報まとめ051025.doc | 定性情報まとめ051102.doc | 定性情報まとめ051108.doc | 定性情報まとめ051115.doc | 定性情報まとめ051124.doc | 定性情報まとめ051129.doc | 定性情報まとめ051206.doc | 定性情報まとめ051213.doc | 定性情報まとめ051220.doc | 定性情報まとめ051227.doc | 定性情報まとめ060111.doc | 定性情報まとめ060117.doc | 定性情報まとめ060124.doc | 定性情報まとめ060201.doc | 定性情報まとめ060207.doc | 定性情報まとめ060214.doc | 定性情報まとめ060303.doc | 定性情報まとめ060307.doc | 定性情報まとめ060314.doc | 定性情報まとめ060322.doc | 定性情報まとめ060404.doc | 定性情報まとめ060411.doc | 定性情報まとめ060418.doc | 定性情報まとめ060425.doc | 定性情報まとめ060508.doc | 定性情報まとめ060516.doc | 定性情報まとめ060523.doc | 定性情報まとめ060530.doc | 定性情報まとめ060606.doc | 定性情報まとめ060613.doc | 定性情報まとめ060620.doc | 定性情報まとめ060627.doc | 定期購読雑誌一覧061206.xls | 対象複合機.gif | 尾崎裕一_TGS2006.txt | 席配置.jpg | 常識力トレーニング_1W_061126.pdf | 常識力トレーニング_5W_061126.pdf | 常識力英語問題.xls | 年末年始措置.pdf | 当番表　2006.pdf | 当番表.pdf | 役職任免推薦書05.05.doc | 待ち受けモード説明資料060202.ppt | 待ち受けモード説明資料060206.ppt | 待ち受け機能.txt | 情開待ち受けの使い方プラン.xls | 情開総開BT問答集20060320.pdf | 承認申請プロセス.doc | 承認者_商標出願依頼承認手順（暫定版）.pdf | 技術系新人一次研修概要.doc | 技術系新人一次研修計画書.doc | 技術系新人二次研修概要.doc | 技術系新人研修計画書.doc | 採用担当者ミーティングメモ(情報系).doc | 携帯サイト説明資料.doc | 操作説明画面案_GENE.tga | 操作説明画面案_GENE(2).tga | 操作説明画面案_PC.tga | 操作説明画面案_PC(2).tga | 放置タイマーサンプルソース_00.txt | 数字発音.xls | 文字入力記録用紙.zip | 文字数えの件.doc | 文字数え問題文及び出題形式仕様ver1.0.xls | 文字数え問題文及び出題形式仕様ver1.0（境野編集）.xls | 文字色の意味.doc | 新しい日本語.pdf | 新しい日本語に対応させた英語.doc | 新不具合.mm | 新人パソコン講習日程と概要.xls | 新入社員要員申請書.doc | 昼食夜食について.pdf | 暫定フローチャート.pdf | 暫定フローチャート.vsd | 暫定版公開061128.zip | 最新版標準モデル韓国語翻訳用①（最新).xls | 最終版シュリンク版CPUの通信仕様.ppt | 未決定事項表0621.xls | 未決定事項表0703.xls | 未決定事項表0704.xls | 未決定事項表0704（コメント付き）.xls | 未決定事項表0707.xls | 未決定事項表0710.xls | 本体進捗管理表_060619.pdf | 東北大.jpg | 東横イン.gif | 案内_FAX用.doc | 案内状.pdf | 検収確認書ガイドライン.xls | 業務フロー060809.xls | 標準モデル韓国語翻訳用　金.xls | 標準モデル韓国語翻訳用（060929).xls | 標準モデル韓国語翻訳用（18.9.27.yun）.xls | 欧州でのTV事情.pdf 1.pdf | 残業１２月.pdf | 残業注意１０月.pdf | 残業注意１０月黄.pdf | 残業注意11月.pdf | 残業注意11月黄.pdf | 残業注意１１月黄.pdf | 残業注意１月.pdf | 残業注意２月.pdf | 残業注意２月黄.pdf | 残業注意４月黄.pdf | 残業注意５月（訂正）.pdf | 残業注意５月黄.pdf | 残業注意６月.pdf | 残業注意７月.pdf | 残業注意７月黄.pdf | 残業注意８月.pdf | 残業注意９月.pdf | 残業注意９月黄.pdf | 注意.txt | 海外版AGBポケモン文字コード.xls | 添付資料１.xls | 添付資料２.pdf | 準備段取り060821.pdf | 準備段取り060823.pdf | 準備段取り060825.pdf | 準備段取り060828.pdf | 照査・承認ルート.pdf | 特許第3668948号.pdf | 特開2000-122537.pdf | 理工情報二次面接まとめ.xls | 環境制作.txt | 申請書①組織変更.doc | 申請書②役職推薦.doc | 申請書③部内異動.doc | 画面イメージ20060818.doc | 着メロセカンドパーティ説明用手元資料.doc | 瞬間パズループ.txt | 研修ワークシート第2回目.xls | 研修ワークシート第４回目.xls | 硬度変更荷重測定.xls | 社長車座参加表.xls | 稟_総情開06-23060919.pdf | 稟_総開技06-31_060828.pdf | 第１期分VCソフト操作確認.lzh | 第1期開催日程表.pdf | 第2回報告会草稿07.ppt | 第５回GM研修ワークシート.xls | 第５回ワークシート参考資料.doc | 第６回ＧＭ研修ワークシート.xls | 管理表【ＶＣソフトチェック】_20061023.xls | 管理表【ＶＣソフトチェック】_20061125.xls | 管理表【ＶＣソフトチェック】_20061205.xls | 管理表【ＶＣソフトチェック】_20061206.xls | 管理表【ＶＣソフトチェック】_20061207.xls | 管理表【ＶＣソフトチェック】_20061208.xls | 管理表【ＶＣソフトチェック】_20061211.xls | 管理表【ＶＣソフトチェック】_20061213.xls | 管理表【ＶＣソフトチェック】_20061214_返信.xls | 管理表【ＶＣソフトチェック】_20061214.xls | 管理表【ＶＣソフトチェック】_20061215.xls | 管理表【ＶＣソフトチェック】_20061218.xls | 管理表【ＶＣソフトチェック】_20061219.xls | 管理表【ＶＣソフトチェック】_20061220.xls | 管理表【ＶＣソフトチェック】_20061221.xls | 簡易会話資料.zip | 経営会議上程.ppt | 経費発生予測フォーム（66下期）.xls | 経費発生予測フォーム（67上期）.xls | 経費発生予測フォーム（67下期）.xls | 総企開稟議の流れ060608.xls | 翻訳採点コメント.xls | 翻訳用.zip | 職務経歴_瀬井健太郎.xls | 能力評価シート.pdf | 能力評価シート（Ａ）のサンプル.pdf | 能力開発シート（Ｂ）の記入要項.pdf | 脳タイトル会議（1105）会議メモ_051107（江里）.doc | 脳トレ・えいご漬け統一用語(061108).xls | 脳トレ(韓）コメント.rtf | 脳トレ韓国版_認識モニタ_アンケート_監督者.doc | 脳トレ韓国版_認識モニタ_アンケート_被験者.doc | 脳トレ韓国版_認識モニタ手順.doc | 脳トレ韓国版_高齢者モニタ_アンケート_監督者.doc | 脳トレ韓国版_高齢者モニタ_アンケート_被験者.doc | 脳トレ韓国版_高齢者モニタ手順.doc | 脳トレ韓国版モニタ資料.zip | 脳トレ韓国語版タイトル候補.doc | 自社タイトル.GIF | 自販機リスト.xls | 若葉面談表2006.doc | 莉・蜑阪・繧・ｊ蜿悶ｊ繝ュ繧ー.txt | 衛生議事録1711.pdf | 衛生議事録1801.pdf | 衛生議事録1802.pdf | 表1-2の変種.doc | 製品技術部への応援異動.xls | 製造本部に対するアンケート用紙（2005年度）.doc | 複合回転囲碁.pdf | 計測データ20060328.txt | 記号.xls | 評価ガイダンスアンケート.doc | 評価ガイダンスアンケートより.pdf | 評価ガイダンスメモ.pdf | 評価ガイダンスメモ050915AM.doc | 評価ガイダンス資料.pdf | 評価ガイダンス連絡書.pdf | 評価シート表示内容一覧.xls | 評価制度Ｑ＆Ａ.pdf | 評価制度説明資料.pdf | 評価基準ガイドライン.pdf | 試験問題.zip | 説明.lzh | 説明会日程（企画開発部）.xls | 説明書.zip | 説明書チェック20061023.xls | 説明書チェック20061107.xls | 説明書チェック20061125.xls | 説明書チェック20061207.xls | 説明書チェック20061208.xls | 説明書チェック20061209.xls | 説明書チェック20061211.xls | 説明書チェック20061213.xls | 説明書チェック20061214.xls | 説明書チェック20061215.xls | 説明書チェック表【ＶＣソフトチェック】.xls | 説明書社外向け.zip | 議事_製技_製造本部　顧客目線評価のフィードバックフォーラムについての打合せ_050606.pdf | 議事録_2005年10月度SPD_GM会議.doc | 議事録_2005年11月度SPD_GM会議.doc | 議事録_2005年12月度SPD_GM会議.doc | 議事録_2005年6月度SPD_GM会議.doc | 議事録_2005年7月度SPD_GM会議.doc | 議事録_2005年8月度SPD_GM会議.doc | 議事録_2005年9月度SPD_GM会議.doc | 議事録_2006年10月度SPD_GM会議.pdf | 議事録_2006年11月度SPD_GM会議.pdf | 議事録_2006年12月SPD_GM会議.pdf | 議事録_2006年1月度SPD_GM会議.doc | 議事録_2006年2月度SPD_GM会議.doc | 議事録_2006年3月度SPD_GM会議.doc | 議事録_2006年4月度SPD_GM会議.doc | 議事録_2006年5月度SPD_GM会議.doc | 議事録_2006年6月度SPD_GM会議.doc | 議事録_2006年7月度SPD_GM会議.pdf | 議事録_2006年8月度SPD_GM会議.pdf | 議事録_2006年9月度SPD_GM会議.pdf | 議事録_ツール_20060531.html | 議事録_リーダ_20050517.txt | 議事録_リーダ_20050524.txt | 議事録_リーダ_20050531.txt | 議事録_リーダ_20050607.txt | 議事録_リーダ_20050614.txt | 議事録_リーダ_20050621.txt | 議事録_リーダ_20050628.txt | 議事録_リーダ_20050705.txt | 議事録_リーダ_20050712.txt | 議事録_リーダ_20050719.txt | 議事録_リーダ_20050726.txt | 議事録_リーダ_20050802.txt | 議事録_リーダ_20050809.txt | 議事録_リーダ_20050823.txt | 議事録_リーダ_20050830.txt | 議事録_リーダ_20050906.txt | 議事録_リーダ_20050913.txt | 議事録_リーダ_20050920.txt | 議事録_リーダ_20050927.txt | 議事録_リーダ_20051004.txt | 議事録_リーダ_20051011.txt | 議事録_リーダ_20051018.txt | 議事録_リーダ_20051025.txt | 議事録_リーダ_20051101.txt | 議事録_リーダ_20051108.txt | 議事録_リーダ_20051115.txt | 議事録_リーダ_20051122.txt | 議事録_リーダ_20051129.txt | 議事録_リーダ_20051206.txt | 議事録_リーダ_20051213.txt | 議事録_リーダ_20051220.txt | 議事録_リーダ_20051227.txt | 議事録_リーダ_20060110.txt | 議事録_リーダ_20060117.txt | 議事録_リーダ_20060124.txt | 議事録_リーダ_20060131.txt | 議事録_リーダ_20060207.txt | 議事録_リーダ_20060214.txt | 議事録_リーダ_20060221.txt | 議事録_リーダ_20060228.txt | 議事録_リーダ_20060314.txt | 議事録_リーダ_20060322.txt | 議事録_リーダ_20060328.txt | 議事録_リーダ_20060404.txt | 議事録_リーダ_20060411.txt | 議事録_リーダ_20060418.txt | 議事録_リーダ_20060425.txt | 議事録_リーダ_20060502.txt | 議事録_リーダ_20060509.txt | 議事録_リーダ_20060516.txt | 議事録_リーダ_20060523.txt | 議事録_リーダ_20060530.txt | 議事録_リーダ_20060606.txt | 議事録_リーダ_20060613.txt | 議事録_リーダ_20060620.txt | 議事録_リーダ_20060627.txt | 議事録_リーダ_20060704.txt | 議事録_リーダ_20060711.txt | 議事録_リーダ_20060718.txt | 議事録_リーダ_20060725.txt | 議事録_リーダ_20060801.txt | 議事録_リーダ_20060808.txt | 議事録_リーダ_20060822.txt | 議事録_リーダ_20060829.txt | 議事録_リーダ_20060905.txt | 議事録_リーダ_20060912.txt | 議事録_リーダ_20060919.txt | 議事録_リーダ_20060926.txt | 議事録_リーダ_20061003.txt | 議事録_リーダ_20061010.txt | 議事録_リーダ_20061017.txt | 議事録_リーダ_20061024.txt | 議事録_リーダ_20061031.txt | 議事録_リーダ_20061107.txt | 議事録_リーダ_20061114.txt | 議事録_リーダ_20061121.txt | 議事録_リーダ_20061128.txt | 議事録_リーダ_20061205.txt | 議事録：要望聞き取り会議051124.doc | 議事録20060710-Opera開発体制.txt | 議事録20060718-Operaコンポーネント.txt | 議事録20060721-ブラウザコンポーネントアクセス制限.txt | 議事録20060725-Opera電話会議.txt | 議事録RVL技術共有20060131.doc | 販売推移051030(5P）.xls | 資料（ソフト日程05_05_31).pdf | 資料（ソフト日程05_07_14).pdf | 資料（ソフト日程05_07_15).pdf | 資料（ソフト日程050822）.pdf | 資料（ソフト日程050823）.pdf | 資料（ソフト日程050920）.pdf | 資料（ソフト日程051020）.pdf | 資料（ソフト日程051118）.pdf | 資料（ソフト日程051221）.pdf | 資料（ソフト日程060203）.pdf | 資料（ソフト日程060307）.pdf | 資料（ソフト日程060427）.pdf | 資料（ソフト日程060606）.pdf | 資料（ソフト日程060705）.pdf | 資料（ソフト日程060811）.pdf | 資料（ソフト日程061006）.pdf | 資料（ソフト日程061208）.pdf | 資料20060720-ブラウザコンポーネントアクセス制限.txt | 逆アセンブル.txt | 通信て_やりたいこと050721.xls | 通訳研修連絡.pdf | 連_システム_退職者情報削除申請の件_050906.pdf | 連_人事_年末・年始休日労働の特別措置_061218.pdf | 連_企画「Ｗｉｉプレビュー」実施に関して_060905.pdf | 連_企画_『Ｎｉｎｔｅｎｄｏ　Ｗｏｒｌｄ　2006　Ｗｉｉ体験会』実施に関して_061018.pdf | 連_営管_（株）ポケモン　イベント用部材　手配依頼の件_060404.pdf | 連_営管_（株）ポケモン　イベント用部材　手配依頼の件_061025.pdf | 連_営管_（株）ポケモン　イベント用部材　手配依頼の件（２）061027.pdf | 連_営管「（株）ポケモン　イベ???ト用部材　手??????頼????????????絡書訂正の件_061102.pdf | 連_営管_「マナフィ」配布用ＡＧＢカートリッジ手配依頼の件_061102.pdf | 連_法務_「Ｗｉｉリモコン」及び「ストラップ」に関する情報の保持のお願い_061211.pdf | 連_知財_新規米国特許侵害訴訟の件_060803.pdf | 連_知財_米国特許訴訟の予想対象製品に関する情報の保持のお願い_061211.pdf | 連_総務部_下請取引の適正化について_061214.pdf | 連_総務部_下請取引の適正化について051216.pdf | 連_製造_製造部　総合サポートＧからの情報提供依頼_050517.pdf | 連_開技_ＡＧＢソフト「ビットジェネレーションシリーズ」カートリッジハウジングの色について_060605.pdf | 週間マクロレポート060719.doc | 週間マクロレポート060727.doc | 週間マクロレポート060803.doc | 週間マクロレポート060810.doc | 週間マクロレポート060825.doc | 週間マクロレポート060831.doc | 週間マクロレポート060907.doc | 週間マクロレポート060915.doc | 週間マクロレポート060921.doc | 週間マクロレポート060926.doc | 週間マクロレポート061003.doc | 週間マクロレポート061013.doc | 週間マクロレポート061017.doc | 週間マクロレポート061024.doc | 週間マクロレポート061031.doc | 週間マクロレポート061110.doc | 週間マクロレポート061116.doc | 週間マクロレポート061124.doc | 週間マクロレポート061201.doc | 週間マクロレポート061201.pdf | 週間マクロレポート061215.pdf | 進行表(管理職).pdf | 部下のメンタルケア相談のご案内（Ｈ・Ｆ）.pdf | 部門ごとの評価項目（2005年3月）.doc | 部門ごとの評価項目（2005年9月）.doc | 部門ごとの評価項目（2006年3月）.doc | 配布予定.xls | 金～StaffCredit061106.xls | 金～StaffCredit061107.xls | 金コピー契約社員061031.xls | 開発ツールスケジュール12-05用.xls | 開発ツールスケジュール２００５年９月版.xls | 阿部友一_TGS2006.doc | 電子取り説【日本】最新バージョン一覧20061116.xls | 電子取り説【日本】最新バージョン一覧20061117.xls | 電子取り説【日本】最新バージョン一覧20061120.xls | 電子取り説【欧州】最新バージョン一覧20061121.xls | 電磁誘導方式TP060118.ppt | 電話会議議事録.txt | 面接評価シート.xls | 韓国向販売計画案1201改訂.xls | 韓国版ＤＳ用語集_文字色の意味0919.doc | 音声認識ライブラリ関連の止まりバグについて.txtTransmission log (/mail.nintendo.co.jp/送信ログ) 送信ログ This folder contains… File Name Extension Description 送信ログ200610_01 .txt   送信ログ200610_02 .txt   送信ログ200610_03 .txt   送信ログ200610_04 .txt   送信ログ200611 .txt   送信ログ200611_01 .txt   送信ログ200611_02 .txt   送信ログ200611_03 .txt   送信ログ200611_04 .txt   送信ログ200611_05 .txt   送信ログ200611_06 .txt   送信ログ200611_07 .txt   送信ログ200612 .txt   送信ログ200612_01 .txt   送信ログ200612_02 .txt   送信ログ200612_03 .txt   Sent Attachments (/mail.nintendo.co.jp/送信添付) 送信添付 This folder contains… File Name Extension Description _Block.pdf     ＜中村秀和＞2006.doc     051227-USG１・２カートリッジロットチェック結果NTRdata20051115USG1207.xls     1-20.18.29.apc     1-20.19.00.apc     1-20.31.40.apc     1-20.34.20.apc     1-20.35.19.apc     1-20.53.33.apc     1-21.06.49.apc     2005年10月度議事次第.txt     2005年8月度議事次第.txt     2006-11-15-Virtual Console(HBM) - EU.xls     2006年11月度議事次第.txt     2006年新入社員技術研修参加者一覧.xls     2006技術系新入社員研修スケジュール（確定）.xls     21968-YoshisIslandDS-FR_1.doc     3D研修課題.doc     ５月０１日分.txt     ５月０２日分.txt     ５月０８日分.txt     ５月０９日分.txt     ５月１０日分.txt     739村川　照貴.xls     ABC.pdf     AboutWXC.pdf     AGBソフト一覧.xls     Assistance to Ubisoft.txt     BackToolForNDEV.zip     BackToolForNDEV104.zip     BackToolForRVTR.zip     BTに関わるゲームリモコンの仕様.pdf     BTに関わるゲームリモコンの仕様.txt     BTに関わるゲームリモコンの仕様20060317.txt     bytecopy_core.s     bytecopy.c     bytecopy.h     Content_Licensing_Ser.pdf     Controller Messages_061102_NOE1.xls     Controller Messages_061103_NOE.xls     Controller Messages_061103_NOE1.xls     Controller Messages1025_NOE.xls     D-abcd.pdf     DebugQuickSave_Ver100_評価版_061129.doc     Demo20060328.zip     Demo20060330.zip     Demo20060406.zip     DesignStatement_Wi-FiConnection_A_20050123AsobiTaizenOnline_1.doc     DPfont060112.zip     DSすれ違い通信中継所プログラム運営050913.ppt     E3 2006 業務出張者一覧（5PG）.xls     E3 2006 研修出張者一覧（5PG）.xls     E3 2006 研修出張者一覧（企画開発部）a.xls     E3 2006 研修出張者一覧（部署名）.xls     E3 2006出張 研修派遣本人希望申込・上司推薦書（木梨玲）.doc     E3 2006出張 研修派遣本人希望申込・上司推薦書（氏名）.doc     E3 EVENT.xls     E3_20060407.zip     E3_20060410b.zip     E3_20060417.zip     E3_20060421.zip     E3Demo_NESSMfiltertest.zip     E3Demo_NESSMfiltertest2.zip     E3Demo_SFC20060406.zip     E3Demo_SNSMW20060411.zip     E3Demo_SNSMW20060411a.zip     E3Demo_SNSMW20060412.zip     E3Demo_SNSMW20060417.zip     E3Demo_SNSMW20060418.zip     E3Demo_SNSMW20060421a.zip     E3Demo_SNSMWfiltertest.zip     E3Demo_SNSMWfiltertest2.zip     E3Demo_SNSMWfiltertest3.zip     E3showversion.pdf     E3ショーバージョンガイドライン_02.txt     E3ショーバージョンガイドライン_03.txt     E3ショーバージョンガイドライン_060322.txt     E3用解説.txt     Ｅ３研修出張報告.doc     Ｅ３研修出張報告概要.doc     effectInterfaceDocs.zip     EMAIL_BUG_REPORT_FORM.TXT     flow_diskupdate_sys1.pdf     font_system.bmp     font_test.lzh     ＧＭ研修アンケート.doc     GM研修シート(1).xls     HBM.jpg     Hollywood修正履歴.xls     homeButtonSample.ddf     HOMEメニューフレームワークAPI.txt     How to make a disc needed to import a wad file.txt     HowtoUseMemory.txt     HowtoUseMemory20060221.txt     HttpTest.zip     InstalledVersionCheck.xls     JAAJ_dbg_061017.ddf     Japanese Introduction v1.7.ppt     KPAD_051011.lzh     KPAD_051014.lzh     KPAD_051020.lzh     KPADSample_051025.lzh     KPADSample_051027.lzh     KPADSample_051028.lzh     LED-makiwari.xls     LED-tennnis.xls     Licensing_Server_Oper.pdf     log.bmp     Makefile     MessageEditor.zip     MiddlewareGuideline_for_Wii_060525.zip     motto_no-19.11.17.apc     motto_no-19.14.58.apc     motto_no-19.19.43.apc     motto_no-19.22.17.apc     N64_E3.zip     NAND Application Development Kit JP.doc     NAND Application Development Kit.doc     NAND Application Development May 29 2006.doc     NANDアプリの基礎知識.ppt     NAND構造2006-08-26.xls     NDEV生産.xls     nintendo_logo_e3_2006.zip     NitroSDK-WXC-050922.zip     NNGC基本日程表060418.xls     NOAからのメール原文.txt     NOE_Localization_26Oct06.xls     NOE用ソフト開発状況0611.xls     ＮＯＫ業務委託連絡書（企画開発）.doc     ＮＯＫ業務委託連絡書（環境制作）.doc     NTRMEM103.EXE     NW説明員・企画開発部.xls     OnAccessScanLog.txt     Online RCF Reporting _ Results from 11_18_2006 to 12_1_2006.eml     Online RCF Reporting _ Results from 12_1_2006 to 12_7_2006.eml     opera.zip     ot_kpad.h     PcmCache.txt     Pegi Ratings_update_September_25th_2006.xls     PG1_wii.xls     PG2_wii.xls     PG3_wii.xls     PG4_wii.xls     poke_font_b.zip     poke-doc.zip     PokeFontTest.zip     PokemonDP_schedule_20061109.xls     pruefergebnisse_1.xls     Qestion from Ubisoft.doc     rakubiki-12.20.03.apc     rakubiki-12.21.30.apc     rakubiki-12.24.13.apc     rakubiki-12.25.56.apc     rakubiki-13.26.10.apc     rakubiki.txt     Readme_en.txt     Readme_jp_Ver06.txt     Readme_jp.txt     ReadmeENG.txt     ReadmeJP.txt     REVOLUTIONネットワークサポートページ.htm     REVネットワーク開発の進め方(060206).ppt     REVネットワーク開発の進め方(060207).zip     REV必要作業一覧060417.xls     REV必要作業一覧表(060124 田原).xls     REV必要作業一覧表(060124).xls     REV必要作業一覧表(機能別)060207-1.xls     REV必要作業一覧表(環境制作G060126).xls     REV必要作業一覧表(部署別)060203.xls     REV必要作業一覧表(部署別)060207_3.xls     REV必要作業一覧表(高橋修正版）)060207_3.xls     REV必要作業一覧表060131-1.xls     REV必要作業一覧表060201_3.xls     Rimg9086.jpg     RVL_Banner_Gudeline_060720.zip     RVL_KPAD_SDK20051122alpha.zip     RVL_KPAD_SDK20051124rc1.zip     RVL_KPAD_SDK20051125.zip     RVL_KPAD_SDK20051128.zip     RVL_MasterEditorForNANDAPP-061106_vc.zip     RVL_NADK-060808.zip     rvl_titles.xls     rvl_titles20060126.xls     RVL_VC_CheckList061011.xls     RVL_VC_CheckList061028_jp.xls     RVL_VC_Guideline_jp_Ver103.doc     RVL_VC_Guideline_jp_Ver104.doc     RVL_VC_Guideline_jp_Ver105_061113.doc     RVL_VC_Guideline_jp_Ver105_評価版_061111.doc     RVL_VC_Guideline_jp_Ver105_評価版_061113.doc     RVL_VC_Guideline_jp_Ver105_評価版.doc     RVL_VC_Guideline_jp_Ver105_試作.doc     RVL_VC_Guideline_jp_Ver105_試作2.doc     RVL_VC_Guideline_jp_Ver105_試作3.doc     RVL_VC_Guideline_jp_Ver106_061118.doc     RVL_VC_Guideline_jp_Ver106_評価版_061114.doc     RVL_VC_Guideline_jp_Ver106_評価版_061115.doc     RVL_VC_Guideline_jp_Ver107_061206.doc     RVL_VC_Guideline_jp_Ver107_評価版_061118.doc     RVL_VC_Guideline_jp_Ver107_評価版_061130.doc     RVL_VC_Guideline_jp_Ver108_評価版_061211.doc     RVL_VC_Overview_jp_Ver102.doc     RVL_VC_Overview_jp_Ver103.doc     RVL_VC_Specifications_jp_Ver105.doc     RVL_VC_Specifications_jp_Ver106.doc     RVL_VC_Specifications_jp_Ver107.doc     RVL_VC_Specifications_jp_Ver108.doc     RVL_VC_Specifications_jp_Ver109.doc     RVL_VC_Specifications_jp_Ver110.doc     RVL_VC_Specifications_jp_Ver111.doc     RVL_VC_Specifications_jp_Ver112_061113.doc     RVL_VC_Specifications_jp_Ver112_評価版.doc     RVL_VC_Specifications_jp_Ver113_061118.doc     RVL_VC_Specifications_jp_Ver113_評価版_061113.doc     RVL_VCMV_SDK-1_4-061101 Patch1 Readme_en.txt     RVL_VCMV_SDK-1_4-061101 Patch1 Readme_jp.txt     RVL_VCMV_SDK-1_4-061101_patch1.zip     RVL_VCMV_SDK-1_4-061101_Patch2.zip     RVL_VCMV_SDK-1_4-061101_Patch3.zip     RVL_WPAD_SDK20051122alpha.zip     RVL_WPAD_SDK20051124rc1.zip     RVLプログラミング注意事項検討資料_060529.xls     RVL用語集 E3 Ver社内（VC担当者専用）用 01版.lzh     RVL用語集0603xx-E3用.xls     RVL開発環境.pdf     screenshot_001.bmp     showversion_RVL.doc     SMC-BTS概要.ppt     smp-toy.wad     SMPTE75%ColorBar_Spec.jpg     SMPTE75%ColorBar.jpg     software_arch.pdf     std_skin.zip     strap_060908.zip     swfdump.ZIP     System Menu DevelopmentJP.zip     System Update Procedure.zip     test_message.zip     test.zip     Thumbs.db     tosa_hal.xls     tosa_srd_id.xls     tsa_srd_id.xls     userManual.pdf     VC Launch Bug Log PAL 1127.xls     VC Launch Bug Log_1102_村川コメント.xls     VC TV Problems.xls     VC_KeyBind_List.zip     VC_Title_List061219IS.xls     vcmv.h     VCSchedule_0906.xls     VCスケジュール20060919.xls     VCスケジュール20060919A.xls     VCスケジュール20060921.xls     VCスケジュール20060922.xls     VCスケジュール20060927.xls     VCスケジュール20060929.xls     VCスケジュール20061101.xls     VCスケジュール20061107.xls     VCフロー_re0322.pdf     VCフロー_re0322(2).pdf     VC作業の流れ.xls     VC作業の流れ20060314.xls     VC作業の流れ20060327.xls     VC作業の流れ20060516.xls     VirtualConsolArchitect20060620.ppt     VirtualConsoleArchitect20060623a.ppt     VirtualConsoleArchitect20060626.ppt     VirtualConsoleArchitect20060628.ppt     VirtualConsoleArchitect20060629.ppt     VirtualConsoleArchitect20060630.ppt     VirtualConsoleArchitect20060703.ppt     VirtualConsoleArchitect20060704.ppt     VirtualConsoleArchitect20060705.ppt     VirtualConsoleArchitect20060706.ppt     VirtualConsoleArchitect20060710.ppt     VirtualConsoleArchitect20060711.ppt     VirtualConsoleArchitect20060712.ppt     VirtualConsoleArchitect20060713.ppt     VirtualConsoleArchitect20060714.zip     VirtualConsoleArchitect20060719.zip     VirtualConsoleArchitect20060721.zip     VirtualConsoleArchitect20060726.zip     VirtualConsoleArchitect20060727.zip     VirtualConsoleArchitect20060808.zip     VirtualConsoleArchitect20060810.zip     VirtualConsoleArchitect20060817.zip     Wi-Fi対応予定ソフト.txt     Wii_Conference_Guideline.jp.txt     Wii_Conference_Guideline.us.txt     Wii_Guidelines_v0.94.pdf     Wii_MessageList_0.10.xls     Wii_MessageList_0.14b_eur.xls     Wii_MessageList_0.14c_eur.xls     Wii_SystemMenu_schedule_2006_0921.pdf     Wii_SystemMenu_schedule.pdf     wii_titles20060626.xls     Wii_ワイド画面対応.xls     WiiConnect24オーバービュー_060526.doc     WiiPrevie構成v1.pdf     WiiSaveDataGuideline_jp_060919.pdf     WiiTitle_PG1.xls     WiiTitle_PG2.xls     WiiTitle_PG3.xls     WiiTitle_PG4.xls     Wiiカンファレンス0609バージョンガイドライン(任天堂タイトル向け)_Ver.0.8_060828.doc     Wiiカンファレンス0609バージョンガイドライン(任天堂ディスクタイトル向け)_Ver.0.9_060830.doc     Wiiショッピングch作業概要.xls     Wiiプログラミングガイドラインv0.91α.zip     Wiiプログラミングガイドラインv0.93α.zip     Wiiプログラミングガイドラインv0.94_.zip     Wiiプログラミングガイドラインv0.94.zip     Wiiプログラミングガイドラインv0.9α.zip     Wiiプログラミングガイドライン検討資料20060626.xls     Wiiリモコンガイドラインを考える会.ppt     Wiiリモコン実験.xls     Wii取説で気づいたこと.txt     Wii本体取説（準備編 改訂1）.pdf     Wii本体機能ROM出しスケジュール20061120.pdf     Wii本体機能ROM出しスケジュール20061120.xls     Workload.exe     Workload.zip     クレーム.pdf     ゲームリモコン＆クラシックコントローラボタン名称検討.xls     コントローラに関して_2.doc     コントローラに関して_3.doc     サムネールとバナーについて0720.doc     サンプル必要数（２００５年９月２２日版）.xls     シャープ技術提案会.xls     シャープ技術提案会ご案内.pdf     ソフト別研修会&全体説明会会スケジュール.xls     バーチャルコンソールアーキテクト.ppt     バーチャルコンソール用HBM_20061211.ppt     バーチャルコンソール用HBM.ppt     バグリスト【ＶＣソフトチェック】_20061107.xls     ハル研アカウント.xls     フランクフルトオフィス拡張の提案（短縮版）_27Mar2006.ppt     メッセージエディタを考える.txt     もっとスマートな翻訳を！.ppt     もっと脳_jp.txt     ランキングシステムの今後.ppt     リモコン操作不能検証.txt     リモコン操作名称.txt     レイアウト2006south.pdf     上司用career06(第5ﾌﾟﾛﾀﾞｸｼｮﾝG).atc     上司用career06(第5ﾌﾟﾛﾀﾞｸｼｮﾝG).xls     今回評価のスケジュール.pdf     任天堂研修内容＆DPプログラム方針について.doc     企画開発部.xls     光回線図面11.7.pdf     入社問題その２.txt     入社問題例.txt     参考情報.doc     各試作におけるHollywoodのバージョン.xls     問題.txt     契約社員.xls     契約社員.zip     契約社員（阿久根さん）.xls     待ち受けモード説明資料060206.ppt     情開総開BT問答集20060320.pdf     技術系新人一次研修計画書.doc     技術系新人二次研修概要.doc     技術系新人研修計画書.doc     新入社員要員申請書5PG.doc     最終版シュリンク版CPUの通信仕様.ppt     本日の議題_20061208.ppt     東芝３Ｄデモ.pdf     欧州でのTV事情.pdf 1.pdf     添付資料１.xls     添付資料２.pdf     瞬間パズループ.txt     研修ワークシート第2回目(村川).xls     研修ワークシート第４回目(村川).xls     硬度変更荷重測定.xls     第５回GM研修ワークシート(村川).xls     第６回ＧＭ研修ワークシート(村川).xls     経費発生予測フォーム（66下期） 第５ＰＧ.xls     経費発生予測フォーム（67上期）5PG.xls     脳タイトル会議（1105）会議メモ_051107（江里）.doc     若葉面談表2006.doc     評価ガイダンスアンケート.doc     試験問題.zip     議事録_リーダ_20051025.txt     議事録_リーダ_20051101.txt     議事録_リーダ_20051108.txt     議事録_リーダ_20051115.txt     議事録_リーダ_20051129.txt     議事録_リーダ_20051206.txt     議事録_リーダ_20051227.txt     議事録_リーダ_20060117.txt     議事録_リーダ_20060228.txt     議事録20060710-Opera開発体制.txt     議事録RVL技術共有20060131.doc     資料（ソフト日程05_05_31).pdf     資料（ソフト日程050822）.pdf     資料（ソフト日程050823）.pdf     資料（ソフト日程050920）.pdf     資料（ソフト日程051020）.pdf     資料（ソフト日程060427）.pdf     逆アセンブル.txt     通信て_やりたいこと050721.xls     通訳研修連絡.pdf     連_営管_（株）ポケモン　イベント用部材　手配依頼の件_060404.pdf     連_法務_「Ｗｉｉリモコン」及び「ストラップ」に関する情報の保持のお願い_061211.pdf     連_知財_米国特許訴訟の予想対象製品に関する情報の保持のお願い_061211.pdf     開発ツールスケジュール12-05用.xls     開発ツールスケジュール２００５年９月版.xls     電磁誘導方式TP060118.ppt     Sent Box (/mail.nintendo.co.jp/送信済み) 送信済み This folder contains… File Name Extension Description 送信済み200505 .txt Talk about interview candidates 送信済み200506 .txt Onboarding process for new hires and 3d training 送信済み200507 .txt   送信済み200508 .txt   送信済み200509 .txt   送信済み200510 .txt   送信済み200511 .txt   送信済み200512 .txt   送信済み200601 .txt   送信済み200602 .txt   送信済み200603 .txt   送信済み200604 .txt   送信済み200605 .txt   送信済み200606 .txt   送信済み200607 .txt   送信済み200608 .txt   送信済み200609 .txt   送信済み200610 .txt   送信済み200611 .txt   送信済み200612 .txt   ", "excerpt": "Introduction In 2020 and 2021 numerous secret files have been leaked from Nintendo thanks to Zammis Clark. Included in these files were the Corporate Emails inbox of an employee called Murakawa Tsushin. Note that this post is under construction, there are thousands of emails to go through, if you have...", "tags": ["leak"], "image": "/public/images/leaks/HidemaruMailLeak.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Home Alone 2 NES Source Code", "url": "/home-alone-2-nes-source-code", "content": "Home Alone 2 NES Source CodeThe Source Code for “Home Alone 2” was kindly released by Frank Cifaldi from GameHistoryorg (@frankcifald).Games on the same engineThe same Game Engine seems to have been used in at least 5 games developed by Imagineering for the Nintendo Entertainment System. Attack of the Killer Tomatoes Simpsons 2 (not sure if Bart vs. the Space Mutants or Bart vs. the World or *Bartman Meets Radioactive Ma*n) Barbie Swamp Thing Home Alone 2Source CodeThis section will analyze the source code for Home Alone 2 on the Nintendo Entertainment system.Full Source Code structure /HomeAlone2_NES_Src/ENG/ENGEQU.SRC /HomeAlone2_NES_Src/ENG/SCRPVAR.SRC /HomeAlone2_NES_Src/ENG/STATEQU.SRC /HomeAlone2_NES_Src/ENG/TEREQU.SRC /HomeAlone2_NES_Src/ENG/OBJCODE.SRC /HomeAlone2_NES_Src/ENG/FILEINFO.FI /HomeAlone2_NES_Src/ENG/PRNTCODE.GME /HomeAlone2_NES_Src/ENG/ENGPGF.SRC /HomeAlone2_NES_Src/ENG/BGMOD.SRC /HomeAlone2_NES_Src/ENG/SPMOVE.SRC /HomeAlone2_NES_Src/ENG/WLDCOM.SRC /HomeAlone2_NES_Src/ENG/STUFVAR.SRC /HomeAlone2_NES_Src/ENG/TERPGF.SRC /HomeAlone2_NES_Src/ENG/ENGVAR.SRC /HomeAlone2_NES_Src/ENG/SCRPEQU.SRC /HomeAlone2_NES_Src/ENG/STATVAR.SRC /HomeAlone2_NES_Src/ENG/COLLCODE.SRC /HomeAlone2_NES_Src/ENG/STUFPGF.SRC /HomeAlone2_NES_Src/ENG/WLDTABS.SRC /HomeAlone2_NES_Src/ENG/TERVAR.SRC /HomeAlone2_NES_Src/ENG/CAMCODE.SRC /HomeAlone2_NES_Src/ENG/STUFCODE.SRC /HomeAlone2_NES_Src/ENG/SCRPPGF.SRC /HomeAlone2_NES_Src/ENG/TERCODE.SRC /HomeAlone2_NES_Src/ENG/STUFEQU.SRC /HomeAlone2_NES_Src/ENG/HOTSCODE.SRC /HomeAlone2_NES_Src/ENG/COLLVAR.SRC /HomeAlone2_NES_Src/ENG/STTCOD.SRC /HomeAlone2_NES_Src/ENG/WLDPGF.SRC /HomeAlone2_NES_Src/ENG/STTVAR.SRC /HomeAlone2_NES_Src/ENG/HOTSVAR.SRC /HomeAlone2_NES_Src/ENG/COLLEQU.SRC /HomeAlone2_NES_Src/ENG/WLDVAR.SRC /HomeAlone2_NES_Src/ENG/CAMVAR.SRC /HomeAlone2_NES_Src/ENG/BGENGINE.SRC /HomeAlone2_NES_Src/ENG/ENGCODE.SRC /HomeAlone2_NES_Src/ENG/STTPGF.SRC /HomeAlone2_NES_Src/ENG/HOTSPGF.SRC /HomeAlone2_NES_Src/ENG/SCRPCODE.SRC /HomeAlone2_NES_Src/ENG/STATCODE.SRC /HomeAlone2_NES_Src/ENG/COLLPGF.SRC /HomeAlone2_NES_Src/ENG/STTEQU.SRC /HomeAlone2_NES_Src/ENG/HOTSEQU.SRC /HomeAlone2_NES_Src/ENG/PRNTNRAM.GME /HomeAlone2_NES_Src/ENG/PRNTDEFS.GME /HomeAlone2_NES_Src/ENG/PRNTZRAM.GME /HomeAlone2_NES_Src/DEVDOC /HomeAlone2_NES_Src/DEVDOC/FILEINFO.FI /HomeAlone2_NES_Src/DEVDOC/SCRPDOC.DOC /HomeAlone2_NES_Src/DEVDOC/TEMPLATE /HomeAlone2_NES_Src/DEVDOC/NEWNES.DOC /HomeAlone2_NES_Src/DEVDOC/INSTALL.DOC /HomeAlone2_NES_Src/DEVDOC/ADDING.DOC /HomeAlone2_NES_Src/LL3 /HomeAlone2_NES_Src/LL3/CLEAN.BAT /HomeAlone2_NES_Src/LL3/FILEINFO.FI /HomeAlone2_NES_Src/LL3/GR /HomeAlone2_NES_Src/LL3/GR/LL3SPR2.LBM /HomeAlone2_NES_Src/LL3/GR/LL3SPR1.LBM /HomeAlone2_NES_Src/LL3/GR/FILEINFO.FI /HomeAlone2_NES_Src/LL3/GR/GR.MAK /HomeAlone2_NES_Src/LL3/SETDIR.BAT /HomeAlone2_NES_Src/LL3/DLG.BAT /HomeAlone2_NES_Src/LL3/DLC.BAT /HomeAlone2_NES_Src/LL3/MP30.SRC /HomeAlone2_NES_Src/LL3/BASE.ERR /HomeAlone2_NES_Src/LL3/WLDATA3.A65 /HomeAlone2_NES_Src/LL3/ST3.SRC /HomeAlone2_NES_Src/LL3/LL3SEQS.SRC /HomeAlone2_NES_Src/LL3/HT3.SRC /HomeAlone2_NES_Src/LL3/BG /HomeAlone2_NES_Src/LL3/BG/C21.LBM /HomeAlone2_NES_Src/LL3/BG/C20.LBM /HomeAlone2_NES_Src/LL3/BG/C19A.LBM /HomeAlone2_NES_Src/LL3/BG/C22.LBM /HomeAlone2_NES_Src/LL3/BG/C23.LBM /HomeAlone2_NES_Src/LL3/BG/BG.MAK /HomeAlone2_NES_Src/LL3/BG/C8.LBM /HomeAlone2_NES_Src/LL3/BG/C9.LBM /HomeAlone2_NES_Src/LL3/BG/C3P1P1.WLD /HomeAlone2_NES_Src/LL3/BG/C18.LBM /HomeAlone2_NES_Src/LL3/BG/C19.LBM /HomeAlone2_NES_Src/LL3/BG/DP_PREFS /HomeAlone2_NES_Src/LL3/BG/WALL6.LBM /HomeAlone2_NES_Src/LL3/BG/WALL7.LBM /HomeAlone2_NES_Src/LL3/BG/ERR /HomeAlone2_NES_Src/LL3/BG/WALL5.LBM /HomeAlone2_NES_Src/LL3/BG/WALL4.LBM /HomeAlone2_NES_Src/LL3/BG/BP2.LBM /HomeAlone2_NES_Src/LL3/BG/WALL1.LBM /HomeAlone2_NES_Src/LL3/BG/WALL3.LBM /HomeAlone2_NES_Src/LL3/BG/WALL2.LBM /HomeAlone2_NES_Src/LL3/BG/WALLEND.LBM /HomeAlone2_NES_Src/LL3/BG/C4_OLD.LBM /HomeAlone2_NES_Src/LL3/BG/NEWC18.LBM /HomeAlone2_NES_Src/LL3/BG/WALL9.LBM /HomeAlone2_NES_Src/LL3/BG/WALL8.LBM /HomeAlone2_NES_Src/LL3/BG/C7.LBM /HomeAlone2_NES_Src/LL3/BG/C14.LBM /HomeAlone2_NES_Src/LL3/BG/C15.LBM /HomeAlone2_NES_Src/LL3/BG/C6.LBM /HomeAlone2_NES_Src/LL3/BG/C4.LBM /HomeAlone2_NES_Src/LL3/BG/C17.LBM /HomeAlone2_NES_Src/LL3/BG/C16.LBM /HomeAlone2_NES_Src/LL3/BG/C5.LBM /HomeAlone2_NES_Src/LL3/BG/WALL11.LBM /HomeAlone2_NES_Src/LL3/BG/C1.LBM /HomeAlone2_NES_Src/LL3/BG/C12.LBM /HomeAlone2_NES_Src/LL3/BG/C13.LBM /HomeAlone2_NES_Src/LL3/BG/WALL10.LBM /HomeAlone2_NES_Src/LL3/BG/WALL12.LBM /HomeAlone2_NES_Src/LL3/BG/C2.LBM /HomeAlone2_NES_Src/LL3/BG/C11.LBM /HomeAlone2_NES_Src/LL3/BG/C10.LBM /HomeAlone2_NES_Src/LL3/BG/C3.LBM /HomeAlone2_NES_Src/LL3/BG/WALL13.LBM /HomeAlone2_NES_Src/LL3/DLALL.BAT /HomeAlone2_NES_Src/LL3/BGDATA3.SRC /HomeAlone2_NES_Src/LL3/SF3.SRC /HomeAlone2_NES_Src/LL3/DIRID.SRC /HomeAlone2_NES_Src/LL3/SS3.SRC /HomeAlone2_NES_Src/LL3/LL3.A65 /HomeAlone2_NES_Src/LL3/LL3COD.SRC /HomeAlone2_NES_Src/LL4 /HomeAlone2_NES_Src/LL4/CLEAN.BAT /HomeAlone2_NES_Src/LL4/FILEINFO.FI /HomeAlone2_NES_Src/LL4/LL4SEQS.SRC /HomeAlone2_NES_Src/LL4/LL4COD.SRC /HomeAlone2_NES_Src/LL4/GR /HomeAlone2_NES_Src/LL4/GR/L4W0.NLD /HomeAlone2_NES_Src/LL4/GR/FILEINFO.FI /HomeAlone2_NES_Src/LL4/GR/DP_PREFS /HomeAlone2_NES_Src/LL4/GR/LL4SPR1.LBM /HomeAlone2_NES_Src/LL4/GR/LL4SPR2.LBM /HomeAlone2_NES_Src/LL4/GR/GR.MAK /HomeAlone2_NES_Src/LL4/GR/PICKUPS.LBM /HomeAlone2_NES_Src/LL4/GR/ENEMY1.LBM /HomeAlone2_NES_Src/LL4/SETDIR.BAT /HomeAlone2_NES_Src/LL4/DLG.BAT /HomeAlone2_NES_Src/LL4/DLC.BAT /HomeAlone2_NES_Src/LL4/SETDIR.CEW /HomeAlone2_NES_Src/LL4/HT4.SRC /HomeAlone2_NES_Src/LL4/ST4.SRC /HomeAlone2_NES_Src/LL4/WLDATA4.A65 /HomeAlone2_NES_Src/LL4/BG /HomeAlone2_NES_Src/LL4/BG/TOWN8.LBM /HomeAlone2_NES_Src/LL4/BG/TOWN9.LBM /HomeAlone2_NES_Src/LL4/BG/PIC.NLD /HomeAlone2_NES_Src/LL4/BG/BG.MAK /HomeAlone2_NES_Src/LL4/BG/FILEINFO.FI /HomeAlone2_NES_Src/LL4/BG/DP_PREFS /HomeAlone2_NES_Src/LL4/BG/PIC1A.WLD /HomeAlone2_NES_Src/LL4/BG/ERR /HomeAlone2_NES_Src/LL4/BG/C5A.WLD /HomeAlone2_NES_Src/LL4/BG/C3_C4.WLD /HomeAlone2_NES_Src/LL4/BG/PIC1.NLD /HomeAlone2_NES_Src/LL4/BG/TOWN10.LBM /HomeAlone2_NES_Src/LL4/BG/BG_3.MAK /HomeAlone2_NES_Src/LL4/BG/PIC1.WLD /HomeAlone2_NES_Src/LL4/BG/C4P1P1.WLD /HomeAlone2_NES_Src/LL4/BG/TOWN1.LBM /HomeAlone2_NES_Src/LL4/BG/TH1.LBM /HomeAlone2_NES_Src/LL4/BG/TOWN2.LBM /HomeAlone2_NES_Src/LL4/BG/TH2.LBM /HomeAlone2_NES_Src/LL4/BG/TH3.LBM /HomeAlone2_NES_Src/LL4/BG/TOWN3.LBM /HomeAlone2_NES_Src/LL4/BG/TOWN7.LBM /HomeAlone2_NES_Src/LL4/BG/PIC.WLD /HomeAlone2_NES_Src/LL4/BG/TH6.LBM /HomeAlone2_NES_Src/LL4/BG/TOWN6.LBM /HomeAlone2_NES_Src/LL4/BG/L4W0.WLD /HomeAlone2_NES_Src/LL4/BG/TOWN4.LBM /HomeAlone2_NES_Src/LL4/BG/TH4.LBM /HomeAlone2_NES_Src/LL4/BG/TH5.LBM /HomeAlone2_NES_Src/LL4/BG/TOWN5.LBM /HomeAlone2_NES_Src/LL4/DLALL.BAT /HomeAlone2_NES_Src/LL4/LL4.A65 /HomeAlone2_NES_Src/LL4/DIRID.SRC /HomeAlone2_NES_Src/LL4/BGDATA4.SRC /HomeAlone2_NES_Src/LL4/MP40.SRC /HomeAlone2_NES_Src/LL4/SS4.SRC /HomeAlone2_NES_Src/LL4/SF4.SRC /HomeAlone2_NES_Src/TIMECLCK /HomeAlone2_NES_Src/LL2 /HomeAlone2_NES_Src/LL2/CLEAN.BAT /HomeAlone2_NES_Src/LL2/FILEINFO.FI /HomeAlone2_NES_Src/LL2/GR /HomeAlone2_NES_Src/LL2/GR/LL2SPR4.LBM /HomeAlone2_NES_Src/LL2/GR/FILEINFO.FI /HomeAlone2_NES_Src/LL2/GR/LL2SPR1.LBM /HomeAlone2_NES_Src/LL2/GR/LL2SPR2.LBM /HomeAlone2_NES_Src/LL2/GR/LL2SPR3.LBM /HomeAlone2_NES_Src/LL2/GR/DP_PREFS /HomeAlone2NES_Src/LL2/GR/_BACKUP.LBM /HomeAlone2_NES_Src/LL2/GR/GR.MAK /HomeAlone2_NES_Src/LL2/GR/BU /HomeAlone2_NES_Src/LL2/GR/BU/LL2COM.SPR /HomeAlone2_NES_Src/LL2/DP_PREFS /HomeAlone2_NES_Src/LL2/SETDIR.BAT /HomeAlone2_NES_Src/LL2/DLG.BAT /HomeAlone2_NES_Src/LL2/LL2COD.SRC /HomeAlone2_NES_Src/LL2/DLC.BAT /HomeAlone2_NES_Src/LL2/LL2SEQS.SRC /HomeAlone2_NES_Src/LL2/WLDATA2.A65 /HomeAlone2_NES_Src/LL2/MP20.SRC /HomeAlone2_NES_Src/LL2/BG /HomeAlone2_NES_Src/LL2/BG/BARTMAN.LBM /HomeAlone2_NES_Src/LL2/BG/C2P1P2.WLD /HomeAlone2_NES_Src/LL2/BG/C2.DOC /HomeAlone2_NES_Src/LL2/BG/C2P1P1.WLD /HomeAlone2_NES_Src/LL2/BG/BG.MAK /HomeAlone2_NES_Src/LL2/BG/FILEINFO.FI /HomeAlone2_NES_Src/LL2/BG/DP_PREFS /HomeAlone2_NES_Src/LL2/BG/BADD.LBM /HomeAlone2_NES_Src/LL2/BG/BAD2.LBM /HomeAlone2_NES_Src/LL2/BG/BAD3.LBM /HomeAlone2_NES_Src/LL2/BG/BADE.LBM /HomeAlone2_NES_Src/LL2/BG/ERR /HomeAlone2_NES_Src/LL2/BG/MK.BAT /HomeAlone2_NES_Src/LL2/BG/BAD1.LBM /HomeAlone2_NES_Src/LL2/BG/BADF.LBM /HomeAlone2_NES_Src/LL2/BG/BLANK.LBM /HomeAlone2_NES_Src/LL2/BG/BAD4.LBM /HomeAlone2_NES_Src/LL2/BG/BADB.LBM /HomeAlone2_NES_Src/LL2/BG/BADC.LBM /HomeAlone2_NES_Src/LL2/BG/BAD5.LBM /HomeAlone2_NES_Src/LL2/BG/ALPHA.LBM /HomeAlone2_NES_Src/LL2/BG/BADA.GRP /HomeAlone2_NES_Src/LL2/BG/BAD7.LBM /HomeAlone2_NES_Src/LL2/BG/BADA.LBM /HomeAlone2_NES_Src/LL2/BG/BAD6.LBM /HomeAlone2_NES_Src/LL2/BG/TREE.LBM /HomeAlone2_NES_Src/LL2/BG/BAD8.LBM /HomeAlone2_NES_Src/LL2/BG/BAD9.LBM /HomeAlone2NES_Src/LL2/BG/_BACKUP.LBM /HomeAlone2_NES_Src/LL2/BG/BLANK1.LBM /HomeAlone2_NES_Src/LL2/BG/BLANK2.LBM /HomeAlone2_NES_Src/LL2/BG/BU /HomeAlone2_NES_Src/LL2/BG/BU/BG.MAK /HomeAlone2_NES_Src/LL2/BG/TREE2.LBM /HomeAlone2_NES_Src/LL2/BG/TREE3.LBM /HomeAlone2_NES_Src/LL2/BG/BAD13.LBM /HomeAlone2_NES_Src/LL2/BG/BAD12.LBM /HomeAlone2_NES_Src/LL2/BG/BAD10.LBM /HomeAlone2_NES_Src/LL2/BG/BAD11.LBM /HomeAlone2_NES_Src/LL2/DLALL.BAT /HomeAlone2_NES_Src/LL2/HT2.SRC /HomeAlone2_NES_Src/LL2/ST2.SRC /HomeAlone2_NES_Src/LL2/BGDATA2.SRC /HomeAlone2_NES_Src/LL2/JJ /HomeAlone2_NES_Src/LL2/SS2.SRC /HomeAlone2_NES_Src/LL2/DIRID.SRC /HomeAlone2_NES_Src/LL2/SF2.SRC /HomeAlone2_NES_Src/LL2/LL2.A65 /HomeAlone2_NES_Src/ERR /HomeAlone2_NES_Src/TREEINFO.NCD /HomeAlone2_NES_Src/LL0 /HomeAlone2_NES_Src/LL0/OPBK /HomeAlone2_NES_Src/LL0/OPENING.SRC /HomeAlone2_NES_Src/LL0/ZIPLL0.BAT /HomeAlone2_NES_Src/LL0/E1.SRC /HomeAlone2_NES_Src/LL0/TEXT.MAK /HomeAlone2_NES_Src/LL0/OPEN_DAT /HomeAlone2_NES_Src/LL0/IRQ_HA.SRC /HomeAlone2_NES_Src/LL0/CLEAN.BAT /HomeAlone2_NES_Src/LL0/FILEINFO.FI /HomeAlone2_NES_Src/LL0/ENDING.SRC /HomeAlone2_NES_Src/LL0/HA2NES.CRD /HomeAlone2_NES_Src/LL0/GAMEOVER.SRC /HomeAlone2_NES_Src/LL0/JJ.BAT /HomeAlone2_NES_Src/LL0/TEXT.A65 /HomeAlone2_NES_Src/LL0/GR /HomeAlone2_NES_Src/LL0/GR/FILEINFO.FI /HomeAlone2_NES_Src/LL0/GR/LL0SPR.LBM /HomeAlone2_NES_Src/LL0/GR/DP_PREFS /HomeAlone2_NES_Src/LL0/GR/LL0SPR1.LBM /HomeAlone2_NES_Src/LL0/GR/LL0SPR2.LBM /HomeAlone2_NES_Src/LL0/GR/MK.BAT /HomeAlone2NES_Src/LL0/GR/_BACKUP.LBM /HomeAlone2_NES_Src/LL0/GR/GR.MAK /HomeAlone2_NES_Src/LL0/TXTADR.A65 /HomeAlone2_NES_Src/LL0/CREDIT.SRC /HomeAlone2_NES_Src/LL0/ENDTXT /HomeAlone2_NES_Src/LL0/DP_PREFS /HomeAlone2_NES_Src/LL0/SETDIR.BAT /HomeAlone2_NES_Src/LL0/DLG.BAT /HomeAlone2_NES_Src/LL0/DECOMP.SRC /HomeAlone2_NES_Src/LL0/MP0.SRC /HomeAlone2_NES_Src/LL0/LL0COD.SRC /HomeAlone2_NES_Src/LL0/JTXT /HomeAlone2_NES_Src/LL0/JOUT /HomeAlone2_NES_Src/LL0/DLC.BAT /HomeAlone2_NES_Src/LL0/OPEN_TXT /HomeAlone2_NES_Src/LL0/WLDATA0.A65 /HomeAlone2_NES_Src/LL0/MOVIE1.SRC /HomeAlone2_NES_Src/LL0/HT00.SRC /HomeAlone2_NES_Src/LL0/TITLE.SRC /HomeAlone2_NES_Src/LL0/BG /HomeAlone2_NES_Src/LL0/BG/E1F2.NIN /HomeAlone2_NES_Src/LL0/BG/TITLE.LBM /HomeAlone2_NES_Src/LL0/BG/C1P1P5.LOD /HomeAlone2_NES_Src/LL0/BG/OS2.LBM /HomeAlone2_NES_Src/LL0/BG/E1.RAW /HomeAlone2_NES_Src/LL0/BG/E1A.NIN /HomeAlone2_NES_Src/LL0/BG/PARENTS.LBM /HomeAlone2_NES_Src/LL0/BG/TESTF1.LBM /HomeAlone2_NES_Src/LL0/BG/E1F3.NIN /HomeAlone2_NES_Src/LL0/BG/AL.NIN /HomeAlone2_NES_Src/LL0/BG/E1F1.NIN /HomeAlone2_NES_Src/LL0/BG/E1F5A.NIN /HomeAlone2_NES_Src/LL0/BG/MOVIE1.jpg /HomeAlone2_NES_Src/LL0/BG/E1F5.RLC /HomeAlone2_NES_Src/LL0/BG/OS1.LBM /HomeAlone2_NES_Src/LL0/BG/OS0.LBM /HomeAlone2_NES_Src/LL0/BG/BG.MAK /HomeAlone2_NES_Src/LL0/BG/E1F4.RLC /HomeAlone2_NES_Src/LL0/BG/E1_OLD.LBM /HomeAlone2_NES_Src/LL0/BG/S4A.A65 /HomeAlone2_NES_Src/LL0/BG/S5A.A65 /HomeAlone2_NES_Src/LL0/BG/E1F4.NIN /HomeAlone2_NES_Src/LL0/BG/FILEINFO.FI /HomeAlone2_NES_Src/LL0/BG/JAIL1.LBM /HomeAlone2_NES_Src/LL0/BG/MOVIE2.LBM /HomeAlone2_NES_Src/LL0/BG/CAUGHT.LBM /HomeAlone2_NES_Src/LL0/BG/JAIL0.LBM /HomeAlone2_NES_Src/LL0/BG/E1F1.RLC /HomeAlone2_NES_Src/LL0/BG/CREDIT.RAW /HomeAlone2_NES_Src/LL0/BG/E1F5.NIN /HomeAlone2_NES_Src/LL0/BG/E1F4A.NIN /HomeAlone2_NES_Src/LL0/BG/JJ.BAT /HomeAlone2_NES_Src/LL0/BG/E1F3.RLC /HomeAlone2_NES_Src/LL0/BG/MOVIE1.LBM /HomeAlone2_NES_Src/LL0/BG/ARMS2.PCX /HomeAlone2_NES_Src/LL0/BG/GAMEOVER.RAW /HomeAlone2_NES_Src/LL0/BG/MOVIE_O.LBM /HomeAlone2_NES_Src/LL0/BG/E1F2.RLC /HomeAlone2_NES_Src/LL0/BG/MOVIE2A.NIN /HomeAlone2_NES_Src/LL0/BG/MISC.NIN /HomeAlone2_NES_Src/LL0/BG/DP_PREFS /HomeAlone2_NES_Src/LL0/BG/LL0SPR1.LBM /HomeAlone2_NES_Src/LL0/BG/E1F3A.NIN /HomeAlone2_NES_Src/LL0/BG/E1F3.RAW /HomeAlone2_NES_Src/LL0/BG/JAIL1A.NIN /HomeAlone2_NES_Src/LL0/BG/S0.LBM /HomeAlone2_NES_Src/LL0/BG/TAPE.LBM /HomeAlone2_NES_Src/LL0/BG/GAMEOVER.RLC /HomeAlone2_NES_Src/LL0/BG/S1.LBM /HomeAlone2_NES_Src/LL0/BG/E1F2.RAW /HomeAlone2_NES_Src/LL0/BG/S2A.A65 /HomeAlone2_NES_Src/LL0/BG/ERR /HomeAlone2_NES_Src/LL0/BG/E1.NIN /HomeAlone2_NES_Src/LL0/BG/ARMS3.GIF /HomeAlone2_NES_Src/LL0/BG/OPENING.NIN /HomeAlone2_NES_Src/LL0/BG/S3.LBM /HomeAlone2_NES_Src/LL0/BG/HOTR.LBM /HomeAlone2_NES_Src/LL0/BG/S2.LBM /HomeAlone2_NES_Src/LL0/BG/E1F1.RAW /HomeAlone2_NES_Src/LL0/BG/OS1A.NIN /HomeAlone2_NES_Src/LL0/BG/CREDIT.RLC /HomeAlone2_NES_Src/LL0/BG/P5.DOC /HomeAlone2_NES_Src/LL0/BG/CREDIT.NIN /HomeAlone2_NES_Src/LL0/BG/E1F5.RAW /HomeAlone2_NES_Src/LL0/BG/CHARS.LBM /HomeAlone2_NES_Src/LL0/BG/E1F4.RAW /HomeAlone2_NES_Src/LL0/BG/GAMEOA.NIN /HomeAlone2_NES_Src/LL0/BG/S3A.A65 /HomeAlone2_NES_Src/LL0/BG/GAMEOVER.NIN /HomeAlone2_NES_Src/LL0/BG/C1P1P5.WLD /HomeAlone2_NES_Src/LL0/BG/CHRIS.LBM /HomeAlone2_NES_Src/LL0/BG/TOM_MEM.LBM /HomeAlone2_NES_Src/LL0/BG/FAMILYA.NIN /HomeAlone2_NES_Src/LL0/BG/E1.RLC /HomeAlone2_NES_Src/LL0/BG/ENDING.NIN /HomeAlone2_NES_Src/LL0/BG/S5.LBM /HomeAlone2_NES_Src/LL0/BG/FAMILY.LBM /HomeAlone2_NES_Src/LL0/BG/S4.LBM /HomeAlone2_NES_Src/LL0/BG/E1.PCX /HomeAlone2_NES_Src/LL0/BG/C0P1P1.WLD /HomeAlone2_NES_Src/LL0/BG/E1F2A.NIN /HomeAlone2_NES_Src/LL0/BG/ALPHA89.NIN /HomeAlone2_NES_Src/LL0/BG/FAMILY.NIN /HomeAlone2_NES_Src/LL0/BG/MOVIE1.RAW /HomeAlone2_NES_Src/LL0/BG/TAPE.RLC /HomeAlone2_NES_Src/LL0/BG/ALPHA89.LBM /HomeAlone2_NES_Src/LL0/BG/SP.MAK /HomeAlone2_NES_Src/LL0/BG/GAMEOVER.LBM /HomeAlone2_NES_Src/LL0/BG/CHRIS.NIN /HomeAlone2_NES_Src/LL0/BG/E1F1A.NIN /HomeAlone2_NES_Src/LL0/BG/TOM_MEM.NIN /HomeAlone2_NES_Src/LL0/BG/C1P1P5.NIN /HomeAlone2_NES_Src/LL0/BG/JAIL1.RAW /HomeAlone2_NES_Src/LL0/BG/MOVIE2.RAW /HomeAlone2_NES_Src/LL0/BG/CAUGHT.RAW /HomeAlone2_NES_Src/LL0/BG/OS0_OLD.LBM /HomeAlone2_NES_Src/LL0/BG/C0P1P1.NIN /HomeAlone2_NES_Src/LL0/BG/CREDIT.LBM /HomeAlone2NES_Src/LL0/BG/_BACKUP.LBM /HomeAlone2_NES_Src/LL0/BG/S0.A65 /HomeAlone2_NES_Src/LL0/BG/OS1.RAW /HomeAlone2_NES_Src/LL0/BG/TITLE.CEW /HomeAlone2_NES_Src/LL0/BG/CREDIT.OLD /HomeAlone2_NES_Src/LL0/BG/OS2A.NIN /HomeAlone2_NES_Src/LL0/BG/S1.A65 /HomeAlone2_NES_Src/LL0/BG/TITLE.RAW /HomeAlone2_NES_Src/LL0/BG/TOM_MEMA.NIN /HomeAlone2_NES_Src/LL0/BG/OS2.RAW /HomeAlone2_NES_Src/LL0/BG/E1.LBM /HomeAlone2_NES_Src/LL0/BG/TOM_MEM.RLC /HomeAlone2_NES_Src/LL0/BG/F_JAIL.NIN /HomeAlone2_NES_Src/LL0/BG/PARENTS.RAW /HomeAlone2_NES_Src/LL0/BG/FAMILY.RLC /HomeAlone2_NES_Src/LL0/BG/S1A.A65 /HomeAlone2_NES_Src/LL0/BG/TITLE.RLC /HomeAlone2_NES_Src/LL0/BG/E1F0_OLD.LBM /HomeAlone2_NES_Src/LL0/BG/OS2.RLC /HomeAlone2_NES_Src/LL0/BG/TOM_MEM.RAW /HomeAlone2_NES_Src/LL0/BG/PARENTS.RLC /HomeAlone2_NES_Src/LL0/BG/BACK.LBM /HomeAlone2_NES_Src/LL0/BG/EJOE.RAW /HomeAlone2_NES_Src/LL0/BG/FAMILY.RAW /HomeAlone2_NES_Src/LL0/BG/MOVIE1A.NIN /HomeAlone2_NES_Src/LL0/BG/MOVIE1.NIN /HomeAlone2_NES_Src/LL0/BG/LV1END1.NIN /HomeAlone2_NES_Src/LL0/BG/TEXT.LBM /HomeAlone2_NES_Src/LL0/BG/OS1.RLC /HomeAlone2_NES_Src/LL0/BG/C0P1P1.RAW /HomeAlone2_NES_Src/LL0/BG/E1F5.LBM /HomeAlone2_NES_Src/LL0/BG/E1F4.LBM /HomeAlone2_NES_Src/LL0/BG/C1P1P5.RAW /HomeAlone2_NES_Src/LL0/BG/JAIL1.NIN /HomeAlone2_NES_Src/LL0/BG/MOVIE2.NIN /HomeAlone2_NES_Src/LL0/BG/CAUGHT.NIN /HomeAlone2_NES_Src/LL0/BG/CAUGHT.RLC /HomeAlone2_NES_Src/LL0/BG/MOVIE2.RLC /HomeAlone2_NES_Src/LL0/BG/JAIL1.RLC /HomeAlone2_NES_Src/LL0/BG/E1F0.LBM /HomeAlone2_NES_Src/LL0/BG/E1F1.LBM /HomeAlone2_NES_Src/LL0/BG/TESTF1.A65 /HomeAlone2_NES_Src/LL0/BG/OPEN1.NIN /HomeAlone2_NES_Src/LL0/BG/OS1.NIN /HomeAlone2_NES_Src/LL0/BG/PARENTS.NIN /HomeAlone2_NES_Src/LL0/BG/TAPE.RAW /HomeAlone2_NES_Src/LL0/BG/ARMS1 /HomeAlone2_NES_Src/LL0/BG/MOVIE1.RLC /HomeAlone2_NES_Src/LL0/BG/MOVIE.NIN /HomeAlone2_NES_Src/LL0/BG/E1F3.LBM /HomeAlone2_NES_Src/LL0/BG/E1F2.LBM /HomeAlone2_NES_Src/LL0/BG/TITLE.NIN /HomeAlone2_NES_Src/LL0/BG/OS2.NIN /HomeAlone2_NES_Src/LL0/BG/LL0ABCST.LOD /HomeAlone2_NES_Src/LL0/DLALL.BAT /HomeAlone2_NES_Src/LL0/OLD.LL0 /HomeAlone2_NES_Src/LL0/SF0.SRC /HomeAlone2_NES_Src/LL0/LL0ZIPB.BAT /HomeAlone2_NES_Src/LL0/BGDATA0.SRC /HomeAlone2_NES_Src/LL0/TOM_MEM.SRC /HomeAlone2_NES_Src/LL0/DIRID.SRC /HomeAlone2_NES_Src/LL0/F1.SRC /HomeAlone2_NES_Src/LL0/ENDTXTOU /HomeAlone2_NES_Src/LL0/LL0SEQS.SRC /HomeAlone2_NES_Src/LL0/TXTCMP.EXE /HomeAlone2_NES_Src/LL0/TEXTO.A65 /HomeAlone2_NES_Src/LL0/LL0.A65 /HomeAlone2_NES_Src/LL1 /HomeAlone2_NES_Src/LL1/CLEAN.BAT /HomeAlone2_NES_Src/LL1/FILEINFO.FI /HomeAlone2_NES_Src/LL1/.DS_Store /HomeAlone2_NES_Src/LL1/GR /HomeAlone2_NES_Src/LL1/GR/KNEW.LBM /HomeAlone2_NES_Src/LL1/GR/KITSP.LBM /HomeAlone2_NES_Src/LL1/GR/FILEINFO.FI /HomeAlone2_NES_Src/LL1/GR/ENEMYMEN.LBM /HomeAlone2_NES_Src/LL1/GR/DP_PREFS /HomeAlone2_NES_Src/LL1/GR/LL1SPR4.LBM /HomeAlone2_NES_Src/LL1/GR/LL1SPR5.LBM /HomeAlone2_NES_Src/LL1/GR/CONC.LBM /HomeAlone2_NES_Src/LL1/GR/DICK.LBM /HomeAlone2_NES_Src/LL1/GR/LL1SPR2.LBM /HomeAlone2_NES_Src/LL1/GR/BLANK.LBM /HomeAlone2_NES_Src/LL1/GR/CHEF.LBM /HomeAlone2_NES_Src/LL1/GR/CHEF2.LBM /HomeAlone2_NES_Src/LL1/GR/LL1SPR3.LBM /HomeAlone2_NES_Src/LL1/GR/LL1SPR1.LBM /HomeAlone2_NES_Src/LL1/GR/CHEF1.LBM /HomeAlone2_NES_Src/LL1/GR/KNEW2.LBM /HomeAlone2_NES_Src/LL1/GR/WAITER.LBM /HomeAlone2_NES_Src/LL1/GR/GR.MAK /HomeAlone2_NES_Src/LL1/GR/ICONS.LBM /HomeAlone2_NES_Src/LL1/GR/MAID.LBM /HomeAlone2_NES_Src/LL1/GR/DISH.LBM /HomeAlone2_NES_Src/LL1/GR/GSA.LBM /HomeAlone2_NES_Src/LL1/GR/GHOSTS.LBM /HomeAlone2_NES_Src/LL1/GR/ENEMY2.LBM /HomeAlone2_NES_Src/LL1/SETDIR.BAT /HomeAlone2_NES_Src/LL1/LAYOUT.DOC /HomeAlone2_NES_Src/LL1/DLG.BAT /HomeAlone2_NES_Src/LL1/MP10.SRC /HomeAlone2_NES_Src/LL1/DLC.BAT /HomeAlone2_NES_Src/LL1/WLDATA1.A65 /HomeAlone2_NES_Src/LL1/HT1.CEW /HomeAlone2_NES_Src/LL1/HT1.SRC /HomeAlone2_NES_Src/LL1/ST1.SRC /HomeAlone2_NES_Src/LL1/LL1 /HomeAlone2_NES_Src/LL1/BG /HomeAlone2_NES_Src/LL1/BG/16B.LBM /HomeAlone2_NES_Src/LL1/BG/12BRA.LBM /HomeAlone2_NES_Src/LL1/BG/LOBM.LBM /HomeAlone2_NES_Src/LL1/BG/LOBL.LBM /HomeAlone2_NES_Src/LL1/BG/16C.LBM /HomeAlone2_NES_Src/LL1/BG/PIC.NLD /HomeAlone2_NES_Src/LL1/BG/L2.WLD /HomeAlone2_NES_Src/LL1/BG/16A.LBM /HomeAlone2_NES_Src/LL1/BG/11CR.LBM /HomeAlone2_NES_Src/LL1/BG/PIC1.TMP /HomeAlone2_NES_Src/LL1/BG/GIFTS.LBM /HomeAlone2_NES_Src/LL1/BG/LOBN.LBM /HomeAlone2_NES_Src/LL1/BG/BG.MAK /HomeAlone2_NES_Src/LL1/BG/NEWS.GRP /HomeAlone2_NES_Src/LL1/BG/ELEV.LBM /HomeAlone2_NES_Src/LL1/BG/FILEINFO.FI /HomeAlone2_NES_Src/LL1/BG/16D.LBM /HomeAlone2_NES_Src/LL1/BG/ELEV.GRP /HomeAlone2_NES_Src/LL1/BG/LOBK.LBM /HomeAlone2_NES_Src/LL1/BG/NEWS.LBM /HomeAlone2_NES_Src/LL1/BG/LOBJ.LBM /HomeAlone2_NES_Src/LL1/BG/LOBBY.LBM /HomeAlone2_NES_Src/LL1/BG/14ER.LBM /HomeAlone2_NES_Src/LL1/BG/16E.LBM /HomeAlone2_NES_Src/LL1/BG/15CR.LBM /HomeAlone2_NES_Src/LL1/BG/12DR.LBM /HomeAlone2_NES_Src/LL1/BG/LOBH.LBM /HomeAlone2_NES_Src/LL1/BG/LOBI.LBM /HomeAlone2_NES_Src/LL1/BG/16F.LBM /HomeAlone2_NES_Src/LL1/BG/12FRA.LBM /HomeAlone2_NES_Src/LL1/BG/16CRA.LBM /HomeAlone2_NES_Src/LL1/BG/DP_PREFS /HomeAlone2_NES_Src/LL1/BG/K10.LBM /HomeAlone2_NES_Src/LL1/BG/PIC1A.WLD /HomeAlone2_NES_Src/LL1/BG/K6.LBM /HomeAlone2_NES_Src/LL1/BG/11E.LBM /HomeAlone2_NES_Src/LL1/BG/LOBFB.LBM /HomeAlone2_NES_Src/LL1/BG/LOBFT.LBM /HomeAlone2_NES_Src/LL1/BG/FIXP2.BAT /HomeAlone2_NES_Src/LL1/BG/11D.LBM /HomeAlone2_NES_Src/LL1/BG/K7.LBM /HomeAlone2_NES_Src/LL1/BG/ERR /HomeAlone2_NES_Src/LL1/BG/C1P1P1.WLD /HomeAlone2_NES_Src/LL1/BG/C1P1P3.WLD /HomeAlone2_NES_Src/LL1/BG/K5.LBM /HomeAlone2_NES_Src/LL1/BG/MK.BAT /HomeAlone2_NES_Src/LL1/BG/11F.LBM /HomeAlone2_NES_Src/LL1/BG/K4.LBM /HomeAlone2_NES_Src/LL1/BG/PIC1.NLD /HomeAlone2_NES_Src/LL1/BG/C1P1P2.WLD /HomeAlone2_NES_Src/LL1/BG/12BR.LBM /HomeAlone2_NES_Src/LL1/BG/11C.LBM /HomeAlone2_NES_Src/LL1/BG/BLANK.LBM /HomeAlone2_NES_Src/LL1/BG/COMMON1.LBM /HomeAlone2_NES_Src/LL1/BG/K1.LBM /HomeAlone2_NES_Src/LL1/BG/11B.LBM /HomeAlone2_NES_Src/LL1/BG/C1P1P5.WLD /HomeAlone2_NES_Src/LL1/BG/K3.LBM /HomeAlone2_NES_Src/LL1/BG/LOBGT.LBM /HomeAlone2_NES_Src/LL1/BG/COMMON3.LBM /HomeAlone2_NES_Src/LL1/BG/COMMON2.LBM /HomeAlone2_NES_Src/LL1/BG/14CR.LBM /HomeAlone2_NES_Src/LL1/BG/K2.LBM /HomeAlone2_NES_Src/LL1/BG/11A.LBM /HomeAlone2_NES_Src/LL1/BG/C1P1P4.WLD /HomeAlone2_NES_Src/LL1/BG/KNEWS.LBM /HomeAlone2_NES_Src/LL1/BG/12A.LBM /HomeAlone2_NES_Src/LL1/BG/L1W1.WLD /HomeAlone2_NES_Src/LL1/BG/12C.LBM /HomeAlone2_NES_Src/LL1/BG/12B.LBM /HomeAlone2_NES_Src/LL1/BG/L1W0.WLD /HomeAlone2_NES_Src/LL1/BG/K9.LBM /HomeAlone2_NES_Src/LL1/BG/12F.LBM /HomeAlone2_NES_Src/LL1/BG/JJ.LBM /HomeAlone2_NES_Src/LL1/BG/K8.LBM /HomeAlone2_NES_Src/LL1/BG/12E.LBM /HomeAlone2_NES_Src/LL1/BG/PIC1.WLD /HomeAlone2_NES_Src/LL1/BG/LOBET.LBM /HomeAlone2_NES_Src/LL1/BG/12D.LBM /HomeAlone2_NES_Src/LL1/BG/CHR.DOC /HomeAlone2_NES_Src/LL1/BG/14C.LBM /HomeAlone2_NES_Src/LL1/BG/LOBD.LBM /HomeAlone2_NES_Src/LL1/BG/LOBE.LBM /HomeAlone2_NES_Src/LL1/BG/14B.LBM /HomeAlone2_NES_Src/LL1/BG/15F.LBM /HomeAlone2_NES_Src/LL1/BG/15D.LBM /HomeAlone2_NES_Src/LL1/BG/ALLEY.LBM /HomeAlone2_NES_Src/LL1/BG/LOBG.LBM /HomeAlone2_NES_Src/LL1/BG/LOBF.LBM /HomeAlone2_NES_Src/LL1/BG/15E.LBM /HomeAlone2_NES_Src/LL1/BG/14A.LBM /HomeAlone2_NES_Src/LL1/BG/14E.LBM /HomeAlone2_NES_Src/LL1/BG/15A.LBM /HomeAlone2_NES_Src/LL1/BG/PIC.WLD /HomeAlone2_NES_Src/LL1/BG/LOBB.LBM /HomeAlone2_NES_Src/LL1/BG/LOBC.LBM /HomeAlone2_NES_Src/LL1/BG/14D.LBM /HomeAlone2_NES_Src/LL1/BG/15B.LBM /HomeAlone2_NES_Src/LL1/BG/14F.LBM /HomeAlone2_NES_Src/LL1/BG/LOBA.LBM /HomeAlone2_NES_Src/LL1/BG/15C.LBM /HomeAlone2_NES_Src/LL1/BG/11CRA.LBM /HomeAlone2_NES_Src/LL1/DLALL.BAT /HomeAlone2_NES_Src/LL1/SS1.SRC /HomeAlone2_NES_Src/LL1/LL1COD.SRC /HomeAlone2_NES_Src/LL1/SF1.SRC /HomeAlone2_NES_Src/LL1/DIRID.SRC /HomeAlone2_NES_Src/LL1/LL1SEQS.SRC /HomeAlone2_NES_Src/LL1/BGDATA1.SRC /HomeAlone2_NES_Src/LL1/LL1.A65 /HomeAlone2_NES_Src/AUD /HomeAlone2_NES_Src/AUD/AUDIOMAC.AUD /HomeAlone2_NES_Src/AUD/COMMON.AUD /HomeAlone2_NES_Src/AUD/TEMP.AUD /HomeAlone2_NES_Src/AUD/HMA2 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_SK.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_SI.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_S9.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_S8.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_SC.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_S5.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_S4.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_SB.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2.INS /HomeAlone2_NES_Src/AUD/HMA2/HMA2DEF.SND /HomeAlone2_NES_Src/AUD/HMA2/HMA2_S6.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_S7.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_SA.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2.SND /HomeAlone2_NES_Src/AUD/HMA2/HMA2_S3.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_SE.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_SD.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_S2.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2.MUS /HomeAlone2_NES_Src/AUD/HMA2/HMA2_SF.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_SG.SQ1 /HomeAlone2_NES_Src/AUD/HMA2/HMA2_S1.SQ1 /HomeAlone2_NES_Src/AUD/AUDIONFF.AUD /HomeAlone2_NES_Src/AUD/AUDSIZE.SYM /HomeAlone2_NES_Src/AUD/INST.AUD /HomeAlone2_NES_Src/AUD/AUDIODEF.AUD /HomeAlone2_NES_Src/AUD/AU.SYM /HomeAlone2_NES_Src/AUD/ERR /HomeAlone2_NES_Src/AUD/MK.BAT /HomeAlone2_NES_Src/AUD/BR-5AE7.MDS /HomeAlone2_NES_Src/AUD/AUDIO.AUD /HomeAlone2_NES_Src/AUD/AU.LOD /HomeAlone2_NES_Src/AUD/AU_DEFS.SRC /HomeAlone2_NES_Src/AUD/AUDIO.DOC /HomeAlone2_NES_Src/AUD/NES.H /HomeAlone2_NES_Src/AUD/AUDIO.A65 /HomeAlone2_NES_Src/AUD/AU.BAT /HomeAlone2_NES_Src/AUD/AUPROG.LOD /HomeAlone2_NES_Src/AUD/HMA2_062.TXT /HomeAlone2_NES_Src/AUD/MUSIC.AUD /HomeAlone2_NES_Src/AUD/SEQUENCE.AUD /HomeAlone2_NES_Src/AUD/AUDIO.DAT /HomeAlone2_NES_Src/AUD/MUSIC.A65 /HomeAlone2_NES_Src/AUD/AU_CODE.SRC /HomeAlone2_NES_Src/AUD/AUDIONZP.AUD /HomeAlone2_NES_Src/AUD/AUDIOZP.AUD /HomeAlone2_NES_Src/AUD/WAVE.DAT /HomeAlone2_NES_Src/AUD/SOUND.AUD /HomeAlone2_NES_Src/AUD/AUDIODRU.AUD /HomeAlone2_NES_Src/AUD/AUDIO.SYM /HomeAlone2_NES_Src/AUD/AUDIOINC.AUD /HomeAlone2_NES_Src/AUD/AUDIOFFP.AUD /HomeAlone2_NES_Src/AUD/DRUMS.A65 /HomeAlone2_NES_Src/AUD/AUDIO.LOD /HomeAlone2_NES_Src/AUD/AU.A65 /HomeAlone2_NES_Src/PUB /HomeAlone2_NES_Src/PUB/DLDISK.BAT /HomeAlone2_NES_Src/PUB/STACOD.SRC /HomeAlone2_NES_Src/PUB/PUBVAR.SRC /HomeAlone2_NES_Src/PUB/PUBBRN.SRC /HomeAlone2_NES_Src/PUB/CLEAN.BAT /HomeAlone2_NES_Src/PUB/FILEINFO.FI /HomeAlone2_NES_Src/PUB/PUBCOD.SRC /HomeAlone2_NES_Src/PUB/CLALL.BAT /HomeAlone2_NES_Src/PUB/PUBMAC.SRC /HomeAlone2_NES_Src/PUB/GR /HomeAlone2_NES_Src/PUB/GR/KNEW.LBM /HomeAlone2_NES_Src/PUB/GR/RLCMP.EXE /HomeAlone2_NES_Src/PUB/GR/KEVINMIS.LBM /HomeAlone2_NES_Src/PUB/GR/KEVIN.LBM /HomeAlone2_NES_Src/PUB/GR/DP_PREFS /HomeAlone2_NES_Src/PUB/GR/PUBCOM.LBM /HomeAlone2_NES_Src/PUB/GR/KEVINRUN.LBM /HomeAlone2_NES_Src/PUB/GR/BLANK.LBM /HomeAlone2_NES_Src/PUB/GR/PICKUPS.CEW /HomeAlone2_NES_Src/PUB/GR/KNEWS.LBM /HomeAlone2_NES_Src/PUB/GR/KNEW2.LBM /HomeAlone2_NES_Src/PUB/GR/KNEW3.LBM /HomeAlone2NES_Src/PUB/GR/_BACKUP.LBM /HomeAlone2_NES_Src/PUB/GR/myapp.txt /HomeAlone2_NES_Src/PUB/GR/GR.MAK /HomeAlone2_NES_Src/PUB/GR/KEVINOLD.LBM /HomeAlone2_NES_Src/PUB/GR/ALI.NIN /HomeAlone2_NES_Src/PUB/GR/BU /HomeAlone2_NES_Src/PUB/GR/BU/PUBCOM.SPR /HomeAlone2_NES_Src/PUB/GR/PICKUPS.LBM /HomeAlone2_NES_Src/PUB/GR/KEVINJMP.LBM /HomeAlone2_NES_Src/PUB/GR/L2N.EXE /HomeAlone2_NES_Src/PUB/STAVAR.SRC /HomeAlone2_NES_Src/PUB/MKDISK.BAT /HomeAlone2_NES_Src/PUB/MMNVAR.SRC /HomeAlone2_NES_Src/PUB/BSUBS.SRC /HomeAlone2_NES_Src/PUB/PUBEQU.SRC /HomeAlone2_NES_Src/PUB/MMC1LOD.BAT /HomeAlone2_NES_Src/PUB/PUBPGF.SRC /HomeAlone2_NES_Src/PUB/STAEQU.SRC /HomeAlone2_NES_Src/PUB/B3CSET.BIN /HomeAlone2_NES_Src/PUB/MF.BAT /HomeAlone2_NES_Src/PUB/WLDP /HomeAlone2_NES_Src/PUB/B3PROG1.BIN /HomeAlone2_NES_Src/PUB/DLALL.BAT /HomeAlone2_NES_Src/PUB/AF.BAT /HomeAlone2_NES_Src/PUB/PUBSET.SRC /HomeAlone2_NES_Src/PUB/MVMAIN.SRC /HomeAlone2_NES_Src/PUB/DIRID.SRC /HomeAlone2_NES_Src/PUB/PUBCOM.SRC /HomeAlone2_NES_Src/PUB/PUBCOM.CEW /HomeAlone2_NES_Src/PUB/PUBINT.SRC /HomeAlone2_NES_Src/PUB/SFC.SRC /HomeAlone2_NES_Src/PUB/TMP.BAT /HomeAlone2_NES_Src/BlofPost /HomeAlone2_NES_Src/BlofPost/Pub_GR_Sheet_0003.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0008.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0009.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0001.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0015.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0014.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0000.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0016.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0002.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0003.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0013.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0007.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0006.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0012.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0004.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0010.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0011.jpg /HomeAlone2_NES_Src/BlofPost/Sheet_0005.jpg /HomeAlone2_NES_Src/UTL /HomeAlone2_NES_Src/UTL/LOD2RAW.EXE /HomeAlone2_NES_Src/UTL/CMERGE.EXE /HomeAlone2_NES_Src/UTL/NIN2OBJ2.EXE /HomeAlone2_NES_Src/UTL/RLCMP.EXE /HomeAlone2_NES_Src/UTL/CNGNIN.EXE /HomeAlone2_NES_Src/UTL/FILEINFO.FI /HomeAlone2_NES_Src/UTL/NIN2LOD.EXE /HomeAlone2_NES_Src/UTL/PKZIP.EXE /HomeAlone2_NES_Src/UTL/CMATCH.EXE /HomeAlone2_NES_Src/UTL/A65.EXE /HomeAlone2_NES_Src/UTL/L2G.EXE /HomeAlone2_NES_Src/UTL/err /HomeAlone2_NES_Src/UTL/POPD.EXE /HomeAlone2_NES_Src/UTL/ERRCHK.EXE /HomeAlone2_NES_Src/UTL/MK.BAT /HomeAlone2_NES_Src/UTL/WLD2RAW.EXE /HomeAlone2_NES_Src/UTL/RAWMRG.EXE /HomeAlone2_NES_Src/UTL/LBM2NIN.EXE /HomeAlone2_NES_Src/UTL/TM.EXE /HomeAlone2_NES_Src/UTL/BKUP.BAT /HomeAlone2_NES_Src/UTL/NOTE.EXE /HomeAlone2_NES_Src/UTL/MAKE.EXE /HomeAlone2_NES_Src/UTL/JTS.BAT /HomeAlone2_NES_Src/UTL/MW.EXE /HomeAlone2_NES_Src/UTL/AD.BAT /HomeAlone2_NES_Src/UTL/NIN2RAW.EXE /HomeAlone2_NES_Src/UTL/CSM.EXE /HomeAlone2_NES_Src/UTL/PUSHD.EXE /HomeAlone2_NES_Src/UTL/EGAVGA.BGI /HomeAlone2_NES_Src/UTL/DL.EXE /HomeAlone2_NES_Src/UTL/TXTCMP.EXE /HomeAlone2_NES_Src/UTL/PKUNZIP.EXE /HomeAlone2_NES_Src/UTL/LOD2BIN.EXE /HomeAlone2_NES_Src/UTL/IN.EXE /HomeAlone2_NES_Src/UTL/A65WLD.BAT /HomeAlone2_NES_Src/UTL/OUT.EXE /HomeAlone2_NES_Src/UTL/L2N.EXE /HomeAlone2_NES_Src/BASE /HomeAlone2_NES_Src/BASE/BNKMAC.SRC /HomeAlone2_NES_Src/BASE/BASETABS.SRC /HomeAlone2_NES_Src/BASE/BASE.CEW /HomeAlone2_NES_Src/BASE/ASMSET.SRC /HomeAlone2_NES_Src/BASE/BNKEQU.SRC /HomeAlone2_NES_Src/BASE/BASE.A65 /HomeAlone2_NES_Src/BASE/BASVAR.SRC /HomeAlone2_NES_Src/BASE/JOYEQU.SRC /HomeAlone2_NES_Src/BASE/BASMAC.SRC /HomeAlone2_NES_Src/BASE/BNKSET.A65 /HomeAlone2_NES_Src/BASE/BASE.OLD /HomeAlone2_NES_Src/BASE/BASEQU.SRC /HomeAlone2_NES_Src/SETPATH.BAT Directory AnalysisUTL Directory (Utility directory)Thanks to “freem” on the NesDev forums we have a good description of the tools available in the UTL directory of the source code. Name Description A65.EXE 6502 NES Assembler Usage: a65 [path]infile[.a65] [[path]outfile[.lod]] CMERGE.EXE Merge Char sets (e.g merge family char set and jail1 set) and returns a NIN file Most likely; here are some results after looking through the files in the \"UTL\" directory:* A65.EXE looks to be a 6502 assembler.* CMATCH.EXE and CMERGE.EXE are probably dev tools, but I'm not sure what they're for.* CNGNIN.EXE: \"This utility replaces the color palette information in dest.nin with the palette information from source.nin\"* CSM.EXE: \"merge part of font from source to destination.\"* DL.EXE, if I had to guess, seems to be used for downloading data to a development cartridge...* L2G.EXE: \"LBM2GRP - LBM to GRP Converter Rev 1.0 (1/22/92)\" (as a USA company, that'd be 1992/01/22 under YYYY/MM/DD)* L2N.EXE: \"LBM2NIN - lbm to nin Converter Rev 1.0 June 7, 1991\" (Probably the main tool used for graphics conversion, given the number of LBM files in the archive)* LOD2BIN.EXE: Converts .LOD to binary files, presumably.* LOD2RAW.EXE: \"LOD2RAW - .LOD to .RAW File Conversion Utility Rev 0.0\"* MW.EXE: \"MakeWorld\" graphical program (uses a mouse)* NIN2LOD.EXE: Converts .NIN files to .LOD files, whatever each of those are.* NIN2OBJ2.EXE: Converts a .NIN to assembler source?* NIN2RAW.EXE: Converts .NIN files to a .RAW file.* TXTCMP.EXE: \"TXTCMP - Text Compression Rev 1.0\"* RAWMRG.EXE: \"RAWMRG - Raw Screen Map Merge Rev 0.1\"* RLCMP.EXE: \"RLCMP - Run-Length Compression Rev 0.1\"* TXTCMP.EXE: \"TXTCMP - Text Compression Rev 1.0\"[https://forums.nesdev.com/viewtopic.php?f=5&t=14339 ]File FormatsThe file formats used in the source are listed in the following table: Name Description .NIN Nintendo image format? .RAW RAW image format (why have these when we have the LBM files?) .LOD I think this is compiled object files from assembly but not sure why its called LOD .LBM Deluxe Paint Images (Interlaced bitmaps), can be opened with XnViewMP .GRP .SRC 6502 Assembler Header files used for includes .A65 6502 Assembler Source Code Implementation files .CEW 6502 Assembler Source Code but with some minor differences .GME 6502 Assembler Source Code Implementation files, these are only located in the Engine folder so does it stand for Game Engine? Game Asset PipelineThe game uses GNU Makefiles to build its assets into the shippable product. It all starts with Deluxe Paint on the Amiga, the artists draw pixel art on pre-defined templates and save them as the standard Deluxe Paint .LBM files.Those LBM files need to be converted into a format that the game engine can read and display on the screen. To convert the .LBM format into a NES friendly (2bpp) image format the developers use a tool called “l2n” which I presume they developed themselves or license from another game development studio.The .MAK makefiles have the format:movie1.nin:\tmovie1.lbm##\t\t\"create movie 1 screen\"#\t\tl2n movie1Where movie1.nin is the output file expected by the makefile and movie1.lbm is the input file.BASE DirectoryThe BASE directory contains all the glue code that puts everything together, sets up the banking etc.BASE.A65 vs BASE.CEWThere seems to be three different versions of the “BASE” file, all with minor differences. I’m trying to figure out what CEW stands for as I presume the main build is the BASE.A65 file.It looks like BASE.CEW is older than its .A65 sibling as the A65 version has additional code plus some of the CEW code commented out.The third file is BASE.OLD which presumably is just an older version of BASE.A65 and not that interesting.DEVDOC Directory (Developer Documentation)This directory contains some very interesting documentation written by the developers for how to use the game engine, scripting etc. File Name Description ADDING.DOC Describes how to go about creating a new ll* directory for the game (local levels). FILEINFO.FI Information about the other files in the directory, mentions Game Boy but not sure the purpose of this file. INSTALL.DOC Installing a new project directory on your hard drive NEWNES.DOC Documents how to build the project for different environments, such as Prod, Demo etc SCRPDOC.DOC Engine scripting documentation, how to use the scripting language TEMPLATE A bunch of Comment Templates for use in the assembly code, for example how to document a function similar to javadoc. PUB (Public?) DirectoryThis directory seems to contain all the assets that are required on every level, for example the main character sprites and pickups.I presume its called public because other developers can work on their own “local levels” but share the PUB folder with each other when they make changes.PUB/GR (Public Graphics directory)Mainly contains LBM files (Deluxe Paint) for Kevin and pickups used in all the other levels.Local Level Directories (ll0 -> ll4)I presume these are the different game levels?Common FIles CLEAN.BAT Clean the folder by removing all the compiled files (*.nin, *.lod, *.spr, *.mem etc) Local Level 0Local level 0 BackgroundsLocal Level 0 Graphics (ll0/GR)Local Level 1Local Level 01 BackgroundsLocal Level 01 GraphicsLocal vs Full Game buildIt looks like there are 2 different ways to compile the game, one is a ‘local build’ which only contains a certain level (ll0, ll1 etc) and the other is the full game which contains all the levels.ENG (Game Engine) DirectoryDevelopers Tony Lau Christoper Will (Is he known in the code as Henry C. Will IV? ) Joseph A. Moses (Known in the code as Jesus? )", "excerpt": "Home Alone 2 NES Source Code The Source Code for “Home Alone 2” was kindly released by Frank Cifaldi from GameHistoryorg (@frankcifald). Games on the same engine The same Game Engine seems to have been used in at least 5 games developed by Imagineering for the Nintendo Entertainment System. Attack...", "tags": ["nes","games","sourcecode"], "image": "https://img.youtube.com/vi/cqsCqG-uako/0.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "How the Dreamcast's Security was Hacked (MIL-CD)", "url": "/How-the-Dreamcast-Security-was-Hacked", "content": "History of Dreamcast HackingNeperos hosts an article (originally from Retro Revival magazine) that chronicles the rise of the Sega Dreamcast homebrew scene. The piece details how the “MIL-CD” exploit and the release of the Utopia Boot Disc bypassed the console’s copy protection, paving the way for homebrew development tools like KallistiOS and the porting of emulators and media players such as DCDivX and ScummVM. History of Dreamcast Homebrew A retrospective on the technical origins of the Dreamcast homebrew scene, covering the discovery of the MIL-CD backdoor, the release of the Utopia bootloader, and the evolution of open-source development kits. Bleemcasting: An Interview With Bleemcast! Developer Randy LindenThe Dreamcast Junkyard speaks with Randy Linden, the core developer behind the Bleemcast! emulator. The interview covers the technical challenges of porting the PC emulator to the Dreamcast’s SH-4 architecture, the reverse engineering of the MIL-CD format to bypass Sega’s licensing, and the history behind the unreleased “BleemPod” hardware. Bleemcasting: Interview With Randy Linden Randy Linden shares insights into the development of Bleemcast!, discussing the low-level optimizations required for the Dreamcast hardware, the legal pressures from Sony, and the unreleased peripherals intended for the system. Did the Dreamcast not have anti-piracy measures?It is a common misconception that the reason the Dreamcast failed was because it has no prevention against playing copied games… Well, that wasn’t entirely true. In fact it had one of the most sophisticated forms of copy protection at time time. With just one little oversight…. the MIL-CD format.You can’t simply copy the contents of a Dreamcast GD-ROM to a CD-R and expect it to boot on an unmodified retail Dreamcast.There is copy protection in place to prevent this. The reason you can play burned games is because the ISO files you find online have been modified to take advantage of the MIL-CD exploit. Unlike games, MIL-CDs have no copy protection so the Dreamcast will boot them without questioning authenticity.How are Dreamcast games able to fit on a CD-R?The dreamcast actually used GD-ROM discs that only developers had access to writing such discs in a manufacturing setting. The GD-ROM could fit about 1GB of data unlike the CD-R that had a maximum size of 700MB.Not all games used the full 1GB of space however so many games were in fact less than 700MB and could be used without removing any content.For games that didn’t fit onto a CD-R, they would rip out or downsample some of the content (usually FMV’s or background music).How were CD-R versions of Dreamcast games created?It was an incredibly involved process to turn a GD-ROM game into a bootable CD-R. But already made CD-R games were very easy to copy, so as soon as the process has been done once, anyone could clone that CD-R to distribute the game.", "excerpt": "History of Dreamcast Hacking Neperos hosts an article (originally from Retro Revival magazine) that chronicles the rise of the Sega Dreamcast homebrew scene. The piece details how the “MIL-CD” exploit and the release of the Utopia Boot Disc bypassed the console’s copy protection, paving the way for homebrew development tools...", "tags": ["dreamcast","hardware","cracking","sega"], "image": "/public/images/dreamcast/Dreamcast Security and Piracy.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "How Do Emulators Work? A Deep Dive into Emulator Design", "url": "/how-emulators-work", "content": "Have you ever wondered how emulators work? How would you implement an emulator? Where should you start if you are interested in emulator development? This post attempts to answer all those questions.Introduction to EmulatorsEmulators are computer programs that run on one system, such as a PC or game console, but pretend to be another system, such as a retro console like the NES or Game Boy.What exactly does an emulator do?It reproduces the behavior of a specific hardware system (e.g NES, SEGA Mega Drive) in software so that original programs can run unchanged.It models CPU instructions, memory interactions, and device behavior well enough for software to behave as if real hardware were present.How can software pretend to be hardware?It implements software models of hardware components such as registers, memory buses, I/O devices, and timers. Programs interact with these models exactly as they would with the physical components.Are FPGA based systems considered emulators?Yes, FPGA systems emulate hardware by reconfiguring logic blocks to mimic the circuitry of the original system. They operate at lower abstraction levels than software emulators, providing near hardware fidelity.Do emulators physically simulate the low level circuits?No. Emulators simulate what the hardware does (the end result), not how every transistor or wire behaves in the real world. Simulating electronics at a physical level is done by circuit simulators and is far too slow for running programs.Emulators focus on reproducing the architectural effects of the hardware: how instructions behave, how memory is accessed, and how devices respond. Some include rough or cycle-level timing, while others ignore timing entirely depending on the goal.Why do some emulators need BIOS or firmware files?Certain hardware relies on proprietary initialization code or system routines stored in ROM. An emulator must load these images to reproduce authentic behavior and maintain compatibility.Bytes N Bits has an excellent video introducing BIOS/firmware files:What role do ROMs and ISOs play in emulation?They contain the original software or firmware images meant for the target hardware. The emulator loads and executes them exactly as the real system would.Is an emulator similar to an interpreter for a high level language?There is a loose similarity. Both run instructions that were written for something else and translate them into operations the host system can perform.The difference is that an emulator reproduces the rules of real hardware, while a language interpreter follows the rules of a programming language.Similarities between Emulators and Programming Language InterpretersInterpreters and emulators each implement an execution model that translates foreign instructions into operations the host system can perform.Both systems typically include: A parser or decoder that reads the incoming instruction format (bytecode, tokens, CPU opcodes) Use a fetch-decode-execute style loop Keep a software model of program state (registers, stacks, heaps, or similar) Handle errors inside their own virtual environmentDifferences between Emulators and Programming Language InterpretersInstead of interpreting source code an emulator operates on compiled (assembled) machine code instructions which are in a binary form.Emulators must also model registers, memory buses, I/O devices, and the timing between these components, which has no analogue in most high level interpreters.Why are some emulators fast and others slow?Speed depends on how much hardware detail is modeled and whether the emulator interprets instructions or uses JIT compilation.Cycle accurate models are significantly slower because they reproduce low level timing.Why do some emulators use JIT compilers instead of interpretation?JIT compilation converts foreign machine code into host machine code for faster execution. It reduces instruction dispatch overhead but increases implementation complexity.What makes an emulator accurate or inaccurate?Accuracy depends on how closely the emulator matches hardware timing, instruction behavior, and device quirks. Omitting subtle hardware details can improve speed but reduce compatibility or fidelity.100th Coin has a video looking at the accuracy of Nintendo’s Official Emulators:What is cycle accuracy and why does it matter?Cycle accuracy means the emulator reproduces hardware behavior at the granularity of individual clock cycles.This is essential for software that relies on precise timing, such as demos or tightly synchronized games.Why are timing bugs in old hardware hard to emulate?They often arise from electrical characteristics, propagation delays, or undocumented behavior. Reproducing these requires extremely detailed models that are expensive to implement.What causes compatibility issues in emulators?Missing hardware features, incorrect timing, or simplified device models can all break software that depends on subtle behavior. Some games rely on undocumented quirks that are difficult to replicate.What is the difference between high-level and low-level emulation?There are two main categories of emulators: High Level Emulators (HLE) and Low Level Emulators (LLE). Low-Level Emulation (LLE) - maximizes accuracy by simulating each hardware component including timing behaviours but is computationally expensive. High-Level Emulation (HLE) - Detects API functions and implements an alternative using modern APIs, rather than executing each instruction of the API function calls.Some modern emulators blend both approaches to balance compatibility and performance. For example, they might use LLE for the CPU and HLE for the graphics or audio subsystems.For a deeper dive into it check out High and low-level emulation - Emulation General WikiWhat can be emulated?Normally, emulators are pretending to be a physical system, so we need to simulate all the connections between physical components, such as different electronic chips.However, there are also many emulators that simulate systems which never existed in physical form, such as fantasy consoles like the PICO-8.So in this post, we are just going to call the thing we want to pretend to be: the system.What is a System made of?Normally, when we are talking about a system such as a game console or PC, they have a few common components that we will need to simulate on our host system, such as: A CPU Chip - e.g Z80, 6502, SH-2, x86, ARM, etc. ROM - Read-Only Memory, such as a game cartridge (or ISO for CD-based systems, which are also read-only) RAM - Memory modules to store the current state of the system Input Interface - Such as controllers for game consoles or keyboard/mouse for PC-like systems Display/Output Interface - Normally a screen such as a monitor or TV, but could also be a more physical output like printing on paper Audio Output Interface - Some systems, such as game consoles, have audio processing chips which need to be simulatedHow do emulators handle graphics, audio, and controllers?They implement software models of the original GPU, audio chip, and input devices. Each instruction or register write updates these models so the output matches what real hardware would produce.Emulating The CPUYou can think of a CPU as running in an infinite loop, performing the same operations repeatedly until it loses power and switches off. So a CPU should be easy to emulate on another system, right? Just create a while loop that runs forever and does everything a CPU would do each cycle. Well, sort of… it’s not quite that easy, but we are on the right track.Fetch-Decode-Execute CycleEvery iteration of the loop (known as a clock cycle in CPU terms), the CPU goes through a process known as the fetch–decode–execute cycle.At a very high level, this would be: Fetch - Find where the next instruction to execute is located Decode - Understand what the instruction is asking to do Execute - Actually do what the instruction wantsThat’s what CPUs do from the moment they are started until they are powered off.So imagine you are a baker with an endless list of tasks to do to make cakes, and every time you finish one of those tasks, you just move on to the next one, forever. The task in this case is what a CPU calls an instruction; for example, “put flour in the bowl” would be an instruction.Fetching would be the baker moving on from the previous step and finding the next step of the recipe (it might be on the next line of the recipe book or on another page). Decoding the instruction would be the baker reading that step of the recipe, and executing would be physically putting the flour in the bowl.Tom Scott has a great video where he explains the Fetch-Decode-Execute Cycle:Program Counter & RegistersIn this analogy, how does the baker remember what step of the recipe he is on? Let’s say the recipe steps are numbered; he needs to use his brain to remember the step number he is on. Then, every time he moves to the next step, he increases the number he is remembering by 1. This is exactly what a CPU needs to do, but since a CPU doesn’t have a human brain, it instead has what are called Registers.Registers are small pieces of memory that can only store a small amount of information at once (let’s say just one number). So in this example, the CPU needs a register to remember what line of the recipe (program) it is executing. This little piece of memory (register) for keeping track of the location it is at has a special name called the Program Counter or PC for short. It is exactly the same as the baker keeping track of which step number of the recipe he is on; he is counting up just like the Program Counter.Binary & Hex RepresentationsSo we now know that CPUs store the step they are on in the Program Counter, but what do those steps look like? Computers don’t understand human language; they only understand 1/On and 0/Off (binary numbers).The steps of the recipe/program are called instructions, and they are indeed a series of 1s and 0s. However, humans are not good at reading long lines of 1s and 0s, and humans need to be able to program and understand computer instructions. So, although they are 1s and 0s to the CPU, we humans represent them as Hex Values split up into Bytes instead.A byte is just eight 1s and 0s in a row and could look like this to a CPU: 00000011, but humans find it easier to represent a single byte as a hex value instead, which would look like this: 0x03. The 0x at the start just tells us that it’s a hex value, so we know it’s not a decimal value. It is also sometimes written with a dollar sign instead, like this: $03, but we will be using 0x throughout this site.Instructions & OpcodesNow that we know we can represent CPU instructions as hex values, we can look at some real CPU instructions used by a number of common processors: 0x04 - In a Z80 CPU, this hex increments the B Register. Think of the B register as similar to the Program Counter, but it doesn’t just store where we are in the program; it can store whatever number you would like. 0xEA - In a 6502 CPU, this hex is called a No-Operation or NOP for short. Yes, doing nothing is a valid thing for a CPU to do-CPUs need time to relax too, you know!These are two examples of different CPUs from real Nintendo game consoles: the Z80 CPU was used in the Game Boy, and the 6502 was used in the NES.Note that in these two examples, the instruction was only one byte long. As you can imagine, one byte is not very much information, with only 256 possible values. So instructions can be many bytes long; the limit depends on which CPU we are talking about.But in all CPUs, the first byte is known as the Opcode and is used to determine how many bytes long the instruction will be.Also, just in case you start to panic and think you need to learn all sorts of different hex values and what they do, you don’t-emulator developers always have a reference for this nearby, and there is a much simpler way to write instructions known as Assembly Language. Most emulators, however, use the hex value in the CPU emulation loop to decode which instruction it should now execute.Opcode Mnemonics & Assembly languageMost humans find it easier to remember patterns of letters (mnemonics) than a set of hex values such as 0x45 0xFF 0xEA. The mnemonics used to represent opcodes are called Assembly Language, and they are normally just shorthand for what the operation does, e.g.: MUL - Multiplies two numbers ADD - Adds two numbers SUB - Subtracts two numbers BEQ - Branch (change location of Program Counter) if numbers are equal to each otherOpcode CategoriesNot all opcodes are created equal; some are for modifying RAM, others are for changing the location of the Program Counter (branching).For the 6502 CPU the reddit user mysticreddit suggests breaking the 56 instruction set down into categories 1: Load/Store - LDA, LDX, LDY, STA, STX, STY, TAX, TAY, TXA, TYA Arithmetic - ADC, SBC, CLC, SEC, INC, DEC, INX, INY, DEX, DEY, CMP, CPY, CPX Branching - BCC, BCS, BEQ, BNE, BMI, BPL, BVC, BVS Logic - AND, ORA, EOR Bit manipulation - ASL, LSR, ROL, ROR, BIT, CLC, SEC Misc - NOP Modes - CLD, SED, CLI, SEI, CLV Stack - PHA, PLA, PHP, PLP Flow Control - JSR, JMP, RTS, RTI, BRK Undocumented instructions - The CPU Vendor has never told anyone what these doPutting it all togetherHere is some pseudo code to piece together that we have talked about so far:var instructions = [0xEA, 0xEA, 0xEA,...]; // All the steps that make up our recipe/programvar programCounter = 0; // start at... well the start of the instructions arraywhile(true) { // loop forever and ever fetchedInstruction = instructions[programCounter]; // get the instruction from the array at the current step we are on (program counter) switch(fetchedInstruction) { // Now decode the instruction case 0xEA: // lets check if the opcode is 0xEA\t // Lets do nothing as this is a NOP (No-operation instruction) } programCounter = programCounter + 1; // go to the next instruction in the loop}Of course, this pseudo code would fail after we get to the end of the instructions array, but CPUs just keep going.Now that you understand the Pseudo code, you can look at how real emulators are implemented: NES - QuickNES_Core/Nes_Cpu.cpp uses a switch statement SNES - snes9x2010/cpuexec.c - snes9x uses a table lookup instead of switch statement N64 - mupen64plus-core/pure_interp.c uses multiple switch statements based on category of opcodeComplexitiesWe have covered CPU emulation at a very high level, simplifying the details to make it easier to understand, but note that CPU emulation is far from a trivial problem to solve.One of the reasons for complexity is that we are trying to simulate physical hardware-hardware with multiple chips working in parallel with each other.Whenever you have multiple tasks running in parallel, you encounter issues with timing, such as the audio processor being out of sync with the CPU, causing the sound to not match what would play on the real hardware.Cycle-accurate TimingsTiming units in emulators are referred to as cycles, so cycle-accurate timing is the gold standard in emulation and matches what the physical hardware would do.Most emulators don’t have cycle-accurate timing and rely on estimated timings which are good enough to run most software created for the hardware. The reason for this is that to get real cycle-accurate timing, you need to effectively emulate all sorts of very low-level hardware details, which requires both a lot of knowledge on the developer’s part and a lot of CPU time on the host machine running the emulator.For most emulators, this is fine, as users won’t notice such subtle timing differences and would prefer the emulator not to consume the entire CPU in the process. However, for true preservation of the original experience, cycle-accurate emulation is very important.Un-documented Opcodes/InstructionsCPUs are complex pieces of hardware, and not all opcodes have been formally documented for use by programmers. However, this doesn’t stop programmers from using instructions that have not been documented by the CPU vendor.This raises a question for emulator developers: what do all those undocumented instructions do? How many bytes do the instructions take up? How many clock cycles? To get a true answer, you need to try them on real hardware and inspect what the physical chips do at a low level. This is a non-trivial task.Most software written for a specific CPU does not use undocumented instructions, as the programmers probably don’t know what they do either. But there are a few retail games and software that use them for specific purposes, such as anti-emulation or anti-piracy.Emulating the MemoryAll systems you would want to emulate have a certain amount of RAM/memory where they store values that impact the running of the program. Variables such as the player’s score would be saved in this memory.A simple way to emulate a system’s memory is to use a large array of bytes, and whenever you need to read or write to a memory location, you access the specific index in the array.For example here is some pseudo code for that:var systemMemory = [0x06, 0x01...];var playerScorePointer = 0; // store the location in memory where the player score is stored// Lets read the value at position 0 (value of playerScorePointer) of the emulated system's memoryvar playerScore = systemMemory[playerScorePointer];// Now lets write a new score for the player, just add 1 because they got 1 more pointsystemMemory[playerScorePointer] = systemMemory[playerScorePointer] + 1;However, it is not quite this simple, as many systems use something called memory-mapped registers/variables. These are certain addresses of memory that, when either read from or written to, interact with some sort of input/output device, such as a game controller.So the CPU can be dumb and just write to a certain address, but the Memory Management Unit needs to be able to tell where that write should occur. Should it write to: High RAM Low RAM Save RAM (SRAM) Audio/Graphics RAMThese will all be different chips on the board but will all just be referenced by an address. So how does the MMU know which addresses point to which memory chips? This is where the memory map comes in handy.Memory MapsA memory map is a piece of documentation that is used to indicate which address ranges are used for what purpose. Here are some example memory maps for various consoles: NES - CPU memory map - NESdev Wiki SNES - Super NES Programming/SNES memory map - Wikibooks, open books for an open world N64 - Memory map detailed - en64 wikiYou will notice that for many game consoles and other systems, there are tons of memory addresses that are mapped to nothing at all. It seems like a huge waste of memory to emulate these unused addresses in a big byte array.So instead of a simple array for all of RAM, it might be better to have smaller arrays-one for each type of memory-and have specific read and write functions that handle going to the correct memory array.Here is some pseudo code after taking into account what was have said above:var HighRAM = [0x00,0x12, ...];var LowRAM = [0x00,0x12, ...];function read(addressLocation) { if (addressLocation > 0 && addressLocation <= 0xFF) { // Read from LowRAM\treturn LowRAM[addressLocation]; }// other if statements for HighRam and other pieces of memory such as SaveRAM, Cartridge ROM or controller input would go here}function write(addressLocation, valueToWrite) { if (addressLocation > 0 && addressLocation <= 0xFF) { // Write to LowRAM\tLowRAM[addressLocation] = valueToWrite; }// other if statements for HighRam and other pieces of memory such as SaveRAM or writing pixels to a screen would go here}Now that you understand the pseudo code, you can look at how real emulators are implemented: NES - QuickNES_Core/Nes_Cpu.cpp uses a bunch of Macros such as READ_LOW/READ_PROG SNES - snes9x2010/memmap.c atis an example of using multiple smaller arrays one for each type of RAMEmulating Graphics/VideoMany systems that you will want to emulate have some sort of graphical output, whether that is to a TV screen such as a CRT or a more permanent physical form via a device such as a printer.Every system handles graphical output in a very different way, so this section will only cover things that they have in common, specifically when talking about a CRT or other TV-like display.Just as we have the Central Processing Unit (CPU) to process system instructions and the Memory Management Unit (MMU) to handle system memory, for graphics we typically refer to the management interface as the Picture Processing Unit or PPU.The PPU normally renders a pixel at a time, but how do you know the color of that pixel? Well, you need to take into account all the background tiles, sprites, etc., that intersect at that pixel.PPU TimingBut what about timing? There is a risk that your emulated PPU will get out of sync with the emulated CPU, resulting in all sorts of weird behavior.The simplest way to solve this issue is to run both the PPU and CPU in the same thread and determine how many pixels are drawn to the screen per CPU cycle. That means you can run one CPU cycle, then call the PPU to draw that number of pixels, and so on in an infinite loop. The problem with this is that if the system you are emulating is more recent or powerful, you won’t have enough GHz on your host machine to emulate that system.Learning how to write your own emulatorsNow that you know the basics of how emulators work, you might be interested in writing your own. This section covers some useful resources available on the web to help you get started.Games and Interactive experiences on emulator developmentThere are a few “games” (or interactive experiences) that can teach the basics of emulator development and are a great way to start as they are very interactive so you can put the theory into practise straight away.EmuDevZ - A game that teaches you emulator developmentThis is a very unique game, it teaches you the basics of emulator development in a fun way, a browser game! It is a very good way to learn the basics:EmuDevzVideos on Emulator DevelopmentWhat better way to learn how to write your own emulator than by watching people write one themselves? This section will link to video tutorials on emulator development. Some are follow-along-at-home type, and others just mention the core concepts, but all are worth a watch if you are serious about emulator development.Apple II Emulator in React and Typescript Chris Torrence has put together an excellent series of videos in which he writes an Apple II emulator from scratch that will run in any modern web browser! Unlike our for loop in the CPU pseudo code we listed above, his system uses the JavaScript setTimeout series of functions instead, but it is equivalent. It is better to use setTimeout when running inside a web browser so the browser can handle other actions instead of waiting forever for the emulator to finish the loop. Also, instead of using a switch statement like we did above, it is a table lookup based on the opcode, but it is functionally equivalent. A very cool feature of his emulator is it has an embedded 6502 assembler inside it, so he can easily write tests with 6502 assembly code and run them straight inside his emulator! NES Emulator from Scratch by javidx9 javidx9 has created an excellent series where he dives into the world of NES emulator development. Commodore 64 Emulation in JavaScript - Imran Nazar - NDC London 2022 Imran Nazar goes over how and why he created a Commodore 64 emulator in Javascript. It is a very good introduction to the concepts of emulators such as the CPU loop, MMU and PPU but doesn’t go into the specifics for how his emulator works in terms of code. Creating a NES emulator in C++11 Bisqwit holds a live coding session where he writes a NES emulator using features new to C++11. Make sure to enable subtitles for this video as that is where all the description is, there is no narration for this video. It is split into two 30 minute videos and can be a little hard to follow reading the subtitles and watching the code editing at the same time but it has a charm to it. ZX Spectrum emulator from scratch using C# and BlazorØredev Conference features a presentation by Jimmy Engström detailing his personal history with the ZX Spectrum and his journey to build an emulator for it. He dives into the technical challenges of emulating the Z80 CPU instructions, memory management, and screen rendering, eventually demonstrating how he ported the project to the web using C# and Blazor WebAssembly with AOT compilation for performance.Useful Tools for Emulator DevelopmentGameboy Doctor: Emulator Debugging ToolGameboy Doctor is a utility designed by Robert Heaton to assist developers in debugging their custom Game Boy emulators. Instead of fixing ROM files, this tool compares the execution logs of a user’s work-in-progress emulator against reference logs from a known-good implementation. This process allows developers to pinpoint the exact CPU cycle where their emulator diverges from correct behavior, making it significantly easier to diagnose faults and pass standard test suites like Blargg’s. Gameboy Doctor: Compare Emulator Logs Robert Heaton has released Gameboy Doctor, a debugging utility that compares emulator execution logs against reference data to isolate CPU state divergences. References Are there good books/resources/guides on Emulator Architecture and how to structure your projects? : EmuDev ↩ ", "excerpt": "Have you ever wondered how emulators work? How would you implement an emulator? Where should you start if you are interested in emulator development? This post attempts to answer all those questions. Introduction to Emulators Emulators are computer programs that run on one system, such as a PC or game...", "tags": ["introduction"], "image": "/public/images/articles/How Emulators Work.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "How to reverse engineer a microchip", "url": "/how-to-reverse-microchip", "content": "In this tutorial from Robert Baruch on his youtube channel [], the target chip used in the video series is the Texas Instruments 74LS01 Logic gate from 1986.First step - photos before recappingBefore de-capping the chip it is important to take photos of the top and bottom markings of the chip so you can refer to them later. The next step is decapping which will likely destroy much of the markings that you might need to refer to later 1.You can do this with a microscope and any camera you happen to have, phone camera should be fine, as long as it isn’t too low resolution to read the markings.Process of De-capping a chip (Heat decapsulation)The next step is to De-cap the chip which was covered very thoughrally in Robert Baruch’s video below 2:Imaging a chipIn order to take high quality images of the newly de-capped chip we need to find a way to attach the bare die to the microscope, basically to make sure it doesn’t move in the process of imaging. One handy way to hold the die is the lids if you still have them from the de-capping process. Glue to die to one of the lids, just make sure you glue the side you don’t want to image!While you are waiting for the glue to dry you could be really organised and create a label with the chips reference information on it (chip number etc) and attach the label to a small container.When the glue has dried you just need to make sure that the lid doesn’t move during imaging, as it is a lot bigger than the tiny die it should be more stable and less likely to move, but you can create a 3d printed holder if you want to be professional!Photo timeNow the chip should be ready to be photographed, move the microscope to the start of the chip and keep creating images with a 50% overlap. To make this easier you can use a Beagle bone driver and machine kit to automatically handle this for you.Each picture is 600 micrometers by 400 micrometers with a 50% overlap on each picture.Lets get stitchingNow that you have the images it is time to stich them together, to do this you can use Microsofts Image Composite Editor (ICE), select the images and the various parameters such as 50% overlap and let it work its magic!If you want a sharper image you can run it through Microsoft photo editor to increase the contrast.Delayering the chipYou will notice that the particular chip in the video tutorial has a lot of metal covering the details. So it’s time to delayer the chip.To do this you can: Use Armor etch to get rid of some of the glass Put in a solution of 6 parts 3% hydrogen peroxide with 1 part 32% hydrochloric acid for about 15 minutes Use Armor etch again to get rid of more glassNow you can repeat the imaging process from above with the delayed chip.Creating a VectorYou can now trace the image created in a tool such as Inkscape and add labels for each pin and component and trace along the resistors etc.Other talks and resourcesChris Gerlinsky’s talk at RECON 2019 on optically preserving Mask ROMS(The ROM Matrix Revolution Unscrambling Bits)[https://recon.cx/media-archive/2019/Session.002.Chris_Gerlinsky.The_ROM_matric_revolution_Unscrambling_bits-K0W7zZQDK9lQQ.mp4]LACED: Laser-Assisted Controlled Etching and DelayeringLACED is a novel methodology developed by LawrenceBrode for delayering multilayer PCBs using accessible, low-cost equipment (under €200). The technique combines a standard 5W diode laser with chemical etching to achieve micron-level precision (3.5–10 µm), offering a viable alternative to industrial FIB systems for home-lab reverse engineering. LACED: Affordable High-Precision PCB Delayering LawrenceBrode details a comprehensive guide on using laser ablation and chemical etching to precisely delayer PCBs for hardware analysis without expensive machinery. References How I reverse engineer a chip - YouTube ↩ Decapsulating a ceramic integrated circuit - YouTube ↩ ", "excerpt": "In this tutorial from Robert Baruch on his youtube channel [], the target chip used in the video series is the Texas Instruments 74LS01 Logic gate from 1986. First step - photos before recapping Before de-capping the chip it is important to take photos of the top and bottom markings...", "tags": ["introduction","hardware"], "image": "https://i.ytimg.com/vi/r8Vq5NV4Ens/sddefault.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "ILBMViewer - Deluxe Paint Image Viewer Online (.LBM and .ILBM)", "url": "/ilbm", "content": " Drop ILBM or LBM files here to view ", "excerpt": "\n\n\n \n\n \n Drop ILBM or LBM files here to view\n \n \n \n \n\n \n \n \n", "tags": ["tools","deluxepaint"], "image": "/public/images/RetroReversingLogoSmall.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Incomplete Reversing Pages", "url": "/incomplete", "content": "Incomplete pagesThese are pages with the tag incomplete, this normally happens on pages that try to cover a large topic but we don’t have the time to complete analysis for the whole topic. This commonly happens when covering leaked source code due to the huge number of files that are in these archives.We start the pages with what we feel are the most interesting aspects and leave it up to the community to help us complete the pages in the future.All Posts N64 MIPS Assembly Video Tutorials Introduction Fraser N64 has created a series of YouTube videos where he teaches N64 MIPS programming from the ground up. This page is designed to act as notes as you... ... Read More n64 assembly tutorial incomplete ", "excerpt": "Incomplete pages These are pages with the tag incomplete, this normally happens on pages that try to cover a large topic but we don’t have the time to complete analysis for the whole topic. This commonly happens when covering leaked source code due to the huge number of files that...", "tags": ["incomplete"], "image": "/public/generated/placeholders/incomplete.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Life in the Games Industry", "url": "/industry", "content": " Have you ever wondered what it was like to be a developer in the games industry in the 80s/90s/00s? This page collects documentaries, interviews, magazines, conference history, and company pages that help reconstruct what day-to-day work in the games industry looked like. It is intended as a hub page rather than a complete chronology, so the goal is to point toward the best material we know about and split deeper topics into their own dedicated posts where needed. If you know of any other footage or information that should be added to this page please get in touch. There must be more out there. Documentary FootageThis section collects documentaries and broadcast segments that show how studios were organized, how developers worked, and how the wider business looked at the time.1984 - Life in Imagine & Ocean Software (The Battle for Santa’s Software)Commercial Breaks was a 30 minute documentary series in the UK about businesses and one episode in particular from 1984 is of interest to this site, it was called “The Battle for Santa’s Software”. It followed two British software companies, Imagine software and Ocean, only one remained at the end of the show!On the Imagine Software side Mark Butler was 23 when the documentary was filmed and it shows his extravagant lifestyle with his fast cars and sponsored motorbike teams. He had 70 people working for them in May 1984 and John Gibson was the only programmer over 30 (Known as Granddad).The documentary starts with Imagine Software looking great and anticipating the next big game, but sadly ends with bankruptcy. This documentary is great for showing the uncertainty in the early games industry, one minute you are on top and gone the next.Fortunately, former programmers at Imagine Software went on to establish Psygnosis, known for the Psy-Q development SDKs.On the other side was Ocean Software and David Ward who managed to survive the time it took to film the documentary and showed off some of their upcoming games for the festive period.You can find more information about this documentary over on VHiStory: Commercial Breaks - Film 84 - Tomorrow's World - Micro Live - tape 1 VHiStory provides additional background on the 1984 documentary episode that covered Imagine Software and Ocean Software. 1993 - A Visit to id Software (November 1993)This video captures id Software shortly before the release of DOOM, making it a useful snapshot of early 1990s PC game development culture.1993-1995 - Working at SEGA Documentary (Careers for the 21st Century)This rare documentary was part of Careers for the 21st Century by Takeoff Multimedia, it shows what life was like as a developer working at SEGA between 1993 and 1995.To find out more we have a separate post all about it here: Working at SEGA Documentary For more information on working at SEGA check out this post. 1996 - GRAND THEFT AUTO - Making Of - GTAFrom the BBC show Working Lunch the reporter Rory Cellan Jones visits the Dundee studios of DMA Design in 1996 as they are working on the Original Grand Theft Auto:They interview people in programming (David Kivlin), music (Craig Conner), sound effects, and QA (Gordon Ross and Fiona Robertson), and there is a brief view of the motion capture department during development.Game Industry Research MaterialsWhen researching a video game, for reverse engineering or otherwise it can be tricky to find all the relevant sources due to most development being done behind closed doors in a time before the internet was the force it is today. So it is important to keep track of the physical media such as magazines, books and conference proceedings as they contain many information that has never been released to the internet.MagazinesBefore widespread access to the internet was common, many game developers would buy magazines to keep up with the latest in the industry and development in general. We have a post covering the most relevant magazines: Retro Gaming & Development Magazines (Games Industry) For more information on all the Game development magazines check out this post. Develop - UK Magazine dedicated to the games industryDevelop was a magazine published in the UK targeted at games industry professionals. Similar to the US magazine Game Developer, it provides a unique insight into game engines, SDKs, and middleware that was never published online. Develop (UK) Game Development Magazine/Journal For more information on the UK magazine Develop check out this post. BookazinesDue to the sheer number of magazines being published in the late 2000s, Publishers realised they could collate all the material from their monthly magazines into yearly publication.This resulted in a rather thick magazine with no advertisements about the size of a book but with the print quality of a magazine, hence the industry dubbed them bookazines.We have an entire page dedicated to just Bookazines related to game development and the technical creative industry as a whole here: Bookazines (Games Industry) For more information on all the game development Bookazines check out this post. Conferences - GDC, E3 and other games industry related conferencesOne of the main ways for different game developers to speak to each other was at yearly conferences such as GDC or Siggraph: Game Industry Conferences For more information on all the Game industry Conferences check out this post. Books - Game Development, 3D general games industry booksBooks were a must have for any game developers getting started in the industry, from teaching the basics of assembler/C to more advanced topics such as 3D rendering: Books (Games Industry) For more information on all the Game development Books check out this post. Museum and Preservation ProjectsThis section collects interactive preservation projects that try to recreate part of the material culture around video games rather than just documenting code or binaries.AUTO MUSEUM 64Built in Unity Auto Museum 64 is a virtual Museum of 3D Vehicles from a variety of Nintendo 64 games.It was built by leoburke and is available on Itch.io: Auto Museum 64 by leoburke A downloadable virtual museum built in Unity that lets you inspect 3D vehicles from a range of Nintendo 64 games. This kind of experience is very cool, but it would be even better in the browser, for example via WebGL. It is the kind of thing people may only visit occasionally, but it would be much easier to share and preserve as a simple web link.Hopefully this will be the start of more Virtual museums that showcase 3d models or even maps from 3D video games.Virtual Game ShopSpecialist game shops were an important part of games culture for decades, especially when boxed software, demo kiosks, strategy guides, and magazine racks all existed in the same physical space.A careful virtual reconstruction of that environment could be a useful preservation project in its own right, especially if it documented how games were displayed, marketed, and sold across different eras and regions.Found some more images & information on the Blockbuster Games concept; and it's companion store (in the next post), Blockbuster Music, in 'Stores of the Year 9' (1995)It was located in Jacksonville, FL; designed by Fitch Inc. in 1994. pic.twitter.com/TtUyUAw9r7— Evan Collins | BLM 🏳️‍🌈 (@EvanCollins90) July 4, 2020Commercial Documentary CataloguesSo far we have listed documentaries that are freely available on youtube, mostly from TV broadcasts, but for a list of video game industry documentaries that you can buy check out IMDB’s list: Video Game Documentaries IMDb hosts a broad list of commercially released documentaries related to video game history and development. Interviews and Oral HistoriesOne of the best sources of information for how retro games were developed are direct interviews with the programmers themselves. This section lists interviews available online, but for even more interviews check out the magazines section above.The Untold History of Japanese Game Developers DVDsDVD produced for the Kickstarter for the book The Untold History of Japanese Game Developers back in 2013: The Untold History of Japanese Game Developers DVD 1 The first Kickstarter bonus DVD collects long-form interviews with Japanese game developers discussing their careers and production history. DVD 2: The Untold History of Japanese Game Developers DVD 2 The second DVD continues the interview collection and includes useful discussion of tools, reverse engineering, and day-to-day studio work. Of particular note is in the second DVD:Enix programmer Toru Hidaka learned to program by reverse engineering the machine code of Cosmic Soldier, and went on to program games, create graphics, sound and compression utilities for Enix, write books on using machine code, and assist in teaching a new generation of programmers.It also shows a development utility created to help designers build levels for Gandhara on the PC-88, where the numbers indicate enemy placement.CompaniesThe games industry is made up of many companies, some as small as a single person and others so large they generate billions in revenue annually. There are so many that have come and gone over the years that we can’t write about them all. Instead we focus on companies that pushed the boundaries in terms of the underlying technology, companies that most gamers may never have heard of but that made considerable technical achievements. Companies that defined iconic game engines such as Krome’s Merkury, others such as SN Systems or Cross Products that created the game development tools that were used by most of the industry.Others used their technical expertise on the unauthorized side by creating products that could run unofficial code on retail hardware, such as Datel’s Action Replay line of cheat devices.Game Development Tooling CompaniesThere are a bunch of notable companies related to retro game development, many of which specialized in creating the Software Development Kits for popular consoles such as the Mega Drive (Cross Products) or PlayStation 1 (SN Systems).Cross ProductsCross Products was a British company specialized in creating development tools for game programming, founded in 1989 by Ian Oliver and Andy Craven. It was a collaborative venture between two UK game companies, Realtime Games Software and Vektor Grafix. Cross Products created cross-platform development tools and kits especially for consoles during the late 80s and early 90s. Cross Products (Creator of Development Tools) For more information about Cross Products check out this post. SN SystemsSN Systems is a company that specialised in creating development tools for game developers in the UK, it created development tools for Sega and Nintendo consoles but is most famous for their Sony PlayStation development tools like PSYQ. SN Systems (Creator of Development Tools) SN Systems is a company that specialised in creating development tools for game developers in the UK, it was founded in 1989 by Martin Day and Andy Beveridge 1. Martin... Game Hacking CompaniesThere are a bunch of notable companies related to game hacking which not only worked on cheat devices like the Game Genie or Action Replay but also built unlicensed products that enabled homebrew on retail consoles, much to the annoyance of the console manufacturer.DatelDatel is most famous for their Action Replay line of products but also created homebrew enablers for the Gamecube and Nintendo DS along with tons of unlicensed games and applications for a wide range of home consoles and handhelds. Datel For more information about Datel check out this post. CodemastersCodemasters is best known for its unlicensed NES work, the Game Genie, and its broader role in shaping the home computer and console market in the UK. It is also a useful case study in how a commercial game studio could overlap with hardware add-ons, cartridge publishing, and unauthorized console development. Codemasters (Creator of the Game Genie) For more information about Codemasters check out this post. Game Development PostmortemsOver the years game developers have posted “Postmortems” of their games, listing the good and bad parts of the development process, these were often given as talks at GDC or published in the physical Game Developer magazine.2003 book Postmortems from Game DeveloperIt is a collection of 25 postmortem articles originally from Game Developer magazine. Based on the published table of contents, these are the included games and their primary original platforms. Most chapters are about Windows PC development, but I have listed the main release platforms relevant to the era if the game was ported 1. Game Primary Platform(s) System Shock 2 PC (Windows) Operation Flashpoint PC (Windows) Drakan: Order of the Flame PC (Windows) Cel Damage Xbox (later ported to GameCube, PS2) Vampire: The Masquerade - Redemption PC (Windows) Age of Empires PC (Windows, Mac later) Diablo II PC (Windows, Mac) Unreal Tournament PC (Windows, Mac, Linux), Dreamcast, PS2 Command & Conquer: Tiberian Sun PC (Windows) Age of Empires II: The Age of Kings PC (Windows, Mac later) Myst III: Exile PC, Mac Tropico PC Black & White PC (Windows, Mac later) Myth: The Fallen Lords PC, Mac Thief: The Dark Project PC Trespasser PC Deus Ex PC, Mac, PS2 Jak and Daxter: The Precursor Legacy PlayStation 2 Star Wars Starfighter PS2, Xbox, PC Star Trek: Voyager - Elite Force PC, PS2, Mac Rainbow Six PC, Mac, N64, Dreamcast, PS1 Soldier of Fortune PC, Dreamcast, PS2 Dark Age of Camelot PC FireTeam PC (online multiplayer) Asheron’s Call PC Interviews with Game Developers (by platform)This is a collection of known interviews with game developers who developed retail (and sometimes unlicensed) games while the console was still on the market.Commodore 64The table below lists the relevant entries. Source Developer Games Description Retro Gamer issue 5 Protovision Metal Dust, Tanks 3000, Pac It The members of Protovision discuss their work developing games for the Commodore 64. The interview mentions several of their games. Retro Gamer issue 95 Shaun Hollingworth Firelord Shaun Hollingworth worked at Teque London and developed the Commodore 64 game Firelord. Nintendo Entertainment System (NES)The table below lists the relevant entries. Source Developer Games Description Retro Gamer issue 11 Color Dreams/Wisdom Tree Bible Adventures This interview features developers from Color Dreams/Wisdom Tree, discussing their unlicensed, religious-themed NES games. Nintendo 64The table below lists the relevant entries. Source Developer Games Description Retro Gamer issue 9 David Doak GoldenEye 007 Doak is known for his work on GoldenEye 007 for the Nintendo 64. Nintendo WiiThe table below lists the relevant entries. Source Developer Games Description Retro Gamer issue 45 Yuji Naka and Takashi Izuka NiGHTS into Dreams, Journey of Dreams Discuss the making of NiGHTS into Dreams and its sequel, Journey of Dreams for the Wii Xbox consolesThe table below lists the relevant entries. Source Developer Games Description Retro Gamer issue 39 Developers at Rare Jetpac Refuelled Discuss the making of Jetpac Refuelled for Xbox Live Arcade Recruitment in the games industryThis section collects smaller notes on how developers found work and how studios staffed projects in different periods.How did game programmers find work?Many Game Boy developers worked freelance and were contracted out by companies to work on a title with a harsh deadline of a couple of months or sometimes even just weeks! Others were hired full-time by companies and would work on a constant stream of new games.Jas Austin was one of the developers who started off freelance on the Game Boy version of R-Type but did such a good job that he accepted a full time job a B.I.T.S 1.He heard about the job through his agent which was a common way for game programmers to find work in the late 80s to early 90s. But by the 2000s games had grown so much that they would require whole teams of developers and hiring freelances who worked from home became rarer.Industry Legends and RetrospectivesRemembering Archer Maclean (1962-2022)Mamemeister presents a retrospective on the life and work of Archer Maclean, a renowned programmer known for pushing the technical limits of 8-bit and 16-bit hardware. The video discusses his most famous works, such as Dropzone and International Karate +, and shares personal anecdotes about his passion for arcade hardware and game development.Platform Holders and Independent DevelopersThis section covers how console manufacturers viewed outside developers, unlicensed publishing, and later indie support.Why Nintendo restricted third-party developers in the 1980sWhen Nintendo prepared to launch the Famicom in the United States, it was entering a market still shaped by the North American video game crash. The company wanted tighter control over software quality, publishing volume, and licensing than many earlier platform holders had exercised.Hiroshi Yamauchi, Nintendo’s president at the time, believed part of the collapse came from a flood of low-quality third-party software:That attitude helps explain Nintendo’s stricter licensing model, manufacturing control, and technical lockout measures in the NES era.Nintendo also deployed a range of hardware and software restrictions to limit unauthorized publishing and preserve control over the platform ecosystem.For many years this made Nintendo comparatively cautious about homebrew and unofficial development compared with the later PC and mobile ecosystems.Later Shift Toward IndiesThat position softened much later, once downloadable storefronts and successful independent releases showed that smaller external teams could strengthen a platform rather than dilute it.Automatically Listed Industry PagesThis final section is generated from site tags, so it works as a wider catch-all index beyond the curated sections above: Bookazines (Games Industry) What do you call a product that collects articles from monthly magazines into a single yearly publication? The publishers came up with the term “Bookazine” to cover this concept of... ... Read More bookazines magazines books industry Books (Games Industry) Awesome list of Historic Retro Games Industry Books and their impact on the industry ... Read More industry Codemasters (Creator of the Game Genie) History of Codemasters Codemasters is a British video game developer and publisher known for its long history in the gaming industry. It was founded by brothers Richard and David Darling... ... Read More companies industry Game Industry Conferences Awesome list of Historic Retro Games Industry Conferences including Audio and Video recordings ... Read More industry Copyright Infringement in the games industry The practice of game cloning in arcades and consoles goes back to the industry’s origins – to take a quote from a 2001 issue of the Japanese CONTINUE magazine 1:... ... Read More industry legal copyright Develop (UK) Game Development Magazine/Journal Develop Develop was a UK magazine dedicated to game developers in the industry similar to the US magazine Game Developer, it published 11 issues a year, one a month except... ... Read More industry magazines Game Developers Conference (GDC) - Full list of historical sessions Awesome list of Historic GDC Conferences including Audio and Video recordings ... Read More industry Game Cracking Software used back in the day A quick look at software used to crack early games industry titles such as SoftICE, W32Dasm and OllyDbg ... Read More software industry GameMaker (UK) Game Development Magazine GameMaker was a unique magazine first published by Future PLC in the UK in October 2003. It was a game development and modding magazine targeted at the general public! It... ... Read More industry magazines Hacking Hacking History 1988 - MORRIS: Earth’s First Computer Worm Disrupt has published a retrospective on the Morris Worm, detailing the specific vectors exploited by the 99 lines of code written... ... Read More industry hacking Retro Gaming & Development Magazines (Games Industry) Awesome list of Historic Retro Games Development Magazines and articles ... Read More industry Retro Gamer Magazine - List of Interviews and Notable issues Retro Gamer is a British magazine devoted entirely to classic video games, first launched in January 2004 1. Over the past 20+ years it has grown from a niche quarterly... ... Read More industry magazines Working at SEGA Documentary Working At SEGA Documentary This rare documentary was part of Careers for the 21st Century by Takeoff Multimedia, it shows what life was like as a developer working at SEGA... ... Read More industry documentary megadrive sega Cross Products (Creator of Development Tools) History of Cross Products Cross Products is a company that specialised in development tools for game programming, located in the UK and founded in 1989 by by Ian Oliver and... ... Read More companies industry crossproducts Datel Introduction Datel Design & Development Ltd., commonly known as Datel, was founded in 1980. They are known for producing unlicenced video game peripherals, cheat devices, homebrew enablers and other gaming... ... Read More companies industry datel SN Systems (Creator of Development Tools) SN Systems is a company that specialised in creating development tools for game developers in the UK, it was founded in 1989 by Martin Day and Andy Beveridge 1. Martin... ... Read More companies industry snsystems References Terminator 2, R-Type, Altered Beast with Jas Austin - The Retro Hour EP320 - YouTube ↩ ↩2 ", "excerpt": "Have you ever wondered what it was like to be a developer in the games industry in the 80s/90s/00s? This page collects documentaries, interviews, magazines, conference history, and company pages that help reconstruct what day-to-day work in the games industry looked like. It is intended as a hub page rather...", "tags": ["industry","companies"], "image": "/public/images/RetroReversingLogoSmall.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Intellivision Reverse Engineering", "url": "/intellivision", "content": "IntroductionWelcome to our page dedicated to Intellivision reverse engineering! The Intellivision was a classic gaming console released by Mattel Electronics in 1979, and has since become an iconic symbol of the early days of home gaming. If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to the right place. On this page, we’ve compiled a list of links to other pages that cover various topics related to Intellivision reverse engineering.Whether you’re interested in understanding the hardware architecture of the console, analyzing game code, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to.So grab your Intellivision controller, and get ready to dive into the exciting world of Intellivision reverse engineering!The Story of The Mattel IntellivisionNewsmakers Games has released a comprehensive retrospective detailing the hardware development and history of the Mattel Intellivision. The video covers the console’s inception as a direct Atari competitor, its reliance on a General Instruments chipset, and the technical ambitions behind the ill-fated “Keyboard Component” intended to upgrade the system with a 6502 processor and 16K of RAM. It also provides a great look into the system’s pioneering controller design and its early push into complex simulation software like Utopia.Software Development for IntellivisionEver wondered what it was like to develop Intellivision games back on the day? The user decle on the AtariAge forum has put together an excellent pdf covering almost everything you would ever want to know about it:Intellivision development, back in the day - Intellivision Programming - AtariAge Forums", "excerpt": "Introduction Welcome to our page dedicated to Intellivision reverse engineering! The Intellivision was a classic gaming console released by Mattel Electronics in 1979, and has since become an iconic symbol of the early days of home gaming. If you’re interested in learning more about the technical aspects of this console...", "tags": ["console"], "image": "/public/generated/placeholders/intellivision.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Beginners Guide to Reverse Engineering (Retro Games)", "url": "/tutorials/introduction", "content": "This guide is for all beginners who are interested in learning more about the technical details of their favourite consoles and games. The guide aims to be as console-agnostic as possible, but after you have completed this you should look into the details of the specific console you are interested in.Lesson 1 - What? Why? How?Many people are confused about what exactly is involved in reverse engineering or why exactly people would “waste their time” on such a task. Well, let’s find out…What is Reverse engineering?Presumably by being on this page you at least have a slight idea about what reverse engineering is and may even have some pre-conceptions.At the end of the day it really is what it says on the tin, “Reverse engineering” taking the engineering process in reverse from finished product to learn how it was made.A reverse engineer is a scientist that studies man-made object rather than natural phenomena.Why reverse retro games?OK, but why exactly would people spend their time reverse engineering an old game instead of creating brand new games?There are many reasons for this such as pure nostalgia and preservation of a part of our modern history, the same way people study traditional art, studying games is a rather obscure version of appreciating human history.When a game is reverse engineered it becomes open to new life, new levels, sounds and more hours of fun. Reversing is like a game inside the game, when you have finished playing the game the fun of reversing can begin!Why learn reverse engineering?It is almost guaranteed to make you a better programmer, you are studying the code of very intelligent developers and you can learn from both their genius and their mistakes.Not only that but you will start to understand in depth how computers work and it can help protect your own games from hackers and may even start you on a path learning about cyber security and malware protection.Consider this: There are many devices that you use daily, like physical gadgets or computer programs, but most people don’t have the skill to look inside them to check if they might invade your privacy or have flaws that could make you less safe. Reverse engineering gives you the skill to be able to check for security flaws and tracking functionality that companies often don’t disclose to the public.What is the benefit to having reversed a game?🏆The most obvious benefit is to allow people to get more from their games, enjoy more hours in their favourite games, get that nostalgic buzz!Whether that is translating a game into a new language, improving the sound or visuals, or porting a classic game to a more modern system, you are bringing the enjoyment that this game gave to you to brand new audiences.It might not exactly be saving lives in the traditional sense, but the hours of joy you can bring to gamers old and new is priceless.Is reverse engineering legal?⚖️Yes, in fact there are many cases where the courts have sided with the reverse-engineer when it comes to anti-competitive practices.If you are interested there are a few court battles that are relevant: SEGA vs Accolade Sony Computer Entertainment, Inc. v. Connectix Corp. - WikipediaIn fact, reverse engineering already plays a vital role in ensuring your freedom in an increasingly more technological society. How do you know a voting machine is accurately counting your vote? Or how do you know if your computer is spying on you? You could reverse engineer it and find out.Lesson 2 - Introduction to Data Structures & FormatsPresumably if you have read this far you are interested in learning at least the basics of reverse engineering, how exciting! Trust me you will absolutely love it when you get started and in fact it can be a little addictive…ROM filesLet’s start at the beginning, you might have seen ROM files before, well actually I can safely assume you HAVE used a few of them in your favourite emulator.But what exactly are ROM files? How did that big plastic cartridge become a single file that can be run into an emulator? Let’s find out! How Retro Cartridges (ROMS) work Have you ever wondered how a game cartridge for Game Boy or the NES actually works? Find out here! ISO files💿ISO files are sometimes incorrectly called ROMs and technically they are a copy of data that was on a Read-only memory format but there are some fundamental differences between them.If you are unaware ISO files are copies of the data on a CD, DVD or Blu-ray Disc. Thus one of the major differences between this and a ROM file is it actually is a standard file format that can be opened in a tool such as Windows Explorer or Apple Finder and you can explore all the subfiles inside.It is generally easier to find graphics, sounds, maps, videos and such in ISO files as they tend to be individual files with a useful file extension. Although this is not always the case as many games engines like to pack up all their files into a single or multiple compressed files.Bits & Hexadecimal As we have said before games are just a series of 1’s and 0’s so we could look at your favourite ROM or favourite ISO file in this way and you could, with enough time, find out what each bit represents. However, humans are not very good at distinguishing parents of bits, so we have a much easier way to view these files in a format called Hexadecimal! In Hexadecimal every single Byte in a ROM or well any file on a computer can be represented as 2 digits using the numbers 0->9 and the letters A->F. Don’t worry you will not need to learn how to convert to Hexadecimal, there are plenty of tools for that, and you will pick up the most common Hex codes as you go along. In fact you may have already seen Hexadecimal if you have worked with Colours as they can be represented as 3 different bytes (Red/Green/Blue), each one of those bytes can be represented as 2 hex digits for example #FFFFFF (White). Viewing files with a Hex editor📄Now that you know why the Hexadecimal notation is useful for developers to represent bytes, let’s use a tool that every reverse engineer has handy at all times, the HEX editor!As we know a game is build up of either a single file (ROM) or multiple files, but at the end of the day they are all files and all contain bytes of data.So we know know that we can represent each byte as two Hexadecimal digits, why don’t we open up some of those game files!Depending on your platform there are multiple good HEX editors to choose from, but here are just a few: ImHex (Windows / macOS / Linux) – Free and open source rehex (Windows / macOS / Linux) – Free and open source HexWalk (Windows / macOS / Linux) - Free and open source 010 Editor (Windows / macOS / Linux) – Proprietary and closed source WinHex (Windows) – Proprietary and closed source HIEW (Windows) – Proprietary and closed sourceSome ROM hacks are done purely with a HEX editor and emulator so this is a powerful tool to get you started, but there are many other useful tools to learn along the way to make it even easier.So go on give it a try, open your favourite ROM in a Hex editor and see what you can find!File Formats Files come in many different formats, for example an image format such as JPG is very different in structure from an executable file such as a Windows Executable. Files tend to have an extension such as .jpg or .exe but this does not always match what is actually contained inside the file. There are so many file formats out there (and many variations) that you couldn’t possibly know them all, so its best to just learn what you need when you need it. Most standard formats are well documented online and for the others that may be custom to a specific game or application we can reverse engineer the assembly code of how the software reads (or writes to) the file. Magic Headers & the file command🪄Now you know the basics of how data can be represented you can dive into many different file formats used in games. You can view them in Hexadecimal with a Hex Editor and you can spot the Magic Header (if the file has one). This can be very useful for looking at files in ISO files, especially if they do not have a file extension.The Magic Header for a file tends to be the first few bytes of the file, for example WAV sound files start with the first 4 ASCII characters WAVE.Wikipedia has a useful table of the most common file formats and what their Magic headers are:List of file signatures - WikipediaSo you could open your file in a Hex editor and search that page for what file type it is. But there exists an even easier solution, systems based on UNIX come pre-installed with a useful tool called file which can tell you what a file contains regardless of its extension.An example of using file:file ./folder/unknownfile.datCustom File formats📄Many files used in games could be a custom format created specifically for that game (or engine), understanding how to decode these custom file formats is a vital skill that is worth learning.We will cover how to reverse engineer a custom file format in a later lesson, but for now you might be surprised how many games contain standard well-documented file formats on their CD’s or Floppies.Strings are your friend When looking at custom file formats or even just executables, one of the most valuable pieces of data in these files are Text Strings, especially if they are in standard ASCII or UTF-8 format. There is a really easy way to dump out all the ASCII strings in a file using the strings command like so: strings your_file_name Game Audio and Music🎧A core part of all video games is the Audio, whether as background music or sound effects, finding out how the sound system works for your chosen game can be fascinating. We have a separate post covering Game Audio and Music reversing and file format information. Introduction to Audio/Music Programming of Retro Games For more information about Game Audio check out this post. Memory Dumps🧠Instead of relying on an infinite number of random attempts to find hidden codes or features, memory dumps provide an efficient way to access and analyze software. It allows for systematic reverse engineering (RE) of the software to uncover “secret” codes that may only be available in memory.Knowing how data is structured in memory is a crucial skill to be able to tear apart how software works and ultimately learn about any hidden functionality, security issues or privacy violations.A practical example is the Nokia 5210 cell phone’s security code. While the manufacturer claimed it was unbreakable, memory dumps revealed a secret sequence (*3001#12345#) to unlock the phone. This discovery can be beneficial to end users who want to unlock their phone or even just for users to know that its possible.Data Representations🔣The exact representation a game uses will vary based on the compiler used, system its developed for and even programmer preference.Here are the most common data representations: Single Character (e.g the letter A) - Single byte ASCII ASCII Text (e.g the string ‘Hello’) - One Byte per character and normally ended with a Null Terminator 0x00 UTF-8 Text (e.g the string ‘Hello’) - A variable number of Bytes (1 to 4) per character and normally ended with a Null Terminator 0x00 Boolean - Either 1 Byte, 4 Bytes or occasionally 1 Bit (along with 7 other boolean bits) Integer/Short - 2 Bytes (16Bit systems) or 4 Bytes (32Bit systems) Long - 4 BytesEndianness🔀Endianness refers to the byte order or how multi-byte data is stored in memory. It’s important to understand endianness because games often need to work with data structures that span multiple bytes, such as integers or color values.There are two main types of endianness: Big-Endian - In a big-endian system, the most significant byte (the “big end”) of a data word is stored at the lowest memory address, and the least significant byte (the “little end”) is stored at the highest memory address. It’s like writing numbers from left to right, with the most significant digits on the left. This is the order you’d naturally expect when reading a number. Little-Endian - In a little-endian system, it’s the opposite. The least significant byte is stored at the lowest memory address, and the most significant byte is stored at the highest memory address. It’s as if you were writing numbers from right to left, with the least significant digits on the right.If you’re developing a game on a little-endian PC but targeting a big-endian games console, you’d need to swap the bytes when loading or saving data. This byte-swapping can be essential when working with things like color values, sound samples, or binary file formats that need to be read and written correctly.Additionally, some retro consoles, like the Sega Genesis, used a mixture of big-endian and little-endian data formats, adding another layer of complexity. Understanding the specific endianness of the target console and adapting your code accordingly is crucial for retro game development to ensure that data is interpreted correctly, graphics are displayed accurately, and sound is played as intended.Memory Pointers➡️When inspecting a game’s memory it is important to know that the address where the data is stored will change from run to run. So for example if you know the lives is stored at a particular address in memory, if you restart the game you may find that it is stored in a completely different location. So how does the computer know where to look for the lives memory? The answer is simply using pointers.Pointers are simply variables that point to a specific memory address asnd they can be modified at runtime.Lesson 3 - Executables & LibrariesThis section will start to look into reverse engineering the actual code that makes the games run on the CPU.What is an executable and how does it work?The Youtuber Bisqwit has created an excellent video on how executables work:What file format do executables have?Executable file formats are specific data structures used by operating systems to understand how to load and execute a program. These formats vary depending on the operating system and architecture, but the most common ones are: PE - Portable Executable used in Microsoft Windows and Xbox ELF - Executable and Linkable Format used in Linux/Unix systems Mach-O - Mach Object used in macOS and iOS COFF - Common Object File Format used in older versions of Windows for device drivers and early Unix COM - Used in DOS and early WindowsNote that most executables don’t have any file extension on Unix/macOS and many games consoles. Many games consoles use a modified version of ELF such as the Sony PSP’s EBOOT.bin files or even completely custom implementations like the original PlayStation’s PS-EXE format.What is an API?🧩An Application Programming Interface (API) is a collection of functions that are so common that they are provided to every programmer of a certain platform (e.g. PS1, Xbox 360, Windows). These functions can either by included in the executable directly or dynamically linked to at runtime from a common set of libraries.API functions are very useful when reversing a game or application as they tend to have documentation associated with them and give hints as to what the code that calls them might be wanting to do. So they are a very good place to start when reverse engineering an executable.How are APIs distributed?APIs are typically distributed in several ways to allow developers to integrate them into their applications: Static Libraries - Provided as .lib (Windows) or .a (Unix-like systems) files that developers link to their applications at compile time. Dynamic Libraries - Provided as .dll (Windows) or .so (Unix-like systems) files, which are linked at runtime.What is a Static Library?🏛️A static library is a collection of precompiled code that is linked directly into a program during the build process. This means the code from the library becomes part of the final executable, allowing the program to run independently without needing the library files at runtime. Static libraries typically have file extensions like .lib on Windows and .a on Unix-like systems.What is a Dynamic Library?♻️A dynamic library is a file containing code and data that can be used by multiple programs simultaneously. Instead of including the code directly in each program, they load the library at runtime, saving memory and allowing updates without recompiling the programs. In Windows, these are called DLLs (Dynamic Link Libraries), while in Unix-like systems, they are often called shared objects (.so files).Which DLLs are used by code compiled by versions of Microsoft Visual C++?Here’s a table of Microsoft Visual C++ (MSVC) versions and their associated runtime DLLs that can be imported. This table provides a quick reference for understanding which runtime DLLs correspond to different versions of MSVC. MSVC Version Runtime DLLs DLL File Names MSVC 6.0 Visual C++ 6.0 runtime MSVCRT.dll MSVC 7.0 Visual Studio .NET 2002 (VC7) MSVCRT.dll, MSVCP60.dll MSVC 7.1 Visual Studio .NET 2003 (VC7.1) MSVCRT.dll, MSVCP71.dll MSVC 8.0 Visual Studio 2005 (VC8) MSVCRT.dll, MSVCP80.dll, MSVCR80.dll MSVC 9.0 Visual Studio 2008 (VC9) MSVCRT.dll, MSVCP90.dll, MSVCR90.dll MSVC 10.0 Visual Studio 2010 (VC10) MSVCRT.dll, MSVCP100.dll, MSVCR100.dll MSVC 11.0 Visual Studio 2012 (VC11) MSVCRT.dll, MSVCP110.dll, MSVCR110.dll MSVC 12.0 Visual Studio 2013 (VC12) MSVCRT.dll, MSVCP120.dll, MSVCR120.dll MSVC 14.0 Visual Studio 2015 (VC14) MSVCRT.dll, MSVCP140.dll, MSVCR140.dll MSVC 14.1 Visual Studio 2017 (VC14.1) MSVCRT.dll, MSVCP140.dll, MSVCR140.dll MSVC 14.2 Visual Studio 2019 (VC14.2) MSVCRT.dll, MSVCP140.dll, MSVCR140.dll MSVC 15.0 Visual Studio 2022 (VC15) MSVCRT.dll, MSVCP140.dll, MSVCR140.dll Notes: MSVCRT.dll is the Microsoft C Runtime Library used across various versions. MSVCPxx.dll refers to the Microsoft C++ Runtime Library, where xx denotes the version (e.g., 80 for Visual Studio 2005). MSVCRxx.dll refers to the Microsoft C Runtime Library versioned similarly to the MSVCPxx.dll.What tools are used to explore Executables and Compiled Libraries?Here’s a table summarizing the tools for viewing the insides of executables and libraries: Tool Platform Description Usage objdump Linux, Unix, macOS, Windows Disassembles and displays information about object files and executables. objdump -d <file> for disassembly, objdump -t <file> for symbols. readelf Linux, Unix Displays detailed information about ELF files, including headers and segments. readelf -h <file> for headers, readelf -s <file> for symbols. nm Linux, Unix, macOS, Windows Lists symbols from object files, executables, and libraries. nm <file>. gdb Linux, Unix, macOS, Windows Debugger that can also inspect executable contents, disassemble code, and view symbols. gdb <file>, then use commands like info functions or disassemble. Ghidra Windows, Linux, macOS Free and open source disassembler and debugger with interactive analysis capabilities. Load the executable into Ghidra and use the GUI for exploration. IDA Pro Windows, Linux, macOS Commercial disassembler and debugger with interactive analysis capabilities. Load the executable into IDA Pro and use the GUI for exploration. Hex-Rays Decompiler Windows, Linux, macOS Converts disassembled code back to C-like pseudo code; an add-on for IDA Pro. Integrated within IDA Pro; select a function and decompile. Binary Ninja Windows, Linux, macOS Modern binary analysis tool with disassembly, decompilation, and scripting. Load the binary and use the GUI or API for analysis. Radare2 Windows, Linux, macOS Open-source framework for reverse engineering, including disassembly and debugging. r2 <file>, then use commands like pdf to disassemble functions. PE Explorer Windows Commercial tool for inspecting and editing Windows PE files. Open the executable in PE Explorer and navigate through sections. CFF Explorer Windows Free tool for analyzing and editing PE files, with detailed views of file structure. Open the PE file in CFF Explorer and explore different sections. Dependency Walker Windows Analyzes dependencies of Windows executables and DLLs, showing imported/exported functions. Load the executable or DLL in Dependency Walker and explore dependencies. dumpbin Windows (Visual Studio) Command-line tool for inspecting PE files, showing headers, symbols, imports, and more. dumpbin /all <file> to view all available information. MachOView macOS Tool for viewing the structure of Mach-O binaries, native to macOS executables. Open the Mach-O binary in MachOView and browse its segments and sections. How do I find out what compiler/linker was used to build an executable?When decompiling it can be incredible useful to know the exact version of the compiler and linker toolchain was used to build an executable so that the correct decompilation settings can be applied.The best tool to detect which compiler and linker was used is Detect It Easy (DIE), it is open source and has pre-build binaries available for Win/Mac and linux: Detect-It-Easy: Program for determining types of files for Windows, Linux and MacOS.Lesson 4 - Assembly LanguageWhat is Assembly language?🔢Assembly language is a low-level programming language that’s a step above the binary machine language that computers understand. It uses human-readable mnemonics and symbols to represent the basic operations a computer’s Central Processing Unit (CPU) can perform, like adding numbers, moving data, and making decisions.In essence, assembly language is a way for humans to communicate with computers in a more understandable way, making it easier to write software that can perform specific tasks or functions on a computer’s hardware.Do I need to learn Assembly Language for reversing?🤔You do not need to learn assembly language to reverse engineer retro games, however, if you want to write your own games from scratch then it is recommended. For reversing you might be dealing with multiple CPUs on a single console so learning the entire instruction set would be too time consuming and by the time you get to actually reversing you may have forgotten much of what you have just learned.The best way is to learn as you go and use the Internet as a reference when you need to know what an instruction does.However there are a few basics that you should know before getting your hands dirty and these apply to the Assembly language used in most retro video game consoles. These will be covered in the next few sections.What Assembly language Should I learn?It depends on the platform (specifically CPU) that your game was built for, here are some examples: Z80 Assembly Language - Game Boy, Sega Master System, Sega Game Gear 6502 Assembly Language - Nintendo Entertainment System, SNES, PC Engine / TurboGrafx-16 Motorola 68000 Assembly Language - Sega Mega Drive MIPS Assembly Language - Sony PlayStation 1, Sony PlayStation 2, Sony PSP, Nintendo 64 SuperH Assembly Language - Sega Saturn, Sega Dreamcast ARM Assembly Language - Game Boy Advance, Nintendo DS, Nintendo 3DS, iPhone, Android PowerPC Assembly Language - Nintendo GameCube, Nintendo Wii, Nintendo Wii U, Microsoft Xbox 360, Sony PlayStation 3 Intel x86 Assembly Language - Microsoft XboxNote that the above are the rough groups, some specific CPUs have more specialised instructions that are exclusive to that console, but mostly its the same programming language.How similar are Instruction Set ArchitecturesHere is a simple comparison table that highlights some key differences between different CPU Instruction Set Architectures (ISA). Please note that this table is not exhaustive and focuses on high-level distinctions: ISA Example Instructions Number of Registers Memory Addressing Modes Complex Instructions Endianness Z80 ADD, SUB, MOV 8 General Purpose Immediate, Direct, Indexed, Register Indirect Conditional Jumps, Bit Manipulation Little-Endian 6502 ADC, LDA, STA 3 General Purpose Zero Page, Absolute, Indexed, Indirect None Little-Endian 68K ADD, SUB, MOVE 16 General Purpose Register Direct, Immediate, Memory Indirect Multiply, Divide, Bit Manipulation Big-Endian MIPS ADD, SUB, LW 32 General Purpose Immediate, Register Direct, Base + Offset Load/Store, Multiply, Divide Big-Endian x86 ADD, SUB, MOV 8 General Purpose Register Direct, Immediate, Memory Indirect Complex Arithmetic, SIMD Little-Endian ARM ADD, SUB, LDR 16 General Purpose Immediate, Register Direct, Base + Offset SIMD, Multiply, Divide Little-Endian SuperH ADD, SUB, MOV 16 General Purpose Immediate, Register Direct, Memory Indirect Multiply, Divide, Bit Manipulation Little-Endian PowerPC ADD, SUB, LWZ 32 General Purpose Immediate, Register Direct, Base + Offset SIMD, Multiply, Divide Big-Endian This table provides a broad overview of these architectures, but there are many more details and specific instructions within each ISA. The number of registers, addressing modes, and the availability of complex instructions can significantly vary even within a single architecture, and the choice of endianness (byte order) can have important implications for software compatibility. For a deep dive into any of these ISAs, you would typically need to consult the official documentation or specific resources for each architecture.How do I convert my game into assembly language?The process of taking a final game executable/ROM and converting it into human readable Assembly language is called disassembling.You need to choose a Disassembler that works for your game’s Instruction Set Architecture (ISA), this will depend on which console or PC your game is compiled for.We have a separate post covering how disassemblers work below: Disassemblers - A Deep Dive For more information on Disassemblers check out this post. Lesson 5 - CPUWhen learning reverse engineering and assembly language programming it is vital to know how a CPU actually works, what are the major parts and how they interact, that is what this section will focus on.What are Microprocessors (CPUs)?Microprocessors provided a cost-effective way to access computing power. Before microprocessors, developing custom hardware for each game or gaming system was expensive and time-consuming. Microprocessors allowed for standardized, affordable, and flexible computing platforms.Microprocessors brought a level of standardization to the gaming industry. Instead of needing custom hardware for each game or console, developers could create games for a common microprocessor architecture (e.g. x86, ARM, or MIPS). This made it easier for developers to create games and for consumers to adopt new gaming systems.How a CPU WorksLiveOverflow has an excellent introduction video to how a CPU works and what exactly assembly language is.A CPU for a game console or PC works by following a series of steps to process instructions and manage the game’s activities.This is known as the Fetch-Decode-Execute-Repeat cycle and it continues indefinitely until the CPU looses power.Here’s a simple explanation: Fetch: The CPU fetches (reads) instructions from the game’s memory. These instructions are like the rules of the game. Decode: The CPU figures out what each instruction means. It’s like understanding the rules of the game, such as “move the character left” or “shoot the enemy.” Execute: The CPU carries out the instructions. It makes the game characters move, calculates scores, and does other tasks as instructed. Repeat: The CPU keeps fetching, decoding, and executing instructions one after the other, making the game run smoothly.The CPU also works with other parts of the console, like the graphics and sound chips, to create the game’s visuals and sounds.What is a CPU Instruction?👣An instruction is a basic operation or command that the CPU can execute. These instructions are written in a machine-readable form, usually in binary code, and are the fundamental building blocks of a computer program. Each CPU has its own specific set of instructions, known as its instruction set architecture (ISA).Instructions can perform various tasks, such as: Arithmetic Operations: These include instructions for addition, subtraction, multiplication, division, and other mathematical operations. Data Movement: Instructions for moving data between registers, memory, and other storage locations. Control Flow: Instructions that control the program’s flow, such as branching (jumping to a different part of the program) or conditional execution (if-then-else). Logical Operations: Instructions for performing logical operations like AND, OR, XOR, and NOT. Load and Store: These instructions load data from memory into registers or store data from registers back into memory. Input/Output: Instructions that allow the CPU to interact with input and output devices like keyboards, displays, and storage devices.CPU instructions are executed sequentially, one after the other, according to the program’s logic. The order and combination of these instructions determine the behavior of a computer program.The No Operation Instruction (NOP)💤In the world of assembly language programming, every Central Processing Unit (CPU) includes an instruction that accomplishes precisely nothing. These unassuming instructions are commonly referred to as ‘No Operation’ or NOPs. When a NOP is executed, the CPU undergoes a brief, yet essential, period of inactivity, ultimately ending up in the exact state it occupied before executing the instruction.While this might seem counterproductive, NOPs have their indispensable uses. One of their primary functions is to ‘waste time’ intentionally. CPUs operate relentlessly, executing instructions in rapid succession, and sometimes, you need the CPU to pause briefly, awaiting the readiness of another part of the system. In such cases, NOPs prove invaluable. They serve as a placeholder or a delay mechanism, ensuring that the CPU remains occupied without altering its state.Imagine a scenario where a CPU needs to synchronize with external hardware that operates at a different speed. By inserting NOPs strategically, you can create the necessary time gaps, allowing the CPU to align its actions with the external hardware’s pace. This is just one example of how NOPs find practical application in assembly programming, despite their seemingly ‘do-nothing’ nature.Also NOP instructions can be used to insert empty space or “padding” in the code. This can be useful for aligning instructions in memory or adjusting the size of loops and branches. For example, if you want to ensure that a certain block of code is located at a specific memory address, you can insert NOP instructions to fill the gap between the end of the previous code and the desired location.What is a CPU Register?🔢You can think of CPU Registers as small (64-bit/32-bit/16-bit) global variables that the CPU accesses directly.Each CPU has a number of built in registers which can each store a set number of Bytes, the number of bytes that they store is defined by the CPU, for example a 64-bit CPU will have 64-bits for each register.Almost all CPUs have special registers that are designated for a particular purpose, one common example is the Program Counter which basically stores the location of the next instruction to execute on the CPU.Lesson 6 - MemoryThe Stack📚But what happens when you want to store more data than the limited number of registers available on the CPU? This is where the computers RAM comes in, no matter how simple your console or PC is it will have some sort of RAM available and is used to store data such as the players X and Y Position.So how do we read and write data to this RAM? One simple way of saving and loading data is with something called the Stack.What is the Stack?You can think of the stack like a deck of cards, you can add new cards only to the top of the deck which represents writing to the stack. For reading data from the stack you can only take the top most card, which is also the most recently written piece of data.Although unlike a deck of cards when you add more data the address of the data goes downwards instead of upwards, so if the first element in a stack is at position 10 then when you add another byte of data its address would be 9.Why does the Stack grow backwards?The stack grows backwards (from high to low memory addresses) to efficiently separate it from the heap, which grows in the opposite direction. This allows both to expand without quickly running into each other, making better use of available memory.How do you interact with the stack?The CPU has designated instructions to read and write from the stack, often called push and pop. Where push adds an additional piece of data to the stack and pop removes the most recently added data from the stack of data.The Heap🧱When you need to store more data than the stack can handle or require memory that persists longer than a single function call, the heap comes into play. The heap is another part of your computer’s RAM, used for dynamic memory allocation, such as storing large objects, game assets, or variables that need to exist throughout the program’s execution.What is the Heap?You can think of the heap as a large pool of memory where you can request chunks of memory as needed. Unlike the stack, memory in the heap can be allocated and freed in any order, making it flexible but also more complex to manage.Which systems had a heap?Early video game consoles typically did not have a heap due to their limited memory and lack of an operating system to manage dynamic memory allocation. However, as consoles evolved and gained more memory and complexity, the concept of a heap started to become relevant.Some heaps were handled by the operating system (Xbox onwards) and others were handled by the game engines themselves (PS2, GameCube).How does the Heap grow?The heap grows upwards, from lower to higher memory addresses. When you request more memory (for example, creating a new object or allocating an array), the heap expands towards higher addresses. This is in contrast to the stack, which grows downwards, ensuring that both areas can grow without quickly overlapping.Why is the Heap important?The heap is essential for managing memory in programs where the amount of data isn’t known ahead of time or varies during execution. It’s particularly useful in situations where you need to allocate large blocks of memory that might need to exist for the lifetime of the program or until explicitly freed.How do you interact with the Heap?Most programming languages provide functions or operators to allocate and free memory on the heap. In languages like C, malloc() and free() are used, while in higher-level languages like Python or Java, memory management on the heap is handled automatically through built-in mechanisms.This allows you to dynamically allocate space when needed and release it when it’s no longer required, making the heap a powerful tool for managing memory in complex programs.Interacting with the heap in assembly language typically involves system calls or interrupts to request memory from the operating system. Unlike the stack, which is managed directly by the CPU with specific instructions, the heap requires explicit requests for memory allocation and deallocation.Pointers➡️Instead of passing large arrays or structures to functions (which is slow), you can pass their address. This is faster and allows the function to modify the original data without needing to return the whole structure. That address when saved into a variable is called a pointer, as it points to data.Lesson 7 - FunctionsFunction Calling Conventions📞Function calling conventions are rules that define how functions receive parameters, return results, and manage memory during a call.Conventions specify whether function arguments are passed in registers (fast) or on the stack (slower) and decide which registers are used for passing parameters. Often, a special register (like eax in x86 architecture) is used to hold the return value.Conventions also decide who is responsible for cleaning up the stack after the function call either the caller of the function or the callee.cdecl (C Declaration)cdecl (short for “C Declaration”) is a calling convention used in C and C++ programming that specifies: Arguments: Passed on the stack from right to left. Cleanup: The caller cleans up the stack after the function returns. Return Value: Typically returned in the eax register.stdcallstdcall is a calling convention used in Windows programming that specifies: Arguments: Passed on the stack from right to left. Cleanup: The callee (the called function) cleans up the stack after the function returns. Return Value: Typically returned in the eax register.fastcallfastcall is a calling convention designed to improve the performance of function calls by reducing the overhead associated with passing arguments and handling stack operations. Arguments: Arguments: The first few arguments are passed in specific registers (e.g. ecx and edx on x86), with additional arguments on the stack. Cleanup: The callee cleans up the stack. Return Value: Typically returned in the eax register.thiscallthiscall is a calling convention used primarily for C++ member functions. It is designed to handle the specific needs of methods that operate on objects (i.e. functions that are part of a class). Arguments: Used primarily for C++ member functions. First Argument: The this pointer (the instance of the object) is passed in a specific register (ecx on x86). Additional Arguments: Passed on the stack. Cleanup: The callee cleans up the stack. Return Value: Typically returned in the eax register.Function Prologue and EpilogueDisassemblers often rely on function prologues and epilogues as key indicators for identifying the boundaries of functions within a binary. These patterns help the disassembler understand where functions start and end, allowing it to organize the disassembled code into coherent blocks. These tend to be fairly standard as they are created by the compiler.Function Prologue🔜The prologue is the sequence of instructions at the beginning of a function that prepares the stack and registers for the function’s execution. It typically includes saving the return address, preserving the base pointer (if used), and allocating space on the stack for local variables.Example (x86 Architecture): push ebp ; Save the old base pointer mov ebp, esp ; Set up the new base pointer sub esp, 0x10 ; Allocate 16 bytes of stack space for local variablesFunction Epilogue🔚The epilogue is the sequence of instructions at the end of a function that cleans up the stack and restores the saved registers. It usually includes restoring the base pointer and the stack pointer, and then returning control to the caller.Example (x86 Architecture): mov esp, ebp ; Restore the stack pointer pop ebp ; Restore the base pointer ret ; Return to the callerSystem Calls⚙️System calls are functions provided by the operating system that allow programs to interact with hardware and system resources, like reading files, creating processes, or communicating over networks. They act as a bridge between user-level applications and the core functions of the operating system.Here are simple examples of making a system call in assembly on Windows, Linux, and macOS.Windows (x86) System Call ExampleIn Windows, system calls can be made directly using two different methods depending on which version of windows: int 0x2e: This interrupt vector was historically used to invoke system calls by placing the syscall number in eax and issuing the interrupt. This method is deprecated and replaced by SYSENTER. SYSENTER: This instruction is optimized for making system calls on modern x86 processors. Windows sets up the MSRs (Model-Specific Registers) required for SYSENTER during boot, so user-mode applications don’t need to manage them. However, this approach is not documented for use in applications and is generally intended for internal OS use.Directly invoking system calls using int 0x2e or SYSENTER is highly discouraged in normal application development due to the risk of instability and compatibility issues across different Windows versions. Instead, using the Windows API (like ExitProcess) is the recommended and supported approach.Using int 0x2e (pre-Windows XP)The int 0x2e interrupt was used in older versions of Windows (pre-Windows XP) to invoke system calls directly. Here’s an example:section .data ; No data needed for this simple examplesection .text global _start_start: ; System call: NtTerminateProcess (similar to ExitProcess) ; System call number: 0x29 (varies by Windows version) ; Parameters: ; - eax: system call number ; - ebx: handle to process (0 for current process) ; - ecx: exit code (0 for success) mov eax, 0x29 ; system call number for NtTerminateProcess xor ebx, ebx ; current process xor ecx, ecx ; exit code 0 int 0x2e ; invoke system callUsing SYSENTER (Modern Method)SYSENTER is a fast system call instruction introduced with Intel’s Pentium II processors and is used internally by Windows for system calls on newer systems. This approach requires setting up specific registers before the SYSENTER instruction is executed:section .data ; No data needed for this simple examplesection .text global _start_start: ; System call: NtTerminateProcess (similar to ExitProcess) ; System call number: 0x29 (varies by Windows version) ; Parameters: ; - eax: system call number ; - edx: address of the system call table (set by the OS, usually in kernel mode) ; - ebx: handle to process (0 for current process) ; - ecx: exit code (0 for success) mov eax, 0x29 ; system call number for NtTerminateProcess xor ebx, ebx ; current process xor ecx, ecx ; exit code 0 mov edx, esp ; load stack pointer into edx (just for demonstration) sysenter ; fast system call entryLinux (x86) System Call ExampleLinux allows direct access to system calls using the int 0x80 instruction:section .data ; No data needed for this simple examplesection .text global _start_start: ; syscall: sys_exit ; syscall number: 1 ; parameters: ; - ebx: exit code (0 for success) mov eax, 1 ; syscall number for sys_exit xor ebx, ebx ; exit code 0 int 0x80 ; invoke system callmacOSX (x86_64) System Call ExamplemacOSX uses a different set of registers and the syscall instruction for system calls:section .data ; No data needed for this simple examplesection .text global _start_start: ; syscall: exit ; syscall number: 0x2000001 ; parameters: ; - rdi: exit code (0 for success) mov rax, 0x2000001 ; syscall number for exit xor rdi, rdi ; exit code 0 syscall ; invoke system callFinding Common Functions🔎When reverse engineering an executable, identifying common library functions can significantly simplify the analysis by allowing you to focus on application-specific code.Here are some resources: FLIRT (Fast Library Identification and Recognition Technology) - FLIRT - Hex-Rays Docs Is Function Similarity Over-Engineered? Building a BenchmarkRandom Number Generation (RNG)🎲While a CPU diligently follows every instruction it receives, this unwavering predictability presents a challenge for game developers. Players crave the excitement of unpredictability to make each gaming experience unique. So, how can a CPU introduce randomness into the game world?One elegant solution involves a Random Number Generator (RNG) that relies on the timing of user input. The CPU continuously increments a counter until the player presses a button. With the timing of button presses being entirely unpredictable, the CPU uses this ever-evolving count to generate random numbers. This injects a vital element of surprise and distinctiveness into every gaming session.This technique is frequently employed in early games, especially when other random seeds, like the current time in milliseconds, which is guaranteed to be unique but somewhat predictable, are unavailable.What is an emulator and how does it work?We have a specific post covering exactly how emulators works including tips for writing your own emulators: How Do Emulators Work? A Deep Dive into Emulator Design For more information on how emulators work check out this post. Reversing with GDBGDB is a very useful tool to debug through an application, with functionality to set breakpoints and disassemble the code, which makes it a very useful tool for basic reverse engineering. Reversing with GDB (GNU Debugger) For more information about GDB check out this post. Next Steps - Choosing your console🕹️You may already have a game or console chosen that you would like to reverse, if not we would suggest you start with either Game Boy or the Nintendo Entertainment System as there are many tools and documentation available for these platforms.Nintendo ConsolesWe have pages on each of the following Nintendo consoles: Nintendo Entertainment System Super Nintendo Entertainment System Nintendo Game Boy Nintendo 64 Nintendo GameCube (Dolphin) Nintendo Wii Nintendo 3DS Nintendo Wii USEGA ConsolesWe have pages on each of the following SEGA consoles: Sega Master System Sega Mega Drive (Genesis) Sega Saturn Sega Dreamcast Sega Game GearSony ConsolesWe have pages on each of the following Sony consoles: Sony PlayStation 1 Sony PlayStation 2 Sony PlayStation PortableMicrosoft Consoles & PCWe have pages on each of the following Microsoft consoles along with a section of the IBM-PC: Microsoft Xbox PCAll Posts tagged with Introduction Why Reverse Engineer Retro games? - About RetroReversing.com If you have arrived at this page you may have a few questions such as why does RetroReversing.com even exist? Well, let us try to answer this question, starting with... ... Read More introduction Arcade - How retro arcade games were made Awesome list of Arcade Game Development information ... Read More arcade introduction hardware 2D & 3D Graphics Techniques This is a Work in progress page to list interesting articles on 2D graphics techniques to create cool effects. 2D Graphics effects How Doom’s Melting Screen Works The YouTuber decino... ... Read More 2d 3d introduction Creating a LibRetro Frontend in Rust Welcome to this comprehensive tutorial on creating a LibRetro Frontend using Rust! If you’re passionate about retro gaming and interested in creating your very own emulation frontend from scratch, you’ve... ... Read More introduction tutorial tools Creating a new reversing emulator Step by step guide for how to create a Reversing emulator for your console of choice. Note that you may not need this guide if someone has already created a... ... Read More reversingEmulator introduction Reversing with GDB (GNU Debugger) Introduction What is GDB? The GNU Debugger or GDB for short is a command line tool that allows you to disassemble and understand the code execution of a program. If... ... Read More introduction gdb Game Architecture - How games are structured Introduction Game architecture refers to the overall design and structure of a video game. It encompasses the organization and management of various components that make up a game, including the... ... Read More introduction Nintendo Game Boy Reverse Engineering Hub page for Game Boy and Game Boy Color hardware, development, reverse engineering, and source code resources ... Read More gameboy introduction Introduction to Game Engines & Middleware Introduction to Game Engines & Middleware Game Engines are the foundation in which games are built, they contain all the logic to be able to show graphics, play audio, compute... ... Read More gameengines middleware introduction sdk Introduction to Decompiling C++ with Ghidra Introduction This tutorial series will guide you through the basics of decompiling a C++ executable, from setup all the way to reversing C++ classes. The video tutorial is created by... ... Read More introduction ghidra N64 Decompiling with Ghidra Importing a Nintendo 64 ROM Download and Install Ghidra Before following the steps on this post please make sure you have a working Ghidra environment setup. So you should be... ... Read More introduction tutorial n64 ghidra How Do Emulators Work? A Deep Dive into Emulator Design Have you ever wondered how emulators work? How would you implement an emulator? Where should you start if you are interested in emulator development? This post attempts to answer all... ... Read More introduction How to reverse engineer a microchip In this tutorial from Robert Baruch on his youtube channel [], the target chip used in the video series is the Texas Instruments 74LS01 Logic gate from 1986. First step... ... Read More introduction hardware Industry Leaks - Game Industry Source Code Leaks The games industry has had its fair share of cyberattacks in the past decade and one of the main targets for hackers has always been source code. This post will... ... Read More leak introduction Legality of Reverse Engineering & Clean Room Reversing Reverse Engineering of commercial Games and Applications straddles a fine line of legality. Whether a Reverse Engineering project is legal or not completely depends on how it was accomplished. Conversion... ... Read More introduction Memory Hacking Memory Hacking One excellent way to get started modifying your favourite game is to use memory hacking techniques. By learning what memory locations are used for specific functions you can... ... Read More n64 memory introduction Emulator Game Memory corruption Introduction Game corruption has become a hot topic recently due to many you tubers playing through games that have in some way had their memory corrupted. This practise can cause... ... Read More introduction pc nes n64 Nintendo 64 (Project Reality) Reversing Interested in learning more about the the N64? Excellent! This section will guide you through the basics, starting from basic MIPS assembly language all the way to an introduction to reverse engineering your first game! ... Read More n64 introduction N64 Reversing Introduction This post will give a brief introduction for the tools and techniques you need to start reverse engineering and decompiling a N64 Game. Part 1 - Looking for Initial Clues... ... Read More n64 introduction NES Sprite Tile Editing Sprite Tile editing with Tile Layer Pro If you have ever wondered how graphical rom hacks are made this is for you! This should work for most early games such... ... Read More nes gameboy introduction Reverse Engineering NES Games - Uncovering the Secrets of Classic Gaming Awesome list of Nintendo Game Development and Reverse Engineering information ... Read More nes introduction PC-Engine Introduction to the PC-Engine Sakharu Baguette has created an excellent documentary which explores the history of the PC Engine (known as the TurboGrafx-16 in North America), detailing its rise as... ... Read More pc-engine introduction PDB Files - Using PDB files for Reverse Engineering If you are very lucky indeed then the game you want to reverse engineer comes with full debug symbols in the form of a Program Database file or PDB for... ... Read More introduction tutorial tools xbox pc Introduction to Audio/Music Programming of Retro Games Introduction To get started the 8-bit Guy on Youtube has an excellent video covering how early computers and game consoles played sound and music 1. The gives a good overview... ... Read More introduction pc nes How Retro Cartridges (ROMS) work Have you ever wondered what exactly is inside those retro game Cartridges (ROMs)? In this post we will find out the purpose of ROM cartridges and how they worked. Advantages... ... Read More introduction hardware nes snes n64 megadrive mastersystem Introduction to Retro Game Graphics The 8-bit Guy on Youtube has an excellent series of videos covering how early computer graphics were implemented with the limitations of the hardware in mind. Memory Previously graphics chips... ... Read More introduction pc nes Sega Master System Reverse Engineering Awesome list of SEGA Master System Game Development and Reverse Engineering information ... Read More mastersystem introduction How does Twitch Play Pokemon? (Emulation through Twitch) Have you ever seen Twitch Plays Pokemon (TPP) and wondered how it actually works? How does typing comments in a twitch stream result in the player moving in the original... ... Read More introduction gameboy 3ds Sony Playstation Vita Reverse Engineering Awesome list of Sony Playstation Vita Game Development and Reverse Engineering information ... Read More vita psp introduction handhelds Understanding libRetro - An Internal Look for Programmers Introduction libRetro is a versatile framework designed to facilitate the development of emulators and games through a unified interface. This post explores the internal workings of libRetro, providing insights tailored... ... Read More introduction tutorial tools Official N64 SDK Setup (MacOSX/Linux/Win) Introduction The Official Nintendo 64 software development kit (SDK) was created by a partnership between Silicon Graphics (SGI) and Nintendo to be released with the development hardware produced by SGI... ... Read More n64 introduction sdk tutorial ", "excerpt": "This guide is for all beginners who are interested in learning more about the technical details of their favourite consoles and games. The guide aims to be as console-agnostic as possible, but after you have completed this you should look into the details of the specific console you are interested...", "tags": ["introduction"], "image": "/public/images/Reverse Engineering Beginners Guide.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Krisalis Development Kit (Sega Master System/Game Gear)", "url": "/krisalis-development-kit-(sega)", "content": "Krisalis Development KitIn the early to mid 1990s Krisalis Software Ltd created their own in-house sega Game Gear and Master System Development Kit.Shaun Hollingworth and Matt Furniss are credited with creation of the kits hardware and software components. Presumably Shaun was in charge of the hardware (as his name is credited on the board itself) and Matt the software BIOS.It seems to be very similar to Spidersofts own in-house dev kit (called ESYS) and it seems they worked quite closely on it. They also shared development software between the two software houses such as the Krisalis Assembler (KASM).Gear Video DecoderThe Gear Video decoder was a board created by Shaun Hollingworth, which presumably is the board that connects the Game Gear to the TV monitor or development system.Games World magazine even featured a version of this hardware (which they called ESYS-RGB) in the first issue dated July 1994, which was sold to other games studios or press outlets rather than to the general public. Presumably this is the hardware they used to provide screenshots for the Game Gear games published in the magazine.Krisalis and Spidersoft collaborationIt seems both Krisalis and Spidersoft were creating their own development hardware in collaboration with one another, presumably sharing experience of what works and what doesn’t work so the other studio can improve their own development kit. They were both mentioned in the Games World article as creator of the ESYS-RGB adapter.RetroSpark on SMSPower.org has the following to say on the comparison: This development system shares many similarities with Spidersoft’s ESYS (described by Matt Taylor), including apparent support for easily swapping the ribbon cable and cartridge for use on a different system. In fact, we discussed the possibility that this box is ESYS. Matt mentioned that Krisalis wrote the software for ESYS - perhaps they were also subcontracted to build the hardware. However, there is at least one difference between this box and Matt’s - this box does not appear to have a battery backup for the SRAM.ESYS Development KitMatt Taylor mentions the similar ESYS development tool used in-house at rival software company Spidersoft: Spidersoft designed and built its own development system called ESYS. This was a ROM emulator box about the size of house brick containing 512Kb of RAM connected to a PC via a parallel cable. Several were in use at Spidersoft at any one time and they were also sold to other developers. The beauty of the system was that different cartridge interface cards were produced for different consoles, meaning that the same ESYS box could be used for Game Boy, Game Gear, Master System, Megadrive, SNES, NES, and even Jaguar. The ESYS box also had battery backup meaning that ROM images downloaded to it could be retained even when removed from a PC, making demonstrating work to publishers very easy. Spidersoft also produced a modified Game Gear and interface board that allowed video output from a Game Gear to be put onto a monitor or television, which was useful during development.Development Kit BIOSThe BIOS for this development kit has been dumped by the talented people over at SMSPower.org and it runs out that you can run it in an emulator as either a Master System ROM OR a Game Gear ROM! The Bootup screen shows a different image depending on if its being run as a Master System game or Game Gear as can be seen in the screenshots below.Master System ModeGame Gear ModePC Development Tools used with KrisalisInitially Krisalis used PDS but then later moved to their own handwritten development toolchain.What was PDS?PDS stands for the Programmers Development System created by “Programmers Development Systems Ltd” (More Information: http://www.cpcwiki.eu/index.php/PDS_development_system)It seems to be waiting for the PDS running the on programmers PC to send the code through the hardware interface into the development kit.Shaun Hollingworth on this development kit: The version you have was originally designed to support the PDS Z80 dev system, but increasingly people ran out of symbol space when developing, so I hastily ported our in house z80 assembler (also written by yours truly) which ran on Atari STs to the PC (completely rewritten in 8086 16 bit code) which solved that problem. KasmZ80 also had a z80 debugger with breakpoints using some z80 RST xx instruction, though I can’t remember which one. We used it for all z80 dev work at Krisalis. We had versions for other CPUs including ARM.KasmZ80So they initially used the PDS Z80 software development kit but due to lack of symbol space (symbols are names of variables, functions etc) they needed to use their own assembler which Shawn ported from the Atari ST to the PC in 1992.It was called the Krisalis Assembler Z80 (KasmZ80) and they later distributed versions to other software companies such as Spidersoft.Matt Taylor (ex Spidersoft employee) on developing Lemmings 2 with KASM: The development compilers and debugging software, called KASM, was written by Krisalis Software and allowed for real-time debugging and breakpointing of code running on any device attached to the ESYS box.Single Codebase for multiple platformsMatt Taylor (ex Spidersoft employee) on developing Lemmings 2 with KASM for both Master System and Game Gear1: The code was written using a single codebase for both MS/GG versions as well as the Game Boy version, and was developed in around 8 months.Example Code for KASMz80 (Playing Sound Samples)Thanks to MattTaylor on SMSPower.org2 we have an example source file which would be parsed by the KASM assembler and produced a ROM for Game Gear and Master System!SMPRTE DB 0 INSREG: LD C,#80 ;Initialise sound registers LD B,3 ISR10: LD A,C OUT (PSG),A XOR A OUT (PSG),A LD A,C ADD #20 LD C,A DJNZ ISR10 RET PSGSAMP: DI CALL INSREG LD HL,LETSGO ;Sample data LD BC,6346 ;Length LD A,16 ;Rate LD (SMPRTE),A PSGS10: LD A,(HL) SUB 127 PUSH HL LD L,A LD H,0 ADD HL,HL ADD HL,HL LD A,(SMPRTE) LD E,A PSGS20: DEC E JR NZ,PSGS20 LD A,L ADD 255&SAMPTB LD E,A LD A,H ADC SAMPTB/256 LD D,A PUSH BC LD A,(DE) LD B,A INC DE LD A,(DE) LD C,A INC DE LD A,(DE) LD D,A LD E,C LD C,PSG OUT (C),B OUT (C),E OUT (C),D POP BC POP HL DEC BC INC HL LD A,B OR C JP NZ,PSGS10 EI RET SAMPTB: INCBIN L2SGSMTB.BIN ; 1024 LETSGO: INCBIN L2LETSGO.SMP ; 6346 References http://www.smspower.org/forums/8528-Lemmings2SMSGG - information on developing Lemmings 2 with KASM ↩ http://www.smspower.org/forums/14724-PlayingSoundSamples#78968 - example of KASM source code ↩ ", "excerpt": "Krisalis Development Kit In the early to mid 1990s Krisalis Software Ltd created their own in-house sega Game Gear and Master System Development Kit. Shaun Hollingworth and Matt Furniss are credited with creation of the kits hardware and software components. Presumably Shaun was in charge of the hardware (as his...", "tags": ["devkit","hardware","gamegear","mastersystem","sega"], "image": "/public/nAxI7tmNzVZDcZMLzn8JA_img_3.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Krome Studios Merkury Engine", "url": "/krome-merkury-engine", "content": "The Merkury engine is a proprietary game engine developed by Krome Studios since at least 2001, known to run on PS2, PSP, Wii and with version 3 of the engine it added support for Xbox 360 and PS3. It is likely also running on the Nintendo Switch thanks to the recent port of Star Wars: The Force Unleashed to the console.Nowadays new games are developed in Unity at Krome Studios (e.g Ty the Tasmanian Tiger 4) rather than the Merkury engine, but remaster of older games are still being released based on the Merkury engine so Krome Studios are still actively developing with it.It is best known for the custom versions of Star Wars: The Force Unleashed on less powerful consoles, because the LucasArts version for Xbox 360 and PS3 was too demanding to port directly to PS2, PSP or Wii. Because a significant installer base remained for those consoles, LucasArts opted to outsource a custom version to Krome, using their existing engine architecture under the name MerkuryOrigin of the Merkury EngineThe Merkury Engine is first listed on the official Krome Studios website sometime before March 2001 (when it was archived by the wayback machine) where it claimed the engine had been in development for 3 years 1, so this would put the creation of the Merkury engine around with 1998 or 1999, depending on when the text was written on the website.There are at least three known major versions of the Merkury engine: Version 1 (1998/1999) - Originally called BEAST (and the 3d library Blast Graphics) created around 1998 or 1999 Version 2 (2004) - Created for Ty the Tasmanian Tiger 2 Version 3 (2010) - Created for The Legend of the Guardians: The Owls of Ga’hoole around 2010Merkury Engine 1.0 featuresOn the official website archived on March 3rd 2001, it called Merkury a “world-class 3D game engine” 1 and it listed the features of the engine as: Soft-Skinned Skeletal Animation System Simultaneous Independent Animations Mesh Morphing and Animation Morphing Full Support For implementation Of 3D Studio MAX Meshes And Animation Support For Hardware Transformation And Lighting Real-time Shadows Full Particle Library Using Realistic Motion Simulation. Advance Material Management System Real-time Collision System Indoor And Outdoor Environments Multi-Platform Multi-Genre Multiple Field Of ViewThe first game that is officially credited as using the engine is the Windows version of Championship Surfer from 2000 with Tony Ball being listed as the Merkury engine programmer in the credits section of the manual.Programming the Merkury engineThe Merkury engine was built in C++ with a few modules written in Assembler, with simultaneous development of the engine on multiple platforms at once (Windows, PS2, GameCube and Xbox) 2.On the port of the Merkury engine to GameCube for Ty the Tasmanian Tiger, Chris Lacy had the following to say in an interview with Nintendo World Report (NWR): In about July of last year (2001) we received our first GameCube DevKit, which was very exciting for me, especially because I had been following the development of “Dolphin” since the PlanetN2000 days when Rick first broke the story about the codename for the project. To see it in person was so cool. Within a couple of weeks, Tony Ball, our GameCube engine lead, had the character animating and drawing and doing most of what was doing in the PS2 version. A couple of months went by and by that point the GameCube version of the Merkury engine was pretty much inline with the PS2 version, so from then on development was simultaneous between the PS2 and GameCube, and later Xbox versions of the game.Early Merkury Engine GamesThe original Krome Studios website archived back in March 2001 has the following games as using the Merkury engine 1: Mike Stewart’s Pro Bodyboarding - Released in February 1999 for Windows Chronicles of Jaru Tenk - Released in 1999 sold as shareware via ScreenOpera Spirit Board - Released in 1999 sold as shareware via ScreenOpera Championship Surfer - Released in 2000 for Windows Kat Burglar - Never released Gruesome Castle - Never officially released but in development in 1998 and a demo was leaked online (Gruesome Castle - Unseen64)However the only actual reference in the game files for the name Merkury was in the 2000 windows release of Championship Surfer. The rest of the games refer to a game engine called BEAST and a 3D engine called Blast Graphics which we believe was simply just renamed to Merkury sometime during the development of Championship Surfer.Krome Studios games and their enginesBecause not all uses of Merkury are documented, below is a table of major titles developed by Krome Studios across platforms. This is a reference for potential engine use, not confirmation of Merkury integration. Game Title Platform(s) Year Using Merkury Engine? Mike Stewart’s Pro Bodyboarding Windows February 1999 Yes but the engine was known as BEAST and Blast Graphics for 3D The Chronicles of Jaru Tenk Windows October 1999 Yes (Blast Graphics) Halloween Spirit Board Windows October 1999 Yes (Blast Graphics) Championship Surfer Windows, PlayStation, Dreamcast 2000 Yes for Windows (SURF_PC.rkv) and Dreamcast (SURF_DCP.rkv) but no for PS1 Barbie Beach Vacation Windows 2001 No not a 3D game so neither Blast Graphics or Merkury Disney’s Extremely Goofy Skateboarding Windows 2001 Yes (Blast graphics, uses fmod, bink, zip files) Sunny Garcia Surfing PlayStation 2 2001 Yes (Merkury creditied in game manual) Barbie: Sparkling Ice Show Windows 2002 Yes (DATA_PC.rkv), DirectX8, fmod, bink Ty the Tasmanian Tiger PS2, Xbox, GameCube, Windows, HD Remasters 2002 Yes The Adventures of Jimmy Neutron: Jet Fusion PS2, GameCube 2003 Yes Ty the Tasmanian Tiger 2: Bush Rescue PS2, Xbox, GameCube, Windows, HD Remasters 2004 Yes King Arthur PS2, Xbox, GameCube 2004   Ty the Tasmanian Tiger 3: Night of the Quinkan PS2, Xbox, GameCube, Windows, HD Remasters 2005   The Legend of Spyro: A New Beginning PS2, Xbox, GameCube, GBA 2006   The Legend of Spyro: The Eternal Night PS2, Wii 2007   Viva Piñata: Party Animals Xbox 360 2007   Hellboy: The Science of Evil PS3, Xbox 360, PSP 2008   Star Wars: The Force Unleashed PS2, PSP, Wii, Nintendo Switch 2008, 2022 Yes Star Wars: The Clone Wars - Lightsaber Duels Wii 2008   Scene It? Box Office Smash Xbox 360 2008   Star Wars: The Clone Wars – Republic Heroes PS3, Xbox 360, Wii, PS2, PSP, Windows 2009 Yes Transformers: Revenge of the Fallen PS2, Wii 2009   Game Room Xbox 360, Windows, Windows Phone 7 2010 Yes (RKV files present in windows version) Blade Kitten PS3, Xbox 360, Windows 2010, 2012 Yes (RKV files present) Legend of the Guardians: The Owls of Ga’Hoole Xbox 360, PS3, Wii 2010 Yes (Merkury 3) Full House Poker Xbox 360, Windows Phone 7 2011   Backyard Sports Basketball 2015 iOS, Android 2015 No (Unity) Ty the Tasmanian Tiger 4 Windows 2015 No (Unity) Ty the Tasmanian Tiger HD Xbox One, Series X/S, Switch, PS4, Windows 2016, 2020 Yes (RKV files present) Ty the Tasmanian Tiger 2: Bush Rescue HD Xbox One, Series X/S, Switch, PS4, Windows 2017, 2021 Yes (RKV files present) Ty the Tasmanian Tiger 3: Night of the Quinkan HD Windows 2018 Yes (RKV files present) The Bard’s Tale Trilogy Windows, Xbox One 2018, 2019 No (Unity) Wasteland Remastered Windows, Xbox One 2020 No (Unity) Ty the Tasmanian Tiger 4: Bush Rescue Returns Nintendo Switch 2023 No (Unity) Monster Dash iOS, Android 2016 / ongoing No (Unity) Gizmotablet (Kid World, Verizon) Android Tablet (EdTech) 2018   History of Krome StudiosThe company was originally founded as Interactive Binary Illusions in 1993 3, then renamed Gee Wizz! entertainment in 1996 on the release of their game Zombie Wars 4, it was formed by partners John Passfield and Steve Stamatiadis 5. It later became Krome Studios on the 1st November 1999 merging with Robert Walsh’s Pacific Interactive Entertainment 6.Despite all the evolution, the studio continued to be based in Brisbane, Australia.Interactive Binary Illusions (1993-1996)Interactive Binary Illusions (IBI) released their first game all the way back in 1993 called Alien Carnage (also known as Halloween Harry), followed by the graphic adventure Flight of the Amazon Queen in 1995 3.They were working on a third title called Stereo Jack for planned release in 1996, however due to lack of funding it has to be cancelled and the pair instead formed a new company called Gee Wizz! entertainment.Halloween Harry (1993) - Alien CarnageHalloween Harry was a join effort between SubZero Software (later became Mind Mechanics 7) and Interactive Binary Illusions, the game itself later got renamed to Alien Carnage to avoid the consumer thinking it was a game that could only be enjoyed on October 31st.John Passfield’s site has Alien Carnage (Halloween Harry) on the Free Stuff! - Passfield Games page but there is no download link, presumably the copyright of the game is owned by Apogee.Flight of the Amazon Queen (1995) - JASPER engineFlight of the Amazon Queen was released for DOS and Amiga in 1995 and then later Windows (2004), iPhone (2009), Mac (2013) and even Linux in 2021! 8.Since the company was so small the copyright for these games is owned by the two co-founders of IBI and John Passfield has generously uploaded the original version of Flight of the Amazon Queen to his personal website which you can download completely free from his Free Stuff! - Passfield Games page!We also highly recommend you buy the recent iOS re-release of the game on the App Store as its incredibly cheap and a great game to play on the go, along with supporting that amazing industry veteran Mr Passfield, a link to it is also available on his Free Stuff! - Passfield Games page.JASPAR (Queen) game engineThe game was built with a custom game engine called JASPAR (John And Steve’s Programmable Adventure Resource) and John even wrote some game editor tools 9: JOKER - JASPAR Object Kernel Editor Resource - Game Editor for building rooms (laying out of objects and actors and walk paths, etc) - may have worked with .JAS files CUTS - Game cutscene editor (it was also called ASE in Flight Of The Amazon Queen - Hall Of Light not sure if this is a typo or an alternative name) worked with .CUT files DOG - Dialogue Object Generation System - Conversation tree editor works with .DOG filesThe game was first written in AMOS BASIC, then converted to C code for the final Amiga build, then the PC version was a port of this C code by Tony Ball. According to John the C code contained a lot of emulated AMOS function calls and game was still edited on the AMIGA using JOKER as they were still all written in AMOS BASIC 9. It was compiled using the WATCOM C toolchain accorsing to strings in the Queen.exe file.The engine was the second non-LucasArts engine added to ScummVM on September 28th 2003 in version 0.6.0 where they called it the Queen engine due to the only game that used it was the Flight of the Amazon Queen and they possibly didn’t know about it being called JASPER at the time. The engine supports all known DOS and Amiga versions of the game, including multiple languages and demos 10.For more information, you absolutely must read John’s blog post on the making of the game Game Musings: Making of Flight of the Amazon Queen - A 20th Anniversary RetrospectiveWhat I also thought was super cool was at the end of John’s 2015 blog post he teased an Apple Watch version of the game with this screenshot:However it was never released due to John realizing that there’s no market on the watch for this kind of game., which is sad because I would love to have seen how well this works on a watch, maybe adverture games are the perfect candidate for watch games? Although to be honest although I own an apple watch I have never downloaded a game for it… maybe I need to be the change I want to see in the market.JASPAR2 game engineIn March 1997 they mentioned working on the new version of the engine JASPAR2 for their new game The Elf Lord’s Bane Quest Saga which sadly never got released 11.Which is a shame as the graphics were looking really nice for the prototype they showed off at E3:You can find out more about Bane Quest on the wayback machine archive of the official website: The Elf Lord’s Bain Quest SagaAs fascinating as the JASPAR engine is, this page is about Merkury and none of the Interactive Binary Illusions games have any hint of the Merkury (or Blast graphics) engines so lets keep going.Gee Wizz! entertainment (1996-1999)In 1996 Gee Wizz! entertainment was born and during their run until they become Krome Studios in 1999 they released the following games: Zombie Wars - 1996 on Windows, a sequal to Alien Carnage/Halloween Harry written in Delphi Mike Stewart’s Pro Bodyboarding - February 1999 on Windows The Chronicles of Jaruu Tenk - October 1999 on Windows (sold via ScreenOpera) Halloween Spirit Board - October 1999 on Windows (sold via ScreenOpera)The original Gee Wizz! entertainment site from back in March 1997 has the following to say about each of the original team members 5:# Steve StamatiadisSteve started out working in the comics field before he got into computer game design and graphics. After studying animation he worked on comics like The Statlight agency, Markam and even a did a short stint on From Hell as a background artist. In 1991 he worked on the movie Fortress after which he and John began work on Flight of the Amazon queen (which was done on a lowly Amiga). Today at Age 27 he is responsible for the look of Gee whiz! games and gets to work with more powerful machines and software to create really cool stuff.# John PassfieldJohn had his first computer game published in 1985 at the ripe old age of 17. He later studied computer science and worked as a programmer for a telecommunications company before co-founding Gee Whiz! Entertainment. John prefers to think of himself as a member of the \"Star Wars Generation\" rather then \"Generation X\". John likes to write comic books - his credits include a two year stint writing Dingo Boy and Vixen Rangers for one of Australia's largest selling magazines, Stereo Jack for Issue One Comics and Jace Riegel for Dark Horse Comics.# Robert CraneRobert is a 24 year old programmer who spent his whole life dedicated to the cause of proving that Pascal is every bit as good as \"C\" as a programming language. In the process he has developed an install program for DOS that games publisher Apogee picked up and uses for its shareware titles. He is also an acknowledged database programmer but likes to keep that secret. His strongest point is doing graphics tools like game systems and sprite editors. Being around so much graphics, he also likes to dabble in 3d modeling.# Tony BallTony has worked on many games, some of which actually made it onto the shelves, including Halloween Harry, Alien Carnage and Flight of the Amazon Queen. He specializes in 'C' and Intel Assembly, particularly graphics code, and is currently working on some really cool stuff with Gee Whiz! Entertainment.Zombie Wars (1996)Zombie Wars was a sequal to Halloween Harry released in 1996 and written in Delphi, it has the codename Harry95 left in the executable.Pratik Anand has reverse engineered the assets for Zombie wars and has an excellent write up here: Detective work on Reverse Engineering obscure 16-bit Windows game (Zombie Wars) · Pratik AnandSadly they found that reverse engineering an old Delphi executable is not easy with most modern tools. It is likely build using a very early version of Delphi such as 1.0 (1995) and their are tools that can help recovering the source files for Delphi 2.0/3.0 from compiled executables such as EXE2DPR - Delphi project sources Rescuer, but I don’t know of any software that works on 1.0 executables unfortunately.It was built using the Microsoft WinG library, which was the original name for DirectX. It also uses a library from SubZero Software with a build date of 4th December 1995. Since its assets are all stored in .SUB0 archives this hints at a library for packing game assets, SubZero Software are also listed as a join developer on the original Halloween Harry game.For the limited analysis of the binary I can do there doesn’t seem to be any connection between the game and what would become the Merkury engine or the 3d library Blast Graphics) and it was written in a completely different programming language so it is unlikely there is a strong connection.Delphi ProgrammingRobert Crane was a big fan of the Delphi programming language (Object Oriented version of Pascal) and exclaimed the following on the company website back in 1997 11: Let me say that if it wasn’t for Delphi, this project would have been a nightmare of great proportions. If there are any sceptics of what Delphi is capable of, wait ‘til they see Zombie Wars. Since all the coding of Zombie Wars (excluding graphics routines) is up to me, I have been REALLY busy just keeping up with the graphics that Steve does. I guess it is a little easier this time around because most of the code was a direct port from the old Halloween Harry. I am glad we chose to do the sequel though because I’ve added some really cool stuff to the engine.BEAST & Blast Graphics - The Original Merkury engineMany of the games listed on the official website in 2001 as being Merkury engine games refer to the engine under a different name BEAST and Blast graphics. Later on Krome would come to retroactively refer to these games as based on the Merkury engine.In the Help file for Mike Stewart’s Pro Bodyboarding it lists two libraries used for making the game, BEAST and Blast Graphics: Beast Game Engine Copyright © 1999 Mind Mechanics Blast Graphics 3D Engine Copyright © 1999 Tony BallBEAST Game EngineThe BEAST game engine was built by Mind Mechanics (SubZero Software) and was used for Mike Stewart’s Pro Bodyboarding and the surfing games that used the same engine.In Championship Surfer we can clearly see the engine was called BEAST: // For use with the BEAST Game Engine and contained a file called beast.cfg which is a plain text file with the text BEAST Config File at the top.It was always compiled into the main game executable so unlike the Blast Graphics 3d library we don’t have a lot of information on what functions it contained.What we do know is a few of the source file paths which were left in the Dreamcast version of championship surfer: C:\\Src\\beast98\\beast98.cpp - Dreamcast version of championship surfer C:\\Src\\beast98\\animscript.cpp - Dreamcast version of championship surfer d:\\beast\\FUNCDECS.CPP - Inside Mike Stewart’s Pro Bodyboarding Dso.bnkRelease/beast98.exeNB11P.\\Release\\beast98.res.\\Release\\StdAfx.obj.\\Release\\INSIDEPOly.obj.\\Release\\Filebank.obj.\\Release\\dxinput.obj.\\Release\\diskio.obj.\\Release\\beast98.obj.\\Release\\animscript.objMicrosoft CVTRES 5.00.1720.1C:\\beast\\INSIDEPOly.CPPC:\\bg\\Filebank.cppC:\\beast\\dxinput.cppC:\\beast\\diskio.cppC:\\beast\\beast98.cppC:\\beast\\animscript.cpp Type Address Demangled Name Symbol Name Segment 0x0000 0x401000 int __cdecl GetValidAnimStr(char *, char *, int) ?GetValidAnimStr@@YAHPAD0H@Z 0x100 0x0000 0x401100 int __cdecl DigitStr(char *, char *, int) ?DigitStr@@YAHPAD0H@Z 0x100 0x0000 0x401190 int __cdecl NonDigitStr(char *, char *, int) ?NonDigitStr@@YAHPAD0H@Z 0x100 0x0000 0x401220 void __cdecl ExtractFrameValues(char *, int &, int &, int &) ?ExtractFrameValues@@YAXPADAAH11@Z 0x100 0x0000 0x401340 public: void __thiscall ANIMATION::Reset(void) ?Reset@ANIMATION@@QAEXXZ 0x100 0x0000 0x401360 public: int __thiscall ANIMATION::GetFrameCount(void) ?GetFrameCount@ANIMATION@@QAEHXZ 0x100 0x0000 0x401370 public: int __thiscall ANIMATION::GetSpeed(void) ?GetSpeed@ANIMATION@@QAEHXZ 0x100 0x0000 0x401380 public: void __thiscall ANIMATION::NextFrame(void) ?NextFrame@ANIMATION@@QAEXXZ 0x100 0x0000 0x401500 public: int __thiscall ANIMATION::GetCurrFrameNr(void) ?GetCurrFrameNr@ANIMATION@@QAEHXZ 0x100 0x0000 0x401510 public: void __thiscall ANIMATION::SetCycle(int) ?SetCycle@ANIMATION@@QAEXH@Z 0x100 0x0000 0x401520 public: int __thiscall ANIMATION::GetCycle(void) ?GetCycle@ANIMATION@@QAEHXZ 0x100 0x0000 0x401530 public: void __thiscall ANIMATION::SetName(char *) ?SetName@ANIMATION@@QAEXPAD@Z 0x100 0x0000 0x401560 public: char * __thiscall ANIMATION::GetName(void) ?GetName@ANIMATION@@QAEPADXZ 0x100 0x0000 0x401570 public: void __thiscall ANIMATION::ProcessAnimData(char *) ?ProcessAnimData@ANIMATION@@QAEXPAD@Z 0x100 0x0000 0x401620 void __cdecl nonewline(char *) ?nonewline@@YAXPAD@Z 0x100 0x0000 0x401640 char * __cdecl StringRemainder(char *, int) ?StringRemainder@@YAPADPADH@Z 0x100 0x0000 0x4016A0 private: void __thiscall ANIMSCRIPT::ParseBadFile(struct _iobuf *) ?ParseBadFile@ANIMSCRIPT@@AAEXPAU_iobuf@@@Z 0x100 0x0000 0x401B30 public: void __thiscall ANIMSCRIPT::Load(char *) ?Load@ANIMSCRIPT@@QAEXPAD@Z 0x100 0x0000 0x401B70 public: int __thiscall ANIMSCRIPT::GetAnimNumber(char *) ?GetAnimNumber@ANIMSCRIPT@@QAEHPAD@Z 0x100 0x0000 0x401BF0 public: char * __thiscall ANIMSCRIPT::GetAnimName(int) ?GetAnimName@ANIMSCRIPT@@QAEPADH@Z 0x100 0x0000 0x401C60 public: int __thiscall ANIMSCRIPT::GetFPS(void) ?GetFPS@ANIMSCRIPT@@QAEHXZ 0x100 0x0000 0x401C70 public: int __thiscall ANIMSCRIPT::GetAnimCount(void) ?GetAnimCount@ANIMSCRIPT@@QAEHXZ 0x100 0x0000 0x401C80 public: void __thiscall ANIMSCRIPT::SetAnim(int) ?SetAnim@ANIMSCRIPT@@QAEXH@Z 0x100 0x0000 0x401CD0 public: int __thiscall ANIMSCRIPT::Animate(int) ?Animate@ANIMSCRIPT@@QAEHH@Z 0x100 0x0000 0x401D30 public: int __thiscall ANIMSCRIPT::GetCurrFrameNr(void) ?GetCurrFrameNr@ANIMSCRIPT@@QAEHXZ 0x100 0x0000 0x401D50 public: void __thiscall ANIMSCRIPT::Destroy(void) ?Destroy@ANIMSCRIPT@@QAEXXZ 0x100 0x0000 0x401D60 public: void __thiscall STRPACK::constructor(void) ??0STRPACK@@QAE@XZ 0x100 0x0000 0x401D80 public: void __thiscall STRPACK::LoadInto(char *) ?LoadInto@STRPACK@@QAEXPAD@Z 0x100 0x0000 0x401E70 public: char * __thiscall STRPACK::Get(int) ?Get@STRPACK@@QAEPADH@Z 0x100 0x0000 0x401E80 public: int __thiscall STRPACK::Count(void) ?Count@STRPACK@@QAEHXZ 0x100 0x0000 0x401E90 public: void __thiscall STRPACK::~destructor(void) ??1STRPACK@@QAE@XZ 0x100 0x0000 0x401FA0 int __cdecl RegisterItem(char *) ?RegisterItem@@YAHPAD@Z 0x100 0x0000 0x402270 struct _RegItem * __cdecl RegDelete(char *) ?RegDelete@@YAPAU_RegItem@@PAD@Z 0x100 0x0000 0x402370 void __cdecl BeastExit(void) ?BeastExit@@YAXXZ 0x100 0x0000 0x402730 int __cdecl CompStrI(char *, char *) ?CompStrI@@YAHPAD0@Z 0x100 0x0000 0x402860 void __cdecl PF(void) ?PF@@YAXXZ 0x100 0x0000 0x4028E0 void __cdecl myhandler(char *, char *) ?myhandler@@YAXPAD0@Z 0x100 0x0000 0x4029D0 char * __cdecl vSprintf(char *) ?vSprintf@@YAPADPADZZ 0x100 0x0000 0x402A60 int __cdecl vRandom(int) ?vRandom@@YAHH@Z 0x100 0x0000 0x402AF0 int __cdecl vRandom2(int, int) ?vRandom2@@YAHHH@Z 0x100 0x0000 0x402B90 void __cdecl vRandomize(int, int) ?vRandomize@@YAXHH@Z 0x100 0x0000 0x402C10 double __cdecl vFloor(float) ?vFloor@@YANM@Z 0x100 0x0000 0x402C30 int __cdecl vF2I(float) ?vF2I@@YAHM@Z 0x100 0x0000 0x402C50 int __cdecl vMAX(int, int) ?vMAX@@YAHHH@Z 0x100 0x0000 0x402C60 int __cdecl vMIN(int, int) ?vMIN@@YAHHH@Z 0x100 0x0000 0x402C70 int __cdecl vabs(int) ?vabs@@YAHH@Z 0x100 0x0000 0x402C80 float __cdecl vabsf(float) ?vabsf@@YAMM@Z 0x100 0x0000 0x402CA0 double __cdecl vSin(double) ?vSin@@YANN@Z 0x100 0x0000 0x402CB0 double __cdecl vCos(double) ?vCos@@YANN@Z 0x100 0x0000 0x402CC0 double __cdecl vATan2(double, double) ?vATan2@@YANNN@Z 0x100 0x0000 0x402CF0 double __cdecl vSqrt(double) ?vSqrt@@YANN@Z 0x100 0x0000 0x402D10 double __cdecl vACos(double) ?vACos@@YANN@Z 0x100 0x0000 0x402D40 void __cdecl vMove(void *, void *, int) ?vMove@@YAXPAX0H@Z 0x100 0x0000 0x402DC0 double __cdecl vatof(char *) ?vatof@@YANPAD@Z 0x100 0x0000 0x402DD0 int __cdecl vatoi(char *) ?vatoi@@YAHPAD@Z 0x100 0x0000 0x402E10 char * __cdecl vStrc(int) ?vStrc@@YAPADH@Z 0x100 0x0000 0x402E30 int __cdecl vStrl(char *) ?vStrl@@YAHPAD@Z 0x100 0x0000 0x402E50 int __cdecl vKey(int) ?vKey@@YAHH@Z 0x100 0x0000 0x402E70 void * __cdecl vGetMem(int) ?vGetMem@@YAPAXH@Z 0x100 0x0000 0x402EF0 void __cdecl vFreeMem(void *) ?vFreeMem@@YAXPAX@Z 0x100 0x0000 0x402F60 float __cdecl vGetObjYWidth(int, int) ?vGetObjYWidth@@YAMHH@Z 0x100 0x0000 0x403000 float __cdecl vGetObjXWidth(int, int) ?vGetObjXWidth@@YAMHH@Z 0x100 0x0000 0x4030A0 float __cdecl vGetObjZWidth(int, int) ?vGetObjZWidth@@YAMHH@Z 0x100 0x0000 0x403140 void __cdecl vBG_GetObjectBox(int, float *, float *, float *, float *, float *, float *) ?vBG_GetObjectBox@@YAXHPAM00000@Z 0x100 0x0000 0x4031D0 void __cdecl vBG_MatriceClear(void) ?vBG_MatriceClear@@YAXXZ 0x100 0x0000 0x403270 void __cdecl vDOUT(char *) ?vDOUT@@YAXPADZZ 0x100 0x0000 0x403360 void __cdecl vFreeSFX(int) ?vFreeSFX@@YAXH@Z 0x100 0x0000 0x403430 int __cdecl vLoadSFX(char *) ?vLoadSFX@@YAHPAD@Z 0x100 0x0000 0x403600 void __cdecl vPlaySFX(int, int, float, float, float, int) ?vPlaySFX@@YAXHHMMMH@Z 0x100 0x0000 0x4036C0 void __cdecl vSFXSetD(int, unsigned int, float, float, float) ?vSFXSetD@@YAXHIMMM@Z 0x100 0x0000 0x4036D0 void __cdecl vStopSFX(int) ?vStopSFX@@YAXH@Z 0x100 0x0000 0x403770 int __cdecl vPlayingSFX(int) ?vPlayingSFX@@YAHH@Z 0x100 0x0000 0x403790 void __cdecl vKillSFX(int) ?vKillSFX@@YAXH@Z 0x100 0x0000 0x403830 int __cdecl vJoyUp(int) ?vJoyUp@@YAHH@Z 0x100 0x0000 0x403900 int __cdecl vJoyDown(int) ?vJoyDown@@YAHH@Z 0x100 0x0000 0x4039D0 int __cdecl vJoyLeft(int) ?vJoyLeft@@YAHH@Z 0x100 0x0000 0x403AA0 int __cdecl vJoyRight(int) ?vJoyRight@@YAHH@Z 0x100 0x0000 0x403B70 int __cdecl vJoyFire(int, int) ?vJoyFire@@YAHHH@Z 0x100 0x0000 0x403C40 void __cdecl vFree3D(int) ?vFree3D@@YAXH@Z 0x100 0x0000 0x403D00 int __cdecl vLoad3D(char *) ?vLoad3D@@YAHPADZZ 0x100 0x0000 0x403F10 void __cdecl vKillObject(void *) ?vKillObject@@YAXPAX@Z 0x100 0x0000 0x404020 void * __cdecl vGetObj(int, int) ?vGetObj@@YAPAXHH@Z 0x100 0x0000 0x404060 void * __cdecl vGetPlayer(int) ?vGetPlayer@@YAPAXH@Z 0x100 0x0000 0x404070 void * __cdecl vGetInfo(int, int, int, int) ?vGetInfo@@YAPAXHHHH@Z 0x100 0x0000 0x404270 void __cdecl ReloadVALSettings(void) ?ReloadVALSettings@@YAXXZ 0x100 0x0000 0x4042C0 void __cdecl ReadandSpawn(void) ?ReadandSpawn@@YAXXZ 0x100 0x0000 0x4042D0 void __cdecl LoadSOLFile(char *) ?LoadSOLFile@@YAXPAD@Z 0x100 0x0000 0x404640 void __cdecl vLoad_LEV_File(char *) ?vLoad_LEV_File@@YAXPADZZ 0x100 0x0000 0x4049E0 int __cdecl vDSprite(struct _dsprite *) ?vDSprite@@YAHPAU_dsprite@@@Z 0x100 0x0000 0x404B60 void __cdecl vClearAllObjects(void) ?vClearAllObjects@@YAXXZ 0x100 0x0000 0x404C40 void __cdecl vLoadingScreen(char *) ?vLoadingScreen@@YAXPAD@Z 0x100 0x0000 0x404D80 void __cdecl vPushCameraState(void) ?vPushCameraState@@YAXXZ 0x100 0x0000 0x404E40 void __cdecl vBG_SetCamera(float, float, float, float, float) ?vBG_SetCamera@@YAXMMMMM@Z 0x100 0x0000 0x404ED0 void __cdecl vPopCameraState(void) ?vPopCameraState@@YAXXZ 0x100 0x0000 0x405050 void __cdecl vClearScreen(void) ?vClearScreen@@YAXXZ 0x100 0x0000 0x405110 void __cdecl vLoadObject0(char *) ?vLoadObject0@@YAXPAD@Z 0x100 0x0000 0x405190 void __cdecl vInitVALFile(char *) ?vInitVALFile@@YAXPAD@Z 0x100 0x0000 0x405210 char * __cdecl vGetStrValue(char *) ?vGetStrValue@@YAPADPAD@Z 0x100 0x0000 0x405370 int __cdecl vGetIntValue(char *) ?vGetIntValue@@YAHPAD@Z 0x100 0x0000 0x405390 double __cdecl vGetFloatValue(char *) ?vGetFloatValue@@YANPAD@Z 0x100 0x0000 0x4053F0 void __cdecl vOpenFile(char *) ?vOpenFile@@YAXPADZZ 0x100 0x0000 0x4054A0 char * __cdecl vReadFile(void) ?vReadFile@@YAPADXZ 0x100 0x0000 0x4054B0 void __cdecl vCloseFile(void) ?vCloseFile@@YAXXZ 0x100 0x0000 0x4054C0 double __cdecl vAngleDif(float, float) ?vAngleDif@@YANMM@Z 0x100 0x0000 0x405560 unsigned int __cdecl vLoadDLL(char *) ?vLoadDLL@@YAIPAD@Z 0x100 0x0000 0x405720 void * __cdecl vGetProcAddr(unsigned int, char *) ?vGetProcAddr@@YAPAXIPAD@Z 0x100 0x0000 0x405800 int __cdecl vAS_Load(char *) ?vAS_Load@@YAHPAD@Z 0x100 0x0000 0x405A30 int __cdecl vAS_GetAnim(int, char *) ?vAS_GetAnim@@YAHHPAD@Z 0x100 0x0000 0x405A50 void __cdecl vAS_SetAnim(int, int) ?vAS_SetAnim@@YAXHH@Z 0x100 0x0000 0x405AD0 int __cdecl vAS_Animate(int, int) ?vAS_Animate@@YAHHH@Z 0x100 0x0000 0x405AF0 char __cdecl vCompareStr(char *, char *) ?vCompareStr@@YADPAD0@Z 0x100 0x0000 0x405B10 void __cdecl vRunMenu(void) ?vRunMenu@@YAXXZ 0x100 0x0000 0x405B80 struct HINSTANCE__ * __cdecl LoadDLL(char *) ?LoadDLL@@YAPAUHINSTANCE__@@PAD@Z 0x100 0x0000 0x405F30 int __cdecl vBFileOpen(char *, char *) ?vBFileOpen@@YAHPAD0@Z 0x100 0x0000 0x405FD0 int __cdecl vBFileRead(void *, int) ?vBFileRead@@YAHPAXH@Z 0x100 0x0000 0x406060 void __cdecl vBFileWrite(void *, int) ?vBFileWrite@@YAXPAXH@Z 0x100 0x0000 0x4060E0 void __cdecl vBFileClose(void) ?vBFileClose@@YAXXZ 0x100 0x0000 0x406160 double __cdecl vA2F(char *) ?vA2F@@YANPAD@Z 0x100 0x0000 0x406170 int __cdecl vA2I(char *) ?vA2I@@YAHPAD@Z 0x100 0x0000 0x406180 char * __cdecl vI2A(int) ?vI2A@@YAPADH@Z 0x100 0x0000 0x4061A0 double __cdecl vI2F(int) ?vI2F@@YANH@Z 0x100 0x0000 0x4061D0 char * __cdecl vF2A(double) ?vF2A@@YAPADN@Z 0x100 0x0000 0x406200 int __cdecl vFileExists(char *) ?vFileExists@@YAHPADZZ 0x100 0x0000 0x4062D0 void __cdecl vFAIL(void) ?vFAIL@@YAXXZ 0x100 0x0000 0x4062E0 void __cdecl SetupCalls(void) ?SetupCalls@@YAXXZ 0x100 0x0000 0x406670 struct Object * __cdecl LoadObject(char *, char *) ?LoadObject@@YAPAUObject@@PAD0@Z 0x100 0x0000 0x4066F0 void * __cdecl vSpawnObject(int, float, float, float, void *) ?vSpawnObject@@YAPAXHMMMPAX@Z 0x100 0x0000 0x406990 void __cdecl Init(void) ?Init@@YAXXZ 0x100 0x0000 0x406AC0 void __cdecl DoLogics(void) ?DoLogics@@YAXXZ 0x100 0x0000 0x406D30 void __cdecl DoDraws(void) ?DoDraws@@YAXXZ 0x100 0x0000 0x406F70 void __cdecl GetDetailsfromINI(void) ?GetDetailsfromINI@@YAXXZ 0x100 0x0000 0x407380 int __cdecl GetKeyStr(int) ?GetKeyStr@@YAHH@Z 0x100 0x0000 0x408250 int __cdecl GetJoyStr(int) ?GetJoyStr@@YAHH@Z 0x100 0x0000 0x408390 void __cdecl Menu_Screen_DefineKeys(int) ?Menu_Screen_DefineKeys@@YAXH@Z 0x100 0x0000 0x408C30 void __cdecl Menu_Screen_DefineJoy(int) ?Menu_Screen_DefineJoy@@YAXH@Z 0x100 0x0000 0x409900 void __cdecl Menu_Screen_Controls(void) ?Menu_Screen_Controls@@YAXXZ 0x100 0x0000 0x40A410 void __cdecl Menu_Screen(void) ?Menu_Screen@@YAXXZ 0x100 0x0000 0x40B120 void __cdecl KillTempFiles(void) ?KillTempFiles@@YAXXZ 0x100 0x0000 0x40B240 void __cdecl RunHub(void) ?RunHub@@YAXXZ 0x100 0x0000 0x40B500 void __cdecl FreeDLLs(void) ?FreeDLLs@@YAXXZ 0x100 0x0000 0x40B510 void __cdecl RemoveAllTempFiles(void) ?RemoveAllTempFiles@@YAXXZ 0x100 0x0000 0x40B520 void __cdecl LoadAllDLLs(void) ?LoadAllDLLs@@YAXXZ 0x100 0x0000 0x40B830 void __cdecl RemoveAllDLLs(void) ?RemoveAllDLLs@@YAXXZ 0x100 0x0000 0x40B8E0 void __cdecl PrintOutAllStats(void) ?PrintOutAllStats@@YAXXZ 0x100 0x0000 0x40BEC0 void __cdecl Test4INIFile(void) ?Test4INIFile@@YAXXZ 0x100 0x0000 0x40BF80 void __cdecl LiftAndSeperate(void) ?LiftAndSeperate@@YAXXZ 0x100 0x0000 0x40C0A0 void __cdecl FormCreate(void) ?FormCreate@@YAXXZ 0x100 0x0000 0x40C1E0 void __cdecl ShowEntryScreens(void) ?ShowEntryScreens@@YAXXZ 0x100 0x0000 0x40C3A0 void __cdecl ShowExitScreens(void) ?ShowExitScreens@@YAXXZ 0x100 0x0000 0x40C570 void __cdecl ReadInBeastCFGValues(void) ?ReadInBeastCFGValues@@YAXXZ 0x100 0x0000 0x40C980 void __cdecl SaveOutBeastCFGValues(void) ?SaveOutBeastCFGValues@@YAXXZ 0x100 0x0000 0x40CCD0 void __cdecl Timer1Timer(void) ?Timer1Timer@@YAXXZ 0x100 0x0000 0x40D040 void __cdecl ExitGame(void) ?ExitGame@@YAXXZ 0x100 0x0000 0x40D070 void __cdecl CheckMessages(void) ?CheckMessages@@YAXXZ 0x100 0x0000 0x40D230 unsigned short int cdecl MyRegisterClass(struct HINSTANCE *) ?MyRegisterClass@@YAGPAUHINSTANCE__@@@Z 0x100 0x0000 0x40D2C0 int cdecl InitInstance(struct HINSTANCE *, int) ?InitInstance@@YAHPAUHINSTANCE__@@H@Z 0x100 0x0000 0x40D330 long int stdcall WndProc(struct HWND *, unsigned int, unsigned int, long int) ?WndProc@@YGJPAUHWND__@@IIJ@Z 0x100 0x0000 0x40D470 _WinMain@16 _WinMain@16 0x100 0x0000 0x40D710 public: void __thiscall BG::constructor(void) ??0BG@@QAE@XZ 0x100 0x0000 0x40E2C0 void __cdecl expand(struct _iobuf *) ?expand@@YAXPAU_iobuf@@@Z 0x100 0x0000 0x40E420 int __cdecl ExtractFromBank(char *, char *) ?ExtractFromBank@@YAHPAD0@Z 0x100 0x0000 0x40E510 unsigned char * __cdecl extract_file(char *, unsigned int *) ?extract_file@@YAPAEPADPAI@Z 0x100 0x0000 0x40E640 public: void __thiscall fileio::constructor(char *) ??0fileio@@QAE@PAD@Z 0x100 0x0000 0x40E670 public: void __thiscall fileio::open(char *) ?open@fileio@@QAEXPAD@Z 0x100 0x0000 0x40E7C0 public: void __thiscall fileio::close(void) ?close@fileio@@QAEXXZ 0x100 0x0000 0x40E7F0 public: void __thiscall fileio::~destructor(void) ??1fileio@@QAE@XZ 0x100 0x0000 0x40E810 public: void __thiscall fileio::reset(int) ?reset@fileio@@QAEXH@Z 0x100 0x0000 0x40E830 public: long int __thiscall fileio::size(void) ?size@fileio@@QAEJXZ 0x100 0x0000 0x40E840 public: long int __thiscall fileio::pos(void) ?pos@fileio@@QAEJXZ 0x100 0x0000 0x40E850 public: unsigned short int __thiscall fileio::getword(void) ?getword@fileio@@QAEGXZ 0x100 0x0000 0x40E890 public: unsigned char __thiscall fileio::getbyte(void) ?getbyte@fileio@@QAEEXZ 0x100 0x0000 0x40E8B0 public: long int __thiscall fileio::getlong(void) ?getlong@fileio@@QAEJXZ 0x100 0x0000 0x40E900 public: void __thiscall fileio::get(void *, int) ?get@fileio@@QAEXPAXH@Z 0x100 0x0000 0x40E950 public: unsigned char __thiscall fileio::eof(void) ?eof@fileio@@QAEEXZ 0x100 0x0000 0x40E960 public: long int __thiscall fileio::togo(void) ?togo@fileio@@QAEJXZ 0x100 0x0000 0x40E970 public: void __thiscall fileio::write(void *, int) ?write@fileio@@QAEXPAXH@Z 0x100 0x0000 0x40E9D0 public: void __thiscall fileio::writetofile(char *) ?writetofile@fileio@@QAEXPAD@Z 0x100 0x0000 0x40EA60 public: char * __thiscall fileio::readline(void) ?readline@fileio@@QAEPADXZ 0x100 0x0000 0x40EB10 unsigned int __cdecl joyGetOEMProductName(unsigned int, char *) ?joyGetOEMProductName@@YAIIPAD@Z 0x100 0x0000 0x40ECB0 int __cdecl DXI_Init(void) ?DXI_Init@@YAHXZ 0x100 0x0000 0x40EE10 void __cdecl DXI_Destroy(void) ?DXI_Destroy@@YAXXZ 0x100 0x0000 0x40EE20 int __cdecl DXI_Total(void) ?DXI_Total@@YAHXZ 0x100 0x0000 0x40EE30 char * __cdecl DXI_GetName(int) ?DXI_GetName@@YAPADH@Z 0x100 0x0000 0x40EE50 void __cdecl DXI_Update(void) ?DXI_Update@@YAXXZ 0x100 0x0000 0x40EEB0 int __cdecl DXI_Left(int) ?DXI_Left@@YAHH@Z 0x100 0x0000 0x40EF10 int __cdecl DXI_Right(int) ?DXI_Right@@YAHH@Z 0x100 0x0000 0x40EF70 int __cdecl DXI_Up(int) ?DXI_Up@@YAHH@Z 0x100 0x0000 0x40EFD0 int __cdecl DXI_Down(int) ?DXI_Down@@YAHH@Z 0x100 0x0000 0x40F030 int __cdecl DXI_Fire(int, int) ?DXI_Fire@@YAHHH@Z 0x100 0x0000 0x40F070 int __cdecl fexists(char *) ?fexists@@YAHPAD@Z 0x100 0x0000 0x40F0A0 public: void __thiscall FileBank::Init(char *) ?Init@FileBank@@QAEXPAD@Z 0x100 0x0000 0x40F1A0 void __cdecl BuildBank(char *, char *, char *) ?BuildBank@@YAXPAD00@Z 0x100 0x0000 0x40F300 public: char * __thiscall FileBank::Extract(char *) ?Extract@FileBank@@QAEPADPAD@Z 0x100 0x0000 0x40F4D0 public: int __thiscall FileBank::Exists(char *) ?Exists@FileBank@@QAEHPAD@Z 0x100 0x0000 0x40F540 int __cdecl insidepoly(float, float, int, struct insidepoint *) ?insidepoly@@YAHMMHPAUinsidepoint@@@Z 0x100 0x0000 0x40F600 _WinExec@8 _WinExec@8 0x100 0x0000 0x40F606 _GetWindowsDirectoryA@8 _GetWindowsDirectoryA@8 0x100 0x0000 0x40F60C _GetCommandLineA@0 _GetCommandLineA@0 0x100 0x0000 0x40F612 _GetLastError@0 _GetLastError@0 0x100 0x0000 0x40F618 _LoadLibraryA@4 _LoadLibraryA@4 0x100 0x0000 0x40F61E _GetProcAddress@8 _GetProcAddress@8 0x100 0x0000 0x40F624 _FreeLibrary@4 _FreeLibrary@4 0x100 0x0000 0x40F62A _GetDriveTypeA@4 _GetDriveTypeA@4 0x100 0x0000 0x40F630 _GetDiskFreeSpaceExA@16 _GetDiskFreeSpaceExA@16 0x100 0x0000 0x40F636 _GlobalMemoryStatus@4 _GlobalMemoryStatus@4 0x100 0x0000 0x40F63C _ExitProcess@4 _ExitProcess@4 0x100 0x0000 0x40F642 _ClipCursor@4 _ClipCursor@4 0x100 0x0000 0x40F648 _GetAsyncKeyState@4 _GetAsyncKeyState@4 0x100 0x0000 0x40F64E _GetCursorPos@4 _GetCursorPos@4 0x100 0x0000 0x40F654 _ShowCursor@4 _ShowCursor@4 0x100 0x0000 0x40F65A _MessageBoxA@16 _MessageBoxA@16 0x100 0x0000 0x40F660 _DestroyWindow@4 _DestroyWindow@4 0x100 0x0000 0x40F666 _GetMessageA@16 _GetMessageA@16 0x100 0x0000 0x40F66C _DispatchMessageA@4 _DispatchMessageA@4 0x100 0x0000 0x40F672 _TranslateMessage@4 _TranslateMessage@4 0x100 0x0000 0x40F678 _PeekMessageA@20 _PeekMessageA@20 0x100 0x0000 0x40F67E _RegisterClassExA@4 _RegisterClassExA@4 0x100 0x0000 0x40F684 _LoadCursorA@8 _LoadCursorA@8 0x100 0x0000 0x40F68A _LoadIconA@8 _LoadIconA@8 0x100 0x0000 0x40F690 _UpdateWindow@4 _UpdateWindow@4 0x100 0x0000 0x40F696 _ShowWindow@8 _ShowWindow@8 0x100 0x0000 0x40F69C _CreateWindowExA@48 _CreateWindowExA@48 0x100 0x0000 0x40F6A2 _DefWindowProcA@16 _DefWindowProcA@16 0x100 0x0000 0x40F6A8 _SetForegroundWindow@4 _SetForegroundWindow@4 0x100 0x0000 0x40F6AE _LoadAcceleratorsA@8 _LoadAcceleratorsA@8 0x100 0x0000 0x40F6B4 _LoadStringA@16 _LoadStringA@16 0x100 0x0000 0x40F6BA _GetActiveWindow@0 _GetActiveWindow@0 0x100 0x0000 0x40F6C0 _RegCloseKey@4 _RegCloseKey@4 0x100 0x0000 0x40F6C6 _RegQueryValueExA@24 _RegQueryValueExA@24 0x100 0x0000 0x40F6CC _RegOpenKeyExA@20 _RegOpenKeyExA@20 0x100 0x0000 0x40F6D2 _timeGetTime@0 _timeGetTime@0 0x100 0x0000 0x40F6D8 _joyGetDevCapsA@12 _joyGetDevCapsA@12 0x100 0x0000 0x40F6DE _joyGetNumDevs@0 _joyGetNumDevs@0 0x100 0x0000 0x40F6E4 _joyGetPosEx@8 _joyGetPosEx@8 0x100 0x0000 0x40F6EA _isalpha _isalpha 0x100 0x0000 0x40F718 _isupper _isupper 0x100 0x0000 0x40F740 _islower _islower 0x100 0x0000 0x40F768 _isdigit _isdigit 0x100 0x0000 0x40F790 _isxdigit _isxdigit 0x100 0x0000 0x40F7BD _isspace _isspace 0x100 0x0000 0x40F7E5 _ispunct _ispunct 0x100 0x0000 0x40F80D _isalnum _isalnum 0x100 0x0000 0x40F83B _isprint _isprint 0x100 0x0000 0x40F869 _isgraph _isgraph 0x100 0x0000 0x40F897 _iscntrl _iscntrl 0x100 0x0000 0x40F8BF ___isascii ___isascii 0x100 0x0000 0x40F8CC ___toascii ___toascii 0x100 0x0000 0x40F8D4 ___iscsymf ___iscsymf 0x100 0x0000 0x40F911 ___iscsym ___iscsym 0x100 0x0000 0x40F94E _atol _atol 0x100 0x0000 0x40F9D9 _atoi _atoi 0x100 0x0000 0x40F9E4 __atoi64 __atoi64 0x100 0x0000 0x40FAA0 _strncmp _strncmp 0x100 0x0000 0x40FAD8 _fgets _fgets 0x100 0x0000 0x40FB3A _fclose _fclose 0x100 0x0000 0x40FB6B __fclose_lk __fclose_lk 0x100 0x0000 0x40FBB7 __fsopen __fsopen 0x100 0x0000 0x40FBE8 _fopen _fopen 0x100 0x0000 0x40FBFB _sprintf _sprintf 0x100 0x0000 0x40FC4D void * __cdecl operator new(unsigned int) ??2@YAPAXI@Z 0x100 0x0000 0x40FC5B void __cdecl operator delete(void *) ??3@YAXPAX@Z 0x100 0x0000 0x40FC66 void __stdcall _JumpToContinuation(void *, struct EHRegistrationNode *) ?_JumpToContinuation@@YGXPAXPAUEHRegistrationNode@@@Z 0x100 0x0000 0x40FC9A void __stdcall _CallMemberFunction0(void *, void *) ?_CallMemberFunction0@@YGXPAX0@Z 0x100 0x0000 0x40FCA1 void __stdcall _CallMemberFunction1(void *, void *, void *) ?_CallMemberFunction1@@YGXPAX00@Z 0x100 0x0000 0x40FCA8 void __stdcall _CallMemberFunction2(void *, void *, void *, int) ?_CallMemberFunction2@@YGXPAX00H@Z 0x100 0x0000 0x40FCAF void __stdcall _UnwindNestedFrames(struct EHRegistrationNode *, struct EHExceptionRecord *) ?_UnwindNestedFrames@@YGXPAUEHRegistrationNode@@PAUEHExceptionRecord@@@Z 0x100 0x0000 0x40FCFE ___CxxFrameHandler ___CxxFrameHandler 0x100 0x0000 0x40FD34 ___CxxLongjmpUnwind@4 ___CxxLongjmpUnwind@4 0x100 0x0000 0x40FD4E void * __cdecl _CallCatchBlock2(struct EHRegistrationNode *, struct _s_FuncInfo const *, void *, int, unsigned long int) ?_CallCatchBlock2@@YAPAXPAUEHRegistrationNode@@PBU_s_FuncInfo@@PAXHK@Z 0x100 0x0000 0x40FDC7 int __cdecl _CallSETranslator(struct EHExceptionRecord *, struct EHRegistrationNode *, void *, void *, struct _s_FuncInfo const *, int, struct EHRegistrationNode *) ?_CallSETranslator@@YAHPAUEHExceptionRecord@@PAUEHRegistrationNode@@PAX2PBU_s_FuncInfo@@H1@Z 0x100 0x0000 0x40FEF2 struct _s_TryBlockMapEntry const * __cdecl _GetRangeOfTrysToCheck(struct _s_FuncInfo const *, int, int, unsigned int *, unsigned int *) ?_GetRangeOfTrysToCheck@@YAPBU_s_TryBlockMapEntry@@PBU_s_FuncInfo@@HHPAI1@Z 0x100 0x0000 0x40FF70 __global_unwind2 __global_unwind2 0x100 0x0000 0x40FFB2 __local_unwind2 __local_unwind2 0x100 0x0000 0x41000A __NLG_Return2 __NLG_Return2 0x100 0x0000 0x41001A __abnormal_termination __abnormal_termination 0x100 0x0000 0x41003D __NLG_Notify1 __NLG_Notify1 0x100 0x0000 0x410046 __NLG_Notify __NLG_Notify 0x100 0x0000 0x410059 __NLG_Dispatch __NLG_Dispatch 0x100 0x0000 0x41005E __onexit __onexit 0x100 0x0000 0x4100DC _atexit _atexit 0x100 0x0000 0x4100EE ___onexitinit ___onexitinit 0x100 0x0000 0x41011D _fprintf _fprintf 0x100 0x0000 0x410159 _vsprintf _vsprintf 0x100 0x0000 0x4101AA _srand _srand 0x100 0x0000 0x4101B7 _rand _rand 0x100 0x0000 0x4101D9 _floor _floor 0x100 0x0000 0x4102A8 __fpmath __fpmath 0x100 0x0000 0x4102BF __fpclear __fpclear 0x100 0x0000 0x4102C0 __cfltcvt_init __cfltcvt_init 0x100 0x0000 0x4102F8 ___setfflag ___setfflag 0x100 0x0000 0x410308 __ftol __ftol 0x100 0x0000 0x410330 __CIacos __CIacos 0x100 0x0000 0x410344 _acos _acos 0x100 0x0000 0x4103FB _atof _atof 0x100 0x0000 0x410460 _fmod _fmod 0x100 0x0000 0x41046A __CIfmod __CIfmod 0x100 0x0000 0x410492 __cinit __cinit 0x100 0x0000 0x4104BF _exit _exit 0x100 0x0000 0x4104D0 __exit __exit 0x100 0x0000 0x4104E1 __cexit __cexit 0x100 0x0000 0x4104F0 __c_exit __c_exit 0x100 0x0000 0x4105A4 __lockexit __lockexit 0x100 0x0000 0x4105AD __unlockexit __unlockexit 0x100 0x0000 0x4105E0 _strchr _strchr 0x100 0x0000 0x4105E6 ___from_strstr_to_strchr ___from_strstr_to_strchr 0x100 0x0000 0x41069C _sscanf _sscanf 0x100 0x0000 0x4106D0 _strstr _strstr 0x100 0x0000 0x410750 _fread _fread 0x100 0x0000 0x41077F __fread_lk __fread_lk 0x100 0x0000 0x410867 _fwrite _fwrite 0x100 0x0000 0x410896 __fwrite_lk __fwrite_lk 0x100 0x0000 0x4109A0 _rewind _rewind 0x100 0x0000 0x410A04 __findfirst __findfirst 0x100 0x0000 0x410AD1 __findnext __findnext 0x100 0x0000 0x410B99 __findclose __findclose 0x100 0x0000 0x410BB9 ___timet_from_ft ___timet_from_ft 0x100 0x0000 0x410C1D _remove _remove 0x100 0x0000 0x410C47 __unlink __unlink 0x100 0x0000 0x410C52 _calloc _calloc 0x100 0x0000 0x410CDF _time _time 0x100 0x0000 0x410DBB _fseek _fseek 0x100 0x0000 0x410DE7 __fseek_lk __fseek_lk 0x100 0x0000 0x410E74 _ftell _ftell 0x100 0x0000 0x410E96 __ftell_lk __ftell_lk 0x100 0x0000 0x410FF7 _realloc _realloc 0x100 Blast Graphics 3D library (bg.dll)The Blast Graphics 3d library, which is 3D library used in early Merkury engine games is either located in the bg.dll file or compiled statically in the executable.The following games have references to Blast graphics in their executables or contain the windows dynamic library bg.dll: Gruesome Castle Demo - bg.dll dated 12th January 1998 (96 KB, 361 functions) Mike Stewart’s Pro Bodyboarding (Australian version) - bg.dll dated 30th May 1999 (258KB, 489 functions) Halloween Spirit Board - bg.dll dated 12th September 1999 (369KB, 1018 functions) The Chronicles of Jaruu Tenk - bg.dll dated 8th Oct 1999 (360KB, 1020 functions) Mike Stewart’s Pro Bodyboarding - bg.dll dated 26th October 1999 (352KB, 1019 functions) Championship Surfer - bg.dll dated 28th September 2000 (217KB, 613 functions) Disney’s Extremely Goofy Skateboarding - Blast Graphics is compiled statically in the executable, dated 23rd August 2001Known Blast Graphics Source filesThanks to compilers adding some additional metadata we know at least some of the file names that made up the source code for the Blast Graphics Library: C:\\bg\\Bgunit.cpp - From MSPB (Aus) Along with .\\Release\\Bgunit.obj and C:\\bg\\bgunit.hKnown Blast Graphics functionsLooking at the exports table of one the the dlls we know it has the following functionality: Name Location Function Signature Function Size (bytes) Description AVIFileExit 0x10032f0a AVIFileExit() 6   AVIFileInit 0x10032f34 AVIFileInit() 6   AVIStreamInfoA 0x10032f1c AVIStreamInfoA() 6   AVIStreamLength 0x10032f22 AVIStreamLength() 6   AVIStreamOpenFromFileA 0x10032f2e AVIStreamOpenFromFileA() 6   AVIStreamRead 0x10032f46 AVIStreamRead() 6   AVIStreamReadFormat 0x10032f28 AVIStreamReadFormat() 6   AVIStreamRelease 0x10032f10 AVIStreamRelease() 6   BG_AddObject 0x1000d1f0 BG_AddObject(param_1, param_2, param_3, param_4, param_5, param_6, param_7, param_8) 5127   BG_AddProjection 0x10010380 BG_AddProjection(param_1, param_2, param_3, param_4, param_5, param_6) 835   BG_AddQuad 0x1000eda0 BG_AddQuad(param_1, param_2, param_3) 5566   BG_AddSprite 0x10008290 BG_AddSprite(param_1, param_2, param_3, param_4, param_5, param_6, param_7, param_8, param_9, param_10) 5445   BG_AddSpriteSection 0x10008240 BG_AddSpriteSection(param_1, param_2, param_3, param_4, param_5, param_6, param_7, param_8, param_9, param_10, param_11) 78   BG_AddText 0x10001aa0 BG_AddText(param_1, param_2, param_3, param_4, param_5) 1030   BG_AddText2 0x10001eb0 BG_AddText2(param_1, param_2, param_3, param_4, param_5, param_6) 1030   BG_AllocObject 0x100028a0 BG_AllocObject() 43   BG_AlterVertice 0x10005500 BG_AlterVertice(param_1, param_2, param_3, param_4, param_5) 93   BG_Animate 0x100055e0 BG_Animate(param_1, param_2) 60   BG_AnimateCustom 0x100056e0 BG_AnimateCustom(param_1, param_2, param_3) 683   BG_AnimateNode 0x10005620 BG_AnimateNode(param_1, param_2, param_3, param_4) 177   BG_BeginFullscreen 0x10012750 BG_BeginFullscreen() 6   BG_CallLogics 0x10012370 BG_CallLogics() 198   BG_ChangeRes 0x10023160 BG_ChangeRes() 1   BG_ClearObjects 0x100231b0 BG_ClearObjects() 78   BG_ClearRGB 0x1001e870 BG_ClearRGB(param_1, param_2, param_3) 861   BG_ClipOff 0x10002490 BG_ClipOff() 28   BG_ClipOn 0x1001f470 BG_ClipOn(param_1, param_2, param_3, param_4) 280   BG_CopyTexture 0x1001d0c0 BG_CopyTexture(param_1, param_2) 345   BG_CreateFont 0x1001ef40 BG_CreateFont(param_1, param_2) 1197   BG_DebugText 0x10002430 BG_DebugText(param_1) 41   BG_Disable 0x1001dfc0 BG_Disable(param_1) 52   BG_DisableOmni 0x10009c20 BG_DisableOmni(param_1) 37   BG_DrawBkg 0x1001fa40 BG_DrawBkg(param_1) 378   BG_DrawObjects 0x10020c80 BG_DrawObjects() 6096   BG_DrawOverlay 0x10020140 BG_DrawOverlay(param_1, param_2, param_3, param_4, param_5, param_6, param_7, param_8, param_9, param_10, param_11, param_12, param_13, param_14, param_15, param_16, param_17, param_18, param_19, param_20, param_21, param_22) 2797   BG_DrawText 0x100022c0 BG_DrawText(param_1, param_2, param_3, param_4, param_5, param_6) 359   BG_Enable 0x1001df40 BG_Enable(param_1) 51   BG_EnableOmni 0x10009c50 BG_EnableOmni(param_1, param_2, param_3, param_4, param_5, param_6, param_7, param_8) 345   BG_EnableSub 0x100016d0 BG_EnableSub(param_1, param_2, param_3) 50   BG_EnableVal 0x1001df80 BG_EnableVal(param_1, param_2) 50   BG_EnumDirectSound 0x10010b20 BG_EnumDirectSound() 5   BG_EnumerateModes 0x1001f5f0 BG_EnumerateModes() 163   BG_EnumHardware 0x1001dc10 BG_EnumHardware() 28   BG_EraseBkg 0x1001e730 BG_EraseBkg(param_1) 91   BG_Exit 0x1001e000 BG_Exit() 260   BG_Flip 0x1001ebd0 BG_Flip(param_1, param_2) 742   BG_FPS 0x10002480 BG_FPS() 7   BG_FrameUsed 0x10012730 BG_FrameUsed() 3   BG_FreeObject 0x100028d0 BG_FreeObject(param_1) 694   BG_GetCamera 0x10011e40 BG_GetCamera(param_1, param_2, param_3, param_4, param_5, param_6, param_7, param_8) 129   BG_GetCaps 0x10023170 BG_GetCaps(param_1) 42   BG_GetDirectSound 0x10010b30 BG_GetDirectSound(param_1) 14   BG_GetDriverID 0x1001ffd0 BG_GetDriverID() 14   BG_GetFaceCount 0x100076b0 BG_GetFaceCount(param_1) 22   BG_GetFile 0x100019d0 BG_GetFile(param_1) 14   BG_GetFloor 0x100065e0 BG_GetFloor(param_1, param_2, param_3, param_4) 363   BG_GetFontMat 0x10002460 BG_GetFontMat(param_1) 32   BG_GetFrameCount 0x10005990 BG_GetFrameCount(param_1) 40   BG_GetFrontFaces 0x100076a0 BG_GetFrontFaces() 6   BG_GetFXPos 0x10009b40 BG_GetFXPos(param_1, param_2, param_3, param_4, param_5) 174   BG_GetHardware 0x100019e0 BG_GetHardware(param_1) 49   BG_GetInitError 0x100024b0 BG_GetInitError() 14   BG_GetLastColor 0x1000e740 BG_GetLastColor(param_1, param_2, param_3) 567   BG_GetLastMatNum 0x1000ea30 BG_GetLastMatNum() 41   BG_GetLastPlane 0x1000e980 BG_GetLastPlane(param_1, param_2, param_3, param_4) 176   BG_GetLastPoint 0x1000e710 BG_GetLastPoint(param_1, param_2, param_3) 37   BG_GetLastVector 0x1000e680 BG_GetLastVector(param_1, param_2, param_3) 136   BG_GetLocalNodePos 0x10001950 BG_GetLocalNodePos(param_1, param_2, param_3, param_4, param_5) 113   BG_GetLogicMul 0x10012360 BG_GetLogicMul() 7   BG_GetMatFaces 0x100097e0 BG_GetMatFaces(param_1, param_2, param_3, param_4, param_5) 115   BG_GetMatID 0x10002870 BG_GetMatID(param_1) 41   BG_GetMatNum 0x1001ff80 BG_GetMatNum(param_1) 14   BG_GetNearestColor 0x10012740 BG_GetNearestColor() 3   BG_GetNodeCount 0x10001710 BG_GetNodeCount(param_1) 44   BG_GetNodeName 0x10001740 BG_GetNodeName(param_1, param_2) 135   BG_GetNodeNum 0x10001620 BG_GetNodeNum(param_1, param_2) 165   BG_GetNodePos 0x100017d0 BG_GetNodePos(param_1, param_2, param_3, param_4, param_5) 370   BG_GetObjectBox 0x100073e0 BG_GetObjectBox(param_1, param_2, param_3, param_4, param_5, param_6, param_7) 144   BG_GetVertice 0x10005560 BG_GetVertice(param_1, param_2, param_3, param_4, param_5) 121   BG_GetVerticeCount 0x100076d0 BG_GetVerticeCount(param_1) 21   BG_GetWorldFXPos 0x10009860 BG_GetWorldFXPos(param_1, param_2, param_3, param_4, param_5, param_6, param_7, param_8, param_9, param_10, param_11, param_12) 731   BG_GetYfromXZ 0x10006420 BG_GetYfromXZ(param_1, param_2, param_3) 29   BG_GrabMaterial 0x100234a0 BG_GrabMaterial(param_1, param_2, param_3, param_4, param_5) 126   BG_Init 0x1001f6a0 BG_Init(param_1, param_2) 921   BG_InitGL 0x10012760 BG_InitGL(param_1, param_2, param_3) 19   BG_KeyDown 0x1001c590 BG_KeyDown(param_1) 17   BG_Line 0x1001e110 BG_Line(param_1, param_2, param_3, param_4, param_5, param_6, param_7) 844   BG_LineIntersect 0x1000ea90 BG_LineIntersect(param_1, param_2, param_3, param_4, param_5, param_6, param_7, param_8, param_9, param_10) 423   BG_LineIntersectCircle 0x1000ec40 BG_LineIntersectCircle(param_1, param_2, param_3, param_4, param_5, param_6, param_7, param_8, param_9) 340   BG_LoadAnimation 0x100041c0 BG_LoadAnimation(param_1, param_2, param_3) 4684   BG_LoadBkg 0x1001e790 BG_LoadBkg(param_1, param_2) 222   BG_LoadCameraTrack 0x10011910 BG_LoadCameraTrack(param_1) 1125   BG_LoadColorMap 0x100059c0 BG_LoadColorMap(param_1, param_2) 712   BG_LoadMatProperties 0x10022eb0 BG_LoadMatProperties(param_1) 679   BG_LoadObject 0x10005cb0 BG_LoadObject(param_1, param_2, param_3, param_4, param_5, param_6, param_7, param_8, param_9, param_10, param_11, undefined1 param_12, undefined1 param_13, undefined1 param_14, undefined1 param_15, undefined1 param_16, undefined1 param_17, undefined1 param_18, undefined1 param_19, undefined2 param_20) 1904   BG_MatriceClear 0x100076f0 BG_MatriceClear() 22   BG_MatriceCustom 0x10007ae0 BG_MatriceCustom(param_1) 107   BG_MatricePoint 0x10007b50 BG_MatricePoint(param_1, param_2, param_3, param_4, param_5, param_6) 151   BG_MatriceRotate 0x10007710 BG_MatriceRotate(param_1, param_2, param_3, param_4) 464   BG_MatriceScale 0x100079e0 BG_MatriceScale(param_1, param_2, param_3) 247   BG_MatriceTranslate 0x100078e0 BG_MatriceTranslate(param_1, param_2, param_3) 247   BG_MatText 0x1001d220 BG_MatText(param_1) 704   BG_MoveWindow 0x1001f3f0 BG_MoveWindow(param_1) 119   BG_PageFlip 0x1001eec0 BG_PageFlip(param_1) 90   BG_PageFlipDC 0x1001ef20 BG_PageFlipDC(param_1) 19   BG_PlayAVI 0x100011d0 BG_PlayAVI(param_1, param_2, param_3, param_4) 650   BG_PopBkg 0x1001d050 BG_PopBkg() 112   BG_Profile 0x10001570 BG_Profile(param_1, param_2) 168   BG_PushBkg 0x1001cf20 BG_PushBkg() 299   BG_RestoreSurfaces 0x1001ff90 BG_RestoreSurfaces() 49   BG_SaveBitmap 0x1001dc30 BG_SaveBitmap(param_1, param_2, param_3, param_4, param_5, param_6, param_7) 771   BG_SaveObject 0x10005c90 BG_SaveObject(param_1, param_2) 26   BG_SaveViewTransform 0x10010360 BG_SaveViewTransform(param_1) 21   BG_ScreenPoint 0x10007500 BG_ScreenPoint(param_1, param_2, param_3, param_4, param_5) 248   BG_ScreenPoint3D 0x10007600 BG_ScreenPoint3D(param_1, param_2, param_3, param_4, param_5, param_6) 159   BG_SetAmbientLight 0x100025f0 BG_SetAmbientLight(param_1) 10   BG_SetCamera 0x10011ed0 BG_SetCamera(param_1, param_2, param_3, param_4, param_5) 283   BG_SetCameraTrack 0x100118c0 BG_SetCameraTrack(param_1) 72   BG_SetCameraVector 0x10011d80 BG_SetCameraVector(param_1, param_2, param_3, param_4, param_5, param_6) 184   BG_SetCameraZoom 0x10011ff0 BG_SetCameraZoom(param_1, param_2) 86   BG_SetFarPlane 0x1001ffe0 BG_SetFarPlane(param_1, param_2) 91   BG_SetFarPlaneEx 0x10009bf0 BG_SetFarPlaneEx(param_1, param_2, param_3) 45   BG_SetFileCallback 0x10012350 BG_SetFileCallback(param_1) 10   BG_SetFontHandle 0x100231a0 BG_SetFontHandle(param_1) 10   BG_SetFOV 0x1000e600 BG_SetFOV(param_1) 118   BG_SetHardware 0x1001dbf0 BG_SetHardware(param_1) 24   BG_SetLightColor 0x100025c0 BG_SetLightColor(param_1, param_2, param_3) 40   BG_SetLightVector 0x10002540 BG_SetLightVector(param_1, param_2, param_3) 116   BG_SetMatColor 0x10002770 BG_SetMatColor(param_1, param_2, param_3, param_4) 65   BG_SetMatColorA 0x100027c0 BG_SetMatColorA(param_1, param_2, param_3, param_4, param_5) 65   BG_SetMatFrame 0x1000ea60 BG_SetMatFrame(param_1, param_2) 42   BG_SetMatProperty 0x100224c0 BG_SetMatProperty(param_1, param_2) 2544   BG_SetMatRotate 0x10002680 BG_SetMatRotate(param_1, param_2, param_3, param_4) 73   BG_SetMatScroll 0x100026d0 BG_SetMatScroll(param_1, param_2, param_3) 146   BG_SetNode 0x1000a490 BG_SetNode(param_1, param_2, param_3) 99   BG_SetObjectLight 0x10002600 BG_SetObjectLight(param_1, param_2) 49   BG_SetObjectLightA 0x10002640 BG_SetObjectLightA(param_1, param_2, param_3) 49   BG_Status 0x10002810 BG_Status() 95   BG_SurfaceHit 0x10006750 BG_SurfaceHit(param_1, param_2, param_3, param_4, param_5, param_6, param_7) 3212   BG_Text 0x1001e580 BG_Text(param_1, param_2, param_3) 419   BG_TextLen 0x1001e460 BG_TextLen(param_1) 283   BG_TextLenFont 0x10001a60 BG_TextLenFont(param_1, param_2) 59   BG_TweenObject 0x10005410 BG_TweenObject(param_1, param_2, param_3, param_4) 230   BG_WaveAnimate 0x10024c80 BG_WaveAnimate(param_1) 1257   BG_WaveCollide 0x10025360 BG_WaveCollide(param_1, param_2, param_3, param_4, param_5, param_6) 501   BG_WaveCollidePost 0x10025560 BG_WaveCollidePost(param_1, param_2, param_3, param_4) 880   BG_WaveCreate 0x10024200 BG_WaveCreate(param_1, param_2, param_3, param_4, param_5, param_6, param_7) 1743   BG_WaveGetFX 0x100258f0 BG_WaveGetFX(param_1, param_2) 23   BG_WaveGetLastFrame 0x10024020 BG_WaveGetLastFrame() 7   BG_WaveGetPitch 0x10025190 BG_WaveGetPitch(param_1, param_2, param_3) 320   BG_WaveGetPitchPost 0x100252d0 BG_WaveGetPitchPost() 7   BG_WaveGetTime 0x100252e0 BG_WaveGetTime(param_1) 30   BG_WaveGetTimeXZ 0x10024130 BG_WaveGetTimeXZ(param_1, param_2) 194   BG_WaveHighestPoint 0x100240f0 BG_WaveHighestPoint(param_1, param_2, param_3) 49   BG_WaveLoadAnimation 0x10024910 BG_WaveLoadAnimation(param_1) 832   BG_WaveScale 0x100248d0 BG_WaveScale(param_1, param_2, param_3) 20   BG_WaveScaleColumn 0x10024c50 BG_WaveScaleColumn(param_1, param_2, param_3) 44   BG_WaveScroll 0x10025300 BG_WaveScroll(param_1, param_2) 95   BG_WaveSetControlPoints 0x100248f0 BG_WaveSetControlPoints(param_1) 31   BG_WaveSetLipZ 0x10025920 BG_WaveSetLipZ(param_1) 10   BG_WaveSetTime 0x10025170 BG_WaveSetTime(param_1, param_2) 27   BG_WaveSetValues 0x100258d0 BG_WaveSetValues(param_1) 30   BG_WaveSmooth 0x10025910 BG_WaveSmooth(param_1) 10   BG_WorldPoint 0x10007470 BG_WorldPoint(param_1, param_2, param_3, param_4, param_5, param_6) 139   BS_AllocSound 0x100109f0 BS_AllocSound() 40   BS_EnumDirectSound 0x100107b0 BS_EnumDirectSound() 28   BS_Exit 0x10010950 BS_Exit() 66   BS_FreeSound 0x100109d0 BS_FreeSound(param_1) 28   BS_GetDirectSound 0x100107d0 BS_GetDirectSound(param_1) 33   BS_Init 0x10010800 BS_Init(param_1, param_2) 324   BS_IsSoundPlaying 0x10010b00 BS_IsSoundPlaying(param_1) 30   BS_LoadSound 0x100109a0 BS_LoadSound(param_1, param_2, param_3) 38   BS_PlaySound 0x10010a20 BS_PlaySound(param_1, param_2) 41   BS_SetSoundFrequency 0x10010aa0 BS_SetSoundFrequency(param_1, param_2) 33   BS_SetSoundPosition 0x10010ad0 BS_SetSoundPosition(param_1, param_2, param_3, param_4) 43   BS_SetSoundVolume 0x10010a70 BS_SetSoundVolume(param_1, param_2) 33   BS_StopSound 0x10010a50 BS_StopSound(param_1) 28   Catch@10027184 0x10027184 Catch@10027184() 16   Catch@10027715 0x10027715 Catch@10027715() 29   DirectDrawCreate 0x10025948 DirectDrawCreate() 6   DirectDrawCreateEx 0x1002593c DirectDrawCreateEx() 6   DirectDrawEnumerateA 0x10025942 DirectDrawEnumerateA() 6   entry 0x10034385 entry(param_1, param_2, param_3) 157   Although Blast Graphics was a 3D library it also contained a lot of game engine functionality such as sound, keyboard input, AVI video playback, animation and more.Mike Stewart’s Pro Bodyboarding (February 1999)Mike Stewart’s Pro Bodyboarding (MSPB) was released to good reviews and would become Gee Whiz! Entertainment’s greatest accompllishment as a studio until they went on to become Krome Studios in November of the same year.The official Krome Studio’s website from 2001 claimed that it was using the Merkury engine, but analysing the game files has no mention of the Merkury engine and instead seems to be using a custom engine called BEAST and Blast Graphics for the 3D.It has a file called beast.cfg which has the following string at the top: BEAST Config File (c) Copyright 1999 Mind Mechanics. Note that the next game that used the same engine, Championship Surfer had the name of the engine as Beast98 during development, the 1998 version of the BEAST game engine.As for Mind Mechanics, they were previously known as SubZero software and had worked on multiple games with Gee Whizz! in the past. Including the Halloween Harry series and their website talked about plans for a 3rd in the series that was 3D, until their site went down at the end of 1999 (when Krome Studios was formed). They are also known for their game Rapid Glider The Race to Galamax 7.We at least know that the wave generation engine was used in three games, as on the website announcing their new PS2 game Sunny Garcia Surfing it proudly announces it : Ground breaking, 3rd generation, proprietary wave generation engine, first seen in Mike Stewart’s Pro Bodyboarding, then in Championship Surfer, creates stunningly realistic wave sets in full 3D.The Chronicles of Jaruu Tenk (October 1999)On 10th of September 1998, Gee Whiz! Entertainment released a press release announcing that they were working on a new 3D title called The Chronicles of Jaruu Tenk with a planned release date of 4th Quarter 1998, however like most ambitious game project it was actually released later on 4th October 1999 12.It was later released for free by John Passfield on his site Free Stuff! - Passfield Games and is still available to this day for everyone to enjoy!Screen OperaIt was so unique that they coined their own genre: “Screen Opera” and it was followed by another game in the same genre very shortly after called Halloween Spirit Board. They also planned a third “Screen Opera” game called Star Date but it was never released.It was inspired by David Crane’s Little Computer People and then sold on their own Screen Opera website 13.Game engine - Was Merkury based on BEAST or Blast Graphics?The was written in C++ and it is built using DirectX 7 and likely Visual C++ as it uses the Microsoft Visual C++ Runtime Library.The interesting thing about the game is it was listed as a Merkury engine game on the official Krome Studios website back in 2001 1. It uses Blast graphics 3D library as per the previous games, but it has no reference to the BEAST game engine or any of the beast config files, so it hints more at Blast Graphics being rebranded Merkury engine rather than BEAST.Although the name “Merkury” wouldn’t appear until the founding of Krome Studios so it used the name Blast Graphics for the 3D engine with the functionality contained in bg.dll. See the Blast graphics section for more information.Some notes about Jaruu: It uses .MAD files for Material Data same as other early Merkury engine gamesHalloween Spirit Board (October 1999)Released on the 25th October 1999 for a price of $9.95 USD Halloween Spirit Board, it was the second game that Gee Wizz! created in a genre that they called “Screen Opera” 14, the first being Jaruu Tenk. Similar to Jaruu Tenk, you can download the game for free on John Passfield’s site: Free Stuff! - Passfield Games.Although it is odd that both Jaruu Tenk and Halloween Spirit Board were released in exactly the same month but that is what their official press releases say 14.Championship Surfer (November 2000) - First game to officially call the engine MerkuryChampionship Surfer is a 2000 game available for Windows, Dreamcast (2001) and PS1 (2001), the Windows and Dreamcast versions are the first game credited as using the Merkury engine, with no mention of the engine for the PS1 release.However it is presumed some of the code was re-used between the Windows and PS1 games so it is likely that even the PS1 version is using some Merkury engine code.PS1 version of Championship SurferThe PS1 version of Championship Surfer (SLUS_012.16) has no mention of the Merkury engine and it was developed by a compeltely different set of programmers at Krome: Tyrone McAuley - Lead programmer Daniel Sewell Craig Herring David GilliganAssets in the PS1 versionThe PS1 version does not use the RKV archive format and instead has files separately on the disc in various PS1 optimized file formats (e.g TIM).This is common with PS1 games as they all use a standard ISO 9660 filesystem, allowing individual files (textures, models, audio, maps, scripts, etc.) to be stored as separate, accessible files.This makes it easy for the game executable to read specific assets directly from the disc and was practical considering memory limits and the way the PS1’s BIOS exposed disc access.Windows, Dreamcast versions of Championship SurferThe Windows and Dreamcast versions of Championship Surfer (2001) is the first game credited as using the Merkury engine, with Tony Ball being listed as the Merkury engine programmer in the credits.It is also the first game that uses the RKV archive format (still never found out what it stands for) in both the Dreamcast and Windows versions, see the section below for the format of these archives as they differ from later Merkury engine games that use the same file extension (.rkv).Beast98 and HotWavesThanks to strings left in the Dreamcast version of the game we know that the main game specific code was in a folder called gamecode under the 1998 Version of their BEAST game engine called beast98. Interestingly call the game HotWaves internally which is a nice nod to Mattel who own the Hot wheels franchise and were also the publisher for this game!The executable has a few paths left intact which give a hint as to the folder structure: File Path Description C:\\Src\\beast98\\beast98.cpp   C:\\Src\\beast98\\animscript.cpp   C:\\Src\\beast98\\gamecode\\arcade.cpp   C:\\Src\\beast98\\gamecode\\championship.cpp   C:\\Src\\beast98\\gamecode\\credits.cpp   C:\\Src\\beast98\\gamecode\\duck.cpp   C:\\Src\\beast98\\gamecode\\elimination.cpp   C:\\Src\\beast98\\gamecode\\freesurf.cpp   C:\\Src\\beast98\\gamecode\\game.cpp   C:\\Src\\beast98\\gamecode\\mainmenu.cpp   C:\\Src\\beast98\\gamecode\\Replay.cpp   C:\\Src\\beast98\\gamecode\\Rumble.cpp   C:\\Src\\beast98\\gamecode\\rumbleicon.cpp   C:\\Src\\beast98\\gamecode\\settings.cpp   C:\\Src\\beast98\\gamecode\\wavegen.cpp   C:\\Src\\beast98\\gamecode\\surfdude.cpp   C:\\Src\\beast98\\gamecode\\dolphin.cpp   C:\\Src\\beast98\\gamecode\\photoman.cpp   C:\\Src\\beast98\\gamecode\\islandboy.cpp   C:\\Src\\beast98\\gamecode\\diver.cpp   C:\\Src\\beast98\\gamecode\\lifeguard.cpp   C:\\Src\\beast98\\gamecode\\femaleswimmer.cpp   C:\\Src\\beast98\\gamecode\\helicopter.cpp   C:\\Src\\beast98\\gamecode\\seagull.cpp   C:\\Src\\beast98\\gamecode\\shark.cpp   C:\\Src\\beast98\\gamecode\\world.cpp   C:\\Src\\beast98\\gamecode\\TextureMatrix.cpp   The PC version also used the Beast98 code even although the strings above were stripped from the binary, we know this as there was a crash.log file left in the Surf_PC.rkv archive:(\"C:\\src\\beast98\\PCRelease\\Hotwaves.exe\" -windowed -lang=2 -nomusic) > Exception !!C:\\src\\beast98\\gamecode\\game.cpp @ 3055Frontend Menu LibraryA few paths in the dreamcast version hint at there being a menu library for the main screens (frontend) with the following source files: C:\\src\\FrontEnd\\Source\\KMenuResources.cpp C:\\src\\FrontEnd\\Source\\KMenuWinner.cpp C:\\src\\FrontEnd\\Source\\ktile.cpp - contained KTile class C:\\src\\FrontEnd\\Source\\ktilescreen.cpp - contained KTextureTile, KTextTile and KTextBoxTile C:\\src\\FrontEnd\\Source\\KMenuCredits.cpp - Credits screen C:\\src\\FrontEnd\\Source\\KMenuSelectBeach.cpp - Beach Selection screen C:\\src\\FrontEnd\\Source\\TestGameScoresScreen.cpp C:\\src\\FrontEnd\\Source\\LanguageScreen.cpp - Language selection screen C:\\src\\FrontEnd\\Source\\Shine.cpp C:\\src\\FrontEnd\\Source\\FrontEndTileScreen.cpp - contained KMenuItemTile, KShadowTextBoxTile, KOutlineTextTileStandard Platform LibraryA few paths in the dreamcast version hint at there being a standard platform library with the following source files: C:\\src\\StdPlatform\\DataInputStream.cpp C:\\src\\StdPlatform\\FileInputStream.cpp C:\\src\\StdPlatform\\IncludeFilterStream.cpp C:\\src\\StdPlatform\\StdString.cpp C:\\src\\StdPlatform\\StringXlat.cpp C:\\src\\StdPlatform\\DirectXConsoleInput.cpp C:\\src\\StdPlatform\\StdProfiler.cpp C:\\src\\StdPlatform\\FileSystemTOC.cpp C:\\src\\StdPlatform\\FileArchive.cppKrome’s Dreamcast Blast Graphics (BG) libraryAlso a few file paths are related to Blast Graphics which uses DirectX 7 on Dreamcast: C:\\src\\Bg\\bg.cpp C:\\src\\Bg\\bgsound.cpp C:\\src\\Bg\\system.cpp C:\\src\\Bg\\animate.cpp C:\\src\\Bg\\colormap.cpp C:\\src\\Bg\\camera.cpp C:\\src\\Bg\\vmu.cpp C:\\src\\Bg\\PlayVideo.cpp C:\\src\\Bg\\waves.cpp - functions like BG_Wave_Create, very specific to surfing games! C:\\src\\Bg\\Rain.cpp C:\\src\\Bg\\SimpleObject.cpp - looks like the base object for a bit of Object Oriented Programming in the game engine! C:\\src\\Bg\\collisions.cpp - presumably collision detection functions C:\\src\\Bg\\bmp.cpp - contains LoadBMP function C:\\src\\Bg\\loadvq.cpp - Loads VQ texture files with LoadVQ()Based on other debug strings from error messages we know that the BG library contained the following functions: BG_GetHardware() BG_AllocObject() BG_FreeObject() BG_LoadObject() BG_Init() BG_PushBkg() BG_Exit() BG_CreateFont() BG_LoadMatProperties() BS_AllocSound() BG_LoadAnimation() - takes in object, skeleton and vat filenames BG_LoadColorMap() - takes in a filename to load BG_LoadCameraTrack() - takes in a filename to load BG_Wave_Create() BG_Wave_LoadAnimation() - loads ASE files BG_WaveSetControlPoints()Sound engine - CRI Middleware’s Sound FactoryThe dreamcast version uses CRI Middleware’s Sound Factory version 1.51 (built in December 1999) for its audio processing, thanks to this information being left in the built executable.Specifically we know it uses the following builds (all from December 8th 1999): CRI_RNV - Ver.0.70(DRAGON) Build: Dec 8 1999 12:10:29 CRI_VFD - Ver.0.99 Build: Dec 8 1999 12:10:55 SJ - Ver.5.50 Build: Dec 8 1999 12:11:38 mwRna - Ver.1.20 Build: Dec 8 1999 10:41:29 mwSnd(DS) - Ver.1.20 Build: Dec 8 1999 10:41:37 SFD - Version 1.21 1999-07-22 (SofdecStream) MPV Version 1.21 1999-07-22 MPS Version 1.21 1999-07-22 ADXENC Ver.1.00 Build:Dec 8 1999 10:48:12 ADXENC.DLL Ver.1.00 Dec 8 1999Other notes: Uses .vqf textures in dreamcast versionThe windows version was also released in a collection called Crazy Fun Games by a french company called fun radio and Ubisoft, but it is currently unknown if it contains any differences or debug symbols present 15.Early RKV Archive formatThe RKV archive format differs from the one used in the more modern games such as Star Wars, but this same format was also used in early PS2 games running on the Merkury engine such as Jimmy Neutron: Jet Fusion!It seems to be the first game that introduced the naming convention for the RKV archives which all have a 2-3 character suffix based on the platform the assets are for: Surf_PC.rkv - Championship Surfer for PC assets SURF_DCP.RKV - Championship Surfer for Dreamcast assets DATA_P2.RKV - Jimmy Neutron for PS2 assets data_pp.rkv - Star Wars: The Force Unleashed for PSP assetsRKV Version 0 QuickBMS extract scriptSince there is already both an RKV.bms and RKV2.bms script to extract RKV files with the QuickBMS tool, I have decided to call the BMS script to extract the early version of the RKV format RKV0.bms, here is a version that works with Surf_PC.rkv and some early PS2 games:# QuickBMS: Old version of Merkury engine games such as Championship Surfing and PS2 games like Jimmy Neutronget FILESIZE asizeif FILESIZE < 8 print \"File too small\" cleanexitendifgoto -8get NUM_FILES longget NUM_DIRS long# directories block (NUM_DIRS * 256) ends at EOF-8math DIRS_SIZE = NUM_DIRSmath DIRS_SIZE *= 256math DIRS_START = FILESIZEmath DIRS_START -= 8math DIRS_START -= DIRS_SIZEprint \"Number of directories: %NUM_DIRS%\"print \"Number of file entries: %NUM_FILES%\"print \"Reading %DIRS_SIZE% bytes of directory entries starting at 0x%DIRS_START|X%\"# read and store dir names by indexgoto DIRS_STARTfor i = 0 < NUM_DIRS getdstring DIR_NAME 256 print \"DIR[%i%]: %DIR_NAME%\" putarray 0 i DIR_NAMEnext i# files block (NUM_FILES * 64) is before directoriesmath FILES_SIZE = NUM_FILESmath FILES_SIZE *= 64math FILES_START = DIRS_STARTmath FILES_START -= FILES_SIZEprint \"Reading %FILES_SIZE% bytes of file entries starting at 0x%FILES_START|X%\"goto FILES_STARTfor i = 0 < NUM_FILES getdstring FILE_NAME 32 get FOLDER_ID long get FILE_SIZE long get FILE_ZERO long get FILE_OFFSET long get FILE_META3 long getdstring FILE_RESERVED 12 # resolve folder name if valid set MATCH_DIR string \"\" if FOLDER_ID >= 0 if FOLDER_ID < NUM_DIRS getarray MATCH_DIR 0 FOLDER_ID endif endif # build output path strlen DIRLEN MATCH_DIR set FULL_NAME string FILE_NAME if DIRLEN > 0 set FULL_NAME string MATCH_DIR string FULL_NAME + / string FULL_NAME + FILE_NAME endif print \"FILE[%i%] name: %FULL_NAME|S% is located at %FILE_OFFSET|X% with size: %FILE_SIZE|X%\" if FILE_ZERO != 0 print \"FILE[%i%] Normally this is zero: %FILE_ZERO|X%\" endif strlen RLEN FILE_RESERVED if RLEN != 0 # Not Sure what this data is (CRC? Timestamps?) # print \"FILE[%i%] reserved: %FILE_RESERVED|X%\" endif # extract if FILE_OFFSET != -1 log FULL_NAME FILE_OFFSET FILE_SIZE endifnext iKat Burglar (Cancelled late 2000)It would have been used in the cancelled Kat Burglar game that Krome Studios was working on in late 2000, which even advertised on their official website about the use of their proprietary Merkury engine 16:Kat Burglar is a 3rd person action-adventure game set in the swinging 60's. Katherine Kelly is a millionaire playgirl by day and a Robin Hood style thief by night. Katherine (\"Kat\" to her friends) specializes in stealing hard to get items from museums and fortified storehouses.But she doesn't steal for the money…Of course we're not going to give it all away just yet. We are keeping a few things under our hat - Kat Burglar is full of secrets and surprises. What we can tell you is that Kat is being developed for next generation console platforms and uses our proprietary 3D graphics engine Merkury.Kat Burglar focuses heavily on characters and storyline. This game isn't a shooter. While there will be occasions where Kat won't be able to avoid a fight, more emphasis is placed on stealth. As Kat Burglar, the player will be part of the story that unfolds on the island of Mont-St-Michel. Kat will also come across many characters in the game, some friends, some enemies and some she's just not sure about.GamesOnNet a site that now seems to be defunct had the following to say about Kat Burglar 17:One of the games that came closest to making it was Kat Burglar, an action-stealth game that began life in late 1998 during Steve’s time at Gee Whiz! Entertainment with John Passfield. A light-hearted game with a James Bond-style 60’s flair, Steve recalls that they encountered some difficulty selling their prototype to publishers in 2000. “It was about the same time that No One Lives Forever was being shown around. And the problem we were running into when we were showing publishers, was ‘Monolith is showing this game where they have this 60’s female spy, and you’re showing us this game with a 60’s female thief, you can’t have two games set in the 60’s with a female character in them! That’s the same thing!’. And we were like ‘Wait, what?’”Recounting with a touch of bitterness that it was apparently okay to have a dozen identical “muscular space marine” games on the market at the same time, Steve and the team were forced to shelve the game. “They just weren’t getting it, even if they did like the characters”, says Steve, remembering failed deals with partners like Mattel. “I’ll always remember the guys came back from one meeting with a publisher, and the publishers said ‘We’re pretty sure there’s already a 60’s female thief game with a character that has red hair’, and I’m standing there going 'Are they... talking about our game?'”.Set on the island of Mont-St. Michael, Kat Burglar featured a number of adventure-game driven mechanics similar to those found in Flight of the Amazon Queen, as well as AI sidekicks who you could give orders to through hand gestures. The intent was to have a Zelda-style unlockable open world, with the island opening up to you as you progressed. Despite the game being developed to a playable state through one prototyped level, they were unable to secure a publisher. Opportunity did come knocking later in the year, as Sony expressed a desire to publish a cartoony platformer on their PS2 - a desire that Krome were only too happy to help fulfill. That game that would later go on to become TY The Tasmanian Tiger, and one of the company’s most iconic franchises.Many of the ideas and concepts of Kat Burglar were eventually carried over into one of Krome’s last published titles, Blade Kitten - including a strong resemblance between Katherine Kelly of Kat Burglar and the pink-haired Kit Ballard of Blade Kitten. “I had all these elements I wanted to use but we apparently couldn’t do a 60’s game,” says Steve, “so I went and turned it into a sci-fi, anime game instead”.More information on Kat Burglar can be found on Unseen64 Kat Burglar- Unseen64Disney’s Extremely Goofy Skateboarding (September 2001)The game Disney’s Extremely Goofy Skateboarding pre-dates the Merkury engine and was built to be windows-only, but it was released in 2001 the same year that they released Sunny Garcia Surfing which did use the Merkury engine. Presumably they were working on a new PS2 engine for the surfing game while working on the Disney game for windows, so it would not be easy to just port the skateboarding game over to the new engine.Although it doesn’t use Merkury it would be interesting to see if any code from this game made it into early versions of the Merkury engine.The 3D Engine programmer for the Goofy game, Tony Ball was also one of the founding developers of the Merkury engine, for this game the Blast graphics engine was compiled statically inside the executable.Differences from the Merkury engine: Asset archives - Instead of the RKV format, the game bundles its assets into a file called data0.pkg, this is simply a Zip file, so its very easy to extract the contents by adding the .zip extention to the end. Images - It stores images directly as .BMP and textures as .TGA in the archive Sounds - It stores sounds directly as .WAV and .MP3 filesSkating.exe executableIf you run the binwalk command on the Skating.exe executable you find that it actually has a few embedded executables too:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------DECIMAL HEXADECIMAL DESCRIPTION----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------0 0x0 Windows PE binary, machine type: Intel x86510344 0x7C988 Copyright text: \"Copyright 1998 Gilles Vollant \"510760 0x7CB28 CRC32 polynomial table, little endian518636 0x7E9EC Copyright text: \"Copyright (C) 1996, Thomas G. Lane\"862766 0xD2A2E Copyright text: \"Copyright (c) 1993 Tal Nevo.\"872435 0xD4FF3 Windows PE binary, machine type: Intel x86889647 0xD932F Windows PE binary, machine type: Intel x86----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------This is because it was packed with the executable packer PEtite, which could potentially be unpacked with unipacker/unipacker: Automatic and platform-independent unpacker for Windows binaries based on emulation.The copyright messages hint at a few things: Gilles Vollant is most likely related to zlib compression used for the asset archives. Thomas G. Lane is a principal author of the IJG’s widely used JPEG image compression software libraries, commonly known as libjpeg. Tal Nevo is possibly related to executable compression but this is a guessThe executable also has a few file paths left in which give a hint about the folder structure: D:\\Src\\Skating\\Source\\Character.cpp D:\\Src\\Skating\\Source\\Object.cpp D:\\Src\\Skating\\Source\\Main.cpp - Contained WinMain D:\\Src\\Skating\\Source\\GameData.cpp - Save DataThe reason we know it uses Blast Graphics without it having the bg.dll file is due to the string BLASTGRAPHICS Build Date : %s but not sure what the build date actually was for the BlastGraphics library for this game.Asset Archive - data0.pkgSince the data0.pkg format is just simple zip compression, it is very easy to extract and modify the assets, so lets take a look at what it contains, there are 1,207 files so we will group files by their extension in the table below: Extension Number of Files Description wav 463 Waveform audio file, uncompressed sound effects or music tga 343 Targa image file, common raster graphic format supporting alpha channels bmp 131 Bitmap image file (case variant) ase 101 3DS MAX ASCII EXPORT for the 3D models rpl 49 resource package file? bad 32 Basic Animation Descriptor - plain text files for animations that link a mesh (.ase) with a skeleton (.ase) and a vertex animation (.vat) bmp 27 Bitmap image file, uncompressed raster graphics mp3 15 Audio file in MPEG Layer-3 format, compressed music or sound effects lvl 15 Level data file in XML format, stores game level layouts mad 15 Material Data - Plain text file setting key value pairs for values such as “color .5 .5 1 .8” vat 11 Vertex Animation in VAT2 format (Linked Vertex Information File ver 2), used for complex mesh animations in games lang 2 Language or localization resource file txt 2 Plain text file, often for logs, documentation, or configs cfg 1 Configuration file, plain text settings The ASE files confirm that the game’s 3d models were creating using 3D Studio Max 3 or 4 back in 2001, but not sure the exact version of 3ds Max (does AsciiExport Version 2.00 narrow it down?).They show how the 3D artists named their 3ds max scene files: beach_boardwalk_sign_nobase.max beach_1375_7_00_2001_JC1003_JC_TB.maxIt also shows the organised folder structure used during development of the game: G:\\Goofy Skateboarding\\data\\Models\\Textures\\badge.tga \\\\Krome-fs4\\data12\\Goofy\\Goofy Skateboarding\\data\\Models\\Textures\\ramp2.tga - Shared Network drive? \\\\Krome-fs4\\data12\\Goofy\\Graphics\\Screens\\S08_Beach\\S08_03_BoardWalk\\textures\\jetty.bmp - I wonder why screen graphics were kept separate?Level files - .lvlThe level files are plain text XML data which links together all the other files, it is extremely modder friendly, here is an example:<LEVEL NAME=\"Downtown\" MESH=\"riverbend.ase\" ENV=\"Cloud_Blue_env.ASE\" MATERIAL=\"riverbend.mad\" ENVROT=\"0\" MUSIC=\"SUBURB_2.mp3\" AMBIENT=\"ambience_centralpark_01.wav\"> <CLIP NEAR=\"100.00\" FAR=\"8000.00\" FOG=\"7000.00\" COLOR=\"0.72,0.86,0.85\"> <OBJECTIVES TYPE=\"SHRED\" DATA1=\"23,7\" DATA2=\"1,70\" DATA3=\"24,7\"> <OBJECTIVES TYPE=\"AGILITY\" DATA1=\"3,7000\" DATA2=\"4,7\" DATA3=\"5,7\" TIME=\"120\"> <TRIGGER POS=\"355.37,-3350.55,6692.30\" SIZE=\"100.00,100.00,100.00\" TYPE=\"spawn\" ID=\"0\" DATA=\"0\" ENTER=\"none\" EXIT=\"none\"> <OBJECT POS=\"4483.87,-3353.96,9730.11\" ROT=\"0.00,0.00,0.00\" SCALE=\"1.00\" MESH=\"coin.ase\" TYPE=\"collectible\" UNIQUE=\"0\" ID=\"1\" DATA=\"0\" FLAGS=\"4\" SPEED=\"1.00\"> <OBJECT POS=\"7183.09,-3706.17,11404.25\" ROT=\"0.00,-90.00,0.00\" SCALE=\"0.60\" MESH=\"critter_duckling.bad\" TYPE=\"duckling\" UNIQUE=\"0\" ID=\"0\" DATA=\"0\" FLAGS=\"31\" SPEED=\"1.00\"></LEVEL>As far as I know this is a custom format made for this game and not an industry standard.Sunny Garcia Surfing (October 2001)Sunny Garcia Surfing was released on the PS2 in October 2001 in which Krome clearly listed the Merkury engine in the game credits. It has no mentions of Blast Graphics which makes sense as this is the first PS2 game they have released which would have required a complete re-write of the graphics engine to make the most out of the hardware.The Merkury Engine programming for the game is credited to the following programmers in the manual for the game 18: Tony Ball - The main 3D developer behind the Blast Graphics 3D engine used in prior titles 19 James Podesta - Also credited as Lead programmer on the game has been at Krome Studios since at least Championship Surfer back in 2000 and still there in 2023! Dave Pevreal - Also credited as Lead engine programmer on the Merkury engine version of Star Wars: The Force Unleashed 19Barbie: Sparkling Ice Show (2002)Barbie: Sparkling Ice Show was released in 2002 with support for DirectX8, it was the first game they released for windows that had no mentions of Blast Graphics at all and instead had strings related to Merkury in the game executable such as Merkury Options.This hints that they never updated the Blast Graphics engine to DirectX 8 and this was the first 3D game for Windows that was released without Blast graphics.File formats used: .anm - Animation data (Used by Animation::Create) .mad - Material Data (Used by Material::Create or Material::InitFromMatDefs) .mdl - Model Data (Used by Model::Create) .dat - Replay Data (Used by Replay class)Source Code StructureThere are strings in the executable that can shad some light on what the source code structure was like, it was very organised, split into the following main folders: BarbieCommon - Common Game Engines files these files are not Barbie specific and most of them are also seen in other Merkury engine games Located at D:\\Src\\IceSkating\\BarbieCommon Also contains a PC sub folder with PC specific implementations (the common folder aims to be cross platform) Source - Game specific functionality Located at D:\\Src\\IceSkating\\Source\\ There are other strings throughout the executable with class and method/function names so we can infer from the file names which functions were in each source file, however this is an estimate they may have actually been located in a different file that’s path was not leaked in the exe.BarbieCommon - Common Game Engine functionalityYou can find a list of the common source code files in the table below along with a description containing the functions that they would have contained:Source File | Function Names—|—D:\\Src\\IceSkating\\BarbieCommon\\PC\\Blitter.cpp | Blitter_Image::Draw, Blitter_Line3D::Draw, Blitter_Particle::Draw, Blitter_TriFan::Draw2D, Blitter_TriStrip::Draw, Blitter_UntexturedImage::Draw, BlitterSphere::DrawD:\\Src\\IceSkating\\BarbieCommon\\PC\\File.cpp | D:\\Src\\IceSkating\\BarbieCommon\\PC\\Image.cpp | Image::Copy, Image::Deinit, Image::Init, Image::LoadTGAD:\\Src\\IceSkating\\BarbieCommon\\PC\\MKGrass_PC.cpp | D:\\Src\\IceSkating\\BarbieCommon\\PC\\MKSound_FMod.cpp | Sound_IsVoicePlaying(), Sound_LoadBank(), Sound_PlayV(), Sound_SetVolume(), Sound_Stop(), Sound_UnloadBank()D:\\Src\\IceSkating\\BarbieCommon\\PC\\System.cpp | D:\\Src\\IceSkating\\BarbieCommon\\PC\\Texture.cpp | Texture::Create, Texture::Destroy, Texture::Find, Texture::InitFromImageD:\\Src\\IceSkating\\BarbieCommon\\PC\\Video.cpp | D:\\Src\\IceSkating\\BarbieCommon\\PC\\View.cpp | D:\\Src\\IceSkating\\BarbieCommon\\Source\\Animation.cpp | D:\\Src\\IceSkating\\BarbieCommon\\Source\\BytePair.cpp | D:\\Src\\IceSkating\\BarbieCommon\\Source\\Camera.cpp | Camera::Reposition(), Camera::Update(), Camera::Reposition()D:\\Src\\IceSkating\\BarbieCommon\\Source\\Collision.cpp | Collision_Init(), Collision_AddStaticModel(),Collision_Grid, Collision_RayCollide, Collision_RayCollideDynamicModel, Collision_SphereCollideD:\\Src\\IceSkating\\BarbieCommon\\Source\\DebugInfo.cpp | DebugInfo_Init()D:\\Src\\IceSkating\\BarbieCommon\\PC\\DebugOptionsPC.cpp | DebugOptions_Create, DebugOptions_DrawDebugOptionsD:\\Src\\IceSkating\\BarbieCommon\\Source\\DebugOptions.cpp | DebugOptions_Create, DebugOptions_DrawDebugOptionsD:\\Src\\IceSkating\\BarbieCommon\\Source\\DirectLight.cpp | DirectLight::SetLightD:\\Src\\IceSkating\\BarbieCommon\\Source\\FileSys.cppD:\\Src\\IceSkating\\BarbieCommon\\Source\\Font.cpp | Font::Create, Font::Destroy, Font::DrawText, Font::DrawText3d, Font::Find, Font::MakeFontD:\\Src\\IceSkating\\BarbieCommon\\Source\\Heap.cppD:\\Src\\IceSkating\\BarbieCommon\\Source\\KromeIni.cppD:\\Src\\IceSkating\\BarbieCommon\\Source\\Material.cpp | Material::Create, Material::InitFromMatDefsD:\\Src\\IceSkating\\BarbieCommon\\Source\\Matrix.cpp | Matrix::InverseSimple(), Matrix::Multiply3x3(), Matrix::Multiply4x4(), Matrix::RotatePYR(), Matrix::RotateYaw(), Matrix::Scale(), Matrix::SetRotationPYR(), Matrix::SetTranslation, Matrix::Translate(), Matrix::Transpose(), Matrix::Transpose3x3()D:\\Src\\IceSkating\\BarbieCommon\\Source\\MKAnimScript.cpp | MKAnimScript::Init, MKAnimScript::GetAnim(char*), MKAnimScript::SetAnim, MKAnimScript::TweenAnimD:\\Src\\IceSkating\\BarbieCommon\\PC\\Model_PC_Common.cpp | D:\\Src\\IceSkating\\BarbieCommon\\PC\\Model_DX8.cpp | D:\\Src\\IceSkating\\BarbieCommon\\Source\\Model.cpp | Model_DeinitModule, Model_InitModule, Model::Create, Model::CreateIndexedTriangles, Model::Destroy, Model::Draw, Model::EnableSubObject, Model::GetRefPointIndex, Model::GetSubObjectIndex, Model::GetSubObjectMatrixIndex, Model::SetAnimation, Model::SubObjectExistsD:\\Src\\IceSkating\\BarbieCommon\\Source\\ParticleSystem.cppD:\\Src\\IceSkating\\BarbieCommon\\Source\\ParticleSystemManager.cppD:\\Src\\IceSkating\\BarbieCommon\\Source\\QuatRotation.cpp | QuatRotation::ConvertNormal(), QuatRotation::Multiply()D:\\Src\\IceSkating\\BarbieCommon\\Source\\StdMath.cpp | Random(), Randomf()D:\\Src\\IceSkating\\BarbieCommon\\Source\\Str.cppD:\\Src\\IceSkating\\BarbieCommon\\Source\\Translation.cppD:\\Src\\IceSkating\\BarbieCommon\\Source\\Vector.cpp | Vector::ApplyQuaternion(), Vector::ApplyRotMatrix(), Vector::CClamp(), Vector::Cross(), Vector::InterpolateLinear(), Vector::Normalise()Also we know it contained the following include files: barbiecommon\\include\\DirectLight.h barbiecommon\\include\\ParticleSystem.h barbiecommon\\include\\PtrListDL.h barbiecommon\\include\\View.hSource - Specific game related functionalityBarbie Source, the actual game code rather than the engine:Source File | Description—|—D:\\Src\\IceSkating\\Source\\Button.cppD:\\Src\\IceSkating\\Source\\ButtonManager.cppD:\\Src\\IceSkating\\Source\\CharacterParticles.cppD:\\Src\\IceSkating\\Source\\Confirmation.cppD:\\Src\\IceSkating\\source\\Credits.cppD:\\Src\\IceSkating\\Source\\EditBox.cppD:\\Src\\IceSkating\\Source\\GameData.cppD:\\Src\\IceSkating\\Source\\GameInterface.cppD:\\Src\\IceSkating\\Source\\GameScreen.cppD:\\Src\\IceSkating\\Source\\Introduction.cppD:\\Src\\IceSkating\\Source\\MainMenu.cppD:\\Src\\IceSkating\\Source\\NameEntry.cppD:\\Src\\IceSkating\\Source\\Object.cppD:\\Src\\IceSkating\\Source\\ObjectManager.cppD:\\Src\\IceSkating\\Source\\PauseMenu.cppD:\\Src\\IceSkating\\Source\\LoadReplay.cppD:\\Src\\IceSkating\\Source\\Replay.cpp | Replay::GetNextPacket, Replay::SetNextPacket, Replay::GetAbsoluteSlot(), Replay::GetCurrentRelativeSlot(), Replay::SetCurrentSlot()D:\\Src\\IceSkating\\Source\\SaveReplay.cppD:\\Src\\IceSkating\\Source\\ScreenManager.cpp | Header: D:\\Src\\IceSkating\\Source\\screenmanager.hD:\\Src\\IceSkating\\Source\\ScrollBox.cppD:\\Src\\IceSkating\\Source\\ScrollSystem.cppD:\\Src\\IceSkating\\Source\\SelectionMenu.cppD:\\Src\\IceSkating\\Source\\Skater.cppD:\\Src\\IceSkating\\Source\\Spline.cpp | Spline::GetPositionD:\\Src\\IceSkating\\Source\\StateMachine.hTy the Tasmanian Tiger (2002)Ty the Tasmanian Tiger was released in 2002 for PS2, Gamecube and Xbox.Gamecube release of Ty (2002)The Gamecube release of Ty the Tasmanian Tiger contains not only debug symbols but also 364 references to the names of the C++ source code files used to build the game, all in the main executable TY_REL.elf. Most of the strings are located in the string table section (.strtab) of the GameCube ELF file and thus the location in that section may not indicate anything about the location of the functions that were contained in that source file.You can find the Source file names in the table below, any descriptions added are a guess at the purpose of the file by us: Location (.strtab) Source File Name Description 0x00018ab2 ZoneBlockerProp.cpp   0x00018979 Z1_RainbowScales.cpp   0x000186ff YabbyStalactite.cpp   0x0000bebe Yabby.cpp   0x0002806b xfontdata.cpp   0x0002803a xFont.cpp   0x0000baba Wombat.cpp   0x0002275a WobbleTexture.cpp   0x00022720 windmill.cpp   0x0000b899 WhiteBat.cpp   0x00018528 WhirlyWind.cpp   0x000226a5 WeatherTypes.cpp   0x00018429 WeatherProp.cpp   0x00003b38 Weather.cpp   0x000182ce WaterWheel.cpp   0x000181b6 WaterVolume.cpp   0x00022455 watertank.cpp   0x00022345 WaterSlide.cpp   0x00017f2e WaterPipe.cpp   0x000222a0 WaterfallStream.cpp   0x000221c0 WaterfallSpray.cpp   0x00022130 WaterfallPoint.cpp   0x0002209c WaterfallBase.cpp   0x00021fbf Waterfall.cpp   0x00003af6 Waterdrip.cpp   0x00002da2 WaterDragon.cpp   0x00027fac Water_GC.cpp   0x00017d90 WarpFlower.cpp   0x00021f6e wake.cpp   0x00027f1e View_GC.cpp   0x00027ea6 Video.cpp   0x00026926 Vector.cpp   0x0002691c Utils.cpp   0x00021f39 UserInterface.cpp   0x00021e02 underWaterEffects.cpp   0x0000f324 UITools.cpp   0x00021c22 TyMemCardQuery.cpp   0x00021b65 TyMemCard.cpp   0x00021ac3 TyHealth.cpp   0x00021976 TyCollisions.cpp   0x00021882 TyAttributes.cpp   0x0002181f TyAnimTables.cpp   0x00020b32 Ty.cpp   0x00002d07 Turtle.cpp   0x00017c2a TurningPlatform.cpp   0x00017af2 TumbleWeed.cpp   0x000176cb TriggerProp.cpp   0x00017522 TreasureChest.cpp   0x0000b461 TrapdoorSpider.cpp   0x000267c0 Translation.cpp   0x00003adc Trails.cpp   0x000209a7 Torch.cpp   0x0002088b tools.cpp   0x000267b6 Timer.cpp   0x0000b1e8 Tick.cpp   0x0001739f ThunderEggCollector.cpp   0x00017227 ThinIceProp.cpp   0x00027a04 Texture.cpp   0x00017093 Teleporter.cpp   0x00003a7f Teleport.cpp   0x0002065b target.cpp   0x00016f23 Talisman.cpp   0x00027788 System_GC.cpp   0x00027776 system_extras.cpp   0x0000b049 SynkerFrill.cpp   0x0000aea7 SynkerBlueTongue.cpp   0x0002679b Str.cpp   0x0002035d stopwatch.cpp   0x00003a39 Steam.cpp   0x0002675e StdMath.cpp   0x00020325 staticSpikes.cpp   0x00016c79 StaticProp.cpp   0x0000f1ca StartupScreens.cpp   0x00016b01 Stalactite.cpp   0x000202ac Spline.cpp   0x000169a2 SpinningLog.cpp   0x000201f5 SpikeyIce.cpp   0x00016862 SpiderWeb.cpp   0x0000ad14 SpiderTrapdoor.cpp   0x00002caf Spider.cpp   0x000039aa SpeedboatWake.cpp   0x0001ffa1 SpecialPickup.cpp   0x00016764 SpawnPoint.cpp   0x00016651 SoundProp.cpp   0x0001fab5 soundbank.cpp   0x00027487 Sound.cpp   0x0000aa03 SnowSpider.cpp   0x0000a774 SnowRoo.cpp   0x00016478 SnowPile.cpp   0x0000387f SnowFootEffects.cpp   0x00003829 SnowBall.cpp   0x00002a46 SmallCrab.cpp   0x0000a3a2 Sly.cpp   0x00009f93 Skink.cpp   0x0001f7b4 SignPost.cpp   0x0000d636 sheila.cpp   0x0001f740 shears.cpp   0x0000d516 shazza.cpp   0x00016143 Shatterable.cpp   0x0001f6b1 Shatter.cpp   0x00016003 SharkCage.cpp   0x00009d1e Shark.cpp   0x00015c2b ShadowBatProps.cpp   0x00009987 ShadowBat.cpp   0x0001f671 Shadow.cpp   0x0001f4d5 setup.cpp   0x00015a52 Sentinel.cpp   0x0001f2e6 SeaMine.cpp   0x000095a9 ScubaFrill.cpp   0x0000928e ScrubTurkey.cpp   0x0001f142 Script.cpp   0x000037c3 SawDust.cpp   0x00008fe5 rufus.cpp   0x00008c98 Roach.cpp   0x00008994 RhinoGround.cpp   0x000086ef Rhino.cpp   0x00015834 Rex.cpp   0x0001efc3 renderTexture.cpp   0x0001ef0d Reflection.cpp   0x0001eea5 reeds.cpp   0x0001571c RangStone.cpp   0x0001edae RangeCheck.cpp   0x000036f2 RainbowEffect.cpp   0x0000368e Rain.cpp   0x00026736 QuatRotation.cpp   0x0001ed78 quadratic.cpp   0x00015712 Props.cpp   0x0001560d Projectile.cpp   0x0000f1a1 ProgressBar.cpp   0x0001ec23 portal.cpp   0x000154f1 PontoonRope.cpp   0x0001e8b1 Pontoon.cpp   0x0001530b Platform.cpp   0x000151ee PipePart.cpp   0x000150a5 Picture.cpp   0x00014ede PicnicBasket.cpp   0x00014c5d PickupCounter.cpp   0x0000f180 PauseScreen_SaveGame.cpp   0x0000f08d PauseScreen_RangInfo.cpp   0x0000ef3c PauseScreen_OptionSound.cpp   0x0000ee09 PauseScreen_OptionScreen.cpp   0x0000edba PauseScreen_Options.cpp   0x0000ec00 PauseScreen_OptionControls.cpp   0x0000e9c1 PauseScreen_Map.cpp   0x0000e7c6 PauseScreen_GameTotals.cpp   0x0000e3c7 PauseScreen_GameInfo.cpp   0x0000e2d9 PauseScreen_Continue.cpp   0x0000dfeb PauseScreen.cpp   0x0001e856 Path.cpp   0x0002670d ParticleSystemManager.cpp   0x00026677 ParticleSystem.cpp   0x0001e4e3 particleengine.cpp   0x0001e490 ParticleEmitter.cpp   0x0001e007 particleEffects.cpp   0x00014a1c OpalCollector.cpp   0x0001df98 NodeOverride.cpp   0x0000837a NinjaGecko.cpp   0x0000801e neddy.cpp   0x0001475c MusicalIcicle.cpp   0x00007d88 muddie.cpp   0x000028a8 Moth.cpp   0x000145af MorayEel.cpp   0x000273e4 ModelGC.cpp   0x00026620 Model.cpp   0x00014359 MobilePlatform.cpp   0x000272f2 MKShadow_GC.cpp   0x000264e7 MKSceneManager.cpp   0x00026475 MKRumble.cpp   0x000263c4 MKParticleGen.cpp   0x000261af MKPackage.cpp   0x00027012 MKMemoryCard.cpp   0x00026116 MKAnimScript.cpp   0x0001df67 mist.cpp   0x0000fb22 MiniGameObjective.cpp   0x0000fb12 MiniGame_E4.cpp   0x0000fa86 MiniGame_C3.cpp   0x0000f868 MiniGame_C2.cpp   0x0000f638 MiniGame_B3.cpp   0x0000f4d0 MiniGame_B1.cpp   0x0000f3b7 MiniGame_A2.cpp   0x0001de04 MetalSpikes.cpp   0x0001dcf4 Messages.cpp   0x0001dce5 MessageMap.cpp   0x0000d33d maurie.cpp   0x000260f2 Matrix.cpp   0x00026cfc Material_GC.cpp   0x0001da87 main.cpp   0x0001414a Log.cpp   0x0001d7e5 LoadLevel.cpp   0x0001d7c1 LineOfSight.cpp   0x0001403d LilyPad.cpp   0x00007a52 LilNeddy.cpp   0x0000359e Lightning.cpp   0x0001d734 LevelObjective.cpp   0x00002e40 LetterBox.cpp   0x0001d6c1 LensFlare.cpp   0x0000d07c Lenny.cpp   0x000077d1 leech.cpp   0x00013eae LavaBurner.cpp   0x00013c82 Lava.cpp   0x0001d496 lasso.cpp   0x000260b5 KromeIni.cpp   0x00013920 KoalaKid.cpp   0x00002559 KingFisher.cpp   0x0001d464 Kinematics.cpp   0x0000cf2c KenOath.cpp   0x0001379f JuliusMachine.cpp   0x0000cd58 julius.cpp   0x0001d132 jeep.cpp   0x00026c17 Input_GC.cpp   0x0001367f IceRamp.cpp   0x00013300 IceCoolant.cpp   0x0001cfbc iceblock.cpp   0x00002391 Ibis.cpp   0x0001cd9f Hud.cpp   0x0001cd66 heatflare.cpp   0x0002608d Heap.cpp   0x0001cb9e GuideParticle.cpp   0x0001ca97 guidebarrel.cpp   0x0000755e Grouper.cpp   0x00003539 GreySmoke.cpp   0x0000220d Grasshopper2.cpp   0x00026aee Grass_GC.cpp   0x0001c7f8 global.cpp   0x0001312c Geyser.cpp   0x00012fb0 Generator.cpp   0x00012cb1 gem.cpp   0x00002012 Gecko.cpp   0x0001c590 Gate.cpp   0x00012b5f GasJet.cpp   0x0001c55a GameObjectManager.cpp   0x0001c491 GameObject.cpp   0x0001c435 GameData.cpp   0x00000905 GameCameraTools.cpp   0x00000133 GameCamera.cpp   0x00012939 Furnace.cpp   0x0000df6f FrontEnd_Videos.cpp   0x0000dec8 FrontEnd_Title.cpp   0x0000dd57 FrontEnd_MainMenu.cpp   0x0000dbd3 FrontEnd_LoadLevel.cpp   0x0000db8b FrontEnd_LoadGame.cpp   0x0000db32 FrontEnd_LanguageSelect.cpp   0x0000da9d FrontEnd_Gallery.cpp   0x0000d9e6 FrontEnd_Extras.cpp   0x0000d821 FrontEnd_Credits.cpp   0x0000d76a FrontEnd.cpp   0x00001b49 Frog.cpp   0x000071e2 FrillSpeedboat.cpp   0x00006d9f frilllizard.cpp   0x00006a66 FrillBike.cpp   0x0000cc1c Friend.cpp   0x00025fce Font.cpp   0x000017a5 Fly.cpp   0x00006357 Fluffy.cpp   0x000127e5 FlamingLog.cpp   0x000034f8 Flame.cpp   0x00001377 FishShoal.cpp   0x000012e2 Fish.cpp   0x0001264c FireDrum.cpp   0x0001c2ec finishline.cpp   0x00025eb9 FileSys.cpp   0x00026ad3 File.cpp   0x0000ca40 farlapp.cpp   0x00012528 FallGuideProp.cpp   0x0001c2af ExtendedAnalogControl.cpp   0x000033ba Explosion.cpp   0x000061e5 EnemySpawner.cpp   0x00005e73 Enemies.cpp   0x0001bed0 emu.cpp   0x0001bd8e elle.cpp   0x00012307 Elevator.cpp   0x00005bf2 Eel.cpp   0x000120eb E4_FlameThrower.cpp   0x00011f86 E4_Door.cpp   0x0001bd53 DustTrail.cpp   0x0001bc15 Drum.cpp   0x0001bb0e draw.cpp   0x00026a3e DiscErrors.cpp   0x00025e8d DirectLight.cpp   0x00003036 DialogPlayer.cpp   0x00002e88 DialogEffect.cpp   0x000059fc Dennis.cpp   0x00026953 demoinit.cpp   0x000280d3 Debug.cpp   0x00011e8b DDACheckpoint.cpp   0x0001baac DDA.cpp   0x0001b80c DataVal.cpp   0x00011d43 Damageable.cpp   0x00011c55 D1_Prop.cpp   0x00001122 CuttleFish.cpp   0x000057db croc.cpp   0x00001110 Critters.cpp   0x00000e3b Critterfield.cpp   0x00000df4 CritterDefs.cpp   0x000119d2 CrikeyProps.cpp   0x00005346 Crikey.cpp   0x00025e6b Crc.cpp   0x0001b30e crate.cpp   0x0001b2ff controlval.cpp   0x0001b29c CollisionObject.cpp   0x00025a78 Collision.cpp   0x00011881 Collapsible.cpp   0x00011730 Coconut.cpp   0x000032fd ChronorangEffects.cpp   0x0001b0f0 checkpoint.cpp   0x000050ba CaveBat.cpp   0x00000bae Cattle.cpp   0x00000001 CameraOverride.cpp   0x00025a59 Camera.cpp   0x000115bb CableCar.cpp   0x0001126f C3_Ringo.cpp   0x0000c763 C3_MiniGame_Rex_Elle.cpp   0x00011165 C3_Chest.cpp   0x00011071 C1Water.cpp   0x00010efc BuzzSaw2.cpp   0x0001ab67 BushPig.cpp   0x00010d5e BurningTree.cpp   0x00010baa Burner.cpp   0x00010995 Burnable.cpp   0x0001080a BunyipStone.cpp   0x0000c582 BunyipElder.cpp   0x0001a980 bunyip.cpp   0x00004a61 bull.cpp   0x000106ac BubbleSpawner.cpp   0x000032c5 Bubble.cpp   0x0001a95e BoundingRegion.cpp   0x0001a4aa BouncingBoulder.cpp   0x0001056d Bouncer.cpp   0x0000493b BossCass.cpp   0x0001a43f boomerangManager.cpp   0x0001a3de BoomerangHud.cpp   0x00019bf7 boomerang.cpp   0x000101d4 BonusPickup.cpp   0x0000452e BlueTongueRock.cpp   0x000042d4 BlueTongue.cpp   0x00028079 Blitter.cpp   0x000009a8 Bird.cpp   0x00019b08 bilby.cpp   0x00019ac4 BezierPathFollower.cpp   0x000100ab BeachHut.cpp   0x0000406a Bat.cpp   0x00003e25 Barracuda.cpp   0x00019a8a barbedWire.cpp   0x00003bb8 BadBoonie.cpp   0x00003230 Avalanche.cpp   0x0000c2b3 AuroraKid.cpp   0x0000c13d Aurora.cpp   0x000199a4 AS_WaterStates.cpp   0x00019850 AS_UnderWaterStates.cpp   0x0001965c AS_SlideStates.cpp   0x000195a5 AS_MiscStates.cpp   0x00019354 AS_LandStates.cpp   0x00019205 AS_LandActionStates.cpp   0x00018fbe AS_BiteStates.cpp   0x00018e4c AS_AirStates.cpp   0x0000ff68 Aquarang.cpp   0x00018d44 anthill.cpp   0x00025937 Animation.cpp   0x0000fda3 AnimatingProp.cpp   0x0000fc53 A1_FrillObjective.cpp   0x00023a49 __ppc_eabi_init.cpp   0x00024f88 __init_cpp_exceptions.cpp   0x802764f8 File.cpp   0x80275a18 demoinit.cpp   The Adventures of Jimmy Neutron: Jet Fusion (2003)The 2003 game The Adventures of Jimmy Neutron: Jet Fusion is confirmed to use the Merkury engine (it uses RKV archives).Prototype version for PS2A Demo of the game was distributed in the Christmas 2003 issue (issue number 41) of the Official Playstation 2 magazine in the UK, the demo disc has the code SCED_51536.It contained a DATA_P2.RKV (201.3MB) RKV archive containing all the game assets and the main game executable JIMMY.ELF (3.4MB).As usual you can find out about all the interesting cut content that was available in the prototype version at The Cutting Room Floor: Proto:The Adventures of Jimmy Neutron Boy Genius: Jet Fusion (GameCube, PlayStation 2) - The Cutting Room FloorStar Wars: The Force Unleashed for PS2, PSP and Wii (2008)Unlike the Xbox 360 and PS3 versions of Star Wars: The Force Unleashed the PS2, PSP and Wii versions were not built by LucasArts or use the Ronin engine.Instead they were developed by Krome Studios, a completely separate studio known for action-platformers and movie tie-in games.Krome developed these versions with a separate engine tailored for the older hardware and with unique content and gameplay elements. It is unlikely that ILM/LucasArts would allow their Zeno/Zed software to be used by a third party developer, so we presume these versions were not made using Zed and any assets were either sent over manually to the studio or made custom by Krome.Because of hardware constraints, these versions use the Open Dynamics Engine (ODE) for physics, rather than Havok, which powers the Xbox 360 / PS3 versions.Files in the PSP Version (UMD Disc contents)If you extract the files from the UMD disc you will get the following file structure:./PSP_GAME ICON0.PNG – Main XMB game icon (21 KB) PARAM.SFO – Game metadata: title, version, firmware (472 B) PIC0.PNG – XMB front image (12 KB) PIC1.PNG – XMB background image (151 KB) SND0.AT3 – Background audio (XMB menu music) (131 KB) SYSDIR BOOT.BIN – Main game executable (uncompressed) (5.4 MB) EBOOT.BIN – Main game executable (encrypted/compressed) (5.4 MB) UPDATE DATA.BIN – Firmware update installer data (19 MB) EBOOT.BIN – Firmware updater executable (5.4 MB) PARAM.SFO – Update metadata (2.0 KB) USRDIR PIC1.PNG – Duplicate XMB background image (150 KB) Attract01_60.pmf – In-game cutscene/attract video (4.7 MB) Attract02_60.pmf – In-game cutscene/attract video (2.7 MB) KromeLogo_60.pmf – Krome Studios logo video (1.2 MB) LucasLogo_60.pmf – LucasArts logo video (406 KB) LngEN_pp.rkv – English language archive (55 MB) LngFR_pp.rkv – French language archive (52 MB) data_pp.rkv – Main game data archive (models, textures, scripts) (892 MB) audiocodec.prx – Audio codec module (3.2 KB) libatrac3plus.prx – ATRAC3+ audio codec library (19 KB) libpsmfplayer.prx – Video playback module (32 KB) psmf.prx – Video parser module (6.9 KB) sc_sascore.prx – Audio library module (5.8 KB) The main executables are EBOOT.BIN and BOOT.BIN, it contains the standard firmware update files directory, XMB metadata for the game, some standard PRX modules (think DLLs but for the PSP) and there are some PlayStation Media Format (.pmf) videos used for cutscenes and studio logos.So it is all pretty standard PSP files apart from the RKV archives, these are where all the game data is stored, so any game modding or asset extraction takes places using these files.The BOOT.BIN executable confirms it is using the Krome Studios Merkury engine rather than the LucasArts Ronin engine used for the PS3 and Xbox 360 versions.Source file references in the PSP versionFor fun here is a list of unique strings that reference some of the original source code file names from inside the BOOT.BIN executable, they all seem to be related to the Ai system and all have the path prefix d:/starwars/src/StarWars/Source/ : Ai/PathMap.cpp Ai/Goals/AI_FollowEntityGoal.cpp Ai/Goals/AI_OrganisedRetreatGoal.cpp Ai/Goals/ScriptGoal.cpp Brains/AIBrain.cpp (AIBrain.h) Entity/Humanoid/Humanoid.cpp Props/CustomizeCostumeProp.cppGame Data Archives - .RKV filesThe game uses RKV archive format, specifically version 2 of the format, these can be extracted with Luigi Auriemma’s QuickBMS and the Rkv2 BMS script.Main Game Data Archive (data_pp.rkv)The data_pp.rkv file has 23,934 files in the PSP version, which seems to be unoptimized as it also contains assets with the Wii prefix such as Wii_Controller.tex and Wii_Vader_Gloves.min.Due to the huge amount of files in the archive, we are not going to list them out in this page, but the file extensions used for all of the files are in the table below: Extension Number of Files Description tex 4112 Texture image file (Magic header: TEX) min 3644 Minimal index or metadata file? mdg 2832 Model geometry or mesh data mdl 2832 3D model file bni 2605 Similar to bbi, a custom binary index file bbi 1688 Binary index or custom binary data file ang 1682 Possibly animation or angle data file anm 1682 Animation file pkg 775 Package file containing grouped assets cgr 692 Character graphics or 3D model data BPK 451 Likely a binary package or game resource file sbk 278 Sound bank file (see format below) at3 230 ATRAC3 compressed audio format used in PSP pmd 180 Polygon model data psb 88 PlayStation bitmap or proprietary sprite sheet mcd 66 Mission/cutscene data or custom game data txt 65 Plain text file mostly used for Locale string definitions per game platform e.g Xbox, PS2, Wii bin 11 Generic binary data file fnt 5 Font file, often bitmap or vector font FontInfo 3 Plain text Font metadata containing a simple script setting variables like CharMap, AspectRatio, CharSpacing, FontXScale and FontYScale bmfc 2 Possibly custom file with material or font info? fnb 2 Font binary file inc 1 Include file, likely script or code include mdb 1 Possibly model data or database file? mdd 1 Model animation or motion data? mine, r11913, r11979 3 Version Control files left over from a merge of the global.lv3.bni file (revision r11913 and r11979) tmp 1 Temporary file storing metadata, only used for one file called lastupdate.tmp csv 1 Comma-separated values text file xls 1 Excel spreadsheet file for translations (Translations.xls) BNI Files?Not quite sure what *.BNI files are, they always start with the ASCII string “D:\\starwars\\data\\RKVs..\\Common”, but I presume they are an archive, possibly compressed (but there is a lot of strings so maybe not).They also have a wide variety of names: global.lv3.bni - contain the string “Sire version 2.70 Data File version 3.0”, but not sure if Sire is an in-house tool or a third party software. global.sound.bni - contains strings like “swfx_RA_canon_ball_fire” GE.model.bniThe lvl files contain strings such as: PQuakePos - Also has QuakeRot Was this a quake format? GameDefaultCamera - camera settings such as nearPlane and farPlane =BOUNDING_REGION - Bounding Box informationLeft-over development contentThe .mine, .r11913, .r11979 files suggest use of the RCS (Revision Control System) version control system as it uses these extensions to manage file revisions and resolve conflicts locally.Also it also highlights that the RKV files have a lot of files that are not required by the game at runtime, these version control files and also the translation Excel spreadsheet Translations.xls. it looks like they just archive a certain folder and distribute it with the game. unfortunately for us they didn’t accidentally also include any debug symbols or source code in the archives.Language Specific Sound Bank Archives (LngEN_pp.rkv and LngFR_pp.rkv)LngEN_pp.rkv and LngFR_pp.rkv contain sound bank files (.sbk) for their respective languages, presumably all the voiced dialog in the game is contained in these and they have the file name format like cscc001_01_00_p01dven.sbk.Likely naming format breakdown: cscg001: Likely an ID for a cutscene, always prefixed with “cs” presumably standing for cutscene. 01_00: Major/minor numbers w.g for scene/area, event, sequence, or version p01 - Possibly part 1/phase 1 or referencing a specific voice/group. dv - Character anchors e.g dv is Darth Vader en - Audio Language (Known values: en, fr)SNK Cutscene CodesPossible cutscene codes are presented in the table below: Cutscene ID Likely scene Rationale (where applicable) csdv001 Darth Vader prologue (Kashyyyk) “DV” = Darth Vader; prologue is a Vader mission. cska2xx Kashyyyk “ka” matches planet. csfe1xx/2xx/20x/205 Felucia “fe” = Felucia. csrp1xx/2xx Raxus Prime “rp” = Raxus Prime. csjt1xx/2xx Jedi Temple (trials) “jt” = Jedi Temple. csmu001 Mustafar (historic mission) “mu” = Mustafar. csns201 Nar Shaddaa “ns” = Nar Shaddaa. cstc001/101 TIE Construction Facility “tc” = TIE Construction; early game mission. csds201 The Dune Sea (Tatooine historic mission) “ds” = Dune Sea; appears as historic mission. cscc001/201/202/204/205 Carbonite Chamber (Bespin historic mission) “cc” = Carbonite Chamber. cscg001 Geonosis Colosseum (historic mission) “cg” = Colosseum Geonosis. csdq001 Dooku’s Quarters (Geonosis historic mission) “dq” = Dooku’s Quarters. csvo001 Vader’s Observatory/Vessel? “vo” ambiguous; likely Vader-related interstitial. csvf101/102/104 Vader’s Flagship/Facility? “vf” ambiguous; Vader-adjacent (briefings/bridges). csqg001 ? Geonosis-related (Qui-Gon is unlikely) “qg” unclear; could be internal codename. cspl001 ? Palace (Jabba’s) “pl” plausible “(Jabba’s) Palace” historic. csps001 ? Palace/Cantina sequence “ps” ambiguous; may be Tatooine set-piece. csrg001 ? Raxus (Gateway)/Royal Guard “rg” unclear; could be encounter beat. csrh201 ? Raxus H- (Hub/Hangar/Holo) “rh” unclear; grouped with Raxus arc number. csrs001 ? Raxus Scrap (yard) “rs” plausible for “scrapyard”. csfd001 ? Felucia derivative “fd” could be Felucia boss/dialogue beat. csil101 ? Imperial Laboratory/Library “il” ambiguous; story contains Imperial facilities. csos001 ? Ossus “os” could be Ossus (Jedi world); unconfirmed. Although these are a guess, proper analysis including playing each of the SBK files while playing the game would be required to give more concrete information.SBK - Sound Bank File FormatAfter some initial analysis it seems the .SBK (header: SB01) files contained in the RKV archives is a small custom container that wraps a mono PSX-ADPCM stream. The container adds a fixed header (magic/version/size/name/flags) and stores raw ADPCM frames without a VAGp/RIFF wrapper.Here are the header Metadata fields, numbers are all 32-bit Little Endian: Magic - Always “SB01” (ASCII) at 0x00 Version - e.g 0x00000001 at 0x04 File size - e.g 0x000029D0 (= 10704) at 0x08 Name - e.g “CSZZ001_00_00_P01ZZEN” (ASCII, 32 bytes, NUL-padded) at 0x10 Header size - e.g 0x50 (= 80 bytes) at 0x30 Data size - 0x2980 (= 10624 = file_size − header_size) at 0x34 Flags/SampleRate - e.g 0x80004A38; low bits 0x4A38 = 19000 Hz, high bit likely a format flag at 0x38 Audio payload offset - e.g 0x50 (immediately after the header)The rest of the file is consistent with PSX ADPCM (a.k.a. VAG): 16-byte frames with pattern 0x0C 0x00 … repeated mono frames (1-byte predictor/shift, 1-byte flags, 14 data bytes → 28 PCM samples/frame).Script to convert .SBK to WAVHere is a Python3 script to convert the .SBK files to WAV:# Convert .SBK (Merkury Engine Sound Bank, Star Wars Force Unleashed) to WAVimport os, struct, wave, resrc = \"./output/csch001_13_03_p01hten.sbk\"with open(src, \"rb\") as f: blob = f.read()# Basic SB01 parsemagic = blob[0:4]version = int.from_bytes(blob[4:8], \"little\")total_size = int.from_bytes(blob[8:12], \"little\")name = blob[0x10:0x30].split(b\"\\x00\",1)[0].decode(\"ascii\", \"replace\")hdr_size = int.from_bytes(blob[0x30:0x34], \"little\") # typically 0x50data_size = int.from_bytes(blob[0x34:0x38], \"little\") # total_size - hdr_sizeflags_sr = int.from_bytes(blob[0x38:0x3C], \"little\") # 0x80000000 | sample_rateaudio = blob[hdr_size:hdr_size+data_size]# Extract sample rate from low 16/32 bits; keep high bit as a flagsample_rate = flags_sr & 0x7FFFFFFF # remove 0x80000000if sample_rate == 0 or sample_rate > 192000: # fallback if the high bit wasn't just a flag sample_rate = flags_sr & 0xFFFF# Minimal PSX ADPCM (VAG) decoder (mono). Each frame is 16 bytes -> 28 samples.COEFFS = [ (0.0, 0.0), (60.0/64.0, 0.0), (115.0/64.0, -52.0/64.0), (98.0/64.0, -55.0/64.0), (122.0/64.0, -60.0/64.0),]def decode_frame(frame, p1, p2): shift = frame[0] & 0x0F filt = frame[0] >> 4 flags = frame[1] a1,a2 = COEFFS[filt] if 0 <= filt < len(COEFFS) else (0.0,0.0) out = [] for i in range(2,16): b = frame[i] for nib in (b & 0x0F, (b >> 4) & 0x0F): s = nib if nib < 8 else nib - 16 sample = (s << 12) >> shift sample = int(sample + p1*a1 + p2*a2) sample = max(min(sample, 32767), -32768) p2, p1 = p1, sample out.append(sample) return out, p1, p2, flagspcm = []p1=p2=0i=0# Skip any leading 0x00 frames (padding)while i+16 <= len(audio): frame = audio[i:i+16] if frame == b\"\\x00\"*16: i += 16 continue batch, p1, p2, fl = decode_frame(frame, p1, p2) pcm.extend(batch) i += 16dst = f\"./{name}.wav\"with wave.open(dst, \"wb\") as w: w.setnchannels(1) w.setsampwidth(2) w.setframerate(sample_rate if 8000 <= sample_rate <= 96000 else 19000) w.writeframes(b\"\".join(struct.pack(\"<h\", s) for s in pcm))print (\"Success:\", dst, len(pcm), sample_rate, magic, version, total_size, hdr_size, data_size)Star Wars Lightsaber Duels for the Wii (2008)There is a video on youtube of a quick behind the scenes route of the Krome offices back in 2008 where they interview the lead programmer of Star Wars Lightsaber Duels Chris Lacey (The Shak EP454)?Merkury 3 - Xbox 360, PS3 and Wii (2010)Lead Environment Artist at Krome Studios Brent Waller posted a video showing off the new Merkury 3 engine in action which was built for the Xbox 360, Playstation 3 and Wii Title: The Legend of the Guardians: The Owls of Ga’hoole.To quote Brent Waller 20: The engine has such features as large scale (16 square kilometres) terrain rendering and LODing, grass and forest LODing and placement tools and real-time day and night cycles.You can watch the video below:References Merkury on the official kromestudios.com website ↩ ↩2 ↩3 ↩4 Chris Lacy of Krome Studios talks to PGC! - Interview - Nintendo World Report ↩ Interactive Binary Illusions - MobyGames ↩ ↩2 RGB Classic Games - Company info for Gee Whiz! Entertainment ↩ Gee Whiz! Meet The Gang - archived March 27th 1997 ↩ ↩2 PC Powerplay Issue 062 - July 2001 - Next Publishing Pty Ltd ↩ Mind Mechanics - News archived April 1999 ↩ ↩2 Flight of the Amazon Queen (1995) - MobyGames ↩ Flight Of The Amazon Queen / Flug Der Amazon Queen - Hall Of Light - The database of Amiga games ↩ ↩2 Queen - ScummVM Wiki ↩ Gee Whiz! Labs - - archived March 27th 1997 ↩ ↩2 Screen Opera Press release for Jaruu on 4th October 1999 ↩ Screen Opera ↩ Screen Opera Press Release for Halloween Spirit Board ↩ ↩2 Crazy Fun Games (2001) - MobyGames ↩ Kat Burgler on the official kromestudios.com website fetched on Dec 12th 2000 ↩ Games On Net - The Unreleased Games of Krome Studios ↩ Sunny Garcia Surfing PS2 Manual ↩ Star Wars: The Force Unleashed PS2 Manual ↩ ↩2 Merkury 3 Engine Showcase - YouTube ↩ ", "excerpt": "The Merkury engine is a proprietary game engine developed by Krome Studios since at least 2001, known to run on PS2, PSP, Wii and with version 3 of the engine it added support for Xbox 360 and PS3. It is likely also running on the Nintendo Switch thanks to the...", "tags": ["middleware","gameengines"], "image": "/public/generated/placeholders/krome-merkury-engine.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Industry Leaks - Game Industry Source Code Leaks", "url": "/leaks", "content": "The games industry has had its fair share of cyberattacks in the past decade and one of the main targets for hackers has always been source code. This post will cover all the major leaks that we are aware of for companies related to the games industry. Specifically focussing on programming related source code rather than assets or design documents, but many contain both types of content.This post covers leaks related to entire companies, if you are looking for leaks for a specific game then check out our page on retail source code leaks: Retail Console Game Source code (C/C++) For more information check out this post. NvidiaOn March 1st 2022 the source code to Nvidia DLSS 2.2 was leaked online.NintendoThere have been so many leaks from Nintendo that we have our own dedicated page just for them here: All Nintendo Leaks For more information check out this post. CapcomOn 1st November 2020 CAPCOM was targeted by known hacker group RagnarLeaks and some source code and private data were leaked to the dark web.We have a separate page covering the content of this leak: Capcom Leaks For more information check out this post. Not covered in that post was source code related to an unreleased Resident Evil game which was not retro enough to be covered on this site.MicrosoftMicrosoft has been the target of multiple hacks over the years, from the theft of the original Xbox firmware source code to the more recent release of the Windows XP source code.In September 2020 the source code for Microsoft’s Windows XP Operating System was leaked online. We will have a post covering this in the future.RockstarAlthough it didn’t contain any programming files, the studio “accidentally” released a folder of internal development tools and game scripts in the retail release of GTA Trilogy for the Nintendo Switch.The Switch version is the Holy Grail for people, who likes behind the scenes. They leaked almost everything for the original trilogy. It includes:Script sources...Text sources...Internal tools...Some other weird files... pic.twitter.com/FjvONzbeNh— Vadim M. (@NationalPepper) November 12, 2021All Posts ATI Low Level Wii SDK Introduction In 2020 and 2021 numerous secret files have been leaked from Nintendo thanks to Zammis Clark. Included in these files were source code for a variety of Wii internal... ... Read More wii sdk leak gamecube BroadOn Archive - Nintendo May 2020 Leak (4Chan) In early May 2020 a leak of Nintendo Source Code hit the popular image board 4chan. The material contained in this leak was obtained by a young hacker known as... ... Read More wii n64 sdk leak ique Capcom Leaks On 1st November 2020 CAPCOM was targeted by known hacker group RagnarLeaks and some source code and private data was leaked to the dark web. This post will only cover... ... Read More leak ps1 ps2 wii Nintendo DsiWare Leak As part of the Platinum Leak on the 9th of September 2020 a ton of DsiWare titles were leaked, including debug versions of games like Legend of Zelda Four Swords... ... Read More ds leak debug Nintendo Emerald Leak The Emerald leak occurred on the 2nd of September 2020 and included about 700MB of content related to the Wii and gamecube. So this would not quite qualify as a... ... Read More wii leak Original F-Zero Source Code (Gigaleak) The Nintendo Gigaleak preserves a small but unusually useful F-Zero source archive under other/SFC/ソースデータ/FZERO. This is not just a loose dump of assembly files. It preserves the main game code,... ... Read More snes leak sourcecode Gigaleak - Game Boy Advance Boot ROM Repository The Nintendo Gigaleak preserves the AGB boot ROM material in two useful forms. Inside other/agb_bootrom it survives as a real Subversion repository, and separately the leak also includes agb_bootrom_trunk.zip, an... ... Read More gameboy gba leak sourcecode Gigaleak - Game Boy Color Boot ROM Repository The Nintendo Gigaleak preserves the CGB boot ROM material in two useful forms. Inside other/agb_bootrom it survives as a compact SVN repository, and separately the leak also includes cgb_bootrom_trunk.zip, an... ... Read More gameboy leak sourcecode Gigaleak - SNES Source Code Leak On 24 July 2020, a large Nintendo archive was uploaded online and quickly became known as the Gigaleak. It was not one single neat source drop. It was a mixed... ... Read More snes leak sourcecode Gigaleak 2 Electric Boogaloo - N64 Source Code Leak On the 25th of July 2020, the day after the Gigaleak, its sequel Gigaleak 2 was uploaded to a thread on 4chan. This is a continuation of the leaks that... ... Read More n64 sdk leak Gigaleak NEWS_05 - Star Fox 2 3D CAD Pipeline & Development Toolkit NEWS_05.tar is a 109 MB workstation backup snapshot from a Nintendo developer’s machine, dated around May 1995. Unlike the structured source-code drops elsewhere in the Gigaleak, NEWS_05 captures raw mid-development... ... Read More snes leak sourcecode tools Nintendo Hidemaru Mail Leak Introduction In 2020 and 2021 numerous secret files have been leaked from Nintendo thanks to Zammis Clark. Included in these files were the Corporate Emails inbox of an employee called... ... Read More leak Original Super Mario Kart Source Code (Gigaleak) The Nintendo Gigaleak preserves a very substantial Super Mario Kart source archive under other/SFC/ソースデータ/MarioKart. Unlike the F-Zero leak, this is not neatly split into Game and Tools. It looks much... ... Read More snes leak sourcecode Netcard - Cancelled GBA Online Peripheral The netcard folder from the Gigaleak contains the documentation, SDKs, and design specifications for an officially scoped but ultimately cancelled online gaming peripheral for the Game Boy Advance. {% capture... ... Read More gba leak pokemon Nintendo Ninja Leak The Ninja leak occurred on the 22nd December 2020 and is named after the contents containing information that prove the long-standing Nintendo “Ninja” myth. Including stalking and intimidation of a... ... Read More leak ds 3ds All Nintendo Leaks Nintendo has has many data leaks in the past, but none as huge as the original Oman Archive of the late 90s or the Gigaleaks of 2020. This post is... ... Read More leak nintendo 3ds gba Nintendo Lot Check ROM Leak Since Nintendo controls manufacturing of all official games they have a process called Lot Check that ensures the games quality before manufacturing. Every game ever officially released for their platform... ... Read More leak nes Oman Archive - N64 Leak by SGI employee The Oman Archive was a leak of Nintendo Technical documents from a source inside SGI in late 1999. It was uploaded to the internet under the name oman.rar but has... ... Read More n64 sdk leak Pokemon Original Source Code Leak On the 11th April 2020 the source code to the original generation of Pokemon games was released to 4chan as osrc.zip. This zip archive contained a password protected zip file... ... Read More leak gameboy Nintendo Paladin Leak The Paladin leak occurred on the 30th of September 2020 and included about 2.4GB of content related to the Nintendo IRIS and Pokemon spinoffs. This was the third Nintendo leak... ... Read More leak ds 3ds gba Pilotwings 2D Art Workspace (fly/flyman) The Nintendo Gigaleak preserves a separate Super Mario Kart art workspace under other/NEWS/テープリストア/NEWS_04/home/sugiyama/fly and home/sugiyama/flyman/, from Nintendo artist Tadashi Sugiyama. These directories are almost entirely art-side production material from the... ... Read More snes leak Nintendo Platinum Leak The Platinum leak occurred on the 9th of September 2020 and included gigabytes of content, hence why some call it GigaLeak 3. {% include_cached link-to-other-post.html post=”/gigaleak” description=”For more information on... ... Read More ds leak sourcecode Super Famicom SFX-DOS Development Environment The Nintendo Gigaleak preserves a surprisingly complete Super Famicom disk and I/O environment inside the Super Mario Kart source directory. This is the SFX-DOS stack: a SNES-side support layer for... ... Read More snes sdk tools leak SimCity SNES 2D Art Workspace (SIM) The Nintendo Gigaleak preserves a separate SimCity SNES art workspace under other/NEWS/テープリストア/NEWS_04/home/sugiyama/SIM. Compared with the much broader Mario Kart CAR folder, SIM is smaller and more focused. It is almost... ... Read More snes leak The Simpsons Hit & Run Source Code Leak Introduction On the 21st August 2021 the full source code to the classic GTA clone staring The Simpsons was released online. This included both the C++ source code plus the... ... Read More ps2 xbox gamecube leak Original Star Fox Source Code (Gigaleak) The Nintendo Gigaleak preserves a compact but very revealing Star Fox source drop under other/SFC/ソースデータ/StarFox. Unlike the F-Zero leak, this one is not laid out as loose source folders from... ... Read More snes leak sourcecode superfx Original Star Fox 2 Source Code (Gigaleak) The Nintendo Gigaleak preserves a much larger and messier Star Fox 2 workspace under other/SFC/ソースデータ/StarFox2. Unlike the original Star Fox drop, this one is not just a compact source archive.... ... Read More snes leak sourcecode Star Fox 2 - 2D Art Workspace (NEWS_04 Archive) Archive Source This article analyzes the Star Fox 2 2D art and graphics workspace preserved in the Gigaleak - specifically from the NEWS_04 archive, a 96 MB Nintendo NEWS workstation... ... Read More snes leak starfox2 graphics gigaleak Stunt Race FX 2D Art Workspace (FX2) Archive Source This page is based on Gigaleak NEWS_04 home/sugiyama/FX2/ (41 files), from Tadashi Sugiyama’s workspace. Glossary FX2 - Wild Trax / Stunt Race FX UI-art folder. cpt - Cup/captain... ... Read More snes leak Super Game Boy SDK Sample and BIOS Files Super Game Boy SDK Sample and BIOS Files This page covers the sgb folder preserved in the Nintendo Gigaleak inside: other/CGB AZL__ゼルダの伝説 夢を見る島DX Source/Disk1/ゼルダの伝説_JP3_US3_EU2/DEMO_zelda/sgb Although it was found inside the... ... Read More gameboy sdk leak sourcecode Original Super Mario Collection / All-Stars Source Code (Gigaleak) The Nintendo Gigaleak preserves a compact but unusually revealing Super Mario Collection source archive under other/SFC/ソースデータ/srd13-SFCマリオコレクション. This is the Japanese Super Famicom release better known in the West as Super... ... Read More snes leak sourcecode Super Mario Kart 2D Art Workspace (CAR) The Nintendo Gigaleak preserves a separate Super Mario Kart art workspace under other/NEWS/テープリストア/NEWS_04/home/sugiyama/CAR. Unlike the main source tree, this directory is almost entirely art-side production material. It is a flat... ... Read More snes leak Nintendo Switch Game Card Leak On the 20th July 2021 the Nintendo Leaks (aka Gigaleaks) continued after a long hiatus. One of the files uploaded by the leakers was datasheet.7z. The archive contains low level... ... Read More leak switch The Unexpected 2021 Nintendo Leak On the 20th July 2021 the Nintendo Leaks (aka Gigaleaks) continued after a long hiatus, the content was obtained by Zammis Clark and then leaked online by anonymous individuals. Files... ... Read More leak wii gamecube Verilog Verilog (Verify Logic) is a hardware definition programming language, this means that it is a text representation of a Digital circuit. So if you wanted to design your own hardware... ... Read More hardware n64 leak Nintendo Wii Diagnostic Disc Source Code In the Nintendo leak on 20th July 2021 an archive called DIAG4RVL.7z was released to the internet, this archive contains a CVS repository containing 3 different software development kits for... ... Read More wii sdk leak gamecube Original Wild Trax / Stunt Race FX Source Code (Gigaleak) The Nintendo Gigaleak preserves a large Super Famicom source tree under other/SFC/ソースデータ/ワイルドトラックス. This is the Japanese Wild Trax project, better known in the west as Stunt Race FX. What makes... ... Read More snes leak sourcecode Original Yoshi's Island Source Code (Gigaleak) The Nintendo Gigaleak preserves a very large Yoshi’s Island archive under other/SFC/ソースデータ/ヨッシーアイランド. This is the Super Famicom codebase for Super Mario World 2: Yoshi’s Island, and it survives in a... ... Read More snes leak sourcecode Original The Legend of Zelda - A Link to the Past Source Code (Gigaleak) The Nintendo Gigaleak preserves a large Super Famicom Zelda source archive under other/SFC/ソースデータ/ゼルダの伝説神々のトライフォース. This is the Japanese game better known in the West as The Legend of Zelda: A Link... ... Read More snes leak sourcecode Gigaleak - Original Zelda Links Awakening Source Code (DMG) The Zelda Links Awakening source code was released in the original Gigaleak inside dmg.7z, itself stored inside Other.7z. This part of the leak contains much more than a single source... ... Read More gameboy leak sourcecode The Legend of Zelda Link's Awakening - 2D Art Workspace (NEWS_04 Archive) Archive Source This article analyzes the Link’s Awakening 2D art and graphics workspace preserved in the Gigaleak - specifically from the NEWS_04 archive, a 96 MB Nintendo NEWS workstation backup.... ... Read More gameboy leak Zelda Links Awakening DX Source Code (CGB) The CGB.7z section of the Nintendo Gigaleak preserves Game Boy Color-era material for two projects: The Legend of Zelda: Link’s Awakening DX and Hamtaro 2. For Zelda, this archive is... ... Read More gameboy leak sourcecode iQue Gamecube Leak (BB2) Introduction In 2020 and 2021 numerous secret files have been leaked from Nintendo thanks to Zammis Clark. Included in these files were documentation and source code for an unreleased console... ... Read More gamecube leak ", "excerpt": "The games industry has had its fair share of cyberattacks in the past decade and one of the main targets for hackers has always been source code. This post will cover all the major leaks that we are aware of for companies related to the games industry. Specifically focussing on...", "tags": ["leak","introduction"], "image": "/public/generated/placeholders/leaks.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Legality of Reverse Engineering & Clean Room Reversing", "url": "/clean-room-reversing", "content": "Reverse Engineering of commercial Games and Applications straddles a fine line of legality. Whether a Reverse Engineering project is legal or not completely depends on how it was accomplished.Conversion from one from to another is still under copyrightFor example simply disassembling a compiled binary and releasing it is equivalent to converting a copyrighted photograph from one image format to another (e.g PNG to JPG), it is still under the copyright of the original creator.What about annotated disassemblies?Most reverse engineering projects don’t just convert a binary executable to a direct assembly source file, they add annotations to the assembly such as comments, variable and function names. You could argue (in court) that these annotations have created a derivative work if the annotations are substantial enough to justify such a claim.Keep annotations separateThe safest way legally speaking would be to distribute the annotations (comments, variable/function names) separate from the source material (disassembled code). One example of this is releasing a symbol table which contains the variable/function names along with their position in the original executable, it would then be up to the end-user to disassemble and join the symbol table to the output.Some impressive examples of disassembly annotations that are available on Github are covered in our post: Decompiled Retail Console Games For more information check out this post. Some release both the disassembled code and a symbol file which can be attached to a debugger.Bare in mind this is not a criticism of Github projects containing both the disassembly along with the annotations, we are not passing judgement saying these are illegal, we are not lawyers, we simply don’t have evidence of court cases where this was put to the test. Although we do personally hope that it never does get put to the test in a court of law, there are so many impressive reverse engineering projects that would be impacted if the ruling was negative.Reimplementations, Remasters and RemakesSo far we have discussed reverse engineering projects that are educational in nature, annotating what functions and variables are used for. But what about decompilation or re-implementations where the purpose is porting to a new platform or modernization? This is where it gets even more risky.For simplicity in the rest of this post will will refer to decompilation/remasters/remakes that are based on the original source but written in a higher level language (such as C/C++) simply as re-implementations.Never distribute original AssetsFirst of all it is important to make sure no original game assets (sprites, sounds, 3d models etc) are distributed with the re-implementation, this is a no-brainer as they are original unmodified copyrighted works so fair use would not apply. This means you need to be extra careful when developing and don’t * accidentally* commit assets to source control (and if you do, don’t forget to purge the history after deleting).Potentially supports the source materialThis also has the added benefit that any users for your re-implementation will need to own a copy of the original game in order to obtain the assets, supporting the original copyrighted work in the process. Although note that this in no way will prevent the copyright holder from pursuing legal action and would not be a strong defense in court, but it can help your case and not doing it would most definitely harm your case.Legality of approaches for Reverse Engineering CodeNow what about the code for the re-implementation or any compiled executables built from that source code?For this we have three options: Clean Room Reverse Engineering (The Best way) Dusty Room Reverse Engineering (Never tested in court, risky) Dirty Room Reverse Engineering (Impressive but also the least protected way)Clean Room ReversingClean Room Reverse Engineering is the only method that has successfully stood up in court (see SEGA vs Accolade). However it is also the hardest to accomplish and requires separate teams of people.One team have access to the original executable and reversing software such as disassemblers, decompilers, Hex Editors etc but has no access to write code. The other team has absolutely no access to the original product and has to rely on the documentation created from the first team to write the code.Note that using Clean Room Reversing does not mean that you won’t get sued, it just means that if you do then you will have a stronger defense than without using it.You may also need to prove that the implementors did not have access to the original implementation, this could be near impossible on a public project that accepts Pull Requests from the general public.Dusty Room ReversingThe difficulty of Clean Room reversing is it requires multiple teams of people including people that have never seen any details of the original executable.A small team of 1 would never be able to accomplish that and thus would need access to the original executable and write the implementation themselves.One way to make the work more transformative is to write it in a higher level language that the original program would have been written in. For example re-implementing a native PS2 game in the high-level language Javascript. The resulting implementation would have to be vastly different from the original and would be closer to the definition of a transformative work.Dirty Room ReversingThe least legally sound method of reverse engineering (but arguably the most impressive) are reversing projects that have re-written the assembly into the original high-level language that the game was written in and are able to compile an almost byte-identical executable from it.The Super Mario 64 Decompilation project is an example of this as they have managed to write C code that compiles with the original compiler into the exact same binary as was released on the ROM cartridge. This took many years to achieve and many talented reverse engineers working via trial and error with the original compile technology.History of Reverse engineering in the Games IndustryReverse engineering is nothing new in the games industry and can go all the way back to the first Arcade games, with developers trying to figure out how their competitors managed to pull off the seemingly impossible in their new games.SEGA vs EAFormer SEGA of America CEO Tom Kalinske was in charge when EA reverse-engineered the Sega Mega Drive. He was furious and famously said: “Trip [Hawkins], didn’t your mother ever teach you the difference between right and wrong?”This may have got the meeting off to a rough start but in the end SEGA got John Madden football and EA got favoured licensing rights.So reverse engineering the Sega Mega Drive certainly brought benefits to both EA and SEGA at the time!How Sega bet against Reverse Engineering…and lostModern Vintage Gamer has an excellent video about the history of reverse engineering on the Sega Genesis. It covers the technical and legal strategies used by Electronic Arts and Accolade to bypass the console’s TMSS security chip, detailing how clean-room reverse engineering led to a landmark court ruling for software interoperability.Rare Reverse Engineered the NES to get an Official Nintendo LicenseThe British company Rare made gaming history by becoming the first non-Japanese licensed game developer for the NES, securing the license from Nintendo through an ingenious demonstration of their skills by reverse engineering the console and showcasing the game “Slalom” as a convincing demo to Nintendo in 1986 1.References Retro Gamer Issue 84 from December 2010 pages 34–35. ↩ ", "excerpt": "Reverse Engineering of commercial Games and Applications straddles a fine line of legality. Whether a Reverse Engineering project is legal or not completely depends on how it was accomplished. Conversion from one from to another is still under copyright For example simply disassembling a compiled binary and releasing it is...", "tags": ["introduction"], "image": "/public/images/clean-room-reversing.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Zeno and Zed - LucasArts & ILM's Unified Production Pipeline", "url": "/lucasarts-zino-and-zed", "content": "Introduction to Zeno and the Zed Game EditorBack in 2004/2005 engineers at LucasArts were on a mission to find the best technology for the new “next-generation” consoles (Xbox 360, PS3), they travelled the world assessing various middleware and proprietary game engines 1. Unbeknownst to them, they would actually find an ideal solution sitting in their own backyard.At that time George Lucas owned the film company Industrial Light & Magic (ILM) along with the games company LucasArts, both companies were pioneering in the field of 3D graphics but they didn’t directly work with each other.This changed when the LucasArts engineer Nick Porcino attended an ILM R&D “open house” and witnessed the power of ILM’s in-house Zeno 3D application framework and immediately thought of the potential for game development 2.Zeno helps ILM build and populate digital stages for their films. It contains texture controls, particle generators, and systems for digital actors. Its only drawback is that it’s rooted in rendering; each frame is rendered individually in a time-consuming process, so making changes is very slow going.Zeno was a modular framework that was used throughout the whole of the ILM studio since at least 1997, to build and populate digital stages for their films. It contained modules for modifying textures, particles and digital actors. However as Zeno was made for the film industry it was not build for real-time 3D pipelines and this making changes in Zeno was a very time consuming process 1.So LucasArts wondered, what if they could modify Zeno to add real-time viewing of assets at runtime using game engine technology, this would not only benefit LucasArts but the whole of ILM would benefit from being able to view assets in real-time.By bringing the film and video game companies closer together they could share the practices of real-time visualization developed for game production in their films and at the same time to provide game makers with high-resolution film scenes as source material, win-win.Thus the real-time Zeno Editor known as Zed was born and was slowly gaining more and more collaborators in both LucasArts and ILM!Bringing the Games and Film industries togetherAt roughly the same time as the Zed project was taking off, George Lucas wanted to bring ILM and LucasArts even closer together, physically this time. He consolidated the offices and moved both LucasArts and ILM to the Letterman Digital Arts Center (LDAC) in Presidio California.This accelerated development of both Zeno and Zed and was praised by the LucasArts president Jim Ward in Computer Graphics World Magazine 3: In the same spirit of collaboration and consolidation of assets and talent, ILM and LucasArts are now housed in the same building on George Lucas’s Presidio campus. “[The idea] came from George himself, and it’s key to rebooting our game studio.”On what was a former Presidio military base, the new 6 acre facility claimed to have the industries largest computer network, designed to accommodate 4K images via 300 10GB and 1,500 1GB ports. It was surrounded by 17 acres of public park including a creek and even a Yoda fountain!There is a very good reason why the move to the new premises keeps getting mentioned in articles about Zeno and Zed, it really was the catalyst that allowed not only knowledge to flow freely but also assets from both movies and games could be shared on the 600 miles of high speed network cable within the facility!The designer of the Zeno interface Dennis Muren has the following to say about the move and its impact on the Zeno pipeline: The move opened the opportunity to re-invent the pipeline, with the Star Wars movies ending, we’re going to get down to a more realistic number of shots. So we’ve given the artists the opportunity to do practically anything if they want to. 4In the September 2005 issue of 3D World magazine 4, they had some interesting statistics in their coverage of the move to the new building:Zed - The Zeno Game Editor (2004)We learn more about the birth of the Zeno Game Editor (Zed) in a 2006 Game Developer Conference (GDC) Talk titled “LucasArts and ILM: A Case Study in the Convergence of Game and Films”.The story goes that after attending the ILM Open House and witnessing Zeno for the first time Nick Porcino and Steve Sullivan together envisioned a “Virtual Studio” integrating LucasArts and ILM pipelines together 5.The result of the “Virtual Studio” became known as Zed (Zeno Editor), it provided a direct link between the game production process and the sophisticated asset management, lighting, animation, and physics tools pioneered in Zeno at Industrial Light & Magic, supporting rapid iteration and collaborative workflows in large-scale projects.Goal of ZedThe goal of Zed according to Cliff Plumer, Chief Technical Officer of ILM, was to enable multiple users to collaborate in real-time, both LucasArts and ILM employees. So that assets sculpted in ILM could simply be dropped into Zed and used in LucasArts projects, allowing an efficient sharing of resources 4.These tools formed the backbone of the pipeline that linked LucasArts and ILM, ensuring assets and scenes could be collaboratively developed and transferred in real-time.Features of Zed/ZenoWhere Zeno ends and Zed begins is a little hard to follow from the outside so the following list of features may apply to either zed and/or zeno (hard to tell from sources, which feature belonged to which software): Consistent user interface - One UI pattern to learn rather than learning hundreds of different UI tools 4 Modular - modules could be loaded and unloaded when needed 6 Multi-user editing - Concurrent editing of assets so artists didn’t need to wait for each other 4 Revision control - Stroing previous versions of assets 4 Asset Mangement - Easy access to all assets in a project/scene 4Contributors to ZedWe don’t know all the contributors to Zeno/Zed as there is very little information available about it online but these are people that have been mentioned in relation to developing it: Nick Porcino - co-founder of Zed Steve Sullivan - co-founder of Zed Dennis Muren - Designer of Zeno interface 4 Cliff Plumer - CTO of ILM Tim Ramsay Eric Johnston Nick PavisGames built with ZedZed played a major role in the development of games like Star Wars: The Force Unleashed, allowing seamless coordination between game asset creation and in-engine testing.Zed was intended not just for star wars but also a future Indiana Jones game that would later be cancelled: To create its upcoming Indiana Jones 2007 and next-gen Star Wars titles, LucasArts will also be using its Zeno Game Editor, which is incorporated into ILM’s Zeno Development Environment, allowing both film and game artists access to the same tools. LucasArts can now use ILM’s high-end art creation software, while ILM can tap into LucasArts’ real-time technology, which underlies their previsualization tools 3LucasArts used Zed/Ronin for The Force Unleashed II (2010), but later projects like Star Wars 1313 were developed on Unreal Engine 3 7. Although sadly the Star Wars 1313 project was cancelled after Disney shut down LucasArts in 2013.Later Developments and Legacy of ZedAfter the collapse of LucasArts, Zed would live on in the real-time rendering feature of Zeno which is still in use by ILM today.The spirit of Zed extended into ILMxLAB (founded in 2015) but used the Unreal Engine directly instead of Zed, producing projects like Vader Immortal and powering ILM’s StageCraft for The Mandalorian 7. It is currently unknown if they have an integration between Unreal Engine and Zeno, if so then you could say parts of Zed are still alive and well in the games industry.The Ronin Engine - Star Wars: The Force UnleashedIn 2005, ILM Chief Technology Officer Cliff Plumer called Zed the LucasArts Game Engine: We’ve been working on collaborative tools with LucasArts for 18 months… Zed, which is LucasArts’ game engine, will have a live connection to Zeno 8.Which is somewhat true as it provided real time rendering to the Zeno platform as a sort of PC game engine, however its not to be confused with the actual game engine that ran Zed games on consumer hardware such as the Xbox 360 and PS3. So as to avoid confusion this article will call Zed the Game editor (think IDE) and Ronin the Game Engine.So while Zed was the game editor software used for building the game, to actually execute the scenes created in Zed on the PS3 or Xbox 360 would require a game engine.Thanks to The Art and Making of Star Wars The Force Unleashed from 2008 we learn that the game engine is called Ronin and although it was only used for the one game it was intended to be used as the basis for multiple including a cancelled Indiana Jones title 9.In this article we will use Zed to refer to the game development tooling based on Zeno and Ronin to refer to the game engine which ran on PS3 and Xbox 360 and was used for Star Wars: The Force Unleashed.There was also a Wii and PS2 version developed but it is unclear how much of the Ronin game engine code they used, they are known to use their own in-house physics engine instead of Havok 10.Middleware in RoninRonin integrated DMM and Euphoria, producing realistic, non-repeating physics; an E3 2006 demo compared throwing R2-D2 at wood in a traditional engine vs. Ronin’s real-time physics 11 along with the following middleware: Havok - Physics engine 6 Digital Molecular Matter (DMM) - Pixelux Entertainment’s Digital Molecular Matter 6 Euphoria 6PS2, PSP and Wii VersionThe PS2, PSP and Wii versions of “Star Wars: The Force Unleashed” are not build by LucasArts and thus are not using their proprietary Ronin engine. Instead they were developed by Krome Studios, a completely separate studio known for action-platformers and movie tie-in games.Krome developed these versions with a separate engine called Merkury tailored for the older hardware and with unique content and gameplay elements. The physics engine for these versions of the game use the Open Dynamics Engine (ODE) rather than Havok due to the performance constraints of the PS2, PSP and Wii.It is unlikely that ILM/LucasArts would allow their Zeno/Zed software to be used by a third party developer, so we presume these versions were not made using Zed and any assets were either sent over manually to the studio or made custom by Krome. This is also confirmed by analysing the game files for the Merkury versions as there is no reference to any of LucasArts tools and the Merkury engine was used on games before this project so it would be unlikely that they would share any code from Ronin.We have a separate post on the Merkury engine including analyzing the various game data formats used and any debug information left in the game, you can check it out below: Krome Studios Merkury Engine For more information on the Merkury engine by Krome Studios check out this post. iOS and N-Gage VersionThere was a very simple version released in 2008 for both iOS and N-Gage, developed by Finnish based developer Universomo, it is neither the LucasArts Ronin engine game nor the Krome Studio game, instead it is a unique experience which has very simple swipe-based controls and only takes about an hour and a half to complete.The Zeno Application FrameworkTo find out more about Zed we need to take a look at the underlying foundation - the Zeno Application Framework. As ILM are very secretive, very few details or screenshots are available online about Zeno so some of the information may be incorrect.Essentially Zeno is a powerful digital content creation pipeline used for managing everything from 3D models and lighting to animation and physics simulations and it is proprietary software used in-house at ILM.The InterfaceThe Interface for Zeno is heavily inspired by Maya with a shelf at the top and outlines for hierarchical views.Based on the screenshot we can presume the following shelves are available: Shelf Name Description default Presumably basic tools? Alembic ILM Alembic is a computer graphics interchange file format developed jointly by Industrial Light & Magic (ILM) and Sony Pictures Imageworks. It was created to efficiently store and share complex animated geometry and visual effects data across different software platforms and production facilities Dynamics Particles and other simulations? Facial Capture Cari Facial animation tools? ILM_TFM Transformation tools? ILM_anim Animation tools ILM_asset Asset modification including Plume ILM_comp Compositing tools (integration with Comptime?) ILM_crdev Creature Development tools? ILM_crdev_retired Old Creature Development tools? ILM_dm deformation tools? ILM_dms deformation and mesh simulation tools? ILM_face Cari Facial animation tools? ILM_Mesh Mesh editing tools ILM_frac Fracturing tools? Initial DevelopmentIndustrial Light & Magic (ILM) began developing Zeno in the late 1990s (~1997) as an in-house content creation framework to unify their visual effects pipeline 12.Early work on the new ILM pipeline had been in development since the pre-production of Star Wars: Episode I in 1998 and 1999, such as the camera tracking software for the pod race which later became part of Zeno called MARS and then the new the camera projection mapping software Zenviro 13.However, the actual development of the new, standardised toolset took place in the previous two years, triggered by the planned move to new premises at the Presidio campus and then a further push for the War of the Worlds movie 13.In an interview in the July 2005 issue of Computer Graphics World (CGW) Cliff Plumer Chief Technology Officer discusses the motivation for the new Zeno toolset: Our first goal was to manage large scenes, It was driven by the pod race in Star Wars: Episode I. Thus, at its core, Zeno manages scene data. The old pipeline used the old Softimage scene file, Building our own gave us control.Pre-Zeno Software at ILMThe Zeno software was actually the third pipeline software developed in-house by ILM, the first was based on SGI Inventor. The second was based on Softimage scene files and was primarily designed to produce living creatures rather than entire movies 13.There were also command line tools such as IShade, Repo, iComp and something called “CBal” used at ILM over 30 years ago in 1995 based on this new employee handbook:These were most likely the precursors for Zeno but some of them may have still been in use.Also ILM has a Maya-based character building system known as Blockparty due to it feeling like creating characters out of building blocks, but not sure it it was integrated with Zeno 14.The Zeno Scene Graph (Shot files)Zeno handles the entire collection of assets, animations, lighting setups, and other data that make up a scene, offering tools like a timeline (to manage animation over time), a scene graph (a hierarchical structure organizing scene elements), and a curve editor (for controlling animation curves and other parameter changes) 13.Under the hood, Zeno’s core was a proprietary scene-graph file format developed and controlled by ILM, that allowed complex scenes to be broken into many referenced files while remaining seamlessly connected.Edits could be layered non-destructively: for instance, a technical director could paint a bullet hole decal onto a model in their own layer, and later if a texture artist updated the base texture, the bullet hole would still remain applied on top 8.Zeno Visual Effect Shot File format (.zshot)Based on the one screenshot of Zeno we have, it looks like the scene graph file format had a .zshot file extension, presumably standing for Zeno Shot (as in a camera ‘shot’) but this is just based on the toolbar and may be incorrect.These files represent the complex scene graph data and networks of operators, data objects (called Oids), and relationships that make up a shot in the VFX pipeline 12.Zeno manages massive amounts of scene data and allows artists from various disciplines to work and exchange data collaboratively.The .zshot files store arbitrary units of a scene, enabling work to be split among artists and passed along efficiently, while maintaining dependencies and non-destructive overrides in versioned files.Simulation engineILM also collaborated with Stanford’s Ron Fedkiw to build a unified simulation engine in Zeno for hair, cloth, skin and fluids 8. In 2008 he won an Academy Award for Technical Achievement for the fluid simulation system 15.Zeno Hair simulation in actionYou can see the animatronic Scrunt being made in the youtube video below for the movie Lady in the Water, this required compositing for the grass-like hairs on the creature, Zeno’s existing hair simulation was used for the task.In the September 2006 issue of Animation Magazine there is an interview with the Digital Production Supervisor Doug Smythe about the work ILM did on Lady in the Water in which he states that he modified the hair simulation system in Zeno to output blades of grass rather than hairs for the “Scrunt” creature.Allowing him to define hundreds of specific “guide hairs” in the Zeno simulation that would be used to generate the tens of thousands of simulated grass-like hairs on the scrunt. Instead of outputting a hair cylinder or curve, Zeno would output polygon meshes that were shaped like blades of grass.These would be placed on the original model which was built in Autodesk Maya along with the face shapes built using Zeno’s Cart facial animation system. Zeno was also used to place lights in the scene and the shot was finally rendered out in Pixar’s RenderMan.Animators then added details such as twigs and branches on the Scrunt’s face using Pixologic’s Zbrush along with adding additional woody material around its nose.Plume - GPU fluid/fire dynamics simulationILM Plume module was added to Zeno roughly around 2009 for The Last Airbender TV Show, Plume is an internal GPU-based fluid simulation tool developed in-house by ILM specifically for high-performance visual effects work. Plume was showcased in technical VFX presentations and is designed to handle complex fluid dynamics simulations, such as smoke, fire, and gaseous effects, using efficient GPU processing (NVIDIA’s CUDA) to enable rapid iteration, preview, and rendering.Plume was implemented as a ray-marching renderer, where rays are cast from the camera into a 3D scene and iteratively advanced (marched) step-by-step until they reach the surface of an object.Plume has been used in many blockbuster films, earning a 2018 Sci-Tech Award, although nowadays it has mostly been replaced with industry standard software such as Houdini 12.Module systemZeno was envisioned as a fundamental VFX toolset – essentially an extensible framework with a scene graph, timeline, curve editor, and module system – all centered on efficient workflow 8.Modules included: Match-moving/Camera Tracking - M.A.R.S Camera projection - Zenviro Facial animation - Caricature (Cari) Lighting - Lux Sculpting - Isculpt 16 Animation - Zeno Poseur 16 Painting - Viewpaint integration with Zeno? For more information about check out Viewpaint: ILM’s secret weapon on Jurassic Park from vfxblog Particles - Plume RotoscopingAccording to Chris Evans who used to work at ILM, Zeno had Geodesic Voxel Binding before it was introduced in Maya 2015, which used mesh normals to eliminate crosstalk between manifold parts like fingers 17.Zeno Commodore?In the Electronic art and animation catalog from SIGGRAPH 2004 it mentions a tool called Zeno Commodore, but not sure what it is 16.ILM Dynamic RiggingILM’s Dynamic Rigging system, often associated with their BlockParty tool, is an advanced rigging framework designed to streamline the creation of rigged characters and assets for animation and visual effects. It was created by Jason Smith for the Transformers movie 18.This system allows artists to build detailed, flexible, and reusable rigs that can animate complex creatures as well as mechanical objects like spaceships.Key features of ILM’s Dynamic Rigging include:\t*\tA comprehensive connection framework that integrates various rigging components consistently.\t*\tA novel graphical user interface and volumetric rig transfer to improve workflow speed and artist productivity.\t*\tThe ability to reuse rig components and focus more on the artistic aspects of rigging rather than technical challenges.\t*\tSupport for both organic and mechanical rigging needs, treating animateable objects with the same pipeline workflow whether they are living creatures or metallic spaceships.This rigging system has been recognized for its innovation, earning ILM Scientific and Technical Awards for facilitating rich, complex rigs to be developed more efficiently, supporting the production of high-quality creature animation and effects in major films.Zeno Tentacle PluginFor the film Pirates of the Caribbean Dead Man’s Chest, David Meny designed a Zeno plug-in that allowed animators and technical directors to randomize sucker placement based on a library of sucker variations. The sucker variations were modelled by Frank Gravatt, 16 variations in total allowing a lot of visual variation really quickly thanks to Zeno’s modular system 14.MARS - Camera Tracking System moduleOne of the first applications built on the Zeno framework was ILM’s new camera tracking system (codenamed MARS), which successfully leveraged Zeno’s scene graph to integrate 3D matchmoving data with film plates 8.This module was so effective it earned an Academy Scientific & Technical Award. Throughout the early 2000s, ILM gradually replaced dozens of older, disconnected tools with new Zeno-based modules 8.Zenviro - camera projection moduleThe camera projection module in Zeno was called Zenviro and was used to great effect in the War of the Worlds (2005), as it allowed ILM compositors to project 2D photographic plates of buildings onto simple 3D geometry to animate destruction effects. They could add cracks, falling debris, and damage progression directly in Zeno 19.In the July 2005 issue of CGW compositing supervisor Marshall Krasser discusses the destruction sequence creation for War of the Worlds: The sequence was crafted with a mixture of effects-from particle simulations for the cracking pavement to practical elements-often with the help of Zenviro, the camera projection module in Zeno. You see a pickup truck that gets rotated around. We lifted it out of the plate, took it into the 3D realm, projected it onto 3D geometry in Zenviro, animated the geometry to rotate it, and composited it back into the plate. 8Alan Trombla was one of the brains behind the Zenviro camera project module at ILM who then went on to found Tweak Software known for its RV software that was also in use by ILM.Caricature (Cari) - Facial Animation SystemFor Dragonheart (1996), ILM created a specialized in-house tool called Caricature (nicknamed “Cari”) to enable animators to work interactively on Draco’s face, with sliders and real-time feedback.Before Cari, facial animation at ILM was handled by hand-writing text commands in files to load shapes over time - effectively like stop-motion animation via scripts.Animators used body motion data from Softimage (the conventional pipeline) then opened that into Caricature just for the facial animation part. Caricature allowed animators to hide the rest of the dragon model and focus solely on facial expressions, making high-iteration tweaking possible (e.g. combining phoneme shapes, sneers, eyebrow movement).Later, Caricature added model correctives, a system allowing artists to fix imperfections in geometry (like a “3D-Photoshop” for sculpted surfaces) inline.Integration of Cari into ZenoCari was later integrated into Zeno as stated on the official Lucasfilm website ILM’s Dragonheart Crew Looks Back - Lucasfilm.com “the techniques in Caricature were integrated into ILM’s current Zeno system in the 2000s.”Cary Phillips was awarded a 1998 Academy Technical Achievement Award for the development of Caricature.Lux - Zeno’s interactive lighting toolZeno’s interactive lighting tool Lux enabled artists to place and adjust lights in a true 3D context while seeing immediate feedback 19.Lux is true 3D lighting for particles and creatures that brings match-moving, interactive lighting, and texture painting together. The shots were later rendered with Pixar’s RenderMan and Mental Images’ Mental Ray 8.Technical Directors in Zeno adjusted the direction and flicker of the Tripods’ headlights during lighting, and applied procedural 2D noise to create an “organic” glow in the alien windows - all without leaving the lighting interface 19.In the book Cinefex from 2006 Tom Fejes is creditied as “setting up” the Lux tool, not sure if that means he was the creator of Lux or if he was the one that set it up for the Pirates movie that the book covers 14.CloneCam - Performance Capture SystemILM animators created about 60 minutes of cinematics for the game Star Wars The Force Unleashed, using their CloneCam performance capture system originally developed for Pirates of the Caribbean 11.Integrations with third party softwareOne of the main benefits of Zeno was the integrations with industry standard software, rather than a collection of siloed programs for modeling, animation, rendering, etc., Zeno could load whatever tools an artist needed into one unified interface 8.Zeno was build from the ground up to be modular, with modules easily written in Python for tasks such as converting between 3D file formats or integrating 3rd party software tools seamlessly 8.Integration with MayaZeno was designed with live links to Maya and Photoshop – an artist could copy and paste data or edits between Maya and Zeno in real time – and its UI was made to resemble Maya’s Outliner to ease adoption 8.Curt Miyashiro, digital production supervisor has the following to say about the benefits of Zeno’s integration with Maya 8: Modelers built the tripods and the aliens in Maya using subdivision surfaces. The animators worked in Maya and then transferred the animation to Zeno. Before, the animation was cached; now TDs can tweak the animation in Zeno. Before if we had wanted to change the headlights on the tripod, we would have had to go back to the animators or go into Maya. With this film we could change the direction of the headlights in Zeno while we were working on lighting the shot.Integration with Compositing toolsZeno was used in ILM along with to their usual compositing tools which included 8: Apple’s Shake ILM’s Saber (based on Autodesk Media and Entertainment’s Inferno) ILM’s CompTime - In House compositorThen final renders from RenderMan or Mental Ray could round-trip back into Zeno’s compositing module for finishing 8.Integration with CompTimeZeno has first class support for woroking the the proprietary compositor developed in-house at ILM known as CompTime.In the July 2002 issue of Linux Journel Technical Directory Robert Weaver notes that ILM’s compositing software, CompTime was ported over to Linux and the plugins for the compositor were all written in Python 2.The Success of ZenoThe success of zeno can not be understanted, by the mid-2000s, Zeno had become the heart of ILM’s pipeline and by 2004, Zeno had matured enough that ILM could fully retire its old pipeline 8.Then by 2006–2007, Pirates of the Caribbean: Dead Man’s Chest and At World’s End benefited from Zeno; the CGI character Davy Jones was one high-profile creation that benefited from Zeno 12. Seven years in the making, Zeno, ILM’s new tool set, has redefined the studio’s pipeline, opened the production process to all the artists on the crew, and positioned the studio to create future forms of entertainment 8Version History of ZenoIt would be interesting to find out the version history of Zeno, all we know about so far is that in 2011 Zeno reached major version 3.0, having experienced a major re-tooling of its interface around the time of Transformers: Dark of the Moon 12.We also know that in September 2013 the current version of Zeno was 3.9.7.It is unclear if Zeno is still in use at ILM today and what version number it has reached, or if it has undergone any major re-writes.2013 Academy SciTech AwardsZeno was so successful The developers Florian Kainz, Jeffery Yost, Philip Hubbard and Jim Hourihan were honoured for the architecture and development of the Zeno application framework in the 2013 Academy SciTech Awards 12.Zviz - The future of Zeno?ILM developed a new pre-visualization tool called Zviz in 2006, built on Zeno and Zed, which aimed to allow directors to access the entire production pipeline in real time, with photogrammetry, live camera tracking, and interactive scene assembly 20.Even although both are real-time, Zviz differs from Zed in the target audience for the interface, Zed targets game developers but Zviz targets directors.It was intended to be used for LucasArts for cut scene authoring in games but it is not clear whether this actually happened.Zviz had three distinct modes: Building the set Animation EditingAlthough it has a less technical audience and didn’t have all the tools such as a compositor for example, since it was built on top of Zeno you could use all the existing Zeno integrations such as CompTime.One cool feature of Zvis was, it supported creating 2D sketches as placeholder assets that can be animatable in 3D 20!ILM’s Zviz previsualization tool was actively used and developed around the early 2010s, with internal users including Lucas Animation and ILM visual effects supervisors. However, over time, previs tools evolved strongly toward using game engines like Unreal Engine, which offered greater flexibility, accessibility, and real-time realism.References Game Developer Magazine March 2007 ↩ ↩2 Industrial Light and Magic ↩ ↩2 Game Films - Computer Graphics World ↩ ↩2 3D World Magazine September 2005 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 GDC Vault - LucasArts and ILM: a Case Study of the Convergence of Games and Film ↩ The Art and Making of Star Wars: The Force Unleashed – Insight Editions (2008), cited via Wookieepedia ↩ ↩2 ↩3 ↩4 Star Wars 1313 – Wikipedia ↩ ↩2 Acts of War – Computer Graphics World (July 2005) ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 The Art and Making of Star Wars The Force Unleashed (2008) ↩ Star Wars: The Force Unleashed – Wikipedia (Development section) ↩ Star Wars: The Force Unleashed – Wookieepedia (Behind the Scenes) ↩ ↩2 ILM’s Scientific Solutions – fxguide (Feb 2014) ↩ ↩2 ↩3 ↩4 ↩5 ↩6 War of the Worlds - Retro Articles - DIGITAL PRODUCTION ↩ ↩2 ↩3 ↩4 Cinefex (2006) ↩ ↩2 ↩3 Professor Ron Fedkiw shares Academy Award for software to digitize destruction - Stanford University School of Engineering ↩ Electronic art and animation catalog : SIGGRAPH (Conference) (2004) ↩ ↩2 ↩3 Stumbling Toward ‘Awesomeness’Geodesic Voxel Binding in Maya 2015 - Stumbling Toward ‘Awesomeness’ ↩ The Rookies - Rookie Awards 2020 Judge - Jason Smith ↩ Lucasfilm CTO Cliff Plumer Talks Technology - VFXWorld ↩ ↩2 ↩3 Zviz: ILM Goes Interactive with Previs - Animation World Network ↩ ↩2 ", "excerpt": "Introduction to Zeno and the Zed Game Editor Back in 2004/2005 engineers at LucasArts were on a mission to find the best technology for the new “next-generation” consoles (Xbox 360, PS3), they travelled the world assessing various middleware and proprietary game engines 1. Unbeknownst to them, they would actually find...", "tags": ["middleware","gameengines"], "image": "/public/generated/placeholders/lucasarts-zino-and-zed.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "MAME Source Code", "url": "/mame-source-code", "content": "MAME Repository StructureA guide to every top-level directory and file in this repository.Glossary of Key TermsIf you are new to MAME’s source tree, this glossary covers the acronyms used throughout the page. AsmJIT - A lightweight library for generating machine code at runtime, used for JIT compilation of emulated CPUs directly into host machine instructions. BDF - Bitmap Distribution Format. A plain-text font format that stores glyph bitmaps. Used by MAME’s built-in UI renderer to draw on-screen text without depending on host OS font APIs. BGFX - A cross-platform rendering abstraction library that sits on top of Direct3D, OpenGL, Metal, and Vulkan. MAME uses it to implement post-processing effects such as scanlines, shadow masks, and bloom in a renderer-agnostic way. Catch2 - A header-only C++ unit testing framework. MAME’s tests/ suite is written against it. CHD - Compressed Hunks of Data. MAME’s disk image format, designed to efficiently store large hard drive and CD-ROM images with per-hunk compression and SHA1 verification. Managed by the chdman command-line tool. Doxygen - A documentation generator that reads specially formatted comments in C/C++ source code and produces browsable HTML or other API reference formats. Genie - A Lua-based build system generator, similar to CMake or Premake. MAME uses it to produce platform-specific Makefiles and IDE project files from a single set of Lua scripts kept in scripts/. GLSL - OpenGL Shading Language. A C-like language for writing GPU shader programs targeting the OpenGL/Vulkan graphics pipeline. HLSL - High Level Shading Language. Microsoft’s shader language for the DirectX/Direct3D graphics pipeline, used by MAME’s legacy Windows renderer. JEDEC - A semiconductor industry standard that defines, among other things, the binary format used to store the fuse-map contents of PLD/GAL chips. jedutil converts between JEDEC files and other internal representations. JIT - Just-In-Time compilation. A technique where emulated CPU instructions are translated and compiled into host machine code at runtime rather than interpreted one-by-one, giving a large speed boost. MAME uses AsmJIT for this. Lua - A lightweight, embeddable scripting language. MAME embeds a Lua interpreter to power its plugin system, the interactive console, and the Genie build system. NTSC - National Television System Committee. The analog television broadcast standard used in North America and Japan. MAME’s CRT shaders can simulate NTSC signal artefacts such as colour bleeding and dot crawl for authentic display output. OSD - OS-Dependent layer. The abstraction layer in MAME (src/osd/) that isolates all platform-specific code, including windowing, audio output, and input handling, so the rest of the emulator is portable. ROM - Read-Only Memory. In the MAME context, a dump of the binary data stored on the chips inside an arcade PCB or console cartridge. MAME loads these dumps to run the original software. SDL - Simple DirectMedia Layer. A cross-platform library providing a unified API for window creation, input, audio, and 2D rendering. MAME’s non-Windows OSD backends are largely built on SDL. Solenoid - An electromechanical coil that produces a strong linear push when energised. In pinball machines they drive flippers, pop bumpers, slingshots, ball launchers, and the cabinet knocker. Because solenoid sounds come from physical mechanisms rather than audio circuitry, they cannot be reconstructed from circuit simulation, so MAME uses recorded WAV samples for them. Sphinx - A Python-based documentation build tool that converts reStructuredText (.rst) source files into HTML, PDF, and other formats. MAME’s docs/ site is built with Sphinx. XSLT - Extensible Stylesheet Language Transformations. A language for transforming XML documents into other XML, HTML, or plain-text documents. MAME uses XSLT to render its XML layout files into HTML for the web interface. Z80 - The Zilog Z80, an 8-bit CPU from 1976 that powered a huge number of arcade games and home computers. src/zexall/ runs the Z80 Exerciser against MAME’s Z80 core to verify correctness.DirectoriesThe top-level directories in the MAME source tree are listed below, with a short summary of what each one contains. Directory Summary 3rdparty/ Vendored third-party libraries (rendering, compression, scripting, testing, build system) android-project/ Gradle project for building MAME on Android artwork/ CRT display effect textures for the BGFX renderer attic/ Retired source files kept as historical documentation and research references benchmarks/ Standalone C++ micro-benchmarks for core components bgfx/ Shader files and post-processing effect chain configs for the BGFX renderer build/ Compiler output directory (not tracked by git) ctrlr/ XML input configs for third-party arcade control panels docs/ Source files for the MAME documentation website doxygen/ Config and templates for Doxygen API reference generation hash/ Software list XMLs describing ROMs for every emulated system hlsl/ DirectX HLSL shaders for the legacy Windows renderer ini/ Example and preset INI configuration files keymaps/ Key remapping files for non-QWERTY host keyboards language/ UI string translation files for all supported locales plugins/ Lua plugins extending MAME at runtime projects/ Sparse top-level project metadata for the build system regtests/ Regression tests for chdman and jedutil roms/ Placeholder directory for development ROMs (not included in repo) samples/ Audio samples for hardware that is difficult to emulate accurately scripts/ Genie/Lua build system scripts src/ All MAME C++ source code tests/ Unit tests using Catch2 web/ Assets and front-end panels for MAME’s built-in HTTP server FilesThe most important top-level files are listed below, along with a short description of their role. File Summary makefile Primary build entry point; orchestrates the Genie-based build system dist.mak Makefile fragment for producing release archives and installers uismall.bdf BDF bitmap font used by MAME’s built-in UI renderer COPYING GNU General Public License v2 README.md Project overview and quick-start build instructions CONTRIBUTING.md Brief contributor guidelines .editorconfig Editor indentation, line-ending, and charset settings .gitattributes Git line-ending normalisation and diff behaviour .gitignore Files and directories excluded from version control .travis.yml Legacy Travis CI configuration for automated build checks .github/ GitHub issue and pull request templates RendererDisplay Effect Artwork (artwork/)CRT and display effect artwork assets used by the BGFX renderer. Contains PNG texture files for shadow masks, aperture grilles, and scanline overlays, plus a bgfx/ subdirectory for additional BGFX-specific artwork.BGFX Renderer Assets (bgfx/)Configuration and shader files for the BGFX-based renderer. Contains post-processing effect chains (chains/), GLSL/HLSL/Metal shaders (shaders/), and screen effect presets (effects/).DirectX HLSL Shaders (hlsl/)DirectX HLSL shader files for the Direct3D renderer (Windows). These are the equivalent of the BGFX shaders but for the legacy D3D pipeline. Includes effects for bloom, scanlines, phosphor, NTSC simulation, and more.DocumentationDocumentation Website (docs/)Source files for the MAME documentation website. Built with Sphinx; contains reStructuredText source (source/), themes, and a Makefile to generate HTML output.API Reference Generator (doxygen/)Configuration and templates for generating Doxygen API documentation from the C++ source. Includes doxygen.config, custom HTML header/footer, and a stylesheet.Games, Software and other AssetsSoftware Lists (hash/)XML databases that describe every known software item (cartridges, floppy disks, cassettes, CD-ROMs, etc.) for every system MAME emulates. Licensed under CC0-1.0 (public domain). Contains 759 XML files, 5 legacy .hsi files, and a README - totalling around 141,000 individual software entries.PurposeSoftware lists serve two roles: ROM verification - MAME checks loaded media against the CRC32 and SHA1 hashes recorded here to confirm the image is a known-good dump. Documentation - Each entry records the title, publisher, year, serial number, region compatibility, PCB type, and other metadata that would otherwise be lost.File NamingEach file is named <system>[_<mediatype>].xml. Systems with only one primary media type (e.g. nes.xml, snes.xml, gameboy.xml) have no suffix. Systems that shipped software on multiple media get one file per type: Suffix Media type Count _flop Floppy disk 125 _cart Cartridge 101 _cass Cassette tape 86 _rom ROM (chip/EPROM dump) 26 _hdd Hard disk image 20 _cdrom / _cd CD-ROM 13 _card Memory/flash card 6 _quik Quickload binary 8 _snap Snapshot 5 For example, the Atari 800 has a800.xml (cartridges), a800_flop.xml (floppy disks), and a800_cass.xml (cassettes) as three separate lists.XML StructureEach file has a <softwarelist> root element. Every software item is a <software> entry:<softwarelist name=\"nes\" description=\"Nintendo Entertainment System cartridges\"> <software name=\"mario\" cloneof=\"marioeu\"> <description>Mario Bros. (Europe, rev. A)</description> <year>1986</year> <publisher>Nintendo</publisher> <info name=\"serial\" value=\"NES-MA-EEC\"/> <part name=\"cart\" interface=\"nes_cart\"> <feature name=\"slot\" value=\"nrom\"/> <feature name=\"pcb\" value=\"NES-NROM-128\"/> <dataarea name=\"prg\" size=\"32768\"> <rom name=\"pal-ma-0 prg\" size=\"16384\" crc=\"2aec46c2\" sha1=\"f5d609720bc60bcb02f434d41149ae68e9f6b899\" offset=\"0\"/> </dataarea> </part> </software></softwarelist>Key attributes and elements: Element / Attribute Purpose <software name> Short identifier used on the MAME command line cloneof Parent entry - used for regional variants, revisions, alternate dumps supported Absent = working; \"partial\" = known issues; \"no\" = does not run <info> Freeform metadata: serial number, release date, alt title, programmer, etc. <sharedfeat> Shared feature across all parts, e.g. compatibility=\"PAL\" <notes> Free-text notes, often explaining why an entry is unsupported <part name interface> A loadable media slot; interface must match the slot the machine exposes <feature> Slot/PCB/mapper configuration (e.g. NES mapper type, mirroring mode) <dataarea>/<rom> The actual binary region: filename, size, CRC32, SHA1, load offset .hsi FilesFive files use an older <hashfile> format instead of <softwarelist>. These are simpler CRC32-keyed lookup tables with no part/dataarea structure, used for the Atari 5200 and a few other systems where only basic hash identification is needed:<hashfile> <hash crc32=\"4019ecec\" name=\"Astro Chase (Parker Brothers)\"> <year>1982</year> <manufacturer>Parker Brothers</manufacturer> <extrainfo>A13MIRRORING</extrainfo> </hash></hashfile>ScaleThe 759 XML files collectively document software for systems ranging from 1970s mainframes and microcomputers through to 2000s consoles, covering arcade conversions, productivity software, games, operating system disks, diagnostic ROMs, and prototype releases. Many entries include multiple regional variants and revisions as cloneof children of a parent entry.Lua Plugin System (plugins/)Lua plugins that extend MAME’s functionality at runtime. All code is BSD-3-Clause licensed unless noted per file.How the plugin system worksWhen MAME starts, boot.lua is executed first. It reads the pluginspath option, sets up Lua’s package.path, then iterates manager.plugins and calls require(name) followed by plugin.startplugin() for every plugin with \"start\": \"true\" in its manifest. Plugins that are off by default must be enabled in plugin.ini or via -plugin <name> on the command line.plugin.json ManifestEvery entry (plugin or library) declares itself with a JSON manifest validated against plugin.schema. The required fields are: Field Values Purpose name alphanumeric + underscore Identifier used by require() and the -plugin flag description string Human-readable label version string Semver string author string Author name or email type \"plugin\" or \"library\" Libraries are shared helpers, not started directly start \"true\" / \"false\" Whether MAME auto-starts the plugin (plugins only) boot.lua - The plugin system entry point. Sets up internationalisation helpers (_(), N_()), builds package.path from pluginspath, then loads and starts all enabled plugins.Plugins (type “plugin”)The built-in plugins are listed below, including whether they start automatically and who maintains them. Plugin Default on Author Purpose autofire no Jack Li Simulates held button presses at a configurable rate, mapped to any input cheat no Carl Loads and applies cheat codes from JSON, XML, or simple text files cheatfind no Carl Lua console library for scanning emulated memory to discover new cheat values console no Carl Interactive Lua REPL accessible while a game is running, with tab-completion and persistent history data yes Carl Aggregates data from external .dat files (history, mameinfo, marp scores, etc.) and surfaces them in the UI info panel discord no Carl Updates Discord Rich Presence with the currently running machine name and play time dummy no Miodrag Milanovic Minimal skeleton used as a reference when writing new plugins gdbstub no Carl Exposes emulated CPUs over a GDB remote serial protocol socket so a real GDB debugger can attach and step through emulated code hiscore no borgar@borgar.net Saves and restores high score RAM using hiscore.dat definitions, replicating the behaviour of older MAME builds (CC0 licensed) inputmacro no Vas Crabb Records and replays sequences of inputs, bound to a configurable trigger key layout yes Carl Runs per-machine Lua layout scripts embedded in .lay files, providing reset and frame callbacks for dynamic artwork offscreenreload no Vas Crabb Sends a configurable input sequence when the crosshair moves off-screen, for light-gun games that require an off-screen shot to reload portname no Carl Overrides the display names of I/O port fields using per-game JSON data files timecode no Vas Crabb Writes a timestamped log of emulated frame counts to a file, used for video capture synchronisation timer no Vas Crabb Tracks and displays cumulative play time for each machine across sessions vector no Ryan Holtz Demonstration plugin that hooks into the vector renderer’s frame-begin/end and line-draw callbacks Libraries (type “library”)The shared plugin libraries are listed below. Library Author Purpose commonui Vas Crabb Shared UI helper functions used by multiple plugins json David Kolf Pure-Lua JSON encoder/decoder (v2.5.0) xml Gavin Kistner Pure-Lua SAX-style XML parser (SLAXML v0.8) data/ Plugin InternalsThe data plugin is the most complex. It ships with sub-scripts for each data source: Script Data source data_history.lua history.dat - arcade game history data_mameinfo.lua mameinfo.dat - driver technical notes data_messinfo.lua messinfo.dat - console/computer driver notes data_sysinfo.lua sysinfo.dat - system information data_hiscore.lua hiscore.dat - high score records data_marp.lua MARP score data data_story.lua story.dat - game storylines data_command.lua command.dat - move lists for fighting games data_gameinit.lua gameinit.dat - game initialisation hints Each sub-script exposes a check(setname) function that returns a heading if it supports that machine, and a get() function that returns the content. database.lua and load_dat.lua provide shared .dat file parsing utilities.ROM Storage (roms/)The default location MAME looks for ROM sets and hard disk images at runtime. The directory ships with a single file:dir.txt - a plain-text placeholder (Place ROM directories here) whose only purpose is to ensure the empty directory is tracked by git, since git does not version-track empty directories.No actual ROM files are included in the repository - distributing them would violate copyright.How MAME resolves ROMsWhen you run a machine, MAME searches every directory listed in rompath (default: roms) for a match. It accepts two layouts inside each path: ZIP archive - roms/<machinename>.zip containing the individual ROM chip dump files. Subdirectory - roms/<machinename>/ containing the same files unpacked.CHD disk images (.chd) follow the same pattern but are typically stored in a subdirectory named after the machine: roms/<machinename>/<diskname>.chd.Configuring additional pathsThe rompath option accepts multiple semicolon-separated directories, so you can keep ROMs spread across different locations without moving them:mame <machine> -rompath /path/to/roms;/another/romsetThe option also has the aliases -rp, -biospath, and -bp for historical compatibility. The default value (roms) is relative to the directory MAME is launched from, so the repo’s roms/ folder is used automatically when running a development build from the repo root.Parent/clone setsMany arcade games share ROM chips with a parent set (e.g. regional variants or revisions). MAME searches rompath for both the clone’s ZIP and the parent’s ZIP, merging them as needed. You do not need to duplicate shared files.Audio Samples (samples/)Real-world audio recordings used by MAME to reproduce mechanical sounds for hardware that is impractical to emulate synthetically. Licensed under CC0-1.0 (public domain - recorded by team members and contributors from real hardware).Like roms/, this directory ships with a dir.txt placeholder (Place samples directories here) so git tracks the otherwise-empty directory. No additional sample sets are bundled beyond floppy/.Why samples existSome sounds - motor whirr, head seek clicks, mechanical latches - are produced by physical mechanisms rather than audio circuitry, making them impossible to reconstruct from the circuit simulation alone. Drivers that need them declare a list of required sample names; if the files are absent MAME mutes that sound channel silently rather than erroring out.floppy/ - The only sample set shipped in the repo. Contains 22 WAV files (44100 Hz, mono) recorded from two real drives: 3.5” samples - recorded from a Sony MPF420-1 drive. 5.25” samples - recorded from a Chinon FZ502 drive.The files are split into three categories: Category Files Description Spin *_spin_start_empty/loaded, *_spin_empty/loaded, *_spin_end Motor spinning up (with/without disk), steady spin, and spin-down Step *_step_1_1 A single head step pulse Seek *_seek_2ms, *_seek_6ms, *_seek_12ms, *_seek_20ms Composite seek sounds at four speeds (2 ms and 5.25”/3.5” seek_2ms are synthesised; all others are real recordings) The prefix 35_ denotes 3.5” and 525_ denotes 5.25”. Floppy sound is opt-in per driver - a driver must call enable_sound(true) on its floppy_sound_device; if the sample files are missing the device silently disables itself.Configuring additional pathsLike rompath, the samplepath option (alias -sp) accepts semicolon-separated directories and defaults to samples relative to the MAME launch directory:mame <machine> -samplepath /path/to/samples;/another/samplesAdditional community sample packs (covering gun sounds, pinball solenoids, coin mechs, etc.) can be dropped into any directory on this path and MAME will find them automatically.Main C++ Source Code (src/)All MAME C++ source code, split across eight subdirectories.src/emu/The core emulation engine - the lowest-level layer that everything else builds on. Key areas:Device Systemdevice.cpp/h defines the base class for every piece of emulated hardware. All chips, boards, and peripherals inherit from it. The di*.cpp/h files are device interfaces - optional capability mixins a device can inherit to declare what it can do: Interface Purpose diexec CPU execution and scheduling dimemory Memory map declaration disound Audio output divideo Video output diimage Media image attachment (floppy, cartridge, etc.) dirtc Real-time clock diserial Serial I/O dinvram Non-volatile RAM persistence distate CPU register state (for debugger) didisasm Disassembly (for debugger) Memory Subsystememumem*.cpp/h - A heavily templated system for mapping address spaces. Split across many files for read/write handlers at 8/16/32/64-bit widths. Supports mirroring, banking, RAM/ROM overlays, and per-access-width handlers.Schedulerschedule.cpp - Co-operative timeslicing of all CPU cores and timed devices. Every device schedules callbacks at precise attotime timestamps (attosecond resolution).Renderingrender.cpp, rendlay.cpp - The display composition engine. rendlay.cpp parses .LAY artwork layout XML files and composites game screens, bezels, and overlays into a final output image.Inputioport.cpp, input.cpp, inputdev.cpp - The I/O port system maps physical inputs (keyboard, joystick, mouse) through configurable bindings to emulated inputs (DIP switches, coin slots, joystick directions, buttons).Audiosound.cpp, speaker.cpp - Mixes all sound streams from all active sound devices into the final output buffer. speaker.cpp defines the speaker device that anchors streams to screen positions.Save Statessave.cpp - Serialises the complete machine state to a file by registering every stateful variable at startup.ROM Loadingromload.cpp - Finds, loads, CRC-verifies, and maps ROM regions from the rompath into the address space.Graphicstilemap.cpp, drawgfx.cpp - Generic tile-map engine and sprite/tile pixel-drawing primitives used by hundreds of drivers.SubdirectoriesThe main subdirectories under src/emu/ are listed below. debug/ - The integrated debugger: CPU stepping, breakpoints (dvbpoints), watchpoints (dvwpoints), expression evaluator (express), memory viewer (dvmemory), disassembly viewer (dvdisasm), register viewer (dvstate). ui/ - The in-game overlay UI (the interface you reach by pressing Tab): main menu, game selection, input mapping, options screens, audio effects, file manager, cheat options, system info, and more (~80 source files). video/ - Video support utilities: generic.cpp for common video patterns, resnet.cpp for resistor-network colour decoding, rgbutil.cpp for fast SIMD colour math. audio_effects/ - DSP audio effects pipeline: compressor, EQ, filters, reverb. layout/ - Built-in .lay artwork layout files compiled directly into the binary. drivers/ - Stub that #includes the full driver list.src/devices/Every piece of emulated hardware, each in its own file. Split into six subdirectories:cpu/ (211 CPU families)Every CPU core MAME emulates, one subdirectory per architecture. Includes: z80, m68000, arm/arm7, mips, x86, 6502, avr8, powerpc, sparc, sh, v60, tms9900, pdp1, and over 200 more. Each core implements the diexec and distate interfaces and optionally didisasm.sound/ (371 chips)Individual sound chip implementations: ay8910, ym2151, ym2612, pokey, sn76496, okim6242, c140, qsound, aica, and hundreds more - covering every era from 1970s beeper chips to 1990s wavetable synthesisers.machine/ (~1,120 files)Support logic chips: timers (6522via, 8253pit), UARTs (ins8250, z80scc), FDC controllers (wd1770, upd765), DMA (am9517a), interrupt controllers, memory mappers, custom ASICs, and miscellaneous glue logic.video/ (330 files)Dedicated video chips: PPUs, VDPs, sprite generators, palette chips, and line buffers. Examples: 315_5124 (Sega Master System VDP), ppu2c0x (NES PPU), tms9928a, mc6845 (CRTC), k052109 (Konami tile layer).bus/ (184 expansion bus families)Cartridge slots, expansion port connectors, and I/O buses. Each subdirectory models a specific bus standard and the cards/cartridges that plug into it: a2bus (Apple II), nes (NES cartridge), megadrive, snes, amiga, isa, pci, and many more.imagedev/Media image devices: floppy (with the floppy sound system), cassette, cartrom, harddriv, cdromimg, magtape, memcard, midiin/midiout, printer, snapquik (snapshot/quickload), picture, and others.src/frontend/mame/The MAME-specific application shell that sits on top of the engine. It owns the command-line interface, the Lua scripting engine, and the full game-selection UI.Core FilesThe main frontend files are listed below. mame.cpp/h - The top-level mame_machine_manager object; application entry point. clifront.cpp - Processes all command-line operations: -listxml, -verifyroms, -romident, -createconfig, etc. mameopts.cpp - Registers all MAME-specific command-line options on top of the base engine options. audit.cpp - ROM set auditing: scans rompath and reports missing, wrong-size, or bad-CRC files. cheat.cpp - The runtime cheat engine (separate from the cheat Lua plugin). infoxml.cpp - Generates the full -listxml machine database output. media_ident.cpp - Identifies unknown ROM files by CRC/SHA1 against the driver database.Lua Engineluaengine*.cpp - Embeds a Lua interpreter and exposes MAME internals as a Lua API, split across five files: luaengine.cpp - Core setup, plugin loading, emu.* table. luaengine_debug.cpp - Debugger bindings (breakpoints, watchpoints, expression evaluation). luaengine_input.cpp - Input port and device bindings. luaengine_mem.cpp - Memory space read/write bindings. luaengine_render.cpp - Render target and screen bindings.ui/ (~80 source files)The complete in-game UI: game/software selection browser (selgame, selsoft), main menu, input mapping, audio effects UI, options menus, file manager, floppy/tape/cartridge controls, state save/load, cheat options, plugin options, system info, barcode reader, and more.Internal utility libraries (src/lib/)Internal utility libraries used across the rest of the codebase.Foundational utilities (src/lib/util/)Foundational utilities with no dependency on the emulation engine. Includes: CHD read/write (chd.cpp), AVI I/O (aviio.cpp), PNG (png.cpp), FLAC (flac.cpp), XML parser (xmlfile.cpp), ZIP/7z decompression (unzip.cpp, un7z.cpp), Unicode handling (unicode.cpp), SHA1/MD5/CRC hashing (hashing.cpp, hash.cpp), palette management (palette.cpp), options parser (options.cpp), HTTP/WebSocket client and server (via asio headers), PLA/JEDEC file parsing (plaparse.cpp, jedparse.cpp), and many more.Disk Image Format Parsers (src/lib/formats/) - 445 filesParsers and writers for disk and tape media image formats. Each file handles a specific format used by imagedev/floppy and imagedev/cassette to translate image files into the internal track/sector model.InfrastructureShared base code used by multiple format implementations - not formats themselves. File Purpose all Registers all compiled-in formats basicdsk Base implementation for simple sector-mapped disk formats cassimg Cassette image abstraction (sample-level) flopimg Floppy image abstraction (new implementation) flopimg_legacy Floppy image abstraction (legacy implementation) fsblk Filesystem operations on mounted image blocks fsblk_vec Block device backed by a vector<u8> fsmeta Filesystem metadata management fsmgr Filesystem management for floppy and HD images imageutl Shared image utility functions mfm_hd MFM hard disk base implementation rpk ROM pack (cartridge packaging) format Filesystem ImplementationsThe table below lists the filesystem backends used by the format layer. File Filesystem fs_cbmdos Commodore DOS (1541, 1571, 1581, etc.) fs_coco_os9 CoCo OS-9 fs_coco_rsdos CoCo RS-DOS (Color Computer “Disk BASIC”) fs_fat FAT12/FAT16 fs_hp98x5 HP 9845 fs_hplif HP LIF (Logical Interchange Format) fs_isis Intel ISIS-II fs_oric_jasmin Oric Jasmin fs_prodos Apple ProDOS fs_unformatted Unformatted disk fs_vtech VTech Audio File FormatsThe table below lists the audio-backed image formats handled here. File Format aiffile Apple AIFF - cassette images in Apple’s audio format flacfile FLAC audio wavfile WAV audio Generic / Cross-Platform Disk ContainersThe table below lists container formats that can hold media from many different systems. File Format Notes cqm_dsk CopyQM DOS-era mass duplication tool image format dfi_dsk DiscFerret Flux Image Raw flux-level capture format dmk_dsk DMK David M. Keil’s TRS-80 Model 4 format; supports copy-protection dsk_dsk DSK Generic .DSK container used by many emulators fdi_dsk FDI v2.0 Formatted Disk Image; supports non-standard sectors g64_dsk G64 Commodore GCR bitstream format for C1541/C1571 hxchfe_dsk HFE HxC Floppy Emulator hardware format hxcmfm_dsk HxC MFM HxC MFM variant imd_dsk IMD ImageDisk by Dave Dunfield; widely used for CP/M disks ipf_dsk IPF SPS/Software Preservation Society; preserves copy-protection mfi_dsk MFI MAME’s own floppy image format pasti_dsk Pasti Atari ST format preserving copy-protection flux td0_dsk TD0 TeleDisk; includes data-compression and sector metadata upd765_dsk uPD765 Raw sector format matching NEC uPD765 FDC register layout Apple FamilyThe table below lists the Apple-family image formats. File System Media ap2_dsk Apple II Disk images (DOS 3.3, ProDOS) ap_dsk35 Apple / Mac 3.5” GCR disk images as_dsk Apple II Applesauce flux-decoded output Atari FamilyThe table below lists the Atari-family image formats. File System Media a26_cas Atari 2600 SuperCharger cassette images atari_dsk Atari 8-bit Disk images (ATR) st_dsk Atari ST Standard ST/MSA disk images pasti_dsk Atari ST Copy-protected disk images Commodore FamilyThe table below lists the Commodore-family image formats. File System Media c3040_dsk CBM 2040/3040 Sector disk images c4040_dsk CBM 4040 Sector disk images c8280_dsk CBM 8280 8” disk images cbm_crt C64 Cartridge .CRT images cbm_tap C16 / C64 / VIC-20 TAP cassette images d64_dsk C1541 / C1551 D64 sector disk images d71_dsk C1571 D71 sector disk images d80_dsk CBM 8050 D80 sector disk images d81_dsk C1581 D81 disk images d82_dsk CBM 8250 / SFD-1001 D82 sector disk images g64_dsk C1541 / C1571 G64 GCR bitstream images Acorn / BBC Micro FamilyThe table below lists the Acorn and BBC Micro image formats. File System Media acorn_dsk BBC Micro / Electron / Archimedes Disk images afs_dsk Acorn FileStore Disk images apd_dsk Archimedes APD protected disk images atom_dsk Acorn Atom Disk images atom_tap Acorn Atom Cassette (Kansas City Standard) fsd_dsk BBC Micro FSD format disk images uef_cas BBC Micro / Electron / Atom UEF cassette images; also covers CUTS/Kansas City standard systems Sinclair / ZX Spectrum FamilyThe table below lists the Sinclair and ZX Spectrum image formats. File System Media opd_dsk ZX Spectrum Opus Discovery disk images ql_dsk Sinclair QL QL disk images sdd_dsk ZX Spectrum Speccy-DOS SDD disk images trd_dsk ZX Spectrum TR-DOS TRD disk images tzx_cas ZX Spectrum / others TZX cassette images; also used for MSX and others zx81_p ZX81 ZX81 cassette .P files TRS-80 / CoCo / Dragon FamilyThe table below lists the TRS-80, CoCo, and Dragon image formats. File System Media coco_cas TRS-80 CoCo CAS cassette images coco_rawdsk TRS-80 CoCo Raw disk images jvc_dsk TRS-80 CoCo / Dragon JVC disk images trs80_dsk TRS-80 JV1/JV3 disk images trs_cas TRS-80 Cassette images vdk_dsk Dragon / CoCo VDK disk images Japanese ComputersThe table below lists the Japanese computer image formats. File System Media 2d_dsk Sharp MZ / X1 Sharp 2D disk format d88_dsk NEC PC-88 / PC-98 D77/D88 disk images dcp_dsk NEC PC-98 DCP/DCU disk images dim_dsk NEC PC-98 DIM disk images dip_dsk NEC PC-98 DIP disk images fm7_cas Fujitsu FM-7 Cassette images fmsx_cas MSX Cassette images (via TZX) fmtowns_dsk Fujitsu FM Towns Disk images msx_dsk MSX Disk images mz_cas Sharp MZ series Cassette images nfd_dsk NEC PC-98 NFD disk images p6001_cas NEC PC-6001 Cassette images pc98_dsk NEC PC-98 Generic disk images pc98fdi_dsk NEC PC-98 FDI disk images sc3000_bit Sega SC-3000 .BIT cassette images sf7000_dsk Sega SF-7000 Disk images x1_tap Sharp X1 TAP cassette images xdf_dsk Sharp X68000 Bare-bones disk images Soviet / Eastern European ComputersThe table below lists the Soviet and Eastern European computer image formats. File System Media agat840k_hle_dsk Agat (Soviet Apple II clone) 840KB floppy - sector-level images bk0010_dsk BK-0010 / DVK / UKNC (Soviet PDP-11) Disk images ds9_dsk Agat-9 840KB controller disk images dvk_mx_dsk DVK MX controller Disk images idpart_dsk Iskra Delta Partner Disk images iq151_dsk IQ-151 (Czechoslovak) Disk images juku_dsk Juku E5101/E5104 (Estonian) Disk images lviv_lvt Lviv PC-01 (Ukrainian) LVT tape images ms0515_dsk MS-0515 (Soviet) Disk images pk8020_dsk PK-8020 Korvet (Soviet) Disk images pyldin_dsk Pyldin-601 (Soviet) Disk images rk_cas RK format (Soviet PDP-11) Tape images smx_dsk Specialist MX (Soviet) Disk images tim011_dsk TIM-011 (Yugoslav) Disk images vector06_dsk Vector-06C (Soviet) Disk images DEC and HP SystemsThe table below lists the DEC and HP image formats. File System Media h17disk Heathkit H17 Hard-sectored 5.25” disk images h8_cas Heathkit H8/H88 H8T cassette images hp300_dsk HP 300 series Disk images hp_ipc_dsk HP IPC Disk images hpi_dsk HP Disk images hti_tape HP Tape images ibmxdf_dsk IBM PC XDF Extended Density Format rx01_dsk DEC RX01 8” disk images rx50_dsk DEC Rainbow 100/190 RX50 disk images Luxor ABC (Swedish)The table below lists the Luxor ABC image formats. File System Media abc1600_dsk Luxor ABC 1600 Disk images abc800_dsk Luxor ABC 830/832/834/838 Disk images abc800i_dsk Luxor ABC 830 Interleaved disk images abcfd2_dsk Scandia Metric ABC FD2 Disk images Thomson (French)The table below lists the Thomson image formats. File System Media sap_dsk Thomson TO/MO series SAP disk images thom_cas Thomson 8-bit Cassette images thom_dsk Thomson 8-bit Disk images OricThe table below lists the Oric image formats. File System Media oric_dsk Oric-1 / Atmos Disk images oric_tap Oric-1 / Atmos Tape images Ensoniq / Music SynthesizersThe table below lists the Ensoniq and other synthesizer image formats. File System Media esq16_dsk Ensoniq ESQ-M, VFX-SD, SD-1, EPS-16+ 16-bit synthesizer disk images esq8_dsk Ensoniq ESQ-1, SQ-80 8-bit synthesizer disk images ppg_dsk PPG Waveterm Waveterm disk images Other Home ComputersThe table below lists the remaining home-computer image formats. File System Media a5105_dsk A5105 (East German KC compact) Disk images ace_tap Jupiter Ace TAP cassette images adam_cas Coleco Adam Cassette images adam_dsk Coleco Adam Disk images aim_dsk AIM-65 Disk images ami_dsk Amiga Disk images (ADF) apf_apt APF Imagination Machine Cassette images apollo_dsk Apollo (Helios) Disk images applix_dsk Applix 1616 Disk images apricotpc_dsk ACT Apricot PC Disk images apridisk ACT Apricot APD disk images aquarius_caq Mattel Aquarius CAQ cassette images as_dsk Applesauce Solved output formats asst128_dsk ASST-128 Disk images bw12_dsk Bondwell 12/14 Disk images bw2_dsk Bondwell 2 Disk images camplynx_cas Camputers Lynx Cassette images camplynx_dsk Camputers Lynx Disk images ccvf_dsk Compucolor II Virtual Floppy Disk images cgen_cas EACA Colour Genie Cassette images cgenie_dsk EACA Colour Genie Disk images comx35_dsk COMX-35 Disk images concept_dsk Corvus Concept Disk images coupedsk SAM Coupé Disk images cp68_dsk CP68 Disk images cpis_dsk Telenova Compis Disk images csw_cas Various CSW (Compressed Square Wave) cassette images dmv_dsk NCR Decision Mate V Disk images ep64_dsk Enterprise 64/128 Disk images excali64_dsk Excalibur 64 Disk images fc100_cas FC-100 Cassette images fdd_dsk Various FDD sector images fdos_dsk FDOS Disk images fl1_dsk FloppyOne DOS Disk images flex_dsk FLEX (TSC / 6800) Disk images fz1_dsk FZ-1 Disk images gtp_cas Galaksija (Yugoslav) GTP cassette images guab_dsk GUAB Disk images hect_dsk Hector (Micronique) Disk images hect_tap Hector (Micronique) K7/FOR cassette images hector_minidisc Hector Minidisc Minidisc images img_dsk IBM PC / various Raw sector .IMG images itt3030_dsk ITT 3030 Disk images jfd_dsk JASPP JASPP Floppy Disk images kc_cas KC85 Cassette images kc85_dsk KC85 Disk images kim1_cas MOS KIM-1 Cassette images lw30_dsk Brother LW-30 Disk images m20_dsk Olivetti M20 Disk images m5_dsk Sord M5 Disk images mbee_cas Microbee Cassette images mdos_dsk Motorola MDOS Disk images (IBM 3740 compatible) mm_dsk MM Disk images mtx_dsk Memotech MTX Disk images nabupc_dsk NABU PC Disk images nanos_dsk NANOS Disk images nascom_dsk Nascom 1/2/3 Disk images naslite_dsk NASLite Disk images nes_dsk NES / Famicom Disk System FDS disk images orao_cas Orao (Yugoslav) TAP cassette images p2000t_cas Philips P2000T Cassette images pc_dsk IBM PC Generic PC disk images phc25_cas Sanyo PHC-25 Cassette images poly_dsk Poly CP/M Disk images primoptp Microkey Primo (Hungarian) PTP tape images rc759_dsk Regnecentralen RC759 Piccoline Disk images roland_dsk Roland samplers Disk images sdf_dsk SAM Coupé SDF disk images smx_dsk Specialist MX Disk images sol_cas SOL-20 Cassette images sorc_cas Exidy Sorcerer Cassette images sorc_dsk Exidy Sorcerer Disk images sord_cas Sord M5 Cassette images spc1000_cas Samsung SPC-1000 Cassette images svi_cas Spectravideo SVI-318/328 Cassette images svi_dsk Spectravideo SVI-318/328 Disk images swd_dsk Swift Disc Disk images tandy2k_dsk Tandy 2000 Disk images tibdd001_dsk TIB Disc Drive DD-001 Disk images tiki100_dsk TIKI 100 Disk images tvc_cas Videoton TVC Cassette images tvc_dsk Videoton TVC Disk images uniflex_dsk UniFLEX Disk images (512-byte sectors) victor9k_dsk Victor 9000 Disk images vg5k_cas VG-5000 .K7 cassette images vgi_dsk Micropolis VGI hard-sectored disk images vt_cas VTech Cassette images vt_dsk VTech Disk images wren_dsk Wren Executive Disk images x07_cas Canon X-07 Cassette images Analog Circuit Simulator (src/lib/netlist/)A full analog circuit simulator. Parses netlist descriptions of discrete circuits (resistors, capacitors, transistors, logic gates) and solves them in real time using numerical integration. Used to accurately emulate the discrete audio circuits found in early arcade games (e.g. Pong, Gun Fight) rather than substituting recorded samples.OSD - OS-Dependent layer (src/osd/)The OSD layer contains all platform-specific code. The rest of MAME calls abstract interfaces defined here; the platform backends implement them.interface/Abstract C++ interfaces (inputman.h, audio.h, midiport.h, uievents.h, etc.) that each platform backend must implement.modules/Platform-agnostic module implementations shared across backends, covering: debugger integration, file I/O, font rendering, input handling, MIDI, network devices, OpenGL, audio output, render pipeline, and window management.Platform BackendsThe platform backends are listed below. Directory Platform Notes sdl/ Linux + macOS fallback SDL2-based window, input, audio sdl3/ Cross-platform SDL3 backend windows/ Windows Win32-native window (winmain.cpp), DirectInput, DirectSound, Direct3D mac/ macOS AppKit/Metal window (mamefswindow.mm), OpenGL view (oglview.mm), native event loop src/tools/Standalone command-line utilities that use MAME’s internal libraries but are built as separate binaries. Tool Purpose chdman.cpp Create, verify, convert, and inspect CHD disk images floptool.cpp Convert and inspect floppy disk images between formats castool.cpp Convert and inspect cassette tape images jedutil.cpp Convert between JEDEC PLD fuse-map files and internal representations romcmp.cpp Compare two ROM sets and report differences unidasm.cpp Universal disassembler - disassemble binary files using any of MAME’s CPU cores ldresample.cpp Resample raw LaserDisc audio captures ldverify.cpp Verify LaserDisc image integrity pngcmp.cpp Compare two PNG files for regression testing regrep.cpp Generate HTML regression test reports srcclean.cpp Normalise source file whitespace and line endings imgtool/ Create and manage filesystem images (Commodore, Apple II, etc.) src/mame/Driver source code, organised into 359 manufacturer subdirectories. Each subdirectory contains the .cpp and .h files that define the machine configurations, memory maps, I/O port bindings, and video/audio wiring for every system that manufacturer made. Examples: apple/, atari/, capcom/, nintendo/, sega/, snk/, taito/, konami/.Each driver calls GAME(...) or CONS(...) or COMP(...) macros to register itself in the global driver list, declaring the machine name, parent, year, manufacturer, and the function that builds its machine_config.ZEXALL - Z80 instruction set exerciser (src/zexall/)A minimal self-contained MAME build target whose only purpose is to run ZEXALL - the Z80 instruction set exerciser originally written by Frank D. Cringle in 1994, adapted for MAME’s Z80 core by Kevin Horton. It is the definitive regression test for MAME’s Z80 CPU implementation.FilesThe ZEXALL target is split across the files below. File Description zexall.z80 The original ZEXALL test program in Z80 assembly (GPL-2.0). The actual test logic and expected CRC values. zexall.h The assembled binary of zexall.z80 baked into a C++ header as a uint8_t array (zexall_binary[0x2189]). interface.h A small hand-written Z80 machine-code stub (interface_binary[0x51]) that bridges CP/M-style BDOS calls to MAME’s memory-mapped I/O output ports. Written directly in hex - no assembly source exists. zexall.cpp The MAME driver. Instantiates a Z80 at 3.579 MHz, maps 64 KB of RAM, loads the interface stub at 0x0000 and the ZEXALL binary at 0x0100, and monitors three memory-mapped I/O ports for output. main.cpp The standalone entry point. Constructs a stripped-down machine_manager with video and sound disabled, throttle off, and runs the single zexall machine to completion. How It WorksEach test group exercises one instruction or a family of related instructions by systematically cycling through a large set of machine states. For each state: Registers - The registers (IY, IX, HL, DE, BC, AF, SP) and a 2-byte memory operand are set to specific values. Instruction - The instruction under test executes. CRC update - The resulting machine state is fed into a running 32-bit CRC.At the end of a test group the computed CRC is compared against an expected value measured empirically on real Z80 hardware. A mismatch means MAME’s Z80 core produces different results to the silicon.The test space is controlled by two vectors per instruction: Increment vector - bits set here are cycled as a binary counter (e.g. if the accumulator byte is 0xFF, all 256 accumulator values are tested). Shift vector - bits set here are inverted one at a time across separate test runs.The total test case count is the product of 2^(increment bits) × (shift bits). Some groups run millions of combinations; others only dozens.The output mechanismThe original ZEXALL was designed for CP/M, which uses BDOS calls (CALL 5) to print strings. Kevin Horton’s interface stub intercepts these calls and redirects them to three memory-mapped ports at the top of the 64 KB address space: Address Port Purpose 0xFFFF output_data The character to output 0xFFFE output_req Incremented to signal a new character is ready 0xFFFC output_ack Incremented by the host to acknowledge receipt zexall.cpp polls these ports each emulated cycle and prints each received character to the console via osd_printf_info. The driver watches for the string \"Tests complete\" and calls machine().schedule_exit() to terminate cleanly.Running ItBecause main.cpp builds a standalone MAME binary containing only the zexall driver (no other machines, no UI), it runs as:./zexallOutput is printed directly to the terminal. A passing run ends with Tests complete. Any line containing ERROR indicates a CRC mismatch on a specific instruction group - meaning MAME’s Z80 core produced a different flag or register result than real hardware.Why It MattersThe Z80 has many edge cases - undefined flag behaviour, the R register increments, block instruction flag interactions, undocumented IXH/IXL half-registers - that are easy to get subtly wrong. ZEXALL catches all of these by running on real silicon first and recording the expected CRCs. Any Z80 core change that alters observed behaviour will cause a ZEXALL failure, making it an unambiguous correctness gate.Testing and PerformanceUnit Tests (tests/)Unit tests for the emulation core and libraries, using the Catch2 framework. Mirrors the src/emu/ and src/lib/ structure.Regression Tests (regtests/)Regression test suite. Contains test definitions for chdman (CHD file tool) and jedutil (JEDEC file tool), along with a regtests.mak makefile to run them.Performance Benchmarks (benchmarks/)Micro-benchmarks for testing performance of core MAME components. Contains standalone C++ benchmark programs.ConfigurationController Configurations (ctrlr/)Controller configuration files (.cfg) that remap MAME’s input system for specific third-party arcade control panels. Loaded at runtime with the -ctrlr <name> flag (omit the .cfg extension).Files IncludedThe controller configuration files shipped with the repo are listed below. File Hardware hotrod.cfg Hanaho HotRod arcade panel hotrodse.cfg Hanaho HotRod SE arcade panel scorpionxg.cfg Digital Systems Design Scorpion XG-2 slikstik.cfg SlikStik arcade cabinet xarcade.cfg Xgaming X-Arcade dual-joystick panel File formatEach file is XML with a <mameconfig version=\"10\"> root element containing one or more <system> blocks: <system name=\"default\"> - applies to every machine. <system name=\"neogeo\"> (or any other driver name) - overrides the default for that specific machine only. xarcade.cfg and slikstik.cfg both use this to remap buttons to match the Neo Geo’s A/B/C/D layout, and slikstik.cfg additionally has per-game overrides for asteroid, missile, and tempest.Inside each <system> block there are two types of entry:Low-level scancode remapsRedirect one raw key to another before any port binding is evaluated:<remap origcode=\"KEYCODE_UP\" newcode=\"KEYCODE_8PAD\" />All five panels use this to route the arrow keys through the numpad (which is how their joysticks report to the OS).Port bindingsAssign one or more inputs to a named MAME input port:<port type=\"P1_BUTTON1\"> <newseq type=\"standard\">KEYCODE_LCONTROL OR JOYCODE_1_BUTTON1 OR MOUSECODE_1_BUTTON1</newseq></port>Input sequence syntax: OR - any of the listed inputs triggers the action. Space-separated codes - a chord; all must be held simultaneously (used for menu combos like coin+start). NONE - explicitly disables an input that would otherwise be inherited.Input source prefixes: KEYCODE_* (keyboard), JOYCODE_<player>_* (joystick/gamepad), MOUSECODE_<player>_* (mouse buttons).UsageTo load one of these controller profiles, pass its base name to the -ctrlr flag:mame <machine> -ctrlr xarcadeConfiguration Presets (ini/)Ready-to-use INI snippet files for MAME’s Direct3D post-processing pipeline. All files use the standard MAME INI format: one key value pair per line, # for comments. They are not loaded automatically - you copy the settings you want into your own mame.ini or a per-machine INI file.The directory is split into two subdirectories by purpose presets and examples.presets/Complete post-processing configurations for a specific display technology. Drop the contents of one of these into your INI to get an appropriate visual style for a whole category of hardware. File Target hardware What it configures raster.ini CRT raster displays (most arcade games, consoles) Shadow mask, scanlines, bloom, phosphor persistence, colour matrix, BT.601 525-line chroma vector.ini Vector displays (Asteroids, Tempest, etc.) Beam width/intensity/flicker, phosphor persistence, bloom with a bright-centre falloff, no scanlines vector-mono.ini Monochrome vector displays Same as vector but stripped to a single colour channel lcd.ini Colour LCD panels (handheld consoles) Slot-mask shadow, no scanlines, neutral colour matrix lcd-matrix.ini Dot-matrix LCD (e.g. older handhelds) Monochrome matrix shadow mask, heavy defocus, boosted saturation for the characteristic greenish tint gameboy.ini Game Boy LCD Same slot-mask pattern as lcd.ini with GBA-like neutral colour tuning gba.ini Game Boy Advance LCD Identical to gameboy.ini - slot-mask, no scanlines, flat colour examples/Single-purpose colour space snippets. Each file sets only the chroma_* parameters that control how MAME maps the emulated system’s native colour space to your monitor. Intended to be mixed into a preset rather than used standalone.Phosphor Colour ExamplesThe phosphor presets below cover common CRT and display technologies. File Phosphor Common use p1.ini P1 - multipurpose green, medium persistence Green-screen monitors p2.ini P2 - blue-green, long persistence Early radar and oscilloscope displays p3.ini P3 - amber/orange Amber-screen monitors p4.ini P4 - white (standard TV phosphor) Consumer CRT televisions p7.ini P7 - blue with yellow-green afterglow Early vector arcade monitors p14.ini P14 - yellow-orange Specialised industrial displays p35.ini P35 - yellow-green, medium persistence Green-screen terminals p55.ini P55 - trichromatic for CRT projectors CRT projection systems Broadcast Colour Space ExamplesThe broadcast colour-space presets below map common video standards to their intended use. File Standard Use bt601-525.ini BT.601 525-line Most 60 Hz arcade, console, and computer systems (US/Japan) bt601-625.ini BT.601 625-line 50 Hz PAL arcade and computer systems (Europe) ntscj.ini NTSC-J Japanese 60 Hz systems - same chromaticity as BT.601 525-line but with a 9300K (D93) white point bt709.ini BT.709 / sRGB Post-1995 computers and HD game systems Keyboard Layout Remaps (keymaps/)Keyboard mapping files (.map) that remap non-QWERTY host keyboards so that MAME’s input system receives the correct key identifiers. Licensed under CC0-1.0 (public domain).Why they existMAME’s internal key identifiers (ITEM_ID_Q, ITEM_ID_A, etc.) are defined relative to a standard US QWERTY layout. On a French AZERTY keyboard the physical key in the QWERTY-Q position produces A, so without a keymap MAME would interpret it incorrectly. Keymap files describe only the keys that differ from QWERTY - anything not listed passes through unchanged.File namingEach file follows the pattern km_<locale>_<OS>.map: File Layout OS km_be_LINUX.map Belgian Linux km_br_LINUX.map Brazilian Linux km_ch_LINUX.map Swiss Linux km_de_LINUX.map German QWERTZ Linux km_es_LINUX.map Spanish Linux km_fr_LINUX.map French AZERTY Linux km_fr_OSX.map French AZERTY macOS km_gb_LINUX.map British Linux km_it_LINUX.map Italian Linux km_pt_LINUX.map Portuguese Linux km_se_LINUX.map Swedish Linux km_se_OSX.map Swedish macOS File formatEach file is an INI-style text file with a [SDL2] section header (all keymaps target the SDL2 backend). Each non-comment line has three columns:ITEM_ID_<key> SDL_SCANCODE_<scancode> <display_char> Column 1 - MAME’s internal key identifier, named after the QWERTY key in that physical position (e.g. ITEM_ID_Q). Column 2 - The SDL2 scancode that the host OS reports for that physical key (e.g. SDL_SCANCODE_A on a French keyboard where the QWERTY-Q physical position sends A). Column 3 - The visible character, included as a human-readable label only.Example - the Y↔Z swap on a German QWERTZ keyboard:ITEM_ID_Y SDL_SCANCODE_Z YITEM_ID_Z SDL_SCANCODE_Y ZKnown issuesSeveral files (km_fr_LINUX.map, km_fr_OSX.map) contain a FIXME comment noting that they produce parse errors and need updating.UI Translations (language/)Translation files for MAME’s UI strings. Each subdirectory is a locale (e.g. Chinese_Simplified, French, German) containing the translated string catalogue.MiscWeb Server Interface (web/)Assets for MAME’s built-in web server interface. Licensed under BSD-3-Clause. Contains two distinct pieces:layout.xslAn XSLT stylesheet that transforms MAME’s .LAY XML layout files into live, interactive HTML pages served by MAME’s built-in HTTP server. The transformation: Converts .LAY elements (rect, text, disk, led7seg) into equivalent SVG shapes, positioned and coloured to match the original layout. Injects JavaScript that opens a WebSocket connection back to MAME (ws://localhost:8080/socket). Sends button press/release events to MAME over WebSocket when the user clicks SVG elements. Receives display-state updates from MAME (e.g. which segments of a 7-segment LED are lit) and updates the SVG in real time.esqpanel/vfx/A hand-crafted browser front panel for the Ensoniq VFX family of synthesiser keyboards. Consists of: FrontPanel.html - The page shell. On load it opens a WebSocket to MAME and instantiates the panel object from FrontPanel.js, showing a “Waiting to connect…” message on the display until the connection is established. FrontPanel.js - A self-contained JavaScript module (fp) that models the physical controls of the VFX, VFX-SD, SD-1, and SD-1/32 keyboards. It renders buttons, indicator lights (off / on / blinking), rotary knobs, and multi-character segment displays as DOM elements. User interactions are sent to MAME over the same WebSocket, and incoming messages update the display and light states accordingly.Running the Web ServerThe HTTP server is off by default. Three command-line flags control it: Flag Default Description -http / -nohttp off Enable or disable the HTTP server -http_port <port> 8080 Port to listen on -http_root <path> web Directory served as the document root (i.e. this folder) Basic usage - start MAME with the server enabled:mame <machine> -httpThen open http://localhost:8080 in a browser. MAME serves everything under web/ as static files, so layout.xsl and esqpanel/ are immediately accessible.Custom port and root:mame apple2 -http -http_port 6502 -http_root /path/to/custom/webThe WebSocket endpoint used by both layout.xsl and the Ensoniq front panel is always at ws://<host>:<port>/socket.Archived Research Files (attic/)Archived source files that are no longer part of the active build but are kept as historical documentation and research references. Every file here is either a standalone tool that was superseded, a stub/skeleton left over from in-progress work, or extended notes on reverse-engineered hardware protection. The directory contains seven files:fd1094dp.cpp - A standalone C++ program (not compiled into MAME) by Charles MacDonald and Nicola Salmoria. It reads 128 MB of raw data extracted from a physical FD1094 encrypted Sega CPU and produces the 8 KB keyfile that MAME’s fd1094.cpp driver uses to decrypt ROM data. Superseded once the key derivation was fully understood and built into the main emulator.fddebug.cpp / fddebug.h - A retired debugging module by Aaron Giles for interactively cracking FD1094 encryption keys at runtime. The bulk of the implementation is wrapped in #if 0 and compiled out; only a hollow stub of fd1094_init_debugging() remains. The commented-out body contains extensive notes on known M68000 instruction sequences found in Sega System 16B games, which were used as known-plaintext anchors when brute-forcing unknown keys.jalmah.x68 - Motorola 68000 assembly source (.x68 format, assembled with the Human68k cross-assembler) by Angelo Salese. Contains simulation snippets for the MCU protection routines in Jaleco mahjong arcade games, written while reverse-engineering the hardware.jrcrypt.cpp - A GPL-licensed standalone C++ program by David Caldwell (1997) documenting the XOR/lookup-table encryption scheme used by Jr. Pac-Man ROMs. Self-described as a documentation artifact; the actual decryption is handled inside the live MAME driver.opwolf_cchip.txt - A detailed plain-text research document describing the Taito TC0030CMD “C-Chip” copy-protection microcontroller used in Operation Wolf. Records the original software simulation that MAME used before an actual EPROM dump of the chip became available, explains the chip’s co-operative threading model (32 thread slots, one per enemy), and catalogues the differences between the original and bootleg versions of the game. Kept purely as documentation now that real C-Chip emulation has replaced the simulation.unkfr.cpp - A driver skeleton by David Haywood acting as a holding area for unidentified fruit machine ROMs that have not yet been matched to a known platform. Most of the driver body is wrapped in #if 0. The file’s own comment instructs contributors to remove confirmed-bad ROMs and migrate anything positively identified to the correct driver.Third-Party Libraries (3rdparty/)Third-party libraries vendored into the repo. Includes cryptography (aes256cbc), networking (asio), JIT compilation (AsmJIT), rendering (BGFX, bimg, bx), compression (flac), XML parsing (expat), image decoding (libjpeg), Lua scripting (lua), SQLite (lsqlite3), benchmarking (benchmark), testing (Catch2), and the Genie build system used to generate project files.BuildingBuild System Scripts (scripts/)Build system scripts. Contains Lua scripts for Genie (genie.lua, toolchain.lua, extlib.lua), subdirectories for per-target and per-source build rules (src/, target/), font generation (font/), XSLT transforms (xslt/), a ROM management utility (minimaws/), and build resource files (resources/).Android Build Project (android-project/)Gradle project files for building MAME as an Android application. Contains the standard Android project structure (app/, build.gradle, gradle.properties, etc.).Build System Project Metadata (projects/)A working area for external MAME-based projects. The directory ships with only a README.md and a .gitignore that ignores everything except those two files - any project you clone here is intentionally untracked by the main repo.How It WorksWhen you run make PROJECT=<name>, the build system sets TARGET to the project name and appends the project’s own Genie Lua build script to the build:projects/<name>/scripts/target/<name>/<subtarget>.luaSo a project cloned as projects/foo/ must provide that script path to be buildable.What You’d Put HereTypical projects that belong here are listed below. A custom operator build targeting only specific hardware (e.g. a stripped binary containing only CPS2 or Neo Geo drivers) A platform-specific distribution - this is how older standalone MESS builds worked before MESS merged into MAME A third-party fork that adds proprietary drivers, a custom UI, or different default options, built on top of MAME’s core without modifying the main treeBuild Output (build/)Output directory created during compilation. Contains generated build system files (generated/), compiled object files and binaries, and IDE project files (projects/). Not tracked by git.", "excerpt": "MAME Repository Structure A guide to every top-level directory and file in this repository. Glossary of Key Terms If you are new to MAME’s source tree, this glossary covers the acronyms used throughout the page. AsmJIT - A lightweight library for generating machine code at runtime, used for JIT compilation...", "tags": ["sourcecode","emulation","arcade"], "image": "/public/generated/placeholders/mame-source-code.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "MSX", "url": "/msx", "content": "IntroductionWelcome to our page dedicated to MSX reverse engineering!On this page, we’ve compiled a list of links to other pages that cover various topics related to MSX reverse engineering. Whether you’re interested in understanding the hardware architecture of retro CPUs, analyzing software at the binary level, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to.So grab your keyboard and mouse, and get ready to dive into the exciting world of MSX reverse engineering!MSXThe MSX was a standard introduced by Microsoft Japan to make sure no matter which manufacturer build the PC (e.g Sony, Panasonic, Philips) they would all be able to run the same software.The MSX has a version of BASIC built in which was an extended version of Microsoft Basic, hence the MSX name 1.There were three different revisions of the MSX: MSX (October 21st 19832) MSX2 (1985) MSX2+ (1988) MSX Turbo R (1990)Introduction to the technology of the MSXThe best video I have found on the MSX is by the Youtuber Displaced Gamers where he goes through all the variations of the MSX (MSX2 etc) and explains the hardware limitations and the impressive feats developers managed to accomplish on the systems:MSX GamesWhile the MSX system is most famous for Konami games like Vampire Killer (Castlevania) and Metal Gear there are quite a few games worth playing for the system. What better video to show off the MSX games than the Game Sack episode on the topic:Sony MSX HardwareWay before the PlayStation or even the Super Nintendo CD, Sony created hardware for playing games in the form of MSX computers 1. Sony released their HIT-BIT machines which started with the HB-10 which had 16KB of RAM and ranged all the way up to the MSX 2 compatible HB-T600 with 128KB RAM 3.All Sony hardware that they developed - Generation MSXAll Posts References PSi2 Issue 19 ↩ ↩2 Release date of MSX ↩ All Sony hardware that they developed - Generation MSX ↩ ", "excerpt": "Introduction Welcome to our page dedicated to MSX reverse engineering! On this page, we’ve compiled a list of links to other pages that cover various topics related to MSX reverse engineering. Whether you’re interested in understanding the hardware architecture of retro CPUs, analyzing software at the binary level, or exploring...", "tags": ["msx","pc"], "image": "/public/generated/placeholders/msx.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Maestro64", "url": "/maestro64", "content": "SN Systems Maestro64 was a development kit sold to game studios in the late 1990s mainly for use by 3D artists, Sound designers and the like rather than programmers.It has also been called a Music Development System, most notably by the Handheld Museum [1]. But on the official website in 1998 it is described as a “low-cost preview tool for Artists, 3D-modellers, Musicians and Level-Designers” [2]. It goes on to describe the advantage of such a tool, basically using a stock N64 with this cartridge is a lot cheaper than buying an entire development kit again.So the benefit of this kit is smaller studios can buy the cartridge from SN Systems, hook it up to a retail N64 console and each Artist can test their own creations on the N64 without having to bug the developers for the full development kit. This allows a much faster prototype cycle, allowing to see exactly how a creation would run on a real Nintendo 64.Photographs of the Maestro64All these excellent photos are from RetroGames.co.uk where one was on sale at the price of £250 [3]Very interesting looking box with a beautiful user-guide, I wonder if there are scans available on the internet for the content of the manual.This particular unit seems to have been purchased by the 3DO Company and you can see the SN Systems logo etched on the cartridge.The back shows the port where you connect to the PC.References http://devkits.handheldmuseum.com/SN64.htm Official Website archive - https://web.archive.org/web/19980523231505/http://www.snsys.com:80/snsys/page.asp?c=maestro64 Images from http://www.retrogames.co.uk/040010/Nintendo/N64-Maestro-Development-Kit", "excerpt": "SN Systems Maestro64 was a development kit sold to game studios in the late 1990s mainly for use by 3D artists, Sound designers and the like rather than programmers. It has also been called a Music Development System, most notably by the Handheld Museum [1]. But on the official website...", "tags": ["n64","devkit","hardware","snsystems"], "image": "/public/bdIl6SRdT2u7pt9pl7YOw_img_0.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Retro Gaming & Development Magazines (Games Industry)", "url": "/magazines", "content": "One of the best ways to get an insight into the games industry is to look at the magazines that were available at the time, both game-specific magazines and digital/creative magazines have a wealth of information that is not currently available on the internet. This post provides details on some of the best magazine sources to help with retro game development research.Games Industry MagazinesOccasionally you can be lucky enough to find a whole magazine specifically dedicated to Game Development but they can be few and far between.Unfortunately, most are now defunct but one excellent title remains until the time of writing: Wireframe magazine, if you are in a position to support this magazine I would strongly recommend it. Title Publisher Notes Develop Intent Media / New Bay Media UK Magazine which was published from August 1996 Until November 2017 MCV Intent Media / New Bay Media / Future UK Magazine which was published weekly and is still going today Game Developer UBM Tech US Magazine which was published from March 1994 until July 2013 - Note that the free pdfs online do not have the full content such as adverts inside GameMaker Future Publishing UK magazine dedicated to Game Modding and Development. Only 1 issue was published in October 2003 before it became a supplement for the PC Format magazine (which also didn’t last long) Journal of Computer Game Design Self Published From June 1987 until 1993 when it rebranded to Interactive Entertainment Design Wireframe Raspberry Pi Press From November 2018 and lasted until January 2023 (70 issues) DevelopDevelop was a UK magazine dedicated to game developers in the industry similar to the US magazine Game Developer, it published 11 issues a year, one a month except December and January where there was one issue for both months. After 188 issues it was merged with its sister title MCV to become MCV/Develop but it kept the MCV issue numbering.There is a wealth of relevant articles and information in this journal so we have split this section into its own post: Develop (UK) Game Development Magazine/Journal For more information on Develop Magazine check out this post. The post contains everything we know about the interviews and articles published every month along with additional information that may be relevant to game development history.GameMaker Magazine (2003) - Magazine in the UK dedicated to Game ModdingGameMaker was a very unique magazine published in the UK on October 2003, it was a game development and modding magazine targetted at the general public!Sadly the topic was deemed too niche and only one issue was ever published before it became a section of PC Format magazine for two issues (159 & 160) and then a stand along supplement distributed along with the magazine for a further 3 issues until it was replaced in issue 165 by a Doom 3 supplement instead.We have a separate page with an index of all the articles and other information about the magazine here: GameMaker (UK) Game Development Magazine GameMaker was a unique magazine first published by Future PLC in the UK in October 2003. It was a game development and modding magazine targeted at the general public! It... Journal of Computer Game DesignThe “Journal of Computer Game Design” was founded by Chris Crawford, a well-known game designer and developer, in June 1987 1. The journal’s primary focus was on computer and video game design. It was one of the first publications to provide insights and discussions on the art and science of game design.It cost $30 a year to subscribe and the journeals were released every other month, it was the first attempt to foster a community around game design 2;The journal featured articles, essays, and discussions about various aspects of game design, development, and theory. It covered topics such as game mechanics, narrative design, player engagement, and industry trends. No programming or asset development articles were posted it was purley for game design.The “Journal of Computer Game Design” ceased publication in the early 1990s. While it had a significant impact during its existence, it was succeeded by other publications and academic efforts dedicated to game design and development.Relevant ArticlesAll the articles are now freely available on Chris Crawford’s website in a well categorized manner so there is little benefit to repeating that work here, if you are interested in early articles about game design then head over there now!Wireframe Magazine Wireframe is an excellent magazine that blends developer interviews with practical tutorials such as how to implement various game mechanics in programming languages such as python or even C programming for the original Game Boy! They even release all the issues they make free on their website in pdf form for everyone (not just subscribers). Sadly Wireframe magazine is no longer producing new magazines after issue 70. You can view all the issues on their official website:Issues - Wireframe MagazineRelevant ArticlesIt is worth reading the entire Wireframe issues cover-to-cover but the most important section for game development is the “Toolbox section of the magazine.Here is a table of the articles most relevant to both modern and retro game development: Issue Name Description 1 Design principles An Atari veteran on the philosophy of game design (Howard Scott Warshaw) 1 City Craft The design Theory behind video game cities (Konstantinos Dimopoulos) 1 Source Code How particle physics turned Defender into a coin-op classic (Python/pygame) (Craig Grannell) 1 Maths of balance Examining the curves and formulae behind the games we play (Will Luton) 2 Life in the trenches interview with Jane Whittaker on Atari Jaguar development of Alien vs Predator 2 FPS level design Learn the basics of shooter level design with Half-Life 2 2 CityCraft How understanding city functions results in better game design 2 Source Code The simple yet effective AI behind Galaxian’s angry aliens 2 Maths of balance part 2 Exploring how maths governs matchmaking and economics 3 Design principles What Yars’ Revenge can teach us about design goals and planning 3 CityCraft The abstract models that will make your video game cities shine 3 Source Code How parallax scrolling gives 2D games the illusion of depth 3 Build a shooter in Unity Get to grips with Unity in our step- by-step guide to making an FPS 4 CityCraft Clever tricks to make our video game cities seem bigger and busier 4 Source Code How to recreate the thrust motion in Atari’s coin-op classic, Asteroids 4 Publishing on itch.io Our step-by-step guide to publishing and selling your games 4 Getting into the industry Some professional advice for anyone hoping to make games for a living 5 Design principles Why being prepared to deviate from established design ideas is essential 5 CityCraft Three ways of making a truly immersive video game city 5 Source Code How to create your own arcade-style high-score table 5 Improving your Unity FPS Part two of our guide to makinga first person shooter 6 CityCraft The pitfalls to avoid when designing a game city 6 Source Code How to recreate the whipping alien tail from R-Type 6 Localisation Prepare your game for a global audience 6 Level design Six tips to make your level designs shine 7 Design Principles How economy and theatre make better games 7 CityCraft Why a game city is only as good as its surroundings 7 Source Code Recreate the jumping physics from Super Mario Bros. 7 Finalising your Unity FPS Add menus, special effects, and more in the final part of our guide 8 CityCraft Ways to make your horror game locations even scarier 8 Structurally Sound How music and sound intertwine to create atmospheric game worlds 8 Source Code The code behind Missile Command’s unforgettable vapour trails 8 Squeezing the Beeb How to fit a 1KB score attack game onto the BBC Micro 9 Design Principles The power of marketing – and a strong game title 9 CityCraft Understanding the hierarchies of villages, towns, and cities 9 Source Code Recreating the disintegrating shields from Space Invaders 9 Character building Import and animate a 3D character model in Unity 10 CityCraft Must-read books for budding virtual city designers 10 Source Code Recreate Pang’s evil bouncing balloons in Python 10 Get into Twine A beginner’s guide to creating interactive fiction in Twine 10 Multiplayer detox Ways to make safer, friendlier multiplayer games 11 Design Principles Defining the difference between theme and design 11 CityCraft Finding fantasy in medieval towns and cities 11 Source Code Recreate the block smashing action of Breakout 11 Paper prototyping How paper and card can help you make better games 12 CityCraft Infrastructure fundamentals for virtual cities 12 Source Code Recreate Bomberman’s four-way explosions 12 Making Snake Code your own arcade game in JavaScript 12 Pushing PICO-8 How to go beyond the virtual console’s memory limits 13 Design Principles Defining the meaning of the word game’, and why it’s important 13 CityCraft Bringing vibrancy and realism to your video game streets 13 Teleporting in Unity Your guide to making an Overwatch-inspired blink mechanic 13 Source Code Recreate Gyruss’s zooming starfield effect 14 CityCraft Analysing the genius of City 17 and New Vegas 14 Art and commerce Making creative games that actually sell 14 SIN made simple Master the SIN function without all the fiddly maths 14 Source Code Make a Donkey Kong-style animated walk cycle 15 Design Principles What video games say about their creators and players 15 Blasting off Make a Jetpack feature in Unreal Engine 4 15 Source Code Ant Attack-style isometric graphics explained 15 A new dev diary Why the vertical slice is an indie dev’s best friend Games Specific MagazinesThere are many magazines related to Gaming both past and present, however only a few of them have interesting articles about game development, the ones we know about are listed in the table below. Title Publisher Run Notes Computer Gaming World   1981-2006 USA Magazine that ran from 1981-2006 DC-UK Future 1999-2001 Short lived UK Dreamcast magazine Dreamcast Magazine Paragon 1999-2002 UK Dreamcast Magazine (34 issues) Dreamcast Monthly Quay Publishing 1999-2001? UK Dreamcast Magazine (17 issues?) Dreamcast Official Magazine (UK) Dennis Publishing 1999-2001 UK Dreamcast Magazine (23 issues including specials) Dreamcast Official Magazine (USA) Imagine Media 1999-2001 USA Dreamcast Magazine with 13 issues Dreamcast Solutions Paragon 1999-2001 UK Dreamcast Magazine Dreamcast Strategies Quay Publishing 1999 UK Dreamcast Magazine DC-Tips Future 2000 UK Dreamcast Magazine Spin off of DC-UK Dreamcast Tips LCD 1999 UK Dreamcast Magazine with only 1 issue ever published EDGE Future   UK magazine that contained interviews with game developers and even adverts for Development Kits GamesTM Highbury 2002-2018 UK Magazine that contained interviews with Game developers reached 213 issues GameBytes   1992-1994 MS-DOS based application for an interactive magazine released on BBS between 1992-1994 https://www.dosgames.com/gamebytes.php Mean Machines Sega EMAP 1992-1997 UK Sega Magazine that has 53 issues MEGA Future 1992-1995 UK based Sega magazine with 38 issues Mega Action Europress 1993-1994 UK Sega Mega Drvie Magazine with 11 issues Mega Machines Impact 1993-1994 UK Sega Magazine with 5 issues Mega Play Sendai 1990-1995 US Sega Magazine Mega Power Paragon 1993-1995 UK Sega Mega Drive Magazine MegaTech EMAP 1991-1995 UK Sega Mega Drive Magazine (43 issues) Megazone Megazone Publications 1990-1994 Australian Amiga & Sega Magazine had a regular section called “Pirates Cave” where crackers could write in and share their thoughts on software piracy Mr Dreamcast Magical Media 2000 Only 2 issues were published of this UK Dreamcast magazine PC Gamer Future 1993-present Long Running UK Magazine dedicated to PC Gaming, sometimes has game developer and modding content PSi2 Thin Ice Media (Datel) 2000-? This occasionally contains top quality articles about Homebrew and Game Development for the Playstation 2 Retro Gamer Live/Imagine/Future 2004-present Long running UK Magazine dedicated to Retro games, often has interviews with game developers Super Pro Paragon Publishing 1992-1994 Super Nintendo Magazine that had some interviews related to game development such as the interview with Brain Fargo of Interplay EGM - Electronic Gaming MonthlyElectronic Gaming Monthly or EGM was a monthly magazine published in the USA by Sendai Punlishing. It often featured interviews with game developers and “Behind the scenes” articles so it is a good source for information on retro game development.Pixels to Pages - The Story of Electronic Gaming MonthlyGame Sack has an excellent documentary about the rise and fall of Electronic Gaming Monthly (EGM). It details the magazine’s aggressive editorial strategies, such as the “Review Crew” and “Sushi X,” and covers the technical challenges of early game journalism, including the use of custom photography rigs like the “cone of silence” to capture CRT screenshots before digital press kits existed.GameBytes (1992-1994)GameBytes was a very unique magazine as it wasn’t published in a traditional sense, it was released for free online on Bulletin Board Systems, it was also unique in its format as it was an actual interactive MS-DOS Application!Over its relatively short life span it obtained some very interesting articles related to the Game development industry, including multiple reviewes of the Computer Game Developers Conference in 1994.You can experience the magazines online through an emulator on DOSGames.com.EDGE MagazineThe magazine EDGE published its first issue on August 19th 1993 with a focus on going more in-depth on technical details such as how games are made, technical aspects and development issues 3. It targeted multiple console/PC platforms (Mega Drive, SNES, Amiga etc) and is famous for hiring many of the engineers at Rare due to their advertisements (Dr Doak is one example of someone who applied thanks to an EDGE advertisement).For their news sections they would “borrow” from Japanese magazines such as “Weekly Famitsu” and US magazines such as “EGM” 3.PSi2 Magazine Published by Thin-Ice Media (Owned by Datel) it was the only non-official Playstation 2 magazine to include a playable CD every issue. Each CD would contain a few Action Replay Cheats and save games that can be applied to a few select games, it formed as a good advertisement to Datel’s Action Replay product. Whether it was always intended to be just another advertisement route for Datel or not, it ended up having a good run of 38 issues or just over 3 years on High Street shelves! Relevant Articles in PSi2As Psi2 was an unofficial magazine published by Datel it was a good magazine for news about development topics and homebrew along with general game reviews and news. Here is a table of the most relevant articles for the topic of the site (game development and homebrew) Issue Name Description 18 Linux PS2 PSi2 interviews developers such as Charles Cecil to find out if the PS2 Linux kit can revive the “bedroom coder”. They are pretty harsh on the kit and outright say its only beneficial for people learning to program and that its better to learn on Windows with Visual Studio and DirectX 18 Yabasic Appeal The editor asks for readers Yabasic games/programs to be put on next issues cover disk 18 Indie day Interview with indie developer Vis entertainment who developed games like Tom & Jerry Fists of Fury on N64 19 Developer files; Europe History of DMA Design (GTA 3), Lost Boys (Knights), Bizarre creations (Fur Fighters), Amuze (Headhunter), Criterion (Burnout) 19 Indie day Interview with indie developer Runecraft founded in 1997 with 120 employees 20 One step beyond Interview with Beyond games they mention they have a game engine called “Brainstom” which they used for Motor Mayhem and Hot Wheels which apparently has networking capabilities 20 A Week in the life of Runecraft Lays out the day to day work of the art development of Runecraft while they develop games for the PS2 such as Premier manager. They use photoshop for texturing but its unclear what software they use for 3D modelling as the screenshots are too low-res but possibly 3DS Max. 20 Indie day Interview with Pivotal games on their game Desert Storm 21 A Week in the life of Kuju   21 Indie day Interview with Argonaut games PSi2 Magazine CDsSome of the Magazine CDs/DVDs contained Video content on behind the scenes information for upcoming games, such as interviews with developers and even Yabasic games with source code. Issue Number Content 19 Yabasic Tetris by Marc Gale (Xalthorn) 20 Yabasic Asteroids Lab X by Christopher Rankine 21 Yabasic Bats in the Lab by Christopher Rankine 21 Trailers for Auto Modellista, Red Dread Revolver, Dino Stalker, JoJo’s Bizarre Adventure and others 22 Behind the Scenes of V-Rally 3 23 Talking about the Mechanics of The Thing 28 Trailer of travel documentaries from Pilot Guides to places like Mexico, Spain, India (Pilot Film and Television Productions Home Page) 29 The Making of Tomb Raider: Angel of Darkness Retro Gamer MagazineRetro Gamer is widely considered one of the single best sources for interviews with classic game developers.So if you are looking for primary source information on how classic games were made, it is arguably the industry standard for print media.We have a separate page with an index of all the interviews, articles and other information about the magazine here: Retro Gamer Magazine - List of Interviews and Notable issues Retro Gamer is a British magazine devoted entirely to classic video games, first launched in January 2004 1. Over the past 20+ years it has grown from a niche quarterly... Creative MagazinesCreative Magazines related to topics such as art/3d graphics and even web development are just as valuable a source as gaming magazines for the time as they would often talk about industry events and software that were often used by game developers. Title Country ISSN Notes 2D Artist UK N/A (online only) Online magazine by UK publisher Zoo Publishing dedicated to 2D Art 3D Artist UK 1759-9636 UK magazine published by Imagine Publishing from 2009 until December 2019 3D Art Direct UK N/A (online only) Online magazine all about Fantasy & SCI-FI art interviews 3D Design US 1083-5288 Magazine published by Miller Freeman, changed its name to just 3D in July 1999 issue 3D World Global 1470-4382 Dedicated 3D Magazine from 2000 until October 2024 Computer Artist USA   magazine From 1994 until at least 1997 published by PennWell Publishing Company Computer Arts UK   magazine from 1995 until 2020 but was also published globally Computer Arts Projects UK   Called Computer Arts Special until issue Computer Graphics World USA   magazine from 1977 until 2022 published by PennWell Publishing Company Cre@teOnline UK   Magazine from 2000 until ? Digit UK   Published by IDG and lasted 112 issues until it got renamed into Digital Arts Digital Arts UK   UK magazine published from ? until ? previously called Digital Arts iCreate UK Magazine dedicated to creating content on Apple platforms like Mac and iPhone   Linux User & Developer UK   magazine that was published for 19 years and reached issue 196 Photoshop Creative UK   Published until September 2018 Web Designer UK   magazine from 2004 until ? .net UK   magazine published until May 2020 3D Design Magazine (USA) (1995-2000) (ISSN 1083-5288)3D Design was a US magazine devoted to 3D graphics and design, published by Miller Freeman in San Francisco. It launched around 1995, with Allison Arden credited as its National Sales Manager who helped start the magazine and its website in 1995​ 4.It was typically issued monthly for example, Volume 2, No. 9 corresponds to September 1996​ but it is unclear when the first issue was published.In mid-1999, Miller Freeman announced that 3D Design would be rebranded as simply “3D” – the change took effect with the July 1999 issue​.After a brief run under the name 3D, the publication was eventually closed by CMP Media (which by then owned Miller Freeman’s titles) around late 1999 or 2000​ 5.Editorial TeamThe magazine’s editorial team included industry veterans. Ted Greenwald served as an early Editor-in-Chief, and Kelly Dove was Senior Editor from 1995 to 1998 (later becoming Editor-in-Chief)​ 6.Under their direction, 3D Design focused on the rapidly evolving field of 3D graphics. Technical editor Bill McCloskey, for example, wrote a monthly column on emerging web-3D technologies – he was among the first to cover VRML (Virtual Reality Modeling Language) for the Web​ 7.Other columnists and contributors (like Barry Fox, who also served as a technical editor) kept readers informed on cutting-edge tools such as VRML, 3D web animation, and hardware acceleration.3D Design Conference & ExhibitionThey also hosted an event called the 3D Design Conference & Exhibition in 1996 to at least 1998 including what they called the Big Kahuna Awards Ceremony.In 1998 it took place on the 19th-22nd of May at the Moscone Center in San Francisco and is credited as the third event which presumably means it started in 1996 6.3D Design Magazine Article Index (1996–1999)Below is a compiled editorial index of selected articles from 3D Design magazine (Miller Freeman, Inc.), covering various issues from 1996 through 1999. Each entry lists the issue (YYYY-MM), article title, author, and a brief description as originally indicated in the magazine’s contents or summary. Issue Title Author Description 1996-12 Year in Review, Wired for 3D: Best of ‘96 Kelly Dove A retrospective of the year’s top developments in 3D graphics and design, highlighting 1996’s “best of” moments and achievements in the industry. 1997-06 Inside The Sixth Man Gretchen J. Bay L.A.-based visual effects house Available Light pushes 3D to the limits as we look behind the scenes at the CG effects created for Disney’s recent live-action release, The Sixth Man. 1997-06 Mastering the 3D Pipeline Omid Rahmat The Applications Programming Interface (API) affects everything from 3D performance to the actual look of the final image. If the ultimate ambition of your 3D design is real-time interaction, you better get a grip on the basics of 3D APIs because they may dictate how far your art can go. 1997-06 Accelerated 3D: Round One Chris Tome Do you really have to spend a lot of cash to get a 3D graphics board that is perfect for your needs? Not necessarily. Look here as the testing begins on nine 3D boards from ATI, Matrox, Intergraph, Diamond Multimedia, Dynamic Pictures, Accelgraphics, and Number 9, all of which retail for less than $1,000. 1997-06 Plugged In Dan Ablan That Special Glow. From glowing-hot logos to the shimmering halos of heavenly creatures, Gaffer, Worley Lab’s latest release for LightWave, lets animators pull out all the stops when creating shadows and light effects. 1997-06 Plug-ins on the Side Gretchen J. Bay We’ve rounded up five exciting new plug-ins for 3D Studio MAX, Softimage, and Photoshop that can add flare and finesse to your next design project. 1997-06 Lighting 3D Cinematically. Don Schaab and Robert Nederhorst Lighting is a critical part of any 3D scene, but the principles of lighting have been around a lot longer than any software package you may have. Take a look at some of the tried-and-true lighting concepts pioneered by the folks in the film industry, and see how things done in the movies apply to the computer screen. 1997-06 Try to Maintain Chris Tome Managing all the resources for your creative endeavors can be a daunting task at best, particularly when they’re stored in that silicon-based repository on your desk. Here are some helpful (and, of course, free) solutions to help you organize the plethora of files, data types, and projects cluttering up your hard drive. 1997-08 Big Kahuna Awards 1997 Kelly Dove Coverage of the 3D Design Conference’s inaugural “Big Kahuna” award winners for 1997 – showcasing the year’s most outstanding 3D design projects and innovators. 1997-10 Let Bones Be the Backbone: Animation in Imagine John Jackman A practical look at character animation in Imagine 3D software, focusing on using bone structures to drive complex animations and bring 3D characters to life. 1998-08 The Best 3D of the Year: Big Kahuna Winners 1998 Kelly Dove An overview of the top 3D projects of 1998, honoring the winners of the 2nd annual Big Kahuna Awards. This feature celebrates the year’s most impressive work in 3D modeling, animation, and visual effects. 1999-04 Wing Commander – From CD to Silver Screen Undisclosed “Digital Anvil’s popular computer game Wing Commander is winging its way to the big screen – join us behind the scenes as we look at the transition from desktop to feature film.” (Behind-the-scenes on the making of the Wing Commander movie’s CGI effects.) 1999-04 Don’t Bug Out!** (Animating Arthropods in 3D Studio MAX) Undisclosed Techniques for bringing creepy-crawlies to life: this tutorial-style article explains how to realistically model and animate insects and other arthropods using 3D Studio MAX, from wing flaps to skittering legs (as hinted by the cover tagline). Computer Graphics World (USA) Computer Graphics World (CGW) is one of the longest running magazines dedicated to computer graphics, published initially in the late 70s right up to the present day (2022+). One of the good things about CGW is that they have articles from each issue available on their web page, going all the way back to 1999. However one of the bad things is that they seem to actively take down PDFs of pre-1999 issues from sites such as Archive.org. This really is a shame as they are one of the best resources to see the state of the art in 3D graphics at a particular point in time. Since this website is dedicated to real-time applications of computer graphics the most useful years are from the 90s onwards when colourful 2D and 3D graphics become possible on consumer hardware. The magazine is formed of 80+ pages of content, some of which are adverts (interesting CG tool adverts however!) and the following main content sections: Editor’s Note - Also available fully on their Website Letters - Published user letters sent to the magazine (Only in physical Magazine) Spotlight - News and Products (Also on Website) Tech Watch - Interesting articles (Only in physical Magazine) Portfolio - Presumably Not got copyright permission from individual authors for publishing on their website User Focus Products - Also available on their WebsiteRelevant ArticlesThe table below focuses on the articles related to Game Development, the list is still a WIP: Issue Title Author Notes 1990-06 Visualizing Math Lisa Stapleton May give interesting information used by early 3D game developers 1990-06 Stereo 3D Phillip Robinson Very early article on Stereoscopic 3D (does it mention Master System 3D?) 1990-12 Silicon Graphics Straddles PC\\Workstation Market Unknown Early SGI articles are always interesting 1991-02 A Real-Time Stroll Unknown Early real-time graphics from 1991 1991-03 The Video Toaster Unknown Later became Lightwave3D 1991-05 3D from the Ground Up Unknown Might have interesting technical details 1991-06 Algorithmic Advancements Peter Sorensen These algorithms influenced CG and game developers 1991-10 Painting in 3D Barbara Robertson Early 3D painting technology 1992-03 Virtual Reality Arielle Emmett   1992-03 Multimedia Development Unknown Games are multimedia so might be an interesting article for a 1992 perspective 1992-05 Let the Games Begin Diana Phillips Mahoney   1992-05 The market for virtual reality Unknown Early VR tech 1992-07 SIGGRAPH ‘92 Preview Unknown Would be good to see what was shown at SIGGRAPH 1992 1992-11 Modeling Made Easy Caren D. Potter   1992-12 Galactic Graphics Patricia Barnes-Svarney   1993-01 Prime-Time Proving Ground for 3D Graphics Barbara Robertson   1993-06 Kicking the Tires of VR Software Louis M. Brill   1993-07 Hell-Bent on Adventure Gaye L. Graves   1993-08 The Amiga: Is it Time You Took a Second Look? Rick Cook   1993-09 Terrain Modeling Laura Lang   1993-10 Evaluating 3D on the High End Tim Forcade   1993-12 The Games People Play Laureen Belleville   1994-09 Interacting With the Gods T. Reveaux   1994-10 Inside the Game Developer’s Toolbox D. Coco   1994-11 Exploring the Options Beyond 3D Studio D. Pope   1994-12 Fresh Paint: Like word processing, page-layout, and image-editing programs, 3D painting software-which enables artists to paint texture maps directly and interactively onto 3D models-is one of those technologies that seems impossible to imagine ever having been without B. Robertson   1995-02 3D conquers the PC Donna Coco   1995-04 User Snapshots - Animations help sell cereal. Creating cartoon characters for new CD-ROM game. Unknown   1995-05 Driving VR Diana Phillips Mahoney   1995-05 Plug-Ins Electrify 3D Studio Barbara Robertson   1995-05 Model Shop - Designing a watch with Alias Studio Unknown   1995-12 Real-Time 3D Games Take Off Donna Coco CGW: Feature: Real-Time 3D Games Take Off (12.95) 1995-12 Capturing Motion George Maestri Only in Physical Magazine 1995-12 Architecture for the Fun of It Diana Phillips Mahoney Only in Physical Magazine 1996-01 3D Graphics Accelerators for PC Game Development Audrey Doyle CGW: News: 3D Graphics Accelerators for PC Game Development (01.96) 1996-03 Graphics for Games - Workstation Laureen Belleville CGW: Products: Graphics for Games - Workstation (03.96) 1996-04 A Window of Opportunity? George Maestri Takes a look at the three Windows NT compatible 3D animation suites (Softimage, Lightwave and 3DS Max) 1996-12 New Tools for 3D Gamers Donna Coco CGW: Feature: New Tools for 3D Gamers (12.96) 2006-12 Middle Ground - The use of third-party middleware within the entertainment realm is expanding Michael Arrington   Computer Artist (USA)Computer Artist was a monthly magazine published every 2 months by the PennWell Publishing Company in the US and dedicated to Digital art creation Computer Artist – PennWell Publishing Company. It is currently unknown when the first issue was published but the last issue was in June 1997 when it merged into Electronic Publishing magazine.ArticlesDue to their age Computer Artist issues are hard to find, but the ones we can find had the following articles listed in the table below: Issue Article Title 1996-08 Profile: Louis Fishauf - When this award-winning Canadian graphic designer picked up digital tools a decade ago, his illustration work came to the fore. 1996-08 Lean and Clean Art - Vector illustration programs are the preferred tool of some of today’s most original and creative digital artists. 1996-08 Clip Art’s New Life - Digital tools and ever-tighter schedules have re-energized one of design’s most venerable resources. 1996-08 Soft Shadows in QuarkXPress - Depending on the effect you’re after, one or more of these workable approaches may fill the bill. 1996-08 Shapes Functionality Empowers Painter 4 - Resolution-independent “Shapes” add new dimensions to Painter’s flexibility. 1997-02 Editorial: The Algorithmic Artist 1997-02 Behind the Art; Creators of Children’s Books Go Digital - Exploring Textile Design 1997-02 Makeready: The Fifth-Color Follies - A fifth color on press can enhance images, too. 1997-02 Review: Fractal Design Takes Painting to 3D 1997-02 Profile: Ken Musgrave - This landscape artist, who paints by programming, has just moved from an East Coast academic setting to Hollywood’s hottest special-effects house. 1997-02 The Computer Artist’s Studio - Whether you’re starting from scratch or updating your digital tools, these guidelines include the latest considerations for artists and designers. 1997-02 Bit by Bit: Taking it to the Web - FreeHand 7 offers a variety of ways to put images on the Web, as this exercise shows. Computer Arts (UK) Computer Arts was a popular UK magazine dedicated to 2D and 3D creation on PC/Mac, it contained a wealth of information related to asset creation for game development. It lasted 305 issues before the pandemic in 2020 stopped production of the magazine, if you can find back issues of this magazines they are well worth picking up 8. Computer Arts IssuesComputer Arts was initially published as a one off in December 1995 but then became bi-monthly in July 1996 and eventually switched over to being Monthly in September 1997. Number Date Title 1 1995-12 Seeing is Believing 2 1996-07 The Secrets of Digital Art 3 1996-09 Get the hang of Scale 4 1996-11 100 Photoshop Tips 5 1997-01 3D Rendering 6 1997-03 Photo-manipulation 7 1997-05 Techniques for Textures 8 1997-07 Increase your Photoshop Skills 9 1997-09 Develop your 3D Skills with Extreme 3D 10 1997-10 Compositing with xRes 13 1997-Winter   121 2006-04 Design Hotspots 122 2006-05 The Money Issue 123 2006-06 50 Ways to Become a Better Designer 130 2006-12 Create Perfect Characters 135 2007-05 Branch out 136 2007-06 Be The best 137 2007-07 Illustrate » Animate 140 2007-09 Global Challenge 141 2007-10 The Inspiration Issue - Young Guns 143 2007-12 Logo Secrets 148 2008-05   150 2008-07   151 2008-08   152 2008-Summer   153 2008-09   154 2008-10   155 2008-11   156 2008-12   157 2009-01   162 2009-06   168 2009-11   172 2010-03   173 2010-04   175 2010-06   177 2010-08   178 2010-Summer   179 2010-09   180 2010-10   181 2010-11   182 2010-12   Free Book ExtractsThe accompanying CD for Computer Arts often had extracts from popular industry books in PDF format, this was a great way to both advertise the book in question and supply useful content for artists. Much of these are extracts from books that game artists would almost certainly have in their collection. Issue Book Name Notes 130 Reinventing Music Video   130 Advertising is Dead: Long live Advertising   137 ESSENCE: The Face Chapter on simulating tissue damage for Face Textures by Paul Fedor. Pages 142-150 137 Character Animation: 2D Skills for Better 3D Extract for taking a 2D Dog walking animation and turning it into a 3D animation. Pages 152-157 137 Sticker City: Paper Graffiti Art Pages 118-119, 130-131, 142-143, 147-147 140 Adobe Photoshop CS3 One-on-One Pages 302-355 but it’s missing the actual images!! 140 Painter X Creativity: Digital Artists Handbook Pages 19-34 and 229-248 141 EXPOSE 5   141 Secrets of Digital Illustration   143 Choosing and Using Paper Book by RotoVision, free pages 0-21 143 How to Cheat in Adobe Flash Pages 2-5 and page 33 143 The Adobe photoshop Layers Book Pages 1-5 Free ResourcesOften the CDs would contain free resources from around the Web, such as a few sample hours of Video training courses or templates/images. One awesome thing they started doing was including full PDFs for issues from 2 years prior but sadly this didn’t last very long. Issue Free Resource Notes 1 Viewpoint and Nvision Datasets 3D models in Alias and Wavefront formats including a scorpion, skyscraper, dinosaur, laser equipped truck and even an army general 1 Truespace 2.0 Animation and Rendering suite 1 Adobe Premiere 4.0 Save disabled version of the movie editor 1 Calamus 95 Windows 95 version of the popular Atari ST Desktop Publishing (DTP) package, save-disabled demo version 1 Photoshop 3.0 Fully featured demo version of photoshop but save is disabled 121 50 photoshop plugins for Digital Darkroom   121 Pentagram documentary   121 Lynda.com Dreamweaver 8 Essential Training   121 50 iStockphoto images   121 16 Typephases fonts   122 MyPictureMarc Freeware 122 Lynda.com Flash 8 Professional Essential Training   122 4 Fontoville fonts   122 3 Media Artist Secrets podcasts   123 Maxdox Mobile Publisher Personal Edition Freeware mobile publishing software 123 5 ShowStoppersFX motion backgrounds 5 Royalty-free videos 123 Lynda.com After Effects 6 Essential Training   123 30 PhotoObjects images 30 Royalty free images used in the tutorial for Adobe Bridge 123 Issue 100 PDF PDF for each page of the 100th Issue of Computer Arts 130 50 Fotolia images   130 The Designer Series Three: Studio Output   130 Lynda.com Illustrator CS2 and Flash 8 Integration training   130 10 Icon Republic icons   130 Jeremyville videos   136 Issue 113 PDF PDF for each page of the 113 Issue of Computer Arts from September 2005 136 100 royalty-free Fotolia images   136 Ten Project Dogwaffle tutorials   136 Lynda.com After Effects 7 Essential Training   137 Issue 114 PDF PDF for each page of the 114 Issue of Computer Arts from October 2005 137 Lynda.com Flash CS3 Professional Essential Training 1 hour 13 minutes of content (chapters 2-4) from Lynda.com’s 8 hour Flash training course Flash CS3 Professional Essential Training - lynda.com Online Training Library® 137 FlashVillage.com Flash Template Free Television Template, this was also free on their website: FlashVillage.com - FREE Flash Templates 140 FlashVillage.com Flash Template Orbital Template, this was also free on their website: FlashVillage.com - FREE Flash Templates 140 Issue 117 PDFs PDF for each page of the 114 Issue of Computer Arts from Christmas 2005 140 Lynda.com Adobe Photoshop CS3 One-on-One: Advanced Techniques 1 hour of content from Smart Objects (chapter 21) of the 9.5 hour training course 141 26 Diomedia royalty-free photos   141 CG Wallpapers   141 Issue 118 PDF PDF for each page of the 118th Issue of Computer Arts 141 Lynda.com Actionscript in Flash CS3 professional Essential Training   143 Free CG Wallpapers 4 Desktop Wallpapers from CGWallpapers.com in different resolutions 143 Issue 120 PDF PDF for each page of the 120th Issue of Computer Arts 143 50 Free Fonts Free Fonts available on the web from: ultimatefontdownload.com, haroldsfonts.com, iconian.com, larabiefonts.com 143 200 Free CSS Templates CSS Templates that are free on the web from freecsstemplates.org 143 68 free deviantART Photoshop brushes 68 free brushes available on chain.deviantart.com such as fingerprints, footprints and paper 143 35 free vector images Creative Commons Vector art from a wide range of different sites such as LAFKON and Ben Blogged 143 7 Go Media Spray Paint brushes Seven 2500px Photoshop brushes provided by gomedia.us 143 Lynda.com Adobe Photoshop CS3 One-on-One: Advanced Techniques 1 hour of content from the Adjustment Layers chapter (number 22) of the 9.5 hour training course Free Full productsOccasionally as an incentive to buy the magazine there would be a few paid products that are offered “free” as long as you have bought the magazine. Not all issues included free full products but the ones that did were generally worth picking up, but of course it was always an older version of the products as an incentive to upgrade to the latest versions. Issue Free Product Notes 1 Monitest Windows 3.1 Application to highlight areas of phosphor damage to a CRT 1 Picture Publisher 3.1 2D Image editor by MicroGrafx 1 WinImages: Morph V1 Tool by Black Belt that allows you to morph a 2D image into an animation as a standard .AVI movie or .FLC file that can be played with AAPLAY 1 Imagine 3.0 Complete 3D program worth £500 121 Shade 7 Designer LE   122 Carrara Studio 2.1   122 TaxCalc Lite   123 Cleanerzoomer 1.0.1 PC only, removes artifacts from images 136 Bryce 5.0   Cre@teOnline Magazine Published by Future in the UK, cre@teOnline was aa magazine dedicated to designing online content such as web sites or flash games. There was a preview issue provided free in issue 46 of Computer Arts (July 2000). It is unknown when the first issue was published but it lasted a good 37 issues before closing down in 2003 9. Issue Number Focus of Issue 11 Streaming Video 14 Flash 15 Where Next? 16 Client Relationships 17 Technology 18 The State of the Net 19 Ecommerce 20 XML 21 Offline 23 Interactive Tv 24 Flash MX 25 The Games Issue 26 Usability 28 New Talent 30 Motion Graphics The most relevant to this site are the games and flash issues, giving an insight into what it was like developing games for the web back in the early 2000s. the net Magazine (UK)the net was a UK magazine published by Haymarket that started in 1999 and finished in 2001 where it was absorbed into Future Publishing’s .net magazine. It contained some articles about web gaming portals, mainly flash and shockwave.There were 27 issues published and it must have come to a shock to the staff as issue 27 still advertised subscriptions to the magazine. The magazine distribution list was sold to Future Publishing and the November 2001 issue of Future’s .net magazine (issue number 90) contained a banner on the cover saying it now incorporated “the net” magazine 10.Web Designer Magazine (UK) Web Designer Magazine was a popular UK magazine purely dedicated to Web development, it was a relaunch of a previous magazine called Practical Internet and was known by the lengthy title Practical Internet Web Designer from issue 86 until dropping the prefix altogether by issue 95 in 2004. It was initially published by Highbury House until they went into receivership on January 20th 2006 where it was bought by Imagine Publishing, which eventually it was sold to Future Publishing and then discontinued at issue 293 [confirmation required]. Total-Web-DesignStrangely for a magazine dedicated to Web Development, there was no website for the magazine or even its sister title Practical Web Projects. This changed in mid-late 2004 when they bought the domain www.Total-Web-Design.com to represent both magazines.Web Designer issue number 97 (from August 2004) had a behind the scenes look at the creation of the website, Luckily the Wayback machine has an archive of the website which you can view here:Total Web DesignEditorsIt was edited by Thomas Watson from the rename of Practical Internet in 2003 until issue 101 where it was taken over by Mark Hattersley in issue 104. Issue 102-103 did not have a named editor and was simply signed off by The Web Designer Team.IssuesEach issue had a main focus but they all contained tutorials for a wide variety of software such as Photoshop, Dreamweaver, PHP and Flash.The issues we know about are listed in the table below: Number Date Title 86 2003-10 Create Amazing Websites 87 2003-11 Sound and Vision 88 2003-12 Futuristic Web Design 89 2004-01 2004’s Most influential Designers 90 2004-02 Build Brilliant Flash Games 91 2004-03 Dreamweaver Power Tips 92 2004-04 Think like a Webmaster 93 2004-05 ? 94 2004-05 ? 95 2004-06 The Perfect Web Site Makeover 96 2004-07 Make your site sticky 97 2004-08 Photoshop Secrets 98 2004-09 Build Amazing Sites that Work 99 2004-10 Power Up Dreamweaver 100 2004-11 100 professional Web Design Tips 101 2004-12 Design on a Budget (Web Designer Man!) 102 2005-01 Get Your work Noticed 103 2005-02 Hit the Web Template Jackpot 104 2005-03 Dreamweaver vs Golive 105 2005-04 Pocket Web site Design 106 2005-05 RSS 107 2005-06 Stunning Website Construction 108 2005-06 Create an online community WD Game Related TutorialsThe magazine had plenty of interesting web programming and graphic creation content, but as the focus of this site is on games development here is a list of the Game related tutorials.Most of these are for Flash game development but there are also a few Pixel Art tutorials for photoshop mixed in for good measure. Issue # Category Author Title 95 Flash Lee Groombridge Create a cool games console interface 95 Flash Robert Firebaugh Learn how to animate characters in flash 95 Flash Mark Shufflebottom Create an intro animation with Flash MX 2004 96 Photoshop Andy Stewart Create A Perfect Pixel Art House In Photoshop 96 Photoshop Zooey Ball Build An Animated Pixel Art Cityscape 97 Flash Darren Richardson Create an interactive animated flash quiz 101 Flash Mark Shufflebottom Create a stunning flash animation with Swift 3D Web Designer issue 101 also had a behind the scenes look at the website for Myst IV Revelation which was implemented in Flash MX 2004 and provided a game-like experience.Web TechniquesWeb Techniques was a US magazine that started in February 1996 and ran until February 2002 when it rebranded as New Architect.Relevant ArticlesThe table below lists the relevant entries. Issue Date Name Author March 1997 An Internet Game Server In Java Andy Wilson March 1997 Programming Web Games in C Andrew Davison March 1997 A Java-Based High-Score Server Neil Bartlett March 1997 Extending VRML with Realspace Sue Wilcox Programming magazinesThere is a lot of overlap between game development and general programming, so many game programmers in the industry would have subscriptions to general programming magazines such as the ones we have in this section. Title Notes MSDN Journal Windows Development Journal from Microsoft from March 2000 - November 2019 Develop (The Apple Technical Journal) Apple development journal from 1991-? EXE UK Magazine for Software developers from 1986-2000 (old website: www.exe.co.uk) OS2 Developer IBM OS/2 Programming magazine from 1989-? General PC MagazinesThere are many magazines related to the PC both past and present, however only a few of them have interesting articles about game development, the ones we know about are listed in the table below. Title Notes PC Magazine Occasionally had a few articles related to game development or programming PC Magazine (UK)PC magazine called itself “the independent guide to IBM-standard personal computing” and was available from April 1992 until it ceased publication in 2002. Issue # Title Author Notes VOL 13; NUMBER 21 (1994) Power Programming: Real Games for Windows Thielen, D Not available online VOL 15; NUMBER 14 (1996) Power Programming: Using Microsoft’s high-speed Direct Draw API in an arcade-style action game Grell, G.   PC PlusThe table below lists the relevant entries. Issue # Title Author Notes ISSUE 126 (1997) Programmers World: Reviewed this month are a library of useful program source code for Delphi, a DirectX toolkit for VB game programmers, and MSDN     Translating Foreign magazinesIn the age of AI it should be easier than ever to research using non-english magazines, providing rare interviews with early game developers which never made it to english speaking countries.If you just want to be able to read the content in Text form, ChatGPT 4o (other providers are available) is fairly accurate, just take a screenshot of a page and ask it to translate it to english and you get the basic text content in Markdown format.However while translating the content of an image of a single page is very easy and accurate with ChatGPT, if you want to be able to read using the original magazine layout but with english text it is very hard to find a tool good enough to do the job.This section of the page will review the tools I have tried so far to translate Japanese magazine pages to english while keeping the format of the original image.Here is the page that I have used for all of the tests, it is a fairly simple layout and its from the August 1989 issue of Famitsu (issue 80/81) which is an interview with Alexey Pajitnov, the creator of Tetris:ChatGPT 4oChatGPT 4o does a great job of translating the text but cannot generate an image in the same format as the original magazine, the text content is placed here to help compare the other providers text translation:# Tetris Lawsuit, Soviet Game Affairs...# Direct Interview with the Creator of \"TETRIS\"!!From fanbooks to international bestsellers—TETRIS is a global phenomenon!We met up with the creator, Alexey Pajitnov, in Tokyo for this exclusive interview! A genius from the Soviet Union has gifted the world one of the greatest puzzle games ever made.Meeting Alexey in person, we asked about the Tetris copyright battle, the Soviet game industry, and more.## Interviewer:Let’s get straight to the point—who actually owns the rights to Tetris?## Alexey:Originally, the rights to Tetris were owned entirely by the Soviet government. Everything I developed was government property, as I was working at a computer research institute at the time. So the rights belonged to the USSR, not to me personally.## Interviewer:So when did you first hear that the game had become a global hit?## Alexey:In February, I came to the U.S. for the first time and saw the Famicom version. I was shocked! There were so many versions—arcade, home console, PC... I had no idea.## Interviewer:What do you think of the home console and arcade versions of Tetris?## Alexey:Honestly, I’m thrilled. I created Tetris as a simple computer puzzle, and to see it now in so many forms is overwhelming. As a game designer, it’s a dream come true.## Interviewer:What do you think of Japanese developers' interpretations of Tetris?## Alexey:Japanese versions are amazing. They’ve taken my simple idea and turned it into something truly spectacular. The arcade version especially is so polished. The sprite movement is clean and fast—it’s very impressive.## Interviewer:What was it like working as a game designer in the Soviet Union?## Alexey:In the USSR, there wasn’t really a profession like \"game designer.\" I was working with computer logic and AI studies. Game design was just something I did on the side. The concept of making games professionally didn’t exist in the Soviet Union.## Interviewer:Do you have any plans for future games?## Alexey:Yes, I'm involved in a few other projects besides Tetris. But they’re not quite ready yet. I hope one day people around the world will play those too.---### Caption Highlights:* \"The Tetris games taking the world by storm!\"* “This is the man behind the worldwide Tetris sensation—Alexey Pajitnov!”* “Pajitnov, originally a computer scientist, speaks softly but has a passionate love for puzzles.”* \"In Japan, Tetris even came out on the Famicom, and seeing it for the first time brought a huge smile to his face.\"* Bottom right photo: \"Soviet Tetris team visiting Japan—Pajitnov laughs as he tries Japanese versions of his own game!\"Slider.ai - Missing textSlider came up at the top of a google search and offered to “translate images and photos online into 50+ languages with precision and ease.”. It certainly does it with ease but the results were far from precise:Mangaaday.ai - Messy textMagazines are rather obscure, not many people are looking to translate them, manga on the other hand have a huge community of people who want to translate from japanese to english so I was excited to try Mangaaday, the results were not the best of quality:kling.aiKling.ai is not a translator but it does offer image-to-image transformation so I thought I would try it with the prompt “Keep the image exactly the same but translate the text to English”. Sadly although the result is cute it is completely unusable.Transmonkey - best so farAnother online service that advertises its ability to translate Manga is Transmonkey, it provided the best result so far but its not quite perfect, it has a very manga-like font (unsurprisingly) which takes away points from the quality of the output:References The Journal of Computer Game Design - Interactive Storytelling Tools for Writers - Chris Crawford ↩ Volume 1 of JCGD ↩ Edge File Volume 1 Bookazine (2006) ↩ ↩2 Allison Arden - AAF ↩ SRDS. - Free Online Library ↩ Computer underground Digest Sun May 17, 1998 Volume 10 : Issue 30 ↩ ↩2 My Life as an Email Entrepreneur: My Final Article. - Only Influencers ↩ Computer Arts Shuts Down - Aestetik ↩ Create Online at Wayback Machine ↩ Haymarket Closes The Net – The Media Leader ↩ ", "excerpt": "One of the best ways to get an insight into the games industry is to look at the magazines that were available at the time, both game-specific magazines and digital/creative magazines have a wealth of information that is not currently available on the internet. This post provides details on some...", "tags": ["industry"], "image": "/public/images/categories/Games Industry Magazines.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Behind the Scenes (Making Of) Playstation Games in PlayStation Underground", "url": "/behind-the-scenes-ps1", "content": "PlayStation UndergroundList of known issues (CD-ROMs):PlayStation Underground Volume 1.1 - Making of the Twisted Metal 2 Commercial - Making of NFL Game Day 97PlayStation Underground Volume 1.2PlayStation Underground Volume 1.3PlayStation Underground Volume 1.4 - Making of Crash Bandicoot 2PlayStation Underground Volume 2.1PlayStation Underground Volume 2.2PlayStation Underground Volume 2.3PlayStation Underground Volume 2.4 - Making of Crash Bandicoot 3PlayStation Underground Volume 3.1PlayStation Underground Volume 3.2PlayStation Underground Volume 3.3PlayStation Underground Volume 3.4 - Behind the scenes of Crash Team RachingPlayStation Underground Volume 4.1PlayStation Underground Volume 4.2PlayStation Underground Volume 4.3PlayStation Underground Volume 4.4PlayStation Underground Vol. 1 Issue 4Making of Crash Bandicoot 2: Cortex Strikes BackCrash Bandicoot Central has uploaded a fascinating behind-the-scenes look at the creation of Crash Bandicoot 2: Cortex Strikes Back for the Sony PlayStation. Originally featured in PlayStation Underground Vol. 1 Issue 4, the video interviews a few of the Naughty Dog employees and shows off some really brief 3D modelling tools being used.Questions: What 3D Editor is shown in the video?PlayStation Underground Vol. 2 Issue 4Making of Crash Bandicoot 3: WarpedCrash Bandicoot Central shares a behind-the-scenes look at the creation of Crash Bandicoot 3: Warped. Originally featured in PlayStation Underground Vol. 2 Issue 4, the video provides technical insights into the development process by NaughtyDog for the 1998 Sony PlayStation release.PlayStation Underground Vol. 3 Issue 4Making of Crash Team Racing (PS1)Behind the scenes of Crash Team Racing with brief interviews of the Naughty Dog staff that worked on the game. However there is very few technical details in this video it is mainly just advertising the features of the game.", "excerpt": "PlayStation Underground List of known issues (CD-ROMs): PlayStation Underground Volume 1.1 - Making of the Twisted Metal 2 Commercial - Making of NFL Game Day 97 PlayStation Underground Volume 1.2 PlayStation Underground Volume 1.3 PlayStation Underground Volume 1.4 - Making of Crash Bandicoot 2 PlayStation Underground Volume 2.1 PlayStation Underground...", "tags": ["documentary","ps1","games"], "image": "https://img.youtube.com/vi/GMHYrCZBmk0/maxresdefault.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Mario Kart 64", "url": "/mario-kart-64", "content": "Introduction to Mario Kart 64 The Game was made by Nintendo EAD and was released in Europe on June 24th, 1997. The development team consisted of 8 programmers under the lead of Masato Kimura, 7 artists under the direction of Visual Director Tadashi Sugiyama, Audio by Taro Bando and all being supervised by the producer Shigeru Miyamoto 1. The source code is almost completely written in C and compiled with IDO C compiler (Unknown version). Documentation about Mario Kart 64 Home · RenaKunisaki/mariokart64 Wiki https://github.com/shygoo/mk64project2D Graphics & RenderingGameplayTracks/WorldObjectsSounds and MusicText and LocalisationToolsMario Kart 64 World ViewerThis is a very cool tool, it actually allows you to see the tracks from Mario Kart 64 in your web browser! I wish more tools were developed as client side web apps as they are much more cross-platform friendly and don’t require the hassle of download/dependencies etc.The project also contains documentation for the Mario Kart 64 rom file, specifying key addresses of track and texture information. Very useful for anyone wanting to create their own tracks for this classic game!You can view the project and even download the source code on github:Mario Kart 64 Kart ViewerReferences Mario Kart 64 Credits - Giant Bomb ↩ ", "excerpt": "Introduction to Mario Kart 64 The Game was made by Nintendo EAD and was released in Europe on June 24th, 1997. The development team consisted of 8 programmers under the lead of Masato Kimura, 7 artists under the direction of Visual Director Tadashi Sugiyama, Audio by Taro Bando and all...", "tags": ["n64","games"], "image": "/public/0pZkOKRfCUlcJDX5TiJL8g_img_0.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Original Super Mario Kart Source Code (Gigaleak)", "url": "/super-mario-kart-source-code", "content": "The Nintendo Gigaleak preserves a very substantial Super Mario Kart source archive under other/SFC/ソースデータ/MarioKart.Unlike the F-Zero leak, this is not neatly split into Game and Tools.It looks much more like a live working directory copied straight out of development, with assembly source, prebuilt .rel objects, regional variants, editor code, backup-RAM routines, and even Super Famicom disk support code all sitting side by side. Gigaleak - SNES Source Code Leak For more information on the rest of the Gigaleak check out this post. At a GlanceThis archive is especially useful because it preserves several layers of the Super Mario Kart project at once: the main race, battle, menu, ending, object, audio, and decompression code regional source branches for Japanese, European, and PAL-era variants in-engine editors for maps, battle layouts, and RAM/debug work a matching set of .rel object files that make the folder look like an active build workspace, not just a source backup low-level SFX-DOS support modules for floppy, serial, console, and printer I/OIt also preserves a nice timeline of how the project grew: the core runtime files cluster around April to August 1992 the SFX-DOS and hardware-driver files are older, mostly from October 1991 the regional files show late-stage branch work for Japanese, European, PAL, and a few German/debug variantsRoot Directory (SFC.7z/ソースデータ/MarioKart)The extracted MarioKart folder is flat rather than neatly nested.That alone is revealing, because it makes the archive feel closer to a live programmer workspace than a cleaned-up archive prepared for handoff or release.At the top level the file types break down like this: Type Count What it suggests .asm 145 Main 65C816 source modules, editor code, and support libraries .rel 144 Prebuilt assembled objects kept alongside the source .def 6 Shared definitions for labels, work RAM, objects, and regions No extension 6 Register maps and helper include files such as rp5a22, rp5c77, and D77C25 .lib 1 sfxdos.lib, likely a bundled library artifact for the DOS-side support layer That near one-to-one source/object pairing is one of the strongest clues in the whole archive.This does not look like a source-only historical export.It looks like a directory that was actively being assembled and relinked during development.The pairing is not completely perfect, though.A few files stand out: TITLE.asm exists without a matching TITLE.rel, while the actual regional title modules such as title-j.asm, title-e.asm, and title-p.asm do have object files hardware and SFX-DOS support files like sfxdos.asm, sccdrv.asm, fdcdrv.asm, and ppidrv.asm have source but no sibling .rel, which makes them look more like shared support code copied into the directory a few .rel files such as kart-check.rel, kart-ctrl.rel, se.rel, and sos.rel survive without matching source, which hints that part of the build graph still lived outside this copied folderHow Complete This LooksThis looks much closer to a real working Super Mario Kart source snapshot than a token sample.The strongest signs in its favour are: the core game runtime is present in major modules like kart-main.asm, kart-init.asm, kart-drive.asm, kart-calc.asm, kart-bg.asm, kart-ppu.asm, kart-enemy.asm, and kart-apu.asm almost every major gameplay and menu module still has a matching .rel object beside it the archive preserves regional variants rather than just one late merged branch the map, RAM, and disk-related editor code is still present the folder still carries the shared register/label include files that tell the rest of the source where graphics, audio, maps, and backup RAM liveThat said, it is still safer to call this a near-complete working source snapshot than a guaranteed self-contained rebuild package.What is still missing or uncertain: there is no obvious top-level makefile or batch file in this folder showing the exact final build order some modules still include paths like ../join, ../../SFX, ../../DSP, and ../../../kimura, which implies this folder originally sat inside a larger tree a handful of .rel objects survive without source, so not every dependency is visible here the actual assembler, linker, and full SDK environment are not bundled in the directorySo the right claim is not “everything needed to rebuild the shipped game is definitely here”.The better claim is that this looks like a very strong working snapshot of Super Mario Kart’s development directory, with most of the game-side code and a surprising amount of editor and support infrastructure still intact.What the Flat Workspace RevealsThe most interesting thing about this leak is how little separation there is between different kinds of work.In the same directory you can find: top-level game control modules like kart-main.asm and kart-init.asm per-scene files like Battle.asm, Pause.asm, Result.asm, Final.asm, Record.asm, and Scene.asm per-system files like Compress.asm, ISPK-j.asm, System.asm, Object.asm, and Sub_sound.asm editor files like mapedit.asm, maped3.asm, maped4.asm, edit_1.asm, edit_2.asm, edit_3.asm, runed.asm, runed1.asm, and runed2.asm DOS and hardware support code like sfxdos.asm, sccdrv.asm, fdcdrv.asm, ppidrv.asm, condrv.asm, and fileio.asmThat mix makes the archive much more useful than a clean “final source” export would have been.It preserves some of the actual production mess: game code, runtime data, editor logic, disk routines, and old helper libraries all living together in one place.The timestamp spread reinforces that impression.Files like sfxdos.asm, ccp_main.asm, condrv.asm, and fileio.asm sit back in late 1991, while the core racing code and regional branches were still being updated through summer 1992.Main Runtime StructureThe central control flow becomes clear very quickly once the core modules are opened.kart-main.asm is the real top-level dispatcher.It defines Reset_entry, NMI_entry, IRQ_entry, COP_entry, and a main loop that waits for NMI, then jumps through a Process_address table based on the current game mode.That one file alone shows how broad the game had already become by July 1992.It pulls together: race flow battle flow title handling course and kart selection record screens endings and staff-roll style sequences pause handling object transport and camera control three separate editor entry pointskart-init.asm plays the matching role on the transition side.Its Selection_address table includes: Title_initial Kart_select_initial World_select_initial Battle_initial Edit1_initial Edit2_initial Edit3_initial Course_select_initial Final_initializeThat is one of the clearest low-level development details in the leak.The editors were wired into the same mode-selection and initialization framework as the real game screens, not treated as completely separate tools.The work RAM definitions in work.def make that structure even clearer.They document shared state for game_status, game_mode, game_level, game_selecta, game_index, irq_index, world_number, map_pointer, race_init, pause_status, camera state, fade state, sound state, lap counters, and ranking buffers.The Main Loop Is a Small SchedulerWhat makes kart-main.asm especially useful is that it does not just define one generic update loop.It preserves the actual scheduler that the rest of the game was written around.After Reset_entry finishes the hardware-side setup, Main_loop does three things in a very tight cycle: call Selection_process to see whether the game is transitioning into a new state wait until the next NMI flips NMI_flag jump through Process_address using game_indexThat says a lot about how the project was organized.Super Mario Kart was built around a mode dispatcher, with each major screen or tool owning its own main and NMI paths.The Process_address table makes that explicit: Game index Main handler Meaning 00 Playing_process00 idle or placeholder state 02 Playing_process02 race 04 Playing_process04 title 06 Playing_process06 kart select 08 Playing_process08 world select 0A Playing_process0A driver’s point screen 0C Playing_process0C ending flow 0E Playing_process0E battle 10 Playing_process10 editor 1 12 Playing_process12 editor 2 14 Playing_process14 editor 3 16 Playing_process16 course select 18 Playing_process18 final sequence 1C Playing_process1C record screen The editors and record screen were not awkward add-ons.They were first-class runtime modes with the same scheduling status as race, battle, title, and ending.Main and NMI Work Are Split Per ModeThe second useful table in kart-main.asm is NMI_address.It mirrors the main-mode structure and gives each major state its own VBlank-side handler.That split shows how Nintendo kept the heavy per-frame simulation separate from VRAM, OAM, and HDMA work.For example: NMI_process02 handles the race-side VRAM and OAM transport path, then calls Race_checker, Set_HDMA_parameter, Screen_control, Demo_camera, and a common package that handles sound and controller scanning NMI_process04, 06, 08, and 0A do much lighter menu-style work, mostly Set_OAM_screen1, mode-specific NMI code, and the shared input and sound package the battle mode mirrors the race structure rather than the menu structure, which makes sense because it still has to move objects, backgrounds, and camera state every frameThe game is effectively written as a pair of dispatch tables: one for per-frame logic one for VBlank-time transport and rendering setupEven before looking at the subsystems, the overall design already looks clean and deliberate.kart-init.asm Is the Transition LayerIf kart-main.asm is the scheduler, kart-init.asm is the state-transition layer that feeds it.Initialize_process is broader than a normal startup routine.It: clears and initializes RAM brings up the Nintendo splash path initializes the APU and DSP side loads character and direction data calls DOS_INI enables NMI seeds the initial game_selecta, fade_control, and fade_speed valuesThat is already enough to show that startup was not only about the retail game.The boot path still expected the DOS-side support layer and wider dev environment to exist.The real architectural center, though, is Selection_process.That routine watches game_selecta, waits for the fade state to reach the right point, disables interrupts, clears the current mode state, and then jumps through Selection_address to run the correct initializer for the next mode.That table is one of the clearest summaries of the whole project: Selection value Initializer 02 Race_initial 04 Title_initial 06 Kart_select_initial 08 World_select_initial 0A DP_initial 0C Record_initial 0E Battle_initial 10 Edit1_initial 12 Edit2_initial 14 Edit3_initial 16 Course_select_initial 18 Final_initialize So game_selecta is really the transition request register, while game_index becomes the active runtime mode after the transition is complete.That is one of the clearest low-level examples in the leak of how Nintendo separated “what we want to become next” from “what we are running now.”work.def Is the Shared Runtime Contractwork.def is easy to skim past, but it is one of the most valuable files in the entire archive because it names the shared RAM contract that all of the major modules are using.The definitions fall into a few clear groups: Category Examples What they control Global mode state game_status, game_mode, game_level, game_selecta, game_index, irq_index Which broad mode is active and how the scheduler should interpret it Frame and race state frame_counter, race_status, race_init, over_flag, lap_number How the current race or sequence is progressing World selection state world_number, map_pointer, map_number, map_type, game_mode_stock Which course family and specific map are loaded Pause and fade state pause_status, pause_index, fade_control, fade_speed, fade_data Mode transitions and paused execution Camera and scroll state scroll_h, scroll_v, center_x, center_y, camera_distance, camera_pitch, camera_zoom, camera_direction, camera_mode The Mode 7 camera model and screen positioning Audio state sound_port, bgm_flag, bgm_pointer, bgm_status, finallap_counter, doppler_driver Sound command flow, BGM state, and race-specific audio behavior Persistent or score state player_coin, win_count, official_flag, rank_index Results, lap progression, and player-facing game state Reading this file alongside kart-main.asm makes the codebase feel much less opaque.The main dispatcher is not passing around complex structs.It is coordinating a shared WRAM workspace that every major module knows how to read.label.def Is the ROM Content AtlasIf work.def is the RAM contract, label.def is the ROM content atlas.The file does much more than define a few constants.It maps out where major gameplay and presentation data actually lives in ROM: BGM addresses such as Title_BGM, Battle_BGM, Circuit_BGM, Ice_BGM, and Ending_BGM demo driver data like DEMO_MARIO, DEMO_PEACH, DEMO_KINOPIO, and the other prerecorded demo inputs per-map screen data such as MAP00_SCR through MAP18_SCR course-family character sets like CIRCUIT_CHR, OBAKE_CHR, GRASS_CHR, CASTLE_CHR, ICE_CHR, DART_CHR, SAND_CHR, and STAR_CHR matching BCH, BSC, color, and object tables for each course familyThe most revealing part is how systematic it is.Rather than giving every map an entirely unique content stack, label.def shows the game reusing themed asset families across multiple courses and battle maps.For example: multiple circuit maps point back to the same circuit graphics family battle maps reuse the same course-family CHR, BCH, BSC, and color banks instead of defining a completely separate battle-only asset format the per-map *_area and *_target definitions hang off one shared Drive_data_address, which makes the course logic look table-driven rather than hardwiredThat makes label.def one of the strongest “how this was really built” files in the whole archive.It is the bridge between symbolic game logic and the actual packed data layout in ROM and RAM.Course Data Is Table-DrivenThe course-loading side becomes much clearer once kart-init.asm and label.def are read together.Set_map_number does not hardcode a cup flow in logic.It computes an index from world_number and map_pointer, then looks that index up in World_map_data.That table preserves the actual cup ordering: Cup Map order Mushroom Cup 13, 12, 10, 11, 07 Flower Cup 0D, 0A, 02, 03, 0F Star Cup 01, 0C, 0B, 09, 00 Special Cup 04, 06, 05, 08, 0E That is a good example of the project’s overall style.The game flow is controlled by lookup tables rather than lots of map-specific branching.The same pattern continues with Map_type_data.Once map_number is chosen, Set_map_type turns it into one of the shared environment families: circuit obake grass castle ice dart sandThat in turn drives Set_maps, which is split neatly into: Set_map_character Set_map_screenOpen_character and Open_screen pull compressed data into work RAM, while Set_character_data, Set_screen_data, and Set_item_BG push the decoded results toward VRAM and the background buffers.That is where label.def becomes especially valuable.Its MAPxx_CHR, MAPxx_BCH, MAPxx_BSC, MAPxx_COL, and MAPxx_OBJ aliases show that each map is assembled from a handful of themed asset families rather than a single monolithic “course blob”.That runtime-side family reuse also lines up neatly with the separate CAR art workspace in NEWS_04.There, families like C1, D1, G1, H1, K1, S1, W1, and STAR survive as grouped .SCR, .CGX, .COL, and backup-heavy revision sets, which makes the artist-side production flow look just as family-based as the code-side loader tables here.The strongest extra clue is the secondary branch material.In CAR, those same families often keep a smaller -B graphics bank plus a matching -B screen file, while on the runtime side label.def and kart-init.asm keep separate BCH and BSC tables alongside the main family graphics and screens.That does not prove the suffixes map one-to-one, but kart-init.asm gets very close.Its loader tables name those secondary branches Back_character_address and Back_screen_address, and Open_character decodes them as the mode 0 background path beside the main Mode 7 course data.So the safest reading is that BCH and BSC are not arbitrary secondary blobs.They look like the back-layer character and screen sets that sit behind or around the main course plane, which in turn makes the CAR workspace’s smaller -B banks look much more like artist-side companion background layers than random alternates.The circuit family is the cleanest worked example.MAP00, MAP07, MAP0E, and MAP0F all alias the same CIRCUIT_CHR, CIRCUIT_BCH, CIRCUIT_BSC, CIRCUIT_COL, and CIRCUIT_OBJ entries, which means four different circuit tracks were built from one shared family package plus their own per-map main screen layouts.That is exactly the kind of pattern the separate CAR workspace shows in families like C1, where one large graphics bank, one smaller -B branch, one palette, and multiple numbered .SCR layouts all live together in the same artist-side package.The next-strongest candidates on the art side are families like D1, G1, and S1.They keep the same package shape and line up naturally with runtime groups like DART, GRASS, and SAND, but unlike the circuit case the surviving names are still too abbreviated to treat those matches as fully proven.W1 is also starting to look like a plausible artist-side candidate for the runtime ICE family.Its palette is much brighter and more white-heavy than the other unresolved groups, and Scene.asm still preserves a SNOW comment alongside one of the shared obstacle paths used around the ice side of the game.That is still an inference, but it is a useful one.K1 also now looks like a plausible artist-side candidate for CASTLE.On the code side that family means Bowser’s castle courses, so an artist-side K shorthand based on Koopa is at least plausible, and K1 preserves the same full bank-plus-companion-branch structure as the other major environment families.H1 is also looking more convincing as the likely artist-side partner to OBAKE.The surviving preview images in the CAR workspace look ghost-course-like rather than neutral: dark vertical tiles, eye-like sprites, jagged skyline bands, and fence or grave-marker shapes fit the haunted-course side of Mario Kart much better than the remaining alternatives.The same is true for the drive data.The MAPxx_area and MAPxx_target labels all hang off one Drive_data_address, and the later MAPxx_ARE and MAPxx_TRG labels point to tightly packed per-course data blocks in ROM.So the course system is not only theme-driven.It is also highly table-driven: choose a map from the cup table map it to a terrain family load the matching character, screen, color, and object banks pull the drive-area and target data from shared course tablesThat is one of the clearest examples in the leak of how Nintendo kept Super Mario Kart’s content scalable without inventing a unique code path for every course.Regional BranchesThe regional structure in this archive is much broader than a simple Japan-versus-export split.The source files show a mixture of suffixes: Suffix Likely meaning Examples Base Shared or default branch kart-init.asm, Final.asm, Pause.asm -j Japanese branch Final-j.asm, Ending1-j.asm, title-j.asm -e European/export branch Final-e.asm, w-select-e.asm, record-e.asm -p PAL-era branch Final-p.asm, Pause-p.asm, ISPK-p.asm -d Debug or German-specific variant Debug-d.asm, Meter-d.asm, title-d.asm, BGunit_set-d.asm Some files only branch once or twice, while others preserve full regional stacks.The heaviest examples are: Final.asm with -e, -j, and -p variants Ending1 and Ending2 with -e, -j, and -p variants c-select and w-select with base, -e, -j, and -p variants kart-init with base, -e, -j, and -p variants title with base, -d, -e, -j, and -p variantsThat regional layering matters because it shows Super Mario Kart as a live branching project rather than a single monolithic source tree.The game was still being locally adapted screen by screen, mode by mode, and system by system.title-j.asm is a good example.It still contains explicit debug helpers for setting player, world, and rank state right from the title sequence.Final-j.asm is equally rich, preserving the full ending flow with award logic, moving clouds, paper effects, and different behavior depending on finishing rank.Some Branches Are Near-Clones, Others Still Carry Real Logic DifferencesOne nice thing about having so many parallel files is that it becomes possible to tell the difference between a true branch and a lightly relabeled copy.So far, the menu and ending code looks split into two broad groups: Branch pattern Examples What it suggests Near-structural clones title-p.asm, Pause-p.asm, Final-p.asm The branch still exists as its own source file, but the overall logic and state-machine shape remain extremely close to the Japanese or base versions Behaviorally distinct branches w-select-e.asm, c-select-p.asm The branch still carries front-end logic around unlock state, replay state, backup-RAM state, or screen-specific restore behavior title-p.asm is a good example of the first category.It keeps the same Backup_Sam_Check, Back_up_clear, rom_checker, and SET_debug flow as the Japanese and debug title branches, and it still writes game_selecta and fade_control in the same broad way.That makes it feel like a maintained branch, but not a radically different title implementation.Pause-p.asm looks similar.It still has the same big pause-state structure: Main_debug, RAM_editer_B, Save_replay, Display_VSnext, Display_GPnext, Retry_check, Change_course, and Change_kart are all still there.So the PAL pause layer appears to preserve the same “pause as front-end bridge” design rather than introducing a substantially different pause model.Final-p.asm also stays very close to the Japanese ceremony logic.It still runs AWARD_SET, Rank_Check, Message_set, Zannen_pose, Pukupuku_1 through Pukupuku_3, KUMO_move, Paper_fall_set, and Final_end_set, with Rotate_mode7 still sitting in the exit path.That suggests the award and celebration flow was stable enough by this point that the branch mainly exists to preserve a separate regional implementation, not to carry a different ending architecture.w-select-e.asm is the file that stands out most strongly in the other direction.Unlike the simpler world-select path, it keeps Old_world_number, updates the old and new cup labels separately in NMI through MOJI_Set_1, and pulls in backup-facing routines like Back_up_set, Backup_Sam_Check, Back_up_clear, and Rank_Check_sum.It also checks the stored Mushroom, Flower, and Star Cup completion bytes before allowing Special Cup to remain selected.That is a real front-end rule difference, not just translated text.So the regional split in this archive is not uniform.Some files are effectively parallel maintenance branches, while others still carry genuinely different front-end behavior around save validation, unlock conditions, or menu state restoration.Title, Menus, and Front-End FlowThe menu-side files are much richer than a simple “press start” layer.Taken together, title-j.asm, c-select.asm, c-select-j.asm, w-select.asm, k-select.asm, and Pause.asm read like one continuous front-end state machine that can move the player from attract mode into race setup, then back out again through retry, course select, or kart select.The Title Code Still Carries Debug Setuptitle-j.asm does far more than animate the logo and hand off to the next screen.Its TITL_init path calls PPU_INT_SET, Backup_Sam_Check, TENSOU_SET, PPU_title, and OBJ_ERASE, then explicitly initializes debug-facing variables like Personal_player and Rank_set.That becomes much more concrete in SET_debug.That routine draws the current debug values into OAM, lets the player step Personal_player, world_number, and Rank_set, and then copies Test_rank_data into the live point_rank table.In other words, the Japanese title branch still preserves a real title-side shortcut for forcing cup and rank state before jumping onward.The main loop is also broader than a plain menu handler.TITL_main runs Random, KEY_CHECK, and FLAG_CHECK, while the visible menu path itself goes through WINDOW_SET and GAME_SELECT.That makes the title file feel less like a self-contained title screen and more like the first front-end controller in the wider runtime scheduler.Course Select Is Also Battle Select and Replay Setupc-select.asm is effectively the race-setup router.Its dispatch tables split the screen into two families: Mode family Dispatch entries What it handles Race select_cup, select_course, map_read, map_yesno Cup choice, course choice, and the map-loading confirmation path Battle select_battle, battlemap_read Battle-map choice and the matching load path That separation is important because it shows battle mode was not bolted onto the side of the race UI.It had its own selection flow, its own map_battle table, and its own branch through the same front-end infrastructure.c-select-j.asm then makes the picture even more interesting.Its init path does Check_backupRAM, Check_replay, WINDOW_INIT, WINDOW_CONTROL, Init_meter, and DMA_meter, and it also carries Erase_timeRAM, world_lock, and keySRAM_world / keySRAM_map handling.So the Japanese course-select code is not only choosing the next track.It is also the point where replay state, key save state, and backup-RAM checks are brought back into sync before the race starts.World Select Is a Cup Screen with Trophies and Rule Gatingw-select.asm is really the cup-select screen, not just a tiny intermediary menu.Its init path builds the whole scene through WORLD_PPU and WORLD_TENSOU, then writes cup labels, trophy sprites, frame graphics, and colors directly into the menu buffers.Several details stand out: WORLD_TENSOU converts the source art into the screen format the menu needs rather than just pointing at a prebuilt tilemap the screen writes trophy markers for Mushroom, Flower, Star, and, when game_level allows it, Special Cup Cup_change.set changes world_number, calls WAKU_change_set, restores the previous cup color, then applies the new one through Color_change the Special Cup is gated through game_level, so the menu logic itself is enforcing progression rulesThe handoff is also very explicit.NEXT_SET clears race_init, triggers sound effect 002Eh, writes #02 into game_selecta, calls BGM_fade_out, and sets fade_control to 8f00h.That is a good low-level example of how menu code and the main runtime scheduler talk to each other: the front end does not launch races directly, it writes the next mode request and the transition parameters, then lets the core loop perform the switch.Kart Select Is an Animated State Machinek-select.asm is far more dynamic than a static character grid.Its main path runs VS_com_set, SELECT_SCROLL, Cursor_Move_set, Small_kart_set, Pikupiku_set, CURSOR_FLASH, KART_CHECK, NEXT_CHECK, and OBJ_MOVE every frame, while the NMI path updates demo kart DMA, cursor erasure, cursor draw, back-screen stop markers, and flashing state.That gives away a lot about how the screen is built: the karts are active object scenes with their own DMA path through DMA_demokart the cursor system keeps separate address, erase, next, and flash state instead of just redrawing one marker Select_Player and Swing_select tables drive the actual carousel order and swing offsets used by the chosen kart art timeattack_flag is threaded deeply through the code, affecting one-player versus rival setup and even the second cursor pathNEXT_CHECK makes the transition logic especially clear.Once both move_flag values settle and next_counter reaches 0040h, the code commits the selected kart IDs into driver_number, optionally mirrors one of them into timeattack_rival, then converts the current game_status into the next runtime mode.Grand Prix jumps to #0008, while VS, Time Trial, and Battle all route through #0016, after which fade_control is set to 8f00h.So even the “pick a driver” screen is not a dead-end UI.It is already performing game-state setup, rival assignment, and front-end transition scheduling.Pause Is a Front-End Bridge, Not Just an OverlayPause.asm may be the single clearest proof that Super Mario Kart’s menus and race code were designed as one connected system.PAUSE_MAIN branches through open_select, every_select, and exit_select, with separate pause-index families for Grand Prix, VS, Time Trial, and Battle.During the active pause state, Every_pause can do much more than wait for resume input: it can enter the RAM editor through RAM_editer_B it calls Main_debug it draws either Display_GPnext or Display_VSnext it checks pause_cursor, pause_index, replay_flag, and ghost_flagThe exit side is even more revealing.The retry tables can jump into: Destination Routine What it means Retry current race or advance Retry_check Chooses between RACE_RETRY and NEXT_RACE Return to title Retry_start Calls Start_title Return to course select Change_course Calls Start_C_select Return to kart select Change_kart Calls Start_K_select That is not just a pause menu.It is a live branch point back into the rest of the front end.The same pause layer also saves replay state with Save_replay, has special handling for ghost/replay flags, and can redraw the menu differently for VS/TM/BT through Display_VSnext versus GP through Display_GPnext.Once that file is read alongside the title and select code, the overall design becomes much clearer.Super Mario Kart was not built as a hard line between “menus” and “gameplay”.It was built as a shared mode system where title, cup select, kart select, race, battle, retry, and debug all talk to the same scheduler through game_selecta, game_index, and fade-control state.The Attract Demo Is a Real Runtime Scenedemo-j.asm is also worth reading as part of the front end, because it shows the attract sequence was not a cheap prerecorded movie.It is a real gameplay-side scene with its own object setup, transport path, and camera math.The clearest clues are: Rotate_mode7 talks directly to the DSP triangle routine to build a zoom-and-rotation matrix DMA_demokart increments demokart_frame and then calls the normal object transport path through OBJ_transport Set_demokart clears trans_counter, resets camera_direction, steps through active objects, and uses Set_trans_data when transfer slots are available Init_demokart mounts demo_kart objects through Mount_A, initializes their positions and pose values, and then seeds extra coins and shells through Init_demokameThat is a great low-level preservation detail.The title-side demo is not just “watch mode”.It is a miniature runtime environment built out of the same object, sprite, and projection systems as the real race code.The Regional Front End Was Still Actively DivergingThe menu files also show that front-end work was still branching late into development.title-d.asm is especially revealing, because it keeps the same Backup_Sam_Check, Back_up_clear, rom_checker, and SET_debug structure as title-j.asm.So the title-side debug path was not unique to one isolated Japanese source file.At least one other branch was still carrying the same skeleton.c-select-p.asm is equally useful because it makes the replay and ghost path very explicit.It still runs Check_backupRAM, clears replay_flag, and then calls both backup_replay and check_replay during init.Those helpers read keySRAM_world and keySRAM_map, mark selected entries in the course buffer, and use ghost_flag to distinguish backup or replay-driven state from a normal manual selection flow.That means the front-end branching was not only about translated text or PAL timing.At least some of the regional menu work was still carrying different save, replay, and debug expectations right inside the selection code.Editors, Debug, and DOS SupportThis is where the Mario Kart leak really separates itself from a normal source drop.In-Engine EditorsThe editor files are not toy leftovers.They are a layered development environment with front-end shells, specialized editing back ends, supporting data files, and disk I/O bridges.The cleanest way to read them is as four connected parts: Part Main files What they appear to do Editor front ends edit_1.asm, edit_2.asm, edit_3.asm Boot different editor modes and route control/NMI flow Map and object editors mapedit.asm, runed.asm, runed1.asm, runed2.asm, maped3.asm, maped4.asm Handle point editing, area editing, object placement, save/load, and battle-map work Editor data edit_data.asm, edmap2.asm Provide UI text, OAM layouts, HDMA tables, file-name tables, and object patterns Disk bridge ed_dos1.asm, ed_dos2.asm Turn editor save/load requests into SFX-DOS file operations That split matters because it shows Nintendo was not just carrying one debug menu.They had a small editor framework with reusable parts.The Debug Hub in edit_3.asmedit_3.asm is the best high-level overview of the whole toolset.It exports ED_init_3, ED_main_3, and ED_nmi_3, then dispatches through a large editer_select table.That table is unusually revealing.It can boot all of these modes from one place: a select or debug-mode menu a Mode 7 test a CG test a larger graphics test the actual map test, which jumps directly into map_init and map_main a title test an object demo a sound testSo edit_3.asm is not just another editor file.It looks more like an internal launcher for multiple test and content-production tools.The file also preserves some nice implementation details: it loads prebuilt screen buffers for title_screen, sound_screen, and select_screen it has dedicated NMI handlers for the select screen and sound screen it explicitly sets debug_rom_flag it includes Mode 7 buffer-flip code, character conversion helpers, and object-character setup for debug displaysThat makes it feel closer to a small internal test shell than a single-purpose editor.What the Top-Level Menu Actually DoesThe select menu in edit_3.asm is more concrete than a generic “debug mode” label makes it sound.select_main draws a text menu from select_data, tracks the current cursor in edit_point, and exposes a set of directly launchable actions: Menu path What it appears to do select_world Change world_number select_course Change map_pointer start_rase Jump straight into a normal race setup select_battleobj Adjust battle-object selection state select_battlemap Choose the current battle map start_battle Jump straight into battle mode edit1 Launch the first editor shell edit2 Launch the second editor shell m7_char Launch the Mode 7 character test cg_map Launch the color/CG test map_check Launch the map editor itself demo2 Launch the object demo sound_test Launch the sound test That matters because it shows the menu was not only for isolated graphics tests.It was also a front door into the real gameplay and editor states.The jump targets are especially clear in the code: start_rase sets race_init, game_selecta, fade_control, and fade_speed, then pushes the game into a normal race path start_battle writes the chosen battlemap into map_number, then jumps through the battle-mode setup path edit1 and edit2 reuse the same battlemap selection and then jump into the first and second editor families through game_selectaSo edit_3.asm is not just browsing internal demos.It is actively driving the same global state machine used by the real game.Screen Buffers and NMI LayoutThe shell also preserves how Nintendo staged editor UI screens in RAM.Three fixed screen buffers sit in WRAM: Buffer Address Use title_screen 7FC000h Title or title-test display data sound_screen 7FC800h Sound-test menu display select_screen 7FD000h Main debug-mode menu The paired nmi_select table is small but revealing: the select menu gets its own DMA-backed NMI handler the sound test gets a different NMI path that also calls DMA_demokart most of the other test modes do not need their own special NMI routine at allThat suggests the shell was designed around a few heavyweight UI screens and several simpler test states.The Built-In Sound TestThe sound test inside edit_3.asm is much richer than a single “play sound” stub.soundtest_init: clears the current PPU setup points the display buffer at sound_screen initializes a sprite set through Init_demokart zeroes sound-port work values and cursor stateThen soundtest_main turns the menu into a live APU-port editor.It: tracks a sound_cursor divides that cursor into a port number and bit position lets the user toggle or edit bytes and individual bits writes the results to 2140h through 2142h mirrors those writes into dummy shadow portsThat is a very strong preservation detail.The developers did not just have a menu of named tracks.They had a low-level sound-port monitor/editor for directly poking the SPC communication registers.The Graphics and Mode 7 Test ModesThe other test modes are also more practical than decorative.m7test_init clears Mode 7 VRAM, initializes the Mode 7 registers, writes a test screen, and turns the display on.cgtest_init does the same, but also fills test character data so the team could inspect how graphics and palette data behaved in Mode 7.The larger bigtest path is the most interesting of the graphics tests.It: clears VRAM converts big character art such as Mario and the other drivers into a Mode 7-friendly format flips and repacks that art with Buffer_write, M7flip, and sp_mode boots a Mode 7 display using those converted assetsThe data tables here are excellent low-level evidence.The file still names source ROM regions like OBJ_mario, OBJ_koopa, OBJ_peach, OBJ_cong, OBJ_luige, OBJ_noko, OBJ_kino, and OBJ_yossy, then assigns palette IDs and conversion parameters to each.That means edit_3.asm is preserving an internal graphics workbench, not only a generic map viewer.The Internal Utility LayerAnother reason edit_3.asm matters is that it keeps a whole bundle of reusable editor helpers in one place.The file contains routines for: cursor stepping and accelerated cursor movement bit, nibble, byte, and word editing text rendering into the debug buffers object-message rendering into OAM Mode 1 to Mode 7 character conversion with Conv_m1m7 VRAM and color writes PPU reset and Mode 7 register initialization auto-repeat input handlingThis is easy to underestimate, but it is one of the clearest signs that the editor shell was a maintained internal platform.The Mario Kart team was not writing every test mode from scratch.They had a shared mini-library for menu rendering, debug cursors, VRAM setup, and Mode 7 conversion.The Standalone Mode 7 Map Editormapedit.asm is the most self-contained editor in the archive, and it is much richer than its plain filename suggests.Its setup path shows a full in-engine workflow: choose the current course with Set_map_number copy the source map into RAM with Set_ROM_to_buffer populate BG item data with Set_BG_item convert screen/text data with Convert_m1m7 upload mode7_char, mode7_screen, and mode7_char2 blocks into VRAM initialize the Mode 7 view with Init_mode7 enter a main loop that alternates between point_edit and save_loadThe hardcoded DMA blocks are especially interesting because they show exactly how the editor expected its working data to be laid out: Block Destination Source Size mode7_char VRAM 0000h via 1900h 7f4000h 4000h mode7_screen VRAM 0000h via 1800h 7f0000h 4000h mode7_char2 VRAM 3400h via 1900h 7fc400h 0400h That is excellent preservation evidence because it turns the editor from an abstraction into a real memory map.The two-process split is just as useful: point_edit handles cursor movement, address calculation, zoom, and direct editing of map points save_load handles backup and restore using a backup_point area at 085c800hSo even at this level, the editor appears to have been built around reversible editing rather than “type once and hope for the best”.The Two Main Editor Shellsedit_1.asm and edit_2.asm are small compared to the heavier files, but they explain how the toolchain was assembled.edit_1.asm looks like the front end for the first editor family.Its main loop switches between three edit modes: AREA_DEIT CODE_EDIT POINT_EDITFrom there it chains into shared worker routines like AREA_SET, NUM_SET, POINT_SET, S.LMODE_SET, SAVE_SET, LOAD_SET, and CLEAR_SET.edit_2.asm plays the same role for the second editor family.It wires together: object or “yakumono” placement routines like YAKDAT_SET1, YAKUSCT_SET1, and YAKIDSP_SET1 direction handling with HOUKOU_SET1 save/load and disk hooks through FILE_SET2, DISK_LOAD, and DISK_SAVEThat makes the structure much easier to understand:the small edit_* files are menu shells, while the much larger runed* and maped* files carry the real editing behavior.What runed.asm and runed1.asm Are Doingruned.asm and runed1.asm are where the first editor family becomes much more concrete.runed.asm exports the first-wave setup and editing routines used by edit_1.asm.Its symbol list shows the main concerns very clearly: initialization and buffer setup position and area editing save/load mode switching menu flow actual disk save and load callsThe file also contains explicit SAVE LOAD MODE SET comments and direct calls to SAVE_FILE1 and LOAD_FILE1.That means the editor was not only modifying data in RAM.It was designed to write changes back out through the SFX-DOS layer.runed1.asm then goes deeper into specialized editing operations.The comments preserved in the file are unusually useful, because they show the kinds of content Nintendo expected to edit without opening a different program: BG1,2 SAVE LOAD SET BG1 LOAD SET SPEED LOAD SET BG2 LOAD SET multiple shape-placement helpers like square, triangle, and parallelogram load routinesThat tells us the editor was not only for placing single points or objects.It also had higher-level terrain and background editing tools, including shape-based fill or placement helpers.What runed2.asm and the ‘maped’ Files AddIf runed.asm and runed1.asm are the first editor family, runed2.asm, maped3.asm, and maped4.asm look like the heavier support side for the second one.runed2.asm exports low-level interaction routines like: POINT_SET ERASE_SET POSI_MOVE1 POSDSP_SET1 SPEED_SETThat makes it feel like the moment-to-moment editing layer: move the cursor, place data, erase data, update the display, and change parameters like speed.maped3.asm is much more presentation-heavy.It builds a large HDMA-driven editor display, exports NMI_SET1, and holds a long run of higher-level editor helpers like SAVE_SET1, MENU_SET1, LOAD_SET1, CLEAR_SET1, and DAT_SET.The most interesting part is how visual it is.It sets up multiple HDMA streams, dynamic VRAM writes, and color-window effects just for the editor UI.That suggests Nintendo wanted the content tools to be comfortably usable on real hardware, not just technically functional.maped4.asm complements that with the disk-facing and battle-facing side.Its symbol list and comments make three things stand out: explicit DISK SAVE and DISK LOAD routines explicit BATTLE_LOAD, BATTLE_SAVE, and BATTLE_ERASE a DSFN_SET2 file-name display helper that writes selected disk filenames into OAM-backed UI textThat is one of the best low-level clues in the whole editor stack.Battle content was not just another map.It had its own save/load path and its own dedicated editor support.The Separate Battle-Map Path in maped4.asmmaped4.asm is where the battle editor stops looking like a small variation on the normal course tools and starts looking like its own workflow.The first clue is that the file carries two overlapping save/load systems.The generic DISK_SAVE and DISK_LOAD paths still exist, but both immediately branch into battle-specific handlers when map_number is 14h.That means the battle map was already being treated as a special case at the top level, not only later when data got written out.The normal path looks like this: editing data lives in 7f8000h DISK_SAVE serializes that RAM into a 1c00h block and hands it to SAVE_FILE2 DISK_LOAD calls LOAD_FILE2, rebuilds the editor’s working buffers, and then redraws VRAM with DAT_SETThe battle path is different almost all the way through: placed battle objects are tracked in a separate work area at 7f8200h battle saves are staged through 7f9300h, not the normal 1c00h block BATTLE_SDISK and BATTLE_LDISK bypass the generic helper wrappers and set up the cop 16h and cop 15h file calls directlyThat split is exactly the sort of low-level detail that makes this leak so useful.The battle maps were not being stored as a trivial variant of normal track data.They had their own object list, their own staging buffer, and their own disk transfer path.How Battle Placement and Erase WorkThe live editing routines in maped4.asm are just as revealing as the save/load code.BTTLE_SET is the core placement routine.It builds battle-object patterns from yakidat, derives width and length values from PTADAT, and has a special water placement path through Water_Set11 and Water_Set1.The important part is what happens after the visual placement work.When the editor is not in save/load mode, BTTLE_SET records the placed battle object into 7f8200h.So the battle editor is maintaining its own persistent object list in RAM, rather than treating VRAM as the only source of truth.BATTLE_ERASE confirms the same design from the opposite direction.It searches that 7f8200h list by bgadd, clears matching entries, updates erasedat and eraseflg, and recalculates the object dimensions through witcnt and lthcnt.That is a stronger implementation than a simple tile paint tool.The editor was tracking discrete battle objects with metadata, placement state, and erase logic, not just rewriting background cells.What the Battle Save Format Appears to PreserveThe internal battle save/load pair is one of the clearest clues about the actual data flow.BATTLE_SAVE walks the battle object list in 7f8200h and serializes it into bank 11h, starting at 11:8200.BATTLE_LOAD does the reverse: it clears VRAM and the live object list, rebuilds the placement data from that serialized block, then replays BTTLE_SET to redraw the resulting objects.That replay step matters.The battle editor was not only restoring a raw tilemap dump.It appears to have been restoring a structured object list and then regenerating the visible map state from it.The disk-facing battle path uses a second stage: BATTLE_SDISK copies battle data into 7f:9300 it then sets filename, address, and count fields manually before calling cop 16h the count is 0c00h, which is much smaller and more fixed than the generic course-editor save pathBATTLE_LDISK mirrors that process on load.It pulls the stored block back into 7f:9300 with cop 15h, rebuilds the 7f8200h object list, then redraws the editor state by calling BTTLE_SET again.So the battle workflow seems to have three layers: a live placement list in 7f8200h a serialized in-memory form around 11:8200 a disk transfer buffer at 7f:9300That is far more elaborate than “save the current map.”It looks like a deliberately separate battle-object pipeline living alongside the normal course tools.Checksum and Validation Cluesmaped4.asm also preserves a small but important validation routine in SUM_CHECK2.That routine computes a checksum over 701000h and 702000h, then compares the result against 700ffeh.In context, it looks like editor-side RAM validation for the loaded battle or map work area, probably to catch corrupted or mismatched buffers before the rest of the tool tries to rebuild display data from them.Even that tiny detail is useful.It shows the editor was robust enough to expect failure cases, not just a one-shot internal script that assumed every load would always succeed.The Data Files Behind the EditorsThe editors are backed by two compact but revealing data modules.edit_data.asm is the small shared data pack used by edit_3.asm.It contains: select_data title_data sound_data conversion helpers like conv_data0 set_m7scr screen-layout dataThat is what makes the debug hub able to present multiple test modes cleanly instead of just dumping raw graphics.edmap2.asm is even more obviously UI-facing.It contains: OAM2 and MSB2 sprite/OAM layouts for editor text and cursors multiple HDMA tables YAKI_NO pattern tables for placeable object sets SELECTDAT1, SELECTDAT2, and MENUDAT1 text data save_numb2 tables for save slots or save areas disk_file2 and file_number2 support data for the file selectorsThe object pattern tables are a particularly nice detail.They include groups for things like question blocks, smiley or face-style tiles, arrows, walls, oil, jumps, and multiple coin frames.So the editor was not only moving abstract data around.It had a real in-engine palette of placeable course objects.How the Disk Bridge Fits InThe last important layer is ed_dos1.asm and ed_dos2.asm.These files show how the editors talked to the DOS support layer without every editor file needing to know the hardware details directly.ed_dos1.asm handles one family of editor files: FILE_SET1 cycles through save slots or file entries SAVE_FILE1 builds a filename, sets address/count fields, and triggers cop 16h LOAD_FILE1 does the same for cop 15hed_dos2.asm does the same for the second editor family, but also preserves: INIDOS_SET, which selects drive and media mode POINT_SET8, which copies stack or work pointers between RAM areas DOS_INI and DOS_INI_1, which are mostly commented out here but still show how the editor originally expected to enter the SFX-DOS environmentThe two bridge files are also a good reminder that the editors were not all saving the same kind of payload.They are preparing different address and size fields before they ever reach the DOS layer: Editor path Save area Transfer size What it suggests SAVE_FILE1 / LOAD_FILE1 0800h 0400h The first editor family writes a larger structured block SAVE_FILE2 / LOAD_FILE2 1c00h 0080h The second editor family writes a much smaller compact object/map buffer BATTLE_SDISK / BATTLE_LDISK 7f:9300 0c00h Battle editing bypasses the generic wrappers and stages its own larger transfer That is useful because it clarifies the architectural boundary.The main editor code manipulated map, object, and UI state.The ed_dos* bridge files then translated those requests into the cop-based save/load calls used by Nintendo’s SFX-DOS layer, with different transfer layouts for different kinds of editor data.Together these editor files make one larger point very clearly:Super Mario Kart was not just developed by editing source and rebuilding the game.Nintendo also had a substantial hardware-facing editor environment for placing objects, shaping course data, previewing Mode 7 output, and saving work back out through floppy-backed dev tools.SFX-DOS LayerThe older 1991 files reveal another part of the setup: a disk and I/O support layer for Super Famicom development hardware.sfxdos.asm describes itself as a Super Famicom Disk Operation System special version, programmed by Y. Nishida on 29 October 1991.Together with fileio.asm, fdcdrv.asm, sccdrv.asm, ppidrv.asm, condrv.asm, and ccp_main.asm, it preserves a real SNES-side operating layer for floppy access, keyboard and serial input, printer output, file management, and text-console interaction.That part of the leak is broader than Mario Kart itself, so it now has its own article: Super Famicom SFX-DOS Development Environment For a full breakdown of the SFX-DOS stack, the COP API, the file system layer, and the driver hardware, check out this post. For Mario Kart specifically, the important takeaway is simple: ed_dos1.asm and ed_dos2.asm were calling into a real disk operating layer the editors were saving named files through a proper file-system API, not a one-off debug stub the battle editor’s direct cop 15h and cop 16h path was still sitting on top of the same broader SFX-DOS environmentCompression, Graphics, and Data FormatsSuper Mario Kart’s Mode 7 pipeline is unusually visible in this archive.The ISPK and Compress files are the key.ISPK-j.asm and ISPK-p.asm preserve the actual decompression logic for a custom ISPK format, with entry points like Decode_7E_X and Decode_7F_X that stream data from ROM into work RAM.Compress.asm then builds on that.It exposes routines such as: Decode_M7copy Decode_M7_BF Decode_M7_buff Decode_mode7Its comments make the intended pipeline unusually explicit: compressed Mode 7 character data is unpacked into RAM buffers and then transferred onward into VRAM.That sits neatly beside the location tables in label.def.The file maps out where music, map screens, character graphics, battle graphics, color data, and object graphics live in ROM.It names concrete resources like: Title_BGM Battle_BGM MAP00_SCR through later course screen entries CIRCUIT_CHR, OBAKE_CHR, GRASS_CHR, CASTLE_CHR, ICE_CHR, DART_CHR, SAND_CHR, and STAR_CHR the matching BCH, BSC, and color tables for each course familyThat makes label.def much more than a generic include.It is effectively a hand-written ROM content index for the project.The other extensionless files play a similar role: File Role rp5a22 SNES CPU register definitions rp5c77 SNES PPU register definitions D77C25 DSP command definitions for the math/Mode 7 support hardware label Older raw register-label include used by the editor-side DOS files label_1 Save/load editor workspace definitions label_3 Larger editor workspace definitions for map/battle editing The Runtime Race PipelineThe main race path in kart-main.asm is worth calling out on its own, because it shows how the game’s heavy per-frame work is ordered.In the normal race state, Playing_process02 runs in a fixed sequence: WINDOW_CONTROL Set_position Camera_controlB OBJ_setB Official_B Set_trans_bufferB Camera_controlA Set_trans_bufferA OBJ_setA Official_A Race_control Color_effectThat is not a random collection of calls.It reveals a two-screen or two-pass mental model where camera, object setup, and transfer preparation are handled separately for A and B contexts before the race simulation finalizes world state.Then the NMI side finishes the transport work.NMI_process02 performs the VBlank-safe half of the pipeline: OBJ_transport BG_transport Race_checker Set_HDMA_parameter Screen_control Demo_camera common sound and controller work through NMI_packageThat split is one of the best low-level architecture details in the whole archive.The race engine is not only “gameplay code plus rendering.”It is a carefully staged pipeline: main-thread logic prepares positions, camera data, object state, and transfer buffers the NMI thread performs the actual VRAM/OAM/background transport and final display setupThe battle loop mirrors that shape rather than inventing a separate engine architecture.It swaps in Battle_objsetA, Battle_objsetB, and Battle_control, but the overall ordering stays recognizably the same.That makes the codebase feel much more like one shared runtime with different mode-specific control modules than a set of unrelated mini-engines.The PPU Layer Is a Split-Screen Display Enginekart-bg.asm and kart-ppu.asm make the hardware-facing side much clearer.They show that Super Mario Kart was not only preparing one Mode 7 screen and then throwing sprites on top.It was actively staging two camera contexts, two OAM states, and a timed IRQ sequence to change how the PPU was configured mid-frame.The camera side lives in kart-bg.asm.Camera_controlA and Camera_controlB both flow through Set_camera_data, which then calls: Set_camera_position Set_camera_direction Pers_parameterCamera_controlB also calls Set_double_buffer first, copying the B-side scroll, center, and background values into a second buffer before the next camera pass runs.That is a strong clue that the game was preserving multiple camera states at once, not only recalculating one set of Mode 7 registers.The background register path is equally explicit.BG_resister_A and BG_resister_B write: Scroll_0H and Scroll_0V Rotation_X and Rotation_Y Scroll_2H and Scroll_2V the extra back-screen values derived from back_2* and back_3*That means the race view was combining the Mode 7 road plane with additional scrolling background layers rather than treating the whole scene as one flat transformed bitmap.The most revealing routine is Screen_control.During VBlank it: sets the OBJ bank calls IRQ_control writes camera_flip into Screen_flip pushes nuki_color values into the color registers when needed applies the A-side background registers applies window and color-bias settings through Set_window_biasThen the IRQ path takes over later in the same frame.Regular_IRQ seeds the timer, and the later IRQ_2 and IRQ_6 handlers do the really interesting work: IRQ_2 waits for the right beam position, blanks the screen, switches the screen-flip state, writes the B-side background registers, and rebuilds OAM for screen 2 IRQ_6 restores the normal PPU control state, resets DMA sync, restores OAM for screen 1, and runs Color_transport_sSo the split-screen effect is not a simple static layout.It is an IRQ-timed display pipeline that changes scroll, window, color, and sprite state while the frame is being drawn.kart-ppu.asm shows the matching sprite and transfer side.OBJ_transport walks obj_trans_buffer in 6-byte chunks, each one describing: the destination VRAM address the source ROM address the source bank the transfer sizeThat is then fed straight into DMA channel 0 for VBlank-time uploads.The paired Set_trans_bufferA and Set_trans_bufferB routines fill those transfer queues, but they do not try to upload everything every frame.They rotate through counters, cap the number of entries, and only call Trans_mark when there is still room.That is a lovely low-level detail because it shows Nintendo throttling sprite and kart graphic uploads instead of treating VRAM as infinitely cheap.Animation and object-character updates were being budgeted across frames.The same file also keeps two separate OAM staging paths: Set_OAM_screen1 Set_OAM_screen2That fits neatly with the IRQ logic in kart-bg.asm.The game was not only maintaining two camera contexts.It was also maintaining two sprite presentation states and swapping between them as the beam moved down the screen.Taken together, these files make the graphics side feel much more concrete.Super Mario Kart’s display pipeline was built around: camera A and camera B state per-frame transfer queues for object graphics VBlank DMA into VRAM and OAM IRQ-timed mid-frame PPU changes split-screen window and color-bias control layered on top of Mode 7That is one of the clearest places in the whole leak where you can see the difference between “a game uses Mode 7” and “a commercial SNES game has a carefully engineered display pipeline.”Camera, Projection, and HUD All Live in Separate LayersThe display side becomes even clearer once Camera.asm, Screen.asm, and Window.asm are read alongside the PPU modules.Camera.asm is not the general race camera solver.It is a smaller control layer for special camera states, and it is explicitly credited to H. Yajima in the file header.Its exported routines are: Init_camera Ending_camera Stop_camera Winner_camera TV_cameraThat makes the file useful because it shows the camera system had named cinematic or state-specific overrides on top of the normal race camera path.Winner_camera, for example, sets special camera-control bits, tracks a separate goalin_offset, and gradually rotates the camera around the winning kart instead of leaving the view locked to the standard chase direction.Screen.asm then shows how world-space objects become on-screen sprite positions.Its header calls it XYZ -> HV convert, and that description is accurate.The file exports: project screen_A screen_B project_Z screen_AZ screen_BZ dist_project dist_screenThe key detail is that this path is DSP-backed.Both project and dist_project write position data to DSP_data, then the later screen_A and screen_B routines read the resulting values back and turn them into: horizontal screen position vertical screen position distance values culling decisions fallback min_patern handling when something is too far away or outside the visible rangeThat means the object layer was not doing all of its projection math in ad hoc per-object code.It had a dedicated world-to-screen conversion module, again credited to H. Yajima, feeding the sprite placement path.The split-screen logic shows up here too.screen_A and screen_B are separate routines, with mirrored handling for upper and lower views.They even preserve special back-view behavior when the player index indicates rear-view mode, flipping the horizontal placement around H_center+80h instead of the normal center.Window.asm fills in the last missing piece: the HUD and rank-window layer.WINDOW_INIT does much more than clear a small buffer.It: decodes rank or number graphics into deco_rank sets up window, color, and blend registers programs DMA channel 7 for HDMA writes into the window registers initializes window_lank data in WRAMThen WINDOW_CONTROL updates that data live from gameplay state.It reads obj_flag and rank_number for the upper and lower players, checks whether each side has reached the goal state, and switches between small and large rank-number layouts by writing different entries into window_lank.That is a great low-level detail because it means the rank display is not only a sprite overlay.It is tied into the SNES window and color-blend hardware as a separate display layer, with its own WRAM-backed HDMA data stream.So the display stack now reads very cleanly from top to bottom: Camera.asm handles special camera-state overrides kart-bg.asm prepares camera A/B scroll, perspective, IRQ, and window state Screen.asm projects world-space positions into screen-space coordinates with DSP help kart-ppu.asm queues and uploads sprite and object graphics Window.asm drives the rank and goal overlay through HDMA-backed window dataThat separation is one of the strongest technical details in the archive.Nintendo did not hide camera math, projection, sprites, and HUD logic in one giant render routine.They split them into distinct layers that each map quite neatly onto specific pieces of SNES hardware.Audio System and BGM ControlThe audio side is much richer than a simple “write song IDs to the SPC” setup.kart-apu.asm shows three different layers working together: Layer Main routines Role High-level music control BGM_control, Set_race_BGM, Set_battle_BGM, Call_bgm, Call_fanfare Choose themes, handle fanfares, final-lap changes, and queue music transitions Frame-to-frame sound dispatch Sound_set, Sound_set_trigger, Check_trigger_SE Feed the current sound command registers and queued effects to the APU Driving and event logic Engine_sound, Count_down_sound, Goal_in_sound, Start_ultra_BGM, End_ultra_BGM Turn race state into engine pitch, countdown behavior, and event-driven music changes Music Is Queued, Not Swapped InstantlyOne of the most useful details in kart-apu.asm is that BGM requests are buffered.Call_bgm does not immediately rewrite the active music.It pushes a value into bgm_buffer and increments bgm_pointer.Later, Sound_set checks bgm_pointer, trigger_pointer, and se_pointer in order, and only then writes the chosen command into the APU-facing sound registers.That means the audio system is explicitly queue-driven.Multiple pieces of logic can request music or sound changes, and the dispatcher drains those requests in a controlled order during the sound update path.That is a much cleaner design than every gameplay routine poking the SPC ports directly.The BGM Theme Selection Is Data-Driven TooSet_race_BGM and Set_battle_BGM reinforce the same theme we saw in the course loader.The game does not hardcode one song per map in scattered logic.Instead: Set_battle_BGM always selects the battle theme path Set_race_BGM uses map_type to pick an entry from a BGM_data table BGM_transport then decodes the corresponding music data into RAM and boots the APU with itThat ties neatly back into label.def, where the actual song data addresses are named explicitly: Title_BGM Battle_BGM Circuit_BGM Ice_BGM Grass_BGM Obake_BGM Sand_BGM Castle_BGM Dart_BGM Ending_BGMSo the audio side follows the same pattern as the graphics side:gameplay code selects a theme category, and the actual data addresses live in tables and labels.The Race-State Audio Logic Is Surprisingly DynamicBGM_control is where the race audio gets much more interesting.It is not only checking “are we racing?”It is watching multiple gameplay-driven counters and using them to trigger music changes: signal_counter controls the delayed handoff from the start countdown into the main race BGM finallap_counter controls the switch into the final-lap music fanfare_counter controls how long win or loss fanfares suppress the normal track themes ultra_index controls a separate special-music path that can start and stop around ultra or star-style statesThat is a strong preservation detail because it shows how much music state the game was tracking in real time.The BGM was not static background decoration.It was reacting to countdowns, race milestones, placement results, and special gameplay states.Sound Effects Are Buffered With Pan DataThe sound-effect side is just as revealing.Trigger_sound_1 and Trigger_sound_2 do not write one effect directly to the sound port and return.They push effect IDs into se_buffer and matching pan values into pan_buffer, then advance se_pointer.Later, Sound_set drains that queue and uses the pan value to decide how to write the stereo side bit into Sound2.That means the effect system was designed around: a small queued list of pending sound effects per-effect pan metadata mode-aware filtering so effects are not triggered for inactive or already-finished kartsEven the helper list is revealing.Named entry points such as Coin_sound, Jump_sound, Spin_jump_sound, Landing_sound, Dash_sound, Crash_sound, Falling_sound, Splash_sound, Balloon_sound, Lost_sound, Kame_sound, and Cursor_sound all exist as stable API hooks, even though the real queue work happens later.Engine Sound Is Part of the Driving ModelThe engine code is also much more tightly coupled to gameplay than the filename alone suggests.Count_down_engine and Check_countdown_engine read: player input game_status rank_number engine_power kart_status special_triggerThat lets the code detect wheelspin and super-start windows before the race even begins.Then the normal Engine_sound path chooses different handlers depending on game_mode, so one- and two-player states can mix engine and doppler behavior differently.That is a nice low-level reminder that the audio layer was not bolted on afterward.It was sharing real state with the kart-control model and reacting to it every frame.kart-calc.asm Is the Movement Math Layerkart-calc.asm sits underneath a lot of the files already discussed and acts as the shared math and decision layer for movement, targeting, ranking, and race progression.The two most important exports are: Calc_move_direction Calc_targetThose are the routines other modules keep leaning on whenever they need a direction or angle from one point to another.The file also imports lookup data like Sec_data and Tan_data, which makes it clear that a lot of the steering and camera math is table-driven rather than done with slow generic arithmetic each frame.That gives the rest of the codebase a common geometry language.kart-enemy.asm, kart-effect.asm, and the camera-side code are all routing through the same shared calculation layer rather than reinventing their own target-angle logic.The rest of the file reinforces that role.Alongside the geometry helpers it also carries: Calc_timer Game_control Race_checker Goalin_control All_check_rank Check_crash_mykart Check_crash_enemySo kart-calc.asm is not only “the math file.”It is also one of the main places where geometric state gets turned into race-state decisions.Calc_target is especially revealing because it shows up all over the project.It is used for: AI target steering in kart-enemy.asm target and vector work in kart-calc.asm itself effect-side steering correction in kart-effect.asm camera and background helpers elsewhere in the runtimeIt is a good example of how shared the low-level movement model really was.The game does not have one aiming system for enemies, another for drift correction, and another for camera turns.It has one core target-angle routine, then a number of systems interpreting that result in their own way.The same is true of Calc_move_direction.That routine appears to convert vector or target deltas into the discrete direction format used by kart and body state, which helps explain why so many files can exchange values like mark_direction, move_direction, body_direction, and kart_direction without needing expensive conversion code everywhere.kart-effect.asm Is the Runtime State-Machine LayerIf kart-calc.asm provides the math, kart-effect.asm provides a lot of the live state-machine glue for driving effects and moment-to-moment reactions.Its exports tell the story immediately: Tire_effect Color_effect Check_engine_status Event_control Camera_spin Spin_jump Spin_crash Fade_control Engine_power_controlThis is not a single-purpose effects module.It is a broad “what should happen to the kart and camera right now?” layer.The file is especially useful because it preserves how Nintendo grouped these behaviors together: engine-power and wheelspin handling fade and display transitions jump, fall, and out-of-bounds event states drift-state updates spin and crash reactions camera-side spin and drift behaviorSo while kart-drive.asm owns the top-level race flow, kart-effect.asm is where a lot of the local state transitions actually get expressed.The drift and spin code is one of the nicest remaining low-level details in the archive.This is not a one-bit “is drifting” flag.kart-effect.asm carries multiple fields like: drift_index drift_angle drift_pose vector_velocity camera_driftand uses them to step through different handling states over time.That is why the file exports separate routines like Spin_jump, Spin_crash, and Spin_crash_sub rather than one general “spin” helper.The game is keeping track of distinct movement phases and using those to decide: how the body should rotate how quickly velocity should decay how the camera should react when to hand control back to the normal drive pathThe same idea shows up in the ultra and engine-status handling.Check_engine_status and Engine_power_control tie wheelspin, braking, drift resistance, and engine power together instead of treating them as unrelated effects.So the “feel” of Mario Kart is not hidden in one giant physics routine.A lot of it lives in these smaller state-machine transitions layered on top of the shared movement math.Event_control Shows How Surface and Hazard States Are UnifiedOne especially helpful part of kart-effect.asm is Event_control.Its dispatch table groups several otherwise separate-looking situations into one unified event-state system: normal jump falling ghost-house pit falling lava falling water out of bounds forced movement kart lift downThat is important because it clarifies the relationship between collision and movement.BGcheck-p.asm can decide that a kart has hit a wall or gone out of bounds, but kart-effect.asm is where those conditions become timed movement states with gravity, landing behavior, and control recovery.So the overall runtime model looks more coherent after reading these two files together: kart-enemy.asm and the drive tables choose where things want to go kart-calc.asm provides the geometry, direction, and race-state calculations kart-effect.asm turns special situations like drift, spin, jump, crash, and fall into explicit state transitions kart-drive.asm keeps the wider race flow moving around themThat makes the remaining gameplay code feel much less fragmented.The separate files are not isolated tricks.They are specialized layers built around one shared movement and state model.Course Logic, AI, and Battle RulesThis is where the source stops being mostly about tools and runtime structure and starts to show the actual rule systems underneath the game.The most revealing files here are kart-enemy.asm, kart-drive.asm, BGcheck-p.asm, Item.asm, and Battle.asm.Taken together, they show a surprisingly data-driven runtime: tracks are broken into area and target tables, AI karts read those tables through shared buffers, collision pushes back through a surface-status layer, and battle mode adds a separate HP and object-state system on top.The Course Logic Uses Area and Target Tableslabel.def already hints that the course logic hangs off Drive_data_address, but kart-enemy.asm makes that concrete.Initial_enemy opens two kinds of per-course data: area data through Area_address_ROM or Area_address_SRAM target data through Target_address_ROM or Target_address_SRAMThat split matters.The course is not treated as one flat AI blob.It is divided into: an area grid that gets unpacked into area_buffer a target list that gets unpacked into target_bufferX, target_bufferY, and target_statusThe area stream is code-based and terminated by FFh, while the target stream is read as repeating position and status entries.After loading, the code even appends the first target to the end of the buffer so the path can wrap cleanly.That is a very strong clue about the runtime model.The AI is not following a hand-authored spline in code.It is moving from target to target across a course map that has already been partitioned into logical areas.The goal line is layered on top of the same system.For race maps below 14h, Initial_enemy also opens Goal_data, finds the matching area rows, and marks those cells with a dedicated goal-box bit inside area_buffer.Battle maps skip that path entirely.That suggests race and battle were already diverging at the data-layout level, not only in higher-level gameplay code.AI Steering Is Driven by Target Buffers and Rank StateThe enemy-control module is more sophisticated than a simple “rubber band” routine.Its update path is split into three passes: Pass Routine What it appears to do Pass 1 Enemy_control_100 Run event logic, update direction, and set velocity Pass 2 Enemy_control_200 Choose steering and control behavior from the current move state Pass 3 Enemy_control_300 Recompute the current drive status for tactical decisions Check_target_direction is the key bridge between course data and steering.In normal driving it can use the precomputed drive_direction table directly from the current area cell.In special states such as jumps or irregular positions, it switches to the explicit target coordinates in target_bufferX and target_bufferY and recomputes the heading through Calc_target.That is a smart hybrid design: cheap area-based direction lookup in the normal case more exact target-based direction when the kart is off the usual pathThe tactical layer sits on top of that.Check_drive_status does not just ask whether a kart is moving.It looks at: current rank whether the kart is first or last whether a player is immediately ahead or behind special states like ultra or thunder/chibi status current lap state and nearby enemy or player spacingFrom there it returns different drive states such as: normal waiting ultra-style catch-up special boosted or constrained movementThis is one of the most interesting low-level findings in the whole archive.The AI is not only “follow the path faster or slower.”It is path-following layered with rank-aware tactical behavior.Battle Maps Reuse the Path System SelectivelyThe battle data in label.def turns out to be revealing here too.Not every battle map has its own unique area and target tables: MAP14, MAP15, MAP17, and MAP18 share the same area and target base MAP16 keeps its own distinct pairThat suggests the battle layouts were not all authored with the same level of unique drive-data support as the normal race tracks.Some are clearly sharing a common base path or logic grid, even while their visual presentation differs.That looks like the same asset-reuse mindset showing up in gameplay data, not just graphics.Collision Is a Surface-State System, Not Just a Wall CheckThe surviving source for the collision side is the PAL branch file BGcheck-p.asm, but it is enough to show the general design clearly.The important routines are: BGcheck_kart BGcheck_item check_BGcheck_entry turns the current position into a lookup inside BGcheck_buffer, then uses the resulting tile or surface code to index BGstatus_buffer.That means the collision layer is working from a decoded background-status map rather than from raw graphics.The consequences are more nuanced than a simple solid or non-solid test: if an object is out of bounds, it gets an area_out flag if the current surface is marked as a mirror or crash surface, the code pushes into BG_mirror control can be temporarily disabled through _flag, _hit_timer, and _unable_control post-impact handling changes horizontal and vertical velocity instead of only stopping the kart deadThe velocity-damping logic is especially revealing.speed_chenge distinguishes between: low-speed bumps normal crashes shell or projectile-style impacts high-speed dash impactsand scales the rebound differently depending on crash side and current speed.So this is not just “did I hit a wall.”It is a compact terrain and crash-response system with out-of-bounds handling, control lockout, and different bounce strengths for different situations.Items Are Also Rank- and Target-AwareItem.asm shows the same design philosophy again.Items are not only random pickups with a single shared probability table.The enemy-fire path uses: rank_number current lap state forward or backward kart selection character-specific table_select and patern_select tablesto decide whether and what to fire.That means enemy item behavior is partly character-tuned and partly position-aware.The source also keeps distinct sound hooks like sound_kame, sound_banana, and sound_missile, which makes the whole item layer feel tightly integrated with both gameplay state and the audio queueing system we already saw in kart-apu.asm.So even the item system is more data-driven than it first appears: choose a likely target based on rank and relative position consult per-driver probability and pattern tables fire an item type through a shared movement and sound pathBattle Mode Adds HP and Dynamic Arena ObjectsBattle.asm is smaller than the editor-side battle files, but it still preserves some important gameplay-specific rules.Init_BTmode initializes battle_HP for both sides, and Check_spin watches effect flags for spin events.When a spin is confirmed, it walks the battle-object status list, updates HP, and can trigger a balloon-hit sound path through sound_balloon.That is a useful reminder that the battle system was not only “race mode with different maps.”It had its own win-condition layer tracking damage or balloon loss separately from lap progression.The same file also preserves the question-block animation path: Init_question DMA_questionThose routines advance through Question_buffer, rewrite character data in BGcheck_buffer, and update the live background display through DMA-style screen writes.That is a nice low-level detail because it shows battle arenas were not static tilemaps.At least some arena objects were being animated by rewriting their backing background data on the fly.Taken together, these files show how table-driven the gameplay layer really was.Tracks were divided into areas and targets, AI steering combined path following with rank-based tactics, collision used a decoded surface-status map, items used character- and rank-aware decision tables, and battle mode layered its own HP and arena-object rules on top.Race Completion and Result FlowThe race-end side of Super Mario Kart is almost its own subsystem.Once you put Goal.asm, Round.asm, and Result.asm together, the finish line stops looking like a single flag flip and starts to look like a layered presentation and state machine.Goal.asm Is Tiny, but Result.asm Carries the Real State MachineGoal.asm itself is surprisingly small.It is basically a thin In_goal entry that copies a block of data with MVN, then returns.The real finish logic lives in Result.asm.That file preserves separate goal handlers for: Grand Prix win, safe, and loss paths Time Trial goal and replay paths VS win and loss paths Battle win and loss pathsThe branching is explicit in the tables.goalset_A and goalset_B read the active goalstate, then use rank_jump to route rank 1 into winer_demo, ranks 2 through 4 into safe_demo, and ranks 5 through 8 into lost_demo.That is a great example of how structured the finish logic was.The game was not only checking “did the player finish?”It was immediately sorting the player into different end-of-race presentation flows based on rank and mode.Round.asm Handles the Animated Round OverlayRound.asm is another nice surprise.It is not a lap-check module at all.It is the animated ROUND overlay system that appears around the start of a race and in demo contexts.The key state variable is round_process, which dispatches through: round_off round_open round_disp sprite_erase round_closeInit_round builds the tile and OAM data in round_buffer, using data_round_a and data_round_b to lay out the ROUND text separately for the upper and lower displays.Then Main_round opens the overlay, holds it on-screen with a timer, erases the sprite side, and finally closes it again.That means the race lifecycle had its own miniature presentation controller before the player even got to lap timing and end-of-race results.Result.asm Bridges Race Logic, Presentation, and Save DataResult.asm is where the finish system becomes much more revealing.It ties together: camera changes through Stop_camera, Winner_camera, and TV_camera finish-state flags in goal_flag and result_status result messages and animated text buffers lap-time formatting the save handoff to Save_laptimeThe goal text path is especially rich.Init_goalin resets the per-screen message state, DMA_goalin pushes character data toward VRAM, and Disp_goalin builds the actual finish-time display into the moji_result buffers.That function does not only print a message.It calls Disp_laptime, which in turn calls Save_laptime, so the visible result screen and the SRAM update are directly connected.That makes the race-end pipeline much clearer: a kart enters a goal state mode- and rank-specific handlers choose the right finish path camera and object behavior switch into finish-mode presentation lap and total times are formatted into result buffers the same handoff also updates the persistent record dataSo the result screen is not just a menu layered on top of the race.It is the point where race logic, save logic, and presentation all meet.Final.asm Is the Award Ceremony ControllerThe cup-clear ceremony is much richer than a simple victory screen.Final-j.asm reads like a full presentation controller with its own timer, rank gate, camera state, paper effects, cloud motion, and shadow logic.The key routines make the structure pretty clear: Champgne_timer acts as the master award timer AWARD_SET handles the core podium and celebration setup Rank_Check decides whether the player gets a true award scene or the lower-ranked “too bad” branch Message_set and Zannen_pose handle the lower-ranked outcome Pukupuku_1, Pukupuku_2, and Pukupuku_3 handle the top-three-specific animation paths KUMO_move, Paper_fall_set, and Final_end_set keep the common background presentation moving underneath the rank-specific animationThat is a lot more than a static post-race overlay.The ceremony is being staged as its own animated scene with separate branches for podium ranks, moving background elements, and a timed handoff into the final exit path.The NMI side confirms that the scene is doing real display work too.Final_nmi writes Scroll_X, Scroll_Y, Center_X, Center_Y, and the live rotate_A to rotate_D matrix values into the SNES registers, while Final_end_set eventually calls Rotate_mode7.So the award ceremony is using the same kind of active Mode 7 camera control we saw elsewhere in the project, not just a flat congratulation screen.The Japanese Ending Is Split into Two Distinct StagesThe Japanese ending path is not bundled into one file.It is split between Ending1-j.asm and Ending2-j.asm, and those two files appear to handle very different parts of the ending presentation.Ending1-j.asm is the staff-roll choreography layer.Its two entry points, Staff_roll_A and Staff_roll_B, pick alternate layouts from ending_pattern, then feed into Staff_roll_set.From there the sequence runs through a clear staged controller: Stage Main routines What it appears to do Initial page setup Executive_position_set, Name_set Lay out the current heading block and matching name rows Motion phase Executive_position_move, Name_move Slide the current heading and name group into place Final packed page Jump_name_set Reconfigure the final page layout before the ending closes Cleanup Erase_Executive_position, Erase_name_set Remove the current page and advance to the next pattern That makes the staff roll feel far more authored than a plain text crawl.The source is positioning, coloring, moving, and erasing credits as grouped OAM data with explicit counters and per-pattern layout rules.Ending2-j.asm then takes over for the actual finale.Its timer triggers a series of staged events: early frames run Banzai_set_everydody Set_fall_moji enables the falling-text phase Set_Wave_play enables the wave sequence and updates Banzai_counter the main body keeps calling Wave_set, Noji_Fall_set, and Color_change_set the tail ends in The_End_set, driven by Fade_set, Fade_counter, and Fade_timerThe setup path in Tensou_ending2_set is just as revealing.It seeds wave acceleration, wave points, landing points, falling-text acceleration, BG3 data, thank-you sprite positions, and the fade controller before the main loop even starts.So the final scene is another real timed animation layer, not just one still image after the credits finish.Scene.asm Shows the Same Presentation Backbone UnderneathScene.asm helps make sense of all of this because it preserves the shared scene/object layer underneath the rest of the game.At the top of the file, scene_select maps every race and battle map to: a grid definition like grid_circuit0 or grid_battle4 a shared set_kart mount step an environment-specific object pack such as set_dokan, set_bubble, set_fish, set_poo, set_wood, set_ball, or set_rdossunIt also keeps type_data and level_data, then exposes the shared helpers the rest of the project relies on, including Execute_VRAM, Execute_TRANS, Set_VRAMextra, Buffer_pause, and Set_debugmap.That matters because the ending and ceremony code are not building an entirely separate renderer.They are leaning on the same project-wide scene, object-mount, and VRAM transport layer that the race and battle systems already use.The Ending Files Preserve Real Regional DeltasThe ending branch layout also reinforces the wider picture of this archive as a live multi-branch project.The source preserves: Final.asm with Final-e.asm, Final-j.asm, and Final-p.asm Ending1.asm with Ending1-e.asm, Ending1-j.asm, and Ending1-p.asm Ending2.asm with Ending2-e.asm, Ending2-j.asm, and Ending2-p.asmThat is useful in itself.Nintendo was not only localizing text strings at this point.It was still carrying separate ending and ceremony code by branch, just as it did for title, cup select, and pause.Debug Hooks and Standalone SystemsThe last group of files worth calling out are the ones that do not fit neatly into the course editor, race loop, or save system sections, but still reveal a lot about how Nintendo actually worked.Debug.asm Is a Real-Time Memory EditorDebug.asm and Debug-d.asm are much more than tiny leftover cheat hooks.They preserve a full in-game RAM inspector and editor built around debug_FLAG, debug_address, debug_cursor, and a small meter-buffer display.The input combinations are unusually explicit.The file can toggle: ON_goaldebug ON_usemeter ON_realtime ON_debugitem ON_debugmodeOnce active, the code displays the current bank and address, reads back RAM through the indirect address in debug_address, and can write modified values back through paired debug_load and debug_store handlers.That is historically useful because it shows Nintendo carrying a real-time memory editor inside the game runtime itself, not only external tooling on the dev hardware side.The Debug-d.asm branch preserves the same structure, which suggests this was not a one-off abandoned experiment.System.asm Is Shared Object-Visibility GlueSystem.asm is not flashy, but it helps explain how the object layer stays under control.The check_mode_A and check_mode_B routines gate object display based on: player mode projected distance sprite-count limits fallback map-screen behaviorIf an object is too far away or the sprite budget is already full, these routines drop it to min_patern and route into an erase or return path instead.That is a very practical low-level detail.The object system was not only projecting and animating hazards.It was continuously deciding whether each object was worth drawing at all in the current screen context.Lakitu, Missiles, Hazards, and Track Objects Each Have Their Own LogicThe smaller object files are revealing because they show how many gameplay-specific systems Nintendo kept as separate modules rather than folding them into one giant object file.Jugem.asm is the biggest example.It is effectively Lakitu’s whole rescue and race-control layer, with control sequences for: start-light behavior lap and final-lap signaling goal handling sea or water recovery takeout and comeback behavior over-out handling when the kart leaves the valid course spaceThat is a strong reminder that Lakitu was not just a sprite with a few canned animations.He was part of the actual race-state machinery, clearing official_flag, interacting with camera control, and moving players back into a valid state.Missile.asm is much smaller, but it preserves the projectile-spawn side very cleanly.open_shot uses per-direction Xoffset and Yoffset tables to place the missile relative to the firing kart, then links it to the current firing register.Pole.asm is really a collection of course-object behaviors rather than only poles.It includes logic for: fish and jumping objects Thwomp-style dossun behavior moving obstacle selection poo and flower variants ball and wood object display pathsBecause it routes those objects through project, project_Z, screen_AZ, screen_BZ, jumpset_A, and jumpset_B, it also acts like a worked example of how the general projection and object-display pipeline was reused for specific hazards.Poo.asm and Net.asm round that picture out.Poo.asm handles a dedicated poo status path and links back into the pole-object state, while Net.asm appears to manage indexed placement data for net or fence-style course objects using per-screen offsets and object-position setup.Taken together, these smaller files make one last point clear:Super Mario Kart’s runtime was highly modular.Lakitu, projectiles, heavy stage hazards, and track-side objects all had their own compact control modules, but they still plugged back into the same shared projection, collision, and display layers described earlier in the page.Backup RAM and Player RecordsThe record and backup side of the game survives unusually well here.Record.asm and record-e.asm are not vague menu helpers.They operate directly on a Backup_RAM area at 700000h, with Backup_time records stored at Backup_RAM+660H.Each course gets its own fixed record block, that block is guarded by a checksum, and the game updates best-lap and best-total tables separately.The Per-Course Record LayoutThe save layout is built around one repeated record structure per course.Check_backupRAM loops over 20 entries, and it computes the per-course address by ORing the course number with 1400h before multiplying.The address math lines up with a fixed 20-byte course record: 2 bytes of checksum at the start 5 ranked total-time entries at 3 bytes each 1 best-lap entry at another 3 bytesThat is exactly 18 data bytes plus the initial checksum word, giving 20 bytes per map.The internal comparison code makes the layout even more concrete: Offset Meaning +00 to +01 Per-course checksum +02 to +04 Fastest total time entry +05 to +07 Second-place total time entry +08 to +0A Third-place total time entry +0B to +0D Fourth-place total time entry +0E to +10 Fifth-place total time entry +11 to +13 Best-lap entry So the record system is not a general-purpose save blob.It is a very tight table of per-course time-attack data.How Validation and Default Data WorkCheck_backupRAM is one of the nicest small routines in the whole archive because it shows exactly how Nintendo treated SRAM integrity.For each course it: computes the course record address runs Checksum_map compares the computed checksum against the stored word at the start of the record reinitializes the whole course block if the check failsThe checksum itself is simple and very hardware-friendly.Checksum_map just sums the next 18 bytes after the checksum word, then stores the resulting 16-bit value back at the start of the course block.The default data is also preserved explicitly.When a course record is initialized, the code writes a sentinel checksum and then fills every time slot with the same placeholder triplet: 99 59 0AThat gives the game an obviously “bad” default time and lets the later comparison code treat any real finish as an improvement.What Gets Packed Into Each EntryEach saved record entry is only 3 bytes wide, so the game packs multiple meanings into the same fields.The low-level display and compare code shows this pattern: the first 2 bytes store the time value used for ordering the low nibble of the third byte stores the remaining small time field used in comparisons the high nibble of the third byte stores the driver identity used for the display name lookupThat is why Disp_best can decode both the time and the character name from the same tiny record.It masks the low nibble to decide whether the time is valid, then pulls the upper nibble back out and uses it as an index into the character-name table: mario luige kuppa peach cong kame kinopio yossySo the save data is not only preserving the best times.It is also preserving who set them.Best Lap and Best Total Are Separate PathsThe most interesting design choice in Save_laptime is that best-lap and best-total handling are separate, even though both live in the same 20-byte course block.The first pass scans the current race’s lap times and chooses the fastest lap from the local _round buffer.If that lap beats the stored best-lap entry, the code writes: the lap time into +11 the lap number into best_flag the driver nibble plus the minute nibble into +13That means the best-lap entry is storing more than a time.It is also encoding which lap number produced the record and which character set it.The second pass then switches to the total race time and compares it against the five ranked total-time entries.If the new total qualifies, the code: copies the whole existing 20-byte block into a temporary escape buffer finds the insertion point by walking backwards through the stored top-five list writes the new 3-byte record into the correct slot shifts the lower-ranked entries down recomputes the checksum and stores it back at the startThat insertion logic is one of the nicest low-level details in the whole file.Super Mario Kart was not just overwriting a single best time.It was maintaining a real ordered top-five table in SRAM.The Export Build Adds an Erase Pathrecord-e.asm also preserves a little extra behavior that the base Record.asm file does not expose as clearly.It exports Erase_timeRAM, which: computes the current course record address checks a flag nibble in the stored data either wipes the whole course record back to defaults or partially reinitializes the lower ranked entries and then rewrites the checksumThat is a useful regional clue.The export branch was carrying a more explicit record-erasure path, not just passive validation on boot.Where the Record Code Is UsedThe save code is not isolated in one forgotten corner of the project.It is wired into the normal game flow.Result.asm calls Save_laptime during the lap-time display path, so the SRAM update happens right where the player sees the finished times.kart-init.asm still has a Record_initial entry in its mode setup table, even if the routine itself is tiny here, and c-select-j.asm calls the backup checks from the menu side.That is a good reminder that on older console projects, menu code and result code often had to know quite a lot about persistent save structures.Taken together, these files show that Super Mario Kart’s save system was compact but carefully structured: per-course top-five total times one separate best-lap record per-entry character ownership checksum-protected SRAM blocks ordered insertion and erase logic rather than simple overwrite behaviorWhy This Archive MattersF-Zero is a beautifully tidy archive.Super Mario Kart is the opposite, and that is exactly why it is so useful.This folder preserves the game code, the regional branches, the prebuilt objects, the decompression code, the editor entry points, the backup-RAM logic, and the DOS/dev-hardware support layer in one place.For anyone trying to understand how official SNES games were actually built at a low level, that combination is the key detail.It shows Super Mario Kart not as a single frozen ROM source tree, but as a living workspace where race code, Mode 7 data handling, editor screens, save logic, and development-hardware support all still overlapped.", "excerpt": "The Nintendo Gigaleak preserves a very substantial Super Mario Kart source archive under other/SFC/ソースデータ/MarioKart. Unlike the F-Zero leak, this is not neatly split into Game and Tools. It looks much more like a live working directory copied straight out of development, with assembly source, prebuilt .rel objects, regional variants, editor...", "tags": ["snes","leak","sourcecode"], "image": "/public/generated/placeholders/super-mario-kart-source-code.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Maths for Game Developers", "url": "/maths", "content": "Vectors Vectors (Maths for Game Developers) For more information on Vectors check out this post. Matrices (Matrix)For an introduction to matrices we have a post on that topic: Matrices (Maths for Game Developers) For more information on Matrices check out this post. View Projection MatrixReversing The ViewProjection Matrix (Game Engine Reversing)The zero-irp blog features a comprehensive series by z1rp on the advanced topic of game engine reverse engineering, focusing specifically on dissecting the construction of the View-Projection Matrix.This multi-part write-up systematically covers the foundational math of 3D transformation matrices (View and Projection), techniques for finding and reversing these matrices in a running game, and detailed analysis of SIMD instructions for matrix math. The series concludes with applications like trampoline hooking to capture entity positions and explaining World To Screen (W2S) transformations. Reversing The Construction Of The View-Projection Matrix (Game Engine Reversing) z1rp presents a deep technical series on reverse engineering an AAA game's rendering pipeline, covering 3D matrix math, tracing matrix construction, and reversing SIMD operations. Quaternions Quaternions (Maths for Game Developers) For more information on Quaternions check out this post. All Posts Matrices (Maths for Game Developers) Introduction to Matrices A matrix is a table of numbers, but in game code the important part is what that table does 1. Matrices let engines package translation, rotation, scale,... ... Read More maths psp ds Quaternions (Maths for Game Developers) Introduction to Quaternions A quaternion is a four-number rotation representation, usually written as { x, y, z, w } or as a vector part plus a scalar part 1. In... ... Read More maths psp ds Vectors (Maths for Game Developers) Introduction to Vectors A vector describes magnitude and direction 1. In game code, that usually means a small structure such as Vector2 or Vector3, but the storage type is only... ... Read More maths ", "excerpt": "Vectors Vectors (Maths for Game Developers) For more information on Vectors check out this post. Matrices (Matrix) For an introduction to matrices we have a post on that topic: Matrices (Maths for Game Developers) For more information on Matrices check out this post. View Projection Matrix Reversing The ViewProjection Matrix...", "tags": ["maths"], "image": "/public/generated/placeholders/maths.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Matrices (Maths for Game Developers)", "url": "/Matrix", "content": "Introduction to MatricesA matrix is a table of numbers, but in game code the important part is what that table does 1.Matrices let engines package translation, rotation, scale, camera transforms, and projection into a form that composes cleanly and applies efficiently to many points at once 12.Matrices in games usually show up in three common shapes: 3x3 - Useful for rotation, scale, and basis changes when no translation is needed 4x4 - The standard choice for full 3D transforms because it can also encode translation and projection through homogeneous coordinates 1 4x3 - A compact affine form used by some SDKs, including the Nintendo DS, when projection is handled separatelyMatrices are useful for: Model transforms - Move a mesh from local space into world space Camera transforms - Move the world into camera space Projection - Convert 3D positions into clip or screen-friendly space Composition - Combine several transforms into one reusable matrix Batch processing - Apply one transform to many vertices, bones, or collision pointsKhan Academy’s introduction to matrices is a useful warm-up if you want a quick visual refresher on what matrices are and how to read them:If vectors are still new, it helps to read that page first because matrix math builds directly on vector operations: Vectors (Maths for Game Developers) Vectors are the building blocks that matrices transform, combine, and project. Core Matrix ConceptsIdentity matrixThe identity matrix is the matrix equivalent of multiplying by 1.Applying it leaves a vector unchanged, which is why it is the default starting point for many transform pipelines 1.This is the smallest useful example:type Vec2 = { x: number; y: number };type Mat2 = [[number, number], [number, number]];function multiplyMat2Vec2(m: Mat2, v: Vec2): Vec2 { return { x: m[0][0] * v.x + m[0][1] * v.y, y: m[1][0] * v.x + m[1][1] * v.y, };}const identity: Mat2 = [ [1, 0], [0, 1],];const velocity = { x: 3, y: -2 };const unchanged = multiplyMat2Vec2(identity, velocity);In this example unchanged is still { x: 3, y: -2 }.That sounds trivial, but it matters because identity matrices are the neutral element you compose other transforms onto.Matrix-vector multiplicationThe most important matrix operation in games is multiplying a matrix by a point or direction.That is how a local-space vertex becomes a world-space vertex, or how a world-space point becomes a camera-space point 13.This small 2D homogeneous-coordinate example shows a translation:type Vec3 = { x: number; y: number; w: number };type Mat3 = [ [number, number, number], [number, number, number], [number, number, number],];function multiplyMat3Vec3(m: Mat3, v: Vec3): Vec3 { return { x: m[0][0] * v.x + m[0][1] * v.y + m[0][2] * v.w, y: m[1][0] * v.x + m[1][1] * v.y + m[1][2] * v.w, w: m[2][0] * v.x + m[2][1] * v.y + m[2][2] * v.w, };}const translateRightBy3: Mat3 = [ [1, 0, 3], [0, 1, 0], [0, 0, 1],];const point = { x: 2, y: 1, w: 1 };const moved = multiplyMat3Vec3(translateRightBy3, point);In this example moved becomes { x: 5, y: 1, w: 1 }.The extra w lane is what lets a matrix encode translation instead of only rotation and scale.Composition and orderOne of the biggest practical lessons with matrices is that transform order matters 2.Scaling, then rotating, then translating is not the same as translating first and scaling afterward.This example shows why:type Mat3 = [ [number, number, number], [number, number, number], [number, number, number],];type Vec3 = { x: number; y: number; w: number };function multiplyMat3(a: Mat3, b: Mat3): Mat3 { return [ [ a[0][0] * b[0][0] + a[0][1] * b[1][0] + a[0][2] * b[2][0], a[0][0] * b[0][1] + a[0][1] * b[1][1] + a[0][2] * b[2][1], a[0][0] * b[0][2] + a[0][1] * b[1][2] + a[0][2] * b[2][2], ], [ a[1][0] * b[0][0] + a[1][1] * b[1][0] + a[1][2] * b[2][0], a[1][0] * b[0][1] + a[1][1] * b[1][1] + a[1][2] * b[2][1], a[1][0] * b[0][2] + a[1][1] * b[1][2] + a[1][2] * b[2][2], ], [ a[2][0] * b[0][0] + a[2][1] * b[1][0] + a[2][2] * b[2][0], a[2][0] * b[0][1] + a[2][1] * b[1][1] + a[2][2] * b[2][1], a[2][0] * b[0][2] + a[2][1] * b[1][2] + a[2][2] * b[2][2], ], ];}function multiplyMat3Vec3(m: Mat3, v: Vec3): Vec3 { return { x: m[0][0] * v.x + m[0][1] * v.y + m[0][2] * v.w, y: m[1][0] * v.x + m[1][1] * v.y + m[1][2] * v.w, w: m[2][0] * v.x + m[2][1] * v.y + m[2][2] * v.w, };}const scaleX2: Mat3 = [ [2, 0, 0], [0, 1, 0], [0, 0, 1],];const translateRightBy5: Mat3 = [ [1, 0, 5], [0, 1, 0], [0, 0, 1],];const point = { x: 1, y: 0, w: 1 };const scaleThenMove = multiplyMat3Vec3(multiplyMat3(translateRightBy5, scaleX2), point);const moveThenScale = multiplyMat3Vec3(multiplyMat3(scaleX2, translateRightBy5), point);In this example scaleThenMove becomes { x: 7, y: 0, w: 1 }, while moveThenScale becomes { x: 12, y: 0, w: 1 }.That is why APIs that expose Before and After variants are useful: they make the ordering explicit instead of forcing you to guess.3x3, 4x3, 4x4, and homogeneous coordinatesIn game math, matrix size usually tells you what kind of transform is being represented: 3x3 - Rotation, scale, or basis conversion only 4x3 - Affine 3D transform, usually rotation/scale plus translation, but not full projective math 4x4 - Full transform matrix, including projection 1The usual trick behind 4x4 matrices is homogeneous coordinates 1.Points get a final coordinate of w = 1, while pure directions use w = 0.That distinction is what makes translation affect positions but not affect direction vectors such as normals, velocity axes, or camera basis directions.TransposeTransposing a matrix swaps rows and columns 4.That sounds simple, but it matters because engines and APIs often disagree about whether basis vectors live in rows or columns, or whether matrices are meant to be read left-to-right or right-to-left.That row-major versus column-major confusion is one of the main reasons matrix code can feel inconsistent across engines even when the underlying math is the same.For example:1 2 3 1 4 74 5 6 -> 2 5 87 8 9 3 6 9In graphics code, transpose often appears when converting between storage conventions or when preparing data for another API that expects the opposite orientation 4.View and projection matricesOnce you move past model transforms, matrices also define how the camera sees the world: View matrix - Moves world-space points into camera space, often through a LookAt helper Perspective matrix - Makes distant objects appear smaller and defines a frustum with a field of view, aspect ratio, and near/far clip planes 15 Orthographic matrix - Preserves parallel lines and does not apply perspective foreshortening 1 Frustum matrix - Encodes an off-centre viewing volume directly, which is useful in lower-level rendering APIsHere is a small LookAt-style example showing the intent of a view matrix:const eye = { x: 0, y: 2, z: 5 };const target = { x: 0, y: 0, z: 0 };const up = { x: 0, y: 1, z: 0 };// A real LookAt helper would build orthonormal axes from these values// and produce a view matrix that transforms world-space points into// camera-space coordinates.In this setup the camera sits slightly above and behind the origin, looks toward the world origin, and uses positive Y as its up direction.That is exactly the kind of input later SDK helpers such as MTX_LookAt on DS or sceVfpuLookAtMatrix on PSP are designed to consume.The video below provides a visual explanation of how a perspective matrix turns a viewing frustum into clip-space coordinates and why field of view, aspect ratio, and clip planes all matter:If you want to continue from matrices into rotation-specific representations, the Quaternion page is the natural next step: Quaternions (Maths for Game Developers) Quaternions solve many of the rotation problems that become awkward with matrix-only or Euler-only workflows. Matrices can represent rotation perfectly well, but quaternions are often preferred when you need stable interpolation between orientations or want to avoid some of the bookkeeping problems that come with repeated Euler-style rotations.Matrix Libraries used in Retail Console Game DevelopmentLooking at retail SDK headers is useful because it shows which matrix operations console programmers expected to use frequently.Nintendo DS Official Matrix LibraryThe Nintendo DS boot ROM headers expose a compact matrix helper API in IrisMTX.h, which is catalogued in this site’s Platinum leak coverage 6.Before looking at the declarations, a few details stand out: Three distinct matrix shapes - Mtx, Mtx33, and Mtx44 map neatly onto affine transforms, rotation/scale-only transforms, and full projection-oriented matrices A compact affine default - Mtx is stored as 4x3, which is a strong hint that the DS SDK treated full 4x4 projection as a special case rather than the default Order-aware helpers - Functions such as TranslateBefore, TranslateAfter, ScaleBefore, and ScaleAfter make transform order explicit Quantized angle domains - Rotation helpers with 256, 1024, and 4096 variants suggest lookup-table or fixed-point style angle representations rather than plain floating-point radians Precomputed trig and fast paths - SinCos and Fast variants show the same performance-conscious flavour we already saw in the DS vector library Full camera pipeline support - LookAt, Perspective, Frustum, and Ortho show that the SDK was trying to cover the whole transform stack, not just local object movementThe split between Mtx33, Mtx, and Mtx44 is especially informative.A 3x3 matrix is enough for orientation and scale, a 4x3 matrix is enough for most model or view transforms, and the header explicitly reserves 4x4 matrices for cases such as projection.That is a very game-engine-shaped design.The 256, 1024, and 4096 rotation suffixes are also a good clue that the SDK expected developers to work with quantized turn units rather than only with conventional floating-point radians.Those variants likely correspond to different angle-resolution domains or lookup-table granularities. Here are the main storage types exposed by the header: typedef s32 MtxRow3_t[3];typedef struct { MtxRow3_t r;} MtxRow3;typedef MtxRow3 MtxRow;typedef MtxRow3 Mtx33Row;typedef vl MtxRow vMtxRow;typedef vl MtxRow3 vMtxRow3;typedef vl Mtx33Row vMtx33Row;typedef s32 MtxRow4_t[4];typedef struct { MtxRow4_t r;} MtxRow4;typedef MtxRow4 Mtx44Row;typedef vl MtxRow4 vMtxRow4;typedef vl Mtx44Row vMtx44Row;// compact 4x3 affine matrixtypedef s32 Mtx_t[4][3];typedef union { Mtx_t m;} Mtx;typedef vl Mtx vMtx;// 3x3 rotation/scale matrixtypedef s32 Mtx33_t[3][3];typedef union { Mtx33_t m;} Mtx33;typedef vl Mtx33 vMtx33;// full 4x4 matrix, used for projectiontypedef s32 Mtx44_t[4][4];typedef union { Mtx44_t m;} Mtx44;typedef vl Mtx44 vMtx44; Here are the main matrix helpers exposed by the header: void MTX_Identity(Mtx *dstp);void MTX33_Identity(Mtx33 *dstp);void MTX44_Identity(Mtx44 *dstp);void MTX_Copy( const Mtx *srcp, Mtx *dstp);void MTX_Copy2Mtx33(const Mtx *srcp, Mtx33 *dstp);void MTX_Copy2Mtx44(const Mtx *srcp, Mtx44 *dstp);void MTX33_Copy( const Mtx33 *srcp, Mtx33 *dstp);void MTX33_Copy2Mtx( const Mtx33 *srcp, Mtx *dstp);void MTX33_Copy2Mtx44(const Mtx33 *srcp, Mtx44 *dstp);void MTX44_Copy( const Mtx44 *srcp, Mtx44 *dstp);void MTX44_Copy2Mtx( const Mtx44 *srcp, Mtx *dstp);void MTX44_Copy2Mtx33(const Mtx44 *srcp, Mtx33 *dstp);void MTX_Concat(Mtx *src0p, Mtx *src1p, Mtx *dstp);void MTX33_Concat(Mtx33 *src0p, Mtx33 *src1p, Mtx33 *dstp);void MTX44_Concat(Mtx44 *src0p, Mtx44 *src1p, Mtx44 *dstp);void MTX_Transpose(Mtx *srcp, Mtx *dstp);void MTX33_Transpose(Mtx33 *srcp, Mtx33 *dstp);void MTX44_Transpose(Mtx44 *srcp, Mtx44 *dstp);void MTX_Translate(Mtx *dstp, s32 x, s32 y, s32 z);void MTX44_Translate(Mtx44 *dstp, s32 x, s32 y, s32 z);void MTX_TranslateBefore(Mtx *srcp, Mtx *dstp, s32 x, s32 y, s32 z);void MTX44_TranslateBefore(Mtx44 *srcp, Mtx44 *dstp, s32 x, s32 y, s32 z);void MTX_TranslateAfter(Mtx *srcp, Mtx *dstp, s32 x, s32 y, s32 z);void MTX44_TranslateAfter(Mtx44 *srcp, Mtx44 *dstp, s32 x, s32 y, s32 z);void MTX_Scale(Mtx *dstp, s32 xS, s32 yS, s32 zS);void MTX33_Scale(Mtx33 *dstp, s32 xS, s32 yS, s32 zS);void MTX44_Scale(Mtx44 *dstp, s32 xS, s32 yS, s32 zS);void MTX_ScaleBefore(Mtx *srcp, Mtx *dstp, s32 xS, s32 yS, s32 zS);void MTX33_ScaleBefore(Mtx33 *srcp, Mtx33 *dstp, s32 xS, s32 yS, s32 zS);void MTX44_ScaleBefore(Mtx44 *srcp, Mtx44 *dstp, s32 xS, s32 yS, s32 zS);void MTX_ScaleAfter(Mtx *srcp, Mtx *dstp, s32 xS, s32 yS, s32 zS);void MTX33_ScaleAfter(Mtx33 *srcp, Mtx33 *dstp, s32 xS, s32 yS, s32 zS);void MTX44_ScaleAfter(Mtx44 *srcp, Mtx44 *dstp, s32 xS, s32 yS, s32 zS);#define MTX_RotateX(dstp, theta) MTXxx_RotatePriv(_, X, SIN_NDIV_DEFAULT, dstp, theta)#define MTX_RotateY(dstp, theta) MTXxx_RotatePriv(_, Y, SIN_NDIV_DEFAULT, dstp, theta)#define MTX_RotateZ(dstp, theta) MTXxx_RotatePriv(_, Z, SIN_NDIV_DEFAULT, dstp, theta)#define MTX33_RotateX(dstp, theta) MTXxx_RotatePriv(33_, X, SIN_NDIV_DEFAULT, dstp, theta)#define MTX33_RotateY(dstp, theta) MTXxx_RotatePriv(33_, Y, SIN_NDIV_DEFAULT, dstp, theta)#define MTX33_RotateZ(dstp, theta) MTXxx_RotatePriv(33_, Z, SIN_NDIV_DEFAULT, dstp, theta)#define MTX44_RotateX(dstp, theta) MTXxx_RotatePriv(44_, X, SIN_NDIV_DEFAULT, dstp, theta)#define MTX44_RotateY(dstp, theta) MTXxx_RotatePriv(44_, Y, SIN_NDIV_DEFAULT, dstp, theta)#define MTX44_RotateZ(dstp, theta) MTXxx_RotatePriv(44_, Z, SIN_NDIV_DEFAULT, dstp, theta)void MTX_RotateX256(Mtx *dstp, u32 theta);void MTX_RotateY256(Mtx *dstp, u32 theta);void MTX_RotateZ256(Mtx *dstp, u32 theta);void MTX_RotateX1024(Mtx *dstp, u32 theta);void MTX_RotateY1024(Mtx *dstp, u32 theta);void MTX_RotateZ1024(Mtx *dstp, u32 theta);void MTX_RotateX4096(Mtx *dstp, u32 theta);void MTX_RotateY4096(Mtx *dstp, u32 theta);void MTX_RotateZ4096(Mtx *dstp, u32 theta);void MTX33_RotateX256(Mtx33 *dstp, u32 theta);void MTX33_RotateY256(Mtx33 *dstp, u32 theta);void MTX33_RotateZ256(Mtx33 *dstp, u32 theta);void MTX33_RotateX1024(Mtx33 *dstp, u32 theta);void MTX33_RotateY1024(Mtx33 *dstp, u32 theta);void MTX33_RotateZ1024(Mtx33 *dstp, u32 theta);void MTX33_RotateX4096(Mtx33 *dstp, u32 theta);void MTX33_RotateY4096(Mtx33 *dstp, u32 theta);void MTX33_RotateZ4096(Mtx33 *dstp, u32 theta);void MTX44_RotateX256(Mtx44 *dstp, u32 theta);void MTX44_RotateY256(Mtx44 *dstp, u32 theta);void MTX44_RotateZ256(Mtx44 *dstp, u32 theta);void MTX44_RotateX1024(Mtx44 *dstp, u32 theta);void MTX44_RotateY1024(Mtx44 *dstp, u32 theta);void MTX44_RotateZ1024(Mtx44 *dstp, u32 theta);void MTX44_RotateX4096(Mtx44 *dstp, u32 theta);void MTX44_RotateY4096(Mtx44 *dstp, u32 theta);void MTX44_RotateZ4096(Mtx44 *dstp, u32 theta);#define MTXxx_RotatePriv(xx_, axis, ndiv, dstp, theta) MTXxx_RotateNDiv(xx_, axis, ndiv, dstp, theta)#define MTXxx_RotateNDiv(xx_, axis, ndiv, dstp, theta) MTX##xx_##Rotate##axis##ndiv(dstp, theta)void MTX_RotateXSinCos(Mtx *dstp, s32 sinA, s32 cosA);void MTX_RotateYSinCos(Mtx *dstp, s32 sinA, s32 cosA);void MTX_RotateZSinCos(Mtx *dstp, s32 sinA, s32 cosA);void MTX33_RotateXSinCos(Mtx33 *dstp, s32 sinA, s32 cosA);void MTX33_RotateYSinCos(Mtx33 *dstp, s32 sinA, s32 cosA);void MTX33_RotateZSinCos(Mtx33 *dstp, s32 sinA, s32 cosA);void MTX44_RotateXSinCos(Mtx44 *dstp, s32 sinA, s32 cosA);void MTX44_RotateYSinCos(Mtx44 *dstp, s32 sinA, s32 cosA);void MTX44_RotateZSinCos(Mtx44 *dstp, s32 sinA, s32 cosA);#define MTX_RotateAxis(dstp, axisp, theta) MTXxx_RotateAxisPriv(_, SIN_NDIV_DEFAULT, dstp, axisp, theta)#define MTX_RotateAxisFast(dstp, axisp, theta) MTXxx_RotateAxisPrivFast(_, SIN_NDIV_DEFAULT, dstp, axisp, theta)#define MTX33_RotateAxis(dstp, axisp, theta) MTXxx_RotateAxisPriv(33_, SIN_NDIV_DEFAULT, dstp, axisp, theta)#define MTX33_RotateAxisFast(dstp, axisp, theta) MTXxx_RotateAxisPrivFast(33_, SIN_NDIV_DEFAULT, dstp, axisp, theta)#define MTX44_RotateAxis(dstp, axisp, theta) MTXxx_RotateAxisPriv(44_, SIN_NDIV_DEFAULT, dstp, axisp, theta)#define MTX44_RotateAxisFast(dstp, axisp, theta) MTXxx_RotateAxisPrivFast(44_, SIN_NDIV_DEFAULT, dstp, axisp, theta)void MTX_RotateAxis256(Mtx *dstp, const Vec *axisp, u32 theta);void MTX_RotateAxis256Fast(Mtx *dstp, const Vec *axisp, u32 theta);void MTX_RotateAxis1024(Mtx *dstp, const Vec *axisp, u32 theta);void MTX_RotateAxis1024Fast(Mtx *dstp, const Vec *axisp, u32 theta);void MTX_RotateAxis4096(Mtx *dstp, const Vec *axisp, u32 theta);void MTX_RotateAxis4096Fast(Mtx *dstp, const Vec *axisp, u32 theta);void MTX33_RotateAxis256(Mtx33 *dstp, const Vec *axisp, u32 theta);void MTX33_RotateAxis256Fast(Mtx33 *dstp, const Vec *axisp, u32 theta);void MTX33_RotateAxis1024(Mtx33 *dstp, const Vec *axisp, u32 theta);void MTX33_RotateAxis1024Fast(Mtx33 *dstp, const Vec *axisp, u32 theta);void MTX33_RotateAxis4096(Mtx33 *dstp, const Vec *axisp, u32 theta);void MTX33_RotateAxis4096Fast(Mtx33 *dstp, const Vec *axisp, u32 theta);void MTX44_RotateAxis256(Mtx44 *dstp, const Vec *axisp, u32 theta);void MTX44_RotateAxis256Fast(Mtx44 *dstp, const Vec *axisp, u32 theta);void MTX44_RotateAxis1024(Mtx44 *dstp, const Vec *axisp, u32 theta);void MTX44_RotateAxis1024Fast(Mtx44 *dstp, const Vec *axisp, u32 theta);void MTX44_RotateAxis4096(Mtx44 *dstp, const Vec *axisp, u32 theta);void MTX44_RotateAxis4096Fast(Mtx44 *dstp, const Vec *axisp, u32 theta);#define MTXxx_RotateAxisPriv(xx_, ndiv, dstp, axisp, theta) MTXxx_RotateAxisNDiv(xx_, ndiv, dstp, axisp, theta)#define MTXxx_RotateAxisPrivFast(xx_, ndiv, dstp, axisp, theta) MTXxx_RotateAxisNDivFast(xx_, ndiv, dstp, axisp, theta)#define MTXxx_RotateAxisNDiv(xx_, ndiv, dstp, axisp, theta) MTX##xx_##RotateAxis##ndiv(dstp, axisp, theta)#define MTXxx_RotateAxisNDivFast(xx_, ndiv, dstp, axisp, theta) MTX##xx_##RotateAxis##ndiv##Fast(dstp, axisp, theta)void MTX_RotateAxisSinCos(Mtx *dstp, const Vec *axisp, s32 sinA, s32 cosA);void MTX_RotateAxisSinCosFast(Mtx *dstp, const Vec *axisp, s32 sinA, s32 cosA);void MTX33_RotateAxisSinCos(Mtx33 *dstp, const Vec *axisp, s32 sinA, s32 cosA);void MTX33_RotateAxisSinCosFast(Mtx33 *dstp, const Vec *axisp, s32 sinA, s32 cosA);void MTX44_RotateAxisSinCos(Mtx44 *dstp, const Vec *axisp, s32 sinA, s32 cosA);void MTX44_RotateAxisSinCosFast(Mtx44 *dstp, const Vec *axisp, s32 sinA, s32 cosA);void MTX_AlignZ(Mtx *dstp, const Vec *vLookInvp);void MTX33_AlignZ(Mtx33 *dstp, const Vec *vLookInvp);void MTX44_AlignZ(Mtx44 *dstp, const Vec *vLookInvp);void MTX_QuatMtx(Mtx *dstp, const Quat *quatp);void MTX_QuatMtxFast(Mtx *dstp, const Quat *quatp);void MTX33_QuatMtx(Mtx33 *dstp, const Quat *quatp);void MTX33_QuatMtxFast(Mtx33 *dstp, const Quat *quatp);void MTX44_QuatMtx(Mtx44 *dstp, const Quat *quatp);void MTX44_QuatMtxFast(Mtx44 *dstp, const Quat *quatp);void MTX_LookAt(Mtx *dstp, const Pos *eye, const Pos *at, const Vec *vUp, Vec *vDst);void MTX_LookAtFast(Mtx *dstp, const Pos *eye, const Pos *at, const Vec *vUp, Vec *vDst);#define MTX44_Perspective(dstp, fovy, aspect, near, far, scaleW) MTX44_PerspectivePriv(SIN_NDIV_DEFAULT, dstp, fovy, aspect, near, far, scaleW)void MTX44_Perspective256(Mtx44 *dstp, u32 fovy, s32 aspect, s32 near, s32 far, s32 scaleW);void MTX44_Perspective1024(Mtx44 *dstp, u32 fovy, s32 aspect, s32 near, s32 far, s32 scaleW);void MTX44_Perspective4096(Mtx44 *dstp, u32 fovy, s32 aspect, s32 near, s32 far, s32 scaleW);#define MTX44_PerspectivePriv(ndiv, dstp, fovy, aspect, near, far, scaleW) MTX44_PerspectiveNDiv(ndiv, dstp, fovy, aspect, near, far, scaleW)#define MTX44_PerspectiveNDiv(ndiv, dstp, fovy, aspect, near, far, scaleW) MTX44_Perspective##ndiv(dstp, fovy, aspect, near, far, scaleW)void MTX44_PerspectiveSinCos(Mtx44 *dstp, s32 sinA, s32 aspect, s32 near, s32 far, s32 scaleW, s32 cosA);void MTX44_Frustum(Mtx44 *dstp, s32 t, s32 b, s32 l, s32 r, s32 n, s32 f, s32 scaleW);void MTX44_Ortho(Mtx44 *dstp, s32 t, s32 b, s32 l, s32 r, s32 n, s32 f, s32 scaleW);void MTX_MultVec(const Mtx *mult, Vec *srcp, Vec *dstp);void MTX33_MultVec(const Mtx33 *mult, Vec *srcp, Vec *dstp);void MTX44_MultVec(const Mtx44 *mult, Vec *srcp, Vec *dstp);void MTX_MultVecArray(const Mtx *mult, Vec *srcBasep, Vec *dstBasep, u32 count);void MTX33_MultVecArray(const Mtx33 *mult, Vec *srcBasep, Vec *dstBasep, u32 count);void MTX44_MultVecArray(const Mtx44 *mult, Vec *srcBasep, Vec *dstBasep, u32 count);void MTX_MultVecSR(const Mtx *mult, Vec *srcp, Vec *dstp);void MTX44_MultVecSR(const Mtx44 *mult, Vec *srcp, Vec *dstp);void MTX_MultVecArraySR(const Mtx *mult, Vec *srcBasep, Vec *dstBasep, u32 count);void MTX44_MultVecArraySR(const Mtx44 *mult, Vec *srcBasep, Vec *dstBasep, u32 count); Names like MTX_MultVecSR are also revealing.That suffix likely means “scale and rotation only”, which is exactly the distinction you want when transforming directions or normals without accidentally applying translation.You can find out more about the Nintendo DS boot ROM in the Platinum leak: Nintendo Platinum Leak For more information on the Nintendo Platinum leak that exposed these DS headers, check out this post. Sony PSP Matrix LibraryThe official PlayStation Portable (PSP) SDK exposes matrix types through psptypes.h and matrix helpers through the VFPU library header libvfpu.h 7.Compared with the DS headers, this API feels much closer to a modern graphics math layer built directly around floating-point transforms and rendering workloads.Several details stand out immediately: Float-first matrix types - The core storage types are ScePspFMatrix2, ScePspFMatrix3, and ScePspFMatrix4, which matches the PSP VFPU’s vector-oriented floating-point design 16-byte alignment on 4D data - ScePspFMatrix4 and related Vector4 types are aligned for VFPU-friendly access and bulk operations Matrix storage as vector lanes - The x, y, z, and w fields are themselves vectors, and the unions let the same data be viewed as vectors, raw float[4][4] storage, or 128-bit quads Translation as a dedicated lane - The implementation of sceVfpuMatrix4SetTransfer and sceVfpuMatrix4GetTransfer shows that the w vector is used as the translation lane in the 4D matrix form 8 A full camera pipeline - The SDK does not stop at identity, multiplication, and transpose. It also includes LookAt, perspective, orthographic, view-screen, drop-shadow, and combined transform-plus-perspective helpersThe PSP matrix API is also more explicit about the jump from algebra to rendering.Functions such as sceVfpuLookAtMatrix, sceVfpuPerspectiveMatrix, sceVfpuViewScreenMatrix, and sceVfpuRotTransPers show that the SDK was designed to help developers move directly from world-space transforms to projected screen-space results 8.As with the PSP vector library, XYZ variants usually mean “operate on the spatial part only”, so helpers such as ApplyXYZ or NormalizeXYZ treat x, y, and z as the active transform data while preserving or sidelining the w component as needed 8. Here are the main storage types exposed by psptypes.h.Like the PSP vector types, these matrices are built from named vector lanes and then wrapped in unions so the same memory can be viewed in several ways: // 2D matricestypedef struct ScePspFMatrix2 { ScePspFVector2 x, y;} ScePspFMatrix2;typedef union ScePspMatrix2 { ScePspFMatrix2 fm; ScePspFVector2 fv[2]; float f[2][2]; SceULong128 qw[2];} ScePspMatrix2;// 3D matricestypedef struct ScePspFMatrix3 { ScePspFVector3 x, y, z;} ScePspFMatrix3;typedef union ScePspMatrix3 { ScePspFMatrix3 fm; ScePspFVector3 fv[3]; float f[3][3]; SceULong128 qw[3];} ScePspMatrix3;// 4D matricestypedef struct ScePspFMatrix4 { ScePspFVector4 x, y, z, w;} ScePspFMatrix4 __attribute__((aligned(16)));typedef struct ScePspFMatrix4Unaligned { ScePspFVector4Unaligned x, y, z, w;} ScePspFMatrix4Unaligned;typedef union ScePspMatrix4 { ScePspFMatrix4 fm; ScePspFVector4 fv[4]; float f[4][4]; SceULong128 qw[4];} ScePspMatrix4 __attribute__((aligned(16))); Here are the main matrix helpers exposed by libvfpu.h.As with the PSP vector section, repeated 2/3/4 families are compacted into one representative declaration with related variants in a trailing comment: // Identity, zero, and copy#define sceVfpuMatrix2Identity(_pm) sceVfpuMatrix2Unit(_pm) // Variants: sceVfpuMatrix3Identity, sceVfpuMatrix4IdentityScePspFMatrix2 *sceVfpuMatrix2Unit(ScePspFMatrix2 *pm); // Variants: sceVfpuMatrix3Unit, sceVfpuMatrix4Unit#define sceVfpuMatrix2Null(_pm) sceVfpuMatrix2Zero(_pm) // Variants: sceVfpuMatrix3Null, sceVfpuMatrix4NullScePspFMatrix2 *sceVfpuMatrix2Zero(ScePspFMatrix2 *pm); // Variants: sceVfpuMatrix3Zero, sceVfpuMatrix4ZeroScePspFMatrix2 *sceVfpuMatrix2Copy(ScePspFMatrix2 *pm0, const ScePspFMatrix2 *pm1); // Variants: sceVfpuMatrix3Copy, sceVfpuMatrix4Copy// Apply matrices to vectorsScePspFVector2 *sceVfpuMatrix2Apply(ScePspFVector2 *pv0, const ScePspFMatrix2 *pm0, const ScePspFVector2 *pv1); // Variants: sceVfpuMatrix3Apply, sceVfpuMatrix4ApplyScePspFVector4 *sceVfpuMatrix4ApplyXYZ(ScePspFVector4 *pv0, const ScePspFMatrix4 *pm0, const ScePspFVector4 *pv1);// Matrix-matrix operationsScePspFMatrix2 *sceVfpuMatrix2Mul(ScePspFMatrix2 *pm0, const ScePspFMatrix2 *pm1, const ScePspFMatrix2 *pm2); // Variants: sceVfpuMatrix3Mul, sceVfpuMatrix4MulScePspFMatrix2 *sceVfpuMatrix2Scale(ScePspFMatrix2 *pm0, const ScePspFMatrix2 *pm1, float s); // Variants: sceVfpuMatrix3Scale, sceVfpuMatrix4ScaleScePspFMatrix2 *sceVfpuMatrix2Transpose(ScePspFMatrix2 *pm0, const ScePspFMatrix2 *pm1); // Variants: sceVfpuMatrix3Transpose, sceVfpuMatrix4Transpose// Normalization and inverse#define sceVfpuMatrix4Invers(_m0,_m1) sceVfpuMatrix4Inverse(_m0,_m1)ScePspFMatrix4 *sceVfpuMatrix4Inverse(ScePspFMatrix4 *pm0, const ScePspFMatrix4 *pm1);ScePspFMatrix3 *sceVfpuMatrix3Normalize(ScePspFMatrix3 *pm0, const ScePspFMatrix3 *pm1);ScePspFMatrix4 *sceVfpuMatrix4NormalizeXYZ(ScePspFMatrix4 *pm0, const ScePspFMatrix4 *pm1);// Rotation buildersScePspFMatrix2 *sceVfpuMatrix2RotZ(ScePspFMatrix2 *pm0, const ScePspFMatrix2 *pm1, float rz);ScePspFMatrix3 *sceVfpuMatrix3RotX(ScePspFMatrix3 *pm0, const ScePspFMatrix3 *pm1, float rx); // Variants: sceVfpuMatrix3RotY, sceVfpuMatrix3RotZScePspFMatrix3 *sceVfpuMatrix3Rot(ScePspFMatrix3 *pm0, const ScePspFMatrix3 *pm1, const ScePspFVector3 *rot);ScePspFMatrix4 *sceVfpuMatrix4RotX(ScePspFMatrix4 *pm0, const ScePspFMatrix4 *pm1, float rx); // Variants: sceVfpuMatrix4RotY, sceVfpuMatrix4RotZScePspFMatrix4 *sceVfpuMatrix4Rot(ScePspFMatrix4 *pm0, const ScePspFMatrix4 *pm1, const ScePspFVector4 *rot);// Translation lane helpersScePspFMatrix4 *sceVfpuMatrix4Transfer(ScePspFMatrix4 *pm0, const ScePspFMatrix4 *pm1, const ScePspFVector4 *ptv);ScePspFMatrix4 *sceVfpuMatrix4SetTransfer(ScePspFMatrix4 *pm, const ScePspFVector4 *ptv);ScePspFVector4 *sceVfpuMatrix4GetTransfer(ScePspFVector4 *pv, const ScePspFMatrix4 *pm);// Queries and algebra helpers#define sceVfpuMatrix2IsIdentity(_pm) sceVfpuMatrix2IsUnit(_pm) // Variants: sceVfpuMatrix3IsIdentity, sceVfpuMatrix4IsIdentitySceBool sceVfpuMatrix2IsUnit(const ScePspFMatrix2 *pm); // Variants: sceVfpuMatrix3IsUnit, sceVfpuMatrix4IsUnitfloat sceVfpuMatrix2Trace(const ScePspFMatrix2 *pm); // Variants: sceVfpuMatrix3Trace, sceVfpuMatrix4Tracefloat sceVfpuMatrix2Determinant(const ScePspFMatrix2 *pm); // Variants: sceVfpuMatrix3Determinant, sceVfpuMatrix4DeterminantScePspFMatrix2 *sceVfpuMatrix2Adjoint(ScePspFMatrix2 *pm0, const ScePspFMatrix2 *pm1); // Variants: sceVfpuMatrix3Adjoint, sceVfpuMatrix4Adjoint// Matrix and quaternion bridgeScePspFMatrix4 *sceVfpuQuaternionToMatrix(ScePspFMatrix4 *pm, const ScePspFQuaternion *pq);ScePspFQuaternion *sceVfpuQuaternionFromMatrix(ScePspFQuaternion *pq, const ScePspFMatrix4 *pm);// Camera, projection, and render-pipeline helpersScePspFMatrix4 *sceVfpuLookAtMatrix(ScePspFMatrix4 *pm0, const ScePspFVector4 *pvEye, const ScePspFVector4 *pvCenter, const ScePspFVector4 *pvUp);ScePspFMatrix4 *sceVfpuPerspectiveMatrix(ScePspFMatrix4 *pm0, float fovy, float aspect, float r_near, float r_far);ScePspFMatrix4 *sceVfpuOrthoMatrix(ScePspFMatrix4 *pm0, float left, float right, float bottom, float top, float r_near, float r_far);ScePspFMatrix4 *sceVfpuCameraMatrix(ScePspFMatrix4 *pm, const ScePspFVector4 *p, const ScePspFVector4 *zd, const ScePspFVector4 *yd);ScePspFMatrix4 *sceVfpuViewScreenMatrix(ScePspFMatrix4 *pm, float scrz, float ax, float ay, float cx, float cy, float zmin, float zmax, float nearz, float farz);ScePspFMatrix4 *sceVfpuDropShadowMatrix(ScePspFMatrix4 *pm, const ScePspFVector4 *lp, float a, float b, float c, int mode);ScePspFVector4 *sceVfpuRotTransPers(ScePspFVector4 *pv0, const ScePspFMatrix4 *pm0, const ScePspFVector4 *pv1);int sceVfpuRotTransPersN(short *pXyz, int pitch, const ScePspFMatrix4 *pm0, const ScePspFVector4 *pv1, int n); The PSP SDK function names also reveal how the library is meant to be used in practice 8: Apply and Mul map directly onto VFPU matrix-transform instructions in the source, which makes the whole API feel like a thin but useful abstraction over the hardware Transfer, SetTransfer, and GetTransfer are the PSP SDK’s names for translation helpers rather than more modern names like Translate or SetTranslation LookAtMatrix builds a camera basis from eye, target, and up vectors using cross products and normalization PerspectiveMatrix, OrthoMatrix, and ViewScreenMatrix show the full path from camera space to projected and screen-oriented coordinates RotTransPers and RotTransPersN are especially game-oriented because they combine transform and perspective divide in one step, with the N variant handling batches of pointsReferences Unity Scripting API - Matrix4x4 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 Unity Scripting API - Matrix4x4.TRS ↩ ↩2 Unity Scripting API - Matrix4x4.MultiplyPoint3x4 ↩ Unity Scripting API - Matrix4x4.transpose ↩ ↩2 Unity Scripting API - Matrix4x4.Perspective ↩ RetroReversing - Nintendo Platinum Leak ↩ Sony PSP SDK headers psptypes.h and libvfpu.h. ↩ Sony PSP SDK implementations src/vfpu/matrix2.c, src/vfpu/matrix3.c, src/vfpu/matrix4.c, and src/vfpu/perspective.c. ↩ ↩2 ↩3 ↩4 ", "excerpt": "Introduction to Matrices A matrix is a table of numbers, but in game code the important part is what that table does 1. Matrices let engines package translation, rotation, scale, camera transforms, and projection into a form that composes cleanly and applies efficiently to many points at once 12. Matrices...", "tags": ["maths","psp","ds"], "image": "/public/generated/placeholders/matrix.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Maya (Alias Wavefront, Autodesk) - The history of the Maya 3D software in the games industry", "url": "/maya", "content": "IntroductionMaya was first released in 1998 as the successor to Alias’s PowerAnimator, integrating technologies from multiple earlier tools (Alias PowerAnimator, Wavefront’s Advanced Visualizer, etc.) into a single package.It has evolved over time and in 2025 it is one of the most used 3D Modeling programs in the games industry.Version HistoryTechnically the history of Maya goes all the way back to the founding of Alias Research (by Stephen Bingham, Nigel McGrath, Susan McKenna and David Springer) back in 1983.Alias/1 (1985-1988)Alias released the first version Alias/1 at SIGGRAPH 85 where it stood out due to its use of smooth cardinal splines rather than the more traditional jagged polygonal lines 1.David Springer supervised the project that involved 300,000 lines of code written in the C programming language 1.For more information on the early history of Alias check out: 8.3 Alias Research – Computer Graphics and Computer Animation: A Retrospective OverviewAlias PowerAnimator (1988–1990s)Before Maya, Alias PowerAnimator (also just “Alias”) was Alias Research’s flagship 3D software from 1988 through the 1990s. PowerAnimator was a fully integrated 3D modeling and animation suite and became a de facto industry standard in its time, widely used in high-end film VFX and game development.Notably, it was used to create groundbreaking effects like the water pseudopod in The Abyss (1989) and the liquid-metal T-1000 in Terminator 2 1.In game development, PowerAnimator was part of Nintendo 64’s SGI-based dev kit and was used for modeling/animation on several ’90s games.Crash Bandicoot (1996) on PS1 is another example of a game whose characters and environments were built with PowerAnimator.Other titles like Wing Commander III/IV, Oddworld: Abe’s Oddysee, and Quake also leveraged PowerAnimator in their art pipelines.Maya 1.0 (1998) Maya 1.0 was released in February 1998, developed by **Alias Wavefront** (a merger of Alias Research and Wavefront Technologies under SGI). Maya’s codebase merged the best of PowerAnimator and Wavefront’s tools into a new unified application. Disney collaborated during Maya’s development, with the Disney’s Dinosaur (2000) team influencing Maya’s UI customization features.Maya 1.0 introduced a comprehensive toolset (modeling, animation, rendering, dynamics) with MEL (Maya Embedded Language) for scripting and workflow customization. This open, scriptable architecture made it extremely flexible and earned early praise from animators.Initially supporting SGI IRIX and Windows NT, Maya 1.0 enabled high-end 3D on both workstation and PC. Its debut was highly anticipated in both the film and game industries.The Matrix (1999) made extensive use of Maya for its groundbreaking effects. Game studios also began evaluating Maya for its advanced animation tools, though the 1.0 release had some growing pains (e.g. the renderer was not on par with dedicated renderers).Maya 1.5 (1998)Later in 1998, Alias|Wavefront released Maya 1.5 – an interim update primarily for SGI IRIX users. Maya 1.5 (IRIX-only) introduced some features that hadn’t made it into the initial Windows release.For example, Depth of Field (DOF) rendering, which was present in the IRIX Maya 1.5 – allowed artists to achieve in-camera focus effects (albeit with heavy render times).Being IRIX-only, 1.5 was aimed at maintaining the existing SGI workstation user base while Alias continued refining the Windows port.Maya 1.0.1 for Windows had arrived by October 1998, so by the end of 1998 both IRIX and Windows platforms were supported. The 1.5 update gave IRIX studios a boost with new rendering and animation tweaks, but was short-lived – the next major version, 2.0, was just around the corner. Maya’s rapid update cadence in this era reflected Alias Wavefront’s push to satisfy high-end users’ demands and get the young software on par with or ahead of competitor features. Maya 2.0 (1999)Maya 2.0, released in mid-1999, was a significant leap forward that addressed many of 1.x’s limitations and firmly established Maya as a top-tier 3D package. This version was released simultaneously on IRIX and Windows NT, signalling equal commitment to both platforms (critical for game studios transitioning to Windows-based pipelines).Maya 2.0 introduced vastly improved rendering and performance: it added multi-processor rendering support, so machines with multiple CPUs could finally use all their cores when rendering (Maya 1.0 had been single-threaded). It also integrated an Interactive Photorealistic Renderer (IPR) – an interactive render view allowing artists to tweak lights and shaders and see updates almost instantly, without full re-renders.Other enhancements included true Depth of Field and 3D motion blur effects in the renderer (bringing Maya closer to film-quality output), and UI improvements like the new Hypershade material editor.While Maya’s native renderer still wasn’t as acclaimed as RenderMan or Mental Ray at this point, 2.0 gave artists more control and preview capability than before.In animation, Maya 2.0 improved character setup and effects – e.g. particle systems gained the ability to instance geometry for richer effects (useful for “chunky” explosions).Reviewers noted that Maya 2.0 “puts more power in the hands of the artist” and was a big stride toward Maya becoming the leading all-in-one 3D package. The community’s reception was positive; technical directors who had used 1.0 recognized 2.0 as a “great leap forward” in functionality and a sign of Maya’s maturity. By the end of 1999, more game developers were starting to adopt Maya 2.x for its strong character animation tools, now that the platform had stabilized and performance improved.Maya 2.5 (1999)Released in November 1999, Maya 2.5 was a mid-cycle upgrade building on 2.0’s foundation. It delivered further refinements and optimizations just in time for the year 2000.While not introducing headline features as 2.0 did, version 2.5 improved overall stability and incorporated user feedback from 2.0 deployments. For example, rendering workflow saw minor enhancements, some features that debuted on IRIX 1.5 (like certain rendering options) were now fully unified across platforms.Maya 2.5 also bundled in various plug-ins and scripts (some of which were external add-ons for 2.0) into the core package – an example being render diagnostics tools to help TDs optimize scene rendering. This version readied Maya to better support large projects; indeed, major productions like Square’s animated film Final Fantasy: The Spirits Within (2001) were in development around this time and using Maya.In games, Maya 2.5 and 2.x in general were being tested in R&D teams, its strong NURBS modeling (for high-res cinematics) and growing polygon tools made it attractive alongside established tools like 3D Studio Max. Overall, Maya 2.5 smoothed the path toward the robust Maya 3.0, ensuring that early adopters’ needs were being met.Maya 3.0 (2000)Maya 3.0 arrived in early 2000 (with a 3.0.1 update in January 2001) and marked another step in Maya’s evolution.Importantly, Maya 3.0 was the first version to support Linux, reflecting the industry’s shifting interest toward Linux for CG work.The initial Linux release targeted Red Hat and came out a few months after the IRIX/Windows release, allowing studios to start deploying Maya on cheaper PC hardware running Linux for rendering and animation tasks. In terms of features, Maya 3.0 continued to refine animation and modeling: it introduced improved character skinning and deformations, and its Trax nonlinear animation editor (for blending animation clips) became more powerful.Maya’s dynamics and particles were enhanced as well, and new presets were added (e.g. quick presets for fire, smoke, etc., giving artists a starting point for effects).The software’s integration capabilities also grew, by this time Maya supported a robust plugin API and formats like OBJ and FBX to move assets between tools, which was crucial for game developers with custom engines.Community reception of Maya 3.0 was generally positive as it showed Alias|Wavefront’s commitment to rapid improvement. Even Linus Torvalds himself commented on Maya’s complexity, calling Maya 3 “the most complex and powerful 3-D application ever to run on Linux”.With stability improvements and cross-platform support, Maya 3.x was increasingly seen in game development pipelines, especially for animation and cutscene creation, at studios that could afford its high price tag.Maya 3.5 (2001)Maya 3.5 was a special release in late 2001 that for the first time brought Maya to Apple’s Mac OS X platform. Alias Wavefront ported Maya to OS X due to growing demand from graphics professionals on the Mac (since Apple’s new Unix-based OS X could handle pro 3D apps). Maya 3.5 was Mac-only (a 3.5.1 followed in 2002) and roughly equivalent to Maya 4’s feature level, but tuned for OS X.This gave Mac-based game art teams (and education institutions using Macs) access to Maya’s toolset for the first time.The Mac port included Maya’s full functionality (minus any IRIX-specific bits), proving the software’s portability.Meanwhile, on other platforms the main line jumped from 3.0 to 4.0, so Maya 3.5 can be seen as Alias’s effort to sync up Mac support.Its release was well received by Mac-oriented studios and developers; Macworld magazine noted Maya Complete 4.5 for OS X finally delivered a no-compromises 3D solution on Mac (since previously only programs like LightWave or Electric Image were on Mac).Maya 3.5 on Mac effectively broadened Maya’s user base, although in the long run Windows and Linux remained dominant in game development.Retro Games that used MayaMany influential games from the late 1990s and 2000s utilized Maya (or its predecessor PowerAnimator) in their development, the table below highlights a few notable examples of retro games and evidence of Maya’s use in their creation: Game Developer Console Proof of Maya Usage MADDEN NFL 2001 EA PS2 Maya Used In Top 4 PlayStation 2 Titles - Animation World Network SSX: SNOWBOARD SUPERCROSS EA PS2 Maya Used In Top 4 PlayStation 2 Titles - Animation World Network TEKKEN TAG TOURNAMENT Namco PS2 Maya Used In Top 4 PlayStation 2 Titles - Animation World Network Heavenly Sword Sony Cambridge Studios, Ninja Theory PS3 SONY GAMES - Heavenly Sword with Autodesk Maya and MotionBuilder.flv - YouTube Heavenly Sword (2007)The PS3 game Heavenly Sword was featured in the November 2007 issue of 3D World magazine where it mentions Maya was used with a screenshot of what appears to be a Maya (2008?) interface 2:Autodesk also produced a marketing video where they show off the use of Maya in Sony Cambridge Studios while they were working on Heavenly Sword where they mention using Maya 2008 directly 3:Need for Speed Underground (2003)In the UK Magazine PSG 24-7 issue 8 they have a preview of Need for Speed Underground which included screenshots of the car models in what looks like the default Maya viewport rendering:References 8.3 Alias Research – Computer Graphics and Computer Animation: A Retrospective Overview ↩ ↩2 ↩3 3D World magazine Issue 96 from November 2007 ↩ SONY GAMES - Heavenly Sword with Autodesk Maya and MotionBuilder.flv - YouTube ↩ ", "excerpt": "Introduction Maya was first released in 1998 as the successor to Alias’s PowerAnimator, integrating technologies from multiple earlier tools (Alias PowerAnimator, Wavefront’s Advanced Visualizer, etc.) into a single package. It has evolved over time and in 2025 it is one of the most used 3D Modeling programs in the games...", "tags": ["3d","tools"], "image": "/public/generated/placeholders/maya.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Sega Mega Drive (Genesis)", "url": "/megadrive", "content": "Welcome to our in-depth guide to Amiga reverse engineering! This page serves two roles. It groups all of our posts related to Amiga reverse engineering, and it aggregates high quality sources from the web into create a unified reference.The content starts high level, outlining the system, its history, and its official game development process, then moves into low level details with a focus on reverse engineering and homebrew development.IntroductionThe Sega Mega Drive, also known as the Sega Genesis in North America, was a popular gaming console released by Sega in 1988, and has since become a beloved classic of the gaming world.History of the Mega DriveSega Retro has an excellent page covering the history of the Sega Mega Drive in great detail, it is highly recommended that you read this before anything else: History of the Sega Mega Drive - Sega Retro Find out about the history of the SEGA Mega Drive in this excellent post How Sega bet against Reverse Engineering…and lostModern Vintage Gamer has an excellent video about the history of reverse engineering on the Sega Genesis. It covers the technical and legal strategies used by Electronic Arts and Accolade to bypass the console’s TMSS security chip, detailing how clean-room reverse engineering led to a landmark court ruling for software interoperability.Are there any Mega Drive Reverse Engineered games or active projects?Before diving in its best to check if there are any existing reversing projects for the Sega Mega Drive that you can contribute to, check out our other post specifically on this topic: Decompiled Retail Console Games For the list of decompiled games check out this post. What are the games exclusive to the Sega Mega Drive?There were many exclusive games for the Mega Drive and the various hardware add-ons that were released for it, these are ideal targets for reverse engineering and porting to other platforms: Sega Mega Drive - Sega Genesis-only games - Wikipedia Sega 32X - Sega 32X-only games - Wikipedia Sega CD - Sega CD-only games - WikipediaHardwareIf you’re interested in reverse engineering software for the Sega Mega Drive gaming console, it’s essential to have a strong understanding of the hardware that powers it. By comprehending the inner workings of the Mega Drive hardware, you can better understand how the software interacts with the hardware and how you can potentially modify or enhance it.In this section of our guide, we will provide you with detailed information and resources on the hardware of the Sega Mega Drive, including retail, prototype, and development hardware.Development HardwareIn order for game developers to create software for the SEGA Mega Drive, they had the choice of a number of different development hardware to purchase, or they could go it alone and create their own hardware. To find out more check out the post below. Sega Mega Drive (Genesis) Development Kit Hardware For information about SEGA’s Mega Drive development hardware check out this post. Sega Digitizer SystemThe Sega Digitizer System was a development kit specifically for creating sprites and background tiles officially inside SEGA. It is unclear if they ever sold the system to third party developers. It required a NEC PC-98 for development which was the ideal choice for many game developers in japan.It had a rudimentary touch screen with a pen allowing artists to “draw” pixels directly on the screen.This was not exclusive to Mega Drive development, it was also used in early sega arcade games, system 1 and system 16 (1986).You can find out more including lots of images on Video Games Densetsu: The Sega Digitizer System, a tool used by graphic…Mega Drive Game Software DevelopmentThe Mega Drive Game development processWhat programming languages were used to create games for the Sega Mega Drive?Although almost all Mega Drive games were written in 68K assembly there is one known commercial Mega Drive game to be written in C, Sonic Spinball 1!What computers were used to write Mega Drive games?Popular choices for computers for writing Mega Drive games in Japan were the Sharp X68000 (it shared the same processor) and the Intel 8086 based NEC PC-9801. In the UK the Amiga was a very popular choice for writing Mega Drive games due to it being based on the same 68000 CPU.The Sharp X68000 is known to have been used at Game Arts 2 and is a smart choice as the assembly code can be tested out on the hardware directly and only required the Mega Drive development kit for testing the graphics and sound capabilities. So game logic could be tested more efficiently.The NEC PC-9801 is known to have been used at SEGA of Japan thanks to the Sound-Source leak 3.Porting From AMIGA to MEGA DRIVE - with Stoo Cambridgeonaretrotip has an excellent interview with Stoo Cambridge about porting Amiga games like Megalomania and Sensible Soccer to the Sega Mega Drive. It covers the technical similarities (shared 68000 CPU) and differences (bitmap vs. tile-based graphics), as well as specific tricks used to overcome the Mega Drive’s color limitations, such as overlaying playfields to simulate 32-color intro screens.How large were Mega Drive game development teams?The development of the game Alien Soldier and other games by Treasure had only 4 people working on it, 2 programmers and 2 game designers which we found out in a translated interview with Masato Maegawa4: In the early 90s, for our Megadrive developments, all our developments were done with 2 programmers and 2 designers max. Alien Soldier, in fact, started out with just one person, NAMI, who took on the role of both designer and programmer.How long did it take to develop games for the Mega Drive back in the day?At Treasure (e.g Alien Soldier) Masato Maegawa reveals that it takes around about 10 months but that more complicated games could last 2 years 4: In the Megadrive days we took about 10 months for a game; now it’s about 15 months. There were some titles that took us a full 2 years, though.Although he also revealed that there was a tight development cycle for Alien Solider as the deadline was January 3rd 1995 and they were working through the New Year switch.What did a Mega Drive Design Document look like?Hardcore Gaming 101 has a video showing the design document created for the Mega Drive game MUSHA:Mega Drive Software Development KitTo find out about the Official SEGA Mega Drive Software development Kit check out our page on the topic: Sega Mega Drive (Genesis) Software Development Kit (SDK) For information about SEGA’s Mega Drive software development kit check out this post. In-House Development SoftwareIt was common in the industry to develop custom software in-house to make the game development process easier not just for the current game but also future games targetting the same hardware.DARI and KETCHUP (Game Arts)For the development of the Mega Drive game Alisia Dragoon, Game Arts created some in-house development software called KETCHUP and DARI: KETCHUP was used for editing maps and defining the pattern of enemy movements by configuring basic curves in the editor, as can be seen in the image below 2. DARI was used for editing animated Sprites for games targetting both Mega Drive and Sharp X68000 systems:In the image below you can see the Main Programmer Naozumi Honma on the left and Assistant Programmer Osamu Harada on the right along with their Sharp X68000 development computers (and Mega Drive controller presumably hooked up to a development kit) 2:Assembly Language programmingBasics of 68K AssemblyIn an interview with Computerphile the Tanglewood developer Matt Phillips explains the basics of how assembly language programming works for creating Mega Drive games:In the video he uses Windows 95 and Notepad++ to edit the assembly files, which are then assembled using the MS-DOS command:snasm68k /sdb test.asm, test.cofYou can see it being assembled in the screenshot:It is then loaded into the SNASM debugger (V2.0) on a SNASM Mega CD Development Kit, which connects to the PC via an ISA card and SCSI cable.Code Your Own Sonic GameThe Youtuber Game Hut has a series of tutorials on Sega Mega Drive programming.Part 1:Part 2:All Posts The Motorola 68000 - Powering the Gaming Revolution The Motorola 68000 - Powering the Gaming Revolution Introduction The video game industry has witnessed remarkable technological advancements throughout its history, with one pivotal component that played a significant role... ... Read More hardware megadrive atari cpu Sega Mega Drive (Genesis) Development Kit Hardware The SEGA Mega drive was released on October 29th 1988 in Japan following with North America almost a year later and Europe another whole year later than that! During its... ... Read More devkit hardware megadrive crossproducts snsystems Sega Mega Drive (Genesis) Software Development Kit (SDK) Sega Mega Drive (Genesis) SDK Unlike the original Master System or SG-1000 systems, SEGA provided third party developers with some tools to make Mega Drive development easier. Files leaked There... ... Read More sdk megadrive 32x crossproducts snsystems How Retro Cartridges (ROMS) work Have you ever wondered what exactly is inside those retro game Cartridges (ROMs)? In this post we will find out the purpose of ROM cartridges and how they worked. Advantages... ... Read More introduction hardware nes snes n64 megadrive mastersystem Working at SEGA Documentary Working At SEGA Documentary This rare documentary was part of Careers for the 21st Century by Takeoff Multimedia, it shows what life was like as a developer working at SEGA... ... Read More industry documentary megadrive sega References Interview: Peter Morawiec (2007-04-20) by Sega-16 - Sega Retro ↩ Alisia Dragoon – 1992 Developer Interview - shmuplations.com ↩ ↩2 ↩3 News/Sega of Japan Sound Documents and Source Code - Hidden Palace ↩ Alien Soldier – 1995 Developer Interview - shmuplations.com ↩ ↩2 ", "excerpt": "Welcome to our in-depth guide to Amiga reverse engineering! This page serves two roles. It groups all of our posts related to Amiga reverse engineering, and it aggregates high quality sources from the web into create a unified reference. The content starts high level, outlining the system, its history, and...", "tags": ["megadrive","sega"], "image": "/public/generated/placeholders/megadrive.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Sega Mega Drive (Genesis) Development Kit Hardware", "url": "/sega-mega-drive-genesis-development-kit", "content": "The SEGA Mega drive was released on October 29th 1988 in Japan following with North America almost a year later and Europe another whole year later than that!During its lifespan it became incredibly popular especially in Brazil and European markets where it lasted long after the death of its successor the Saturn.Official Development KitsSEGA provided developers with different options for developing games for the platform throughout the years, starting with their Super Mega Drive and eventually leading to the distribution of Cross Products SNASM development kits.Below is the photo containing the only information we have on the pricing of the development kit:Super Mega Drive Development console There is very little information out there about the Super Mega Drive but a manual was leaked thanks to the techdocs.exodusemulator.com website. This gives the information that it would be a Mega Drive console with the ability to use a In-circuit emulator such as the ZAX ICE to debug game code. At first glance it might seem that it was built by Sega Ozisoft due to the copyright notice that is on every page, however there is another version where the copyright notice is instead changed to “The Code Monkeys”. Both Sega OziSoft and “The Code Monkeys” were games studios that developed games for the Mega Drive, so it is likely that Sega printed different versions of the user manual each with a watermark of the company they sent it to. It is believed that this was the first development kit that Sega produced in the early years of the Mega Drive and that it was fairly quickly replaced with others such as the Cross Products SNASM. There was no known images of this rare development kit online until Phil Bennett (@PhilBennett3D) posted one of my favourite tweets which you can see below:What's this? Why it's a Super Mega Drive, Sega's Mega Drive development system. (1/) pic.twitter.com/Jl29Bj3pOw— Phil Bennett (@PhilBennett3D) June 20, 2021ZAX ER308 ICE for Z80 (Sound) The ER308 was a In-Circuit-Emulator (ICE) developed by ZAX Corporation for developing Z80 assembly programs. Sega officially distributed these for Sega Mega Drive development due to the sound chip being a Z80 processor 1. Interestingly this piece of hardware required not one but two ISA cards to be in a developers PC in order to communicate with the ICE 1. The ICE would allow developers to set breakpoints, step through instructions and trace programs but don’t expect audio or graphics output, this is literally just for tracing the execution of the CPU to test programs. Zax Corporation - Sega Retro For more information about the ZAX corporation checkout this excellent Sega Retro page ZAX ERX 318P ICE for Motorola 68K There was another ZAX ICE for the Motorola 68k processor which would provide the same functionality as the Z80 one but for the main Mega Drive processor. This would have most likely been the way most Mega Drive game programmers debugged their main game logic. Mega Drive Loader (171-5734) The SEGA Mega Drive Loader was a connector for transferring data from a developers PC to the Mega Drive console. It connected to the controller port on the console and the printer port of the PC. It was mainly used for downloading ROM files to the ICE unit to be played on the console. Mega Drive Address Checker (171-6286) The SEGA Mega Drive Address Checker was a development tool used to check the integrity of software for the system. It warned the user of any writes to invalid memory addresses, which is a very useful debugging tool and useful for SEGA itself to make sure cartridges are of a quality enough to produce. Prototype CartridgesIn order to QA the game and send out promotional copies to magazines or other media publications, prototype cartridges were sold by SEGA that contained slots for EPROMs to be burned.4Meg ROM Board A (171-5694-01) The 4Mb ROM board is the most common to find today as it was distributed to media companies, especially games magazines. The developer would use an EPROM writer to write each of the chips and then place them inside the cartridge. SEGADEV SRAM Sega Mega Drive Development Cartridge The Sega Dev Card by Western Technologies was a development kit that functioned in a similar way to modern day Flash Cartridges. It connects to the developers PC (running MS-DOS) via a port on the back of the cartridge 2. Western Technologies created the 2MB RAM cartridge that was then distributed by SEGA to developers. This development cartridge has a port on it to connect to a development PC to load data into the RAM chips 1. Apparently the two 8KB EPROMS you can see are for a bootloader program. So if you are considering buying one of these please remember that there will be no prototype games on them due to it being SRAM based. The data is gone as soon as it is disconnected.</div></section> The developer could run SEGALOAD GameName.bin to load a compiled Sega Mega Drive game ROM file. It can also debug games using breakpoints and memory dumps 2. Official Development Kits for Mega Drive Addons The SEGA Mega drive is one of the most upgradable consoles ever on the market due to SEGAs initiatives to keep the hardware up to date with up coming 32-bit systems. Sega Virtua Processor (SVP) Dev Board (171-6666A) The Sega Virtua Processor was an additional processor for handling 3D geometry contained inside the mega drive cartridge itself. You can think of this as SEGAs answer to the superFX chip. In order to develop games that used this new processor, development hardware has to be created with the processor on board. The SVP Dev board was just that, it had the SVP processor along with slots for EPROM chips to be inserted with the custom game code. MegaCD CTrac CD Emulation System The CTrac CD Emulation system was developed by ICOM Simulations and distributed officially by SEGA. As the name suggest it emulates a CD drive, instead using the hard drive of the developers PC to stream content to the Mega CD. This was also used for the Cross Products Mega-CD development kit and you can see more details about both in the following video. Third Party Development Kits SEGA were not the only distributer of development kits for the SEGA Mega Drive, British-based companies such as SN Systems and Cross Products dominated the marked in the UK. Cross Products SNASM 68000 The SNASM 68K was Cross Products first development kit for a SEGA console and it was hugely popular! So popular that SEGA purchased Cross Products outright and they became the official creator of development kits for every SEGA system since. SNASM68K was part of an overall product suite known as SNAM which had development kits for most of the major consoles at the time including the SNES. Note that the SNASM68K was not just development hardware but in fact contained the very popular SDK toolchain also called SNASM68K. SEGARetro.org has an excellent page on the development kit: SNASM68K - Sega Retro The SNASM 68K lasted until late 1993 when it was then replaced with version 2 of the suite aptly called SNASM2. Cross Products SNASM2 Suite In November 1993 Cross Products teamed up with SEGA to produce the sequel to their popular SNASM68K development kit named SNASM2. There were multiple flavours of the SNASM2 development kits, one with a SEGA Mega-CD built in and another for 32X development. Cross Products SNASM2 Mega-CD development Kit The SNASM2 Mega-CD kit is one of the most commonly seen Mega Drive developments kits and has been used recently to create the game Tanglewood. In fact you can even see the Tanglewood developer Matt give an overview of the hardware in a video for Computerphile: For even more details about the Mega-CD development kit check out the video below. Cross Products SNASM2 32X development kit In Issue 17 of the UK Magazine EDGE there is a full-page advert for the 32X version fo the SNASM2 suite. Psy-Q Development Kit (Plus 32X support) SN Systems were a well known company in the UK for producing development kit hardware and so they jumped at the chance to develop a kit for the Sega Mega Drive. Common to most of their other development kits they tend to be extensions of the retail hardware with custom cartridges placed in the console with a connected to the developers PC for sending ROMS down to the console. Nicholas Cottrill has some excellent photos of the Psy-Q Mega Drive hardware on his Flickr:Psy-Q Mega Drive/Mega CD and 32X by Nicholas Cottrill | Flickr The Mega Drive setup - that card looks sussssssspiciously similar, so I have my hopes up.I think this is the setup @Psycatic used for his Invaders game. pic.twitter.com/I7teIze9MG— Matt Phillips (@bigevilboss) June 21, 2019 In-House development Kits Even with the wide variety of development kits on the market for the SEGA Genesis some companies prefered to create their own development kits. SPROBE by Electronic Arts (EA) Developed for Electronic Arts in 1989, the SPROBE combines a Sega Mega Drive and a development board. Latching onto the Mega Drive cart interface, it adds a cartridge emulator as well as a debug / development capability using a PC card link.This hardware is one of the reasons for EA’s early dominance in Sega Genesis gaming 3. There used to be a video showing off this hardware on Youtube by AssemblerGames, however it has since been deleted. There is an EA SPROBE development kit in the Museum of Play collection: You can see the inside of the SPROBE development kit below: References ZAX Z80H in-circuit emulator / ER308 / ERX 308P - Forums - SMS Power ↩ ↩2 ↩3 Western Technologies Sega Dev Card Demo - YouTube ↩ ↩2 Rare video game hardware: The SPROBE Megadrive development system - YouTube ↩ ", "excerpt": "The SEGA Mega drive was released on October 29th 1988 in Japan following with North America almost a year later and Europe another whole year later than that! During its lifespan it became incredibly popular especially in Brazil and European markets where it lasted long after the death of its...", "tags": ["devkit","hardware","megadrive","crossproducts","snsystems"], "image": "/public/images/megadrive/Sega Mega Drive Genesis Devkit.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Sega Mega Drive (Genesis) Software Development Kit (SDK)", "url": "/sega-mega-drive-genesis-sdk", "content": "Sega Mega Drive (Genesis) SDKUnlike the original Master System or SG-1000 systems, SEGA provided third party developers with some tools to make Mega Drive development easier.Files leakedThere are still Sega Mega Drive SDK files that have never been archived or released on the internet unfortunately, so this post will only cover the files we have access to.The following files have been released to the internet over time: Sega Mega Family.7z - Documentation PDFs for 32x, Mega CD and Sound development and the 32X SDK Sega SDK.zip - Similar to the first archive but the documentation are individual gifs for each documentation page, also contains mainly Saturn SDK files, no point in downloading this if you are only interested in Mega DriveOfficial Sega Mega Drive Software Development KitThe files in this section are from the Sega Mega Family.7z archive as they are much easier to use when in pdf format. The Sega SDK.zip archive contains the same contend but each page is a separate .gif file.What is missing?Before we look at the files we have access to lets have a look at the files that are known about but that have never been archived.Macintosh Based toolsSEGA developed some tools for Apple Macintosh computers for editing sound and potentially graphics too. Midi2Bin32X - Converts MIDI to BGM compatible binary file SeConv32X - Converts MIDI to Sequence Data for the 32X Sound Simulator Midi2Txt32X - Converts MIDI to BGM compatible text file 32X Sound Simulator - Tone Editor 32X - Creates and Edits MIDI filesStandard Mega Drive/Genesis DocumentationThe only documentation we have for the standard (non add-on) Sega Mega Drive development are: Genesis Software Manual - Created in 1989 contains documentation on Memory Maps, Interrupts, VDP, DMA, backwards compatibility and I/O Sega Software Development and Game Standards.pdf - 9 page guide to what needs to be in your game in order to get approval from SEGA, including a requirement for demonstration to play if the user doesn’t press startFor low level technical information about how the Genesis works the Genesis Software Manual document is worth a read, but it’s not information that you can’t find in a better form elsewhere.The Game standards document (Sega Software Development and Game Standards.pdf) is an interesting read, it is surprising how specific the game standards were, and it is why so many games looked the same during the startup and title screens. It even includes specifications for Continue/Game over sections and a password screen.Sound DocumentationThe Sega Mega Family.7z archive contains a few interesting documents on how Sound was produced for the Sega Mega Drive, which are listed in the table below. Name Description 68000 Sound Driver Ver 3.00.pdf Documentation for the 32x sound driver (PCM) Genesis Sound Software Manual.pdf Contains Z80 memory Map, how to communicate with the Main 68K CPU, envelope specification and Programmable Sound generator information MIDI Converter Ver 1.30.pdf Documentation for a few Macintosh tools that convert standard MIDI files into multiple formats Development Cartridge DocumentationIn order to test games on the retail Genesis hardware a few development cartridges were sold to developers which act like flash cartridges.In the Sega Mega Family.7z archive there are three manuals for these cartridges listed in the table below. Name Description IC BD 16M 42 PIN 4 EPROM 32X RD 837-11070 User’s Manual.pdf Documentation for the 16Mbit EPROM based development cartridge for the 32X IC BD 32M SRAM + 256K BUP 32X RD 837-11068 User’s Manual.pdf documentation for the SRAM based development cartridge with 32Mbit of space IC BD 4M 32 PIN 8 EPROM 32X RD 837-11069 User’s Manual.pdf Documentation for the 32Mbit EPROM based development cartridge for the 32X Official Sega BulletinsThe folder Bulletins inside the archive contains a number of scanned emails that SEGA of America sent out to all registered Genesis developers. Name Description Addendum Contains a few additional specifications, including custom joysticks via the I/O port, DMA, H-Blank and V-Blank interrupts and details about communication between Z80 and the 68K Cinepak Contains an email sent to Sega Developers in 1994 about Cinepak version 1.2, which must now be used for all future games. This was presumably only for Mega CD and Saturn developers as Cinepak is a video library Gen-tech Scanned emails from 1991 giving newer information to all Mega Drive developers. Includes assembly code listings for some examples. MCD-tech SEGA CD specific technical bulletins including information on the US BIOS, information on CD writers and discs, and corrections to the Mega CD documentation Misc Information about the Super Target hardware and corrections for the software guidelines. The most interesting emails are in the Gen-tech folder as they are the earliest known documentation we have on SEGA Mega Drive development.Technical Bulletin number 32 includes an introduction to XBAND for assing online multiplayer support into your games!The Sega CD Technical Bulletin number 20 mentions that there are only two approved CD re-writers for SEGA CD content which are: Yamaha model #YPE-301/YPR-301S (Uses SEGA Red discs) Fujitsu model #FMCDW101S (Uses SEGA Blue discs)The first Technical Bulletin mentions some errors with Microtec example code, which has never been archived or distributed online.It looks like it would be for DOS and It mentions that it has a few files: asm68k - Assembler for the main Mega Drive 68k CPU lnk68k - Linker to link together assembled object code into a single executable/ROM TestC68K.bat - Seems to be an example of using the C programming language on the Mega Drive!SOUND-SORCE - Japanese Sound Driver for the Mega DriveThe source code to the Japan-only sound driver that was called SOUND-SORCE (incorrect spelling probably due to filename limits?) and was leaked online by Hidden Palace: News/Sega of Japan Sound Documents and Source Code - Hidden PalaceThis leak suggests that development in Sega of Japan was done on NEC PC-9801 DOS based workstations and since these PCs were only popular in Japan it wouldn’t make sense to send the sound driver source code over to the Sega of America development team.As for building the Z80 assembly code it required the X68K assembler and the ERX68K simulator environment which would be connected to a ZAX ICD-series in-circuit emulator which could be controlled with a program called ZICE on the NEC PC-9801.", "excerpt": "Sega Mega Drive (Genesis) SDK Unlike the original Master System or SG-1000 systems, SEGA provided third party developers with some tools to make Mega Drive development easier. Files leaked There are still Sega Mega Drive SDK files that have never been archived or released on the internet unfortunately, so this...", "tags": ["sdk","megadrive","32x","crossproducts","snsystems"], "image": "/public/generated/placeholders/sega-mega-drive-genesis-sdk.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Memory Hacking", "url": "/n64-rom-memory-hacking", "content": "Memory HackingOne excellent way to get started modifying your favourite game is to use memory hacking techniques. By learning what memory locations are used for specific functions you can perform all sorts of crazy cheats and start to get an understanding of how the game works internally.You can even use a tool like Cheat Engine to inspect memory of an emulator such as Mupen64 to modify the contents of N64 game memory!How it works So we know that anything that can change in a game will be stored in some sort of Writable memory such as RAM. This means that there are a number of bytes in RAM which corrospond to an interesting value in-game such as the Lives of the Player, or well anything at all really. If we can find where these locations are we can change how the game behaves in real-time. But how do we find out where the values are located in the big blob of bytes known as RAM? Just like finding anything we perform a search, if we know the current game lives are set to 3, then just loop over each byte in RAM until the value 3 and that should be the value right?! Well sort of, it could be but the number 3 will also be used for many other non-lives related things in the game, for example an enemy could be located at position 3 on the Y axis etc. So we need to find out which location that has the number 3 corrosponds to the actual lives. The technique is simple: Perform an initial memory search for the current value of the stat you want (e.g Lives or HP). Change the stat in the game, e.g loose a life. Now do a “sub-search” which will search within the results of the first search for the new value of lives. The results should have been vastly reduced Repeat until you only get a couple of values Then change these values and the one that increases your lives is the variable you want Now you can lock these memory addresses if you don’t want the game to change the stat, e.g you won’t lose HP. Share What you findTry to document these addresses and share your findings with the community, any new cheat codes or information about what memory addresses are responsible for what are always appreciated.Any information you share can then give other Reversers a head start when they look into the same game and hopefully they will build on what you found, creating even more value for the community.Run on real Hardware It is even possible to edit the memory of your favourite game on the original hardware, with no modifications required! Just use an old School Cheat Cartridge such as the Action Replay, Game Breaker or Equalizer cartridges. These cartridges use a special syntax to tell the Nintendo 64 which memory addresses you want to modify and using that you can convert any cheat you have made in an emulator to run on physical hardware. For example if you look for a life cheat code for Action Replay it will have the same addresses. You can then put this knowledge to the test and create your own cheat codes which run on physical Action Replay cartridges. More advanced Memory HackingMemory Hacking is not exclusive to Emulators or cheat cartridges, the PC gaming community has been using these methods for many years. One very popular tool is known as Cheat Engine and it performs the same functions but for any PC program.iHaxGames - Cheat Engine for mac!Source code: https://github.com/rwilfong50401/iHaxGamezReferences", "excerpt": "Memory Hacking One excellent way to get started modifying your favourite game is to use memory hacking techniques. By learning what memory locations are used for specific functions you can perform all sorts of crazy cheats and start to get an understanding of how the game works internally. You can...", "tags": ["n64","memory","introduction"], "image": "/public/images/n64/N64 Memory Editing.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Emulator Game Memory corruption", "url": "/emulator-game-memory-corruption", "content": "IntroductionGame corruption has become a hot topic recently due to many you tubers playing through games that have in some way had their memory corrupted.This practise can cause the game to produce some weird and wonderful effects which can be entertaining to watch.However game memory corruption can also be a very effective tool for reverse engineering games.One of the troubles with reversing games is that there are no variable names so the memory is one giant blob of bytes that are unlabelled. By corrupting this memory and watching the effect on the game you can start to figure out what part of memory does what.You can then map the memory reads/writes back to the game code to get an indication of what a function or piece of assembly code is doing for the game.ToolsROM Corruptors have existed since the year 2000 with many no longer being updated, however there are 2 main corruptors that are still in use today 1: Vinesauce ROM Corruptor Real Time CorruptorVinesauce ROM CorruptorThe Vinesauce ROM Corruptor was developed due to inspiration from YouTuber Vinesauce rom corruption videos. It corrupts the ROM file itself rather than memory, so technically it can be used on any file 2.Real Time CorruptorThe Real Time Corruptor was developed by Phil Girard and Dan Barreiro as a way to corrupt emulated games in an easy to use manner.RTC EnginesThere are a number of different “Engines” available in RTC, these are basically different ways to corrupt the data, the corruptors available are: Nightmare engine - throws random bytes at the selected memory regions Hellgenie Engine (cheats) - applies random cheats (e.g game engine codes) Distortion Engine (Bytes) - creates blast backups and re-applies them later External ROM Plugin - use with Glitch HarvesterError DelayThe error delay chooses how much time to wait between each blasted byte.Memory ZonesMemory Zones are areas of memory that are allowed to be corrupted. For example you could only select Video RAM for only graphical glitches 3.Blast RadiusThe blast radius controls how it corrupts memory, there are a few options: SPREAD - spreads corruptions random across selected memory CHUNK - corrupts all the memory in one chunk BURST - same as chunk but split into 10 different areasBlast TypeBlast type chooses how to change the bytes that are to be blasted. Basically how it selects the value to replace the old memory value. There are three blast types: Random - Random value is placed at that byte location Tilt - it will go up or down a value Random Tilt - both combinedIf you are looking for a specific thing in the game it is good to set the region of memory that would most likely contain that data along with setting the Blast Radius to CHUNK.Time Flow & Time MapIf you choose to use TimeStack it will keep creating a save state every X number of seconds (configurable).The time map consists of a green line that represents time, orange line is fast forward and the blue line is rewinding.This basically allows you to keep track of what is happening in the game while you corrupt, so you can go back in time to undo corruptions.Glitch HarvesterThe Glitch Harvester comes as part of RTC but works in a very different manner. It works on save states, allowing you to quickly try different random corruptions and save the ones you like.It works with RTC as it still uses the selected engine and settings from RTC, it just provides an additional interface for save state management.Blast EditorNot currently available but will be very useful int he future to see the exact bytes that were corrupted and what their new value is.Console Specific corruptingThis section covers techniques for corrupting games for specific consoles.Nintendo Entertainment SystemOne Lone Coder on youtube has quite a fun video showing random NES memory corruption. Unfortunately it doesn’t mention any source code release of the changes made to the emulator and it doesn’t mention how much memory gets corrupted at a time.But it is quite fun to watch as the levels get more and more corrupted as it seems the corruption happens after a set number of frames.Nintendo 64Nintendo 64 corruption is covered in depth on the Corrupt.Wiki site available here:Basic/Advanced ROM Corruption - Corrupt.wikiGamecube & Wii (Dolphin)This uses the Real Time Corruptor which is a tool for specifically corrupting the memory of emulated games 4.References Old Corruptors - Corrupt.wiki ↩ The Vinesauce ROM Corruptor :: Corrupted Bytes ↩ RTC Guide Part 1 - Main Program - YouTube ↩ Real-Time Corruptor ↩ ", "excerpt": "Introduction Game corruption has become a hot topic recently due to many you tubers playing through games that have in some way had their memory corrupted. This practise can cause the game to produce some weird and wonderful effects which can be entertaining to watch. However game memory corruption can...", "tags": ["introduction","pc","nes","n64"], "image": "/public/images/articles/Emulator Memory Corruption.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Mr Do! Source Code (Game Boy)", "url": "/mrdo", "content": "IntroductionThis page documents the official release of the assembly source for Ocean Software’s Mr Do! port to the Game Boy.It focuses on what the code is doing (maps, chewing, actors, rendering timing, and data formats), plus how to verify it in SameBoy.Start hereIf you only read a few sections, these are the best “entry points” for understanding how the engine works: Data formats - Jump to Scene format (maps, cherries, apples, food) for the SCENE stream and the BYTESCREEN control map. Core trick - Jump to Dirty-tile updates and why BACKSCREEN exists for the BACKSCREEN + CHRDUMP design. Timing - Jump to Timing, VBlank, and the window split for the mid-frame LCDC swap and OAM DMA strategy. Hands-on - Jump to SameBoy debugger walkthrough for watchpoints you can run immediately.Mr Do! - Game Boy ReviewThis video provides a brief look at the Game Boy port and is useful context before diving into the source 1:Source code releaseThe original release is a single monolithic assembly file (mrdo.asm) containing code, data tables, and large blocks of embedded graphics data 2.Description from Paul Hughes 3: Many moons ago I debugged and finished off Ocean’s Mr Do! for the original Game Boy. As Joffa, the late, great original author, decided to release the source code,I thought I’d also put it up.The header for the source file also mentions Wesley Knackers and gives a start date of June 28, 1990 and a last date of September 5, 1990:*****************************************************************************\t\t\t\t\t\t\t\t\t *\t\tMR DO! (C) 1990 SPECIAL FX SOFTWARE LIMITED\t\t *\t\t *\t\t BY WESLEY KNACKERS\t\t\t\t *\t\t\t\t\t\t\t\t\t *\t\t \t START DATE 28/06/90\t\t\t\t *\t\t \t LAST DATE 05/09/90\t\t\t\t *\t\t\t\t\t\t\t\t\t ****************************************************************************Known developers mentioned across the release and related posts: Paul Hughes - Debugged and finished off Ocean’s Mr Do! for the original Game Boy (per his note) 3. Joffa - The original author who released the source code (per Hughes) 3. Wesley Knackers - Credited as the author in the mrdo.asm header 2.Glossary of Key TermsIf you are new to Game Boy reverse engineering terminology, this quick glossary should help: DMA - The Game Boy OAM DMA mechanism used to copy 160 bytes of sprite attribute data into OAM via the DMA register ($FF46) 4. OAM - Object Attribute Memory ($FE00) containing the hardware sprite list (position, tile, attributes) 4. VRAM - Video RAM ($8000-$9FFF) containing tile graphics and background/window tilemaps 4. WRAM - Work RAM ($C000-$DFFF) used for variables, buffers, and scratch space 4. HRAM - High RAM ($FF80-$FFFE) used here to run short routines (including the DMA trigger) without being blocked during OAM DMA 4. MBC1 - A Game Boy cartridge mapper that enables ROM bank switching (writes to $2000-$3FFF select the active ROMX bank) 4. ROM0 / ROMX - The fixed 16 KiB window at $0000-$3FFF (ROM0) and the switchable 16 KiB window at $4000-$7FFF (ROMX) 4.Code overviewThe source is useful because it is not a “disassembly” or a ROM dump, it is a rare case of real Game Boy source code being released online for a commerical game.Some highlights worth skimming first: Main loop - START runs SYSETUP, MENU, and then enters a per-level loop that calls the gameplay subsystems in a predictable order. State-machine style - Multiple behaviours are selected via jump tables (BADTAB, APPLETAB, LOGOTAB, etc.) rather than long chains of branches. 2x2 meta-tiles - The map is built from 4-tile blocks (top-left/top-right/bottom-left/bottom-right) with additional tables for “eaten” wall variants. Split-screen rendering - SPLITSCREEN does a status-window pass, then triggers OAM DMA for gameplay sprites after a timing delay.Frame pipelineThe MAINLOOP order is deliberate.The parts that must run during VBlank (tilemap updates, OAM DMA) are clustered in SPLITSCREEN, and the rest of gameplay runs with predictable data flow: Routine What it does Why it matters SPLITSCREEN Waits for VBlank, updates status, dumps dirty tiles, prints apples, then does OAM DMA swaps Coordinates tilemap writes and sprite DMA so VRAM/OAM access stays safe KEYS Polls the joypad and writes KEYPRESS Centralizes input sampling for the frame DECODE Updates Mr Do movement/animation and handles ball throwing Implements turn validity checks and scroll updates MRDOCHEW Updates the “chewed” tunnel tiles around Mr Do Writes tunnel state into the map mirror and queues tilemap updates BADDIES Updates all active enemies and special actors via BADTAB Shared AI + per-type state machine updates COLLISIONS Checks the thrown ball against all 16x16 actors via HITBALLTAB Handles catches, kills, freeze/unfreeze logic, and score popups APPLEPIE Updates apples via APPLETAB Apple state machine (waiting, jiggle, falling, splitting) DUMPOBJ Builds the gameplay OAM list (GAMEOBJ) from sprite records Includes a simple OAM-order mixing trick to reduce persistent flicker patterns STATSP Builds the status-window OAM list (STATUSOBJ) Renders lives/extra letters + bonus monster status sprites CLOCK / RAND / FLAGS Timekeeping, RNG stirring, animation helpers Keeps animation offsets and randomness consistent frame-to-frame This diagram shows the per-frame call order as a pipeline:flowchart LR SPLIT[\"SPLITSCREEN (VBlank work + OAM DMA)\"] --> KEYS[\"KEYS (poll joypad)\"] KEYS --> DECODE[\"DECODE (Mr Do movement + ball throw)\"] DECODE --> CHEW[\"MRDOCHEW (tunnel updates + CHRDUMP)\"] CHEW --> BADDIES[\"BADDIES (actor update via BADTAB)\"] BADDIES --> COLL[\"COLLISIONS (ball vs actors via HITBALLTAB)\"] COLL --> APPLE[\"APPLEPIE (apple states via APPLETAB)\"] APPLE --> DUMP[\"DUMPOBJ (build GAMEOBJ OAM list)\"] DUMP --> STATSP[\"STATSP (build STATUSOBJ OAM list)\"] STATSP --> CLOCK[\"CLOCK\"] CLOCK --> RAND[\"RAND\"] RAND --> FLAGS[\"FLAGS\"]Joypad polling and turn validationInput is polled by KEYS using the standard $FF00 joypad register scan, with repeated reads and bit-masking before the final nibble merge into KEYPRESS.Mr Do turning is restricted to tile boundaries: Tile boundary gating - DECODE only considers direction changes when both (X+8)&15 == 0 and (Y+8)&15 == 0, which effectively makes turns occur on a 16x16 grid even though positions are stored in pixels. Directional validity tables - The VALIDLR and VALIDUD tables translate the pressed direction bits into a “direction+1” value, letting the code reject invalid transitions cheaply.Coordinate transforms you will see everywhereMultiple helper routines convert between pixel positions and addresses in different memory-backed maps: LOWAD / PIXAD - Convert pixel XY into a DISPSCREEN tilemap address. GETMAPHI / GETMAPLO - Convert pixel XY into a BACKSCREEN tilemap address. GETBYTEHI / GETBYTELO - Convert pixel XY into a BYTESCREEN byte-map address (used as a compact “control map” for tunnels/items).If you are tracing code in an emulator, these routines are great stepping stones for understanding whether a subsystem is reading the “visual map” (DISPSCREEN / BACKSCREEN) or the compact control map (BYTESCREEN).Dirty-tile updates and why BACKSCREEN existsThe tunnel chewing system is optimized around a RAM mirror of the background tilemap: Canonical map mirror - COPYMAP copies DISPSCREEN into BACKSCREEN so gameplay logic can read/modify a RAM copy without touching VRAM constantly. Chew writes go to BACKSCREEN - MRDOCHEW edits BACKSCREEN tiles using direction-specific lookup tables (UTL, UTR, UBL, UBR, and friends). Changes are queued - The chewing code writes address+tile triples into CHRDUMP and increments DUMPTOT. VBlank flush - CHRDUMPER runs inside SPLITSCREEN and copies only the queued tile changes back into DISPSCREEN.CHRDUMPER contains a particularly neat trick.It stores queued addresses in the BACKSCREEN address space and then XORs the high byte so they point at the equivalent DISPSCREEN tilemap location.That avoids storing two pointers per tile update and keeps the dirty list compact.This is the CHRDUMPER hot loop, showing the XOR high-byte mapping:CHRDUMPER\tLD\tA,(DUMPTOT)\t;ANY CHRS TO DUMP?\t\tOR\tA\t\tRET\tZ\t\tLD\tB,A\t\tXOR\tA\t\tLD\t(DUMPTOT),A\t\tLD\tHL,CHRDUMP\t\tLD\tC,>DISPSCREEN^>BACKSCREENCDUMP\t\tLD\tE,(HL)\t\tINC\tL\t\tLD\tA,(HLI)\t\tXOR\tC\t\tLD\tD,A\t\tLD\tA,(HLI)\t\tLD\t(DE),A\t\tDEC\tB\t\tJR\tNZ,CDUMP\t\tRETScene format (maps, cherries, apples, food)The map/scene data (SCENE1..SCENE10) is a compact stream consumed by DRAWMAP.At a high level, each scene contains: Part Encoding Consumed by Mr Do start + initial tunnel 4 bytes: MRDO_Y, MRDO_X, TUNNEL_Y, TUNNEL_X DRAWMAP then DOTUNNEL Tunnel strokes Repeating triples: START_BLOCK, DIRECTION, LENGTH terminated by 0xFF DOTUNNEL (draws a series of 2x2 blocks using VECTAB2) End cap block 1 byte: END_BLOCK ENDTUNNEL (draws one final 2x2 block) Cherry placements Repeating pairs: Y, X terminated by 0xFF PUTCHERRY (draws a 2x2 cherry block at 4 offsets and increments CHERRYTOT) Apple placements Repeating pairs: Y, X terminated by 0xFF PUTAPPLES (initializes apple records and draws apple blocks) Food placement 3 bytes: Y, X, UNDERLAY_BLOCK_INDEX PUTFOOD (draws the food block, then patches the underlay in BACKSCREEN) This diagram shows the scene stream at a glance:flowchart TB H[\"Header: MRDO_Y, MRDO_X, TUNNEL_Y, TUNNEL_X (4 bytes)\"] --> T[\"Tunnel strokes: (START_BLOCK, DIR, LEN) repeated\"] T --> TEND[\"0xFF terminator\"] TEND --> E[\"End cap: END_BLOCK (1 byte)\"] E --> C[\"Cherry placements: (Y, X) repeated\"] C --> CEND[\"0xFF terminator\"] CEND --> A[\"Apple placements: (Y, X) repeated\"] A --> AEND[\"0xFF terminator\"] AEND --> F[\"Food placement: (Y, X, UNDERLAY_BLOCK_INDEX) (3 bytes)\"]At the assembly level, the tunnel-stroke part of the stream is parsed by DOTUNNEL as a small self-recursing loop:DOTUNNEL\tLD\tA,(HLI)\t\t;START BLOCK NUMBER\t\tCP\t-1\t\tRET\tZ\t\tADD\tA,A\t\tADD\tA,A\t\tLD\tC,A\t\tLD\tA,1\t\tCALL\tDRAWBLOCK\t;DRAW START BLOCK\t\tLD\tA,(HLI)\t\t;DIRECTION 0TO4\t\tADD\tA,A\t\tLD\tB,A\t\tADD\tA,A\t\tLD\tC,A\t\t;C=BLOCK ADDR LOW\t\tLD\tA,<VECTAB2\t\tADD\tA,B\t\tLD\tB,A\t\t;B=VECTOR TABLE ADDR LOW\t\tLD\tA,(HLI)\t\t;GET LENGTH\t\tPUSH\tHL\t\tLD\tH,>VECTAB2DRAWREP\t\tPUSH\tAF\t\tLD\tL,B\t\tLD\tA,(HLI)\t\t;MOVE TO NEXT POS\t\tADD\tA,E\t\tLD\tE,A\t\tLD\tA,(HL)\t\tADD\tA,D\t\tLD\tD,A\t\tLD\tA,1\t\tCALL\tDRAWBLOCK\t;DRAW REPEAT BLOCK\t\tPOP\tAF\t\tDEC\tA\t\tJR\tNZ,DRAWREP\t\tPOP\tHL\t\tJR\tDOTUNNELThe control-layer that makes this practical is BYTESCREEN ($CC00), which is defined as $100 bytes.That size is a strong hint that the gameplay logic is operating on a 16x16 grid of “macro cells” (each macro cell is a 2x2 set of 8x8 tiles, i.e. 16x16 pixels).DRAWBLOCK writes a macro-cell value into BYTESCREEN, and DECODE reads it (via GETBYTEHI) to choose what happens when Mr Do enters a cell.The values map directly onto the EATJP jump table: Value Meaning EATJP target 0 Solid wall / gravel (not yet tunneled) EATWALL (slows Mr Do down while chewing) 1 Tunnel / already-open cell EATUNNEL (no-op) 2 Cherry EATCHERRY (score + sequence bonus + decrements CHERRYTOT) 3 Apple EATAPPLE (no-op here, apples are handled via the apple state machine) 4 Food EATFOOD (score + palette/freeze + spawns ghosts/bonus monster behaviour) This is the core BYTESCREEN dispatch from DECODE, including the EATJP jump table:EATJP\t\tDEFW\tEATWALL\t\t;00\t\tDEFW\tEATUNNEL\t;01\t\tDEFW\tEATCHERRY\t;02\t\tDEFW\tEATAPPLE\t;03\t\tDEFW\tEATFOOD\t\t;04\t\tCALL\tGETBYTEHI\t\tLD\tA,(HL)\t\t;GET CONTROL BYTE\t\tLD\t(HL),1\t\t;SET TUNNEL BYTE\t\tADD\tA,A\t\tADD\tA,<EATJP\t\tLD\tL,A\t\tLD\tH,>EATJP\t\tLD\tA,(HLI)\t\tLD\tH,(HL)\t\tLD\tL,A\t\tCALL\tJPHL\t\t;WORK EAT ROUTINEThe 2x2 meta-tile blocks themselves come from the BLOCKS table.These are not “gameplay types”, they are tilemap stamps (four bytes each) built from tile-id groups like ED, CN, DT, CH, FD, and AP0: Block index Purpose (from comments) Typical use $00-$03 Tunnel segments (U/R/D/L variants) Repeated stamps for a tunnel stroke (DOTUNNEL) $04-$07 Tunnel ends (U/R/D/L) Start/end caps for strokes and final end cap (DOTUNNEL / ENDTUNNEL) $08-$0B Corners (TL/TR/BR/BL) Corner shaping when building complex tunnels $0C-$0F Walls (top/right/bottom/left) Wall shaping and underlays $10 Cherry block PUTCHERRY (placed as a 2x2 cluster of macro cells) $11 Food block PUTFOOD (drawn in VRAM) $12 Apple block PUTAPPLES $13 Middle / filler Used as a special-case stamp The tunnel stroke direction encoding is consistent across the code:the direction byte is used to index VECTAB2 (macro-cell steps of 2 tiles) and to select which tunnel segment block ($00-$03) to stamp repeatedly.In practice this behaves like a 4-way direction enum (up/right/down/left).The food placement code is worth reading closely because it shows the kind of “tight” control-flow you get in commercial LR35902 assembly.After drawing the food into VRAM using DRAWBLOCK, PUTFOOD computes the BACKSCREEN address for the same position and then jumps into the middle of DRAWBLOCK (DRWBLOCK) to stamp a 2x2 underlay block into the RAM mirror.To make the stack clean up properly, it pushes AF three times so the POP DE, POP BC, and POP HL epilogue inside DRAWBLOCK has something to consume.It is a tiny micro-optimization, but it is also a very “real world” example of trading readability for speed and code size.Tile ID taxonomyThis codebase relies heavily on treating a tile ID as a semantic category, not just a graphic.Most comparisons are against the base constants that define the background tile groups: Constant Value Used as WL $00 “Wall/gravel” tile group used for initial fill and tunnel shaping CH $10 Cherry tile group ED $14 Tunnel edge tile group (used by chewing, apple deformation, and ball bounce tables) CN $1C Corner tile group DT $20 Dots/walkable tile group (also used by passability tests) WT $24 A single special tile labelled “WHITE CHR!” FD $25 Food tile group (background) AP0 $5C Apple tile group (background) When you see code doing things like CP DT+3 or CP ED+7, it is not doing collision against an object.It is testing whether the background tile under an actor belongs to one of these groups.You will also see a common trick in passability checks: it ORs the tile with 1 (tile|1) before comparing, which makes even/odd variants of an edge tile compare the same without a second branch.There are similar “semantic tile ID” patterns on the sprite side.For example, the 2x2 sprite expansion uses CHRTABLE to translate an animation frame index into four tile IDs plus per-quadrant flags (flip, palette, etc.).Chew algorithm deep diveThe chewing system is split between “gameplay semantics” (what happens when you enter a macro cell) and “visual updates” (how tiles are rewritten).This diagram shows those two layers side-by-side:flowchart LR subgraph \"Gameplay semantics\" DECODE[\"DECODE\"] --> BYTES[\"Read BYTESCREEN macro-cell value\"] BYTES --> EATJP[\"EATJP jump table\"] EATJP --> EFFECTS[\"Score/timers/palette/freeze side effects\"] end subgraph \"Visual updates\" CHEW[\"MRDOCHEW\"] --> BACK[\"Rewrite BACKSCREEN (RAM mirror)\"] CHEW --> DUMPQ[\"Append dirty tiles to CHRDUMP (via DUMPTOT)\"] SPLIT[\"SPLITSCREEN (VBlank)\"] --> FLUSH[\"CHRDUMPER flushes to DISPSCREEN (VRAM tilemap)\"] end BACK --> FLUSH DUMPQ --> FLUSHAt the semantic level, DECODE reads a macro-cell value from BYTESCREEN and dispatches via EATJP: 0 - EATWALL slows movement (sets SPEED and SPDCOW) while you are chewing. 1 - EATUNNEL does nothing (already-open cell). 2 - EATCHERRY decrements CHERRYTOT and adds score, including a small sequence bonus controlled by CHERRYBON/CHERRYDEL. 3 - EATAPPLE is a no-op here (apples are driven by the apple state machine). 4 - EATFOOD adds score and triggers the “food mode” effects (palette change + FREEZE + extra/ghost behaviour).At the visual level, MRDOCHEW performs a 2x2 macro-cell rewrite into BACKSCREEN, and queues the corresponding DISPSCREEN updates for VBlank: Grid gating - It only chews when the mouth position is aligned to an 8-pixel boundary ((x|y)&7 == 0 after a small offset). Allocate dirty slots - It uses DUMPTOT as an index into CHRDUMP, increments it by 4, and computes HL so there is room for four tile updates. Resolve direction - It dispatches through CHEWJP based on Mr Do’s facing direction (MRDOSP+FLG). Rewrite a 2x2 - Each CHEW* routine computes four replacement tiles using direction-specific tables (UTL/UTR/UBL/UBR, LTL/LTR/LBL/LBR, DTL/DTR/DBL/DBR, etc.), writes the new tiles into BACKSCREEN, and writes four (addrLo, addrHi, tile) triples into CHRDUMP. VBlank flush - CHRDUMPER runs during the next SPLITSCREEN and applies each queued tile to DISPSCREEN.The core reason this is robust is that BACKSCREEN is treated as the canonical map state.VRAM only gets updated in bursts via CHRDUMPER, which keeps the chew logic simple and makes it easy to reproduce in a reimplementation.Apple state machineApples are driven by a compact state machine very similar to the enemy and ball systems.Each apple is a fixed-size record in APPLESP, and APPLEPIE iterates APNUM entries and dispatches via APPLETAB based on TYP.The apple states are: Value Meaning Update routine 0 Inactive slot NOAPPLE 1 Waiting / on the map APPLEWAIT 2 Wobble (“jig”) before falling APPLEJIG 3 Falling APPLEFALL 4 Splitting / impact animation APPLESPLIT APPLEWAIT does a very cheap support test by reading the two tiles under the apple (left and right) from the background mirror.If either tile is less than CH+4, it treats that as “solid” and the apple does not fall.If both tiles look passable, it increments TYP and starts a 60-frame wobble.APPLEJIG uses SPEEDFLAG bit 2 (%100) to toggle the tile index (AP0 vs AP0+4), which gives you a free shake animation without moving the apple.APPLEFALL is the most interesting part because it is integrated with the dirty-tile system: Rate control - It uses APPLEAND masked with SPEEDFLAG to slow the fall rate (difficulty scaling). Background restore - It queues tile restores into CHRDUMP so the old apple stamp is erased in the next VBlank. Wall deformation - After a “critical point” (when the falling counter reaches 3), it starts modifying the edge tiles it passes through using LAFALL and RAFALL.APPLESPLIT enforces that only one apple can do the expensive 4-tile split write per frame using the SPLAT flag (“done once”).That is a very pragmatic performance guard: without it, multiple apples impacting in the same frame would explode the dirty-tile list and VRAM work.Ball states and bounce tablesThe ball is implemented as another actor type dispatched via BADTAB, with multiple states:carried (CARRYBALL), thrown (THROWBALL), spinning out (OUTBALL), and returning (INBALL).When carried, the ball is positioned relative to Mr Do using the facing direction and a small offset table.The key tables are: Table Role Notes BALLOFF Base XY offset from Mr Do Indexed by direction BALLXY Extra 1-pixel offsets Gives a 4-frame wobble animation BALLVEC Movement deltas Maps direction to (dx, dy) at BALLSPEED When thrown, THROWBALL is deliberately grid-gated:it only does a bounce decision when (x+4)&7 == 0 or (y+4)&7 == 0.On those alignments it reads the contacted tile ID from the background mirror: Wall/cherry class - If the tile is less than CH+4, it always flips direction (dir ^= 2). Bounce lookup - Otherwise it scans a per-direction list of bounce-trigger tiles (BALLCPS) and uses a parallel bounce table (BALLBOU) to pick the new direction.One of the bounce entries has bit 7 set, enabling a small RND3 perturbation that is explicitly commented as preventing the ball from getting trapped in repeatable ricochet loops.This is the bounce decision core inside THROWBALL:\t\tLD\tL,E\t\tLD\tH,D\t\tCALL\tGETMAPHI\t;HL=SCRN3 ADDR\t\tLD\tA,(HL)\t\t;GET CHR\t\tCP\tCH+4\t\t;WALL OR CHERRY?\t\tJR\tNC,NOCHWL\t\tLD\tA,B\t\t;THEN ALWAYS FLIP DIRECTION\t\tXOR\t2\t\tLD\tB,A\t\tJR\tNOCHNNOCHWL\t\tPUSH\tDE\t\tLD\tE,A\t\tLD\tA,B\t\t;GET LAST DIRECTION\t\tADD\tA,A\t\tLD\tL,A\t\tADD\tA,A\t\tADD\tA,L\t\tADD\tA,<BALLCPS\t\tLD\tL,A\t\tLD\tH,>BALLCPS\t\tLD\tD,6\t\t;TOTAL NUMBER OF CHRS TO CHECKBCHECK\t\tLD\tA,(HLI)\t\t;HAVE WE HIT A VALID CHR?\t\tCP\tE\t\tJR\tNZ,NOBHIT\t\tLD\tA,BALLBOU-BALLCPS-1\t\tADD\tA,L\t\tLD\tL,A\t\t;INDEX BOUNCE VECTORS\t\tLD\tA,(HL)\t\t;GET NEW BOUNCE DIRECTION\t\tBIT\t7,A\t\t;BIT OF RND?\t\tJR\tZ,NRNDB\t\tLD\tB,A\t\tLD\tA,(RND3)\t;STOPS BEING TRAPPED!\t\tAND\t2\t\tADD\tA,128\t\tXOR\tBNRNDB\t\tLD\tB,A\t\tPOP\tDEAfter a kill, the ball enters a circular spin-out phase (OUTBALL).This uses the CIRCLE routine (lookup table + quadrant xor) and a small multiply trick (MULTIE / MULTID) to scale the circle output, then adds that to a stored centre position.When the counter reaches a threshold it transitions into INBALL and eventually reattaches to Mr Do.Timing, VBlank, and the window splitMost of the rendering safety in this codebase comes from two tiny wait primitives: Routine Mechanism Used for WAITBLANK Sets LYC=144 and busy-waits for STAT bit 2 (LYC=LY) Entering VBlank before touching VRAM/tilemaps WAITSYNC Sets LYC=A and busy-waits for STAT bit 2 Scheduling mid-frame changes (like the status/gameplay split) This is the full implementation of both waits in mrdo.asm:WAITBLANK\tLD\tA,144WAITSYNC\tLD\t(LYC),AWAITSC\t\tLD\tA,(STAT)\t\tBIT\t2,A\t\tJR\tZ,WAITSC\t\tRETThis diagram shows the split-screen timing model across a frame:flowchart TB VBL[\"LY=144: WAITBLANK enters VBlank\"] --> DMA0[\"DMA STATUSOBJ (write $FF46)\"] DMA0 --> WINON[\"LCDC=0xE3 (window on for status strip)\"] WINON --> VBWORK[\"VBlank work: PRSCORE + CHRDUMPER + PRAPPLES\"] VBWORK --> SYNC16[\"WAITSYNC to LY=16 (write $FF45=16)\"] SYNC16 --> DMA1[\"DMA GAMEOBJ (write $FF46)\"] DMA1 --> WINOFF[\"LCDC=0xC3 (window off for gameplay)\"] WINOFF --> RUN[\"Gameplay scanlines: LY 16..143\"] RUN --> NEXT[\"Next frame\"]SPLITSCREEN combines these waits with LCDC writes to effectively toggle the status window on and off within a single frame.This is also where OAM DMA happens, so if you are debugging timing issues in an emulator, WAITBLANK, WAITSYNC, and writes to LCDC/DMA are the most information-dense breakpoints you can set.The split itself is implemented as a two-phase OAM DMA swap: VBlank entry - WAITBLANK, then OAM DMA STATUSOBJ so scanlines 0..15 use the status OAM list. Status mode - Enable the window with LCDC=0xE3 and do VBlank work (PRSCORE, CHRDUMPER, PRAPPLES). Boundary sync - WAITSYNC to LY==16 (a 16-pixel strip). Gameplay swap - OAM DMA GAMEOBJ, then disable the window with LCDC=0xC3 for the rest of the frame.The DMA trigger itself is a tiny stub (DMATRANS) that SYSETUP copies into HRAM ($FF80) and calls via the BLITS label.This is the classic safe-DMA pattern: during OAM DMA the CPU can still execute from HRAM even though most other memory access is blocked.This is the stub and the SYSETUP copy loop that installs it into INTRAM ($FF80):DMATRANS\tDI\t\tLD\t(DMA),A\t\tLD\tA,40DMAL\t\tDEC\tA\t\tJR\tNZ,DMAL\t\tEI\t\tRET\t\tLD\tHL,DMATRANS\t;SETUP DMA TRANS ROUTINE\t\tLD\tDE,INTRAM\t\tLD\tB,SYSETUP-DMATRANSTOINTRAM\tLD\tA,(HLI)\t\tLD\t(DE),A\t\tINC\tE\t\tDEC\tB\t\tJR\tNZ,TOINTRAMOne caveat when rebuilding this release is that SYSETUP enables interrupts (IE=1 then EI) but the file does not obviously define an interrupt handler ending in RETI.If you try to assemble/port this code, verify what ends up at the interrupt vectors (especially $0040) before leaving IME enabled.SameBoy debugger walkthroughIf you want to verify the claims above, SameBoy’s textual debugger is a good fit because it supports write watchpoints and conditional expressions 5.To use the textual debugger you generally: Pause - Press Control+C (or use the interrupt command). Instrument - Set breakpoints and watchpoints. Run - Use continue and let the emulator stop at interesting writes.Suggested watchpointsThese watchpoints catch the most important hardware edges and RAM mirrors: Target Why it matters SameBoy command $FF46 OAM DMA trigger (writes happen in SPLITSCREEN) watch/w $ff46 $FF40 LCDC mode changes (window on/off and LCD state) watch/w $ff40 $FF45 LYC scheduling for mid-frame timing (WAITSYNC) watch/w $ff45 $C800-$CBFF BACKSCREEN RAM mirror (canonical background state) watch/w $c800 to $cbff $CC00-$CCFF BYTESCREEN macro-cell control map (0..4 for EATJP) watch/w $cc00 to $ccff If the BACKSCREEN and BYTESCREEN ranges are too noisy, narrow them temporarily to what you are currently testing (or delete/re-add watchpoints as needed).Lab 1 - Prove the window splitThis lab is just enough to prove SPLITSCREEN is doing a mid-frame OAM DMA swap and toggling the window: Instrument - watch/w $ff46 and watch/w $ff40. Run - continue and let SameBoy stop on $ff46. Confirm the double-hit - Continue a few times and you should see $ff46 hit twice per frame (status OAM, then gameplay OAM). Confirm the mode change - When $ff40 hits, check if the value matches the two modes described above (0xE3 vs 0xC3).Lab 2 - Prove chewing is BYTESCREEN + BACKSCREEN + CHRDUMPThis lab connects “macro-cell semantics” to “tilemap updates”: Instrument - watch/w $cc00 to $ccff and watch/w $c800 to $cbff. Chew a wall - Walk into an unchewed area and wait for a $cc00-$ccff write (macro-cell type changes). Watch the mirror update - Continue and you should see $c800-$cbff writes as edge tiles are rewritten in BACKSCREEN. Watch the flush (optional) - Temporarily add watch/w $9800 to $9bff and you should see the queued updates land in VRAM during the next SPLITSCREEN.Debugging the window split and OAM DMATo see the split-screen renderer in action, do this: Start running - Use continue. Stop on OAM DMA - The $ff46 watchpoint should hit twice per frame (status DMA, then gameplay DMA). Inspect state - Use lcd, dma, and registers, then disassemble/32 pc to see the immediate code path.Useful debugger commands at those stops are:lcddmaregistersdisassemble/32 pcIf you want to focus on the moment the window toggles, use a conditional watchpoint on LCDC:watch/w $ff40 if new != oldDebugging tunnel chewing and dirty-tile flushesTo connect Mr Do chewing with background writes: Stop on BYTESCREEN writes - Move into a wall and watch for writes into $cc00-$ccff (macro-cell type changes). Stop on BACKSCREEN writes - Watch for tunnel edge tiles being rewritten in $c800-$cbff. Observe the VBlank flush - If you temporarily watch DISPSCREEN ($9800-$9BFF), you should see the queued updates being applied during the next SPLITSCREEN when CHRDUMPER runs.If you do want to watch the VRAM tilemap itself, limit it to short bursts because it is very high traffic:watch/w $9800 to $9bff # DISPSCREEN (VRAM tilemap) - expect lots of hitsDebugging applesApple falling is a good demonstration of this engine’s “update RAM mirror, flush in VBlank” strategy.When an apple transitions from APPLEWAIT to APPLEFALL you should see: BACKSCREEN writes - The apple punches through tunnel edge tiles (via LAFALL/RAFALL after the critical point). Dirty-tile flush - The queued updates are applied in the next VBlank when CHRDUMPER runs.Debugging ball bouncesBall bounces are easiest to catch by letting the $c800-$cbff watchpoint stop you while the ball is in flight, then stepping until you hit a bounce decision and noting the current tile ID being compared against BALLCPS.In practice the bounce decision points are rare because THROWBALL only checks collisions on an 8-pixel grid alignment.If you are not seeing interesting stops, throw the ball into a dense area of tunnel corners/walls and let it ricochet.Enemy AI is shared and table-drivenThe baddie update loop (BADDIES) is structurally very similar to the apple loop: Update dispatch - BADTAB maps TYP to the update routine for dinos, ghosts, the bonus monster states, ball states, and score popups. Junction decisions - FINDEXITS scans the 2x2 neighbourhood around an actor on 8-pixel boundaries and returns an exit bitmask. Direction selection - WORKEXITS validates the current direction (via VECTOBIT) and then chooses a new one using a bounded retry loop against BITAB/BITTOVEC, stirred by RND1/RND2.This is a nice example of how multiple enemies can share navigation logic while still having distinct “animation and special case” behaviour per type.One detail that helps when tracing enemy movement is the exit bit layout.FINDEXITS sets bits in the returned mask in a slightly non-obvious order:bit 3 is up, bit 0 is right, bit 2 is down, and bit 1 is left.That ordering matches the VECTOBIT and BITTOVEC tables used by WORKEXITS.The other critical detail is that passability is decided purely by tile IDs in BACKSCREEN.FINDEXITS effectively whitelists a handful of DT+* and ED+* variants: Up - tile is DT+1 or DT+3 or (tile|1) == ED+3 Right - (tile|1) == DT+3 or (tile|1) == ED+5 Down - tile is DT+0 or DT+2 or (tile|1) == ED+7 Left - tile is DT+1 or (tile|1) == ED+1This is the full FINDEXITS tile-whitelist routine, including the %UDLR bit layout:;DE=XY RETS A=%UDLR BITSFINDEXITS\tPUSH\tDE\t\tLD\tL,E\t\tDEC\tL\t\tLD\tH,D\t\tDEC\tH\t\tCALL\tGETMAPHI\t\tLD\tDE,$0100\t\tLD\tA,(HLI)\t;TOP CHR...\t\tCP\tDT+1\t\tJR\tZ,ISUP\t\tCP\tDT+3\t\tJR\tZ,ISUP\t\tOR\tD\t\tCP\tED+3\t\tJR\tNZ,NOUPISUP\t\tSET\t3,ENOUP\t\tLD\tA,(HL)\t;R CHR...\t\tOR\tD\t\tCP\tDT+3\t\tJR\tZ,ISRT\t\tCP\tED+5\t\tJR\tNZ,NORTISRT\t\tSET\t0,ENORT\t\tLD\tA,L\t\tADD\tA,32\t\tLD\tL,A\t\tADC\tA,H\t\tSUB\tL\t\tLD\tH,A\t\tLD\tA,(HLD)\t;BOT CHR...\t\tCP\tDT+0\t\tJR\tZ,ISDW\t\tCP\tDT+2\t\tJR\tZ,ISDW\t\tOR\tD\t\tCP\tED+7\t\tJR\tNZ,NODWISDW\t\tSET\t2,ENODW\t\tLD\tA,(HL)\t;L CHR...\t\tOR\tD\t\tCP\tDT+1\t\tJR\tZ,ISLF\t\tCP\tED+1\t\tJR\tNZ,NOLFISLF\t\tSET\t1,ENOLF\t\tLD\tA,E\t\tPOP\tDE\t\tRETWORKEXITS then adds a few pragmatic behaviours: Keep direction if possible - If the current direction remains valid, it usually keeps going. Forced randomness - Even when a direction is valid, it forces a re-pick roughly 1/8 of the time (RND2 & 7 == 0). Bounded search - When it must pick a new direction, it tries up to 4 candidates.This is the core of WORKEXITS, showing how it keeps direction when possible and otherwise picks a new one using BITAB and BITTOVEC:WORKEXITS\tPUSH\tDE\t\tLD\tD,L\t\tLD\tE,A\t\t;TEMP EXITS\t\tLD\tA,B\t\t;GET OLD DIR\t\tADD\tA,<VECTOBIT\t\tLD\tL,A\t\tLD\tH,>VECTOBIT\t\tLD\tA,(HL)\t\tAND\tE\t\t;IS DIR AN OPTION\t\tJR\tZ,CHANGEDIR\t\tLD\tA,(RND2)\t;RND MOVE\t\tAND\t7\t\tJR\tNZ,DINODECHANGEDIR\tLD\tA,(RND1)\t\tADD\tA,D\t\tSRL\tA\t\tSRL\tA\t\tSRL\tAFINDEX\t\tLD\tD,A\t\tAND\t3\t\tADD\tA,<BITAB\t\tLD\tL,A\t\tLD\tA,(HL)\t\tAND\tE\t\tJR\tNZ,GOEXIT\t\tLD\tA,D\t\t;WILL DO MAX 4 TIMES ONLY!\t\tINC\tA\t\tJR\tFINDEXGOEXIT\t\tLD\tA,(HL)\t\tADD\tA,<BITTOVEC\t\tLD\tL,A\t\tLD\tB,(HL)\t\t;NEW DIRECTIONDINODE\t\tPOP\tDE\t\tRETCollisions are simple AABB tests plus a jump tableCOLLISIONS does an axis-aligned bounding-box overlap test in 16x16 space between the moving ball and every 2x2 actor.On hit, it dispatches via HITBALLTAB to routines like MRDOCATCH, DINODIE, and GHOSTDIE.This makes the collision layer easy to extend:you can add a new actor type by adding a BADTAB entry (update) and a HITBALLTAB entry (ball interaction) without touching the collision loop itself.Ball-vs-world behaviour is tile-driven and grid-gated.The thrown ball only does bounce decisions when it is aligned to an 8-pixel grid, and then compares the contacted tile against per-direction tables (BALLCPS and BALLBOU), with a small RNG hook to reduce repeatable trap patterns.Sprite dumping and OAM orderingDUMPOBJ converts logical actor records into actual OAM entries.Each 2x2 sprite frame is expanded into four OAM entries using CHRTABLE, which stores tile indices and flags for the four quadrants.There is also a small per-frame “OAM address mixing” step:it varies the ADL fields for the first 8 sprite records and then uses OBJSWAP for the rest.This kind of deterministic shuffling is commonly used to avoid the same sprite always losing when the hardware sprite-per-scanline limit is exceeded.This is the start of DUMPOBJ, including scroll inversion and the ADL mixing pass:DUMPOBJ\t\tLD\tA,(NEWSCX)\t;INVERT SCROLL OFFSETS\t\tCPL\t\tINC\tA\t\tLD\t(SCXT),A\t\tLD\tA,(NEWSCY)\t\tCPL\t\tADD\tA,9\t\tLD\t(SCYT),A\t\tLD\tHL,SPRITES+ADL\t;SWAP 8 OBJ POINTERS\t\tLD\tDE,EVAR\t\tLD\tA,(SPEEDFLAG)\t\tLD\tC,A\t\tSWAP\tA\t\tLD\tB,8MPLEX\t\tAND\t%01110000\t\tLD\t(HL),A\t\tADD\tA,16\t\tADD\tHL,DE\t\tDEC\tB\t\tJR\tNZ,MPLEXStatus line updates are deliberately amortizedThe status line is updated a little at a time: One digit per frame - PRSCORE uses SPEEDFLAG & 7 to update only one score digit tile each frame rather than writing all digits every frame. Timers as ASCII digits - CLOCK increments ASCII digits in-place and carries when a digit exceeds \"9\".PRSCORE is driven by a small pointer table (STATNUM) that pairs a destination tile address in STATSCREEN with a source byte in REALSCORE.The SPEEDFLAG & 7 index means each of the 6 score digits plus two spare slots can be refreshed gradually while keeping per-frame VRAM writes tiny.The underlying score representation is very literal: Main score - REALSCORE is a 6-byte ASCII string (\"000000\"). Per-level board - SCORE stores multiple fixed-length records (BRDLEN = 9) that include score digits and extra per-level stats, with TALLOFF selecting the active record.Score adds go through SCOREADD / UPSCORE, which perform ASCII digit addition with carry propagation.That makes it easy to add different point values by passing “digit + offset” pairs rather than doing binary-to-decimal conversion every time.High score tableHigh scores are stored as a simple fixed-size table (ENTRIES = 8) beginning at HIGHTAB.Each entry is LINELEN = 12 bytes, laid out as: Field Bytes Notes Score 6 ASCII digits (same format as REALSCORE) Name 3 Initials, wiped to $FF on insert Scene 1 Stored as a binary value (printed via PRDECDIGITS) Time 2 A tick count that is divided by 60 for MM;SS printing CHECKHIGH compares REALSCORE against each table entry digit-by-digit and inserts the new score by shifting the table down in memory.PRHIGHSCORES then prints the table into the status tilemap and formats the time by dividing the stored ticks into minutes and seconds.Memory map and data structuresThe file defines a set of fixed addresses that make its rendering and buffering model easier to follow.This is also a good example of how much you can get done on a ROM-only cartridge by leaning on careful RAM layout.Key addresses used throughout the code are: Name Address Notes STACK $CFFF Stack top (end of WRAM) OBJSET $8000 Sprite tile data base in VRAM BGSET $9000 Background tile data base in VRAM DISPSCREEN $9800 Background tilemap for gameplay STATSCREEN $9C00 Background tilemap for the status window BACKSCREEN $C800 RAM buffer used for background work BYTESCREEN $CC00 Small RAM buffer used as scratch / temp OAMRAM $FE00 OAM INTRAM $FF80 HRAM Sprite recordsThe game uses fixed-size records in WRAM to represent sprites and “actors”.The comments in the SPRITES block give the layout, and you can see the same pattern repeated in multiple systems (Mr Do, dinos/ghosts, apples).The sprite record fields are: Field Offset Purpose TYP 0 Actor type (used as an index into jump tables) YNO 1 Y position (pixel units) XNO 2 X position (pixel units) GNO 3 Base tile index / graphics selector FLG 4 Flags (palette, flip, priority, etc.) ADL 5 Pointer / address low byte (varies by actor) YSD 6 Y speed / delta XSD 7 X speed / delta Main loop and jump-table patternAt the top level the program flow is very direct: Boot - START sets up the stack, calls SYSETUP, runs the menu, and resets the game state. Per level - LEVELSETUP prepares graphics and variables and then drops into MAINLOOP. Per frame - MAINLOOP calls the major gameplay subsystems (input, Mr Do movement/eating, baddies, collisions, apples, sprite dumping, timers, RNG, and flag updates).One of the most reusable techniques in the file is the jump-table driven state machine.For example, BADTAB maps each actor type to its update routine, and APPLETAB does the same for apple states.This is a good pattern to steal when writing your own LR35902 assembly because it keeps the hot-path branch structure compact.Rendering, split-screen, and DMAThe code uses two different “sprite worlds” and then does a timed swap: Status sprites - A separate OAM-shaped buffer (STATUSOBJ) is DMA’d first, with the LCDC configured so the status window is enabled. Gameplay sprites - After updating the status line graphics, the code waits a fixed amount of time and then DMA’s the gameplay sprite list (GAMEOBJ) and disables the status window again.This is orchestrated by SPLITSCREEN, and it relies on a tiny DMA-trigger routine being copied into HRAM during SYSETUP.The routine is then called via the BLITS label, passing the source high-byte in A before writing to DMA ($FF46) 4.If you are reverse engineering the ROM in an emulator, the easy breakpoint targets are: OAM DMA - writes to $FF46 (DMA). Mode changes - writes to LCDC ($FF40) to enable/disable the window.Map format and 2x2 meta-tilesThe background is assembled from 2x2 blocks of tile IDs.The BLOCKS, CORNERS, CHERRY, FOOD, and APPLE tables each store 4 bytes in the order “top-left, top-right, bottom-left, bottom-right”.There are also multiple “eat tables” (for example UTL, UTR, UBL, UBR) that appear to define the replacement tiles to use when Mr Do chews through walls in a particular direction.If you are trying to re-implement or rewrite the map system, these tables are a good anchor for reconstructing the exact tile semantics.RNG and text routinesThe RNG is a compact 3-byte state (RND1, RND2, RND3) stirred each frame and mixed with the DIV hardware register.It is small enough that you can single-step it and see how entropy flows into map generation (for example the gravel fill in DRAWMAP).The text routines are also worth a quick look because they show a very practical “engine” approach:strings are stored in a compact custom format, and PRINTEXT renders them directly into the background tilemap.Assembling it todayThe source uses an older assembler dialect with directives like DEFB, DEFW, DEFS, HEX, ORG, and ENT.That means you should not expect it to assemble cleanly with modern rgbds without some conversion work 6.Original AssemblerThe custom assembler for this file was either Special FX’s own Gameboy assembler or Ocean’s own Atari ST based assembler according to Paul Hughes in his tweet 7:It was started on Special FX's own Gameboy assembler and hardware and was finished on Ocean's own Atari ST based assembler and hardware.— Paul Hughes (@PaulieHughes) February 22, 2020It would be great to find out more about either Special FX or Ocean’s development kit hardware, so please get in touch if you have any information.If you want to get it building as an exercise, a reasonable approach is: Start with rgbds scaffolding - Create a ROM0 header section and make sure the reset entry and cartridge header bytes land at the expected addresses 46. Convert directives mechanically - Map DEFB/DEFW/DEFS to db/dw/ds, and replace HEX blocks with db $.. sequences. Replace ORG with sections - Translate fixed ORG placements into SECTION blocks pinned to ROM0/ROMX addresses. Validate in an emulator - Use breakpoints on $FF46 and LCDC to confirm you are hitting the same high-level flow as the original.Also note that the in-file cartridge header comments claim a 256K ROM, but the ROM size byte in the header is written as 0.If you do attempt a rebuild, you will need to reconcile those fields with the actual output ROM size.RGBDS conversion scriptWe have written a best-effort converter that keeps the original mrdo.asm untouched and produces a RGBDS-parseable .asm file:What it does: converts EQU/DEFB/DEFW/DEFS, turns HEX into db $.., and maps each ORG to an explicit SECTION. Heuristic bank split - The converter includes a pragmatic split so the output links as a simple ROM-only build: ORG $800 becomes fixed ROMX bank 1 code, and the SCENE1+ data block is placed back into ROM0 at $0800. Main limitation - The original toolchain could pre-initialize RAM, but RGBDS cannot, so WRAM/HRAM sections in the output are primarily for symbol addresses (you still need real init/copy code for a working rebuild). Interrupt vector stubs - The converter injects reti stubs at $0040/$0048/$0050/$0058/$0060 because the release enables interrupts (IE=1 then EI) but does not define handlers in the vector table. Without this, a rebuild will often crash or “flash” as soon as VBlank fires 4.One thing to keep in mind is that this converted build is not trying to match the retail ROM layout.The retail Mr Do! ROM is a banked MBC1 cartridge and is effectively a 64 KiB-class image (4 x 16 KiB banks), while the direct conversion build is a minimal 32 KiB ROM ONLY image so you can explore code and data quickly.Installing RGBDSIf you want to run the rgbasm/rgblink sanity-check commands locally, install RGBDS first: macOS - Install via Homebrew (brew install rgbds) 8. Linux - Install via your distro package manager, or use the official release tarball + install.sh 9. Windows - Use WSL and follow the Linux instructions, or use the official .zip release and add it to your PATH 10.To generate a converted file we have a script convert-mrdo-to-rgbds.py:python3 scripts/convert-mrdo-to-rgbds.py mrdo.asm build/mrdo.rgbds.asmIf you have RGBDS installed, you can sanity-check that the output parses and links:rgbasm -o build/mrdo.o build/mrdo.rgbds.asmrgblink -m build/mrdo.map -n build/mrdo.sym -o build/mrdo.gb build/mrdo.orgbfix -v -p 0xFF -m 0x00 -t \"MRDO!\" build/mrdo.gbComparing against a retail ROMOnce you have a retail ROM to compare against, you can use the scripts/compare-gb-roms.py helper to quantify how close a rebuilt image is.It supports three useful comparisons: Header sanity - title, MBC type, ROM size byte, plus recalculated header/global checksums. Coverage scan - a fast sliding-window scan that estimates how much of the rebuilt ROM appears verbatim in the retail ROM (useful for data/graphics blocks that should match exactly). Signature search from a map - take a rgblink -m map from the rebuilt ROM and search for N-byte sequences inside the retail ROM to find where specific labels land.Then compare the direct conversion build against your retail ROM:python3 scripts/compare-gb-roms.py \\ --rebuilt build/mrdo.gb \\ --original build/mrdo_original.gb \\ --map build/mrdo.map \\ --scan-map \\ --sig-len 32 \\ --window 256 \\ --stringsCurrent repo comparison resultsThis repository already includes a known-good retail ROM at build/mrdo_original.gb, plus the direct conversion build at build/mrdo.gb.As of 2026-04-19, the headline results are: ROM Size Title Cart type SHA256 build/mrdo_original.gb 64 KiB MR.DO! MBC1 c19f7ec9ff29fa438d7ef189f81711dcaedaa55c86b192d6d9020f5f7dc22702 build/mrdo.gb 32 KiB MRDO! ROM ONLY bb824ead872abaf5055be48c42c01873bbda749afb400353682bea9bfc565fda The direct conversion build does not match the retail binary byte-for-byte (it is a different size and layout), but it still contains many verbatim data/code blocks: Window coverage - at a 256-byte window size, 17024/32768 bytes (52.0%) from build/mrdo.gb appear verbatim somewhere in the retail ROM. Offset equality is low - only 1731/32768 bytes (5.28%) are identical at the same file offsets because the retail image is banked and laid out differently. Different build lineage strings - text like \"CLONE\" / \"TWINS\" / \"REMIX\" appears in the source-derived builds but does not appear in the retail ROM, which is a quick way to confirm you are not comparing a simple re-link.Build completeness sanity checkBecause the direct conversion output is only 32 KiB, it is reasonable to ask whether code went missing during conversion/linking.To make that question testable, we have a small audit script:audit-mrdo-build-completeness.pypython3 scripts/audit-mrdo-build-completeness.pyAt the moment, it reports: every ROM-side “procedure-style” label from the released source snapshot is present in build/mrdo.map. none of those labels were accidentally assembled into a RAM region (they all land in ROM0 or ROMX).Retail bank switching hotspotsThe direct conversion build is a ROM ONLY image and does not contain any cartridge bank switch writes.The retail ROM does, and you can locate the most obvious sites by scanning for LD (a16),A stores into the 0x2000-0x3FFF mapper register range:python3 scripts/scan-gb-mbc1-bankswitch-sites.py --rom build/mrdo_original.gb --markdown --max 30In the current retail ROM, the most common pattern is ld a,imm; ld [$2004],a (still inside the standard MBC1 ROM bank select range).That gives you a concrete place to start debugging retail-only behaviour: set a write watchpoint on $2004 and log which bank numbers are selected before/after big asset loads, menu code, or level setup. compare those call sites against the direct conversion build (which never switches banks) to identify code/data that only exists in banked form in retail.Header-level differencesThe retail ROM’s banking/layout is not described by the header block embedded in the released mrdo.asm.For example, the source’s ORG $100 header declares ROM ONLY and a ROM size code of 0, while the retail ROM is a 64 KiB MBC1 image.Why the banking/layout differsEven when large chunks match byte-for-byte, the bank placement and offsets can still diverge from retail.In practice, the biggest drivers are: Header vs actual cartridge - the embedded header block in mrdo.asm does not reflect the retail cartridge (it declares ROM ONLY / size code 0 while retail is 64 KiB MBC1). Toolchain differences - the original Special FX/Ocean build tools could place and pack data/code into banks differently from modern RGBDS, even when assembling the same logical source. ORG vs final placement - a monolithic file with ORG anchors does not automatically encode the final bank split; a linker/pack step may have decided which blocks live in which bank. Late-stage layout tuning - it is common for a final build to reorder/move blocks to reduce bank switches or reclaim space, without meaningfully changing the underlying logic.The net effect is that a build can have high “verbatim somewhere in ROM” coverage while still having low same-offset equality.Why retail uses MBC1 even if a ROM-only build existsIt is tempting to assume a ROM ONLY image implies the retail cartridge could have used a no-mapper PCB.In practice, a ROM-only rebuild can exist for several reasons that do not contradict a banked retail cart: The converter is a minimal build - the current RGBDS output is aimed at making the release assemble, not reproducing every late-stage asset, layout, or build-flag that shipped. Retail likely had more content - additional assets, levels, audio, bugfix code, region tweaks, or tool-generated tables can push a project past 32 KiB. Banking is also about engineering - even when size is close, MBC banking lets you keep hot code/data in fixed areas and move large/rarely-used blocks into switchable banks. Production standardization - studios often standardized on a cart/PCB type across multiple titles for sourcing and manufacturing, even if some games could technically squeeze into a smaller ROM.Treat the ORG $100 header block in mrdo.asm as “what this particular source snapshot declares”, not as authoritative evidence for the shipped cartridge configuration.What is in the “no 256-byte match” regionsThe 256-byte window scan flags a few large regions where no 256-byte chunk from the direct conversion build appears anywhere in the retail ROM.Those regions are interesting because they are strong candidates for: toolchain-generated tables that never existed in the source snapshot, later bugfix/content additions, code/data that is present in the released source but gets rearranged enough that 256-byte windows no longer line up.In the current build/mrdo_original.gb vs build/mrdo.gb comparison, the largest retail-only regions (window=256) start at: bank1:4600..bank1:7FFF - text/tables-heavy region. bank0:0608..bank0:3FFF - a large ROM0 region with many strings/tables. bank2:4EC0..bank2:7FFF - a large bank 2 region. bank3:4600..bank3:6FFF - a large bank 3 region.If you see: No exact bank matches - that is normal when the layout does not match byte-for-byte. High window coverage - that is a strong sign that many assets are identical, even if the overall banking/layout differs. Repeated signature hits for HEX labels - that is usually where the retail build stores those graphics blocks, and it is a good next target for tightening the placement map.Retail ROM disassembly (mgbdis)RGBDS does not ship a disassembler, so for the retail image the most practical option is mgbdis: Run mgbdis - python3 tools/mgbdis/mgbdis.py --output-dir build/mgbdis-retail --overwrite build/mrdo_original.gb Browse by bank - open build/mgbdis-retail/bank_000.asm (ROM0), build/mgbdis-retail/bank_001.asm, etc. Use the table as an index - if a procedure row is mapped to Retail file offset 0x35A0, that corresponds to a bank_000.asm label like Jump_000_35a0: (and you can search for 35a0).This gives you a stable way to sanity-check the procedure mappings and to dig into retail-only regions without needing a full emulator trace.If you want to start from the retail entrypoint, mgbdis makes it easy to follow the exact flow from the reset vector: Header entrypoint - Boot:: at 00:0100 (nop; jp Jump_000_0150). Post-header jump - Jump_000_0150 at 00:0150 (jp Jump_000_173b). First real init routine - Jump_000_173b at 00:173B (sets SP=$CFFF and begins calling the init/menu/game loop routines).The first few calls in Jump_000_173b are a good place to start comparing factoring differences between retail and the rebuilt image: ROM0 calls - calls like call Call_000_14ba are within bank 0. Banked calls - calls to $4459 / $4432 jump into the ROMX window and rely on the currently selected MBC1 bank.To quickly identify routines that look shared between the source rebuild and retail, you can use python3 scripts/report-mrdo-retail-similar-functions.py, which measures exact byte and opcode-stream similarity for every procedure row that currently has a retail placement.Some of the higher-similarity hits so far include: Map/address helpers - PIXAD, GETMAPHI, GETMAPLODE, GETBYTEHI. Tile/sprite dump helpers - DUMP2BY1, DUMP2BY2, DUMP2BY2SEQU, DUMP2BY2S. Gameplay loops - APLOOP / WORKAPPLE, BADLOOP / WORKBADDIE. Score/text helpers - PUTSCORE, PUTLINE.Rebuilt procedure mapThis table lists every procedure-style label detected in the converted RGBDS output, along with its rebuilt bank:addr location, so you can set breakpoints quickly:The retail columns are best-effort and are only filled when the mapper script can place the routine at a single retail offset in build/mrdo_original.gb using either byte-signature matching or opcode-stream matching (ignoring immediates).The Retail match column gives a rough confidence level: entry - the routine entrypoint bytes match retail (high confidence). in-body - the entrypoint is inferred from multiple in-body signature matches (use as a hint, not proof). opcodes - the instruction opcode stream matches while ignoring immediates (useful when the routine moved, but still a hint rather than proof). candidate - a top-ranked candidate was promoted from the candidates table by passing additional similarity heuristics (treat as a strong hint, but still validate in the retail disassembly). callgraph - promoted by matching the sequence of calls/jumps to already-mapped routines (useful when entry bytes differ heavily, but still validate in the retail disassembly). unverified - the row was previously filled but could not be re-verified by the current mapper settings.The similarity columns are a quick way to see “how close” the mapped routine looks: Retail byte prefix - number of identical bytes from the mapped entrypoint (capped and limited to the routine span within the rebuilt bank). Retail opcode prefix ops - number of matching decoded instruction opcodes (immediates ignored), starting at the mapped entrypoint. Procedure Rebuilt bank:addr Retail bank:addr Retail file offset Retail match Retail byte prefix Retail opcode prefix ops MULTIE 00:06A4           MULTID 00:06A9           MENU 00:363C           SLOGO 00:3661           RESETST 00:366F           LOGOLOOP 00:3699           WORKMENU 00:36B5           EXITMENU 00:36D6           OPTIONS 00:36E2           NEXTUP 00:36FD           NEXTMENU 00:3702           NOGAME 00:370A           NEWSEL 00:3715           NOSEL 00:3723           UPMENU 00:3732           HANDYMAN 00:3743           SOUNDOPT 00:375D           DWMENU 00:3765           LOGOPULSE 00:377B           FADE 00:37D0           LOGOON 00:37E0           LOGON 00:37EB           NOMOV 00:37FE           BARREL 00:3803           BARON 00:3810           RASTARS 00:3823           RASTAR 00:3832           STARFALL 00:3845 00:31D5 0x31D5 in-body 3 27 ANIHEAD 00:3872 00:3202 0x3202 in-body 3 27 MENUOBJ 00:3894           WORKSTAR 00:38AC           STAROFF 00:38B7           NOBOW 00:38E4           DUMP3BY3 00:38F8           SHOWRESULTS 00:395F           SETBIG 00:3989 00:32DA 0x32DA in-body 20 15 RESLOOP 00:39B5           APLM 00:39CE           WORKWELL 00:3A1A           EMOVE 00:3A30           UPWELLY 00:3A3A           UPWELL 00:3A3F           ALLWAIT 00:3A47           ALLMOVE 00:3A51           DODIMOVE 00:3A58           DUMPBIG 00:3A7E 00:33CD 0x33CD entry 21 12 DUMPBG 00:3A93           SHOWAVERAGES 00:3AA2 00:340A 0x340A opcodes 1 13 PUTAVER 00:3ABF           AVELOOP 00:3B10           RESETBOARD 00:3B29           RESETB 00:3B2E           BOARDLINED 00:3B41           BOARDLINE 00:3B61 00:358E 0x358E opcodes 2 12 PUTSCORE 00:3B73 00:35A0 0x35A0 in-body 18 28 TOTOTAL 00:3B9C           UPTOTAL 00:3BA1           DIGITADD 00:3BA6           DUMPENDOBJ 00:3BB8 00:35F6 0x35F6 unverified 5 4 DUMP2BY2SEQU 00:3BBD 00:35FB 0x35FB in-body 44 37 CHECKHIGH 00:3BE9           CHECKLINE 00:3BEE           CHECKCHR 00:3BF4           NEXTLINE 00:3BFF           ISBIG 00:3C08           SHUNTLINE 00:3C11           PUTDIG 00:3C20           PRHIGHSCORES 00:3C39           PRHIGHS 00:3C41 00:3AA7 0x3AA7 opcodes 2 44 PRHGH 00:3C85           DMATRANS 01:40E9           DMAL 01:40EF           SYSETUP 01:40F4           RESETV 01:4101           TOINTRAM 01:4114           GAMESETUP 01:4122           LEVELSETUP 01:4141           ISMISTER 01:4165           RESETSP 01:4198           SETAPPLES 01:41AB           RESETEX 01:41BD           SETET 01:420E           START 01:4219           MAINLOOP 01:4228 00:175D 0x175D callgraph 1 13 EXITLEVEL 01:426A           NOMAPR 01:4288           NOLEVR 01:42A4           WAITISH 01:42AA           WINHOW 01:42B2           EXTRALIFE 01:42BE           SETEXTRA 01:42C8           RESETET 01:42D3           PAUSEGAME 01:42DE           NOSTRT 01:42F3           WAITNOK 01:4303           SPLITSCREEN 01:430A           PRAPPLES 01:434C           PRALOOP 01:4352           APPLEPIE 01:437F           APLOOP 01:4388 00:1942 0x1942 opcodes 2 15 WORKAPPLE 01:439A 00:1954 0x1954 opcodes 11 17 NOAPPLE 01:43AD           NOLFALL 01:43B0           GOSPLIT 01:43B2           APPLEWAIT 01:43BA           APPLEJIG 01:43D5           APPLEFALL 01:43E4           LEEV0 01:4419           LEEV1 01:442B           FLOUT 01:442D           HLOUT 01:443E           REPBACK 01:4440           STOPAFALL 01:444B           APPLESPLIT 01:4455           NOASPL 01:4461           LEEV2 01:4493           LEEV3 01:44A5 00:1ABA 0x1ABA entry 25 23 BRINGON 01:44BE           GETDINO 01:44D2           GETSP 01:44D8           GETAPPLE 01:44E3           GETAP 01:44E9 00:1BE4 0x1BE4 unverified 11 10 FLAGS 01:44F4 00:1BEF 0x1BEF in-body 39 20 NOT3 01:451B           COLLISIONS 01:451F           BALLCP 01:4522 00:1F9D 0x1F9D in-body 18 13 BALLCPL 01:4535 00:1FB0 0x1FB0 in-body 20 22 NBALLCP 01:4551           MRDOCATCH 01:455A           GHOSTDIE 01:4563           NOTLASTG 01:4574           EXDIE 01:4582           GAPPLE 01:45D6           GOAPPLE 01:45DF           GOBALLBANG 01:45FE           BALLSCORE 01:4606           DUFKILL 01:462B           EATCHERRY 01:462D           NOCHSEQU 01:4651           RESCHSEQU 01:4656           EATWALL 01:4668           EATFOOD 01:4675           GETLET 01:46A0           GOTLET 01:46AB           ISOUT 01:46D1           PUTGHST 01:46D8           SETGHST 01:46E1           DECODE 01:46F5           NOGODEL 01:4700           NODECBON 01:470A           DECODER 01:4734           ISSLOW 01:4749           NOSLOW 01:4751           INVALIDX 01:4776           NEWMOVE 01:4790           NOWRAP 01:479D           NOSCROLL 01:47C4           INVALID 01:47DD           DOBALL 01:47E7           BADDIES 01:480E           BADLOOP 01:4813 00:2131 0x2131 opcodes 4 26 WORKBADDIE 01:4835 00:2153 0x2153 entry 18 17 NOBAD 01:4847           CIRCLE 01:484C 00:216A 0x216A opcodes 8 34 MOVEBADF 01:4876           MOVEBAD 01:487B           FINDEXITS 01:4889           NOUP 01:48A4           NORT 01:48B0 00:21DD 0x21DD opcodes 9 15 NODW 01:48C7           NOLF 01:48D3           WORKEXITS 01:48D6           CHANGEDIR 01:48EA           FINDEX 01:48F4           GOEXIT 01:4902           DINODE 01:4907           DINO 01:4909           DINOMOVE 01:491A           DINOEAT 01:492A           DINOPUSH 01:492C           EXDANCE 01:492E           NOEXFL 01:4941           UPTYPE 01:4973           EXUP 01:4979           EXEAT 01:4985           EXWALK 01:4987           EXMOVE 01:4998           EXOUT 01:49A1           GHOST 01:49A3           GHOSTMOVE 01:49B4           GHOSTR 01:49C0           GHOSTEAT 01:49C7           CARRYBALL 01:49C9           THROWBALL 01:49EE           CDEL0 01:49F8           ISCHN 01:4A06           NOCHWL 01:4A16           BCHECK 01:4A24           NRNDB 01:4A3A           NOBHIT 01:4A3D           NOCHN 01:4A41           OUTBALL 01:4A50           GOINBALL 01:4A7D           INBALL 01:4A87           INBALL0 01:4A91           INBALL1 01:4A9B           POINTS 01:4AC3           DUMPOBJ 01:4ACF 00:27C2 0x27C2 in-body 18 9 MPLEX 01:4AEE           DUMPL 01:4B14           DUMP2BY1 01:4B29 00:283A 0x283A entry 37 30 DUMP1BY1 01:4B4F 00:2861 0x2861 in-body 28 21 DUMP2BY2 01:4B73 00:2884 0x2884 entry 19 14 DUMP2BY2S 01:4B86 00:2897 0x2897 in-body 13 59 MRDOCHEW 01:4BCA           GOCHEW 01:4BE1           CHEWS 01:4BF2           CHEWUP 01:4C14           CHU0 01:4C21           CHU1 01:4C32           CHU2 01:4C49           CHU3 01:4C5A           CHEWRT 01:4C61           CHR0 01:4C6E 00:2916 0x2916 candidate 13 14 CHR1 01:4C7F           CHR2 01:4C96           CHR3 01:4CA7           CHEWDW 01:4CAE           CHD0 01:4CBB           CHD1 01:4CCC           CHD2 01:4CE3           CHD3 01:4CF4           CHEWLT 01:4CFB           CHL0 01:4D0A           CHL1 01:4D1B           CHL2 01:4D32           CHL3 01:4D43           CHRDUMPER 01:4D4A           CDUMP 01:4D59           PRSCORE 01:4D64           SCOREADD 01:4D81 00:2AAA 0x2AAA opcodes 3 15 UPSCORE 01:4D97           NOSCRP 01:4DA3           CLOCK 01:4DA5 00:2ACE 0x2ACE opcodes 1 13 UPCLOCK 01:4DC0           STATUS 01:4DC5           STATSP 01:4DDE           PUTSSP 01:4DF4 00:2B44 0x2B44 in-body 23 30 ONSTAT 01:4E1A           DRAWMAP 01:4E22           FILLMAP 01:4E28           FILLBYTE 01:4E3F           PUTFOOD 01:4E76           DRAWBLOCK 01:4E91 00:2C07 0x2C07 opcodes 5 12 DRWBLOCK 01:4EA1 00:2C17 0x2C17 in-body 1 22 DOTUNNEL 01:4EB9 00:2C2F 0x2C2F opcodes 10 19 DRAWREP 01:4ED2 00:2C48 0x2C48 opcodes 11 15 ENDTUNNEL 01:4EE6           PUTCHERRY 01:4EEF 00:2C65 0x2C65 opcodes 12 26 PUTAPPLE 01:4F1F           COPYMAP 01:4F41           COPYM 01:4F4A           COPYLETTER 01:4F53 00:2CCE 0x2CCE opcodes 3 26 PUTLINE 01:4F80 00:2CFB 0x2CFB in-body 54 41 KEYS 01:4FB6           PIXAD 01:4FED 00:2D63 0x2D63 entry 23 13 GETMAPHI 01:5004 00:2D7A 0x2D7A entry 23 13 GETMAPLODE 01:501B 00:2DBA 0x2DBA entry 18 13 GETMAPLO 01:502D 00:2DA8 0x2DA8 entry 18 13 GETBYTEHI 01:503F 00:2DCC 0x2DCC unverified 14 10 GETBYTELO 01:504D           LOWAD 01:5059 00:2DE6 0x2DE6 in-body 18 13 WAITSC 01:5070           RESETOBJ 01:5078           RESETOB 01:5087           RESETO 01:508B           RAND 01:5097           PRINTEXT 01:50B1 00:2E45 0x2E45 unverified 8 8 TEXTL 01:50B9 00:2E4D 0x2E4D unverified 8 6 PRINTSHAPE 01:50C1           YROWS 01:50C5           XROWS 01:50C7 00:2E5B 0x2E5B entry 19 16 DIVIDE 01:50DA           DIVE 01:50DE           CREATESET 01:50E6 00:2EAC 0x2EAC opcodes 15 18 CLEARSET 01:50FB           SHUNT 01:5106           DISPBIN 01:510F           DOBIN 01:5114 00:2EDA 0x2EDA unverified 7 4 ISNONE 01:511B 00:2EE1 0x2EE1 unverified 5 4 CLEARSTAT 01:5120 00:2EE6 0x2EE6 unverified 11 4 CLR 01:512B           HEXBYTE 01:5134           HEXWORD 01:5139           PRHEX 01:5143 00:2F09 0x2F09 opcodes 4 15 PRDEC 01:5158           PRDECDIGITS 01:5160           PRDEC1 01:516B           Retail offsets for known verbatim code blocksIf you want to map the retail ROM quickly, these labels have a unique 32-byte verbatim signature match inside build/mrdo_original.gb (found by scanning build/mrdo.map against the retail binary): Label Retail bank:addr Retail file offset STATLINE 00:0D44 0x0D44 LOGO 00:0E3B 0x0E3B GETAP 00:1BE4 0x1BE4 FLAGS 00:1BEF 0x1BEF CIRCLE 00:216A 0x216A DUMP2BY1 00:283A 0x283A DUMP2BY2 00:2884 0x2884 DUMP2BY2S 00:2897 0x2897 PUTLINE 00:2CFB 0x2CFB PIXAD 00:2D63 0x2D63 GETBYTEHI 00:2DCC 0x2DCC PRINTEXT 00:2E45 0x2E45 TEXTL 00:2E4D 0x2E4D DOBIN 00:2EDA 0x2EDA ISNONE 00:2EE1 0x2EE1 CLEARSTAT 00:2EE6 0x2EE6 DUMPENDOBJ 00:35F6 0x35F6 DUMP2BY2SEQU 00:35FB 0x35FB These are also good candidates for setting breakpoints in SameBoy, because you can place the breakpoint at a confirmed retail address and then work backwards to the calling code.Retail offsets for known verbatim asset blocksIf you are mapping data/graphics rather than code, these blocks also have unique 32-byte verbatim matches in the retail ROM: Label Retail bank:addr Retail file offset Hit count CHRTABLE 00:0400 0x0400 1 CTAB 00:09A8 0x09A8 1 WAVETAB 00:0AA4 0x0AA4 1 CMRDO 01:4600, 03:4000, 03:4600 0x4600, 0xC000, 0xC600 3 CBADS 01:4C00, 03:4C00 0x4C00, 0xCC00 2 CLOGO 02:4080 0x8080 1 CSTAR 02:47F0 0x87F0 1 CICONS 02:4B20 0x8B20 1 CHEADS 02:4D60 0x8D60 1 CFINI 02:5840 0x9840 1 CMRSDO 03:4300 0xC300 1 When a block has multiple hits, it means the same 32-byte signature occurs in multiple places in the retail ROM (so treat those offsets as “this data exists here”, not “this is the only copy”).Rebuild feasibility checklistIf you want to go from “interesting source release” to a reproducible modern build, these are the main technical unknowns to resolve: Interrupt vectors - SYSETUP sets IE=1 and executes EI, but mrdo.asm does not obviously define an ISR ending in RETI. You will want to verify what the original ROM has at $0040 and friends before leaving IME enabled. Header fields - The header code writes CARTRIDGE TYPE = 0 (ROM-only) and ROM SIZE = 0 (which is 32 KiB in the standard header encoding), but the comment claims 256K. A rebuilt ROM must pick consistent header values and banking strategy. Banking model - The file uses fixed ORG placements and does not contain explicit MBC register writes, which is consistent with ROM-only or a custom build step that split content across banks. If the retail game is larger than 32 KiB, you will need to decide how to map this file into ROM0/ROMX.Key takeawaysIf you want a quick summary of what makes this source release interesting from a reverse engineering perspective: RAM mirror + dirty queue - BACKSCREEN acts as the canonical map state and CHRDUMP batches the VRAM writes for VBlank. Macro-cell control map - BYTESCREEN turns map semantics into a simple 0..4 lookup (EATJP), separating gameplay rules from tile stamping. Table-driven everything - Actors, apples, collisions, and menus all lean on jump tables rather than deep branch trees. Timing-first renderer - The split-screen HUD is a deliberate LYC-timed LCDC toggle with an OAM DMA swap mid-frame. Pragmatic performance guards - Small flags like SPLAT and amortized updates like PRSCORE keep worst-case frames under control.Fun breadcrumbs in the commentsThe release is full of tiny details that give it some personality and make it easier to follow.Some examples you will see while browsing: “STOPS STUPID BUG!” - A defensive load before a compare in the status-sprite dump routine. HIGHBUFF - A hardcoded string containing FROBUSH HERE in the high-score data block.References Mr. Do! for Game Boy review video ↩ Paul Hughes - Mr Do GB source (mrdo.asm) ↩ ↩2 Paul Hughes - Downloads ↩ ↩2 ↩3 Pan Docs (Game Boy technical reference) ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 SameBoy debugger documentation ↩ RGBDS documentation ↩ ↩2 Paul Hughes tweet about dev hardware/toolchain ↩ Installing RGBDS on macOS ↩ Installing RGBDS on Linux ↩ Installing RGBDS on Windows ↩ ", "excerpt": "Introduction This page documents the official release of the assembly source for Ocean Software’s Mr Do! port to the Game Boy. It focuses on what the code is doing (maps, chewing, actors, rendering timing, and data formats), plus how to verify it in SameBoy. Start here If you only read...", "tags": ["gameboy","games","sourcecode"], "image": "/public/generated/placeholders/mrdo.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "N64 Reversing Emulator - Mupen64+ RE", "url": "/mupen64RE", "content": "Introduction Mupen64+ Reverser Edition (RE) is a fork of the Mupen64+ Nintendo 64 emulator tailored for reverse engineering. The main aim is to generate information that will be useful for the disassembling and decompilation of your chosen game. It does this by tracing and logging information about asm instructions, functions, memory addresses, DMAs etc as the user plays the game. The main output after the user has finished playing is a couple of files: an n64split config file and a tracing JSON file. FeaturesAuto detection of ASM regions Using DMA and TLB data we can auto detect regions of the rom which are interpreted as assembly instructions and use this information to write out a N64Split config file with asm region information. Auto detection of data reads to ROM addresses Using DMA and TLB tracing information we can generate a list of sections in the rom which are used to transfer data to memory. We also log the 4 byte header of each region which can be very useful for finding compressed data, e.g MIO or RNC are common headers. This information is written out into the n64split config file allowing the splitter to separate binary sections from assembly and eventually to use the header information to generate uncompressed assets. Auto detection of Function names We provide a json file with common function signatures from libultra, this is used to auto detect which functions are included in the game and putting a name to the function. This information is also written out into the n64split config file as a label which can further help the process of starting a new reversing project. Finding common functions across games We store the byte pattern of every function we come across while playing multiple games and can use this information to find common functions across games. This can be very useful for finding common libraries used across multiple games as well as finding out common game engines used by companies. It was very common for the same development house to use a game engine for multiple games, one example is the Turok2 engine being used for the South Park game. This also means we only need to name a function once and it can be detected in other games, sharing the knowledge between multiple projects. This information is written out into the labels section of the n64split config file and if you find functions with names that start with a different game name then you have likely found a common library or engine function. Here is part of the n64split label output of playing a single race in top gear overdrive, note that it finds common functions that it has seen before when playing Road Rash and BlastCorps. Along with finding common libultra symbols. Auto detection of Audio regions Logging of the RSP Audio decoding allows us to identify which parts of the rom are audio files. Configurable Dynamic Memory Corruption One effective way to find out what to name certain areas of a rom is to corrupt it and witness the result. For example we currently detect audio regions of the rom but can’t detect WHAT audio is playing, to help with this we support custom config parameters that allow you to choose the section to corrupt at runtime, allowing you to effectively name unmapped regions of the ROM. Printf Logging (osSyncPrintf) Sometimes the developer leaves in printf statement to help debugging, we can log these to json and also print them to the console, also useful for homebrew development. Future Plans Auto detection of Texture/3D data? Auto detection of memcopy Auto detection of uncompression routine config file to load what to log More ultra64 signatures (use Zignature format?) Auto Detection of Audio/Input/Display functions option to collapse audio regions into smaller regions log function calls replace functions with javascript auto detect rsp.boot— Download & Source Code You can get a pre-built MacOSX binary for intel Mac’s only here:MACOSX Release Or you can build it yourself by cloning the github repository: RetroReversing/mupen64plus-core: Core module of the Mupen64Plus Reversing EmulatorRunningwhen you have compiled the code you will get a dynamic library file (*.dylib on mac, *.so on linux and *.dll on windows) you can run mupen using this core like so:./mupen64plus --corelib ./libmupen64plus.dylib --gfx ./mupen64plus-video-glide64mk2.dylib --noosd ./example.v64The easiest way to to change the runme.sh script in the pre-built binaries to the ROM you want and to copy the rom into the same folder.e.g edit runme.sh to the following:./mupen64plus --corelib ./libmupen64plus.dylib --input ./mupen64plus-input-sdl.dylib --gfx ./mupen64plus-video-glide64mk2.dylib --noosd --emumode 0 \"./YOUR_ROM_FILE.v64\"This will create a few files while running the game, a .yaml and a .json based on the game name of the ROM.", "excerpt": "Introduction Mupen64+ Reverser Edition (RE) is a fork of the Mupen64+ Nintendo 64 emulator tailored for reverse engineering. The main aim is to generate information that will be useful for the disassembling and decompilation of your chosen game. It does this by tracing and logging information about asm instructions, functions,...", "tags": ["n64","reversingEmulator"], "image": "/public/N64/N64ReversingEmulator.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Mupen64+ Emulator Source Code Analysis", "url": "/mupen64sourcecode", "content": "IntroductionThe Mupen64+ emulator is one of the best open source emulators available for the Nintendo 64, so if you are interested in emulator development or how the Nintendo 64 works then this post should help.This post will be a sort of Cliff Notes to give an overview of how the emulators source code is laid out and should give you an idea on where to start looking for what you are interested in.Compiling the EmulatorThe first step is to compile the emulator on your system, this will allow you to experiment by changing variables and functions to help you better understand the emulator.Building for MacOSXBuilding the emulator in MacOSX is fairly straightforward as long as you have all the dependencies installed.First install dependencies in Brewbrew install pkg-config libpng sdl freetype nasm binutilsRun MakeThis step is common among all the Operating systems, the DEBUGGER=1 parameter is used to enable debug mode so that you can step through the N64 MIPS assembly instructions one at a time and even supports creating basic breakpoints.make all DEBUGGER=1Common Errors when buildingThis section is a reference to be used only when you have a problem compiling the emulator, otherwise it can be ignored.‘cmath’ file not foundIf you get this error you will need to modify the MakeFile and change -mmacosx-version-min= in both places to the version of your OS (e.g 10.14)unrecognised output format `macho64’If you get the following error:nasm: fatal: unrecognised output format `macho64' - use -hf for a listThen make sure to install a new version of nasm, as it is most likely out-of-date:brew install nasm ‘dis-asm.h’ file not foundIf you get an error about dis-asm.h such as:../../src/debugger/dbg_memory.c:37:10: fatal error: 'dis-asm.h' file not found#include <dis-asm.h>You need to install bin-utils via brew and then you need to run the following in your current bash session:export LDFLAGS=\"-L/usr/local/opt/binutils/lib\" export CPPFLAGS=\"-I/usr/local/opt/binutils/include\"So We get further but now an new error probably due to the version of binutils:../../src/debugger/dbg_memory.c:113:19: error: use of undeclared identifier 'print_insn_i386'; did you mean 'print_insn_m32c'? disassemble = print_insn_i386;To fix this I simply added this to the top of the file called dbg_memory.c:#define USE_LIBOPCODES_GE_2_29 1Undefined symbols Linker errorsIf you get lots of Undefined symbol linker errors such as the following:Undefined symbols for architecture x86_64: \"_htab_hash_pointer\", referenced from: _xcoff_archive_info_hash in libbfd.a(xcofflink.o) \"_libintl_dngettext\", referenced from: _ppc64_elf_build_stubs in libbfd.a(elf64-ppc.o) \"_xexit\", referenced from: _spu_elf_final_link in libbfd.a(elf32-spu.o) \"_hex_init\", referenced from: _ihex_object_p in libbfd.a(ihex.o) _srec_object_p in libbfd.a(srec.o) _srec_mkobject in libbfd.a(srec.o) _symbolsrec_object_p in libbfd.a(srec.o) _tekhex_init in libbfd.a(tekhex.o) _verilog_mkobject in libbfd.a(verilog.o) \"__hex_value\", referenced from: _ihex_object_p in libbfd.a(ihex.o) _ihex_get_section_contents in libbfd.a(ihex.o) _srec_object_p in libbfd.a(srec.o) _srec_get_section_contents in libbfd.a(srec.o) _srec_scan in libbfd.a(srec.o) _tekhex_object_p in libbfd.a(tekhex.o) _getvalue in libbfd.a(tekhex.o) ...This is due to brew not installing libiberty.a library file. I found it quite difficult to fix using brew so I installed macports and ran:sudo port install x86_64-elf-binutilsThe look in the folder: /opt/local/x86_64-elf/host/lib and you will find a libiberty.a file, copy this across to: /usr/local/opt/binutils/libcp /usr/local/opt/binutils/lib/libiberty.a /usr/local/opt/binutils/libOk now we have a lot less linker errors we now just need to find libintl.Now finally change the Makefile on line 643 to add -L/usr/local/opt/binutils/lib -liberty -lintl -liconv so it should look like:ifeq ($(DEBUGGER), 1) SOURCE += \\ $(SRCDIR)/debugger/dbg_debugger.c \\ $(SRCDIR)/debugger/dbg_decoder.c \\ $(SRCDIR)/debugger/dbg_memory.c \\ $(SRCDIR)/debugger/dbg_breakpoints.c LDLIBS += -lopcodes -lbfd -L/usr/local/opt/binutils/lib -liberty -lintl -liconvif you get the following error:ld: library not found for -lintlThen run:brew link gettext --forceSo Finally we have a libmupen64plus.dylib with the debugger enabled! Now what? How do we use it?! Well first we need a few plugins to be compiled to be able to render graphics.Compiling Glitch64In order to compile Glitch64 you will need to make sure you have boost installed, which you can do via brew like so:brew install boostAlso I had to change line 137 of MakeFile to match the following:CFLAGS += $(OPTFLAGS) $(WARNFLAGS) -ffast-math -fno-strict-aliasing -fvisibility=hidden -I../../src -I../../src/Glitch64/inc -DGCC -I/usr/local/Cellar/boost/1.67.0_1/includeNow Glitch64 should be able to be compiled with make.Building the Console ApplicationFinally the Console Application is the last piece of the puzzle, this is what will actually execute the emulator, so when this is built we will be able to run games!You will need to point APIDIR to the location of the core source code you checked out earlier.make APIDIR=/../mupen64plus-core-master/src/api DEBUG=1 allThe console application is the simplest frontend for the emulator and it also has a very basic debugger in it.Now copy over the plugins that you have built previously such as glide64.Running the emulatorNow the run the emulator! The emulator comes with an example public domain rom file called example.v64, this ROM only seems to work with glide64 graphics for me. You can run it like so:./mupen64plus --emumode 0 --corelib ./libmupen64plus.dylib --gfx ./mupen64plus-video-glide64mk2.dylib ./example.v64Running With DebuggerYou can run the emulator with the debugger enabled by passing a few extra parameters like so:./mupen64plus --corelib ./libmupen64plus.dylib --gfx ./mupen64plus-video-glide64mk2.dylib --emumode 0 --noosd --verbose --debug ./example.v64In debugger mode PC starts at 0xA4000040 (2751463488) with:mtc0 $zero,C0_CAUSEMupen64+ FeaturesGlideHQ (Texture upscale)GlideHQ is a texture upscale for the Glide graphics emulator plugin. This uses a number of different upscaling algorithms to make textures look higher quality than the what the original hardware supported.GlideHq comes as part of the Mupen64+ Glide64 source code.Source code analysisDevice folderContains most of the emulator logic for the N64.r4300_coreThe r4300 is the main CPU used in the Nintendo64, it is based on the R4200 by MIPS Technologies Inc. R4200 - WikipediaThe main implementation of the cpu is contained in the r4300_core folder along with implementations of the 3 co-processors (cp0, cp1 and cp2).More information about the CPU can be found here:N64 Programming/CPU overview - Wikibooks, open books for an open worldrdp_corersp_coreai_controllermi_controllerpi_controllerri_controllersi_controllervi_controllerpif;rdrammemorygame_controllerbiopakmempakrumblepaktransferpakgb_cartcart cart_rom.c - cartridge stuff like DMA sram.c/eeprom.c/flashram.c - saving stuff with the Controller Pak (list of games that use this: http://micro-64.com/database/gamesave.shtml )IPL2 is the PIF ROM?IPL3 is the first 1MB of CART?dd_controller", "excerpt": "Introduction The Mupen64+ emulator is one of the best open source emulators available for the Nintendo 64, so if you are interested in emulator development or how the Nintendo 64 works then this post should help. This post will be a sort of Cliff Notes to give an overview of...", "tags": ["n64"], "image": "/public/N64/N64Mupen64SourceCodeAnalysis.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo 64 (Project Reality) Reversing", "url": "/n64", "content": "Introduction to Hacking the Nintendo 64Interested in learning more about the the N64? Excellent! This section will guide you through the basics, starting from basic MIPS assembly language all the way to an introduction to reverse engineering your first game! N64 Reversing Introduction For an introduction on reverse engineering N64 games check out this post. Nintendo 64 EmulationWe recommend using the Reversers Edition of the Mupen64+ emulator as it provides useful features for reverse engineering such as auto detection of functions. N64 Reversing Emulator - Mupen64+ RE Check out the N64 Reversing Emulator to help create full game reversals for your favourite game. Nintendo 64 Assembly Language (MIPS)Although most Nintendo 64 games are written in C or C++, they all get compiled down to MIPS assembly code, so this is what you will mainly be working with when reverse engineering, so it is good to at least have a basic knowledge before getting started. N64 MIPS Assembly Video Tutorials For an introduction to N64 MIPS assembly check out this set of video tutorials. Nintendo 64 Boot CodeEvery game produced for the N64 required a little piece of code known as the “bootloader” or boot code to initialise the state of the console. You don’t have to know anything about this, apart from that it exists and tends to execute in the address space 0xa4000000 to 0xa4000b64. N64 Boot Code Analysis For more information on the boot code check out this post. N64 GamesPrototypes & DemosAlthough Nintendo 64 didn’t have a massive library of games compared to its rival the Playstation, there has been a huge interest in finding and preserving early prototypes of the games, which are normally found on development (Flash) cartridges. List of Nintendo 64 Prototypes - Hidden Palace Hidden Palace has the most complete list of released Nintendo 64 Prototypes and Demos, check it out here. Nintendo 64 ExclusivesWhen it comes to finding a game to reverse engineer it can be helpful to look at games that are cross-platform to compare builds.But the most valuable reverse engineering projects tend to be the platform exclusives as these are games people can no longer play on modern consoles. List of Nintendo 64 Exclusive Games - N64 Squid The website N64 Squid has compiled an excellent list of games that have never been re-released and thus need N64 hardware to be able to play Wikipedia also maintains a list of N64 exclusives - Nintendo 64-only games - Wikipedia.N64 Limit PushersThe Youtuber Sharopolis has an excellent video talking about the games that really pushed the limits of the Nintendo 64 Hardware.While the N64 is good at rendering 3D graphics, it struggles with textures due to its 4KB texture cache limitation. This results in the console being unable to display high-resolution detailed textures. However, the N64 can filter low-resolution textures, creating a smoother appearance. Beetle Adventure Racing exploits this feature to create realistic environments.One of the standout visual features of the game is the reflection effect on the cars, achieved through a technique likely involving a frame buffer as a texture. The game also showcases other graphical effects such as particle effects, motion blur, fog, and real-time shadows. Beetle Adventure Racing maintains a solid framerate, though it doesn’t reach 60 FPS.F-ZeroF-Zero is a standout N64 game with a consistent 60 frames per second, which was rare for games in that era. Smooth action was important for this fast-paced game, and it achieved this by keeping the graphics simple, focusing on essential elements like the track and cars. Nintendo’s expertise made the simplicity feel like a stylistic choice.Factor 5 gamesFactor 5 developed three visually impressive N64 games: Rogue Squadron, Star Wars Episode 1: The Battle for Naboo, and Indiana Jones and the Infernal Machine. These games featured high polygon environments, excellent lighting and shadow effects, great character animations, and higher resolutions. Factor 5 achieved these improvements through custom micro code for the N64’s reality signal processor, allowing for better performance and more complex scenes.Resident Evil 2The most impressive console port of all time is Resident Evil 2 on the N64. It was a surprise to see on the N64 due to storage space limitations, as N64 cartridges maxed out at 64 megabytes, while CD ROMs on PlayStation and Sega Saturn had capacities over 600 megabytes. The two-disc game was compressed to fit in a 64-megabyte cartridge through data compression techniques. Comparing the two versions, the PlayStation’s cutscenes look slightly better, but the N64 version has higher quality music. The N64 managed to achieve full motion video through its powerful CPU and Graphics co-processor.Rare gamesRare games, particularly Perfect Dark, pushed the N64 to its limits, making brilliant use of limited textures, layering, and variety. Perfect Dark showcased a range of impressive effects like volumetric lighting, corona effect, and a reflective floor in the main hub. Despite its lower resolution and frame rate compared to Factor 5 games.Making of Goldeneye 007The Youtuber OnaRetroTip has an excellent documentary about the making of Goldeneye 007 which goes into incredible detail about the development of the game.It mentions a few interesting things: The working ZX Spectrum emulator added to the game by Steve Ellis. They hired a number of the developers through adverts in the EDGE magazine. They used Alias Wavefront Version 4 (later became Maya) which Brett Jones needed to learn from scratch from Video Tapes and a Book. (I wonder which book it was?!) They used the ONYX 2 Reality Engine which had a N64 simulator on it, it also had a networked flight simulator on it with a dog fighting game mode! They created a Virtual Memory system for the N64 to swap memory in and out of the cartridge. They created a scripting system for the enemy AIs which were a list of instructions (byte data) which was simpler than writing it in C. Mark Edmonds had to create a pipeline for converting the graphics/animations so they could be played on the console. They used NinGen (Multigen) to place all the objects in the level.N64 Game Reverse EngineeringRecently there has been a growing interest in reversing Nintendo 64 games back to source code that when compiled is binary-compatible with the original ROM.These projects take a very long time but in the end are hugely rewarding, they result in full source code that can be compiled and even ported to other hardware. N64 Decompiling with Ghidra If you are interested in Decompiling a Nintendo 64 game with Ghidra check out this post. With the source code available it is trivial to understand how the game works and can be the basis for future game mods that are many times more complex.This can be beneficial for game developers and anyone who is interested in how games are made, they can also be beneficial for speed runners due to the better understanding of how to exploit the game.Super Mario 64 Super Mario 64 For an example of a decompilation project for Super Mario 64 check out this post. Mario Kart 64 Mario Kart 64 For an example of a partial reversal of Mario Kart 64 check out this post. Legend of Zelda Ocarina Of Time Legend of Zelda Ocarina Of Time Decompilation Check out the Legend of Zelda Ocarina Of Time decompilation project on Github! Legend of Zelda Majora’s Mask Legend of Zelda Majora's Mask Decompilation Check out the Legend of Zelda Majora's Mask decompilation project on Github! Game ModdingUnlike a full game reversal project a Mod goes in the opposite direction by changing the original game to add new levels, textures, music and even alter the games code and physics engine.The Game Modding category also includes translation patches to convert the game’s text to another language, which can bring many region-exclusive games to a world-wide audience.HD Texture PacksNintendo 64 games can look a bit dated due to their low resolution textures, but it is possible to replace these textures with High Definition versions using an emulator!HD Texture pack showcase In this HD Texture pack showcase by **Gaming Revived** you can see some of the awesome work that can be achieved using **Esrgan** which is software that uses machine learning algorithms to upscale images.</div>N64 Cheats, Secrets & GlitchesWhether you just want to get further in your favourite game, unlock hidden content or even completely corrupt/glitch the game, you can use a cheat cartridge such as Action Replay or emulator memory editing to change games in real-time. Emulator Game Memory corruption For details about corrupting ROMs and memory at runtime to create check out this post. Mystical Ninja N64 Memory ROM Editing60namrruC has a video covering Mystical Ninja N64 Memory ROM Editing utilizing CheatEngine alongside the Mupen64 emulator. The author goes over the progress made in reverse engineering and understanding the memory layout of the Mystical Ninja Starring Goemon ROM file, showcasing findings that are documented in text files and a collaborative CheatEngine table.Mupen64 allocates a specific block of host PC memory to simulate the N64’s physical RDRAM.Rather than statically decompiling the ROM binary block by block, he attaches CheatEngine directly to the running MuPen64 executable. This hooks into the emulator’s memory space, allowing the user to view, freeze, or write over raw hexadecimal values in real-time as the N64 game executes instructions.State Isolation and Sub-SearchingTo identify unknown memory addresses governing specific game mechanics (such as Goemon’s health, Ryo currency, or X/Y/Z coordinates), the researcher uses an iterative scanning technique known as sub-searching. First, an initial broad scan is made for a known integer or float value (e.g., current health). The researcher then intentionally alters that state in the emulator (e.g., taking damage). A secondary “sub-search” is executed exclusively within the previous subset of results for the new value. This rapidly filters out dynamic background data, narrowing thousands of addresses down to the exact hex offset governing the targeted mechanic.Documenting the ROM StructureOnce dynamic RAM addresses are confirmed, the technical hurdle is understanding how these align with the data structures loaded from the game cartridge. The progress showcased involves taking these isolated addresses and compiling them into a collaborative CheatEngine table (.CT file) and documented text maps. This shared structural blueprint allows multiple reverse engineers to manipulate game logic and aids in broader N64 decompilation efforts.N64 Anti-piracyThe main Nintendo 64 anti-piracy measure was the enhanced CIC chip based on the Super Nintendos CIC chip design but far more secure.This was a mechanism to prevent cartridges being produced without Nintendo’s licensing fee.3rd Party tricks for unlicensed CartsDuring the N64’s lifetime there were various unlicensed devices that ignored the CIC chip such as game backup devices (e.g Bung’s Dr V64), game cheat cartridges (e.g Equalizer/Action Replay) and region unlockers (Passport Plus).Most required a legitimate cartridge to be inserted into the back and used that for the CIC chip communication. Datel Action Replay Professional (N64) For more information on the Action Replay Cheat Code Cartridge check out this post. Piracy DevicesDuring its lifetime the Nintendo 64 had its share of piracy problems, although no where near the extend of its competitor the Sony Playstation it was still possible to backup and run backup games via hardware such as the Doctor V64.Development Kits (Hardware)Development kits are released to game developers before the launch of the system to allow games to be developed for the system’s launch. These systems would evolve over the systems lifespan and contained useful features for debugging and optimising games for the platform. These systems were not just limited to the official offerings by Nintendo as a few other publishers had their own versions of development hardware.Official Development KitsThe official development kit for the N64 was a partnership between SGI and Intelligent Systems and the hardware evolved over time. The first development kit released was a modified SGI ONYX provided by SGI and contained similar hardware to the final N64. Nintendo 64 (Ultra 64) Development Kit Hardware (Official & Unofficial) For more information on the original N64 Devkit check out this post. 3rd Party Development KitsThere were a few third party developers who created their own custom development kits for the Nintendo 64. One of the main developers for 3rd party devkits was SN Systems with their Maestro64 aimed at 3D and Sound artists and with a much cheaper price tag than an official N64 devkit. Maestro64 For more information on the SN Systems Maestro 64 check out this post. Software Development KitsOfficial Software development kitA version of the Nintendo 64 SDK was released on the internet allowing you to use the same tools that your favourite developer used back-in-the-day. This can be useful if you are aiming for a 100% accurate decompilation of a game that can be compiled to the byte-identical ROM. Official Nintendo 64 SDK For more information on the released n64 SDK check out this post. Official SDK Setup Instructions Official N64 SDK Setup (MacOSX/Linux/Win) For more information on how to setup the released n64 SDK check out this post. 3D Modelling toolsDuring the Nintendo 64s lifetime 3D modelling tools evolved at an incredible pace. 3D games were the new trend which pushed developers into creating new 3D games in order to get published. N64 3D Modelling Software If you are interested in how 3D models were created for the N64 check out this post. Nintendo 64 Sound and MusicThe Nintendo 64 has some of the most beloved video game soundtracks with classics such as Banjo-Kazooie, Buck Bumble, Super Mario 64 and many more. N64 Sound and Music If you are interested in how sound and music was implemented into your favourite games check out this post. Retail N64 hardwareWhen the N64 was launched it was the most powerful game console on the market and brought incredible processing power into the home. The hardware was state of the art and exploring how it was developed is a fascinating topic.ConsoleThe Console itself was built by a partnership between Nintendo and SGI and contained a 64-bit MIPS CPU along with a custom chip known as the Reality Co-Processor which handled graphics and vector calculations along with a few other functions. Nintendo 64 Hardware Architecture For more information on the N64 hardware architecture check out this post. ControllerThe N64 controller was a very distinctive shape, some people loved it and others hated it, but we can all agree it was a unique experience. If you are interested in how the controller hardware works then check out this excellent article by HowStuffWorks. Controller - How N64 Works | HowStuffWorksCartridgeNintendo made the controversial decision to continue using cartridges for its next-gen console after the Super Nintendo, this has the benefit of excellent loading times compared to CDs but came at the cost of a smaller capacity and higher cost to produce.Source CodeOfficial Source CodeUp until very recently there has been little official N64 source code released, just a few examples that come with the released SDKs. This changed very suddenly when 2 retail games had their source code leaked at roughly the same time, these games were Turok - Dinosaur Hunter and Mortal Kombat 64.Studying the source code for these games can give vital insight into what it was like developing games back in the mid to late 90s when the Nintendo 64 was at the cutting-edge. The information gained from this can be very useful to help you reverse engineer the games back into retail-like source code. Turok 64 Official Source Code Analysis For more information on the released turok64 source code check out this post. Homebrew Source CodeThere are some fantastic open source projects in the Nintendo 64 homebrew community, these range from tech demos to full games and everything in between.One excellent example of source code provided by the homebrew community is Peter Lemon’s N64 Bare Metal Mips programming examples:PeterLemon/N64: N64 Bare Metal Mips Assembly ProgrammingEmulator Source CodeOne of the best ways to learn how the Nintendo 64 worked is to take a look inside the source code of an emulator, by modifying it and seeing the results on your favourite games you can start to understand why it worked the way it did. Mupen64+ Emulator Source Code Analysis For a walkthrough of the Mupen64+ source code check out this post. Writing a N64 Emulator in RustThe Youtuber Ferris (ferrisstreamsstuff) has an excellent playlist taking you right from the start to a working N64 emulator:All Posts BroadOn Archive - Nintendo May 2020 Leak (4Chan) In early May 2020 a leak of Nintendo Source Code hit the popular image board 4chan. The material contained in this leak was obtained by a young hacker known as... ... Read More wii n64 sdk leak ique Datel Action Replay Professional (N64) Datel Action Replay Professional V-Ram functionality You could press a “Freeze button” on the Action Replay to “see images not normally visible during playing of the game”. The video seems... ... Read More n64 memory cheatcartridge datel N64 Decompiling with Ghidra Importing a Nintendo 64 ROM Download and Install Ghidra Before following the steps on this post please make sure you have a working Ghidra environment setup. So you should be... ... Read More introduction tutorial n64 ghidra Gigaleak 2 Electric Boogaloo - N64 Source Code Leak On the 25th of July 2020, the day after the Gigaleak, its sequel Gigaleak 2 was uploaded to a thread on 4chan. This is a continuation of the leaks that... ... Read More n64 sdk leak Maestro64 SN Systems Maestro64 was a development kit sold to game studios in the late 1990s mainly for use by 3D artists, Sound designers and the like rather than programmers. It... ... Read More n64 devkit hardware snsystems Mario Kart 64 Introduction to Mario Kart 64 The Game was made by Nintendo EAD and was released in Europe on June 24th, 1997. The development team consisted of 8 programmers under the... ... Read More n64 games Memory Hacking Memory Hacking One excellent way to get started modifying your favourite game is to use memory hacking techniques. By learning what memory locations are used for specific functions you can... ... Read More n64 memory introduction Emulator Game Memory corruption Introduction Game corruption has become a hot topic recently due to many you tubers playing through games that have in some way had their memory corrupted. This practise can cause... ... Read More introduction pc nes n64 N64 Reversing Emulator - Mupen64+ RE Introduction Mupen64+ Reverser Edition (RE) is a fork of the Mupen64+ Nintendo 64 emulator tailored for reverse engineering. The main aim is to generate information that will be useful for... ... Read More n64 reversingEmulator Mupen64+ Emulator Source Code Analysis Introduction The Mupen64+ emulator is one of the best open source emulators available for the Nintendo 64, so if you are interested in emulator development or how the Nintendo 64... ... Read More n64 N64 Boot Code Analysis Introduction to Nintendo 64 Bootcode In this post we will be exploring the Nintendo 64 Bootstrapping Code or Boot code for short. The boot code is a short piece of... ... Read More n64 assembly Nintendo 64 (Ultra 64) Development Kit Hardware (Official & Unofficial) The website N64Squid has a page dedicated to Nintendo 64 development hardware that is well worth a look: Nintendo 64 development hardware - N64 Squid. This page aims to compliment... ... Read More n64 devkit hardware Nintendo 64 Hardware Architecture The Nintendo 64 hardware brought incredible processing power into players homes with its 64-bit architecture and state of the art graphics. In order to pull this off Nintendo worked with... ... Read More n64 hardware consolearchitecture N64 MIPS Assembly Video Tutorials Introduction Fraser N64 has created a series of YouTube videos where he teaches N64 MIPS programming from the ground up. This page is designed to act as notes as you... ... Read More n64 assembly tutorial incomplete N64 RDP - Reality Display Processor Introduction Unlike most PC hardware at the time the Nintendo 64 has the advantage of having its own stand alone graphics processor known as the Reality Co-Processor (RCP). This freed... ... Read More n64 N64 RSP - Reality Signal Processor Introduction Unlike most PC hardware at the time the Nintendo 64 has the advantage of having its own stand alone graphics processor known as the Reality Co-Processor (RCP). This freed... ... Read More n64 N64 Reversing Introduction This post will give a brief introduction for the tools and techniques you need to start reverse engineering and decompiling a N64 Game. Part 1 - Looking for Initial Clues... ... Read More n64 introduction Official Nintendo 64 SDK This post covers the Official Nintendo 64 Software Development kit that was sent to developers is actually split among a number of different discs due to its size. These Discs... ... Read More n64 sdk N64 Sound and Music Decoding Audio on the RSP The Reality Signal Processor or RSP is not only used for the games graphics, it is also used for the games audio and so the... ... Read More n64 N64 3D Modelling Software During the Nintendo 64s lifetime 3D modelling tools evolved at an incredible pace. 3D games were the new trend which pushed developers into creating new 3D games in order to... ... Read More n64 3d tools Oman Archive - N64 Leak by SGI employee The Oman Archive was a leak of Nintendo Technical documents from a source inside SGI in late 1999. It was uploaded to the internet under the name oman.rar but has... ... Read More n64 sdk leak How Retro Cartridges (ROMS) work Have you ever wondered what exactly is inside those retro game Cartridges (ROMs)? In this post we will find out the purpose of ROM cartridges and how they worked. Advantages... ... Read More introduction hardware nes snes n64 megadrive mastersystem SN64 - Nintendo 64 Software Development Kit (SDK) SN64 was a software development kit for the Nintendo 64 created by SN Systems and was especially popular with 3rd party game developers. Introduction Sn Systems are a company that... ... Read More n64 sdk snsystems Super Mario 64 Introduction to Super Mario 64 Reversing & Modding The Game was made by Nintendo EAD and was released in Europe on March 1st, 1997. The development team consisted of 2... ... Read More n64 games Turok 64 Official Source Code Analysis Introduction to Turok 64 Game was made by Iguana Entertainment under Acclaim and released on March 4th 1997. The development team consisted of 9 programmers under the lead of Rob... ... Read More n64 games sourcecode Verilog Verilog (Verify Logic) is a hardware definition programming language, this means that it is a text representation of a Digital circuit. So if you wanted to design your own hardware... ... Read More hardware n64 leak iQue Player Software Development Kit The iQue Player was a sort of plug and play version of the Nintendo 64 system sold in China with its main aim to stop the rampant piracy in the... ... Read More ique n64 sdk N64 ROM Visualizer (.z64) Drop Z64 files here to view ... Read More tools n64 Official N64 SDK Setup (MacOSX/Linux/Win) Introduction The Official Nintendo 64 software development kit (SDK) was created by a partnership between Silicon Graphics (SGI) and Nintendo to be released with the development hardware produced by SGI... ... Read More n64 introduction sdk tutorial N64 Rom Analysis with Radare2 This guide will presume you have already installed the radare2 suite of binary analysis tools on your computer. Radare 2 supports z64 big endian binaries using the r_bin plugin that... ... Read More n64 radare2 tools ", "excerpt": "Introduction to Hacking the Nintendo 64 Interested in learning more about the the N64? Excellent! This section will guide you through the basics, starting from basic MIPS assembly language all the way to an introduction to reverse engineering your first game! N64 Reversing Introduction For an introduction on reverse engineering...", "tags": ["n64","introduction"], "image": "/public/generated/placeholders/n64.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "N64 Boot Code Analysis", "url": "/n64bootcode", "content": "Introduction to Nintendo 64 BootcodeIn this post we will be exploring the Nintendo 64 Bootstrapping Code or Boot code for short.The boot code is a short piece of MIPS assembly code located in every single N64 ROM that starts at offset 0x40 and has a size of 4032 bytes.Technically any code could have been placed in this section of the ROM as long as it initialises the hardware, but in practise there were only a couple of variations on the standard bootcode.Different Bootcodes usedThe Boot Codes can be named after the CIC (Lockout) chip that they were created to work with and have the format CIC-NUS-####, to detect which boot code has which name we can take the MD5 hash of the code and compare it to the table below 1. Md5 Hash PAL Name (CIC chip) NA Name (CIC Chip) Details 2dacea29bd5ae921009b68f2763112d8 CIC-NUS-7101 CIC-NUS-6102 Used in 88% of games 877439da8c0021675bbbcfb63c0a10a6 CIC-NUS-7103 CIC-NUS-6103 Used in 3% of games (e.g 1080 Snowboarding) 519f29ee1440f2c7b39a79eea1aec40d CIC-NUS-7105 CIC-NUS-6105 Used in 4% of games (e.g Legend of Zelda OOT) ?? CIC-NUS-7106 CIC-NUS-6106 Used in 3 games (Yoshi’s Story, Cruis’n World and F-Zero X) 2 ?? CIC-NUS-7102 CIC-NUS-6101 Used in 1 game: Starfox64 (also known as Lylat Wars in PAL) Standard BootcodeThe standard Boot Code (CIC-NUS-7101/CIC-NUS-6102) is what we will analysis in this post as it covers 88% of all Retail N64 games and the other Boot Codes tend to be based on it anyway.The md5 hash for this boot code in binary format is:2dacea29bd5ae921009b68f2763112d8So you can check if your rom uses this bootcode by copying 4032 bytes from offset 0x0040 into a separate file and running the md5 command on it.What execute the bootcodeWhen the PIF ROM has finished executing and it passes the anti-piracy CIC check it always jumps to address 0xA4000040 in memory. This is the start of the bootcode and will be where the start of the code analysis will begin.What does the bootcode do?In the official N64 SDK documentation you can read about some of the tasks that the bootcode is responsible for:Chapter 6 - N64 Operating System OverviewBasically it all boils down to initialization of the different chips (CP0, RCP, RDRAM) and loading and jumping to the actual game code.Why have different bootcodes?One reason is for security and to prevent backup devices being used, for example the CIC-NUS-6103 and CIC-NUS-6106 change the RAM entry point for the game 3.Currently more analysis is needed to compare the different bootcodes and figure out why the differences were required and how similar they are. Comment below if you have any information that might be of use.Pseudo C-codeBefore jumping straight into the Assembly code for the bootcode we can have a look at a simplified form of the code, which is a sort of decompilation, but bare in mind that the code was originally written in assembly so its not a true decompilation.We have split up the code into the functions displayed in the table below: Fake Name Address Purpose Boot() 0xa4000040 Start of Bootcode (Initialize C0P and RCP) SevenSeventyEight() 0xa4000778   EightEighty() 0xa4000880   AForty() a4000a40   We will simplify the code by treating each block of code as a C function, and what better place to start than the code at address 0xA4000040:void Boot_a4000040(){ bool bVar1; int iVar2; int extraout_v1; int extraout_v1_00; undefined4 *puVar3; undefined4 *puVar4; uint local_t2_64; uint uVar5; uint uVar6; undefined4 uVar7; uint *puVar8; int iVar9; int iVar10; int iVar11; int iVar12; uint uVar13; int iVar14; int iVar15; uint uVar16; int *piVar17; undefined4 *puVar18; undefined local_60 [72]; // Co-Processor Zero Exception & Timer Registers setCopReg(0,Cause,0,0); // Cause of Last Exception setCopReg(0,Count,0,0); // Timer Count setCopReg(0,Compare,0,0); // Timer Compare if (RI_SELECT == 0) { local_t2_64 = 0xa3f80000; puVar3 = (undefined4 *)&MI_BASE; _RI_CONFIG = 0x40; // Loop 8000 to delay 24000 cycles iVar11 = 8000; do { iVar11 = iVar11 + -1; } while (iVar11 != 0); RI_CURRENT_LOAD = 0; RI_SELECT = 0x14; countdown = 4; do { countdown = countdown + -1; } while (countdown != 0); RI_BASE = 0xe; countdown2 = 0x20; do { countdown2 = countdown2 + -1; } while (countdown2 != 0); MI_BASE = 0x10f; RDRAM_DELAY = 0x18082838; RDRAM_REF_ROW = 0; RDRAM_DEVICE_ID = 0x80000000; uVar6 = 0; iVar8 = 0; puVar9 = (uint *)&RDRAM_BASE; iVar15 = 0; uVar13 = 0; iVar14 = 0; iVar12 = 0; piVar17 = (int *)local_60; puVar18 = (undefined4 *)local_60; if (MI_VERSION == 0x1010101) { // Version >=2 RCP iVar10 = 0x200; iVar12 = 0xa3f04000; piVar18 = (int *)auStack96; } else { // Version 1 RCP iVar10 = 0x400; iVar12 = 0xa3f08000; } do { *(int *)(iVar12 + 4) = iVar11; iVar2 = SevenSeventyEight(); // call SevenSeventyEight_a4000778() if (iVar2 == 0) break; *piVar18 = iVar2; *puVar3 = 0x2000; uVar6 = *puVar9; piVar18[1] = uVar6 & 0xf0ff0000; piVar18 = piVar18 + 2; *puVar3 = 0x1000; if ((uVar6 & 0xf0ff0000) == 0xb0190000) { iVar16 = iVar16 + 0x8000000; uVar14 = uVar14 + 0x200000; iVar13 = iVar13 * 2 + 1; } *puVar3 = 0x2000; uVar6 = puVar9[9]; uVar17 = *puVar9; *puVar3 = 0x1000; if (((uVar6 & 0xffff) == 0x500) && ((uVar17 & 0x1000000) == 0)) { puVar9[6] = 0x101c0a04; } else { puVar9[6] = 0x80c1204; } iVar11 = iVar11 + 0x8000000; puVar9 = (uint *)((int)puVar9 + iVar10 * 2); uVar7 = uVar7 + 1; } while (uVar7 < 8); *(undefined4 *)(iVar5 + 0xc) = 0xc0000000; *(undefined4 *)(iVar5 + 4) = 0x80000000; do { if (puVar19[1] == -0x4ff70000) { *(iVar12 + 4) = iVar16; AFourty(*puVar19,1); // call AForty_a4000a40() uVar14 += 0x100000; *(iVar12 + 4) = iVar15; iVar5 = extraout_v1; } else { *(int *)(iVar12 + 4) = iVar15; AFourty(*puVar19,1); // call AForty_a4000a40() iVar15 = iVar15 + 0x8000000; iVar5 = extraout_v1_00; } puVar19 = puVar19 + 2; } while (iVar5 + 1 < (int)uVar7); _DAT_a4700010 = iVar13 << 0x13 | 0x63634; _DAT_a0000318 = uVar14 & 0xfffffff; uVar14 = 0x80000000; setCopReg(0,TagLo,0,0); setCopReg(0,TagHi,0,0); do { cacheOp(8,uVar14); bVar1 = uVar14 < 0x80003fe0; uVar14 = uVar14 + 0x20; } while (bVar1); uVar14 = 0x80000000; do { cacheOp(9,uVar14); bVar1 = uVar14 < 0x80001ff0; uVar14 = uVar14 + 0x10; } while (bVar1); } else { // RI_SELECT was not equal to 0, so lets just run a subset of the code uVar14 = 0x80000000; setCopReg(0,TagLo,0,0); setCopReg(0,TagHi,0,0); while (uVar14 < 0x80003fe0) { cacheOp(8,uVar14); uVar14 = uVar14 + 0x20; } uVar14 = 0x80000000; while (uVar14 < 0x80001ff0) { cacheOp(1,uVar14); uVar14 = uVar14 + 0x10; } } // Copy the 6102 bootcode from 0xa40004c0 to address 0x80000000 in RAM int* current_loc = &CIC_NUS_6102_Code_Start_Location; // CIC_NUS_6102_Code_Start_Location is 0xa40004c0 int* destination_loc = &DAT_a0000000; while (puVar3 < 0xa4000774) { byte value = *current_loc; current_loc++; *destination_loc = value; destination_loc++; } CIC_NUS_6102_Code(); // 0x80000000 is the code that was loaded previously return;}CIC_NUS_6102_Code()This is a small piece of code that was loaded into memory in the previous function.void CIC_NUS_6102_Code() { u4 *puVar1; u4 *puVar2; uint in_t1; int in_t3; int unaff_s3; u4 unaff_s4; u4 unaff_s5; u4 unaff_s7; _PI_DRAM_ADDR = in_t1 & 0x1fffffff; do { } while ((_PI_STATUS & 2) != 0); __PI_DMA_CART_ADDR = in_t3 + 0x1000U & 0x1fffffff; _PI_DMA_WRITE_LEN = 0xfffff; do { } while ((_PI_STATUS & 1) != 0); if (_SP_PC_BASE != 0) { _SP_PC_BASE = 0; } _SP_STATUS = 0xaaaaae; _MI_INTR_MASK = 0x555; _SI_STATUS = 0; _AI_STATUS = 0; _MI_BASE = 0x800; _PI_STATUS = 2; if (unaff_s3 == 0) { _CART_DOMAIN_ADDRESS = 0xb0000000; // (CART_DOM1_ADDR2) } else { _CART_DOMAIN_ADDRESS = 0xa6000000; // (CART_DOM1_ADDR1) } // Write Zeros To Entire RSP DMEM & IMEM Regions current_address = &SP_MEM_BASE; _DAT_a0000300 = unaff_s4; _DAT_a0000304 = unaff_s3; _DAT_a000030c = unaff_s5; _DAT_a0000314 = unaff_s7; // Clear RSP DMEM do { next_address = current_address + 1; *current_address = 0; current_address = next_address; } while (next_address != &RSP_IMEM_START); // Clear RSP IMEM current_address = &RSP_IMEM_START; do { next_address = current_address + 1; *current_address = 0; current_address = next_address; } while (next_address != 0xa4002000); Boot_Address_Offset(); // Boot_Address_Offset == 0xb0000008 return;}SevenSeventyEight()This function loops 4 times and sums up the output from the EightEighty_a4000880 function.u8 SevenSeventyEight_a4000778() { undefined4 in_v1; int count = 0; int total = 0; while (count < 4) { count += 1; total += EightEighty_a4000880(); }; FUN_a4000a40(total >> 2, 1); return CONCAT44(total >> 2, in_v1);}EightEighty()u4 EightEighty_a4000880() { int iVar5; int counter = 0; int result = 0; int iVar5 = 0; while (counter < 0x50) { if (iVar5 > 0x3f) { return 0; } int iVar1 = FUN_a400090c(iVar5); if (iVar1 > 0) { result += (iVar1 - counter) * iVar5; counter = iVar1; } iVar5 += 1; } result = FUN_a4000980(result * 0x16 - 0x370); return result;}Assembly CodeSome basics before reading the assembly listing:$t0.. Temporary registers$s0.. Saved registers (get saved on stack)$k0 & $K1 Reserved for Kernal$gp - Global Pointer$sp - Stack Pointer (location of stack in memory)$fp - Frame Pointer$v0 - function result 32bit$v1 - function result 64bit$a0.. - function argument registers$ra - return address from functionAfter running the boot code in an emulator I traced each unique instruction executed and made notes on the purpose of each instruction.The boot code that executed came to 438 lines of MIPS assembly which is listed below:; Format of code is 0xMEMORY_ADDRESS: [HEX_BYTES] DISASSEMBLED_BYTES]; First initialise the Coprocessor 0 memory; Copy $zero to C0_CAUSE (Cause of Last Exception) in coprocessor 0.; Repeated for Timer Count (C0_COUNT) and Timer Compare (C0_COMPARE)0xa4000040: [40806800] mtc0 $zero,C0_CAUSE ; Cause of Last Exception0xa4000044: [40804800] mtc0 $zero,C0_COUNT0xa4000048: [40805800] mtc0 $zero,C0_COMPARE; set the $t0 register to ; $t0 = (0xa470 << 16);; $t0 = 0xA47000000xa400004c: [3c08a470] lui $t0,0xa470 ; Load Upper Immediate; Now we add 0 to the $t0 register for some reason…; $t0 = $t0 +0;; So now $t0 = 0xA47000000xa4000050: [25080000] addiu $t0,$t0,0 ; Add Immediate Unsigned; Now we use add 12 to $t0 and dereference it as a pointer; $t1 = MEM[$t0 + 12];; $t1 = MEM[0xA4700000 + 12];; So now $t1 = 00xa4000054: [8d09000c] lw $t1,12($t0) ; Load Word; if $t1 != $zero advance_pc(0xA4000410 << 2));; Since $t1 does equal 0 we don’t branch and go straight to next instruction0xa4000058: [152000ed] bne $t1,$zero,0xA4000410 ; Branch on Not Equal; Now we are going to initialise some values on the STACK; So first lets update the Stack Pointer ($sp) to give us 24 bytes; before running: $sp = 0xA4001FF0; $sp = $sp - 24; after running: $sp = 0xA4001FD80xa4000060: [27bdffe8] addiu $sp,$sp,-24 ; Add Immediate Unsigned; Now that we have the 24 bytes lets store the S registers to save them; MEM[$sp + 0] = $s3; ($s3 was 0 when executing)0xa4000064: [afb30000] sw $s3,0($sp) ; Store word; MEM[$sp + 4] = $s4; ($s4 was 1 when executing)0xa4000068: [afb40004] sw $s4,4($sp); MEM[$sp + 8] = $s5; ($s5 was 0 when executing)0xa400006c: [afb50008] sw $s5,8($sp); MEM[$sp + 12] = $s6; ($s6 was 0x3F when executing)0xa4000070: [afb6000c] sw $s6,12($sp); MEM[$sp + 16] = $s7; ($s7 was 0 when executing)0xa4000074: [afb70010] sw $s7,16($sp); Now lets0xa4000078: [3c08a470] lui $t0,0xa470 ; Load Upper Immediate0xa400007c: [25080000] addiu $t0,$t0,00xa4000080: [3c0aa3f8] lui $t2,0xa3f8 ; Load Upper Immediate0xa4000084: [3c0ba3f0] lui $t3,0xa3f0 ; Load Upper Immediate0xa4000088: [3c0ca430] lui $t4,0xa430 ; Load Upper Immediate0xa400008c: [258c0000] addiu $t4,$t4,00xa4000090: [34090040] ori $t1,$zero,0x400xa4000094: [ad090004] sw $t1,4($t0)0xa4000098: [24111f40] li $s1,8000 ; Load how many times to loop into $s1 (8000); —— Start of Loop (8000 times) ——; Loop seems to be waiting for other hardware to init; it simply counts down from 8000 to zero0xa400009c: [00000000] nop ; do nothing while we wait for other hardware0xa40000a0: [2231ffff] addi $s1,$s1,-1 ; $s1=$s1-10xa40000a4: [1620fffd] bne $s1,$zero,0xA400009C; —— End of Loop ——0xa40000ac: [ad000008] sw $zero,8($t0)0xa40000b0: [34090014] ori $t1,$zero,0x140xa40000b4: [ad09000c] sw $t1,12($t0)0xa40000b8: [ad000000] sw $zero,0($t0)0xa40000bc: [24110004] li $s1,4 ; Load how many times to loop into $s1 (4); —— Start of Loop (4 times) ——0xa40000c0: [00000000] nop 0xa40000c4: [2231ffff] addi $s1,$s1,-1 ; $s1=$s1-10xa40000c8: [1620fffd] bne $s1,$zero,0xA40000C0; —— End of Loop ——0xa40000d0: [3409000e] ori $t1,$zero,0xe0xa40000d4: [ad090000] sw $t1,0($t0)0xa40000d8: [24110020] li $s1,32 ; Load how many times to loop into $s1 (32); —— Start of Loop (32 times) ——0xa40000dc: [2231ffff] addi $s1,$s1,-10xa40000e0: [1620fffe] bne $s1,$zero,0xA40000DC; —— End of Loop ——0xa40000e8: [ad890000] sw $t1,0($t4)0xa40000ec: [3c091808] lui $t1,0x1808 ; Load Upper Immediate0xa40000f0: [35292838] ori $t1,$t1,0x28380xa40000f4: [ad490008] sw $t1,8($t2)0xa40000f8: [ad400014] sw $zero,20($t2)0xa40000fc: [3c098000] lui $t1,0x8000 ; Load Upper Immediate0xa4000100: [ad490004] sw $t1,4($t2)0xa4000104: [00006825] or $t5,$zero,$zero0xa4000108: [00007025] or $t6,$zero,$zero0xa400010c: [3c0fa3f0] lui $t7,0xa3f0 ; Load Upper Immediate0xa4000110: [0000c025] or $t8,$zero,$zero0xa4000114: [3c19a3f0] lui $t9,0xa3f0 ; Load Upper Immediate0xa4000118: [3c16a000] lui $s6,0xa000 ; Load Upper Immediate0xa400011c: [0000b825] or $s7,$zero,$zero0xa4000120: [3c06a3f0] lui $a2,0xa3f0 ; Load Upper Immediate0xa4000124: [3c07a000] lui $a3,0xa000 ; Load Upper Immediate0xa4000128: [00009025] or $s2,$zero,$zero0xa400012c: [3c14a000] lui $s4,0xa000 ; Load Upper Immediate; Assign 72 Bytes on Stack0xa4000130: [27bdffb8] addiu $sp,$sp,-720xa4000134: [03a0f025] or $s8,$sp,$zero0xa4000138: [3c10a430] lui $s0,0xa430 # Load Upper Immediate0xa400013c: [8e100004] lw $s0,4($s0)0xa4000140: [3c110101] lui $s1,0x101 # Load Upper Immediate0xa4000144: [26310101] addiu $s1,$s1,2570xa4000148: [16110005] bne $s0,$s1,0xA40001600xa4000160: [24100400] li $s0,10240xa4000164: [35718000] ori $s1,$t3,0x8000; —— Start of Loop (5 times) ——0xa4000168: [ae2e0004] sw $t6,4($s1)0xa400016c: [25f5000c] addiu $s5,$t7,12; Call Function $v0 = SevenSeventyEight()0xa4000170: [0d0001de] jal 0xA4000778; Break out of loop if $v0 = 0 ($v0 is the return value of SevenSeventyEight())0xa4000178: [10400038] beq $v0,$zero,0xA400025C0xa4000180: [afa20000] sw $v0,0($sp)0xa4000184: [24092000] li $t1,81920xa4000188: [ad890000] sw $t1,0($t4)0xa400018c: [8deb0000] lw $t3,0($t7)0xa4000190: [3c08f0ff] lui $t0,0xf0ff0xa4000194: [01685824] and $t3,$t3,$t00xa4000198: [afab0004] sw $t3,4($sp); Delete 8 Bytes on Stack0xa400019c: [23bd0008] addi $sp,$sp,80xa40001a0: [24091000] li $t1,40960xa40001a4: [ad890000] sw $t1,0($t4)0xa40001a8: [3c08b019] lui $t0,0xb0190xa40001ac: [1568000c] bne $t3,$t0,0xA40001E00xa40001b4: [3c080800] lui $t0,0x8000xa40001b8: [0308c020] add $t8,$t8,$t00xa40001bc: [0330c820] add $t9,$t9,$s00xa40001c0: [0330c820] add $t9,$t9,$s00xa40001c4: [3c080020] lui $t0,0x200xa40001c8: [02c8b020] add $s6,$s6,$t00xa40001cc: [0288a020] add $s4,$s4,$t00xa40001d0: [00129040] sll $s2,$s2,10xa40001d4: [22520001] addi $s2,$s2,10xa40001d8: [10000003] b 0xA40001E80xa40001e8: [24082000] li $t0,81920xa40001ec: [ad880000] sw $t0,0($t4)0xa40001f0: [8de90024] lw $t1,36($t7)0xa40001f4: [8dfa0000] lw $k0,0($t7)0xa40001f8: [24081000] li $t0,40960xa40001fc: [ad880000] sw $t0,0($t4)0xa4000200: [3129ffff] andi $t1,$t1,0xffff0xa4000204: [24080500] li $t0,12800xa4000208: [15280009] bne $t1,$t0,0xA40002300xa4000210: [3c1b0100] lui $k1,0x1000xa4000214: [035bd024] and $k0,$k0,$k10xa4000218: [17400005] bne $k0,$zero,0xA40002300xa4000230: [3c08080c] lui $t0,0x80c0xa4000234: [35081204] ori $t0,$t0,0x12040xa4000238: [ade80018] sw $t0,24($t7)0xa400023c: [3c080800] lui $t0,0x8000xa4000240: [01c87020] add $t6,$t6,$t00xa4000244: [01f07820] add $t7,$t7,$s00xa4000248: [01f07820] add $t7,$t7,$s00xa400024c: [25ad0001] addiu $t5,$t5,10xa4000250: [2da80008] sltiu $t0,$t5,80xa4000254: [1500ffc4] bne $t0,$zero,0xA4000168; —— End of Loop ——0xa400025c: [3c08c400] lui $t0,0xc4000xa4000260: [ad48000c] sw $t0,12($t2)0xa4000264: [3c088000] lui $t0,0x80000xa4000268: [ad480004] sw $t0,4($t2)0xa400026c: [03c0e825] or $sp,$s8,$zero0xa4000270: [00001825] or $v1,$zero,$zero; —— Start of Loop (4 times) ——0xa4000274: [8fa90004] lw $t1,4($sp)0xa4000278: [3c08b009] lui $t0,0xb0090xa400027c: [15280016] bne $t1,$t0,0xA40002D80xa40002d8: [ae370004] sw $s7,4($s1)0xa40002dc: [24d5000c] addiu $s5,$a2,120xa40002e0: [8fa40000] lw $a0,0($sp); Delete 8 Bytes on Stack0xa40002e4: [23bd0008] addi $sp,$sp,80xa40002e8: [24050001] li $a1,1; Call Function AForty($a0,$a1)0xa40002ec: [0d000290] jal 0xA4000A400xa40002f4: [8ce80000] lw $t0,0($a3)0xa40002f8: [3c080008] lui $t0,0x80xa40002fc: [01074020] add $t0,$t0,$a30xa4000300: [8d090000] lw $t1,0($t0)0xa4000304: [3c080010] lui $t0,0x100xa4000308: [01074020] add $t0,$t0,$a30xa400030c: [8d090000] lw $t1,0($t0)0xa4000310: [3c080018] lui $t0,0x180xa4000314: [01074020] add $t0,$t0,$a30xa4000318: [8d090000] lw $t1,0($t0)0xa400031c: [8ce80000] lw $t0,0($a3)0xa4000320: [3c080008] lui $t0,0x80xa4000324: [01074020] add $t0,$t0,$a30xa4000328: [8d090000] lw $t1,0($t0)0xa400032c: [3c080010] lui $t0,0x100xa4000330: [01074020] add $t0,$t0,$a30xa4000334: [8d090000] lw $t1,0($t0)0xa4000338: [3c080018] lui $t0,0x180xa400033c: [01074020] add $t0,$t0,$a30xa4000340: [8d090000] lw $t1,0($t0)0xa4000344: [3c080800] lui $t0,0x8000xa4000348: [02e8b820] add $s7,$s7,$t00xa400034c: [00d03020] add $a2,$a2,$s00xa4000350: [00d03020] add $a2,$a2,$s00xa4000354: [3c080020] lui $t0,0x200xa4000358: [00e83820] add $a3,$a3,$t00xa400035c: [24630001] addiu $v1,$v1,10xa4000360: [006d402a] slt $t0,$v1,$t50xa4000364: [1500ffc3] bne $t0,$zero,0xA4000274; —— End of Loop ——0xa400036c: [3c0aa470] lui $t2,0xa4700xa4000370: [001294c0] sll $s2,$s2,190xa4000374: [3c090006] lui $t1,0x60xa4000378: [35293634] ori $t1,$t1,0x36340xa400037c: [01324825] or $t1,$t1,$s20xa4000380: [ad490010] sw $t1,16($t2)0xa4000384: [8d490010] lw $t1,16($t2)0xa4000388: [3c08a000] lui $t0,0xa0000xa400038c: [35080300] ori $t0,$t0,0x3000xa4000390: [3c090fff] lui $t1,0xfff0xa4000394: [3529ffff] ori $t1,$t1,0xffff0xa4000398: [02c9b024] and $s6,$s6,$t10xa400039c: [ad160018] sw $s6,24($t0)0xa40003a0: [03c0e825] or $sp,$s8,$zero; Delete 72 Bytes on Stack0xa40003a4: [27bd0048] addiu $sp,$sp,72; Load the Saved S registers back from stack0xa40003a8: [8fb30000] lw $s3,0($sp)0xa40003ac: [8fb40004] lw $s4,4($sp)0xa40003b0: [8fb50008] lw $s5,8($sp)0xa40003b4: [8fb6000c] lw $s6,12($sp)0xa40003b8: [8fb70010] lw $s7,16($sp); Delete 24 Bytes on Stack0xa40003bc: [27bd0018] addiu $sp,$sp,240xa40003c0: [3c088000] lui $t0,0x80000xa40003c4: [25080000] addiu $t0,$t0,00xa40003c8: [25094000] addiu $t1,$t0,163840xa40003cc: [2529ffe0] addiu $t1,$t1,-320xa40003d0: [4080e000] mtc0 $zero,C0_TAGLO0xa40003d4: [4080e800] mtc0 $zero,C0_TAGHI; —— Start of Loop (until $at == 0, 512 times) ——0xa40003d8: [bd080000] cache 0x8,0x0($t0)0xa40003dc: [0109082b] sltu $at,$t0,$t10xa40003e0: [1420fffd] bne $at,$zero,0xA40003D8; —— End of Loop ——0xa40003e8: [3c088000] lui $t0,0x80000xa40003ec: [25080000] addiu $t0,$t0,00xa40003f0: [25092000] addiu $t1,$t0,81920xa40003f4: [2529fff0] addiu $t1,$t1,-16; —— Start of Loop (until $at == 0, 512 times) ——0xa40003f8: [bd090000] cache 0x9,0x0($t0)0xa40003fc: [0109082b] sltu $at,$t0,$t10xa4000400: [1420fffd] bne $at,$zero,0xA40003F8; —— End of Loop ——0xa4000408: [10000013] b 0xA40004580xa4000458: [3c0aa400] lui $t2,0xa4000xa400045c: [254a0000] addiu $t2,$t2,00xa4000460: [3c0bfff0] lui $t3,0xfff00xa4000464: [3c090010] lui $t1,0x100xa4000468: [014b5024] and $t2,$t2,$t30xa400046c: [3c08a400] lui $t0,0xa4000xa4000470: [2529ffff] addiu $t1,$t1,-10xa4000474: [3c0ba400] lui $t3,0xa4000xa4000478: [250804c0] addiu $t0,$t0,12160xa400047c: [256b0774] addiu $t3,$t3,19080xa4000480: [01094024] and $t0,$t0,$t10xa4000484: [01695824] and $t3,$t3,$t10xa4000488: [3c09a000] lui $t1,0xa0000xa400048c: [010a4025] or $t0,$t0,$t20xa4000490: [016a5825] or $t3,$t3,$t20xa4000494: [25290000] addiu $t1,$t1,0; —— Start of Loop (until $at == 0, 173 times) ——0xa4000498: [8d0d0000] lw $t5,0($t0)0xa400049c: [25080004] addiu $t0,$t0,40xa40004a0: [010b082b] sltu $at,$t0,$t30xa40004a4: [25290004] addiu $t1,$t1,40xa40004a8: [1420fffb] bne $at,$zero,0xA4000498; —— End of Loop ——0xa40004b0: [3c0c8000] lui $t4,0x80000xa40004b4: [258c0000] addiu $t4,$t4,00xa40004b8: [01800008] jr $t4; —— Start Function SevenSeventyEight (called 5 times) —— ; This function basically preserves all the registers on stack; then it calls function EightEighty() exactly 4 times; Assign 160 Bytes on Stack0xa4000778: [27bdff60] addiu $sp,$sp,-160; Start Saving all the registers into the newly created stack space0xa400077c: [afb00040] sw $s0,64($sp)0xa4000780: [afb10044] sw $s1,68($sp)0xa4000784: [00008825] or $s1,$zero,$zero0xa4000788: [00008025] or $s0,$zero,$zero0xa400078c: [afa20000] sw $v0,0($sp)0xa4000790: [afa30004] sw $v1,4($sp)0xa4000794: [afa40008] sw $a0,8($sp)0xa4000798: [afa5000c] sw $a1,12($sp)0xa400079c: [afa60010] sw $a2,16($sp)0xa40007a0: [afa70014] sw $a3,20($sp)0xa40007a4: [afa80018] sw $t0,24($sp)0xa40007a8: [afa9001c] sw $t1,28($sp)0xa40007ac: [afaa0020] sw $t2,32($sp)0xa40007b0: [afab0024] sw $t3,36($sp)0xa40007b4: [afac0028] sw $t4,40($sp)0xa40007b8: [afad002c] sw $t5,44($sp)0xa40007bc: [afae0030] sw $t6,48($sp)0xa40007c0: [afaf0034] sw $t7,52($sp)0xa40007c4: [afb80038] sw $t8,56($sp)0xa40007c8: [afb9003c] sw $t9,60($sp)0xa40007cc: [afb20048] sw $s2,72($sp)0xa40007d0: [afb3004c] sw $s3,76($sp)0xa40007d4: [afb40050] sw $s4,80($sp)0xa40007d8: [afb50054] sw $s5,84($sp)0xa40007dc: [afb60058] sw $s6,88($sp)0xa40007e0: [afb7005c] sw $s7,92($sp)0xa40007e4: [afbe0060] sw $s8,96($sp)0xa40007e8: [afbf0064] sw $ra,100($sp); End Saving Registers to Stack; —— Start of Loop (4 times) ——0xa40007ec: [0d000220] jal 0xA4000880 ; Call function EightEighty()0xa40007f4: [26100001] addiu $s0,$s0,1; $s0 = $s0 + 10xa40007f8: [2a090004] slti $t1,$s0,4 ' if $s0 < imm $t1 = 10xa40007fc: [1520fffb] bne $t1,$zero,0xA40007EC; —— End of Loop ——; Load all the registers back from the stack0xa4000804: [00112082] srl $a0,$s1,20xa4000808: [0d000290] jal 0xA4000A400xa4000810: [8fbf0064] lw $ra,100($sp)0xa4000814: [00111082] srl $v0,$s1,20xa4000818: [8fb10044] lw $s1,68($sp)0xa400081c: [8fa30004] lw $v1,4($sp)0xa4000820: [8fa40008] lw $a0,8($sp)0xa4000824: [8fa5000c] lw $a1,12($sp)0xa4000828: [8fa60010] lw $a2,16($sp)0xa400082c: [8fa70014] lw $a3,20($sp)0xa4000830: [8fa80018] lw $t0,24($sp)0xa4000834: [8fa9001c] lw $t1,28($sp)0xa4000838: [8faa0020] lw $t2,32($sp)0xa400083c: [8fab0024] lw $t3,36($sp)0xa4000840: [8fac0028] lw $t4,40($sp)0xa4000844: [8fad002c] lw $t5,44($sp)0xa4000848: [8fae0030] lw $t6,48($sp)0xa400084c: [8faf0034] lw $t7,52($sp)0xa4000850: [8fb80038] lw $t8,56($sp)0xa4000854: [8fb9003c] lw $t9,60($sp)0xa4000858: [8fb00040] lw $s0,64($sp)0xa400085c: [8fb20048] lw $s2,72($sp)0xa4000860: [8fb3004c] lw $s3,76($sp)0xa4000864: [8fb40050] lw $s4,80($sp)0xa4000868: [8fb50054] lw $s5,84($sp)0xa400086c: [8fb60058] lw $s6,88($sp)0xa4000870: [8fb7005c] lw $s7,92($sp)0xa4000874: [8fbe0060] lw $s8,96($sp); Return back to wherever called this function0xa4000878: [03e00008] jr $ra ; return;; ——— End Function ——; —— Start Function EightEighty (runs 20 times) ——; Add 32 Bytes on Stack0xa4000880: [27bdffe0] addiu $sp,$sp,-320xa4000884: [afbf001c] sw $ra,28($sp); store the return address on the stack0xa4000888: [00004825] or $t1,$zero,$zero0xa400088c: [00005825] or $t3,$zero,$zero0xa4000890: [00006025] or $t4,$zero,$zero; —— Start of Loop (? times) ——0xa4000894: [299a0040] slti $k0,$t4,640xa4000898: [53400018] beql $k0,$zero,0xA40008FC ; if $k0==0 return;; Call Function NinetyC()0xa40008a0: [0d000243] jal 0xA400090C0xa40008a8: [58400008] blezl $v0,0xA40008CC0xa40008b0: [0049d023] subu $k0,$v0,$t10xa40008b4: [034c0019] multu $k0,$t40xa40008b8: [00404825] or $t1,$v0,$zero0xa40008bc: [0000d012] mflo $k00xa40008c0: [017a5821] addu $t3,$t3,$k00xa40008c4: [00000000] nop 0xa40008c8: [293a0050] slti $k0,$t1,800xa40008cc: [1740fff1] bne $k0,$zero,0xA4000894; —— End of Loop ——0xa40008d4: [000b2080] sll $a0,$t3,20xa40008d8: [008b2023] subu $a0,$a0,$t30xa40008dc: [00042080] sll $a0,$a0,20xa40008e0: [008b2023] subu $a0,$a0,$t30xa40008e4: [00042040] sll $a0,$a0,1; Call function NineEighty()0xa40008e8: [0d000260] jal 0xA4000980 ; JUMP to Function0xa40008f0: [10000003] b 0xA40009000xa40008fc: [8fbf001c] lw $ra,28($sp) ; load the return address on the stack; Delete 32 Bytes on Stack0xa4000900: [27bd0020] addiu $sp,$sp,32; return from function0xa4000904: [03e00008] jr $ra; return;; ——— End Function ——; —— Start Function NinetyC (runs 288 times) ——; Add 40 Bytes on Stack0xa400090c: [27bdffd8] addiu $sp,$sp,-400xa4000910: [afbf001c] sw $ra,28($sp)0xa4000914: [00001025] or $v0,$zero,$zero0xa4000918: [0d000290] jal 0xA4000A400xa4000920: [0000f025] or $s8,$zero,$zero0xa4000924: [241affff] li $k0,-10xa4000928: [ae9a0004] sw $k0,4($s4)0xa400092c: [8e830004] lw $v1,4($s4)0xa4000930: [ae9a0000] sw $k0,0($s4)0xa4000934: [ae9a0000] sw $k0,0($s4)0xa4000938: [0000e025] or $gp,$zero,$zero0xa400093c: [00031c02] srl $v1,$v1,160xa4000940: [307a0001] andi $k0,$v1,0x10xa4000944: [53400003] beql $k0,$zero,0xA40009540xa400094c: [24420001] addiu $v0,$v0,10xa4000950: [279c0001] addiu $gp,$gp,10xa4000954: [2b9a0008] slti $k0,$gp,80xa4000958: [1740fff9] bne $k0,$zero,0xA40009400xa4000960: [27de0001] addiu $s8,$s8,10xa4000964: [2bda000a] slti $k0,$s8,100xa4000968: [5740ffef] bnel $k0,$zero,0xA40009280xa4000970: [8fbf001c] lw $ra,28($sp); Delete 40 Bytes on Stack0xa4000974: [27bd0028] addiu $sp,$sp,40; Return from function0xa4000978: [03e00008] jr $ra; return;; ——— End Function ——; —— Start Function NineEighty ——; Add 40 Bytes on Stack0xa4000980: [27bdffd8] addiu $sp,$sp,-400xa4000984: [afbf001c] sw $ra,28($sp)0xa4000988: [afa40020] sw $a0,32($sp)0xa400098c: [a3a00027] sb $zero,39($sp)0xa4000990: [00004025] or $t0,$zero,$zero0xa4000994: [00005025] or $t2,$zero,$zero0xa4000998: [340dc800] ori $t5,$zero,0xc8000xa400099c: [00007025] or $t6,$zero,$zero0xa40009a0: [29da0040] slti $k0,$t6,640xa40009a4: [57400004] bnel $k0,$zero,0xA40009B80xa40009b8: [0d000290] jal 0xA4000A40; Call Function AaDeeZero()0xa40009c0: [0d0002b4] jal 0xA4000AD0; Call Function AaDeeZero()0xa40009c8: [0d0002b4] jal 0xA4000AD00xa40009d0: [93ba0027] lbu $k0,39($sp)0xa40009d4: [241b0320] li $k1,8000xa40009d8: [8fa40020] lw $a0,32($sp)0xa40009dc: [035b0019] multu $k0,$k10xa40009e0: [00004012] mflo $t00xa40009e4: [0104d023] subu $k0,$t0,$a00xa40009e8: [07430003] bgezl $k0,0xA40009F80xa40009f0: [0088d023] subu $k0,$a0,$t00xa40009f4: [034dd82a] slt $k1,$k0,$t50xa40009f8: [53600004] beql $k1,$zero,0xA4000A0C0xa4000a00: [03406825] or $t5,$k0,$zero0xa4000a04: [01c05025] or $t2,$t6,$zero0xa4000a08: [8fa40020] lw $a0,32($sp)0xa4000a0c: [0104d82a] slt $k1,$t0,$a00xa4000a10: [53600006] beql $k1,$zero,0xA4000A2C0xa4000a18: [25ce0001] addiu $t6,$t6,10xa4000a1c: [29db0041] slti $k1,$t6,650xa4000a20: [5760ffe0] bnel $k1,$zero,0xA40009A40xa4000a2c: [00021042] srl $v0,$v0,10xa4000a30: [8fbf001c] lw $ra,28($sp); Delete 40 Bytes on Stack0xa4000a34: [27bd0028] addiu $sp,$sp,400xa4000a38: [03e00008] jr $ra ; return;; ——— End Function ——; —— Start Function AForty ——; Add 8 Bytes on Stack0xa4000a40: [27bdffd8] addiu $sp,$sp,-400xa4000a44: [308400ff] andi $a0,$a0,0xff0xa4000a48: [241b0001] li $k1,10xa4000a4c: [3884003f] xori $a0,$a0,0x3f0xa4000a50: [afbf001c] sw $ra,28($sp)0xa4000a54: [14bb0003] bne $a1,$k1,0xA4000A640xa4000a5c: [3c1a8000] lui $k0,0x80000xa4000a60: [01fa7825] or $t7,$t7,$k00xa4000a64: [309a0001] andi $k0,$a0,0x10xa4000a68: [001ad180] sll $k0,$k0,60xa4000a6c: [01fa7825] or $t7,$t7,$k00xa4000a70: [309a0002] andi $k0,$a0,0x20xa4000a74: [001ad340] sll $k0,$k0,130xa4000a78: [01fa7825] or $t7,$t7,$k00xa4000a7c: [309a0004] andi $k0,$a0,0x40xa4000a80: [001ad500] sll $k0,$k0,200xa4000a84: [01fa7825] or $t7,$t7,$k00xa4000a88: [309a0008] andi $k0,$a0,0x80xa4000a8c: [001ad100] sll $k0,$k0,40xa4000a90: [01fa7825] or $t7,$t7,$k00xa4000a94: [309a0010] andi $k0,$a0,0x100xa4000a98: [001ad2c0] sll $k0,$k0,110xa4000a9c: [01fa7825] or $t7,$t7,$k00xa4000aa0: [309a0020] andi $k0,$a0,0x200xa4000aa4: [001ad480] sll $k0,$k0,180xa4000aa8: [01fa7825] or $t7,$t7,$k00xa4000aac: [241b0001] li $k1,10xa4000ab0: [14bb0003] bne $a1,$k1,0xA4000AC00xa4000ab8: [3c1aa430] lui $k0,0xa4300xa4000abc: [af400000] sw $zero,0($k0)0xa4000ac0: [8fbf001c] lw $ra,28($sp); Delete 40 Bytes on Stack0xa4000ac4: [27bd0028] addiu $sp,$sp,400xa4000ac8: [03e00008] jr $ra; ——— End Function ——; —— Start Function AaDeeZero ——; Add 40 Bytes on Stack and save return address0xa4000ad0: [27bdffd8] addiu $sp,$sp,-400xa4000ad4: [afbf001c] sw $ra,28($sp); $k0 = 81920xa4000ad8: [241a2000] li $k0,8192; $k1 = 0xa4300xa4000adc: [3c1ba430] lui $k1,0xa430; MEM[$k1] = $k0 (8192)0xa4000ae0: [af7a0000] sw $k0,0($k1)0xa4000ae4: [0000f025] or $s8,$zero,$zero0xa4000ae8: [8ebe0000] lw $s8,0($s5)0xa4000aec: [241a1000] li $k0,40960xa4000af0: [af7a0000] sw $k0,0($k1)0xa4000af4: [241b0040] li $k1,640xa4000af8: [037ed824] and $k1,$k1,$s8; Now divide $k1 by 2^60xa4000afc: [001bd982] srl $k1,$k1,60xa4000b00: [0000d025] or $k0,$zero,$zero0xa4000b04: [035bd025] or $k0,$k0,$k10xa4000b08: [241b4000] li $k1,163840xa4000b0c: [037ed824] and $k1,$k1,$s8; Now divide $k1 by 2^130xa4000b10: [001bdb42] srl $k1,$k1,130xa4000b14: [035bd025] or $k0,$k0,$k10xa4000b18: [3c1b0040] lui $k1,0x400xa4000b1c: [037ed824] and $k1,$k1,$s8; Now divide $k1 by 2^200xa4000b20: [001bdd02] srl $k1,$k1,200xa4000b24: [035bd025] or $k0,$k0,$k10xa4000b28: [241b0080] li $k1,1280xa4000b2c: [037ed824] and $k1,$k1,$s8; Now divide $k1 by 2^40xa4000b30: [001bd902] srl $k1,$k1,40xa4000b34: [035bd025] or $k0,$k0,$k10xa4000b38: [341b8000] ori $k1,$zero,0x80000xa4000b3c: [037ed824] and $k1,$k1,$s8; Now divide $k1 by 2^110xa4000b40: [001bdac2] srl $k1,$k1,110xa4000b44: [035bd025] or $k0,$k0,$k10xa4000b48: [3c1b0080] lui $k1,0x800xa4000b4c: [037ed824] and $k1,$k1,$s8; Now divide $k1 by 2^180xa4000b50: [001bdc82] srl $k1,$k1,18 ; $k1 = $k1 >> 18;0xa4000b54: [035bd025] or $k0,$k0,$k1 ; $k0 = $k0 | $k1; 0xa4000b58: [a09a0000] sb $k0,0($a0) ; MEM[$a0] = $k0; Load return address back from stack0xa4000b5c: [8fbf001c] lw $ra,28($sp); Delete 40 Bytes on Stack0xa4000b60: [27bd0028] addiu $sp,$sp,400xa4000b64: [03e00008] jr $ra; ——— End Function ——References Talcardo Jirones in the comment sections of this page ↩ Micro-64 ↩ ROM - en64 wiki ↩ ", "excerpt": "Introduction to Nintendo 64 Bootcode In this post we will be exploring the Nintendo 64 Bootstrapping Code or Boot code for short. The boot code is a short piece of MIPS assembly code located in every single N64 ROM that starts at offset 0x40 and has a size of 4032...", "tags": ["n64","assembly"], "image": "/public/N64/N64BootCodeAnalysis.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo 64 (Ultra 64) Development Kit Hardware (Official & Unofficial)", "url": "/official-n64-devkit", "content": "The website N64Squid has a page dedicated to Nintendo 64 development hardware that is well worth a look: Nintendo 64 development hardware - N64 Squid. This page aims to compliment that page and give additional details about the hardware, so it is recommended you read that page first 1.Official Development KitSGI started work on what it called the Reality Engine in 1992, this technology cost $100,000 but produced some of the most beautiful 3D demos that the world had ever seen. An SGI employee called Tim Van Hook then took this technology and produced a functionally similar engine at a much cheaper price point and called it the Multimedia Engine 2.It was this technology that SGI wanted to bring into the home, but they decided that they would need the help of a major player in the video game industry, Nintendo. Thus in August 1993 the Ultra64 project began its life as a partnership between Nintendo and SGI.Early Development Hardware - SGI Onyx In the very early days of the Ultra64 project the retail hardware was still under active development, but games would need to start development as soon as possible so that the system could have launch titles. As there was no ready hardware to use early developers such as Shigeru Miyamoto for the platform used the SGI Onyx and it’s Multimedia Engine along with a software emulation layer to model how they envisioned the Ultra64 project. This is where Super Mario 64 started its life in July of 1994 2. All the launch titles had to be developed on the SGI workstations with the software emulation layer until working prototypes of the Nintendo 64 hardware was available and could be slotted in the same SGI workstations. The earliest mention of the SGI Onyx being used as an early development kit for the Nintendo 64 was in the Edge UK magazine issue 20 from May 1995. 3. Nintendo 64 Development Unit (SGI IRIX workstations) As the N64 hardware matured so did the development hardware, the Nintendo 64 Development Unit was one of the first evolutions of the development kit and was sold directly by Nintendo from October 1996 onwards. It consisted of a standard SGI workstation such as an Indy with an add-on board containing the retail Nintendo 64 hardware. This has the benefit of not using any workstation hardware resources to run the games as it used the N64 hardware directly and just communicated with it for debugging 4. N64 hardware add-on board (Nintendo 64 Development Board) The add-on board slips into the SGI Indy workstations case and has pretty much all the hardware from a retail console, with a few changes to allow the communication between the IRIX operating system and the hardware. N64 Hardware Connectivity You can see the standard SNES/N64 A/V out socket in the back on the Indy, apart from this the connectivity was very sparse. The controllers connected via another bit of hardware and are not on the add-on board at all. If you look closer you will notice that there is a number of ethernet ports which actually go to the add-on board. These are used to connect to multiple development hardware including an adapter for retail controllers which can be seen in a tweet from Shane Battye . But wait a minute; don't u64 development boards require a 'Joybus' adapter? Yep, but only if they're interfacing with retail type controllers (which may have been available not too long after RJ-11 development controllers)... pic.twitter.com/kY3wOjPQug— Shane Battye (@shanebattye) September 21, 2019KMC Partner-N64The Nintendo 64 Development Unit later evolved into the Partner-N64 series of hardware by KMC (Kyoto Microcomputer, Co. Ltd.) and consisted not only of hardware for the SGI workstations but also created a version that worked on standard Windows PCs!KMC Partner-N64NW (Network SGI workstations)Unlike the Nintendo 64 Development Unit this development kit didn’t contain an add-on board and instead connected directly to a modified retail N64. This was achieved using a custom cartridge known as a Debugger Pak slotted in the N64 with a network adapter that could be connected directly to an SGI workstation such as an Indy 5.Check this out!Here is an Ultra rare #N64 development kit. The \"Partner-N64 NW\".Targeted at Game development Studio's using SGI Indy computer systems. This version of the Partner dev system communicates with the Indy over the Ethernet LAN port. #N64Dev #RETROGAMING #gamedev pic.twitter.com/SEHLgRece1— BehindTheCode (@GerryRobotics) December 11, 2020KMC Partner-N64PC (Windows PCs)The Partner-N64PC was another full official development kit by KMC (Kyoto Microcomputer, Co. Ltd.) specifically for Windows PCs.The SDK that comes with the Partner-N64PC was provided by Metrowerks (Codewarrior).Fun Fact! The official Nintendo #N64Dev Kit released by Kyoto Microcomputer, was called the "PARTNER-N64". The Kit was actually available in two versions. One for Windows PC, and the second for the SGI INDY. This was KuC's way of attracting Game Studios using SGI INDY equipment. pic.twitter.com/mLfbZRFZeH— Gerry_MAN (@GerryRobotics) June 19, 2019Partner-N64 Debugger Pak The Debugger Pak was used by both Partner-N64PC and Partner-N64NW, it functioned similarly to the standard Game Pak but were longer and had the connection port at the top for connecting to the PC. This allowed full debugging support such as breakpoints and stack traces to be used. ISA Card (Dedicated Interface board) The ISA card was a small add-on card that could be slotted a the standard PC’s ISA bus slot and contained just enough hardware to allow communication over the port. The ISA card comes as part of the Partner-N64PC pack but you could also buy a PCI version separately for $350 6. Notice that there are DIP switches at the top of the board that need to be configured before installing to make sure that the I/O addresses for communication match the PC. Modified N64 (Control Deck Assembly) In order to use the Partner64 the retail N64 console hardware had to be modified, these normally came with the development kit when you bought the Partner64 or you could buy a separate one for about $200 6. Ultra64.ca has an excellent tutorial which shows you how to create your own Partner N64 development kit for home-brew development, very cool! It is available here: Make your own Partner N64 console, for use with IS Viewer : Nintendo (Ultra) 64 Usage of Partner64The official Partner64 development kit was quite popular and used both inside and outside of Nintendo.Here is a list of games that still contain KMC Partner64 debug code thanks to a Pastebin by user ZOINKITY 7: 1080 TenEighty Snowboarding 64 Oozumou 2 64 Trump Collection - Alice no Wakuwaku Trump World AI Shougi 3 Aidyn Chronicles - The First Mage Battlezone - Rise of the Black Dogs Blues Brothers 2000 Brunswick Circuit Pro Bowling Buck Bumble Charlie Blast’s Territory Dragon Sword 64 (NTSC) (Proto) Earthworm Jim 3D Elmo’s Letter Adventure Elmo’s Number Journey Fighter Destiny 2 Fighting Force 64 GameShark Pro (v2.0) Ganbare Goemon - Neo Momoyama Bakufu no Odori / Mystical Ninja Starring Goemon Ganbare! Nippon! Olympics 2000 Gex 3 - Deep Cover Gecko Gex 64 - Enter the Gecko Glover 2 (USA) (Proto)  [[internal crc B7F40BCF 553556A5]] Harvest Moon 64 / Bokujou Monogatari 2 Hercules - The Legendary Journeys Hyper Olympics in Nagano 64 / Nagano Winter Olympics ‘98 Ide Yosuke no Mahjong Juku International Superstar Soccer 2000 International Track & Field - Summer Games / International Track & Field 2000 Jikkyou J.League 1999 - Perfect Striker 2 Kakutou Denshou - F-Cup Maniax Legend of Zelda, The - Majora’s Mask (Debug) Lylat Wars Mario Party (Europe) Mario Party 3   [[USA, PAL, +not+ Japan]] Micro Machines 64 Turbo Midway’s Greatest Arcade Hits - Volume 1 Mischief Makers (USA) (Rev A) MRC - Multi Racing Championship NFL Blitz - Special Edition NFL Blitz 2001 Nightmare Creatures Parlor! Pro 64 - Pachinko Jikki Simulation Game Pokemon Puzzle League Pokemon Stadium 2 / Pocket Monster Stadium 3 Polaris SnoCross Powerpuff Girls, The - Chemical X-Traction Premier Manager 64 Ready 2 Rumble Boxing Ready 2 Rumble Boxing - Round 2 Road Rash 64 Rockman 64 (Japan) (Proto) Star Fox 64 (Rev A) (Japan and USA; not in v1.0) Superman (USA) (Proto) (not in retail version) Tom and Jerry in Fists of Furry Triple Play 2000 WCW Nitro 4567 (64DD) Dezaemon DD (64DD) Doshin the Giant (retail and demo) (64DD) Doshin the Giant 2 (64DD) Mario Artist Communication Kit (64DD)Monegi Smart PackAlso on display will be a #64DD dev kit with Monegi Smart Pack. These setups were probably the last 'official' N64 development systems and likely used for later Hudson titles as well as being sold alongside the CodeWarrior IDE. They supported 512mb ROMs and 64DD out of the box pic.twitter.com/We3h3ahXa3— Shane Battye (@shanebattye) October 5, 2019IS-Viewer 64The IS-Viewer64 or IS64 for short was the official way to create a N64 prototype cartridge than ran on a modified version of retail hardware. It is a flash cart created by Intelligent Systems (hence the IS prefix) and was released as part of the official N64 development kit. This did not have debug support such as breakpoints and stack traces and this was much cheaper than alternatives. Although It cost around 1800 USD on release so was still an expensive solution 8.View it in action in the excellent video below by BehindTheCode 9:The main benefit of the IS-Viewer64 over alternative flash carts available to developers was the crazy fast transfer speed, allowing games to be written to the onboard RAM in as little as 30 seconds! 10.Usage of IS-Viewer64The IS-Viewer 64 was used to develop the two Zelda games (Oracle of Time, Majoras Mask) and still contains some code to write out debug messages to a connected PC on the retail ROM 11.Here is a list of games that still contain IS64 debug code thanks to a Pastebin by user ZOINKITY 7: Castlevania / Akumajou Dracula Mokushiroku - Real Action Adventure Dance Dance Revolution - Disney Dancing Museum Ganbare Goemon - Neo Momoyama Bakufu no Odori / Mystical Ninja Starring Goemon Ganbare! Nippon! Olympics 2000 Hyper Olympics in Nagano 64 / Nagano Winter Olympics ‘98 J.League Tactics Soccer Mario Artist Paint Studio (64DD) Paper Mario Legend of Zelda, The - Ocarina of Time - Master Quest (Debug) Legend of Zelda, The - Ocarina of Time (Debug) International Superstar Soccer 2000 International Track & Field - Summer Games / International Track & Field 2000 Jikkyou J.League 1999 - Perfect Striker 2 Legend of Zelda, The - Majora’s Mask (Debug) Mario Party 3   [[USA, PAL, +not+ Japan]] Midway’s Greatest Arcade Hits - Volume 1 Pokemon Stadium 2 / Pocket Monster Stadium 3 4567 (64DD) Doshin the Giant 2 (64DD) Mario Artist Communication Kit (64DD)LuigiBlood has written a script for the Project64 emulator that logs IS-Viewer64 function calls that can be used with the games listed above:EmuScripts/N64/Project64/IS64Log.js at master · LuigiBlood/EmuScripts · GitHubPrototype Cartridges (NUS-8F16F/NUS-16F32SB/NUS-16F32S/NUS-16F32S) Rewritable Prototype cartridges were available to buy and came in 128Mb, 256Mb and 512Mb configurations, with the largest capacity being the most expensive. These were given out to journalists to preview/review the games in their magazines before the official launch of the game along with being used to demonstrate upcoming games at trade shows such as E3 12. They are double the size of regular N64 games and they are actually re-writeable 7 at a time using a flashing device by Intelligent systems. Unofficial N64 Development KitSN64 (SN Systems)SN Systems released their own cheaper Nintendo 64 development kit aimed at smaller studios and it was used to create some classic games such as Resident Evil 2 13. It was an SRAM based cartridge with a PCMCIA SCSI-2 interface card and utilized Sn Systems Pro-DG software to upload ROMs on to the cartridge from a Windows PC.You can view a cached version of the official SN systems SN64 development kit thanks to Icequake SN64 Nintendo64 Development ToolsCheck this out!!I recently acquired these #N64dev cartridges called the \"SN64\" and the \"Maestro64\". Manufactured by the company:\"SN Systems\". The more Rare of the two is the Maestro64, which was used for N64 Sound development. #N64 #RETROGAMING https://t.co/9vvlB1MOQ7 pic.twitter.com/NRHoj2Uu34— Gerry_MAN (@GerryRobotics) October 4, 2019Gerry also managed to get it up and running:Check this out!The \"SN64\" SRAM development cartridge. Developed by SN-Systems in the 90's for the #N64.My test setup entails a PCMCIA SCSI-2 interface card, docked to a PC dev laptop running Windows 2000. Software is ProDG debugger + rom uploader GUI.😎👌#N64Dev #RETROGAMING pic.twitter.com/fPCBGRUz50— BehindTheCode (@GerryRobotics) March 1, 2021Maestro64SN Systems also released an unofficial development kit created specifically for Musicians called the Maestro64, we have another post specifically for this piece of hardware. Maestro64 For information about SN Systems’s Maestro64 development cartridge check out this post. Bung DoctorV64The Doctor V64 was a 3rd Party Development kit and Piracy device that was much cheaper than the official nintendo development kits 14. It is the original Creator of .v64 files (it has functionality to dump carts) and even came with a CD full of N64 roms.Development Studios known to have used The V64 Acclaim/Iguana (Turok series)Technical Specifications Manufacturer: Bung Enterprises Limited Release Date: 1997 Launch Price: $450 USD 15 Onboard CPU: MOS Technology 6502 (8-bit) System Memory: 128 megabits (16 MB) DRAM initially; later revisions included 256 megabits (32 MB) to accommodate larger games. Storage Media: IDE CD-ROM drive (initial runs featured 8x speed; later models were upgraded to 16x and 32x). Interfacing & I/O: Connects to the N64 via the bottom EXT expansion port (which shares the same connector pinout as the top cartridge port) 15. Pass-through cartridge adapter to mount a retail N64 cartridge, acting solely as a donor to satisfy the console’s PIF (Peripheral Interface) and CIC security handshake. Standard Parallel Port located on the rear for PC data transfer. Pass-through Cartridge AdapterThe Bung Dr V64 required a cartridge to be placed in the cartridge slot in order to interrupt the signal coming from the official game cartridge and instead send the data from the V64. The original cartridge that you put in the top was just used for the CIC anti-piracy check.Doctor V64 emulation cartridge adapter; 50-pin connector and PCB with solder across pin 9 and 10 #N64dev pic.twitter.com/tqrdJB9wZU— Shane Battye 🎮 (@shanebattye) January 30, 2018Core Functionality Cartridge Dumping: Capable of copying native N64 cartridge data directly into its internal DRAM. This data can be transmitted to a PC over the parallel connection. The ubiquitous .v64 ROM file extension originated directly from this hardware. ROM Execution: Loads binary game files from a CD into DRAM, allowing the console to boot them as if they were genuine cartridges. Media Playback: Operates as a standalone external Video CD (VCD) player. System BIOS: Utilized a custom BIOS that could be updated or replaced by pushing a new firmware file over the PC transfer cable.Connecting a Doctor V64 to a Windows PC for N64 DevelopmentBehindTheCode has a detailed video demonstrating how to configure a Doctor V64 backup device with Windows 98 and Windows 7 PCs to create a complete Nintendo 64 development test station. The video explores the device’s internal PCBAs and demonstrates using software like TPC2 and RTOOL64 for loading ROMs into the DrV64’s internal SRAM and dumping cartridge data directly to a PC. Additionally, it highlights a rare Acclaim “ArtSend” development cartridge setup that was utilized during the creation of Turok 3.Rareware custom cartridgesRAREWARE N64 security dongleCheck this out!This is a proprietary RAREWARE N64 security dongle.These adapters prevented N64 prototype games from booting, unless the Dongle was connected.Used by Rare Ltd. specifically during development of games such as Conker's Bad Fur Day.#RETROGAMING #N64Dev #gamedev pic.twitter.com/WdyvTj3mhX— BehindTheCode (@GerryRobotics) November 24, 2020Official Sound Development ToolsNintendo released multiple hardware for Sound designers to test their creations on the real hardware without having to bug the developers to borrow a full development machine.The SDK also came with the N64 Sound Tools and MusyX Audio Tools which contain software such as a sound sample editor which used a format similar to MIDI 16.NUS-SUD (Sound development)Gerry_MAN has taken some excellent photos of his NUS-SUD on Twitter along with photos of him actually managing to connect and send data from his PC to the hardware!Check this out!The #N64dev SoundTools Dev cart streams Music or samples in real-time to the #N64. Sent over an LPT printer cable. Notice the white squares? @ the bottom of the screen? Sound PEAK meters!!Inactive when the Cart is not streaming sound.Pretty cool!! #RETROGAMING pic.twitter.com/ZpgL1RtSdD— Gerry_MAN (@GerryRobotics) 10 October 2019For the Updated version 3.0 of the ROM you can actually see the pre-existing peak meter pixels as they are just slightly visible...as shown in the image below. Would be cool to get a Version 3 of the SoundTools cart someday. Pretty Awesome!!😎👌 pic.twitter.com/xAZ8moXAXe— Gerry_MAN (@GerryRobotics) 10 October 2019Full Devkit used by Sound designersThe full n64 development kit was used by Sound designer Grant Kirkhope at Rare to produce masterpieces such as Banjo-Kazooie and GoldenEye. This consisted of a Silicon Graphics Indy with the N64 hardware used as an extension inside it 16.Hmmm I don't think I did. I had a Silicon Graphics Indy computer with the Ultra 64 circuit board inside it. I connected my PC to it via midi— Grantilda Von Scarehope (@grantkirkhope) October 10, 2019References Nintendo 64 development hardware - N64 Squid ↩ NEXT Generation Issue #14 February 1996 ↩ ↩2 EDGE 20 1995-05 ↩ Development Hardware ↩ Development Tools Summary ↩ Guid to NINTENDO64 development tools ↩ ↩2 IS64 and KMC N64 Titles - Pastebin.com ↩ ↩2 NESWORLD.COM - IS VIEWER64 (N64 DEVELOPMENT UTILITY) ↩ BTC #3 RARE Nintendo N64 “IS-VIEWER 64” Development Cartridge - NOW WORKING!! - YouTube ↩ RARE N64 “IS-VIEWER 64” SCSI Development Cartridge - Up and Running!! - Nintendo 64 Forever ↩ IS64 - z64 wiki ↩ Duke Nukem Prototype ↩ Gamasutra - Postmortem: Angel Studios Resident Evil 2 N64 Version ↩ Bung Doctor V64! A 3rd-Party N64 Development System - H4G - YouTube ↩ The Doctor V64 - Nintendo 64 DevKit or Piracy Device - MVG - YouTube ↩ ↩2 Gerry_MAN on Twitter ↩ ↩2 ", "excerpt": "The website N64Squid has a page dedicated to Nintendo 64 development hardware that is well worth a look: Nintendo 64 development hardware - N64 Squid. This page aims to compliment that page and give additional details about the hardware, so it is recommended you read that page first 1. Official...", "tags": ["n64","devkit","hardware"], "image": "/public/N64/N64 Development Kit Hardware.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo 64 Hardware Architecture", "url": "/n64-hardware-architecture", "content": " The Nintendo 64 hardware brought incredible processing power into players homes with its 64-bit architecture and state of the art graphics. In order to pull this off Nintendo worked with SGI and a number of manufacturers to develop a PCB that would not only deliver power but would also be affordable to the average consumer. The custom chips inside the N64 all have the suffix NUS which stands for Nintendo Ultra Sixtyfour. CPU (CPU-NUS A) (9726XK053) The CPU was called the VR4300 which was a derivative of the 64-bit MIPS R4300i, it developed by a partnership between SGI and Nintendo and manufactured by NEC 1. It ran at 93.75MHz and has an onboard 24 KB L1 cache 2. RCP-NUS (Reality Co-processor) (9727EK078) Unlike most PC hardware at the time the Nintendo 64 has the advantage of having its own stand alone graphics processor known as the Reality Co-Processor (RCP). This freed up the main CPU from having to do any graphics calculations and it could use all its processing power for the main game logic. The RCP chip was developed by a partnership between SGI Inc and Nintendo and the retail version was physically manufactured by NEC 1. The RCP is actually split into two distinct parts one for the Gemotry transformations known as the Reality Signal Processor (RSP) and the other for the Per-pixel calculations known as the Reality Display Processor (RDP). You can see the de-capped chip on the left, showing the main parts such as the RDP and RSP. The Reality Display Processor (RDP) is used to render the polygons into 2D pixels that it stores in the FrameBuffer ready to be displayed on the screen. N64 RDP - Reality Display Processor For more information about the Reality Display Processor check out this post. The N64 Reality Signal Processor (RSP) is the part of the Reality Co-Processor (RCP) that deals with data transform. It is a MIPS-based cpu like the main R4300 cpu but it also contains additional 8-bit vector opcodes. N64 RSP - Reality Signal Processor For more information about the Reality Signal Processor check out this post. PIF(P)-NUS (PIF)The Peripheral Interface Bus (PIF) handles all the input from external peripherals such as the game controllers. It has a small Initial Program Loader which is about 2kb of code.It also was used for security to region-lock and prevent piracy, it does this by waiting for the security chip in the cartridge before it loads the next IPL from the cartridge 1.It was designed by Nintendo but manufactured by Sharp.Nintendo RDRAM18-NUS (9727LU641) The RDRAM came as a standard 4MB and was manufactured by NEC, you could get an additional 4MB if you used the Expansion Pak 1. MX8330MC (Main Clock)The MX8330MC is a RAMBUS clock generator developed by Macronix, hence the MX in the name.Audio/Video HardwareAMP-NUS (Audio Amp)The Audio Amp used for any audio playback and fun actions as a regular amp.9480F16-bit stereo audio DAC.DENC-NUS (Dac Encoder)The Dac Encoder is used for processing videoCartridge hardwareMask ROMSThe Mask ROMS were manufactured by Macronix and contained all the game data in a single chip 1.References EEVblog #491 - Nintendo 64 Game Console Teardown - Page 1 ↩ ↩2 ↩3 ↩4 ↩5 Nintendo 64 technical specifications - Wikipedia ↩ ", "excerpt": "The Nintendo 64 hardware brought incredible processing power into players homes with its 64-bit architecture and state of the art graphics. In order to pull this off Nintendo worked with SGI and a number of manufacturers to develop a PCB that would not only deliver power but would also be...", "tags": ["n64","hardware","consolearchitecture"], "image": "https://img.youtube.com/vi/ScicrgZwvg4/hqdefault.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "N64 MIPS Assembly Video Tutorials", "url": "/N64MipsAssembly", "content": "IntroductionFraser N64 has created a series of YouTube videos where he teaches N64 MIPS programming from the ground up. This page is designed to act as notes as you follow along with the tutorials.First of all in order to help support the creation of more excellent N64 MIPS tutorials, consider subscribing to Fraser here:Fraser N64 - YouTubeAlso if you are lucky you can catch the stream live here: fraserN64 - TwitchSource Code and ResourcesYou can access all the source code and resources referenced in the videos here: fraser125/N64_ASM_Videos: The files complementing my video series N64 MIPS AssemblyGlossary of Key TermsIf you are new to MIPS or N64 development, these terms are fundamental to the workflow: MIPS - Microprocessor without Interlocked Pipelined Stages; the RISC architecture used by the N64. bass - A versatile, multi-architecture assembler created by near, used extensively for N64 projects. n64chain - A pre-built GCC toolchain specifically configured for creating Nintendo 64 programs. MAME - Multiple Arcade Machine Emulator; used here for its built-in debugger which is superior for inspecting N64 CPU state.Lesson 001 - Dev Environment SetupThis section is based on the technical walkthrough by Fraser N64 and covers the initial setup of a Windows-based development environment for N64 MIPS development.Essential Development ToolingHere is the essential software stack: bass Assembler - The primary tool for converting assembly source into N64 ROM data. The ARM9 github fork is the standard version used for these tutorials. GCC for Windows - Used for creating Windows-side tools or if integrating C code into the pipeline. n64chain - Essential for projects requiring the standard C library or more complex compilation. Notepad++ - A recommended text editor for its speed, simplicity, and customization options. Legacy Windows Calculator - The Windows 7 version is preferred over the Windows 10 app for its much more intuitive binary bit-view, which is crucial for manually verifying register values and bitwise operations. GitHub Desktop - Recommended for users who prefer a GUI for version control and cloning test repositories, such as Peter Lemon’s N64 tests.Emulator and Debugger ConfigurationTo run N64 software in MAME, you must have the N64 BIOS files. The file n64.zip must be placed inside the roms/ directory of your MAME installation. It is recommended to leave this file zipped to ensure MAME recognizes it correctly.Launching the DebuggerThis view provides direct access to the MIPS architecture internals: GPRs - General Purpose Registers. MIPS contains 32 of these (ranging from zero to ra), though roughly 30 are practically usable since a few (like the zero register) are hard-wired by the architecture. HI / LO Registers - Special-purpose registers used specifically to hold the 64-bit results of integer multiplication and division. Floating Point Registers - The Coprocessor 1 (CP1/FPU) register set natively used for floating-point mathematical operations on the N64.Repo Layout and Template BaselineThe N64_ASM_Videos repo is structured as a set of self-contained projects per lesson plus a shared LIB/ folder. Knowing where things live makes the later lessons much easier to follow.Here is the high-level layout used by the repo: Template - A minimal bootable ROM skeleton (Template/Template.asm, Template/N64_Header.asm, Template/make.cmd). LIB - Shared includes, macros, and binary assets such as LIB/N64.INC, LIB/N64_GFX.INC, and LIB/N64_BOOTCODE.BIN. Video002 … Video009 - Per-video projects that repeat the same pattern: Video00X.asm, N64_Header.asm, make.cmd, and the built Video00X.N64.Build Loop (bass + chksum64)The repo uses the same 2-step build loop in every make.cmd: assemble, then patch header checksums.For example, Template/make.cmd looks like this:@echo offbass Template.asm -strict -benchmarkchksum64 Template.N64This matters because chksum64 is not optional: without it, CRC placeholders in the header remain unpatched and the ROM often will not boot reliably in stricter emulators or on hardware.One-Click MAME Run and Debug ScriptsThe repo includes wrapper scripts that take a ROM path and launch MAME from a fixed install directory. This avoids retyping long mame64.exe ... commands every iteration.The basic pattern used in bass/run.cmd is:@echo offset ROM=%~dpnx1set OLDDIR=%CD%cd \\mamemame64.exe n64 -window -cart %ROM% -switchres -nofilterchdir /d %OLDDIR%bass/debug.cmd is the same idea but launches with -debug -log -verbose enabled so you drop straight into the debugger and get a log file.Toolchain Shells (n64chain + gcc)If you also use the repo’s n64chain/ and gcc/ tooling, it provides small helper scripts that just set PATH and keep a dedicated prompt open.For example, n64chain/WinN64.cmd is:@ECHO OFFSET PATH=C:\\n64chain\\bin;%PATH%ECHO N64 GCC Command PromptRepo Naming ConventionsThe repo uses simple file naming conventions to separate macros/constants from executable code: .asm - Main program file (entry point + top-level flow). .INC - Variables, constants, and macros (included as source). .S - Function bodies, often called via macros or jal.Workflow AutomationThis section covers small Windows-side workflow tweaks that keep your build loop fast and your logs visible.Persistent Command PromptsStandard batch files close their terminal window immediately upon completion, which wipes out your compilation errors and build history.By creating a Windows shortcut to your batch file and modifying the target, you can force the environment to stay open:%COMSPEC% /k \"C:\\path\\to\\your\\script.bat\"The /k parameter tells the command processor to carry out the command specified by the string but remain open, leaving you at a command prompt precisely where you need to be to run repeated bass assembly commands. You can pin these shortcuts directly to your taskbar for quick access.MAME Launch ScriptsBecause developers do not use a frontend, typing the full MAME executable path and N64 launch parameters repeatedly becomes tedious. A common pattern is to create a run.cmd and debug.cmd wrapper that takes a ROM path, changes into the MAME install directory, then launches MAME.If you are following along with the N64_ASM_Videos repo, prefer its existing wrappers (bass/run.cmd and bass/debug.cmd) rather than inventing your own. The key detail is that the wrapper should pass an absolute ROM path (the repo uses %~dpnx1) so it still works after switching directories.Lesson 002 - bass Assembler KeywordsThis section covers the fundamental keywords and directives used by the bass assembler to structure a Nintendo 64 ROM.Walkthrough: Video002.asm Minimal Bootable ROMThe N64_ASM_Videos repo includes a minimal, bootable skeleton in Video002/Video002.asm that is a good reference for what a known-good bass project looks like.This is the directive block used by the repo:arch n64.cpuendian msboutput \"Video002.N64\", createfill $0010'1000origin $00000000base $80000000include \"../LIB/N64.INC\"include \"../LIB/N64_GFX.INC\"include \"N64_Header.asm\"insert \"../LIB/N64_BOOTCODE.BIN\"Two directives that are easy to confuse early on are origin and base: origin is the current write cursor inside the output ROM file (a file offset). base is the runtime address space that labels resolve to (the address you will see in the debugger).In the repo’s layout, the first 0x1000 bytes are deliberately reserved for the header + bootcode, which is why the label Start: typically ends up at 0x80001000 with base $80000000 (this is explained in more detail in the header section below).Build uses the same make.cmd pattern described in Lesson 001: assemble with bass -strict -benchmark, then run chksum64 on the resulting ROM to patch header CRCs.Core bass DirectivesThe main directives required for an N64 project include: arch - Defines the target architecture. For the primary N64 CPU, use arch n64.cpu. The assembler also supports n64.rsp for the Reality Signal Processor and n64.rdp for the Reality Display Processor. endian - Defines the byte order. The N64 uses Big-Endian, so this must be set to endian msb (Most Significant Bit). output - Specifies the filename of the generated ROM. Using output \"name.n64\", create tells the assembler to generate a completely new ROM from scratch. origin - Sets the current positional cursor within the output ROM file, which dictates exactly where the following bytes of code will be physically placed. fill - Used to write zero-padding into the ROM.Here is an example of what the top of your main assembly file will look like:arch n64.cpuendian msboutput \"lesson2.n64\", createfill 1052672The Purpose of FillWhen the N64 boots, it automatically copies the first 1 Megabyte of the game cartridge into the console’s RAM.To prevent the console from copying garbage memory if the game is smaller than 1MB, developers pad the ROM with zeros.The value 1052672 is derived from adding the size of the 4KB header (4096 bytes) to exactly 1 Megabyte (1048576 bytes).File Modularization DirectivesIt is crucial to understand the difference between these two keywords: include - Works like #include in C. It parses the external file as source code. If the file contains macros or constants, they are loaded into memory but no bytes are written to the ROM unless those macros are explicitly invoked. insert - Treats the target file as raw binary data. It grabs the file byte-by-byte and writes it directly to the output ROM at the exact physical location of the insert command.Example usage:include \"lib/n64.inc\" // Loads constants and macros, writes nothing yet.insert \"n64_bootcode.bin\" // Physically dumps 4KB of raw binary boot code here.The N64 HeaderThis section covers the small metadata block at the start of an N64 ROM, and the handful of fields you typically touch first when building a ROM from scratch.In the N64_ASM_Videos repo, the header file N64_Header.asm is structured to occupy exactly 0x40 (64) bytes, and it is immediately followed by a 0xFC0 (4032) byte bootcode blob. Together, these add up to 0x1000 (4096) bytes, which is why the repo’s entrypoint code label typically starts at 0x80001000 when base $80000000 is used.Data Width KeywordsWhen manually constructing the header or laying out data, you use specific keywords to tell bass how many bytes to allocate for the literal value: db - Data Byte (1 byte / 8-bit) dw - Data Word (4 bytes / 32-bit). Note: A “word” on the MIPS architecture is strictly 32 bits. dd - Data Double (8 bytes / 64-bit)Strings can be placed easily using db. The N64 header allows for a 27-character string name:db \"MY FIRST N64 GAME \" // Pads the remaining space with spacesCRC CalculationThe header also contains two placeholder words for the CRC (Cyclic Redundancy Check) checksums. The N64 boot process calculates the checksum of the first megabyte and compares it to these header values. If they do not match, the game will not boot on hardware.Because the CRC requires the final compiled ROM, the assembler leaves placeholder dw values. You must run a secondary tool-such as sum64 or chksum64-as a post-assembly step in your build script to calculate the true CRC and inject it back into the header.Debugging in MAMEIn the MAME debugger command line, use the bp (breakpoint) command:bp 80000400Address 0x80000400 is conventionally where control is handed over to the user’s game loop. From there, you can press F10 (Step Over) or F11 (Step Into) to walk through the instructions line by line while inspecting the MIPS registers.Lesson 003 - Registers and First 6 InstructionsThis section covers the MIPS architecture fundamentals, register layout, and foundational instructions.Walkthrough: Video003 First InstructionsThe N64_ASM_Videos repo includes a minimal entrypoint in Video003/Video003.asm that is useful for understanding what these first instructions do in practice.This is the first block of real code the repo runs after Start::Start: lui t0, PIF_BASE addi t1, zero, 8 sw t1, PIF_CTRL(t0)Loop: j Loop nopThis short sequence is doing three important things: It uses lui to build a memory-mapped IO base address in a register (t0). It uses addi with zero to create a small immediate (t1 = 8) without needing a pseudo-instruction. It uses sw base+offset addressing to write to a specific hardware register.If you expand the address math, this write becomes very concrete: PIF_BASE is defined in LIB/N64.INC as 0xBFC0, so lui t0, PIF_BASE yields t0 = 0xBFC00000. PIF_CTRL is defined in LIB/N64.INC as 0x07FC, so sw t1, PIF_CTRL(t0) writes to 0xBFC00000 + 0x07FC = 0xBFC007FC.In debuggers, you will often see these addresses sign-extended into 64-bit registers as FFFFFFFFBFC00000 and similar values. That is normal on the VR4300 and is the same sign-extension behaviour described later in this lesson.Memory HierarchyThe MIPS architecture is referred to as a register architecture because all data must be loaded into a register, operated upon, and then written back out to memory.The typical flow follows this speed hierarchy (fastest to slowest): Registers - Located physically at the center of the CPU, these operate with zero latency. Cache - The N64 MIPS CPU has separate Data and Instruction caches. Console RAM - Fast, dynamically allocated memory. Cartridge ROM - The slowest medium of the immediate hierarchy.MIPS Register ArchitectureWhile you can technically use any register for anything (except register 0), developers adhere to strict conventions to ensure code compatibility: zero (r0) - Hardwired to the value 0. Any attempt to write to it fails silently. at (r1) - Assembler Temporary. Reserved for assembler pseudo-instructions. v0-v1 (r2-r3) - Used exclusively for function return values. a0-a3 (r4-r7) - Used to pass arguments into functions. t0-t9 (r8-r15, r24-r25) - Temporaries. Function-local variables that do not need to be saved to the stack before calling another function. s0-s8 (r16-r23, r30) - Saved registers. Global variables; if a function modifies these, it must back up the original value to the stack and restore it before returning. k0-k1 (r26-r27) - Kernel variables. Strictly reserved for system exception handling. sp (r29) - Stack Pointer. Used to save context during function calls. ra (r31) - Return Address. Populated by Jump-and-Link instructions so the CPU knows where to return after a function call completes.Assembly Syntax and FormattingThese formatting rules are conventions that make low-level code easier to scan, especially when you are comparing register state in a debugger to what you wrote in source: Whitespace is ignored - Tabs or spaces are purely for human readability. Instruction format - The line begins with the instruction mnemonic, followed by 1 to 4 parameters separated by commas. Right-to-Left evaluation - For most instructions, the destination register is listed first on the left, but conceptually the operation evaluates the right-hand elements and places the result into the left. Exception: sw - The Store Word instruction works left-to-right (take the data on the left, store it to the address on the right).Foundational MIPS InstructionsThese are the baseline building blocks used throughout the early lessons before you start leaning on heavier macro abstractions.Loading Immediate DataAn immediate instruction incorporates literal data directly inside the instruction’s opcode itself, rather than reading it from RAM. lui (Load Upper Immediate) - Takes a 16-bit constant and loads it into the upper 16 bits of the 32-bit space of a register, padding the lower 16 bits with zeros. addi (Add Immediate) - Adds a literal constant to the value of a source register and stores the result.Memory StorageThese instructions move data between registers and memory. sw (Store Word) - Grabs a 32-bit word from a register and writes it into memory. It takes a destination address and an offset value. MIPS also has variants like sb (Store Byte), sh (Store Halfword), and sd (Store Double/64-bit).Control FlowThese instructions change what executes next. j (Jump) - Unconditionally shifts execution to a specific label/address. An infinite loop can simply be j loop_label. nop (No Operation) - Instructs the CPU to do absolutely nothing for one cycle.Delay SlotsMIPS architecture relies heavily on Delay Slots-a quirk where the instruction placed immediately after a branch or jump is executed before the jump actually takes effect. This happens because the CPU pipeline has already fetched the next instruction while calculating the jump destination. During early development, it is common practice to simply place a nop in the delay slot to prevent execution errors.Sign ExtensionWhen loading 32-bit values into the N64’s 64-bit registers, the CPU performs Sign Extension.If the highest bit (the sign bit) of the 32-bit value is 1 (indicating a negative value in a signed integer), the CPU extends that 1 across the entire upper 32 bits of the 64-bit register. This is why memory addresses frequently appear in the debugger padded with Fs (e.g., FFFFFFFFBFC00000). While initially confusing, the N64 memory management unit largely ignores the upper 32 bits when addressing 32-bit software space.Lesson 004 - Memory Mapped Hardware and Video InitThis section details the Nintendo 64 memory mapping, hardware interfaces, and the assembly required to initialize the video subsystem.Walkthrough: Video004 VI Register InitThe N64_ASM_Videos repo includes a complete, explicit VI init sequence in Video004/Video004.asm. It is a useful reference because it shows the exact register writes the later ScreenNTSC(...) macro wraps.The lesson uses a classic pattern: load the VI base, then sw to a series of fixed offsets:lui t0, VI_BASEli t1, BPP16sw t1, VI_STATUS(t0)li t1, $A000'0000sw t1, VI_ORIGIN(t0)li t1, 320sw t1, VI_WIDTH(t0)If you are new to memory-mapped IO, it helps to see the address math that bass is doing for you. This table shows a few of the key VI registers and how their offsets relate to the VI base address: Register Offset Absolute address (KSEG1) VI_STATUS 0x00 0xA4400000 VI_ORIGIN 0x04 0xA4400004 VI_WIDTH 0x08 0xA4400008 VI_X_SCALE 0x30 0xA4400030 VI_Y_SCALE 0x34 0xA4400034 Once you understand the explicit sequence, you can switch to the repo’s macro in LIB/N64_GFX.INC:ScreenNTSC(320, 240, BPP16, $A010'0000)That macro writes the same VI registers, but it also documents what the “magic” constants mean (for example, the VI_TIMING and VI_H_VIDEO fields), which makes it a good long-term reference when you start changing resolution, origin, or scaling.The Flat Memory MapWhen the console boots, the BIOS places the MIPS processor into a 32-bit kernel mode. This provides a 4 Gigabyte (0x00000000 to 0xFFFFFFFF) address space. Even though 64-bit mathematics are available, memory addressing remains firmly in 32-bit.This flat structure makes assembly programming relatively straightforward because all internal systems-such as the Video Interface (VI), Audio Interface (AI), Peripheral Interface (PI), and Serial Interface (SI)-are mapped directly to specific addresses. You do not need complex port configurations; you interact with the console’s hardware simply by reading and writing to standard memory addresses.Cached vs. Uncached MemoryThese address ranges actually point to the exact same physical memory on the motherboard: 0x80000000 (Cached) - Operations hit the CPU caches first. While reads from the cache take just 1 CPU cycle, writes stay in the cache until manually flushed to physical RAM. 0xA0000000 (Uncached) - Bypasses the internal CPU cache entirely and interacts directly with physical RAM.For example, 0x80000400 and 0xA0000400 access the identical location in memory. When updating hardware subsystems like the Video Interface, you must either write to the 0xA uncached range or write to the 0x8 cached range and remember to trigger a cache flush command so the hardware actually receives the data.Initializing the Video Interface (VI)When writing values to configure the Video Interface, two technical boundaries exist: Resolution Limits - The hardware only outputs at 320x240 or 640x480. Attempting to render non-standard internal resolutions will just draw them inside the standard 320x240 canvas surrounded by physical black borders. Color Depth - The standard format is 16 Bits-Per-Pixel (BPP). The n64 structures this as an RGBA 5-5-5-1 layout (5 bits Red, 5 bits Green, 5 bits Blue, and 1 bit Alpha transparency).A fun trick during early development: Setting the frame buffer origin address to point to the start of your game code memory (e.g., 0xA0001000) will force the VI to render your compiled assembly instructions to the television screen as blobs of static color data.Assembly Quality of Life TricksHere are techniques commonly used in MIPS projects: Pseudo-instructions - The li (Load Immediate) command doesn’t actually exist in the MIPS CPU. It is a pseudo-instruction that the assembler automatically splits into two real instructions at compile time: lui (Load Upper Immediate) and ori (Or Immediate). This keeps your source code highly readable without sacrificing exact register control. Hexadecimal Ticks - Reading long memory addresses is error-prone. The bass assembler allows inserting a single quote tick ' anywhere inside a hexadecimal number as a visual separator (e.g. 0x8000'0000). It compiles the same but is far easier to read. Compile-time Math - Mathematical functions can be placed directly in the source file, such as configuring resolutions via 320 * 240. The assembler evaluates this calculation before generating the ROM, costing zero CPU cycles during gameplay. NOP Padding - Using three consecutive nop (No Operation) instructions creates an obvious blank block inside the MAME memory debugger. This is an excellent tactic for placing visual boundaries between distinct functions or initialization loops.Lesson 005 - Draw Line & Branching Delay SlotThis section covers the fifth technical walkthrough by Fraser MIPS, focusing on drawing basic lines to the screen and understanding the nuances of the MIPS pipeline and delay slots.Frame Buffer Memory PositioningA standard practice is to place the frame buffer exactly at the 1 Megabyte mark (0x00100000).To set this up cleanly using the assembler: Convert 1 Megabyte to bytes: 1024 * 1024 = 1,048,576 bytes. Convert to hexadecimal: 0x100000. Assign this as your VI Origin (Video Interface Origin) pointer.Pixel Coordinate MathThe formula for finding the offset of a single pixel is:((Y_Position * Screen_Width) + X_Position) * Bytes_Per_PixelFor example, to start a line 15 rows down and 110 columns in on a 16-bit (2 bytes per pixel) display:((15 * 320) + 110) * 2This yields the literal memory offset that should be added to your frame buffer’s base address to locate the exact destination for your pixel color data.Writing 32-bit ColorsYou achieve this by loading the same 16-bit color constant into both the upper and lower halves of a temporary register: lui - Loads the 16-bit color into the upper half of the register. ori - Loads the identical 16-bit color into the lower half of the register.Now, a single sw (Store Word) command writes two adjacent pixels to the frame buffer simultaneously.Walkthrough: Video005 Horizontal Line (Two Pixels Per Store)The repo’s Video005/Video005.asm is a concrete implementation of the pixel math described above. It draws a horizontal line by writing 32-bit words into a 16bpp framebuffer.The key trick is that the repo packs a single 16-bit color constant into both halfwords of a 32-bit register, so each sw produces two adjacent pixels of the same color:lui t0, LAWN_GREEN16ori t0, t0, LAWN_GREEN16Then it computes the starting pixel pointer using the same formula, and loops in 4-byte steps:la t1, $A010'0000addi t1, t1, ((320 * 15) + 110) * 2addi t2, t1, 200do_Store2Pixels: sw t0, 0(t1) bne t1, t2, do_Store2Pixels addi t1, t1, 4This loop is also a good demonstration of why delay slots matter: the addi t1, t1, 4 runs in the branch delay slot, so it executes even on the final iteration when the branch falls through. When you start writing your own loops, be explicit about whether your end pointer is inclusive or end-exclusive so you do not accidentally do one extra store.Loop ConstructionMIPS favors a do-while loop structure. The typical flow is: Calculate the starting pixel address (t1). Calculate the ending pixel address (t2). Store the pixel color into the address at t1. Increment the pointer t1 by 4 bytes (addi t1, t1, 4). Compare t1 and t2. If they are not equal, branch back to Step 3 (bne t1, t2, loop_label).The MIPS Pipeline and Delay SlotsThe Branch Delay Slot is the single instruction located immediately after a branch or jump command. Because of how the pipeline fetches instructions, this slot is executed before the jump actually takes effect.Pipeline Rules and PerformanceHere are a few practical rules of thumb that help avoid accidental slowdowns and hard-to-debug control flow issues. Register-to-Register (e.g., addi): These take 5 pipeline cycles. Placing one in a branch delay slot is the most efficient use of CPU time, essentially granting you a “free” instruction calculation while the branch evaluates. Load and Store (e.g., sw): These are blocking operations. If placed in a delay slot, they halt the pipeline, taking 11 pipeline cycles (wasting roughly 3 clock cycles). Do not place them in delay slots. Branch inside a Branch: Placing a jump or branch inside the delay slot of another jump causes completely unpredictable execution behavior and should be strictly avoided. Pseudo-instructions: Never place pseudo-instructions (like la or li) inside a delay slot. They can secretly expand to multiple literal instructions during assembly, meaning only half of the intended operation will fit into the single delay slot, breaking your code.Best Practice: If you cannot find a suitable register-to-register calculation to place in a delay slot, always use a nop (No Operation) to keep the pipeline stable.Lesson 006 - Draw Vertical Line & Delay Slot OptimizationThis section covers the sixth technical walkthrough by Fraser MIPS, detailing the structural changes needed to draw vertically and how to implement a practical MIPS delay slot optimization.Vertical Line Logic and Coordinate MathInstead of an end address, a vertical line loop relies on a specific counter register (e.g., t2) that decrements on each pass, terminating when it hits zero. This is easily checked using the MIPS zero register (r0).The Screen Pitch TrapWhen moving horizontally, memory is perfectly linear. When moving vertically, you must jump down an entire row in memory.A common bug when calculating this jump is forgetting about the pixel data size. If the screen is 320 pixels wide, you do not simply add 320 to the pointer to move down one row. You must multiply the width by the Bytes-Per-Pixel (BPP).For a 16-bit display (2 bytes per pixel), the mathematical stride (or “pitch”) is:320 * 2 = 640 bytes.If you incorrectly add just 320, the N64 will write halfway across the screen horizontally rather than directly below, resulting in strange graphical glitches like drawing multiple half-height lines diagonally.Practical Delay Slot OptimizationA typical vertical line loop might evaluate like this: addi t2, t2, -1 (Subtract 1 from the counter) addi t1, t1, 640 (Move memory pointer down one screen row) bne t2, zero, loop_label (Branch back if counter is not zero) nop (Delay slot buffer)To optimize this and save execution time, you can pull the counter subtraction out of the main loop body and place it directly into the branch delay slot: addi t1, t1, 640 bne t2, zero, loop_label addi t2, t2, -1 (Executes “for free” while the branch resolves)Because the CPU always evaluates the delay slot before taking the jump, the counter is safely decremented on every pass, speeding up the geometry rendering loop.Walkthrough: Video006 Vertical Line (Pitch in the Delay Slot)The repo’s Video006/Video006.asm shows a practical version of this optimisation pattern. It decrements the counter in the loop body, then advances the framebuffer pointer by one full row in the branch delay slot:addi t2, r0, 200do_Store2Pixels: sw t0, 0(t1) addi t2, t2, -1 bne t2, r0, do_Store2Pixels addi t1, t1, 320 * 2This is a good template for learning because the delay-slot instruction is a single real instruction (addi), not a pseudo-instruction like li or la, so it cannot expand into multiple instructions and accidentally break control flow.Pitfall: sw Writes Two Pixels in 16bpp ModeIn Video006/Video006.asm, the color is loaded as lui t0, LIGHT_BLUE16 but the matching ori is commented out. That means the lower 16 bits of the store are 0x0000, so each sw writes one LIGHT_BLUE pixel and one black pixel.If you want each sw to write two identical 16bpp pixels, pack the color into both halfwords:lui t0, LIGHT_BLUE16ori t0, t0, LIGHT_BLUE16Lesson 007 - bass Macros and Debugger ScriptsThis section covers the seventh technical walkthrough by Fraser MIPS, focusing on code restructuring using bass assembler macros and automating the MAME debugger.Restructuring with Compile-Time MacrosIt is crucial to understand that bass macros evaluate strictly at compile-time. When the assembler encounters a macro call, it literally copies and pastes the underlying instruction block into the compiled ROM at that exact location. It does not perform a function jump (jal). If you invoke a large macro 20 times, the code is duplicated 20 times, heavily inflating the ROM size.Repo Macro Examples (LIB/*.INC)The N64_ASM_Videos repo leans heavily on macros in LIB/*.INC to keep the main .asm files readable while still being explicit about what gets written to hardware.Two macros you will see in almost every lesson project are: init() from LIB/N64.INC, which performs early boot stabilisation and sets up a usable stack pointer. ScreenNTSC(width, height, status, origin) from LIB/N64_GFX.INC, which is covered in more detail in Lesson 004 (it wraps the same VI register writes shown in Video004/Video004.asm).When you are learning, it is worth reading the macro bodies in LIB/N64.INC and LIB/N64_GFX.INC because they also serve as documentation: the repo includes comments that describe what each VI timing constant represents.Macro Syntax RulesWhen declaring a macro in bass, you must follow strict syntax constraints: The macro must be declared above where it is used in the source file. The opening curly brace { must reside on the exact same line as the macro declaration. The closing curly brace } can be on its own line.Example of wrapping the Video Interface setup:macro init_video() {lui t0, 0xA440sw zero, 0x0010(t0)// ... extra instructions ...}Handling Macro ParametersBecause macros are compile-time text replacements, the passed arguments do not automatically land in CPU registers. You must explicitly load the parameter placeholder into a register inside the macro using pseudo-instructions like la (Load Address) or li (Load Immediate).macro screen_setup(width, height, origin) {la t0, {origin}li t1, {width}// Now t0 and t1 contain the passed parameters}Automating the MAME DebuggerTo automate breakpoints, create a simple text file (e.g., n64_debug.txt) in your working directory and populate it with standard MAME debugger commands:bp 80000400wp 80000400, 4, rwIf you want to launch into MAME’s debugger without rewriting command lines, use the repo’s bass/debug.cmd wrapper described earlier in Lesson 001.Advanced WatchpointsThe wp command in the script above sets a Watchpoint. Unlike a standard breakpoint that halts execution when the Program Counter reaches a line of code, a watchpoint halts execution whenever a specific memory address is accessed.The parameters 80000400, 4, rw instruct MAME to halt if the 4-byte range starting at 0x80000400 is either read (r) or written to (w). This is an incredibly powerful tool for tracking down exactly which function is modifying a variable.Loading the Debug ScriptTo use the script, you append the -debugscript parameter to your debug.bat launch file:mame64 -debug -log -verbose n64 -window -cart \"%ROM_PATH%\" -debugscript \"n64_debug.txt\"When MAME launches, it will execute the commands in the text file and halt at the system reset vector. Simply press F5 to resume execution, and MAME will instantly warp to your custom 80000400 breakpoint.Lesson 008 - Fonts Part 1: Macros and 1-Bit ExpansionThis section covers the eighth technical walkthrough by Fraser MIPS, introducing custom fonts and how to manipulate 1-bit per pixel assets for the N64’s 16-bit display in MIPS-based projects.1-Bit Fonts on the N64The standard ASCII table contains 32 non-printable control characters at the beginning. If your font starts at the first printable character (the Space character), you can easily find the correct graphic by subtracting 32 from the character’s standard ASCII decimal value.Because of the 1bpp density, an entire 8x8 ASCII font set requires extremely little memory-roughly 760 bytes. However, the N64 hardware only draws in 16-bit or 32-bit color depths. Therefore, before the font can be drawn to the screen, a routine must parse the 1bpp data and expand it into full 16-bit colors in RAM.Repo Walkthrough: PIXEL8 Font Pipeline (Video008/Video009)The N64_ASM_Videos repo implements an end-to-end font pipeline using a 1bpp 8x8 font file and a pair of routines in LIB/PIXEL8_UTIL.S.At a high level, the pipeline is: Insert the 1bpp font data into the ROM (the repo uses LIB/PIXEL8.FNT). Call pixel8_init16(...) once to expand the 1bpp font into a 16bpp font atlas in RAM. Call pixel8_static16(...) to blit characters from the expanded atlas into the framebuffer.The repo wraps these routines with small calling macros in LIB/PIXEL8_UTIL.INC so the call sites stay readable. For example, pixel8_init16(destination, forecolor, backcolor) is implemented as a macro that sets a0/a1/a2 and then calls the real routine:macro pixel8_init16(destination, forecolor, backcolor) { li a0, {destination} ori a1, r0, {forecolor} jal pixel8_init16 ori a2, r0, {backcolor}}There are two details worth noticing in that macro: It uses the jal delay slot intentionally to load a2 with a single real instruction (ori), avoiding the pseudo-instruction hazard described later in this lesson. It uses registers a0/a1/a2 because the real implementation in LIB/PIXEL8_UTIL.S treats those as fixed parameters (a0 = font destination, a1 = forecolor, a2 = backcolor).Video008/Video008.asm demonstrates the “expand font into RAM” step by calling pixel8_init16(...) twice with different color pairs. Video009/Video009.asm demonstrates rendering text by calling pixel8_static16(...) and defining a ROM string with db \"Hello World!\".Data Inclusion and AlignmentAlways insert external binary assets at the very end of your source file, far away from your program loops.Byte AlignmentWhen inserting binary files, it is highly recommended to enforce byte alignment. You can use the align macro in bass to force the assembler to pad the file with zeros until the data sits on a clean boundary.ALIGN(8)include \"../LIB/PIXEL8_UTIL.S\"Aligning data to an 8-byte boundary is a defensive programming habit that prevents critical crashes when reading blocks of memory into hardware systems like the DMA (Direct Memory Access) controller later on.Repo Detail: How pixel8_static16 Passes Position and LengthIn the repo, the pixel8_static16(...) macro packs the on-screen position into a single register (a2) to keep the call ABI simple. The upper 16 bits are top and the lower 16 bits are left.The macro builds that packed value using two real instructions, avoiding li in a delay slot:lui a2, {top}ori a2, {left}Inside the implementation in LIB/PIXEL8_UTIL.S, the routine unpacks those halves with:srl top, position, 16andi left, position, 0xFFFFThe macro also passes the string length in v1 as a simple safety bound. In the repo this is set with ori v1, zero, {length}, which again stays as a single instruction.File Structure ConventionsThese conventions help keep large projects modular without accidentally emitting bytes into the ROM. .inc files: Used exclusively for macros and constants. Including these at the top of your main file will not write any arbitrary bytes to the ROM. .s files: Used exclusively for pure assembly routines. These should be included carefully, typically at the bottom of your main file, so the routines do not execute accidentally during standard program flow.Jump and Link (JAL)Instead, the macro should only prepare the arguments and immediately call a single, shared assembly routine using Jump and Link (jal):macro init_font(dest, fg_color, bg_color) {li a0, {dest}li a1, {fg_color}li a2, {bg_color}jal expand_font_routinenop // Delay slot}The jal instruction serves two purposes: It jumps to the target label (expand_font_routine). It automatically saves the address of the next instruction into the Return Address (ra) register.Once the expand_font_routine finishes its work, it terminates with a Jump Register (jr ra) instruction, sending the CPU straight back to where the macro was initially called.Repo Implementation Notes: pixel8_init16 Expansion LoopThe repo’s LIB/PIXEL8_UTIL.S shows what a 1bpp-to-16bpp expansion loop looks like in real VR4300 code. Conceptually, it streams bits out of the 1bpp font and writes either the foreground or background 16-bit color into a destination buffer in RAM.One interesting instruction choice in the repo is the use of a branch-likely to place the foreground store in the delay slot:bltzl t1, _continuesh forecolor, 0(font_addr)sh backcolor, 0(font_addr)Because bltzl only executes its delay-slot instruction when the branch is taken, this pattern becomes a compact per-bit decision: If the current bit is set, store forecolor (delay slot runs) and skip the backcolor store. If the bit is not set, the delay slot is nullified and the following sh backcolor, ... runs instead.The routine returns the expanded font memory size (in the repo this is 0x2F80) so higher-level code can allocate multiple font atlases in RAM without guessing sizes.The Delay Slot Pseudo-Instruction TrapNever place an li (Load Immediate) into a branch delay slot.li is a pseudo-instruction. The assembler automatically breaks it down into two separate hardware instructions (lui and ori). The branch delay slot is strictly hardware-enforced to hold only one single instruction. If you place an li there, only the lui half will execute before the jump takes effect, resulting in a corrupted parameter and a broken font initialization.If you must optimize a parameter load into a delay slot, explicitly write the exact single hardware instruction (like ori or addi) yourself.", "excerpt": "Introduction Fraser N64 has created a series of YouTube videos where he teaches N64 MIPS programming from the ground up. This page is designed to act as notes as you follow along with the tutorials. First of all in order to help support the creation of more excellent N64 MIPS...", "tags": ["n64","assembly","tutorial","incomplete"], "image": "/public/N64/N64LearnMIPSAssemblyLanguage.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "N64 RDP - Reality Display Processor", "url": "/n64rdp", "content": "Introduction Unlike most PC hardware at the time the Nintendo 64 has the advantage of having its own stand alone graphics processor known as the Reality Co-Processor (RCP). This freed up the main CPU from having to do any graphics calculations and it could use all its processing power for the main game logic. The RCP is actually split into two distinct parts one for the Geometry transformations known as the Reality Signal Processor (RSP) and the other for the Per-pixel calculations known as the Reality Display Processor (RDP). The N64 Reality Display Processor (RDP) is used to render the Nintendo 64’s game polygons into 2D pixels that it stores in the FrameBuffer ready to be displayed on the screen 1. The functionality of the RDP was first described in an interview with George Zachary in the magazine Next Generation where he described the processor as the big advantage over the Playstation hardware as it allowed advanced features such as Texture Perspective correction which Sony’s hardware could not perform efficiently 2. The RDP is used after the Reality Signal Processor has processed its calculations, so you can think of the RSP as a sort of Vertex Shader and the RDP as a sort of Pixel Shader 3. N64 RSP - Reality Signal Processor For more information about the second half of the RCP known as the Reality Signal Processor check out this post. Purpose of the RDPThe main purpose of the Reality Display Processor was to rasterise polygons into pixels that can be displayed on the screen.But it can also be used for a variety of effects: Anti-Aliasing blending Mip-mapping Texturing (including perspective correction) Trilinear Interpolation Z-bufferingAnti-AliasingOne of the main advantages the N64 had over its competitors was its hardware accelerated Anti-Aliasing. Anti-Aliasing is a technique that makes the graphics look a lot smoother by removing the “jaggies” which are caused by pixels drawing a line in low resolution.While this was a great feature when the N64 was released, people wanting to play N64 on more modern hardware started to hate the blurring effect of Anti-Aliasing. So there have been a number of ways to remove the Anti-Aliasing such as game modifications, game shark cheat codes and hardware modifications.Z-bufferingZ-buffering is vital for 3D game engines for perspective, without it 3d models would just be displayed on the screen in the order you draw them. No matter where they are supposed to be in the 3D scene.This was all handled by the N64’s Reality Display Processor as it handles it on a per-pixel basis. You can even visualise the z-buffer as a black and white image of pixels that have already been written.Components of the RDPThe RDP is built up of a number of sub-components such as memory for Texture data (TMEM), Lookup tables for textures (TLUT) and display lists that hold the result of the RSP’s calculations on the vertices.TLUT (Texture Lookup Table)TLUT stands for Texture Look up table and is stored in TMEM (Texture Memory). The first 2kb of the 4kb TMEM will be the texture look up table if it is used.Texture Memory (TMEM)The Texture Memory (TMEM) located in the RDP can store up to 8 textures (tiles) at one time.Display Lists (DP)Just like Microcode is used to program the Reality Signal Processor (RSP), display Lists are used to program the Reality Display Processor (RDP).Although whether these are really programs is debatable, you can change the functionality similar to the openGL concept of glTexEnv but at its core its a fixed-function pipeline.Display Lists might be similar to a binarized OpenGL display list format for models but this is unconfirmed 3.Emulating the RDPOne of the biggest problems with N64 emulation to date is that the RDP is not emulated at a low level.Instead High Level Emulation or HLE is used, which involves approximating the functionality required instead of accurately emulating the behaviour of the physical chip.There are many benefits to the High level approach, specially the faster speed, but it will never be as accurate as proper low-level emulation.By High Level emulation we mean that the emulator checks which uCode is used for a specific game and instead of running the uCode with a CPU-like emulator it just runs various graphics commands directly.Low level emulation would be emulating each opcode in the uCode 1.Rendering in Low Level Emulation ModeOne of the developers of the N64 emulation plugin GLideN64 known as gonetz has written an excellent series of posts about the difficulties: implementing Low Level Emulation of the N64s RDP.GLideN64: Rendering in Low Level Emulation mode. Part I.GLideN64: Rendering in Low Level Emulation mode. Part IIReferences N64 RDP/RSP ↩ ↩2 NEXT Generation Issue #14 February 1996 : Imagine Media : Free Download, Borrow, and Streaming : Internet Archive ↩ N64 object software renderer in 512 lines ↩ ↩2 ", "excerpt": "Introduction Unlike most PC hardware at the time the Nintendo 64 has the advantage of having its own stand alone graphics processor known as the Reality Co-Processor (RCP). This freed up the main CPU from having to do any graphics calculations and it could use all its processing power for...", "tags": ["n64"], "image": "/public/N64/N64 Reality Display Processor.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "N64 RSP - Reality Signal Processor", "url": "/n64rsp", "content": "Introduction Unlike most PC hardware at the time the Nintendo 64 has the advantage of having its own stand alone graphics processor known as the Reality Co-Processor (RCP). This freed up the main CPU from having to do any graphics calculations and it could use all its processing power for the main game logic. The RCP is actually split into two distinct parts one for the Geometry transformations known as the Reality Signal Processor (RSP) and the other for the Per-pixel calculations known as the Reality Display Processor (RDP). The N64 Reality Signal Processor (RSP) is the part of the Reality Co-Processor that deals with data transform. It is a MIPS-based cpu like the main R4000 cpu but it also contains additional 8-bit vector opcodes 1. The functionality of the RSP was first described in an interview with George Zachary in the magazine Next Generation where he described the processor as specially design for fast Matrix and addition calculations unlike the standard PC RISC and CISC based processors 2. N64 RDP - Reality Display Processor For more information about the second half of the RCP known as the Reality Display Processor check out this post. You can think of the RSP as a more powerful version of the Sony PlayStation’s Geometry Transformation Engine (GTE) in terms of functionality, but the RDP was a huge benefit over the PlayStation as it was able to do effects such as Texture Perspective correction. Sony Playstation Sony PlayStation 1 (PSX) Sony PlayStation 1 (PSX) For more information about Sony’s answer to the Geometry calculation problem known as the GTE check out this post. Usage of RSP for GraphicsCommon tasks given to the RSP for graphical data processing are: Lighting calculations Display List decoding Shading Level of Detail culling (LOD) Clipping Vertex Transforms (translate, scale, rotate)Usage of RSP for AudioCommon tasks given to the RSP for graphical data processing are: Wavetable Audio format decoding Midi Audio processing MP3 decoding (Conkers Bad Fur Day)Memory inside the RSP As you can see from the De-capped RSP chip there are 2 4KB memory sections inside, one labeled as IMEM and the other labeled as DMEM. IMEM is the shorthand for Instruction Memory and is just for Assembly instructions that run on the RSP, this is also known as Microcode or uCode. DMEM is the shorthand for Data Memory and is used for all the data the RSP needs access too, so this would normally be geometry or audio data that it is performing calculations on 3. Instruction Memory (IMEM) (0x04001000 -> 0x04001FFF)Instruction Memory is the executable area of memory inside the RCP that runs microcode, you can sort of think of the microcode as a shader that gets executed by the RSP, however this is not quite the case.Data Memory (DMEM) (0x04000000 -> 0x04000FFF)In order to process data on the RSP the game needs to copy memory into the DMEM section of the RCP at locations 0x04000000 to 0x04000FFF, and copy the result back out into standard DRAM.RSP MicrocodeThe ability to do fast Matrix and Addition calculations is crucial for 3D graphics and Audio Synthesis and decompression, so to take advantage of the specialised CPU programmers had the ability to write custom assembly for this processor known as microcode.Microcode (otherwise known as uCode) is similar to assembly language but optimized for parallel computation of thousands of matrix calculations per second, but its much less documented than traditional assembly and took developers years to figure out how to make the best use of the chip.Pre-written MicrocodeAlthough you can initially think of the RSP microcode as similar to a modern Shader language, as they are both used to implement a programmable graphics pipeline, this is not quite the case in practise. Most of the time the developers used the Nintendo written microcode and called it as if it was a normal Fixed function pipeline.Custom MicrocodeIt wasn’t common for developers to write their own microcode for their games until near the end of the N64 lifecycle. So most early games used pre-written microcode developed by SGI and Nintendo and used it like a fixed function graphical pipeline.In fact the main reason for the lack of custom microcode development by 3rd party games is due to the poor tools and documentation provided by nintendo. Not to mention the complexity of programming for it and no debugger was provided 1.The Microcode wizard - Yoshitaka YasumotoYoshitaka Yasumoto is credited in many games as being the microcode programmer (e.g Yoshi’s story) but most games use his microcode without explicitly giving credit as it was part of the Official N64 SDK.If you search a N64 rom file for his name “Yoshitaka Yasumoto” you will likely find the microcode that he has written. This works for most games unless they used their own custom uCode.Output of MicrocodeThe main output of the RSP microcode tends to be either graphical rasterization commands for the RDP or audio buffers for the DAC.Pre-written MicrocodesThe list of RSP Microcodes provided by the Official Nintendo64 SDK are as follows: gspFast3D - most full features, includes shading fog etc gspF3DNoN - same as Fast3D but without near-clipping gspLine2D - does not render triangles so it gives a wireframe effect gspSprite2D - efficient for 2D sprite images gspTurbo3D - faster than Fast3D but reduced precision.Variations of Fast3D (F3D)Fast3D is a very common microcode provided with the N64 SDK, it went through multiple iterations during the N64 lifecycle.It started with the standard Fast3D used in the game Super Mario 64.It then evolved into the Extended version known as Fast3DEX used in Mario Kart 64.Multiple versions were released of this microcode including Fast3DEX2 the second major version released and promised accelerated RSP processing speeds 4.Later other modifications of Fast3D emerged such as F3dZEX which stands for Fast 3D Zelda Extended used in Zelda 64 5.F3DLX - No Texture compressionF3DLX (Fast3DLimitedteXture) was an optimized version of the original Fast3D by removing texture compression support, this was deprecated after version 1 and was not carried over to F3DEX2 4.F3DLP - sub-pixel calculations ommitedF3DLP (Fast3DLimitedPixel) was an optimized version of the original Fast3D by removing subpixel calculation support, this was deprecated after version 1 and was not carried over to F3DEX2 4..REJ (e.g F3DLX.Rej)The microcode files that have .Rej in the name subsitute the clipping process for the lighter reject processing feature.For example this is more efficient for rendering characters as clipping is not required but would not be suitable for landscapes where clipping is required 6..NoN (e.g gspF3DEX.NoN.fifo.o)The microcode files that have .NoN in the name remove the Near Clip feature, which can be more efficient if you make sure to render your objects in the order from furthest away to closest as no clipping will take place 6.Presumably NoN stands for No Near-Clip but this is unconfirmed.Sending RSP result to RDP (.fifo, .dram etc)The result of the RSP graphical calculations need to be sent to the Reality Display Processor or RDP in order to rasterize the pixels for the game. There are multiple different ways to copy the result from RSP to RDP and each provide a slightly modified version of the RSP uCode to accomplish this..fifo (e.g gspFast3D.fifo.o)FIFO microcode uses a Queue (First in First Out) in RDRAM that is directly passed to the RDP..xbus (e.g gspF3DEX2.xbus.o)The XBUS is a physical connection that connects the RSP and RDP together on the chip. This allows passing data directly from the RSP to RDP without going through any additional steps such as using RDRAM..dram (e.g gspFast3D.dram.o)The DRAM method uses extensive use of RDRAM to store the RDP commands and requires work on the cpu to move the data to the RDP.RSPBOOTRSPBOOT is a short piece of code to initialise/boot the RSP, the assembled rspboot.o file contains in the Official Nintendo64 SDK is 740bytes but as that contains extra object data when compiled into the final rom it only takes about 208bytes (e.g Mario64).RSPBoot is included in pretty much all N64 games and is specified in the n64 development spec file normally after the codesegment.In an example spec file:include \"codesegment.o\"include \"$(ROOT)/usr/lib/PR/rspboot.o\"The rspboot ucode is loaded into IMEM at the beginning of each OSTask (e.g in osSpTaskLoad). The rspboot microcode is used to set a few initial register values, parse the Task header and then load the next microcode.CodeSegment.oCodeSegment.o file is generated s part of the build process for many of the demos, it can technically be called anything but most of the games call this codesegment.o. The file is a result of linking all the source files together so it is the output of the Linker (LD).Microcode/uCode limitationsInstructions must fit in the 4KB IMEM memory region so this limits the microcode to 1,000 instructions available in memory at once (due to each instruction being 4bytes and the total IMEM is 4kb) 7.To get around this limitation code overlays can be used and will be discussed further on, however it is important to note that the use of code overlays has a negative performance impact.Display ListsDisplay lists can be thought of as a set of commands that can be used by the programmer to manipulate the RSP’s currently running microcode 8. Basically we want the CPU to setup a list of commands that the RSP will use to calculate the next frame, which the RSP will run in parallel while the CPU is computing game logic.So you can think of a display list as an array of 64-bit words (8 bytes) where each element of the array is a command that the RSP will use to render the frame.Graphical Binary Interface (GBI)The graphics programmer controls the RSP from main game code using the GBI.So Display lists are created based on the commands listed in the GBI and are sent to the RSP to be interpreted by the loaded RSP Microcode.So you could summarize that the purpose of the graphics RSP microcode is to implement the functionality required by the GBI.References N64 RDP/RSP ↩ ↩2 NEXT Generation Issue #14 February 1996 ↩ N64 ASM - Day 8 ↩ https://level42.ca/projects/ultra64/Documentation/man/pro-man/pro25/index25.4.html ↩ ↩2 ↩3 https://hylianmodding.com/Thread-A-comprehensive-guide-to-F3DZEX-F3DEX2-Display-Lists ↩ https://level42.ca/projects/ultra64/Documentation/man/n64man/ucode/gspF3DLP.Rej.html ↩ ↩2 https://www.docdroid.net/NXMlF3s/grucode.pdf#page=3 ↩ https://en.wikibooks.org/wiki/N64_Programming/Video_coprocessor ↩ ", "excerpt": "Introduction Unlike most PC hardware at the time the Nintendo 64 has the advantage of having its own stand alone graphics processor known as the Reality Co-Processor (RCP). This freed up the main CPU from having to do any graphics calculations and it could use all its processing power for...", "tags": ["n64"], "image": "/public/N64/N64RealitySignalProcessor.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "N64 Reversing Introduction", "url": "/N64Reversing", "content": "This post will give a brief introduction for the tools and techniques you need to start reverse engineering and decompiling a N64 Game.Part 1 - Looking for Initial CluesFind filenames in romOne way to get a hint of the programming languages that a rom was written in (normally either c or c++) is to look for any left over references to the filenames in the rom.One really nice website that lists this information is:http://shygoo.net/n64-uncompiled/n64-filenames.txtFind left over source code in the romVery occasionally you can be lucky and see a snippet or two of the original source code left in the rom, you can view a list of these here:http://en64.shoutwiki.com/wiki/N64_C_RepoPart 2 - Splitting up the ROMIntroduction to N64SplitN64 Split is a tool initially developed for Super Mario 64 for extracting files out of the n64 rom but it is now general enough to be used for any N64 game.This is the tool we will be using to start reversing the game of your choice.You can download N64 Split here: queueRAM/sm64tools: Collection of tools for Super Mario 64 ROM hackingFind existing N64Split configsIf someone has already started reversing a game you may be lucky and they could have generated a config file that we can use in N64Split:https://github.com/queueRAM/sm64tools/tree/master/configsCreating a new N64Split configIf the game you want to reverse engineer does not yet have a split file config then we can create one using the following template:# ROM splitter configuration filename: \"Your Game Name (Region)\"# checksums from ROM header offsets 0x10 and 0x14# used for auto configuration detectionchecksum1: 0xA03CF036checksum2: 0xBCC1C5D2# base filename used for outputs - [please, no spaces)basename: \"yourGameName.region\"# ranges to split the ROM into# types:# asm - MIPS assembly block. Symbol names are in 'labels' list below# behavior - behavior script# bin - raw binary, usually data# header - ROM header block# instrset - instrument set# level - level commands# m64 - M64 music sequence bank# mio0 - MIO0 compressed data block. may have texture breakdown# ptr - RAM address or ROM offset pointer## textures types:# rgba - 16-bit RGBA - [5-5-5-1)# ia - 16/8/4/1-bit greyscale# skybox - grid of 32x32 16-bit RGBAranges: # start, end, type, label - [0x000000, 0x000040, \"header\", \"header\"] - [0x000040, 0x001000, \"bin\", \"boot\"] - [0x001000, 0x0B6A40, \"asm\", \"main\", 0x80241800]# Labels for functions or data memory addresses# All label addresses are RAM addresses# Order does not matterlabels: - [0x80241800, \"EntryPoint\"]Save this with a filename in the form: gameName.region.yaml in the config folder next to n64split executable.Set checksum valuesYou will notice in the above template that there are 2 checksum addresses:checksum1: 0xA03CF036checksum2: 0xBCC1C5D2These are currently set to the checksum for Mario64 which will be no good for any other game, so lets get some proper values for this!You will need to change the checksum1 and checksum2 values to the values of your specific rom.You can find the values by opening the Z64 ROM in a hex editor and going to address 0x10 and copying the hex value at that location. The same for checksum2 at 0x14 in the ROM.Set Entry point valuesIn two sections of the above template we have reference to the hex address 0x80241800.One is in the labels section:labels: - [0x80241800, \"EntryPoint\"]The other is in the main range section: - [0x001000, 0x0B6A40, \"asm\", \"main\", 0x80241800]This is called the Entry Point of a game and it is start point for the game code in RAM, the value above is for the Super Mario ROM.So we need to replace this value with the start address of the game you are wanting to reverse.Again open your ROM in a hex editor and go to address: 0x08 and use the 4 bytes at that address to set the entry point for you rom.Set end of assemblyThis is much trickier, so while we know that the assembly code starts at 0x001000 we don’t know where it finishes. This will require some disassembling and detective work which is what we will do in the next section so for now keep it at 0x0B6A40 which is where the initial Mario code ends. We will find the proper value for this later on.Run N64SplitIf you have put your new config file inside the config folder beside the n64split executable then you should be able to run this:./n64split GameName.z64It detects the correct config file using the checksum settings we defined earlier.If however you would rather keep the config file in a different directory you can directly specify it like so:./n64split -c gameName.region.yaml GameName.z64If all goes well the output should be similar to:root@69b99468cc18:/sm64tools# ./n64split GameName.z64Using config file: configs/gameName.region.yamlSplitting into \"gameName.region.split\" directoryROM split statistics:Total decoded section size: B5A80/800000 (8.87%)This will create a gameName.region.split directory, where gameName and region are replaced with your specific rom settings. Don’t worry about that low percentage of decoded section we still have a few more ticks which can help increase the percentage decoded quickly.N64Split OutputLets briefly look at the output of our initial run of n64split, if you open the directory it created it contains a number of different files listed below: Name Description Makefile   Makefile.split   bin This is where the binary blobs get extracted to, initially you will have yourGameName.region.000040.boot.bin which contains the boot code common in all roms geo geometry will be extracted here (currently none) geo_commands.inc   globals.inc This is where all the labels you defined will be placed allowing compilers/assemblers to refer to them levels Game Levels will be placed here when we tell n64split how to decode the levels macros.inc   models 3D Model data will be placed in this folder textures Game textures will be placed here when we tell n64split where in the rom the textures are yourGameName.region.ld   yourGameName.region.s   The MakeFileThe MakeFile generated by n64 split is a great start but you will notice running make doesn’t actually manage to rebuild the rom as certain settings will need to be changed first.While changing these there is also a number of other modifications to do to the makeFile so I tend to just replace the entire makefile with one based on the Sm64 project. This allows us to set it up to compile with the IDO compiler initially and we can easily change to a n64 version of gcc when we find out which compiler is used for this ROM.Here is the new MakeFile:TODO: Get the contents of the fileNotice you can now run make and it will try to create the ROM from the split sections, cool!Note that currently it will fail with lots of errors when you run make but this is actually good as we will cover this in the next section as it is giving us hints as to where the assembly code stops and the data section begins!This will form the basis of your reversing project, soon it will be filled with .c files, 3d models and other data and will all be able to be rebuilt back into the original rom using make!However the current content of the folder is not very useful at the moment as we haven’t actually split the rom into any proper areas yet but that is what we will do in the Next section.So now at the end of this section you will have a folder with files that will eventually become the reversed source code of the game, we just need to tell n64split where the code, models, levels and other assets are in the game. To do that we will need to do some digging to understand the internals of your chosen game rom.Part 3 - Code AnalysisUse the makeYou will notice that running make will produce tons of assembler errors, well there is a good reason for this, remember when we talked about finding the end of the assembly section and we just kept the value from Mario64?Well that is whats throwing these errors, it is trying to assemble bytes that are not valid instructions and there for are data.Ok so lets see what the first error that its throwing as that will give as a hint to say that address is definitely past the end of the assembly section, lets pipe the output of make to a file called output.txt:make &>output.txtSo if we open this output.txt file and look at the top we get:yourGameName.region.s: Assembler messages:yourGameName.region.s:1111: Error: opcode not supported on this processor: vr4300 (mips3) `movn $zero,$zero,$zero'Now open yourGameName.region.s and go to line number it says the first error is at (in the example above its 1111).A quick way to do this on linux with nano install is to run:nano +1111 yourGameName.region.sYou will notice a line similar to/* 001F00 80242700 0B */ movn $zero, $zero, $zeroThe instructions and addresses will most likely be completely different but what we are interested in is the first part of the comment 001F00 this is the offset where we got an invalid instruction so we know this is not supposed to be asm.Splitting up the assembly code into smaller filesHaving one giant .s assembly file is not very manageable and I can (almost) guarantee it wasn’t that way when originally developing the rom. So lets try to split up the file into smaller chunks by looking for hints of file boundaries inside the assembly.These can often be a certain number of nops between 2 functions symbolising that each function is in a different file or we can use the rodata for clues as to the file boundary information.TODOThe tricky part is coming up with names for each of these files based on the functions they contain. Initially I create dummy file names and then rename them later when we can figure out what functions the file contains and name the file something more appropriate like saveGame.c or drawLevel.c.Find Ultra64 SDK Library SymbolsYou can use this tool: https://github.com/shygoo/n64symn64sym paper_mario.bin -l libs/libgultra_rom.aPart 4 - Decompilation to C codeLinker ReinsertionSo now that you have all the assembly code in separate .s files we can start decompilation!The technique we will use is called Linker reinsertion and it requires that your Linker supports scripts (*.ld files), we will be using the gcc mips ld for this task.The idea of Linker reinstertion is to slowly replace the assembly files with an equivalent C file, function by function, maing sure that the resulting assembly generated by the C code is identical to the original assembly.So pick an interesting looking .s file to start with and create a .c file with the same name but in the source directory.Lets say your assembly file was called target.s and located in the asm directory, then just create a target.c file in the src directory.For example:src/target.casm/target.sNow pick one function from target.s file and create it in target.c, constantly monitor the assembly output as we want it to match exactly to the original.Part 5 -MiscEmbedded Javascript engine in Project64Youtube: https://www.youtube.com/watch?v=PC0Tlz6oiN0Use the official tools to display textures, sounds and NIF modelsyoutube - https://www.youtube.com/watch?v=yUX1Vga6amgIDA ProWhen loading Turok .z64 into IDA pro an error window pops up with:The boot code is not loaded into the database, use manual load to load it", "excerpt": "This post will give a brief introduction for the tools and techniques you need to start reverse engineering and decompiling a N64 Game. Part 1 - Looking for Initial Clues Find filenames in rom One way to get a hint of the programming languages that a rom was written in...", "tags": ["n64","introduction"], "image": "/public/N64/N64 Introduction.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Official Nintendo 64 SDK", "url": "/n64-sdk", "content": "This post covers the Official Nintendo 64 Software Development kit that was sent to developers is actually split among a number of different discs due to its size.These Discs include: N64Kit - Applications used for N64 development N64 OS - The SDK files (includes, libraries etc) Nintendo 64 Sound Tools - Tools for Musicians DocumentationN64Kit CD (N64 Developers Toolkit)The N64 Developers toolkit contained all the following applications used for N64 Development: ccbl - Color Combiner and Blender N64 code DPTEST - PC application to communicate with ccbl DDTools HVQ/HVQM - Image and Video compression Monegi Multi Viewer64 NIFF NuSYSTEM N64 Disk Drive Multi File System (MFS)The CD contains a PC and SGI folder, with the SGI folder simply containing a tar archive of all the contents.On Windows a Setup.exe file was included that is installed into C:\\nintendo\\n64kit and contained pre-compiled executables for all of the main applications.Known Versions of N64KitLatest Version: 5.2Released Versions: 3.0, 4.0, 4.1, 5.0, 5.1, 5.2 Download N64Kit from ultra64.ca N64kit was distributed to developers in the form of CDs, Ultra64.ca has full CD ISOs of versions 3.0->5.2. Version 5.1 (10th Feb 2000) of the kit was partially released in the BroadOn archive leak of May 2020 due to its use in the iQue player development.ccbl - ColorCombiner and Blender DemoThis is an application that runs on the Nintendo 64 hardware to teach programmers about the RDP features. It has the ability to communicate with a Windows Application called dptest for which the source code is also available.dptest - Display Processor Test toolWindows application that communicates with the N64 application ccbl to save and load configurations.It works with a number of different N64 development flash cartridges such as: MSP-A/MSP-B/MSP-C Partner-N64 IS-Viewer64 dptest Files in the dptest folder. ⚙️ dptest.exe Main application for communicating from PC to N64 📄 TargetN64.dll DLL for communication between flash cartridge and the PC 📄 KMCCtrl.dll DLL for communication through the KMC Partner N64 flash cartridge 📄 dptest.n64 Compiled N64 ROM of CCBL that communicated with dptest HVQ - Image & Video compression HVQ The Hybrid Vector Quantization (HVQ) algorithm is an effective form of image compression for low bit rate images and can out perform JPEG by between 10 and 20%. This allowed developers to compress their textures down and allow much more data to be stored on the limited cartridge space provided by the Nintendo 64. Also since videos are just a collection of images there is a variant of the algorithm called HVQM that compress video content. This folder contains code for both the image and video compression tools. If a game used the HVQ algorithm they were required to show a logo which was contained in the HVQlogo folder. The source code suggests that the algorithm may have been written by Hudson. hvq2encThis folder contains a pre-built Windows executable called hvq2enc.exe for compressing BMP or PPM images into HVQ encoded images.There is also a version of this tool for video content called hvqm2enc.exewhich supports converting uncompressed AVI files to compressed HVQM2 files.libhvq2libHVQ2 is the main static library used to decompress static images (for movies see libhvqm2) on the Nintendo 64. The source code for the library itself is not provided in the SDK, but the header files and the static library files (including RSP microcode) are included along with some pretty decent documentation.There are two methods of decompressing the data, one is purley CPU using just functions in the static library.The other uses the CPU to decode half of the data then passes it over to the RSP microcode to do the rest, saving CPU time. Filename Description GUIDE.txt Tutorial for using both the CPU and RSP versions rspcode/hvq2sp2.o RSP Microcode to decompress the intermediate image to 32-bit image data rspcode/hvq2sp1.o RSP Microcode to decompress the intermediate image to 16-bit image data FUNCTIONS.txt Documentation for each function in the lbirary lib/HVQ2File.h Contains the HVQ2Header structure for parsing the data header lib/libhvq2.a The main static library that must be linked to use HVQ functionality lib/HVQmd.h N64 version of the Machine Dependent (MD) definitions. lib/hvq2dec.h Header file for all the functions and main structures in the library README.txt Overview of the folder contents nuHvq - Nintendo Ultra HVQNuHVQ is a Nintendo 64 sample project provided by Monegi Corporation to demonstrate loading HVQ compressed images on the N64 via the NuSystem API.This is a higher level version of the code presented in the sample folder, which essentially does the same thing but without NuSystem.This example seems to have been forked from the nu4 sample code as it includes the same music and code.sample - Sample code for N64This folder contains the bare-bones implementation of a N64 image viewer for images compressed with HVQ. This does not use the NuSystem API so it is lower level than the nuHvq sample but provides similar functionality. Filename Description hvqwork.c Variable setup for memory used by HVQ2 RSP microcode sample.hvq Sample Image compressed with HVQ Makefile Standard Makefile for building sample system.c Implements the standard boilerplate code such as mainproc spec Standard ROM spec file but notably includes the “sample.hvq” image as a segment cfb.c Just contains the CFBPix Frame Buffer main.c Contains the sample specific logic to load the HVQ image README.txt Brief overview of how to use the sample system.h Header file for all the definitions from main.c hvqbuf.c Simply defines the HVQ buffer where the image is read into N64 Operating SystemThe N64 OS was initially released with both SGI and PC versions on the same disc, later it was moved to a disc for each operating system.On Windows it was installed into C:\\Ultra\\usr and used a UNIX-like directory structure containing the following folders: include - C Source code Header files lib - compiled static libraries for N64 sbin - a few custom command line tools src - Source code for Demo applications and the libultra and libnaudio librariesKnown VersionsLatest Version: 2.0LReleased Versions: 2.0J, 2.0K, 2.0H, 2.0L", "excerpt": "This post covers the Official Nintendo 64 Software Development kit that was sent to developers is actually split among a number of different discs due to its size. These Discs include: N64Kit - Applications used for N64 development N64 OS - The SDK files (includes, libraries etc) Nintendo 64 Sound...", "tags": ["n64","sdk"], "image": "/public/N64/N64 SDK.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "N64 Sound and Music", "url": "/n64sound", "content": "Decoding Audio on the RSPThe Reality Signal Processor or RSP is not only used for the games graphics, it is also used for the games audio and so the developers need to have a balance between time spent for graphics processing and time spend for audio processing on the RSP.The RSP is where all the low-level audio processing is done, decoding the audio sample data and passing it on to be played through TV speakers.N64 Sound BanksN64 sound banks are composed of two files: the ctl and tbl.The N64 Developer Documentation refers to a Wave bank file .wbk and a Pointer Bank File .ptr but it is not clear what this file is compared to .ctl and .tbl 1. My guess is that CTL is the same as .ptr and .TBL is the same as wok but this is unconfirmed.CTL FileThe ctl is the sets of sounds and details about them., it starts with the Magic Header: 0x42310001.TBL FileThe tbl is the actual raw sound data, usually vadpcm encoded.Finding the TBL from CTLThe tool attempts to locate ctl via its magic word (0x42310001), then tries to guess the .tbl. In many games however, the tbl is not directly past the .ctl, since it is hardcoded in the ROM, and thus many ROMs, while they may have soundbanks, will not work exactly out of the box. In that case, search for the magic word in a hex editor, 0x42310001, then the .tbl is usually following it, and is a series of random hex characters that followed some 00 padding. 2Official Sound ToolsThe official N64 Development Sound tools were released by Nintendo for use by Musicians to create and test sounds for N64 hardware.The Sound Tools has two applications bundled, one is the N64 Waveform Editor (dse.exe) and the other is the N64 Sequencer (dream.exe)N64 Sound LibrariesThere are 2 known officials sound libraries for N64 development, the Sound Tools API Library and the N_Audio Driver for Sound Tools.The N_Audio Driver is the new version of the older SGI Sound Tools API and is more optimised for playing sounds. Most later games used this API.Sound Player (Sound effects)At the start of the game the Sound Player is initialised and assigned a bank of sound effects.The Sound Player requires a section of RAM to be reserved for it to move sound sample data from ROM into RAM.Sound effects are often edited with the N64 Waveform Editor also known as dse.exe.Sound Effects format (Wave) (.tbl)Sound effects are made up of a couple of files, one is an ADPCM .AIFF file which stores the raw wave data and the other is a metadata file for playback settings.Sound effect samples are stored in the ROM with a bunch of parameters required for playing the audio such as: Pitch Envelopes Key MappingThe parameter data is stored in a .bnk file and is paired with a single compressed sound effect data .tbl file.The compressed Sound effect data is stored in .tbl files during development before it gets merged into the ROM.Sound effects Development ProcessThe Musician would initially have created the sound sample as AIFF files which are then compressed into AIFC files.An .inst file is created with the playback parameters in it, then this file is merged with the AIFC files to generate a single .tbl file.Whats the difference between .inst and .bnk?Example .tbl fileA .tbl file is plain text:24 979 474 697 564 606 563 562 541 991 1458 1179 1268 1177 1175 1131 1109 -1567 -2597 -3104 -3156 -2854 -2314 -1650 -963 3394 4056 4124 3729 3023 2156 1259 436 -113 -117 -115 -113 -111 -109 -107 -104 2123 2088 2048 2008 1969 1931 1893 1856 -1735 -3186 -4381 -5346 -6106 -6683 -7100 -7376 3761 5171 6310 7207 7888 8380 8706 8888 Example .inst fileenvelope env1{ attackTime\t\t= 5000; attackVolume\t= 127; decayTime\t\t= 364920; decayVolume\t\t= 127; releaseTime\t\t= 5000; releaseVolume\t= 0;}sound sound1{ use (“SoundFileName”); pan = 64; volume = 127; envelope = env1;}instrument inst1{ volume = 127; pan = 64; sound = sound1;}bank Wave1{ instrument [0] = inst1;}Sound Sequencer (Music)At the start of the game the Sound Sequencer is initialised and assigned a bank of instruments and a bank of MIDI sequences.Sequence (Music) format (.seq)Sequences are saved as .seq file in MIDI format but can also be a compressed version of MIDI that gets decompressed at runtime.The seq format is slightly more optimised than standard MIDI as it has all the unneeded events removed 3.Sequences are edited using the N64 Sequencer tool also known as dream.exe.Sequence Bank format (.sbk)The Sequence Bank format is just a bunch of .seq files added together.Music Development ProcessTo generate a .sbk file the Musician would compile the MIDI first into .seq files and then merge multiple .seq into a single .sbk file.References https://n64squid.com/homebrew/ProgManual/chapter_libuse.html ↩ https://www.therwp.com/project/n64-sound-tool ↩ https://level42.ca/projects/ultra64/Documentation/man/pro-man/pro20/index20.1.html ↩ ", "excerpt": "Decoding Audio on the RSP The Reality Signal Processor or RSP is not only used for the games graphics, it is also used for the games audio and so the developers need to have a balance between time spent for graphics processing and time spend for audio processing on the...", "tags": ["n64"], "image": "/public/N64/N64SoundMusic.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "N64 3D Modelling Software", "url": "/n64-3d-modelling", "content": "During the Nintendo 64s lifetime 3D modelling tools evolved at an incredible pace. 3D games were the new trend which pushed developers into creating new 3D games in order to get published.For Nintendo 64 3D Model development the official standards were NinGen (based on MultiGen) or Alias but it was also common to use SoftImage, Nichimen Graphics or Autodesk’s 3DStudio.3D Modelling3D Modelling software was relatively new when development for Nintendo 64 game started, but during the lifetime many new products flooded the market and by the end artists were spoiled for choice.Ningen/Multigen/GameGen Ningen was a custom version of the realtime 3D modelling software called MultiGen created by the company Multigen Inc and tailored specifically for video game platforms, especially Nintendo 64. The company Multigen were well known for creating very good 3D modelling tools for a variety of purposes, such as flight simulators and games. They were developed to run on SGI’s IRIX Operating system and so would be limited to developers who can afford the cost of the SGI workstations. Although a later version was released for Windows NT based systems, the price of the software itself at 9 thousand dollars was still rather costly. The product known as Ningen was later renamed to Gamegen and supported other consoles such as a PlayStation 1 as well as the N64 1. Unlike its competitors such as Softimage and 3D Studio Max, Multigen did not offer any animation functionality as it was presumed that it would be handeled manually in the game engine 2. The official Nintendo 64 SDK came with documentation that covered the use of Ningen files (*.flt) and a few tools to convert the FLT format into C-code that could be used in a game. Notable Games with assets created in Multigen: San Francisco Rush (N64, PS1) 2 HUGE NEWS: ModelGen (the basis for NinGen) on #SGI Irix is now unlocked + working!Similar to the interface used by @RareLtd for #Nintendo64 #3DmodellingThanks @Windoze999 for cracking flexlm, @SiliconClassics for ModelGen itself, @GoldenEraDoco and @drdoak for motivation... pic.twitter.com/NmxHFoi9Sf— Shane Battye🎄 🎮 (@shanebattye) September 27, 2020Alias/Power Animator/WavefrontAlias Power Animator was an excellent 3D modelling and animation package developed for SGI workstations. It came at a very high price point of £60,000 but came with plugins especially for Nintendo 64 development but they were not officially supported by Nintendo 3.The software later changed its name to Alias | Wavefront after buying out the rival company called Wavefront.This package eventually got turned in to Maya and was bought by Autodesk, it is still used in the games industry today but not as widely as competitors such as 3DS Max 3.Power Animator was used to develop games such as DMA Design’s Silicon Valley for the Nintendo 64 4.The Video below showed Batman & Robin 3D Character Models running on a SGI Indy from Probe Software but it has since been deleted:Hopefully someone can re-upload this video as it was a good demo for how Alias Wavefront looked on the SGI Indy!SoftimageAt a cost of £20,000 per license Softimage was a rather expensive product for game development studios to purchase. However its advanced features and excellent support for SGI Workstations made it popular with companies like Nintendo 5.Softimage was used in classic Nintendo 64 games such as Super Mario 64, Resident Evil 2 and Wave Race 64 6. As these started development before Softimage was available for PCs then they were using a version of Softimage such as Softimage Creative Environment 2.6 which would only run on SGI workstations.The video above was created by David Gallagher and uses Softimage 3D V3.5-3.7 so this would have been available during the development of many Nintendo 64 games as version 3.5 was available from May 1996.Kinetix/AutoDesk 3D Studio/3DS MAX3D Studio 4 was released in 1994 and only ran on the 16-bit MS-DOS operating system. It wasn’t until 1996 that 3D Studio MAX 1.0 was released with support for Windows NT.The main advantage of 3D Studio was its cheaper price point (£3,000) than competitors such as Alias, Multigen and Softimage 3.The official Nintendo 64 Developer Documentation refers to the 3DS plugins that Nintendo distributes as part of the official SDK. These plugins allowed 3D Studio to output to the Nintendo 64 format known as NIFF 7.3D Studio Max R2 was used to create all the vehicles and tracks for the N64 game Top Gear Overdrive 8.GAMUT-64Intelligent Systems added support for 3D Studio MAX R2 and above to their IS-VIEWER64 development cartridge. This provided a bunch of plugins for 3D Studio Max to convert to the Nintendo 64 NIFF and AGT file formats along with the ability to preview 3D models directly from 3DS Max on the n64 hardware 9.Nichimen Graphics N-WorldOne of the most unique things about N-World is that it was written in the programming language Lisp, which is still a very rare occurrence to find commercial software written in a form of Lisp.One of the benefits of N-World was a feature called Instant Gratification which showed a 3D model in real time on the Nintendo 64 hardware 3.N-World was used for classic Nintendo 64 games such as Super Mario 64 and Banjo Kazooie 10.Unconfirmed Other 3D Modelling SoftwareIt is possible that Lightwave 3D was used for the creation of assets for some Nintendo 64 games as it was available during its lifetime, and Nintendo even sealed a plugin for Lightwave that exported to their NIFF format 7, but no commercial games have been confirmed that used Lightwave.Other 3D Related toolsNIFF Editor NIFF Editor was part of the package known as NIFF Navigator and the first version was released on the 9th of October 1997 and the last release on May 6th 1999 11. Okay found a scene viewer program, which builds a preview executable for running on hardware. This seems to have a more complete makefile so I'll use that one as a base and try building the samples again pic.twitter.com/eaPYR95WUP— Matt Phillips (@bigevilboss) 8 January 2020Texture CreationDeluxe Paint (Dpaint) was the most popular tool for making textures, along with PaintShopPro and PhotoShop. So any editor which supported saving the SGI’s RGB format was supported and their were tools to convert other formats to RGB.In order to use the textures in a Nintendo 64 game, the official SDK came with the command line tool called rgb2c which converted a SGI RGB image file into compilable C Code!If the texture was referenced in a 3D model format such as Ningen (*.flt) then it would be automatically converted to C-code when the model was converted.References FAQ: Chris Lee – MCV/Develop ↩ GDM January 1999 ↩ ↩2 N64 3D modeling software options ↩ ↩2 ↩3 ↩4 Gamasutra: John Szczepaniak’s Blog - Unusual Evolution – Developing Space Station Silicon Valley ↩ What programs did people use to make models for the N64 and PS1? - General Forums / Blender and CG Discussions - Blender Artists Community ↩ Softimage Used by Game Developers to Create Award-Winning Games ↩ RESOURCES ↩ ↩2 GAME DEVELOPER Magazine - DECEMBER 1998 ↩ IS-VIEWER64 ↩ ACCL Message Board - Msg: 1910481 ↩ NIFF 2.0 Graphic Environment ↩ ", "excerpt": "During the Nintendo 64s lifetime 3D modelling tools evolved at an incredible pace. 3D games were the new trend which pushed developers into creating new 3D games in order to get published. For Nintendo 64 3D Model development the official standards were NinGen (based on MultiGen) or Alias but it...", "tags": ["n64","3d","tools"], "image": "/public/N64/Nintendo64_NinGen_MultiGen_ge007_stpetersburg.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "NES Sprite Tile Editing", "url": "/nes-sprite-tile-editing", "content": "Sprite Tile editing with Tile Layer ProIf you have ever wondered how graphical rom hacks are made this is for you! This should work for most early games such as NES and Game Boy. Future generation games start to compress their sprites which makes it more difficult.Back in the day of NES and Game Boy development, the sprites and tiles were saved in the rom file completely uncompressed and thus visible with the correct editor, one such editor is Tile Layer Pro.Tile Layer Pro: ROM Graphics EditorTile Layer Pro is a fundamental and widely-used utility in the field of ROM hacking and graphical reverse engineering. The application allows users to view, edit, and manipulate the raw tile data (8x8 or 16x16 pixel blocks) that constitute the sprites, background images, and foreground elements within classic video game ROM files. This tool is essential for understanding how tilemaps are laid out in memory, enabling hackers to customize graphics across numerous tile-based consoles. Tile Layer Pro Sega Retro has an entry for Tile Layer Pro, a classic ROM hacking utility used for viewing and editing the tile-based graphics data in video game ROMs. How to Hack NES Games: Editing GraphicsJohn Riggs presents a tutorial on modifying NES game graphics using Tile Layer Pro. The video demonstrates how to locate 8x8 tile patterns within a ROM (using Super Mario Bros. as an example), use the “Tile Arranger” to visualize sprites, and edit them pixel-by-pixel or by importing graphics from other games to create custom characters.One cool feature of Tile Layer Pro is being able to open multiple games at once and copy tiles over, so in the video they copy a ghost from Pacman and replace the Mario Goomba with it!", "excerpt": "Sprite Tile editing with Tile Layer Pro If you have ever wondered how graphical rom hacks are made this is for you! This should work for most early games such as NES and Game Boy. Future generation games start to compress their sprites which makes it more difficult. Back in...", "tags": ["nes","gameboy","introduction"], "image": "/public/QkyxcBhunP1JpTNuoeDIMw_img_0.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "NES (Famicom) Development Kit Hardware", "url": "/famicom-nes-development-kit", "content": "IntroductionThe Nintendo Famicom was released in Japan on 15th July, 1983 at a price of 14,800 yen. Development for the machine was strictly controlled by Nintendo as they didn’t want a repeat of the US “Video Game Crash” which they blamed on the lack of quality games. As such most of the games initially released for the platform were made by Nintendo itself, presumably on prototype NES hardware.Since Nintendo were very new to the video game market and saw themselves as creating most of the software that will run on the NES they did not make a specific development kit, or if they did it was very well hidden in the official Nintendo headquarters and no public information has been released on it.What about 3rd parties?It wasn’t until the first 3rd party game was in development that the need for a Development Kit for the NES was established. It took a full year after the Famicom’s launch for the first 3rd party title to appear.Nintendo Licensee programIn 1986 Nintendo would open up its licensee program to allow other developers to create software for the Famicom 1. It was then on the lookout for talented programmers to make use of the 6502 chip which was relatively uncommon at the time of its launch (although had been used in the Commodore 64).Presumably many developers would write code for the C64 taking into account the memory model of the NES and test their code via burning an EEPROM cartridge.It is likely that developers who managed to get an official license from Nintendo were given some basic documentation about the hardware such as the memory map, PPU and APU. It would then be up to the developer to create their own development environment 2.Official Nintendo in-house development kitNintendo has been very secretive about how their official NES games were developed but there is some information coming from a Japanese children’s book of all places and kindly translated by Chris Covell on his website.Programming Hardware When the NES was first released it was not common in Japan for PCs to be running with a 6502 processor 3, so how did developers write and test code for the famicom? Did they have to burn a EPROM everytime they assembled their code to test even the smallest change?! Well yes in fact that was the case, the code for the early NES games was written using a NEC PC-8001 3 which has a Z80 processor, so none of the 6502 assembly code could be run without connecting to a NES system. In the photograph from a children’s book titled Stars of the Famicom Games (Kindly scanned and translated by Chris Covell) you can see 4 programmers presumably working on Super Mario Bros 3 4. They are using HP 64000 mainframe computers which have presumably been modified to have a Famicom add-on board or 6502 processor card to be able to test their assembled code. Testing & prototype Hardware So how did Nintendo test the games they were writing on the hardware? The EEPROM writers scattered around the offices in the children’s book hint at how this was done. An EEPROM writer writes to an erasable version of the games “ROM” chip which can be slotted in a development cartridge which can be placed in a retail Famicom unit for testing. In the photograph on the left you can see a custom EEPROM cartridge inside the retail Famicom on Miyamoto’s desk, so he would run through the game and give feedback or bug reports to the programmers and artists for the next build of the game. In the American TV staion PBS there was a 9 minute segment broadcast on December 30th, 1988 from MacNeil/Lehrer “NewsHour” 5 which gave a very brief look inside the Nintendo Research and Development office and shows an EEPROM chip being written to on a system called the PROS-80 by IWASAKI:Since the image is a bit blurry here is an image of a slightly different unit (PROS-80F):This chip is then transferred over to a custom NES cartridge by Masahiro Ishizuka and an unknown developer:Graphic Artist hardware From the same children’s book we can see Mr. Tezuka hard at work on Super Mario Bros 3, it looks like he is viewing the Character (Sprite/Pixel) data for the Mario sprite sheet. It is unclear if it is connected to the version running on the Famicom to the right of the computer. It would be pretty useful if changes made on the PC automatically updated the sprites in the running game, but it is unlikely they had built the hardware to support such a feature. Presumably this is some sort of pixel editing tool that can piece together parts from the sprite sheet and update and possibly even animate the result to the viewer. It is unclear what the colours at the top represent, it could be the available colour pallet. The Fujitsu FM R-50 HD business computer was used to create all the pixel art for Super Mario Bros 3. It was an IBM-PC compatible which ran a version of MS-DOS. Famicom Disk System Development hardwareThe Famicom Disk System (FDS) was just a cheaper way of distributing games for the Famicom in Japan due to the higher cost of producing cartridges.It was released in Japan only on the 21st of February 1986, 3 years later than the Famicom but the same year as the European NES release.It seems to have been commonly been used for development of NES games even if they ended up on cartridges for western audiences.FDT ICE (ISD) This is a very rare item, it is possibly only used within Intelligent Systems (IS) themselves, although IS did mass produce a similar product for the SNES so it is possible that this was THE official development kit for the NES. ICE stands for In-Circuit Emulator and Intelligent Systems made these for most of Nintendo’s hardware in the future too. These would be used by connecting to a development PC and allowing breakpoints and memory checking to be run from a debugger-like interface. As for the acronyms used in the name: ISD may stand for Intelligent Systems Debugger or Development. FDT may stand for Famicom Disk T(?) Famicom Disk System Prototypes Retail FDS games were either yellow or Blue so a White FDS disk is used for in-development prototype games and may be re-writable. It is unclear whether they could be written to via a standard PC floppy drive however. Consumer Development KitsIt is very rare for Nintendo to allow non-licensed developers to write code or “homebrew” on their consoles. However when they developed the Famicom (Family Computer) they wanted to expand the computer aspect and not just rely on games so they had a few initiatives to allow PC like functionality on the console.Family BASIC for Famicom The first ever Nintendo development kit that general consumers could buy was Family Basic, which was as the name suggests an implementation of the BASIC programming language that you could write and execute on the Famicom 6. As for Commercial games, the legendary developer of Pokemon, Satoshi Tajiri from Game Freaks used Family BASIC to create his first game, which he then built his own NES development kit on top of and created the game called Mendel Palace 7. In-house development kitsDue to the lack of official NES development kits, many companies had to reverse engineer the system themselves in order to do any game development for the system.NES Mission control dev kit The Mission Control NES development kit was created by Rocket Science Productions to help smaller developers get into the market of creating games for Nintendos new console 8. It consists of a breadboard filled with chips and screwed to a plank of wood and a modified retail NES console 9. Games built using this development system include but is not limited to: Bill & Ted’s Excellent Adventure The Mutant Virus 9 HAL “Game Maker” (Twin Famicom) HAL Laboratory, Inc. who are best known for creating the Kirby and Mother series of games were very early NES developers. Like many other developers they did not have an official development kits available so took a rather unique approach to developing games on the system. They used the retail Twin Famicom System with an added trackball mouse along with a tool they created that had a virtual keyboard 10. Development data was written and read from the floppy disc and they created some software that ran on the cartridge port that allowed them to edit code or sprite data. This was during the development of their game Metal Slader Glory11. This system was also used in the development of HALs most famous creation Kirby’s Adventure12. Software Creations Development Kit (Mike Webb)Software Creations Ltd has a problem on their hands, they wanted to develop games for Nintendo’s new home console but Nintendo only allowed companies who were already developing NES games to become licensed.This Catch-22 situation resulted in Mike Webb reverse engineering the NES hardware and creating his own development kit. According to an interview in Retro Gamer Magazine issue 37 it was quite an elaborate creation consisting of a stack of RAM chips that could be written on a Commodore 64 and then read via the cartridge port of a retail NES 13.You can see Mike Webb talking about the making of Solstice for NES, a game he not only programmed but also created the hardware development kit for, in the video below.BEAM’s NES Development SystemBEAM was a very small company in the 80s mostly creating titles for the ZX Spectrum from their office in Melbourne, Australia. When the Famicom (NES) was released in Japan to critical acclaim they knew hat their next development platform would be. However they also knew that Nintendo would never give development kits to such a small company 14.They spent the year reverse engineering the Famicom hardware and in 1987 they completed their NES Development System. These caused quite a stir especially in the local Australian development community, so much so that BEAM started selling the kits to other development companies 14.The news of the sale of these 3rd party development kits did not please Nintendo and after a lengthy negotiation process BEAM agreed to stop selling its development kit in order to gain an official development license from Nintendo 14.Westwood Studios A rather intriguing looking item was put up for auction on Ebay in 2011 claiming it was a NES development kit used by Westwood studios. Strangely the description for the item also mentions that “Atari” was printed on some of the boards. It is currently unknown who bought the hardware and if it was used for Westwood’s only NES title called DragonStrike. Games that may have been built with this kit: DragonStrike NamcoNamco reverse engineered the Famicom hardware and created their own suite of development tools 15. However very little information has been released about their internal development kits so it is presumed they were disposed of after NES development ceased.N2G - Nintendo Development System The user JaxsBox posted details of a 3rd party development kit for the NES on the old NintendoAge site, where he has posted a few photos and some technical information 16. Note that this development kit doesn’t contain a cartridge slot so it probably connects to a developers PC directly to send ROM data to the machine for emulation. Presumably this was developed in house by RSP (Riedel Software Productions, Inc), although it is also possible that it was developed by another company and just licensed to RSP. Games that may have been built by this development kit: Sesame Street: Countdown Sesame Street: Big Bird’s Hide and Speak MTV Remote Control Win, Lose, or Draw Square (Apple II & Twin Famicom) In a very rare interview with Nasir Gebelli he talks about creating NES games for Square with an Apple II and Mini Assembler, including final fantasy 1! This is a short video on the making on final fantasy 2 and it looks like most of the developers are using a Sharp Twin Famicom. This was used to at least test their games on but it is unclear if they built any custom hardware or even what computers they used to write the 6502 assembly on. Although it was presumably the Apple II with Mini Assembler. Programmers Development System (PDS)The Programmers Development System or PDS for short was a development kit for many 8-bit systems including C64 and ZX Spectrum that was very popular in the UK 17.It was developed by Andrew Glaister, Foo Katan and his friend Jez San and sold by their company PD Systems Ltd. Foo Katan was also the founder of Bits studios which created the NES game Loopz and many gameboy games, including a game boy development kit 18. It is unclear if his NES and GB development was based on his prior work with PDS but it is very likely at least influenced by it.Rare Ltd (PDS) Rare became one of Nintendos first 3rd party developers outside of Japan by Reverse engineering the Famicom hardware before its western launch and presenting the results to Nintendo 19. This development kit was the result of the reverse engineering effort as you can see the board has COPYRIGHT 1988 RARE LTD rather than an official Nintendo or Intelligent Systems Copyright mark. It also has Nintendo PDS Interface printed on the board, which likely stands for Programmers Development System. This hints at it being used with the PDS development system made by P.D.Systems Ltd (Andy Glaister & co) which came with a 6502 assembler and was a full development system for C64 and ZX Spectrum 17. PDS was a commonly used development kit in UK and it would be likely that when Rare was developing ZX Spectrum games they used this development system so all they had to do was reverse-engineer the NES and create an interface to control it from their existing development setup. Eurocom (PDS)In the source code for the 1990 NES game Magician, which was kindly opened source by developer Chris Shrigley, it contains .PDS files which are used in the PDS development kit.When you open the .PDS files in a text editor the string P.D.Systems Ltd 1985-88 can clearly be seen confirming that it used the PDS development system.So it was definitely used for NES game development by studio Eurocom but whether they used Rare’s interface board or created their own remains a mystery.Zippo Software (Rare partnership, probably PDS)In the UK Magazine GamesTM issue 22 it is mentioned that Zippo software’s partnership with Rare meant they were one of the first to receive a NES development kit outside of Japan and thus producing Solar Jetman in 1989. It is possible that this is a PDS development System kit with the Interface card built by Rare.CodemastersAs a fellow British game developer who was working on C64 and Spectrum games, Codemasters used PDS to develop most of their games for all of these platforms 20.Although it has been confirmed that used PDS for all their other systems there is no proof that they also used the development kit for NES games but it is probable as they were already familiar with the environment.In Edge UK Magazine Issue 136 it is mentioned that they created their own prototype NES development kit to get around Nintendo’s expensive licensing fees. This is also how they developed the cheat device known as the Game Genie 21.Their hardware side of the development kit was described as a PC connected to a C64 connected to a NES in a mass of wires and each release was named after a character from Blade Runner 21!Bit Managers & Infogrames (PDS) In an Interview with Alberto González who was a composer for many classic video game soundtracks along with graphics development work, he mentioned that he used PDS with modifications for GameBoy, Master System and NES 22. The screenshot on the left is Alberto using PDS Pc1.24 developed by P.D.Systems Ltd 1985-88. Unanswered QuestionsDid Nintendo ever provide an Official Development kit for the NES?Many sources hint that there was no official Nintendo development kit for the NES and in fact there is very little information that has been leaked about these development kits. It looked like Nintendo themselves used EEPROM writers and custom made cartridges for development.However in the NintendoAge article from issue 2 14 it mentioned that in 1987 BEAM software knew they couldn’t get an official development kit from Nintendo and so made their own. When Nintendo found out about their custom development kit they wanted the sale of it stopped. Why did they want the custom development kits to cease production if they didn’t have officially supported ones?Did they really rely on every single studio creating their own hardware based development kit? It seems like quite a barrier for entry, but then again Nintendo only wanted quality software so this could be intentional.Official NES development software such as assemblers?Some sources such as 2 suggest that there was an official Nintendo assembler for the NES but very little information online confirms this.References Gamasutra - A former mentor recalls the early career of Satoru Iwata ↩ What was dev like on the NES back in 1987? ↩ ↩2 Nintendo Entertainment System/NES (1985-1995) – History of Console Gaming ↩ ↩2 Stars of Famicom Games ↩ News Report: Nintendo’s Revival of the Video Game Industry. December 1988 - YouTube ↩ history - Was Family BASIC for the NES/Famicom powerful enough to create full games and applications? - Retrocomputing Stack Exchange ↩ Gamasutra - A basic history of BASIC on its 50th birthday ↩ NES Mission control dev kit ↩ NES Mission Control Development System ↩ ↩2 Kirby’s Development Secrets – Source Gaming ↩ First Kirby Game Was Created With a Trackball, No Keyboard Gaming ↩ Beta64 - Kirby’s Adventure & Kirby’s Dream Land - YouTube ↩ Bagshot Row : The Chuckie Egg Professional’s Resource Kit ↩ NintendoAge e-Zine Issue 02 2009 ↩ ↩2 ↩3 ↩4 How Do You Make a Game? Part 2: Development Tools – The History of How We Play ↩ N2G ↩ PDS development system - CPCWiki ↩ ↩2 Retro Gamer 2018 PressReader.com ↩ Original Famicom (NES) development kit belonging to RARE. : retrogaming ↩ Oliver Twins ↩ Edge UK Issue 136 ↩ ↩2 Interview with Alberto González (composer) – VGArc ↩ ", "excerpt": "Introduction The Nintendo Famicom was released in Japan on 15th July, 1983 at a price of 14,800 yen. Development for the machine was strictly controlled by Nintendo as they didn’t want a repeat of the US “Video Game Crash” which they blamed on the lack of quality games. As such most...", "tags": ["nes","devkit","hardware"], "image": "/public/images/nes/NES Famicom Development Hardware.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "The History of NES Emulation", "url": "/nes-emulation", "content": "The History of NES EmulationThe Birth of Emulation and the NESIn the early 1990s, as personal computers became more powerful, a new frontier in gaming culture emerged: emulation.Emulation involves mimicking one system’s hardware or software on another platform, allowing games and applications designed for older systems to run on modern hardware.The Nintendo Entertainment System (NES), released in 1983 in Japan as the Famicom and in 1985 globally, became one of the most iconic gaming consoles of all time.By the mid-90s, with the NES discontinued and its cartridges becoming harder to find, nostalgia fueled the desire to play classic games on newer systems.The Pioneers of NES EmulationThe earliest attempts to emulate the NES were small-scale and rudimentary.Family Computer EmulatorIn 1990, programmer Haruhisa Udagawa developed “Family Computer Emulator V0.35” for the Japan-only FM Towns PC.Since this was long before the iNES format each game was split into multiple files depending on the ROM chip inside the cartridge (.P25 for Program ROM, .C64 for Character ROM)This primitive emulator could run only five NES games and Version 0.35 of it lacked complete sound support.The emulator even in its last known version (V0.45) had several limitations: The priority between sprites and background is fixed (for instance, it cannot display Mario entering a pipe or enemies appearing behind it). It only supports vertical scrolling. ROMs are limited to 40KB in size (PRG 16KB or 32KB + CHR 8KB). Sound reproduction is incomplete, and color rendering is also inaccurate.These issues limit the titles that can run, but for games that do work, the emulator allows normal operation and can be played as long as the sound is ignored.It was available on the FM Towns Freeware Collection 3 CD (which is available on archive.org here: FreeWare Collection 3 / フリーウェアコレクション3 - Internet Archive)You can see a video of version Ver 0.45 of it here running in the FM Towns emulator Tsugaru by bcc2528:iNES (1996)The iNES emulator is a significant piece of NES emulation history, developed by Marat Fayzullin in 1996. One of iNES’s lasting contributions was the introduction of the iNES file format for ROMs. This format (.nes file extension) became the de facto standard for NES ROM images and is still widely used today. The format includes a small header containing metadata about the ROM, such as the mapper type, mirroring, and other technical details.NESticle (1997)A significant breakthrough came in 1997 with the release of NESticle, a Windows-based NES emulator created by programmer Icer Addis of Bloodlust Software.NESticle was revolutionary: it could play many NES games at full speed on common PCs of the era and featured debugging tools, save states, and graphical enhancements.Modern Vintage Gamer has an excellent video covering the impact of NESticle:Its user-friendly design and high compatibility made it popular among gamers and developers, laying the groundwork for the emulation scene as we know it today.ROMs and the Ethics of EmulationAlongside the rise of NES emulators, ROM files-digital copies of NES game cartridges-began circulating on the internet.These ROMs were often extracted using specialized hardware devices and shared on forums, newsgroups, and early file-sharing networks.NES ROMs allowed players to access classic games that were otherwise out of print, but they also sparked intense debates about the legality and ethics of emulation.Nintendo, aware of the growing emulation scene, began cracking down on websites hosting ROM files, issuing cease-and-desist letters and pursuing legal action.Despite these efforts, emulation continued to grow as a grassroots movement, with many enthusiasts arguing that it preserved video game history and offered access to games no longer commercially available.The Rise of Open-Source EmulatorsBy the late 1990s and early 2000s, the NES emulation scene matured significantly. Open-source emulators like FCE Ultra and Nintendulator emerged, allowing communities to contribute to the codebase and improve compatibility.These projects pushed emulation accuracy to new heights, ensuring that NES games ran as close to their original hardware as possible.Another milestone came with Nestopia (2003), an emulator renowned for its near-perfect accuracy and feature set.Nestopia’s focus on preserving every quirk and behavior of the NES hardware earned it praise from enthusiasts and developers alike.Accuracy vs. Speed: A Balancing ActAs emulation technology progressed, a split in philosophy emerged within the NES emulation community: accuracy versus speed.Some developers prioritized making emulators as accurate as possible, replicating the NES’s hardware down to its most obscure bugs and quirks. Others focused on optimizing performance to ensure that emulators ran smoothly even on older computers.Emulators like higan (formerly bsnes), created by Near (formerly known as byuu), represented the pinnacle of accuracy, using techniques like cycle-accurate emulation to replicate the exact behavior of the NES CPU, PPU (Picture Processing Unit), and memory. However, the cost of such accuracy was higher system requirements.On the other hand, lightweight emulators like Nestopia UE and QuickNES prioritized accessibility and performance, making NES emulation available to a broader audience.NES Emulation Goes MainstreamBy the mid-2000s, NES emulation had entered the mainstream. Emulators became essential tools for game preservation, speedrunning, and modding. Fan-made hacks, translations, and homebrew games flourished, breathing new life into classic NES titles.Popular emulator frontends like RetroArch and OpenEmu further democratized NES emulation by offering polished, all-in-one solutions for managing ROM libraries and running emulators.Official NES Emulation from NintendoNintendo, meanwhile, began embracing its retro library through official channels.With the launch of the Virtual Console on the Wii in 2006 and later services like the NES Classic Edition and the Nintendo Switch Online NES library, the company capitalized on the enduring popularity of its 8-bit classics.These official emulators offered an alternative to the fan-driven emulation scene while underscoring the importance of preserving gaming history.The Role of NES Emulation in Game PreservationNES emulation has become a cornerstone of video game preservation. Many classic games risked being lost to time due to aging cartridges, hardware failure, and the lack of re-releases. Emulation has allowed these titles to remain accessible to new generations of players and researchers.Moreover, the tools built by emulation developers-debuggers, disassemblers, and reverse engineering frameworks-have been invaluable to historians, speedrunners, and modders.Projects like Mesen, a highly accurate NES emulator with powerful debugging tools, have enabled developers to analyze NES games at a granular level, leading to discoveries about programming techniques, unused assets, and developer secrets.Legacy and Future of NES EmulationToday, NES emulation is a mature, well-documented field, with multiple emulators offering near-perfect accuracy.Modern tools like Mesen, higan, and RetroArch allow players to experience NES games in ways that were impossible on the original hardware-complete with high-definition", "excerpt": "The History of NES Emulation The Birth of Emulation and the NES In the early 1990s, as personal computers became more powerful, a new frontier in gaming culture emerged: emulation. Emulation involves mimicking one system’s hardware or software on another platform, allowing games and applications designed for older systems to...", "tags": ["nes","emulation"], "image": "/public/generated/placeholders/nes-emulation.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Reversing Engineering a NES Game With Ghidra", "url": "/nes-ghidra", "content": "Introduction This page walks you through using Ghidra to reverse engineer NES ROMs using the Ghidra-Nes-Rom-Decompiler-Plugin. This plugin currently only supports a handful of the most common mappers but it adds up to quite a large number of games supported. A Note on Mapper SupportTo reverse engineer a NES ROM with Ghidra you need the GhidraNES Plugin, but note that it only currently supports the following mappers so far: Mapper 0 - NROM - NES games using mapper 0 (245 games including worldwide variants) Mapper 1 - MMC1 - NES games using mapper 1 (673 games including worldwide variants) Mapper 2 - UxROM NES games using mapper 2 (265 games including worldwide variants) Mapper 7 - AxROM - NES games using mapper 7 (76 games including worldwide variants) Mapper 10 - MMC4 - NES games using mapper 10 (3 games, all Japanese) Mapper 19 - Namco 129/163 - NES games using mapper 19 (20 games, all Japanese)So make sure that your game is in one of those lists before continuing.What about the other mappers?So it might look like there is not much mapper support in the list above, but remember not all mappers have been used, and many just for a single game.It is unlikely your game will be using Mappers: 6,8,12,14,15,17,27-31,35-47,49-63, 74, 81, 83-84, 90-91, 98-104, 106-117, 120-139, 141-143, 145-151, 153, 155-157, 160-179, 181-183, 186-205, 208-209, 211-231, 233-255 as there was no official games released for them (pirate games and multi-carts only).Notes on a couple of other mappers: Mapper 9 was just used for Punch-Out. Mapper 11 was for unlicensed religious games by Color Dreams. Mapper 13 was only used for Videomation (a paint program for NES) Mappers 16, 18-19, 21-26, 32-33,48, 65, 67, 70, 72-73, 75-78, 80, 82, 85-89, 92-97, 140, 152, 154, 159, 180, 184-185, 207, 210 was only used for Japanese games Mapper 20 was never actually used (intended for FDS games) Mapper 34 was only used for 2 different games (Deadly Towers/Mashou and Impossible Mission-II) Mapper 64 was used for 5 TENGEN games in the USA Mapper 66 (GxROM) was used for 11 unique games worldwide Mapper 68 was used for 3 games (After Burner and 2 Japanese games) Mapper 69 was used for 10 Sunsoft games Mapper 71 was used for Camerica/Codemasters games Mapper 79 was used for 15 American Video Entertainment games Mapper 105 was only used for the Nintendo World Championships 1990 cart Mapper 118 was used for 6 games worldwide Mapper 119 was only used in 2 games (High-Speed and PinBot) Mapper 144 was only used for Death race Mapper 158 was only used for the TENGEN game Alien Syndrome Mapper 205 was used for 41 games and is similar to MMC3 Mapper 232 was used for 3 Quattro games by CamericaSo unless you are looking to reverse engineer Japanese, pirate or a few obscure games, the only mappers that need to be implemented to give access to the majority of the NES library are mappers 3-5 and maybe 205.Opening NES ROMs with GhidraGhidra doesn’t have support out of the box for NES ROM reverse engineering so we need to use a plugin created by ilyakharlamov available here:ilyakharlamov/Ghidra-Nes-Rom-Decompiler-Plugin: Ghidra NES / Famicom ROM Decompiler PluginAfter downloading open up ghidra and go to File -> Install Extensions..It will then open up the following window, click the green plus icon in the top right:Then make sure to select the zip file that you downloaded previously:If you get the following screen then you will either need to build the plugin from source or use an older version of Ghidra:When attempting to compile the plugin from source and linking the ghidra directory I normally get the error: JavaModelException: Build path contains duplicate entry: ‘/ghidra_10.2.3_PUBLIC/Ghidra/Processors/68000/lib/68000.jar’for project ‘Ghidra-Nes-Rom-Decompiler-Plugin’To fix this you need to right Click on the Project and select “Properties”, go to the “Java Build Path” tab and then the Libraries tab and delete all the jars.When that is done you will be able to run the application in Eclipse by clicking the green play icon and the following window will pop up:Select “Ghidra” from this window.If you get an error such as: Exception in thread “main” ghidra.util.exception.AssertException: Multiple modules collided with same name: Ghidra-Nes-Rom-Decompiler-PluginTHen you need to delete the Ghidra-Nes-Rom-Decompiler-Plugin folder from the global ghidra config file location e.g ~/.ghidra/ExtensionsNow when you go to Import File and select a .nes ROM file you should get the following dialog:Now after import you should be able to decompile any function you want as long as the Mapper is supported in the NES Plugin (currently only Mapper 0):Reversing Super Mario Bros with GhidraSuper Mario Bros is an excellent game to use to learn Ghidra and how to reverse NES roms, as there is already documentation and disassembly on the web. So you can practise using Ghidra and use the Mario Bros disassembly here to check your work!First make sure to open the Super Mario Bros. (World).nes rom (MD5: 811b027eaf99c2def7b933c5208636de) with Ghidra and the GhidraNes plugin as shown in the previous guide.Now you will notice that it has detected about 36 functions, along with some already named like reset and vblank:If you start at the top of the Ghidra Disassembly window you can start to name them based on the disassembly file here.Note that normally you won’t have all the symbol names given to you like this for ROMS that have not yet been disassembled by the community, we are just using this as an example to teach the basics of Ghidra.Renaming Functions and LabelsGo to the first function at 0x8000 and you will notice it has already been named as “reset”, in the disassembly we are using it was called start so we can rename this to match just for convenience.To do this select the reset name and Press the L key on the keyboard, this will open a dialog asking for the name type in Start like so:The reason we know this is called Start is because of the .org $8000 just before the Start label, this means place that function at location 0x8000.We can now start from the top of the Ghidra Listing and start re-naming the labels to match the disassembly, starting with VBlank1 then VBlank2 etc by pressing L and typing in the name.You now know how to rename a function/label, which will be used all the time when reverse engineering your own ROMS.Fixing Incorrect DisassemblyNow you can keep going down and naming until we get to MoveAllSpritesOffscreen where you will notice the community disassembly and the Ghidra auto disassembly listing don’t match:We can tell this is wrong as Ghidra put a label 1 byte into what it thinks is the BIT instruction (LAB_8222+1) which should not be possible.The strange thing is that this doesn’t look like valid 6502 assembly, the BIT instruction is normally more than just the opcode (has operands too), but the disassembly just has it as:.db $2c // Just the opcode for BIT instructionThis could be an optimisation to keep the number of bytes down, if the program comes from the MoveAllSpritesOffscreen label then it will indeed read it as a BIT instruction, however if they go to the MoveSpritesOffscreen (LAB_8222+1) label it will be read as a ldy #$04 instruction.You can leave this code as it is but if you want it to look like the original disassembly you can use Ghidra features to change it.You can Right click and select Clear Code Bytes or just press C, this will mark it back to data. Then right click 0x8223 and select Disassemble to see the LDY instruction. In the end it should look like this:Defining Missing code and labelsKeep going through the disassembly until after you have named SprInitLoop and you will notice that after the RTS Ghidra just thinks there is data:However the community disassembly knows this is a label called TitleScreenMode with some assembly code in it.It is easy to tell Ghidra that this is code in the same way you did above, by right clicking 0x8231 and select Disassemble or just pressing D on the keyboard.But you will notice that it didn’t auto add a label to this code, because Ghidra has no idea it has been called and where it has been called.You can give the 0x8231 address a label by pressing L in the same way we have been renaming labels before.it should now look like this:Defining data typesNow you will notice that the community disassembly uses the Define Word (.dw) opcodeafter the JSR to join the bytes together into words (2 byte blocks).We can also do this in Ghidra by right clicking the first byte that you know is actually a Word and select Data -> Word like so:How JumpEngine works (Jump tables)Now this is where it is useful to know about one of the functions in the disassembly called JumpEngine.The code is here (copied from the community disassembly):;-------------------------------------------------------------------------------------;Memory address 0x04 - address low to jump address;Memory address 0x05 - address high to jump address;Memory address 0x06 - jump address low;Memory address 0x07 - jump address highJumpEngine: asl ;shift bit from contents of A (Multiply Accumulator by 2 due to 16-bit addressing (2 bytes for an address) tay ; Y = A pla ; pull saved return address from stack into Accumulator sta $04 ; Store value of Accumulator at Memory location 0x04 pla ; pull saved return address from stack into Accumulator sta $05 ; Store value of Accumulator at Memory location 0x05 iny lda ($04),y ;load pointer from indirect sta $06 ;note that if an RTS is performed in next routine iny ;it will return to the execution before the sub lda ($04),y ;that called this routine sta $07 jmp ($06) ;jump to the address we loadedThis code implements a jump table mechanism using indirect addressing to determine which function to execute based on the contents of the accumulator (A), and perform a jump to that routine.Now remember all the DW (DefineWord) opcodes we just added, these are the functions that get executed by the JumpEngine function based on the Accumulator (A register).This means that the 2-Byte Words we are defining are actually locations to functions that get jumped to at runtime.Ghidra’s static disassembler was not smart enough to pick this up (would require dynamic disassmbler/runtime information). But we can use this information to tell Ghidra about functions it doesn’t know about.This is why Ghidra only detected about 36 functions by itself, its not because Mario has been implemented in that few functions, it just didn’t have enough information to find them.Defining Blocks of dataYou will notice in the community disassembly there are blocks of named data such as WSelectBufferTemplate:WSelectBufferTemplate: .db $04, $20, $73, $01, $00, $00We can name the first byte with a label like we have done previously, but how do we group these bytes together?One way is to define them as a Byte Array in Ghidra (Data -> Choose Data Type -> Type in byte[6]. Or by Data -> Create Array and type in 6 elements then choose the data type after.Which should result in:Defining FunctionsAfter WSelectBufferTemplate You will notice that Ghidra thinks there is just data but the disassembly knows that there should be a function there.So first at location 0x8245 tell Ghidra to disassemble it as we have done before, and then you will be able to right click the same address and a new option will appear to Create Function.Call the function GameMenuRoutine like so:Now it will appear along side all its other friends in the function panel for easy reference.You will also notice that after marking the bytes as disassemblable, Ghidra has managed to find even more functions by itself (up to 168 now).Using the Kayboard ShortcutsAt this point you should be able to go through the rest of the file and you can use the following table of keyboard shortcuts to save time: Keyboard Key Purpose F Create a Function L Name/Rename a Label or Function D Disassemble [ Create an Array This exercise will really make you appreciate how big a game disassembly is, how many labels need to be discovered and named.Bare in mind you need to find out what the code does in the first place to be able to name them!So its a very time consuming task starting a full disassembly project (never mind a decompilation).Importing symbolsNow I don’t expect you to go throught he whole file and manually add all the functions/labels, there is a much easier way to do that by using some Ghidra scripts that we provide here.Follow the instructions on that readme to import all the symbols for Super Mario into your Ghidra project.", "excerpt": "Introduction This page walks you through using Ghidra to reverse engineer NES ROMs using the Ghidra-Nes-Rom-Decompiler-Plugin. This plugin currently only supports a handful of the most common mappers but it adds up to quite a large number of games supported. A Note on Mapper Support To reverse engineer a NES...", "tags": ["nes","ghidra"], "image": "https://github.com/user-attachments/assets/096a3d2c-ad64-47b3-9671-687b138c146b", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Reverse Engineering NES Games - Uncovering the Secrets of Classic Gaming", "url": "/nes", "content": "Welcome to our in-depth guide to Nintendo Entertainment System (NES) reverse engineering! This page serves two roles. It groups all of our posts related to reverse engineering for the system, and it aggregates high quality sources from the web into create a unified reference.The content starts high level, outlining the system, its history, and its official game development process, then moves into low level details with a focus on reverse engineering and homebrew development.IntroductionThis section gives a high level overview of the Famicom/NES to give context that can be useful when trying to understand why the system works in a certain way and how officially licensed game developers worked with the system.History of the Nintendo Entertainment SystemThe Family Computer (Famicom) was released in Japan on July 15, 1983.How many NES games were released after its successor, the SNES launch?Despite the release of the Super Nintendo Entertainment System (SNES) in the early 1990s, the original Nintendo Entertainment System (NES) continued to maintain a substantial presence in the gaming industry.In 1993, a surprising 55 new NES titles were released 1, showcasing the enduring popularity of the 8-bit console. This phenomenon can be attributed to several factors, including the affordability of the NES, its vast existing user base, and the dedication of developers and publishers who continued to support the platform.Official Retail NES Game Source CodeIf you are interested to see officially released or leaked source code for the Nintendo Entertainment System check out our other post: Retail Console Game Source code (C/C++) For the official source code check out this post. Home Alone NES Source CodeThe full source code for the NES game Home Alone was released online thats to the Game History Org and we have a specific post covering the details of the files included: Home Alone 2 NES Source Code For the official source code to Home Alone for the NES check out this post. HardwareIn this section, we’ll explore the hardware that powers the NES and how it can be reverse engineered. Understanding the hardware that drives the NES is key to unlocking its potential and gaining a deeper appreciation for the games that were developed for it.We’ll take a closer look at the different components of the NES hardware, including the CPU, PPU, and APU, and discuss how they work together to create the unique gaming experience of the NES.Development Kit HardwareSince Nintendo were very new to the home video game market, they saw themselves as creating most of the software that will run on the NES.So they did not make a public NES development kit, so most third parties has to roll their own development kits.We have a specific post covering all the NES development kits that we know about here: NES (Famicom) Development Kit Hardware For information about Nintendo’s Famicom development hardware check out this post. Retail NES HardwareIf you’re interested in learning more about the hardware architecture of the NES, we highly recommend checking out the post on Copetti.org. This website is dedicated to exploring the technical details of the NES hardware, including the CPU, PPU, and APU, as well as other components that make up the console. You’ll find in-depth explanations of how each component works, as well as detailed schematics and diagrams that help illustrate the inner workings of the NES. Nintendo Entertainment System (NES) Architecture - A Practical Analysis Copetti.org has an excellent tear down of the NES Hardware and how it works Retail NES Cartridges (Custom chips, Mappers)Although all NES cartridges look similar from the outside apoart from a different sticker and maybe a different color cartridge casing, the internals can be vastly different from game to game.This is especially the case in Japan where Nintendo allowed third party developers to manufacture their own cartridges, which means they could add additional microchips inside, such as custom memory mappers.However the same wasn’t the case in the west as described in this quote from MobyGames: Nintendo didn’t normally allow developers to use custom mapper chips in western releases, instead requiring them to reprogram their games for Nintendo’s own MMC mappers. This is because Nintendo manufactured all cartridges in the west.Mr. Gimmick and Batman:Return of the Joker (which uses the same FME-7 mapper chip) are the only two official western NES releases to use custom mapper chips.For emulators to support all the different cartridge hardware, emulator authors came up with the concept of Mappers which are part of the iNES Header and are used by emulators to vary the emulation based on what Mapper the game ROM is defined as using.NESCartDB: NES Cartridge DatabaseNESCartDB is the definitive resource for technical information on Nintendo Entertainment System (NES) and Famicom cartridges, originally created by BootGod. The database catalogs high-resolution PCB scans, mapper assignments, ROM checksums, and chipset details for thousands of games. It serves as a critical reference for emulator developers and reverse engineers needing to verify hardware configurations and understand how specific titles interface with the console. NESCartDB: NES Cartridge Database BootGod provides NESCartDB, an exhaustive database of NES cartridge PCBs, mappers, and hardware specs vital for accurate emulation and preservation. Retail NES Controller Electronics Have you ever wondered about how a NES controller actually works, such as the circuits and electronic components used to physically create it? Well you are in luck, the YouTuber Displaced Gamers explains exactly how the electronics of the NES controller works and a few interesting facts along the way! He opens up the NES controller revealing the physical wires, traces (green lines on the circuit), rubber membranes and the 8-bit shift register (HD14021BP). The Controller as with all electronics has both a Power (High) and Ground (Low) lines, with 5V used for Power. Ground is connected to all of the buttons including the 4 D-pad buttons, whereas the Power lines go straight to the Carbon Printed Pull-Up resistors which then in-turn goes to each of the buttons. When a button is pressed it completes the circuit at that point meaning it is pulled Low (Grounded) which allows the shift register to know that button is pressed. The resistors are used to make sure the power lines are always High, so we can ensure that when a pin is pulled low it has definitely been pressed. Game Software Development for the NES and FamicomThere was an official software development kit provided by Nintendo/Intelligent Systems for the NES/Famicom but Nintendo didn’t distribute it to third party developers. Instead developers were required to either get an off-the-shelf 6502 assembler or write their own. Paired with a booklet covering how the NES handled graphics, input and sound, this was all that game developers got in terms of software for game development on the NES.Nowadays there are many open source assemblers, IDE’s and even high level language compilers that can be used to create NES homebrew games.How long did it take to develop games for the NES back in the day?On average, NES game development could take anywhere from several months to a couple of years. Some simpler or shorter games might be developed more quickly, while larger, more complex titles could take longer.Most game development teams only hand a handful of people working full time on the game, mostly programmers. Artists and Sound Engineers were often working on multiple projects at the same time. Music was usually created and added to the game near the end of the development process when the game was getting ready to be shipped.Some examples of the length of time it took to develop Nintendo Entertainment System games are: SOLAR JETMAN: HUNT FOR THE GOLDEN WARSHIP - Took 1 year with 4 developers (but only 2 developers for 60% of development time) 2. The Portopia Serial Murder Case and other ports by Chunsoft took about 4 months with a team of about 5-6 people 3. Guevara/Guerrilla War by SNK was ported from the arcade original in just two months by the main programmer Yukio Kaneda. This was an agreement in which he would accept the short deadline in return for being allowed to add a hidden minigame based on the orignal SNK game Sasuke vs. Commander 4Who was the first NES game developers outside of Japan?The British company Rare made gaming history by becoming the first non-Japanese licensed game developer for the NES, securing the license from Nintendo through an ingenious demonstration of their skills by reverse engineering the console and showcasing the game “Slalom” as a convincing demo to Nintendo in 1986 5.They created their own development kits based on the PDS and you can find out more about it in our post on the NES Development Hardware: NES (Famicom) Development Kit Hardware For information about Nintendo’s Famicom development hardware check out this post. What do we know about the Official Famicom SDK?The Official Famicom SDK was created by Nintendo and Intelligent Systems in 1986, as revealed by a file leaked in the Nintendo Gigaleaks. The file, called HDT.EXE, was included with the source code to the Game Boy Zelda game.It contains the NES/Famicom Debugger, a tool developed by Intelligent Systems between 1986-1989, which appears to read in three file formats: CHR (Character/Tile Data), SCR (Screen data or Source Data), and CGD (possibly standing for Character Graphic Designer, though this is uncertain).What did a NES/Famicom Design Document look like?Hardcore Gaming 101 has a video showing the design document created for the Famicom game Guardian Legend:NES EmulationWhat is a NES emulator and how does it work?We have a specific post covering exactly how emulators work including tips for writing your own emulators: How Do Emulators Work? A Deep Dive into Emulator Design For more information on how emulators work check out this post. When was the first NES emulator?We have a specific post on the history of NES emulation: The History of NES Emulation For more information on the history of NES emulators check out this post. NES Emulators with Debugging FunctionalityWhen reversing or developing NES games it is vital to use a good emulator which has debugging support such as: BreakPoints - e.g can create a breakpoint at a specific code or memory location and execution will stop at that place Symbol File support - e.g supports loading a file with a list of known variable and function names Built-in Assembler - assemble code in real-time within the emulator to quickly create patches PPU Viewer - see the current state of the Picture Processing Unit such as the Nametable, Sprites, CHR Memory viewer etcHere is a list of a few Open Source emulators that have some of these features: Mesen - SourMesen/Mesen: Mesen is a cross-platform (Windows & Linux) NES/Famicom emulator built in C++ and C# Nintendulator - quietust/nintendulator: NES emulator for WindowsGame Modding and ROM HackingBy modifying the code, graphics, or sound of an NES game, you can create new levels, characters, or even entirely new games that build upon the classic gameplay and aesthetics of the original.Additionally, modding NES games can be a great way to learn more about the technical aspects of game development and programming.Tonkachi Editor (Hammer Editor)Released on the 1st July 1987 by I-2 Co. Ltd 6 the Tonkachi Editor was a Famicom Disk System Disk which allowed editing of other Famicom Disk System games. This is the earliest ROM Hacking software we are aware of and was sold in retail stores in Japan.This was years before the first Game Genie’s were released and it was far more powerful than any chat cartridge that was ever released in the west.How did Tonkachi Editor work?Since Famicom Disk system games were written on re-writeable Quick Disks all the software needed to do was load itself into memory, ask the user to put the game they want to modify in and then allow the user to change bytes in HEX or ASCII format before writing the game out to a free slot on the card.Although it was quite cumbersome as in order to test out the changes you would need to write the card and reboot the system into the written game. So some people used multiple Disk systems, so they could keep the Tonkachi Editor editor running on one of them and test out the changes on the other, without the constant restarting 6.What documentation did Tonkachi Editor come with?It came with a rather beefy 63 page manual in A5 format, printed in black and white. Apparently it even teaches some basic 6502 assembly language 6! It even documented how the original Super Mario Bros worked (although it is inaccurate), that would become the basis of our deep understanding of the game to this day.Did Tonkachi Editor come with any ROM Hacks built in?Yes there was a ROM hack of the original Super Mario Bros called Hammer Mario which may be one of the first ROM hacks ever created! 6.Did Tonkachi Editor support cartridge based games?Yes cartridge games were supported (on the twin fami) but only up to 320kb could be transfered on to the disk cards so when Nintendo started releasing larger cartridge based games they could not be edited 7.The Tonkachi Editor magazines/news/bookletsSimilar to cheat books that were published for cheat cartridges there was a magazine produced called the Hammer News, it had 6 volumes and was created by users writing in to i2 with their own findings modifying Famicom Disk System (and even ROM cartridges).Quick Hunter Parameter Software (Game Analyzer Group Club)Despite the success of Tonkachi Editor no other companies created competitors, the only thing that came close was the Quick Hunter Parameter software (クイックハンター) for the Famicom Disk System 6.It’s not quite clear what the Quick Hunter Parameter software actually did, but since Quick Hunter itself was a illegal Disk copier, presumably the Parameter Disks allowed some minor modifications such as a cheat code to be inserted.There was at least 3 Parameter software disks released in japan 8.Although I can only find photos of the main software and two parameter disks:Game Genie Cheat Cartridges (1990+)The main cheat cartridge available for the NES was the Game Genie created by Codemasters (Distributed by Galoob & Hornby Hobbies). This was a physical connector that would sit between the NES and the Game Cartridge you wanted to cheat on. It would alter the signals based on which memory addresses were being read/written to in real-time based on the Cheat code that was loaded into the system.Game Genie Code FormatThe Game Genie used a special encoding format for its codes which can be encoded and decoded using this handy online tool:Game Genie Encoder/DecoderMaking Game Genie Codes PermanentIf you want to permanently modify one of your NES ROM files with a certain cheat code there is a Windows Only tool to do this created by rdurbin:Romhacking.net - Utilities - Permanent Game GenieNES Memory CorruptionCorrupting the memory of a ROM has become very popular over on Youtube with creators such as Vinesauce regularly using ROM corruptors on popular games to produce some interesting results.If you want to try it yourself we recommend the Real-Time Corruptor Vanguard (RTCV) available on Github: redscientistlabs/RTCV: Real-Time Corruptor, Vanguard, CorruptCore, NetCore2 https://redscientist.com/rtc. It is written using DotNet so it should work on Windows and MacOSX/Linux via Mono.For more information we have a specific post on the topic of Game memory corruption: Emulator Game Memory corruption For information about Game Memory Corruption check out this post. Deliberate NES Memory Corruption by Javidx9The Youtuber Javidx9 has created a system that randomly corrupts the memory of a NES game (every 5 seconds) as it runs just for the fun of seeing the chaos that follows. The interesting part of this is that his system is somewhat smart in that it tracks the most common memory addresses used per frame (excluding screen memory) and changes those at a higher rate compared to just random memory locations.Apparently the source code was once linked on the twitch page, but it is sadly so old now that the link has disappeared, it would have been really interesting to see it!HD Texture PacksYou can easily replace the 2D Sprites and Tiles from a NES game with HD/4K alternatives using specific emulators such as Mesen and HDNes. The gameplay is unchanged as it overlays the HD Graphics on top of the game and doesn’t have any of the colour limitations of the NES hardware. These modifications as emulator specific and will not modify the original ROM.Mesen even comes with a HD Pack Builder Tool to create your own texture packs, for more information: HD Packs :: Mesen DocumentationHomebrew NES DevelopmentNES Assembly ProgrammingProgramming the Nintendo Entertainment SystemLevi D. Smith provides a deep dive into the NES architecture, specifically detailing the 6502 CPU registers, PPU and APU memory mapping, and cartridge components like PRG and CHR ROM.The presentation extensively covers writing 6502 assembly, translating high-level programming constructs like loops and subroutines into opcodes, handling hardware interrupts (NMI), reading controller I/O ports, and utilizing the five audio channels.Finally, it demonstrates the practical application of these concepts by assembling a custom homebrew title, “Space Dude,” using the NESASM3 assembler and YCHR sprite editor.Nerdy Nights NES Programming TutorialsThe best 6502 Assembly tutorial for the NES has to be Brian Parker’s Nerdy Nights tutorial series which goes from the basics all the way up to writing a version of pong!It stats with basic architecture and moves through PPU graphics (sprites, backgrounds), APU sound engine creation, and advanced mappers like MMC1.The original posts have been taken down but you can find a mirror here: Nerdy Nights Mirror A complete, preserved archive of the Nerdy Nights tutorials covering NES development from 'Hello World' to a full Pong clone and sound engine. Writing NES Games! With Assembly!!Coding Tech presents a talk by Christian, a web developer who spent three months learning 6502 assembly to build a game for the NES. The presentation walks through the technical hurdles of retro development, from understanding ROM board architecture and the Picture Processing Unit (PPU) to writing low-level code for sprite movement and controller input using the CC65 toolchain.How are NES games so small (40KB)?The game developer Morphcat Games has released a video on how they created an impressive game called Micro Mages in just 40KB without using a mapper (NROM board):It mentioned Metatiles and techniques for optimizing tile usage (removing duplicates and using mirroring).Graphics & RenderingFor an introduction to how the NES renders graphics to the screen checkout Austin Morlan’s excellent article on his website:An Overview of NES Rendering - Austin Morlan.It covers the following topics related to NES Graphics: Tiles - 8x8 pixel graphics used to make up the background of a game Block - A set of 4x4 tiles (used for colour indexing) Frames - Background made up of 32x30 titles (256x240 pixels) Nametable - Big blob of bytes, specifying which tile is placed where in the frame (Like a Room in GameMaker) Pattern Table - Contains the actual pixels for the 8x8 tiles as either a 1 or a 0 (no colour information) System Palette - A Palette of all the 64 colours a NES can output to the screen Frame Palette - A dynamic subset of the System Palette of just the colours used in a single frame. Palette 0 to 3 are for background tiles, and 4 to 7 are for sprites. Attribute Table - A look up table of which Palette to use for that Block (set of 4x4 tiles) Sprites - Graphics made up of tiles but are rendered above the background tilesNES Graphics Explained - The PPUNesHacker provides a technical deep dive into the Nintendo Entertainment System’s graphics architecture, focusing on the Picture Processing Unit (PPU). The video explains the four critical memory sections used to render 8-bit graphics: Pattern Tables for raw tile data, Name Tables for background layouts, Palettes for color management, and Object Attribute Memory (OAM) for handling foreground sprites.What’s Beyond the Screen Borders of the NES?100th Coin presents a technical analysis of the data and rendering artifacts hidden within the overscan regions of Nintendo Entertainment System games. The video explores how the PPU handles off-screen sprite management and scrolling seams, highlighting specific emulation challenges such as OAM cycling and scanline zero behavior.Reverse Engineering Famicom and NES gamesIf you’re interested in exploring the inner workings of classic video games, reverse engineering is a process that can help you uncover the secrets of how these games were designed and programmed.The Basics of NES ReversingIn this section, we’ll provide an overview of the basic techniques used to reverse engineer NES games, including disassembly, debugging, and memory analysisWhat games have already been reverse engineered or are under active development?If you are interested to see existing reversing projects for the NES check out our other post specifically on this topic: Decompiled Retail Console Games For the list of decompiled games check out this post. What does it mean to reverse engineer a NES game?Reverse engineering is a process that can help uncover the inner workings of these games and reveal how they were programmed, designed, and even uncover hidden easter eggs.For more information on the basics and benefits of reverse engineering games in general check out our introductory guide: Beginners Guide to Reverse Engineering (Retro Games) This guide is for all beginners who are interested in learning more about the technical details of their favourite consoles and games. The guide aims to be as console-agnostic as... What are the different File Formats for the NES and Famicom?When reversing NES games you will come across a variety of file formats, this section will try to cover all of the most common formats you will encounter.The formats for NES ROMS (virtual cartridges) are: .NES - This is the most common format for NES ROMs to be in, it is also known as the iNES format, most emulators will play this format (For More information: INES - NESdev Wiki) .UNIF - The Universal NES Image Format was a competitor format to iNES 1.0 but has largely been replaced by iNES 2.0 .FDS - Famicom Disc System backup format created for the fwNES emulator .NSF (NSF2/NSFe) - NES Sound Format for playing music ripped from NES games can be played back in some emulators and specific NSF tools. .TNES - Official Format by Nintendo used on the 3DS Virtual Console and also supports Famicom Disc System gamesHow can I reverse engineer a NES ROM with Ghidra?Ghidra is an excellent tool to reverse engineer NES games but there is a lot to cover so we have moved this section to its own post which you can view here: Reversing Engineering a NES Game With Ghidra For a guide on how to reverse NES games with Ghidra check out this post. NES and Famicom Reverse Engineering GuidesThis section aggregates many of the excellent guides and write-ups of the process of reverse engineering NES games.Ghidra Plays Mario: Emulating NES games in Ghidra with pCodeGhidra uses pcode as an intermediate representation of machine code, enabling more abstract analysis and manipulation of binary instructions across different processor architectures during the reverse engineering process.Ghidra provides a built-in emulator that can execute pcode, which has been put to good use in the ghidra-plays-mario Github project. Where they have taken the cpu emulation out of smolnes emulator and replaced it with the Ghidra pcode emulation and it plays the first level of Mario!This isn’t a realistic way to play the game, it uses pre-recorded inputs, but it is an excellent want to test Ghidra’s pcode emulation! Allowing bugs to be found which when fixed will benefit all NES reversing projects.Adding Hard Drops to NES TetrisThe website Grid Bugs has written an excellent article on reverse engineering the NES version of Tetris to add functionality to the game called a Hard Drop. Check it out here:Reverse-Engineering NES Tetris to add Hard DropNestadia CTF - Reversing a Cloud-based NES EmulatorThe security blog segfault.me has an excellent write-up of a Capture The Flag (CTF) challenge called Nestadia. The challenge involved reverse engineering a cloud-based NES emulator to find a flag hidden inside a game’s ROM. It is a fascinating read on a modern twist to classic NES hacking. NorthSec 2021 Writeup: Nestadia Part 1 Check out the Nestadia CTF Writeup here Super Mario Bros Reverse EngineeringThe original Super Mario Bros was the game that revolutionised platformers, with its smooth scrolling and excellent game design there was bound to be many reversing projects related to it. This section covers projects specifically targeted towards the classic platformer. Let’s reverse Super Mario Bros (NES) Introduction This page will give a brief overview of how Super Mario Bros for the Nintendo Entertainment System (NES) works. This page wouldn’t have been possible without the excellent work... Super Mario Bros Annotated DisassemblyIf you are interested in how Super Mario Bros works (or to really get an insight into how any NROM Mapper 0 game works) you need to check outA Comprehensive Super Mario Bros. Disassembly by doppelganger.Super Mario CompilerThe website neilb.net has created what it calls a Mario Compiler which takes in the original Super Mario Bros ROM and disassembles it.The disassembled code is then shown to the user and can then be modified and re-assembled back into a working NES ROM. All from within the web application! Mario Compiler Check out the Mario compiler here You can also view the source code for the project here: nbarkhina/MarioCompiler: A Super Mario Compiler written in JavaScriptSuper Mario Bros in CMitchell Sternke has created an impressive port of the original NES Super Mario Bros, he has written a tool that converts most of the 6502 assembly code into its equivalent C code. He has then written a PPU, Controller and APU emulation layer in C to make it all work into a portable C application running natively on the target hardware (No 6502 CPU emulation required!).You can find it on Github here:SuperMarioBros-C/README.md at master · MitchellSternke/SuperMarioBros-CExtracting Super Mario Bros levels in PythonMatthew Earl has an excellent post on how he managed to extract the level data for Super Mario Bros using the disassembly project and python scripts:Extracting Super Mario Bros levels with Python - Matt’s RamblingsROM City Rampage (Grand Theftendo) for the NESThe developers of Retro City Rampage (V-blank Entertainment) created a limited NES port of their game for the NES and documented some of the major changes that they needed in order to get it to run on the real console:This is a good introduction to some of the limitations you need to think about when developing a NES game.How to get the ROMAccording to RomHacking.net9 they were not allowed to release the NES ROM created for Grand Theftendo or even some of the documentation that they wrote while creating it. However the ROM is in the final game, so if you own the game it is possible to extract the NES ROM and play it in an emulator!You need to use a tool called BFP Extractor to extract content from: the file gamedata.bfp at addresses 0x747E67D6 and 0xC87FC3A3 then create a iNES ROM Header for it with the following Hex values:4E 45 53 1A 20 20 50 00 00 00 00 00 00 00 00 00Then simply join the header with the content from address 0x747E67D6 and 0xC87FC3A3 together and name it as a .nes file.All Posts The 6502 Microprocessor - Gaming's Unsung Hero The 6502 Microprocessor The 6502 microprocessor was an 8-bit microprocessor that was incredibly popular for 8-bit home computers (e.g Apple II) and consoles (e.g NES) due to its low cost.... ... Read More hardware nes snes cpu Home Alone 2 NES Source Code Home Alone 2 NES Source Code The Source Code for “Home Alone 2” was kindly released by Frank Cifaldi from GameHistoryorg (@frankcifald). Games on the same engine The same Game... ... Read More nes games sourcecode Emulator Game Memory corruption Introduction Game corruption has become a hot topic recently due to many you tubers playing through games that have in some way had their memory corrupted. This practise can cause... ... Read More introduction pc nes n64 NES Sprite Tile Editing Sprite Tile editing with Tile Layer Pro If you have ever wondered how graphical rom hacks are made this is for you! This should work for most early games such... ... Read More nes gameboy introduction NES (Famicom) Development Kit Hardware Introduction The Nintendo Famicom was released in Japan on 15th July, 1983 at a price of 14,800 yen. Development for the machine was strictly controlled by Nintendo as they didn’t want... ... Read More nes devkit hardware The History of NES Emulation The History of NES Emulation The Birth of Emulation and the NES In the early 1990s, as personal computers became more powerful, a new frontier in gaming culture emerged: emulation.... ... Read More nes emulation Reversing Engineering a NES Game With Ghidra Introduction This page walks you through using Ghidra to reverse engineer NES ROMs using the Ghidra-Nes-Rom-Decompiler-Plugin. This plugin currently only supports a handful of the most common mappers but it... ... Read More nes ghidra Nintendo Lot Check ROM Leak Since Nintendo controls manufacturing of all official games they have a process called Lot Check that ensures the games quality before manufacturing. Every game ever officially released for their platform... ... Read More leak nes Introduction to Audio/Music Programming of Retro Games Introduction To get started the 8-bit Guy on Youtube has an excellent video covering how early computers and game consoles played sound and music 1. The gives a good overview... ... Read More introduction pc nes How Retro Cartridges (ROMS) work Have you ever wondered what exactly is inside those retro game Cartridges (ROMs)? In this post we will find out the purpose of ROM cartridges and how they worked. Advantages... ... Read More introduction hardware nes snes n64 megadrive mastersystem Introduction to Retro Game Graphics The 8-bit Guy on Youtube has an excellent series of videos covering how early computer graphics were implemented with the limitations of the hardware in mind. Memory Previously graphics chips... ... Read More introduction pc nes Let's reverse Super Mario Bros (NES) Introduction This page will give a brief overview of how Super Mario Bros for the Nintendo Entertainment System (NES) works. This page wouldn’t have been possible without the excellent work... ... Read More nes games References Game Developer Magazine April 1994 Page 24 ↩ Retro Gamer Issue 96 page 55 ↩ Chunsoft 30th Anniversary – 2014 Developer Interview - shmuplations.com ↩ Ikari Warriors, Guerilla War, and The SNK Golden Age - shmuplations.com ↩ Retro Gamer Issue 84 from December 2010 pages 34–35. ↩ Hammer Editor (Eye-2) Famicom modification tool code page ↩ ↩2 ↩3 ↩4 ↩5 Hammer News Hammer Editor (Eye-2) Famicom Modification Tool Code Page ↩ Buy Quick Hunter - Parameter Disk No. 3 (Unlicensed) Nintendo Famicom Disk System Video Games on the Store ↩ ROM City Rampage ↩ ", "excerpt": "Welcome to our in-depth guide to Nintendo Entertainment System (NES) reverse engineering! This page serves two roles. It groups all of our posts related to reverse engineering for the system, and it aggregates high quality sources from the web into create a unified reference. The content starts high level, outlining...", "tags": ["nes","introduction"], "image": "/public/images/nes/NES Reversing.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Net Yaroze - The PS1 Consumer Dev Kit", "url": "/net-yaroze", "content": "Introduction to the Net YarozeThe Net Yaroze was a consumer development kit for the PlayStation 1, it consisted of a customised retail console with the ability to connect to a developer PC. It cost about £550 in the UK 1 was black in colour and was also used by various Universities to teach game development to their students.What you get in the packWhen you receive a Net Yaroze directly from Sony it will contain the following items: Start up Guide Library Reference User Guide Net Yaroze Boot Disc Net Yaroze Software Development Disc Access card - Similar to a memory card but doesn’t store data (for copy protection?) Communication cableStart up Guide (010-1997-startupguide.pdf)The NetYaroze Start up Guide has 39 pages going through topics such as the members only website, the hardware and software included, getting set up and even writing a simple sample program!Library Reference (030-1997-libraryref.pdf)The NetYaroze Library Reference book has 332 or 349 pages depending on version and is blueish-green in color, it contains the API documentation for Graphics, Sound, Standard and Mathematical functions. It has full descriptions of each of the functions, their arguments and return values.User Guide (020-1997-userguide.pdf)The NetYaroze User Guide has 207 pages and is yellow in color, it contains tutorials for game development such as frame buffer, integrated graphics, sound, kernel management, cd-rom management, and peripheral devices management. Along with documentation for how to use the Sound/Programming and Console tools.Net Yaroze Boot DiscThe NetYaroze Boot Disc is the PS1 Disc that runs the NetYaroze system, it waits for PC input via the communication cable and runs the code sent to it.Net Yaroze Software Development DiscThe Net Yaroze Software Development Disc contains all the PC development tools requires to compile, link and communicate with the PS1 over the communication cable.Net Yaroze Access cardThe Net Yaroze Access card goes in the Memory card 1 slot and the boot disc doesn’t start without it, unsure if this is just for copy protection or if it also saves some data on it.Net Yaroze Communication cableThe Net Yaroze Communication cable slots into the back of the PS1 and connects to a PC’s serial portNet Yaroze in the mediaEDGE ArticleNet Yaroze was featured in the 2000 Christmas edition of the UK Magazine called Edge, it contained interviews with eight programmers who used it to get a start into the games industry 1.You can read the full article over on archive.org:Class of 2000UK Official PlayStation MagazineMany Yaroze games were included in the free demo disc distributed with the UK Official PlayStation Magazine and for many was an introduction to homebrew games!Developing for the Net YarozeSpecial Thanks to XPCoin, who is one of the few people who have documented the process of developing for Net Yaroze on YouTube! Check him out here: https://www.youtube.com/user/gwaldYaroze games on the NUON DVD games consoleBelieve it or not a few games built on the Net Yaroze were ported to the relatively obscure NUON platform 2, they were ported by a site called DragonShadow Industries. The way this was done is rather interesting, they were porting their own game Decaying Orbit to the NUON and instead of fully reqriting the games source code, they created a wrapper library that simulated some of the Net Yaroze librarys. This has the benefit of allowing multiple Net Yaroze games to be ported to the NUON with little code modification required!The games released for the NUON that were developed for Net Yaroze are as follows: Decaying Orbit by DragonShadow Industries Katapila by Ben James Invs by Philippe-Andre Lorin BreakDown by Chris Wallaceunfortunately the source code for this library was never released, so the games that can be ported are limited to the above list for now.References Class of 2000 ↩ ↩2 DragonShadow Industries releases Yaroze Classics for NUON ↩ ", "excerpt": "Introduction to the Net Yaroze The Net Yaroze was a consumer development kit for the PlayStation 1, it consisted of a customised retail console with the ability to connect to a developer PC. It cost about £550 in the UK 1 was black in colour and was also used by...", "tags": ["ps1","hardware","devkit"], "image": "https://img.youtube.com/vi/kswSNF8gsHY/maxresdefault.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Netcard - Cancelled GBA Online Peripheral", "url": "/netcard", "content": "The netcard folder from the Gigaleak contains the documentation, SDKs, and design specifications for an officially scoped but ultimately cancelled online gaming peripheral for the Game Boy Advance. netcard The folder preserves gba.tar (a 2.3 GB toolkit archive) and nc_stuff.7z, but the most revealing contents are internal design documents written in late 2004 by BroadOn (the networking company Nintendo later partnered with heavily for the Wii). They outline a fully structured project to bring Pokémon online via a WAN (Wide Area Network). 📄 NetworkingPokemonDesign.doc Proposes the 3rd Floor of the Pokémon Center 📄 NetworkingPokemonRequirement.doc Details the VNG matchmaking API 📄 OnlinePokemonProject_Design.ppt Internal PowerPoint presentation 📄 PokemonExplained.doc 2004 BroadOn overview of multiplayer modes 🗜️ gba.tar Massive 2.3 GB GBA SDK/toolchain archive 🗜️ iqgba.tar Secondary 532 MB archive 🗜️ nc_stuff.7z Miscellaneous Netcard utilities The 3rd Floor (3F) of the Pokémon CenterAccording to the NetworkingPokemonDesign.doc engineering document, developers planned to add a massive new 3F (Third Floor) to all in-game Pokémon Centers, acting as the dedicated hub for global internet connectivity.The design called for a Communication Lobby that merged the abilities of the wireless Union Room and link-cable Direct Corner into one global environment: Matchmaking & Buddy Lists - Players could search for specific global communication lobbies based on criteria or check a dedicated “Buddy List” to track exactly which lobby their friends were already sitting in. Global Trade Board - An asynchronous trading post where players could register Pokémon they wanted to trade with a visual Lobby Administrator. This heavily foreshadows the GTS (Global Trade Station) introduced a full hardware generation later in Pokémon Diamond & Pearl! Multiplayer Battle Board - A lobby management space specifically designated for coordinating 2 VS 2 online global battles.The VNG Matchmaking APIBehind the scenes, NetworkingPokemonRequirement.doc details an underlying C-style networking and matchmaking API designated VNG.The documentation reveals an ambitious server-client topology utilizing functions like VNG_RegisterGame(), VNG_SearchGames(), and VNG_GetBuddyStatus(). Interestingly, it notes that a public communication lobby would be hosted by a “dedicated Pokemon server running on Linux at IDC,” while private lobbies would function on a peer-to-peer level where the host game creates a Virtual Network (VN) dynamically.The iQue Multimedia Player FeaturesDigging into the ncclient C++ MFC source code itself reveals that the PC client wasn’t just built for matchmaking-it was also an iTunes-style synchronization hub for turning the Game Boy Advance into a portable media center!The ncDlg.h and ncDlg.cpp interface declarations expose explicit file management systems for three core non-gaming media types: MUSIC: The client includes an MCIMP3 audio player implementation and specifically checks file types to sync .mp3, .wav, and .raw audio files onto the Netcard’s storage. PICTURE: There are handlers to view and transfer image directories (OnListPicture()). EBOOK: Explicit buttons and lists exist (OnListBook()) for loading and reading text documents directly on the GBA screen.The UI code tracks SD/Flash storage capacity using m_freespace and m_cardspace tracking variables, confirming the Netcard itself possessed internal memory meant to be managed over USB/link by this desktop client.The Netcard Native GBA Firmware (iqgba.tar)This multimedia functionality is perfectly corroborated by the massive iqgba.tar archive found alongside it. Unlike the misplaced BroadOn Wii repository, iqgba.tar contains the actual target Game Boy Advance firmware source code under the iQue-GBA/viewer/Viewer_NC/ compiler directory!This firmware (the NC Viewer) features a dedicated ncpart/ module containing a fully native GBA MP3 software decoder (mp3dec_mad.c, utilizing the open-source MAD library) and user interface graphical assets (mp3_bg.acg, mp3_obj.aob) designed to render the Music Player natively on the GBA screen. It also contains nc_lobby.c and networking hooks directly referencing the viewer_vng.h protocol layer!The PC Client & 3D Colosseum ModePerhaps the most striking reveal in the OnlinePokemonProject_Design.ppt pitch deck and the nc_stuff.7z archive is that the GBA was planned to connect directly to a Windows PC Client managed by iQue (Nintendo’s Chinese subsidiary).The archive actually contains the active source code for the ncclient Windows application-a C++ MFC tool meant to bridge the GBA to the internet and parse Netcard firmware.The 2004 design slides detail that while all controls and basic offline progression would remain on the Game Boy Advance, the ncclient PC software would be used to handle high-definition 3D rendering: Online Tournament Mode - Players would battle online using the GBA purely as a controller. But exactly like Pokémon Stadium or Pokémon Colosseum, the actual battle animations and 3D models would be rendered on the PC monitor! The documents specify this was to be built directly “based on Coliseum code and 3D model library.” Online Catching Events - iQue planned dedicated “Online Pokemon Capture and Treasure Hunt” map events where “additional Pokemon / treasure shall be released on the network for capturing / hunting.” This massive early “live-service” event would have been visually rendered entirely on the PC screen.The Windows Deployment ArchitectureWe also managed to find the exact Windows executables that iQue intended to use to deploy this entire system out to users. Inside the nc_stuff.7z archive lies an NSIS (Nullsoft Scriptable Install System) directory containing the compiled NetCard0524 distribution build executable structure.This folder holds the underlying proxy engines that allowed the Game Boy Advance to seamlessly push data through the host PC and up to the IDC Linux servers: libvng.dll: A compiled Windows dynamic link library version of the VNG connection API. vnproxy.exe & usbproxy.exe: Dedicated Virtual Network proxy engines meant to run silently in the background, tunneling the GBA’s hardware USB driver (usb_driver/) traffic straight to the matchmaking servers. pki_data/ & root.pem: Public Key Infrastructure certificates, proving all communication between the Game Boy Advance Netcard and the online servers was fully encrypted! tomp3.exe: A background audio conversion utility, confirming the PC ncclient actively ripped and converted audio files into a specific format to accommodate the GBA’s lighter-weight MAD software decoding engine!Structural Gameplay Changes (Offline & Online)Because this Netcard infrastructure required constant server-side connectivity, the design specified making radical changes to the vanilla FireRed & LeafGreen game mechanics to incentivize internet usage and cater to the Chinese iQue audience: The “Region” Concept - To encourage massive online trading over the WAN, the initial retail release would contain the full FireRed and LeafGreen maps, but wild Pokémon distributions would be strictly “region-locked” depending on the player. You would literally have to trade online via the Global Trade Board to complete the Pokédex. Online Hatching System - The classic local egg hatching step-counter system was disabled offline. Eggs could presumably only be hatched while actively connected to the server, likely to track and prevent the illicit offline generation of rare Pokémon. Restricted PC Storage - Players could only access exactly 36 Pokémon in offline mode (6 in the party, and exactly 30 stored in a single PC Box). The rest had to be banked securely online on the IDC Linux servers to prevent offline save-file Hex editing. Disabled Local Wireless - The standard wireless Union Room was actively disabled offline to push players exclusively towards the new 3F Online Communication Lobby. New Chinese Input Method - A native Chinese localization input mechanism was built into the offline GBA game specifically to enable complex chat features within the newly designed 3F Communication Lobby.The Birth of IOS and the Fate of VNGThe most historic revelation discovered within these documents is how deeply the cancelled GBA Netcard influenced the future of Nintendo hardware.Looking into the actual GBA source code inside iqgba.tar (nc_lobby.c), the Netcard natively boots using <sc/ios.h> and starts its server matchmaking loops through explicit IOS_CreateThread() calls. IOS stands for Internal Operating System-the notoriously secure, proprietary operating system developed by BroadOn that eventually powered the entirety of the Nintendo Wii’s background network processing.This source code confirms that BroadOn successfully prototyped and implemented the core foundations of the Nintendo Wii’s IOS directly onto the primitive Game Boy Advance processor years before the Wii even launched!This is completely corroborated by gba.tar, the massive 2.3 GB archive sitting next to it. Far from being a GBA SDK, gba.tar is actually an offline subversion depot (depot-offline/sw/) containing the entire finalized networking source code for TWL (Nintendo DSi) and RVL (Nintendo Wii) and the finished target IOS.Crucially, inside depot-offline/sw/common/lib/p2p/api/, the gba.tar Wii repository explicitly preserves vng_api.c. The VNG matchmaking and peer-to-peer networking API conceptualized in 2004 exclusively for the Game Boy Advance Netcard did not die with its cancellation.Instead, BroadOn took the underlying VNG Matchmaking topology and the rudimentary GBA IOS implementation, massively scaled them up, and integrated them directly into the Nintendo Wii and DSi base operating systems to power the es (eTicket/eShop) networking infrastructure. The cancelled Game Boy Advance online Pokémon project was literally the technological birthplace of Nintendo’s modern digital networking ecosystem.", "excerpt": "The netcard folder from the Gigaleak contains the documentation, SDKs, and design specifications for an officially scoped but ultimately cancelled online gaming peripheral for the Game Boy Advance. netcard The folder preserves gba.tar (a 2.3 GB toolkit archive) and nc_stuff.7z, but the most revealing contents are internal design documents written...", "tags": ["gba","leak","pokemon"], "image": "/public/generated/placeholders/netcard.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo Ninja Leak", "url": "/ninjaleak", "content": "The Ninja leak occurred on the 22nd December 2020 and is named after the contents containing information that prove the long-standing Nintendo “Ninja” myth.Including stalking and intimidation of a Nintendo 3DS developer who is well respected in the scene known as Neimod.Note that as Nintendo kept private information about this individual such as real name, address and parents information, it is not recommended to share this information, and none of that information will be in this article.Files leaked: NintendoSDK_fromSSD_IKEDA_20151124.zip - Old 2015 Switch SDK Documents.7z (901.8 MB) - Anti-piracy Related documents Secure.7z (570.2 MB) - Security related documentsDocuments.7zThe Documents archive contains exactly what it says on the tin, internal documents related to security of the 3DS, Switch and WiiU Amiibos.Root filesThe files at the root after extracting the directory are: AP紹介.pptx - Associated Press introduction ASSP - Empty folder BitLocker 回復キー 6668A7A8-9BEB-4525-9D1F-DF7614E02B3D.txt - BitLocker Drive Encryption Recovery Key CTR - Nintendo 3DS documents GlobalAPteam - Global Anti-piracy team presentations and meeting notes PCSG Switch - Switch security documents WiiU試遊台amiibo対応リスク.pptx - Presentation on risk of duplicating amiibo via WiiU セキュリティチーム運営 - Security team management files 暗号＆セキュリティ＆不正行為.pptx - Cryptography & Security & FraudAcronyms mentionedIn some of the presentation files a number of acronyms are mentioned, we will list what they mean here. ASIC - Application-specific integrated circuit HASP - Firmware Generation Tool HSM - Hardware Security Module (Signing Device) MITM - Man in the Middle Attacks NCL - Nintendo Central Location in Japan NTD - Nintendo Technology Development (North American Nintendo division) NUP - Nintendo Update - used to talk about the 3DS firmware version PSEG - ? PCSG - ?Security team management files (/セキュリティチーム運営)This is where the Ninja part of the name comes from, Nintendo has documented proof of stalking and intimidating consumers who managed to find any exploits for the 3DS.The root folder only contains one document called NXT1_revoke_toNishiurasan.pptx which is simply a diagram of the security mldel used on the 3DS.The folder is split into two sections: セキュリティ仕様書 - Security specifications プロジェクト - projectSecurity specifications (/セキュリティ仕様書)This folder contains a list of useful security specifications for various consoles and even android. This is to give the developers context as to what security systems are available.The files in this folder are: CTR - 3DS security specifications DRM - 3DS Digital Rights Management specifications DS - Nintendo DS specifications DSP_support_200_100903-internal - Documentation for the Nintendo DS Anti-Piracy tool DSProtect RFC 5756 - Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters.mht S2セキュリティリスク管理.docx - S2 Security Risk Management Doc S2セキュリティリスク管理.pdf - S2 Security Risk Management in PDF format S2セキュリティリスク表.xlsx - S2 Security Risk Table SSセキュリティリスク管理.docx - SS Security Risk Management TWL - Nintendo DSi Card specifications WiiU XBOX360 android マジコン - Magicon 新規 Microsoft Visio 図面.vsd 暗号一般 - General code3DS security specifications (CTR) 3チップ構成のCTRカード111226_2.doc CTR-ROM-IDフォーマット.xls CTR_Card_Memrory_SPEC20121212正式版.pdf CTR_GameCardEncription_MXIC.xlsx CTRソフトのデータ変換.xlsx NAND暗号111208.pdf S1 S2 media_binary.pdf バックアップメモリ ペアレンタルコントロール マスタリングツール 全体 外国人に説明するための資料_ctr_architecture_documents_0704_20133DS Digital Rights Management (/DRM) CTR_BroadOnF2F_MT_eFuse関連検討事項.lzh CTR_BroadOnF2F_MT_eFuse関連検討事項.xls CTR_Security.pdf DRM_Infrastructure_Overview.pptx DRM_Overview_20110615.ppt DRM_TitleDatabase_20110628_Final.ppt DRM鍵.vsd - DRM Key ES_Overview.pdf NIM_Overview_20110727_2.pptx Visio-マスタリング・OLSデータフロー_20100426.pdf - Mastering / OLS Data Flow_20100426 drm-module-image.pdf drmArch140324_disclosedToIAAB.pdf drmArch140324_disclosedToIAAB.pptx drmArch140402_disclosedToIAAB.pdf drmArch140402_disclosedToIAAB.pptx 新しいフォルダー - contains a diagram showing the security of the entire systemThe file drmArch140402_disclosedToIAAB.pdf is well worth checking as it is a diagram showing the entire security from game creation to game installing. It is also completely in english!Nintendo DS Security specificationsThis folder contains the following files: NORのNTR本体設定.pdf NORのNTR本体設定.xlsx NTRカード用ROM（TYPE2)要求仕様書(07-1-12a) NTRカード用ROM（TYPE2)要求仕様書(07-1-12a).zip NTRカード用ＲＯＭ(TYPE1)要求仕様書・セキュリティ省略版(07-1-12)b NTRカード用ＲＯＭ(TYPE1)要求仕様書・セキュリティ省略版(07-1-12)b.zip NTRメモリID管理表.xls バックアップメモリ仕様書DSProtect documents (DSP_support_200_100903-internal)DSProtect is a library that can help prevent Nintendo DS games from being illegally copied. This folder contains the documentation for it in japanese.This folder contains the following files: 200 Support_Manual_DSProtect.pdf - Documentation for DSProtectNintendo DSi Card Specifications (TWL)This folder contains the following files which all describe the Nintendo DSi Cards in different sizes (512M, 2G, 4G): TWLcard070724(512M、MXIC仕様).pdf TWLcard2G070916.pdf TWLcard4G080519.pdf TWLcard512M080530.pdfWiiUThis folder only contains a very brief diagram of the WiiU security model in both PDF and Visio formats.This folder contains the following files: 新規 Microsoft Visio 図面.pdf 新規 Microsoft Visio 図面.vsdXBOX360This folder contains the following files: Xbox360_MemoryHashingAndEncription.pdf 新規 Microsoft Visio 図面.vsdAndroidThis folder contains the following files: NetworkSecurityGuide1.pdf android_securecoding.pdf hmmail650_signed.exeMagicon (マジコン)This folder just contains a signle pdf file which is the documentation for the M25P10-A chip by NUMONYX.General Code (暗号一般)This folder just contains the RFC specification for RFC2313 in both english and japanese: rfc2313-Ja.txt rfc2313.txtProjects (/プロジェクト)The files in this folder are: Arch FANGATE - Vulnerabilities for the Nintendo NFC adapter codenamed “fangate” FANG検討 - FANG review (NFC Amiibo vulnerabilities) INDY検討 Knock_And_Talk_directcnotact NTR NewSwitch Niji - 3DS Zorro signature tool NorthPort - Nvidia Shield Android TV (foster) PUMP S1.5 SNAKE - Switch security Amiibo whiteCryption - security system コードレビュー - Code Review 新井さん下村さん案件 - Mr. Arai and Mr. Shimomura 汎用SoC - General purpose SoCArchThis folder contains the following files: Arch.pptx チート対策ガイド.pdf - Cheat Countermeasure Guide ネイティブアプリに対する攻撃と防御方法（外部用）.pdf - Attack and defence against native apps (external) ブレーンストーミング.txt - Brainstorming.txtFANGATEThis folder contains the following files: FANGATE.pptx WiiU試遊台amiibo対応リスク.pptx 新規 Microsoft Word 文書.docxFANG検討This folder contains the following files: 20120824.ppt 20120904.ppt DLPDFR009671_P1-136.pdf MR201301_NFC_Security.pdf RFC_3711.txt TLSに対するCBC攻撃.txt - CBC attack against TLS TagFormat.pptx Tagセキュリティ簡略図.pdf - Tag security simplified diagram Tag共通鍵生成方法案.pdf - Tag common key generation method proposal Tag共通鍵生成方法案2.pdf Tag共通鍵生成方法案3.pdf Tag共通鍵生成方法案4.pdf 新規 Microsoft Visio 図面.vsdINDY検討 ()This folder contains the following files: BROM GlobalPlatform IDクリエーター - ID Creator INDYセキュリティレビュー - INDY Security Review IRDプロジェクトへの人員配置_20131025a.xlsx - Staffing for IRD projects_20131025a STM-TEE SoC SoC進捗管理表121128.xlsx - SoC Progress Management Table Toronto Training ValidationSoftware Visio-互換セキュリティ.pdf - Visio-Compatible Security.pdf eFuse検討 - eFuse review memo_SoC_SHARP.txt カードIFファームウェアブート方式 - Card IF firmware boot method ゲームカード - Game card コピーIRDプロジェクトへの人員配置_20131025a.xlsx - copy of Staffing for IRD projects メインメモリセキュリティ.pdf - Main memory security 新規 Microsoft Excel ワークシート.xlsx 方法2_TWL互換2_TEG-CVer.vsd - Method 2_TWL compatible 2_TEG-CVer 次世代検討課題.txt - Next Generation Examination.txtProject Knock and Talk (Knock_And_Talk_directcnotact)Project Knock and Talk (K&T) also known as Belgian Waffle was an effort for Nintendo to stop the 3DS hacker known as Neimod.This folder contains the following files: 20130713175143854.pdf - Settlement agreement between Nintendo and Neimod Belgian Waffle - KT Debrief Next Steps.pptx Criminal Complaint (draft) 5 April 2013.doc Final Enforcement Proposal Neimod 4 5 13.doc FinalK&TProposalFlowChart.4.5.13.pdf - Flowchart for the project steps KandT結果共有.pptx - Details on the progress Neimod made with his hardware plus lego starwars exploit NDADraft4.5.13.docx - Draft version of Non-Disclosure Agreement PGPのしくみ.mht - How PGP works (Cryptography) - html file SSSPWN - Documents on the SSSPWN project by smealum TargetingHackerProcedure.pdf - Diagram showing the process of Knock and Talk TargetingHackerProcedure.vsd - Visio version of above ap_kt_discussion.15apr2013.key.pdf - presentation discussing other potential targets including geohot 報奨金制度 - Reward systemNintendo made an entire list of actions for approaching a 3DS hacker lol. https://t.co/B8CJzXpnSo— Forest of Illusion (@forestillusion) December 22, 2020NTRThis folder just contains a single document called 111027_Detection which is a spreadsheet of the Card ROM header values for each Card size, in Hex, Decimal and even binary!NewSwitchThis folder contains the following files: SecurityPORmeeting.pptx SecurityPORmeeting_GameCart.pptx SoC on_the_rotor_head.jpg セキュリティ設計検証 - Security design verification 極小署名 - Minimal signature3DS Zorro signature tool (/Niji)This folder contains the following files: CTR_MW-Zorro CTR_MW-Zorro_20150916alpha.zip CTR_MW-Zorro_20160122.zip CTR_MW-Zorro_alpha OPSSR_project.pptxNorthPortThis folder contains the following files: AP-114750851-080316-2251-1880.pdf プレゼンテーション1.pptx プレゼンテーション1.thmx - same as above but in different Powerpoint formatPUMPThis folder contains the following files: PUMP Security With Secure Zone.pdf PUMP Security Without Secure Zone.pdf 新規 Microsoft PowerPoint プレゼンテーション.pptx 新規 Microsoft Visio 図面.vsdS1.5This folder contains the following files: 160108_HS-SPIによるS1.5モード実装のご提案_ver1.00.pdf S1_5.vsd S1_5まとめ_20160411.pptxSwitch Security (/SNAKE)This folder contains the following files: HASPed SNAKEセキュリティ改善_20140423.pdf - SNAKE Security Improvement 2014/04/23 SNAKEセキュリティ改善概要.txt - SNAKE Security Improvement Overview readme.txt readme.vsd reserve.bin 新規 Microsoft Visio 図面.vsdamiiboThis folder contains the following files: _CATALOG.VIX amiibo-PKI.png amiibo-PKI.pptx ecqv-poc-v2 ecqv-poc-v2.zip ecqv-poc.zip sec4-1.0.pdf 新規 Microsoft PowerPoint プレゼンテーション.pptxwhiteCryption Security systemThis folder contains the following files: SKB.zip SKB_EvalSample.exe SKB_with_CP.zip SKB_with_CP_EvalSample.exe dataCode Review (コードレビュー)This folder contains a folder called データ書込みソフト_セキュリティホール確認用_20140509 (Data writing software For checking security holes) which contains the following files: CTR_TRIAL CTR_TRIAL.zip - zipped version of CTR_TRIAL HwCheck_Import HwCheck_Import.zip - zipped version of HwCheck_Import新井さん下村さん案件This folder contains the following files: FSL_Roadmap update_20140716.pdf IMX6DQ6SDLSRM.pdf IMX6DQRM.pdf NDES-56759045-250814-1402-614.pdf i MX7 Security Document 8-5-2014.pdf 必要なセキュリティ要件.pptx - Required security requirements 必要なセキュリティ要件.pptx.gpg - GPG version of above 新しいテキスト ドキュメント.txtGeneral purpose SoC (汎用SoC)This folder contains the following files: ContentsDistributionDesign.png GameSecurity-j.pdf Mobile App Integrity Protection Handbook.pdf NTD_20140424.txt img-X10175644.pdf 新しいフォルダー - contains pdf of Mobile App Integrity Protection Handbook in japanese by ARXAN 新規 Microsoft Visio 図面.vsd 汎用SoC.pptxNintendo 3DS (/CTR)The files in the folder are: 32C3 - screenshots from the Breaking the 3DS 32C3 talk win32diskimager-v0.9-binary.zip - Image Writer for Windows from SourceForge (LGPL license) 新しいフォルダー - Translated to new folder - duplicate of 32C3 folder contents 新しいフォルダー (2) - another new folder simply containing 32c3.txtMost of the files in this folder are screenshots from the 32C3 talk by Smealum, derrek and plutoo.Also contains the 32c3.txt document in japanese which contains the main hacks and notes on when they will be patched in the next 3DS update (NUP).3DS /PCSGThe files in this folder are: AP-20151218-Boot9Dumping-140316-1457-2496.pdf - Document describing a security flaw to dump Boot9 on the 3DS using an FPGA AP-AES_SLOT.pdf - AES SLOT KEY exposure status AP-NTRCARDHAX.pdf - document describing the memory overflow in process9 aka “NTRCARDHAX” AP-memchunkhax2.pdf - 3DS security flaws aka “memchunkhax2” スケジュール - Schedule of a trip to the US for derrekThese documents are good at explaining 3DS exploits that Nintendo were aware about in 2015-2016.Note that most of this information is available on the internet already, just google NTRCARDHAX or memchunkhax2.There is an excellent presentation on media.ccc.de:media.ccc.de - Console HackingSwitch Documents (/Switch)The files in this folder are: LatourCrypt修正3.pdf - LatourCrypt Fix 3 (Diagram of Switch hardware security) Switch開発カードレビュー.pptx - Switch Development Card ReviewThe Development Card review Powerpoint presentation is very interesting it provides Attack scenarios for how hackers would get around the security of the NAND storage.Development card and diagrams to show the security to prevent Man in the Middle attacks (MITM).Global Anti-Piracy Team (/GlobalAPteam)The files in this folder are: GlobalAPteamKickoff.pptx - Presentation on the introduction to a global Anti-Piracy team NTD - Nintendo Technology Development documents security meeting with ntd 20170418.pdf - Mind map of meeting with japan and NA teams security meeting with ntd 20170419.pdf - Another Mind map of meetingThe GlobalAPteamKickoff.pptx presentation is interesting (if you can get over the terrible spelling) as it covers the goals of the Anti-Piracy team which has members from all 3 Nintendo studios (NTD, NERD and NCL).The mind maps are also worth a look as they highlight the problems a big company like Nintendo can have allocating time for security issues. They are not given as much time compared to brand new features and seems to be no full-time security experts at all.NTD Exploit presentations (/GlobalAPteam/ntd)In this folder we have some presentations that are both worth a read if you are interested in exploits: NTD-security-slides-v2.pptx - Really interesting presentation of the vulnerabilities of ARM7 BPMP and others Rand_Exploit_Raptor.pptx - Presentation from NVIDIA on the Random Number bug for Switch (December 2016)Secure.7zWhen the archive has been extracted it contains the following contents: CTR-ROM-IDフォーマット.xls - 3DS ROM format based on the maker of the ROM (e.g Sandisk, KMC..) CTRカードについて.ppt - PresentationAbout CTR card hardware GCIP_RTL - Switch Game Cartridge hardware simulator software Lotus3Brom NewFormat - 3DS CCI Format ROM-ID_100421okisemi.xls - 3DS ROM forwat for OKI Semiconductor chips Swtich ウェハ取れ数計算_140728.xls - Wafer removal number calculation カード関連仕様書 - Card-related specifications **マリオカート8のROM容量の内訳と解像度比からサイズ縮小を検討.pdf - Mario Kart 8 ROM capacity 情報開発見積もり** - Information development estimate 鍵 - Card key filesSwitch Game Cartridge IP (/GCIP_RTL)This folder contains files for both the Game Cartridge chips known as MontBlanc and the Design Simulation Model (DSM) for the ARM Cortex M4.Files in this folder are: Cortex_M4_DSM_license_NTD - contains license file for the Cortex M4 Cortex_M4_DSM_license_NTD.zip - archive of the Cortex_M4_DSM_license_NTD folder stmicroelectronics_montblanc_vp_2.4.1-GC_NCL stmicroelectronics_montblanc_vp_2.4.1-GC_NCL.tar.gz - archive of the stmicroelectronics_montblanc_vp_2.4.1-GC_NCL folderThe Mont-Blanc GC Virtual Platform by STMicroelectronics was used by Nintendo for simulating Game Cartridges (GC).Since these documents were created in 2014 it is very likely that this is for the Nintendo Switch.Switch Game Card Lotus3 Boot ROM code (/Lotus3Brom/src)This folder contains the source code for the Game cartridge BootROM firmware called “Lotus” version 3 written by MegaChips Corporation in 2015.Files in this folder are: crypt - contains PKCS1_Decode in pkcs1.c driver - contains the main source code modules main.c - main starting point for boot ROM mpu.c - Main Microprocessor code mpu.h - header for mpu.c mpu_reg.h - register for MPUDriver Source filesThe driver sub folder contains the main code for each module that makes up the entire Game Cartridge BootROM.These source files look like they have been generated from a hardware description language such as Verilog, and contain “register” files which are common in HDLs. Name Description aes.c Advanced Encryption Standard (AES) module aes.h Advanced Encryption Standard header aes_reg.h Advanced Encryption Standard register bol.c Boot Loader driver bol.h Header file for Boot Loader driver bol_reg.h Boot Loader Register copy.c memory copy code (Peripheral to Peripheral) copy.h   ctl.c Controller module ctl.h Header for Controller module ctl_reg.h Controller module register dma.c Direct memory access module dma.h Direct memory access header dma_reg.h Direct memory access register emmc.c embedded Multi-Media Controller module emmc.h embedded Multi-Media Controller header fifo.c First In first Out module fifo.h First In first Out module header fifo_reg.h First In first Out module register lts3.h Main lotus3 header otp.c   otp.h   otp_reg.h   rnd.c Random number module rnd.h Random number header rnd_reg.h Random number register rom.h ROM data header rom_reg.h ROM data register rsa.c Rivest-Shamir-Adleman (RSA) encryption module rsa.h RSA header rsa_reg.h RSA register sha.c Secure Hash Algorithm module sha.h Secure Hash Algorithm header sha_reg.h Secure Hash Algorithm register startup_lts3.s   wgn.c   wgn.h   wgn_reg.h   3DS CCI format (/NewFormat)This folder contains 3DS Cart images (.cci) which have an unknown purpose, probably just to show off the NCSD file format.Files in this folder are: Invalid-PROD0.cci Invalid-PROD0.cci.bak - old version of Invalid-PROD0.cci Invalid-PROD1.cci Invalid.cci.bak demo1-11_0-PROD0.master.cci demo1-11_0-PROD1.master.cciSwitch private key certificates (/Swtich)Files in this folder are: AsicPrivKey - Private key for Game Card BootRom CardHeader - Tool to build Game Cards CardKensa - Test Card certificates DevL3Cert - Level 3 Dev game card certificate FwSigner - Tool for signing the Game card firmware Package_20150902 aes_ccm - code for AES encryption in CCM mode aes_ccm_old - old code for above cardheader_gen - script for generating card header binary data(/Swtich/Package_20150902)This folder contains documentation from MegaChips about their simulation environment for Lotus game cards.Files in this folder are: LotusメモリエミュレーションFPGAボードPC用ライター仕様書 - Lotus Memory Embroidery FPGA Board PC Writer Specifications MPTool_NCL_v3.0 - Mass Production Tool version 3 by MegaChips T1_FPGAボード納品物リスト - T1_FPGA Board Delivery List T1セキュリティ用メモリエミュレーション FPGAボード仕様書 - Memory Embroidery FPGA Board Specification for T1 SecurityThe pdfs in this folder show how to use the Mass Production Tool (MPTool) to create Game Cards.Card Key /鍵/カード鍵not sure exactly what these certificate keys are for but they are related to either Switch or 3DS Game Cards.Files in this folder are: S1ハードウェアキー - S1 hardware key S2用秘密鍵 - Private key for S2 ユニークIDの鍵 - Unique ID keyInformation development estimate )/情報開発見積もり)Files in this folder are: SNAKE開示者のみ公開_MTB開発ユニット_電力や熱に関するまとめ_20140822.pdf - Power and Heat (requires SNAKE disclosure) レビュー後公開_MTB開発ユニット_Switch_熱予算の考え方_20140822.pdf - Thermal Budget for hardware 非公開_マリオカート８処理削減リスト_20140822.xlsx - Mario Kart 8 reduction list 非公開_改訂版_マリオカート8のROM容量の内訳と解像度比からサイズ縮小を検討.pdf - Size reduciton of Mario Kart 8Only certain members of staff are given disclosure for certain projects and it seems SNAKE was the name of the disclosure for the Switch.These documents are very low level dealing with the switch hardware power and heat.NintendoSDK_fromSSD_IKEDA_20151124.zipThis folder contains the following files: NintendoSDK パッケージを取ってきた元.txt - just links to internal Nintendo sites like Teamcity 初めて用のセット - Initial SetupInitial Setup files (/初めて用のセット)This folder contains the following files: HostBridgeController_0.3.3.0 OasisSetup.0.6.0.12639.msi OasisTMSetup.0.6.0.12639.msi Windows用ドライバ - Driver for Windows kernel.img siglo_boot write-emmcNot quite sure what these files are used for or what Oasis is.Nintendo Switch SDK from 2015This folder contains the following files: Build Common Compilers Documents Externals Include Libraries NintendoSdkRootMark Resources Revisions Samples Sources ToolsThese folders will be documented later when we add Nintendo switch to the site.", "excerpt": "The Ninja leak occurred on the 22nd December 2020 and is named after the contents containing information that prove the long-standing Nintendo “Ninja” myth. Including stalking and intimidation of a Nintendo 3DS developer who is well respected in the scene known as Neimod. Note that as Nintendo kept private information...", "tags": ["leak","ds","3ds"], "image": "/public/images/leaks/Nintendo Ninja Leak.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "All Nintendo Leaks", "url": "/nintendoleaks", "content": "Nintendo has has many data leaks in the past, but none as huge as the original Oman Archive of the late 90s or the Gigaleaks of 2020. This post is a reference point to help people catch up on any content they might have missed, each leak has its own page with much more detail about the contents of the archives.We only list leaks that have development related content, mainly source code as that is the main focus of this site.If you are interested in the full timeline of everything that has been ever released check out the Gigaleak Timeline on Protocrystal:Gigaleak TimelineOman Archive (1999)The “Oman Archive” was a leak of Nintendo Technical documents from a source inside SGI in late 1999. It was uploaded to the internet under the name oman.rar but has since been repackaged into multiple other archive formats.An updated version of the Oman Archive was released in 2020 at the same time as the Gigaleak, another Nintendo Leak which includes N64 content.Files Leaked: oman.rarWe have a post on the contents of the archive here: Oman Archive - N64 Leak by SGI employee For more information on the Oman Archive check out this post. Pokemon Leak (April 2020)In April 2020 the source code for Generation one and two of the Pokemon games was released. A Page discussing this leak will be available some time in the future.Files Leaked: OriginalSouce.zip - Pokemon Blue and Yellow source code (password: poke1024) (also released in a file called osrc.zip Gen2.7z - Source code for Pokemon Gold/Silver, released on 24th April 2020We have a post on the contents of the OriginalSouce.zip archive here: Pokemon Original Source Code Leak For more information on the Pokemon leak check out this post. BroadOn Archive (2nd May 2020)In early May 2020 a leak of Nintendo Source Code hit the popular image board 4chan. The material contained in this leak was obtained by a young hacker known as Zammis Clark.Files leaked: unsorted.zipWe have a post on the contents of the archive here: BroadOn Archive - Nintendo May 2020 Leak (4Chan) For more information on the Paladin leak check out this post. Citrus Leak (May 24th 2020)The page on the Citrus leak is currently under development but here is a list of files that were included in the leak: ctr.7z ctr-etc.7z svn_v1.068.zipGigaleak (24th July 2020)On the 24th of July 2020, the mother-load (2GB) was uploaded to a thread on 4chan and was dubbed the Gigaleak. This is a continuation of the leaks that were obtained from a iQue/BroadOn/Routefree hack earlier in the year.Files Leaked: 20100713cvs_backup.tar.7z - CVS Repo Dump of projects such as ensata netcard.7z - Game Boy Advance Peripheral cgb_bootrom_trunk.zip - Game Boy Color Boot ROM pokemon-checkout.7z agb_bootrom_trunk.zip - Game Boy Advance Boot ROM other.7z - Source code for DMG, GBC, SNES gamesWe have a post on the contents of the archives here: Gigaleak - SNES Source Code Leak For more information on the original Gigaleak check out this post. Gigaleak 2 (25th July 2020)On the 25th of July 2020, the day after the Gigaleak, its sequel Gigaleak 2 was uploaded to a thread on 4chan. This is a continuation of the leaks that were obtained from a iQue/BroadOn/Routefree hack earlier in the year.Files Leaked: bbgames.7z (just contains bbgames.tar)We have a post on the contents of the archive here: Gigaleak 2 Electric Boogaloo - N64 Source Code Leak For more information on the second Gigaleak check out this post. Emerald Leak (2nd September 2020)The Emerald leak occurred on the 2nd of September 2020 and included about 700MB of content related to the Wii and gamecube. So this would not quite qualify as a “Gigaleak” but it was definitely from the same source as the Gigaleak.Files Leaked: emeralds.7z (742MB)We have a post on the contents of the archive here: Nintendo Emerald Leak For more information on the Emerald leak check out this post. Paladin Leak (30th September 2020)The Paladin leak occurred on the 30th of September 2020 and included about 2.4GB of content related to the Nintendo IRIS and Pokemon spinoffs such as Ranger and Mystery Dungeon.Files Leaked: paladin.7z (2.44GB)We have a post on the contents of the archive here: Nintendo Paladin Leak For more information on the Paladin leak check out this post. Unexpected Leak (20th July 2021)After more than half a year without any Nintendo leaks, on 20th July 2021 even more goddies were release to the internet from the archive of Zammis Clark.Files Leaked: datasheet.7z - Low level hardware information for Switch Game cards and Gamecube memory cards DIAG4RVL.7z - just contains DIAG4RVL.zip DIAG4RVL.zip -Contains the source code for A Wii/Gamecube Diagnostic tool know as DIAG4 pmEME_US20050207.7z - Pokemon Emerald Localisation from Japanese to Other languages information ique_player_common_tickets.7z - Collection of 86 tik and tikmd files for the iQue player (N64 version) haishin_20130912.zip - Pokemon X/Y Distribution event Software bb2.7z - Information and Verilog source code for the BroadOn Board 2 a planned Chinese version of the gamecube gen4_era_protos.7z - Diamond and perl prototype roms and the source code teru-sama_mail_2006.7z - A dump of the personal email inbox of Murakawa TsushinThe main files inside DIAG4RVL.zip was the source code to a DVD that is used to test all the hardware components of the Gamecube/Wii’s hardware. This was used throughout the development of the console and also for fixing retail units. Nintendo Wii Diagnostic Disc Source Code For more information on the contents of the DIAG4RVL archive check out this post. Also inside DIAG4RVL.zip was the source code to the SDK provided to Nintendo by ArtX/ATI when developing both the Gamecube and Wii graphics hardware, we have a post covering it linked below. ATI Low Level Wii SDK For more information on the leaked low level ArtX/ATI SDK check out this post. For more information on the rest of the files leaked on the 20th July 2021 check out our post: The Unexpected 2021 Nintendo Leak For more information July 2021 leak check out this post. ", "excerpt": "Nintendo has has many data leaks in the past, but none as huge as the original Oman Archive of the late 90s or the Gigaleaks of 2020. This post is a reference point to help people catch up on any content they might have missed, each leak has its own...", "tags": ["leak","nintendo","3ds","gba"], "image": "/public/images/leaks/All Nintendo Leaks.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo Lot Check ROM Leak", "url": "/nintendo-lot-check", "content": " Since Nintendo controls manufacturing of all official games they have a process called Lot Check that ensures the games quality before manufacturing. Every game ever officially released for their platform has had to go through the Lot Check process in order to achieve the Nintendo Seal of Quality. Lot Check ListsIn the Pokemon Leak on the 10th of April 2020 a bunch of excel spreadsheets were uploaded into the /misc folder, these contained the full list of all games that have gone through the Nintendo Lot Check process for most systems up until the Nintendo DS. Name Description MIN_data.xls Pokemon Mini Lot Check AGB_data.xls Game Boy Advance Lot Check CGB_data.xls Game Boy Color Lot Check DMG_data.xls Game Boy Lot Check FileList.csv NES Lot Check with less columns HNPdata_List.xlsx NES Lot Check NTR_data.xls Nintendo DS Lot Check NUD_data.xls Nintendo 64DD Lot Check NUS_data.xls Nintendo 64 Lot Check S-ROY_data.xls SNES late release games with Royalties SHNP_data.xls SNES Lot Check TWL-DW_data.xls DSiware lot Check TWL-Hyb_data.xls Nintendo DSi Hyb? lot Check TWL-Ltd_data.xls Nintendo DSi Lot Check VUE_data.xls Virtual Boy Lot Check The GigaLeak (NES Lot Check released)As part of the Gigaleak the full set of official Nintendo Lot Check ROMS were distributed online on 4Chan. They were located in an archive called Other.7z and the sub archive Famicom_NES.7z.Contents of Famicom_NES.7zWhen extracted from the archive, two folders are created: HVC - Japanese Famicom ROMS NES - US Nintendo Entertainment System ROMSNote that in the NES Lot Check list (HNPdata_List.xlsx) it had 3 different codes, HVC, NES and PAL, but all the PAL content was not leaked during the Gigaleak.HVC stands for Home Video Computer and was the codename for the Famicom during development, this is also the product code for all Japanese games.ROM FormatThe ROMS contained in the 2 main folders are not standard, e.g they are not .NES files and don’t have an iNES header. You can not just rename to .nes and run them in an emulator.If you look at the internals of NES cartridge you will notice that there are in fact multiple ROM chips on board, known as PRG for Program code and CHR for Character Tiles (Graphics).This is important as when manufacturing the cartridge Nintendo would need to have the data for both chips and thus the ROMS available in the Lot Check are split into these two parts.In theory you could create an iNES header and merge the 2 parts into a .NES rom that would run in an emulator, but you might as well just get the rom elsewhere. It is only worth doing this for games that have never been dumped before, which is the topic of the next section.The name format is:{HVC or NES}{Abbreviation}{Revision_version}{P or C}.{Software_Number}So for example for Kirby’s Adventure its Abbreviation is “KR”, it has 2 revisions of the program so you can choose either 0 or one for the revision version.System = \"NES\"Abbreviation = \"KR\"Revision_version = 0Software_Number = '073'// ResultPRG_FileName = System + Abbreviation + Revision_version + \"P.\" + Software_Number // NESKR0P.073CHR_FileName = System + Abbreviation + Revision_version + \"C.\" + Software_Numbe // NESKR0C.073You can find the Abbreviation, revision and software numbers in the HDPdata_List spreadsheet.Un-released NES ROMSAs the Nintendo Lot Check process is only done during the final stages of development, don’t expect any beta or prototype games to be here.However there is an occasional game that made it all the way to Lot Check phase but was then deemed too costly to physically manufacture. It is these games that make the Lot Check leak worthwhile.I cross-referenced the NES bank dumps from today's leaks, against the known collection of NES roms (No-Intro 2017-06-18). Looks like there's a few previously unknown roms, including a second revision of the Nintendo World Championship cart! pic.twitter.com/tFol8CxyLH— ラ0.F (@MrCheeze_) July 25, 2020New Revision ROMSAll computer programs have bugs, and NES games are no different, in some cases there were new patched versions of a game released with a higher revision number. A few of these never got physically manufactured such as 1: Bridgestone Cycle: Radac Tailor-made (Japan) Dragon Slayer Jr.: Romancia (Japan) Family Computer Othello (Japan) Nintendo World Cup (North America) Roger Clemens’ MVP Baseball (North America)the mystery roms have been discovered pic.twitter.com/tY5sH5yfeq— I..A..N..S (@IANSYT) July 27, 2020Famicom Disk System Lot CheckOn the 30th September 2020 the Famicom Disc System Lot Check ROMS were leaked to the public as part of the Paladin Leak. The archive containing these ROMS was called FMC_DISK.7z and was included in the paladin.7z main archive.It is important to know a few things about the Famicom Disk System before proceeding, the disks could have multiple sides (2 of course) and has different content on each side. Nintendo used a format called RD* to store these games and had a different file for each side, so if a game has two sides then there would be both an RDA and RDB file (for side A and side B respectively).Contents of FMC_DISK.7zWhen the FMC_DISK.7z archive has been extract it creates the following files and folders: 110803HNPdata.xls - NES Lot Check list (from 3rd August 2011) DiskWriterSoftPak_ZEL.txt - Notes about the Zelda EPROM Converter DiskWriterSoftPak_ZEL.zip - Source code and Zelda EPROM result FMC_DISK.zip - Zip of the disk_image folder (password protected) FMCｄｉｓｋsystem_ead_070726.xls - Lot Check list of Famicom Disk System Games (from 26th July 2007) FMCｄｉｓｋsystem_ead_160519.xls - Lot Check list of Famicom Disk System Games (from 19th May 2016) disk_image - ROMS for each of the sides (A/B) of the disks disk_labels - photographs of each of the master disks that was dumped readme.txt - notes about the files in this folder, created for Wii Virtual Console tool - contains a tool to convert RDA/RDB to FDS format (rdafds.exe)The readme.txt file is really interesting as it mentions converting side A and side B of the Disk to a format called QD, which is basically both rda and rda files concatenated together.Presumably the D in both file extension formats stands for Disk, but it is unclear what the Q stands for or even the R in RDA/RDB.RDA to FDS Converter tool (rdafds)This is a tool that converts from the Nintendo RD* format for Disk System games to the iNES FDS so that it can be emulated on a PC. It seems that nintendo were using an NES emulator to test these games before the virtual console versions were available.If you are interested in converting the RD* files located in this archive then you can use the rdafds.exe executable located in the tool folder to do the conversion.Zelda Disk Version (DiskWriterSoftPak_ZEL.zip)It seems that Nintendo had trouble getting any data from the Master Disk for Zelda so they asked Mr. Tomohiro Kawase who managed to get the data from an EPROM (SQCD?).It seems they needed to create a tool called scattoqd.exe to convert the resulting EPROM data (called SCAT for some reason?) to the Virtual Console QD format. The source code is also available for this tool under a single C++ source file called scattoqd.cpp.The result is in the zip archive under the name 007_FMC-ZEL-0-1.qd, as mentioned before the Virtual Console (QD) format is just RDA and RDB concatenated together, so you could split it up fairly easily.Unreleased Famicom Disc System GamesThanks to MrCheeze_ over on twitter we have a list of games that do not match any previously released Game Codes, these games are: 064 - BAN-UL1-0-0 - Ultraman - Kaijuu Teikoku no Gyakushuu 070 - SCO-MEA-2-0 - Michael English Daibouken (Sample) 085 - FMC-ON1-3-0 - Famicom Mukashi Banashi - Shin Onigashima 086 - FMC-ON2-0-0 - Famicom Mukashi Banashi - Shin Onigashima (Disk 2) 143 - NDS-PAC-1-0 - Pac-Man 145 - NDS-DIG-0-0 - Dig Dug 146 - NDS-DD2-0-0 - Dig Dug II 164 - FSC-FTAJ-1-0 - 野村のファミコントレード (Nomura NES Trade) 165 - FSC-FTEJ-1-0 - 野村のファミコントレード（デモ用）(Nomura’s NES trade (for demo)) 166 - FMC-KMAR-0-0 - Kaettekita Mario Bros. (translation: Come back Mario Bros) 174 - FMC-BFD-1-0 - バルーンファイト (Balloon fight) 180 - FMC-GOD-0-0 - 五目ならべ (Five eyes) (Gomoku Narabe Renju) 194 - SFL-TMG-1-0 - ザ·マネーゲーム (The Money Game) 195 - PAC-KTD-1-0 - Kattobi! Warabe Ko 201 - BAN-SG2-0-0 - SDｶﾞﾝﾀﾞﾑﾜｰﾙﾄﾞ ｶﾞﾁｬﾎﾟﾝ戦士 SCRAMBLE WARS ﾏｯﾌﾟｺﾚｸｼｮﾝ (SD Gundam World Gachapon Warrior SCRAMBLE WARS Map Collection) 210 - FSC-FTBJ-1-0 - 野村のファミコントレード (Nomura NES Trade)Some of the names for the games were found in the MAME source code, so not completely unknown ROMS 2.of particular note are the Nomura NES Trade ROMS which were used to trade Stock with the Japanese bank Nomura.The format of each Games product code is as follows (example is for Bandai’s Ultraman):Publisher = \"BAN\"Abbreviation = \"UL1\"Revision_version = 0Unknown = 0Software_Number = '064'// ResultSIDE_A_FileName = Software_Number + \"_\" Publisher + \"-\" + Abbreviation + \"-\" + Revision_version + Unknown + \".rda\" // 064_BAN-UL1-0-0.rdaSIDE_B_FileName = Software_Number + \"_\" Publisher + \"-\" + Abbreviation + \"-\" + Revision_version + Unknown + \".rdb\" // 064_BAN-UL1-0-0.rdbThe Publisher codes used for the above files are as follows: BAN - Bandai KDS - Konami FSC - Nintendo FMC - Nintendo NDS - Namco PAC - Pack-In Video SCO - Scorpion Soft SFL - SofelGomoku Narabe Renju 五目ならべ@LuigiBlood already documented the unreleased FDS port of Balloon Fight. I think this is another unrelease FDS port of "Gomoku Narabe Renju", Nintendo's Famicom version of Go. pic.twitter.com/PAhjtBW8fJ— ラ0.F (@MrCheeze_) September 30, 2020Balloon FightI've never seen Balloon Fight on FDS, ever pic.twitter.com/NACIXI3nCP— LuigiBlood (@LuigiBlood) September 30, 2020Game Boy (DMG & GBC) Lot CheckThe Game Boy Lot check including both original and Color games was released to the public on the 9th of September as part of the Platinum Leak. The content was available inside the platinum.7z file in an archive called dmg_sgb.7z.Contents of dmg_sgb.7zThere are two folders at the top level of the archive which are: DMG - lot Check ROMS are in here SGB - Super Game Boy BIOSFor documentation on the SGB folder checkout the Cutting Room Floors article on it: Proto:Super Game Boy - The Cutting Room FloorDMG FolderThe DMG (Dot Matrix Game) folder actually also contains GBC Roms too, it has the following folders in it: 001~500 - first 500 games (.001 to .500) 501~@00 - second 500 games (.501 to .@00) @01~E00 - next 500 games (.@01 to .E00) e01~j00 - next 500 games (.e01 to .j00) J01~O00 - next 500 games (.j01 to .O00) TestPRG - Test programs internal to Nintendo (MBC5 tester) CGB - Game Boy color roms, also split into 2 folders of 500 MBC3_CGB - Documentation for Memory Bank Controller 3 for the Color Game Boy NG - ? POOL - ? KENSA - Test Games (KENSA is Japanese word for test/inspection/examination.)The games are numbered based on when they came into the Lot Check process so release dates can vary.Not that because they use a 3 digit extension for the number, when it reached .999 it had to start using the alphabet as the first character, counting from @ to the letter O. The @ symbol comes before A but it is unclear why they did this, maybe to give an extra letter incase they ran out, but surely they would do that at the end after Z.The NG folder contains games: One Piece (J) Yu-Gi-Oh (EU) Yu-Gi-Oh (FR) Wendy Der Traum Yon Arizona (GER) Watashi no Restaurant (J) Kanji Boy 3 (J) Tonka Construction Zone (U) Komugi-Chan no Cake o Tsukurou! (J)The POOL folder contains games such as: Edd the Duck CutThroat Island (U) NFL Quarterback Club ‘96 US Alien Games 2044 AD (U)Un-released Game Boy ROMSAs the Nintendo Lot Check process is only done during the final stages of development, don’t expect any beta or prototype games to be here.However there is an occasional game that made it all the way to Lot Check phase but was then deemed too costly to physically manufacture. It is these games that make the Lot Check leak worthwhile. Unlike the NES Lot Check Leak, for the Game Boy there was a plethora of previously un-released games in the Lot Check set!All Un-released and Un-dumped DMG ROMSThe table below contains all the previously unreleased ROMS for the original Game Boy (DMG). Some are from cancelled games, unreleased localisations and others are games that made it to retail but have never been dumped or released online. Name Description 10-Pin Bowling (USA).gb Previously un-dumped Aguri Suzuki F-1 Super Driving (Japan).gb Previously un-dumped Alien Games (USA).gb Cancelled Game All Star Tennis 2000 (AZTX) (Rev 0).gb Never released in AZTX? All Star Tennis 2000 (USA) (Rev 0).gb Never released in USA Asterix (USA).gb Never released in USA Baby’s Day Out (USA).gb Cancelled Game 3 Bakusou Senki Metal Walker GB - Koutetsu no Yuujou (Japan) (Rev 1).gb New Revision Beethoven (USA).gb Previously un-dumped Berlitz German Language Translator (USA, Europe).gb Previously un-dumped Berlitz Japan Language Translator (USA, Europe).gb Previously un-dumped Bloomland.gb Never released Bobby’s World (Europe) (Rev 0).gb Never released 4 Bobby’s World (USA) (Rev 0).gb Never released 4 Calculator-0.7.gb Never released Card Games (USA).gb Never released in USA Castelian (Japan).gb Previously un-dumped Castle Quest (USA).gb Never released in USA Chuugaku Eijukugo 350 (Japan).gb Previously un-dumped Chuugaku Eitango 1700 (Japan).gb Previously un-dumped Cutthroat Island (Japan).gb Never released in Japan Dirty Racing (USA).gb Never released in USA Disney’s Mulan (USA).gb   Donkey Kong Land 2 (Japan).gb Game Boy Color re-release Doomsayer - A Heroes Crusade (USA).gb Previously un-dumped Dragon Dance (Europe) (Rev 0).gb Was released for Game boy Color instead Dragon Dance (USA) (Rev 0).gb Was released for Game boy Color instead Dragon Quest Monsters - Terry no Wonderland (Japan) (Rev 1).gb Previously un-dumped Dungeon Savior (Japan) (Rev 1).gb New revision Edd The Duck.gb New never-released game based on Baby T-rex Eurosport XS Racing (Europe).gb Never released F1 Challenge (USA).gb Never released Fastest Lap (USA).gb Previously un-dumped Flappy Special (USA).gb Never released in USA G1 King - 3 Biki no Yosouya (Japan).gb Never released GB Slam Dunk (Japan).gb Released as Slam Dunk instead Gakkyuu Ou Yamazaki (Japan).gb Previously un-dumped Game Boy Gallery 2 (Japan).gb Previously un-dumped Garfield Labyrinth (USA).gb This was released as The Real Ghostbusters in North America Instead Gargoyle’s Quest II - The Demon Darkness (Europe).gb Never released in Europe Gargoyle’s Quest II - The Demon Darkness (USA).gb Never released in USA Golf King (Europe).gb Never released Golf Robot (USA).gb Never released Hammerin’ Harry - Ghost Building Company (USA).gb Never released in USA Hello Kitty - PocketCamera (Japan).gb Never released Hello Kitty’s Cube Frenzy (Europe).gb Never released in Europe Hexcite (Europe).gb Previously un-dumped Home Alone 2 - Kevin’s Dream (USA).gb Never released Hudson Hawk (Europe).gb Never released in Europe Hyper Lode Runner (Japan).gb Previously un-dumped Itchy & Scratchy - Miniature Golf Madness (USA).gb Previously un-dumped Jeep Jamboree (USA).gb Previously un-dumped John Madden (USA).gb Never released Jungle Strike (USA).gb Previously un-dumped KICK ATTACK (Japan).gb Never released in Japan Kaseki Reborn (Japan) (Rev 1).gb   Kawa no Nushi Tsuri 4 (Japan) (Rev 1).gb New revision Klustar (Japan).gb Never released in Japan (USA and Europe only) Konchuu Hakase 2 (Japan) (Rev 1).gb New revision LOPPI-KAN1 (Japan) (Rev 1).gb ? LOPPI-KAN2 (Japan) (Rev 1).gb ? LOPPI-KAN3 (Japan) (Rev 1).gb ? Legend of the Sea King GB (USA).gb Never released in USA Lunar Chase (USA).gb Never released Mini Putt (Europe).gb Never released in Europe (Japan exclusive) Mini Putt (USA).gb Never released in USA (Japan exclusive) Momoiro Zousan (Japan).gb Never released NBA In The Zone (USA).gb Released for Game Boy Color NFL Quarterback Club 96 (Japan).gb Never released in Japan (USA and Europe only) Nanonote (Japan) (Rev 1).gb New revision Nemesis (USA) (Rev 1).gb New revision Nick Faldo Championship Golf (USA).gb Never released Ninja Spirit (Europe).gb Never released in Europe Ninja Spirit (USA).gb Never released in USA One Piece - Maboroshi no Grand Line Boukenki! (Japan) (Rev 0).gb New revision One Piece - Maboroshi no Grand Line Boukenki! (Japan) (Rev 1).gb New revision Oni 4 - Kishin no Ketsuzoku (Japan) (Rev 1).gb Previously un-dumped POWERPAWS (USA) (P4X).gb Released as Cat Trap POWERPAWS (USA) (PMX).gb Released as Cat Trap Pac-Man (USA) (Rev 0).gb New revision Pac-in-Time (Europe) (Rev 1).gb New revision Palamedes (USA).gb Never released in USA (Europe and Japan only) Pang (Europe).gb Previously un-dumped Pocket Golf (USA).gb Never released in USA (Japan exclusive) Pokemon Picross (Japan).gb Unreleased Popeye (USA).gb Never released in USA (Japan exclusive) Prince of Persia (Japan).gb Previously un-dumped Pro Champ Fishing (Europe).gb Never released in Europe Puchi Carat (USA).gb Never released in USA Purikura Pocket 3 (Japan).gb Previously un-dumped Puzznic (USA).gb Never released in USA (Japan exclusive) R-Type II (Europe).gb Previously un-dumped Rap Quest (USA).gb Never released Robopon - Star Version (USA).gb Never released Robot Ponkottsu - Sun Version (Japan) (Rev 0 Sample).gb Never released sample Rockboard (Japan).gb Never released SINGER-2 (Europe) (En,Fr,Es,Pt).gb Never released SINGER-3 (Europe) (En,De,It,Nl).gb Never released Sei Hai Densetsu (Japan).gb Previously un-dumped Shanghai Pocket (Rev 0).gb New revision Shanghai Pocket (Rev 1).gb New revision Shikakui Atama wo Maruku Suru - Nanmon no Shou (Japan).gb Never released Space Date (USA).gb Released as “Out of Gas” instead Space Invaders (USA).gb Previously un-dumped Speedball 2 - Brutal Deluxe (Japan).gb Previously un-dumped Speedy Gonzales (Japan).gb Released as Soreyuke! Speedy Gonzales in Japan Star Trek - The Next Generation (USA).gb Previously un-dumped Stargate (Japan).gb Never released in Japan Super James Pond (USA).gb Never released in USA (Europe exclusive) Survival Kids 2 - Dasshutsu!! Futago Shima! (Japan) (Rev 1).gb New revision Sutte Hakkun (Japan) (Rev 0).gb Never released Sutte Hakkun GB (Japan) (Rev 0).gb Never released Tale Spin (Europe) (Es).gb Never released Spanish version Teenage Mutant Hero Turtles III - Radical Rescue (USA) (Rev 1).gb New revision Teenage Mutant Ninja Turtles III - Radical Rescue (USA) (Rev 1).gb New revision Tesserae (USA).gb Previously un-dumped Test Drive 6 (USA) (Rev 1).gb Released for Color Game Boy instead The Adventures of Rocky and Bullwinkle (USA).gb Previously un-dumped The Flintstones - King Rock Treasure Island (Japan).gb Never released in Japan The Jetsons Robot Panic (USA) (Rev 0).gb New revision The Jetsons Robot Panic (USA) (Rev 1).gb New revision The Lawnmower Man (USA).gb Never released in USA The Little Mermaid (Europe) (Es).gb Never released Spanish version The Sword of Hope (USA).gb Previously un-dumped The XVII Olympic Winter Games - Lillehammer 1994 (USA) (Rev 1).gb New revision Triple Ace (USA).gb Never released Umi no Nushi Tsuri 2 (Japan).gb Previously un-dumped Wordhai (USA).gb Never released Wordtris (Europe) (De).gb Never released in Germany Wordtris (Europe) (En).gb Never released in Europe Wordtris (Europe) (Fr).gb Never released in France Workboy (USA).gb Never released World Cup Striker (Europe) (En,Fr,De).gb Never released in Europe World Ice Hockey (USA).gb Never released in USA ZAS (Europe).gb Never released in Europe Zool (Japan).gb Never released in Japan Bloomland (DMGB7A-0.288)Another fascinating discovery 'Philip & Marlowe in Bloomland'. Appears to be an English version of 'Taiyou no Tenshi Marlowe' but lacks the cutscene at the start, but also is dated 1991 - This game eventually came out in 1994! pic.twitter.com/oYzglvAPZW— Nintendo Metro (@NintendoMetro) September 9, 2020John Madden Football (DMGAJFE0)Ubisoft's unreleased port of John Madden Football for the Game Boy has found its way online https://t.co/l51xnKbbBO pic.twitter.com/58QdHqHVWG— GoNintendoTweet (@GoNintendoTweet) September 16, 2020Gargoyle’s Quest II (DMGRFE-0.828)'Gargoyle's Quest II' was released in the US on the NES. In Japan this was also released on the Game Boy, but didn't get an English release.Except thanks to these new #NintendoLeaks.. the seeminly finished game is just here. In English. pic.twitter.com/O4yZjmA4Gs— Nintendo Metro (@NintendoMetro) September 9, 2020Golf King (DMGBGRP0.2) & Golf Robot (DMGBGRE0.1)at some point this game was reworked into SuperShot Golf Robot, where Bobby is replaced with a robot called Vibot pic.twitter.com/ZgCzJo6gTO— taizou 🏳️‍🌈🦁 (@taizou_hori) September 10, 2020Hello Kitty Pocket Camera (GBDHKAJ0.2)Hello Kitty Pocket Camera Game Boy (I never thought I'd say those words and yet here we are..) Press and hold Start + Select while booting up to access an "erase all Data" screen, as in the original Game Boy / Pocket Camera. pic.twitter.com/B9wlynjzMe— ‏Soul filing cabinets (@nensondubois_) September 12, 2020Home Alone 2 - Kevin’s Dream (DMGV6E-0)Here's a Toys R Us Vidpro card for the Game Boy game Home Alone 2: Kevin's Dream. This game was never released and I can barely find anything else about it pic.twitter.com/9MjGWqHNzh— N4Us (@TheN4Us) July 9, 2020Lunar Chase/X (DMGECE-0.477)The game 'X', developed by Argonaut on the Game Boy as a 3D title, never made it to the states. With the new #NintendoLeaks, it appears this was intended to release as 'Lunar Chase' at some point. @dylancuthbert pic.twitter.com/QfeLxC6hb9— Nintendo Metro (@NintendoMetro) September 9, 2020Nick Faldo Championship Golf (DMGNFE-0.372)'Nick Faldo Championship Golf' appears to be an unreleased 1991 Golf game for the Game Boy by Titus. #NintendoLeaks pic.twitter.com/biarKEJjLT— Nintendo Metro (@NintendoMetro) September 9, 2020Rap Quest (DMGRQE-0.547)Checking out Rap Quest, an unreleased Game Boy game featuring Vanilla Ice https://t.co/HoDPMfhCPO pic.twitter.com/NQfYIEtiIe— GoNintendoTweet (@GoNintendoTweet) October 30, 2018Robopon (DMGHRCE0.2)I've found another huge get in the leak!? This Robopon pre-release, raffled out in Comic BomBom to only 500 people! Unlike the final GBC version, it targets the Super Game Boy, and lacks the special cartridge.With this… some revision of EVERY official GB(C) cart is preserved!!! pic.twitter.com/G1SBoi5qgc— Samuel 💻✨ Messner (@obskyr) September 14, 2020Sutte Hakkun (DMGASPJ0.2)both of the sutte hakkun protos from the leak have a neat SGB border.. huh. pic.twitter.com/nZyEYcnaes— 🦦kuro!! (@kurobutt) September 13, 2020WorkBoy (DMGWYE-0.781)In today's #NintendoLeak there is also the GB ROM of the WorkBoy, a never-released peripheral!!!More info: https://t.co/dJAXlqQFkR pic.twitter.com/kyfvRFOecd— WaluigiBSOD (@WaluigiBSOD) September 9, 2020RockBoard (DMGVOJ-0)News: Unreleased RockBoard Game Boy Port Discoveredhttps://t.co/6C9WmhkBOA pic.twitter.com/UXizG2448p— Brian (@Protodude) September 9, 2020Un-released Game Boy Color ROMSAll Un-released GBC ROMSThe table below contains all the previously unreleased ROMS for the original Game Boy (DMG).The table was generated from a file called newroms.7z was was released after the main leak. Name Description 3D Pool Allstars (U).gbc   AMF Bowling (U).gbc Cancelled Game Absolute X (EU).gbc Cancelled Game 5 Austin Powers Episode III (EU).gbc Cancelled Game Austin Powers Episode IV (EU).gbc Cancelled Game Billard Club (J).gbc Cancelled Game 6 Blue’s Clues - Blue’s Alphabet Book (U).gbc Previously un-dumped Bomberman Selection (K) (Rev 1).gbc Previously un-dumped Bomberman Selection (K).gbc Previously un-dumped Bounced! (EU).gbc Cancelled Game 7 Card Captors Sakura (J).gbc   Carmageddon (U).gbc   Carmageddon TDR 2000 (EU).gbc Cancelled Game Carnivale (U).gbc Cancelled Game 8 Carrera (EU).gbc Cancelled Game Casper (U).gbc   Catwoman (J).gbc Never released in Japan Daikatana (U).gbc Never released in North America David Beckham Soccer (U).gbc Never released in North America Denki Blocks (U).gbc Never released in North America Di Gi Charat (J).gbc Cancelled Game Donkey Kong Country (U).gbc   E.T The Extraterrestrial (EU).gbc Cancelled Game Equestriad 2001 (EU).gbc Cancelled Game F-18 Thunder Strike (U).gbc Never released in North America F1 Racing Championship (U).gbc Never released in North America F1 World Grand Prix (J) (Rev 1).gbc Never released in Japan F1 World Grand Prix (J).gbc Never released in Japan Formula One 2000 (EU).gbc Never released in EU Game Boy Wars III (J).gbc   Ganso! Doubutsu uranai (J).gbc Cancelled Game Gift (EU).gbc Never released in EU Gifty (GER).gbc Never released in Germany Gimmick Land (J).gbc Cancelled Game Grand Casino (J).gbc Cancelled Game Hajimari no Mori (J).gbc Cancelled Game Hello Kitty Pocket Camera (J).gb Cancelled Game Heroes of Might & Magic (U).gbc   Hydro Cross (U).gbc Cancelled Game Jeremny McGarth Supercross 2000 (J).gbc Never released in Japan Jibaku Kun Twelve World Story (J).gbc Cancelled Game Jimmy White’s Cueball (U).gbc Never released in North America Jissen no Yakudatsu Tsumego (J).gbc   Kanji Boy 3 (J).gbc   Kanji Shishuu (J).gbc Cancelled Game Kirby Family (J).gbc Cancelled Game (Sewing Patterns) Komugi-Chan no Cake o Tsukurou! (J) (Rev 1).gbc Cancelled Game Komugi-Chan no Cake o Tsukurou! (J).gbc Cancelled Game Lemmings (EU).gbc Never released in EU MBC3 Test ROM 16M Model.gb Internal Only Tool MBC5 Tester Ver7.08 (16m).gb Internal Only Tool MBC5 Tester Ver7.08 (2m).gb Internal Only Tool MBC5 Tester Ver7.08 (32m).gb Internal Only Tool MBC5 Tester Ver7.08 (4m).gb Internal Only Tool MBC5 Tester Ver7.08 (64m).gb Internal Only Tool MBC5 Tester Ver7.08 (8m).gb Internal Only Tool MBC5 Tester Ver99.6 (1m).gb Internal Only Tool Magi-Nation Keeper’s Quest (U).gbc Cancelled Game Max Steel (U).gbc Cancelled Game Mission Bravo (U).gbc Cancelled Game Mission Impossible (EU).gbc Previously not dumped Monster Traveler (J).gbc Previously not dumped Mystery Dungeon Shiren the Wanderer GB2- Sabaku no Majou (J).gbc Previously un-dumped NBA Show Time (U).gbc   Playmobil Laura (EU) (Rev 1).gbc Never released in EU Playmobil Laura (EU).gbc Never released in EU Pocket GT (U).gbc Cancelled Game Pocket Music (U).gbc   Primera División Stars 2001 (SP).gbc Never Released in Spain Pro Pool (U).gbc   Qix Adventure (U).gbc Never released in North America RPG Tsukuru GB (J).gbc Previously un-dumped Runelords (U).gbc Cancelled Game Shin Megami Tensei- Devil Children (J).gbc Previously un-dumped Space-Net Cosmo Neo (J).gbc Previously un-dumped Spy vs. Spy (EU).gbc Never released in EU Spy vs. Spy (U).gbc Previously un-dumped Street Fighter Alpha - Warriors Dreams (EU).gbc Never Released in EU Suzuki Alstare Extreme Racing (U).gbc Never Released in North America Swing (EU).gbc Previously un-dumped Sylva 2 (J).gbc Cancelled Game Taxi 2 (EU).gbc Previously un-dumped The Little Mermaid II- Pinball Frenzy (J).gbc   The New Adams Family (EU).gbc   The Powerpuff Girls- Bad Mojo Jojo (IT).gbc Never Released in Italy The Powerpuff Girls- Bad Mojo Jojo (UK).gbc Never Released in UK The Powerpuff Girls- Paint the Townsville Green (UK).gbc Never Released in UK Tiny Toon Adventures- Dizzy’s Candy Quest (U).gbc Never Released in North America Tonka Construction Zone (U).gbc Previously un-dumped Tony Hawk’s Pro Skater (J).gbc Never released in Japan Top Gear Pocket 2 (J).gbc Never released in Japan Top Gear Pocket 2 (U).gbc Previously un-dumped Towers II- Plight of the Stargazer (U).gbc Cancelled Game VR Sports Powerboat Racing (U).gbc Cancelled Game Vegas Games (U).gbc Previously un-dumped Watashi no Restaurant (J) (Rev 1).gbc Previously un-dumped Watashi no Restaurant (J) (Rev 2).gbc Previously un-dumped Watashi no Restaurant (J).gbc Previously un-dumped Wendy Der Traum Yon Arizona (GER).gbc Previously un-dumped Xtreme Wheels (J).gbc Never released in Japan Yakouchuu GB (J).gbc   Yu-Gi-Oh (EU).gbc Never released in EU Yu-Gi-Oh (FR).gbc Never released in France Austin Powers Episode 3 (CGBBA3P0.3) & 4 (CGBBA4P0.0)gamers, the motherlode has been found in this latest nintendo leak: TWO unreleased game boy color austin powers games pic.twitter.com/QdAYa9dhBx— The Ordinary Nintendo (@sebmal) September 9, 2020Gimmick Land/Tomato Adventure (KENSA\\CGBBAKJ0.0)Gimmick Land/Tomato Adventure for the GBC!It looks AMAZING!! pic.twitter.com/HKHNAKDKFK— toruzz (@toruzz) September 9, 2020Hajimari no Mori (CGBAHJJ0.1)Game Boy Bunko: Hajimari no Mori (Game Boy Pocket Books: The Forest of Beginnings) is an unannounced first party game for the GBC found in the recent leaks. It's apparently a version of Famicom Bunko: Hajimari no Mori, a Super Famicom game.It looks incredible. pic.twitter.com/tjBAp7qekp— toruzz (@toruzz) September 9, 2020Kanji Shishuu / Kanji Embroidery (CGBBKBJ0.0)Kirby Family (CGBBJVJ0.0)[Bonus Posts !]Today, a new Nintendo leaks happened, and it contained the unreleased (JPN only AD-ON/games) "Kirby Family" for the GBC ! which was planned to be released in September 2001 !So, today we can say that it's the day this game was released (discovered) in the world! pic.twitter.com/TF2nr6tMPm— Kirby Birthday ! 🎉 (@KirbyBirthday) September 9, 2020Pokémon Picross (DMGAKVJ0.1)Canceled Pokémon Picross Game Boy Color Game Surfaces In Nintendo Leak https://t.co/A8QS7LTEno— ⭐ yyoossk⭐ (@Cloud0835) September 10, 2020Nintendo DSiWhile not quite a Lot Check release, you might also be interested in the DSiWareROM.rar archive from the Platinum leak as it contains a ton of DSiWare ROMS in TAD format.These were sent to iQue for localisation for the Chinese market and were presumably taken from the Lot Check archive by Nintendo SPD. Nintendo DsiWare Leak For more information on the files inside the DsiWare archive check out this post. References Nintendo “Gigaleak” - nesdev.com ↩ mame/famicom_flop.xml at master mamedev/mame GitHub ↩ Baby’s Day Out The Lost Media Wiki ↩ Bobby’s World (Game Boy) - The Cutting Room Floor ↩ ↩2 NESWORLD.COM - MIDAS ATTEMPT TO ENTER THE GAMEBOY MARKET ↩ Billard Club for Game Boy Color - GameFAQs ↩ Bounced - The Cutting Room Floor ↩ Carnivale for Game Boy Color - GameFAQs ↩ ", "excerpt": "Since Nintendo controls manufacturing of all official games they have a process called Lot Check that ensures the games quality before manufacturing. Every game ever officially released for their platform has had to go through the Lot Check process in order to achieve the Nintendo Seal of Quality. Lot Check...", "tags": ["leak","nes"], "image": "/public/images/leaks/Nintendo Lot Check.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Official PlayStation 1 Software Development Kit (PSYQ)", "url": "/Official-PlayStation-1-Software-Development-Kit", "content": "History for the PSY-Q SDKThe History of the PSYQ PS1 Software development kit is fascinating, it starts with a collaboration between two UK companies, SN Systems and Cross Products, to find out more we need to go a litter further back to the history of these two companies.SN SystemsSNSystems was founded by Andy Beveridge and Martin Day back in 1988. While developing their own games they created the SN Assembler (SNASM) for Atari and Amiga computers [4].SNASM became so useful that it was even licenced to other game developers such as Cross Products which then later licenced it even further as SNASM68K! So SN Systems were already making quite a name for themselves in the Game Development Tool Market.List of games that used SNASM: Flashback [https://segaretro.org/SNASM68K ] Lemmings [https://twitter.com/mdf200/status/804438544940822528 ]Collaboration with Cross ProductsThe earliest use of SN systems products by “Cross Products” was suggested on the SegaRetro wiki claiming that Ian Oliver (joint-founder of Cross Products) manually made a RAM board for Mega Drive development which needed an Assembler for the Motorola 68K processor in the MD and thus SNASM68K was born [2].So this suggests Cross Products were working very closely with SN Systems throughout the 90s.This is further confirmed on the official SN Systems website where it says [3]:The assembler came together first and the debugger shortly afterwards. We called the assembler SNasm (for SN AsSeMbler) and we licensed it to Cross Products Ltd and it rapidly established itself as the industry standard. Since then most Sega Genesis games have been developed using SN Systems' software.The website makes quite a claim that ‘Since then most Sega Genesis games have been developed using SN Systems’ software’, it would be interesting to find out how true that statement is, how many development studios were using the SN Systems development toolchain to develop Mega Drive games compared to other development kits.On the official Cross Products website in 1997 it mentions builds of the SNASM2.1 Assembler and Debugger, which Cross Products were selling as part of their Sega Saturn Development Kit [1].Birth of Psy-QIn 1993 we launched Psy-Q with Psygnosis - this second generation product included C source level stepping and breakpointing and was even faster than the original SNasm. We haven't looked back since, we went on to make Psy-Q even faster and more powerful and able to handle even larger projects and we added support for more cpus and target systems.Death of PSY-QPSY-Q for PS1 was later rebranded as SDevTC (Sony Developer Toolchain) sometime before August 1999 as it is mentioned the rebranding in the Official Run-Time Library Overview from August 1999.Hardware by SN Systems for Psy-Q debugging[Next generation issue 15 from March 1996]Psy-Q for Other Platforms (Sega and PC)Advert for PsyQ from Edge magazine, interestingly it says in the Ad that its a “Sony Electronic Publishing Company” but advertises its Sega 32X and PC products [Edge Magazine issue 14 from November 1994].PsygnosisYouTube documentary about Psygnosis - https://www.youtube.com/watch?v=tvYlxnHOY-QThe Psy-Q Software SuiteThe official SN Systems website advertised the Psy-Q Software Suite with the following blurb:The Psy-Q Software Suite* Two highly optimised R3000 Assemblers providing powerful macro and data definition facilities and section handling. These are fully compatible with the output from the popular Freeware GNU-C (supplied)* High speed Linker and Librarian with extensive link-time options* The popular Psy-Q Debugger for Windows '95 as well as the Psy-Q Debugger for DOS. Both systems allow developers to debug via their original C or Assembly language source files and support full C expression handling and data browsingFrom the blurb it looks like it contained a version of the open source GNU C compiler which would feed compiled assembly language into the Psy-Q assemblers. The Psy-Q assemblers would then optimise the code and feed it to the ‘High Speed Linker’ which puts all the different assembly output files together to create a single PlayStation executable.I’m not sure what they meant by a Librarian as thats not a common term when speaking about development toolchains but my guess is that it would just be software to manage all the different pre-compiled psx libraries.Next generation/EDGE ArticleThe following article was published by EDGE in the UK and later “Next generation” magazine in the US:Games Developed With Psy-QColony Wars Red Sun (Ps1) (Psygnosis)Psygnosis used its own development kit to create the PS1 game “Colony Wars Red Sun” and in the Game Developer Magazine from August 2000 they have an Postmortem that you can view here:https://archive.org/stream/GDM_August_2000#page/n31/mode/2up/search/%22SN+Systems%22Notes from article: Uses Sn Systems PlayStation 1 dev kit 220,000 lines of code Moved C files to C++ Inherited legacy code from Krazy Ivan, Colony wars 1 and 2Other SN Systems Development KitsAccording to the Official SN Systems “PC Development System for the Nintendo 64” guide (Thanks to Ultra64.ca), the list of SN systems development kits are as follows: Sony PlayStation (PSY-Q) SEGA Saturn SEGA 32X SEGA MegaDrive/Genesis (SNASM65k) SEGA Mega-CD (SNASM2) Nintendo Super NES Commodore Amiga 1200 and 600 Williams Phoenix Arcade Board Nintendo 64 (SN64 ProDG)References", "excerpt": "History for the PSY-Q SDK The History of the PSYQ PS1 Software development kit is fascinating, it starts with a collaboration between two UK companies, SN Systems and Cross Products, to find out more we need to go a litter further back to the history of these two companies. SN...", "tags": ["snsystems","sdk","psyq","ps1"], "image": "/public/psyqsdk.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Pokemon Mini Official Software Development Kit (Toolchain)", "url": "/official-pokemon-mini-sdk", "content": "Introduction to the Pokemon MiniUnlike previously thought, Nintendo did not actually create custom hardware for the Pokemon Mini, as it was recently found out that the CPU is actually a standard Seiko model that was previously used to power similar devices with small LCDs.The hardware for the Pokemon Mini was provided by Seiko EPSON which included a 8-bit CPU called the S1C88 , it was a cpu that was commonly sold for small portable devices such as watches or pedometers [^2].Which S1C88 chip?Seiko created many different chips in the S1C88 family which all have different configurations so to find out what specific chip the Pokemon Mini used required some investigation.The chip was found to be the E0C88V20 which was never actually advertised on their website as part of the family but the community found a description file in the epson toolchain that almost matched the PM completely.The only difference between the PM and the description was the different execution core, presumably to handle the sprite engine 1.Although the SDK provided by the hardware vendor is for the whole family of chips so we don’t need to know the exact chip, it is just interesting information.Official Hardware SDK toolchainThe Pokemon mini was never intended to be a huge income-generator, with the gameboy advance released soon after it was more a toy base don some cool technology with the Pokemon brand applied. So not much Nintendo resources went into the project, so if you are expecting a full Software development kit similar to the GBC, GBA or N64 you will be slightly disappointed.As Nintendo had very little involvement in the Pokemon Mini’s hardware design the Official software development kit was provided by the hardware manufacturer.In this case a toolchain was provided specifically provided for the S1C88 assembly language, providing the common tools such assemblers and even a C compiler!It contains everything needed to develop games for the portable console, including an emulator with LCD support and simple debugging tools that they have simply named simulator.Obtaining the SDKThe hardware SDK toolchain was found still alive on the Epson website: https://www.epsondevice.com/products_and_drivers/semicon/products/micro_controller/zip/s5u1c88000c16.zip which if you download provides you with a setup.exe to be run on early Windows OS (98/ME).However you are most likely wanting to run it on a more modern operating system and that is where the c88-pokemin project comes in. It will run through all the steps, even downloading the zip file from epson (or Internet Archive) and extracting the contents of the setup executable!The main steps to set this up are as follows: Clone or download: https://github.com/pokemon-mini/c88-pokemini If downloaded as zip Extract the contents Go into the directory named c88-pokemini Run makeIf everything has succeeded then you are in luck and can proceed to the next stage, otherwise we have a few tips to help fix the problem.Error wineboot command not foundIf you get an error on MacOSX such as:/bin/sh: wineboot: command not foundThen you will need to install the wineboot dependency in order to make progress.DocumentationThe documentation given to the developers would be fairly limited in comparison to the official N64 of GBC offerings but they did go into great detail about how the hardware works. https://global.epson.com/products_and_drivers/semicon/pdf/id000920.pdf http://www.rayslogic.com/Software/TimexUSB/Docs/s1c88%20core%20cpu%20manual.pdfOfficial AssemblerAs the CPU used Seiko S1c88 assembly language which was a very specialised dialect of assembly there was only one assembler that could handle it and it was made by a cooperation between Seiko EPSON and Tasking Inc.Official C CompilerThe official SDK provided a proprietary C compiler developed by Tasking Inc and licensed by Seiko EPSON for distribution with their SDK.Compiler Optimizationshttps://web.archive.org/web/20010304085224/http://www.tasking.com/technology/compiler.htmlSimulator (emulator)Simulator doc: https://global.epson.com/products_and_drivers/semicon/pdf/id000926.pdfthe simulator works fine for standard S1C88 parts, but only the info file was provided, and the V20 core. It was missing some DLL files specific to that part thoughMinlibMinlib is a library of code either written by Nintendo or Jupiter and included in all of the games developed for the Pokemon Mini.It contains common functionality such as displaying the boot logo and audio functions.Homebrew SDKBrowser-based EmulatorWith basic debugging support but there are a few known bugs which cause inaccuracies in the emulation.https://minimon.scyl.us/Reverse Engineering Toolchainmindis2 DisassemblerGitHub - pokemon-mini/mindis2: Pokémon Mini ROM disassemblerReferences Jhynjhiruu, Scylus (aka asterisk) and VirtualChris on PokeMini Dev Discord ↩ ", "excerpt": "Introduction to the Pokemon Mini Unlike previously thought, Nintendo did not actually create custom hardware for the Pokemon Mini, as it was recently found out that the CPU is actually a standard Seiko model that was previously used to power similar devices with small LCDs. The hardware for the Pokemon...", "tags": ["pokemonmini","sdk"], "image": "/public/generated/placeholders/official-pokemon-mini-sdk.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Official Sony Vita SDK", "url": "/official-vita-sdk", "content": "IntroductionA Torrent with 52.61GB of content was anonymously leaked online in May 2019 containing pretty much all the Official Playstation Vita Software Development Kit files.It was split into 2 main folders: PlaystationPartners (1.54MB) Documentation for psvita (52.60 GB) - the main SDK filesPlaystationPartners (/PlaystationPartners)The Playstation Partners folder is not particularly interesting, it is just legal information about becoming a registered Playstation Partner. Size Name Notes 1.1M PlayStation_GDPA_Japanese.pdf PLAYSTATION GLOBAL DEVELOPER & PUBLISHER AGREEMENT (Japanese) 410K PlayStation GDPA v1.03 (clickthrough).pdf PLAYSTATION GLOBAL DEVELOPER & PUBLISHER AGREEMENT (English) 6.4K PRIVACYPOLICY.TXT Same as TOS.TXT 6.4K TOS.TXT The Terms of Service for Playstation Partners Registration Portal 586B FAQ.TXT PartnerHome Frequently Asked Questions such as GDPA questions Main PS Vita SDK (/psvita)The Main PS Vita SDK folder has been neatly organized into a number of different categories which makes it much easier to just get the content you are interested in. Name Size Notes Docs 993.71 MB Contains all the documentation for the entire SDK in both English and Japanese Software 209.67 MB Contains the SDK Manager along with the SN Systems DBS plus VC extensions PUPs 13.56 GB Playstation Update packages for the DevKit and TestKit hardware from version 1.680 to 3.650 Engines 4.79 GB Contains the Unity, PhyreEngine and live2d Cubism SDKs SDKS 33.07 GB Contains 3.300/3.500/3.550/3.570 SDKs plus the Photon PSVita SDK Software (/psvita/Software)The table below lists the relevant entries. Name Size Notes SDK_Manager-2_8_2.exe 61M   SN-DBSv2.5.6.60.exe 41M   SN-DBSv2.5.4.2.exe 41M   SN-DBS-VC-Extension-2017v1.0.20.0.exe 7.0M   SN-DBS-VC-Extension-2017v1.0.21.0.exe 7.0M   SN-DBS-VC-Extension-2010v1.0.20.0.exe 6.4M   SN-DBS-VC-Extension-2010v1.0.21.0.exe 6.4M   SN-DBS-VC-Extension-2012v1.0.20.0.exe 6.4M   SN-DBS-VC-Extension-2012v1.0.21.0.exe 6.4M   SN-DBS-VC-Extension-2013v1.0.20.0.exe 6.4M   SN-DBS-VC-Extension-2013v1.0.21.0.exe 6.4M   SN-DBS-VC-Extension-2015v1.0.20.0.exe 6.4M   SN-DBS-VC-Extension-2015v1.0.21.0.exe 6.4M   Docs (/psvita/Docs)Most of the files are contained in the root of the Docs folder in an unorganized mannor, but there are two subfolders: PhyreEngine - Extracted content from PhyreEngine_3.21.0.0_EnglishDocs.zip TrainingVideos - contains an mp4 and flash videos about optimizing games for the VitaNote that in the table below we have not included the Japanese files unless no english version exists, to avoid duplicate content. Size Name Notes 215M DevStation12_Programming_Slides.zip   130M NGPGameDesignDay2011.zip   82M VITA_DevCon_2011_Slides.zip   46M PhyreEngine_3.21.0.0_EnglishDocs.zip   42M DevStation12_Network_and_Submissions_Slides.zip   33M DevStation12_Business_Slides.zip   15M 24658.mp4   13M Vita_Network_Presentation_PDFs.zip   6.0M VITA_Tuning_Workshop_2011_Slides.zip   3.7M SystemSoftware_Themes_Overview_20141219.pdf   3.7M Unity_logos.zip   2.6M SN-DBS_Documentation-2.5.4-English.zip   2.5M SN-DBS_Documentation_2.5.6-English.zip   2.0M PS_Vita-TestCase_for_TRC1.7_e.pdf   1.1M PS_Vita-TRC1.7_e.pdf   827K PS_Vita_Testcase-1_7-CHM_En.zip   658K PSN_Service_Setup-Guide_e.pdf   426K In-game   412K PS_Vita-TRC1_7-CHM_e.zip   166K SCEE_Virtual_Currency_Policy.pdf   161K SupplementarySubmissionForm-1_10-20121212.zip   159K Cross-Title-Commerce.pdf   127K SCEE   89K Demo_to_Full_Game_Upsell.pdf   51K SN-DBS_ReleaseNotes_e.htm   18K SN-DBS-VC-Extension-2012-ReleaseNotes-E.htm   18K SN-DBS-VC-Extension-2010-ReleaseNotes-E.htm   17K SN-DBS-VC-Extension-2013-ReleaseNotes-E.htm   17K SN-DBS-VC-Extension-2015-ReleaseNotes-E.htm   15K SN-DBS-VC-Extension-2017-ReleaseNotes-E.htm   12K faq.txt   7.4K PSTVDev.txt   Training Videos (/Docs/TrainingVideos)This folder contains both English and Japanese training videos related to optimizing games for the Playstation Vita.It contains a single MP4 video called Lesson1.mp4 which lasts 6minutes and 38 seconds and talks about requesting and configuring Playstation Network (PSN) services for Vita games. It is quite an interesting video for people who have never seen the secret Vita Developer Network website (DevNet) that was only available to registered developers.It also contains around 100MB zip files for Japanese and English flash content called PS_Vita_Tutorial_Videos_SDK_1800_E.zip.These Videos are split into two sections with the following contents: Introduction Setting up Your Development Environment Controlling Development Kits Battery Monitor, Controller Capture and Screen Capture Performing Distributed Builds Razor Capturing CPU Traces Analyzing CPU Traces CPU HUD Exporting CPU Trace Information ", "excerpt": "Introduction A Torrent with 52.61GB of content was anonymously leaked online in May 2019 containing pretty much all the Official Playstation Vita Software Development Kit files. It was split into 2 main folders: PlaystationPartners (1.54MB) Documentation for psvita (52.60 GB) - the main SDK files PlaystationPartners (/PlaystationPartners) The Playstation Partners...", "tags": ["vita","sdk"], "image": "/public/generated/placeholders/official-vita-sdk.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Official Xbox SDK (XDK)", "url": "/xbox-sdk-xdk", "content": "The Official software development kit for the original xbox was called the XDK (Xbox Development Kit). This was only provided to developers on their Xbox Developer Services website (xds.xbox.com) and not via CD/DVD.This was mainly due to the frequency in which the XDK changes, new builds would be available very frequently, at least a couple every month. This was a stark contrast to the SDKs from the previous generation that would only have a handful of releases during the whole lifetime of the console.Unsurprisingly the XDK requires Microsoft Visual Studio as the IDE and Microsoft Visual C++ compilers. This was very welcome by existing Windows PC developers and was considerably easier to use than the PS2 or Gamecube development environments.Publicly Leaked XDKsThe following versions of the SDK have been released to the public unofficially and can be found on sites like archive.org: XDK 4361 2002-03-01 (Accession) XDK 4627 2002-07-05 (WAM) XDK 5558 2003-06-12 (COMPLEX) XDK 5659 2003-08-27 (COMPLEX) XDK 5788 2003-11-24 (COMPLEX) XDK 5849 XDK 5933 2005-03-22 (WAM)Cleaning up Previous installsIt is important to remove previous installs of the SDK and the installer actively checks the version number of an installed xdk and won’t allow you to install prior versions.Registry keysYou need to remove the following registry keys using regedit on windows or wine:HKEY_LOCAL_MACHINE\\Software\\Microsoft\\XboxSDKHKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\Microsoft Xbox SDKInstalling the XDKNote that you MUST install Visual Studio 6.0 and apply Service Pack 4 and above (SP6 works) otherwise the XDK installer will not install the Samples, include or lib files so you will have an incomplete SDK!Step 1 - Install Microsoft Visual C++ 6.0If possible try to download the following iso if you don’t already have Visual C++:Microsoft_DevTools_January_2001_Visual_C++_6.0.isoStep 2 - Apply the Service PackThe XDK installer checks to see if your copy of Visual C++ is up to date with Service Pack 4, but any service pack later then that will also work. You can get the latest service pack 6 from the official Microsoft website:Download Service Pack 6 for Visual Basic 6.0, Visual C++ 6.0 with Visual Source Safe 6.0d from Official Microsoft Download CenterStep 3 - Install the Processor PackIn early versions of the XDK such as XDK4361 it comes with an installer called Visual Studio Processor Pack. Make sure to run this before installing the XDK.Step 3 - Run the SetupXDK.exe fileRun the SetupXDK executable and it will guide you through the rest of the installation process.Optional StepsThe following are optional installers that might be useful, you don’t need these tools but they could come in helpful for debugging specific issues.Install Microsoft Network Monitor 2.0Comes with XDK 4361. It is a tool for Network debugging, useful for debugging issues with online/lan games.DocumentationThe documentation folder contains a few helpful files which we have listen in the table below with a brief description of its purpose, but the main documentation comes in the form of a CHM (Windows Compiled Help Format) file called .chm; File Name Notes xboxwhitepapers.url goes to https://xds.xbox.com/BPProgInfo.asp?page=content/wp_index.htm xboxguide.url https://xds.xbox.com/BPProgInfo.asp?Page=content/cert_req.htm adadeded.xml Seems to be an example Leaderboard xml document, something to do with xbox live leaderboards? XboxSDK.chi Compiled Help index for the CHM file SamplesIf you had Visual C++ installed when you installed the SDK you will find a Samples folder under Program Files/ Microsoft Xbox SDK which contains example source code that can be compiled for the Xbox.IncludesLibraries", "excerpt": "The Official software development kit for the original xbox was called the XDK (Xbox Development Kit). This was only provided to developers on their Xbox Developer Services website (xds.xbox.com) and not via CD/DVD. This was mainly due to the frequency in which the XDK changes, new builds would be available...", "tags": ["xbox","sdk"], "image": "/public/images/xbox/XboxSDK.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Oman Archive - N64 Leak by SGI employee", "url": "/oman-archive", "content": "The Oman Archive was a leak of Nintendo Technical documents from a source inside SGI in late 1999. It was uploaded to the internet under the name oman.rar but has since been repackaged into multiple other archive formats, such as the now more common oman.7z (148.3 MB).An updated version of the Oman Archive was released in 2020 at the same time as the Gigaleak, another Nintendo Leak which includes N64 content. Gigaleak - SNES Source Code Leak For more information on the original Gigaleak check out this post. History of the Oman ArchiveEven the origin of the name itself is clouded in mystery with some saying it was leaked by a person called “Oman” and others disagreeing, but very little information is known about the leak.It is believed that the archive kickstarted the N64 Emulation development scene and that without it we wouldn’t have made much of the early progress in figuring out how the hardware worked 1.However the problem with the Oman archive is that the contents were obtained illegally and thus any development based on the stolen content would be liable for copyright infringement.Thus many talented N64 emulator authors refuse to use the material and instead reverse engineer the inner working of the system themselves. This prevents the code (and the resulting binary) from any patent/copyright/trademark violations, but requires a lot of time and patience. So we are thankful for all these dedicated developers, helping maintain the codebase in a way that prevents distribution of N64 emulators from becoming illegal 2.If you plan to do any N64 development then stay as far away from the Oman Archive as you can, including leaving this page…However historically these documents are very interesting and preservation of the material is vital. So even if the originally material disappears from the internet forever (unlikely but not impossible) lets at least clear up a few misconceptions by asking: What exactly IS in the Oman archive?Top Level filesLike most leaks there are a bunch of misc files at the root of the archive that are not always particularly relevant. This section will try to categorised them as best we can.SN64 SDK FilesThese documents are all from February 1997 and really should have been in a folder called N64Win95 or Sn64 as they all come from the same product, maybe it was a copy error by the original author of the leak.They are from a development kit by SN Systems known as SN64 and this was the Windows 95 version of the SDK. SN64 is just the brand name of the Nintendo 64 versions of SN Systems PSYQ development kit that also supported Playstation and Saturn consoles.This made it a really popular choice for 3rd party game developers as it was slightly easier to port code between the consoles using the SDK. SN64 - Nintendo 64 Software Development Kit (SDK) If you are wondering what these files do check out our page on the SN64 SDK. All of the files in the root directory up to and including N64NOTES.TXT (9th March 1997) are from this SN64 SDK. The other top level files are listed separately below.tmp fileAlthough the file simple called tmp looks like a linux directory it is in fact an ASCII Text file that is the output of running a directory command on their E:\\oman\\DOC folder.AUD.c A C-source file that must have been misplaced, not sure exactly where it came from but it was created by SGI in 1994. The same file exists in TOOLS\\EMULATE\\AUD.C so it must have been copied by accident to the top level directory. docs.zip This contains a subset of the files from the /DOC folder and they are all identical in contents to those files too. This zip can be ignored and you can go straight to the /DOC folder. INSTD.tarThis TAR archive contains the N64 SDK version 2.0G (for RCP 2.0) for use on an IRIX Unix machine, to install just copy the 2 folders (var and usr) to the root of your SGI IRIX.Also note that these files also exist extracted in the root directory of the main tar file.usr folderThe files in this tar are part of the standard N64 SDK so will not be covered here as they have been covered multiple times elsewhere.tmp folderThe tmp folder is blank and contains no data, it should not have been included in the archive.var/inst folderIRIX machines comes with a command called inst used for installing software distributed by SGI 3.The program saves the details of everything that has been installed in the /var/inst folder, and so the SDK comes with a few files used by the inst program when listing what is installed: Name Description rsp_dev Install record for Nintendo 64 RSP Development Environment 2.0G ultra Install record for Ultra 64 Development Environment, 2.0G rsp_audio Install record for Nintendo 64 RSP Audio Microcode Source Code 2.0G gng_noship Install record for Ultra 64 Noship Go/No-go Test Software 2.0G rsp_gfx Install record for Nintendo 64 RSP Graphics Microcode Source Code 2.0G hist History file for IRIX inst command .rqsfiles standard file on all IRIX machines that have inst command orphan standard file on all IRIX machines that have inst command .machine_inventory Holds metadata about the current machine INSTLOG Log file from the last time the inst command ran var/sysgen/master.d folderThe folder var/sysgen/master.d on an IRIX system is used by the lboot command to define the master files for the bootable kernel. In this case it just contains one file called u64 for the N64 hardware.Master files are basically configuration for all the modules on an IRIX system and can be viewed using the master command 4.AS Folder (Algorithm Simulator) The folder called AS is at the top level and contains a brief README saying that this folder contains a C program that begins to model the algorithms and functionality of the MSP and MDP (presumably the RSP and RDP). The Algorithm Simulator was used before the N64 hardware prototype was available to develop on and allowed developers to get a head start on their games. The folder contains: *.c C source code *.h C header files *.o compiled version of the *.c files *.RGB - Textures *.I - 3D object files COSIM Folder (Co-Simulation)The Cosim folder contains C and Assembly source code used to test the hardware including testing the early Verilog model for “Project Reality”.Co-Simulation is using software to verify and test simulated hardware, in this case it is testing the N64 development hardware with a few basic software tests 5.DOC Folder (Documentation)This is the main folder of goodies, whenever someone talks about the value of the Oman Archive this is the documentation they are talking about.The folder contains many different file formats, some are plain text (.TXT), others are Postscript (.PS) and more are File Maker files (*.FM & *.DOC). So there was clearly no standard when it came to documentation.Note that all the documentation located under this folder is part of what SGI called their HeadStart development environment, which was documentation for starting development before the actual hardware was finalised for the console.Top Level DocumentationThe files located at the root of the DOCS folder tend to be in 3 different formats, .DOC, .FM and .TXT.Note that the .DOC files start with the ASCII string <MakerFile 4.0K> and are not MS Word documents. Also the .FM files start with the ASCII string <MakerFile 3.0F>.They were both created with an early version of Adobe FrameMaker but don’t seem to be usable in the latest versions of the tool. They also can’t be converted with Adobe createPDF service either so the only current way to get partial content is to run strings on it but it is hardly readable.There was a FM2HTML tool developed according to W3.org but all download links seem to have been Brough offline 6.For anyone trying to reverse engineer the old FrameMaker format, they is a Postscript version of AUDUCODE.FM which could help understand what the bytes in the format represent.Hopefully someone will be able to convert them to a PS, PDF or HTML file someday for us all to enjoy. Name Description ABI.DOC Audio Binary Interface MakerFile Documentation ANIMATION_ENGINE.FM Brief overview of 3D Animation of Models AS.FM Graphics Algorithm Simulator AUDBI.FM Audio Binary Interface 1.0 command reference (e.g for A_CLEARBUFF) AUDUCODE.FM RSP Audio Microcode Architecture AUDUCODE.PS Same as AUDUCODE.FM but in Postscript format BLEND_MODES.TXT Very detailed description of the Blend Modes by Phil Gossett CHAR_PLAN.DOC Device Characterization checklist CHIP_DESIGN_DIRS.FM Description of the Verilog folders DEBUGGER.TXT Notes on how to use the CaseVision Debugger DIAGNOSTIC_PROPOSAL.FM Proposal to create a Diagnostic System for the Nintendo 64 Hardware and Software DIAGS.DOC Diagnostic program documentation for the Ultra 64 development board DMA_PERFORMANCE DMA Performance Analysis EMULATOR.TXT Status of the Graphics Binary Interface Emulator for SGI workstations ENDIAN.TXT Brief notes on Big Endian bit ordering FILTER_BUILDLOG Bash script to filter the log files in the directory FIXEDPT.FM Notes on Fixed Point Numbers FRAMEREC.TXT Notes on a way to record gameplay frame by frame on an SGI ONYX GFX_TEST.TXT Notes on the tests located in the PR/apps/rsp* folder for testing the RSP GFXBI.FM RCP Graphics Binary Interface Documentation GONOGO.FM Ultra 64 Go/No Go Test Plan GRUCODE.FM RSP Graphics Microcode Architecture GRUCODE.OLD.FM Old version of RSP Graphics Microcode Architecture HUFFMAN.FM Huffman Decoding for MPEG IO.FM Interaction between I/O components IOSIM.FM iosim I/O simulator command documentation LIGHT-MATERIAL.FM Lighting and Materials LIGHTFOG.TXT Documentation for Lighting, fog, and reflection mapping LOGICAL_RDP.FM Rendering Pipeline MAKEFILE Top level makefile that just calls the “RSP” folders makefile MEM_MGMT.FM Memory Management such as Virtual Addresses and Segments MEMORY_MAP Simple Text memory map of each of the components of the N64 (RCP, RDRAM etc) MMAKE Fork of the SGI mmake bash script MNIGHTLY Bash script for nightly builds using mmake MPEG_API.FM MPEG Video API MPEG_STATUS.FM Status of MPEG integration into the SDK MPEG_TALK.FM How MPEG Works presentation MPEG_TALK.PS How MPEG Works presentation (Postscript) MVT.FM Multi-View Textures (Level of Detail optimisation) NIGHTLY.SH Bash script to run nightly regression testing PERFORMANCE.DOC RSP Geometry Transformation Performance PERFORMANCE.DOC.RECOVER Older version of PERFORMANCE.DOC PERSPNORM.FM Perspective Normalization PROBLEMS Ultra64 Problems and Tips (with workarounds) RCP_ELEC_SPEC.FM Electrical specification for RCP RDB.DOC RDB Port connecting Indy & the development board RDP_COMMANDS.FM Documentation for each of the Reality Display Processor commands RDP_COMMANDSIX.DOC Index of RDP Commands RDP_FUNC_IO_TABLES.PS I/O tables for the Reality Display Processor RDPPROG.FM RDP Programmers Guide RDRAM_INITIALIZATION Brief notes on the initialization sequence of the RDRAM (Rambus) README Description of the HeadStart development environment README.6.2 Notes on one developers attempts to get it running on a 6.2 Indy README.NIGHTLY Instructions for setting up a nightly build of regression tests RELEASE2.FM Readme for Ultra 64 Developers Release 2.0 RI_PROGRAMMING_GUIDE RI/RDRAM register read/write operations RSP_GFX_SW.FM RSP Fast3D Graphics Software Architecture RSP_VERIF_ENV Notes about the RSP verification environment RSPVERIF.DOC RSP Design Verification Strategy SPRITELIB.FM Sprite Library Documentation SPRITES.VGS Introduction to Video Game Sprites SRCTREE.FM Introduction to the Src folder SWARCH.FM Software Architecture SWARCH.PS Postscript version of SWARCH.FM SWBRINGUP.DOC Operational Software Bringup Sequence - nothing much in this document SYSDATAFLOW.FM System Data Flow for both hardware and software TESTVECTOR.TXT Test vector development environment for the RCP TEX_FIGS.FM Texture Image Coordinate Space TEXTURE_OUTLINE.DOC Good overview of texturing on N64 TREEBUILD.DOC Document that outlines how to use the SGI pbuild development environment to build the source tree TREESETUP.SH Small bash script for running the inst command to setup the dev environment TUTORIAL.FM Tutorial for making a N64 game ULTRADBG.FM FrameMaker version of ULTRADBG.TXT ULTRADBG.TXT Very interesting document on how to debug N64 code VIDEO_MODES.TXT Described the different video modes for both NTSC and PAL YIELD.TXT Notes on What Yield is (e.g osSpTaskYield) One of the most interesting documents in this list that can be easily read is SWARCH.PS as it contains plenty of interesting information about how the software architecture works.HW - Hardware DocumentationThe table below lists the relevant entries. Name Description HW/4300_PIN_LIST Comparison between the VR4300i and Nintendo R4300i Pins, most are the same but some are off by one such as EValidB HW/ASICSYN_QUICK_REFERENCE ASIC Synthesizer Quick Reference HW/ATTRIBUTEBUFFER.FM Attribute Buffering HW/AUDIO_DOC AI CONTROLLER PROGRAMMING INTERFACE HW/BL.FM Hardware Blender description HW/CC.FM Color Combiner hardware HW/CELL_NEEDS.FM   HW/CELL_TRACK.FM   HW/CS.FM   HW/CSIM_INTRO.DOC   HW/CYCLES   HW/EWCTR.FM   HW/HWSYMBOLS.FM   HW/OS_DEV.SC   HW/OS_VIDEO.SC   HW/PI_BLOCK.TXT PI Datapath Block Diagram HW/PI.FM   HW/PIN_LIST List of all the pins on the RCP HW/PROTOBOARD.SH   HW/RAMSPEC.SC   HW/RCP_BLOCK.FM   HW/RCP_IO.FM   HW/REGFILESPEC.SC   HW/SHUFFLETABLE.FM   HW/SI_SPEC.TXT Serial Interface specification HW/TAB_FORMAT.DOC   HW/TESTER_CRC.DOC   HW/TF.FM   HW/TOOLTIPS Tips for using the tools Verilog and Compass HW/TRI_FORMAT.FM   HW/VERILOG_HEADER_TEST Source code header - not interesting HW/WIREDELAYS Email rising wire resistance and capacitance VERIFHardware verification documentation files are located in this folder. Name Description VERIF/BL hardware Blender test cases VERIF/CC Color combiner test cases VERIF/CS Command Shuffle Unit Test Plan VERIF/CV Check Vectors VERIF/EW Edge Walker Unit Test Plan VERIF/HIGHLEVELTEST   VERIF/IO I/O Subsystem Verification Plan VERIF/MS Misc Info (it is blank) VERIF/RDPOVERALL High level RDP Test cases VERIF/RDPVERIF.FM   VERIF/ST   VERIF/TC Texture Compression Tests VERIF/TF   VERIF/TM Texture Memory test cases PICSThese are pictures in SGI RGB format but it is currently unclear where they are used. If you want to view them just add the .SGI extension to the end of them and you can open them in most image editors. Name Description PICS/BALL.1 Unknown image format starts with Magic number: 59 A6 6A 95 PICS/BALL.2 Not an SGI image PICS/BALL.3 Not an SGI image PICS/INTL.RGB Has the TDK logo in it, very blurry greyscale PICS/LOGO_SGI.SMALL Small SGI logo (205x196) PICS/TEN1.MB Square with white pixels in bottom left and dark grey everywhere else PICS/TEN1.BLK Small white Square with grey pixels in the top right corner PICS/TENNIS1.CIF Greyscale image of man holding ping pong racket and bouncing ball on it PICS/PIC8.SGI lots of squares with different patterns in them ## AUDIONot sure why a new directory was created for one file but this folder does exactly what it says on the tin, has Audio documentation in it. Which is only one file which contains the Audio API functions.The file is: AUDIO/AUDIOLIBREF.DOC - Audio Library ReferenceDEVThe documents this folder are intended to be released to developers when they obtain the SDK.Pretty much all of this is already available on the web such as on square7.ch: N64 Programming Manual.As such we have just listed the chapter that each document corresponds to int he table below. Name Description DEV/ADVMEMORYMGMT.DOC Chapter 10 DEV/AUDIOFORMATS.DOC Chapter 19 DEV/AUDIOLIB.DOC Chapter 17 DEV/AUDIOMEMORYUSAGE.DOC Chapter 21 DEV/AUDIOTOOLS.DOC Chapter 18 DEV/BARKLEY.PS Seems to be incomplete guide to setting up Development hardware DEV/BLENDER.DOC Chapter 15 DEV/DK32.PS Image of Donkey Kong as a RGBA32 texture DEV/DK32SF.PS Upside down image of Diddy kong DEV/GAMESHOP.DOC Chapter 23 DEV/GFXUCODE.DOC Chapter 25 DEV/INSTALLATION.DOC Chapter 1 DEV/IO.DOC Chapter 8 DEV/MAKEFILE makefile to create Postscript versions of the FrameMaker files DEV/MEMORYMGMT.DOC Chapter 9 DEV/MUSICIANMAN.DOC Chapter 20 DEV/OSCORE.DOC Chapter 7 DEV/OSINTRO.DOC Chapter 6 DEV/OVERVIEWCOMPILETIME.DOC Chapter 5 DEV/OVERVIEWHARDWARE.DOC Chapter 3 DEV/OVERVIEWRUNTIME.DOC Chapter 4 DEV/PARTAUDIOTAB.DOC PART files are just collections of chapters DEV/PARTDEVTOOLSTAB.DOC PART files are just collections of chapters DEV/PARTGETSTARTEDTAB.DOC PART files are just collections of chapters DEV/PARTGRAPHICSTAB.DOC PART files are just collections of chapters DEV/PARTINDEXTAB.DOC PART files are just collections of chapters DEV/PARTOSTAB.DOC PART files are just collections of chapters DEV/PARTOVERVIEWTAB.DOC PART files are just collections of chapters DEV/PARTPERFORMANCETAB.DOC PART files are just collections of chapters DEV/PERFORMANCETUNE.DOC Chapter 24 DEV/PERFORMANCETUNE.PS Chapter 24 DEV/PRDEV.BOOK Entire Book file references all the other docs DEV/PRDEVIX.DOC Index DEV/PRDEVLOF.DOC List of Figures DEV/PRDEVLOT.DOC List of Tables DEV/PRDEVTOC.DOC Table of Contents DEV/RDPSTATEMACHINE.DOC Chapter 12 DEV/RSPSTATEMACHINE.DOC Chapter 11 DEV/SCHEDULER.DOC Chapter 22 DEV/SOFTWAREBRINGUP.DOC Programming Manual Chapter 2 DEV/SPRITES.DOC Chapter 16 DEV/SPRITEUCODE.DOC Programming Manual Chapter 18 DEV/STYLE_STRUCTURE.TXT Style guide for the documentation DEV/TEMPLATE.DOC Template used for creating new documentation pages DEV/TEXRECT.DOC Chapter 14 DEV/TEXTURE.DOC Chapter 13 DEV/WALKAPP.DOC Unreleased documentation about a Haunted house demo The file DEV/WALKAPP.DOC seems to have never been released to developers as part of the SDK as it describes a N64 demo where a user walks around a haunted house.DEV/SCRIPTSThis folder just contains the scripts to convert the FrameMaker files into PostScript files. Name Description DEV/SCRIPTS/UPDATE.SCRIPT fmbatch script to update the documentation DEV/SCRIPTS/PRINT_TO_PS.FM   DEV/SCRIPTS/PS.SCRIPT fmbatch script to convert to Postscript RSPThis folder contains all the documentation about programming the Reality Signal Processor. Name Description RSP/ADVANCED.DOC Advanced topics, such as DMEM usage, RSP performance, code overlays, and the CPU-RSP relationship. RSP/APPENDIXA.DOC Formally describes the behavior of each instruction RSP/COP0.DOC Chapter 4 RSP Coprocessor 0 RSP/MAKEFILE Used to make the postscript versions using fmbatch RSP/OVERVIEW.DOC Overview of the documentation chapters RSP/RSPARCH.DOC RSP MIPS Instruction Set Architecture RSP/RSPASM.DOC RSP MIPS Assembly Directives RSP/RSPPROGGUIDE.BOOK Book file that references each doc file RSP/RSPPROGGUIDEIX.DOC Index of the Documentation RSP/RSPPROGGUIDELABELS.FM List of Labels RSP/RSPPROGGUIDELOF.DOC List of Figures RSP/RSPPROGGUIDELOT.DOC List of Tables RSP/RSPPROGGUIDETOC.DOC Table of Contents RSP/RSPREFCARD.FM Reality Signal Processor Programmer’s Reference Card RSP/TITLEPAGE.DOC Title Page of Documentation RSP/VUINST.DOC Vector Unit Instructions RSP/PSThis folder contains the printable postscript versions of the RSP Programming Guide and the Reference card documentation.The reference card is a sort of “Cheat Sheet” for programming on the RSP. Name Description RSP/PS/AA.ZIP Zip archive of the two postscript files in this folder RSP/PS/RSPPROGGUIDE.PS Postscript version of the RSP Programmers Guide RSP/PS/RSPREFCARD.PS Postscript version of the reference card RSP/SCRIPTSThis folder contains scripts to convert the Adobe FrameMaker documentation into printable PostScript files. Name Description RSP/SCRIPTS/UPDATE.SCRIPT fmbatch script to update the doc files RSP/SCRIPTS/PRINT_TO_PS.FM   RSP/SCRIPTS/REFCARD.SCRIPT fmbatchto print the Reference card to Postscript RSP/SCRIPTS/PS.SCRIPT fmbatch to print to Postscript MSP_EXAMPLEThis folder contains pseudo-assembly examples for the Media Signal Processor (MSP) which is basically the RSP. Name Description MSP_EXAMPLE/MSP_TRANSFORM.TXT Transform example code MSP_EXAMPLE/README Describes the purpose of the folder MSP_EXAMPLE/MSP_LIGHT.TXT Example of lighting calculations MSP_EXAMPLE/MSP_SETUP.TXT Example of triangle setup 4300 - The N64 CPUThis folder contains all the RISC Processor Specification for the N64 CPU (NEC VR4300). Name Description 4300/ADDENDUM.DOC Additional details about the CPU 4300/BLOCKWRITE.MIF Converted version of BLOCKWRITE.SUP using supTomif 4300/BLOCKWRITE.SUP   4300/BOOK FrameMaker Book file that references all the Docs 4300/BOOKLOF.DOC List of Figures 4300/BOOKLOT.DOC List of Tables 4300/BOOKTOC.DOC Table of contents 4300/CACHE.DOC Chapter 5 Data and Instruction Cache 4300/CLOCKS.DOC CPU Clocks documentation (on-chip Phase Locked Loop circuit) 4300/CP0.DOC System Control Coprocessor (CP0) 4300/CP0.DOC.RECOVER Old version of CP0.DOC 4300/DELAYEDREAD.MIF Converted version of DELAYEDREAD.SUP using 4300/DELAYEDREAD.SUP Delayed processor read request figure 4300/DIFF.DOC Differences from the R4000 4300/DIFFICE.DOC   4300/ELECTRICAL.DOC Electrical information such as Voltages 4300/EXCP_HAND.DOC Exception Handling 4300/EXECUTION.DOC The instruction execution unit 4300/FMDICTIONARY Adobe FileMaker Dictionary 4300/FUNDAMENTAL.DOC Operation Fundamentals 4300/GLOSSARY.DOC Glossary of Terms 4300/HISTORY.DOC Revision History of the documentation 4300/INTRO.DOC Very short Introduction to the documentation 4300/JTAG.DOC JTAG Interface for the CPU 4300/OVERVIEW.DOC Overview of the five-stage execution pipeline 4300/SYSINTF.DOC Chapter 8 System Interface 4300/TEMP.DOC Template based on the Exception Handling chapter 4300/TESTMODE.DOC Test Mode (JTAG) 4300/TITLE.DOC Title Page of documentation HW & HW2 Folders (Hardware Verilog Models)Verilog is a Hardware Description Language used to Design and verify hardware. The HW and HW2 folders contain Verilog source code for the Nintendo 64 hardware, including the prototype development boards.HW.old contains version 1.0 of the RCP Verilog source code presumably for archival reasons. Verilog For more information about Verilog source code click here INCLUDE FolderThis folder contains header files that are distributed with the official N64 SDK to developers plus some additional headers used for internal tools.Files unique to this directory and not in the SDK are as follows: AudioTools.h DbgDefs.h DbgProto.h DriverD.h Em.h RSP_IPC.h TaskOff.C Trace.h Ultra64.h UltraHost.h verify.hIOSIM Folder (Input Output Simulation)This folder contains code for Input/Output simulation for the Verilog models of the N64 hardware.This seems to be mainly used for testing the prototype N64 hardware while still in development.KERN FolderThis folder contains the source code for the N64 development board kernel so that it can be used from the Indy workstation.This consists of the following folders: INSTALL - source for prinstall which installs the SDK MASTER.D - Boot information for n64 development hardware board SYS - Header files for device driver U64 - Device driver source code for /dev/u64LIB FolderThis folder contains the source code for a variety of different libraries that are not distributed to developers. BRINGUPBOOT - contains code for Boot and pif2Boot, along with IPL4 code LIBAUDIO.SKIP - Old version of the Audio code found in libUltra LIBMPAUDIO - MPEG Audio library (only 2 files) LIBULTRAHOST - Code for functions such as uhOpenGame which communicate with the N64 development hardware ERROR - Seems to be a list of supported Error messages used in libUltra LIBIMAGE - converts libimage.a to libimage.so LIBRCPPLI - Code for librcppli - unknown purpose LIBVID - Huf Mpeg Video LibraryLIBULTRA FolderLibUltra is the official Nintendo 64 development library sent out to all developers in compiled form as part of the official SDK. This folder contains the actual source code for this library.The source code is split into a number of folders based on the specific task: AUDIO - all the Audio functions that start with al in the library GT - Turbo Graphics Utility functions such as gtDumpTurbo GU - all the Graphics functions that start with gu such as guLookAtF IO - Input/Output functions that normally start with os such as osContReset LIBC - Standard C library functions such as sprintf LIBULTRA - Config for creating retail hardware version of libUltra LIBULTRA_D - Config for creating retail hardware version of libUltra with debugging LIBULTRA_EM - Config for creating emulator version of libUltra LIBULTRA_I - Config for creating Indy Workstation version of libUltra LIBULTRA_ROM - Config for creating retail libultra_rom.a library LOG - Debug Functions for logging such as osCreatelog OS - Main operating system functions such as osInitialize RG - Memory region functions such as osMalloc RMON - Reality Monitor functions such as osMalloc SCHED - Scheduler functions such as osCreateScheduler SP - Sprite Library functions such as spMoveMan Folder (Manual Pages)This folder contains all the Manual pages (known as man pages in unix) for the entire N64 development kit.If you ever wonder what a specific tool or function was used for in N64 development then this is the best place to search.During install of the development kit, two versions were created of these files, one in the standard man page location and the other in PostScript file format intended for physically printing out at /usr/src/PR/doc/ps.RDPSIM & RDPSIM2 Folders (Reality Display Processor Simulation)These folders contain two different versions of the Reality Display Processor Simulator. One for RCP 1.0 and the other for RCP 2.0.This was used to help software developers start coding their games while the hardware was still being developed and also as a way to test the hardware while it was being created.RSPASM & RSPASM1201 Folders (Reality Signal Processor Assembler)This folder contains the source code for the Assembler used to compile *.S assembly files into RSP microcode (uCode).To do this they have created a yacc parser grammar file called PARSER.G.Y and a Lexer called PARSER.LX.L. Also included are a few AWK scripts to help the assembler with tasks such as wrapping the file in C code etc.This is a fairly standard way to create an assembler or compiler and it doesn’t take very long to understand the YACC grammar syntax and you can understand how it works.The RSPASM1201 is just a previous version of the RSPASM folder from the 1st of December (12/01) used for regression testing of the RSP.RSPCODE Folder (RSP uCode microcode)This folder contains RSP source code (known as uCode or microcode) for performing a bunch of tasks on the RSP (Reality Signal Processor) chip.These include: AUDIO - playing Sounds and Music using the RSP GRAPHICS - Graphics calculations such as Lighting etc MANTEST - Manufacturing Test Vectors microcode MPAUDIO.DELETED - MPEG audio microcode (deprecated) MPVIDEO.DELETED - MPEG video microcode (deprecated) RSPBOOT - The Boot (Startup) code for the RSP VIDEO - MPEG video microcode grfx_ucode_src.zip - compressed version of the GRAPHICS folderAll the source code requires RSPASM to assemble into object files and then RSP2ELF to convert into an executable file format.RSPSIM Folder (Reality Signal Processor Simulation)This folder contains the source code for a full simulator (emulator) of the RSP (Reality Signal Processor). This was created to allow developers to start writing RSP scripts while the hardware was still being developed.There are a few executables that this source code builds which are: rsp - main simulation executable (CLI version) rspg - main simulation executable (GUI version) rsp_ops - utility to dump the disassembly of the command setThese tools helped 1st party developers (and a few lucky third parties) write and debug their RSP microcode on their workstation without constantly testing on the hardware. N64 RSP - Reality Signal Processor For more information about the RSP check out this page. TOOLS FolderThe Tools folder contains the source code of many of the tools distributed in the Nintendo 64 SDK.There is a Makefile in this directory that can be used to build all of the tools at once.COMPUTILSThe CompUtils folder contains code for a bunch of compiler tools such as nld, gdis, gnm and r4300_check.CONTROLLERThe Controller folder contains example C code for a Unix (IRIX) program that can access a game controller. Probably useful for testing code before the N64 hardware was ready by connecting a controller directly to the IRIX workstation.CONV - multigen database conversion toolsMultigen was a tool for creating 3D models and environments on SGI IRIX workstations and so was ideal for creating 3D graphics for the N64.In fact Nintendo had its own fork of the project specifically for the Nintendo 64 called Ningen. N64 3D Modelling Software For more information about MultiGen and Ningen check out this post on 3D Modelling Software for the N64. The CONV project is source code for a series of tools to convert Multigen models and textures to a format that can be run on the N64. These tools include: flt2c - Convert 3D models in FLT format to C code rgb2c - convert RGB textures to C code ppmquant - reduce colours in pixmap imscale - RGB image scale toolDATA - Verilog data toolsNot sure exactly what these tools are for but something to do with manipulating .data scripts for Verilog.Tools included I n this package are: checkaudio - extracts and verifies audio from Verilog log file checkhex checkimage - extracts and verifies image from Verilog log file checkvideo - extracts image from vi.tab and compare to rgb file data2rdram rdram2data rdram2image rdramgclr bump - creates bump map? dump2mem gbi2memThere seems to be a few tools from converting rdram to data and back but it is not clear what the purpose of this would be.DLPRINT - Print DisplayListsThis folder is the course code for a tool called dlprint that basically sits in a loop waiting for Display Lists to be passed to it and it will print them to the console, very useful for debugging.So how exactly do we pass display lists to the tool? Well it seems to use a macro defined in u64gio.h called DEV_U64_DATA for this purpose and is set to the path: /dev/u64_data.Notice that this is a UNIX device (in /dev folder) so it is used to communicate with the N64 development board that was inside the workstation.It calls a function called uhOpenGame which is defined in the LIBULTRAHOST project in the file OPENGAME.C. It returns a file descriptor if it succeeds.DRIVERD - Driver Daemon startup utilityThis folder contains the source code for a program called driverd which is used to setup the N64 emulation hardware. This program is a daemon so it runs in the background and should only ever be running one instance at any given time.It provides functionality to send commands to running games and read responses. You can use this functionality by using the IRIX device driver for u64. See the dlprint source code above for example code utilising this driver daemon.EMULATE - N64 Emulator by SGIThis folder contains the source code for the emulate executable and the library libem.a. The emulate tool takes in a rom image and a bunch of parameters whether to enable lighting and openGL.This tool is used as a High Level emulator running on the IRIX workstation and forks a process of each of the RSP and RDP simulators to handle the additional chips.GLOAD - Game LoaderThis folder contains the source code for the command gload which is use for loading a ROM into the N64 development board inside the IRIX workstation. Unlike the emulate tool this actually runs the game on real N64 hardware.GPERF - Game Performance ProfilerThe source code for the gperf tool is in this folder, the tool is used to help game developers optimise their code by profiling how much time is spent in each function.MAKEROMThis folder contains the source code for the makerom utility which converts a specfile into a ROM image that can be run on the hardware and also an ELF executable that can be run in the debugger (GVD).KDEBUG - Kernel DebuggerThis folder contains the source code for the Kernel Debugger known as kdebug, this tool was used to send debugging information to and from the N64 development kit hardware inside the IRIX workstation. It used the /dev/u64_kdebug device driver for the communication.GCORD - Code Re-order toolThis folder contains source code for two versions of a tool called gcord, which is similar to the Unix command cord. The purpose is to optimise the game code to fit into the machines cache more efficiently.usr and var foldersThese 2 folders are just extracted versions from the INSTD.tar file at the root of the project, please see the section on that topic for more information.Glossary of TermsThere are a few terms used in the Oman archive that you may not be familiar with, here we try to list the most common ones.MSP - Media Display ProcessorMSP or Media Display Processor is a term thought up by SGI for their co-processor that purely handles graphic data. You probably know this for its later name as it became the Reality Display Processor when it became part of Project Reality (i.e the N64).MBI - Media Binary InterfaceThe Media Binary interface is just a term that refers to the software interface for interacting with the Reality Co-Processor.ASIC - Application-specific integrated circuitUsed in some of the hardware documentation to discuss the Chips created to excel at a single purpose.References Why did N64 emulation hit a reef? : emulation ↩ /vg/ - Emulation General /emugen/ - 4chan ↩ inst - IRIX ↩ master - IRIX ↩ HW/SW CoSim ↩ fm2html ↩ ", "excerpt": "The Oman Archive was a leak of Nintendo Technical documents from a source inside SGI in late 1999. It was uploaded to the internet under the name oman.rar but has since been repackaged into multiple other archive formats, such as the now more common oman.7z (148.3 MB). An updated version...", "tags": ["n64","sdk","leak"], "image": "/public/N64/N64 Oman Archive.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Pokemon Original Source Code Leak", "url": "/pokemon-original-source-code", "content": "On the 11th April 2020 the source code to the original generation of Pokemon games was released to 4chan as osrc.zip. This zip archive contained a password protected zip file called OriginalSouce.zip which was quickly cracked and found that the password was poke1024.This post will cover the contents of the leaked source code.Files Leaked OriginalSouce.zip - 24.6 MBWhen extracted the OriginalSouce.zip file contains the following folders: blue8M - Source code for Pokemon Blue yellow - Source code for Pokemon YellowThe next section will talk about Pokemon Blue.Blue8m (/blue8M) /blue8M This folder contains the entire source code for Pokemon Blue, the files directly in this folder are for assembling the source code into a ROM and even includes a pre-built ROM file (BLUEMONS.ISX). Nintendo used .ISX as the extension for GameBoy ROM files, presumably standing for Intelligent Systems eXecutable as they are built using the Intelligent systems Game Boy development kit. You will also find files with the .ISO extension, these are Intelligent System Object files that are the assembled output of the assembly source code. Assembler used: isdmg - DMG Relocatable Macro Assembler Version 1.21fLinker used: islink - ISASM Linker Version 1.20e This folder also contains the following sub-directories: 検索 - unknown, translates to “search”, Just contains one txt file with embedded messages in it in japanese source - The z80 Assembly source code for the game EFFDATA - Sound effect data Document - Translation documents from Japanese to English MAPDATA - Files which specify which graphic tile goes where on each of the maps DATA - Static data like graphics and boss statistics SXY - Structure data for each map (NPCs etc) MONSDATA - Pokemon Data (graphics?) The files in this folder are described in the table below: File Name Extension Description BLUEMONS .ISX Pre-built Pokemon Blue ROM DMGFUNC .TB0   bluemons .sdb Debug Symbols for the Blue ROM file, contains offsets of each function in the ROM depends .bat, .mak, .mak0 Lists all of the dependencies for each file err .txt Terminal output of runnking assemble/link on the source code link .lnk Link file to tell the Linker how to link everything together into the final ROM makefile N/A Used to build the source code in the folder (run make) makerom .bat Windows Batch file for running mssccprj .scc Microsoft Visual Studio Source Control config file mvmsg .bat Windows Batch file for running readme .txt Short text file that explains DMY_MAP2_EXRAM in Japanese Data (/blue8M/DATA) /DATA This folder contains static data like tables that can be looked up to get specific pokemon and boss statistics. They are all technically assembly files but they just use DefineByte (db) with data in hex format for example: db\t001h,002h,003h,004h,005h,006h,007h,008h\t; Note that whenever the files mention the word “Dealer” they mean “Pokemon Trainer”. The files in this folder are described in the table below: File Name Extension Description ALPHABET .DAT   BADGE .DAT   BANKTOOL .DAT   BDMONS .DAT   BOSS01 .DAT   BOSS02 .DAT   BOSS03 .DAT   BOSS04 .DAT   B_GAUGE .DAT   B_MARUC .DAT   CAST_UP .DAT   CHARA .DAT   CHARI .DAT   DANPEI .DAT   DEALER .DEF   DEALER00 .DAT   DEALER01 .DAT   DEALER02 .DAT   DEALER03 .DAT   DEALER04 .DAT   DEALER05 .DAT   DEALER06 .DAT   DEALER07 .DAT   DEALER08 .DAT   DEALER09 .DAT   DEALER10 .DAT   DEALER11 .DAT   DEALER12 .DAT   DEALER13 .DAT   DEALER14 .DAT   DEALER15 .DAT   DEALER16 .DAT   DEALER17 .DAT   DEALER18 .DAT   DEALER19 .DAT   DEALER20 .DAT   DEALER21 .DAT   DEALER22 .DAT   DEALER23 .DAT   DEALER24 .DAT   DEALER25 .DAT   DEALER26 .DAT   DEALER27 .DAT   DEALER28 .DAT   DEALER29 .DAT   DEALER30 .DAT   DEALER31 .DAT   DEALER32 .DAT   DEALER33 .DAT   DEALER34 .DAT   DEALER41 .DAT   DEALER42 .DAT   DEALER43 .DAT   DEALER44 .DAT   DEALER45 .DAT   DEALERAI .DAT   DEALERNM .DAT   DEALERTB .DAT   DEMO_TIT .DAT   DMONS .DAT, .SYM   ENCOUNT .DAT, .SAV   ENCOUNTB .DAT   ENCOUNTR .DAT   FIGHT .DAT   FONT .DAT   GAUGE .DAT   GAUGE_B .DAT   HANAHANA .DAT   HERO .DAT   ITEMGOLD .DAT   ITEMMENU .DAT, .SAV   ITEMNAME .DAT, .SAV   JIKI .DAT   JIKI_BLU .DAT   JI_BACK .DAT   JUMPDAI .DAT   KASYA1 .DAT   KASYA2 .DAT   KASYA3 .DAT   KASYA4 .DAT   KOMONO .DAT   LOGOVER .DAT   MAPJIKI .DAT   MARUSHI .DAT   MARUSHI2 .DAT   MARUSI_N .DAT   MY_BACK .DAT   NUSI_01 .DAT   NUSI_02 .DAT   NUSI_03 .DAT   NUSI_04 .DAT   NUSI_05 .DAT   NUSI_06 .DAT   NUSI_07 .DAT   NUSI_08 .DAT   N_GAUGE .DAT   OBJ01 .DAT   OBJ02 .DAT   OBJ03 .DAT   OBJ04 .DAT   OBJ05 .DAT   OBJ06 .DAT   OBJ_01 .DAT   OBJ_02 .DAT   OBJ_03 .DAT   OBJ_04 .DAT   OBJ_05 .DAT   OBJ_06 .DAT   OKI01 .DAT   OP_BG .DAT   OP_OBJ .DAT   OP_PURIN .DAT   PMTIT .DAT   PSY .DAT   RAPLUS .DAT   RDMONS .DAT   RIVAL .DAT   SERIFU .DAT   SERIFU_B .DAT   SHINKA .DAT, .SAV   SLOT1 .DAT   SLOT_BG .DAT   SLOT_OB .DAT   STATUSX .DAT   THEEND .DAT   TITLCAP2 .DAT   TITLE03 .DAT   TITLE04 .DAT   TITLE_JI .DAT   TRADE_AN .DAT   VANISH .DAT   WAZAGOLD .DAT   WAZANAME .DAT   WAZA_SE .DAT, .H   WAZA_TBL .DAT, .SAV   WORLDMAP .DAT   YUUICHI .DAT   ZUKAN .DAT   err .txt   font_us .dat   Document (/blue8M/Document) /Document This folder contains documentation related to translation of the game into english and also general data on bugs found during development. The .dmg0 files are not assembly code but seem to be a custom scripting language for dialog, where each message has a unique id and a end of message character ({EOMeom}), for example; message_id:msg1_0_R06R0201//ちかつうろは　うすぐらいから{home@}//おとしもの　おおいんですって{EOMeom}People often lose{home@}things in that{gyo3@}UNDERGROUND PATH.{EOMeom} This folder also contains the following sub-directories: translation -</div> </section> The files in this folder are described in the table below: File Name Extension Description POFINAL .XLS Final version of tranlation of Pokemon names from japanese to English POKEMO10 .DOC   bugs .txt Talks about bugs such as the save data being corrupted when the user turns off the Game Boy before finishing save err .txt The terminal output of comparing the two files i_msg2_2.dmg0 and 2-2-33.txt which seem to be identical. fontdef .xls Contains two tables with 256 cells, one for the japanese font and the other for the english includng all the special characters like PKMN i_msg2_0 .dmg0 English translations for phrases like “Not even a nibble!” and more i_msg2_1 .dmg0 English translations for dialog on Sylph Corporation 6th floor and more i_msg2_2 .dmg0 English translations for dialog outside hotel and more i_msg2_3 .dmg0 English translations for dialog i_msg2_4 .dmg0 English translations for dialog i_msg2_5 .dmg0 English translations for dialog i_msg2_6 .dmg0 English translations for dialog i_msg2_7 .dmg0 English translations for dialog i_msg2_8 .dmg0 English translations for dialog i_msg2_9 .dmg0 English translations for dialog i_msg2_a .dmg0 English translations for dialog logo .txt Seems to be an Adobe Illustrator file for the logo but with .txt extension for some reason pmfile .dat0 Pokedex data such as height/weight and english text (japanese text as comments) poke_ram .xls Contains tables showing the layout in ram for the pokemon data, like name, status (sleeping, poisoned etc) pokemon_map .txt Very useful document describing each of the maps pokescript .txt Describes the dialog scripting format called pokescript and special variables such as {gyo3@} or {cr@} (carriage return) readme .txt Same as pokescript.txt schedule .txt The planned release schedule for releasing Pokemon to the US market water_enc .txt Japanese document describing where to capture pokemon in the water with the Fishing rod その他テキスト .txt Translations for pokemon types and dialogs その他テキスト2 .txt List of all the pokemon types (e.g water,fire etc) in Japanese その他テキスト3 .txt Talks about the different states a pokemon can be in like sleeping 英語メッセージ未入力 .txt Talks about garbase data where the english text is missing Translation (/blue8M/Document/translation) /translation This folder contains… This folder also contains the following sub-directories: old -</div> </section> The files in this folder are described in the table below: File Name Extension Description 2-0-17 .txt   2-1-18 .txt   2-2-34 .txt   2-3-19 .txt   2-4-21 .txt   2-5-27 .txt   2-6-17 .txt   2-7-13 .txt   2-8-16 .txt   2-9-21 .txt   2-a-7 .txt   Zukan-9 .txt   err .txt   Old translation documents (/blue8M/Document/translation/old) /old This folder contains… The files in this folder are described in the table below: File Name Extension Description 2-0-1 .TXT   2-0-10 .txt   2-0-11 .txt   2-0-12 .txt   2-0-13 .txt   2-0-14 .txt   2-0-15 .txt   2-0-16 .txt   2-0-2 .TXT   2-0-3 .txt   2-0-4 .txt   2-0-5 .txt   2-0-6 .txt   2-0-7 .txt   2-0-8 .txt   2-0-9 .txt   2-1-1 .TXT   2-1-10 .txt   2-1-11 .txt   2-1-12 .txt   2-1-13 .txt   2-1-14 .txt   2-1-15 .txt   2-1-16 .txt   2-1-17 .txt   2-1-2 .txt   2-1-3 .txt   2-1-4 .txt   2-1-5 .txt   2-1-6 .txt   2-1-7 .txt   2-1-8 .txt   2-1-9 .txt   2-2-1 .txt   2-2-10 .txt   2-2-11 .txt   2-2-12 .txt   2-2-13 .txt   2-2-14 .txt   2-2-15 .txt   2-2-16 .txt   2-2-17 .txt   2-2-18 .txt   2-2-19 .txt   2-2-2 .txt   2-2-20 .txt   2-2-21 .txt   2-2-22 .txt   2-2-23 .txt   2-2-24 .txt   2-2-25 .txt   2-2-26 .txt   2-2-27 .txt   2-2-28 .txt   2-2-29 .txt   2-2-3 .TXT   2-2-30 .txt   2-2-31 .txt   2-2-32 .txt   2-2-33 .txt   2-2-4 .TXT   2-2-6 .TXT   2-2-7 .txt   2-2-8 .txt   2-2-9 .txt   2-3-1 .txt   2-3-10 .txt   2-3-11 .txt   2-3-12 .txt   2-3-13 .txt   2-3-14 .txt   2-3-15 .txt   2-3-16 .txt   2-3-17 .txt   2-3-18 .txt   2-3-2 .TXT   2-3-3 .txt   2-3-4 .txt   2-3-5 .txt   2-3-6 .txt   2-3-7 .txt   2-3-8 .txt   2-3-9 .txt   2-4-1 .txt   2-4-10 .txt   2-4-11 .txt   2-4-12 .txt   2-4-13 .txt   2-4-14 .txt   2-4-15 .txt   2-4-16 .txt   2-4-17 .txt   2-4-18 .txt   2-4-19 .txt   2-4-2 .TXT   2-4-20 .txt   2-4-3 .TXT   2-4-4 .TXT   2-4-5 .txt   2-4-6 .txt   2-4-7 .txt   2-4-8 .txt   2-4-9 .txt   2-5-1 .txt   2-5-10 .txt   2-5-11 .txt   2-5-12 .txt   2-5-13 .txt   2-5-14 .txt   2-5-15 .txt   2-5-16 .txt   2-5-17 .txt   2-5-18 .txt   2-5-19 .txt   2-5-2 .TXT   2-5-20 .txt   2-5-21 .txt   2-5-22 .txt   2-5-23 .txt   2-5-24 .txt   2-5-25 .txt   2-5-26 .txt   2-5-3 .TXT   2-5-4 .TXT   2-5-5 .TXT   2-5-6 .TXT   2-5-7 .txt   2-5-8 .txt   2-5-9 .txt   2-6-1 .txt   2-6-10 .txt   2-6-11 .txt   2-6-12 .txt   2-6-13 .txt   2-6-14 .txt   2-6-15 .txt   2-6-16 .txt   2-6-2 .txt   2-6-3 .txt   2-6-4 .txt   2-6-5 .txt   2-6-6 .txt   2-6-7 .txt   2-6-8 .txt   2-6-9 .txt   2-7-1 .txt   2-7-10 .txt   2-7-11 .txt   2-7-12 .txt   2-7-2 .txt   2-7-3 .txt   2-7-4 .txt   2-7-5 .txt   2-7-6 .txt   2-7-7 .txt   2-7-8 .txt   2-7-9 .txt   2-8-1 .txt   2-8-10 .txt   2-8-11 .txt   2-8-12 .txt   2-8-13 .txt   2-8-14 .txt   2-8-15 .txt   2-8-2 .TXT   2-8-3 .txt   2-8-4 .txt   2-8-5 .txt   2-8-6 .txt   2-8-7 .txt   2-8-8 .txt   2-8-9 .txt   2-9-1 .TXT   2-9-10 .txt   2-9-11 .txt   2-9-12 .txt   2-9-13 .txt   2-9-14 .txt   2-9-15 .txt   2-9-16 .txt   2-9-17 .txt   2-9-18 .txt   2-9-19 .txt   2-9-2 .txt   2-9-20 .txt   2-9-3 .txt   2-9-4 .txt   2-9-5 .txt   2-9-6 .txt   2-9-7 .txt   2-9-8 .txt   2-9-9 .txt   2-A-1 .txt   2-a-2 .txt   2-a-3 .txt   2-a-4 .txt   2-a-5 .txt   2-a-6 .txt   ZUKAN-1 .TXT   ZUKAN-3 .TXT   Zukan-4 .txt   Zukan-5 .txt   Zukan-6 .txt   Zukan-7 .txt   Zukan-8 .txt   zukan-2 .txt   Effect Data (/blue8M/EFFDATA) /EFFDATA This folder contains all the Super Game Boy data and possibly sound effect data? The files in this folder are described in the table below: File Name Extension Description BLSLOTBG .DAT   CAPTURE .DAT   COL_BLUE .DAT   COL_RE .COL   COL_RED .DAT   DEMO_TIT .DAT   EF0 .DAT   EF1 .DAT   FLAME1 .DAT   HYDRO1 .DAT   MARUMARU .DAT   MIZU .DAT Water? MUSI .DAT   PF_BLUE .CGX, .MAP   PF_COL .COL   PF_COLOR .COX   PF_GRE .CGX, .MAP Super GameBoy Data PF_GRE2 .CGX, .COL, .MAP Super GameBoy Data PF_GREEN .MAP Super GameBoy Data PF_RED .CGX, .COL, .MAP Super GameBoy Data PF_RED2 .CGX, .COL, .MAP Super GameBoy Data PICT_F .DAT   RYDEEN1 .DAT   SGB_PF .CGX, .COL, .MAP   SGB_PF2 .MAP   SIMPHIT .DAT   SLOTBG_B .DAT   SLOTOB_B .DAT   SLOTOB_R .DAT   STATNAME .DAT   STATNO .DAT   STATUS1 .DAT   STATWAKU .DAT   TEST1 .COX   TETSU .DAT   TURI .DAT   Map Data (/blue8M/MAPDATA) /MAPDATA This folder contains all the character tiles for each of the maps along with the actual layouts of the maps.. The .MAP files contain the layout of each of the screens and are actually just assembly files using Define Byte (db) for each of the graphic tiles in the map, for example: ; Map size\tX = 10 Y = 9; Page size\tPX = 1 PY = 1\tdb\t016h,06bh,06ah,017h\tdb\t002h,009h,008h,001h\tdb\t018h,06ch,069h,019h This folder contains .CEL files that contain the character tile graphics. Presumably the C stands for Character but we are unsure what the E and L stands for in the extension.The .CHR files are character file graphics too? The files in this folder are described in the table below: File Name Extension Description 1 .CEL Character Tiles for ? 11_18GAT .MAP Gate on route 11 and 18? 12GATE .MAP Gate on route 12 16_GATE .MAP Gate on route 16 22GATE .MAP Pokémon League Reception Gate 5_6GATE .MAP Gate between Lavender Town and Vermillion City 7_8GATE .MAP Gate between ARASARE .CEL, .CHR, .MAP   AZITO_B1 .MAP Rocket HQ Basement 1 AZITO_B2 .MAP Rocket HQ Basement 2 AZITO_B3 .MAP Rocket HQ Basement 3 AZITO_B4 .MAP Rocket HQ Basement 4 AZITO_EL .MAP Rocket HQ ? AZITO_R1 .MAP Rocket HQ ? AZITO_R2 .MAP Rocket HQ ? AZITO_R3 .MAP Rocket HQ ? BILDING .CEL   BOSSDOJO .MAP   BTOWN_B1 .DAT   BUILDING .CEL, .DAT   BULDING .CEL   CHAMPCUP .CEL, .CHR, .MAP   CICLE .CEL, .DAT, .MAP Bicycle Shop COLOSEUM .MAP   CYCLE .CEL, .DAT, .MAP   DAIMANIA .CEL, .DAT   DAISUKI .MAP   DENDOU .MAP   DENDOU2 .MAP   DEPELV .MAP   DEPT .CEL, .DAT Celadon Department Store Graphics DEPT1F .MAP Celadon Department Store 1F DEPT2F .MAP Celadon Department Store 2F DEPT3F .MAP Celadon Department Store 3F DEPT4F .MAP Celadon Department Store 4F DEPT5F .MAP Celadon Department Store 5F DEPT6F .MAP Celadon Department Store 6F DGN01 .CEL, .DAT, .MAP   DGN02 .CEL, .DAT, .MAP   DGN04 .MAP   DGN05 .MAP   DGN06 .MAP   DOJO .MAP Gym Graphics DOJO_01 .MAP Early Gym 1 DOJO_02 .MAP Early Gym 2 DOJO_03 .MAP Early Gym 3 DOJO_04 .MAP Early Gym 4 DOJO_05 .MAP Early Gym 5 DOJO_06 .MAP Early Gym 6 DOJO_07 .MAP Early Gym 7 DOJO_08 .MAP Early Gym 8 DONATA .MAP   DUN02 .CEL   END01 .MAP   END02 .MAP   END03 .MAP   FIRE_DUN .MAP   GATE .CEL, .DAT   GATE2F .MAP   GATEHAKU .CEL, .DAT   GYM .CEL, .DAT Gym graphics GYM_01 .MAP Gym 1 GYM_02 .MAP Gym 2 GYM_03 .MAP Gym 3 GYM_04 .MAP Gym 4 GYM_05 .MAP Gym 5 GYM_06 .MAP Gym 6 GYM_07 .MAP Gym 7 GYM_08 .MAP Gym 8 HAKUBU1F .MAP Science Museum 1F HAKUBU2F .MAP Science Museum 2F HAKUBUTU .DAT   HONBU1 .MAP Headquarters 1 HONBU2 .MAP Headquarters 2 HONBU3 .MAP Headquarters 3 HOTEL .CEL, .CHR, .DAT, .MAP Standard Pokemon Center map HYOUSIKI .DAT   IWAMIN .MAP   IWANUKE_ .MAP   IWA_1F .MAP   IWA_2F .MAP   JIMKYOK .MAP   JIMSHO .MAP   JISAN .MAP Unused Grandpa’s House KAICHO_5 .MAP   KENKYU .CEL, .DAT, .MAP   KENKYU_1 .MAP   KENKYU_2 .MAP   KENKYU_3 .MAP   KENKYU_4 .MAP   KENKYU_S .MAP   KOKANJO .MAP   LASTBOSS .MAP   MANIA .DAT, .MAP   MANSH01 .MAP   MANSH02 .MAP   MANSH03 .MAP   MANSH04 .MAP   MANSHO .CEL, .DAT   MANSHO1 .CEL   MAP_TBL .DAT   MDUN_1 .MAP   MDUN_2 .MAP   MDUN_3 .MAP   MDUN_4 .CEL, .MAP   MDUN_5 .MAP   MDUN_6 .MAP   MINKA_A .CEL, .DAT, .MAP Minka is a japanese house MINKA_B .CEL, .MAP House MINKA_C .MAP House destroyed by pokemon MINKA_D .MAP House MISEYADO .CEL, .DAT   NEND01 .MAP Forgotten Cave NEND02 .MAP   NEND03 .MAP   NEW_IWA1 .MAP   NEW_IWA2 .MAP   NHOTEL .MAP New version of Pokemon Center NIWA .MAP Unused test map NROAD_01 .DAT, .MAP Route 1 NROAD_02 .DAT, .MAP Route 2 NROAD_03 .DAT, .MAP Route 3 NROAD_04 .DAT, .MAP Route 4 NROAD_05 .DAT, .MAP Route 5 NROAD_06 .DAT, .MAP Route 6 NROAD_07 .DAT, .MAP Route 7 NROAD_08 .DAT, .MAP Route 8 NROAD_09 .DAT, .MAP Route 9 NROAD_10 .DAT, .MAP Route 10 NROAD_11 .DAT, .MAP Route 11 NROAD_12 .DAT, .MAP Route 12 NROAD_13 .DAT, .MAP Route 13 NROAD_14 .DAT, .MAP Route 14 NROAD_15 .DAT, .MAP Route 15 NROAD_16 .DAT, .MAP Route 16 NROAD_17 .DAT, .MAP Route 17 NROAD_18 .DAT, .MAP Route 18 NROAD_19 .DAT, .MAP Route 19 NROAD_20 .DAT, .MAP Route 20 NROAD_21 .DAT, .MAP Route 21 NROAD_22 .DAT, .MAP Route 22 NROAD_23 .DAT, .MAP Route 23 NROAD_24 .DAT, .MAP Route 24 NROAD_25 .DAT, .MAP Route 25 NSILF_1 .MAP Silph Co. 1 NSILF_2 .MAP Silph Co. 2 NSILF_3 .MAP Silph Co. 3 NSILF_4 .MAP Silph Co. 4 NSILF_5 .MAP Silph Co. 5 NTOWER .CEL, .DAT   NTOWN_01 .CEL, .DAT, .MAP   NTOWN_02 .MAP   NTOWN_03 .MAP   NTOWN_04 .DAT, .MAP   NTOWN_05 .DAT, .MAP   NTOWN_06 .DAT, .MAP   NTOWN_07 .DAT, .MAP   NTOWN_08 .DAT, .MAP   NTOWN_09 .DAT, .MAP   NTOWN_10 .DAT, .MAP   NTOWN_11 .DAT   NTOWN_12 .DAT   NTOWN_T .DAT, .MAP   NT_1F .MAP   NT_2F .MAP   NT_3F .MAP   NT_4F .MAP   NT_5F .MAP   NT_6F .MAP   NT_7F .MAP   NT_EL .MAP   NUKE .CEL, .DAT   NUKE5_6 .MAP   NUKEMIN .MAP   OHKIDO .MAP   ORI .MAP   OTUKI_B1 .MAP   OTUKI_B2 .MAP   OTUKI_B3 .MAP   PACHNCO .CEL, .MAP   POKECEN .CEL, .DAT, .MAP   POKECHR .CEL   POKESEN .CEL, .DAT   POKE_1F .CEL, .MAP   POKE_2F .CEL, .MAP   POKE_3F .MAP   POKE_B1 .CEL, .MAP   PORT .CEL, .DAT, .MAP   PREAGUE .MAP   R1_CHR .DAT   R1_ENC .DAT   ROAD1 .DAT   ROAD10 .DAT   ROAD11 .DAT   ROAD12 .DAT   ROAD13 .DAT   ROAD14 .DAT   ROAD15 .DAT   ROAD16 .DAT   ROAD17 .DAT   ROAD18 .DAT   ROAD19 .DAT   ROAD1T .DAT   ROAD2 .DAT   ROAD20 .DAT   ROAD21 .DAT   ROAD22 .DAT   ROAD23 .DAT   ROAD24 .DAT   ROAD25 .DAT   ROAD3 .DAT   ROAD4 .DAT   ROAD5 .DAT   ROAD6 .DAT   ROAD7 .DAT   ROAD8 .DAT   ROAD9 .DAT   ROOM .CEL, .DAT Player’s House ROOM1F .CEL, .DAT, .MAP Downstairs of the Player’s House ROOM1~00 .ORG   ROOM2F .CEL, .DAT, .MAP Upstairs of the Player’s House ROOM2~00 .ORG   ROOMCELL .DAT   ROOMIMG .DAT   SAFACELL .CEL   SAFARI_1 .MAP   SAFARI_2 .MAP   SAFARI_3 .MAP   SAFARI_4 .MAP   SCFOOL .CEL   SCHOOL .CEL, .DAT, .MAP   SCLCELL .DAT   SCLCE~00 .ORG   SCLIMG .DAT   SEKISHO .CEL, .DAT, .MAP   SHIP .CEL, .DAT   SHOKUDO .MAP   SHOP .CHR, .MAP PokeMart map SHOP1 .DAT   SHOPCELL .DAT   SHOPIMG .DAT   SHOP~~00 .ORG   SHROOM1 .MAP   SHROOM2 .MAP   SHROOM3 .MAP   SHROOM4 .MAP   SILE_B4 .MAP   SILF_11F .MAP   SILF_1F .MAP   SILF_2F .MAP   SILF_3F .MAP   SILF_4F .MAP   SILF_5F .MAP   SILF_B1 .MAP   SILF_B2 .MAP   SILF_B3 .MAP   SILF_B3A .MAP   SILF_B3B .MAP   SILF_B4 .MAP   SILF_B5 .MAP   SILF_B6 .MAP   SILF_B7 .MAP   SILF_B8 .MAP   SKOYA_1 .MAP Safari Zone rest house SKOYA_2 .MAP Unused Safari Zone rest house STANNU .CEL, .DAT   STANNU01 .MAP   STANNU02 .MAP   STANNU03 .MAP   STANNU04 .MAP   STANNU05 .MAP   T6S2 .DAT   TORI_1F .MAP   TORI_B1 .MAP   TORI_B2 .MAP   TOWER .CEL, .DAT   TOWER1F .MAP   TOWER2F .MAP   TOWER3F .MAP   TOWER4F .MAP   TOWER5F .MAP   TOWER6F .MAP   TOWER7F .MAP   TOWN1 .DAT   TOWN10 .DAT   TOWN11 .DAT   TOWN12 .DAT   TOWN2 .DAT   TOWN3 .DAT   TOWN4 .DAT   TOWN5 .DAT   TOWN6 .DAT   TOWN7 .DAT   TOWN8 .DAT   TOWN9 .DAT   TOWNCELL .DAT   TOWNIMG2 .DAT   TOWN_B1 .CEL, .DAT   TRADE .MAP   TRAINING .CEL, .MAP Unused Broken room TURI .MAP   UMIIE .MAP   YDUN_1 .MAP   Monsdata (/blue8M/MONSDATA) /MONSDATA This folder contains… The files in this folder are described in the table below: File Name Extension Description DEALER26 .DAT   KABUBONE .DAT   KAIHATSU .DAT   MONSB100 .DAT   MONSB101 .DAT   MONSB102 .DAT   MONSB103 .DAT   MONSB104 .DAT   MONSB105 .DAT   MONSB106 .DAT   MONSB107 .DAT   MONSB108 .DAT   MONSB109 .DAT   MONSB110 .DAT   MONSB111 .DAT   MONSB112 .DAT   MONSB113 .DAT   MONSB114 .DAT   MONSB116 .DAT   MONSB117 .DAT   MONSB118 .DAT   MONSB119 .DAT   MONSB120 .DAT   MONSB122 .DAT   MONSB123 .DAT   MONSB124 .DAT   MONSB125 .DAT   MONSB126 .DAT   MONSB127 .DAT   MONSB128 .DAT   MONSB129 .DAT   MONSB130 .DAT   MONSB131 .DAT   MONSB132 .DAT   MONSB133 .DAT   MONSB134 .DAT   MONSB136 .DAT   MONSB137 .DAT   MONSB138 .DAT   MONSB139 .DAT   MONSB140 .DAT   MONSB141 .DAT   MONSB142 .DAT   MONSB143 .DAT   MONSB144 .DAT   MONSB145 .DAT   MONSB146 .DAT   MONSB147 .DAT   MONSB148 .DAT   MONSB149 .DAT   MONSB150 .DAT   MONSB151 .DAT   MONSB152 .DAT   MONSB153 .DAT   MONSB154 .DAT   MONSB155 .DAT   MONSB156 .DAT   MONSB157 .DAT   MONSB158 .DAT   MONSB159 .DAT   MONSB160 .DAT   MONSB161 .DAT   MONSB162 .DAT   MONSB163 .DAT   MONSB164 .DAT   MONSB165 .DAT   MONSB166 .DAT   MONSB167 .DAT   MONSB168 .DAT   MONSB169 .DAT   MONSB170 .DAT   MONSB171 .DAT   MONSB172 .DAT   MONSB173 .DAT   MONSB174 .DAT   MONSB175 .DAT   MONSB176 .DAT   MONSB177 .DAT   MONSB178 .DAT   MONSB179 .DAT   MONSB180 .DAT   MONSB181 .DAT   MONSB185 .DAT   MONSB186 .DAT   MONSB187 .DAT   MONSB188 .DAT   MONSB189 .DAT   MONSB190 .DAT   MONSBK01 .DAT   MONSBK02 .DAT   MONSBK03 .DAT   MONSBK04 .DAT   MONSBK05 .DAT   MONSBK06 .DAT   MONSBK07 .DAT   MONSBK08 .DAT   MONSBK09 .DAT   MONSBK10 .DAT   MONSBK11 .DAT   MONSBK12 .DAT   MONSBK13 .DAT   MONSBK14 .DAT   MONSBK15 .DAT   MONSBK16 .DAT   MONSBK17 .DAT   MONSBK18 .DAT   MONSBK19 .DAT   MONSBK20 .DAT   MONSBK21 .DAT   MONSBK22 .DAT   MONSBK23 .DAT   MONSBK24 .DAT   MONSBK25 .DAT   MONSBK26 .DAT   MONSBK27 .DAT   MONSBK28 .DAT   MONSBK29 .DAT   MONSBK30 .DAT   MONSBK31 .DAT   MONSBK32 .DAT   MONSBK33 .DAT   MONSBK34 .DAT   MONSBK35 .DAT   MONSBK36 .DAT   MONSBK37 .DAT   MONSBK38 .DAT   MONSBK39 .DAT   MONSBK40 .DAT   MONSBK41 .DAT   MONSBK42 .DAT   MONSBK43 .DAT   MONSBK44 .DAT   MONSBK45 .DAT   MONSBK46 .DAT   MONSBK47 .DAT   MONSBK48 .DAT   MONSBK49 .DAT   MONSBK50 .DAT   MONSBK51 .DAT   MONSBK52 .DAT   MONSBK53 .DAT   MONSBK54 .DAT   MONSBK55 .DAT   MONSBK56 .DAT   MONSBK57 .DAT   MONSBK58 .DAT   MONSBK59 .DAT   MONSBK60 .DAT   MONSBK61 .DAT   MONSBK62 .DAT   MONSBK63 .DAT   MONSBK64 .DAT   MONSBK65 .DAT   MONSBK66 .DAT   MONSBK67 .DAT   MONSBK68 .DAT   MONSBK69 .DAT   MONSBK70 .DAT   MONSBK71 .DAT   MONSBK72 .DAT   MONSBK73 .DAT   MONSBK74 .DAT   MONSBK75 .DAT   MONSBK76 .DAT   MONSBK77 .DAT   MONSBK78 .DAT   MONSBK79 .DAT   MONSBK80 .DAT   MONSBK81 .DAT   MONSBK82 .DAT   MONSBK83 .DAT   MONSBK84 .DAT   MONSBK85 .DAT   MONSBK86 .DAT   MONSBK87 .DAT   MONSBK88 .DAT   MONSBK89 .DAT   MONSBK90 .DAT   MONSBK91 .DAT   MONSBK92 .DAT   MONSBK93 .DAT   MONSBK94 .DAT   MONSBK95 .DAT   MONSBK96 .DAT   MONSBK97 .DAT   MONSBK98 .DAT   MONSBK99 .DAT   MONSC182 .DAT   MONSC183 .DAT   MONSC184 .DAT   MONSDATA .DAT, .OV, .OVB   MONSNAM2 .DAT   MONSNAME .DAT   MONSTBL .DAT   ORDER .DAT   PM2F_001 .DAT   PM2F_002 .DAT   PM2F_003 .DAT   PM2F_004 .DAT   PM2F_005 .DAT   PM2F_006 .DAT   PM2F_007 .DAT   PM2F_008 .DAT   PM2F_009 .DAT   PM2F_010 .DAT   PM2F_011 .DAT   PM2F_012 .DAT   PM2F_013 .DAT   PM2F_014 .DAT   PM2F_015 .DAT   PM2F_016 .DAT   PM2F_017 .DAT   PM2F_018 .DAT   PM2F_019 .DAT   PM2F_020 .DAT   PM2F_021 .DAT   PM2F_022 .DAT   PM2F_023 .DAT   PM2F_024 .DAT   PM2F_025 .DAT   PM2F_026 .DAT   PM2F_027 .DAT   PM2F_028 .DAT   PM2F_029 .DAT   PM2F_030 .DAT   PM2F_031 .DAT   PM2F_032 .DAT   PM2F_033 .DAT   PM2F_034 .DAT   PM2F_035 .DAT   PM2F_036 .DAT   PM2F_037 .DAT   PM2F_038 .DAT   PM2F_039 .DAT   PM2F_040 .DAT   PM2F_041 .DAT   PM2F_042 .DAT   PM2F_043 .DAT   PM2F_044 .DAT   PM2F_045 .DAT   PM2F_046 .DAT   PM2F_047 .DAT   PM2F_048 .DAT   PM2F_049 .DAT   PM2F_050 .DAT   PM2F_051 .DAT   PM2F_052 .DAT   PM2F_053 .DAT   PM2F_054 .DAT   PM2F_055 .DAT   PM2F_056 .DAT   PM2F_057 .DAT   PM2F_058 .DAT   PM2F_059 .DAT   PM2F_060 .DAT   PM2F_061 .DAT   PM2F_062 .DAT   PM2F_063 .DAT   PM2F_064 .DAT   PM2F_065 .DAT   PM2F_066 .DAT   PM2F_067 .DAT   PM2F_068 .DAT   PM2F_069 .DAT   PM2F_070 .DAT   PM2F_071 .DAT   PM2F_072 .DAT   PM2F_073 .DAT   PM2F_074 .DAT   PM2F_075 .DAT   PM2F_076 .DAT   PM2F_077 .DAT   PM2F_078 .DAT   PM2F_079 .DAT   PM2F_080 .DAT   PM2F_081 .DAT   PM2F_082 .DAT   PM2F_083 .DAT   PM2F_084 .DAT   PM2F_085 .DAT   PM2F_086 .DAT   PM2F_087 .DAT   PM2F_088 .DAT   PM2F_089 .DAT   PM2F_090 .DAT   PM2F_091 .DAT   PM2F_092 .DAT   PM2F_093 .DAT   PM2F_094 .DAT   PM2F_095 .DAT   PM2F_096 .DAT   PM2F_097 .DAT   PM2F_098 .DAT   PM2F_099 .DAT   PM2F_100 .DAT   PM2F_101 .DAT   PM2F_102 .DAT   PM2F_103 .DAT   PM2F_104 .DAT   PM2F_105 .DAT   PM2F_106 .DAT   PM2F_107 .DAT   PM2F_108 .DAT   PM2F_109 .DAT   PM2F_110 .DAT   PM2F_111 .DAT   PM2F_112 .DAT   PM2F_113 .DAT   PM2F_114 .DAT   PM2F_115 .DAT   PM2F_116 .DAT   PM2F_117 .DAT   PM2F_118 .DAT   PM2F_119 .DAT   PM2F_120 .DAT   PM2F_121 .DAT   PM2F_122 .DAT   PM2F_123 .DAT   PM2F_124 .DAT   PM2F_125 .DAT   PM2F_126 .DAT   PM2F_127 .DAT   PM2F_128 .DAT   PM2F_129 .DAT   PM2F_130 .DAT   PM2F_131 .DAT   PM2F_132 .DAT   PM2F_133 .DAT   PM2F_134 .DAT   PM2F_135 .DAT   PM2F_136 .DAT   PM2F_137 .DAT   PM2F_138 .DAT   PM2F_139 .DAT   PM2F_140 .DAT   PM2F_141 .DAT   PM2F_142 .DAT   PM2F_143 .DAT   PM2F_144 .DAT   PM2F_145 .DAT   PM2F_146 .DAT   PM2F_147 .DAT   PM2F_148 .DAT   PM2F_149 .DAT   PM2F_150 .DAT   PM2F_151 .DAT   PM2F_MYU .DAT   PM2F_TES .DAT   PMDUMMY .DAT   PMFILE .DAT, .OV, .OVB   PUTEBONE .DAT   Map Structure (/blue8M/SXY) /SXY This folder contains the map stucture data such as the locations of NPCs and signs. The files are named in a specic way: First character is the type T for Town D for Dungeon R for Route? Second and third characters are the number of that specifc type T01 is Pallet Town T02 is Viridian City T03 is Pewter City T04 is Cerulean City T05 is Lavender Town T06 is Vermillion City T07 is Celadon City T08 is Fuchsia City T09 is Cinnabar Island T10 is Indigo Plateau T11 is Saffron City Fourth character is R presumable standing for Room</div> </section> The files in this folder are described in the table below: File Name Extension Description D01R0101 .SXY   D02R0101 .SXY   D02R0102 .SXY   D02R0103 .SXY   D03R0101 .SXY S.S. Anne D03R0102 .SXY   D03R0103 .SXY   D03R0104 .SXY   D03R0105 .SXY   D03R0106 .SXY   D03R0107 .SXY   D03R0108 .SXY   D03R0109 .SXY   D03R0110 .SXY   D03R0111 .SXY S.S. Anne Cabins D03R0112 .SXY   D03R0113 .SXY   D03R0114 .SXY   D03R0115 .SXY   D03R0116 .SXY   D03R0117 .SXY   D03R0118 .SXY   D03R0119 .SXY   D03R0120 .SXY   D03R0121 .SXY   D03R0122 .SXY   D03R0123 .SXY   D03R0124 .SXY S.S. Anne Cabins D04R0101 .SXY   D05R0101 .SXY   D06R0101 .SXY   D07R0101 .SXY   D08R0101 .SXY   D08R0102 .SXY   D09R0101 .SXY   D09R0102 .SXY   D09R0103 .SXY   D09R0104 .SXY   D09R0105 .SXY   D10R0101 .SXY   D10R0102 .SXY   D10R0103 .SXY   D10R0104 .SXY   D10R0105 .SXY   D10R0106 .SXY   D10R0107 .SXY   D10R0108 .SXY   D10R0109 .SXY   D10R0110 .SXY   D10R0111 .SXY   D10R0112 .SXY   D10R0201 .SXY   D10R0202 .SXY   D10R0203 .SXY   D10R0204 .SXY   D11R0101 .SXY   D11R0102 .SXY   D11R0103 .SXY   D12R0101 .SXY   D12R0102 .SXY   D12R0103 .SXY   D12R0104 .SXY   D12R0105 .SXY   D12R0106 .SXY   D12R0107 .SXY   D12R0108 .SXY   D12R0109 .SXY   D13R0101 .SXY   D13R0102 .SXY   D14R0101 .SXY   D14R0102 .SXY   D14R0103 .SXY   D14R0104 .SXY   D14R0105 .SXY   D14R0106 .SXY   D14R0107 .SXY   D14R0108 .SXY   D14R0109 .SXY   D14R0110 .SXY   D14R0111 .SXY   D14R0112 .SXY   D14R0113 .SXY   D14R0114 .SXY   D14R0115 .SXY   D14R0116 .SXY   D14R0117 .SXY   D14R0118 .SXY   D14R1414 .SXY   D15R0101 .SXY   D16R0101 .SXY   D16R0102 .SXY   D16R0103 .SXY   D16R0104 .SXY   D23R0101 .SXY   R02R0101 .SXY   R02R0201 .SXY   R02R0301 .SXY   R02R0401 .SXY   R02R0501 .SXY   R04R0101 .SXY   R05R0101 .SXY   R05R0201 .SXY   R05R0301 .SXY   R06R0101 .SXY   R06R0201 .SXY   R07R0101 .SXY   R07R0201 .SXY   R07R0301 .SXY   R08R0101 .SXY   R08R0201 .SXY   R10R0101 .SXY   R10R0201 .SXY   R10R0301 .SXY   R11R0101 .SXY   R11R0102 .SXY   R11R0201 .SXY   R12R0101 .SXY   R12R0102 .SXY   R12R0201 .SXY   R15R0101 .SXY   R15R0102 .SXY   R16R0101 .SXY   R16R0102 .SXY   R16R0201 .SXY   R18R0101 .SXY   R18R0102 .SXY   R20R0101 .SXY   R22R0101 .SXY   R23R0101 .SXY   R23R0201 .SXY   R25R0101 .SXY   ROAD01 .SXY Route 1 (Pallet to Viridian) ROAD02 .SXY Route 2 ROAD03 .SXY Route 3 ROAD04 .SXY Route 4 ROAD05 .SXY Route 5 ROAD06 .SXY Route 6 ROAD07 .SXY Route 7 ROAD08 .SXY Route 8 ROAD09 .SXY Route 9 ROAD10 .SXY Route 10 ROAD11 .SXY Route 11 ROAD12 .SXY Route 12 ROAD13 .SXY Route 13 ROAD14 .SXY Route 14 ROAD15 .SXY Route 15 ROAD16 .SXY Route 16 ROAD17 .SXY Route 17 ROAD18 .SXY Route 18 ROAD19 .SXY Route 19 ROAD20 .SXY Route 20 ROAD21 .SXY Route 21 ROAD22 .SXY Route 22 ROAD23 .SXY Route 23 ROAD24 .SXY Route 24 ROAD25 .SXY Route 25 T00R0101 .SXY   T00R0102 .SXY   T01R0101 .SXY Player’s house F01 T01R0102 .SXY Player’s house F02 T01R0201 .SXY Rival’s house T01R0301 .SXY Professor Oak’s Lab T02R0101 .SXY Viridian City Pokemon Center T02R0201 .SXY   T02R0301 .SXY   T02R0401 .SXY   T02R0501 .SXY   T03R0101 .SXY   T03R0102 .SXY   T03R0201 .SXY   T03R0301 .SXY   T03R0401 .SXY   T03R0501 .SXY   T03R0601 .SXY   T04R0101 .SXY   T04R0102 .SXY   T04R0201 .SXY   T04R0301 .SXY   T04R0401 .SXY   T04R0501 .SXY   T04R0601 .SXY   T04R0701 .SXY Cerulean Cave 1F T04R0801 .SXY   T05R0101 .SXY   T05R0201 .SXY   T05R0202 .SXY   T05R0203 .SXY   T05R0204 .SXY   T05R0205 .SXY   T05R0206 .SXY   T05R0207 .SXY   T05R0208 .SXY Pokemon Tower Elevator (unused) T05R0301 .SXY   T05R0401 .SXY   T05R0501 .SXY   T05R0601 .SXY   T06R0101 .SXY   T06R0201 .SXY   T06R0301 .SXY   T06R0401 .SXY   T06R0501 .SXY   T06R0601 .SXY   T06R0701 .SXY   T06R0801 .SXY   T07R0101 .SXY   T07R0102 .SXY   T07R0103 .SXY   T07R0104 .SXY   T07R0105 .SXY   T07R0106 .SXY   T07R0201 .SXY   T07R0202 .SXY   T07R0203 .SXY   T07R0204 .SXY   T07R0205 .SXY   T07R0301 .SXY   T07R0401 .SXY   T07R0501 .SXY   T07R0601 .SXY   T07R0701 .SXY   T07R0801 .SXY   T07R0901 .SXY   T07R1001 .SXY   T08R0101 .SXY   T08R0201 .SXY   T08R0301 .SXY   T08R0401 .SXY   T08R0501 .SXY   T08R0601 .SXY   T08R0701 .SXY   T08R0801 .SXY   T08R0901 .SXY   T08R1001 .SXY   T08R1101 .SXY   T08R1201 .SXY Unused Cage map T08R1301 .SXY   T09R0101 .SXY   T09R0201 .SXY   T09R0301 .SXY   T09R0302 .SXY   T09R0303 .SXY   T09R0304 .SXY   T09R0401 .SXY   T09R0501 .SXY   T09R0601 .SXY   T0TR0101 .SXY   T0TR0201 .SXY Fighting Dojo T0TR0301 .SXY   T0TR0501 .SXY   T0TR0601 .SXY   T0TR0701 .SXY   T0TR0801 .SXY   T10R0101 .SXY   T11R0101 .SXY   T11R0102 .SXY   T11R0201 .SXY Fighting Dojo T11R0301 .SXY   T11R0401 .SXY   T11R0501 .SXY   T11R0601 .SXY   T11R0701 .SXY   T11R0801 .SXY   TOWN01 .SXY Pallet Town TOWN02 .SXY Viridian City TOWN03 .SXY Pewter City TOWN04 .SXY Cerulean City TOWN05 .SXY Lavender Town TOWN06 .SXY Vermillion City TOWN07 .SXY Celadon City TOWN08 .SXY Fuchsia City TOWN09 .SXY Cinnabar Island TOWN0T .SXY   TOWN10 .SXY Indigo Plateau TOWN11 .SXY Saffron City TOWN11NO .SXY   Source (/blue8M/source) /source This folder contains the z80 assembly code for the game in .DMG files (DMG is the shorthand for Dot Matrix Game, the original name for the GameBoy). This folder also contains the following sub-directories: Temp - Debug - Cotnains the compiled object files for each of the .DMG files</div> </section> The files in this folder are described in the table below: File Name Extension Description ACTOR .DMG   ACTPUT .DMG   ACTSUB .DMG   ANIME .DEF   A_DEMO .DMG   A_MOVE .DMG   BADGE .DMG   BANK .DMG   BANKTOOL .DEF, .DMG   BATTLE .DMG   BMUSIC .DMG   BMUSIC2 .DMG   BMUSIC3 .DMG   CHRSET .DMG   COMMSG .DMG   CONT .DMG   C_EFFECT .DMG   Common .def   D01R0101 .DMG   D02R0101 .DMG   D02R0102 .DMG   D02R0103 .DMG   D03R0101 .DMG   D03R0102 .DMG   D03R0103 .DMG   D03R0104 .DMG   D03R0105 .DMG   D03R0106 .DMG   D03R0107 .DMG   D03R0108 .DMG   D03R0109 .DMG   D03R0110 .DMG   D04R0101 .DMG   D06R0101 .DMG   D07R0101 .DMG   D08R0101 .DMG   D09R0101 .DMG   D09R0102 .DMG   D09R0103 .DMG   D09R0104 .DMG   D09R0105 .DMG   D10R0101 .DMG   D10R0102 .DMG   D10R0103 .DMG   D10R0104 .DMG   D10R0105 .DMG   D10R0106 .DMG   D10R0107 .DMG   D10R0108 .DMG   D10R0109 .DMG   D10R0110 .DMG   D10R0111 .DMG   D11R0101 .DMG   D11R0102 .DMG   D11R0103 .DMG   D12R0101 .DMG   D12R0102 .DMG   D12R0103 .DMG   D12R0104 .DMG   D12R0105 .DMG   D12R0106 .DMG   D12R0107 .DMG   D12R0108 .DMG   D12R0109 .DMG   D13R0101 .DMG   D13R0102 .DMG   D14R0104 .DMG   D14R0109 .DMG   D14R0114 .DMG   D14R0115 .DMG   D14R0116 .DMG   D14R0117 .DMG   D14R0118 .DMG   D15R0101 .DMG   D16R0101 .DMG   D16R0102 .DMG   D16R0103 .DMG   D16R0104 .DMG   DATA_BOX .DMG   DEALER .DEF, .DMG   DEBUG .DMG   DEMO .DMG   DMA .DMG   D_ACTION .DMG   EFFECT .DEF, .DMG   EFFECTER .DAT, .DMG, .H   EFF_TBL .DMG   ENCOUNT .DMG   EV_TOOL .DMG   FADEPLAY .DMG   FEW_MAC .H Include file for declaring FIGHT .DEF, .DMG   FIGHTER .DEF, .DMG   FNTEQU .DEF   GROUP .DEF   HANA .DAT   HANA2 .DAT   HANA3 .DAT   HEADER .DMG   HITCHECK .DMG   ISASM .TAG   ITEM .DMG   ITEMMENU .DMG   LABOBANK .MAP   LCDC .DMG   MACRO .H Include file for declaring MAIN .DMG   MAP .DEF   MAPBANK .DAT   MAPHEAD .DEF   MAPORG .DMG   MAPPER .DMG   MAPSUB .DMG   MAPTYPE .DEF   MONSLIST .DMG   MONSTER .DMG   MUSHEAD .DMG   MUSHEAD2 .DMG   MUSHEAD3 .DMG   MUSIC .TBL   MVOICE .DAT, .H   MYUFILE .DAT   M_ASA .DMG   M_AWALK .DMG   M_CASINO .DMG   M_CHARI .DMG   M_DEAL1 .DMG   M_DEAL2 .DMG   M_DEAL3 .DMG   M_DENDOU .DMG   M_DUNG .DMG   M_DUNG2 .DMG   M_DUNG3 .DMG   M_DUNG4 .DMG   M_ENDING .DMG   M_FAN1 .DMG   M_FAN2 .DMG   M_FAN3 .DMG   M_FAN4 .DMG   M_FAN5 .DMG   M_FAN6 .DMG   M_FAN8 .DMG   M_FIELD1 .DMG   M_FIELD2 .DMG   M_FIELD3 .DMG   M_FIELD4 .DMG   M_FIELD5 .DMG   M_FIGHT1 .DMG   M_FIGHT3 .DMG   M_FIGHT4 .DMG   M_FIGHT5 .DMG   M_GYM .DMG   M_HTOWN .DMG   M_KOKAN1 .DMG   M_KOKAN2 .DMG   M_LABO .DMG   M_OHKIDO .DMG   M_PMC .DMG   M_PURIN .DMG   M_RIVAL .DMG   M_SANTO .DMG   M_SEA .DMG   M_SHINKA .DMG   M_START .DMG   M_TITLE .DMG   M_TOU1 .DMG   M_TOU2 .DMG   M_TOWN1 .DMG   M_TOWN2 .DMG   M_TOWN3 .DMG   M_TOWN4 .DMG   M_TOWN5 .DMG   M_TOWN6 .DMG   M_VIC1 .DMG   M_VIC2 .DMG   M_VIC3 .DMG   OBJSET .DMG   OBSERVE .DMG   PATTERN .DMG   PLAY .DMG   PLAY1 .DMG   PLAY2 .DMG   PM_DEBUG .DEF   PRINT .DMG   PRT .DMG   R02R0101 .DMG   R02R0201 .DMG   R02R0301 .DMG   R02R0401 .DMG   R02R0501 .DMG   R04R0101 .DMG   R05R0101 .DMG   R05R0201 .DMG   R05R0301 .DMG   R06R0101 .DMG   R06R0201 .DMG   R07R0101 .DMG   R07R0201 .DMG   R07R0301 .DMG   R08R0101 .DMG   R08R0201 .DMG   R10R0101 .DMG   R10R0201 .DMG   R10R0301 .DMG   R11R0101 .DMG   R11R0102 .DMG   R11R0201 .DMG   R12R0101 .DMG   R12R0102 .DMG   R12R0201 .DMG   R15R0101 .DMG   R15R0102 .DMG   R16R0101 .DMG   R16R0102 .DMG   R16R0201 .DMG   R18R0101 .DMG   R18R0102 .DMG   R20R0101 .DMG   R22R0101 .DMG   R23R0101 .DMG   R25R0101 .DMG   RESET .DMG   ROAD01 .DMG   ROAD02 .DMG   ROAD03 .DMG   ROAD04 .DMG   ROAD05 .DMG   ROAD06 .DMG   ROAD07 .DMG   ROAD08 .DMG   ROAD09 .DMG   ROAD10 .DMG   ROAD11 .DMG   ROAD12 .DMG   ROAD13 .DMG   ROAD14 .DMG   ROAD15 .DMG   ROAD16 .DMG   ROAD17 .DMG   ROAD18 .DMG   ROAD19 .DMG   ROAD20 .DMG   ROAD21 .DMG   ROAD22 .DMG   ROAD23 .DMG   ROAD24 .DMG   ROAD25 .DMG   SAVELOAD .DMG   SE .DEF   SETDMONS .DMG   SFX .DMG   SGB_COL .DEF, .DMG   SHINKA .DMG   SIO .DMG   SOUND .H Include file for declaring SPATTACK .DMG   T00R0101 .DMG   T00R0102 .DMG   T01R0101 .DMG   T01R0102 .DMG   T01R0201 .DMG   T01R0301 .DMG   T02R0101 .DMG   T02R0201 .DMG   T02R0301 .DMG   T02R0401 .DMG   T02R0501 .DMG   T03R0101 .DMG   T03R0102 .DMG   T03R0201 .DMG   T03R0301 .DMG   T03R0401 .DMG   T03R0501 .DMG   T03R0601 .DMG   T04R0101 .DMG   T04R0201 .DMG   T04R0301 .DMG   T04R0401 .DMG   T04R0501 .DMG   T04R0601 .DMG   T04R0701 .DMG   T04R0801 .DMG   T05R0101 .DMG   T05R0201 .DMG   T05R0202 .DMG   T05R0203 .DMG   T05R0204 .DMG   T05R0205 .DMG   T05R0206 .DMG   T05R0207 .DMG   T05R0301 .DMG   T05R0401 .DMG   T05R0501 .DMG   T05R0601 .DMG   T06R0101 .DMG   T06R0201 .DMG   T06R0301 .DMG   T06R0401 .DMG   T06R0501 .DMG   T06R0601 .DMG   T06R0701 .DMG   T06R0801 .DMG   T07R0101 .DMG   T07R0102 .DMG   T07R0103 .DMG   T07R0104 .DMG   T07R0105 .DMG   T07R0106 .DMG   T07R0201 .DMG   T07R0202 .DMG   T07R0203 .DMG   T07R0204 .DMG   T07R0205 .DMG   T07R0301 .DMG   T07R0401 .DMG   T07R0501 .DMG   T07R0601 .DMG   T07R0701 .DMG   T07R0801 .DMG   T07R0901 .DMG   T07R1001 .DMG   T08R0101 .DMG   T08R0201 .DMG   T08R0301 .DMG   T08R0401 .DMG   T08R0501 .DMG   T08R0601 .DMG   T08R0701 .DMG   T08R0801 .DMG   T09R0101 .DMG   T09R0201 .DMG   T09R0301 .DMG   T09R0302 .DMG   T09R0303 .DMG   T09R0304 .DMG   T09R0401 .DMG   T09R0501 .DMG   T10R0101 .DMG   T11R0101 .DMG   T11R0102 .DMG   T11R0201 .DMG   T11R0301 .DMG   T11R0401 .DMG   T11R0501 .DMG   T11R0601 .DMG   T11R0701 .DMG   T11R0801 .DMG   TABLE .MAC   TALKMAP .DMG   TIMER .DMG   TOWN01 .DMG   TOWN02 .DMG   TOWN03 .DMG   TOWN04 .DMG   TOWN05 .DMG   TOWN06 .DMG   TOWN07 .DMG   TOWN08 .DMG   TOWN09 .DMG   TOWN11 .DMG   TYPE .DEF   Tools .dmg   UNCOMP .DMG   USEITEM .DMG   USEITEM2 .DMG   VANISH .DEF, .DMG   VBLANK .DMG   VOICE .DAT, .H   WATASHI .DMG   WAZA .DMG   WINDOW .DMG   WORLDMAP .DMG   YUKA .DAT   ZUKAN .DMG   i_msg2_0 .dmg   i_msg2_1 .dmg   i_msg2_2 .dmg   i_msg2_3 .dmg   i_msg2_4 .dmg   i_msg2_5 .dmg   i_msg2_6 .dmg   i_msg2_7 .dmg   i_msg2_8 .dmg   i_msg2_9 .dmg   i_msg2_a .dmg   pmcom .dmg   Debug (/blue8M/source/Debug) /Debug This folder contains compiled object code files for each of the .DMG source code files in the parent folder. The files in this folder are described in the table below: File Name Extension Description ACTOR .ISO   ACTPUT .ISO   ACTSUB .ISO   A_DEMO .ISO   A_MOVE .ISO   BADGE .ISO   BANK .ISO   BANKTOOL .ISO   BATTLE .ISO   BLUEMONS .ISX   BMUSIC .ISO   BMUSIC2 .ISO   BMUSIC3 .ISO   CHRSET .ISO   COMMON .ISO   COMMSG .ISO   CONT .ISO   C_EFFECT .ISO   D01R0101 .ISO   D02R0101 .ISO   D02R0102 .ISO   D02R0103 .ISO   D03R0101 .ISO   D03R0102 .ISO   D03R0103 .ISO   D03R0104 .ISO   D03R0105 .ISO   D03R0106 .ISO   D03R0107 .ISO   D03R0108 .ISO   D03R0109 .ISO   D03R0110 .ISO   D04R0101 .ISO   D06R0101 .ISO   D07R0101 .ISO   D08R0101 .ISO   D09R0101 .ISO   D09R0102 .ISO   D09R0103 .ISO   D09R0104 .ISO   D09R0105 .ISO   D10R0101 .ISO   D10R0102 .ISO   D10R0103 .ISO   D10R0104 .ISO   D10R0105 .ISO   D10R0106 .ISO   D10R0107 .ISO   D10R0108 .ISO   D10R0109 .ISO   D10R0110 .ISO   D10R0111 .ISO   D11R0101 .ISO   D11R0102 .ISO   D11R0103 .ISO   D12R0101 .ISO   D12R0102 .ISO   D12R0103 .ISO   D12R0104 .ISO   D12R0105 .ISO   D12R0106 .ISO   D12R0107 .ISO   D12R0108 .ISO   D12R0109 .ISO   D13R0101 .ISO   D13R0102 .ISO   D14R0104 .ISO   D14R0109 .ISO   D14R0114 .ISO   D14R0115 .ISO   D14R0116 .ISO   D14R0117 .ISO   D14R0118 .ISO   D15R0101 .ISO   D16R0101 .ISO   D16R0102 .ISO   D16R0103 .ISO   D16R0104 .ISO   DATA_BOX .ISO   DEALER .ISO   DEBUG .ISO   DEMO .ISO   DMA .ISO   D_ACTION .ISO   EFFECT .ISO   EFFECTER .ISO   EFF_TBL .ISO   ENCOUNT .ISO   EV_TOOL .ISO   FADEPLAY .ISO   FIGHT .ISO   FIGHTER .ISO   HEADER .ISO   HITCHECK .ISO   ITEM .ISO   ITEMMENU .ISO   I_MSG2_0 .ISO   I_MSG2_1 .ISO   I_MSG2_2 .ISO   I_MSG2_3 .ISO   I_MSG2_4 .ISO   I_MSG2_5 .ISO   I_MSG2_6 .ISO   I_MSG2_7 .ISO   I_MSG2_8 .ISO   I_MSG2_9 .ISO   I_MSG2_A .ISO   LCDC .ISO   MAIN .ISO   MAPORG .ISO   MAPPER .ISO   MAPSUB .ISO   MONSLIST .ISO   MONSTER .ISO   MUSHEAD .ISO   MUSHEAD2 .ISO   MUSHEAD3 .ISO   M_ASA .ISO   M_AWALK .ISO   M_CASINO .ISO   M_CHARI .ISO   M_DEAL1 .ISO   M_DEAL2 .ISO   M_DEAL3 .ISO   M_DENDOU .ISO   M_DUNG .ISO   M_DUNG2 .ISO   M_DUNG3 .ISO   M_DUNG4 .ISO   M_ENDING .ISO   M_FAN1 .ISO   M_FAN2 .ISO   M_FAN3 .ISO   M_FAN4 .ISO   M_FAN5 .ISO   M_FAN6 .ISO   M_FAN8 .ISO   M_FIELD1 .ISO   M_FIELD2 .ISO   M_FIELD3 .ISO   M_FIELD4 .ISO   M_FIELD5 .ISO   M_FIGHT1 .ISO   M_FIGHT3 .ISO   M_FIGHT4 .ISO   M_FIGHT5 .ISO   M_GYM .ISO   M_HTOWN .ISO   M_KOKAN1 .ISO   M_KOKAN2 .ISO   M_LABO .ISO   M_OHKIDO .ISO   M_PMC .ISO   M_PURIN .ISO   M_RIVAL .ISO   M_SANTO .ISO   M_SEA .ISO   M_SHINKA .ISO   M_START .ISO   M_TITLE .ISO   M_TOU1 .ISO   M_TOU2 .ISO   M_TOWN1 .ISO   M_TOWN2 .ISO   M_TOWN3 .ISO   M_TOWN4 .ISO   M_TOWN5 .ISO   M_TOWN6 .ISO   M_VIC1 .ISO   M_VIC2 .ISO   M_VIC3 .ISO   OBJSET .ISO   OBSERVE .ISO   PATTERN .ISO   PLAY .ISO   PLAY1 .ISO   PLAY2 .ISO   PMCOM .ISO   PRINT .ISO   PRT .ISO   R02R0101 .ISO   R02R0201 .ISO   R02R0301 .ISO   R02R0401 .ISO   R02R0501 .ISO   R04R0101 .ISO   R05R0101 .ISO   R05R0201 .ISO   R05R0301 .ISO   R06R0101 .ISO   R06R0201 .ISO   R07R0101 .ISO   R07R0201 .ISO   R07R0301 .ISO   R08R0101 .ISO   R08R0201 .ISO   R10R0101 .ISO   R10R0201 .ISO   R10R0301 .ISO   R11R0101 .ISO   R11R0102 .ISO   R11R0201 .ISO   R12R0101 .ISO   R12R0102 .ISO   R12R0201 .ISO   R15R0101 .ISO   R15R0102 .ISO   R16R0101 .ISO   R16R0102 .ISO   R16R0201 .ISO   R18R0101 .ISO   R18R0102 .ISO   R20R0101 .ISO   R22R0101 .ISO   R23R0101 .ISO   R25R0101 .ISO   RESET .ISO   ROAD01 .ISO   ROAD02 .ISO   ROAD03 .ISO   ROAD04 .ISO   ROAD05 .ISO   ROAD06 .ISO   ROAD07 .ISO   ROAD08 .ISO   ROAD09 .ISO   ROAD10 .ISO   ROAD11 .ISO   ROAD12 .ISO   ROAD13 .ISO   ROAD14 .ISO   ROAD15 .ISO   ROAD16 .ISO   ROAD17 .ISO   ROAD18 .ISO   ROAD19 .ISO   ROAD20 .ISO   ROAD21 .ISO   ROAD22 .ISO   ROAD23 .ISO   ROAD24 .ISO   ROAD25 .ISO   SAVELOAD .ISO   SETDMONS .ISO   SFX .ISO   SGB_COL .ISO   SHINKA .ISO   SIO .ISO   SPATTACK .ISO   T00R0101 .ISO   T00R0102 .ISO   T01R0101 .ISO   T01R0102 .ISO   T01R0201 .ISO   T01R0301 .ISO   T02R0101 .ISO   T02R0201 .ISO   T02R0301 .ISO   T02R0401 .ISO   T02R0501 .ISO   T03R0101 .ISO   T03R0102 .ISO   T03R0201 .ISO   T03R0301 .ISO   T03R0401 .ISO   T03R0501 .ISO   T03R0601 .ISO   T04R0101 .ISO   T04R0201 .ISO   T04R0301 .ISO   T04R0401 .ISO   T04R0501 .ISO   T04R0601 .ISO   T04R0701 .ISO   T04R0801 .ISO   T05R0101 .ISO   T05R0201 .ISO   T05R0202 .ISO   T05R0203 .ISO   T05R0204 .ISO   T05R0205 .ISO   T05R0206 .ISO   T05R0207 .ISO   T05R0301 .ISO   T05R0401 .ISO   T05R0501 .ISO   T05R0601 .ISO   T06R0101 .ISO   T06R0201 .ISO   T06R0301 .ISO   T06R0401 .ISO   T06R0501 .ISO   T06R0601 .ISO   T06R0701 .ISO   T06R0801 .ISO   T07R0101 .ISO   T07R0102 .ISO   T07R0103 .ISO   T07R0104 .ISO   T07R0105 .ISO   T07R0106 .ISO   T07R0201 .ISO   T07R0202 .ISO   T07R0203 .ISO   T07R0204 .ISO   T07R0205 .ISO   T07R0301 .ISO   T07R0401 .ISO   T07R0501 .ISO   T07R0601 .ISO   T07R0701 .ISO   T07R0801 .ISO   T07R0901 .ISO   T07R1001 .ISO   T08R0101 .ISO   T08R0201 .ISO   T08R0301 .ISO   T08R0401 .ISO   T08R0501 .ISO   T08R0601 .ISO   T08R0701 .ISO   T08R0801 .ISO   T09R0101 .ISO   T09R0201 .ISO   T09R0301 .ISO   T09R0302 .ISO   T09R0303 .ISO   T09R0304 .ISO   T09R0401 .ISO   T09R0501 .ISO   T10R0101 .ISO   T11R0101 .ISO   T11R0102 .ISO   T11R0201 .ISO   T11R0301 .ISO   T11R0401 .ISO   T11R0501 .ISO   T11R0601 .ISO   T11R0701 .ISO   T11R0801 .ISO   TALKMAP .ISO   TIMER .ISO   TOOLS .ISO   TOWN01 .ISO   TOWN02 .ISO   TOWN03 .ISO   TOWN04 .ISO   TOWN05 .ISO   TOWN06 .ISO   TOWN07 .ISO   TOWN08 .ISO   TOWN09 .ISO   TOWN11 .ISO   UNCOMP .ISO   USEITEM .ISO   USEITEM2 .ISO   VANISH .ISO   VBLANK .ISO   WATASHI .ISO   WAZA .ISO   WINDOW .ISO   WORLDMAP .ISO   ZUKAN .ISO   Temp (/blue8M/source/Temp) /Temp This folder contains… The files in this folder are described in the table below: File Name Extension Description COMMON .ISO, .PRN   common .dmg   検索 (/blue8M/検索) /検索 This folder contains just a single file called 埋め込みメッセージ.txt which seems to list each bank along with some define byte assembly instructions beside source file line numbers. It is unclear the purpose of this file. Yellow (/yellow) /yellow This folder contains the source code to Pokemon Yellow, in this seciton we will only cover the differences between Pokemon Yellow and Blue, so new files added or modified so as not to repeat the content from above. This folder also contains the following sub-directories: test - Source - EFFDATA - Document - final - MAPDATA - yellow - DATA - SOUND - SXY - MONSDATA -</div> </section> The files in this folder are described in the table below: File Name Extension Description Yellmons .bin, .sdb   depends .bat, .mak   err .txt   link .lnk   makefile N/A Used to build the source code in the folder (run make) makerom .bat Windows Batch file for running mapinfo .txt   mssccprj .scc   Data (/yellow/DATA) /DATA This folder contains… The files in this folder are described in the table below: File Name Extension Description ALPHABET .DAT   ANE .CHR   BADGE .DAT   BANKTOOL .DAT   BASAN .CHR   BDMONS .DAT, .SYM   BOSS .CHR   BOSS01 .DAT   BOSS02 .DAT   BOSS03 .DAT   BOSS04 .DAT   BOY .CHR   B_GAUGE .DAT   B_MARUC .DAT   CAST_UP .DAT   CHARA .DAT   CHARI .DAT   CHARIYA .CHR   CHIKIN .CHR   COINBIT .DAT   COOK .CHR   CYCLE .CHR   DANIN .CHR   DANPEI .CHR, .DAT   DEALER00 .DAT   DEALER01 .DAT   DEALER02 .DAT   DEALER03 .DAT   DEALER04 .DAT   DEALER05 .DAT   DEALER06 .DAT   DEALER07 .DAT   DEALER08 .DAT   DEALER09 .DAT   DEALER10 .DAT   DEALER11 .DAT   DEALER12 .DAT   DEALER13 .DAT   DEALER14 .DAT   DEALER15 .DAT   DEALER16 .DAT   DEALER17 .DAT   DEALER18 .DAT   DEALER19 .DAT   DEALER20 .DAT   DEALER21 .DAT   DEALER22 .DAT   DEALER23 .DAT   DEALER24 .DAT   DEALER25 .DAT   DEALER26 .DAT   DEALER27 .DAT   DEALER28 .DAT   DEALER29 .DAT   DEALER30 .DAT   DEALER31 .DAT   DEALER32 .DAT   DEALER33 .DAT   DEALER34 .DAT   DEALER41 .DAT   DEALER42 .DAT   DEALER43 .DAT   DEALER44 .DAT   DEALER45 .DAT   DEALERAI .DAT   DEALERNM .DAT   DEALERTB .DAT   DEMO_TIT .DAT   DEPAGA .CHR   DMONS .DAT, .SYM   DUMMY .CHR   ENCOUNT .DAT   ENCOUNTB .DAT   ENCOUNTR .DAT   ENCOUNTY .DAT   ENTHOU .CHR   FIGHT .DAT   FONT .DAT   FUJI .CHR   FUNANORI .CHR   FUSHIGI .CHR   GAMERM .CHR   GAUGE .DAT   GAUGE_B .DAT   GSAN .CHR   GSAN2 .CHR   HANAHANA .DAT   HERO .DAT   HOTELM .CHR   HOTELMAN .CHR   HOTELW .CHR   ITEMBIT .DAT   ITEMGOLD .DAT   ITEMMENU .DAT   ITEMNAME .DAT   JIBUN .CHR   JIKI .DAT   JIKI_BLU .DAT   JI_BACK .DAT   JUMPDAI .DAT   JUNSAR .CHR   KAKUTOU .CHR   KANNA .CHR   KASYA1 .DAT   KASYA2 .DAT   KASYA3 .DAT   KASYA4 .DAT   KEIBI .CHR   KENKYUIN .CHR   KIKUKO .CHR   KITOUSHI .CHR   KOJIRO .CHR   KOMONO .DAT   LOGOVER .DAT   LOLITA .CHR   LUCKY .CHR   MAPJIKI .DAT   MARUMON .CHR   MARUSHI .DAT   MARUSHI2 .DAT   MARUSHIY .DAT   MARUSI_N .DAT   MONSTER .CHR   MORIMORI .CHR   MUSASHI .CHR   MY_BACK .DAT   NANAMI .CHR   NAZOKUSA .CHR   NEECHYAN .CHR   NIICHYAN .CHR   NUSI_01 .DAT   NUSI_02 .DAT   NUSI_03 .DAT   NUSI_04 .DAT   NUSI_05 .DAT   NUSI_06 .DAT   NUSI_07 .DAT   NUSI_08 .DAT   N_GAUGE .DAT   OBASAN .CHR   OBJ01 .DAT   OBJ02 .DAT   OBJ03 .DAT   OBJ04 .DAT   OBJ05 .DAT   OBJ06 .DAT   OKAASAN .CHR   OKI01 .DAT   OKID_BAK .DAT   OOKIDO .CHR   OP_BG .DAT   OP_OBJ .DAT   OP_PURIN .DAT   OSSAN .CHR   OSSAN2 .CHR   PHILIP .CHR   PICKMAP .DAT, .TBL   PICKTBL .DAT   PIKA10AA .DAT   PIKA10A_ .DAT   PIKA10B_ .DAT   PIKA_01 .DAT   PIKA_01A .DAT   PIKA_02 .DAT, .USO   PIKA_02A .DAT   PIKA_03 .DAT   PIKA_03A .DAT   PIKA_04 .DAT   PIKA_04A .DAT   PIKA_05 .DAT   PIKA_05A .DAT   PIKA_06 .DAT   PIKA_06A .DAT   PIKA_07 .DAT   PIKA_07A .DAT   PIKA_08 .DAT   PIKA_08A .DAT   PIKA_09 .DAT   PIKA_09A .DAT   PIKA_10 .DAT   PIKA_10A .DAT   PIKA_10B .DAT   PIKA_11 .DAT   PIKA_11A .DAT   PIKA_12 .DAT   PIKA_12A .DAT   PIKA_13 .DAT   PIKA_13A .DAT   PIKA_14 .DAT   PIKA_14A .DAT   PIKA_15 .DAT   PIKA_15A .DAT   PIKA_16 .DAT   PIKA_16A .DAT   PIKA_17 .DAT   PIKA_17A .DAT   PIKA_18 .DAT   PIKA_18A .DAT   PIKA_19 .DAT   PIKA_19A .DAT   PIKA_20 .DAT   PIKA_20A .DAT   PIKA_21 .DAT   PIKA_21A .DAT   PIKA_21B .DAT   PIKA_21C .DAT   PIKA_21D .DAT   PIKA_22 .DAT   PIKA_22A .DAT   PIKA_23 .DAT   PIKA_23A .DAT   PIKA_24 .DAT   PIKA_24A .DAT   PIKA_25 .DAT   PIKA_25A .DAT   PIKA_25B .DAT   PIKA_26 .DAT   PIKA_26A .DAT   PIKA_27 .DAT   PIKA_27A .DAT   PIKA_28 .DAT   PIKA_28A .DAT   PIKA_WLK .DAT   PIPPI .CHR   PMTIT .DAT   PSY .DAT   PURIN .CHR   RAPLUS .DAT   RDMONS .DAT, .SYM   RIVAL .CHR, .DAT   ROCKET1 .DAT   ROCKET2 .DAT   ROCKETS .DAT   SAND .CHR   SEINEN .CHR   SENTHOU .CHR   SERIFU .DAT   SERIFU_B .DAT   SHAINM .CHR   SHAINW .CHR   SHATHOU .CHR   SHINKA .DAT   SHIVA .CHR   SHOPMAN .CHR   SHOUNEN .CHR   SLOT1 .DAT   SLOT_BG .DAT   SLOT_OB .DAT   STATUSNE .DAT   STATUSX .DAT   SURFPIKA .DAT   SWIMMER .CHR   SYLPHMAN .CHR   TESTBALL .CHR   THEEND .DAT   TITLCAP2 .DAT   TITLE03 .DAT   TITLE04 .DAT   TITLE_JI .DAT   TITLE_Y .DAT   TORI .CHR   TRADE_AN .DAT   TRAINERM .CHR   TRAINERW .CHR   UMINOIE .CHR   UMIRYU .CHR   VANISH .DAT   WALKPIKA .CHR   WATARU .CHR   WAZAGOLD .DAT   WAZANAME .DAT   WAZA_SE .DAT, .H   WAZA_TBL .DAT   WORLDMAP .DAT   YUUICHI .DAT   ZUKAN .DAT   font_us .dat   Document (/yellow/Document) /Document This folder contains… This folder also contains the following sub-directories: BugReportFromNOA - Script -</div> </section> The files in this folder are described in the table below: File Name Extension Description FAX MESSAGE .doc   pika .bmp   バンク移動計画(1) .txt   バンク移動計画(2) .txt   青の履歴 .txt   Bugreportfromnoa (/yellow/Document/BugReportFromNOA) /BugReportFromNOA This folder contains… The files in this folder are described in the table below: File Name Extension Description BUG1-13 .TXT   Bug1-19 .txt   Bug1-21 .txt   Bug1-25 .txt   Bug1-28 .txt   Bug2-01 .txt   debug .txt   Script (/yellow/Document/Script) /Script This folder contains… The files in this folder are described in the table below: File Name Extension Description PMFILE .dat   YELMSG_9 .txt   mvzukan .bat Windows Batch file for running putmsgj .bat Windows Batch file for running yelmsg .zip   yelmsg_0 .txt   yelmsg_1 .txt   yelmsg_2 .txt   yelmsg_3 .txt   yelmsg_4 .txt   yelmsg_5 .txt   yelmsg_6 .txt   yelmsg_7 .txt   yelmsg_8 .txt   yelmsg_a .txt   Effdata (/yellow/EFFDATA) /EFFDATA This folder contains… The files in this folder are described in the table below: File Name Extension Description BLSLOTBG .DAT   CAPTURE .DAT   COL_BLUE .DAT   COL_RED .DAT   DEMO_TIT .DAT   EF0 .DAT   EF1 .DAT   FLAME1 .DAT   HYDRO1 .DAT   MARUMARU .DAT   MIZU .DAT   MUSI .DAT   PF_Y_CGX .DAT   PF_Y_MAP .DAT   PICT_F .DAT   RYDEEN1 .DAT   SIMPHIT .DAT   SLOTBG_B .DAT   SLOTOB_B .DAT   SLOTOB_R .DAT   STATNAME .DAT   STATNO .DAT   STATUS1 .DAT   STATWAKU .DAT   TETSU .DAT   TURI .DAT   Map Data (/yellow/MAPDATA) /MAPDATA This folder contains all the tile data for each of the maps. The files in this folder are described in the table below: File Name Extension Description 1 .CEL   11_18GAT .MAP   12GATE .MAP   16_GATE .MAP   22GATE .MAP   5_6GATE .MAP   7_8GATE .MAP   ARASARE .CEL, .CHR, .MAP   AZITO_B1 .MAP   AZITO_B2 .MAP   AZITO_B3 .MAP   AZITO_B4 .MAP   AZITO_EL .MAP   AZITO_R1 .MAP   AZITO_R2 .MAP   AZITO_R3 .MAP   BILDING .CEL   BOSSDOJO .MAP   BTOWN_B1 .DAT   BUILDING .CEL, .DAT   BULDING .CEL   CHAMPCUP .CEL, .CHR, .MAP   CICLE .CEL, .DAT, .MAP   COLOSEUM .MAP   CYCLE .CEL, .DAT, .MAP   DAIMANIA .CEL, .DAT   DAISUKI .MAP   DENDOU .MAP   DENDOU2 .MAP   DEPELV .MAP   DEPT .CEL, .DAT   DEPT1F .MAP   DEPT2F .MAP   DEPT3F .MAP   DEPT4F .MAP   DEPT5F .MAP   DEPT6F .MAP   DGN01 .CEL, .DAT, .MAP   DGN02 .CEL, .DAT, .MAP   DGN04 .MAP   DGN05 .MAP   DGN06 .MAP   DOJO .MAP   DOJO_01 .MAP   DOJO_02 .MAP   DOJO_03 .MAP   DOJO_04 .MAP   DOJO_05 .MAP   DOJO_06 .MAP   DOJO_07 .MAP   DOJO_08 .MAP   DONATA .MAP   DUN02 .CEL   END01 .MAP   END02 .MAP   END03 .MAP   FIRE_DUN .MAP   GATE .CEL, .DAT   GATE2F .MAP   GATEHAKU .CEL, .DAT   GYM .CEL, .DAT   GYM_01 .MAP   GYM_02 .MAP   GYM_03 .MAP   GYM_04 .MAP   GYM_05 .MAP   GYM_06 .MAP   GYM_07 .MAP   GYM_08 .MAP   GYM_Y .CEL   HAKUBU1F .MAP   HAKUBU2F .MAP   HAKUBUTU .DAT   HONBU1 .MAP   HONBU2 .MAP   HONBU3 .MAP   HOTEL .CEL, .CHR, .DAT, .MAP   HOTEL_Y .MAP   HYOUSIKI .DAT   IWAMIN .MAP   IWANUKE_ .MAP   IWA_1F .MAP   IWA_2F .MAP   JIMKYOK .MAP   JIMSHO .MAP   JISAN .MAP   KAICHO_5 .MAP   KENKYU .CEL, .DAT, .MAP   KENKYU_1 .MAP   KENKYU_2 .MAP   KENKYU_3 .MAP   KENKYU_4 .MAP   KENKYU_S .MAP   KOKANJO .MAP   LASTBOSS .MAP   MANIA .DAT, .MAP   MANSH01 .MAP   MANSH02 .MAP   MANSH03 .MAP   MANSH04 .MAP   MANSHO .CEL, .DAT   MANSHO1 .CEL   MAP_TBL .DAT   MDUN_1 .MAP   MDUN_2 .MAP   MDUN_3 .MAP   MDUN_4 .CEL, .MAP   MDUN_5 .MAP   MDUN_6 .MAP   MINKA_A .CEL, .DAT, .MAP   MINKA_B .CEL, .MAP   MINKA_C .MAP   MINKA_D .MAP   MISEYADO .CEL, .DAT   NEND01 .MAP   NEND02 .MAP   NEND03 .MAP   NEW_IWA1 .MAP   NEW_IWA2 .MAP   NHOTEL .MAP   NHOTEL_Y .MAP   NIWA .MAP   NROAD_01 .DAT, .MAP   NROAD_02 .DAT, .MAP   NROAD_03 .DAT, .MAP   NROAD_04 .DAT, .MAP   NROAD_05 .DAT, .MAP   NROAD_06 .DAT, .MAP   NROAD_07 .DAT, .MAP   NROAD_08 .DAT, .MAP   NROAD_09 .DAT, .MAP   NROAD_10 .DAT, .MAP   NROAD_11 .DAT, .MAP   NROAD_12 .DAT, .MAP   NROAD_13 .DAT, .MAP   NROAD_14 .DAT, .MAP   NROAD_15 .DAT, .MAP   NROAD_16 .DAT, .MAP   NROAD_17 .DAT, .MAP   NROAD_18 .DAT, .MAP   NROAD_19 .DAT, .MAP   NROAD_20 .DAT, .MAP   NROAD_21 .DAT, .MAP   NROAD_22 .DAT, .MAP   NROAD_23 .DAT, .MAP Route 23 NROAD_24 .DAT, .MAP   NROAD_25 .DAT, .MAP   NSILF_1 .MAP   NSILF_2 .MAP   NSILF_3 .MAP   NSILF_4 .MAP   NSILF_5 .MAP   NTOWER .CEL, .DAT   NTOWN_01 .CEL, .DAT, .MAP   NTOWN_02 .MAP   NTOWN_03 .MAP   NTOWN_04 .DAT, .MAP   NTOWN_05 .DAT, .MAP   NTOWN_06 .DAT, .MAP   NTOWN_07 .DAT, .MAP   NTOWN_08 .DAT, .MAP   NTOWN_09 .DAT, .MAP   NTOWN_10 .DAT, .MAP   NTOWN_11 .DAT   NTOWN_12 .DAT   NTOWN_T .DAT, .MAP   NT_1F .MAP   NT_2F .MAP   NT_3F .MAP   NT_4F .MAP   NT_5F .MAP   NT_6F .MAP   NT_7F .MAP   NT_EL .MAP   NUKE .CEL, .DAT   NUKE5_6 .MAP   NUKEMIN .MAP   OHKIDO .MAP   OHKIDO_Y .CEL   ORI .MAP   OTUKI_B1 .MAP   OTUKI_B2 .MAP   OTUKI_B3 .MAP   PACHNCO .CEL, .MAP   POKECEN .CEL, .DAT, .MAP   POKECHR .CEL   POKESEN .CEL, .DAT   POKE_1F .CEL, .MAP   POKE_2F .CEL, .MAP   POKE_3F .MAP   POKE_B1 .CEL, .MAP   PORT .CEL, .DAT, .MAP   PREAGUE .MAP   R1_CHR .DAT   R1_ENC .DAT   ROAD1 .DAT   ROAD10 .DAT   ROAD11 .DAT   ROAD12 .DAT   ROAD13 .DAT   ROAD14 .DAT   ROAD15 .DAT   ROAD16 .DAT   ROAD17 .DAT   ROAD18 .DAT   ROAD19 .DAT   ROAD1T .DAT   ROAD2 .DAT   ROAD20 .DAT   ROAD21 .DAT   ROAD22 .DAT   ROAD23 .DAT   ROAD24 .DAT   ROAD25 .DAT   ROAD3 .DAT   ROAD4 .DAT   ROAD5 .DAT   ROAD6 .DAT   ROAD7 .DAT   ROAD8 .DAT   ROAD9 .DAT   ROOM .CEL, .DAT   ROOM1F .CEL, .DAT, .MAP   ROOM2F .CEL, .DAT, .MAP   ROOMCELL .DAT   ROOMIMG .DAT   SAFACELL .CEL   SAFARI_1 .MAP   SAFARI_2 .MAP   SAFARI_3 .MAP   SAFARI_4 .MAP   SCFOOL .CEL   SCHOOL .CEL, .DAT, .MAP   SCLCELL .DAT   SCLIMG .DAT   SEKISHO .CEL, .DAT, .MAP   SHIP .CEL, .DAT   SHOKUDO .MAP   SHOP .CHR, .MAP   SHOP1 .DAT   SHOPCELL .DAT   SHOPIMG .DAT   SHOP_Y .CEL, .CHR, .MAP   SHROOM1 .MAP   SHROOM2 .MAP   SHROOM3 .MAP   SHROOM4 .MAP   SILE_B4 .MAP   SILF_11F .MAP   SILF_1F .MAP   SILF_2F .MAP   SILF_3F .MAP   SILF_4F .MAP   SILF_5F .MAP   SILF_B1 .MAP   SILF_B2 .MAP   SILF_B3 .MAP   SILF_B3A .MAP   SILF_B3B .MAP   SILF_B4 .MAP   SILF_B5 .MAP   SILF_B6 .MAP   SILF_B7 .MAP   SILF_B8 .MAP   SKOYA_1 .MAP   SKOYA_2 .MAP   STANNU .CEL, .DAT   STANNU01 .MAP   STANNU02 .MAP   STANNU03 .MAP   STANNU04 .MAP   STANNU05 .MAP   T6S2 .DAT   TORI_1F .MAP   TORI_B1 .MAP   TORI_B2 .MAP   TOWER .CEL, .DAT   TOWER1F .MAP   TOWER2F .MAP   TOWER3F .MAP   TOWER4F .MAP   TOWER5F .MAP   TOWER6F .MAP   TOWER7F .MAP   TOWN1 .DAT   TOWN10 .DAT   TOWN11 .DAT   TOWN12 .DAT   TOWN2 .DAT   TOWN3 .DAT   TOWN4 .DAT   TOWN5 .DAT   TOWN6 .DAT   TOWN7 .DAT   TOWN8 .DAT   TOWN9 .DAT   TOWNCELL .DAT   TOWNIMG2 .DAT   TOWN_B1 .CEL, .DAT   TRADE .MAP   TRAINING .CEL, .MAP   TURI .MAP   UMIHOUSE .CEL, .DAT, .MAP   UMIIE .MAP   YDUN_1 .MAP   YEND_01 .MAP   YEND_02 .MAP   YEND_03 .MAP   YGYM_04 .MAP   YPACHNCO .MAP   YROAD_04 .MAP   YROAD_19 .MAP   YTOWN_B1 .DAT   Monsdata (/yellow/MONSDATA) /MONSDATA This folder contains… The files in this folder are described in the table below: File Name Extension Description 029NIDO .GIF   DEALER26 .DAT   DEALER42 .DAT   HERO .DAT   KABUBONE .DAT   KAIHATSU .DAT   MONSB100 .DAT   MONSB101 .DAT   MONSB102 .DAT   MONSB103 .DAT   MONSB104 .DAT   MONSB105 .DAT   MONSB106 .DAT   MONSB107 .DAT   MONSB108 .DAT   MONSB109 .DAT   MONSB110 .DAT   MONSB111 .DAT   MONSB112 .DAT   MONSB113 .DAT   MONSB114 .DAT   MONSB116 .DAT   MONSB117 .DAT   MONSB118 .DAT   MONSB119 .DAT   MONSB120 .DAT   MONSB122 .DAT   MONSB123 .DAT   MONSB124 .DAT   MONSB125 .DAT   MONSB126 .DAT   MONSB127 .DAT   MONSB128 .DAT   MONSB129 .DAT   MONSB130 .DAT   MONSB131 .DAT   MONSB132 .DAT   MONSB133 .DAT   MONSB134 .DAT   MONSB136 .DAT   MONSB137 .DAT   MONSB138 .DAT   MONSB139 .DAT   MONSB140 .DAT   MONSB141 .DAT   MONSB142 .DAT   MONSB143 .DAT   MONSB144 .DAT   MONSB145 .DAT   MONSB146 .DAT   MONSB147 .DAT   MONSB148 .DAT   MONSB149 .DAT   MONSB150 .DAT   MONSB151 .DAT   MONSB152 .DAT   MONSB153 .DAT   MONSB154 .DAT   MONSB155 .DAT   MONSB156 .DAT   MONSB157 .DAT   MONSB158 .DAT   MONSB159 .DAT   MONSB160 .DAT   MONSB161 .DAT   MONSB162 .DAT   MONSB163 .DAT   MONSB164 .DAT   MONSB165 .DAT   MONSB166 .DAT   MONSB167 .DAT   MONSB168 .DAT   MONSB169 .DAT   MONSB170 .DAT   MONSB171 .DAT   MONSB172 .DAT   MONSB173 .DAT   MONSB174 .DAT   MONSB175 .DAT   MONSB176 .DAT   MONSB177 .DAT   MONSB178 .DAT   MONSB179 .DAT   MONSB180 .DAT   MONSB181 .DAT   MONSB185 .DAT   MONSB186 .DAT   MONSB187 .DAT   MONSB188 .DAT   MONSB189 .DAT   MONSB190 .DAT   MONSBK01 .DAT   MONSBK02 .DAT   MONSBK03 .DAT   MONSBK04 .DAT   MONSBK05 .DAT   MONSBK06 .DAT   MONSBK07 .DAT   MONSBK08 .DAT   MONSBK09 .DAT   MONSBK10 .DAT   MONSBK11 .DAT   MONSBK12 .DAT   MONSBK13 .DAT   MONSBK14 .DAT   MONSBK15 .DAT   MONSBK16 .DAT   MONSBK17 .DAT   MONSBK18 .DAT   MONSBK19 .DAT   MONSBK20 .DAT   MONSBK21 .DAT   MONSBK22 .DAT   MONSBK23 .DAT   MONSBK24 .DAT   MONSBK25 .DAT   MONSBK26 .DAT   MONSBK27 .DAT   MONSBK28 .DAT   MONSBK29 .DAT   MONSBK30 .DAT   MONSBK31 .DAT   MONSBK32 .DAT   MONSBK33 .DAT   MONSBK34 .DAT   MONSBK35 .DAT   MONSBK36 .DAT   MONSBK37 .DAT   MONSBK38 .DAT   MONSBK39 .DAT   MONSBK40 .DAT   MONSBK41 .DAT   MONSBK42 .DAT   MONSBK43 .DAT   MONSBK44 .DAT   MONSBK45 .DAT   MONSBK46 .DAT   MONSBK47 .DAT   MONSBK48 .DAT   MONSBK49 .DAT   MONSBK50 .DAT   MONSBK51 .DAT   MONSBK52 .DAT   MONSBK53 .DAT   MONSBK54 .DAT   MONSBK55 .DAT   MONSBK56 .DAT   MONSBK57 .DAT   MONSBK58 .DAT   MONSBK59 .DAT   MONSBK60 .DAT   MONSBK61 .DAT   MONSBK62 .DAT   MONSBK63 .DAT   MONSBK64 .DAT   MONSBK65 .DAT   MONSBK66 .DAT   MONSBK67 .DAT   MONSBK68 .DAT   MONSBK69 .DAT   MONSBK70 .DAT   MONSBK71 .DAT   MONSBK72 .DAT   MONSBK73 .DAT   MONSBK74 .DAT   MONSBK75 .DAT   MONSBK76 .DAT   MONSBK77 .DAT   MONSBK78 .DAT   MONSBK79 .DAT   MONSBK80 .DAT   MONSBK81 .DAT   MONSBK82 .DAT   MONSBK83 .DAT   MONSBK84 .DAT   MONSBK85 .DAT   MONSBK86 .DAT   MONSBK87 .DAT   MONSBK88 .DAT   MONSBK89 .DAT   MONSBK90 .DAT   MONSBK91 .DAT   MONSBK92 .DAT   MONSBK93 .DAT   MONSBK94 .DAT   MONSBK95 .DAT   MONSBK96 .DAT   MONSBK97 .DAT   MONSBK98 .DAT   MONSBK99 .DAT   MONSC182 .DAT   MONSC183 .DAT   MONSC184 .DAT   MONSDATA .DAT, .OV   MONSNAM2 .DAT   MONSNAME .DAT   MONSTBL .DAT   ORDER .DAT   PMDUMMY .DAT   PMFILE .DAT, .OV   PMYF_001 .DAT   PMYF_002 .DAT   PMYF_003 .DAT   PMYF_004 .DAT   PMYF_005 .DAT   PMYF_006 .DAT   PMYF_007 .DAT   PMYF_008 .DAT   PMYF_009 .DAT   PMYF_010 .DAT   PMYF_011 .DAT   PMYF_012 .DAT   PMYF_013 .DAT   PMYF_014 .DAT   PMYF_015 .DAT   PMYF_016 .DAT   PMYF_017 .DAT   PMYF_018 .DAT   PMYF_019 .DAT   PMYF_020 .DAT   PMYF_021 .DAT   PMYF_022 .DAT   PMYF_023 .DAT   PMYF_024 .DAT   PMYF_025 .DAT   PMYF_026 .DAT   PMYF_027 .DAT   PMYF_028 .DAT   PMYF_029 .DAT   PMYF_030 .DAT   PMYF_031 .DAT   PMYF_032 .DAT   PMYF_033 .DAT   PMYF_034 .DAT   PMYF_035 .DAT   PMYF_036 .DAT   PMYF_037 .DAT   PMYF_038 .DAT   PMYF_039 .DAT   PMYF_040 .DAT   PMYF_041 .DAT   PMYF_042 .DAT   PMYF_043 .DAT   PMYF_044 .DAT   PMYF_045 .DAT   PMYF_046 .DAT   PMYF_047 .DAT   PMYF_048 .DAT   PMYF_049 .DAT   PMYF_050 .DAT   PMYF_051 .DAT   PMYF_052 .DAT   PMYF_053 .DAT   PMYF_054 .DAT   PMYF_055 .DAT   PMYF_056 .DAT   PMYF_057 .DAT   PMYF_058 .DAT   PMYF_059 .DAT   PMYF_060 .DAT   PMYF_061 .DAT   PMYF_062 .DAT   PMYF_063 .DAT   PMYF_064 .DAT   PMYF_065 .DAT   PMYF_066 .DAT   PMYF_067 .DAT   PMYF_068 .DAT   PMYF_069 .DAT   PMYF_070 .DAT   PMYF_071 .DAT   PMYF_072 .DAT   PMYF_073 .DAT   PMYF_074 .DAT   PMYF_075 .DAT   PMYF_076 .DAT   PMYF_077 .DAT   PMYF_078 .DAT   PMYF_079 .DAT   PMYF_080 .DAT   PMYF_081 .DAT   PMYF_082 .DAT   PMYF_083 .DAT   PMYF_084 .DAT   PMYF_085 .DAT   PMYF_086 .DAT   PMYF_087 .DAT   PMYF_088 .DAT   PMYF_089 .DAT   PMYF_090 .DAT   PMYF_091 .DAT   PMYF_092 .DAT   PMYF_093 .DAT   PMYF_094 .DAT   PMYF_095 .DAT   PMYF_096 .DAT   PMYF_097 .DAT   PMYF_098 .DAT   PMYF_099 .DAT   PMYF_100 .DAT   PMYF_101 .DAT   PMYF_102 .DAT   PMYF_103 .DAT   PMYF_104 .DAT   PMYF_105 .DAT   PMYF_106 .DAT   PMYF_107 .DAT   PMYF_108 .DAT   PMYF_109 .DAT   PMYF_110 .DAT   PMYF_111 .DAT   PMYF_112 .DAT   PMYF_113 .DAT   PMYF_114 .DAT   PMYF_115 .DAT   PMYF_116 .DAT   PMYF_117 .DAT   PMYF_118 .DAT   PMYF_119 .DAT   PMYF_120 .DAT   PMYF_121 .DAT   PMYF_122 .DAT   PMYF_123 .DAT   PMYF_124 .DAT   PMYF_125 .DAT   PMYF_126 .DAT   PMYF_127 .DAT   PMYF_128 .DAT   PMYF_129 .DAT   PMYF_130 .DAT   PMYF_131 .DAT   PMYF_132 .DAT   PMYF_133 .DAT   PMYF_134 .DAT   PMYF_135 .DAT   PMYF_136 .DAT   PMYF_137 .DAT   PMYF_138 .DAT   PMYF_139 .DAT   PMYF_140 .DAT   PMYF_141 .DAT   PMYF_142 .DAT   PMYF_143 .DAT   PMYF_144 .DAT   PMYF_145 .DAT   PMYF_146 .DAT   PMYF_147 .DAT   PMYF_148 .DAT   PMYF_149 .DAT   PMYF_150 .DAT   PMYF_151 .DAT   PMYF_DMY .DAT   PUTEBONE .DAT   RIVAL .DAT   TEST .DAT   Sound (/yellow/SOUND) /SOUND This folder contains… The files in this folder are described in the table below: File Name Extension Description AABO .DAT   AABOKKU .DAT   BATAFURI .DAT   BETOBETA .DAT   BETOBETO .DAT   BIIDORU .DAT   BIRIRIDA .DAT   DAGUTORI .DAT   DANE30 .DAT   DATA .DAT   DIGUDA .DAT   DOGAASU .DAT   DOKUKURA .DAT   DOODORIO .DAT   EBIWARAA .DAT   FILENAME .DAT   FUSHIGI .DAT   FUSIGIDA .DAT   GENGAA .DAT   GOOSU .DAT   GOOSUTO .DAT   GOROON .DAT   GORUBATT .DAT   HITODEMA .DAT   HITOKAGE .DAT   ISITUBUT .DAT   IWAAKU .DAT   KARAKARA .DAT   KEESII .DAT   KODAKKU .DAT   KOIKINGU .DAT   KOIRU .DAT   KOKUUN .DAT   KONPAN .DAT   KORATTA .DAT   KURABU .DAT   KUSAIHAN .DAT   KYATAPII .DAT   MADATUBO .DAT   MANKII .DAT   MATADOGA .DAT   MENOKURA .DAT   MONJYARA .DAT   MORUHON .DAT   NAZONOKU .DAT   NYAASU .DAT   OKORIZAR .DAT   ONISUZUM .DAT   PARASU .DAT   PAUWAU .DAT   PERUSIAN .DAT   PIJYON .DAT   PIKA01 .DAT   PIKA02 .DAT   PIKA03 .DAT   PIKA04 .DAT   PIKA05 .DAT   PIKA06 .DAT   PIKA07 .DAT   PIKA08 .DAT   PIKA09 .DAT   PIKA10 .DAT   PIKA11 .DAT   PIKA12 .DAT   PIKA13 .DAT   PIKA14 .DAT   PIKA15 .DAT   PIKA16 .DAT   PIKA17 .DAT   PIKA18 .DAT   PIKA19 .DAT   PIKA20 .DAT   PIKA21 .DAT   PIKA22 .DAT   PIKA23 .DAT   PIKA24 .DAT   PIKA25 .DAT   PIKA26 .DAT   PIKA27 .DAT   PIKA30 .DAT   PIKA33 .DAT   PIKA36 .DAT   PIKA38 .DAT   PIKA41 .DAT   PIKACHUU .DAT   PIKACU10 .DAT   PIKACU11 .DAT   PIKACU12 .DAT   PIKACU13 .DAT   PIKACU14 .DAT   PIKACU15 .DAT   PIKACU16 .DAT   PIKACUU .DAT   PIKACUU2 .DAT   PIKACUU3 .DAT   PIKACUU4 .DAT   PIKACUU5 .DAT   PIKACUU6 .DAT   PIKACUU7 .DAT   PIKACUU8 .DAT   PIKACUU9 .DAT   PIKUSII .DAT   PIPPI .DAT   POKEMON .DAT   POPPO .DAT   RAICHUU .DAT   RAKKII .DAT   RATTA .DAT   REAKOIRU .DAT   ROKON .DAT   SANDO .DAT   SAWAMURA .DAT   SUPIAA .DAT   SURIIPAA .DAT   SURIIPU .DAT   SUTAAMII .DAT   TATTUU .DAT   TEST .DAT   TORANSER .DAT   TOSAKINT .DAT   UTUDON .DAT   WANRIKII .DAT   YADON .DAT   YADORAN .DAT   YUN16 .DAT   YUN21 .DAT   YUN25 .DAT   YUN30 .DAT   YUN35 .DAT   YUN40 .DAT   YUNGERAA .DAT   ZENIGAME .DAT   ZUBATTO .DAT   Sxy (/yellow/SXY) /SXY This folder contains… The files in this folder are described in the table below: File Name Extension Description D01R0101 .SXY   D02R0101 .SXY   D02R0102 .SXY   D02R0103 .SXY   D03R0101 .SXY   D03R0102 .SXY   D03R0103 .SXY   D03R0104 .SXY   D03R0105 .SXY   D03R0106 .SXY   D03R0107 .SXY   D03R0108 .SXY   D03R0109 .SXY   D03R0110 .SXY   D03R0111 .SXY   D03R0112 .SXY   D03R0113 .SXY   D03R0114 .SXY   D03R0115 .SXY   D03R0116 .SXY   D03R0117 .SXY   D03R0118 .SXY   D03R0119 .SXY   D03R0120 .SXY   D03R0121 .SXY   D03R0122 .SXY   D03R0123 .SXY   D03R0124 .SXY   D04R0101 .SXY   D05R0101 .SXY   D06R0101 .SXY   D07R0101 .SXY   D08R0101 .SXY   D08R0102 .SXY   D09R0101 .SXY   D09R0102 .SXY   D09R0103 .SXY   D09R0104 .SXY   D09R0105 .SXY   D10R0101 .SXY   D10R0102 .SXY   D10R0103 .SXY   D10R0104 .SXY   D10R0105 .SXY   D10R0106 .SXY   D10R0107 .SXY   D10R0108 .SXY   D10R0109 .SXY   D10R0110 .SXY   D10R0111 .SXY   D10R0112 .SXY   D10R0201 .SXY   D10R0202 .SXY   D10R0203 .SXY   D10R0204 .SXY   D11R0101 .SXY   D11R0102 .SXY   D11R0103 .SXY   D12R0101 .SXY   D12R0102 .SXY   D12R0103 .SXY   D12R0104 .SXY   D12R0105 .SXY   D12R0106 .SXY   D12R0107 .SXY   D12R0108 .SXY   D12R0109 .SXY   D13R0101 .SXY   D13R0102 .SXY   D14R0101 .SXY   D14R0102 .SXY   D14R0103 .SXY   D14R0104 .SXY   D14R0105 .SXY   D14R0106 .SXY   D14R0107 .SXY   D14R0108 .SXY   D14R0109 .SXY   D14R0110 .SXY   D14R0111 .SXY   D14R0112 .SXY   D14R0113 .SXY   D14R0114 .SXY   D14R0115 .SXY   D14R0116 .SXY   D14R0117 .SXY   D14R0118 .SXY   D14R1414 .SXY   D15R0101 .SXY   D16R0101 .SXY   D16R0102 .SXY   D16R0103 .SXY   D16R0104 .SXY   D23R0101 .SXY   R02R0101 .SXY   R02R0201 .SXY   R02R0301 .SXY   R02R0401 .SXY   R02R0501 .SXY   R04R0101 .SXY   R05R0101 .SXY   R05R0201 .SXY   R05R0301 .SXY   R06R0101 .SXY   R06R0201 .SXY   R07R0101 .SXY   R07R0201 .SXY   R07R0301 .SXY   R08R0101 .SXY   R08R0201 .SXY   R10R0101 .SXY   R10R0201 .SXY   R10R0301 .SXY   R11R0101 .SXY   R11R0102 .SXY   R11R0201 .SXY   R12R0101 .SXY   R12R0102 .SXY   R12R0201 .SXY   R15R0101 .SXY   R15R0102 .SXY   R16R0101 .SXY   R16R0102 .SXY   R16R0201 .SXY   R18R0101 .SXY   R18R0102 .SXY   R19R0101 .SXY   R20R0101 .SXY   R22R0101 .SXY   R23R0101 .SXY   R23R0201 .SXY   R25R0101 .SXY   ROAD01 .SXY   ROAD02 .SXY   ROAD03 .SXY   ROAD04 .SXY   ROAD05 .SXY   ROAD06 .SXY   ROAD07 .SXY   ROAD08 .SXY   ROAD09 .SXY   ROAD10 .SXY   ROAD11 .SXY   ROAD12 .SXY   ROAD13 .SXY   ROAD14 .SXY   ROAD15 .SXY   ROAD16 .SXY   ROAD17 .SXY   ROAD18 .SXY   ROAD19 .SXY   ROAD20 .SXY   ROAD21 .SXY   ROAD22 .SXY   ROAD23 .SXY   ROAD24 .SXY   ROAD25 .SXY   T00R0101 .SXY   T00R0102 .SXY   T01R0101 .SXY   T01R0102 .DBG, .SXY   T01R0201 .SXY   T01R0301 .SXY   T02R0101 .SXY   T02R0201 .SXY   T02R0301 .SXY   T02R0401 .SXY   T02R0501 .SXY   T03R0101 .SXY   T03R0102 .SXY   T03R0201 .SXY   T03R0301 .SXY   T03R0401 .SXY   T03R0501 .SXY   T03R0601 .SXY   T04R0101 .SXY   T04R0102 .SXY   T04R0201 .SXY   T04R0301 .SXY   T04R0401 .SXY   T04R0501 .SXY   T04R0601 .SXY   T04R0701 .SXY   T04R0801 .SXY   T05R0101 .SXY   T05R0201 .SXY   T05R0202 .SXY   T05R0203 .SXY   T05R0204 .SXY   T05R0205 .SXY   T05R0206 .SXY   T05R0207 .SXY   T05R0208 .SXY   T05R0301 .SXY   T05R0401 .SXY   T05R0501 .SXY   T05R0601 .SXY   T06R0101 .SXY   T06R0201 .SXY   T06R0301 .SXY   T06R0401 .SXY   T06R0501 .SXY   T06R0601 .SXY   T06R0701 .SXY   T06R0801 .SXY   T07R0101 .SXY   T07R0102 .SXY   T07R0103 .SXY   T07R0104 .SXY   T07R0105 .SXY   T07R0106 .SXY   T07R0201 .SXY   T07R0202 .SXY   T07R0203 .SXY   T07R0204 .SXY   T07R0205 .SXY   T07R0301 .SXY   T07R0401 .SXY   T07R0501 .SXY   T07R0601 .SXY   T07R0701 .SXY   T07R0801 .SXY   T07R0901 .SXY   T07R1001 .SXY   T08R0101 .SXY   T08R0201 .SXY   T08R0301 .SXY   T08R0401 .SXY   T08R0501 .SXY   T08R0601 .SXY   T08R0701 .SXY   T08R0801 .SXY   T08R0901 .SXY   T08R1001 .SXY   T08R1101 .SXY   T08R1201 .SXY Unused Cage map T08R1301 .SXY   T09R0101 .SXY   T09R0201 .SXY   T09R0301 .SXY   T09R0302 .SXY   T09R0303 .SXY   T09R0304 .SXY   T09R0401 .SXY   T09R0501 .SXY   T09R0601 .SXY   T0TR0101 .SXY   T0TR0201 .SXY   T0TR0301 .SXY   T0TR0501 .SXY   T0TR0601 .SXY   T0TR0701 .SXY   T0TR0801 .SXY   T10R0101 .SXY   T11R0101 .SXY   T11R0102 .SXY   T11R0201 .SXY   T11R0301 .SXY   T11R0401 .SXY   T11R0501 .SXY   T11R0601 .SXY   T11R0701 .SXY   T11R0801 .SXY   TOWN01 .SXY   TOWN02 .SXY   TOWN03 .SXY   TOWN04 .SXY   TOWN05 .SXY   TOWN06 .SXY   TOWN07 .SXY   TOWN08 .SXY   TOWN09 .SXY   TOWN0T .SXY   TOWN10 .SXY   TOWN11 .SXY   Source (/yellow/Source) /Source This folder contains… This folder also contains the following sub-directories: Temp - Iso - bin - Isx -</div> </section> The files in this folder are described in the table below: File Name Extension Description ACTOR .DMG   ACTPUT .DMG   ACTSUB .DMG   ANIME .DEF   A_DEMO .dmg   A_MOVE .DMG   BADGE .DMG   BANK .DMG, .MAP   BANKTOOL .DEF, .DMG   BATTLE .dmg   BITPLAY .DMG   BMUSIC .DMG   BMUSIC2 .DMG   BMUSIC3 .DMG   BMUSIC4 .DMG   CHRSET .DMG   COMMON .DEF   COMMSG .dmg   CONT .DMG   C_EFFECT .dmg   D01R0101 .dmg   D02R0101 .dmg   D02R0102 .dmg   D02R0103 .dmg   D03R0101 .dmg   D03R0102 .dmg   D03R0103 .dmg   D03R0104 .DMG   D03R0105 .dmg   D03R0106 .dmg   D03R0107 .dmg   D03R0108 .dmg   D03R0109 .dmg   D03R0110 .dmg   D04R0101 .DMG   D06R0101 .DMG   D07R0101 .DMG   D08R0101 .dmg   D09R0101 .dmg   D09R0102 .dmg   D09R0103 .dmg   D09R0104 .dmg   D09R0105 .dmg   D10R0101 .dmg   D10R0102 .dmg   D10R0103 .dmg   D10R0104 .dmg   D10R0105 .dmg   D10R0106 .dmg   D10R0107 .dmg   D10R0108 .dmg   D10R0109 .dmg   D10R0110 .dmg   D10R0111 .DMG   D11R0101 .dmg   D11R0102 .dmg   D11R0103 .dmg   D12R0101 .dmg   D12R0102 .dmg   D12R0103 .dmg   D12R0104 .dmg   D12R0105 .dmg   D12R0106 .dmg   D12R0107 .dmg   D12R0108 .dmg   D12R0109 .dmg   D13R0101 .DMG   D13R0102 .dmg   D14R0104 .dmg   D14R0109 .dmg   D14R0114 .dmg   D14R0115 .dmg   D14R0116 .dmg   D14R0117 .dmg   D14R0118 .dmg   D15R0101 .dmg   D16R0101 .DMG   D16R0102 .DMG   D16R0103 .DMG   D16R0104 .dmg   DATA_BOX .DMG   DEALER .DEF, .DMG   DEBUG .dmg   DEMO .dmg   DMA .DMG   DMGFUNC .TB0   D_ACTION .dmg   EFFECT .DEF, .dmg   EFFECTER .DAT, .DMG, .H   EFF_TBL .DMG   ENCOUNT .DMG   ENDING .dmg   EV_TOOL .dmg   EX_ACTOR .DMG, .H   FADEPLAY .DMG   FEW_MAC .H Include file for declaring FIGHT .DEF, .dmg   FIGHTER .DEF, .dmg   FNTEQU .DEF   GROUP .DEF   HANA .DAT   HANA2 .DAT   HANA3 .DAT   HEADER .DMG   HITCHECK .DMG   ISASM .TAG   ITEM .DMG   ITEMMENU .DMG   LASTER .H Include file for declaring LCDC .DMG   LINKFILE .Y   MACRO .H Include file for declaring MAIN .dmg   MAP .DEF   MAPBANK .DAT   MAPHEAD .DEF   MAPORG .DMG   MAPPER .DMG   MAPSUB .dmg   MAPTYPE .DEF   MONSLIST .dmg   MONSTER .DMG   MUSHEAD .DMG   MUSHEAD2 .DMG   MUSHEAD3 .DMG   MUSHEAD4 .DMG   MUSIC .TBL   MVOICE .DAT, .H   MYUFILE .DAT   M_ASA .DMG   M_AWALK .DMG   M_CASINO .DMG   M_CHARI .DMG   M_DEAL1 .DMG   M_DEAL2 .DMG   M_DEAL3 .DMG   M_DENDOU .DMG   M_DUNG .DMG   M_DUNG2 .DMG   M_DUNG3 .DMG   M_DUNG4 .DMG   M_ENDING .DMG   M_FAN1 .DMG   M_FAN2 .DMG   M_FAN3 .DMG   M_FAN4 .DMG   M_FAN5 .DMG   M_FAN6 .DMG   M_FAN8 .DMG   M_FIELD1 .DMG   M_FIELD2 .DMG   M_FIELD3 .DMG   M_FIELD4 .DMG   M_FIELD5 .DMG   M_FIGHT1 .DMG   M_FIGHT3 .DMG   M_FIGHT4 .DMG   M_FIGHT5 .DMG   M_GYM .DMG   M_HTOWN .DMG   M_KOKAN1 .DMG   M_KOKAN2 .DMG   M_LABO .DMG   M_NAMI .DMG   M_OHKIDO .DMG   M_PIKA .DMG   M_PMC .DMG   M_PURIN .DMG   M_RIVAL .DMG   M_ROCKET .DMG, .ORG   M_SAKAKI .DMG, .ORG   M_SANTO .DMG   M_SEA .DMG   M_SHINKA .DMG   M_START .DMG   M_TITLE .DMG   M_TOU1 .DMG   M_TOU2 .DMG   M_TOWN1 .DMG   M_TOWN2 .DMG   M_TOWN3 .DMG   M_TOWN4 .DMG   M_TOWN5 .DMG   M_TOWN6 .DMG   M_VIC1 .DMG   M_VIC2 .DMG   M_VIC3 .DMG   NAMINORI .DMG   NEWMAP .DMG   NEWOBJ .DMG   OBJBANK .DEF   OBSERVE .dmg   OPENING .DMG   PATTERN .DMG   PIKA .DEF   PIKAACT .DMG   PIKAANM .H Include file for declaring PIKAFACE .DMG   PIKATALK .dmg   PLAY .DMG   PLAY1 .dmg   PLAY2 .dmg   PM_DEBUG .DEF   PRINT .dmg   PRINTER .DMG, .H   PRINTER2 .dmg   PRT .DMG   PRT_SIO .DMG   P_VOICE .DMG   R02R0101 .dmg   R02R0201 .dmg   R02R0301 .dmg   R02R0401 .dmg   R02R0501 .dmg   R04R0101 .dmg   R05R0101 .dmg   R05R0201 .DMG   R05R0301 .dmg   R06R0101 .DMG   R06R0201 .dmg   R07R0101 .DMG   R07R0201 .dmg   R07R0301 .dmg   R08R0101 .DMG   R08R0201 .dmg   R10R0101 .dmg   R10R0201 .dmg   R10R0301 .dmg   R11R0101 .dmg   R11R0102 .dmg   R11R0201 .dmg   R12R0101 .dmg   R12R0102 .dmg   R12R0201 .dmg   R15R0101 .dmg   R15R0102 .dmg   R16R0101 .dmg   R16R0102 .dmg   R16R0201 .dmg   R18R0101 .dmg   R18R0102 .dmg   R19R0101 .dmg   R20R0101 .DMG   R22R0101 .dmg   R23R0101 .dmg   R25R0101 .dmg   RESET .DMG   ROAD01 .dmg   ROAD02 .dmg   ROAD03 .dmg   ROAD04 .dmg   ROAD05 .dmg   ROAD06 .dmg   ROAD07 .dmg   ROAD08 .dmg   ROAD09 .dmg   ROAD10 .dmg   ROAD11 .dmg   ROAD12 .dmg   ROAD13 .dmg   ROAD14 .dmg   ROAD15 .dmg   ROAD16 .dmg   ROAD17 .dmg   ROAD18 .dmg   ROAD19 .dmg   ROAD20 .dmg   ROAD21 .dmg   ROAD22 .dmg   ROAD23 .dmg   ROAD24 .dmg   ROAD25 .dmg   SAVELOAD .dmg   SE .DEF   SETDMONS .DMG   SET_PPL .DMG   SFX .DMG   SGB_COL .DEF, .DMG   SHINKA .dmg   SIO .DMG   SOUND .H Include file for declaring SPATTACK .dmg   T00R0101 .dmg   T00R0102 .dmg   T01R0101 .dmg   T01R0102 .DMG   T01R0201 .dmg   T01R0301 .dmg   T02R0101 .dmg   T02R0201 .dmg   T02R0301 .dmg   T02R0401 .dmg   T02R0501 .dmg   T03R0101 .dmg   T03R0102 .dmg   T03R0201 .dmg   T03R0301 .dmg   T03R0401 .dmg   T03R0501 .dmg   T03R0601 .dmg   T04R0101 .dmg   T04R0201 .dmg   T04R0301 .dmg   T04R0401 .dmg   T04R0501 .dmg   T04R0601 .dmg   T04R0701 .DMG   T04R0801 .dmg   T05R0101 .dmg   T05R0201 .dmg   T05R0202 .dmg   T05R0203 .dmg   T05R0204 .dmg   T05R0205 .dmg   T05R0206 .dmg   T05R0207 .dmg   T05R0301 .dmg   T05R0401 .dmg   T05R0501 .dmg   T05R0601 .dmg   T06R0101 .dmg   T06R0201 .dmg   T06R0301 .dmg   T06R0401 .dmg   T06R0501 .dmg   T06R0601 .dmg   T06R0701 .dmg   T06R0801 .dmg   T07R0101 .dmg   T07R0102 .dmg   T07R0103 .dmg   T07R0104 .dmg   T07R0105 .dmg   T07R0106 .DMG   T07R0201 .dmg   T07R0202 .dmg   T07R0203 .dmg   T07R0204 .dmg   T07R0205 .dmg   T07R0301 .dmg   T07R0401 .dmg   T07R0501 .dmg   T07R0601 .dmg   T07R0701 .dmg   T07R0801 .dmg   T07R0901 .dmg   T07R1001 .dmg   T08R0101 .dmg   T08R0201 .dmg   T08R0301 .dmg   T08R0401 .dmg   T08R0501 .dmg   T08R0601 .dmg   T08R0701 .dmg   T08R0801 .dmg   T09R0101 .dmg   T09R0201 .dmg   T09R0301 .dmg   T09R0302 .dmg   T09R0303 .dmg   T09R0304 .dmg   T09R0401 .dmg   T09R0501 .dmg   T10R0101 .dmg   T11R0101 .dmg   T11R0102 .dmg   T11R0201 .dmg   T11R0301 .dmg   T11R0401 .dmg   T11R0501 .dmg   T11R0601 .dmg   T11R0701 .dmg   T11R0801 .dmg   TALKMAP .dmg   TAMA N/A   TIMER .DMG   TOOLS .dmg   TOWN01 .dmg   TOWN02 .dmg   TOWN03 .dmg   TOWN04 .dmg   TOWN05 .dmg   TOWN06 .dmg   TOWN07 .dmg   TOWN08 .dmg   TOWN09 .dmg   TOWN11 .dmg   TURIDATA .DMG   TYPE .DEF   UNCOMP .DMG   USEITEM .dmg   USEITEM2 .DMG   VANISH .DEF, .DMG   VBLANK .DMG   VOICE .DAT, .H   VYOSI1 .DAT   WATASHI .DMG   WAZA .DMG   WINDOW .DMG   WORLDMAP .dmg   YUKA .DAT   Y_PATCH .DMG   ZUKAN .DMG   yelmsg_0 .dmg   yelmsg_1 .dmg   yelmsg_2 .dmg   yelmsg_3 .dmg   yelmsg_4 .dmg   yelmsg_5 .dmg   yelmsg_6 .dmg   yelmsg_7 .dmg   yelmsg_8 .dmg   yelmsg_9 .dmg   yelmsg_a .dmg   zukanmsg .dmg   Iso (/yellow/Source/Iso) /Iso This folder contains… The files in this folder are described in the table below: File Name Extension Description ACTOR .ISO   ACTPUT .ISO   ACTSUB .ISO   A_DEMO .ISO   A_MOVE .ISO   BADGE .ISO   BANK .ISO   BANKTOOL .ISO   BATTLE .ISO   BMUSIC .ISO   BMUSIC2 .ISO   BMUSIC3 .ISO   BMUSIC4 .ISO   CHRSET .ISO   COMMON .ISO   COMMSG .ISO   CONT .ISO   C_EFFECT .ISO   D01R0101 .ISO   D02R0101 .ISO   D02R0102 .ISO   D02R0103 .ISO   D03R0101 .ISO   D03R0102 .ISO   D03R0103 .ISO   D03R0104 .ISO   D03R0105 .ISO   D03R0106 .ISO   D03R0107 .ISO   D03R0108 .ISO   D03R0109 .ISO   D03R0110 .ISO   D04R0101 .ISO   D06R0101 .ISO   D07R0101 .ISO   D08R0101 .ISO   D09R0101 .ISO   D09R0102 .ISO   D09R0103 .ISO   D09R0104 .ISO   D09R0105 .ISO   D10R0101 .ISO   D10R0102 .ISO   D10R0103 .ISO   D10R0104 .ISO   D10R0105 .ISO   D10R0106 .ISO   D10R0107 .ISO   D10R0108 .ISO   D10R0109 .ISO   D10R0110 .ISO   D10R0111 .ISO   D11R0101 .ISO   D11R0102 .ISO   D11R0103 .ISO   D12R0101 .ISO   D12R0102 .ISO   D12R0103 .ISO   D12R0104 .ISO   D12R0105 .ISO   D12R0106 .ISO   D12R0107 .ISO   D12R0108 .ISO   D12R0109 .ISO   D13R0101 .ISO   D13R0102 .ISO   D14R0104 .ISO   D14R0109 .ISO   D14R0114 .ISO   D14R0115 .ISO   D14R0116 .ISO   D14R0117 .ISO   D14R0118 .ISO   D15R0101 .ISO   D16R0101 .ISO   D16R0102 .ISO   D16R0103 .ISO   D16R0104 .ISO   DATA_BOX .ISO   DEALER .ISO   DEBUG .ISO   DEMO .ISO   DMA .ISO   D_ACTION .ISO   EFFECT .ISO   EFFECTER .ISO   EFF_TBL .ISO   ENCOUNT .ISO   ENDING .ISO   EV_TOOL .ISO   EX_ACTOR .ISO   FADEPLAY .ISO   FIGHT .ISO   FIGHTER .ISO   HEADER .ISO   HITCHECK .ISO   ITEM .ISO   ITEMMENU .ISO   LCDC .ISO   MAIN .ISO   MAPORG .ISO   MAPSUB .ISO   MONSLIST .ISO   MONSTER .ISO   MUSHEAD .ISO   MUSHEAD2 .ISO   MUSHEAD3 .ISO   MUSHEAD4 .ISO   M_ASA .ISO   M_AWALK .ISO   M_CASINO .ISO   M_CHARI .ISO   M_DEAL1 .ISO   M_DEAL2 .ISO   M_DEAL3 .ISO   M_DENDOU .ISO   M_DUNG .ISO   M_DUNG2 .ISO   M_DUNG3 .ISO   M_DUNG4 .ISO   M_ENDING .ISO   M_FAN1 .ISO   M_FAN2 .ISO   M_FAN3 .ISO   M_FAN4 .ISO   M_FAN5 .ISO   M_FAN6 .ISO   M_FAN8 .ISO   M_FIELD1 .ISO   M_FIELD2 .ISO   M_FIELD3 .ISO   M_FIELD4 .ISO   M_FIELD5 .ISO   M_FIGHT1 .ISO   M_FIGHT3 .ISO   M_FIGHT4 .ISO   M_FIGHT5 .ISO   M_GYM .ISO   M_HTOWN .ISO   M_KOKAN1 .ISO   M_KOKAN2 .ISO   M_LABO .ISO   M_NAMI .ISO   M_OHKIDO .ISO   M_PIKA .ISO   M_PMC .ISO   M_PURIN .ISO   M_RIVAL .ISO   M_ROCKET .ISO   M_SAKAKI .ISO   M_SANTO .ISO   M_SEA .ISO   M_SHINKA .ISO   M_START .ISO   M_TITLE .ISO   M_TOU1 .ISO   M_TOU2 .ISO   M_TOWN1 .ISO   M_TOWN2 .ISO   M_TOWN3 .ISO   M_TOWN4 .ISO   M_TOWN5 .ISO   M_TOWN6 .ISO   M_VIC1 .ISO   M_VIC2 .ISO   M_VIC3 .ISO   NAMINORI .ISO   NEWMAP .ISO   NEWOBJ .ISO   OBSERVE .ISO   OPENING .ISO   PATTERN .ISO   PIKAACT .ISO   PIKAFACE .ISO   PIKATALK .ISO   PLAY .ISO   PLAY1 .ISO   PLAY2 .ISO   PRINT .ISO   PRINTER .ISO   PRINTER2 .ISO   PRT .ISO   PRT_SIO .ISO   P_VOICE .ISO   R02R0101 .ISO   R02R0201 .ISO   R02R0301 .ISO   R02R0401 .ISO   R02R0501 .ISO   R04R0101 .ISO   R05R0101 .ISO   R05R0201 .ISO   R05R0301 .ISO   R06R0101 .ISO   R06R0201 .ISO   R07R0101 .ISO   R07R0201 .ISO   R07R0301 .ISO   R08R0101 .ISO   R08R0201 .ISO   R10R0101 .ISO   R10R0201 .ISO   R10R0301 .ISO   R11R0101 .ISO   R11R0102 .ISO   R11R0201 .ISO   R12R0101 .ISO   R12R0102 .ISO   R12R0201 .ISO   R15R0101 .ISO   R15R0102 .ISO   R16R0101 .ISO   R16R0102 .ISO   R16R0201 .ISO   R18R0101 .ISO   R18R0102 .ISO   R19R0101 .ISO   R20R0101 .ISO   R22R0101 .ISO   R23R0101 .ISO   R25R0101 .ISO   RESET .ISO   ROAD01 .ISO   ROAD02 .ISO   ROAD03 .ISO   ROAD04 .ISO   ROAD05 .ISO   ROAD06 .ISO   ROAD07 .ISO   ROAD08 .ISO   ROAD09 .ISO   ROAD10 .ISO   ROAD11 .ISO   ROAD12 .ISO   ROAD13 .ISO   ROAD14 .ISO   ROAD15 .ISO   ROAD16 .ISO   ROAD17 .ISO   ROAD18 .ISO   ROAD19 .ISO   ROAD20 .ISO   ROAD21 .ISO   ROAD22 .ISO   ROAD23 .ISO   ROAD24 .ISO   ROAD25 .ISO   SAVELOAD .ISO   SETDMONS .ISO   SET_PPL .ISO   SFX .ISO   SGB_COL .ISO   SHINKA .ISO   SIO .ISO   SPATTACK .ISO   T00R0101 .ISO   T00R0102 .ISO   T01R0101 .ISO   T01R0102 .ISO   T01R0201 .ISO   T01R0301 .ISO   T02R0101 .ISO   T02R0201 .ISO   T02R0301 .ISO   T02R0401 .ISO   T02R0501 .ISO   T03R0101 .ISO   T03R0102 .ISO   T03R0201 .ISO   T03R0301 .ISO   T03R0401 .ISO   T03R0501 .ISO   T03R0601 .ISO   T04R0101 .ISO   T04R0201 .ISO   T04R0301 .ISO   T04R0401 .ISO   T04R0501 .ISO   T04R0601 .ISO   T04R0701 .ISO   T04R0801 .ISO   T05R0101 .ISO   T05R0201 .ISO   T05R0202 .ISO   T05R0203 .ISO   T05R0204 .ISO   T05R0205 .ISO   T05R0206 .ISO   T05R0207 .ISO   T05R0301 .ISO   T05R0401 .ISO   T05R0501 .ISO   T05R0601 .ISO   T06R0101 .ISO   T06R0201 .ISO   T06R0301 .ISO   T06R0401 .ISO   T06R0501 .ISO   T06R0601 .ISO   T06R0701 .ISO   T06R0801 .ISO   T07R0101 .ISO   T07R0102 .ISO   T07R0103 .ISO   T07R0104 .ISO   T07R0105 .ISO   T07R0106 .ISO   T07R0201 .ISO   T07R0202 .ISO   T07R0203 .ISO   T07R0204 .ISO   T07R0205 .ISO   T07R0301 .ISO   T07R0401 .ISO   T07R0501 .ISO   T07R0601 .ISO   T07R0701 .ISO   T07R0801 .ISO   T07R0901 .ISO   T07R1001 .ISO   T08R0101 .ISO   T08R0201 .ISO   T08R0301 .ISO   T08R0401 .ISO   T08R0501 .ISO   T08R0601 .ISO   T08R0701 .ISO   T08R0801 .ISO   T09R0101 .ISO   T09R0201 .ISO   T09R0301 .ISO   T09R0302 .ISO   T09R0303 .ISO   T09R0304 .ISO   T09R0401 .ISO   T09R0501 .ISO   T10R0101 .ISO   T11R0101 .ISO   T11R0102 .ISO   T11R0201 .ISO   T11R0301 .ISO   T11R0401 .ISO   T11R0501 .ISO   T11R0601 .ISO   T11R0701 .ISO   T11R0801 .ISO   TALKMAP .ISO   TIMER .ISO   TOOLS .ISO   TOWN01 .ISO   TOWN02 .ISO   TOWN03 .ISO   TOWN04 .ISO   TOWN05 .ISO   TOWN06 .ISO   TOWN07 .ISO   TOWN08 .ISO   TOWN09 .ISO   TOWN11 .ISO   TURIDATA .ISO   UNCOMP .ISO   USEITEM .ISO   USEITEM2 .ISO   VANISH .ISO   VBLANK .ISO   WATASHI .ISO   WAZA .ISO   WINDOW .ISO   WORLDMAP .ISO   YELLMONS .ISX   YELMSG_0 .ISO   YELMSG_1 .ISO   YELMSG_2 .ISO   YELMSG_3 .ISO   YELMSG_4 .ISO   YELMSG_5 .ISO   YELMSG_6 .ISO   YELMSG_7 .ISO   YELMSG_8 .ISO   YELMSG_9 .ISO   YELMSG_A .ISO   Y_PATCH .ISO   ZUKAN .ISO   ZUKANMSG .ISO   Isx (/yellow/Source/Isx) /Isx This folder contains… This folder also contains the following sub-directories: saveData -</div> </section> The files in this folder are described in the table below: File Name Extension Description DMGFUNC .TB0   ISX2BIN .EXE   USRED .BIN   YELLMONS .ISX, .rtc   isdwdcmd .dat   isdwdrng .dat   isdwdsym .dat   y990218 .bin   y990222 .bin   yellmons .ram   コピー ～ yellmons .ram   Route10 (/yellow/Source/Isx/saveData/Route10) /Route10 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route11 (/yellow/Source/Isx/saveData/Route11) /Route11 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route12 (/yellow/Source/Isx/saveData/Route12) /Route12 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route13 (/yellow/Source/Isx/saveData/Route13) /Route13 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route14 (/yellow/Source/Isx/saveData/Route14) /Route14 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route15 (/yellow/Source/Isx/saveData/Route15) /Route15 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route16 (/yellow/Source/Isx/saveData/Route16) /Route16 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route17 (/yellow/Source/Isx/saveData/Route17) /Route17 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route18 (/yellow/Source/Isx/saveData/Route18) /Route18 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route19 (/yellow/Source/Isx/saveData/Route19) /Route19 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route20 (/yellow/Source/Isx/saveData/Route20) /Route20 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route21 (/yellow/Source/Isx/saveData/Route21) /Route21 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route22 (/yellow/Source/Isx/saveData/Route22) /Route22 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route23 (/yellow/Source/Isx/saveData/Route23) /Route23 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route24 (/yellow/Source/Isx/saveData/Route24) /Route24 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _1 (/yellow/Source/Isx/saveData/Route25/_1) /_1 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ﾐｻｷﾉｺﾔ (/yellow/Source/Isx/saveData/Route25/ﾐｻｷﾉｺﾔ) /ﾐｻｷﾉｺﾔ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route3 (/yellow/Source/Isx/saveData/Route3) /Route3 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route4 (/yellow/Source/Isx/saveData/Route4) /Route4 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route5 (/yellow/Source/Isx/saveData/Route5) /Route5 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route6 (/yellow/Source/Isx/saveData/Route6) /Route6 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route8 (/yellow/Source/Isx/saveData/Route8) /Route8 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Route9 (/yellow/Source/Isx/saveData/Route9) /Route9 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｲﾜﾔﾏﾄﾝﾈﾙ (/yellow/Source/Isx/saveData/ｲﾜﾔﾏﾄﾝﾈﾙ) /ｲﾜﾔﾏﾄﾝﾈﾙ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _1 (/yellow/Source/Isx/saveData/ｵﾂｷﾐﾔﾏ/_1) /_1 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _2 (/yellow/Source/Isx/saveData/ｵﾂｷﾐﾔﾏ/_2) /_2 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _1 (/yellow/Source/Isx/saveData/ｸﾁﾊﾞｼﾃｨ/_1) /_1 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ####### 1f (/yellow/Source/Isx/saveData/ｸﾁﾊﾞｼﾃｨ/ｻﾝﾄｱﾝﾇ/1F) /1F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ####### 2f (/yellow/Source/Isx/saveData/ｸﾁﾊﾞｼﾃｨ/ｻﾝﾄｱﾝﾇ/2F) /2F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ####### B1f (/yellow/Source/Isx/saveData/ｸﾁﾊﾞｼﾃｨ/ｻﾝﾄｱﾝﾇ/B1F) /B1F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｼﾞﾑ (/yellow/Source/Isx/saveData/ｸﾁﾊﾞｼﾃｨ/ｼﾞﾑ) /ｼﾞﾑ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _1 (/yellow/Source/Isx/saveData/ｸﾞﾚﾝﾀｳﾝ/_1) /_1 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｼﾞﾑ (/yellow/Source/Isx/saveData/ｸﾞﾚﾝﾀｳﾝ/ｼﾞﾑ) /ｼﾞﾑ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   1f (/yellow/Source/Isx/saveData/ｸﾞﾚﾝﾀｳﾝ/ﾎﾟｹﾓﾝﾔｼｷ/1f) /1f This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   2f (/yellow/Source/Isx/saveData/ｸﾞﾚﾝﾀｳﾝ/ﾎﾟｹﾓﾝﾔｼｷ/2f) /2f This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   3f (/yellow/Source/Isx/saveData/ｸﾞﾚﾝﾀｳﾝ/ﾎﾟｹﾓﾝﾔｼｷ/3f) /3f This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   B1f (/yellow/Source/Isx/saveData/ｸﾞﾚﾝﾀｳﾝ/ﾎﾟｹﾓﾝﾔｼｷ/B1F) /B1F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _1 (/yellow/Source/Isx/saveData/ｼｵﾝﾀｳﾝ/_1) /_1 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   1f (/yellow/Source/Isx/saveData/ｼｵﾝﾀｳﾝ/ﾎﾟｹﾓﾝﾀﾜｰ/1F) /1F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   2f (/yellow/Source/Isx/saveData/ｼｵﾝﾀｳﾝ/ﾎﾟｹﾓﾝﾀﾜｰ/2F) /2F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   3f (/yellow/Source/Isx/saveData/ｼｵﾝﾀｳﾝ/ﾎﾟｹﾓﾝﾀﾜｰ/3F) /3F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   4f (/yellow/Source/Isx/saveData/ｼｵﾝﾀｳﾝ/ﾎﾟｹﾓﾝﾀﾜｰ/4F) /4F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   5f (/yellow/Source/Isx/saveData/ｼｵﾝﾀｳﾝ/ﾎﾟｹﾓﾝﾀﾜｰ/5F) /5F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   6f (/yellow/Source/Isx/saveData/ｼｵﾝﾀｳﾝ/ﾎﾟｹﾓﾝﾀﾜｰ/6F) /6F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   7f (/yellow/Source/Isx/saveData/ｼｵﾝﾀｳﾝ/ﾎﾟｹﾓﾝﾀﾜｰ/7F) /7F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _1 (/yellow/Source/Isx/saveData/ｾｷｴｲｺｳｹﾞﾝ/_1) /_1 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｶﾝﾅ (/yellow/Source/Isx/saveData/ｾｷｴｲｺｳｹﾞﾝ/ｶﾝﾅ) /ｶﾝﾅ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｷｸｺ (/yellow/Source/Isx/saveData/ｾｷｴｲｺｳｹﾞﾝ/ｷｸｺ) /ｷｸｺ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｼﾊﾞ (/yellow/Source/Isx/saveData/ｾｷｴｲｺｳｹﾞﾝ/ｼﾊﾞ) /ｼﾊﾞ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ﾗｲﾊﾞﾙ (/yellow/Source/Isx/saveData/ｾｷｴｲｺｳｹﾞﾝ/ﾗｲﾊﾞﾙ) /ﾗｲﾊﾞﾙ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ﾜﾀﾙ (/yellow/Source/Isx/saveData/ｾｷｴｲｺｳｹﾞﾝ/ﾜﾀﾙ) /ﾜﾀﾙ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _1 (/yellow/Source/Isx/saveData/ｾｷﾁｸｼﾃｨ/_1) /_1 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｻﾌｧﾘ (/yellow/Source/Isx/saveData/ｾｷﾁｸｼﾃｨ/ｻﾌｧﾘ) /ｻﾌｧﾘ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｼﾞﾑ (/yellow/Source/Isx/saveData/ｾｷﾁｸｼﾃｨ/ｼﾞﾑ) /ｼﾞﾑ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _1 (/yellow/Source/Isx/saveData/ﾀﾏﾑｼｼﾃｨ/_1) /_1 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   B1f (/yellow/Source/Isx/saveData/ﾀﾏﾑｼｼﾃｨ/ｱｼﾞﾄ/B1F) /B1F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   B2f (/yellow/Source/Isx/saveData/ﾀﾏﾑｼｼﾃｨ/ｱｼﾞﾄ/B2F) /B2F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   B3f (/yellow/Source/Isx/saveData/ﾀﾏﾑｼｼﾃｨ/ｱｼﾞﾄ/B3F) /B3F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   B4f (/yellow/Source/Isx/saveData/ﾀﾏﾑｼｼﾃｨ/ｱｼﾞﾄ/B4F) /B4F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｻｶｷ (/yellow/Source/Isx/saveData/ﾀﾏﾑｼｼﾃｨ/ｱｼﾞﾄ/ｻｶｷ) /ｻｶｷ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｼﾞﾑ (/yellow/Source/Isx/saveData/ﾀﾏﾑｼｼﾃｨ/ｼﾞﾑ) /ｼﾞﾑ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   1f (/yellow/Source/Isx/saveData/ﾁｬﾝﾋﾟｮﾝﾛｰﾄﾞ/1F) /1F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   2f (/yellow/Source/Isx/saveData/ﾁｬﾝﾋﾟｮﾝﾛｰﾄﾞ/2F) /2F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   3f (/yellow/Source/Isx/saveData/ﾁｬﾝﾋﾟｮﾝﾛｰﾄﾞ/3f) /3f This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _1 (/yellow/Source/Isx/saveData/ﾄｷﾜｼﾃｨ/_1) /_1 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _2 (/yellow/Source/Isx/saveData/ﾄｷﾜｼﾃｨ/_2) /_2 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｼﾞﾑ (/yellow/Source/Isx/saveData/ﾄｷﾜｼﾃｨ/ｼﾞﾑ) /ｼﾞﾑ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ﾄｷﾜﾉﾓﾘ (/yellow/Source/Isx/saveData/ﾄｷﾜﾉﾓﾘ) /ﾄｷﾜﾉﾓﾘ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _1 (/yellow/Source/Isx/saveData/ﾆﾋﾞｼﾃｨ/_1) /_1 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｼﾞﾑ (/yellow/Source/Isx/saveData/ﾆﾋﾞｼﾃｨ/ｼﾞﾑ) /ｼﾞﾑ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _1 (/yellow/Source/Isx/saveData/ﾊﾅﾀﾞｼﾃｨ/_1) /_1 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _2 (/yellow/Source/Isx/saveData/ﾊﾅﾀﾞｼﾃｨ/_2) /_2 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｼﾞﾑ (/yellow/Source/Isx/saveData/ﾊﾅﾀﾞｼﾃｨ/ｼﾞﾑ) /ｼﾞﾑ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ﾌﾀｺﾞｼﾞﾏ (/yellow/Source/Isx/saveData/ﾌﾀｺﾞｼﾞﾏ) /ﾌﾀｺﾞｼﾞﾏ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _1 (/yellow/Source/Isx/saveData/ﾏｻﾗﾀｳﾝ/_1) /_1 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _2 (/yellow/Source/Isx/saveData/ﾏｻﾗﾀｳﾝ/_2) /_2 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   _3 (/yellow/Source/Isx/saveData/ﾏｻﾗﾀｳﾝ/_3) /_3 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ####### _4 (/yellow/Source/Isx/saveData/ﾏｻﾗﾀｳﾝ/_4) /_4 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ####### _5 (/yellow/Source/Isx/saveData/ﾏｻﾗﾀｳﾝ/_5) /_5 This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .BAK, .gbp   ####### ｶｸﾄｳ (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｶｸﾄｳ) /ｶｸﾄｳ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ######## 10f (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｼﾙﾌｶﾝﾊﾟﾆ/10f) /10f This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ######## 11f (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｼﾙﾌｶﾝﾊﾟﾆ/11f) /11f This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ######## 1f (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｼﾙﾌｶﾝﾊﾟﾆ/1F) /1F This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ######## 2f (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｼﾙﾌｶﾝﾊﾟﾆ/2f) /2f This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ######## 3f (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｼﾙﾌｶﾝﾊﾟﾆ/3f) /3f This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ######## 4f (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｼﾙﾌｶﾝﾊﾟﾆ/4f) /4f This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ######## 5f (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｼﾙﾌｶﾝﾊﾟﾆ/5f) /5f This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ######## 6f (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｼﾙﾌｶﾝﾊﾟﾆ/6f) /6f This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ######## 7f (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｼﾙﾌｶﾝﾊﾟﾆ/7f) /7f This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ######## 8f (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｼﾙﾌｶﾝﾊﾟﾆ/8f) /8f This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   9f (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｼﾙﾌｶﾝﾊﾟﾆ/9f) /9f This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｻｶｷ (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｼﾙﾌｶﾝﾊﾟﾆ/ｻｶｷ) /ｻｶｷ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ﾗｲﾊﾞﾙ (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｼﾙﾌｶﾝﾊﾟﾆ/ﾗｲﾊﾞﾙ) /ﾗｲﾊﾞﾙ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   ｼﾞﾑ (/yellow/Source/Isx/saveData/ﾔﾏﾌﾞｷｼﾃｨ/ｼﾞﾑ) /ｼﾞﾑ This folder contains… The files in this folder are described in the table below: File Name Extension Description YELLMONS .ram   Yellmons .gbp   Temp (/yellow/Source/Temp) /Temp This folder contains… The files in this folder are described in the table below: File Name Extension Description COMMON .ISO, .PRN   common .dmg   Bin (/yellow/Source/bin) /bin This folder contains… The files in this folder are described in the table below: File Name Extension Description y990203 .bin   y990203a .bin   y990210 .bin   y990215 .bin   y990216 .bin   y990217 .bin   Final (/yellow/final) /final This folder contains… The files in this folder are described in the table below: File Name Extension Description CTYPE .TXT   apse00-0 .gb   Test (/yellow/test) /test This folder contains… The files in this folder are described in the table below: File Name Extension Description mvmsg .bat Windows Batch file for running Data (/yellow/yellow/DATA) /DATA This folder contains… The files in this folder are described in the table below: File Name Extension Description ALPHABET .DAT   ANE .CHR   BADGE .DAT   BANKTOOL .DAT   BASAN .CHR   BDMONS .DAT, .SYM   BOSS .CHR   BOSS01 .DAT   BOSS02 .DAT   BOSS03 .DAT   BOSS04 .DAT   BOY .CHR   B_GAUGE .DAT   B_MARUC .DAT   CAST_UP .DAT   CHARA .DAT   CHARI .DAT   CHARIYA .CHR   CHIKIN .CHR   COINBIT .DAT   COOK .CHR   CYCLE .CHR   DANIN .CHR   DANPEI .CHR, .DAT   DEALER00 .DAT   DEALER01 .DAT   DEALER02 .DAT   DEALER03 .DAT   DEALER04 .DAT   DEALER05 .DAT   DEALER06 .DAT   DEALER07 .DAT   DEALER08 .DAT   DEALER09 .DAT   DEALER10 .DAT   DEALER11 .DAT   DEALER12 .DAT   DEALER13 .DAT   DEALER14 .DAT   DEALER15 .DAT   DEALER16 .DAT   DEALER17 .DAT   DEALER18 .DAT   DEALER19 .DAT   DEALER20 .DAT   DEALER21 .DAT   DEALER22 .DAT   DEALER23 .DAT   DEALER24 .DAT   DEALER25 .DAT   DEALER26 .DAT   DEALER27 .DAT   DEALER28 .DAT   DEALER29 .DAT   DEALER30 .DAT   DEALER31 .DAT   DEALER32 .DAT   DEALER33 .DAT   DEALER34 .DAT   DEALER41 .DAT   DEALER42 .DAT   DEALER43 .DAT   DEALER44 .DAT   DEALER45 .DAT   DEALERAI .DAT   DEALERNM .DAT   DEALERTB .DAT   DEMO_TIT .DAT   DEPAGA .CHR   DMONS .DAT, .SYM   DUMMY .CHR   ENCOUNT .DAT   ENCOUNTB .DAT   ENCOUNTR .DAT   ENCOUNTY .DAT   ENTHOU .CHR   FIGHT .DAT   FONT .DAT   FUJI .CHR   FUNANORI .CHR   FUSHIGI .CHR   GAMERM .CHR   GAUGE .DAT   GAUGE_B .DAT   GSAN .CHR   GSAN2 .CHR   HANAHANA .DAT   HERO .DAT   HOTELM .CHR   HOTELMAN .CHR   HOTELW .CHR   ITEMBIT .DAT   ITEMGOLD .DAT   ITEMMENU .DAT   ITEMNAME .DAT   JIBUN .CHR   JIKI .DAT   JIKI_BLU .DAT   JI_BACK .DAT   JUMPDAI .DAT   JUNSAR .CHR   KAKUTOU .CHR   KANNA .CHR   KASYA1 .DAT   KASYA2 .DAT   KASYA3 .DAT   KASYA4 .DAT   KEIBI .CHR   KENKYUIN .CHR   KIKUKO .CHR   KITOUSHI .CHR   KOJIRO .CHR   KOMONO .DAT   LOGOVER .DAT   LOLITA .CHR   LUCKY .CHR   MAPJIKI .DAT   MARUMON .CHR   font_us .dat   ", "excerpt": "On the 11th April 2020 the source code to the original generation of Pokemon games was released to 4chan as osrc.zip. This zip archive contained a password protected zip file called OriginalSouce.zip which was quickly cracked and found that the password was poke1024. This post will cover the contents of...", "tags": ["leak","gameboy"], "image": "/public/generated/placeholders/pokemon-original-source-code.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "PC-88 - NEC's Influential Japanese Microcomputer", "url": "/pc-88", "content": " [!error] AI writtenNot updated yet! Probably very wrongDevelopment of the PC-88What programming languages were used to create PC-88 software? In a 1985 interview, Nihon Falcom’s Masayuki Kato described the PC-8801 as “a machine that demanded direct manipulation of memory and hardware registers”, noting that most of their work on Dragon Slayer and Xanadu was done in Z80 assembly.Commercial PC-88 titles were predominantly written in Z80 assembly for performance, particularly games relying on fast scrolling, sprite multiplexing, or timing-sensitive sound routines. BASIC (N88-BASIC), included with the system, served as an entry point for hobby development and some productivity software. Later PC-88MA models supported MS-DOS and high-level languages such as C, but commercial game development continued to rely mainly on assembly for deterministic control over the video and FM sound hardware.What tools were used to create the art for PC-88 games? Enix artist testing notes from 1987 reference “pixel boards” and “RGB preview rooms” where artists would repeatedly verify that PC-8801 palette constraints matched intended designs.Pixel art was often created on external workstations or specialized drawing tools before being converted into PC-88 bitplane formats. Early studios used: NEC’s internal graphics editors supplied to licensed developers Proprietary in-house editors running directly on the PC-88 X68000 or FM Towns machines for cross-authoring, then exporting assets to PC-88 formatsDue to 8-color display limitations on early models, artists relied heavily on dithering, careful adjacency of palette indices, and structured shading patterns. Later VA models with 640x200 65-color modes broadened stylistic possibilities.How long did it take to create typical PC-88 games? In a 1992 retrospective, Hideo Kodama of Micro Cabin stated that the first Xak title was produced by “a team of five over roughly eight months”, with the majority of engineering time spent on scrolling and text rendering systems.Small teams were common. Development cycles ranged from 3 to 12 months depending on genre and asset complexity. Studios developing adventure and visual novels often worked faster due to static screens, while RPGs or action games required extended tooling and engine creation.Why was the PC-88 significant in Japanese game development? According to a 2010 interview with Nihon Falcom founder Masayuki Kato, “the PC-88 was the proving ground for an entire generation of Japanese creators. Its limitations forced invention”.The PC-88 became a pivotal platform for early Japanese PC game development due to: Widespread adoption in schools and businesses Accessible N88-BASIC environment for learners Availability of FM synthesis (OPN) sound hardware on later models Rich market for doujin games Strong backing from NEC and a robust distribution channelMajor franchises such as Ys, Dragon Slayer, Sorcerian, Policenauts, and early visual novels established templates that influenced later PC and console ecosystems.PC-88 Hardware DetailsVideo hardware and graphics pipelineThe earliest PC-8801 models used a planar graphics system with 640x200 resolution and an 8-color fixed palette derived from RGB combinations. There was no hardware sprite engine; all animation was achieved through software blitting, often optimized with handwritten Z80 routines. Later VA models expanded to a 65-color palette and supported hardware scrolling.Audio hardware Composer Yuzo Koshiro recalled that programming the YM2203 for Ys required “writing long sequences of register values by hand” before later upgrading to macro-based sound drivers.Audio configuration varied by model: Early PC-88: simple PSG (AY-3-8910 compatible) Later PC-88: Yamaha YM2203 (OPN) FM synthesis Doujin scene: custom or modified sound drivers enabling richer FM patchesFM-supported models became essential for studios producing music-heavy RPGs and action titles.Storage and mediaThe system supported: 5.25-inch floppy disks (common distribution medium) Optional cassette interface on early units Hard disk options on later MA systems running MS-DOSGame Development at FalcomInternal workflow and tools A 1988 Falcom technical note states: “Each new game begins with a fresh graphics converter and a fresh sound driver”, highlighting their iterative approach to tooling.Falcom pioneered efficient reuse of subsystems across titles. Their structure around 1987 included: Lead Programmer – Masayuki Kato Composer – Yuzo Koshiro or Mieko Ishikawa Scenario Planner – Yoshio Kiya Graphic Designers – rotating teams of 2 to 4 artistsThey maintained custom assemblers, map editors, FM music drivers, and debugging tools for rapid iteration.PC-88 Source CodeYs I (1987 by Nihon Falcom)Partial source materials, including disassemblies and fan analyses of sound drivers, are available through community preservation projects. These include: Disassembled Z80 instruction traces Reconstructed map formats FM and PSG driver documentationPolicenauts (Prototype PC-88 build)Early assets and test scripts from the uncompleted PC-88 version circulate among preservation groups, offering insight into adventure-engine architecture designed for NEC platforms.References", "excerpt": "[!error] AI written Not updated yet! Probably very wrong Development of the PC-88 What programming languages were used to create PC-88 software? In a 1985 interview, Nihon Falcom’s Masayuki Kato described the PC-8801 as “a machine that demanded direct manipulation of memory and hardware registers”, noting that most of their...", "tags": ["pc-88","pc"], "image": "/public/generated/placeholders/pc-88.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "PC-Engine", "url": "/pc-engine", "content": "Introduction to the PC-EngineSakharu Baguette has created an excellent documentary which explores the history of the PC Engine (known as the TurboGrafx-16 in North America), detailing its rise as a major rival to Nintendo in Japan and its struggle to find footing in the US 1.How were games distributed for the PC-Engine?Instead of bulky cartridges, games were released on HuCards (credit-card-sized chips), which were cheaper to make and futuristic for the time.How did the PC Engine work?Retro48K has an excellent video diving in to the low level details of the PC engine hardware:What CPU did the PC-Engine use?The PC-Engine used the 8-bit Hudson Soft HuC6280, an enhanced 65C02 derivative running at selectable 1.79 or 7.16 MHz. It added a memory management unit for bank switching, integrated timers and IRQ handling, and simple I/O functions, making it a compact but efficient control CPU for the system.HardwareRetail HardwareIf you’re interested in learning more about the hardware architecture of the NES, we highly recommend checking out the post on Copetti.org. PC-Engine Hardware Architecture - A Practical Analysis Copetti.org has an excellent page on the Hardware and how it works Consumer Development HardwareDevelo boxThe Develo box was a development kit sold to consumers allowing development of PC-Engine software via either an interface that can connect to either the MSX or PC-9801 2. It was created by Tokuma Shoten Intermedia.From the book “The untold history of Japanese Game Developers Volume 2” we can see a photo of the Develo Box in action:There were two books released for the plaform, one for assembly language and the other for basic, you can find out more on Develo BooksFor more images of the Develo Box check out the page on Generation MSX:Tokuma Shoten Intermedia - DEVELOでべろBOX - Generation MSXSound on the PC-EngineInterview with Takayuki Hirono where he explains the differences between the sound capabilities of the Famicom compared to the PC-engine:An Interview with 8ing and developers from Compile and TechnoSoft - YouTubeReferences The PC-Engine Chronicles, the unexpected success of an unusual console - A TurboGrafx-16 Documentary ↩ Tokuma Shoten Intermedia - DEVELOでべろBOX - Generation MSX ↩ ", "excerpt": "Introduction to the PC-Engine Sakharu Baguette has created an excellent documentary which explores the history of the PC Engine (known as the TurboGrafx-16 in North America), detailing its rise as a major rival to Nintendo in Japan and its struggle to find footing in the US 1. How were games...", "tags": ["pc-engine","introduction"], "image": "/public/generated/placeholders/pc-engine.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "PDB Files - Using PDB files for Reverse Engineering", "url": "/PDBFileReversing", "content": "If you are very lucky indeed then the game you want to reverse engineer comes with full debug symbols in the form of a Program Database file or PDB for short.These files tend to be created by Microsoft Visual C++ compilers and contain all the debug symbol information for an executable (function names, class names etc) 1.This means the PDB files are much more likely for platforms such as the PC and Xbox.They are a lot harder to find than executables with symbols embedded inside as it is much easier for developers to spot the file on a disc than to check if an executable is suspiciously large.This means that the number of retail games that come with full PDB files is very low indeed, almost like a needle in a haystack.PDB files pretty much takes away the bulk of the work of a reversing project, as you no longer need to find out what to name every function and it is easy to see where to start.But the question is, how do we use these binary blobs of debug data to give our executables back their function names? That is exactly what this post will cover.Displaying the symbols located in a PDB filePDB files are not like GCC .map or .sym files, they are n to plain text, they are a custom binary format.So in order to display the debug information that is contained in a PDB file you can use a tool like radare2, or more specifically rabin2 which is a tool that comes as part of standard radare2.To use rabin2 to display the symbol information to the command line you can run the following command:rabin2 -P YourFile.pdbAlso if it is a fairly standard executable that you are reversing you can check to see if radare2 can download a pdb file for your executable from the official Microsoft symbol server like so:rabin2 -PP YoutFile.exeUsing PDB files with Binary NinjaBinary Ninja makes it almost too easy, just open your game executable and perform analysis like usual. Now go to the Tools menu and select PDB -> Set Symbol Path.This will open a file dialog, use it to find where you have your .pdb file. Now if you are lucky and the pub file matches the executable that you have analysed you should start seeing function names being populated in the interface!Using PDB files with GhidraTo load a pdb file, first open the PE game executable and run analysis. Next just Go to the menu option File -> Load PDB File.If the executable is in the PE format and has been compiled with debug support Ghidra will start to populate the function names correctly.Note that there is also a Download PDB file but it is really only for standard Microsoft symbols.Using PDB files in radare2First of all load the binary into radare2 but DO NOT run analysis yet!Instead you need to run idp to load the pdb file if its in the same directory as the executable and then run analize as normal.References https://reverseengineering.stackexchange.com/questions/17298/pdb-file-vs-sdb-file ↩ ", "excerpt": "If you are very lucky indeed then the game you want to reverse engineer comes with full debug symbols in the form of a Program Database file or PDB for short. These files tend to be created by Microsoft Visual C++ compilers and contain all the debug symbol information for...", "tags": ["introduction","tutorial","tools","xbox","pc"], "image": "/public/generated/placeholders/pdbfilereversing.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Playstation 1 PsyQ Linker (Psylink.exe)", "url": "/ps1-psylink", "content": "PSY-Q Linker FilesThe PS1 linker files for the game chicken run by Blitz Games were made publicly available and are available for both the release and the demo version: crtest.lnk and crdemo.lnk respectively.So what are these control (.lnk) files?Control files are files that help the linker to decide where in memory a specific binary should be placed, they can be given any extension but using .LNK was common practise as the official PSYQ development samples used this file naming convention.So if you have a .lnk file you can figure out the structure of a PlayStation executable, which libraries were used and what the original source file names would have been.How would a developer use .lnk files in their workflow?You can pass a .lnk file as a control parameter to the PSX Linker (PSYLINK.EXE) like so:$(PSYLINK) /l $(LIBISL) /psx /wo /v /c /strip /nostriplib @crdemo.lnk,crdemo.cpe,crdemo.sym,crdemo.mapThe use of the @ operator is explained in the PSX developer documentation: Long command lines can be stored in control files. By using an ‘@’ sign in front of the control file name the contents of the control file can be embedded in the command line. The contents of the control file can be split across several lines without the need to use any special characters. An end of line in a control file is treated as a space. You can specify as many control files as you want on the command line and a control file can even reference another control file.ORG directiveThe ORG directive is normally used is assemblers/linkers to choose a specific location for certain pieces of code. For the PS1 the executable is normally started at location 0x00018000 but for demos it seems to be 0x80018000, not sure why.; org $00018000; 18000, this is a demo disk... org $80018000REGS directiveThe REGS directive sets the initial value of registers, in the case below this will set the program counter to the location of __SN_ENTRY_POINT which is a symbol defined in the standard library SNLIB.LIB. \t\tregs pc=__SN_ENTRY_POINT\tGroup directiveYou can also specify a section group such as text or bss here. In this executable we only have text for code and bss for small static variable init. Also it looks like they used to have a grouo called dcache but it was commented out.text group; I've removed the dcache area so that it's definitely all available; for the model plotter. So just be careful to use it for leaf-routine; optimisations only, rather than the placement of moderately commonly used; globals (as was the case in the shell) - Fred;dcache group obj(0x1f800000),size(0x400)bss group bss\tOverlaysThe PSYQ development kit offered a unique feature called Overlays which allowed developers to switch out parts of the executable at run time, meaning they could load different executable code into memory at different times. This allowed better use of memory as developers were not limited to just the space of RAM.Chicken run demo didn’t use overlays but the main released game did, it looks like they made effective use of this feature by splitting the game into subgames and using the same section of memory (vid_ovl) to load the subgame in depending on where the player is.;overlay1 group file(\"overlay1.bin\") ; Test 1;overlay2 group over(overlay1),file(\"overlay2.bin\") ; Test 2;vid_ovl group over(overlay1),file(\"vid_ovl.bin\") ; video playvid_ovl group file(\"vid_ovl.bin\") ; videosub1_ovl group over(vid_ovl),file(\"sub1_ovl.bin\") ; subgamessub2_ovl group over(vid_ovl),file(\"sub2_ovl.bin\") ; subgamessub4_ovl group over(vid_ovl),file(\"sub4_ovl.bin\") ; subgamesdeb_ovl group over(vid_ovl),file(\"deb_ovl.bin\") ; debug menu; exp_ovl\t\t\tgroup\tover(overlay1),file(\"exp_ovl.bin\")\t; explore gameAlso of interesting note is there is a debug menu in the game that occupies this same region of memory, does this mean the debug menu doesn’t apply when in the sub games? Also what happened to sub3? they went straight to subgame 4…Section directiveThe section directive allows youto specify the order of sections within the executable, if a section is missed out such as “icontim” it will be added to the start.So for example if in the example below the section\t.bss,bss was missed out, it would still create that section but it would be before the other sections.Example:; section.4096 align4k.text,text; section align4k.*,text; section align4k.bss,bss; section align4k.sbss,bss\tsection .*,text\tsection\t.sdata,text\tsection\t.sbss,bss\tsection\t.bss,bss\tsection vid_ovl.*, vid_ovl\tsection sub1_ovl.*, sub1_ovl\tsection sub2_ovl.*, sub2_ovl\tsection sub4_ovl.*, sub4_ovl\tsection deb_ovl.*, deb_ovlYou can see the difference that the section directive makes by inspecting the map file generated, change the order of sections or comment some out to see what the default behaviour is.Note that it will still group sections together based on the group directive, so the text sections will be together and the bss sections will be grouped together.INCLUDE directiveThe Include directive is used to include a specific compiled C/asm object, normally produced by a C compiler, this will allow specifying the rough order that the objects should be linked in the executable, but note that the linker can reorder during optimisation so this order is not guaranteed!Example based on the Chicken Run crdemo.lnk:;include \"fixed.obj\";include \"powerbar.obj\";include \"fx.obj\";include \"map_asm.obj\";\"Particle\" was being initialised, but never used for anything;include \"particle.obj\" include \"demostub.obj\" include \"dualshock.obj\" include \"pad.obj\"; include \"options.obj\"; include \"gallery.obj\"; include \"cntrscn.obj\" include \"fmademo.obj\" include \"inv_demo.obj\" include \"startup.obj\" include \"credits.obj\" include \"timer.obj\"; include \"main.obj\" include \"maindemo.obj\" include \"actor.obj\"; include \"lev_flow.obj\" include \"map_view.obj\" include \"map_play.obj\" include \"bff_load.obj\" include \"map_draw.obj\" include \"snapshot.obj\" include \"debris.obj\" include \"lights.obj\" include \"puzzles.obj\" include \"collide.obj\" include \"maths.obj\" include \"camera.obj\" include \"enemies.obj\" include \"platform.obj\" include \"platcoll.obj\" include \"overlays.obj\" include \"scenics.obj\" include \"sound.obj\" include \"cr_asm.obj\" include \"sptstream.obj\"; include \"card.obj\" include \"loadsnd.obj\" include \"help.obj\" include \"deth.obj\" include \"demo.obj\" include \"nme_dogs.obj\"\t;,exp_ovl include \"nme_mrst.obj\"\t;,exp_ovl include \"route.obj\" ;,exp_ovl include \"sprouts.obj\"\t;,exp_ovl include \"charactr.obj\"\t;,exp_ovl; include \"curtains.obj\"\t;,exp_ovl include \"language.obj\" include \"map.obj\" include \"pause.obj\";include \"stilts.obj\";include \"station.obj\";include \"fxtest.obj\" include \"subgame.obj\"; include \"menu.obj\",deb_ovl; include \"viewer.obj\",deb_ovl; include \"cus_dyn.obj\",deb_ovl; include \"cus_full.obj\",deb_ovl; include \"dogchase.obj\",sub1_ovl include \"fireworks.obj\"; include \"catapult.obj\",sub2_ovl; include \"seesaw.obj\",sub2_ovl; include \"engine.obj\",sub4_ovl; include \"construct.obj\",sub4_ovl; include \"wings.obj\",sub4_ovl; include \"egglaying.obj\",sub4_ovl; include \"crate.obj\",sub4_ovl;include \"overlay1.obj\", overlay1;include \"overlay2.obj\", overlay2; Things that have been adapted from the ISL libs, rather than; actually using them include \"custom.obj\" include \"custom2.obj\" include \"cus_anim.obj\"; include \"islvideo.obj\",vid_ovl include \"islutil.obj\" include \"incbin.obj\" include \"islxa.obj\" include \"islfile.obj\"\t\tinclude \"islfont.obj\"Inclib DirectiveThe inclib directive is very similar to the include directive but instead links in a full library of files.Example from Chicken Run source code:; The ISL libraries; \"Debug\" or \"Release\" versions are switched between in the makefile; by cunning use of environment variables. inclib \"islmem.lib\" inclib \"isltex.lib\" inclib \"isllocal.lib\" inclib \"islpad.lib\" inclib \"islsfx2.lib\" inclib \"islcard.lib\" inclib \"islcard.lib\"; -- REMOVED ISL LIBS --; -- video has the multi-language stuff --; -- psi is now in custom.c --; -- util has had it's un-flat-packer rewritten --; -- sound is now islsfx2 --; -- xa has a fix for \"current sector\" establishment; -- file has an assert check for XA playing; -- islfont now copes with \"OE\" and \"oe\" for French use; inclib \"islvideo.lib\"; inclib \"islutil.lib\"; inclib \"islpsi.lib\"; inclib \"islsound.lib\"; inclib \"islxa.lib\"; inclib \"islfile.lib\"; inclib \"islfont.lib\"; -- Sony Libs -- ;inclib \"libsn.lib\" ;inclib \"c:\\psx\\crtest\\source\\none2.lib\"; Fred's cunning plan:; PSX\\ISL\\LIB\\DEBUG\\NONE2.LIB is actually LIBSN.LIB; PSX\\ISL\\LIB\\RELEASE\\NONE2.LIB is the real thing\t inclib none2.lib\tinclib \"libapi.lib\"\tinclib \"libpad.lib\"\tinclib\t\"libmcrd.lib\"\tinclib\t\"libcard.lib\"\tinclib \"libgpu.lib\"\tinclib \"libgs.lib\"\tinclib \"libgte.lib\"\tinclib \"libcd.lib\"\tinclib \"libetc.lib\"\tinclib \"libspu.lib\"\tinclib \"libc2.lib\" inclib \"libds.lib\"; inclib \"libpress.lib\",vid_ovlOBJ File formatWhen you pass -c to CCPSX.EXE it can generate a compiled object for each of the source files, this is very useful when you have a make file set up using PSYMAKE.EXE, and you can be reasonably confident most games were developed with some sort of build system such as PsyMake.The resulting obj files are in the LINK 2 format and can be dumped using the PSYQ development tool called DUMPOBJ.EXE, you will have to run this in DOSBOX as it is a 16-bit executable.DUMPOBJ.EXE hello.obj /c >hello_dumped.txtThis will produce output similar to:Header : LNK version 246 : Processor type 716 : Section symbol number 1 '.rdata' in group 0 alignment 816 : Section symbol number 2 '.text' in group 0 alignment 816 : Section symbol number 3 '.data' in group 0 alignment 816 : Section symbol number 4 '.sdata' in group 0 alignment 816 : Section symbol number 5 '.sbss' in group 0 alignment 816 : Section symbol number 6 '.bss' in group 0 alignment 816 : Section symbol number 7 '.ctors' in group 0 alignment 816 : Section symbol number 8 '.dtors' in group 0 alignment 828 : Define file number 9 as \"HE\\HELLOWORLD.C\"6 : Switch to section 26 : Switch to section 12 : Code 14 bytes0000:48 65 6c 6c 6f 2c 20 57 6f 72 6c 64 21 00 6 : Switch to section 26 : Switch to section 26 : Switch to section 22 : Code 76 bytes0000:e8 ff bd 27 14 00 bf af 10 00 be af 21 f0 a0 03 0010:00 00 00 0c 00 00 00 00 00 00 04 3c 00 00 84 24 0020:00 00 00 0c 00 00 00 00 21 10 00 00 00 00 00 08 0030:00 00 00 00 21 e8 c0 03 14 00 bf 8f 10 00 be 8f 0040:18 00 bd 27 08 00 e0 03 00 00 00 00 10 : Patch type 74 at offset 10 with [b]10 : Patch type 82 at offset 18 with (sectbase(1)+$0)10 : Patch type 84 at offset 1c with (sectbase(1)+$0)10 : Patch type 74 at offset 20 with [c]10 : Patch type 74 at offset 2c with (sectbase(2)+$34)6 : Switch to section 260 : End SLD info at offset 014 : XREF symbol number b '__main'14 : XREF symbol number c 'printf'12 : XDEF symbol number a 'main' at offset 0 in section 274 : Function start : section 0002 offset $00000000 file 0000 start line 0 frame reg 30 frame size 24 return pc reg 31 mask $c0000000 mask offset -4 name main76 : Function end : section 0002 offset $0000004c end line 00 : End of fileNotice that in the example we have a definition (XDEF) for the main function and we are referencing (XREF) printf from the standard libraries.The code for the function is printed in hexidecimal but you can convert this to assembly using a disassembler.LIB File formatA library file is just a collection of object files in the same format as above. In fact a lib is just an archive of them! The PSYQ development kit comes with a set of official sony libraries that are used in almost every retail game released.You can print the contents of a library (.lib) file using the PSYQ development tool called PSYLIB.EXE like so:PSYLIB.EXE \\l LIBSN.LIBThis will result in output like so:PsyLib version 2.04Module Date Time Externals definedOPEN 20-09-95 20:44:22 PCopen CLOSE 20-09-95 20:44:22 PCclose LSEEK 20-09-95 20:44:22 PClseek CREAT 20-09-95 20:44:22 PCcreat SNREAD 20-09-95 20:44:22 _SN_read SNMAIN 20-09-95 20:44:22 __bss __heapsize __SN_ENTRY_POINT __bsslen __data __main __text __datalen __textlen __do_global_dtors __heapbase Each Module would be a .c/.asm file compiled into an object file and then added to the library using the PSYLIB /a option. You can extract all the object files by passing the /x command line flat to PSYLIB.EXE.", "excerpt": "PSY-Q Linker Files The PS1 linker files for the game chicken run by Blitz Games were made publicly available and are available for both the release and the demo version: crtest.lnk and crdemo.lnk respectively. So what are these control (.lnk) files? Control files are files that help the linker to...", "tags": ["ps1","sdk","assembly"], "image": "/public/PS1_PsyQ_Linker.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Sony PlayStation 1 (PSX)", "url": "/ps1", "content": "Introduction to Hacking the Sony PlayStationThe PlayStation One was not only Sony’s first commercial video games console it was also the most popular console of its generation.The PS1 was competing against both the Nintendo 64 and Sega Saturn during its lifetime and in some respects was the underdog in terms of processing power and graphics. However don’t be disillusioned the PS1 was still a very powerful machine for its time and when programmed correctly games could look stunning, sometimes even better than the Nintendo 64!GamesWhat would the Sony PlayStation be without its excellent line-up of games? It was the games that attracted many people away from the Nintendo 64 and Sega Saturn and on to their very first Sony console.PlayStation 1 Games with Debug SymbolsAn excellent way to start reverse engineering is to find games where the developers accidentally left the Debug symbols in the retail release of the game. While this is not very common it has happened for a few games released for the PlayStation One and gives you access to all the original function and variables names that were used in the retail source code. Playstation 1 Games with Debug Symbols For a list of PS1 games that have debug symbols available check out this post. Crash BandicootCrash Bandicoot was one of the first 3d platformers that managed to deliver quality gameplay while looking impressive for its time.It was created by Andy Gavin and Jason Rubin for release on the original PlayStation console, and both developers have been kind enough to share ample amount of information on how the game was implemented. Crash Bandicoot To find out how Crash Bandicoot was developed check out this post. Evolution of (Playstation) PS1 Games 1995-2018GameForest presents a comprehensive visual timeline of the PlayStation platform’s library, showcasing the graphical and gameplay evolution from 1995 to 2018. The compilation chronicles major releases across the console generations, starting with early PS1 titles like Jumping Flash! and Arc the Lad, moving through the PS2 and PS3 eras with defining games such as Grand Theft Auto and Uncharted, and concluding with modern PS4 blockbusters like Horizon Zero Dawn and God of War.PS1 ExclusivesThe most valuable reverse engineering projects tend to be the platform exclusives that have never been re-released as these are the games that can benefit the most from enhancements on modern hardware.Wikipedia maintains a list of PlayStation 1 exclusives - PlayStation (console)-only games - WikipediaRemastered PS1 GamesSome classic PS1 games have been remastered or remade for more modern consoles, if you are looking to reverse engineer one of these games it may help to look at the modern version to find additional information that may be relevant. Name Platform Notes Ape Escape PSP Source Code was ported to the PSP as Ape Escape: On the Loose Crash Bandicoot 1-3 PS4, Switch, PC, XboxOne Remade in Alchemy engine but tried to be as faithful as possible to the originals Crash Team Racing PS4, Switch, XboxOne Remade in Alchemy Engine with additional content from Crash Nitro Kart and Crash Tag Team Racing Castlevania SOTN Xbox360, PS4, iOS, Android Re-Released in Castlevania Requiem compilation Final Fantasy 7-9 PS4, Switch   Legend of Mana PS4, Switch, iOS, Android Original engine but with higher resolution assets? (confirmation required) MediEvil PS4 Remade in the Unreal Engine Mega Man X 4 PS4, Switch, XboxOne Source Code Port of X4 Released in Mega Man X Legacy Collection Metal Gear Solid Gamecube Remade for Gamecube as Metal Gear Solid: The Twin Snakes PaRappa The Rapper PSP, PS4 The PS4 version is actually just a the PSP version emulated with higher resolution assets Resident Evil 1-3 PS3, PS4, XboxOne Does this use original engine with higher resolution assets? SaGa Frontier PS4, Switch, iOS, Android, Windows   Spyro 1-3 PS4, Switch Remade in Unreal Engine 4 but aims to be as faithful as possible to the originals Tony Hawk’s Pro Skater 1+2 PS4/5, Switch, XboxOne Remade in Unreal Engine 4 Wipeout Omega Collection is one game that did not make the list as its technically not a remaster of the PS1 original.This list also doesn’t include projects such as PS one Classics as they were just emulations of the original PS1 games running on a more modern console and not either a source port or a full remake.Tool-Assisted-Speedruns (TAS) for PS1In this video EZScape demonstrates a few speed runs for PS1 games that could never be possible by humans as they require changing the controller input every single frame. He shows techniques such as Zig-zagging in Crash Bandicoot, Pac-Man World and Spyro 3.If you are interested in creating your own Tool-Assisted-Speedruns then you might want to check the latest version of BizHawk. If you are interested in improving some existing TAS then check out PS1 Tool-assisted movies - TASVideosHomebrewPSXSplash Documentation: Unity to PS1 HomebrewThe PSXSplash documentation provides a comprehensive guide for using SplashEdit, a Unity editor package designed for building PlayStation 1 games. This toolchain allows developers to design scenes in Unity, write game logic using Lua, and export the project directly to real PS1 hardware or emulators. The documentation covers essential technical topics such as VRAM packing, texture quantization, MIPS compiler integration, and Lua API references for handling entities, audio, and animations. Introduction - PSXSplash Documentation The PSXSplash documentation offers a detailed technical walkthrough for using Unity as a front-end editor to create authentic homebrew for the original PlayStation. HardwareRetail PlayStation hardwareThe PS1 was competing against both the Nintendo 64 and Sega Saturn during its lifetime and in some respects was the underdog in terms of processing power and graphics.The Hardware initially looks quite clean and simple, especially in comparison to other consoles of its generation, but it still managed to pack a lot of power on to its small design.The main parts of the hardware are: 32-bit MIPS CPU (33.96Mhz) GPU - Unlike more modern GPUs it Only handled 2D Polygons (360k per second) 1 Geometry Transformation Engine (GTE) - 1.5M Vertices per second 1 24 Channel sound chip (SPU)Main Board The CPU (MIPS R3000A 33.96Mhz 32-bit 2) ROM containing the Operating System (512KB 2) The GPU Main RAM (DRAM) Video RAM (VRAM) Sound Processing Unit (SPU) Sound RAM (512K) CD Controller CD DSP (Digital Signal Processor) Digital Audio Converter ??? Video de/encoder The CPUIf you thought that the Nintendo 64 was the only console that partnered with SGI for this generation of consoles you would be mistaken, the CPU for the original PlayStation used technology licensed from SGI and build by LSI Logic Corp 3.The CPU used for the PlayStation was not just a simple MIPS R3000A, it was partnered with additional co-processors to handle system resources and geometry processing. There was actually only 2 co-processors in the CPU named COP0 and COP2 as COP1 and COP3 were not present in the chip.System Control Co-processor (COP0)The System control co-processor was the part of the CPU that handled memory management, interrupts and hardware breakpoints. This allows the main processor to focus on game logic while the system co-processor handled all the lower-level details 4.Geometry Transformation Engine (GTE)The Geometry Transformation Engine (GTE) was what allowed the PlayStation to handle 3D graphics, it was specifically designed to do the sort of fast mathematical calculations used for Vertex/Geometry processing. Without it the PlayStation hardware would not have been able to pull of the excellent 3D graphics it was known for in its time.The GTE is the second co-processor attached to the main processor of the PS1 and this it is also reffered to as Cop2.It is ideal for the mathematics required to do calculations in 3D space, as it is much faster than the main cpu for these sort of calculations.Some of the main uses for the GTE are: 3D Rotation/Translation/Projection calculations Fogging calculations Lighting calculations Colour calculationsThe PSY-Q development environment exposes the gte functionality to programmers using a bunch of functions and assembly instructions that start with gte_, for example gte_ncdt().One interesting limitation of the PS1 GPU is that it didn’t have a Z-buffer so polygons needed to be sorted by the PS1 CPU instead, so often the Painters algorithm was used 5.Development Kit HardwareDevelopment kits are released to game developers before the launch of the system to allow games to be developed for the system’s launch. These systems would evolve over the systems lifespan and contained useful features for debugging and optimizing games for the platform. These systems were not just limited to the official offerings by Sony as a few other publishers had their own versions of development hardware.Official Development KitThe official development kit for the PS1 was a partnership between Sony and SN Systems which allowed developers to use their PC to interact with the real PS1 hardware. Official PlayStation 1 Development Kit (Hardware) For more information on the official Sony PlayStation Devkit check out this post. Official Consumer Development Kit (Net Yaroze)The official development kit for the PS1 was only available for licensed game developers but there was a stripped-down version available for the general public known as Net Yaroze. Net Yaroze - The PS1 Consumer Dev Kit For more information on the consumer development kit known as Net Yaroze check out this post. Unofficial Hardware Add-onsSony PlayStation VCD Player Add-On CardThe YouTuber Scarlet Sprites has a good overview of this rather rare unofficial Chinese PS1 add-on which allowed playing the rather obscure Video CD (VCD) format on retail PlayStation 1 consoles:It plugged into the back of the console via the IO and AV ports without any need for additional power and has a switch on the top to switch between VCD mode and game mode. This suggests that the PlayStation first boots into the IO port before running the game disc.Also note that there was an official PS1 model released in Japan that played Video CDs called the SCPH-5903 VideoCD which has additional hardware inside the console.Software Development KitsOfficial Software development kitThe Official Software development kit was developed by a partnership between SN Systems who are known for excellent 3rd party development kits and the Game Studio Psygnosis who are known for excellent quality games.It was initially called PSY-Q and even although it was owned by Sony it was actually a cross-platform development kit which included support for the Sega Saturn!Sony later rebranded the SDK to SDevTC at some point in 1998(?). Official PlayStation 1 Software Development Kit (PSYQ) For more information on Official SDK for the PlayStation 1 check out this post. Official 3D Graphics Tools (DTL-S220A)In August 1998 Sony provided a CD to developers with a bunch of 3D Graphics tools6 such as: Meditor - Material Editor BMP2TIM, PICT2TIM, RGB2TIM, TIMUTIL.EXE - Tools to convert image formats into the PS1 texture image format TIMAlso provided was the 3D Graphics Tools manual with tutorials on how to use the provided software.PS1 File formats Playstation 1 File Formats For more information on PS1 File Formats check out this post. PS1 Executable FormatThe PS1-EXE (executable) format is detailed in the post below: PSX-EXE Format For more information on PS1 EXE File Format check out this post. PS1 Emulationbleem! Commerical PS1 Emulator for Pentium 166+ PCsZophar has released an in-depth interview with veteran programmer Randy Linden, diving into his extensive career in reverse engineering and emulator development. The video covers the technical hurdles of creating the bleem! PlayStation emulator for the PC, including the implementation of a dynamic optimizing recompiler to achieve playable speeds on a Pentium 166. Additionally, it details his groundbreaking work reverse engineering hardware to port Doom to the Super Nintendo using the Super FX chip.Game Asset Creation ToolsEver wondered how your favourite game artists made assets for PlayStation 1? Although the exact software used for most games are still a secret, we have managed to piece together what we know so far about how 3D models and 2D Images were created.What software was used to create 3D models for PS1 games?To create 3D models for PlayStation 1 games the following tools are known to have been used: trueSpace for PlayStation - Directly reads the PS1 RSD format rather than going through the standard DXF 6 3D Studio - Exports to DXF format AutoCAD - Exports to DXF format but not really made for game developmentWhat software was used to create 2D Textures and Sprites for PS1 games?To create textures (and therefore sprites) the following tools are known to have been used: Adobe Photoshop - A plugin was available to directly edit PlayStation TIM files without requiring conversion 6.Reverse Engineering PS1 GamesRadare2First you need to find the executable on the PS1 disc image, it will be named after the unique Sony Code e.g SLES_032.85.Then open it with radare2 like so:r2 ./SLES_032.85Fix the PS1 Offset in r2To Disassemble PS1 Binary files (MIPS little endian) you need to map a file at offset 0x80010000 like so:o ./SLES_032.85 0x80010000 rwxReplace SLES_032.85 with the location of your own PSX executable.Now we want to analyze all the functions in the executable like so:aaaaAll Posts Batman Forever - The Arcade Game (1996) As the name suggests Batman Forever is originally an Arcade Game that got ported to MS-DOS, the Playstation 1 and Sega Saturn by Iguana Entertainment (Acclaim Published). The original arcade... ... Read More saturn sega ps1 games Capcom Leaks On 1st November 2020 CAPCOM was targeted by known hacker group RagnarLeaks and some source code and private data was leaked to the dark web. This post will only cover... ... Read More leak ps1 ps2 wii Chicken Run Source Code Developed by Blitz Games (formerly known as Interactive Studios Limited) in 2000 as a cross platform action adventure game based on the movie with the same name. Throughout the engine... ... Read More dreamcast ps1 pc games sourcecode Crash Bandicoot Introduction to Crash Bandicoot Crash Bandicoot was one of the first 3D Platform games that managed to deliver both quality gameplay and impressive graphics for its time. It was developed... ... Read More ps1 games Behind the Scenes (Making Of) Playstation Games in PlayStation Underground PlayStation Underground List of known issues (CD-ROMs): PlayStation Underground Volume 1.1 - Making of the Twisted Metal 2 Commercial - Making of NFL Game Day 97 PlayStation Underground Volume 1.2... ... Read More documentary ps1 games Net Yaroze - The PS1 Consumer Dev Kit Introduction to the Net Yaroze The Net Yaroze was a consumer development kit for the PlayStation 1, it consisted of a customised retail console with the ability to connect to... ... Read More ps1 hardware devkit Official PlayStation 1 Software Development Kit (PSYQ) History for the PSY-Q SDK The History of the PSYQ PS1 Software development kit is fascinating, it starts with a collaboration between two UK companies, SN Systems and Cross Products,... ... Read More snsystems sdk psyq ps1 Playstation 1 PsyQ Linker (Psylink.exe) PSY-Q Linker Files The PS1 linker files for the game chicken run by Blitz Games were made publicly available and are available for both the release and the demo version:... ... Read More ps1 sdk assembly Playstation 1 File Formats File Formats used to distribute PS1 Discs A Playstation One CD can either be directly put into your PC via the CD-ROM drive or mounting a .BIN/.ISO file. All of... ... Read More ps1 reverseengineering fileformats Playstation 1 Games with Debug Symbols I have never seen a PS1 executable bigger than 2mb, normally if they require more code they split it into multiple executables. With memory being so precious it would be... ... Read More ps1 reverseengineering symbols Official Sony PS1 Libraries Note that the order of the externals defined in this list will not reflect the order in the final linked executable, as the order here is just the order that... ... Read More ps1 sdk symbols PSYQ SDK Setup on MacOSX/Linux Hello World example We are going to use the PSX Hello world example from PSXDEV (http://www.psxdev.net/help/psyq_hello_world.html) Create a new file called Hello.C /* =========================================================== Sony PlayStation 1 Source Code ===========================================================... ... Read More ps1 reverseengineering sdk tutorial Official PlayStation 1 Development Kit (Hardware) This post covers the hardware used to develop PlayStation One games by major studios back in the day, for the software side see the post on the PsyQ Software Development... ... Read More ps1 hardware devkit PSX-EXE Format The PS-X EXE format is the PlayStation 1’s main “load this into RAM and jump to it” executable format. It is used for both retail discs and homebrew. Despite the... ... Read More ps1 sdk fileformats References 20 Years of PlayStation®. Console development past and future - Unite Europe 2015 - YouTube ↩ ↩2 What’s inside a Playstation? - YouTube ↩ ↩2 PlayStation technical specifications - Wikipedia ↩ www.raphnet.net/electronique/psx_adaptor/Playstation.txt ↩ Edge Magazine issue 20 (May 1995) ↩ 3D Graphics Tools manual from August 1998 ↩ ↩2 ↩3 ", "excerpt": "Introduction to Hacking the Sony PlayStation The PlayStation One was not only Sony’s first commercial video games console it was also the most popular console of its generation. The PS1 was competing against both the Nintendo 64 and Sega Saturn during its lifetime and in some respects was the underdog...", "tags": ["ps1"], "image": "/public/images/RetroReversingLogoSmall.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Playstation 1 File Formats", "url": "/ps1-file-formats", "content": "File Formats used to distribute PS1 DiscsA Playstation One CD can either be directly put into your PC via the CD-ROM drive or mounting a .BIN/.ISO file. All of these are just ways to be able to see the contents of a PS1 Disc similar to a folder of files. Extension Description .BIN A BIN file needs a .CUE file in order to be useful, it is the raw binary contents of a PS1 disc .CUE A CUE sheet describes a .BIN file and can be mounted on a pc to reveal the file system of the disc .ISO A ISO file can be mounted on a pc to reveal the file system of the disc .CHD Compressed Hunks of Data (CHD) format intiially created by MAME can be used in most PS1 emulators .PBP Playstation Boot Package - PS1 games that run on the PSP (and also PS Classic) File formats Located on the PS1 DiscAfter mounting a PS1 Disc ISO/BIN/CUE you can view the file system of the Disc and you will see files with a variety of extensions, some of these extensions are standard across games and are listed in the table below. Extension Description .STR Streaming Movie .BS MDEC Stream .XA Streaming CD-ROM Vocals .RSD 3D Model files .TMD 3D Model files (for PSYQ libraries) .PMD High speed Modelling data .TOD Animation Data .HMD Hierarchical 3D Model plus animation and other data .TIM 2D Image file .SDF Sprite Editor Project File .PXL Pixel Image Data .CLT Palette Data .ANM Animation informaton for 2D .TSQ Animation Time sequence for 2D .CEL Cell Data .BGD Background Map Data .SEQ Audio Sequence file .SEP Multi-Track Audio Sequence file .VAG Audio Wavefile .VAB Audio Source Data .DA CD-DA Data .FAT Memory Card File 3D Model Formats (RSD Formats)These formats tend to be only available in source code and relate to 3D models.Most of these are human readable ASCII files apart from TMD which is optimised for the game itself and DXF which is generated by the original 3D modeeling application (e.g 3D Studio).You can convert DXF to RSD formats using the tool DXF2RSD provided in the PSQ SDK. Format Description DXF Drawing Exchange Format, Standard 3D model format used in a variety of 3D software such as AutoCAD and 3D Studio RSD Format used in the 3D Graphics Tools while artists are editing PLY Polygon vertices information (coordinates) MAT Material (Texture) Information GRP Group of Polygon information MSH Mesh, information on how polygons are linked together PVT Pivot file used for rotation information COD Coordinate for Vertex data MOT Animation information OGP Vertex grouping information TMD Format used by the game itself, MD is Modelling Data (What does the T stand for?) ", "excerpt": "File Formats used to distribute PS1 Discs A Playstation One CD can either be directly put into your PC via the CD-ROM drive or mounting a .BIN/.ISO file. All of these are just ways to be able to see the contents of a PS1 Disc similar to a folder of...", "tags": ["ps1","reverseengineering","fileformats"], "image": "/public/images/ps1/Sony PS1 File Formats.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Playstation 1 Games with Debug Symbols", "url": "/ps1-debug-symbols", "content": "I have never seen a PS1 executable bigger than 2mb, normally if they require more code they split it into multiple executables. With memory being so precious it would be unlikely a developer would forget to strip the debug symbols from an executable. However it is possible to find symbols included on the disk in various formats, one of those formats is SYM:SYM Symbol Files.SYM Files are generated by the Official Sony PS1 PSYQ SDK for use in debugging, they contain all the symbols (function names etc) and can also contain other chunks such as source filenames and line numbers.You can get the information from a .SYM file using DUMPSYM.EXE from the PSQ SDK or you can use this open source tool:https://github.com/stohrendorf/symdump/.Also the integration of .sym files into the No$PSX emulator is documented in the following forum thread: http://www.psxdev.net/forum/viewtopic.php?f=76&t=1318Games with SYM Symbol fileThe table below lists the relevant entries. Game Name Symbol File Genre Youtube AirAssault - The Red Mercury Missions (Japan) PSX.SYM     Brunswick Circuit Pro Bowling THQB2.SYM Sport https://www.youtube.com/watch?v=2XRmszyyf8Q Buggy (Europe) (En,Fr,De,Es,It,Pt) SYMS/NEW.SYM Racing https://www.youtube.com/watch?v=PfBSXU0Sc7s Cardinal Syn (Europe) SYN.SYM Fighting https://www.youtube.com/watch?v=xxHyg5JEgSw Castrol Honda Superbike Racing BIKE.SYM Racing https://www.youtube.com/watch?v=1-v3kMlJx50 Crow, The - City of Angels (Europe) CROW.SYM Action https://www.youtube.com/watch?v=0vDrqQAK5Yk CyberTiger GOLF.SYM Sport https://www.youtube.com/watch?v=XxyXU8he-Iw Deka Yonku - Tough the Truck (Japan) MAIN.SYM     Destruction Derby (Japan) TEMP/DEMOLISH.SYM Racing https://www.youtube.com/watch?v=FFMzFthGHkc Diablo (Japan) DIABPSX.SYM Action   Disney’s 101 Dalmatians 2 /DATA/MAIN.SYM Platformer https://www.youtube.com/watch?v=SHr2BYzShtE Divide The Enemies Within /SYMBOL/GAME.SYM Action https://www.youtube.com/watch?v=H3JE8iuwIog Dora the Explorer - Barnyard Buddies /DATA/MAIN.SYM Childrens https://www.youtube.com/watch?v=UJ6vgxBdoMs Dragon Quest Characters - Torneko no Daibouken 2 - Fushigi no Dungeon (Japan) FPS.SYM     Driver 2 (Spanish Version Disc 1) /SPANISH.SYM Driving https://www.youtube.com/watch?v=hfEF_z0JfcQ Fear Effect (Germany) (Disc 1) FEARPAL.SYM Action https://www.youtube.com/watch?v=rQBnYPnJqYw Flintstones, The - Bedrock Bowling (Europe) FLINTR.SYM Platformer https://www.youtube.com/watch?v=EG3a8C4kQfs Grid Run (Europe) SYM/SLES0381.SYM Platformer https://www.youtube.com/watch?v=ccPzDlWz-mE Grid Runner (Japan) SYM_SLPS0659.SYM Platformer   Hardcore 4x4 (Europe) (En,Fr,De) MAIN.SYM Racing https://www.youtube.com/watch?v=vv99PiwQEWQ Hi-Octane (Europe) (En,Fr,De,Es) MAIN.SYM Racing https://www.youtube.com/watch?v=xOEozcuLm-U Idol Promotion - Suzuki Yumie (Japan) (Yumie Island) TEST/JANKEN/MAIN.SYM     Indy 500 (Japan) INDY500.SYM     International Moto X (Europe) (En,Fr,De,Es,It,Nl) PSX.SYM Racing https://www.youtube.com/watch?v=oCvHbkQLLWU Kidou Senshi Gundam - Gihren no Yabou - Zeon no Keifu - Kimitsu Eizou Disc Tokubetsu Hen (Japan) TAIKEN3/TAIKEN3.SYM     Kyuu Bakukku (Japan) CUBE.SYM     Jackie Chan Stuntmaster /GAME_REL.SYM Action https://www.youtube.com/watch?v=OxQ0Pr-NlGQ Legacy of Kain - Soul Reaver (Germany) DEBUG/NTSC/KAIN2.SYM Action https://www.youtube.com/watch?v=lz9HtrZc9Gk MDK (Japan) MAIN.SYM     Next Wave Herbst ‘98 (Germany) DTK/dtk_menu.sym dtk_stub.sym Unknown (Demo?) Unknown NHL Powerplay (Europe) SYM/front.sym game.sym psx.sym runfront.sym rungame.sym Sport https://www.youtube.com/watch?v=Zx2o5OoSCx0 Nuclear Strike (Europe) DATA/DELTA.SYM dmz.sym e3demo.sym Shooter https://www.youtube.com/watch?v=P33C7GjY3nU Ore no Shikabane wo Koete Yuke (Japan) ORECD_MAIN.SYM     PrePre Vol. 6 (Japan) STRIKE_DATA_CRIMEA.SYM     RC Revenge (Europe) (En,Fr,De,Es) release.sym Racing   Re-Loaded (Europe) (En,Fr,De) relpal.sym     Soccer ‘97 (Europe) olysocc.sym     Syndicate Wars (Germany) main.sym     Team Losi RC Racer (US version of Buggy) /SYMS/NEW.SYM Racing https://www.youtube.com/watch?v=tH2CYEj3uZI Tiger Woods PGA Tour 2000 (Europe) (En,Fr,De,Es,Sv) golfcd_a.sym Sport   Tomb Raider Chronicles (Unknown build) MAIN.SYM Action https://www.youtube.com/watch?v=KbV7dZ8xJfI True Pinball (Europe) pinball.sym Sport   Twisted Metal (Japan) PSX.SYM Action https://www.youtube.com/watch?v=NmcTF4JXnYs Twisted Metal Small Brawl (USA) tmsb.sym (in zip file MOV/ZDUMMY.bin) Racing https://www.youtube.com/watch?v=rJNHwyjKu6o Who Wants to Be a Millionaire 3rd Edition /MIL3.SYM Quiz https://www.youtube.com/watch?v=IwuwbxV4pGw Demos and Betas with SYM Symbol fileThe table below lists the relevant entries. Game Name Demo CD Symbol File Croc Demo SLED-00038 /CROC.SYM Biohazard 2 Biohazard 2 (Japan) (Beta 2) /MAIN.SYM Cardinal Syn Euro Demo 18 (Germany) SYN/SYN.SYM Colin McCrae Rally 2 Euro Demo 08-00 (Germany) CMR2/GAMEFLOW.SYM Felony 11-79 Essential PlayStation 7 (Europe) /FELONY/MAIN.SYM Granstream Denki Granstream Denki (Japan) (Demo) GS/P/MAIN.SYM O.D.T. Euro Demo 28 (France) /ODT/MOVIES.SYM ODT.SYM SCARS PlayStation Zone CD Vol. 8 (Germany) SCARSPAL.SYM TH Pro Skater Euro Demo 07-00 (Germany) PROSKATE/MAIN.SYM UEFA EURO 2000 Euro Demo 07-00 (Germany) EURODEMO/BECODE_Z.SYM E2000_Z.SYM FECODE_Z.SYM Sled Storm USA Demo Disc 24 DEBUG/MAIN.MAP Soul reaver Soul reaver (SLES-02024) /DEBUG/NTSC/KAIN2.SYM Wipeout XL Wipeout XL (USA) (Beta) NTSC.SYM DemoDemo Vol. 12 (Japan) DemoDemo Vol. 12 (Japan) MAIN.SYM MAP FilesLinker Map file FormatThe .MAP file created by a c/c++ linker such as LD follows the format:Start Stop Length Obj Group Section name80010000 800179C3 000079C4 80010000 text .rdata...Program entry point : 00000000Address Names alphabetically8008CEF4 CD_readyThese files contain all the information you need to get the full debug symbols back for a game! You just need to parse them and add them to your disassembler of choice (e.g Radare2 or IDA Pro)Games with Linker Map fileThe table below lists the relevant entries. Game Name Map File Brunswick Circuit Pro Bowling 2 THQB2R.MAP Castrol Honda Superbike Racing BIKE.MAP Diablo (Japan) /DIABPSX.MAP Disney’s 101 Dalmatians 2 /DATA/MAIN.MAP Dora the Explorer - Barnyard Buddies /DATA/MAIN.MAP Knockout Kings /DATA/MAIN.MAP Legacy of Kain - Soul Reaver (Germany) DEBUG/NTSC/KAIN2.MAP NCAA March Madness Located inside IGBIN.BIN SnoCross Championship Racing Located inside SNOW.IMG Tomb Raider Chronicles (Unknown build) MAIN.MAP True Pinball Contains PINBALL.MAP but doesn’t seem to contain function names Demos and Betas with Linker Map fileThe table below lists the relevant entries. Game Name Demo CD Symbol File Colin McCrae Rally 2 Euro Demo 08-00 (Germany) /CMR2/GAMEFLOW.MAP Soul reaver SLES-02024 /DEBUG/NTSC/KAIN2.MAP Syphon Filter (USA) (Demo) SCUS-94362 /SIPHON.MAP Syphon Filter (USA) (Demo)The Github user Wuteva has been investigating the Linker Map file contained in the USA version of the Syphon Filter Demo and has found some very interesting information 1.They have found that the MAP file doesn’t quite match the binary executable contained on the disc (the MainLoop function is at 0x800144a4 in Ghdira but is at 0x800144C0 in the map file). This is likely due to the version of the binary having an earlier date compared to the Linker Map file 1.Games with Partial Source Code Beatmania Best Hits has a near-final copy of Beatmania 5th Mix’s source code 2Other Interesting: Disney GoofysFunHouse contains string - “dbugpsx /h /epsx.cpe /m- psx.sym” Chill (Europe) seems to have lots of source code in it! incide CDFILLER, includes C files!! Might just be the names of the files tho… Digimon World contains quite a lot of what look like symbols in MOV_REL.BIN DivideThe EnemiesWithin contains GAME.SYM and looks like it uses C++! DoraTheExplorer has MAIN.SYM Frogger2 seems to contain Makefiles JackieChanStuntmaster contains GAME_REL.SYM!!! KnockoutKings contains MAIN.MAP with address name mapping NASCAR 2001 contains some references to source files in the executable SLUS_012.63 NBA Shoot Out seems to have some source code VIP Demo (SCES-00236) Seems to contain a makefileReferences PSX game with debug symbol: Syphon Filter (USA) (Demo) contains a .map file ↩ ↩2 https://assemblergames.com/threads/retail-playstation-1-games-with-debug-symbols.68587/#post-965072 ↩ ", "excerpt": "I have never seen a PS1 executable bigger than 2mb, normally if they require more code they split it into multiple executables. With memory being so precious it would be unlikely a developer would forget to strip the debug symbols from an executable. However it is possible to find symbols...", "tags": ["ps1","reverseengineering","symbols"], "image": "/public/images/ps1/Sony PS1 Games with Debug Symbols.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Official Sony PS1 Libraries", "url": "/ps1-libs", "content": "Note that the order of the externals defined in this list will not reflect the order in the final linked executable, as the order here is just the order that the PSYLIB.EXE tool exports in.LIBAPI - PS1 OS Kernel APIThe LIBAPI.LIB file is required in all PS1 executables as it controls the Playstation Kernel and interactions between the basic Playsation Operating System. Module Date Externals defined C57 23-07-99 InitHeap C58 23-07-99 _exit C65 23-07-99 LoadTest C66 23-07-99 Load C67 23-07-99 Exec C68 23-07-99 FlushCache C73 23-07-99 GPU_cw C81 23-07-99 LoadExec C82 23-07-99 GetSysSp C112 23-07-99 _bu_init C113 23-07-99 _96_init C114 23-07-99 _96_remove C157 23-07-99 GetConf C159 23-07-99 SetMem C160 23-07-99 _boot C161 23-07-99 SystemError C167 23-07-99 bufs_cb_0 C168 23-07-99 bufs_cb_1 C169 23-07-99 bufs_cb_2 C170 23-07-99 bufs_cb_3 C174 23-07-99 bufs_cb_4 A07 23-07-99 DeliverEvent A08 23-07-99 OpenEvent A09 23-07-99 CloseEvent A10 23-07-99 WaitEvent A11 23-07-99 TestEvent A12 23-07-99 EnableEvent A13 23-07-99 DisableEvent A14 23-07-99 OpenTh A15 23-07-99 CloseTh A16 23-07-99 ChangeTh A18 23-07-99 InitPAD2 A19 23-07-99 StartPAD2 A20 23-07-99 StopPAD2 A21 23-07-99 PAD_init2 A22 23-07-99 PAD_dr A23 23-07-99 ReturnFromException A24 23-07-99 ResetEntryInt A25 23-07-99 HookEntryInt A32 23-07-99 UnDeliverEvent A36 23-07-99 EnterCriticalSection A37 23-07-99 ExitCriticalSection A38 23-07-99 Exception A39 23-07-99 SetSp A40 23-07-99 SwEnterCriticalSection A41 23-07-99 SwExitCriticalSection A50 23-07-99 open A51 23-07-99 lseek A52 23-07-99 read A53 23-07-99 write A54 23-07-99 close A55 23-07-99 ioctl A64 23-07-99 cd A65 23-07-99 format A66 23-07-99 firstfile2 A67 23-07-99 nextfile A68 23-07-99 rename A69 23-07-99 erase A70 23-07-99 undelete A71 23-07-99 AddDrv A72 23-07-99 DelDrv A81 23-07-99 Krom2RawAdd A84 23-07-99 _get_errno A85 23-07-99 _get_error A91 23-07-99 ChangeClearPAD A94 23-07-99 GetGp A95 23-07-99 GetSp A96 23-07-99 GetCr A97 23-07-99 GetSr L02 23-07-99 SysEnqIntRP L03 23-07-99 SysDeqIntRP L10 23-07-99 ChangeClearRCnt COUNTER 23-07-99 SetRCnt GetRCnt StartRCnt StopRCnt ResetRCnt SC2B 23-07-99 SetConf PATCH 23-07-99 _patch_pad EnablePAD DisablePAD FIRST 23-07-99 firstfile PAD 23-07-99 SetInitPadFlag ReadInitPadFlag PAD_init InitPAD StartPAD *_apiPadPatch PADSTOP 23-07-99 StopPAD I_HEAP2 23-07-99 InitHeap2 *_AllocRestBlockTop *_TopAllocArea *_max_heap *_Candidate MALLOC2 23-07-99 malloc2 FREE2 23-07-99 free2 REALLOC2 23-07-99 realloc2 CALLOC2 23-07-99 calloc2 CHCLRPAD 23-07-99 _remove_ChgclrPAD I_HEAP3 23-07-99 _freep InitHeap3 MALLOC3 23-07-99 malloc3 FREE3 23-07-99 free3 *_r_bp *_r_p *_r_freep REALLOC3 23-07-99 realloc3 CALLOC3 23-07-99 calloc3 LIBC - Standard GCC C LibraryThe standard C library used for functions like printf that are compiled in almost every C-based program. Module Externals defined A56 exit A58 getc A59 putc A60 getchar A61 putchar A62 gets A63 puts C10 todigit C12 strtoul C13 strtol C14 abs C15 labs C16 atoi C17 atol C18 atob C19 setjmp C20 longjmp C21 strcat C22 strncat C23 strcmp C24 strncmp C25 strcpy C26 strncpy C27 strlen C28 index C29 rindex C30 strchr C31 strrchr C32 strpbrk C33 strspn C34 strcspn C36 strstr C37 toupper C38 tolower C39 bcopy C40 bzero C42 memcpy C43 memset C46 memchr C47 rand C48 srand C51 malloc C52 free C53 lsearch C55 calloc C56 realloc C63 printf CTYPE0 ctype SPRINTF sprintf ITOA itoa MEMMOVE memmove BCMP bcmp MEMCMP memcmp STRTOK strtok QSORT qsort BSEARCH bsearch LIBC2 - Standard C libraryA faster (cacheable) implementation of the C standard libraries but required more memory than standard LIBC. Module Date Externals defined BCMP 23-07-99 bcmp BCOPY 23-07-99 bcopy BZERO 23-07-99 bzero GETC 23-07-99 getc GETCHAR 23-07-99 getchar GETS 23-07-99 gets MEMCHR 23-07-99 memchr MEMCMP 23-07-99 memcmp MEMCPY 23-07-99 memcpy MEMMOVE 23-07-99 memmove MEMSET 23-07-99 memset PUTC 23-07-99 putc PUTCHAR 23-07-99 _putchar _putchar_flash putchar QSORT 23-07-99 qsort RAND 23-07-99 rand srand STRCAT 23-07-99 strcat STRCHR 23-07-99 strchr STRCMP 23-07-99 strcmp STRCPY 23-07-99 strcpy STRCSPN 23-07-99 strcspn STRINGS 23-07-99 index rindex STRLEN 23-07-99 strlen STRNCAT 23-07-99 strncat STRNCMP 23-07-99 strncmp STRNCPY 23-07-99 strncpy STRPBRK 23-07-99 strpbrk STRRCHR 23-07-99 strrchr STRSPN 23-07-99 strspn STRSTR 23-07-99 strstr STRTOK 23-07-99 strtok STRTOUL 23-07-99 strtoul TODIGIT 23-07-99 todigit PRINTF 23-07-99 printf PRNT 23-07-99 prnt SPRINTF 23-07-99 sprintf ITOA 23-07-99 itoa PUTS 23-07-99 puts BSEARCH 23-07-99 bsearch LSEARCH 23-07-99 lsearch SETJMP 23-07-99 setjmp longjmp EXIT 23-07-99 exit MALLOC 23-07-99 malloc free calloc realloc ABS_0 23-07-99 abs ABS_1 23-07-99 labs ATOI_0 23-07-99 atoi ATOI_1 23-07-99 atol CTYPE_0 23-07-99 ctype CTYPE_1 23-07-99 toupper CTYPE_2 23-07-99 tolower STRTOL_0 23-07-99 strtol STRTOL_1 23-07-99 atob LIBCARDLIBCARD.LIB is the library for communicating with the memory cards. Module Date Externals defined C112 23-07-99 _bu_init C171 23-07-99 _card_info C172 23-07-99 _card_load C173 23-07-99 _card_auto A74 23-07-99 InitCARD2 A75 23-07-99 StartCARD2 A76 23-07-99 StopCARD2 A78 23-07-99 _card_write A79 23-07-99 _card_read A80 23-07-99 _new_card A88 23-07-99 _card_chan A92 23-07-99 _card_status A93 23-07-99 _card_wait CARD 23-07-99 _card_clear PATCH 23-07-99 _patch_card _patch_card2 _copy_memcard_patch _patch_card_info INIT 23-07-99 InitCARD StartCARD StopCARD END 23-07-99 _ExitCard FORMAT 23-07-99 _card_format LIBCD (Basic CD-ROM & Streaming)LIBCD.LIB is required for any games that need to access data from the CD drive.From the official documentation:The CD/Streaming Library (libcd) consists of two separate libraries:• The CD-ROM Library, which provides functions for controlling the PlayStation built-in CD-ROM drive. It provides CD sound control and other services.• The Streaming Library, which is a group of functions for continuous reading of realtime data such as movies, sounds or vertex data stored on high-capacity media. Module Date Externals defined CDROM 23-07-99 StSetRing *StRingAddr *StRingSize *StRingBase *StRgb24 *StEmu_Addr *StEmu_Idx *StRingIdx1 *StRingIdx2 *StRingIdx3 *StSTART_FLAG *StStartFrame *StEndFrame *StFinalSector *Stframe_no *Stsector_offset *StCdIntrFlag *StCHANNEL *CChannel TOC 23-07-99 CdGetToc CdGetToc2 EVENT 23-07-99 CD_cbread CD_read_dma_mode CdInit SYS 23-07-99 CdPosToInt ISO9660 23-07-99 CdSearchFile CDREAD2 23-07-99 CdRead2 CDPLAY 23-07-99 CdPlay C_002 23-07-99 StClearRing C_003 23-07-99 StUnSetRing C_004 23-07-99 data_ready_callback StGetBackloc C_005 23-07-99 StSetStream *StFunc1 *StFunc2 C_006 23-07-99 StSetEmulate C_007 23-07-99 StFreeRing C_008 23-07-99 init_ring_status C_009 23-07-99 StGetNext C_010 23-07-99 StSetMask C_011 23-07-99 debug_cause StCdInterrupt C_012 23-07-99 StSetChannel C_013 23-07-99 StGetNextS C_014 23-07-99 StNextStatus BIOS_1 23-07-99 CD_cbsync CD_cbready CD_debug CD_status CD_status1 CD_nopen CD_pos CD_mode CD_com DS_active CD_comstr CD_intstr CD_sync CD_flush CD_ready CD_cw CD_vol CD_initvol CD_initintr CD_init CD_datasync CD_set_test_parmnum *StMode BIOS_2 23-07-99 CD_getsector BIOS_3 23-07-99 CD_getsector2 C_015 23-07-99 StRingStatus S_002 23-07-99 CdIntToPos S_003 23-07-99 CdStatus S_004 23-07-99 CdMode S_005 23-07-99 CdLastCom S_006 23-07-99 CdLastPos S_007 23-07-99 CdReset S_008 23-07-99 CdFlush S_009 23-07-99 CdSetDebug S_010 23-07-99 CdComstr S_011 23-07-99 CdIntstr S_012 23-07-99 CdSync S_013 23-07-99 CdReady S_014 23-07-99 CdSyncCallback S_015 23-07-99 CdReadyCallback S_016 23-07-99 CdControl CdControlF CdControlB S_020 23-07-99 CdMix S_021 23-07-99 CdGetSector S_022 23-07-99 CdGetSector2 S_023 23-07-99 CdDataCallback S_024 23-07-99 CdDataSync CDR_1 23-07-99 CdReadBreak CdRead CdReadSync CDR_2 23-07-99 CdReadCallback CDR_3 23-07-99 CdReadMode TYPE_1 23-07-99 CdDiskReady TYPE_2 23-07-99 CdGetDiskType CRE_1 23-07-99 CdReadFile CRE_2 23-07-99 CdReadExec LIBCOMB (Link Cable Library)The Link Cable Library (libcomb.lib) provides functions for connecting PlayStatios’s together via a “link” cable. Module Date Externals defined COMB 23-07-99 AddCOMB _comb_control COMB_2 23-07-99 DelCOMB COMB_3 23-07-99 ChangeClearSIO LIBDS (Extended CD-ROM)The extended CD-ROM library is basically the same as libcd but it implements a command queue to allow for speed differences between cpu and cdrom. You can’t use both libds and libcd at the same time! Module Date Externals defined DSSYS_1 23-07-99 DS_init DS_reset_members DS_close DS_cw DS_vsync_callback DS_sync_callback DS_ready_callback DS_start_callback DS_system_status DS_lastcom DS_lastmode DS_lastpos DS_lastseek DS_lastread DS_status DS_shell_open DS_cw_system parcpy rescpy DS_stop DS_restart DS_system_active DSSYS_2 23-07-99 DS_CQ_flush DsInit DsReset DsCommand DsPacket _DsPacket2 DsSync DsReady DsQueueLen DSSYS_3 23-07-99 DsMix DSSYS_4 23-07-99 DsControlF DSSYS_5 23-07-99 DS_comstr DsComstr DSTOC 23-07-99 DsGetToc DSREAD 23-07-99 DsRead DsReadSync DsReadCallback DsReadBreak DsReadMode DSREAD2 23-07-99 DsRead2 DSREADE 23-07-99 DsReadFile DSFILE 23-07-99 DsSearchFile DSPLAY 23-07-99 DsPlay DSREADY 23-07-99 DsStartReadySystem DsEndReadySystem DsReadySystemMode ER_active ER_clear DSTYPE 23-07-99 DsGetDiskType *GD_retry *GD_disk_kind DSCB 23-07-99 *GlobalCallback D1_001 23-07-99 DS_sync D1_002 23-07-99 DS_ready D2_001 23-07-99 DsClose D2_002 23-07-99 DsStatus D2_003 23-07-99 DsShellOpen D2_004 23-07-99 DsLastCom D2_005 23-07-99 DsFlush D2_006 23-07-99 DsSystemStatus D3_002 23-07-99 DsGetSector D3_003 23-07-99 DsGetSector2 D3_004 23-07-99 DsDataSync D3_005 23-07-99 DsIntToPos D3_006 23-07-99 DsPosToInt D3_007 23-07-99 DsSetDebug D3_008 23-07-99 DsLastPos D4_002 23-07-99 DsControl D4_003 23-07-99 DsControlB D5_001 23-07-99 DS_intstr DsIntstr DRE_2 23-07-99 DsReadExec DSCB_1 23-07-99 DsSyncCallback DSCB_2 23-07-99 DsReadyCallback DSCB_3 23-07-99 DsStartCallback DSCB_4 23-07-99 DsDataCallback LIBETC (Callbacks management Library)The ETC library (libetc.lib) is mainly used for callbacks and is needed for a variety of other libraries such as graphics and sound as well as controllers. It main function is to control callbacks.From the official documentation:Many functions such as graphics drawing, transferring data to the sound buffer, and loading data from the CD-ROM, may execute in parallel (asynchronously) in the background. These functions are called non- blocking functions, because they don’t block the CPU from performing other tasks.You can define callback functions that execute when the non-blocking function actually terminates. What actually happens is that when the non-blocking function completes, it generates an interrupt and the program jumps to the address registered as the callback. When the callback returns, the program returns to the point where the callback began, and normal processing resumes.A dedicated local stack is used for a callback function so that control can return to the original state after the callback returns. All interrupts are prohibited within callback functions. (Areas in which interrupts are prohibited are called critical sections.) Module Date Externals defined PAD 23-07-99 PadInit *PadIdentifier PadRead PADSTOP 23-07-99 PadStop VSYNC 23-07-99 Hcount VSync INTR 23-07-99 ResetCallback InterruptCallback DMACallback VSyncCallback VSyncCallbacks StopCallback RestartCallback CheckCallback GetIntrMask SetIntrMask INTR_VB 23-07-99 Vcount startIntrVSync INTR_DMA 23-07-99 startIntrDMA VMODE 23-07-99 SetVideoMode GetVideoMode HWCONFIG 23-07-99 get_hwconfig LIBGPU (Basic Graphics Library)LibGPU is a library for utilizing the Graphics Processing Unit (GPU) and frame buffer, it works using Primitives similar to OpenGL, triangles, sprites etc.The frame buffer is a 1mb memory chip that stores all the values of the pixels to display to the TV screen. Module Date Externals defined FONT 23-07-99 Font SetDumpFnt FntPrint FntLoad FntOpen FntFlush FONTTEX 23-07-99   KPRINTF 23-07-99 kanjiclut *txyuv KanjiFntOpen *KanjiFont KanjiFntClose KanjiFntFlush KanjiFntPrint OTAG 23-07-99 DrawOTagIO DumpOTag CheckPrim SYS 23-07-99 GPU_printf GEnv ResetGraph SetGraphDebug SetGraphQueue GetGraphDebug DrawSyncCallback SetDispMask DrawSync ClearImage ClearImage2 LoadImage StoreImage MoveImage ClearOTag ClearOTagR DrawPrim DrawOTag PutDrawEnv DrawOTagEnv GetDrawEnv PutDispEnv GetDispEnv GetODE SetDrawArea SetDrawOffset SetDrawEnv _qin _qout *_que LoadImage2 _GPU_ResetCallback StoreImage2 MoveImage2 DrawOTag2 BREAK 23-07-99 BreakDraw IsIdleGPU ContinueDraw PARAM 23-07-99 GetDrawEnv2 GetDrawMode GetTexWindow GetDrawArea GetDrawOffset E00 23-07-99 LoadTPage E01 23-07-99 LoadClut E02 23-07-99 LoadClut2 E03 23-07-99 SetDefDrawEnv E04 23-07-99 SetDefDispEnv P00 23-07-99 GetTPage P01 23-07-99 GetClut P02 23-07-99 DumpTPage P03 23-07-99 DumpClut P04 23-07-99 NextPrim P05 23-07-99 IsEndPrim P06 23-07-99 AddPrim P07 23-07-99 AddPrims P08 23-07-99 CatPrim P09 23-07-99 TermPrim P10 23-07-99 SetSemiTrans P11 23-07-99 SetShadeTex P12 23-07-99 SetPolyF3 P13 23-07-99 SetPolyFT3 P14 23-07-99 SetPolyG3 P15 23-07-99 SetPolyGT3 P16 23-07-99 SetPolyF4 P17 23-07-99 SetPolyFT4 P18 23-07-99 SetPolyG4 P19 23-07-99 SetPolyGT4 P20 23-07-99 SetSprt8 P21 23-07-99 SetSprt16 P22 23-07-99 SetSprt P23 23-07-99 SetTile1 P24 23-07-99 SetTile8 P25 23-07-99 SetTile16 P26 23-07-99 SetTile P27 23-07-99 SetLineF2 P28 23-07-99 SetLineG2 P29 23-07-99 SetLineF3 P30 23-07-99 SetLineG3 P31 23-07-99 SetLineF4 P32 23-07-99 SetLineG4 P33 23-07-99 SetDrawTPage P34 23-07-99 SetDrawMove P35 23-07-99 SetDrawLoad P36 23-07-99 MargePrim P37 23-07-99 DumpDrawEnv DumpDispEnv P38 23-07-99 SetTexWindow P39 23-07-99 SetPriority P40 23-07-99 SetDrawStp P41 23-07-99 SetDrawMode K00 23-07-99 GetTimSize K01 23-07-99 Krom2Tim T00 23-07-99 OpenTIM ReadTIM T01 23-07-99 OpenTMD ReadTMD KT00 23-07-99 Krom2RawAdd2 KT01 23-07-99 kanjitrans KT02 23-07-99 hankanjitrans LIBGS (Extended Graphics Library)The extended graphics library LIBGS.LIB builds on top of LIBGPU and LIBGTE and provides functions to display TIM images and TMD model files.From the official docs:The extended graphics library (libgs) integrates the 2D and 3D graphics systems used in libgpu and libgte. It is designed to work well with the standard graphics file formats that can be created by PlayStation authoring tools:• The TIM format stores image resolution, color numbers and color look-up table information.• The TMD format stores multiple objects, scale information and texture address information.• HMD is a new format that was added in version 4.0 of the libraries. See Chapter 18, “HMD Library”, for more information about this format.In contrast with the libgpu and libgte libraries which process polygon-level data, libgs processes data by object units (groups of polygons), allowing 3D programs to be prototyped easily. By adding attributes to objects, it’s easy to create special effects.Using libgs involves extra overhead compared to using libgpu and libgte. However, libgs is an open architecture. Therefore, once you are ready to produce your game, you can optimize it by adding user- defined functions (via a jump table) that use libgpu and libgte services. Module Date Externals defined 2D_BG0 23-07-99 GsSortBg 2D_BG1 23-07-99 GsSortFastBg 2D_BG21 23-07-99 GsSortFixBg16 2D_BG22 23-07-99 GsInitFixBg16 2D_BG31 23-07-99 GsSortFixBg32 2D_BG32 23-07-99 GsInitFixBg32 2D_COM0 23-07-99 _mk_spr_packet _mk_xpndsp _mk_normsp 2D_COM1 23-07-99 _make_packet 2D_LIN0 23-07-99 GsSortLine 2D_LIN1 23-07-99 GsSortGLine 2D_BOX0 23-07-99 GsSortBoxFill 2D_PRIM 23-07-99 GsSortPoly 2D_SP0 23-07-99 GsSortSprite 2D_SP1 23-07-99 GsSortFastSprite 2D_SP2 23-07-99 GsSortFlipSprite 2D_SP41 23-07-99 GsSortFastSprite2 2D_SP42 23-07-99 GsInitFastSprite2 2D_SP43 23-07-99 GsSortFastSpriteArray 2D_SP44 23-07-99 GsInitFastSpriteArray 2D_SP45 23-07-99 GsSetFastSpriteArray 2D_SP0A 23-07-99 GsSortSpriteA 2D_SP1A 23-07-99 GsSortFastSpriteA 2D_SP0B 23-07-99 GsSortSpriteB 2D_SP1B 23-07-99 GsSortFastSpriteB GS_001 23-07-99 GsInitGraph *PSDIDX *GsDRAWENV *GsDISPENV *PSDGPU GsInitGraph2 *PSDBASEX *PSDBASEY *POSITION *CLIP2 *PSDCNT GsSortClear *PSDOFSX *PSDOFSY *GsORGOFSX *GsORGOFSY GS_0021 23-07-99 GsGetActiveBuff GS_0022 23-07-99 GsSetDrawBuffOffset GS_003 23-07-99 GsSetDrawBuffClip GS_004 23-07-99 GsSetOffset GS_005 23-07-99 GsSetClip GS_006 23-07-99 GsSetClip2D GS_007 23-07-99 GsInitVcount GS_008 23-07-99 GsGetVcount GS_009 23-07-99 GsClearVcount GS_010 23-07-99 GsSwapDispBuff GS_011 23-07-99 GsClearDispArea GS_012 23-07-99 GsSetClip2 GS_013 23-07-99 GsSetOrign MATRIX1 23-07-99 *DSTACK MATRIX2 23-07-99 GsInitCoordinate2 MATRIX3 23-07-99 GsInitCoord2param MATRIX4 23-07-99 GsSetLsMatrix MATRIX5 23-07-99 GsSetLightMatrix MATRIX6 23-07-99 GsSetLightMatrix2 MATRIX7 23-07-99 GsMulCoord0 MATRIX8 23-07-99 GsMulCoord2 MATRIX9 23-07-99 GsMulCoord3 MATRIX10 23-07-99 print_matrix MATRIX11 23-07-99 print_vector GS_101 23-07-99 GsSetNearClip GS_102 23-07-99 GsSetFarClip GS_103 23-07-99 GsDefDispBuff GS_104 23-07-99 GsInit3D *HWD0 *VWD0 *GsCLIP3near *GsLIGHT_MODE *GsCLIP3far GS_105 23-07-99 GsMapModelingData GS_106 23-07-99 GsSetProjection GS_107 23-07-99 GsSetFlatLight *GsLIGHTWSMATRIX *_LC GS_108 23-07-99 GsSetLightMode GS_109 23-07-99 GsSetFogParam GS_110 23-07-99 GsSetAmbient GS_111 23-07-99 GsDrawOt GS_112 23-07-99 GsDrawOtIO GS_113 23-07-99 GsClearOt GS_114 23-07-99 GsSortOt GS_1151 23-07-99 gte_apply_matrixl GS_1152 23-07-99 gte_apply_matrixll GS_116 23-07-99 gte_copy_matrix GS_117 23-07-99 gte_rotate_x_matrix GS_118 23-07-99 gte_rotate_y_matrix GS_119 23-07-99 gte_rotate_z_matrix GS_120 23-07-99 gte_scale_matrix GS_121 23-07-99 gte_init GS_122 23-07-99 GsGetTimInfo GS_123 23-07-99 Gssub_make_matrix *GsWSMATRIX *GsWSMATRIX_ORG GS_124 23-07-99 GsSetWorkBase GS_125 23-07-99 GsGetWorkBase GS_126 23-07-99 GsCutOt GS_127 23-07-99 GsDefDispBuff2 GS_128 23-07-99 *GsIDMATRIX *GsIDMATRIX2 GS_131 23-07-99 GsSetRefView2 GS_132 23-07-99 GsSetView2 GS_133 23-07-99 GsGetLw GS_134 23-07-99 GsGetLs GS_135 23-07-99 GsGetLws GS_136 23-07-99 GsScaleScreen GS_137 23-07-99 GsSetRefView2L PRESET_1 23-07-99 GsLinkObject5 PRESET_2 23-07-99 GsPresetObject PRESET2 23-07-99 GsSortObject5 PRESET3 23-07-99 GsSortObject5J *GsFCALL5 PRESET4 23-07-99 dmyGsPrstF3NL dmyGsPrstF3LFG dmyGsPrstF3L dmyGsPrstNF3 dmyGsTMDdivF3NL dmyGsTMDdivF3LFG dmyGsTMDdivF3L dmyGsTMDdivNF3 dmyGsPrstG3NL dmyGsPrstG3LFG dmyGsPrstG3L dmyGsPrstNG3 dmyGsTMDdivG3NL dmyGsTMDdivG3LFG dmyGsTMDdivG3L dmyGsTMDdivNG3 dmyGsPrstTF3NL dmyGsPrstTF3LFG dmyGsPrstTF3L dmyGsPrstTNF3 dmyGsTMDdivTF3NL dmyGsTMDdivTF3LFG dmyGsTMDdivTF3L dmyGsTMDdivTNF3 dmyGsPrstTG3NL dmyGsPrstTG3LFG dmyGsPrstTG3L dmyGsPrstTNG3 dmyGsTMDdivTG3NL dmyGsTMDdivTG3LFG dmyGsTMDdivTG3L dmyGsTMDdivTNG3 dmyGsPrstF4NL dmyGsPrstF4LFG dmyGsPrstF4L dmyGsPrstNF4 dmyGsTMDdivF4NL dmyGsTMDdivF4LFG dmyGsTMDdivF4L dmyGsTMDdivNF4 dmyGsPrstG4NL dmyGsPrstG4LFG dmyGsPrstG4L dmyGsPrstNG4 dmyGsTMDdivG4NL dmyGsTMDdivG4LFG dmyGsTMDdivG4L dmyGsTMDdivNG4 dmyGsPrstTF4NL dmyGsPrstTF4LFG dmyGsPrstTF4L dmyGsPrstTNF4 dmyGsTMDdivTF4NL dmyGsTMDdivTF4LFG dmyGsTMDdivTF4L dmyGsTMDdivTNF4 dmyGsPrstTG4NL dmyGsPrstTG4LFG dmyGsPrstTG4L dmyGsPrstTNG4 dmyGsTMDdivTG4NL dmyGsTMDdivTG4LFG dmyGsTMDdivTG4L dmyGsTMDdivTNG4 dmyGsTMDfastF3NL dmyGsTMDfastF3LFG dmyGsTMDfastF3L dmyGsTMDfastNF3 dmyGsTMDfastG3NL dmyGsTMDfastG3LFG dmyGsTMDfastG3L dmyGsTMDfastNG3 dmyGsTMDfastTF3NL dmyGsTMDfastTF3LFG dmyGsTMDfastTF3L dmyGsTMDfastTNF3 dmyGsTMDfastTG3NL dmyGsTMDfastTG3LFG dmyGsTMDfastTG3L dmyGsTMDfastTNG3 dmyGsTMDfastF4NL dmyGsTMDfastF4LFG dmyGsTMDfastF4L dmyGsTMDfastNF4 dmyGsTMDfastG4NL dmyGsTMDfastG4LFG dmyGsTMDfastG4L dmyGsTMDfastNG4 dmyGsTMDfastTF4NL dmyGsTMDfastTF4LFG dmyGsTMDfastTF4L dmyGsTMDfastTNF4 dmyGsTMDfastTG4NL dmyGsTMDfastTG4LFG dmyGsTMDfastTG4L dmyGsTMDfastTNG4 dmyGsTMDfastF3GL dmyGsTMDfastF3GLFG dmyGsTMDfastF3GNL dmyGsTMDfastG3GL dmyGsTMDfastG3GLFG dmyGsTMDfastG3GNL dmyGsPrstF3GL dmyGsPrstF3GLFG dmyGsPrstF3GNL dmyGsPrstG3GL dmyGsPrstG3GLFG dmyGsPrstG3GNL GLOBAL 23-07-99 GsADIVZ GsADIVW GsADIVH *GsOUT_PACKET_P *GsMATE_C *GsLMODE *GsLIGNR *GsLIOFF *GsZOVER *GsBACKC *GsNDIV *GsTRATE *GsTON *GsDISPON PMD1 23-07-99 GsLinkObject3 PMD2 23-07-99 GsSortObject3 OBJT 23-07-99 GsLinkObject4 OBJT2 23-07-99 GsSortObject4 OBJT3 23-07-99 GsSortObject4J *GsFCALL4 DATG4_00 23-07-99 GsA4divTG4L DATG4_01 23-07-99 GsA4divTG4LFG DATG4_02 23-07-99 GsA4divTG4NL DATG4_03 23-07-99 GsA4divTNG4 DATG4M00 23-07-99 GsA4divTG4LM DATG4M01 23-07-99 GsA4divTG4LFGM DATG4M02 23-07-99 GsA4divTG4NLM DATG4M03 23-07-99 GsA4divTNG4M DAFT4_00 23-07-99 GsA4divTF4L DAFT4_01 23-07-99 GsA4divTF4LFG DAFT4_02 23-07-99 GsA4divTF4NL DAFT4_03 23-07-99 GsA4divTNF4 DAFT4M00 23-07-99 GsA4divTF4LM DAFT4M01 23-07-99 GsA4divTF4LFGM DAFT4M02 23-07-99 GsA4divTF4NLM DAFT4M03 23-07-99 GsA4divTNF4M DAG4_00 23-07-99 GsA4divG4L DAG4_01 23-07-99 GsA4divG4LFG DAG4_02 23-07-99 GsA4divG4NL DAG4_03 23-07-99 GsA4divNG4 DAF4_00 23-07-99 GsA4divF4L DAF4_01 23-07-99 GsA4divF4LFG DAF4_02 23-07-99 GsA4divF4NL DAF4_03 23-07-99 GsA4divNF4 DATG3_00 23-07-99 GsA4divTG3L DATG3_01 23-07-99 GsA4divTG3LFG DATG3_02 27-07-99 GsA4divTG3NL DATG3_03 23-07-99 GsA4divTNG3 DAG3_00 23-07-99 GsA4divG3L DAG3_01 23-07-99 GsA4divG3LFG DAG3_02 23-07-99 GsA4divG3NL DAG3_03 23-07-99 GsA4divNG3 DAG3GF00 23-07-99 GsTMDfastG3GL DAG3GF01 23-07-99 GsTMDfastG3GLFG DAG3GF02 23-07-99 GsTMDfastG3GNL DAG3GP00 23-07-99 GsPrstG3GL DAG3GP01 23-07-99 GsPrstG3GLFG DAG3GP02 23-07-99 GsPrstG3GNL DAFT3_00 23-07-99 GsA4divTF3L DAFT3_01 23-07-99 GsA4divTF3LFG DAFT3_02 23-07-99 GsA4divTF3NL DAFT3_03 27-07-99 GsA4divTNF3 DAF3_00 23-07-99 GsA4divF3L DAF3_01 23-07-99 GsA4divF3LFG DAF3_02 23-07-99 GsA4divF3NL DAF3_03 23-07-99 GsA4divNF3 DAF3GF00 23-07-99 GsTMDfastF3GL DAF3GF01 23-07-99 GsTMDfastF3GLFG DAF3GF02 23-07-99 GsTMDfastF3GNL DAF3GP00 23-07-99 GsPrstF3GL DAF3GP01 23-07-99 GsPrstF3GLFG DAF3GP02 23-07-99 GsPrstF3GNL DAG3MF00 23-07-99 GsTMDfastG3M DAG3MF01 23-07-99 GsTMDfastG3MFG DATG3MF0 23-07-99 GsTMDfastTG3M DATG3MF1 23-07-99 GsTMDfastTG3MFG DAG4MF00 23-07-99 GsTMDfastG4M DAG4MF01 23-07-99 GsTMDfastG4MFG DATG4MF0 23-07-99 GsTMDfastTG4M DATG4MF1 23-07-99 GsTMDfastTG4MFG DAF3MF00 23-07-99 GsTMDfastF3M DAF3MF01 23-07-99 GsTMDfastF3MFG DAFT3MF0 23-07-99 GsTMDfastTF3M DAFT3MF1 23-07-99 GsTMDfastTF3MFG DAF4MF00 23-07-99 GsTMDfastF4M DAF4MF01 23-07-99 GsTMDfastF4MFG DAFT4MF0 23-07-99 GsTMDfastTF4M DAFT4MF1 23-07-99 GsTMDfastTF4MFG DAF4GF00 23-07-99 GsTMDfastF4GL DAF4GF01 23-07-99 GsTMDfastF4GLFG DAF4GF02 23-07-99 GsTMDfastF4GNL DAG4GF00 23-07-99 GsTMDfastG4GL DAG4GF01 23-07-99 GsTMDfastG4GLFG DAG4GF02 23-07-99 GsTMDfastG4GNL LIBGTE (Geometry Transformation Engine)LIBGTE is a library for 2D/3D math calculations that use the GTW hardware chip on the playstation to calculate coordinates and colour information before it is sent to the GPU. Module Date Externals defined SINCOS 23-07-99 rsin_tbl GEO_00 23-07-99 rsin sin_1 GEO_01 23-07-99 rcos FOG_00 23-07-99 SetFogFar FOG_01 23-07-99 SetFogNear FOG_02 23-07-99 SetFogNearFar COR_00 23-07-99 RotMatrixC COR_01 23-07-99 H_cor_tbl csincos COR_02 23-07-99 ccos COR_03 23-07-99 csin_1 csin COR_04 23-07-99 H_ln_tbl cln_1 cln COR_05 23-07-99 csqrt_1 csqrt COR_06 23-07-99 K_cor_tbl catan SQRTBL 23-07-99 SQRT MSC00 23-07-99 InitGeom MSC01 23-07-99 SquareRoot0 MSC02 23-07-99 InvSquareRoot VectorNormal VectorNormalS VectorNormalSS MatrixNormal MSC03 23-07-99 InterpolShort MSC04 23-07-99 InterpolByte MSC05 23-07-99 gteMIMefunc MSC07 23-07-99 p2otz MSC08 23-07-99 otz2p MSC09 23-07-99 SquareRoot12 MTX_000 23-07-99 MulMatrix0 MTX_001 23-07-99 MulRotMatrix MTX_002 23-07-99 MulRotMatrix0 MTX_003 23-07-99 CompMatrix MTX_004 23-07-99 ApplyMatrixLV MTX_005 23-07-99 ApplyRotMatrix MTX_006 23-07-99 PushMatrix PopMatrix MTX_007 23-07-99 ReadLightMatrix MTX_008 23-07-99 ReadColorMatrix MTX_009 23-07-99 ReadRotMatrix MTX_00A 23-07-99 ScaleMatrixL MTX_00B 23-07-99 SetMulMatrix MTX_00C 23-07-99 CompMatrixLV MTX_01 23-07-99 ApplyRotMatrixLV MTX_02 23-07-99 SetMulRotMatrix MTX_03 23-07-99 MulMatrix MTX_04 23-07-99 MulMatrix2 MTX_05 23-07-99 ApplyMatrix MTX_06 23-07-99 ApplyMatrixSV MTX_07 23-07-99 TransMatrix MTX_08 23-07-99 ScaleMatrix MTX_09 23-07-99 SetRotMatrix MTX_10 23-07-99 SetLightMatrix MTX_11 23-07-99 SetColorMatrix MTX_12 23-07-99 SetTransMatrix REG00 23-07-99 SetRGBcd REG04 23-07-99 ReadSZfifo3 REG05 23-07-99 ReadSZfifo4 REG06 23-07-99 ReadSXSYfifo REG07 23-07-99 ReadRGBfifo REG08 23-07-99 ReadGeomOffset REG09 23-07-99 ReadGeomScreen REG10 23-07-99 SetBackColor REG11 23-07-99 SetFarColor REG12 23-07-99 SetGeomOffset REG13 23-07-99 SetGeomScreen SMP_02 23-07-99 RotTransPers SMP_03 23-07-99 RotTransPers3 SMP_04 23-07-99 RotTrans SMP_05 23-07-99 NormalClip SMP_06 23-07-99 NormalClipS CMB_00 23-07-99 RotTransPers4 CMB_01 23-07-99 RotAverage3 CMB_02 23-07-99 RotAverage4 CMB_03 23-07-99 RotNclip CMB_04 23-07-99 RotNclip3 CMB_05 23-07-99 RotNclip4 CMB_06 23-07-99 RotAverageNclip3 CMB_07 23-07-99 RotAverageNclip4 CMB_08 23-07-99 RotAverageNclipColorDpq3 CMB_09 23-07-99 RotAverageNclipColorCol3 CMB_10 23-07-99 ColorMatDpq CMB_11 23-07-99 ColorMatCol CMB_12 23-07-99 RotColorDpq CMB_13 23-07-99 RotColorDpq3 CMB_14 23-07-99 RotColorMatDpq CMB_15 23-07-99 RotAverageNclip3_1 CMB_16 23-07-99 RotTransPersN CMB_17 23-07-99 RotTransPers3N CMB_18 23-07-99 RotAverageNclipColorDpq3_1 HGT 23-07-99 RotMeshH CSTBL 23-07-99 rcossin_tbl CSTBLOLD 23-07-99 rcossin_tbl_0 FGO_00 23-07-99 TransposeMatrix FGO_01 23-07-99 RotMatrix FGO_02 23-07-99 RotMatrixYXZ FGO_03 23-07-99 RotMatrixZYX FGO_04 23-07-99 RotMatrixX FGO_05 23-07-99 RotMatrixY FGO_06 23-07-99 RotMatrixZ FGO_07 23-07-99 rcossin FGO_08 23-07-99 RotMatrixZXY FGO_09 23-07-99 RotMatrixXZY FGO_10 23-07-99 RotMatrixYZX RMAT_00 23-07-99 RotMatrixZYX_gte RMAT_01 23-07-99 RotMatrix_gte RMAT_02 23-07-99 RotMatrixYXZ_gte FT4M_00 23-07-99 GsTMDfastTNF4M FT4M_01 23-07-99 GsTMDfastTF4NLM FT4M_02 23-07-99 GsTMDfastTF4LM FT4M_03 23-07-99 GsTMDfastTF4LFGM GT4M_00 23-07-99 GsTMDfastTNG4M GT4M_01 23-07-99 GsTMDfastTG4NLM GT4M_02 23-07-99 GsTMDfastTG4LM GT4M_03 23-07-99 GsTMDfastTG4LFGM SMD_00 23-07-99 RotSMD_F3 SMD_01 23-07-99 RotSMD_G3 SMD_02 23-07-99 RotSMD_FT3 SMD_03 23-07-99 RotSMD_GT3 SMD_04 23-07-99 RotSMD_F4 SMD_05 23-07-99 RotSMD_G4 SMD_06 23-07-99 RotSMD_FT4 SMD_07 23-07-99 RotSMD_GT4 SMD_08 23-07-99 RotSMD_SV_F3 SMD_09 23-07-99 RotSMD_SV_G3 SMD_10 23-07-99 RotSMD_SV_FT3 SMD_11 23-07-99 RotSMD_SV_GT3 SMD_12 23-07-99 RotSMD_SV_F4 SMD_13 23-07-99 RotSMD_SV_G4 SMD_14 23-07-99 RotSMD_SV_FT4 SMD_15 23-07-99 RotSMD_SV_GT4 RMD_00 23-07-99 RotRMD_F3 RMD_01 23-07-99 RotRMD_G3 RMD_02 23-07-99 RotRMD_FT3 RMD_03 23-07-99 RotRMD_GT3 RMD_04 23-07-99 RotRMD_F4 RMD_05 23-07-99 RotRMD_G4 RMD_06 23-07-99 RotRMD_FT4 RMD_07 23-07-99 RotRMD_GT4 RMD_08 23-07-99 RotRMD_SV_F3 RMD_09 23-07-99 RotRMD_SV_G3 RMD_10 23-07-99 RotRMD_SV_FT3 RMD_11 23-07-99 RotRMD_SV_GT3 RMD_12 23-07-99 RotRMD_SV_F4 RMD_13 23-07-99 RotRMD_SV_G4 RMD_14 23-07-99 RotRMD_SV_FT4 RMD_15 23-07-99 RotRMD_SV_GT4 CLIP_INI 23-07-99 CLIPEvbf *_tmp_evbf InitClip *CLIPNearz *CLIPFarz *CLIPHdkx *CLIPHdky *CLIPKdhx *CLIPKdhy CLIPF_00 23-07-99 Clip3FP CLIPF_01 23-07-99 Clip4FP CLIPF_02 23-07-99 Clip3F CLIPF_03 23-07-99 Clip4F CLIPF_04 23-07-99 ClipF CLIPF_05 23-07-99 ZClipF DVF3_00 23-07-99 GsTMDdivF3L DVF3_01 23-07-99 GsTMDdivF3LFG DVF3_02 23-07-99 GsTMDdivF3NL DVF3_03 23-07-99 GsTMDdivNF3 DVF3_04 23-07-99 DivideF3 DVFT3_00 23-07-99 GsTMDdivTF3L DVFT3_01 23-07-99 GsTMDdivTF3LFG DVFT3_02 23-07-99 GsTMDdivTF3NL DVFT3_03 23-07-99 GsTMDdivTNF3 DVFT3_04 23-07-99 DivideFT3 DVG3_00 23-07-99 GsTMDdivG3L DVG3_01 23-07-99 GsTMDdivG3LFG DVG3_02 23-07-99 GsTMDdivG3NL DVG3_03 23-07-99 GsTMDdivNG3 DVG3_04 23-07-99 DivideG3 DVGT3_00 23-07-99 GsTMDdivTG3L DVGT3_01 23-07-99 GsTMDdivTG3LFG DVGT3_02 23-07-99 GsTMDdivTG3NL DVGT3_03 23-07-99 GsTMDdivTNG3 DVGT3_04 23-07-99 DivideGT3 DVF4_00 23-07-99 GsTMDdivF4L DVF4_01 23-07-99 GsTMDdivF4LFG DVF4_02 23-07-99 GsTMDdivF4NL DVF4_03 23-07-99 GsTMDdivNF4 DVF4_04 23-07-99 DivideF4 DVFT4_00 23-07-99 GsTMDdivTF4L DVFT4_01 23-07-99 GsTMDdivTF4LFG DVFT4_02 23-07-99 GsTMDdivTF4NL DVFT4_03 23-07-99 GsTMDdivTNF4 DVFT4_04 23-07-99 DivideFT4 DVG4_00 23-07-99 GsTMDdivG4L DVG4_01 23-07-99 GsTMDdivG4LFG DVG4_02 23-07-99 GsTMDdivG4NL DVG4_03 23-07-99 GsTMDdivNG4 DVG4_04 23-07-99 DivideG4 DVGT4_00 23-07-99 GsTMDdivTG4L DVGT4_01 23-07-99 GsTMDdivTG4LFG DVGT4_02 23-07-99 GsTMDdivTG4NL DVGT4_03 23-07-99 GsTMDdivTNG4 DVGT4_04 23-07-99 DivideGT4 DIVF3A 23-07-99 RCpolyF3 RCpolyF3A DIVFT3A 23-07-99 RCpolyFT3 RCpolyFT3A DIVG3A 23-07-99 RCpolyG3 RCpolyG3A DIVGT3A 23-07-99 RCpolyGT3 RCpolyGT3A DIVF4A 23-07-99 RCpolyF4 RCpolyF4A DIVFT4A 23-07-99 RCpolyFT4 RCpolyFT4A DIVG4A 23-07-99 RCpolyG4 RCpolyG4A DIVGT4A 23-07-99 RCpolyGT4 RCpolyGT4A DIVP 23-07-99 DivPloyFT4 DVFT4M00 23-07-99 GsTMDdivTF4LM DVFT4M01 23-07-99 GsTMDdivTF4LFGM DVFT4M02 23-07-99 GsTMDdivTF4NLM DVFT4M03 23-07-99 GsTMDdivTNF4M DVGT4M00 23-07-99 GsTMDdivTG4LM DVGT4M01 23-07-99 GsTMDdivTG4LFGM DVGT4M02 23-07-99 GsTMDdivTG4NLM DVGT4M03 23-07-99 GsTMDdivTNG4M RMPS_F 23-07-99 RotMeshPrimS_F3 RMPS_G 23-07-99 RotMeshPrimS_G3 RMPS_FT 23-07-99 RotMeshPrimS_FT3 RMPS_GT 23-07-99 RotMeshPrimS_GT3 RMPS_FC 23-07-99 RotMeshPrimS_FC3 RMPS_GC 23-07-99 RotMeshPrimS_GC3 RMPS_FCT 23-07-99 RotMeshPrimS_FCT3 RMPS_GCT 23-07-99 RotMeshPrimS_GCT3 RMPS_T 23-07-99 RotMeshPrimS_T3 RMPR_F 23-07-99 RotMeshPrimR_F3 RMPR_G 23-07-99 RotMeshPrimR_G3 RMPR_FT 23-07-99 RotMeshPrimR_FT3 RMPR_GT 23-07-99 RotMeshPrimR_GT3 RMPR_FC 23-07-99 RotMeshPrimR_FC3 RMPR_GC 23-07-99 RotMeshPrimR_GC3 RMPR_FCT 23-07-99 RotMeshPrimR_FCT3 RMPR_GCT 23-07-99 RotMeshPrimR_GCT3 RMPR_T 23-07-99 RotMeshPrimR_T3 RMPQ_T 23-07-99 RotMeshPrimQ_T RATAN 23-07-99 ratan_tbl ratan2 PPMFT 23-07-99 pers_map PPM 23-07-99 ScanXY0 PATCHGTE 23-07-99 _patch_gte PHN 23-07-99 PhongLine DVF3B00 23-07-99 GsTMDdivF3LB DVF3B01 23-07-99 GsTMDdivF3LFGB DVF3B02 23-07-99 GsTMDdivF3NLB DVF3B03 23-07-99 GsTMDdivNF3B DVF4B00 23-07-99 GsTMDdivF4LB DVF4B01 23-07-99 GsTMDdivF4LFGB DVF4B02 23-07-99 GsTMDdivF4NLB DVF4B03 23-07-99 GsTMDdivNF4B DVFT3B00 23-07-99 GsTMDdivTF3LB DVFT3B01 23-07-99 GsTMDdivTF3LFGB DVFT3B02 23-07-99 GsTMDdivTF3NLB DVFT3B03 23-07-99 GsTMDdivTNF3B DVFT4B00 23-07-99 GsTMDdivTF4LB DVFT4B01 23-07-99 GsTMDdivTF4LFGB DVFT4B02 23-07-99 GsTMDdivTF4NLB DVFT4B03 23-07-99 GsTMDdivTNF4B DVG3B00 23-07-99 GsTMDdivG3LB DVG3B01 23-07-99 GsTMDdivG3LFGB DVG3B02 23-07-99 GsTMDdivG3NLB DVG3B03 23-07-99 GsTMDdivNG3B DVG4B00 23-07-99 GsTMDdivG4LB DVG4B01 23-07-99 GsTMDdivG4LFGB DVG4B02 23-07-99 GsTMDdivG4NLB DVG4B03 23-07-99 GsTMDdivNG4B DVGT3B00 23-07-99 GsTMDdivTG3LB DVGT3B01 23-07-99 GsTMDdivTG3LFGB DVGT3B02 23-07-99 GsTMDdivTG3NLB DVGT3B03 23-07-99 GsTMDdivTNG3B DVGT4B00 23-07-99 GsTMDdivTG4LB DVGT4B01 23-07-99 GsTMDdivTG4LFGB DVGT4B02 23-07-99 GsTMDdivTG4NLB DVGT4B03 23-07-99 GsTMDdivTNG4B GEO_1 23-07-99 RotMatrixZYX_C GEO_2 23-07-99 RotMatrix_C GEO_3 23-07-99 RotMatrixYXZ_C GEO_4 23-07-99 RotMatrixX_C GEO_5 23-07-99 RotMatrixY_C GEO_6 23-07-99 RotMatrixZ_C GEO_02_1 23-07-99 EigenMatrix GEO_02_2 23-07-99 IsIdMatrix GEO_03_1 23-07-99 MatrixNormal_0 GEO_03_2 23-07-99 MatrixNormal_1 GEO_03_3 23-07-99 MatrixNormal_2 SPL_1 23-07-99 SubPol4 SPL_2 23-07-99 SubPol3 MSC06_1 23-07-99 LoadAverage12 MSC06_2 23-07-99 LoadAverage0 MSC06_3 23-07-99 LoadAverageShort12 MSC06_4 23-07-99 LoadAverageShort0 MSC06_5 23-07-99 LoadAverageByte MSC06_6 23-07-99 LoadAverageCol REG02_1 23-07-99 ReadOTZ REG02_2 23-07-99 ReadIR0 REG02_3 23-07-99 ReadIR123 REG02_4 23-07-99 ReadSZ2 REG02_5 23-07-99 ReadMac0 REG02_6 23-07-99 ReadMAC123 REG02_7 23-07-99 ReadORGB REG02_8 23-07-99 ReadLZC REG02_9 23-07-99 ReadFLAG REG03_1 23-07-99 SetVertex0 REG03_2 23-07-99 SetVertex1 REG03_3 23-07-99 SetVertex2 REG03_4 23-07-99 SetVertexTri REG03_5 23-07-99 SetRGBfifo REG03_6 23-07-99 SetIR123 REG03_7 23-07-99 SetIR0 REG03_8 23-07-99 SetSZfifo3 REG03_9 23-07-99 SetSZfifo4 REG03_10 23-07-99 SetSXSYfifo REG03_11 23-07-99 SetRii REG03_12 23-07-99 SetMAC123 REG03_13 23-07-99 SetData32 REG03_14 23-07-99 SetDQA REG03_15 23-07-99 SetDQB SMP_1 23-07-99 LocalLight SMP_2 23-07-99 DpqColor SMP_3 23-07-99 NormalColor SMP_4 23-07-99 NormalColor3 SMP_5 23-07-99 NormalColorDpq SMP_6 23-07-99 NormalColorDpq3 SMP_7 23-07-99 NormalColorCol SMP_8 23-07-99 NormalColorCol3 SMP_9 23-07-99 ColorDpq SMP_10 23-07-99 ColorCol SMP_11 23-07-99 AverageSZ3 SMP_12 23-07-99 AverageSZ4 SMP_00_1 23-07-99 LightColor SMP_00_2 23-07-99 DpqColorLight SMP_00_3 23-07-99 DpqColor3 SMP_00_4 23-07-99 Intpl SMP_00_5 23-07-99 Square12 SMP_00_6 23-07-99 Square0 SMP_00_7 23-07-99 AverageZ3 SMP_00_8 23-07-99 AverageZ4 SMP_00_9 23-07-99 OuterProduct12 SMP_00_1 23-07-99 OuterProduct0 SMP_00_1 23-07-99 Lzc SMP_01_1 23-07-99 RotTransSV SMP_01_2 23-07-99 SquareSS12 SMP_01_3 23-07-99 SquareSS0 SMP_01_4 23-07-99 SquareSL12 SMP_01_5 23-07-99 SquareSL0 TMD_1 23-07-99 gte_scope_f3 TMD_2 23-07-99 gte_scope_tf3 TMD_3 23-07-99 gte_scope_g3 TMD_4 23-07-99 gte_scope_tg3 TMD_5 23-07-99 gte_flat3 TMD_6 23-07-99 gte_texture_flat3 TMD_7 23-07-99 gte_gouraud3 TMD_8 23-07-99 gte_texture_gouraud3 TMD_9 23-07-99 gte_flat_fog3 TMD_10 23-07-99 gte_texture_flat_fog3 TMD_11 23-07-99 gte_gouraud_fog3 TMD_12 23-07-99 gte_texture_gouraud_fog3 TMD_13 23-07-99 gte_scope_tf4_B TMD_14 23-07-99 gte_scope_tf4 NOM_1 23-07-99 RotTransPers_nom NOM_2 23-07-99 RotTransPers3_nom NOM_3 23-07-99 RotTrans_nom NOM_4 23-07-99 RotTransPers4_nom NOM_5 23-07-99 RotAverage3_nom NOM_6 23-07-99 RotNclip3_nom NOM_7 23-07-99 RotAverageNclip3_nom NOM_8 23-07-99 RotColorDpq_nom NOM_9 23-07-99 RotColorDpq3_nom NOM_10 23-07-99 RotAverageNclipColorDpq3_nom NOM_11 23-07-99 RotAverageNclipColorCol3_nom NOM_12 23-07-99 NormalColor_nom NOM_13 23-07-99 NormalColor3_nom NOM_14 23-07-99 NormalColorDpq_nom NOM_15 23-07-99 NormalColorDpq3_nom NOM_16 23-07-99 NormalColorCol_nom NOM_17 23-07-99 NormalColorCol3_nom F3_1 23-07-99 GsTMDfastNF3 F3_2 23-07-99 GsTMDfastF3NL F3_3 23-07-99 GsTMDfastF3L F3_4 23-07-99 GsTMDfastF3LFG F4_1 23-07-99 GsTMDfastNF4 F4_2 23-07-99 GsTMDfastF4NL F4_3 23-07-99 GsTMDfastF4L F4_4 23-07-99 GsTMDfastF4LFG F4S_1 23-07-99 GsTMDfastNF4D F4S_2 23-07-99 GsTMDfastF4NLD F4S_3 23-07-99 GsTMDfastF4LD F4S_4 23-07-99 GsTMDfastF4LFGD G3_1 23-07-99 GsTMDfastNG3 G3_2 23-07-99 GsTMDfastG3NL G3_3 23-07-99 GsTMDfastG3L G3_4 23-07-99 GsTMDfastG3LFG G4_1 23-07-99 GsTMDfastNG4 G4_2 23-07-99 GsTMDfastG4NL G4_3 23-07-99 GsTMDfastG4L G4_4 23-07-99 GsTMDfastG4LFG G4S_1 23-07-99 GsTMDfastNG4D G4S_2 23-07-99 GsTMDfastG4NLD G4S_3 23-07-99 GsTMDfastG4LD G4S_4 23-07-99 GsTMDfastG4LFGD FT3_1 23-07-99 GsTMDfastTNF3 FT3_2 23-07-99 GsTMDfastTF3NL FT3_3 23-07-99 GsTMDfastTF3L FT3_4 23-07-99 GsTMDfastTF3LFG FT4_1 23-07-99 GsTMDfastTNF4 FT4_2 23-07-99 GsTMDfastTF4NL FT4_3 23-07-99 GsTMDfastTF4L FT4_4 23-07-99 GsTMDfastTF4LFG FT4S_1 23-07-99 GsTMDfastTNF4D FT4S_2 23-07-99 GsTMDfastTF4NLD FT4S_3 23-07-99 GsTMDfastTF4LD FT4S_4 23-07-99 GsTMDfastTF4LFGD GT3_1 23-07-99 GsTMDfastTNG3 GT3_2 23-07-99 GsTMDfastTG3NL GT3_3 23-07-99 GsTMDfastTG3L GT3_4 23-07-99 GsTMDfastTG3LFG GT4_1 23-07-99 GsTMDfastTNG4 GT4_2 23-07-99 GsTMDfastTG4NL GT4_3 23-07-99 GsTMDfastTG4L GT4_4 23-07-99 GsTMDfastTG4LFG GT4S_1 23-07-99 GsTMDfastTNG4D GT4S_2 23-07-99 GsTMDfastTG4NLD GT4S_3 23-07-99 GsTMDfastTG4LD GT4S_4 23-07-99 GsTMDfastTG4LFGD PRS_F3_1 23-07-99 GsPrstNF3 PRS_F3_2 23-07-99 GsPrstF3NL PRS_F3_3 23-07-99 GsPrstF3L PRS_F3_4 23-07-99 GsPrstF3LFG PRS_F4_1 23-07-99 GsPrstNF4 PRS_F4_2 23-07-99 GsPrstF4NL PRS_F4_3 23-07-99 GsPrstF4L PRS_F4_4 23-07-99 GsPrstF4LFG PRS_F4S_ 23-07-99 GsPrstNF4D PRS_F4S_ 23-07-99 GsPrstF4NLD PRS_F4S_ 23-07-99 GsPrstF4LD PRS_F4S_ 23-07-99 GsPrstF4LFGD PRS_G3_1 23-07-99 GsPrstNG3 PRS_G3_2 23-07-99 GsPrstG3NL PRS_G3_3 23-07-99 GsPrstG3L PRS_G3_4 23-07-99 GsPrstG3LFG PRS_G4_1 23-07-99 GsPrstNG4 PRS_G4_2 23-07-99 GsPrstG4NL PRS_G4_3 23-07-99 GsPrstG4L PRS_G4_4 23-07-99 GsPrstG4LFG PRS_G4S_ 23-07-99 GsPrstNG4D PRS_G4S_ 23-07-99 GsPrstG4NLD PRS_G4S_ 23-07-99 GsPrstG4LD PRS_G4S_ 23-07-99 GsPrstG4LFGD PRS_FT3_ 23-07-99 GsPrstTNF3 PRS_FT3_ 23-07-99 GsPrstTF3NL PRS_FT3_ 23-07-99 GsPrstTF3L PRS_FT3_ 23-07-99 GsPrstTF3LFG PRS_FT4_ 23-07-99 GsPrstTNF4 PRS_FT4_ 23-07-99 GsPrstTF4NL PRS_FT4_ 23-07-99 GsPrstTF4L PRS_FT4_ 23-07-99 GsPrstTF4LFG PRS_FT4S 23-07-99 GsPrstTNF4D PRS_FT4S 23-07-99 GsPrstTF4NLD PRS_FT4S 23-07-99 GsPrstTF4LD PRS_FT4S 23-07-99 GsPrstTF4LFGD PRS_GT3_ 23-07-99 GsPrstTNG3 PRS_GT3_ 23-07-99 GsPrstTG3NL PRS_GT3_ 23-07-99 GsPrstTG3L PRS_GT3_ 23-07-99 GsPrstTG3LFG PRS_GT4_ 23-07-99 GsPrstTNG4 PRS_GT4_ 23-07-99 GsPrstTG4NL PRS_GT4_ 23-07-99 GsPrstTG4L PRS_GT4_ 23-07-99 GsPrstTG4LFG PRS_GT4S 23-07-99 GsPrstTNG4D PRS_GT4S 23-07-99 GsPrstTG4NLD PRS_GT4S 23-07-99 GsPrstTG4LD PRS_GT4S 23-07-99 GsPrstTG4LFGD PMD_1 23-07-99 RotPMD_F3 PMD_2 23-07-99 RotPMD_G3 PMD_3 23-07-99 RotPMD_FT3 PMD_4 23-07-99 RotPMD_GT3 PMD_5 23-07-99 RotPMD_F4 PMD_6 23-07-99 RotPMD_G4 PMD_7 23-07-99 RotPMD_FT4 PMD_8 23-07-99 RotPMD_GT4 PMD_9 23-07-99 RotPMD_SV_F3 PMD_10 23-07-99 RotPMD_SV_G3 PMD_11 23-07-99 RotPMD_SV_FT3 PMD_12 23-07-99 RotPMD_SV_GT3 PMD_13 23-07-99 RotPMD_SV_F4 PMD_14 23-07-99 RotPMD_SV_G4 PMD_15 23-07-99 RotPMD_SV_FT4 PMD_16 23-07-99 RotPMD_SV_GT4 NMD_1 23-07-99 RotNMD_F3 NMD_2 23-07-99 RotNMD_G3 NMD_3 23-07-99 RotNMD_FT3 NMD_4 23-07-99 RotNMD_GT3 NMD_5 23-07-99 RotNMD_F4 NMD_6 23-07-99 RotNMD_G4 NMD_7 23-07-99 RotNMD_FT4 NMD_8 23-07-99 RotNMD_GT4 NMD_9 23-07-99 RotNMD_SV_F3 NMD_10 23-07-99 RotNMD_SV_G3 NMD_11 23-07-99 RotNMD_SV_FT3 NMD_12 23-07-99 RotNMD_SV_GT3 NMD_13 23-07-99 RotNMD_SV_F4 NMD_14 23-07-99 RotNMD_SV_G4 NMD_15 23-07-99 RotNMD_SV_FT4 NMD_16 23-07-99 RotNMD_SV_GT4 CLIP_G_1 23-07-99 Clip3GP Clip3G CLIP_G_2 23-07-99 Clip4GP Clip4G CLIP_G_3 23-07-99 ClipG ZClipG CLIP_FT_ 23-07-99 Clip3FTP Clip3FT CLIP_FT_ 23-07-99 Clip4FTP Clip4FT CLIP_FT_ 23-07-99 ClipFT ZClipFT CLIP_GT_ 23-07-99 Clip3GTP Clip3GT CLIP_GT_ 23-07-99 Clip4GTP Clip4GT CLIP_GT_ 23-07-99 ClipGT ZClipGT TRR_1 23-07-99 TransRot_32 TRR_2 23-07-99 TransRotPers TRR_3 23-07-99 TransRotPers3 TRR_4 23-07-99 ApplyTransposeMatrixLV F3B_1 23-07-99 GsTMDfastNF3B F3B_2 23-07-99 GsTMDfastF3NLB F3B_3 23-07-99 GsTMDfastF3LB F3B_4 23-07-99 GsTMDfastF3LFGB F4B_1 23-07-99 GsTMDfastNF4B F4B_2 23-07-99 GsTMDfastF4NLB F4B_3 23-07-99 GsTMDfastF4LB F4B_4 23-07-99 GsTMDfastF4LFGB G3B_1 23-07-99 GsTMDfastNG3B G3B_2 23-07-99 GsTMDfastG3NLB G3B_3 23-07-99 GsTMDfastG3LB G3B_4 23-07-99 GsTMDfastG3LFGB G4B_1 23-07-99 GsTMDfastNG4B G4B_2 23-07-99 GsTMDfastG4NLB G4B_3 23-07-99 GsTMDfastG4LB G4B_4 23-07-99 GsTMDfastG4LFGB FT3B_1 23-07-99 GsTMDfastTNF3B FT3B_2 23-07-99 GsTMDfastTF3NLB FT3B_3 23-07-99 GsTMDfastTF3LB FT3B_4 23-07-99 GsTMDfastTF3LFGB FT4B_1 23-07-99 GsTMDfastTNF4B FT4B_2 23-07-99 GsTMDfastTF4NLB FT4B_3 23-07-99 GsTMDfastTF4LB FT4B_4 23-07-99 GsTMDfastTF4LFGB GT3B_1 23-07-99 GsTMDfastTNG3B GT3B_2 23-07-99 GsTMDfastTG3NLB GT3B_3 23-07-99 GsTMDfastTG3LB GT3B_4 23-07-99 GsTMDfastTG3LFGB GT4B_1 23-07-99 GsTMDfastTNG4B GT4B_2 23-07-99 GsTMDfastTG4NLB GT4B_3 23-07-99 GsTMDfastTG4LB GT4B_4 23-07-99 GsTMDfastTG4LFGB GT3F_1 23-07-99 GsTMDfastTNG3_FLIP GT3F_2 23-07-99 GsTMDfastTG3NL_FLIP GT3F_3 23-07-99 GsTMDfastTG3L_FLIP GT3F_4 23-07-99 GsTMDfastTG3LFG_FLIP LIBGUNLightgun library Module Date Externals defined GUN 22-09-97 RemoveGUN StopGun StartGun SelectGUN StartGUN StopGUN InitGUN SendGUN EnableGUN DisableGUN NEWGUN 22-09-97 _InitGun _ExitGun _check_gun_flag _clear_gun_flag read_gun_v read_gun_h LIBHMD (HMD model, texture and animation format handling)The LIBHMD.LIB library supports loading the HMD format which is a 3D object that contains animation, texture and vertices to represent an object in 3D space. Module Date Externals defined 00000008 23-07-99 GsU_00000008 00000009 23-07-99 GsU_00000009 0000000A 23-07-99 GsU_0000000a 0000000B 23-07-99 GsU_0000000b 0000000C 23-07-99 GsU_0000000c 0000000D 23-07-99 GsU_0000000d 0000000E 23-07-99 GsU_0000000e 0000000F 23-07-99 GsU_0000000f 00000010 23-07-99 GsU_00000010 00000011 23-07-99 GsU_00000011 00000012 23-07-99 GsU_00000012 00000013 23-07-99 GsU_00000013 00000014 23-07-99 GsU_00000014 00000015 23-07-99 GsU_00000015 00000016 23-07-99 GsU_00000016 00000017 23-07-99 GsU_00000017 00000018 23-07-99 GsU_00000018 00000019 23-07-99 GsU_00000019 0000001C 23-07-99 GsU_0000001c 0000001D 23-07-99 GsU_0000001d 00000209 23-07-99 GsU_00000209 0000020B 23-07-99 GsU_0000020b 0000020D 23-07-99 GsU_0000020d 0000020F 23-07-99 GsU_0000020f 00000211 23-07-99 GsU_00000211 00000213 23-07-99 GsU_00000213 00000215 23-07-99 GsU_00000215 00000217 23-07-99 GsU_00000217 00020008 23-07-99 GsU_00020008 00020009 23-07-99 GsU_00020009 0002000A 23-07-99 GsU_0002000a 0002000B 23-07-99 GsU_0002000b 0002000C 23-07-99 GsU_0002000c 0002000D 23-07-99 GsU_0002000d 0002000E 23-07-99 GsU_0002000e 0002000F 23-07-99 GsU_0002000f 00020010 23-07-99 GsU_00020010 00020011 23-07-99 GsU_00020011 00020012 23-07-99 GsU_00020012 00020013 23-07-99 GsU_00020013 00020014 23-07-99 GsU_00020014 00020015 23-07-99 GsU_00020015 00020016 23-07-99 GsU_00020016 00020017 23-07-99 GsU_00020017 00020209 23-07-99 GsU_00020209 0002020B 23-07-99 GsU_0002020b 0002020D 23-07-99 GsU_0002020d 0002020F 23-07-99 GsU_0002020f 00020211 23-07-99 GsU_00020211 00020213 23-07-99 GsU_00020213 00020215 23-07-99 GsU_00020215 00020217 23-07-99 GsU_00020217 00040048 23-07-99 GsU_00040048 00040049 23-07-99 GsU_00040049 0004004C 23-07-99 GsU_0004004c 0004004D 23-07-99 GsU_0004004d 00040050 23-07-99 GsU_00040050 00040051 23-07-99 GsU_00040051 00040054 23-07-99 GsU_00040054 00040055 23-07-99 GsU_00040055 00040058 23-07-99 GsU_00040058 00040059 23-07-99 GsU_00040059 0004005C 23-07-99 GsU_0004005c 0004005D 23-07-99 GsU_0004005d 00040148 23-07-99 GsU_00040148 00040149 23-07-99 GsU_00040149 0004014C 23-07-99 GsU_0004014c 0004014D 23-07-99 GsU_0004014d 00040150 23-07-99 GsU_00040150 00040151 23-07-99 GsU_00040151 00040154 23-07-99 GsU_00040154 00040155 23-07-99 GsU_00040155 00040249 23-07-99 GsU_00040249 0004024D 23-07-99 GsU_0004024d 00040251 23-07-99 GsU_00040251 00040255 23-07-99 GsU_00040255 00100008 23-07-99 GsU_00100008 00100009 23-07-99 GsU_00100009 0010000A 23-07-99 GsU_0010000a 0010000B 23-07-99 GsU_0010000b 0010000C 23-07-99 GsU_0010000c 0010000D 23-07-99 GsU_0010000d 0010000E 23-07-99 GsU_0010000e 0010000F 23-07-99 GsU_0010000f 00100010 23-07-99 GsU_00100010 00100011 23-07-99 GsU_00100011 00100012 23-07-99 GsU_00100012 00100013 23-07-99 GsU_00100013 00100014 23-07-99 GsU_00100014 00100015 23-07-99 GsU_00100015 00100016 23-07-99 GsU_00100016 00100017 23-07-99 GsU_00100017 00100209 23-07-99 GsU_00100209 0010020B 23-07-99 GsU_0010020b 0010020D 23-07-99 GsU_0010020d 0010020F 23-07-99 GsU_0010020f 00100211 23-07-99 GsU_00100211 00100213 23-07-99 GsU_00100213 00100215 23-07-99 GsU_00100215 00100217 23-07-99 GsU_00100217 00200008 23-07-99 GsU_00200008 00200009 23-07-99 GsU_00200009 0020000C 23-07-99 GsU_0020000c 0020000D 23-07-99 GsU_0020000d 00200010 23-07-99 GsU_00200010 00200011 23-07-99 GsU_00200011 00200014 23-07-99 GsU_00200014 00200015 23-07-99 GsU_00200015 00200209 23-07-99 GsU_00200209 0020020D 23-07-99 GsU_0020020d 00200211 23-07-99 GsU_00200211 00200215 23-07-99 GsU_00200215 00240048 23-07-99 GsU_00240048 00240049 23-07-99 GsU_00240049 0024004C 23-07-99 GsU_0024004c 0024004D 23-07-99 GsU_0024004d 00240050 23-07-99 GsU_00240050 00240051 23-07-99 GsU_00240051 00240054 23-07-99 GsU_00240054 00240055 23-07-99 GsU_00240055 00240249 23-07-99 GsU_00240249 0024024D 23-07-99 GsU_0024024d 00240251 23-07-99 GsU_00240251 00240255 23-07-99 GsU_00240255 00300008 23-07-99 GsU_00300008 00300009 23-07-99 GsU_00300009 0030000C 23-07-99 GsU_0030000c 0030000D 23-07-99 GsU_0030000d 00300010 23-07-99 GsU_00300010 00300011 23-07-99 GsU_00300011 00300014 23-07-99 GsU_00300014 00300015 23-07-99 GsU_00300015 00300209 23-07-99 GsU_00300209 0030020D 23-07-99 GsU_0030020d 00300211 23-07-99 GsU_00300211 00300215 23-07-99 GsU_00300215 01000000 23-07-99 GsU_01000000 0100000C 23-07-99 GsU_0100000c 0100000D 23-07-99 GsU_0100000d 0100000E 23-07-99 GsU_0100000e 0100000F 23-07-99 GsU_0100000f 01000014 23-07-99 GsU_01000014 01000015 23-07-99 GsU_01000015 01000016 23-07-99 GsU_01000016 01000017 23-07-99 GsU_01000017 0100020D 23-07-99 GsU_0100020d 0100020F 23-07-99 GsU_0100020f 01000215 23-07-99 GsU_01000215 01000217 23-07-99 GsU_01000217 0102000C 23-07-99 GsU_0102000c 0102000D 23-07-99 GsU_0102000d 0102000E 23-07-99 GsU_0102000e 0102000F 23-07-99 GsU_0102000f 01020014 23-07-99 GsU_01020014 01020015 23-07-99 GsU_01020015 01020016 23-07-99 GsU_01020016 01020017 23-07-99 GsU_01020017 0102020D 23-07-99 GsU_0102020d 0102020F 23-07-99 GsU_0102020f 01020215 23-07-99 GsU_01020215 01020217 23-07-99 GsU_01020217 01040048 23-07-99 GsU_01040048 01040049 23-07-99 GsU_01040049 0104004C 23-07-99 GsU_0104004c 0104004D 23-07-99 GsU_0104004d 01040050 23-07-99 GsU_01040050 01040051 23-07-99 GsU_01040051 01040054 23-07-99 GsU_01040054 01040055 23-07-99 GsU_01040055 01040249 23-07-99 GsU_01040249 0104024D 23-07-99 GsU_0104024d 01040251 23-07-99 GsU_01040251 01040255 23-07-99 GsU_01040255 0120000C 23-07-99 GsU_0120000c 0120000D 23-07-99 GsU_0120000d 01200014 23-07-99 GsU_01200014 01200015 23-07-99 GsU_01200015 0120020D 23-07-99 GsU_0120020d 01200215 23-07-99 GsU_01200215 01240048 23-07-99 GsU_01240048 01240049 23-07-99 GsU_01240049 0124004C 23-07-99 GsU_0124004c 0124004D 23-07-99 GsU_0124004d 01240050 23-07-99 GsU_01240050 01240051 23-07-99 GsU_01240051 01240054 23-07-99 GsU_01240054 01240055 23-07-99 GsU_01240055 01240249 23-07-99 GsU_01240249 0124024D 23-07-99 GsU_0124024d 01240251 23-07-99 GsU_01240251 01240255 23-07-99 GsU_01240255 ANIM 23-07-99 GsScanAnim GsLinkAnim ANIM2 23-07-99 GsSetBetaParam BEZIER 23-07-99 setBezierCof BETA 23-07-99 setBetaCof MIME 23-07-99 GsInitRstVtxMIMe GsInitRstNrmMIMe 00000000 23-07-99 GsU_00000000 00010008 23-07-99 GsU_00010008 00010009 23-07-99 GsU_00010009 0001000C 23-07-99 GsU_0001000c 0001000D 23-07-99 GsU_0001000d 00010010 23-07-99 GsU_00010010 00010011 23-07-99 GsU_00010011 00010014 23-07-99 GsU_00010014 00010015 23-07-99 GsU_00010015 00030008 23-07-99 GsU_00030008 00030009 23-07-99 GsU_00030009 0003000C 23-07-99 GsU_0003000c 0003000D 23-07-99 GsU_0003000d 00030010 23-07-99 GsU_00030010 00030011 23-07-99 GsU_00030011 00030014 23-07-99 GsU_00030014 00030015 23-07-99 GsU_00030015 00050048 23-07-99 GsU_00050048 00050049 23-07-99 GsU_00050049 0005004C 23-07-99 GsU_0005004c 0005004D 23-07-99 GsU_0005004d 00050050 23-07-99 GsU_00050050 00050051 23-07-99 GsU_00050051 00050054 23-07-99 GsU_00050054 00050055 23-07-99 GsU_00050055 02000000 23-07-99 GsU_02000000 02000001 23-07-99 GsU_02000001 03000000 23-07-99 GsU_03000000 03000001 23-07-99 GsU_03000001 03000002 23-07-99 GsU_03000002 03000003 23-07-99 GsU_03000003 03000009 23-07-99 GsU_03000009 0300000A 23-07-99 GsU_0300000a 0300000B 23-07-99 GsU_0300000b 03000100 23-07-99 GsU_03000100 03000901 23-07-99 GsU_03000901 03000902 23-07-99 GsU_03000902 03000909 23-07-99 GsU_03000909 0300090A 23-07-99 GsU_0300090a 03010110 23-07-99 GsU_03010110 03010111 23-07-99 GsU_03010111 03010112 23-07-99 GsU_03010112 03010121 23-07-99 GsU_03010121 03010122 23-07-99 GsU_03010122 03010141 23-07-99 GsU_03010141 03010142 23-07-99 GsU_03010142 03010171 23-07-99 GsU_03010171 03010172 23-07-99 GsU_03010172 03010182 23-07-99 GsU_03010182 03010210 23-07-99 GsU_03010210 03010211 23-07-99 GsU_03010211 03010212 23-07-99 GsU_03010212 03010221 23-07-99 GsU_03010221 03010222 23-07-99 GsU_03010222 03010241 23-07-99 GsU_03010241 03010242 23-07-99 GsU_03010242 03010271 23-07-99 GsU_03010271 03010272 23-07-99 GsU_03010272 03010310 23-07-99 GsU_03010310 03010311 23-07-99 GsU_03010311 03010312 23-07-99 GsU_03010312 03010321 23-07-99 GsU_03010321 03010322 23-07-99 GsU_03010322 03010341 23-07-99 GsU_03010341 03010342 23-07-99 GsU_03010342 03010371 23-07-99 GsU_03010371 03010372 23-07-99 GsU_03010372 04010011 23-07-99 GsU_04010011 04010018 23-07-99 GsU_04010018 04010019 23-07-99 GsU_04010019 04010028 23-07-99 GsU_04010028 GsU_04010029 07000100 23-07-99 GsU_07000100 07010100 23-07-99 GsU_07010100 07020100 23-07-99 GsU_07020100 07030100 23-07-99 GsU_07030100 00080008 23-07-99 GsU_00080008 00080009 23-07-99 GsU_00080009 0008000C 23-07-99 GsU_0008000c 0008000D 23-07-99 GsU_0008000d 00080010 23-07-99 GsU_00080010 00080011 23-07-99 GsU_00080011 00080014 23-07-99 GsU_00080014 00080015 23-07-99 GsU_00080015 000A0008 23-07-99 GsU_000a0008 000A0009 23-07-99 GsU_000a0009 000A000C 23-07-99 GsU_000a000c 000A000D 23-07-99 GsU_000a000d 000A0010 23-07-99 GsU_000a0010 000A0011 23-07-99 GsU_000a0011 000A0014 23-07-99 GsU_000a0014 000A0015 23-07-99 GsU_000a0015 000C0048 23-07-99 GsU_000c0048 000C0049 23-07-99 GsU_000c0049 000C004C 23-07-99 GsU_000c004c 000C004D 23-07-99 GsU_000c004d 000C0050 23-07-99 GsU_000c0050 000C0051 23-07-99 GsU_000c0051 000C0054 23-07-99 GsU_000c0054 000C0055 23-07-99 GsU_000c0055 04010010 23-07-99 GsU_04010010 04010020 23-07-99 GsU_04010020 GsU_04010021 05000000 23-07-99 GsU_05000000 05000001 23-07-99 GsU_05000001 06000100 23-07-99 GsU_06000100 0600100C 23-07-99 GsU_0600100c 06001014 23-07-99 GsU_06001014 0600110C 23-07-99 GsU_0600110c 06001114 23-07-99 GsU_06001114 0600200C 23-07-99 GsU_0600200c 06002014 23-07-99 GsU_06002014 0600300C 23-07-99 GsU_0600300c 06003014 23-07-99 GsU_06003014 0600400C 23-07-99 GsU_0600400c 06004014 23-07-99 GsU_06004014 0600500C 23-07-99 GsU_0600500c 06005014 23-07-99 GsU_06005014 07000200 23-07-99 GsU_07000200 07010200 23-07-99 GsU_07010200 07020200 23-07-99 GsU_07020200 07030200 23-07-99 GsU_07030200 00140048 23-07-99 GsU_00140048 00140049 23-07-99 GsU_00140049 0014004C 23-07-99 GsU_0014004c 0014004D 23-07-99 GsU_0014004d 00140050 23-07-99 GsU_00140050 00140051 23-07-99 GsU_00140051 00140054 23-07-99 GsU_00140054 00140055 23-07-99 GsU_00140055 00140249 23-07-99 GsU_00140249 0014024D 23-07-99 GsU_0014024d 00140251 23-07-99 GsU_00140251 00140255 23-07-99 GsU_00140255 00340048 23-07-99 GsU_00340048 00340049 23-07-99 GsU_00340049 0034004C 23-07-99 GsU_0034004c 0034004D 23-07-99 GsU_0034004d 00340050 23-07-99 GsU_00340050 00340051 23-07-99 GsU_00340051 00340054 23-07-99 GsU_00340054 00340055 23-07-99 GsU_00340055 00340249 23-07-99 GsU_00340249 0034024D 23-07-99 GsU_0034024d 00340251 23-07-99 GsU_00340251 00340255 23-07-99 GsU_00340255 01140048 23-07-99 GsU_01140048 01140049 23-07-99 GsU_01140049 0114004C 23-07-99 GsU_0114004c 0114004D 23-07-99 GsU_0114004d 01140050 23-07-99 GsU_01140050 01140051 23-07-99 GsU_01140051 01140054 23-07-99 GsU_01140054 01140055 23-07-99 GsU_01140055 01140249 23-07-99 GsU_01140249 0114024D 23-07-99 GsU_0114024d 01140251 23-07-99 GsU_01140251 01140255 23-07-99 GsU_01140255 01340048 23-07-99 GsU_01340048 01340049 23-07-99 GsU_01340049 0134004C 23-07-99 GsU_0134004c 0134004D 23-07-99 GsU_0134004d 01340050 23-07-99 GsU_01340050 01340051 23-07-99 GsU_01340051 01340054 23-07-99 GsU_01340054 01340055 23-07-99 GsU_01340055 01340249 23-07-99 GsU_01340249 0134024D 23-07-99 GsU_0134024d 01340251 23-07-99 GsU_01340251 01340255 23-07-99 GsU_01340255 0020000A 23-07-99 GsU_0020000a 0020000B 23-07-99 GsU_0020000b 0020000E 23-07-99 GsU_0020000e 0020000F 23-07-99 GsU_0020000f 00200012 23-07-99 GsU_00200012 00200013 23-07-99 GsU_00200013 00200016 23-07-99 GsU_00200016 00200017 23-07-99 GsU_00200017 0020020B 23-07-99 GsU_0020020b 0020020F 23-07-99 GsU_0020020f 00200213 23-07-99 GsU_00200213 00200217 23-07-99 GsU_00200217 0030000A 23-07-99 GsU_0030000a 0030000B 23-07-99 GsU_0030000b 0030000E 23-07-99 GsU_0030000e 0030000F 23-07-99 GsU_0030000f 00300012 23-07-99 GsU_00300012 00300013 23-07-99 GsU_00300013 00300016 23-07-99 GsU_00300016 00300017 23-07-99 GsU_00300017 0030020B 23-07-99 GsU_0030020b 0030020F 23-07-99 GsU_0030020f 00300213 23-07-99 GsU_00300213 00300217 23-07-99 GsU_00300217 0120000E 23-07-99 GsU_0120000e 0120000F 23-07-99 GsU_0120000f 01200016 23-07-99 GsU_01200016 01200017 23-07-99 GsU_01200017 0120020F 23-07-99 GsU_0120020f 01200217 23-07-99 GsU_01200217 03000010 23-07-99 GsU_03000010 03001010 23-07-99 GsU_03001010 03002010 23-07-99 GsU_03002010 03003010 23-07-99 GsU_03003010 03004010 23-07-99 GsU_03004010 03005010 23-07-99 GsU_03005010 03000011 23-07-99 GsU_03000011 03001011 23-07-99 GsU_03001011 03002011 23-07-99 GsU_03002011 03003011 23-07-99 GsU_03003011 03004011 23-07-99 GsU_03004011 03005011 23-07-99 GsU_03005011 03000012 23-07-99 GsU_03000012 03001012 23-07-99 GsU_03001012 03002012 23-07-99 GsU_03002012 03003012 23-07-99 GsU_03003012 03004012 23-07-99 GsU_03004012 03005012 23-07-99 GsU_03005012 03000013 23-07-99 GsU_03000013 03001013 23-07-99 GsU_03001013 03002013 23-07-99 GsU_03002013 03003013 23-07-99 GsU_03003013 03004013 23-07-99 GsU_03004013 03005013 23-07-99 GsU_03005013 03000019 23-07-99 GsU_03000019 03001019 23-07-99 GsU_03001019 03002019 23-07-99 GsU_03002019 03003019 23-07-99 GsU_03003019 03004019 23-07-99 GsU_03004019 03005019 23-07-99 GsU_03005019 0300001A 23-07-99 GsU_0300001a 0300101A 23-07-99 GsU_0300101a 0300201A 23-07-99 GsU_0300201a 0300301A 23-07-99 GsU_0300301a 0300401A 23-07-99 GsU_0300401a 0300501A 23-07-99 GsU_0300501a 0300001B 23-07-99 GsU_0300001b 0300101B 23-07-99 GsU_0300101b 0300201B 23-07-99 GsU_0300201b 0300301B 23-07-99 GsU_0300301b 0300401B 23-07-99 GsU_0300401b 0300501B 23-07-99 GsU_0300501b 03000020 23-07-99 GsU_03000020 03001020 23-07-99 GsU_03001020 03002020 23-07-99 GsU_03002020 03003020 23-07-99 GsU_03003020 03004020 23-07-99 GsU_03004020 03005020 23-07-99 GsU_03005020 03000021 23-07-99 GsU_03000021 03001021 23-07-99 GsU_03001021 03002021 23-07-99 GsU_03002021 03003021 23-07-99 GsU_03003021 03004021 23-07-99 GsU_03004021 03005021 23-07-99 GsU_03005021 03000022 23-07-99 GsU_03000022 03001022 23-07-99 GsU_03001022 03002022 23-07-99 GsU_03002022 03003022 23-07-99 GsU_03003022 03004022 23-07-99 GsU_03004022 03005022 23-07-99 GsU_03005022 03000023 23-07-99 GsU_03000023 03001023 23-07-99 GsU_03001023 03002023 23-07-99 GsU_03002023 03003023 23-07-99 GsU_03003023 03004023 23-07-99 GsU_03004023 03005023 23-07-99 GsU_03005023 03000029 23-07-99 GsU_03000029 03001029 23-07-99 GsU_03001029 03002029 23-07-99 GsU_03002029 03003029 23-07-99 GsU_03003029 03004029 23-07-99 GsU_03004029 03005029 23-07-99 GsU_03005029 0300002A 23-07-99 GsU_0300002a 0300102A 23-07-99 GsU_0300102a 0300202A 23-07-99 GsU_0300202a 0300302A 23-07-99 GsU_0300302a 0300402A 23-07-99 GsU_0300402a 0300502A 23-07-99 GsU_0300502a 0300002B 23-07-99 GsU_0300002b 0300102B 23-07-99 GsU_0300102b 0300202B 23-07-99 GsU_0300202b 0300302B 23-07-99 GsU_0300302b 0300402B 23-07-99 GsU_0300402b 0300502B 23-07-99 GsU_0300502b 03000030 23-07-99 GsU_03000030 03001030 23-07-99 GsU_03001030 03002030 23-07-99 GsU_03002030 03003030 23-07-99 GsU_03003030 03004030 23-07-99 GsU_03004030 03005030 23-07-99 GsU_03005030 03000031 23-07-99 GsU_03000031 03001031 23-07-99 GsU_03001031 03002031 23-07-99 GsU_03002031 03003031 23-07-99 GsU_03003031 03004031 23-07-99 GsU_03004031 03005031 23-07-99 GsU_03005031 03000032 23-07-99 GsU_03000032 03001032 23-07-99 GsU_03001032 03002032 23-07-99 GsU_03002032 03003032 23-07-99 GsU_03003032 03004032 23-07-99 GsU_03004032 03005032 23-07-99 GsU_03005032 03000033 23-07-99 GsU_03000033 03001033 23-07-99 GsU_03001033 03002033 23-07-99 GsU_03002033 03003033 23-07-99 GsU_03003033 03004033 23-07-99 GsU_03004033 03005033 23-07-99 GsU_03005033 03000039 23-07-99 GsU_03000039 03001039 23-07-99 GsU_03001039 03002039 23-07-99 GsU_03002039 03003039 23-07-99 GsU_03003039 03004039 23-07-99 GsU_03004039 03005039 23-07-99 GsU_03005039 0300003A 23-07-99 GsU_0300003a 0300103A 23-07-99 GsU_0300103a 0300203A 23-07-99 GsU_0300203a 0300303A 23-07-99 GsU_0300303a 0300403A 23-07-99 GsU_0300403a 0300503A 23-07-99 GsU_0300503a 0300003B 23-07-99 GsU_0300003b 0300103B 23-07-99 GsU_0300103b 0300203B 23-07-99 GsU_0300203b 0300303B 23-07-99 GsU_0300303b 0300403B 23-07-99 GsU_0300403b 0300503B 23-07-99 GsU_0300503b 03000111 23-07-99 GsU_03000111 03001111 23-07-99 GsU_03001111 03002111 23-07-99 GsU_03002111 03003111 23-07-99 GsU_03003111 03004111 23-07-99 GsU_03004111 03005111 23-07-99 GsU_03005111 03000112 23-07-99 GsU_03000112 03001112 23-07-99 GsU_03001112 03002112 23-07-99 GsU_03002112 03003112 23-07-99 GsU_03003112 03004112 23-07-99 GsU_03004112 03005112 23-07-99 GsU_03005112 03000119 23-07-99 GsU_03000119 03001119 23-07-99 GsU_03001119 03002119 23-07-99 GsU_03002119 03003119 23-07-99 GsU_03003119 03004119 23-07-99 GsU_03004119 03005119 23-07-99 GsU_03005119 0300011A 23-07-99 GsU_0300011a 0300111A 23-07-99 GsU_0300111a 0300211A 23-07-99 GsU_0300211a 0300311A 23-07-99 GsU_0300311a 0300411A 23-07-99 GsU_0300411a 0300511A 23-07-99 GsU_0300511a 03000910 23-07-99 GsU_03000910 03001910 23-07-99 GsU_03001910 03002910 23-07-99 GsU_03002910 03003910 23-07-99 GsU_03003910 03004910 23-07-99 GsU_03004910 03005910 23-07-99 GsU_03005910 03000911 23-07-99 GsU_03000911 03001911 23-07-99 GsU_03001911 03002911 23-07-99 GsU_03002911 03003911 23-07-99 GsU_03003911 03004911 23-07-99 GsU_03004911 03005911 23-07-99 GsU_03005911 03000912 23-07-99 GsU_03000912 03001912 23-07-99 GsU_03001912 03002912 23-07-99 GsU_03002912 03003912 23-07-99 GsU_03003912 03004912 23-07-99 GsU_03004912 03005912 23-07-99 GsU_03005912 03000919 23-07-99 GsU_03000919 03001919 23-07-99 GsU_03001919 03002919 23-07-99 GsU_03002919 03003919 23-07-99 GsU_03003919 03004919 23-07-99 GsU_03004919 03005919 23-07-99 GsU_03005919 0300091A 23-07-99 GsU_0300091a 0300191A 23-07-99 GsU_0300191a 0300291A 23-07-99 GsU_0300291a 0300391A 23-07-99 GsU_0300391a 0300491A 23-07-99 GsU_0300491a 0300591A 23-07-99 GsU_0300591a MIME_S 23-07-99 GsVNMIMeFunc GsRestoreOrgsVNMIMe SCANUNIT 23-07-99 GsScanUnit GsGetHeadpUnit SORTUNIT 23-07-99 GsSortUnit MAPUNIT 23-07-99 GsMapUnit *USTACK CMAPUNIT 23-07-99 GsMapCoordUnit LWUNIT 23-07-99 GsGetLwUnit LSUNIT 23-07-99 GsGetLsUnit LWSUNIT 23-07-99 GsGetLwsUnit VWUNIT 23-07-99 GsSetViewUnit RVWUNIT 23-07-99 GsSetRefViewUnit RVWLUNIT 23-07-99 GsSetRefViewLUnit LIBMATHBasic Maths library that supports floating point operations. Module Date Externals defined ADDDF3 23-07-99 __adddf3 ADDMANT 23-07-99 _add_mant_d ADDSF3 23-07-99 __addsf3 DBSHIFT 23-07-99 _dbl_shift DBSHIFTU 23-07-99 _dbl_shift_us DIVDF3 23-07-99 __divdf3 _comp_mant DIVSF3 23-07-99 __divsf3 EQDF2 23-07-99 __eqdf2 EQSF2 23-07-99 __eqsf2 EXTSFDF2 23-07-99 __extendsfdf2 FIXDFSI 23-07-99 __fixdfsi FIXSFSI 23-07-99 __fixsfsi FIXUDFSI 23-07-99 __fixunsdfsi FIXUSFSI 23-07-99 __fixunssfsi FLTSIDF 23-07-99 __floatsidf FLTSISF 23-07-99 __floatsisf GEDF2 23-07-99 __gedf2 GESF2 23-07-99 __gesf2 GTDF2 23-07-99 __gtdf2 GTSF2 23-07-99 __gtsf2 LEDF2 23-07-99 __ledf2 LESF2 23-07-99 __lesf2 LTDF2 23-07-99 __ltdf2 LTSF2 23-07-99 __ltsf2 MAINASU 23-07-99 _mainasu MULDF3 23-07-99 __muldf3 _mul_mant_d MULSF3 23-07-99 __mulsf3 NEDF2 23-07-99 __nedf2 NEGDF2 23-07-99 __negdf2 NEGSF2 23-07-99 __negsf2 NESF2 23-07-99 __nesf2 SUBDF3 23-07-99 __subdf3 SUBSF3 23-07-99 __subsf3 TRUDFSF2 23-07-99 __truncdfsf2 FERR 23-07-99 math_errno math_err_point _err_math ARC00 23-07-99 atan ARC01 23-07-99 atan2 ARC02 23-07-99 asin ARC03 23-07-99 acos EXP 23-07-99 exp FLOOR00 23-07-99 floor FLOOR01 23-07-99 ceil HYPOT 23-07-99 hypot LDEXP00 23-07-99 ldexp LDEXP01 23-07-99 frexp LOG00 23-07-99 log LOG01 23-07-99 log10 MODF00 23-07-99 modf MODF01 23-07-99 fmod POW 23-07-99 pow SIN00 23-07-99 tan sin SIN01 23-07-99 cos SINH00 23-07-99 sinh SINH01 23-07-99 cosh SINH02 23-07-99 tanh SQRT 23-07-99 sqrt PRINTF2 23-07-99 printf2 sprintf2 STRTOD00 23-07-99 atof STRTOD01 23-07-99 strtod LIBMCRD (Extended Memory card)Higher level library for using the playstation memory cards, higherlevel than libcard. Module Date Externals defined INIT 23-07-99 MemCardInit MemCardEnd LIBMCRD 23-07-99 PushCallbackFunc MemCardCallback PullCallbackFunc McrdGetGlobalStructure MemCardStart MemCardStop MemCardExist MemCardAccept MemCardOpen MemCardSync MemCardClose MemCardReadData MemCardWriteData MemCardReadFile MemCardWriteFile MemCardGetDirentry MemCardCreateFile MemCardFormat USERFUNC 23-07-99 UserFuncInit UserFuncOpen UserFuncExecute UserFuncComplete BIOS 23-07-99 funcEvSpIOE funcEvSpError funcEvSpTimeout funcEvSpNewcard funcEvSpIOEx funcEvSpErrorx funcEvSpTimeoutx funcEvSpNewcardx _card_open _card_start _clr_card_event _card_close _card_stop _get_card_event _get_card_event_x _chk_card_event _chk_card_event_x LOW 23-07-99 _card_format2 _card_create2 DELETE 23-07-99 MemCardDeleteFile UNFORMAT 23-07-99 MemCardUnformat LIBMCX - PocketStationProvides functions to control the PocketStation (a playstation memory card with a screen that can run ARM code) (referred to as PDA in the official developer documentation). Module Date Externals defined MCXCMD1 23-07-99 McxGetApl MCXCMD2 23-07-99 McxExecApl MCXCMD3 23-07-99 _mcxRxRestLen MCXCMD4 23-07-99 McxGetTime MCXCMD5 23-07-99 McxGetMem MCXCMD6 23-07-99 _mcxTxGetMem _mcxRxGetMem MCXCMD7 23-07-99 McxSetMem MCXCMD8 23-07-99 _mcxTxSetMem _mcxRxSetMem MCXCMD9 23-07-99 McxReadDev MCXCMD10 23-07-99 _mcxTxReadDev _mcxRxReadDev MCXCMD11 23-07-99 McxWriteDev MCXCMD12 23-07-99 _mcxTxWriteDev _mcxRxWriteDev MCXCMD13 23-07-99 McxSetTime MCXCMD14 23-07-99 McxGetUIFS MCXCMD15 23-07-99 McxSetUIFS MCXCMD16 23-07-99 McxShowTrans MCXCMD17 23-07-99 _mcxTxSetTrans MCXCMD18 23-07-99 McxHideTrans MCXCMD19 23-07-99 McxCurrCtrl MCXCMD20 23-07-99 McxFlashAcs MCXCMD21 23-07-99 McxGetSerial MCXCMD22 23-07-99 McxSetLED MCXCMD23 23-07-99 McxCardType McxGetMcxInfo MCXCMD24 23-07-99 McxAllInfo MCXCMD25 23-07-99 McxExecFlag MCXCMD26 23-07-99 McxGetInfo MCXCMD27 23-07-99 chkMemArea MCXRESI 23-07-99 _mcxTblCardEnt _mcxTblDsrEnt _mcxStat _mcxCmdSeq _mcxPort _mcxPass _mcxUIFSretry _mcxTxLen _mcxRxLen *_mcxFuncNo _mcxChkRsrv *_mcxRestSize _mcxStepSio *_mcxTxBuf *_mcxFuncGetTx *_mcxRxBuf *_mcxFuncApplyRx *_mcxDataLen *_mcxPtrBuff *_mcxSum *_mcxPtrCmdBuf0 *_mcxPtrCmdBuf1 *_mcxParam *_mcxFlag MCXINIT 23-07-99 McxStartCom McxStopCom MCXMAIN 23-07-99 _mcxDsrEntry _mcxInitSioMode _mcxSetRC2wait _mcxChkRC2wait _mcxSioRW McxSync MCXDSR 23-07-99 _mcxStartFastDsr _mcxStopFastDsr _mcxFastDsrEnt _mcxIntRestSize _mcxCallFromC _mcxVecDsr _mcxVecSave LIBPADThe LIBPAD.LIB library is used to interface with the game pads (controllers), including Dual shock controllers. Module Date Externals defined PDCMD1 23-07-99 PadSetAct PDCMD2 23-07-99 PadSetActAlign PDCMD3 23-07-99 PadSetMainMode PDENT1 23-07-99 PadChkMtap PDENT2 23-07-99 PadGetState PDENT3 23-07-99 PadInfoMode PDENT4 23-07-99 PadInfoAct PDENT5 23-07-99 PadInfoComb PDGUNRES 23-07-99 _padGunResultPtr _padGunHitCntPtr _padGunEnalePort _padGunMachType oldVcount _padSetIntH2000 _padGetGunPos *_padGunPosRecv _padSetGunPort *_padGunSavePadPtr *_padGunSaveTxBuf *_padGunSaveTxLen PDGN1INI 23-07-99 PadInitGun PDGN2INI 23-07-99 PadEnableGun PDGUN 23-07-99 PadRemoveGun PDMAIINI 23-07-99 PadStartCom PadStopCom PDMAIN1 23-07-99 PadEnableCom PDMAIN2 23-07-99 PadChkVsync PDDIRINI 23-07-99 PadInitDirect PDTAPINI 23-07-99 PadInitMtap PDDIRRES 23-07-99 _padInitDirPort _dirFailAuto PDTAPRES 23-07-99 _mtapLastResult _padInitMtapPort _mtapFailAuto PDRESRES 23-07-99 _padFuncNextPort _padFuncClrInfo _padFuncGetTxd _padFuncCurrLimit _padFuncPtr2Port _padFuncPort2Info _padFuncSendAuto _padFuncChkEng _padFuncRecvAuto _padFuncClrCmdNo _padFuncIntGun _padFuncSetGunPort _padFuncGetGunPos _padInfoDir _padIntExec _padGunExec _padSioChan _padSioState _padTotalCurr _padModeMtap _padChanStart _padChanStop _padFixResult _padVsyncParam _padIntPad _padIsVsync _padCalledIntPad *_padRestPeriod _padInitSioMode _padSetRC2wait _padChkRC2wait _padClrIntSio0 _padWaitRXready _padSioRW _padSioRW2 _padSetCmd _padSendAtLoadInfo _padRecvAtLoadInfo _padGetActSize _padLoadActInfo _padCmdParaMode PDHOKRES 23-07-99 *_padGunPosHbuf *_padGunPosVbuf _padGunInitHook _padGunExitHook _padGetHitCount _padClrHitCount LIBPressLIBPress is a compression library that can compress and decompress sound and image data using a few different compression algorithms such as DCT (Discrete Cosine Transform), BVQ (Block Vector Quantization) and Huffman Encoding. Module Date Externals defined LIBPRESS 23-07-99 DecDCTReset DecDCTGetEnv DecDCTPutEnv DecDCTin DecDCTout DecDCTinSync DecDCToutSync DecDCTinCallback DecDCToutCallback VLC 23-07-99 DecDCTvlcSize DecDCTvlc VLC_C 23-07-99 DecDCTvlcSize2 DecDCTvlc2 BUILD 23-07-99 DecDCTvlcBuild ENCSPU 23-07-99 EncSPU ENCSPU2 23-07-99 EncSPU2 TABLE 23-07-99 CF_DVLC CF2_DVLC DCT002 23-07-99 DecDCTBufSize TBL_001 23-07-99 DCL_DVLC TBL_002 23-07-99 DCC_DVLC LIBSIOLibSIO is a standard input output library for development kits to connect to and from PC,so you can write out debugging information to the PC. Module Date Externals defined SIOHANDL 23-07-99 *siobuf _sio_driver siocons DelSIO AddSIO LIBSIO 23-07-99 _cdevinput _cdevscan _circgetc _ioabort add_nullcon_driver SIO 23-07-99 _sio_control *cntl *mode *baud SIOCB 23-07-99 Sio1Callback LIBSNLibSN (Sn systems reference?) is a very low-level library for managing the stack pointer (SP along with access to the PC).It is used along with 2MByte and 8MByte.obj files. Module Date Externals defined OPEN 20-09-95 PCopen CLOSE 20-09-95 PCclose LSEEK 20-09-95 PClseek CREAT 20-09-95 PCcreat SNREAD 20-09-95 _SN_read SNMAIN 20-09-95 __bss __heapsize __SN_ENTRY_POINT __bsslen __data __main __text __datalen __textlen __do_global_dtors __heapbase FSINIT 20-09-95 PCinit SNWRITE 20-09-95 _SN_write READ 20-09-95 PCread WRITE 20-09-95 PCwrite SNDEF 20-09-95 _stacksize _ramsize PUREV 20-09-95 __pure_virtual CACHE 20-09-95 SNFlushCache _ASHLDI3 20-09-95 __ashldi3 _ASHRDI3 20-09-95 __ashrdi3 _CMPDI2 20-09-95 __cmpdi2 _DIVDI3 20-09-95 __divdi3 _EH 20-09-95 __throw_type_match __register_exceptions __find_first_exception_table_match _FFSDI2 20-09-95 __ffsdi2 _FXDFDI 20-09-95 __fixdfdi _FXSFDI 20-09-95 __fixsfdi _FXTFDI 20-09-95   _FXUSDFD 20-09-95 __fixunsdfdi _FIXUSDF 20-09-95 __fixunsdfsi _FXUSSFD 20-09-95 __fixunssfdi _FXUSSFS 20-09-95 __fixunssfsi _FXUSTFD 20-09-95   _FXUSXFD 20-09-95   _FXUSXFS 20-09-95   _FXXFDI 20-09-95   _FLTDIDF 20-09-95 __floatdidf _FLTDISF 20-09-95 __floatdisf _FLTDITF 20-09-95   _FLTDIXF 20-09-95   _LSHLDI3 20-09-95 __lshldi3 _LSHRDI3 20-09-95 __lshrdi3 _MODDI3 20-09-95 __moddi3 _MULDI3 20-09-95 __muldi3 _NEGDI2 20-09-95 __negdi2 _NEW_HAN 20-09-95 set_new_handler __new_handler __default_new_handler _OP_DELE 20-09-95 __builtin_delete _OP_NEW 20-09-95 __builtin_new _OP_VDEL 20-09-95 __builtin_vec_delete _OP_VNEW 20-09-95 __builtin_vec_new _SHTAB 20-09-95 __shtab _TRAMPOL 20-09-95   _UCMPDI2 20-09-95 __ucmpdi2 _UDIVDI3 20-09-95 __udivdi3 _UDIVMOD 20-09-95 __udivmoddi4 UDIV_W 20-09-95 __udiv_w_sdiv _UMODDI3 20-09-95 __umoddi3 _VARARGS 20-09-95 __builtin_saveregs __GCC_BC 20-09-95 __gcc_bcmp LIBSNDLibSND is the extended sound library that is at a higher level than the basic libspu, it can play VAB and SEQ audio files, along with a variety of different sound effects. Module Date Externals defined CCADSR 23-07-99 _SsUtResolveADSR _SsUtBuildADSR CC_0 23-07-99 _SsContBankChange CC_6 23-07-99 _SsContDataEntry CC_7 23-07-99 _SsContMainVol CC_10 23-07-99 _SsContPanpot CC_11 23-07-99 _SsContExpression CC_64 23-07-99 _SsContDamper CC_91 23-07-99 _SsContExternal CC_98 23-07-99 _SsContNrpn1 CC_99 23-07-99 _SsContNrpn2 CC_100 23-07-99 _SsContRpn1 CC_101 23-07-99 _SsContRpn2 CC_121 23-07-99 _SsContResetAll DE_0 23-07-99 _SsSetNrpnVabAttr0 DE_1 23-07-99 _SsSetNrpnVabAttr1 DE_2 23-07-99 _SsSetNrpnVabAttr2 DE_3 23-07-99 _SsSetNrpnVabAttr3 DE_4 23-07-99 _SsSetNrpnVabAttr4 DE_5 23-07-99 _SsSetNrpnVabAttr5 DE_6 23-07-99 _SsSetNrpnVabAttr6 DE_7 23-07-99 _SsSetNrpnVabAttr7 DE_8 23-07-99 _SsSetNrpnVabAttr8 DE_9 23-07-99 _SsSetNrpnVabAttr9 DE_10 23-07-99 _SsSetNrpnVabAttr10 DE_11 23-07-99 _SsSetNrpnVabAttr11 DE_12 23-07-99 _SsSetNrpnVabAttr12 DE_13 23-07-99 _SsSetNrpnVabAttr13 DE_14 23-07-99 _SsSetNrpnVabAttr14 DE_15 23-07-99 _SsSetNrpnVabAttr15 DE_16 23-07-99 _SsSetNrpnVabAttr16 DE_17 23-07-99 _SsSetNrpnVabAttr17 DE_18 23-07-99 _SsSetNrpnVabAttr18 DE_19 23-07-99 _SsSetNrpnVabAttr19 CRES 23-07-99 _SsSndCrescendo DECRES 23-07-99   MIDIBEND 23-07-99 _SsSetPitchBend MIDICC 23-07-99 _SsSetControlChange MIDIMETA 23-07-99 _SsGetMetaEvent MIDINOTE 23-07-99 _SsNoteOn MIDIPROG 23-07-99 _SsSetProgramChange MIDIREAD 23-07-99 _SsSeqPlay _SsGetSeqData _SsSeqGetEof MIDITIME 23-07-99 _SsReadDeltaValue NEXT 23-07-99 _SsSndNextSep NPAUSE 23-07-99 _SsSndNextPause PAUSE 23-07-99 _SsSndPause PLAY 23-07-99 _SsSndPlay REPLAY 23-07-99 _SsSndReplay SEPINIT 23-07-99 _SsInitSoundSep SEQINIT 23-07-99 _SsInitSoundSeq SSACCELE 23-07-99 _SsSndSetAccele SsSeqSetAccelerando SsSepSetAccelerando SSCALL 23-07-99 SsSeqCalledTbyT SSCLOSE 23-07-99 SsSeqClose SsSepClose SSCMUTE 23-07-99 SsChannelMute SSGCMUTE 23-07-99 SsGetChannelMute SSCRES 23-07-99 _SsSndSetCres SsSeqSetCrescendo SsSepSetCrescendo SSDECRES 23-07-99 _SsSndSetDecres SsSeqSetDecrescendo SsSepSetDecrescendo SSEND 23-07-99 SsEnd SSGM 23-07-99 SsGetMute SSGMV 23-07-99 SsGetMVol SSGNC 23-07-99 SsGetNck SSGRV 23-07-99 SsGetRVol SSGSATTR 23-07-99 SsGetSerialAttr SSGSV 23-07-99 SsGetSerialVol SSINIT 23-07-99 _snd_vmask _SsInit *_SsMarkCallback *VBLANK_MINUS *_snd_openflag *_snd_ev_flag *SsFCALL *_ss_score *_snd_seq_s_max *_snd_seq_t_max SSINIT_C 23-07-99 SsInit SSINIT_H 23-07-99 SsInitHot SSLOOP 23-07-99 SsSetLoop SSISEOS 23-07-99 SsIsEos SSMARK 23-07-99 SsSetMarkCallback SSNEXT 23-07-99 SsSetNext SSNEXT_2 23-07-99 SsSeqSetNext SSNOFF 23-07-99 SsSetNoiseOff SSNON 23-07-99 SsSetNoiseOn SSOPENP 23-07-99 SsSepOpen SSOPENQ 23-07-99 SsSeqOpen SSOPENPJ 23-07-99 SsSepOpenJ SSOPENQJ 23-07-99 SsSeqOpenJ SSPAUSE 23-07-99 _SsSndSetPauseMode SsSeqPause SsSepPause SSPLAY 23-07-99 SsSeqPlay SSPLAY_2 23-07-99 SsSepPlay SSPLAYB 23-07-99 SsPlayBack SSQUIT 23-07-99 SsQuit SSREPLAY 23-07-99 _SsSndSetReplayMode SsSeqReplay SsSepReplay PLAYMODE 23-07-99 Snd_SetPlayMode SSRIT 23-07-99 _SsSndSetRit SsSeqSetRitardando SsSepSetRitardando SSP 23-07-99 SsSeqSkip SSSP 23-07-99 SsSetCurrentPoint SSPPTP 23-07-99 SsSeqPlayPtoP SSSATTR 23-07-99 SsSetSerialAttr SSSM 23-07-99 SsSetMute SSSMV 23-07-99 SsSetMVol SSSNC 23-07-99 SsSetNck SSSRV 23-07-99 SsSetRVol SSSTART 23-07-99 _snd_seq_tick_env SsStart SsStart2 SSSTOP 23-07-99 _SsSndStop SsSeqStop SsSepStop SSSV 23-07-99 SsSetSerialVol SSTABLE 23-07-99 SsSetTableSize SSTEMPO 23-07-99 SsSetTempo SSTICK 23-07-99 SsSetTickMode SSTICKCB 23-07-99 SsSetTickCallback SSVKOFF 23-07-99 SsVoKeyOff SSVKON 23-07-99 SsVoKeyOn SSVOL 23-07-99 _SsSndSetVol SsSeqSetVol SsSepSetVol SSVOL_2 23-07-99 SsSeqGetVol TEMPO 23-07-99 _SsSndTempo VOL 23-07-99 _SsSndSetVolData DMYNOT1 23-07-99 dmy_nothing1 DMYNOTE 23-07-99 dmy_SsNoteOn DMYPROG 23-07-99 dmy_SsSetProgramChange DMYMETA 23-07-99 dmy_SsGetMetaEvent DMYBEND 23-07-99 dmy_SsSetPitchBend DMYCC 23-07-99 dmy_SsSetControlChange DMYCC_0 23-07-99 dmy_SsContBankChange DMYCC_6 23-07-99 dmy_SsContDataEntry DMYCC_7 23-07-99 dmy_SsContMainVol DMYCC_10 23-07-99 dmy_SsContPanpot DMYCC_11 23-07-99 dmy_SsContExpression DMYCC_64 23-07-99 dmy_SsContDamper DMYCC_91 23-07-99 dmy_SsContExternal DMYCC_98 23-07-99 dmy_SsContNrpn1 DMYCC_99 23-07-99 dmy_SsContNrpn2 DMYCC100 23-07-99 dmy_SsContRpn1 DMYCC101 23-07-99 dmy_SsContRpn2 DMYCC121 23-07-99 dmy_SsContResetAll DMYDE_0 23-07-99 dmy_SsSetNrpnVabAttr0 DMYDE_1 23-07-99 dmy_SsSetNrpnVabAttr1 DMYDE_2 23-07-99 dmy_SsSetNrpnVabAttr2 DMYDE_3 23-07-99 dmy_SsSetNrpnVabAttr3 DMYDE_4 23-07-99 dmy_SsSetNrpnVabAttr4 DMYDE_5 23-07-99 dmy_SsSetNrpnVabAttr5 DMYDE_6 23-07-99 dmy_SsSetNrpnVabAttr6 DMYDE_7 23-07-99 dmy_SsSetNrpnVabAttr7 DMYDE_8 23-07-99 dmy_SsSetNrpnVabAttr8 DMYDE_9 23-07-99 dmy_SsSetNrpnVabAttr9 DMYDE_10 23-07-99 dmy_SsSetNrpnVabAttr10 DMYDE_11 23-07-99 dmy_SsSetNrpnVabAttr11 DMYDE_12 23-07-99 dmy_SsSetNrpnVabAttr12 DMYDE_13 23-07-99 dmy_SsSetNrpnVabAttr13 DMYDE_14 23-07-99 dmy_SsSetNrpnVabAttr14 DMYDE_15 23-07-99 dmy_SsSetNrpnVabAttr15 DMYDE_16 23-07-99 dmy_SsSetNrpnVabAttr16 DMYDE_17 23-07-99 dmy_SsSetNrpnVabAttr17 DMYDE_18 23-07-99 dmy_SsSetNrpnVabAttr18 DMYDE_19 23-07-99 dmy_SsSetNrpnVabAttr19 SSGCP 23-07-99 SsGetCurrentPoint SSVM 23-07-99 SsSetVoiceMask SSVM_2 23-07-99 SsGetVoiceMask UT_AKO 23-07-99 SsUtAllKeyOff UT_AUTOP 23-07-99 SsUtAutoPan UT_AUTOV 23-07-99 SsUtAutoVol UT_CADSR 23-07-99 SsUtChangeADSR UT_CP 23-07-99 SsUtChangePitch UT_F 23-07-99 SsUtFlush UT_GPA 23-07-99 SsUtGetProgAtr UT_GVA 23-07-99 SsUtGetVagAtr UT_GVAD 23-07-99 SsUtGetVagAddr UT_GVAFT 23-07-99 SsUtGetVagAddrFromTone UT_GVBA 23-07-99 SsUtGetVBaddrInSB UT_GVH 23-07-99 SsUtGetVabHdr UT_KEY 23-07-99 SsUtKeyOn SsUtKeyOff UT_KEYV 23-07-99 SsUtKeyOnV SsUtKeyOffV UT_PB 23-07-99 SsUtPitchBend UT_RDEL 23-07-99 SsUtSetReverbDelay UT_RDEP 23-07-99 SsUtSetReverbDepth UT_REV 23-07-99 SsUtSetReverbType UT_REV_2 23-07-99 SsUtGetReverbType UT_RFB 23-07-99 SsUtSetReverbFeedback UT_ROFF 23-07-99 SsUtReverbOff UT_RON 23-07-99 SsUtReverbOn UT_SPA 23-07-99 SsUtSetProgAtr UT_SVA 23-07-99 SsUtSetVagAtr UT_SVH 23-07-99 SsUtSetVabHdr UT_VVOL 23-07-99 SsUtGetDetVVol UT_VVOL2 23-07-99 SsUtSetDetVVol UT_VVOL3 23-07-99 SsUtGetVVol UT_VVOL4 23-07-99 SsUtSetVVol VM_ALOC1 23-07-99 _SsVmAlloc VM_ALOC2 23-07-99 _SsVmDoAllocate VM_AUTOP 23-07-99 SeAutoPan SetAutoPan VM_AUTOV 23-07-99 SeAutoVol SetAutoVol VM_DOFF 23-07-99 _SsVmDamperOff VM_DON 23-07-99 _SsVmDamperOn VM_F 23-07-99 _SsVmFlush *_svm_envx_ptr *_svm_envx_hist *_svm_voice *_svm_okof1 *_svm_okon1 *_svm_okof2 *_svm_okon2 *_autovol *_autopan *_svm_sreg_dirty *_svm_sreg_buf *_svm_orev2 *_svm_orev1 *_svm_onos2 *_svm_onos1 VM_G 23-07-99 *_svm_stereo_mono *_svm_vab_not_send_size *_svm_rattr *_svm_vab_used *_SsVmMaxVoice *_svm_vab_count *kMaxPrograms *_svm_cur *_svm_damper *_svm_auto_kof_mode *_svm_vab_vh *_svm_vab_pg *_svm_vab_tn *_svm_vab_start *_svm_vab_total *_svm_vh *_svm_pg *_svm_tn *_svm_vg VM_INIT 23-07-99 _SsVmInit VM_KEY 23-07-99 _SsVmKeyOn _SsVmKeyOff _SsVmSeKeyOn _SsVmSeKeyOff VM_KEY_2 23-07-99 KeyOnCheck VM_N2P 23-07-99 note2pitch SsPitchFromNote note2pitch2 VM_NO1 23-07-99 vmNoiseOn VM_NO2 23-07-99 vmNoiseOn2 VM_NOFF 23-07-99 vmNoiseOff VM_NOISE 23-07-99 _SsVmNoiseOnWithAdsr _SsVmNoiseOn VM_NOIS2 23-07-99 _SsVmNoiseOff VM_NOWOF 23-07-99 _SsVmKeyOffNow VM_NOWON 23-07-99 _SsVmKeyOnNow VM_PB 23-07-99 _SsVmPBVoice _SsVmPitchBend VM_PORTA 23-07-99   VM_PROG 23-07-99 _SsVmGetProgVol _SsVmSetProgPan _SsVmGetProgPan VM_PROG2 23-07-99 _SsVmSetProgVol VM_SEQ 23-07-99 _SsVmSetSeqVol _SsVmGetSeqVol _SsVmSeqKeyOff VM_SEQ_2 23-07-99 _SsVmGetSeqLVol _SsVmGetSeqRVol VM_SPB 23-07-99 SePitchBend VM_STAV 23-07-99 _SsVmSelectToneAndVag VM_VIB 23-07-99 SeVibOn SetVib SsUtVibrateOn SsUtVibrateOff VM_VOL 23-07-99 _SsVmSetVol VM_VSU 23-07-99 _SsVmVSetUp VS_AUTO 23-07-99 SsSetAutoKeyOffMode VS_MONO 23-07-99 SsSetMono SsSetStereo VS_SRV 23-07-99 SsSetReservedVoice VS_VAB 23-07-99 SsVabClose VS_VFB 23-07-99 SsVabFakeBody VS_VH 23-07-99 SsVabOpenHeadSticky _SsVabOpenHeadWithMode SsVabFakeHead VS_VH2 23-07-99 SsVabOpenHead VS_VT 23-07-99 SsVabTransfer VS_VTB 23-07-99 SsVabTransBody VS_VTBP 23-07-99 SsVabTransBodyPartly VS_VTC 23-07-99 SsVabTransCompleted VM_ALOC3 23-07-99 SsBlockVoiceAllocation VM_ALOC4 23-07-99 SsUnBlockVoiceAllocation VM_ALOC5 23-07-99 SsAllocateVoices Q_KEYON 23-07-99 SsQueueKeyOn Q_KEYON2 23-07-99 SsQueueReverb Q_KEYON3 23-07-99 SsQueueRegisters Q_KEYON4 23-07-99 SsGetActualProgFromProg Q_KEYON5 23-07-99 SsSetVoiceSettings Q_KEYON6 23-07-99 SsVoiceCheck LIBSPUThe basic sound library for contacting the Sound processing Unit (SPU). Module Date Externals defined SPU 23-07-99 spu_RXX _spu_tsa _spu_transMode _spu_addrMode _spu_mem_mode _spu_mem_mode_plus _spu_mem_mode_unit _spu_mem_mode_unitM _spu_inTransfer _spu_transferCallback _spu_IRQCallback _spu_init _spu_Fw1ts *_spu_RQ _spu_FiDMA _spu_Fr _spu_t _spu_Fw _spu_Fr _spu_FsetRXX _spu_FsetRXXa _spu_FgetRXXa _spu_FsetPCR S_CB 23-07-99 _SpuCallback S_DCB 23-07-99 _SpuDataCallback SPU_GEX 23-07-99   S_INI 23-07-99 _spu_EVdma _spu_keystat _spu_trans_mode _spu_rev_flag _spu_rev_reserve_wa _spu_rev_offsetaddr _spu_rev_attr _spu_RQvoice _spu_RQmask _spu_voice_centerNote _spu_env _SpuInit SpuStart _spu_isCalled S_I 23-07-99 SpuInit S_IH 23-07-99 SpuInitHot S_Q 23-07-99 SpuQuit S_SM 23-07-99 SpuSetMute S_GM 23-07-99 SpuGetMute S_M 23-07-99 _spu_AllocBlockNum _spu_AllocLastNum _spu_memList S_M_INT 23-07-99 _spu_gcSPU S_M_INIT 23-07-99 SpuInitMalloc S_M_UTIL 23-07-99 SpuIsInAllocateArea _SpuIsInAllocateArea S_M_M 23-07-99 SpuMalloc S_M_WSA 23-07-99 SpuMallocWithStartAddr S_M_F 23-07-99 SpuFree S_M_X 23-07-99 _spu_print S_SE 23-07-99 SpuSetEnv S_F 23-07-99 SpuFlush ZEROBUF 23-07-99 _spu_zerobuf S_SAV 23-07-99 _SpuSetAnyVoice S_GAV 23-07-99 _SpuGetAnyVoice S_SNV 23-07-99 SpuSetNoiseVoice S_GNV 23-07-99 SpuGetNoiseVoice S_SNC 23-07-99 SpuSetNoiseClock S_GNC 23-07-99 SpuGetNoiseClock S_SR 23-07-99 SpuSetReverb S_GR 23-07-99 SpuGetReverb S_SRMP 23-07-99 SpuSetReverbModeParam S_GRMP 23-07-99 SpuGetReverbModeParam S_SRA 23-07-99 _spu_setReverbAttr S_RRWA 23-07-99 SpuReserveReverbWorkArea S_IRWAR 23-07-99 SpuIsReverbWorkAreaReserved S_SRD 23-07-99 SpuSetReverbDepth S_SRV 23-07-99 SpuSetReverbVoice S_GRV 23-07-99 SpuGetReverbVoice S_CRWA 23-07-99 SpuClearReverbWorkArea S_RDD 23-07-99 SpuReadDecodedData S_SI 23-07-99 SpuSetIRQ S_GI 23-07-99 SpuGetIRQ S_SIA 23-07-99 SpuSetIRQAddr S_GIA 23-07-99 SpuGetIRQAddr S_SIC 23-07-99 SpuSetIRQCallback S_SK 23-07-99 SpuSetKey S_GKS 23-07-99 SpuGetKeyStatus S_SKOWA 23-07-99 SpuSetKeyOnWithAttr S_GVEA 23-07-99 SpuGetVoiceEnvelopeAttr S_R 23-07-99 SpuRead S_W 23-07-99 SpuWrite S_W0 23-07-99 SpuWrite0 S_STSA 23-07-99 SpuSetTransferStartAddr S_GTSA 23-07-99 SpuGetTransferStartAddr S_STM 23-07-99 SpuSetTransferMode S_GTM 23-07-99 SpuGetTransferMode S_WP 23-07-99 SpuWritePartly S_ITC 23-07-99 SpuIsTransferCompleted S_STC 23-07-99 SpuSetTransferCallback S_IT 23-07-99 _spu_setInTransfer _spu_getInTransfer S_SPLV 23-07-99 SpuSetPitchLFOVoice S_GPLV 23-07-99 SpuGetPitchLFOVoice S_GCA 23-07-99 SpuGetCommonAttr S_N2P 23-07-99 _spu_note2pitch _spu_pitch2note SR_GAKS 23-07-99 SpuRGetAllKeysStatus SpuGetAllKeysStatus ST 23-07-99 SpuStTransfer SpuStInit SpuStQuit SpuStGetStatus SpuStGetVoiceStatus SpuStSetPreparationFinishedCallback SpuStSetTransferFinishedCallback SpuStSetStreamFinishedCallback T_C 23-07-99 TimerCallback VERSION 23-07-99   S_SESA 23-07-99 SpuSetESA S_SVV 23-07-99 SpuSetVoiceVolume S_SVVA 23-07-99 SpuSetVoiceVolumeAttr S_SVP 23-07-99 SpuSetVoicePitch S_SVN 23-07-99 SpuSetVoiceNote S_SVSN 23-07-99 SpuSetVoiceSampleNote S_SVSA 23-07-99 SpuSetVoiceStartAddr S_SVLSA 23-07-99 SpuSetVoiceLoopStartAddr S_SVAR 23-07-99 SpuSetVoiceAR S_SVDR 23-07-99 SpuSetVoiceDR S_SVSR 23-07-99 SpuSetVoiceSR S_SVRR 23-07-99 SpuSetVoiceRR S_SVSL 23-07-99 SpuSetVoiceSL S_SVARA 23-07-99 SpuSetVoiceARAttr S_SVSRA 23-07-99 SpuSetVoiceSRAttr S_SVRRA 23-07-99 SpuSetVoiceRRAttr S_SVAD 23-07-99 SpuSetVoiceADSR S_SVADA 23-07-99 SpuSetVoiceADSRAttr S_SVA 23-07-99 SpuSetVoiceAttr SR_SVA 23-07-99 SpuRSetVoiceAttr SN_SVA 23-07-99 SpuNSetVoiceAttr SL_SVA 23-07-99 SpuLSetVoiceAttr S_GVV 23-07-99 SpuGetVoiceVolume S_GVVA 23-07-99 SpuGetVoiceVolumeAttr S_GVVX 23-07-99 SpuGetVoiceVolumeX S_GVP 23-07-99 SpuGetVoicePitch S_GVN 23-07-99 SpuGetVoiceNote S_GVSN 23-07-99 SpuGetVoiceSampleNote S_GVEX 23-07-99 SpuGetVoiceEnvelope S_GVSA 23-07-99 SpuGetVoiceStartAddr S_GVLSA 23-07-99 SpuGetVoiceLoopStartAddr S_GVAR 23-07-99 SpuGetVoiceAR S_GVDR 23-07-99 SpuGetVoiceDR S_GVSR 23-07-99 SpuGetVoiceSR S_GVRR 23-07-99 SpuGetVoiceRR S_GVSL 23-07-99 SpuGetVoiceSL S_GVARA 23-07-99 SpuGetVoiceARAttr S_GVSRA 23-07-99 SpuGetVoiceSRAttr S_GVRRA 23-07-99 SpuGetVoiceRRAttr S_GVAD 23-07-99 SpuGetVoiceADSR S_GVADA 23-07-99 SpuGetVoiceADSRAttr S_SCMV 23-07-99 SpuSetCommonMasterVolume S_SCMVA 23-07-99 SpuSetCommonMasterVolumeAttr S_SCCV 23-07-99 SpuSetCommonCDVolume S_SCCR 23-07-99 SpuSetCommonCDReverb S_SCCM 23-07-99 SpuSetCommonCDMix S_GCMV 23-07-99 SpuGetCommonMasterVolume S_GCMVX 23-07-99 SpuGetCommonMasterVolumeX S_GCMVA 23-07-99 SpuGetCommonMasterVolumeAttr S_GCCV 23-07-99 SpuGetCommonCDVolume S_GCCR 23-07-99 SpuGetCommonCDReverb S_GCCM 23-07-99 SpuGetCommonCDMix S_SCA 23-07-99 SpuSetCommonAttr S_SCERR 23-07-99 *SpuCommonError S_SRMT 23-07-99 SpuSetReverbModeType S_SRMD 23-07-99 SpuSetReverbModeDepth S_SRMDT 23-07-99 SpuSetReverbModeDelayTime S_SRMFB 23-07-99 SpuSetReverbModeFeedback S_GRMT 23-07-99 SpuGetReverbModeType S_GRMD 23-07-99 SpuGetReverbModeDepth S_GRMDT 23-07-99 SpuGetReverbModeDelayTime S_GRMFB 23-07-99 SpuGetReverbModeFeedback S_GVA 23-07-99 SpuGetVoiceAttr SN_GVA 23-07-99 SpuNGetVoiceAttr S_RMP0 23-07-99 _spu_rev_startaddr S_RMP1 23-07-99 _spu_rev_workareasize S_RMP2 23-07-99 _spu_rev_param LIBTAPThe Playstation Multi-Tap library that allows 8 players to connect to one playstation with their controller and memory card. Module Date Externals defined TAP 22-09-97 InitTAP StartTAP StopTAP SendTAP EnableTAP DisableTAP Function Names in linking orderInitTAPStartTAPStopTAPSendTAPEnableTAPDisableTAPbzeroPAD_drEnterCriticalSectionExitCriticalSectionSysEnqIntRPSysDeqIntRPChangeClearRCnt", "excerpt": "Note that the order of the externals defined in this list will not reflect the order in the final linked executable, as the order here is just the order that the PSYLIB.EXE tool exports in. LIBAPI - PS1 OS Kernel API The LIBAPI.LIB file is required in all PS1 executables...", "tags": ["ps1","sdk","symbols"], "image": "/public/psyqlibs.png", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Sony Playstation 2", "url": "/ps2", "content": "IntroductionWelcome to our page dedicated to PS2 reverse engineering! The PlayStation 2 was a gaming console released by Sony in 2000, and has since become a beloved classic of the gaming world. If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to the right place.On this page, we’ve compiled a list of links to other pages that cover various topics related to PS2 reverse engineering. Whether you’re interested in understanding the hardware architecture of the console, analyzing game code, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to.So grab your DualShock controller, and get ready to dive into the exciting world of PS2 reverse engineering!Game Software Development for the Sony Playstation 2How long did it take to develop PS2 games back in the day?In Postmortems from Game Developer, one LucasArts PlayStation 2 production released in February 2001 is described as taking 30 months to complete 1.At the height of production, the team had approximately 40 full-time developers 1.The postmortem also provides a useful snapshot of a relatively large early-PS2 production: Schedule - 30 months of development Team size - Approximately 40 full-time developers at peak production Project scale - 301,000 lines of code, including internal tools Development hardware - 700MHz Pentium III PCs with 256MB of RAM, GeForce 256 graphics cards, and dedicated PS2 tools Software stack - Windows 2000, Microsoft Visual C++, Metrowerks for PS2, 3D Studio Max, Softimage, Photoshop, Bryce, Visual SourceSafe, Perl, AfterEffects, and Premiere Specialized technology - The Eve level design tool, Miles Sound System, ObjectSpace STL, Macromedia/Secret Level Flash, and Planet Blue’s Tulip for prerendered cut-scene lip-syncingHardwareSimilar to the original PlayStation the PS2 used a MIPS processor but this time it was 64 bit and codenamed the Emotion Engine, along with 2 custom vector processors. Although the PS2 has a much more modern GPU design compared to the PS1, the actual transformation of the vertices were still being process by the CPU core rather than the GPU 2.The main components of the PS2 hardware were: Emotion Engine (EE) - (64 bit MIPS processor + 2 vector processors) Graphics Synthesiser (GS) - 4MB with features such as Z-buffer, trilinear texturing and Gourard shading 2 Sound Processor (SPU2) - 48-Channel sound chip Image processing Unit (IPU) - Decodes MPEG2 streamsRetail HardwareFor an in-depth look at the PlayStation 2 Retail hardware architecture check out the excellent post by Copetti.org: PlayStation 2 Architecture - A Practical Analysis Copetti.org has an excellent tear down of the PlayStation 2 Hardware and how it works What were the specs of the PS2?Display Specs: Supports 480p progressive MPEG-2 Full Motion Video (FMV)Sound Specs: Dolby pro logic 2 (5.1 Surround sound) DTS Streaming AudioMax Game Specs Per frame: 120,000 and 6,000 tris 3Mb of Textures Frame rate of 30 or 60fpsEmotion EngineThe Emotion Engine was used for Game Logic and had the following: 32MB RAM MIPS 59k CPUGraphic Synthesiser (GS)Used for rendering and vertex transformation: 4MB RAM 2.4 GPixel/sec Support for Mip-mapping and alpha blending Texture formats: 32/24/16/8/4I/O Processor (IOP)Used for Interaction with peripherals (Memory cards, usb devices, Networking, Audio, DVD etc) 2MB RAM (8MB on a devkit) Playstation 1 on a chip (used for playing PS1 games) 36.9 MhzSerial Interface (SIF)The Serial Interface (SIF) is used to Interface between the Emotion Engine (EE) and the I/O processor (IOP) SIFDMA - transfer memory to other processor CIFCMD - run a command on the other processor such as setting flags SIFRPC - run remote operations on the other processor, includes a return valueExample of SIF in actionAn example of using the SIF to communicate between both processors is the controller pad libraries. We want to communicate between libpad.a which runs on the Emotion Engine and padman.irx which runs on the I/O Processor.So during the VBlank period the IOP Padman.irx uses SIFDMA to send controller information (such as which buttons are pressed) to the Emotion Engine.The Emotion Engine can then request this information by calling the API scePadReadDevelopment HardwareThe hardware used to develop PlayStation 2 games was similar but had an increase in memory along with a few debugging features. The details are covered in a separate post: Sony PlayStation 2 Development Kit (Hardware) For information about Sony’s PlayStation Two development hardware check out this post. Later in the PS2’s lifetime SN Systems released a specific development kit for developing online multiplayer PS2 games compatible with the PS2 Modem called the Network Development Kit (NDK). SN Systems Network Development Kit for PS2 For information about Network Development Kit development hardware check out this post. Third Party HardwarePlayStation 2 Olympus Eye-Trek FMD-20Olympus managed to get an official license for “VR goggles” specifically for the PS2 which were supposed to simulate a 52 inch tv floating in front of your eyes. Sounds like a great idea for a cheaper large screen tv without taking all the space, however prolonged use did cause headaches due to only having 180k pixels per eye, much lower than modern VR headsets.Review from PSi2 magazine issue 18:GamesWhat would the Sony Playstation 2 be without its excellent line-up of games? It was huge line up of third party games that attracted many people away from the Nintendo Gamecube and Microsoft Xbox.Playstation 2 Games with Debug SymbolsAn excellent way to start reverse engineering is to find games where the developers accidentally left the Debug symbols in the retail release of the game. This was surprisingly common in early PS2 games as the SDK didn’t remove them when building the final executables. These gives you access to all the original function and variables names that were used in the retail source code so are very valuable for reversers! PS2 Games with Debug Symbols (UnStripped Binaries) For a full list of PS2 games that have debug symbols check out this post. Playstation 2 Demos with Debug Symbols PS2 Demo Disks with Debug Symbols For a full list of PS2 games that have debug symbols check out this post. Playstation 2 ExclusivesThe most valuable reverse engineering projects tend to be the platform exclusives that have never been re-released as these are the games that can benefit the most from enhancements on modern hardware.Wikipedia maintains a list of games exclusive to the Playstation 2 - PlayStation 2-only games - WikipediaSoftware Development KitsOfficial Software development kitThe Official Software development kit was developed by a partnership between SN Systems who are known for excellent 3rd party development kits and the Game Studio Psygnosis who are known for excellent quality games. PS2 Official Software Development Kit (SDK) For information about Sony’s Playstation Two SDK check out this post. Emotion Engine Static LibrariesThe Playstation 2 Software Development kit included various statically compiled libraries that could be optionally included in your games, these ranged from vital (gcc runtime) to optional such as Multi-tap support. Static Libraries (.A) for Playstation 2 Emotion Engine For a list of all the static libraries inside the PS2 SDK check out this post. Emotion Engine Relocatable Executable (.ERX) FilesThis was a newer format introduced by Sony which can be used to provide patches for online PS2 games according to a GDC advert from Metrowerks Codewarrior 3.IOP Relocatable Executable Executable (.IRX) Files IRX Files for Playstation 2 For a list of all the dynamic libraries inside the PS2 SDK and from third parties check out this post. Consumer Development KitsPlaystation 2 LinuxSimilar to how the PS1 had Net Yaroze for consumers to develop small games for the Playstation, the PS2 had special software that ran a build of Linux. The software ran on consumer PS2 models and came with a PS2 hard-drive.Homebrew PS2 Software Development KitsAthena - Javascript on the PS2Athena is an environment that acts as a native PS2 program (written in C) which embeds a modified version of the QuickJS engine to interpret and run JavaScript code on the console.JSLegendDev has a good video covering the basic of the engine, showing how to show a 2D Sonic sprite, move it around with the controller and text rendering:Creative Software used to create PS2 Games3D Studio Max3D Studio Max and Character Studio was used by Runecraft software to develop games such as Premier manager on the PS24.We have a separate post on 3D Studio Max which you can find below: 3D Studio (Max) For more information on 3D Studio Max check out this post. Photoshop - industry standard for PS2 TexturingPhotoshop was used by Runecraft software to develop games such as Premier manager on the PS2.In issue 20 of PSi2 magazine there is an interview with Mark Edwards from Runecraft where he talks about using Photoshop for Premier manager on the PS2 along with a low-resolution screenshot you can see below 4:Game Engines for the PS2Before Unity and the modern Unreal Engine dominated the scene it was common for developers to create their own in-house game engine, or license a third party engine such as Renderware.Brainstorm by BeyondGames (in-house)In issue 20 of PSi2 an interview with Clark Stacey revealed that they have an in-house game engine called Brainstorm which was used for racing games such as Motor Mayhem and Hot Wheels 4. It also mentioned that it in theory has support for other genres of games such as platformers and that it has built in networking support.Merkury engine by Krome Studios (in-house)Krome Studios used the Merkury Engine for many of its own titles, particularly on the PS2 and other last-generation systems: Ty the Tasmanian Tiger (2002) - The first in the franchise and a flagship Merkury title. Sunny Garcia Surfing (2001) - Credited engine programmers in the manual. The Adventures of Jimmy Neutron: Jet Fusion (2003) - Confirmed via file analysis. King Arthur (2004) Ty the Tasmanian Tiger 2: Bush Rescue (2004) Ty the Tasmanian Tiger 3: Night of the Quinkan (2005) The Legend of Spyro: A New Beginning (2006) - Developed by Krome for the PS2, Xbox, GameCube, and GBA. The Legend of Spyro: The Eternal Night (2007) - Developed by Krome for the PS2 and Wii. Star Wars: The Force Unleashed (2008) - The PS2, PSP, and Wii versions were custom-built by Krome using Merkury. Star Wars: The Clone Wars – Republic Heroes (2009) - Included a PS2 version. Transformers: Revenge of the Fallen (2009) - The PS2 and Wii versions were developed by Krome Studios.If you are interested in learning more we have a specific post about the Merkury engine: Krome Studios Merkury Engine The Merkury engine is a proprietary game engine developed by Krome Studios since at least 2001, known to run on PS2, PSP, Wii and with version 3 of the engine... All Posts Capcom Leaks On 1st November 2020 CAPCOM was targeted by known hacker group RagnarLeaks and some source code and private data was leaked to the dark web. This post will only cover... ... Read More leak ps1 ps2 wii Static Libraries (.A) for Playstation 2 Emotion Engine This post will cover the programming libraries that were provided by the Official PS2 SDK for the Emotion Engine (the main processor for the PS2). Main Emotion Engine SDK libraries... ... Read More ps2 sdk PS2 Demo Disks with Debug Symbols This page is dedicated to listing Playstation 2 Demo Discs that contain developer debug symbols, either embedded inside the executable or as separate .map or .sym files. It was much... ... Read More ps2 symbols games PS2 Official Software Development Kit (SDK) PS2 Official Software development Kit by Sony Last known version: 3.1.0 1 First known version: 0.3.0 2 Updates were provided to licenced PlayStation developers on ps2-pro.com, where the update contained... ... Read More ps2 symbols sdk Sony PlayStation 2 Development Kit (Hardware) This post covers the hardware used to develop Playstation 2 games by major studios back in the day, for the software side see the post on the Official PS2 SDK.... ... Read More ps2 hardware devkit PS2 Games with Debug Symbols (UnStripped Binaries) Debug symbols are normally a rare treasure sought by reverse engineers from prototypes and beta versions of games, however in the early years of the PS2 it was common for... ... Read More ps2 symbols games SN Systems Network Development Kit for PS2 History of the SN Systems NDK for PS2 First mentioned on the official SN Systems website on the 10th November 2000 the PS2 Network Development Kit (NDK) was a software... ... Read More ps2 snsystems sdk The Simpsons Hit & Run Source Code Leak Introduction On the 21st August 2021 the full source code to the classic GTA clone staring The Simpsons was released online. This included both the C++ source code plus the... ... Read More ps2 xbox gamecube leak IRX Files for Playstation 2 Introduction If you are interested in the Playstation 2, especially reversing or developing games for it, you will eventually come across files with the .IRX extension. What are IRX Files?... ... Read More ps2 sdk References Postmortems from Game Developer (Austin Grossman, 2003) Page 299 ↩ ↩2 20 Years of PlayStation®. Console development past and future - Unite Europe 2015 - YouTube ↩ ↩2 GDC 2004 Evolve ↩ Psi2 issue 20 ↩ ↩2 ↩3 ", "excerpt": "Introduction Welcome to our page dedicated to PS2 reverse engineering! The PlayStation 2 was a gaming console released by Sony in 2000, and has since become a beloved classic of the gaming world. If you’re interested in learning more about the technical aspects of this console and how it works,...", "tags": ["ps2"], "image": "/public/generated/placeholders/ps2.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "PS2 Demo Disks with Debug Symbols", "url": "/ps2-demos", "content": "This page is dedicated to listing Playstation 2 Demo Discs that contain developer debug symbols, either embedded inside the executable or as separate .map or .sym files.It was much more common for PS2 debug symbols to be leaked on Demo Discs than their retail counterparts during the early days of the PS2 lifespan, later in the lifespan demos with Debug symbols became rarer and rarer.Which games were likely to have debug symbols?Most games found with debug symbols on this list are using the PS2 SDK about 2.1.0 and below 2.5.2 so its possible that after that version they started stripping the symbols by default on demo builds, or maybe the people who created the demo discs got stricter for looking for them. Although there are some exceptions to this rule, there are a few games using PS2 SDK 3.0.0 that accidentally left a .MAP file of symbols somewhere on the disc (rather than in the executable), so it wasn’t fool proof.PS2 Demo Discs from Official PlayStation 2 Magazine in EuropeThe Official PlayStation 2 Magazine in the UK and Europe often had a playable PS2 Demo free with every magazine, this was a great way for games to ‘try before you buy’. Many of the same discs were pressed and then released throughout Europe with their own localised version of the magazine. However there were some variations based on local region restrictions and trademarks etc, so we include the SCED code along with any referenced demo disc on this page so its easier to track down the demo you are looking for.You can find out more about these Demo Discs including scans of each of the covers and discs over at crimson-ceremony.net: demo pals - OPS2M Demo UK.List of demo games that contain debug symbolsThe table below has a list of all the playable game demos that we have confirmed have debug symbols inside them, although we have only managed to search Demo Disc 10->31 so far. So if you have any of the demos then please help by contributing to the list! Demo Disc Game PS2 SDK Debug Info? 10 - August 2001, SCED_50145) Le Mans 24 Hours 2.1.4 Full Debug Symbols! Plus a zip file that is actually multiple zips concatenated together 10 - August 2001, SCED_50145) Gauntlet Dark Legacy 2.1.0 Full Debug Symbols! 10 - August 2001, SCED_50145) GT3 Quiz 2.2.4 Full Debug Symbols! 11 - September 2001 SCED_50146 Lotus Challenge 2.1.4 2,837 Debug Symbols 12 - October 2001 SCED_50147 MX Rider 2.1.0 10,586 Debug Symbols 12 - October 2001 SCED_50147 Portal Runner 2.1.4 5,101 Debug Symbols 12 - October 2001 SCED_50147 Spy Hunter 2.1.0 11,268 Debug Symbols 12 - October 2001 SCED_50147 Soul Reaver 2 2.1.4 4,376 Debug Symbols 13 - November 2001 SCED_50148 NBA Street 2.1.0 9,125 Debug Symbols, also contains C++ header .h for animation files 13 - November 2001 SCED_50148 Driven 2.2.4 7,752 Debug Symbols 13 - November 2001 SCED_50148 MX 2002 2.1.4 4,892 Debug Symbols 13 - November 2001 SCED_50148 SplashDown MPEG Player 2.3.0 947 Debug Symbols 14 - December 2001 SCED_50149 AirBlade 2.3.2 3,962 Debug Symbols 14 - December 2001 SCED_50149 Dark Cloud 2.1.1 3,952 Debug Symbols 14 - December 2001 SCED_50149 Tarzan Freeride 2.2.4 10,588 Debug Symbols 15 - Christmas 2001 SCED_50150J GTC: Africa 2.2.4 Full Debug Symbols (2.5mb elf) 15 - Christmas 2001 SCED_50150J Lotus Challenge 2.1.4 Full Debug Symbols (1.8mb elf) 15 - Christmas 2001 SCED_50150J Jak and Daxter 2.2.1 880 Debug Symbols (incomplete) (532kb elf) 15 - Christmas 2001 SCED_50150J Extreme-G 3 2.1.4 2,874 Debug Symbols (7.4mb elf) 16 - January 2002 SCED_50151 Shaun Palmer’s Pro Snowboarding 2.3.4 Full Debug Symbols 16 - January 2002 SCED_50151 Ecco the Dolphin: Defender of the Future 2.2.0 Full Debug Symbols (33mb elf) 16 - January 2002 SCED_50151 FIFA Football 2002 2.2.0 Full Debug Symbols (7.6mb elf) 16 - January 2002 SCED_50151 Twisted Metal: Black 2.1.3 Full Debug Symbols (5.6mb elf) LGDEV.IRX 17 - February 2002 SCED_50152 Crash Bandicoot: The Wrath of Cortex 2.4.0 Full Debug Symbols 17 - February 2002 SCED_50152 Parappa the Rapper 2 2.4.1 Full Debug Symbols 17 - February 2002 SCED_50152 Robot Wars 2.1.1 Full Debug Symbols 18 - March 2002 SCED_50153 Drakan The Ancients Gates 2.3.2 No symbols but has a txt file mentioning Riot Engine and a DEBUG folder and uses SNPROFIL.IRX 18 - March 2002 SCED_50153 GODAI Elemental Force 2.1.4 Full Debug Symbols! (6.4mb elf) plus SCRIPTS folder 18 - March 2002 SCED_50153 Herdy Gerdy 2.4.2 No symbols but does have lots of printf debugging with filenames, plus HGSOUND.TRX Herdy Gerdy Sound IOP module 18 - March 2002 SCED_50153 Maximo 2.2.0 Full Debug Symbols (5.9MB) MJOLNIR.IRX 18 - March 2002 SCED_50153 Stuntman Xav Stream Video ? Full Debug Symbols (1mb) plus IOP Module for playing XAV files XAVSTRM.IRX (not a game) 19 - April 2002 SCED_50154 Mike Tyson Heavyweight Boxing 2.3.4 Full Debug Symbols 19 - April 2002 SCED_50154 Vampire Night 2.3.0 Full Debug Symbols 20 - May 2002 SCED_50743 Rally Championship 2.2.4 3,019 Debug Symbols 20 - May 2002 SCED_50743 Taz Wanted 2.4.3 4,927 Debug symbols 21 - June 2002 SCED_50742 Medal of Honor: Frontline 2.4.2 6,199 Debug Symbols, also contains .MAP file 21 - June 2002 SCED_50742 Frequency 2.3.2 13,890 Debug Symbols, uses python, uses EZMidi 21 - June 2002 SCED_50742 Peter Pan: Return to Never Land 2.3.0 4,382 Debug Symbols 21 - June 2002 SCED_50742 Super Trucks 2.4.3 2,990 Debug Symbols 22 - July 2002 SCED_50744 F1 2002 2.4.0 Debug Symbols in the .MAP file 22 - July 2002 SCED_50744 2002 FIFA World Cup 2.3.4 9,823 Debug Symbols 22 - July 2002 SCED_50744 MTV Music Generator 2.1.0 2,098 Debug Symbols 23 - August 2002 SCED_50745 Men in Black II: Alien Escape 2.4.3 20,542 Debug Symbols, References to Metrowerks SDK 23 - August 2002 SCED_50745 Project Zero 2.2.4 4,328 Debug Symbols 24 - September 2002 SCED_50746 Need for Speed: Hot Pursuit 2 2.4.3 8,341 Debug Symbols, Plus .MAP file that contains filenames and library names, odd fact is that it contains 2 elfs, one with debug symbols and one without, why include the debug symbols version, was it a mistake? 24 - September 2002 SCED_50746 Jak and Daxter: The Precursor Legacy 2.2.1 880 debug symbols plus interesting looking .CGO and .DGO files… 25 - October 2002 SCED_50747 X-Men: Next Dimension 2.4.3 3,418 Debug Symbols 26 - November 2002 SCED_50748 Crash Bandicoot: The Wrath of Cortex 2.4.0 3,817 Debug Symbols 26 - November 2002 SCED_50748 Summoner 2 2.4.0 5,647 Debug Symbols 27 - December 2002 SCED_50749 Colin McRae Rally 3 2.5.2 4,969 Debug Symbols 27 - December 2002 SCED_50749 Haven: Call of the King 2.5.0 Contains a RUNABOUT.EXE with debug symbols but it unpacks the actual elf from some data file 27 - December 2002 SCED_50749 Alpine Racer 3 2.4.2 3,916 Debug Symbols 28 - Christmas 2002 SCED_50750 V-Rally 3 2.5.2 6,603 Debug Symbols 28 - Christmas 2002 SCED_50750 MX Superfly 2.5.0 6,115 Debug Symbols 28 - Christmas 2002 SCED_50750 Treasure Planet 2.5.0 4,519 Debug Symbols 29 - January 2003 SCED_51384 FIFA 2003 2.3.4 12,074 Debug Symbols 30 - February 2003 SCED_51457 NBA Live 2003 2.4.3 15,756 Debug Symbols 30 - February 2003 SCED_51457 Space Channel 5 V2 2.3.0 10,212 Debug Symbols 30 - February 2003 SCED_51457 Tom Clancy’s Ghost Recon 2.4.2 19,496 Debug Symbols 31 - March 2003 SCED_51529 Grand Prix Challenge 2.5.4 14,342 Debug Symbols 31 - March 2003 SCED_51529 The Mark of Kri 2.5.4 7,387 Debug Symbols plus .MAP file! 31 - March 2003 SCED_51529 Wakeboarding Unleashed 2.4.3 Debug Symbols split over 3 elfs 55 - January 2005 SCED_52170 Rumble Roses PS2SDK 3.0.1 Contains Map file 56 - February 2005 SCED_53122 Athens 2004 PS2SDK 3.0.0 Contains .MAP file 57 - March 2005 SCED_53160 Full Spectrum Warrior PS2SDK 3.0.0 Contains 19,690 symbols in .sndata segment List of games without debug symbols but with interesting dataThe following is a list of games that while they don’t contain debug symbols, during analysis we did find they countained some interesting information that may be worth looking into: Demo Disc Game PS2 SDK Debug Info? 10 - August 2001, SCED_50145) Star Wars Super Bomad Racing 1.6.0 No debug symbols but early version of SDK 53 - January 2005 SCED_52168 Driver 3 PS2SDK 2.7.0 Contains animation Data in DRIVER3.IMG 53 - January 2005 SCED_52168 Sega Superstars PS2SDK 3.0.0 Uses boost libraries 54 - January 2005 SCED_52169 EyeToy: Play 2 3.0.0 Has .lua script files but no symbols in main elf 55 - January 2005 SCED_52170 Mashed PS2SDK 3.0.1 contains some strings related to C source file location (Physics/Rwp37Active/src/core/context/src/RwpObj.c) 55 - January 2005 SCED_52170 Mercenaries PS2SDK 2.7.1 Mentions Indiana Jones as unlockable character in config 55 - January 2005 SCED_52170 Pro Evolution Soccer 4 PS2SDK 3.0.1 mentions ADXT 55 - January 2005 SCED_52170 Splinter Cell Pandora Tomorrow PS2 SDK 3.0.0 contains a few symbol-like strings 56 - February 2005 SCED_53122 Timesplitters Future Perfect PS2SDK 3.0.2 Contains some symbols as segment names and a few references to source files 59 - May 2005 SCED_53162 Enthusia 3.0.0 Symbols in segment names 65 - November 2005 SCED_53186 Need for Speed: Most Wanted 2.8.0 Some function and class names in uncommon format 65 - November 2005 SCED_53186 NHL 06 2.8.0 FontFusion 2.4.1-nhl APT 0.18.06-nhl RealCore 6.25.00-nhl RealGraph 6.11.01-nhl Reveal 1.4.0 Mudlark 1.1.6 65 - November 2005 SCED_53186 Wallace & Gromit: The Curse of the Were-Rabbit ? Uses same engine as Project Zoo fgdk3 (Frontier Game Development Kit 3?) 72 - May 2006 SCED_54044 Driver 4 3.0.0 Contains .MAP files in DRIVER4.IMG 1 72 - May 2006 SCED_54044 TOCA Race Driver 3 3.0.2 a few references to cpp files and a small .sndata section Also note the following demo discs have no debug information, as far as we can tell, but some may be encrypted/compressed etc so its still possible there is something of value on them: 58 - April 2005 SCED_53161Full list of playable demos (regardless of debug)You may have reached this page out of genuine curiosity to try out some Playstation 2 demo games, and are not interested in the debug information, for this we have a table below that lists all the known playable games and which demo disc they are on engine: Demo Name SCED Code Playable Game Names OPS2M Demo 01 SCED-50065 International Superstar Soccer, Wild Wild Racing OPS2M Demo 02 SCED-50066 Dynasty Warriors 2, NHL 2001 OPS2M Demo 03 SCED-50067 Dynasty Warriors 2, International Superstar Soccer, Moto GP, NHL 2001, Wild Wild Racing OPS2M Demo 05 SCED-50140 Gran Turismo 3 A-spec OPS2M Demo 06 SCED-50141 Dead Or Alive 2, Zone of the Enders OPS2M Demo 07 SCED-50142 Sky Odyssey, Star Wars Starfighter, Warriors of Might and Magic OPS2M Demo 08 SCED-50143 Moto GP, MTV Music Generator 2 OPS2M Demo 09 SCED-50144 Formula 1 2001, Rugby, Wacky Races OPS2M Demo 10 SCED-50145 Gauntlet: Dark Legacy, Le Mans 24 Hours, Star Wars: Super Bombad Racing OPS2M Demo 11 SCED-50146 Lotus Challenge, World Championship Snooker 2002 OPS2M Demo 12 SCED-50147 MX Rider, Portal Runner, Soul Reaver 2, Spy Hunter, This Is Football 2 OPS2M Demo 12 SCED-50543 Portal Runner, Soul Reaver 2, Spy Hunter, This Is Football 2002 OPS2M Demo 13 SCED-50148 Driven, Klonoa 2: Lunatea’s Veil, MX 2002 Featuring Ricky Carmichael, NBA Street, Rayman M, Silent Scope 2, Time Crisis 2 OPS2M Demo 14 SCED-50149 Airblade, Baldur’s Gate 2: Dark Alliance, Dark Cloud, Silent Hill 2, Tarzan Freeride, Wipeout Fusion, World Rally Championship, WWF Smackdown! Just Bring It OPS2M Demo 15 SCED-50150 Burnout, Dropship: United Peace Force, ESPN X Games Skateboarding, Extreme G-3, Formula One 2001, G-Surfers, GTC Africa, Jak & Daxter, Lotus Challenge, Project Eden, Thunderhawk: Operation Phoenix, Top Gun: Combat Zones OPS2M Demo 16 SCED-50151 Ace Combat 4, Dropship: United Peace Force, Ecco The Dolphin: Defender Of The Future, FIFA 2002, Headhunter, MotoGP 2, Pro Evolution Soccer, Shaun Palmer’s Pro Snowboarder, Twisted Metal: Black, Wipeout Fusion OPS2M Demo 17 SCED-50152 Crash Bandicoot: The Wrath of Cortex, Metal Gear Solid 2: Sons of Liberty, Parappa the Rapper 2, Rez, Robot Wars, Soul Reaver 2, Wipeout Fusion OPS2M Demo 18 SCED-50153 Drakan: The Ancients’ Gates, Dynasty Warriors 3, Godai: Elemental Force, Half-Life, Herdy Gerdy, Maximo OPS2M Demo 19 SCED-50154 Dead or Alive 2, Formula One 2001, Ico, Mike Tyson Heavyweight Boxing, Vampire Night OPS2M Demo 20 SCED-50743 Final Fantasy X, Moto GP, Rally Championship, Space Race, Taz Wanted OPS2M Demo 21 SCED-50742 Frequency, Medal of Honor: Frontline, Peter Pan: Return to Never Land, Redcard, Smash Court Tennis Pro Tournament, Star Wars: Jedi Starfighter, Super Trucks, This is Football 2002, Tiger Woods PGA Tour 2002 OPS2M Demo 22 SCED-50744 2002 FIFA World Cup, Britney’s Dance Beat, Formula One 2002, Gitaroo Man, MTV Music Generator, Time Crisis 2 OPS2M Demo 23 SCED-50745 Army Men: Real Time Strategy, Fireblade, Men In Black II: Alien Escape, Project Zero, Stuntman UPS2M Demo Italia 08/02 SCED-51111 2002 FIFA World Cup, Army Men: Real Time Strategy, Britney’s Dance Beat, Fireblade, Formula One 2002, Men In Black II: Alien Escape, Project Zero, Stuntman OPS2M Demo 24 SCED-50746 Aggressive Inline Skating, Conflict: Desert Storm, Downforce, Jak & Daxter: The Precursor Legacy, Need for Speed Hot Pursuit 2, TOCA Race Driver, World Rally Championship OPS2M Demo 25 SCED-50747 Disney’s Stitch: Experiment 626, Ninja Assault, This is Football 2003, Timesplitters 2, WWE Smackdown! Just Bring It!, X-Men Next Dimension OPS2M Demo 26 SCED-50748 Burnout 2: Point of Impact, Crash Bandicoot: The Wrath of Cortex, Ferrari F355 Challenge, Hitman 2: Silent Assassin, Micro Machines, Ratchet & Clank, Red Faction 2, Summoner 2, Superman: Shadow of Apokolips, Tekken 4 OPS2M Demo 27 SCED-50749 Alpine Racer 3, Colin McRae Rally 3, Heaven: Call of the King, Reign of Fire, Twin Caliber, Ty the Tasmanian Tiger, WRC II Extreme OPS2M Demo 28 SCED-50750 Battle Engine Aquila, MX Superfly, The Getaway, Treasure Planet, V-Rally 3 OPS2M Demo 29 SCED-51384 Ape Escape 2, Eggo Mania, FIFA 2003, Formula One 2002, Pro Evolution Soccer 2, Rocky OPS2M Demo 29 SCED-51440 Ape Escape 2, Eggo Mania, FIFA 2003, Formula One 2002, Pro Evolution Soccer 2, Rocky OPS2M Demo 30 SCED-51457 ATV2: Quad Power Racing, Crashed, Mortal Kombat: Deadly Alliance, NBA Live 2003, Primal, Sly Raccoon, Space Channel 5 v2, Tiger Woods PGA Tour 2003, Tom Clancy’s Ghost Recon, WWE Smackdown! Shut Your Mouth OPS2M Demo 30 SCED-51489 ATV Quad Power Racing 2, Crashed, Mortal Combat Deadly Alliance, NBA Live 2003, Primal, Sly Raccoon, Space Channel 5: Part 2, Tiger Wood’s PGA Tour 2003, Tom Clancy’s Ghost Recon, WWE Smackdown: Shut Your Mouth! OPS2M Demo 31 SCED-51529 Dr Muto, Grand Prix Challenge, Rayman 3: Hoodlum Havoc, Splinter Cell, The Mark of Kri, Timesplitters 2, Wakeboarding Unleashed, War of the Monsters, Zapper OPS2M Demo 31 SCED-51556 Dr. Muto, Grand Prix Challenge, Rayman 3 Hoodlum Havoc, The Mark Of Kri, Timesplitters 2, Tom Clancy’s Splinter Cell, War Of The Monsters, Wakeboarding Unleashed Featuring Shaun Murray, Zapper OPS2M Demo 32 SCED-51530 Ape Escape 2, Dakar 2, Mobile Suit Gundam: Federation Vs Zeon, Silent Hill 2, Spy Hunter, Techu: Wrath Of Heaven, Scorpion King, Splinter Cell, Vexx, Zone Of The Enders OPS2M Demo 32 (French) SCED-51558 Ape Escape 2, Dakar 2, Mobile Suit Gundam Fed Vs Zeon, Silent Hill 2, Splinter Cell, Spy Hunter, Tenchu, The Scorpion King, Vexx, Zone Of The Enders The 2nd Runner UPS2M Demo Italia 04/03 SCED-51652 Ape Escape 2, Dakar 2, Mobile Suit Gundam: Federation Vs Zion, Silent Hill 2, Splinter Cell, Spy Hunter, Tenchu: Wrath Of Heaven, The Scorpion King, Vexx, Zone Of The Enders OPS2M Demo 33 SCED-51531 Conflict: Desert Storm, Dynasty Warriors 3, Evolution Skateboarding, Herdy Gerdy, Moto GP3, Pride FC, Project Eden, Shinobi, WRC II Extreme OPS2M Demo 33 SCED-51559 Conflict Desert Storm, Dynasty Warriors 3, Evolution Skateboarding, Herdy Gerdy, Moto GP3, Pride FC, Primal, Project Eden, Shinobi, WRC II Extreme (Challenge Demo) OPS2M Demo 34 SCED-51532 Airblade, Baldur’s Gate: Dark Alliance, Burnout 2, Def Jam Vendetta, Rygar, Silent Hill 3, Virtua Fighter 4, Wipeout Fusion OPS2M Demo 34 SCED-51560 Airblade, Baldur’s Gate, Burnout 2 Point Of Impact, Def Jam Vendetta, Gunfighter 2, Rygar, Silent Hill 3, Virtua Figther 4 Evo, Wipeout Fusion OPS2M Demo 35 SCED-51533 Alter Echo, Gunfighter II, Hitman 2: Silent Assassin, Ico, Jak & Daxter, Ratchet & Clank, Socom: US Navy Seals, Twisted Metal: Black, WWE Smackdown! Shut Your Mouth OPS2M Demo 35 SCED-51561 Gunfighter 2, Hitman 2, Ico, Jak & Daxter, Ratchet & Clank, SOCOM: US Navy Seals, Twisted Metal Black, WWE Smackdown: Shut Your Mouth! OPS2M Demo 36 SCED-51534 Final Fantasy X, Futurama, Headhunter, Mace Griffin Bounty Hunter, Starsky & Hutch, Tekken 4, This is Football 2003, Tiger Woods PGA Tour 2003, Zone of the Enders OPS2M Demo 37 SCED-51537 Alter Echo, Ape Escape 2, Die Hard Vendetta, Dynasty Warriors 3, Metal Gear Solid 2, Ratchet & Clank, Return to Castle Wolfenstein, Splashdown 2: Rides Gone Wild, Splinter Cell, The Great Escape, WRC II Extreme OPS2M Demo 37 SCED-51563 Alter Echo, Ape Escape 2, Die Hard Vendetta, Dynasty Warriors 3, Metal Gear Solid 2, Ratchet & Clank, Return To Castle Wolfenstein, Splashdown 2 Rides, Splinter Cell, The Great Escape, WRC II Extreme OPS2M Demo 38 SCED-51538 Amplitude, Chaos Legion, Colin McRae Rally 4, Finding Nemo, Formula One 2003, Freedom Fighters, Metal Gear Solid 3 Snake Eater, Perfect Ace, Rugby 2004, Soul Calibur 2, Sphinx And The Shadow Of Set, Summer Heat Beach Volleyball, True Crime: Streets Of LA, Warhammer 40K: Firewarrior, Zone Of The Enders The 2nd Runner OPS2M Demo 39 SCED-51540 Beyond Good & Evil, Conflict: Desert Storm II, Extreme Skate Adventure, Freestyle Metal X, Ironstorm: World War Zero, Jak II: Renegade, Judge Dredd: Dredd Vs Death, My Street, Prince of Persia: The Sands of Time, Rolling, The Italian Job: LA Heist (Circuit), The Italian Job: LA Heist (Stunt) OPS2M Demo 40 SCED-51535 Destruction Derby Arenas, Dog’s Life, Freaky Flyers, Ghosthunter, Gladius, James Bond 007: Everything or Nothing, Need for Speed Underground, Ratchet & Clank 2: Locked and Loaded, Tiger Woods PGA Tour 2004, Time Crisis 3, Wallace & Gromit in Project Zoo UPS2M Demo Italia 06/03   Airblade, Baldur’s Gate: Dark Alliance, Burnout 2, Def Jam Vendetta, Rygar, Silent Hill 3, Virtua Fighter 4, Wipeout Fusion UPS2M Demo Italia 07/03   Gunfighter, Hitman 2, Ico, Jak & Daxter, Ratchet & Clank, Socom U.S. Navy Seals, Twisted Metal Black, WWE Smackdown UPS2M Demo Italia 08/03   Final Fantasy X, Futurama, Headhunter, Mace Griffin Bounty Hunter, Starsky & Hutch, Tekken 4, This Is Fotball 2003, Tiger Woods PGA Tour 2003, Zone Of The Enders UPS2M Demo Italia 09/03   Alter Echo, Ape Escape 2, Die Hard Vendetta, Dynasty Warriors 3, Metal Gear Solid 2 Sons Of Liberty, Ratchet & Clank, Return To Castle Wolfenstein: Operation Resurrection, Splashdown 2: Rides Gone Wild, The Great Escape, Tom Clancy’s Splinter Cell, WRC II Extreme UPS2M Italia 12/03   007 Everything Or Nothing, Destruction Derby Arenas, Dog’s Life, Freaky Flyers, Ghosthunter, Gladius, Need For Speed Underground, Ratchet & Clank 2, Tiger Woods PGA Tour 2004, Time Crisis 3, Wallace & Gromit OPS2M Demo 41   Buffy the Vampire Slayer: Chaos Bleeds, Dancing Stage Fever, Jimmy Neutron Jet Fusion, Kao the Kangaroo 2, NHL Hitz Pro, Pro Evolution Soccer 3, Scooby-Doo! Mystery Mayhem, Super Farm, The Hulk, The Simpsons Hit & Run, Tom Clancy’s Ghost Recon: Jungle Storm, Buffy the Vampire Slayer: Chaos Bleeds, Dancing Stage Fever, Jimmy Neutron Jet Fusion, Kao the Kangaroo 2, NHL Hitz Pro, Pro Evolution Soccer 3, Scooby-Doo! Mystery Mayhem, Super Farm, The Hulk, The Simpsons Hit & Run, Tom Clancy’s Ghost Recon: Jungle Storm UPS2M Italia 01/04 Demo   Buffy The Vampire Slayer: Chaos Bleeds, Dancing Stage Fever, Ghost Recon: Jungle Storm, Kao The Kangaroo 2, NHL Hitz Pro, Pro evolution Soccer 3, Scooby-Doo! Mystery Mayhem, Super Farm, The Simpson’s Hit And Run OPS2M Demo 42   FIFA 2004, Grooverider, Pop Idol, R-Type Final, Socom: US Navy Seals, Soul Calibur II, Starsky & Hutch, Tak and the Power of Juju, WRC 3, XIII, FIFA 2004, Grooverider, R-Type Final, Socom: US Navy Seals, Soul Calibur II, Starsky & Hutch, Tak and the Power of Juju, WRC 3, XIII UPS2M Demo Italia 02/04   FIFA Football 2004, Grooverider, R-Type Final, Socom: U.S. Navy Seals, Soul Calibur II, Starsky & Hutch, Tak And The Power Of Juju, World Rally Championship 3, XIII OPS2M Demo 43   Arc: Twilight of the Spirits, Castlevania, Ford Racing 2, I-Ninja, Maximo Vs Army of Zin, Metal Arms: Glitch in the System, Rogue Ops, SSX 3, Worms 3D, Arc Twilight Of The Spirits, Castlevania Lament Of Innocence, Ford Racing 2, I-Ninja, Maximo Vs The Army Of Zin, Metal Arms, Rogue Ops, SSX 3, Worms 3D OPS2M Demo 44   007: Everything Or Nothing, Crash Nitro Cart, Downhill Domination, Kill Switch, Nightshade, Rainbow Six 3, Urban Freestyle Soccer, Whiplash OPS2M Demo 45   Broken Sword: The Sleeping Dragon, Final Fantasy X-2, Firefighter FD:18, Forbidden Siren, Kya: Dark Lineage, R: Racing Evolution, Socom 2: US Navy Seals, This is Football 2004, Broken Sword: The Sleeping Dragon, Final Fantasy X-2, Firefighter FD:18, Forbidden Siren, Kya: Dark Lineage, R: Racing Evolution, Socom 2: US Navy Seals, This is Football 2004 UPS2M Italia 05/04   Broken Sword 3 The Sleeping Dragon, Final Fantasy X-2, Firefighter F.D. 18, Forbidden Siren, Kya: Dark Lineage, R: Racing, Socom II, This Is Fotball 2004 OPS2M Demo 46   Arc: Twilight Of The Spirits, CY Girls, Fight Night 2004, MX Unleashed, NFL Street, Richard Burns Rally, Rise To Honour, Sonic Heroes, Teenage Mutant Ninja Turtles, Transformers UPS2M Italia 06/04   Arc Twilight Of The Spirits, Cy Girls, Fight Night, Mashed, MX Unleashed, NFL Street, Richard Burns Rally, Rise To Honor, Sonic Heroes, Teenage Mutant Ninja Turtles, Transformers OPS2M Demo 47   Alias, Champions Of Norrath, Deadly Skies III, Goblin Commander: Unleash The Horde, Megaman X7, Pool Paradise, World War Zero: Ironstorm OPS2M Demo 47   Alias, Champions Of Norrath, Deadly Skies III, Goblin Commander: Unleash The Horde, Megaman X7, Pool Paradise, World War Zero OPS2M Demo 48   Athens 2004, Mashed, MTV Music Generator 3, Serious Sam, Syphon Filter: The Omega Strain, This Is Football 2004, Athens 2004, Mashed, MTV Music Generator 3, Serious Sam, Syphon Filter: The Omega Strain, This Is Football 2004 OPS2M Demo 49   Formula One 2004, Hitman Contracts, Mashed, Smash Court Tennis 2, Splinter Cell: Pandora Tomorrow OPS2M Demo 49   Formula One 04, Hitman Contracts, Mashed, Smash Court Tennis Pro Tournament 2, Splinter Cell Pandora Tomorrow OPS2M Demo 50   Burnout 3, Crash Unlimited, Psi Ops, Ribbit King, Second Sight, Silent Hill 4 The Room, Star Wars Battlefront, Van Helsing OPS2M Demo 50   Burnout 3, Crash Unlimited, Psi Ops The Mindgate Conspiracy, Ribbit King, Second Sight, Silent Hill 4 The Room, Star Wars Battlefront, Van Helsing UPS2M Italia 09/04   Burnout 3, Crash Unlimited, Formula One 04, Psi Ops, Ribbit King, Second Sight, Silent Hill 4 The Room, Smash Court Tennis Pro Tournament 2, Splinter Cell Pandora Tomorrow, Star Wars Battlefront, Van Helsing OPS2M Demo 51   Colin McRae Rally 2005, Crisis Zone, DJ: Decks And Effects, Ratched & Clank 3, Spyro: A Hero’s Tail OPS2M Demo 51/eur   Colin McRae Rally 2005, Crisis Zone, DJ: Decks & FX, Ratchet & Clank: Up Your Arsenal, Spyro: A Hero’s Tail OPS2M Demo 52   Killzone, Obscure, Pro Evolution Soccer 4, Rocky Legends, Sly 2: Band Of Thieves OPS2M Demo 52   Jak II Renegade, Killzone, Obscure, Pro Evolution Soccer 4, Ratchet & Clank 2, Rocky Legends, Sly 2 Band Of Thieves, TOCA Race Driver 2, WRC 3 UPS2M Italia 11/04   Jak II Renegade, Killzone, Need For Speed Underground 2, Obscure, Pro Evolution Soccer 4, Ratchet & Clank 2, Rocky Legends, Sly 2 Band Of Thieves, TOCA Race Driver 2, WRC 3 OPS2M Demo 53   Driv3er, Jackie Chan Adventures, Jak 3, Need For Speed Underground 2, Sega Superstars, The Incredibles, This Is Football 2005, Tiger Woods PGA Tour 2005, TOCA Race Driver 2, World Rally Championship 4 OPS2M Demo 53   Adiboo And The Energy Thieves, Jackie Chan Adventures, Jak 3, Need For Speed Underground 2, Sega Superstars, The Incredibles, This Is Football 2005, Tiger Woods PGA Tour 2005, WRC 4 OPS2M Demo 54   Dancing Stage Fusion, EyeToy Play 2, Forgotten Realms: Demon Stone, Fren-zE, Prince Of Persia 2, The Getaway: Black Monday OPS2 Demo 54 spa   Athens 2004, Dancing Stage Fusion, Forbidden Realms: Demon Stone, EyeToy Play 2, Fren-zE, Moto GP 3, Prince Of Persia 2, Soul Calibur 2, The Getaway Black Monday UPS2 Demo 2005/01 ita   Athens 2004, Dancing Stage Fusion, Demon Stone, EyeToy Play 2, Fren-zE, Moto GP 3, Prince Of Persia 2, Soul Calibur 2, The Getaway Black Monday OPS2M Demo 55   Burnout 3, Fren-zE, Killzone, Mashed, Mercenaries, Pro Evolution Soccer 4, Rumble Roses, Splinter Cell: Pandora Tomorrow OPS2 Demo 55 euro   Burnout 3, Fren-zE, Megaman X8, Mercenaries, Metal Slug 3, Nanobreaker, Pro Evolution Soccer 4, Rumble Roses, Splinter Cell: Pandora Tomorrow, Tekken 4, Van Helsing OPS2M Germany 02-2005   Burnout 3, Fren-zE, Megaman X8, Metal Slug 3, Nanobreaker, Pro Evolution Soccer 4, Rumble Roses, Second Sight, Serious Sam, Sonic Heroes, Splinter Cell: Pandora Tomorrow, Tekken 4, Van Helsing OPS2M Demo 56 uk   Ace Combat 5: Squadron Leader, Athens 2004, Metal Slug 3, Moto GP 3, Nanobreaker, Prince Of Persia: Sands Of Time, Timesplitters: Future Perfect, Transformers OPS2M Demo 56   Ace Combat Squadron Leader, Burnout 3, Fren-Ze, Killzone, Mercenaries, Metal Slug 3, Nanobreaker, Pro Evolution Soccer 4, Rumble Roses, Splinter Cell Pandora Tomorrow, TimeSplitters Future Perfect, Ace Combat 5: Squadron Leader, Death By Degrees, King Of Fighters: Maximum Impact, Legend Of Kay, Moto GP 3, Prince Of Persia: Sands Of Time, Smash Court Tennis Pro Tournament 2, Teenage Mutant Ninja Turtles 2, Transformers, Viewtiful Joe 2 OPS2M Demo 57   Ace Combat 5 Squadron Leader, Death By Degrees, Full Spectrum Warrior, King Of Fighters: Maximum Impact, Legend Of Kay, Megaman X8, Metal Gear Solid 3 Snake Eater, Teenage Mutant Ninja Turtles 2, Area 51, Cold Winter, Constantine, Full Spectrum Warrior, Megaman X8, Metal Gear Solid 3 Snake Eater, Ratchet & Clank 3, WRC 4 OPS2M Demo 58   Area 51, Cold Winter, Constantine, EyeToy: AntiGrav, Jak 3, Juiced, Metal Gear Solid 3: Snake Eater, Ratchet & Clank 3, The Getaway: Black Monday, WRC 4 OPS2M Demo 58 euro   Enthusia, Fight Night Round 2, Full Spectrum Warrior, Jak 3, Juiced, Killzone, Rugby 2005, The Spongebob Squarepants Movie OPS2M Demo 58 - spa/por   Enthusia, Fight Night Round 2, Full Spectrum Warrior, Jak 3, Juiced, Killzone, Rugby 2005, The Spongebob Squarepants Movie, Timesplitters Future Perfect OPS2M Demo 59   Enthusia, Fight Night Round 2, Full Spectrum Warrior, Juiced, Killzone, Lego Star Wars, Rugby 2005, The Spongebob Squarepants Movie OPS2M Demo 59 euro   CT Special Forces: Fire For Effect, EyeToy Play 2, FIFA Street, Lego Star Wars, Robots, SingStar Pop, SRS: Street Racing Syndicate, Super Monkey Ball Deluxe OPS2M Demo 60   Brave, Brothers In Arms: Road To Hill 30, CT Special Forces: Fire For Effect, Robots, Singstar Pop, SRS: Street Racing Syndicate, Stolen, Super Monkey Ball Deluxe OPS2M Demo 60 euro   Brother In Arms: Road To Hill 30, Burnout 3, Destroy All Humans!, Killzone, Moto GP 3, Prince Of Persia 2, SingStar Pop, Super Monkey Ball Deluxe OPS2M Italian Demo 61 07/05   Brothers In Arms: Road To Hill 30, Burnout 3, Destroy All Humans, Killzone, Moto GP 3, Prince Of Persia 2, SingStar Popworld, Super Monkey Ball Deluxe OPS2M Demo 61   Destroy All Humans!, Pro Evolution Soccer 4, Worms 4 Mayhem, Ys: Ark Of Napishtim, Tekken 5 OPS2M Demo 61 euro   Brave, Demon Stone, Final Fantasy X-2, Formula One 2005, Pro Evolution Soccer 4, Soul Calibur 2, Spyro: A Hero’s Tail, Tekken 5, Worms 4 Mayhem, Ys The Ark Of Napishtim OPS2M Demo 62   Area 51, Brothers In Arms: Road To Hill 30, Destroy All Humans!, Fight Nigh Round 2, Formula One 2005, God Of War, Lego Star Wars, Madagascar OPS2M Demo 62 euro   Area 51, Brothers In Arms: Road To Hill 30, Destroy All Humans!, Fight Night Round 2, Formula One 2005, God Of War, Lego Star Wars, Madagaskar OPS2M Demo 63   187 Ride Or Die, Brian Lara International Cricket 2005, God Of War, Juiced, Musashi: Samurai Legend, Tekken 5, The Incredible Hulk: Ultimate Destruction, Tiger Woods PGA Tour 2005 OPS2M Demo 63 euro   187 Ride Or Die, God Of War, Juiced, Metal Gear Solid 3: Snake Eater, Musashi Samurai Legend, Rugby 2005, Tekken 5, The Incredible Hulk: Ultimate Destruction, Tiger Woods PGA Tour 2006, TimeSplitters: Future Perfect OPS2M Demo 64   Burnout Revenge, Conflict Global Terror, Crash Tag Team Racing, Everybody’s Golf, Fahrenheit, Steel Lancer Arena International, Wild Water Adrenaline UPS2M Italia 10/2005 - Italian Demo   Burnout Revenge, Conflict Global Terror, Crash Tag Team Racing, Delta Force: Black Hawk Down, Everybody’s Golf, Fahrenheit, Steel Lancer Arena International, Total Overdose, Wild Water Adrenaline OPS2 Demo 65   Beatdown: Fists Of Vengeance, Brothers In Arms: Earned in Blood, Darkwatch, Delta Force: Black Hawk Down, Need For Speed Most Wanted, NHL 2006, Pro Evolution Soccer 5, Soul Calibur 3, Tom Clancy’s Rainbow Six Lockdown, Wallace & Gromit The Curse Of The Were-Rabbit, WRC Rally Evolved OPS2M Demo 66   Asterix & Obelix XXL2, Dancing Stage Max, Evil Dead Regeneration, FIFA 2006, Genji, LA Rush, King Kong, Ratchet Gladiator, Shrek Superslam, Sly 3: Honour Among Thieves, Spartan Total Warrior, SpyToy, The Sims 2 OPS2M Demo 67   From Russia With Love, The Incredibles: Rise Of The Underminer, Jak X Racing, The Matrix: The Path Of Neo, SingStar 80’s, Without Warning, Battlefield 2: Modern Combat, From Russia With Love, Jak X Racing, SingStar 80’s, The Incredibles: Rise Of The Underminer, The Matrix: The Path Of Neo, Without Warning UPS2M Demo Italia 01/2006   007 From Russia With Love, Battlefield 2 Modern Combat, Jak X, SingStar 80’s, The Incredibles: Rise of the Underminer, The Matrix: Path Of Neo, Without Warning OPS2M Demo 68   Battlefield 2 Modern Combat, Pilot Down: Behind Enemy Lines, The Chronicles Of Narnia, TOCA Race Driver 3, Urban Reign OPS2M Demo 69   24: The Game, Black, Fahrenheit, ICO, Shadow Of The Colossus OPS2M Demo 69 & 70   24: The Game, Black, Castlevania: Curse Of Darkness, Drakengard 2, Driver: Parallel Lines, Fahrenheit, ICO, Shadow Of The Colossus, The Sword Of Etheria, We Love Katamari OPS2M Demo 70   Castlevania: Curse Of Darkness, Commandos: Strike Force, Drakengard 2, Driver: Parallel Lines, The Sword Of Etheria, We Love Katamari OPS2M Demo 71/uk   Dragon Quest: The Journey Of The Cursed King, FIFA Street 2, Fight Night Round 3, Marc Ecko’s Getting Up: Contents Under Pressure, Rugby 06, Suikoden Tactics, Tomb Raider Legend OPS2M Demo 71 por/spa   Commandos Strike Force, Dragon Quest: The Journey Of The Cursed King, FIFA Street 2, Fight Night Round 3, Marc Ecko’s Getting Up: Contents Under Pressure, Rugby 06, Sonic Riders, Suikoden Tactics, Tomb Raider Legend UPS2M Demo Italia 03-2006   Commandos Strike Force, Drakengard 2, Driver: Parallel Lines, FIFA Street 2, Fight Night Round 3, Rugby 06, Suikoden Tactics, Tomb Raider Legend OPS2M Demo 72/uk   24: The Game, Black, Driver: Parallel Lines, Hitman: Blood Money, Outrun 2006: Coast 2 Coast, Sonic Riders, TOCA Race Driver 3, Tomb Raider Legend, We Love Katamari UPS2M Demo Italia 04/2006   Dragon Quest VIII, Hitman Blood Money, Mark Echo’s Getting Up: Contents Under Pressure, Outrun 2006 Coast 2 Coast, Sensible Soccer, Sonic Riders, Super Monkey Ball Deluxe OPS2M Demo 73/uk   Ape Escape 3, Dragon Quest VIII, FIFA Street 2, Hitman: Blood Money, Micro Machines V4, Outrun 2006: Coast 2 Coast, Sensible Soccer, Sonic Riders, Super Monkey Ball Adventure, Tomb Raider Legend OPS2M Demo 73/benelux   Dragon Quest VIII, FIFA Street 2, Hitman Blood Money, Micro Machines V4, Outrun 2006: Coast 2 Coast, Sensible Soccer, Sonic Riders, Super Monkey Ball Adventure, Tomb Raider Legend, Urban Chaos: Riot Response UPS2M Demo Italia 05-2006   24: The Game, Dragon Quest VIII, FIFA Street 2, Hitman Blood Money, Micro Machines V4, Outrun 2006: Coast 2 Coast, Pro Evolution Soccer 5, Super Monkey Ball Adventure, Tomb Raider Legend, Urban Chaos: Riot Response OPS2M Demo 74   Driver: Parallel Lines, Earache Extreme Metal Racing, EyeToy: Play Sports, Fight Night Round 3, Forbidden Siren 2, Micro Machines V4, Sensible Soccer, SingStar Rocks!, Tomb Raider Legend OPS2M Demo 74/spa   Driver: Parallel Lines, Earache Extreme Metal Racing, EyeToy: Play Sports, Fight Night Round 3, Forbidden Siren 2, SingStar Rocks!, Tomb Raider Legend, Urban Chaos Riot Response UPS2M Italia06/2006   Driver: Parallel Lines, Earache Extreme Metal Racing, EyeToy: Play Sports, Fight Night Round 3, Forbidden Siren 2, Metal Gear Solid 3 Snake Eater, Micro Machines V4, Sensible Soccer, SingStar Rocks!, Tekken 5 OPS2M Demo 75   B-Boy, Dragon Quest VIII, FIFA Street 2, Hitman: Blood Money, Jak 3, Micro Machines V4, Outrun 2006: Coast 2 Coast, Ratchet Gladiator, SingStar Rocks!, Sonic Riders, Tomb Raider Legend UPS2M Demo Italia 07-2006   B-Boy, Dragon Quest VIII, Hitman Blood Money, Jak 3, Micro Machines V4, Outrun 2006 Coast 2 Coast, Ratchet Gladiator, Shinobido, SingStar Rocks!, Sonic Riders, Tomb Raider Legend OPS2M Demo 76/uk   B-Boy, Black, FIFA 06, Forbidden Siren 2, Formula One 2006, LEGO Star Wars 2, Metal Gear Solid 3: Snake Eater, Shinobido, SingStar Rocks!, Yakuza OPS2M Demo 77 uk/eur   Ace Combat: The Belkan War, B-Boy, Bionicle: Heroes, EyeToy: Lemmings, Formula One 06, LEGO Star Wars II: The Original Trilogy, Need For Speed Carbon, ProStroke Golf, Yakuza OPS2M Demo 78   Bionicle Heroes, Destroy All Humans! 2, Lemmings Classic, Lemmings EyeToy, Made Man, Need for Speed: Carbon, The Sims 2 OPS2M Demo 79   Bionicle Heroes, Buzz! Junior Jungle Party, Destroy All Humans! 2, FIFA 07, LEGO Star Wars, LEGO Star Wars II, LMA Manager 2007, Made Man, Pro Evolution Soccer 6 OPS2M Demo 80   Eragon, Final Fantasy X-2, LMA Manager 2007, Pro Evolution Soccer 6, Silent Hill 3, Virtua Fighter 4 OPS2M Demo 80 spa/por   Eragon, Final Fantasy X-2, Lemmings Classic, LMA Manager 2007, Pro Evolution Soccer 6, Silent Hill 3, The Sims 2, Virtua Fighter 4 OPS2M Demo 81   Arthur & The Invisibles, Black, Dragon Quest VIII, FIFA 2007, Final Night Round 3, Jak 3, Okami, Outrun 2006: Coast 2 Coast, TOCA Race Driver 3, Tomb Raider Legend, We Love Katamari OPS2M Demo 81 spa/por   Arthur & The Invisibles, Dragon Quest VIII, Driver: Parallel Lines, FIFA 2007, Formula 1 2006, Lego Star Wars 2, Need For Speed Carbon, Okami, Pro Evolution Soccer 6, SingStar Rocks!, Tomb Raider Legend OPS2M Demo 82   EyeToy Play Sports, FIFA 2007, FIFA Street 2, Fight Night Round 3, Okami, Pro Evolution Soccer 6, Rugby 06, SingStar Rocks!, Sonic Riders, Suikoden Tactics, Tomb Raider Legend OPS2M Demo 83   Dancing Stage Fusion, Ferrari F355 Challenge, Formula One 04, Heatseeker, Juiced, Kill Switch, Need For Speed: Hot Pursuit 2, Rocky Legends, Stuntman, The Simpsons: Hit & Run, WRC 4, Zone Of The Enders: The 2nd Runner OPS2M Demo 84   Brian Lara’s International Cricket 2007, Castlevania: Curse Of Darkness, Everybody’s Tennis, God Of War, ICO, Mashed, Maximo Vs. Army Of Zin, Rise To Honour, Soul Calibur 3, Virtua Fighter 4 OPS2M Demo 85   Alias, Beyond Good & Evil, Buffy The Vampire Slayer: Chaos Bleeds, Cy Girls, God Of War 2, Mercenaries, Primal, Tomb Raider Legend, Transformers, UEFA Championship League 2006-2007 OPS2M Demo 86   24 The Game, Crash Tag Team Racing, Dark Cloud, Enthusia Professional Racing, Everybody’s Golf, Everybody’s Tennis, Fahrenheit, From Russia With Love, Ratchet Gladiator, Second Sight OPS2M Demo 87   Buzz! Junior: Jungle Party, Destroy All Humans! 2, Dog’s Life, Ford Racing 2, Ghost Recon: Jungle Storm, God Of War II, Hitman 2 Silent Assassin, Lumines Plus, Metal Gear Solid 3: Snake Eater, Obscure II, Reign Of Fire, War Of The Monsters OPS2M Demo 88   Broken Sword 3: The Sleeping Dragon, Ghosthunter, King Of Clubs, Micro Machines Odyssey, Project Zero, Sly Raccoon 2: Band Of Thieves, Viewtiful Joe 2, V-Rally 3, World Rally Championship 4, Worms 3D OPS2M Demo 88 (OPS2M Demo 89 uk/eur)   Final Fantasy X, Finding Nemo, Firefighter F.D. 18, Forbidden Siren 2, Freedom Fighters, Juiced, Obscure 2, Okami, Rogue Galaxy, The Incredibles OPS2M Demo 90   Crash Nitro Cart, Crash Of The Titans, Moto GP3, Project Eden, Rogue Galaxy, Shrek Superslam, Spartan: Total Warrior, Syphon Filter: The Omega Strain, Tomb Raider Anniversary, Yakuza OPS2M Demo 91   Amplitude, Beyond Good & Evil, Crash Of The Titans, Freedom Fighters, Killzone, Rez, Stuntman Ignition, The Simpsons: Hit & Run, Tomb Raider Anniversary, Wallace & Gromit OPS2M Demo 92   Destroy All Humans!, FIFA 08, Need For Speed: Most Wanted, Pro Evolution Soccer 2008, Ratchet & Clank 3, Return To Castle Wolfenstein, Soul Calibur 2, Space Channel 5: Part 2, Spider-Man: Friend Or Foe, Tenchu: Wrath Of Heaven, Whiplash OPS2M Demo 93   Brian Lara Cricket 2007, Everybody’s Tennis, FIFA 08, God Of War II, Harry Potter And The Order Of The Phoenix, Heatseeker, Okami, PDC World Championship Darts 2008, Rogue Galaxy, Spider-Man Friend Or Foe, Stuntman Ignition, Tomb Raider Anniversary OPS2M Demo 94   Asterix At The Olympic Games, Black, Crash Of The Titans, Harry Potter & The Order Of The Phoenix, LEGO Star Wars 2, Lumines Plus, Metal Gear Solid 3: Snake Eater, Need For Speed: Carbon, Outrun 2006: Coast 2 Coast, SingStar Rocks, TimeSplitters: Future Perfect OPS2M Demo 95   24: The Game, Brothers In Arms: Earned In Blood, Dragon Quest VIII, Harry Potter And The Order Of The Phoenix, High School Musical, Jak 3, Prince Of Persia: The Sands Of Time, Ratchet: Gladiator, Rise To Honour, SEGA Superstars, Spyro: A Hero’s Tail OPS2M Demo 96   Arthur And The Invisibles, Bionicle Heroes, From Russia With Love, ICO, Prince Of Persia: The Warrior Within, Rocky Legends, Shadow Of The Colossus, Sonic Riders, The Incredible Hulk, The Incredibles, Tomb Raider Anniversary OPS2M Demo 97   Arthur And The Invisibles, Bionicle Heroes, Crash Of The Titans, Dark Cloud, Harry Potter & The Order Of The Phoenix, Klonoa 2: Lunatea’s Veil, Okami, Tak And The Power Of Juju, The Simpsons: Hit & Run, The Incredibles: Rise Of The Underminer, Wallace & Gromit: Curse Of The Were Rabbit, We Love Katamari OPS2M Demo 98   Burnout Revenge, Ferrari F355 Challenge, Formula One 2006, Juiced, Mashed, Micro Machines V4, Moto GP 3, Need For Speed: Carbon, Outrun 2006: Coast 2 Coast, Stuntman Ignition, Toca Race Driver 3, WRC Rally Evolved OPS2M Demo 99   24: The Game, Black, Brothers In Arms: Road To Hill 30, Conflict Desert Storm, Ghost Recon: Jungle Storm, Killzone, Medal Of Honor: Frontline, Metal Slug 3, Rainbow Six: Lockdown, Return To Castle Wolfenstein, Rez, Second Sight, TimeSplitters 2 OPS2M Demo 100   Burnout Revenge, Final Fantasy X, Metal Gear Solid 3 Snake Eater, Okami, Pro Evolution Soccer 2008, Rogue Galaxy, Shadow Of The Colossus, TimeSplitters 2, Tomb Raider Legend OPS2M Demo 101 eur   Amplitude, Area 51, Beyond Good & Evil, Broken Sword 3: The Sleeping Dragon, Cold Winter, Freedom Fighters, Futurama, Goblin Commander: Unleash The Horde, Kill.Switch, Mashed, Maximo Vs. Army Of Zin, Metal Slug 3, R-Type Final, Viewtiful Joe 2, Virtua Fighter 4, XIII References Driver: Parallel Lines with MAP files in it - https://assemblergames.com/threads/ops2m-demo-disc-72-driver-parallel-lines-late-05-beta-demo-download.66661/ ↩ ", "excerpt": "This page is dedicated to listing Playstation 2 Demo Discs that contain developer debug symbols, either embedded inside the executable or as separate .map or .sym files. It was much more common for PS2 debug symbols to be leaked on Demo Discs than their retail counterparts during the early days...", "tags": ["ps2","symbols","games"], "image": "https://www.retroreversing.com/public/images/ps2/PS2 Demos with Debug Symbols.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "PS2 Official Software Development Kit (SDK)", "url": "/ps2-official-sdk", "content": "PS2 Official Software development Kit by SonyLast known version: 3.1.0 1First known version: 0.3.0 2Updates were provided to licenced PlayStation developers on ps2-pro.com, where the update contained just the files that have changed and could be dropped in place to overwrite the previous versions.SDK VersionsThe table below lists the relevant entries. SDK Version Publicly Leaked? Notes   0.3.0 No     0.4.0 No     0.5.0 No     1.0 No Sep 1999   1.1 No     1.2 No     1.3 No     1.3.1 No     1.4 No     1.4.1 No Feb 2000   1.4.2 No     1.4.3 No     1.5 No Apr 2000   1.5.1 No     1.5.3 No     1.5.7 No     1.6.0 No Star Wars Super Bomad Racing Demo   1.6.0a No     1.6.3 No SSX (PAL) Jun 2000   1.6.4 No     1.6.5 No Midnight Club (PAL)   1.6.6 No     2.0.0 No Timesplitters Aug 2000   2.0.3 No New library called \"libhig\" (High Level Graphics)   2.0.2 No This is Football 2002   2.0.5 No     2.0.6 No Nov 2000   2.1.0 No Gauntlet Dark Legacy Demo   2.1.1 No Dark Cloud Demo   2.1.3 No Resident Evil Code Veronica X   2.1.4 No Crazy Taxi   2.2.0 No Ecco the Dolphin: Defender of the Future Demo   2.2.1 No Jak and Daxter   2.2.2 No Shadow Hearts   2.2.4 No ICO (PAL)   2.3.0 No Grand Theft Auto III Jun 2001   2.3.2 No AirBlade Demo   2.3.4 No Shaun Palmers Pro Snowboarding Demo   2.4.0 No Crash Bandicoot The Wrath of Cortex Demo   2.4.1 No Parappa the Rapper 2 Demo   2.4.2 No Xenosaga Episode I Der Wille zur Macht   2.4.3 No 007 Nightfire   2.5.0 No Mx Superfly Demo   2.5.2 No VRally 3   2.5.4 No The Mark of Kri   2.5.5 No Virtual Fighter 4 Evolution (Korean version)   2.7.0 Docs leaked March 2003   2.7.1 No Jak II Neon Genesis Evangelion 2 (NTCS-J) MCMAN.IRX has PsIImcman 2710 2.7.2 No     2.8.0 No Fatal Frame 2   2.8.1 No Bloody Roar MCMAN.IRX has PSIImcman 2810   3.0.0 (publicly leaked with 2.7 Docs; maybe incomplete) Resident Evil 4 Nov 2003   3.0.1 No 24 The Game Mar 2004   3.0.2 publicly leaked maybe incomplete Shadow of the Colossus (PAL) Jul 2004   3.0.3 publicly leaked complete Jun 2005   3.0.4 No King of Fighters XI (NTSC-J) NTGUI.IRX has PsIIntgui2 3040   3.1.0 No     How to check version of SDK in useYou are really just looking for a string of the form “PSII* 2720” where the * denotes text that can change based on which library you search.You can search for Games that match a specific SDK version by running the following bash command:find . -name \"MCMAN.IRX\" -print0 | xargs -0 strings | grep -Hn \" 272\"Replace 2720 with the version number you want, e.g 272 is 2.7.2Running PS2 Official SDK under 64-bit ubuntu LinuxBy default the 64-bit version of ubuntu does come with the 32bit libraries that the SDK binaries have been linked to. So when you try to run any of the binaries it gives an error such as:iop-gcc: command not foundIn order to fix this you need to run the following commands:sudo apt-get update; sudo apt-get upgrade; sudo apt-get install ia32-libssudo dpkg --add-architecture i386sudo apt-get updatesudo apt-get install lib32z1SDK ContentsEmotion Engine (EE) ToolchainThe Emotion Engine Toolchain was developed by Cygnus based on GNUPro and has support for running the toolchain on windows, linux and Solaris. Tool Description ee-gcc C compiler modified from GNU GCC ee-g++ C++ GNU compiler ee-as GNU Assembler dvp-elf-as GNU Assembler for DVP (Vector unit Assembler?) ee-ld GNU Linker (Link object files together to create libraries) ee-gbd Standard GNU Debugger ee-run Simulator sky.ld Script that calls the Linker? ee-addr2line Get filenames and lines numbers from program addresses ee-ar GNU Archive handler ee-c++filt Demangle C++ symbols ee-nm print the list of symbols contained in an object file ee-objcopy Copy object files ee-objdump Standard GNU object dumper to display information about an object ee-ranlib List the index of an archive ee-size Display the size of sections in a file ee-strings Standard SNU strings utility to get strings from binary files ee-strip Strip an executable to remove debugging symbols DebuggingOne important point is that generating debug symbols doesn’t ever modify the code generation but there are some optimisation flags that can make debugging more difficult.Emotion Engine SimulatorThe simulator was released before developers got access to the hardware 3, it is basically an emulator which virtualizes the hardware of the emotion engine on a standard pc. This emulator was not cycle-accurate so was not guaranteed to produce the same result as running on the physical hardware.EENet LibraryEyeToy® Vision LibraryHTTPS LibraryIOP ToolchainLibcheck LibraryPoweroff Processing LibrariesRuntime Libraries 3.0.3Runtime Library DocsSample CodeSample DataSIF DMA PackageUSB PSP™ Communications LibraryDemo Disc SDKShell System PackageSDK SoftwareHDD CheckerMultiStream PackageNetwork Analysis SuitePerformance Analysis PackageQA ToolSulpha Sound UtilityVCLVRAMSnapVUEditYNCF ToolMiscLegend of termsThe table below lists the relevant entries. Name Meaning DECI2 Protocol for PC to communicate with PS2 TOOL DMAC … DMA Direct Memory Access? DNAS Online library for.. DSNet Suite of tools for debugging using a PS2 TOOL DVP D* Vector Processor? GIF Graphics Interface GS Graphics Synthesiser IOP Input/Output Processor SIF Serial Interface SPR Scratch Pad RAM SPU Sound Processing Unit TRC Technical Requirements Checklist VIF0 Vector Unit 0 Interface VIF1 Vector Unit 1 Interface VU0 Vector Unit 0 VU1 Vector Unit 1 References https://assemblergames.com/threads/sdk-and-tools-versions-information.35040/ ↩ https://assemblergames.com/threads/request-ps2-sdk-3-0-0.64540/ ↩ http://redhatpartnerweb.com/about/presscenter/cygnus_1999/sony2.html ↩ ", "excerpt": "PS2 Official Software development Kit by Sony Last known version: 3.1.0 1 First known version: 0.3.0 2 Updates were provided to licenced PlayStation developers on ps2-pro.com, where the update contained just the files that have changed and could be dropped in place to overwrite the previous versions. SDK Versions The...", "tags": ["ps2","symbols","sdk"], "image": "https://www.retroreversing.com/public/images/ps2/PS2 Software Development Kit.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Sony Playstation 3 Reverse Engineering", "url": "/ps3", "content": "IntroductionWelcome to our page dedicated to PS3 reverse engineering! The PlayStation 3 was a gaming console released by Sony in 2006, and has since become a beloved classic of the gaming world. If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to the right place.On this page, we’ve compiled a list of links to other pages that cover various topics related to PS3 reverse engineering. Whether you’re interested in understanding the hardware architecture of the console, analyzing game code, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to.So grab your DualShock 3 controller, and get ready to dive into the exciting world of PS3 reverse engineering!HardwareIf you’re interested in reverse engineering software for the Sony PlayStation 3 gaming console, it’s crucial to have a thorough understanding of the hardware that powers it. By comprehending the inner workings of the PS3 hardware, you can better understand how the software interacts with the hardware and how you can potentially modify or enhance it.This segment of our guide will provide you with comprehensive information and resources on the hardware of the Sony PS3, including retail, prototype, and development hardware.Retail HardwareThe PS3 moved from a MIPS-based CPU to the PowerPC architecture and its CPU was known as the Cell Broadband Engine, it was 64bit and and 6 Synergistic Processing Units (SPUs).The GPU was built by Nvidia and was called the RSX it was as powerful as a DirectX9 class GPU.All Posts Official PlayStation 3 Development Kit (Hardware) This post covers the hardware used to develop Playstation 3 games by major studios back in the day, for the software side see the post on the Official PS3 SDK.... ... Read More ps3 hardware devkit The PowerPC - Shaping the Future of Gaming The PowerPC - Shaping the Future of Gaming The PowerPC microprocessor is a name etched in the annals of gaming history. It’s a technological powerhouse that left an indelible mark... ... Read More hardware wii ps3 cpu ", "excerpt": "Introduction Welcome to our page dedicated to PS3 reverse engineering! The PlayStation 3 was a gaming console released by Sony in 2006, and has since become a beloved classic of the gaming world. If you’re interested in learning more about the technical aspects of this console and how it works,...", "tags": ["ps3"], "image": "/public/generated/placeholders/ps3.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Sony Playstation 4", "url": "/ps4", "content": "IntroductionWelcome to our page dedicated to PS4 reverse engineering! The PlayStation 4 was a gaming console released by Sony in 2013, and has since become a beloved classic of the gaming world. If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to the right place.On this page, we’ve compiled a list of links to other pages that cover various topics related to PS4 reverse engineering. Whether you’re interested in understanding the hardware architecture of the console, analyzing game code, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to.Mark Cerny: The Road to PS4 ArchitectureDarien features a recording of Mark Cerny’s “The Road to PS4” presentation from GameLabs 2013, where the lead architect details the technical philosophy behind the console’s design. Cerny explains the strategic shift from the complex Cell processor of the PS3 to the developer-friendly x86 architecture of the PS4, emphasizing the critical decision to utilize unified GDDR5 memory to reduce “time to triangle” for game creators.HardwareIf you’re interested in reverse engineering software for the Sony PlayStation 4 gaming console, it’s essential to have a strong understanding of the hardware that powers it. By comprehending the inner workings of the PS4 hardware, you can better understand how the software interacts with the hardware and how you can potentially modify or enhance it.In this section of our guide, we will provide you with detailed information and resources on the hardware of the Sony PS4, including retail, prototype, and development hardware.Retail HardwareThe PS4 has an 8-core AMD x64 class CPU paired with a AMD DirectX 11 class GPU with a few DirectX 12 features built in.Development HardwareWe have a post all about the Official Playstation 4 Development Hardware: Official PlayStation 4 Development Kit (Hardware) This post covers the hardware used to develop PlayStation 4 games by major studios back in the day, for the software side see the post on the Official PS4 SDK.... Operating SystemAccording to Phoronix the operating system for the PS4 is called OrbisOS and is based on FreeBSD 9.0 1.All Posts Official PlayStation 4 Development Kit (Hardware) This post covers the hardware used to develop PlayStation 4 games by major studios back in the day, for the software side see the post on the Official PS4 SDK.... ... Read More ps4 hardware devkit References Sony’s PlayStation 4 Is Running Modified FreeBSD 9 - Phoronix ↩ ", "excerpt": "Introduction Welcome to our page dedicated to PS4 reverse engineering! The PlayStation 4 was a gaming console released by Sony in 2013, and has since become a beloved classic of the gaming world. If you’re interested in learning more about the technical aspects of this console and how it works,...", "tags": ["ps4"], "image": "/public/generated/placeholders/ps4.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Sony Playstation Portable (PSP)", "url": "/psp", "content": "IntroductionWelcome to our page dedicated to PSP reverse engineering! The PlayStation Portable, or PSP, was a popular handheld gaming console released by Sony in 2004. If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to the right place.On this page, we’ve compiled a list of links to other pages that cover various topics related to PSP reverse engineering. Whether you’re interested in understanding the hardware architecture of the console, analyzing game code, or exploring the many mods and hacks that have been created by enthusiasts over the years, you’ll find a wealth of resources and information on the pages we’ve linked to.So grab your PSP, and get ready to dive into the exciting world of PSP reverse engineering!HardwareWhen announced the PSP was claimed to be as powerful as the PS2 and while it was certainly a very powerful system and the most impressive portable console on the market, it didn’t quite reach the performance of it’s home console sibling.The PSP was made up of: Dual Core MIPS 32-bit CPU with SIMD Matrix coprocessor GPU with embedded memory (Fixed Function Pipeline) Sound processing on second CPU coreRetail HardwareFor an in-depth look at the Playstation Portable’s Retail hardware architecture check out the excellent post by Copetti.org: PlayStation Portable Architecture - A Practical Analysis Check out the page on Copetti.org ALLEGREX CPUThe main CPU in the PSP was the ALLEGREX.VFPU - Vector Floating-point processorThe VFPU operates as a coprocessor for ALLEGREX it is a 128-bit vector floating-point processor.Operates synchronously with ALLEGREX’s clock (However, the write buffer operates at the bus clock speed.)Equipped with 32 128-bit matrix registersDesigned for vector and matrix calculations (The minimum access unit is 32 bits.)Capable of high-speed processing for geometry calculations, audio processing, and more.Development HardwareWe have a separate post all about the development hardware used to make PSP games: Official PlayStation Portable Development Kit For more information on the development hardware check out this post. PSP Game Software DevleopmentSN Systems ProDG SDKThere was a custom Software Development kit that was created by SN Systems before they got bought by Sony in 2005. It was later included in the official SDK when Sony bought the company. SN Systems ProDG PSP SDK For more information on the SN Systems SDK check out this post. File FormatsThis section lists all the file formats that are useful to know about for reverse engineering or developing PSP games.PSP Executable FormatsOn official PSP discs, there are actually two executables included in the SYSDIR folder: BOOT.BIN and EBOOT.BIN the former is uncompressed/unencrypted and suitable for reverse engineering and the latter is the encrypted version that is loaded by the PSP retail firmware. BOOT.BIN - uncompressed, unencrypted executable, typically used during development and debugging. EBOOT.BIN - encrypted, compressed version of the same executable. Sony’s encryption prevents casual tampering and reverse engineering.Sometimes the BOOT.BIN file is filled with zero bytes, this was more common with later PSP games, in which case you will need to decrypt EBOOT.BIN manually instead.If you only have an EBOOT.BIN don’t worry there are tools that can decrypt it back into a BOOT.BIN such as PRXDecrypter.On retail discs, games almost always ship with both executables, even though only EBOOT.BIN is guaranteed to be used by official firmware.Homebrew/custom firmware can be configured to load either, which is why BOOT.BIN remains useful for modders.PSP Game File FormatsOfficially the PSP either used physical Universal Media Discs (UMD) or PBP files to distrubte games, but there are a variety of formats available for storing PSP games: ISO - The most common format for PSP game files, an ISO is a disc image containing all the game disc’s data, essentially a copy of the Universal Media Disc (UMD) used by the PSP console. CSO - A compressed version of an ISO file that reduces file size for storage and sharing but might result in slightly longer load times during gameplay. PBP - Used for official PSP game files downloaded from the PlayStation Network, this format contains multiple compressed files such as the game executable, data, and media. CHD - Another compressed and compact format supported by many PSP emulators. DAX - An older compressed game file format used with early custom firmware. ELF - Contains the executable code of a PSP game and is usually associated with homebrew applications.Additionally, compressed zip and rar archives can sometimes be used by PSP emulators like PPSSPP run games without extracting.DAX - Dark_AleX’s compressed File FormatThe DAX file format is named after Dark_AleX, the pseudonym of a famous Spanish programmer who was a key figure in the PSP hacking and homebrew community.Dark_AleX developed custom firmware and various tools that enabled compressed PSP game images, including the DAX format, to overcome storage limitations of early PSP memory sticks.Specifically, the DAX ISO compressor was created by Dark_AleX as a solution to the small storage sizes of Memory Stick PRO Duo cards available at the time. His work allowed users to compress PSP game images into smaller files (DAX files) for easier storage and use on PSP devices with limited storage capacity.However more recently users found it more convenient to convert DAX files to the more popular compressed CSO format, which offers better compression and compatibility with almost all emulators unlike DAX.Common PSP FilesThere are some files that are common to almost all PSP games, they are often found in an extracted PSP game, this section will describe the purpose of each of them.UMD_DATA.BINUMD_DATA.BIN is a small binary file found inside PSP game disc images (UMD ISOs). It essentially contains header data about the UMD disc, mainly including the disc ID and partition information. This file helps the PSP or emulators identify and manage the game data on the UMD image correctly.In the structure of a dumped PSP game ISO, UMD_DATA.BIN serves as metadata that references the partitions (numbered typically 0001 and 0002) and the disc identity. It is crucial for proper loading and launching of the game when the ISO is used on the PSP system or emulators.It usually contains the following metadata separated by the pipe “|” (0x7C) character: Game disc ID (e.g “ULUS-10345”) Unique disc hash or identifier (e.g “E93842F88AADAA8C”) Partition number (e.g 0001) - often partition 0001 for the game data and 0002 for updates or extras Additional flags or markers (e.g “G”) - unsure what other values are valid, does G mean game?Tools like UMDGen, commonly used for creating and editing PSP UMD ISO files, can generate or edit UMD_DATA.BIN as part of managing the overall disc imagePARAM.SFOPARAM.SFO is a small but critical metadata file used by the PSP (and also PS3/PS4/PS5 with different schema). It’s stored in the root of the PSP_GAME folder and sometimes inside the SYSDIR/UPDATE folders too.The purpose of the file is to describes the game (or update package) to the PSP system, so that the XMB had the data for displaying the game icon, title, version, and other details. It also tells the firmware what minimum system software version is required to run.Typical Fields (for a PSP game): TITLE - Human-readable game title (what you see on XMB). DISC_ID - Unique identifier (e.g., ULUS-10409). CATEGORY - Type (e.g., MG for game, UG for update). BOOTABLE - Whether the package can be launched. PSP_SYSTEM_VER - Minimum firmware version required. PARENTAL_LEVEL - Restriction flag for parental controls. REGION - Sometimes embedded to limit compatibility.The PSP will refuse to boot the game if PARAM.SFO is missing or corrupted, so make sure that when modding or trimming ISOs, PARAM.SFO must stay intact in the root!The update folder’s PARAM.SFO is only used if you try to run the included firmware updater.It can be edited (with tools like PSP SFO Editor) to spoof firmware requirements, useful for running older ISOs on newer/different firmware.PSP Development FormatsSome file formats used in the creation of PSP games: .GIM - 2D Image Texture format similar to the PS1 TIM image format .GMO - 3D model format .PMF - PlayStation Media Format used for full-motion video in games.PMF - PlayStation Media FormatOn the PSP, .pmf files are PlayStation Media Format containers. They are a proprietary Sony format used mainly for full-motion video (FMV) in games e.g for logos, intro movies, attract/demo sequences, cutscenes and credits.Internally, PMF files are very similar to MPEG-4 video with H.264-like video and ATRAC3+ audio.They are typically played with the psmf.prx and libpsmfplayer.prx modules.They are not essential to gameplay itself so they can be removed and the game usually still runs, but it may crash when trying to load the missing FMV unless the executable is patched. So its best to replace them with 0 byte files if you want to save space or skip cutscenes.GamesPSP Games with Debug SymbolsAn excellent way to start reverse engineering is to find games where the developers accidentally left the Debug symbols in the retail release of the game. While this is rare due to Sony’s TRC requirements, it has happened for some PSP games. These gives you access to all the original function and variables names that were used in the retail source code so are very valuable for reversers! Playstation Portable Games with Debug Symbols For a list of PSP games that have debug symbols available check out this post. Reverse Engineering PSP Games with GhidraFirst step is to find your BOOT.BIN file, normally in the PSP_GAME/SYSDIR folder of the extracted game ISO. If you only have an EBOOT.BIN file you will need to convert it to a BOOT.BIN with a tool such as PRXDecrypter.Since BOOT.BIN files are standard ELF executables compiled for the MIPS R4000 (little-endian) instruction set you can import directly into Ghidra without any plugins!Now double click on BOOT.BIN in the Ghidra tree view and Ghidra will then ask you if you want to analyze the imported binary, say yes and keep the default settings for now.Give it some time to analyze, depending on the size of the executable it could take up to 10 or 20 minutes.All Posts Matrices (Maths for Game Developers) Introduction to Matrices A matrix is a table of numbers, but in game code the important part is what that table does 1. Matrices let engines package translation, rotation, scale,... ... Read More maths psp ds Official PlayStation Portable Development Kit Official PSP Development Kit hardware The hardware supports booting games from both the UMD and DVD drive, the DVD drive can even boot games from standard DVD-R/RW and so many... ... Read More psp hardware devkit Official Sony PSP SDK Introduction What versions of the SDK have been leaked? Version 1.5.0 (psp_full_sdk_JSR) from 2005 Version 6.6.0 (psp_sdk_660) from 2011 This page will document the latest release version 6.6.0 as it... ... Read More psp sdk PSP Saints Row Undercover Officially Released Prototype Saints Row Undercover Also known as Saint Row - The Fall earlier in development, this is one of the rare few prototype games released by the developers themselves, in this... ... Read More psp games Playstation Portable Games with Debug Symbols The Sony Playstation portable used encrypted executables known as EBOOT.BIN, these are basically just an encrypted ELF file and it is possible to decrypt them with the correct tools. Some... ... Read More psp symbols games Quaternions (Maths for Game Developers) Introduction to Quaternions A quaternion is a four-number rotation representation, usually written as { x, y, z, w } or as a vector part plus a scalar part 1. In... ... Read More maths psp ds SN Systems ProDG PSP SDK Introduction What is the SN Systems ProDG PSP SDK? SN Systems were in the business of creating excellent 3rd party development tools and many game development studios relied on them... ... Read More psp sdk snsystems Sony Playstation Vita Reverse Engineering Awesome list of Sony Playstation Vita Game Development and Reverse Engineering information ... Read More vita psp introduction handhelds ", "excerpt": "Introduction Welcome to our page dedicated to PSP reverse engineering! The PlayStation Portable, or PSP, was a popular handheld gaming console released by Sony in 2004. If you’re interested in learning more about the technical aspects of this console and how it works, you’ve come to the right place. On...", "tags": ["psp"], "image": "/public/generated/placeholders/psp.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Official PlayStation Portable Development Kit", "url": "/official-psp-devkit", "content": "Official PSP Development Kit hardwareThe hardware supports booting games from both the UMD and DVD drive, the DVD drive can even boot games from standard DVD-R/RW and so many prototype PSP games are actually written on standard rewritable DVDs.PSP-1000 Standard Commander ArmIn order to use the DevKit to play games you need a controller, and what better controller than the psp itself! A custom PSP Controller Arm was provided with the devkit for such a purpose. It wasn’t a real psp and the inside board were very different to a retail psp, it was mainly just an interface for providing button in put and screen output for the developers to see what it would look like on a real psp.Here is a tear down of the controller hardware by RetroGameTech 1:PSP Go Commander ArmWhen the PSP Go console came out there was an optional accessory for the development kit to switch the standard PSP controller to a version that is basically a PSP-Go shell with all the PSP chips ripped out and it is pretty much just used as a controller and display.2The Testing Tool (DTP-H1500)The testing tool tower contains both a DVD and UMD drive with a toggle to switch between the two, it contains a slot to insert the PSP memory stick, a usb-mini port, a headphone port and a port to connect the Commander Arm. It also contains a number of DIP switches but it is unclear what each DIP-switch does.Notice that this does not have an ethernet port so can’t be used for debugging unless using the slow usb serial or WLAN interface 3The Development Unit (DTP-T1000) The front of the development Unit looks pretty much identical to the Testing tool (DTP-H1500), but on the back it contains an ethernet port to allow debugging with a host PC. this was the recommended choice for programmers as it was easy to send code to the development unit via LAN and debug the code by setting breakpoints and viewing memory/registers. Software Development KitSince the development TOOL doesn’t have a hard drive and I can’t find references to any CDs that contains the development kit files, presumably developers had to logon to the SCE developer website to download the SDK, compilers etc for their PC.A PSP SDK has never been leaked probably because it was just a download that most people would do and then throw away, much easier to loose than a physical CD like previous Sony SDKs.References What’s Inside? - Sony PSP Development Controller - DTP-H110 - YouTube ↩ SCEE Hardware Overview ↩ Hooking up DTP-H1500 to computer ↩ ", "excerpt": "Official PSP Development Kit hardware The hardware supports booting games from both the UMD and DVD drive, the DVD drive can even boot games from standard DVD-R/RW and so many prototype PSP games are actually written on standard rewritable DVDs. PSP-1000 Standard Commander Arm In order to use the DevKit...", "tags": ["psp","hardware","devkit"], "image": "/public/images/psp/PSP Development Kit.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Official Sony PSP SDK", "url": "/pspsdk", "content": "IntroductionWhat versions of the SDK have been leaked? Version 1.5.0 (psp_full_sdk_JSR) from 2005 Version 6.6.0 (psp_sdk_660) from 2011This page will document the latest release version 6.6.0 as it is the most complete. The 1.5.0 JSR version only contains the files that get installed to C:\\usr\\local\\psp\\devkit on windows.Wheras the more complete version also contains the ProDG installers and additional documentation.What was included in the SDK?Later versions of the SDK included the ProDG development kit provided by SN Systems, which provided a way to compile PSP games using Visual Studio 2005/2008/.NET as an alternative to the Cygwin (unix like) development environment provided in the rest of the SDK.For information on the ProDG SDK we have a separate post: SN Systems ProDG PSP SDK For more information check out this post. High Level Documentation (/Docs) /Docs This folder contains documentation for the Technical Requirementments Checklist and some conference slides, along with the SN Systems ProDG documentation. This folder also contains the following sub-directories: SNTools - Documentation on SN Systems ProDG Tools ConferenceContent - Password protected slides from conferences in 2005 in both English and Japanese TRC - Technical Requirements Checklist - It contains important rules and restrictions for creating master discs for PSP games The contents of the SNTools folder will not be discussed in this post as we have a sepeate page for all the SN Systems ProDG SDk information: SN Systems ProDG PSP SDK For more information check out this post. The files in this folder are described in the table below: File Name Extension Description PSP_Setup_Guide-English .pdf 40 page guide on setting up the SDK on both windows and linux and connecting to the development hardware PSP_Setup_Guide-Japanese .pdf Japanese Version PSP_Setup_Guide-Korean .pdf Korean Version Conference Content /Conference This folder contains Powerpoint files from Sony seminars hosted in both February 2005 and July 2005, with the February content only being in Japanese but the July content being in both English and Japanese. We can’t open these files as they are protected by a password and thus can’t describe what is in them. One of the files was unencrypted (Seminar2005-02_VFPU-Japanese) and it’s from the Sony software development seminar that took place on 28th February 2005. The VFPU session has this cool screenshot of a dragon example to show that the VFPU is suitable for real-time transformations of 3D models, such as animations:The files in this folder are described in the table below: File Name Extension Description Seminar2005-02_GRAPHICS-Japanese .pps   Seminar2005-02_KERNEL-Japanese .pps   Seminar2005-02_MASTER-Japanese .pps   Seminar2005-02_MPEG-Japanese .pps   Seminar2005-02_NETWORK-Japanese .pps   Seminar2005-02_SOUND-Japanese .pps   Seminar2005-02_Utility-Japanese .pps   Seminar2005-02_VFPU-Japanese .pps 19 slides that talks about how to Utilize the VFPU Effectively (libvfpu) and Key Considerations. Seminar2005-07_browser-English .pps   Seminar2005-07_graphics-English .pps   Seminar2005-07_network-English .pps   Seminar2005-07_savedata-English .pps   Seminar2005-07_sound-English .pps   Seminar2005-07_umd-English .pps   Seminar2005-07_update-English .pps   Seminar2005-07_browser-Japanese .pps   Seminar2005-07_graphics-Japanese .pps   Seminar2005-07_network-Japanese .pps   Seminar2005-07_savedata-Japanese .pps   Seminar2005-07_sound-Japanese .pps   Seminar2005-07_umd-Japanese .pps   Seminar2005-07_update-Japanese .pps   Technical Requirements Checklist (/TRC) /TRC This folder contains the Technical Requirements Checklist that need to be followed in order to get Sony to green light a PSP game. It has strict brand guidelines on how to use the Sony and Playstation branding along with all the naming conventions in all the different languages and PSP versions. It also has a document of all the test cases that each game goes through before mastering. This folder also contains the following sub-directories: Logo - Adobe Illustrator (.ai) vector images of the allowed Sony logos One of the test cases makes sure that all games that get published do not contain debug symbols unfortunately: It is forbidden to include the following types of files in the master in any form, even in archive format. Data and files used only for development and debugging purposes such as program source files, executable files with symbols, map files, and driver modules used in title development Data and files designed only for use on other platforms such as Windows wallpaper and screensavers The files in this folder are described in the table below: File Name Extension Description BrandGuideline_E_100729L .pdf   BrandGuideline_J_101112L .pdf Japanese version of the Brand Guidelines Frequency_Specification-Guideline-English .pdf 138 page brand guidelines on how to use the PlayStation brands (including PsOne, Ps3 etc) Frequency_Specification-Guideline-Japanese .pdf Japanese version of the brand guidelines Frequency_Specification-Guideline-Korean .pdf Korean version f the brand guidelines PSP_NC_E1000_WW_temp_20111005 .pdf PSP Naming Conventions for PSP-E1000 series - Temporary release from October 5, 2011 PSP_NC_N1000_WW_temp_1.01 .pdf PSP Naming Conventions for PSP-N1000 series - Temporary release 1.01 August 2009 PSP_NC_v200_WW_temp .pdf PSP Naming Conventions for PSP-2000 PSP_NC_v3.00_WW_temp_1.01 .pdf PSP Naming Conventions for PSP-3000 series - Temporary release 1.01 January 2009 psp_nc_de_3_10 .pdf PSP Naming Conventions for German psp_nc_en_3_10 .pdf PSP Naming Conventions for English psp_nc_es_3_10 .pdf PSP Naming Conventions for Spanish psp_nc_fr_3_10 .pdf PSP Naming Conventions for French psp_nc_it_3_10 .pdf PSP Naming Conventions for Italian psp_nc_ja_3_10 .pdf PSP Naming Conventions for Japanese psp_nc_ko_3_10 .pdf PSP Naming Conventions for Korean psp_nc_nl_3_10 .pdf PSP Naming Conventions for Dutch psp_nc_pt-PT_3_10 .pdf PSP Naming Conventions for Portuguese psp_nc_ru_3_10 .pdf PSP Naming Conventions for Russian psp_nc_zh-Hans_3_10 .pdf PSP Naming Conventions for Chinese Simplified psp_nc_zh-Hant_3_10 .pdf PSP Naming Conventions for Chinese Traditional psptestcases_forTRC50-English .pdf 94 page document on all the tests that are done on every game when the master copy is received by Sony psptestcases_forTRC50-Japanese .pdf Japanese version of all the test cases ptrc52-English .doc, .pdf TRC for PSPtm Software, Version 5.2, including information on how to submit the TRC form ptrc52-Japanese .doc, .pdf Japanese version of the TRC PSP PGF Fonts (pgf_archives_1.0.0) / This folder contains infromation on the officially supported fonts for PSP. The PGF font format is a proprietary font format developed by Sony specifically for the PlayStation Portable (PSP). It is used to render text in PSP applications and games efficiently, taking into account the constraints of the PSP hardware. PGF stands for PlayStation Game Font, and it is part of the PSP’s system libraries. They are mainly: FTT-Matisse Pro Latin - serif font FTT-NewRodin Pro Latin - san serif font AsiaKNHH-SONY-uni - Korean font In various different combinations such as bold italic etc This folder also contains the following sub-directories for each size of the font, containing all the .pgf files for each variant (korean, japanese etc): org - the original version of the font 6pt - 6 point version of the font 8pt - 8 point version of the font 10pt - 10 point version of the font 14pt - 14 point version of the font 18pt - 18 point version of the font 22pt - 22 point version of the font Developers were free to use all the PGF files that are contained in this archive file via “libfont,” which is included in PSP Runtime Library 2.0.0 or later. The files in this folder are described in the table below: File Name Extension Description PgfContentsTable-English .pdf A single page table of the details of fonts for distribution (1.0.0), NewRodin Pro Latin and Matisse Pro Latin Readme_PgfArchives-English .txt Brief details on the files located in this folder Cygwin Software Development Kit (/devkit) /devkit This folder contains the main software development kit for both Window and Linux. This folder also contains the following sub-directories: 1st_read - The initial documentation to be read first bin - Binary Executables for compiling/building in both cygwin and linux (also known as psp-utils) bin.windows - Windows version of the build tools such as compilers bin.linux - Linux version of the build tools such as compilers document - Main Documentation include - SDK header files lib - SDK Static Library files module - Compiled PRX modules src - Source code to the libraries sample - Examples for using the PSP SDK, e.g for playing sound or displaying graphics on the PSP data - Data used in the sample applications contrib - A Photoshop plugin for the GIM texture format htool_updater - Update for the PSP Tool hardware flash - tips - tool_flash - tool - setup - Hardware Tool instruction manual The files in this folder are described in the table below, I have removed the japanese and korean versions to avoid duplication: File Name Extension Description Install_e .bat Windows Batch file for moving the bin.windows exe files into the bin directory Readme-English .txt Brief description of the Contents of the devkit directory Readme-Hardware_tool_Kernel_Update_Binary-English .txt Changelog for htool_updater folder Readme-PSP_Supplement_Font-English .txt Limited explanations of some font related files Readme-PSP_Utils_Windows-English .txt Lists all the files in bin.windows (psp-utils) and a changelog Readme-Testing_tool_Kernel_Update_Binary-English .txt List of files in the flash folder and a changelog Install instructionsWhen first receiving the devkit the developers had to run a few commands to install the SDK. Cygwin > cd /usr/local/psp Cygwin > unzip psp-utils-x.x.x-windows.zip Cygwin > cd ./devkit Cygwin > ./Install_e.batThis will move the Linux commands in /usr/local/psp/devkit/bin to /usr/local/psp/devkit/bin.linux and will install commands for Windows XP.After installation, /usr/local/psp/devkit/bin.linux and /usr/local/psp/devkit/bin.windows may be deleted.Initial documentation (/1st_read) /1st_read This folder contains the bare bones documentation that should be read as soon as recieveing the development kit, such as setting up the system. The files in this folder are described in the table below: File Name Extension Description Changes-English .txt History of changes to the whole devkit going all the way back to 0.5.0 Flash_Update_Instruction_H1500-English .txt A note on updating the DTP-H2500/DTP-H1500 (A) firmware Flash_Update_Instruction_T1000-English .txt A note on updating the DTP-T2000/DTP-T1000 (A) firmware Hardware-Restriction-English .pdf 16 page PDF on low level restrictions on assembly instructions on both the CPU and VFPU Important_notice-English .txt A note on providing a system update with your game due to operation of titles created with the new version of Runtime Library will not be guaranteed on the old PSP system software. PSP_Setup_Guide-English .pdf 40 page PDF on setting everything up Sample_List-English .txt Description of all the samples included in the sample folder PSP Utils Binary Toolchain (/bin) /bin The /bin folder is the result of running the Install_e.bat install script, and copies the windows version of psp-utils into the /bin folder, where the linux versions are their by default. As such the contents of this folder will not be documented as they are the same as the contents in bin.linux and bin.windows folders. Linux psp-utils (/bin.linux) /bin.linux This folder contains all the command line programs to build and debug PSP games in a Linux environment. The executables that start with “ds” are part of “dsnet for PSP” which is a debugging environment that uses the DECI2P protocol. It enables the host and the PSP tool to work together so that applications that will run on the target can be developed more efficiently. The files in this folder are described in the table below: File Name Extension Description binary2elf N/A pspbin2elf creates an elf file for PSP when no specification is made on the command line dsdcons N/A dsdcons is a console program that is the companion to dstdb’s remote console input/output function. dstdb opens a DTTYP protocol server on the specified port number so that it can be used by the remote console dspcons N/A dspcons is a console program that is the destination of TTYP input/output of the target program dspkill N/A dspkill is a program for forcibly disconnecting a client that is connected to a specific protocol from the client programs that are connected to the entire target dspmcons N/A dspmcons is a dedicated console program for running the dsnetm_psp debug console, which runs as CP on the PSP TOOL dspreset N/A dspreset is a client program for resetting the entire target. dspstat N/A dspstat is a client program for displaying a list of client programs that are connected to the entire target. It is used to identify people who are currently using the target. dsptun N/A dsptun is a program that relays packets wrapped in the ETHERP protocol from the target to a linux tun device, when the Ether over DECI2p feature is enabled by setting bit 15 of the boot parameter. dstdb N/A dstdb is a source-level/instruction-level debugger. dsxfilesv N/A dsxfilesv is a file server program for processing Remote File Access requests that are sent from the target program. dsxlist N/A dsxlist is a client program for displaying a list of modules that are loaded on the target. dsxping N/A dsxping is a client program for diagnosing whether or not there is a response from the target program. Normally, this client program need not be used. dsxstart N/A dsxstart is a client program for loading modules on the target. It operates in a similar manner as dstdb’s mstart command. enlargeprx N/A   prx-version-off N/A   prxinfo N/A Displays information about PSP relocatable execution format (.prx) objects. psp-addr2line N/A   psp-ar N/A Archiver psp-ar-util N/A   psp-as N/A Assembler psp-c++ N/A   psp-c++filt N/A   psp-cpp N/A   psp-g++ N/A C++ compiler psp-gcc N/A C compiler psp-gcov N/A Coverage collects the number of times each line of source code is executed in terms of basic blocks. psp-gnu-strip N/A Deletes symbol information from an elf-format relocatable object. psp-gprof N/A Profile calculates the number of times the routines in a module are executed and how long it takes to execute each routine. psp-ld N/A Linker psp-nm N/A Outputs a list of symbols in an object psp-objcopy N/A Converts the format of an object file psp-objdump N/A Displays information about an object file psp-path-setup N/A PSP compiler path search and setup psp-prver N/A Command for confirming the version of the static library psp-prx-strip N/A Deletes symbol information from a PSP relocatable execution format (.prx) object. psp-ranlib N/A Generates index information for an archive psp-readelf N/A   psp-selcomment .rb Comment language filter, e.g only including english comments psp-size N/A Displays the size of each section in an object psp-strings N/A Gets the ASCII strings from an ELF psp_boot_packager N/A The psp_boot_packager tool is used for packaging. pspbin2elf N/A same as binary2elf pspexportpickup N/A The pspexportpickup command is used to find mangled symbols in an object file that correspond to exported functions and variables previously specified in SCE_LIB_EXPORTPICKUP_*() macros and generates a library definition file in C source code. pspfixup N/A Converts an elf-format relocatable object to the PSP relocatable execution format (.prx). pspgcsection N/A An internal auxiliary tool psplibgen N/A Generates stub information required for linking objects. pspprofutil N/A Same as psp-gprof but for prx files pspsplitoverlay N/A This command separates the overlay file off the PSP ELF that is generated with an overlay segment attached. pspuidfnkeygen N/A   Windows psp-utils (/bin.windows) /bin.windows This folder contains thw windows compiled versions of the build utilities. The files in this folder are described in the table below: File Name Extension Description binary2elf .exe binary2elf creates an elf file for PSP when no specification is made on the command line dsbloadp .exe dsbloadp is a client program for sending the PSP boot code to the target. dsdcons .exe dsdcons is a console program that is the companion to dstdb’s remote console input/output function. dspcons .exe dspcons is a console program that is the destination of TTYP input/output of the target program. dspkill .exe dspkill is a program for forcibly disconnecting a client that is connected to a specific protocol from the client programs that are connected to the entire target. dspmcons .exe dspmcons is a dedicated console program for running the dsnetm_psp debug console, which runs as CP on the PSP TOOL. dspreset .exe dsbloadp is a client program for sending the PSP boot code to the target. dspstat .exe dspstat is a client program for displaying a list of client programs that are connected to the entire target. dstdb .exe dstdb is a source-level/instruction-level debugger. dsxlist .exe dsxlist is a client program for displaying a list of modules that are loaded on the target. dsxping .exe dsxping is a client program for diagnosing whether or not there is a response from the target program. dsxstart .exe dsxstart is a client program for loading modules on the target. enlargeprx .exe   prx-version-off .exe   prxinfo .exe Displays information about PSP relocatable execution format (.prx) objects. psp-ar-util .exe   psp-prver .exe Command for confirming the version of the static library psp-prx-strip .exe Deletes symbol information from a PSP relocatable execution format (.prx) object. psp_boot_packager .exe The psp_boot_packager tool is used for packaging. pspbin2elf .exe same as binary2elf pspexportpickup .exe The pspexportpickup command is used to find mangled symbols in an object file that correspond to exported functions and variables previously specified in SCE_LIB_EXPORTPICKUP_*() macros and generates a library definition file in C source code. pspfixup .exe Converts an elf-format relocatable object to the PSP relocatable execution format (.prx). pspgcsection .exe An internal auxiliary tool psplibgen .exe Generates stub information required for linking objects. pspprofutil .exe Same as psp-gprof but for prx files pspsplitoverlay .exe This command separates the overlay file off the PSP ELF that is generated with an overlay segment attached. pspuidfnkeygen .exe   GIM Photoshop Plugin (/contrib/tool/gimPhotoshopPlugin) /gimPhotoshopPlugin This folder contains a photoshop plugin for supporting the PSP texture format .GIM (Similar to the PS1 TIM format). The files in this folder are described in the table below: File Name Extension Description GIM_Photoshop_Plugin_Overview-English .pdf 6 page PDF explaining how to use the photoshop plugin readme_e .txt Brief explanation and changelog for the photoshop plugin tgGimFormat .8bi The Photoshop 6.0 Plugin for GIM image format When running the plugin in Photoshop 6.0 you get the following dialog to save to GIM format:Data (/data) /data This folder contains data used for the samples to keep them separate from the actual source code. This folder also contains the following sub-directories: ccc - libccc Data File dvdumd - DVD/UMD(TM) Image File for the dvdumd sample (sample/dvdumd) model - Model Data File for GMO movie - PSMF Stream File and MP4 Stream File or_dict - libface data picture - Image Data File for GIM scene - A sample scene sound - Data File for libsndp for the playsmf sample (sample/sound/playsmf) The files in this folder are described in the table below: File Name Extension Description Readme_English .txt brief description of all the folders in the data folder an a changelog Readme_Sample_Code_Data-Graphics-English .txt Changelog for the Graphics samples Readme_Sample_Code_Data-Movie-English .txt Changelog for the Movie samples Readme_Sample_Code_Data-Sound-English .txt Changelog for the Sound samples Module (/module) /module This folder contains the PSP runtime modules that ship with the SDK as .prx binaries. These are loadable kernel or user-mode components rather than normal static libraries. The table below covers the 35 PRX modules present in the leaked SDK tree. They include utility libraries, multimedia support such as libpsmfplayer, and small diagnostic modules such as show_macaddr. The files in this folder are described in the table below: File Name Extension Description libadler .prx Implements Adler-32 checksum computation. libbase16 .prx Provides Base16 (hexadecimal) encoding and decoding. libbase32 .prx Provides Base32 encoding and decoding functionality. libbase64 .prx Implements Base64 encoding and decoding. libccc .prx Character Code Conversion utilities libdeflt .prx libdeflt is a library for expanding data in zlib format, deflate format, gzip format, and PK0304 zip format which are defined in RFC 1950, RFC 1951, and RFC 1952. libface .prx Manages face detection or recognition utilities. libfont .prx Handles font rendering and manipulation. libfpu .prx FPU functions libheap .prx Provides heap memory management functionality. libmd5 .prx Implements the MD5 hashing algorithm. libmt19937 .prx Mersenne Twister random number generator (MT19937). libpsmfplayer .prx Plays PSP Motion Format (PSMF) video files. libpuny .prx Handles Punycode encoding for internationalized domain names. libqpcode .prx Encodes and decodes Quoted-Printable format. libsfmt11213 .prx SIMD-oriented Fast Mersenne Twister (11213 parameters). libsfmt1279 .prx SIMD-oriented Fast Mersenne Twister (1279 parameters). libsfmt132049 .prx SIMD-oriented Fast Mersenne Twister (132049 parameters). libsfmt19937 .prx SIMD-oriented Fast Mersenne Twister (19937 parameters). libsfmt216091 .prx SIMD-oriented Fast Mersenne Twister (216091 parameters). libsfmt2281 .prx SIMD-oriented Fast Mersenne Twister (2281 parameters). libsfmt4253 .prx SIMD-oriented Fast Mersenne Twister (4253 parameters). libsfmt44497 .prx SIMD-oriented Fast Mersenne Twister (44497 parameters). libsfmt607 .prx SIMD-oriented Fast Mersenne Twister (607 parameters). libsfmt86243 .prx SIMD-oriented Fast Mersenne Twister (86243 parameters). libsha0 .prx Implements the SHA-0 hashing algorithm. libsha1 .prx Implements the SHA-1 hashing algorithm. libsha224 .prx Implements the SHA-224 hashing algorithm. libsha256 .prx Implements the SHA-256 hashing algorithm. libsha384 .prx Implements the SHA-384 hashing algorithm. libsha512 .prx Implements the SHA-512 hashing algorithm. psmf .prx Provides core functionality for handling PSP Motion Format headers. pspnet_ap_dialog_dummy .prx Dummy module for PSP network access point dialogs. scan .prx Performs scanning operations (e.g., QR codes or network). show_macaddr .prx Displays the device’s MAC address. What is a PRX file?On PSP, a PRX file is a relocatable module that the kernel loader can map into memory at runtime.It is related to ELF, but it is packaged for the PSP module loader rather than as a plain standalone executable.That distinction matters because PRX files usually carry: Imports and exports - Function and variable linkage data so one module can call into another resident library Module metadata - The module name, attributes, version fields, and startup or shutdown entry points used by the loader Relocations - Fixups that let the loader place the module at a suitable address in memoryIn practice, a PSP build often starts from ordinary ELF objects and then converts them into PRX modules for loading on hardware or devkit targets.That is why this SDK ships with tools such as pspfixup, psplibgen, prxinfo, and psp-prx-strip.Those utilities handle PRX conversion, stub generation, inspection, and symbol stripping.Documentation (/document) /document This folder contains all the main documentation for the Software Development Kit This folder also contains the following sub-directories: chm - CHM version of the documentation in both english and japanese (PSP™ Programmer Tool Runtime Library) html - HTML version of the documentation in both english and japanese (PSP™ Programmer Tool Runtime Library) pdf - PDF version of the documentation PSP_DevKit_6.6.0_Doc_Index_e - Index (.idx) files format - GIM, GMO and GSO format information in PDF format sound - PHD/PBD Format documentation in PDF format hardware_manual - Hardware Manual Release 1.0.0 (2006) tool - PDF Tool documentation The files in this folder are described in the table below: File Name Extension Description PSP_DevKit_6.6.0_Doc_Index_e .pdx Adobe Acrobat Portable Document Index file, index of the other PDF files Readme-CHM-English .txt Lists the documentation available in CHM format Readme-HTML-English .txt Lists the documentation available in HTML format Readme-NP_Dev-Users_Guide-English .txt It contains documents that describe necessary information to develop a PlayStation Network enabled application Readme-PDF-English .txt Change log of pdf document changes and how t use the .PDX file We will only document the PDF version of the documentation files in this post as they are equal to the CHM and HTML versions.PDF Documentation (/document/pdf) /pdf This folder contains… This folder also contains the following sub-directories: overview - General overview o topics such as the compiler toolchain movie - Documentation on Movie playback such as AVI Encoding, MP4 Playback debug_support - Documentation related to debugging PSP software network - Documentation on the networking libraries such as pspnet others - Misc documentation on libraries like Adler and Game authoring fpu-vfpu - Low level FPU and VFPU SDK documentation guideline - General guidelines for tasks such as creating a custom PSP system theme image_recognition - Documentation for libface, which is a library for analyzing grayscale images and recognizing the faces of people whose pictures appear in those images still - JPEG and PNG Library documentation peripheral - References for APIs such as Battery, Storage and UMD graphics - References for the APIs for graphics such as 3D models (GMOs) and graphics engine sound - References for the Sound APIs for MP3/VOB, sound input etc kernel - Low level kernel information like threading a cache tool - Documentation on software related to the Hardware Tool utility - Documentation on Browser, RSS Reader utilities The files in this folder are described in the table below, they are mainly related to the Network Platform (NP), specifically the PlayStation Network Server Management Tools or SMT for short: File Name Extension Description NP-Product_Management_Guide_e .pdf NP Product Management Guide NP_SMT_Matching2-Users_Guide_e .pdf PlayStation Network SMT - NP Matching 2 Tools User’s Guide NP_SMT_Portal-Users_Guide_e .pdf PlayStation Network SMT - Portal User’s Guide NP_SMT_TPPS-Users_Guide_e .pdf PlayStation Network SMT - Title Patch Publishing System User’s Guide NP_SMT_TSSS-Users_Guide_e .pdf PlayStation Network SMT - Title Small Storage Service User’s Guide SMT are a group of web-based tools that support the development of applications with respect to the various PlayStation®Network communication services.In the course of testing the behavior of applications in the communication services (such as the NP score ranking service, NP matching 2 service, and patch distribution service), SMT functions can be used to modify PlayStation®Network server settings and to obtain registered data.The SMT Portal is a portal site for connecting to the various SMT tools and for managing all the user and organization privileges for the tools.The “administrator”, the user who registered the NP Communication IDs and title IDs (product codes) for an organization, can set the access privileges for the organization and the organization’s users using the SMT Portal.Overview (/document/pdf/overview) /overview This folder contains overview information on topics such as the compiler and how to package DLC for your game for the Playstation Store. Note that psp-gcc 1.x is based on GCC 3.3.x and psp-gcc 2.x is based on GCC 4.0.x. The files in this folder are described in the table below: File Name Extension Description Additional_Game_Data-Packaging-English .pdf This document explains the step-by-step procedure needed to create a PSP additional gamedata package. It describes how to create data and programs so they can be distributed as DLC Compiler-Overview-English .pdf Overview of the GCC based compiler toolchain ContentInformation-Check-English .pdf This is a function which checks the files which make up content information shown on the XMB Downloadable_Game-Notes-English .pdf Notes on Creating PSP Downloadable Games such as difference in access timing compared to UMD Downloadable_Game-Packaging-English .pdf This document describes the procedure for creating a PSP downloadable game package. Game_MasterDisc-Users_Manual-English .pdf Game Master Disc Creation Procedure PSP_Setup_Guide-English .pdf 40 page guide on setting everything up PSP_System_Overview-English .pdf 8 Page high level hardware architecture Patch-Overview-English .pdf A patch system is provided that can add or replace any program or data file of a previously released application supplied on a UMD, or of a PSPTM downloadable game application installed on a Memory Stick. Patch-Packaging-English .pdf PSP Patch Package Creation Guide Programming-Overview-English .pdf PSP Programming Tutorial Debug_support (/document/pdf/debug_support) /debug_support This folder contains information on debugging PSP software with Dsnet. Dsnet is a debugging environment that uses the DECI2P protocol. It enables the host and the PSPTM tool to work together so that applications that will run on the target can be developed more efficiently. The files in this folder are described in the table below: File Name Extension Description BSOD-Overview-English .pdf Blue Screen of Death module documentation that saves the state when a crash occurs. Dsnet-Client-English .pdf dsnet for PSP Overview Dsnet_Command_Reference-English .pdf dstdb source-level/instruction-level debugger Command Reference GPI_GPO-Reference-English .pdf 6 page GPI / GPO Manipulation Utility Reference Profiler-Reference-English .pdf Profiler Operation Utility Reference, documentation for the low level profiling API USB_Serial-Overview-English .pdf USB Serial Driver Overview, The USB serial driver enables the TOOL (DTP-T1000 / DTP-H1500) to communicate with a PC via serial communication over USB using the Abstract Control Model (ACM) of the USB Communication Device Class (CDC). USB_Serial-Reference-English .pdf USB Serial Driver Reference, low level API documentation BSOD is a module which, when erroneous processing occurs in a program on the DTP-H1500, if possible halts the program in that state and allows the conditions in which the error occurred to be observed.It enables the values of registers and of the program counter, the state of threads, and the state of the synchronization primitives such as semaphores and event flags, to be observed as they were at the time when the crash occurred.FPU and VFPU (/document/pdf/fpu-vfpu) /fpu-vfpu This folder contains documentation for the Vector FPU, the Allegrex CPU and the FPU. The files in this folder are described in the table below: File Name Extension Description ALLEGREX-Builtin_Function-Reference-English .pdf Built in CPU functions like __builtin_allegrex_clz VFPU_Intrinsics-Overview-English .pdf The psp-gcc VFPU intrinsics are functions which enable gcc to use V4SF and V16SF mode types as built-in types. VFPU_Intrinsics-Reference-English .pdf VFPU Intrinsics Reference VFPU_Macro-Overview-English .pdf psp-as VFPU Assembler Overview VFPU_Macro-Reference-English .pdf psp-as VFPU Macro Reference libvfpu-Overview-English .pdf VFPU Operation Library (libvfpu) is a library that performs vector and matrix operations using VFPU instructions. It also provides the ability to copy memory using vfpu vector load and store instructions. libfpu-Reference-English .pdf libfpu Reference for functions like sceFpuFloor libvfpu-Reference-English .pdf libvfpu Reference for functions like sceVfpuScalarAbs Graphics (/document/pdf/graphics) /graphics This folder contains documentation related to 3D gaphics such as the GMO 3d Model API and how the Graphics engine works. The Graphics Engine manager (geman) is a service for controlling the Graphics Engine, which is the drawing engine of the PSPTM.geman provides functions for managing display lists (sequences of commands that are transferred to the Graphics Engine) as a queue. By using geman, an application can create and transfer display lists without being concerned with when drawing actually ends. The files in this folder are described in the table below: File Name Extension Description GE-Overview-English .pdf 21 page Graphics Engine Manager (geman) Overview GE-Reference-English .pdf Graphics Engine Manager (geman) Reference for functions such as sceGeListEnQueue Graphics-Overview-English .pdf High level overview of the Graphics Processing Flow libgim_Picture-Overview-English .pdf libgim_picture is a library for handling 2D graphics data that are to be used as textures. It provides functions for parsing 2D graphics data files into picture structures having image and palette subblocks, functions for animating picture structures, and functions for setting textures in conjunction with libgu by creating display lists based on picture structures. libgim_Picture-Reference-English .pdf libgim_picture Reference libgiq_Picture-Overview-English .pdf libgiq_picture is a lightweight version of libgim_picture. It provides an almost identical API as libgim_picture but can display GIM files with less CPU load. libgiq_Picture-Reference-English .pdf libgiq_picture Reference libgmo_Model-Overview-English .pdf libgmo is a library for handling 3D model data. It provides functions for parsing 3D model data files into model structures having bone, part, and material subblocks, functions for animating model structures, and functions for creating display lists based on model structures in conjunction with libgu. libgmo_Model-Reference-English .pdf libgmo_model Reference libgmq_Model-Overview-English .pdf libgmq_model is a lightweight version of libgmo_model. It provides an almost identical API as libgmo_model but can display GMO files with less CPU load. libgmq_Model-Reference-English .pdf libgmq_model Reference libgso_Scene-Overview-English .pdf libgso is a library which handles 3D scene data. libgso provides structure definitions and macro definitions for the 3D scene format. Using these, information on lights, cameras, etc. declared in the 3D scene format can be obtained. libgso_Scene-Reference-English .pdf libgso_scene Reference libgu-Overview-English .pdf libgu is a basic library that uses the Graphics Engine to draw graphics. It is primarily used to create display lists (sequences of drawing parameters and drawing commands) that are used by the Graphics Engine to perform the actual drawing. The library also provides functions for starting, interrupting, and synchronizing drawing operations. libgu-Reference-English .pdf libgu Reference libgum-Overview-English .pdf libgum is a library for supporting 3D operations. It has functions for performing matrix calculations such as rotation, scaling, and perspective projection as well as functions for reflecting the calculation result matrix in a display list that was created using libgu. libgum-Reference-English .pdf libgum Reference libgup-Reference-English .pdf libgup Reference libgxp_Packet-Reference-English .pdf libgxp_packet Reference Guideline (/document/pdf/guideline) /guideline This folder contains documents on misc topics such as creating custom system themes or creating content for the internet browser, including the PSP Flash player plugin. The files in this folder are described in the table below: File Name Extension Description CustomTheme-Packaging-English .pdf Custom Theme Package Creation Guide Custom_Theme-English .pdf Custom Theme Creation Guidelines InternetBrowser_ContentGuideline_Dev-English .pdf 53 page Guidelines for Creating Content for the PSP Internet Browser NP_Dev-Users_Guide_e .pdf 21 page Network Platform for Development User’s Guide PSN_Avatar-Guidelines_e .pdf PlayStation®Network Avatar Guidelines, including premium paid for avatars (also mentions vita and PS3) PSP_PlayStation_Store_Content-Guidelines-English .pdf 25 page document explains how to create system files, gives precautions when creating content information, and provides notes that should be followed when creating user programs and data. Readme-CustomTheme-Packaging-English .txt Changelog for the Custom_Theme-English document Readme-CustomTheme_CreationGuideline-English .txt Changelog for the CustomTheme-Packaging-English.pdf Readme-InternetBrowser_ContentGuideline_Dev-English .txt Changelog for the InternetBrowser_ContentGuideline_Dev-English.pdf Readme-PlayStation_Store_ContentGuideline-English .txt Changelog for the PSP_PlayStation_Store_Content-Guideline-English.pdf Image Recognition (/document/pdf/image_recognition) /image_recognition This folder contains documentation on the Face recognition API provided by the PSP SDK. The files in this folder are described in the table below: File Name Extension Description libface-Overview-English .pdf libface is a library for analyzing grayscale images and recognizing the faces of people whose pictures appear in those images libface-Reference-English .pdf libface reference api with functions such as sceFaceDetection Kernel (/document/pdf/kernel) /kernel This folder contains low level documentation on how the PSP Kernel works for example details of the cache inside the . The files in this folder are described in the table below: File Name Extension Description Cache-Overview-English .pdf 14 page ALLEGREX CPU Cache Overview Cache-Reference-English .pdf Cache Manipulation Utilities Reference IO_File_Manager-Reference-English .pdf Reference for IO file functions such as SceIoStat Interrupt_Manager-Reference-English .pdf intrman (PSP Interrupt Manager) Reference Kernel-Overview-English .pdf 24 page PSP Kernel Overview Loadexec-Reference-English .pdf Restarting the PSP and Starting Applications (loadexec) Reference Module_Manager-Reference-English .pdf PSP Module Manager Reference Stdio-Reference-English .pdf Reference for functions such as sceKernelRegisterStdoutPipe System_Memory_Manager-Reference-English .pdf PSP System Memory Manager Reference Thread_Manager-Reference-English .pdf PSP Thread Manager Specifications Reference Types-Reference-English .pdf Common Type Definitions Reference libheap-Overview-English .pdf libheap is a library for managing in smaller chunks, memory that is first allocated using the fixed-length memory pool (FPL) of the thread manager. libheap is useful when you want to perform malloc()/free()-like memory management without depending on libc. It can also be used when you want to allocate multiple independent heaps. libheap-Reference-English .pdf libheap Reference for functions such as sceHeapAllocHeapMemory Movie (/document/pdf/movie) /movie This folder contains… The files in this folder are described in the table below: File Name Extension Description AVIenc-Overview-English .pdf   AVIenc-Reference-English .pdf   Movie-Overview-English .pdf   libmp4-Overview-English .pdf   libmp4-Reference-English .pdf   libmpeg-Overview-English .pdf   libmpeg-Reference-English .pdf   libpsmf-Overview-English .pdf   libpsmf-Reference-English .pdf   libpsmfplayer-Overview-English .pdf   libpsmfplayer-Reference-English .pdf   Network (/document/pdf/network) /network This folder contains… The files in this folder are described in the table below: File Name Extension Description Game_Sharing-Authoring-English .pdf   Game_Sharing-Overview-English .pdf   HTTPS-Overview-English .pdf   HTTPS-Reference-English .pdf   Ifhandle-Overview-English .pdf   Ifhandle-Reference-English .pdf   NP-Overview-English .pdf   NP-Reference-English .pdf   NPDRM-Overview-English .pdf   NPDRM-Reference-English .pdf   NP_Account-Overview-English .pdf   NP_Auth-Reference-English .pdf   NP_Commerce-Overview-English .pdf   NP_Commerce_Programming_Guide-English .pdf   NP_Common-Reference-English .pdf   NP_Communication-Overview-English .pdf   NP_In_Game_Commerce2-Overview-English .pdf   NP_In_Game_Commerce2-Reference-English .pdf   NP_Lookup-Overview-English .pdf   NP_Lookup-Reference-English .pdf   NP_Matching2-Overview-English .pdf   NP_Matching2-Reference-English .pdf   NP_Matching2_System-Overview-English .pdf   NP_Roster-Reference-English .pdf   NP_Service-Reference-English .pdf   Network-Overview-English .pdf   Network_Infrastructure_Mode-Overview-English .pdf   PSPNET-Overview-English .pdf   PSPNET_Adhoc-Reference-English .pdf   PSPNET_Adhoc_Discover-Overview-English .pdf   PSPNET_Adhoc_Discover-Reference-English .pdf   PSPNET_Adhoc_Matching-Overview-English .pdf   PSPNET_Adhoc_Matching-Reference-English .pdf   PSPNET_Adhocctl-Reference-English .pdf   PSPNET_Ap_Dialog_Dummy-Reference-English .pdf   PSPNET_Apctl-Reference-English .pdf   PSPNET_Core-Reference-English .pdf   PSPNET_Error-Reference-English .pdf   PSPNET_Inet-Reference-English .pdf   PSPNET_Resolver-Overview-English .pdf   PSPNET_Resolver-Reference-English .pdf   PSP_Boot_Binary-Overview-English .pdf   Wlan-Overview-English .pdf   Wlan-Reference-English .pdf   libbase16-Overview-English .pdf   libbase16-Reference-English .pdf   libbase32-Overview-English .pdf   libbase32-Reference-English .pdf   libbase64-Overview-English .pdf   libbase64-Reference-English .pdf   libgameupdate-Overview-English .pdf   libgameupdate-Reference-English .pdf   libhttp-Overview-English .pdf   libhttp-Reference-English .pdf   libparse_HTTP-Overview-English .pdf   libparse_HTTP-Reference-English .pdf   libparse_URI-Overview-English .pdf   libparse_URI-Reference-English .pdf   libqpcode-Overview-English .pdf   libqpcode-Reference-English .pdf   libssl-Overview-English .pdf   libssl-Reference-English .pdf   Others (/document/pdf/others) /others This folder contains… The files in this folder are described in the table below: File Name Extension Description GameData-Authoring-English .pdf   GameData-Reference-English .pdf   OpenPSID-Overview-English .pdf   OpenPSID-Reference-English .pdf   libadler-Overview-English .pdf   libadler-Reference-English .pdf   libccc-Reference-English .pdf   libdeflt-Overview-English .pdf   libdeflt-Reference-English .pdf   libfont-Overview-English .pdf   libfont-Reference-English .pdf   libmd5-Overview-English .pdf   libmd5-Reference-English .pdf   libmt19937-Overview-English .pdf   libmt19937-Reference-English .pdf   libpuny-Overview-English .pdf   libpuny-Reference-English .pdf   libsfmt11213-Overview-English .pdf   libsfmt11213-Reference-English .pdf   libsfmt1279-Overview-English .pdf   libsfmt1279-Reference-English .pdf   libsfmt132049-Overview-English .pdf   libsfmt132049-Reference-English .pdf   libsfmt19937-Overview-English .pdf   libsfmt19937-Reference-English .pdf   libsfmt216091-Overview-English .pdf   libsfmt216091-Reference-English .pdf   libsfmt2281-Overview-English .pdf   libsfmt2281-Reference-English .pdf   libsfmt4253-Overview-English .pdf   libsfmt4253-Reference-English .pdf   libsfmt44497-Overview-English .pdf   libsfmt44497-Reference-English .pdf   libsfmt607-Overview-English .pdf   libsfmt607-Reference-English .pdf   libsfmt86243-Overview-English .pdf   libsfmt86243-Reference-English .pdf   libsha0-Overview-English .pdf   libsha0-Reference-English .pdf   libsha1-Overview-English .pdf   libsha1-Reference-English .pdf   libsha224-Overview-English .pdf   libsha224-Reference-English .pdf   libsha256-Overview-English .pdf   libsha256-Reference-English .pdf   libsha384-Overview-English .pdf   libsha384-Reference-English .pdf   libsha512-Overview-English .pdf   libsha512-Reference-English .pdf   Peripheral (/document/pdf/peripheral) /peripheral This folder contains… The files in this folder are described in the table below: File Name Extension Description BatteryIcon-Overview-English .pdf   Controller-Overview-English .pdf   Controller-Reference-English .pdf   DMAC-Overview-English .pdf   DMAC-Reference-English .pdf   Display-Overview-English .pdf   Display-Reference-English .pdf   FATMS-Overview-English .pdf   FATMS-Reference-English .pdf   HeadphoneRemote-Overview-English .pdf   HeadphoneRemote-Reference-English .pdf   ISO9660-Reference-English .pdf   Impose-Reference-English .pdf   Power-Overview-English .pdf   Power-Reference-English .pdf   RTC-Overview-English .pdf   RTC-Reference-English .pdf   UMD-Overview-English .pdf   UMD-Reference-English .pdf   UMD_Block-Reference-English .pdf   UMD_Cache-Overview-English .pdf   USB_Camera-Overview-English .pdf   USB_Camera-Reference-English .pdf   USB_Driver-Overview-English .pdf   USB_Driver-Reference-English .pdf   USB_Gps-Overview-English .pdf   USB_Gps-Reference-English .pdf   USB_Mic-Overview-English .pdf   USB_Mic-Reference-English .pdf   USB_PSPComm-Overview-English .pdf   USB_PSPComm-Reference-English .pdf   fmacvideo-Overview-English .pdf   fmacvideo-Reference-English .pdf   Sound (/document/pdf/sound) /sound This folder contains… The files in this folder are described in the table below: File Name Extension Description AudioInput-Overview-English .pdf   AudioInput-Reference-English .pdf   AudioRouting-Reference-English .pdf   PHD_PBD_Format-English .pdf   Sas-Overview-English .pdf   SimpleAudio-Overview-English .pdf   SimpleAudio-Reference-English .pdf   Sound-Overview-English .pdf   VAG_Format-English .pdf   Vaudio-Overview-English .pdf   Vaudio-Reference-English .pdf   libaac-Overview-English .pdf   libaac-Reference-English .pdf   libatrac3plus-Overview-English .pdf   libatrac3plus-Reference-English .pdf   libg729-Overview-English .pdf   libg729-Reference-English .pdf   libmp3-Overview-English .pdf   libmp3-Reference-English .pdf   libp3da-Overview-English .pdf   libp3da-Reference-English .pdf   libsas-Overview-English .pdf   libsas-Reference-English .pdf   libsndp-Overview-English .pdf   libsndp-Reference-English .pdf   libulaw-Overview-English .pdf   libulaw-Reference-English .pdf   libwave-Overview-English .pdf   libwave-Reference-English .pdf   Still (/document/pdf/still) /still This folder contains… The files in this folder are described in the table below: File Name Extension Description JPEGDEC-Overview-English .pdf   JPEGDEC-Reference-English .pdf   SCEJPEGENC-Overview-English .pdf   SCEJPEGENC-Reference-English .pdf   scepng-Overview-English .pdf   scepng-Reference-English .pdf   Tool (/document/pdf/tool) /tool This folder contains… The files in this folder are described in the table below: File Name Extension Description PSMF_Composer-Tool-English .pdf   PSMF_Encoder-Tool-English .pdf   PSPhtool_Updater-English .pdf   Readme-Stream_Composer_Doc-English .txt   Stream_Composer-Tool-English .pdf   Utility (/document/pdf/utility) /utility This folder contains… The files in this folder are described in the table below: File Name Extension Description Utility-Overview-English .pdf   Utility-Reference-English .pdf   Utility_Gamedata_Install-Overview-English .pdf   Utility_Gamedata_Install-Reference-English .pdf   Utility_InternetBrowser-Overview-English .pdf   Utility_InternetBrowser-Reference-English .pdf   Utility_RssChannelSubscriber-Overview-English .pdf   Utility_RssReader-Overview-English .pdf   Utility_RssReader-Reference-English .pdf   Utility_Savedata-Overview-English .pdf   Utility_Savedata-Reference-English .pdf   Utility_Savedata-Reference-Member-English .pdf   Format (/document/format) /format This folder contains… The files in this folder are described in the table below: File Name Extension Description GIM_Format-Overview-English .pdf   GMO_Format-Overview-English .pdf   GMO_Format-Reference-English .pdf   GSO_Format-Overview-English .pdf   GSO_Format-Reference-English .pdf   Hardware_manual (/document/hardware_manual) /hardware_manual This folder contains… This folder also contains the following sub-directories: Graphics_Engine - VFPU - ALLEGREX - The files in this folder are described in the table below: File Name Extension Description Hardware-Restriction-English .pdf   Readme-English .txt   Allegrex Hardware Documentation (/document/hardware_manual/ALLEGREX) /ALLEGREX This folder contains… This folder also contains the following sub-directories: Instruction_list - Just contains one file ALLEGREX_FPU-Instruction_List-English.pdf that… The files in this folder are described in the table below: File Name Extension Description ALLEGREX-Instruction_Manual-English .pdf   ALLEGREX-Users_Manual-English .pdf   FPU-Instruction_Manual-English .pdf   FPU-Users_Manual-English .pdf   Graphics Engine Documentation (/document/hardware_manual/Graphics_Engine) /Graphics_Engine This folder contains… This folder also contains the following sub-directories: Command_list - Japanese and Korean version of Graphics_Engine-Command_List Graphics_Engine-Command_list - Just contains one file Graphics_Engine-Command_List-English.pdf that… The files in this folder are described in the table below: File Name Extension Description Graphics_Engine-Command_Reference_Manual-English .pdf   Graphics_Engine-Users_Manual-English .pdf   VFPU Documentation (/document/hardware_manual/VFPU) /VFPU This folder contains… This folder also contains the following sub-directories: VFPU-Instruction_list - Just contains one file VFPU-Instruction_List-English.pdf that… Instruction_list - Japanese and korean version of Vfpu-instruction_list The files in this folder are described in the table below: File Name Extension Description VFPU-Instruction_Manual-English .pdf   VFPU-Users_Manual-English .pdf   Flash (/flash) /flash This folder contains… This folder also contains the following sub-directories which each just contain a single EBOOT.PBP file : downgrade_DTP_H1500 - update_DTP_H1500 - The files in this folder are described in the table below: File Name Extension Description English-Notes_on_using_the_updater .txt   Japanese-Notes_on_using_the_updater .txt Japanese version of the notes Korean-Notes_on_using_the_updater .txt Korean version of the notes Htool_updater (/htool_updater) /htool_updater This folder contains an update binary and license files for the PSP Hardware Tool Development Kit. This folder also contains the following sub-directories: license - contains a single text file per language (English, Japanese, Korean) for the license file psptool_license_e.txt The files in this folder are described in the table below: File Name Extension Description htool_updater-660-A .bin Firmware update for the PSP Tool Include Headers (/include) /include This folder contains… This folder also contains the following sub-directories: gmq - gso - gxp - libhttp - deci2p - gim - giq - pspnet - gmo - np - utility - The files in this folder are described in the table below: File Name Extension Description allegrex .h Include file for declaring audioerror .h Include file for declaring audioinput .h Include file for declaring audiooutput .h Include file for declaring audiorouting .h Include file for declaring avienc .h Include file for declaring breakcode .h Include file for declaring cpureg .h Include file for declaring crashdump .h Include file for declaring ctrlsvc .h Include file for declaring deci2p .h Include file for declaring devkit_version .h Include file for declaring displaysvc .h Include file for declaring dmacdrv .h Include file for declaring exportcplusplus .h Include file for declaring fatms .h Include file for declaring fmacvideo .h Include file for declaring gecmd .h Include file for declaring geman .h Include file for declaring gevtx .h Include file for declaring gprof .h Include file for declaring hpremotedrv .h Include file for declaring impose .h Include file for declaring intrman .h Include file for declaring iofilemgr .h Include file for declaring iofilemgr_dirent .h Include file for declaring iofilemgr_dnas .h Include file for declaring iofilemgr_dnas_inline .h Include file for declaring iofilemgr_fcntl .h Include file for declaring iofilemgr_stat .h Include file for declaring isofs_ioctl .h Include file for declaring kernel .h Include file for declaring kerneltypes .h Include file for declaring kernelutils .h Include file for declaring kerror .h Include file for declaring libaac .h Include file for declaring libadler .h Include file for declaring libatrac3plus .h Include file for declaring libatrac3plus_aa3 .h Include file for declaring libbase16 .h Include file for declaring libbase32 .h Include file for declaring libbase64 .h Include file for declaring libccc .h Include file for declaring libdeflt .h Include file for declaring libface .h Include file for declaring libfont .h Include file for declaring libfpu .h Include file for declaring libg729 .h Include file for declaring libgameupdate .h Include file for declaring libgu .h Include file for declaring libgum .h Include file for declaring libgup .h Include file for declaring libheap .h Include file for declaring libhttp .h Include file for declaring libhttp_error .h Include file for declaring libhttps .h Include file for declaring libmd5 .h Include file for declaring libmp3 .h Include file for declaring libmp4 .h Include file for declaring libmpeg .h Include file for declaring libmt19937 .h Include file for declaring libp3da .h Include file for declaring libp3da_types .h Include file for declaring libp3da_values .h Include file for declaring libparse_http .h Include file for declaring libparse_uri .h Include file for declaring libpsmf .h Include file for declaring libpsmfplayer .h Include file for declaring libpuny .h Include file for declaring libqpcode .h Include file for declaring libsas .h Include file for declaring libsfmt11213 .h Include file for declaring libsfmt1279 .h Include file for declaring libsfmt132049 .h Include file for declaring libsfmt19937 .h Include file for declaring libsfmt216091 .h Include file for declaring libsfmt2281 .h Include file for declaring libsfmt4253 .h Include file for declaring libsfmt44497 .h Include file for declaring libsfmt607 .h Include file for declaring libsfmt86243 .h Include file for declaring libsha0 .h Include file for declaring libsha1 .h Include file for declaring libsha224 .h Include file for declaring libsha256 .h Include file for declaring libsha384 .h Include file for declaring libsha512 .h Include file for declaring libsndp .h Include file for declaring libssl .h Include file for declaring libvfpu .h Include file for declaring libwave .h Include file for declaring loadexec .h Include file for declaring mediaman .h Include file for declaring moduleexport .h Include file for declaring modulemgr .h Include file for declaring modulemgr_gamesharing .h Include file for declaring mscm_error .h Include file for declaring msstor_error .h Include file for declaring openpsid .h Include file for declaring powersvc .h Include file for declaring profiler .h Include file for declaring pspalias .h Include file for declaring pspconst .h Include file for declaring psperror .h Include file for declaring pspioctl .h Include file for declaring pspkeywords .h Include file for declaring pspnet .h Include file for declaring pspnet_adhoc .h Include file for declaring pspnet_adhoc_discover .h Include file for declaring pspnet_adhoc_matching .h Include file for declaring pspnet_adhocctl .h Include file for declaring pspnet_ap_dialog_dummy .h Include file for declaring pspnet_apctl .h Include file for declaring pspnet_error .h Include file for declaring pspnet_inet .h Include file for declaring pspnet_resolver .h Include file for declaring pspnet_upnp .h Include file for declaring pspstdint .h Include file for declaring psptypes .h Include file for declaring rtcsvc .h Include file for declaring scejpeg .h Include file for declaring scejpegenc .h Include file for declaring scepng .h Include file for declaring sceulaw .h Include file for declaring scratchpad .h Include file for declaring sdphd .h Include file for declaring sysmem .h Include file for declaring thread .h Include file for declaring umddevctl .h Include file for declaring umddisc .h Include file for declaring umderror .h Include file for declaring usb .h Include file for declaring usbacc .h Include file for declaring usbcam .h Include file for declaring usbgps .h Include file for declaring usbmic .h Include file for declaring usbpspcm .h Include file for declaring usbser .h Include file for declaring vaudio .h Include file for declaring wlan .h Include file for declaring Deci2p Headers (/include/deci2p) /deci2p This folder contains… The files in this folder are described in the table below: File Name Extension Description dbgp .h Include file for declaring dcmp .h Include file for declaring deci2p .h Include file for declaring drfp .h Include file for declaring loadp .h Include file for declaring netmp .h Include file for declaring ttyp .h Include file for declaring GIM Image Format Headers (/include/gim) /gim This folder contains… The files in this folder are described in the table below: File Name Extension Description gim_format .h Include file for declaring gim_metrics .h Include file for declaring gim_picture .h Include file for declaring gim_protected .h Include file for declaring Giq Headers (/include/giq) /giq This folder contains… The files in this folder are described in the table below: File Name Extension Description giq_format .h Include file for declaring giq_picture .h Include file for declaring giq_protected .h Include file for declaring Gmo Headers (/include/gmo) /gmo This folder contains… The files in this folder are described in the table below: File Name Extension Description gmo_format .h Include file for declaring gmo_metrics .h Include file for declaring gmo_model .h Include file for declaring gmo_protected .h Include file for declaring Gmq Headers (/include/gmq) /gmq This folder contains… The files in this folder are described in the table below: File Name Extension Description gmq_format .h Include file for declaring gmq_model .h Include file for declaring gmq_protected .h Include file for declaring Gso headers (/include/gso) /gso This folder contains… The files in this folder are described in the table below: File Name Extension Description gso_format .h Include file for declaring gso_scene .h Include file for declaring Gxp headers (/include/gxp) /gxp This folder contains… The files in this folder are described in the table below: File Name Extension Description gxp_format .h Include file for declaring gxp_packet .h Include file for declaring Lib Http headers (/include/libhttp) /libhttp This folder contains… The files in this folder are described in the table below: File Name Extension Description http_methods .h Include file for declaring http_status_code .h Include file for declaring schemes .h Include file for declaring Np Headers (/include/np) /np This folder contains… The files in this folder are described in the table below: File Name Extension Description np .h Include file for declaring np_auth .h Include file for declaring np_commerce2 .h Include file for declaring np_common .h Include file for declaring np_drm .h Include file for declaring np_drm_inline .h Include file for declaring np_error .h Include file for declaring np_lookup .h Include file for declaring np_matching2 .h Include file for declaring np_roster .h Include file for declaring np_service .h Include file for declaring PSP Net inet headers (/include/pspnet/netinet) /netinet This folder contains… The files in this folder are described in the table below: File Name Extension Description in .h Include file for declaring ip_var .h Include file for declaring tcp .h Include file for declaring tcp_fsm .h Include file for declaring tcp_var .h Include file for declaring udp_var .h Include file for declaring PSP Net System Headers (/include/pspnet/sys) /sys This folder contains… The files in this folder are described in the table below: File Name Extension Description poll .h Include file for declaring select .h Include file for declaring socket .h Include file for declaring time .h Include file for declaring uio .h Include file for declaring Utility Headers (/include/utility) /utility This folder contains… The files in this folder are described in the table below: File Name Extension Description utility_auto_connect .h Include file for declaring utility_common .h Include file for declaring utility_gamedata_install .h Include file for declaring utility_gamesharing .h Include file for declaring utility_htmlviewer .h Include file for declaring utility_module .h Include file for declaring utility_msgdialog .h Include file for declaring utility_netconf .h Include file for declaring utility_netparam .h Include file for declaring utility_np_signin .h Include file for declaring utility_osk .h Include file for declaring utility_ps3scan .h Include file for declaring utility_psn .h Include file for declaring utility_rss_reader .h Include file for declaring utility_rss_subscriber .h Include file for declaring utility_savedata .h Include file for declaring utility_screenshot .h Include file for declaring utility_store_checkout .h Include file for declaring utility_sysparam .h Include file for declaring Static Libraries (/lib) /lib This folder contains… This folder also contains the following sub-directories: ldscripts - The files in this folder are described in the table below:</div> </section> File Name Extension Description audio_stub_02 .a Static Library archive of audiorouting_stub .a Static Library archive of crt0_elf .o   crt0_prx .o   crt0_prxlibc .o   ctrl_stub .a Static Library archive of deci2p_user_stub .a Static Library archive of display_stub .a Static Library archive of dmac_stub .a Static Library archive of exportgcc_eh .o   exportlibc .o   exportlibm .o   g729_stub .a Static Library archive of g729_stub_weak .a Static Library archive of ge_user_stub .a Static Library archive of hpremote_stub .a Static Library archive of ifhandle_stub .a Static Library archive of ifhandle_stub_weak .a Static Library archive of impose_stub .a Static Library archive of kernel_bridge .o   libaac_stub .a Static Library archive of libaac_stub_weak .a Static Library archive of libadler .a Static Library archive of libadler_stub .a Static Library archive of libadler_stub_weak .a Static Library archive of libatrac3plus_stub .a Static Library archive of libatrac3plus_stub_weak .a Static Library archive of libavienc .a Static Library archive of libbase16 .a Static Library archive of libbase16_stub .a Static Library archive of libbase16_stub_weak .a Static Library archive of libbase32 .a Static Library archive of libbase32_stub .a Static Library archive of libbase32_stub_weak .a Static Library archive of libbase64 .a Static Library archive of libbase64_stub .a Static Library archive of libbase64_stub_weak .a Static Library archive of libc_stub .a Static Library archive of libc_stub_weak .a Static Library archive of libccc .a Static Library archive of libccc_stub .a Static Library archive of libccc_stub_weak .a Static Library archive of libdeflt .a Static Library archive of libdeflt_small .a Static Library archive of libdeflt_stub .a Static Library archive of libdeflt_stub_weak .a Static Library archive of libface_stub .a Static Library archive of libface_stub_weak .a Static Library archive of libfmacvideo .a Static Library archive of libfont_stub .a Static Library archive of libfont_stub_weak .a Static Library archive of libfpu .a Static Library archive of libfpu_stub .a Static Library archive of libfpu_stub_weak .a Static Library archive of libgameupdate_stub .a Static Library archive of libgameupdate_stub_weak .a Static Library archive of libgcc_eh_stub .a Static Library archive of libgcc_eh_stub_weak .a Static Library archive of libgcovio .a Static Library archive of libgim_picture .a Static Library archive of libgiq_picture .a Static Library archive of libgmo_model .a Static Library archive of libgmo_model_vfpu .a Static Library archive of libgmq_model .a Static Library archive of libgprof .a Static Library archive of libgso_scene .a Static Library archive of libgu .a Static Library archive of libgu_debug .a Static Library archive of libgum .a Static Library archive of libgum_vfpu .a Static Library archive of libgxp_packet .a Static Library archive of libheap .a Static Library archive of libheap_stub .a Static Library archive of libheap_stub_weak .a Static Library archive of libhttp_stub .a Static Library archive of libhttp_stub_weak .a Static Library archive of libkernel .a Static Library archive of libm_stub .a Static Library archive of libm_stub_weak .a Static Library archive of libmd5 .a Static Library archive of libmd5_stub .a Static Library archive of libmd5_stub_weak .a Static Library archive of libmp3_stub .a Static Library archive of libmp3_stub_weak .a Static Library archive of libmp4_stub .a Static Library archive of libmp4_stub_weak .a Static Library archive of libmt19937 .a Static Library archive of libmt19937_stub .a Static Library archive of libmt19937_stub_weak .a Static Library archive of libp3da .a Static Library archive of libp3da_weak .a Static Library archive of libparse_http_stub .a Static Library archive of libparse_http_stub_weak .a Static Library archive of libparse_uri_stub .a Static Library archive of libparse_uri_stub_weak .a Static Library archive of libpsmfplayer .a Static Library archive of libpsmfplayer_stub .a Static Library archive of libpsmfplayer_stub_weak .a Static Library archive of libpuny .a Static Library archive of libpuny_stub .a Static Library archive of libpuny_stub_weak .a Static Library archive of libqpcode .a Static Library archive of libqpcode_stub .a Static Library archive of libqpcode_stub_weak .a Static Library archive of libsas .a Static Library archive of libsas_weak .a Static Library archive of libscejpegenc .a Static Library archive of libscejpegenc_vfpu .a Static Library archive of libscepng .a Static Library archive of libsceulaw .a Static Library archive of libsfmt11213 .a Static Library archive of libsfmt11213_stub .a Static Library archive of libsfmt11213_stub_weak .a Static Library archive of libsfmt1279 .a Static Library archive of libsfmt1279_stub .a Static Library archive of libsfmt1279_stub_weak .a Static Library archive of libsfmt132049 .a Static Library archive of libsfmt132049_stub .a Static Library archive of libsfmt132049_stub_weak .a Static Library archive of libsfmt19937 .a Static Library archive of libsfmt19937_stub .a Static Library archive of libsfmt19937_stub_weak .a Static Library archive of libsfmt216091 .a Static Library archive of libsfmt216091_stub .a Static Library archive of libsfmt216091_stub_weak .a Static Library archive of libsfmt2281 .a Static Library archive of libsfmt2281_stub .a Static Library archive of libsfmt2281_stub_weak .a Static Library archive of libsfmt4253 .a Static Library archive of libsfmt4253_stub .a Static Library archive of libsfmt4253_stub_weak .a Static Library archive of libsfmt44497 .a Static Library archive of libsfmt44497_stub .a Static Library archive of libsfmt44497_stub_weak .a Static Library archive of libsfmt607 .a Static Library archive of libsfmt607_stub .a Static Library archive of libsfmt607_stub_weak .a Static Library archive of libsfmt86243 .a Static Library archive of libsfmt86243_stub .a Static Library archive of libsfmt86243_stub_weak .a Static Library archive of libsha0 .a Static Library archive of libsha0_stub .a Static Library archive of libsha0_stub_weak .a Static Library archive of libsha1 .a Static Library archive of libsha1_stub .a Static Library archive of libsha1_stub_weak .a Static Library archive of libsha224 .a Static Library archive of libsha224_stub .a Static Library archive of libsha224_stub_weak .a Static Library archive of libsha256 .a Static Library archive of libsha256_stub .a Static Library archive of libsha256_stub_weak .a Static Library archive of libsha384 .a Static Library archive of libsha384_stub .a Static Library archive of libsha384_stub_weak .a Static Library archive of libsha512 .a Static Library archive of libsha512_stub .a Static Library archive of libsha512_stub_weak .a Static Library archive of libsndp .a Static Library archive of libssl_stub .a Static Library archive of libssl_stub_weak .a Static Library archive of libvfpu .a Static Library archive of libwave .a Static Library archive of mediaman_stub .a Static Library archive of modulemgr_user_stub_03 .a Static Library archive of mpeg_stub .a Static Library archive of mpeg_stub_weak .a Static Library archive of np_auth_stub .a Static Library archive of np_auth_stub_weak .a Static Library archive of np_commerce2_stub .a Static Library archive of np_commerce2_stub_weak .a Static Library archive of np_matching2_stub .a Static Library archive of np_matching2_stub_weak .a Static Library archive of np_service_stub .a Static Library archive of np_service_stub_weak .a Static Library archive of np_stub .a Static Library archive of np_stub_weak .a Static Library archive of npdrm_stub .a Static Library archive of npdrm_stub_weak .a Static Library archive of openpsid_stub .a Static Library archive of power_stub .a Static Library archive of psmf_stub .a Static Library archive of psmf_stub_weak .a Static Library archive of pspnet_adhoc_discover_stub .a Static Library archive of pspnet_adhoc_discover_stub_weak .a Static Library archive of pspnet_adhoc_matching_stub .a Static Library archive of pspnet_adhoc_matching_stub_weak .a Static Library archive of pspnet_adhoc_stub .a Static Library archive of pspnet_adhoc_stub_weak .a Static Library archive of pspnet_adhocctl_stub .a Static Library archive of pspnet_adhocctl_stub_weak .a Static Library archive of pspnet_ap_dialog_dummy_stub .a Static Library archive of pspnet_ap_dialog_dummy_stub_weak .a Static Library archive of pspnet_apctl_stub .a Static Library archive of pspnet_apctl_stub_weak .a Static Library archive of pspnet_inet_stub .a Static Library archive of pspnet_inet_stub_weak .a Static Library archive of pspnet_resolver_stub .a Static Library archive of pspnet_resolver_stub_weak .a Static Library archive of pspnet_stub .a Static Library archive of pspnet_stub_weak .a Static Library archive of pspnet_upnp_stub .a Static Library archive of pspnet_upnp_stub_weak .a Static Library archive of pspspecs_1 N/A   pspspecs_2 N/A   rtc_stub .a Static Library archive of scejpeg_stub .a Static Library archive of scejpeg_stub_weak .a Static Library archive of usb_stub .a Static Library archive of usbacc_stub .a Static Library archive of usbacc_stub_weak .a Static Library archive of usbcam_stub .a Static Library archive of usbcam_stub_weak .a Static Library archive of usbgps_stub .a Static Library archive of usbgps_stub_weak .a Static Library archive of usbmic_stub .a Static Library archive of usbmic_stub_weak .a Static Library archive of usbser_stub .a Static Library archive of utility_stub .a Static Library archive of vaudio_stub .a Static Library archive of vaudio_stub_weak .a Static Library archive of wlan_stub .a Static Library archive of Linker (ld) Scripts (/lib/ldscripts) /ldscripts This folder contains… The files in this folder are described in the table below: File Name Extension Description elf32elmip .x, .xbn, .xc, .xn   prx .xr   Samples (/sample) /sample This folder contains… This folder also contains the following sub-directories: net - mpeg - avi - fileio - face - hash - deflt - module - fmac - ccc - png - guideline - usb - profiling - tips - np - kernelutils - font - rand - jpeg - graphics - sound - dvdumd - tool - player - utility - The files in this folder are described in the table below:</div> </section> File Name Extension Description Makefile N/A Used to build the source code in the folder (run make) PSP Samples .sln   ", "excerpt": "Introduction What versions of the SDK have been leaked? Version 1.5.0 (psp_full_sdk_JSR) from 2005 Version 6.6.0 (psp_sdk_660) from 2011 This page will document the latest release version 6.6.0 as it is the most complete. The 1.5.0 JSR version only contains the files that get installed to C:\\usr\\local\\psp\\devkit on windows. Wheras...", "tags": ["psp","sdk"], "image": "/public/generated/placeholders/pspsdk.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "PSP Saints Row Undercover Officially Released Prototype", "url": "/psp-saints-row-undercover", "content": "Saints Row UndercoverAlso known as Saint Row - The Fall earlier in development, this is one of the rare few prototype games released by the developers themselves, in this case Savage games and Volition, they are a rare example of developers that truly cares about the community and game preservation 1.The story behind the release is very interesting and can be read in full over at Unseen64 (https://www.unseen64.net/2016/01/25/saints-row-undercover-fall-psp-cancelled/) including a link to download the playable prototype, design doc and prototype. In short this release is mainly thanks to Josh Stinson who found the game in a random cupboard around the office and managed to convince his bosses with support from Alexander Mejia and Mike Watson to allow releasing information about this game 1.The ISO ImageThe PSP devkit supports 2 different methods of reading discs, one from the UMD drive and the other from a built in DVD drive. The build found by Violition was burned to a DVD-R and will only play on a Official PSP dev kit until it was ripped into .ISO format which can be run by both emulators and modded PSP consoles.How to play the ISOInterestingly there is a few modifications you need to make in order to run the ISO on a psp. MrMario has created a video covering how to do this 2:EBOOT.BINThe EBOOT.BIN file in the iso is completely blank, although it says it is 6mb it is actually just 6mb of 0 bytes. This is why tutorials tell you to replace the EBOOT.BIN with the BOOT.BIN. This is common for prototypes as the EBOOT.BIN is only really needed when encrypting for the final release to retail PSP units.References Saints Row: Undercover [PSP - Cancelled] - Unseen64 ↩ ↩2 (116) How to Play Saints Row: Undercover on PSP! - Unreleased Saints Row Game Patched - YouTube ↩ ", "excerpt": "Saints Row Undercover Also known as Saint Row - The Fall earlier in development, this is one of the rare few prototype games released by the developers themselves, in this case Savage games and Volition, they are a rare example of developers that truly cares about the community and game...", "tags": ["psp","games"], "image": "https://img.youtube.com/vi/-8O2cLAiWIE/maxresdefault.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Playstation Portable Games with Debug Symbols", "url": "/psp-debug-symbols", "content": "The Sony Playstation portable used encrypted executables known as EBOOT.BIN, these are basically just an encrypted ELF file and it is possible to decrypt them with the correct tools. Some games also ship with unencrypted executables in BOOT.BINFinding Debug symbols in retail PSP games is very rare as one of the test cases in the Sony TRC (Technical Requirements Checklist) makes sure that all games that get published do not contain debug symbols: It is forbidden to include the following types of files in the master in any form, even in archive format: Data and files used only for development and debugging purposes such as program source files, executable files with symbols, map files, and driver modules used in title development Data and files designed only for use on other platforms such as Windows wallpaper and screensavers Types of PSP Symbol filesSYM Symbol Files.SYM Files are generated by the SN Systems ProDG SDK for PSP for use in debugging, they contain all the symbols (function names etc) and can also contain other chunks such as source filenames and line numbers.MAP Symbol FilesSimilar to .sym files but are created by the linker to document where each function is located in the final linked executable.BOOT.BINs with Debug Symbols Adventure Player (Japan) (v1.05) Armored Core - Formula Front (Korea) (v1.02) Astonishia Story (Korea) (v1.02) Big Bang Bang (Japan) (Sample) (2003-09-22) Demo Disc for PSP Vol. 1 (Japan) (Demo) Glorace - Phantastic Carnival (Korea) (v1.02) Jan Sangoku Musou (Japan) (v1.02) Puzzle Bobble Pocket (Japan) (v1.01) Rengoku - The Tower of Purgatory (Japan) (v1.01) Space Invaders - Galaxy Beat (Japan) (v1.02) Yu-Gi-Oh! Duel Monsters GX - Tag Force (Japan) (En,Ja,Fr,De,Es,It) (v1.02)ViciousEngineMany games using the ViciousEngine actually came with both the .sym and .map files compressed inside the DATA.PAK file.ViciousEngine was one of the few game engines recommended officially by Sony, and in fact they offered a discount for the engine if it was used to create a PSP Mini [^1].You can extract the .sym and .map file by opening the PSP_GAME/USRDIR/DATA.PAK withThe DATA.PAK file normally contains some files with a name that is a variation of Game-dvd.map and Game-dvd.sym.ViciousEngine Games with Debug Symbols Alien Syndrome (USA) (PSN) Ben 10 - Alien Force (USA) (En,Fr,De,Es,It) (PSP) (PSN) Cart Kings (EUR) Days of Thunder (USA) (minis) (PSN) (/PSP_GAME/USRDIR/DATA.PAK) Desi Adda - Games of India (Europe) (PSN) Despicable Me (EUR) DON 2 The Game (EUR) PlayEnglish - Capitulos Extra (Spain) (PSN) PlayEnglish - Desvela el Misterio (Spain) (PSN) PlayEnglish - Manual y Consejos (Spain) (PSN) Pro Bull Riders - Out of the Chute (USA) (PSN) Top Gun (USA) (minis) (PSN) (Data.pak) (ViciousEngine)Games with PRX symbolsSome games implement some major parts of the game logic in prx files rather than in the EBOOT executables. The PRX format contains lots of debug information as its a dynamic library which requires the symbols to be exported (the same as a windows dll). Flowars (KOR) /PSP_GAME/USRDIR/umodule/flowars.prx SSX On Tour (KOR) (PRX files with lots of debug symbols) SOCOM US Navy Seals Portable (JPN) (/PSP_GAME/USRDIR/TACTICS.PRX)Other Retail Games with Debug SymbolsOutside of games that use the Vicious Engine it is very rare to find games that bundled with their debug symbols, but there are a few games: Need for Speed - ProStreet (Europe) (PSP) (PSN) (big files) Chandragupta Warrior Prince (EUR) - mentions of C-like exports (infernal engine)Games with Lua ScriptingWhile not quite debug symbols, these games contain unencrypted Lua scripts that can be modified Pirates of the Caribbean - Dead Man’s Chest (Europe) (PSN)Games with Squirrel ScriptingSquirrel - The Programming Language The Mystery TeamGames with Makefiles Circles, Circles, Circles (Europe) (minis) (PSN) D-Cube Planet (Europe) (minis) (PSN) Deflector (Europe) (minis) (PSN) Route 66 (Europe) (minis) (PSN)Other developer content Death Jr II Root Of Evil (USA) has a bash script (/PSP_GAME/USRDIR/STREAMS/IGOR.SH) the bash script mentions SN Systems the company that created the ProDG SDK Ghostbusters The Video Game (EUR) Contains c-like extern statements Armored Core Formula Front Extreme Battle (EUR) BOOT.BIN contains lots of mentions of debug symbols but not complete Dantes Inferno (USA) What looks like unit test content? Hellboy_The_Science_of_Evil (USA) Interesting BOOT.BIN Marvel_Nemesis_Rise_Of_The_Imperfects_USA_PSP-ARTiSAN Interesting BOOT.BIN Medal.of.Honor.Heroes.EUR.GERMAN.PSP-SUSHi EAGL debug symbols Megpoid_The_Muic_Sharp_JPN_PSP-Caravan Interesting stuff in DATA.zip, scripting? NASCAR_07_EUR_PSP-BAHAMUT Contains .o object files and EAGL PixelJunk_Monsters_UMD_Limited_Edition_ASiA_PSP-PLAYASiA GM script files The_Sims_2_USA_PSP-ARTiSAN Scripting stuff Need_For_Speed_Most_Wanted_USA_PSP-ARTiSAN contains debug object files Prototype Games - debug symbolsSurprisingly the currently released prototypes have very little debug symbol information in themPrototype games with potential debug symbols Melodie_(Sep_2,_2005_prototype) (looks like symbols in: /USER_L0.IMG)Prototype Games without Debug symbolsThese games have been checked and unfortunately do not contain any symbols: Castlevania The Dracula X Chronicles (Jan 30, 2007) Championship Manager 2010 (Prototype) Chili Con Carnage (Sep 23, 2006 prototype) Crazy Taxi - Fare Wars (Jun 28, 2007 prototype) Daxter (Feb 10, 2006 prototype) Death Jr (Jul 22, 2005 prototype) Fight Night Round 3 (Dec 21, 2005 prototype - Debug) Gangs of London (Jun 5, 2006 prototype) Ghost Rider (Jan 18, 2007 prototype) Isle of Minno (May 12, 2006 prototype) Jeanne d’Arc (Aug 17, 2006 prototype) Killzone Liberation (Jul 19, 2006 prototype) Lemmings (Sep 30, 2005 prototype) LocoRoco (Apr 20, 2006 prototype) LocoRoco 2 (Sep 5, 2008 prototype) MediEvil - Resurrection (Feb 15, 2005 prototype) Metal Gear Solid - Portable Ops (Feb 6, 2007 prototype) Ratchet & Clank - Size Matters (Dec 20, 2006 prototype) Ratchet and Clank - Size Matters (Oct 11, 2006 Multiplayer Beta) Rock Band Unplugged (Dec 10, 2008 prototype) SOCOM U.S. Navy SEALs - Fireteam Bravo (Aug 19, 2005 prototype) Saints Row - Undercover (Sep 8, 2009 prototype) Silent Hill - Origins (Aug 7, 2006 prototype) Silent Hill - Origins (Jul 19, 2007 prototype) Silent Hill - Origins (May 26, 2006 prototype) Sonic Rivals 2 Test Sample (Oct 8, 2007 prototype) The 3rd Birthday (Jan 27, 2011 prototype) The Elder Scrolls Travels - Oblivion (Apr 27, 2007 prototype) The Elder Scrolls Travels - Oblivion (Feb 1, 2007 prototype) The Elder Scrolls Travels - Oblivion (Jan 31, 2007 prototype) The Elder Scrolls Travels - Oblivion (Jun 9, 2006 prototype) The Elder Scrolls Travels - Oblivion (Nov 21, 2006 prototype) The Eye of Judgement - Legends (Sep 28, 2009 prototype) The Lord of the Rings - Tactics (Oct 4, 2005 prototype) Tiger Woods PGA Tour 09 (Jul 15, 2008 prototype) Tom Clancy’s Splinter Cell Essentials (Jan 18, 2006 prototype) WRC - FIA World Rally Championship (Aug 11, 2005 prototype) Work Time Fun (Jul 27, 2006 prototype)References[^1] - Gamasutra - Vicious Engine To Support PSP Minis Program", "excerpt": "The Sony Playstation portable used encrypted executables known as EBOOT.BIN, these are basically just an encrypted ELF file and it is possible to decrypt them with the correct tools. Some games also ship with unencrypted executables in BOOT.BIN Finding Debug symbols in retail PSP games is very rare as one...", "tags": ["psp","symbols","games"], "image": "/public/images/psp/PSP Games with Debug Symbols.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "PSYQ SDK Setup on MacOSX/Linux", "url": "/psyq-sdk-setup", "content": "Hello World exampleWe are going to use the PSX Hello world example from PSXDEV (http://www.psxdev.net/help/psyq_hello_world.html)Create a new file called Hello.C/*=========================================================== Sony PlayStation 1 Source Code=========================================================== FONT EXAMPLEDisplays text on the screen using the built in GPU routines----------------------------------------------------------- Developer / Programmer..............: SCEI & PSXDEV.net Software Ddevelopment Kit...........: PSY-Q\tLast Updated........................: 04/MAY/2017 Original code by SCEI | Edited by PSXDEV.net \tNOTE: This example uses double buffering. Copyright (C) 1994,1995 by Sony Computer Entertainment Inc. Sony Computer Entertainment Inc. Development Department. All Rights Reserved.\t\t\t\t http://psxdev.net/-----------------------------------------------------------*/#include <stdlib.h>#include <libgte.h>#include <libgpu.h>#include <libgs.h>#define OT_LENGTH 1 // the ordertable length#define PACKETMAX 18 // the maximum number of objects on the screen#define SCREEN_WIDTH 320 // screen width#define\tSCREEN_HEIGHT 240 // screen height (240 NTSC, 256 PAL)GsOT myOT[2]; // ordering table headerGsOT_TAG myOT_TAG[2][1<<OT_LENGTH]; // ordering table unitPACKET GPUPacketArea[2][PACKETMAX]; // GPU packet datau_long _ramsize = 0x00200000; // force 2 megabytes of RAMu_long _stacksize = 0x00004000; // force 16 kilobytes of stack// --------// INTEGERS// --------short CurrentBuffer = 0; // holds the current buffer number// ----------// PROTOTYPES// ----------void graphics(); // inits the GPUvoid display(); // updates the GPU (IE: VRAM/SGRAM/framebuffer)const DEBUG = 1; // debugging (1=on, 0=off)// ----// MAIN// ----int main() {\tgraphics(); // setup the graphics (seen below)\tFntLoad(960, 256); // load the font from the BIOS into the framebuffer\tSetDumpFnt(FntOpen(5, 20, 320, 240, 0, 512)); // screen X,Y | max text length X,Y | automatic background clear 0,1 | max characters\t\tif (DEBUG) // should debug be true (equal 1)...\t{\t\t// print to the TTY stream (only visible if you're using one)\t\tprintf(\"\\n\\nHello World\\n\");\t\tprintf(\"\\nhttp://psxdev.net/\");\t}\twhile (1) // draw and display forever\t{\t\tFntPrint(\" HELLO WORLD\\n\\n HTTP://PSXDEV.NET/\");\t\tdisplay();\t}\treturn 0; // this will never be reached because we're in a while loop above}void graphics(){\tSetVideoMode(1); // PAL mode\t//SetVideoMode(0); // NTSC mode\t\tGsInitGraph(SCREEN_WIDTH, SCREEN_HEIGHT, GsINTER|GsOFSGPU, 1, 0); // set the graphics mode resolutions (GsNONINTER for NTSC, and GsINTER for PAL)\tGsDefDispBuff(0, 0, 0, SCREEN_HEIGHT); // tell the GPU to draw from the top left coordinates of the framebuffer\t\t// init the ordertables\tmyOT[0].length = OT_LENGTH;\tmyOT[1].length = OT_LENGTH;\tmyOT[0].org = myOT_TAG[0];\tmyOT[1].org = myOT_TAG[1];\t\t// clear the ordertables\tGsClearOt(0,0,&myOT[0]);\tGsClearOt(0,0,&myOT[1]);}void display(){\t// refresh the font\tFntFlush(-1);\t\t// get the current buffer\tCurrentBuffer = GsGetActiveBuff();\t\t// setup the packet workbase\tGsSetWorkBase((PACKET*)GPUPacketArea[CurrentBuffer]);\t\t// clear the ordering table\tGsClearOt(0,0, &myOT[CurrentBuffer]);\t\t// wait for all drawing to finish\tDrawSync(0);\t\t// wait for v_blank interrupt\tVSync(0);\t\t// flip the double buffers\tGsSwapDispBuff();\t\t// clear the ordering table with a background color (R,G,B)\tGsSortClear(50,50,50, &myOT[CurrentBuffer]);\t\t// draw the ordering table\tGsDrawOt(&myOT[CurrentBuffer]);}32-bit compilers using WineYou can run the 32-bit compilers built for windows through WINE on Mac and Linux.Create a new batch (hello32.bat) file in the same folder as hello.c you created previously with the following contents:REM ================= PSX DEVELOPMENT ENVIRONMENT VARIABLES =============REM RELEASE 1.8 LIBRARY 3.6.1 Date: 1-31-1998 Time: 21:38:44set PATH=C:\\Psyq\\bin;set PSX_PATH=C:\\Psyq\\binset LIBRARY_PATH=C:\\Psyq\\libset C_PLUS_INCLUDE_PATH=C:\\Psyq\\includeset C_INCLUDE_PATH=C:\\Psyq\\includeset PSYQ_PATH=C:\\Psyq\\binset COMPILER_PATH=C:\\Psyq\\binset GO32=DPMISTACK 1000000 set G032TMP=C:\\TEMPset TMPDIR=C:\\TEMP CCPSX.EXE HELLO.C -o HELLO.CPE pauseYou should now be able to run this in the terminal like so:wineconsole hello32.batYou should now get an HELLO.CPE file that you need to convert to a PSX Executable with CPE2X.EXE but that only seems to work under dosbox for me…Error : could not execute cpppsxThis happens because the PSYQ.ini file has incorrect paths, since I was using the Z: drive I had to change it to:[ccpsx]stdlib=libgs.lib libgte.lib libgpu.lib libspu.lib libsnd.lib libetc.lib libapi.lib libsn.lib libc.lib libcd.lib libcard.lib libmath.libcompiler_path=Z:\\Psyq\\binassembler_path=Z:\\Psyq\\binlinker_path=Z:\\Psyq\\binlibrary_path=Z:\\Psyq\\libc_include_path=Z:\\Psyq\\includecplus_include_path=Z:\\Psyq\\includeError - can’t read ‘sn.ini’ or ‘psyq.ini’ config files - stopping.Make sure you have a file called PSYQ.INI in the bin directory and that you have not renamed it etc.16-bit compilers using DOSBoxIf you can’t get the 32-bit compilers to work there is another option, the PSYQ SDK comes with 16-bit versions of the compilers built for DOS that we can emulate in DOSBOX.The 16-bit executables are located in the psyq folder which is located at the same level as the bin directory.Create a new batch (hello16.bat) file in the same folder as hello.c you created previously with the following contents:REM ================= PSX DEVELOPMENT ENVIRONMENT VARIABLES =============REM RELEASE 1.8 LIBRARY 3.6.1 Date: 1-31-1998 Time: 21:38:44set PATH=C:\\Psyq\\psyq;set PSX_PATH=C:\\Psyq\\psyqset LIBRARY_PATH=C:\\Psyq\\libset C_PLUS_INCLUDE_PATH=C:\\Psyq\\includeset C_INCLUDE_PATH=C:\\Psyq\\includeset PSYQ_PATH=C:\\Psyq\\psyqset COMPILER_PATH=C:\\Psyq\\psyqset GO32=DPMISTACK 1000000 set G032TMP=C:\\TEMPset TMPDIR=C:\\TEMP CCPSX.EXE HELLO.C -o HELLO.CPECPE2EXE HELLO.CPEpauseNow right click this file and select open with DOSBOX which will run the batch script and leave you at a new command prompt in DOS. If everything went successfuly you will notice a generated file called HELLO.EXE.TOMB5 ExampleTomb Raider 5 (Chronicles) reversing project. It uses a modern version of make with the original PSYQ compilers so you can’t run it through PSYMAKE.In order to get this to run on MacOSX and Linux I needed to create a windows .bat file to wrap around the cc1psx.exe file so that we can run it in wineconsole with all the paths already setup.So create a new file called cc1psx.bat with the following contents:REM ================= PSX DEVELOPMENT ENVIRONMENT VARIABLES =============REM RELEASE 1.8 LIBRARY 3.6.1 Date: 1-31-1998 Time: 21:38:44set PATH=Z:\\Psyq\\bin;set PSX_PATH=Z:\\Psyq\\binset LIBRARY_PATH=Z:\\Psyq\\libset C_PLUS_INCLUDE_PATH=Z:\\Psyq\\includeset C_INCLUDE_PATH=Z:\\Psyq\\includeset PSYQ_PATH=Z:\\Psyq\\binset COMPILER_PATH=Z:\\Psyq\\binset GO32=DPMISTACK 1000000 set G032TMP=Z:\\TEMPset TMPDIR=Z:\\TEMPCCPSX.EXE %*Replace the path with the directory of your Psyq installation, I found it was easier to experiment running commands with wineconsole cmd to make sure all the paths are valid.Now we can edit the Makefile so that we can replace:CC = ccpsxwith:CC = wineconsole ./bin/cc1psx.bat", "excerpt": "Hello World example We are going to use the PSX Hello world example from PSXDEV (http://www.psxdev.net/help/psyq_hello_world.html) Create a new file called Hello.C /* =========================================================== Sony PlayStation 1 Source Code =========================================================== FONT EXAMPLE Displays text on the screen using the built in GPU routines ----------------------------------------------------------- Developer / Programmer..............: SCEI & PSXDEV.net...", "tags": ["ps1","reverseengineering","sdk","tutorial"], "image": "/public/images/ps1/Sony PS1 PsyQ SDK Setup.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Psy-Q Sega Saturn Development Kit", "url": "/psyq-sega-saturn", "content": "Introduction to PSY-Q SaturnThe PsyQ Sega Saturn development kit was developed by a partnership of Psygnosis and SN Systems in order to make it really easy to develop for both the Sega Saturn and PS1 using the same sort of development approach.*Almost* a complete Psy-Q setup! At least I have enough bits to make it do something useful now. Pretty damn happy. pic.twitter.com/JZsPnIiYkR— Matt Phillips (@bigevilboss) June 21, 2019How it workedInstead of relying on modified console such as their competitors Cross Products they used purly retail hardware with the aim of reducing costs for development studios as the retail hardware and repair costs are much cheaper than specialist hardware.In order to turn the retail consoles into a development system they used cartridges that plugged into the retail console that has software written in assembly to control the hardware.The cartridge would have a SCSI port for connection between the cartridge inside the console and the development PC. The saturn version was no different and slotted into the memory expansion slot above the CD drive.Advert for Psy-Q Sega SaturnTher is an advert in the UK magazine EDGE issue 20 for the PSYQ Sega Saturn development kit, which would be competing against the Official Cross Products development kit also advertised in the same issue:Development Manual for PSY-Q SaturnThe excellent wiki known as SegaRetro has uploaded the full development manual for using the PsyQ development kit for Sega Saturn. It is unknown where they managed to get it from but it is much appreciated by the whole sega saturn community. PSY-Q Development System Manual SegaRetro has the programmer manual available for download. Games that were built with PSYQNot many Sega Saturn games were actually developed using the PsyQ development kit unfortunately, but there were a small number of quality titles that we have confirmed use the PsyQ SDK.The Games are: Bubble Bobble also featuring Rainbow Islands Batman Forever - The Arcade Game Battle StationsInteresting PSYQ Related Strings within the GamesOn Windows/DOS systems PSYQ the PSYQ SDK was normally installed to the root of the main harddrive, so it is very common to find games that have references to the location built into the executables, such as: c:/psyq/ d:\\\\psyqsat (in the game BattleStations)From these games we also know that the PSYQ SDK install folder contained at least these folders: Folder Name Purpose include Holds all the PSYQ .h header include files segalib Holds the sega libraries for saturn PSYQ IncludesAs PsyQ Saturn was a C-based development kit, it was common to provide an api via c header (.h) files. Since there is no version of PsyQ Saturn available on the internet we have had to data mine a few games that have left over symbols in them.These are presented in the list below: File Purpose _ansi.h   ctype.h   sys/config.h   References", "excerpt": "Introduction to PSY-Q Saturn The PsyQ Sega Saturn development kit was developed by a partnership of Psygnosis and SN Systems in order to make it really easy to develop for both the Sega Saturn and PS1 using the same sort of development approach. *Almost* a complete Psy-Q setup! At least...", "tags": ["devkit","hardware","saturn","sega","snsystems","psyq"], "image": "/public/images/saturn/Sega Saturn PSYQ Development Kit.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Nintendo Paladin Leak", "url": "/paladinleak", "content": " The Paladin leak occurred on the 30th of September 2020 and included about 2.4GB of content related to the Nintendo IRIS and Pokemon spinoffs. This was the third Nintendo leak in September 2020 with the First being the Emerald leak and the second being the Platinum leak. Nintendo Emerald Leak For more information on the Emerald leak check out this post. Files LeakedAs usual the files were uploaded to anonfiles and the links shared on the 4Chan /vp board, the files were: paladin.7z (2.44GB)Contents of Paladin.7zWhen the paladin.7z archive has been extracted it creates the following contents: Dungeon - Pokemon Mystery Dungeon GBA and NDS ROMs E3 - Pokemon Leaf Green and Fire Red GBA ROMS FMC_DISK.7z - Famicom Disc System Lot Check ROMS NetCardWads - Unknown Wii Wad files for something called NetCard PokeRanger_Euro.zip - Initial Pokemon Ranger PAL Translations Ranger_EURO.zip - Final Pokemon Ranger PAL Translations Ranger_e3_060420 - Pokemon Ranger E3 Demo rangereu.7z - Pokemon Ranger PAL builds ctr_card_test.zip - Source code for a 3DS test card that seems to mainly test the units memory ctr_eFuse.zip - Source code for a tool that generates IDs for eFuses ctr_firmware.zip - 3DS Firmware source code (bootrom) ctr_test_tools.zip - 3DS DSi Backup Tools ctr_tools_red.zip - This repository contains internal tools used in Nintendo RED (Research & Engineering Department) irisSDKbulb-snapshot-031203-forToolMaker.tar.gz - IRIS SDK Files from December 3rd 2003 (with some missing files compared to the next archive) irisSDKbulb-snapshot-031203.tar.gz - IRIS SDK Files from December 3rd 2003 irisSDKbulb-snapshot-031212.tar.gz - IRIS SDK Files from December 12th 2003 irisSDKbulb-snapshot-040120-private.tar.gz - Private files not to be distributed with IRIS SDK from 20th January 2004 irisSDKbulb-snapshot-040120.tar.gz - IRIS SDK from 20th January 2004Famicom Disk System Lot Check ROMS (FMC_DISK.7z)Similar to the previous Gigaleak, this leak also contains content from the Nintendo Lot Check process, in this case it was the Famicom Disk System ROMs. Some of these games had been previously unreleased, you can find more details in our post about the Nintendo Lot Check ROMs. Nintendo Lot Check ROM Leak For full information on the new Famicom Disk System ROMs in the leak check out this post. E3 Leaf Green and Fire Red GBA ROMS (/E3)The files have the standard Nintendo SRL extension which was used both both GBA and NDS ROMS, you can rename the extension to .gba and they will play just fine in a GBA emulator.It is unclear the file naming convention and how far along the different builds of the game are but we know that the first 4 characters are the standard product ID for Leaf Green (BPGE) and Fire Red (BPRE).ROMS leakedIt is currently unknown what differences are in these builds, but you can rename them to ‘.gba’ and run them in any Game Boy Advance emulator to find out.Contents: BPGE264RR.srl - Leaf Green BPGE264RU1.srl BPGE264RU2.srl BPGE264RU5.srl BPGE264RU6.srl BPGE264RU9.srl BPRE264RR.srl - Fire Red BPRE264RU0.srl BPRE264RU3.srl BPRE264RU4.srl BPRE264RU7.srl BPRE264RU8.srl CRC.txt - Just lists the CRC codes for each of the ROMS in this directoryPokemon Mystery Dungeon (/Dungeon)In the Dungeon folder it has a bunch of Game Boy Advance and Nintendo DS ROMS for Pokemon Mystery Dungeon, they are in the SRL format which is the same as .GBA, so can you can easily play these in any GBA emulator.Mystery Dungeon GBA & NDS ROMS leakedContents: AB24J00.srl - Pocket Monsters: Fushigi no Dungeon Aka no Kyuujotai (Japanese) (GBA) NAPHJ00.srl - Pokemon Fushigi no Dungeon: Ao no Kyuujotai (Nintendo DS) ab9je00.srl - Pokemon Mystery Dungeon Red Rescue Team Demo (English) (GBA) fushigi2.srl - Some sort of Test Nintendo DS ROM fushigi_agb.bin - GBA Test ROM fushigi_agb2.bin - GBA Test ROM 2 na57e00.srl - Pokemon Mystery Dungeon Blue Rescue Team Demo (English) (Nintendo DS) na57j00.srl - Pokemon Fushigi no Dungeon: Ao no Kyuujotai Demo (Nintendo DS) naphj10.srl - Pokemon Fushigi no Dungeon: Ao no Kyuujotai (Nintendo DS) naphj10_debug.srl - Debug version of Pokemon Fushigi no Dungeon: Ao no Kyuujotai (Nintendo DS) pkd2_build157_toki_debug.srl - Debug version of Pokemon Fushigi no Dungeon: Toki no Tankentai (Nintendo DS) pkd2_build157_toki_final.srl - Pokemon Fushigi no Dungeon: Toki no Tankentai (Nintendo DS) pkd2_build157_yami_debug.srl - Debug version of Pokemon Fushigi no Dungeon: Yami no Tankentai pkd2_build157_yami_final.srl - Pokemon Fushigi no Dungeon: Yami no Tankentai (Nintendo DS) pkd2_build163_toki_debug.srl - Debug build 163 of Pokemon Fushigi no Dungeon: Toki no Tankentai pkd2_build163_yami_debug.srl - Debug build 163 of Pokemon Fushigi no Dungeon: Yami no Tankentai pocchama.srl - ? pocchama_agb.bin - Another GBA Test ROMThe Product IDs with numbers as the second 2 characters tend to be Demo versions and are not in the GBA or NDS LotCheck spreadsheet (AGB_data).NetCardWadsNot sure what these Wii WAD files are and they don’t open in the Dolphin emulator, the contents of this folder are: common-key.bin devmon.wad devmon_.wad viewer.wad - ShowMiiWads says its corrupt viewer_.wad - Sample ViewerYou can extract both devmon_.wad and viewer_.wad with the tool ShowMiiWads but it is still not clear what purpose they have.Pokemon RangerPokemon Ranger is a Nintendo Ds game that was first released in Japan on the 23rd of March 2006. It was jointly developed by HAL Laboratory and Creatures Inc.Unfortunately this leak does not have the source code for it but it does have some interesting E3 builds of the game and the translation files sent out to the localisation teams.Pokemon Ranger E3 Demo (Ranger_e3_060420)This folder contains two Nintendo DS ROMs for Pokemon Ranger, you can play these in any Nintendo DS emulator as they are the same as the .NDS format.The Contents of this folder are: tycho_e3_0604202018DSf.bin - Nintendo DS ROM Demo of Pokemon Ranger from 20th April 2006 (F) tycho_e3_0604202018DSm.bin - Nintendo DS ROM Demo of Pokemon Ranger from 20th April 2006 (M)The only difference in the file names is the last letter either being an f or an m. Currently waiting for the Pokemon Rom hacking community to figure out what the differences are in these two ROMs.Could the F stand for Female and the M stand for Male?Initial Pokemon Ranger PAL Translations (PokeRanger_Euro.zip)The PokeRanger_Euro.zip seems to be created before the localisation process for Pokemon Ranger has started, for the result of the translation process check out the other archive Ranger_EURO.zip.There is a folder called To_Alessio which were files to be sent to Alessio Danieli who is a Localization Producer at Nintendo of Europe, files in this folder are: pokemon_Ranger_NCL_log_final.xls - List of Bugs for Nintendo Japan (NCL) PokemonRanger_NOA_log_final.xls - Nintendo of America Log of Translation changes from Japanese to English capture_challenge.xls - Notes on how Pokemon appear in the capture challenge RangerTextList_Eng.xls - This is an overview of what each excel spread sheet sent to translators means Targets_QuickReference.xls - Targets and how to destroy the target (e.g Ice needs to be burned) Ranger_milestone_debug.xls - Testing script for how to test the game PokemonRanger_TaskList.xls - Priority of localization tasks between Nintendo of Europe (NOE) and Nintendo Japan (NCL) Pokemon_DataFile.xls - details about all the Pokemon in the gameThe second folder is titled To_translators and contains the documents that translators need to create their respective localization: capture_challenge.xls - Notes on how Pokemon appear in the capture challenge RangerTextList_Eng.xls - This is an overview of what each excel spread sheet sent to translators means Targets_QuickReference.xls - Targets and how to destroy the target (e.g Ice needs to be burned) Ranger_milestone_debug.xls - Testing script for how to test the game Pokemon_DataFile.xls - details about all the Pokemon in the gameThe remaining files in this folder are: NARGEd.SRL - Nintendo DS ROM for Pokemon Ranger staffrole_noa.xls - List of People who worked on Pokemon Ranger in English and Japanese - used for the credits screenPokemon Ranger PAL Translation Spreadsheets (Ranger_EURO.zip)This folder contains a slightly modified /Documents folder compared to the previous PokeRanger_Euro.zip archive, but the changes are not particularly interesting apart from the new folder containing the Japanese translations Ranger_JP.There are four localisations which each have their own separate folder with the same files but with different locale text, these are: German, Italian, French and Spanish.The list of files that are present in all the localisations are: message_tap.xls - Tap messages DPmode_message.xls - Sending data between games message_freenpc_sub.xls - NPC dialogues message_mcNPC.xls - MC brothers dialogues message_system.xls - System text & NPC dialogues PKR_Others.xls - Names of Places and Misc message_pokemove.xls - Descriptions of Pokémon moves target_text.xls - Target names & descriptions message_record.xls - Ranger Record related messages message_commu.xls - Ranger Net text message_menu.xls - Menu items graphic_text.xls - images that need to be translated message_dictionary.xls - Ranger glossary message_wslot.xls - Post-main story special missions scenario_text.xls - Mission titles and related descriptions message_powerline.xls - Poké Assist descriptions PKR_Characters.xls - Names of Characters map_text.xls - Area names and descriptions message_browser.xls - “Browser completion event” scenario message_delivery.xls - Text for the special missions to distribute message_nameselect.xls - Name entry related messages message_ending.xls - Post-main story scenario including some events and NPC dialogues message_scenario.xls - Body text (main story)The file from the previous archive RangerTextList_Eng.xls was sent to translators which explains the contents of each of these files.The other two files not related to the four localisations are at the root of this folder: PKR_EURO.xls - Pokemon Ranger Instructions for updating the documents via “macro book” NARGJ00_debag.srl - Debug version of - Pokemon Ranger NDS ROMThis folder also contains the Japanese version of the Documents seen in the previous archive (PokeRanger_Euro.zip), these are the new files in the new Ranger_JP in the documents directory: RangerTextList.xls - This is an overview of what each excel spreadsheet sent to translators means (in Japanese) PKRanger_DebugMode.doc - How to use the Pokemon Ranger debug function ポケモンレンジャー欧州版作業内容.xls - - Priority of localization tasks between Nintendo of Europe (NOE) and SMC (what is SMC?) PKRanger_milestone_JP.xls - Testing script for how to test the game (in Japanese)The most interesting document here is the PKRanger_DebugMode.doc which describes the debug functions in the provided Pokemon Ranger DS ROM. it has functions for infinite life, mission select and map select, this would make it a lot easier for translators to go to the exact area of the game to make sure the text they are writing would work in that context.Overall this is a very interesting insight into the translation process of a Nintendo DS game, it is something people don’t really think about very much but nice to see whole they solved the task, especially for PAL regions that required four additional languages.Pokemon Ranger PAL builds (rangereu.7z)When the rangereu.7z archive has been extracted you will get a folder for each of the Pokemon Ranger builds.Each folder contains both a M and F (Male/Female?) version of the European Nintendo DS ROM, it will take some time for Pokemon ROM hackers to understand all the differences in these builds but for now here is the list of builds included: 061024 - 24th October 2006 061031 - 31st October 2006 061108 - 8th November 2006 061109 - 9th November 2006 061110 - 10th November 2006 061114 - 14th November 2006 061115 - 15th November 2006 061116 - 16th November 2006 061117 - 17th November 2006 061120 - 20th November 2006 061121 - 21st November 2006 061122 - 22nd November 2006 061128 - 28th November 2006 (version 1) 061128 - 28th November 2006 (version 2) 061129 - 29th November 2006 061130 - 30th November 2006 061204 - 4th December 2006 061205 - 5th December 2006 061206 - 6th December 2006 061207 - 7th December 2006 061211 - 11th December 2006 (trial) 061212 - 12th December 2006 (trial) 061213 - 13th December 2006 (trial) 061214 - 14th December 2006 (trial)The archives Ranger_trial_eu_061214.zip and Ranger_trial_eu_061214.rar have exactly the same content inside, so they were probably seeing which format compressed the best when sending it on.3DS Test Card SVN Repository (ctr_card_test.zip)In order to access the contents of the SVN repository you have to run the following command:svn checkout \"file:///$PWD\" trunkThis is the first in a number of Citrus (CTR/3DS) source code archives which contain interesting test programs used internally at Nintendo.This project creates a 3DS ROM which has a variety of testing functions: Function Test - keeps looping over a function until B is pressed Command Test Reliability Test for ROM - Aging test Reliability Test for Writable Memory - Aging Test Back Up Memory TestSource code filesThe files that will be checked out into the trunk directory are: BackupMemoryTest.cpp - sets up the menu for the Backup Memory Test CardTestFunction.cpp - dummy functions cardFunctionTestStart and cardFunctionTestEnd CardTestFunction.h CommandTest.cpp CtrCardTest.cpp - Sets up the selectable Menu for which test to select CtrCardTest.desc - 3DS card specification file CtrCardTest.rsf - Meta-data about the Card (e.g Title, CompanyCode) FunctionTest.cpp OMakefile - OMake makefile for building the project OMakeroot - OMake build system settings ReliabilityTestForRWMemory.cpp ReliabilityTestForRom.cpp main.cpp - just contains main function that calls program.Execute from CtrCardTest nakayama.cpp - Utility functions, presumably by a guy called nakayama nakayama.h - header file for nakayama.cpp utility functions クラス図.bmp - UML Diagram of all the classes (クラス図 is Japanese for Class Diagram)The nakayama.cpp file is a pretty useful library of functions to create a basic UI for 3DS programs, it has classes such as Page/UIControl etc which can be used to create nice clean UI code.One of the more interesting files is actually クラス図.bmp which is a rare case of programmers actually using UML to design or document the code they are writing.It can be quite rare for game developers to use UML, but this class diagram was created for the Nintendo 3DS (CTR) Test Card. This was presumably created by Nakayama (nakayama.cpp) who seems to have created a nice little UI library for the 3DS. #NintendoLeaks #Nintendo3ds pic.twitter.com/drWynTWPEL— RetroReversing.com (@RetroReversing) October 3, 2020Also this project seems to use OMake rather than standard make, but since it is a fork of make it is fully backwards compatible and has a few new features such as dependency analysis 1.This needs more investigation in to how the ROM performs each of the tests, if you have a build environment set up for 3DS and an emulator then lets us know what you find.3DS eFuse SVN Repository (ctr_eFuse.zip)In order to access the contents of the SVN repository you have to run the following command:svn checkout \"file:///$PWD\" trunkThis seems to be the source code for a Unix (Windows via Cygwin) tool to generate an eFuseID. eFuse are microscopic ‘fuses’ that can be physically burned away. They are used to prevent downgrading a firmware to a lower version as each firmware requires a higher number of fuses to have been destroyed. However we are not exactly sure what this software is used for or what an eFuse ID is. Also we know that the Nintendo Switch uses eFuses but no record of the 3DS using eFuses.All we know is that this project uses openssl and uses private/public key encryption using AES.It creates three different executables: outputSharpID - Outputs the ID in a format corresponding to testSharpID sharp testSharpID gen_idSource Code FilesThe files that will be checked out into the trunk directory are: Makefile - Makefile for gen_id Makefile.outputSharpID - Makefile for outputSharpID executable Makefile.sharp - Makefile for sharp executable Makefile.testSharpID - Makefile for testSharpID executable ReleasePackage.sh - creates a zip archive for the sharp executable cr_alloc.c - memory allocation functions cr_alloc.h - memory allocation header cr_device_cert.c - create 3DS (CTR) Device certificate cr_enc_id.c - functions such as EncryptID cr_generate_id.c - functions such as cr_generate_id cr_generate_id.h - header for cr_generate_id cr_generate_id_private.h - private internal functions for generate_id cr_hsm_alloc.c - memory allocation for HSM cr_hsm_alloc.h - header for cr_hsm cr_hsm_bignum.c - big number functions (from nCipher Corporation Limited) cr_hsm_bignum.h - header for cr_hsm_bignum cr_hsm_code.c - functions such as hsm_aes_encrypt and hsm_rsa_decrypt cr_hsm_code.h - header for cr_hsm_code cr_id_util.c - utility functions such as GetTimestamp cr_keyPair.c - functions such as GenarateECCKeyPair dep_objs - empty folder document - function documentation in japanese dummyKey hsm_utils - utility functions for the Hardware Security Module (HSM) main.c - main entry point for gen_id.exe and libgenid.a main2.c - main entry for executable called testSharpID.exe main3.c - main entry point for outputSharpID.exe output - empty folder package - just contains OpenSSL archives (openssl-0.9.8k.tar.gz) realKey - folder that contains eFuse_iv.bin and NCT2_pub.der for both dev and production sample.c - main entry point for sharp.exe tools - contains perl scripts for bin2c, merge_lib_objs_hsm and merge_lib_objs util.c - small number of utility functions keyboard_is_hit util.h - header for utilIf you know anything about this tool please reach out to us so we can update the information here.Mystery from the Nintendo Paladin Leak: Why is there a Nintendo 3DS "eFuse" repository when they were not used on the console? The switch used eFuses to prevent downgrading firmware versions but the 3DS did not as far as we know. https://t.co/1BrJ1wDS7i #NintendoLeaks #3ds— RetroReversing.com (@RetroReversing) October 3, 20203DS Firmware SVN Repository (ctr_firmware.zip)In order to access the contents of the SVN repository you have to run the following command:svn checkout \"file:///$PWD\" trunkThe files that will be checked out into the trunk directory are: Makefile bootrom doc firmware public readme.txt setup tools3DS DSi Backup Tools (TwlBkpCheck) SVN Repository (ctr_test_tools.zip)In order to access the contents of the SVN repository you have to run the following command:svn checkout \"file:///$PWD\" trunkThe ctr_test_tools.zip archive contains source code for a tool called TwlBkpCheck which was created for the DSi (Project Twilight/TWL) partition on the 3DS.The project comes in two parts, one that runs on the 3DS itself and the other that runs on Windows PCs.TwlBkpImporter for 3DSThe first tool is for the 3DS system itself and it is called TwlBkpImporter, which seems to be a tool to import a previously backed-up DSi (partition?/game?) from the SD card into the TWL NAND partition, the source files are: TwlBkpImporter/sdAccessor.h - header file for SD card functions TwlBkpImporter/OMakefile - OMakefile for the 3DS rom TwlBkpImporter/twlBkpImporter.rsf - Meta-data about the Card (e.g Title, CompanyCode) TwlBkpImporter/window.cpp - implementation of the Window class methods TwlBkpImporter/sdAccessor.cpp - functions to read from the SD Card TwlBkpImporter/window.h - header file for Window class TwlBkpImporter/draw.cpp - drawing functions such as DrawBinaryFile TwlBkpImporter/main.cpp - main method nnMain with initialise code TwlBkpImporter/draw.h - header for drawing functions OMakefile - calls OMake for all sub folders apart from BinOne interesting thing is that some of the source files says they are part of project “Horizon”, but it is not mentioned anywhere what this project is.The Bin folder contains the compiled version as two different CCI ROM files: twlBkpImporterForWPS_DevFast_r43296.cci twlBkpImporter_DevFast_r43296.cciOne of the builds is TwlBkpImporterForWPS, the WPS stands for With Private Save, the make file for this is in the TwlBkpImporterForWPS folder: TwlBkpImporterForWPS/OMakefileTwlBkpCheck for WindowsThe other folder holds the Windows based tools for the TwlBkpCheck tool, the contents are: TwlBkpCheck.sln - Visual Studio solution (project file)The Bin folder just contains the compiled results of both TWLBackupBlock and FalsifyTwlBackup: FalsifyTwlBackup.exe TwlBackupBlock.dll - dynamic library used by FalsifyTwlBackup.exe to read TWL: backup filesTWLBackupBlock (.net C# Project)This is a Dynamic Library that provides encryption / decryption processing for TWL backup data. Not sure if this is for TAD files, the contents are: ExtBinaryReader.cs SignatureBody.cs Utility.cs AesCmac.cs TmdReserved.cs HeaderBody.cs Body.cs Block.cs Blocks.cs Properties Properties/AssemblyInfo.cs Properties/Settings.Designer.cs Properties/Resources.resx Properties/Settings.settings Properties/Resources.Designer.cs TwlBackupBlock.csproj AbstractBody.csFalsifyTwlBackup (.net C# Project)This is a .net C# executable that seems to modify a TWL backup by removing sections of bytes and replacing with 0-only bytes.There seems to be 6 different categories of modifications it will make (1xx,2xx,3xx,4xx,5xx and 9xx).This program is to presumably create bad input for the 3DS TwlBkpImporter application to test that it correctly errors on bad input. The contents of this folder are: Category1xx.cs Properties.cs - Standard C# file with meta-data Category9xx.cs main.cs Category5xx.cs FalsifyTwlBackup.csproj - Standard C# Project file Properties/AssemblyInfo.cs - Standard C# file with meta-data Falsify.cs - functions such as CreateImproperData Category4xx.cs Category3xx.cs Category2xx.csWhen trying to run the FalsifyTwlBackup.exe executable the following usage information is printed:./FalsifyingTwlBackup.exe BACKUP_FILE ENC_KEY_FILE MAC_KEY_FILE [-mode MODE] [-type TYPE] BACKUP_FILE : *.bin ENC_KEY_FILE : *.txt MAC_KEY_FILE : *.txt MODE all (default) : output all falsifying pattern cat:CAT_NUM : output all pattern of CAT_NUM category ex) -mode cat:100 -> falsifying 100,101,102.... each:PAT_NUM : output PAT_NUM pattern ex) -mode each:204 -> falsifying 204 only verify : verify backup file TYPE normal (default) : normal bkp type wps : bkp with private save type legacy : legacy bkp typeSecond Mystery from the Paladin Leak, what were the DSi Backup tools for 3DS used for (FalsifyTwlBackup). They seem to be tools to import a DSi Backup and "Falsify" it but why would this be needed on the 3DS? https://t.co/1BrJ1wmgII #nintendoleak— RetroReversing.com (@RetroReversing) October 3, 2020Nintendo RED 3DS Tools (ctr_tools_red.zip)In order to access the contents of the SVN repository you have to run the following command:svn checkout \"file:///$PWD\" trunkThe folders that will be checked out into the trunk directory are: HSM_Server - Hardware Security Module Server for signing content from the 3DS Store MakeUpdatePartition - Create the Update Partition in a 3DS Game MasterEditorCTR MediaSizeTestProjectMaker MetaDataExtractor RatingEditorCTR RomCompareTool masteringHSM Server by Sarion Systems ResearchSarion Systems Research is a Japanese Company who specialise in Hardware Security Modules (HSM) 2.This is the source code to a server that issues HSM certificates for 3DS downloadable content. This acts in a similar way to browsers certificate authorities to make sure that the software being sent to the 3DS is signed by official sources and has not been tampered with.Basically it is Java EE web application source code that gets compiled into a war file and uses apache as the web server for static content.They call the application Web Service Signer (WSSigner) and it comes in a few parts: Wssigner-client - sample client -this would probably have been used to help development of the 3DS Game Store, although of course it would not have been written in Java like this sample is WSSigner-API - The main API uses to get signed content and make sure the content is correctUnless you are really interested in security and cryptography you will probably not be interested in this source code.MakeUpdatePartitionThis folder contains the source code for a tool that updated *.cia files and adds a standard update partition into it.Presumably this tool is used just before mastering the final Game card so that it will contain the necessary update data so that if the user doesn’t have a high enough firmware version, they can update via the Game Card.Most if not all 3DS game cards had update partitions with the latest firmware available at the time on them.This project is a mix of Python and bash scripts a long with two executables which we are not sure the purpose of: imas-tool.4.8.1.exe CommandLineOls.exeNote that many of these files confirm that the 3DS operating Systems name was “Horizon”.CommandLineOls (Official Licensing Service/Server?)When you try to run the ** executable from the Command Prompt it provides the following usage information:Usage: ./CommandLineOls *.xml threadNum[default=1]It is not clearly understood the purpose, but we believe it is a tool to contact the Official Licensing Server (OLS) to create signed licenses for each game title, presumably it is quite an extensive operation if you can customise the number of threads used!Although there is a few scripts that can give a clue as to what this tools does, they are: genDevOlsXml.py genOlsXml.py genProdOlsXml.pyWhen you try to run one of the python files it prints the following usage information:Usage: genOlsXml.py UserName Password Tin downloadDirectory serverName titlePassword ciaFiles...The Username and Password will be for a Nintendo user admin, serverName will presumably be one of the licensing servers that handles 3DS content.IMAS Tool (Item Uploader?)The executable imas-tool.4.8.1.exe is quite interesting, while we don’t quite know the purpose of it, some of the contents can be seen using a simple strings command.It contains compiled Java classes for apache and even some from Nintendo, this is because the executable is using Launch4J, so it’s a Java application that looks like a standard executable.You can see the Nintendo files in the table below. Name Possible Purpose jp/co/nintendo/imas/tool/ImasTool.class   jp/co/nintendo/imas/tool/MailSender.class   jp/co/nintendo/imas/tool/util/PropertyManager$PropertyKey.class   jp/co/nintendo/imas/tool/util/UserConfigurationManager.class   jp/co/nintendo/imas/tool/util/Messages.class   jp/co/nintendo/imas/tool/util/UserConfigurationManager$1.class   jp/co/nintendo/imas/tool/util/ImasUrlUtil.class   jp/co/nintendo/imas/tool/util/PropertyManager.class   jp/co/nintendo/imas/tool/util/ImasToolUtil.class   jp/co/nintendo/imas/tool/xml/Proxy.class   jp/co/nintendo/imas/tool/xml/BmsAccount.class   jp/co/nintendo/imas/tool/xml/Operation.class   jp/co/nintendo/imas/tool/xml/Configuration.class   jp/co/nintendo/imas/tool/xml/Operations.class   jp/co/nintendo/imas/tool/xml/Titles.class   jp/co/nintendo/imas/tool/xml/ObjectFactory.class   jp/co/nintendo/imas/tool/xml/Notification.class   jp/co/nintendo/imas/tool/xml/RsaServerDownNotification.class   jp/co/nintendo/imas/tool/xml/Title.class   jp/co/nintendo/imas/tool/xml/ServerInfo.class   jp/co/nintendo/imas/tool/HttpClientManager$1.class   jp/co/nintendo/imas/tool/OlsException.class   jp/co/nintendo/imas/tool/ResponseParser.class   jp/co/nintendo/imas/tool/ResponseParser$1.class   jp/co/nintendo/imas/tool/NotificationException.class   jp/co/nintendo/imas/tool/HttpClientManager.class   jp/co/nintendo/imas/tool/BtsException.class   jp/co/nintendo/imas/tool/BmsException.class   jp/co/nintendo/imas/tool/HttpClientManager$3.class   jp/co/nintendo/imas/tool/HttpClientManager$2.class   jp/co/nintendo/imas/tool/MailSender$1.class   jp/co/nintendo/imas/tool/enums/OperationEnum.class   jp/co/nintendo/imas/tool/enums/CountryEnum.class   jp/co/nintendo/imas/tool/enums/PlatformEnum.class   jp/co/nintendo/imas/tool/enums/BmsErrorCodeEnum.class   jp/co/nintendo/imas/tool/enums/TitleTypeEnum.class   jp/co/nintendo/imas/tool/ols/BtsOperation$UploadStatusTask.class   jp/co/nintendo/imas/tool/ols/BtsOperation.class   jp/co/nintendo/imas/tool/ols/OlsOperation.class   jp/co/nintendo/imas/tool/ols/AbstractOlsOperation.class   jp/co/nintendo/imas/tool/HttpClientManager$4.class   jp/co/nintendo/imas/tool/HttpClientManager$5.class   jp/co/nintendo/imas/tool/messages.properties   jp/co/nintendo/imas/tool/messages_ja.properties   jp/co/nintendo/imas/tool/HttpManager.class   jp/co/nintendo/imas/tool/RsaServerDownException.class   jp/co/nintendo/imas/tool/Constants.class   META-INF/maven/jp.co.nintendo/imas-tool/pom.xml   META-INF/maven/jp.co.nintendo/imas-tool/pom.properties   If you try to run the application with a Java Runtime installed it shows the following usage information and then quits: Usage: Execute from command line : ./item-uploader.exe [Configuration file] Execute from explorer : Drag & drop a configuration file over item-uploader.exe icon IRIS Software Development KitThe IRIS project was supposed to be the next in the Game Boy line, a more powerful Game Boy Advance with a single screen. Later the project was changed into the NITRO project when another screen was added and it became the Nintendo DS.Files from December 3rd 2003 for ToolMaker (irisSDKbulb-snapshot-031203-forToolMaker.tar.gz)The irisSDKbulb-snapshot-031203-forToolMaker.tar.gz archive is the earliest known Software development kit for the IRIS project.There are some files that are not in this archive that are in the irisSDKbulb-snapshot-031203.tar.gz archive instead, namely the docs/_private/ folder which will be covered in the next section.As for the files in this archive they are just earlier versions of the IRIS SDK so check out the section below for the files in the last known version of the IRIS SDK as it is very similar.Files from December 3rd 2003 (irisSDKbulb-snapshot-031203.tar.gz)This is almost exactly the same as the content from irisSDKbulb-snapshot-031203-forToolMaker.tar.gz but contains some new files which I guess are not to be sent in the forToolMaker build (whatever that is).All the new files are under the folder docs/_private/ which is a completely new directory, these files are: how-to-make-headers.txt web CodeWarriorFiles from December 12th 2003 (irisSDKbulb-snapshot-031212.tar.gz)The contents are pretty much the same as December 3rd but there has been development work so there isn’t that many new files but quite a few source files have changed, which is to be expected.Nothing of real interest is in this archive unless you want to see the progress made between two different snapshots. Check out the last IRIS SDK (irisSDKbulb-snapshot-040120.tar.gz) for an overview of the contents of the IRIS SDK.Private Files from 20th January 2004 (irisSDKbulb-snapshot-040120-private.tar.gz)This is an interesting archive as it only contains contents not found in the other build from 20th January 2004 (irisSDKbulb-snapshot-040120.tar.gz).These files are: ./KnownIssues ./KnownIssues/031212 ./KnownIssues/031212/kagemai.css ./KnownIssues/031212/69.htm ./KnownIssues/031212/126.htm ./KnownIssues/031203 ./KnownIssues/031203/kagemai.css ./KnownIssues/031203/110.htm ./KnownIssues/031203/69.htm ./KnownIssues/031203/81.htm ./KnownIssues/@ ./READMEs-Snapshot ./READMEs-Snapshot/@ChangeLog.cvs ./SDKTools ./SDKTools/@CVS-TagTable.rtf ./SDKTools/@WinCvsSetting.rtfFiles from 20th January 2004 (irisSDKbulb-snapshot-040120.tar.gz)This is the last known version of the IRIS SDK built on the 20th of January 2004, presumably just after the Nintendo DS (NITRO) project was started as it contains files referencing the project under the name Nitro.Contents: Makefile SrcTreeMap.txt build - source code docs - Documentation for using the SDK such as Release Notes and the Nitro ROM format include - C/C++ header files lib - Precompiled Static Libraries man - Manual in japanese tools - Tools such as elftobin and makeromDocumentation (/docs)Contents: ./SDKHowTo ./SDKHowTo/HowToBuildSDKTree.rtf ./SDKRules ./SDKRules/Rule-Defines.html ./SDKRules/Rule-NameSpace.html ./SDKRules/irisSDKstandard.css ./TechnicalNotes ./TechnicalNotes/NitroRomFormat.rtf ./READMEs-Snapshot ./READMEs-Snapshot/ChangeLog.cvs ./READMEs-Snapshot/QuickStartForIrisSDK.rtf ./READMEs-Snapshot/history ./READMEs-Snapshot/history/ReleaseNotes-031212.rtf ./READMEs-Snapshot/history/ReleaseNotes-031203.rtf ./READMEs-Snapshot/ReleaseNotes-040120.rtf ./READMEs-Snapshot/AboutChangelog.rtf ./SDKTools ./SDKTools/CygwinPackageList.rtfIRIS Sub-processor (IRIS_SP) Header files (/include/iris_sp)These files are for the ARM7 CPU core and would be included in your C/C++ source code in order to use the functionalities provided by the Sub-processor SDK library. Name Description ./iris_sp.h   ./iris_sp/init   ./iris_sp/init/crt0.h   ./iris_sp/hw   ./iris_sp/hw/mmap_global.h   ./iris_sp/hw/ioreg_SPSND.h   ./iris_sp/hw/ioreg.h   ./iris_sp/hw/mmap_wram.h   ./iris_sp/hw/ioreg_SPPAD.h   ./iris_sp/hw/armArch.h   ./iris_sp/hw/ioreg_SPMPI.h   ./iris_sp/hw/ioreg_SPDISP.h   ./iris_sp/hw/ioreg_SPOS.h   ./iris_sp/hw/ioreg_SPMI.h   ./iris_sp/code32.h   ./iris_sp/os.h   ./iris_sp/memorymap.h   ./iris_sp/snd   ./iris_sp/snd/snd_capture.h   ./iris_sp/snd/snd_channel.h   ./iris_sp/snd/snd.h   ./iris_sp/snd/snd_init.h   ./iris_sp/snd/snd_util.h   ./iris_sp/os   ./iris_sp/os/interrupt.h   ./iris_sp/os/system.h   ./iris_sp/code16.h   IRIS Header files (/include/iris)These files are for the ARM9 CPU core and would be included in your C/C++ source code in order to use the functionalities provided by the main processor SDK library. Name Description ./iris/init   ./iris/init/crt0.h   ./iris/ARM7-TEG.lcf   ./iris/version.h   ./iris/hw   ./iris/hw/ioreg_PAD.h   ./iris/hw/ioreg_G3X.h   ./iris/hw/mmap_global.h   ./iris/hw/ioreg_G3.h   ./iris/hw/ioreg_OS.h   ./iris/hw/mmap_shared.h   ./iris/hw/ioreg.h   ./iris/hw/mmap_main.h   ./iris/hw/armArch.h   ./iris/hw/ioreg_MI.h   ./iris/hw/mmap_vram.h   ./iris/hw/ioreg_GX.h   ./iris/hw/mmap_tcm.h   ./iris/hw/ioreg_SPI.h   ./iris/hw/ioreg_CP.h   ./iris/hw/ioreg_G2.h   ./iris/types.s   ./iris/code32.h   ./iris/types.h   ./iris/mi   ./iris/mi/wram.h   ./iris/mi/dma.h   ./iris/mi/exMemory.h   ./iris/ARM9-BB.lcf   ./iris/misc.h   ./iris/fx   ./iris/fx/fx.h   ./iris/fx/fx_mtx33.h   ./iris/fx/fx_trig.h   ./iris/fx/fx_mtx43.h   ./iris/fx/fx_cp.h   ./iris/fx/fx_mtx44.h   ./iris/fx/fx_mtx.h   ./iris/fx/fx_const.h   ./iris/fx/fx_vec.h   ./iris/os.h   ./iris/ARM7-BB.lcf   ./iris/pad   ./iris/pad/pad.h   ./iris/ARM9-TEG.lcf   ./iris/memorymap.h   ./iris/ARM9-TEG.lcf.template   ./iris/gx   ./iris/gx/gx.h   ./iris/gx/g3c.h   ./iris/gx/g3x.h   ./iris/gx/g3.h   ./iris/gx/g2_oam.h   ./iris/gx/gxcommon.h   ./iris/gx/gx_vramcnt.h   ./iris/gx/g2.h   ./iris/gx/gx_load.h   ./iris/gx/g3imm.h   ./iris/gx/g3_util.h   ./iris/gx/gx_capture.h   ./iris/gx/g3b.h   ./iris/gx/gx_bgcnt.h   ./iris/os   ./iris/os/spinLock.h   ./iris/os/halt.h   ./iris/os/protectionUnit.h   ./iris/os/context.h   ./iris/os/cache.h   ./iris/os/message.h   ./iris/os/protectionRegion.h   ./iris/os/emulator.h   ./iris/os/systemCall.h   ./iris/os/timer.h   ./iris/os/thread.h   ./iris/os/printf.h   ./iris/os/interrupt.h   ./iris/os/system.h   ./iris/os/mutex.h   ./iris/os/utility.h   ./iris/os/init.h   ./iris/os/exception.h   ./iris/os/arena.h   ./iris/os/alloc.h   ./iris/os/tcm.h   ./iris/cp   ./iris/cp/sqrt.h   ./iris/cp/divider.h   ./iris/code16.h   ./iris.h   Precompiled Static Libraries (*.A) (/lib)These are: ARM7-BB - Sub processor Library compiled for Bread Board IRIS ARM7-TEG - Sub processor Library compiled for TEG board IRIS ARM9-BB - Main processor Library compiled for Bread Board IRIS ARM9-TEG - Main processor Library compiled for TEG board IRISThe compiled libraries are: libirissubpsyscall.a - Sub processor Library libirissubpsyscall_arm.a - Sub processor Library (compiled for ARM) libirissyscall.a - Main processor Library libirissyscall_arm.a - Main processor Library (compiled for ARM) crt0.o libfx.a libgx.a libirissyscall.a libirissyscall_arm.a libmi.a libos.a libstubsisd.aJapanese Manual (/man/ja_JP)Contents: a-z.html contents.html cp css demos fx gx icons.html index.html main.html mi os pad snd svcTools (/tools)contents: ./bin ./bin/makelcf.exe ./bin/dis ./bin/makerom.exe ./makerom ./makerom/spMain_defs.sbin ./makerom/spMain.sbin ./elftobin ./elftobin/spIdle.elf ./elftobin/romHeader.bin ./elftobin/IrisPostLinker.batBuild (/build)Contents: Makefile buildsetup buildtools demos libraries libraries_sp tests toolsContents: Makefile fs fx gx ide mi os pad template template_spReferences The OMake build system ↩ HSM - Sarion Systems Research ↩ ", "excerpt": "The Paladin leak occurred on the 30th of September 2020 and included about 2.4GB of content related to the Nintendo IRIS and Pokemon spinoffs. This was the third Nintendo leak in September 2020 with the First being the Emerald leak and the second being the Platinum leak. Nintendo Emerald Leak...", "tags": ["leak","ds","3ds","gba"], "image": "/public/images/leaks/PaladinLeak.jpg", "consoleImage": "/public/images/RetroReversingLogoSmall.png", "console": null } ,{ "title": "Pilotwings 2D Art Workspace (fly/flyman)", "url": "/pilotwings-2d-art-workspace", "content": "The Nintendo Gigaleak preserves a separate Super Mario Kart art workspace under other/NEWS/テープリストア/NEWS_04/home/sugiyama/fly and home/sugiyama/flyman/, from Nintendo artist Tadashi Sugiyama.These directories are almost entirely art-side production material from the Super Nintendo Pilotwings game. Super Famicom / SNES File Formats For cross-project format definitions and evidence-backed extension behavior, see the SNES File Formats page. At a GlanceThe fly and flyman folders form a complete artist workspace pair with 817 files total and no subdirectories.That flat, two-folder structure makes the archive feel less like a cleaned release and more like a direct snapshot of one developer’s working branches copied at tape-restore time.Despite the simple folder structure, the file families split into several clear production domains: Art and graphics - fly contains 102 CGX tile banks, 69 COL palettes, 78 SCR composition tests Disciplines - Pilotwings vocabulary: SKYDIVE, HANG, PARA, ROCKET, PLANE, HELI with lesson/layout variants Mode 7 system - 47 M7-prefixed files including terrain banks, 9 weather/condition palettes, HUD overlays Mission layout - flyman with 429 files organizing lessons into MAP1-8 core spine plus RACE, JUMP, BONUS, CHIKA branches Combat layer - BOSS progression, underground bosses (CHIKABOSS), UFO enemies, CORE targets, combat backdrops Iteration evidence - 276 BAK files showing sustained production iteration, not one-shot asset dumpThe file type breakdown is stark: Type In fly In flyman Combined reading CGX (tile graphics) 102 3 Graphics production concentrated in fly with a small helper set in flyman COL (palettes) 69 1 Palette work is mostly art-side with one layout-side companion palette SCR (layout/composition) 78 286 flyman is SCR-heavy mission composition OBJ (object-side data) 2 0 Object definitions in fly only BAK (backups) 137 139 Heavy iteration trail in both folders This distribution shows a clean pipeline: fly produces reusable art components while flyman assembles mission layouts and progression structure. The presence of 276 backup files indicates this workspace captures an active iteration snapshot, not a frozen final export.Glossary of Key TermsIf you are new to SNES art and layout production terminology, this glossary will help clarify the technical terms used throughout this page. fly - Art-side folder with tiles, palettes, and object graphics. flyman - Layout-side folder with mission and screen assembly files. Mode 7 - SNES background mode used for scaling and rotation effects. CGX - Tile graphics bank data. SCR - Screen layout composition data. COL - Palette data. OBJ - Object-side definitions. BAK - Local backup snapshot copy. Tadashi Sugiyama - Nintendo developer whose NEWS_04 home contains fly, flyman, CAR, SIM, MARIO, and FX2.Executive summaryfly and flyman open on the same day (1989-10-13) and split cleanly into art production vs layout composition.The branch contains strong Pilotwings discipline vocabulary and a large Mode 7 package.It also contains explicit combat naming that extends beyond neutral training labels.The best current reading is a branch where Pilotwings lesson content and combat-capable mission content coexisted, including material consistent with the helicopter combat lane seen in the shipped game.Folder snapshotThe folders share origin timing but diverge in closure behavior.flyman closes in 1991, while fly carries late 1994 timestamps likely influenced by tape restore handling. Folder Files Date range Dominant types Role fly 388 1989-10-13 to 1994-03-18 CGX, SCR, COL, BAK Art production and palette variants flyman 429 1989-10-13 to 1991-05-07 SCR, BAK Stage and lesson composition Discipline matrixThe clearest evidence for Pilotwings-era identity is discipline naming. Family Example files Interpreted feature Skydiving SKYDIVE.* Skydiving mission assets Hang gliding HANG.*, HANG-L.* Hang-glider mission variant set Parachute PARA.*, PARA-L.* Parachute mission assets and layout variants Rocket belt ROCKET.*, ROKETMAN.* Rocket belt mission and rider graphics Plane PLANE.* Fixed-wing mission art Helicopter HELI.*, HELI-L.* Helicopter mission variant set This is a dense cluster of flight-discipline naming.That concentration is hard to explain as generic flight tooling.Combat matrixThe branch also preserves combat-oriented naming families. Family Example files Why it matters Boss BOSS*, BOSS-1/2/3* Explicit enemy progression naming Underground boss CHIKABOSS* Named boss context per mission environment Enemy craft UFO* Multi-variant enemy family Target cores CORE* Destructible/target object naming pattern Bombs OBJ-BOMB* Weapon/object layer naming Combat backgrounds BG-FORTRESS*, BG-ENEMYSHIP*, BG-BASESHIP* Combat scenario environment set Shipped Pilotwings does include combat in the final helicopter test, with projectile fire against ground targets.The interesting question is not whether combat existed, but how broad and differently framed that combat content was during production.Mode 7 architecture deep diveThe M7-* set looks like a modular terrain and condition system. Group Example files System role Base terrain banks M7-BG-L.*, M7-BG-L-NIGHT.* Day/night terrain tile sources Mission terrain banks M7-BG-RACE.*, M7-BG-JUMP.*, M7-BG-HELI.*, M7-BG-DESERT.*, M7-BG-BONUS.* Mission-specific world surfaces Course packs M7-BG-C0.*, M7-BG-C00.*, M7-BG-C01.* Alternate course tile variants Condition palettes M7-L-FINE.*, M7-L-RAIN.*, M7-L-SNOW.*, M7-L-SUNSET.*, M7-L-NIGHT.*, M7-L-DESERT.* Weather/time-of-day palette switching Sub-context palettes M7-CHIKA.*, M7-FORTRESS.* Underground and fortress context palette sets HUD overlays M7-METER.*, M7-METER-B.* Cockpit or mission status UI overlays This pattern suggests a production workflow where a small set of geometry/tile bases could be re-skinned by palette and mission context.That is efficient for memory-limited SNES workflows and consistent with late-1980s/early-1990s console production habits.flyman layout grammarflyman appears to encode lesson and mission progression as grouped screen families. Group Likely function Notes MAP1 to MAP8 Core mission progression Numbered progression indicates explicit curriculum flow CHIKA-* Underground mission block Mirrors underground palette families in fly BONUS* Bonus mission branch Non-core progression branch POOL* Water mission branch Distinct environment context DESERT* Desert mission branch Matches desert Mode 7 families JUMP* Jump-focused training/race branch Mechanical skill emphasis RACE* Racing branch Separate pacing from free-flight lessons BGBG-* Multi-layer background composites Indicates composition-level layering work A practical reading is that fly supplied reusable art modules while flyman assembled stage-facing lesson screens and mission sequences.Mode 7 composition and course variantsThe M7-BG-C0/C00/C01 naming pattern deserves closer attention now that we have actual file presence data.In fly these three tiles exist: M7-BG-C0.CGX, M7-BG-C0.CGX.BAK (dated Oct 13, 1989) M7-BG-C00.CGX, M7-BG-C00.CGX.BAK (dated Oct 13, 1989) M7-BG-C01.CGX, M7-BG-C01.CGX.BAK (dated Oct 13, 1989)All three arrived on the same day with identical backup pairs. This is not random - it is three coordinated course base tiles.Matching palette sets exist for each: M7-C0.COL (base palette for C0) M7-C00-A.COL, M7-C00-B.COL, M7-C00-C.COL, M7-C00-DAME.COL (four palette variants for C00) M7-C01.COL (palette for C01)This suggests: C0 is a single-palette course variant C00 is a course with 4 distinct color schemes (possibly different times of day or difficulty modes) C01 is another single-palette variantIn practical gameplay terms: players could fly three different aerial courses (C0, C00, C01) using shared terrain code but distinct tile banks and multiple weather/time-of-day palettes.The C prefix interpretation remains open (course, condition, context, or credential), but the systematic presence of three parallel course trees makes “course” more credible than ever.Deeper Mode 7 condition-palette catalogThe M7-L-* palette family is larger and more structured than initially noted.Complete catalog of weather/condition states in fly: State Palette files present Variant count Notes FINE (clear weather) M7-L-FINE.COL, M7-L-FINE.COL.BAK 1 Baseline daylight RAIN M7-L-RAIN.COL, M7-L-RAIN.COL.BAK 1 Wet/overcast mood SNOW M7-L-SNOW.COL, M7-L-SNOW.COL.BAK 1 Cold palette SUNSET M7-L-SUNSET.COL, M7-L-SUNSET.COL.BAK 1 Evening/dusk transition NIGHT M7-L-NIGHT.COL, M7-L-NIGHT.COL.BAK 1 Dark/night flight DESERT M7-L-DESERT.COL, M7-L-DESERT.COL.BAK 1 Sand/arid environment GRASS M7-L-GRASS.COL, M7-L-GRASS.COL.BAK 1 Green/vegetation mood ISLAND M7-L-ISLAND.COL, M7-L-ISLAND.COL.BAK 1 Tropical/water-adjacent color Base M7-L M7-L.COL, M7-L.COL.BAK 1 Default terrain palette This gives 9 total condition palettes (8 named states plus 1 base), each with a backup pair.Interpretation: Each condition likely represents a distinct atmospheric or environmental mood that could be swapped at runtime. The backup prevalence shows active iteration on color tuning for each state. A mission could select its own condition palette (e.g., RAIN for a storm-flight lesson, SUNSET for an evening race) independently of the tile bank. The range from generic (FINE, NIGHT) to specific (DESERT, ISLAND) suggests both universal moods and location-specific palettes.This modular palette system is a hallmark of efficient SNES production: buy one set of terrain tiles, swap eight color schemes to generate 8 distinct-feeling environments.File-level walkthroughTo go deeper than folder labels, it helps to look at how specific filename families appear to cooperate.The pattern below is the clearest recurring structure in the workspace. Layer Example files Practical role Tile banks M7-BG-RACE.CGX, M7-BG-JUMP.CGX, M7-BG-HELI.CGX Core visual tiles for each mission context Palette states M7-L-FINE.COL, M7-L-RAIN.COL, M7-L-SNOW.COL, M7-L-NIGHT.COL Lighting and weather swaps over shared terrain Screen composition M7-METER.SCR, M7-METER-B.SCR and MAP*/mission SCR groups Runtime layout and HUD composition That three-part structure is exactly what you would expect from an efficient SNES pipeline.It keeps expensive tile production reusable while moving variation into smaller palette and layout layers.Representative family dossiersThese family snapshots are useful because they combine naming semantics with likely production intent. Family Example evidence Why this family matters SKYDIVE SKYDIVE.* Strong direct link to Pilotwings lesson vocabulary HANG HANG.*, HANG-L.* Base plus variant grammar suggests lesson/layout split PARA PARA.*, PARA-L.* Another base plus variant family with consistent discipline naming ROCKET / ROKETMAN ROCKET.*, ROKETMAN.* Indicates both mission context and character/object-side representation M7-BG-* M7-BG-L.*, M7-BG-RACE.*, M7-BG-DESERT.* Coherent Mode 7 world-surface namespace M7-L-* M7-L-FINE.*, M7-L-RAIN.*, M7-L-SUNSET.* Condition state system, likely swapped at runtime The repeated base-plus-variant behavior across multiple discipline families is one of the strongest signs of deliberate content planning.Combat footprint detailThe combat layer is not just a single odd token.It spans objects, enemies, and environment sets. Combat class Example files Interpretation Enemy hierarchy BOSS*, BOSS-1*, BOSS-2*, BOSS-3* Progression-oriented enemy tiering Area-specific bossing CHIKABOSS* Underground branch likely had distinct boss content Enemy craft UFO* Multiple related enemy variants Object payload OBJ-BOMB*, CORE* Combat-object and target logic footprint on asset side Stage backdrop BG-FORTRESS*, BG-ENEMYSHIP*, BG-BASESHIP* Combat-specific stage themes beyond flight lessons For a reader, this is the key tension in the archive.The same workspace that looks strongly Pilotwings-like also preserves a broader combat vocabulary than the final game surfaces outside its helicopter combat segment.Notable filename evidence setsIf you want the shortest high-signal view of this archive, these are the most useful exemplar sets.Each set groups names that, together, show one production behavior clearly. Evidence set Example names Low-level reading Discipline identity set SKYDIVE.*, HANG.*, PARA.*, ROCKET.*, PLANE.*, HELI.* Mission disciplines were authored as distinct content families, not generic placeholders Mode 7 and state set M7-BG-L.*, M7-BG-RACE.*, M7-BG-JUMP.*, M7-BG-DESERT.*, M7-L-RAIN.*, M7-L-SNOW.*, M7-L-NIGHT.* Terrain banks and runtime condition palettes were designed as modular layers Layout progression set MAP1 to MAP8, RACE*, JUMP*, BONUS*, DESERT*, POOL*, CHIKA-* Stage flow was assembled as progression plus branch modules on the layout side Combat envelope set BOSS*, CHIKABOSS*, UFO*, CORE*, OBJ-BOMB*, BG-FORTRESS*, BG-ENEMYSHIP* Combat content reached object and background level, implying structured experimentation The sets are easiest to read as one combined statement: discipline naming strongly anchors the branch to Pilotwings-era content Mode 7 naming shows a reusable rendering and condition system flyman grouping shows staged mission composition rather than flat asset storage combat naming confirms broader design experimentation inside the same workspaceStem continuity testOne practical way to read these files is a stem-continuity check.If a stem appears across graphics, palette, and screen families, it likely represents an implemented content thread rather than a discarded name stub. Test type What to look for What it would imply Discipline stem continuity Same stem across CGX, COL, and SCR families Production-ready discipline package Environment stem continuity Same environment tokens in both fly and flyman Coordinated art-to-layout handoff Condition continuity Same M7-L-* state tokens across multiple mission banks Shared runtime condition system Combat stem continuity Combat tokens across object and background families Broader mission design envelope, not isolated experiments This is a useful checkpoint because it connects archive naming to probable in-engine behavior.flyman mission progression architectureThe flyman folder shows dense composition work organized by progression families.Core progression spine: Family Count Range Interpretation MAP1 4 screens MAP1-1 through MAP1-4 Lesson 1 progression with BAK backups for -1, -2, -4 MAP2 4 screens MAP2-1 through MAP2-4 Lesson 2 progression with backups for all four MAP3 1 screen MAP3-1 Lesson 3 (single screen, possible tutorial/test) MAP4 16 screens MAP4-1 through MAP4-16 (selective backups) Lesson 4 is most complex, densest iteration evidence MAP5 6 screens + variant MAP5-1 through MAP5-4, MAP5-2B, MAP5-4B Lesson 5 with explicit B-variants MAP6 37 screens MAP6-0 through MAP6-36 Lesson 6 is largest single progression (extensive variant/backup trail) MAP7 64 screens MAP7-1 through MAP7-64 Lesson 7 is massive - more screens than many entire games MAP8 8 screens MAP8-1 through MAP8-8 Lesson 8 conclusion Mission branch families (non-linear paths): Family Count Context Notes RACE1 4 screens RACE1-1 through RACE1-4 Racing discipline branch (backup trail on all) CHIKA 27+ screens Underground progression with A/B/C variant tracks Three parallel underground lanes JUMP 37 screens total Multiple jump-training lanes (JUMP1/2/3) with sub-variants Skill-focused branch BONUS Limited Optional content Speculative completion track DESERT, POOL, etc. Scattered Environment-specific variants Alternate environment contexts The cascade:MAP1 (4 lessons) → MAP2 (4) → MAP3 (1) → [split] ├→ MAP4-6 (main path, 57 screens) ├→ RACE1 (side race, 4 screens) ├→ CHIKA (underground branch, 27 screens) ├→ JUMP (jump training, 37 screens) └→ [environment variants] └→ MAP7 (64-screen mega progression) └→ MAP8 (finale, 8 screens)Data interpretation: MAP4 through MAP6 each hit double-digit screen counts, suggesting complex multistage missions rather than single-screen challenges. MAP7’s 64-screen count is extraordinary. This could represent: one massive free-roam course 64 individual challenge variations of the same mission a progression grid (8×8 or similar) of tiered difficulty/feature unlocks The presence of B-variants (MAP5-2B, MAP5-4B, CHIKA-B*, etc.) alongside main lanes suggests parallel design iteration - not just backups, but deliberate alternate routes tested in parallel. Heavy backup presence in MAP4 and MAP6 is evidence of sustained iteration, not final polish.This architecture is consistent with a flight-training game where: early lessons (MAP1-3) teach basics progressively mid-lessons (MAP4-6) build difficulty optional branches (RACE, CHIKA, JUMP) offer style variants MAP7 represents peak challenge or comprehensive integration MAP8 wraps up with finale contentThe filename evidence supports a compact mission assembly sequence:flowchart TD A[\"<b>Discipline and environment tiles</b><br>CGX banks in fly\"] --> B[\"<b>Condition palettes</b><br>M7-L weather/time variants\"] B --> C[\"<b>Stage composition</b><br>MAP and mission SCR families in flyman\"] C --> D[\"<b>HUD and meter overlays</b><br>M7-METER SCR layer\"] D --> E[\"<b>Final lesson scene</b><br>discipline mission runtime\"]This model is consistent with the extension split and token grammar already visible in the folders.Low-level decoding guide (without raw files)You can understand most of the technical structure in this workspace directly from naming and extension patterns. Artifact type Typical extension What it usually represents What to infer from this page Tile/character graphics banks CGX Packed visual tiles used by backgrounds and objects Mission surfaces and discipline visuals were authored as reusable banks Palette banks COL Color sets applied to tiles/objects at runtime Weather/time variants (FINE, RAIN, SNOW, NIGHT) were likely palette-driven state changes Screen/layout maps SCR Tile placement and composition layers flyman assembled mission scenes and HUD placement from upstream art banks Object-side resources OBJ and object-prefixed families Actor or interactive element-side content Combat and discipline naming appear at object level, not only background level Backup snapshots BAK Local saved variants during iteration Heavy backup presence supports active iteration rather than one-shot import The key practical model is that this archive preserves a layered SNES workflow: art banks define reusable visual pieces palettes define runtime mood and condition changes screen maps assemble final mission scenes object families attach actor and gameplay-side behavior cuesThat is enough to reconstruct a credible low-level production picture without opening the original binary files.Pilotwings-specific format findings beyond the generic SNES profileThe generic SNES format page explains what SCR, CGX, COL, and OBJ are across projects.Pilotwings adds branch-specific detail about how those formats were used in day-to-day production.SCR format behavior is extremely consistent across both foldersAll SCR files in both folders are exactly 8,960 bytes: fly: 78 of 78 files at 8,960 flyman: 286 of 286 files at 8,960That is strong evidence of one stable editor-side layout container shared across both art testing (fly) and mission composition (flyman).Pilotwings SCR files show multiple opening-pattern classesThe first 16-bit words split into a few recurring behaviors. Pattern class Example file Opening words Reading Zeroed template TEST-1A.SCR, MAP1-1.SCR 0x0000 repeated Empty or baseline canvas state Constant tile fill M7-METER.SCR, METERC00.SCR, RAIN1-1.SCR 0x0080 or 0x0030 or 0x0023 repeated Uniform prefill region or shared panel block Sequential table run MISSION.SCR 0x004F, 0x0050, 0x0051, 0x0052… Ordered tile/index table Mixed attribute entries PANEL.SCR 0x0092, 0x0093, 0x0000, 0x4093… Layout entries with variant/flag bits This gives a stronger practical model than just “SCR holds layout”: the format supports both blank templates and pre-seeded composition blocks under the same fixed container size.Variant pairs show two different editing stylesComparing close variant pairs reveals two distinct workflows. Pair First differing byte What it suggests MISSION.SCR vs MISSION-1.SCR 1 Immediate full-layout divergence METERC00.SCR vs METERC01.SCR 1 Separate meter layouts from the first entry onward RAIN1-1.SCR vs RAIN1-2.SCR 65 Shared header block before branch-specific edits POOL1-1.SCR vs POOL2-1.SCR 41 Early template reuse, then divergence TEST-1A.SCR vs TEST-1B.SCR 257 Strong shared base template with later modifications So Pilotwings does not use only one edit pattern.Some families are cloned early into separate branches, while others keep a shared front block and diverge later.File-type distribution also exposes a small layout-side helper bankUnlike a purely SCR folder, flyman keeps a tiny graphics and palette support set: BG.CGX MYSHIP.CGX OBJ.CGX 1.COLThis is useful format evidence: mission composition in Pilotwings was not strictly tilemap-only.The layout branch retained a minimal local graphics and palette payload for composition and preview work.Deep dive on under-documented format familiesThe two highest-value remaining format families are MET* and LICENSE*.Both families preserve cross-file evidence (SCR, CGX, COL) and clear variant behavior.MET family structure and variant behaviorThe MET* set is broader than the earlier meter discussion and appears to encode several HUD or mission-meter modes. Family slice Files Size pattern What it suggests Core meter layouts M7-METER.SCR, M7-METER-B.SCR, METER.SCR, METER-B.SCR all 8,960 Shared base meter grammar across two naming namespaces Course meter variants METERC00.SCR, METERC00-B.SCR, METERC01.SCR, METERC01-B.SCR all 8,960 Course-specific meter branches with A/B-style alternates Mode-specific meter layouts MET.SCR, MET-PARA.SCR all 8,960 Meter behavior tied to a specific discipline or mission mode Meter graphics banks MET.CGX, MET-B.CGX, MET-S.CGX all 34,048 Three graphics-bank variants feeding the meter layout side The opening words show four distinct meter-template classes: M7-METER and METER families open with repeated 0x0080 METERC00 family opens with repeated 0x0030 METERC01 family opens with repeated 0x002D before switching later MET/MET-PARA family opens with repeated 0x0029This means the meter system was not one template with small edits.It was a small cluster of related layout templates tuned for different course or discipline contexts.Pairwise diff evidence reinforces that reading: Pair First differing byte Reading M7-METER.SCR vs METER.SCR identical Same layout body survives under both names across folders M7-METER.SCR vs M7-METER-B.SCR 93 Small branch on top of shared base METER.SCR vs METER-B.SCR 93 Same branch point behavior as M7-METER pair METERC00.SCR vs METERC00-B.SCR 87 Late-ish divergence after shared prefix METERC01.SCR vs METERC01-B.SCR 93 Similar branch offset to meter B variants METERC00.SCR vs METERC01.SCR 1 Different course variant from first word onward MET.SCR vs MET-PARA.SCR 79 Shared front block with mode-specific edits afterward The practical implication is a two-layer meter pipeline: shared meter base templates for broad HUD structure per-course and per-discipline branches for mission-specific tuningLICENSE family and localization behaviorThe LICENSE* family is one of the clearest UI/localization format clusters in the branch. Family slice Files Size pattern What it suggests License screens LICENSE.SCR, LICENSE-ENG.SCR, LICENSE2.SCR, LICENSE2-ENG.SCR all 8,960 Two layout generations with English-localized pairs License graphics LICENSE.CGX, LICENSE-ENG.CGX both 34,048 Dedicated localized graphics banks, not only layout swaps License palette LICENSE.COL 1,024 Shared palette anchor for the license screen family All four SCR files begin with repeated 0x0CB2, which suggests a shared screen template skeleton.But they are not duplicates: Pair First differing byte Reading LICENSE.SCR vs LICENSE-ENG.SCR 777 English variant keeps long common prefix, then diverges LICENSE2.SCR vs LICENSE2-ENG.SCR 777 Same localization branch point in second layout generation LICENSE.SCR vs LICENSE2.SCR 407 Second generation diverges earlier than language variants LICENSE.CGX vs LICENSE-ENG.CGX 2,561 Localized graphics banks share large common prefix before diverging Revision depth is also visible in the graphics backups: LICENSE.CGX vs LICENSE.CGX.BAK first diff at byte 4,746 LICENSE-ENG.CGX vs LICENSE-ENG.CGX.BAK first diff at byte 10,259That combination suggests the family was maintained as a deliberate localization pipeline: common template base language-specific layout divergence at stable offsets dedicated localized graphics banks with their own revision historyThis is stronger than a one-off translated screen and looks like a proper reusable front-end localization workflow.Timestamp forensicsDate behavior in NEWS_04 needs caution. Date Observation Confidence 1989-10-13 Both folders start the same day High confidence shared origin 1991-05-07 flyman closure is tight and plausible High confidence operational endpoint 1994-03-18 fly has late timestamp tail Medium confidence as restore-touch artifact Why this matters: If 1994-03-18 is mostly restore-touch behavior, true active design likely ended much earlier. If some files were genuinely accessed or revised at restore time, late timestamps may represent archival edits, not gameplay-system iteration.Competing hypotheses and confidenceThe table below lists the relevant entries. Hypothesis Description Confidence Pilotwings production branch with expanded combat envelope Branch includes shipped-style helicopter combat plus additional combat families and scenario variants High Parallel unreleased flight-combat project Shared tool/art vocabulary with possible side experiments beyond shipped mission framing Medium Mixed folder contamination Different project assets merged into one branch by workstation hygiene Low-to-medium Current best fit remains the first hypothesis, with the second still plausible.Synthesis: what the data tells usNow that we have examined actual file evidence in depth, several conclusions are stronger than before:Curriculum structure: The presence of a 64-file TEST grid (created in a single batch on day 1) plus the MAP1-8 + branches system in flyman points to deliberate curriculum design. This was not improvisation; it was planned lesson progression.Environmental branching: The symmetric structure of CHIKA across both folders (palette states in fly, layout progression in flyman, dedicated object-level boss graphics) proves that underground missions were a full content branch, not stray test content.Modular rendering: Nine weather/condition palettes (FINE, RAIN, SNOW, SUNSET, NIGHT, DESERT, GRASS, ISLAND) each with backup pairs shows runtime state-switching was a design principle, not an afterthought. Every mission could change mood.Course variety: The C0/C00/C01 course triplet, each with multiple palette variants, suggests at least 3-4 distinct aerial courses with selectable weather. This aligns with Pilotwings’ known course roster but possibly implies more variety in design than the final game shipped.Combat integration: The presence of: BOSS-1/2/3 boss progression CHIKABOSS underground-specific boss UFO enemy craft CORE target objects OBJ-BOMB weapons BG-FORTRESS, BG-ENEMYSHIP, BG-BASESHIP combat backdrops…across object, palette, and background layers means combat was not a single experiment or discarded branch - it was integrated into the same mission assembly pipeline as the flight lessons. It reached object level and environment level, suggesting structured gameplay intent.Production velocity: Heavy backup presence in MAP4, MAP6, CHIKA-B*, JUMP* variants suggests these were actively iterated, not frozen designs. The workspace captures an in-flight development snapshot, not just a final asset dump.These are the main unresolved points that would most improve confidence if answered: Build a filename-frequency matrix for discipline and combat tokens, then compare by timestamp band. Cluster M7-* files by palette suffix and mission prefix to estimate state transitions. Cross-check BGBG-* and mission family prefixes against other Sugiyama branches for reuse patterns. Compare byte-level headers for key CGX, SCR, and COL variants to identify export/tool lineage. Compare ROKETMAN, HELI, and PLANE sprite dimensions against known Pilotwings ROM assets.Production pipeline reconstructionThe current file evidence supports a three-lane pipeline