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.
Tim Allen