bsnes/higan/md/controller/controller.hpp

35 lines
764 B
C++
Raw Normal View History

Update to v101r12 release. byuu says: Changelog: - new md/bus/ module for bus reads/writes - abstracts byte/word accesses wherever possible (everything but RAM; forces all but I/O to word, I/O to byte) - holds the system RAM since that's technically not part of the CPU anyway - added md/controller and md/system/peripherals - added emulation of gamepads - added stub PSG audio output (silent) to cap the framerate at 60fps with audio sync enabled - fixed VSRAM reads for plane vertical scrolling (two bugs here: add instead of sub; interlave plane A/B) - mask nametable read offsets (can't exceed 8192-byte nametables apparently) - emulated VRAM/VSRAM/CRAM reads from VDP data port - fixed sprite width/height size calculations - added partial emulation of 40-tile per scanline limitation (enough to fix Sonic's title screen) - fixed off-by-one sprite range testing - fixed sprite tile indexing - Vblank happens at Y=224 with overscan disabled - unsure what happens when you toggle it between Y=224 and Y=240 ... probably bad things - fixed reading of address register for ADDA, CMPA, SUBA - fixed sign extension for MOVEA effect address reads - updated MOVEM to increment the read addresses (but not writeback) for (aN) mode With all of that out of the way, we finally have Sonic the Hedgehog (fully?) playable. I played to stage 1-2 and through the special stage, at least. EDIT: yeah, we probably need HIRQs for Labyrinth Zone. Not much else works, of course. Most games hang waiting on the Z80, and those that don't (like Altered Beast) are still royally screwed. Tons of features still missing; including all of the Z80/PSG/YM2612. A note on the perihperals this time around: the Mega Drive EXT port is basically identical to the regular controller ports. So unlike with the Famicom and Super Famicom, I'm inheriting the exension port from the controller class.
2016-08-21 22:11:24 +00:00
struct Controller : Thread {
Controller(uint port);
virtual ~Controller();
static auto Enter() -> void;
Update to v103r24 release. byuu says: Changelog: - gb/mbc6: mapper is now functional, but Net de Get has some text corruption¹ - gb/mbc7: mapper is now functional² - gb/cpu: HDMA syncs other components after each byte transfer now - gb/ppu: LY,LX forced to zero when LCDC.d7 is lowered (eg disabled), not when it's raised (eg enabled) - gb/ppu: the LCD does not run at all when LCDC.d7 is clear³ - fixes graphical corruption between scene transitions in Legend of Zelda - Oracle of Ages - thanks to Cydrak, Shonumi, gekkio for their input on the cause of this issue - md/controller: renamed "Gamepad" to "Control Pad" per official terminology - md/controller: added "Fighting Pad" (6-button controller) emulation [hex\_usr] - processor/m68k: fixed TAS to set data.d7 when EA.mode==DataRegisterDirect; fixes Asterix - hiro/windows: removed carriage returns from mouse.cpp and desktop.cpp - ruby/audio/alsa: added device driver selection [SuperMikeMan] - ruby/audio/ao: set format.matrix=nullptr to prevent a crash on some systems [SuperMikeMan] - ruby/video/cgl: rename term() to terminate() to fix a crash on macOS [Sintendo] ¹: The observation that this mapper split $4000-7fff into two banks came from MAME's implementation. But their implementation was quite broken and incomplete, so I didn't actually use any of it. The observation that this mapper split $a000-bfff into two banks came from Tauwasser, and I did directly use that information, plus the knowledge that $0400/$0800 are the RAM bank select registers. The text corruption is due to a race condition with timing. The game is transferring font letters via HDMA, but the game code ends up setting the bank# with the font a bit too late after the HDMA has already occurred. I'm not sure how to fix this ... as a whole, I assumed my Game Boy timing was pretty good, but apparently it's not that good. ²: The entire design of this mapper comes from endrift's notes. endrift gets full credit for higan being able to emulate this mapper. Note that the accelerometer implementation is still not tested, and probably won't work right until I tweak the sensitivity a lot. ³: So the fun part of this is ... it breaks the strict 60fps rate of the Game Boy. This was always inevitable: certain timing conditions can stretch frames, too. But this is pretty much an absolute deal breaker for something like Vsync timing. This pretty much requires adaptive sync to run well without audio stuttering during the transition. There's currently one very important detail missing: when the LCD is turned off, presumably the image on the screen fades to white. I do not know how long this process takes, or how to really go about emulating it. Right now as an incomplete patch, I'm simply leaving the last displayed image on the screen until the LCD is turned on again. But I will have to output white, as well as add code to break out of the emulation loop periodically when the LCD is left off eg indefinitely, or bad things would happen. I'll work something out and then implement. Another detail is I'm not sure how long it takes for the LCD to start rendering again once enabled. Right now, it's immediate. I've heard it's as long as 1/60th of a second, but that really seems incredibly excessive? I'd like to know at least a reasonably well-supported estimate before I implement that.
2017-08-01 11:41:27 +00:00
virtual auto main() -> void;
Update to v101r12 release. byuu says: Changelog: - new md/bus/ module for bus reads/writes - abstracts byte/word accesses wherever possible (everything but RAM; forces all but I/O to word, I/O to byte) - holds the system RAM since that's technically not part of the CPU anyway - added md/controller and md/system/peripherals - added emulation of gamepads - added stub PSG audio output (silent) to cap the framerate at 60fps with audio sync enabled - fixed VSRAM reads for plane vertical scrolling (two bugs here: add instead of sub; interlave plane A/B) - mask nametable read offsets (can't exceed 8192-byte nametables apparently) - emulated VRAM/VSRAM/CRAM reads from VDP data port - fixed sprite width/height size calculations - added partial emulation of 40-tile per scanline limitation (enough to fix Sonic's title screen) - fixed off-by-one sprite range testing - fixed sprite tile indexing - Vblank happens at Y=224 with overscan disabled - unsure what happens when you toggle it between Y=224 and Y=240 ... probably bad things - fixed reading of address register for ADDA, CMPA, SUBA - fixed sign extension for MOVEA effect address reads - updated MOVEM to increment the read addresses (but not writeback) for (aN) mode With all of that out of the way, we finally have Sonic the Hedgehog (fully?) playable. I played to stage 1-2 and through the special stage, at least. EDIT: yeah, we probably need HIRQs for Labyrinth Zone. Not much else works, of course. Most games hang waiting on the Z80, and those that don't (like Altered Beast) are still royally screwed. Tons of features still missing; including all of the Z80/PSG/YM2612. A note on the perihperals this time around: the Mega Drive EXT port is basically identical to the regular controller ports. So unlike with the Famicom and Super Famicom, I'm inheriting the exension port from the controller class.
2016-08-21 22:11:24 +00:00
virtual auto readData() -> uint8 { return 0xff; }
virtual auto writeData(uint8 data) -> void {}
const uint port;
};
Update to v103r02 release. byuu says: Changelog: - fc/apu: improved phase duty cycle emulation (mode 3 is 25% phase inverted; counter decrements) - md/apu: power/reset do not cancel 68K bus requests - md/apu: 68K is not granted bus access on Z80 power/reset - md/controller: replaced System::Peripherals with ControllerPort concept - md/controller: CTRL port is now read-write, maintains value across controller changes (and soon, soft resets) - md/psg: PSG sampling rate unintentionally modified¹ - processor/spc700: improve cycle timing of (indirect),y instructions [Overload] - processor/spc700: idle() cycles actually read from the program counter; much like the 6502 [Overload] - some of the idle() cycles should read from other addresses; this still needs to be supported - processor/spc700: various cleanups to instruction function naming - processor/z80: prefix state (HL→IX,IY override) can now be serialized - icarus: fix install rule for certain platforms (it wasn't buggy on FreeBSD, but was on Linux?) ¹: the clock speed of the PSG is oscillator/15. But I was setting the sampling rate to oscillator/15/16, which was around 223KHz. I am not sure whether the PSG should be outputting at 3MHz or 223KHz. Amazingly ... I don't really hear a difference either way `o_O` I didn't actually mean to make this change; I just noticed it after comparing the diff between r01 and r02. If this turns out to be wrong, set stream = Emulator::audio.createStream(1, frequency() / 16.0); in md/psg.cpp to revert this change.
2017-06-27 01:18:28 +00:00
struct ControllerPort {
auto connect(uint deviceID) -> void;
Update to v103r02 release. byuu says: Changelog: - fc/apu: improved phase duty cycle emulation (mode 3 is 25% phase inverted; counter decrements) - md/apu: power/reset do not cancel 68K bus requests - md/apu: 68K is not granted bus access on Z80 power/reset - md/controller: replaced System::Peripherals with ControllerPort concept - md/controller: CTRL port is now read-write, maintains value across controller changes (and soon, soft resets) - md/psg: PSG sampling rate unintentionally modified¹ - processor/spc700: improve cycle timing of (indirect),y instructions [Overload] - processor/spc700: idle() cycles actually read from the program counter; much like the 6502 [Overload] - some of the idle() cycles should read from other addresses; this still needs to be supported - processor/spc700: various cleanups to instruction function naming - processor/z80: prefix state (HL→IX,IY override) can now be serialized - icarus: fix install rule for certain platforms (it wasn't buggy on FreeBSD, but was on Linux?) ¹: the clock speed of the PSG is oscillator/15. But I was setting the sampling rate to oscillator/15/16, which was around 223KHz. I am not sure whether the PSG should be outputting at 3MHz or 223KHz. Amazingly ... I don't really hear a difference either way `o_O` I didn't actually mean to make this change; I just noticed it after comparing the diff between r01 and r02. If this turns out to be wrong, set stream = Emulator::audio.createStream(1, frequency() / 16.0); in md/psg.cpp to revert this change.
2017-06-27 01:18:28 +00:00
auto readControl() -> uint8;
auto writeControl(uint8 data) -> void;
auto power(uint port) -> void;
auto unload() -> void;
auto serialize(serializer&) -> void;
uint port;
uint8 control;
Controller* device = nullptr;
Update to v103r02 release. byuu says: Changelog: - fc/apu: improved phase duty cycle emulation (mode 3 is 25% phase inverted; counter decrements) - md/apu: power/reset do not cancel 68K bus requests - md/apu: 68K is not granted bus access on Z80 power/reset - md/controller: replaced System::Peripherals with ControllerPort concept - md/controller: CTRL port is now read-write, maintains value across controller changes (and soon, soft resets) - md/psg: PSG sampling rate unintentionally modified¹ - processor/spc700: improve cycle timing of (indirect),y instructions [Overload] - processor/spc700: idle() cycles actually read from the program counter; much like the 6502 [Overload] - some of the idle() cycles should read from other addresses; this still needs to be supported - processor/spc700: various cleanups to instruction function naming - processor/z80: prefix state (HL→IX,IY override) can now be serialized - icarus: fix install rule for certain platforms (it wasn't buggy on FreeBSD, but was on Linux?) ¹: the clock speed of the PSG is oscillator/15. But I was setting the sampling rate to oscillator/15/16, which was around 223KHz. I am not sure whether the PSG should be outputting at 3MHz or 223KHz. Amazingly ... I don't really hear a difference either way `o_O` I didn't actually mean to make this change; I just noticed it after comparing the diff between r01 and r02. If this turns out to be wrong, set stream = Emulator::audio.createStream(1, frequency() / 16.0); in md/psg.cpp to revert this change.
2017-06-27 01:18:28 +00:00
};
extern ControllerPort controllerPort1;
extern ControllerPort controllerPort2;
extern ControllerPort extensionPort;
Update to v103r24 release. byuu says: Changelog: - gb/mbc6: mapper is now functional, but Net de Get has some text corruption¹ - gb/mbc7: mapper is now functional² - gb/cpu: HDMA syncs other components after each byte transfer now - gb/ppu: LY,LX forced to zero when LCDC.d7 is lowered (eg disabled), not when it's raised (eg enabled) - gb/ppu: the LCD does not run at all when LCDC.d7 is clear³ - fixes graphical corruption between scene transitions in Legend of Zelda - Oracle of Ages - thanks to Cydrak, Shonumi, gekkio for their input on the cause of this issue - md/controller: renamed "Gamepad" to "Control Pad" per official terminology - md/controller: added "Fighting Pad" (6-button controller) emulation [hex\_usr] - processor/m68k: fixed TAS to set data.d7 when EA.mode==DataRegisterDirect; fixes Asterix - hiro/windows: removed carriage returns from mouse.cpp and desktop.cpp - ruby/audio/alsa: added device driver selection [SuperMikeMan] - ruby/audio/ao: set format.matrix=nullptr to prevent a crash on some systems [SuperMikeMan] - ruby/video/cgl: rename term() to terminate() to fix a crash on macOS [Sintendo] ¹: The observation that this mapper split $4000-7fff into two banks came from MAME's implementation. But their implementation was quite broken and incomplete, so I didn't actually use any of it. The observation that this mapper split $a000-bfff into two banks came from Tauwasser, and I did directly use that information, plus the knowledge that $0400/$0800 are the RAM bank select registers. The text corruption is due to a race condition with timing. The game is transferring font letters via HDMA, but the game code ends up setting the bank# with the font a bit too late after the HDMA has already occurred. I'm not sure how to fix this ... as a whole, I assumed my Game Boy timing was pretty good, but apparently it's not that good. ²: The entire design of this mapper comes from endrift's notes. endrift gets full credit for higan being able to emulate this mapper. Note that the accelerometer implementation is still not tested, and probably won't work right until I tweak the sensitivity a lot. ³: So the fun part of this is ... it breaks the strict 60fps rate of the Game Boy. This was always inevitable: certain timing conditions can stretch frames, too. But this is pretty much an absolute deal breaker for something like Vsync timing. This pretty much requires adaptive sync to run well without audio stuttering during the transition. There's currently one very important detail missing: when the LCD is turned off, presumably the image on the screen fades to white. I do not know how long this process takes, or how to really go about emulating it. Right now as an incomplete patch, I'm simply leaving the last displayed image on the screen until the LCD is turned on again. But I will have to output white, as well as add code to break out of the emulation loop periodically when the LCD is left off eg indefinitely, or bad things would happen. I'll work something out and then implement. Another detail is I'm not sure how long it takes for the LCD to start rendering again once enabled. Right now, it's immediate. I've heard it's as long as 1/60th of a second, but that really seems incredibly excessive? I'd like to know at least a reasonably well-supported estimate before I implement that.
2017-08-01 11:41:27 +00:00
#include "control-pad/control-pad.hpp"
#include "fighting-pad/fighting-pad.hpp"