mirror of https://github.com/bsnes-emu/bsnes.git
14 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
Tim Allen
|
6524a7181d |
Update to v104r15 release.
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.
|
|
|
Tim Allen
|
fbc58c70ae |
Update to v104r14 release.
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
|
|
|
Tim Allen
|
9c25f128f9 |
Update to v104r07 release.
byuu says:
Changelog:
- md/vdp: added VIP bit to status register; fixes Cliffhanger
- processor/m68k/disassembler: added modes 7 and 8 to LEA address
disassembly
- processor/m68k/disassembler: enhanced ILLEGAL to display LINEA/LINEF
$xxx variants
- processor/m68k: ILLEGAL/LINEA/LINEF do not modify the stack
register; fixes Caeser no Yabou II
- icarus/sfc: request sgb1.boot.rom and sgb2.boot.rom separately; as
they are different
- icarus/sfc: removed support for external firmware when loading ROM
images
The hack to run Mega Drive Ballz 3D isn't in place, as I don't know if
it's correct, and the graphics were corrupted anyway.
The SGB boot ROM change is going to require updating the icarus database
as well. I will add that in when I start dumping more cartridges here
soon.
Finally ... I explained this already, but I'll do so here as well: I
removed icarus' support for loading SNES coprocessor firmware games with
external firmware files (eg dsp1.program.rom + dsp1.data.rom in the same
path as supermariokart.sfc, for example.)
I realize most are going to see this as an antagonizing/stubborn move
given the recent No-Intro discussion, and I won't deny that said thread
is why this came to the forefront of my mind. But on my word, I honestly
believe this was an ineffective solution for many reasons not related to
our disagreements:
1. No-Intro distributes SNES coprocessor firmware as a merged file, eg
"DSP1 (World).zip/DSP1 (World).bin" -- icarus can't possibly know
about every ROM distribution set's naming conventions for firmware.
(Right now, it appears GoodSNES and NSRT are mostly dead; but there
may be more DATs in the future -- including my own.)
2. Even if the user obtains the firmware and tries to rename it, it
won't work: icarus parses manifests generated by the heuristics
module and sees two ROM files: dsp1.program.rom and dsp1.data.rom.
icarus cannot identify a file named dsp1.rom as containing both
of these sub-files. Users are going to have to know how to split
files, which there is no way to do on stock Windows. Merging files,
however, can be done via `copy /b supermariokart.sfc+dsp1.rom
supermariokartdsp.sfc`; - and dsp1.rom can be named whatever now.
I am not saying this will be easy for the average user, but it's
easier than splitting files.
3. Separate firmware breaks icarus' database lookup. If you have
pilotwings.sfc but without firmware, icarus will not find a match
for it in the database lookup phase. It will then fall back on
heuristics. The heuristics will pick DSP1B for compatibility with
Ballz 3D which requires it. And so it will try to pull in the
wrong firmware, and the game's intro will not work correctly.
Furthermore, the database information will be unavailable, resulting
in inaccurate mirroring.
So for these reasons, I have removed said support. You must now load
SNES coprocessor games into higan in one of two ways: 1) game paks with
split files; or 2) SFC images with merged firmware.
If and when No-Intro deploys a method I can actually use, I give you all
my word I will give it a fair shot and if it's reasonable, I'll support
it in icarus.
|
|
|
Tim Allen
|
186f008574 |
Update to v102r03 release.
byuu says: Changelog: - PCE: split VCE from VDC - HuC6280: changed bus from (uint21 addr) to (uint8 bank, uint13 addr) - added SuperGrafx emulation (adds secondary VDC, plus new VPC) The VDC now has no concept of the actual display raster timing, and instead is driven by Vpulse (start of frame) and Hpulse (start of scanline) signals from the VCE. One still can't render the start of the next scanline onto the current scanline through overly aggressive timings, but it shouldn't be too much more difficult to allow that to occur now. This process incurs quite a major speed hit, so low-end systems with Atom CPUs can't run things at 60fps anymore. The timing needs a lot of work. The pixels end up very jagged if the VCE doesn't output batches of 2-4 pixels at a time. But this should not be a requirement at all, so I'm not sure what's going wrong there. Yo, Bro and the 512-width mode of TV Sports Basketball is now broken as a result of these changes, and I'm not sure why. To load SuperGrafx games, you're going to have to change the .pce extensions to .sg or .sgx. Or you can manually move the games from the PC Engine folder to the SuperGrafx folder and change the game folder extensions. I have no way to tell the games apart. Mednafen uses CRC32 comparisons, and I may consider that since there's only five games, but I'm not sure yet. The only SuperGrafx game that's playable right now is Aldynes. And the priorities are all screwed up. I don't understand how the windows or the priorities work at all from sgxtech.txt, so ... yeah. It's pretty broken, but it's a start. I could really use some help with this, as I'm very lost right now with rendering :/ ----- Note that the SuperGrafx is technically its own system, it's not an add-on. As such, I'm giving it a separate .sys folder, and a separate library. There's debate over how to name this thing. "SuperGrafx" appears more popular than "Super Grafx". And you might also call it the "PC Engine SuperGrafx", but I decided to leave off the prefix so it appears more distinct. |
|
|
Tim Allen
|
0ad70a30f8 |
Update to v101r30 release.
byuu says:
Changelog:
- SMS: added cartridge ROM/RAM mirroring (fixes Alex Kidd)
- SMS: fixed 8x16 sprite mode (fixes Wonder Boy, Ys graphics)
- Z80: emulated "ex (sp),hl" instruction
- Z80: fixed INx NF (should be set instead of cleared)
- Z80: fixed loop condition check for CPxR, INxR, LDxR, OTxR (fixes
walking in Wonder Boy)
- SFC: removed Debugger and sfc/debugger.hpp
- icarus: connected MS, GG, MD importing to the scan dialog
- PCE: added emulation skeleton to higan and icarus
At this point, Master System games are fairly highly compatible, sans
audio. Game Gear games are running, but I need to crop the resolution
and support the higher color palette that they can utilize. It's really
something else the way they handled the resolution shrink on that thing.
The last change is obviously going to be the biggest news.
I'm very well aware it's not an ideal time to start on a new emulation
core, with the MS and MD cores only just now coming to life with no
audio support.
But, for whatever reason, my heart's really set on working on the PC
Engine. I wanted to write the final higan skeleton core, and get things
ready so that whenever I'm in the mood to work on the PCE, I can do so.
The skeleton is far and away the most tedious and obnoxious part of the
emulator development, because it's basically all just lots of
boilerplate templated code, lots of new files to create, etc.
I really don't know how things are going to proceed ... but I can say
with 99.9% certainty that this will be the final brand new core ever
added to higan -- at least one written by me, that is. This was
basically the last system from my childhood that I ever cared about.
It's the last 2D system with games that I really enjoy playing. No other
system is worth dividing my efforts and reducing the quality and amount
of time to work on the systems I have.
In the future, there will be potential for FDS, Mega CD and PCE-CD
support. But those will all be add-ons, and they'll all be really
difficult and challenge the entire design of higan's UI (it's entirely
cartridge-driven at this time.) None of them will be entirely new cores
like this one.
|
|
|
Tim Allen
|
4d2e17f9c0 |
Update to v101r09 release.
byuu says:
Sorry, two WIPs in one day. Got excited and couldn't wait.
Changelog:
- ADDQ, SUBQ shouldn't update flags when targeting an address register
- ADDA should sign extend effective address reads
- JSR was pushing the PC too early
- some improvements to 8-bit register reads on the VDP (still needs
work)
- added H/V counter reads to the VDP IO port region
- icarus: added support for importing Master System and Game Gear ROMs
- tomoko: added library sub-menus for each manufacturer
- still need to sort Game Gear after Mega Drive somehow ...
The sub-menu system actually isn't all that bad. It is indeed a bit more
annoying, but not as annoying as I thought it was going to be. However,
it looks a hell of a lot nicer now.
|
|
|
Tim Allen
|
3dd1aa9c1b |
Update to v100r02 release.
byuu says: Sigh ... I'm really not a good person. I'm inherently selfish. My responsibility and obligation right now is to work on loki, and then on the Tengai Makyou Zero translation, and then on improving the Famicom emulation. And yet ... it's not what I really want to do. That shouldn't matter; I should work on my responsibilities first. Instead, I'm going to be a greedy, self-centered asshole, and work on what I really want to instead. I'm really sorry, guys. I'm sure this will make a few people happy, and probably upset even more people. I'm also making zero guarantees that this ever gets finished. As always, I wish I could keep these things secret, so if I fail / give up, I could just drop it with no shame. But I would have to cut everyone out of the WIP process completely to make it happen. So, here goes ... This WIP adds the initial skeleton for Sega Mega Drive / Genesis emulation. God help us. (minor note: apparently the new extension for Mega Drive games is .md, neat. That's what I chose for the folders too. I thought it was .smd, so that'll be fixed in icarus for the next WIP.) (aside: this is why I wanted to get v100 out. I didn't want this code in a skeleton state in v100's source. Nor did I want really broken emulation, which the first release is sure to be, tarring said release.) ... So, basically, I've been ruminating on the legacy I want to leave behind with higan. 3D systems are just plain out. I'm never going to support them. They're too complex for my abilities, and they would run too slowly with my design style. I'm not willing to compromise my design ideals. And I would never want to play a 3D game system at native 240p/480i resolution ... but 1080p+ upscaling is not accurate, so that's a conflict I want to avoid entirely. It's also never going to emulate computer systems (X68K, PC-98, FM-Towns, etc) because holy shit that would completely destroy me. It's also never going emulate arcade machines. So I think of higan as a collection of 2D emulators for consoles and handhelds. I've gone over every major 2D gaming system there is, looking for ones with games I actually care about and enjoy. And I basically have five of those systems supported already. Looking at the remaining list, I see only three systems left that I have any interest in whatsoever: PC-Engine, Master System, Mega Drive. Again, I'm not in any way committing to emulating any of these, but ... if I had all of those in higan, I think I'd be content to really, truly, finally stop writing more emulators for the rest of my life. And so I decided to tackle the most difficult system first. If I'm successful, the Z80 core should cover a lot of the work on the SMS. And the HuC6280 should land somewhere between the NES and SNES in terms of difficulty ... closer to the NES. The systems that just don't appeal to me at all, which I will never touch, include, but are not limited to: * Atari 2600/5200/7800 * Lynx * Jaguar * Vectrex * Colecovision * Commodore 64 * Neo-Geo * Neo-Geo Pocket / Color * Virtual Boy * Super A'can * 32X * CD-i * etc, etc, etc. And really, even if something were mildly interesting in there ... we have to stop. I can't scale infinitely. I'm already way past my limit, but I'm doing this anyway. Too many cores bloats everything and kills quality on everything. I don't want higan to become MESS v2. I don't know what I'll do about the Famicom Disk System, PC-Engine CD, and Mega CD. I don't think I'll be able to achieve 60fps emulating the Mega CD, even if I tried to. I don't know what's going to happen here with even the Mega Drive. Maybe I'll get driven crazy with the documentation and quit. Maybe it'll end up being too complicated and I'll quit. Maybe the emulation will end up way too slow and I'll give up. Maybe it'll take me seven years to get any games playable at all. Maybe Steve Snake, AamirM and Mike Pavone will pool money to hire a hitman to come after me. Who knows. But this is what I want to do, so ... here goes nothing. |
|
|
Tim Allen
|
0d0af39b44 |
Update to v097r14 release.
byuu says: This is a few days old, but oh well. This WIP changes nall,hiro,ruby,icarus back to (u)int(8,16,32,64)_t. I'm slowly pushing for (u)int(8,16,32,64) to use my custom Integer<Size>/Natural<Size> classes instead. But it's going to be one hell of a struggle to get that into higan. |
|
|
Tim Allen
|
605a8aa3e9 |
Update to v097r05 release.
byuu says: More V30MZ implemented, a lot more to go. icarus now supports importing WS and WSC games. It expects them to have the correct file extension, same for GB and GBC. > Ugh, apparently HiDPI icarus doesn't let you press the check boxes. I set the flag value in the plist to false for now. Forgot to do it for higan, but hopefully I won't forget before release. |
|
|
Tim Allen
|
3414c8c8df |
Update to v096r06 release.
byuu says: This WIP finally achieves the vision I've had for icarus. I also fixed a mapping issue with Cx4 that, oddly enough, only caused the "2" from the Mega Man X2 title screen to disappear. [Editor's note - "the vision for icarus" was described in a separate, public forum post: http://board.byuu.org/phpbb3/viewtopic.php?p=20584 Quoting for posterity: icarus is now a full-fledged part of higan, and will be bundled with each higan WIP as well. This will ensure that in the future, the exact version of icarus you need to run higan will be included right along with it. As of this WIP, physical manifest files are now truly and entirely optional. From now on, you can associate your ROM image files with higan's main binary, or drop them directly on top of it, to load and play your games. Furthermore, there are two new menu options that appear under the library menu when icarus is present: - "Load ROM File ..." => gives you a single-file selection dialog to import (and if possible) run the game - "Import ROM Files ..." => gives you a multi-file import dialog with checkboxes to pull in multiple games at once Finally, as before, icarus can generate manifest.bml files for folders that lack them. For people who like the game folder and library system, nothing's changed. Keep using higan as you have been. For people who hate it, you can now use higan like your classic emulators. Treat the "Library->{System Name}" entries as your "favorites" list: the games you actually play. Treat the "Library->Load ROM" as your standard open file dialog in other emulators. And finally, treat "Advanced->Game Library" as your save data path for cheat codes, save states, save RAM, etc. ] |
|
|
Tim Allen
|
2a4eb1cfc8 |
Update to higan and icarus v095r16 release.
byuu says (in the WIP forum):
Changelog:
- satellaviewcartridge/SatellaviewCartridge is now bsmemory/BSMemory
- Emulation/BS-X Satellaview/ is now Emulation/BS Memory/
- masking is in for MCC's mcu (awful hack in the code, but that's
temporary)
- BS Memory types are now "flash" or "mrom"
- fixed loading Same Game - Tengai Hen
- icarus fixed up a lot; can load database entries for any supported
media type now (only the SFC DB exists currently)
mMenu::remove() fix will be in the next WIP.
byuu says (in the public beta thread):
Changelog:
- GBA emulation accuracy improved quite a bit
- video shaders are supported once again
- icarus shares settings.bml with higan; changing library path in
one now affects the other
- icarus manifest generation now uses my SNES game dumping database
for perfect mapping of US games
- major overhaul to manifest file format. As long as you have
v095-style folders without manifest.bml, you will be fine
- if not, go to higan->settings->configuration->advanced and check
"Ignore Manifests" before loading your first game
- new "Manifest Viewer" tool (not really meant for regular users;
more of a developer tool)
- experimental (but disabled in the binary) WASAPI driver. Help
stabilizing it would be *greatly* appreciated!
- lots of other stuff
|
|
|
Tim Allen
|
bd628de3cf |
Update to higan and icarus v095r15 release.
r13 and r14 weren't posted as individual releases, but their changelogs
were posted.
byuu says about r13:
I'm not going to be posting WIPs for r13 and above for a while.
The reason is that I'm working on the major manifest overhaul I've
discussed previously on the icarus subforum.
I'm recreating my boards database from scratch using the map files
and the new map analyzer. The only games that will load are ones
I've created board definitions for, and updated
sfc/cartridge/markup.cpp to parse. Once I've finished all the
boards, then I'll update the heuristics.
Then finally, I'll sync the syntax changes over to the fc, gb, gba
cores.
Once that's done, I'll start posting WIPs again, along with a new
build of icarus.
But I'll still post changelogs as I work through things.
Changelog (r13):
- preservation: created new database-builder tool (merges
region-specific databases with boards)
- icarus: support new, external database format
(~/.config/icarus/Database/(Super Famicom.bml, ...)
- added 1A3B-(10,11,12); 1A3B-20
byuu says about r14:
r14 work:
I successfully created mappings for every board used in the US set.
I also updated icarus' heuristics to use the new mappings, and
created ones there for the boards that are only in the JP set.
Then I patched icarus to support pulling games out of the database
when it's used on a game folder to generate a manifest file.
Then I updated a lot of code in higan/sfc to support the new mapping
syntax. sfc/cartridge/markup.cpp is about half the size it used to
be with the new mappings, and I was able to kill off both map/id and
map/select entirely.
Then I updated all four emulated systems (and both subsystems) to
use "board" as the root node, and harmonized their syntax (made them
all more consistent with each other.)
Then I added a manifest viewer to the tools window+menu. It's kind
of an advanced user feature, but oh well. No reason to coddle people
when the feature is very useful for developers. The viewer will show
all manifests in order when you load multi-cart games as well.
Still not going to call any syntax 100% done right now, but
thankfully with the new manifest-free folders, nobody will have to
do anything to use the new format. Just download the new version and
go.
The Super Famicom Event stuff is currently broken (CC92/PF94
boards). That's gonna be fun to support.
byuu says about r15:
EDIT: small bug in icarus with heuristics. Edit
core/super-famicom.cpp line 27:
if(/*auto*/ markup = cartridge.markup) {
Gotta remove that "auto" so that it returns valid markup.
Resolved the final concerns I had with the new manifest format.
Right now there are two things that are definitely broken: MCC (BS-X
Town cart) and Event (CC '92 and PF'94).
And there are a few things that are untested: SPC7110, EpsonRTC,
SharpRTC, SDD1+RAM, SufamiTurbo, BS-X slotted carts.
|
|
|
Tim Allen
|
483fc81356 |
Update to v094r44 release.
byuu says: Changelog: - return open bus instead of mirroring addresses on the bus (fixes Mario&Luigi, Minish Cap, etc) [Jonas Quinn] - add boolean flag to load requests for slotted game carts (fixes slot load prompts) - rename BS-X Town cart from psram to ram - icarus: add support for game database Note: I didn't rename "bsx" to "mcc" in the database for icarus before uploading that. But I just fixed it locally, so it'll be in the next WIP. For now, make it create the manifest for you and then rename it yourself. I did fix the PSRAM size to 256kbit. |
|
|
Tim Allen
|
7081f46e45 | Added icarus 20150821. |