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.
Lior Halphon