2011-05-06 14:16:46 +00:00
|
|
|
#define CYCLE_ACCURATE
|
2011-05-05 11:37:46 +00:00
|
|
|
|
2012-04-29 06:16:44 +00:00
|
|
|
#include <sfc/sfc.hpp>
|
2011-05-02 13:53:16 +00:00
|
|
|
|
|
|
|
|
#define SMP_CPP
|
2012-04-26 10:51:13 +00:00
|
|
|
namespace SuperFamicom {
|
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
|
|
|
SMP smp;
|
2011-05-02 13:53:16 +00:00
|
|
|
|
|
|
|
|
#include "algorithms.cpp"
|
|
|
|
|
#include "core.cpp"
|
|
|
|
|
#include "memory.cpp"
|
|
|
|
|
#include "timing.cpp"
|
|
|
|
|
|
|
|
|
|
void SMP::synchronize_cpu() {
|
|
|
|
|
if(CPU::Threaded == true) {
|
2011-05-05 11:37:46 +00:00
|
|
|
//if(clock >= 0 && scheduler.sync != Scheduler::SynchronizeMode::All) co_switch(cpu.thread);
|
2011-05-02 13:53:16 +00:00
|
|
|
} else {
|
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
|
|
|
while(clock >= 0) cpu.enter();
|
2011-05-02 13:53:16 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void SMP::synchronize_dsp() {
|
|
|
|
|
if(DSP::Threaded == true) {
|
2011-05-05 11:37:46 +00:00
|
|
|
//if(dsp.clock < 0 && scheduler.sync != Scheduler::SynchronizeMode::All) co_switch(dsp.thread);
|
2011-05-02 13:53:16 +00:00
|
|
|
} else {
|
|
|
|
|
while(dsp.clock < 0) dsp.enter();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void SMP::enter() {
|
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
|
|
|
while(clock < 0) op_step();
|
2011-05-02 13:53:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void SMP::power() {
|
2012-03-23 10:43:39 +00:00
|
|
|
Thread::frequency = system.apu_frequency();
|
|
|
|
|
Thread::clock = 0;
|
2011-05-02 13:53:16 +00:00
|
|
|
|
|
|
|
|
timer0.target = 0;
|
|
|
|
|
timer1.target = 0;
|
|
|
|
|
timer2.target = 0;
|
|
|
|
|
|
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
|
|
|
for(unsigned n = 0; n < 256; n++) {
|
|
|
|
|
cycle_table_dsp[n] = (cycle_count_table[n] * 24);
|
|
|
|
|
cycle_table_cpu[n] = (cycle_count_table[n] * 24) * cpu.frequency;
|
|
|
|
|
}
|
|
|
|
|
|
2011-05-05 11:37:46 +00:00
|
|
|
cycle_step_cpu = 24 * cpu.frequency;
|
|
|
|
|
|
2011-05-02 13:53:16 +00:00
|
|
|
reset();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void SMP::reset() {
|
|
|
|
|
for(unsigned n = 0x0000; n <= 0xffff; n++) apuram[n] = 0x00;
|
|
|
|
|
|
2011-05-05 11:37:46 +00:00
|
|
|
opcode_number = 0;
|
|
|
|
|
opcode_cycle = 0;
|
|
|
|
|
|
2011-05-02 13:53:16 +00:00
|
|
|
regs.pc = 0xffc0;
|
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
|
|
|
regs.sp = 0xef;
|
2011-05-02 13:53:16 +00:00
|
|
|
regs.a = 0x00;
|
|
|
|
|
regs.x = 0x00;
|
|
|
|
|
regs.y = 0x00;
|
|
|
|
|
regs.p = 0x02;
|
|
|
|
|
|
|
|
|
|
//$00f1
|
|
|
|
|
status.iplrom_enable = true;
|
|
|
|
|
|
|
|
|
|
//$00f2
|
|
|
|
|
status.dsp_addr = 0x00;
|
|
|
|
|
|
|
|
|
|
//$00f8,$00f9
|
|
|
|
|
status.ram00f8 = 0x00;
|
|
|
|
|
status.ram00f9 = 0x00;
|
2011-05-05 11:37:46 +00:00
|
|
|
|
|
|
|
|
//timers
|
|
|
|
|
timer0.enable = timer1.enable = timer2.enable = false;
|
|
|
|
|
timer0.stage1_ticks = timer1.stage1_ticks = timer2.stage1_ticks = 0;
|
|
|
|
|
timer0.stage2_ticks = timer1.stage2_ticks = timer2.stage2_ticks = 0;
|
|
|
|
|
timer0.stage3_ticks = timer1.stage3_ticks = timer2.stage3_ticks = 0;
|
2011-05-02 13:53:16 +00:00
|
|
|
}
|
|
|
|
|
|
2013-05-05 09:21:30 +00:00
|
|
|
void SMP::serialize(serializer& s) {
|
2012-03-23 10:43:39 +00:00
|
|
|
Thread::serialize(s);
|
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
|
|
|
|
|
|
|
|
s.array(apuram, 64 * 1024);
|
|
|
|
|
|
2011-05-05 11:37:46 +00:00
|
|
|
s.integer(opcode_number);
|
|
|
|
|
s.integer(opcode_cycle);
|
|
|
|
|
|
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
|
|
|
s.integer(regs.pc);
|
|
|
|
|
s.integer(regs.sp);
|
|
|
|
|
s.integer(regs.a);
|
|
|
|
|
s.integer(regs.x);
|
|
|
|
|
s.integer(regs.y);
|
|
|
|
|
|
|
|
|
|
s.integer(regs.p.n);
|
|
|
|
|
s.integer(regs.p.v);
|
|
|
|
|
s.integer(regs.p.p);
|
|
|
|
|
s.integer(regs.p.b);
|
|
|
|
|
s.integer(regs.p.h);
|
|
|
|
|
s.integer(regs.p.i);
|
|
|
|
|
s.integer(regs.p.z);
|
|
|
|
|
s.integer(regs.p.c);
|
|
|
|
|
|
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
|
|
|
s.integer(rd);
|
|
|
|
|
s.integer(wr);
|
|
|
|
|
s.integer(dp);
|
|
|
|
|
s.integer(sp);
|
|
|
|
|
s.integer(ya);
|
|
|
|
|
s.integer(bit);
|
|
|
|
|
|
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
|
|
|
s.integer(status.iplrom_enable);
|
|
|
|
|
|
|
|
|
|
s.integer(status.dsp_addr);
|
|
|
|
|
|
|
|
|
|
s.integer(status.ram00f8);
|
|
|
|
|
s.integer(status.ram00f9);
|
2011-05-05 11:37:46 +00:00
|
|
|
|
|
|
|
|
s.integer(timer0.enable);
|
|
|
|
|
s.integer(timer0.target);
|
|
|
|
|
s.integer(timer0.stage1_ticks);
|
|
|
|
|
s.integer(timer0.stage2_ticks);
|
|
|
|
|
s.integer(timer0.stage3_ticks);
|
|
|
|
|
|
|
|
|
|
s.integer(timer1.enable);
|
|
|
|
|
s.integer(timer1.target);
|
|
|
|
|
s.integer(timer1.stage1_ticks);
|
|
|
|
|
s.integer(timer1.stage2_ticks);
|
|
|
|
|
s.integer(timer1.stage3_ticks);
|
|
|
|
|
|
|
|
|
|
s.integer(timer2.enable);
|
|
|
|
|
s.integer(timer2.target);
|
|
|
|
|
|
|
|
|
|
s.integer(timer2.stage1_ticks);
|
|
|
|
|
s.integer(timer2.stage2_ticks);
|
|
|
|
|
s.integer(timer2.stage3_ticks);
|
2011-05-02 13:53:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SMP::SMP() {
|
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
|
|
|
apuram = new uint8[64 * 1024];
|
2013-05-05 09:21:30 +00:00
|
|
|
for(auto& byte : iplrom) byte = 0;
|
2011-05-02 13:53:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SMP::~SMP() {
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|