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
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.
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)
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.
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)).
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 <luke.usher@outlook.com>
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.
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".
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).
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 <luke@usher.cc>
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
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.
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.
曾耿森