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