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

50 lines
988 B
C++
Raw Normal View History

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
class Interface;
Update to release v000r04. byuu says: [screenshot of the Tetris title screen] Less than fourty-eight hours after starting on this. I guess you weren't kidding, Exophase.
2010-12-30 07:18:47 +00:00
enum class Input : unsigned {
Up, Down, Left, Right, B, A, Select, Start,
};
Update to v083r05 release. (r04 was not posted to the WIP thread) byuu says: NES: passes ppu_sprite_overflow tests 01, 02, 05. Game Boy: uses DMG BIOS (the one with the slow title scroll) or SGB BIOS, based upon how you load the game. Game Boy Color: Everything except the IR port is emulated. I don't have any plans to allow linking two instances of bsnes. And that's frankly never going to happen over netplay anyway, due to latency requirements of the serial/IR ports. The new DMA stuff is possibly incorrect, my test games don't seem to use it. Zelda: DX usually resets or crashes on the intro right before the beach scene. I'm not sure why. Skip the intro and the game plays fine. This is the best I can do when the most up-to-date GB/C reference document is over ten years old and half-assed (pandocs.) I could really use some help from anyone who understands the system. Probably the worst part of my emulation at the moment is the interrupt system. Lots of things real hardware doesn't allow (DMA outside HRAM, CGB DMA to invalid addresses, etc) isn't blocked yet. LCD renderer is still scanline-based, which is just terrible. Doesn't seem to be any good docs on cycle-level operation. I only know that it's incredibly pathological and variable.
2011-10-27 00:00:17 +00:00
struct System : property<System> {
enum class Revision : unsigned {
GameBoy,
SuperGameBoy,
GameBoyColor,
};
readonly<Revision> revision;
inline bool dmg() const { return revision == Revision::GameBoy; }
inline bool sgb() const { return revision == Revision::SuperGameBoy; }
inline bool cgb() const { return revision == Revision::GameBoyColor; }
Update to release v000r10. byuu says: Changelog: - fixed LYC interrupt at LY=0 (fixes Makai Toushi SaGa) - fixed MBC3 ROM bank mapping (fixes Harvest Moon GBC) - added Super Game Boy MLT_REQ support to JOYP, needed for ICD2-R emulation - temporarily changed System::run() to execute only four cycles before exiting for bsnes, will make two versions later - uses actual boot ROMs, has DMG+SGB1 for now. Need SGB2, don't care about CGB. Defaults to SGB1, no way to select just yet. DMG 4-second wait is annoying. Does not force games to act like SGB on bgameboy itself, because that has no ICD2 and fails the required MLT_REQ check
2011-01-06 10:16:07 +00:00
struct BootROM {
Update to v087r28 release. byuu says: Be sure to run make install, and move required images to their appropriate system profile folders. I still have no warnings in place if those images aren't present. Changelog: - OBJ mosaic should hopefully be emulated correctly now (thanks to krom and Cydrak for testing the hardware behavior) - emulated dummy serial registers, fixes Sonic Advance (you may still need to specify 512KB FlashROM with an appropriate ID, I used Panaonic's) - GBA core exits scheduler (PPU thread) and calls interface->videoRefresh() from main thread (not required, just nice) - SRAM, FRAM, EEPROM and FlashROM initialized to 0xFF if it does not exist (probably not needed, but FlashROM likes to reset to 0xFF anyway) - GBA manifest.xml for file-mode will now use "gamename.xml" instead of "gamename.gba.xml" - started renaming "NES" to "Famicom" and "SNES" to "Super Famicom" in the GUI (may or may not change source code in the long-term) - removed target-libsnes/ - added profile/ Profiles are the major new feature. So far we have: Famicom.sys/{nothing (yet?)} Super Famicom.sys/{ipl.rom} Game Boy.sys/{boot.rom} Game Boy Color.sys/{boot.rom} Game Boy Advance.sys/{bios.rom[not included]} Super Game Boy.sfc/{boot.rom,program.rom[not included]} BS-X Satellaview.sfc/{program.rom,bsx.ram,bsx.pram} Sufami Turbo.sfc/{program.rom} The SGB, BSX and ST cartridges ask you to load GB, BS or ST cartridges directly now. No slot loader for them. So the obvious downsides: you can't quickly pick between different SGB BIOSes, but why would you want to? Just use SGB2/JP. It's still possible, so I'll sacrifice a little complexity for a rare case to make it a lot easier for the more common case. ST cartridges currently won't let you load the secondary slot. BS-X Town cart is the only useful game to load with nothing in the slot, but only barely, since games are all seeded on flash and not on PSRAM images. We can revisit a way to boot the BIOS directly if and when we get the satellite uplink emulated and data can be downloaded onto the PSRAM :P BS-X slotted cartridges still require the secondary slot. My plan for BS-X slotted cartridges is to require a manifest.xml to specify that it has the BS-X slot present. Otherwise, we have to load the ROM into the SNES cartridge class, and parse its header before we can find out if it has one. Screw that. If it's in the XML, I can tell before loading the ROM if I need to present you with an optional slot loading dialog. I will probably do something similar for Sufami Turbo. Not all games even work with a secondary slot, so why ask you to load a second slot for them? Let the XML request a second slot. A complete Sufami Turbo ROM set will be trivial anyway. Not sure how I want to do the sub dialog yet. We want basic file loading, but we don't want it to look like the dialog 'didn't do anything' if it pops back open immediately again. Maybe change the background color of the dialog to a darker gray? Tacky, but it'd give you the visual cue without the need for some subtle text changes.
2012-04-18 13:58:04 +00:00
uint8 dmg[ 256];
uint8 sgb[ 256];
uint8 cgb[2048];
Update to release v000r10. byuu says: Changelog: - fixed LYC interrupt at LY=0 (fixes Makai Toushi SaGa) - fixed MBC3 ROM bank mapping (fixes Harvest Moon GBC) - added Super Game Boy MLT_REQ support to JOYP, needed for ICD2-R emulation - temporarily changed System::run() to execute only four cycles before exiting for bsnes, will make two versions later - uses actual boot ROMs, has DMG+SGB1 for now. Need SGB2, don't care about CGB. Defaults to SGB1, no way to select just yet. DMG 4-second wait is annoying. Does not force games to act like SGB on bgameboy itself, because that has no ICD2 and fails the required MLT_REQ check
2011-01-06 10:16:07 +00:00
} bootROM;
Update to release v000r11. byuu says: Changelog: - adds XML memory mapping to cartridge loading; nall/gameboy/cartridge.hpp will bullshit one for now - still need to add proper MMM01 detection (menu code goes at end of ROM apparently) - added save state support, which works here (but not inside bsnes, go figure), to aid in debugging. Expect constant changes for now a long while, it's way too early to add states
2011-01-07 11:11:56 +00:00
void run();
void runtosave();
void runthreadtosave();
Update to v082r13 release. byuu says: I've updated the {System}::Interface classes to encapsulate all common functionality, so they are C++ equivalents of libsnes now. The idea being, use the interface class and you'll never have to reach into core objects (unless you really want to.) Not guaranteeing as stable an API as I do with libsnes for that, though. C++ doesn't make for nice dynamic libraries, anyway. Added back the state manager, and it now works for both SNES and Game Boy. NES save states aren't in yet. Anyway, this should give you a pretty good feel for what the combined UI is going to be like: same as before, everything works the same. Only difference is the dynamic system menu and cartridge menu with more load options. The settings window will be mostly the same as well, but will obviously have options that only apply to some systems.
2011-09-15 12:41:49 +00:00
void init();
Update to v083r05 release. (r04 was not posted to the WIP thread) byuu says: NES: passes ppu_sprite_overflow tests 01, 02, 05. Game Boy: uses DMG BIOS (the one with the slow title scroll) or SGB BIOS, based upon how you load the game. Game Boy Color: Everything except the IR port is emulated. I don't have any plans to allow linking two instances of bsnes. And that's frankly never going to happen over netplay anyway, due to latency requirements of the serial/IR ports. The new DMA stuff is possibly incorrect, my test games don't seem to use it. Zelda: DX usually resets or crashes on the intro right before the beach scene. I'm not sure why. Skip the intro and the game plays fine. This is the best I can do when the most up-to-date GB/C reference document is over ten years old and half-assed (pandocs.) I could really use some help from anyone who understands the system. Probably the worst part of my emulation at the moment is the interrupt system. Lots of things real hardware doesn't allow (DMA outside HRAM, CGB DMA to invalid addresses, etc) isn't blocked yet. LCD renderer is still scanline-based, which is just terrible. Doesn't seem to be any good docs on cycle-level operation. I only know that it's incredibly pathological and variable.
2011-10-27 00:00:17 +00:00
void load(Revision);
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
void power();
Update to release v000r10. byuu says: Changelog: - fixed LYC interrupt at LY=0 (fixes Makai Toushi SaGa) - fixed MBC3 ROM bank mapping (fixes Harvest Moon GBC) - added Super Game Boy MLT_REQ support to JOYP, needed for ICD2-R emulation - temporarily changed System::run() to execute only four cycles before exiting for bsnes, will make two versions later - uses actual boot ROMs, has DMG+SGB1 for now. Need SGB2, don't care about CGB. Defaults to SGB1, no way to select just yet. DMG 4-second wait is annoying. Does not force games to act like SGB on bgameboy itself, because that has no ICD2 and fails the required MLT_REQ check
2011-01-06 10:16:07 +00:00
unsigned clocks_executed;
Update to release v000r11. byuu says: Changelog: - adds XML memory mapping to cartridge loading; nall/gameboy/cartridge.hpp will bullshit one for now - still need to add proper MMM01 detection (menu code goes at end of ROM apparently) - added save state support, which works here (but not inside bsnes, go figure), to aid in debugging. Expect constant changes for now a long while, it's way too early to add states
2011-01-07 11:11:56 +00:00
//serialization.cpp
unsigned serialize_size;
serializer serialize();
bool unserialize(serializer&);
void serialize(serializer&);
void serialize_all(serializer&);
void serialize_init();
Update to v087r28 release. byuu says: Be sure to run make install, and move required images to their appropriate system profile folders. I still have no warnings in place if those images aren't present. Changelog: - OBJ mosaic should hopefully be emulated correctly now (thanks to krom and Cydrak for testing the hardware behavior) - emulated dummy serial registers, fixes Sonic Advance (you may still need to specify 512KB FlashROM with an appropriate ID, I used Panaonic's) - GBA core exits scheduler (PPU thread) and calls interface->videoRefresh() from main thread (not required, just nice) - SRAM, FRAM, EEPROM and FlashROM initialized to 0xFF if it does not exist (probably not needed, but FlashROM likes to reset to 0xFF anyway) - GBA manifest.xml for file-mode will now use "gamename.xml" instead of "gamename.gba.xml" - started renaming "NES" to "Famicom" and "SNES" to "Super Famicom" in the GUI (may or may not change source code in the long-term) - removed target-libsnes/ - added profile/ Profiles are the major new feature. So far we have: Famicom.sys/{nothing (yet?)} Super Famicom.sys/{ipl.rom} Game Boy.sys/{boot.rom} Game Boy Color.sys/{boot.rom} Game Boy Advance.sys/{bios.rom[not included]} Super Game Boy.sfc/{boot.rom,program.rom[not included]} BS-X Satellaview.sfc/{program.rom,bsx.ram,bsx.pram} Sufami Turbo.sfc/{program.rom} The SGB, BSX and ST cartridges ask you to load GB, BS or ST cartridges directly now. No slot loader for them. So the obvious downsides: you can't quickly pick between different SGB BIOSes, but why would you want to? Just use SGB2/JP. It's still possible, so I'll sacrifice a little complexity for a rare case to make it a lot easier for the more common case. ST cartridges currently won't let you load the secondary slot. BS-X Town cart is the only useful game to load with nothing in the slot, but only barely, since games are all seeded on flash and not on PSRAM images. We can revisit a way to boot the BIOS directly if and when we get the satellite uplink emulated and data can be downloaded onto the PSRAM :P BS-X slotted cartridges still require the secondary slot. My plan for BS-X slotted cartridges is to require a manifest.xml to specify that it has the BS-X slot present. Otherwise, we have to load the ROM into the SNES cartridge class, and parse its header before we can find out if it has one. Screw that. If it's in the XML, I can tell before loading the ROM if I need to present you with an optional slot loading dialog. I will probably do something similar for Sufami Turbo. Not all games even work with a secondary slot, so why ask you to load a second slot for them? Let the XML request a second slot. A complete Sufami Turbo ROM set will be trivial anyway. Not sure how I want to do the sub dialog yet. We want basic file loading, but we don't want it to look like the dialog 'didn't do anything' if it pops back open immediately again. Maybe change the background color of the dialog to a darker gray? Tacky, but it'd give you the visual cue without the need for some subtle text changes.
2012-04-18 13:58:04 +00:00
System();
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 v087r04 release. byuu says: Changelog: - gameboy/ -> gb/ - GameBoy -> GB - basic memory map for GBA - enough code to execute the first BIOS instruction (b 0x68) I have the code resetting r(15) to 0 on an exception just as a test. Since that flushes the pipeline, that means we're basically executing "b 0x68" at 8MHz, and nothing else. ... and I am getting __6 motherfucking FPS__ at 4.4GHz on an i7. Something is seriously, horribly, unfuckingbelievably wrong here, and I can't figure out what it is. My *fully complete* ARM core on the ST018 is even less efficient and runs at 21.47MHz, and yet I get 60fps even after emulating the SNES CPU+PPU @ 10+MHz each as well. ... I'm stuck. I can't proceed until we figure out what in the holy fuck is going on here. So ... if anyone can help, please do. If we can't fix this, the GBA emulation is dead. I was able to profile on Windows, and I've included that in this WIP under out/log.txt. But it looks normal to me. But yeah, there's NO. FUCKING. WAY. This code should be running this slowly.
2012-03-18 12:35:53 +00:00
#include <gb/interface/interface.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
extern System system;