2011-06-24 10:43:29 +00:00
|
|
|
// SNES controller port pinout:
|
|
|
|
// -------------------------------
|
|
|
|
// | (1) (2) (3) (4) | (5) (6) (7) )
|
|
|
|
// -------------------------------
|
|
|
|
// pin name port1 port2
|
|
|
|
// 1: +5v
|
|
|
|
// 2: clock $4016 read $4017 read
|
|
|
|
// 3: latch $4016.d0 write $4016.d0 write
|
|
|
|
// 4: data1 $4016.d0 read $4017.d0 read
|
|
|
|
// 5: data2 $4016.d1 read $4017.d1 read
|
|
|
|
// 6: iobit $4201.d6 write; $4213.d6 read $4201.d7 write; $4213.d7 read
|
|
|
|
// 7: gnd
|
|
|
|
|
2012-03-23 10:43:39 +00:00
|
|
|
struct Controller : Thread {
|
2011-06-24 10:43:29 +00:00
|
|
|
enum : bool { Port1 = 0, Port2 = 1 };
|
Update to v079r06 release.
byuu says:
It does add some more code to the CPU::step() function, so performance
probably went down actually, by about 1%. Removing the input.tick() call
didn't compensate as much as I'd hoped.
Hooked up Super Scope and Justifier support. The good news is that the
Justifier alignment doesn't get fucked up anymore when you go
off-screen. Never could fix that in the old version.
The bad news is that it takes a major speed hit for the time being.
I need to figure out how to run the CPU and input threads out of order.
Every time I try, the input gets thrown off by most of a scanline.
Right now, I'm forced to sync constantly to get the latching position
really accurate. But worst case, I can cut the syncs down by skipping
large chunks around the cursor position, +/-40 clock cycles. So it's
only temporarily slow.
Lastly, killed the old Input class, merged Controllers class into it.
I actually like Controllers as a name better, but it doesn't jive with
video/audio/input, so oh well.
2011-06-25 12:56:32 +00:00
|
|
|
|
2011-06-24 10:43:29 +00:00
|
|
|
Controller(bool port);
|
Update to v094r39 release.
byuu says:
Changelog:
- SNES mid-scanline BGMODE fixes finally merged (can run
atx2.zip{mode7.smc}+mtest(2).sfc properly now)
- Makefile now discards all built-in rules and variables
- switch on bool warning disabled for GCC now as well (was already
disabled for Clang)
- when loading a game, if any required files are missing, display
a warning message box (manifest.bml, program.rom, bios.rom, etc)
- when loading a game (or a game slot), if manifest.bml is missing, it
will invoke icarus to try and generate it
- if that fails (icarus is missing or the folder is bad), you will get
a warning telling you that the manifest can't be loaded
The warning prompt on missing files work for both games and the .sys
folders and their files. For some reason, failing to load the DMG/CGB
BIOS is causing a crash before I can display the modal dialog. I have no
idea why, and the stack frame backtrace is junk.
I also can't seem to abort the failed loading process. If I call
Program::unloadMedia(), I get a nasty segfault. Again with a really
nasty stack trace. So for now, it'll just end up sitting there emulating
an empty ROM (solid black screen.) In time, I'd like to fix that too.
Lastly, I need a better method than popen for Windows. popen is kind of
ugly and flashes a console window for a brief second even if the
application launched is linked with -mwindows. Not sure if there even is
one (I need to read the stdout result, so CreateProcess may not work
unless I do something nasty like "> %tmp%/temp") I'm also using the
regular popen instead of _wpopen, so for this WIP, it won't work if your
game folder has non-English letters in the path.
2015-08-04 09:00:55 +00:00
|
|
|
|
|
|
|
static auto Enter() -> void;
|
|
|
|
virtual auto enter() -> void;
|
|
|
|
|
|
|
|
auto step(unsigned clocks) -> void;
|
2015-10-10 02:16:12 +00:00
|
|
|
auto synchronizeCPU() -> void;
|
Update to v094r39 release.
byuu says:
Changelog:
- SNES mid-scanline BGMODE fixes finally merged (can run
atx2.zip{mode7.smc}+mtest(2).sfc properly now)
- Makefile now discards all built-in rules and variables
- switch on bool warning disabled for GCC now as well (was already
disabled for Clang)
- when loading a game, if any required files are missing, display
a warning message box (manifest.bml, program.rom, bios.rom, etc)
- when loading a game (or a game slot), if manifest.bml is missing, it
will invoke icarus to try and generate it
- if that fails (icarus is missing or the folder is bad), you will get
a warning telling you that the manifest can't be loaded
The warning prompt on missing files work for both games and the .sys
folders and their files. For some reason, failing to load the DMG/CGB
BIOS is causing a crash before I can display the modal dialog. I have no
idea why, and the stack frame backtrace is junk.
I also can't seem to abort the failed loading process. If I call
Program::unloadMedia(), I get a nasty segfault. Again with a really
nasty stack trace. So for now, it'll just end up sitting there emulating
an empty ROM (solid black screen.) In time, I'd like to fix that too.
Lastly, I need a better method than popen for Windows. popen is kind of
ugly and flashes a console window for a brief second even if the
application launched is linked with -mwindows. Not sure if there even is
one (I need to read the stdout result, so CreateProcess may not work
unless I do something nasty like "> %tmp%/temp") I'm also using the
regular popen instead of _wpopen, so for this WIP, it won't work if your
game folder has non-English letters in the path.
2015-08-04 09:00:55 +00:00
|
|
|
|
|
|
|
auto iobit() -> bool;
|
|
|
|
auto iobit(bool data) -> void;
|
|
|
|
virtual auto data() -> uint2 { return 0; }
|
|
|
|
virtual auto latch(bool data) -> void {}
|
|
|
|
|
|
|
|
const bool port;
|
2011-06-24 10:43:29 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
#include "gamepad/gamepad.hpp"
|
|
|
|
#include "multitap/multitap.hpp"
|
|
|
|
#include "mouse/mouse.hpp"
|
|
|
|
#include "superscope/superscope.hpp"
|
|
|
|
#include "justifier/justifier.hpp"
|
Update to v086r04 release.
byuu says:
There will probably be a series of small WIPs as I experiment here.
snes/controller/serial is now snes/controller/uart. Asynchronous serial
communications, typically capped at 57,600 baud.
snes/controller/usart is new. It aims to emulate the SNES connected to
a Teensy++ board, and can easily handle 524,288 baud.
And much more importantly, it's synchronous, so there are no timing
issues anymore. Just bit-bang as fast as you can.
Right now, the USART code is just enough for SNES->PC to transfer data
to ... well, nothing yet.
Unless anyone is actually using the UART stuff, I'll be removing it once
the USART is totally up and running.
No sense maintaining code that is 10x slower, more error prone, and used
by nobody.
Note: this is all thanks to blargg being absolutely amazing.
2012-02-25 08:49:27 +00:00
|
|
|
#include "usart/usart.hpp"
|