2016-01-27 11:31:39 +00:00
|
|
|
#pragma once
|
|
|
|
|
2016-04-09 05:20:41 +00:00
|
|
|
//license: GPLv3
|
|
|
|
//started: 2016-01-26
|
|
|
|
|
2016-01-27 11:31:39 +00:00
|
|
|
#include <emulator/emulator.hpp>
|
|
|
|
#include <processor/v30mz/v30mz.hpp>
|
|
|
|
|
|
|
|
namespace WonderSwan {
|
Update to v097r24 release.
byuu says:
Changelog:
- WS: fixed bug when IRQs triggered during a rep string instruction
- WS: added sprite attribute caching (per-scanline); absolutely massive
speed-up
- WS: emulated limit of 32 sprites per scanline
- WS: emulated the extended PPU register bit behavior based on the
DISP_CTRL tile bit-depth setting
- WS: added "Rotate" key binding; can be used to flip the WS display
between horizontal and vertical in real-time
The prefix emulation may not be 100% hardware-accurate, but the edge
cases should be extreme enough to not come up in the WS library. No way
to get the emulation 100% down without intensive hardware testing.
trap15 pointed me at a workflow diagram for it, but that diagram is
impossible without a magic internal stack frame that grows with every
IRQ, and can thus grow infinitely large.
The rotation thing isn't exactly the most friendly set-up, but oh well.
I'll see about adding a default rotation setting to manifests, so that
games like GunPey can start in the correct orientation. After that, if
the LCD orientation icon turns out to be reliable, then I'll start using
that. But if there are cases where it's not reliable, then I'll leave it
to manual button presses.
Speaking of icons, I'll need a set of icons to render on the screen.
Going to put them to the top right on vertical orientation, and on the
bottom left for horizontal orientation. Just outside of the video
output, of course.
Overall, WS is getting pretty far along, but still some major bugs in
various games. I really need sound emulation, though. Nobody's going to
use this at all without that.
2016-03-12 13:27:41 +00:00
|
|
|
enum class Model : uint {
|
|
|
|
WonderSwan, //SW-001 (ASWAN)
|
|
|
|
WonderSwanColor, //WSC-001 (SPHINX)
|
|
|
|
SwanCrystal, //SCT-001 (SPHINX2)
|
|
|
|
};
|
|
|
|
|
|
|
|
enum : uint { Byte = 1, Word = 2, Long = 4 };
|
|
|
|
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
struct File {
|
|
|
|
static const auto Read = vfs::file::mode::read;
|
|
|
|
static const auto Write = vfs::file::mode::write;
|
|
|
|
static const auto Optional = false;
|
|
|
|
static const auto Required = true;
|
|
|
|
};
|
|
|
|
|
2016-01-27 11:31:39 +00:00
|
|
|
struct Thread {
|
|
|
|
~Thread() {
|
|
|
|
if(thread) co_delete(thread);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto create(auto (*entrypoint)() -> void, uint frequency) -> void {
|
|
|
|
if(thread) co_delete(thread);
|
Update to v098r06 release.
byuu says:
Changelog:
- emulation cores now refresh video from host thread instead of
cothreads (fix AMD crash)
- SFC: fixed another bug with leap year months in SharpRTC emulation
- SFC: cleaned up camelCase on function names for
armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes
- GB: added MBC1M emulation (requires manually setting mapper=MBC1M in
manifest.bml for now, sorry)
- audio: implemented Emulator::Audio mixer and effects processor
- audio: implemented Emulator::Stream interface
- it is now possible to have more than two audio streams: eg SNES
+ SGB + MSU1 + Voicer-Kun (eventually)
- audio: added reverb delay + reverb level settings; exposed balance
configuration in UI
- video: reworked palette generation to re-enable saturation, gamma,
luminance adjustments
- higan/emulator.cpp is gone since there was nothing left in it
I know you guys are going to say the color adjust/balance/reverb stuff
is pointless. And indeed it mostly is. But I like the idea of allowing
some fun special effects and configurability that isn't system-wide.
Note: there seems to be some kind of added audio lag in the SGB
emulation now, and I don't really understand why. The code should be
effectively identical to what I had before. The only main thing is that
I'm sampling things to 48000hz instead of 32040hz before mixing. There's
no point where I'm intentionally introducing added latency though. I'm
kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be
much appreciated :/
I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as
well, and that would be very bad.
2016-04-22 13:35:51 +00:00
|
|
|
thread = co_create(65'536 * sizeof(void*), entrypoint);
|
2016-01-27 11:31:39 +00:00
|
|
|
this->frequency = frequency;
|
|
|
|
clock = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto serialize(serializer& s) -> void {
|
|
|
|
s.integer(frequency);
|
|
|
|
s.integer(clock);
|
|
|
|
}
|
|
|
|
|
|
|
|
cothread_t thread = nullptr;
|
|
|
|
uint frequency = 0;
|
|
|
|
int64 clock = 0;
|
|
|
|
};
|
|
|
|
|
2016-02-18 10:32:22 +00:00
|
|
|
#include <ws/memory/memory.hpp>
|
|
|
|
#include <ws/eeprom/eeprom.hpp>
|
2016-01-27 11:31:39 +00:00
|
|
|
#include <ws/system/system.hpp>
|
|
|
|
#include <ws/scheduler/scheduler.hpp>
|
|
|
|
#include <ws/cartridge/cartridge.hpp>
|
|
|
|
#include <ws/cpu/cpu.hpp>
|
|
|
|
#include <ws/ppu/ppu.hpp>
|
|
|
|
#include <ws/apu/apu.hpp>
|
Update to v097r28 release.
byuu says:
Changelog: (all WSC unless otherwise noted)
- fixed LINECMP=0 interrupt case (fixes FF4 world map during airship
sequence)
- improved CPU timing (fixes Magical Drop flickering and FF1 battle
music)
- added per-frame OAM caching (fixes sprite glitchiness in Magical Drop,
Riviera, etc.)
- added RTC emulation (fixes Dicing Knight and Judgement Silversword)
- added save state support
- added cheat code support (untested because I don't know of any cheat
codes that exist for this system)
- icarus: can now detect games with RTC chips
- SFC: bugfix to SharpRTC emulation (Dai Kaijuu Monogatari II)
- ( I was adding the extra leap year day to all 12 months instead of
just February ... >_< )
Note that the RTC emulation is very incomplete. It's not really
documented at all, and the two games I've tried that use it never even
ask you to set the date/time (so they're probably just using it to count
seconds.) I'm not even sure if I've implement the level-sensitive
behavior correctly (actually, now that I think about it, I need to mask
the clear bit in INT_ACK for the level-sensitive interrupts ...)
A bit worried about the RTC alarm, because it seems like it'll fire
continuously for a full minute. Or even if you turn it off after it
fires, then that doesn't seem to be lowering the line until the next
second ticks on the RTC, so that likely needs to happen when changing
the alarm flag.
Also not sure on this RTC's weekday byte. On the SharpRTC, it actually
computes this for you. Because it's not at all an easy thing to
calculate yourself in 65816 or V30MZ assembler. About 40 lines of code
to do it in C. For now, I'm requiring the program to calculate the value
itself.
Also note that there's some gibberish tiles in Judgement Silversword,
sadly. Not sure what's up there, but the game's still fully playable at
least.
Finally, no surprise: Beat-Mania doesn't run :P
2016-03-25 06:19:08 +00:00
|
|
|
#include <ws/cheat/cheat.hpp>
|
2016-01-27 11:31:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#include <ws/interface/interface.hpp>
|