2012-03-23 10:43:39 +00:00
|
|
|
struct SMP : Thread {
|
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 iplrom[64];
|
2013-05-05 09:21:30 +00:00
|
|
|
uint8* apuram;
|
2011-05-02 13:53:16 +00:00
|
|
|
|
|
|
|
|
enum : bool { Threaded = false };
|
|
|
|
|
alwaysinline void synchronize_cpu();
|
|
|
|
|
alwaysinline void synchronize_dsp();
|
|
|
|
|
|
|
|
|
|
unsigned port_read(unsigned port);
|
|
|
|
|
void port_write(unsigned port, unsigned data);
|
|
|
|
|
|
Update to v078r02 release.
byuu says:
New S-SMP core is feature-complete, but still buggy. It's good enough
for perfect audio in Zelda 3 and Super Mario World, but there are plenty
of issues. No audio in Bahamut Lagoon, deadlock in Earthworm Jim 2,
etc.
With this core, bsnes/Performance runs about 3-5% faster than with the
old one. That won't seem like much, because the S-SMP is the least
demanding portion of the SNES. blargg's SMP core netted me a 5-8%
speedup the last time I tried it, so I'm sure there's still room to
speed things up.
The core is opcode-based, but has dummy op_io() calls (they compile to
nothing), so it is trivial to make it cycle-based if desired. I'm not
convinced that is necessary, but we shall see once we get the opcode
bugs ironed out.
2011-05-03 09:58:12 +00:00
|
|
|
unsigned mmio_read(unsigned addr);
|
|
|
|
|
void mmio_write(unsigned addr, unsigned data);
|
|
|
|
|
|
2011-05-02 13:53:16 +00:00
|
|
|
void enter();
|
|
|
|
|
void power();
|
|
|
|
|
void reset();
|
|
|
|
|
|
|
|
|
|
void serialize(serializer&);
|
|
|
|
|
SMP();
|
|
|
|
|
~SMP();
|
|
|
|
|
|
Update to v085r03 release.
byuu says:
Changelog:
- fixed cursor being visible under Metacity window manager (hopefully
doesn't cause regression with other WMs)
- show normal cursor when using SDL video driver
- added menu accelerators (meh, why not?)
- removed debugvirtual, ChipDebugger and chip/debugger functionality
entirely
- alt/smp disassembler moved up
- fixed alt/smp incw/decw instructions (unsigned->uint16 for internal
variables)
My plan going forward for a debugger is not to hardcode functionality
that causes the 10-15% slowdown right into the emulator itself.
Instead, I'm going to make a callback class, which will be a specialized
version of nall::function:
- can call function even if not assigned (results in no-op, return type
must have a trivial default constructor)
- if compiled without #define DEBUGGER, the entire thing turns into
a huge no-op; and will be eliminated entirely when compiled
- strategically place the functions: cb_step, cb_read, cb_write, etc.
From here, the ui-debugger GUI will bind the callbacks, implement
breakpoint checking, usage table generation, etc itself.
I'll probably have to add some breakout commands to exit the emulation
core prior to a frame event in some cases as well.
I didn't initially want any debugger-related stuff in the base cores,
but the #if debugger sCPUDebugger #else sCPU #endif stuff was already
more of a burden than this will be.
2012-02-04 09:23:53 +00:00
|
|
|
void disassemble_opcode(char *output, uint16 addr);
|
|
|
|
|
|
2011-05-05 11:40:22 +00:00
|
|
|
//private:
|
2011-05-02 13:53:16 +00:00
|
|
|
struct Flags {
|
|
|
|
|
bool n, v, p, b, h, i, z, c;
|
|
|
|
|
|
|
|
|
|
alwaysinline operator unsigned() const {
|
|
|
|
|
return (n << 7) | (v << 6) | (p << 5) | (b << 4)
|
|
|
|
|
| (h << 3) | (i << 2) | (z << 1) | (c << 0);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
alwaysinline unsigned operator=(unsigned data) {
|
|
|
|
|
n = data & 0x80; v = data & 0x40; p = data & 0x20; b = data & 0x10;
|
|
|
|
|
h = data & 0x08; i = data & 0x04; z = data & 0x02; c = data & 0x01;
|
2011-06-13 12:13:30 +00:00
|
|
|
return data;
|
2011-05-02 13:53:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
alwaysinline unsigned operator|=(unsigned data) { return operator=(operator unsigned() | data); }
|
|
|
|
|
alwaysinline unsigned operator^=(unsigned data) { return operator=(operator unsigned() ^ data); }
|
|
|
|
|
alwaysinline unsigned operator&=(unsigned data) { return operator=(operator unsigned() & data); }
|
|
|
|
|
};
|
|
|
|
|
|
2011-05-05 11:37:46 +00:00
|
|
|
unsigned opcode_number;
|
|
|
|
|
unsigned opcode_cycle;
|
|
|
|
|
|
2011-05-02 13:53:16 +00:00
|
|
|
struct Regs {
|
|
|
|
|
uint16 pc;
|
Update to v078r02 release.
byuu says:
New S-SMP core is feature-complete, but still buggy. It's good enough
for perfect audio in Zelda 3 and Super Mario World, but there are plenty
of issues. No audio in Bahamut Lagoon, deadlock in Earthworm Jim 2,
etc.
With this core, bsnes/Performance runs about 3-5% faster than with the
old one. That won't seem like much, because the S-SMP is the least
demanding portion of the SNES. blargg's SMP core netted me a 5-8%
speedup the last time I tried it, so I'm sure there's still room to
speed things up.
The core is opcode-based, but has dummy op_io() calls (they compile to
nothing), so it is trivial to make it cycle-based if desired. I'm not
convinced that is necessary, but we shall see once we get the opcode
bugs ironed out.
2011-05-03 09:58:12 +00:00
|
|
|
uint8 sp;
|
2011-05-02 13:53:16 +00:00
|
|
|
union {
|
|
|
|
|
uint16 ya;
|
|
|
|
|
struct { uint8 order_lsb2(a, y); };
|
|
|
|
|
};
|
|
|
|
|
uint8 x;
|
|
|
|
|
Flags p;
|
|
|
|
|
} regs;
|
|
|
|
|
|
Update to v085r03 release.
byuu says:
Changelog:
- fixed cursor being visible under Metacity window manager (hopefully
doesn't cause regression with other WMs)
- show normal cursor when using SDL video driver
- added menu accelerators (meh, why not?)
- removed debugvirtual, ChipDebugger and chip/debugger functionality
entirely
- alt/smp disassembler moved up
- fixed alt/smp incw/decw instructions (unsigned->uint16 for internal
variables)
My plan going forward for a debugger is not to hardcode functionality
that causes the 10-15% slowdown right into the emulator itself.
Instead, I'm going to make a callback class, which will be a specialized
version of nall::function:
- can call function even if not assigned (results in no-op, return type
must have a trivial default constructor)
- if compiled without #define DEBUGGER, the entire thing turns into
a huge no-op; and will be eliminated entirely when compiled
- strategically place the functions: cb_step, cb_read, cb_write, etc.
From here, the ui-debugger GUI will bind the callbacks, implement
breakpoint checking, usage table generation, etc itself.
I'll probably have to add some breakout commands to exit the emulation
core prior to a frame event in some cases as well.
I didn't initially want any debugger-related stuff in the base cores,
but the #if debugger sCPUDebugger #else sCPU #endif stuff was already
more of a burden than this will be.
2012-02-04 09:23:53 +00:00
|
|
|
uint16 rd, wr, dp, sp, ya, bit;
|
Update to v082r04 release.
byuu says:
So, here's the deal. I now have three emulators. I don't think the
NES/GB ones are at all useful, but I do want them to be eventually. And
having them have those pathetic little GUIs like ui-gameboy, and keeping
everything in separate project folders, just doesn't work well for me.
I kind of "got around" the issue with the Game Boy, by only allowing SGB
mode emulation. But there is no "Super Nintendo" ... er ... wait ...
uhmm ... well, you know what I mean anyway.
So, my idea is to write a multi-emulator GUI, and keep the projects
together. The GUI is not going to change much. The way I envision this
working:
At startup, you have a menubar with: "Cartridge, Settings, Tools, Help".
Cartridge has "Load NES Cartridge", "Load SNES Cartridge", etc.
When you load something, Cartridge is replaced with the appropriate
system menu, eg "SNES". Here you have all your regular items: "power,
reset, controller port selection, etc." There is also a new "Unload
Cartridge" option, which is how you restore the "Cartridge" menu again.
I have no plans to emulate any other systems, but if I ever do emulate
something that doesn't take cartridges, I'll change the name to just
"Load" or something.
The cheat editor / state manager will look and act exactly the same. The
settings panel will look exactly the same. I'll simply show/hide
system-specific options as needed, like NES/SNES aspect ratio
correction, etc. The input mapping window will just have settings for
the currently loaded system. Video and audio tweaking will apply
cross-system, as will hotkey mapping.
The GUI stuff is mostly copy-paste, so it should only take me a week to
get it 95% back to where it was, so don't worry, this isn't total GUI
rewrite #80.
I am, however, making all the objects pointers, so that I can destruct
them all prior to main() returning, which is certainly one way of fixing
that annoying Windows/Qt crash.
Please only test on Linux. The Windows port is broken to hell, and will
give you a bad impression of the idea:
- menu groups are not hiding for some reason (all groups are showing, it
looks hideous)
- Timer interval(0) is taking 16ms per call, capping the FPS to ~64 tops
[FWIW, bsnes/accuracy gets 130fps, bgameboy gets 450fps, bnes gets
800fps; all run at lowest possible granularity]
- the OS keeps beeping when you press keys (AGAIN)
Of course, Qt and GTK+ don't let you shrink a window from the requested
geometry size, because they suck. So the video scaling stuff doesn't
work all that great yet.
Man, a metric fuckton of things need to be fixed in phoenix, and
I really don't know how to fix any of them :/
2011-09-09 04:08:38 +00:00
|
|
|
|
2011-05-02 13:53:16 +00:00
|
|
|
struct Status {
|
|
|
|
|
//$00f1
|
|
|
|
|
bool iplrom_enable;
|
|
|
|
|
|
|
|
|
|
//$00f2
|
|
|
|
|
unsigned dsp_addr;
|
|
|
|
|
|
|
|
|
|
//$00f8,$00f9
|
|
|
|
|
unsigned ram00f8;
|
|
|
|
|
unsigned ram00f9;
|
|
|
|
|
} status;
|
|
|
|
|
|
|
|
|
|
template<unsigned frequency>
|
|
|
|
|
struct Timer {
|
|
|
|
|
bool enable;
|
2011-05-05 11:37:46 +00:00
|
|
|
uint8 target;
|
|
|
|
|
uint8 stage1_ticks;
|
|
|
|
|
uint8 stage2_ticks;
|
|
|
|
|
uint8 stage3_ticks;
|
2011-05-02 13:53:16 +00:00
|
|
|
|
2011-05-05 11:40:22 +00:00
|
|
|
void tick();
|
Update to v078r02 release.
byuu says:
New S-SMP core is feature-complete, but still buggy. It's good enough
for perfect audio in Zelda 3 and Super Mario World, but there are plenty
of issues. No audio in Bahamut Lagoon, deadlock in Earthworm Jim 2,
etc.
With this core, bsnes/Performance runs about 3-5% faster than with the
old one. That won't seem like much, because the S-SMP is the least
demanding portion of the SNES. blargg's SMP core netted me a 5-8%
speedup the last time I tried it, so I'm sure there's still room to
speed things up.
The core is opcode-based, but has dummy op_io() calls (they compile to
nothing), so it is trivial to make it cycle-based if desired. I'm not
convinced that is necessary, but we shall see once we get the opcode
bugs ironed out.
2011-05-03 09:58:12 +00:00
|
|
|
void tick(unsigned clocks);
|
2011-05-02 13:53:16 +00:00
|
|
|
};
|
|
|
|
|
|
2011-05-05 11:37:46 +00:00
|
|
|
Timer<128> timer0;
|
|
|
|
|
Timer<128> timer1;
|
|
|
|
|
Timer< 16> timer2;
|
2011-05-05 11:40:22 +00:00
|
|
|
|
|
|
|
|
void tick();
|
|
|
|
|
alwaysinline void op_io();
|
Update to v085r03 release.
byuu says:
Changelog:
- fixed cursor being visible under Metacity window manager (hopefully
doesn't cause regression with other WMs)
- show normal cursor when using SDL video driver
- added menu accelerators (meh, why not?)
- removed debugvirtual, ChipDebugger and chip/debugger functionality
entirely
- alt/smp disassembler moved up
- fixed alt/smp incw/decw instructions (unsigned->uint16 for internal
variables)
My plan going forward for a debugger is not to hardcode functionality
that causes the 10-15% slowdown right into the emulator itself.
Instead, I'm going to make a callback class, which will be a specialized
version of nall::function:
- can call function even if not assigned (results in no-op, return type
must have a trivial default constructor)
- if compiled without #define DEBUGGER, the entire thing turns into
a huge no-op; and will be eliminated entirely when compiled
- strategically place the functions: cb_step, cb_read, cb_write, etc.
From here, the ui-debugger GUI will bind the callbacks, implement
breakpoint checking, usage table generation, etc itself.
I'll probably have to add some breakout commands to exit the emulation
core prior to a frame event in some cases as well.
I didn't initially want any debugger-related stuff in the base cores,
but the #if debugger sCPUDebugger #else sCPU #endif stuff was already
more of a burden than this will be.
2012-02-04 09:23:53 +00:00
|
|
|
alwaysinline uint8 op_read(uint16 addr);
|
|
|
|
|
alwaysinline void op_write(uint16 addr, uint8 data);
|
|
|
|
|
alwaysinline void op_step();
|
2011-05-05 11:40:22 +00:00
|
|
|
static const unsigned cycle_count_table[256];
|
|
|
|
|
uint64 cycle_table_cpu[256];
|
|
|
|
|
unsigned cycle_table_dsp[256];
|
|
|
|
|
uint64 cycle_step_cpu;
|
|
|
|
|
|
|
|
|
|
uint8 op_adc (uint8 x, uint8 y);
|
|
|
|
|
uint16 op_addw(uint16 x, uint16 y);
|
|
|
|
|
uint8 op_and (uint8 x, uint8 y);
|
|
|
|
|
uint8 op_cmp (uint8 x, uint8 y);
|
|
|
|
|
uint16 op_cmpw(uint16 x, uint16 y);
|
|
|
|
|
uint8 op_eor (uint8 x, uint8 y);
|
|
|
|
|
uint8 op_inc (uint8 x);
|
|
|
|
|
uint8 op_dec (uint8 x);
|
|
|
|
|
uint8 op_or (uint8 x, uint8 y);
|
|
|
|
|
uint8 op_sbc (uint8 x, uint8 y);
|
|
|
|
|
uint16 op_subw(uint16 x, uint16 y);
|
|
|
|
|
uint8 op_asl (uint8 x);
|
|
|
|
|
uint8 op_lsr (uint8 x);
|
|
|
|
|
uint8 op_rol (uint8 x);
|
|
|
|
|
uint8 op_ror (uint8 x);
|
2011-05-02 13:53:16 +00:00
|
|
|
};
|
|
|
|
|
|
Update to v085r03 release.
byuu says:
Changelog:
- fixed cursor being visible under Metacity window manager (hopefully
doesn't cause regression with other WMs)
- show normal cursor when using SDL video driver
- added menu accelerators (meh, why not?)
- removed debugvirtual, ChipDebugger and chip/debugger functionality
entirely
- alt/smp disassembler moved up
- fixed alt/smp incw/decw instructions (unsigned->uint16 for internal
variables)
My plan going forward for a debugger is not to hardcode functionality
that causes the 10-15% slowdown right into the emulator itself.
Instead, I'm going to make a callback class, which will be a specialized
version of nall::function:
- can call function even if not assigned (results in no-op, return type
must have a trivial default constructor)
- if compiled without #define DEBUGGER, the entire thing turns into
a huge no-op; and will be eliminated entirely when compiled
- strategically place the functions: cb_step, cb_read, cb_write, etc.
From here, the ui-debugger GUI will bind the callbacks, implement
breakpoint checking, usage table generation, etc itself.
I'll probably have to add some breakout commands to exit the emulation
core prior to a frame event in some cases as well.
I didn't initially want any debugger-related stuff in the base cores,
but the #if debugger sCPUDebugger #else sCPU #endif stuff was already
more of a burden than this will be.
2012-02-04 09:23:53 +00:00
|
|
|
extern SMP smp;
|