bsnes/higan/ms/controller/controller.hpp

struct Controller : Thread {
  Controller(uint port);
  virtual ~Controller();

  static auto Enter() -> void;
  auto main() -> void;

  virtual auto readData() -> uint7 { return 0x7f; }

  const uint port;
};

#include "gamepad/gamepad.hpp"
Update to v101r28 release. byuu says: Changelog: - SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd) 0xcb (displacement) (opcode) set - 1/8th of these were "legal" instructions, and apparently games use them a lot - SMS: emulated the standard gamepad controllers - reset button not emulated yet The reset button is tricky. In every other case, reset is a hardware thing that instantly reboots the entire machine. But on the SMS, it's more like a gamepad button that's attached to the front of the device. When you press it, it fires off a reset vector interrupt and the gamepad polling routine lets you query the status of the button. Just having a reset option in the "Master System" hardware menu is not sufficient to fully emulate the behavior. Even more annoying is that the Game Gear doesn't have such a button, yet the core information structs aren't flexible enough for the Master System to have it, and the Game Gear to not have it, in the main menu. But that doesn't matter anyway, since it won't work having it in the menu for the Master System. So as a result, I'm going to have to have a new "input device" called "Hardware" that has the "Reset" button listed under there. And for the sake of consistency, I'm not sure if we should treat the other systems the same way or not :/ 2017-01-08 20:55:02 +00:00			`struct Controller : Thread {`
			`Controller(uint port);`
			`virtual ~Controller();`

			`static auto Enter() -> void;`
			`auto main() -> void;`

Update to v101r32 release. byuu says: Changelog: - SMS: fixed controller connection bug - SMS: fixed Z80 reset bug - PCE: emulated HuC6280 MMU - PCE: emulated HuC6280 RAM - PCE: emulated HuCard ROM reading - PCE: implemented 178 instructions - tomoko: removed "soft reset" functionality - tomoko: moved "power cycle" to just above "unload" option I'm not sure of the exact number of HuC6280 instructions, but it's less than 260. Many of the ones I skipped are HuC6280-originals that I don't know how to emulate just yet. I'm also really unsure about the zero page stuff. I believe we should be adding 0x2000 to the addresses to hit page 1, which is supposed to be mapped to the zero page (RAM). But when I look at turboEMU's source, I have no clue how the hell it could possibly be doing that. It looks to be reading from page 0, which is almost always ROM, which would be ... really weird. I also don't know if I've emulated the T mode opcodes correctly or not. The documentation on them is really confusing. 2017-01-13 23:59:38 +00:00			`virtual auto readData() -> uint7 { return 0x7f; }`
Update to v101r28 release. byuu says: Changelog: - SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd) 0xcb (displacement) (opcode) set - 1/8th of these were "legal" instructions, and apparently games use them a lot - SMS: emulated the standard gamepad controllers - reset button not emulated yet The reset button is tricky. In every other case, reset is a hardware thing that instantly reboots the entire machine. But on the SMS, it's more like a gamepad button that's attached to the front of the device. When you press it, it fires off a reset vector interrupt and the gamepad polling routine lets you query the status of the button. Just having a reset option in the "Master System" hardware menu is not sufficient to fully emulate the behavior. Even more annoying is that the Game Gear doesn't have such a button, yet the core information structs aren't flexible enough for the Master System to have it, and the Game Gear to not have it, in the main menu. But that doesn't matter anyway, since it won't work having it in the menu for the Master System. So as a result, I'm going to have to have a new "input device" called "Hardware" that has the "Reset" button listed under there. And for the sake of consistency, I'm not sure if we should treat the other systems the same way or not :/ 2017-01-08 20:55:02 +00:00
			`const uint port;`
			`};`

			`#include "gamepad/gamepad.hpp"`