ShuriZma
/
bsnes
mirror of https://github.com/bsnes-emu/bsnes.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
bsnes/higan/sfc/alt/ppu-balanced/memory/memory.hpp

11 lines
276 B
C++
Raw Normal View History

First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
uint16 get_vram_address();
Update to v085r04 release. byuu says: Changelog: - added base/ folder - base/base.hpp defines the version number for all UI targets, all the varint-types, and a hook() class for debugger functions (see below) - fixed compatibility profile compilation - removed within<> template from the SNES target - the SNES core can be built without Game Boy support now, if you so choose (my SNES debugger is not going to support debugging the GBZ80, sorry.) - added ui-debugger; not at all useful right now, will be a long while to get something usable ready So hook is a class wrapper around nall::function. It allows you to invoke potentially empty functions (and as such, the return type must have a trivial constructor.) It also doesn't actually perform the test+invocation when DEBUGGER (options=debugger) is not defined. So you should have no overhead in regular builds. The core classes now have a subclass with all the debugging hooks, so you'll see eg: void CPU::op_step() { debugger.op_exec(regs.pc); (this->*opcode_table[op_read()])(); } Clear what it's doing, clear what it's for. A whole lot less work than inheriting the whole CPU core and virtualizing the functions we want to hook. All the logic for what to do inside these callbacks will be handled by individual debuggers, so they can have all the functionality they want.
2012-02-06 12:03:45 +00:00
uint8 vram_mmio_read(uint16 addr);
void vram_mmio_write(uint16 addr, uint8 data);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v085r04 release. byuu says: Changelog: - added base/ folder - base/base.hpp defines the version number for all UI targets, all the varint-types, and a hook() class for debugger functions (see below) - fixed compatibility profile compilation - removed within<> template from the SNES target - the SNES core can be built without Game Boy support now, if you so choose (my SNES debugger is not going to support debugging the GBZ80, sorry.) - added ui-debugger; not at all useful right now, will be a long while to get something usable ready So hook is a class wrapper around nall::function. It allows you to invoke potentially empty functions (and as such, the return type must have a trivial constructor.) It also doesn't actually perform the test+invocation when DEBUGGER (options=debugger) is not defined. So you should have no overhead in regular builds. The core classes now have a subclass with all the debugging hooks, so you'll see eg: void CPU::op_step() { debugger.op_exec(regs.pc); (this->*opcode_table[op_read()])(); } Clear what it's doing, clear what it's for. A whole lot less work than inheriting the whole CPU core and virtualizing the functions we want to hook. All the logic for what to do inside these callbacks will be handled by individual debuggers, so they can have all the functionality they want.
2012-02-06 12:03:45 +00:00
uint8 oam_mmio_read(uint16 addr);
void oam_mmio_write(uint16 addr, uint8 data);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v085r04 release. byuu says: Changelog: - added base/ folder - base/base.hpp defines the version number for all UI targets, all the varint-types, and a hook() class for debugger functions (see below) - fixed compatibility profile compilation - removed within<> template from the SNES target - the SNES core can be built without Game Boy support now, if you so choose (my SNES debugger is not going to support debugging the GBZ80, sorry.) - added ui-debugger; not at all useful right now, will be a long while to get something usable ready So hook is a class wrapper around nall::function. It allows you to invoke potentially empty functions (and as such, the return type must have a trivial constructor.) It also doesn't actually perform the test+invocation when DEBUGGER (options=debugger) is not defined. So you should have no overhead in regular builds. The core classes now have a subclass with all the debugging hooks, so you'll see eg: void CPU::op_step() { debugger.op_exec(regs.pc); (this->*opcode_table[op_read()])(); } Clear what it's doing, clear what it's for. A whole lot less work than inheriting the whole CPU core and virtualizing the functions we want to hook. All the logic for what to do inside these callbacks will be handled by individual debuggers, so they can have all the functionality they want.
2012-02-06 12:03:45 +00:00
uint8 cgram_mmio_read(uint16 addr);
void cgram_mmio_write(uint16 addr, uint8 data);