Fix envelope timing and key-on delay, jump to the repeat address on sample end.
Capture CD audio before volume processing,
Fix sign handling for cd-rom volume and pitch modulation
ref: https://psx-spx.consoledev.net/soundprocessingunitspu/
Devices are now in charge of their own timing, fix Memory Card and Controller timing to be closer to hardware.
Fixes an infinite loop polling for memory cards in Ace Combat 3 (USA)
Clearing DPC_FREEZE calls flushCommands even when END equals CURRENT. Previously, this set pipeBusy and startGclk without executing any commands, leaving an initially idle RDP reporting busy.
Return before setting the busy flags when no forward command range is available. Preserve existing busy state for starved pipelines and leave START/END latching unchanged.
The following are new behavoirs in the python tooling:
Extract DIP switch definitions, input mappings, and other metadata by parsing tables directly from the MAME source tree; this lifts metadata (such as dip switch names and bit-values and button labels) into Arcade.bml, no code is lifted.
Support custom overrides for information that is missing or insufficient in MAME's database.
Allow ROMs to be excluded from the generated database, including incomplete dumps, unsupported bootlegs, and non-game software.
Extend the existing per-system input override functionality to support game-specific controller mappings.
The intended workflow is for users to configure their Virtual Pad once. The Virtual Pad attempts to map inputs to each system's controller based on the physical position of its buttons.
Users can then customize mappings by adding overrides for specific inputs per-system, or per-game. Per-game overrides can only be configured while the relevant game is loaded.
ares attempts to strip common Disc, Disk, Side and Part suffixes from game titles, allowing multi-disc games to share the same input configuration.
Introduce a shared DIP switch implementation for arcade systems, replacing system-specific implementations.
Neo Geo:
Implement the NEC uPD4990A real-time clock.
Implement the MVS hardware watchdog.
Fix IRQ acknowledgement register handling to that only pending IRQs can be acknowledged
Move ROM decryption and protection handling into runtime PCB emulation, more closely reflecting the behaviour of original hardware.
Add support for additional protection schemes and game-specific memory mappers.
SG-1000A:
Add support for the encrypted Z80 variant used by Championship Wrestling.
Introduce separate opcode fetch and data read paths for the Z80, allowing accurate emulation of hardware-dependent decryption.
Portions of the ROM decryption and protection implementations are derived from MAME. Only code distributed under permissive licences, including the BSD 3-Clause License, has been incorporated.
All MAME-derived implementations are explicitly identified in the source code, with the applicable copyright notices and licence terms preserved in the project's LICENSE file.
To measure texture cache timing, textured draws previously waited for
the renderer to catch up before emulation could continue.
Now we wait only when the GPU becomes ready for another draw.
draw timing observed by the game is unaffected.
Moon Patrol's HSCROL write was landing too early in ares, corrupting the mountains
Altirra Hardware Reference Manual was used to determine correct behavoir, which I believe to be trustworthy as the introduction specifies that "This document attempts to describe the hardware in detail as the target to which the emulator aspires to imitate"
Weave (default): combines the current field with the previous field. this preserves detail but may introduce combing during motion. This is how ares behaved historically.
Bob: displays the current field and interpolates missing lines. This prevents motion combing but causes a noticable loss of vertical detail and may flicker thin lines.
Blend: displays an average of consecutive bobbed fields. Behaves similar to bob, but swaps flicker for motion blur.
Phosphor: displays only the currently displaying field while simulating phosphor decay. This Produces a darker image with visible scanlines and may flicker, but is closer to how a real CRT handles interlaced video.
nocash DIAG's hardware cache tests measure miss penalties of ~60 CPU
clocks for eight entries and ~120 clocks for sixteen entries. This is
approximately 12 GPU clocks per 8-byte refill.
We use 13 clocks here as it better fits JaCzekanski's GPU bandwidth
test; textured drawing timings now measure within ~1-2% of the hardware
baseline.
- prevent discarded polygons from counting in draw timing calculations
- fix depth mode changes applying one frame too late
- fix cd-rom stop command
- prevent MDEC output fifo from losing data when full and reduce output size to a more realistic 32 words-
Rationale is that the clang64 ci is resulting in a build that drops as low as 40vps in FMV sequences in the PS1 core, vs 90vps in the same scene for clang-cl
Pinning a known-performant version of clang was considered (local testing proved clang22 produces more performant builds than clang20), but this is not viable with how msys2 is managed. Investigation concluded that we cannot reliably update the clang msys environment; just running 'update:true' breaks the build due to a ymfm issue with the clang23 runtime, and installing the 'clang22' packages still uses the clang23 runtimes, it only pins the compiler itself.
A block can end before an instruction that has a gdb breakpoint. Its
last instruction can then be straight-line code, which does not commit
the pipeline PC. The block exited with ipu.pc at the last commit point,
so the CPU ran the instructions after that point a second time. If that
point was an internal entry of the same block, the CPU looped forever
and the breakpoint never hit.
Commit the pipeline PC on the last instruction of every block. All other
block ends already commit there, so code without breakpoints is
unchanged.
- more accurately model the CPU bus, write buffering and cache behavior
- improve DMA arbitration, chopping, transfer timing, and interaction with CPU
- rework CD-ROM command timing, deferred responses, interrupts, sector delivery, subchannel data, and disc session handling
- implement the GPU command FIFO, busy timing, texture caches, rasterization, and improve scanout accuracy
- improve timer synchronization, reset, interrupt, and blanking behavior
- improve peripheral, SPU, MDEC, and memory-mapped I/O timing
- add support for Datel Action Replay and Blaze Xplorer cartridges
- add support for the Pixel Accuracy toggle to enable per-pixel scanout (required by tajmiing demo)
These changes were validated against psxtest_cpx, psxtest_gpu, nocash diag.exe, JaCzekanski's tests, and the pcsx-redux CD-ROM torture tests.
Most of tests now pass, and known problematic games such as Monkey Hero are working.
Framebuffer output matches expected hardware output pixel-for-pixel in the nocash diagnostics and psxtest_gpu primitive tests.
Timer test results generally remain within a small margin of hardware baseline results (when compared against the psx.log reference point shipped with the tests)
psxtest_cpx and psxtest_gpu do not initialize controllers correctly when launched directly from the BIOS. You must run them them through software that initializes the hardware first, such as a Datel Action Replay or Blaze Xplorer cartridge. These devices can be configured in Core settings. This issue exists on real hardware and is correct behavoir.
ares can now run the tajmiing demo and all its effects end-to-end.
tajmiing changes display registers at individual-pixel boundaries, so it requires the Pixel Accuracy option in Video settings. Scanline-level synchronization remains the default as oridnary software does not depend on mid-scanline register changes.
Latch the left and right edge matches independently until the next scanline, preserving the inclusive right edge. This prevents mid-line bounds writes from reopening a stopped window, as demonstrated by Mickey Magic and MiSTer SNES PR #508.
Serialize the latches and bump the SNES state format. Fixesares-emulator/ares#2645.
With FreeBSD 15.0 going EOL very soon, it is time to update the runner
in the CI to FreeBSD 15.1. This version is supported by Cross-Platform
GitHub Actions since version 1.3.0, and the runner is updated to the
currently newest version 1.6.0, which corresponds to the commit
https://github.com/cross-platform-actions/action/commit/e0b9770014ba65d5e0815f15b74031c3a635f641.
Using the operating system's shell for running commands inside steps is
deprecated. Cross-Platform GitHub Actions provides and recommends the
new custom shell cpa.sh instead, which the runner is now using.
This requires to split the "Build: FreeBSD" step into at least one
separate step for setting up the VM before executing commands in the
following steps. This opens up the opportunity to be more in line with
the Linux runner by installing the build dependencies in its own step,
"Install FreeBSD Dependencies".
Before installing dependencies, the runner now updates the preinstalled
packages in the VM via pkg upgrade -y. This ensures that the whole VM is
cohesively up-to-date.
Last but not least, the TARGET_PRESET environment variable must be set
in the "Build: FreeBSD" step with the --environment-variables option of
cpa.sh, or else it won't be propagated to the build environment.
Ported directly from bsnes PRs 377 and 401.
- When triggering a cache preload by writing to $7f48, update the pb register with the prepared program page
- When preloading a page, ignore all runtime checks and reload the page immediately
- Step 1+WS on both reads for cache, not just one
- Remove extra cycle on bus reads/writes
- Remove extra cycle on DMA to internal RAM (fixes excessive slowdown in Morph Moth fight)
On macoS, a binary executed directly by another process (e.g. a frontend
spawning and emulator) starts as an unregistered background process. It
must be promoted to a regular GUI application to reclaim focus.
Generic port menu callbacks could mutate scheduler threads and audio streams while the emulator worker was active. Route both disconnect and connect actions through one Program::Guard-protected helper and add a deterministic concurrent regression test.
The CPU keeps a free-running cycle counter (COUNT) that guest software
reads to measure elapsed time. Internally the emulator does not update
that counter after every instruction: cycles are accumulated in a
running clock and only folded into COUNT when the CPU synchronizes with
the rest of the machine. Reading the register returned the folded value
only, ignoring any cycles accumulated since the last fold, so the value
handed back to software could be stale.
How stale depends on how often synchronization happens, which is why
this was mostly invisible with the interpreter and clearly wrong with
the recompiler. The interpreter synchronizes after every instruction, so
at most one instruction worth of cycles was missing. The recompiler
translates a whole run of instructions into a single unit of host code
and only folds the accumulated cycles at its boundaries, so several
consecutive reads of COUNT inside one such unit all returned the exact
same number. Code that reads the counter repeatedly to check that time
is moving forward would see it standing still; the test_timer_ticks test
in the libdragon test suite fails this way, with two successive readings
comparing equal.
Track how many cycles have already been folded into COUNT in a separate
countClock field, so the cycles accumulated since then can be recovered
at any point. Reading COUNT now folds those pending cycles in first,
which both returns an up-to-date value and evaluates the COMPARE match
at the same moment, keeping the register and the timer interrupt
consistent with each other. Writing COUNT or COMPARE folds them in as
well, so the pending cycles are attributed to the old value rather than
being added on top of the newly written one.
The CPU has a free-running cycle counter (COUNT) and a programmable
target register (COMPARE); an interrupt is raised whenever the counter
reaches the target. The check for that event was written as
"count < compare && count + elapsed >= compare", which assumes the
target always lies ahead of the current counter value in plain
arithmetic order. Since both registers are unsigned, that assumption
breaks as soon as the target is behind the counter, and it breaks
permanently when the target is exactly zero: no unsigned value is ever
less than zero, so the first half of the condition is never true and the
interrupt is never raised at all.
That is not a corner case in practice. The counter is only 32 bits wide
and wraps around roughly every 90 seconds, so software that wants to
maintain a wider timestamp typically arms the target at zero in order to
be notified on every wrap. libdragon did exactly this: timer_init()
programs COMPARE to zero and used the resulting interrupt to increment
the high half of a 64-bit tick counter. Under ares that interrupt never
arrived, so the high half was never incremented and timer_ticks() went
backwards across a wrap, which is what the test_timer_ticks test in the
libdragon test suite reports.
Replace the ordered comparison with a modular distance computed over the
counter's full range: the number of ticks remaining until the target is
(compare - count) truncated to the counter width, and the interrupt
fires when at least that many ticks elapse. This behaves identically
when the target is ahead of the counter and additionally handles the
wrap-around case, including a target of zero. The counter update, the
crossing check and the cycle profiling counters are moved together into
a new stepCount() helper so that a single implementation stays
authoritative.
The client can now ask the stub to deliver chosen signals without stopping
or reporting (gdb sends QPassSignals automatically for signals configured
'handle <sig> nostop noprint pass'). Advertised in qSupported; the pass set
is client state, cleared on connect/disconnect like breakpoints.
## Overview
Adds Nintendo Vs. UniSystem support to the ares FC core. Games remain in
MAME
ZIP format and load through the existing Arcade path, without going
through
the iNES detection path used by regular Famicom software.
The implementation covers MAME metadata generation, parent ZIP lookup,
Vs. PPU
and palette behavior, cartridge boards, protection logic, cabinet I/O,
DIP
switches, controller wiring, Zapper input, and save states. A total of
41 Vs.
UniSystem sets have been validated. Vs. DualSystem, non-standard bootleg
hardware, and other configurations that have not yet been implemented
are
explicitly marked as unsupported instead of being started with the
UniSystem
model.
## Why `vsnes.py` is separate
MAME groups three substantially different hardware families in
`nintendo/vsnes.cpp`:
- Vs. UniSystem with one CPU and one PPU;
- Vs. DualSystem with two CPUs and two PPUs;
- non-standard bootleg hardware built around a Z80 and SN76489.
The generic MAME parser reads common data such as machine entries, ROM
regions,
and DIP switches. Those fields alone are not enough to determine which
Vs.
hardware model a game requires. The three families have different
runtime
structures and cannot share a single emulation path.
Configurations also differ between Vs. UniSystem games. The PPU,
palette,
cartridge board, protection logic, controller wiring, Zapper support,
and DIP
settings may all vary by set. The core needs explicit configuration data
rather than inferring hardware from a game title.
`vsnes.py` reuses the MAME XML and ROM-region information produced by
the
generic parser, then adds hardware classification and per-game
configuration.
It generates a deterministic `VsSystem.bml` database. At runtime,
supported
sets select the corresponding FC hardware model from this metadata,
while
DualSystem and bootleg sets are rejected with a clear explanation.
## Video
The combined video shows the attract modes of all 41 supported games.
Each
game is shown for approximately ten seconds, with its name in the
upper-right corner.
https://github.com/user-attachments/assets/46a59b2b-f64a-40ce-a870-1351d5df3948https://github.com/user-attachments/assets/7927d1d0-4349-4f4b-9092-feeb7b0ac127https://github.com/user-attachments/assets/d162c834-b227-497b-afe7-2f766f3ab42ahttps://github.com/user-attachments/assets/12d7b58e-7cd5-4bbf-b040-9d615e654e0chttps://github.com/user-attachments/assets/a8708059-4369-48e1-be1f-42d15099d7a8
## Screenshots
The contact sheet contains one attract-mode screenshot for each game,
composed
at the original capture resolution.
<img width="3920" height="5328" alt="contact-sheet"
src="https://github.com/user-attachments/assets/e111cf05-4a49-4b0d-9719-082b2b925342"
/>
## Supported sets
The following 41 Vs. UniSystem MAME sets have been validated for loading
and
attract-mode operation:
| No. | MAME short name | Game |
| ---: | --- | --- |
| 1 | `btlecity` | Vs. Battle City |
| 2 | `cluclu` | Vs. Clu Clu Land |
| 3 | `cstlevna` | Vs. Castlevania |
| 4 | `drmario` | Vs. Dr. Mario |
| 5 | `duckhunt` | Vs. Duck Hunt (set DH3 E) |
| 6 | `excitebk` | Vs. Excitebike (set EB4-3 E) |
| 7 | `excitebkj` | Vs. Excitebike (set EB4-4 A) |
| 8 | `excitebko` | Vs. Excitebike (set EB4-3 ?) |
| 9 | `goonies` | Vs. The Goonies (set E) |
| 10 | `hogalley` | Vs. Hogan's Alley (set HA4-1 E-1) |
| 11 | `iceclimb` | Vs. Ice Climber (set IC4-4 B-1) |
| 12 | `iceclimba` | Vs. Ice Climber (set IC4-4 ?) |
| 13 | `jajamaru` | Vs. Ninja Jajamaru Kun (Japan) |
| 14 | `ladygolf` | Vs. Stroke & Match Golf (Ladies Version, set LG4 ?)
|
| 15 | `ladygolfe` | Vs. Stroke & Match Golf (Ladies Version, set LG4 E)
|
| 16 | `nvs_machrider` | Vs. Mach Rider (Endurance Course Version) |
| 17 | `nvs_machridera` | Vs. Mach Rider (Fighting Course Version, set
MR4-1 A) |
| 18 | `nvs_mightybj` | Vs. Mighty Bomb Jack (Japan) |
| 19 | `nvs_platoon` | Vs. Platoon |
| 20 | `rbibb` | Vs. Atari R.B.I. Baseball (set 1) |
| 21 | `rbibba` | Vs. Atari R.B.I. Baseball (set 2) |
| 22 | `skatekds` | Vs. Skate Kids. (Graphic hack of Super Mario Bros.)
|
| 23 | `smgolf` | Vs. Stroke & Match Golf (Men Version, set GF4-2 F) |
| 24 | `smgolfb` | Vs. Stroke & Match Golf (Men Version, set GF4-2 ?) |
| 25 | `smgolfj` | Vs. Stroke & Match Golf (Men Version) (Japan, set GF3
B) |
| 26 | `starlstr` | Vs. Star Luster |
| 27 | `suprmrio` | Vs. Super Mario Bros. (set SM4-4 E) |
| 28 | `suprmrioa` | Vs. Super Mario Bros. (set ?, harder) |
| 29 | `supxevs` | Vs. Super Xevious |
| 30 | `tkoboxng` | Vs. T.K.O. Boxing |
| 31 | `topgun` | Vs. Top Gun |
| 32 | `vsfdf` | Vs. Freedom Force |
| 33 | `vsgradus` | Vs. Gradius (US, set GR E) |
| 34 | `vsgshoe` | Vs. Gumshoe (set GM5) |
| 35 | `vspinbal` | Vs. Pinball (US, set PN4 E-1) |
| 36 | `vspinbalj` | Vs. Pinball (Japan, set PN3 B) |
| 37 | `vsskykid` | Vs. Super SkyKid |
| 38 | `vsslalom` | Vs. Slalom |
| 39 | `vssoccer` | Vs. Soccer (set SC4-2 A) |
| 40 | `vssoccera` | Vs. Soccer (set SC4-3 ?) |
| 41 | `vstetris` | Vs. Tetris |
## Changes
- Accumulate relative mouse movement until it is read and consumed by an
input mapping.
- Maintain an independent read position for each `InputRelative`
binding.
- Synchronize relative input positions when input bindings or mouse
capture state changes.
- Apply the same relative-motion handling to the Raw Input, NSEvent, and
Xlib mouse drivers.
## Motivation
In my testing, `InputManager::poll()` is called approximately once every
8ms on my system, with observed intervals generally no shorter than 5ms.
At 60Hz, each frame lasts approximately 16.67ms, so input is normally
polled twice per frame.
Each poll retrieves the mouse-axis movement accumulated during the
preceding approximately 8ms. However, emulator cores generally read
relative input only once per frame. This means that `InputManager` may
complete its second poll before the core reads the movement value.
The previous implementation retained only the mouse-axis movement
reported by the most recent poll. The second poll therefore overwrote
the result of the first, allowing the core to observe only the movement
from the latest approximately 8ms. Mouse movement from the earlier
approximately 8ms of the frame was lost.
This change accumulates all relative mouse movement produced between
consecutive core input reads. As a result, even when
`InputManager::poll()` runs multiple times within a single frame, the
core can still retrieve the complete mouse-axis movement accumulated
during that period.
## Abstract
Support the absolute mouse movement events in the native input driver
for Windows.
Modifications:
- Convert the absolute original input coordinates to relative motion
increments;
- Handle the coordinate spaces of the main desktop and virtual desktop
while maintaining independent absolute coordinate positions;
- Add locking in the `poll` function to prevent partial data loss in the
event of multi-threaded competition.
## Reasons
When I used 'Windows Remote Desktop Connection' for remote debugging, I
found that 'win raw input' did not provide the corresponding 'relative
mouse event'. Since 'ruby' ignored the 'absolute mouse event', the input
relying on the mouse (such as the crosshair of a gun sight) could
receive key operations, but it was unable to move.
Fixes a video mixing issue which affected graphics in the "Demon's
Judgement" LDRom2 game for the Pioneer LaserActive with the NEC PAC.
---------
Co-authored-by: Roger Sanders <[email protected]>
This uses all the latest research on the exact behavior of flash chips,
including quirks of specific models, as documented on n64brew.
Thanks to the new PI bus emulation, it is now possible to correctly
implement many quirks "naturally", because of the simple way flash
chips interact with the bus.
PIDevice is now a generic device sitting on the PI bus that is able
to reply to addresses in any range. Now each device knows the addresses
it is listening to, which is how the hardware works.
PI accesses are only 16-bit wide, and both DMA and CPU I/O are built
upon it. There is no more code to mimic the weird access patterns for
misaligned addresses or different access sizes, as everything descends
naturally from the way the bus works (as it should be).
Open bus is simulated by latching the last value on the bus, which is
what happens on hardware.
This opens the door to more accurate emulation of chips which abuse the
bus in weird ways (like flash memories).
We always update hidden bits on memory writes. Given that in most cases
this is done during dcache flushes, we use SIMD to optimize that code
path and update a whole cacheline's worth with a few opcodes.
Also take the chance to add a mi/bus.hpp that implements the special
MI modes (ebus, repeat, upper), so that they naturally only apply
to CPU-issued reads.
This finally allows Ares to fully run through the IPL3 to fully initialize
the RAM chips. It tries to simulate also all the various non-working
conditions so that a change in a IPL3 that results in failure to boot,
should also fail in Ares. Obviously this would be a very long journey,
but at least all major failures are covered here.
Default RDRAM linear mapping is still kept as default as a fast path
in the recompiler to avoid slowdowns in normal situations. Given
that parallel-RDP doesn't support non-linear mappings, we just emit
a warning in that case.
Invalid current values will result in degraded RAM accesses like on real
hardware. This is also necessary to fully pass the current calibration
algorithm and to provide entropy (collected by libdragon's IPL3).
If we hit the final branch of the if in the read hook and `byteCount` is
not a multiple of 4, the remaining bytes are never read, but the buffer
is still sent back with unset data. This adds one more iteration to the
loop if necessary to read another word, and then shrinks the string to
the correct size.
In the write hook, the simple cases will do a write and then break the
switch and end up in the conditionals, potentially writing twice. So I
switched the breaks to returns.
The final conditional code in the write hook also cannot handle data
sizes that aren't multiples of 4 bytes, but I'm less confident about how
to fix that. Happy to add it to this PR if someone who knows what
they're doing advises.
Also trimmed some trailing whitespace.
Before we were drawing the frame according to the VI registers at line
0. After a recent change (I believe
https://github.com/ares-emulator/ares/commit/31526ded9196b046b0b5ce1769f14335eba9cc33
), we now draw it according to VI registers when display area begins.
This means that we take into account the vblank interrupt that normally
changes the registers so the field swapping workaround is not needed
anymore.
Some platforms experienced very poor performance with the SDL3 audio
driver, especially in combination with a demanding core like the N64.
It is assumed that SDL couldn't keep up filling the output device buffer
with the audio data from the input queue buffer. Increasing the amount
of generated input data before feeding it to the device buffer has shown
to greatly improve the performance.
This sparked the following idea and change to how the SDL3 audio driver
fills its buffers: request a fixed-sized 10ms device buffer and apply
the latency to the input buffer, i.e. the input buffer holds a multiple
of 10ms worth of audio. This allows SDL to steadily consume audio from
the input buffer and feed it into the 10ms device buffer, while the user
can still control the latency.
Additionally add the value 30 to the possible latency options. This
allows users to specify a lower latency than 40 if 20 is just a tiny bit
shy of being good enough.
The renderSettingsLabel identifier isn't declared anymore after the
recent structural changes, but it's still referenced conditionally in
desktop-ui/settings/cores.cpp and breaks the build if the N64 core is
disabled:
/tmp/ares/desktop-ui/settings/cores.cpp:108:3: error: use of undeclared identifier 'renderSettingsLabel'
108 | renderSettingsLabel.setCollapsible(true).setVisible(false);
| ^
Remove it to fix the build.
Remove the build dependencies of the removed audio and input drivers,
now that SDL3 is the only supported driver.
Additional cleanup on FreeBSD:
- libX* and libglvnd are dependencies of sdl3 itself and can reasonable
be expected to continue to be so. This allows to remove them from the
list of explicit bulid dependencies.
- vulkan-loader provides libvulkan.so which is a dlopen'ed runtime
dependency of parallel-rdp used in the N64 core. It is not a build
dependency and can be removed (though it gets installed anyway as a
dependency of sdl3).
We were telling Vulkan to display a frame as per the VI configuration
at vblank (line 0). This is wrong since all games will actually use
vblank to configure VI for the new frame. Vulkan would thus draw the
*previous* frame, rather than the new one that was just created, causing
one full frame of latency. The correct point where to kick Vulkan is at
vstart, when the active display begins.
With CPU-based rendering in a double-buffering scenario (rather than
triple buffering), this means that the wrong framebuffer would always
be shown: the one that was just going to be drawn upon. Thus, we would
basically get a race between the emulated CPU writing to RDRAM and the
host Vulkan reading RDRAM.
The bug was hidden when using RDP rendering because RDP emulation also
goes through Vulkan, so it would basically be queued *after* the VI
drawing rather than *during* it.
Use the application stream format rather than the physical device format.
Some outputs, such as HDMI/TV devices with Dolby processing enabled,
may expose a multichannel device format even though ares is submitting
stereo float audio to SDL. Using the device format for queue sizing and
drain timing could make the blocking sync path sleep for the wrong
amount of time, causing the emulator to run too slowly.
General cleanup:
- avoid heap allocation for every audio packet
- add proper failure checks
- correctly teardown SDL_Audio on shutdown
Replace the old fixed multiplier window sizing model with configurable
viewport sizing.
Window sizes are now stored as target viewport dimensions rather than
being derived from the emulated screen. Standard presets have been
provided, as well as the option to specify a custom size.
Adaptive sizing has been reworked to treat the window size as target
bounds, the actual window will dynamically grow or shrink within this
boundary to preserve the correct aspect ratio.
Oversized window recovery has been changed to respect aspect ratio
and available workspace rather than a hardcoded reducton from the
monitors geometry.
Add an optional stable text identifier to HID devices and use it for
persisted input mappings when available.
SDL joypads now expose a GUID/slot identifier, so newly saved controller
mappings no longer depend on SDL serial or device path values that can
change across disconnects, reconnects, or app launches. This keeps
multiplayer controllers distinguishable by assigning slots per matching
GUID while avoiding unstable path-derived IDs.
The input mapping parser remains backward compatible with existing
numeric 0x<deviceID>/<group>/<input> mappings. Drivers that do not set a
stable identifier continue to save and load mappings using the existing
numeric HID device ID format.
Uncovered by new tests in n64-systemtest. The JIT wasn't tested because
little-endian is only supported in user-mode for now (RE=1), where
memory accesses must go through TLBs so they currently are not JIT'd.
Anyway the fix should be correct if we eventually uncover full
little-endian mode (with BE=0).
This is a mode available only in the user mode, activated when RE=0. It
facilitates running MIPS binary code that was build for a little-endian
architecture, assuming that the code/data was 8-byte swapped in memory
before running it.
It passes the new RE tests in n64-systemtest
Avoid keeping the dirty-byte mask live across store fast paths in
jitMemoryOpcode. Compute it at the end from Rs+i16 so temporary
register clobbers (eg. SDC1/SWL/SWR) cannot corrupt dirty tracking and
lead to stale cache data.
Terminals are now only hard jumps and the special opcodes that change
state key, timers, etc.
Internal branch targets in each block are also registered as JIT
entrypoints.
Opportunistic branch linking is now removed as not useful anymore.
While provably useful, the implementation is completely confusing. We
need to rework it from scratch at some point. The way it is written
now, it impedes further progress in other areas.
Emit loads and stores directly against fpu state via sreg(2), using the same
full- versus half-mode register layout as the interpreter (word selection and
pairing). COProcessor-unusable blocks still call the C++ helpers. Skip GPR
writes when MFC1/DMFC1 targets $zero. FPU word offsets use CPU::r64 in offsetof
to avoid colliding with the host Real type at file scope.
Add generic LMUL and DIVMOD helpers (32/64, signed/unsigned) and emit fast paths for MULT/MULTU, DIV/DIVU, DMULT/DMULTU, DDIV/DDIVU. Reserved-instruction and divide-by-zero cases stay on interpreter slow paths; DDIV avoids host INT64_MIN/-1 idiv overflow. Decoder no longer marks these opcodes as JitUseCallf or JitAddsExtraCyclesInternally.
Move callf synchronization to the paths that actually emit helper calls, and keep slow-path callf state restoration explicit. Rename jitMayCallf to jitUseCallf so the flag name matches its eager-call semantics.
Route opcode helper calls through a shared setup path that materializes PC and flushes deferred state on demand, so callf overhead is emitted where calls actually occur.
Move trap exception cases to deferred slow paths and generate direct JIT code for the remaining 64-bit shift immediates, keeping reserved-instruction handling and R0 writeback behavior on the fast path.
Expand CPU JIT codegen for DADDIU, DSLLV/DSRLV/DSRAV, DADDU, DSUB, and DSUBU while preserving exact overflow and reserved-instruction behavior through helper fallbacks. Factor 64-bit reserved-instruction gating into a shared helper and collapse duplicated slow-path conditions to keep hot paths compact.
Move ADD/ADDI/DADD/DADDI hot paths to direct codegen with deferred slow-path helpers so overflow and reserved-instruction behavior stay exact without polluting the hot block body. Centralize state-key bit semantics in a typed accessor wrapper so JIT-time folding no longer depends on hardcoded bit masks.
Emit state test/update and endblock jumps only when branch/helper pipeline semantics are active, removing these control-flow overhead ops from the linear hot path.
Accumulate linear nextpc advances and flush only when current PC is needed, removing per-opcode nextpc materialization on the fast path. Also rematerialize helper call PC directly from vaddr in the linear non-delay-slot case.
Commit architectural PC only for branch/helper/terminal paths while preserving exception PC correctness for helper calls and delay slots. This removes unconditional per-opcode ipu.pc stores on the linear hot path.
Keep pipeline pc writes on branch/helper paths, and commit linear opcode ipu.pc from nextpc-4 to reduce per-opcode JIT overhead while preserving n64-systemtest behavior.
Skip per-opcode deferred-cycle flushes for straight-line instructions while keeping EndBlock checks unchanged, reducing hot-loop helper-call overhead without regressing system tests.
Skip emitting EndBlock test/jump in straight-line instructions where state cannot request block termination, reducing hot-loop overhead while preserving control-flow correctness.
Drop JIT metrics counters and reporting from the CPU recompiler to keep the hot-path code easier to read while preserving runtime behavior. This also keeps the architectural state commit path in emit() minimal by removing duplicated commit emission.
Model taken and not-taken link edges per block so conditional branches can be linked by final PC, and add finer diagnostics for no-direct-link causes. Also inline BC1 JIT branch handling with deterministic cause clearing layout checks to reduce unsupported FPU branch cases without regressing exception behavior.
Link JIT blocks lazily within sections with state-key matching and pending backpatches to cut dispatcher overhead. Gate linked jumps on dirty sections, clock/queue budget checks, and unsafe delay slots while adding detailed diagnostics on link misses and candidate coverage.
Convert all remaining integer branch and branch-likely opcodes to direct JIT emission and update decoder JIT flags, while intentionally keeping BC1 on the callf path.
Convert BGTZ, JR, BLTZ, and BGEZ to direct JIT branch emission and update decoder Jit flags accordingly, then extend invalid-offsetof suppression across cpu/recompiler.cpp to match the RSP pattern.
Verbose refactoring to only use decoder.cpp for extracting information
from opcodes (removing isTerminal and the return value of emit functions).
Added tracing to the cache index so that we basically version the JIT
blocks depending on whether it is enabled or not. This allows to
implement support for emux tracing without overhead.
This generates optimized codepaths for lqv and sqv. It also relies on
constant tracking to optimize situations where the base address is
know at JIT time (very common) and we can thus prove its alignment.
The JIT now tracks constant registers within each recompiled blocks.
This is currently unused in the generated code, will be useful to
improve code generation for vector load/stores opcodes.
This is non trivial because input arguments might mistakenly override
ABI registers. Prevent register argument clobber by resolving move
dependencies and breaking cycles with a temporary register.
Move UsesDmem and MayHalt traits into OpInfo so decoder metadata directly drives recompiler decisions, and simplify the JIT loop by unifying delay-slot state while documenting the current architecture and optimizations.
Drop the JIT write-sink indirection and skip code emission when the destination is R0, while keeping side-effecting C++ helpers and guarding their writeback to preserve R0 semantics.
Emit status.halted exit checks only for instructions that can mutate halt state (BREAK and MTC0 to SP_STATUS), reducing per-opcode overhead in the main JIT loop.
Do not classify VU opcodes as callf preflush candidates so deferred clocks are only synchronized for paths that actually require clock-visible C++ calls.
Track deferred clock progress for slow-path entries so memory fast paths avoid callf-triggered flushes while preserving correct timing when deferred fallbacks execute.
Emit direct fast paths for LB/LBU/LH/LHU/LWU/SB/SH/SW and keep unaligned half/word cases in deferred slow paths, reducing callf overhead while preserving interpreter behavior.
Keep deferred slow-path records minimal and re-enter opcode emission in slow mode, reducing per-opcode slow-path boilerplate while preserving the compact LW fast path.
Implement DMEM read/write paths with MSB-first word semantics and byte-accurate unaligned wrapping. Adjust RSP DMA DMEM transfers to use word paths consistent with the new DMEM representation while preserving IMEM behavior.
Replace the delay-slot call to instructionEpilogue<1> with explicit clock flush plus instructionBranchEpilogue, removing wrapper overhead while preserving delay-slot branch semantics.
Replace the JIT call to RSP::step with a direct thread clock increment while keeping deferred clock flushing behavior, reducing hot-path call overhead without changing interpreter behavior.
Defer fixed clock stepping across pure inlined opcodes and flush before callf paths, delay-slot handling, halts, and block exit to preserve observable timing while reducing hot-path step calls.
Emit the DelaySlot|EndBlock mask directly into branch state destinations for conditional branches, removing temporary state move instructions in the hot path.
Emit branch state updates directly in non-delay-slot branch paths and avoid copying nstate into state in the non-delay-slot epilogue, reducing branch-state traffic in the hot path.
Pass delay-slot phase into EXECUTE/SPECIAL/REGIMM emitters so branch-like ops can write the active destination directly and remove redundant delay-slot branch.begin state traffic.
Use compile-time next-PC values for non-delay-slot commits and avoid per-op branch.begin updates outside delay slots, reducing hot-path branch state traffic while preserving delay-slot behavior.
Use a compact xor-mask select for conditional branch target/fallthrough selection, reducing generated hot-path instructions while preserving existing branch semantics.
Replace runtime fallthrough reads from branch.nextpc with compile-time PC+8 immediates for REGIMM and EXECUTE conditional branches to remove extra hot-path memory dependencies.
Include block base address in the RSP JIT hash and use compile-time branch targets for conditional branches so generated code stays correct while removing extra runtime target math.
Pass the current block PC into RSP JIT emitters and use compile-time PC+8 immediates for JAL/JALR/BLTZAL/BGEZAL link register writes while keeping existing branch flow unchanged.
Skip branch state/pc commit work for non-branch non-terminal opcodes and simplify branch begin emission, and fix BLTZAL/BGEZAL when Rs aliases RA by deferring link write until after condition evaluation.
Emit BEQ/BNE/BLEZ/BGTZ and REGIMM conditional branches directly in JIT to remove per-opcode C++ calls while preserving delay-slot and link-register behavior.
Drop the fastInstructionEpilogue runtime toggle now that the specialized JIT epilogue path is stable. Keep the delay-slot fallback path while making the optimized path the only code path.
Choose the fast epilogue path at compile time for non-delay-slot instructions and keep the legacy path only for delay slots. This removes per-opcode branch-state dispatch in the hot path while preserving behavior.
Replace the slow-path JIT epilogue call with direct step/clocksTotal updates and a call to instructionBranchEpilogue, keeping branch exit semantics unchanged. This reduces call overhead while preserving behavior under the fast epilogue toggle.
Store RSP IPU PC as 32-bit so JIT word-sized accesses cannot clobber adjacent state. This keeps the fast epilogue path behaviorally stable while preserving 12-bit address masking semantics.
Add an A/B switch for a fast JIT epilogue path while preserving the legacy path as fallback, and widen branch pc storage so JIT word-sized accesses are safe. This gives a stable way to compare behavior and performance during further tuning.
Model RSP branch flow with pc/nextpc and latched state/nstate so interpreter and JIT follow the same delay-slot and end-block semantics. This stabilizes branch behavior while keeping stall and dual-issue logic unchanged.
Refactor reset handling to align with project architecture by removing the
'resetting' flag from the MOS6502 core. The reset state is now managed via
'resetPending' within the specific A2600 and Famicom CPU implementations.
- MOS6502: Remove resetting flag and internal reset logic from power().
- CPU: Introduce io.resetPending to handle reset triggers in the main loop.
- Debugger: Add interrupt/reset notification support for better tracing.
- Serialization: Update A26 (v140) and FC (v152) versions for state changes.
- Implement Dendy-specific timings: CPU divider 15, 312 total scanlines, and vblank starting at scanline 291.
- Refactor CPU/APU rate calculation to use a dynamic system divider instead of hardcoded PAL/NTSC checks.
- Add Dendy to the system region enumeration and UI emulator list.
- Handle Dendy-specific hardware differences: disable microphone input and adjust PPU aspect ratio/pixel output offset to match PAL-like characteristics.
- Clean up controller and system unloading logic to prevent memory leaks.
This implements a first subset of the emux extensions on the RSP. The
implementation is similar to the CPU one, and forwards to it things
that have to be identical.
Emux is a spec for emulator extensions to help homebrew development.
The spec can be found here at the time of writing:
https://hackmd.io/@rasky/r1k7na6Jn
Usage of emux is gated behind the "homebrew development mode" setting.
This commit introduces support for several extensions on the CPU, but
none on the RSP yet.
For homebrew profiling features, we need to track what hardware device
is accessing the shared RDRAM. We do have this already for debugging
purposes as a string. This commit changes that to an enum.
Normally, cores shouldn't be able to request the emulator to shut down
on the host computer, but this might be required for some homebrew
development features.
Previously the condition checked for MINGW, treating MSVC and all other
toolchains as a single "no detection needed" case. This inverts the
guard to MSVC, so that MSVC correctly skips detection (Windows SDK
provides xaudio2 directly) while MinGW and other non-MSVC toolchains
go through the CheckCXXSourceCompiles probe as intended.
Add cmake/finders/FindXAudio2.cmake to replace the ad-hoc XAudio2
link logic in os-windows.cmake. On MinGW, the module uses
check_cxx_source_compiles to probe for xaudio2_9 and xaudio2_8 in
the sysroot; on MSVC and other toolchains the Windows SDK umbrella
library is used directly. An imported target XAudio2::XAudio2 is
exported so call sites need no platform conditionals.
Replace the generator-expression-based -gcodeview selection in
compilerconfig.cmake with an explicit check_cxx_compiler_flag probe
at configure time (ARES_COMPILER_SUPPORTS_GCODEVIEW). This avoids
passing -gcodeview to toolchains that do not support it and makes
the fallback to DWARF visible in the configure log rather than
silently resolved at build time.
- ruby/cmake/os-windows.cmake: call find_package(XAudio2) and
consume XAudio2::XAudio2 via a generator expression; remove the
old MSVC/else block that unconditionally linked xaudio2/xaudio2_9
- cmake/windows/compilerconfig.cmake: add -gcodeview capability
probe; rewrite Clang and GCC debug-symbol blocks to branch on the
cached result instead of a generator expression
We were rendering background and sprites in burst mode, which shouldn't
happen.
I'm not the author, I'm just upstreaming changes done a member in our
team.
- Implementation of JY Company (Mapper 90, 209, 211) with support for
complex PRG/CHR banking, IRQ counter modes, and math registers.
- Implementation of SC-127 (Wario Land II Kirby hack) with A12-based
IRQ filtering.
- Enhanced CPU with `isWriting()` check and PPU with `isRenderingRead()`
status to support advanced mapper timing.
- Updated MIA database to recognize iNES mappers 35, 90, 209, and 211.
Currently Ares implements an infinitely fast EEPROM, but alas real
EEPROMs can take even 20 ms to save a single block of 8 bytes.
This commit implement approximate timings and the related flag to
notify the CPU that the EEPROM is busy writing data.
Introduce a `--batch` command-line option to run with a minimal presentation for frontend-driven launches (eg EmulationStation, arcade cabinets etc).
Behavior
- `--batch` implies `--no-file-prompt`
- Requires at least one valid game path (otherwise exits with a clear error)
- Uses a minimal presentation:
- hides menu bar
- removes status bar
- black background / centered viewport
- keeps file-open and drag/drop support
- Skips constructing settings/tools/game-browser windows in batch
Runtime safety
- Batch mode avoids UI-only flows where possible (logs messages instead)
- Driver and load/identify failures trigger a clean batch exit path
- Runtime defocus checks now use `settings.input.defocus` instead of `driverSettings.*.checked()`:
- avoids dereferencing non-constructed UI widgets in batch
- fixes batch crash from UI-state reads on non-UI code paths
`Program::quit()` could call `unlock()` on a `unique_lock` that did not own
the mutex, triggering `std::system_error` ("Operation not permitted")
and terminating the process on exit.
Guard the `unlock()` call with `owns_lock()`.
Call scheduler.setSynchronize(synchronize) during PS1 serialization
to match the behavior used by other cores.
Without synchronized serialization, coroutine/thread state may be
captured inconsistently, which can lead to crashes or undefined
behavior when loading savestates after relaunch.
Bump serializer version to v147 to invalidate incompatible v146
savestates created without scheduler synchronization.
The multi-byte read handler for the RCP/PI address range
(0xA4000000-0xBFFFFFFF) correctly fills the result buffer via
bus.read<Word> but then falls through to `return {}` instead
of returning the result. This causes GDB memory reads from ROM
cartridge addresses to return empty responses.
CMake install(DIRECTORY "path") without a trailing slash copies the
directory itself, creating an extra shaders_slang/ level under Shaders/.
Adding a trailing slash makes it copy the contents directly, consistent
with macOS (ditto) and Windows (copy_directory) which both copy contents.
Co-Authored-By: Claude Opus 4.6 <[email protected]>
On a real console, when the AI DMA ends, even if the volume is not zero,
there is a decay happening on the analog path that doesn't cause any
audible pops. This can happen in games when they fail to meet the
audio deadline and schedule a new buffer before the previous one ends.
When the homebrew header was first introduced, in its first limited
spec, Ares defaulted to enable both rumble pak and controller pak:
https://github.com/ares-emulator/ares/commit/bc8c308ee96162f5a7068001a0ece83e5f821e16
Back at the time, there wasn't any way to specify that a controller pak
was needed by the ROM, and Ares didn't even provide a GUI to install it.
So basically this was the only way to allow a homebrew game to use
the controller pak at all.
Fast forward 4 years and now we have a GUI to select which pak to install
on each controller, and the homebrew header allows to pre-install whatever
you want into each port.
In case the user doesn't specify a suggested controller configuration
in the homebrew header, the default of using a controller pak has the
annoying side effect of creating a useless .sav file next to any ROM.
CPak is not very common in homebrew ROMs anyway, so enabling it by
default now seems to create more hassle than it solves.
The advanced homebrew header (https://n64brew.dev/wiki/ROM_Header)
specifies a bit to mark a ROM as "region free", meaning that it can be
booted in all regions. Ares now has a region preference option, so
that option can be respected for the region free ROMs.
- cpu: implemented memory timing/control registers
- cpu: update bus accesses to obey memory timing registers
- cdrom: incorrect 150lba offset in command 0x14
- cdrom: fix behavior when a command is issued before the previous has completed
- cdrom: implement behavior where a new command cannot be executed until pending IRQ are acknowledged
- cdrom: implement 'command/parameter busy' register
- dma: update bus accesses to obey memory timing registers
- dma: improve chopping/allowing the cpu to run between blocks of a long transfer
- mdec: implement basic decode timing
- mdec: implement correct input fifo behavior
- mdec: fix behavior when an incomplete block is transferred via the input fifo
- mdec: fix dma request registers, input/output full/empty registers, busy register
- gpu: use correct clock frequency for PAL and NTSC
- timer: improve behavior around timer overflow/target reached irq
When placing co_swap_function byte array into the text section, libco
uses the trick of appending a # to the section name. This name string is
passed directly to the generated assembly and the # is treated as
comment token by the GNU assembler. This is a hack to avoid a warning
about changed section attributes.
This hack doesn't work with other compilers like Clang or TinyCC, but
unlike GCC they don't require such hacks. I've added some compile time
checks around the hack to try to isolate it to GCC and allow other
compilers to see the unmodified section name.
Validated on the following OSes/architectures/compilers:
- Windows/amd64: gcc, clang, cl, clang-cl, tcc
- Windows/aarch64: clang, cl, clang-cl
- Linux/amd64: gcc, clang, tcc[1]
- Linux/aarch64: gcc, clang, tcc[1]
- macOS/aarch64: gcc, clang
[1] TCC only works with a fix to glibc headers that was only made very
recently. Without it, you have to #undef __attribute__ after including
glibc headers.
This is required on amd64 due to the aligned moves in co_swap. While
note technically needed on aarch64, I found information online that
suggested ldp/stp perform better on certain microarchitectures with
16-byte alignment.
VI_H_TOTAL is defined as the number of cycles per scanline *minus 1*.
We forgot to add that 1 back. Besides the minor inaccuracy in timing,
we could hit a race condition during initial VI config: if the Ares
VI thread ran when the display was turned on (VI_CTRL configured) but
VI_H_TOTAL wasn't already configured (and thus defaulted to 0), the
thread would spinloop forever because it would step by 0 cycles.
While fixing this, I also noticed that I wasn't properly taking into
account leap timings because of a typo; this means that PAL timings
were very slightly off.
Fixes#2293
When beginning to execute a joybus frame, PIF clears the RX flags before
the transaction begins, so that errors notified in previous transactions
don't accumulate.
This is only visible in the where an application performs multiple
transactions (SI DMA reads) on the same frame layout (sent via a single
SI DMA write), while controllers are being hotplugged. This is not very
common in Ares, which is probably why it was not noticed before.
- Replace all nall::vector declarations with std::vector in desktop-ui
- Update API calls: .append() -> .push_back(), .reset() -> .clear()
- Replace .takeFirst()/.takeLast() with .front()/.back() + .erase()/.pop_back()
- Convert .find() to std::ranges::find() and std::ranges::find_if()
- Replace .sort() with std::ranges::sort()
- Fix boolean conversions: if(!vector) -> if(vector.empty())
- Migrate all emulator-specific files and core desktop-ui components
- Use direct assignments between std::vector instead of manual loops
- Maintain compatibility with nall::split() by using auto type deduction
genius can't build with Qt as it uses ComboEdit, but it is currently
enabled in the ubuntu-ci-qt as it inherits the base ubuntu-ci (which is
GTK-based).
GCC evaluated the always failing assert before the constexprs leading
to it, resulting in a compilation failure. As a workaround, we can move
the 'imm64' case inside the else block and check for the type there,
which also catches unhandled types at compile time.
Uses the new 'callf' function instead of 'call' in generated code. In
the n64-systemtest ROM, this change shaves off 6% and 10% of the
respective VR4300 and RSP median block sizes:
VR4300 block size statistics
min max mean median
before 113 6369 893.93 573
after 104 5937 881.17 537
RSP block size statistics
min max mean median
before 97 19196 3941.95 5336
after 88 17044 3414.06 4606
Also, on a benchmark with an RSP-intensive homebrew libdragon ROM, this
change gave about 1% actual runtime speedup.
When ares switched to SLJIT, some tiny overhead was introduced in every call
from guest to host code on 64-bit Linux. This was due to the argument register
mapping differing between SLJIT's own convention and the System V AMD64 ABI.
This commit makes the recompiler put function arguments directly in the correct
registers.
This commit introduces a new 'callf' template function that accepts recompiler's
'mem' and 'imm' argument types. It abstracts away the register setup so that
different host platforms can implement their optimized function calls. This also
results in slightly shorter code in the recompiler (see the followup commit).
The SLJIT_CALL_REG_ARG type of call is actually meant for SLJIT's own, optimized
calling convention, but since it assumes function arguments are placed in
correct registers, it works here. The only other option I could think would've
been emitting x64 machine code directly.
A simple implementation that is only accurate for 4-byte or 8-byte
aligned writes. Smaller accesses will require a full implementation of
write masking to be accurate.
ubsan on Mac caught an issue in this method: all geometry coordinates
are floats out and into Cocoa, but intermediate calculations were
being performed with u32 that caused undefined behavior when negative
numbers were involved.
- Use std::erase and ranges::find where shorter.
- Replace ranges::distance with iterator subtraction.
- Enable <ranges> in hiro core/extension; use views::reverse for reverse-destruction loops.
- Minor cleanups (array_view ctor from vector, build fixes).
- array-view/span: include <vector> so std::vector constructors are visible on stricter compilers
- directory (Windows): make ufolders/ufiles return std::vector<string>; update locals accordingly to match headers
Build verified locally with ninja.
- Add Pak::append(std::vector<u8>&, string) overload to accept std::vector without wrappers
- Convert remaining callers to pass std::vector directly; remove redundant array_view wrappers
- Replace nall::vector truthiness/foreach assumptions with std::vector equivalents (!empty(), range-for)
- Use std::vector APIs consistently (push_back; insert with begin()/end() when merging)
- Align medium analyze signatures/callers to std::vector where required; no semantic changes intended
- Keep explicit array_view only for subspans (pointer+length) where necessary
Build verified with ninja.
- directory, zip, mmi, cue: switch public APIs to std::vector; fix sort/find/append
- vfs/cdrom: use std::vector buffers and wrap into array_view when needed
- hid: replace inheritance from nall::vector with std::vector-backed fields
- instruction-set: use std::vector for cpuid data blocks
- windows/registry: contents() returns std::vector<string>
- set: iterator internals use std::vector stack
- tcptext socket/server: move buffers and onData() to std::vector<u8>
- remove umbrella includes of <nall/vector.hpp>
Callers fixed accordingly (ares/mcd, mia, desktop-ui).
Qt 5 introduces QScreen, which can be used to implement most of the
functionality needed by Monitor, although some of it probably won't make
sense when using Wayland.
Qt 6 no longer allows us to poll for the status of the event loop.
However, Qt 6 does still have a processEvents function, and the version
with the timeout actually spins the event loop and returns as early as
there are no more events in it. That's basically what we want to do. We
could run this with a really huge timeout, but that would just make it
more likely that hiro freezes up, so instead let's mirror hiro/gtk3 and
use a 50ms timeout.
This does not seem to be used anywhere in bsnes, higan or ares. It's not
really possible to implement with Qt 6, which has stop exposing this
detail of the event loop. It turns out this is actually OK, since we
don't *really* need it anyway, and in the case of hiro/qt, the
replacement should be more robust anyways.
Qt 5.0 adds the QScreen API, which exposes enough information that
Desktop::{size,workspace} no longer needs to fall back to Win32/Xlib. I
manually tested that this seems to give the same exact answers as the
Xlib path (though it technically goes a different route for
Desktop::size.)
Qt 4.8 LTS was released on December 15th, 2011. It hit its official
end-of-life on December 31st, 2015. It has been dead for nearly 10
years. Qt 4 is now so old, that it has been removed from Debian long
enough that "qt4" doesn't show up in *any* of the indexed package suites
in Debian's online package search service.
The CMake build of ares never supported Qt 4 in the first place, so this
code should all be dead anyway.
Now that the usage issues with string_view have been resolved it can be
safely used to wrap a vector<u8>. I'll note that passing a vector<u8>
directly to the string constructor would work as well (thanks to a
stringify overload) but I'm preserving the wishes of the author of the
MegaLD code to keep the type conversions explicit.
I'll also note that we're still constructing a string from the
string_view when we call JSON::unserialize(). Ideally, it would take a
string_view instead of a const string& and we could avoid the copy.
Unfortunately, all of the markup decoders currently require the input to
be null-terminated, which is only guaranteed by the string class.
Previously, string_view had a constuctor that allocated a new string and
forwarded all arguments to the string constructor. Among other things,
this allowed construction of string_view objects using any of the
various stringify overloads. However, there were drawbacks:
1. The constructor string_view(const char*, u32) shadowed the
forwarding constructor, leading to very different behavior. In the
forwarding version, the first parameter would be treated as a
null-terminated string, and the second parameter would be formatted
as a string and concatenated with the first.
2. Having both owning and non-owning modes makes it difficult for
someone reading the code to reason about lifetimes, as they depend
on how the object was constructed. It also deviates from the
behavior of the identically-named standard C++ string_view.
This commit splits the PI DMA-Write transfers (that is, loads from ROM)
in multiple blocks, following what happens on real hardware. Moreover,
it tries to more accurately reflect timing that each block takes. This
is easier to be done at the block granularity, otherwise the timing
algorithm would need to figure it out again the whole block splitting
logic.
From the point of view of the running application, now a ROM con see
the two hardware registers PI_CART_ADDR and PI_RDRAM_ADDR increment
one block at a time during the transfer, which more accurately reflect
what happens on real hardware.
This commit is validated with n64_pi_dma_test test ROM
(https://github.com/rasky/n64_pi_dma_test) which we now pass in full,
including timing tests with the default 10% tolerance.
This allows callbacks for repeated events (rescheduled at each callback)
to not have additional latency caused by the latency with which we call
step().
The homebrew header supports configuring a different controller and pak
for each port, but mia couldn't represent that in the manifest. The
required change is trivial though.
For backward compatibility, if the homebrew header doesn't declare
anything (which is the same as asking for a standard controller in all
four ports with no paks), we install a cpak in port 1 and a rpak in
port 2, which is also what we have been doing forever with commercial
games.
Controller pak formatting had two bugs: checksum calculation was wrong
(didn't really iterate on all bugs), and the FAT backup copy was in the
wrong position.
Pixel perfect (1.1 PAR) can still be achieved "Scale:Integer" combined with "Aspect: No correction"; this works better than the 'Pixel Perfect' setting ever did.
Currently, Ares has an "Aspect Correction" checkbox that allows to
disable the PAR (pixel aspect ratio) configuration made by each core,
to basically display the framebuffer without any additional scaling,
with host PC aspect ratio.
In addition to this, it is common for people to request an
"anamorphic 16:9" option, to correctly display games the way they would
appear on a 16:9 TV when stretched. Sometimes, homebrew games are even
designed to be viewed like this.
This PR changes the aspect mode from a boolean to a 3-value option.
The standard option is now named "Standard (4:3 TV)", and a new
option called "Anamorphic (16:9 TV)" is added.
Currently, we render PAL games as 640x480 which is wrong because PAL has
more vertical resolution. This causes PAL graphics to be reduced in
quality compared to a real output.
This commit renders PAL at 640x576 which is the commonly used active
display area used by PAL games, and then configure the aspect ratio to
make sure the output is correct.
/Oi, /Ob2, and /Ot are implied by /O2, which CMake adds by default in
Release and RelWithDebInfo builds. In RelWithDebInfo builds CMake also
downgrades inlining by adding in /Ob1, but we already have a workaround
for this. MinSizeRel builds may see a change in behavior, where CMake
passes /O1 instead, but in any case that is the recommended flag for
minimizing binary size.
The removal of /GL is especially important for MSVC builds. CMake will
add it when IPO is enabled, and forcing it on for all non-debug builds
was not simply redundant; it was overriding the user preference
expressed with ENABLE_IPO. ClangCL requires other flags to enable the
equivalent LTO feature, and this is already addressed elsewhere.
The CPU serialization logic would sometimes write pointers to save
states. Needless to say, this was not very compatible with saving and
loading states across separate runs of the ares process.
The topmost bit of the DICR (DMA Interrupt) register should not
influenced by the per-channel interrupt enable bits. This flaw was
masked in fast boot mode, as it allows title code to begin execution in
a pristine state unlike what the BIOS leaves behind.
With this change, the titles that were "fixed" by enabling fast boot
mode can now be launched with it disabled.
Allows bit 1 of R15 to be set in ARM mode.
The updated LDM/STM implementations are functionally identical to the
previous versions, but are significantly shorter and require less
special-casing.
Fixed a bug where the prefetcher was restarting too early upon being
emptied, and implemented a timing edge case involving simultaneous
accesses from the CPU and prefetcher.
* Acquire the program mutex when updating audio sync settings to prevent
a possible crash in some audio drivers
* Pause emulation while showing driver confirmation modals to prevent
interference from the UI thread calling `ruby::audio.clear()` during the
modal state, and also because pausing the application for a modal is a
normal pattern
* Restore a workaround when loading Arcade systems via the game browser
window that prevented a crash
When loading a ROM via a startup argument, `Program` requires access to
elements that are initialized as part of the Tools window. Thus, make
sure the Tools window is fully loaded before creating `Program`.
This restores the load order prior to the threading rework. An earlier
version of the threading rework created the program mutex differently,
which is why the load order was modified in the first place
(incidentally rather than intentionally).
Fixes#2043
- Adds instruction encodings for BX with bit 21 clear, and for an
undocumented `mov rd, rn` instruction
- Uses specific encodings for undefined instructions, rather than
binding them to unused encodings, and then asserts that all encodings
have been bound
Removes a speedup in the GBA core that was detrimental to accuracy.
Testing on Linux, the performance cost is more than offset by the recent
UI threading rework.
Rearranges ares's main run loop, putting emulation in its own dedicated
thread that is separate from the main/GUI thread. This updates ares to
somewhat more modern application practices. This rework should have an
array of benefits, including increased UI responsiveness, improved
energy efficiency/performance, and increased compatibility with various
modern APIs and frameworks for rendering, input, and audio.
## Details
Generally, this PR implements a fairly simple approach to threading,
using `nall::thread`'s pthread-like semantics and several basic
recursive mutexes. For this initial implementation, we use very coarse
locking on the emulation thread, combined with very limited access to
the emulator state from the main and other ares threads, allowed to
occur between emulator run loop iterations. Synchronization on the
emulator state is managed via `programMutex`.
Since this mutex is held for the duration of the primary work loop,
including while the thread is suspended, the GUI thread should try to
never acquire the program mutex unless absolutely necessary. Doing so
with regularity will incur a severe UI responsiveness penalty. For
destructive updates like driver settings updates, memory writes, and
game loads/unloads, we acquire it. For other cross-thread communication,
we try to synchronize using other methods that do not incur a
significant performance penalty.
Window resizes triggered via the emulation loop synchronize with the
`_needsResize` atomic. Status messages are passed by acquiring the
`messageMutex`. `vBlanksPerSecond` is also now an `atomic<u64>`.
Input continues to poll on the main thread for compatibility with
existing code. Access to the input system is managed via `inputMutex`.
### Known Issues
Draft status as this is still a work in progress, but PRing now for
visibility, feedback, and to consolidate any issue tracking. There are
likely kinks left to work out; testing is appreciated.
~~- Cores are loaded on the main thread before being run on the emulator
thread; this causes issues for paraLLEl-RDP, which expects that the
thread to initialize Vulkan is also the thread that will make RDP
calls.~~ Addressed.
~~- Memory editor currently does not have access to the program mutex;
reads and writes are unsynchronized.~~ Addressed; memory editor
synchronizes on writes but reads occur in a thread-unsafe fashion.
~~- The Clang thread sanitizer still reports a couple data races in
Metal and OpenGL; further testing with other Ruby drivers is needed to
make sure resource access is properly managed, particularly with respect
to the output framebuffers.~~ A larger examination of locking in other
parts of ares is probably necessary, but I think out of scope for the
first iteration of this rework.
- The gdb server seems to still be working fine, but could probably use
more testing.
The SD/HD/UHD options represent scaling the internal N64 resolution to
1x/2x/4x. Even for a title running at 640x480, this results in 1280x960
and 2560x1920 which doesn't match the meaning of HD/UHD. Games running
at lower resolutions give even more out of whack results. New label
communicates more explicitly what the option actually does.
I didn't change the string used to serialize this option in
`settings.bml`. Feedback welcome on whether I should do that.
Metal checks whether librashader handles are non-null during
deinitialization to determine whether to call librashader's `free`
functions on them.
If the handles are initialized to contain junk data, they will be
non-null but `free` will fail, causing a crash during the deinit that
occurs prior to any initialization of the video driver.
On Apple Silicon, the system malloc implementation provides something of
a guarantee that heap allocations are zero-initialized, but this proves
to not always be the case in practice. There are also no (or fewer) such
guarantees on x86_64.
On OpenGL, these pointers were already being zero-initialized.
When the CPSR mode field is set to an invalid mode, SP (R13), LR (R14),
and SPSR are not mapped to any register. Therefore, writes to them
should fail, and reading them should return zero (or 0x00000010 in the
case of SPSR).
Update: Also implemented a new edge case for BX instructions, where
setting bit 22 causes SPSR to be modified rather than CPSR.
* Fix a regression where the application manifest was not embedding
properly on Windows, leading to various problems including incorrect UI
styling and DPI settings
* Fix an issue where we would fail to parse a canonical version from a
`git describe` string without a suffix
* Update SDL to 3.2.14, containing miscellaneous bugfixes
* Update librashader to 0.8.1, which should address a rare crash with
bad shader caches on Windows
* Update slang-shaders to its master branch contents as of 5-21
(8c630e0d3234d93b6c2bc847371f86aa4e535686)
* Update MoltenVK to version 1.3.0
Add explicit support for CMake 4.0 version policies; the only change
required is to remove a superfluous/invalid POST_BUILD designation from
Linux bundling code.
Also add .DS_Store to the .gitignore, since developers may possibly
still be on systems old enough to litter these everywhere.
Fixed an issue where an undefined opcode was being treated as an
unconditional branch in Thumb mode, and added a destination register
field to ARM mode BX instructions.
- Fixes an edge case involving overflowing audio FIFOs
- Slight FIFO channel timing improvements
- Prevents most APU registers from being written while audio is disabled
- Fixes writing to wave RAM while audio is disabled
ares' build system tries to always have version information available
for debuggability and build tracking. It depends upon the presence of
Git to provide version information, since Git is the version control
system used by the project.
When distributing tarballs of ares, however, no `.git` directory and no
inherent version information is included in-tree, which causes the build
to fail with a vague fatal error after failing to derive a version for
itself.
Since we would like building a tarball to be at least possible with
minimal fuss, we should provide some version information inside a tar
archive served by GitHub. This PR uses Git's
[export-subst](https://git-scm.com/docs/gitattributes#_export_subst)
attribute to automatically bundle version information when `git-archive`
is run against the repository, as is done when the GitHub API serves a
tar archive of a given release, branch or commit. The build system will
check for the presence of this file if it finds that there is no `.git`
directory at the root of the repository.
This PR also improves the version handling in general to better support
semantic version strings of the form `v123.x.y`, in case future releases
of ares require hotfixes or minor versions.
The [Windows signing action used by
ares](https://github.com/Dana-Prajea/code-sign-action) fails under
clangarm64 due to having the wrong path for `signtool.exe`.
This PR swaps the clang-cl arm64 Windows build back into the
primary/nightly workflow until we have a fix for clangarm64 codesigning.
Includes:
* Stop vendoring the librashader header on Linux
* deps.windows: Update librashader to 0.6.3
* deps.macos: Update librashader to 0.6.3
* Update slang-shaders to ref 25311dc
* Pin Rust nightly to version contemporary with librashader version
* Establish macOS deployment targets
* deps.macos: Update SDL to 3.2.10
* deps.windows: Update SDL to 3.2.10
Serialization for the MD, specific to the ym2612 audio implementation was changed, but there wasn't a version bump. This corrects this missing contribution.
As part of the boot security, IPL2 (run by CPU), PIF and CIC collaborate
to verify that the IPL3 (stored at the beginning of the ROM) is valid
and not tampered, by running a checksum. If the checksum is invalid,
the console is halted immediately.
Ares emulates this behavior correctly. Sometimes, though, it might be
useful for development purposes to let some ROM boot even with a failing
checksum. Given that disabling the check was non-obvious, I'm adding
an accuracy compile-time flag for now.
- the noise LFSR reset bit takes effect immediately
- channel period counters tick only when they're enabled, including
if channel 2 is in voice mode or channel 4 is in noise mode
- the noise LFSR only ticks if channel 4 is enabled in noise mode
All commercial ROMs in N64 have the value 0x80371240 in the first 4
bytes. This has long been used by emulators both as a magic number to
"detect a N64 rom", and as a way to detect endianess of the dump.
In reality, the first byte (0x80) is unused/ignored by the console, while
the other 3 (0x371240) are just parameters used to configure cartridge
access (basically, ROM speed). There's absolutely nothing that prevents
a ROM with other values to boot. Ares currently fails to honor this
by refusing booting ROMs with different values, but this is just wrong.
To fix this, we change approach and use the CIC detection algorithm to
also detect the endianess, given that it's based on a checksum match.
If we can't find a match, we tried the two common types of byteswaps,
hoping to find a match. Eventually, we fallback to assume it's a
big-endian dump, and needs the common CIC-6102.
This means that analyze() will now only reject ROMs with size lower
than 4 KiB, but that's correct. Given that 4 KiB are loaded by the
IPL2, we assume that minimum size is required. Besides that, there is
nothing else in the ROM that can be used to "detect" a N64 ROM, so
it's correct to just let it boot and see what happens.
Fixes using the same rom file on both GB and GBC hardware without losing save-data between them
Fixes Pokemon Stadium when loading a .gbc rom (the Transfer Pak only used the GB path)
Existing users using a custom save game path will have to manually move their saves from "Game Boy Color" to "Game Boy"
Users using the default "Save alongside rom files" will not have to take any action.
- SH2 memory windows have been adjusted. The framebuffer areas must be mirrored up to 0x5ffffff -- fixes Toughman Contest backgrounds.
- VDP FEN & PEN flags are closer to accurate but still missing some finer timing details.
- FEN/PEN status may block vdp memory accesses. The docs seem to indicate that accesses may be held in wait until a status change, but thats not totally clear (nor validated?). For now, these accesses are blocked and logged in debug.
- FM setting (framebufferAccess) only allows vdp access by either 68k or SH2-side, so additional guards have been inserted for cram/framebuffer accesses. VDP reg accesses should be blocked as well according to docs, but this aspect needs to be reviewed.
- VDP reg latching has been implemented. The timing isnt completely accurate, but should be decent enough for now. Fixes Mars Check image test (corrupt lines from mode switching).
- Autofill timing has been implemented according to the docs. For now, this is just signaling via the FEN flag. Fixes MK II glitching et al.
Minor changes:
- Run CI for pushes to any branch, not just master. This is mostly
relevant for forks, where you will often want CI on WIP branches.
Releases still check that they are on the master branch and won't be
generated for other branches.
- The GCC `stringop-overflow` heuristic still seems to be buggy,
tripping in seemingly irrelevant areas, and in different areas depending
on toolchain/OS. Hence, just disable it for now; conforms with legacy
behavior.
- Fix a macro redefinition in the GTK CMake code
- Add a missing "included" source to the desktop-ui CMake code so it
shows up in IDEs
- `gersemi` formatting pass
Lastly:
Allow generating DWARF symbols in MSYS2/MinGW environments. This is
controlled by the cache variable `ARES_MINGW_USE_DWARF_SYMBOLS` (on by
default only for GCC, inoperable under MSVC/Clang-CL). This allows for
easier use of gdb or lldb for debugging on Windows. The support here is
considered incomplete but functional for debugging the main ares
executable.
In particular, we do not generate DWARF symbols on Windows in ares-deps,
so debugging dynamic dependency issues with gdb or lldb will require
self-compiling dependencies. DWARF symbols are also embedded and this PR
does not ship them with releases. The "primary" Windows clang build will
continue to use CodeView symbols so that releases may be debugged with
WinDbg, Visual Studio, etc.
I am not satisfied with this level of support, but I am also not sure
whether "full support" for two independent debugging symbol formats on
one platform is a reasonable thing or a good idea to maintain. For one
thing, ares-deps targets the MSVC ABI for portability, where DWARF
symbol availability is limited. Targeting the GNU ABI in ares-deps would
mean reconciling multiple independent components' dependence on libc++
that would eventually need to be linked together. This might
theoretically be possible but in any case is not undertaken here. Also
not undertaken is the extant PDB functionality for stripping into
separate files, bundling, copying to the rundir, etc.
1. Revised pwm emulation, mostly to align with documentation. Not likely
to affect much except for rare edge cases. Also, added a dc filter to
prevent audio popping in certain situations (like window losing focus),
but pops on init are correct behavior. Fixes#937 by implementing
byte-wide fifo writes from the SH2 side.
2. Various fixups to 32x io access by the 68k. Fixes#1196 and missing
music in Brutal.
3. Follow-up to a previous PR: cram dots were not limited properly, and
line buffer adjustment was crashing 32x in certain cases (as reported in
the discord).
targeted 192 for ntsc and 224 for pal. Framing on top and sides is now
precise to active display. Sadly, only a few codemasters pal games
utilized 224.
In its current form, all games that use standard Aleck64 hardware should
function correctly, using the current MAME romset at the time of writing
(0.273)
The following games are known to be working:
- Eleven Beat
- Hanabi de Doon! - Don-chan Puzzle
- Hi Pai Paradise
- Hi Pai Paradise 2
- Kurukuru Fever
- Mayjinsen 3
- Star Soldier: Vanishing Earth
- Super Real Mahjong VS
- Super Real Mahjong VS (Rev A)
- Tower & Shaft
- Vivid Dolls
The following games are known to be non-working:
- Magical Tetris Challenge (981009 Japan): Requires custom video
hardware: boots but unplayable.
Known Issues:
- Games using EEPROM do not currently save their settings between
executions.|
---------
Co-authored-by: Darren Thompson <[email protected]>
At some point it might be worth going through the list of widgets to
understand which ones require WM_KEYDOWN messages to be forwarded by
Application_keyboardProc. For the time being, it's clear the HexEdit
widget is not among them, so this change disables forwarding for that
widget type.
As an added bonus, this change also makes the number pad functional.
- Fixes the nightly release so that the release body will contain the
latest commit message (only the first line). Tagged releases will now
also contain a description.
- Ignore a benign warning in sljit that was popping up in build
annotations.
- Fix a warning about a conflict in the `mia-ui` domain string on macOS.
> [!NOTE]
> Seeking testers on this to validate that errors appear correctly, are
accurate, and we didn't break anything.
### Description
Adds the `LoadResult` type, used to identify and propagate upwards
errors encountered when loading ROMs and systems.
Modifies the `mia` and `desktop-ui` load routines to use this type
instead of generic booleans, so that if we have a load failure, we can
propagate a precise and useful error to the user rather than a vague and
possibly mismatched one.
Currently the scope of the error handling is just `mia` and
`desktop-ui`; errors encountered when loading in `ares` itself are
currently generic "`otherError`"s. `LoadResult` is placed in
`mia/mia.hpp` so it is accessible to both `mia` and `desktop-ui`. If
LoadResult is added to ares loading in the future, the LoadResult type
may need to be moved.
This is a minor reorganization of the new CI to be more modular and use
more organized patterns. Rather than one large all-in-one workflow,
items are now split slightly into discrete parts. Namely, there is a now
a PR workflow called for PRs, and a push workflow called for pushes to
the master branch, which in turn call constituent workflows for builds
and releases.
This enables a few conveniences:
- Workflows are split into concurrency groups that will automatically
cancel themselves. For example, if a PR is pushed multiple times in
succession, CI will be automatically canceled for all but the most
recent push.
- Permissions are applied discretely and in a somewhat more organized
way. The PR workflow simply has the "read" permission, while the master
push workflow has the "write" permission.
While the existing all-in-one workflow was not insecure, it relied on
GitHub Actions failsafes (such as pulls from public forks not being
granted write permissions nor secrets) in order to work properly, which
has the side effect of making the workflow's logic somewhat more
difficult to understand.
- New workflows can hopefully be more easily created based on
constituent parts. For example, the PR flow simply executes "build",
while the push workflow simply executes "build" as well as "release".
Future workflows could, for example, "build" and then call a new "test"
workflow to execute the test harnesses using the built artifacts and
report results. This can now be done without requiring as much delicate
attention to the existing workflow logic.
Future work:
- Ideally our "build" workflow could be refactored into a composite
action rather than a workflow. This would enable it to use defines
created in the initial "pull" or "push" workflows more easily, allowing
us to cleanly separate, for example, codesigning-related steps that
install secrets on the build machine, from actual build steps/jobs.
> [!NOTE]
> This was tested on a local fork, but several minor changes were made,
so it's opened as a draft until it can be double checked that nothing
broke.
While looking at something else I noticed that we were not respecting
the stored value of the "Force sRGB" option on startup. As a result we
would always output in sRGB unless the user explicitly modified the
option during the session.
There are numerous headers in Mega Drive & 32X games that are not
correct resulting in PAL games to run at 60Hz instead of 50Hz. This
corrects this issue by using the same technique the Atari 2600 core uses
which is to look for "(PAL)" or "(Europe)" in the ROM name which will
then force the game to run as a PAL game.
This also addresses the 32X game Shadow Squadron - Stellar Assault which
is supposed to be an NTSC-U and PAL game, but only has PAL in the header
so it could only run at 50Hz. This adds NTSC-U as an option (leaving PAL
as the default), but can be selected using the "Prefer US" boot option
so it can run at 60Hz.
Addresses issues:
https://github.com/ares-emulator/ares/issues/1066https://github.com/ares-emulator/ares/issues/1067
And yes, I'm aware I submitted an additional commit cause I spelled
Assault wrong in the comment, and managed to spell it wrong again in the
commit message. 🤦♂️
Fix macOS CI on pull requests by persisting if we fail to import the
certificate (as expected). Notarization should expectedly fail as well
on pull requests, if it tries to run.
(Whether CI succeeds on this is the testing)
It's already expected that nall/main.hpp will only be included in a
single file, so we may as well define main at the same time. This allows
the console/Windows subsystem distinction to be controlled on a
per-target basis instead of being compiled into nall.
Targets that should always build as console applications now set a
CONSOLE variable in their CMakeLists.txt, overriding the cache variable
of the same name. The remaining targets can still be controlled at
configure time by passing -DCONSOLE=1, which will compile everything as
a console application.
1. The cycle update order needed clean up, mostly to fix feedback.
2. Envelope update function was also reordered to avoid double update
issue.
3. LFO behavior was corrected (should apply proper attenuation when
disabled).
4. To avoid potential update issue, rate scaling was lightly refactored.
Avoids recalc of key scale factor and renames keyScale to rateScaling
(RS) for clarity.
Related issues: #1159, #1112
Run the new CI on pull requests (and not just the old one) so we can
catch bugs and failures, take advantage of new inline annotations, etc.
Working on a slight refactor of CI in general to make it
better-organized, but seems worth PRing this first before that is
complete.
For each emulator core with a `.bml` file in the Database folder
packaged with ares, this PR adds a separate check in their mia `load`
functions to verify that their database file exists on disk. If it does
not, we bail out of the loading process.
Meanwhile, in desktop-ui, if loading failed, we will now throw up an
error.
This PR stops short of adding fully robust error handling to the load
routines; the error message we throw up is generalized, and will appear
for anything that causes loading to fail, not just specifically database
files not being found. I think that the database files should be by far
the most common cause of load failure, so this seems OK to me for now,
but could certainly be improved in the future to provide more specific
errors. I obviously welcome feedback on how to handle any aspect of this
better.
Changes the regex used to determine our macOS SDK version to match on
Command Line Tools install paths and not just Xcode install paths, since
we do not require Xcode to build ares, just the Xcode Command Line
Tools.
Also fixes up how we handle the macOS deployment target.
(boring details below)
CMake is meant to transparently derive and pass appropriate compiler
options for our minimum deployment target. It does this via the
`CMAKE_OSX_DEPLOYMENT_TARGET` variable. This variable can be initialized
either by the project (which must happen before the `project()` call),
or else as part of the `project()` call, CMake will inherit it from the
`MACOSX_DEPLOYMENT_TARGET` environment variable, or else "compute it
based on the host platform" (whatever that means).
Our desired behavior is to set it to 10.13, except for local builds,
where we should respect the MACOSX_DEPLOYMENT_TARGET environment
variable (if it is set). This PR enables that behavior.
---------
Co-authored-by: invertego <[email protected]>
By default the SDL audio driver would initialize with a latency value of
0; this doesn't crash, but it ends up causing an unpleasant stuttering
and hitching, which is a bad default.
Also makes Metal the default driver on macOS.
> [!IMPORTANT]
> This alters default behavior for configuration on Linux that
maintainers should be aware of.
Introduces `ARES_BUILD_LOCAL` on Linux, enabled by default, that will
pass `-march=native` if enabled. Maintainers will probably want to
disable this. Also adds `ARES_ENABLE_MINIMUM_CPU`, `ON` by default, that
compiles with the previously enforced `x86-64-v2` minimum on x86_64.
Maintainers should do whatever they want with this option.
(@bsdcode @Mastergatto)
These changes are intended to give Linux users building from source a
better experience. Enabling x86-64-v2 compared to compiling without any
SSE functionality is a 10%+ performance loss locally in the N64 core,
and may be higher on actual x86_64 machines.
> [!NOTE]
> It is worth noting that even though we do not explicitly define a
minimum SSE functionality on arm64, in practice nall will still [define
`__SSE4_1__`](https://github.com/ares-emulator/ares/blob/e808d2c5ab5be91d3e1035063892e8c5115d25e2/nall/intrinsics.hpp#L232)
and take advantage of SIMD on that platform via sse2neon.
### Other changes
* Adds `-march=native` on macOS builds under the control of
`ARES_BUILD_LOCAL`, and fixes `ARES_BUILD_LOCAL` on Windows so that
`-march=native` is added under gcc and not just clang.
* Removes warning in the N64 core related to the issue caused by strict
aliasing under GCC.
* Fixed an issue where macOS would always generate for arm64 rather than
the host architecture.
* Ran a formatter pass that was previously missed on the CMake code, so
there are a couple miscellaneous formatting changes.
This change corrects two regressions introduced by my last change.
1. The purge() call in SH2::Cache::power() was, through a call to
Recompiler::invalidate(), accessing the pool array before it was
allocated.
This purge call was erronous for two reasons:
- It was purging a single line, though it *appears* the intent was
to purge the entire cache.
- According to the SH7604 manual, the cache is not initialized on
reset.
Therefore, I simply removed the call.
2. The size of the recompiler code cache for both of the two SH2s is now
halved to fit within the recently halved fixed code cache buffer. The
SH2 recompiler is good at reusing previously compiled blocks, so flushes
should not be especially common even with this reduced capacity.
- Reduce the code cache allocation from 128 MiB to 64 MiB. The CPU/RSP
split is now 63/1 instead of 64/64 (which was egregiously generous to
the RSP) so this should have little practical impact on cache flushes.
- Convert some larger static allocations to heap allocations to shrink
the ares executable's data section.
These changes increase the likelihood of the entire code cache being
within 128 MiB of the ares executable's text section, allowing for more
efficient branch encodings on ARM64 and better performance from the host
CPU's branch predictor.
Non-strict aliasing is found to resolve
https://github.com/ares-emulator/ares/issues/1737.
We also use signed integer overflow around ares, so we want to allow the
compiler to optimize for that if it wants to; essentially everywhere
ares runs is two's complement.
Couple quirks: Xcode has its own declaration for strict aliasing, so use
that. Clang-CL doesn't transparently accept `-fwrapv`, so it's passed
with `/clang:-fwrapv`.
`_ares_gcc_common_options` will eventually see more development to make
warnings consistent across platforms where possible.
(Fixes https://github.com/ares-emulator/ares/issues/1737)
Cmake based builds don't disable as many checks as the old make files,
so there were a few new warnings clang was showing during the Windows
build about unreachable code in mia.cpp & desktop-ui.cpp that are now
fixed (it would fall through properly on other OSes). Note that there
are still two remaining warnings about unreachable code during the build
but this is within zstd included in libchdr so this needs to be
addressed upstream.
A user trying to compile ares made a single post in the ares Discord
channel about a warning they were receiving during the link phase about
an overflow. I've never seen the warning or remember anyone bringing it
up so I asked about OS/compiler (I know it was Linux flavored cause they
mentioned working on an AppImage) but they never responded. I think they
were using openSUSE, but it is interesting this wasn't flagged anywhere
else. We were assigning an enum value to a Color struct in
table-view-cell.cpp which wasn't correct, so this has been fixed.
Finally, SuperMikeMan100 pointed out that when the controller combobox
in Settings > Input didn't fit entirely on the screen, you couldn't
scroll to the bottom of the list (Windows issue). They also pointed out
the fix needed in combo-button.cpp which I've tested and have included
the fix for it here.
First commit stops notarizing the legacy build; for some reason
notarization currently
[fails](https://github.com/ares-emulator/ares/actions/runs/12626365618/job/35179407527)
only with the legacy build, despite us not having modified the legacy
workflow. In any case it seems fine to no longer notarize this artifact.
Second commit allows the new build CI to continue if the repository it
is being run on does not have macOS codesigning set up. This means CI
won't automatically fail on your fork if you do not have macOS
codesigning set up on your repository.
Many parts of ares are compiled as a single translation unit in a "unity
build". Targets such as `hiro` and `ruby` directly compile only one
file, `hiro.cpp` or `ruby.cpp` (or `hiro.mm` and `ruby.mm` on macOS),
which `#include`s all other files beneath it in a branching fashion. By
contrast, in the `ares` target, each area of each core is generally
compiled as a separate translation unit, with lots of redundant
inclusion of common headers. This allows for faster "development cycle"
build times; if a small change to one part of the core is made, we do
not need to recompile the entire core.
Despite slower incremental build times, compiling each ares core instead
as a single translation unit has some benefits.
We can lower build times by a decent amount:
| Build | Build time (multiple units) | Build time (single unit) |
|-----------|-------------|-----|
| `ares-windows-x64` | 9m16s | 6m47s |
| `ares-windows-clang-cl-x64` | 11m3s | 8m23s |
| `ares-windows-clang-cl-arm64` | 12m29s | 9m20s |
| `ares-macos-universal` | 13m33s | 8m12s |
Not only that, but single-unit builds also seem to confer a minor
performance benefit, presumably due to more effective link-time
optimization.
On macOS arm64:
| Game (core) | VPS (multiple units) | VPS (single unit) |
|-----------|-------------|-----|
| Knuckles Chaotix (Mega Drive) | 101-102 | 108-109 |
| Snowboard Kids (N64) | 66-67 | 69-70 |
Last but not least, we can actually arrange for single-unit builds
without any code-level changes to existing ares source files. We can
simply add a `<core>.cpp` file for each core that includes each
'primary' `.cpp` file that would otherwise be directly compiled; due to
the magic of the `#pragma once` compiler directive, redundant header
inclusions are eliminated in the unity build, but compiling still works
normally if we are compile as multiple units.
Given that there were no significant issues adapting existing code to
compile this way, it seems worth considering adding this functionality.
It can disabled for default configurations transparently (to enable
faster incremental builds during development), but enabled on CI for
faster builds and a modest performance benefit.
* Fix a bunch of miscellaneous name deprecations
* Fix deprecated modal file handling patterns; use the `URL` properties
rather than the ones for paths
* Remove the Gatekeeper bypass menu item
* While the idea here was quaint, it's very dated, the approach doesn't
work at all on modern macOS (and would be a significant exploit surface
if it did), and the functionality is somewhat outside the scope of the
ares application in the first place. It won't remove Gatekeeper
restrictions on ares itself, since if we're using the menu item, we've
already made it past Gatekeeper. Functionality to disable Gatekeeper in
general for other applications is, again, maybe nice in an abstract way,
but well outside our scope.
* Suppress OpenGL symbol resolver deprecation warnings
* Fix protocol warnings in `CocoaMenu` that revealed a mistaken design
pattern:
* We had both a protocol and an interface called `CocoaMenu`, and our
Cocoa hiro menu subclasses were declaring that they adopted the
`CocoaMenu` protocol, rather than what was almost certainly intended, to
be subclasses of `CocoaMenu` which would itself conform to the protocol
by virtue of being an `NSMenuItem`.
* In effect, this meant that each CocoaMenu subclass interface was
telling the compiler it wanted to reimplement the `NSObject` protocol
rather than be an `NSObject` subclass. This may have resulted in various
typical properties of `NSObject`s not being present, and various methods
(such as Accessibility) entirely not working.
Linking was failing under MinGW gcc because of a link order issue
between `libares` and `mingw32`. Establishing a direct link relationship
between `desktop-ui` and `mingw32` means that our `WinMain` definition
will not be discarded by `ld` before it's needed.
We also here add a Linux gcc runner and a Windows gcc runner; these do
not upload artifacts, but will allow us to detect build failures on CI.
At the moment, gcc support in general under CMake will still rougher
edges than clang or MSVC support, but it is intended that building with
`gcc` and `ld` should always at least work, even if `clang` remains
recommended and achieves superior performance.
This PR also adds a warning in the N64 core to acknowledge
https://github.com/ares-emulator/ares/issues/1737 until that issue can
be fixed.
Co-authored-by: John Tur <[email protected]>
`fetch-tags: true` only works within the specified fetch depth.
`fetch-depth: 0` fetches more than necessary, but seems to be the
simplest way to guarantee we actually fetch the latest release tag
needed by CI.
See also: https://github.com/actions/checkout/issues/338
For various reasons, OpenAL on Windows is not supported. If we do manage
to find it and link against it, the build we produce is unlikely to work
outside of an MSYS2 command line environment, so we should just disable
it.
If we ever want OpenAL support on Windows, we would need to either
locate a version that depends only on Windows system libraries (i.e.
does not dynamically load libc++ or other MSYS2 libraries), or else
build and provide OpenAL ourselves as part of `ares-deps`.
- Completes #1498 -- dots should be clearly visible in overscan areas
normally. If you notice odd dots appearing on top of games irregularly
(inbounds, non-overscan), please mention it. The Direct Color DMA demos
(https://gendev.spritesmind.net/forum/viewtopic.php?f=8&t=1203) should
be stable for the most part (note, they are very timing sensitive).
- VDPFIFOTesting rom should run without any failures. Previously,
16-FIFO Wait States was the only failed test.
- Both Titan Overdrive demos should run cleanly. There were a few minor
wrinkles that needed to be ironed out.
- Fixes#1075 -- there was a minor adjustment for a window edge case in
H32 mode. Unlikely to affect other games.
- Fixes#1061 -- looks pretty clean now.
- Fixes#626 -- I don't notice anything weird currently, just some minor
fringe in the left border, not visible when overscan is disabled.
- Review #1675 wrt md -- there are no parts of the active display area
that are currently cropped out. There was an unreported issue with Exo
Squad (E) that had clipped the topmost lines in PAL V30 mode (observed
on the copyright screen) but that has been fixed.
- Fixes an unreported bug in 32X PWM sound (right channel was missing),
typo from previous commit d7dfae7a7a.
* Remove version overrides from CMakePresets.json
* These were necessary for CI to run when CMake existed on the forked
branch, but *should* no longer be necessary
* Disable release flows for the legacy build
* Keep legacy builds running for the time being, but disable the release
flow so it does not conflict with the new CI
On some Linux and BSD distribution, Ares from the repositories may not
come with shaders preinstalled. Instead, these one may come from another
package, for example on Archlinux the package `libretro-shaders-slang`
installs the shaders in the following path:
`/usr/share/libretro/shaders/shaders_slang/` .
This will make Ares fail to load any shaders on these distro. So to fix
it, this PR adds the aforementioned location as another path to search
for, as a fallback.
I know, the two dots are a bit ugly, given that locate() normally
doesn't search for files or directories outside of those of
Ares...Ideally, locate() should be expanded to search the entire file
system, but I'm afraid the required changes may be a bit more far
reaching than expected.
This PR introduces a new CMake-based build system for ares.
Broadly, the goals of this build system are to:
* Modernize the build process somewhat, and make ares more approachable
for new developers
* Improve ares's dependency handling
* Expand and standardize platform/compiler/architecture support for ares
* Improve project code quality
* Improve build performance
* Lay groundwork for easier support of more platforms in the future
There are a few notable changes that this PR brings about. Briefly:
* Dynamic dependencies (librashader, MoltenVK, SDL, slang-shaders) are
no longer built in-tree
* Build system generation and building now take place as two separate
steps
Other notes:
* The legacy build system is deprecated, but is planned to still
function until such time as it is removed in a later PR
# New Features
* ares can now generate projects for Xcode and Visual Studio 17 2022.
Xcode is the recommended generator on macOS, supporting universal
binaries, advanced profiling and GPU debugging. Visual Studio projects
can be configured with either Clang-CL or MSVC, and may be generated for
either x86_64 or arm64.
* On macOS and Windows, dynamic dependencies are now built by
[ares-deps](https://github.com/jcm93/ares-deps) and fetched at
configure-time. This is to reduce build requirements for development,
define explicit versioning for dependencies, reduce build times
generally, and streamline CI workflows.
* Builds can now be configured through the default Windows command line
rather than requiring an MSYS2/MinGW shell.
* Ccache is also now universally supported to improve build performance.
Compile times should be further reduced with the addition of
precompilation of certain headers.
* A variety of other build system generators are now supported on all
platforms, including multi-configuration Ninja and applicable types of
Makefiles.
* Compiler diagnostic flags with clang have been standardized across all
platforms where possible[^1]. Currently, diagnostic flags have rough
parity with the old build system, but one goal of the new build system
is to introduce more strict compiler settings, to eliminate certain
classes of bugs and generally increase code quality.
# Supported Platforms
ARM64 and x86_64 architectures are officially supported across macOS,
Windows, Linux, and BSD[^1]. clang, Clang-CL, gcc, and MSVC are all
supported on applicable platforms. MSYS2/MinGW is supported along with
configuration and builds via the default Windows shell.
32-bit builds have not been tested.
# Current Status
Builds across all three of macOS, Windows, Linux, and BSD are generally
expected to work. Detailed build instructions can be found on the new
[ares wiki](https://github.com/ares-emulator/ares/wiki). CI workflows
are present and implemented but are still a work in progress. More
complete documentation is also a work in progress.
#### macOS
* Xcode, Ninja, Ninja Multi-Config, and Makefile generators are
functional
* Unlike Windows, multi-architecture builds are supported; pass
`-DCMAKE_OSX_ARCHITECTURES` as appropriate.
* Builds should generate a fully functional and relocatable app bundle
within the build directory, with relative rpaths; `install` rules are
placeholders.
#### Windows
* Visual Studio 17 2022, Ninja, Ninja Multi-Config, and Makefile
generators are functional
* Only single-architecture builds are currently supported
* Similarly to macOS, the build step generates a fully functional and
relocatable rundir with placeholder `install` commands.
#### Linux / BSD
* Unlike on macOS and Windows, it is required that the developer have
packages installed for libraries ares links against. A list of required
and optional libraries is found in the README.
* Build will output to a staging directory `rundir`; ares only uses
system libraries so this rundir should be fully relocatable
* `install` will perform a standard installation as CMake deems
appropriate for your distribution; you may pass the `--prefix` argument
as needed
* Maintainers may package as appropriate; a new Flatpak may be created
as part of this process, but has not yet
> [!IMPORTANT]
> These tasks should be completed before this PR moves out of the draft
state:
>
> * ~~CI workflows~~ - incomplete
> * ~~BSD support~~
> * ~~Windows SDL added to ares-deps~~
> * ~~ares-deps should probably be migrated to the ares-emulator
organization~~
> * More documentation
> * Miscellaneous cleanup, fixing issues found in testing, incorporating
general feedback
Nevertheless, now that builds are functioning on all three platforms, I
wanted to get this PR out there in a draft state to solicit testing and
feedback, as well as to give Linux package maintainers a head start in
terms of packaging.
> [!NOTE]
> While the PR is in a draft state, there may be breaking changes,
things may temporarily stop functioning, commits may be squashed, etc.
Thank you for testing and please report any issues you encounter!
* More detailed documentation on the internals of the build system is
available
[here](https://github.com/jcm93/ares/blob/cmake/cmake/README.md).
### Miscellaneous changes/points
* .gitignore is reorganized
* [gersemi](https://github.com/BlankSpruce/gersemi) is used for CMake
formatting, hence the presence of a `.gersemirc` file
* SDL on Windows is now a dynamic dependency.
* macOS asset files are reworked into .xcassets archives
* new macOS local build script introduced
* CI will include debug symbols for easier crash debugging
[^1]: Indicates something that might not be finished yet, or is subject
to change
---------
Co-authored-by: invertego <[email protected]>
Co-authored-by: Stefan Schlosser <[email protected]>
Co-authored-by: John Tur <[email protected]>
This commit ensures that changes to the FDS disk get saved when the
Famicom system saves (similar to how the 64DD works already). Without
this, changes to the FDS disk were only written back to the pak in
FDS::disconnect, _after_ the save on unloading/exit or any periodic
autosaves.
This PR adds the hex editor widget to Cocoa hiro and enables the memory
editor in Tools. The widget is a cell-based NSTableView with data source
the core hex editor widget and supports editing of memory (but not of
the encoded ANSI).
---------
Co-authored-by: jcm <[email protected]>
This commit implements correct VI timings using VI registers rather than
hardcoding the behavior for the default presets made by commercial
games. This makes Ares behaves correctly, timing-wise, also with non
standard timing like eg: the so-called PAL60 mode.
Moreover, it fixes VI interrupts in interlaced mode to happen on the
exact scanline they happen on the hardware, including known hardware
bugs.
The pixel accuracy setting will now emulate the sub-pixel timing
behaviours for bitmap and affine backgrounds described in [fleroviux's
PPU
docs](https://github.com/nba-emu/hw-docs/blob/main/src/ppu/background.md).
This PR also splits the PPU into two separate libco threads: one for
rendering and one for raising IRQs and starting DMAs. This allows the
CPU and PPU to be run more asynchronously, which helps mitigate the
performance cost of finer-grained PPU emulation.
Instead of advancing RSP DMA only after each CPU basic block, allow it
to run between each RSP block. This prevents the RSP from racing with
the DMAs it initiates in the event of a long running CPU block (which
can trigger multiple consecutive blocks of RSP execution).
This fixes hangs in Tarzan and possibly other games that use MusyX.
Another observable side effect of this change is that when the RSP is
halted, it no longer risks falling increasingly behind the CPU, because
ares will now step multiple times if needed instead of just once.
The "Type" column in the Settings > Firmware table view was being set to
false by default. As there is no visibility handling for columns in hiro
for Windows or Cocoa, this column would always be visible. But in the
hiro GTK table view definition (there is also a visibility
implementation for Qt) it did contain a function to disable/enable a
specific column so this column would be absent on Linux distros making
it look like there were duplicate entries in the table. This PR removes
removes the call setting visibility by default so that the column is
always visible.
Co-authored-by: remutro <remulationtro.gmail.com>
* Remove `macos-compat`, since the macOS 12 runner is no longer in
GitHub Actions, so we can no longer target macOS 10.9
* Rename the macOS build to "macos-universal", reflecting the OS and
arch
* Don't install `make` via brew any more, since it isn't necessary
* Establish the macOS version minimum as 10.13
* 10.9 was not a proper target, because of `fstatat` usage, which isn't
available on macOS 10.9. On a code level, we may technically be
compatible with macOS 10.10, but because no available build environment
can target this macOS version, it makes no sense to support it without
being able to test it. Since we can deploy for macOS 10.13, just
establish this version as the minimum. If someone wants to compile
themselves for lower macOS versions, they should still be able to.
* Increment the macOS runner for the primary macOS build to macOS 15,
and the Xcode version to Xcode 16.1.
* Better to explicitly pick the macOS and Xcode version rather than
using `macos-latest` as the runner, even though they refer to the same
thing, just so that we have explicit versioning wherever possible.
Not tested; CI run needed.
If you choose to select a new driver without pressing the Apply button,
and then go ahead and update related options for the currently loaded
driver then the combo box will revert to the currently loaded driver but
leave the Apply button enabled indicating the user has to do something
when they do not. This changes this behavior so that if options are
changed and the driver is reverted back to the current driver the Apply
button will be disabled again.
Brings back the Pseudo Full Screen option present in bsnes as a
configurable hotkey.
I'm also including the type mistake pointed out for the colorWidthBleed
value someone pointed out so we don't lose track of it.
Fixes test cases in the dma_speed_test rom.
1. "*VRAM TO ROM" is a dma load to a VRAM read target, which doesn't
have any effect. Though, for timing purposes, it's similar to a VRAM
write (1 byte access per slot) so fifo throughput is the limiting
factor.
2. A VDP refresh blocks bus access for 2 consecutive slots, slightly
affecting dma load transfer rates.
Random fix from CMake work.
Precompiled headers under CMake are currently buggy and unreliable on
Windows, largely because the precompiled `<ares/ares.hpp>` header
includes `<ares/resource/resource.hpp>`, which is generated by
`sourcery` as part of the build process.
While sourcery will almost never meaningfully change the contents of
this `resource.hpp` file, Windows may insert its own line endings
depending on the user's environment, and despite enforcing uniform line
endings as part of our `.gitattributes` file, some compilers will throw
a fit about the precompiled header being modified from underneath it.
Since the `resource.hpp` file is simple, short, and not included in that
many places, we can just refactor it out of `<ares/ares.hpp>` without
issue, and precompiled headers will work again regardless of system line
ending convention or environment.
Tested to build locally on macOS; CI run definitely recommended.
Fixes a few issues relating to open bus emulation:
- Accounts for cases where the last memory access was not an instruction
fetch
- For most memory regions, 8-bit and 16-bit accesses should be mirrored
along bus (except in IWRAM, where only part of the open bus value gets
overwritten, and the rest is carried over from the last IWRAM access)
- Open bus read alignment was not being respected in all regions
Following up on #1688 and #1575; removes the ARES_PREFIX preprocessor
variable and its use in `prefixSharedData()` in favor of a relative
path.
Passing a preprocessor argument to the program to define an install
prefix, which is then used to locate application data, is awkward and
overall not an ideal approach. Wherever possible, ares should have the
same behavior on the same classes of OS. Further, if we are to cleanly
separate ares's build and install steps, we shouldn't be defining
anything related to install locations at build-time. After building
ares, it should be able to be installed wherever the user wishes without
any unexpected changes in behavior.
Following the standard paradigm here means that on *nix systems, the
prefix's data directory would be, relative to the executable, in
`../share/ares/`. Hence, define `prefixSharedData()` from #1688 to
return this relative path appended to the executable path (given by
nall's `Path::program()`), instead of doing the preprocessor prefix
hooplah.
Tested on aarch64 Fedora; made sure ares can still locate the database
and shaders.
#1688 broke the build, and also did not actually perform one of the main
intended changes; reverting `sharedData()` to return "/usr/share/".
Second time's the charm!
### Context
https://github.com/ares-emulator/ares/pull/1575 ended up defining the
`sharedData` directory on Unix-like systems as `~/.local/share` if a
build prefix was not defined. This is not exactly correct; the meaning
of a "shared data" directory on a Unix-like system is variously
`/usr/share`, `/usr/local/share`, or else the `share` directory of a
given install prefix.
### Changes
This PR allows us to respect normal Unix conventions while also
respecting the option to build and install with a given prefix. This is
done by defining two more functions in nall's `path`:
* `localSharedData()` for `/usr/local/share`
* `prefixSharedData()` for `${ARES_PREFIX}/share`
`sharedData()` is changed back to the old behavior and returns
`/usr/share`.
Then, the `locate` logic in desktop-ui (and uh, mia) is adjusted to now
search (in order):
1. the prefix's shared data if the prefix exists
2. local shared data
3. system shared data
82bfc2d576 deps: update deps
7d7536f9fd rt(wgpu): approximate clamp-to-border with clamp-to-edge if not supported
9039a7c040 reflect: use FastHashMap for linkinputs pass
d8e35d4374 preprocess: add a test for include_optional
76347f63ac preprocess: add support for pragma include_optional
git-subtree-dir: thirdparty/librashader
git-subtree-split: 82bfc2d576d4c1a90339dcfba6c0163d5345b9c3
DDA was incorrectly capped at 16 bits instead of 24, making DMAs to
BWRAM banks 0x41-43 be sent to the corresponding spot in 0x40 instead.
See [the corresponding bug in
bsnes](https://github.com/bsnes-emu/bsnes/issues/309) for some more
context.
While checking out minimum requirements for the new build system, found
a couple small issues worth fixing:
* librashader was not operable on systems pre-macOS 12 with a linker
issue; it can be resolved by setting a minimum deployment target; here
we do that by setting an environment variable on CI.
* While investigating this, I found that librashader's minimum required
macOS seems to be 10.15; this is because `glslang` seems to require
macOS 10.15.
* It wasn't possible to build the Metal driver because of the older SDK
lacking some definitions; however, we can fall back to the
`__MAC_OS_X_VERSION_MAX_ALLOWED` compile definition which we do here.
* Not sure if building on these older systems should really be
considered "supported", but since the fix here was simple enough it
seems fine to throw it in.
paraLLEl-RDP and MoltenVK seem to have [a lot of
issues](https://github.com/user-attachments/assets/088879a9-9153-4b05-a207-212cfac7f831)
on my older system's GeForce 650M. I was able to compile debug MoltenVK
locally, but Xcode GPU capture just hung, so I was unable to figure out
what was going on. Either a driver issue or a MoltenVK issue seems like
the probable culprit. In any case, performance wasn't really good enough
to make me want to investigate further. Other cores seem to work well.
Tested [on my fork's
CI](https://github.com/jcm93/ares/actions/runs/11554703214) to make sure
everything still works.
The CACHE opcode does not work correctly when the specified virtual
address is in an uncached segment. The exact hardware behavior has not
been reversed yet (we know for instance that when doing cache
invalidation, some other cacheline is invalidated instead, but we do not
know the relation yet).
Nonetheless, the behavior is really obscure and all usages should be
considered bugs. Add a debug unusual warning for now (mainly to help
developers, as this is a known instance where Ares doesn't yet follow
hardware behavior).
Similarly to how the S-CPU and S-SMP are handled in the SFC core, it's
possible to run the GBA CPU and APU more asychronously as long as
synchronization is performed on FIFO or APU I/O accesses. From my
testing on Linux, this performs comparably to the performance profile
but without the accuracy downsides, so the performance/accuracy profiles
have been removed (the more accurate behaviour is now always used).
This PR also adds an option to disable pixel accuracy in the GBA core in
exchange for ~10-15% performance benefits, and makes some small PPU
timing improvements that were not feasible to implement in the
performance profile.
We want to allow arbitrary writes through the GDB server to the RDRAM
area. This was done in #1620, but that version has a subtle issue where
the server will still refuse to write or change writes that happen to be
of size `Byte|Half|Word|Dual` if the addressed is not aligned to that
size.
This PR fixes the issue by checking if the write is to RDRAM first,
allowing arbitrary and possibly unaligned writes. Otherwise, the write
is handled through the normal machinery where these issues may be
semantically important.
This pull request allows for all pak swapping on controller port 1 only.
It also enables support for the transfer pak for the 64DD which was
previously missing.
It is being added for port 1 only now because there is additional work
to manage all the different saves, and gameboy games/saves with the
transfer pak which is a larger effort, and Luke is currently looking
into modifying settings in a more complete manner. So other ports can be
added later. For most people, being able to swap for the first
controller is likely good enough.
This pull request doesn't change any of the current initialization logic
regarding default pak selection that already existed.
This is a change spun off from continuing build system work.
There, we've found that precompiling the `ares/ares.hpp` header can
speed up compile times for the emulator cores by 30-35%. Doing so,
however, leads to a few collisions:
* Several files in parallel-rdp use the `Hash` type, which variously
resolves to a `Hash` in its own namespace as well as nall's namespace.
* Also in the N64 core, nall's `noinline` macro conflicts with similar
definitions present in `xxhash`.
For parallel-rdp, we can simply skip precompiled headers for the
conflicting files; parallel-rdp does not use anything in the
`ares/ares.hpp` header, so including it there is unnecessary anyway.
This change resolves the second set of collisions by putting nall's
noinline preprocessor macro into its own namespace.
There are many macros remaining that are not namespaced. I did not
proceed in namespacing them for this PR, because there are a lot of
them, and it would be a fairly significant code style change that
probably merits further discussion (not to mention, it will be a decent
amount of work). However, in this instance, there is (or will be) a
material benefit that probably trumps the minor style issue.
Implements a couple improvements to OBJ-related timings:
- OBJs are now rendered one scanline in advance, as on hardware
- OBJ palette RAM accesses are now performed in `PPU::Objects::run`
rather than `PPU::Objects::scanline`, bringing OBJ PRAM access timings
closer to matching hardware
40 Winks was released aftermarket on physical media, and support has
been added for this (does NOT include prototypes). The US version was
tested, but was unable to test the EU release (game Id and pak options
should be the same and should theoretically work).
Additionally, looks like ares was missing some region descriptions, so
these have been added as well based on info located at:
https://n64brew.dev/wiki/ROM_Header#Advanced_Homebrew_ROM_Header
When debugging homebrew with gdb, it might be annoying if gdb stops at
exceptions that are correctly handled by the running application. This
is a bit hard to know so, besides providing some (debatable) default, we
need a way to selectively ignore specific exceptions.
This commit generates different GDB signals for different families of
exceptions. The mapping between MIPS exceptions and UNIX signals is
completely arbitrary; it tries to "sort of" match the meaning of the
exception where possible, and otherwise just use a random signal.
The GDB client can configure which signals should be logged, which
should cause the application to stop, and which should be ignored, using
the "handle" command.
By default, we want to ignore exceptions generated by interrupts (as
those are normally handled by the application) and those handled by the
operating system (like the COP1 exception which both libultra and
libdragon use to speed up context switching). To do so, we assign to
them signals that are ignored by default by gdb (SIGWINCH and SIGURG
respectively).
d334ab1a95 Fix left-shift signed overflows (UB) (#62)
434e793dc4 Assert that only valid timer numbers are passed to engine_timer_expired().
16e1d4281a Use snprintf instead of sprintf to fix#59. Use std::array for operators to remove the need for array_size.
4e654a3e8f Add virtual destructors to all base abstract classes, to prevent memory leaks (#55)
1a5cc66cb6 Keyon all ops on CSM mode (#56)
git-subtree-dir: thirdparty/ymfm
git-subtree-split: d334ab1a957351ce2a0aa2777b8c704664be3189
cbdbdafecd chore: Release
ffcb8ba1d1 doc: Update BROKEN_SHADERS.md
941275199b build: unpin cc
525c311844 cli: allow raw-id for spirv output
2fe66d958f reflect: put vars to end with running link pass to fix naga ordering
ed8bf637a9 cli: size_of not in prelude
7555bb9024 build: make librashader-reflect features-table more consistent
562e1e5f18 doc(msrv): bump msrv to 1.78
13b44e1639 cargo: revert lockfile version
240aae1bcf chore: Release
95a489ee12 cli(render): allow specifying output dimensions
git-subtree-dir: thirdparty/librashader
git-subtree-split: cbdbdafecdfd6113ef1cdc15e0a4140b46420f0b
We elect to just remove all usage of libra_viewport_t for Metal, since the current rendering path conforms better to recommended Metal patterns than passing the drawable texture directly to librashader would.
The libra_gl_init_context function has been removed. The OpenGL loader used to
create the filter chain, previously passed to libra_gl_init_context, is now
passed as a parameter to the libra_gl_filter_chain_create function.
The libra_output_framebuffer_gl_t and libra_source_image_gl_t structs have been
replaced with libra_image_gl_t.
The position of the viewport parameter in libra_gl_filter_chain_frame has moved
to after the output parameter, and its type has changed from libra_viewport_t to
libra_viewport_t *.
In order to retain the behaviour in ABI 1, output holds the width and height of
the previously used viewport and the viewport itself is removed and replaced
with NULL in the call to _libra.gl_filter_chain_frame.
4abd48eb24 capi(presets): support `d3d9_hlsl` VID-DRV
0007bd6d98 doc: update preset_ctx_set_runtime doc
72c72dafa0 capi(d3d12): remove unintentional IMAGE_TYPE infix for LIBRA_D3D12_IMAGE_TYPE
0fde712f3c doc: update librashader::reflect docs
2323b18710 capi(ld): add `LIBRA_RUNTIME_D3D9` define commented out
5978f95f76 reflect: make `ShaderPassArtifact` simpler as `PassResource` already includes the source data
3ee5e66c0d presets: make naming more consistent
f189468f6d ci: don't build cli for windows 7
fc47fb4c5a doc: typo
fc7739d9ab ci: update github actions
4a8a9ee444 chore: Release
756cbe63d9 cli: fix cli Cargo.toml
796b03b42b test: rework tests to work with ShaderPresetPack
742a1c8658 dep: update glslang
7c03a7e3fe doc(pack): reword doc on `ShaderPresetPack`
4ba6effc2f rt(mtl): fix test
32c99d9f4a rt: implement filter chain loading in terms of pack
75b70cc0e6 cli: add `pack` command to create a preset pack
828464c351 rt(image): helper to load image from shaderpack `TextureBuffer`
c19593e289 pack: implement shader pack library to preload resources from disk
1bbbd784d8 preset: make ShaderPassConfig and TextureConfig type aliases to PathReference
4273a833e8 pack: add librashader-pack
f14f45b3b1 rt: separate out meta information for textures
859d16e64e rt: separate out meta information to its own struct
b395b94a40 doc(abi2): add migration details for `libra_source_image_d3d12_t` layout
90a9ee754d doc: fix migration api typo
34b50059ca doc(d3d12,vk): clear up language for barriers
7a13136f9a capi(d3d12): allow d3d12 to optionally use a resource handle with chain-managed descriptors
0cb3880d7f rt(d3d12): allow construction of D3D12InputImage without a descriptor handle
c526b7043a capi(d3d12): change the layout so that descriptor is first in libra_source_image_d3d12_t
33d95ac399 rt(d3d12): allow creating input view without a CPU handle
40691cc406 rt(d3d12): allow creating output view from a resource ref
3c20c83bc9 rt(d3d12): use InterfaceRef for D3D12InputImage to avoid refcount for input image
b123f63a6e doc(reflect): fix link
4285ad2bd1 rt(d3d12): allow a pipeline to be available for multiple formats without recompilation
c57e502b78 rt(d3d12): make images with OwnedFramebuffer provenance use ManuallyDrop
7edff0ae35 rt(d3d12): allow manually specifying the strategy to get a manuallydrop for luts
dedde05c83 rt(d3d12): move update subresources to lut
7d483f2e08 rt(d3d9): take viewport by reference to avoid AddRef/Release
7b7fd99b92 rt(d3d11): take viewport by reference to avoid AddRef/Release
28931ae50a rt(d3d12): update d3d12-descriptor-heap
2fe7702957 rt(d3d11): avoid QueryInterface in GetSize
a5c8fcf4f8 doc: missing period
629070ea2f ci: build cli
da53c3df59 cli(render): make frame inclusive to ensure correct feedback and history behaviour
84e78f4e48 cli(render): add ability to specify frame options
91f8089277 cli(render): add ability to specify params and passes enabled
3993f57271 doc(cli): document CLI
55ff7a93f2 cli: rename librashader-test -> librashader-cli
227757a221 cli: parse transpile versions
a72a593029 reflect: allow indexed and non-indexed semantics to be serialized and deserialized as strings
1537c1bcd7 cli: ensure shaders are validated before compile
5573f13227 test: add CLI with multiple functions
bac09ad2a3 reflect: allow validation of shaders without reflecting against semantics
31ece05246 reflect: allow more reflection objects to be serializable
5ede061975 preprocess: allow shadersource to be serializable with serde
1676150858 presets: allow presets to be serializable with serde
eeda0d02d0 test: make RenderTest trait object safe
f7a938a00d deps: update dependencies
6394b28d40 deps: update dependencies
443fa20d22 test: clean up imports and features
5c726efe21 test(d3d12): Add D3D12 render test
d33c2a84b2 test(d3d9): Add Direct3D 9 render test
5a35a2bd1e test(render): reenable cache
41034330a7 test(mtl): Add Metal render test
a7836923d7 test: split test harnesses into features
20039b9347 test: abstract test framework
799d409ddb test(gl): Add OpenGL render test
79513a301e test(vk): Add Vulkan render test
6de2de8d12 test(wgpu): Add WGPU render test
2904a2ac10 test(d3d11): Add D3D11 triangle test to image
341fbceb82 rt(d3d12): derive clone on D3D12InputImage
c54747d398 deps: update dependencies
3888b56c83 rt(d3d9): accept input image by reference
b0df631651 rt(d3d9): load LUTS as BGRA8
dbfa822f7c rt(d3d9): disable alpha blending
e7fe96520e rt(gl): ensure framebuffers are bound
97ad0d64bf rt(gl): make FilterChain::load_from argument order consistent with other runtimes
feaebc5f44 fmt(gl): cargo fmt
ef35e2a620 presets: rename to_hashmap -> into_hashmap
987e967269 doc(capi): add error doc for infallible error
c3469520f9 examples(d3d11): fix d3d11 examples
45b98a2bdd rt(gl): use array_init instead of manually doing it with MaybeUninit
2ee9eca854 ci: ignore .DS_Store
59937aced5 fmt: cargo fmt
e4eed34c10 capi: const qualify chain in `_filter_chain_get_param` and `_filter_chain_get_active_pass_count`"
7abd679bd7 doc: add migration docs
41353ac9c4 rt(gl): remove need for explicit external FBO object
4d790e7a7b doc: update ABI versions in version.rs and readme
aeb0a16cfb rt(vk): allow specifying the queue to use
16108838b1 rt(d3d11): remove unneeded transmutes
7cfbca7755 rt(wgpu): remove unnecessary output move
8467e5cd97 rt(mtl): remove unnecessary output move
1e33b4cc03 capi: make viewport optional, defaulting to a viewport that is the entire size of the render target
eb53699590 capi(include): update headers
0cbf8024a7 build: update soname
7e354a56a1 capi: upgrade cbindgen to fix syn bug
0a87bcc657 rt: respect viewport extents when rendering
f0a7970b44 rt: add viewport extent separate from output texture dimensions
e7e6ed8fb8 capi: remove _internal_alloc from libra_preset_param_list_t
61fdaeea14 capi(gl): update to take opengl context in constructor
2552d4321b capi(gl): set output in libra_output_image_gl_t, not viewport
eaf939c861 capi(vk): set output in libra_output_image_vk_t, not viewport
14abb0362b capi(d3d12): set output in libra_output_image_d3d12_t, not viewport
e064f8d0be capi(d3d12): remove ignored fields from libra_source_image_d3d12_t
f18c22a95a capi(d3d11): take ManuallyDrop<ID3D11ShaderResourceView> directly in libra_d3d11_filter_chain_t
763c05755d rt: mark error types as non_exhaustive
e6d23f1d8f doc: update opengl example
2f9df143cf deps: consolidate and update dependencies
1bdadaa449 rt(gl): port to OpenGL runtime to glow
77b957bf5e reflect: stop adding null bytes to uniform names
1e0727f89d chore: Release
60d2c3f177 chore: Release
72a98272f3 doc(capi): document all C API members
7d0b135710 rt(mtl): remove unused 'pass lifetime
4ba5aefafc capi: don't export wrap_ok macro
6edfaed91f test: update slang-shaders
cd877d7883 build: respect CARGO env in build script
d56d92ea0f test: update slang-shaders
f49e3b58d8 doc(capi): fix rotation integer docs
1f4f1b6c12 capi: Fix Metal error message, function header
57f2dabf0c reflect: fix `CurrentSubFrame` being parsed as `TotalSubFrames`
81840a9e9c reflect: insert alias semantics for shader name through pragma
87e0405675 presets: properly trim shader name if given through pragma
e0c97f77b4 build: nicer build script messages
6e60dd6fa0 test: update slang-shaders
d55d0e4839 rt(mtl): use f32::MAX for lodMaxClamp
6cdd9247de presets: trim aliases and shader parameter names
cbe6510f76 preprocess: the step argument is optional according to slang-shaders spec
d6f8950bdc rt: only draw last pass twice if the last pass is needed as feedback
0fe5bbd57b rt: do reflection to see if the final pass is needed as feedback
eace595ebb chore: Release
66561ad2ed doc: fix header image
05d48841ad doc: update docs for stable build instructions
927740433c build: remove unneeded image dependency
316e92dc09 build: allow building stable with --stable flag
e930f90a9c capi: allow building on stable by gating #[doc] comments
2f988d5b1d rt: add stable feature to build ShaderPassArtifacts via Box<dyn CompileReflectShader>
e0a5c90103 reflect: implement stable FromCompilation
4cc3c875bf reflect: allow compilation of boxed trait objects
805854b94b reflect: simplify FromCompilation output signature
c291d9d85f capi: remove dependency on `try_blocks`
8b2ff57ee8 reflect: replace `let_chains` with `Option::filter`
3d9139b4e0 rt(d3d11): replace `let_chains` with stable alternatives
b432a1e02d rt(d3d12): replace `let_chains` with stable alternatives
ab9ab6fe68 rt(gl): use `Option::filter` instead of `let_chains`
0ba4c482b3 rt(vk): use `Option::filter` instead of `let_chains`
57f9a13ee7 rt(wgpu): use `Option::filter` instead of `let_chains`
2661effab4 chore: Release
02288554b9 rt(mtl): fix history buffer off-by-one by buffering the history read.
98d8d91c66 capi: undo const qualification of chain in `_filter_chain_get_param` and `_filter_chain_get_active_pass_count`
6f5b342c1b build: fix dev-dependencies on non-apple
bec0482513 ci: trigger ci
e24beede0b rt(mtl): draw final pass to output targets
22b2118e97 rt(mtl): don't resize if the requested format differs from optimal format
856f69113d rt(mtl): don't make mipmapper for history if not needed
477d0ae67c rt(wgpu): draw final pass to output targets
e68da7b984 rt(gl): draw final pass to output targets
666588ef0d rt(vk): draw final pass to output targets
336f540ce9 rt(d3d9): draw final pass to output targets
894d19eb81 rt(d3d12): draw final pass to output targets
1bf5d7efca rt(d3d11): draw final pass to output targets
c9205bc922 rt(mtl): remove internal_frame_count
cebc7a939a rt(mtl): fix faulty history but only copying one mipmap slice of texture
fe48fd03a5 test(mtl): update the metal test
50580cfc3b chore: Release
075a2981e1 rt(gl): fix `glShaderSource` going past the buffer
a7dd40a79f ci: allow c_str_literals to maintain a lower MSRV
fd8d6f6ab8 chore: Release
c5fdffa6aa dep: update cargo.lock
090e268c4a doc: improve docs
8856a78eb8 api: expose `FastHashMap` and `ShortString`
ec3add1616 rt(params): rename get_parameter -> parameter_value
f83fd1e98f ci: debug is broken on windows 7
c3033cfbbf reflect: port to spirv-cross2
820fb69328 reflect: remove get_prefix from get_texture_semantic/get_unique_semantic
c9a6411394 deps: consolidate and update dependencies
40a56bf165 reflect/preprocess/presets: use SmallString where it makes sense
c447e40583 rt: redesign parameters to be thread-safe across FFI using arcswap and atomicusize
ae76bf9cc1 rt(d3d12): pull out descriptor heap implementation into its own crate
e934f175ef rt(d3d12): stop leaking transition barriers
2e7c3b3273 rt(d3d12): use gpu_allocator instead of CreateCommittedResource
e90c27ebbd rt(vk): use manuallydrop for VulkanBuffer rather than Option
8fb5d48a1e chore: Release
b7fd3bc507 runtime: fix image swizzle for remainder
af05cc5bd8 ci: build for windows 7
2f0a3356d9 rel([email protected]): doc fix
0efaf2b8a0 doc: fix docsrs build on macos
436d1fe3cd chore: Release
0ce11bac71 doc: promote d3d9 to secondary support
bc269c270c rt(d3d9): remove backtrace from Direct3DError
db3d5d05a6 presets: use crate for extract_if with fully qualified syntax to avoid name collision with unstable std
1957f576ca reflect: further improve link i/o pass by ensuring that the output SPIR-V is valid according to Vulkan 1.0 semantics
5560c1ed09 runtime: use a more efficient swizzling implementation without array_chunks_mut
f8c055524b doc(readme): document shader pre-linkage
fee92113f1 ci: remove PR full test
45c3c876f4 reflect: remove explicit compile function in favour of TryFrom
28f5674a80 presets: remove rustc 1.74 compatibility
bffad12ea2 doc(presets): add docstring for ContextItem::key
321e30a0f1 capi: extend config_struct macro to handle overrides
9b40c10466 reflect: improve inout link algorithm
cd14bca23a Revert "reflect: improve inout link algorithm"
1ac78695c6 reflect: improve inout link algorithm
d1e49b7eb4 rt(d3d9): search "global" namespace for register assignments
5ef0055e05 rt(d3d9): fix vertex assignments accidentally searching fragment
1c6581d737 rt(d3d9): set colorwritemask to all
ac66b1b6f6 style: fix warnings
977975f4c7 doc: document naga reflect
3b9514ad38 doc: allow wgpu doc on apple
899fb50da6 chore: Release
162226ce44 ci: don't build locally
039fdfd41a ci: update OBS build platform
e13bb88df2 doc: update MSRV due to naga
7b375658c5 dep: update cargo.lock
3fb6e3843e dep: update to windows 0.58
3cda5b706d rt(d3d12): get rid of size in inputview
4d6793d305 rt(d3d11): get rid of input/output view wrappers
35f499f5e1 wgpu: enable pipeline caching
6ce711db26 ci: don't build Arch
d4b4366836 dep: update ash to 0.38
c646086df4 dep: update wgpu
f6cf642e50 chore: Release
98958dfb5e dep: update rustc_hash
b5d523e9f3 rt(mtl): move icrate definitions to objc2-metal
5e9ce1207c Revert "ci: temporarily remove deny-deprecated on ctypes to unblock ares"
1b0574c140 presets: show file name and details on io error
b84e104212 capi: fix malformed vulkan include
git-subtree-dir: thirdparty/librashader
git-subtree-split: 4abd48eb244e15ca40307f28fce0061627ff0143
aaca599e18 Merge pull request #130 from notaz/release_lzma_init_buffers
2099836c2b release lzma init buffers
9b6ff6c3c2 Merge pull request #128 from scribam/zstd-legacy
85dd19217a Merge pull request #129 from scribam/arm-neon
71e57f533d lzma: extends neon support when hwcap is not available
a6c474ddee zstd: disable legacy support
git-subtree-dir: thirdparty/libchdr
git-subtree-split: aaca599e18e43933fc193bd1b715c368c306208b
f6326087b3 Improve op flags operation on x86
2a79c59737 Fix sign conversion warning on Windows arm64 (#270)
7a6ceb3e03 Fix examples (#269)
2c105e2461 Fixed a compare logical case on s390x
4c4802dd4c Emit brk #0xf000 for breakpoint opcode on arm64 (#267)
3b9c0c8925 Enable public usage of SLJIT_LOCALS_OFFSET (#264)
4dd388a736 loongarch: add memory fence & support tmp register for atomic (#263)
8c089bd584 Implement m,emory fence
d21a5448f6 Fix compiler warning
f9f512c080 Support tmp register for atomic
883118537c Add action (#259)
8099661b54 Add SLJIT_ATOMIC_USE_LS/CAS support to LoongArch (#261)
728db2007a riscv: only enable SIMD if supported by toolchain (#260)
8727735933 Bitmanipulation instructions on RISC-V (#258)
c85dd1dd97 Rework sljit_emit_enter argument passing
3e5568bfcc Add more tmp reg tests
bd056ab1df Add control flags to atomic operations
ee8861243f loongarch: Implement ll/sc support for atomic operations (#254)
d3a10d1986 x86: avoid SIGILL in CPUs with AVX but without AVX2 (#256)
460f02a1b8 x86: check for extended function availability before using (#255)
0a74f16bea x86: improve execute_cpuid() portability (#251)
7b0fd86bd5 test: avoid leaking compiler on early exit (#253)
31cfa2fef2 Add shuffle support for LoongArch (#252)
06a5bafd7c Initial implementation of riscv simd
5ad2541117 x86: improve execute_get_xcr0_low() portability (#250)
6128486813 Implement atomic store on ppc and mips
fcade55c27 Update atomic on s390x
8bcd711708 Rework atomic load/store
bd221f0e86 Support non-overlaping vector registers
git-subtree-dir: thirdparty/sljit
git-subtree-split: f6326087b3404efb07c6d3deed97b3c3b8098c0c
256KB of SRAM is possible on hardware and many hacks use it (Super
Metroid Practice ROM, Super Mario Bros. Maker, etc.). It could be
implemented in Ares in many ways, but I limited the ramSize to 1-8 with
a wrap-around as values higher than 8 wrap-around when used (9 is the
same as 1, 10 is the same as 2, etc. verified by
[kandowontu](https://github.com/kandowontu)).
Implements the following changes:
- Bits 8-11 of SIOCNT should be read/write
- Mode specified by SIOCNT uses 2 bits rather than 1
- Lower 3 bits of JOYCNT are cleared when 1's are written
Needs to merge #1654 first.
Enables loading folders instead files from cmd line.
Removes loading firmware files from rom folders in sfc mia (firmware
data would be loaded twice, db hashes would not match anymore).
Adds a 2-cycle synchronizer delay to IRQs. Unhalting the CPU also
appears to be delayed by 2 cycles.
The GBA CPU core currently steps in increments of 16 cycles when halted
or stopped to reduce emulation overhead. Since this optimization can
cause unhalt timings to be off by a few cycles, this PR reduces the step
size for halt mode and removes the optimization for stop mode.
Performance impact should be minimal in cases where performance is a
concern.
Minor code cleanup. clang reports that it's possible under some
circumstances these variables are uninitialized when used.
Overall motivation is to utilize some stricter compiler settings in the
future and error on `-Wuninitialized`.
This change contains a large refactoring with no functional changes,
plus a small functional change that will help speeding up the JIT.
The refactoring allows CPU::devirtualize to return all the information
regarding the memory access. This in turn allows to simplify all memory
ops (which contained lots of duplicated code) to use devirtualize,
reducing code duplication.
The functional change is that we now use JIT only when running code from
icache (which is 99.9999% of the times). Running code without icache is
extremely slow on real hardware and only happens in specific situations
(eg: during boot when RDRAM is not initialized). By limiting the JIT to
run from icache, we open the door to implement proper icache support in
the JIT and finish remove the instruction epilogue with its slow
"instruction cache stepper" (which in addition to being slow, is also
inaccurate and make us fail cache test ROMs).
Currently, gdb hooks in n64 doesn't allow for large sizes of writes
because it wouldn't be obvious which data size use on the bus. While
this is true, it doesn't really matter for RDRAM where all data sizes
work in the obvious, correct way. So relax the constraint to allow
writing large portions of RDRAM with a single gdb command.
Co-authored-by: Chase Meadors <[email protected]>
Co-authored-by: Luke Usher <[email protected]>
Originally, to run ares on Linux after building it, you'd `make install`
which copied everything into the right places in your home directory.
Windows and macOS don't have the same traditions about installing apps,
so on those platforms the makefile staged a "portable" installation in
the output directory.
Since then, `make install` was modified to install ares system-wide.
It's possible to use it to install ares into your home directory, but a
bit overkill. For consistency, let's also stage a "portable"
installation in the output directory on Linux and the BSDs, so it's
easier to test on those platforms.
Essentially a revert of fbaf7d8118
This optimization was found to compromise correctness due to the lack of
alignment checks. If something like this proves truly beneficial for
performance, we can bring it back.
If you like to slow down booting into your game and want to read the
same old text each time on the Mega Drive, the option is yours now! This
is available as a choice in Settings > Options now. By default, this
will not be enabled (same behavior as existed prior to this PR). You
don't need to specify anything in the firmware section, ares had the
plumbing in place all along, it was just hardcoded to not load the tmss
boot rom.
The Sufami Turbo base cartridge is listed in the Super Famicom verified
dump database, so it did not use the heuristics. It turns out the
heuristic detection wouldn't have worked anyway - although the game's
header does contain the serial A9PJ, the heuristic revision() method
does not report that serial at all.
Meanwhile, the serial A9PJ is *also* used by the game Bishoujo Senshi
Sailor Moon SuperS - Fuwafuwa Panic, so loading this game would prompt
for Sufami Turbo mini-cartridges even though the game could not make use
of them.
I have used mia to generated heuristic manifests for every SNES/SFC game
in the No-Intro set, and the only difference introduced by this change
is that the Sufami Turbo base cartridge is now detected as having Sufami
Turbo slots, and Fuwafuwa Panic is not.
It took me a little messing around to find a syntax for comparing an
`array_view<u8>` that the compiler would accept; if there's some more
concise or idiomatic way to do it, please let me know.
Of the other emulators I surveyed, bsnes works just like ares did,
MesenS doesn't seem to support the Sufami Turbo, and snes9x uses a
slightly stricter check than I implemented:
https://github.com/snes9xgit/snes9x/blob/85591435763dede7ef111aab8070cdf2d5a7da49/memmap.cpp#L1016-L1023
MSVC build logs are complaining [very
loudly](https://github.com/ares-emulator/ares/actions/runs/10524248801/job/29160592080#step:10:835)
about unknown pragmas.
Only clang complains about these code areas currently, so for now, just
put these diagnostic pragmas behind a check for clang. If MSVC pragmas
end up being a good idea, could look into compiler-agnostic pragma
macros, but that doesn't seem necessary at present.
Removed `__VA_ARGS__` from line 6 of interpreter.cpp, since it appears
to be unused and was causing compiler issues. Tested on Ubuntu with g++
and clang++ with both interpreter and recompiler running a default build
of n64-systemtest.
---------
Co-authored-by: invertego <[email protected]>
This will bloat generated code in the short term, but some of that can
be elided with future optimizations.
Passes [n64-systemtest](https://github.com/lemmy-64/n64-systemtest) with
both the interpreter and recompiler.
---------
Co-authored-by: Giovanni Bajo <[email protected]>
A better fix for the problem discussed in
https://github.com/ares-emulator/ares/pull/1412.
Also unbreaks CI.
Changing `clipsToBounds` was fine, but the property isn't exposed on
older SDKs (that are still used by ares to maintain backwards
compatibility), and exposing it manually when building with an older SDK
was not great practice (and may have just been a noop anyway).
Instead, we should just not draw on the dirtyRect, when we intend to
draw on the view's `bounds`. Apple's documentation on this subject is
pretty thin on the ground, not to mention contradictory, especially
pre-macOS 14. But it seems pretty clear that in any case, a view's
`bounds` will always be the area we intend to draw on, while the view's
`dirtyRect` may or may not be. So here we make every element in hiro's
Cocoa implementation that does manual drawing always draw using
`bounds`.
More code cleanup for the new build system along with
https://github.com/ares-emulator/ares/pull/1602,
https://github.com/ares-emulator/ares/pull/1603, and
https://github.com/ares-emulator/ares/pull/1604.
This one is fairly mysterious. clang thinks that all paths through this
particular signature of the `square()` function call itself. This area
of nall is a mass of templating and operator overloads, and figuring out
exactly what's going on here would be a good one to unravel for a
large-brained, C++-enjoying individual.
For now, just ignore this warning locally so that we can compile the
rest of ares while still warning about infinite recursion elsewhere.
Enforce newlines at end-of-file in the codebase.
While every modern compiler is able to deal with not having EOF
newlines, it is still a good idea to enforce this.
ParaLLEl-RDP has a few files without EOF newlines, so I surrounded the
n64 Vulkan `include` with a diagnostic pragma to ignore it. This avoids
having to deal with compiler errors if ParaLLEl-RDP is updated, pending
newlines added upstream.
Fixes several issues and compiler warnings with hiro's Cocoa
implementation. Among them:
* We were technically declaring `clipsToBounds` incorrectly; properties
in subclasses aren't correct and can conflict with the system version;
rather, implement it as an instance method.
* Fix some non-strict pointer aliasing in menu-separator.cpp;
* Remove a couple blatant unused variables from desktop.cpp and
monitor.cpp;
* Fix an instance passing nil to a function that requires a non-null
argument in popup-menu.cpp;
* Some ancient C functions in Cocoa don't pass -Wwritable-strings; for
now, just surround the function that uses them with a clang diagnostic
pragma.
In C++ land:
* Various C++ functions were `override`s but were not declared as such.
Lastly, the second commit:
* In Objective-C, you declare subclasses in the `@interface` header, but
not in the implementation. hiro was including the superclasses in the
`@implementation` block, which isn't correct. For some reason, clang was
only erroring on one instance of this, but we go ahead and fix it
everywhere.
Removes apparently dead, unused functions in the OpenGL backend.
### Context
Work continues on the new build system. Among its goals are to start
compiling ares with stricter settings, where applicable, to increase
code quality. This includes removing unused functions, to satisfy
`-Wunused-function`.
Some systems report target-triples below i686, although they target i686
in reality. One such system is FreeBSD since version 13.0. It reports
i386 but targets i686. Without accepting target-triples below i686 such
systems can't compile ares on the x86 architecture.
Currently, the prefetcher halts whenever DMAs are running. However, on
hardware the prefetcher is able to keep running until DMA accesses
cartridge ROM. This PR implements said behaviour, allowing ares to fully
pass the mGBA test suite timing tests as shown below:
Added missing serialized fields to N64 save state, one in AI and one in
PI (both added in same commit).
Scanned the other sections looking for other missing fields so we don't
need to invalidate save states frequently and I didn't spot others that
were missing right now.
The 2 DMA idle cycles currently processed before running a DMA channel
should instead run for 1 cycle when DMAs start, and 1 cycle when the
DMAs have all finished.
The OSS audio backend was very limited in its capabilities and its error
handling. Essentially it supported only the initial parameters for
channels, format and frequency, e.g. 48000Hz 16bit stereo. If the audio
device didn't support these parameters, the backend would keep using the
initial values although OSS had probably adjusted the parameters to
supported values. Be aware, there are possible configurations for the
system and the audio devices which don't support the above mentioned
standard values, e.g. on FreeBSD it's possible to configure an audio
device to only accept 96000Hz 32bit 7.1 surround sound.
Now the OSS backend takes the changed parameters for channels, format
and frequency into account, updates the resampler accordingly and feeds
the audio data into the audio device with the right format.
It appears the datasheet was not entirely conclusive with regard to how
the CPU handles chains of more than 7 consecutive instruction prefixes;
in addition, Ares was incorrectly using the *first* rather than *last*
segment override in the chain.
This doesn't affect well-formed code (duplicate instruction prefixes
should never happen, nor should more than one segment override), but
brings Ares up from 2/7 to 7/7 in
[ws-test-suite](https://github.com/asiekierka/ws-test-suite)'s new
`mono/cpu/prefixes` test.
Replace deprecated elements with suggested replacements.
QApplication::hasPendingEvents() and QWidget::paintEngine() are still in
use, their replacement is way out of scope for this PR.
The Superampling option in the Video category isn't visible in QT5
builds, the settings window is too small. Therefore increase the height
of the window by 20 to unhide the setting. This also gives the setting a
little bit more distance to the bottom edge in GTK3 builds.
Currently a per-instruction epilogue is needed to make sure the
read-only register r0 stays as the value 0. To improve performance of
the generated code, we'd like to move this operation to be done only
when needed.
This commit solves the above problem in two ways: simple instructions
are never emitted if their destination register is r0, and more complex
instructions now emit a clear operation right after. This way exceptions
are still thrown when needed.
Address some edge cases of LDM/STM instructions (also affects Thumb mode
PUSH/POP):
- Using an empty register list will cause R15 to still be accessed, but
the base register will be modified as if all 16 registers were accessed
- Writeback does not occur in LDM if the base register is in the
register list
The hardcoded `/usr/share` for the sharedData location doesn't respect
the given prefix, e.g. `~/.local` or `/usr/local`. This results in the
emulator not finding the shaders or databases in case the emulator is
not installed under `/usr` and the files are not found in the
application or user data directory.
Now the build script defines a preprocessor constant `ARES_PREFIX` which
is set to the requested prefix. With the help of the C preprocessor
stringize operator, this prefix is then used as the root of the
sharedData location.
Fixes https://github.com/ares-emulator/ares/issues/1179
These commits improve the compatibility with FreeBSD. Among some
cosmetic changes is a commit to unbreak the build on FreeBSD and two
commits adding an audio and an input backend to FreeBSD builds.
There's still a change needed to make ares completely buildable on
FreeBSD:
use of `CLOCK_MONOTONIC` in
`ares/n64/vulkan/parallel-rdp/util/timer.cpp`, see
https://github.com/Themaister/Granite/pull/135. This change will
propagate to ares if/when Granite upstream merges the PR, parallel-rdp
adopts the updated Granite and ares updates its parallel-rdp.
Provides a getDebugger function for the ARM debugger to read memory
without advancing CPU state, fixing a bug where GBA core CPU timings
were impacted by debugger use.
Automatically detect the (clang-)cl target architecture instead of
assuming amd64. Note that -print-target-triple is now used in favor of
-dumpmachine for all versions of clang. This option has been around for
ages in the regular clang driver but is only supported by clang-cl as of
LLVM 18, which isn't yet available via the Visual Studio installer but
is available through a standalone installer on GitHub.
This commit also adds a compiler flag to the command line when targeting
arm64 with cl to work around an optimizer bug.
On versions of make prior to 3.82, pattern matching rules are applied in
the order they were first defined, as opposed to the probably-desired
order of most specific to least specific. In ares, `nall`'s pattern
matching rule comes fairly early on and is thus used to build most of
ares. The parallel-rdp build code in ares defines its own pattern
matching rule, which caused building with 3.81 to not work since the
more specific rule is not used, and the less specific rule cannot be
applied successfully.
For other fun reasons, macOS still ships with make 3.81 (released in
2006).
This PR just allows building on macOS's stock `make`, which means a bit
less effort in building, as well as easier integration with IDEs (in my
testing so far, what few IDEs on macOS support direct Make integration,
seem to require or expect the stock toolchain).
There may be slightly more elegant ways to do this, but this pattern
conforms with how object paths are defined for other third party
dependencies around ares.
Eventually™, if ares migrates to CMake, there could much better cross
platform build tool integration (generating Xcode or other OS project
files as desired, for example). Until that point, it is convenient to
support the stock toolchain on all operating systems if possible.
Co-authored-by: jcm <[email protected]>
### OpenGL rendering (all platforms)
- librashader specifies that the output viewport should be the same size
as the output framebuffer texture. This was not the case for the OpenGL
render code.
* Previously, librashader under OpenGL would render onto an intermediate
framebuffer sized to the "output" size (the entire window view size),
rather than the "target" size (the final composited size of the game
area within the output area). The `libra_viewport_t` would be sized to
the target size, but the underlying buffer would be larger.
* Now, we size the intermediate framebuffer to the "target" size, let
librashader render onto it with a `libra_viewport_t` that matches that
size. In the final pass we sample this buffer within an area of the
"output"-sized buffer as appropriate.
This prior behavior would lead to scaling issues with shaders in the
Metal backend. The same issues did not seem to be obviously present in
OpenGL in my testing, but we should nevertheless probably fix this in
case it is causing any of the subtle issues with shaders that have been
reported, and also in case something breaks in the future as a result of
not following this recommendation.
(The above is also unrelated to the scaling issues addressed by
https://github.com/ares-emulator/ares/pull/1508)
### CGL fix-ups (macOS)
- Backports the native fullscreen and monitor selection options to
OpenGL, and removes unnecessary custom window code from the OpenGL
driver.
- Removes a seemingly unnecessary output call from `reshape` that would
cause flickering during resizes.
This has been tested on macOS but should probably be tested on other
platforms as well to make sure nothing breaks.
Co-authored-by: jcm <[email protected]>
This originally added the N64, but after inspecting remaining
cartridge/card/fixed ROM based systems I have also added the additional
four so that hash is available in manifest. This should complete adding
this info for these types of consoles.
N64
Gameboy Advance
MyVision
SG-1000
Sufami-Turbo
Testing some games on Coleco Vision & Atari 2600 and noticed that the
SHA256 ROM hash was missing from the manifest for these two, which I
have now added.
c2e49625e Fix incorrect argument order in x86 sljit_emit_simd_lane_mov
68bb7c7cc Support shuffle on s390x
b3f492960 Support simd shuffle operation
git-subtree-dir: thirdparty/sljit
git-subtree-split: c2e49625e4be2f1e62263044527fe83cce88d2f2
1. pass mmc3/3-a12_clocking.nes
2. refactor the ppu/var and ppu/scroll
3. fix ppu var and scroll read/write($2005/$2006/$2007)
4. inc serialization to v144
5. fix the color generator
6. fix the game Burai Fighter (USA)
7. pass issue #151
Currently, gdb is polled once per frame, which seems enough for
interactive usage. Some ROM hacks would like to use the gdb interface to
provide additional emulation-only features such as online multiplayer,
but that requires a faster turnaround.
A quick solution is to poll gdb more frequently within the n64 core.
This patch does that once per screen line, approximately. Notice that
the poll is only scheduled and run if there is a gdb client connected so
it should not cause any performance impact on normal users.
Just a small fix to account for the new video settings in Metal; the
threaded renderer, native fullscreen behavior and color space option.
These options were not fully persistent because the `videoDriverUpdate`
function (run on startup, among other times) did not account for them.
They would be set correctly in `settings.bml` and the settings object,
but would never actually be set correctly on the driver struct.
Co-authored-by: jcm <[email protected]>
* The behaviour of bits 0-3 and 7 in the control/status port were a
complete guess and had no reflection in hardware testing. They have been
adjusted to match hardware.
* The EEPROM interface always writes and reads out 16 bits to/from the
EEPROM, including the initial zeroes in the command value. The M93LCx6
code has been updated to support this case in line with the datasheet.
* The read and write data port have been separated. This was a detail
which every community documentation in existence got wrong, so no
worries about that one ^^
* Internal EEPROM protection has been implemented.
* The handling of invalid control commands (more than one bit set) has
been fixed.
* Emulation of the 93C46-family internal EEPROM on SPHINX in ASWAN mode
has been implemented. In particular, this fixes running any mono
WonderSwan game which takes advantage of the internal EEPROM on the
WonderSwan Color system's compatibility mode.
All of these changes pass the relevant tests in
[ws-test-suite](https://github.com/asiekierka/ws-test-suite)
(mono/eeprom/internal.ws) both as a WonderSwan and a WonderSwan Color.
This isn't 100% accurate (particularly, timing is not reflected; but
there are also some questions about more edge case-y behaviour), but
it's much closer.
The paraLLEl-RDP build was broken on macOS because of a change from
February to Granite in regarding platform ifdefs for pthreads.
A PR that applies a fix has been opened
[upstream](https://github.com/Themaister/Granite/pull/131), but until an
upstream fix lands, this PR will unbreak the build for ares without
needing to roll back the recent paraLLEl-RDP update entirely.
Co-authored-by: jcm <[email protected]>
Reduces the synchronization interval between the GBA CPU and other
components from 64 to 16 cycles, which significantly improves PPU
timings in the performance profile. These PPU timing improvements can be
observed in
[status-irq-dma.gba](https://github.com/nba-emu/hw-test/tree/master/ppu/status-irq-dma),
which now frequently gets results within a few cycles of the correct
values in situations which were previously off by dozens of cycles.
While this does impact performance by ~5-10%, in my testing this is
still faster than versions from before [commit
b145f0f](https://github.com/ares-emulator/ares/commit/b145f0f000c4e0ddedf25a62cdcfe713deea1f6a).
This PR improves handling of BIOS open bus edge cases that previously
were handled incorrectly, such as unaligned 8-bit and 16-bit accesses,
and cases where the last value read from BIOS was not a 32-bit value.
Compiling with GCC 14.1 in MSYS2 caused a lot of warnings of the
`-Wcast-user-defined` variety. This PR adresses that.
Note: This PR does not address
https://github.com/ares-emulator/ares/issues/1399 . Those warnings
happen at the link stage, they don't seem to be GCC-only (since issue OP
also reports them with clang), and they don't appear at lower
optimization settings (I tested `build=debug` and `build=stable` which
compiled cleanly).
pass blargg_ppu_tests_2005.09.15b/power_up_palette.nes
pass "Hello World" PPU test:
https://github.com/PeterLemon/NES/tree/master/HelloWorld
In https://forums.nesdev.org/viewtopic.php?t=567#top,
blargg say: "The power-up values of the palette are what my test program
reads back after powering the NES. I have one of the older units that
shows a green screen (I think newer front-loading ones had a gray
screen). These values probably vary slightly from one console to the
next."
Palette at power-up
0x09,0x01,0x00,0x01,
0x00,0x02,0x02,0x0D,
0x08,0x10,0x08,0x24,
0x00,0x00,0x04,0x2C,
0x09,0x01,0x34,0x03,
0x00,0x04,0x00,0x14,
0x08,0x3A,0x00,0x02,
0x00,0x20,0x2C,0x08,
To read/write a cgram, it needs to and 0x03, not 0x13
In https://www.nesdev.org/wiki/PPU_palettes#Memory_Map
$3F00 Universal background color
$3F10 Mirror of universal background color
$3F04 Normally unused color 1
$3F14 Mirror of unused color 1
$3F08 Normally unused color 2
$3F18 Mirror of unused color 2
$3F0C Normally unused color 3
$3F1C Mirror of unused color 3
For IPS patches that extend the original ROM beyond its initial size, we
will now resize the target buffer when patches extend the size of the
original.
Originally found testing out the Shin Megami Tensei patch by Orden
(https://www.romhacking.net/translations/2616/), which will now work
correctly.
Latches writes to timer registers for 1 cycle. This fixes common
off-by-one errors with precise timer use, which for example positively
impacts the test cases in #154.
This PR applies several minor fixes and improvements to macOS driver
settings and the driver settings pane.
#### Remove the "exclusive mode" video option on macOS.
* There is no real notion of exclusive presentation on macOS beyond what
already exists in normal fullscreen. If an application is covering the
screen and no other application or window is visible, the system
automatically switches to a "direct" presentation mode that optimizes
for single-application presentation performance. There is not a good
reason to show this option on macOS, even disabled.
* By contrast, it is possible (though not implemented by ares) to enter
exclusive mode on the audio device with CoreAudio, so leave that option
there, just disabled.
#### Add a "use native fullscreen" option on macOS.
* There are various good reasons to prefer either native platform
fullscreen behavior, or a custom borderless windowed fullscreen. Rather
than guess what the user wants, offer an option.
* If unchecked, make the window title bar enlarge the window rather than
fullscreen it, so we don't mix behaviors.
#### Implement fullscreen monitor selection behavior for Metal, and
correctly enumerate the user's monitor names.
* Fullscreen display on the selected monitor in the settings pane was
previously not implemented on macOS. This implementation only works if
"Use native fullscreen" is disabled, since the macOS fullscreen idiom
doesn't feature selecting a specific display.
* Additionally, the old function to retrieve the monitor's localized
name did not work reliably on newer macOS versions. Use the modern
property `localizedName` on NSScreen for macOS versions above 10.15, and
fall back to the old implementation otherwise.
* Implementing this meant adding a `uintptr` handle to the NSScreen
instance in the `Monitor` struct in ruby that uses a bridged cast to
interface with Objective-C. I would have preferred not to do this, but I
didn't see another good way to handle getting the `NSScreen` instance
that didn't involve a serious refactor.
#### (all platforms) Disable monitor selection if the video driver's
`hasMonitor()` is false.
* Just a minor fixup; the existing behavior is that the dropdown list
can be navigated and selected, but the selection does not persist. It
makes more sense to just disable it if the driver doesn't support it.
Co-authored-by: jcm <[email protected]>
- v2 will be unavailable from the end of June 2024
- v4 can be up to 98% faster than previous versions according to
[Github's
notification](https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/)
This PR only changes the version number, and I'm submitting it to see if
it works.
It is possible that further changes are necessary, as there were some
[breaking
changes](https://github.com/actions/upload-artifact?tab=readme-ov-file#breaking-changes),
but I don't think any of them apply to ares.
Testing:
- See if CI passes
- See if warnings regarding using v2 of `upload-artifact` and
`download-artifact` are gone (There will still be other warnings
regarding `checkout` and `cache`)
- (Optional) Compare times for the tasks using `upload-artifact` and
`download-artifact` with previous CI runs
Turns out the problem some folks experienced trying to load 64DD games
was due to run ahead not being disabled by default. An exception for
this system has been added.
#1463 renamed the `macos` build to `macos-latest` and introduced
`macos-compat`. We need to address the rename in the release workflow. I
believe this PR accounts for every use of the package name. Also adds
macos-compat to the release (for now).
Co-authored-by: jcm <[email protected]>
clear() in Metal was implemented by outputting a (1, 1) sized output
buffer. This was very quick and dirty though generally worked.
With librashader introduced in the render output chain, outputting a (1,
1) sized buffer can sometimes, depending on the shader, introduce an
intermediate pass that involves a (0, 0) sized MTLTexture, which can
lead to assertion failures and possible crashes.
This PR adds an actual clear() implementation that just does a blank
render pass. the clear color on the drawable is already defined during
initialization so we do not need to redefine it here.
Co-authored-by: jcm <[email protected]>
Added a section for building librashader on Linux
Didn't want this to get too long or distro specific so these should be
the absolute minimal instructions for the platform.
This PR does a few things:
- Updates ares to create macOS builds with the latest SDK. After
https://github.com/ares-emulator/ares/commit/65264090b06853f3d831f507a3335d9c42e8a198
there are no longer any outstanding issues doing so. Importantly, we use
Xcode 15.2, since prior versions have issues with weak linking.
- Adds `macos-compat` to CI as a compatibility build that maintains
macOS 10.9 to 10.13 compatibility. The `macos-latest` runner will target
10.13 and above. The only difference with this build is the SDK version
used to build it (Xcode 13.4); macOS weak linking handles the rest.
- Increments the MoltenVK version to 1.2.7. The version ares was
building required a Python library `distutils` that is no longer
trivially available with newer Python versions.
- Refactors the `xcode-select` usage reserved for GitHub Actions out of
the SDL script and up to the top level, before any dependency scripts
are run. This is just tidying up.
- Improves the librashader build script warning to specify that you need
to add a target with the nightly toolchain to build librashader (from
@rasky)
- Unbreaks the build.
This PR has been tested and verified to build in a local branch, but to
be safe, it would probably be good to run it here as well.
Co-authored-by: jcm <[email protected]>
When we are synchronizing to audio and waiting for buffers to play back
before continuing in the emulation thread, the SDL and OpenAL audio
drivers currently wait inefficiently in tight loops that consume many
CPU cycles. This PR adds `usleep` calls to these loops.
In the case of the SDL driver, we sleep for ~~the time it takes one
quarter of our prescribed buffer size to play~~ precisely the amount of
time to play our queued audio that's in excess of our prescribed buffer
size.
For the OpenAL driver, it was more difficult for me to determine how to
see exactly how much time we should be waiting since the loop seems to
work slightly differently. One millisecond seemed reasonable given that
the minimum latency is 20 milliseconds, and was sufficient to introduce
significant savings without impacting performance.
Exactly how much CPU use this saves depends on a couple factors;
primarily, the host CPU and the guest core (more demanding cores will
spend a smaller share of time waiting in the audio driver). Reduction
seems independent of audio latency. Here are some sample figures for the
M1 Max:
SNES core (Super Mario World): 95-105% CPU use before, 40-50% CPU use
after with both OpenAL and SDL.
N64 core (Super Smash Bros): 100-110% CPU use before, 60-70% CPU use
after with both OpenAL and SDL.
(macOS's activity monitor measures activity as 'percent of one core',
hence the over-100% figures).
Less demanding cores and more powerful systems will benefit more from
this change, generally.
I tested this pretty thoroughly on my system to make sure that it did
not impact performance on even the lowest 10ms SDL latency on the most
demanding N64 core. However, other people putting this through its
paces, particularly on less powerful systems, would be a good idea, to
make sure that platform differences in `usleep` behavior don't have
unexpected results.
Co-authored-by: jcm <[email protected]>
DMAs on the GBA wait for two cycles before taking control of the bus.
While ares implements this behaviour, ticking these cycles before
running DMAs causes the DMA to run early in ares when the current call
to `CPU::step()` runs for a number of cycles equal to or greater than
the number of DMA wait cycles left.
This PR addresses the issue by ticking DMA wait cycles after running all
DMAs that are currently ready, fixing several timing test cases in the
mGBA test suite, and improving timings in the [Hades DMA start delay
tests](https://github.com/hades-emu/Hades-Tests/blob/master/source/dma-start-delay.c).
This PR accounts for using 16- or 32-bit accesses in the cartridge
backup region, which has an 8-bit bus, and accounts for reading from
said region when no SRAM or flash memory is present. Passes all of
[jsmolka's save
tests](https://github.com/jsmolka/gba-tests/tree/master/save).
Adds to the Metal backend from #1431, extending host VSync functionality
to variable refresh rate (VRR) displays, enabling the ability to sync to
guest and host refresh rates simultaneously, along with an assortment of
minor changes and code cleanups:
- Adds a threaded renderer option (technically a GCD queue) to the Metal
backend; essential for VRR at lower audio latencies. At higher audio
latencies, the synchronous rendering option may function better.
- Add easier debug capabilities, including a shell script to compile a
debug `.metallib` shader library which will be used at runtime if ares
is compiled in debug mode. The debug `.metallib` enables GPU frame
capture.
- Implement `clear()` for the Metal backend; the last displayed frame
will no longer stay on the screen if a core is explicitly unloaded.
- Implement fullscreen mode. Uses a borderless window that covers the
entire screen, rather than idiomatic fullscreen, primarily in order to
render around the camera housing. Normal macOS fullscreen behavior is
available via the main window title bar controls.
- Remove unused custom window code.
- Remove redundant copy of `Shaders.metal`.
- Miscellaneous small fixes and code cleanups to resolve compiler
warnings.
https://github.com/ares-emulator/ares/assets/6864788/1e2d594a-c84f-4b95-a792-cacdde2a09b0
## ares vs. VRR
As discussed in #1431, there are some challenges in implementing smooth
VRR support for ares on Metal. Briefly:
- ares lacked a mechanism to tell the display backend the core's desired
refresh rate, in order to sync to it.
- ares on macOS lacked an effective mechanism for receiving callbacks
when frames were presented, in order to keep track of whether we were
running fast or slow, because of the way ares monopolizes the main
thread on macOS.
The first issue has been resolved by a3c57b4 and ec0b625. Cores now tell
the `Screen` instance how often they want to present, and the screen
instance will tell the display backend if it implements the
`refreshRateHint` function. This enables the display backend to quickly
respond to changing guest refresh rates even during runtime.
The second issue is a bit trickier. As discussed, `MTKViewDelegate` and
`CAMetalDisplayLink` are both effectively unavailable until ares moves
its primary emulation work off of the main thread. There is, however,
one Metal callback mechanism that can still be used by ares;
[[MTLDrawable
addPresentedHandler:]](https://developer.apple.com/documentation/metal/mtldrawable/2806858-addpresentedhandler?language=objc),
because it calls back on a dedicated serial queue
(`com.apple.coreanimation.CAMachPortUtilReplyQueue`) rather than the
main thread.
Using this presented handler, ares can use `drawable.presentedTime` to
keep a running average of how long our frames are being presented for,
determine if we are running ahead or behind, and modify our subsequent
present intervals accordingly. That is what we do for this initial VRR
implementation.
## macOS VRR
> [!NOTE]
> The following applies to "ProMotion" displays, as those are the ones
most tightly integrated with macOS and most likely to be used by Mac
users on VRR displays.
Unfortunately, VRR sync is not as simple as just picking a present
interval and telling macOS to present each frame for the guest's
requested interval. macOS only pretends to offer this capability in
exclusive fullscreen mode, and even then, present intervals cannot be
completely arbitrary. Realistically, we seem to be able to get
consistent present intervals for some integer refresh rates between 40
Hz and 120 Hz, and certain rational present intervals (59.97, 23.976
among them). The spread of achievable consistent present intervals seems
to be arbitrary enough that there isn't any sense in targeting them
specifically. Even if we can theoretically present at the exact interval
the guest wants, we inevitably end up falling behind due to transient
load conditions.
> [!NOTE]
> For background, the landscape of guest refresh rates in ares is quite
wide. Many systems present near 60 Hz; 59.97, 60.01, 59.73, 59.92,
59.82, etc. Many of these systems have PAL modes that present near 50
with similar variations. The WonderSwan presents at a maximum of ~75.47
Hz, with per-game variations. The Atari 2600 can present at completely
arbitrary intervals during runtime owing to its CRT- and
processor-centric presentation strategies. In short, It is difficult to
narrow the range of expected guest present intervals if we wanted to
simplify this problem.
Rather, we have to pursue a more holistic strategy. The strategy ares
uses with this PR is as follows:
1. The output function sends frames into a FIFO dispatch queue that can
present asynchronously, to reduce the burden of needing to present
immediately if we are in danger of blocking the main thread.
2. If we are more than 0.5% off of the targeted present interval as
determined by a weighted rolling average, start "nudging" the system to
present at earlier intervals calculated according to the difference
between the rolling average and the target, multiplied by a constant
`kVRRCorrectiveForce`.
- This is done because we can often prod the system into presenting at
rational intervals close to the target interval, resulting in an overall
smoother presentation to the user than if we were to correct more
forcefully.
3. If more than `kVRRImmediatePresentThreshold = 3` frames are in the
queue to be presented, start telling the system to present immediately
instead of "nudging."
- This is a more forceful correction toward the target present interval,
and must be kept low for systems that want to present at intervals that
are far away from any achievable consistent present interval.
4. If the queue gets much deeper, `kMaxSourceBuffersInFlight = 6`, start
dropping frames.
- This is necessary for synchronizing to neither audio nor video, or
else in rare cases where the GPU is overloaded, such as for a shader
that the system is not capable of rendering in time each frame.
This system achieves decent results across most systems in my testing. I
considered allowing these constants to be twiddled with sliders, but was
wary of presenting too many esoteric options to the user. If it's
determined to be worth exposing these constants, that can be done in
future work (if a superior VRR presentation strategy entirely is not
discovered by that point).
## Miscellany
- The threaded renderer is necessary so that we do not ever block the
main thread in the worst case present interval conditions. However, it
only works well at relatively low audio latencies. At higher audio
latencies (as for users on lower-specced systems), the queue overflows
easily and it works better to render synchronously.
- The threaded renderer can also have unintuitive results when
exclusively syncing to host VSync or GPU sync, so for users that expect
particular behavior from that functionality, it is better left disabled.
- For PAL refresh intervals, players will get generally better results
in exclusive fullscreen. macOS likes to render things at 60Hz and will
struggle to render near 50 Hz with other elements onscreen.
- To view the present interval graph as in these debug shots, input
`defaults write -g MetalForceHudEnabled -bool YES` at the command line
before launching ares.
## Future Work
We could possibly achieve better VRR results utilizing something like
`CAMetalDisplayLink` after freeing up the macOS main thread. In my
testing it seems to have the same limitations in terms of achievable
consistent present intervals, but it may offer a more precise picture of
host vs. guest present timing.
Regardless of the viability of other strategies, it would still be
valuable to free up the main thread on macOS for the sake of other
system APIs that may be used in the future, plus benefits of being able
to use the UI consistently and smoothly concurrently with emulation.
N64 and PS1 also do not fully implement the `refreshRateHint` API, and
the API may be buggy for some platforms. Metal refresh rate hints
currently appear in stdout, so if you are seeing an issue with VRR sync,
check the console to see the guest's requested present interval first.
## Gallery
https://github.com/ares-emulator/ares/assets/6864788/1022c24b-fd83-4ede-b1ac-3f0c3a207972https://github.com/ares-emulator/ares/assets/6864788/7e36bd4a-7acd-4d37-a572-7550ba1ad2b2
(PAL Super Mario World)
https://github.com/ares-emulator/ares/assets/6864788/9655fcbe-28de-48b2-88b7-7fb864991ef0
Co-authored-by: jcm <[email protected]>
The 1MiB ROM chips used in most Famicom Mini carts and all Classic NES
series carts are mirrored, unlike with the larger ROM chips other carts
used. This PR implements the ROM mirroring behaviour and adds detection
for the affected games.
Closes#893
1. let the APU inherit the Thread
2. change the execution sequence of the apu and cpu
3. pass blargg_apu_2005.07.30/08.irq_timing.nes
4. pass blargg_apu_2005.07.30/09.reset_timing.nes
This fixes an issue where upon loading a game that doesn't use a controller pak after a game that does, a .pak file would be created using the previous games data.
There are a few ways to get mouse position: GCMouse and using NSEvent.
GCMouse is newer and better, it reports mouse movement in raw x/y deltas
which is exactly what we need. The issue is that it expects you to set
up handlers for the movement events , but I couldn't figure out a way to
do that with the existing `poll()` paradigm where it passes the device
into the function. Ideally I'd be able to do
`assign(HID::Mouse::GroupID::Axis, 0, deltaX);` directly in the event
handler.
The other advantage to GCMouse is that we can use
`CGAssociateMouseAndMouseCursorPosition` and then we don't have to worry
about moving the hidden cursor over built in UI (such as the dock).
This implementation uses regular NSEvent for mouse data which works
pretty well with the current poll() paradigm. I had difficulty handing
mouse centering/zeroing so I left it out. It works pretty well both full
screen and windowed but it is possible to accidentally click the dock.
Open to feedback so please let me know what you think! I'd love to get
GCMouse working.
Demo:
https://www.youtube.com/watch?v=UwPyVNWP5hM
Most systems will use an accurate refresh rate calculated from display timing
N64, PS1, PC-Engine and Neo Geo Pocket use 50hz and 60hz until we determine how to calculate.
This constitutes one puzzle piece that will help improve ares's frame
pacing, particularly for variable refresh rate displays.
While continued work on ares's audio drivers is likely to smooth the
pace at which ares generates video frames, transient changes in
application and system load inevitably means that frames will be
delivered earlier or later than expected. Additionally, relying on video
frames to be generated precisely when needed and presenting them
immediately is fairly demanding. If we can pace frames some distance in
advance, it can significantly lessen the burden on the CPU and GPU.
This PR is one tool to help the video backend deal with these issues.
Cores can now inform the screen of their expected rate of frame
generation at any given time, and the screen will inform the video
backend. The backend can then employ various strategies to perform
optimal frame pacing and drop frames when necessary.
The function is emphasized as a 'hint' to indicate that the rate is only
that which is expected, rather than certain. Unpredictable changes in
system conditions mean that we can never be entirely certain when a
frame will be generated or presented.
> [!NOTE]
> No concrete `refreshRateHint` implementations are added in this PR.
Given the variety of core refresh rates across ares, as well as the
consideration that for some cores refresh rates can change during
runtime, that work is left for separate PRs.
Co-authored-by: jcm <[email protected]>
detail:
1. Improve the emulational accuracy of apu framecounter
2. pass the apu_test/4-jitter.nes
todo:
1. Does apu need to emulate blocking_write_4017?
question:
1. A white screen will appear when running
blargg_apu_2005.07.30/04.clock_jitter.nes
Fix an error when cherry picking changes from a local branch for #1438.
Use the new variable for the base shaders directory when loading the
program start shader. Unbreak the build.
Co-authored-by: jcm <[email protected]>
Previously, the `LoadShaders()` function in `desktop-ui` searched only
two levels deep, which did not find all `.slangp` shader presets
available. The entirety of "megabezel" was not exposed, for example.
Now we properly traverse the entire directory structure of `Shaders/`
looking for `.slangp` files, exposing all that are available.
This PR does a small amount of rudimentary pruning for paths that do not
contain `.slangp` shaders, but future work, perhaps undertaken by
someone who has more fun with recursive directory traversal, should
probably properly prune all paths not containing presets.
Co-authored-by: jcm <[email protected]>
Based on [ototo2009's PCB
scans](http://blog-imgs-131-origin.fc2.com/o/t/o/ototo2009/WS-2019-12b.html),
I have verified that every single cartridge that uses the value `0x01`
for its save type in the ROM header actually comes with 256 Kbit (or 32
KB) of SRAM.
In addition, WonderSwan ROM chips tend to use the notation of
`MHxxMyySzzzz` for a cartridge with `xx` megabits of ROM, `yy` kilobits
of SRAM (or `yyE` for EEPROM), and the ROM data ID `zzzz`. All of the
cartridges in question appear to use `256S`.
As such, it seems to me that Ares should similarly emulate 32KB of save
data for all such cartridges. It seems that this actually fixes a game,
for once.
This PR adds a Metal display backend to ares.
<img width="1482" alt="Screenshot 2024-03-31 at 7 02 40 PM"
src="https://github.com/ares-emulator/ares/assets/6864788/48718f19-9916-491b-8301-c16b95f95c19">
*ares N64 core on a 60Hz P3 display. Shader: "crt-maximus-royale".*
## Context
With ares's recent introduction of librashader, ares users have enjoyed
access to the sizable library of shaders in the slang format, such as
those used by the RetroArch frontend. Simultaneously, up to now, the CGL
OpenGL backend shipped by ares for Mac users has offered enough
functionality to do the (relatively) simple job of an ares display
backend; display software-rendered frame buffers and pace them
appropriately.
librashader's advanced postprocessing, however, has asked a bit more of
the display backend, and in the case of OpenGL, has laid bare various
deficiencies in macOS's OpenGL driver. These deficiencies can kneecap
ares's librashader support on macOS with compiler errors and broken
shader behavior.
Rather than chase down these errors and try to work around what is
fundamentally a broken driver shipped by Apple, we take advantage of
librashader's native Metal support by adding a Metal backend to ares.
This greatly increases baseline shader compatibility, with the added
benefit of documentation and greater platform debugging information when
issues arise. The Metal backend will also generally future-proof ares on
macOS, with OpenGL's uncertain future on macOS.
## Basics
The first iteration of this Metal driver mostly offers feature parity
with the OpenGL driver. More advanced features, particularly in the
realm of frame pacing on ProMotion displays, will arrive in future
iterations. The priority with this PR is to start getting the driver in
the hands of users with basic features and greater librashader
compatibility.
Host refresh rate sync is still a work in progress and in this iteration
will only be enabled for users above 10.15.4 on non-VRR displays
(discussed more below).
Explicit sRGB color matching is offered as a new option for those on
wide gamut displays (by default, the Metal driver will map to the native
color space, conforming to OpenGL driver behavior). This option is only
exposed on macOS, since other operating systems lack per-surface color
matching.
<img width="400" alt="Screenshot 2024-03-31 at 6 37 38 PM"
src="https://github.com/ares-emulator/ares/assets/6864788/e177a256-bba2-4a02-ad5b-9ad84cb09740">
<img width="400" alt="Screenshot 2024-03-31 at 6 37 46 PM"
src="https://github.com/ares-emulator/ares/assets/6864788/dd517394-e97e-40f6-98de-4562d62bda98">
*Left: ares presenting in Display P3. Right: ares presenting more
accurately in sRGB with "Force sRGB" enabled. Shader: crt-hyllian.*
A simple vertex and fragment shader are compiled at runtime, so we avoid
the need to add another compiler toolchain to the ares build process.
There is unfortunately some code duplicated at present; `metal.cpp` and
`Shaders.metal` both include types defined in `ShaderTypes.h`, but we
also need to place `Shaders.metal` inside the .app bundle for runtime
compilation, making for awkward `#include`s. Presently, we just bundle a
copy of `Shaders.metal` appended with `ShaderTypes.h`, inside
`desktop-ui/resource`. This will be cleaned up in future work.
The driver's draw implementation itself is fairly simple; one render
pass renders to an offscreen texture, librashader performs its work on
that offscreen texture, and a second ares Metal render pass composites
the finished texture inside ares's viewport. Since we do not use
`MTKViewDelegate`, our output function finishes with a `[view draw]`
call and the system presents at the earliest opportunity.
## Details
When it came to the details of implementing this driver, there were some
nontrivial issues encountered. Some of these will need solving in
separate PRs before this driver is feature-complete.
### ares vs. VRR
Users on fixed refresh rate displays should enjoy good frame pacing with
this driver. Unfortunately, users of more recent Mac machines with
"ProMotion" refresh rates will not have an ideal experience in terms of
pacing. To understand why, we need to take a brief detour into how ares
works and then discuss some current limitations with ares's macOS
integration.
In ares "synchronize to audio" mode, ares creates and delivers video
frames as audio frames are created. This means that the video frame
timing is completely dependent on when exactly the audio driver
processes audio frames. For display modes with a refresh rate at or
close to the core refresh rate, this is mostly no problem; the system
seems to naturally present frames in a FIFO-esque fashion, and every
once in awhile the system will just drop or duplicate a frame if two or
no draw calls fall within one refresh interval.
For recent more advanced Mac displays with "up to 120Hz" refresh rate,
the story is more complicated. We have to explicitly tell the system
when we want it to draw the frame once available. It is tempting to
answer "now"; after all, if our audio timings are correct, then video
frames should be generated precisely when they need to be shown.
Unfortunately, in higher latency modes of OpenAL or with SDL audio in
general on macOS, audio frames are processed in large batches. That
means that we end up emitting several video frames in quick succession
at 8ms intervals on a 120Hz display, then waiting as long as 75ms for a
new batch of audio (and thus video) frames:
<img width="265" alt="Screenshot 2024-03-31 at 4 55 25 PM"
src="https://github.com/ares-emulator/ares/assets/6864788/69f887a0-8ded-4f47-ac4c-4cf2b58283a7">
<img width="265" alt="Screenshot 2024-03-31 at 4 55 35 PM"
src="https://github.com/ares-emulator/ares/assets/6864788/2f7a417a-0378-44b5-b0c0-f894542c0371">
<img width="265" alt="Screenshot 2024-03-31 at 4 55 56 PM"
src="https://github.com/ares-emulator/ares/assets/6864788/13b471d9-3e77-45cd-baf4-0d786ae83e22">
*VRR macOS frame pacing across audio driver settings in v0.1 of the
Metal driver. The graph in blue shows frame present intervals over time;
the values in red show the minimum and maximum present intervals over
the graph duration.*
If we do not answer "now," we have to decide when to present.
Unfortunately, currently, there is not a satisfying way to answer that
question. Core refresh rates vary somewhat widely, sometimes during
runtime, and there is no mechanism in ares by which to inform the
graphics driver of a core's desired refresh rate.
We could elect to just duplicate the behavior for a fixed display
refresh rate and pick, e.g. 60 Hz, but unfortunately even that option is
not available, because we currently have no way of receiving callbacks
when a frame is actually presented. Why not `CAMetalDisplayLink` or even
`MTKViewDelegate` you ask? Well...
### ares vs. macOS
For most of its cores, ares performs much of its work on a single
dedicated main thread that blocks for audio and video presentation to
drive hardware-accurate timing. Unfortunately, all of this work occurs
on the macOS main thread, with lots of blocking and CPU-intensive
activity. This interferes with the macOS application run loop's ability
to perform its callbacks and call out to observers.
In practice, this means that if we try to employ delegates that
interface with macOS, that could send a callback when a frame is
presented, or tell ares the exact moment a frame needs to be presented,
these system delegates cannot actually make these calls in time in
between ares's main thread activity; upwards of 50% of `MTKViewDelegate`
callbacks are lost, for example.
This means that tools like `MTKViewDelegate` or `CAMetalDisplayLink`
that would help us solve the frame pacing problem are, unfortunately,
useless to us. We cannot leverage these tools as ares is currently
architected.
To get around these issues, we will need one of: less main thread
blocking, so delegates can interface with ares on the main thread, or an
audio driver with a processing tolerance that falls within the display's
minimum refresh interval. Our best bet for now is to emit frames to the
system within ares's main thread work as they come available, let the
system draw them as it will, and hope that our audio driver is doing a
good job pacing them.
In practice, for Metal driver users on VRR displays you cannot set to a
fixed rate, this means you should use the OpenAL driver, and set the
latency to the lowest value possible.
## Future Work
The future for the Metal driver in ares takes us down a few different
paths.
The main issue at present is making macOS system delegates work well
with ares, which is the ideal path forward. Ideally, we could move all
of the emulation-intensive work off of the main thread in macOS and into
a high priority dedicated thread, reserving the main thread for actual
UI and rendering, giving the system plenty of overhead with which to
communicate.
For the future of VRR in ares, it would be good to create a mechanism to
tell the graphics driver what refresh rate the core wants to present at.
This would be one way to pace draw calls appropriately in the absence of
reliable feedback from the system about the state of the display.
It has gone without mentioning so far due to the other issues, but long
term, it would also be good for ares or librashader to have some way of
utilizing the entire viewport for shaders; currently, shaders are
limited to the output width and height area rather than the entire
window view size. This is limiting for "bezel"-style shaders that want
to use the entire screen in fullscreen, for example.
Co-authored-by: jcm <[email protected]>
5c598c2df3 Merge pull request #115 from notaz/gitignore
4cbba6df03 add a basic .gitignore
7239eab39c Merge pull request #114 from bslenul/windows-case-include
e2589a612c Make sure all windows.h includes are lowercase
git-subtree-dir: thirdparty/libchdr
git-subtree-split: 5c598c2df3a7717552a76410d79f5af01ff51b1d
e8ffd8fdf3 chore: Release
d893b6ec97 doc: update supported runtime table to include D3D9 and clarify wgpu status
8c8e386a6c capi(d3d9): expose d3d9 in capi
b7071958bd rt(d3d9): add a runtime for direct3d 9
5feac91af2 runtime: add ARGB8 pixel format
9c895caa51 wgpu: fix format mismatch for copies
7593f9f9b5 rt: pass device context to uniform binder if needed
af3ea252ba rt(d3d11): split luts out to own module
9dc0cf26fd chore: Release
2550bf7ed5 test: update shaders_slang
35fc21bbef capi: fix mtl noop free fn name
89b620a7c1 rt(gl46): fix invalid framebuffer copies
66a0ee21e3 Revert "rt(gl): account for flipped coordinate space when blitting to output"
31b7a6f33f chore: Release
ed7216990a test: update slang_shaders
623c6776f7 rt(gl): account for flipped coordinate space when blitting to output
bacfbf0791 cache: delete cache if corrupted
e02e1ae26a rt(gl): load luts with topleft origin due to MVP changes
d72519b9fd chore: Release
752417f320 rt(vk): switch from an rwlock to a mutex for allocator
10ad2d927c rt(d3d12): make descriptor heap lockfree
8a9adebb96 rt(d3d12): upgrade to windows 0.52
7719b939f9 rt(d3d11): upgrade to windows 0.52
a849f5e745 dep: unify on windows 0.52.0
f61bed3a22 vk: remove unneeded device arcs
git-subtree-dir: thirdparty/librashader
git-subtree-split: e8ffd8fdf31f29e35f0c367ef2c3c40c19088971
Resubmission of https://github.com/ares-emulator/ares/pull/1389 with
improvements.
Now the SDL build script will not call `xcode-select`, which can have
undesired effects on the user build environment, unless it is on CI
(detected with the `$GITHUB_ACTIONS` env var).
It will also not call ``cmake --install .``, which would previously
replace the user's SDL installation.
This second change required some minor changes to ruby's makefile. We
now include the header directory from the cloned SDL source, and inform
the linker correctly of the location of the SDL .dylib.
Also added the cloned SDL repository and .dylib to the .gitignore for
easier development workflow.
To ensure compatibility with
https://github.com/ares-emulator/ares/pull/1390, the
`MACOS_COMPILED_SDL` flag is added so we can include the proper "SDL.h"
header for compiled builds and `<SDL2/SDL.h>` header for system builds.
Co-authored-by: jcm <[email protected]>
When an instruction is already present in the prefetch buffer, fetching
the instruction should take only one cycle in both ARM and Thumb modes.
Currently, ares uses 1 cycle for each halfword read from the prefetch
buffer, which is correct for Thumb but not ARM. Fixing this discrepancy
allows ares to pass 1890/2020 of the timing tests in the mGBA test suite
(up from 1760/2020).
Exposes the option to use SDL's audio backend on macOS. The wiring for
this is already fully present, just needs to be added to builds.
Good to have another option for Mac audio for anyone having issues with
the OpenAL backend.
Tested locally and verified to work in the Metal dev branch.
Co-authored-by: jcm <[email protected]>
Addresses a minor issue with driver change confirmation logic and the
"Apply" button in the UI.
Previously, if the player changed the video, audio, or input driver with
a title loaded and clicked "No" at the confirmation dialog, the "Apply"
button would be disabled as if the player had changed the driver, when
they had not.
With this PR the "Apply" button state correctly reflects the driver
state and the result of the confirmation modal.
Co-authored-by: jcm <[email protected]>
* Significantly improved Hyper Voice implementation accuracy (verified,
at least for Sound DMA writes, with a test ROM)
* Implemented emulation of unused/undocumented debug ports (0x64-0x67,
0x69, 0x95-0x9B)
* Improved cycle accuracy of APU channel handling
* Added slightly faster "inaccurate" APU emulation mode (for most games,
output should be essentially identical; debug ports will not match up,
though)
For some reason, on macOS, debug symbols do not seem to be available for
lldb if link-time optimization is enabled. I do not know exactly why
that's the case, but it seems safe and without downsides to just disable
LTO if we're doing a debug build.
Co-authored-by: jcm <[email protected]>
Use the Games Express system card for the games that require it
Use System Card 1.0 for Altered Beast (this game is broken on other bios versions, even on hardwar
Fix CD-ROM pregap offset (Fixes Super Air Zonk, allows Games Express games to boot)
Fix PC-Engine Duo/Super CD-ROM Ram Enable Register
e)
This PR adjusts PPU timings as follows:
- There is a 46-cycle wait period between the start of a scanline and
the first pixel drawn, instead of a 32-cycle period between clearing
io.hblank and incrementing io.vcounter
- io.hblank is set for 226 cycles instead of 240
- Video capture DMAs occur on scanlines 2-161, instead of scanlines
0-159
These changes can be observed in
[status-irq-dma.gba](https://github.com/nba-emu/hw-test/tree/master/ppu/status-irq-dma).
When using the accuracy profile, ares now gets within 5 cycles of the
correct value for all tests except video capture DMA.
Fixes CI failing to build after #1412.
`clipsToBounds` is available as far back as 10.9 but not exposed until
14.0, so we have to expose it manually if we're building on an earlier
SDK.
In future, ares should of course be built with the current SDK, but
should support building with earlier SDKs.
Co-authored-by: jcm <[email protected]>
### Status Bar
When building with the macOS SDK included with macOS Sonoma, ares has
had a regression involving an overly large status bar that rendered over
the game viewport, causing confusion as well as being tricky to debug.
It turns out that this was due to a breaking change in AppKit in macOS
14 where an `NSView`'s `dirtyRect` was no longer clipped to its bounds
by default. In short, a view's `dirtyRect` is now often much larger than
its `bounds` if `clipsToBounds` is not defined explicitly. This creates
problems in views that draw by calling `NSFillRect` on the dirtyRect, a
common pattern, as it will fill a rect that is much larger than the
actual bounds.
This PR sets the `clipsToBounds` property for NSView to `true` for views
in ares that draw by filling `dirtyRect`. Accordingly these views'
`dirtyRect` will now always be the same size as their `bounds`.
This was true of `canvas.cpp`, `viewport.cpp`, and `label.cpp`. To avoid
making the change overly broad, and to enable macOS to perform whatever
optimizations it wants to perform, other view types are left alone.
### Splash Screen
This PR also addresses logo clipping issues in macOS on the splash
screen. The dimensions for the logo on the splash screen, as defined,
seemed to be a bit off previously, with the square logo rendering into a
non-square canvas area. For whatever reason, this only clipped the logo
rendering on macOS. The size and padding are adjusted slightly by this
PR. It should not result in regressions on other platforms, but should
be tested to make sure.
> [!IMPORTANT]
> Pwease test on Windows and Linux to make sure the splash screen looks
OK.
macOS screenshot of adjusted splash screen and fixed status bar, built
with Xcode 15:
<img width="1072" alt="Screenshot 2024-03-02 at 1 43 20 AM"
src="https://github.com/ares-emulator/ares/assets/6864788/83504592-03dd-4881-8f3d-0db1fb771f44">
---------
Co-authored-by: jcm <[email protected]>
This PR is a change to pass the [SA-1 RAM protection
test](https://github.com/absindx/SNES-TestRoms/tree/main/SA1RamProtectionTest).
---
242e2fd1a1
BW-RAM protection was not implemented to make Kirby's Dream Land 3 work.
[Reference: Near's post
(nesdev)](https://forums.nesdev.org/viewtopic.php?p=237733#p237733)
This commit implements the conditions under which BW-RAM protection
works as determined from hardware testing.
* BW-RAM Protection will not be reflected unless protection is enabled
on both SNES and SA-1.
* KDL3 sets `CWEN=0`, but `SWEN=80`. not protected.
* `$2228 BWPA` is a register for the SNES CPU, but it also affects the
SA-1 protection area.
---
654f5f02ce
Change the BW-RAM mapping range from $400000-$4FFFFF to $400000-$5FFFFF.
[Reference: SA-1 Hardware Behavior -
SnesLab](https://sneslab.net/wiki/SA-1_Hardware_Behavior#BW-RAM)
---
aa1da58d8b
Initialize the following at SA-1 reset. (change `$2200 CCNT.RESB` 1 to
0)
* CPU data bank register
* CPU stop flag
* IO `$222A CIWP` register
NOTE: The timing of when these registers are reset is unknown because
they cannot be observed in a stopped SA-1 CPU.
I include todo as a reminder that there are many unknown behaviors. I'll
delete it if it's not needed.
KDL3 restarts the SA-1 CPU several times on the title screen.
Before this change, KDL3(JPN: Hoshi no Kirby 3, SHA-1:
`5038596a1ec450d8f1d7cc07759737bfd996e87f`) was not restarting properly:
```log
SA1 008294 sei A:0000 X:0000 Y:0000 S:01ff D:0000 B:00 nv1BdIzc
SA1 008295 clc A:0000 X:0000 Y:0000 S:01ff D:0000 B:00 nv1BdIzc
SA1 008296 xce A:0000 X:0000 Y:0000 S:01ff D:0000 B:00 nv1BdIzc
# (snip)
SA1 0082b1 lda #$ff A:0000 X:0000 Y:0000 S:01ff D:0000 B:00 nvMXdIZC
SA1 0082b3 sta $222a [00222a] A:00ff X:0000 Y:0000 S:01ff D:0000 B:00 NvMXdIzC # B:00 ... write to CIWP
# (snip)
SA1 0082cf pea $4040 [004040] A:3600 X:37ff Y:3800 S:37ff D:3600 B:00 nvmxdIzC
SA1 0082d2 plb A:3600 X:37ff Y:3800 S:37fd D:3600 B:00 nvmxdIzC
SA1 0082d3 plb A:3600 X:37ff Y:3800 S:37fe D:3600 B:40 nvmxdIzC
# (snip)
[Omitted: 3303247]
# reboot from SNES CPU (CCNT.RESB)
SA1 008294 sei A:0000 X:37ff Y:3800 S:37ff D:3600 B:40 nvmxdIZC
SA1 008295 clc A:0000 X:37ff Y:3800 S:37ff D:3600 B:40 nvmxdIZC
SA1 008296 xce A:0000 X:37ff Y:3800 S:37ff D:3600 B:40 nvmxdIZc
SA1 008297 sep #$20 A:0000 X:37ff Y:3800 S:37ff D:3600 B:40 nvmxdIZc
# (snip)
SA1 0082b1 lda #$ff A:0000 X:37ff Y:3800 S:37ff D:3600 B:40 nvMxdIZc
SA1 0082b3 sta $222a [40222a] A:00ff X:37ff Y:3800 S:37ff D:3600 B:40 NvMxdIzc # B:40 ... write to incorrect address ($40222a = BW-RAM)
```
The data bank register `B` has not been reset and an access to a
different address is occurring.
Although not related to BW-RAM protection, other registers probably need
to be reset as well.
Further hardware testing is required.
---
These commits boot KDL3 with BW-RAM protection implemented.
2a1119c68 Merge pull request #113 from scribam/ci-switch-vita
51bd8e969 Add GitHub Actions for Switch and Vita
bd19fbd6f Merge pull request #110 from scribam/zlib-1.3
577f3276c Merge pull request #111 from scribam/c90
5f04e2fdf Merge pull request #109 from scribam/actions-checkout
16ebde42b Merge pull request #112 from scribam/dr_libs
647f42b27 dr_flac: Version 0.12.42
5fd516519 Compilation fix when using C90 with GCC
ea2da72d3 Bump zlib to 1.3.1
4e0aa45a7 Update actions/checkout to v4
git-subtree-dir: thirdparty/libchdr
git-subtree-split: 2a1119c686eb07033d02f8c6d12406f8fd373775
5420f8bee Update README
5c0a2c232 Support recent changes on s390x
ebe11bab4 Support target address for mov_addr operations
a5503d6dd Merge jumps and put_labels
b6b79d5c2 Remove JUMP_LABEL flag
e453c820e Refactor serial numbers of tests (#233)
f63755091 Improve sljit_generate_code on several cpus
9ee290982 Improve code generation on s390x
git-subtree-dir: thirdparty/sljit
git-subtree-split: 5420f8bee8f954fa11c72e4402bb1b9b32a2b11f
Ares checked each of the two input arguments to three-ops functions
separately, but this is not correct. Conditions causing unimplemented
operation on either input (sNAN, subnormal) take precedence on
conditions causing invalid operation on either input (qNAN).
After this fix, Ares passes n64-systemtest COP1 stress test.
Adds a cheat editor to Tools->Cheats when a game is loaded.
The cheat editor should work for all systems except N64 and PS1: support for these will come later.
The code has currently only been tested for MS, MD and SFC but it is assumed all the other systems are also functioning; the code paths are the same.
Code format is standard patch codes in the format X:Y where X is a memory address and Y is a value to place there; most emulators also support this format.
You can use multiple codes in a single cheat by separating codes with a + sign.
Cheats that require memory comparisons are not currently supported, only replacements
Cheats are saved alongside the roms, eg "Game.sfc" will create "Game.cheats.bml".
607158516 Improve serialize interface
dd73cb873 Implement serialization interface
5d2d7cd59 Improve PPC branch support
8b8b6b442 Improve ARM32 branch support
2cfed9ce4 Improve x86, ARM-T2 branch support
6c75e773c Improve riscv branch support
dfeb8cf68 Add extraction macros for operands
dc52b334e Fix typo (#229)
7a821cd71 Add LoongArch float to integer conversion special cases (#226)
cbde0bea6 regex: allow building with a C++ compiler (#224)
40680870e Fix masked shift on arm32
a0643952a Fix sljit_get_register_index on x86-32
80bdff333 Support temporary registers in sljit_get_register_index
4629814f8 riscv: fix getput_arg and load_addr_to_reg (#223)
a26427a6e define float to integer conversion special cases
42128180d build: make code mostly ANSI C89 compatible (#221)
57c212f58 loongarch: fix FTBFS when building pcre2test as part of PCRE2 (#220)
3faacd431 Optimize certain fop1 operations on x86
4f33321c1 Move float/call/simd tests to separate files
230429241 Add another temp register on s390x
fbf9c47f3 Support access to temporary registers
8c5c50463 Implement simd on s390x
02e76fb14 s390x: fix FTBFS with clang (#219)
0bd5147fc Implement simd2 operations
git-subtree-dir: thirdparty/sljit
git-subtree-split: 6071585164d9a38a8890cfd2722ca9d8492528bb
Not required anymore, possibly for a long time. IPL3 does that, plus
this creates correctness issues with open source IPL3 which *doesn't*
initialize those memory locations.
Addresses a few cases where the current horizontal sprite mosaic
implementation is incorrect:
- Transparent pixels should be affected by horizontal sprite mosaic
effects
- If the latched pixel does not have the sprite mosaic effect enabled,
the next pixel should always be latched
- Mosaic offset should not be reset to 0 at the start of a new
horizontal mosaic effect
Accounting for these cases improves visual accuracy of sprite mosaic
effects. This is easily visible in test cases such as
[sprite-hmosaic.gba](https://github.com/nba-emu/hw-test/tree/master/ppu/sprite-hmosaic),
and [Tonc's mosaic demo](https://www.coranac.com/projects/#tonc)
(mos_demo.gba, from tonc-bin.zip v1.4.2).
I've lately discovered that misaligned PI DMA is also affected by RDRAM
writes that must cross RDRAM row boundaries (2048 bytes). It is obvious
in retrospect that the DMA implementation cannot generate a write burst
across different rows, so its internal buffering must be segmented on
RDRAM row boundaries.
The PI DMA testsuite has been updated to cover this edge case as well:
https://github.com/rasky/n64_pi_dma_test
Ares now passes the updated testsuite in full (timing aside, which is
close but not perfect).
This updates most pre-32bit systems to have hardware accurate borders and
aspect ratio where known, reasonable estimates are used where not known.
This also means that PAL games will use the correct PAL aspect rather than
using the NTSC pixel aspect ratio.
All TMS9918 VDP based consoles are thought to be be correct, as are Master
System, Mega Drive, and NES, while SNES and PC-Engine are (educated)
estimates.
The overscan option has been reworked to crop all non-desirable edges of the
screen, including borders and areas that often contain garbage data, previously
this option only cropped the bottom 16 lines of active display.
The reworked overscan is not yet implemented for Atari 2600, PC-Engine, N64 or
PlayStation.
According to NanoBoyAdvance author fleroviux, the prefetch buffer should
be reset on any ROM accesses from the CPU or DMA. This PR implements
this behaviour for CPU ROM accesses. This allows ares to pass 1760/2020
of the timing tests in the mGBA test suite (up from 1608/2020).
Allowing DMA ROM accesses to clear the prefetch buffer seems to worsen
timings at the moment, possibly due to some other timing issues that
also come into effect in these situations. I've left comments to make a
note of the issue, so that resetting the prefetch buffer on ROM accesses
from DMA can be implemented once it becomes beneficial to do so.
The readme references `libsdl2-0.0` which does not exist:
https://packages.ubuntu.com/search?suite=default§ion=all&arch=any&keywords=libsdl2-0.0&searchon=names
I'm not sure it's even useful mentioning `libsdl2-2.0-0` since
`libsdl2-dev` depends on it. Maybe for distributing ares you would then
know people have to install `libsdl2-2.0-0` I guess
Also added a note that SDL2 input allows using a controller on *nix as I
haven't seen that documented anywhere
And I fixed a random makefile indentation issue that messed with my
head.
* Fix the firmware search path not being saved or loaded from the
settings file.
* Fix `FirmwareSettings::findFirmware` not using the right casing when
locating the firmware directory.
Contains three main changes:
* In `Path::program()`, account for the macOS app bundle, so that
portable config support works with the app bundle.
* Create a new function `Path::resources()` for the resources path,
since `Path::program()` can no longer trivially be used to construct the
bundle resources path (no guarantee what the .app is named). On macOS
this returns the path to "ares.app/Contents/Resources", on other
platforms (in case they use it in the future) it just returns the same
as `Path::program()`.
* Fix an issue where, if Ares is stored in a sub-directory of the
desktop, the path settings UI will display paths next to the program as
relative to the desktop instead of relative to the program directory.
When performing a DMA with source and destination addresses both in
cartridge memory, the first write should use sequential access timings.
Implementing this in ares gives more accurate timings for ROM to ROM
DMAs than the previous approach, which instead removed the 2-cycle DMA
starting delay in these cases.
ISViewer is currently gated by the homebrew mode flag. It seems like
this is not ideal for rom hackers because they would still need a way to
log but homebrew mode is too verbose for them and hide the ISViewer
messages in streams of actual problems in game code that they don't
intend to fix. So restore ISViewer functionality without homebrew mode.
This closes the socket server after each successful connection so that
new connections are immediately refused. Before, given that the server
socket was always in listen mode, one additional connection could always
be estabilished at the TCP level, even though the server wouldn't accept
it right away.
Currently, when a client disconnects, the server in Ares fails to notice
and to call the onDisconnect hook, which in turns cause the server to
stop responding (it won't accept a new client, and will never receive
more data from the disconnected one).
This commit fixes it by correctly handling the recv() return code to
detect peer disconnections (return value 0) and any other kind of error
(return value < 0).
Commercial GBA games contain strings in the ROM that correspond to a
save type (e.g. SRAM, flash memory, EEPROM), followed by 3 digits. These
strings are used by ares to detect what save type to use. However, when
running [jsmolka's SRAM and flash memory save
tests](https://github.com/jsmolka/gba-tests/tree/master/save), ares does
not detect a save type, since the programs lack the 3 digits at the end
of the save type string. This PR ignores the trailing digits during save
type detection, since it's likely that many other homebrew programs are
affected by the same issue ([GBATEK even advises developers to not add
digits when including save type
strings](https://problemkaputt.de/gbatek-gba-cart-backup-ids.htm)).
Depending on which cycle they read values from registers, instructions
will read a different PC value. This is handled in ares by adding an
offset to the program counter (r15) value in affected cases. This PR
applies the offset in a few instructions that are affected by this
behaviour, but were previously not covered.
ARM and Thumb mode variants of the ldmia and stmia instructions use a
shared pattern of sequential and nonsequential memory accesses. The
correct pattern was already implemented in ARM mode, and this PR applies
the same pattern to Thumb mode, making the timings of these instructions
more accurate.
### Description
Adds SDL (properly) to Mac builds.
This time, it has been added as a fully fledged optional dependency in
`thirdparty`, à la MoltenVK, and built from source before ares. We build
from source because brew installations are both single-architecture and
not fully portable.
The .dylib is copied inside the app bundle when linking, at the same
stage as MoltenVK.
The initialization of `ares.dylibs` has been moved from ares's Makefile
to the `desktop-ui` Makefile so that it's initialized when building
ruby, which it wasn't previously.
The SDL build is also added to CI, with the same caching methods as used
for MVK.
### Relevant Details
`HEAD` points at SDL 2.28.5 currently, which is the most recent stable
release. This should probably be periodically incremented as
appropriate.
~~SDL is currently built with the macOS deployment target of 10.13.
While SDL's minimum supported macOS version is 10.11, ares CI is using
Xcode 14.2, which has a minimum deployment target of 10.13. I am
currently testing to see if I can get the deployment target lower
without breaking other parts of ares's CI.~~ resolved, per below; SDL
supporting 10.11 is built + bundled.
### Testing
This has been tested to build properly locally and via GitHub CI. The
.dylib is packaged inside the bundle correctly and SDL functions
correctly in my testing, even if the user does not have SDL installed
elsewhere on their system.
This is seeking tests from other Mac users, especially on older
operating systems, to verify that SDL works correctly there.
Co-authored-by: jcm <[email protected]>
Added the minimum macOS version key, but kept it at 10.9 which is what
macOS currently reports it as.
Now that the key is here, it will be easier to update it in the future.
Also added the copyright line attributing the ares team and
contributors.
Some issues I noticed while playing with this on macOS. Took a bit of a
deep dive and attempted to fix them up:
- changing the tracer settings did not seem to change what was logged.
seems to be the row isn't selected when the `onToggle` callback is
called. solution was to instead use the toggled `cell` to get the row
its in. this caused some C++ template issues but removing the `auto`
fixes them all (the alternative being adding `template` to a few method
calls, I should add I'm not a C++ programmer so from my limited
understanding this was the best solution)
- text in text fields were invisible. this was due to
`setForegroundColor` in the macOS backend not properly handling a
0,0,0,0 color. changed to perform the ternary on the `Color` rather than
the `NSColor` (`SystemColor` did not support the ternary)
merry christmas :)
Currently, the n64 core is limited to ROMs whose size is 63.9375 MiB
(also known as 64 MiB - 64 KiB). The reason is twofold: first, only 64
MiB are actually mapped in the PI bus; second, the last 64 KiB are
shadowed by the ISViewer debugging device.
ISViewer addresses sit in the last 64 KiB of the 64th MiB, so when the
ROM is larger than that (for instance, it is exactly 64 MiB), we should
simply disable ISViewer. In the long run, there will be a better
debugging solution which doesn't sit in the PI address space anyway.
Moreover, N64 supports basically ROM of unlimited size, there is no 64
MiB limit. This commit also allows that by simply mapping the whole ROM
into the PI address bus, whatever the actual size is.
When doing PIF HLE emulation, we run the HLE state machine just once per
frame. This is OK in general, but there can be a few situations where
this can cause PIF to miss one command from CPU. For instance, a ROM
might send the PIF boot termination command (0x8) and then shortly after
issue a SI DMA to identify controllers. If the two happen within the
same frame, our HLE emulation would miss the boot termination command.
This commit updates the HLE state machine also after each write to PIF
RAM.
Originally found by vmicka72, so credits to them. Documented as issue:
https://github.com/ares-emulator/ares/issues/1275 and confirmed by
TascoDLX.
Since it is easy and straightforward, no sense in letting it hang
around.
Some unmapped I/O registers on the GBA always return 0 when read. This
pull request implements the required behaviour on six registers that
previously used open bus behaviour instead, allowing ares to pass all
remaining I/O read tests in the mGBA test suite.
Added "Xin1" mapper for the ColecoVision, this mapper supports:
- 31-in-1 (v1.1) ( 2013 )
- 63-in-1 (v1.0) ( 2013/0 1)
Both carts are by "Buzz and ZX-81", and i tested all games for both
multis and they all at least boot perfectly fine
And the "MegaCart" mapper, this mapper automaticly triggers for any rom
over 32k that isnt known to be another mapper (like the "xin1" mapper).
it all should be well with all homebrew games that requite the MegaCart
hardware.
If anyone knows of any other ColecoVision carts like these let me know
and I'll try to add them.
---------
Co-authored-by: Luke Usher <[email protected]>
General fixes:
- model data lines separately from output data latches
- update data lines after control register writes
- distinguish between driven and floating data lines
- remove redundant data latch state from devices
- separate host input polling from data line synthesis
6 button/fighting pad fixes:
- reset timeout only on TH 0->1 transitions
- remain in last phase until timeout (don't wrap)
- read back C/B button state along with M/X/Y/Z
Mega mouse:
- remove erroneous thread synchronize on attach which could crash ares
Affected titles:
- Decap Attack (MD)
- Trouble Shooter/Battle Mania (MD)
- WWF Raw (32X)
### Description
Up to this point, SDL as an input library has not been present in macOS
builds. The plumbing was already in place for macOS to make use of SDL,
but SDL was not actually linked. This PR rectifies that. Seemingly
unnecessary references to the IOKit joypad are also removed from
`sdl.cpp`.
To facilitate adding SDL to ruby for macOS, a stubbed out macOS mouse
driver, `gcmouse.cpp`, has been added, to avoid needing to make numerous
modifications to `sdl.cpp` to work around mouse-related code.
### Motivation
The legacy macOS input uses raw values from IOKit, which are not
available for all supported controllers, and where present, are
uncalibrated and generally not ideal. SDL's input support is much more
advanced comparatively, properly handling and interpolating input from a
wide variety of controllers where raw IOKit input values aren't
sufficient. This should resolve a number of situations where ares won't
recognize input from controllers connected to macOS machines, among
other macOS input-related issues.
### Discussion
I am not super well-acquainted with ares's code and build system, and
it's entirely probable that I missed something here or went about this
not-quite-correctly; I did so as straightforwardly as possible and may
have missed something, for example fallbacks if SDL is not present at
build-time; I am not sure if this is currently handled. I encourage any
and all edits from maintainers if I broke something or went about
something incorrectly.
### Testing?
Tested locally on my Apple Silicon machine on macOS Sonoma. SDL can now
be selected and used successfully as an input driver for all supported
connected controllers.
Co-authored-by: jcm <[email protected]>
As a bonus, use the Unicode ellipsis character in the ares UI on all
platforms instead of just macOS. In addition to looking nicer, it will
make regressions in this area very obvious.
Allow ares to be more easily built against external dependencies on
Windows outside of MSYS2 and using the MSVC ABI.
For example, dependencies can now acquired via vcpkg by installing the
relevant packages (pkgconf, gtk3, qt5, sdl2) and setting up the
environment appropriately before building.
```
CMD:
set PKG_CONFIG=C:\src\vcpkg\installed\x64-windows\tools\pkgconf\pkgconf.exe
set PKG_CONFIG_PATH=C:\src\vcpkg\installed\x64-windows\lib\pkgconfig
Bash:
export PKG_CONFIG=/c/src/vcpkg/installed/x64-windows/tools/pkgconf/pkgconf.exe
export PKG_CONFIG_PATH=/c/src/vcpkg/installed/x64-windows/lib/pkgconfig
```
Changes:
- hiro: fix building against gtk/qt with cl
- build: improve pkg-config detection and use with cl
- nall: support dynamic crt with clang-msvc/cl
Doom Resurrection patch version 3.0 (currently at version 3.1) added
support for the Mega Mouse, as well as making use of Mega CD hardware if
available. When I added mouse support for the Mega CD, the patch for
Doom Resurrection was at version 2.2, and since there was no licensed
32X software that supported the Mega Mouse I declined to add support at
the time. But leave it to homebrew, especially one as comprehensive as
this patch to add support.
This adds Mega Mouse support for both the 32X and 32X/CD combo, so it is
now available for all Mega * consoles.
To make sure to intercept all possible errors, the check are now
performed by the RDRAM module, whenever a RDRAM read/write behind a
cacheline happens.
CPU writes to cache is now tracking dirtyness at the byte level rather
than whole cacheline level, so that hardware accessing memory does not
trigger a false positive for false-shared variables. An initial round of
testing has shown that the check would trigger far too much otherwise.
Error reporting is also much improved to provide more context to analyze
the issue, including tracking the PC at which the hardware DMA was
triggered.
For RSP DMA, we do even more: instead of reporting an issue when area of
a cached memory is DMA into RSP DMEM/IMEM, we actually just mark those
memory locations as tainted, and emit the warning only if RSP later
reads them. This is necessary because it is extremely common for RSP
ucode to read data beyond the actual buffers it cares about, even though
that data is then never accesses.
Some of the warnings issues by Ares have been analyzed on Super Mario 64
and Zelda OOT and in both cases they have been confirmed to as real bugs
in cache management made by the game.
For instance, in Mario 64, the programmers forgot to invalidate the
cache before loading data for the initial Mario head animation, as
reported by Ares now:
```
[unusual] PI DMA writing to RDRAM address 0x390650 which is cached (missing cache invalidation?)
Cacheline was loaded at CPU PC: 0xffffffff80183b38
PI DMA started at CPU PC: 0xffffffff80328558
```
The game just happens to work because after loading, the game does
something else and manages to get the cache invalidated by touching
other locations, but otherwise it would be a real bug.
As another example, in Zelda OOT, we get these warnings at boot:
```
[unusual] AI reading from RDRAM address 190820 which is modified in the cache (missing cache writeback?)
Cacheline was loaded at CPU PC: ffffffff800b54fc
Cacheline was last written at CPU PC: ffffffff800b5528
[unusual] RSP reading from DMEM address fe0 which contains a value which is not cache coherent
Current RSP PC: d10
The value read was previously written by RSP DMA from RDRAM address 00199e40
RSP DMA started at RSP PC: abc
The relative CPU cacheline was dirty (missing cache writeback?)
Cacheline was loaded at CPU PC: ffffffff800b5244
Cacheline was last written at CPU PC: ffffffff800b5264
```
These warnings appear to be real bugs in the audio library. Quoting
Thar0:
```
* AudioHeap_ClearCurrentAiBuffer/AudioHeap_ResetStep wipe the AI buffers with CPU writes and
then don't write back the cache, and I guess an AI DMA is either in progress or starts before it can
be properly flushed. On boot this shouldn't matter as gAudioHeap is BSS and is already zero, but
if the driver is reset later it might cause some minor issues?
* The RSP cache coherency problems is from loading filters in AudioHeap_LoadLowPassFilter.
The heap allocator returns a pointer to which the CPU writes the filter data.. but the allocator
writes back the cache before the CPU writes the data 😂
```
Moreover, this PR also implements all the known SysAD-related CPU
freezes that cause the console to crash. We now pass the
[n64-systemcrash](https://github.com/rasky/n64-systemcrash) testsuite in
full.
Improvements to fds irq generation logic, to match description at
https://www.nesdev.org/wiki/Family_Computer_Disk_System#Timer_IRQ_control_($4022)
- Fixed "i/o enable" register address
- Correctly acknowledge interrupts in writes to $4022 / $4023
- Improve irq generation logic
The changes are based on the discusion on this thread:
https://forums.nesdev.org/viewtopic.php?t=16507
With this pr ares passes all 21 tests on FdsIrqTestsV7 (many failed
before), which can be downloaded at
https://forums.nesdev.org/download/file.php?id=10240
In addition to passing the tests this pr also fixes Kaettekita Mario
Bros. (Japan): this game has 3 random opening animations before
requesting to switch to side B, two of these openings will display a
glitchy screen with old irq logic. This can be tested by just resetting
if the game shows the animation that works.
Instead of directly specializing std traits classes (which would result
in undefined behavior) define our own traits classes that inherit from
the std types.
This allows us to remove a hack in the serializer class and paves the
way for building ares with Qt on Windows.
- remove -stdlib=libc++ as it caused warnings when applied to C files
and has been the default on macOS for something like a decade
- add -Wno-deprecated-declarations to the command line to silence
warnings about things like sprintf in thirdparty
This option is usually enabled by default by GCC/Clang with -O1 and
above. This is not true on some targets like macOS/arm64, and there we
are better off deferring to the compiler anyway.
This became an issue because Xcode 15 shipped with a new linker that, at
least when LTO is enabled, appears to mess up metadata that is used to
unwind the stack during exception handling. Without a frame pointer to
fall back on, unwinding fails completely and causes ares to terminate.
In addition to approximating the correct values in SI STATUS fields,
this commit also fixes a bug: I/O writes to PIF RAM do trigger an
interrupt just like DMA does.
Disable "fast fail" so jobs will run to completion even if others fail.
The workflow as a whole will still fail, but the jobs that succeed will
produce downloadable artifacts.
Secondly, allow the "macOS: Import Certificate" step to fail on forks.
This allows CI to function on forks without any other setup, though the
produced macOS builds won't run actually run unless you re-sign them.
We frequently get issue reports in GitHub and Discord about driver
settings not being saved. This is due to the fact that changes to
drivers requires using the Apply (formerly Reload) button for changes to
stick, which is different than other options in the settings window.
With this change, the Apply button is grayed out until a different
driver is selected, hopefully making it more obvious that the buttons
need to be used. A small note was also added at the bottom explicitly
stating that they Apply buttons must be used in order to switch/change
updates to driver selection.
From the MSVC docs: "You can use the /permissive- compiler option to
specify standards-conforming compiler behavior. This option disables
permissive behaviors, and sets the /Zc compiler options for strict
conformance."
While generally a positive thing, this does make MSVC stricter than
GCC/Clang in some cases. A couple of things popped out:
- nall::multiFactorImage had a busted constructor. I fixed this and did
some other cleanup while I was at it.
- nall::string has an implicit conversion operator to const char*. This
is honestly really ugly and creates ambiguity and allows for all kinds
of surprising silent conversions. Unfortunately, fixing that (by making
it explicit) will require touching hundreds of lines of code so I opted
not to deal with it now. Instead I fixed the much smaller number of
ambigous cases relating to string literals.
As noted in the Chromium source, the value for
NSTreatUnknownArgumentsAsOpen needs to be of type string despite being a
boolean setting.
If the type is boolean, AppKit throws an exception (which is caught),
but if unwinding fails (observed on some arm64 systems in certain build
configurations when ares is compiled with LTO and -fomit-frame-pointer)
it terminates the whole application.
I've confirmed the behavior the original commit was designed to correct
is still fixed with this change.
MMC3 and MMC6 share the same mapper in the iNES format. To disambiguate
MMC6 from the MMC3 mapper the NES 2.0 submapper 004:1 should be used:
https://www.nesdev.org/wiki/MMC6
Code for using the MMC6 was actually commented in mia/medium/famicom.cpp
up to commit bed4ce3659, where it was deleted. This commit
reintroduces this code to use it with the NES 2.0 submapper 004:1. This
adds compatibility with the games "StarTropics" and "Zoda's Revenge:
StarTropics II".
Fix two issues caused by disc swap timers:
1. Crash on exit in certain build configurations
2. Crash on system unload shortly after disc swap
Because these timers were simply members of Emulator derived classes
(which are in turn owned by a global variable), they were being
destructed after main() along with other static lifetime objects. This
was problematic because hiro also has global state that the timer
implementation depends on, at least on Windows. Whether this manifested
in a crash depended on a few factors, object destruction order among
them (which is at the mercy of the linker).
The second crash would reliably reproduce simply by initiating a disc
swap and unloading the emulated system (such as by closing the emulator)
within the next 3 seconds.
The following applies only to macOS when JIT page protection is enforced
(namely on Apple silicon).
A sequence of jitprotect(false) calls must now be followed by an equal
number of jitprotect(true) calls to restore executable protection. A
further assumption is that nesting always starts with (false), which is
only logical because you have to write something before you have
anything to execute. This is explicitly checked in debug builds.
The N64 and PS1 recompilers have needed this since commit 8ed4af8 in
order to handle the path taken on recompiler cache flushes. It's subtle,
but emit() will evict all pools and so the second call to pool() from
block() will reallocate the pool and unexpectedly toggle the protection
out from under it.
Technically the SH2 recompiler has needed this since commit 241f0e9
(from 8 months ago!) but that same commit made cache flushes practically
nonexistent, so it's likely not impacting the retail title library.
The CPU will freeze until power-off if a cached access is performed to a
non RDRAM area. This obviously never happens with games, but it is a not
so uncommon error when doing very low level development on the system.
This patch emulates the freeze for the data cache, and for the
instruction cache when using the interpreter. Implementation for
instruction cache and recompiler is left as a followup.
To prevent undue performance losses, the extra codegen only occurs when
tracing is enabled. To support toggling tracing on/off during execution,
the recompiler cache is flushed on setting changes.
Flushing the recompiler cache has its own side effects, but that's
already an issue, and it seemed the least bad way to isolate the impact
of this feature.
Add ability to enable/disable N64 4MB expansion pak.
Similarly to the video settings window, I've added a Nintendo 64
specific section in the options window, which was mostly empty. Existing
options fall under a generic "Emulator Options" section. Seems like a
reasonable place to add a few console specific options.
Addresses issue: https://github.com/ares-emulator/ares/issues/939
Currently, we detect the CIC to emulate by calculating a CRC32 over IPL3
bootcode in ROM, and keeping a database of the known IPL3s. This works
because right now there are only a handful of IPL3 variants (exactly one
per CIC).
In preparation for libdragon releasing an open source IPL3 that could
evolve and be forked an unbounded number of times, we must stop keeping
a database of IPL3s.
This commit changes strategy: it simulates the IPL2 checksum hash over
IPL3 (which is exactly what a real N64 does at boot) and verifies if the
checksum matches that expected by any of the known CIC variants. This
works because open source IPL3 variants must anyway have a checksum that
collides with that of CICs (which must be obtained via a second preimage
attack, bruteforced on GPUs), otherwise they would not work on real
hardware nor on Ares itself (which correctly simulates the boot sequence
and would refuse to boot an "unsigned" IPL3).
Level 2 warnings are considered "significant" and turning them on
revealed one issue that could, in the future, have affected MSVC-ABI
builds using either CL or Clang.
MSVC's C++ name mangling distinguishes between classes and structs, and
throughout the ares codebase there were friend declarations using
"class" to refer to types that were defined with "struct".
I don't see any value in retaining this inconsistency, especially
considering that ares otherwise avoids the "class" keyword (though I
spotted a few uses that crept in from recent commits).
Implements port 0x60 bit 1 and 3, a newly-discovered way to change the
cartridge SRAM and I/O bus speed. Also fixes a regression, and adjusts
the ROM bus speed to match a test ROM.
~~Marked as draft as validation on ASWAN ("mono" system) is required.~~
Nobody stepped up for 3 months, so, ehh. It's still more accurate than
it was.
Level 1 warnings are considered "severe" and, unsurprisingly, turning
them on revealed some true bugs.
- file-buffer.hpp: What should have been a zero extend followed by a
complement was instead a complement followed by a zero extend,
inadvertently truncating the file seek offset to 32 bits.
- file-map.cpp: What should have been a nullptr check after
CreateFileMapping() was instead a check for INVALID_HANDLE_VALUE. The
warning pointing me toward this was not technically about the misuse but
rather the redefinition of INVALID_HANDLE_VALUE in nall. I've removed
this and any reference to INVALID_HANDLE_VALUE except for error checks
immediately after calls to the few APIs that return it.
The WASAPI driver in ruby is a bit of an oddball. It has a fixed length
circular queue for samples, and before this commit there was no logic to
prevent queuing more than the requested "latency" number of samples or
even to prevent the queue from overflowing entirely.
In practice this wasn't much of an issue when audio or video
synchronization were enabled and therefore bounding the rate of audio
generation. It did not, however, play nice with the fast-forward
feature, and it caused a noticeable pause after returning to normal
speed as the queue drained from whatever level of fullness it had
wrapped around to (effectively random but averaging over half a second).
Now the length of the sample queue is (mostly) bounded to the "latency"
parameter which is more consistent with the other drivers.
Fixes#958
- add more details to the dd time.rtc format as comments for readability
- fix dd rtc skipping december entirely (wrong comparison)
- I feel really dumb for this one.
- add validity checks on every rtc second tick to avoid glitchy rtc time
& date
- This also avoids the user to be able to skip the time & date error
into a glitchy rtc by simply restarting.
- add validity check on load if the time is valid or not, if not valid,
destroy the rtc info to get the user to input new rtc info
This effect runs on the CPU, which is expensive for HD content and
incredibly so for UHD content. It doesn't make much sense to apply to
non-SD content, in any case.
Currently this only affects the N64 core in HD and UHD modes.
c1cbaf09e x86: avoid clobbering ebx register during CPU detection (#217)
62c91605a cpuid on x86 clobbers memory
856fce15d loongarch: sljit_emit_atomic_load/store implementation using LoongArch V1.10 (#216)
44cee7aa5 allocator: add support for PowerPC in Apple (#214)
e09319736 Improve Windows compatiblity
112fd4119 Add AVX detection
2713dda05 config: use standard interface to detect macOS version (#213)
029327875 Fix addc and subc on arm32
6a718f07d Improve simd lane mov on x86
292bf2e63 The bug is in the generation of a call relative instruction (because this is PIC code). Call relative of 0 will run the next instruction. So call relative is relative to the next instruction, not the current instruction. (#208)
b6f010324 s390x: make sljit_generated_code_size() accurate (#209)
e2c460881 Improve simd lane replicate on x86
73e84319c arm: small improvements for atomics with LSE (#210)
0436b57a6 Improve sljit_emit_simd_extend
ff4c77263 mips: improve FPU detection also for MIPS64 (#205)
6d1376f84 Improve x86 code generation
a443763e4 build: clear warnings with gcc12 and improve Makefile (#191)
d78063a88 ppc: correctly implement SLJIT_REV in 64bit little endian (#193)
git-subtree-dir: thirdparty/sljit
git-subtree-split: c1cbaf09e995d4d2ab87a85b2ed6a27f4e123754
This incorrectly implies that we support the old .smd rom format that used to be standard prior to .bin/.md;
This format is an interleaved format designed for the Super Magic Drive copier and ares does not support it
To prevent confusing users who may sill have legacy .smd files around, I'm removing the extension from mia.
This adds:
- 64DD Disk Swapping for both 64DD standalone games and N64 Combo games
(only if a disk is loaded).
- Safety checks to prevent corruptions.
- Change manufacture timestamp and line to differenciate different disk
files from each other to avoid confusion
Adds D64 file format support, which is the official master 64DD data
file format, which is basically NDD but a lot of the useless data
trimmed out and disk formatting data kept to a minimum.
Works in this way:
- Adds *.d64 file extension to the list.
- Redo code that uses clearer variables to keep track of recognized 64DD
disk file format.
- Add a file size check to do a proper format recognition and avoid
errors.
- Additional data validity checks.
- D64 conversion to the internal disk format (I refer to it as MAME
format) by reusing the same algorithm as NDD while ignoring blocks of
data that are not present.
More information:
https://www.nesdev.org/wiki/Expansion_Port_Sound_Module
While this is a homebrew device, it has already shipped to consumers in
this manner.
TODO (I'm not sure how to fix these issues myself):
- [x] Switching from EPSM back to another peripheral (None or Family
Keyboard) unloads not just the additional EPSM-provided audio streams,
but seems to break *all* audio from the NES core.
- [x] NES 2.0 cartridges can declare that they wish to have the EPSM
peripheral installed by default (Extended Console Type 0x04), but I'm
not sure how to hook this nicely from the pak data to the expansion port
node.
- [ ] Missing serialization, but this affects the Family Keyboard to
some limited extent already, so...
Not urgent at all. It has shipped to consumers, but the amount of
software using it is still lacking.
---------
Co-authored-by: Luke Usher <[email protected]>
This PR adds a new general setting called "homebrew mode", that can be
used as an umbrella setting for all kind of developer-related aids in
the emulator. This will also allow resource intensives checks to be
added (eg: N64 RDP command list validation).
For now, we hook this to the N64 core only in two ways:
* ISVIewer emulation is now only performed in homebrew mode. This is
obviously not resource intensive, but it would have naturally been an
homebrew mode feature, if it existed at the time. Normally, games should
behave exactly like on a real N64, where there is no ISViewer peripheral
plugged in into the PI bus.
* A new cache coherency check is added to PI DMA. If a DMA is performed
to/from RDRAM locations for which the CPU holds a valid cacheline, a
warning is emitted to the console as the game is probably buggy.
Slightly unrelated, a commit also adds a new "DCache" memory viewer, to
see the memory from the point of view of the CPU (so with data cache
taken into account). This is useful to ROM hackers which don't care
about the physical RDRAM contents but rather the memory contents as
written by the CPU.
The latest macOS runner updated the version of python to 3.12.0.
This removes the deprecated distutils core module, requiring the "setuptools" package to be installed to provide it.
distutils is a dependency of MoltenVK.
>Regarding PLB, it looks like it reads from $200 and snes9x, mesen,
bsnes, and the official CPU manual all got it wrong.
Reproduced and verified on real hardware via
https://github.com/gilyon/snes-tests
This implementation was based on our Z80 implementation and as such, has the following quirks:
1. Z80 style opcode mnemonics rather than intel style
2. Has an internal WZ register than a real 8080 lacks
3. May not have fully accurate timing
Despite this, it passes every test in this harness and is correctly detected by CPUTEST.COM as an 8080 rather than a Z80.
The remaining quirks can be addressed as needed
1. Bus refreshes needed a clean up and readjustment. Timings were
compared against US Model 1 VA3 via Ti_'s test_inst_speed rom. Yellow
values are ok, as they normally skew lower due to refresh. Some reds
still remain (of the regular instruction tests) that appear to be off by
1.
2. Basic implementation of delays incurred on both main 68k and z80.
Delay values are tuned according to Ti_'s misc_test rom tests ("Z80
DELAY ON ROM READ", "M68K DELAY ON Z80 ROM READ"). Hardware tests
indicate that z80 delay may skew lower towards 170, while m68k delay
typically sticks to 460. This change puts ares at ~178 z80 delay & ~461
68k delay. Fixes#255.
3. Trivial readjustment of m68000 interrupt timing. Approx'd autovector
delay changed to 14 cycles, which happens to be the median of the
expected range (10-18).
Commit history shows that these were initially added to get audio working in OverDrive 2, but now it works better without them.
Having these additional delays present caused audio to stop working late in overdrive 2's execution, most likely due to causing extended delays and confusing timing sensitive code.
While fixing the observed behavior in games, it also fixed things that are known to be broken on hardware; needs further work.
This reverts commit 785edf60c8.
Compatible with the current MAME romset at time of writing.
This system only has three games:
- Champion Boxing [cboxing]
- Champion Pro Wrestling [chwrestl]
- Doki Doki Penguin Land [dokidoki]
Known Issues:
- No support for configuring DIP switches
- Champion Pro Wrestling [chwrestl] is not working due to encryption
A file is regarded as a Famicom Disk System Bios when
1. It is 8KiB in size, AND
2. it contains the Famicom License DRM/Trademark security string at offset 0xd37
Before this change, the OPN2 thread had to play catch-up, generating a
bunch of samples and potentially overflowing the resampler queue in the
audio stream, as observed in Shining Force.
macOS 14 (Sonoma)'s Game Mode offers some small benefits for ares,
including lower latency for bluetooth peripherals and potential minor
performance gains. The system has various ways of detecting that an
application is a game and enabling game mode, but ares does not
currently engage it. Adding the "Games" app category key value pair to
the bundle .plist is one way of hinting to macOS that Game Mode should
be enaged. In my testing, adding this key to ares's bundle .plist
successfully activates Game Mode when ares is fullscreened.
Co-authored-by: jcm <[email protected]>
sljit performs a single (potentially) oversized executable memory
allocation before generating code. Instead of reserving the requested
amount of space, we can reserve only the used amount and eliminate some
dead space between code blocks.
In some cases sljit may write extra data beyond the generated code.
Because of this, it is no longer safe to assume the remainder of the
code cache is zero initialized. In practice, this assumption only
affected pools which can easily zeroed on demand. This also saves time
on code cache flushes, as we no longer zero the entire cache at once.
- align static code cache to 64 KiB (up from 4 KiB)
- remove dependency on alignas() and associated build workaround
- check for mprotect() failure and fall back on dynamic allocation
- perform dynamic allocation (if needed) at top of main on all platforms
Commit 9422ea5905 introduced support for
resetting the 32x SH2 CPUs from the MD 68k CPU, and it also created a
couple of new issues.
1. SH2::power() tries to allocate from a fixed bump allocator, but that
allocator is only reset from M32X::power(), which is not called in
response to a reset register write. In practice this meant we were
falling back on dynamic allocation, creating performance issues when the
allocation is distant from the ares executable.
2. The code cache could be released out from under a running SH2 libco
thread we switched away from to run the 68k thread.
This change fixes#1 and partially addresses #2, but it doesn't address
the issue of an already executing SH2 code block resuming where it left
off after a reset. I don't currently have a test for this case, so I'll
leave it for a later change.
sljit performs a single (potentially) oversized executable memory
allocation before generating code. Instead of reserving the requested
amount of space, we can reserve only the used amount and eliminate some
dead space between code blocks.
This PR may necessitate more third-party verification than usual. It
also allows for detection of the correct MMC5 board based on NES 2.0
header alone.
bc844c90a Implement vex prefix encoding on x86
3551015c7 mips: enable SLJIT_HAVE_REV for SLJIT_MIPS_REV >= 2 (#203)
3dcdb2575 mips: allow detection of StatusFR with prctl() (#202)
03d40019b mips: fix little endian (#197)
8dcad370c loongarch: implement sljit_emit_fop2r() (#201)
90df876ec mips: correctly detect valid FPU and support StatusFR=1 in 32bit (#200)
5628f9065 Implement full f32 register access on arm32 and mips32
2e0a7b9b7 Double the range available for register indicies
ce85ea911 mips: fix SLJIT_COPYSIGN in 32bit (#199)
2d177ccdc mips: fix sljit_emit_fcopy() for 32bit (#198)
0aed5d4dd s390x: sanitize warnings with clang 15 (#192)
831ea3ec4 mips: fix implementation of sljit_emit_fset64 in 32bit mips (BE) (#196)
abda1b90f mips: add missing ADJUST_LOCAL_OFFSET for sljit_emit_select (#195)
bf5e9a145 atomic: avoid unused checks if not implemented (#194)
c4dc1c8a7 Implement sign extraction on x86, arm
1eaeac321 arm: fix unaligned REG_PAIR thumb2 operations (#190)
63de0d9f6 arm: restrict NEON/VFPv3 code in sljit_emit_fset{32,64} (#189)
108a4b410 arm: restore emulation for SLJIT_CTZ in armv6 (#187)
abe5001d8 arm: use armv6 compatible instructions for thumb2 in atomic (#186)
0821be0b6 simd: prevent SIGILL with armv6 (#184)
be7b02a41 Better simd checking in the tests
299ae4ae7 Implement element extension on x86, arm
976e5d813 Be explicit about OS version (#179)
351d9afc7 x86: really detect SSE41 (#181)
8a3c0d1d8 x86: correctly detect SSE41 (#180)
dfff60447 Implement simd zero before lane set on x86, arm
0e4cbc9a8 Rename SLJIT_INT_REGISTER to SLJIT_GP_REGISTER
12d36226e simd: avoid unused parameter warnings (#178)
5c15decbf Implement sign extended lane store on x86, arm
44d8136d1 Implement lane replication on x86, arm
31556f80e Implement lane replication on x86, arm
750987e45 Implement simd mov reg on x86, arm
d17bf952d Implement simd source duplication on x86, arm
d9c74c990 Remove MEM prefix from several simd constants
a2c65c3c7 Implement simd lane transfer on x86, arm
38d96705b Fix incorrect branch offset calculation (#177)
87f9e7791 Rework sljit_get_register_index
git-subtree-dir: thirdparty/sljit
git-subtree-split: bc844c90ac79e7d56c04182e010c6aa8e5957b24
Fix various recently introduced build issues.
Some background for the string indexing thing: using operator[] to index
nall::string causes some ambiguous overload errors in 32-bit builds.
This isn't the first time it's come up, but since it's so easy to work
around (using operator() instead) I haven't bothered to try to fix it.
This PR adds a generic GDB server to ares with the ability to be used by
all systems.
For now only the N64 systems was implemented here.
Most documentation on how the server/TCP socket works can be found in
comments.
A detailed documentation for ares developers on how to add this to other
systems is included in the `Readme.md` file.
The feature itself was also already tested by a few people on both linux
and windows (with WSL) and seems to be stable now.
The data is still loaded sequentially and accesses will block until the
data at a given address is available. In the worst case (an immediate
read at the end of the last track) things are no faster than before, but
it still feels better because the UI responds immediately to the user's
load request.
This could be further refined by skipping ahead to serve incoming reads.
Up until 67d1647d6e, clang was the assumed
compiler on macOS and BSD, and g++ was the default everywhere else.
After that commit, we defaulted to clang on all platforms if it was
found in the user's path. It has since become clear that while a number
of Linux users have clang in their path, many have not installed
critical packages necessary to build C++ software and are completely
unaware of this state of affairs or which packages need installing.
To simplify matters, we will revert to the default of g++ on systems
other than Windows, macOS, and BSD. Additionally, the `verbose` target
will now print the compiler in use, as this is pretty relevant
information for diagnosing build issues.
This allows for firmware to be set from a user selectable firmware directory at the click of a single "Scan" button on the firmware configuration screen.
1. Fix timing relationship between cpu and tia,
2. Implement latching of current playfield pixel
3. include "current cycle on this scanline" counts in cpu trace output
Instead of assuming pkg-config is available with bash, test for its
presence. This allows the build to function if using bash without
pkg-config or using cmd with pkg-config.
Instead of assuming the sdl2-config is available if pkg-config indicates
that SDL2 is present, just use pkg-config directly to acquire the
compile and link arguments. Again, this allows the build to work with
cmd (since sdl2-config is a bash script) and if your copy of SDL2 just
didn't come with sdl2-config (for example, from vcpkg).
On Windows and Linux, ares uses a buffer in the bss section for the
recompiler code cache. On macOS this buffer must be dynamically
allocated for security reasons. The distance between the code cache and
the rest of the ares executable has a large influence on performance on
all platforms because there are microarchitecural thresholds beyond
which branches will never be correctly predicted by the CPU.
To make performance more consistent on macOS, we can make this dynamic
allocation sooner, at the top of main(), before the address space has
become too cluttered with allocations made by other code.
In addition to detecting the pattern `beq 0,0,<pc>` for idle loops,
detect the pattern `j <pc>`.
From a selection of about 60 games, about half used beq, a quarter used
jump, and a quarter had nontrivial idle loops.
Additionally, this commit returns the step time for idle loop
acceleration to 64 CPU cycles (128 system cycles). This was accidentally
halved in commit ffcce5823c.
Some instructions should complete faster for simple inputs (notably
mul), but this is not yet implemented. The extra cycle delay imposed by
the next instruction depending on the output of the previous is also not
implemented, as there is currently no framework for emulating pipeline
effects in the main CPU.
aa71425db Improve info provided about simd
b5f214edb Implement simd load/store on x86, arm
dd683ab67 build: add barebones cmake for Windows (#123)
13d577046 Implement copysign on ppc, mips
9637d82c9 loongarch: implement copysign (#176)
7c78ea2e1 Implement copysign on s390x
9764568d0 Implement copysign on x86, arm, riscv
d2363accc s390x: fix atomic store emulation when offset in higher int (#175)
18fc38fe3 config: allow CPU specific configurations (#174)
818706a80 loongarch: fixes and other cleanup for portability (#171)
db433181a add base support for LoongArch 64bit (#170)
git-subtree-dir: thirdparty/sljit
git-subtree-split: aa71425db565916d1ebaef107df295d66626e963
- Beetle Adventure Racing (J): Replace "NBB" with "NB8" (fix substitution).
- J.League Live 64: Replace "NLJ" with "NJL" (fix transposition).
- Quake 64: Replace "NKQ" with "NQK" (fix transposition).
- Star Fox 64: Remove "NFP" variant. This was printed on the box/manual
in some regions but only "NFX" appears in the ROM.
Implement vector unit (VU) timing including dual issue with the SU.
Tested against real hardware with a random instruction stream generator.
Known limitations:
- Invalid/missing instruction timings not implemented.
- CFC2/CTC2 dual issue restrictions not implemented.
- Some corner-case dual issue restrictions (e.g. LTV + VNOP) not implemented.
On real hardware, VU instructions with a DE operand are sometimes prevented
from dual issuing with vector loads under seemingly erroneous conditions.
The previous formula was a decent approximation, but it looks like 6105
antipiracy protection requires a better one (in addition to better RSP
timings that already went in).
Fixes#129 (Jet Force Gemini and Mickey Speedway USA)
Implement pipeline stall conditions for the RSP's scalar unit (SU).
Tested against real hardware with a random instruction stream generator.
Vector unit (VU) timing, including dual issue with the SU, is not yet
implemented.
When an interlaced output is made by the game, an N64 emulator right now only allows "Bob" deinterlacing, this commit also adds a "Weave" deinterlace option
like all of these computers, loading cassette tape games is awkward,
requiring the user to know what format data the tape contains.
The following basic commands are used to load cassette tapes:
Binary Data: `BLOAD"CAS:",R`
Tokenized Basic: `CLOAD`
ASCII `RUN"CAS:"`
This introduces a faster version of tlb.Load which omits exception and debug checks in
instructionEpilogue; as it is assumed these checks are handled sufficiently by the recompiler
instruction fetch phase before execution.
Additionally, this also introduces a simple cache that caches the virtual to physical mapping
for a single 4k page; this prevents per-instruction lookups within recompiled block; and is
cleared when the TLB is written to, so should never become stale.
It is too slow to be usable with the rest of ares,
Now that macOS can run Parallel-RDP with MoltenVK, there is little reason
to keep this around.
We can just say that Vulkan is *required* for the N64 core going forward.
This reduces the total number of function calls made in each loop of system->run()
n64: add fast variant of devirtualize; fix remaining task from PR #1069
to scale according to cardinalMax, rename startCardinalMax and others for better clarity, and reformulate startCardinalMax based on new response equation.
54bfb871c Merge pull request #99 from scribam/dr_libs
5cd76b97e Revert "deps: add dr_libs as a header-only library"
903f2f5cc Merge pull request #93 from scribam/deps
1ccead153 deps: add dr_libs as a header-only library
3c6e0e47a deps: add zlib-1.2.13
8e04476eb deps: remove zlib 1.2.11 and zlib 1.2.12
468490000 Merge pull request #97 from scribam/github-workflows
b2996c832 Add basic GitHub Actions
688759416 Merge pull request #96 from scribam/malloc
10c340c5a Check mem alloc failures triggered by invalid chd
37a5c0f3c Merge pull request #94 from scribam/auxv
026969b6d Merge pull request #95 from scribam/division
179f02553 Avoid division by zero
5f3927dc3 Declare hardware capabilities for the Nintendo Switch and PlayStation Vita
fec8ab942 Merge pull request #89 from jpd002/huff_codec
4ddae00e5 Merge pull request #91 from flyinghead/master
de740535f Avoid huffman tree buffer overrun in huffman_import_tree_rle
571507743 Add support for 'huff' codec.
git-subtree-dir: thirdparty/libchdr
git-subtree-split: 54bfb871ccae31903b95a8feb7f2bf7121f304be
51538f102 documentation: refactor registers and function signatures (#169)
47ed75d0b Improve copy between float and general regs on x86-32
91798631a Fix uint to float conversion on x86, ppc, mips
6a8dc94e0 Implement unsigned to float conversion on ppc, mips
61736a11a Implement unsigned to float conversion on s390x
ec6d52516 Implement unsigned to float conversion on x86, arm, riscv
f368bb254 arm64: use MOV instead of ORR for readability (#166)
07a556181 arm64: implement atomics using CAS for CPUs with LSE (#164)
1a4d5f229 Improve atomic operation constraints (#165)
b7fed8e11 x86: correctly detect mode32 for atomic_store (#163)
a0e16b14f arm64: avoid undefined behaviour with signed shifts (#161)
7f2886127 Implement operations on s390x
c54325fee Improve atomic instructions
3499aba93 Set armv6 as the minimum arm version
53d5a2252 Implement set f32/f64 on x86, arm, riscv, ppc, mips
03bb5347f Improve atomic operations
b91921e24 Increase max stack to 1 Mbyte
af4ca5da5 Add atomic instructions (#157)
e37ec3253 macos: allow runtime detection if target is older than BigSur (#127)
5ed7e00a1 Remove functions for unsupported architecture
fa1881b57 Implement operations on s390x
cf5a17b77 Implement fselect operation on x86
e5c75cd73 Implement rev.u32 and rev.s32 on x86, arm, riscv, ppc, mips
d1f287bec Implement select, rev.u16 and rev.s16 on s390x
7efd60de8 Implement rev.u16 and rev.s16 on x86, arm, riscv, ppc, mips
63e307e4a Implement select operation on x86, arm, riscv, ppc, mips
3cc2b0fb2 Improve floating point comparison
git-subtree-dir: thirdparty/sljit
git-subtree-split: 51538f102dd342a6246e98acafc00ceebbab4618
Although Nintendo made many different cartridge circuit boards with different
memory mappings, ROMs do not indicate which specific board they are intended
to work with. Super Famicom emulators traditionally group mutually-compatible
mappings together and use heuristics to guess which family of mappings the
game expects.
There's one family of mappings that maps ROM data to the top half ($8000-$FFFF)
of memory banks in the Super Famicom address space. For historical reasons,
this family is called "LoROM" and has three main variants:
1. ROM only, mapped to the top half of every possible bank.
The boards database calls this "LOROM".
2. ROM mapped to the top half of every possible bank,
RAM mapped to the bottom half of banks 70-7d,f0-ff.
The boards database calls this "LOROM-RAM"
3. ROM mapped to the top half of low-numbered banks,
RAM mapped to both halves of banks 70-7d,f0-ff.
The boards database calls this "LOROM-RAM#A"
The largest official game that used variant 3 was 1MiB, so a common heuristic
is "if the ROM is 2MiB or less, use variant 3, otherwise use variant 2".
2MiB is used as the threshold instead of 1MiB, perhaps so somebody can expand a
commercial ROM that uses variant 3 without having to rework it to suit a
different mapping.
Since v107 or so, higan (and by extension, ares) has implemented variant 3 by
mapping ROM to banks 00-3f,80-bf, which exactly fits a 2MiB ROM. However,
other emulators like Mesen, snes9x and higan v106 implement it by mapping ROM
to banks 00-6f,80-ef, all the space that is left after the RAM is mapped.
This doesn't affect any verified games in the `Super Famicom.bml` database,
since those have specific, accurate memory maps. It also won't affect
well-written games that only read from memory addresses they have populated.
However, homebrew games and ROM hacks that have never existed on a real circuit
board depend on these heuristics across all devices that read Super Famicom
ROMs, including software emulators, flash-carts, and FPGA implementations, so
ares should match what other emulators do.
Adds support for patching ROMs on the fly with a corresponding IPS patch
file. Functions in a similar manner to the pre-existing BPS support. If
a *.ips file is found with the same name as the ROM, it attempts to
apply the patch. If both a BPS and IPS file are found, the BPS patch
takes priority. This patch implements the IPS format as described here:
https://zerosoft.zophar.net/ips.php
SWL/SWR do not raise address errors (it's their whole reason of
being), but they can still raise TLB misses if they access an unmapped
memory area. In that case, the COP0 BADVADDR register is expected to
contain *exactly* the address passed to them.
This happened to be true (by luck) for SWL but not for SWR: SWR in fact
needs to write *before* the address passed to it, so the opcode itself
was adjusting the address before calling the memory function.
Fixed by passing the misaligned address to CPU::write and telling it
to skip address errors. It's not pretty: the code in CPU::write/read is
a bit of a mess and it would require some refactoring but that's for
another day.
Verified on real hardware by adding a new test to n64-systemtest, which
is has been submitted upstream (https://github.com/lemmy-64/n64-systemtest/pull/50).
Interrupts are deferred when the CPU is in a branch delay slot. If the
recompiler repeatedly exits the code cache in a delay slot (much more
likely with "min cycles between syncs" optimization active) then
interrupts will be deferred indefinitely.
This is now avoided by resetting the "cycles until sync" count when
interrupts are deferred due to a branch delay slot.
An alternate and possibly more robust solution would be to single step
the next instruction with the interpreter. One side effect would be the
generation of more compiled blocks.
VR4300 icache/dcache use both the virtual address and the physical
address: the former one is used to select the cacheline (just like
the key to a hashtable), while the latter is used to check that the
cacheline contains the correct line of memory and not another one
that happens to have the same hash key.
So any access to the cache requires both addresses. This commit makes
this explicit, and make sure to call the functions correctly.
The only exception where we leave a FIXME is the icache.step call
in the recompiler, as we can't possibly devirtualize the PC for each
opcode. This will have to be fixed in another way.
With PC Engine, ares always emulates the presence of CD-ROM drive so
games can use its backup RAM for save data. However, it was not properly
loading the backup RAM file when loading a non-CD game, causing the file
to be subsequently filled with FFs on save.
The BIOS format procedure detects the size of backup RAM by sweeping
bank $f7 while writing zero and reading back the result. It stops when
the read back value is nonzero, proving that the 2 KiB backup RAM is not
intended to be mirrored across the 8 KiB address range. With this
corrected in ares the BIOS writes the correct header indicating the end
of the backup RAM is at 0x8800 rather than 0xA000.
This adds a hotkey that can be used to reset the active system.
Although this is similar to the existing "Reload Current Game" hotkey, it does have a functional difference, since a soft reset can result in the state of a system being slightly different than a cold boot. It also does not result in resizing the emulator window and is slightly faster due to not needing to reload various resources.
When using nall as a header-only library it was possible to opt out of
nall taking over main() by simply not including main.hpp. There was no
mechanism to opt out when building nall as a separate translation unit
because nall.cpp unconditionally pulled in main.cpp. Now, users of nall
must specifically opt in by including main.cpp in their build (though
header-only users still only need to include main.hpp).
- Update dirty bit field on invalidate so overlapping blocks can be lazily evicted
- Track "generation" to allow entire cached memory area to be lazily evicted
- Invalidate appropriate cache line/memory area on cache purge
Using lld is required to support advanced scenarios like incremental
ThinLTO and PDB symbol output. macOS has its own linker (ld64) and we
can continue to use that there.
If the iNES 2.0 header specifies NTSC timing, ares should not emulate a
PAL console even if the user region setting is "prefer Europe".
This change also embeds the iNES header in manifests to simplify user
bug reporting.
While I am happy we did the work to support this, having multiple
build systems does make it harder for contributions to be made
We can restore msbuild CI tests once (if) we eventually switch
to cmake.
Apply -march tuning for x86 (not just x86-64) and correctly pass
the ThinLTO cache path through the non-CL Clang frontend on Windows.
The move to CMake can't come soon enough.
With ThinLTO and an incremental LTO cache, incremental link time (with
LTO, of course) goes down from tens of seconds to less than a second.
For whatever reason, ThinLTO needs libco's co_swap_function to have
external linkage. Who am I to argue?
When booting the MD core from a CD a board is allocated on demand in
Cartridge::power(), and this is critical for Mega CD 32X games to
function. However, it also puts the cartridge into an inconsistent state
in which allocate() was never called and therefore catridge.node is
null, causing disconnect() and save() to be short-circuited. This means
the board never gets cleaned up, which also means it never gets
recreated in power() on subsequent loads. One consequence is that
loading a MCD game followed by a MCD 32X game will cause the 32X to not
actually be connected.
Given that all of these system configurations contain a cartridge slot,
it follows that one should always be allocated. This implies
cartridge.node will always be non-null so it cannot be used to determine
if a cartridge is actually connected. This change corrects one such
usage.
Avoid hard dependency on __int128 type suppport. For extended
multiplication, use MSVC intrinsics as an alternative when possible.
If neither are supported, fall back on the u128 type defined in
nall/arithmetic.hpp (which incidentally also works when building as
32-bit).
MSVC applies the same narrowing rules to these as it does to list
initializers, and while I don't know if that's justified by the standard
it's easy to avoid narrowing conversions. In this case, basically every
other core already defines System::frequency as a double so the a26 core
was the odd one out.
MSVC doesn't seem to support string literal concatenation in a
__declspec attribute, but that's fine because we only care about adding
to the .text section. It also requires an explicit pragma to define the
.text section before it can be referenced. Clang is fine with or without
these changes.
MSVC wants these to compile certain experessions, and while I'm not 100%
sure if it technically should require them, I see no reason for these
classes not to have any.
Narrowing conversions in initialization lists are disallowed by the
standard, but nall was supressing this diagnostic (which is actually
an error by default). MSVC doesn't let you supress errors so easily, so
we'd do well to abide by the standard and perform explicit casts as
needed. For nall::shared_pointer::create() we can simply avoid the
uniform initialization syntax to bypass these extra rules, which is the
same strategy taken by implementations of std::make_shared().
Variable length arrays are a C language feature (one of many, actually)
that does not exist in any version of the C++ standard. GCC supports
them in C++ with improvised semantics defined by no standards body, and
Clang follows suit for compatiblity with GCC.
Now a setting can be changed from command line using --setting.
The list of settings can be dumped with --dump-all-settings, so that
it is easy to find out how a certain setting is exactly spelled.
Previously, terminal (console) support on Windows required opting in at
compile time. Now, the runtime behavior is largely the same regardless
of how ares is compiled.
- ares will attach to the terminal of the parent process (if present) by
default and redirect any unset stdio streams.
- If the --terminal argument is provided, ares will always create a new
terminal window and stdio will be redirected to it.
- Otherwise, if stdio handles were already valid on launch they will be
left alone (to support redirection to/from files).
By default, builds are "local", meaning they are optimized specifically
for the host machine. For non-local builds such as our CI builds, we
enforce a minimum CPU spec to allow the compiler to use instructions
beyond the base AMD64 ISA. ares may also make use of SSE4 instructions
via intrinsics in the N64 core. On AMD64, the capabilities of the host
CPU are now checked at runtime and an error message will be displayed to
inform users if their machine does not meet the CPU requirements of that
build.
- Because clangarm64 is now a default enabled package source, there is
no need to edit pacman.conf.
- Because there is no need to edit pacman.conf, there is no need to sync
the package database.
- Because there is no need to sync the package database, there is no
need to update the initial set of installed packages to prevent
version mismatches.
- Install the "clang" package in favor of the "toolchain" package group
as none of the extra packages are needed by ares.
The other audio drivers in ares read exactly two samples from the buffer
passed to output(), but the WASAPI driver was reading the number of
channels supported by the device. ares only ever passes in two samples
so ruby was reading beyond the extent of the array. This caused garbage
to be piped through and resulted in silence on certain systems and build
configurations (likely because of NaNs).
This was only needed for parallel-rdp and that's been fixed upstream
which is now causing redefinition warnings. It's still defined by nall
headers so most of ares is unaffected either way.
When in a delay slot, instructions that modify PC should immediately
trigger an illegal slot instruction exception. This exception is not
predicated on the branch condition (in the case of BF/S or BT/S) of the
instruction in the slot. Furthermore, it should trigger before any side
effects of the instruction are observed.
Raise the timeout to make Start Wars: Shadows of the Empire boot again.
Also improve simulation of CPU halt; the real PIF does toggle the NMI
line but it does so extremely quickly. We don't emulate PIF that often,
so it's more accurate to simply keep the NMI line asserted forever,
as the final effect on the CPU is the same.
The multiplier scale settings are now radio buttons, allowing the
user to see which option is selected.
Available scale sizes are no longer bound by the current monitor
size, avoiding the situation where a selected option disappears
when moving a portable configuration to a different computer,
instead, the actual resizing code prevents the window from growing
larger than the display size.
The window resizing logic now avoids un-maximizing the window, if
the user has manually done so, even when adaptive sizing is
enabled.
Scale options have been renamed to better describe their function
and two new scaling modes have been added:
"Center" has been renamed to "Scale (Integer)"
"Scale" has been renamed to "Scale (Best Fit)"
New setting: "Pixel Perfect" which will always display a 1x scale
image in the center of the display, regardless of the window size
New setting: "Scale (Fixed)" which will always display an image
matching the users selected scale factor (1x, 2x, etc) regardless
of screen size.
This reverts pull-request #945 as it made ares rather frustrating
to use in non-1x situations for most users.
A more robust scaling solution will be worked on soon.
Allow Turok to boot again. This probably points to a problem in our
CPU timings, but the boot timeout number is made up anyway and doesn't
really help anyone to keep it short, so bump it.
Thanks to kev4cards for the analysis
Controller paks only accept writes in range 0-7FFF (without mirroring),
and return 0 when reading out of range.
Rumble paks return the ID only in range 0x8000-???? (TBC)
and accept writes only in range 0xC000-???? (TBC).
Fixes Milo's Astro Lanes saves, and Goldeneye initial rumbling.
Selecting "nothing" for a controller port from the UI only consistently
blocked input from the host, and it did not reliably do the extra work
required to actually disconnect the controller from the perspective of
the emulated device.
This was handled only by the MD and N64 cores, but now all cores are
standardized on the disconnection method originally implemented for MD.
4f7d8ec545 Improve code generation on x86
09cad66bc0 Change tmp1 to ebx on x86-32
2de5e04919 Allow negated comparison
5040a3caa1 Test84 fix
1811f1dcea Rework sljit_emit_shift_into on s390x
ba08667852 Rework sljit_emit_shift_into on x86, arm, ppc, riscv, mips
95d2d320ed Add define for masked shifts
dc79333621 Implement fcopy on ppc, mips
c9e58a4806 Implement fcopy on s390x
03f68fea46 Implement fcopy on x86, arm, riscv
ac6c7b307f Implement byte reverse on ppc
f4d1b06e9d Implement byte reverse on s390x
5ed842e093 Implement byte reverse on x68, arm, mips, riscv
fba2206b40 freebsd: implement system specific execallocator (#155)
0a0ab41d03 test: update test15 for 4 arguments (#149)
1942237bda config: really improve autodetection for arm (#153)
7de0fee9a7 Move allocators to separate files (#151)
7de1a4356d On x86_32, check for virtual registers in conversions to and from floating point (#152)
c2f9c138a6 riscv: disable FPU when using soft-float ABI (#147)
3b89155a25 config: improve autodetection for ARM (#145)
0a313731b9 Implement new features on s390x
26213dadc4 Introduce op_dst
faecd2b12f Implement sljit_get_return_address
8b491d0ade Replace not with xor
88e0dcf360 Add allocator data getters
git-subtree-dir: thirdparty/sljit
git-subtree-split: 4f7d8ec545f58ebe93a08f137fcb9a6dd2bb170f
This very boring commit should basically produce no changes. It just
make sure all devices can now step the CPU while the I/O is in
progress, if needed.
Numbers are based on this test ROM:
https://github.com/rasky/n64-systembench
There are still many other cases to handle but this should provide
the initial framework for further experimentation with PIF timings.
Fix a regression introduced by my last change. The pattern of checking
ready() at the top doesn't work for clear() because it's called from
iniatialize(). This was obscured by the fact that other code calls
clear() again after initialization *unless* you are loading a ROM
directly from the command line.
The WASAPI driver should now gracefully handle machines that don't have
any available output devices. The XAudio2 driver probably still won't,
but more importantly it won't crash machines that don't have a specific
DirectX redist from 2008 (!). It needs a rework but for now I'm leaving
it a little better than I found it.
The rom viewer debug window is a casualty of moving
to the board system, but as NES/Master System and
others with multiple board types don't have it,
it's not a big loss.
NOTE: This requires 'non merged' type roms, with all files related to
the game in a single zip file, ares does NOT resolve parent/child
relationships between roms.
This is a little bit hacky, because the debugging code in libdragon
is not compatible with actual IS-Viewer hardware, so we emulate
a 'quirky' version that satisfies both libraries.
This emulates the ZX Spectrum 48k and 128k models and should be fairly accurate
although imperfect; it is considered experimental for now. Save States are not
fully implemented, you may wish to avoid using them for this core.
No controller interface is currently exposed, meaning games must be played with
the keyboard at this time. It is planned to support the Kempston interface,
while supported by the underlying core, the UI interface for attaching expansion
port devices has not yet been implemented.
You must map a "Keyboard Capture" hotkey to allow ares to emulate the keyboard.
Ares maps most ZX Spectrum keys 1:1 with the same key on the host keyboard.
CAPS SHIFT is mapped to Left Shift, and Symbol shift is mapped to Left Control.
For special characters, it may be beneficial to look up the ZX Spectrum
keyboard layout. For the 48K it is necessary, as BASIC uses hot keys
rather than typed commands, for example, to load a game on the 48k,you must
type `J <symbol shift> PP` and then hit enter, which results in `LOAD ""`
being entered on the screen.
For the ZX Spectrum 128k, you can just use the Tape Loader menu option.
The emulator only implements support for raw WAV dumps right now; this is
because the TZX format is over-complicated, and I did wish to implement it at
this time.
There are many tools available for converting TZX to WAV, for all platforms,
so this isn't really seen as a blocking issue.
Enable these warnings in nall so they apply to all of ares and annotate
legitimate fallthrough with C++17 standard [[fallthrough]] attribute.
This type of mistake is just too easy to make.
Add support for American Video Entertainment's NINA-001 board which was
used only by the unlicensed NES port of Impossible Mission II developed
by Novotrade.
iNES mapper 34 is assigned to two unrelated boards, so detection must
rely on the NES 2.0 header or use the CHR ROM size as a heuristic.
The -mconsole and -mwindows flags don't seem to do much of anything when
Clang isn't targeting MinGW. On the other hand, directly overriding the
subsystem with a linker flag results in a bunch of unresolved symbols.
However, if the right entry point exists (either WinMain or main),
some apparent magic goes on under the hood to ensure that everything
links as expected, so we can just take advantage of that.
context.physMask is only used for TLBs. In directly-mapped memory
segments (either cached or uncached), the virtual-to-physical conversion
uses a hardcoded mask that depends on the exact address space segment,
and is not contextful. In 32-bit, segments only use 29 bits of the
virtual address. In 64-bit, some segments (xkphys*) use the full 32 bits.
Besides 64-bit direct-mapped segments correctness, this also fixes
the devirtualize function that is used as part of the CACHE/LL/SC
opcodes, which were misbehaving when used with a uncached segment
(0xa000'0000) in 32-bit mode. This might actually affect also games.
This change makes it possible to build ares using Clang without
MinGW-w64. All that is required is a copy of Visual Studio (or Build
Tools for Visual Studio) and Clang (also available through the VS
installer) along with GNU Make.
To build, just open an x64 Native Tools command prompt and run
`make compiler=clang++` as usual.
Begin the process of splitting nall into separate translation units.
It can now be used in two ways:
1) as a header-only library by defining NALL_HEADER_ONLY
2) by compiling nall/nall.cpp
sourcery has been updated to demonstrate the header-only use and
everything else now builds nall.cpp.
So far the only things moved into .cpp files are implementations that
call Windows APIs. This allows most of ares to build without including
windows.h and enables the removal of the abomination that was
windows/guard.hpp. The things that actually need windows.h (hiro, ruby)
must avoid using names reserved by Windows headers, but the rest of ares
is free to use names like "far", "boolean", and "interface" with
reckless abandon.
This work is done in preparation for building against MSVC and Windows
SDK headers/libraries an an alternative to MinGW-w64.
I know we play with this a lot; but it is the difference between barely scraping 50-55fps on 32x core to getting constant 60-70fps on my machine.
This does increase compilation time with GCC, clang fares a lot better.
This brings a significant performance increase to the NES/FC core with no accuracy or maintainability impact;
This is possible only because they share the same base clock, and always step at the same rate.
4b8798e4d2 config: simplify use of external allocator (#143)
d598b86d81 Add tcc to the list of compilers using AT&T syntax (#142)
c8e664c73b Fix x86 inline asm register clobbers (#141)
b65c854289 Add conditional exit for clz/ctz on riscv, mips
f55425dac8 riscv: typo in detect_jump_type (#140)
0148e65576 Implement ctz and improve clz on riscv, mips
e8eb434b2e Implement ctz on s390x
51d3c96183 arm: add missing check sljit_emit_mem_update in aarch64 (#139)
cd2a31e199 Implement ctz on x86, arm, and ppc
c0286016cf Improve rotate on mips, riscv
fded9f7823 Implement rotate on s390x
35764edc9e Implement rotate on mips, riscv
ea49b3f52e Implement rotate on x86, arm, and ppc
da180ae7e1 Implement sljit_emit_shift_into on s390x
05f5980620 Implement sljit_emit_shift_into on ppc, mips, riscv
84c0bc3614 Implement sljit_emit_shift_into on x86 and arm
8da3b39558 Label odd numbered tests (#134)
06e13ac7cc Label even numbered tests (#133)
1501371fad Split emit_mem to emit_mem and emit_mem_update
89965887cc Implement return_to on mips, ppc, riscv
e21f485cb4 Implement return_to on s390x
a122423a40 Implement return_to on x86, ARM
4672d4f6cb Improve cmov on s390x
06e9864247 Change SLJIT_32 flag passing to cmov
29af0267ce Update documentation
190313fcc2 Fix spelling of 'subtract' (#132)
4325440b0b Support floating point return
ba0f935c9a Implement recent features on s390x
12e6cb055b Implement always masked shift
f22f976060 Support memory moving of register pairs on riscv, mips, and ppc
git-subtree-dir: thirdparty/sljit
git-subtree-split: 4b8798e4d2fe8f8e8fb82b28e2dda9d71a00b27f
* The NEC V30MZ does not ignore the immediate operand in AAD/AAM calls.
This is contrary to NEC V20/V30 behaviour, as well as many existing
emulators. It is, broadly speaking, important to remember that the
V30MZ is much closer to "an 80186-compatible CPU with much better
opcode timings" than "a V20/V30 derivative". A test ROM is provided
for this.
* The sprite base location register's access to 0x4000-0x7FFF memory
is gated by the color mode bit, not by the 4bpp mode bit. A test
ROM is provided for this.
* The PPU can address 1024 tiles in 2bpp color mode, simply by
following the consecutive addresses (so 0x2000-0x5FFF total). This
has been verified independently.
* The planar(), packed(), depth() and grayscale() functions have been
reworked to accurately reflect what the hardware does. This has been
verified independently.
Currently, analog inputs are bound when crossing the threshold in either
direction halfway between zero and full positive/negative. This logic
doesn't work for triggers that are mapped to the full range of an axis
(as opposed to half the range) which makes them impossible to bind
correctly unless they are initially half pulled when pressing the assign
button. I'm not convinced there is much utility in binding any axis on
motion toward the center position, so this change triggers binding only
on motion away from the center.
Converting a negative floating-point value to an unsigned integer is
undefined behavior and just happens to do the desired thing when
compiling for x86-64. Convert to a signed integer first to avoid UB and
guarantee the expected result on arm64.
Using the host carry flag is a bit tricky because on ARM64 (and most
other non-x86 architectures) the meaning of the flag is inverted for
subtraction. There were some helpers in the recompiler to deal with this
but they performed explicit architecture checks which ran counter to the
goals of a generic recompiler.
Reading back the carry flag is now handled directly by sljit. This
feature had been removed from sljit but was recently added back. It
internally tracks whether the setting operation was an add or a subtract
so that x86 semantics are observed on all architectures.
Loading the carry flag is now handled with an explicit add or subtract
that matches the subsequent usage. This results in expected behavior on
all architectures.
Reinstate preprocessor guards for SSE code. Constexpr if statements
don't really work because the compiler still requires declarations for
the SSE types and intrinsics even if the body is ultimately discarded.
When building with clang for ARM64, the cmath round functions that
return floats compile to a single FRINT instruction. The ones that
return ints are provided by the C runtime, which is problematic on
Windows because the mingw implementations don't set the desired
status bits.
Two things are making this a bit more complicated than it ought to be:
- The msys2 clangarm64 package repository is not enabled by default
because it is still considered 'experimental'
- Cross-compiling requires that you manually override the runtime
library directory for the 'builtins' lib to be located
Both of these issues are known and should be addressed eventually.
There's a "hardware bug" in VI that hides 8 pixels on beginning/end
of each scanline if the scanout begins within the active area.
It is emulated by parallel-RDP but not by our VI implementation.
In a CRT, this is all within the border so it's not visible, and most
games will also respect an even smaller "safe area" anyway. It becomes
visible once the horizontal scanout start is pushed right into the
central area of the screen.
This is another regression introduced to mame RDP wrt upstream
angrylion and parallel-RDP. The color combiner slot "ONE" should use
the value 0x100 for the color components, not 0xff. Notice that
"ONE" in the blender is indeed 0xFF, instead.
- Fix copy assignment operator
- Prevent reserve() from reallocating/rehashing unless capacity is increasing
- Prevent insert() from inserting duplicate entries
- Disable remove() as needs some work and is currently unused
The "mask" feature in the instruction tracer broke when the N64 address
space was increased to 64 bits. This change fixes it by switching from a
vector to a hashset for tracking visited addresses.
The instruction tracer's default history depth (4) is much too low to
reliably filter out hot loops in processors clocked above a few
megahertz.
Assuming a correlation between processor speed and the path length of
code written for that processor, this change sets the history depth to
the processor's clock speed in megahertz rounded to the nearest power of
two.
This choice is arbitrary, but in practice I've nearly always had to
manually adjust the trace depth to values in the 16-64 range when
dealing with faster processors, so this seems like a good enough
heuristic.
- Detect RTC with MBC30 mapper (Pocket Monsters - Crystal Version)
- Read current time before saving it to disk, not after
- Don't clear RTC in power()
GDI's default mode of operation for downscaling is optimized for
monochrome images (!) and produces strange artifacts on color images.
This change selects the GDI mode that is essentially nearest-neighbor,
which is not great but is at parity with how it does upscaling.
e02b3d68eb Merge pull request #84 from scribam/dr_flac
146f076ca7 dr_flac: Version 0.12.39
9882eeaaa2 Bump dr_flac to latest, bump libchdr version to 0.2
44c91c96d4 Bump LZMA SDK to 22.01, need to implement asm optimizations
8cd08c0752 Upgrade to zlib 1.2.12
2781322c4a Merge pull request #78 from snickerbockers/virtual_core_file
40ec221c8a use virtual file i/o API which defaults to a stdio wrapper
git-subtree-dir: thirdparty/libchdr
git-subtree-split: e02b3d68eb759793ab8142376594c840c1194b3e
4de967acd0 Support memory moving of register pairs on x86 and arm.
git-subtree-dir: thirdparty/sljit
git-subtree-split: 4de967acd03499e7def404eab861e83a0689579b
The value of PC indicates the fourth byte (second instruction) after the
current instruction. The value stored when an exception raised does not
maintain this four byte offset. Consequently, the RTE instruction must
offset the value it reads back by four bytes.
ares was storing the offset value (and not applying one in RTE) and this
went unnoticed until an encounter with code that manually sets up an
exception frame (in an interrupt handler common to CD 32X games).
This change also fixes the PC stored in the event of an illegal slot
exception, which should be the delayed branch target.
The functional part of this change is just a few additional lines in
bus-external.cpp. The rest is refactoring to model the game cart as a
separate entity from the 32x, making it possible to delegate reads and
writes through the 0x900000... range to the cart implementation.
This fixes the corrupted menus and crashes in Golf Magazine: 36 Great
Holes Starring Fred Couples.
fc3121239 Update to 0f7cc6c3a13494a575dbbb977ff4424743b688d7.
d37cf0ed0 Update to 93dfb98643d0dd8094c5739300dfed818502304e.
d433bc4d2 Update to 93d77f713ba0fbcf6bb9e654924e89f808b04398.
22f03bb13 Update to 0f0f9446470f4d0aa018b88ff6280bbc4137b6f6.
482a41deb Update to 07c3d161dbeb78121be5eebdab7c810b72af822a
git-subtree-dir: ares/n64/vulkan/parallel-rdp
git-subtree-split: fc3121239716e3cd99ec63175c9ce5c9d088c033
* timing info based on Z80 netlist analysis by Floh
1. Corrected cycle counts for DDCB & FDCB prefixed opcode fetches (was 17, now 16). Instructions cycle counts were increased to compensate for the lost cycle, though this corrects wrong cycle counts for corresponding instructions without a DD or FD prefix (+1 cycle).
2. Removed redundant code for instructions fixed in 1.
3. Changed BIT instructions in DDCB & FDCB blocks to not modify registers (ref: "The Undocumented Z80 Documented").
* based on Z80 netlist analysis by Floh
1. Corrected cycle counts for EX (SP),rr (was 16, now 19) & IM n (was 12, now 8).
2. Reordered cycles for ADD/ADC/SBC HL,rr, RLD/RRD, & LD (rr),n.
3. Removed redundant code for CALL nn & IN (C).
While testing parallel-RDP on macOS via MoltenVK, I found out that
a special syntax used in the N64 Makefile to compile parallel-RDP
requires a version of GNU make which is newer than the one that comes
with macOS. To avoid confusion, just error out for now.
The presence of undefined behavior (in C++) revealed several
bugs in various shift and rotate instructions. These are
deceptively hard get right without resorting to iteration.
Rather than complicate the implementation further, a few more
are now implemented wtih loops like RCL/RCR.
The new code was completely wrong for interlaced resolutions, fix it
by changing into a simple filter on the current field.
Moreover, for some reason, the screen was only updated at 30fps.
Do it at 60fps, as both Vulkan and the native Ares screen knows how
to handle that.
There a handful of sequences of invalid commands that can
cause the RDP to crash (it will stop processing commands until hard
reboot). Mame RDP already knows about them and reacts by throwing an
exception, that currently kills Ares because it is not caught.
This commit lets Ares actually emulate the crashed RDP by basically
freezing its command processor. A log is also emitted on console.
This is useful to homebrew developers that can do mistakes while
coding.
from mooneye/acceptance/oam_dma_start
```
Expected timing (fresh DMA):
; M = 0: write to $FF46 happens
; M = 1: nothing (OAM still accessible)
; M = 2: new DMA starts, OAM reads will return $FF
```
The test still fails, likely due to bad restart behavior,
but it no longer hangs.
This should fix all games that had broken resolutions when not using
Vulkan. It also fix garbled graphics appearing on screen during scene
changes, usually at boot.
This pull request adds support for the Sega Mega Mouse. As the name implies,
this mouse was released for the MegaDrive, but as it is the case for 3/6 Button
controllers, the Mega Mouse can be safely connected to a Master System console and
even used, provided that the game software is programmed accordingly.
To my knowledge there are no official games on the SMS with mouse support, but there
is one demo I released (SMS-A-Sketch) which supports the Mega Mouse, and I have
an unreleased game that also supports it. I think it would be great to have ares
support the Mega Mouse on SMS as the only alternative at this point is to use
real hardware.
The VDPTEST still doesn't pass for any hcounter tests.
Inserting debug prints to print the hcounter value for every possible x coord shows correct output.
I suspect there are still some core timing issues in the z80...
At the moment, the game sees a controller in all ports, even after
the controller type is changed from Gamepad to Nothing. (the Gamepad
instance still lives and still gets called...)
I worked around this by making sure that port->allocate gets called,
even when the selection is "Nothing". The code in port.cpp simply
does not allocate anything in this case.
For most systems and in most practical cases this probably does
not matter. But now the raphnet N64 adapter manager ROM correctly
reports "Not conneted" in ports set to Nothing.
When the ->comm method returns with the invalid bit set, it means no
data was received. This happens for instance when sending invalid
or proprietary commands to a standard controller which does not answer.
When there is no answer, the PIF emulation code sets bit 7 of the receive
length byte to flag this error.
Since no data was received, the original (filler) bytes should be left
as-is in PIF RAM. This is what the hardware appears to do.
This fixes code that checks if the receive buffer got overwritten instead of
inspecting bit 7 for errors.
Ideally I think one should not need to read the source code to learn
that ares accepts command-line options and what those options are.
I wish I had known earlier that I could pass --system MSX when loading
a ROM directly, it would have saved me a lot of time. I had tried --help,
but it just opened the application window...
Many specializations of stringify store a reference to the wrapped
value. Therefore, passing arguments to make_string() by value can be
disastrous if the compiler does not perform copy elision and stringify
stores a reference to a variable that goes out of scope when
make_string() returns.
Detect build environments where 'g++' is just an alias for 'clang++'.
Example: MSYS2's Clang64 environment. This avoids the need to manually
override compiler detection.
Master system ports are compatible with megadrive controllers and
those can be used directly to play many original master system
games.
However MD controllers can be fully supported (i.e all buttons
working) if the game software is programmed to do so.
While really only useful on real hardware, there are game patches to
enable the Start button on MD controllers. But it's also possible
to make patches that use additional buttons or code full support
for Megadrive controllers in a homebrew title.
The N64 and PS1 cores set custom Screen:refresh() callbacks that run on
the video thread and have meaningful dependencies on core state. It's
not safe to unload components from beneath them, so the video thread
should be stopped before any unloading occurs.
ares uses nall::thread with the assumption that calling join() multiple
times on the same thread will have no harmful effects. This was true of
the Windows implementation but not of the POSIX one.
mia cannot save a file when the manifest size is zero.
instead, use the largest known eeprom size + 1 as a default.
The +1 signifies that we should auto-detect the real size of the eeprom
and the large size makes sure mia creates a file on disk large enough.
For games without a database entry, the eeprom size be larger on disk
than is actually used, but it's better than completely broken saves.
Note that even with this, some games will require database entries,
but most should work now.
This prevents slowdown in games that poll games multiple times per-frame.
5ms was chosen as ares already has a 5ms limit higher up the chain.
For me, Advanced Wars 2 (GBA) jumped from 50-55fps to 65-68 with this change
Following the precedent set by the SFC performance PPU, override the
timing of the PCE performance VDP for a handful of problematic games.
All of these games already work fine with the accuracy VDP (enabled with
the "pixel accuracy mode" video setting) which does not and never will
contain contain game specific logic.
Affected games:
- Kore ga Pro Yakyuu '89
- Kore ga Pro Yakyuu '90
- TV Sports Baseball
- TV Sports Football
- TV Sports Hockey
- Valkyrie no Densetsu
- Victory Run
- The primary lookup table is direct addressed
- The secondary lookup table is indexed by hash of code block contents
- IMEM invalidation is tracked at 64-byte granularity and used to
evict primary lookup table entries
- The secondary lookup table is only pruned on a full code cache flush
- Only executed instructions are hashed, so the code cache no longer
experiences unbounded growth
- Code blocks can now wrap around the end of IMEM
- generic::recompiler now supports aborting recompilation (required by
by an earlier version of this change)
On MSX, both joysticks are read through a common port (PSG port 14).
Which joystick is being accessed is selected through bit 6 in PSG
port 15. In other words, the ports inputs are multiplexed.
This pull request adds a simple concept of controller multiplexer
which the PSG IO code can call whenever port 14 is read.
PSG port 15 also controls the level and direction of some joystick
pins, but those are not multiplexed. This pull request corrects how
writes to port 15 are handled and organizes output bits in a predefined
order so controller implementation do not need to know which port they
are connected to. This paves the way for more advanced peripherals
controlled through those outputs, such as the Taito Arkanoid Vaus Paddle.
This adds support for the Sports Pad, a trackball controller for Master System. Input
is done using a Mouse or a trackball (best).
Tested with Sports Pad Soccer and a homebrew test ROM.
The write method is now actually called when TR/TH level and direction
IO port is written to. Also redefined the write method bit width (4) and
document which bit is used for what.
This will allow emulation of controllers which uses the TH line as a
control output. This includes the Export Paddle, the Sports Pad, and
Megadrive controllers.
When the mouse is grabbed, the current implementation hides the
pointer and centers it on the screen.
When the mouse is polled, its relative motion is determined by how far it
has moved from the center of the screen, then it is moved back to the
center by calling XWarpPointer().
XWarpPointer generates an event resulting in an additional poll, which then
sees no movement at all (since the pointer is now centered) and therefore
resets the relative motion values to zero.
If the above reset occurs before the controller code has had the chance to
access the relative motion values, the motion never reach the game. This
works around this issue using a flag to ignore the next event if the
mouse is still centered on the screen.
1. Nametable address is not a latched register, it takes effect immediately
2. Sprites should still be processed & overflow is still set during display disable
3. Hcounter -94 offset is incorrect for ares, as we already have clock 0 = pixel 0.
Despite the Game Gear having no physical controller ports, writes to the IO control register still need to be emulated, and thus the ports need to be present in ares, such that latching h-counter on 0-1 transition is still possible.
Internal Hcounter values (actually clock cycles) are larger than the range of a u8.
The actual Master System h-counter (0x00-0xff range) is calculated later.
1. ram is mirrored between 0xa000-0xbfff, not 0xa000-0xa1ff
2. ram & bank registers are mapped through 0x0000-0x3fff, using only bit.8 to select between them
1. Grouping systems by vendor in the system menu can no longer be disabled.
2. It is no longer possible to hide emulator cores from the menu
3. It is no longer possible to use the higan file select dialog; only the native OS file picker is available.
This makes games requiring a Paddle, such as Megumi Rescue,
playable with an analog stick, or using adapters USB adapters
supporting the HPD-200 Paddle.
"Prefer Japan" should be selected in tools->Boot Options before load
otherwise the game will expect the "Export Paddle" which is not
compatible.
Checking for libraries in /usr/lib does not work reliably, e.g.
on a x86-64 Gentoo the 64-bit libraries are located in /usr/lib64.
Use pkg-config to detect libraries, which should work much better
on any modern Linux distro and also covers Debian's multi-arch
setup.
Using a native data type significantly improves performance of ares::Nintendo64::RSP::instructionEpilogue, making it jump from ~9-10% of cpu time to 5-6% of cpu time during execution
045f2a7f2 Merge pull request #74 from 2weak2live/raw
e23f32f37 Add support for reading LZMA and FLAC hunks in non-CD CHDs.
git-subtree-dir: thirdparty/libchdr
git-subtree-split: 045f2a7f23f5ac10c0122f6f56e42023dfb71e2a
7c37b7ebc Rework x86-32 stack layout
09a58361f Improve sljit abi calling convention
58e36c06a Change skip checks to a macro
ac445a3ef Add sljit specific register argument calling convention
a6c8e5bf7 Remove fast call support on x86-32
a3785b330 Fix x86 mem address encoding
2f8e5c2f2 Implement ARM unaligned support
3e86c50e9 Fix PPC logical or/xor with flag set
d8af3f91b Remove sparc support
3055f116b Fix test50 alignment
41cb888d8 Start supporting unaligned memory access
git-subtree-dir: thirdparty/sljit
git-subtree-split: 7c37b7ebcf17a80f606100ae88e744dff22befe6
because Ubuntu 20.04 still has outdated GCC that doesn't support this flag;
people who get a performance hit from optimising for nehalem will just need to
self compile.
This reverts commit f7657dca4f.
The AI IRQ should be generated when a buffer starts playing, not when
it finishes playing, as verified by hardware tests.
Fixes the audio in Hey Pikachu and possibly other games.
This commit introduces preliminary Atari 2600 emulation.
In the current state, many games are working but with the following caveats
1. Only a small subset of mappers are supported
2. The TIA isn't cycle accurate yet; many games have rendering and/or collision issues.
There is currently little-to-no reason to use this over other Atari 2600 emulators at this time,
but the goal is to eventually have cycle-accurate atari emulation.
The exact behavior of the freeze bit hasn't been investigate yet, but
at the very least it stops the RDP command engine. This PR does a
basic approximation of it, pending more in-depth tests.
Fixes Banjo-Tooie.
It looks like address exceptions and TLB exceptions always set the
same registers (though some are marked as undefined in the manual), so
we unify the two implementations.
Fix several tests in n64-systemtest.
There's a big confusion in the CPU core between virtual and physical
addresses, and we have been fixing many bugs around this. Now that the
situation seems stable, do a big sweep and rename all "address" variables
to "vaddr" when they refer to a virtual address, to simplify reading
the code.
"address" is kept for physical addresses, which is consistent to the
rest of the code outside the CPU that only talks about physical
addresses anyway.
No functional changes.
This commit do further fixes 64-bit addressing. In 64-bit mode, the bus
addressable range is 2Gb (instead of 512Mb), so we need to mask
appropriately all physical addresses.
Fix several tests in n64-systemtest.
This begins improving the RDP status bits to more accurately reflect
what it can be seen on real hardware. It also undoes a hack for RDP
freeze that was allowing Banjo-Tooie to boot. Being a game-specific
hack, I think it is better to simply disable and wait until we find
out how to properly fix the game.
Fix a few new tests in n64-systemtest.
This one is the weirdest. The current implementation is unrolled, but
I can't find a pattern that works. Surely there must be one as the
hardware doesn't surely have a lookup table. Anyway for now this
implementation is completely accurate, albeit verbose.
Fix one test in n64-systemtest
On real hardware, LWL/LWR execute a SysAD 32-bit masked read. Ares
was emulating them with one or multiple shorter accesses, which is
not the correct behavior wrt RCP hardware registers and PI bus area,
where the RCP incorrectly ignores the access size causing several bugs.
After this commit, LWL/LWR always do a 32-bit access on the bus, which
makes sure that we replicate the exact behavior.
SWL/SWR have a similar problem but harder to fix, because the SysAD
bus can do 24-bit writes, which is not something that Ares memory
functions support. So that's for another day.
This fixes a bug in mame RDP with respect to scissoring: the upper X
bound is inclusive in copy and fill modes (and exclusives in the others).
This seems another bug in Mame's refactorings that doesn't appear
in upstream angrylion, given the fact that both cen64 and parallel-RDP
emulates this correctly.
Also adding in protection against another bad shift case. Can't use the same code here though... could avoid the branching if it can be safely assumed _addressBits is always at least 3
329a8c9 had a bug: it moved the queue.insert line *after* dmaWrite;
but dmaWrite updates the io.writeLength to its post-transfer status,
so the calculated timing was incorrect.
Fix the regression in Cruisin' Exotica and possibly others.
Luckily enough, n64-systemtest triggered an interesting bug in our
RSP recompiler: a hash collision of the IMEM contents. The used hash
is objectively very poor so a collision is well possible.
Switch to CRC32 that should be enough to our scope.
The idea of doing a full IMEM hash is probably a bit weak to begin with,
but that's for another time.
Fix a new test in n64-systemtest (that only failed because of this).
This change implements RSP DMA double buffering in a more faithful
way, so that reads from the registers always return the current values
(ongoing transfer or finished transfer) rather than the pending ones.
Moreover, this also makes Ares transfer bytes in background a row at
a time, rather than all of them at the end. It is a bit more accurate,
and it was also easier to implement in the new architecture.
This also fixes several tests in n64-systemtest.
Ares used to have full 64-bit TLB support but it was removed at some
point because of some wrong testing that apparently made us believe
that the CPU didn't support that mode. It will have to be restored from
the git history in the future, though it's not very urgent because
nobody is using 64-bit pointers on N64 (there is no toolchain with
64-bit pointers, nor it seems useful).
Luckily, at least the segment parsing was left in and just commented out.
This allows to pass the last two remaining tests in n64-systemtest.
761d48d2b Improve constant generation
1f32a9f23 Implement fpu operations for RISC-V
ad99f17a9 Improve x86 float compare
fb55788d0 Initial implementation of RISC-V port
7f08de6ff Improve jump code generator on MIPS
469c61db9 Improve mips code generator
a4e8e34ef Support unsaved registers on s390x
f404f3608 Support unsaved registers
88d4778b9 Add license file
160b6f99d windows: fix building in arm64 with clang (#126)
022482eeb wxexec: officially drop support for EOL NetBSD < 8 versions (#124)
beda74f07 Support reworked floating point compare on s390x
050215b22 Remove unnecessary checks
6b950049d Improve floating point compare.
6ace72c90 windows: allow building with MinGW64 gcc/clang (#125)
186b07064 mips: avoid sign conversion warnings with clang (#122)
e0b17f5a6 macos: fix recent regression breaking build in macos/arm64e (#121)
68d9b4bac misc: mostly to avoid warnings (#120)
76330309a Update s390x.
6807c7a8f Remove SLJIT_NEG.
ca530a4a7 Readd carry flag support.
5f60134b5 s390x: be explicit about cache coherence needs (#119)
75a555604 power: avoid bogus clear_cache builtin in gcc >= 10 (#118)
1448ef97c sparc: avoid NOP implementation for clear_cache with gcc (#117)
ad69ad87b sparc: build fixes (#116)
47646b943 Support incoming arguments in scratch registers for s390x.
4fbdd6953 Support incoming arguments in scratch registers.
86ebfbd50 Rework x86-32 function prologue/epilogue.
2f8cf7a08 Increase the number of floating point registers on ppc, mips, and sparc.
2737606ee Increase the number floating point registers on s390x.
03469c8e1 Rename tail call to call return and minor ARM improvements.
7cb8a5c24 Increase the number floating point registers on x86 and ARM.
b35ab5e7e Implement fpu support on s390x.
dcc8fc149 misc: fix -Wextra related errors (#114)
92fcb0fe5 Fix fallthrough errors.
d345a64b3 misc: build/documentation fixes from recent changes (#113)
ff6ec4f74 Implement tail call on MIPS.
eed28632f Implement tail call on ARM.
d7793570f Reduce signed comparison warnings.
30b2dcd83 Reduce value conversion warnings on s390x.
c783c1119 Reduce value conversion warnings on MIPS, PPC, SPARC.
335ee51f5 Reduce value conversion warnings on ARM.
8d0f668fa Improve value conversion warnings.
373163144 Implementing tail calls for x86.
9c8b6961b Improve argument sanity checks.
24c547b7e Swap f32 and f64 argument types.
7f0afb25e Rework function argument list descriptor macros.
585ac42bf Implement four argument support for emit enter.
b5e0b1234 Improve mov32 operation.
433294658 Fix incorrect function call (#112)
cf594d74d Change SLJIT_I32_OP and SLJIT_F32_OP to SLJIT_32.
ae5fff841 Improve arm code generator.
43538b877 Replace SLJIT_UNUSED with appropriate function calls.
git-subtree-dir: thirdparty/sljit
git-subtree-split: 761d48d2b89a048badbd9c5cf45da75336891cfe
When an exception happen in a delay slot, it behaves the same whether
the branch was taken or not. In Ares, instead, the state "delay slot"
only applied to taken branches.
Fix several tests in n64-systemtest
These timings actually depend on the PI registers, even though they
are almost always set to fixed default values. We will get there
eventually and provide a more accurate figure, but for now this
allows to pass timing tests in n64-systemtest so that it can't be
more wrong than before.
A last minute change in 741320e0be introduced a regression in controller
input.
Similar to what we did with PI DMA, SI DMA does not go through the main
bus (SysAD bus) but directly communicate with pif and rdram. This is not
just for the sake of correctness, but SysAD bus half-word writes are
now emulated with the same brokeness they have on real hardware, and
obviously DMA works instead. Moreover, since SI only reads/writes
32-bit words, also switch to word access.
Currently, Ares does not model the PIF chip on its own: it looks like
there was an original mistake that conflated the PI (peripheral
interface, one of the components of RCP) with the PIF-NUS (a separate
chip, connected to SI component of RCP via a serial bus).
This refactor introduces a PIF class and moves all the related code
into it. Since the class implements the Memory::IO protocol for memory
accesses, it also fixes memory accesses with non standard sizes, as
tested by n64-systemtest.
There is a bit confusion of virtual vs physical addresses in Ares,
so dcache/icache were sometimes using a virtual address, sometimes
a physical one. This is wrong: cache is based on physical addresses
only.
Moreover, the CACHE opcode was not even going through TLBs, while it
should. So a CACHE opcode on a TLB-mapped address wasn't working before.
This bug has always been there, but was hidden by the incorrect TLB
matching logic. After fixing the logic in 0bf24b3, this bug was
uncovered.
Fixes Goldeneye.
All writes through the PI bus are actually performed asynchronous by
the hardware, and the status is reflected in the PI IO busy bit.
This commit emulates this properly, and also emulates what happens while
the busy bit is set: further writes are ignored, and reads at any
address return the word being written.
This fixes A Bug's Life and Toy Story 2.
This is a revert of 56458d5b, while keeping b7f96b7109 which is the
real fix that should have been done all along. The former just papered
over the issue and actually introduced a regression (Goldeneye wouldn't
boot).
Co-Authored-By: remutro <[email protected]>
Also take the chance to remove the "hopefully accurate but then not
really" implementation which runs after every instruction in favor
of a real random.
Fix one test in n64-systemtest ROM.
PC register in VR4300 is 64-bit but there were many places where
the register was incorrectly treated as a 32-bit one, effectively
discarding the higher half.
Fix several tests in n64-systemtest ROM.
To get clean makefile targets working robustly under a Windows command
prompt, allow the entire contents of obj/out directories to be deleted.
They are now recreated by the build as needed.
Replace uses of Bourne shell commands (cp, mkdir) with shell-agnostic
versions that work from a Windows command prompt. Some Bourne shell
commands still remain in macOS and Linux specific makefile lines.
using `type` results in compiler warnings: `warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead)`
Was informed by merryhime that `typeStr` was probably intended.
The N64 core was forcing -msse4.2 for compilation of the whole Ares.
On host PCs without SSE 4.2, Ares would crash at startup with SIGILL
because GCC used SSE 4.2 instructions even in hiro, while building up
the UI.
RSP SIMD emulation requires SSE 4.1, but the solution here is to
fallback to SISD if SSE 4.1 is not supported. This can be checked
with a predefined macro, that will be set by GCC. We do compile with
-march=native, so this will reflect the host PC of the build process.
For non-local builds (eg: official CI builds), default to nehalem
(Core 2) which is the first architecture with SSE 4.1.
Since this is yet another compile-time flag that affects the N64 core
performance, add a status message warning if SIMD is disabled.
Fixes#193
This is because C-BIOS has significant compatibility issues, including
the ability to boot any software that uses BASIC.
The MSX2 emulation is still too preliminary to be able to boot the
official bios, so msx2 will continue to use C-BIOS for the time being.
Replace the large, inner circular dead-zone of the N64 control stick with a small, inner square dead-zone; separate the inner and outer dead-zones; attach the scaling equation to the outer dead-zone; fixes https://github.com/ares-emulator/ares/issues/86 .
Nintendo 64 homebrew community is standardizing on a convention to
declare the save memory type as a header flag. This convention has been
first introduced by EverDrive 64 as a way to handle games not present
in their DB, but it's been since adopted by libdragon as well.
With this commit, Ares will automatically configure the correct savetype
for homebrew ROMs using the special header flag.
This is implemented via a 'keyboard capture' hotkey; this ensures that
users can switch between keyboard & gamepad emulation, even if they have
no physical gamepad.
When keyboard capture is enabled:
- All non-hotkey key-presses are translated and dispatched to the guest
- Virtual GamePad Inputs that are mapped to Keyboard no longer trigger
- Virtual GamePad inputs that are mapped to Mouse or physical GamePads work normally.
Nearly all state is initialized to a fixed or random value during
power-on, though a few things are deliberately left alone on soft reset.
A handful of fields weren't being initialized at all, save for the zero
initialization that occurs during process creation. This state would be
persisted from one ROM load to the next.
This fix is intended to address 32x PWM audio eventually going silent
after switching between multiple roms.
- vtick() shifted; can't be any later w/o breaking due to render alignment
- vblank flag update moved to vtick(); also updated on v28/v30 switch (per ekeeke's note re: Kabuto's findings)
- corrected apu irq timing
- readded extra refresh slot when display is disabled (confirmed after latest timing fixes)
ares v127 brings significant improvements to Mega Drive and Nintendo 64
emulation, as well as improvements to NES / Famicom and SNES / Super Famicom.
Other than the usual emulation improvements, there have been the following notable
changes:
**Apple Silicon Support**
ares v127 fixes the recompiler for aarch64 architecture, meaning that it is now
possible to create Apple Silicon/M1 native builds, without relying on Rosetta
and without losing support for the high performance JIT recompilers.
In order to be Apple Silicon Native, it is currently required to compile ares
from source code as automated builds have not yet been configured, but users
who wish to do so will no longer lose functionality or suffer poor performance
as a result.
**MAME RDP**
ares's Nintendo 64 core uses paraLLEl-RDP by default; this brings fast and
accurate RDP emulation as long as Vulkan is present on the users machine; this
meant that Nintendo 64 emulation was completely broken for all configurations
without Vulkan support, including macOS.
ares v127 adds support for MAME's RDP implementation as a fallback, allowing
Nintendo 64 emulation to be used when Vulkan is not present. This is handled
automatically, however, a new option has been added to video settings to allow
Vulkan support to be toggled, giving all users the ability to test the MAME
RDP, if they wish to do so.
Although MAME RDP is now an option, paraLLEl-RDP is still the recommended
choice, for both performance and accuracy.
**Pixel Accuracy Mode**
ares has contains two implementations of some of our emulated hardware; one
optimised for performance, and another optimised for accuracy.
Historically, the choice of which path to use has never been exposed to the
user; higan *always* used the 'accurate' profiles, with ares always opting for
the 'performance' profiles; any user wishing to change this would be required
to compile ares themselves from source.
As of ares v127, we now provide a new option in the emulator settings: "Pixel
Accuracy"; when this is enabled, any emulator core that supports a pixel
accurate mode will use it.
For 99% of games, the default fast profiles will be sufficient, but enabling
"Pixel Accuracy" allows games that require mid-scanline effects, such as the
infamous "Air Strike Patrol" to function properly.
The following systems are currently support the Pixel Accuracy setting:
* NEC - PC-Engine / TurboGrafx
* Nintendo - Super Famicom / SNES
**Changelog:**
* desktop-ui: hook up pc-engine 6-button pads to virtual pads [Luke Usher]
* desktop-ui: implement frame advance [Luke Usher]
* fc: add bus conflicts to cnrom [encoded-byte]
* fc: check for ram on mmc1 [encoded-byte]
* fc: check if ram exists on mmc3 [encoded-byte]
* fc: clear oam address on each scanline [encoded-byte]
* fc: improve mmc3 irq behavior [encoded-byte]
* fc: improve ppu skipped clock timing [encoded-byte]
* fc: use hkrom for mmc6 [encoded-byte]
* m68000: allow recovery from zero divide [TascoDLX]
* m68000: reimplement DBcc instruction with correct timing[TascoDLX]
* md: A few fixes to SRAM save game [rasky]
* md: correct overscan / output when display is off [TascoDLX]
* md: correct reads of CRAM and VSRAM [rasky]
* md: detect region 'K' as NTSC-J [invertego]
* md: fix APU port in [rasky]
* md: fix debug register sprite masking [rasky]
* md: fix high bits in control port read [rasky]
* md: fix misaligned reads from VRAM [rasky]
* md: fix register masked write in mode5 [rasky]
* md: fix vblank bit toggling horizontal timing [rasky]
* md: fix VSRAM out of bound accesses [rasky]
* md: ignore erroneous device string used by Codemasters [invertego]
* md: implement undocumented VDP VRAM 8-bit reading mode [rasky]
* md: persist VDP state on reset [invertego]
* md: restore vdp free slot lost to refresh [TascoDLX]
* mia: Correct save type for Premier Manager 64 (N64) [sp1187]
* mia: Correct save type for Transformers: Beast Wars Transmetals (N64) [sp1187]
* mia: correct type for pak attribute [encoded-byte]
* mia: fix 32x sram [Luke Usher]
* mia: properly pass MD eeprom details to ares [Luke Usher]
* mia: updated famicom database [encoded-byte]
* mos6502: add illegal nops [encoded-byte]
* ms: correct overscan inc. dynamic screen resizing [TascoDLX]
* n64: add MAME RDP as a fallback for parallel-RDP [invertego]
* n64: allow vulkan to be disabled [Luke Usher]
* n64: change PI DMA to use 16 bit fetches [CasualPokePlayer]
* n64: fix mult/div opcode timings [rasky]
* n64: fix RSP halt condition to be more accurate [rasky]
* n64: fix several RDP regressions [invertego]
* n64: fix small bug in VMACQ [rasky]
* n64: fix SRA/SRAV opcodes [rasky]
* n64: fix vulkan detection [Luke Usher]
* n64: improve rsp recompiler pool allocation [invertego]
* n64: swap RSP/RDP order [CasualPokePlayer]
* n64: templatize rsp vpu [invertego]
* n64: vulkan tweaks [Luke Usher]
* nall: fix many compilation warnings on macOS [Luke Usher]
* nall: fix page protection on Apple silicon [invertego]
* nall: rewrite recompiler for machine-independence using sljit [invertego]
* pce: runtime pixel accurate VDP setting [invertego]
* sfc: fix horizontal off-screen test for sprites [jbo-85]
* sfc: fix missing sprite tile on Super Conflict title screen [jbo-85]
* sfc: fix missing sprites in Jurassic Park that are partly offscreen [jbo-85]
* sfc: runtime pixel accurate PPU setting [invertego]
* sh2: move registers into POD struct [invertego]
Some systems in ares contained two implementations of video hardware;
these systems were Mega Drive / Genesis, Super Famicom / SNES, and
PC-Engine / TurboGrafx 16.
For the Mega Drive, we switched to the accuracy core quite some time ago,
SNES and PC-Engine we were still using the performance core.
Going forward, we wish to only maintain the accuracy focused renderers.
VDP always writes transparent pixels to the internal sprite buffers,
overwriting previous transparent pixels; then the first non-transparent
pixel sticks and wins. This implementation detail only reveals itself
when sprite plane masking is activated using the VDP debug register:
in that case, the palette number of transparent pixels concurs in the
AND of the visible pixels, and thus the correct palette number should
be found in the buffer.
Fixes the logo effect of Overdrive 2 (ref #255)
After more analysis, it looks like the correct thing to do is to
check for vblank status on most of the raster line. Kabuto's doc says
that it is possibly to switch from V30 to V28 during line 224 and
still see the vblank triggered, which suggests that the hardware does
actually check it on most of the time.
This seems to fix#402 and does not seem to cause any immediate
regression in timing-sensitive ROMs.
Currently, the vblank bit is turned on/off at the same time vcounter
is incremented, which is a reasonable assumption, missing any real
data on this.
But it turns out this is responsible for most of the breakage of
Overdrive 1. I did some tests and it looks like anything in the
range >= 0xF0 (same line), or <= 0x80 (on next line) fixes those bugs.
I decided to bind it to vedge(), which means that vblank bit now is
triggered the same instant that VINT is raised, which also makes sense
when you think of it.
Updates #212
VRAM misaligned addresses were implemented with partial slot reads.
This seems to be wrong, as proven by vdpfifotesting: once the slot is
read, the whole word is invalidated.
VSRAM is actually made of 40 11-bit words, though the chip only accesses
the first 10 bits. The top bit on each word is still readable and writable
though, so they should be emulated.
Also, reading at addresses >= 40 returns a copy of the first word,
rather than 0.
Mode5 (SMS compatibility mode) is unsupported and mostly undocumented,
but the vdpfifotesting ROM at least checks one know behavior: non-SMS
registers can't be written.
Bits 10-15 in control port read (aka status register) are not fixed
as found in some online docs, but they are actually an open bus
that returns the instruction prefetched by m68k at that cycle.
* Allow MIA to declare address for mapping (typically from ROM header)
rather than hardcoding 0x200000.
* Autoenable SRAM if the ROM size is smaller. Also make the ramEnable
I/O conditional to the same layout.
* Add MIA entries for NBA Live 98, NHL 96 and NHL 98, which have a 8-bit
SRAM not declared in the header.
Using the read<Byte> currently in use breaks DMAs from Flash (breaking Paper Mario, probably others), which always return 0. I assume 8 bit reads are just not allowed for Flash, although I can't verify this myself.
Checking https://github.com/n64dev/cen64/commit/8367698e20cca7eb262779f19c8c7847ae31bb29, it seems that fetches should always be 16 bits anyways, so I presume this is the correct behavior, and fixes DMAs from Flash.
No regressions with the original testrom have occured.
- introduce a status api, so cores can report status messages to the UI
- avoid calling vulkan-related functions when vulkan is disabled
- show status messages so the user is aware of what RDP implementation is active
- Disabled 'loaded' status message, it prevented the Vulkan messages being shown
Update the stack base and limit in the thread information block. This is
required to support kernel stack unwinding, which is used for both C++
exception dispatch and setjmp/longjmp on Windows x64 and ARM64.
Add a cothread entry routine that consistently aborts when the user
supplied routine returns. Debugger stack backtraces now stop
consistently at this entry routine.
The Korean release of Tiny Toon Adventures specifies its region with a
'K' and, like several other Korean releases, is region locked to
Japanese consoles. It may be the only one with a 'K' specifier, though.
Taken from NEC VR4300 manual. These are easier than expected to
implement accurately as the CPU doesn't execute them in parallel but
stalls the entire pipeline while they are running.
Real hardware testing showed that VMACQ does not modify the accumulator
if it is exactly zero. Fix it.
Also remove two "unconfirmed" comments which I have personally verified.
* Fix usage of break opcode in a delay slot. After unhalt, the
RSP continues execution, taking the jump if needed. So the
branch state should not be affected by the break opcode.
* Reading from SP_PC produces garbage (open bus?) when the RSP is
running. This fix is unlikely to fix game but may help homebrew
developers.
* Writing to SP_PC resets the RSP MIPS pipeline, so any pending branch
is canceled.
The existing implementation was allocating pools in the code cache only
to copy them to the heap. This was wasteful on multiple counts: the
space in the cache would go unused until the next allocator flush and
the data copied to the heap consisted almost entirely of zeroes. Best of
all, writing the hash code to the code cache was triggering a page
protection fault on Apple M1.
A small data structure refactor avoids the heap allocations, the copies,
the wasted space in the code cache, and the page protection issue.
For systems that do not meet parallel-RDP's Vulkan requirements, use the
pure software RDP implementation from MAME as a fallback.
All of the source files taken from MAME are either BSD-3-Clause licensed
or public domain. Edits were kept to a minimum and guarded by ifdefs to
ease future integrations.
- when dynamically allocating executable memory, use VirtualAlloc/mmap()
for finer control over allocation flags (like MAP_JIT on macOS/arm64)
- toggle JIT memory protection around writes on macOS/arm64
- reduce recompiler code cache sizes to improve likelihood of dynamic
allocations being close to ares image (affects branch perf)
- remove arch x86_64 override on macOS non-local builds; native arm64
builds should now be at feature parity with x86_64
- sh2: prevent pollution of code cache with empty pools by invalidate()
Games tested so far. Two new not working games discovered:
- Aladdin (Europe): Hangs after starting game
- Wizards & Warriors (Europe): Graphicals glitches on HUD, severe slowdowns. PAL timing related?
For some users, this gives a dramatic performance boost, and finally
brings the Windows builds in-line with Linux/Mac builds in terms of
performance.
This technically goes against the Win64 ABI, which demands that SSE
registers are saved, however, in-practice, our testing has shown that
this has not caused any issues so far.
On Windows, track WM_SETFOCUS and WM_KILLFOCUS messages to determine
focused status rather than polling with GetForegroundWindow(). The
latter involves a syscall and causes noticeable slowdown when called
repeatedly, such as when GameBoy games poll joypad status in a loop.
Fix unloading systems with light gun peripherals active. The code
responsible for removing crosshair sprites was dereferencing a null
pointer. This cleanup now occurs in Screen::quit() when unloading.
Instead of just reading the first file from a zip archive, prefer files
that match known rom extensions. Extra files such as readmes should not
interfere with the loading of the game.
Fix several correctness bugs in SH2 instructions in both the interpreter and
recompiler and switch the default implementation from the cached interpreter to
the recompiler. This brings the 32x games BC Racers and Zaxxon's
Motherbase 2000 to playable status. Fixed instructions:
Interpreter
- ADDC Rm,Rn
- ADDV Rm,Rn
Recompiler
- MAC.W @Rm+,@Rn+
Both
- CMP/STR Rm,Rn
- MOV.B Rm,@-Rn
- MOV.W Rm,@-Rn
- MOV.L Rm,@-Rn
- NEGC Rm,Rn
Improves thread-switching performance using the following techniques:
- Interleave stores/loads
- Restore the stack pointer and link register as early as possible
The calling convention specifies that d8-d15 (the lower 64 bits of
vector registers q8-q15) are callee-saved. However, libco was
erroneously saving and restoring general-purpose registers x8-x15
instead.
Ares JIT recently started to require the data segment to be executable
(see https://github.com/ares-emulator/ares/pull/200 for details on why
this was done instead of allocating a new segment via mmap).
To do this, it uses mprotect() (bump_allocator::resize), but it also
needs to tell the linker that the data segment can be upgraded to
executable with -Wl,-segprot,__DATA,rwx,rw (nall/GNUmakefile).
Unfortunately, for quite some time, the clang LD had a bug and didn't
accept that option for the data segment.
The official CI has a newer linker without the bug, but for developers
compiling ares with an old toolchain, this small tool will patch the
binary to mark the data segment as potentially executable.
This change upgrades GCC from the version preinstalled by GitHub Actions
(8.1.0) to the latest MSYS2 version (10.3.0). It also adds a
Windows/Clang build configuration, though the release job still
grabs the GCC build.
ares v124 brings the compatibility rating for the Famicom and Nintendo 64 cores
up to three stars. This means that at least 80% of the game library is working.
There have been notable improvements to Game Boy, Mega Drive, Sega Mega CD,
Sega 32X and Nintendo 64 emulation, and the PC-Engine multi-tap is now supported.
Finally, the dynamic recompiler now generates slightly more efficient code. You
may notice a slight performance boost in Nintendo 64, Sega 32X and Sony
PlayStation.
**Changelog:**
* Famicom: Add support for Jaleco JF11/JF14 mapper [Shideravan]
* Game Boy: Bring fast-boot closer to normal boot; Fixes Dr. Fraken [invertego]
* Game Boy: Use stable sort for sprites; fixes speech bubbles in Crayon Shin-chan 3 [invertego]
* Game Boy: Remove limit on window width; fixes pause screen in Heiankyo Alien [invertego]
* Game Boy: Emulate serial transfers with no link; fixes input in Alleyway [invertego]
* Game Boy: Improve handling of LCD/BG enable for DMG; fixes Hyper Lode Runner [invertego]
* Game Boy: Resume from halt whenever (IE & IF) != 0; fies Amazing Penguin [invertego]
* Mega Drive: Fix DMA transfer rate and H-Int signalling; fixes Another World, 3 Ninja's Kick Back, Virtua Racing, Burning Force [TascoDLX]
* Mega Drive: Fix sprite masking and overflow; Fixes Mickey Mania [TascoDLX]
* Mega Drive: Fix DMA fill; Fixes Demons of Asteborg [TascoDLX]
* Mega Drive: Fix VRAM byte addressing; Fixes Contra Hard Corps, Musha [TascoDLX]
* Mega Drive: Fix VDP control port writes [TascoDLX]
* Mega Drive: Implement HV Counter Patching [TascoDLX]
* Mega Drive: Implement STOP instruction; fixes Thunder Force IV [TascoDLX]
* Mega Drive: Default to 3-button gamepad; fixes games that don't support 6-button pads [Shideravan]
* Mega Drive/Mega CD: Fix detection of device rom header; allows Mode-1 to work [Luke Usher]
* Mega CD: Fix word-ram 1M access pattern; Fixes Lethal Enforcers II [TascoDLX]
* Mega CD: Fix H-Int vectoring; Fixes Microcosm, Silpheed, Wing Commander, and others [TascoDLX]
* Mega CD: Implement full graphics/1M wordram translations; fixes Rebel Assault [TascoDLX]
* Mega 32X: Tighten M68k sync; Fixes Kolibri and Fifa 96 [TascoDLX]
* Neo Geo Pocket: Fix off-by-one error in LDAR instruction; fixes a crash in SNK Gals' Fighters [invertego]
* Nintendo 64: Support controller ports 3 & 4 [LukeUsher]
* Nintendo 64: Better Flash Ram support; Fixes Majora's Mask, Paper Mario, Derby Stallion 64 [jeltaqq]
* Nintendo 64: Add mempack/rumble status to database; eliminates controller pak/rumble pak warnings [remutro]
* Nintendo 64: Consume cycles to compensate for skipped RDRAM initialization; fixes Wave Race 64 Shindou Pak [invertego]
* Nintendo 64: Fix PIF RAM init on cold boot, preserve RDRAM on warm reset; fixes Perfect Dark boot [invertego]
* Nintendo 64: Default to 3 controllers for Jeopardy!, this game doesn't work with 4 controllers, even on hardware [invertego]
* Nintendo 64: Fix FPU compare and divide exceptions; Turok is now able to play the entire Acclaim logo animation [invertego]
* Nintendo 64: Decrease SI DMA delay; improves Turok, Donkey Kong 64, Forsaken 64, Hercules, Triple Play 2000 [invertego]
* Nintendo 64: Implement perfect PI DMA write [rasky]
* PC Engine: Support Multi-Tap [LukeUsher]
* TMS9918: Widen vcounter to 9-bits; improves ColecoVision, SG-1000, MSX [invertego]
* desktop-ui: Support up-to 5 virtual controllers (For PC-Engine) [LukeUsher]
* desktop-ui: Fix window background with GTK3 [ghisvail]
* desktop-ui: Install icons in freedesktop compliant locations [ghisvail]
* desktop-ui/hiro: Improved macOS user experience [LIJI32]
* ruby: Fix conflated keys on Windows; fixes some keyboard input issues [invertego]
* nall: Use XDG base directories on *nix systems [ghisvail]
* shaders: Include a selection of public-domain shaders [LukeUsher]
* ares: Fix address masking in instruction tracer [invertego]
* ares: Fix warnings reported by clang [invertego]
* ares: Fix static init in node subclasses [invertego]
* ares: Use 64-bit integers instead of 128-bit integers in the scheduler [invertego]
* ares: Use IP relative direct branches in the recompiler, where possible [invertego]
* ares: Emit only one epilog per block in the recompiler [invertego]
* ares: add label API to recompiler to simplify branches [invertego]
* ares: Use fixed BSS allocation for code cache; improves recompiler performance [invertego]
* ares: Fix instructionEpilogue test [invertego]
* ares: Directly emit code for target ABI; generates more efficient code in the recompiler [invertego]
* ares: Avoid encoding absolute data addresses in the recompiler [invertego]
* nall: allow mingw headers to define _MSVCRT_VERSION_ [invertego]
* nall: generate PDB when building with clang on windows [invertego]
* nall: allow generation of debug symbols with symbols=true [invertego]
* nall: link with lld wen building with clang on Windows [invertego]
* nall: Make thread movable but not copyable; fixes random UI hangs on Windows [invertego]
* mia: Fix MSU-1 rom loading [Luke Usher]
Reference data members via offsets from nonvolatile registers instead of
directly encoded absolute memory addresses. This is the last change
required for generated code to be fully position independent.
The reduction in code size is generally 5-7%, with the exception of the
N64 RSP, which sees a reduction of nearly 40%. This is mostly a result
of moving the clock increment to instructionEpilogue().
Previously, the recompilers in ares would assume the System V calling
convention, then emit extra moves on Windows to handle the differences
in register usage. Now, they directly populate the registers used by the
target system for passing parameters to functions. This is achieved
with register aliases set for the appropriate ABI at compile time.
Furthermore, registers that are nonvolatile only on Windows - rsi and
rdi - are no longer used as temporaries, removing the need to save and
restore them in recompiled code blocks.
This accounts for roughly a 10% reduction in recompiled code size on
Windows while making functionally no difference to other systems.
The thread class owns a resource and should have semantics akin to
std::unique_ptr. By allowing copying, the Windows implementation was
calling CloseHandle() when the original copy was destructed, meaning the
new copy would have no actual ownership of the handle. Once the thread
itself exited (dropping the last reference on the handle), later uses of
this handle in join() and ~thread() could end up operating on anything
or nothing depending on whether the handle value had been recycled.
This change modifies the POSIX implementation just enough to keep the
semantics the same as the Windows implementation for users of the class.
Otherwise, there is no functional change.
This fixes random UI hangs and other bad behavior on reset or unload.
instructionEpilogue() returns a bool, but all recompilers were
performing a 64-bit test on the return value. If sizeof(bool) == 1, only
the bottom 8 bits are guaranteed to be valid.
Place code caches in the bss section to guarantee proximity to the text
section in order to improve branch prediction and eventually so we can
reliably utilize IP-relative branch instructions.
There is now a fixed 1 GB buffer that is shared by all system cores with
recompilers (m32x, n64, ps1). Because the linker will place it in bss,
it will consume no space in the executable on disk, and operating
systems should be clever enough to avoid comitting physical pages until
it is actually in use. The buffer is defined in a separate translation
unit and only referenced from under compile-time recompiler checks, so
it should be left out by the linker when recompilers are disabled.
And defaulting it, as some older games depend on it to this kind of input to work properly.
eg.: Forgotten Worlds
https://youtu.be/ngHDIFQHFyQ
This also solves https://github.com/higan-emu/ares/issues/177
Fighting pad is still supported just need to be selected in Mega Drive->Controller Port
Currently ares is using 128-bit counters when the built-in __int128 type
is available. Near's notes on this topic conceded that it wasn't really
necessary, but defended it by stating there was no speed penalty on
64-bit architectures.
Unfortunately, LLVM's 128-bit integer support is buggy when compiling
for Windows targets. I've filed a bug report and am optimistic this will
eventually be fixed, but to prevent people from being burned when
compiling ares themselves, it would be safer to avoid the built-in
__int128 type entirely.
This change imposes 64-bit counters on all architectures for
consistency. It redefines the nall (u)intmax types to match the standard
(u)intmax_t types, though there is no longer anything in ares using them
at the moment.
This commit implement perfect PI DMA write. The PI DMA is normally used
for 8-byte aligned transfers, which is where it constantly works. The
hardware does contain a half-baked, buggy support for 2-byte aligned
transfers and odd-size lengths. I have extensively investigated the
behavior of every single quirk, and produced a test ROM that Ares
passes after this commit (timing is still off, but that's for another
day):
https://github.com/rasky/n64_pi_dma_test
The implementation is the same that I've previously submitted to cen64,
adapted for the ares codebase.
Whatever defining this manually was intended to fix, today it is only
breaking things. The mingw headers define this as 0x700 if you are
linking against MSVCRT and 0xE00 if you are linking against UCRT. This
is a mingw-internal macro, and there is currently no comparison in the
headers that evaluates differently for 0x601 than for 0x700. However,
always forcing it to 0x601 as nall does breaks linking against UCRT.
We should let mingw define this appropriately.
When building with clang, two static inline members of Node subclasses -
identifier and register - were not consistently initialized in that
order during application startup. Because the constructor of register
depends on identifier, this poses a problem.
I'm not sure if clang is on the wrong or if the initialization order is
actually unspecified by the language standard, but this situation can be
easily avoided, so I opted to do just that.
These warnings can often catch genuine bugs. The only tautological
compare warning I observed was reporting a real bug in the SFC core. The
shift count overflow warnings appeared to be for cases that were benign,
though only because I already fixed a significant one in the instruction
tracer. In general, such shifts are undefined behavior and require
surrendering to the whims of the compiler and the processor
architecture, so they are worth avoiding.
The large diff in ares/component/processor/tlcs900h/instruction.cpp is
mostly uninteresting. I had to make the control flow more explicit for
undefined instructions to stop the compiler from complaining about bad
template specializations. While I was at it, I enabled unused-value
warnings for that file, which only required adding a few void casts.
Most of the warnings are from Windows specific code, as the rest of the
codebase is already fairly clean. This change fixes a couple of (benign)
bugs discovered by these warnings.
In hiro/windows/action/menu.cpp, menu-item.cpp:
A function pointer was being passed in place of a bool argument to
nall::image::scale(). At one point the name Interpolation::Linear
referred to an enum. In any case, the argument in question defaults to
true - specifying linear interpolation - so it is unneeded.
In hiro/windows/widget/widget.hpp:
The function minimumSize() was being overloaded instead of overridden
due to a missing const qualifier. It doesn't appear to have had any
negative side effects in ares.
This change corrects masking for 32 bit addresses.
Per the C++ standard on shift operators: "The behavior is undefined if
the right operand is negative, or greater than or equal to the width of
the promoted left operand."
Reduce the (minimum) number of cycles between an SI DMA request and the
completion of said request from 131072 to 2304 cycles. This is the
duration used in other emulators, and it is in agreement with the
observed behavior of Turok, which can only tolerate a delay between 215
and 3888 cycles (subject to current timings in ares).
In addition to fixing input in Turok - Dinosaur Hunter, this change gets
the following games past the intro:
- Donkey Kong 64 (w/ major graphical issues)
- Forsaken 64
- Hercules - The Legendary Journeys
- Triple Play 2000
On compare to NaN:
- do not raise an exception if exceptions are disabled
- do not update the csr condition bit if exceptions are enabled
On divide by zero:
- do update the destination fpr if exceptions are disabled
For both of the above:
- do set the csr cause bit
- do set the csr flag bit if exceptions are disabled
Turok is now able to play out the entire Acclaim logo animation. It was
previously resetting due to erroneously raised invalid operation
exceptions.
Jeopardy! only supports up to 3 players, and if four controllers are
plugged in when the game starts, it performs an out of bounds array
access that breaks further input logic. The only workaround is to unplug
a controller and reset the system. To make this game work well in ares
out of the box, we should connect no more than 3 controllers by default.
I opted to put a check specifically in desktop-ui because this is
fundamentally a mismatch between a specific game and a design choice (to
default to 4 controllers) in the desktop-ui frontend. It didn't feel
right to add a dedicated attribute to mia that did not describe a
feature of the cartridge itself and would not be generally applicable
other games (unlike rumble and memory pak support).
This change also brings the rumble and memory pak attributes in line
with the implementation of boolean attributes for other systems. There
is no functional change, though it will affect generated manifests if
they are/were persisted to disk.
A recent workaround for BattleTanx caused a regression in Perfect Dark.
Essentially, it was always telling games that they had been started by a
warm reset rather than a cold boot. Perfect Dark expects data to be
preserved in RDRAM across resets and fails to get as far as drawing
something on the screen if it isn't there.
This change reverts the workaround so that Perfect Dark will perform the
full initialization required after a cold boot. Luckily, this will not
regress the BattleTanx games, as they were fixed by my last change
(making sure IPL3 consumes a sufficient number of cycles). This change
also skips clearing RDRAM on resets, which is again required by Perfect
Dark and possibly other games.
The RI_SELECT register is read by IPL3 to check if RDRAM initialization
should be skipped. If we are forcing it to be skipped, we should also
consume enough cycles to not inadvertently speed up the boot process.
Wave Race 64 Shindou Pak Taiou Version will freeze on the N64 logo if
the SCC count register, which increments at half the CPU clock rate, has
too small a value.
The idea of using RI_SELECT reads as a cue to consume extra cycles was
borrowed from MAME.
Thanks to Rasky for measuring the timing on real hardware.
The flags returned by the Raw Input API have distinct meanings. The
lowest bit reflects the state of the key and the next two bits indicate
scan code prefixes. An oversimplified interpretation of these flags was
causing ruby to conflate events for keys that differ only by prefix.
Reference:
https://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-rawkeyboard
The full set of conflated key pairs:
Return Enter
Keypad0 Insert
Keypad1 End
Keypad2 Down
Keypad3 PageDown
Keypad4 Left
Keypad6 Right
Keypad7 Home
Keypad8 Up
Keypad9 PageUp
LeftAlt RightAlt
LeftControl RightControl
Multiply PrintScreen
Point Delete
Slash Divide
The TLCS-900 manual states the loaded address is relative to the start
of the instruction plus four bytes - in other words, one byte before the
end of the instruction.
This fixes crashes in SNK Gals' Fighters.
By using an 8 bit counter, the last 6 lines of every frame were being
skipped and the VDP was firing vblank interrupts ~2.3% faster than
intended in the ColecoVision, SG-1000, and MSX.
This also fixes the corrupted turtle graphics in Frogger for
ColecoVision, though this is mostly by chance. The game is buggy and
susceptible to graphics corruption if a vblank is raised between these
instructions:
1d09 out ($bf),a ; write low VRAM address byte
1d0b ld a,h
1d0c out ($bf),a ; write high VRAM address byte
It could easily be regressed by any future change that impacts timing.
Normally, breaking out of the halt state is handled by CPU::raise(), but
there is an edge case:
; preconditions: IME = 0, IE = 1, IF.0 = 1, LCDC.7 = 0
ei
halt
In other words, a vblank interrupt was requested with IME disabled, then
the display was disabled (so no more vblank interrupts will follow),
then interrupts were enabled while entering the halt state. Once halted,
there is no logic in ares to service the requested vblank interrupt.
A better long term approach would be to refactor the SM83 implementation
of halt to be more like the Z80 core - eliminating the loop within the
halt instruction itself - but in the meantime this change offers an
incremental improvement.
This fix prevents Amazing Penguin from freezing immediately on load.
On DMG, when the LCD is toggled from off to on, the screen remains blank
until one frame after the PPU becomes operational.
Furthermore, when the BG is disabled, the window is also no longer
drawn, though the other window logic (like the incrementing window line
counter) seems to remain operational.
This cleans up the visuals of Hyper Lode Runner on level start, but many
more games will be affected by blanking the first frame after the LCD is
toggled on.
This allows for all four n64 controllers to be used, while providing
capatbility to expand to five controllers for PC-Engine, once we
implement the multi/tubo-tap
When a serial transfer is started using the internal clock and no second
device is connected via link cable, 1 bits are shifted into the SB
register. This behavior must be emulated for the game Alleyway;
otherwise, it does not accept player input.
I couldn't find any research to support this limit, nor does it match
the behavior of other emulators. Everything I could find indicates that
the window should be drawn to the end of the line.
This fixes the right edge of the pause screen in Heiankyo Alien.
On DMG, sprites are sorted by x value then by OAM address. As the sprite
array begins in OAM order, a stable sort on x can achieve the desired
result. Conveniently, nall already contains a stable sort implementation
that is optimized for small arrays.
This fixes ordering issues with speech bubbles in Crayon Shin-chan 3.
The previous fast boot patch skipped the entire Nintendo logo animation
and sound. Unfortunately, this left a number of registers with different
values than they would otherwise have. The European release of the game
Dr. Franken does not initialize SCY, and fast boot was leaving it set to
100 instead of zero, causing the first logo to be shifted offscreen.
It would be easy enough to amend the patch to initialize SCY to 0, but
for most games this will cause the Nintendo logo to appear for a single
frame, which doesn't look so great.
This new patch skips the first ~4 seconds of the boot animation and
disables scrolling but otherwise leaves things alone. The result is a
a stationary Nintendo logo that appears centered on the screen,
accompanied by the usual sound, for ~1.5 seconds.
ares v123 includes significant improvements to the emulation of the ColecoVision,
SG-1000 and the Game Boy/Game Boy Color.
This release brings the compatibility rating for ColecoVision and SG-1000 to
four stars.
This means that we have 100% compatiiblity with both of those libraries, with
the only exception being the few games that require additional peripherals
(driving controllers; touchpads, etc).
The Game Boy improvements are significant, but not quite enough to increase
the compatibility rating at the present time, even so, Many more games are
playable than before.
Finally, a few tweaks to MegaDrive emulation have improved compatibility,
reduced the occurance of video corruption, and improved performance of
the Sega 32X emulation.
**Changelog:**
* ColecoVision: Initialize ram to 0; fixes a crash in The Heist [Luke Usher]
* ColecoVision: Disable cartridge rom mirroring; fixes Sammy Lightfoot [invertego]
* ColecoVision/MSX/SG-1000: Initialize VRAM to 0; fixes various games [invertego]
* Game Boy: Check window x-coord instead of only y-coord; improves the Acid2 test rom [Luke Usher]
* Game Boy: Only raise STAT interrupt when display is enabled; fixes Cool Hand [invertego]
* Game Boy: Implement HALT hardware bug [Meepster99]
* Game Boy: Fix relationship between LY and STAT interrupt; fixes Elite Soccer, Mouse Trap Hotel, Shantae [invertego]
* Game Boy: Only trigger STAT interrupts at the start of OAM search; fixes Mortal Kombat 3 [invertego]
* Game Boy Color: Fix HDMA5 bit.7 reads; improves a significant number of GBC games [invertego]
* Game Boy Advance: Simulate standard GBA instead of Game Boy Player; fixes GBA Video titles [Luke Usher]
* Mega Drive: Implement support for Sonic & Knuckles merged roms; fixes Sonic 2K, Sonic 3K [Luke Usher]
* Mega Drive: Implement support for SRAM/EEPROM when using the SEGA Mapper; fixes Demons of Asteborg [Luke Usher]
* Mega Drive: Default to 'accuracy' VDP; improves compatibility at the expense of performance [Luke Usher]
* Mega Drive: Optimize how often the emulator synchronises between components; offsets the cost of the previous change [Luke Usher]
* Nintendo 64: Maintain Parallel-RDP as a subtree; simplifies compilation [Luke Usher]
* SG-1000: Implement support for roms greater than 32KB [Luke Usher]
* SG-1000: Implement support for Taiwan Type-A/Type-B mappers; fixes unlicensed Taiwan releases [Luke Usher]
* SM83: Fix DAA instruction [Meepster99]
* TMS9918: Implement multicolor mode; fixes various SG-1000/ColecoVision games [invertego]
* TMS9918/Master System/MSX: Allow sprites to bleed off top/left screen edges [invertego]
* ares: Rename lucia to desktop-ui to better represent it's function [Luke Usher]
* mia: Improve N64 save-type database [jeltaqq]
* mia: Add support for UNF extension, alongside UNIF and NES [Shideravan]
* nall: Add macOS deployment target flags; fixes ares on macOS 10.14 [MerryMage]
* ruby: Give PulseAudio higher priority than ALSA on Linux Systems; ALSA was causing frame-rate issues [Luke Usher]
A refactor in v116r07 replaced the variable dmaCompleted with dmaActive
but failed to update its usage on HDMA5 register reads. Bit 7 should
read 0 if HDMA is active and 1 if completed.
This change will affect many (most?) GBC games.
STAT interrupts triggered by mode 2 (OAM search) should only occur at the
start of the line. Crucially, writes to STAT in the midst of mode 2 that
enable OAM interrupts should not trigger a STAT interrupt. This is
especially important on DMG because of the hardware bug that causes STAT
writes to briefly enable all STAT interrupts. Spurious STAT interrupts
that would not have occurred on real hardware can violate the
assumptions of games that aren't expecting them. Mortal Kombat 3 is one
such game, and it is now playable.
Previously, ares was emulating the coincidence flag in the the STAT
register with M-cycle accuracy but was much less accurate with the
timing of coincidence triggered STAT interrupts or with resetting the LY
register to 0 during vblank. This was breaking a pattern common to a
number of games that goes like this:
1) Write 0 to LYC and set the coincidence interrupt enable bit in STAT
2) In the STAT interrupt handler, read LY and increment by one
3) Loop until LY equals the incremented value
ares would trigger a STAT interrupt during line 153 but LY would
continue to read back as 153 instead of 0. A game incrementing this
value and waiting for it to appear in LY would become stuck in an
infinite loop, as there is no line 154.
This change brings M-cycle accuracy to the LY register and STAT
interrupts using "The Cycle-Accurate Game Boy Docs" by AntonioND as a
reference. It also stops resetting LY on write, as this erroneously
described behavior is not hardware accurate.
The following games should now be playable:
- Elite Soccer
- Mouse Trap Hotel
- Shantae
This significantly improves performance for md, cd, 32x and cd32x, with
minimal impact on accuracy.
Assuming 3420 cpu cycles per scanline, with a max horizontal resolution
of 320/342:
For MegaDrive/Mega-CD, we can sync every 10 cycles (approx 1 pixel),
since we're using a dot renderer, there is little point in synching more
often than that.
For 32X/CD32X, we sync once every 40 cycles (4 pixels), this provides
enough of a performance boost to make 32X emulation viable for modest
machines, but does not significantly impact compatibiltiy or accuracy;
it's still significantly better than with the scanline renderer we used
previously.
This improves compatibility with both MegaDrive and 32X titles at the
expense of performance.
On modest hardware, this still retains full-speed for MegaDrive titles, but 32X and MegaCD may struggle; this will be addressed in a later
commit.
This emulation bug, combined with the intentional emulation of the
hardware bug that causes spurious stat interrupts, was causing stat
interrupts to be raised when the display was disabled.
This stops the GB game Cool Hand from freezing after selecting cribbage.
This removes the special casing for Sonic & Knuckles, treating it as a standard rom.
While not strictly correct from an accuracy/real world point of view, all existing
emulators and rom dumps assume the emulator will treat it as a single cart.
The TMS9918 allows for sprites to, in the words of TI's VDP Programmer's
Guide, "bleed" off the top or left edge of the screen. Depending on the
edge, this is accomplished by different means.
Proper implementation of this behavior is known to affect the following
ColecoVision games:
- Frogger: some sprites should be hidden off the left edge of the screen
- The Heist: the player sprite crosses the left edge of the screen
- Bump 'N' Jump: car sprites cross the top edge of the screen
It looks as though the V9938 and SMS VDP will require similar fixes.
Initialize VRAM to zero on load for systems that use the TMS9918/V9938.
On real hardware this memory will be in a partially indeterminate state,
but as far as approximations go, 0x00 is much less problematic than
0xff. A sprite attribute table filled with 0xff is interpreted to have
valid entries for sprites in the top right corner of the screen. If the
pattern data is also filled with 0xff, a white square will be drawn in
the corner. On the other hand, a sprite entry of all 0x00 bytes will be
fully transparent (due to the color byte being zero) and therefore
invisible.
This is most noticeable in games that never get around to fully
initializing VRAM, such as the ColecoVision game Boulder Dash, which has
a permanent square in the corner.
SG-1000 games only seem to exhibit this problem briefly after booting,
and only for certain games, as they eventually get around to
initializing VRAM. Some homebrew is more seriously affected.
MSX compatibility is in too poor a state to test comprehensively, but a
survey of other emulators shows initializing VRAM to zero is the norm.
This change also allows VRAM to carry over across soft resets. This
should be closer to hardware behavior, though in reality it is possible
for some bits to be perturbed.
ColecoVision carts contain up to 4 separate 8 KiB banks, and there is no
mirroring when some banks are absent. The existing mirroring behavior
was causing Sammy Lightfoot to freeze on load.
This release primarily provides improved Neo Geo Pocket/Neo Geo Pocket Color and Sega 32X emulation.
The entire Neo Geo Pocket/Color library is now thought to be playable, with minor graphical issues in four titles.
A small number of SEGA 32X games are now playable, although most still experience graphical and/or audio issues.
Changelog:
ColecoVision: Clear top bit of controller port reads; fixes Defender [invertego]
Neo Geo Pocket: Allow BIOS to handle the boot process [invertego]
Neo Geo Pocket: Copy SNK logo from BIOS during fast boot; fixes Metal Slug: 2nd Mission [invertego]
Neo Geo Pocket: Fix address used to test ram initialization [invertego]
Neo Geo Pocket: Initialize Neo Geo Pocket port 1 to zero; fixes Dynamite Slugger [invertego]
Neo Geo Pocket: Many improvements to 'fast boot' [invertego]
Neo Geo Pocket: Re-enable savint ram to disk on unload [invertego]
Sega 32X: Implement FM/Framebuffer access bit; fixes Spiderman [Luke Usher]
Sega 32X: Implement RV bit [Luke Usher]
Sega 32X: Optimise SH7604 recompiler min-cycles for 32X; fixes Knuckles Choatix & Virtua Fighter [remutro]
Sega 32X: PWM DREQ and timer are different things; fixes PWM audio in many games [Luke Usher]
Sega 32X: Used cached interpreter instead of recompiler [Luke Usher]
TMS9918: Fix sprite size emulation; fixes many graphical issues in ColecoVision/MSX/SG-1000 [invertego]
TMS9918: fix interrupt behavior [invertego]
hiro: Fix browser dialog filters on macOS [Luke Usher]
hiro: Force GTK3 to use X11 backend; fixes a crash under Wayland [thrimbor]
lucia: Disable fast boot by default [Luke Usher]
lucia: Support digital presses from analog inputs [invertego]
mia: Add workaround for underdumped Delta Warp rom [Luke Usher]
mia: Improve Nintendo 64 save chip database; fixes saving in some titles [sp1187]
nall: Enable LTO by default on non-debug builds [Luke Usher]
nall: Speed up recompiler codegen [Luke Usher]
sh2: Allow cores to determine an ideal minimum recompiler block size [Luke Usher]
sh2: Optimised code-gen for the interpreter [Luke Usher]
sh2: Recompiler should invalidate single blocks, not entire pools [Luke Usher]
tlc2900h: Fix immediate mask in BIT #,r; fixes Pocket Tennis [invertego]
z80: Correct the effect of IE on the next instruction; fixes audio drop-out in Neo Geo Pocket games [invertego]
The existing implementation was very incorrect. Fortunately, this chip
is well documented and the correct behavior is quite easy to implement.
This fixes most of the remaining ColecoVision bugs that aren't related
to missing peripheral support.
The TMS9918 is also used by the SG-1000 and MSX cores. I don't have a
list of bugs for those platforms, so I couldn't do any targeted testing,
but I booted up a few games and did not see any new issues.
Commit 532aafe074 made some improvements
to sprite zoom (magnification) emulation. It also corrected sprite size
emulation in the SMS VDP in what is referred to as Mode 4 by most
sources ("graphics3" in ares). Unfortunately, it erroneously applied the
same changes to the TMS9918 and V9938 as well as the SMS VDP in TMS9918
compatible modes. This caused widespread regressions in ColecoVision,
SG-1000, MSX, and MSX2 emulation.
This commit reverts the changes made outside of SMS VDP Mode 4,
restoring the dimensions of double sized sprites from 8x16 to 16x16.
I couldn't find any references describing the expected value of the top
bit of controller port reads, but some games require it to be cleared.
Here is an example from Defender when it is waiting a 1/2 button press:
in a,($FC) ; read controller 1
cp $7D ; compare 1 button
jr z,$876D
cp $77 ; compare 2 button
jr z,$8773
Clearing it fixes input in games that depend on all the undefined bits.
The implementation of IE in the Z80 processor was incorrectly causing
nonmaskable interrupts raised before the next instruction to be dropped.
A correct implementation should do two things:
- set IFF1 and IFF2 to 1
- disable maskable interrupts until after the following instruction
This fixes the issue of audio dropping out of Neo Geo Pocket games
seemingly at random.
References:
Z80 CPU User Manual (http://www.zilog.com/docs/z80/UM0080.pdf)
Page 6: "NMI is always recognized at the end of the current instruction,
independent of the status of the interrupt enable flip-flop..."
Page 183: "During the execution of this instruction [EI] and the
following instruction, maskable interrupts are disabled."
Use three first letters of game ID for mapping.
Add more entries (mostly Japanese games) and fix a few incorrect ones.
Handle some special cases involving different save chips for different
revisions and regions of the same game.
Change manifest generation to use whole four-letter ID and also output
the revision.
modified: ares/md/m32x/sh7604.cpp
Change the cached interpreter's recompiler min_cycles value from 23 to 22.
It's just ever so slightly too agressive.
This addresses problems with the bonus levels in Knuckles Chaotix,
as well as the hang in Virtua Fighter after selecting your character.
This appears to be the optimal value through lots of additional testing.
There were no other problems observed in the 32X library by lowering this
value to 22. Additionally, there were no further gains to be made by going
any lower (all the way to zero) such as correcting the hang at the end of
the match in Brutal: Above the Claw or NBA Jam failing to go in-game. Both
of these currently require using the full interpreter, and not the cached
interpreter enabled by default to correct timing issues.
This fixes 5% of games in the 32X library. :-)
lucia maps the N64 C-buttons to the right thumbstick of the virtual pad.
These are analog inputs on the virtual pad, so sampled analog values are
not converted to digital. This means any nonzero value is treated as
button press, which is not ideal when mapped to an analog input device.
This change introduces a helper to convert raw input values to a binary
"pressed" state at time of use, currently only defined for digital and
analog input mappings - for relative and absolute inputs this concept
would not make much sense.
My last change indexed into the ram array by an absolute memory address,
but the array only covers a portion of the address space beginning at
0x4000. This was in fact indexing past the end of the array, but it
appeared to work as long as 1) something was mapped there and 2) that
something was nonzero. It's possible that booting from the shutdown
vector every time doesn't have any negative side effects, but booting
from the hardware reset vector the first time is still the more correct
thing to do from an accuracy perspective.
Neo Geo Pocket is an "always on" system. On first boot, it quickly
enters a low power state via a halt instruction. From there, the user
must press the power button to wake the sytem. At this point, the BIOS
setup is shown, requiring the user to pick a preferred language among
other choices. When power is pressed again, the system returns to a low
power state. This state is maintained by an internal battery should the
external batteries discharge or be removed. The hardware reset entry
point will not execute again until the internal battery fails.
The current design of ares appears to be motivated by a few goals:
- Avoid requiring the user to press the emulated power button
- Avoid showing the BIOS setup more times than necessary
- Enable "fast boot" mode to skip the boot animation
The required power button press is avoided by skipping the first boot
code entirely in CPU::power(). Emulation never begins at the hardware
reset vector, but rather at 0xFF1800, following MAME's lead. This entry
point appears to have been for development purposes only and is not
referenced by the BIOS itself. Crucially, it does not run some
bookkeeping logic that only occurs when entering a low power state
either after a cold boot, in response to a power button press, or after
a software requested shutdown. Skipping this logic can cause the BIOS
setup to be shown on next boot.
The BIOS setup is avoided by simulating the bookkeping done by the BIOS
in the emulator itself. This logic is located in CPU::load(), meaning
that it does not run between system resets. Therefore, resetting a game
can still cause the BIOS setup to be shown. The BIOS setup is also
skipped by fast boot mode.
Fast boot mode bypasses the BIOS entirely on boot, jumping straight to
the cartridge entry point. This means all of the many important side
effects of the boot process must be replicated by CPU::fastBoot().
Currently, it also gives the user no way to select Japanese as a
preferred language.
The existing solutions to these problems fall short of providing a
consistent user experience, tightly couple ares to the internals of the
BIOS rom, and (particularly with fast boot) have been a source of many
bugs. This change removes the existing solutions in favor of ones that
let the BIOS handle the entirety of the boot process.
The new code in this change does the following:
- Begin execution at the hardware reset vector on first boot
- Begin execution at the VECT_SHUTDOWN syscall on subsequent boots
- Simulate a power button press when entering a low power state
- Patch the BIOS to skip the boot animation in fast boot mode
Starting at the hardware reset vector ensures the BIOS setup will be
shown on first boot, affording the user the opportunity to pick a
preferred language. Subsequent boots will begin at the VECT_SHUTDOWN
system call. It may seem counterintuitive, but this allows the BIOS to
perform cleanup that would normally only occur when the user shuts off
the device before switching cartridges. In both of these cases, we can
avoid requiring the user to press the emulated power button by
simulating a button press on their behalf. It's a low tech solution to
be sure, but a reliable one.
Finally, the implementation of fast boot mode is replaced with a single
byte patch to the BIOS to immediately return from the routine that plays
the boot animation.
When this bit is set to 0, any framebuffer or VDP access from the sh2 has to be ignored and when this bit is set to 1, any framebuffer or VDP access from the m68k should be ignored.
This fixes the rendering issues in Spiderman, likely others too.
The fastboot option is a nice to have, but it has potential to introduce serious bugs/glitches into emulation, as seen with Neo Geo Pocket, so it is safer to default this option to disabled.
The game Metal Slug - 2nd Mission compares a region of character memory
to a copy of the SNK logo in the game rom. Normally this memory is
initialized for the boot animation played by the BIOS. If the logo isn't
an exact match, the game starts but you are unable to fire any weapons.
Conceptually, this is the reverse of what the Game Boy does on boot.
There, the boot rom validates a Nintendo logo on the cartridge.
Since we already have the BIOS loaded, we can copy the logo from there
during a fast boot, though some unpacking is required.
This code was commented out in commit
4e82321182 which otherwise only affected
TLCS900/H timing. I believe this was left in by mistake. Uncommenting
this code restores the ability to persist BIOS settings across play
sessions.
In the game Dynamite Slugger, when your batter strikes out it loads a
16-bit word from 0x0000 and resets the game if anything but zero comes
back. The second byte, at address 0x0001, is mapped to internal port 1,
and currently almost all port values are initialized to 1 at power on.
In a 2019 nesdev post [1], Near stated that port emulation was incomplete
and likely incorrect. Without hardware tests, I'd rather not touch this
code more than necessary, but at the very least it seems more correct to
initialize the latched value in port 1 to zero.
There is a chance that the null dereference in Dynamite Slugger is
itself the result of an emulation bug, but all I have to compare against
is MAME, and the game behaves the same there. I believe this is decent
evidence that we are seeing a real game bug and that reading back zero
is what would have occurred on actual hardware.
[1] http://forums.nesdev.com/viewtopic.php?f=23&t=18579#p236069
"I added ports 1, 2, A, and B. Although ports 1 (d8-d15) and 2 (a16-a23)
are ... strange. They're likely emulated very wrong. I don't even
understand how one can change the direction of the data bus. I'm ...
suspecting that ports have their own latch values, but the manual isn't
very clear on this."
Perform more initialization to match the side effects of booting from
the BIOS.
1) Initialize XIX register. Puyo Pop World relies on this (likely a game
bug).
2) Initialize interrupt vector table. SNK Gals' Fighters and the Pocket
Casino Series games rely on this.
3) Initialize interrupt request levels used by the VECT_INTLVSET system
call. The Pocket Casino Series games rely on this.
The BIT (imm, reg) instruction uses the low 4 bits of its immediate operand even
when the register operand is only 8 bits wide. When the register is 8 bits and
the immediate value is between 8 and 15, ZF will be always be set. ares was
erroneously using only the bottom 3 immediate bits in this case (so 15 would
behave the same as 7).
With this fix, sprites now render correctly in the Neo Geo Pocket game Pocket
Tennis.
This bug was discovered by comparing against an instruction trace from MAME.
This change is the functional equivalent of commit
57e42cda31430c75566403c5f27ec290dc123da3 in the MAME git repo.
Although mia doesn't use threads itself, it includes `ares/ares.hpp` and ares
*does* use threads, so we need to build with `-pthread` in order to link
successfully.
I've released ares v121. Because it is not fully complete or stable, it is
released as source code only.
The license is now once again ISC instead of CC-BY-NC-ND.
Master System, WonderSwan, and WonderSwan Color compatibility have increased to
100%, with no remaining known bugs.
The Neo Geo Pocket is very close to 100% now with one issue remaining, where
sound effects sometimes mute in games.
Nintendo 64 compatibility has increased to above 80% thanks to corrections to
controller pak handling.
Several NES and Mega CD fixes have been added. EEPROM support has been added for
the Mega Drive.
Memory cards and paks now pre-format themselves, so you don't have to do so in-
game or in BIOS settings.
The new Neo Geo emulation is slowly improving, but it's still very preliminary
with only seven games fully playable so far.
The Nintendo 64 SM5K and PlayStation HC05 processor cores have been emulated,
but not connected yet due to a lack of information.
Added mouse input support and connected peripheral selection to the GUI, so mice
and light gun games can now be used.
There is now per-system input mapping overlays, so you can map controllers based
on the original system button names.
And lastly as promised, the SNES core has gained optional widescreen support.
Changelog (since v120):
- Nintendo 64: added Windows ABI support to dynamic recompilers
- PlayStation: added Windows ABI support to dynamic recompiler
- Nintendo 64: temporarily disabled 64-bit addressing mode due to issues
- Nintendo 64: corrected analog stick ranges and emulated octagonal
boundaries
- Nintendo 64: code cleanups around memory access functions
- Nintendo 64: started to implement RDRAM broadcasting (very incomplete
still)
- Mega Drive: improved VDP scanline renderer timing
- M68K: corrected clipping bug in ADD,CMP,SUB instructions
- Nintendo 64: improved SI scanning of PIF RAM and emulated more flags
- Nintendo 64: added very accurate controller pak initialization code
- Nintendo 64: improved controller analog stick approximations [MerryMage]
- Nintendo 64: added priority queue to delay SI and PI DMA transfers
- Master System: added bit-perfect YM2413 instrument patch sets
- Mega Drive: fixed a bug with LINEA and LINEF instructions (should not
decrement PC)
- Mega Drive: added EEPROM emulation
- mia: added Mega Drive and Mega 32X EEPROM database entries
- nall: added priority_queue::remove(T) support
- Nintendo 64: reverted 64-bit TLB (not actually present)
- Neo Geo: initial implementation
- Neo Geo: many emulation improvements
- nall: add workaround for compilers that lack __has_builtin
- Nintendo 64: ignore A15 on controller pak reads and writes
- Master System: implemented Codemasters, Korea, MSX, Janggun mappers
- Master System: improved Sega mapper emulation
- Master System: added initial emulation of port $3e
- Master System: added support to load BIOSes
- Master System: initialize stack pointer to 0xfffd when no BIOS loaded
[Luke Usher]
- Game Boy Advance: emulated BIOS swap register [MerryMage]
- Mega Drive: cancel pending IRQs when they are disabled [Jonas Quinn]
- Mega Drive: fixed handling of VDP field flag [Jonas Quinn]
- Mega Drive: mask upper bit of VDP sprite Y value when in progressive
display mode [Jonas Quinn]
- X24C01, M24Cxx: improve emulation of EEPROM command sequences
- Famicom: added database entries for Jajamaru Gekimaden and Mazase Top
Pro PRG-RAM
- M24Cx: rewrote emulation to be more complete; though still not working
for Cxx/Cxxx sizes
- Nintendo 64: try stopping SI polling on recv=0xfe
- Mega Drive: improved EEPROM emulation
- Nintendo 64: fixed CPU SCC counter rate [simer]
- Nintendo 64: added initial emulation of the SM5K processor (not connected
yet)
- lucia: update frame rate from the main thread to prevent a race condition
with GTK
- Master System: emulated sprite zoom and fifth-sprite status flag
- Master System: corrected VDP background emulation for mode 4 [fixes
Codemasters games]
- Master System: latch VDP background nametable address and scroll registers
[fixes Desert Speedtrap]
- Master System: mask CRAM reads to 6-bit in Master System mode [fixes Mercs]
- Master System: refactored VDP code
- Z80: swapped IND/INI to post-decrement B, and OUTD/OUTI to pre-decrement B
- lucia: fixed a crash when loading Game Gear games due to stubbing out
the BIOS
- Nintendo 64: fixed cartridge flash memory support
- Master System: VDP line coincidence should be initialized to $ff [fixes
Shadow Dancer]
- Master System: VDP sprite overflow index defaults to $1f, not $00 [fixes
PGA Tour Golf]
- SN76489: corrected port latching behavior and noise volume writes [fixes
Micro Machines]
- TMS9918: greatly refactored code
- V9938: greatly refactored code
- Z80: disassembler fixes
- lucia: corrected mapping of Master System pause button [fixes Baku
Baku Panic]
- nall: disable -Wstringop-overflow for GCC due to compiler heuristics error
- M68HC05: initial core implementation added
- M68000: renamed core from M68K
- Super Famicom: clearing $4200.d0 stops active joypad polling for the rest
of the frame [Jonas Quinn]
- Master System: don't evaluate sprites past active display area [fixes
Rescue Mission]
- Mega Drive: don't acknowledge VDP IRQs until the CPU triggers them [fixes
Mega Lo Mania]
- lucia: begin refactoring input mapping to allow per-system mappings and
multiple controller types
- Game Gear: set CPU::in() unmapped return value to MDR; fixes RoboCop 3
[Jonas Quinn]
- WonderSwan Color: do not mask screen tilemap base address; fixes Sorobang
[FPGAzumSpass]
- Mega Drive: set supervisor mode and clear trace mode for all exceptions;
fixes Gouketsuji Ichizoku [Jonas Quinn]
- Mega CD: format BRAM instead of leaving it uninitialized; fixes Popful Mail
(US)
- WonderSwan: add patch for Meitantei Conan: Nishi no Meitantei Saidai
no Kiki!
- Game Boy: add MBC1#M mapper database entries; fixes Bomber Man Collection,
Genjin Collection, Momotarou Collection, and Mortal Kombat I & II
- Neo Geo Pocket: $8118 background register exists even in the K1GE GPU;
fixes Samurai Shodown
- Neo Geo Pocket Color: return 0xFF acknowledge byte after flash erase
command; fixes Puzzle Link 2 and Memories off: Pure
- Neo Geo Pocket: clear watchdog timer counter on trigger to prevent
infinite triggering; fixes Neo Baccarat, Neo Cherry Master Color, and
Neo Mystery Bonus
- TLCS900H: do not allow interrupts to run between CPDR, LDIR, LDDR
instructions; fixes Fantastic Night Dreams Cotton
- Neo Geo Pocket: add all remaining missing I/O registers (not emulated,
but registers are readable and writable now)
- Neo Geo Pocket Color: above changes also fixed in-game audio in Crush
Roller and Dynamite Slugger
- Mega CD: added 1M mode WRAM swap request flag; fxies AX-101, Earnest Evans,
and Might & Magic III [TascoDLX]
- lucia: added input mapping overlays for all remaining systems
- lucia: added two-player support to all remaining systems
- TLCS900H: refactored instruction decoder and disassembler using range-case
- TLCS900H: improved emulation of (PC+d16) addressing mode (LDAR)
- TMS9918, V9938, SMS VDP: corrected sprite zoom emulation [Jonas Quinn]
- Neo Geo Pocket: added new debugging modules (flash ROM, I/O accesses,
system calls)
- Neo Geo Pocket: improved CPU interrupt logger (prints name of interrupt
now)
- Neo Geo Pocket: fixed a critical issue with interrupt priority levels;
fixes many games
- Neo Geo Pocket: added stubs for all remaining TMP95C061F I/O registers
(not emulated yet)
- Neo Geo Pocket: set CPU I/O port $b1.d2 reads to return 1 (fixes SNK
Gals' Fighter)
- Neo Geo Pocket: added stubs for undocumented CPU I/O ports $b6 and $b7
- Super Famicom: PPU code restructuring
- Super Famicom: added widescreen (16:9 and 21:9) support to the scanline
renderer
- WonderSwan: refactored I/O handlers to use switch/case instead of if tests
- WonderSwan: rewrote PPU renderer to modularize each component (screen1,
screen2, sprite, dac, etc)
- WonderSwan: corrected timers to count down instead of up; fixes timing
in many games [FPGAzumSpass]
- WonderSwan: improved screen two window emulation [FPGAzumSpass]
- hiro: TableView::onContext() is now TableView::onContext(TableViewCell)
(not supported for Cocoa or Qt yet)
- lucia: merged code to handle input assignment overlays and controller
polling for each emulation core
- lucia: added virtual mouse emulation and added mouse capture support
- lucia: added support to change devices connected to controller ports
- Neo Geo Pocket: added database workaround for underdumped Prize Game:
PP-AA01 Pusher Program (Japan)
- Neo Geo Pocket: fixed fast boot mode for Neo Cherry Pocket
- nall/range: added new within() templates
- V30MZ: emulated instruction prefetch
- V30MZ: greatly improved instruction timings (thanks to FPGAzumSpass'
test ROM)
- WonderSwan: disabling an interrupt source does clear its pending status
(fixes Digimon Tamers)
- TLCS900H: improved prefetch handling and instruction timing (still
imperfect)
- TLCS900H: improved timing further (still imperfect)
- WonderSwan: disabling an interrupt source does clear its pending status
(fixes Digimon Tamers)
- TLCS900H: improved prefetch handling and instruction timing (still
imperfect)
This gets a 100% pass on FPGAzumSpass' WonderSwan instruction timing tests, and
emulates CPU prefetch as well, but it seems to make games less stable rather
than more =(
- TLCS900H: refactored instruction decoder and disassembler using range-case
- TLCS900H: improved emulation of (PC+d16) addressing mode (LDAR)
- TMS9918, V9938, SMS VDP: corrected sprite zoom emulation [Jonas Quinn]
- Neo Geo Pocket: added new debugging modules (flash ROM, I/O accesses,
system calls)
- Neo Geo Pocket: improved CPU interrupt logger (prints name of interrupt
now)
- Neo Geo Pocket: fixed a critical issue with interrupt priority levels;
fixes many games
- Neo Geo Pocket: added stubs for all remaining TMP95C061F I/O registers
(not emulated yet)
- Neo Geo Pocket: set CPU I/O port $b1.d2 reads to return 1 (fixes SNK
Gals' Fighter)
- Neo Geo Pocket: added stubs for undocumented CPU I/O ports $b6 and $b7
- Super Famicom: PPU code restructuring
- Super Famicom: added widescreen (16:9 and 21:9) support to the scanline
renderer
- WonderSwan: refactored I/O handlers to use switch/case instead of if tests
- WonderSwan: rewrote PPU renderer to modularize each component (screen1,
screen2, sprite, dac, etc)
- WonderSwan: corrected timers to count down instead of up; fixes timing
in many games [FPGAzumSpass]
- WonderSwan: improved screen two window emulation [FPGAzumSpass]
- hiro: TableView::onContext() is now TableView::onContext(TableViewCell)
(not supported for Cocoa or Qt yet)
- lucia: merged code to handle input assignment overlays and controller
polling for each emulation core
- lucia: added virtual mouse emulation and added mouse capture support
- lucia: added support to change devices connected to controller ports
- Neo Geo Pocket: added database workaround for underdumped Prize Game:
PP-AA01 Pusher Program (Japan)
- Neo Geo Pocket: fixed fast boot mode for Neo Cherry Pocket
- nall/range: added new within() templates
- Game Gear: set CPU::in() unmapped return value to MDR; fixes RoboCop 3
[Jonas Quinn]
- WonderSwan Color: do not mask screen tilemap base address; fixes Sorobang
[FPGAzumSpass]
- Mega Drive: set supervisor mode and clear trace mode for all exceptions;
fixes Gouketsuji Ichizoku [Jonas Quinn]
- Mega CD: format BRAM instead of leaving it uninitialized; fixes Popful Mail
(US)
- WonderSwan: add patch for Meitantei Conan: Nishi no Meitantei Saidai
no Kiki!
- Game Boy: add MBC1#M mapper database entries; fixes Bomber Man Collection,
Genjin Collection, Momotarou Collection, and Mortal Kombat I & II
- Neo Geo Pocket: $8118 background register exists even in the K1GE GPU;
fixes Samurai Shodown
- Neo Geo Pocket Color: return 0xFF acknowledge byte after flash erase
command; fixes Puzzle Link 2 and Memories off: Pure
- Neo Geo Pocket: clear watchdog timer counter on trigger to prevent
infinite triggering; fixes Neo Baccarat, Neo Cherry Master Color, and
Neo Mystery Bonus
- TLCS900H: do not allow interrupts to run between CPDR, LDIR, LDDR
instructions; fixes Fantastic Night Dreams Cotton
- Neo Geo Pocket: add all remaining missing I/O registers (not emulated,
but registers are readable and writable now)
- Neo Geo Pocket Color: above changes also fixed in-game audio in Crush
Roller and Dynamite Slugger
- Mega CD: added 1M mode WRAM swap request flag; fxies AX-101, Earnest Evans,
and Might & Magic III [TascoDLX]
- Nintendo 64: added ISViewer support
- lucia: added input mapping overlays for all remaining systems
- lucia: added two-player support to all remaining systems
- Game Gear: fix inputs
- Master System: don't evaluate sprites past active display area [fixes
Rescue Mission]
- Mega Drive: don't acknowledge VDP IRQs until the CPU triggers them [fixes
Mega Lo Mania]
- lucia: begin refactoring input mapping to allow per-system mappings and
multiple controller types
- M68HC05: initial core implementation added
- M68000: renamed core from M68K
- Super Famicom: clearing $4200.d0 stops active joypad polling for the rest
of the frame [Jonas Quinn]
- Nintendo 64: fixed cartridge flash memory support
- Master System: VDP line coincidence should be initialized to $ff [fixes
Shadow Dancer]
- Master System: VDP sprite overflow index defaults to $1f, not $00 [fixes
PGA Tour Golf]
- SN76489: corrected port latching behavior and noise volume writes [fixes
Micro Machines]
- TMS9918: greatly refactored code
- V9938: greatly refactored code
- Z80: disassembler fixes
- lucia: corrected mapping of Master System pause button [fixes Baku
Baku Panic]
- nall: disable -Wstringop-overflow for GCC due to compiler heuristics error
- Master System: emulated sprite zoom and fifth-sprite status flag
- Master System: corrected VDP background emulation for mode 4 [fixes
Codemasters games]
- Master System: latch VDP background nametable address and scroll registers
[fixes Desert Speedtrap]
- Master System: mask CRAM reads to 6-bit in Master System mode [fixes Mercs]
- Master System: refactored VDP code
- Z80: swapped IND/INI to post-decrement B, and OUTD/OUTI to pre-decrement B
- lucia: fixed a crash when loading Game Gear games due to stubbing out
the BIOS
- Mega Drive: improved EEPROM emulation
- Nintendo 64: fixed CPU SCC counter rate [simer]
- Nintendo 64: added initial emulation of the SM5K processor (not connected
yet)
- lucia: update frame rate from the main thread to prevent a race condition
with GTK
- Famicom: added database entries for Jajamaru Gekimaden and Mazase Top
Pro PRG-RAM
- M24Cx: rewrote emulation to be more complete; though still not working
for Cxx/Cxxx sizes
- Nintendo 64: try stopping SI polling on recv=0xfe
- Nintendo 64: ignore A15 on controller pak reads and writes
- Master System: implemented Codemasters, Korea, MSX, Janggun mappers
- Master System: improved Sega mapper emulation
- Master System: added initial emulation of port $3e
- Master System: added support to load BIOSes
- Master System: initialize stack pointer to 0xfffd when no BIOS loaded
[Luke Usher]
- Game Boy Advance: emulated BIOS swap register [MerryMage]
- Mega Drive: cancel pending IRQs when they are disabled [Jonas Quinn]
- Mega Drive: fixed handling of VDP field flag [Jonas Quinn]
- Mega Drive: mask upper bit of VDP sprite Y value when in progressive
display mode [Jonas Quinn]
- X24C01, M24Cxx: improve emulation of EEPROM command sequences
This one is an experiment to ignore A15 on memory pak reads+writes. If possible,
I'd like to know if any games with controller pak issues start working with this
change that didn't before ^-^;
- Mega Drive: fixed a bug with LINEA and LINEF instructions (should not
decrement PC)
- Mega Drive: added EEPROM emulation
- mia: added Mega Drive and Mega 32X EEPROM database entries
- nall: added priority_queue::remove(T) support
This doesn't justify a new WIP release yet, but it changes the PI DMA delay
timing which seems to make Aidyn Chronicles work again, so let's see how it
does.
- Nintendo 64: improved SI scanning of PIF RAM and emulated more flags
- Nintendo 64: added very accurate controller pak initialization code
- Nintendo 64: improved controller analog stick approximations [MerryMage]
- Nintendo 64: added priority queue to delay SI and PI DMA transfers
- Master System: added bit-perfect YM2413 instrument patch sets
This fixes a major issue with the 68K ADD,CMP,SUB instructions not clipping, and
improves the VDP scanline renderer timing somewhat.
This fixes Alien Solder, and I also moved the DMA run below the FIFO/prefetch to
fix Comix Zone's graphics. It regresses several Titan Overdrive 2 screens, but
oh well.
I'm trying to track down a bug in Popful Mail (US) where the CPU crashes right
after the title screen. It seems like the CPU is getting stuck in a loop that
keeps calling the same function, so the stack keeps decrementing until it ends
up overwriting the currently executing code with a bad instruction.
Without an I/O tracer it's really difficult to try and understand what the CPU
is stuck waiting on and looping on. I'll have to add an I/O tracer to the Mega
CD registers.
The CPU fixes sadly didn't improve anything in the 32X space. Metal Head gets in
a loop until it overwrites the stack frame return address with 0x1fff1fff that
causes a return to an unaligned address that crashes the SH2 master.
After Burner Complete doesn't boot at all. Amazing Spider-Man still has screwed
up graphics priority ordering for the 32X VDP.
Space Harrier still shows a bunch of junk lines at the top and bottom of the
screen.
The scanline VDP can now run Lemmings 1&2, Alien Soldier, etc. But it still does
horrifically bad with Titan Overdrive, especially 2.
This release provides improved Nintendo 64 and Mega Drive emulation, plus some
emulation speedups and new features like keyboard-mapping for all Nintendo 64
controls.
The infamous Titan Overdrive demos now run with the exception of one glitched
screen each, but you will need to compile with profile=accuracy to enable the
required cycle-based VDP renderer for this to work. I'll try in the future to
support as much of it as I can with the default scanline renderer as well.
Changelog (since v119):
- SH2: added support for Windows ABI to the recompiler
- SH2: MAC must increment R[n] before reading from R[m]; fixes Virtua
Fighter and Toughman Contest
- SH2: fixed dynarec MOV @Rm+,Rn to not increment when Rm==Rn
- SH2: fixed dynarec TST instruction
- SH2: improved dynarec accuracy by breaking blocks on delay slot branches
- SH2: improved dynarec accuracy by decreasing the underclocking amount
- Mega Drive: implemented undocumented VSRAM and CRAM DMA fill
- Mega Drive: simplified scanline VDP renderer; fixes TMNT: Tournament
Fighters graphics
- Mega Drive: improved region detection; correctly identifies Alien Soldier
region now
- Mega CD: fixed crash on game load
- Super Famicom: fixed direct color mode; fixes Secret of Mana world map
- WonderSwan Color: fixed initial state for new EEPROMs plus EEPROM size;
fixes missing sound
- lucia: fixed saving RAM files when a manual save path was specified
- ruby: fixed library dependency detection for Arch Linux and other
distributions
- SH2: additional correction for dynarec MOV @Rm+,Rn instructions
- hiro/GTK3: added CSS stylesheet overrides to improve appearance [Screwtape]
- N64: VMRG was not clearing VCO in C++ version [Rasky]
- N64: fixed "ctc2" in the disassembler
- Mega Drive: VDP address/command bits are set even for non-register writes
[Eke]
- Mega Drive: implemented VDP FIFO with approximated timings
- Mega Drive: implemented CPU bus arbitrator
- N64: fixed RSP vector unit register values in the disassembler
- Mega Drive: implemented proper VDP FIFO timings for both reads and writes
(hopefully)
- Mega Drive: enabled external and RAM refresh timing
- Mega Drive: added (Mega Drive | Mega 32X) + Mega CD mode 1 emulation
- Mega Drive: refactored dot-based VDP renderer
- ares: added Thread::restart() function to reset a thread without resetting
its clock
- Mega Drive: improved DRAM refresh timings
- Mega Drive: added VDP I/O logger
- Mega Drive: fixed VDP counter emulation (still inaccurate)
- Mega Drive: improved VDP DMA and FIFO emulation
- Nintendo 64: report 64DD as missing for now; fixes F-Zero X
- Nintendo 64: improved TLB emulation; fixes Conker's Bad Fur Day
- Nintendo 64: PI DMA from flash always reads data, never the status;
fixes Paper Mario
- Mega Drive: improved VDP FIFO emulation
- Mega Drive: improved VDP dot-renderer
- nall/bit-range: fixed bug with bit indexes >= 32
- Mega Drive: fixed VDP read buffer indexing for VSRAM and CRAM
- Mega Drive: fixed 68K to VDP DMA so that it instantly freezes the CPU
- Mega Drive: emulated VDP left window hardware glitch where hscroll&15!=0
- Mega Drive: improved CPU interrupt handling
- Mega Drive: added APU bus mirrorings
- Mega Drive: emulated the VDP debug register
- Mega Drive: fixed VDP VRAM DMA copy
- Mega Drive: improved 128KB VRAM mode support
- Mega Drive: mask sprite attribute table address in H40 mode [Sik]
- Mega Drive: VDP timing improvements
- Nintendo 64: improved EEPROM support; fixes Perfect Dark
- Nintendo 64: improved VI interrupt support; fixes Star Wars: Rogue Squadron
title screen [nodev]
- Nintendo 64: emulated CIC-NUS-6105 copy protection; fixes Banjo-Tooie
[XScale]
- Nintendo 64: added serrate (interlace) support and fixed bug when
supersampling in serrate mode
- Nintendo 64: emulated CPU instruction cache
- Nintendo 64: emulated CPU data cache
- Nintendo 64: emulated CPU CACHE instruction
- Nintendo 64: fixed CPU TLB bug; fixes GoldenEye
- Nintendo 64: began adapting CPU cached interpreter into a dynamic
recompiler
- Nintendo 64: began adapting RSP cached interpreter into a dynamic
recompiler
- Nintendo 64: added 64-bit addressing and TLB supporting
- Nintendo 64: added endian support to [LS][WD][LR] instructions
- Nintendo 64: improved dynamic recompiler
- PlayStation: began adapting CPU cached interpreter into a dynamic
recompiler
- lucia: allow mapping analog axes separately (allows mapping sticks to
the keyboard)
- Nintendo 64: corrected analog stick ranges
- Nintendo 64: emulate the analog stick as an octagon rather than a circle
[YetAnotherEmuDev]
[This is actually the second release of v120; the change since the first release
is the N64 analog stick ranges and the octagon gate. -Ed.]
- Mega Drive: VDP scanline renderer compiles once more
- Nintendo 64: improved dynamic recompiler
- PlayStation: began adapting CPU cached interpreter into a dynamic
recompiler
- lucia: allow mapping analog axes separately (allows mapping sticks to
the keyboard)
All that's left now is fixing the call() function in the N64/PS1 to support >3
(4) arguments on Windows and we can release v120
- Nintendo 64: began adapting CPU cached interpreter into a dynamic
recompiler
- Nintendo 64: began adapting RSP cached interpreter into a dynamic
recompiler
- Nintendo 64: added 64-bit addressing and TLB supporting
- Nintendo 64: added endian support to [LS][WD][LR] instructions
I could really use a hand with my CPU dynarec, n64/cpu/recompiler.cpp line 1335.
When calling an FPU instruction without SCC coprocessor 1 enabled, it throws an
exception.
If I call the exception function, the emulator crashes hard and I don't
understand why at all.
The stack is aligned, but it seems if I modify rbx/rbp/r13 as I do with the
RSP+SH2 just fine, it seems to die. Yet even if I make that code restore
rbx/rbp/r13 before calling the coprocessor exception function, it still dies.
Really at a loss >_>
Also, this will only work on Linux/BSD at the moment. The RSP vector functions
pass four parameters, and my Windows call wrapper can only handle 3 arguments
because after that the argument has to go on the stack. I'll fix that later.
Working Nintendo 64 data cache emulation (still don't know the memory access
timings for it) and improved Mega Drive VDP emulation (still can't run TO1&2)
GoldenEye 007 and Jet Force Gemini run now. Right now, known N64 bugs are:
Donkey Kong 64 hangs when the EEPROM support is enabled, Indiana Jones doesn't
boot (probably anti-emulator code?), Blast Corps blinks a lot (though less than
it did before.)
This WIP has CPU instruction and data cache emulation, though I had to disable
the data cache as it's not working yet.
Three N64 game fixes. Refactored Mega Drive profile=accuracy vdp more, still
can't pass Titan Overdrive 1 or 2 ._. Really getting demotivated on that one.
[Previously, Near said "Now to fix sprite fetching on Y=-1"]
Should be substantially better now.
Titan Overdrive 2 shows distorted graphics on the "Overdrive 2" logo screen
(after the ship crash and maze run), and the only way to get that working is to
double the VDP FIFO speed. It already runs twice as fast in 128K VRAM mode. The
same FIFO speed doubling is required to not crash after the Titancade screen.
Unless I'm really fundamentally misunderstanding something, I'm not sure what's
going on here.
This gets us a lot further with the Mega Drive, but still some major issues.
Lemmings 2 will sometimes crash when you load it (not threading related), and
Titan Overdrive 2 crashes after the arcade scene. Ran out of steam to work on
this more today though, 12 hours in already.
This has VDP debug register emulation, well one of the 16 debug registers anyway
I fixed sound in TO2, was mirroring like crazy in the APU space, also fixed
sprites not rendering all the way in the rain scene.
So what you'll see I'm doing is setting an irq.(vh)blank.pending=1 flag, and
then whenever you have hvirq enabled AND a pending flag, it sends an IRQ to the
CPU and clears the pending flag, and when the CPU triggers it, the CPU marks it
as acknowledged.
Apparently BlastEm links bit 7 of the control status register to the
vblank.pending flag, so I'm copying that.
[Near then posted a screenshot of Titan Overdrive 2 running inside ares. In
white text on a blue background, it says:
0D2 B50D
D0 00000001
D1 00FF2700
D2 93979301
D3 40000002
D4 0D12001C
D5 00000000
D6 00000001
D7 0000FFFF
A0 00C00004
A1 00C00000
A2 00000CBC
A3 00000DEC
A4 00FF1464
A5 00FF0C1A
A6 00FF0C1A
A7 00FFFFFE
-Ed.]
Crashes here if I don't lower the CPU H/VIRQ lines on Vblank/Hblank=0
Also I am faking the Vcounter incrementing early when reading the Vcounter,
easier that way.
Really substantial Mega Drive profile=accuracy timing improvements, but still
Titan Overdrive 2 performs much worse than the default performance profile, and
that fucking audio driver still won't play any sound.
- Nintendo 64: report 64DD as missing for now; fixes F-Zero X
- Nintendo 64: improved TLB emulation; fixes Conker's Bad Fur Day
- Mega Drive: improved VDP FIFO emulation
- ares: added Thread::restart() function to reset a thread without resetting
its clock
- Mega Drive: improved DRAM refresh timings
- Mega Drive: added VDP I/O logger
- Mega Drive: fixed VDP counter emulation (still inaccurate)
- Mega Drive: improved VDP DMA and FIFO emulation
- N64: fixed RSP vector unit register values in the disassembler
- Mega Drive: implemented proper VDP FIFO timings for both reads and writes
(hopefully)
- Mega Drive: enabled external and RAM refresh timing
- Mega Drive: added (Mega Drive | Mega 32X) + Mega CD mode 1 emulation
- Mega Drive: refactored dot-based VDP renderer
A working VDP FIFO implementation (write slots only), but probably wildly
inaccurate. Rough timing approximations for the slots.
This build fixes some issues in MD Sonic the Hedgehog (forgot to undo the
background color register bit twiddling when reverting some overly aggressive
VDP-performance optimizations) and also fixes MD Golden Axe II.
I spent a few hours trying to fix Lemmings 2 from locking up immediately. What
happens is I get a fourth Hblank IRQ before it clears a RAM value, whereas
Mednafen only gets three. And that desyncs something and it never gets out of a
loop.
Unfortunately a few critical issues crept in between v118 and v119, so here is a
bugfix release for all reported issues.
It also fixes some game bugs while I'm at it, and boosts 32X compatibility from
50% to a little over 60%.
Please do upgrade if you have v119, this one's important.
- SH2: MAC must increment R[n] before reading from R[m]; fixes Virtua
Fighter and Toughman Contest
- SH2: fixed dynarec MOV @Rm+,Rn to not increment when Rm==Rn
- SH2: fixed dynarec TST instruction
- SH2: improved dynarec accuracy by breaking blocks on delay slot branches
- SH2: improved dynarec accuracy by decreasing the underclocking amount
- Mega Drive: implemented undocumented VSRAM and CRAM DMA fill
- Mega Drive: simplified scanline VDP renderer; fixes TMNT: Tournament
Fighters graphics
- Mega Drive: improved region detection; correctly identifies Alien Soldier
region now
- Mega CD: fixed crash on game load
- Super Famicom: fixed direct color mode; fixes Secret of Mana world map
- WonderSwan Color: fixed initial state for new EEPROMs plus EEPROM size;
fixes missing sound
- lucia: fixed saving RAM files when a manual save path was specified
- ruby: fixed library dependency detection for Arch Linux and other
distributions
- hiro/GTK3: added CSS stylesheet overrides to improve appearance [Screwtape]
I'm releasing ares v119 today, which includes very preliminary Sega 32X
emulation support. Compatibility is currently at around 50% with the dynamic
recompiler, probably closer to 75% with the cached interpreter, and since the
system requirements were a bit too steep (on account of my Mega Drive core being
cycle/dot-accurate), I downclocked the SH2s a bit until I can speed up the
emulator more. You'll currently need about a Ryzen 5 2600 to hit 60fps reliably.
With the underclock, my Ryzen 7 5800X hits 120fps, and without it, 85fps.
Although the compatibility for the new 32X core is a bit low, this is mostly due
to pesky CPU bugs. The accuracy is quite high and I've emulated as much of the
32X and SH7604 peripheral functions as possible. I pass all 161 tests from the
Mars Check Program. It should not take much more work to reach 98% compatibility
in the future. Sega CD 32X emulation support is present, but is likely not
functional, as I haven't tested it yet.
Other major features in this release include Sega SVP support for Virtua Racing,
plus improved Nintendo 64, Mega Drive, and Mega CD emulation compatibility.
I'm going to start working on Sega Saturn emulation now, while Luke Usher works
on Neo Geo emulation. No promises as to when or if these cores will become
playable, I'm just giving you all a heads up since you'll see the skeletons for
these systems in the source code now.
Changelog:
- Nintendo 64: improved Expansion Pak detection
- Nintendo 64: fixed swapped L and R buttons [simer]
- Nintendo 64: emulated the RST bit for gamepads
- ruby: added library detection support for the Linux and BSD targets
- lucia: gained support for game paks (custom file dialog only)
- Super Famicom: added support for Super Game Boy, Sufami Turbo, and BS
Memory packs
- hiro: made SourceEdit optional for gtk2 and gtk3 targets (disabled
for ares)
- Nintendo 64: emulated 2048-byte EEPROM identifier and transfer protocol
- Super Famicom: corrected ppu-performance widths table indexing to consider
overscan
- Mega CD: fixed a bug in register $ff8003; allows Popful Mail to boot
[TascoDLX]
- Mega Drive: fixed a bug with 256-width video modes
- Mega Drive: improved VDP DMA emulation which should fix many games
- Mega Drive: added SVP emulation
- Mega Drive: added 32X emulation
- Mega CD: fixed a bit-masking bug in register $ff8004; fixes Radical Rex
[TascoDLX]
- Nintendo 64: fixed C implementation of RSP VMACU instruction
- Nintendo 64: use correct NTSC and PAL PIF ROM images based on the region
- Mega Drive: fixed reset logic, Z80 interrupt timing + prefix timing +
bus control [TascoDLX]
- Mega CD: fixed word RAM access and CDC DMA word RAM transfers [TascoDLX]
- Nintendo 64: improved RSP VMOV emulation [Rasky]
- Nintendo 64: fixed RSP DMEM DMA alignment (&~7, not &~3) [Rasky]
- Nintendo 64: upgraded to the latest version of ParaLLEl-RDP
- nall: greatly expanded recompiler/amd64's supported intrinsics
- mia: substantial refactoring around a new virtual filesystem implementation
from nall
[This release was posted to the ares Discord after r16. That version introduced
128KB VRAM mode for the Super Famicom core, and somebody requested the previous
version so they could see the changes involved in implementing that feature.
-Ed.]
That's as far as I can go with 32X support for now. I fully emulated the Sh2
cache but I still hang at Mars test 123. The Hblank (2) test fails because it
looks like I'm running a bit too fast. The DMA test fails because it expects
DREQ to become inactive when the DREQ length hits zero. If I do that, the test
hangs. If I don't do that, the test fails.
Virtua Fighter shows no graphics in-game, Virtua Racing shows no graphics
period.
Knuckles Chaotix is now fully playable at glorious 20fps, heh.
Still a whole ton of issues but I really went to town with this WIP. I
implemented read/write functionality for all the SH7804 internal
registers/functional units, and added basic simulation of the free-range timer,
DMA controller (very basic) and interrupt controller.
On the 32X side, it should be functionally complete save for bugs now. VDP and
PWM are fully implemented.
I am getting my ass kicked by SH-2 delay slots >_>
The basic idea of them is simple, but the PR register and when to do the +4 or
+2 or not is not intuitive.
SH-2 core finished, started connecting the 32X to it. It executes some
instructions and does some I/O register stuff before hanging. Still gotta
implement the 32X interrupts, PWM, and VDP stuff.
Here's the current build with working SVP support. Build with profile=accuracy
if you try it because my fast scanline renderer breaks soooo many games
including Virtua Racing ._.
This WIP has the new mia system. It's a pretty massive change ... I hope it will
go okay for you. Feel free to ping me and I'll walk you through it.
Essentially, we want to edit mia/system/neo-geo-(aes|mvs).cpp to load in the
necessary files from MAME's neogeo.zip that is given to it (I have a helper
Pak::read(zipfile, pattern) function to grab files out of the archive for you
into a vector<u8>), do endian conversion, add to the pak, then the Neo Geo core
can see it.
The Neo Geo cartridge support should be enough for Magician Lord and super early
games with no mappers or crypto, so we'll start there and work our way up.
My tracer was crashing in v118 for the Mega CD due to the trace address not
being masked and the value underflowing, so here's a pre-v118.4 WIP with that
fixed.
So, spoiler since you'll all see it: Luke and I are gonna be working on a
Neo*Geo core. Please keep that a secret for now until we can get some
screenshots to share with people.
Would appreciate feedack on the vfs redesign, still a work in progress. Right
now, the potential is there to have ares cores that don't use manifests at all.
So far, only the ColecoVision core actually does it. However, all cores are
ported to use the new Platform::pak() function instead of Platform::open() [now
removed.]
Lots of stuff is broken right now: N64/PS1 memory cards, PC Engine CD / Mega CD
internal save memory, Mega CD can't play any games, FDS and NGP don't save, etc.
I'm excited to launch ares v118 today, the first release featuring playable,
full-speed Nintendo 64 emulation!
The new Nintendo 64 emulation is made possible thanks to [Themaister] very
graciously porting his Vulkan-based ParaLLEl-RDP graphics renderer to ares. With
its default settings, it is nearly pixel-perfect to real hardware, and it
optionally supports upscaling to 2x or 4x the original Nintendo 64 resolution,
plus optional supersampling back down to the original resolution (for enhanced
anti-aliasing) if desired. The Vulkan support requires an appropriate graphics
card, and either Windows or Linux. At this time, Vulkan is not available for
macOS nor the BSDs.
Also new for the Nintendo 64 core in this release is Rumble Pak, Cartridge Pak,
SRAM, EEPROM, and Flash save support. Note that for right now, the Rumble Pak
will only be enabled for games which use internal saves (SRAM, EEPROM, and
Flash.) That does not cover all Rumble Pak-capable games. The option to choose
between Rumble Paks and Cartridge Paks will be added to a future release.
For the PlayStation core, [Luke Usher] provided two rendering fixes that allow
Final Fantasy VII and Tony Hawk's Pro Skater to be fully playable!
Right now, approximately 33% of the Nintendo 64 library is fully playable, and
about 67% of the PlayStation library is fully playable. Each core has only been
under active development for about one month each, so they both have a long way
to go. Please treat these early releases as tech samples, rather than finished
emulation cores.
Further, note that the Nintendo 64 and PlayStation cores employ cached
interpreters. This is a middle-ground between the accuracy of interpreters and
the performance of dynamic recompilers. As such, ares' system requirements will
be a bit higher than traditional emulators for these systems. Presuming no
background task interference or CPU throttling, generally speaking, a Ryzen 5
2600 or better CPU should get you to around ~120fps in the average case, and
~60fps in the worst case.
The source code has also been released under the terms of the Creative Commons
BY-NC-ND 4.0 license.
[Themaister]: http://github.com/Themaister/
[Luke Usher]: https://twitter.com/LukeUsher1
Ridge Racer now boots and gets in-game, but likely GTE errors prevent it
from being very playable yet.
- PlayStation: added DMA IRQ support
- PlayStation: added more GTE instructions
- ares: started on a new Debug class for notifications (unimplemented
features, etc.)
- PlayStation: improved timer support
- PlayStation: added more GPU GP0 rendering commands
- lucia: split the emulator list and emulator options into separate
settings panels
- lucia: added fast boot option for PlayStation and Neo Geo Pocket
cores
- PlayStation: fixed masking bug in LWL and LWR instructions
- PlayStation: improved timer support
- PlayStation: added EXE side-loading support
- PlayStation: added fast boot support
- PlayStation: added libc putchar logging support
- PlayStation: started implementing controller support
- PlayStation: improved texture semi-transparency support
- PlayStation: fixed a bug in render clipping
- Super Famicom: mosaic fix wasn't exactly right before; now it should
be
- PlayStation: started implementing CD interface
- PlayStation: started implementing GTE coprocessor
- Super Famicom: fixed bugs in hires + interlaced mosaic rendering
- PlayStation: started implementing the SPU (no DMA, CD-DA, reverb, or
sweep support yet)
I've started on a Sony PlayStation emulation core with this WIP. The
goal is to work on the MIPS CPU core while I am still well-versed with
the MIPS ISA. The Nintendo 64 core will remain my primary focus,
however.
- PlayStation: implemented initial driver skeleton (no emulation code
yet)
- lucia: added option to group the load menu options into submenus by
manufacturer
- lucia: connected Cocoa-specific application menu options to their
appropriate callbacks
- hiro/Cocoa: fixed compilation issues for HexEdit (the widget is not
implemented, however)
- hiro/Cocoa: fixed a subpixel precision rendering issue causing
blurry fonts [LIJI]
This WIP adds non-SIMD implementations of all RSP vector unit
functionality. This allows compiling without SSE, but was mainly added
for debugging SSE issues. It's also useful for documenting in code what
the SSE instructions are doing in C++ code.
- Nintendo 64: added non-SSE implementation of RSP vector unit
The new recompilers increase the framerate in Namco Museum from 60fps to
160fps, and in Zelda: Ocarina of Time from 55fps to 135fps (presuming no
RDP renderer.)
- Nintendo 64: completed basic CPU dynamic recompiler
- Nintendo 64: completed basic RSP dynamic recompiler
- N64: redesigned the bus handler
- N64: execute eight CPU instructions per synchronization event
- N64: range test the CPU Compare register
- N64: decode more RDP display list commands
Many N64 games are now playable.
- N64: VSUB should clear VCO
- N64: corrected VRCP(L) and VRSQ(L) instructions
- N64: many other smaller various fixes
- N64: added missing BLTZAL, BGEZAL instructions
- N64: added missing SLT, SLTI instructions (they were erroneously
aliased to SLTU, SLTIU)
- N64: mask low two bits of PC when writing to SP_PC_REG
- N64: refactored RSP DMA; only mask the low two bits SP_PBUS_ADDRESS
- N64: RSP DMA seemingly updates SP_PBUS_ADDRESS and SP_DRAM_ADDRESS
- N64: added PIF boot ROM emulation
- N64: detected NUS-CIC revision based on ROM bootcode checksum
- N64: added skeleton I/O reading and writing for all VI and PI
registers
This WIP separates the RSP SCC registers so that RDP rendering commands
are not processed inside of the RSP. The register interface is shared
between the SCC and the CPU bus, so there is no technically correct
location for these handlers.
- N64: moved RSP SCC registers to outer RSP and RDP I/O handlers
- N64: improved audio playback (AI_LENGTH &=~ 7, not (AI_LENGTH | 7) +
1)
- N64: improved exception handling (ERL bit isn't set on standard
exceptions)
- N64: added very incomplete, inital TLB emulation
- N64: various improvements to the disasssembler (including FPU
instruction support)
- N64: improved SI emulation (Namco Museum input now works)
This WIP boots the first official Nintendo 64 title, Namco Museum. It
remains to be playable, however.
- N64: improved interrupt handling
- N64: implemented basic state machine handling for PI serial data
transfers
- N64: resume previously executed instruction after ERET for non-
interrupt exceptions
- N64: various other improvements
- N64: removed libco completely, using direct cycle counters now
instead
- N64: emulated RSP DMA between IRAM/DRAM and RDRAM
- N64: emulated RSP core R4000 instructions
- N64: started working on RSP COP2 vector instructions
Emulation is now far enough along to complete the boot loading code and
begin executing game code. The "hello world" CPU rendering demo now runs
correctly in both 15bpp and 24bpp output modes.
- N64: implemented skeleton interfaces (MI, VI, AI, PI, RI, SI)
- N64: implemented PI DMA
- N64: added basic frame buffer rendering (320x240 only)
- VR4300: implemented register-immediate instructions
- VR4300: implemented half of the general instructions
- ares: added Port::supported() -> vector<string> API
- nall: improve checks in directory::exists() and directory::create()
- PC Engine CD: fixed Arcade Card emulation bug in register I/O
address decoding
- PC Engine CD: fixed a bug with ADPCM DMA
- Super Famicom: implemented more of the HG51B disassembler (still
very incomplete)
- PC Engine: added support for Populous save RAM
- PC Engine: attached debugging Node::Memory objects to HuCards with
RAM
- PC Engine: split System Card and Super System Card emulation into
separate classes
- PC Engine: added Arcade Card Duo and Arcade Card Pro emulation
(though it isn't working yet)
- PC Engine Duo: added emulation support (as a separate interface;
requires SSC 3.0 BIOS)
- lucia: display warning message when loading games if the save
directory is unwritable
- lucia: display error status message when capturing a screenshot to
an unwritable directory
- nall: added nall/encode/png.hpp (uses optipng or pngcrush for
optional compression)
- luna: capture screenshots in PNG format instead of in BMP format
- lucia: capture screenshots in PNG format instead of in BMP format
- PC Engine CD: emulated drive seek delays
- PC Engine CD: emulated CD-DA and ADPCM audio volume fader
- PC Engine CD: corrected ADPCM $180d flags (fixes many ADPCM playback
issues)
- PC Engine CD: use live playing flag for $180d.d5 (fixes Popful Mail
hanging bug)
- PC Engine CD: supported SCSI command 0xd9 CDDA playback mode (loop,
notify, stop)
- mia: use nall/vfs/cdrom to convert images on import (more complete;
shares code)
- mia: added identify(filename) function to detect what system a given
game image is for
- mia: added medium(name) to locate a Media object to use
- lucia: replaced Emulator::extensions with Emulator::medium
This WIP has started on a stream manager, which for now only allows you
to mute individual streams, but in the future it could be nice to expand
this tool to selectively configure bandpass filters and more.
- ares: added Node::Stream::setMuted(bool) function
- lucia: added audio stream manager to selectively mute individual
streams (for debugging purposes)
- lucia: include system name in recent games entries, to disambiguate
Mega CD and PC Engine CD games
The first officially licensed PC Engine CD games are now playable:
Bomberman '94 Taikenban and Deden no Den.
- ares: emulated the OKI MSM5025 ADPCM chip
- PC Engine CD: added ADPCM playback support (incomplete)
- PC Engine CD: various emulation improvements
- nall/vfs/cdrom: build image in-memory (required to support the below
features more easily)
- nall/vfs/cdrom: support multiple files per CUE sheet
- nall/vfs/cdrom: support WAV audio files
This release implements enough of the PC Engine CD to boot its first
software title, Chris Covell's Screen Dimension Test. There's a large
amount of work that remains before commercial titles will be playable,
however.
- PC Engine CD: started implementing SCSI commands
- nall/decode/cue: new decoder for parsing CD-ROM CUE sheets
- nall/vfs/cdrom: support ISO images
The base tree initialization rewrite is completed, however there remains
work to be done with attaching peripherals not unserializing properly.
But it's a solid start.
- ares: ported all cores to the new simplified tree construction
This WIP marks the start of an effort to simplify the process of
initializing system trees in ares. Before, all load functions had to
take both a parent Object, and a shadow source Object. During the
construction of every Object, the attributes and values of the shadow
Object would be copied in.
The goal here is to instead construct system trees only from parent
Objects, and then once the system tree has been constructed, copy a
serialized tree into the actual system tree. What makes this difficult
is that the serialized tree will have peripherals connected to ports,
resulting in a much larger tree. So the copy function has to specialize
on ports to create and attach said peripherals to the actual system
tree, and then continue unserializing the shadow tree to the actual
system tree.
In any case, so far this new approach is working, thankfully. This
reduces a substantial amount of boilerplate that was previously needed
inside every single emulation cores in ares. But it will take many WIPs
to slowly convert all twelve emulation cores to the new design. I made
this change in a way that the other cores will continue to function as
expected, so both designs are currently fully functional. Once every
core has been ported, I will start removing the boilerplate
functionality that was needed for the old design.
- ares: created Object::copy(Node::Object)
- Famicom: started simplifying tree construction
- Famicom: renamed NES-* boards to HVC-*
- Famicom, Super Famicom, Mega Drive, PC Engine: restructured
cartridge slot and expansion port handling
- hiro/Qt: fix crash on exit by destructing all UI objects first
[baraclese]
- ruby: removed Input::onHotplug(); luna and lucia handle hot-plugging
automatically
- Famicom: refactored SxROM and MMC1 into a single class
- Famicom: converted generic class variable types (bool, uint) to
uint# types
- Game Boy Advance: fixed a bug with keypad interrupt handling (keypad
array was erroneously marked static)
- all: moved inline designators from function designators to function
declarations
- ColecoVision: added memory editing support (CPU only; no VDP support
yet)
- Famicom: added memory editing support
- Game Boy + Game Boy Color: added memory editing support
- Game Boy Advance: added memory editing support
- Master System + Game Gear: added memory editing support
- MSX: added memory editing support (CPU only; no VDP support yet)
- SG-1000 + SC-3000: added memory editing support (CPU only; no VDP
support yet)
- SG-1000 + SC-3000: $c000-ffff maps to system RAM, not cartridge RAM
- Neo Geo Pocket + Neo Geo Pocket Color: added memory editing support
- WonderSwan + WonderSwan Color: added memory editing support
- ruby: added joypad hotplugging support to the SDL 2.0 driver
- ruby: added workaround for FreeBSD's SDL 2.0 port not supporting
SDL_JOYDEVICE(ADDED|REMOVED)
- lucia: support new ruby::Input::onHotplug() callback to
automatically refresh input mappings
- Mega Drive + Mega CD: added memory editing support
- lucia: implemented graphics viewer and export tool
- Super Famicom: added graphics viewing support to the accurate
renderer
- all: Makefile improvements (obj and out paths are no longer hard-
coded)
- all: renamed Screen::Region<String> to Screen::Overscan<Boolean>
- lucia: implemented bsnes' multiple-mappings per input system
- lucia: implemented memory editor and export tool
- Super Famicom: added memory editing support
- PC Engine: added overscan setting to the dot-based renderer (256 ->
272 width)
- restructured project layout by moving targets (luna and lucia) out
of ares
- added ares logo to lucia, luna, and mia's about dialog
- lucia: added screenshot capture tool (captures the *next* frame
rendered)
Initial release; fork of **higan** v110.
- the project and core library is now called **ares**
- the simplified user interface is now called **lucia**
- the advanced user interface is now called **luna**
- the game analyzer is now called **mia**
- removed the database editor **genius** from the project
- PC Engine: adjusted rendering viewport for the scanline renderer
from Y=18 to Y=21
* PC Engine: emulate MPR latch used by TMA and TAM instructions
* PC Engine: randomize various registers and memory at power-on
* PC Engine: do not allow block moves to read from $ff:0800-17ff
* PC Engine: always set P.B flag (except when pushing P during BRK)
* PC Engine: clean up and improve CPU IRQ handling
* PC Engine: delay PSG synchronization when not needed (~8% speedup for accuracy core)
* PC Engine: emulate 4-color background and sprite modes (partial; fixes Fighting Run sprites)
* PC Engine: emulate grayscale VCE mode
* PC Engine: emulate extra scanline VCE mode
* PC Engine: improve burst-mode emulation (including VRAM->VRAM early termination)
* PC Engine: fixed VRAM->VRAM DMA transfers (was transferring one byte less than it should)
* PC Engine: reposition background and sprite scanline latching slightly (for Toy Shop Boys flickering)
* PC Engine: improve Vblank handling when vertical timing registers exceed 261 scanlines
* PC Engine: added vertical timing latching to scanline renderer as well
* Mega Drive: fix crash when loading Sonic & Knuckles or Game Genie without a daughter cartridge
* all cores: add unload() to all cartridge and controller ports
* byuu: focus the viewport after loading games
* icarus: fix typo in save RAM portion of the manifest (was marked as ROM by mistake)
* PC Engine: improved IRQ handling significantly, fixes many games
* PC Engine: improved VDP penalty cycle timing
* PC Engine: emulated all T=1 mode instructions, not just immediate mode
* PC Engine: fixed T-Memory instructions (fixes Gai Flame and Dragon Spirit)
* PC Engine: run VDS first instead of VDW at the start of new frames (fixes Davis Cup Tennis)
* PC Engine: disassembler improvements
* PC Engine: add support for Street Fighter II CE's custom mapper
* higan: fix System menu option enabling when "Create New System" is selected
* byuu: don't show the program icon in the main window briefly when switching games
* Sega CD: mask CDC DMA d0-d2 bits on address register set [EkeEke]
* Sega CD: merge CDC PCM DMA fix verbatim [EkeEke]
* Sega CD: reset all state on power cycle
* disable context menu on "Create New System" list item
* PC Engine: disassembler improvements
* PC Engine: CPU instruction timing improvements
* PC Engine: fix VDC DCR writes (fixes Gaia no Monshou, Magical Chase, etc)
* PC Engine: added Avenue Pad 6 emulation (higan only for now)
* Mega CD: CDC PCM DMA can only write to current bank [EkeEke]
* PC Engine: trigger VDC coincidence IRQs at start of scanline
** (fixes Bomberman '94, Air Zonk start screen rendering issues)
* added higan::Node::enumerate() to find all nodes of a given type
* Famicom: emulated the X24C01 EEPROM for Bandai-FGC boards
** (no X24C02 support yet)
* nall: fixed a subtle yet critical issue with Natural/Integer::bit()
** (values out of range were not being masked out upon assignment)
* add support for deterministic serialization (save states)
* add support for run-ahead (has issues on GBA and MSX cores, however)
* SFC/Performance: do not render scanline 0
* SFC/Performance: fix rendering of mixed-resolution screens
* SFC/Performance: add raster override for Air Strike Patrol
* PCE/Performance: complete VDP serialization support
* SFC: scanline renderer - fixed an issue where the backdrop color was showing while the screen was disabled
* SFC: scanline renderer - fixed an off-by-one issue with the vertical sprite positions
* SFC: scanline renderer - added known scanline render position overrides from bsnes
* SFC: dot renderer - fixed an issue with scrolling in hires mode
* MS: fixed the pause button mapping (also, it binds to the start button now)
byuu v1:
* SNES: fixed hires and interlace rendering with new scanline-based renderer
* Mega Drive and Neo Geo Pocket (Color): default to English/NTSC-U for multi-region games
* Windows: fix an occasional crash when unloading games
* Windows: fix beeping sound when assigning inputs and hotkeys
* Neo Geo Pocket: added flash ROM save support
* Super Famicom: improved appended firmware size detection [devinacker]
* ruby: added dynamic rate control support to Linux/ALSA driver [RedDwarf]
* ruby: added dynamic rate control support to Linux/PulseAudio driver [RedDwarf]
byuu v0.14:
* PC Engine: fixed sprite rendering issue
* PC Engine: nearly doubled performance via audio decimation
* Game Boy Advance: 20% performance increase via lower-precision CPU synchronization
* added auto-save memory option
* added optional native file dialog support
* added warning when trying to map inputs with no input driver active
* abort input mapping attempts after closing settings window
* added 50ms delay for input mapping so that pressing enter won't automap said key
byuu v0.12:
* capture keyboard during input and hotkey assignments
** (prevents bell sound on Windows)
* support Trigger.Hi input mapping
** (will make mapping triggers harder, unfortunately)
* Mega Drive: added scanline renderer (~85fps to ~210fps average)
* Super Famicom: renamed "Cartridge Port" to "Cartridge Slot"
* Game Boy Advance: renamed "Screen" to "DAC"
SFC: fixed PAL region detection (for higan and byuu)
SFC: added scanline-based renderer (for byuu)
SFC: improved Super Game Boy MLT_REQ emulation [devinacker]
byuu v0.10
* fixed initial bindings for gamepad axes and hats
* allow multi-selection clear on input mappings
* added path searching to higan::Node::find()
* added higan::Node::scan() to locate relative tree nodes
* exposed settings for color bleed/emulation, interframe blending, overscan
* default to Path::desktop() instead of Path::user() for loading games
* started on scanline-based renderer for the SNES
byuu v0.9
* update driver settings when changing audio and input drivers
* correct sound output when not outputting at 48KHz
* correct sound output when changing frequency after game is loaded
* show program icon when game is not loaded
* move from native status bar to higan/bsnes-style status bar
* fix a bug with WonderSwan internal EEPROM data
* fix hotkey polling in fullscreen mode
* added joypad support
I've started on a new multi-system emulator, byuu.
It will share all cores with higan, and as such will be focused on accuracy and self-documenting code foremost.
But unlike higan, I will do everything possible to make the program featureful and easy to use.
The way I'm doing this is through a translation layer to abstract higan's tree-view into a list-view.
The list-view is similar to higan v106 and earlier. I'm also going to add more ease-of-use improvements from bsnes.
The list-view will sacrifice support for extreme edge cases, but should more than make up for it in ease of use.
bsnes' success greatly exceeded my expectations, and resulted in many improvements to higan's SNES core as well.
But unfortunately, bsnes is for the SNES only, and I just don't have the bandwidth to maintain 24 emulator projects.
As such, the goal of this project is to try and create an easy-to-use alternative for *all* of my emulator cores.
Right now, I'm maintaining this as an alternate user interface target inside the higan source tree.
Long-term, the intention is that higan and byuu will be equal emulators, rather than one being a superset of the other.
I don't know how that final form will look just yet, but for now, this will at least allow me to keep the history in Git.
I do ask that binaries not be distributed of byuu until the software is ready for release.
I wouldn't even recommend using it. It's not really functional at all yet. But it'll get there over time.
Fixed NES manifest lookups (mirroring, VRC pinouts, etc)
Corrected Game Boy CPU name strings
Updated databases to use SM83 instead of LR35902 for GB CPU naming
Sorry, I pasted the v107.1 changelog by mistake. The changelog for v107.3 is:
removed usleep() from main() during Application::modal()
* allows smooth window movement and resizing on Windows
Windows: added WS_CLIPCHILDREN to Window class
* prevents flickering of the viewport when moving the vertical resize grip
Windows: added WS_EX_TRANSPARENT to Frame class
* prevents drawing issues caused by WS_CLIPCHILDREN (which is why it was left off previously)
ASIO: ensure the minimum, maximum, and preferred buffer latencies are available in the latency list
ASIO: defer IASIO::start() until audio starts playing
* prevents bad ASIO drivers from segfaulting at application startup
ASIO: re-enabled the option for ASIO now that it can be enabled safely
* there is still an issue that many drivers (including Steinberg's) crash after music starts playing
Windows: added workaround for the audio settings panel not displaying properly on first-launch
GTK: added gtk_widget_queue_redraw() call after Widget::setGeometry() calls
* prevents minor redraw issues with higan's status bar when resizing the window
don't show "Disconnect" button when "Nothing" is selected if nothing is currently connected to a port
select the currently connected peripheral (or "Nothing" if disconnected) when selecting a port from the node manager
GTK: fix focus behavior to always work when changing which peripheral is connected to a port
disable any action on connecting an already-connected peripheral (was previously losing focus on the port connection panel)
hide events from the node manager (use the event manager instead)
added Node::Peripheral::manifest() API and connected it for all emulated cartridges, floppy disks, and CD-ROMs
added peripheral overview to see game manifests
removed Settings -> Advance Mode (failed concept; it didn't do anything)
removed v107 beta release warning message
removed video and audio driver activation (auto-activates at launch now)
add remove, rename, launch buttons to system overview panel
show system creation panel controls as disabled instead of hiding them when nothing is selected
added "Create New System" option to the top of the system manager panel list
added "Launch" option to system manager context and system menus
refresh the port connector list and select the newly created peripheral after creating new peripherals
fix an issue with showing "Import ..." button on port connector at inappropriate times
don't show "Disconnect" button when "Nothing" is selected if nothing is currently connected to a port
select the currently connected peripheral (or "Nothing" if disconnected) when selecting a port from the node manager
GTK: fix focus behavior to always work when changing which peripheral is connected to a port
disable any action on connecting an already-connected peripheral (was previously losing focus on the port connection panel)
hide events from the node manager (use the event manager instead)
added Node::Peripheral::manifest() API and connected it for all emulated cartridges, floppy disks, and CD-ROMs
added peripheral overview to see game manifests
removed Settings -> Advance Mode (failed concept; it didn't do anything)
removed v107 beta release warning message
SFC: disable math color bleed for first pixel
(fixes green line on the left-edge of Jurassic Park)
SFC/GG: attach Screen settings to Screen node, not PPU/VDP node
(fixes remembering Screen settings)
SFC: disable math color bleed for first pixel
(fixes green line on the left-edge of Jurassic Park)
SFC/GG: attach Screen settings to Screen node, not PPU/VDP node
(fixes remembering Screen settings)
Fixed focus issue with hotkeys.
Added sprite zoom emulation to TMS9918 and V9938 cores.
Improved clarity of ABCD and SBCD M68K instructions.
Fixes to ruby IOkit driver.
Added save state file size validation to all cores.
Added simple capture screenshot function.
Fixed macOS monitor name detection on multi-monitor systems.
Replaced the higan::Logger { Tracer, Notification } system.
Now uses Node::Event { Instruction, Notification } instead.
That is to say, loggable event sources are now part of the system tree.
The intention is do the same for higan::Video and higan::Audio soon.
* moved Screen, Sprite, Stream back to shared pointers
* fixed two SNES SA1 regressions
* added trace logging support to the GB and SNES cores
** (HG51BS169 not supported yet; uPD96050 and GSU are buggy still)
* WonderSwan: improve 1024-tile mode (fixes WSC IPLROM menu)
* WonderSwan: import boot ROMs from system template folders on first run
* WonderSwan: added automatic screen rotation support
* WS: added status icon emulation [icons by furrtek]
* WS: added option to use monaural speaker instead of stereo speakers
* WS,GBA: corrected screen rotation support
* WS: added proper keypad mappings for the Pocket Challenge V2
* WS: initialize EEPROMs as they would be from the factory
* added WonderSwan + WonderSwan Color IPLROM support [thanks furrtek!]
* split Microchip 93LCx6 emulation to shared component/eeprom class
* Game Boy MBC7 and WonderSwan EEPROMs now use 93LCx6 base class
* various WonderSwan emulation improvements
* provide actual display device names in ruby::Video::hasMonitors()
* macOS: fixed LineEdit::onChange (fixes state manager state naming)
* macOS: fixed RadioLabel height to not clip off bottom of radio icons
* macOS: fixed RadioLabel initial check states (fixed input settings
focus mode options)
* macOS: fixed TableViewItem::setSelected (fixes initial selection on
settings/tools windows)
* macOS: fixed TextEdit geometry (fixed manifest viewer)
* macOS: don't allow multiple TableViewItems to be selected in
single-selection mode
** (fixes settings/tools windows selecting multiple items via menubar
options)
The existing ppc implementation in libco only supports
the ELFv1 ABI on PowerPC 64 and therefore can't be used on
Little Endian systems and Big Endian systems running ELFv2
distros.
This commit introduces a new implementation of the libco
API for ppc64 elfv2. It has been tested with bsnes and higan.
The original ppc implementation is maintained for non-ELFv2
targets.
byuu says:
Moved operator() to .range() and operator[] to .field() for Natural/Integer
types. Also improved Super Game Boy emulation speed by ~16%, and removed the
need for two callbacks (but adding one new one). Joypad interrupts should now
work during CPU HALT and STOP as they're supposed to.
byuu says:
- higan: reset all thread clocks on power cycle
- higan: fix minor regression from WDC65816 CPU rewrite
- higan: fix nall::Integer casting regression
- higan: removed nall/bit-field.hpp and nall/bit-vector.hpp
byuu says:
- higan: don't create manifest.bml for peripherals created from
templates
- higan: fix binding of inputs when changing connected peripherals
- higan: fixed a Game Boy regression with an edge case in writes to
VRAM being blocked errantly
- higan: removed cheat code support (which was not working for most
systems; nor implemented in the new GUI)
- higan: corrected loading of BS Memory cassettes
- higan: added adaptive sizing option (changes the size of the program
window to fit the active system's video output size)
byuu says:
- ruby: fullscreen support for Windows OpenGL 3.2, DirectDraw 7.0, GDI drivers
- ruby: output(width, height) support for all drivers on all platforms
- hiro: improve focus capture for Canvas and Viewport widgets
- hiro: added two hotfixes for the macOS Cocoa target [Sintendo]
- higan, bsnes: focus the viewport after leaving fullscreen exclusive mode
- freebsd: moved from GCC 8.2.0 to Clang 6.0.1
- higan: added video display emulation option to Famicom and Mega Drive cores
The reason I moved to Clang was because GCC keeps deadlocking my FreeBSD system.
I don't know if it's GCC's fault, or suddenly running 32 copies of any high-CPU
usage program, heh. But at any rate, it's worth a try. The performance is the
same, but compilation takes a tiny bit longer with Clang.
byuu says:
- ruby: fullscreen exclusive support for XVideo and XShm video drivers
- ruby: support for 30-bit RGB under Xorg with OpenGL 3.2 and OpenGL 2.0
drivers
- bsnes: update libco, nall, ruby, hiro, sourcery
- bsnes: use new ruby::Video API for viewport sizing
- higan, bsnes: added EXLOROM, EXLOROM-RAM, EXHIROM mappings
- higan: added video display emulation option (NTSC 448p / PAL 480p output
selection)
- higan: reverted metadata.bml to manifest.bml
byuu says:
I merged the concepts of fullscreen and exclusive mode. There's no non-exclusive
mode anymore. I added support to the Linux/BSD OpenGL 2.0 and OpenGL 32 drivers
for the new fullscreen mode, which allows Gsync to work. I still have to add it
to the Windows OpenGL 3.2 driver. After that, I fixed a nasty issue with audio
breaking after loading save states. I redesigned the Audio, Video classes to use
regular pointers instead of shared pointers to function like the Scheduler. Also
threw in a few more GUI refinements.
byuu says:
some GUI work. better initial autosizing of tableview columns in gtk (removes a
bunch of 'todo hacks' in higan). added a status bar and menu toggles for that
and the panels. need to hook them both properly to hotkeys, that isn't working
right now.
byuu says:
I finally pass blargg's dmg-sound and cgb-sound tests, but at quite a cost.
Reads and writes can't happen on an exact T-cycle (clock cycle) point within an
M-cycle (opcode cycle) for the DMG. Writes to trigger take effect two clocks
after writes to wave RAM, for instance. Probably going to be a lot more of this
in low-level PPU emulation, so I'm biting the bullet and slowly converting the
Game Boy bus handler to this new format, which I'll use as a test bench for
doing this later to other systems with, since Game Boy performance isn't as
critical (it's a drop from 220fps to 200fps to have to poll the bus four times
per memory access and synchronize the CPU four times as often, so a lot less bad
than I'd feared at least.)
byuu says:
Game Boy: latch WY and don't increment when WX>=127 or window is disabled. Fixes
Donkey Kong level complete bottom status screen.
Mega Drive: add Z80 stall on 68K bus access during VDP DMA. Allow Z80 to
read 68K version register. Map $c0001c-c0001f (and its mirrors) to the CPU
prefetch IR register. Add work RAM refresh and cartridge/expansion /RAS refresh
emulation.
Fixed compilation bugs on Windows. Fixed DIrect3D driver. Disabled the mouse
capture trick for custom cursors on Windows because it was having bad side
effects. Disabled the multi-select activate on GTK workaround because it was
sometimes breaking input navigation in list boxes. Fixed a major issues in the
last WIP with GTK controls becoming unfocusable. Other stuff as well.
byuu says:
added viewport input capturing for windows. updated ruby (opengl 2.0, opengl
3.2, direct3d 9.0 only so far) to support width,height on the output() call,
which lets me center video inside a viewport widget. added center,scale,stretch
video output modes. added aspect correction setting. hotkey bindings are now
saved between runs. added fast forward hotkey. replaced alternating row colors
with column colors for input mappings. added batched mapping assignments to
inputs and hotkeys. fixed the video output not being black on startup with
windows and gtk3. added mouse cursor changing support to hiro for windows, gtk
and qt. the resize grips and about dialog hyperlink get appropriate cursors now.
the input driver now fully runs [as of] startup for the sake of hotkeys.
activating menu items that display panels will reshow a hidden panel bar now.
resored the ability to get game titles from every higan/icarus core. restored
the framerate counter. fixed a bug with nall::Location::pathname() returning a
blank string when there was no suffix on a filename. added video shader support
(needs testing with the new output(width, height) support.) lots of other
polishing work.
byuu says:
some more game boy improvements and a quick regression in legend of zerd
(already fixed but i'll spare you another one-line wip ^-^;;), also started on a
much larger GUI redesign to merge the video output with the panels.
needless to say, it's incredibly, incredibly broken. so, don't use it unless you
want to explore. but some major issues: hotkeys don't work before starting a
game. windows video output isn't working for some reason?? only GTK supports the
new Viewport::setFocusable() API needed to let the video output act as a sink
for keyboard input. on and on.
byuu says:
you can now unload a loaded system, allowing you to switch to another emulation
core without a restart (finally.) Fixed a couple of gekkio's Game Boy test ROMs,
but there's a lot of work left to do there.
byuu says:
150 KiB diff this time around. Rewrote almost all of the Node::Object tree
construction and unserializing functionality, so that everything's consistent
now instead of there being 3-4 different ways of doing it based on what type
of object we were working with. Certainly more to do there of course. I made
the Video::Screen stuff spawn at load time rather than power cycle time, which
fixes the SNES light guns form crashing or not working. However, I still haven't
connected mouse support to the new higan GUI. A minor thing that was bugging me
before: when powering on the system, if a settings page is open, it will refresh
to update the latched value text. I added a missing interframe blending option
to the Game Gear. There was also an issue before with certain settings not being
saved between runs, which should be fixed now. I moved all the system controls
under their own node, so it's System->Controls now instead of appearing in the
root System node. It adds another node to the system tree for each system, but
it should make it more obvious where the system controls are to remap them.
byuu says:
fixes a sprite rendering issue in Neo Geo Pocket affecting Magical Drop. Also
added NGP fast boot option that's pretty spiffy. Emulated 68K prefetch much
better than it was before, not that it's likely to affect any software -- except
there was a slight regression, so...
byuu says:
Scheduler/Thread redesign completed. Only about a ~1% performance hit, and fixes
the previous flaw completely. I also implemented region priorities (fancier
auto-detection) for all console-based systems. I need to remove the region node
from Game Gear still, though.
byuu says:
I made the Thread class aware of the Scheduler class, which removes the need
for every emulator core to inherit from higan::Thread. But I do have to
duplicate them via #include magic because of the Super Game Boy needing separate
schedulers for the SNES and GB. I improved some of the performance loss in the
last WIP, but 161 should do better still.
byuu says:
improved Mega Drive 128K mode (still far from complete, it's not well
documented), renamed Scheduler::synchronize() to Scheduler::resume(), and now
Scheduler::synchronize() is a version of synchronize(Thread&) that synchronizes
to all threads instead of just the specified one. It's much slower, but
unfortunately needed when two threads both sync to the same third thread plus
each other (long story, see Twitter.)
[byuu is referring to a thread starting at
https://twitter.com/byuu_san/status/1138436552634249217 reproduced below for
posterity:
Well heck, higan's about to take a speed hit it can't afford. Here's my
current scheduler design. It has a critical flaw, can you spot it?
CPU::step(uint clocks) {
Thread::step(clocks);
synchronize(apu);
synchronize(ym2612);
}
APU::step(uint clocks) {
Thread::step(clocks);
synchronize(cpu);
synchronize(ym2612);
}
YM2612::step(uint clocks) {
Thread::step(clocks);
synchronize(cpu);
synchronize(apu);
}
Thread::synchronize(Thread& thread) {
if(clock >= thread.clock) resume(thread);
}
Say the APU consumes some time, but it's not yet ahead of the CPU, but it
*is* ahead of the YM2612, so it switches to the YM2612 thread. The YM2612
isn't cycle accurate yet and consumes 144 clocks per sample. It's now way
ahead of the CPU, and so it resumes the CPU thread.
The problem is that the CPU may still be ahead of the APU, and so we just
broke synchronization between the CPU and APU. The solution will be painful:
we have to evaluate all available threads, find the one furthest behind in
time, and switch to that.
I'm probably going to need something like a binary min-heap array to allow
O(1) to find min(objects...), but for the immediate present, it'll have to
be a for-loop.
- Ed.]
byuu says:
completed all the cycle timings as per yacht.txt, with the exception of ...
exceptions. They have really weird cycle counts for some reason. I think he's
counting the opcodes in with the exceptions. Well whatever. I also implemented
128K VRAM mode, but without the 128K VRAM existing (since this isn't the Sega
Teradrive.) I may make 128K VRAM an option as with the SNES though.
byuu says:
added 68k prefetching, also reordered all of the 68k instructions in the C++
code to their opcode mnemonic ordering, improved cycle timings more, fixed a
crashing bug when a genesis game would enable TMSS but TMSS wasn't enabled in
the GUI so the ROM data wasn't there
byuu says:
r154 had a regression so let's skip to r155.
This greatly improves timing emulation on the 68K CPU (still far from complete),
including proper MUL(S,U)/DIV(S,U) cycle timing. The latter of which is ...
unbelievably nuanced. I also fixed a masking bug that snuck into r139 which
broke the loops in Sonic The Hedgehog.
Sadly, none of this has had any impact on the Sega CD issues: Sonic CD's intro
still has some gibberish, the US BIOS' music doesn't stop in the CD player, the
JP BIOS' music doesn't play, Lunar's Game Arts splash screen runs way too fast,
Popful Mail hangs ... sigh.
byuu says:
added Mega CD deemphasis emulation (with help on the high shelf feature from
MerryMage) and seek latencies that take the physical structure of the disc into
account (thanks to code from JosJuice). Added 2-cycle latencies to the 68K core
for -(An) and indirect indexed modes. None of this improved the emulation of
anything, sadly.
Oh yeah, r152 emulated the CDD DAC's attenuator, which is used for audio
fade-outs.
byuu says:
lots of cleanups to the subcode generation/parsing. Also emulated sega cd's cdc
dma, though it doesn't seem to get popful mail ingame, and sonic cd is pretty
weird with the audio on the title screen.
Oh wow I stand corrected, it's really just like that. The title screen plays
Sonic Boom much louder than the FMV that starts a few seconds later.
byuu says:
a quick regression slipped in trying to do a dma.io.length-- in the VDP DMA from
MCD WRAM, but with that reverted, Lunar: The Silver Star is now fully playable.
Only the "Game Arts" intro screen runs a bit too fast, but otherwise there's no
observable issues.
byuu says:
adds CD-DA audio and multi-track support + CUE parsing to Mega CD. Posted it
just a bit too soon before a freeze fix for Lunar: Silver Star, but that game
will be playable (with some glitches in FMV sequences) in the next release.
byuu says:
further along. The first sector is loaded by the BIOS, the BIOS confirms it's a
Sega CD game from it, goes to "press start button". That loads the first sector
again for some reason, and then ... nothing =( So close, so terribly close ...
byuu says:
not dead yet. full reed solomon implementation courtesy of merrymage's help
(still no C1/C2 CIRC, but P/Q RSPC is completed). implemented more CDD commands,
far enough along now to get the drive to seek to the start of the data track and
then .............. nothing. But ... progress?
byuu says:
emulated mega cd word ram -> vdp vram dma latency cycle penalty, fixes asic
graphics. bit of improvements to CDD, but it's still 99% unimplemented. hooked
up the ability to connect a game folder node representing a CD to the mega cd
hardware node, but no actual disc reading yet.
byuu says:
rewrote 68K memory handling, added a modest amount of CDC emulation, a bit of
CDD emulation, and full PSG emulation (though it doesn't work.)
byuu says:
added a whole lot of Sega CD stuff, got the secondary CPU booting and running
code, firing interrupts, etc. But unfortunately, ... nothing. Still seems to
just hang in a loop forever.
byuu says:
rewrote most of icarus to act like higan wherein you add a media class instance
to an array, and every other part of the program gains the ability to work with
the new system, emulated most of SA1 RAM write protections, added superfx backup
RAM even though nothing uses it, added genesis expansion port and enough to
get a frozen boot screen from the sega cd bios. icarus is missing some of the
niceties it had before, but they'll be re-added in time.
Last Blade broke on NGPC at some point... that's very depressing.
I removed MSX2+ stub support. There's only five exclusive games for it, and all
five are floppy disk games. There's 30+ floppy drive controllers, and C-BIOS
only has a non-working stub for it. So even if I pick a floppy drive, it'll
require a disk BIOS that is not legal to distribute with higan. So given both of
those, I'm just going to call it a day on MSX2+ support for now.
byuu says:
MSX2 V9938 support is in. I implemented graphics modes 1-4, sprite modes 1-2,
all hardware accelerated commands, some other stuff. still need graphics modes
5-7, text modes 1-2, multicolor mode, interlace, mouse, light pen, couple
hundred hours of bugfixing. then onto the MSX2+ V9958. "yay".
byuu says:
Got a better handle on understanding MSX primary, secondary, memory slots and
cartridge memory mappers. I knew this system would be a rabbit hole, yet somehow
it's still surprising me with just how much work there is to do here. I don't
know how far along my MSX support is going to get at this rate.
byuu says:
- improved waveOut DRC handling to match bsnes v107.1
- removed Famicom::APU::setSample() and replaced with Emulator::Stream
objects
- updated genius, map-analyzer, board-editor to new version of hiro
- updated genius, map-analyzer, board-editor to use nall::Instance
hiro objects
- removed Emulator::Game (failed experiment at code reuse which was
never used consistently)
- resynced Super Famicom/boards.bml to include 1CB5B-01 and 1K1X-10
PCBs
- Super Famicom: hard-forked bsnes; removed ppu-fast and speed hacks
from higan
- UI: removed "Show Hacks" from the settings menu
- Super Famicom: minor cleanups on PPU variable types (nothing
important)
- fix carry flag calculation bug in uPD7725/uPD96050 core
- don't render the screen during overscan area if overscan is
disabled; fixes Top Gear 3000 sprites
- note: I don't know if overscan can be enabled mid-scanline, but
it's somewhat likely ...
- added code to validate all peripheral locations on system load to
remove renamed/deleted peripherals from the tree
- remove FDS disk slot on cartridge disconnect rather than cartridge
unload
- all cores: scheduler.reset() called inside load() rather than
power(); as peripherals often create threads prior to power()
- removed binary=library rules from Makefile; since higan doesn't have
any use for it (it remains an option in bsnes)
- added icarus support for MSX2 and MSX2+
- added higan stubs for future MSX2 and MSX2+ support
- added MSX keyboard skeleton class (need to decide how to name the
keys before implementing the actual key bindings)
byuu says:
I improved FDS emulation a good deal. Timer IRQs were running too fast because
I was stepping at 21MHz instead of 21MHz/CPU rate (12 or 16 based on NTSC or
PAL), that fixes Zelda scrolling. I also emulate the CRC16 error check bit now.
I added a really simple emulation of the Famicom controller port 2 microphone,
where I just send random noise to the port when a Famicom/Microphone hotkey is
held down. Proper emulation would require ruby to support microphones. Next,
Molive wrote an SNES PPU test surrounding sprites and force blank, which showed
that a) sprite evaluations happen during Hblank instead of during active display
(which means the double-buffering system for OAM items/tiles can be eliminated),
and b) when force blank is enabled, it just skips updating the buffer entirely
(which is really strange ... I would've expected it'd zero out the sprites and
show nothing). So I emulate that test correctly now, but ... as always, exact
PPU timings are unknown so this is just playing whack-a-mole, but at least
it's more correct now than it was before. Finally, I added a dumb hack to the
scanline PPU to run Uniracers 2-player correctly, because why not?
byuu says:
I completed the initial emulation of the Famicom Disk System. Reading and
writing to disks work, plus the FM synthesis audio channel is now supported.
It's going to be far from perfect, but ... it mostly works.
A horrifying amount of additional work will be needed on the GUI to be able to
handle save states for FDS games cleanly.
byuu says:
fixed the pitch/speed of the VRC7, and added a 2280hz lowpass filter to match
hardware a bit more (it's kind of hacked in, but it works.) forgot to set the
echo buffer disable flag on the SNES DSP, which was breaking SNES games, so
that's fixed. started emulating the famicom disk system. so far just the icarus
BIOS + FDS disk imports (won't handle multi-disk merged ROMs yet), the basic PCB
mapping of PRG-ROM+RAM and CHR-RAM, some MMIO registers, FDS timer IRQs, and the
GUI connections to connect a disk (marked hot swappable.) I need more info on
the low-level details of how the ram adaper talks to the disk drive to proceed
further. But it's a start.
byuu says:
this release adds Talarubi's YM2413 emulation, VRC7 emulation, and NukeYKT's
dumped VRC7 patchset. It also adds MSX gamepad support (still no keyboard
support, though.)
byuu says:
now that it seems we're finally going to get some real alternative choices in
SNES emulation, I felt a bit emboldened to start performing some more radical
changes I put off for a long time. This WIP rewrites huge swaths of the SNES
DSP core to separate internal registers from underlying RAM. This allows me to
emulate the randomized memory registers at power-on, while not breaking games
due to also randomizing the actual DSP registers. This is part of Jonas Quinn's
findings about a year and a half ago, which is aimed at improving the chances
Magical Drop doesn't crash, as on real hardware.
byuu says:
substantially improved the Z80 emulation core. We now have sound in MSX games,
compatibility should be way up for MSX+ColecoVision, zexall passes, and I
even emulate new SCF/CCF flag findings that haven't made it into MAME yet.
Still needs a good review of all the cycle timings, though. I don't have full
confidence in those.
byuu says:
Nymp works fully now, need to initialize RAM to 0x00. It seems like my Z80
core is running twice as fast as it should, but if I halve it, audio starts
breaking up in other games... sigh. I finally committed the Megalomania SNES
intro scanline fix. I also emulated the MSX AY-3-8910, but unfortunately the
game I'm testing with isn't writing anything useful to the PSG registers yet, so
it's untested.
byuu says:
massively improved NGP timing emulation. Turns out I was running the CPU about
twice as fast as I was supposed to (Mednafen runs it about 2.5x too fast, MAME
can't run the bus timing test ROM for some reason, acts like there's no game
when loaded.) The actual cycle counts and specifics of the prefetch emulation
are still going to be extremely wrong, but ... it's already enough to run the
first minute of Nymp perfectly. Then the audio distorts for about 20 seconds,
and recovers for 40 seconds. Then it loops. So ... I have not had any luck
finding what's wrong here yet =( Neither Mednafen nor MAME have this distortion,
so it's obviously a CPU bug, but nothing at all jumps out at me in the trace
log. Comparing to the nymp source code, it's something to do with channel B /
phase B getting calculated incorrectly... in any case, I also emulated the LDAR
instruction, that one was well hidden, heh. I fixed several disassembler issues,
and another issue with writing to the upper word of XSP.
byuu says:
lots of improvements. Fixed the power on/off toggle, and fixed a bunch of neo
geo pocket bugs and improved things more. This is as good as I can get it
without hardware tests, though. So unless someone else comes along to help, or I
get my hands on a flash cart and figure out how to write tests on my own, this
is the end of the line.
If there's glaring bugs in games, but not in MAME, then I can probably create
CPU traces and figure out what's going wrong from that.
But as a whole, the CPU is likely running twice as fast as it's supposed to, and
even more than that, there's no penalty for using the CPU+Z80 at the same time
on APU RAM.
byuu says:
I didn't even notice that sound on the right channel was busted. Fixed now.
Also fixed a major issue where decw/l #3,r doesn't update flags, but
decw #3,(mem) DOES. It didn't help anything, but I updated LDIR/LDDR/CPIR/CPDR
so that interrupts can fire during them. Fixed the V flag with BS1B/BS1F, and
improved the carry assignment function to clear/set to undefined (eg clear for
now) other flags as they should. didn't help anything either. At this point, a
majority of games run okay. A few more key fixes (eg Puyo Puyo 2 not booting)
and then I'll start implementing proper reset and serialization, and then I
think that'll be a good neutral point to shift focus to other tasks for a while.
byuu says:
fixed a bug in ld reg,(reg+) instructions, which allows Card Fighters to run
properly. Rewrote the interrupt handling to vastly reduce the amount of polling
needed per instruction and ... it resulted in no difference to speed. Wonderful.
Spent hours trying to figure out the issue with Sonic Pocket skipping the title
screen and Rockman Fighters not accepting input on the character select screen.
Really heroic lengths like tracking every branch the code takes and inverting
the branches, one by one. Firing each interrupt sequentially based on a bound
debugger key. On and on. I have absolutely no idea what's wrong here ...
byuu says:
I added proper cycle timings for every instruction, including all of the various
penalty cycles that the dev manual lists. Also improved HDMA a bit. I can run
the FM synthesis demo ROM now, but the audio still appears to be playing about
twice as fast as it should, although with correct pitch. Any attempts I make to
halve the speed results in the pitch being halved. I have no idea what's wrong,
but we should be really close, hopefully, to running that demo ...
byuu says:
- added watchdog timer emulation,
- improved interrupt handling,
- implemented the GPIO modes of all port registers,
- completely revamped how ports, timer pins, and interrupt pins all
interoperate,
- updated the VPU to render sprite priorities correctly,
- added HDMA emulation,
- fixed a bug in the ZCF instruction that was preventing the time from being
set in the BIOS,
- accidentally stumbled across a crude RAM patching hack so that subsequent
boots don't keep dumping you into the BIOS setup (hopefully I can track down
where the RAM variable is supposed to get set, and determine why higan's not
setting it normally.)
byuu says:
some fixes to unmapped register bits, flash memory write commands, and some
other things ... a couple of NGP games are now playable, but the Z80 is
definitely not talking to the PSG correctly, still only DAC sound output.
byuu says:
I've added a waveOut audio driver for Windows (no DRC), and hooked up a lot more
neo geo pocket stuff (gamepad polling, APU/Z80 enable/disable, APU->CPU IRQs,
VPU I/O registers, etc.) still not enough to get any further than we already
were, sigh.
byuu says:
I made it default to the safe drivers so no more ASIO crash out of the box,
and full driver configuration is now in place, plus a skeleton Hotkeys
implementation (it won't save hotkey bindings to disk yet though...)
The way the driver stuff works is pretty spiffy...but also not complete. So when
you start the program, I don't initialize any drivers, because sucky vendor
drivers can crash higan and you get stuck in a crash loop. So instead, you
have to "activate" the driver before the driver settings are editable. For
instance, until XAudio2 is initialized, it can't query XAudio2 for all available
playback devices. So you go to audio settings, activate your driver, and now
you can change devices. whenever you change any driver setting, it updates all
driver settings again and refreshes the entire settings panel again. Because
for instance, if you change a WASAPI device, the new device may not support the
currently assigned frequency. Aren't computers fun?
Starting a system initializes the input and audio drivers, so that
auto-activates those drivers and you can immediately edit their settings. Video
is more difficult ... you have to have a visible window that has been realized
on the screen before you can initialize a video driver. So to get it to auto
activate, you have to actually power on the system. Otherwise, when you hit
activate, I flash a 1x1 pixel viewport at the bottom left of the video settings
panel, populate the settings, and then destroy it.
The downside to all of this is input ... if you try and bind hotkeys immediately
after starting higan, then no input driver will be bound. So, yeah, I gotta
figure out what I'm going to do there.
Like bsnes v107, higan now lets you change drivers on the fly, but of course
that's risky, so ... you know. you probably shouldn't. "activate" becomes
"change" once a driver is activated for the first time.
byuu says:
The sliders/checks are implemented on the audio/input settings panels, but
there's still the problem that I can't poll the video/audio properties
until after a device is initialized, which happens only after powering on a
system......... I added an import button to the port connector to shell an
icarus single-game import dialog, so you don't have to run icarus separately
now. i fixed a bug in nall/arguments .. off by TWO error, yikes. i removed the
name text box at the bottom of the port connector for templates, and changed the
icon from a white folder to a + icon. double clicking one pops open a create
name dialog box now. i forgot again about the nall/integer fix, so i just fixed
it now and it'll be in r112.
oh yeah, i changed it from centering the video and bumping the program window to
the left ... to centering both the program window + video window now. it means
the program window moves less drastically, and the program window won't get
placed offscreen unless the program window + video window exceed the width of
the entire window
still not ideal to be moving windows around but......... for now, this is more
tolerable.
[This WIP was made after byuu's forum closed, so byuu only gave a one-line
description -Ed.]
byuu says:
It improves windows hidpi support and removes the old, broken higan/bsnes legacy
ports since they'll never compile anyway.
[This WIP was made after byuu's forum closed, so byuu only gave a one-line
description -Ed.]
byuu says:
lots more Windows port improvements; adds high DPI support to Windows (icons
don't scale, but it still looks okay)
[This WIP was made after byuu's forum closed, so byuu only gave a one-line
description -Ed.]
byuu says:
This redesigned icarus; lots of improvements to build and run on Windows
[This WIP was made after byuu's forum closed, so byuu only gave a one-line
description -Ed.]
byuu says:
This splits ColecoVision, SG-1000/SC-3000 away from Master System/Game Gear.
Was getting too crowded in there.
byuu says:
Okay, all ten cores (and all 21 interfaces) have been ported to the new API.
Everything is of course super unstable, but ... it'll just take time.
byuu says:
8.5 hours today. I took too long to get on the PC after waking up, so I
wore out a bit sooner than I wanted.
I ported the Game Boy+Game Boy Color+Super Game Boy and Mega Drive cores
over to the new API. The Super Game Boy support is very unstable, and
will die horribly if you have no cartridge connected, or if you try
disconnecting a cartridge after the system is powered on. Lots of work
to do there. I didn't test Mega Drive cartridge chaining.
The Game Gear gained smarter up+down and left+right masking.
I added removeWhere() and findWhere() to nall::vector.
There's also been a lot of cleanups to various things.
There's four cores left to go, and two are skeletons so they shouldn't
be too terribly difficult.
byuu says:
Ten hours today.
identity.bml is now metadata.bml. I did not yet rename node.bml to
settings.bml, nor did I merge manifest.bml to metadata.bml.
I added a setting editor, which is fairly fancy. It'll show you the
latched value on static settings (eg CPU version#, which can't change
dynamically), and in the tree it'll show you "name: currentValue
(latchedValue)". Powering the system on latches the current settings,
and refreshes the tree (but not yet the Latched: value in the setting
editor ... polish work is needed.)
The node manager can refresh without losing its place now, which means
you can connect/disconnect peripherals without the port connector
disappearing.
I ported the Master System (and its five systems) and the Game Boy
Advance to the new Node API. I also separated out the Game Boy Advance
core into two models: Game Boy Advance and Game Boy Player, since
they're different physical devices. I skipped over the Game Gear Up+Down
/ Left+Right improved handling, so I'll need to get back to that.
I created Video::Screen, which acts a lot like Audio::Stream insofar as
allowing you to have different screens with different color counts and
color conversion functions. The big use case for multiple screens will
probably be if we emulate a peripheral that has its own screen (think
Dreamcast VMU but something more modest ... maybe one of those weird
peripherals Shonumi has been researching has a little status LCD screen
or something.)
I still need to update Audio::Stream to take a Node::Audio object on
construction.
I hooked up really, really rough save state support via a new tools
menu. Now, unfortunately I am so far unable to reproduce Tala's crashing
behavior with the Master System core's save states. If I can find a
reproducable case, I'll fix it.
So at this point we have three of nine cores converted. Once they are
all converted, I need to split off ColecoVision and SG-1000+SC-3000 to
their own separate cores. That's still going to be a ton of extra code
to write and compile, but the overall workload should be lessened with
the new higan/component/(video,audio) abstraction layer.
byuu says:
Only five hours today (maybe more later ...), but ... a fairly
productive day still.
The SNES is completely migrated to the new structure and seems to be
working ... quite well! (okay, the SGB support is still busted and ...
oh gods that one's gonna be tough as nails.)
I tweeted the new Interface and Platform APIs, and they're a real dream.
Lots more to do internally of course, like abstract higan::Video to use
shared_pointer<Screen> objects, so that each screen can get its own
dimensions and palettes. I also want to hook up the Node::RealTimeClock
stuff better. We can serialize the timestamp outside of the RTC RAM
now, so yay more faithful rtc.ram files. Should help with Satellaview
emulation when we can jump the time ahead seven minutes for the "wait
for the broadcast" titles.
I think it makes sense to build out CartridgePort, BSMemoryPort,
SufamiTurboPort classes as well, instead of merging the port +
peripheral into one.
There's gonna be tons of bugs, and I'd greatly favor fixes over reports
right now.
Hmm ... and of course, the pending bikeshedpocalypse coming up for
serialization of the tree and peripherals. I'd like to simplify the way
we save and load input mappings. Instead of
pathID+vendorID+productID+groupID+inputID, we could reduce it to
id+name, and print out string values for the group+input IDs.
On and on.
byuu says:
Only eleven hours today ...
So, I redesigned the Justifier/s support, added NTT Data Keypad and Twin
Tap emulation to the SNES core, and I improved the handling of up+down
and left+right to use the last key pressed instead of canceling each
other out when held simultaneously.
I started to port the Master System core to the new Node system, but
quickly grew displeased with the nested spaghetti code required to
unserialize the system. I wanted a design where the core runs alongside
creating new nodes, and copying in node values from a parallel tree next
to it. With every step along the way, the true tree should have the
equivalent level from the unserialized tree, so we can copy in exactly
what we want, and ignore what we don't want. Anything less than this,
and we're going to risk stagnant elements from previous versions
sticking around in new trees and causing issues. Further, this redesign
allows me to merge the peripheral node setup and device node binding
together.
It required a huge amount of rewriting, but the idea works. So far only
the SNES cartridge and controller port gamepads work. And even then,
they just barely work. Lots of annoying issues like losing input
mappings when unloading and reloading the gamepad, not displaying the
folder names in the system tree view, etc.
I wanted to get further along, but I'm getting too tired to think, so
it's best to stop here. It looks like I'll get one more day at this
tomorrow due to it being some kind of Japanese holiday. I'm hoping I can
repair the SNES core completely (well, sans SGB), and with any luck ...
it'd be great to get the Master System core up and running. I'll try my
best.
byuu says:
Sixteen hours of work today. This is getting ridiculous ...
I basically rewrote the GUI to merge the configuration and system
managers into one program window. I did all of this basically to save a
quick blinking when the configuration manager went away and the system
manager appeared. The menus have been broken out to their own classes,
so that we can share the settings and help menus between the two modes.
Renaming systems/peripherals on top of existing names now just errors
instead of letting you optionally delete the old item and rename it
anyway. Laziness, I may readd it later. Renaming peripherals that are
already connected to ports works much better now. Renaming systems is
still very broken.
There were a few other changes to things here and there, like the path
the port selection windows scan in is more obvious, with a button at the
bottom-left to select an alternate port.
This new design should let us do some more interesting things, like have
the settings and tools activate in the right-hand pane instead of
generating another window.
I regretfully went ahead and wrote the GUI using ListView widgets this
time instead of TreeView widgets. So, I'm sure this won't compile on
other platforms due to missing new functions to hiro, but ... let me
know what they are and then I can add them, I guess.
For some reason, I got distracted for about half an hour and started on
a nall/image64 class ... I don't know what I want that to be just yet,
but I'm kind of annoyed with how cumbersome everything is with
nall::image on account of having to support every possible ARGB image
format. I think this is because I added a somewhat subtle logo to the
empty panes in the main window, and doing so was kind of annoying.
There's a very strange bug in hiro/GTK's Frame control. For some reason
when you have a widget directly attached to it, it shows up just fine.
But attach a layout to it, and then put a widget inside that, and the
widget won't show up. I added a hack to call setVisible() on the layout
inside the pFrame::setGeometry call, but I have no idea why that works
or why that's necessary. If anyone's willing to take a stab at that,
you'd be a real life saver.
I updated the SNES mouse, super scope, and justifier code to compile
once again. Although the justifier code is completely broken. I am
struggling with how to design it to support dual justifiers more like
real hardware would. I think what I need is to bind the controller port
IO bit read/write functions to callbacks, so that the second justifier
can send the iobit strobe back up to the first justifier, which can then
propagate it to controller port 2. The second justifier really needs to
be its own class as well, as it's not simply just another justifier.
Overall I'm really disappointed. It took way, way too much work to merge
those two panels. I thought it'd be a relatively quick copy-paste affair
with a few tweaks, but it ended up being a huge mess that was easier to
just redo. But, damn. I wasted a critical day and a half on ...
something trifling. Sigh.
byuu says:
Another thirteen hours ... Concerta is a hell of a drug.
Okay, so this is a partial merging of Screwtape and bun's suggestions
for a multi-pane layout.
The configuration manager shows the list of systems on the left, and you
can choose to create a new system in the right pane, or to see
(read-only) the current connections of a given system entry. For right
now, there's just a simple logo display on the right when no systems are
selected and you're not in create mode. I imagine it will make more
sense to list the systems on the right when not showing a specific
system connections list, but ... I wanted to put the icon there for now.
To do that, I wrote a new nall::image function, shrink(), which detects
all entirely blank/transparent rows/columns on all four sides of an
image, and then crops them out. I could have just used Imagemagick on
the icon.png file, but ... overkill is more fun.
My thoughts were, maybe in the future, we can populate it as a kind of
"home" screen with some more things. Have to think about it.
The system manager window shows the connections on the left, and you can
edit either port↔peripheral connections or input mappings on the
right. And in the future, settings and other such things as well. The
system manager also has a "blank" panel, but this time it's just a
disabled, empty TreeView (so that the frame matches the other panels.)
We could put anything here as well in the future ...
There's new hiro classes, HorizontalResizeGrip and VerticalResizeGrip.
The former is used to let you resize the two panels.
I burned a lot of time reimplementing the horizontal scroll bar display
in GtkTreeView, because GTK's implementation was busted, ignored icon
indentations, and showed the scrollbar way too early.
The tree views now render little L bracket things to help show
indentation a bit better. Unfortunately my GTK themes can't do this even
with the extenders visible, so this is the best I can do in a
cross-platform manner for now ...
If we decide to give up on tree views ... we will have to lose the icons
(and the chance of any nicer node-specific icons in the future), because
the TableViewItem icons always appear at the far left. I might consider
it anyway because I really don't want to port TreeView to Windows, Qt,
and MacOS.
I turned back on the GTK alternating row colors for a bit, to make the
input mapping panel a bit easier to read.
I cleaned up a lot of the SNES core code as well. The Super Multitap is
back, and functions like a real Super Multitap for the first time ever.
There is the possibility of a controller that passes through the iobit
lines to PIO d6/d7, but for now, the only controller we emulate with
extra ports (save for maybe the dual Justifier) is the Multitap, and it
doesn't pass through the iobits to its connected children, so for now
I'm just having anything other than controller ports 1&2 return 0 from
iobit reads, and ignore iobit writes. The ControllerPorts implement
wrappers for the Controller functions (iobit, data, latch) so that the
Controller* device object can be a nullptr.
Expansions are connectable again. There's a new Thread::destroy() to
both release a cothread_t and remove it from the scheduler threads
list. I still regrettably have to also remove the threads from the
cpu.coprocessors/cpu.peripherals vectors (speaking of, I should
double-check that the peripherals do this right.) All of the
coprocessors have been updated to properly do all of this, and handle
thread attach/detach inside their own unload/power functions, instead of
in System/Cartridge::power,unload.
The Satellaview maps data onto and off the SNES bus, but ultimately this
should be okay because the expansion port isn't hot-swappable. If you
forcefully do it anyway, it should still work since nothing else maps to
those ranges except for the 21fx.
I updated hiro's setAlignment functions to replace the newer
setPlacement with something even more flexible. Love it or hate it,
higan now places the system manager window in the center of the screen,
and when you power on a system, it centers the video, and then moves the
system manager to the left of the video output. When you close the video
output, it acts like an unload event and moves the system manager back.
If the system manager is either minimized or maximized, it won't move it
on power on (though currently you can't power the system on with the
system manager minimized, but maybe later with a hotkey ...) When you
close the video window, it'll unminimize the system manager if you did
that, and then center it ... unless it was maximized.
Unserializing node.bml tables got a lot more strict. Now only Setting
values and Property values can be unserialized into the root tree, and
only when both the type (identity) and name of the node matches up. This
should hopefully help to prevent incompatibilities as the node.bml
structure changes.
If you right-click on a port, you can change the path it looks for
things in. This is a bit hidden, and the port connection panel should
really tell you where it's looking as well. We'll get there.
I'm sure there's a lot more, but that's all I can remember right now.
byuu says:
Fuck it, what's another few hours, right?
So remapping the SNES bus on power-on wasn't going to work, if we wanted
to also support hot-swappable cartridges (which would only work on real
hardware if you disabled the CIC, easy to do but breaks SA-1 and S-DD1
games ...). Plus, it's a lot of extra work. So instead, I'm reloading
the bus on every cartridge load and unload event. The CPU and PPU bus
mappings were broken out to CPU::map() and PPU::map().
An extremely long-overdue change ... I improved higan::Thread to let you
pass nall::function objects to create threads, so all of the static void
Enter(); methods are now deprecated. This was essential for Multitap
support to be able to connect peripherals to it that would then need
their own threads. Multitap support still isn't ready yet, but ... it's
getting closer now.
Ports gained a hotSwappable flag. When false and you try to disconnect a
peripheral (the flag can be set per-peripheral if you want too), it'll
warn you with options to forcefully disconnect the peripheral (and
possibly connect a new one), to power off the system first (safest), or
to cancel the port change attempt.
I may move this prompt to when you double-click on a port, but I held
off for now because that may not work well if we go with Screwtape's
multi-panel layout.
byuu says:
Another thirteen hours of work put in ... things are starting to shape
up.
I fixed the issue with relasing all the shared pointers properly, and
higan always exits cleanly now. I even went back to Application::quit()
instead of kill/exit().
The templates directory is now "fixed" to ~/.local/share/higan, which
holds all of the system folders. The configuration directory is now
fixed to ~/.config/higan, which holds the template and data paths, and
eventually program settings as well.
I removed as much of the old Emulator::Interface and Emulator::Platform
cruft as possible. I had to disable all but Gamepads for now, which is
fine since they were the only inputs that actually worekd anyway. It's
going to require a lot of reworking to get all the peripherals up and
running again ... sigh.
I killed off the properties/options support, and with it,
nall/settings.hpp, in favor of just using Nodes to represent things.
My trickery with trying to get us to have Node, Node::Input,
Node::Input::Button, etc was backfiring. I had to make Node::Input a
member of a Node struct, which inherited from
shared_pointer<Core::Node>, and so forth. This was leading to all kinds
of overloads and using statements necessary, and eventually things just
weren't converting properly to the derived types, so I scrapped it all
and now every Node::Object is just a shared_pointer<Core::Object> and
nothing more. Not crazy about this, but ... oh well. Ten-page compiler
errors on typos was clearly a sign I was pushing things.
<Platform::attach> and detach work properly now, which kills off the
GUI's Emulator::load,save hacks. You can attach and detach controllers
and have all the state saved properly now.
I sped up input polling by creating an intermediate shared_pointer
object that holds decoded group/input IDs. Probably doesn't matter much
in practice, but why not?
I have an initial fix for the annoying ipl.rom error ... it'll try to
import missing files from the templates folder for a given system. Won't
work for the GBA BIOS, but it's a start.
The next major thing I need to work on is SNES cartridge loading ... I
need it to just load for now, and do the mapping stuff at power-on.
I guess I'm going to get this as far as I can by the end of this
weekend, and then I'm going back to NGPC.
byuu says:
Very, very slow going ... sigh. Aforementioned changes to the Property
system in hiro and higan. string::from/to removed.
Input mappings now serialize the path/vendor/product IDs, and input
binding events were added to connect inputs back to devices on load and
on ruby device attach/detach events. (Speaking of ... a good tangent
would be a notification callback when adding/remove HID::Device objects
from ruby::Input. Neither hard nor expensive to scan the result of
Input::poll() to detect this, but still.)
The actual tree of each peripheral is loaded and saved now, and there's
an initial attempt at importing this data into the actual root tree on
load. I'm going to have to do this same thing in the port selection
manager when attaching/detaching peripherals.
There's code in place now to detect when you try to connect the same
peripheral to multiple ports, and it'll stop you. It won't attempt to
validate this if you give Interface::initialize a root.bml file that has
the same peripheral in two ports, however. Maybe later we can detect
that as well somehow ... it won't crash or anything even if you do this
anyway.
There's new <Platform::attach>, detach callbacks to send notifications
to the GUI whenever the emulator tree changes in any way.
And it's about here that I'm running into problems again. When closing
the emulator, I'm seemingly unable to get the tree to actually destruct
properly.
If we have ~Node::Port call disconnect(), it works, but then segfaults
after the application terminates in the global destructors. I was
thinking, the Peripheral is inside of the Port, so maybe catch
~Node::Peripheral instead, see if it's attached to a parent Node::Port
via the weak_pointer it holds, but no matter what that painfully
segfaults on startup.
I was pretty sure I wiped out all of the copies of the shared_pointers
to the ports before calling Application::exit(), but it seems not. I
guess that's the one downside to using shared pointers and holding
copies of them everywhere. It quickly becomes overwhelming to keep it
all in your head. Best I can think is to just slowly work on destructing
everything as cleanly as possible. Eg closing the input mapping window
should erase the list to clear the Node handles cached in the
TableViewItem entries, reset its holding of the Node::Port for said
mapping, etc.
There's another problem with the <Platform::attach,detach> ... it's
getting called with a bunch of nameless items. Nodes without names
should never be attached to the emulator tree, so there's some spurious
copies somewhere ... I'll need to update the static create() functions
to take variadic template parameter lists, and make the name parameter a
constant for the construction of Node objects. That should allow me to
find where nameless Nodes are being spawned, and stop that from
happening.
A lot more work needs to go into serializing and unserializing
Node::Peripherals to their respective folders. I feel like Node::clone
is asking for too much trouble, and we should instead rely more heavily
on <Platform::attach> during the load process to then connect
peripherals for us from our shadow tree instance. The GUI should only
ever call a function that copies all of the properties from the shadow
unserializing tree to the actual emulation core, and never act
recursively.
I really don't know what to do about the serialized root tree holding
all of the peripheral metadata. We have to do it in the case of
peripherals having their own ports that may be connected to things, but
... a lot of the information in the tree isn't necessary at all. It
would probably make sense to write some code to filter the serialized
tree, like stripping all Input nodes from it before saving.
Well whatever ... I *really* have to hurry up with this, but there's
just so much work to do ... sigh.
byuu says:
Templates now import to the user data folders, so you can create
multiple gamepads with distinct mappings ... or at least, you will be
able to. Things have progressed enough that you can map keyboard inputs
to play Zelda 3 a bit now. But if you close the emulator, the assignment
device will be lost. Right now, it's serializing things to the root.bml
document instead of to individual peripherals, and it's also not
properly serializing/unserializing the HID object from ruby.
The old naming of program, emulator, emulators didn't match the new
design where Program wasn't the center of higan anymore (the
configuration manager precedes it), and Emulator has become higan, so
that's been renamed to emulator, interface, interfaces.
Some new work on hiro and nall:
MessageDialog
- when dismissing, set the response to the last button
- add dismissed() function
NameDialog
- new class for create / rename file/folder dialog boxes
BrowserDialog
- add create (folder), rename, and delete support
directory:
- add copy() function
- fix sorting of folders to ignore trailing /
string:
- added string::from<T> and string.to<T> for object binding
- requires string::operator bool() to return true when capacity() == 0
...
The last one is going to be really contentious, but ... oh my gods I am
in love with it already. So for an example:
auto x = shared_pointer_make<Foo>();
node->setProperty("id", string::from(x));
if(auto y = node->property("id")) y.to<shared_pointer<Foo>>()->bar();
The idea is to add another special case in nall::string, where when the
capacity is zero, the new _hold pointer holds a type-erasing object.
This object is set via string::from<T>(), and extracted via
string.to<T>(). The capacity is always >= 23 normally, due to SSO, so
it's okay to special-case zero. _hold doesn't make the string take any
more space ... with SSO of 24 and two pointers before, we're just using
up the rest of the space we already had. The total size of strings is
still 32. Although at some point I'll probably make it 40 for 64-bit
size/capacity, but that's not super pressing right now.
Anyway ... why in the hell would I do this? Well, hiro has the
Object::property/setProperty system for keeping a set (red-black tree)
of name:value mappings. And higan adopted the same system for its Node
objects. The name is obviously a string, but the value is also a string.
Why a string? Because it's the easiest to serialize, and can be
converted to and from any data type: booleans, integers, floats,
strings, pointers ... and all of those implicitly convert into strings
for you, so you setProperty("name", 3.7) is just fine. But it can't hold
objects. Even if you allocate a new pointer and store it in the string,
it'll end up leaking if you don't make sure to extract the pointer and
delete it before the string goes away.
I really didn't want to move the property system to any<T> types because
they are such a massive pain in the ass to use in every case. It would
make serializing/unserializing Property structures in Node elements way
more painful, too. And any<T> basically requires heap allocation for
absolutely any value. nall::string will only allocate memory when the
string size is > 24 (or now, if you use the new string::from support.)
Now obviously, string::from has a caveat: you can't serialize it. You
can copy a string holding a T object to another safely, but once you try
and print it into a text document, the string value will be empty, and
when you try and read a string back from the text file, it's gonna also
be empty. Even if we extracted the pointer from the string to store,
restarting your program would invalidate the pointer anyway.
This is a pretty significant win ... for my tree structure in higan's
system manager, I can just hold shared_pointer copies of each Node
inside each TreeViewItem, and retrieve them directly. No crazy path
traversal up and down the tree with lots of string parsing involved. No
possibilities for bizarre bugs because the two get out of sync, or the
tree paths change in higan, or whatever else. The worst thing that could
possibly happen is the shared_pointers between higan::Interface::root()
and SystemManager get broken, and SystemManager just stabs at perfectly
valid but detached Node objects. No big deal. No problem. In practice
that's not going to happen anyway.
In implementing this new feature, I realized that my
template<typename... P> string(P&&...) constructor was matching
instead of string(const string&), so I added a string(string&)
constructor, which should in general help the performance of building
strings a whole hell of a lot, presumably much more than the tiny tiny
hit for the extra checks for the new string::from mode.
There's only one thing about string::from that kind of worries me ...
explicit string::operator bool() const must necessarily return true when
holding a T object, even though the size and capacity are both zero. If
we don't do this, the values will be lost in eg setProperty erasing
nall::set entries when the assigned value is a blank string. I don't
know if this will have unfortunate side effects in other string
processing code, but ... in general, I've never used nall::from in any
other code, so if there's an issue, we'll find it as we are using
nall::from objects. The change should not impact any existing code as
such.
Lastly, the MessageDialog change ... in way too many places, I do tests
like if(MessageDialog() .... question() == "Yes") or (... question() ==
"No"), but I don't test both Yes and No. So whichever I tested with ==,
it'd be false when the MessageDialog were dismissed, and the inverse for
!=. Not good. Sometimes it's the difference between deleting a
directory recursively or cancelling the operation. I don't think in the
history of using hiro I've ever bothered to actually test for
.question()=="", so I think this change is really imporant. If the
dismissal case is really needed, MessageDialog::dismissed() can be
checked now instead.
So the next big thing is going to be more advanced tree parsing: it
doesn't really matter whether the root tree gets serialized with all the
peripheral input values, but we absolutely must serialize each
peripheral to its respective folder. And when unserializing the root, we
have to go through and unserialize all of the peripherals.
Also for input mapping, I have to serialize the hardware HID path +
deviceID + vendorID, and then create a binding function that'll scan the
root tree for all Input devices and rebind the shared_pointers to the
new shared_pointer<HID::Device> instances.
But, hopefully, hopefully ... I can get that done in the next WIP.
byuu says:
Another eleven hours in ... I think we're finally starting to see some
hope.
Unserialization of the tree works now. An absolutely heroic effort. The
design challenges were thus:
- given a text document, reproduce a tree of shared pointer objects
- the text document may have extra or bad node names (perhaps it's
from an older version) -- ignore these so they don't appear in the
actual tree
- the text document may be missing some node names (again, maybe an
older version) -- populate the actual tree nodes with default values
in this case
- any peripherals connected in text document nodes won't be in the
actual tree, so we have to connect them
- upon the creation of a new actual tree peripheral, we must populate
it with the metadata from the text document recursively, with the
above rules in effect
- we also need to allow the GUI to attach new peripherals, where it
would not know about the child nodes each peripheral contains (eg
the buttons on a gamepad)
- lastly, even though the tree is small, try not to take an absolute
eternity to import a document into the tree
There's a hell of a lot of restructuring that needs doing, in the SNES
core far more than anywhere else. We have to split bus mapping to occur
at power-on time, and manifest generation + slot attachments to happen
during load / system configuration. GBA also should move to detecting
save types at run-time. And honestly, that scan is pretty painfully slow
... it may make sense to suffix array it ... 13*4MiB isn't that much
memory. That or just write a smarter substring scanner. Sigh.
So now that things can be serialized, the next step is going to be
writing an input manager. It's going to be a radical departure from the
old way of doing things. Now, when the core wants input state, it'll
call inputPoll with a Node::Input object that we can directly write the
value to (well, after we `dynamic_cast` it to its specialized type. It'd
sure be nice if there were a `dynamic_multicast` switch construct, so we
didn't have to keep doing repeated `dynamic_cast` calls for each input
type. I digress.) I guess we can cache things ...
Thus, input polling will be more like this:
- produce a map of Node::Input to
`shared_pointer<InputManager::Binding>` objects
- maybe even do a multitap as a lazier way of handling multiple
input bindings
- have the InputManager::Binding hold a `shared_pointer<nall::HID>`
object, the group ID, and the input ID
- polling will thus be a map (or multitap) lookup; copying the
nall::HID value over to the Node::Input value
- it should be fine to just store `shared_pointers` here, to save
the overhead of constantly converting `weak_pointers`
And of course, we have to write a GUI for this. Oh, and before I can
even do the above ... I have to implement template importing, and
implement serialization support when attaching / detaching peripherals.
Hmm, what else ... I got rid of the Port specializations, as Port ends
up needing a lot of glue code and any special handling can be done
inside the emulation cores anyway. So now, a Port is a Port. It's just a
Node with the special property that it may contain either zero or one
Peripheral nodes. In addition to nodes of other types, of course.
I'm thinking we should probably also enforce a tree rule that no parent
node shall have two child nodes that have both the same type and the
same name. If we stick to that rule, we can simplify path traversal, and
allow the append function to be used as a "create if not exists"
function.
Also, we're really going to need a system to pick sensible default
peripheral and template paths for ports, including for dynamic ports.
Having to manually assign these, and having the values on dynamically
generated ports lost easily, is very annoying.
byuu says:
This is starting to get ridiculous ... thirteen and a half hours today
of non-stop coding, and I barely made a dent.
So, the main change with this release was building out an introspection
layer for higan::Node objects. You can now construct a Node from a
string that represents its identifier.
There's now a templates system for things connected to ports. The idea
here is controllers will let you pick a template (Gamepad, Mouse,
Multitap, ...) which will (in the future) import a folder by the name
you gave it to the path you set the port to. This system will also be
used for creating eg blank BS Memory cassettes. Connecting something to
a port shows the templates first, and then the folders found in the
path. If you pick a template, you need to give it a name, although it'll
fill in by default to the name of the template. In the future, it may be
nice to produce a "#n" suffix, by counting the number of existing
matches in the path folder for said port.
The UI is currently erroneously collapsing the Display settings, because
it's a Port::Video, and the code tries to do that on all ports. This is
the same problem as with the Game Genie that I talked about previously.
Basically, what I need to do is have Node::Port hold its own separate
Node connected instance, and that will be the thing that gets condensed
in the system manager. It's still going to end up looking weird if a
connected Peripheral/Cartridge exposes its own child Nodes, while the
Port::Peripheral/Port::Cartridge also has its own child Nodes. They'd
end up getting merged into the same parent TreeViewItem.
So as such, I think we're gonna have to say it was a nice try, but
overloading two different things (Node connected + vetor<Node> children)
into one parent (Node::Port) isn't going to work well. If you connect a
to a port, it'll just have to create a child peripheral/cartridge node.
The Node::id field is gone. There's a new path/find API that generates a
string of tree indexes, eg "2/7/4" to represent root[2][7][4].
Nodes hold weak pointers to their parents now to do the reverse
traversal. Unlike hiro, I didn't bother keeping the offsets in the
children, I just do a scan of the parent Nodes list instead. Speaking of
... this traversal requirement is another dead-end for overloading Port
with a Node connected child. Too much extra work added on here.
Hmm, let's see ... there was also a failed initial attempt at actually
unserializing a loaded cartridge, but so far that isn't working. That's
a "fun" problem ... the serialized tree that we try and load in will
have the child Cartridge node, whereas the actual root tree will only
have the Port::Cartridge node. I added a virtual overload to grab the
child type, so a Port::Cartridge will attach a Cartridge instead of a
Node, so that's a start ...
What I'll need to do is, when unserializing a document, if the
Markup::Node has a child Cartridge, I'll have to attach it there and
invoke a callback bound in eg the SuperFamicom::Cartridge core, to go
ahead and do the cartridge load after we've populated the
Port::Cartridge properties (which holds where the game is located), and
before returning, so that the parent unserialize function will now see
that our Port::Cartridge node has a child Cartridge node, and begin to
unserialize that in turn.
The Super Famicom core is going to need a reworked bus mapping system:
we can't be calling bus.map and risking bus.read calls during
initialization. It's also a problem if we unload a cart and all of these
bus map entries still exist on the bus for the cartridge. So bus mapping
is going to have to be done at power-on for the entire system, and the
manifest parsing + slot creation stuff will have to happen during
initialization. Fun.
Once all of that is done, I'll then need to hook up input mapping, which
is going to be completely different. Hooray.
... I really didn't anticipate this being so much work. This is really
bad ... I am going to have to start triaging features. I think the goal
is gonna be getting just higan with just the SFC core working on just
GTK with the bare minimum of features. Work on the new GUI will have to
be a weekend thing while my day job comes first.
byuu says:
Things are slowly coming along. I keep making everything more and more
flexible though, not wanting to ever have to do this again, so it's
taking a lot of time to plan everything out.
Node now has subclassing, and can hold shared pointers to itself,
resulting in much more powerful run-time introspection of the tree.
The main window is now the connection manager (which I'm going to rename
the system manager.) The tree is scanned and a viewport is spawned for
each video port the system exposes. So that'll let us support eg
dual-screen Nintendo DS or whatever later. It also kills the
Interface::display(s) function. And by detaching displays from the main
menu and status, we open up a future possibility of spawning a
fullscreen exclusive viewport as a top-level window, without ruby having
to very hackishly attempt to do that per-driver (though it's only going
to be useful for maybe Direct 3D and OpenGL.)
Inputs are going underneath peripherals now. In the Node object system,
this means we can have any kind of values bound to any kind of inputs,
so we aren't limited to just int16 values anymore. Photoresistors,
microphones, etc become possible, presuming the GUI can handle them, of
course.
Properties and Options are going to be folded back into the tree as
well. We can attach options exactly where they're used this way. Slowly
but surely, the Interface specializations for each core are being
reduced in complexity. Lots of hard-coded IDs are going away, too. The
tree is going to assimilate as much as possible.
Nodes do still have IDs for the sole purpose of the connection manager
mapping a tree item back to a Node. But we can probably eliminate this
by writing wrappers to store weak pointers to nodes inside tree item
properties.
byuu says:
Things are further along ... good luck using it in its current state ...
A rather large change was removing Edge as a separate type to Node. Edge
conveys quite useful information (that it's connecting two nodes, and
thus will only have either zero children or one child Node), but forces
us to do twice the work in every tree parsing recursion. I added an edge
flag to Node for now, but it may be nicer to derive Edge from Node.
It's looking like Node unique IDs aren't really useful, when we can just
pass around the Node objects instead. So I will probably start doing
that.
I also added a property system, which was directly inspired from hiro's
property system. Each Node contains a set<Property>, where each Property
holds {string name, value;}. This lets any GUI set any metadata it wants
directly into the tree, so we don't have to keep parallel structures in
the GUI to link the two together.
The tree can be serialized, including its properties now. But it can't
yet be unserialized.
While I *can* allow configuration of the connections from the
configuration window, I'm thinking it's better if we don't allow that.
It might possibly start to end up in a weird state with the SNES hooking
directly into the GB core for SGB support. I won't be entirely opposed
to reverting this change and allowing the connections dialog inside the
configurations window, though.
The main window viewport is back when you start a system, but once again
this release has hard-coded OpenGL 3.2 / OSS / SDL drivers.
I think that I want to build out the tree far more in-depth than before:
a Gamepad should add child Nodes for all of its buttons, and the
connection manager can ignore anything that's marked as permanently
attached as a child so the list doesn't get cluttered.
This whole tree structure is making me rethink a lot of things as well
... why have each class call each subclass when doing things like saving
save RAM to disk, or unloading games, or serializing state, etc? If we
iterate over the tree, we can find everything that needs these things
done and do from the higan::Interface base class instead.
[Since r91 was not posted to the WIP thread, this changelog describes
changes made in that WIP. -Ed.]
[r91 was not posted to the WIP thread, but linked to later without a changelog.
This commit also incorporates some .gitignore files missing previously. -Ed.]
byuu says:
This WIP has another higan GUI rewrite. Since this one is far more
ambitious, it's much less further along.
For the first time in its history, higan won't start at the familiar
black window. Instead, you start at the configuration manager. Here, you
can create a tree of folders and system configurations. There's full
support for creation, renaming, and deleting of both. With lots of
safeguard messages for when things go wrong. Since this is based around
the filesystem, things are sorted alphabetically. The easy solution to
force sorting is to prefix things with numbers.
There's a very raw properties editor for systems in place. This is meant
for extremely advanced users, and it may even make sense to hide this by
default.
Then there's the connections manager. The emulator interface can return
a hierarchy now, which is an Object representing the system. Inside each
object is a list of connectors that are present. A cartridge port,
controller ports, an expansion port, etc. These may or may not be
connected to another Object. When they are, you thus have formed an
infinitely recursive chain, that should be able to do anything other
than literally form a circular dependency.
This model lets us emulate things at a far greater granularity than ever
before: multi-taps can expose four generic controller ports each, which
can have any device you want connected to them. So four mice? Sure, I
don't think the multitap protocol will really work with it, but why not?
The second-player Justifier? You can literally daisy-chain it off the
first Justifier now. Although it will have to be a slightly different
device that won't itself contain its own connector. The Voicer-kun can
let you pick a CD-ROM to use for playback. And so on.
The connections manager marks an ideal place to control user input
mappings. And for good reason: you can have different mappings for each
created device. So instead of just attaching the generic "Gamepad" to
port 1, you could have it generate a folder, assign it a label, and have
your inputs stored there.
When you go to connect an object to a connector, it'll inspect what
you're trying to connect, and adapt it to what it shows you. Cartridges
get you a folder selection dialog. Controllers get you a peripherals
list. And so forth.
Currently, the connection manager doesn't do anything but recursively
show you the tree of objects and their connectors. There's no assignment
support yet.
I need a couple of critical pieces now: since we can't delete Interface
objects and respawn them, emulator-\>initialize() needs to completely
reset the emulated core, detach all of the inputs, reset the system
properties and options, etc.
After that, I'll need a system of serializing and unserializing the
object hierarchy, so that we can save the configuration from the
configuration manager to a "defaults.bml".
Once I have that, then I can implementing launching a system. When this
happens, the connection manager will go away, and the selected
configuration will load on the selected system.
I want to give us lots of cool options, like an "auto power-on system
after launch". Then combine that with a command-line "--configuration
name", and you could create a shortcut that literally starts playing
Zelda: Link's Awakening on the Super Game Boy, with the SGB Commander
connected and configured for your Xbox 360 gamepad. Running with the CRT
Royale shader. In fullscreen mode. Set to close higan when you close the
launched system, rather than return to the configuration manager.
Yeah, the system I built is that flexible: you can have per-game
configurations now.
I need to think through the specifics of where to create these folders.
\~/.local/share/higan is getting kind of old.
The real question will be, where do we import games to? There's pros and
cons of importing them to a generic folder (\~/Emulation/Super Famicom),
as well as to importing them to the Configuration we just made (you
could create categories of games. Your main window can be "RPGs",
"Fighters", etc, that launches you into an emulation core that will only
show you the relevant games.) Probably ... it needs to be a
configuration option on the connector item.
byuu says:
This WIP starts on a new higan GUI, and it's extremely new. To the point
where you have to edit the settings file to assign your own ruby drivers
by name. No input support, only systems configuration. Only the GBA core
just barely compiles with target=higan, and nothing else works.
There's substantial changes to the higan Interface API that is going to
take time to work through.
So, the gist of it is: emulator->load() now basically just initializes
the emulation core and nothing else. After that, the GUI can call
emulator->load(id), where id comes from emulator->slots(). After
calling this and loading a game, you now call emulator->slots() again
to see if the newly loaded game added any new slots. The same,
unfortunately, will have to happen when changing expansion port devices
(MSX tape/floppy drives, and uh ... BS-X Satellaview CompactFlash drives
:P) Basically, the available slots for media change dynamically.
Next up, emulator->regions() is going to replace the per-game folder
load dialog's options list. It's kinda silly for every loaded cart to
ask you what region the system should run in, so instead it appears on
the main load dialog now instead.
Oh, and because I'm using TreeView, this'll only work on Linux/BSD.
Anyway, if you want to torture yourself to be the first to test the new
higan, go for it. Things will probably change a lot still, though.
byuu says:
Couldn't sleep again.
So, this updates all cores to the new options/properties setup, and
connects onModify events to nall/settings.
manifest.bml files are no longer required for .sys folders (I still need
to delete a few of them, I forgot.)
Currently, systems with slightly different properties (WonderSwan EEPROM
sizes, Game Boy boot ROM sizes, ...) require per-system properties()
functions. This in effect exposes a limitation with trying to share the
properties from a single object. What's probably going to be necessary
is to have each Interface class hold a `vector<Settings*>`, and during
construction, add all the members said system needs. The same goes for
options (Master System has controller ports whereas Game Gear does not.)
This also means that we can't pre-declare the default values for all
systems. We'll have to declare defaults inside each Interface instance.
So in light of all of this, I'm probably going to reshape Settings to be
a single-level class holding a ton of `Settings*` objects, and the
serialization functionality will just have to build the tree from a flat
list somehow. I could probably rely on Markup::Node itself to do this
for me.
Oh, nall/primitives gained explicit specializations for converting from
a `const char*` (the string class isn't defined at this point,
regrettably.) So with that, you can make a `Setting<T>` out of any `T` that
can be explicitly constructed from a `const char*`. I want to do the same
for the string class, and allow explicit casting to the nall/primitives
types, as the toInteger(), etc classes are a little wonky to use.
byuu says:
These WIPs are gonna be unstable for a bit, sorry. Large amounts of
changes. Right now, higan+bsnes compile, but only with cores="sfc gb".
There's a new nall::Settings class, which I really dislike the design
of, but as long as the classes that use it remain stable, then ... I'll
have to live with it for now.
Interface loses both the old get/set/cap interface, plus the
configuration interface. It now returns either properties() or
options(). Both return a Settings& object. There's also helpers for
accessing individual properties and options by string lookup.
Properties are immutable traits of the hardware itself: CPU version, PPU
VRAM size, boot ROM information, etc.
Options are mutable traits that users may change.
The idea with nall/settings is to build out a kind of extremely complex
configuration object that'll do everything we'd ever want:
- allow recursive children settings similar to Markup::Node
- access values directly without dynamic_cast (type erasure) or
string conversion (Markup::Node style)
- serialize to and unserialize from BML
- support valid values to guarantee that the settings are never in an
invalid state
- support latching of values to cache reads without another separate
variable (so the GUI can modify any variables at any time safely)
Todo:
- allow binding callback functions on assignment, so that eg changing
video/colorEmulation will regenerate the video palette
- provide a hint on whether an option can be changed dynamically at
run-time, or only statically at first load
- provide descriptions for each setting
And then once the class is fully fleshed out, I want to build a tool
that will generate a fancy modal hiro Window from a Settings& object.
Once that is complete, we'll then have System → Options to configure
per-emulator settings (like bsnes PPU stuff) that otherwise doesn't fit
into higan's GUI. We will be exposing the extended Super Famicom options
to the bsnes GUI, of course. That's the emulator tab there.
Next up, higan's systems tab will need to generate blank default
property files for each system, and let you configure system properties
from this screen. That's going to mean that, by allowing the same system
to appear multiple times, that each entry gets its own options file,
which will have to be stored somewhere.
And to do all of that, we really need to work out how to handle regions
first. It may have to be something radical like FitzRoy's idea, or it
may be that we can come up with something a little less drastic. But I
have no idea right now ...
What I'd really like to do is start trying to get bsnes v107 out
already. The two things holding it up are: fixing the desync between the
settings.bml GUI settings and options.bml SNES properties (I know what's
wrong, I just have to fix it), and getting XAudio2 DRC working (I copied
BearOso's implementation details, but it just doesn't work for me ...).
Then I also have to install Windows, set up a dev environment with
msys2, and build it all.
Lots and lots of work ...
byuu says:
In addition to the restructuring changes mentioned previously, I've
started on yet another attempt at unifying per-emulator core
configuration settings.
This time, everything is based on template<typename T> struct Setting;
which has child elements similar to Markup::Node, but holds the exact
type rather than a string that needs to be converted. If we had a
setting checked millions of times a second in the core (say, a mute flag
for a 2MHz audio chip), it would be too much overhead. I don't even want
it to be a heap-allocated pointer that has to be dynamic_casted
(nall::any), so it ends up more like an std::variadic object.
Setting classes construct the same way hiro does: the children specify
their parents in the variable declarations. From there, you can
serialize (and soon, unserialize) to (and from) BML.
Presently, I'm thinking we are going to want two separate settings
structures: one for fixed system properties (CPU version, PPU1 VRAM
amount, etc) -- basically, variables that describe a certain machine
configuration. And another for user-configurable properties (interframe
blending, color bleed, scanlines, speed hacks, etc.)
The reasoning is for higan: under the systems tab, when you pick a
system to add, it would be nice to display the system configuration
there. Polluting that with options you'd likely change at run-time would
be confusing and annoying.
I'm also hoping to write a rather complex class that will generate a
dialog window for editing all of the settings found. We could *really*
use TreeView on all platforms for this, heh ... I may have to go attempt
to merge hex_usr's previous work there.
In the future, I'd like to flesh out the settings even more with
optional additional things like lists of possible values, that can then
result in drop-downs in the generated dialogs.
The real question is ... is it time to use the new machine properties to
separate NTSC, PAL, etc regions? There's gonna be cases like the Mark
III having the YM2413 module, but only in Japan. The load dialog option
dropdown was always kind of a hacky way of doing regions.
...
Oh, I also wrote nall/instance.hpp, which is a grotesque delayed
construction hack. The amethyst hiro bug was kind of the last straw in
attempting to tame global construction order. I'm going to slowly kill
off hiro::initialize and revert back to requiring hiro objects to be
constructed -after- main().
byuu says:
The bad instruction was due to the instruction before it fetching one
too many bytes. Didn't notice right away as the disassembler got it
right.
The register map was incorrect on the active 16-bit flags.
I fixed and improved some other things along those lines. Hooked up some
basic KnGE (VPU) timings, made it print out VRAM and some of the WRAM
onto the screen each frame, tried to drive Vblank and Hblank IRQs, but
... I don't know for sure what vector addresses they belong to.
MAME says "INT4" for Vblank, and says nothing for Hblank. I am wildly
guessing INT4==SWI 4==0xffff10, but ... I have no idea. I'm also not
emulating the interrupts properly based on line levels, I'm just firing
on the 0→1 transitions. Sounds like Vblank is more nuanced too, but I
guess we'll see.
Emulation is running further along now, even to the point of it
successfully enabling the KnGE IRQs, but VRAM doesn't appear to get much
useful stuff written into it yet.
I reverted the nall/primitive changes, so request for testing is I guess
rescinded, for whatever it was worth.
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]
byuu says:
Changelog:
- reverted nall/inline-if.hpp usage for now, since the
nall/primitives.hpp math operators still cast to (u)int64_t
- improved nall/primitives.hpp more; integer8 x = -128; print(-x) will
now print 128 (unary operator+ and - cast to (u)int64_t)
- renamed processor/lr35902 to processor/sm83; after the Sharp SM83
CPU core [gekkio discovered the name]
- a few bugfixes to the TLCS900H CPU core
- completed the disassembler for the TLCS900H core
As a result of reverting most of the inline if stuff, I guess the
testing priority has been reduced. Which is probably a good thing,
considering I seem to have a smaller pool of testers these days.
Indeed, the TLCS900H core has ended up at 131KiB compared to the M68000
core at 128KiB. So it's now the largest CPU core in all of higan. It's
even more ridiculous because the M68000 core would ordinarily be quite a
bit smaller, had I not gone overboard with the extreme templating to
reduce instruction decoding overhead (you kind of have to do this for
RISC CPUs, and the inverted design of the TLCS900H kind of makes it
infeasible to do the same there.)
This CPU core is bound to have dozens of extremely difficult CPU bugs,
and there's no easy way for me to test them. I would greatly appreciate
any help in looking over the core for bugs. A fresh pair of eyes to spot
a mistake could save me up to several days of tedious debugging work.
The core still isn't ready to actually be tested: I have to hook up
cartridge loading, a memory bus, interrupts, timers, and the micro DMA
controller before it's likely that anything happens at all.
byuu says:
Half of the disassembler is implemented now. Well, the decoding half
anyway. I'm splitting the decoding and string building into separate
components this time around, on account of the instruction encoding
being in reverse order. The string building portion hasn't been written
yet, either.
We're up to 112KiB now, compared to 128KiB for the 68K.
byuu says:
First 32 instructions implemented in the TLCS900H disassembler. Only 992
to go!
I removed the use of anonymous namespaces in nall. It was something I
rarely used, because it rarely did what I wanted.
I updated all nested namespaces to use C++17-style namespace Foo::Bar {}
syntax instead of classic C++-style namespace Foo { namespace Bar {}}.
I updated ruby::Video::acquire() to return a struct, so we can use C++17
structured bindings. Long term, I want to get away from all functions
that take references for output only. Even though C++ botched structured
bindings by not allowing you to bind to existing variables, it's even
worse to have function calls that take arguments by reference and then
write to them. From the caller side, you can't tell the value is being
written, nor that the value passed in doesn't matter, which is terrible.
byuu says:
Any usage of natural and integer cast to 64-bit math operations now.
Hopefully this will be the last of the major changes for a bit on
nall/primitives, at least until serious work begins on removing implicit
conversion to primitive types.
I also completed the initial TLCS900H core, sans SWI (kind of a ways off
from support interrupts.) I really shouldn't say completed, though. The
micro DMA unit is missing, interrupt priority handling is missing,
there's no debugger, and, of course, there's surely dozens of absolutely
critical CPU bugs that are going to be an absolute hellscape nightmare
to track down.
It was a damn shame, right up until the very last eight instructions,
[CP|LD][I|D](R), the instruction encoding was consistent. Of course,
there could be other inconsistencies that I missed. In fact, that's
somewhat likely ... sigh.
byuu says:
This WIP is just work on nall/primitives ...
Basically, I'm coming to the conclusion that it's just not practical to
try and make Natural/Integer implicitly castable to primitive signed and
unsigned integers. C++ just has too many edge cases there.
I also want to get away from the problem of C++ deciding that all math
operations return 32-bit values, unless one of the parameters is 64-bit,
in which case you get a 64-bit value. You know, so things like
array[-1] won't end up accessing the 4 billionth element of the array.
It's nice to be fancy and minimally size operations (eg 32-bit+32-bit =
33-bit), but it's just too unintuitive. I think all
Natural<X>+Natural<Y> expessions should result in a Natural<64> (eg
natural) type.
nall/primitives/operators.hpp has been removed, and new
Natural<>Natural / Integer<>Integer casts exist. My feeling is that
signed and unsigned types should not be implicitly convertible where
data loss can occur. In the future, I think an integer8*natural8 is
fine to return an integer64, and the bitwise operators are probably all
fine between the two types. I could probably add
(Integer,Natural)+Boolean conversions as well.
To simplify expressions, there are new user-defined literals for _b
(boolean), _n (natural), _i (integer), _r (real), _n# (eg _n8),
_i# (eg _i8), _r# (eg _r32), and _s (nall::string).
In the long-term, my intention is to make the conversion and cast
constructors explicit for primitive types, but obviously that'll shatter
most of higan, so for now that won't be the case.
Something I can do in the future is allow implicit conversion and
casting to (u)int64_t. That may be a nice balance.
byuu says:
I've implemented a lot more TLCS900H instructions. There are currently
20 missing spots, all of which are unique instructions (well, MINC and
MDEC could be considered pairs of 3 each), from a map of 1024 slots.
After that, I have to write the disassembler. Then the memory bus. Then
I get to start the fun process of debugging this monstrosity.
Also new is nall/inline-if.hpp. Note that this file is technically a war
crime, so be careful when opening it. This replaces ternary() from the
previous WIP.
byuu says:
So this turned out to be a rather unproductive ten-hour rabbit hole, but
...
I reworked nall/primitives.hpp a lot. And because the changes are
massive, testing of this WIP for regressions is critically important. I
really can't stress that enough, we're almost certainly going to have
some hidden regressions here ...
We now have a nall/primitives/ subfolder that splits up the classes into
manageable components. The bit-field support is now shared between both
Natural and Integer. All of the assignment operator overloads are now
templated and take references instead of values. Things like the
GSU::Register class are non-copyable on account of the function<>
object inside of it, and previously only operator= would work with
classes like that.
The big change is nall/primitives/operators.hpp, which is a really
elaborate system to compute the minimum number of bits needed for any
operation, and to return a Natural<T> or Integer<T> when one or both of
the arguments are such a type.
Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3
breaks if we include operators.hpp. Zelda 3 runs fine with this, but I
had to make a huge amount of core changes, including introducing a new
ternary(bool, lhs, rhs) function to nall/algorithm to get past
Natural<X> and Natural<Y> not being equivalent (is_integral types get a
special exemption to ternary ?: type equivalence, yet it's impossible to
simulate with our own classes, which is bullshit.) The horrifying part
is that ternary() will evaluate both lhs and rhs, unlike ?:
I converted some of the functions to test ? uint(x) : uint(y), and
others to ternary(test, x, y) ... I don't have a strong preference
either way yet.
But the part where things may have gotten broken is in the changes to
where ternary() was placed. Some cases like in the GBA PPU renderer, it
was rather unclear the order of evaluations, so I may have made a
mistake somewhere.
So again, please please test this if you can. Or even better, look over
the diff.
Longer-term, I'd really like the enable nall/primitives/operators.hpp,
but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help
would be appreciated, but ... it's gonna be really complex and difficult
to debug, so I'm probably gonna be on my own here ... sigh.
byuu says:
I added some useful new functions to nall/primitives:
auto Natural<T>::integer() const -> Integer<T>;
auto Integer<T>::natural() const -> Natural<T>;
These let you cast between signed and unsigned representation without
having to care about the value of T (eg if you take a Natural<T> as a
template parameter.) So for instance when you're given an unsigned type
but it's supposed to be a sign-extended type (example: signed
multiplication), eg Natural<T> → Integer<T>, you can just say:
x = y.integer() * z.integer();
The TLCS900H core gained some more pesky instructions such as DAA, BS1F,
BS1B.
I stole an optimization from RACE for calculating the overflow flag on
addition. Assuming: z = x + y + c;
Before: ~(x ^ y) & (x ^ z) & signBit;
After: (x ^ z) & (y ^ z) & signBit;
Subtraction stays the same. Assuming: z = x - y - c;
Same: (x ^ y) & (x ^ z) & signBit;
However, taking a speed penalty, I've implemented the carry computation
in a way that doesn't require an extra bit.
Adding before:
uint9 z = x + y + c;
c = z & 0x100;
Subtracting before:
uint9 z = x - y - c;
c = z & 0x100;
Adding after:
uint8 z = x + y + c;
c = z < x || z == x && c;
Subtracting after:
uint8 z = x - y - c;
c = z > x || z == x && c;
I haven't been able to code golf the new carry computation to be any
shorter, unless I include an extra bit, eg for adding:
c = z < x + c;
But that defeats the entire point of the change. I want the computation
to work even when T is uintmax_t.
If anyone can come up with a faster method, please let me know.
Anyway ... I also had to split off INC and DEC because they compute
flags differently (word and long modes don't set flags at all, byte mode
doesn't set carry at all.)
I also added division by zero support, although I don't know if it's
actually hardware accurate. It's what other emulators do, though.
byuu says:
So tired ... so much left to do still ... sigh.
If someone's up for some code golf, open to suggestions on how to handle
the INTNEST control register. It's the only pure 16-bit register on the
system, and it breaks my `map`/`load`/`store<uint8,16,32>` abstraction.
Basically what I suspect happens is when you access INTNEST in 32-bit
mode, the upper 16-bits are just undefined (probably zero.) But
`map<uint32>(INTNEST)` must return a uint32& or nothing at all. So for the
time being, I'm just making store(ControlRegister) check if it's the
INTNEST ID, and clearing the upper bits of the written byte in that
case. It's hacky, but ... it's the best I can think of.
I added LDX, which is a 900H-only instruction, and the control register
map is for the 900/H CPU. I found the detailed differences between the
CPUs, and it doesn't look likely that I'm gonna support the 900 or
900/H1 at all. Not that there was a reason to anyway, but it's nice to
support more stuff when possible. Oh well.
The 4-byte instruction fetch queue is going to have to get implemented
inside fetch, or just not implemented at all ... not like I'd be able to
figure out the details of it anyway.
The manual isn't clear on how the MULA flags are calculated, but since
MUL doesn't set any flags, I assume the flags are based on the addition
after the multiplication, eg:
uint32 a = indirect<int16>(XDE) * indirect<int16>(XHL);
uint32 b = reg16; //opcode parameter
uint32 c = a + b; //flags set based on a+b
No idea if it's right or not. It doesn't set carry or half-carry, so
it's not just simply the same as calling algorithmAdd.
Up to almost 70KB, not even halfway done, don't even have a disassembler
started yet. There's a real chance this could overtake the 68K for the
biggest CPU core in higan, although at this point I'm still thinking the
68K will end up larger.
byuu says:
So I spent the better part of eight hours refactoring the TLCS900H core
to be more flexible in light of new edge cases.
I'm now including the size information inside of the types (eg
Register<Byte>, Memory<Word>) rather than as parameters to the
instruction handlers. This allows me to eg implement RETI without
needing template arguments in all the instructions. pop(SR), pop(PC) can
deduce how much to pop off of the stack. It's still highly templated,
but not unrolling the 3-bit register indexes and instead going through
the switch table to access registers is going to hurt the performance a
good deal.
A benefit of this is that Register{A} != Register{WA} != Register{XWA}
anymore, despite them sharing IDs.
I also renamed read/write to load/store for the CPU core, because
implicit conversions are nasty. They all call the virtual read/write.
I added more instructions, improved the memory addressing mode support,
and some other things.
I got rid of Byte, Word, Long because there's too many alternate sizes
needed: int8, int16, uint24, etc.
Ran into a really annoying C++ case ...
struct TLCS900H {
template<typename T> auto store(Register<T> target, T source) -> void;
};
If you call store(Register<uint32>(x), uint16(y)); it errors out since
the T types don't match. But you can't specialize it:
template<typename T, typename U> auto store(Register<T>, U) -> void;
template<typename U> auto TLCS900H::store<uint32, U>(Register<uint32>, U) -> void;
Because somehow it's 2019 and we still can't do partial template
specialization inside classes ...
So as a result, I had to make T source be type uint32 even for
Register<uint8> and Register<uint16>. Doesn't matter too much, just
annoying.
byuu says:
This probably won't fix the use of register yet (I imagine ruby and hiro
will complain now), but ... oh well, it's a start. We'll get it
compiling again eventually.
I added JP, JR, JRL, LD instructions this time around. I'm also starting
to feel that Byte, Word, Long labels for the TLCS900H aren't really
working. There's cases of needing uint24, int8, int16, ... it may just
be better to name the types instead of trying to be fancy.
At this point, all of the easy instructions are in. Now it's down to a
whole lot of very awkward bit-manipulation and special-use instructions.
Sigh.
byuu says:
For this WIP, I added more TLCS900H instructions. All of the
ADC,ADD,SBB/SBC,SUB,AND,OR,XOR.CP,PUSH,POP instructions are in.
Still an incredible amount of work left to do on this core ... it has all kinds
of novel instructions that aren't on any other processors.
Still no disassembler support yet, so I can't even test what I'm doing. Fun!
byuu says:
I started working on the Toshiba TLCS900H CPU core today.
It's basically, "what if we took the Z80, added in 32-bit support, added
in SPARC register windows, added a ton of additional addressing modes,
added control registers, and added a bunch of additional instructions?"
-- or in other words, it's basically hell for me.
It took several hours just to wrap my head around the way the opcode
decoder needed to function, but I think I have a decent strategy for
implementing it now.
I should have all of the first-byte register/memory address decoding in
place, although I'm sure there's lots of bugs. I don't have anything in
the way of a disassembler yet.
byuu says:
Changelog:
- Interface::displays() -> vector<Display> → Interface::display() -> Display
- <Platform::videoRefresh(display>, ...) → <Platform::videoFrame>(...)
- <Platform::audioSample>(...) → <Platform::audioFrame>(...)
- higan, icarus: use AboutDialog class instead of ad-hoc
implementations
- about dialog is now modal, but now has a clickable website URL
- icarus: reverted if constexpr for now
- MSX: implemented basic CPU, VDP support
I took out the multiple displays support thing because it was never
really implemented fully (Emulator::Video and the GUIs both ignored it)
or used anyway. If it ends up necessary in the future, I'll worry about
it then.
There's enough MSX emulation now to run Mr. Do! without sound or input.
I'm shipping higan with C-BIOS 0.29a, although it likely won't be good
enough in the future (eg it can't do BASIC, floppy disk, or cassette
loading.) I have keyboard and (not working) AY-3-8910 support in a
different branch, so that won't take too long to implement. Main problem
is naming all the darned keyboard keys. I think I need to change
settings.bml's input mapping lines so that the key names are values
instead of node names, so that any characters can appear inside of them.
It turns out my MSX set uses .rom for the file extensions ... gods. So,
icarus can't really import them like this. I may have to re-design
icarus' importer to stop caring about the file extension and instead ask
you what kind of games you are importing. There's no way icarus can
heuristically guess what systems the images belong to, because many
systems don't have any standardized magic bytes.
I'm struggling with where to put SG-1000, SC-3000, ColecoVision, Coleco
Adam stuff. I think they need to be split to two separate higan
subfolders (sg and cv, most likely ...) The MS/GG share a very
customized and extended VDP that the other systems don't have. The Sega
and Coleco older hardware share the same TMS9918 as the MSX, yet have
very different memory maps and peripherals that I don't want to mix
together. Especially if we start getting into the computer-variants
more.
Debian has served us well, but byuu would like to start using C++17 features
which generally requires GCC7. Debian Stable only has GCC6 right now, while
Ubuntu LTS has the required version, so that should get things going again.
byuu says:
The biggest change was improving WonderSwan emulation. With help from
trap15, I tracked down a bug where I was checking the wrong bit for
reverse DMA transfers. Then I also emulated VTOTAL to support variable
refresh rate. Then I improved HyperVoice emulation which should be
unsigned samples in three of four modes. That got Fire Lancer running
great. I also rewrote the disassembler. The old one disassembled many
instructions completely wrong, and deviated too much from any known x86
syntax. I also emulated some of the quirks of the V30 (two-byte POP into
registers fails, SALC is just XLAT mirrored, etc) which probably don't
matter unless someone tries to run code to verify it's a NEC CPU and not
an Intel CPU, but hey, why not?
I also put more work into the MSX skeleton, but it's still just a
skeleton with no real emulation yet.
byuu says:
Changelog:
- nall: converted range, iterator, vector to 64-bit
- added (very poor) ColecoVision emulation (including Coleco Adam
expansion)
- added MSX skeleton
- added Neo Geo Pocket skeleton
- moved audio,video,resource folders into emulator folder
- SFC heuristics: BS-X Town cart is "ZBSJ" [hex_usr]
The nall change is for future work on things like BPA: I need to be able
to handle files larger than 4GB. It is extremely possible that there are
still some truncations to 32-bit lurking around, and even more
disastrously, possibly some -1s lurking that won't sign-extend to
`(uint64_t)0-1`. There's a lot more classes left to do: `string`,
`array_view`, `array_span`, etc.
byuu says:
Changelog:
- added all pre-requisite to make install rule (note: only for higan,
icarus so far)
- added SG-1000 emulation
- added SC-3000 emulation (no keyboard support yet)
- added MS graphics mode 1 emulation (SC-1000)
- added MS graphics mode 2 emulation (F-16 Fighter)
- improve Audio::process() to prevent a possible hang
- higan: repeat monaural audio to both left+right speakers
- icarus: add heuristics for importing MSX games (not emulated in
higan yet in this WIP)
- added DC bias removal filter [jsd1982]
- improved Audio::Stream::reset() [jsd1982]
I was under the impression that the 20hz highpass filter would have
removed DC bias ... if not, then I don't know why I added that filter to
all of the emulation cores that have it. In any case, if anyone is up
for helping me out ... if we could analyze the output with and without
the DC bias filter to see if it's actually helping, then I'll enable it
if it is. To enable it, edit
higan/audio/stream.cpp::addDCRemovalFilter() and remove the return
statement at the top of the function.
At some point, higan moved system metadata from higan/profile to higan/systems.
Also, higan's Super Famicom core added config options of its own, which it now
writes out.
byuu says:
Changelog:
- moved to GCC 8.2 and C++17
- fixed compilation under FreeBSD 12.0
- don't read beyond the file size in
SuperFamicom::Cartridge::loadMemory
- add missing I/O cycle HuC6280::instructionImmediate
- serialize Mega Drive's Game Genie state
- serialize SPC7110::Thread information
- enable 30-bit color depth support under the GLX/OpenGL 2.0 driver
(doesn't work with OpenGL 3.2 yet)
The 30-bit color depth option isn't super useful, but why not? I need to
update ruby to detect that the display is actually capable of it before
exposing an option that can result in the driver failing to initialize,
however.
Changes include:
- The "Library" menu was replaced with the "Systems" menu
- The "Settings" menu was reorganised
- Game Boy rumble is now under the MBC5 "controller" for the cartridge "port",
instead of being presented as a part of the base console
- Import instructions now mention that icarus ships with some firmware files,
and describe the "Firmware" directory that icarus will use for firmware
it needs.
- Apparently the correct name is "MSU1", not "MSU-1"
- v107 changes the way MSU1 data is stored in game folders
- PowerFest '94 import instructions removed, since I can't get it to work
with v107
- Links to the official forum have been replaced with links to the unofficial
forum archive, since the official forum is shutting down
- Links to Mercurial Magic updated to point at qwertymodo's archive, since
hex_usr is no longer developing it
- Links to nSide updated, since hex_usr no longer uses GitHub.
- Windows build instructions now describe a compiler that is actually
maintained, instead of stale TDM64-GCC.
- Linux build instructions now mention higan requires SDL 2.0.
- minor wording changes, typos, broken links fixed, etc.
The latest WIP renames icarus/database and icarus/firmware to
icarus/Database and icarus/Firmware (in title case).
Also, somewhere along the line we stopped building icarus for higan/Linux,
which seems an oversight.
byuu says:
This synchronizes bsnes/higan with many recent internal nall changes.
This will be the last WIP until I am situated in Japan. Apologies for the
bugfixes that didn't get applied yet, I ran out of time.
byuu says:
Changelog:
- sfc: completed BS Memory Cassette emulation (sans bugs, of course --
testing appreciated)
- bsnes: don't strip - on MSU1 track names in game ROM mode
[hex_usr]
I'm going with "metadata.bml" for the flash metadata filename for the
time being, but I'll say that it's subject to change. I'll have to make
a new extension for it to be supported with bsnes.
byuu says:
Changelog:
- gb/mbc7: rewrote the 93LCx6 EEPROM emulation
- sfc/slot/bsmemory: rewrote the flash emulation for Satellaview
cartridges
As of this release, flash-based BS Memory cartridges will be writable.
So without the bsnes patch to disable write limits, some games will lock
out after a few plays.
byuu says:
Changelog:
- sfc/cx4: added missing instructions [info from Overload]
- sfc/cx4: added instruction cache emulation [info from ikari]
- sfc/sa1: don't let CPU access SA1-only I/O registers, and vice versa
- sfc/sa1: fixed IRQs that were broken from the recent WIP
- sfc/sa1: significantly improved bus conflict emulation
- all tests match hardware now, other than HDMA ROM↔ROM, which
is 0.5 - 0.8% too fast
- sfc/cpu: fixed a bug with DMA→CPU alignment timing
- sfc/cpu: removed the DMA pipe; performs writes on the same cycles as
reads [info from nocash]
- sfc/memory: fix a crashing bug due to not clearing Memory size field
[hex_usr]
- bsnes/gb: use .rtc for real-time clock file extensions on the Game
Boy [hex_usr]
- ruby/cgl: compilation fix [Sintendo]
Now let's see if I can accept being off by ~0.65% on one of twelve SA1
timing tests for the time being and prioritize much more important
things or not.
byuu says:
This release adds ikari's Cx4 notes to bsnes. It fixes the MMX2 intro's
boss fight sequence to be frame perfect to real hardware. It's also very
slightly faster than before.
I've also added an option to toggle the CPU↔coprocessor cycle
synchronization to the emulation settings panel, so you don't have to
recompile to get the more accurate SA1 timings. I'm most likely going to
default this to disabled in bsnes, and *maybe* enabled in higan out of
the box.
StaticRAM (wasn't used) and MappedRAM are gone from the Super Famicom
core. Instead, there's now ReadableMemory, WritableMemory, and
ProtectedMemory (WritableMemory with a toggle for write protection.)
Cartridge::loadMap now takes a template Memory object, which bypasses an
extra virtual function call on memory accesses, but it doesn't really
impact speed much. Whatever.
byuu says:
I added (imperfect) memory conflict timing to the SA1.
Before:
- WRAM↔↔ROM ran 7% too fast
- ROM↔↔ROM ran 100% too fast
- WRAM↔↔IRAM ran 7% too fast
- ROM↔↔IRAM ran 7% too fast
- IRAM↔↔IRAM ran 287% too fast
- BWRAM↔↔BWRAM ran 100% too fast
- HDMA ROM↔↔ROM ran 15% too fast
- HDMA WRAM↔↔ROM ran 15% too fast
- DMA ROM↔↔ROM ran 100% too fast
After:
- ROM↔↔ROM runs 14% too fast
- HDMA WRAM↔↔ROM runs 7% too fast
- DMA ROM↔↔ROM runs 4% too fast
If you enable this with the fast PPU + DSP, your framerate in SA1 games
will drop by 51%. And even if you disable it, you'll still lose 9% speed
in SA1 games, and 2% speed in non-SA1 games, because of changes needed
to make this support possible.
By default, I'm leaving this off. Compile with `-DACCURATE_SA1` (or
uncomment the line in sfc/sfc.hpp) if you want to try it out.
This'll almost certainly cause some SA1 regressions, so I guess we'll
tackle those as they arise.
byuu says:
Changelog:
- fixed bug in Emulator::Game::Memory::operator bool()
- nall: renamed view<string> back to `string_view`
- nall:: implemented `array_view`
- Game Boy: split cartridge-specific input mappings (rumble,
accelerometer) to their own separate ports
- Game Boy: fixed MBC7 accelerometer x-axis
- icarus: Game Boy, Super Famicom, Mega Drive cores output internal
header game titles to heuristics manifests
- higan, icarus, hiro/gtk: improve viewport geometry configuration;
fixed higan crashing bug with XShm driver
- higan: connect Video::poll(),update() functionality
- hiro, ruby: several compilation / bugfixes, should get the macOS
port compiling again, hopefully [Sintendo]
- ruby/video/xshm: fix crashing bug on window resize
- a bit hacky; it's throwing BadAccess Xlib warnings, but they're
not fatal, so I am catching and ignoring them
- bsnes: removed Application::Windows::onModalChange hook that's no
longer needed [Screwtape]
byuu says:
The main thing I worked on today was emulating the MBC7 EEPROM.
And... I have many things to say about that, but not here, and not now...
The missing EEPROM support is why the accelerometer was broken. Although
it's not evidently clear that I'm emulating the actual values
incorrectly. I'll think about it and get it fixed, though.
bsnes went from ~308fps to ~328fps, and I don't even know why. Probably
something somewhere in the 140KB of changes to other things made in this
WIP.
byuu says:
The Windows port can now run the emulation while navigating menus,
moving windows, and resizing windows. The main window also doesn't try
so hard to constantly clear itself. This may leave a bit of unwelcome
residue behind in some video drivers during resize, but under most
drivers, it lets you resize without a huge amount of flickering.
On all platforms, I now also run the emulation during MessageWindow
modal events, where I didn't before.
I'm thinking we should probably mute the audio during modal periods,
since it can generate a good deal of distortion.
The tooltip timeout was increased to ten seconds.
On Windows, the enter key can now activate buttons, so you can more
quickly dismiss MessageDialog windows. This part may not actually work
... I'm in the middle of trying to get messages out of the global
`Application_windowProc` hook and into the individual `Widget_windowProc`
hooks, so I need to do some testing.
I fixed a bug where changing the input driver wouldn't immediately
reload the input/hotkey settings lists properly.
I also went from disabling the driver "Change" button when the currently
active driver is selected in the list, to instead setting it to say
"Reload", and I also added a tool tip to the input driver reload button,
advising that if you're using DirectInput or SDL, you can hit "Reload"
to rescan for hotplugged gamepads without needing to restart the
emulator. XInput and udev have auto hotswap support. If we can ever get
that into DirectInput and SDL, then I'll remove the tooltip. But
regardless, the reload functionality is nice to have for all drivers.
I'm not sure what should happen when a user changes their driver
selection while a game is loaded, gets the warning dialog, chooses not
to change it, and then closes the emulator. Currently, it will make the
change happen the next time you start the emulator. This feels a bit
unexpected, but when you change the selection without a game loaded, it
takes immediate effect. So I'm not really sure what's best here.
byuu says:
This release fixes the XAudio 2.1 and WASAPI drivers on Windows, and
extends XAudio to support device selection (eg headphones, speakers,
monitor, etc.) It also adds DRC to XAudio, however it's not currently
working.
The code is courtesy of Talarubi, I just botched it somewhere upon
porting it to the newer version of ruby.
byuu says:
I've added tool tips to hiro for Windows, GTK, and Qt. I'm unsure how to
add them for Cocoa. I wasted am embarrassing ~14 hours implementing tool
tips from scratch on Windows, because the `TOOLTIPS_CLASS` widget just
absolutely refused to show up, no matter what I tried. As such, they're
not quite 100% native, but I would really appreciate any patch
submissions to help improve my implementation.
I added tool tips to all of the confusing settings in bsnes. And of
course, for those of you who don't like them, there's a configuration
file setting to turn them off globally.
I also improved Mega Drive handling of the Game Genie a bit, and
restructured the way the Settings class works in bsnes.
Starting now, I'm feature-freezing bsnes and higan. From this point
forward:
- polishing up and fixing bugs caused by the ruby/hiro changes
- adding DRC to XAudio2, and maybe exclusive mode to WGL
- correcting FEoEZ (English) to load and work again out of the box
Once that's done, a final beta of bsnes will go out, I'll fix any
reported bugs that I'm able to, and then v107 should be ready. This time
with higan being functional, but marked as v107 beta. v108 will restore
higan to production status again, alongside bsnes.
byuu says:
I fixed all outstanding bugs that I'm aware of, including all of the
errata I listed yesterday.
And now it's time for lots of regression testing.
After that, I need to add Talarubi's XAudio2 DRC code, and then get a
new public bsnes WIP out for final testing.
New errata: when setting an icon (nall::image) larger than a Canvas on
Windows, it's not centering the image, so you end up seeing the overscan
area in the state manager previews, and the bottom of the image gets cut
off. I also need to forcefully disable the Xlib screensaver disable
support. I think I'll remove the GUI option to bypass it as well, and
just force screensaver disable always on with Windows. I'll improve it
in the future to toggle the effect between emulator pauses.
byuu says:
Everything *should* be working again, but of course that won't
actually be the case. Here's where things stand:
- bsnes, higan, icarus, and genius compile and run fine on FreeBSD
with GTK
- ruby video and audio drivers are untested on Windows, macOS, and
Linux
- hiro is untested on macOS
- bsnes' status bar is not showing up properly with hiro/qt
- bsnes and higan's about screen is not showing up properly with
hiro/qt (1x1 window size)
- bsnes on Windows crashes often when saving states, and I'm not sure
why ... it happens inside Encode::RLE
- bsnes on Windows crashes with ruby.input.windows (unsure why)
- bsnes on Windows fails to show the verified emblem on the status bar
properly
- hiro on Windows flickers when changing tabs
To build the Windows bsnes and higan ports, use
ruby="video.gdi audio.directsound"
Compilation error logs for Linux will help me fix the inevitable list of
typos there. I can fix the typos on other platforms, I just haven't
gotten to it yet.
The WonderSwan Color came out in 2000 and the GBA in 2001, so technically
they're not "video-game consoles of the 1980s and 1990s". Since there's no
elegant way to talk about the 2000-2009 timespan, let's just not mention
dates at all.
byuu says:
Changes to hiro will break all but the GTK target. Not that it matters
much given that the only ruby drivers that function are all on BSD
anyway.
But if you are fortunate enough to be able to run this ... you'll find
lots of polishing improvements to the bsnes GUI. I posted some
screenshots on Twitter, if anyone were interested.
byuu says:
Okay, so the WIPs-within-WIPs thing wasn't achieving its desired effect,
and it ended up causing me to have to redo some work on hiro since my
last local snapshot was of r52. So, heck it. I'll just do mostly
non-functional WIPs for a bit, and worry about the fallout years later
when I'm trying to find an emulation regression and cursing that the
WIPs aren't compiling.
I ported all of the ruby input drivers to the new syntax, as well as the
OpenAL driver. If you patch the ruby drivers for Linux with this in
mind, bsnes should compile and run there again.
Also, the bsnes program icon has returned, now that the new hiro layout
code is mature enough and I can simply add and remove the icon as a
Canvas instead of having to try and render into a viewport. The icon
shows up instantly with the main window.
byuu says:
I've completed moving all the class objects from `unique_pointer<T>` to
just T. The one exception is the Emulator::Interface instance. I can
absolutely make that a global object, but only in bsnes where there's
just the one emulation core.
I also moved all the SettingsWindow and ToolsWindow panels out to their
own global objects, and fixed a very difficult bug with GTK TabFrame
controls.
The configuration settings panel is now the emulator settings panel. And
I added some spacing between bold label sections on both the emulator
and driver settings panels.
I gave fixing ComboButtonItem my best shot, given I can't reproduce the
crash. Probably won't work, though.
Also made a very slight consistency improvement to ruby and renamed
driverName() to driver().
...
An important change ... as a result of moving bsnes to global objects,
this means that the constructors for all windows run before the
presentation window is displayed. Before this change, only the
presentation window was constructed first berore displaying it, followed
by the construction of the rest of the GUI windows.
The upside to this is that as soon as you see the main window, the GUI
is ready to go without a period where it's unresponsive.
The downside to this is it takes about 1.5 seconds to show the main
window, compared to around 0.75 seconds before.
I've no intention of changing that back. So if the startup time becomes
a problem, then we'll just have to work on optimizing hiro, so that it
can construct all the global Window objects quicker. The main way to do
that would be to not do calls to the Layout::setGeometry functions for
every widget added, and instead wait until the window is displayed. But
I don't have an easy way to do that, because you want the widget
geometry values to be sane even before the window is visible to help
size certain things.
byuu says:
These WIPs-within-WIPs are getting more and more broken ... this isn't
going the way I wanted.
But ... this time around, I've revamped the entire ruby API again, to
solve a bunch of tough problems that have always made using ruby really
clunky.
But there are *so many* ruby drivers that it's going to take a long
time to work through them all. This WIP is only going to run bsnes, and
only on FreeBSD, and only with some drivers.
hiro's Application::initialize() now calls hiro::initialize(), which you
define inside of your hiro apps. This lets you call
Application::setName(...) before anything else in hiro runs. This is
essential on Xorg to set program icons, for instance.
With the ruby rewrite and the change to hiro, I can get away from the
need to make everything in bsnes/higan pointers to objects, and can now
just declare them as regular objects.
byuu wrote:
Sigh ...
asio.hpp needs #include <nall/windows/registry.hpp>
[Since the last WIP, byuu also posted the following message. -Ed.]
ruby drivers have all been updated (but not tested outside of BSD), and
I redesigned the settings window. The driver functionality all exists on
a new "Drivers" panel, the emulator/hack settings go to a
"Configuration" panel, and the video/audio panels lose driver settings.
As does the settings menu and its synchronize options.
I want to start pushing toward a v107 release. Critically, I will need
DirectSound and ALSA to support dynamic rate control. I'd also like to
eliminate the other system manifest.bml files. I need to update the
cheat code database format, and bundle at least a few quark shaders --
although I still need to default to Direct3D on Windows.
Turbo keys would be nice, if it's not too much effort. Aside from
netplay, it's the last significant feature I'm missing.
I think for v107, higan is going to be a bit rough around the edges
compared to bsnes. And I don't think it's practical to finish the bsnes
localization support.
I'm thinking we probably want another WIP to iron out any critical
issues, but this time there should be a feature freeze with the next
WIP.
byuu says:
Sigh, I seem to be spiraling a bit here ... but the work is very
important. Hopefully I can get a solid WIP together soon. But for now...
I've integrated dynamic rate control into ruby::Audio via
setDynamic(bool) for now. It's very demanding, as you would expect. When
it's not in use, I realized the OSS driver's performance was pretty bad
due to calling write() for every sample for every channel. I implemented
a tiny 256-sample buffer and bsnes went from 290fps to 330fps on my
FreeBSD desktop. It may be possible to do the same buffering with DRC,
but for now, I'm not doing so, and adjusting the audio input frequency
on every sample.
I also added ruby::Video::setFlush(bool), which is available only in the
OpenGL drivers, and this causes glFinish() to be called after swapping
display buffers. I really couldn't think of a good name for this, "hard
GPU sync" sounds kind of silly. In my view, flush is what commits queued
events. Eg fflush(). OpenGL of course treats glFlush differently (I
really don't even know what the point of it is even after reading the
manual ...), and then has glFinish ... meh, whatever. It's
setFlush(bool) until I come up with something better. Also as expected,
this one's a big hit to performance.
To implement the DRC, I started putting helper functions into the ruby
video/audio/input core classes. And then the XVideo driver started
crashing. It took hours and hours and hours to track down the problem:
you have to clear XSetWindowAttributes to zero before calling
XCreateWindow. No amount of `--sync`, `gdb break gdk_x_error`, `-Og`,
etc will make Xlib be even remotely helpful in debugging errors like
this.
The GLX, GLX2, and XVideo drivers basically worked by chance before. If
the stack frame had the right memory cleared, it worked. Otherwise it'd
crash with BadValue, and my changing things broke that condition on the
XVideo driver. So this has been fixed in all three now.
Once XVideo was running again, I realized that non-power of two video
sizes were completely broken for the YUV formats. It took a while, but I
managed to fix all of that as well.
At this point, most of ruby is going to be broken outside of FreeBSD, as
I still need to finish updating all the drivers.
byuu says:
Once again, I wasn't able to complete a full WIP revision.
This WIP-WIP adds very sophisticated emulation of the Sega Genesis
Lock-On and Game Genie cartridges ... essentially, through recursion and
a linked list, higan supports an infinite nesting of cartridges.
Of course, on real hardware, after you stack more than three or four
cartridges, the power draw gets too high and things start glitching out
more and more as you keep stacking. I've heard that someone chained up
to ten Sonic & Knuckles cartridges before it finally became completely
unplayable.
And so of course, higan emulates this limitation as well ^-^. On the
fourth cartridge and beyond, it will become more and more likely that
address and/or data lines "glitch" out randomly, causing various
glitches. It's a completely silly easter egg that requires no speed
impact whatsoever beyond the impact of the new linked list cartridge
system.
I also designed the successor to Emulator::Interface::cap,get,set. Those
were holdovers from the older, since-removed ruby-style accessors.
In its place is the new Emulator::Interface::configuration,configure
API. There's the usual per-property access, and there's also access to
read and write all configurable options at once. In essence, this
enables introspection into core-specific features.
So far, you can control processor version#s, PPU VRAM size, video
settings, and hacks. As such, the .sys/manifest.bml files are no longer
necessary. Instead, it all goes into .sys/configuration.bml, which is
generated by the emulator if it's missing.
higan is going to take this even further and allow each option under
"Systems" to have its own editable configuration file. So if you wanted,
you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option.
Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the
various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate"
option.
I've not fully settled on the syntax of the new configuration API. I
feel it might be useful to provide type information, but I really quite
passionately hate any<T> container objects. For now it's all
string-based, because strings can hold anything in nall.
I might also change the access rules. Right now it's like:
emulator→configure("video/blurEmulation", true); but it might be nicer
as "Video::Blur Emulation", or "Video.BlurEmulation", or something like
that.
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.
byuu says:
I failed to complete a WIP, have five of eight cores updated with some
major changes to Emulator::Interface. I'll just post a quick temporary
WIP in the off chance someone wants to look over the new interface and
comment on it.
Also implemented screen saver suppression into hiro/GTK.
I should also add ... a plan of mine is to develop target-bsnes into a
more generic user interface, with the general idea being that
target-higan is for multiple Emulator::Interface cores at the same time,
and target-bsnes is for just one Emulator::Interface core.
The idea being that if one were to compile target-bsnes with the GBA
core, it'd become bgba, for instance.
I don't plan on releasing single-core emulators like this, but ... I don't see any downsides to being more flexible.
byuu says:
Changelog:
- added `Emulator::Interface::connected(uint port) -> uint device;`
- higan, bsnes: updated emulators to use the new
Emulator::Interface::connected() function
- hiro: fixed Object::cast<T> finally
So, Emulator::Interface::connected() solves two annoying problems at the
same time.
First, on first run of the emulator when the settings file is blank, it
will retrieve the default "sane" device ID, which is usually a gamepad
for a controller port, or nothing for an expansion/extension port.
Second, if you were to select a multi-port device, like the NES Four
Score, the core will set the other port to the Four Score device as
well, and the GUIs query connected() right after any call to connect(),
so it gets updated without needing a system for the emulation core to
send messages alerting the GUI of changes.
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
byuu says:
This is a fairly radical WIP with extreme changes to lots of very
important parts.
The result is a ~7% emulation speedup (with bsnes, unsure how much it
helps higan), but it's quite possible there are regressions. As such, I
would really appreciate testing as many games as possible ... especially
the old finnicky games that had issues with DMA and/or interrupts.
One thing to note is that I removed an edge case test that suppresses
IRQs from firing on the very last dot of every field, which is a
behavior I've verified on real hardware in the past. I feel that the
main interrupt polling function (the hottest portion of the entire
emulator) is not the appropriate place for it, and I should instead
factor it into assignment of NMITIMEN/VTIME/HTIME using the new
io.irqEnable (==virqEnable||hirqEnable) flag. But since I haven't done
that yet ... there's an old IRQ test ROM of mine that'll fail for this
WIP. No commercial games will ever rely on this, so it's fine for
testing.
Changelog:
- sfc/cpu.smp: inlined the global status functions
- sfc/cpu: added readRAM, writeRAM to use a function pointer instead
of a lambda for WRAM access
- sfc/cpu,smp,ppu/counter: updated reset functionality to new style
using class inline initializers
- sfc/cpu: fixed power(false) to invoke the reset vector properly
- sfc/cpu: completely rewrote DMA handling to have per-channel
functions
- sfc/cpu: removed unused joylatch(), io.joypadStrobeLatch
- sfc/cpu: cleaned up io.cpp handlers
- sfc/cpu: simplified interrupt polling code using
nall::boolean::flip(),raise(),lower() functions
- sfc/ppu/counter: cleaned up the class significantly and also
optimized things for efficiency
- sfc/ppu/counter: emulated PAL 1368-clock long scanline when
interlace=1, field=1, vcounter=311
- sfc/smp: factored out the I/O and port handlers to io.cpp
byuu says:
The problems with the Windows and Qt4 ports have all been resolved,
although there's a fairly gross hack on a few Qt widgets to not destruct
once Application::quit() is called to avoid a double free crash (I'm
unsure where Qt is destructing the widgets internally.) The Cocoa port
compiles again at least, though it's bound to have endless problems. I
improved the Label painting in the GTK ports, which fixes the background
color on labels inside TabFrame widgets.
I've optimized the Makefile system even further.
I added a "redo state" command to bsnes, which is created whenever you
load the undo state. There are also hotkeys for both now, although I
don't think they're really something you want to map hotkeys to.
I moved the nall::Locale object inside hiro::Application, so that it can
be used to translate the BrowserDialog and MessageDialog window strings.
I improved the Super Game Boy emulation of `MLT_REQ`, fixing Pokemon
Yellow's custom border and probably more stuff.
Lots of other small fixes and improvements. Things are finally stable
once again after the harrowing layout redesign catastrophe.
Errata:
- ICD::joypID should be set to 3 on reset(). joypWrite() may as well
take uint1 instead of bool.
- hiro/Qt: remove pWindow::setMaximumSize() comment; found a
workaround for it
- nall/GNUmakefile: don't set object.path if it's already set (allow
overrides before including the file)
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
byuu says:
Changelog:
- bsnes, higan: simplified make output; reordered rules
- hiro: added Window::set(Minimum,Maximum)Size() [only implemented in
GTK+ so far]
- bsnes: only allow the window to be shrunk to the 1x multiplier size
- bsnes: refactored Integral Scaling checkbox to {Center, Scale,
Stretch} radio selection
- nall: call fflush() after nall::print() to stdout or stderr [needed
for msys2/bash]
- bsnes, higan: program/interface.cpp renamed to program/platform.cpp
- bsnes: trim ".shader/" from names in Settings→Shader menu
- bsnes: Settings→Shader menu updated on video driver changes
- bsnes: remove missing games from recent files list each time it is
updated
- bsnes: video multiplier menu generated dynamically based on largest
monitor size at program startup
- bsnes: added shrink window and center window function to video
multiplier menu
- bsnes: de-minimize presentation window when exiting fullscreen mode
or changing video multiplier
- bsnes: center the load game dialog against the presentation window
(important for multi-monitor setups)
- bsnes: screenshots are not immediate instead of delayed one frame
- bsnes: added frame advance menu option and hotkey
- bsnes: added enable cheats checkbox and hotkey; can be used to
quickly enable/disable all active cheats
Errata:
- hiro/Windows: `SW_MINIMIZED`, `SW_MAXIMIZED `=> `SW_MINIMIZE`,
`SW_MAXIMIZE`
- hiro/Windows: add pMonitor::workspace()
- hiro/Windows: add setMaximized(), setMinimized() in
pWindow::construct()
- bsnes: call setCentered() after setMaximized(false)
byuu says:
Changelog:
- sfc/ppu-fast: added hires mode 7 option (doubles the sampling rate
of mode 7 pixels to reduce aliasing)
- sfc/ppu-fast: fixed mode 7 horizontal screen flip [hex_usr]
- bsnes: added capture screenshot function and path selection
- for now, it saves as BMP. I need a deflate implementation that
won't add an external dependency for PNG
- the output resolution is from the emulator: (256 or 512)x(240 or
480 minus overscan cropping if enabled)
- it captures the NEXT output frame, not the current one ... but
it may be wise to change this behavior
- it'd be a problem if the core were to exit and an image was
captured halfway through frame rendering
- bsnes: recovery state renamed to undo state
- bsnes: added manifest viewer tool
- bsnes: mention if game has been verified or not on the status bar
message at load time
- bsnes, nall: fixed a few missing function return values
[SuperMikeMan]
- bsnes: guard more strongly against failure to load games to avoid
crashes
- hiro, ruby: various fixes for macOS [Sintendo]
- hiro/Windows: paint on `WM_ERASEBKGND` to prevent status bar
flickering at startup
- icarus: SPC7110 heuristics fixes [hex_usr]
Errata:
- sfc/ppu-fast: remove debug hires mode7 force disable comment from
PPU::power()
[The `WM_ERASEBKGND` fix was already present in the 106r44 public
beta -Ed.]
byuu says (in the public announcement):
I'm releasing a beta version of bsnes, for the purpose of gathering feedback and
ensuring that the first official release of bsnes is as solid as possible.
With the exception of dynamic rate control for automatic audio/video sync, and
no pack-in video shaders or cheat code database, it is mostly feature complete.
However, please do not form a lasting opinion of bsnes based on this beta.
byuu says:
Changelog:
- hiro/Windows: use `WS_CLIPSIBLINGS` on Label to prevent resize
drawing issues
- bsnes: correct viewport resizing
- bsnes: speed up window resizing a little bit
- bsnes: fix the cheat editor list enable checkbox
- bsnes: fix the state manager filename display in game ROM mode
- bsnes: fix the state manager save/rename/remove functionality in
game ROM mode
- bsnes: correct path searching for IPS and BPS patches in game ROM
mode
- bsnes: patch BS-X town cartridge to disable play limits
- bsnes: do not load (program,data,expansion).(rom,flash) from disk in
game pak mode
- this is required to support soft-patching and ROM hacks
- bsnes: added speed mode selection (50%, 75%, 100%, 150%, 200%);
maintains proper pitch
- bsnes: added icons to the menubar
- this is particularly useful to tell game ROMs from game paks in
the load recent game menu
- bsnes: added emblem at bottom left of status bar to indicate if a
game is verified or not
- verified means it is in the icarus verified game dump database
- the verified diamond is orange; the unverified diamond is blue
- bsnes: added an option (which defaults to off) to warn when loading
unverified games
- working around a bug in GTK, I have to use the uglier
MessageWindow instead of MessageDialog
- bsnes: added (non-functional) link to <https://doc.byuu.org/bsnes/>
to the help menu
- bsnes: added GUI setting to toggle memory auto-save feature
- bsnes: added GUI setting to toggle capturing a backup save state
when closing the emulator
- bsnes: made auto-saving states on exit an option
- bsnes: added an option to auto-load the auto-saved state on load
- basically, the two combined implements auto-resume
- bsnes: when firmware is missing, offer to take the user to the
online help documentation
- bsnes: added fast PPU option to disable the sprite limit
- increase from 32 items/line + 34 tiles/line to 128 items/line +
128 tiles/line
- technically, 1024 tiles/line are possible with 128 sprites at
64-width
- but this is just a waste of cache locality and worst-case
performance; it'll never happen
Errata:
- hiro/Windows: fallthrough on Canvas `WM_ERASEBKGND` to prevent
startup flicker
byuu says:
Changelog:
- bsnes: added video settings panel
- bsnes: added audio settings panel
- bsnes: disable assign/clear buttons at startup for hotkeys panel
- bsnes: program initialization restructured: drivers initialize last
- this lets me reinitialize the settings panel values on driver
changes
- so eg things like input/hotkey remappings should work after
input driver changes now
- ... but I had to disable the window icon for this ... it takes
too long to show up this way
- bsnes: added synchronize video/audio options to settings menu
- bsnes: added audio skew slider for video/audio synchronization
- bsnes: state manager edit/remove works on game ROM .bsz archives now
- bsnes: removed View→Color Emulation; default to 150% gamma instead
(it's a touch brighter but similar)
At this point, I'm pretty much ready to make an initial beta release for
wider testing.
Please use this WIP to indicate any must-fix issues before I do so.
byuu says:
Changelog:
- emulator: added `Thread::setHandle(cothread_t)`
- icarus: added special heuristics support for the Tengai Maykou Zero
fan translation
- board identifier is: EXSPC7110-RAM-EPSONRTC (match on SPC7110 +
ROM size=56mbit)
- board ROM contents are: 8mbit program, 40mbit data, 8mbit
expansion (sizes are fixed)
- bsnes: show messages on game load, unload, and reset
- bsnes: added support for BS Memory and Sufami Turbo games
- bsnes: added support for region selection (Auto [default], NTSC,
PAL)
- bsnes: correct presentation window size from 223/239 to 224/240
- bsnes: add SA-1 internal RAM on cartridges with BS Memory slot
- bsnes: fixed recovery state to store inside .bsz archive
- bsnes: added support for custom manifests in both game pak and game
ROM modes
- bsnes: added icarus game database support (manifest → database →
heuristics)
- bsnes: added flexible SuperFX overclocking
- bsnes: added IPS and BPS soft-patching support to all ROM types
(sfc,smc,gb,gbc,bs,st)
- can load patches inside of ZIP archives (matches first “.ips” or
“.bps” file)
- bsnes/ppu: cache interlace/overscan/vdisp (277 → 291fps with fast
PPU)
- hiro/Windows: faster painting of Label widget on expose
- hiro/Windows: immediately apply LineEdit::setBackgroundColor changes
- hiro/Qt: inherit Window backgroundColor when one is not assigned to
Label
Errata:
- sfc/ppu-fast: remove `renderMode7Hires()` function (the body isn't in
the codebase)
- bsnes: advanced note label should probably use a lighter text color
and/or smaller font size instead of italics
I didn't test the soft-patching at all, as I don't have any patches on
my dev box. If anyone wants to test, that'd be great. The Tengai Makyou
Zero fan translation would be a great test case.
byuu says:
Changelog:
- hiro: added Label::set(Background,Foreground)Color (not implemented
on Cocoa backend)
- hiro: added (Horizontal,Vertical)Layout::setPadding()
- setMargin(m) is now an alias to setPadding({m, m, m, m})
- hiro/Windows: update Label rendering to draw to an offscreen canvas
to prevent flickering
- sfc: reverted back to 224/240-line height (from 223/239-line height
in earlier v106 WIPs)
- bsnes: new multi-segment status bar added
- bsnes: exiting fullscreen mode will resize and recenter window
- this is required; the window geometry gets all scrambled when
toggling fullscreen mode
- bsnes: updated to a new logo [Ange Albertini]
Errata:
- hiro/Windows: try to paint Label backgroundColor quicker to avoid
startup flicker
- `WM_ERASEBKGND` fallthrough to `WM_PAINT` seems to work
- hiro/Qt: use Window backgroundColor for Label when no Label
backgroundColor set
- bsnes: update size multipliers in presentation.cpp to 224/240 (main
window size is off in this WIP)
byuu says:
Changelog:
- hiro: added BrowserDialog::openObject() [match file *or* folder
by filters]
- hiro: BrowserDialog accept button is now disabled when it would
otherwise do nothing
- eg openFile without a folder to enter or file to open selected
- eg saveFile without a file name or with a file name that matches
a folder name
- bsnes: added support for gamepaks (game folders)
- bsnes: store all save states inside per-game .bsz (ZIP) archives
instead of .bst/ folders
- this reduces the number of state files from 10+ to 1; without
having folders sort before files
- hiro: both gtk2 and gtk3 now use cairo to render Canvas; supports
sx,sy [BearOso]
- higan, bsnes: fast PPU/DSP are now run-time options instead of
compile-time options
- bsnes: disable fast PPU when loading Air Strike Patrol / Desert
Fighter
- bsnes: disable fast DSP when loading Koushien 2
- bsnes: added options to advanced panel to disable fast PPU and/or
fast DSP
byuu says:
Changelog:
- ruby/video: implement onUpdate() callback to signal when redraws are
necessary
- ruby/video/GLX,GLX2,XVideo,XShm: implement onUpdate() support
- bsnes: implement Video::onUpdate() support to redraw Viewport icon
as needed
- bsnes: save RAM before ruby driver changes
- sfc/sa1: clip signed multiplication to 32-bit [Jonas Quinn]
- sfc/sa1: handle negative dividends in division [Jonas Quinn]
- hiro/gtk3: a few improvements
- bsnes: added empty stub video and audio settings panels
- bsnes: restructured advanced settings panel
- bsnes: experiment: input/hotkeys name column bolded and colored for
increased visual distinction
- bsnes: added save button to state manager
byuu says:
Changelog:
- hiro: added Qt5 support
- hiro: added GTK3 support (currently runs very poorly)
- bsnes: number of recent games and quick state slots can be changed
programmatically now
- I may expose this as a configuration file setting, but probably
not within the GUI
- nall: use -Wno-everything when compiling with Clang
- sorry, Clang's meaningless warning messages are just endless ...
byuu says:
Changelog:
- bsnes: cheat code “enabled” option changed to “enable”
- bsnes: connected “Cancel” action on add/edit cheat code window
- hiro: improved BrowserDialog::selectFolder() behavior
- can choose “Select” inside of a target folder when no items are
selected
- bsnes: implemented state manager
- bsnes: save a recovery state before loading a state, quitting, or
changing drivers
- bsnes: input settings, hotkey settings, cheat editor, state manager
entries are now batchable
- this allows bulk clearing/deleting of entries
- bsnes: cheat code list now auto-sorts alphabetically instead of
using up/down move arrows
I know most people will probably prefer to order cheat codes the way
they want, but the issue is that the state manager can't really work
this way. Each state is a file on disk. So yes, we could store a
states-manifest.bml to track the order of the states, or try to insert
numbers into the filenames and do bulk filesystem rename operations on
sorting, but then we would run into oddities when users delete state
files manually. And really, manual sorting is just clumsy. If you really
want a specific ordering, you can prefix cheats/states with numeric
indices instead.
byuu says:
Changelog:
- nall: renamed array to adaptive_array; marked it as deprecated
- nall: created new array class; which is properly static (ala
std::array) with optional bounds-checking
- sfc/ppu-fast: converted unmanaged arrays to use nall/array (no speed
penalty)
- bsnes: rewrote the cheat code editor to a new design
- nall: string class can stringify pointer types directly now, so
pointer() was removed
- nall: added array_view and pointer types (still unsure if/how I'll
use pointer)
byuu says:
Changelog:
- sfc/ppu-fast: fixed overscan crash
- sfc/ppu-fast: fixed direct color mode
- sfc: reconnected MSU1 support
- higan: game.sfc/msu1/data.rom, game.sfc/msu1/track-#.pcm
- bsnes: game.msu, game-#.pcm
- bsnes: added cheat code editor
- bsnes: added cheat code database support
- sfc/ppu-fast: clear overscan lines when overscan disabled
- sfc: output 223/239 lines instead of 224/240 lines
- bsnes: fix aspect correction calculation
- bsnes: crop line 224 when overscan masking is enabled
- bsnes: exposed Expansion Port menu; but hid “21fx” from the list of
devices
- bsnes: tools menu is hidden until a game is loaded
- ruby/input/keyboard/quartz: fixed compilation error
So only bsnes the automated overscan cropping option. In higan, you can
crop however many lines you like from the top or bottom of the image.
But for bsnes, it automatically eats sixteen lines. My view right now is
that if bsnes is meant to be the casual gaming emulator, that it should
eat line 224 in this mode. Most games show content here, but because of
the way the SNES PPU works, the very last line ends up on its very own
tile row (line 0 isn't rendered), if the scroll registers don't account
for it. There's a small number of games that will draw junk data to the
very last scanline of the frame as a result of this. So I chose, at
least for now, to hide it. Users can obviously disable overscan cropping
to see this scanline. I'm open to being convinced not to do this, if
someone has a compelling reason.
We're pretty much screwed one way or the other with no overscan masking.
If we output 239 lines, then most games will render 7 blank lines + 224
drawn lines + 8 blank lines, and the black top and bottom aren't
centered. But if we output 240 lines to get 8 + 224 + 8, then games that
do use overscan will have a blank line at the very bottom of the window.
I'm also trying out a modified cheat code file format. It's been forever
since I bothered to look at it, and the “cartridge” parent node doesn't
match what I'm doing with trying to rename “cartridge” to “game” in
manifests. And indeed, the idea of requiring a root node is rather
superfluous for a cheat code file. Current format looks like this:
cheat
description: foo
code: 7e2000=20+7e2001=30?40
enabled
cheat
description: bar
code: 7e4000=80
Open to discussing this, and I'd like to sync up with Snes9X before they
push out a new release, and I'll agree to finalize and never change this
format again.
I chose to use .cht for the extension when using game files (eg
gamename.cht)
Also, since byuu changes the defaults according to what he's working on, let's
be explicit tat higan gets the accuracy core and bsnes gets the performance
core.
byuu says:
Changelog:
- sfc/ppu-fast:
- don't use mosaicSize unless mosaicEnable is set
- fix background tiles that aren't 8x8 in size
- flush (render) queued lines whenever VRAM or OAM are modified
mid-frame
- queue tile outputs to buffer for object rendering final pass
- fix object window mask indexing
- disable color bleed when output width is 256 pixels
- handle reset(bool) events
- implemented save states
- icarus: fixed SPC7110-RAM-EPSONRTC mapping typo [hex_usr]
- bsnes: fixed overscan masking mode when output height is 240
Todo:
- sfc/ppu-fast: should not have deleted the tilecache freeing in
~PPU()
- ruby/input/carbon: change setPath() call to setPathID()
Errata:
- Rendering Ranger R2 crashes at startup, seems to be an issue with
the expansion port device
Bug reports on the new fast SNES PPU are now welcome.
byuu says:
Changelog:
- nall/GNUmakefile: added `openmp=(true,false)` option; can be toggled
when building higan/bsnes
- defaults to disabled on macOS, because Xcode doesn't stupidly
doesn't ship with support for it
- higan/GNUmakefile: forgot to switch target,profile back from
bsnes,fast to higan,accurate
- this is just gonna happen from time to time, sorry
- sfc/dsp: when using the fast profile, the DSP syncs per sample
instead of per clock
- should only negatively impact Koushien 2, but is a fairly
significant speedup otherwise
- sfc/ppc,ppu-fast: optimized the code a bit (ppu 130fps to 133fps)
- sfc/ppu-fast: basic vertical mosaic support (not accurate, but
should look okay hopefully)
- sfc/ppu-fast: added missing mode7 hflip support
- sfc/ppu-fast: added support to render at 256-width and/or 240-height
- gives a decent speed boost, and also allows all of the older
quark shaders to work nicely again
- it does violate the contract of Emulator::Interface, but oh
well, it works fine in the bsnes GUI
- sfc/ppu-fast: use cached CGRAM values for mode7 and sprites
- sfc/ppu-fast: use global range/time over flags in object rendering
- may not actually work as we intended since it's a race condition
even if it's only ORing the flags
- really don't want to have to make those variables atomic if I
don't have to
- sfc/ppu-fast: should fully support interlace and overscan modes now
- hiro/cocoa: updated macOS Gatekeeper disable support to work on
10.13+
- ruby: forgot to fix macOS input driver, sorry
- nall/GNUmakefile: if uname is present, then just default to rm
instead of del (fixes Msys)
Note: blur emulation option will break pretty badly in 256x240 output
mode. I'll fix it later.
byuu says:
Changelog:
- sfc/ppu-fast: everything other than vertical mosaic and interlace
support is in
Games are quite playable now, and you're welcome to try things out, but
please don't report bugs yet. It's still too early for that.
byuu says:
Changelog:
- sfc/ppu-fast: added a barebones background renderer; very incomplete
Right now, the 2bpp Mega Man X2 splash screen is rendering correctly,
but everything else looks really garbled. I'm thinking my tile cache
conversions from 4bpp to bitmap pixels is wrong, but I'm not seeing any
obvious issues.
If anyone wants to take a look at it, I'd appreciate it. The renderer is
mostly modeled after ppu-performance's.
byuu says:
Changelog:
- nall/GNUmakefile: fixed findstring parameter arguments [Screwtape]
- nall/Windows: always include -mthreads -lpthread for all
applications
- nall/memory: code restructuring
I really wanted to work on the new PPU today, but I thought I'd spend a
few minutes making some minor improvements to nall::memory, that was
five and a half hours ago. Now I have a 67KiB diff of changes. Sigh.
byuu says:
Changelog:
- sfc/ppu: collapsed folders to a single directory to match all other
emulated processors
- sfc/ppu-fast: implemented I/O registers
byuu says:
Changelog:
- SNES: started on skeleton of the new parallel PPU core
To build the new PPU core, set profile=fast via GNU make. The old core
is profile=accurate.
The names of the profiles, and the name of the folder for the fast PPU
are subject to change.
The new PPU core doesn't do anything but demonstrate the proof of
concept: every scanline, make a copy of all the PPU registers and CGRAM.
Share the VRAM and OAM. Batch render all scanlines at once using OpenMP
at the end of each frame and blit the result.
With no PPU core at all, bsnes runs 91% faster than with the accuracy
PPU (230fps vs 120fps.) That's the absolute theoretical best-case
scenario. With the skeleton in place, we're already around 220fps. It'll
go down more as the PPU line renderer starts to do real work. I don't
know where things will end up yet. I suppose we'll find out in time.
My own copy of TDM/GCC can't use OpenMP on Windows, so ... it won't
parallelize if you build with that. I'm going to have to switch to a
different MinGW distribution once this is complete, I suppose.
byuu says:
Changelog:
- nall: merged Path::config() and Path::local() to Path::userData()
- ~/.local/share or %appdata or ~/Library/ApplicationSupport
- higan, bsnes: render main window icon onto viewport instead of
canvas
- should hopefully fix a brief flickering glitch that appears on
Windows
- icarus: improved Super Famicom heuristics for Starfox / Starwing RAM
- ruby/Direct3D: handle viewport size changes in lock() instead of
output()
- fixes icon disappearing when resizing main window
- hiro/Windows: remove WS_DISABLED from StatusBar to fix window
resize grip
- this is experimental: I initially used WS_DISABLED to work
around a focus bug
- yet trying things now, said bug seems(?) to have gone away at
some point ...
- bsnes: added advanced settings panel with real-time driver change
support
I'd like feedback on the real-time driver change, for possible
consideration into adding this to higan as well.
Some drivers just crash, it's a fact of life. The ASIO driver in
particular likes to crash inside the driver itself, without any error
messages ever returned to try and catch.
When you try to change a driver with a game loaded, it gives you a scary
warning, asking if you want to proceed.
When you change a driver, it sets a crash flag, and if the driver
crashes while initializing, then restarting bsnes will disable the
errant driver. If it fails in a recoverable way, then it sets the driver
to “None” and warns you that the driver cannot be used.
What I'm thinking of further adding is to call emulator→save() to
write out the save RAM contents beforehand (although the periodic
auto-saving RAM will handle this anyway when it's enabled), and possibly
it might be wise to capture an emulator save state, although those can't
be taken without advancing the emulator to the next frame, so that might
not be a good idea.
I'm also thinking we should show some kind of message somewhere when a
driver is set to “None”. The status bar can be hidden, so perhaps on the
title bar? Or maybe just a warning on startup that a driver is set to
“None”.
byuu says:
Changelog:
- nall: added -static-libgcc -static-libstdc++ to Windows/GCC link
flags
- bsnes, higan: added program icons to main window when game isn't
loaded
- bsnes: improved recent games menu sorting
- bsnes: fixed multi-game recent game loading on Windows
- bsnes: completed path override support
- bsnes, higan: added screensaver suppression on Windows
- icarus: add 32K volatile RAM to SuperFX boards that report no RAM
(fixes Starfox)
- bsnes, higan: added automatic dependency generation [Talarubi]
- hiro/GTK: appending actions to menus restores enabled() state
- higan: use board node inside manifest.bml if it exists
- bsnes: added blur emulation and color emulation options to view menu
- ruby: upgraded input.sdl to SDL 2.0 (though it makes no functional
difference sadly)
- ruby: removed video.sdl (due to deprecating SDL 1.2)
- nall, ruby: improvements to HID class (generic vendor and product
IDs)
Errata:
- bsnes, higan: on Windows, Application::Windows::onScreenSaver needs
`[&]` lambda capture, not `[]`
- find it in presentation/presentation.cpp
byuu says:
Changelog:
- bsnes:
- added full input mapping support (multi-mapping, digital+analog
inputs, rumble, hotkeys, etc)
- can now load multi-part games (eg Super Game Boy) from the
command-line
- added recent games menu with list clear function; supports
multi-part games (sorting logic incomplete)
- added automatic binding of gamepads on new configuration files
- added view scaling support with aspect correction, overscan
cropping, and integral scaling modes
- added video shader support
- added status bar (can be hidden)
- added save states (both menu and hotkeys)
- added fullscreen mode support
- added support for loading compressed (ZIP) archives for any
supported media type (SNES, GB, etc)
- added frame counter
- added auto-memory saving
- added pause / block-input modes when main window loses focus
- added --fullscreen command-line option to start bsnes in
fullscreen mode
- added input settings panel
- added hotkeys settings panel
- added path settings panel (paths aren't actually used set, but
can be assigned)
- higan: fixed macOS install rule [Sintendo]
- higan: minor UI code cleanups
- nall: renamed Processor to Architecture to fix macOS builds
[Sintendo]
Yeah, you read right: recent games menu, path settings. And dynamic rate
control + screensaver suppression is on the todo list. I'm not fucking
around this time. I really want to make something special here.
byuu says:
Changelog:
* yes.
But seriously, a list of changes on a pre-alpha GUI is going to get annoying.
Basically, work on embedding stuff in the binary, firmware loading (both
appended to the ROM and in a firmware/ subfolder) added, SGB games can be
loaded, config file holds more values for driver settings, added ruby drivers to
other platforms, etc.
byuu says:
Changelog:
- bsnes: work on the new GUI; can load games now, but no input support
yet
- icarus: heuristics game/label uses filename instead of internal
header name
byuu says:
Changelog:
- created new bsnes target (it currently does nothing)
- Super Famicom: fixed BS Memory pack support in the MCC emulation
- icarus: fixed manifest-free support for BS Memory flash-based
cartridges
- icarus: database improvements
byuu says:
Changelog:
- higan: target-tomoko has been renamed to target-higan
- Super Famicom: event has been renamed to
processor(architecture=uPD78214)
- Super Famicom: SNES-EVENT supported once more; under board IDs
EVENT-CC92 and EVENT-PF94
- Super Famicom: SNES-EVENT preliminarily set up to use DIP switch
settings ala the Nintendo Super System (incomplete)
- Super Famicom: MCC PSRAM moved inside the MCU, as it is remappable
- Super Famicom: MCC emulation rewritten from scratch; it is now
vastly more accurate than before
- Super Famicom: added BSC-1A5B9P-01 board definition to database;
corrected BS-MCC-RAM board definition
- Super Famicom: moved SHVC-LN3B-01 RAM outside of
processor(identifier=SDD1)
- higan: when selecting a default game to load for a new system entry,
it will change the system option to match the media type
- higan: the load text box on the system entry window is now editable;
can be used to erase entries
- icarus: fixed bug in Famicom importing
- icarus: importing unappended SNES coprocessor firmware will now
rename the firmware properly
- hiro/GTK,Qt: WM_CLASS is now set correctly in `argv[0]`, so
applications should show “higan”, “icarus” instead of “hiro” now
Note: if you wish to run the BS-X town cartridge, the database currently
lists the download RAM as type “PSRAM”. This needs to be changed to
“RAM” in order to load properly. Otherwise, the emulator will bomb
out on the load window, because BSC-1A5B9P-01 expects PSRAM to always be
present, but it won't find it with the wrong memory type. I'll correct
this in the database in a later release. For now, you can copy the game
portion of the manifest to a new manifest.bml file and drop it into the
gamepak folder until I fix the database.
byuu says:
Changelog:
- Super Famicom: fixed loading of BS Memory and Sufami Turbo
cartridges
- Super Famicom: renamed NSS to DIP; as that's really all it is, it's
not true NSS emulation
- Super Famicom: slot loading now happens inside of board parsing
instead of generically in loadCartridge()
- Super Famicom: BS-X cartridges with flash memory now serialize their
data and write it out to disk¹
- icarus: fixed Famicom game importing (hopefully) and set file import
title to “Load ROM File”
¹: there's no emulation of write commands yet, so the data is never
going to change anyway. This is just in preparation for more advanced
emulation of BS Memory cartridges.
byuu says:
Changelog:
- Super Famicom: everything outside of Nintendo Super System, Campus
Challenge '92 and Powerfest '94 should play
- Super Famicom: removed RAM from coprocessor/event (should use global
RAM)
- Super Famicom: removed RAM from SDD1 (should use global RAM)
- icarus: fixed Super Famicom game importing [hex_usr]
Also worth reminding that you'll need to disable database lookup in
order to run the BS-X Town cartridge right now. Plus, Star Ocean's
database entry still has the RAM in the wrong spot. The MSU1 code is not
looking at the right locations for data, so it's not going to work in
this release either.
I need to figure out what to call coprocessor/event and coprocessor/nss,
as neither are slots or processors like everything else.
Outside of those issues, all games for all systems should be playable,
at least to the extent they were in v106.
byuu says:
Changelog:
- major restructuring of board manifests
- cleanup of generic board names
- Super Famicom: updates to SA1, SuperFX, Cx4, SPC7110, EpsonRTC,
SharpRTC load/save code
- Super Famicom: added experimental SuperFX plot dithering fix
[qwertymodo]
- higan, icarus: rename shared folders to lowercase names; put .sys
folders into new subfolder
- Video Shaders/ → shaders/
- Database/ → database/
- Firmware/ → firmware/
- \*.sys/ → systems/\*.sys/
So right now, only standard SNES games, SA-1, SuperFX, and Cx4 games
load. I have not tested SPC7110 or RTC support, because icarus import
seems to be completely broken? It's creating blank folders when I try it
now. I'll have to fix that ...
Since we are now up to thirteen systems, I've put the .sys folders into
a subfolder. This should declutter the main higan-windows release folder
a good deal. Linux users will need to re-run make install, or manually
move things into a new systems/ subfolder.
Same goes for icarus: lowercase the database/ and firmware/ folders or
re-run make install.
I don't know if qwertymodo's SuperFX fix is exactly correct or not.
Hopefully it is, but I didn't write a test ROM or anything to be
certain. Since SuperFX games should run, if people could please play
through some of them and look for any regressions, that'd be very much
appreciated.
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.
byuu says:
Changelog:
- main menu renamed again (Library→System→Systems)
- the 'Hidden' checkbox on system properties was moved to the main
list as a 'Show' checkbox instead
- the move up/move down buttons on the systems panel now function
- added icons to indicate 'system' versus 'game boot' entries in the
systems list
I still didn't add ComboEdit to the Windows hiro port, so once again
this will be Linux/BSD only.
I polished the browse button for selecting a boot game. It'll use a list
of all bootable media file extensions, so that if you double-click any
supported game, it'll select it instead of going inside the folder. If
you pick a non-bootable folder, like say a Sufami Turbo cartridge, it
will go inside the folder instead, because it will treat it like any
other regular folder.
Having a checkbox next to text in the same cell doesn't work so well on
lists that have an onActivate action. Say you tried to double-click the
“Name” field on the Systems tab, it would toggle the checkbox twice
before popping open the system properties editor window. So because of
this, I made the show checkbox its own column. And for consistency, I
did the same for the slot# on the cheat editor window.
As a bit of really pedantic polish: if there are no systems enabled,
then the main menu won't show the separator before the “Load ROM Image”
option anymore.
I think something is wrong with the Markup::Node::insert syntax, but I
realized I have Markup::Node::swap, and just used that for the up/down
arrows on the systems panel for now. But we should probably fix insert()
at some point ... sigh.
byuu says:
Changelog:
- Super Game Boy: fixed loading of boot ROM
- hiro: added ComboEdit::setEditable(bool = true);
- tomoko: added new systems settings panel
Note!!: this release will not compile on Windows or macOS due to the
missing ComboEdit control! I'll try to merge in hex's implementation
for the Windows release here soon. macOS users will probably be out of
luck for a while, sorry.
The new systems panel is an idea I've been meaning to implement for
quite a while, but finally got around to starting on it. It's still
fairly unpolished, but the basic idea is there for Linux/BSD users to
try out now.
So imagine the Super Game Boy, BS-X Satellaview, Sufami Turbo, and the
associated BS Memory Pack-slotted SNES cartridges. To play any of those,
you needed to choose Nintendo→Super Famicom, and then select the
relevant cartridge, and then select any slotted cartridges to play with
it.
This was acceptable-ish, if not ideal. But now imagine in the future if
we wanted to support the Famicom Disk System, which is technically a
cartridge that plugs into the Famicom deck. Or the PC Engine CD, which
has one of three special HuCards that must be inserted (ignoring the
Turbo Duo where it's built-in—I'm going to be emulating the Super CD
as if you're using a stock PCE CD.) Or the Mega CD, where there are
probably a half dozen or more BIOS + hardware revisions that are
region-specific, which connect to an expansion port that is identical to
the cartridge port save for the Mega Drive seeing an I/O register bit
toggled here.
In all of these cases, it's going to be a real pain to have to choose
the 'BIOS' every time you want to play a game for them.
I can't distribute these BIOSes with higan due to copyright
restrictions, and trying to ship dummy folders for every possible
combination would become quite odious, and difficult for people to use
(compare to setting up the Game Boy Advance system BIOS.)
And so I've created the new systems settings panel. Here, you can manage
a list of systems that show up under the higan library menu (now renamed
to “System”), where each entry contains name, boot, and hidden
parameters.
The name parameter is what shows up in the system menu. You can call any
system higan emulates whatever you like here. Don't like “Super
Famicom”? Change it to “SNES”, then.
The boot parameter is a combo edit with a dropdown for all of the
systems higan emulates. If you choose one of these, then the higan
system menu option will work exactly like in previous releases, and
prompt you for a cartridge. But if you choose the browse button next to
the combo edit control, you'll get to pick any gamepak from the higan
library of your choosing.
So you could choose the SGB2 BIOS, and name the menu option “Super Game
Boy 2”, and when you choose the menu option, it will load the SFC core,
load the SGB2 BIOS, and only prompt you for the Game Boy game you wish
to play on it. The same deal goes for the FDS, PCE-CD, Mega CD, Mega
Drive Sonic & Knuckles lock-on cartridge, BS-X Satellaview, SD Gundam
G-Next, etc. Whatever you want to be in the menu, you can put in there
by pointing higan at the appropriate 'BIOS' gamepak to load.
Astute readers have probably already noticed, but you can technically
use this on non-slotted games as well, thus creating instant boot
options for your absolute favorite games, if you so wanted. Point it at
Zelda 3, and you can boot it instantly from the main menu, without any
need for file selection.
The hidden option is a way to hide the system entries from the system
menu. Primarily this would be a fast way for users to disable emulation
cores they never use in higan, without having to remove the options.
The major concession with this change is the collapsing of the
per-manufacturer submenus. What this means is you will now have all
twelve higan emulated systems in the main menu by default. This makes
the list rather long, but ... oh well. I may try to offer some form of
grouping in the future, but the grouping defeats the “list order =
display order” design, and I'm not willing to auto-sort the list. I want
people to be able to control the ordering of the system menu, and have
added (as yet non-functional) sorting arrows for that purpose. I also
don't have a combined tree+table view widget in higan to try to and
group things. But ... we'll see how things go in the future.
Another idea is to add a specialty load option that opens up the user's
Emulation library path, and lets you pick a gamepak for any system,
which would boot the same way as when you drop a gamepak onto the higan
executable or main window. So say you almost never play Wonderswan
games, this would be a way to play them without them cluttering your
system menu list.
The “import ROM files” option has been removed. All it does is launch
icarus directly. I would rather users become familiar with using icarus.
The “load ROM file” option remains.
Anyway, this is all still a work in progress, so please give it time and
don't overload me with too many suggested changes right now, thanks :3
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.
byuu says:
Changelog:
- game/memory/category → game/memory/content
- game/memory/model → game/memory/architecture
- game/memory/identity → game/memory/identifier
- Super Famicom: memory/content=Bitmap → memory/content=Save
- Super Famicom: memory/architecture=DMG,MGB →
memory/architecture=LR35902
The game manifest field names are now officially set in stone. I won't
change them again, I'll only add new fields if required.
As for the values in the field, I'm still undecided on the manufacturer
of the ST018, and I could be talked into different identifiers for the
Super Game Boy (SGB1/SGB2, DMG/MGB, or just ICD(2)?)
The board manifest format is still in flux, as is the choice of what to
name firmware files (it's between manufacturer and architecture, where
I'm leaning toward the latter currently.)
Board memory to Game memory mappings will require both the manufacturer
and architecture fields to match.
I'll be updating doc.byuu.org soon with the finalized game manifest
format.
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
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.
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.
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.
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
byuu says:
Changelog:
- icarus: new Firmware/ folder, which is used to import external
firmware when it's missing from the ROM image
- icarus: improved Super Famicom heuristics; including Shift-JIS to
UTF-8 encoding of game titles
Errata:
- if firmware isn't appended, it still cuts out the size from the
memory/program.rom file
- boards.bml is still missing the new Japanese production boards
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.
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.
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.
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.
byuu says:
Changelog:
- Z80: infinite DD/FD prefixes will no longer cause an emulator crash;
but will still deadlock savestates
- Z80: emulated R incrementing on M1 cycles
- Z80: `LD a, [ir]` should update flags [hex_usr]
- Z80: minor code cleanups
- tomoko: added “Pause Emulation” toggle to Tools menu
- you can still use the hotkey to pause emulation before starting
a game if you really want to
- this will be useful if and when I re-add trace logging to
capture instructions from power-on
- icarus: more PAL games added to the SNES database
I hope I've implemented R correctly. It should only increment twice on
DD,FD CB xx instructions. LDI/LDD/LDIR/LDDR should work as expected as
well. It increments once when interrupts are executed (and not maksed.)
The top bit is ignored in increments.
byuu says:
Changelog (since v105tr1):
Changelog:
- added Emulation/AutoSaveMemory/Interval setting to specify number of
seconds between auto-saves
- added Game Notes tool
- added 64 new SNES PAL games to the icarus preservation database
The Games Notes tool is a new feature that gives you a blank text box to
enter notes about a game that you're playing: so you can write down
things like level select codes for games with save RAM, combo moves, or
whatever other information you'd like quick and easy access to.
This is kind of an experiment. Ideally, we'd wanna allow more
personalized information, drawings, etc. But hey, let's try it out and
see what people think.
It seems on Windows, `compiler` has defaulted to `g++` for a while now,
so we didn't need to override it in the `make` invocation.
Since v105r01, `compiler` defaults to `g++` on Linux too, so we don't
need to override it there either.
By default, mkdocs uses "highlight.js" to apply syntax-highlighting
to code blocks. Left to its own devices, highlight.js will guess the
language being used in the code block, apply the "hljs" CSS class
(so the code block will be given a nice border, a sensible font-size,
etc.) and apply the appropriate formatting markup. If it guesses wrongly,
you can give a language hint on the opening line of the block.
If you use a language that highlight.js does not recognise, or
the special name "nohighlight", highlight.js will leave the block
alone. Unfortunately, in mkdocs' default theme, that means it will be
formatted like *inline* code, with a border and background that wraps
behind each line of the block.
In order to make a code-block that looks like a code-block, you have
to carefully pick a language that highlight.js has heard of, but whose
syntax is sufficiently different from whatever's in the block that no
unwanted highlighting will occur.
This seems to be fixed in the readthedocs theme that comes with mkdocs
0.16.1, but ReadTheDocs doesn't actually seem to be using that version. :/
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.
Added LICENSE.txt and GPLv3.txt. Also updated libco documentation.
After discussion with byuu, libco gets a more specific ISC license
to match nall, ruby and hiro. higan, as clarified in LICENSE.txt,
continues to be GPL version 3 only (no "or later" clause).
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).
git requires a name and email to be configured before it can commit a change. We're not going to push the merge result anywhere, so we don't strictly speaking need it to commit.
byuu says:
This release provides several major improvements to Mega Drive emulation
which enhances compatibility a good deal. It also includes important
Super Famicom mosaic emulation improvements, plus a much-needed SuperFX
save state issue fix.
Changelog (since v104):
- higan: many improvements to Emulator::Interface to support
forks/frontends
- higan: refreshed program icon
- icarus: new program icon
- Game Boy Advance: slight emulation speedup over v104
- Game Boy Advance: synchronize APU FIFO updates better
- Mega Drive: added automatic region detection [hex_usr]
- Mega Drive: support 8-bit SRAM
- Game Boy Advance: fixed bug when changing to THUMB mode via MSR
[MerryMage]
- Master System: fix bug in backdrop color and background 0 priority
[hex_usr]
- Mega Drive: backgrounds always update output priority bit [Cydrak]
- Mega Drive: emulated interlaced video output
- Mega Drive: emulated shadow/highlight mode [Cydrak]
- Super Famicom: auto joypad polling clears the shift register when
starting
- Super Famicom: added new low-entropy RAM initialization mode to more
closely match hardware
- Game Boy Advance: rumble will now time out after being left on for
500ms
- ruby: improved rumble support in udev input driver [ma_rysia]
- M68K: `move.b (a7)[+/-]` adjust a7 by two
- M68K: illegal/lineA/lineF opcodes do not modify the stack register
- Mega Drive: emulate VIP status bit
- uPD7725: improved emulation of OV1/S1 flags [byuu, AWJ, Lord
Nightmare]
- uPD7725: improved handling of DP, RP updates [Jonas Quinn]
- Super Famicom: improved emulation of mosaic effects in hires,
interlace, and offset-per-tile modes [byuu, Cydrak]
- ruby: improved Direct3D exclusive mode monitor selection [Cydrak]
- Super Famicom: fixed save state bug affecting SuperFX games
[Cydrak]
- Mega Drive: added workaround for Clang compiler bug; allowing this
core to work on macOS [Cydrak, Sintendo]
- higan: hotkeys now also trigger when the main window lacks focus yet
higan is set to allow input on focus loss
- higan: fixed an edge case where `int16_t` ↔ `double` audio
conversion could possibly result in overflows
- higan: fixed a crash on macOS when choosing quit from the
application menu [ncbncb]
Changelog (since the previous WIP):
- higan: restored `make console=true`
- tomoko: if you allow input when main window focus is lost, hotkeys
can now be triggered without focus as well
- hiro/cocoa: fix crash on exit from menu [ncbncb]
- ruby: smarter `double` → `int16_t` conversion to prevent
underflow/overflow
byuu says:
Changelog:
- processor/m68k: fix error in disassembler [Sintendo]
- processor/m68k: work around Clang compiler bug [Cydrak, Sintendo]
This is one of the shortest WIPs I've done, but I'm trying not to change
anything before v105.
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
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.
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
byuu says:
Changelog:
- nall/GNUmakefile: build=release changed to -O2, build=optimize is
now -O3
- hiro: added Monitor::dpi(uint index) → Position [returns logical
DPI for x, y]
- Position is a bad name, but dpi(monitor).(x,y)() make more sense
than .(width,height)()
- hiro: Position, Size, Geometry, Font changed from using signed int
to float
- hiro: Alignment changed from using double to float
- hiro: added skeleton (unused) Application::scale(), setScale()
functions
Errata:
- hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues
with macOS' automatic scaling.
- hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI
scaling
- hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this,
but I still use Qt 4.x)
- and just to get global DPI, hiro/qt's DPI retrieval has to use
undocumented functions ... fun
The goal with this WIP was basically to prepare hiro for potential
automatic scaling. It'll be extremely difficult, but I'm convinced that
it must be possible if macOS can do it.
By moving from signed integers to floats for coordinates, we can now
scale and unscale without losing precision. That of course isn't the
hard part, though. The hard part is where and how to do the scaling. In
the ideal application, hiro/core and hiro/extension will handle 100% of
this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware
of what's going on, but ... to even make that possible, things will need
to change in every per-platform core, eg the per-platform code will have
to call a core function to change geometry, which will know about the
scaling and unscale the values back down again.
Gonna be a lot of work, but ... it's a start.
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.
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.
byuu says:
Changelog:
- processor/upd96050: per manual errata note, SGN always uses SA1;
never SB1 [fixes v104r09 regression]
- processor/upd96050: new OV1/S1 calculation that doesn't require OV0
history buffer [AWJ]
- processor/upd96050: do not update DP in OP if DST=4 [Jonas Quinn]
- processor/upd96050: do not update RP in OP if DST=5 [Jonas Quinn]
- resource: recreated higan+icarus icons, higan logo as 32-bit PNGs
So higan v104r08 and earlier were 930KiB for the source tarball. After
creating new higan and icarus icons, the size jumped to 1090KiB, which
was insane for only adding one additional icon.
After digging into why, I discovered that ImageMagick defaults to
64-bit!! (16-bits per channel) PNG images when converting from SVG.
You know, for all those 16-bit per channel monitors that don't exist.
Sigh. Amazingly, nobody ever noticed this.
The logo went from 78.8KiB to 24.5KiB, which in turn also means the
generated resource.cpp shrank dramatically.
The old higan icon was 32-bit PNG, because it was created before I
installed FreeBSD and switched to ImageMagick. But the new higan icon,
plus the new icarus icon, were both 64-bit as well. And they're now
32-bit.
So the new tarball size, thanks to the logo optimization, dropped to
830KiB.
Cydrak had some really interesting results in converting higan's
resources to 8-bit palletized PNGs with the tRNS extension for alpha
transparency. It reduces the file sizes even more without much visual
fidelity loss. Eg the higan logo uses 778 colors currently, and 256
represents nearly all of it very well to the human eye. It's based off
of only two colors, the rest are all anti-aliasing. Unfortunately,
nall/image doesn't support this yet, and I didn't want to flatten the
higan logo to not have transparency, in case I ever want to change the
about screen background color.
byuu says:
Changelog:
- processor/upd96050: SGN should select between (A,B).S1 flag using
ASL opcode bit
- processor/upd96050: use a temporary to cache new S1, then compute
OV1 using old S1, then assign new S1
- processor/upd96050: add SR.(siack,soack) and connect to relevant
jump instructions (serial not implemented)
- processor/upd96050: initialize SR properly in power() [r08
regression]
- icarus: improve Makefile rules [Screwtape]
- higan: new program icon
- icarus: new program icon
I've generally tried to keep to en_AU spellings rather than en_US spellings
for the sake of my own sanity, but it's difficult when documenting a program
that exclusively uses en_US spellings since I'm quoting the text on
menu-items and in config files.
Strictly speaking, there's no dependency between them, but higan's
install target happens to create the destination bin directory if it
doesn't already exist, so we want to run that install script first.
Sufami Turbo games are in a separate set now, they don't have the "(ST)"
marker in the filename.
Satellaview memory paks may have "(BS)", "(BS SoundLink)" or "(BSROM)"
for various reasons that aren't important to higan, so let's just not mention
them at all.
byuu says:
Changelog:
- processor/upd96050: code cleanups
- processor/upd96050: improved emulation of S1/OV1 flags [thanks to
Cydrak, Lord Nightmare]
- tomoko/settings/audio: reduced the size of the frequency/latency
combo boxes to show longer device driver names
Errata: I need to clear regs.sr in uPD96050::power()
Note: the S1/OV1 emulation is likely not 100% correct yet, but it's a
step in the right direction. No SNES games actually use S1/OV1, so this
shouldn't result in any issues, I'd just like to have this part of the
chip emulated correctly.
byuu says:
Changelog:
- md/vdp: added VIP bit to status register; fixes Cliffhanger
- processor/m68k/disassembler: added modes 7 and 8 to LEA address
disassembly
- processor/m68k/disassembler: enhanced ILLEGAL to display LINEA/LINEF
$xxx variants
- processor/m68k: ILLEGAL/LINEA/LINEF do not modify the stack
register; fixes Caeser no Yabou II
- icarus/sfc: request sgb1.boot.rom and sgb2.boot.rom separately; as
they are different
- icarus/sfc: removed support for external firmware when loading ROM
images
The hack to run Mega Drive Ballz 3D isn't in place, as I don't know if
it's correct, and the graphics were corrupted anyway.
The SGB boot ROM change is going to require updating the icarus database
as well. I will add that in when I start dumping more cartridges here
soon.
Finally ... I explained this already, but I'll do so here as well: I
removed icarus' support for loading SNES coprocessor firmware games with
external firmware files (eg dsp1.program.rom + dsp1.data.rom in the same
path as supermariokart.sfc, for example.)
I realize most are going to see this as an antagonizing/stubborn move
given the recent No-Intro discussion, and I won't deny that said thread
is why this came to the forefront of my mind. But on my word, I honestly
believe this was an ineffective solution for many reasons not related to
our disagreements:
1. No-Intro distributes SNES coprocessor firmware as a merged file, eg
"DSP1 (World).zip/DSP1 (World).bin" -- icarus can't possibly know
about every ROM distribution set's naming conventions for firmware.
(Right now, it appears GoodSNES and NSRT are mostly dead; but there
may be more DATs in the future -- including my own.)
2. Even if the user obtains the firmware and tries to rename it, it
won't work: icarus parses manifests generated by the heuristics
module and sees two ROM files: dsp1.program.rom and dsp1.data.rom.
icarus cannot identify a file named dsp1.rom as containing both
of these sub-files. Users are going to have to know how to split
files, which there is no way to do on stock Windows. Merging files,
however, can be done via `copy /b supermariokart.sfc+dsp1.rom
supermariokartdsp.sfc`; - and dsp1.rom can be named whatever now.
I am not saying this will be easy for the average user, but it's
easier than splitting files.
3. Separate firmware breaks icarus' database lookup. If you have
pilotwings.sfc but without firmware, icarus will not find a match
for it in the database lookup phase. It will then fall back on
heuristics. The heuristics will pick DSP1B for compatibility with
Ballz 3D which requires it. And so it will try to pull in the
wrong firmware, and the game's intro will not work correctly.
Furthermore, the database information will be unavailable, resulting
in inaccurate mirroring.
So for these reasons, I have removed said support. You must now load
SNES coprocessor games into higan in one of two ways: 1) game paks with
split files; or 2) SFC images with merged firmware.
If and when No-Intro deploys a method I can actually use, I give you all
my word I will give it a fair shot and if it's reasonable, I'll support
it in icarus.
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.
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.
I made a change to ruby/input/joypad/udev.cpp while diagnosing a problem
with higan's rumble behaviour on Linux, and accidentally committed it
in 15b3dc8b0b as part of a documentation
change.
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.
The file was originally named `higan-config.md` because the dialog box
it described was called "higan Configuration", which was because the
menu-item to open it was in a menu called "Settings" and it would have
been weird to have a "Settings" item in a "Settings" menu.
Now there are individual menu-items for each tab in the Settings dialog,
none of which are named Settings, so the dialog has been renamed back to
"Settings", and the filename should match.
For Windows documentation, "folder" is the correct term. For generic
documentation, probably either would do but I suspect people are
slightly more likely to be familiar with "folder".
byuu says:
Changelog:
- md/vdp: added full interlace emulation [byuu, Sik, Eke, Mask of
Destiny]
- md/vdp: fix an issue with overscan/highlight when setting was
disabled [hex\_usr]
- md/vdp: serialize field, and all oam/objects state
- icarus/md: do not enable RAM unless header 0x1b0-1b1 == "RA"
[hex\_usr]
I really can't believe how difficult the interlace support was to add. I
must have tried a hundred combinations of adjusting Y, Vscroll, tile
addressing, heights, etc. Many of the changes were a wash that improved
some things, regressed others.
In the end I ended up needing input from three different people to
implement what should have been trivial. I don't know if the Mega Drive
is just that weird, if I've declined that much in skill since the days
when I implemented SNES interlace, or if I've just never been that good.
But either way, I'm disappointed in myself for not being able to figure
either this or shadow/highlight out on my own. Yet I'm extremely
grateful to my friends for helping carry me when I get stuck.
Since it wasn't ever documented before, I'm going to try and document
the changes necessary to implement interlace mode for any future
emudevs.
Also, some of the text in the higan and icarus settings docs wanted to
link to a discussion of why we ignore manifests by default; now we have
such a thing.
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.
Also, moved the "you should install the GBA BIOS" advice from the
install pages (where I doubt anybody would see it) to the "importing and
playing" guide, which I figure people are more likely to stumble across.
The actually instructions are still in `install/general.md` for lack of
anywhere more appropriate.
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.
[As mentioned in the v104 internal release notes, byuu fixed a small typo in
the GBA core. -Ed.]
byuu says:
There are lots of improvements in this new release, both to core
emulation and to the user interface. However, some of these changes are
quite substantial, so regressions are a possibility. Please report any
regressions from v103 on the forums if found.
Note that Mega Drive save RAM files will not be compatible with v103,
but will now be compatible with save RAM files from all other Mega Drive
emulators, and the format will be stable going forward.
Also!! Thanks to the tireless work of Screwtape, the
Help->Documentation link in higan now takes you to a very comprehensive
user guide. Please be sure to consult this if you have any questions
about using higan.
Lastly, I've added a link to my Patreon page (https://patreon.com/byuu/)
to the higan downloads page. The money will go exclusively toward
purchasing SNES games for preservation, hardware and flash carts for
reverse engineering, equipment such as backup drives, etc. Donating is
entirely optional and comes with no rewards, but would of course be
greatly appreciated! ^^;
Changelog (since v103):
- nall/dsp: improved first-order IIR filtering
- Famicom: improved audio filtering (90hz lowpass + 440hz lowpass +
14khz highpass)
- Game Boy Advance: corrected bug in PSG wave channel emulation
[Cydrak]
- Mega Drive: added first-order 2.84KHz low-pass filter to match VA6
model hardware
- Mega Drive: lowered PSG volume relative to YM2612 to match VA6 model
hardware
- Mega Drive: Hblank flag is not always set during Vblank
- Mega Drive: fix PAL mode reporting from control port reads
- Famicom: improved phase duty cycle emulation (mode 3 is 25% phase
inverted; counter decrements)
- Mega Drive: reset does not cancel 68K bus requests
- Mega Drive: 68K is not granted bus access on Z80 reset
- Mega Drive: CTRL port is now read-write, maintains value across
controller changes
- Z80: IX, IY override mode can now be serialized in save states
- 68K: fixed calculations for ABCD, NBCD, SBCD [hex\_usr,
SuperMikeMan]
- SPC700: improved all cycle timings to match results observed by
Overload with a logic anaylzer
- Super Famicom: SMP uses a separate 4x8-bit buffer for $f4-f7; not
APU RAM [hex\_usr]
- Super Famicom: SMP TEST register is now finally 100% fully emulated
[byuu, AWJ]
- Game Boy Advance: DMA can run between CPU instruction cycles
- Game Boy Advance: added 2-cycle delay between DMA activation and
transfers
- higan: improved aspect ratio correction accuracy at higher video
scaling sizes
- higan: overscan masking will now actually crop the underlying video
instead of just blanking it
- Mega Drive: center video when overscan is disabled
- higan: added increment/decrement quick save slot hotkeys
- Game Boy Advance: fixed wave RAM nibble ordering (fixes audio in
Castlevania, Pocket NES)
- higan: added new adaptive windowed mode: resizes the window to the
current emulated system's size
- higan: added new integral scaling mode: resizes the window to fill
as much of the screen as possible
- higan: main window is now resizable and will automatically scale
contents based on user settings
- higan: fixed one-time blinking of the main window on startup caused
by focus stealing bug
- ruby: fixed major memory leak in Direct3D driver
- ruby: added fullscreen exclusive mode to Direct3D driver
- Super Famicom: corrected latching behavior of BGnHOFS PPU registers
- higan: all windows sans the main viewport can be dismissed with the
escape key now
- ruby: complete API rewrite; many audio drivers now support device
selection
- higan: output frequency can now be modified
- higan: configuration settings split to individual menu options for
faster access to individual pages
- ruby: improved WASAPI driver to event-driven model; more compatible
in exclusive mode now
- libco: fix compilation of sjlj and fiber targets [Screwtape]
- ruby: added YV12 and I420 support to X-Video driver
- Game Boy: added TAMA emulation (RTC emulation is not working yet)
[thanks to endrift for notes]
- Game Boy: correct data ordering of MMM01 ROMs (MMM01 ROMs will need
to be re-imported into higan)
- Game Boy: store MBC2 save RAM as 256-bytes instead of 512-bytes (RAM
is 4-bit; not 8-bit with padding)
- Game Boy: fixed a bug with RAM serialization in games without a
battery
- Mega Drive: fix CRAM reads (fixes Sonic Spinball) [hex\_usr]
- Game Boy: added rumble support to MBC5 games such as Pokemon Pinball
- Game Boy: added MBC7 emulation (accelerometer X-axis, EEPROM not
working yet) [thanks to endrift for notes]
- hiro: macOS compilation fixes and UI improvements [MerryMage,
ncbncb]
- Game Boy: added MBC6 emulation (no phone link or flash support;
timing bugs in game still)
- Game Boy: HDMA syncs to other components after each byte transfer
now
- Game Boy: disabling the LCD completely halts the PPU (fixes onscreen
graphical corruption in some games)
- Mega Drive: added 6-button Fighting Pad emulation [hex\_usr]
- 68K: TAS sets d7 when EA mode is a direct register (fixes Asterix
graphical corruption)
- Game Boy: STAT mode is forced to zero when LCD is disabled (fixes
Pokemon Pinball)
- LR35902: complete rewrite
- icarus: high-DPI is not supported on Windows yet; remove setting for
consistency with higan window sizes
- hiro: added full support for high-DPI displays on macOS [ncbncb]
- ARM7TDMI: complete rewrite
- Super Famicom: disabled channels during HDMA initialization appear
to set DoTransfer flag
- V30MZ: code cleanup
- Mega Drive: added optional TMSS emulation; disabled by default
[hex\_usr]
- ARM7TDMI: pipeline decode stage caches CPSR.T [MerryMage]
- ARM7TDMI: fixed timing of THUMB stack multiple instruction
[Cydrak]
- higan: detect when ruby drivers crash; disable drivers on next
startup to prevent crash loop
- Mega Drive: added automatic region detection (favors NTSC-J >
NTSC-U > PAL) [hex\_usr]
- Mega Drive: support 8-bit SRAM
- ARM7TDMI: PC should be incremented by 2 when setting CPSR.T via MSR
instruction [MerryMage]
- ruby: add Windows ASIO driver support (does not work on some systems
due to buggy vendor drivers)
- higan: default to safe drivers on a new install; due to instability
with some optimal drivers
The existing documentation was getting *way* too long to be a single
document.
I've just bulk moved the existing content into the new structure, but it
definitely needs another pass to make the prose match, fix hyperlinks,
etc. etc.
Also, remove the sections for importing and playing Game Boy and GBA
games... the Game Boy section was just going to be about black cartridges
anyway, and I have no idea what the GBA section was going to be for.
Wrap SHA256 hashes in `<code/>` so they'll all be visually the same length.
Make the references from DSP1 and DSP1B to the notes below more obviously
references, not content.
Reword the DSP1 note so that it makes sense even if you didn't just come
from the DSP1/1A row of the table.
Also, move the higher-level questions about the game library
and game folders to the end of the section,
so people can more easily find the bits about importing types of game.
byuu says:
Changelog:
- emulator/interface: removed unused Region struct
- gba/cpu: optimized CPU::step() as much as I could for a slight
speedup¹
- gba/cpu: synchronize the APU better during FIFO updates
- higan/md, icarus: add automatic region detection; make it the
default option [hex\_usr]
- picks NTSC-J if there's more than one match ... eventually, this
will be a setting
- higan/md, icarus: support all three combinations of SRAM (8-bit low,
8-bit high, 16-bit)
- processor/arm7tdmi: fix bug when changing to THUMB mode via MSR
[MerryMage]
- tomoko: redesigned crash detector to only occur once for all three
ruby drivers
- this will reduce disk thrashing since the configuration file
only needs to be written out one extra time
- technically, it's twice ... but we should've always been writing
one out on first run in case it crashes then
- tomoko: defaulted back to the safest ruby drivers, given the optimal
drivers have some stability concerns
¹: minor errata: spotted a typo saying `synchronize(cpu)` when the CPU
is stopped, instead of `synchronize(ppu)`. This will be fixed in the v104
official 7zip archives.
I'm kind of rushing here but, it's really good timing for me to push out
a new official release. The blocking issues are resolved or close to it,
and we need lots of testing of the new major changes.
I'm going to consider this a semi-stable testing release and leave links
to v103 just in case.
byuu says:
Changelog:
- Master System: merged Bus into CPU
- Mega Drive: merged BusCPU into CPU; BusAPU into AU
- Mega Drive: added TMSS emulation; disabled by default [hex\_usr]
- VDP lockout not yet emulated
- processor/arm7tdmi: renamed interrupt() to exception()
- processor/arm7tdmi: CPSR.F (FIQ disable) flag is set on reset
- processor/arm7tdmi: pipeline decode stage caches CPSR.T (THUMB mode)
[MerryMage]
- fixes `msr_tests.gba` test F
- processor/arm7tdmi/disassembler: add PC address to left of currently
executing instruction
- processor/arm7tdmi: stop forcing CPSR.M (mode flags) bit 4 high (I
don't know what really happens here)
- processor/arm7tdmi: undefined instructions now generate Undefined
0x4 exception
- processor/arm7tdmi: thumbInstructionAddRegister masks PC by &~3
instead of &~2
- hopefully this is correct; &~2 felt very wrong
- processor/arm7tdmi: thumbInstructionStackMultiple can use sequential
timing for PC/LR PUSH/POP [Cydrak]
- systems/Mega Drive.sys: added tmss.rom; enable with cpu version=1
- tomoko: detect when a ruby video/audio/input driver crashes higan;
disable it on next program startup
v104 blockers:
- Mega Drive: support 8-bit SRAM (even if we don't support 16-bit;
don't force 8-bit to 16-bit)
- Mega Drive: add region detection support to icarus
- ruby: add default audio device information so certain drivers won't
default to silence out of the box
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.
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.
byuu says:
Changelog:
- processor/arm7tdmi: implementation all nine remaining ARM
instructions
- processor/arm7tdmi: implemented five more THUMB instructions
(sixteen remain)
byuu says:
Changelog:
- processor/arm7tdmi: implemented 10 of 19 ARM instructions
- processor/arm7tdmi: implemented 1 of 22 THUMB instructions
Today's WIP was 6 hours of work, and yesterday's was 5 hours.
Half of today was just trying to come up with the design to use a
lambda-based dispatcher to map both instructions and disassembly,
similar to the 68K core. The problem is that the ARM core has 28 unique
bits, which is just far too many bits to have a full lookup table like
the 16-bit 68K core.
The thing I wanted more than anything else was to perform the opcode
bitfield decoding once, and have it decoded for both instructions and
the disassembler. It took three hours to come up with a design that
worked for the ARM half ... relying on #defines being able to pull in
other #defines that were declared and changed later after the first
one. But, I'm happy with it. The decoding is in the table building, as
it is with the 68K core. The decoding does happen at run-time on each
instruction invocation, but it has to be done.
As to the THUMB core, I can create a 64K-entry lambda table to cover all
possible encodings, and ... even though it's a cache killer, I've
decided to go for it, given the outstanding performance it obtained in
the M68K core, as well as considering that THUMB mode is far more common
in GBA games.
As to both cores ... I'm a little torn between two extremes:
On the one hand, I can condense the number of ARM/THUMB instructions
further to eliminate more redundant code. On the other, I can split them
apart to reduce the number of conditional tests needed to execute each
instruction. It's really the disassembler that makes me not want to
split them up further ... as I have to split the disassembler functions
up equally to the instruction functions. But it may be worth it if it's
a speed improvement.
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.
byuu says:
Changelog:
- processor/lr35902: completed rewrite
I'd appreciate regression testing of the Game Boy and Game Boy Color
emulation between v103r24 and v103r26 (skip r25) if anyone wouldn't
mind.
I fixed up processor/lr35902-legacy to compile and run, so that trace
logs can be created between the two cores to find errors. I'm going to
kill processor/lr35902-legacy with the next WIP release, as well as make
changes to the trace format (add flags externally from AF; much easier
to read them that way), which will make it more difficult to do these
comparisons in the future, hence r26 may prove important later on if we
miss regressions this time.
As for the speed of the new CPU core, not too much to report ... at
least it's not slower :)
Mega Man II: 212.5 to 214.5fps
Shiro no Sho: 191.5 to 191.5fps
Oracle of Ages: 182.5 to 190.5fps
byuu says:
Changelog:
- gb/cpu: force STAT mode to 0 when LCD is disabled (fixes Pokemon
Pinball, etc)
- gb/ppu: when LCD is disabled, require at least one-frame wait to
re-enable, display white during this time
- todo: should step by a scanline at a time: worst-case is an
extra 99% of a frame to enable again
- gba/ppu: cache tilemap lookups and attribute parsing
- it's more accurate because the GBA wouldn't read this for every
pixel
- but unfortunately, this didn't provide any speedup at all ...
sigh
- ruby/audio/alsa: fixed const issue with free()
- ruby/video/cgl: removed `glDisable(GL_ALPHA_TEST)` [deprecated]
- ruby/video/cgl: removed `glEnable(GL_TEXTURE_2D)` [unnecessary as
we use shaders]
- processor/lr35902: started rewrite¹
¹: so, the Game Boy and Game Boy Color cores will be completely
broken for at least the next two or three WIPs.
The old LR35902 was complete garbage, written in early 2011. So I'm
rewriting it to provide a massive cleanup and consistency with other
processor cores, especially the Z80 core.
I've got about 85% of the main instructions implemented, and then I have
to do the CB instructions. The CB instructions are easier because
they're mostly just a small number of opcodes in many small variations,
but it'll still be tedious.
byuu says:
Changelog:
- gb/mbc6: mapper is now functional, but Net de Get has some text
corruption¹
- gb/mbc7: mapper is now functional²
- gb/cpu: HDMA syncs other components after each byte transfer now
- gb/ppu: LY,LX forced to zero when LCDC.d7 is lowered (eg disabled),
not when it's raised (eg enabled)
- gb/ppu: the LCD does not run at all when LCDC.d7 is clear³
- fixes graphical corruption between scene transitions in Legend
of Zelda - Oracle of Ages
- thanks to Cydrak, Shonumi, gekkio for their input on the cause
of this issue
- md/controller: renamed "Gamepad" to "Control Pad" per official
terminology
- md/controller: added "Fighting Pad" (6-button controller) emulation
[hex\_usr]
- processor/m68k: fixed TAS to set data.d7 when
EA.mode==DataRegisterDirect; fixes Asterix
- hiro/windows: removed carriage returns from mouse.cpp and
desktop.cpp
- ruby/audio/alsa: added device driver selection [SuperMikeMan]
- ruby/audio/ao: set format.matrix=nullptr to prevent a crash on some
systems [SuperMikeMan]
- ruby/video/cgl: rename term() to terminate() to fix a crash on macOS
[Sintendo]
¹: The observation that this mapper split $4000-7fff into two banks
came from MAME's implementation. But their implementation was quite
broken and incomplete, so I didn't actually use any of it. The
observation that this mapper split $a000-bfff into two banks came from
Tauwasser, and I did directly use that information, plus the knowledge
that $0400/$0800 are the RAM bank select registers.
The text corruption is due to a race condition with timing. The game is
transferring font letters via HDMA, but the game code ends up setting
the bank# with the font a bit too late after the HDMA has already
occurred. I'm not sure how to fix this ... as a whole, I assumed my Game
Boy timing was pretty good, but apparently it's not that good.
²: The entire design of this mapper comes from endrift's notes.
endrift gets full credit for higan being able to emulate this mapper.
Note that the accelerometer implementation is still not tested, and
probably won't work right until I tweak the sensitivity a lot.
³: So the fun part of this is ... it breaks the strict 60fps rate of
the Game Boy. This was always inevitable: certain timing conditions can
stretch frames, too. But this is pretty much an absolute deal breaker
for something like Vsync timing. This pretty much requires adaptive sync
to run well without audio stuttering during the transition.
There's currently one very important detail missing: when the LCD is
turned off, presumably the image on the screen fades to white. I do not
know how long this process takes, or how to really go about emulating
it. Right now as an incomplete patch, I'm simply leaving the last
displayed image on the screen until the LCD is turned on again. But I
will have to output white, as well as add code to break out of the
emulation loop periodically when the LCD is left off eg indefinitely, or
bad things would happen. I'll work something out and then implement.
Another detail is I'm not sure how long it takes for the LCD to start
rendering again once enabled. Right now, it's immediate. I've heard it's
as long as 1/60th of a second, but that really seems incredibly
excessive? I'd like to know at least a reasonably well-supported
estimate before I implement that.
byuu says:
Changelog:
- gb: added accelerometer X-axis, Y-Axis inputs¹
- gb: added rumble input¹
- gb/mbc5: added rumble support²
- gb/mbc6: added skeleton driver, but it doesn't boot Net de Get
- gb/mbc7: added mostly complete driver (only missing EEPROM), but it
doesn't boot Kirby Tilt 'n' Tumble
- gb/tama: added leap year assignment
- tomoko: fixed macOS compilation [MerryMage]
- hiro/cocoa: fix table cell redrawing on updates and automatic column
resizing [ncbncb]
- hiro/cocoa: fix some weird issue with clicking table view checkboxes
on Retina displays [ncbncb]
- icarus: enhance Game Boy heuristics³
- nall: fix three missing return statements [Jonas Quinn]
- ruby: hopefully fixed all compilation errors reported by Screwtape
et al⁴
¹: because there's no concept of a controller for cartridge inputs,
I'm attaching to the base platform for now. An idea I had was to make
separate ports for each cartridge type ... but this would duplicate the
rumble input between MBC5 and MBC7. And would also be less discoverable.
But it would be more clean in that users wouldn't think the Game Boy
hardware had this functionality. I'll think about it.
²: it probably won't work yet. Rumble isn't documented anywhere, but
I dug through an emulator named GEST and discovered that it seems to use
bit 3 of the RAM bank select to be rumble. I don't know if it sets the
bit for rumbling, then clears when finished, or if it sets it and then
after a few milliseconds it stops rumbling. I couldn't test on my
FreeBSD box because SDL 1.2 doesn't support rumble, udev doesn't exist
on FreeBSD, and nobody has ever posted any working code for how to use
evdev (or whatever it's called) on FreeBSD.
³: I'm still thinking about specifying the MBC7 RAM as EEPROM, since
it's not really static RAM.
⁴: if possible, please test all drivers if you can. I want to ensure
they're all working. Especially let me know if the following work:
macOS: input.carbon Linux: audio.pulseaudiosimple, audio.ao (libao)
If I can confirm these are working, I'm going to then remove them from
being included with stock higan builds.
I'm also considering dropping SDL video on Linux/BSD. XShm is much
faster and supports blurring. I may also drop SDL input on Linux, since
udev works better. That will free a dependency on SDL 1.2 for building
higan. FreeBSD is still going to need it for joypad support, however.
byuu says:
Changelog:
- ruby: ported all remaining drivers to new API¹
- ruby/wasapi: fix for dropping one sample per period [SuperMikeMan]
- gb: emulated most of the TAMA RTC; but RTC state is still volatile²
¹: the new ports are:
- audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao}
- input/{udev, quartz, carbon}
It's pretty much guaranteed many of them will have compilation errors.
Please paste the error logs and I'll try to fix them up. It may take a
WIP or two to get there.
It's also possible things broke from the updates. If so, I could use
help comparing the old file to the new file, looking for mistakes, since
I can't test on these platforms apart from audio/directsound.
Please report working drivers in this list, so we can mark them off the
list. I'll need both macOS and Linux testers.
audio/directsound.cpp:112:
if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false;
²: once I get this working, I'll add load/save support for the RTC
values. For now, the RTC data will be lost when you close the emulator.
Right now, you can set the date/time in real-time mode, and when you
start the game, the time will be correct, and the time will tick
forward. Note that it runs off emulated time instead of actual real
time, so if you fast-forward to 300%, one minute will be 20 seconds.
The really big limitation right now is that when you exit the game, and
restart it, and resume a new game, the hour spot gets corrupted, and
this seems to instantly kill your pet. Fun. This is crazy because the
commands the game sends to the TAMA interface are identical between
starting a new game and getting in-game versus loading a game.
It's likely going to require disassembling the game's code and seeing
what in the hell it's doing, but I am extremely bad at LR35092 assembly.
Hopefully endrift can help here :|
byuu says:
Changelog:
- gb: added TAMA emulation [thanks to endrift for the initial notes]
- gb: save RTC memory to disk (MBC3 doesn't write to said memory yet;
TAMA doesn't emulate it yet)
- gb: expect MMM01 boot loader to be at end of ROM instead of start
- gb: store MBC2 save RAM as 256-bytes (512x4-bit) instead of
512-bytes (with padding)
- gb: major cleanups to every cartridge mapper; moved to Mapper class
instead of MMIO class
- gb: don't serialize all mapper states with every save state; only
serialize the active mapper
- gb: serialize RAM even if a battery isn't present¹
- gb/cartridge: removed unnecessary code; refactored other code to
eliminate duplication of functions
- icarus: improve GB(C) heuristics generation to not include filenames
for cartridges without battery backup
- icarus: remove incorrect rearrangement of MMM01 ROM data
- md/vdp: fix CRAM reads -- fixes Sonic Spinball colors [hex\_usr]
- tomoko: hide the main higan window when entering fullscreen
exclusive mode; helps with multi-monitor setups
- tomoko: destroy ruby drivers before calling Application::quit()
[Screwtape]
- libco: add settings.h and defines to fiber, ucontext [Screwtape]
¹: this is one of those crystal clear indications that nobody's
actually playing the higan DMG/CGB cores, or at least not with save
states. This was a major mistake.
Note: I can't find any official documentation that `GL_ALPHA_TEST` was
removed from OpenGL 3.2. Since it's not hurting anything except showing
some warnings in debug mode, I'm just going to leave it there for now.
byuu says:
Changelog:
- ruby/audio/xaudio2: ported to new ruby API
- ruby/video/cgl: ported to new ruby API (untested, won't compile)
- ruby/video/directdraw: ported to new ruby API
- ruby/video/gdi: ported to new ruby API
- ruby/video/glx: ported to new ruby API
- ruby/video/wgl: ported to new ruby API
- ruby/video/opengl: code cleanups
The macOS CGL driver is sure to have compilation errors. If someone will
post the compilation error log, I can hopefully fix it in one or two
iterations of WIPs.
I am unable to test the Xorg GLX driver, because my FreeBSD desktop
video card drivers do not support OpenGL 3.2. If the driver doesn't
work, I'm going to need help tracking down what broke from the older
releases.
The real fun is still yet to come ... all the Linux-only drivers, where
I don't have a single Linux machine to test with.
Todo:
- libco/fiber
- libco/ucontext (I should really just delete this)
- tomoko: hide main UI window when in exclusive fullscreen mode
byuu says:
Changelog:
- tomoko: Application::onMain assigned at end of Program::Program()
[Screwtape]¹
- libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c
[Screwtape]
- ruby/audio/openal: fixed device driver string list enumeration
- ruby/audio/wasapi: changing device re-initializes the driver now
- ruby/audio/wasapi: probably a pointless change, but don't fill the
buffer beyond the queue size with silence
- ruby/video/xvideo: renamed from ruby/video/xv
- ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists
before setting it [SuperMikeMan]
- ruby/video/xvideo: align buffer sizes to be evenly divisible by four
[SuperMikeMan]
- ruby/video/xvideo: fail nicely without crashing (hopefully)
- ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV
formats²
¹: prevents crashes when drivers fail to initialize from running the
main loop that polls input drivers before the input driver is
initialized (or fails to initialize itself.) Some drivers still don't
block their main functions when initialization fails, so they will still
crash, but I'll work to fix them.
²: this was a **major** pain in the ass, heh. You only get one chroma
sample for every four luma samples, so the color reproduction is even
worse than UYVY and YUYV (which is two to four chroma to luma.) Further,
the planar format took forever to figure out. Apparently it doesn't care
what portion of the image you specify in XvShmPutImage, it expects you
to use the buffer dimensions to locate the U and V portions of the data.
This is probably the most thorough X-Video driver in existence now.
Notes:
- forgot to rename the configuration settings dialog window title to
just "Settings"
byuu says:
Changelog:
- tomoko: improved handling of changing audio devices on the audio
settings panel
- ruby/audio/wasapi: added device enumeration and selection support¹
- ruby/audio/wasapi: release property store handle from audio device
- ruby/audio/wasapi: fix exclusive mode buffer filling
- ruby/video/glx2: ported to new API -- tested and confirmed working
great²
- ruby/video/sdl: fixed initialization -- tested and confirmed working
on FreeBSD now³
- ruby/video/xv: ported to new API -- tested and mostly working great,
sans fullscreen mode⁴
Errata:
- accidentally changed "Driver Settings" label to "Driver" on the
audio settings tab because I deleted the line and forgot the
"Settings" part
- need to use "return initialize();" from setDevice() in the WASAPI
driver, instead of "return true;", so device selection is currently
not functioning in this WIP for said driver
¹: for now, this will likely end up selecting the first available
endpoint device, which is probably wrong. I need to come up with a
system to expose good 'default values' when selecting new audio drivers,
or changing audio device settings.
²: glx2 is a fallback driver for system with only OpenGL 2.0 and no
OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards.
³: although I really should track down why InputManager::poll() is
crashing the emulator when Video::ready() returns false ...
⁴: really bizarrely, when entering fullscreen mode, it looks like the
image was a triangle strip, and the bottom right triange is missing, and
the top left triangle skews the entire image into it. I'm suspecting
this is a Radeon driver bug when trying to create a 2560x1600 X-Video
surface. The glitch persists when exiting fullscreen, too.
If anyone can test the X-Video driver on their Linux/BSD system, it'd be
appreciated. If it's just my video card, I'll ignore it. If not,
hopefully someone can find the cause of the issue :|
byuu says:
Changelog:
- tomoko: re-hid the video sync option¹
- tomoko: removed " Settings" duplication on all the individual
settings tab options
- ruby/audio/wasapi: finished port to new syntax; adapted to an
event-driven model; support 32-bit integral audio²
- ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³
¹: still contemplating a synchronize submenu of {none, video, audio},
but ... the fact that video can't work on PAL, WonderSwan games is a
real limitation for it
²: this driver actually received a ton of work. There's also a new
ring-buffer queue, and I added special handling for when exclusive mode
fails because the latency requested is lower than the hardware can
support. It'll pick the closest latency to the minimum that is possible
in this case.
On my Audigy Rx, the results for non-exclusive mode are the same. For
exclusive mode, the framerate drops from 60fps to ~50fps for smaller
buffers, and ~55fps for larger buffers (no matter how big, it never hits
60fps.) This is a lot better than before where it was hitting ~15fps,
but unfortunately it's the best I can do.
The event system used by WASAPI is really stupid. It just uses SetEvent
at some arbitrary time, and you have to query to see how many samples
it's waiting on. This makes it unknowable how many samples we should
buffer before calling `WaitForSingleObject(INFINITE)`, and it's also
unclear how we should handle cases where there's more samples available
than our queue has: either we can fill it with zeroes, or we can write
less samples. The former should prevent audio looping effects when
running too slowly, whereas the latter could potentially be too
ambitious when the audio could've recovered from a minor stall.
It's shocking to me how there's as many ways to send audio to a sound
card as there are sound card APIs, when all that's needed is a simple
double buffer and a callback event from another thread to do it right.
It's also terrifying how unbelievably shitty nearly all sound card
drivers apparently are.
Also, I don't know if cards can output an actual 24-bit mode with three
byte audio samples, or if they always just take 32-bit samples and
ignore the lower 8-bits. Whatever, it's all nonsense for the final
output to be >16-bits anyway (hi, `double[]` input from ruby.)
³: unfortunately, this driver always crashes on FreeBSD (even before
the rewrite), so I'll need someone on Linux to test it and make sure it
actually works. I'll also need testing for a lot of the other drivers as
well, once they're ported over (I don't have X-video, PulseAudio, ALSA,
or udev.)
Note that I forgot to set `_ready=true` at the end of `initialize()`,
and `_ready=false` in `terminate()`, but it shouldn't actually matter
beyond showing you a false warning message on startup about it failing
to initialize.
byuu says:
Changelog:
- emulator/audio: added the ability to change the output frequency at
run-time without emulator reset
- tomoko: display video synchronize option again¹
- tomoko: Settings→Configuration expanded to Settings→{Video,
Audio, Input, Hotkey, Advanced} Settings²
- tomoko: fix default population of audio settings tab
- ruby: Audio::frequency is a double now (to match both
Emulator::Audio and ASIO)³
- tomoko: changing the audio device will repopulate the frequency and
latency lists
- tomoko: changing the audio frequency can now be done in real-time
- ruby/audio/asio: added missing device() information, so devices can
be changed now
- ruby/audio/openal: ported to new API; added device selection support
- ruby/audio/wasapi: ported to new API, but did not test yet (it's
assuredly still broken)⁴
¹: I'm uneasy about this ... but, I guess if people want to disable
audio and just have smooth scrolling video ... so be it. With
Screwtape's documentation, hopefully that'll help people understand that
video synchronization always breaks audio synchronization. I may change
this to a child menu that lets you pick between {no synchronization,
video synchronization, audio synchronization} as a radio selection.
²: given how much more useful the video and audio tabs are now, I
felt that four extra menu items were worth saving a click and going
right to the tab you want. This also matches the behavior of the Tools
menu displaying all tool options and taking you directly to each tab.
This is kind of a hard change to get used to ... but I think it's for
the better.
³: kind of stupid because I've never seen a hardware sound card where
floor(frequency) != frequency, but whatever. Yay consistency.
⁴: I'm going to move it to be event-driven, and try to support 24-bit
sample formats if possible. Who knows which cards that'll fix and which
cards that'll break. I may end up making multiple WASAPI drivers so
people can find one that actually works for them. We'll see.
byuu says:
Changelog:
- ruby: rewrote the API interfaces for Video, Audio, Input
- ruby/audio: can now select the number of output channels (not useful
to higan, sorry)
- ruby/asio: various improvements
- tomoko: audio settings panel can now select separate audio devices
(for ASIO, OSS so far)
- tomoko: audio settings panel frequency and latency lists are
dynamically populated now
Note: due to the ruby API rewrite, most drivers will not compile. Right
now, the following work:
- video: Direct3D, XShm
- audio: ASIO, OSS
- input: Windows, SDL, Xlib
It takes a really long time to rewrite these (six hours to do the
above), so it's going to be a while before we're back at 100%
functionality again.
Errata:
- ASIO needs device(), setDevice()
- need to call setDevice() at program startup to populate
frequency/latency settings properly
- changing the device and/or frequency needs to update the emulator
resampler rates
The really hard part is going to be the last one: the only way to change
the emulator frequency is to flush all the audio streams and then
recompute all the coefficients for the resamplers. If this is called
during emulation, all audio streams will be erased and thus no sound
will be output. I'll most likely be forced to simply ignore
device/frequency changes until the user loads another game. It is at
least possible to toggle the latency dynamically.
byuu says:
Changelog:
- tomoko: by popular choice, default to adaptive mode on new installs
- hiro/windows: fix bug that was preventing the escape key from
closing some dialog windows
- nall/registry: use "\\\\" as separator instead of "/" ... because
some registry keys contain "/" in them >_>
- ruby: add ASIO driver stub (so far it can only initialize and grab
the driver name/version information)
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 >_>
byuu says:
Changelog:
- ruby/video: cleaned up Direct3D9 driver and fixed catastrophic
memory leak
- ruby/video: added fullscreen exclusive mode support to the Direct3D9
driver¹
- ruby/video: minor cosmetic code cleanups to various drivers
- tomoko: added support to always allow input when in fullscreen
exclusive mode
- tomoko: fixed window to not remove resizability flag when exiting
fullscreen mode
¹: I am assuming that exclusive mode will try to capture the primary
monitor. I don't know what will happen in multi-monitor setups, however,
as I don't use such a setup here.
Also, I am using `D3DPRESENT_DISCARD` instead of `D3DPRESENT_FLIP`. I'm
not sure if this will prove better or worse, but I've heard it will
waste less memory, and having a BackBufferCount of 1 should still result
in page flipping anyway. The difference is supposedly just that you
can't rely on the back buffer being a valid copy of the previous frame
like you can with FLIP.
Lastly, if you want Vsync, you can edit the configuration file to enable
that, and then turn off audio sync.
Errata: "pause emulation when focus is lost" is not working with
exclusive mode. I need to add a check to never auto-pause when in
exclusive mode. Thanks to bun for catching that one.
byuu says:
Changelog:
- tomoko: removed "Settings→Video Emulation→Overscan Mask" setting¹
- tomoko: remove a few unnecessary calls to resizeViewport on startup
- tomoko: only resize main window from video settings when in adaptive
or toggling adaptive mode²
- hiro/windows: add `SWP_NOACTIVATE` flag to prevent focus stealing on
resizing invisible windows³
- hiro/windows: suppress spurious API-generated `onSize()` callback
when calling `setVisible()`
¹: it just seemed like bad design to default to overscan masking
being disabled with overscan masks of 8 horizontal, 8 vertical out of
the box. Users would adjust the sliders and not see anything happening.
Instead, I've set the default masks to zero. If you want to turn off
overscan masking, simply slide those to zero again.
²: I figure the only way we're going to be able to fairly evaluate
Screwtape's suggestion is to try it both ways. And I will admit, I kind
of like the way this works as well ... a lot more so than I thought I
would, so I think it was a great suggestion. Still, now's the time if
people have strong opinions on this. Be sure to try both r10 and r11 to
compare. Barring no other feedback, I'm going to keep it this way.
³: this fixes the blinking of the main window on startup.
Screwtape, thanks again for the improvement suggestions. At this point
though, I am not using a tiling window manager. If you are able to patch
hiro/gtk and/or hiro/qt (I mostly use GTK) to work with tiling window
managers better, I wouldn't mind applying said patches, so long as they
don't break things on my own Xfce desktop with xfwm4.
Also, I noticed one issue with Xfce ... if the window is maximized and I
try to call `Window::setSize()`, it's not actually removing the maximize
flag. We'll need to look into how to add that to GTK, but I don't think
it's a huge issue. A similar glitch happens on windows where the icon
still reflects being maximized, but it does actually shrink, it just
sticks to the top left corner of the screen. So this isn't really a
critical bug, but would be extra polish.
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.
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.
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
byuu says:
Changelog:
- gba/cpu: massive code cleanup effort
- gba/cpu: DMA can run in between active instructions¹
- gba/cpu: added two-cycle startup delay between DMA activation and
DMA transfers²
- processor/spc700: BBC, BBC, CBNE cycle 4 is an idle cycle
- processor/spc700: ADDW, SUBW, MOVW (read) cycle 4 is an idle cycle
¹: unfortunately, this causes yet another performance penalty for the
poor GBA core =( Also, I think I may have missed disabling DMAs while
the CPU is stopped. I'll fix that in the next WIP.
²: I put the waiting counter decrement at the wrong place, so this
doesn't actually work. Needs to be more like
this:
auto CPU::step(uint clocks) -> void {
for(auto _ : range(clocks)) {
for(auto& timer : this->timer) timer.run();
for(auto& dma : this->dma) if(dma.active && dma.waiting) dma.waiting--;
context.clock++;
}
...
auto CPU::DMA::run() -> bool {
if(cpu.stopped() || !active || waiting) return false;
transfer();
if(irq) cpu.irq.flag |= CPU::Interrupt::DMA0 << id;
if(drq && id == 3) cpu.irq.flag |= CPU::Interrupt::Cartridge;
return true;
}
Of course, the real fix will be restructuring how DMA works, so that
it's always running in parallel with the CPU instead of this weird
design where it tries to run all channels in some kind of loop until no
channels are active anymore whenever one channel is activated.
Not really sure how to design that yet, however.
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.
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
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]
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.
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.
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.
byuu says (in the public annoucement):
With this release, PC Engine, Master System, Game Gear, Mega Drive and
the newly added SuperGrafx support are now quite usable! They're far
from the best emulators for these systems, but with many bugfixes, full
sound emulation, and save state support ... many games are now fully
playable with decent accuracy. The Game Boy Advance emulation is also
now substantially improved with vastly improved sound quality and a new
dot-based PPU renderer. With that change, every single component in
higan is now cycle-based. Regrettably, these changes do carry a ~20%
performance penalty compared to GBA emulation in v102.
Changelog (since the previous release):
- added SuperGrafx emulation
- improved audio band-pass filtering for all emulated systems
- screen rotation is now a hotkey; automatically rotates control
bindings
- screen rotation now supported on the Game Boy Advance as well (used
by a small number of games)
- massive improvements to Mega Drive emulation
- massive code cleanups and rewrites to many CPU emulation cores
(MOS6502, WDC65816, SPC700, etc)
- Famicom, Master System, Mega Drive: added PAL emulation support
- PC Engine, SuperGrafx, Master System, Game Gear, Mega Drive: added
save state support
- PC Engine, SuperGrafx: added PSG sound emulation
- Master System, Game Gear: added PSG sound emulation
- Mega Drive: added Z80 APU emulation [with help from Cydrak]
- Mega Drive: added PSG sound emulation
- Mega Drive: added YM2612 sound emulation [Cydrak]
- Super Famicom: fixed Super Game Boy emulation
- PC Engine: added save RAM support (using per-game PCE-CD backup RAM)
- Game Boy Advance: substantial improvements to audio emulation
quality
- Game Boy Advance: convert scanline-based PPU renderer to a dot-based
renderer
- Game Boy Advance: properly initialize CPU state (fixes Classic NES
Series games)
- Game Boy Advance: MUL timing corrected [Jonas Quinn]
- Mega Drive: emulate special mappers for Phantasy Star IV, Super
Street Fighter II, etc.
- Super Famicom: use darker luma for INIDISP=0 (large improvement to
Final Fantasy III opening)
- Super Famicom: fixed bugs in SMP OR1,AND1 instructions
- cheat code database regrettably removed from official releases; will
be made available separately
- Famicom: PAL emulation improvements [hex\_usr]
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.
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.
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.
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.
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.
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.
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.
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
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.
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 ...
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
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
byuu says:
Changelog:
- GBA: process audio at 2MHz instead of 32KHz¹
- MD: do not allow the 68K to stop the Z80, unless it has been granted
bus access first
- MD: do not reset bus requested/granted signals when the 68K resets
the Z80
- the above two fix The Lost Vikings
- MD: clean up the bus address decoding to be more readable
- MD: add support for a13000-a130ff (#TIME) region; pass to cartridge
I/O²
- MD: emulate SRAM mapping used by >16mbit games; bank mapping used
by >32mbit games³
- MD: add 'reset pending' flag so that loading save states won't
reload 68K PC, SP registers
- this fixes save state support ... mostly⁴
- MD: if DMA is not enabled, do not allow CD5 to be set [Cydrak]
- this fixes in-game graphics for Ristar. Title screen still
corrupted on first run
- MD: detect and break sprite lists that form an infinite loop
[Cydrak]
- this fixes the emulator from dead-locking on certain games
- MD: add DC offset to sign DAC PCM samples [Cydrak]
- this improves audio in Sonic 3
- MD: 68K TAS has a hardware bug that prevents writing the result back
to RAM
- this fixes Gargoyles
- MD: 68K TRAP should not change CPU interrupt level
- this fixes Shining Force II, Shining in the Darkness, etc
- icarus: better SRAM heuristics for Mega Drive games
Todo:
- need to serialize the new cartridge ramEnable, ramWritable, bank
variables
¹: so technically, the GBA has its FIFO queue (raw PCM), plus a GB
chipset. The GB audio runs at 2MHz. However, I was being lazy and
running the sequencer 64 times in a row, thus decimating the audio to
32KHz. But simply discarding 63 out of every 64 samples resorts in
muddier sound with more static in it.
However ... increasing the audio thread processing intensity 64-fold,
and requiring heavy-duty three-chain lowpass and highpass filters is not
cheap. For this bump in sound quality, we're eating a loss of about 30%
of previous performance.
Also note that the GB audio emulation in the GBA core still lacks many
of the improvements made to the GB core. I was hoping to complete the GB
enhancements, but it seems like I'm never going to pass blargg's
psychotic edge case tests. So, first I want to clean up the GB audio to
my current coding standards, and then I'll port that over to the GBA,
which should further increase sound quality. At that point, it sound
exceed mGBA's audio quality (due to the ridiculously high sampling rate
and strong-attenuation audio filtering.)
²: word writes are probably not handled correctly ... but games are
only supposed to do byte writes here.
³: the SRAM mapping is used by games like "Story of Thor" and
"Phantasy Star IV." Unfortunately, the former wasn't released in the US
and is region protected. So you'll need to change the NTSU to NTSCJ in
md/system/system.cpp in order to boot it. But it does work nicely now.
The write protection bit is cleared in the game, and then it fails to
write to SRAM (soooooooo many games with SRAM write protection do this),
so for now I've had to disable checking that bit. Phantasy Star IV has a
US release, but sadly the game doesn't boot yet. Hitting some other bug.
The bank mapping is pretty much just for the 40mbit Super Street Fighter
game. It shows the Sega and Capcom logos now, but is hitting yet another
bug and deadlocking.
For now, I emulate the SRAM/bank mapping registers on all cartridges,
and set sane defaults. So long as games don't write to $a130XX, they
should all continue to work. But obviously, we need to get to a point
where higan/icarus can selectively enable these registers on a per-game
basis.
⁴: so, the Mega Drive has various ways to lock a chip until another
chip releases it. The VDP can lock the 68K, the 68K can lock the Z80,
etc. If this happens when you save a state, it'll dead-lock the
emulator. So that's obviously a problem that needs to be fixed. The fix
will be nasty ... basically, bypassing the dead-lock, creating a
miniature, one-instruction-long race condition. Extremely unlikely to
cause any issues in practice (it's only a little worse than the SNES
CPU/SMP desync), but ... there's nothing I can do about it. So you'll
have to take it or leave it. But yeah, for now, save states may lock up
the emulator. I need to add code to break the loops when in the process
of creating a save state still.
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.
byuu says:
Changelog:
- nall: added DSP::IIR::OnePole (which is a first-order IIR filter)
- FC/APU: removed strong highpass, weak hipass filters (and the
dummied out lowpass filter)
- MS,GG,MD/PSG: removed lowpass filter
- MS,GG,MD/PSG: audio was not being centered properly; removed
centering for now
- MD/YM2612: fixed clipping of accumulator from 18 signed bits to 14
signed bits (-0x2000 to +0x1fff) [Cydrak]
- MD/YM2612: removed lowpass filter
- PCE/PSG: audio was not being centered properly; removed centering
for now
First thing is that I've removed all of the ad-hoc audio filtering.
Emulator::Stream intrinsically provides a three-pass, second-order
biquad IIR butterworth lowpass filter that clips frequencies above 20KHz
with very good attenuation (as good as IIR gets, anyway.)
It doesn't really make sense to have the various cores running
additional lowpass filters. If we want to filter frequencies below
20KHz, then I can adapt Emulator::Audio::createStream() to take a cutoff
frequency value, and we can do it all at once, with much better quality.
Right now, I don't know what frequencies are best to cut off the various
other audio cores, so they're just gone for now.
As for the highpass filters for the Famicom core, well ... you don't get
aliasing from resampling low frequencies. And generally speaking, too
low a frequency will be inaudible anyway. All these were doing was
killing possible bass (if they were too strong.) We can add them again,
but only if someone can convert Ryphecha's ad-hoc magic integers into a
frequency cutoff. In which case, I'll use my biquad IIR filter to do it
even better. On this note, it may prove useful to do this for the MD PSG
as well, to try and head off unnecessary clamping when mixing with the
YM2612.
Finally, there was the audio centering issue that affected the
MS,GG,MD,PCE,SG cores. It was flooring the "silent" audio level, which
was resulting in extremely heavy distortion if you tried listening to
higan and, say, audacious at the same time. Without the botched
centering, this distortion is completely gone now.
However, without any centering, we've halved the potential volume range.
This means the audio slider in higan's audio settings panel will start
clamping twice as quickly. So ultimately, we need to figure out how to
fix the centering. This isn't as simple as just subtracting less. We
will probably have to center every individual audio channel before
summing them to do this properly.
Results:
On the Mega Drive, Altered Beast sounds quite a bit better, a lot less
distortion now. But it's still not perfect, especially sound effects.
Further, Bare Knuckle / Streets of Rage still has really bad sound
effects. It looks like I broke something in Cydrak's code when trying to
adapt it to my style =(
byuu says:
Changelog:
- (MS,GG,MD)/PSG: flip output bit from noise channel [TmEE]
- MD/YM2612: rewrite YM2612::Channel functions to
YM2612::Channel::Operator functions¹
- MD/YM2612: pitch/octave I/O registers should set reload, not value
(fixes sound in most games)
- MD/YM2612: don't try to sign-extend raw PCM values (fixes Shining
Force opening music)
- MD/YM2612: various algorithm simplifications; conversions from
`*`, `/`, `%` to `<<`, `>>`; etc.
Overall ... Sonic the Hedgehog sounds really, really great. Almost
perfect, but there's a bit of clamping going on in the special zones.
Langrisser II sounds really great. Shining Force sounds pretty much
perfect. Bare Knucles (Streets of Rage) does pretty badly ... punches
sound more like dinging a salad fork on a wine glass, heh. Altered Beast
is extremely broken ... no music at the title screen, very distorted
in-game music. I suspect a bug outside of the YM2612 is affecting this
game.
So, the YM2612 emulation isn't perfect, but it's a really good start to
the most complex sound chip in all of higan. Hopefully the VRC7 and
YM2413 will prove to be less ferocious ... not that I'm in any rush to
work on either. The former is going to need the NES mapper rewrite to be
done first, and the latter is cool but not very necessary since all
those games have fallbacks to the inferior PSG audio.
But really ... I can't thank Cydrak enough for doing this for me. It
would have probably taken me months to parse through all of the
documentation on this chip (most of which is in a 55-page thread on
spritesmind that is filled with wrong/outdated information at the start,
and corrections as you go deeper.) Not to mention, learning about what
the hell detuning, low-frequency oscillation, tremolo, vibrato, etc were
all about. Or how those algorithms to compute the final output work. Or
the dozens of special cases littered in there to make everything sound
good. Fierce, nasty chip that.
Now the last real problem is save states ... the Mega Drive is going to
be the trickiest of all to implement with libco. There are lots of areas
where one chip will deadlock another chip while it completes some
operation. We don't have a choice but to force those stalls to abort
anyway, in order to let libco reach the start of its entry point once
again. I don't know what kind of impact that'll have on states ... I
suspect they'll work almost as reliably as the SNES does, but I can't
know that until I implement it. It's going to be pretty nasty, though.
¹: this basically removes a lot of unnecessary op. prefixes and the
need to capture `auto& op = operators[index]` at the start of every
function.
I wanted to have subfunctions like
`YM2612::Channel::Operator::Envelope::run()`, etc but unfortunately,
pretty much all of the envelope, phase, pitch, level functions need to
access each other's state.
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.
byuu says:
Changelog:
- MD/PSG: fixed 68K bus Z80 status read address location
- MS, GG, MD/PSG: channels post-decrement their counters, not
pre-decrement [Cydrak]¹
- MD/VDP: cache screen width registers once per scanline; screen
height registers once per frame
- MD/VDP: support 256-width display mode (used in Shining Force, etc)
- MD/YM2612: implemented timers²
- MD/YM2612: implemented 8-bit PCM DAC²
- 68000: TRAP instruction should index the vector location by 32 (eg
by 128 bytes), fixes Shining Force
- nall: updated hex(), octal(), binary() functions to take uintmax
instead of template<typename T> parameter³
¹: this one makes an incredible difference. Sie noticed that lots of
games set a period of 0, which would end up being a really long period
with pre-decrement. By fixing this, noise shows up in many more games,
and sounds way better in games even where it did before. You can hear
extra sound on Lunar - Sanposuru Gakuen's title screen, the noise in
Sonic The Hedgehog (Mega Drive) sounds better, etc.
²: this also really helps sound. The timers allow PSG music to play
back at the correct speed instead of playing back way too quickly. And
the PCM DAC lets you hear a lot of drum effects, as well as the
"Sega!!" sound at the start of Sonic the Hedgehog, and the infamous,
"Rise from your grave!" line from Altered Beast.
Still, most music on the Mega Drive comes from the FM channels, so
there's still not a whole lot to listen to.
I didn't implement Cydrak's $02c test register just yet. Sie wasn't 100%
certain on how the extended DAC bit worked, so I'd like to play it a
little conservative and get sound working, then I'll go back and add a
toggle or something to enable undocumented registers, that way we can
use that to detect any potential problems they might be causing.
³: unfortunately we lose support for using hex() on nall/arithmetic
types. If I have a const Pair& version of the function, then the
compiler gets confused on whether Natural<32> should use uintmax or
const Pair&, because compilers are stupid, and you can't have explicit
arguments in overloaded functions. So even though either function would
work, it just decides to error out instead >_>
This is actually really annoying, because I want hex() to be useful for
printing out nall/crypto keys and hashes directly.
But ... this change had to be made. Negative signed integers would crash
programs, and that was taking out my 68000 disassembler.
byuu says:
Changelog:
- MD: connected 32KB cartridge RAM up to every Genesis game under 2MB
loaded¹
- MS, GG, MD: improved PSG noise channel emulation, hopefully²
- MS, GG, MD: lowered PSG volume so that the lowpass doesn't clamp
samples³
- MD: added read/write handlers for VRAM, VSRAM, CRAM
- MD: block VRAM copy when CD4 is clear⁴
- MD: rewrote VRAM fill, VRAM copy to be byte-based⁵
- MD: VRAM fill byte set should fall through to regular data port
write handler⁶
¹: the header parsing for backup RAM is really weird. It's spaces
when not used, and seems to be 0x02000001-0x02003fff for the Shining
games. I don't understand why it starts at 0x02000001 instead of
0x02000000. So I'm just forcing every game to have 32KB of RAM for now.
There's also special handling for ROMs > 2MB that also have RAM
(Phantasy Star IV, etc) where there's a toggle to switch between ROM and
RAM. For now, that's not emulated.
I was hoping the Shining games would run after this, but they're still
dead-locking on me :(
²: Cydrak pointed out some flaws in my attempt to implement what he
had. I was having trouble understanding what he meant, so I went back
and read the docs on the sound chip and tried implementing the counter
the way the docs describe. Hopefully I have this right, but I don't know
of any good test ROMs to make sure my noise emulation is correct. The
docs say the shifted-out value goes to the output instead of the low bit
of the LFSR, so I made that change as well.
I think I hear the noise I'm supposed to in Sonic Marble Zone now, but
it seems like it's not correct in Green Hill Zone, adding a bit of an
annoying buzz to the background music. Maybe it sounds better with the
YM2612, but more likely, I still screwed something up :/
³: it's set to 50% range for both cores right now. For the MD, it
will need to be 25% once YM2612 emulation is in.
⁴: technically, this deadlocks the VDP until a hard reset. I could
emulate this, but for now I just don't do the VRAM copy in this case.
⁵: VSRAM fill and CRAM fill not supported in this new mode. They're
technically undocumented, and I don't have good notes on how they work.
I've been seeing conflicting notes on whether the VRAM fill buffer is
8-bits or 16-bits (I chose 8-bits), and on whether you write the low
byte and then high byte of each words, or the high byte and then low
byte (I chose the latter.)
The VRAM copy improvements fix the opening text in Langrisser II, so
that's great.
⁶: Langrisser II sets the transfer length to one less than needed to
fill the background letter tile on the scenario overview screen. After
moving to byte-sized transfers, a black pixel was getting stuck there.
So effectively, VRAM fill length becomes DMA length + 1, and the first
byte uses the data port so it writes a word value instead of just a byte
value. Hopefully this is all correct, although it probably gets way more
complicated with the VDP FIFO.
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.
byuu says:
Changelog:
- MD: restructured DMA to a subclass of VDP
- MD: implemented VRAM copy mode (fixes Langrisser II ... mostly)
- MS: implemened PSG support [Cydrak]
- GG: implemented PSG stereo sound support
- MS: use the new struct Model {} design that other cores use
The MS/GG PSG should be feature complete, but I don't have good tests
for Game Gear stereo mode, nor for the noise channel. There's also a
really weird behavior with when to reload the channel counters on volume
register writes. I can confirm what Cydrak observed in that following
the docs and reloading always creates serious audio distortion problems.
So, more research is needed there.
To get the correct sound out of the PSG, I have to run it at 3.58MHz /
16, which seems really weird to me. The docs make it sound like it's
supposed to run at the full 3.58MHz. If we can really run it at
223.7KHz, then that's help reduce the overhead of PSG emulation, which
will definitely come in handy for Mega Drive, and possibly later Mega
CD, emulation.
I have not implemented the PSG into the Mega Drive just yet. Nor have I
implemented save states or cheat code support into the MS/GG cores yet.
The latter is next on my list.
byuu says:
Changelog:
- PCE: restructured VCE, VDCs to run one scanline at a time
- PCE: bound VDCs to 1365x262 timing (in order to decouple the VDCs
from the VCE)
- PCE: the two changes above allow save states to function; also
grants a minor speed boost
- PCE: added cheat code support (uses 21-bit bus addressing; compare
byte will be useful here)
- 68K: fixed `mov *,ccr` to read two bytes instead of one [Cydrak]
- Z80: emulated /BUSREQ, /BUSACK; allows 68K to suspend the Z80
[Cydrak]
- MD: emulated the Z80 executing instructions [Cydrak]
- MD: emulated Z80 interrupts (triggered during each Vblank period)
[Cydrak]
- MD: emulated Z80 memory map [Cydrak]
- MD: added stubs for PSG, YM2612 accesses [Cydrak]
- MD: improved bus emulation [Cydrak]
The PCE core is pretty much ready to go. The only major feature missing
is FM modulation.
The Mega Drive improvements let us start to see the splash screens for
Langrisser II, Shining Force, Shining in the Darkness. I was hoping I
could get them in-game, but no such luck. My Z80 implementation is
probably flawed in some way ... now that I think about it, I believe I
missed the BusAPU::reset() check for having been granted access to the
Z80 first. But I doubt that's the problem.
Next step is to implement Cydrak's PSG core into the Master System
emulator. Once that's in, I'm going to add save states and cheat code
support to the Master System core.
Next, I'll add the PSG core into the Mega Drive. Then I'll add the
'easy' PCM part of the YM2612. Then the rest of the beastly YM2612 core.
Then finally, cap things off with save state and cheat code support.
Should be nearing a new release at that point.
byuu says:
Changelog:
- PCE: emulated PSG volume controls (vastly enhances audio quality)
- PCE: emulated PSG noise as a square wave (somewhat enhances audio
quality)
- PCE: added save state support (currently broken and deadlocks the
emulator though)
Thankfully, MAME had some rather easy to read code on how the volume
adjustment works, which they apparently ripped out of expired patents.
Hooray!
The two remaining sound issues are:
1. the random number generator for the noise channel is definitely not
hardware accurate. But it won't affect the sound quality at all. You'd
only be able to tell the difference by looking at hex bytes of a stream
rip.
2. I have no clue how to emulate the LFO (frequency modulation). A comment
in MAME's code (they also don't emulate it) advises that they aren't
aware of any games that even use it. But I'm there has to be at least one?
Given LFO not being used, and the RNG not really mattering all that much
... the sound's pretty close to perfect now.
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.
byuu says:
Changelog:
- higan: added Makefile option,
`build=(release|debug|instrument|optimize)` , defaults to release
- PCE: added preliminary PSG (sound) emulation
The Makefile thing is just to make it easier to build debug releases
without having to hand-edit the Makefile. Just say "gmake build=debug"
and you'll get -g, otherwise you'll get -O3 -s. I'll probably start
adding these build= blocks to my other projects. Or maybe I'll put it
into nall, in which case release will need a different name ... a stable
-01, and a fast -03 mode. I also want to add a mode to generate
profiling information (via gprof.)
Unfortunately, the existing documentation on the PCE's PSG is as
barebones as humanly possible.
Right now, I support waveform mode, direct D/A mode, and noise
generation mode. However for noise, I'm not actually generating a proper
square wave, and I don't know the PRNG algorithm used for choosing the
random values. So for now, I'm just feeding in nall::random() values to
it.
I'm also not sure about the noise mode's frequency counter. Magic Kit is
implying it's 64*~frequency, but that results in an 11-bit period. It
seems only logical that we'd want a 12-bit period. So my guess is that
it's actually 12-bit, and halfway through it alternates between two
randomly generated values every 32 samples, and the two values are
generated every time the period hits zero.
Next up, it's not clear when the period counter is reloaded, either for
the waveform or the noise mode. So for now, when enabling the channel, I
reload the waveform period. And when enabling noise mode, I reload the
noise period. I don't know if you need to do it when writing to the
frequency registers or not.
Next, it's not clear whether the period is a decrement-and-compare, or a
compare-and-decrement, and whether we reload with frequency,
frequency-1, or frequency+1. There's this cryptic note in
pcetext.txt:
> The PSG channel frequency is 12 bits, $001 is the highest frequency,
> $FFF is the next to lowest frequency, and $000 is the lowest frequency.
As best I can tell, he's trying to say that it's decrement-and-compare.
Whatever the case, there's periodic popping noises every few seconds. I
thought it might be because this is the first system with a fractional
sampling rate (~3.57MHz), but rounding the frequency to a whole number
doesn't help at all, and emulator/audio should be able to handle
fractional resampling rates anyway.
The popping noises could also be due to PSG writes being cycle-timed,
and my HuC6280 cycle timings not being very great yet. The PSG has no
kind of interrupts, so I think careful timing is the only way to do
certain things, especially D/A mode.
Next up, I really don't understand the frequency modulation mode at all.
I don't have any idea whatsoever how to support that. It also has a
frequency value that we'll need to understand how the period works and
reloads. Basic idea though is the channel 1 output turns into a value to
modulate channel 0's frequency by, and channel 1's output gets muted.
Next up, I don't know how the volume controls work at all. There's a
master volume left+right, per-channel volume left+right, and per-channel
overall volume. The documentation lists their effects in terms of
decibels. I have no fucking clue how to turn decibels into multiply-by
values. Let alone how to stack THREE levels of audio volume controls
>_>
Next, it looks like the output is always 5-bit unsigned per-channel, but
there's also all the volume adjustments. So I don't know the final
bit-depth of the final output to normalize the value into a signed
floating point value between -1.0 and +1.0. So for now, half the
potential speaker range (anything below zero) isn't used in the
generated output.
As bad as all this sounds, and it is indeed bad ... the audio's about
~75% correct, so you can definitely play games like this, it just won't
be all that much fun.
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.
byuu says:
Changelog:
- PCE: split VCE from VDC
- HuC6280: changed bus from (uint21 addr) to (uint8 bank, uint13 addr)
- added SuperGrafx emulation (adds secondary VDC, plus new VPC)
The VDC now has no concept of the actual display raster timing, and
instead is driven by Vpulse (start of frame) and Hpulse (start of
scanline) signals from the VCE. One still can't render the start of the
next scanline onto the current scanline through overly aggressive
timings, but it shouldn't be too much more difficult to allow that to
occur now. This process incurs quite a major speed hit, so low-end
systems with Atom CPUs can't run things at 60fps anymore.
The timing needs a lot of work. The pixels end up very jagged if the VCE
doesn't output batches of 2-4 pixels at a time. But this should not be a
requirement at all, so I'm not sure what's going wrong there.
Yo, Bro and the 512-width mode of TV Sports Basketball is now broken as
a result of these changes, and I'm not sure why.
To load SuperGrafx games, you're going to have to change the .pce
extensions to .sg or .sgx. Or you can manually move the games from the
PC Engine folder to the SuperGrafx folder and change the game folder
extensions. I have no way to tell the games apart. Mednafen uses CRC32
comparisons, and I may consider that since there's only five games, but
I'm not sure yet.
The only SuperGrafx game that's playable right now is Aldynes. And the
priorities are all screwed up. I don't understand how the windows or the
priorities work at all from sgxtech.txt, so ... yeah. It's pretty
broken, but it's a start.
I could really use some help with this, as I'm very lost right now with
rendering :/
-----
Note that the SuperGrafx is technically its own system, it's not an
add-on.
As such, I'm giving it a separate .sys folder, and a separate library.
There's debate over how to name this thing. "SuperGrafx" appears more
popular than "Super Grafx". And you might also call it the "PC Engine
SuperGrafx", but I decided to leave off the prefix so it appears more
distinct.
byuu says:
Changelog:
- I caved on the `samples[] = {0.0}` thing, but I'm very unhappy about it
- if it's really invalid C++, then GCC needs to stop accepting it
in strict `-std=c++14` mode
- Emulator::Interface::Information::resettable is gone
- Emulator::Interface::reset() is gone
- FC, SFC, MD cores updated to remove soft reset behavior
- split GameBoy::Interface into GameBoyInterface,
GameBoyColorInterface
- split WonderSwan::Interface into WonderSwanInterface,
WonderSwanColorInterface
- PCE: fixed off-by-one scanline error [hex_usr]
- PCE: temporary hack to prevent crashing when VDS is set to < 2
- hiro: Cocoa: removed (u)int(#) constants; converted (u)int(#)
types to (u)int_(#)t types
- icarus: replaced usage of unique with strip instead (so we don't
mess up frameworks on macOS)
- libco: added macOS-specific section marker [Ryphecha]
So ... the major news this time is the removal of the soft reset
behavior. This is a major!! change that results in a 100KiB diff file,
and it's very prone to accidental mistakes!! If anyone is up for
testing, or even better -- looking over the code changes between v102r01
and v102r02 and looking for any issues, please do so. Ideally we'll want
to test every NES mapper type and every SNES coprocessor type by loading
said games and power cycling to make sure the games are all cleanly
resetting. It's too big of a change for me to cover there not being any
issues on my own, but this is truly critical code, so yeah ... please
help if you can.
We technically lose a bit of hardware documentation here. The soft reset
events do all kinds of interesting things in all kinds of different
chips -- or at least they do on the SNES. This is obviously not ideal.
But in the process of removing these portions of code, I found a few
mistakes I had made previously. It simplifies resetting the system state
a lot when not trying to have all the power() functions call the reset()
functions to share partial functionality.
In the future, the goal will be to come up with a way to add back in the
soft reset behavior via keyboard binding as with the Master System core.
What's going to have to happen is that the key binding will have to send
a "reset pulse" to every emulated chip, and those chips are going to
have to act independently to power() instead of reusing functionality.
We'll get there eventually, but there's many things of vastly greater
importance to work on right now, so it'll be a while. The information
isn't lost ... we'll just have to pull it out of v102 when we are ready.
Note that I left the SNES reset vector simulation code in, even though
it's not possible to trigger, for the time being.
Also ... the Super Game Boy core is still disconnected. To be honest, it
totally slipped my mind when I released v102 that it wasn't connected
again yet. This one's going to be pretty tricky to be honest. I'm
thinking about making a third GameBoy::Interface class just for SGB, and
coming up with some way of bypassing platform-> calls when in this
mode.
byuu says:
Changelog:
- MS, MD, PCE: remove controllers from scheduler in destructor
[hex_usr]
- PCE: no controller should return all bits set (still causing errant
key presses when swapping gamepads)
- PCE: emulate MDR for hardware I/O $0800-$17ff
- PCE: change video resolution to 1140x242
- PCE: added tertiary background Vscroll register (secondary cache)
- PCE: create classes out of VDC VRAM, SATB, CRAM for cleaner access
and I/O registers
- PCE: high bits of CRAM read should be set
- PCE: partially emulated VCE display registers: color frequency, HDS,
HDW, VDS, VDW
- PCE: 32-width sprites now split to two 16-width sprites to handle
overflow properly
- PCE: hopefully emulated sprite zero hit correctly (it's not well
documented, and not often used)
- PCE: trigger line coincidence interrupts during the previous
scanline's Hblank period
- tomoko: raise viewport from 320x240 to 326x242 to accommodate PC
Engine's max resolution
- nall: workaround for Clang compilation bug that can't figure out
that a char is an integral data type
byuu says (in the public announcement):
This release adds very preliminary emulation of the Sega Master System
(Mark III), Sega Game Gear, Sega Mega Drive (Genesis), and NEC PC Engine
(Turbografx-16). These cores do not yet offer sound emulation, save
states or cheat codes.
I'm always very hesitant to release a new emulation core in its alpha
stages, as in the past this has resulted in lasting bad impressions
of cores that have since improved greatly. For instance, the Game Boy
Advance emulation offered today is easily the second most accurate around,
yet it is still widely judged by its much older alpha implementation.
However, it's always been tradition with higan to not hold onto code
in secret. Rather than delay future releases for another year or two,
I'll put my faith in you all to understand that the emulation of these
systems will improve over time.
I hope that by releasing things as they are now, I might be able to
receive some much needed assistance in improving these cores, as the
documentation for these new systems is very much less than ideal.
byuu says (in the WIP forum):
Changelog:
- PCE: latch background scroll registers (fixes Neutopia scrolling)
- PCE: clip background attribute table scrolling (fixes Blazing Lazers
scrolling)
- PCE: support background/sprite enable/disable bits
- PCE: fix large sprite indexing (fixes Blazing Lazers title screen
sprites)
- HuC6280: wrap zeropage accesses to never go beyond $20xx
- HuC6280: fix alternating addresses for block move instructions
(fixes Neutopia II)
- HuC6280: block move instructions save and restore A,X,Y registers
- HuC6280: emulate BCD mode (may not be 100% correct, based on SNES
BCD) (fixes Blazing Lazers scoring)
byuu says:
Changelog:
- PCE: added 384KB HuCard ROM mirroring mode
- PCE: corrected D-pad polling order
- PCE: corrected palette color ordering (GRB, not RGB -- yes,
seriously)
- PCE: corrected SATB DMA -- should write to SATB, not to VRAM
- PCE: broke out Background, Sprite VDC settings to separate
subclasses
- PCE: emulated VDC backgrounds
- PCE: emulated VDC sprites
- PCE: emulated VDC sprite overflow, collision interrupts
- HuC6280: fixed disassembler output for STi instructions
- HuC6280: added missing LastCycle check to interrupt()
- HuC6280: fixed BIT, CMP, CPX, CPY, TRB, TSB, TST flag testing and
result
- HuC6280: added extra cycle delays to the block move instructions
- HuC6280: fixed ordering for flag set/clear instructions (happens
after LastCycle check)
- HuC6280: removed extra cycle from immediate instructions
- HuC6280: fixed indirectLoad, indirectYStore absolute addressing
- HuC6280: fixed BBR, BBS zeropage value testing
- HuC6280: fixed stack push/pull direction
Neutopia looks okay until the main title screen, then there's some
gibberish on the bottom. The game also locks up with some gibberish once
you actually start a new game. So, still not playable just yet =(
byuu says:
Changelog:
- PCE: emulated gamepad polling
- PCE: emulated CPU interrupt sources
- PCE: emulated timer
- PCE: smarter emulation of ST0,ST1,ST2 instructions
- PCE: better structuring of CPU, VDP IO registers
- PCE: connected palette generation to the interface
- PCE: emulated basic VDC timing
- PCE: emulated VDC Vblank, Coincidence, and DMA completion IRQs
- PCE: emulated VRAM, SATB DMA transfers
- PCE: emulated VDC I/O registers
Everything I've implemented today likely has lots of bugs, and is
untested for obvious reasons.
So basically, after I fix many horrendous bugs, it should now be
possible to implement the VDC and start getting graphical output.
byuu says:
Changelog:
- PCE: HuC6280 core completed
There's bound to be a countless stream of bugs, and the cycle counts are
almost certainly not exact yet, but ... all instructions are implemented.
So at this point, I can start comparing trace logs against Mednafen's
debugger output.
Of course, we're very likely to immediately slam into a wall of needing
I/O registers implemented for the VDC in order to proceed further.
byuu says:
Changelog:
- SMS: fixed controller connection bug
- SMS: fixed Z80 reset bug
- PCE: emulated HuC6280 MMU
- PCE: emulated HuC6280 RAM
- PCE: emulated HuCard ROM reading
- PCE: implemented 178 instructions
- tomoko: removed "soft reset" functionality
- tomoko: moved "power cycle" to just above "unload" option
I'm not sure of the exact number of HuC6280 instructions, but it's less
than 260.
Many of the ones I skipped are HuC6280-originals that I don't know how
to emulate just yet.
I'm also really unsure about the zero page stuff. I believe we should be
adding 0x2000 to the addresses to hit page 1, which is supposed to be
mapped to the zero page (RAM). But when I look at turboEMU's source, I
have no clue how the hell it could possibly be doing that. It looks to
be reading from page 0, which is almost always ROM, which would be ...
really weird.
I also don't know if I've emulated the T mode opcodes correctly or not.
The documentation on them is really confusing.
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.
byuu says:
Changelog:
- SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd)
- SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics)
- Z80: emulated "ex (sp),hl" instruction
- Z80: fixed INx NF (should be set instead of cleared)
- Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes
walking in Wonder Boy)
- SFC: removed Debugger and sfc/debugger.hpp
- icarus: connected MS, GG, MD importing to the scan dialog
- PCE: added emulation skeleton to higan and icarus
At this point, Master System games are fairly highly compatible, sans
audio. Game Gear games are running, but I need to crop the resolution
and support the higher color palette that they can utilize. It's really
something else the way they handled the resolution shrink on that thing.
The last change is obviously going to be the biggest news.
I'm very well aware it's not an ideal time to start on a new emulation
core, with the MS and MD cores only just now coming to life with no
audio support.
But, for whatever reason, my heart's really set on working on the PC
Engine. I wanted to write the final higan skeleton core, and get things
ready so that whenever I'm in the mood to work on the PCE, I can do so.
The skeleton is far and away the most tedious and obnoxious part of the
emulator development, because it's basically all just lots of
boilerplate templated code, lots of new files to create, etc.
I really don't know how things are going to proceed ... but I can say
with 99.9% certainty that this will be the final brand new core ever
added to higan -- at least one written by me, that is. This was
basically the last system from my childhood that I ever cared about.
It's the last 2D system with games that I really enjoy playing. No other
system is worth dividing my efforts and reducing the quality and amount
of time to work on the systems I have.
In the future, there will be potential for FDS, Mega CD and PCE-CD
support. But those will all be add-ons, and they'll all be really
difficult and challenge the entire design of higan's UI (it's entirely
cartridge-driven at this time.) None of them will be entirely new cores
like this one.
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
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
byuu says:
Changelog:
- SMS: emulated the generic Sega memory mapper (none of the more
limited forms of it yet)
- (missing ROM shift, ROM write enable emulation -- no commercial
games use either, though)
- SMS: bus I/O returns 0xff instead of 0x00 so games don't think every
key is being pressed at once
- (this is a hack until I implement proper controller pad reading)
- SMS: very limited protection against reading/writing past the end of
ROM/RAM (todo: should mirror)
- SMS: VDP background HSCROLL subtracts, rather than adds, to the
offset (unlike VSCROLL)
- SMS: VDP VSCROLL is 9-bit, modulates voffset+vscroll to 224 in
192-line mode (32x28 tilemap)
- SMS: VDP tiledata for backgrounds and sprites use `7-(x&7)` rather
than `(x&7)`
- SMS: fix output color to be 6-bit rather than 5-bit
- SMS: left clip uses register `#7`, not palette color `#7`
- (todo: do we want `color[reg7]` or `color[16 + reg7]`?)
- SMS: refined handling of 0xcb, 0xed prefixes in the Z80 core and its
disassembler
- SMS: emulated (0xfd, 0xdd) 0xcb opcodes 0x00-0x0f (still missing
0x10-0xff)
- SMS: fixed 0xcb 0b-----110 opcodes to use direct HL and never allow
(IX,IY)+d
- SMS: fixed major logic bug in (IX,IY)+d displacement
- (was using `read(x)` instead of `operand()` for the displacement
byte fetch before)
- icarus: fake there always being 32KiB of RAM in all SMS cartridges
for the time being
- (not sure how to detect this stuff yet; although I've read it's
not even really possible `>_>`)
TODO: remove processor/z80/dissassembler.cpp code block at line 396 (as it's unnecessary.)
Lots of commercial games are starting to show trashed graphical output now.
byuu says:
Changelog:
- Makefile: added $(windres), -lpthread to Windows port
- GBA: WAITCNT.prefetch is not writable (should fix Donkey Kong: King
of Swing) \[endrift\]
- SMS: fixed hcounter shift value \[hex\_usr\]
- SMS: emulated interrupts (reset button isn't hooked up anywhere, not
sure where to put it yet)
This WIP actually took a really long time because the documentation on
SMS interrupts was all over the place. I'm hoping I've emulated them
correctly, but I honestly have no idea. It's based off my best
understanding from four or five different sources. So it's probably
quite buggy.
However, a few interrupts fire in Sonic the Hedgehog, so that's
something to start with. Now I just have to hope I've gotten some games
far enough in that I can start seeing some data in the VDP VRAM. I need
that before I can start emulating graphics mode 4 to get some actual
screen output.
Or I can just say to hell with it and use a "Hello World" test ROM.
That'd probably be smarter.
byuu says:
Changelog:
- SMS: extended bus mapping of in/out ports: now decoding them fully
inside ms/bus
- SMS: moved Z80 disassembly code from processor/z80 to ms/cpu
(cosmetic)
- SMS: hooked up non-functional silent PSG sample generation, so I can
cap the framerate at 60fps
- SMS: hooked up the VDP main loop: 684 clocks/scanline, 262
scanlines/frame (no PAL support yet)
- SMS: emulated the VDP Vcounter and Hcounter polling ... hopefully
it's right, as it's very bizarre
- SMS: emulated VDP in/out ports (data read, data write, status read,
control write, register write)
- SMS: decoding and caching all VDP register flags (variable names
will probably change)
- nall: \#undef IN on Windows port (prevent compilation warning on
processor/z80)
Watching Sonic the Hedgehog, I can definitely see some VDP register
writes going through, which is a good sign.
Probably the big thing that's needed before I can get enough into the
VDP to start showing graphics is interrupt support. And interrupts are
never fun to figure out :/
What really sucks on this front is I'm flying blind on the Z80 CPU core.
Without a working VDP, I can't run any Z80 test ROMs to look for CPU
bugs. And the CPU is certainly too buggy still to run said test ROM
anyway. I can't find any SMS emulators with trace logging from reset.
Such logs vastly accelerate tracking down CPU logic bugs, so without
them, it's going to take a lot longer.
byuu says:
This is a really tiny WIP. Just wanted to add the known fixes before I start debugging it against Mednafen in a fork.
Changelog:
- Z80: fixed flag calculations on 8-bit ADC, ADD, SBC, SUB
- Z80: fixed flag calculations on 16-bit ADD
- Z80: simplified DAA logic \[AWJ\]
- Z80: RETI sets IFF1=IFF2 (same as RETN)
byuu says:
Changelog:
- Z80: emulated 83 new instructions
- Z80: timing improvements
DAA is a skeleton implementation to complete the normal opcode set. Also
worth noting that I don't know exactly what the hell RETI is doing,
so for now it acts like RET. RETN probably needs some special handling
besides just setting IFF1=IFF2 as well.
I'm now missing 24 ED-prefix instructions, plus DAA, for a total of 25
opcodes remaining. And then, of course, several weeks worth of debugging
all of the inevitable bugs in the core.
byuu says:
Changelog:
- added \~130 new PAL games to icarus (courtesy of Smarthuman
and aquaman)
- added all three Korean-localized games to icarus
- sfc: removed SuperDisc emulation (it was going nowhere)
- sfc: fixed MSU1 regression where the play/repeat flags were not
being cleared on track select
- nall: cryptography support added; will be used to sign future
databases (validation will always be optional)
- minor shims to fix compilation issues due to nall changes
The real magic is that we now have 25-30% of the PAL SNES library in
icarus!
Signing will be tricky. Obviously if I put the public key inside the
higan archive, then all anyone has to do is change that public key for
their own releases. And if you download from my site (which is now over
HTTPS), then you don't need the signing to verify integrity. I may just
put the public key on my site on my site and leave it at that, we'll
see.
byuu says:
Changelog:
- added 30 new PAL games to icarus (courtesy of Mikerochip)
- new version of libco no longer requires mprotect nor W|X permissions
- nall: default C compiler to -std=c11 instead of -std=c99
- nall: use `-fno-strict-aliasing` during compilation
- updated nall/certificates (hopefully for the last time)
- updated nall/http to newer coding conventions
- nall: improve handling of range() function
I didn't really work on higan at all, this is mostly just a release
because lots of other things have changed.
The most interesting is `-fno-strict-aliasing` ... basically, it joins
`-fwrapv` as being "stop the GCC developers from doing *really* evil
shit that could lead to security vulnerabilities or instabilities."
For the most part, it's a ~2% speed penalty for higan. Except for the
Sega Genesis, where it's a ~10% speedup. I have no idea how that's
possible, but clearly something's going very wrong with strict aliasing
on the Genesis core.
So ... it is what it is. If you need the performance for the non-Genesis
cores, you can turn it off in your builds. But I'm getting quite sick of
C++'s "surprises" and clever compiler developers, so I'm keeping it on
in all of my software going forward.
byuu says:
Changelog:
- Z80: added most opcodes between 0x00 and 0x3f (two or three hard
ones missing still)
- Z80: redid register declaration *again* to handle AF', BC', DE',
HL' (ugggggh, the fuck? Alternate registers??)
- basically, using `#define <register name>` values to get around
horrendously awful naming syntax
- Z80: improved handling of displace() so that it won't ever trigger
on (BC) or (DE)
byuu says:
Changelog:
- Z80: implemented 113 new instructions (all the easy
LD/ADC/ADD/AND/OR/SBC/SUB/XOR ones)
- Z80: used alternative to castable<To, With> type (manual cast inside
instruction() register macros)
- Z80: debugger: used register macros to reduce typing and increase
readability
- Z80: debugger: smarter way of handling multiple DD/FD prefixes
(using gotos, yay!)
- ruby: fixed crash with Windows input driver on exit (from SuperMikeMan)
I have no idea how the P/V flag is supposed to work on AND/OR/XOR, so
that's probably wrong for now. HALT is also mostly a dummy function for
now. But I typically implement those inside instruction(), so it
probably won't need to be changed? We'll see.
byuu says:
Changelog:
- added (poorly-named) castable<To, With> template
- Z80 debugger rewritten to make declaring instructions much simpler
- Z80 has more instructions implemented; supports displacement on
(IX), (IY) now
- added `Processor::M68K::Bus` to mirror `Processor::Z80::Bus`
- it does add a pointer indirection; so I'm not sure if I want to
do this for all of my emulator cores ...
byuu says:
Changelog:
- rewrote the Z80 core to properly handle 0xDD (IX0 and 0xFD (IY)
prefixes
- added Processor::Z80::Bus as a new type of abstraction
- all of the instructions implemented have their proper T-cycle counts
now
- added nall/certificates for my public keys
The goal of `Processor::Z80::Bus` is to simulate the opcode fetches being
2-read + 2-wait states; operand+regular reads/writes being 3-read. For
now, this puts the cycle counts inside the CPU core. At the moment, I
can't think of any CPU core where this wouldn't be appropriate. But it's
certainly possible that such a case exists. So this may not be the
perfect solution.
The reason for having it be a subclass of Processor::Z80 instead of
virtual functions for the MasterSystem::CPU core to define is due to
naming conflicts. I wanted the core to say `in(addr)` and have it take
the four clocks. But I also wanted a version of the function that didn't
consume time when called. One way to do that would be for the core to
call `Z80::in(addr)`, which then calls the regular `in(addr)` that goes to
`MasterSystem::CPU::in(addr)`. But I don't want to put the `Z80::`
prefix on all of the opcodes. Very easy to forget it, and then end up not
consuming any time. Another is to use uglier names in the
`MasterSystem::CPU` core, like `read_`, `write_`, `in_`, `out_`, etc. But,
yuck.
So ... yeah, this is an experiment. We'll see how it goes.
byuu says:
Changelog:
- MS: added ms/bus
- Z80: implemented JP/JR/CP/DI/IM/IN instructions
- MD/VDP: added window layer emulation
- MD/controller/gamepad: fixed d2,d3 bits (Altered Beast requires
this)
The Z80 is definitely a lot nastier than the LR35902. There's a lot of
table duplication with HL→IX→IY; and two of them nest two levels deep
(eg FD CB xx xx), so the design may change as I implement more.
byuu says:
Changelog:
- new md/bus/ module for bus reads/writes
- abstracts byte/word accesses wherever possible (everything but
RAM; forces all but I/O to word, I/O to byte)
- holds the system RAM since that's technically not part of the
CPU anyway
- added md/controller and md/system/peripherals
- added emulation of gamepads
- added stub PSG audio output (silent) to cap the framerate at 60fps
with audio sync enabled
- fixed VSRAM reads for plane vertical scrolling (two bugs here: add
instead of sub; interlave plane A/B)
- mask nametable read offsets (can't exceed 8192-byte nametables
apparently)
- emulated VRAM/VSRAM/CRAM reads from VDP data port
- fixed sprite width/height size calculations
- added partial emulation of 40-tile per scanline limitation (enough
to fix Sonic's title screen)
- fixed off-by-one sprite range testing
- fixed sprite tile indexing
- Vblank happens at Y=224 with overscan disabled
- unsure what happens when you toggle it between Y=224 and Y=240
... probably bad things
- fixed reading of address register for ADDA, CMPA, SUBA
- fixed sign extension for MOVEA effect address reads
- updated MOVEM to increment the read addresses (but not writeback)
for (aN) mode
With all of that out of the way, we finally have Sonic the Hedgehog
(fully?) playable. I played to stage 1-2 and through the special stage,
at least. EDIT: yeah, we probably need HIRQs for Labyrinth Zone.
Not much else works, of course. Most games hang waiting on the Z80, and
those that don't (like Altered Beast) are still royally screwed. Tons of
features still missing; including all of the Z80/PSG/YM2612.
A note on the perihperals this time around: the Mega Drive EXT port is
basically identical to the regular controller ports. So unlike with the
Famicom and Super Famicom, I'm inheriting the exension port from the
controller class.
byuu says:
Changelog:
- 68K: fixed NEG/NEGX operand order
- 68K: fixed bug in disassembler that was breaking trace logging
- VDP: improved sprite rendering (still 100% broken)
- VDP: added horizontal/vertical scrolling (90% broken)
Forgot:
- 68K: fix extension word sign bit on indexed modes for disassembler
as well
- 68K: emulate STOP properly (use r.stop flag; clear on IRQs firing)
I'm really wearing out fast here. The Genesis documentation is somehow
even worse than Game Boy documentation, but this is a far more complex
system.
It's a massive time sink to sit here banging away at every possible
combination of how things could work, only to see no positive
improvements. Nothing I do seems to get sprites to do a goddamn thing.
squee says the sprite Y field is 10-bits, X field is 9-bits. genvdp says
they're both 10-bits. BlastEm treats them like they're both 10-bits,
then masks off the upper bit so it's effectively 9-bits anyway.
Nothing ever bothers to tell you whether the horizontal scroll values
are supposed to add or subtract from the current X position. Probably
the most basic detail you could imagine for explaining horizontal
scrolling and yet ... nope. Nothing.
I can't even begin to understand how the VDP FIFO functionality works,
or what the fuck is meant by "slots".
I'm completely at a loss as how how in the holy hell the 68K works with
8-bit accesses. I don't know whether I need byte/word handlers for every
device, or if I can just hook it right into the 68K core itself. This
one's probably the most major design detail. I need to know this before
I go and implement the PSG/YM2612/IO ports-\>gamepads/Z80/etc.
Trying to debug the 68K is murder because basically every game likes to
start with a 20,000,000-instruction reset phase of checksumming entire
games, and clearing out the memory as agonizingly slowly as humanly
possible. And like the ARM, there's too many registers so I'd need three
widescreen monitors to comfortably view the entire debugger output lines
onscreen.
I can't get any test ROMs to debug functionality outside of full games
because every **goddamned** test ROM coder thinks it's acceptable to tell
people to go fetch some toolchain from a link that died in the late '90s
and only works on MS-DOS 6.22 to build their fucking shit, because god
forbid you include a 32KiB assembled ROM image in your fucking archives.
... I may have to take a break for a while. We'll see.
byuu says:
Changelog:
- 68K: MOVEQ is 8-bit signed
- 68K: disassembler was print EOR for OR instructions
- 68K: address/program-counter indexed mode had the signed-word/long
bit backward
- 68K: ADDQ/SUBQ #n,aN always works in long mode; regardless of size
- 68K→VDP DMA needs to use `mode.bit(0)<<22|dmaSource`; increment by
one instead of two
- Z80: added registers and initial two instructions
- MS: hooked up enough to load and start running games
- Sonic the Hedgehog can execute exactly one instruction... whoo.
byuu says:
Sorry, two WIPs in one day. Got excited and couldn't wait.
Changelog:
- ADDQ, SUBQ shouldn't update flags when targeting an address register
- ADDA should sign extend effective address reads
- JSR was pushing the PC too early
- some improvements to 8-bit register reads on the VDP (still needs
work)
- added H/V counter reads to the VDP IO port region
- icarus: added support for importing Master System and Game Gear ROMs
- tomoko: added library sub-menus for each manufacturer
- still need to sort Game Gear after Mega Drive somehow ...
The sub-menu system actually isn't all that bad. It is indeed a bit more
annoying, but not as annoying as I thought it was going to be. However,
it looks a hell of a lot nicer now.
byuu says:
Added VDP sprite rendering. Can't get any games far enough in to see if
it actually works. So in other words, it doesn't work at all and is 100%
completely broken.
Also added 68K exceptions and interrupts. So far only the VDP interrupt
is present. It definitely seems to be firing in commercial games, so
that's promising. But the implementation is almost certainly completely
wrong. There is fuck all of nothing for documentation on how interrupts
actually work. I had to find out the interrupt vector numbers from
reading the comments from the Sonic the Hedgehog disassembly. I have
literally no fucking clue what I0-I2 (3-bit integer priority value in
the status register) is supposed to do. I know that Vblank=6, Hblank=4,
Ext(gamepad)=2. I know that at reset, SR.I=7. I don't know if I'm
supposed to block interrupts when I is >, >=, <, <= to the interrupt
level. I don't know what level CPU exceptions are supposed to be.
Also implemented VDP regular DMA. No idea if it works correctly since
none of the commercial games run far enough to use it. So again, it's
horribly broken for usre.
Also improved VDP fill mode. But I don't understand how it takes
byte-lengths when the bus is 16-bit. The transfer times indicate it's
actually transferring at the same speed as the 68K->VDP copy, strongly
suggesting it's actually doing 16-bit transfers at a time. In which case,
what happens when you set an odd transfer length?
Also, both DMA modes can now target VRAM, VSRAM, CRAM. Supposedly there's
all kinds of weird shit going on when you target VSRAM, CRAM with VDP
fill/copy modes, but whatever. Get to that later.
Also implemented a very lazy preliminary wait mechanism to to stall out
a processor while another processor exerts control over the bus. This
one's going to be a major work in progress. For one, it totally breaks
the model I use to do save states with libco. For another, I don't
know if a 68K->VDP DMA instantly locks the CPU, or if it the CPU could
actually keep running if it was executing out of RAM when it started
the DMA transfer from ROM (eg it's a bus busy stall, not a hard chip
stall.) That'll greatly change how I handle the waiting.
Also, the OSS driver now supports Audio::Latency. Sound should be
even lower latency now. On FreeBSD when set to 0ms, it's absolutely
incredible. Cannot detect latency whatsoever. The Mario jump sound seems
to happen at the very instant I hear my cherry blue keyswitch activate.
byuu says:
I reworked the video sizing code. Ended up wasting five fucking hours
fighting GTK. When you call `gtk_widget_set_size_request`, it doesn't
actually happen then. This is kind of a big deal because when I then go
to draw onto the viewport, the actual viewport child window is still the
old size, so the image gets distorted. It recovers in a frame or so with
emulation, but if we were to put a still image on there, it would stay
distorted.
The first thought is, `while(gtk_events_pending())
gtk_main_iteration_do(false);` right after the `set_size_request`. But
nope, it tells you there's no events pending. So then you think, go
deeper, use `XPending()` instead. Same thing, GTK hasn't actually issued
the command to Xlib yet. So then you think, if the widget is realized,
just call a blocking `gtk_main_iteration`. One call does nothing, two
calls results in a deadlock on the second one ... do it before program
startup, and the main window will never appear. Great.
Oh, and it's not just the viewport. It's also the widget container area
of the windows, as well as the window itself, as well as the fullscreen
mode toggle effect. They all do this.
For the latter three, I couldn't find anything that worked, so I just
added 20ms loops of constantly calling `gtk_main_iteration_do(false)`
after each one of those things. The downside here is toggling the status
bar takes 40ms, so you'll see it and it'll feel a tiny bit sluggish.
But I can't have a 20ms wait on each widget resize, that would be
catastrophic to performance on windows with lots of widgets.
I tried hooking configure-event and size-allocate, but they were very
unreliable. So instead I ended up with a loop that waits up to a maximm
of 20ms that inspects the `widget->allocation.(width,height)` values
directly and waits for them to be what we asked for with
`set_size_request`.
There was some extreme ugliness in GTK with calling
`gtk_main_iteration_do` recursively (`hiro::Widget::setGeometry` is
called recursively), so I had to lock it to only happen on the top level
widgets (the child ones should get resized while waiting on the
top-level ones, so it should be fine in practice), and also only run it
on realized widgets.
Even still, I'm getting ~3 timeouts when opening the settings dialog in
higan, but no other windows. But, this is the best I can do for now.
And the reason for all of this pain? Yeah, updated the video code.
So the Emulator::Interface now has this:
struct VideoSize { uint width, height; }; //or requiem for a tuple
auto videoSize() -> VideoSize;
auto videoSize(uint width, uint height, bool arc) -> VideoSize;
The first function, for now, is just returning the literal surface size.
I may remove this ... one thing I want to allow for is cores that send
different texture sizes based on interlace/hires/overscan/etc settings.
The second function is more interesting. Instead of having the UI trying
to figure out sizing, I figure the emulation cores can do a better job
and we can customize it per-core now. So it gets the window's width and
height, and whether the user asked for aspect correction, and then
computes the best width/height ratio possible. For now they're all just
doing multiples of a 1x scale to the UI 2x,3x,4x modes.
We still need a third function, which will probably be what I repurpose
videoSize() for: to return the 'effective' size for pixel shaders, to
then feed into ruby, to then feed into quark, to then feed into our
shaders. Since shaders use normalized coordinates for pixel fetching,
this should work out just fine. The real texture size will be exposed to
quark shaders as well, of course.
Now for the main window ... it's just hard-coded to be 640x480, 960x720,
1280x960 for now. It works nicely for some cores on some modes, not so
much for others. Work in progress I guess.
I also took the opportunity to draw the about dialog box logo on the
main window. Got a bit fancy and used the old spherical gradient and
impose functionality of nall/image on it. Very minor highlight, nothing
garish. Just something nicer than a solid black window.
If you guys want to mess around with sizes, placements, and gradient
styles/colors/shapes ... feel free. If you come up with something nicer,
do share.
That's what led to all the GTK hell ... the logo wasn't drawing right as
you resized the window. But now it is, though I am not at all happy with
the hacking I had to do.
I also had to improve the video update code as a result of this:
- when you unload a game, it blacks out the screen
- if you are not quitting the emulator, it'll draw the logo; if
you are, it won't
- when you load a game, it black out the logo
These options prevent any unsightliness from resizing the viewport with
image data on it already
I need to redraw the logo when toggling fullscreen with no game loaded
as well for Windows, it seems.
byuu says:
Changelog:
- 68K: fixed bug that affected BSR return address
- VDP: added very preliminary emulation of planes A, B, W (W is
entirely broken though)
- VDP: added command/address stuff so you can write to VRAM, CRAM,
VSRAM
- VDP: added VRAM fill DMA
I would be really surprised if any commercial games showed anything at
all, so I'd probably recommend against wasting your time trying, unless
you're really bored :P
Also, I wanted to add: I am accepting patches\! So if anyone wants to
look over the 68K core for bugs, that would save me untold amounts of
time in the near future :D
byuu says:
Changelog:
- pulled the (u)intN type aliases into higan instead of leaving them
in nall
- added 68K LINEA, LINEF hooks for illegal instructions
- filled the rest of the 68K lambda table with generic instance of
ILLEGAL
- completed the 68K disassembler effective addressing modes
- still unsure whether I should use An to decode absolute
addresses or not
- pro: way easier to read where accesses are taking place
- con: requires An to be valid; so as a disassembler it does a
poor job
- making it optional: too much work; ick
- added I/O decoding for the VDP command-port registers
- added skeleton timing to all five processor cores
- output at 1280x480 (needed for mixed 256/320 widths; and to handle
interlace modes)
The VDP, PSG, Z80, YM2612 are all stepping one clock at a time and
syncing; which is the pathological worst case for libco. But they also
have no logic inside of them. With all the above, I'm averaging around
250fps with just the 68K core actually functional, and the VDP doing a
dumb "draw white pixels" loop. Still way too early to tell how this
emulator is going to perform.
Also, the 320x240 mode of the Genesis means that we don't need an aspect
correction ratio. But we do need to ensure the output window is a
multiple 320x240 so that the scale values work correctly. I was
hard-coding aspect correction to stretch the window an additional \*8/7.
But that won't work anymore so ... the main higan window is now 640x480,
960x720, or 1280x960. Toggling aspect correction only changes the video
width inside the window.
It's a bit jarring ... the window is a lot wider, more black space now
for most modes. But for now, it is what it is.
byuu says:
The 68K core now implements all 88 instructions. It ended up being 111
instructions in my core due to splitting up opcodes with the same name
but different addressing modes or directions (removes conditions at the
expense of more code.)
Technically, I don't have exceptions actually implemented yet, and
RESET/STOP don't do anything but set flags. So there's still more to
go. But ... close enough for statistics time!
The M68K core source code is 124,712 bytes in size. The next largest
core is the ARM7 core at 70,203 bytes in size.
The M68K object size is 942KiB; with the next largest being the V30MZ
core at 173KiB.
There are a total of 19,656 invalid opcodes in the 68000 revision (unless
of course I've made mistakes in my mappings, which is very probably.)
Now the fun part ... figuring out how to fix bugs in this core without
VDP emulation :/
byuu says:
Changelog:
- Emulator: use `(uintmax)-1 >> 1` for the units of time
- MD: implemented 13 new 68K instructions (basically all of the
remaining easy ones); 21 remain
- nall: replaced `(u)intmax_t` (64-bit) with *actual* `(u)intmax` type
(128-bit where available)
- this extends to everything: atoi, string, etc. You can even
print 128-bit variables if you like
22,552 opcodes still don't exist in the 68K map. Looking like quite a
few entries will be blank once I finish.
byuu says:
Changelog:
- added eight more 68K instructions
- split ADD(direction) into two separate ADD functions
I now have 54 out of 88 instructions implemented (thus, 34 remaining.)
The map is missing 25,182 entries out of 65,536. Down from 32,680 for
v101.00
Aside: this version number feels really silly. r10 and r11 surely will
as well ...
byuu says (in the public announcement):
Not a large changelog this time, sorry. This release is mostly to fix
the SA-1 issue, and to get some real-world testing of the new scheduler
model. Most of the work in the past month has gone into writing a 68000
CPU core; yet it's still only about half-way finished.
Changelog (since the previous release):
- fixed SNES SA-1 IRQ regression (fixes Super Mario RPG level-up
screen)
- new scheduler for all emulator cores (precision of 2^-127)
- icarus database adds nine new SNES games
- added Input/Frequency to settings file (allows simulation of
latency)
byuu says (in the WIP forum):
Changelog:
- in 32-bit mode, Thread uses uint64\_t with 2^-63 time units (10^-7
precision in the worst case)
- nearly ten times the precision of an attosecond
- in 64-bit mode, Thread uses uint128\_t with 2^-127 time units
(10^-26 precision in the worst case)
- far more accurate than yoctoseconds; almost closing in on planck
time
Note: a quartz crystal is accurate to 10^-4 or 10^-5. A cesium fountain
atomic clock is accurate to 10^-15. So ... yeah. 2^-63 was perfectly
fine; but there was no speed penalty whatsoever for using uint128\_t in
64-bit mode, so why not?
byuu says:
(Windows users may need to include <sys/time.h> at the top of
nall/chrono.hpp, not sure.)
Unchangelog:
- forgot to add the Scheduler clock=0 fix because I have the memory of
a goldfish
Changelog:
- new icarus database with nine additional games
- hiro(GTK,Qt) won't constantly write its settings.bml file to disk
anymore
- added latency simulator for fun (settings.bml => Input/Latency in
milliseconds)
So the last one ... I wanted to test out nall::chrono, and I was also
thinking that by polling every emulated frame, it's pretty wasteful when
you are using Fast Forward and hitting 200+fps. As I've said before,
calls to ruby::input::poll are not cheap.
So to get around this, I added a limiter so that if you called the
hardware poll function within N milliseconds, it'll return without
doing any actual work. And indeed, that increases my framerate of Zelda
3 uncapped from 133fps to 142fps. Yay. But it's not a "real" speedup,
as it only helps you when you exceed 100% speed (theoretically, you'd
need to crack 300% speed since the game itself will poll at 16ms at 100%
speed, but yet it sped up Zelda 3, so who am I to complain?)
I threw the latency value into the settings file. It should be 16,
but I set it to 5 since that was the lowest before it started negatively
impacting uncapped speeds. You're wasting your time and CPU cycles setting
it lower than 5, but if people like placebo effects it might work. Maybe
I should let it be a signed integer so people can set it to -16 and think
it's actually faster :P (I'm only joking. I took out the 96000hz audio
placebo effect as well. Not really into psychological tricks anymore.)
But yeah seriously, I didn't do this to start this discussion again for
the billionth time. Please don't go there. And please don't tell me this
WIP has higher/lower latency than before. I don't want to hear it.
The only reason I bring it up is for the fun part that is worth
discussing: put up or shut up time on how sensitive you are to
latency! You can set the value above 5 to see how games feel.
I personally can't really tell a difference until about 50. And I can't
be 100% confident it's worse until about 75. But ... when I set it to
150, games become "extra difficult" ... the higher it goes, the worse
it gets :D
For this WIP, I've left no upper limit cap. I'll probably set a cap of
something like 500ms or 1000ms for the official release. Need to balance
user error/trolling with enjoyability. I'll think about it.
[...]
Now, what I worry about is stupid people seeing it and thinking it's an
"added latency" setting, as if anyone would intentionally make things
worse by default. This is a limiter. So if 5ms have passed since the
game last polled, and that will be the case 99.9% of the time in games,
the next poll will happen just in time, immediately when the game polls
the inputs. Thus, a value below 1/<framerate>ms is not only pointless,
if you go too low it will ruin your fast forward max speeds.
I did say I didn't want to resort to placebo tricks, but I also don't
want to spark up public discussion on this again either. So it might
be best to default Input/Latency to 0ms, and internally have a max(5,
latency) wrapper around the value.
byuu wrote:
Aforementioned scheduler changes added. Longer explanation of why here:
http://hastebin.com/raw/toxedenece
Again, we really need to test this as thoroughly as possible for
regressions :/
This is a really major change that affects absolutely everything: all
emulation cores, all coprocessors, etc.
Also added ADDX and SUB to the 68K core, which brings us just barely
above 50% of the instruction encoding space completed.
[Editor's note: The "aformentioned scheduler changes" were described in
a previous forum post:
Unfortunately, 64-bits just wasn't enough precision (we were
getting misalignments ~230 times a second on 21/24MHz clocks), so
I had to move to 128-bit counters. This of course doesn't exist on
32-bit architectures (and probably not on all 64-bit ones either),
so for now ... higan's only going to compile on 64-bit machines
until we figure something out. Maybe we offer a "lower precision"
fallback for machines that lack uint128_t or something. Using the
booth algorithm would be way too slow.
Anyway, the precision is now 2^-96, which is roughly 10^-29. That
puts us far beyond the yoctosecond. Suck it, MAME :P I'm jokingly
referring to it as the byuusecond. The other 32-bits of precision
allows a 1Hz clock to run up to one full second before all clocks
need to be normalized to prevent overflow.
I fixed a serious wobbling issue where I was using clock > other.clock
for synchronization instead of clock >= other.clock; and also another
aliasing issue when two threads share a common frequency, but don't
run in lock-step. The latter I don't even fully understand, but I
did observe it in testing.
nall/serialization.hpp has been extended to support 128-bit integers,
but without explicitly naming them (yay generic code), so nall will
still compile on 32-bit platforms for all other applications.
Speed is basically a wash now. FC's a bit slower, SFC's a bit faster.
The "longer explanation" in the linked hastebin is:
Okay, so the idea is that we can have an arbitrary number of
oscillators. Take the SNES:
- CPU/PPU clock = 21477272.727272hz
- SMP/DSP clock = 24576000hz
- Cartridge DSP1 clock = 8000000hz
- Cartridge MSU1 clock = 44100hz
- Controller Port 1 modem controller clock = 57600hz
- Controller Port 2 barcode battler clock = 115200hz
- Expansion Port exercise bike clock = 192000hz
Is this a pathological case? Of course it is, but it's possible. The
first four do exist in the wild already: see Rockman X2 MSU1
patch. Manifest files with higan let you specify any frequency you
want for any component.
The old trick higan used was to hold an int64 counter for each
thread:thread synchronization, and adjust it like so:
- if thread A steps X clocks; then clock += X * threadB.frequency
- if clock >= 0; switch to threadB
- if thread B steps X clocks; then clock -= X * threadA.frequency
- if clock < 0; switch to threadA
But there are also system configurations where one processor has to
synchronize with more than one other processor. Take the Genesis:
- the 68K has to sync with the Z80 and PSG and YM2612 and VDP
- the Z80 has to sync with the 68K and PSG and YM2612
- the PSG has to sync with the 68K and Z80 and YM2612
Now I could do this by having an int64 clock value for every
association. But these clock values would have to be outside the
individual Thread class objects, and we would have to update every
relationship's clock value. So the 68K would have to update the Z80,
PSG, YM2612 and VDP clocks. That's four expensive 64-bit multiply-adds
per clock step event instead of one.
As such, we have to account for both possibilities. The only way to
do this is with a single time base. We do this like so:
- setup: scalar = timeBase / frequency
- step: clock += scalar * clocks
Once per second, we look at every thread, find the smallest clock
value. Then subtract that value from all threads. This prevents the
clock counters from overflowing.
Unfortunately, these oscillator values are psychotic, unpredictable,
and often times repeating fractions. Even with a timeBase of
1,000,000,000,000,000,000 (one attosecond); we get rounding errors
every ~16,300 synchronizations. Specifically, this happens with a CPU
running at 21477273hz (rounded) and SMP running at 24576000hz. That
may be good enough for most emulators, but ... you know how I am.
Plus, even at the attosecond level, we're really pushing against the
limits of 64-bit integers. Given the reciprocal inverse, a frequency
of 1Hz (which does exist in higan!) would have a scalar that consumes
1/18th of the entire range of a uint64 on every single step. Yes, I
could raise the frequency, and then step by that amount, I know. But
I don't want to have weird gotchas like that in the scheduler core.
Until I increase the accuracy to about 100 times greater than a
yoctosecond, the rounding errors are too great. And since the only
choice above 64-bit values is 128-bit values; we might as well use
all the extra headroom. 2^-96 as a timebase gives me the ability to
have both a 1Hz and 4GHz clock; and run them both for a full second;
before an overflow event would occur.
Another hastebin includes demonstration code:
#include <libco/libco.h>
#include <nall/nall.hpp>
using namespace nall;
//
cothread_t mainThread = nullptr;
const uint iterations = 100'000'000;
const uint cpuFreq = 21477272.727272 + 0.5;
const uint smpFreq = 24576000.000000 + 0.5;
const uint cpuStep = 4;
const uint smpStep = 5;
//
struct ThreadA {
cothread_t handle = nullptr;
uint64 frequency = 0;
int64 clock = 0;
auto create(auto (*entrypoint)() -> void, uint frequency) {
this->handle = co_create(65536, entrypoint);
this->frequency = frequency;
this->clock = 0;
}
};
struct CPUA : ThreadA {
static auto Enter() -> void;
auto main() -> void;
CPUA() { create(&CPUA::Enter, cpuFreq); }
} cpuA;
struct SMPA : ThreadA {
static auto Enter() -> void;
auto main() -> void;
SMPA() { create(&SMPA::Enter, smpFreq); }
} smpA;
uint8 queueA[iterations];
uint offsetA;
cothread_t resumeA = cpuA.handle;
auto EnterA() -> void {
offsetA = 0;
co_switch(resumeA);
}
auto QueueA(uint value) -> void {
queueA[offsetA++] = value;
if(offsetA >= iterations) {
resumeA = co_active();
co_switch(mainThread);
}
}
auto CPUA::Enter() -> void { while(true) cpuA.main(); }
auto CPUA::main() -> void {
QueueA(1);
smpA.clock -= cpuStep * smpA.frequency;
if(smpA.clock < 0) co_switch(smpA.handle);
}
auto SMPA::Enter() -> void { while(true) smpA.main(); }
auto SMPA::main() -> void {
QueueA(2);
smpA.clock += smpStep * cpuA.frequency;
if(smpA.clock >= 0) co_switch(cpuA.handle);
}
//
struct ThreadB {
cothread_t handle = nullptr;
uint128_t scalar = 0;
uint128_t clock = 0;
auto print128(uint128_t value) {
string s;
while(value) {
s.append((char)('0' + value % 10));
value /= 10;
}
s.reverse();
print(s, "\n");
}
//femtosecond (10^15) = 16306
//attosecond (10^18) = 688838
//zeptosecond (10^21) = 13712691
//yoctosecond (10^24) = 13712691 (hitting a dead-end on a rounding error causing a wobble)
//byuusecond? ( 2^96) = (perfect? 79,228 times more precise than a yoctosecond)
auto create(auto (*entrypoint)() -> void, uint128_t frequency) {
this->handle = co_create(65536, entrypoint);
uint128_t unitOfTime = 1;
//for(uint n : range(29)) unitOfTime *= 10;
unitOfTime <<= 96; //2^96 time units ...
this->scalar = unitOfTime / frequency;
print128(this->scalar);
this->clock = 0;
}
auto step(uint128_t clocks) -> void { clock += clocks * scalar; }
auto synchronize(ThreadB& thread) -> void { if(clock >= thread.clock) co_switch(thread.handle); }
};
struct CPUB : ThreadB {
static auto Enter() -> void;
auto main() -> void;
CPUB() { create(&CPUB::Enter, cpuFreq); }
} cpuB;
struct SMPB : ThreadB {
static auto Enter() -> void;
auto main() -> void;
SMPB() { create(&SMPB::Enter, smpFreq); clock = 1; }
} smpB;
auto correct() -> void {
auto minimum = min(cpuB.clock, smpB.clock);
cpuB.clock -= minimum;
smpB.clock -= minimum;
}
uint8 queueB[iterations];
uint offsetB;
cothread_t resumeB = cpuB.handle;
auto EnterB() -> void {
correct();
offsetB = 0;
co_switch(resumeB);
}
auto QueueB(uint value) -> void {
queueB[offsetB++] = value;
if(offsetB >= iterations) {
resumeB = co_active();
co_switch(mainThread);
}
}
auto CPUB::Enter() -> void { while(true) cpuB.main(); }
auto CPUB::main() -> void {
QueueB(1);
step(cpuStep);
synchronize(smpB);
}
auto SMPB::Enter() -> void { while(true) smpB.main(); }
auto SMPB::main() -> void {
QueueB(2);
step(smpStep);
synchronize(cpuB);
}
//
#include <nall/main.hpp>
auto nall::main(string_vector) -> void {
mainThread = co_active();
uint masterCounter = 0;
while(true) {
print(masterCounter++, " ...\n");
auto A = clock();
EnterA();
auto B = clock();
print((double)(B - A) / CLOCKS_PER_SEC, "s\n");
auto C = clock();
EnterB();
auto D = clock();
print((double)(D - C) / CLOCKS_PER_SEC, "s\n");
for(uint n : range(iterations)) {
if(queueA[n] != queueB[n]) return print("fail at ", n, "\n");
}
}
}
...and that's everything.]
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.
byuu says:
All of the above fixes, plus I added all 24 variations on the shift
opcodes, plus SUBQ, plus fixes to the BCC instruction.
I can now run 851,767 instructions into Sonic the Hedgehog before hitting
an unimplemented instruction (SUB).
The 68K core is probably only ~35% complete, and yet it's already within
4KiB of being the largest CPU core, code size wise, in all of higan. Fuck
this chip.
byuu says:
I split the Register class and read/write handlers into DataRegister and
AddressRegister, given that they have different behaviors on byte/word
accesses (data tends to preserve the upper bits; address tends to
sign-extend things.)
I expanded EA to EffectiveAddress. No sense in abbreviating things
to death.
I've now implemented 26 instructions. But the new ones are just all the
stupid from/to ccr/sr instructions.
Ryphecha confirmed that you can't set the undefined bits, so I don't
think the BitField concept is appropriate for the CCR/SR. Instead, I'm
just storing direct flags and have (read,write)(CCR,SR) instead. This
isn't like the 65816 where you have subroutines that push and pop the
flag register. It's much more common to access individual flags. Doesn't
match the consistency angle of the other CPU cores, but ... I think this
is the right thing to for the 68K specifically.
byuu says:
Redesigned the handling of reading/writing registers to be about eight
times faster than the old system. More work may be needed ... it seems
data registers tend to preserve their upper bits upon assignment; whereas
address registers tend to sign-extend values into them. It may make
sense to have DataRegister and AddressRegister classes with separate
read/write handlers. I'd have to hold two Register objects inside the
EffectiveAddress (EA) class if we do that.
Implemented 19 opcodes now (out of somewhere between 60 and 90.) That gets
the first ~530,000 instructions in Sonic the Hedgehog running (though
probably wrong. But we can run a lot thanks to large initialization
loops.)
If I force the core to loop back to the reset vector on an invalid opcode,
I'm getting about 1500fps with a dumb 320x240 blit 60 times a second and
just the 68K running alone (no Z80, PSG, VDP, YM2612.) I don't know if
that's good or not. I guess we'll find out.
I had to stop tonight because the final opcode I execute is an RTS
(return from subroutine) that's branching back to address 0; which is
invalid ... meaning something went terribly wrong and the system crashed.
byuu says:
Another six hours in ...
I have all of the opcodes, memory access functions, disassembler mnemonics
and table building converted over to the new template<uint Size> format.
Certainly, it would be quite easy for this nightmare chip to throw me
another curveball, but so far I can handle:
- MOVE (EA to, EA from) case
- read(from) has to update register index for +/-(aN) mode
- MOVEM (EA from) case
- when using +/-(aN), RA can't actually be updated until the transfer
is completed
- LEA (EA from) case
- doesn't actually perform the final read; just returns the address
to be read from
- ANDI (EA from-and-to) case
- same EA has to be read from and written to
- for -(aN), the read has to come from aN-2, but can't update aN yet;
so that the write also goes to aN-2
- no opcode can ever fetch the extension words more than once
- manually control the order of extension word fetching order for proper
opcode decoding
To do all of that without a whole lot of duplicated code (or really
bloating out every single instruction with red tape), I had to bring
back the "bool valid / uint32 address" variables inside the EA struct =(
If weird exceptions creep in like timing constraints only on certain
opcodes, I can use template flags to the EA read/write functions to
handle that.
byuu says:
Six and a half hours this time ... one new opcode, and all old opcodes
now in a deprecated format. Hooray, progress!
For building the table, I've decided to move from:
for(uint opcode : range(65536)) {
if(match(...)) bind(opNAME, ...);
}
To instead having separate for loops for each supported opcode. This
lets me specialize parts I want with templates.
And to this aim, I'm moving to replace all of the
(read,write)(size, ...) functions with (read,write)<Size>(...) functions.
This will amount to the ~70ish instructions being triplicated ot ~210ish
instructions; but I think this is really important.
When I was getting into flag calculations, a ton of conditionals
were needed to mask sizes to byte/word/long. There was also lots of
conditionals in all the memory access handlers.
The template code is ugly, but we eliminate a huge amount of branch
conditions this way.
byuu says:
Four and a half hours of work and ... zero new opcodes implemented.
This was the best job I could do refining the effective address
computations. Should have all twelve 68000 modes implemented now. Still
have a billion questions about when and how I'm supposed to perform
certain edge case operations, though.
byuu says:
Up to ten 68K instructions out of somewhere between 61 and 88, depending
upon which PDF you look at. Of course, some of them aren't 100% completed
yet, either. Lots of craziness with MOVEM, and BCC has a BSR variant
that needs stack push/pop functions.
This WIP actually took over eight hours to make, going through every
possible permutation on how to design the core itself. The updated design
now builds both the instruction decoder+dispatcher and the disassembler
decoder into the same main loop during M68K's constructor.
The special cases are also really psychotic on this processor, and
I'm afraid of missing something via the fallthrough cases. So instead,
I'm ordering the instructions alphabetically, and including exclusion
cases to ignore binding invalid cases. If I end up remapping an existing
register, then it'll throw a run-time assertion at program startup.
I wanted very much to get rid of struct EA (EffectiveAddress), but
it's too difficult to keep track of the internal effective address
without it. So I split out the size to a separate parameter, since
every opcode only has one size parameter, and otherwise it was getting
duplicated in opcodes that take two EAs, and was also awkward with the
flag testing. It's a bit more typing, but I feel it's more clean this way.
Overall, I'm really worried this is going to be too slow. I don't want
to turn the EA stuff into templates, because that will massively bloat
out compilation times and object sizes, and will also need a special DSL
preprocessor since C++ doesn't have a static for loop. I can definitely
optimize a lot of EA's address/read/write functions away once the core
is completed, but it's never going to hold a candle to a templatized
68K core.
----
Forgot to include the SA-1 regression fix. I always remember immediately
after I upload and archive the WIP. Will try to get that in next time,
I guess.
byuu says:
Alright, I'm definitely going to need to find some people willing to
tolerate my questions on this chip, so I'm going to go ahead and announce
I'm working on this I guess.
This core is way too big for a surprise like the NES and WS cores
were. It'll probably even span multiple v10x releases before it's
even ready.
byuu says:
I now have enough of three instructions implemented to get through the
first four instructions in Sonic the Hedgehog.
But they're far from complete. The very first instruction uses EA
addressing, which is similar to x86's ModRM in terms of how disgustingly
complex it is. And it also accesses Z80 control registers, which obviously
isn't going to do anything yet.
The slow speed was me being stupid again. It's not 7.6MHz per frame,
it's 7.67MHz per second. So yeah, speed is so far acceptable again. But
we'll see how things go as I keep emulating more. The 68K decode is not
pretty at all.
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.
byuu says:
Sigh ... I'm really not a good person. I'm inherently selfish.
My responsibility and obligation right now is to work on loki, and
then on the Tengai Makyou Zero translation, and then on improving the
Famicom emulation.
And yet ... it's not what I really want to do. That shouldn't matter;
I should work on my responsibilities first.
Instead, I'm going to be a greedy, self-centered asshole, and work on
what I really want to instead.
I'm really sorry, guys. I'm sure this will make a few people happy,
and probably upset even more people.
I'm also making zero guarantees that this ever gets finished. As always,
I wish I could keep these things secret, so if I fail / give up, I could
just drop it with no shame. But I would have to cut everyone out of the
WIP process completely to make it happen. So, here goes ...
This WIP adds the initial skeleton for Sega Mega Drive / Genesis
emulation. God help us.
(minor note: apparently the new extension for Mega Drive games is .md,
neat. That's what I chose for the folders too. I thought it was .smd,
so that'll be fixed in icarus for the next WIP.)
(aside: this is why I wanted to get v100 out. I didn't want this code in
a skeleton state in v100's source. Nor did I want really broken emulation,
which the first release is sure to be, tarring said release.)
...
So, basically, I've been ruminating on the legacy I want to leave behind
with higan. 3D systems are just plain out. I'm never going to support
them. They're too complex for my abilities, and they would run too slowly
with my design style. I'm not willing to compromise my design ideals. And
I would never want to play a 3D game system at native 240p/480i resolution
... but 1080p+ upscaling is not accurate, so that's a conflict I want
to avoid entirely. It's also never going to emulate computer systems
(X68K, PC-98, FM-Towns, etc) because holy shit that would completely
destroy me. It's also never going emulate arcade machines.
So I think of higan as a collection of 2D emulators for consoles
and handhelds. I've gone over every major 2D gaming system there is,
looking for ones with games I actually care about and enjoy. And I
basically have five of those systems supported already. Looking at the
remaining list, I see only three systems left that I have any interest
in whatsoever: PC-Engine, Master System, Mega Drive. Again, I'm not in
any way committing to emulating any of these, but ... if I had all of
those in higan, I think I'd be content to really, truly, finally stop
writing more emulators for the rest of my life.
And so I decided to tackle the most difficult system first. If I'm
successful, the Z80 core should cover a lot of the work on the SMS. And
the HuC6280 should land somewhere between the NES and SNES in terms of
difficulty ... closer to the NES.
The systems that just don't appeal to me at all, which I will never touch,
include, but are not limited to:
* Atari 2600/5200/7800
* Lynx
* Jaguar
* Vectrex
* Colecovision
* Commodore 64
* Neo-Geo
* Neo-Geo Pocket / Color
* Virtual Boy
* Super A'can
* 32X
* CD-i
* etc, etc, etc.
And really, even if something were mildly interesting in there ... we
have to stop. I can't scale infinitely. I'm already way past my limit,
but I'm doing this anyway. Too many cores bloats everything and kills
quality on everything. I don't want higan to become MESS v2.
I don't know what I'll do about the Famicom Disk System, PC-Engine CD,
and Mega CD. I don't think I'll be able to achieve 60fps emulating the
Mega CD, even if I tried to.
I don't know what's going to happen here with even the Mega Drive. Maybe
I'll get driven crazy with the documentation and quit. Maybe it'll end
up being too complicated and I'll quit. Maybe the emulation will end up
way too slow and I'll give up. Maybe it'll take me seven years to get
any games playable at all. Maybe Steve Snake, AamirM and Mike Pavone
will pool money to hire a hitman to come after me. Who knows.
But this is what I want to do, so ... here goes nothing.
[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)
byuu says:
higan has finally reached v100!
I feel it's important to stress right away that this is not "version
1.00", nor is it a major milestone release. Rather than arbitrary version
numbers, all of my software simply bumps version numbers by one for each
official release. As such, higan v100 is simply higan's 100th release.
That said, the primary focus of this release has been code
clean-ups. These are always somewhat dangerous in that regressions are
possible. We've tested through sixteen WIP revisions, one of which was
open to the public, to try and minimize any regressions. But all the same,
please report any regressions if you discover any.
Changelog (since v099):
FC: render during pixels 1-256 instead of 0-255 [hex_usr]
FC: rewrote controller emulation code
SFC: 8% speedup over the previous release thanks to PPU optimizations
SFC: fixed nasty DB address wrapping regression from v099
SFC: USART developer controller removed; superseded by 21fx
SFC: Super Multitap option removed from controller port 1; ports
renamed 2-5
SFC: hidden option to experiment with 128KB VRAM (strictly for novelty)
higan: audio volume no longer divided by number of audio streams
higan: updated controller polling code to fix possible future mapping
issues
higan: replaced nall/stream with nall/vfs for file-loading subsystem
tomoko: can now load multi-slotted games via command-line
tomoko: synchronize video removed from UI; still available in the
settings file
tomoko, icarus: can navigate to root drive selection on Windows
all: major code cleanups and refactoring (~1MB diff against v099)
Note 1: the audio volume change means that SGB and MSU1 games won't
lose half the volume on the SNES sounds anymore. However, if one goes
overboard and drives the sound all the way to max volume with the MSU1,
clamping may occur. The obvious solution is not to drive volume that high
(it will vastly overpower the SNES audio, which usually never exceeds
25% volume.) Another option is to lower the volume in the audio settings
panel to 50%. In general, neither is likely to ever be necessary.
Note 2: the synchronize video option was hidden from the UI because it
is no longer useful. With the advent of compositors, the loss of the
complicated timing settings panel, support for the WonderSwan and its
75hz display, the need to emulate variable refresh rate behaviors in the
Game Boy, the unfortunate latency spike and audio distortion caused by
long Vsync pauses, and the arrival of adaptive sync technology ... it
no longer makes sense to present this option. However, as stated, you
can edit settings.bml to enable this option anyway if you insist and
understand the aforementioned risks.
Changelog (since v099r16 open beta):
- fixed MSU1 audio sign extension
- fixed compilation with SGB support disabled
- icarus can now navigate to root directory
- fixed compilation issues with OS X port
- (hopefully) fixed label height issue with hiro that affected icarus
import dialog
- (mostly) fixed BS Memory, Sufami Turbo slot loading
Errata:
- forgot to remove the " - Slot A", " - Slot B" suffixes for Sufami
Turbo slot loading
- this means you have to navigate up one folder and then into Sufami
Turbo/ to load games for this system
- moving WonderSwan orientation controls to the device slot is causing
some nastiness
- can now select orientation from the main menu, but it doesn't rotate
the display
byuu says:
Changelog:
- hiro: BrowserDialog can navigate up to drive selection on Windows
- nall: (file,path,dir,base,prefix,suffix)name =>
Location::(file,path,dir,base,prefix,suffix)
- higan/tomoko: rename audio filter label from "Sinc" to "IIR - Biquad"
- higan/tomoko: allow loading files via icarus on the command-line
once again
- higan/tomoko: (begrudging) quick hack to fix presentation window focus
on startup
- higan/audio: don't divide output audio volume by number of streams
- processor/r65816: fix a regression in (read,write)DB; fixes Taz-Mania
- fixed compilation regressions on Windows and Linux
I'm happy with where we are at with code cleanups and stability, so I'd
like to release v100. But even though I'm not assigning any special
significance to this version, we should probably test it more thoroughly
first.
byuu says:
Changelog:
- nall::lstring -> nall::string_vector
- added IntegerBitField<type, lo, hi> -- hopefully it works correctly...
- Multitap 1-4 -> Super Multitap 2-5
- fixed SFC PPU CGRAM read regression
- huge amounts of SFC PPU IO register cleanups -- .bits really is lovely
- re-added the read/write(VRAM,OAM,CGRAM) helpers for the SFC PPU
- but they're now optimized to the realities of the PPU (16-bit data
sizes / no address parameter / where appropriate)
- basically used to get the active-display overrides in a unified place;
but also reduces duplicate code in (read,write)IO
byuu says:
Changelog:
- (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel
like they were contributing enough to be worth it]
- cleaned up nall::integer,natural,real functionality
- toInteger, toNatural, toReal for parsing strings to numbers
- fromInteger, fromNatural, fromReal for creating strings from numbers
- (string,Markup::Node,SQL-based-classes)::(integer,natural,real)
left unchanged
- template<typename T> numeral(T value, long padding, char padchar)
-> string for print() formatting
- deduces integer,natural,real based on T ... cast the value if you
want to override
- there still exists binary,octal,hex,pointer for explicit print()
formatting
- lstring -> string_vector [but using lstring = string_vector; is
declared]
- would be nice to remove the using lstring eventually ... but that'd
probably require 10,000 lines of changes >_>
- format -> string_format [no using here; format was too ambiguous]
- using integer = Integer<sizeof(int)*8>; and using natural =
Natural<sizeof(uint)*8>; declared
- for consistency with boolean. These three are meant for creating
zero-initialized values implicitly (various uses)
- R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees
up struct IO {} io; naming]
- SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {}
(status,registers); now
- still some CPU::Status status values ... they didn't really fit into
IO functionality ... will have to think about this more
- SFC CPU, PPU, SMP now use step() exclusively instead of addClocks()
calling into step()
- SFC CPU joypad1_bits, joypad2_bits were unused; killed them
- SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it
- SFC PPU OAM moved into PPU::Object; since nothing else uses it
- the raw uint8[544] array is gone. OAM::read() constructs values from
the OAM::Object[512] table now
- this avoids having to determine how we want to sub-divide the two
OAM memory sections
- this also eliminates the OAM::synchronize() functionality
- probably more I'm forgetting
The FPS fluctuations are driving me insane. This WIP went from 128fps to
137fps. Settled on 133.5fps for the final build. But nothing I changed
should have affected performance at all. This level of fluctuation makes
it damn near impossible to know whether I'm speeding things up or slowing
things down with changes.
byuu says:
Changelog:
- GB core code cleanup completed
- GBA core code cleanup completed
- some more cleanup on missed processor/arm functions/variables
- fixed FC loading icarus bug
- "Load ROM File" icarus functionality restored
- minor code unification efforts all around (not perfect yet)
- MMIO->IO
- mmio.cpp->io.cpp
- read,write->readIO,writeIO
It's been a very long work in progress ... starting all the way back with
v094r09, but the major part of the higan code cleanup is now completed! Of
course, it's very important to note that this is only for the basic style:
- under_score functions and variables are now camelCase
- return-type function-name() are now auto function-name() -> return-type
- Natural<T>/Integer<T> replace (u)intT_n types where possible
- signed/unsigned are now int/uint
- most of the x==true,x==false tests changed to x,!x
A lot of spot improvements to consistency, simplicity and quality have
gone in along the way, of course. But we'll probably never fully finishing
beautifying every last line of code in the entire codebase. Still,
this is a really great start. Going forward, WIP diffs should start
being smaller and of higher quality once again.
I know the joke is, "until my coding style changes again", but ... this
was way too stressful, way too time consuming, and way too risky. I'm
too old and tired now for extreme upheavel like this again. The only
major change I'm slowly mulling over would be renaming the using
Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as
easily confused with the (u)int_t types ... but we'll see. I'll definitely
continue to change small things all the time, but for the larger picture,
I need to just accept the style I have and live with it.
byuu says:
Changelog:
- fixed FC AxROM / VRC7 regression
- BitField split to BooleanBitField/NaturalBitField (in preparation
for IntegerBitField)
- BitFieldReference removed
- GB CPU cleaned up
- GB Cartridge + Mappers cleaned up
- SFC CGRAM is now emulated as uint15[256] instead of uint[512]
- sfc/ppu/memory.cpp no longer needed; removed
- purged SFC Debugger hooks for now (some of the operator[] calls were
bypassing them anyway)
Unfortunately, for reasons that defy all semblance of logic, the CGRAM
change caused a slight speed hit. As have the last few changes. We're
now down to around 129.5fps compared to 123.fps for v099 and 134.5fps
at our peak (v099r01-r02).
I really like the style I came up with for the Game Boy mappers to settle
the purpose(ROM,RAM) vs (rom,ram)Purpose naming convention. If I ever get
around to redoing the NES mappers, that's likely the approach I'll take.
byuu says:
Changelog:
- NES PPU core updated to use BitFields (absolutely massive improvement
in code readability)
- NES APU core updated to new coding style
- NES cartridge/board and cartridge/chip updated to new coding style
- pushed NES PPU rendering one dot forward (doesn't fix King's Quest V
yet, sadly)
- fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's
Island, though)
So ... I kind of went overboard with the fc/cartridge changes. This WIP
diff is 185KiB >_>
I didn't realize it was going to be as big a task as it was, but once
I started everything broke in a chain reaction, so I had to do it all
at once.
There's a massive chance we've broken a bunch of NES things. Any typos
in this WIP are going to be absolutely insidious to track down =(
But ... supposing I pulled it off, this means the Famicom core is now
fully converted to the new coding style as well. That leaves only the
GB and GBA cores. Once those are finished, then we'll finally be free
of these gigantic hellspawn diffs.
byuu says:
Changelog:
- higan/profile/ => higan/systems/ [temporary; unless we can't think of
a better base folder name]
- god-damn-better-have fixed the input polling bug
- re-added command-line and drag-and-drop loading
- command-line loading can now load multiple folders at once (SGB+GB
game; Sufami Turbo+Slot A+Slot B; etc)
- if you load just the base cart, it'll present you with a dialog to
optionally load slotted cart(s)
- MSU1 now goes through nall/vfs instead of directly accessing the
filesystem
- Famicom Cartridge, PPU cores updated to newer programming style
- there's countless opportunity for BitField and .bits() in the PPU
... but I'm worried about breaking things
If anyone has a working MSU1 game and can test the changes out, that'd
be appreciated. I still don't have a test ROM on my dev box.
I wouldn't worry too much about extensively testing the Famicom PPU
changes just yet ... I'm still struggling with what to name the structs
inside the classes between all of my emulators, and the BitField/.bits()
changes will be much more important to test at a later date.
The only use case left for Emulator::Interface::path(uint id) is for
21fx emulation. This peripheral loads a DLL/SO via LoadLibrary/dlopen,
which do not have any official ways to open a file in RAM. I'm
very hesitant to use the portable trick of writing the memory to a
temporary file, loading it, and deleting the temporary file once done
... it's a real waste of disk activity. I might make something like
vfs::file::isVirtual->bool,path()->string to get around this. But even
once I do, the underlying LoadLibrary/dlopen call is still going to be
direct disk access.
byuu says:
Changelog:
- Emulator::Interface::Medium::bootable removed
- Emulator::Interface::load(bool required) argument removed
[File::Required makes no sense on a folder]
- Super Famicom.sys now has user-configurable properties (CPU,PPU1,PPU2
version; PPU1 VRAM size, Region override)
- old nall/property removed completely
- volatile flags supported on coprocessor RAM files now (still not in
icarus, though)
- (hopefully) fixed SNES Multitap support (needs testing)
- fixed an OAM tiledata range clipping limit in 128KiB VRAM mode (doesn't
fix Yoshi's Island, sadly)
- (hopefully, again) fixed the input polling bug hex_usr reported
- re-added dialog box for when File::Required files are missing
- really cool: if you're missing a boot ROM, BIOS ROM, or IPL ROM,
it warns you immediately
- you don't have to select a game before seeing the error message
anymore
- fixed cheats.bml load/save location
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
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.
byuu says:
Changelog:
- Super Famicom core converted to use nall/vfs
- excludes Super Game Boy; since that's invoked from inside the GB core
This was definitely the major obstacle to test nall/vfs'
applicability. Things worked out pretty great in the end.
We went from 22.0KiB (cartridge) + 18.6KiB (interface) to 24.5KiB
(cartridge) + 11.4KiB (interface). Or 40.7KiB to 36.0KiB. This removes
a very large source of indirection. Before it was: "coprocessor <=>
cartridge <=> interface" for loading and saving data, and now it's just
"coprocessor <=> cartridge". And it may make sense to eventually turn
this into just "cartridge -> coprocessor" by making each coprocessor
class handle its own markup parsing.
It's nice to have all the manifest parsing in one location (well, sans
MSU1); but it's also nice for loading/unloading to be handled by each
coprocessor itself. So I'll have to think longer about that one.
I've also started handling Interface::save() differently. Instead of
keeping track of memory IDs and filenames, and iterating through that
vector of objects ... instead I now have a system that mirrors the markup
parsing on loading, but handles saving instead. This was actually the
reason the code size savings weren't more significant, but I like this
style more. As before, it removes an extra level of indirection.
So ... next up, I need to port over the GB, then GBA, then WS
cores. These shouldn't take too long since they're all very simple with
just ROM+RAM(+RTC) right now. Then get the SGB callbacks using vfs. Then
after that, gut all the old stream stuff from nall and higan. Kill the
(load,save)Request stuff, rename the load(Gamepak)Request to something
simpler, and then we should be good.
Anyway ... these are some huge changes.
byuu says:
Changelog:
- lots of code cleanups to processor/r6502 (the switch.cpp file is only
halfway done ...)
- lots of code cleanups to fc/cpu
- removed fc/input
- implemented fc/controller
hex_usr, you may not like this, but I want to keep the controller port
and expansion port interface separate, like I do with the SNES. I realize
the NES' is used more for controllers, and the SNES' more for hardware
expansions, but ... they're not compatible pinouts and you can't really
connect one to the other.
Right now, I've only implemented the controller portion. I'll have to
get to the peripheral portion later.
Also, the gamepad implementation there now may be wrong. It's based off
the Super Famicom version obviously. I'm not sure if the Famicom has
different behavior with latching $4016 writes, or not. But, it works in
Mega Man II, so it's a start.
Everyone, be sure to remap your controls, and then set port 1 -> gamepad
after loading your first Famicom game with the new WIP.
byuu says:
Changelog:
- finished cleaning up the SFC core to my new coding conventions
- removed sfc/controller/usart (superseded by 21fx)
- hid Synchronize Video option from the menu (still in the configuration
file)
Pretty much the only minor detail left is some variable names in the
SA-1 core that really won't look good at all if I move to camelCase,
so I'll have to rethink how I handle those. It's probably a good area
to attempt using BitFields, to see how it impacts performance. But I'll
do that in a test branch first.
But for the most part, this should be the end of the gigantic diffs (this
one was 174KiB), at least for the SFC/WS cores. Still have the FC/GB/GBA
cores to clean up more fully. Assuming we don't spot any new regressions,
we should be ~95% out of the woods on code cleanups breaking things.
byuu says:
Changelog:
- massive cleanups and optimizations on the PPU core
- ~9% speedup over v099 official
This is pretty much it for the low-hanging fruit of speeding up higan. Any
more gains from this point will be extremely hard-fought, unfortunately.
byuu says:
Time for a new release. There are a few important emulation improvements
and a few new features; but for the most part, this release focuses on
major code refactoring, the details of which I will mostly spare you.
The major change is that, as of v099, the SNES balanced and performance
cores have been removed from higan. Basically, in addition to my five
other emulation cores, these were too much of a burden to maintain. And
they've come along as far as I was able to develop them. If you need to
use these cores, please use these two from the v098 release.
I'm very well aware that ~80% of the people using higan for SNES
emulation were using the two removed profiles. But they simply had
to go. Hopefully in the future, we can compensate for their loss by
increasing the performance of the accuracy core.
Changelog (since v098):
SFC: balanced profile removed
SFC: performance profile removed
SFC: expansion port devices can now be changed during gameplay (atlhough
you shouldn't)
SFC: fixed bug in SharpRTC leap year calculations
SFC: emulated new research findings for the S-DD1 coprocessor
SFC: fixed CPU emulation-mode wrapping bug with pei, [dp], [dp]+y
instructions [AWJ]
SFC: fixed Super Game Boy bug that caused the bottom tile-row to flicker
in games
GB: added MBC1M (multi-cart) mapper; icarus can't detect these so manual
manifests are needed for now
GB: corrected return value when HuC3 unmapped RAM is read; fixes Robopon
[endrift]
GB: improved STAT IRQ emulation; fixes Altered Space, etc [endrift,
gekkio]
GB: partial emulation of DMG STAT write IRQ bug; fixes Legend of Zerd,
Road Rash, etc
nall: execute() fix, for some Linux platforms that had trouble detecting
icarus
nall: new BitField class; which allows for simplifying flag/register
emulation in various cores
ruby: added Windows WASAPI audio driver (experimental)
ruby: remove attempts to call glSwapIntervalEXT (fixes crashing on some
Linux systems)
ui: timing settings panel removed
video: restored saturation, gamma, luminance settings
video: added new post-emulation sprite system; light gun cursors are
now higher-resolution
audio: new resampler (6th-order Butterworth biquad IIR); quite a bit
faster than the old one
audio: added optional basic reverb filter (for fun)
higan: refresh video outside cooperative threads (workaround for shoddy
code in AMD graphics drivers)
higan: individual emulation cores no longer have unique names
higan: really substantial code refactoring; 43% reduction in binary size
Off the bat, here are the known bugs:
hiro/Windows: focus stealing bug on startup. Needs to be fixed in hiro,
not with a cheap hack to tomoko.
higan/SFC: some of the coprocessors are saving some volatile memory to
disk. Completely harmless, but still needs to be fixed.
ruby/WASAPI: some sound cards have a lot of issues with the current driver
(eg FitzRoy's). We need to find a clean way to fix this before it
can be made the default driver. Which would be a huge win because
the latency improvements are substantial, and in exclusive mode,
WASAPI allows G-sync to work very well.
[From the v099 WIP thread, here's the changelog since v098r19:
- GB: don't force mode 1 during force-blank; fixes v098r16 regression
with many Game Boy games
- GB: only perform the STAT write IRQ bug during vblank, not hblank
(still not hardware accurate, though)
-Ed.]
byuu says:
Changelog:
- added nall/bit-field.hpp
- updated all CPU cores (sans LR35902 due to some complexities) to use
BitFields instead of bools
- updated as many CPU cores as I could to use BitFields instead of union {
struct { uint8_t ... }; }; pairs
The speed changes are mostly a wash for this. In some instances,
I noticed a ~2-3% speedup (eg SNES emulation), and in others a 2-3%
slowdown (eg Famicom emulation.) It's within the margin of error, so
it's safe to say it has no impact.
This does give us a lot of new useful things, however:
- no more manual reconstruction of flag values from lots of left shifts
and ORs
- no more manual deconstruction of flag values from lots of ANDs
- ability to get completely free aliases to flag groups (eg GSU can
provide alt2, alt1 and also alt (which is alt2,alt1 combined)
- removes the need for the nasty order_lsbN macro hack (eventually will
make higan 100% endian independent)
- saves us from insane compilers that try and do nasty things with
alignment on union-structs
- saves us from insane compilers that try to store bit-field bits in
reverse order
- will allow some really novel new use cases (I'm planning an
instant-decode ARM opcode function, for instance.)
- reduces code size (we can serialize flag registers in one line instead
of one for each flag)
However, I probably won't use it for super critical code that's constantly
reading out register values (eg PPU MMIO registers.) I think there we
would end up with a performance penalty.
byuu says:
Changelog:
- hiro: fixed the BrowserDialog column resizing when navigating to new
folders (prevents clipping of filenames)
- note: this is kind of a quick-fix; but I have a good idea how to do
the proper fix now
- nall: added BitField<T, Lo, Hi> class
- note: not yet working on the SFC CPU class; need to go at it with
a debugger to find out what's happening
- GB: emulated DMG/SGB STAT IRQ bug; fixes Zerd no Densetsu and Road Rash
(won't fix anything else; don't get hopes up)
byuu says:
Changelog:
- fixed Super Game Boy regression from v096r04 with bottom tile row
flickering
- fixed GB STAT IRQ regression from previous WIP
- Altered Space is now playable
- GBVideoPlayer isn't; but nobody seems to know exactly what weird
hardware quirk that one relies on to work
- ~3-4% speed improvement in SuperFX games by eliminating function<>
callback on register assignments
- most noticeable in Doom in-game; least noticeable on Yoshi's Island
title screen (darn)
- finished GSU core and SuperFX coprocessor code cleanups
- did some more work cleaning up the LR35902 core and GB CPU code
Just a fair warning: don't get your hopes up on these GB
fixes. Cliffhanger now hangs completely (har har), and none of the
other bugs are fixed. We pretty much did all this work just for Altered
Space. So, I hope you like playing Altered Space.
byuu says:
Changelog:
- GNUmakefile: reverted $(call unique,) to $(strip)
- processor/r6502: removed templates; reduces object size from 146.5kb
to 107.6kb
- processor/lr35902: removed templates; reduces object size from 386.2kb
to 197.4kb
- processor/spc700: merged op macros for switch table declarations
- sfc/coprocessor/sa1: partial cleanups; flattened directory structure
- sfc/coprocessor/superfx: partial cleanups; flattened directory structure
- sfc/coprocessor/icd2: flattened directory structure
- gb/ppu: changed behavior of STAT IRQs
Major caveat! The GB/GBC STAT IRQ changes has a major bug in it somewhere
that's seriously breaking most games. I'm pushing the WIP anyway, because
I believe the changes to be mostly correct. I'd like to get more people
looking at these changes, and also try more heavy-handed hacking and
diff comparison logging between the previous WIP and this one.
byuu says:
Changelog:
- removed template usage from processor/spc700; cleaned up many function
names and the switch table
- object size: 176.8kb => 127.3kb
- source code size: 43.5kb => 37.0kb
- fixed processor/r65816 BRK/COP vector regression [hex_usr]
- corrected HuC3 unmapped RAM read value; fixes Robopon [endrift]
- cosmetic: simplified the butterworth constant calculation
[Wolfram|Alpha]
The SPC700 core changes took forever, about three hours of work.
Only the LR35902 and R6502 still need their template functions
removed. The point of this is that it doesn't cause any speed penalty
to do so, and it results in smaller binary sizes and faster compilation
times.
byuu says:
Changelog:
- improved attenuation of biquad filter by computing butterworth Q
coefficients correctly (instead of using the same constant)
- adding 1e-25 to each input sample into the biquad filters to try and
prevent denormalization
- updated normalization from [0.0 to 1.0] to [-1.0 to +1.0]; volume/reverb
happen in floating-point mode now
- good amount of work to make the base Emulator::Audio support any number
of output channels
- so that we don't have to do separate work on left/right channels;
and can instead share the code for each channel
- Emulator::Interface::audioSample(int16 left, int16 right); changed to:
- Emulator::Interface::audioSample(double* samples, uint channels);
- samples are normalized [-1.0 to +1.0]
- for now at least, channels will be the value given to
Emulator::Audio::reset()
- fixed GUI crash on startup when audio driver is set to None
I'm probably going to be updating ruby to accept normalized doubles as
well; but I'm not sure if I will try and support anything other 2-channel
audio output. It'll depend on how easy it is to do so; perhaps it'll be
a per-driver setting.
The denormalization thing is fierce. If that happens, it drops the
emulator framerate from 220fps to about 20fps for Game Boy emulation. And
that happens basically whenever audio output is silent. I'm probably
also going to make a nall/denormal.hpp file at some point with
platform-specific functionality to set the CPU state to "denormals as
zero" where applicable. I'll still add the 1e-25 offset (inaudible)
as another fallback.
byuu says:
Changelog:
- nall/dsp returns with new iir/biquad.hpp and resampler/cubic.hpp files
- nall/queue.hpp added (simple ring buffer ... nall/vector wouldn't
cause too many moves with FIFO)
- audio streams now only buffer 20ms; so even if multiple audio streams
desync, latency can never exceed 20ms
- replaced blackman windwed sinc FIR hermite audio filter with transposed
direct form II biquadratic sixth-order IIR butterworth filter (better
attenuation of frequencies above 20KHz, faster, no need for decimation,
less code)
- put in experimental eight-tap echo filter (a lot better than what I
had before, but still rather weak)
- substantial cleanups to the SuperFX GSU processor core (slightly
faster, 479KB->100KB object file, 42.7KB->33.4KB source code size,
way less code duplication)
We'll definitely want to test the whole SuperFX library (not many games)
just to make sure there's no regressions caused by this one.
Not sure what I want to do with audio processing effects yet. I've always
really wanted lots of fun controls to customize audio, and now finally
with this new biquad filter, I can finally start implementing real
effects. For instance, an equalizer wouldn't be too complicated anymore.
The new reverb effect is still a poor man's version. I need to find human
readable source for implementing a comb-filter properly. I'm pretty sure
I can already treat nall::queue as an all-pass filter since all that
does is phase shift (fancy audio term for "delay audio"). What's really
going to be hard is figuring out how to expose user-friendly settings for
controlling it. It looks like you need a bunch of coprime coefficients,
and I don't think casual users are going to be able to hand-enter coprime
values to get the echo effect they want. I uh ... don't even know how
to calculate coprime values dynamically right now >_> But we're going
to have to, as they are correlated to the output sampling rate.
We'll definitely want to make some audio profiles so that users can
quickly select pre-configured themes that sound nice, but expose the
underlying coefficients so that they can tweak stuff to their liking. This
isn't just about higan, this is about me trying to learn digital signal
processing, so please don't be too upset about feature creep or anything
on this.
Anyway ... I'm having some difficulties with my audio right now. When
the reverb effect is enabled, there's a bunch of static on system
reset for just a moment. But this should not be possible. nall::queue
is initializing all previous reverb sample elements to 0.0. I don't
understand where static is coming in from. Further, we have the same
issue with both the windowed sinc and the biquad filters ... a bit of
a popping sound when starting a game. Any help tracking this down would
be appreciated.
There's also one really annoying issue ... I can't seem to do reverb
or volume adjustments with normalized samples. If I say "volume *= 0.5"
in higan/audio/audio.cpp line 68, it doesn't just halve the volume, it
adds a whole bunch of distortion. This makes absolutely zero sense to
me. The sample values are between 0.0 (mute) and 1.0 (full volume) here,
so multiplying a double by 0.5 shouldn't cause distortion. So right now,
I'm doing these adjustments with less precision after denormalizing back
to int16. Anyone ever see something like that? :/
byuu says:
Changelog:
- higan/video: added support for Emulator::Sprite
- higan/resource: a new system for accessing embedded binary files
inside the emulation cores; holds the sprites
- higan/sfc/superscope,justifier: re-enabled display of crosshairs
- higan/sfc/superscope: fixed turbo toggle (also shows different
crosshair color when in turbo mode)
- higan/sfc/ppu: always outputs at 512x480 resolution now
- causes a slight speed-hit from ~127fps to ~125fps;
- but allows high-resolution 32x32 cursors that look way better;
- also avoids the need to implement sprite scaling logic
Right now, the PPU code to always output at 480-height is a really gross
hack. Don't worry, I'll make that nicer before release.
Also, superscope.cpp and justifier.cpp are built around a 256x240
screen. But since we now have 512x480, we can make the cursor's movement
much smoother by doubling the resolution on both axes. The actual games
won't see any accuracy improvements when firing the light guns, but the
cursors will animate nicer so I think it's still worth it. I'll work on
that before the next release as well.
The current 32x32 cursors are nicer, but we can do better now with full
24-bit color. So feel free to submit alternatives. I'll probably reject
them, but you can always try :D
The sprites don't support alpha blending, just color keying (0x00000000
= transparent; anything else is 0xff......). We can revisit that later
if necessary.
The way I have it designed, the only files that do anything with
Emulator::Sprite at all are the superscope and justifier folders.
I didn't have to add any hooks anywhere else. Rendering the sprite is
a lot cleaner than the old code, too.
byuu says:
Changelog:
- fixed nall/path.hpp compilation issue
- fixed ruby/audio/xaudio header declaration compilation issue (again)
- cleaned up xaudio2.hpp file to match my coding syntax (12.5% of the
file was whitespace overkill)
- added null terminator entry to nall/windows/utf8.hpp argc[] array
- nall/windows/guid.hpp uses the Windows API for generating the GUID
- this should stop all the bug reports where two nall users were
generating GUIDs at the exact same second
- fixed hiro/cocoa compilation issue with uint# types
- fixed major higan/sfc Super Game Boy audio latency issue
- fixed higan/sfc CPU core bug with pei, [dp], [dp]+y instructions
- major cleanups to higan/processor/r65816 core
- merged emulation/native-mode opcodes
- use camel-case naming on memory.hpp functions
- simplify address masking code for memory.hpp functions
- simplify a few opcodes themselves (avoid redundant copies, etc)
- rename regs.* to r.* to match modern convention of other CPU cores
- removed device.order<> concept from Emulator::Interface
- cores will now do the translation to make the job of the UI easier
- fixed plurality naming of arrays in Emulator::Interface
- example: emulator.ports[p].devices[d].inputs[i]
- example: vector<Medium> media
- probably more surprises
Major show-stoppers to the next official release:
- we need to work on GB core improvements: LY=153/0 case, multiple STAT
IRQs case, GBC audio output regs, etc.
- we need to re-add software cursors for light guns (Super Scope,
Justifier)
- after the above, we need to fix the turbo button for the Super Scope
I really have no idea how I want to implement the light guns. Ideally,
we'd want it in higan/video, so we can support the NES Zapper with the
same code. But this isn't going to be easy, because only the SNES knows
when its output is interlaced, and its resolutions can vary as
{256,512}x{224,240,448,480} which requires pixel doubling that was
hard-coded to the SNES-specific behavior, but isn't appropriate to be
exposed in higan/video.
byuu says:
Changelog:
- fixed major nall/vector/prepend bug
- renamed hiro/ListView to hiro/TableView
- added new hiro/ListView control which is a simplified abstraction of
hiro/TableView
- updated higan's cheat database window and icarus' scan dialog to use
the new ListView control
- compilation works once again on all platforms (Windows, Cocoa, GTK,
Qt)
- the loki skeleton compiles once again (removed nall/DSP references;
updated port/device ID names)
Small catch: need to capture layout resize events internally in Windows
to call resizeColumns. For now, just resize the icarus window to get it
to use the full window width for list view items.
byuu says:
Changelog:
- nall/vector rewritten from scratch
- higan/audio uses nall/vector instead of raw pointers
- higan/sfc/coprocessor/sdd1 updated with new research information
- ruby/video/glx and ruby/video/glx2: fuck salt glXSwapIntervalEXT!
The big change here is definitely nall/vector. The Windows, OS X and Qt
ports won't compile until you change some first/last strings to
left/right, but GTK will compile.
I'd be really grateful if anyone could stress-test nall/vector. Pretty
much everything I do relies on this class. If we introduce a bug, the
worst case scenario is my entire SFC game dump database gets corrupted,
or the byuu.org server gets compromised. So it's really critical that we
test the hell out of this right now.
The S-DD1 changes mean you need to update your installation of icarus
again. Also, even though the Lunar FMV never really worked on the
accuracy core anyway (it didn't initialize the PPU properly), it really
won't work now that we emulate the hard-limit of 16MiB for S-DD1 games.
byuu says:
Changelog:
- GB: support modeSelect and RAM for MBC1M (Momotarou Collection)
- audio: implemented native resampling support into Emulator::Stream
- audio: removed nall::DSP completely
Unfortunately, the new resampler didn't turn out quite as fast as I had
hoped. The final hermite resampling added some overhead; and I had to
bump up the kernel count to 500 from 400 to get the buzzing to go away
on my main PC. I think that's due to it running at 48000hz output
instead of 44100hz output, maybe?
Compared to Ryphecha's:
(NES) Mega Man 2: 167fps -> 166fps
(GB) Mega Man II: 224fps -> 200fps
(WSC) Riviera: 143fps -> 151fps
Odd that the WS/WSC ends up faster while the DMG/CGB ends up slower.
But this knocks 922 lines down to 146 lines. The only files left in all
of higan not written (or rewritten) by me are ruby/xaudio2.h and
libco/ppc.c
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.
byuu says:
Changelog:
- WS/WSC: re-added support for screen rotation (code is inside WS core)
- ruby: changed sample(uint16_t left, uint16_t right) to sample(int16_t
left, int16_t right);
- requires casting to uint prior to shifting in each driver, but
I felt it was misleading to use uint16_t just to avoid that
- ruby: WASAPI is now built in by default; has wareya's improvements,
and now supports latency adjust
- tomoko: audio settings panel has new "Exclusive Mode" checkbox for
WASAPI driver only
- note: although the setting *does* take effect in real-time, I'd
suggest restarting the emulator after changing it
- tomoko: audio latency can now be set to 0ms (which in reality means
"the minimum supported by the driver")
- all: increased cothread size from 512KiB to 2MiB to see if it fixes
bullshit AMD driver crashes
- this appears to cause a slight speed penalty due to cache locality
going down between threads, though
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.
byuu says:
It took several hours, but I've rebuilt much of the SNES' bus memory
mapping architecture.
The new design unifies the cartridge string-based mapping
("00-3f,80-bf:8000-ffff") and internal bus.map calls. The map() function
now has an accompanying unmap() function, and instead of a fixed 256
callbacks, it'll scan to find the first available slot. unmap() will
free slots up when zero addresses reference a given slot.
The controllers and expansion port are now both entirely dynamic.
Instead of load/unload/power/reset, they only have the constructor
(power/reset/load) and destructor (unload). What this means is you can
now dynamically change even expansion port devices after the system is
loaded.
Note that this is incredibly dangerous and stupid, but ... oh well. The
whole point of this was for 21fx. There's no way to change the expansion
port device prior to loading a game, but if the 21fx isn't active, then
the reset vector hijack won't work. Now you can load a 21fx game, change
the expansion port device, and simply reset the system to active the
device.
The unification of design between controller port devices and expansion
port devices is nice, and overall this results in a reduction of code
(all of the Mapping stuff in Cartridge is gone, replaced with direct bus
mapping.) And there's always the potential to expand this system more in
the future now.
The big missing feature right now is the ability to push/pop mappings.
So if you look at how the 21fx does the reset vector, you might vomit
a little bit. But ... it works.
Also changed exit(0) to _exit(0) in the POSIX version of nall::execute.
[The _exit(0) thing is an attempt to make higan not crash when it tries
to launch icarus and it's not on $PATH. The theory is that higan forks,
then the child tries to exec icarus and fails, so it exits, all the
unique_ptrs clean up their resources and tell the X server to free
things the parent process is still using. Calling _exit() prevents
destructors from running, and seems to prevent the problem. -Ed.]
byuu says:
Changelog:
- SFC: fixed a regression on auto joypad polling due to missing
parentheses
- SFC: exported new PPU::vdisp() const -> uint; function [1]
- SFC: merged PPU MMIO functions into the read/write handles (as
I previously did for the CPU)
- higan: removed individual emulator core names (bnes, bsnes, bgb, bgba,
bws) [2] Forgot:
- to remove /tomoko from the about dialog
[1] note that technically I was relying on the cached, per-frame
overscan setting when the CPU and light guns were polling the number of
active display scanlines per frame. This was technically incorrect as
you can change this value mid-frame and it'll kick in. I've never seen
any game toggle overscan every frame, we only know about this because
anomie tested this a long time ago. So, nothing should break, but ...
you know how the SNES is. You can't even look at the code without
something breaking, so I figured I'd mention it >_>
[2] I'll probably keep referring to the SNES core as bsnes anyway.
I don't mind if you guys use the b<system> names as shorthand. The
simplification is mostly to make the branding easier.
byuu says:
Changelog:
- SFC: balanced profile removed
- SFC: performance profile removed
- SFC: code for handling non-threaded CPU, SMP, DSP, PPU removed
- SFC: Coprocessor, Controller (and expansion port) shared Thread code
merged to SFC::Cothread
- Cothread here just means "Thread with CPU affinity" (couldn't think
of a better name, sorry)
- SFC: CPU now has vector<Thread*> coprocessors, peripherals;
- this is the beginning of work to allow expansion port devices to be
dynamically changed at run-time
- ruby: all audio drivers default to 48000hz instead of 22050hz now if
no frequency is assigned
- note: the WASAPI driver can default to whatever the native frequency
is; doesn't have to be 48000hz
- tomoko: removed the ability to change the frequency from the UI (but
it will display the frequency used)
- tomoko: removed the timing settings panel
- the goal is to work toward smooth video via adaptive sync
- the model is broken by not being in control of the audio frequency
anyway
- it's further broken by PAL running at 50hz and WSC running at 75hz
- it was always broken anyway by SNES interlace timing varying from
progressive timing
- higan: audio/ stub created (for now, it's just nall/dsp/ moved here
and included as a header)
- higan: video/ stub created
- higan/GNUmakefile: now includes build rules for essential components
(libco, emulator, audio, video)
The audio changes are in preparation to merge wareya's awesome WASAPI
work without the need for the nall/dsp resampler.
byuu says:
This release most notably adds WonderSwan and WonderSwan Color
emulation.
It is also the final release that will include the balanced and
performance profiles for bsnes.
Changelog (since v097):
- higan: added WonderSwan and WonderSwan Color emulation
- higan: simplified the coooperative-thread schedulers for all emulation
cores
- higan: moved from native (u)int[8,16,32,64]_t types to
Natural<T>/Integer<T> classes
- higan: major cleanups to the Makefiles; including auto-selection of
processor cores
- loki: very barebones skeleton in place now; does absolutely nothing
- these allow the removal of huge amounts of manual bit-twiddling with
more readable alternatives
- FC: fixed PPU OAM reads (mask the correct bits when writing) [hex_usr]
- SFC: fixed expansion port device mapping on game load
- SFC: reworked the way SGB games were loaded -* SFC core can now be
compiled without GB core (and thus without SGB support)
- SFC: added Super Disc expansion port device (although it's just
a non-functional skeleton so far)
- SFC: bugfix to SharpRTC emulation regarding leap year extra day counts
(Dai Kaijuu Monogatari II)
- SFC: major code cleanups to the CPU core and the R65816 processor base
class
- SFC: added 21fx emulation (not the old 21fx that became MSu1; reusing
the name for a new idea)
- basic idea is to move the serial USART to the expansion port along
with a reset vector hijack
- SFC: emulate reset vector pushing PC onto the stack on system soft
reset
- GB: pass gekkio's if_ie_registers and boot_hwio-G test ROMs
- GBA: reworked all handling of MMIO functions: removed the get/set
class functions
- nall: improved edge case return values for
(basename,pathname,dirname,...)
- ruby: fixed ~AudioXAudio2() typo (now calls destructor on exit)
- ruby: if DirectSoundCreate fails (no sound device present), return
false from init instead of crashing
- tomoko: added "All" option to filetype dropdown for ROM loading
- allows loading GBC games in SGB mode
- tomoko: locate() updated to search multiple paths [2]
- tomoko: fixed some oddities when changing the audio frequency/latency
settings
- icarus: can now work with WonderSwan and WonderSwan Color games
Note 1: 90% of the changelog for this release was related to the
WonderSwan emulation being in development. Doesn't make a lot of sense
to post about fixes since the code didn't exist publicly prior to this
release.
byuu says:
Changelog:
- bsnes-accuracy emulates reset vector properly[1]
- bsnes-balanced compiles once more
- bsnes-performance compiles once more
The balanced and performance profiles are fixed for the last time. They
will be removed for v098r01.
Please test this WIP as much as you can. I intend to release v098 soon.
I know save states are a little unstable for the WS/WSC, but they work
well enough for a release. If I can't figure it out soon, I'm going to
post v098 anyway.
[1] this one's been a really long time coming, but ... one of the bugs
I found when I translated Tekkaman Blade was that my translation patch
would crash every now and again when you hit the reset button on a real
SNES, but it always worked upon power on.
Turns out that while power-on initializes the stack register to $01ff,
reset does things a little bit differently. Reset actually triggers the
reset interrupt vector after putting the CPU into emulation mode, but it
doesn't initialize the stack pointer. The net effect is that the stack
high byte is set to $01, and the low byte is left as it was. And then
the reset vector runs, which pushes the low 16-bits of the program
counter, plus the processor flags, onto the stack frame. So you can
actually tell where the game was at when the system was reset ... sort
of.
It's a really weird behavior to be sure. But here's the catch: say
you're hacking a game, and so you hook the reset vector with jsl
showMyTranslationCreditsSplashScreen, and inside this new subroutine,
you then perform whatever bytes you hijacked, and then initialize the
stack frame to go about your business drawing the screen, and when
you're done, you return via rtl.
Generally, this works fine. But if S={0100, 0101, or 0102}, then the
stack will wrap due to being in emulation mode at reset. So it will
write to {0100, 01ff, 01fe}. But now in your subroutine, you enable
native mode. So when you return from your subroutine hijack, it reads
the return address from {01ff, 0200, 0201} instead of the expected
{01ff, 0100, 0101}. Thus, you get an invalid address back, and you
"return" to the wrong location, and your program dies.
The odds of this happening depend on how the game handles S, but
generally speaking, it's a ~1:85 chance.
By emulating this behavior, I'll likely expose this bug in many ROM
hacks that do splash screen hooks like this, including my own Tekkaman
Blade translation. And it's also very possible that there are commercial
games that screw this up as well.
But, it's what the real system does. So if any crashes start happening
as of this WIP upon resetting the game, well ... it'd happen on real
hardware, too.
byuu says:
Changelog:
- WS: fixed sprite window clipping (again)
- WS: don't set IRQ status bits of IRQ enable bits are clear
- SFC: signed/unsigned -> int/uint for DSP core
- SFC: removed eBoot
- SFC: added 21fx (not the same as the old precursor to MSU1; just
reusing the name)
Note: XI Little doesn't seem to be fixed after all ... but the other
three are. So I guess we're at 13 bugs :( And holy shit that music when
you choose a menu option is one of the worst sounds I've ever heard in
my life >_<
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.
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
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.
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.
byuu says:
Changelog:
- WS: added HblankTimer and VblankTimer IRQs; although they don't appear
to have any effect on any games that use them :/
- WS: added sound emulation; works perfectly in some games (eg Riviera);
is completely silent in most games (eg GunPey)
The sound emulation only partially supports the hypervoice (headphone
only) channel. I need to implement the SDMA before it'll actually do
anything useful. I'm a bit confused about how exactly things work. It
looks like the speaker volume shift and clamp only applies to speaker
mode and not headphone mode, which is very weird. Then there's the
software possibility of muting the headphones and/or the speaker.
Preferably, I want to leave the emulator always in headphone mode for
the extra audio channel. If there are games that force-mute the
headphones, but not speakers, then I may need to force headphones back
on but with the hypervoice channel disabled. I guess we'll see how
things go.
Rough guess is probably that the channels default to enabled after the
IPLROM, and games aren't bothering to manually enable them or something.
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.
byuu says:
Changelog:
- emulated SuperDisc $21e1 basic interface (NEC 4-bit MCU); all hardware
tests pass now (but they don't test much)
- WS/V30MZ: fixed inc/dec reg flag calculation
- WS/V30MZ: fixed lds/les instructions
WS/C compatibility should be way up now. SuperDisc BIOS passes all tests
now (but they only test for the presence of the interface, nothing
more.)
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.
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.
byuu says:
Changelog:
- WS: fixed a major CPU bug where I was using the wrong bits for
ModR/M's memory mode
- WS: added grayscale PPU emulation (exceptionally buggy)
GunPey now runs, as long as you add:
eeprom name=save.ram size=0x800
to the manifest after importing with icarus.
Right now, you can't control the game due to missing keypad polling.
There's also a lot of glitchiness with the sprites. Seems like they're
not getting properly cleared sometimes or something.
Also, the PPU emulation is totally unrealistic bullshit. I decode and
evaluate every single tile and sprite on every single pixel of output.
No way in hell the hardware could ever come close to that. The speed's
around 500fps without the insane sprite evaluations, and around 90fps
with it. Obviously, I'll fix this in time.
Nothing else seems to run that I've tried. Not even far enough to
display any output whatsoever. Tried Langrisser Millenium, Rockman
& Forte and Riviera. I really need to update icarus to try and encode
eeprom/sram sizes, because that's going to break a lot of stuff if it's
missing.
byuu says:
Changelog:
- fixed nall/windows/guard.hpp
- fixed hiro/(windows,gtk)/header.hpp
- fixed Famicom PPU OAM reads (mask the correct bits when writing)
[hex_usr]
- removed the need for (system := system) lines from higan/GNUmakefile
- added "All" option to filetype dropdown for ROM loading
- allows loading GBC games in SGB mode (and technically non-GB(C)
games, which will obviously fail to do anything)
- loki can load and play game folders now (command-line only) (extremely
unimpressive; don't waste your time :P)
- the input is extremely hacked in as a quick placeholder; not sure
how I'm going to do mapping yet for it
byuu says:
Changelog:
- fixed SNES sprite priority regression from r17
- added nall/windows/guard.hpp to guard against global namespace
pollution (similar to nall/xorg/guard.hpp)
- almost fixed Windows compilation (still accuracy profile only, sorry)
- finished porting all of gba/ppu's registers over to the new .bit,.bits
format ... all GBA registers.cpp files gone now
- the "processors :=" line in the target-$(ui)/GNUmakefile is no longer
required
- processors += added to each emulator core
- duplicates are removed using the new nall/GNUmakefile's $(unique)
function
- SFC core can be compiled without the GB core now
- "-DSFC_SUPERGAMEBOY" is required to build in SGB support now (it's
set in target-tomoko/GNUmakefile)
- started once again on loki (higan/target-loki/) [as before, loki is
Linux/BSD only on account of needing hiro::Console]
loki shouldn't be too horrendous ... I hope. I just have the base
skeleton ready for now. But the code from v094r08 should be mostly
copyable over to it. It's just that it's about 50KiB of incredibly
tricky code that has to be just perfect, so it's not going to be quick.
But at least with the skeleton, it'll be a lot easier to pick away at it
as I want.
Windows compilation fix: move hiro/windows/header.hpp line 18 (header
guard) to line 16 instead.
byuu says:
Changelog:
- ruby: if DirectSoundCreate fails (no sound device present), return
false from init instead of crashing
- nall: improved edge case return values for
(basename,pathname,dirname,...)
- nall: renamed file_system_object class to inode
- nall: varuint_t replaced with VariadicNatural; which contains
.bit,.bits,.byte ala Natural/Integer
- nall: fixed boolean compilation error on Windows
- WS: popa should not restore SP
- GBA: rewrote the CPU/APU cores to use the .bit,.bits functions;
removed registers.cpp from each
Note that the GBA changes are extremely major. This is about five hours
worth of extremely delicate work. Any slight errors could break
emulation in extremely bad ways. Let's hold off on extensive testing
until the next WIP, after I do the same to the PPU.
So far ... endrift's SOUNDCNT_X I/O test is failing, although that code
didn't change, so clearly I messed up SOUNDCNT_H somehow ...
To compile on Windows:
1. change nall/string/platform.hpp line 47 to
return slice(result, 0, 3);
2. change ruby/video.wgl.cpp line 72 to
auto lock(uint32_t*& data, uint& pitch, uint width, uint height) -> bool {
3. add this line to the very top of hiro/windows/header.cpp:
#define boolean FuckYouMicrosoft
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.
byuu says:
Changelog:
- higan now uses Natural<Size>/Integer<Size> for its internal types
- Super Famicom emulation now uses uint24 instead of uint for bus
addresses (it's a 24-bit bus)
- cleaned up gb/apu MMIO writes
- cleaned up sfc/coprocessor/msu1 MMIO writes
- ~3% speed penalty
I've wanted to do that 24-bit bus thing for so long, but have always
been afraid of the speed impact. It's probably going to hurt
balanced/performance once they compile again, but it wasn't significant
enough to harm the accuracy core's frame rate, thankfully. Only lost one
frame per second.
The GBA core handlers are clearly going to take a lot more work. The
bit-ranges will make it substantially easier to handle, though. Lots of
32-bit registers where certain values span multiple bytes, but we have
to be able to read/write at byte-granularity.
byuu says:
Got it. Wow, that didn't hurt nearly as much as I thought it was going
to.
Dropped from 127.5fps to 123.5fps to use Natural/Integer for
(u)int(8,16,32,64).
That's totally worth the cost.
byuu says:
This is a few days old, but oh well.
This WIP changes nall,hiro,ruby,icarus back to (u)int(8,16,32,64)_t.
I'm slowly pushing for (u)int(8,16,32,64) to use my custom
Integer<Size>/Natural<Size> classes instead. But it's going to be one
hell of a struggle to get that into higan.
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.
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.
byuu says:
Alright, well interrupts are in. At least Vblank is.
I also fixed a bug in vector() indexing, MoDRM mod!=3&®==6 using SS
instead of DS, opcodes a0-a3 allowing segment override, and added the
"irq_disable" stuff to the relevant opcodes to suppress IRQs after
certain instructions.
But unfortunately ... still no go on Riviera. It's not reading any
unmapped ports, and although it enables Vblank IRQs and they set port
$b4's status bit, the game never sets the IE flag, so no interrupts ever
actually fire. The game does indeed appear to be sitting in a rather
huge loop, which is probably dependent upon some RAM variable being set
from the Vblank IRQ, but I don't know how I'm supposed to be triggering
it.
... I'm really quite stumped here >_>
byuu says:
All 256 instructions implemented fully. Fixed a major bug with
instructions that both read and write to ModRM with displacement.
Riviera now runs into an infinite loop ... possibly crashed, possibly
waiting on interrupts or in to return something. Added a bunch of PPU
settings registers, but nothing's actually rendering with them yet.
244 of 256 opcodes implemented now, although the interrupt triggering
portions are missing from them still. Much better handling of prefixes
now.
I definitely have a newfound hatepreciation for x86 now >_>
byuu says:
Up to 211 opcodes implemented, with the caveat that the four opcodes
that make up group 3 and group 4 don't do anything yet. Both groups seem
to have some "illegal" instructions in them, so that'll be "fun".
I have a new mechanic in place for opcode prefixes, but it could use
some work still. I also only have it working to override ModRM mem
addressing, but of course it does it in a lot of other places like the
string operations.
Making it about 5.5 million instructions into Gunpey now, but of course
that doesn't mean much. Could be going off the rails at any point due to
CPU bugs or unimplemented ports. Riviera's still crashing.
byuu says:
26 hours in, 173 instructions implemented. Although the four segment
prefix opcodes don't actually do anything yet. There's less than 256
actual instructions on the 80186, not sure of the exact count.
Gunpey gets around ~8,200 instructions in before hitting an unsupported
opcode (loop). Riviera goes off the rails on a retf and ends up
executing an endless stream of bad opcodes in RAM =( Both games hammer
the living shit out of the in/out ports pretty much immediately.
byuu says:
Man, the 80186 is taking a lot longer to implement than I thought it
would. So far I'm 18 hours into this emulator. Whereas I had Super Mario
Bros fully playable (no sound) in 12 hours for the NES >_>
I refactored all the byte/word variant functions to single functions
that take a size parameter. Cuts the amount of code in half.
Also implemented repz/repnz + movsb/movsw, so Riviera now gets 299
instructions in before dying. Nobody really bothers to explain how the
CPU actually implements these instructions, but I think I have it right:
ignore non-string opcodes that follow rep, invoke the string operations
inside the rep opcodes to prevent interrupts from triggering between the
two (which will be even more fun for segment selector overrides ...)
The next opcode needed is 0xC7, which ... throws ModRM on its head. In
this mode, ModRM is only used to determine the target operand (and it
doesn't use the middle bits for that at all), and the source is an
immediate that follows it. Gonna have to waste a few more hours thinking
about how best to handle that.
Also, disabled HiDPI for higan as well on OS X.
byuu says:
More V30MZ implemented, a lot more to go.
icarus now supports importing WS and WSC games. It expects them to have
the correct file extension, same for GB and GBC.
> Ugh, apparently HiDPI icarus doesn't let you press the check boxes.
I set the flag value in the plist to false for now. Forgot to do it for
higan, but hopefully I won't forget before 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.)
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.
byuu says:
Note: balanced/performance profiles still broken, sorry.
Changelog:
- added nall/GNUmakefile unique() function; used on linking phase of
higan
- added nall/unique_pointer
- target-tomoko and {System}::Video updated to use
unique_pointer<ClassName> instead of ClassName* [1]
- locate() updated to search multiple paths [2]
- GB: pass gekkio's if_ie_registers and boot_hwio-G test ROMs
- FC, GB, GBA: merge video/ into the PPU cores
- ruby: fixed ~AudioXAudio2() typo
[1] I expected this to cause new crashes on exit due to changing the
order of destruction of objects (and deleting things that weren't
deleted before), but ... so far, so good. I guess we'll see what crops
up, especially on OS X (which is already crashing for unknown reasons on
exit.)
[2] right now, the search paths are: programpath(), {configpath(),
"higan/"}, {localpath(), "higan/"}; but we can add as many more as we
want, and we can also add platform-specific versions.
byuu says:
A minor WIP to get us started.
Changelog:
- System::Video merged to PPU::Video
- System::Audio merged to DSP::Audio
- System::Configuration merged to Interface::Settings
- created emulator/emulator.cpp and accompanying object file for shared
code between all cores
Currently, emulator.cpp just holds a videoColor() function that takes
R16G16B16, performs gamma/saturation/luma adjust, and outputs
(currently) A8R8G8B8. It's basically an internal function call for cores
to use when generating palette entries. This code used to exist inside
ui-tomoko/program/interface.cpp, but we have to move it internal for
software display emulation. But in the future, we could add other useful
cross-core functionality here.
byuu says:
This release features improvements to all emulation cores, but most
substantially for the Game Boy core. All of blargg's test ROMs that pass
in gambatte now either pass in higan, or are off by 1-2 clocks (the
actual behaviors are fully emulated.) I consider the Game Boy core to
now be fairly accurate, but there's still more improvements to be had.
Also, what's sure to be a major feature for some: higan now has full
support for loading and playing ordinary ROM files, whether they have
copier headers, weird extensions, or are inside compressed archives. You
can load these games from the command-line, from the main Library menu
(via Load ROM Image), or via drag-and-drop on the main higan window. Of
course, fans of game folders and the library need not worry: that's
still there as well.
Also new, you can drop the (uncompressed) Game Boy Advance BIOS onto the
higan main window to install it into the correct location with the
correct file name.
Lastly, this release technically restores Mac OS X support. However,
it's still not very stable, so I have decided against releasing binaries
at this time. I'd rather not rush this and leave a bad first impression
for OS X users.
Changelog (since v096):
- higan: project source code hierarchy restructured; icarus directly
integrated
- higan: added software emulation of color-bleed, LCD-refresh,
scanlines, interlacing
- icarus: you can now load and import ROM files/archives from the main
higan menu
- NES: fixed manifest parsing for board mirroring and VRC pinouts
- SNES: fixed manifest for Star Ocean
- SNES: fixed manifest for Rockman X2,X3
- GB: enabling LCD restarts frame
- GB: emulated extra OAM STAT IRQ quirk required for GBVideoPlayer
(Shonumi)
- GB: VBK, BGPI, OBPI are readable
- GB: OAM DMA happens inside PPU core instead of CPU core
- GB: fixed APU length and sweep operations
- GB: emulated wave RAM quirks when accessing while channel is enabled
- GB: improved timings of several CPU opcodes (gekkio)
- GB: improved timings of OAM DMA refresh (gekkio)
- GB: CPU uses open collector logic; return 0xFF for unmapped memory
(gekkio)
- GBA: fixed sequencer enable flags; fixes audio in Zelda - Minish Cap
(Jonas Quinn)
- GBA: fixed disassembler masking error (Lioncash)
- hiro: Cocoa support added; higan can now be compiled on Mac OS X 10.7+
- nall: improved program path detection on Windows
- higan/Windows: moved configuration data from %appdata% to
%localappdata%
- higan/Linux,BSD: moved configuration data from ~/.config/higan to
~/.local/higan
byuu says:
Changelog:
- configuration files are now stored in localpath() instead of configpath()
- Video gamma/saturation/luminance sliders are gone now, sorry
- added Video Filter->Blur Emulation [1]
- added Video Filter->Scanline Emulation [2]
- improvements to GBA audio emulation (fixes Minish Cap) [Jonas Quinn]
[1] For the Famicom, this does nothing. For the Super Famicom, this
performs horizontal blending for proper pseudo-hires translucency. For
the Game Boy, Game Boy Color, and Game Boy Advance, this performs
interframe blending (each frame is the average of the current and
previous frame), which is important for things like the GBVideoPlayer.
[2] Right now, this only applies to the Super Famicom, but it'll come to
the Famicom in the future. For the Super Famicom, this option doesn't
just add scanlines, it simulates the phosphor decay that's visible in
interlace mode. If you observe an interlaced game like RPM Racing on
a real SNES, you'll notice that even on perfectly still screens, the
image appears to shake. This option emulates that effect.
Note 1: the buffering right now is a little sub-optimal, so there will
be a slight speed hit with this new support. Since the core is now
generating native ARGB8888 colors, it might as well call out to the
interface to lock/unlock/refresh the video, that way it can render
directly to the screen. Although ... that might not be such a hot idea,
since the GBx interframe blending reads from the target buffer, and that
tends to be a catastrophic option for performance.
Note 2: the balanced and performance profiles for the SNES are
completely busted again. This WIP took 6 1/2 hours, and I'm exhausted.
Very much not looking forward to working on those, since those two have
all kinds of fucked up speedup tricks for non-interlaced and/or
non-hires video modes.
Note 3: if you're on Windows and you saved your system folders somewhere
else, now'd be a good time to move them to %localappdata%/higan
byuu says:
This WIP finally achieves the vision I've had for icarus.
I also fixed a mapping issue with Cx4 that, oddly enough, only caused
the "2" from the Mega Man X2 title screen to disappear.
[Editor's note - "the vision for icarus" was described in a separate,
public forum post: http://board.byuu.org/phpbb3/viewtopic.php?p=20584
Quoting for posterity:
icarus is now a full-fledged part of higan, and will be bundled with
each higan WIP as well. This will ensure that in the future, the
exact version of icarus you need to run higan will be included right
along with it. As of this WIP, physical manifest files are now truly
and entirely optional.
From now on, you can associate your ROM image files with higan's
main binary, or drop them directly on top of it, to load and play
your games.
Furthermore, there are two new menu options that appear under the
library menu when icarus is present:
- "Load ROM File ..." => gives you a single-file selection dialog to
import (and if possible) run the game
- "Import ROM Files ..." => gives you a multi-file import dialog
with checkboxes to pull in multiple games at once
Finally, as before, icarus can generate manifest.bml files for
folders that lack them.
For people who like the game folder and library system, nothing's
changed. Keep using higan as you have been.
For people who hate it, you can now use higan like your classic
emulators. Treat the "Library->{System Name}" entries as your
"favorites" list: the games you actually play. Treat the
"Library->Load ROM" as your standard open file dialog in other
emulators. And finally, treat "Advanced->Game Library" as your save
data path for cheat codes, save states, save RAM, etc.
]
byuu says:
Changelog:
- GB: re-enabling the LCD resets the display to LY=0,LX=0 [1]
- GB: emulated new findings (as of today!) for a DMG quirk that triggers
an extra OAM STAT IRQ when Vblank STAT IRQs are off
- GB: made VBK, BGPI, OBPI readable
- GB: fixed APU length operations
- GB: fixed APU sweep operations
- NES: fixed cartridge/ -> board/ manifest lookups for mirroring/pinous
- hiro/Cocoa: added endrift's plist keys
Fixed:
- Astro Rabby is fully playable, even the title screen works correctly
- Bomb Jack is fully playable
- Kirby's Dream Land 2 intro scrolling first scanline of Rick is now fixed
- GBVideoPlayer functions correctly [2]
- Shin Megami Tensei: Devichil series regression fixed
[1] doesn't pass oam_bug-2/1-lcd_sync; because it seems to want
LY=0,LX>0, and I can't step the PPU in a register write as it's not
a state machine; the effect is emulated, it just starts the frame a tiny
bit sooner. blargg's testing is brutal, you can't be even one cycle off
or the test will fail.
[2] note that you will need the GBC Display Emulation shader from
hunterk's repository, or it will look like absolute shit. The
inter-frame blending is absolutely critical here.
byuu says:
Changelog:
- fixed S-DD1 RAM writes (Star Ocean audio fixed)
- applied all of the DMG test ROM fixes discussed earlier; passes many
more test ROMs now
- at least until the GBVideoPlayer is working: for debugging purposes,
CPU/PPU single-step now instead of sync just-in-time (~30% slower)
- fixed OS X crash on NSTextView (hopefully, would be very odd if not)
Unfortunately passing these test ROMs caused my favorite GB/GBC game to
break all of its graphics =(
Shin Megami Tensei - Devichil - Kuro no Sho (Japan) is all garbled now.
I'm really quite bummed by this ... but I guess I'll go through and
revert r04's fixes one at a time until I find what's causing it.
On the plus side, Astro Rabby is playable now. Still acts weird when
pressing B/A on the first screen, but the start button will start the
game.
EDIT: got it. Shin Megami Tensei - Devichil requires FF4F (VBK) to be
readable. Before, it was always returning 0x00. With my return 0xFF
patch, that broke. But it should be returning the VBK value, which also
fixes it. Also need to handle FF68/FF6A reads. Was really hoping that'd
help GBVideoPlayer too, but nope. It doesn't read any of those three
registers.
byuu says:
Changelog:
- fixed icarus to save settings properly
- fixed higan's full screen toggle on OS X
- increased "Add Codes" button width to avoid text clipping
- implemented cocoa/canvas.cpp
- added 1s delay after mapping inputs before re-enabling the window
(wasn't actually necessary, but already added it)
- fixed setEnabled(false) on Cocoa's ListView and TextEdit widgets
- updated nall::programpath() to use GetModuleFileName on Windows
- GB: system uses open collector logic, so unmapped reads return 0xFF,
not 0x00 (passes blargg's cpu_instrs again) [gekkio]
byuu says:
New update. Most of the work today went into eliminating hiro::Image
from all objects in all ports, replacing with nall::image. That took an
eternity.
Changelog:
- fixed crashing bug when loading games [thanks endrift!!]
- toggling "show status bar" option adjusts window geometry (not
supposed to recenter the window, though)
- button sizes improved; icon-only button icons no longer being cut off
byuu says:
Warning: this is not for the faint of heart. This is a very early,
unpolished, buggy release. But help testing/fixing bugs would be greatly
appreciated for anyone willing.
Requirements:
- Mac OS X 10.7+
- Xcode 7.2+
Installation Commands:
cd higan
gmake -j 4
gmake install
cd ../icarus
gmake -j 4
gmake install
(gmake install is absolutely required, sorry. You'll be missing key
files in key places if you don't run it, and nothing will work.)
(gmake uninstall also exists, or you can just delete the .app bundles
from your Applications folder, and the Dev folder on your desktop.)
If you want to use the GBA emulation, then you need to drop the GBA BIOS
into ~/Emulation/System/Game\ Boy\ Advance.sys\bios.rom
Usage:
You'll now find higan.app and icarus.app in your Applications folders.
First, run icarus.app, navigate to where you keep your game ROMs. Now
click the settings button at the bottom right, and check "Create
Manifests", and click OK. (You'll need to do this every time you run
icarus because there's some sort of bug on OSX saving the settings.) Now
click "Import", and let it bring in your games into ~/Emulation.
Note: "Create Manifests" is required. I don't yet have a pipe
implementation on OS X for higan to invoke icarus yet. If you don't
check this box, it won't create manifest.bml files, and your games won't
run at all.
Now you can run higan.app. The first thing you'll want to do is go to
higan->Preferences... and assign inputs for your gamepads. At the very
least, do it for the default controller for all the systems you want to
emulate.
Now this is very important ... close the application at this point so
that it writes your config file to disk. There's a serious crashing bug,
and if you trigger it, you'll lose your input bindings.
Now the really annoying part ... go to Library->{System} and pick the
game you want to play. Right now, there's a ~50% chance the application
will bomb. It seems the hiro::pListView object is getting destroyed, yet
somehow the internal Cocoa callbacks are being triggered anyway. I don't
know how this is possible, and my attempts to debug with lldb have been
a failure :(
If you're unlucky, the application will crash. Restart and try again. If
it crashes every single time, then you can try launching your game from
the command-line instead. Example:
open /Applications/higan.app \
--args ~/Emulation/Super\ Famicom/Zelda3.sfc/
Help wanted:
I could really, really, really use some help with that crashing on game
loading. There's a lot of rough edges, but they're all cosmetic. This
one thing is pretty much the only major show-stopping issue at the
moment, preventing a wider general audience pre-compiled binary preview.
byuu says:
Changelog:
- restructured the project and removed a whole bunch of old/dead
directives from higan/GNUmakefile
- huge amounts of work on hiro/cocoa (compiles but ~70% of the
functionality is commented out)
- fixed a masking error in my ARM CPU disassembler [Lioncash]
- SFC: decided to change board cic=(411,413) back to board
region=(ntsc,pal) ... the former was too obtuse
If you rename Boolean (it's a problem with an include from ruby, not
from hiro) and disable all the ruby drivers, you can compile an
OS X binary, but obviously it's not going to do anything.
It's a boring WIP, I just wanted to push out the project structure
change now at the start of this WIP cycle.
byuu says:
Changelog (since v095):
- higan: absolutely massive amounts of coding style updates; probably
150 hours of work here
- higan: manifest format updated for much greater consistency and
simplicity
- higan: wrote popen() replacement to suppress console flashing when
loading games via icarus
- icarus: now includes external database with mapping information for
all verified games
- icarus: added support for importing Campus Challenge '92 and Powerfest
'94
- icarus: merged settings.bml with higan; changing library path in one
affects the other now
- SFC: added MSU1 audio resume support
- SFC: added new expansion port device (eBoot); simulation of SNES-Boot
hardware
- SFC: expansion port device can now be selected from system menu
- SFC: updated handling of open bus (thanks to Exophase for the design
idea)
- SFC: "BS-X Satellaview" library folder renamed to "BS Memory"
- GBA: fixed 8-bit SRAM reading/writing
- GBA: PRAM is 16-bits wide
- GBA: VRAM OBJ 8-bit writes are ignored
- GBA: BGnCNT unused bits are writable
- GBA: BG(0,1)CNT can't set d13
- GBA: BLDALPHA is readable (fixes many games including Donkey Kong
Country)
- GBA: DMA masks &~1/Half, &~3/Word
- GBA: fixed many other I/O register reads; gets perfect score on
endrift's I/O tests
- GBA: fixed caching of r(d) to pass armwrestler tests (Jonas Quinn)
- GBA: blocked DMA to/from BIOS region (Cydrak)
- GBA: fixed sign-extend and rotate on ldrs instructions (Cydrak)
- tomoko: added "Ignore Manifests" option to advanced settings panel
- tomoko: re-added support for ruby/quark video shaders
- tomoko: improved aspect correction behavior
- tomoko: added new tool, "Manifest Viewer" (mostly useful for
developers)
- ruby: fixed mouse capture clipping on Windows (Cydrak)
- ruby: won't crash when using OpenGL 3.2 Linux driver with only OpenGL
2.0 available
- ruby: added Linux fallback OpenGL 2.0 driver (not compiled in by
default)
- ruby: added preliminary WASAPI driver (not compiled in by default, due
to bugginess)
- hiro: fixed the appearance of Button and ListView::CheckButton on
Windows classic
- hiro: added missing return values from several functions (fixes
crashes with Clang)
byuu says:
Changelog:
- replaced popen() with execvp() / CreateProcess()
- suppressed (hid) controllers with no mappable inputs from the input
settings panel
This gets rid of the window flashing when loading games with
higan+icarus. And hiding of empty devices should be a huge usability
improvement, especially since "None" was appearing at the top of the
list before for the SNES.
byuu says:
higan supports Event mapping again.
Further, icarus can now detect Event ROMs and MSU1 games.
Event ROMs must be named "program.rom", "slot-(1,2,3).rom" MSU1 games
must contain "msu1.rom"; and tracks must be named "track-#.pcm"
When importing the CC'92, PF'94 ROMs, the program.rom and
slot-(1,2,3).rom files must be concatenated. The DSP firmware can
optionally be separate, but I'd recommend you go ahead and merge it all
to one file. Especially since that common "higan DSP pack" floating
around on the web left out the DSP1 ROMs (only has DSP1B) for god knows
what reason.
There is no support for loading "game.sfc+game.msu+game-*.pcm", because
I'm not going to support trying to pull in all of those files through
importing. Games will have to be distributed as game folders to use
MSU1. The MSU1 icarus support is simply so your game folders won't
require an unstable manifest.bml file to be played. So once they're in
there, they are good for life.
Note: the Event sizes in icarus' SFC heuristics are wrong for appended
firmware. Change from 0xXX8000 to 0xXX2000 and it works fine. Will be
fixed in r18.
Added Sintendo's flickering fixes. The window one's a big help for
regular controls, but the ListView double buffering does nothing for me
on Windows 7 :( Fairly sure I know why, but too lazy to try and fix that
now.
Also fixes the mMenu thing.
byuu says (in the WIP forum):
Changelog:
- satellaviewcartridge/SatellaviewCartridge is now bsmemory/BSMemory
- Emulation/BS-X Satellaview/ is now Emulation/BS Memory/
- masking is in for MCC's mcu (awful hack in the code, but that's
temporary)
- BS Memory types are now "flash" or "mrom"
- fixed loading Same Game - Tengai Hen
- icarus fixed up a lot; can load database entries for any supported
media type now (only the SFC DB exists currently)
mMenu::remove() fix will be in the next WIP.
byuu says (in the public beta thread):
Changelog:
- GBA emulation accuracy improved quite a bit
- video shaders are supported once again
- icarus shares settings.bml with higan; changing library path in
one now affects the other
- icarus manifest generation now uses my SNES game dumping database
for perfect mapping of US games
- major overhaul to manifest file format. As long as you have
v095-style folders without manifest.bml, you will be fine
- if not, go to higan->settings->configuration->advanced and check
"Ignore Manifests" before loading your first game
- new "Manifest Viewer" tool (not really meant for regular users;
more of a developer tool)
- experimental (but disabled in the binary) WASAPI driver. Help
stabilizing it would be *greatly* appreciated!
- lots of other stuff
r13 and r14 weren't posted as individual releases, but their changelogs
were posted.
byuu says about r13:
I'm not going to be posting WIPs for r13 and above for a while.
The reason is that I'm working on the major manifest overhaul I've
discussed previously on the icarus subforum.
I'm recreating my boards database from scratch using the map files
and the new map analyzer. The only games that will load are ones
I've created board definitions for, and updated
sfc/cartridge/markup.cpp to parse. Once I've finished all the
boards, then I'll update the heuristics.
Then finally, I'll sync the syntax changes over to the fc, gb, gba
cores.
Once that's done, I'll start posting WIPs again, along with a new
build of icarus.
But I'll still post changelogs as I work through things.
Changelog (r13):
- preservation: created new database-builder tool (merges
region-specific databases with boards)
- icarus: support new, external database format
(~/.config/icarus/Database/(Super Famicom.bml, ...)
- added 1A3B-(10,11,12); 1A3B-20
byuu says about r14:
r14 work:
I successfully created mappings for every board used in the US set.
I also updated icarus' heuristics to use the new mappings, and
created ones there for the boards that are only in the JP set.
Then I patched icarus to support pulling games out of the database
when it's used on a game folder to generate a manifest file.
Then I updated a lot of code in higan/sfc to support the new mapping
syntax. sfc/cartridge/markup.cpp is about half the size it used to
be with the new mappings, and I was able to kill off both map/id and
map/select entirely.
Then I updated all four emulated systems (and both subsystems) to
use "board" as the root node, and harmonized their syntax (made them
all more consistent with each other.)
Then I added a manifest viewer to the tools window+menu. It's kind
of an advanced user feature, but oh well. No reason to coddle people
when the feature is very useful for developers. The viewer will show
all manifests in order when you load multi-cart games as well.
Still not going to call any syntax 100% done right now, but
thankfully with the new manifest-free folders, nobody will have to
do anything to use the new format. Just download the new version and
go.
The Super Famicom Event stuff is currently broken (CC92/PF94
boards). That's gonna be fun to support.
byuu says about r15:
EDIT: small bug in icarus with heuristics. Edit
core/super-famicom.cpp line 27:
if(/*auto*/ markup = cartridge.markup) {
Gotta remove that "auto" so that it returns valid markup.
Resolved the final concerns I had with the new manifest format.
Right now there are two things that are definitely broken: MCC (BS-X
Town cart) and Event (CC '92 and PF'94).
And there are a few things that are untested: SPC7110, EpsonRTC,
SharpRTC, SDD1+RAM, SufamiTurbo, BS-X slotted carts.
byuu says:
Got it. They broke in r05.
Changelog:
- fixed typo in sfc/cpu/timing.cpp that was breaking coprocessor games
with clocks
- updated sfc/coprocessor/hitachidsp to not access Bus directly
byuu says:
Changelog:
- SFC: "uint8 read(uint addr)" -> "uint8 read(uint addr, uint8 data)"
- hiro: mHorizontalLayout::setGeometry() return value
- hiro/GTK: ListView,TreeView::setFocused() does not grab focus of first
item
Notes:
- nall/windows/utf8.hpp needs using uint = unsigned; at the top to
compile
- sfc/balanced, sfc/performance won't compile yet
Seems Cx4 games broke a while back. Not from this WIP, either. I'll go
back and find out what's wrong now.
byuu says:
Changelog:
- int_t<bits> replaced with Integer<bits>
- uint_t<bits> replaced with Natural<bits>
- fixed "Synchronize Audio" menu option that broke recently
- all of sfc/performance ported to "auto function() -> return;" syntax
With this WIP, all of higan is finally ported over to the new function
declaration syntax. Thank the gods.
There's still going to be periodic disruption for diffs from porting
over signed->int, unsigned->uint, and whatever we come up with for the
new Natural<> and Integer<> classes. But the worst of it's behind us
now.
byuu says:
Changelog:
- all of fc/ ported to "auto function() -> return;" syntax
- (includes all of cartridge/board and cartridge/chip as well; even
though they're all deprecated)
- sfc balanced profile ported to "auto function() -> return;" syntax
- sfc balanced and performance profiles compile again
- Linux always gets -ldl
- removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't
produce bug-free 32-bit binaries anyway
The only code that continues to use the old function syntax is the SFC
performance core, obscure parts of nall that higan doesn't use, and the
pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's
sinc resampler, and OV2's xaudio2 header file.)
I was too burned out to finish it tonight. The above was about four
hours straight of non-stop typing. Really can't wait to be done with
this once and for all.
byuu says:
Changelog:
- added preliminary WASAPI driver (it's really terrible, though. Patches
most welcome.)
- all of processor/ updated to auto fn() -> ret syntax
- all of gb/ updated to auto fn() -> ret syntax
If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile,
and replace audio.xaudio2 with audio.wasapi Note that the two drivers
are incompatible and cannot co-exist (yet. We can probably make it work
in the future.)
All that's left for the auto fn() -> ret syntax is the NES core and the
balanced/performance SNES components. This is kind of a big deal because
this syntax change causes diffs between WIPs to go crazy. So the sooner
we get this done and out of the way, the better. It's also nice from
a consistency standpoint, of course.
byuu says:
This release adds a settings dialog that lets you control the library
path, optionally generate manifest.bml files, and optionally bypass the
internal games database (so far this is only the US SNES set.)
Also, the settings.bml file can exist in the same folder as the binary
now (portable mode). Plus it can share the same config file as
higan/tomoko itself does. This will allow you to change the library
location in either program and have it affect the other program as well.
It's a bit hackish, but it works >_>
Note: don't use this with higan v095.06 or earlier, or bad things will
happen.
byuu says:
Changelog:
- entire GBA core ported to auto function() -> return; syntax
- fixed GBA BLDY bug that was causing flickering in a few games
- replaced nall/config usage with nall/string/markup/node
- this merges all configuration files to a unified settings.bml file
- added "Ignore Manifests" option to the advanced setting tab
- this lets you keep a manifest.bml for an older version of higan; if
you want to do regression testing
Be sure to remap your controller/hotkey inputs, and for SNES, choose
"Gamepad" from "Controller Port 1" in the system menu. Otherwise you
won't get any input. No need to blow away your old config files, unless
you want to.
byuu says:
Changelog:
- fixed I/O register reads; perfect score on endrift's I/O tests now
- fixed mouse capture clipping on Windows [Cydrak]
- several hours of code maintenance work done on the SFC core
All higan/sfc files should now use the auto fn() -> ret; syntax. Haven't
converted all unsigned->uint yet. Also, probably won't do sfc/alt as
that's mostly just speed hack stuff.
Errata:
- forgot auto& instead of just auto on SuperFamicom::Video::draw_cursor,
which makes Super Scope / Justifier crash. Will be fixed in the next
WIP.
byuu says:
Changelog:
- GBA: lots of emulation improvements
- PPU PRAM is 16-bits wide
- DMA masks &~1/Half, &~3/Word
- VRAM OBJ 8-bit writes are ignored
- OAM 8-bit writes are ignored
- BGnCNT unused bits are writable*
- BG(0,1)CNT can't set the d13
- BLDALPHA is readable (fixes Donkey Kong Country, etc)
- SNES: lots of code cleanups
- sfc/chip => sfc/coprocessor
- UI: save most recent controller selection
GBA test scores: 1552/1552, 37/38, 1020/1260
(* forgot to add the value to the read function, so endrift's I/O tests
for them will fail. Fixed locally.)
Note: SNES is the only system with multiple controller/expansion port
options, and as such is the only one with a "None" option. Because it's
shared by the controller and expansion port, it ends up sorted first in
the list. This means that on your first run, you'll need to go to Super
Famicom->Controller Port 1 and select "Gamepad", otherwise input won't
work.
Also note that changing the expansion port device requires loading a new
cart. Unlike controllers, you aren't meant to hotplug expansion port
devices.
Changelog:
- S-SMP core code style updated
- S-SMP loads reset vector from IPLROM ($fffe-ffff)
- sfc/base => sfc/expansion
- system/input => system/device
- added expansion/eBoot (simulation of defparam's SNES-Boot device)
- expansion port device can now be selected from Super Famicom menu
option
- improved GBA MROM/SRAM reading
endrift's memory test is up to 1388/1552.
Note: I added the expansion port devices to the same group as controller
ports. I also had to move "None" to the top of the list. Before v096,
I am going to have to add caching of port selections to the
configuration file, check the proper default item in the system menu,
and remove the items with no mappings from the input configuration
window. Lots of work >_>
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
byuu says:
Aspect correction is fixed now. Works way better than in v095 official.
It's still force-enabled in fullscreen mode. The idea of disabling it is
that it looks bad at 2x scale. But when you're fullscreen with a minimum
of 4x scale, there's no reason not to enable it.
It won't turn on at all for GB/C/A anymore. And I dropped the cute
attempt at making the aspect prettier on 2560x1600 monitors, so it'll be
the stock 8:7 across the board now for S/NES.
Also, the aspect correction will affect the window even when a game's
not loaded now, so the size won't bounce around as you change games in
windowed mode between GB/C/A and S/NES.
...
I also enhanced the ruby/glx driver. It won't crash if OpenGL 3.2 isn't
available anymore (fails safely ... had to capture the Xlib error
handler to suppress that), and it defaults to the MESA glXSwapInterval
before the SGI version. Because apparently the MESA version defines the
SGI version, but makes it a no-op. What. The. Fuck. right? But whatever,
reordering the enumerations fixes the ability to toggle Vsync on AMD
GPUs now.
...
Video shaders are back again. If you are using the OpenGL driver, you'll
see a "Video Shaders" menu beneath the "Video Filters" menu (couldn't
merge it with the filters due to hiro now constructing menu ordering
inside the header files. This works fine though.)
You want either "higan.exe" + "Video Shaders/" or "~/.local/bin/tomoko"
+ "~/.local/tomoko/Video Shaders/"
byuu says:
Changelog:
- added MSU1 resume support
- updated sfc/dsp, sfc/controller to match my coding style
- fixed hiro/Windows Button and ListView::CheckButton in Windows Classic
mode
byuu says:
After 20 months of development, higan v095 is released at long last!
The most notable feature is vastly improved Game Boy Advance emulation.
With many thanks to endrift, Cydrak, Jonas Quinn and jchadwick, this
release contains substantially improved CPU timings and many bugfixes.
Being one of only two GBA emulators to offer ROM prefetch emulation,
higan is very near mGBA in terms of accuracy, and far ahead of all
others. As a result of these fixes, compatibility is also much higher
than in v094.
There are also several improvements to SNES emulation. Most
significantly is support for mid-scanline changes to the background mode
in the accuracy profile.
Due to substantial changes to the user interface library used by higan,
this release features yet again a brand-new UI. With the exception of
video shaders and NSS DIP switch selection, it is at feature-parity with
the previous UI. It also offers some new features that v094 lacked.
The cheat code database has also been updated to the latest version by
mightymo.
ananke has been superseded by icarus.
The new tomoko UI does not support shaders, and if it ever does it will
probably use another format, so not much point keeping the old files
around.
byuu says:
- fixes checkboxes (-again- again [*again*])
- won't check folders with select all / unselect all
- won't crash anymore if the SNES ROM image is too small (Saturday Night
Slam Masters was crashing it before due to DB size error)
- corrected heuristics for Sufami Turbo base cart (mirrors the
absurdities of the real cart precisely, since it's one of a kind)
- corrected a few DB issues (BS-X name + PSRAM (again [*again*]), SNSM,
LAH) (_again_)
- these are temporary. Monkey patched in the generated .hpp source
rather than the actual DB
- not going to fix the SFT sizes because I want to verify what
happened there first
byuu says:
With any luck, this will be the final WIP before v095. If all looks
good, this will be identical to v095. But if we hit some major issues,
I'll try and fix those first.
The most notable part of this release is probably Jonas Quinn's fix for
the unmapped regions of the GBA memory map. This allows games like Mario
& Luigi and Zelda: Minish Cap to (hopefully) be fully playable now.
icarus now supports my game database, so all games I've dumped will be
emulated with bit-perfect memory maps and native-language game titles.
byuu says:
Changelog:
- return open bus instead of mirroring addresses on the bus (fixes
Mario&Luigi, Minish Cap, etc) [Jonas Quinn]
- add boolean flag to load requests for slotted game carts (fixes slot
load prompts)
- rename BS-X Town cart from psram to ram
- icarus: add support for game database
Note: I didn't rename "bsx" to "mcc" in the database for icarus before
uploading that. But I just fixed it locally, so it'll be in the next
WIP. For now, make it create the manifest for you and then rename it
yourself. I did fix the PSRAM size to 256kbit.
byuu says:
Updated to compile with all of the new hiro changes. My next step is to
write up hiro API documentation, and move the API from alpha (constantly
changing) to beta (rarely changing), in preparation for the first stable
release (backward-compatible changes only.)
Added "--fullscreen" command-line option. I like this over
a configuration file option. Lets you use the emulator in both modes
without having to modify the config file each time.
Also enhanced the command-line game loading. You can now use any of
these methods:
higan /path/to/game-folder.sfc
higan /path/to/game-folder.sfc/
higan /path/to/game-folder.sfc/program.rom
The idea is to support launchers that insist on loading files only.
Technically, the file can be any name (manifest.bml also works); the
only criteria is that the file actually exists and is a file, and not
a directory. This is a requirement to support the first version (a
directory lacking the trailing / identifier), because I don't want my
nall::string class to query the file system to determine if the string
is an actual existing file or directory for its pathname() / dirname()
functions.
Anyway, every game folder I've made so far has program.rom, and that's
very unlikely to change, so this should be fine.
Now, of course, if you drop a regular "game.sfc" file on the emulator,
it won't even try to load it, unless it's in a folder that ends in .fc,
.sfc, etc. In which case, it'll bail out immediately by being unable to
produce a manifest for what is obviously not really a game folder.
byuu says:
I imagine you guys will like this WIP very much.
Changelog:
- ListView check boxes on Windows
- ListView removal of columns on reset (changing input dropdowns)
- DirectSound audio duplication on latency change
- DirectSound crash on 20ms latency
- Fullscreen window sizing in multi-monitor setups
- Allow joypad bindings of hotkeys
- Allow triggers to be mapped (Xbox 360 / XInput / Windows only)
- Support joypad rumble for Game Boy Player
- Video scale settings modified from {1x,2x,3x} to {2x,3x,4x}
- System menu now renames to active emulation core
- Added fast forward hotkey
Not changing for v095:
- not adding input focus settings yet
- not adding shaders yet
Not changing at all:
- not implementing maximize
byuu says:
Changelog (since the last open beta):
- icarus is now included. icarus is used to import game files/archives
into game paks (folders)
- SNES: mid-scanline BGMODE changes now emulated correctly (used only by
atx2.smc Anthrox Demo)
- GBA: fixed a CPU bug that was causing dozens of games to have
distorted audio
- GBA: fixed default FlashROM ID; should allow much higher compatibility
- GBA: now using Cydrak's new, much improved, GBA color emulation filter
(still a work-in-progress)
- re-added command-line loading support for game paks (not for game
files/archives, sorry!)
- Qt port now compiles and runs again (may be a little buggy;
Windows/GTK+ ports preferred)
- SNES performance profile now compiles and runs again
- much more
byuu says:
Changelog:
- updated to newest hiro API
- SFC performance profile builds once again
- hiro: Qt port completed
Errata 1: the hiro/Qt target won't run tomoko just yet. Starts by
crashing inside InputSettings because hiro/Qt isn't forcefully selecting
the first item added to a ComboButton just yet. Even with a monkey patch
to get around that, the UI is incredibly unstable. Lots of geometry
calculation bugs, and a crash when you try and access certain folders in
the browser dialog. Lots of work left to be done there, sadly.
Errata 2: the hiro/Windows port has black backgrounds on all ListView
items. It's because I need to test for unassigned colors and grab the
default Windows brush colors in those cases.
Note: alternating row colors on multi-column ListView widgets is gone
now. Not a bug. May add it back later, but I'm not sure. It doesn't
interact nicely with per-cell background colors.
Things left to do:
First, I have to fix the Windows and Qt target bugs.
Next, I need to go through and revise the hiro API even more (nothing
too major.)
Next, I need to update icarus to use the new hiro API, and add support
for the SFC games database.
Next, I have to rewrite my TSV->BML cheat code tool.
Next, I need to post a final WIP of higan+icarus publicly and wait a few
days.
Next, I need to fix any bugs reported from the final WIP that I can.
Finally, I should be able to release v095.
byuu says:
Changelog:
- SNES mid-scanline BGMODE fixes finally merged (can run
atx2.zip{mode7.smc}+mtest(2).sfc properly now)
- Makefile now discards all built-in rules and variables
- switch on bool warning disabled for GCC now as well (was already
disabled for Clang)
- when loading a game, if any required files are missing, display
a warning message box (manifest.bml, program.rom, bios.rom, etc)
- when loading a game (or a game slot), if manifest.bml is missing, it
will invoke icarus to try and generate it
- if that fails (icarus is missing or the folder is bad), you will get
a warning telling you that the manifest can't be loaded
The warning prompt on missing files work for both games and the .sys
folders and their files. For some reason, failing to load the DMG/CGB
BIOS is causing a crash before I can display the modal dialog. I have no
idea why, and the stack frame backtrace is junk.
I also can't seem to abort the failed loading process. If I call
Program::unloadMedia(), I get a nasty segfault. Again with a really
nasty stack trace. So for now, it'll just end up sitting there emulating
an empty ROM (solid black screen.) In time, I'd like to fix that too.
Lastly, I need a better method than popen for Windows. popen is kind of
ugly and flashes a console window for a brief second even if the
application launched is linked with -mwindows. Not sure if there even is
one (I need to read the stdout result, so CreateProcess may not work
unless I do something nasty like "> %tmp%/temp") I'm also using the
regular popen instead of _wpopen, so for this WIP, it won't work if your
game folder has non-English letters in the path.
byuu says:
I'll post more detailed changes later, but basically:
- fixed Baldur's Gate bug
- guess if no flash ROM ID present (fixes Magical Vacation, many many
others)
- nall cleanups
- sfc/cartridge major cleanups
- bsxcartridge/"bsx" renamed to mcc/"mcc" after the logic chip it uses
(consistency with SGB/ICD2)
- ... and more!
byuu says:
Changelog:
- synchronizes lots of nall changes
- changes displayed program title from tomoko to higan(*)
- browser dialog sort is case-insensitive
- .sys folders look at user-selected library path; no longer hard-coded
Tried to get rid of the file modes from the Windows browser dialog, but
it was being a bitch so I left it on for now.
- The storage locations and binary still use tomoko. I'm not really sure
what to do here. The idea is there may be more than one "higan" UI in
the future, but I don't want people to go around calling the entire
program by the UI name. For official Windows releases, I can rename
the binaries to "higan-{profile}.exe", and by putting the config files
with the binary, they won't ever see the tomoko folder. Linux is of
course trickier.
Note: Windows users will need to edit hiro/components.hpp and comment
out these lines:
#define Hiro_Console
#define Hiro_IconView
#define Hiro_SourceView
#define Hiro_TreeView
I forgot to do that, and too lazy to upload another WIP.
byuu says:
Changelog:
- GBA emulation accuracy has been substantially improved [Cydrak]
- GBA ldm bug fixed [jchadwick]
- SNES SuperFX timing has been improved [AWJ, ARM9, qwertymodo]
- SNES accuracy profile is now ~8% faster than before
- you no longer need to copy the .sys profile folders to
~/Emulation/System
- you still need to put bios.rom (GBA BIOS) into Game Boy
Advance.sys to use GBA emulation!!
- you no longer need to pre-configure inputs before first use
- loading games / changing window size won't recenter window
- checkboxes in cheat editor update correctly
- can't type into state manager description textbox on an empty slot
- typing in state manager description box works correctly; and updates
list view correctly
- won't show files that match game extensions anymore (only game folders
show up)
- libco Win64 port fixes with FPU^H^H^H XMM registers
- libco ARM port now available; so you too can play at 15fps on an RPi2!
[jessedog3, Cydrak]
- controller selection will check the default item in the menu now on
game load
- as usual, a whole lot of other stuff I'm forgetting
Known issues:
- type-ahead find does not work in list views (eg game selection
dialog); I don't know how to fix this
- there's no game file importer yet
- there's no shader support yet
- there's no profiler available for the timing panel, you need to adjust
values manually for now
byuu says:
GBA timings are *almost* perfect now. Off by 1-3 cycles on each test,
sans a few DMA ones that seem to not run at all according to the numbers
(crazy.)
byuu says:
Fixes SuperFX fmult, lmult timings; rambr, bramr and clsr assignment
masking. Implements true GBA ROM prefetch (buggy, lower test score, but
runs Mario & Luigi without crashing on battles anymore.)
byuu says:
Small WIP, just fixes the timings for GSU multiply.
However, the actual product may still be wrong when CLSR and MS0 are
both set. Since I wasn't 'corrupting' the value in said case before,
then this behavior can only be better than before.
Turned the (cache,memory)_access_timing into functions that compute the
values; and pulled "clockspeed" into GSU.
Also, I'm thinking it might be kind of pointless to have clockspeed at
all. Supposedly even the Mario Chip can run at 21.48MHz anyway.
Enforcing 10.74MHz mode seems kind of silly. If we change it to just be
a "default value for CLSR", then we can just inline the memory access
tests without the need for the access_timing functions (literally just
clsr?2:1 then)
Slight compilation bug: go to processor/gsu/registers.hpp:33 and add
reg16_t() = default;
I missed it due to a partial recompile. Too lazy to upload another WIP
just for that.
Probably not worth doing much SuperFX testing just yet, as it looks like
they're doing some other tests at the moment on NESdev.
byuu says:
Lots more timing improvements to GBA emulation. We're now ahead of
everything but mGBA.
Mario & Luigi is still hanging in battles, so I guess my prefetch
simulation isn't as good as Cydrak's previous attempt, no surprise.
byuu says:
This WIP scores 448/920 tests passed.
Gave a shot at ROM prefetch that failed miserably (ranged from 409 to
494 tests passed. Nowhere near where it would be if it were implemented
correctly.)
Three remaining issues:
- ROM prefetch
- DMA timing
- timers (I suspect it's a 3-clock delay in starting, not a 3-clock into
the future affair)
Probably only going to be able to get the timers working without heroic
amounts of effort.
MUL timing is fixed to use idle cycles.
STMIA is fixed to set sequential at the right moments.
DMA priority support is added, so DMA 0 can interrupt DMA 1 mid-transfer.
In other news ...
I'm calling gtk_widget_destroy on the GtkWindow now, so hopefully those
Window_configure issues go away.
I realize I was leaking Display* handles in the X-video driver while
I was looking at it, so I fixed those.
I added DT_NOPREFIX so the Windows ListView will show & characters
correctly now.
byuu says:
This WIP does substantially better on endrift's GBA timing tests. Still
not perfect, though. But hopefully enough to get me out of dead last
place. I also finally fixed the THUMB-mode ldmia bug that jchadwick
reported.
So, GBA emulation should be improved quite a bit, hopefully.
byuu says:
Note: for Windows users, please go to nall/intrinsics.hpp line 60 and
correct the typo from "DISPLAY_WINDOW" to "DISPLAY_WINDOWS" before
compiling, otherwise things won't work at all.
This will be a really major WIP for the core SNES emulation, so please
test as thoroughly as possible.
I rewrote the 65816 CPU core's dispatcher from a jump table to a switch
table. This was so that I could pass class variables as parameters to
opcodes without crazy theatrics.
With that, I killed the regs.r[N] stuff, the flag_t operator|=, &=, ^=
stuff, and all of the template versions of opcodes.
I also removed some stupid pointless flag tests in xcn and pflag that
would always be true.
I sure hope that AWJ is happy with this; because this change was so that
my flag assignments and branch tests won't need to build regs.P into
a full 8-bit variable anymore.
It does of course incur a slight performance hit when you pass in
variables by-value to functions, but it should help with binary size
(and thus cache) by reducing a lot of extra functions. (I know I could
have used template parameters for some things even with a switch table,
but chose not to for the aforementioned reasons.)
Overall, it's about a ~1% speedup from the previous build. The CPU core
instructions were never a bottleneck, but I did want to fix the P flag
building stuff because that really was a dumb mistake v_v'
byuu says:
This WIP substantially restructures the ruby API for the first time
since that project started.
It is my hope that with this restructuring, destruction of the ruby
objects should now be deterministic, which should fix the crashing on
closing the emulator on Linux. We'll see I guess ... either way, it
removed two layers of wrappers from ruby, so it's a pretty nice code
cleanup.
It won't compile on Windows due to a few issues I didn't see until
uploading the WIP, too lazy to upload another. But I fixed all the
compilation issues locally, so it'll work on Windows again with the next
WIP (unless I break something else.)
(Kind of annoying that Linux defines glActiveTexture but Windows
doesn't.)
byuu says:
Added AWJ's fixes for alt/cpu (Tetris Attack framelines issue) and
alt/dsp (Thread::clock reset)
Added fix so that the taskbar entry appears when the application first
starts on Windows.
Fixed checkbox toggling inside of list views on Windows.
Updated nall/image to properly protect variables that should not be
written externally.
New Object syntax for hiro is in.
Fixed the backwards-typing on Windows with the state manager.
NOTE: the list view isn't redrawing when you change the description
text. It does so on the cheat editor because of the resizeColumns call;
but that shouldn't be necessary. I'll try and fix this for the next WIP.
byuu says:
Obviously, this is a fairly major WIP. It's the first public release in
17 months. The entire UI has been rewritten (for the 74th time), and is
now internally called tomoko. The official releases will be named higan
(both the binaries and title bar.)
Missing features from v094:
- ananke is missing (this means you will need v094 to create game
folders to be loaded)
- key assignments are limited to one physical button = one mapping (no
multi-mapping)
- shader support is missing
- audio/video profiling is missing
- DIP switch window is missing (used by NSS Actraiser with a special
manifest; that's about it)
- alternate paths for game system folders and configuration BML files
There's some new stuff, but not much. This isn't going to be an exciting
WIP in terms of features. It's more about being a brand new release with
the brand new hiro port and its shared memory model. The goal is to get
these WIPs stable, get v095 out, and then finally start improving the
actual emulation again after that.
byuu says:
Windows port should run mostly well now, although exiting fullscreen
breaks the application in a really bizarre way. (clicking on the window
makes it sink to background rather than come to the foreground o_O)
I also need to add the doModalChange => audio.clear() thing for the
accursed menu stuttering with DirectSound.
I also finished porting all of the ruby drivers over to the newer API
changes from nall.
Since I can't compile the Linux or OS X drivers, I have no idea if there
are any typos that will result in compilation errors. If so, please let
me know where they're at and I'll try and fix them. If they're simple,
please try and fix them on your end to test further if you can.
I'm hopeful the udev crash will be gone now that nall::string checks for
null char* values passed to its stringify function. Of course, it's
a problem it's getting a null value in the first place, so it may not
work at all.
If you can compile on Linux (or by some miracle, OS X), please test each
video/audio/input driver if you don't mind, to make sure there's no
"compiles okay but still typos exist" bugs.
byuu says:
Finally!! Compilation works once again on Windows.
However, it's pretty buggy. Modality isn't really working right, you can
still poke at other windows, but when you select ListView items, they
redraw as empty boxes (need to process WM_DRAWITEM before checking
modality.)
The program crashes when you close it (probably a ruby driver's term()
function, that's what it usually is.)
The Layout::setEnabled(false) call isn't working right, so you get that
annoying chiming sound and cursor movement when mapping keyboard keys to
game inputs.
The column sizing seems off a bit on first display for the Hotkeys tab.
And probably lots more.
byuu says:
The library window is gone, and replaced with
hiro::BrowserWindow::openFolder(). This gives navigation capabilities to
game loading, and it also completes our slotted cart selection code. As
an added bonus, it's less code this way, too.
I also set the window size to consistent sizes between all emulated
systems, so that switching between SFC and GB don't cause the window
size to keep changing, and so that the scaling size is consistent (eg at
normal scale, GB @ 3x is closer to SNES @ 2x.) This means black borders
in GB/GBA mode, but it doesn't look that bad, and it's not like many
people ever use these modes anyway.
Finally, added the placeholder tabs for video, audio and timing. I don't
intend to add the timing calculator code to v095 (it might be better as
a separate tool), but I'll add the ability to set video/audio rates, at
least.
Glitch 1: despite selecting the first item in the BrowserDialog list, if
you press enter when the window appears, it doesn't activate the item
until you press an arrow key first.
Glitch 2: in Game Boy mode, if you set the 4x window size, it's not
honoring the full requested height because the viewport is smaller than
the window. 8+ years of trying to get GTK+ and Qt to simply set the god
damned window size I ask for, and I still can't get them to do it
reliably.
Remaining issues:
- finish configuration panels (video, audio, timing)
- fix ruby driver compilation on Windows
- add DIP switch selection window (NSS) [I may end up punting this one
to v096]
byuu says:
I fixed the hiro layout enable bug, so when you go to assign joypad
input, the window disables itself so your input doesn't mess with the
controls.
I added "reset" to the hotkeys, in case you feel like clearing all of
them at once.
I added device selection support and the ability to disable audio
synchronization (run > 60fps) to the ruby/OSS driver. This is exposed in
tomoko's configuration file.
I added checks to stringify so that assigning null char* strings to
nall::string won't cause crashes anymore (technically the crash was in
strlen(), which doesn't check for null strings, but whatever ... I'll do
the check myself.)
I hooked up BrowserDialog::folderSelect() to loading slotted media for
now. Tested it by loading a Game Boy game successfully through the Super
Game Boy. Definitely want to write a custom window for this though, that
looks more like the library dialog.
Remaining issues:
- finish slotted cart loader (SGB, BSX, ST)
- add DIP switch selection window (NSS) [I may end up punting this one
to v096]
- add more configuration panels (video, audio, timing)
byuu says:
This updates ruby to return shared_pointer<HID::Device> objects instead
of HID::Device* objects. It also fixes an ID bug where joypads were
starting at ID# 2+, but mice were also set to ID# 2. I also revised
nall/hid a lot, with getters and setters instead of stabbing at internal
state. I didn't yet patch nall::string to safely consume nullptr const
char* values, though.
byuu says:
Main reason for this WIP was because of all the added lines to hiro for
selective component disabling. May as well get all the diff-noise apart
from code changes.
It also merges something I've been talking to Cydrak about ... making
nall::string::(integer,decimal) do built-in binary,octal,hex decoding
instead of just failing on those. This will have fun little side effects
all over the place, like being able to view a topic on my forum via
"forum.byuu.org/topic/0b10010110", heh.
There are two small changes to higan itself, though. First up, I fixed
the resampler ratio when loading non-SNES games. Tested and I can play
Game Boy games fine now. Second, I hooked up menu option hiding for
reset and controller selection. Right now, this works like higan v094,
but I'm thinking I might want to show the "Device -> Controller" even if
that's all that's there. It kind of jives nicer with the input settings
window to see the labels there, I think. And if we ever do add more
stuff, it'll be nice that people already always expect that menu there.
Remaining issues:
* add slotted cart loader (SGB, BSX, ST)
* add DIP switch selection window (NSS)
* add timing configuration (video/audio sync)
byuu says:
The input port menu was hooked up.
Alternate input support was added, although I wasn't able to test rumble
support because SDL doesn't support that, and I don't have XInput or
udev drivers on FreeBSD. This one's going to be tricky. Maybe I can test
via cross-compiling on Windows/GTK.
Added mouse capture hotkey, and auto capture/release on toggling
fullscreen (as a bonus it hides the mouse cursor.)
Added all possible video and input drivers to ruby for BSD systems.
Remaining issues before we can release v095:
- add slotted cart loader (SGB, BSX, ST)
- add DIP switch selection window (NSS)
- add timing configuration (video/audio sync)
- hide inapplicable options from system menu (eg controller ports and
reset button from handheld systems)
byuu says:
Okay yeah, lots of SNES coprocessor games were horribly broken. They
should be fixed now with the below changes:
Old syntax:
auto programROM = root["rom[0]/name"].text();
auto dataROM = root["rom[1]/name"].text();
load_memory(root["ram[0]"]);
New syntax:
auto rom = root.find("rom");
auto ram = root.find("ram");
auto programROM = rom(0)["name"].text();
auto dataROM = rom(1)["name"].text();
load_memory(ram(0));
Since I'm now relying on the XShm driver, which is multi-threaded, I'm
now compiling higan with -fopenmp. On FreeBSD, this requires linking
with -Wl,-rpath=/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc49 to get
the right version of GOMP.
This gives a pretty nice speed boost for XShm, I go from around 101fps
to 111fps at 4x scale on the accuracy profile. The combination of
inlining the accuracy-PPU and parallelizing the XShm renderer about
evenly compensates now for the ~20% CPU overclock I gave up a while ago.
The WIP also has some other niceties from the newer version of nall.
Most noticeably, cheat code database searching is now instantaneous. No
more 3-second stall.
byuu says:
This updates higan to use the new Markup::Node changes. This is a really
big change, and one slight typo anywhere could break certain classes of
games from playing.
I don't have ananke hooked up again yet, so I don't have the ability to
test this much. If anyone with some v094 game folders wouldn't mind
testing, I'd help out a great deal.
I'm most concerned about testing one of each SNES special chip game.
Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using
the fancier lookups, eg node["rom[0]/name"], which I had to convert to
a rather ugly node["rom"].at(0)["name"], which I'm fairly confident
won't work. I'm going to blame that on the fumes from the shelves I just
stained >.> Might work with node.find("rom[0]/name")(0) though ...? But
so ugly ... ugh.
That aside, this WIP adds the accuracy-PPU inlining, so the accuracy
profile should run around 7.5% faster than before.
byuu says:
Finished the cheat code system, it'll now load and save cheats.bml to
disk.
Also hooked up overscan masking. But for now you can only configure the
amount it clips via the configuration file, since I don't have a video
settings dialog anymore.
And that's the last of the low-hanging fruit. The remaining items are
all going to be a pain in the ass for one reason or another.
Short-term:
- add input port changing support
- add other input types (mouse-based, etc)
Long-term:
- add slotted cart loader (SGB, BSX, ST)
- add DIP switch selection window (NSS)
- add timing configuration (video/audio sync)
Not planned:
- video color adjustments (will allow emulated color vs raw color; but
no more sliders)
- pixel shaders
- ananke integration (will need to make a command-line version to get my
games in)
- fancy audio adjustment controls (resampler, latency, volume)
- input focus settings
- localization support (not enough users)
- window geometry memory
- anything else not in higan v094
byuu says:
Implemented the cheat database dialog, and most of the cheat editor
dialog. I still have to handle loading and saving the cheats.bml file
for each game. I wanted to finish it today, but I burned out. It's a ton
of really annoying work to support cheat codes. There's also some issue
with the width calculation for the "code(s)" column in hiro/GTK.
Short-term:
- add input port changing support
- add other input types (mouse-based, etc)
- finish cheat codes
Long-term:
- add slotted cart loader (SGB, BSX, ST)
- add DIP switch selection window (NSS)
- add overscan masking
- add timing configuration (video/audio sync)
Not planned:
- video color adjustments (will allow emulated color vs raw color; but
no more sliders)
- pixel shaders
- ananke integration (will need to make a command-line version to get my
games in)
- fancy audio adjustment controls (resampler, latency, volume)
- input focus settings
- localization support (not enough users)
- window geometry memory
- anything else not in higan v094
byuu says:
Man, over five weeks have passed without so much as touching the
codebase ... time is advancing so fast it's positively frightening. Oh
well, little by little, and we'll get there eventually.
Changelog:
- added save state slots (1-5 in the menu)
- added hotkeys settings dialog + mapping system
- added fullscreen toggle (with a cute aspect correction trick)
About three hours of work here.
Short-term:
- add input port changing support
- add other input types (mouse-based, etc)
- add cheat codes
- add timing configuration (video/audio sync)
Long-term:
- add slotted cart loader (SGB, BSX, ST)
- add DIP switch selection window (NSS)
- add cheat code database
- add state manager
- add overscan masking
Not planned:
- video color adjustments (will allow emulated color vs raw color; but
no more sliders)
- pixel shaders
- ananke integration (will need to make a command-line version to get my
games in)
- fancy audio adjustment controls (resampler, latency, volume)
- input focus settings
- relocating game library (not hard, just don't feel like it)
- localization support (not enough users)
- window geometry memory
- anything else not in higan v094
byuu says:
This version polishes up the input dialogue (reset, erase, disable
button when item not focused, split device ID from mapping name), adds
color emulation toggle, and add dummy menu items for remaining features
(to be filled in later.)
Also, it now compiles cleanly on Windows with GTK.
I didn't test with TDM-GCC-32, because for god knows what reason, the
32-bit version ships with headers from Windows 95 OSR2 only. So I built
with TDM-GCC-64 with arch=x86.
And uh, apparently, moving or resizing a window causes a Visual C++
runtime exception in the GTK+ DLLs. This doesn't happen with trance or
renshuu built with TDM-GCC-32. So, yeah, like I said, don't use -m32.
byuu says:
Changelog:
* added driver selection
* added video scale + aspect correction settings
* added A/V sync + audio mute settings
* added configuration file
* fixed compilation bugs under Windows and Linux
* fixed window sizing
* removed HSU1
* the system menu stays as "System", because "Game Boy Advance" was too
long a string for the smallest scale size
* some more stuff
You guys probably won't be ecstatic about the video sizing options, but
it's basically your choice of 1x, 2x or 4x scale with optional aspect
correction. 3x was intentionally skipped because it looks horrible on
hires SNES games. The window is resized and recentered upon loading
games. The window doesn't resize otherwise. I never really liked the way
v094 always left you with black screen areas and left you with
off-centered window positions.
I might go ahead and add the pseudo-fullscreen toggle that will jump
into 4x mode (respecting your aspect setting.)
Short-term:
* add input port changing support
* add other input types (mouse-based, etc)
* add save states
* add cheat codes
* add timing configuration (video/audio sync)
* add hotkeys (single state)
We can probably do a new release once the short-term items are
completed.
Long-term:
* add slotted cart loader (SGB, BSX, ST)
* add DIP switch selection window (NSS)
* add cheat code database
* add state manager
* add overscan masking
Not planned:
* video color adjustments (will allow emulated color vs raw color; but
no more sliders)
* pixel shaders
* ananke integration (will need to make a command-line version to get my
games in)
* fancy audio adjustment controls (resampler, latency, volume)
* input focus settings
* relocating game library (not hard, just don't feel like it)
* localization support (not enough users)
* window geometry memory
* anything else not in higan v094
byuu says:
I've hooked up the input subsystem, and the input manager to assign
hotkeys.
So far I only have digital buttons working (keyboard only), and I'm not
planning on supporting input groups again (mapping multiple physical
buttons to one emulated button), but it's progress. As with the rest of
tomoko, the code's a lot more compact. The nice thing about redoing code
so many times is that each time you get a little bit better at it.
The input configuration is saved to ~/.config/tomoko/settings.bml (just
realized that I'm an idiot and need to rename it to input.bml)
Also hooked up game saves and cartridge unloading. Active controller
changing isn't hooked up yet, and I'll probably do it differently.
Oh, and I declared the ruby lines for other platforms.
Still need to add Cydrak's Windows compilation fixes. I am nothing if
not lazy :P
byuu says:
This starts the tomoko UI. So far I have basic library loading and
video+audio output. Basically just enough to take the below screenshot.
(aside from Library, the menus are empty stubs.)
The .sys (system) game folders are now going under ~/Emulation/System,
to avoid needing root privileges to stick them into /usr/share. The game
library now shows all bootable media types, and the drop-down subtype is
gone. I'm going to display a separate modal dialog for loading slotted
games this time around. Much cleaner this way, less clutter.
tomoko's starting off a lot cleaner than ethos was, and I'm scaling back
the number of abstracted classes. What was Utility, Interface, etc are
now being merged all into Program. Of course, the real hell is the input
system. That has so many layers of bullshit that there's really no sane
way to write it.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
byuu says:
Lots of changes this time around. FreeBSD stability and compilation is
still a work in progress.
FreeBSD 10 + Clang 3.3 = 108fps
FreeBSD 10 + GCC 4.7 = 130fps
Errata 1: I've been fighting that god-damned endian.h header for the
past nine WIPs now. The above WIP isn't building now because FreeBSD
isn't including headers before using certain types, and you end up with
a trillion error messages. So just delete all the endian.h includes from
nall/intrinsics.hpp to build.
Errata 2: I was trying to match g++ and g++47, so I used $(findstring
g++,$(compiler)), which ends up also matching clang++. Oops. Easy fix,
put Clang first and then else if g++ next. Not ideal, but oh well. All
it's doing for now is declaring -fwrapv twice, so you don't have to fix
it just yet. Probably just going to alias g++="g++47" and do exact
matching instead.
Errata 3: both OpenGL::term and VideoGLX::term are causing a core dump
on BSD. No idea why. The resources are initialized and valid, but
releasing them crashes the application.
Changelog:
- nall/Makefile is more flexible with overriding $(compiler), so you can
build with GCC or Clang on BSD (defaults to GCC now)
- PLATFORM_X was renamed to PLATFORM_XORG, and it's also declared with
PLATFORM_LINUX or PLATFORM_BSD
- PLATFORM_XORG probably isn't the best name ... still thinking about
what best to call LINUX|BSD|SOLARIS or ^(WINDOWS|MACOSX)
- fixed a few legitimate Clang warning messages in nall
- Compiler::VisualCPP is ugly as hell, renamed to Compiler::CL
- nall/platform includes nall/intrinsics first. Trying to move away from
testing for _WIN32, etc directly in all files. Work in progress.
- nall turns off Clang warnings that I won't "fix", because they aren't
broken. It's much less noisy to compile with warnings on now.
- phoenix gains the ability to set background and foreground colors on
various text container widgets (GTK only for now.)
- rewrote a lot of the MSU1 code to try and simplify it. Really hope
I didn't break anything ... I don't have any MSU1 test ROMs handy
- SNES coprocessor audio is now mixed as sclamp<16>(system_sample
+ coprocessor_sample) instead of sclamp<16>((sys + cop) / 2)
- allows for greater chance of aliasing (still low, SNES audio is
quiet), but doesn't cut base system volume in half anymore
- fixed Super Scope and Justifier cursor colors
- use input.xlib instead of input.x ... allows Xlib input driver to be
visible on Linux and BSD once again
- make install and make uninstall must be run as root again; no longer
using install but cp instead for BSD compatibility
- killed $(DESTDIR) ... use make prefix=$DESTDIR$prefix instead
- you can now set text/background colors for the loki console via (eg):
- settings.terminal.background-color 0x000000
- settings.terminal.foreground-color 0xffffff
byuu says:
Changelog for loki:
- added command aliases (match with * [sorry, regex lib isn't available
everywhere yet], replace with {1}+)
- added command hotkeys
- added window geometry saving
- added save state support
- added power/reset commands
- added an input manager, so you can remap keys (limiting it to the
keyboard for now though)
The combination of aliases and hotkeys really makes things shine. Save
states will temporarily disable your breakpoints (run/step are
technically temporary breakpoints) so as to ensure the state is captured
at a good time. In practice, this should pose about as much of a problem
as higan desyncing and breaking when capturing states ... should be
exceedingly rare to ever even notice this behavior at all, with 99.9% of
state captures happening in half an instruction boundary. But still,
keep it in mind, as you might see the CPU step one instruction ahead.
Tracing and usage map functionality is still enabled during state
synchronization.
So at this point, I have 100% of the essential stuff in. All that's left
now is to add polish / wishlist features like bass and mosaic
integration.
byuu says:
New terminal is in. Much nicer to use now. Command history makes a major
difference in usability.
The SMP is now fully traceable and debuggable. Basically they act as
separate entities, you can trace both at the same time, but for the most
part running and stepping is performed on the chip you select.
I'm going to put off CPU+SMP interleave support for a while. I don't
actually think it'll be too hard. Will get trickier if/when we support
coprocessor debugging.
Remaining tasks:
- aliases
- hotkeys
- save states
- window geometry
Basically, the debugger's done. Just have to add the UI fluff.
I also removed tracing/memory export from higan. It was always meant to
be temporary until the debugger was remade.
byuu says:
Commands can be prefixed with: (cpu|smp|ppu|dsp|apu|vram|oam|cgram)/ to
set their source. Eg "vram/hex 0800" or "smp/breakpoints.append execute
ffc0"; default is cpu.
These overlap a little bit in odd ways, but that's just the way the SNES
works: it's not a very orthogonal system. CPU is both a processor and
the main bus (ROM, RAM, WRAM, etc), APU is the shared memory by the
SMP+DSP (eg use it to catch writes from either chip); PPU probably won't
ever be used since it's broken down into three separate buses (VRAM,
OAM, CGRAM), but DSP could be useful for tracking bugs like we found in
Koushien 2 with the DSP echo buffer corrupting SMP opcodes. Technically
the PPU memory pools are only ever tripped by the CPU poking at them, as
the PPU doesn't ever write.
I now have run.for, run.to, step.for, step.to. The difference is that
run only prints the next instruction after running, whereas step prints
all of the instructions along the way as well. run.to acts the same as
"step over" here. Although it's not quite as nice, since you have to
specify the address of the next instruction.
Logging the Field/Vcounter/Hcounter on instruction listings now, good
for timing information.
Added in the tracer mask, as well as memory export, as well as
VRAM/OAM/CGRAM/SMP read/write/execute breakpoints, as well as an APU
usage map (it tracks DSP reads/writes separately, although I don't
currently have debugger callbacks on DSP accesses just yet.)
Have not hooked up actual SMP debugging just yet, but I plan to soon.
Still thinking about how I want to allow / block interleaving of
instructions (terminal output and tracing.)
So ... remaining tasks at this point:
- full SMP debugging
- CPU+SMP interleave support
- aliases
- hotkeys
- save states (will be kind of tricky ... will have to suppress
breakpoints during synchronization, or abort a save in a break event.)
- keep track of window geometry between runs
byuu says:
Changelog:
- target-ethos/ is now target-higan/ (will unfortunately screw up diffs
pretty badly at this point.)
- had a serious bug in nall::optional<T>::operator=, which is now fixed.
- added tracer (no masking just yet, I need to write a nall::bitvector
class because I don't want to hard-code those anymore.)
- added usage logging (keep track of RWX/EP states for all bus
addresses.)
- added read/write to poke at memory (hex also works for reading, but
this one can poke at MMIO regs and is for one address only.)
- added both run.for (# of instructions) and run.to (program counter
address.)
- added read/write/execute breakpoints with counters for a given
address, and with an optional compare byte (for read/write modes.)
About the only major things left now for loki is support for trace
masking, memory export, and VRAM/OAM/CGRAM access.
For phoenix/Console, I really need to add a history to up+down arrows,
and I should support left/right insert-at.
byuu says:
Changelog:
- ethos: use nall::programpath() instead of realpath(argv[0]) to get
executable path
- loki: add presentation window
- loki: add terminal window
- loki: add interface to emulation core
- loki: add ruby
- loki: add enough support to run games and save data on exit
- load game folders via command-line (or drop folder onto binary),
use "r" to start, "p" to pause ... temporary command names
I'll probably have to say this several times, but for now, loki is only
available on Linux/GTK+, due to the use of the Console widget. Support
for other platforms can come later easily enough.
byuu says:
Changelog:
- port: various compilation fixes for OS X [kode54]
- nall: added programpath() function to return path to process binary
[todo: need to have ethos use this function]
- ruby: XAudio2 will select default game sound device instead of first
sound device
- ruby: DirectInput device IDs are no longer ambiguous when VID+PID are
identical
- ruby: OpenGL won't try and terminate if it hasn't been initialized
- gb: D-pad up+down/left+right not masked in SGB mode
- sfc: rewrote ICD2 video rendering to output in real-time, work with
cycle-based Game Boy renderer
- sfc: rewrote Bus::reduce(), reduces game loading time by about 500ms
- ethos: store save states in {game}/higan/* instead of {game}/bsnes/*
- loki: added target-loki/ (blank stub for now)
- Makefile: purge out/* on make clean
byuu says:
This release adds support for game libraries, and substantially improves
Game Boy and Game Boy Color emulation with cycle-based renderers. Many
other changes are also present.
It's very important to note that this release now defaults to optimal
drivers rather than safe drivers. This is particularly important if you
do not have strong OpenGL 3.2 drivers. If performance is bad, go to
Settings -> Configuration -> Advanced, change the video driver, and
restart higan. In the rare case that you have trouble opening higan, you
can edit settings.bml directly and change the setting there. The Windows
safe driver is Direct3D, and the Linux safe driver is XShm.
Also note that although display emulation shaders are now supported,
they have not been included in this release as they are not ready yet.
The support has been built-in anyway, so that they can be tested by
everyone. Once refined, future releases of higan will come with built-in
shaders for each emulated system that simulates the unique display
characteristics of each.
Changelog (since v093):
- sfc: added SA-1 MDR support (fixes SD Gundam G-Next bug)
- sfc: remove random/ and config/, merge to system/ with better
randomization
- gb: improved color emulation palette contrast
- gbc: do not sort sprites by X-priority
- gbc: allow transparency on BG priority pixels
- gbc: VRAM DMA timing and register fixes
- gbc: block invalid VRAM DMA transfer source and target addresses
- gba: added LCD color emulation (without it, colors are grossly
over-saturated)
- gba: removed internal frame blending (use shaders to simulate motion
blur if desired)
- gba: added Game Boy Player support (adds joypad rumble support to
supported games)
- gba: SOUND_CTL_H is readable
- gb/gbc: PPU renderer is now cycle-based (major accuracy improvement)
- gb/gbc: OAM DMA runs in parallel with the CPU
- gb/gbc: only HRAM can be accessed during OAM DMA
- gb/gbc: fixed serialization of games with SRAM
- gb/gbc: disallow up+down or left+right at the same time
- gb/gbc: added weak hipass filter to remove DC bias
- gb/gbc: STAT OAM+Hblank IRQs only trigger during active display
- gb/gbc: fixed underflow in window clamping
- gb/gbc/gba: audio mixes internally at 2MHz now instead of 4MHz (does
not affect accuracy)
- gb/gbc/gba: audio volume reduced for consistency with other systems
- fc/sfc/gb/gbc/gba: cheat codes are now stored in universal, decrypted
format
- ethos: replaced file loader with a proper game library
- ethos: added display emulation shader support
- ethos: added color emulation option to video settings
- ethos: program icon upgraded from 48x48 to 512x512
- ethos: settings and tools windows now use tab frames (less wasted
screen space)
- ethos: default to optimal (video, audio, input) drivers instead of
safest drivers
- ethos: input mapping system completely rewritten to support
hotplugging and unique device mappings
- ruby: added fixes for OpenGL 3.2 on AMD graphics cards
- ruby: quark shaders now support user settings inside of manifest
- ruby: quark shaders can use integral textures (allows display
emulation shaders to work with raw colors)
- ruby: add joypad rumble support
- ruby: XInput (Xbox 360) controllers now support hotplugging
- ruby: added Linux udev joypad driver with hotplug support
- phoenix: fixed a rare null pointer dereference issue on Windows
- port: target -std=c++11 instead of -std=gnu++11 (do not rely on GNU
C++ extensions)
- port: added out-of-the-box compilation support for BSD/Clang 3.3+
- port: applied a few Debian upstream patches
- cheats: updated to mightymo's 2014-01-02 release; decrypted all Game
Genie codes
byuu says:
This WIP removes nall/input.hpp entirely, and implements the new
universal cheat format for FC/SFC/GB/GBC/SGB.
GBA is going to be tricky since there's some consternation around
byte/word/dword overrides.
It's also not immediately obvious to me how to implement the code search
in logarithmic time, due to the optional compare value.
Lastly, the cheat values inside cheats.bml seem to be broken for the
SFC. Likely there's a bug somewhere in the conversion process. Obviously
I'll have to fix that before v094.
I received no feedback on the universal cheat format. If nobody adds
anything before v094, then I don't want to hear any complaining about
the formatting :P
byuu says:
Not an official WIP (a WIP WIP? A meta-WIP?), just throwing in the new
fullscreen code, and I noticed that OpenGL colors in 30-bit mode are all
fucked up now for some strange reason. So I'm just using this snapshot
to debug the issue.
byuu says:
I've completely redone the ethos InputManager and ruby to work on
HID::Device objects instead of one giant scancode pool.
Currently only the udev driver supports the changes to ruby, so only
Linux users will be able to compile and run this WIP build.
The nice thing about the new system is that it's now possible to
uniquely identify controllers, so if you swap out gamepads, you won't
end up with it working but with all the mappings all screwed up. Since
higan lets you map multiple physical inputs to one emulated input, you
can now configure your keyboard and multiple gamepads to the same
emulated input, and then just use whatever controller you want.
Because USB gamepad makers failed to provide unique serial#s with each
controller, we have to limit the mapping to specific USB ports.
Otherwise, we couldn't distinguish two otherwise identical gamepads. So
basically your computer USB ports act like real game console input port
numbers. Which is kind of neat, I guess.
And the really nice thing about the new system is that we now have the
capability to support hotplugging input devices. I haven't yet added
this to any drivers, but I'm definitely going to add it to udev for v094
official.
Finally, with the device ID (vendor ID + product ID) exposed, we gain
one last really cool feature that we may be able to develop more in the
future. Say we created a joypad.bml file to include with higan. In it,
we'd store the Xbox 360 controller, and pre-defined button mappings for
each emulated system. So if higan detects you have an Xbox 360
controller, you can just plug it in and use it. Even better, we can
clearly specify the difference between triggers and analog axes, and
name each individual input. So you'd see "Xbox 360 Gamepad #1: Left
Trigger" instead of higan v093's "JP0::Axis2.Hi"
Note: for right now, ethos' input manager isn't filtering the device IDs
to look pretty. So you're going to see a 64-bit hex value for a device
ID right now instead of something like Joypad#N for now.
byuu says:
Changelog:
- GBA: SOUND_CTL_H is readable, fixes sound effects in Mario&Luigi
Superstar Saga [Cydrak] (note: game is still unplayable due to other
bugs)
- phoenix/Windows: workaround for Win32 API ListView bug, fixes slot
loading behavior
- ruby: added udev driver for Linux with rumble support, and added
rumble support to existing RawInput driver for XInput and DirectInput
- ethos: added new "Rumble" mapping to GBA input assignment, use it to
tell higan which controller to rumble (clear it to disable rumble)
- GBA: Game Boy Player rumble is now fully emulated
- core: added new normalized raw-color palette mode for Display
Emulation shaders
The way rumble was added to ethos was somewhat hackish. The support
doesn't really exist in nall.
I need to redesign the entire input system, but that's not a change
I want to make so close to a release.
byuu says:
Changelog:
- Game Boy (Color): STAT OAM+HBlank IRQs only trigger during LY=0-143
with display enabled
- fixes backgrounds and text in Wacky Races
- Game Boy (Color): fixed underflow in window clamping
- fixes Wacky Races, Prehistorik Man, Alleyway, etc
- Game Boy (Color): LCD OAM DMA was running too slow
- fixes Shin Megami Tensei - Devichil - Kuro no Sho
- Game Boy Advance: removed built-in frame blending; display emulation
shaders will handle this going forward
- Game Boy Advance: added Game Boy Player emulation
- currently the screen is tinted red during rumble, no actual gamepad
rumble support yet
- this is going to be slow, as we have to hash the frame to detect the
GBP logo, it'll be optional later on
- Emulator::Interface::Palette can now output a raw palette (for Display
Emulation shaders only)
- color channels are not yet split up, it's just the raw packed value
byuu says:
Changelog:
- GB/C OAM DMA now runs in parallel with the CPU
- CPU can only access HRAM during OAM DMA
- fixed SGB mode again
- brand new config files will default to the optimal drivers now
(OpenGL, etc) instead of the safest
- hopefully fixed remaining Windows UI issues
byuu says:
Changelog:
- Game Boy and Game Boy Color now have a weak hipass filter to remove DC
bias (or whatever)
- Game Boy and Game Boy Color now have cycle-based PPU renderers instead
of scanline-based renderers
- improved Game Boy color emulation palette contrast
- fixed GTK+ ListView selection bug
- fixed a typo when saving states (should say "Saved to slot N", not
"Save to slot N")
byuu says:
Changelog:
- importing a game won't show message box on success
- importing a game will select the game that was imported in the list
- caveat: GTK+ port doesn't seem to be removing focus from item 0 even
though the selection is on item 2
- Game Boy audio reduced in volume by 50%
- Game Boy Advance audio reduced in volume by 50%
- Game Boy internally mixes audio at 2MHz now
- Game Boy Advance's Game Boy audio hardware internally mixes audio at
2MHz now
- Game Boy Color doesn't sort sprites by X-coordinate
- Game Boy Color allows transparency on BGpriority pixels
- caveat: this seems to allow sprites to appear on top of windows
- Game Boy Color VRAM DMA transfers 16 bytes in 8 clocks (or 16 clocks
in double speed mode)
- Game Boy Color VRAM DMA masks low 4-bits of source and destination
address
- Game Boy Color VRAM DMA only allows reads from ROM or RAM
- Game Boy Color VRAM DMA only allows writes to VRAM
- fixed a bug in dereferencing a nullptr from pObject::find(), should
fix crash when pressing enter key on blank windows
- fixed Windows RadioItem selection
- Game Boy Advance color emulation code added
byuu says:
Changelog:
- Windows port should compile out-of-the-box
- InputManager::scancode[] initialized at startup
- Library menu shows item for each bootable media type (notably Game Boy
Color)
- Display Emulation menu selection fix
- LibraryManager load button works now
- Added hotkey to show library manager (defaults to L)
- Added color emulation to video settings (missing on GBA for now)
- SFC loading SGB without GB cartridge no longer segfaults
- GB/GBC system.load() after cartridge.load()
- GB/GBC BG-over-OAM fix
- GB/GBC disallow up+down and left+right
byuu says:
Updated to support latest phoenix changes.
Converted Settings and Tools to TabFrame views.
Errata:
- phoenix/Windows ComboButton wasn't calling parent
pWidget::setGeometry() [fixed locally]
- TRACKBAR_CLASS draws COLOR_3DFACE for the background even when its
parent is a WC_TABCONTROL
byuu says:
Changelog:
- nall: fixed major memory leak in string class
- ruby: video shaders support #define-based settings now
- phoenix/GTK+: support > 256x256 icons for window / task bar / alt-tab
- sfc: remove random/ and config/, merge into system/
- ethos: delete higan.png (48x48), replace with higan512.png (512x512)
as new higan.png
- ethos: default gamma to 100% (no color adjustment)
- ethos: use "Video Shaders/Display Emulation/" instead of "Video
Shaders/Emulation/"
- use g++ instead of g++-4.7 (g++ -v must be >= 4.7)
- use -std=c++11 instead of -std=gnu++11
- applied a few patches from Debian upstream to make their packaging job
easier
So because colors are normalized in GLSL, I won't be able to offer video
shaders absolute color literals. We will have to perform basic color
conversion inside the core.
As such, the current plan is to create some sort of Emulator::Settings
interface. With that, I'll connect an option for color correction, which
will be on by default. For FC/SFC, that will mean gamma correction
(darker / stronger colors), and for GB/GBC/GBA, it will mean simulating
the weird brightness levels of the displays. I am undecided on whether
to use pea soup green for the GB or not. By not doing so, it'll be
easier for the display emulation shader to do it.
byuu says:
Changelog:
- added SA-1 MDR; fixes bug in SD Gundam G-Next where the main
battleship was unable to fire
- added out-of-the-box support for any BSD running Clang 3.3+ (FreeBSD
10+, notably)
- added new video shader, "Display Emulation", which changes the shader
based on the emulated system
- fixed the home button to go to your default library path
- phoenix: Windows port won't send onActivate unless an item is selected
(prevents crashing on pressing enter in file dialog)
- ruby: removed vec4 position from out Vertex {} (helps AMD cards)
- shaders: updated all shaders to use texture() instead of texture2D()
(helps AMD cards)
The "Display Emulation" option works like this: when selected, it tries
to load "<path>/Video Shaders/Emulation/<systemName>.shader/"; otherwise
it falls back to the blur shader. <path> is the usual (next to binary,
then in <config>/higan, then in /usr/share/higan, etc); and <systemName>
is "Famicom", "Super Famicom", "Game Boy", "Game Boy Color", "Game Boy
Advance"
To support BSD, I had to modify the $(platform) variable to
differentiate between Linux and BSD.
As such, the new $(platform) values are:
win -> windows
osx -> macosx
x -> linux or bsd
I am also checking uname -s instead of uname -a now. No reason to
potentially match the hostname to the wrong OS type.
byuu says:
Changelog:
- added Cocoa target: higan can now be compiled for OS X Lion
[Cydrak, byuu]
- SNES/accuracy profile hires color blending improvements - fixes
Marvelous text [AWJ]
- fixed a slight bug in SNES/SA-1 VBR support caused by a typo
- added support for multi-pass shaders that can load external textures
(requires OpenGL 3.2+)
- added game library path (used by ananke->Import Game) to
Settings->Advanced
- system profiles, shaders and cheats database can be stored in "all
users" shared folders now (eg /usr/share on Linux)
- all configuration files are in BML format now, instead of XML (much
easier to read and edit this way)
- main window supports drag-and-drop of game folders (but not game files
/ ZIP archives)
- audio buffer clears when entering a modal loop on Windows (prevents
audio repetition with DirectSound driver)
- a substantial amount of code clean-up (probably the biggest
refactoring to date)
One highly desired target for this release was to default to the optimal
drivers instead of the safest drivers, but because AMD drivers don't
seem to like my OpenGL 3.2 driver, I've decided to postpone that. AMD
has too big a market share. Hopefully with v093 officially released, we
can get some public input on what AMD doesn't like.
byuu says:
Changelog:
- you can now drop game folders (not game files, sorry) onto higan's
main window to load them
- audio buffer will clear on Windows when entering modal loop (entering
menu, moving or resizing window)
- this prevents DirectSound driver's audio repetition
- ruby defaults to the optimal driver for each platform, rather than the
safest driver, now
- added Cydrak's gl_Position.zw change to ruby
- added fixes for all the changes to nall, ruby, phoenix over the past
three months
byuu says:
This will be another massive diff from the previous version.
All of higan was updated to use the new foo& bar syntax, and I also
updated switch statements to be consistent as well (but not in the
disassemblers, was starting to get an RSI just from what I already did.)
phoenix/{windows, cocoa, qt} need to be updated to use "string foo"
instead of "const string& foo", and after that, the major diffs should
be finished.
This archive is the first time I'm posting my copy-on-write,
size+capacity nall::string class, so any feedback on that is welcome as
well.
byuu says:
Changelog:
- fixed cartridge load window focus on Windows
- lots of updates to nall, ruby and phoenix
- ethos and Emulator::Interface updated from "foo &bar" to "foo& bar"
syntax (work-in-progress)
Before I had mixed the two ways to declare variables/arguments all over
the place, so the goal is to unify them all for consistency. So the
changelog for this release will be massive (750KB >.>) due to the syntax
change. Yeah, that's what I spent the last three days working on ...
byuu says:
- OpenGL should work on OS X now; it uses VAOs and VBOs, and is fully
OpenGL 3.2 core compliant
- all configuration files are now stored in BML format, instead of CFG
format (half the size, much more readable)
- some old nall libraries that were never used have been removed
- make install works with or without root now (copies core files to
/usr/share/higan [non-configurable])
- make install also works on OS X (copies to /Library/Application
Support/higan)
byuu says:
Changelog:
- added support for ruby shader folders (place in "Video Shaders/")
- higan now also looks in your shared folder for configuration files and
system media folders
- added CFBundleExecutable key to OS X Info.plist
Shared folder locations:
- Windows XP: C:\Documents and Settings\All Users\Application Data\higan
- Windows 7: C:\ProgramData\higan
- OS X: /Library/Application Support/higan
- Linux: /etc/higan
Evaluation order:
- look for item in binary folder: if found, use this folder
- look for item in user folder: if found, use this folder
- look for item in shared folder: if found, use this folder
- create item in user folder
For people repackaging higan for other distros: you should chmod 777
/etc/higan. Failure to do so could result in higan breaking. No, I will
not copy the files from the shared path to the user path.
byuu says:
This release should be polished enough for a general release.
This release should be polished enough for a general release.
Anyone with a real, clean Mac up for posting compiled binaries?
Preferably compile with "make profile=balanced" In fact, I'd like it if
someone were willing to host a "higan for Mac" page, with binaries of
each of the latest releases. Only really needed for major official
releases, but it'd be preferable to have the builds updated as soon as
possible after I post new builds.
Changelog:
- no more keyboard chimes when pressing keys
- status bar added, fully functional
- Label::minimumSize() takes frame into account (but note a few places
hard-code raw Font::size(), so a few text labels are still clipped)
- resizing the main window looks smooth regardless of whether a game is
running or not
- currently, resizing the window pauses the emulation. Allowing it to
run the main loop was lagging out the window resize process too much
to be worth it
Additional OS X integration enhancements:
- closing the main window unloads the current game, but does not quit
the application (quit via the main menu or the dock menu)
- clicking the icon in the dock will (re)display the main menu
byuu says:
This is the first release with full support for OS X, although it's
certainly still very buggy.
Known issues:
- window status bars are still unsupported (they just don't show up)
- you get the bad keypress chime when you use the keyboard
- window geometry and font metrics aren't perfect (bit of clipping here
and there)
- list view headers that aren't auto-sized are sometimes too short (file
browser)
- input assignment is really rough (assigning a key also moves around in
the list or beeps at you)
Custom OS X integration support so far:
- 512x512 ICNS application icon: will look razor-sharp even on a retina
display
- basic Info.plist added to application bundle
- program menu about, preferences, quit all connected
- Settings->Configuration removed (use higan->Preferences instead)
- global menubar
To compile and use this, you'll need:
- Xz Utils (to extract .tar.xz)
- Xcode 4.6
- Lion 10.7.4 or newer
mkdir higan_v092r04
tar -xJf higan_v092r04.tar.xz -C higan_v092r04
cd higan_v092r04
make -j 2
ananke is missing, and I haven't updated purify yet, so you'll have to
move game folders from Windows or Linux over, or make them by hand (a
not so enjoyable experience, to say the least.)
byuu says:
This release adds the phoenix/Cocoa port, and rewrites a lot of the
higan user interface to work with all of the new changes (like blocking
in the main run loop and in modal windows.)
It doesn't yet modify the compilation flags to actually build on OS
X yet, and even then, we don't really have ruby drivers, so there'd be
no video, audio or input.
Two months between a single WIP point release ... for the first six
years, I never went more than a month without a full official release.
I guess I should be happy that it's become so refined, but I sure do
miss those halcyon days of exciting progress.
byuu says:
Changelog:
- merged AWJ's hires color blending improvements (most notably: fixes
Marvelous' text)
- created sfc/base/ to store base unit (expansion port device) emulation
- synchronized the markup of Satellaview and Sufami Turbo cartridge
slots in the board markup
- fixed "Initializing ..." typo in timing settings
If at all possible, I'd really like to have heavy testing of games that
use hires graphics to check for any regressions.
I trust AWJ's code, and all of the test ROMs I have thrown at it all
appear to work great. But better safe than sorry. Same deal for any core
changes, it's a lot better to catch it now than after v093 is released.
byuu says:
higan changelog:
- compiler is set to g++-4.7, subst(cc,++) rule is gone, C files compile
with $(compiler) -x c
- make throws an error when you specify an invalid profile or compile on
an unsupported platform (instead of hanging forever)
- added unverified.png to resources (causes too big of a speed hit to
actually check for folder/unverified file ... so disabled for now)
- fixed default browser paths for Game Boy, Sufami Turbo and BS-X
Satellaview (have to delete paths.cfg to see this)
- browser home button seeks to configpath()/higan/library.cfg
- settings->driver is now settings->advanced, and it adds game library
path setting and profile information
- emulation cores now load manifest files internally, manifest.bml is
not required for a game folder to be recognized by higan as such
- BS-X Satellaview and Sufami Turbo slot cartridge handling moved out of
sfc/chip and into sfc/slot
- Video::StartFullScreen only sets fullscreen when a game is specified
on the command-line
purify and ananke changelog:
- library output path shown in purify window
- added button to change library path
- squelch firmware warning windows to prevent multi-threading crash, but
only via purify (they show up in higan still)
byuu says:
This release has an updated version of ananke. If you replace the higan
v092 ananke.dll with this new one, it will fix the SGB+TG3000+ToP+DKJM2
loading issues.
This version fixes a problem where ananke would leave out the
'information' section (that is, the game name) when converting a game to
a game folder, resulting in a folder named " (!)".
It also includes the latest version of nall.
Because byuu's Win32 compiler does not yet support the C++11 std::thread
API, he wrote his own portable wrapper library, so now the new purify
works on Windows too.
byuu says:
purify has been rewritten. It now resembles the older snespurify, and
lets you import multiple game files+archives and regenerate manifests
for multiple game folders. It is also recursive.
So you can now import all of your games for all systems at once, or you
can update all of your bsnes v091 game folders to the new higan v092
format at once.
Caveats:
First, I am now using std::thread, so that the GUI doesn't freeze.
Instead, you get a nice progress bar. Unfortunately, I was mislead and
TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but
I can't compile purify for Windows. I am sick and tired of not being
able to write multi-threaded code, so fuck it. If anyone can get it to
build on Windows, whether that be by using Windows threads, hacking in
std::thread support, skipping threading all together, whatever ...
that'll be great. Otherwise, sorry, purify is Linux only until MinGW can
get its god damned shit together and offers threading support.
Second, there's no way to regenerate Famicom (NES) manifests, because we
discard the iNES header. We are going to need a database for that. So,
all I can suggest is that if you use bsnes/higan, keep all your iNES
images around to re-import as new releases come out.
Third, when you purify game folders, it will back up the ROM and RAM
files only. Your save states, cheat codes, debug logs, etc will be wiped
out. There's a whole lot of reasons for this, the most pertinent is that
it's meant to clean up the folder to a pristine state. It also fixes the
game folder name, etc. So ... sorry, but this is how it works. New
releases rarely if ever allow old save states to work anyway.
Lastly, I am not going to have purify contain infinite backward
compatibility for updating manifests. You will want to keep up with
purifying the collection, otherwise you'll have to grab older purify
copies and convert your way along. Although hopefully the format won't
be so volatile and this won't be necessary very often.
byuu says:
For higan:
- I fixed the data ROM/RAM initialization for the Cx4, which would
periodically cause a crash.
- I also moved the Satellaview MaskROM vs FlashROM detection into the
Satellaview manifests, so Same Game - Character Data works now.
- I also re-added the driver filter to the video shaders, so the D3D
driver won't show OGL shaders and vice versa.
For ananke:
- You can now generate the other SGB images by putting sgb.rom in the
same folder as the BIOS images.
- I fixed the markup in the database and via heuristics for 5MB+ games
(DKJM2, ToP)
- Sufami Turbo and BS-X Satellaview generate BML now instead of XML when
using heuristics.
In the release thread, byuu says:
The first official release of higan has been posted. higan is the
new name for bsnes, and it continues with the latter's version
numbering.
Note that as of now, bsnes still exists. It's a module distributed
inside of higan. bsnes is now specific to my SNES emulator.
Due to last minute changes to the emulator interface, and missing
support in ananke, I wasn't able to include Cydrak's Nintendo DS
emulator dasShiny in this build, but I hope to do so in the next
release.
http://code.google.com/p/higan/downloads/list
For both new and experienced users, please read the higan user guide
first:
http://byuu.org/higan/user-guide
In the v091 WIP thread, byuu says:
r15->r16:
- BS-X MaskROM handling (partial ... need to split bsx/flash away
from sfc/chip, restructure code - it requires tagging the base
cart markup for now, but it needs to parse the slotted cart
markup)
- phoenixflags / phoenixlink += -m32
- nall/sort stability
- if(input.poll(scancode[activeScancode]) == false) return;
- MSU1 / USART need to use interface->path(1)
- MSU1 needs to use Markup::Document, not XML::Document
- case-insensitive folder listings
- remove nall/emulation/system.hpp files (move to ananke)
- remove rom/ram id= checks with indexing
X have cores ask for manifest.bml (skipped for v092's release, too
big a change)
- rename compatibility profile to balanced (so people don't assume
it has better compatibility than accuracy)
byuu says:
Changelog:
- all media types always show base name in the title now (eg Super Game
Boy + Mega Man II)
- Game Boy loading via ananke has been fixed
- phoenix is dynamically linked on Windows now (needed for ananke)
- Linux port shows the higan program icon (once you install the program
to get the bitmap into /usr/local/share/pixmaps)
- paths.cfg defaults to "userpath()/Emulation/System Name/" when it is
created from scratch
[Later, after the v092 release, byuu posted this additional changelog:
- new compilation rules for win32
- OS::setName
- default to ~/Emulation/media.name for paths.cfg
]
byuu says:
higan changelog:
- generates title displayed in emulator window by asking the core
- core builds title solely from "information/title" ... if it's not
there, you don't get a title at all
- sub-system load menu is gone ... since there are multiple revisions of
the SGB, this never really worked well anyway
- to load an SGB, BS-X or ST cartridge, load the base cartridge first
- "File->Load Game" moved to "Load->Import Game" ... may cause a bit of
confusion to new users, but I don't like having a single-item menu,
we'll just have to explain it to new users
- browser window redone to look like ananke
- home button here goes to ~/Emulation rather than just ~ like ananke,
since this is the home of game folders
- game folder icon is now the executable icon for the Tango theme
(orange diamond), meant to represent a complete game rather than
a game file or archive
ananke changelog:
- outputs GBC games to "Game Boy Color/" instead of "Game Boy/"
- adds the file basename to "information/title"
Known issues:
- using ananke to load a GB game trips the Super Famicom SGB mode and
fails (need to make the full-path auto-detection ignore non-bootable
systems)
- need to dump and test some BS-X media before releasing
- ananke lacks BS-X Satellaview cartridge support
- v092 isn't going to let you retarget the ananke/higan game folder path
of ~/Emulation, you will have to wait for a future version if that
bothers you so greatly
[Later, after the v092 release, byuu posted this additional changelog:
- kill laevateinn
- add title()
- add bootable, remove load
- combine file, library
- combine [][][] paths
- fix SFC subtype handling XML->BML
- update file browser to use buttons
- update file browser keyboard handling
- update system XML->BML
- fix sufami turbo hashing
- remove Cartridge::manifest
]
byuu says:
This should be basically final now.
Works with all media types (nes, sfc, gb, gbc, gba, bs, st), strips
headers, can use internal or external firmware, imports saves on first
run.
Added a custom file dialog. It seems both GTK+ and Windows XP have
(un)intelligent file sorting, which puts eg "ActRaiser 2 (NA)" before
"ActRaiser (NA)". So, screw 'em.
byuu says (about higan):
- dropped release/ root node for individual games (still there in
ananke's database.)
- Memory export uses smarter names (vram.rwm -> video.ram, etc.)
- cheat database moved from XML to BML (3.1MB to 1.9MB file size.)
- cheat codes moved from XML to BML
- resource manifest moved from XML to BML
What can I say, I like consistency. But I'll leave the shaders alone
until I get around to shader folders.
byuu says (about ananke):
Works with higan v091r13. Only does SNES stuff so far.
byuu says:
This release refines HSU1 support as a bidirectional protocol, nests SFC
manifests as "release/cartridge" and "release/information" (but release/
is not guaranteed to be finalized just yet), removes the database
integration, and adds support for ananke.
ananke represents inevitability. It's a library that, when installed,
higan can use to load files from the command-line, and also from a new
File -> Load Game menu option.
I need to change the build rules a bit for it to work on Windows (need
to make phoenix a DLL, basically), but it works now on Linux.
Right now, it only takes *.sfc file names, looks them up in the included
database, converts them to game folders, and returns the game folder
path for higan to load.
The idea is to continue expanding it to support everything we can that
I don't want in the higan core:
- load *.sfc, *.smc, *.swc, *.fig files
- remove SNES copier headers
- split apart merged firmware files
- pull in external firmware files (eg dsp1b.rom - these are staying
merged, just as SPC7110 prg+dat are merged)
- load *.zip and *.7z archives
- prompt for selection on multi-file archives
- generate manifest files based on heuristics
- apply BPS patches
The "Load" menu option has been renamed to "Library", to represent games
in your library. I'm going to add some sort of suffix to indicate
unverified games, and use a different folder icon for those (eg
manifests built on heuristics rather than from the database.)
So basically, to future end users:
File -> Load Game will be how they play games.
Library -> (specific system) can be thought of as an infinitely-sized
recent games list.
purify will likely become a simple stub that invokes ananke's functions.
No reason to duplicate all that code.
[r07 and r08 were not posted to the WIP thread. -Ed.]
byuu says:
I'd appreciate it if you guys wouldn't mind testing out the database
functionality.
Save this file as database.bml (remove the date) inside
~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/
http://byuu.org/snes/database/database_2012-10-21.bml
Now load any of the 20 games in the database from the file dialog. They
need to be named *.sfc, have no copier header, and have firmware
appended (for Mario Kart only so far.)
If anyone actually does test it, please let me know how it goes for you
and what you think. Note that future versions of higan will have the
database.bml file included with the release.
byuu says:
This release adds initial database support.
The way it works is you can now load game folders as you always have, or
you can load a game file. If you load a game file, it tries to create
a game folder for you by looking up the file's sha256 in a database. If
it can't find it, sorry, the game won't play. I'm not hooking up the
oldschool "make up a manifest" code here. The easiest way to handle this
is to get me every game so I can dump it and add it to the database :D
The database entries are complete entries that can be copied directly.
So it describes the board, the information, file layout, etc. That'll be
what comes with higan releases in the future.
Internally, I'm separating the information and board descriptions, and
will use a tool to merge the two together.
Here's a current database copy, with one game in it. Still hammering out
some details, but it's mostly how it's going to look.
cartridge region=NTSC
board type=1CB5B-20
superfx revision=2
rom name=program.rom size=0x200000
ram name=save.rwm size=0x8000
map id=io address=00-3f,80-bf:3000-32ff
map id=rom address=00-3f:8000-ffff mask=0x8000
map id=rom address=40-5f:0000-ffff
map id=ram address=00-3f,80-bf:6000-7fff size=0x2000
map id=ram address=70-71:0000-ffff
information
name: Super Mario World 2 - Yoshi's Island (SNS) (1.1)
title: Super Mario World 2: Yoshi's Island
sha256: bd763c1a56365c244be92e6cffefd318780a2a19eda7d5baf1c6d5bd6c1b3e06
board: SHVC-1CB5B-20
rom: 0x200000
ram: 0x8000
layout
file name=program.rom size=0x200000
[No prior releases were posted to the WIP thread. -Ed.]
byuu says:
Super Famicom mapping system has been reworked as discussed with the
mask= changes. offset becomes base, mode is gone. Also added support for
comma-separated fields in the address fields, to reduce the number of
map lines needed.
<?xml version="1.0" encoding="UTF-8"?>
<cartridge region="NTSC">
<superfx revision="2">
<rom name="program.rom" size="0x200000"/>
<ram name="save.rwm" size="0x8000"/>
<map id="io" address="00-3f,80-bf:3000-32ff"/>
<map id="rom" address="00-3f:8000-ffff" mask="0x8000"/>
<map id="rom" address="40-5f:0000-ffff"/>
<map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/>
<map id="ram" address="70-71:0000-ffff"/>
</superfx>
</cartridge>
Or in BML:
cartridge region=NTSC
superfx revision=2
rom name=program.rom size=0x200000
ram name=save.rwm size=0x8000
map id=io address=00-3f,80-bf:3000-32ff
map id=rom address=00-3f:8000-ffff mask=0x8000
map id=rom address=40-5f:0000-ffff
map id=ram address=00-3f,80-bf:6000-7fff size=0x2000
map id=ram address=70-71:0000-ffff
As a result of the changes, old mappings will no longer work. The above
XML example will run Super Mario World 2: Yoshi's Island. Otherwise,
you'll have to write your own.
All that's left now is to work some sort of database mapping system in,
so I can start dumping carts en masse.
The NES changes that FitzRoy asked for are mostly in as well.
Also, part of the reason I haven't released a WIP ... but fuck it, I'm
not going to wait forever to post a new WIP.
I've added a skeleton driver to emulate Campus Challenge '92 and
Powerfest '94. There's no actual emulation, except for the stuff I can
glean from looking at the pictures of the board. It has a DSP-1 (so
SR/DR registers), four ROMs that map in and out, RAM, etc.
I've also added preliminary mapping to upload high scores to a website,
but obviously I need the ROMs first.
byuu says:
Basically just a project rename, with s/bsnes/higan and the new icon
from lowkee added in.
It won't compile on Windows because I forgot to update the resource.rc
file, and a path transform command isn't working on Windows.
It was really just meant as a starting point, so that v091 WIPs can flow
starting from .00 with the new name (it overshadows bsnes v091, so
publicly speaking this "shouldn't exist" and will probably be deleted
from Google Code when v092 is ready.)
byuu says:
A few issues crept up in the last release, this should take care of
them.
First, it seems that the 32-bit runtime on 64-bit versions of Windows
have 64-bit time functions; whereas true 32-bit Windows does not. This
was causing a DLL error when attempting to load bsnes v090.
Second, when there were more than 2,000 files in the same folder on
Windows, it was lagging the file browser. With OV2's help, I've fixed
that and it'll now load the list instantly.
Lastly, I've included the missing video shaders this time.
byuu says:
Most notably, this release adds Nintendo DS emulation. The Nintendo DS
module was written entirely by Cydrak, so please give him all of the
credit for it. I for one am extremely grateful to be allowed to use his
module in bsnes.
The Nintendo DS emulator's standalone name is dasShiny. You will need
the Nintendo DS firmware, which I cannot provide, in order to use it. It
also cannot (currently?) detect the save type used by NDS games. As
such, manifest.xml files must be created manually for this purpose. The
long-term plan is to create a database of save types for each game.
Also, you will need an analog input device for the touch screen for now
(joypad axes work well.)
There have also been a lot of changes from my end: a unified
manifest.xml format across all systems, major improvements to SPC7110
emulation, enhancements to RTC emulation, MSU1 enhancements, icons in
the file browser list, improvements to SNES coprocessor memory mapping,
cleanups and improvements in the libraries used to build bsnes, etc.
I've also included kaijuu (which allows launching game folders directly
with bsnes) and purify (which allows opening images that are compressed,
have copier headers, and have wrong extensions); both of which are fully
GUI-based.
This release only loads game folders, not files. Use purify to load ROM
files in bsnes.
Note that this will likely be the last release for a long time, and that
I will probably rename the emulator for the next release, due to how
many additional systems it now supports.
byuu says:
Changelog:
- fixed bsnes to let config files and system folders to be in the same
folder as the executable
- fixed RawInput driver to compile again without linear_vector
- fixed phoenix/Windows to compile again without linear_vector
- fixed old vs new name warnings on MinGW w64 (technically the warnings
were erroneous, but I worked around them anyway)
- added memory export hotkey (SNES driver only; mainly for FEoEZ
translation)
- restored WRAM randomization for v090 stability (we can discuss that
idea for v091+)
- fixed SuperFX / SA-1 "0x" prefix in the header generation (drop it
into the latest purify if you want)
- added nall/Makefile uname support for UnxUtils (was breaking
compilation with full UnxUtils in your path otherwise)
byuu says:
This update uses the latest manifest.xml mappings. It also adds a new
"Update Manifests" button that can be used to quickly regenerate all
manifests (sans Famicom games ... since I strip the iNES header, that
information is gone. We can't support Famicom manifest.xml updates until
we have a database.) This is different than the before wrapping of the
functionality on the convert games button. You can also trigger this on
the command-line with "purify synchronize"
g6672D, great catch. This was fixed, thank you.
[g6672D's bug was: "SA-1 and SuperFX are missing the "0x" for
program.rom/save.rwm size." - Ed.]
byuu says:
This implements the spec from the XML part 3 thread:
http://board.byuu.org/viewtopic.php?f=16&t=2998
It's also propagated the changes to nall and purify, so you can test
this one.
This is basically it, after years of effort I feel I finally have
a fully consistent and logical XML board format.
The only things left to change will be: modifications if emulation turns
out to be incorrect (eg we missed some MMIO mirrors, or mirrored too
much), and new additions.
And of course, I'm giving it a bit of time for good arguments against
the format.
Other than that, this release removes linear_vector and pointer_vector,
as vector is better than linear_vector and I've never used
pointer_vector.
vector also gets move(), which is a way to use move-semantics across
types. It lets you steal the underlying memory pool, effectively
destroying the vector without a copy.
This works really nicely with the move for read() functions to return
vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
byuu says:
Changelog:
- eliminated <mmio>, <mcu> tags [they are merged to their parent nodes
now]
- added <ram name= size=> tag to EpsonRTC, SharpRTC
- added <firmware> tag to DSP-n, ST-01n, ST-018, Cx4
- interface->path(0) now returns the system folder, which can be used
for storage now
- as a fun proof-of-concept, I've simulated SNES warm power cycles by
saving and loading work RAM (same effect if you instantly swapped
carts)
- long-term, I'm not sure how I want to do this. The power menu option
makes no sense with warm RAM
- I like the idea of decaying RAM based on timestamp from last play;
and power can just force the timestamp to 0 (which will corrupt all
RAM)
- Interface::firmware is gone. The cores now load firmware inside their
boot up routines
- you now get a message on the screen if the emulator can't find
firmware, should help with "I just get a black screen" messages
I'd like to start preparing for a v090 release. I think we're almost
there now. Have to update nall/cartridge and purify to handle XML
changes first.
byuu says:
Changelog:
- SuperFX has its own ROM and RAM
- Cx4 has its own ROM
- SPC7110 has its own ProgramROM, DataROM and RAM
- OBC1 has its own RAM
- BsxCartridge has its own ROM, RAM and PSRAM
- mapping changes to accommodate the above
byuu says:
Changelog:
- NSS emulation improvement (DIP is 8-bits, not 16-bits; can be remapped
via XML now like all the other chips)
- SA-1 memory map improvements (IRAM and BWRAM can be saved; ROM, IRAM
and BWRAM are separate from Cartridge::ROM, RAM; no MCU)
- S-DD1 memory map improvements (ROM, RAM inside mapping; no MCU)
- SPC7110 memory map improvements (ROM, RAM inside mapping; no MCU; not
finished yet [have to handle 8mbit expansion somehow now)
I have tried multiple times now to get the SuperFX core to use internal
ROM and RAM (separate from Cartridge::ROM, RAM) to no avail.
Not sure what the hell is going on there. Trace logs of 430MB are not
enticing ...
So right now: SuperFX, SPC7110 and BS-X cheat by mapping stuff to
Cartridge::ROM, RAM still. They need to not do that.
[also, replace the old purify tool with the new tool by the same name.
There were some previous releases outside the WIP thread, but this is
the first one that actually works with a WIP release. -Ed.]
byuu says:
Fixes up loading issues with recent purify changes, and purify also
works on BS/ST file types now and should be a bit more crash-resistant.
byuu says:
Changelog:
- Game Boy XML uses <cartridge><board type="MBC3"/> instead of
<cartridge mapper="MBC3">
- if you run bsnes with a filename argument, it will invoke "purify
filename" and exit immediately
- this chains: purify will turn the file into a game folder, and then
invoke bsnes with the game folder name
- net result: you can drag a ZIP file onto bsnes or associate SMC
headered ROMs with bsnes and they'll just work
- new nall: unified usage of - vs _ vs nothing on filenames; fancier
lstring; fancier image (constructor for creating from filename or from
memory); etc
- new phoenix: images in ListView, GTK+ merges the check box into the
first column like the other targets do, etc
- browser list now uses icons to differentiate system folders from game
folders (the game folder icon sucks, I'm open to suggestions though,
as long as it's available on Debian Squeeze in /usr/share/icons, no
custom stuff please)
byuu says:
Changelog:
- SPC7110 $480b (and its settings in $4805-6 + $4807) is now fully
emulated
- decompressor restructured and commented accordingly
The final parts remaining for the SPC7110 core, all within the
decompression engine:
- need to detect when 15+ input bytes are read for one output byte and
simulate a crash somehow (don't have to perfectly simulate corrupted
data stream)
- need to emulate time required to decompress data (doesn't have to be
perfect, just something other than instantaneous)
- need to determine what $480c status flags d6-d0 are for, as best we
can anyway
byuu says:
Changelog:
- Cydrak merged all three SPC7110 decompression routines into one, cuts
the size in half
- fixed masking of $4803.d7 and $4813.d7
- data port out of bounds accesses emulated correctly for app SPC7110
boards
- all(?) data port $4810 reload cases now supported
- basic timing for $4805-6 seeking; reworked delay timing to work better
as well
- fixed $480c.d7 flag (1 = ready, not busy)
- AbsoluteInput returns -32768 if presentation window lacks focus and
you don't always allow input
byuu says:
Changelog:
- SPC7110 data port emulation greatly improved
- SPC7110 $480b.d1 emulated (but $4805-4806 does not work right for mode
2 decompression yet)
- MSU1 audio output will be muted when the S-DSP FLG ($6c).d6 (mute)
flag is set
- MSU1 will read filenames from manifest now (defaults to msu1.rom and
track-#.pcm if missing ... for now)
- bugfixes with MSU1 load state and track seek (and $4804 was wrapping
into $4805 to change the track#)
- Link coprocessor removed (it was meant for ST018 HLE, which never
happened)
Notes for things I forgot but need to address:
- $4813 needs to be uint7 for the set_data_offset() to not allow reading
A23 as set ever (or we can mask)
- AbsoluteInput when window doesn't have focus should return -32768, not
0
- need to support input ID lists that aren't linear (0-7), but arbitrary
(0,1,6,7 or whatever)
byuu says:
Changelog:
- Super Game Boy, BS-X Satellaview and Sufami Turbo cartridges all load
manifests that specify their file names, and they all work
- Sufami Turbo can now properly handle carts without RAM, or empty slots
entirely
- Emulator::Interface structures no longer specify any file names, ever
- exposed "capability.(cheats,states)" now. So far, this just means the
GBA doesn't show the cheat editor, since it doesn't support cheat
codes yet
- as such, state manager and cheat editor windows auto-hide (may be
a tiny bit inconvenient, but it makes not having to sync them or deal
with input when no cart is loaded easier)
- added "AbsoluteInput" type, which returns mouse coordinates from
-32767,-32767 (top left) to +32767,+32767 (bottom right) or
-32768,-32768 (offscreen)
AbsoluteInput is just something I'm toying with. Idea is to support eg
Super Scope or Justifier, or possibly some future Famicom controllers
that are absolute-indexed. The coordinates are scaled, so the bigger
your window, the more precise they are. But obviously you can't get more
precise than the emulated system, so 1x scale will behave the same
anyway. I haven't hooked it up yet, need to mess with the idea of custom
cursors via phoenix for that first. Also not sure if it will feel
smoother or not ... if you resize the window, your mouse will seem to
move slower. Still, not having to capture the mouse for SS/JS may be
nicer yet. But we'll see ... just experimenting for now.
byuu says:
Not even purify makes compatible images for this WIP.
Unless you want to figure it out yourself, I'd suggest waiting for an
updated tool before using subsequent WIPs.
Changelog:
- MSU1 initializes data port + audio track to 0
- MSU1 implements audio track error flag on $2000.d3
- manifest.xml now controls file names for cartridge folders ... mostly
Regressions:
- Super Game Boy support is broken
- Sufami Turbo support is broken
So, basically Emulator::Interface() now has:
void load(const string &manifest);
void save();
The first one will analyze the manifest, and call all the ROM + RAM
loadRequest() commands necessary to run the game.
The second one will call saveRequest() commands on all writable and
non-volatile storage (basically if it's a RAM type and has a filename
specified, it gets saved to disk.)
save() shrinks the size of Emulator::Interface() by hiding information
one is unlikely to care about. It also makes it much easier to save.
The core auto-calls this when you unload a game as well. So the only
time you ever have to worry about it is if you want to save RAM files
mid-game (in case you want to do periodic backups in case of a crash.)
[Yes, the release number is re-used. -Ed.]
byuu says:
I had some bugs in r07 that I couldn't track down, DKJM2's clock was
getting all out of sync.
So I just reverted to r05, blew away both RTCs entirely, and wrote them
cleanly from scratch (obviously looking off the old code.) A bit
extreme, but it worked.
I believe I found the error in the process, day and month were resetting
the counter to 0 instead of 1, it wasn't handling leap year, etc.
While I was at it, I fixed the day-of-week calculation. The SharpRTC
epoch is actually 1000-01-01, and not 1900-01-01.
I'm sure you guys will be really happy that if it ever becomes 1000AD
again and you're playing a ROM hack that uses the SharpRTC and relies on
its weekday value that it will show the correct day now ...
Kind of a pain to compute, but nothing compared to the seventh circle of
hell that was my IBM dBase III Julian<>Gregorian conversion functions :/
Also found a few bugs in the Epson code this way. And I moved the round
seconds actions and flag clear to +125us after flag set.
So, if you had the old r06 or r07, please delete those.
Unfortunately, this took all of my energy today, so the file names
inside manifest changes will have to be in the next WIP.
EDIT: ran a diff against old r07 and new r06.
- added if(days == 31) case twice in EpsonRTC::tick_day()
- forgot weekday = 0; in SharpRTC::load()
- need to move the cartridge+cheat objects up in sfc/Makefile again
- System::init() needs assert(interface != nullptr /* not 0 */)
byuu says:
Changelog:
- EpsonRTC emulation improved further (stop/pause blocks IRQs, verified
secondhi >= 3 triggers 30-second adjust (even on invalid BCD),
second-changed flag is mirrored to minute+hour+day+month+weekday,
improved busy timing, etc.)
- SharpRTC rewritten, works like EpsonRTC now in that it has its own
timing thread and ticks with the emulation
- won't attempt to read from an unopen file stream now (I think this is
what was crashing Sufami Turbo without SRAM?)
- added Tools -> Synchronize Time option below load/save state options.
Only appears when you play a game with an emulated RTC chip
Just realized that I used 125ms for the 30-second adjust instead of
125us, so I'll fix that in the next WIP.
Aside from that, this is as good as the emulation is going to get.
There's still a couple of absolutely psychopathic edge cases that are
just too damn difficult to simulate.
So that leaves us with data port control + decompression status
registers to investigate before SPC7110 will be finished.
byuu says:
Changelog:
- renamed SRTC -> SharpRTC
- renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema)
- full emulation of invalid BCD values for EpsonRTC
- fixed EpsonRTC IRQ mask
Remaining SPC7110 tasks:
- RTC: test 30-second adjust with all values from 00-7f
- RTC: hold is supposed to tick the clock one second after being
released?
- RTC: wait times are too long (need to use >32KHz oscillation to
simulate it properly)
- Data Port: test $4818 more thoroughly (not too important)
- Decompression: test $480c more thoroughly (very important)
- Decompression: perform some tests on DMA transferring data, especially
with $4807 set
Write-offs, at least for now:
- Decompression: emulation of the crash/glitch behavior seen on the real
chip when fed invalid data
- Decompression: I can find no use of $4808
- ALU: Booth cycles for MUL/DIV (this could actually be rather important
if the game reads simpler values quickly [some shoddy games did this
with the CPU ALU])
- RTC: delay after hold release for $4841 accesses
- RTC: 125uS delay after 30-second adjust that will screw with registers
in odd ways if your read or write too soon
- RTC: psychotic behavior of reading too early returning port address
- 1
byuu says:
I split the RTC-4513 code from the SPC7110 code (and obviously in the
XML mapping as well), since they are separate chips on the FEoEZ PCB.
In this way, you can use just the RTC-4513 in homebrew now if you want.
It's a bit nicer than the Sharp RTC from Dai Kaijuu Monogatari II.
This was needed anyway, it has an internal oscillator that's not
divisible by the SNES clock used by the SPC7110; and both the RTC and
decompression code need to be running their own threads anyway.
In the process, I rewrote the way variables are stored to use named
integers rather than a block of memory. Makes the code a lot easier on
the eyes, and more importantly, will make emulating bad BCD values
a whole lot easier.
byuu says:
Changelog: (SPC7110)
- emulated $480b.d0 + $4807 deinterleave mode
- cleaned up decompression core (I'd still like to wipe out those static
variables, those are bad for save states.)
- improved emulation of data port ($481a only increments, never reads)
- improved emulation of RTC (block appropriate bits in the hour register
based on 12/24h mode select; $4840 modes != 1 all disable the chip;
added MDR; etc.)
byuu says:
Substantial improvements to SPC7110 emulation. Added all of the findings
from http://byuu.org/temp/spc7110-mmio.txt that I understood.
I also completely rewrote the RTC. We only had about ~40% of the chip
emulated before. Turns out there's cool stuff like spare RAM, calendar
disable, 12-hour mode, IRQs, IRQ masking, duty cycles, etc. So I went
ahead and emulated all of it. The upper bits on hour+ don't work as
nocash described though, not sure what doc he was reading. The Epson
RTC-4513 manual I have doesn't explain any of the registers.
The new RTC core also ticks seconds based on the emulated clock, and not
on the system clock. This is going to suck for people wanting to keep
the in-game clock synced with their computer, who also abuse fast
forward and save states. Fast forward makes the clock run faster, and
save states will jump the clock to the time it was at when you took the
save state. (It will keep track of the number of seconds between
unloading the game and loading it again, so time passes normally there.)
This is required, however, and how I'm going to rearrange all of the
RTCs for all systems. Any other method can be detected by the game, and
is thus not faithful emulation. To help with this, I'll probably make an
RTC time tool so that you can adjust the time when the emulator isn't
running, but I don't intend to bundle that into bsnes.
New state format bit-packs the RTCRAM values, and it also uses a 64-bit
timestamp. So it's 16 bytes now instead of 20 bytes. S-RTC will drop
from 16 to 12 when it's done.
The RTC busy flag timing needs to be refined with more hardware tests,
there's a slim chance of the game hanging on save at the moment.
The SPC7110 ALU delays are emulated now, too. They may not be perfectly
accurate, but they get the basic gist down.
The only hack that needs to be removed now is the decompression busy
flag. That's ... not going to be fun.
I also redid the mouse emulation. I was polling the mouse position
multiple times per latch. So it should be a bit more precise now,
I hope.
I read it regardless of latch state, dunno if that's good or not.
(r01 was not posted to the WIP thread)
byuu says:
r01 changelog:
- major improvements to SPC7110 MCU (memory controller unit)
- revised SPC7110 memory map to reflect aforementioned improvements
- added "Toggle Tracer" hotkey to target-ethos (only works for SFC so
far, I plan to use this as a lightweight laevateinn for FEoEZ)
r02 changelog:
- quick fix: SRAM is mapped to 00-3f|80-bf:6000-7fff
- quick fix: $4830.d7 is SRAM chip enable, not SRAM write enable. Reads
return 0x00 when this bit is clear
byuu says:
Changelog to v089:
- fix SA-1 Mini Yonku Shining Scorpion
- load from command-line
- remove SNES::Cartridge::NVRAM
- fix SGB save RAM
- update cheats.xml
- already mapped inputs cancel input assign
BS-X wasn't broken after all. I forgot that I ran purify on my BS-X
images, and that the BS Zelda ZIP I have has the disable ROM bit set.
Whoops.
byuu says:
Changelog:
- fixed BGnxOFS to not cache when MOSAIC is not in effect [fixes Air
Strike Patrol "Good Luck" text]
- added GameBoy::Interface::Hook for SGB bindings [SGB works again]
- do not create bsnes/ folder unless it is absolutely needed (eg you
create a save state or state manager archive)
- SuperFX works [needed to call system.init() in Interface::Interface()]
Last chance for any bug reports, at this point I pretty much consider
ethos to be finished. It's shipping without BS-X BIOS game loading
support. Sorry, I can't figure that one out.
byuu says:
Changelog:
- default placement of presentation window optimized for 1024x768
displays or larger (sorry if yours is smaller, move the window
yourself.)
- Direct3D waits until a previous Vblank ends before waiting for the
next Vblank to begin (fixes video timing analysis, and ---really---
fast computers.)
- Window::setVisible(false) clears modality, but also fixed in Browser
code as well (fixes loading images on Windows hanging)
- Browser won't consume full CPU resources (but timing analysis will,
I don't want stalls to affect the results.)
- closing settings window while analyzing stops analysis
- you can load the SGB BIOS without a game (why the hell you would want
to ...)
- escape closes the Browser window (it won't close other dialogs, it has
to be hooked up per-window)
- just for fun, joypad hat up/down moves in Browser file list, any
joypad button loads selected game [not very useful, lacks repeat, and
there aren't GUI load file open buttons]
- Super Scope and Justifier crosshairs render correctly (probably
doesn't belong in the core, but it's not something I suspect people
want to do themselves ...)
- you can load GB, SGB, GB, SGB ... without problems (not happy with how
I did this, but I don't want to add an Interface::setInterface()
function yet)
- PAL timing works as I want now (if you want 50fps on a 60hz monitor,
you must not use sync video) [needed to update the DSP frequency when
toggling video/audio sync]
- not going to save input port selection for now (lot of work), but it
will properly keep your port setting across cartridge loads at least
[just goes to controller on emulator restart]
- SFC overscan on and off both work as expected now (off centers image,
on shows entire image)
- laevateinn compiles properly now
- ethos goes to ~/.config/bsnes now that target-ui is dead [honestly,
I recommend deleting the old folder and starting over]
- Emulator::Interface callbacks converted to virtual binding structure
that GUI inherits from (simplifies binding callbacks)
- this breaks Super Game Boy for a bit, I need to rethink
system-specific bindings without direct inheritance
Timing analysis works spectacularly well on Windows, too. You won't get
your 100% perfect rate (unless maybe you leave the analysis running
overnight?), but it'll get really freaking close this way.
byuu says:
Changelog:
- added NSS DIP switch settings window (when loading NSS carts with
appropriate manifest.xml file)
- added video shader selection (they go in ~/.config/bsnes/Video
Shaders/ now)
- added driver selection
- added timing settings (not only allows video/audio settings, also has
code to dynamically compute the values for you ... and it actually
works pretty good!)
- moved "None" controller device to bottom of list (it is the least
likely to be used, after all)
- added Interface::path() to support MSU1, USART, Link
- input and hotkey mappings remember list position after assignment
- and more!
target-ethos now has all of the functionality of target-ui, and more.
Final code size for the port is 101.2KB (ethos) vs 167.6KB (ui).
A ~67% reduction in code size, yet it does even more! And you can add or
remove an entire system with only three lines of code (Makefile include,
header include, interface append.)
The only problem left is that the BS-X BIOS won't load the BS Zelda no
Densetsu file.
I can't figure out why it's not working, would appreciate any
assistance, but otherwise I'm probably just going to leave it broken for
v089, sorry.
So the show stoppers for a new release at this point are:
- fix laevateinn to compile with the new interface changes (shouldn't be
too hard, it'll still use the old, direct interface.)
- clean up Emulator::Interface as much as possible (trim down
Information, mediaRequest should use an alternate struct designed to
load firmware / slots separately)
- enhance purify to strip SNES ROM headers, and it really needs a GUI
interface
- it would be highly desirable to make a launcher that can create
a cartridge folder from an existing ROM set (* ethos will need to
accept command-line arguments for this.)
- probably need to remember which controller was selected in each port
for each system across runs
- need to fix the cursor for Super Scope / Justifier games (move from
19-bit to 32-bit colors broke it)
- have to refactor that cache.(hv)offset thing to fix ASP
byuu says:
Changelog:
- fixed Super Game Boy input
- Sufami Turbo prompts to load second slot now (you can cancel to leave
it empty)
- NEC/Hitachi/ARM DSP firmware is loaded; NEC RAM is saved
- folders are grouped properly: Sufami Turbo save RAM saves to its slot
folder, etc.
- title shows properly (SGB shows GB game name only, BS-X slotted shows
game name and optional slot name, etc.)
- above extends to saving cheats and such in their correct folders
as well
- added cheat editor and cheat database
- and hooked up the requisite SGB mode loads and can use GB cheats,
because that's kinda cool
- added state manager
- input settings, cheat editor and state manager all have erase (one)
and reset (all) buttons now
- lots of cleanup and restructuring on Emulator::Interface; *almost*
finished with it now
Remaining:
- BS-X BIOS won't show the data pack
- need XML mapping information window
- need NSS DIP switch settings window
- need video shaders
- need driver selection
- need to hide controllers that have no inputs from the input mapping
list (tempted to just remove "None" as a controller option ...)
ethos is currently 88KB of code, ui is 167KB. We're missing about 5-10KB
of code in ethos to complete it, so the rewrite nearly cut the GUI code
size in half, while support all of the same functionality and allowing
the easy addition and removal of entire systems.
byuu says:
Changelog:
- all hotkeys from target-ui now exist in target-ethos
- controller port menus now show up when you load a system (hidden if
there are no options to choose from)
- tools menu auto-hides with no game open ... not much point to it then
- since we aren't using RawInput's multi-KB/MS support anyway, input and
hotkey mappings remove KB0:: and turn MS0:: into Mouse::, makes it
a lot easier to read
- added mute audio, sync video, sync audio, mask overscan
- added video settings: saturation, gamma, luminance, overscan
horizontal, overscan vertical
- added audio settings: frequency, latency, resampler, volume
- added input settings: when focus is lost [ ] pause emulator [ ] allow
input
- pausing and autopausing works
- status messages hooked up (show a message in status bar for a few
seconds, then revert to normal status text)
- sub systems (SGB, BSX, ST) sorted below primary systems list
- added geometry settings cache
- Emulator::Interface cleanups and simplifications
- save states go into (cart foldername.extension/bsnes/state-#.bsa) now.
Idea is to put emulator-specific data in their own subfolders
Caveats / Missing:
- SGB input does not work
- Sufami Turbo second slot doesn't work yet
- BS-X BIOS won't show the data pack
- need XML mapping information window
- need cheat editor and cheat database
- need state manager
- need video shaders
- need driver selection
- need NSS DIP switch settings
- need to hide controllers that have no inputs from the input mapping
list
So for video settings, I used to have contrast/brightness/gamma.
Contrast was just a multiplier on intensity of each channel, and
brightness was an addition or subtraction against each channel. They
kind of overlapped and weren't that effective. The new setup has
saturation, gamma and luminance.
Saturation of 100% is normal. If you lower it, color information goes
away. 0% = grayscale. If you raise it, color intensity increases (and
clamps.) This is wonderful for GBA games, since they are oversaturated
to fucking death. Of course we'll want to normalize that inside the
core, so the same sat. value works on all systems, but for now it's
nice. If you raise saturation above 100%, it basically acts like
contrast used to. It's just that lowering it fades to grayscale rather
than black.
Adding doesn't really work well for brightness, it throws off the
relative distance between channels and looks like shit. So now we have
luminance, which takes over the old contrast <100% role, and just fades
the pixels toward black. Obviously, luminance > 100% would be the same
as saturation > 100%, so that isn't allowed, it caps at 100% now.
Gamma's the same old function. Gamma curve on the lower-half of the
color range.
Effects are applied in the order they appear in the GUI: color ->
saturate -> gammify -> luminate -> output.
byuu says:
Changelog:
- phoenix has added Window::setModal(bool modal = true);
- file dialog is now modal. This allows emulation cores to request data
and get it immediately before continuing the loading process
- save data is hooked up for most systems, still need to handle
subsystem slot saves (Sufami Turbo, basically.)
- toggle fullscreen key binding added (Alt+Enter for now. I think F11 is
probably better though, Enter is often mapped to game start button.)
- video scaling is in (center, scale, stretch), works the same in
windowed and fullscreen mode (stretch hides resize window option), all
in the settings menu now
- enough structure to map all saved paths for the browser and to load
BS-X slotted carts, BS-X carts, single Sufami Turbo carts
Caveats / Missing:
- Super Game Boy input doesn't work yet (due to change in callback
binding)
- doesn't load secondary Sufami Turbo slot yet
- BS-X BIOS isn't show the data pack games to load for some reason (ugh,
I hate the shit out of debugging BS-X stuff ...)
- need mute audio, sync audio+video toggle, save/load state menu and
quick keys, XML mapping information window
- need cheat editor and cheat database
- need state manager
- need to sort subsystems below main systems in load menu (basically
just see if media.slot.size() > 0)
- need video shaders (will probably leave off filters for the time being
... due to that 24/30-bit thing)
- need video adjustments (contrast etc, overscan masks)
- need audio adjustments (frequency, latency, resampler, volume,
per-system frequency)
- need driver selection and input focus policy (driver crash detection
would be nice too)
- need NSS DIP switch settings (that one will be really fun)
- need to save and load window geometry settings
- need to hook up controller selection (won't be fun), create a map to
hide controllers with no inputs to reassign
byuu says:
ethos is going to be absolutely amazing. You guys are in for a treat :D
I'm impressing the hell out of myself with how well-structured this code
is, it's allowing me to do amazing new things.
Just a small sampling of what's in store (and already implemented):
The file browser will display folders as "[ folder name ]", and
cartridge folders as "Game Name" (no extension, no /) [icons would be
nicer, but well ... phoenix.]
Folders are sorted above cartridge folders.
Cartridge folders for other systems do not show up in the list.
Not only are unique paths stored for each image type, your position in
the list is saved across runs.
Some voodoo was added to GTK+ so that all targets even scroll directly
to that item when you open the list. Load->System->Enter restarts your
last game.
That sounds really simple and obvious, but it makes an -incredible-
difference. Didn't realize it until I tried an implementation of it,
wow.
The input mapping list now lets you bind as many hotkeys as you want to
any given input.
So SFC::Port1::Joypad::B = Keyboard::Z or Joypad::Button1 ... no need to
remap everything to switch between keyboard and joypad. Either one
activates the key.
There is a separate Hotkeys tab now. This should hopefully end the
confusion about how to remap hotkeys that users experience.
Hotkeys are different, too. Instead of OR logic, they use AND logic.
So Fullscreen = Keyboard::Alt and Keyboard::Enter. Both must be pressed
to enter the key. This lets you easily implement "super" modifier keys.
The actual codebase has new features the old UI never had, and has about
~50% of the old functionality (so far, of course), yet is only ~25% as
much code.
The entire GUI no longer needs to pull in all the headers for each
emulated system. It just needs a small interface header file.
Then bind the entire system with exactly **two** lines of code.
Everything is dynamically generated for you after that.
byuu says:
Lots of work on ethos, nothing more.
Settings window is in, InputManager pulls all the inputs from all cores
and binds them to ruby inputs, main window adds menu and dynamically
maps in all systems and cartridge slots and options and such, file
browser's back in, RAM is loaded and saved, etc. It's barely usable, but
you have to set up your inputs from the config file by hand for now.
byuu says:
From this WIP, I'm starting on the impossible task of
a declarative-based GUI, which I'm calling Ethos.
base/ becomes emulator/, and we add emulator/interface.hpp, which is
a base API that all emulation cores must implement in full.
(Right now, it's kind of a hybrid to work with the old GUI and the new
GUI at the same time, of course.)
Unlike the old interfaces, the new base class also provides all general
usability hooks: loading and saving files and states, cheat codes, etc.
The new interface also contains information and vector structs to
describe all possible loading methods, controller bindings, etc; and
gives names for them all.
The actual GUI in fact should not include eg <gba/gba.hpp> anymore.
Should speed up GUI compilation.
So the idea going forward is that ethos will build a list of emulators
right when the application starts up.
Once you've appended an emulator to that list, you're done. No more GUI
changes are needed to support that system.
The GUI will have code to parse the emulator interfaces list, and build
all the requisite GUI options dynamically, declarative style.
Ultimately, once the project is finished, the new GUI should look ~99%
identical to the current GUI. But it'll probably be a whole lot smaller.
byuu says:
(r05 and r06 were save points between large core modifications)
I would really appreciate extensive regression testing (especially
around SuperFX, Cx4, ST018, DSP-n, ST-01n, NES, GB) at this point.
The most critical core changes should be completed now. And it was an
unbelievable amount of restructuring.
Changelog:
- SuperFX core moved to Processor::GSU
- SNES::CPU core moved to Processor::R65816
- SNES::SMP core moved to Processor::SPC700
- NES::CPU core renamed to Processor::R6502
- use filestream to load RAM files from interface
- save states store SHA256 instead of CRC32 (CRC32 usage removed
entirely from bsnes)
- nes/ -> fc/ and NES -> FC
- snes/ -> sfc/ and SNES -> SFC
- SuperFamicom::MappedRAM::copy uses stream instead of data+size
- Linux port uses gcc-4.7 (still using only gcc-4.6 subset, so you can
make a gcc-4.6 symlink for now if you like.)
- all profiles and all targets compile and work properly
All eight instruction set cores have been moved to processor/ now.
Consistency's a wonderful thing.
The last remnants of NES/SNES are now limited to target-ui code; and the
nall/(system) folder names.
I'm building with gcc-4.7 on my Linux box now because the resultant
binaries are up to 20% faster (seriously) than gcc-4.6.
byuu says:
This will hopefully be a short-lived WIP, I just want to save
a breakpoint before I attempt something else.
NES, GB, GBC and GBA all load via const stream& now.
NES CPU core moved to Processor::RP2A03.
byuu says:
static vector<uint8_t> file::read(const string &filename); replaces:
static bool file::read(const string &filename, uint8_t *&data, unsigned
&size); This allows automatic deletion of the underlying data.
Added vectorstream, which is obviously a vector<uint8_t> wrapper for
a data stream. Plan is for all data accesses inside my emulation cores
to take stream objects, especially MSU1. This lets you feed the core
anything: memorystream, filestream, zipstream, gzipstream, httpstream,
etc. There will still be exceptions for link and serial, those need
actual library files on disk. But those aren't official hardware devices
anyway.
So to help with speed a bit, I'm rethinking the video rendering path.
Previous system:
- core outputs system-native samples (SNES = 19-bit LRGB, NES = 9-bit
emphasis+palette, DMG = 2-bit grayscale, etc.)
- interfaceSystem transforms samples to 30-bit via lookup table inside
the emulation core
- interfaceSystem masks off overscan areas, if enabled
- interfaceUI runs filter to produce new target buffer, if enabled
- interfaceUI transforms 30-bit video to native display depth (24-bit or
30-bit), and applies color-adjustments (gamma, etc) at the same time
New system:
- all cores now generate an internal palette, and call
Interface::videoColor(uint32_t source, uint16_t red, uint16_t green,
uint16_t blue) to get native display color post-adjusted (gamma, etc
applied already.)
- all cores output to uint32_t* buffer now (output video.palette[color]
instead of just color)
- interfaceUI runs filter to produce new target buffer, if enabled
- interfaceUI memcpy()'s buffer to the video card
videoColor() is pretty neat. source is the raw pixel (as per the
old-format, 19-bit SNES, 9-bit NES, etc), and you can create a color
from that if you really want to. Or return that value to get a buffer
just like v088 and below. red, green, blue are 16-bits per channel,
because why the hell not, right? Just lop off all the bits you don't
want. If you have more bits on your display than that, fuck you :P
The last step is extremely difficult to avoid. Video cards can and do
have pitches that differ from the width of the texture. Trying to make
the core account for this would be really awful. And even if we did
that, the emulation routine would need to write directly to a video card
RAM buffer. Some APIs require you to lock the video buffer while
writing, so this would leave the video buffer locked for a long time.
Probably not catastrophic, but still awful. And lastly, if the
emulation core tried writing directly to the display texture, software
filters would no longer be possible (unless you -really- jump through
hooks and divert to a memory buffer when a filter is enabled, but ...
fuck.)
Anyway, the point of all that work was to eliminate an extra video copy,
and the need for a really painful 30-bit to 24-bit conversion (three
shifts, three masks, three array indexes.) So this basically reverts us,
performance-wise, to where we were pre-30 bit support.
[...]
The downside to this is that we're going to need a filter for each
output depth. Since the array type is uint32_t*, and I don't intend to
support higher or lower depths, we really only need 24+30-bit versions
of each filter. Kinda shitty, but oh well.
byuu says:
Basically, the current implementation of nall/array is deprecated now.
The old method was for non-reference types, it acted like a vector for
POD types (raw memory allocation instead of placement new construction.)
And for reference types, it acted like an unordered set. Yeah, not good.
As of right now, nall/array is no longer used. The vector type usage was
replaced with actual vectors.
I've created nall/set, which now contains the specialization for
reference types.
nall/set basically acts much like std::unordered_set. No auto-sort, only
one of each type is allowed, automatic growth.
This will be the same both for reference and non-reference types ...
however, the non-reference type wasn't implemented just yet.
Future plans for nall/array are for it to be a statically allocated
block of memory, ala array<type, size>, which is meant for RAII memory
usage.
Have to work on the specifics, eg the size as a template parameter may
be problematic. I'd like to return allocated chunks of memory (eg
file::read) in this container so that I don't have to manually free the
data anymore.
I also removed nall/moduloarray, and moved that into the SNES DSP class,
since that's the only thing that uses it.
byuu says:
Changes to v088:
- OBJ mosaic Y fix
- Laevateinn compilation
- Remove filebrowser extra code
- Fix -march=native on Windows
- Fix purify mkdir
- GBA sound volume
- Add .gbb
- free firmware memory after file load
- Add GBA game to profile list (Yoshi's Island should work)
byuu says:
Changelog:
- DMA channel masks added (some are 27-bit source/target and some are
14-bit length -- hooray, varuint_t class.)
- No more state.pending flags. Instead, we set dma.pending flag when we
want a transfer (fixes GBA Video - Pokemon audio) [Cydrak]
- fixed OBJ Vmosaic [Cydrak, krom]
- OBJ cannot read <=0x13fff in BG modes 3-5 (fixes the garbled tile at
the top-left of some games)
- DMA timing should be much closer to hardware now, but probably not
perfect
- PPU frame blending uses blargg's bit-perfect, rounded method (slower,
but what can you do?)
- GBA carts really unload now
- added nall/gba/cartridge.hpp: used when there is no manifest. Scans
ROMs for library tags, and selects the first valid one found
- added EEPROM auto-detection when EEPROM size=0. Forces disk/save state
size to 8192 (otherwise states could crash between pre and post
detect.)
- detects first read after a set read address command when the size
is zero, and sets all subsequent bit-lengths to that value, prints
detected size to terminal
- added nall/nes/cartridge.hpp: moves iNES detection out of emulation
core.
Important to note: long-term goal is to remove all
nall/(system)/cartridge.hpp detections from the core and replace with
databases. All in good time.
Anyway, the GBA workarounds should work for ~98.5% of the library, if my
pre-scanning was correct (~40 games with odd tags. I reject ones without
numeric versions now, too.)
I think we're basically at a point where we can release a new version
now. Compatibility should be relatively high (at least for a first
release), and fixes are only going to affect one or two games at a time.
I'd like to start doing some major cleaning house internally (rename
NES->Famicom, SNES->SuperFamicom and such.) Would be much wiser to do
that on a .01 WIP to minimize regressions.
The main problems with a release now:
- speed is pretty bad, haven't really optimized much yet (not sure how
much we can improve it yet, this usually isn't easy)
- sound isn't -great-, but the GBA audio sucks anyway :P
- couple of known bugs (Sonic X video, etc.)
byuu says:
Changelog:
- revised NES XML tag nesting
- program.rom is going to refer to PRG+CHR combined. Split is going to
have to use different file names
- slot loader is gone (good riddance!)
- "Cartridge -> Load Game Boy Advance Cartridge ..." has become "Load ->
Game Boy Advance ..."
- Load Satellaview Slotted Cartridge is gone. If you load an SNES
cartridge and it sees <bsx><slot>, it asks if you want to load a BS-X
data pack
- If you load a Sufami Turbo cartridge with <cartridge linkable="true">,
it asks if you want to link in another Sufami Turbo cartridge
- if you try and load the same exact Sufami Turbo cartridge in both
slots, it yells at you for being an idiot :P
byuu says:
Be sure to run make install, and move required images to their appropriate system profile folders.
I still have no warnings in place if those images aren't present.
Changelog:
- OBJ mosaic should hopefully be emulated correctly now (thanks to krom
and Cydrak for testing the hardware behavior)
- emulated dummy serial registers, fixes Sonic Advance (you may still
need to specify 512KB FlashROM with an appropriate ID, I used
Panaonic's)
- GBA core exits scheduler (PPU thread) and calls
interface->videoRefresh() from main thread (not required, just nice)
- SRAM, FRAM, EEPROM and FlashROM initialized to 0xFF if it does not
exist (probably not needed, but FlashROM likes to reset to 0xFF
anyway)
- GBA manifest.xml for file-mode will now use "gamename.xml" instead of
"gamename.gba.xml"
- started renaming "NES" to "Famicom" and "SNES" to "Super Famicom" in
the GUI (may or may not change source code in the long-term)
- removed target-libsnes/
- added profile/
Profiles are the major new feature. So far we have:
Famicom.sys/{nothing (yet?)}
Super Famicom.sys/{ipl.rom}
Game Boy.sys/{boot.rom}
Game Boy Color.sys/{boot.rom}
Game Boy Advance.sys/{bios.rom[not included]}
Super Game Boy.sfc/{boot.rom,program.rom[not included]}
BS-X Satellaview.sfc/{program.rom,bsx.ram,bsx.pram}
Sufami Turbo.sfc/{program.rom}
The SGB, BSX and ST cartridges ask you to load GB, BS or ST cartridges
directly now. No slot loader for them. So the obvious downsides: you
can't quickly pick between different SGB BIOSes, but why would you want
to? Just use SGB2/JP. It's still possible, so I'll sacrifice a little
complexity for a rare case to make it a lot easier for the more common
case. ST cartridges currently won't let you load the secondary slot.
BS-X Town cart is the only useful game to load with nothing in the slot,
but only barely, since games are all seeded on flash and not on PSRAM
images. We can revisit a way to boot the BIOS directly if and when we
get the satellite uplink emulated and data can be downloaded onto the
PSRAM :P BS-X slotted cartridges still require the secondary slot.
My plan for BS-X slotted cartridges is to require a manifest.xml to
specify that it has the BS-X slot present. Otherwise, we have to load
the ROM into the SNES cartridge class, and parse its header before we
can find out if it has one. Screw that. If it's in the XML, I can tell
before loading the ROM if I need to present you with an optional slot
loading dialog. I will probably do something similar for Sufami Turbo.
Not all games even work with a secondary slot, so why ask you to load
a second slot for them? Let the XML request a second slot. A complete
Sufami Turbo ROM set will be trivial anyway. Not sure how I want to do
the sub dialog yet. We want basic file loading, but we don't want it to
look like the dialog 'didn't do anything' if it pops back open
immediately again. Maybe change the background color of the dialog to
a darker gray? Tacky, but it'd give you the visual cue without the need
for some subtle text changes.
byuu says:
Changelog:
- serialize processor.pc.data, not processor.pc
- call CPU processor.setMode() in ARM serialize
- serialize BIOS.mdr
- support SRAM > 32KB
- EEPROM, FlashROM serialize
- EEPROM lose nall/bitarray.hpp
- noise line feed after envelope
- space out PSR read
- ST018 needs byte reads fixed (don't align) [fixes HNMS2]
- flush sram/eeprom/flashrom to 0 on cartridge load
- APU/PPU dont sync back to CPU if syncing for state
- fixed APU sync problems in GB/GBC core that could possibly wreck save
states as well
Quite a lot of little problems there. I believe GBA save states are
fixed now.
byuu says:
Changelog:
- fixed FIFO[1] reset behavior (fixes audio in Sword of Mana)
- added FlashROM emulation (both sizes)
- GBA parses RAM settings from manifest.xml now
- save RAM is written to disk now
- added save state support (it's currently broken, though)
- fixed ROM/RAM access timings
- open bus should mostly work (we don't do the PC+12 stuff yet)
- emulated the undocumented memory control register (mirror IWRAM,
disable I+EWRAM, EWRAM wait state count)
- emulated keypad interrupts
- emulated STOP (freezes video, audio, DMA and timers; only breaks on
keypad IRQs)
- probably a lot more, it was a long night ...
Show stoppers, missing things, broken things, etc:
- ST018 is still completely broken
- GBC audio sequencer apparently needs work
- GBA audio FIFO buffer seems too quiet
- PHI / ROM prefetch needs to be emulated (no idea on how to do this,
especially PHI)
- SOUNDBIAS 64/128/256khz modes should output at that resolution
(really, we need to simulate PWM properly, no idea on how to do this)
- object mosaic top-left coordinates are wrong (minor, fixing will
actually make the effect look worse)
- need to emulate PPU greenswap and color palette distortion (no idea on
how do this)
- need GBA save type database (I would also LIKE to blacklist
/ patch-out trainers, but that's a discussion for another day.)
- some ARM ops advance the prefetch buffer, so you can read PC+12 in
some cases
byuu says:
(r24 was a point release during merging of changes.)
This release is almost entirely Cydrak's direct work:
- Added ARM::sequential() and some WAITCNT timings
- Added Bus::io(uint32 pc), intended for prefetch timing
- Added ARM::load() with data rotation (fixed Mother 3 graphics)
- Added ARM::store() for data mirroring
- LDM, STM, and instruction fetch still use read/write()
- ARM::vector() no longer unmasks FIQs
- Set THUMB shifter flags via bit(), consistent with ARM
- Replace shifter loops with conditional tests
My changes:
- fixed sprite clipping on left-edge of screen
- added first system folder, GBA.system
- sudo make install is now make install
- make install will create GBA.system for you in your home folder
Windows users, take data/GBA.system and put it in the same folder as
bsnes.exe, and give it a BIOS named bios.rom
Or place it in your home folder (%APPDATA%/bsnes)
Also note that this is highly experimental, I'll probably be changing
things a lot before release.
EDIT: I botched the cartridge timing change. Will fix in r26. It'll
still run a bit too fast for now, unfortunately.
byuu says:
Changelog:
- fixed cascading timers and readouts (speed hit from 320fps to 240fps;
would be 155fps with r20 timers) (fixes Spyro)
- OBJ mode 3 acts like OBJ mode 2 now (may not be correct, but nobody
has info on it)
- added background + object vertical+horizontal mosaic in all modes
(linear+affine+bitmap)
- object mosaic uses sprite (0,0) for start coordinates, not screen
(0,0) (again, nobody seems to have info on it)
- BIOS cannot be read by r(15)>=0x02000000; returns last BIOS read
instead (I can't believe games rely on this to work ... fixes SMA
Mario Bros.)
Mosaic is what concerns me the most, I've no idea if I'm doing it
correctly. But anything is probably better than nothing, so there's
that. I don't really notice the effect in Metroid Fusion. So either it's
broken, or it's really subtle.
byuu says:
Changelog:
- fixed below pixel green channel on color blending
- added semi-transparent objects [Exophase's method]
- added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable)
- EEPROM uses nall::bitarray now to be friendlier to saving memory to disk
- removed incomplete mosaic support for now (too broken, untested)
- improved sprite priority. Hopefully it's right now.
Just about everything should look great now. It took 25 days, but we
finally have the BIOS rendering correctly.
In order to do OBJ windows, I had to drop my above/below buffers
entirely. I went with the nuclear option. There's separate layers for
all BGs and objects. I build the OBJ window table during object
rendering. So as a result, after rendering I go back and apply windows
(and the object window that now exists.) After that, I have to do
a painful Z-buffer select of the top two most important pixels. Since
I now know the layers, the blending enable tests are a lot nicer, at
least. But this obviously has quite a speed hit: 390fps to 325fps for
Mr. Driller 2 title screen.
TONC says that "bad" window coordinates do really insane things. GBAtek
says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240
? 240 : x2; I like the GBAtek version more, so I went with that. I sure
hope it's right ... but my guess is the hardware does this with
a counter that wraps around or something. Also, say you have two OBJ
mode 2 sprites that overlap each other, but with different priorities.
The lower (more important) priority sprite has a clear pixel, but the
higher priority sprite has a set pixel. Do we set the "inside OBJ
window" flag to true here? Eg does the value OR, or does it hold the
most important sprite's pixel value? Cydrak suspects it's OR-based,
I concur from what I can see.
Mosaic, I am at a loss. I really need a lot more information in order to
implement it. For backgrounds, does it apply to the Vcounter of the
entire screen? Or does it apply post-scroll? Or does it even apply after
every adjust in affine/bitmap modes? I'm betting the hcounter
background mosaic starts at the leftmost edge of the screen, and repeats
previous pixels to apply the effect. Like SNES, very simple. For
sprites, the SNES didn't have this. Does the mosaic grid start at (0,0)
of the screen, or at (0,0) of each sprite? The latter will look a lot
nicer, but be a lot more complex. Is mosaic on affine objects any
different than mosaic of linear(tiled) objects?
With that out of the way, we still have to fix the CPU memory access
timing, add the rest of the CPU penalty cycles, the memory rotation
/ alignment / extend behavior needs to be fixed, the shifter desperately
needs to be moved from loops to single shift operations, and I need to
add flash memory support.
byuu says:
Timer speedup added. Boosts Mr. Driller 2 title from 170fps to 400fps.
Other games still benefit, but not as amazingly. I don't dip below
160fps ever here.
Reverted the memory speed to 2 for everything for now, to fix
Castlevania slowdown. We obviously need to add the N/S stuff before we
do that.
Added linear BG and linear OBJ mosaic-Y. Did not add mosaic-X, or any
mosaic to the affine/bitmap modes, because I'm not sure when to apply
the compensation.
Rewrote layer stuff. It now has two layers (above and below), and it
performs the four blending modes as needed.
Didn't add semi-transparent sprites because the docs are too confusing.
Added a blur filter directly into the PPU for now. This obviously
violates my interface, but F-Zero needed it for HUD display. We can
remove it when we have an official release with a blur filter available.
The filter still doesn't warp colors like a real GBA, because I don't
know the formula.
byuu says:
Changelog:
- HALT waits 16 cycles before testing IRQs instead of 1 (probably less
precise, but provides a massive speedup) [we will need to work on this
later]
- MMIO regs for CPU/PPU simplified by combining array accesses
- custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit
writes
- 16-bit PRAM data (decent speedup)
- emulated memory access speed (but don't handle non-sequential
penalties or PPU access penalties yet) [amazingly, doesn't help speed
at all]
- misc. code cleanups
For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps.
Compatibility should be unchanged. Timers are still an interesting
avenue to increase performance, but will be very tough to handle the
16MHz timers with eg a period of 65535 (overflow every single tick.) And
that's basically the last major speed boost we'll be able to get.
Blending and windowing is going to hurt performance, but it remains to
be seen how much.
byuu says:
Changelog:
- added FIFO buffer emulation (with DMA and all that jazz) [Cydrak]
- fixed timers and vcounter assign [Cydrak]
- emulated EEPROM (you have to change size manually for 14-bit mode, we
need a database badly now) [SMA runs now]
- removed OAM array, now decoding directly to struct Object {} [128] and
ObjectParam {} [32] (faster this way)
- check forceblank (still doesn't remove all garble between transitions,
though??)
- lots of other stuff
Delete your settings.cfg, or manually change frequencyGBA to 32768, or
bad things will happen (this may change back to 256KHz-4MHz later.)
15 of 16 games are fully playable now, and look and sound great.
The major missing detail right now is PPU blending support, and we
really need to optimize the hell out of the code.
byuu says:
Merged Cydrak's r17c changes:
- BG affine mode added
- BG bitmap mode added
- OBJ affine mode added
- fixed IRQ bug in THUMB mode (fixed almost every game)
- timers added (broke almost every game, whee.)
Cydrak is absolutely amazingly awesome and patient. This really wouldn't
be happening without him.
Also fixed some things from my end, including greatly improved sprite
priorities, and a much better priority sorter. Mr. Driller looks a lot
better now.
byuu says:
Emulated GBC sound plus the new extensions to it.
I am kind of surprised by how little developers utilized the GBC audio
portion.
Mr. Driller now has sound effects, and Pinobee no Daibouken has BGM.
I still have yet to emulate the GBA extra sound channels and PWM. Need
to emulate timers and DMA 2 refresh mode before I can do that.
Also, I moved both GBC and GBA audio to use length = data; if(++length
== 0); rather than length = 64 - data; if(--length == 0); so that
I could return literal values for register reads.
I thought there was a good reason we used the latter version, but
I can't hear any audible difference even in GBC games, so oh well.
Lastly, I think the pattern[++offset] in the wave channel was a bug in
the DMG/GBC only. I really, really hope it doesn't apply to the GBA,
because that will make bank selection a serious pain in the ass.
byuu says:
Fixed the r15 mask per Cydrak.
Added DMA support (immediate + Vblank + Hblank + HDMA) with IRQ support.
Basically only missing FIFO reload mode for the APU on channel 2.
Added background linear renderer (tilemap mode.)
Added really inefficient pixel priority selector, so that all BGs+OBJ
could be visible onscreen at the same time.
As a result of the above:
* Mr. Driller is our first fully playable game
* Bakunetsu Dodge Ball Fighters is also fully playable
* Pinobee no Daibouken is also fully playable
Most games (15 of 16 tested) are now showing *something*, many things
look really really good in fact.
Absolutely essential missing components:
- APU
- CPU timers and their interrupts
- DMA FIFO mode
- OBJ affine mode
- BG affine mode
- BG bitmap mode
- PPU windows (BG and OBJ)
- PPU mosaic
- PPU blending modes
- SRAM / EEPROM (going to rely on a database, not heuristics. Homebrew
will require a manifest file.)
byuu says:
Added linear (eg non-affine) sprite rendering, 4bpp and 8bpp with hflip
and vflip. Nothing else.
You can now see the Nintendo logo and Gameboy text at the end of the BIOS.
It's a start =)
byuu says:
Fixed aforementioned issues.
[From a previous post:
- mul was using r(d) instead of r(n) for accumulate.
- mull didn't remove c/v clear.
- APU register mask was broken, so SOUNDBIAS was reading out wrong.
- APU was only mapping 0x088 and not 0x089 as well.
- Halfword reads in CPU+PPU+APU were all reading from the low address
each time.]
All CPU+PPU registers are now hooked up (not that they do anything.)
SOUNDBIAS for APU was hooked up, got tired of working on it for the rest :P
I recall from the GB APU that you can't just assign values for the APU
MMIO regs. They do odd reload things as well.
Also, was using MMIO read code like this:
return (
(flaga << 0)
|| (flagb << 1)
|| (flagc << 2)
);
Logical or doesn't work so well with building flags :P
Bad habit from how I split multiple conditionals across several lines.
So ... r14 is basically what r13 should have been yesterday, delaying my
schedule by yet another day :(
byuu says:
Contains all of Cydrak's fixes, sans PPU.
On the PPU front, I've hooked up 100% of read and write registers.
All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now
as well.
Super Mario Advance now runs without *appearing* to crash, although it's
hard to tell since I have no video or sound :P
ARM Wrestler is known to run, as is the BIOS.
byuu says:
Enough to get through the BIOS and into cartridge ROM.
I am a bit annoyed that I was basically told that the GBA PPU wasn't
that bad. Sprites are a clusterfuck, easily worse than Mode7, docs don't
even begin to explain them in enough detail.
This is going to be fun.
byuu says:
Added all of the above fixes and changes. [A lot of individual fixes for
the ARM core from Cydrak - Ed.] Also new is pipeline_decode() to fetch
data, and IME/IE/IF support, and an ARM::processor.irqline flag that
triggers IRQs at 0x18. Only Vblank is hooked up, which is what SWI 4 was
waiting on previously.
I'm sure my interrupt support is horribly broken and wrong. I was never
able to really figure out IE/IF on the Game Boy, so there's no question
this is even worse.
It's now going crazy and writing 0 to IE forever now after the Vblank
IRQ triggers.
byuu says:
Changelog:
- fixed THUMB hi immediate reads (immediate * 4)
- cartridge is properly mirrored to 32MB (eg 12mbit repeats as
lo8+hi4+hi4+lo8+hi4+hi4) [so it's a bit slower than a standard memcpy
fill]
- added ARM - load/store halfword register offset
- added ARM - load/store halfword immediate offset
- added ARM - load signed halfword/byte register offset
- added ARM - load signed halfword/byte immediate offset
- added decode() function to make opcode bit testing a lot clearer
(didn't apply it to the debugger yet)
All ARMv4M and all THUMBv4 instructions should now be implemented.
Although I'm not sure if my implementations of the new instructions are
correct.
byuu says:
Split apart necdsp: core is now in processor/upd96050 (wish I had
a better name for it, but there's no family name that is maskable.)
I would like to support the uPD7720 in the core as well, just for
completeness' sake, but I'll have to modify the decoder to drop one bit
from each mode.
So ... I'll do that later. Worst part is even if I do, I won't be able
to test it :(
Added all of Cydrak's changes. I also simplified LDMIA/STMIA and
PUSH/POP by merging the outer loops.
Probably infinitesimally slower, but less code is nicer. Maybe GCC
optimization will expand it, who knows.
byuu says:
Added some more ARM opcodes, hooked up MMIO. Bind it with mmio[(addr
000-3ff)] = this; inside CPU/PPU/APU, goes to read(), write().
Also moved the Hitachi HG51B core to processor/, and split it apart from
the snes/chip/hitachidsp implementation.
This one actually worked really well. Very clean split between MMIO/DMA
and the processor core. I may move a more generic DMA function inside
the core, not sure yet.
I still believe the HG51B169 to be a variant of the HG51BS family, but
given they're meant to be incredibly flexible microcontrollers, it's
possible that each variant gets its own instruction set.
So, who knows. We'll worry about it if we ever find another HG51B DSP,
I guess.
GBA BIOS is constantly reading from 04000300, but it never writes. If
I return prng()&1, I can get it to proceed until it hits a bad opcode
(stc opcode, which the GBA lacks a coprocessor so ... bad codepath.)
Without it, it just reads that register forever and keeps resetting the
system, or something ...
I guess we're going to have to try and get ARMwrestler working, because
the BIOS seems to need too much emulation code to do anything at all.
There was a "v087r07pre" release that I unfortunately missed.
byuu says (about v087r07pre):
Creates the bsnes/processor folder. This has a shared ARM core there
which both the GBA and ST018 inherit.
There are going to be separate decoders, and revision-specific checks,
to support the differences between v3+.
In the future, I also want to move the other processor cores here:
- GBZ80 (GB, GBC)
- 65816 (SNES CPU, SA-1)
- NEC uPD (7725, 96050, maybe 7720 just for fun)
- Hitachi HG51B169
- SuperFX
- SPC700
- 65(C?)02
Basically, the GBA/ST018 forces my hand to start coding a bit more like
a multi-system emulator.
Right now, the ST018 is broken. Hence the pre. Apparently the GBA core
being used now has some bugs. So this'll be a nice way to stress-test
the GBA core a bit before we make it to ARMwrestler.
byuu says (about v087r07):
Both snes/chip/armdsp and gba/cpu use processor/arm now.
Fixed THUMB to execute the BL prefix and suffix separately. I can now
get the GBA BIOS stuck in some kind of infinite loop. Hooray ...
I guess?
byuu says:
I believe I've implemented every THUMB instruction now, although I'm
sure there are dozens of bugs in the implementation.
It seems that the last jump taken is ending up being off-by-two. It's
probably due to not masking/adjusting PC correctly at certain points.
I don't know if any other bugs are being hit prior to this or not.
I don't implement any I/O registers yet, and the BIOS seems to be poking
at a few of them along the way, so ... who knows.
I could also be reading the log wrong, but it looks to me like there's
some PSR setting the mode flag register to 0, which is supposed to be an
undefined behavior mode ... perhaps mrs has no effect on the m/t bits,
and it just affects the i/f bits?
byuu says:
Implemented all of the ARMv3 instructions, and the bx rm instruction as
well. Already hit THUMB mode right at the start of the BIOS, sigh.
Implemented the first THUMB instruction to get that rolling. Also tried
to support the S flag to LDM/STM, but not sure how successful I was.
byuu says:
GBA stuff re-added. Only thing missing that was there before is the ARM
branch opcode.
Since we're going to be staring at it for a very long time, I added
a more interesting test video pattern.
Went from 6fps to 912fps. Amazing what being able to divide can do for
a frame rate.
byuu says:
Fixing the PPU stepping increased FPS to 250. Promising, at least, since
the ARM core is still severely overclocked.
However, I reverted back to r02. This one patches gameboy/ and GameBoy::
to gb/ and GB:: and that's it.
Sorry, I just couldn't shake this bad feeling about the code. There were
some poorly hacked-together constructs. I'd rather just redo two days of
work than feel bad about the codebase for the next several years. Going
to attempt the GBA bridge again. Third time's a charm, I suppose (there
was a pre-r03 WIP I abandoned as well.)
This isn't unprecedented, GB core took a few attempts like this as well.
byuu says:
Changelog:
- gameboy/ -> gb/
- GameBoy -> GB
- basic memory map for GBA
- enough code to execute the first BIOS instruction (b 0x68)
I have the code resetting r(15) to 0 on an exception just as a test.
Since that flushes the pipeline, that means we're basically executing "b
0x68" at 8MHz, and nothing else.
... and I am getting __6 motherfucking FPS__ at 4.4GHz on an i7.
Something is seriously, horribly, unfuckingbelievably wrong here, and
I can't figure out what it is.
My *fully complete* ARM core on the ST018 is even less efficient and
runs at 21.47MHz, and yet I get 60fps even after emulating the SNES
CPU+PPU @ 10+MHz each as well.
... I'm stuck. I can't proceed until we figure out what in the holy fuck
is going on here. So ... if anyone can help, please do. If we can't fix
this, the GBA emulation is dead.
I was able to profile on Windows, and I've included that in this WIP
under out/log.txt.
But it looks normal to me. But yeah, there's NO. FUCKING. WAY. This code
should be running this slowly.
byuu says:
I wanted to keep this a secret, but unlike other recent additions, this
will easily take several weeks, maybe months, to show anything.
Assuming I can even pull it off. Nothing technically overwhelming here,
I'm more worried about the near-impossibility of debugging the CPU.
byuu says:
Changelog:
- extended USART with quit(), readable(), writable() [both emulation and
hardware]
- quit() returns true on hardware when Ctrl+C (SIGINT) is generated
(breaks main loop); no effect under emulation yet (hard to
simulate)
- readable() returns true when data is ready to be read
(non-blocking support for read())
- writable() returns true when data can be written (non-blocking
support for write()) [always true under emulation, since we have
no buffer size limit]
byuu says:
Changelog:
- fixes ARM core unaligned memory reads (fixes HNMS2 AI, hopefully completely,
we'll see though) [Cydrak]
- ARM 40000010 writes are now connected to d2 rather than the timer
- ARM bus_readbyte() removed (would love to do the same for writebyte if
we can ... then we can drop back to bus_read + bus_write only)
- USART with IObit set acts as a regular gamepad now (don't have this
hooked up with real hardware, but oh well, it's technically possible
so there's that)
- OpenGL/GLX will use 30-bit when you have a 30-bit display; no need for
config file video.depth anymore
byuu says:
This release adds ST018 emulation. As this was the final unsupported
SNES coprocessor, this means that bsnes v087 is the first SNES emulator
to be able to claim 100% known compatibility with all officially
released games. And it does this with absolutely no hacks.
Again, I really have to stress the word known. No emulator is perfect.
No emulator ever really can be perfect for a system of this complexity.
The concept doesn't even really exist, since every SNES behaves subtly
different. What I mean by this, is that every single game ever
officially sold has been tested, and zero bugs (of any severity level)
are currently known.
It is of course extremely likely that bugs will be found in this
release, as well as in future releases. But this will always be
a problem for every emulator ever made: there is no way to test every
possible codepath of every single game to guarantee perfection. I will,
of course, continue to do my best to fix newfound bugs so long as I'm
around.
I'd really like to thank Cydrak and LostTemplar for their assistance in
emulating the ST018. I could not have done it without their help.
The ST018 ROM, like the other coprocessor ROMs, is copyrighted. This
means I am unable to distribute the image.
Changelog (since v086):
- emulated the 21.47MHz ST018 (ARMv3) coprocessor used by Hayazashi
Nidan Morita Shougi 2
- fixed PPU TM/TS edge case; fixes bottom scanline of text boxes in
Moryo Senki Madara 2
- fixed saving and loading of Super Game Boy save RAM
- NEC uPD7725,96050 ROMs now stored in little-endian format for
consistency
- cartridge folder concept has been reworked to use fixed file names
- added emulation of serial USART interface (replaces asynchronous UART
support previously)
byuu says:
Cydrak, I moved the step from the opcode decoder and opcodes themselves
into bus_(read,write)(byte,word), to minimize code.
If that's not feasible for some reason, please let me know and I'll
change it back to your latest WIP.
This has your carry flag fix, the timer skeleton (doesn't really work
yet), the Booth two-bit steps, and the carry flag clear thing inside
multiply ops.
Also added the aforementioned reset delay and reset bit stuff, and fixed
the steps to 21MHz for instructions and 64KHz for reset pulse.
I wasn't sure about the shifter extra cycles. I only saw it inside one
of the four (or was it three?) opcodes that have shifter functions.
Shouldn't it be in all of them?
The game does indeed appear to be fully playable now, but the AI doesn't
exactly match my real cartridge.
This could be for any number of reasons: ARM CPU bug, timer behavior
bug, oscillator differences between my real hardware and the emulator,
etc.
However ... the AI is 100% predictable every time, both under emulation
and on real hardware.
- For the first step, move 九-1 to 八-1.
- The opponent moves 三-3 to 四-3.
- Now move 七-1 to 六-1.
- The opponent moves 二-2 to 八-8.
However, on my real SNES, the opponent moves 一-3 to 二-4.
byuu says:
Most importantly ... I'm now using "st018.rom" which is the program ROM
+ data ROM in one "firmware" file. Since all three Seta DSPs have the
ST01N stamp, unlike some of the arcade variants, I'm just going to go
with ST01N from now on instead of ST-001N. I was using the latter as
that's what Overload called them.
Moving on ...
The memory map should match real hardware now, and I even match the open
bus read results.
I also return the funky 0x40404001 for 60000000-7fffffff, for whatever
that's worth.
The CPU-side registers are also mirrored correctly, as they were in the
last WIP, so we should be good there.
I also simulate the reset pulse now, and a 0->!0 transition of $3804
will destroy the ARM CPU thread.
It will wait until the value is set back to zero to resume execution.
At startup, the ARM CPU will sleep for a while, thus simulating the
reset delay behavior.
Still need to figure out the exact cycle length, but that's really not
important for emulation.
Note in registers.hpp, the |4 in status() is basically what allows the
CPU program to keep going, and hit the checkmate condition.
If we remove that, the CPU deadlocks. Still need to figure out how and
when d4 is set on $3804 reads.
I can run any test program on both real hardware and in my emulator and
compare results, so by all means ... if you can come up with a test,
I'll run it.
byuu says:
Attempted to fix the bugs pointed out by Cydrak for the shifter carry
and subtraction flags. No way to know if I was successful.
The memory map should exactly match real hardware now.
Also simplified bus reading/writing: we can get fancy when it works,
I suppose.
Reduced some of the code repetition to try and minimize the chances for
bugs.
I hopefully fixed up register-based ror shifting to what the docs were
saying.
And lastly, the disassembler should handle every opcode in every mode
now.
ldr rn,[pc,n] adds (pc,n) [absolute address] after opcode. I didn't want
to actually read from ROM here (in case it ever touches I/O or
something), but I suppose we could try anyway.
At startup, it will write out "disassembly.txt" which is a disassembly
of the entire program ROM.
If anyone wants to look for disassembly errors, I'll go ahead and fix
them. Just note that I won't do common substitutions like mov pc,lr ==
ret.
At this point, we can make two moves and then the game tells us that
we've won.
So ... I'm back to thinking the problem is with bugs in the ARM core,
and that our bidirectional communication is strong enough to play the
game.
Although that's not perfect. The game definitely looks at d4 (and
possibly others later), but my hardware tests can't get anything but
d0/d3 set.
byuu says:
That's my best implementation of the shifter carry. It's horribly
inefficient and possibly wrong (especially on ROR by register, but that
doesn't ever appear to be used in this program), but oh well. It's the
best I can do.
Game is basically getting stuck after a board upload and issuing another
command. It's sitting in a loop waiting on $3804.d0 to be set, meaning
the ARM is never writing anything for the CPU to read. There's some
chance that my $3804/r40000000 flags are wrong. Short of guessing
though, I'm not sure how we can get more info on how those work.
... I really can't debug this any better than I have. If no one else
sees anything, then we're going to have to give up and wait for MESS to
create opcode logs for us to compare against.
byuu says:
More ARM work. Can get in-game, and upload the board (0xaa) successfully.
Bug in checkmate command makes the CPU really difficult to defeat :P
byuu says:
Contains the fledgling beginnings of an ARM CPU core, which can execute
the first three and a half instructions of the ST-0018.
It's a start, I guess.
byuu says:
USART improvements. The clock pulse from reading data() drives both
reading and writing.
Also added a usart_init() to bind the initializer functions, so all you
need now is:
extern "C" usartproc void usart_main() { ... }
And inside, you use usart_read(), usart_write(), etc.
So we can add all the new functions we want (eg I'd like to have
usart_readable() to check if data is available) without changing the
entry point signature.
blargg enhanced his Teensy driver to ignore frame error reads, as well.
byuu says:
It is done. bsnes can now emulate sending and receiving data via USART.
As such, the UART code has been removed.
The final UART code can be downloaded here: http://byuu.org/snes/uart/
I won't maintain it going forward, because nobody ever used it, and
USART is superior in every way.
I've also verified both sending and receiving on the real SNES now :D
It's so easy ... a caveman with electrical engineering and computer
programming experience can do it.
byuu says:
USART implements reading and writing, but I don't yet have code to test
SNES reading yet.
So ... obviously I need to do that next.
Went ahead and required nall::function, so the modules will have to be
C++11. I don't see anyone else making these, and it avoids the annoyance
of deducing the correct controller port based on dynamic casting the
active thread.
Apparently a library can have a main() function to no ill effect, so
there's no need for USART_HARDWARE. Same exact code with different flags
will make the binary and the library.
byuu says:
There will probably be a series of small WIPs as I experiment here.
snes/controller/serial is now snes/controller/uart. Asynchronous serial
communications, typically capped at 57,600 baud.
snes/controller/usart is new. It aims to emulate the SNES connected to
a Teensy++ board, and can easily handle 524,288 baud.
And much more importantly, it's synchronous, so there are no timing
issues anymore. Just bit-bang as fast as you can.
Right now, the USART code is just enough for SNES->PC to transfer data
to ... well, nothing yet.
Unless anyone is actually using the UART stuff, I'll be removing it once
the USART is totally up and running.
No sense maintaining code that is 10x slower, more error prone, and used
by nobody.
Note: this is all thanks to blargg being absolutely amazing.
byuu says:
Cart unload save path was using the new game rather than the old game.
Caused by trying to allow a failed cartridge load to not unload the
current game.
But that's so uncommon that it's not worth worrying about. It'll always
unload before trying to load a new game now.
Removed the TM/TS disable speedup, to fix Madara 2's text boxes.
This actually did cause a slight performance penalty on games that
disable layers via TM/TS. Zelda 3 inside Link's house is a good example.
It knocked the FPS from 98.5 to 94.5. So to counter that, I removed
conditionals from tiledata loading and decoding, and used fall through
switches.
This boosted us back to 97.0. The -march=native flag apparently works
better with SB now, so that was added, putting us up to 99.0fps.
So it should be the same speed in the worst case, and slightly faster in
the best case.
Bumped the pre-render time to 68 clocks from 60 clocks. Adjusted sprite
tile fetch time from 22 to 14 to compensate.
This should give us perfectly stable Dai Kaijuu Monogatari 2 battles.
byuu says:
Fixed Super Game Boy RAM saving and loading. It plainly wasn't hooked up
at all. Was apparently hard-coded before it became a multi-emulator.
I also fixed a crashing issue when loading Satellaview-slotted or
Satellaview games without specifying the sub-cart, wasn't setting
has_bsx_slot = true, so the raw memory wasn't being allocated internally
when it wasn't mapped in. Of course a better fix would be to just not
physically map the ranges if the things aren't present. Kind of a lazy
hack to map blank cartridges there, but oh well. Oh, fixed title
displays as well; and did the best I could for now with regards to
multi-file path saving.
byuu says:
The goals for v087 are to have a unified cartridge-folder concept, as
well as a more functional SNES debugger.
Starting with the cartridge folders. What I have so far:
Code:
NES:
- program.rom
- character.rom
- program.ram
- …
SNES:
- program.rom
- program.rtc
- data.rom (SPC7110)
- { dsp1.rom, dsp1b.rom, cx4.rom, … }
- msu1.rom
- track-#.pcm
Game Boy, Game Boy Color:
- program.rom
- program.ram
- program.rtc
Sub-cartridges (BS-X, Sufami Turbo, …) are stored as separate folders
Folder names must be UTF-8 based, with all-lowercase extensions
File names must be all-lowercase
SNES:
- "program.ram" (.srm, .sts)
- "msu1.rom" (name.msu)
- "track-#.pcm" (name-#.pcm)
- "upd96050.ram" -> "name.ram"
- "bsx.ram" (.bss)
- "bsx.psram" (.bsp)
- "serial.so" -> "libserial.so" (broken)
Need:
- Super Game Boy (not even sure how this loads and saves memory, it's
obviously broken)
And I need to think of some way of handling multi-cart loaded games.
Eg Satellaview-slotted and Sufami Turbo. It was { base + slot ( + slot
... } }, but this gets trickier with folders and fixed names.
Actual markup for the NES needs to change as well.
byuu says:
The main focus of this release is Laevateinn, which is the new bsnes
debugger. Unlike previous debuggers, Laevateinn is a standalone
application with its own GUI entirely focused on debugging.
Changelog:
- created ui-debugger target (Laevateinn)
- fixed multitap ports 2-4 [quequotion]
- fixed ui-libsnes target compilation
- fixed a crashing issue with NSS XML markup
- improved cartridge-folder loading support
- NES can now load .fc (headerless NES) or .prg+.chr (split NES) images
- fixed cursor being visible in fullscreen mode when using
Linux/Metacity window manager [ncbncb]
- show normal cursor when using Linux/SDL video driver [ncbncb]
- added menu accelerators
- fixed a bug in performance profile SMP incw/decw instructions
- SNES core can now optionally be built without Game Boy emulation core
- added 2012-02-04 cheats.xml database [mightymo]
byuu says:
Added VRAM viewer (mouse over to get tile# and VRAM address), CPU+SMP
register editors, settings.cfg to cache path+sync audio+mute audio
settings (Windows Vista+ ignore my request for the default folder
because they are fucking stupid, so they always default to your home
folder. I'm going to have to recommend using a batch file to start
laevateinn there. Sorry, blame Microsoft for being fuck-ups),
geometry.cfg to remember where you placed windows and what size you made
them (a bug in Qt prevents me from making some windows fixed-size for
now, but that'll change when I can work around the Qt issue), usage map
invalidation if the ROM was modified after the usage files, that empty
line insertion thing creaothceann wanted on emulation resume, all chips
now synchronize immediately rather than just-in-time, which is important
for a debugger.
Going to postpone the properties viewer until after v086.
So this is pretty much ready for release. Please bug-test. I don't care
so much about little frills like "oh the memory editor window should
default to a little bigger", you can work around that by resizing it.
I care about things like, "VRAM write breakpoints don't work at all."
If we miss any bugs and it gets released, not the end of the world, but
you'll be waiting a while for the next release to address any missed
bugs now.
byuu says:
Changelog:
- follow the Laevateinn topic to get most of it
- also added NMI, IRQ step buttons to CPU debugger
- also added trace masking + trace mask reset
- also added memory export
- cartridge loading is entirely folder-based now
FitzRoy, I'll go ahead and make a second compromise with you for v086:
I'll match the following:
/path/to/SNES.sfc/*.sfc
/path/to/NES.fc/*.prg, *.chr (split format)
/path/to/NES.fc/*.fc (merged format)
/path/to/GB.gb/*.gb
/path/to/GBC.gbc/*.gbc
Condition will be that there can only be one of each file. If there's
more than one, it'll abort. That lets me name my ROMs as
"Game.fc/Game.fc", and you can name yours as "Game.fc/cartridge.prg,
cartridge.chr". Or whatever you want.
We'll just go with that, see what fares out as the most popular, and
then restrict it back to that method.
The folder must have the .fc, etc extension though. That will be how we
avoid false-positive folder matches.
[Editor's note - the Laevateinn topic mentions these changes for
v085r08:
Added SMP/PPU breakpoints, SMP debugger, SMP stepping / tracing,
memory editing on APU-bus / VRAM / OAM / CGRAM, save state menu,
WRAM mirroring on breakpoints, protected MMIO memory regions
(otherwise, viewing $002100 could crash your game.)
Major missing components:
- trace mask
- trace mask clear / usage map clear
- window geometry caching / sizing improvements
- VRAM viewer
- properties viewer
- working memory export button
The rest will most likely appear after v086 is released.
]
byuu says:
Lots of debugger enhancements. Memory editor works for CPU-bus only,
breakpoint editor does nothing yet.
Tracing works, writes to 001-999 files sequentially. Stepping works,
too. But only on the CPU.
Added "privileged", which becomes "public" if DEBUGGER is defined,
"private" otherwise.
Meant so the debugger can stab deeply into the cores for state
manipulation. Interface is guaranteed to be unstable and dependent upon
the accuracy core.
The about screen logo adds 100KB onto the source download (won't affect
regular bsnes binaries), but too bad. I want some visual flair this
time.
byuu says:
Changelog:
- added base/ folder
- base/base.hpp defines the version number for all UI targets, all the
varint-types, and a hook() class for debugger functions (see below)
- fixed compatibility profile compilation
- removed within<> template from the SNES target
- the SNES core can be built without Game Boy support now, if you so
choose (my SNES debugger is not going to support debugging the GBZ80,
sorry.)
- added ui-debugger; not at all useful right now, will be a long while
to get something usable ready
So hook is a class wrapper around nall::function. It allows you to
invoke potentially empty functions (and as such, the return type must
have a trivial constructor.)
It also doesn't actually perform the test+invocation when DEBUGGER
(options=debugger) is not defined. So you should have no overhead in
regular builds.
The core classes now have a subclass with all the debugging hooks, so
you'll see eg:
void CPU::op_step() {
debugger.op_exec(regs.pc);
(this->*opcode_table[op_read()])();
}
Clear what it's doing, clear what it's for. A whole lot less work than
inheriting the whole CPU core and virtualizing the functions we want to
hook.
All the logic for what to do inside these callbacks will be handled by
individual debuggers, so they can have all the functionality they want.
byuu says:
Changelog:
- fixed cursor being visible under Metacity window manager (hopefully
doesn't cause regression with other WMs)
- show normal cursor when using SDL video driver
- added menu accelerators (meh, why not?)
- removed debugvirtual, ChipDebugger and chip/debugger functionality
entirely
- alt/smp disassembler moved up
- fixed alt/smp incw/decw instructions (unsigned->uint16 for internal
variables)
My plan going forward for a debugger is not to hardcode functionality
that causes the 10-15% slowdown right into the emulator itself.
Instead, I'm going to make a callback class, which will be a specialized
version of nall::function:
- can call function even if not assigned (results in no-op, return type
must have a trivial default constructor)
- if compiled without #define DEBUGGER, the entire thing turns into
a huge no-op; and will be eliminated entirely when compiled
- strategically place the functions: cb_step, cb_read, cb_write, etc.
From here, the ui-debugger GUI will bind the callbacks, implement
breakpoint checking, usage table generation, etc itself.
I'll probably have to add some breakout commands to exit the emulation
core prior to a frame event in some cases as well.
I didn't initially want any debugger-related stuff in the base cores,
but the #if debugger sCPUDebugger #else sCPU #endif stuff was already
more of a burden than this will be.
byuu says:
Fixed NSS XML crashing issue.
Improved folder-loading support.
NES can now load game.fc/game.fc, or game.fc/game.prg+game.chr.
Both types should have no iNES header at all.
And both types require an XML file (until we have a built-in database.)
byuu says:
Changelog:
- updated bsnes to use the newest versions of nall and phoenix
- fixed ui-libsnes compilation (testing would be a good idea, especially
the cheat codes. I just copy-pasted that from the regular UI.)
- fixed multitap controllers 2-4 [quequotion]
byuu says:
A new release for the new year.
Changelog:
fixed auto joypad polling edge case; fixes Ys 5 controls
fixed Justifier polling code; Lethal Enforcers should be fully
responsive once again
rewrote SNES S-SMP processor core (~20% code reduction)
fixed Game Boy 8x16 sprite mode; fixed some sprites in Zelda: Link's
Awakening
treat Game Boy HuC1 RAM enable flag as writable flag instead; fixes
Pokemon Card GB
created far faster XML parser; bsnes can now load XML files once again
updated to mightymo's most recent cheat code database
internal color calculations now performed at 30-bits per pixel
gamma slider now acts as fine-tuned gamma ramp option
Linux OpenGL driver will output at 30bpp on capable displays
Linux port defaults to GTK+ now instead of Qt (both are still available)
byuu says:
Okay, everything can now load XML again, including board layouts for all
three systems. New is the ability to load external Game Boy layouts (not
really that useful, but it's there.)
I'd like to aim for a v085 release soon. I've included a binary, so I'd
appreciate testing. I had to redo all of the XML mappings for every
system (I like consistency), so basically the following things need to
be tested:
* load one of every type of game for every system (every NES board type,
* every Game Boy MBC type, every SNES chip and layout type.)
* test cheat codes and the cheat database
* test pixel shaders for OpenGL and Direct3D (sepia for the win)
* test anything else for v085 release
byuu says:
Added the new super-fast XML parser. So far, the shaders, cheat files,
and cheat database have been updated to allow XML mode once again. Which
is sure to please Screwtape =)
So it's down to just the cartridge mapping files now, which are always
a major pain.
I still think BML is better for parsing simplicity, memory usage, disk
size, lack of red tape and speed (but horrendously bad for ease of
creating files manually), but since the base API is identical, there's
no reason not to support both. Especially since the pixel shaders have
kind of taken on a life of their own.
byuu says:
Changelog:
- fixed sprite tile masking for 8x16 mode (fixes Zelda: DX sprites)
- HuC1 flag sets RAM writable, not RAM enable (fixes Pokemon Card)
- removed within<> template, didn't turn out to be all that useful
I would be almost certain no games would break by allowing reads when it
is disabled, no game would rely on that behavior.
I prefer to be overly restrictive. Better to not allow valid behavior
than to allow invalid behavior. The latter is what gives us a dozen
broken SNES translations.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
byuu says:
Fixed the Ys 5 input bug in the auto joypad polling code. Can't
guarantee it's hardware-accurate (I have no way to extensively test it),
but I can guarantee it is closer to being correct now.
Also uses updated version of phoenix.
The justifier input is indeed all fucked up now. Seems like it stops
updating input after firing for a few frames.
I really don't want to debug that code anymore ... anyone want to make
$10 by fixing it? :P
(r02 was not posted to the WIP thread)
byuu says:
Internally, all color is processed with 30-bit precision. The filters
also operate at 30-bit depth.
There's a new config file setting, video.depth, which defaults to 24.
This causes the final output to downsample to 24-bit, as most will
require.
If you set it to 30-bit, the downsampling will not occur, and bsnes will
ask ruby for a 30-bit surface. If you don't have one available, you're
going to get bad colors. Or maybe even a crash with OpenGL.
I don't yet have detection code to make sure you have an appropriate
visual in place.
30-bit mode will really only work if you are running Linux, running Xorg
at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD
FireGL card with the official drivers, and have a 30-bit capable
monitor.
Lots of planning and work for very little gain here, but it's nice that
it's finally finished.
Oh, I had to change the contrast/brightness formulas a tiny bit, but
they still work and look nice.
I rewrote the S-SMP processor core (implementation of the 256 opcodes),
utilizing my new 6502-like syntax. It matches what bass v05r01 uses.
Took 10 hours.
Due to being able to group the "mov reg,mem" opcodes together with
"adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from
55.7KB to 42.5KB for identical accuracy and speed.
I also dropped the trick I was using to pass register variables as
template arguments, and instead just use a switch table to pass them as
function arguments. Makes the table a lot easier to read.
Passes all of my S-SMP tests, and all of blargg's
arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't
test further.
This does have the potential to cause some regressions if I've messed
anything up, and none of the above tests caught it, so as always,
testing would be appreciated.
Anyway, yeah. By writing the actual processor with this new mnemonic
set, it confirms the parallels I've made.
My guess is that Sony really did clone the 6502, but was worried about
legal implications or something and changed the mnemonics last-minute.
(Note to self: need to re-enable snes.random before v085 official.)
EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside
term(). Without it, there is a tiny pop when the driver is
re-initialized. But with it, the entire emulator would lock up for five
whole seconds waiting on that call to complete. I'll take the pop any
day over that.
byuu says:
Hiding the viewport is necessary on Windows to prevent it from
overlapping the status bar. I've changed it to set the size to 1,1 when
nothing is loaded.
That still puts a 1x1 pixel over the status bar when you resize the
window to 1xHeight, but ... you know, don't do that.
Also corrected the mask overscan option for NES/SNES.
Silently updated the bsnes_v084-source.tar.bz2 archive with those fixes,
there were only 48 downloads.
byuu says:
This release adds preliminary Game Boy Color emulation. Due to lack of
technical information, this is undoubtedly the least stable module
I provide at this time; but improvements should continue as it is
developed.
This release also polishes the NES emulation and user interface code.
Changelog (since v083):
- added preliminary Game Boy Color emulation
- NES: added MMC6, VRC1, VRC2, VRC3 emulation
- NES: fixed MMC5 banking and added split-screen support [Cydrak]
- NES: pass all of blargg's ppu_vbl_nmi tests, pass more sprite tests
- NES: palette is now generated algorithmically [Bisqwit]
- SNES: fixed SA-1 IRQ regression caused by code refactoring
- Game Boy: rewrote audio channel mixing code; sound output is greatly
improved as a result
- Game Boy: uses DMG boot ROM instead of SGB boot ROM
- Game Boy: fixed potential bug when loading save states
- phoenix: fixed ListView focus issue [X-Fi6]
- phoenix: fixed dialog message parsing [X-Fi6]
- ui: video output is truly 24-bit now; SNES luma=0 edge case emulated
- ui: audio frequency, latency, resampler are now user configurable
- ui: gamma ramp is dynamically adjustable
- ui: all filters ported to 24-bit mode (speed hit to HQ2x)
- ui: added turbo button mappings for all generic controllers
- ui: fixed audio volume on unmute via menu [Ver Greeneyes]
- ui: shrink window option does nothing when no cartridge is loaded
- ui: re-added compositor disable, driver verification from v082
byuu says:
Changelog:
- NES: added VRC1, VRC2, VRC3, MMC6 emulation
- shrink window doesn't do anything when no cartridge is loaded
- phoenix Horizontal,VerticalLayout use const Size& instead of unsigned
width,height [for consistency]
So, all official NES ASICs are supported now. Just need sound output for
MMC5+VRC7 to complete them; and then some board re-arrangement stuff for
VRC2+MMC3.
Note that MMC6 uses the same mapper ID as MMC3, and VRC2 uses the same
ID as VRC4, so you have to make a BML board mapping or toggle which type
is chosen in the source file to use these two chips.
Side note: NES overscan clamping is obviously still assuming 16-bit, as
only half the lines are erased. Need to fix that.
byuu says:
Added frequency, latency, resampler selection to the audio settings
panel (I really only wanted it there for resampler selection ... having
three options matches the driver selection style though, so whatever.)
The linear/hermite sampler will double the framerate when running Game
Boy games, and sounds the same. Same framerate and sound quality on
SNES. But it will cause buzzing in many NES titles.
Also re-added the composition { never, fullscreen, always } modes.
I think that option is clutter, but it's just impossible to get good
audio+video on Windows 7 without it ...
Lastly, HQ2x was ported over, but not very well. I just convert source
pixels from RGB888 to RGB555, and output pixels in the opposite
direction.
Need someone good to port the diff() and blend functions over to RGB888
in a way that's not terribly slow.
byuu says:
Fixed SA-1 IRQ regression for Super Mario RPG
Added turbo B,A to NES+GB; B,A,X,Y to SNES (please don't ask for turbo
L,R; you never use those keys rapidly.)
Re-added video color adjustments, which are now done in full 8-bit
colorspace for more precision
Gamma ramp option is gone. It's now the gamma option, which now only
affects the lower-half of the colors.
A value of 1.0 gives you the original, washed out colors. 1.75 is what
the gamma ramp checkbox used to do (roughly).
The new default is 1.5, which still prevents color washout, but isn't as
overly dark as before.
I wanted to make the core/interface stuff abstract the complexity of
setting up a new C++ class, but it really didn't make anything easier.
It was all one-line stubs to internal functions, and there was just too
many platform-specific things that needed to be captured, so I did away
with that. Made a base class for the ui/interface stuff to get rid of
a lot of switch(mode()) stuff, still a work in progress.
byuu says:
Game Boy: audio should sound a lot better, eg Zelda: DX first opening
scene
Game Boy Color: now uses cothread Processor::frequency to dynamically
clock GB-CPU to 8MHz. Proper OAM DMA and timer speed. Fixes SMT: DC - WB
audio.
Added the break; statements to phoenix/windows/platform message loop
Added audio latency/frequency to config file only
byuu says:
All cores: Video classes have internal->{RGB30,24,16,15} palette
generation support
All cores: video output is now RGB24, all filters except HQ2x were
updated to reflect this (HQ2x will be very hard)
NES: MMC5 CHR mapping fixes (Bandit Kings, RTK2, Uchuu Keibitai SDF)
[Cydrak]
NES: MMC5 vertical split screen support (Uchuu Keibitai SDF) [Cydrak]
Game Boy + Game Boy Color: fixed a potential freezing bug when loading
save states (re-create cothreads on state load; was implied when using
SGB mode.)
Game Boy Color: fixed freezing bug with Zelda: LA opening (SVBK is
readable.)
Game Boy Color: more accurate colors (better than GiiBii, probably worse
than KiGB)
SNES: luminance of zero is no longer pure black, as on real hardware.
This is possible thanks to using RGB888 output now.
The current major problems I'd like to solve:
- Zelda: Link's Awakening music when Link first wakes up in the house is
atrociously bad
- Shin Megami Tensei: Devil Children - White Book (Shiro no Sho) plays
music at 50% speed; yet Black Book (Kuro no Sho) does not ... one of
my favorite games, so it'd be great to fix it
(r04 was not posted to the WIP thread)
byuu says:
NES: passes ppu_sprite_overflow tests 01, 02, 05.
Game Boy: uses DMG BIOS (the one with the slow title scroll) or SGB
BIOS, based upon how you load the game.
Game Boy Color: Everything except the IR port is emulated. I don't have
any plans to allow linking two instances of bsnes. And that's frankly
never going to happen over netplay anyway, due to latency requirements
of the serial/IR ports.
The new DMA stuff is possibly incorrect, my test games don't seem to use
it.
Zelda: DX usually resets or crashes on the intro right before the beach
scene. I'm not sure why. Skip the intro and the game plays fine.
This is the best I can do when the most up-to-date GB/C reference
document is over ten years old and half-assed (pandocs.)
I could really use some help from anyone who understands the system.
Probably the worst part of my emulation at the moment is the interrupt
system.
Lots of things real hardware doesn't allow (DMA outside HRAM, CGB DMA to
invalid addresses, etc) isn't blocked yet.
LCD renderer is still scanline-based, which is just terrible. Doesn't
seem to be any good docs on cycle-level operation. I only know that it's
incredibly pathological and variable.
byuu says:
Lots of phoenix issues fixed, especially for Windows and GTK+.
NES emulation passes all ten ppu_vbl_nmi tests from blargg.
Sprite timing is nowhere near accurate yet (always consumes four clocks
per sprite), but oh well.
byuu says:
This adds Bisqwit's NES palette generation code:
http://nesdev.parodius.com/bbs/viewtopic.php?p=85060#85060
I set the saturation to 2.0 to closer match the existing "bright"
palette, although it still has a greater contrast range (some colors are
darker.) The gamma ramp option works now. Like SNES, best to also set
gamma to 0.8 afterward. Once I think of a good way to expose the
saturation/hue settings, I'll do so.
I've also merged in the updated nall. Adds Cygwin uname check, and
replaces linear_vector with vector in lstring and the GUI.
byuu says:
This release adds preliminary Nintendo / Famicom emulation. It's only
a week or two old, so a lot of work still needs to be done before it can
compete with the most popular NES emulators.
It's important to clarify: bsnes is primarily an SNES emulator. That
will always be its forte and my core focus. I have added Game Boy
support previously for Super Game Boy emulation, and I've added NES
support mostly for something fun to work on to break up the monotony of
working on one system for seven years now. Obviously, I'd like the
emulation to be accurate and highly compatible, but I simply cannot
afford to invest the same amount of time and money into any other
systems.
Still, either way the NES and GB emulation serve as fun side-diversions,
and allow for a unified emulator interface with all of bsnes' unique
features applied to all systems. My personal favorite feature is
mightymo's extended built-in cheat code database that now also includes
NES and Game Boy codes. And it even works in Super Game Boy mode now,
too!
I'm also not worried about speed at all: so long as NES/GB are faster
than SNES/compatibility, it's fine by me. Note that due to the NES audio
running at 1.78MHz, and Game Boy audio at 4MHz stereo, a more
sophisticated audio resampler was needed: Ryphecha (Mednafen author) has
graciously written a first-rate resampler: it is a band-limited
Kaiser-windowed polyphase sinc resampler. It is combined with two
highpass filters to remove DC bias. The filter itself is SSE optimized,
but even still, approximately 50% of CPU usage for NES/GB emulation goes
to the audio filtering alone. However, you now have the best sound
possible for NES and Game Boy emulation as a result.
The GUI has also been heavily re-structured to accommodate multiple
emulators from the same interface. As such, it's quite likely a few bugs
are still lurking here and there. Please report them and I'll iron them
out for the next release.
Changelog:
- license is now GPLv3
- re-structured GUI as a multi-system emulator
- added NES emulation [byuu, Ryphecha]
- added NES ICs: MMC1, MMC2, MMC3, MMC4, MMC5, VRC4, VRC6+audio, VRC7,
Sunsoft-5B+audio, Bandai-LZ93D50
- added NES boards: AxROM, BNROM, CNROM, ExROM, FxROM, GxROM, NROM,
PxROM, SxROM, TxROM, UxROM
- Game Boy emulation improvements [Jonas Quinn]
- SNES core outputs full 19-bit color (4-bit luma included) for more
accurate color reproduction (~5% speed hit)
- audio resampler is now a band-limited polyphase resampler [Ryphecha]
- cheat database includes NES+GB codes as well [mightymo, tukuyomi]
- lots of other changes
byuu says:
Added MMC2, MMC4, VRC4, VRC7 (no audio.)
Split NES audio code up into individual modules.
Fixed libsnes to compile: Themaister, can you please test to make sure
it works? I don't have a libsnes client on my work PC to test it.
Added about / license information to bottom of advanced settings screen
for now (better than nothing, I guess.)
Blocked PPU reads/writes while rendering for now, easier than coming up
with a bus address locking thing :/
I can't seem to fix MMC5 graphics during the intro to Uchuu Keibitai.
Without that, trying to implement vertical-split screen mode doesn't
make sense.
So as far as special audio chips go ...
* VRC6 is completed
* Sunsoft 5B has everything the only game to use it uses, but there are
more unused channels I'd like to support anyway (they aren't
documented, though.)
* MMC5 audio unsupported for now
* VRC7 audio unsupported, probably for a long time (hardest audio driver
of all. More complex than core NES APU.)
* audio PCM games (Moero Pro Yakyuu!) I probably won't ever support
(they require external WAV packs.)
byuu says:
Added delay to MMC1 register writes, to fix Bill & Ted's Godawful
Adventure.
Fixed up MMC5 RAM+fill mode, and added EXRAM mode support (8x8
tiles/attributes.)
Just Breed is fully playable now.
MMC5 is a total pain in the ass, the documentation on it is just
terrible. I basically just tried seven hundred variations until
something worked.
I still need to add MMC5 vertical split screen (for one single game's
attract screen, ugh), and the extra sound channels.
Would like to rework the NES APU first. Since the pulse channels are
identical sans sweep, it'd be nice to just inherit those and mask out
the sweep register bit writes.
So that probably won't make it into the first release, at least.
Still, overall I think it'll be an impressive showing of complex mappers
for a first release: MMC3, MMC5, VRC6 and 5B. The latter two with full
audio. The only other really, really hard bit is the VRC7 audio,
supposedly.
byuu says:
Enable Overscan->Mask Overscan [best I'm doing]
Video settings -> Overscan mask: (horizontal, vertical: 0-16 on each
side) [only works on NES+SNES]
BPS patching works for NES+SNES+GB; note that long-term I want BPS to
only patch headerless PRG+CHR files, but we'll need a database
/ completed board mapping system first.
MMC1 splits the board/chip markups a bit better. My attempts to emulate
the extra CHR bits per hardware fail repeatedly. Docs do not explain how
it works at all.
Emulated enough of the MMC5 to play Castlevania 3.
The MMC5 is easily the most complicated mapper the NES has to offer, and
of course, has the most pitifully vague and difficult documentation of
any mapper around.
It seems the only way anyone is able to emulate this chip is
empirically.
Everyone else apparently hooks the MMC5 right into the PPU core, which
I of course cannot do. So I had to come up with my own (probably wrong)
way to synchronize the PPU simply by observing CHR bus accesses.
I must say, I over-estimated how well fleshed out the NES hardware
documentation was. Shit hits the fan right after MMC3.
It's miles beyond the GB scene, but I find myself wanting for someone
with the technical writing ability of anomie.
I can't find anything at all on how we're supposed to support the $2007
port reads/writes without it extra-clocking the PPU's bus, which could
throw off mapper timing.
Absolutely nothing at all on the subject anywhere, something everybody
is required to do for all cycle-based emulators and ... nada.
Anyway, I'd like to refine the MMC5 a bit, getting Just Breed playable
even without sound would be really nice (it's a fun game.)
Then we need to get libsnes building again (ugh, getting worn out in
backporting changes to it.)
Once v083 is public, we can start discussing a new API for multiple
emulators.
byuu says:
cheats.xml -> cheats.bml, includes NES+SNES+GB codes now. Absolutely
awesome, thanks to mightymo and tukuyomi.
I also added Sunsoft-FME7/5B (with sound) emulation. Really only useful
for playing the Japanese release of Gimmick!
Fun game, but balls to the wall hard.
byuu says:
I doubt anyone is going to like these changes, but oh well.
The base height output for NES+SNES is now always 256x240. The Enable
Overscan option blanks out borders around the screen. This eliminates
the need for an overscan software filter. For NES, it's 16px from the
top and bottom, and 8px from the left and right. Anything less and you
get scrolling artifacts in countless games. For the SNES, it's only 16px
from the top and bottom. Main point is that most NTSC SNES games are
224-height games, so you'll have black borders. Oh well, hack the source
if you want. Game Boy overscan option does nothing.
Everything except for the cheats.xml file now uses BML markup. I need to
write a converter for cheats.xml still. Cut the SNES board parsing code
in half, 30KB->16KB. Much cleaner now.
Took the opportunity to fix a mistake I made back with the XML spec: all
numbers are integers, but can be prefixed with 0x to become hexadecimal.
Before, offset/size values defaulted to hex-mode even without a prefix,
unlike frequency/etc values.
The XML shaders have gone in their own direction anyway, with most being
multi-pass and incompatible with bsnes. So that said, please don't
extend the BML functionality from your end. But f eel free to add to the
XML spec, since other emulators now use that as well. And don't
misunderstand, I love the work that's being done there. It's pretty
awesome to see multi-pass shader capabilities, and the RAM watching
stuff is just amazing.
If there are any really awesome single-pass shaders that people would
like, I can convert it from XML and include it with future releases.
On that topic, I removed the watercolor/hdr-tv ones from the binary
packages (still in the source archive) ... they are neat, but not very
useful for actual gaming.
If we had more than one, I'd remove the Direct3D sepia one. Not going to
use shaders from a certain bipolar manic, because I'd never hear the end
of it if I did :/
Oh, one change I think people will like: MSU1 no longer requires
a memory map specification, so MSU1 authors won't have to keep updating
to my newer revisions of board markups. Basically, if there's not
a board with an msu1 section, it'll check if "gamename.msu" exists. If
it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is
music, make a blank, zero-byte gamename.msu file.
byuu says:
Was mostly working on BML. Still working on the spec.
Added NES-BNROM, NES-GNROM/NES-MHROM boards. I don't even know why. The
latter games do not work very well without Zapper support.
byuu says:
Finished porting over all mappers to board/chip disambiguations. Had to
nearly rewrite the MMC1 code to do it, but all variants should be
supported.
iNES1 is too stupid to express them all, so you'll need a board markup
if you want to play the >8KB PRG RAM games.
For whatever reason, they call VRC6's memory WRAM, and MMC1's PRG RAM.
I am calling them all PRG RAM, since it's the same damn thing.
Board spec is not going to be stable until I have a hell of a lot more
mappers implemented, so be wary of that.
Anyway, at this time, all games can be loaded sans iNES header, if you
have the board markup. I'd also like to have a board database for all
commercial titles.
I'm treating *.fc as PRG-ROM(+CHR-ROM). Will work on loading the split
files later possibly.
byuu says:
.cht files now use BML-formatted data. I'm still going to request the
cheats.xml file as-is, and will write my own converter for embedding
during releases.
This is where parsing 2MB markup files in 10ms is really going to be
nice. Had to use an evil hack before for actually searching for games.
This has the start of the board/chip separation from mappers for NES,
and it has a barebones iNES->board markup converter.
You can specify your own board markup and bypass the need for an iNES
header, so in other words it will load No-Intro style games with
a proper board file.
Long-term, we'll have an internal database for commercial boards, and
probably folder.fc/prg.rom{,chr.rom} loading support.
Since they can't co-exist, the mappers are currently disabled, and I've
only ported the easy ones. So no MMC1/MMC3/VRC6 in this release. I need
to make them into chips first.
byuu says:
Ryphecha fixed Gun Nac, it was some sort of problem with blank sprite
address fetching messing with the MMC3
I've started on an XML parser for iNES-free loading, but it's pretty
barebones right now. Only NROM-256 loads, and you have to make it
a compile-time thing (so other games work for now.)
Updated nall with nullptr stuff.
nall/detect is now nall/intrinsic and has both #defines + static
constants that can be used to detect the platform (allows for run-time
platform checks where practical.)
ruby has a Makefile now, that makes using it in other projects a lot
easier
byuu says:
Upgraded to GCC 4.6.1.
Removed nall/foreach and nall/concept, upgraded iterator support on all
of my containers, and replaced everything with range-for.
Fixed up Qt geometry a good bit, should at least create windows now without bouncing around.
Added some initial nullptr / constexpr changes.
Some other minor cleanups ... removing foreach() took about 6-8 hours
alone.
byuu says:
Ryphecha fixed the FF1 glitch, added two highpass filters to NES audio
output (still working on a lowpass), and fixed VRC6 audio issues.
I reduced the complexity of all eight supported mapping modes, and
standardized them; and added in an overscan filter (not in archive) for
chopping off all the NES edge garbage (8 pixels on the left and right,
16 on the top and bottom.)
It's extreme, but anything less shows junk. I may make this part of the
menu option, just clip off more on NES mode than SNES mode.
byuu says:
Mappers are now optionally threaded.
Fixed up MMC3 emulation, SMB3 and MM3-6 are all fully playable. However,
many unusual variants of this chip are not supported still.
Added UNROM+UOROM for Contra and MM1, allowing all six MM games to play
now.
Added VRC6 with sound emulation, because I wanted to get audio mixing in
place.
Chose VRC6 because it has Esper Dream 2, which is an absolutely amazing
game that everyone should play :D
The game didn't use sawtooth, and I didn't test any other VRC6 games, so
hopefully that is emulated passably well enough.
byuu says:
2-6% speed hit in SNES core for outputting 19-bit (rounded to 32-bit ...
sigh) video, so that luma non-linearity can eventually be emulated
properly.
Now using sinc audio resampler, massive speed hit of course to NES+GB
only, but it's required to get rid of aliasing (buzzing) present in
many, many games otherwise.
Fixed fast forward and none/blur select.
Finally fixed texture clearing for changing pixel shaders and video
filters.
Some realllly basic NES MMC3, extremely broken so don't bug me about it.
Other stuff, probably.
byuu says:
NES now has save state support.
NES A/B buttons were indeed swapped, so that's fixed now.
nall/dsp now puts resamplers into separate classes, so that each can
have their own state information.
opengl.hpp uses GL_RGBA internal format and doesn't regenerate textures
on resize. No speedup, no fix to junk on resize, so I will be very
unhappy if this breaks things for anyone.
GLSL shaders use <fragment filter="nearest/point"> as you guys wanted.
ui-snes was removed.
This was released beside bsnes v082r19. byuu didn't mention it in the
v082r19 release notes, but in a previous post mentioned that a number of
filters stopped working when bsnes switched to using RGB555 for all its
internal data.
byuu says:
This will be the last release with the ui-snes folder (it's broken now
anyway.)
Re-added cheat code database searching + add window. It hashes
NES+SNES+GB images now and will look them up in the database.
Re-added filter support, all filters now output at RGB555. Stacking is
possible, but I don't currently allow it.
Removed mouse capture + test options from tools menu.
Removed smooth video output from settings menu.
There are now two built-in "shaders": "None" (point filtering) and
"Blur" (linear filtering).
OpenGL shaders can now use <shader language="GLSL" filter="point"> (or
"linear") to specify their filtering mode.
Individual emulator versions are gone, and names are hidden from the
GUI: you just see bsnes v082.19 now. A new release bumps all core
versions.
I cannot for the life of me get the video to clear properly when
toggling the shaders. Say you set pixellate2x filter, then turn on
curvature shader, then turn off the filter, you get junk at the bottom
right.
I have tried clearing and flipping the OpenGL surface 64x in a row ...
I don't know where the hell it's getting the data from. If anyone can
make a small patch to fix that, I'd greatly appreciate it.
byuu says:
There we go, the GUI is nearly feature-complete once again.
All cores now output their native video format (NES={emphasis}{palette},
SNES=BGR555, GameBoy={ bright, normal, darker, darkest }), and are
transformed to RGB555 data that is passed to the video renderer.
The video renderer then uses its internal palette to apply
brightness/contrast/gamma/ramp adjustments and outputs in RGB888 color
space.
This does add in another rendering pass, unfortunately, but it's
a necessary one for universal support.
The plan is to adapt all filters to take RGB555 input, and output RGB555
data as well. By doing this, it will be possible to stack filters.
However, it's a bit complicated: I need to plan how the stacking should
occur (eg we never want to apply scanlines before HQ2x, etc.)
Added input frequency adjustments for all three systems. I can easily
get perfect video/audio sync on all three now, hooray.
Long-term, it seems like we only really need one, and we can do
a video/audio delta to get an adjusted value. But for now, this gets the
job done.
Added audio volume adjust. I left out the balance for now, since it's
obviously impossible to balance the NES' single channel audio (I can
duplicate the channel, and do twice the filtering work, but ... why?)
I replaced NTSC/PAL TV mode selection with an "Enable Overscan"
checkbox. On, you get 240 lines on NES+SNES. Off, you get 224 lines on
NES+SNES.
Also added aspect correction box back. I don't do that gross PAL
distortion shit anymore, sorry PAL people. I just scale up the
54/47*(240/224) aspect correction for overscan off mode.
All memory is loaded and saved now, for all three systems (hooray, now
you can actually play Zelda 1&2.)
Added all of the old bsnes hotkeys, with the exception of capture
screenshot. May add again later. May come up with something a bit
different for extra features.
Re-added the NSS DIP switch setting window. Since geometry is saved,
I didn't want to auto-hide rows, so now you'll see all eight possible
DIPs, and the ones not used are grayed out.
Ultimately, nobody will notice since we only have DIPs for ActRaiser
NSS, and nobody's probably even using the XML file for that anyway.
Whatever, it's nice to have anyway.
Took FitzRoy's advice and single-item combo boxes on the input selection
are disabled, so the user doesn't waste time checking them.
I wanted to leave text so that you know there's not a problem. Qt
disabled radio box items look almost exactly like enabled ones.
Fixed lots of issues in phoenix and extended it a bit. But I was still
having trouble with radio box grouping, so I said fuck it and made the
panels show/hide based instead of append/remove based.
That's all for stuff off the checklist, I did a bunch of other things
I don't recall.
So yeah, I'd say the GUI is 100% usable now. This is my opinion on how
multi-platform GUIs should be done =)
Oh, I figure I should mention, but the NES core is GPLv3, and all future
SNES+GB releases will be as well. It's a move against Microsoft's Metro
store.
byuu says:
Adds BS-X/Slotted/SufamiTurbo/SGB cartridge loading. Calling it
Satellaview as I'm more partial to that at the moment.
FileBrowser now remembers your folders per filter type like before, and
will keep your place in the list if you don't switch away.
I wanted there to be ONE slot loader, so the loader will show a grayed
out secondary slot on non-ST loading, but it's more consistent to only
have one window instead of two for geometry placement.
Removed help menu. Will try and work it in somewhere unobtrusive later
on I suppose.
Added timed messages and the usual "no cart loaded / paused" messages
and such.
byuu says:
Binary output is once again called bsnes. No versioning on the title
without a system cartridge loaded. Still saving config files to
.config/batch for now.
Finally fixed NES APU frame IRQ clearing on $4015 reads.
Added mouse button/axis binding through buttons on the input capture
window.
Added advanced settings window with driver selection and focus policy
settings. Will show your default driver properly if none are selected
now, unlike old bsnes.
That exposed a small bug where phoenix isn't removing widgets on
Layout::remove, worked around it for now by hiding the panels. Damn,
sick of working on phoenix.
Added all missing input controllers, which can all now be mapped, and
bound them to the main menu, and added NES support for selecting "no
connected controller."
Added mouse capture and the requisite tools menu option for it.
Added WindowManager class that keeps track of both position and size now
(eg full geometry), so now you can resize your windows and save the
settings, unlike old bsnes.
WindowManager has more stringent geometry checks. The *client area* (not
the window border) can't be below 0,0 or above the width/height of three
30" monitors. If you have 4+ 30" monitors, then fuck you :P
settings.cfg is now also saved, captures all currently available
settings. Right now, there's only one path for the file browser to
remember. I will probably make this per-system later.
FileBrowser has been made a bit more friendly. The bottom left tells you
what type of files the list is filtered by (so you see "*.sfc" for
SNES), and the bottom right has an open button that can enter folders or
load files.
Added video shader support.
Fixed nall/dsp variadic-channel support, was only outputting the left
channel.
byuu says:
7.5 hours of power coding. Das Keyboard definitely helped (but didn't
eliminate) RSI, neato.
Okay, the NES resampler was using 315 / 88.8 by mistake, so the output
rate was wrong, causing way more video/audio stuttering than necessary.
STILL forgot the NES APU frame IRQ clear thing on $4015 reads, blah. Why
do I always remember things right after uploading the WIPs?
Recreated the input manager with a new design, works much nicer than the
old one, a whole lot less duplicated code.
Recreated the input settings window to work with the new multi-system
emulation.
All input settings are saved to their own configuration file, input.cfg.
Going to batch folder for now.
Okay, so the new input settings window ... basically there are now three
drop-downs, and I'm not even trying to label them anymore.
They are primary, secondary, tertiary selectors for the listed group
below. Examples:
"NES -> Controller Port 1 -> Gamepad"
"SNES -> Controller Port 2 -> Super Scope"
"User Interface -> Hotkeys -> Save States"
I am aware that "Clear" gets disabled when assigning. I will work on
that later, being lazy for now and disabling the entire window. Have to
add the mouse binders back, too.
Escape and modifiers are both mappable as individual keys now. If you
want to clear, click the damn clear button :P
Oh, and all input goes to all windows for now. That'll be fixed too when
input focus stuff is re-added.
byuu says:
Emulates DMC channel (sound effect when Link gets hit in Zelda 1, for
instance), fixes up bugs in rectangle/sweep and triangle channels, adds
DMC/frame APU IRQs, adds proper stalling for DMC ROM reads (should even
be cycle accurate, but has one extra cycle when triggered during OAM
DMA, I think), but forgets the frame IRQ acknowledge clear on $4015 read
(will fix next WIP.) All sound courtesy of Ryphecha.
Made template configuration settings window (empty for now.) Simplified
SNES cheat.cpp code. Some other stuff.
Further developed RSI.
byuu says:
I've updated the {System}::Interface classes to encapsulate all common
functionality, so they are C++ equivalents of libsnes now.
The idea being, use the interface class and you'll never have to reach
into core objects (unless you really want to.)
Not guaranteeing as stable an API as I do with libsnes for that, though.
C++ doesn't make for nice dynamic libraries, anyway.
Added back the state manager, and it now works for both SNES and Game
Boy. NES save states aren't in yet.
Anyway, this should give you a pretty good feel for what the combined UI
is going to be like: same as before, everything works the same. Only
difference is the dynamic system menu and cartridge menu with more load
options. The settings window will be mostly the same as well, but will
obviously have options that only apply to some systems.
byuu says:
Merged Ryphecha's APU emulation, so NES has sound output now. We are
still missing the DMC memory fetch, so there will be missing sound
effects here and there.
byuu says:
Emulated the Game Genie for the NES and Game Boy, and wrote a new cheat
editor that doesn't reach into specific emulation cores so that it would
work.
Before you ask: yes, long-term I'd like Super Game Boy mode to accept
Game Boy codes. But that's not high on the priority list.
Renamed the mappers toward board names, LZ...->BandaiFCG,
LS161...->AOROM, added CNROM emulation (Adventure Island, Gradius, etc.)
Added the tools menu load/save state stuff, but note that the NES
doesn't have save state support yet (waiting for the interface to
stabilize a bit more first.)
Note: this will be the last release to have the ui-gameboy folder, it's
been deleted locally from my end, as the new multi-GUI does all that it
does and more now.
byuu says:
Fixed up the PPU to be as close to cycle-perfect as possible. Fixed RMW
to write twice instead of read twice. Ryphecha added AOROM and fixed up
MMC1. Have CNROM too, but I need to rethink the mapper/board
distinction. Apparently the same logic IC is used in both AOROM and
CNROM, and it's just a matter of routing the pins to it. I need to
consider how crazy it'd be to emulate the logic IC and have boards
simply reroute pins to it. If it's too much work, we'll just treat
mappers as board + logic IC combinations. We'll see.
byuu says:
Emulated MMC1, currently defaults to B2 configuration. Fixed a whole
bunch of timing things, render things, nametable mirroring things, etc.
Zelda and Mega Man II are fully playable, but they have odd vertical
scrolling issues that make it a not so fun experience.
Not sure what the problem is there, yet. The Y scroll register writes
seem to be wonky ... I don't know.
Keeping the Cartridge menu always visible now, so it's faster to load
carts, but I am still hiding the non-loaded system menus.
byuu says:
Okay, I fixed up many outstanding phoenix issues.
* Windows/GTK+ fixed by using processEvents instead of main(); Windows can run unthrottled, and GTK+ shows the window contents now
* fixed keyboard beeping once and for all on Windows: I now whitelist tabbable controls
* fixed main menubar setVisible calls
* Qt and GTK+ now allow you to resize windows smaller than they initially were
Both Qt and GTK+ still fuck up the geometry a bit when toggling fullscreen mode. I have tried, and tried, and tried and tried and tried to fix it all. Nothing works. I give up.
Easier to destroy and recreate the fucking window than figure out how to resize it on Linux (and no, I can't do that. ruby would not like the handle changing.)
As for the GUI:
* file browser is back in, still need remember place and open folder code; that needs to be extended to handle multiple systems now
* shrink window command added to tools menu.
byuu says:
So, here's the deal. I now have three emulators. I don't think the
NES/GB ones are at all useful, but I do want them to be eventually. And
having them have those pathetic little GUIs like ui-gameboy, and keeping
everything in separate project folders, just doesn't work well for me.
I kind of "got around" the issue with the Game Boy, by only allowing SGB
mode emulation. But there is no "Super Nintendo" ... er ... wait ...
uhmm ... well, you know what I mean anyway.
So, my idea is to write a multi-emulator GUI, and keep the projects
together. The GUI is not going to change much. The way I envision this
working:
At startup, you have a menubar with: "Cartridge, Settings, Tools, Help".
Cartridge has "Load NES Cartridge", "Load SNES Cartridge", etc.
When you load something, Cartridge is replaced with the appropriate
system menu, eg "SNES". Here you have all your regular items: "power,
reset, controller port selection, etc." There is also a new "Unload
Cartridge" option, which is how you restore the "Cartridge" menu again.
I have no plans to emulate any other systems, but if I ever do emulate
something that doesn't take cartridges, I'll change the name to just
"Load" or something.
The cheat editor / state manager will look and act exactly the same. The
settings panel will look exactly the same. I'll simply show/hide
system-specific options as needed, like NES/SNES aspect ratio
correction, etc. The input mapping window will just have settings for
the currently loaded system. Video and audio tweaking will apply
cross-system, as will hotkey mapping.
The GUI stuff is mostly copy-paste, so it should only take me a week to
get it 95% back to where it was, so don't worry, this isn't total GUI
rewrite #80.
I am, however, making all the objects pointers, so that I can destruct
them all prior to main() returning, which is certainly one way of fixing
that annoying Windows/Qt crash.
Please only test on Linux. The Windows port is broken to hell, and will
give you a bad impression of the idea:
- menu groups are not hiding for some reason (all groups are showing, it
looks hideous)
- Timer interval(0) is taking 16ms per call, capping the FPS to ~64 tops
[FWIW, bsnes/accuracy gets 130fps, bgameboy gets 450fps, bnes gets
800fps; all run at lowest possible granularity]
- the OS keeps beeping when you press keys (AGAIN)
Of course, Qt and GTK+ don't let you shrink a window from the requested
geometry size, because they suck. So the video scaling stuff doesn't
work all that great yet.
Man, a metric fuckton of things need to be fixed in phoenix, and
I really don't know how to fix any of them :/
byuu says:
Couple more fixes to audio from Jonas, and I converted all types from
"unsigned" to the smallest sizes possible, which simplified a bit of the
code. Love variable-length integers.
Audio core should be really good now. Not perfect, but pretty close for
99% of games. Also fixed the window stuff for Cool World and such.
byuu says:
Has Jonas Quinn's many Game Boy APU fixes, and two more from blargg's
notes that I added.
It also has the new dynamic phoenix. So yeah, it'll crash on bsnes/Qt
exit. If anyone can fix it *properly* and wants the money, I'll pay them
$20 for the trouble =)
byuu says:
Changelog:
- if config file window coordinates are >= 30000, it snaps them back to
128,128; should end the "why aren't windows visible?" posts
- updated GUI code to match new phoenix changes
- phoenix: Layout and Widget inherit from Sizable; directional layouts
make no distinction between widgets and layouts
- phoenix: individual widgets / layout can maintain visible/hidden
status in spite of their parents' visibility
byuu says:
This release features many substantial Game Boy emulation improvements
(all courtesy of Jonas Quinn), a new audio DSP class, and BPS patching
support.
Changelog (since v081):
- added new DSP audio engine; supports sample-averaging for the Game
Boy's high frequency rate
- GB: MMM01 images with boot loader at bottom of ROM can now be loaded
- GB: EI is delayed one cycle; fixes Bubble Bobble [Jonas Quinn]
- GB: fixed window -7 offset behavior; fixes Contra 3 first boss [Jonas
Quinn]
- GB: disable LCD interrupts when rendering is off; fixes Super Mario
Land 2 [Jonas Quinn]
- GB: fixed noise channel LFSR; fixes Zelda: LA lightning sound [Jonas
Quinn]
- GB: square channels use initial_length like the noise channel [Jonas
Quinn]
- UI: added BPS patching support; removed UPS patching support
- UI: when loading BS-X/Sufami Turbo/Game Boy games; display game title
instead of BIOS title
- UI: modified timestamps on screenshots for Windows/NTFS (which
disallows use of ':')
byuu says:
- GB: square channels cache initial_length and invert the length value
on writes [Jonas Quinn]
- GB: updated LCD disable to just ignore interrupts and pixel writes,
fixes Contra
- BPS patch information and cartridge sections are now copied from the
patch metadata, if it is present
- fixed bpslinear out-of-bounds issue, which will be in snespurify v11
official [Danish]
- simplified Makefile again since command-line trumps manual assignments
byuu says:
- GameBoy: fixed window behavior for Contra 3 first boss [Jonas Quinn]
- GameBoy: fixed noise channel for Zelda: LA intro [Jonas Quinn]
- GameBoy: completely disable LCD when turned off, no interrupts; fixes
Super Mario Land 2 [thanks to Jonas Quinn]
- GameBoy: keep track of where pixels come from for OBJ priority mode
[Jonas Quinn]
- updated mode+slot-dependent name handling: simplifies Path class,
allows SGB/BSX/ST games to show the slot title (instead of BIOS name)
on the title bar
- Makefile allows command-line definitions for ui and profile now (make
profile=compatibility ui=ui-libsnes)
- Makefile now allows (make pgo=instrument) and (make pgo=optimize)
- added BPS patching support, removed UPS patching support
byuu says:
This release adds nall/dsp, which is a new framework for audio DSP
effects. It currently supports the usual fractional hermite resampling
and volume adjustments from ruby; but it also adds balance, and
arbitrary precision input and output (still limited to two channels, and
still signed audio [just subtract 1<<(bits-1) from an unsigned value.])
Internally, all samples are converted to doubles in the range of -1.0 to
+1.0, to allow for far greater precision with the hermite resampler and
volume/balance/etc adjustments.
As a result of this, all of the extra resampling/volume code from
ruby::audio has been removed. bsnes pulls in a copy of nall::dsp to
handle that stuff now.
byuu says:
- EI takes an extra cycle to raise IME; fixes Bubble Bobble [for the
Gameboy], and likely many more games [Jonas Quinn]
- nall/gameboy/cartridge.hpp descrambles MMM01 images (header can be at
top or bottom of image now)
- screenshot timestamps use filename-yyyy-mm-dd hh.mm.ss.bmp format; so
that they can save on Windows
- closing the emulator will switch to windowed mode first, so that
geometry is preserved
byuu says:
This release polishes up the GUI, adds some more features, and fixes
a few minor issues.
Changelog (since v080):
- rewrote S-DD1 module to decompress individual bytes at a time
- simplified SPC7110 deinterleaving code
- OBC1 should not clear RAM on reset [Jonas Quinn]
- fixed enum-cast compilation errors with the latest GCC 4.6.x releases
- added bsnes logo to about screen
- make phoenix=gtk will now build the GTK+ port on Linux
- added settings.startFullScreen to the config file for front-end users
- added advanced settings option to disable window compositor (only
works on Windows and Xfce)
- merged settings windows into the panel approach used by bsnes/Qt in
the past
- fixed a crashing bug on input settings window
- fixed GTK+ auto-geometry sizing
- added screenshot capture capability
- added exit emulator hotkey (defaults to being unmapped)
- Xorg keyboard polling now uses cached Display variable [Bisqwit]
- cheat code database updated [mightymo]
byuu says, in a post between the v080r07 release and the v080r08
release:
phoenix/Windows:
The slider and scrollbar setParent calls setLength+setPosition, but
setLength sets position = 0 (due to new length possibly invalidating
previous position.)
Cache position first to fix this, can now reparent widgets with proper
slider/scroll positions.
ListView had a workaround where the horizontal scrollbar was always
appearing on single-column lists. The workaround was forcing the config
settings list in bsnes to only select the text portions of each item in
the list, instead of the entire lines. The workaround was needed because
without setting a single header text, the header text count was equal to
zero, causing autoSizeColumns to have no effect. Made the constructor
call setHeaderText("") to guarantee size() >= 1 always. Removes the need
for the workaround, and gives a good file browser and configuration
setting window.
phoenix/Qt:
Worked around Qt bugs #258,674+258,675: if you click a list item with
your mouse, currentItem()->isSelected() returns false. It does not
return true until you select an item with a keyboard key. I forced it to
set the selected item upon currentItemChanged() message. It was also not
sending a changed message upon clearing the selection and then selecting
the same item again. I had to do something undocumented:
setCurrentItem(nullptr) so that currentItemChanged works again.
phoenix/All:
Fonts are now initialized to the platform default settings, Tahoma or
Sans 8-point. This lets geometry on widgets not attached to windows work
better. Makes the ../... buttons smaller pretty much everywhere.
byuu says, announcing the v080r08 release:
Fixed all of the above phoenix issues, and improved the auto-disabling
of buttons on the input setting and state manager windows.
Also manually initiailized lastConfigure for Valgrind in GTK+. Windows
and GTK+ ports look a lot nicer now.
byuu says:
- fixed a long-standing crash: when you have a device index above the
range permitted by another port, the app would crash (eg Controller
Port 2 -> Mouse, then switch to Hotkeys)
- Qt bug workaround: have to use currentItemChanged signal instead of
itemSelectionChanged signal for QTreeWidget, otherwise scrolling with
mouse gives you the previous item with currentItem() ...
- added support for toggling the Xfce compositor
- added support for detecting if the compositor is enabled in the first
place on Windows, so that it won't get turned on when you had it off
permanently
- added advanced setting to toggle behavior (never disable, disable only
in fullscreen mode, disable whenever emulator is open)
- worked around GTK+ ../... button height issue
- worked around Windows slider position issue when attaching to a new
window (need to research this one more)
- fixed up input settings window more: closing window ends assignment,
custom mapping buttons hidden by default
Some of those bugs have been there since the phoenix port began, good
times.
byuu says:
Ran out of time, so this is incomplete, but ...
Windows will disable the compositor in fullscreen mode, and enable it
when switching back to windowed mode. Should help with Vsync issues, but
of course only in fullscreen mode.
I've also merged the four settings windows back into a panel with a list
view (since I have no tab control widget.) The input settings window is
a bit incomplete, need to break assignment on window close, hide the
capture buttons on first showing, etc. Will probably try and finish that
up tonight.
byuu says:
Includes updated versions of nall and phoenix, which mostly improves the
GTK+ version. However, it appears to be crashing at the moment after
loading a game. Unfortunately it works when gdb is used, so I can't
easily debug it :/
You can now build with make phoenix=gtk if you want the GTK+ version on
Linux (the Qt version is leagues better even on Gnome, please use it if
at all possible.)
There's also settings.startFullScreen, config-file only, to allow for
front-end use. Forgot to add the reset/power hotkeys.
I also fixed compilation of ui-gameboy on GCC 4.6. I hope that's the
last switch(enum) error, those are damn annoying. Can't wait to switch
to GCC 4.6 on Windows.
byuu says:
Adds nall/inflate.hpp and nall/unzip.hpp. Updates nall/resource.hpp to
encode and decode using ZIP/deflate files, rather than a much simpler
(and less powerful) LZSS implementation. Cuts the bsnes-logo.hpp file
from 270KB to 130KB, and the binary overhead from 80KB to 35KB.
byuu says:
Wow, nothing in 19 days. Anyway, I wanted to get Nick's logo back in on
the about screen. Adds 80kb to both the binary and source archive, but
eh. Gotta have some style. Nothing else new.
byuu says:
- added qstrlower and qstrupper; mainly for the sake of others wanting
to patch bass
- added: string sha256(const uint8_t *data, unsigned size); for easier
hash generation
- cleaned up the NEC DSP and Hitachi DSP XML mapping code; they are
consistent now as well
- "necdsp" in paths.cfg is now "firmware", since it also affects the
Hitachi DSP
- XML mapping was using program= for DSP-n/ST-001n and data= for Cx4;
they both use firmware= now instead
- fixed icd2/interface casting issue for GCC 4.6.0 (thanks for the
reminder, vEX)
- removed the last parts of code that used string << foo; and removed
that from nall/string entirely
- I need to do this for the debugger as well, I'll make sure that it
compiles before v081 though
- converted all string(...) syntax to { ... } syntax that I could
(obviously it won't cast to a function that takes const char* instead
of const string&)
Probably some other tiny things. Just basic maintenance here.
byuu says:
There was one unfortunate aspect of the S-DD1 module: you had to give it
the DMA length and a target buffer, and it would do the entire
decompression at once. Real hardware would work by streaming the data
byte by byte. So with that, I went ahead and rewrote the code to handle
byte-based streaming.
This WIP is an important milestone for me personally. Up until now,
bsnes has always had code that was directly copy-pasted from other
authors. With all of the DSP and Cx4 chips rewritten in LLE, and the
SPC7110 algorithm already ported over from C, and archive decompression
code removed for a long time, the S-DD1 was the only module left like
this. It's obviously not that big of a deal. The code is basically still
a copy of the original. S-DD1 decomp from Andreas Naive, SPC7110 decomp
from neviksti, and S-DSP from blargg. And the rest of the emulator is of
course only possible because of code and research before it, although
everything else has no resemblance at all to code before it. The main
advantage, really, is absolute code consistency. I always use the same
variant of K&R, for instance. I dunno, I guess I just never really liked
the "Build-a-Bear Workshop" style of emulators, like is so prominent in
the Genesis scene: "My new Genesis emu (uses Starscream/Musashi 68K
core, Marat Fayzullin's Z80 core, YM2612 core from Game_Music_Emu, VDP
core from Gens, SVP core from picodrive)", sorry, but you wrote
a front-end, not an emulator :/
I also updated the SPC7110 decompression module: I merged the class
inside the SPC7110 class (not sure why it was separate before), and
replaced the morton lookup tables with for-loops. The morton tables were
added to be a tiny bit faster when I was more interested in speed than
code clarity. It may be a tiny bit slower (or faster due to less L2
cache usage), but you won't even notice an FPS drop, and it cuts out
a good chunk of code and some tables. Lastly, I added pinput_poll() to
video_refresh(). Forgot to remove Interface::input_poll() from the C++
side, will have to do that later.
byuu says:
This release adds low-level emulation of the Hitachi HG51B169 DSP, which
was used in Mega Man X2 and Mega Man X3 as the Cx4 chip. It also fixes
a regression in both the sound core and cheat engine.
You will now need the HG51B169 data ROM to play MMX2/MMX3.
Once again, Cx4 LLE could not have been possible without the help of Dr.
Decapitator, Jonas Quinn, Overload and Segher. Be sure to thank them,
please!
Changelog:
* added Cx4 low-level emulation; removed Cx4 high-level emulation code
* fixed S-SMP synchronization to S-CPU on CPUIO writes
* controllers now have their own threads and classes
* serial controller is now emulated as an actual controller, rather than
as a coprocessor
* added link coprocessor module for special chip research and homebrew
* fixed cheat codes that target mask ROM addresses [Cydrak]
* fixed compilation error with the latest GCC 4.6.0 beta releases
* added flexibility to XML memory mapping file format
* updated to mightymo's latest cheat pack (2011-06-20)
byuu says:
It does add some more code to the CPU::step() function, so performance
probably went down actually, by about 1%. Removing the input.tick() call
didn't compensate as much as I'd hoped.
Hooked up Super Scope and Justifier support. The good news is that the
Justifier alignment doesn't get fucked up anymore when you go
off-screen. Never could fix that in the old version.
The bad news is that it takes a major speed hit for the time being.
I need to figure out how to run the CPU and input threads out of order.
Every time I try, the input gets thrown off by most of a scanline.
Right now, I'm forced to sync constantly to get the latching position
really accurate. But worst case, I can cut the syncs down by skipping
large chunks around the cursor position, +/-40 clock cycles. So it's
only temporarily slow.
Lastly, killed the old Input class, merged Controllers class into it.
I actually like Controllers as a name better, but it doesn't jive with
video/audio/input, so oh well.
byuu says:
- Fixed GCC-4.6 casting errors in ui/input/input.cpp.
- Fixed some of the opcode mnemonics specified in the HG51B169 core (was
unable to speed up the code)
- Started on a new core input system: snes/controller. More on that
here:
http://board.byuu.org/viewtopic.php?f=16&t=1761
- Have not yet attempted to add threading support to the controllers, so
serial is still there as a coprocessor.
- I'm going to move the Controllers {} class back to Input {} once all
individual controllers have been ported over.
Note: Super Scope and Justifier do not have counter latching support
yet, so you can't really use them. The gamepad, multitap and mouse all
work great; and the SS/Justifier cursors work at least. I also colored
the SS cursor red, so that all three (SS, Justifier, chained secondary
Justifier) all have unique R/G/B colors now. Should prevent confusion
between the SS and one Justifier.
byuu says:
Back from vacation. We were successful in emulating the Cx4 using LLE
during my vacation. We finished on June 15th. And now that I'm back,
I've rewritten the code and merged it into bsnes official. With that,
the very last HLE emulation code in bsnes has now been purged.
[...]
The emulation is as minimal as possible. If I don't see an opcode or
feature actually used, I don't implement it. The one exception being
that I do support the vector override functionality. And there are also
dummy handlers for ld ?,$2e + loop, so that the chip won't stall out.
But things like "byte 4" on rdram/wrram, the two-bit destination
selections for all but ld, etc are treated as invalid opcodes, since we
aren't 100% sure if they are there and work as we hypothesize. I also
only map in known registers into the 256-entry register list. This
leaves 90% of the map empty.
The chip runs at 20MHz, and it will disable the ROM while running. DMA
does transfer one byte at a time against the clock and also locks out
the ROM. rdbus won't fetch from IRAM, only from ROM. DMA transfer only
reads from ROM, and only writes to RAM. Unless someone verifies that
they can do more, I'll leave it that way. I don't yet actually buffer
the program ROM into the internal program RAM just yet, but that is on
the to-do list. We aren't entirely sure how that works either, but my
plan is to just lock the Cx4 CPU and load in 512-bytes.
There's still a few unknown registers in $7f40-5f that I don't do
anything with yet. The secondary chip disable is going to be the
weirdest one, since MMX3 only has one chip. I'd really rather not have
to specify the ROM mapping as two separate chips on MMX2 and as one on
MMX3 just to support this, so I don't know yet.
Save state support is of course there already.
Speed hit is 118fps HLE -> 109fps LLE in most scenes. Not bad, honestly.
byuu says:
This fixes the S-SMP synchronization on CPUIO writes that was broken by
improvements in v078.01. Terranigma will work now. Also adds the 'link'
coprocessor module that was added in v079.01, and improved in v079.02.
byuu says:
Added "unsigned link_run();" which acts as its own thread synchronized
against the S-CPU. Specify the frequency in the configuration file.
I intend to prototype the Cx4 LLE openly using the link module, and that
required timing support, so there we go.
It's very basic, and it synchronizes the CPU to the coprocessors and
vice versa after every call to link_run(). Meaning performance won't be
super exceptional at full 21MHz or higher, but then this is for
prototyping only. I didn't want to expose cothreading, yielding, calls
back into bsnes' core, calls to sync up the S-CPU, etc.
This version adds a "link" SNES coprocessor module, which just loads
a shared library. It was posted outside the v079 WIP thread, in this
thread:
http://board.byuu.org/viewtopic.php?f=16&t=1700
byuu says:
This release includes Nintendo Super System DIP switch emulation and
improved PPU rendering accuracy, among other things.
Changelog:
- added Nintendo Super System DIP switch emulation [requires XML setting
maps]
- emulated Super Game Boy $6001 VRAM offset selection port [ikari_01]
- fixed randomness initialization of S-SMP port registers [fixes
DBZ:Hyper Dimension and Ninja Warriors]
- mosaic V-countdown caches BGOFS registers (fixes Super Turrican
2 effect) [reported by zal16]
- non-mosaic BGOFS registers are always cached at H=60 (fixes NHL '94
and Super Mario World flickering)
- fixed 2xSaI family of renderers on 64-bit systems
- cleaned up SMP source code
- phoenix: fixed a bug when closing bsnes while minimized
Please note that the mosaic BGOFS fix is only for the accuracy profile.
Unfortunately the older scanline-based compatibility renderer's code is
nearly unmaintainable at this point, so I haven't yet been able to
backport the fixes.
Also, I have written a new cycle-accurate SMP core that does not use
libco. The aim is to implement it into Snes9X v1.54. But it would of
course be prudent to test the new core first.
[...then in the next post...]
Decided to keep that Super Mario World part a surprise, so ... surprise!
Realized while working on the Super Turrican 2 mosaic fix, and from
looking at NHL '94 and Dai Kaijuu Monogatari 2's behavior, that BGOFS
registers must be cached between H=0 and H=88 for the entire scanline
... they can't work otherwise, and it'd be stupid for the PPU to re-add
the offset to the position on every pixel anyway. I chose H=60 for now.
Once I am set up with the RGB monitor and the North American cartridge
dumping is completed, I'll set it on getting exact timings for all these
things. It'll probably require a smallish speed hit to allow exact-cycle
timing events for everything in the PPU.
byuu says:
Would appreciate testing on any games with mosaic, especially Mode7
mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES
Test Program.
This only applies to BG modes 0-6, and technically should not affect
Mode7 at all. I am not sure if Mode7 needs the same change made or not,
but given the way it fetches that could prove quite challenging. I also
simplified the background renderer a good bit. See eg the pixel copy
stuff in Background::run().
I've only fixed this in the accuracy renderer. I'm sorry, but the
compatibility renderer is a fucking mess. I haven't really touched it in
four or five years now.
Will probably just revert to the accuracy/SMP in the performance profile
for the next release since it's not being used otherwise. People can
toggle it on if they want to try it out.
byuu says:
This adds ikari_01's emulation of the ICD2 (Super Game Boy) $6001 register.
It basically removes a really ugly hack where I was intercepting the DMA
transfer destination address to determine while Game Boy tile row to
transfer. This should make implementing SGB emulation in other
emulators easier, as said hooks were very emulator-specific.
byuu says:
This WIP adds Nintendo Super System emulation, at least of its DIP
switches. This is done via XML mapping, like so:
<?xml version="1.0" encoding="UTF-8"?>
<cartridge region="NTSC">
<name>ActRaiser</name>
<rom>
<map mode="linear" address="00-7f:8000-ffff"/>
<map mode="linear" address="80-ff:8000-ffff"/>
</rom>
<nss>
<setting name="Difficulty">
<option value="0000" name="Easy"/>
<option value="0001" name="Normal"/>
<option value="0002" name="Hard"/>
<option value="0003" name="Expert"/>
</setting>
<setting name="Lives">
<option value="0000" name="5 lives"/>
<option value="0004" name="4 lives"/>
<option value="0008" name="3 lives"/>
<option value="000c" name="2 lives"/>
</setting>
</nss>
</cartridge>
The value field is a 16-bit value. All selected options are ORed
together to produce the final DIP switch values. The number of options
per setting is unlimited, but there are only sixteen settings allowed
(you can't have more settings than you have switches, that's just
stupid.)
In the example above, d0-d1 controls difficulty, and d2-d3 controls # of
lives. d4-d15 appear to be unused, as far as I can tell.
byuu says:
Changelog:
- file and slot load dialogs should now have perfectly square buttons
that are based on the platform's default button height.
- cleaned up bsnes/Accuracy SMP source code (removed old !! stuff, stage
3 timer is now uint4, memory access switch/case cleaned up,
sSMPTimer->Timer, etc.)
- cleaned up bsnes/Accuracy memory access functions (read/writestack ->
read/writesp, read/writeaddr -> read/write)
- minor optimization to bsnes/Performance SMP core in cycle-mode
byuu says:
I apparently wasted two days writing that SMP core for nothing. I had
a perfectly well-written and well-tested core in bsnes v045. The old
opcode.b files that were a cycle-based markup language.
So I took that core, and wrote new parsers to generate both opcode-based
(one switch) and cycle-based (two switch) cores. Throw in a
little #define magic around CYCLE_ACCURATE, and it is compile-time
toggleable.
EWJ2's bug was due to not resetting the timer variables, and Bahamut
Lagoon's was due to dividing timer frequencies by 3, but failing to
remove the 0->1 transition phase (should have done the latter and
divided by two.)
Anyway, all fixed up.
byuu says:
New S-SMP core is feature-complete, but still buggy. It's good enough
for perfect audio in Zelda 3 and Super Mario World, but there are plenty
of issues. No audio in Bahamut Lagoon, deadlock in Earthworm Jim 2,
etc.
With this core, bsnes/Performance runs about 3-5% faster than with the
old one. That won't seem like much, because the S-SMP is the least
demanding portion of the SNES. blargg's SMP core netted me a 5-8%
speedup the last time I tried it, so I'm sure there's still room to
speed things up.
The core is opcode-based, but has dummy op_io() calls (they compile to
nothing), so it is trivial to make it cycle-based if desired. I'm not
convinced that is necessary, but we shall see once we get the opcode
bugs ironed out.
byuu says:
Started on a new SMP core for bsnes/Performance. I wanted to start
clean, and only copied over the debugger+disassembler portions from the
existing version. I figured that if I took the existing one and tried
trimming it down, that it'd end up with too much old baggage. But so
far, the opcodes are looking mostly the same anyway, only I'm
using #defines and a switch table in place of the template function
trickery.
I have enough written now that I can run Zelda 3 at least (although it
gets stuck in a loop immediately after.) No real point in comparing
speed yet, because it'll definitely go down as it becomes more complete.
byuu says:
Finally, a new release. I have been very busy finishing up SNES box,
cartridge and PCB scanning plus cataloguing the data, however this
release still has some significant improvements.
Most notably would be randomization on startup. This will help match the
behavior of real hardware and uninitialized memory + registers. It
should help catch homebrew software that forgets to initialize things
properly. Of course, I was not able to test the complete library, so it
is possible that if I've randomized anything that should be constant,
that this could cause a regression. You can disable this randomization
for netplay or to work around any incompatibilities by editing bsnes.cfg
and setting snes.random to false.
The GUI also received some updates. Widget sizes are now computed based
on font sizes, giving it a perfectly native look (because it is native.)
I've also added a hotkey remapping screen to the input settings. Not
only can you remap inputs to controllers now, but those who did not know
the hotkey bindings can now quickly see which ones exist and what they
are mapped to.
Changelog (since v077):
- memory and most registers are now randomly initialized on power-up
- fixed auto joypad polling issue in Super Star Wars
- fixed .nec and .rtc file extensions (they were missing the dot) [krom]
- PPU/accuracy now clears overscan region on any frame when it is
disabled
- PPU/compatibility no longer auto-blends hires pixels (use NTSC filter
for this)
- added hotkey remapping dialog to input settings window
- added a few new hotkeys, including quick-reset
- phoenix API now auto-sizes widgets based on font sizes
- file dialog once again remembers previously selected file when
possible
byuu says:
Changelog:
- fixed .nec and both .rtc file extensions (thanks krom)
- randomized most S-PPU registers, should trip up some broken homebrew
that does not initialize all registers
- randomization is now seeded with time(0) rather than 'byuu'
- SNES::interface.video_refresh() now always receives
{256,512}x{240,480}
- PPU/accuracy scanline 0 does not render the screen back color anymore,
fixes strange coloring look on first scanline in PAL TV mode in
non-overscan games
- disabled hires blending in PPU/compatibility; all three cores act the
same now
byuu says:
Changelog:
- setGeometry is called after append(layout) now. This fixes the window
sizing on Qt.
- removed enum Style {} code, as it's no longer necessary.
- removed Filter, Shader path selection code from the file load dialog,
since that is menu-driven now.
- improved the file load dialog to remember last selected file when mode
doesn't change (had to split a switch statement into two switches.)
- added Hotkeys port onto input settings window, allowing one to
dynamically see and remap GUI shortcuts
- added power cycle / reset shortcuts
Still very minimal with the hotkeys, so I packed them all into one group
for now. A few more I'd like to add, but I don't want to get ridiculous
like with the Qt GUI.
byuu says:
Fixed up the geometry calculation code. There is now minimumGeometry()
[returns minimum size needed to display a layout, treats MaximumSize as
MinimumSize], and minimumLayoutGeometry() [like minimumGeometry(), but
it will return MaximumSize if a single container item has that
attribute. Used mostly internally for layout sizing.]
It looks great on Windows, but it looks visually off on Qt. Not exactly
sure what's up there. When I make a test application, everything looks
great. Going to have to clone a bsnes window that's having a problem (eg
bsnes main debugger checkbox window), and see what's up.
byuu says:
Wouldn't recommend using this, but it has bsnes ported to the new auto-size calculating phoenix API.
Known issues:
- minimumWidth/Height on layouts isn't working right, windows that use
it are usually too small
- Windows gives 0,0 size for empty text string sizes, which messes up
a lot of default sizes for LineEdit controls
byuu says:
Changelog:
- fixed auto joypad polling bug (fixes Super Star Wars start button
input)
- added pseudo-random class; so far it is RAM only [WRAM, APURAM, VRAM,
OAM, CGRAM]
- added new system configuration options to bsnes.cfg
The pseudo-random class is optional. For right now, I am defaulting it
to enabled. bsnes.cfg::snes.random = true.
You can of course turn it off if you want. This will break Death Brade
and Unnamed Euro Racer, no questions about it.
So I don't know if I want to leave this on or off by default. Leaving it
on will thwart emulator detection code and help to keep code that relies
on uninitialized memory from working, but leaving it off will increase
compatibility.
byuu says:
Changelog (since v076):
- video filters and shaders now populate inside main menu; no longer
have to select them as files
- fixed 2xSaI, Super 2xSaI and Super Eagle on 32-bit platforms; still
buggy on 64-bit Windows
- fixed linear mirroring issues (fixes Mega Man X dash bug)
- fixed RAM memory mapping bug in Sufami Turbo games
- home folder is now %APPDATA%/bsnes or ~/.config/bsnes
- added paths.cfg file, which will allow you to specify custom paths for
any file types
- save states and cheat files for multi-slot games are based on slot
names instead of BIOS names
- fixed compilation warning on OS X with nall::decimal
- fixed calculation bug in nall::fp
- Makefile now has options variable, example: make options=debugger
- configuration files and cheat database can now reside in the same
folder as the binary itself
- updated to 2011-03-11 release of mightymo's cheat database
byuu says:
Rather than make the libsnes API incompatible with previous versions,
I just implemented path as return { basename, hint };
So you will still use the set basename function already there as before.
So either DSP/MSU1/Serial all go in the ROM folder, or they all go
somewhere else. You can be fancy and detect the gametype and override
the basename as you like, if you really want.
Bumped the API to 1.3, and added const char* snes_library_id(void); it
will return "bsnes v076.07" at the moment. The internal string is
static, but don't try caching it or modifying it anyway. You'll have to
split the name and version yourself if you want them separately. API is
backward-compatible to 1.0 still.
Also improved string::assign and string::append to take a variadic
number of arguments. To make this happen, I had to make to_string return
const char* so that infinite recursion did not happen.
byuu says:
Changelog:
- path code finished for ui/, just need to expose for ui-libsnes/ now
- filters and shaders use radio items now, so you know which is active
- smooth video was placed inside video mode (list is getting too long)
- .bsnes -> .config/bsnes in make install
- pixelshaders -> snesshader, added Makefile with make install target
- snesfilter, added Makefile with make install and make clean targets
- maybe other stuff
byuu says:
Changelog:
- QMenu::setVisible() does nothing, have to use
QMenu::menuAction::setVisible()
- improved path system, especially for ST games (states will be
/path/to/slotA+notdir(slotB).ext, saves are per-game and per-path)
- paths are now valid when you load just the BS-X/ST/SGB BIOSes with no
carts inserted; maybe useful for BS-X I guess
- removed video filter and pixel shader code from video settings dialog
- added Settings->Video Filter and Settings->Video Shader menu lists
- fixed the SaI family of filters in lores-mode only; although I don't
really know how or why the change fixed them, the code is too vague
The menu list for the video filters and shaders are populated from
either base/filters and base/shaders, or user/.config/bsnes/filters and
user/.config/bsnes/shaders. It tries the first, and if it does not find
anything it tries the second, just like the configuration files.
That meant doing away with multiple folders for the shaders, so now the
shaders have a suffix to indicate what driver uses them, eg
"Curvature.OpenGL.shader" and "Sepia.Direct3D.shader" -- probably nicer
to use GLSL/HLSL, but using the driver name lets me sub in the currently
loaded video driver with no special casing. So the filter if you have eg
OpenGL loaded is "*.OpenGL.shader"; and for SDL you get "*.SDL.shader",
which will obviously not be there as the non-GL-based SDL driver doesn't
support shaders.
If there are no filters or no shaders available, the menu options do not
show up. The lists are not radio items with active item ticked states
just yet, but they will be.
byuu says:
Changelog:
- fixed Sufami Turbo ROM and RAM mapping bugs
- more paths work, definitely need to clean up parameter names and enum
typenames now
I had to cheat just a bit on the ST SRAM. For now, I am specifying the
RAM size in the XML file.
The base XML isn't supposed to know about the slots though. What I need
to do is write an ST header parser to get actual RAM sizes, and then
from there generate an ST-specific XML file (like I do for the Game Boy)
to specify this info. Would also be nice for some BS-X info.
Added NECDSP, MSU1 and Serial paths. This eliminates
SNES::Cartridge::basename.
byuu says:
Changelog:
- paths.cfg work completed
- save states/archives and cheat files for multi-slot games are more
intelligent now
For paths.cfg, there are three types of entries. Each have different
special prefixes.
Folder paths: sfc, bs, st, gb, filter, shader
By default, bsnes will remember the last path you loaded a file of said
type from. It will be prefixed with "recent/" in the file. Specify an
explicit hard-coded path to override this.
BIOS paths: satellaviewBios, sufamiTurboBios, superGameBoyBios
Remembers an explicit hard-coded path to the BIOS you selected last.
I was thinking that a nice feature would be for the "Load Special"
windows to pop open the slot A load dialog if a BIOS was selected.
Select a game from this popup and it loads directly, cancel it to get
the regular window to override the BIOS.
Save paths: srm, rtc, bsa, bst, cht, log
Paths to write various files that the emulator generates. Note: srm
groups bsp, bss and sav for now. Was being lazy.
There are four special prefixes for these:
"base/" -- gets replaced with the executable path
"user/" -- gets replaced with the same folder where bsnes.cfg goes
(%APPDATA%/bsnes or ~/.config/bsnes) -- good for hiding
files
"./" -- gets replaced with the current ROM path
"../" -- gets replaced with the folder above the current ROM path
If you want to go up two folders or more, then use a hard-coded path. If
that's not good enough, kill yourself because God hates you.
byuu says:
Changelog:
- fixed a crashing bug when you toggle a cheat code and then load a save state
- added paths.cfg
- bsnes now remembers the most recent path per file-type, like bsnes/Qt
used to do
- re-added -s to Linux linker flags
- fixed crash with libsnes/SGB XML parsing
byuu says:
Changelog:
- fixed linear mirroring issue in memory map (fixes dash in Mega Man X)
- home path for Windows is now %APPDATA%/bsnes (not %APPDATA%/.bsnes)
- home path for OS X and Linux is now ~/.config/bsnes (not ~/.bsnes)
- bsnes-geometry.cfg is now geometry.cfg; and it stores width,height
- I do not yet restore width, height; because the GTK+ and Qt APIs treat window
resize as implying setMinimumSize
- added bsnes/ui/path; which I have some significant plans for
- fixed a bug in realpath (specified path is not always a folder, so we should
not always append / as with userpath)
- bsnes.cfg, geometry.cfg and cheats.xml may now optionally exist in the same
folder as the binary itself
- ruby only imports the nall namespace after including system headers (should
fix OS X 'decimal' issue)
- nall::fp now uses atof (fixes nall::fp("0.05"))
- I split the CheatDatabase to a separate cheat-database.cpp file; it was
pretty ugly packed into cheat-editor.cpp
- Makefile now has "options := " line; where you can add "debugger" if you
like, and in the future maybe more options
- also works via command-line: make options=debugger
byuu says:
Most notable in this release is that sound support has been added to my
own Super Game Boy emulation. The GUI toolkit, phoenix, has also
received a complete rewrite; with the most visible change there being
that windows are now resizable.
Changelog (since v075):
* added sound emulation to Game Boy core
* fixed Super Game Boy save state
* support added HexEdit widget to Windows and Qt targets; debugger can
now be compiled on all platforms
* entering fullscreen now auto-hides mouse; and mouse capture is toggled
otherwise by F12 key
* fullscreen command and geometry caching works much better on GTK+ and
Qt targets
* phoenix rewritten from scratch; now supports resizable layout
containers
* phoenix/Windows no longer relies on buggy SetParent API to reparent
widgets
byuu says:
This has my latest API enhancements, but there are some known issues:
- resize on Windows seems to not repaint the buttons properly in rare
cases. I may just need to revert to flickering resize.
- GTK+ reports the wrong menu height, off by two pixels, prior to the
window being realized (made visible)
- this results in the main window moving up two pixels after each run
of bsnes
The menu height bug was actually there previously, it was just that Qt
and GTK+ were computing the frame margins incorrectly (ignoring the menu
bar) before.
On the bright side, ui/settings/input.cpp has been improved by way of
the new multi-layout support. The window is no longer forced to an
awkward 640 pixels wide, as the mouse axes/buttons can overlap now. The
code is also simpler since I am using the Layout::setVisible command to
toggle groups on and off instead of doing it for each and every control.
byuu says (in the thread about rewriting Phoenix):
- added phoenix/reference; a dummy implementation that contains the 22KB
of static boilerplate code needed to start a new target
- OS::setDefaultFont removed; problem is that objects in the global
scope are constructed before you can call that function
- added Window::setWidgetFont, which is applied if your widgets have no
custom font set already upon attaching them to the window with
Window::setLayout, more understandable behavior
- renamed ListBox to ListView
byuu says (in the v075 WIP thread):
Found the source of lag on cartridge load. ListView::modify() was not
locking Qt messages, so it was causing a CheatEditor::refresh (copies
16MB of memory each call) for all 128 cheat items.
Final issue now is that nested submenus (menus inside of menus) are not
applying Window::setMenuFont yet.
byuu says:
phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues:
1: font sizes of menu items are wrong, I can fix this easily enough
2: there's some sort of multi-second lag when loading games, not sure
what's happening there yet
The new phoenix isn't exactly complete yet, still making some key
changes, and then I'll start on phoenix/Windows and phoenix/GTK+.
The most noticeable difference is that you don't have to give all of the
header paths and PHOENIX_PLATFORM defines when compiling individual GUI
object files. It's only needed for phoenix.cpp itself. The overall
structure of the phoenix source folder is much saner as well for
sync.sh.
I'm really surprised things are working as well as they are for
a two-day power rewrite of an entire phoenix target. The other targets
won't be as bad insofar as the core stuff is completed this time. And
thank god for that, I was about ready to kill myself after writing
dozens of lines like this:
HorizontalSlider::HorizontalSlider() : state(*new State),
base_from_member<pHorizontalSlider&>(*new pHorizontalSlider(*this)),
Widget(base_from_member<pHorizontalSlider&>::value),
p(base_from_member<pHorizontalSlider&>::value) {}
But each platform does have some new, unique problems. phoenix/GTK+ was
acting screwy prior to the rewrite, and will most likely still have
issues. Even more important, one of the major points of this rewrite was
having the new phoenix/core cache widget settings/data, so that I can
destroy and recreate widgets rather than relying on SetParent. This
means that simple copying of the old phoenix/Windows won't work, and
this new method is significantly more involved.
byuu says:
Rewrote the way menus are attached, they act like layouts/widgets now.
All three phoenix targets once again work with both radio menu items and
radio widgets. Both GTK+ and Qt have built-in group controls right
inside the widgets, so I don't have to keep my own groups around
anymore. They do act screwy at widget creation though, have to jump
through some hoops to get it to work right. All I can say is, definitely
set all child widgets to the parent before trying to check any of them.
My long-term goal for the main window is to honor the fullscreen video
setting as a generic setting, and let the window scale auto-fit the best
possible size that matches your scale preference into the output window,
centered just like fullscreen. For now, I've just set it to a fixed
window size until I finish working on phoenix. The scale X settings will
just be to snap the window to an exact size in case you don't want any
black borders, they won't be radio items and the bsnes-geometry.cfg file
will save width/height information as well.
Simplified the sizing requirements for creating layouts and updated all
bsnes windows to support the new system. Layouts also expose their
minimum width/height values, which I use to create perfectly sized
windows on all three platforms. This will fix cut-off heights on the
last Windows WIP. Qt is being annoying though and forcing a minimum
window size of 300,100 despite me telling it to use a smaller window
size. Always have to fight with Qt, I swear to god.
byuu says:
phoenix/Windows and phoenix/Qt are mostly fully operational now. All
platforms support dynamic layout resizing. I tried WM_GETMINMAXINFO
(thanks, OV2), but it was acting kind of choppy on resize, and it would
get confused and go crazy if you snapped one direction to the minimum
height but not another, so for now I'm leaving it off.
phoenix/GTK+ will be missing some functionality in regards to window
geometry. The other two have a more coherent strategy now: geometry() is
the client area, and setGeometry moves the client area to where you ask
for. This makes truly centering your client area trivial.
frameGeometry() includes the borders, menu and status. There is no
setFrameGeometry(), not sure if I really even want that, but it could be
useful so who knows. All targets also support non-resizable windows.
X11 is of course horrendously poor with frame sizes, Qt and GTK+ don't
even pretend to simulate them, so they say the frame is 0x0 pixels in
size until your widget is fully realized and visible to the end user. So
for now, to get window positioning right, I have to wait until the
window appears and then reposition the window again, causing a slight
jump. My plan is to build some persistent caching support directly into
phoenix. From here, I can just have the window snap the very first time
you run your very first phoenix app. I'll then determine the frame size
information, and use that to create future windows. Once they spawn,
I'll recheck and update the frame size info in case it has changed (eg
user changed themes.) Saving settings into .config/phoenix will allow me
to avoid having to snap the window every time on first startup. If the
config file is missing or unwritable, too bad, happens every time then.
I'm thinking about renaming onResize to onSize, and getting rid of
Window::create(). Rather make it spawn like every other control in its
constructor.
byuu says:
Ported phoenix/Windows and phoenix/GTK+ over to the new system. There
are some problems that need to be addressed:
- Windows ComboBox height setting needs widget creation height to
properly scale itself (make Widget::setGeometry virtual and override
ComboBox::setGeometry)
- Windows Canvas is completely broken
- GTK+ Canvas is slow as shit compared to Qt Canvas, probably nothing
I can do about it, have to do a very costly conversion because GTK+ is
stupid and uses BGR like Nintendo
- GTK+ listboxes are fucking insanely complicated to set up. Currently
I just split the second-half of creation to the setHeaderText call,
but when you don't call that, things explode
- I'm probably going to have to completely destroy and recreate
listboxes when changing the header text / column count
- Qt resize code is still impossible to get right, it's not letting me
size a window > 2/3rds of the screen size (it's in their docs)
- I swear, Qt is the most painful API in the world to move/size
windows with
- now that Window is separate, it really needs geometry() and
frameGeometry() as the two are quite different
- I need a way to toggle window resizability for fixed layouts, Qt is
once again going to be a nightmare as it lacks a way to do this other
than fixed layouts
- GTK+ currently explodes on bsnes, millions of console messages,
wonderful
- plenty more I'm forgetting
One bit of really cool/good news though: I made
Fixed/Horizontal/Vertical layouts external to phoenix itself. The code
is included for all targets so that it's always there and compiled into
one object, but the great news is that you can easily write your own
layout widgets and they'll work on all toolkits instantly.
That resize issue with bsnes was so simple it's annoying: my FixedLayout
container was repositioning on geometry updates. Made it only do it once
at creation like it should.
bsnes now has a fancy resize, grow the window and get black borders,
shrink it and the video shrinks with it. I plan to make it fancier with
constraint settings (center, scale, stretch). Basically I want to turn
the fullscreen setting into a general setting that also applies to
windowed scaling. I will probably turn the video scale X sizes into
regular items instead of radio boxes, so you can easily reset to a fixed
size whenever you want. Update bsnes to remember width,height geometry
as well and it should be quite nice.
byuu says:
Eleven hours of work. Window is now a base type (inherits from Object,
not Widget), same for Layout. FixedLayout still inherits from Layout.
Added HorizontalLayout and VerticalLayout types, that can append each
other to themselves to create box layouts. Layout margins are supported,
spacing is specified inline (I find this a much better way to fine-grain
spacing than Qt's single setSpacing function), and alignment is handled
strictly via padding widgets (insert a zero-sized label and it will
automatically grow to consume all extra space.)
Overall, my box packing model is slightly less powerful than Qt's, but
it is a good deal simpler and and easier to use in 90% of cases. The one
limitation I hit was with my input settings window, I'm not currently
able to embed two different layouts and toggle one on and the other off
to show only either { mouse x-axis, y-axis } or { mouse left, middle,
right }, so they instead just space out differently and I had to grow
the input window width a bit to compensate.
Resizing works great, pretty cool seeing that this is the first time
I've ever written my own resizer. I had to fight with Qt for several
hours to the point of potentially developing an aneurysm, but I finally
got it to properly handle geometry and sizing stuff. Some weird issue
with the bsnes viewport widget, I tell it to resize and for some reason
it doesn't. Cheap hack, I just make it constantly resize every video
refresh and it eventually takes. Wish I knew what was up with that.
All of bsnes now uses dynamic layouts sans the main window, so you can
resize them however you like.
This is still all Qt-only, I'm afraid. The other two ports are
in-progress.
byuu says:
This has the phoenix changes applied. Instead of widgets attaching
directly to windows, you now attach them to layouts, which can then be
attached to windows. Layouts are widgets themselves, so adding layouts
to layouts is trivial. It also allows for multi-widget show/hide, etc.
Right now there is only FixedLayout, but of course the plan is to
support a BoxLayout, that lets you add HorizontalLayout and
VerticalLayout containers to it, thus enabling auto-resize and simpler
form layout.
So far only phoenix/Qt is 100% moved over. phoenix/GTK+ has about 1/3rd
ported, and phoenix/Windows only has one control ported over as
a proof-of-concept.
On the user side, bsnes, bgameboy, snespurify and curse have been moved
to this new layout system. All of bsnes works great with it, as far as
I can tell. Fullscreen, debugger, etc are good.
byuu says:
Removed the floating-point volume adjustments from the wave channel and
the left/right speaker mixers. Also, against my better judgment I'm
backing out of left/right computation when they are both turned off.
This basically makes non-stereo games run faster, but will make stereo
games appear to run slower. I don't like it when end-users experience
mystery slowdowns.
Anyway, it appears that the audio calculation is really fucking
demanding. Knocks FPS from 800 down to 300. I thought it might be libco,
so I took it out and it only went up to 305fps o.O
There is also some sort of problem with bsnes/Super Game Boy audio. The
latency is really great when you first start, but it seems to drift
apart over time until it is well over 500ms, and then it either pops or
fades back to very low, sub-50ms latency again. The way I handle mixing
is that the coprocessor audio samples go into a resampler to the native
SNES rate, and fed to an output buffer. SNES audio samples go there
untouched. When there is a sample in each, I add them together and
average the result (I still don't understand why we divide by two since
these are signed integers), and output it immediately. It's just-in-time
sampling, so as long as DSP v Coprocessor do not drift very far, it
should have very low latency. And I make the CPU sync DSP and
Coprocessor once per scanline, which is something like 15 samples or so.
byuu says:
Added Game Boy sound emulation, all four channels.
It's really, really, really bad. Plenty of bugs, I don't even know what
the fuck a high-pass filter is so that isn't there. Hermite resampling
from 4MHz down to 44KHz. But it's tolerable.
I don't understand what sweep is for at all, and I'm sure I have that
insane recursive reload behavior wrong.
This is pretty much my own design. I referenced blargg's gb snd emu,
blargg's older gb apu ref, Cydrak's APU core, that lousy gbdev wiki
article, the completely and utterly worthless pandocs, and received
nothing but bad and wrong information that just wasted my time from
But I managed to pull it off. It's also painfully slow, like 250fps on
my machine slow. Countless optimizations are possible.
byuu says:
Changelog:
- hooked up everything necessary for Game Boy sound emulation ...
- bgameboy and bsnes/SGB input 4MHz frequency, and output 44.1KHz
frequency (produces soft static for now, to verify it is working)
- rewrote all of gameboy/apu, it now has a 4MHz worker thread, and
separate classes/folders for each channel+master, and serializes
So it's basically all I can do without actual emulation code or
human-readable documentation/example code.
byuu says:
Changelog:
- added full HexEditor widget to phoenix/Qt (has dynamic scrollbar like
phoenix/GTK, but does not yet support page up/down scrolling)
- optimized debugger to look great with either phoenix/GTK or phoenix/Qt
- fixed phoenix/Qt fullscreen mode (had to allow resizing of the layout,
and resize the container)
- fixed phoenix/Qt Window::setBackgroundColor() bug that was making
statusbar invisible
- entering fullscreen now captures mouse, leaving fullscreen releases it
- so by default, no cursor in fullscreen mode now
- F12 key was assigned the task of toggling mouse capture,
Tools->Capture Mouse was removed
- above change allows toggling mouse capture in fullscreen if you like
It wasn't my idea, but toggling the mouse capture in fullscreen also hiding the mouse cursor is what I call genius design. Two birds with one stone, and very intuitive.
Also, the default GUI on Linux for bsnes and bgameboy is now Qt, instead
of GTK+. I did this because Qt's fullscreen is far more stable, and
I fixed up the remaining bugs anyway.
byuu says:
Changelog:
- added ui-libsnes directory back into source archive; make archive-all
includes it now
- added basic HexEditor widget to phoenix/Windows
byuu says:
Changelog:
- fixed Super Game Boy save state support
- both SNES and GameBoy only initialize serialize size on cartridge load
once now, just like I've already done with memory mapping
- added nall/public_cast.hpp for fun ... don't worry, I'm never actually
going to use it in production code :D
byuu says:
This release brings improved Super Game Boy emulation, the final SHA256
hashes for the DSP-(1,1B,2,3,4) and ST-(0010,0011) coprocessors, user
interface improvements, and major internal code restructuring.
Changelog (since v074):
- completely rewrote memory sub-system to support 1-byte granularity in
XML mapping
- removed Memory inheritance and MMIO class completely, any address can
be mapped to any function now
- SuperFX: removed SuperFXBus : Bus, now implemented manually
- SA-1: removed SA1Bus : Bus, now implemented manually
- entire bus mapping is now static, happens once on cartridge load
- as a result, read/write handlers now handle MMC mapping; slower
average case, far faster worst case
- namespace memory is no more, RAM arrays are stored inside the chips
they are owned by now
- GameBoy: improved CPU HALT emulation, fixes Zelda: Link's Awakening
scrolling
- GameBoy: added serial emulation (cannot connect to another GB yet),
fixes Shin Megami Tensei - Devichil
- GameBoy: improved LCD STAT emulation, fixes Sagaia
- ui: added fullscreen support (F11 key), video settings allows for
three scale settings
- ui: fixed brightness, contrast, gamma, audio volume, input frequency
values on program startup
- ui: since Qt is dead, config file becomes bsnes.cfg once again
- Super Game Boy: you can now load the BIOS without a game inserted to
see a pretty white box
- ui-gameboy: can be built without SNES components now
- libsnes: now a UI target, compile with 'make ui=ui-libsnes'
- libsnes: added WRAM, APURAM, VRAM, OAM, CGRAM access (cheat search,
etc)
- source: removed launcher/, as the Qt port is now gone
- source: Makefile restructuring to better support new ui targets
- source: lots of other internal code cleanup work
byuu says:
Changelog:
- debugger compiles on all three profiles
- libsnes compiles on all three platforms (no API changes to libsnes)
- memory.cpp : namespace memory removed (wram -> cpu, apuram -> smp,
vram, oam, cgram -> ppu)
- sa1.cpp : namespace memory removed (SA-1 specific functions merged
inline to SA1::bus_read,write)
- GameBoy: added serial link support with interrupts and proper 8192hz
timing, but obviously it acts as if no other GB is connected to it
- GameBoy: added STAT OAM interrupt, and better STAT d1,d0 mode values
- UI: since Qt is dead, I've renamed the config files back to bsnes.cfg
and bsnes-geometry.cfg
- SA1: IRAM was not syncing to CPU on SA-1 side
- PPU/Accuracy and PPU/Performance needed Sprite oam renamed to Sprite
sprite; so that I could add uint8 oam[544]
- makes more sense anyway, OAM = object attribute memory, obj or
sprite are better names for Sprite rendering class
- more cleanup
byuu says:
Major WIP, countless changes. I really went to town on cleaning up the
source today with all kinds of new ideas. I'll post the ones I remember,
use diff -ru to get the rest.
What I like the most is my new within template:
template<unsigned lo, unsigned hi>
alwaysinline bool within(unsigned addr) {
static const unsigned mask = ~(hi ^ lo);
return (addr & mask) == lo;
}
Before, you would see code like this:
if((addr & 0xe0e000) == 0x206000) { //$20-3f:6000-7fff
The comment is basically necessary, and you have to trust that the mask
is right, or do the math yourself.
Now, it looks like this:
if(within<0x20, 0x3f, 0x6000, 0x7fff>(addr)) {
That's the same as within<0x206000, 0x3f7fff>, I just made an
SNES-variant to more closely simulate my XML mapping style:
20-3f:6000-7fff.
Now obviously this has limitations, it only works in base-2 and it can't
manage some tricky edge cases like (addr & 0x408000) == 0x008000 for
00-3f|80-bf:8000-ffff. But for the most part, I'll be using this where
I can. The Game Boy is fully ported over to it (via the MBCs), but the
SNES only has the BS-X town cartridge moved over so far. SuperFX and
SA-1 at the very least could benefit.
Next up, since the memory map is now static, there's really no reason to
remap the entire thing at power-on and reset. So it is now set up at
cartridge load and that's it. I moved the CPU/PPU/WRAM mapping out of
memory.cpp and into their respective processors. A bit of duplication
only because there are multiple processor cores for the different
profiles, but I'm not worried about that. This is also going to be
necessary to fix the debugger.
Next, Coprocessor::enable() actually does what I initially intended it
to now: it is called once to turn a chip on after cartridge load. It's
not called on power cycle anymore. This should help fix power-cycle on
my serial simulation code, and was needed to map the bus exactly one
time. Although most stuff is mapped through XML, some chips still need
some manual hooks for monitoring and such (eg S-DD1.)
Next, I've started killing off memory::, it was initially an
over-reaction to the question of where to put APURAM (in the SMP or
DSP?). The idea was to have this namespace that contained all memory for
everything. But it was very annoying and tedious, and various chips
ignored the convention anyway like ST-0011 RAM, which couldn't work
anyway since it is natively uint16 and not uint8. Cx4 will need 24-bit
RAM eventually, too. There's 8->24-bit functions in there now, because
the HLE code is hideous.
So far, all the cartridge.cpp memory:: types have been destroyed.
memory::cartrom, memory::cartram become cartridge.rom and cartridge.ram.
memory::cartrtc was moved into the SRTC and SPC7110 classes directly.
memory::bsxflash was moved into BSXFlash. memory::bsxram and
memory::bsxpram were moved into BSXCartridge (the town cartridge).
memory::st[AB](rom|ram) were moved into a new area,
snes/chip/sufamiturbo. The snes/chip moniker really doesn't work so
well, since it also has base units, and the serial communications stuff
which is through the controller port, but oh well, now it also has the
base structure for the Sufami Turbo cartridge too. So now we have
sufamiturbo.slotA.rom, sufamiturbo.slotB.ram, etc.
Next, the ST-0010/ST-0011 actually save the data RAM to disk. This
wasn't at all compatible with my old system, and I didn't want to keep
adding memory types to check inside the main UI cartridge RAM loading
and saving routines.
So I built a NonVolatileRAM vector inside SNES::Cartridge, and any chip
that has memory it wants to save and load from disk can append onto it
: data, size, id ("srm", "rtc", "nec", etc) and slot (0 = cartridge,
1 = slot A, 2 = slot B)
To load and save memory, we just do a simple: foreach(memory,
SNES::cartridge.nvram) load/saveMemory(memory).
As a result, you can now keep your save games in F1 Race of Champions II
and Hayazashi Nidan Morita Shougi. Technically I think Metal Combat
should work this way as well, having the RAM being part of the chip
itself, but for now that chip just writes directly into cartridge.ram,
so it also technically saves to disk for now.
To avoid a potential conflict with a manipulated memory map, BS-X SRAM
and PSRAM are now .bss and .bsp, and not .srm and .psr. Honestly I don't
like .srm as an extension either, but it doesn't bother me enough to
break save RAM compatibility with other emulators, so don't worry about
that changing.
I finally killed off MappedRAM initializing size to ~0 (-1U). A size of
zero means there is no memory there just the same. This was an old
holdover for handling MMIO mapping, if I recall correctly. Something
about a size of zero on MMIO-Memory objects causing it to wrap the
address, so ~0 would let it map direct addresses ... or something.
Whatever, that's not needed at all anymore.
BSXBase becomes BSXSatellaview, and I've defaulted the device to being
attached since it won't affect non-BSX games anyway. Eventually the GUI
needs to make that an option. BSXCart becomes BSXCartridge. BSXFlash
remains unchanged.
I probably need to make Coprocessor::disable() functions now to free up
memory on unload, but it shouldn't hurt anything the way it is.
libsnes is most definitely broken to all hell and back now, and the
debugger is still shot. I suppose we'll need some tricky code to work
with the old ID system, and we'll need to add some more IDs for the new
memory types.
byuu says:
This WIP fixes up the last bit from the old memory mapping system, the
BS-X Satellaview town cartridge now has a static memory mapper that is
dynamically decoded based on register settings. Tested with BS Town + BS
Zelda, and I can get in-game just fine. The mapping code is actually
a lot more readable this way, too.
byuu says:
The nall::function binding for the memory map apparently breaks when the
debugger is enabled, as PPU:: becomes PPUdebugger::, etc; and C++ isn't
smart enough to upconvert for us.
Not sure how I am going to work around that yet ...
Changelog:
- improved GameBoy::CPU::Halt emulation, fixes Legend of Zelda intro
water+world-map scrolling at the same time
- added GameBoy::APU skeleton, and hooked up MMIO read/write for all
registers
- modified nall integer->string functions
byuu says:
Fullscreen works on all ports, but Qt is in general pretty wonky at the
moment. Don't really care right now.
F11 toggles fullscreen, there is no menu or status in fullscreen, and it
auto-scales to the highest even multiple that it can.
It copies all other settings (filter, shader, aspect correction, video
region, vsync, async) from your windowed mode settings.
You cannot enable the menu or status bars, because those are a major
pain in the ass to support with both GTK+ and Qt returning nonsense
geometries.
Combine with each platform treating whether or not to handle menus
and/or statuses as part of the geometry or not, and it's a recipe for
pain.
It is pseudo-fullscreen for now, but if we have some spiffy code in the
future to set a true fullscreen that works on Linux (and hopefully OS
X), I'll add a true-FS option to ruby later.
byuu says:
This WIP uses the 16MB+64MB memory tables for 1:1 mapping of the S-CPU
bus.
Minimum RAM requirement goes up to 128MB, dare I be bold here and
recommend you have 256MB.
I also hooked up the basic bindings for making pseudo-fullscreen windows
in phoenix/Windows and phoenix/GTK+, but both have some serious issues.
- GTK+ won't resize my form container, even though it's the same code
I used successfully in bsnes v039 and prior with hiro
- Windows scale selection breaks the faux-fullscreen effects
- I am intending to write off the menu/status bars and just auto-size
the video to fill the screen, nice and simple
byuu says:
Oh good, that turned out to be a lot easier than I expected.
Almost all of the work was already done yesterday in porting the SA-1
over to a static map.
byuu says:
SuperFXBus was inheriting from Bus, in other words using a copy of the
same memory mapping subsystem.
I've removed that and made it a simple mask, since only ROM+RAM are
mapped there.
byuu says:
You guys are going to hate the hell out of this one. It's twenty hours
of non-stop work, no exaggeration at all. Started at 4AM, just wrapped
up now at 8PM.
I rewrote the entire memory subsystem.
Old system:
65536 pages that map 256 bytes each
Mapping a new page overwrites old page
Granularity capped at 256 bytes minimum, requiring ST-001x to map
60:0000-00ff instead of 60:0000,0001
Classes inherit from MMIO and Memory, forcing only one mappable function
per class, and fixed names
MMIO sub-mapper inside memory: 00-3f:2000-5fff for one-byte granularity
Can dynamically change the map at run-time, MMC register settings
perform dynamic remapping
New system:
XML mapping is still based around banklo-bankhi:addrlo-addrhi, as that
shapes almost everything on the SNES very well
Internally, 2048 pages that map 8192 bytes each
Pages are vectors, scans O(n) from last to first (O(log n) would not
help, n is never > 3)
Can multi-cast writes, but not reads [for the obvious reason of: which
read do you return?]
Can map reads and writes separately
Granularity of one for entire 24-bit address range, no need for MMIO
- whatever is in XML is exactly what you get
Read/Write tables bind function callbacks, so I can have any number of
functions with any names from any classes with no inheritance (no
more uPD7725DR, uPD7725SR helpers, etc)
Less memory usage overall due to less tables [ I tried 16 million tables
and it used 2GB of RAM >_o ]
Cannot dynamically change the map at run-time, MMC read/write functions
perform address translation [worse average case speed, better worst
case speed]
Now the hate me part, functors can't beat virtual functions for speed.
There are speed penalties involved:
-4.5% on average games
-11% on SuperFX games (SFX has its own bus)
-15% on SA-1 games (SA-1 has two buses)
Of course the two that need the speed the most get the biggest hits.
I'm afraid there's really not a lot of wiggle room to boost speed back
up.
I suppose one bright spot is that we can much more easily try out
entirely new mapping systems now, since the dynamic portions have been
eliminated.
byuu says:
Changelog:
- updated/fixed st0011.bin SHA256 sum
- removed launcher/
- building ui-gameboy only builds the Game Boy core, not the SNES core
- binary name output is bgameboy for ui-gameboy
- make install/make uninstall work as expected with the extra data files
[Editor's note - those last three changes seem to have been made in
v074r01]
byuu says:
Changelog:
- fixed libsnes to compile again, the GB RTC constant is there but
doesn't do anything just yet (no serialize support in GameBoy core)
- libsnes: added SNES_MEMORY_(WRAM,APURAM,VRAM,OAM,CGRAM) -- really only
for the first one, it allows libsnes users to implement their own
cheat search
- you can now load the SGB BIOS without a game!! please be sure to enjoy
the blinking cartridge icon emulation :D
- necdsp (uPD7725,96050) - simplified code a bit: removed persistent
regs.idb, simplified jumps, merged exec() with main loop, etc.
- nall::function - fixed an initialization bug when copy-constructing
objects
- nall::vector - use calloc instead of malloc to help safeguard against
uninitialized class data (potentially hides errors, but better than
crashing in production)
byuu says (since v073):
This release adds full low-level emulation of the NEC uPD96050
coprocessor, used by the ST-0010 (F1 Race of Champions II) and the
ST-0011 (Hayazashi Nidan Morita Shougi). The former was already playable
with HLE, but lacked timing emulation. The latter has never been
playable through emulation before now. But as with SD Gundam GX before,
you really weren't missing much.
[...]
Also new in this release is my own Game Boy emulator. It is being used
to provide native Super Game Boy support, built directly into bsnes.
This core is released under the GPLv2, but I am willing to grant a more
permissive license for other SNES emulators, if anyone is interested.
Of course I cannot compete with the quality of gambatte, and certainly
not from only a weeks' worth of work. Currently, there is no Game
Boy-side sound output and there are quite a few bugs remaining in its
emulation core. I would appreciate any help on this, the Game Boy is not
my forte. So yes, we are taking a step back today, so that we may take
two steps forward in the future.
[...]
Lastly, the debugger is still Linux-only, but it is now stable enough to
be considered usable. Check it out if you like, compile with -DDEBUGGER
to enable it.
byuu says:
I give up for now. This WIP doesn't really improve uPD any, but it does
have major fixes to the debugger.
Debugger is still Linux-only for want of a HexEditor widget, but the
Linux one is now usable.
Before it'd trace and search for breakpoint at sub-1fps. Fixed it to not
break out of core for simple things and it'll run at near-fullspeed for
BPs, half-speed for tracing to file (lots of I/O.)
byuu says:
Above WIP will automatically map in the ST-001x chips, no need for an
XML file.
F1 Race of Champions II (J) is fully playable, at least. It's forced to
15MHz like the ST-0011 for now.
The core (snes/chip/necdsp/core) is somewhat unstable at the moment,
some debugging hooks commented out and some hacks / ideas floating
around in there. Disassembler can't handle long jumps yet.
Added uPD96050 emulation, but it's not working right now. I'm totally
stumped. The ST-0010 player cars aren't moving right, and it crashes
sometimes on exit like it's going out of bounds.
I had decided to try and avoid duplicating the 20KB uPD7725 core, so
I made a new folder:
snes/chip/necdsp
snes/chip/necdsp/upd7725
snes/chip/necdsp/upd96050
The latter two derive from the former, and they specify the PC, RP and
DP sizes, which allocates appropriate memory.
I use simple runtime-masked registers (to avoid template hell on every
uPDcore function), and then I derive from that to complete each actual
DSP. The uPD7725 seems to work great, but the uPD96050 is fucked and
I don't know why :(
Help would be appreciated, it must be something simple because I am
certain the cars were working before.
Kinda wish I didn't scrap the old code now :(
I've merged the bgameboy GUI into the bsnes project, as it's only ~3KB
and it means I don't have to keep manually editing and copying two
projects around. You can set ui := ui-gameboy to build bgameboy as
a standalone, and ui := ui to build the bsnes you are used to. I will be
polishing it to allow changing the binary output name, not building the
SNES portions when not needed, etc in time.
So that'll end bgameboy standalone releases, at least for now. If it
ever gets important enough to split back out again I can, but I prefer
it this way. bgameboy was never meant to be mainstream anyway, just
a component for bsnes.
byuu says:
Changelog:
- much tighter SGB integration, but this is still a work-in-progress
- memory::gb(rom,ram,rtc) is gone, uses GameBoy:: memory structures
directly (a big gain, no need to copy memory to save and load)
- UI-based cartridge loading works with GameBoy:: directly as well
- libsnes will need to be updated internally to reflect this
- games can save and load (even before bgameboy can, hah)
- save states hooked up, but they crash the DMG. I don't know why, as
if it was hard enough saving states with libco, try doing it for an
emulator inside an emulator >_<
- last remnants of old SGB stuff removed, <sueprgameboy> XML converted
to <icd2>
- looks like the XML list idea is looking pretty useless for
SNES::Cartridge now that bgameboy handles its own XML mapping
byuu says:
Changelog:
- removed bsnes/supergameboy (libgameboy -> libgambatte binding)
- added direct ICD2-R coprocessor emulation
- linked in bgameboy to the ICD2-R module
- Makefile removes -Isnes, all files adjusted from <name.hpp> to
<snes/name.hpp> [relic from asnes split]
You can now play Super Game Boy games with the core bsnes library.
byuu says:
Changelog:
- adds XML memory mapping to cartridge loading;
nall/gameboy/cartridge.hpp will bullshit one for now
- still need to add proper MMM01 detection (menu code goes at end of ROM
apparently)
- added save state support, which works here (but not inside bsnes, go
figure), to aid in debugging. Expect constant changes for now a long
while, it's way too early to add states
byuu says:
Changelog:
- fixed LYC interrupt at LY=0 (fixes Makai Toushi SaGa)
- fixed MBC3 ROM bank mapping (fixes Harvest Moon GBC)
- added Super Game Boy MLT_REQ support to JOYP, needed for ICD2-R emulation
- temporarily changed System::run() to execute only four cycles before
exiting for bsnes, will make two versions later
- uses actual boot ROMs, has DMG+SGB1 for now. Need SGB2, don't care
about CGB. Defaults to SGB1, no way to select just yet. DMG 4-second
wait is annoying. Does not force games to act like SGB on bgameboy
itself, because that has no ICD2 and fails the required MLT_REQ check
byuu says:
Changelog:
- added skeleton HuC1 (gets to a menu)
- added skeleton HuC3 (gets to a menu, this one is supposedly a lot more
complex (IR, RTC, etc.))
- added MMM01 emulation
byuu says:
Changelog:
- rewrote sprite rendering, grabs first ten sprites, draws them in
revere order of a: X-index, b: OAM appearance order
- simplified tile decoding to use less variables
- added MBC3 emulation (for now, RTC is always enabled)
- STOP can be broken via joypad IF, this may not be correct though (it
may trigger even without P10-13 being modified)
- cleaned up all MBC emulation to use masks instead of ranges
- MBC2 uses 512-byte table now, ignores high 4-bits. Easier this way I guess
- tools menu temporarily has a console tracer enable option
- some other stuff
No real visible improvements :(
byuu says:
Changelog:
- fixed sprite Vflip check
- fixed up window rendering (well, mostly, works great in Megaman II but
not so great in Makaitoushi SaGa)
- added MBC2, MBC5 (already had MBC0, MBC1)
- removed reset, hooked up power cycle and Vsync toggle
- some other stuff
Makaitoushi SaGa locks on the main menu after some graphical glitches on
the title screen, damn.
Shin Megami Tensei - Devichil Black Book locks up immediately, hitting
HALT opcodes all the time, damn again.
Megaman II should be fully playable now.
Contra 3 is really close, but goes crazy on the turtle boss fight.
byuu says:
Added MBC1 emulation, although battery RAM doesn't save or load to disk
yet.
Made up a fake MBC0 which is really just saying 'no MBC', for consistent
handling of all MBCs.
Added bumpers to stop ROM/RAM out of bounds accesses.
Added STAT interrupts for LY coincidence, Vblank and Hblank (not for OAM
access yet, I don't know the timings.)
Fixed timer interrupt [Jonas Quinn]
Made all interrupts call a CPU function instead of just setting a flag
for better control (to allow below addition.)
Added HALT and STOP emulation, the latter permanently locks the Game Boy
for now. The former breaks on interrupts.
Rewrote all the rendering code to suck 50% less, though it's still
absolutely miserable and scanline-based.
Added pixel-level horizontal scrolling to BGs.
Fixed OBJ rendering error that was making them render upside down (I was
flipping to compensate before.)
Added OBJ 8x16 mode.
Added OBJ priority support.
Added window (but it's broken to all hell on Mega Man II.)
byuu says:
Fixed all of the previously mentioned problems by myself and Jonas
Quinn.
Fixed up JOYP and hooked up JOYP interrupts, they work on JOYP writes as
well if your selection makes the low four bits change to != 0xF.
Added basic sprite emulation, very very very lousy but it works for
Tetris.
Fixed DAA, fuck that opcode. Fixes blargg's CPU tests 1 and 11 (for some
odd reason.) Only test 2 is failing, on the "EI" test. Maybe it relies
on STAT interrupts?
Did some other stuff.
Tetris is now 100% fully playable. But that renderer is an abomination.
Soooooo simplistic and missing so many edge cases.
But holy shit, a fully playable commercial game in three days. I would
have killed to have made that progress when I started on bsnes.
byuu says:
All 512 instructions implemented. To make debugging flags easier and to
reduce the code size, I made parent routines for all the bit-logic that
sets flags. This bumped up the speed to 3,045fps. So about 51x faster
than a real Game Boy.
I suspect the frame rate to plummet rapidly as I emulate more stuff and
try and get timings more accurate. Wild ballpark, I'd guess 300fps or
so. Not based on anything, just a made up number. I have no idea what it
will end up being.
So I still need:
* decode MMIO reads/writes
* add CPU interrupt support
* add LCD emulation (probably the hardest part)
* add PCM emulation (well, this would likely be the hardest; but it's
not essential right now)
* debug the holy living shit out of the CPU core. Anyone want to help
now by looking it over? :D
byuu says:
314 of 512 opcodes implemented, can execute the first 67,450
instructions of Tetris.
I also added an MMIO bus, ala bsnes, so that I can map and access
individual registers with a single indirection.
byuu says:
Hooked up a scheduler to enter/exit the CPU core wherever I want. Added
basic 4*1024*1024hz clock, and about eleven or so opcodes. Creating the
disassembler as I encounter each new opcode, not skipping ahead to do
all 'like other' opcodes, eg if I add 'dec b', I don't then add 'dec c'
until I encounter it.
The source tarball also included empty obj/ and out/ directories which
git does not support.
byuu says:
Project started, so basically everything is new.
It's basically a rough skeleton that mimics bsnes project structure.
Eventually the src/gameboy folder will be copied into bsnes-official and
used by the chip/supergameboy core.
The middleware layer (supergameboy/interface) will be merged into a new
chip/icd2 folder that will represent direct Super Game Boy emulation in
the future.
At least, if all goes according to plan.
There is a simple GUI that can load ROMs, but do nothing after it. It's
not hooked up to ruby yet.
There is a basic system class and interface to expose the
video/audio/input functions.
There is a basic memory bus that doesn't support any MBCs yet.
There is a CPU skeleton that only handles easy read/write access to the
CPU registers (AF is a really fucked up register.)
The core is not hooked up to libco yet, but I intend for it to be, so
that I can run the CPU + LCD how I like.
If it turns out the LCD+audio is easily enslavable, then I'll probably
drop libco and just run it like a regular emulator, using a thread
wrapper around it in bsnes only. We'll see.
The CPU doesn't actually support any opcodes, and loading a ROM won't
actually execute anything.
byuu says:
While perhaps not perfect, pretty good is better than nothing ... I've
added emulation of auto-joypad poll timing.
Going off ikari_01's confirmation of what we suspected, that the strobe
happens every 256 clocks, I've set up emulation as follows:
Upon reset, our clock counter is reset to zero.
At the start of each frame, our poll counter is reset to zero.
Every 256 clocks, we call the step_auto_joypad_poll() function.
If we are at V=225/240+ (based on overscan setting), we check the poll
counter.
At zero, we poll the actual controller and set the joypad polling flag
in $4212.d0 to 1.
From zero through fifteen, we read in one bit for each controller and
shift it into the register.
At sixteen, we turn off the joypad polling flag.
The 256-clock divider allows the start point of polling for each frame
to fluctuate wildly like real hardware.
I count regardless of auto joypad enable, as per $4212.d0's behavior;
but only poll when it's actually enabled.
I do not consume any actual time from this polling. I honestly don't
know if I even should, or if it manages to do it in the background.
If it should consume time, then this most likely happens between opcode
edges and we'll have to adjust the code a good bit.
All commercial games should continue to work fine, but this will likely
break some hacks/translations not tested on hardware.
Without the timing emulation, reading $4218-421f before V=~228 would
basically give you the valid input controller values of the previous
frame.
Now, like hardware, it should give you a state that is part previous
frame, part current frame shifted into it. Button positions won't be
reliable and will shift every 256 clocks.
I've also removed the Qt GUI, and renamed ui-phoenix to just ui. This
removes 400kb of source code (phoenix is a lean 130kb), and drops the
archive size from 564KB to 475KB. Combined with the DSP HLE, and we've
knocked off ~570KB of source cruft from the entire project. I am looking
forward to not having to specify which GUI is included anymore.
byuu says:
This release marks a major step forward, offering full low-level
emulation of all four DSP coprocessors based on the NEC uPD77C25
processor core. Many people were responsible for this milestone: Dr.
Decapitator for the actual decapping and extraction; Lord Nightmare for
the cartridges and some special analysis tools; myself, Jonas Quinn and
Cydrak for the uPD77C25 emulation; and all of the donors who raised the
necessary $1,000 for the necessary hardware and equipment needed to pull
this all off. To say thanks to the donors, I am releasing the uPD77C25
emulation core to the public domain, so that everyone can benefit from
it.
All four DSP emulations will be improved by this by way of having
realistic timing; the DSP-4 will benefit further as the high-level
emulation was incomplete and somewhat buggy; and the DSP-3 will benefit
the most as the high-levle emulation there was not complete enough to be
playable. As a result, most notably, this means bsnes v073 is the first
emulator to fully be able to play SD Gundam GX (J)!
As bsnes' primary goal is accuracy, the LLE DSP support renders the old
HLE DSP support obsolete. Ergo, I have removed the 166KB of HLE source
code, and replaced it with the uPD77C25 core, which comprises a mere
20KB of source code. As this LLE module supports save states, this also
means that for the first time, DSP-3 and DSP-4 games have save state
support.
On the other hand, this also means that to run any DSP game, you will
need the appropriate program ROM. As these are copyrighted, I cannot
distribute them nor tell you where to get them. All I can do is provide
you with the necessary filenames and hashes.
Changelog (since v072 release):
* added NEC uPD77C25 emulation core
* added low-level emulation of the DSP-1, DSP-1B, DSP-2, DSP-3, DSP-4
coprocessors
* removed high-level emulation of the DSP-n coprocessors
* added blargg's libco::ppc.c module, which is far more portable, even
running on the PS3
* added software filter support via binary plugins
* added debugger (currently Linux-only); but it is as yet unstable
* added pause shortcut
* updated mightymo's cheat code database
byuu says:
Changelog:
* added SNES::interface.message(const string&) so that the core can send
messages for the GUI to display
* failing to load a DSP-n ROM, or failing the DSP-n SHA256 hash (if
there is one) will result in a warning message
* all DSP-1 games by default once again use the DSP-1B program, now that
it has been redumped and reverified
* fixed bugs in uPD77C25 SHL2 and SHL4 opcodes; fixes DSP-2 and DSP-4
emulation
* removed all DSP HLE (DSP-1, DSP-2, DSP-3, DSP-4)
* as a result of LLE, DSP-3 and DSP-4 games can now load and save states
byuu says:
The DSP-1 and DSP-3 emulation appears to be great.
However, there are bugs in the other two.
DSP-2, Dungeon Master: the graphics in-game appear corrupt. It looks
like the first two pixels have the right color, the next six have the
wrong color, resulting in vertical stripes.
DSP-4, Top Gear 3000: the car sprites appear to be showing 8x8 tiles
instead of 16x16 files, resulting in 3/4ths of the cars being invisible,
but only up close.
Dr. Decapitator and Lord Nightmare are supremely confident that our
dumps are 100% accurate, there was no bus wavering at all this time.
We believe they are bugs in the uPD77C25 emulation.
I desperately need help! I have spent the past several hours trying to
ascertain what the problem is, to no avail.
I've tried messing with just about every flag, every register, checking
for use of OV1, S1, custom opcodes, etc ... I am having no luck.
I'm going to keep trying with even more sophisticated cross-analysis.
But Cydrak, if you would please rework that magic of yours, I'd be
eternally grateful :D
byuu says:
This release defaults DSP-3 loading to use the uPD77C25 core. It also
pre-emptively does the same for the DSP-2 and DSP-4. v072r11 did this
for the DSP-1.
I've also renamed my string<>integer conversion function names:
strhex -> hex
strsigned -> integer
strunsigned -> decimal
strbin -> binary
strdouble -> fp (this one will no doubt be trouble since 'file fp' is
a common idiom. floatingpoint is too long, float and double are
already reserved.)
A number of changes in this release were contributed by Cydrak in the
WIP thread, who described his changes from r09/r10 thusly:
- Call cpu.synchronize_coprocessor() on external R/W to avoid missing data
- Sign-extend K, L before multiplying
- Load IDB before ALU. Supports the MOV A, d; XOR A, A idiom which is
all over the place
- Use 16-bit types in flag checks (notably Z)
- Flags mostly unified; hopefully at least OV0 and SGN work
- Carry-in comes from the *other* accumulator's flags, this is used for
long arithmetic
- CMP is ~q (see the many CMP A; INC A where values get negated)
- SHR1 is arithmetic shift and retains the sign bit (Mario Kart sprites
and physics are broken without it)
- SHL1 has carry-in per the datasheet, it doesn't seem to be used though
- XCHG probably byteswaps, but it's not used either
- Reversed DR external R/W order again, big-endian seems to break it
byuu described the remaining changes:
You do not need the XML files anymore, bsnes will automatically choose
the new uPD module, and look for dsp1b.bin.
If you make your own XML file, you can force the old HLE mode, or use
a differently-named PROM.
If and when we get the DSP-2,3,4 modules, bsnes v072.11 and above should
already be able to run them, assuming no more emulation core bugs.
Unfortunately, I missed the v072r08 release; it was taken down before
I saw the announcement.
byuu says (about v072r08):
This WIP adds NEC uPD77C25 emulation. Unfortunately it's not at all functional yet, there are way too many things I don't understand about the chip.
I'm absolutely going to need help to complete this.
[...]
For now, you need the included PCB XML to manually map the program/data ROM in, which are included with the archive. You'll have to rewrite the map yourself to run other DSP-1 games, unless they have the same layout as Mario Kart. I am using the US [!] version, name it mariokart.sfc and put all the archive files and the ROM together.
From here, bsnes will load up the ROMs, and start executing instructions. Since the emulation is so incomplete, it just deadlocks on the "Nintendo" logo as if there were no DSP on the cart at all, but if you enable tracing, you'll see it actually starts doing a lot of stuff before getting stuck in a really long and confusing loop.
[Note: the DSP-1B program and data ROMs are not included in this commit.
The PCB XML file mentioned above looks like this:
<?xml version='1.0' encoding='UTF-8'?>
<cartridge region='NTSC'>
<rom>
<map mode='shadow' address='00-3f:8000-ffff'/>
<map mode='linear' address='40-7f:0000-ffff'/>
<map mode='shadow' address='80-bf:8000-ffff'/>
<map mode='linear' address='c0-ff:0000-ffff'/>
</rom>
<ram size='800'>
<map mode='linear' address='20-3f:6000-7fff'/>
<map mode='linear' address='a0-bf:6000-7fff'/>
<map mode='linear' address='70-7f:0000-ffff'/>
</ram>
<upd77c25 program="dsp1b-program.bin" data="dsp1b-data.bin">
<dr>
<map address='00-1f:6000-6fff'/>
<map address='80-9f:6000-6fff'/>
</dr>
<sr>
<map address='00-1f:7000-7fff'/>
<map address='80-9f:7000-7fff'/>
</sr>
</upd77c25>
</cartridge>
Save it as 'mariokart.xml']
byuu says (about v072r09):
Fixes OP/LD RQM=1 on DR modify, Mario Kart can get in-game, but the
track is completely corrupted.
Reorders order of operations for OP, in an attempt to mimic parallelism.
Added support for OP KLM DST.
Added S1 flag setting, probably not correct.
byuu says:
I'm happy enough with the debugger now. Not 100% up to par with the old
one, but it also does some new things the old one didn't.
- step into / step over are disabled unless they can be done safely
- this means step over is usually grayed unless you hit step into first,
due to bsnes not being opcode-based (you can't skip an opcode that is
half-executed)
- you can now trace console output to disk
- stepping the CPU will print stepped SMP opcodes if the checkbox for it
is on and vice versa
- button added to clear the console log
(there was no r05 release posted to the WIP thread)
byuu says:
Updated libsnes to use new file and function names.
Also added EditBox::setCursorPosition for GTK+ and Qt, only used by the
debugger so far so that when text is added, it auto-scrolls to the
bottom.
(there was no r03 release posted to the WIP thread)
byuu says:
nall/snes/smp.hpp created, ~68 addressing modes compared to the CPU's
~27, ugh. All hooked up, you can step into / step over / trace the S-SMP
now as well.
byuu says:
Just debugger work here. About three or four hours to write
nall/snes/cpu.hpp, which is basically opcode encoding information for
disassembly.
byuu says:
- added pause shortcut ('P' key, as pause/break is too finicky)
- pause and auto-pause show on status bar
- added a debugger skeleton, very very primitive and completely unusable
- don't try it yet
- added software filter support
Also included is the new snesfilter library. It has all of the filters
the old one had, as well as scanline filters since that's not in my GUI
anymore
If you want scanlines and other software filters, then you can either
make your own hybrid two-in-one software filter, or make a pixel shader
(I don't have one of those yet.)
byuu says (since v070):
- fixed a regression in the accuracy/compatibility CPU core with IRQ
masking; fixes World Heroes 2
- fixed OAM address reset on $2100 writes for performance PPU core;
fixes Mahjongg 2 and others
- DSP-1 always returns high 8-bits of status register; fixes Ace wo
Nerae! freeze [Jonas Quinn]
- performance core can now take advantage of serial support
- pixel shaders now use a unified XML format; in the future they will
support multi-pass shaders and textures
- major code restructuring
- first public release of phoenix GUI port
- mightymo's cheat code pack is now an external file for the phoenix
port
- phoenix port stores cheat codes in XML format as well, unifying all
file formats to the same markup language
(there was no r15 release posted to the WIP thread)
byuu says:
This mostly contains improvements for nall, like path unification.
This should fix FitzRoy's issue with .. on Windows.
(there was no r13 release posted to the WIP thread)
byuu says:
- nall/string: trim and split functions now take the limit as a template
parameter for clarity, trim_once variants are removed
- quotable.trim<1>("\""); //remove quotes from string
- cheatcode.split<3>(","); //split up to three times, third one is
a description that may have commas
- foobar.trim(" "); //remove any and all spaces
- nall/string: added wildcard() and iwildcard() functions for pattern
matching
- nall/directory: accepts an optional pattern parameter to perform
wildcard matching
- lstring cartridges = directory::contents(path, "*.sfc");
- some people may prefer directory::contents("/path/to/files/*.sfc"),
but I like not having to build a string when you have the path
separated already
- nall/qt: removed entirely, now resides in bsnes/ui-qt/template; I do
intend to replace the check/radio actions with native Qt versions
later
- bsnes/data: new folder, share the parts that both UIs use; bsnes.ico,
bsnes.png, bsnes.Desktop, cheats.xml; simplify Makefile install target
- Makefile: install target now creates .bsnes folder and copies
cheats.xml there for you
- Makefile: gconftool hack removed, not needed for phoenix, will work
around with Qt later
- will probably make bsnes/Qt read the cheats.xml file externally as
well, as that file makes each profile 1MB bigger when embedded
- as such, will probably make bsnes also look in the binary directory
for that file, so Windows users don't have to copy it to their
userdata folder
byuu says:
- removed support for images with copier headers
- phoenix/Windows: Label properly refreshes on text changes, fixes video
settings sliders
- alt/ppu-performance: fixed mosaic Voffset bug, fixes Super Bowling et al
- alt/cpu: fixed CPU::joylatch() reporting, allows serial applications
to work with performance profile
- hooked up SNES::cartridge.basename, allows MSU1 and serial support
with the phoenix UI
- updated UPS patching code for bsnes/Qt, allowing it to compile again,
hidden config option file.bypassPatchCrc32 was removed
byuu says:
- phoenix/All: converted all instances of const char* to const
nall::string&
- above used to require: label.setText(string("FPS: ", fps)); but can
now use: label.setText({"FPS", fps});
- also avoids the need for the internal implementations to have to
check for null string pointers
- phoenix/GTK+: no longer disabling double buffering on the viewport.
Does not cause flickering, and fixes redraw issue on window resize
- phoenix/Qt: like phoenix/GTK+, it will use the default font on the
menubar as well, so child menu items are consistently sized now
- Linux: file browser can list contents of / and won't let you go
higher; Windows needs a similar guard for n:/ or \\
- UPS soft-patching support added
- external XML memory map loading support added
- cartridge folder support added: if folder ends in .sfc and there is
ONE .sfc ROM inside it, it will load the folder as if it were a ROM
- input assignment refreshes text instead of reloading the list, this
saves your position
- auto-advance wasn't working very well, will try again later
- input clear all button removed since it's pretty fast now to do
clear+down:repeat
byuu says:
- added workaround to phoenix/Windows to prevent horizontal scrollbar
always being visible on single-column ListBoxes
- phoenix gains Window::geometry()
- added code to save and restore window positions, as in bsnes/Qt.
Positions are saved to bsnes-phoenix-geometry.cfg this time
- resizing the main window will keep its position onscreen now
There's one issue with GTK+, if you close a window and then call
gtk_window_get_position(), it returns the previously set position rather
than where you actually placed the window. My easy fix of calling
gtk_window_get_position right before actually closing the window didn't
work, so for now you'll have to live with it.
byuu says:
- removed native OS dialog option, I don't plan to add all the code
required to make it optional everywhere
- cheat database supported, although it's external now. Either in the
.bsnes folder or with the binary, named cheats.xml
- cheats.xml is external so that binaries can be much smaller, important
for multiple profiles
- added "find codes" button to cheat editor (need to gray it out
permanently if cheats.xml isn't found)
- added cheat database add window, works the same as bsnes/Qt, but it
will also alert you if you run out of empty cheat slots upon import
- note: I should rename that ok button to "Import"
- hooked up callbacks for multitap/mouse/SS/justifier input
- added mapping for mouse axes and buttons
- used a simplified approach that only lets you map left/middle/right
buttons, but doesn't need a separate popup window or fake controls
- moved capture mouse command to tools menu
- different from Qt where you'd click inside the main window, meant to
be safer from accidental capture, escape still releases capture
- made a skeleton for GUI hotkey support, but the only hotkey is escape
byuu says:
- all three ports of phoenix gain the ability to use
ListBox::setCheckable(), checked(row), setChecked(row, checked
= true);
- cheat editor updated to take advantage of this
Some fun differences between the implementations. Windows was the least
flexible, it only lets you have a check at the start of each item.
Luckily that's all I need for my purposes so it'll work. It's also a lot
easier, as now I don't need a ton of extra code to try and set
per-column checkboxes. Now both Windows and Qt can put text into the
first item with the checkbox, but GTK+ cannot. Further, Qt needs this
because even if you hide the checkbox column, it still tries to search
for typed text from the checkbox column. GTK+ does this too, but unlike
GTK+, Qt lacks an API call to set the search column. Since my code
basically has to change this in real-time since you have to call the
setProperty functions after create(), this means I always set up the
checkbox columns regardless of whether or not they are used. For Qt,
I had to work around this and it'll be an annoying edge case if you try
and use setCheckable(true) and then setCheckable(false), because Qt has
no way to clear the checkboxes from an item once you've enabled them for
the first time. But without doing it this way, there's no way for eg the
ROM file loader to allow type-searching, so that's the way I do it.
Windows works the same, and GTK+ has a separate column (hidden from the
phoenix API standpoint) for the checkboxes, with no column header label
text.
All in all, a major hassle, but it was the only really major GUI hit
from leaving Qt, aside from the horror that's going to be the debugger,
which needs all kinds of highly specialized controls.
byuu says:
- added menu options to select controller port devices, they do actually
work too
- however, input mapping can't map analog axes yet, and the mouse can't
be captured yet, so it's of little use
- added clear and clear all buttons to the input mapper window, mainly
because there was no reason not to (escape clears active input too)
- going to be adding a "special" button in the future that lets you map
mouse axes and buttons
- fixed phoenix/Qt port, both the video rendering and Window::focused()
commands work now
The way I've implemented mouse mapping has always been screwy. So the
special button is going to pop open another window. For digital mapping,
it'll let you choose a mouse button, and for analog mapping, it'll let
you choose an axis. May add in some manual joypad assignment stuff in
there for analog joypad buttons, those things are impossible to
auto-detect.
(there was no r05 release posted to the WIP thread)
byuu says:
- bsnes/phoenix uses XML for per-game cheat codes, markup is identical
to the main database
- added clear and clear all buttons to the cheat code editor
- phoenix/GTK+ sets all child menu elements to match the parent menu font
- phoenix/Windows will draw a black canvas for the Viewport widget
(phoenix/GTK+ still needs this)
byuu says:
- fixed new config file input driver name (you'll have to delete your old config, or change to a different driver and back and restart)
- fixed slot loader windows' OK button placement
- fixed nall/directory.hpp when list size was zero
- rewrote nall/function.hpp, no longer requires <functional> or union tricks
- added state manager
The state manager is a little bit different this time. It's functionally
identical to bsnes/Qt, 100% of the way. But when you save slots, it
stores them in RAM. It only writes the BSA archive upon ROM unload
/ program exit. Yes, this means that technically if the emulator
crashes, you'll lose your states. But a) that very rarely happens, and
b) the old way was thrashing the disk like crazy, every letter you typed
dumped up to 8MB to disk. With this new method, I can simply store
a boolean valid flag before each slot, and pack the file better. Before,
a save on only slot 3 would be 3*state size (~1.2mb), it will now be
3bytes+state size (~400kb.) I have also added a proper signature because
of this, so it will detect when you load an archive for a previous
serializer version and ignore it. When you go to save (unload the game),
if there are no valid slots, the BSA archive gets unlinked (deleted.)
I am also planning a feature around the now-hidden "slot 0". My idea is
for it to be a fallback slot. How many times have you loaded a state
when you meant to save and said, "shit, now I lost some of my progress"?
The idea is that whenever you load a state, right before loading, it
will save to slot 0. When you unload the game, or exit the emulator, it
will also save to slot 0. You will be able to load from slot 0 from the
menu, but not save to it. It will appear at the bottom of the load list.
And lastly, I'll add an advanced option to auto-load slot 0 if it
exists, which will enable "close the emulator and restart where you left
off." functionality.
byuu has traditionally kept these shaders separately, but I don't see
why they shouldn't be stored alongside the code that uses them.
Unlike previous versions of pixel shaders, these are updated to use the
new file-format introduced in v070r03.
byuu says:
- fixed a bug in xml_element::parse() with <![CDATA[...]]> tags
- merged FragmentShader and and VertexShader into Shader, which is an
XML file that contains all relevant data
- updated Qt port to reflect the above
- added support for pixel shaders to the phoenix port
- updated all pixel shaders to use the new format
- ruby won't crash if you give an HLSL driver a GLSL shader or vice
versa, but it will still crash on bad programs
- phoenix::Viewport has its own window class, that paints a black brush
background
[The XML shader] format is subject to change, more specifically I may
change the <source> tag from HLSL shaders.
In the long-long term, it'd be nice to extend the format to allow
multiple shaders to be chained together and to encode base64 texture
files.
But for now, this is good enough.
byuu says:
- phoenix supports onActivate, or return key pressed, on text boxes
- phoenix supports setGeometry() on all widgets
- input settings can now map analog axes and analog buttons
- analog button support is simplified over bsnes/Qt, and it supports the
trigger inversion you see between Xbox 360 and Thrustmaster
controllers
- load cartridge window lets you press enter in the path box to select
the folder, but currently allows invalid folders (makes list empty)
- load cartridge won't reset your view if the folder doesn't change
- this means the last ROM you loaded is highlighted the next time you
go to load cartridge; you're welcome, FitzRoy :P
- removed quit system menu option
- added dummy controller port system menu options, there's no code
behind them yet
- added power/reset menu options, dropped the power checkbox in favor of
a standard power cycle option, removes unnecessary complexity
- added video mode scaling, 1x to 5x; and aspect ratio correction
- added video mode smooth toggle
- added audio settings panel with volume and input frequency adjustment
- config file is where you can control output frequency and latency,
they are too niche for a GUI
- fixed a realpath() crash on Linux when the bsnes binary was in /usr/bin
byuu says:
This release represents the coup de grâce of bsnes/Qt.
Changelog:
- configuration file is now called bsnes-qt.cfg; the first run of this
release will start with a clean state
- MSU1 now supports audio looping via new PCM file format
- disabled state load/save menu due to a serious bug in Qt 4.6.0 for
Windows
- RawInput: all keyboards merged to KB0, it should no longer be required
to reconfigure the keyboard out-of-the-box
- RawInput: fixed a bug where Xbox 360 controller states were being
overwritten by DirectInput controllers
- RawInput: fixed a device sorting bug caused by moving ruby to Unicode
- Direct3D: fixed a pixel shader bug caused by moving ruby to Unicode
- Linux port: fixed sudo make install target
- Linux port: default to gcc/g++ instead of gcc-4.5/g++-4.5 for one last
release
- updated to mightymo's 2010-09-20 cheat pack
byuu says (since v068):
- added new effect toggle tool window, which allows toggling of BG/OAM
graphics layers and DSP audio channels
- added an option to use the native OS file and folder open dialogs
instead of my custom browser
- added a new state selection window
- added frame skipping support, which is only used during fast
forwarding; as a result, fast forward is now ~80% faster
- removed unnecessary icons, added workaround for checkbox/radiobox menu
icons on Linux/GNOME
- added RTS/CTS support to serial simulation
- all cores: OAM high table even address writes should update OAM latch
data register [blargg]
- accuracy core: major improvements to mosaic emulation
- accuracy core: added additional hardware-based caching, resulting in
a ~15% speed boost
- accuracy core: emulated CGRAM address invalidation for writes during
active display
- performance core: added new S-PPU renderer, resulting in a ~10% speed
bost
byuu says:
This is basically the v069 release candidate, heavy testing would really
be appreciated. I'd like for v070 to be the first official phoenix
release, but if a major bug slips past us that will ruin it.
The big change is that save state support was added to the
PPU-performance core.
(there was no r23 release posted to the WIP thread)
byuu says:
Fixes OAM latchdata for all 3 cores and CGRAM address invalidation for
the accuracy core (the only one that really does it because it needs
cycle PPU timing.) Also removes the OAM/CGRAM read/write functions to
put them inside the actual MMIO functions. Easier to handle all the
special cases that way. VRAM is a bit more annoying since there's two
read and two write functions.
This should fix battletech/mechwarrior 3050 palette at least.
byuu says:
Wanted to torture myself, so I implemented the hardest window of all,
the cheat code editor. I had to sacrifice checkboxes inside lists,
unfortunately, but it's a necessary evil. Maybe some day if we can port
checkboxes inside list items to Windows and GTK+, we can add it back. It
should be the only really apparent GUI sacrifice, though. You toggle
cheats by double-clicking them in the list. Easy to do, but not
apparent.
I also added in the focus policy.
byuu says:
Changelog:
- adds synchronize video
- adds synchronize audio
- adds mute audio
- adds advanced settings window with driver selection only
- adds the pretty section header thing I started going toward with Qt
- adds a configuration file, saves to bsnes-phoenix.cfg (I don't make
the .bsnes folder yet)
- the status bar shows [A] for accuracy, [C] for compatibility and [P]
for carburetor
byuu says:
Changelog:
- fixed window casting crash in phoenix
- added perfect forwarding to nall::string variadic templates to fix
file load dialog crash in phoenix
- disabled copy constructors in utf8_t to prevent this problem from
occurring again in the future
- separated canvas window proc by creating a separate class for it
(ironically it was a desktop window causing the first crash)
- use processorArchitecture="*" to make compilation easier
- fixed status bar font assignment in phoenix/Windows
- added InitCommonControls + CoInitialize for XAudio2 on XP
- had to use DirectSound for audio; XAudio2 is crashing on exit which
breaks the profiling (only a problem because you can't change the
drivers without recompiling, there's really no reason to profile
XAudio2 anyway)
byuu says:
This adds proper manifest files to get the nice XP/Vista controls. Need
to find a way to auto-detect MinGW 32 vs 64 since I can't use $shell or
`` on gcc -v on Windows. For now you have to edit the
ui-phoenix/Makefile by hand.
I've implemented the video settings window. I am going to be using
separate windows this time. As nice as having everything in one place
was, I didn't like being forced to stretch things to fill out the
one-size-fits-all tab window I was using before. That and I don't feel
like implementing tab support with phoenix anyway.
The menu gets a load cartridge command, and bsnes writes save RAM files
now. Loading by file dialog crashes on 64-bit. Something's fucked up
there, but I don't know what. Again, help would be great here :)
byuu says:
This WIP fixes the Mode7 repeat issue in the accuracy core.
More importantly, it's the first build to include phoenix. There is
a stub GUI that does basically nothing right now. It will give you
a window, a command to close the emulator, and an FPS meter so you can
tell how fast it is. To load a ROM, you have to drag the ROM on top of
the binary. I don't know if it will work if the filename+path has spaces
in it or not, so avoid that to be safe.
[...]
For some reason, the 64-bit binary sometimes crashes on start, maybe 1:6
times. So just keep trying. I don't know what's up with that, I'd
appreciate if someone here wanted to debug that for me though :D
One really good bit of news, there was that old hiro bug where keyboard
input would cause the main window to beep. I spied on the main event
loop and, as suspected, the status bar was getting focus and rejecting
key presses. What. The. Fuck. Why would a status bar ever need focus? So
I set WM_DISABLED on it, which luckily leaves the font color alone.
I also had to use WM_DISABLED on the Viewport widget that I use for
video output. These two combined let me have my main window with no
keyboard beeping AND allow tab+shift-tab to work as you'd expect on
other windows, so hooray.
Now, at the moment there's no Manifest included, because Microsoft for
some reason includes the processorArcitecture in the file. So I can't
use the same manifest for 32-bit and 64-bit mode, or the binary will
crash on one or the other. Fuck. So the status bar may look old-school
or something, whatever, it's only temporary.
Next up, my goal is to avoid the hiro icon corruption bullshit by making
phoenix itself try and use an internal resource icon. So just compile
your app with that resource icon and voila, perfect icon. Not in there
yet so you get the white box.
Input is hard-coded, up/down/left/right/z/x/a/s/d/c/apostrophe/return.
Lastly, compilation is ... in a serious state of flux. The code is set
to compile bsnes/phoenix-gtk right now. Try it at your own risk. Give me
a few WIPs to get everything nice and refined. Ubuntu users will need
gcc-4.5, which you can get by adding the Maverick Meerkat repository,
updating apt, installing the gcc-4.5 + g++-4.5 packages, and then
removing and re-updating your apt/sources.list file so you don't end up
fucking your whole system when you run apt again in the future.
For anyone who can work with all of that, great! Please post a framerate
comparison between 32-bit and 64-bit builds. Any game, any screen, so
long as the FPS is not fluctuating when you measure it (eg don't do it
during an attract sequence.)
If anyone complains about the 64-bit binary not working and it turns out
they are on 32-bit Windows, they are going to be removed from this WIP
forum :P
byuu says:
This hopefully fixes vertical and horizontal mosaic with the accurate
S-PPU core.
It also adds frame-skipping support to the compatibility and performance
S-PPU cores. This is not visible to the user interface, because I feel
that virtually nobody is going to play with frame-skipping on when they
could use a faster emulation with it off. However, I did use it to
enhance the 'Fast Forward' key. When you press it, it will now turn off
video and audio sync, and set a frameskip of 9. This allows you to speed
things up an additional ~60% over your max theoretical speed without
frameskipping. ~35% with the compatible core, because the PPU is less of
a bottleneck for it. Slowdown was improved, it will turn on audio sync
if it is off until you release the key to ensure you actually get 30fps.
Eventually it'd probably be wise to set a cap on the fast forward speed,
but I hardly think it's an issue on today's computers.
byuu says:
Testing this one and all the new features would be appreciated.
New features?
http://img203.imageshack.us/img203/505/bsnes20100907.jpg
[For future reference, the above URL points to a screenshot of bsnes' Qt
GUI running with the following windows (apart from the main window) visible:
- A new 'state selection' dialog wih buttons labelled 'Slot 1' through
'Slot 10'.
- The 'Tools' dialog open to a new 'Effect Toggle' tab, which has
checkboxes for the various PPU backgrounds and sprites, and SPU
channels.
- The 'Configuration Settings' dialog open to the 'Advanced' tab, with
a "Use Native OS File Dialogs" checkbox.
- A 'Load Cartridge' dialog, which is the standard Windows file-open
dialog.
It seems these are the new features referred to. -- Ed]
byuu says:
This adds a new "Effect Toggle" window to the tools tab list. There's no
menu entry for it yet, oversight, but you can go to another tool and tab
to it.
The effect toggle window lets you toggle background/OAM layers on
a per-priority basis and DSP sound channels. This only works with the
compatibility and performance cores, because I'm not going to allow
accuracy-violating hacks like that into the core.
Non-essential icons have been removed, there's six of them left at the
moment. I am too much of a consistency guy to only have some scattered
around. I know other apps do that, but I'm not going to do that, and
I grow tired of trying to hammer in icons that don't really represent
the actions. Anyway, it still looks pretty good I think.
byuu says:
Holy hell, that was a total brain twister. After hours of crazy bit
twiddling and debug printf's, I finally figured out how to allow both
lores and hires scrolling in the accurate PPU renderer. In the process,
I modified the main loop to run from -7 to 255, regardless of the hires
setting, and perform X adjustment inside the tile fetching. This fixed
a strange main/subscreen misalignment issue, so I was able to restore
the proper sub-then-main rendering for the final screen output stage.
Code looks a good bit cleaner this way overall.
I also added load state and save state menus to the tools menu, so you
can use the menubar to load and save to ten slots. I am thinking that
I should nuke the icons. As pretty as they are, it's getting tiresome
trying to find icons for everything, I have no pictures to represent
loading or saving a slot, nor to represent individual slots. I'll just
stick to radios and checkboxes.
byuu says:
Bug-fix night for the new PPUs.
Accuracy:
Fixed BG palette clamping, which fixes Taz-Mania.
Added blocking for CGRAM writes during active display, to match the
compatibility core. It really should override to the last fetched
palette color, I'll probably try that out soon enough.
Performance:
Mosaic should match the other renderers. Unfortunately, as suspected, it
murders speed. 290->275fps. It's now only 11fps faster, hardly worth it
at all. But the old rendering code is really awful, so maybe it's for
the best it gets refreshed.
It's really tough to understand why this is such a performance hit, it's
just a decrement+compare check four times per pixel. But yeah, it hits
it really, really hard.
Fixed a missing check in Mode4 offset-per-tile, fixes vertical alignment
of a test image in the SNES Test Program.
(there was no r11 release posted to the WIP thread)
byuu says:
This took ten hours of mind boggling insanity to pull off.
It upgrades the S-PPU dot-based renderer to fetch one tile, and then
output all of its pixels before fetching again. It sounds easy enough,
but it's insanely difficult. I ended up taking one small shortcut, in
that rather than fetch at -7, I fetch at the first instance where a tile
is needed to plot to x=0. So if you have {-3 to +4 } as a tile, it
fetches at -3. That won't work so well on hardware, if two BGs fetch at
the same X offset, they won't have time.
I have had no luck staggering the reads at BG1=-7, BG3=-5, etc. While
I can shift and fetch just fine, what happens is that when a new tile is
fetched in, that gives a new palette, priority, etc; and this ends up
happening between two tiles which results in the right-most edges of the
screen ending up with the wrong colors and such.
Offset-per-tile is cheap as always. Although looking at it, I'm not sure
how BG3 could pre-fetch, especially with the way one or two OPT modes
can fetch two tiles.
There's no magic in Hoffset caching yet, so the SMW1 pixel issue is
still there.
Mode 7 got a bugfix, it was off-by-one horizontally from the mosaic
code. After re-designing the BG mosaic, I ended up needing a separate
mosaic for Mode7, and in the process I fixed that bug. The obvious
change is that the Chrono Trigger Mode7->Mode2 transition doesn't cause
the pendulum to jump anymore.
Windows were simplified just a tad. The range testing is shared for all
modes now. Ironically, it's a bit slower, but I'll take less code over
more speed for the accuracy core.
Speaking of speed, because there's so much less calculations per pixel
for BGs, performance for the entire emulator has gone up by 30% in the
accuracy core. Pretty neat overall, I can maintain 60fps in all but,
yeah you can guess can't you?
(there was no r09 release posted to the WIP thread)
byuu says:
It is feature-complete, but horizontal mosaic is less accurate. I have
an idea for a mosaic color ring buffer to get it equally accurate, but
I haven't implemented it yet. For now it's just a simple x & ~(mosaic >>
1) trick that is passable.
Hires blending was left out, as it's more processor intensive and
blargg's NTSC does a better job with that anyway.
There's some OPT vertical positioning issues in the SNES Test Program's
character test; Goodbye, Anthrox has some sort of fast CPU DMA issue;
etc.
Total speedup is a mere 13.5%. Not quite the 50% I wanted in the best
case, but I'll take what I can get.
254->289fps in Zelda 3 on my E8400 now. There's another 15% hiding with
blargg's SMP and 5-10% with blargg's fast DSP, but they lose too much
accuracy. It'd put me at or below Snes9X accuracy, while still being 50%
slower.
SSE2 was performing worse this time, both on x86 and amd64, so I left
that optimization off.
So, barring a miracle, this is about the best it's going to get.
byuu says:
This gets the basic new PPU skeleton up and running, still missing
a lot:
- Mode7
- direct color mode
- OAM color exemption (this one will impact performance negatively)
- vertical mosaic
- horizontal mosaic (this one may impact performance negatively)
- offset per tile
- interlace
- hires
- pseudo-hires
But it's correct enough to play most games okay.
So far, the new PPU is about 11% faster on my Atom, and 17% faster on my
E8400. I was hoping for more, but the window masking and sprite
calculation is just kicking my ass.
The 11/17 figure is total emulator overhead, so that means raw PPU vs
PPU, the new one is at least 22-34% faster than the old one.
I don't really have any ideas for additional optimizations. I'm even
using little-endian word reads where applicable. But at any rate, I need
to get all the above implemented correctly before trying to push
optimizations even further.
(there was no r06 release posted to the WIP thread)
byuu says:
New PPU renderer is coming along. Lots of new ideas, especially with
regards to the way the background renders in tiles rather than in
pixels. That skips the need for tile caching and compares, and it even
gets scrolling right.
The sprite item+tile lists are computing, but they are not rendering
yet.
It's a good deal faster for now, obviously, because 90% of the PPU
features are missing.
byuu says:
Started over again on the new S-PPU, heh. Three hours wasted last night
I guess.
I wanted to make the new one more like the accurate core in its
structure: multiple class instances for each background. It makes the
code easier to read, results in less structure insanity
(regs.main_enabled[bg] -> main_enabled), and will probably make it a tad
easier to parallelize if we want to go that route eg for the ARM.
Still very incomplete.
(there was no r03 release posted to the WIP thread)
byuu says:
This should provide hardware-accurate mosaic support in the accurate
renderer, with the exception that I'm still not sure what mid-frame
vertical mosaic or mid-scanline horizontal mosaic writes do. Either the
code I have is correct, or it bypasses the mosaic adjust and gives the
exact H/V positions.
I've also renamed the fast folder to alternative (thinking about naming
it simply alt instead), and started on a brand new PPU renderer. So far
it's just a barebones setup with some MMIO support and VRAM/OAM/CGRAM
writing. I'm not even confident that I can get this to be faster than
the current scanline renderer, but it's the only avenue that we have
left for any kind of significant bsnes speedup, so I have to try. I'm
going to finish up the MMIO stuff first, that way we have a clean slate
with no actual rendering. And then from here we can try various
different approaches.
byuu says:
This adds mosaic improvements to the S-PPU dot renderer. Specifically,
it eliminates the mosaic_table entirely, and performs mosaic adjustment
per pixel instead. It also moves from a mosaic countdown for mosaic Y to
a mosaic counter (incrementing).
In the process, I realized Sim Earth's map was broken, so I fixed that.
In doing so, I also fixed my old Mode7 demo that was always off-by-one,
causing different results on real hardware versus emulation. But then
I broke both Final Fantasy 5 and Air Strike Patrol effects that use
Mode7 but no mosaic.
I'm not really sure what's going on, but I think I am close. This is the
first time I can reproduce the Mode7 test ROM results without screwing
with M7Y which was obviously wrong. I think that somehow a mosaic >=
1 is glitching the Ycounter for the BG layers to tick one extra time.
There's a workaround that's not very nice to get everything going right
now. It could very well be that the workaround is hardware accurate, but
I can't help but feel there's a more eloquent way of doing this.
byuu says:
This adds RTS/CTS support to the serial communications emulation. Okay,
well the PC acts as if it is always ready, because it always is even on
the real thing, but the PC-waiting-for-SNES side works.
Source only, hardware communication only works on OS X and Linux
(Windows serial communication is totally different, I don't feel like
writing a Windows version), more documentation will come later.
byuu describes the changes since v067:
This release officially introduces the accuracy and performance cores,
alongside the previously-existing compatibility core. The accuracy core
allows the most accurate SNES emulation ever seen, with every last
processor running at the lowest possible clock synchronization level.
The performance core allows slower computers the chance to finally use
bsnes. It is capable of attaining 60fps in standard games even on an
entry-level Intel Atom processor, commonly found in netbooks.
The accuracy core is absolutely not meant for casual gaming at all. It
is meant solely for getting as close to 100% perfection as possible, no
matter the cost to speed. It should only be used for testing,
development or debugging.
The compatibility core is identical to bsnes v067 and earlier, but is
now roughly 10% faster. This is the default and recommended core for
casual gaming.
The performance core contains an entirely new S-CPU core, with
range-tested IRQs; and uses blargg's heavily-optimized S-DSP core
directly. Although there are very minor accuracy tradeoffs to increase
speed, I am confident that the performance core is still more accurate
and compatible than any other SNES emulator. The S-CPU, S-SMP, S-DSP,
SuperFX and SA-1 processors are all clock-based, just as in the accuracy
and compatibility cores; and as always, there are zero game-specific
hacks. Its compatibility is still well above 99%, running even the most
challenging games flawlessly.
If you have held off from using bsnes in the past due to its system
requirements, please give the performance core a try. I think you will
be impressed. I'm also not finished: I believe performance can be
increased even further.
I would also strongly suggest Windows Vista and Windows 7 users to take
advantage of the new XAudio2 driver by OV2. Not only does it give you
a performance boost, it also lowers latency and provides better sound by
way of skipping an API emulation layer.
Changelog:
- Split core into three profiles: accuracy, compatibility and
performance
- Accuracy core now takes advantage of variable-bitlength integers (eg
uint24_t)
- Performance core uses a new S-CPU core, written from scratch for speed
- Performance core uses blargg's snes_dsp library for S-DSP emulation
- Binaries are now compiled using GCC 4.5
- Added a workaround in the SA-1 core for a bug in GCC 4.5+
- The clock-based S-PPU renderer has greatly improved OAM emulation;
fixing Winter Gold and Megalomania rendering issues
- Corrected pseudo-hires color math in the clock-based S-PPU renderer;
fixing Super Buster Bros backgrounds
- Fixed a clamping bug in the Cx4 16-bit triangle operation [Jonas
Quinn]; fixing Mega Man X2 "gained weapon" star background effect
- Updated video renderer to properly handle mixed-resolution screens
with interlace enabled; fixing Air Strike Patrol level briefing screen
- Added mightymo's 2010-08-19 cheat code pack
- Windows port: added XAudio2 output support [OV2]
- Source: major code restructuring; virtual base classes for processor
- cores removed, build system heavily modified, etc.
byuu says:
Re-added blargg's DSP, but this time I merged only spc_dsp and also
fixed the initial regs for Dual Orb II. Which restores the 5-10% speedup
on the compatibility and performance cores. Fixed the initial register
values for the fast CPU core, which fixes Armored Police and the other
Atlus game's title screen in the performance core. Added a missing
debugvirtual prefix to op_step, which fixes CPU stepping in the
performance core. I was using the description field for profile
identification in savestates, but that was of course the description for
the state manager. Whoops. Added a new field for profile name to the
save states, and fixed the state manager to work with that change.
Adjusted the about screen colors, which is how you can tell which core
you're using without it being annoying. Probably did some other stuff
too, meh.
byuu says:
Removed snes_spc, and the fast/smp + fast/dsp wrappers around it.
Cloned dsp to fast/dsp, and re-added the state machine, affects
Compatibility and Performance cores.
Added debugger support to fast/cpu, with full properties list and Qt
debugger functionality.
Rewrote all debugger property functions to return data directly:
- this avoids some annoying conflicts where ChipDebugger::foo()
overshadows Chip::foo()
- this removes the need for an extra 20-200 functions per debugger
core
- this makes the overall code size a good bit smaller
- this currently makes PPU::oam_basesize() inaccessible, so the OAM
viewer will show wrong sprite sizes
Used an evil trick to simplify MMIO read/write address decoding:
- MMIO *mmio[0x8000], where only 0x2000-5fff are used, allows direct
indexing without -0x2000 adjust
So end result: both save states and debugger support work on all three
cores now. Dual Orb II sound is fixed. The speed hit was worse than
I thought, -7% for compatibility, and -10% for performance. At this
point, the compatibility core is the exact same code and speed as v067
official, and the performance core is now only ~36-40% faster than the
compatibility core. Sigh, so much for my dream of using this on my
netbook. At 53fps average now, compared to 39fps before. Profiling will
only get that to ~58fps, and that's way too low for the more intensive
scenes (Zelda 3 rain, CT black omen, etc.)
It would probably be a good idea to find out why my DSP is so much
slower than blargg's, given that it's based upon the same code. The
simple ring buffer stuff can't possibly slow things down that much.
More precisely, it would probably be best to leave blargg's DSP in the
performance core since it's a pretty minor issue, but then I'd have to
have three DSPs: accuracy=threaded, compatibility=state-machine,
performance=blargg. Too much hassle.
Only code in the core emulator now that wasn't at the very least
rewritten for bsnes would be the DSP-3 and DSP-4 modules, which are
really, really lazily done #define hacks around the original C code.
byuu says:
Fixed bsnes launcher on Windows XP
Fixed Windows bsnes launcher internationalization support (emulator can
be in a folder with spaces and Japanese characters, and you can drag
a Japanese file name onto the launcher, and it will load it properly)
Moved fast CPU to use a switch table for MMIO, unfortunately for no
speed gain
Bus::read/write take uint24 parameters for address, luckily no speed
penalty
MMIOAccess gained a handle() function, and hid the mmio[] table. Makes
hooking it cleaner
Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0
error
Fixed a fairly large bug in the fast CPU IRQ handler, which fixes
Robocop et al
Forgot to bump revision to .24 in the compiled binaries, too lazy to
recompile or hex edit to change them
Unfortunately, in order to add nice battery usage, I have to add the
sleep calls to the video and audio wait loops. But they don't know
anything about the GUI and its settings, nor do I really want to make
them know about this setting. I do not want to force allow it. Even with
the media timer trick, Sleep(0) makes Vsync+Async fail a lot more
frequently than never sleeping at all. I would rather laptop users
suffer 100% utilization of a single core than for all users to not be
able to get good audio+video sync. Not sure what to do about that, so
I'll probably just remove the battery usage comment from performance
mode for now.
byuu says:
Added missing $4200 IRQ lock, which fixes Chou Aniki on the fast CPU
core, so slower PCs can get their brotherly love on.
Added range-based controller IOBit latching to the fast CPU core, which
enables Super Scope and Justifier support. Uses the priority queue as
well, so there is zero speed-hit. Given the way range-testing works, the
trigger point may vary by 1-2 pixels when firing at the same spot. Not
really a big deal when it avoids a massive speed penalty.
Fixed PAL and interlace-mode HVIRQs at V=0,H<2 on the fast CPU core.
Added the dot-renderer's sprite list update-on-OAM-write functionality
to the scanline-based PPU renderer. Unfortunately it looks like all the
speed gain was already taken from the global dirty flag I was using
before, but this certainly won't hurt speed any, so whatever.
Added #ifdef to stop CoInitialize(0) on non-Windows ports.
Added #ifdefs to stop gradient fade on Windows port. Not going to fuck
over the Linux port aesthetic because of Qt bug #47,326,927. If there's
a way to tell what Qt theme is being used, I can leave it enabled for
XP/Vista themes.
Moved HDMA trigger from 1104 to 1112, and reduced channel overhead from
24 to 16, to better simulate one-cycle DMA->CPU sync.
Code clarity: I've re-added my varint.hpp classes, and am actively using
them in the accuracy cores. So far, I haven't done anything that would
detriment speed, but it is certainly cool. The APU ports exposed by the
CPU and SMP now take uint2 address arguments, the CPU WRAM address
register is a uint17, and the IRQ H/VTIME values are uint10. This
basically allows the source to clearly convey the data sizes, and
eliminates the need to manually mask values when writing to registers or
reading from memory. I'm going to be doing this everywhere, and it will
have a speed impact eventually, because the automation means we can't
skip masks when we know the data is already masked off.
Source: archive contains the launcher code, so that I can look into why
it's crashing on XP tomorrow.
It doesn't look like Circuit USA's flags are going to work too well with
this new CPU core. Still not sure what the hell Robocop vs The
Terminator is doing, I'll read through the mega SNES thread for clues
tomorrow. Speedy Gonzales is definitely broken, as modifying the MDR was
breaking things with my current core. Probably because the new CPU core
doesn't wait for a cycle edge to trigger.
I was thinking that perhaps we could keep some form of cheat codes list
to work as game-specific hacks for the performance core. Keeps the hacks
out of the emulator, but could allow the remaining bugs to be worked
around for people who have no choice but to use the performance core.
byuu says:
Added OV2's XAudio2 driver (it's better and faster than the DirectSound
one)
Fixed DirectInput keypad number codes
Added launcher to make the profiles work
Profiles now called: Accuracy, Compatibility, Performance (not debating
names anymore)
The launcher isn't going to work on OS X because of the .app folder
bullshit (yes, yes, .sfc folders.)
It also crashes on Windows XP for god only knows what reason. Works fine
on Windows 7 and Linux. So XP users, rename the .dll files to .exe to
test this release. I'll fix it on Monday.
The color highlighting fucks up the radio boxes on the Windows classic
theme, because Nokia can't afford a god damn QA team.
Lastly, I forgot to add launcher to the make archive-all command, so the
source for it will be in the next WIP.
byuu says:
This moves toward a profile-selection mode. Right now, it is incomplete.
There are three binaries, one for each profile. The GUI selection
doesn't actually do anything yet. There will be a launcher in a future
release that loads each profile's respective binary.
I reverted away from blargg's SMP library for the time being, in favor
of my own. This will fix most of the csnes/bsnes-performance bugs. This
causes a 10% speed hit on 64-bit platforms, and a 15% speed hit on
32-bit platforms. I hope to be able to regain that speed in the future,
I may also experiment with creating my own fast-SMP core which drops bus
hold delays and TEST register support (never used by anything, ever.)
Save states now work in all three cores, but they are not
cross-compatible. The profile name is stored in the description field of
the save states, and it won't load a state if the profile name doesn't
match.
The debugger only works on the research target for now. Give it time and
it will return for the other targets.
Other than that, let's please resume testing on all three once again.
See how far we get this time :)
I can confirm the following games have issues on the performance
profile:
- Armored Police Metal Jacket (minor logo flickering, not a big deal)
- Chou Aniki (won't start, so obviously unplayable)
- Robocop vs The Terminator (major in-game flickering, unplayable)
Anyone still have that gigantic bsnes thread archive from the ZSNES
forum? Maybe I posted about how to fix those two broken games in there,
heh.
I really want to release this as v1.0, but my better judgment says we
need to give it another week. Damn.
byuu says:
Since we're now talking about three splits, that's getting a bit out of
hand.
This WIP combines everything back into one project again. Added the
src/fast folder that has all the speed-oriented cores.
A slight slowdown to csnes from what it was before, I'm using blargg's
accurate DSP. I just don't like the idea of releasing a less accurate
DSP core than Snes9X v1.52 has. Plus the fast DSP core doesn't serialize
yet.
I moved back to snes_spc 0.9.0 because I care more about Tales and Star
Ocean than I do about Earthworm Jim 2. So if you try EWJ2 on csnes,
expect it to sound like it does on Snes9X. In other words, don't wear
headphones if you value your hearing.
The middle-of-the-road bsnes core uses blargg's accurate DSP, because
it's about 3% faster than mine which removes all of blargg's
optimizations. There is absolutely no accuracy loss here. bsnes v067.20
that is included should be equal to v067 official.
Performance:
Code:
asnes = 58fps
bsnes = 172fps +2.97x
csnes = 274fps +1.59x +4.72x
The binaries are not profiled, so that's an additional 15% slower from
the previous builds.
Save states only work on asnes, as I don't know how to serialize
blargg's cores yet. The copy_func thing is very confusing to me for some
reason. The debugger won't work anywhere.
Outside of that, please go ahead and bug test. Once I get the debugger
and save states working, I'll build some profiled v1.0 releases for all
three, and we can test that for a bit and then release.
byuu says:
12-15% faster than v067.10, and my Atom never goes below 58fps for
normal lo-res games at this point. Just a little more and I can leave
Async on. That's pretty much it though for the low hanging fruit.
Everything else will be a lot of work for a little gain. Speedups are
from range testing across scanline boundaries and from using blargg's
fast DSP core.
Snes9X is now only 1.93x faster than bsnes, and bsnes is now faster than
Super Sleuth.
I also fixed the Circuit USA menus (HDMA timing adjustment), Wild Guns
flickering (IRQ lock) and Jumpin' Derby (external IRQ triggering.)
There's definitely a lot of troublesome games, mostly the same ones we
had in the past (Koushien 2, Robocop vs The Terminator, etc.) I'm
definitely going to debug Starfox, but I may not bother with some of the
more obscure ones.
byuu says:
I wrote a new CPU core from scratch. It has range-based IRQs, and is
good enough even to run F-1 Grand Prix and Sink or Swim. It also uses
a binary min-heap array for the timing priority queue. This resulted in
a ~40% speedup.
I also added in blargg's snes_spc library, which is an S-SMP + S-DSP
emulator. I am still using his accurate DSP core, and not the fast one.
This gives an additional ~10% speedup.
THIS IS NOT PERFECT, THERE WILL BE BUGS!
I already know that Tales of Phantasia and Star Ocean are hitting some
edge cases. Now that it's fast enough, hopefully blargg can take a look
at it. Something he couldn't test before because you can't rip SPCs of
these games, so it's probably something simple.
My CPU core also doesn't nail every last possible edge case. So things
like Wild Guns and the two or three games that rely on NMI/IRQ hold
aren't going to work ... yet. Be patient.
The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt
compatibility to reduce their precision a bit.
End result is that you can now get well over 60fps in normal games even
n a first-generation Intel Atom.
byuu says:
This adds some sync.sh improvements to make it handle errors more
gracefully.
It also updates asnes a good bit. All of the four base processors now
have all publicly accessible functions right at the top of the main
headers, and everything else is private. This is to allow these headers
to essentially take the place of the previous base classes in the old
bsnes-merged format. So if there's something public there, you need to
implement that exact function to make your own module.
I removed the frame counter from the PPU, as it has nothing to do with
emulation. That now resides inside the Qt -> SNES interface code. Quite
amazing, I was actually saving the frame counter into the save state
files before, yuck.
Removed some baggage in the System class: it was friending a bunch of
long-dead functions and classes.
Forgot to re-add the CHEAT_SYSTEM define to info.hpp, so that's been put
back.
byuu says:
This fixes libsnes and debugger builds, and collapses bsnes/ppu/bppu to
bsnes/ppu and bsnes/dsp/sdsp to bsnes/dsp. It also introduces
bsnes/sync.sh, which will synchronize all of asnes/ with bsnes/,
excepting the custom speed-focused modules. So far, that's bsnes/ppu
(scanline renderer) and bsnes/dsp (state machine.)
Should make keeping the two ports in sync much, much easier. It's
basically the same thing as before, only you run sync.sh and have a few
duplicated folders now. May make it clearer by creating a stub/ or src/
folder inside bsnes to do all of the copying, so that you only see the
custom folders in bsnes/' root directory.
about:Report an issue running a specific game in ares
title:"[system] Game"
labels:bug
assignees:''
---
Before submitting an issue, please use the search to make sure an issue doesn't already exist, you should also make sure your rom is not a bad dump, by comparing against the hashes in the No-Intro (Cartridges) or Redump (CD-ROM) databases.
**Describe the issue**
A clear and concise description of what the bug is.
**Rom Information**
Specify the impacted rom filename and any associated hashes (sha256 preferred);.
The easiest way to do this is to open the game in ares, and go to "Tools -> Manifest" and copy/paste the contents.
**ares** is a multi-system emulator that began development on October 14th, 2004.
It is a descendant of [higan](https://github.com/higan-emu/higan) and [bsnes](https://github.com/bsnes-emu/bsnes/), and focuses on accuracy and preservation.
It's worth noting that ares takes some uncommon design approaches that essentially trade speed for code clarity. We avoid state machines and bitmasks (when possible). Most cores end up being half the amount of code, but slower. The code is clearer and less spaghettified, especially for systems with lots of processors. C bitfields being non-portable incurs a speedhit. Windows also has a speedhit over Linux due to its ABI needing more instructions to switch contexts.
Official Releases
-----------------
Official releases are available from
[the ares website](https://ares-emu.net).
Nightly Builds
--------------
Automated, untested builds of ares are available for Windows and macOS as a [pre-release](https://github.com/ares-emulator/ares/releases/tag/nightly).
Only the latest nightly build is kept.
Building ares
-------------
ares supports building on Windows, macOS, and various Linux/BSD distributions. See build instructions for:
Loaded 100 of 4300 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Luke Usher
