In this post we will resume our study of the interrupt system. Recall from our post Emulating The Core, Part 2: Interrupts and Timing that we studied the foundations of interrupt systems and showed how RealBoy manages to implement the interrupt system specific to the Game Boy. However, we didn’t have a chance to actually process an interrupt because at such an early stage of emulation we didn’t have any interrupt request from any device. Therefore we limited our study to showing how RealBoy checks for interrupt requests from all the possible sources of interruption. We will now show a particular, real-world example of an interrupt being requested and subsequently processed. (Be sure to take a look at our post Emulating The Core, Part 2: Interrupts and Timing in order to fully understand this one. For this activity we will also make use of GDDB, RealBoy’s internal debugger, so make sure you also take a look at A Small Exercise: Presenting GDDB).
One special feature presented by RealBoy is an interactive debugger called GDDB. This debugger lets you execute a particular code in a controller manner; it effectively lets you debug it. With GDDB you can, among other things, set breakpoints at specific addresses; print very useful information at any point, including the value of the various Game Boy registers, or even the value of an arbitrary memory address, etc. We will use these facilities to help us with a small exercise: We will see one way in which games wait for the appropriate moment to access the Video RAM (VRAM). This is extremely important because accessing VRAM can only be done at precise timings, and Nintendo even rejected games that did not respect this rule.
After having emulated and studied the first part of ‘the core’, we now study in detail the second part of what is found in every computer system emulator. This happens immediately after executing every instruction: First, we must check if any interrupt has occurred. Second, we must take into account the duration of the instruction just executed, and update the machine’s status accordingly. After studying this ubiquitous part of the emulator, we will have a firm understanding of the basics of emulating (via interpretation) a computer system. Of course, for an emulator to be usable this isn’t enough; many more things, some of them not directly related to emulation (for example the user interface), must be done in order to have a complete and functional emulator.
In previous posts we have attempted to give an integral overview of the Nintendo Game Boy console. We have discussed considerably its various subsystems and tried to show how they interact to make the whole Game Boy experience possible. We have, additionally, studied the Game Boy’s bootstrap ROM; a 256 byte program responsible for starting up the console upon power on. With this background, therefore, we have gained knowledge about the way the Game Boy behaves, and how it get things done. It is about time to begin with the actual emulation of the Nintendo Game Boy system.
THE WAY THE GAME BOY BOOTS
Let us study the Game Boy’s bootstrap. Every time the console is turned on, this special, 256-byte program, is mapped to the beginning of the Game Boy’s Address Space, the Program Counter Register (‘PC’) is set to 0x0000 and the ‘real stuff’ begins.
Booting the Game Boy with the RealBoy Emulator
Having reviewed the Game Boy’s hybrid CPU, it’s time to take a look at the rest of the hardware that compose this beautiful console, and that we have to emulate. The CPU, though arguably the most important part of the whole system, would undoubtedly be plain useless if not played along with the rest of the symphony.
THE CHIP BEHIND THE NINTENDO GAME BOY: THE SHARP LR35902
Having looked at the foundations for the Game Boy’s hybrid CPU, let us see just what did and what didn’t make it from the Intel 8080 and the Zilog Z80 into the SHARP LR35902.
The Game Boy’s CPU is a hybrid between the Intel 8080 and the Zilog Z80. In this post we’ll investigate the foundations of this custom microprocessor.