Thinking about how to develop PalmBoy I tried my good old Atari ST. After successfully porting the necessary tools (PilRC, Pila, and some of PLink) to TOS that way was right for me. The core development was done with STemBoy - just the user interface and support functions have to be done separately. STemBoy means "ST emulates GameBoy."
STemboy is put under the GNU General Public License.
The version V3.2 of STemBoy is made running Pure-C in STonX, the ST emulator on X. This version introduced support for color screens and the cursor keys for the direction pad.
Matthias Jaap took my sources and went on. Please visit his STemBoy page for more information. I have to thank him for his great work!
stemboy.zip Archive with executable, no games, 88KB.
stemboys.zip Archive with source and executable, no games, 170KB.
OK, this picture is a montage of a snapshot and the ressource image... On the monochrome SM124 the emulator shows these light and dark gray shades by switching the window contents. And yes, that flickers a LOT!
Currently STemBoy runs only on stock and emulated STs. I had some reports that it runs on STEs, too, and that it crashes on TTs. If you don't use monochrome screens, it uses the color screen by VDI calls. The latter is really slow...
After my good old Atari ST broke down, I'm now using STonX on my Linux box. Equipped with a 700 MHz Duron the emulated Gameboy runs at full speed or faster, depending on the screen mode. I tried TOSBOX (ST emulator for DOS) running on dosemu, and it works, too. PaCifiST doesn't run on dosemu, but on "real" DOS it's first choice.
Monochrome screens: When the emulator is stopped, the standard GEM interface is active. At this time the gray shades in the Gameboy screen are created by copying alternately one of two buffers. This leads to heavy flicker with the standard VDI. I recommend to use NVDI or other products to speed this up, but you'll never get the screen smooth. When the emulator runs, the two screen buffers are copied by optimized machine code in the vertical blank interrupt. This is the fastest and easiest method to do. The flicker stays because the screen rate is still low at 71 Hz / 3 = 24 Hz.
Color screens: To get things faster, I change four of the standard VDI colors. This works fine in 4-color-mode and 16-color-mode, I didn't try other modes. STemBoy looks and works great in 960 x 640 in 16 colors on STonX, and runs like hell!
There are four different emulations: a pure one (which can be exported to be used for PalmBoy), one with more runtime checks, one with checks and opcode profiling, and one like the profiling one but with single stepping. Each time you select one of these - even if it's already selected - the emulation will be reset. This is BTW the only method to reset aside from loading a cartridge!
The windows for profiling results and emulation messages are closed by default. They give most advantages when starting the single stepping emulation by "Animate." Their contents are created in any case (if appropriate) so you can speed up the animated single stepping if you close the windows.
You can try small sequences of opcodes. After confirming the entry the emulation is reset and the registers are loaded with special values. This is intended to check the emulation of the Gameboy CPU itself.
To set breakpoints you may define upto ten addresses in the Gameboy ROM space which will be overwritten with the unused opcode 0DBH ("de break"). Reaching one of those points and fetching this byte as opcode the emulation will stop in any mode.
Back to my home page.
Comments and such stuff go to: [email protected]