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.
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.
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.
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.
- 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
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.
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.
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.
- 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
Luke Usher