ShuriZma
/
bsnes
mirror of https://github.com/bsnes-emu/bsnes.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
bsnes/gameboy/system/system.cpp

25 lines
319 B
C++
Raw Normal View History

Update to release v000r07. byuu says: Changelog: - fixed sprite Vflip check - fixed up window rendering (well, mostly, works great in Megaman II but not so great in Makaitoushi SaGa) - added MBC2, MBC5 (already had MBC0, MBC1) - removed reset, hooked up power cycle and Vsync toggle - some other stuff Makaitoushi SaGa locks on the main menu after some graphical glitches on the title screen, damn. Shin Megami Tensei - Devichil Black Book locks up immediately, hitting HALT opcodes all the time, damn again. Megaman II should be fully playable now. Contra 3 is really close, but goes crazy on the turtle boss fight.
2011-01-03 04:28:36 +00:00
#include <gameboy/gameboy.hpp>
Initial commit of bgameboy v000. The source tarball also included empty obj/ and out/ directories which git does not support. byuu says: Project started, so basically everything is new. It's basically a rough skeleton that mimics bsnes project structure. Eventually the src/gameboy folder will be copied into bsnes-official and used by the chip/supergameboy core. The middleware layer (supergameboy/interface) will be merged into a new chip/icd2 folder that will represent direct Super Game Boy emulation in the future. At least, if all goes according to plan. There is a simple GUI that can load ROMs, but do nothing after it. It's not hooked up to ruby yet. There is a basic system class and interface to expose the video/audio/input functions. There is a basic memory bus that doesn't support any MBCs yet. There is a CPU skeleton that only handles easy read/write access to the CPU registers (AF is a really fucked up register.) The core is not hooked up to libco yet, but I intend for it to be, so that I can run the CPU + LCD how I like. If it turns out the LCD+audio is easily enslavable, then I'll probably drop libco and just run it like a regular emulator, using a thread wrapper around it in bsnes only. We'll see. The CPU doesn't actually support any opcodes, and loading a ROM won't actually execute anything.
2010-12-28 01:53:15 +00:00
#define SYSTEM_CPP
namespace GameBoy {
System system;
void System::init(Interface *interface_) {
interface = interface_;
}
void System::power() {
Update to release v000r02. byuu says: 314 of 512 opcodes implemented, can execute the first 67,450 instructions of Tetris. I also added an MMIO bus, ala bsnes, so that I can map and access individual registers with a single indirection.
2010-12-29 11:03:42 +00:00
bus.power();
cartridge.power();
Initial commit of bgameboy v000. The source tarball also included empty obj/ and out/ directories which git does not support. byuu says: Project started, so basically everything is new. It's basically a rough skeleton that mimics bsnes project structure. Eventually the src/gameboy folder will be copied into bsnes-official and used by the chip/supergameboy core. The middleware layer (supergameboy/interface) will be merged into a new chip/icd2 folder that will represent direct Super Game Boy emulation in the future. At least, if all goes according to plan. There is a simple GUI that can load ROMs, but do nothing after it. It's not hooked up to ruby yet. There is a basic system class and interface to expose the video/audio/input functions. There is a basic memory bus that doesn't support any MBCs yet. There is a CPU skeleton that only handles easy read/write access to the CPU registers (AF is a really fucked up register.) The core is not hooked up to libco yet, but I intend for it to be, so that I can run the CPU + LCD how I like. If it turns out the LCD+audio is easily enslavable, then I'll probably drop libco and just run it like a regular emulator, using a thread wrapper around it in bsnes only. We'll see. The CPU doesn't actually support any opcodes, and loading a ROM won't actually execute anything.
2010-12-28 01:53:15 +00:00
cpu.power();
Update to release v000r02. byuu says: 314 of 512 opcodes implemented, can execute the first 67,450 instructions of Tetris. I also added an MMIO bus, ala bsnes, so that I can map and access individual registers with a single indirection.
2010-12-29 11:03:42 +00:00
lcd.power();
Update to release v000r01. byuu says: Hooked up a scheduler to enter/exit the CPU core wherever I want. Added basic 4*1024*1024hz clock, and about eleven or so opcodes. Creating the disassembler as I encounter each new opcode, not skipping ahead to do all 'like other' opcodes, eg if I add 'dec b', I don't then add 'dec c' until I encounter it.
2010-12-28 06:03:02 +00:00
scheduler.init();
Initial commit of bgameboy v000. The source tarball also included empty obj/ and out/ directories which git does not support. byuu says: Project started, so basically everything is new. It's basically a rough skeleton that mimics bsnes project structure. Eventually the src/gameboy folder will be copied into bsnes-official and used by the chip/supergameboy core. The middleware layer (supergameboy/interface) will be merged into a new chip/icd2 folder that will represent direct Super Game Boy emulation in the future. At least, if all goes according to plan. There is a simple GUI that can load ROMs, but do nothing after it. It's not hooked up to ruby yet. There is a basic system class and interface to expose the video/audio/input functions. There is a basic memory bus that doesn't support any MBCs yet. There is a CPU skeleton that only handles easy read/write access to the CPU registers (AF is a really fucked up register.) The core is not hooked up to libco yet, but I intend for it to be, so that I can run the CPU + LCD how I like. If it turns out the LCD+audio is easily enslavable, then I'll probably drop libco and just run it like a regular emulator, using a thread wrapper around it in bsnes only. We'll see. The CPU doesn't actually support any opcodes, and loading a ROM won't actually execute anything.
2010-12-28 01:53:15 +00:00
}
Update to release v000r01. byuu says: Hooked up a scheduler to enter/exit the CPU core wherever I want. Added basic 4*1024*1024hz clock, and about eleven or so opcodes. Creating the disassembler as I encounter each new opcode, not skipping ahead to do all 'like other' opcodes, eg if I add 'dec b', I don't then add 'dec c' until I encounter it.
2010-12-28 06:03:02 +00:00
void System::run() {
scheduler.enter();
Initial commit of bgameboy v000. The source tarball also included empty obj/ and out/ directories which git does not support. byuu says: Project started, so basically everything is new. It's basically a rough skeleton that mimics bsnes project structure. Eventually the src/gameboy folder will be copied into bsnes-official and used by the chip/supergameboy core. The middleware layer (supergameboy/interface) will be merged into a new chip/icd2 folder that will represent direct Super Game Boy emulation in the future. At least, if all goes according to plan. There is a simple GUI that can load ROMs, but do nothing after it. It's not hooked up to ruby yet. There is a basic system class and interface to expose the video/audio/input functions. There is a basic memory bus that doesn't support any MBCs yet. There is a CPU skeleton that only handles easy read/write access to the CPU registers (AF is a really fucked up register.) The core is not hooked up to libco yet, but I intend for it to be, so that I can run the CPU + LCD how I like. If it turns out the LCD+audio is easily enslavable, then I'll probably drop libco and just run it like a regular emulator, using a thread wrapper around it in bsnes only. We'll see. The CPU doesn't actually support any opcodes, and loading a ROM won't actually execute anything.
2010-12-28 01:53:15 +00:00
}
}