mirror of https://github.com/bsnes-emu/bsnes.git
29 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
Tim Allen
|
53843934c0 |
Update to v106r84 release.
byuu says:
Changelog:
- fixed a few TLCS900H CPU and disassembler bugs
- hooked up a basic Neo Geo Pocket emulator skeleton and memory map;
can run a few instructions from the BIOS
- emulated the flash memory used by Neo Geo Pocket games
- added sourcery to the higan source archives
- fixed ternary expressions in sfc/ppu-fast [hex_usr]
|
|
|
Tim Allen
|
22bd4b9277 |
Update to v106r52 release.
byuu says: I stand corrected, I managed to create and even larger diff than ever. This one weighs in at 309KiB `>__>` I'll have to create a changelog later, I'm too tired right now to go through all of that. |
|
|
Tim Allen
|
35ff15f83e |
Update to v106r50 release.
byuu says:
Changelog:
- emulator/video,audio: various cleanups
- emulator/audio: removed reverb effect (it breaks very badly on
high-frequency systems)
- emulator/audio: the Nyquist anti-aliasing lowpass filter is now
generated automatically instead of set per-core
- at 44.1KHz output, it's set to 22KHz; at 48KHz, it's set to
22KHz; at 96KHz, it's set to 25KHz
- this filter now takes the bsnes emulation speed setting into
account
- all system/video.cpp files removed; inlined in System::power() and
Interface::set() instead
- sfc/cpu: pre-compute `HTIME` as `HTIME+1<<2` for faster comparisons of
HIRQs
- sfc/cpu: re-add check to block IRQs on the last dot of each frame
(minor speed hit)
- hiro/gtk3: fixed headers for Linux compilation finally
- hiro/gtk,qt: fixed settings.cpp logic so initial values are used
when no settings.bml file exists
- hiro/gtk: started a minor experiment to specify theming information
in settings.bml files
- nall/dsp: allow the precision type (double) to be overridden (to
float)
- nall: add some helpers for generating pre-compiled headers
- it was a failure to try using them for higan, however ...
- nall: add some helpers for reading fallback values from empty
`Markup::Node[search]` statements
Todo:
- CRITICAL: a lot of my IRQ/NMI/HDMA timing tests are failing with the
fast PPU ... need to figure out why
- space between Emulator::video functions and Emulator::audio
functions in gb/system/system.cpp
- remove Audio/Reverb/Enable from settings.bml in target-bsnes
|
|
|
Tim Allen
|
8617711ea2 |
Update to v106r17 release.
byuu says:
Changelog:
- tomoko: the library menu is now called the systems menu (even in
code)
- tomoko: added icons to menus (disambiguates systems menu entries)
- icarus: added missing .ws, .wsc extensions to scan dialog search
list
- higan: added Benesse - Pocket Challenge V2 emulation¹
¹: the Benesse - Pocket Challenge V2 is a WonderSwan (ASWAN) SoC
inside a custom designed shell. Games made for the WonderSwan (mostly)
run on the Pocket Challenge V2 and vice versa. The big difference is
that the Benesse has a different number of input buttons, that are also
named differently. Of course, right now, I don't know what the buttons
are named or where they're mapped on the 16-input keypad matrix I/O
port. It's also possible that the internal EEPROM doesn't exist, it
definitely has a unique (and also undumped) IPLROM, and other things.
The ROMs have their own .pc2 file extension. So it's getting its own
system entry.
What I'm going to do for v107 and above is utilize the new systems
configuration to mark the Benesse as hidden by default from the main
menu. I don't think anyone in the world will actually care or want to
play this, but there was really no reason not to add it.
|
|
|
Tim Allen
|
8f61c267c5 |
Update to v106r14 release.
byuu says:
Changelog:
- game/memory/type/battery → game/memory/volatile
- (manufacturer.)content.type → (architecture.)content.type
- nall: Markup::find() strips spaces from values in comparisons
- higan: updated game manifest loading/saving code for all cores
- GBA: flash memory ID is internally selected based on the
manufacturer and memory size
- SFC: ST018 (ARM6) frequency can be modified via game manifest now
- WS: EEPROM::name removed (not useful)
- icarus, genius: battery→volatile updates
I did my best to look over the diff between r13 and r14, but it's 84KiB
excluding the game database changes. It's just too much for me. I'd
greatly appreciate if someone could look over it and check for any
errors in this update. But more than likely, I suppose we'll iron out
any issues by determining which games fail to load.
Right now, I know the Super Game Boy support doesn't seem to work. But
all non-SFC cores should work fully, and all normal + NEC DSP SFC games
should work as well. Unsure about the rest.
Also, I'm planning to change the Game Boy “MBC1M” mapper to “MBC1#A” to
indicate it's an alternate wiring configuration of the stock MBC1, and
not a new mapper type.
|
|
|
Tim Allen
|
afa8ea61c5 |
Update to v104r06 release.
byuu says:
Changelog:
- gba,ws: removed Thread::step() override¹
- processor/m68k: move.b (a7)+ and move.b (a7)- adjust a7 by two, not
by one²
- tomoko: created new initialize(Video,Audio,Input)Driver() functions³
- ruby/audio: split Audio::information into
Audio::available(Devices,Frequencies,Latencies,Channels)³
- ws: added Model::(WonderSwan,WonderSwanColor,SwanCrystal)()
functions for consistency with other cores
¹: this should hopefully fix GBA Pokemon Pinball. Thanks to
SuperMikeMan for pointing out the underlying cause.
²: this fixes A Ressaha de Ikou, Mega Bomberman, and probably more
games.
³: this is the big change: so there was a problem with WASAPI where
you might change your device under the audio settings panel. And your
new device may not support the frequency that your old device used. This
would end up not updating the frequency, and the pitch would be
distorted.
The old Audio::information() couldn't tell you what frequencies,
latencies, or channels were available for all devices simultaneously, so
I had to split them up. The new initializeAudioDriver() function
validates you have a correct driver, or it defaults to none. Then it
validates a correct device name, or it defaults to the first entry in
the list. Then it validates a correct frequency, or defaults to the
first in the list. Then finally it validates a correct latency, or
defaults to the first in the list.
In this way ... we have a clear path now with no API changes required to
select default devices, frequencies, latencies, channel counts: they
need to be the first items in their respective lists.
So, what we need to do now is go through and for every audio driver that
enumerates devices, we need to make sure the default device gets added
to the top of the list. I'm ... not really sure how to do this with most
drivers, so this is definitely going to take some time.
Also, when you change a device, initializeAudioDriver() is called again,
so if it's a bad device, it will disable the audio driver instead of
continuing to send samples at it and hoping that the driver blocked
those API calls when it failed to initialize properly.
Now then ... since it was a decently-sized API change, it's possible
I've broken compilation of the Linux drivers, so please report any
compilation errors so that I can fix them.
|
|
|
Tim Allen
|
8af3e4a6e2 |
Update to v102r22 release.
byuu says:
Changelog:
- higan: Emulator::Interface::videoSize() renamed to videoResolution()
- higan: Emulator::Interface::rtcsync() renamed to rtcSynchronize()
- higan: added video display rotation support to Video
- GBA: substantially improved audio mixing
- fixed bug with FIFO 50%/100% volume setting
- now properly using SOUNDBIAS amplitude to control output
frequencies
- reduced quantization noise
- corrected relative volumes between PSG and FIFO channels
- both PSG and FIFO values cached based on amplitude; resulting in
cleaner PCM samples
- treating PSG volume=3 as 200% volume instead of 0% volume now
(unverified: to match mGBA)
- GBA: properly initialize ALL CPU state; including the vital
prefetch.wait=1 (fixes Classic NES series games)
- GBA: added video rotation with automatic key translation support
- PCE: reduced output resolution scalar from 285x242 to 285x240
- the extra two scanlines won't be visible on most TVs; and they
make all other cores look worse
- this is because all other cores output at 240p or less; so they
were all receiving black bars in windowed mode
- tomoko: added "Rotate Display" hotkey setting
- tomoko: changed hotkey multi-key logic to OR instead of AND
- left support for flipping it back inside the core; for those so
inclined; by uncommenting one line in input.hpp
- tomoko: when choosing Settings→Configuration, it will
automatically select the currently loaded system
- for instance, if you're playing a Game Gear game, it'll take you
to the Game Gear input settings
- if no games are loaded, it will take you to the hotkeys panel
instead
- WS(C): merged "Hardware-Vertical", "Hardware-Horizontal" controls
into combined "Hardware"
- WS(C): converted rotation support from being inside the core to
using Emulator::Video
- this lets WS(C) video content scale larger now that it's not
bounded by a 224x224 square box
- WS(C): added automatic key rotation support
- WS(C): removed emulator "Rotate" key (use the general hotkey
instead; I recommend F8 for this)
- nall: added serializer support for nall::Boolean (boolean) types
- although I will probably prefer the usage of uint1 in most cases
|
|
|
Tim Allen
|
bf90bdfcc8 |
Update to v101r31 release.
byuu says:
Changelog:
- converted Emulator::Interface::Bind to Emulator::Platform
- temporarily disabled SGB hooks
- SMS: emulated Game Gear palette (latching word-write behavior not
implemented yet)
- SMS: emulated Master System 'Reset' button, Game Gear 'Start' button
- SMS: removed reset() functionality, driven by the mappable input now
instead
- SMS: split interface class in two: one for Master System, one for
Game Gear
- SMS: emulated Game Gear video cropping to 160x144
- PCE: started on HuC6280 CPU core—so far only registers, NOP
instruction has been implemented
Errata:
- Super Game Boy support is broken and thus disabled
- if you switch between Master System and Game Gear without
restarting, bad things happen:
- SMS→GG, no video output on the GG
- GG→SMS, no input on the SMS
I'm not sure what's causing the SMS\<-\>GG switch bug, having a hard
time debugging it. Help would be very much appreciated, if anyone's up
for it. Otherwise I'll keep trying to track it down on my end.
|
|
|
Tim Allen
|
79c83ade70 |
Update to v101r29 release.
byuu says:
Changelog:
- SMS: background VDP clips partial tiles on the left (math may not be
right ... it's hard to reason about)
- SMS: fix background VDP scroll locks
- SMS: fix VDP sprite coordinates
- SMS: paint black after the end of the visible display
- todo: shouldn't be a brute force at the end of the main VDP
loop, should happen in each rendering unit
- higan: removed emulator/debugger.hpp
- higan: removed privileged: access specifier
- SFC: removed debugger hooks
- todo: remove sfc/debugger.hpp
- Z80: fixed disassembly of (fd,dd) cb (displacement) (opcode)
instructions
- Z80: fix to prevent interrupts from firing between ix/iy prefixes
and opcodes
- todo: this is a rather hacky fix that could, if exploited, crash
the stack frame
- Z80: fix BIT flags
- Z80: fix ADD hl,reg flags
- Z80: fix CPD, CPI flags
- Z80: fix IND, INI flags
- Z80: fix INDR, INIT loop flag check
- Z80: fix OUTD, OUTI flags
- Z80: fix OTDR, OTIR loop flag check
|
|
|
Tim Allen
|
ca277cd5e8 |
Update to v100r14 release.
byuu says:
(Windows: compile with -fpermissive to silence an annoying error. I'll
fix it in the next WIP.)
I completely replaced the time management system in higan and overhauled
the scheduler.
Before, processor threads would have "int64 clock"; and there would
be a 1:1 relationship between two threads. When thread A ran for X
cycles, it'd subtract X * B.Frequency from clock; and when thread B ran
for Y cycles, it'd add Y * A.Frequency from clock. This worked well
and allowed perfect precision; but it doesn't work when you have more
complicated relationships: eg the 68K can sync to the Z80 and PSG; the
Z80 to the 68K and PSG; so the PSG needs two counters.
The new system instead uses a "uint64 clock" variable that represents
time in attoseconds. Every time the scheduler exits, it subtracts
the smallest clock count from all threads, to prevent an overflow
scenario. The only real downside is that rounding errors mean that
roughly every 20 minutes, we have a rounding error of one clock cycle
(one 20,000,000th of a second.) However, this only applies to systems
with multiple oscillators, like the SNES. And when you're in that
situation ... there's no such thing as a perfect oscillator anyway. A
real SNES will be thousands of times less out of spec than 1hz per 20
minutes.
The advantages are pretty immense. First, we obviously can now support
more complex relationships between threads. Second, we can build a
much more abstracted scheduler. All of libco is now abstracted away
completely, which may permit a state-machine / coroutine version of
Thread in the future. We've basically gone from this:
auto SMP::step(uint clocks) -> void {
clock += clocks * (uint64)cpu.frequency;
dsp.clock -= clocks;
if(dsp.clock < 0 && !scheduler.synchronizing()) co_switch(dsp.thread);
if(clock >= 0 && !scheduler.synchronizing()) co_switch(cpu.thread);
}
To this:
auto SMP::step(uint clocks) -> void {
Thread::step(clocks);
synchronize(dsp);
synchronize(cpu);
}
As you can see, we don't have to do multiple clock adjustments anymore.
This is a huge win for the SNES CPU that had to update the SMP, DSP, all
peripherals and all coprocessors. Likewise, we don't have to synchronize
all coprocessors when one runs, now we can just synchronize the active
one to the CPU.
Third, when changing the frequencies of threads (think SGB speed setting
modes, GBC double-speed mode, etc), it no longer causes the "int64
clock" value to be erroneous.
Fourth, this results in a fairly decent speedup, mostly across the
board. Aside from the GBA being mostly a wash (for unknown reasons),
it's about an 8% - 12% speedup in every other emulation core.
Now, all of this said ... this was an unbelievably massive change, so
... you know what that means >_> If anyone can help test all types of
SNES coprocessors, and some other system games, it'd be appreciated.
----
Lastly, we have a bitchin' new about screen. It unfortunately adds
~200KiB onto the binary size, because the PNG->C++ header file
transformation doesn't compress very well, and I want to keep the
original resource files in with the higan archive. I might try some
things to work around this file size increase in the future, but for now
... yeah, slightly larger archive sizes, sorry.
The logo's a bit busted on Windows (the Label control's background
transparency and alignment settings aren't working), but works well on
GTK. I'll have to fix Windows before the next official release. For now,
look on my Twitter feed if you want to see what it's supposed to look
like.
----
EDIT: forgot about ICD2::Enter. It's doing some weird inverse
run-to-save thing that I need to implement support for somehow. So, save
states on the SGB core probably won't work with this WIP.
|
|
|
Tim Allen
|
76a8ecd32a |
Update to v100r03 release.
byuu says: Changelog: - moved Thread, Scheduler, Cheat functionality into emulator/ for all cores - start of actual Mega Drive emulation (two 68K instructions) I'm going to be rather terse on MD emulation, as it's too early for any meaningful dialogue here. |
|
|
Tim Allen
|
88c79e56a0 |
Update to v100r01 release.
[This version, with the internal version number changed back to "v100",
replaced the original v100 source archive on byuu.org soon after v100's
release, because it fixes important bugs in that version. --Ed]
byuu says:
Changelog:
- fixed default paths for Sufami Turbo slotted games
- moved WonderSwan orientation controls to the port rather than the device
- I do like hex_usr's idea here; but that'll need more consideration;
so this is a temporary fix
- added new debugger interface (see the public topic for more on that)
|
|
|
Tim Allen
|
f48b332c83 |
Update to v099r08 release.
byuu says:
Changelog:
- nall/vfs work 100% completed; even SGB games load now
- emulation cores now call load() for the base cartridges as well
- updated port/device handling; portmask is gone; device ID bug should
be resolved now
- SNES controller port 1 multitap option was removed
- added support for 128KiB SNES PPU VRAM (for now, edit sfc/ppu/ppu.hpp
VRAM::size=0x10000; to enable)
Overall, nall/vfs was a huge success!! We've substantially reduced
the amount of boilerplate code everywhere, while still allowing (even
easier than before) support for RAM-based game loading/saving. All of
nall/stream is dead and buried.
I am considering removing Emulator::Interface::Medium::id and/or
bootable flag. Or at least, doing something different with it. The
values for the non-bootable GB/BS/ST entries duplicate the ID that is
supposed to be unique. They are for GB/GBC and WS/WSC. Maybe I'll use
this as the hardware revision selection ID, and then gut non-bootable
options. There's really no reason for that to be there. I think at one
point I was using it to generate library tabs for non-bootable systems,
but we don't do that anymore anyway.
Emulator::Interface::load() may not need the required flag anymore ... it
doesn't really do anything right now anyway.
I have a few reasons for having the cores load the base cartridge. Most
importantly, it is going to enable a special mode for the WonderSwan /
WonderSwan Color in the future. If we ever get the IPLROMs dumped ... it's
possible to boot these systems with no games inserted to set user profile
information and such. There are also other systems that may accept being
booted without a cartridge. To reach this state, you would load a game and
then cancel the load dialog. Right now, this results in games not loading.
The second reason is this prevents nasty crashes when loading fails. So
if you're missing a required manifest, the emulator won't die a violent
death anymore. It's able to back out at any point.
The third reason is consistency: loading the base cartridge works the
same as the slot cartridges.
The fourth reason is Emulator::Interface::open(uint pathID)
values. Before, the GB, SB, GBC modes were IDs 1,2,3 respectively. This
complicated things because you had to pass the correct ID. But now
instead, Emulator::Interface::load() returns maybe<uint> that is nothing
when no game is selected, and a pathID for a valid game. And now open()
can take this ID to access this game's folder contents.
The downside, which is temporary, is that command-line loading is
currently broken. But I do intend on restoring it. In fact, I want to do
better than before and allow multi-cart booting from the command-line by
specifying the base cartridge and then slot cartridges. The idea should
be pretty simple: keep a queue of pending filenames that we fill from
the command-line and/or drag-and-drop operations on the main window,
and then empty out the queue or prompt for load dialogs from the UI
when booting a system. This also might be a bit more unorthodox compared
to the traditional emulator design of "loadGame(filename)", but ... oh
well. It's easy enough still.
The port/device changes are fun. We simplified things quite a bit. The
portmask stuff is gone entirely. While ports and devices keep IDs,
this is really just sugar-coating so UIs can use for(auto& port :
emulator->ports) and access port.id; rather than having to use for(auto
n : range(emulator->ports)) { auto& port = emulator->ports[n]; ... };
but they should otherwise generally be identical to the order they appear
in their respective ranges. Still, don't rely on that.
Input::id is gone. There was no point since we also got rid of the nasty
Input::order vector. Since I was in here, I went ahead and caved on the
pedantics and renamed Input::guid to Input::userData.
I removed the SNES controller port 1 multitap option. Basically, the only
game that uses this is N-warp Daisakusen and, no offense to d4s, it's
not really a good game anyway. It's just a quick demo to show 8-players
on the SNES. But in the UI, all it does is confuse people into wasting
time mapping a controller they're never going to use, and they're going
to wonder which port to use. If more compelling use cases for 8-players
comes about, we can reconsider this. I left all the code to support this
in place, so all you have to do is uncomment one line to enable it again.
We now have dsnes emulation! :D
If you change PPU::VRAM::size to 0x10000 (words), then you should now
have 128KiB of VRAM. Even better, it serializes the used-VRAM size,
so your save states shouldn't crash on you if you swap between the two
(though if you try this, you're nuts.)
Note that this option does break commercial software. Yoshi's Island in
particular. This game is setting A15 on some PPU register writes, but
not on others. The end result of this is things break horribly in-game.
Also, this option is causing a very tiny speed hit for obvious reasons
with the variable masking value (I'm even using size-1 for now.) Given
how niche this is, I may just leave it a compile-time constant to avoid
the overhead cost. Otherwise, if we keep the option, then it'll go into
Super Famicom.sys/manifest.bml ... I'll flesh that out in the near-future.
----
Finally, some fun for my OCD ... my monitor suddenly cut out on me
in the middle of working on this WIP, about six hours in of non-stop
work. Had to hit a bunch of ctrl+alt+fN commands (among other things)
and trying to log in headless on another TTY to do issue commands,
trying to recover the display. Finally power cycled the monitor and it
came back up. So all my typing ended up going to who knows where.
Usually this sort of thing terrifies me enough that I scrap a WIP and
start over to ensure I didn't screw anything up during the crashed screen
when hitting keys randomly.
Obviously, everything compiles and appears to work fine. And I know
it's extremely paranoid, but OCD isn't logical, so ... I'm going
to go over every line of the 100KiB r07->r08 diff looking for any
corruption/errors/whatever.
----
Review finished.
r08 diff review notes:
- fc/controller/gamepad/gamepad.cpp:
use uint device = ID::Device::Gamepad; not id = ...;
- gb/cartridge/cartridge.hpp:
remove redundant uint _pathID; (in Information::pathID already)
- gb/cartridge/cartridge.hpp:
pull sha256 inside Information
- sfc/cartridge/load/cpp:
add " - Slot (A,B)" to interface->load("Sufami Turbo"); to be more
descriptive
- sfc/controller/gamepad/gamepad.cpp:
use uint device = ID::Device::Gamepad; not id = ...;
- sfc/interface/interface.cpp:
remove n variable from the Multitap device input generation loop
(now unused)
- sfc/interface/interface.hpp:
put struct Port above struct Device like the other classes
- ui-tomoko:
cheats.bml is reading from/writing to mediumPaths(0) [system folder
instead of game folder]
- ui-tomoko:
instead of mediumPaths(1) - call emulator->metadataPathID() or something
like that
|
|
|
Tim Allen
|
ccd8878d75 |
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.
|
|
|
Tim Allen
|
e2ee6689a0 |
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.
|
|
|
Tim Allen
|
a2d3b8ba15 |
Update to v098r04 release.
byuu says: Changelog: - SFC: fixed behavior of 21fx $21fe register when no device is connected (must return zero) - SFC: reduced 21fx buffer size to 1024 bytes in both directions to mirror the FT232H we are using - SFC: eliminated dsp/modulo-array.hpp [1] - higan: implemented higan/video interface and migrated all cores to it [2] [1] the echo history buffer was 8-bytes, so there was no need for it at all here. Not sure what I was thinking. The BRR buffer was 12-bytes, and has very weird behavior ... but there's only a single location in the code where it actually writes to this buffer. It's much easier to just write to the buffer three times there instead of implementing an entire class just to abstract away two lines of code. This change actually boosted the speed from ~124.5fps to around ~127.5fps, but that's within the margin of error for GCC. I doubt it's actually faster this way. The DSP core could really use a ton of work. It comes from a port of blargg's spc_dsp to my coding style, but he was extremely fond of using 32-bit signed integers everywhere. There's a lot of opportunity to remove red tape masking by resizing the variables to their actual state sizes. I really need to find where I put spc_dsp6.sfc from blargg. It's a great test to verify if I've made any mistakes in my implementation that would cause regressions. Don't suppose anyone has it? [2] so again, the idea is that higan/audio and higan/video are going to sit between the emulation cores and the user interfaces. The hope is to output raw encoding data from the emulation cores without having to worry about the video display format (generally 24-bit RGB) of the host display. And also to avoid having to repeat myself with eg three separate implementations of interframe blending, and so on. Furthermore, the idea is that the user interface can configure its side of the settings, and the emulation cores can configure their sides. Thus, neither has to worry about the other end. And now we can spin off new user interfaces much easier without having to mess with all of these things. Right now, I've implemented color emulation, interframe blending and SNES horizontal color bleed. I did not implement scanlines (and interlace effects for them) yet, but I probably will at some point. Further, for right now, the WonderSwan/Color screen rotation is busted and will only show games in the horizontal orientation. Obviously this must be fixed before the next official release, but I'll want to think about how to implement it. Also, the SNES light gun pointers are missing for now. Things are a bit messy right now as I've gone through several revisions of how to handle these things, so a good house cleaning is in order once everything is feature-complete again. I need to sit down and think through how and where I want to handle things like light gun cursors, LCD icons, and maybe even rasterized text messages. And obviously ... higan/audio is still just nall::DSP's headers. I need to revamp that whole interface. I want to make it quite powerful with a true audio mixer so I can handle things like SNES+SGB+MSU1+Voicer-Kun+SNES-CD (five separate audio streams at once.) The video system has the concept of "effects" for things like color bleed and interframe blending. I want to extend on this with useful other effects, such as NTSC simulation, maybe bringing back my mini-HQ2x filter, etc. I'd also like to restore the saturation/gamma/luma adjustment sliders ... I always liked allowing people to compensate for their displays without having to change settings system-wide. Lastly, I've always wanted to see some audio effects. Although I doubt we'll ever get my dream of CoreAudio-style profiles, I'd like to get some basic equalizer settings and echo/reverb effects in there. |
|
|
Tim Allen
|
2d83300235 |
Update to v097r30 release.
byuu says: Changelog: - fixed sprite window attribute bit (Final Fantasy, Tekken Card Challenge, etc) - rewrote renderer to support 2bpp color mode (Dark Eyes, Dokodemo Hamster, Flash Koibito-kun, etc) |
|
|
Tim Allen
|
680d16561e |
Update to v097r29 release.
byuu says:
Changelog:
- fixed DAS instruction (Judgment Silversword score)
- fixed [VH]TMR_FREQ writes (Judgement Silversword audio after area 20)
- fixed initialization of SP (fixes seven games that were hanging on
startup)
- added SER_STATUS and SER_DATA stubs (fixes four games that were
hanging on startup)
- initialized IEEP data (fixes Super Robot Taisen Compact 2 series)
- note: you'll need to delete your internal.com in WonderSwan
(Color).sys folders
- fixed CMPS and SCAS termination condition (fixes serious bugs in four
games)
- set read/writeCompleted flags for EEPROM status (fixes Tetsujin 28
Gou)
- major code cleanups to SFC/R65816 and SFC/CPU
- mostly refactored disassembler to output strings instead of using
char* buffer
- unrolled all the subfolders on sfc/cpu to a single directory
- corrected casing for all of sfc/cpu and a large portion of
processor/r65816
I kind of went overboard on the code cleanup with this WIP. Hopefully
nothing broke. Any testing one can do with the SFC accuracy core would
be greatly appreciated.
There's still an absolutely huge amount of work left to go, but I do
want to eventually refresh the entire codebase to my current coding
style, which is extremely different from stuff that's been in higan
mostly untouched since ~2006 or so. It's dangerous and fickle work, but
if I don't do it, then the code will be a jumbled mess of several
different styles.
|
|
|
Tim Allen
|
379ab6991f |
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
|
|
|
Tim Allen
|
d3413db04a |
Update to v097r27 release.
byuu says: Absolutely major improvements to the WS/C emulation today. Changelog: (all WS/C related) - fixed channel 3 sweep pitch adjustment - fixed channel 3 sweep value sign extension - removed errant channel 5 speed setting (not what's really going on) - fixed sign extension on channel 5 samples - improved DAC mixing of all five audio channels - fixed r26 regression with PPU timing loop - fixed sprite windowing behavior (sprite attribute flag is window mode; not window enable) - added per-scanline register latching to the PPU - IRQs should terminate HLT even when the IRQ enable register bits are clear - fixed PALMONO reads - added blur emulation - added color emulation (based on GBA, so it heavily desaturates colors; not entirely correct, but it helps a lot) - no longer decimating audio to 24KHz; running at full 3.072MHz through the windowed sinc filter [1] - cleaned up PPU portRead / portWrite functions significantly - emulated a weird quirk as mentioned by trap15 regarding timer frequency writes enabling said timers [2] - emulated LCD_CTRL sleep bit; screen can now be disabled (always draws black in this case for now) - improved OAM caching; but it's still disabled because it causes huge amounts of sprite glitches (unsure why) - fixed rendering of sprites that wrap around the screen edges back to the top/left of the display - emulated keypad interrupts - icarus: detect orientation bit in game header - higan: use orientation setting in manifest to set default screen rotation [1] the 24KHz -> 3.072MHz sound change is huge. Sound is substantially improved over the previous WIPs. It does come at a pretty major speed penalty, though. This is the highest frequency of any system in higan running through an incredibly (amazing, yet) demanding sinc resampler. Frame rate dropped from around 240fps to 150fps with the sinc filter on. If you choose a different audio filter, you'll get most of that speed back, but audio will sound worse again. [2] we aren't sure if this is correct hardware behavior or not. It seems to very slightly help Magical Drop, but not much. The blur emulation is brutal. It's absolutely required for Riviera's translucency simulation of selected menu items, but it causes serious headaches due to the WS's ~75hz refresh rate running on ~60hz monitors without vsync. It's probably best to leave it off and just deal with the awful flickering on Riviera's menu options. Overall, WS/C emulation is starting to get quite usable indeed. Couple of major bugs that I'd really like to get fixed before releasing it, though. But they're getting harder and harder to fix ... Major Bugs: - Final Fantasy battle background music is absent. Sound effects still work. Very weird. - Final Fantasy IV scrolling during airship flight opening sequence is horribly broken. Scrolls one screen at a time. - Magical Drop flickers like crazy in-game. Basically unplayable like this. - Star Hearts character names don't appear in the smaller dialog box that pops up. Minor Bugs: - Occasional flickering during Riviera opening scenes. - One-frame flicker of Leda's sprite at the start of the first stage. |
|
|
Tim Allen
|
a7f7985581 |
Update to v097r26 release.
byuu says: Changelog: - WS: fixed 8-bit sign-extended imul (fixes Star Hearts completely, Final Fantasy world map) - WS: fixed rcl/rcr carry shifting (fixes Crazy Climber, others) - WS: added sound DMA emulation (Star Hearts rain sound for one example) - WS: added OAM caching, but it's forced every line for now because otherwise there are too many sprite glitches - WS: use headphoneEnable bit instead of speakerEnable bit (fixes muted audio in games) - WS: various code cleanups (I/O mapping, audio channel naming, etc) The hypervoice channel doesn't sound all that great just yet. But I'm not sure how it's supposed to sound. I need a better example of some more complex music. What's left are some unknown register status bits (especially in the sound area), keypad interrupts, RTC emulation, CPU prefetch emulation. And then it's all just bugs. Lots and lots of bugs that need to be fixed. EDIT: oops, bad typo in the code. ws/ppu/ppu.cpp line 20: change range(256) to range(224). Also, delete the r.speed stuff from channel5.cpp to make the rain sound a lot better in Star Hearts. Apparently that's outdated and not what the bits really do. |
|
|
Tim Allen
|
c33065fbd1 |
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. |
|
|
Tim Allen
|
3d3ac8c1db |
Update to v097r22 release.
byuu says: Changelog: - WS: fixed lods, scas instructions - WS: implemented missing GRP4 instructions - WS: fixed transparency for screen one - WSC: added color-mode PPU rendering - WS+WSC: added packed pixel mode support - WS+WSC: added dummy sound register reads/writes - SFC: added threading to SuperDisc (it's hanging for right now; need to clear IRQ on $21e2 writes) SuperDisc Timer and Sound Check were failing before due to not turning off IRQs on $21e4 clear, so I'm happy that's fixed now. Riviera starts now, and displays the first intro screen before crashing. Huge, huge amounts of corrupted graphics, though. This game's really making me work for it :( No color games seem fully playable yet, but a lot of monochrome and color games are now at least showing more intro screen graphics before dying. This build defaults to horizontal orientation, but I left the inputs bound to vertical orientation. Whoops. I still need to implement a screen flip key binding. |
|
|
Tim Allen
|
b0d2f5033e |
Update to v097r21 release.
byuu says: Changelog: - icarus: WS/C detects RAM type/size heuristically now - icarus: WS/C uses ram type=$type instead of $type - WS: use back color instead of white for backdrop - WS: fixed sprite count limit; removes all the garbled sprites from GunPey - WS: hopefully fixed sprite priority with screen 2 - WS: implemented keypad polling; GunPey is now fully playable - SNES: added Super Disc expansion port device (doesn't do anything, just for testing) Note: WS is hard-coded to vertical orientation right now. But there's basic code in there for all the horizontal stuff. |
|
|
Tim Allen
|
810cbdafb4 |
Update to v097r16 release.
byuu says: Changelog: - sfc/ppu/sprite updated to use new .bit(s) functions; masked sizes better; added valid flags instead of using magic numbers - ws/ppu updates to use new .bit(s) functions - ws/ppu: added line compare interrupt support - added ws/eeprom; emulation of WS/WSC internal EEPROM and cartridge EEPROM (1kbit - 16kbit supported) - added basic read/write handlers for remaining WS/WSC PPU registers WS EEPROM emulation is basically a direct copy of trap15's code. Still some unknown areas in there, but hopefully it's enough to get further into games that depend on EEPROM support. Note that you'll have to manually add the eeprom line to the manifest for now, as icarus doesn't know how to detect EEPROM/sizes yet. I figured the changes to the SNES PPU sprites would slow it down a tad, but it actually sped it up. Most of the impact from the integer classes are gone now. |
|
|
Tim Allen
|
6c83329cae |
Update to v097r13 release.
byuu says: I refactored my schedulers. Added about ten lines to each scheduler, and removed about 100 lines of calling into internal state in the scheduler for the FC,SFC cores and about 30-40 lines for the other cores. All of its state is now private. Also reworked all of the entry points to static auto Enter() and auto main(). Where Enter() handles all the synchronization stuff, and main() doesn't need the while(true); loop forcing another layer of indentation everywhere. Took a few hours to do, but totally worth it. I'm surprised I didn't do this sooner. Also updated icarus gmake install rule to copy over the database. |
|
|
Tim Allen
|
32a95a9761 |
Update to v097r12 release.
byuu says: Nothing WS-related this time. First, I fixed expansion port device mapping. On first load, it was mapping the expansion port device too late, so it ended up not taking effect. I had to spin out the logic for that into Program::connectDevices(). This was proving to be quite annoying while testing eBoot (SNES-Hook simulation.) Second, I fixed the audio->set(Frequency, Latency) functions to take (uint) parameters from the configuration file, so the weird behavior around changing settings in the audio panel should hopefully be gone now. Third, I rewrote the interface->load,unload functions to call into the (Emulator)::System::load,unload functions. And I have those call out to Cartridge::load,unload. Before, this was inverted, and Cartridge::load() was invoking System::load(), which I felt was kind of backward. The Super Game Boy really didn't like this change, however. And it took me a few hours to power through it. Before, I had the Game Boy core dummying out all the interface->(load,save)Request calls, and having the SNES core make them for it. This is because the folder paths and IDs will be different between the two cores. I've redesigned things so that ICD2's Emulator::Interface overloads loadRequest and saveRequest, and translates the requests into new requests for the SuperFamicom core. This allows the Game Boy code to do its own loading for everything without a bunch of Super Game Boy special casing, and without any awkwardness around powering on with no cartridge inserted. This also lets the SNES side of things simply call into higher-level GameBoy::interface->load,save(id, stream) functions instead of stabbing at the raw underlying state inside of various Game Boy core emulation classes. So things are a lot better abstracted now. |
|
|
Tim Allen
|
a8323d0d2b |
Update to v097r04 release.
byuu says: Lots of improvements. We're now able to start executing some V30MZ instructions. 32 of 256 opcodes implemented so far. I hope this goes without saying, but there's absolutely no point in loading WS/WSC games right now. You won't see anything until I have the full CPU and partial PPU implemented. ROM bank 2 works properly now, the I/O map is 16-bit (address) x 16-bit (data) as it should be*, and I have a basic disassembler in place (adding to it as I emulate new opcodes.) (* I don't know what happens if you access an 8-bit port in 16-bit mode or vice versa, so for now I'm just treating the handlers as always being 16-bit, and discarding the upper 8-bits when not needed.) |
|
|
Tim Allen
|
d7998b23ef |
Update to v097r03 release.
byuu says: So, this WIP starts work on something new for higan. Obviously, I can't keep it a secret until it's ready, because I want to continue daily WIP releases, and of course, solicit feedback as I go along. |