mirror of https://github.com/bsnes-emu/bsnes.git
137 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
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
|
985610c167 |
Update to v106r12 release.
byuu says:
Changelog:
- Emulator: update to final manifest syntax
- Super Famicom: new board syntax (still experimental)
- Super Famicom: match (manufacturer.)category.type instead of
(model.)category.type
Errata:
- Markup::Node::find() needs to be extended to support multiple
subtype matches
- Sufami Turbo ROM/RAM nodes are part of separate gamepaks; need to
refactor this
|
|
|
Tim Allen
|
2dd35f984d |
Update to v106r10 release.
byuu says:
Changelog:
- manifest: memory/battery now resides under type at
memory/type/battery
- genius: volatile option changed to battery; auto-disables when not
RAM or RTC type
- higan: added new Emulator::Game class to parse manifests for all
emulated systems consistently
- Super Famicom: board manifest appended to manifest viewer now
- Super Famicom: cartridge class updated to use Emulator::Game objects
- hiro: improve suppression of userland callbacks once
Application::quit() is called
- this fixes a crash in genius when closing the window with a tree
view item selected
My intention is to remove Emulator::Interface::sha256(), as it's not
really useful. They'll be removed from save states as well. I never
bothered validating the SHA256 within them, because that'd be really
annoying for ROM hackers.
I also intend to rename Emulator::Interface::title() to label() instead.
Most everything is still broken. The SNES still needs all the board
definitions updated, all the other cores need to move to using
Emulator::Game.
|
|
|
Tim Allen
|
e216912ca3 |
Update to v106r09 release.
byuu says: Changelog: - higan, icarus, genius: new manifest syntax (work in progress) Pretty much only LoROM and HiROM SNES games will load right now, and RAM will only work right if the save.ram file already exists to pull its file size from (a temporary cheap hack was used.) Basically, I'm just getting this out there for evaluation. One minor errata is that I switched icarus to using “memory/battery” to indicate battery-backed RAM, whereas genius still uses “memory/volatile” to indicate non-battery-backed RAM. I intend to make it “memory/battery” in genius, and have the field auto-enable when RAM or RTC is selected for type (obviously allowing it to be unchecked for volatile memory.) I need to update all 64 production boards, and 25 of 29 generic boards, to use the new slot syntax; and I also need to update every single core in higan to use the new manifest game syntax. I want to build out a generic manifest game parser that all emulation cores will use. Once I finish this, I'll also need to write a database converter to update all of my licensed game dumps to the new database syntax. I also need to write up something for doc.byuu.org explaining the new manifest game syntax. The manifest board syntax will still be “internal” and subject to revisions, but once v107 is out, the gamepak manifest format will be set in stone sans extensions. |
|
|
Tim Allen
|
5c55cc2c94 |
Update to v106r08 release.
byuu says:
Changelog:
- Game Boy: fixed RAM/RTC saving¹
- Super Famicom: ICD2 renamed to ICD (there exists an SGB prototype
with a functionally identical ICD1)
- Sufami Turbo: removed short-circuiting when loading an unlinkable
cartridge into slot A²
- Super Game Boy: the 20971520hz clock of the SGB2 is now emulated
- Super Famicom: BSC-1Lxx (SA1) boards now prompt for BS memory
cartridges; and can make use of them³
- Super Famicom: fixed a potential for out-of-bounds reads with BS
Memory flash carts
¹: I'm using a gross hack of replacing `type: ` with `type:` so that
`memory(type=...)` will match without the extra spaces. I need to
think about whether I want the BPath query syntax to strip whitespace or
not. But longer term, I want to finalize game/memory's design, and build
a higan/emulation/manifest parser that produces a nicer interface to
reading manifests for all cores, which will make this irrelevant for
higan anyway.
²: I don't think it's appropriate for higan to enforce this. Nothing
stops you from inserting games that can't be linked into a real Sufami
Turbo. I do short-circuit if you cancel the first load, but I may allow
loading an empty slot A with a populated slot B. I think the BIOS does
something when you do that. Probably just yells at you.
³: I know it's emulated correctly now, but I still don't know what
the heck changes when you load the SD Gundam G Next - Unit & Map
Collection BS Memory cartridge with SD Gundam G Next to actually test
it.
|
|
|
Tim Allen
|
c49d3b2006 |
Update to v106r07 release.
byuu says:
Changelog:
- Super Game Boy: for the 50th time, higan won't segfault if you
cancel the Game Boy cartridge load request
- icarus: moved to new manifest syntax for all remaining systems
- Game Boy: moved to new manifest syntax
Errata:
- Game Boy: save RAM does not appear to be working for some reason
- Famicom: higan won't even start to run this system; it just acts
like a cartridge was never loaded ...
- cores outside of the Super Famicom and Game Boy/Color will not run
due to icarus/higan manifest syntax differences
|
|
|
Tim Allen
|
5e330da4e8 |
Update to v106r05 release.
byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though. |
|
|
Tim Allen
|
c38a771f22 |
Update to v106r04 release.
byuu says:
Changelog:
- nall: `Markup::Node::operator[]` now uses `find()` instead of `lookup()`
behind the scenes
- Super Famicom: RAM memory ordering is now independent of ROM memory
ordering
- Super Famicom: added 19 new generic board definitions
- icarus: improved Super Famicom heuristics generation
Not putting it in the changelog, but the SPC7110 RAM now has write
protection disabled again.
99% of games should now be playable with heuristics. The exceptions
should be:
- 4MB LoROM games with SRAM (Ys 3, FE: Thracia 776)
- 2MB DSP LoROM games
- BS-X Town
- BS-X slotted games
- SA1 BSX slotted games
- SPC7110 games without the RTC (Momotarou Dentetsu Happy, Super Power
League 4)
- SPC7110 7MB fan translation (wasn't supported earlier either)
- ExLoROM games (wasn't supported earlier either)
- Sufami Turbo
- Campus Challenge '92 and Powerfest '94
- ST010 is going to run at 15MHz instead of 11MHz
- MSU1 (needs to be supported in higan, not icarus)
I'll add support for most of these before the release of v107.
|
|
|
Tim Allen
|
3d8be92550 |
Update to v106r3 release.
byuu says:
Changelog:
- Super Famicom: update to newer board markup syntax
- Super Famicom: update all mapped ROMs to be write-protected
- errata: SPC7110 set ram.writeProtect(true), I'll fix it in the
next WIP
- icarus: rewrote the Super Famicom heuristics module from scratch
Instead of icarus heuristics generating higan-specific mappings, it now
generates generic board IDs that can be used by any emulator. I had
originally planned to print out real PCB ID codes here, but these board
mappings are meant to be more generic, and I don't want them to look
real. The pseudo-codes are easy to parse, for example: `DSP-LOROM-NVRAM`
for Super Mario Kart, `SUPERFX-RAM` for Doom.
I'm going to make a `Boards (Generic).bml` file that will contain mapping
definitions for every board. Until this is done, any games not in the SNES
preservation database will fail to play because the mapping information is
now missing.
|
|
|
Tim Allen
|
2f81b5a3e7 |
Update to v106r2 release.
byuu says:
Changelog:
- Super Famicom: added support for loading manifests without embedded
mapping information¹
- genius: initial commit
- various Makefile cleanups
¹: so the idea here is to try and aim for a stable manifest format,
and to allow direct transposition of icarus/genius database entries into
manifest files. The exact mechanics of how this is going to work is
currently in flux, but we'll get there.
For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw
database from my board-editor tool, and higan itself tries to load
`boards.bml`, match an entry to game/board from the game's `manifest.bml`
file, and then transform it into the format currently used by higan. It
does this only when the game's `manifest.bml` file lacks a board node.
When such a board node exists, it works as previous versions of higan
did.
The only incompatible change right now is information/title is now
located at game/label. I may transition window title display to just use
the filenames instead.
Longer term, some thought is going to need to go into the format of the
`boards.bml` database itself, and at which point in the process I should
be transforming things.
Give it time, we'll refine this into something nicer.
|
|
|
Tim Allen
|
e9d2d56df9 |
Update to v105r1 release.
byuu says:
Changelog:
- higan: readded support for soft-reset to Famicom, Super Famicom,
Mega Drive cores (work in progress)
- handhelds lack soft reset obviously
- the PC Engine also lacks a physical reset button
- the Master System's reset button acts like a gamepad button, so
can't show up in the menu
- Mega Drive: power cycle wasn't initializing CPU (M68K) or APU (Z80)
RAM
- Super Famicom: fix SPC700 opcode 0x3b regression; fixes Majuu Ou
[Jonas Quinn]
- Super Famicom: fix SharpRTC save regression; fixes Dai Kaijuu
Monogatari II's real-time clock [Talarubi]
- Super Famicom: fix EpsonRTC save regression; fixes Tengai Makyou
Zero's real-time clock [Talarubi]
- Super Famicom: removed `*::init()` functions, as they were never used
- Super Famicom: removed all but two `*::load()` functions, as they
were not used
- higan: added option to auto-save backup RAM every five seconds
(enabled by default)
- this is in case the emulator crashes, or there's a power outage;
turn it off under advanced settings if you want
- libco: updated license from public domain to ISC, for consistency
with nall, ruby, hiro
- nall: Linux compiler defaults to g++; override with g++-version if
g++ is <= 4.8
- FreeBSD compiler default is going to remain g++49 until my dev
box OS ships with g++ >= 4.9
Errata: I have weird RAM initialization constants, thanks to hex_usr
and onethirdxcubed for both finding this:
http://wiki.nesdev.com/w/index.php?title=CPU_power_up_state&diff=11711&oldid=11184
I'll remove this in the next WIP.
|
|
|
Talarubi
|
a9571ff5b8 |
Fixed: Restore SPC7110 and S-RTC time properly
Loading and unloading the RTC is a little odd, since it's normally always powered in the first place. What we want, and what the load() functions really do, is to resync using the saved timestamps or reset it. unload() proper doesn't do anything. However, an interface refactoring after v098 reordered the above operations, and this (along with a typo, shh!) was causing the already synced time to be cleared. I've added checks so that whenever rtc.ram can't be found, load() gets called with empty arguments to initialise the defaults (like putting in a fresh battery). |
|
|
Tim Allen
|
5dbaec85a7 |
Update to v104r16 release.
byuu says:
Changelog:
- processor/upd96050: always potentially update S1 on ALU ops, sans NOP
- theory by Lord Nightmare. I'm impartial on this one, but may as
well match his design
- sfc: fixed save state hang [reported by FitzRoy; fixed by Cydrak]
- icarus: do not save settings.bml file when in library mode
|
|
|
Tim Allen
|
6524a7181d |
Update to v104r15 release.
byuu says:
Changelog:
- processor/huc6280,mos6502,wdc65816: replaced abbreviated opcode
names with descriptive names
- nall: replaced `PLATFORM_MACOSX` define with `PLATFORM_MACOS`
- icarus: added `Icarus::missing() -> string_vector` to list missing
appended firmware files by name
- ruby, hiro: fix macosx→macos references
The processor instruction renaming was really about consistency with the
other processor cores. I may still need to do this for one or two more
processors.
The icarus change should allow a future release of the icarus
application to import games with external SNES coprocessor firmware once
again. It will also allow this to be possible when used in library mode.
|
|
|
Tim Allen
|
fbc58c70ae |
Update to v104r14 release.
byuu says:
Changelog:
- Emulator::Interface::videoResolution() -\> VideoResolution renamed
to videoInformation() -\> VideoInformation
- added double VideoInformation::refreshRate
- higan: added `binary := (application|library)` — set this to
`library` to produce a dynamic link library
- higan: removed `-march=native` for macOS application builds; and for
all library builds
- higan: removed `console` build flag; uncomment `link += -mwindows`
instead
- nall/GNUmakefile: `macosx` platform renamed `macos`
- still need to do this for nall/intrinsics.hpp
- Game Gear: return region=NTSC as the only option, so that the system
frequency is always set correctly
- hiro/cocoa: fixed typo [Sintendo]
- hiro/Windows: removed GetDpiForMonitor, as it's Windows 8+ only; DPI
is no longer per-monitor aware
- icarus: core Icarus class now has virtual functions for
directory::create, <file::exists>, <file::copy>, <file::write>
- icarus: Sufami Turbo can import save RAM files now
- icarus: setting `ICARUS_LIBRARY` define will compile icarus without
main(), GUI components
- ruby/video/Direct3D: choose the current monitor instead of top-left
monitor for fullscreen exclusive [Cydrak]
- ruby/video/Direct3D: do not set `WS_EX_TOPMOST` on fullscreen
exclusive window [Cydrak]
- this isn't necessary for exclusive mode, and it just makes
getting out of the application more difficult
|
|
|
Tim Allen
|
4fb8ce2821 |
Update to v104r12 release.
byuu says:
Changelog:
- higan: URLs updated to HTTPS
- sfc/ppu/background: use hires/interlace/mosaic-adjusted X/Y
coordinates for offset-per-tile mode
- sfc/ppu/background: hires mosaic seems to advance pixel counter on
subscreen pixels
- tomoko: added “Help→Credits” menu option (currently the page does
not exist; should before v105)
- tomoko: reduced volume slider from {0% - 500%} to {0% - 200%}.
Distortion is too intense above 200%.
- technically, I've encountered distortion at 200% as well in
Prince of Persia for the SNES
- nall/run/invoke: use program path for working directory
- allows you to choose “Library→Import ROMs” from a different
directory on the command-line
I don't know how to assign credit for the mosaic stuff. It's been a
work-in-progress with me, Cydrak, and hex_usr.
The current design should be correct, but very unpleasant. The code
desperately needs to be refactored, but my recent attempt at doing so
ended in spectacular failure.
|
|
|
Tim Allen
|
3dce3aa3c8 |
Update to v104r11 release.
byuu says:
Changelog:
- sfc/ppu/background: minor code cleanup and simplification
- sfc/ppu/background: $2106 MOSAIC register was implemented
incorrectly
- sfc/ppu/background: fixed mosaic effects in hires mode (temporary
fix)
- sfc/ppu/background: fixed mosaic effects in interlace mode [Cydrak]
Errata:
- sfc/ppu/background/background.cpp:48: should be
`if(!mosaic.enable) {`
Turns out there is only one mosaic size, and the other four bits are
per-BG mosaic enable. This matters a lot for hires/interlace, as
mosaicSize=0 (2x2) is not the same thing as mosaicEnable=false (1x1).
Although I've now implemented this, I really don't like how my mosaic
implementation works right now. I tried to redesign the entire system,
and completely failed. So I started over from v104r10 again and instead
went with a more evolutionary improvement for now. I'll keep trying.
Also, the combination of mosaic + offset-per-tile is still sketchy, as
is mode 6 offset-per-tile. I'll get to those in the future as well.
|
|
|
Tim Allen
|
b38a657192 |
Update to v104r05 release.
byuu says:
Changelog:
- emulator/random: new array function with more realistic RAM
initializations
- emulator/random: both low and high entropy register initializations
now use PCG
- gba/player: rumble will time out and disable after being left on for
500ms; fixes Pokemon Pinball issue
- ruby/input/udev: fixed rumble effects [ma\_rysia]
- sfc/system: default to low-entropy randomization of memory
The low-entropy memory randomization is modeled after one of my SHVC
2/1/3 systems. It generates striped patterns in memory, using random
inputs (biased to 0x00/0xff), and has a random chance of corrupting 1-2
bits of random values in the pool of memory (to prevent easy emulator
detection and to match observed results on hardware.)
The reasoning for using PCG on register initializations, is that I don't
believe they're going to have repeating patterns like RAM does anyway.
And register initializations are way more vital.
I want to have the new low-entropy RAM mode tested, so at least for the
next few WIPs, I've set the SNES randomization over to low-entropy.
We'll have to have a long discussion and decide whether we want official
releases to use high-entropy or low-entropy.
Also, I figured out the cause of the Prince of Persia distortion ... I
had the volume under the audio settings tab set to 200%. I didn't
realize there were SNES games that clipped so easily, given how
incredibly weak SNES audio is compared to every other sound source on my
PC. So with no entropy or low-entropy, indeed the game now sounds just
fine.
I can't actually test the udev fixes, so I guess we'll see how that goes
for Screwtape and ma\_rysia.
|
|
|
Tim Allen
|
d621136d69 |
Update to v104r04 release.
byuu says:
Changelog:
- higan/emulator: added new Random class with three entropy settings:
none, low, and high
- md/vdp: corrected Vcounter readout in interlace mode [MoD]
- sfc: updated core to use the new Random class; defaults to high
entropy
No entropy essentially returns 0, unless the random.bias(n) function is
called, in which case, it returns n. In this case, n is meant to be the
"logical/ideal" default value that maximizes compatibility with games.
Low entropy is a very simple entropy modeled after RAM initialization
striping patterns (eg 32 0x00s, followed by 32 0xFFs, repeating
throughout.) It doesn't "glitch" like real hardware does on rare
occasions (parts of the pattern being broken from time to time.) It also
only really returns 0 or ~0. So the entropy is indeed extremely low, and
not very useful at all for detecting bugs. Over time, we can try to
improve this, of course.
High entropy is PCG. This replaces the older, lower-entropy and more
predictable, LFSR. PCG should be more than enough for emulator
randomness, while still being quite fast.
Unfortunately, the bad news ... both no entropy and low entropy fix the
Konami logo popping sound in Prince of Persia, but all three entropy
settings still cause the distortion in-game, especially evident at the
title screen. So ... this may be a more serious bug than first
suspected.
|
|
|
Tim Allen
|
11357169a5 |
Update to v104r02 release.
byuu says:
Changelog:
- md/vdp: backgrounds always update priority bit output [Cydrak]
- md/vdp: vcounter.d0 becomes vcounter.d8 in interlace mode 3
- md/vdp: return field number in interlace modes from status register
- md/vdp: rework scanline/frame counting in main loop so first frame
won't clock to field 1 instead of field 0
- md/vdp: add support for shadow/highlight mode; optimize to minimal
code [Cydrak]
- md/vdp: update outputPixel() to support interlace modes
- sfc/cpu: auto joypad polling start should clear the shift registers;
fixes Nuke (PD)
- thanks to BMF54123 for this bug report
- tomoko: if an invalid video/audio/input driver is found in the
configuration file, it's reset to "None"
- prevents showing the wrong driver under advanced settings; no
longer requires possibly two reboots to fix
Note: the Mega Drive interlace mode 1 should be working fully, but I
don't know any games that use it. Interlace mode 3 (Sonic 2's two-player
mode) does not work at all yet, but this is a good start.
|
|
|
Tim Allen
|
366e9cebff |
Update to v104r01 release.
byuu says:
Changelog:
- gba/cpu: synchronize to the PPU, not oneself, when the CPU is
stopped
- this bug was patched in the official v104 release; but not in
the .tar.xz archive
- ms/vdp: backdrop color is on the second 16-entry palette, not the
first [hex\_usr]
- ms/vdp: fix background color 0 priority; fixes Alex Kidd in High
Tech World text boxes [hex\_usr]
- tomoko: choose first option when loading files via the command-line
[hex\_usr]
- icarus: lo/hi RAM addressing was backwards; M68K is big endian;
fixes save files in Sonic 3
Many thanks to hex\_usr for the Master System / Game Gear VDP fix.
That's a tricky system to get good technical information on. The fix
should be correct, but please report if you spot any regressions just in
case.
|
|
|
Tim Allen
|
406b6a61a5 |
Update to v103r31 release.
byuu says:
Changelog:
- gba/cpu: slight speedup to CPU::step()
- processor/arm7tdmi: fixed about ten bugs, ST018 and GBA games are
now playable once again
- processor/arm: removed core from codebase
- processor/v30mz: code cleanup (renamed functions; updated
instruction() for consistency with other cores)
It turns out on my much faster system, the new ARM7TDMI core is very
slightly slower than the old one (by about 2% or so FPS.) But the
CPU::step() improvement basically made it a wash.
So yeah, I'm in really serious trouble with how slow my GBA core is now.
Sigh.
As for higan/processor ... this concludes the first phase of major
cleanups and rewrites.
There will always be work to do, and I have two more phases in mind.
One is that a lot of the instruction disassemblers are very old. One
even uses sprintf still. I'd like to modernize them all. Also, the
ARM7TDMI core (and the ARM core before it) can't really disassemble
because the PC address used for instruction execution is not known prior
to calling instruction(), due to pipeline reload fetches that may occur
inside of said function. I had a nasty hack for debugging the new core,
but I'd like to come up with a clean way to allow tracing the new
ARM7TDMI core.
Another is that I'd still like to rename a lot of instruction function
names in various cores to be more descriptive. I really liked how the
LR35902 core came out there, and would like to get that level of detail
in with the other cores as well.
|
|
|
Tim Allen
|
1067566834 |
Update to v103r30 release.
byuu says: Changelog: - processor/arm7tdmi: completed implemented - gba/cpu, sfc/coprocessor/armdsp: use arm7tdmi instead of arm - sfc/cpu: experimental fix for newly discovered HDMA emulation issue Notes: The ARM7TDMI core crashes pretty quickly when trying to run GBA games, and I'm certain the same will be the case with the ST018. It was never all that likely I could rewrite 70KiB of code in 20 hours and have it work perfectly on the first try. So, now it's time for lots and lots of debugging. Any help would *really* be appreciated, if anyone were up for comparing the two implementations for regressions =^-^= I often have a really hard time spotting simple typos that I make. Also, the SNES HDMA fix is temporary. I would like it if testers could run through a bunch of games that are known for being tricky with HDMA (or if these aren't known to said tester, any games are fine then.) If we can confirm regressions, then we'll know the fix is either incorrect or incomplete. But if we don't find any, then it's a good sign that we're on the right path. |
|
|
Tim Allen
|
0b6f1df987 |
Update to v103r27 release.
byuu says:
Changelog:
- hiro/windows: set dpiAware=false, fixes icarus window sizes relative
to higan window sizes
- higan, icarus, hiro, ruby: add support for high resolution displays
on macOS [ncbncb]
- processor/lr35902-legacy: removed
- processor/arm7tdmi: new processor core started; intended to one day
be a replacement for processor/arm
It will probably take several WIPs to get the new ARM core up and
running. It's the last processor rewrite. After this, all processor
cores will be up to date with all my current programming conventions.
|
|
|
Tim Allen
|
ed5ec58595 |
Update to v103r13 release.
byuu says:
Changelog:
- gb/interface: fix Game Boy Color extension to be "gbc" and not "gb"
[hex\_usr]
- ms/interface: move Master System hardware controls below controller
ports
- sfc/ppu: improve latching behavior of BGnHOFS registers (not
hardware verified) [AWJ]
- tomoko/input: rework port/device mapping to support non-sequential
ports and devices¹
- todo: should add move() to inputDevice.mappings.append and
inputPort.devices.append
- note: there's a weird GCC 4.9 bug with brace initialization of
InputEmulator; have to assign each field separately
- tomoko: all windows sans the main presentation window can be
dismissed with the escape key
- icarus: the single file selection dialog ("Load ROM Image...") can
be dismissed with the escape key
- tomoko: do not pause emulation when FocusLoss/Pause is set during
exclusive fullscreen mode
- hiro/(windows,gtk,qt): implemented Window::setDismissable() function
(missing from cocoa port, sorry)
- nall/string: fixed printing of largest possible negative numbers (eg
`INT_MIN`) [Sintendo]
- only took eight months! :D
¹: When I tried to move the Master System hardware port below the
controller ports, I ran into a world of pain.
The input settings list expects every item in the
`InputEmulator<InputPort<InputDevice<InputMapping>>>>` arrays to be
populated with valid results. But these would be sparsely populated
based on the port and device IDs from inside higan. And that is done so
that the Interface::inputPoll can have O(1) lookup of ports and devices.
This worked because all the port and device IDs were sequential (they
left no gaps in the maps upon creating the lists.)
Unfortunately by changing the expectation of port ID to how it appears
in the list, inputs would not poll correctly. By leaving them alone and
just moving Hardware to the third position, the Game Gear would be
missing port IDs of 0 and 1 (the controller ports of the Master System).
Even by trying to make separate MasterSystemHardware and
GameGearHardware ports, things still fractured when the devices were no
longer contigious.
I got pretty sick of this and just decided to give up on O(1)
port/device lookup, and moved to O(n) lookup. It only knocked the
framerate down by maybe one frame per second, enough to be in the margin
of error. Inputs aren't polled *that* often for loops that usually
terminate after 1-2 cycles to be too detrimental to performance.
So the new input system now allows non-sequential port and device IDs.
Remember that I killed input IDs a while back. There's never any reason
for those to need IDs ... it was easier to just order the inputs in the
order you want to see them in the user interface. So the input lookup is
still O(1). Only now, everything's safer and I return a
maybe<InputMapping&>, and won't crash out the program trying to use a
mapping that isn't found for some reason.
Errata: the escape key isn't working on the browser/message dialogs on
Windows, because of course nothing can ever just be easy and work for
me. If anyone else wouldn't mind looking into that, I'd greatly
appreciate it.
Having the `WM_KEYDOWN` test inside the main `Application_sharedProc`, it
seems to not respond to the escape key on modal dialogs. If I put the
`WM_KEYDOWN` test in the main window proc, then it doesn't seem to get
called for `VK_ESCAPE` at all, and doesn't get called period for modal
windows. So I'm at a loss and it's past 4AM here >_>
|
|
|
Tim Allen
|
cbbf5ec114 |
Update to v103r10 release.
byuu says:
Changelog:
- tomoko: video scaling options are now resolutions in the
configuration file, eg "640x480", "960x720", "1280x960"
- tomoko: main window is now always resizable instead of fixed width
(also supports maximizing)
- tomoko: added support for non-integral scaling in windowed mode
- tomoko: made the quick/managed state messaging more consistent
- tomoko: hide "Find Codes ..." button from the cheat editor window if
the cheat database is not present
- tomoko: per-game cheats.bml file now goes into the higan/ subfolder
instead of the root folder
So the way the new video system works is you have the following options
on the video settings panel:
Windowed mode: { Aspect correction, Integral scaling, Adaptive }
Fullscreen mode: { Aspect correction, Integral scaling } (and one day,
hopefully Exclusive will be added here)
Whenever you adjust the overscan masking, or you change any of the
windowed or fullscreen mode settings, or you choose a different video
scale from the main menu, or you load a new game, or you unload a game,
or you rotate the display of an emulated system, the resizeViewport
logic will be invoked. This logic will remember the last option you
chose for video scale, and base the new window size on that value as an
upper limit of the new window size.
If you are in windowed mode and have adaptive enabled, it will shrink
the window to fit the contents of the emulated system's video output.
Otherwise, if you are not in integral scaling mode, it will scale the
video as large as possible to fit into the video scaled size you have
selected. Otherwise, it will perform an integral scale and center the
video inside of the viewport.
If you are in fullscreen mode, it's much the same, only there is no
adaptive mode.
A major problem with Xorg is that it's basically impossible to change
the resizability attribute of a window post-creation. You can do it, but
all kinds of crazy issues start popping up. Like if you toggle
fullscreen, then you'll find that the window won't grow past a certain
fairly small size that it's already at, and cannot be shrunk. And the
multipliers will stop expanding the window as large as they should. And
sometimes the UI elements won't be placed in the correct position, or
the video will draw over them. It's a big mess. So I have to keep the
main window always resizable. Also, note that this is not a limitation
of hiro. It's just totally broken in Xorg itself. No amount of fiddling
has ever allowed this to work reliably for me on either GTK+ 2 or Qt 4.
So what this means is ... the adaptive mode window is also resizable.
What happens here is, whenever you drag the corners of the main window
to resize it, or toggle the maximize window button, higan will bypass
the video scale resizing code and instead act as though the adaptive
scaling mode were disabled. So if integral scaling is checked, it'll
begin scaling in integral mode. Otherwise, it'll begin scaling in
non-integral mode.
And because of this flexibility, it no longer made sense for the video
scale menu to be a radio box. I know, it sucks to not see what the
active selection is anymore, but ... say you set the scale to small,
then you accidentally resized the window a little, but want it snapped
back to the proper small resolution dimensions. If it were a radio item,
you couldn't reselect the same option again, because it's already active
and events don't propagate in said case. By turning them into regular
menu options, the video scale menu can be used to restore window sizing.
Errata:
On Windows, the main window blinks a few times on first load. The fix
for that is a safeguard in the video settings code, roughly like so ...
but note you'd need to make a few other changes for this to work against
v103r10:
auto VideoSettings::updateViewport(bool firstRun) -> void {
settings["Video/Overscan/Horizontal"].setValue(horizontalMaskSlider.position());
settings["Video/Overscan/Vertical"].setValue(verticalMaskSlider.position());
settings["Video/Windowed/AspectCorrection"].setValue(windowedModeAspectCorrection.checked());
settings["Video/Windowed/IntegralScaling"].setValue(windowedModeIntegralScaling.checked());
settings["Video/Windowed/AdaptiveSizing"].setValue(windowedModeAdaptiveSizing.checked());
settings["Video/Fullscreen/AspectCorrection"].setValue(fullscreenModeAspectCorrection.checked());
settings["Video/Fullscreen/IntegralScaling"].setValue(fullscreenModeIntegralScaling.checked());
horizontalMaskValue.setText({horizontalMaskSlider.position()});
verticalMaskValue.setText({verticalMaskSlider.position()});
if(!firstRun) presentation->resizeViewport();
}
That'll get it down to one blink, as with v103 official. Not sure I can
eliminate that one extra blink.
I forgot to remove the setResizable toggle on fullscreen mode exit. On
Windows, the main window will end up unresizable after toggling
fullscreen. I missed that one because like I said, toggling resizability
is totally broken on Xorg. You can fix that with the below change:
auto Presentation::toggleFullScreen() -> void {
if(!fullScreen()) {
menuBar.setVisible(false);
statusBar.setVisible(false);
//setResizable(true);
setFullScreen(true);
if(!input->acquired()) input->acquire();
} else {
if(input->acquired()) input->release();
setFullScreen(false);
//setResizable(false);
menuBar.setVisible(true);
statusBar.setVisible(settings["UserInterface/ShowStatusBar"].boolean());
}
resizeViewport();
}
Windows is stealing focus on calls to resizeViewport(), so we need to
deal with that somehow ...
I'm not really concerned about the behavior of shrinking the viewport
below the smallest multiplier for a given system. It might make sense to
snap it to the window size and forego all other scaling, but honestly
... meh. I don't really care. Nobody sane is going to play like that.
|
|
|
Tim Allen
|
7af270aa59 |
Update to v103r09 release.
byuu says:
Changelog:
- gba/apu: fixed wave RAM nibble ordering (fixes audio in Castlevania,
PocketNES)
- emulator: restructured video information to just a single
videoResolution() → VideoResolution function
- returns "projected size" (between 160x144 and 320x240)
- "internal buffer size" (up to 1280x480)
- returns aspect correction multiplier that is to be applied to
the width field
- the value could be < 1.0 to handle systems with taller
pixels; although higan doesn't emulate such a system
- tomoko: all calculations for scaling and overscan masking are done
by the GUI now
- tomoko: aspect correction can be enabled in either windowed or
fullscreen mode separately; moved to Video settings panel
- tomoko: video scaling multipliers (against 320x240) can now me
modified from the default (2,3,4) via the configuration file
- use this as a really barebones way of supporting high DPI
monitors; although the GUI elements won't scale nicely
- if you set a value less than two, or greater than your
resolution divided by 320x240, it's your own fault when things
blow up. I'm not babysitting anyone with advanced config-file
only options.
- tomoko: added new adaptive windowed mode
- when enabled, the window will shrink to eliminate any black
borders when loading a game or changing video settings. The
window will not reposition itself.
- tomoko: added new adaptive fullscreen mode
- when enabled, the integral scaling will be disabled for
fullscreen mode, forcing the video to fill at least one
direction of the video monitor completely.
I expect we will be bikeshedding for the next month on how to describe
the new video options, where they should appear in the GUI, changes
people want, etc ... but suffice to say, I'm happy with the
functionality, so I don't intend to make changes to -what- things do,
but I will entertain better ways to name things.
|
|
|
Tim Allen
|
191a71b291 |
Update to v103r08 release.
byuu says:
Changelog:
- emulator: improved aspect correction accuracy by using
floating-point calculations
- emulator: added videoCrop() function, extended videoSize() to take
cropping parameters¹
- tomoko: the overscan masking function will now actually resize the
viewport²
- gba/cpu: fixed two-cycle delay on triggering DMAs; not running DMAs
when the CPU is stopped
- md/vdp: center video when overscan is disabled
- pce/vce: resize video output from 1140x240 to 1120x240
- tomoko: resize window scaling from 326x240 to 320x240
- tomoko: changed save slot naming and status bar messages to indicate
quick states vs managed states
- tomoko: added increment/decrement quick state hotkeys
- tomoko: save/load quick state hotkeys now save to slots 1-5 instead
of always to 0
- tomoko: increased overscan range from 0-16 to 0-24 (in case you want
to mask the Master System to 240x192)
¹: the idea here was to decouple raw pixels from overscan masking.
Overscan was actually horrifically broken before. The Famicom outputs at
256x240, the Super Famicom at 512x480, and the Mega Drive at 1280x480.
Before, a horizontal overscan mask of 8 would not reduce the Super
Famicom or Mega Drive by nearly as much as the Famicom. WIth the new
videoCrop() function, the internals of pixel size distortions can be
handled by each individual core.
²: furthermore, by taking optional cropping information in
videoSize(), games can scale even larger into the viewport window. So
for example, before the Super Famicom could only scale to 1536x1440. But
by cropping the vertical resolution by 6 (228p effectively, still more
than NTSC can even show), I can now scale to 1792x1596. And wiht aspect
correction, that becomes a perfect 8:7 ratio of 2048x1596, giving me
perfectly crisp pixels without linear interpolation being required.
Errata: for some reason, when I save a new managed state with the SFC
core, the default description is being set to a string of what looks to
be hex numbers. I found the cause ... I'll fix this in the next release.
Note: I'd also like to hide the "find codes..." button if cheats.bml
isn't present, as well as update the SMP TEST register comment from
smp/timing.cpp
|
|
|
Tim Allen
|
16f736307e |
Update to v103r06 release.
byuu says:
Changelog:
- processor/spc700: restored fetch/load/store/pull/push shorthand
functions
- processor/spc700: split functions that tested the algorithm used (`op
!= &SPC700:...`) to separate instructions
- mostly for code clarity over code size: it was awkward having
cycle counts change based on a function parameter
- processor/spc700: implemented Overload's new findings on which
cycles are truly internal (no bus reads)
- sfc/smp: TEST register emulation has been vastly improved¹
¹: it turns out that TEST.d4,d5 is the external clock divider (used
when accessing RAM through the DSP), and TEST.d6,d7 is the internal
clock divider (used when accessing IPLROM, IO registers, or during idle
cycles.)
The DSP (24576khz) feeds its clock / 12 through to the SMP (2048khz).
The clock divider setting further divides the clock by 2, 4, 8, or 16.
Since 8 and 16 are not cleanly divislbe by 12, the SMP cycle count
glitches out and seems to take 10 and 2 clocks instead of 8 or 16. This
can on real hardware either cause the SMP to run very slowly, or more
likely, crash the SMP completely until reset.
What's even stranger is the timers aren't affected by this. They still
clock by 2, 4, 8, or 16.
Note that technically I could divide my own clock counters by 24 and
reduce these to {1,2,5,10} and {1,2,4,8}, I instead chose to divide by
12 to better illustrate this hardware issue and better model that the
SMP clock runs at 2048khz and not 1024khz.
Further, note that things aren't 100% perfect yet. This seems to throw
off some tests, such as blargg's `test_timer_speed`. I can't tell how
far off I am because blargg's test tragically doesn't print out fail
values. But you can see the improvements in that higan is now passing
all of Revenant's tests that were obviously completely wrong before.
|
|
|
Tim Allen
|
40802b0b9f |
Update to v103r05 release.
byuu says:
Changelog:
- fc/controller: added ControllerPort class; removed Peripherals class
- md/controller/gamepad: removed X,Y,Z buttons since this isn't a
6-button controller
- ms/controller: added ControllerPort class (not used in Game Gear
mode); removed Peripherals class
- pce/controller: added ControllerPort class; removed Peripherals
class
- processor/spc700: idle(address) is part of SMP class again, contains
flag to detect mov (x)+ edge case
- sfc/controller/super-scope,justifier: use CPU frequency instead of
hard-coding NTSC frequency
- sfc/cpu: move 4x8-bit SMP ports to SMP class
- sfc/smp: move APU RAM to DSP class
- sfc/smp: improved emulation of TEST registers bits 4-7 [information
from nocash]
- d4,d5 is RAM wait states (1,2,5,10)
- d6,d7 is ROM/IO wait states (1,2,5,10)
- sfc/smp: code cleanup to new style (order from lowest to highest
bits; use .bit(s) functions)
- sfc/smp: $00f8,$00f9 are P4/P5 auxiliary ports; named the registers
better
|
|
|
Tim Allen
|
ff3750de4f |
Update to v103r04 release.
byuu says:
Changelog:
- fc/apu: $4003,$4007 writes initialize duty counter to 0 instead of 7
- fc/apu: corrected duty table entries for use with decrementing duty
counter
- processor/spc700: emulated the behavior of cycle 3 of (x)+
instructions to not read I/O registers
- specifically, this prevents reads from $fd-ff from resetting the
timers, as observed on real hardware
- sfc/controller: added ControllerPort class to match Mega Drive
design
- sfc/expansion: added ExpansionPort class to match Mega Drive design
- sfc/system: removed Peripherals class
- sfc/system: changed `colorburst()` to `cpuFrequency()`; added
`apuFrequency()`
- sfc: replaced calls to `system.region == System::Region::*` with
`Region::*()`
- sfc/expansion: remove thread from scheduler when device is destroyed
- sfc/smp: `{read,write}Port` now use a separate 4x8-bit buffer instead
of underlying APU RAM [hex\_usr]
|
|
|
Tim Allen
|
78f341489e |
Update to v103r03 release.
byuu says:
Changelog:
- md/psg: fixed output frequency rate regression from v103r02
- processor/m68k: fixed calculations for ABCD, NBCD, SBCD [hex\_usr,
SuperMikeMan]
- processor/spc700: renamed abbreviated instructions to functional
descriptions (eg `XCN` → `ExchangeNibble`)
- processor/spc700: removed memory.cpp shorthand functions (fetch,
load, store, pull, push)
- processor/spc700: updated all instructions to follow cycle behavior
as documented by Overload with a logic analyzer
Once again, the changes to the SPC700 core are really quite massive. And
this time it's not just cosmetic: the idle cycles have been updated to
pull from various memory addresses. This is why I removed the shorthand
functions -- so that I could handle the at-times very bizarre addresses
the SPC700 has on its address bus during its idle cycles.
There is one behavior Overload mentioned that I don't emulate ... one of
the cycles of the (X) transfer functions seems to not actually access
the $f0-ff internal SMP registers? I don't fully understand what
Overload is getting at, so I haven't tried to support it just yet.
Also, there are limits to logic analyzers. In many cases the same
address is read from twice consecutively. It is unclear which of the two
reads the SPC700 actually utilizes. I tried to choose the most logical
values (usually the first one), but ... I don't know that we'll be able
to figure this one out. It's going to be virtually impossible to test
this through software, because the PC can't really execute out of
registers that have side effects on reads.
|
|
|
Tim Allen
|
3517d5c4a4 |
Update to v103r02 release.
byuu says:
Changelog:
- fc/apu: improved phase duty cycle emulation (mode 3 is 25% phase
inverted; counter decrements)
- md/apu: power/reset do not cancel 68K bus requests
- md/apu: 68K is not granted bus access on Z80 power/reset
- md/controller: replaced System::Peripherals with ControllerPort
concept
- md/controller: CTRL port is now read-write, maintains value across
controller changes (and soon, soft resets)
- md/psg: PSG sampling rate unintentionally modified¹
- processor/spc700: improve cycle timing of (indirect),y instructions
[Overload]
- processor/spc700: idle() cycles actually read from the program
counter; much like the 6502 [Overload]
- some of the idle() cycles should read from other addresses; this
still needs to be supported
- processor/spc700: various cleanups to instruction function naming
- processor/z80: prefix state (HL→IX,IY override) can now be
serialized
- icarus: fix install rule for certain platforms (it wasn't buggy on
FreeBSD, but was on Linux?)
¹: the clock speed of the PSG is oscillator/15. But I was setting the
sampling rate to oscillator/15/16, which was around 223KHz. I am not
sure whether the PSG should be outputting at 3MHz or 223KHz. Amazingly
... I don't really hear a difference either way `o_O` I didn't actually
mean to make this change; I just noticed it after comparing the diff
between r01 and r02. If this turns out to be wrong, set
stream = Emulator::audio.createStream(1, frequency() / 16.0);
in md/psg.cpp to revert this change.
|
|
|
Tim Allen
|
ecc7e899e0 |
Update to v103r01 release.
byuu says:
Changelog:
- nall/dsp: improve one pole coefficient calculations [Fatbag]
- higan/audio: reworked filters to support selection of either one
pole (first-order) or biquad (second-order) filters
- note: the design is not stable yet; so forks should not put too
much effort into synchronizing with this change yet
- fc: added first-order filters as per NESdev wiki (90hz lowpass +
440hz lowpass + 14khz highpass)
- fc: created separate NTSC-J and NTSC-U regions
- NESdev wiki says the Japanese Famicom uses a separate audio
filtering strategy, but details are fuzzy
- there's also cartridge audio output being disabled on NES units;
and differences with controllers
- this stuff will be supported in the future, just adding the
support for it now
- gba: corrected serious bugs in PSG wave channel emulation [Cydrak]
- note that if there are still bugs here, it's my fault
- md/psg,ym2612: added first-order low-pass 2840hz filter to match
VA3-VA6 Mega Drives
- md/psg: lowered volume relative to the YM2612
- using 0x1400; multiple people agreed it was the closest to the
hardware recordings against a VA6
- ms,md/psg: don't serialize the volume levels array
- md/vdp: Hblank bit acts the same during Vblank as outside of it (it
isn't always set during Vblank)
- md/vdp: return isPAL in bit 0 of control port reads
- tomoko: change command-line option separator from : to |
- [Editor's note: This change was present in the public v103,
but it's in this changelog because it was made after the v103 WIP]
- higan/all: change the 20hz high-pass filters from second-order
three-pass to first-order one-pass
- these filters are meant to remove DC bias, but I honestly can't
hear a difference with or without them
- so there's really no sense wasting CPU power with an extremely
powerful filter here
Things I did not do:
- change icarus install rule
- work on 8-bit Mega Drive SRAM
- work on Famicom or Mega Drive region detection heuristics in icarus
My long-term dream plan is to devise a special user-configurable
filtering system where you can set relative volumes and create your own
list of filters (any number of them in any order at any frequency), that
way people can make the systems sound however they want.
Right now, the sanest place to put this information is inside the
$system.sys/manifest.bml files. But that's not very user friendly, and
upgrading to new versions will lose these changes if you don't copy them
over manually. Of course, cluttering the GUI with a fancy filter editor
is probably supreme overkill for 99% of users, so maybe that's fine.
|
|
|
Tim Allen
|
b7006822bf |
Update to v103 WIP release.
byuu says (in the WIP forum):
Changelog:
- higan: cheat codes accept = and ? separators now
- the new preferred code format is: address=value or
address=if-match?value
- the old code format of address/value and address/if-match/value
will continue to work
- higan: cheats.bml is no longer included with the base distribution
- mightymo stopped updating it in 2015, and it's not source code;
it can still be pulled in from older releases
- fc: improved PAL mode timing; use PAL APU timing tables; fix PAL
noise period table [hex\_usr]
- md: support aborting a Z80 bus wait in order to capture save states
without freezing
- note that this will violate accuracy; but in practice a slight
desync is better than an emulator deadlock
- sfc: revert DSP ENDX randomization for now (want to research it more
before deploying in an official release)
- sfc: fix Super Famicom.sys/manifest.bml APU RAM size [hex\_usr]
- tomoko: cleaned up make install rules
- hiro/cocoa: use ABGR for pixel data [Sintendo]
Note: I forgot to change the command-line and drag-and-drop separator
from : to | in this WIP. However, it is corrected in the v103 official
binary and source published on download.byuu.org. Sorry about that, I
know it makes the Git repository history more difficult. I'm not
concerned whether the : → | change is part of v103 or v103r01 in the
repository, and will leave this to your discretion, Screwtape.
I also still need to set the VDP bit to indicate PAL mode in the Mega
Drive core. This is what happens when I have 47 things I have to do,
given how lousy my memory is. I miss things.
|
|
|
Tim Allen
|
8476f35153 |
Update to v102r28 release.
byuu says:
Changelog:
- higan: `Emulator::<Platform::load>()` now returns a struct containing
both a path ID and a string option
- higan: `Emulator::<Platform::load>()` now takes an optional final
argument of string options
- fc: added PAL emulation (finally, only took six years)
- md: added PAL emulation
- md: fixed address parameter to `VDP::Sprite::write()`; fixes missing
sprites in Super Street Fighter II
- md: emulated HIRQ counter; fixes many games
- Super Street Fighter II - status bar
- Altered Beast - status bar
- Sonic the Hedgehog - Labyrinth Zone - water effect
- etc.
- ms: added PAL emulation
- sfc: added the ability to override the default region auto-detection
- sfc: removed "system.region" override setting from `Super Famicom.sys`
- tomoko: added options list to game folder load dialog window
- tomoko: added the ability to specify game folder load options on the
command-line
So, basically ... Sega forced a change with the way region detection
works. You end up with games that can run on multiple regions, and the
content changes accordingly. Bare Knuckle in NTSC-J mode will become
Streets of Rage in NTSC-U mode. Some games can even run in both NTSC and
PAL mode.
In my view, there should be a separate ROM for each region a game was
released in, even if the ROM content were identical. But unfortunately
that's not how things were done by anyone else.
So to support this, the higan load dialog now has a drop-down at the
bottom-right, where you can choose the region to load games from. On the
SNES, it defaults to "Auto", which will pull the region setting from the
manifest, or fall back on NTSC. On the Mega Drive ... unfortunately, I
can't auto-detect the region from the ROM header. $1f0 is supposed to
contain a string like "JUE", but instead you get games like Maui Mallard
that put an "A" there, and other such nonsense. Sega was far more lax
than Nintendo with the ROM header validity. So for now at least, you
have to manually select your region every time you play a Mega Drive
game, thus you have "NTSC-J", "NTSC-U", and "PAL". The same goes for the
Master System for the same reason, but there's only "NTSC" and "PAL"
here. I'm not sure if games have a way to detect domestic vs
international consoles.
And for now ... the Famicom is the same as well, with no auto-detection.
I'd sincerely hope iNES has a header bit for the region, but I didn't
bother with updating icarus to support that yet.
The way to pass these parameters on the command-line is to prefix the
game path with "option:", so for example:
higan "PAL:/path/to/Sonic the Hedgehog (USA, Europe).md"
If you don't provide a prefix, it uses the default (NTSC-J, NTSC, or
Auto.) Obviously, it's not possible to pass parameters with
drag-and-drop, so you will always get the default option in said case.
|
|
|
Tim Allen
|
e7806dd6e8 |
Update to v102r27 release.
byuu says:
Changelog:
- processor/gsu: minor code cleanup
- processor/hg51b: renamed reg(Read,Write) to register(Read,Write)
- processor/lr35902: minor code cleanup
- processor/spc700: completed code cleanup (sans disassembler)
- no longer uses internal global state inside instructions
- processor/spc700: will no longer hang the emulator if stuck in a WAI
(SLEEP) or STP (STOP) instruction
- processor/spc700: fixed bug in handling of OR1 and AND1 instructions
- processor/z80: minor code cleanup
- sfc/dsp: revert to initializing registers to 0x00; save for
ENDX=random(), FLG=0xe0 [Jonas Quinn]
Major testing of the SNES game library would be appreciated, now that
its CPU cores have all been revised.
We know the DSP registers read back as randomized data ... mostly, but
there are apparently internal latches, which we can't emulate with the
current DSP design. So until we know which registers have separate
internal state that actually *is* initialized, I'm going to play it safe
and not break more games.
Thanks again to Jonas Quinn for the continued research into this issue.
EDIT: that said ... `MD works if((ENDX&0x30) > 0)` is only a 3:4 chance
that the game will work. That seems pretty unlikely that the odds of it
working are that low, given hardware testing by others in the past :/ I
thought if worked if `PITCH != 0` before, which would have been way more
likely.
The two remaining CPU cores that need major cleanup efforts are the
LR35902 and ARM cores. Both are very large, complicated, annoying cores
that will probably be better off as full rewrites from scratch. I don't
think I want to delay v103 in trying to accomplish that, however.
So I think it'll be best to focus on allowing the Mega Drive core to not
lock when processors are frozen waiting on a response from other
processors during a save state operation. Then we should be good for a
new release.
|
|
|
Tim Allen
|
50411a17d1 |
Update to v102r26 release.
byuu says:
Changelog:
- md/ym2612: initialize DAC sample to center volume [Cydrak]
- processor/arm: add accumulate mode extra cycle to mlal [Jonas
Quinn]
- processor/huc6280: split off algorithms, improve naming of functions
- processor/mos6502: split off algorithms
- processor/spc700: major revamp of entire core (~50% completed)
- processor/wdc65816: fixed several bugs introduced by rewrite
For the SPC700, this turns out to be very old code as well, with global
object state variables, those annoying `{Boolean,Natural}BitField` types,
`under_case` naming conventions, heavily abbreviated function names, etc.
I'm working to get the code to be in the same design as the MOS6502,
HuC6280, WDC65816 cores, since they're all extremely similar in terms of
architectural design (the SPC700 is more of an off-label
reimplementation of a 6502 core, but still.)
The main thing left is that about 90% of the actual instructions still
need to be adapted to not use the internal state (`aa`, `rd`, `dp`,
`sp`, `bit` variables.) I wanted to finish this today, but ran out of
time before work.
I wouldn't suggest too much testing just yet. We should wait until the
SPC700 core is finished for that. However, if some does want to and
spots regressions, please let me know.
|
|
|
Tim Allen
|
b73d918776 |
Update to v102r25 release.
byuu says:
Changelog:
- processor/arm: corrected MUL instruction timings [Jonas Quinn]
- processor/wdc65816: finished phase two of the rewrite
I'm really pleased with the visual results of the wdc65816 core rewrite.
I was able to eliminate all of the weird `{Boolean,Natural}BitRange`
templates, as well as the need to use unions/structs. Registers are now
just simple `uint24` or `uint16` types (technically they're `Natural<T>`
types, but then all of higan uses those), flags are now just bool types.
I also eliminated all of the implicit object state inside of the core
(aa, rd, dp, sp) and instead do all computations on the stack frame with
local variables. Through using macros to reference the registers and
individual parts of them, I was able to reduce the visual tensity of all
of the instructions. And by using normal types without implicit states,
I was able to eliminate about 15% of the instructions necessary, instead
reusing existing ones.
The final third phase of the rewrite will be to recode the disassembler.
That code is probably the oldest code in all of higan right now, still
using sprintf to generate the output. So it is very long overdue for a
cleanup.
And now for the bad news ... as with any large code cleanup, regression
errors have seeped in. Currently, no games are running at all. I've left
the old disassembler in for this reason: we can compare trace logs of
v102r23 against trace logs of v102r25. The second there's any
difference, we've spotted a buggy instruction and can correct it.
With any luck, this will be the last time I ever rewrite the wdc65816
core. My style has changed wildly over the ~10 years since I wrote this
core, but it's really solidifed in recent years.
|
|
|
Tim Allen
|
6e8406291c |
Update to v102r24 release.
byuu says
Changelog:
- FC: fixed three MOS6502 regressions [hex\_usr]
- GBA: return fetched instruction instead of 0 for unmapped MMIO
(passes all of endrift's I/O tests)
- MD: fix VDP control port read Vblank bit to test screen height
instead of hard-code 240 (fixes Phantasy Star IV)
- MD: swap USP,SSP when executing an exception (allows Super Street
Fighter II to run; but no sprites visible yet)
- MD: grant 68K access to Z80 bus on reset (fixes vdpdoc demo ROM from
freezing immediately)
- SFC: reads from $00-3f,80-bf:4000-43ff no longer update MDR
[p4plus2]
- SFC: massive, eight-hour cleanup of WDC65816 CPU core ... still not
complete
The big change this time around is the SFC CPU core. I've renamed
everything from R65816 to WDC65816, and then went through and tried to
clean up the code as much as possible. This core is so much larger than
the 6502 core that I chose cleaning up the code to rewriting it.
First off, I really don't care for the BitRange style functionality. It
was an interesting experiment, but its fatal flaw are that the types are
just bizarre, which makes them hard to pass around generically to other
functions as arguments. So I went back to the list of bools for flags,
and union/struct blocks for the registers.
Next, I renamed all of the functions to be more descriptive: eg
`op_read_idpx_w` becomes `instructionIndexedIndirectRead16`. `op_adc_b`
becomes `algorithmADC8`. And so forth.
I eliminated about ten instructions because they were functionally
identical sans the index, so I just added a uint index=0 parameter to
said functions. I added a few new ones (adjust→INC,DEC;
pflag→REP,SEP) where it seemed appropriate.
I cleaned up the disaster of the instruction switch table into something
a whole lot more elegant without all the weird argument decoding
nonsense (still need M vs X variants to avoid having to have 4-5
separate switch tables, but all the F/I flags are gone now); and made
some things saner, like the flag clear/set and branch conditions, now
that I have normal types for flags and registers once again.
I renamed all of the memory access functions to be more descriptive to
what they're doing: eg writeSP→push, readPC→fetch,
writeDP→writeDirect, etc. Eliminated some of the special read/write
modes that were only used in one single instruction.
I started to clean up some of the actual instructions themselves, but
haven't really accomplished much here. The big thing I want to do is get
rid of the global state (aa, rd, iaddr, etc) and instead use local
variables like I am doing with my other 65xx CPU cores now. But this
will take some time ... the algorithm functions depend on rd to be set
to work on them, rather than taking arguments. So I'll need to rework
that.
And then lastly, the disassembler is still a mess. I want to finish the
CPU cleanups, and then post a new WIP, and then rewrite the disassembler
after that. The reason being ... I want a WIP that can generate
identical trace logs to older versions, in case the CPU cleanup causes
any regressions. That way I can more easily spot the errors.
Oh ... and a bit of good news. v102 was running at ~140fps on the SNES
core. With the new support to suspend/resume WAI/STP, plus the internal
CPU registers not updating the MDR, the framerate dropped to ~132fps.
But with the CPU cleanups, performance went back to ~140fps. So, hooray.
Of course, without those two other improvements, we'd have ended up at
possibly ~146-148fps, but oh well.
|
|
|
Tim Allen
|
cea64b9991 |
Update to v102r23 release.
byuu says:
Changelog:
- rewrote the 6502 CPU core from scratch. Now called MOS6502,
supported BCD mode
- Famicom core disables BCD mode via MOS6502::BCD = 0;
- renamed r65816 folder to wdc65816 (still need to rename the actual
class, though ...)
Note: need to remove build rules for the now renamed r6502, r65816
objects from processor/GNUmakefile.
So this'll seem like a small WIP, but it was a solid five hours to
rewrite the entire 6502 core. The reason I wanted to do this was because
the old 6502 core was pretty sloppy. My coding style improved a lot, and
I really liked how the HuC6280 CPU core came out, so I wanted the 6502
core to be like that one.
The core can now support BCD mode, so hopefully that will prove useful
to hex\_usr and allow one core to run both the NES and his Atari 2600
cores at some point.
Note that right now, the core doesn't support any illegal instructions.
The old core supported a small number of them, but were mostly the no
operation ones. The goal is support all of the illegal instructions at
some point.
It's very possible the rewrite introduced some regressions, so thorough
testing of the NES core would be appreciated if anyone were up for it.
|
|
|
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
|
a4629e1f64 |
Update to v102r21 release.
byuu says:
Changelog:
- GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn]
- R65816: added support for yielding/resuming from WAI/STP¹
- SFC: removed status.dmaCounter functionality (also fixes possible
TAS desync issue)
- tomoko: added support for combinatorial inputs [hex\_usr\]²
- nall: fixed missing return value from Arithmetic::operator--
[Hendricks266]
Now would be the time to start looking for major regressions with the
new GBA PPU renderer, I suppose ...
¹: this doesn't matter for the master thread (SNES CPU), but is
important for slave threads (SNES SA1). If you try to save a state and
the SA1 is inside of a WAI instruction, it will get stuck there forever.
This was causing attempts to create a save state in Super Bomberman
- Panic Bomber W to deadlock the emulator and crash it. This is now
finally fixed.
Note that I still need to implement similar functionality into the Mega
Drive 68K and Z80 cores. They still have the possibility of deadlocking.
The SNES implementation was more a dry-run test for this new
functionality. This possible crashing bug in the Mega Drive core is the
major blocking bug for a new official release.
²: many, many thanks to hex\_usr for coming up with a really nice
design. I mostly implemented it the exact same way, but with a few tiny
differences that don't really matter (display " and ", " or " instead of
" & ", " | " in the input settings windows; append → bind;
assignmentName changed to displayName.)
The actual functionality is identical to the old higan v094 and earlier
builds. Emulated digital inputs let you combine multiple possible keys
to trigger the buttons. This is OR logic, so you can map to eg
keyboard.up OR gamepad.up for instance. Emulated analog inputs always
sum together. Emulated rumble outputs will cause all mapped devices to
rumble, which is probably not at all useful but whatever. Hotkeys use
AND logic, so you have to press every key mapped to trigger them. Useful
for eg Ctrl+F to trigger fullscreen.
Obviously, there are cases where OR logic would be nice for hotkeys,
too. Eg if you want both F11 and your gamepad's guide button to trigger
the fullscreen toggle. Unfortunately, this isn't supported, and likely
won't ever be in tomoko. Something I might consider is a throw switch in
the configuration file to swap between AND or OR logic for hotkeys, but
I'm not going to allow construction of mappings like "(Keyboard.Ctrl and
Keyboard.F) or Gamepad.Guide", as that's just too complicated to code,
and too complicated to make a nice GUI to set up the mappings for.
|
|
|
Tim Allen
|
3bcf3c24c9 |
Update to v102r20 release.
byuu says:
Changelog:
- nall: `#undef OUT` on Windows platform
- GBA: add missing CPU prefetch state to serialization (this was
breaking serialization in games using ROM prefetch)
- GBA: reset all PPU data in the power() function (some things were
missing before, causing issues on reset)
- GBA: restored horizontal mosaic emulation to the new pixel-based
renderer
- GBA: fixed tilemap background horizontal flipping (Legend of Spyro -
warning screen)
- GBA: fixed d8 bits of scroll registers (ATV - Thunder Ridge Racers -
menu screen)
- SFC: DRAM refresh ticks the ALU MUL/DIV registers five steps forward
[reported by kevtris]
- SFC: merged dmaCounter and autoJoypadCounter into new shared
clockCounter
- left stub for old dmaCounter so that I can do some traces to
ensure the new code's 100% identical
GBA save states would have been broken since whenever I emulated ROM
prefetch. I guess not many people are using the GBA core ...
|
|
|
Tim Allen
|
1ca4609079 |
Update to v102r18 release.
byuu says:
This WIP fixes all the critical pending issues I had open. I'm sure
there's many more that simply didn't make their way into said list. So
by all means, please report important issues you're aware of so they can
get fixed.
Changelog:
- ruby: add variable texture support to GDI video driver [bug
reported by Cydrak]
- ruby: minor cleanups to XShm video driver
- ruby: fix handling of up+down, left+right hat cases for XInput
driver [bug reported by Cydrak]
- nall: fixed vector class so that compilation with GCC 7.1 should
succeed [SuperMikeMan]
- sfc: initialize most DSP registers to random values to fix Magical
Drop [Jonas Quinn]
- sfc: lower PPU brightness when luma=0 from 50% scale to 25% scale;
helps scenes like Final Fantasy III's intro
|
|
|
Tim Allen
|
04072b278b |
Update to v102r16 release.
byuu says:
Changelog:
- Emulator::Stream now allows adding low-pass and high-pass filters
dynamically
- also accepts a pass# count; each pass is a second-order biquad
butterworth IIR filter
- Emulator::Stream no longer automatically filters out >20KHz
frequencies for all streams
- FC: added 20Hz high-pass filter; 20KHz low-pass filter
- GB: removed simple 'magic constant' high-pass filter of unknown
cutoff frequency (missed this one in the last WIP)
- GB,SGB,GBC: added 20Hz high-pass filter; 20KHz low-pass filter
- MS,GG,MD/PSG: added 20Hz high-pass filter; 20KHz low-pass filter
- MD: added save state support (but it's completely broken for now;
sorry)
- MD/YM2612: fixed Voice#3 per-operator pitch support (fixes sound
effects in Streets of Rage, etc)
- PCE: added 20Hz high-pass filter; 20KHz low-pass filter
- WS,WSC: added 20Hz high-pass filter; 20KHz low-pass filter
So, the point of the low-pass filters is to remove frequencies above
human hearing. If we don't do this, then resampling will introduce
aliasing that results in sounds that are audible to the human ear. Which
basically an annoying buzzing sound. You'll definitely hear the
improvement from these in games like Mega Man 2 on the NES. Of course,
these already existed before, so this WIP won't sound better than
previous WIPs.
The high-pass filters are a little more complicated. Their main role is
to remove DC bias and help to center the audio stream. I don't
understand how they do this at all, but ... that's what everyone who
knows what they're talking about says, thus ... so be it.
I have set all of the high-pass filters to 20Hz, which is below the
limit of human hearing. Now this is where it gets really interesting ...
technically, some of these systems actually cut off a lot of range. For
instance, the GBA should technically use an 800Hz high-pass filter when
output is done through the system's speakers. But of course, if you plug
in headphones, you can hear the lower frequencies.
Now 800Hz ... you definitely can hear. At that level, nearly all of the
bass is stripped out and the audio is very tinny. Just like the real
system. But for now, I don't want to emulate the audio being crushed
that badly.
I'm sticking with 20Hz everywhere since it won't negatively affect audio
quality. In fact, you should not be able to hear any difference between
this WIP and the previous WIP. But theoretically, DC bias should mostly
be removed as a result of these new filters. It may be that we need to
raise the values on some cores in the future, but I don't want to do
that until we know for certain that we have to.
What I can say is that compared to even older WIPs than r15 ... the
removal of the simple one-pole low-pass and high-pass filters with the
newer three-pass, second-order filters should result in much better
attenuation (less distortion of audible frequencies.) Probably not
enough to be noticeable in a blind test, though.
|
|
|
Tim Allen
|
0bf2c9d4e1 |
Update to v102r13 release.
byuu says:
Changelog:
- removed Emulator::Interface::videoFrequency(), audioFrequency()¹
- (MS,GG,MD)/PSG: removed inversion on noise channel LFSR update
[mic_]
- MD/PSG: lowered volume to match YM2612 volume
- MD/YM2612: added Cydrak's emulation of FM channels and LFO²
¹: These were no longer used by the UI. The video frequency is
adaptive on many systems. And the audio frequency is meaningless due to
Emulator::Audio always outputting a consistent frequency specified by
the UI. Plus, take the Genesis where there's two sound chips running at
different frequencies. So, these had to go.
²: Due to some lurking bugs, the audio is completely broken
unfortunately. Will need to be debugged :(
First pass looking for any typos didn't yield any obvious results.
|
|
|
Tim Allen
|
68f04c3bb8 |
Update to v102r10 release.
byuu says: Changelog: - removed Emulator::Interface::Capabilities¹ - MS: improved the PSG emulation a bit - MS: added cheat code support - MS: added save state support² - MD: emulated the PSG³ ¹: there's really no point to it anymore. I intend to add cheat codes to the GBA core, as well as both cheat codes and save states to the Mega Drive core. I no longer intend to emulate any new systems, so these values will always be true. Further, the GUI doesn't respond to these values to disable those features anymore ever since the hiro rewrite, so they're double useless. ²: right now, the Z80 core is using a pointer for HL-\>(IX,IY) overrides. But I can't reliably serialize pointers, so I need to convert the Z80 core to use an integer here. The save states still appear to work fine, but there's the potential for an instruction to execute incorrectly if you're incredibly unlucky, so this needs to be fixed as soon as possible. Further, I still need a way to serialize array<T, Size> objects, and I should also add nall::Boolean serialization support. ³: I don't have a system in place to share identical sound chips. But this chip is so incredibly simple that it's not really much trouble to duplicate it. Further, I can strip out the stereo sound support code from the Game Gear portion, so it's even tinier. Note that the Mega Drive only just barely uses the PSG. Not at all in Altered Beast, and only for a tiny part of the BGM music on Sonic 1, plus his jump sound effect. |
|
|
Tim Allen
|
fa6cbac251 |
Update to v102r06 release.
byuu says:
Changelog:
- added higan/emulator/platform.hpp (moved out Emulator::Platform from
emulator/interface.hpp)
- moved gmake build paramter to nall/GNUmakefile; both higan and
icarus use it now
- added build=profile mode
- MD: added the region select I/O register
- MD: started to add region selection support internally (still no
external select or PAL support)
- PCE: added cycle stealing when reading/writing to the VDC or VCE;
and when using ST# instructions
- PCE: cleaned up PSG to match the behavior of Mednafen (doesn't
improve sound at all ;_;)
- note: need to remove loadWaveSample, loadWavePeriod
- HuC6280: ADC/SBC decimal mode consumes an extra cycle; does not set
V flag
- HuC6280: block transfer instructions were taking one cycle too many
- icarus: added code to strip out PC Engine ROM headers
- hiro: added options support to BrowserDialog
The last one sure ended in failure. The plan was to put a region
dropdown directly onto hiro::BrowserDialog, and I had all the code for
it working. But I forgot one important detail: the system loads
cartridges AFTER powering on, so even though I could technically change
the system region post-boot, I'd rather not do so.
So that means we have to know what region we want before we even select
a game. Shit.
|
|
|
Tim Allen
|
ee7662a8be |
Update to v102r04 release.
byuu says:
Changelog:
- Super Game Boy support is functional once again
- new GameBoy::SuperGameBoyInterface class
- system.(dmg,cgb,sgb) is now Model::(Super)GameBoy(Color) ala the PC
Engine
- merged WonderSwanInterface, WonderSwanColorInterface shared
functions to WonderSwan::Interface
- merged GameBoyInterface, GameBoyColorInterface shared functions to
GameBoy::Interface
- Interface::unload() now calls Interface::save() for Master System,
Game Gear, Mega Drive, PC Engine, SuperGrafx
- PCE: emulated PCE-CD backup RAM; stored per-game as save.ram (2KiB
file)
- this means you can now save your progress in games like Neutopia
- the PCE-CD I/O registers like BRAM write protect are not
emulated yet
- PCE: IRQ sources now hold the IRQ line state, instead of the CPU
holding it
- this fixes most SuperGrafx games, which were fighting over the
VDC IRQ line previously
- PCE: CPU I/O $14xx should return the pending IRQ bits even if IRQs
are disabled
- PCE: VCE and the VDCs now synchronize to each other; fixes pixel
widths in all games
- PCE: greatly increased the accuracy of the VPC priority selection
code (windows may be buggy still)
- HuC6280: PLA, PLX, PLY should set Z, N flags; fixes many game bugs
[Jonas Quinn]
The big thing I wanted to do was enslave the VDC(s) to the VCE. But
unfortunately, I forgot about the asynchronous DMA channels that each
VDC supports, so this isn't going to be possible I'm afraid.
In the most demanding case, Daimakaimura in-game, we're looking at 85fps
on my Xeon E3 1276v3. So ... not great, and we don't even have sound
connected yet.
We are going to have to profile and optimize this code once sound
emulation and save states are in.
Basically, think of it like this: the VCE, VDC0, and VDC1 all have the
same overhead, scheduling wise (which is the bulk of the performance
loss) as the dot-renderer for the SNES core. So it's like there's three
bsnes-accuracy PPU threads running just for video.
-----
Oh, just a fair warning ... the hooks for the SGB are a work in
progress.
If anyone is working on higan or a fork and want to do something similar
to it, don't use it as a template, at least not yet.
Right now, higan looks like this:
- Emulator::Video handles the platform→videoRefresh calls
- Emulator::Audio handles the platform→audioSample calls
- each core hard-codes the platform→inputPoll, inputRumble calls
- each core hard-codes calls to path, open, load to process files
- dipSettings and notify are specialty hacks, neither are even hooked
up right now to anything
With the SGB, it's an emulation core inside an emulation core, so
ideally you want to hook all of those functions. Emulator::Video and
Emulator::Audio aren't really abstractions over that, as the GB core
calls them and we have to special case not calling them in SGB mode.
The path, open, load can be implemented without hooks, thanks to the UI
only using one instance of Emulator::Platform for all cores. All we have
to do is override the folder path ID for the "Game Boy.sys" folder, so
that it picks "Super Game Boy.sfc/" and loads its boot ROM instead.
That's just a simple argument to GameBoy::System::load() and we're done.
dipSettings, notify and inputRumble don't matter. But we do also have to
hook inputPoll as well.
The nice idea would be for SuperFamicom::ICD2 to inherit from
Emulator::Platform and provide the desired functions that we need to
overload. After that, we'd just need the GB core to keep an abstraction
over the global Emulator::platform\* handle, to select between the UI
version and the SFC::ICD2 version.
However ... that doesn't work because of Emulator::Video and
Emulator::Audio. They would also have to gain an abstraction over
Emulator::platform\*, and even worse ... you'd have to constantly swap
between the two so that the SFC core uses the UI, and the GB core uses
the ICD2.
And so, for right now, I'm checking Model::SuperGameBoy() -> bool
everywhere, and choosing between the UI and ICD2 targets that way. And
as such, the ICD2 doesn't really need Emulator::Platform inheritance,
although it certainly could do that and just use the functions it needs.
But the SGB is even weirder, because we need additional new signals
beyond just Emulator::Platform, like joypWrite(), etc.
I'd also like to work on the Emulator::Stream for the SGB core. I don't
see why we can't have the GB core create its own stream, and let the
ICD2 just use that instead. We just have to be careful about the ICD2's
CPU soft reset function, to make sure the GB core's Stream object
remains valid. What I think that needs is a way to release an
Emulator::Stream individually, rather than calling
Emulator::Audio::reset() to do it. They are shared\_pointer objects, so
I think if I added a destructor function to remove it from
Emulator::Audio::streams, then that should work.
|