2012-03-19 11:19:53 +00:00
|
|
|
#include <gba/gba.hpp>
|
|
|
|
|
2012-04-26 10:51:13 +00:00
|
|
|
namespace GameBoyAdvance {
|
2012-03-19 11:19:53 +00:00
|
|
|
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
#include "mrom.cpp"
|
|
|
|
#include "sram.cpp"
|
2012-04-09 06:19:32 +00:00
|
|
|
#include "eeprom.cpp"
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
#include "flash.cpp"
|
Update to v087r26 release.
byuu says:
Changelog:
- fixed FIFO[1] reset behavior (fixes audio in Sword of Mana)
- added FlashROM emulation (both sizes)
- GBA parses RAM settings from manifest.xml now
- save RAM is written to disk now
- added save state support (it's currently broken, though)
- fixed ROM/RAM access timings
- open bus should mostly work (we don't do the PC+12 stuff yet)
- emulated the undocumented memory control register (mirror IWRAM,
disable I+EWRAM, EWRAM wait state count)
- emulated keypad interrupts
- emulated STOP (freezes video, audio, DMA and timers; only breaks on
keypad IRQs)
- probably a lot more, it was a long night ...
Show stoppers, missing things, broken things, etc:
- ST018 is still completely broken
- GBC audio sequencer apparently needs work
- GBA audio FIFO buffer seems too quiet
- PHI / ROM prefetch needs to be emulated (no idea on how to do this,
especially PHI)
- SOUNDBIAS 64/128/256khz modes should output at that resolution
(really, we need to simulate PWM properly, no idea on how to do this)
- object mosaic top-left coordinates are wrong (minor, fixing will
actually make the effect look worse)
- need to emulate PPU greenswap and color palette distortion (no idea on
how do this)
- need GBA save type database (I would also LIKE to blacklist
/ patch-out trainers, but that's a discussion for another day.)
- some ARM ops advance the prefetch buffer, so you can read PC+12 in
some cases
2012-04-16 12:19:39 +00:00
|
|
|
#include "serialization.cpp"
|
2012-03-19 11:19:53 +00:00
|
|
|
Cartridge cartridge;
|
|
|
|
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
Cartridge::Cartridge() {
|
|
|
|
mrom.data = new uint8[mrom.size = 32 * 1024 * 1024];
|
|
|
|
sram.data = new uint8[sram.size = 32 * 1024];
|
|
|
|
eeprom.data = new uint8[eeprom.size = 8 * 1024];
|
|
|
|
flash.data = new uint8[flash.size = 128 * 1024];
|
|
|
|
}
|
|
|
|
|
|
|
|
Cartridge::~Cartridge() {
|
|
|
|
delete[] mrom.data;
|
|
|
|
delete[] sram.data;
|
|
|
|
delete[] eeprom.data;
|
|
|
|
delete[] flash.data;
|
|
|
|
}
|
|
|
|
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
auto Cartridge::load() -> bool {
|
|
|
|
information = Information();
|
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.
2015-12-19 08:52:34 +00:00
|
|
|
|
2017-01-13 01:15:45 +00:00
|
|
|
if(auto pathID = platform->load(ID::GameBoyAdvance, "Game Boy Advance", "gba")) {
|
Update to v099r08 release.
byuu says:
Changelog:
- nall/vfs work 100% completed; even SGB games load now
- emulation cores now call load() for the base cartridges as well
- updated port/device handling; portmask is gone; device ID bug should
be resolved now
- SNES controller port 1 multitap option was removed
- added support for 128KiB SNES PPU VRAM (for now, edit sfc/ppu/ppu.hpp
VRAM::size=0x10000; to enable)
Overall, nall/vfs was a huge success!! We've substantially reduced
the amount of boilerplate code everywhere, while still allowing (even
easier than before) support for RAM-based game loading/saving. All of
nall/stream is dead and buried.
I am considering removing Emulator::Interface::Medium::id and/or
bootable flag. Or at least, doing something different with it. The
values for the non-bootable GB/BS/ST entries duplicate the ID that is
supposed to be unique. They are for GB/GBC and WS/WSC. Maybe I'll use
this as the hardware revision selection ID, and then gut non-bootable
options. There's really no reason for that to be there. I think at one
point I was using it to generate library tabs for non-bootable systems,
but we don't do that anymore anyway.
Emulator::Interface::load() may not need the required flag anymore ... it
doesn't really do anything right now anyway.
I have a few reasons for having the cores load the base cartridge. Most
importantly, it is going to enable a special mode for the WonderSwan /
WonderSwan Color in the future. If we ever get the IPLROMs dumped ... it's
possible to boot these systems with no games inserted to set user profile
information and such. There are also other systems that may accept being
booted without a cartridge. To reach this state, you would load a game and
then cancel the load dialog. Right now, this results in games not loading.
The second reason is this prevents nasty crashes when loading fails. So
if you're missing a required manifest, the emulator won't die a violent
death anymore. It's able to back out at any point.
The third reason is consistency: loading the base cartridge works the
same as the slot cartridges.
The fourth reason is Emulator::Interface::open(uint pathID)
values. Before, the GB, SB, GBC modes were IDs 1,2,3 respectively. This
complicated things because you had to pass the correct ID. But now
instead, Emulator::Interface::load() returns maybe<uint> that is nothing
when no game is selected, and a pathID for a valid game. And now open()
can take this ID to access this game's folder contents.
The downside, which is temporary, is that command-line loading is
currently broken. But I do intend on restoring it. In fact, I want to do
better than before and allow multi-cart booting from the command-line by
specifying the base cartridge and then slot cartridges. The idea should
be pretty simple: keep a queue of pending filenames that we fill from
the command-line and/or drag-and-drop operations on the main window,
and then empty out the queue or prompt for load dialogs from the UI
when booting a system. This also might be a bit more unorthodox compared
to the traditional emulator design of "loadGame(filename)", but ... oh
well. It's easy enough still.
The port/device changes are fun. We simplified things quite a bit. The
portmask stuff is gone entirely. While ports and devices keep IDs,
this is really just sugar-coating so UIs can use for(auto& port :
emulator->ports) and access port.id; rather than having to use for(auto
n : range(emulator->ports)) { auto& port = emulator->ports[n]; ... };
but they should otherwise generally be identical to the order they appear
in their respective ranges. Still, don't rely on that.
Input::id is gone. There was no point since we also got rid of the nasty
Input::order vector. Since I was in here, I went ahead and caved on the
pedantics and renamed Input::guid to Input::userData.
I removed the SNES controller port 1 multitap option. Basically, the only
game that uses this is N-warp Daisakusen and, no offense to d4s, it's
not really a good game anyway. It's just a quick demo to show 8-players
on the SNES. But in the UI, all it does is confuse people into wasting
time mapping a controller they're never going to use, and they're going
to wonder which port to use. If more compelling use cases for 8-players
comes about, we can reconsider this. I left all the code to support this
in place, so all you have to do is uncomment one line to enable it again.
We now have dsnes emulation! :D
If you change PPU::VRAM::size to 0x10000 (words), then you should now
have 128KiB of VRAM. Even better, it serializes the used-VRAM size,
so your save states shouldn't crash on you if you swap between the two
(though if you try this, you're nuts.)
Note that this option does break commercial software. Yoshi's Island in
particular. This game is setting A15 on some PPU register writes, but
not on others. The end result of this is things break horribly in-game.
Also, this option is causing a very tiny speed hit for obvious reasons
with the variable masking value (I'm even using size-1 for now.) Given
how niche this is, I may just leave it a compile-time constant to avoid
the overhead cost. Otherwise, if we keep the option, then it'll go into
Super Famicom.sys/manifest.bml ... I'll flesh that out in the near-future.
----
Finally, some fun for my OCD ... my monitor suddenly cut out on me
in the middle of working on this WIP, about six hours in of non-stop
work. Had to hit a bunch of ctrl+alt+fN commands (among other things)
and trying to log in headless on another TTY to do issue commands,
trying to recover the display. Finally power cycled the monitor and it
came back up. So all my typing ended up going to who knows where.
Usually this sort of thing terrifies me enough that I scrap a WIP and
start over to ensure I didn't screw anything up during the crashed screen
when hitting keys randomly.
Obviously, everything compiles and appears to work fine. And I know
it's extremely paranoid, but OCD isn't logical, so ... I'm going
to go over every line of the 100KiB r07->r08 diff looking for any
corruption/errors/whatever.
----
Review finished.
r08 diff review notes:
- fc/controller/gamepad/gamepad.cpp:
use uint device = ID::Device::Gamepad; not id = ...;
- gb/cartridge/cartridge.hpp:
remove redundant uint _pathID; (in Information::pathID already)
- gb/cartridge/cartridge.hpp:
pull sha256 inside Information
- sfc/cartridge/load/cpp:
add " - Slot (A,B)" to interface->load("Sufami Turbo"); to be more
descriptive
- sfc/controller/gamepad/gamepad.cpp:
use uint device = ID::Device::Gamepad; not id = ...;
- sfc/interface/interface.cpp:
remove n variable from the Multitap device input generation loop
(now unused)
- sfc/interface/interface.hpp:
put struct Port above struct Device like the other classes
- ui-tomoko:
cheats.bml is reading from/writing to mediumPaths(0) [system folder
instead of game folder]
- ui-tomoko:
instead of mediumPaths(1) - call emulator->metadataPathID() or something
like that
2016-06-24 12:16:53 +00:00
|
|
|
information.pathID = pathID();
|
|
|
|
} else return false;
|
|
|
|
|
2017-01-13 01:15:45 +00:00
|
|
|
if(auto fp = platform->open(pathID(), "manifest.bml", File::Read, File::Required)) {
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
information.manifest = fp->reads();
|
|
|
|
} else return false;
|
2013-01-21 12:27:15 +00:00
|
|
|
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
auto document = BML::unserialize(information.manifest);
|
Update to higan v091r14 and ananke v00r03 releases.
byuu says:
higan changelog:
- generates title displayed in emulator window by asking the core
- core builds title solely from "information/title" ... if it's not
there, you don't get a title at all
- sub-system load menu is gone ... since there are multiple revisions of
the SGB, this never really worked well anyway
- to load an SGB, BS-X or ST cartridge, load the base cartridge first
- "File->Load Game" moved to "Load->Import Game" ... may cause a bit of
confusion to new users, but I don't like having a single-item menu,
we'll just have to explain it to new users
- browser window redone to look like ananke
- home button here goes to ~/Emulation rather than just ~ like ananke,
since this is the home of game folders
- game folder icon is now the executable icon for the Tango theme
(orange diamond), meant to represent a complete game rather than
a game file or archive
ananke changelog:
- outputs GBC games to "Game Boy Color/" instead of "Game Boy/"
- adds the file basename to "information/title"
Known issues:
- using ananke to load a GB game trips the Super Famicom SGB mode and
fails (need to make the full-path auto-detection ignore non-bootable
systems)
- need to dump and test some BS-X media before releasing
- ananke lacks BS-X Satellaview cartridge support
- v092 isn't going to let you retarget the ananke/higan game folder path
of ~/Emulation, you will have to wait for a future version if that
bothers you so greatly
[Later, after the v092 release, byuu posted this additional changelog:
- kill laevateinn
- add title()
- add bootable, remove load
- combine file, library
- combine [][][] paths
- fix SFC subtype handling XML->BML
- update file browser to use buttons
- update file browser keyboard handling
- update system XML->BML
- fix sufami turbo hashing
- remove Cartridge::manifest
]
2012-12-25 05:31:55 +00:00
|
|
|
information.title = document["information/title"].text();
|
2012-05-26 08:18:42 +00:00
|
|
|
|
2015-11-10 11:02:29 +00:00
|
|
|
hasSRAM = false;
|
|
|
|
hasEEPROM = false;
|
|
|
|
hasFLASH = false;
|
|
|
|
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
if(auto node = document["board/rom"]) {
|
|
|
|
mrom.size = min(32 * 1024 * 1024, node["size"].natural());
|
2017-01-13 01:15:45 +00:00
|
|
|
if(auto fp = platform->open(pathID(), node["name"].text(), File::Read, File::Required)) {
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
fp->read(mrom.data, mrom.size);
|
|
|
|
}
|
2012-03-27 11:02:57 +00:00
|
|
|
}
|
2012-03-19 11:19:53 +00:00
|
|
|
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
if(auto node = document["board/ram"]) {
|
|
|
|
if(node["type"].text() == "sram") {
|
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.
2015-12-19 08:52:34 +00:00
|
|
|
hasSRAM = true;
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
sram.size = min(32 * 1024, node["size"].natural());
|
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.
2015-12-19 08:52:34 +00:00
|
|
|
sram.mask = sram.size - 1;
|
|
|
|
for(auto n : range(sram.size)) sram.data[n] = 0xff;
|
|
|
|
|
2017-01-13 01:15:45 +00:00
|
|
|
if(auto fp = platform->open(pathID(), node["name"].text(), File::Read)) {
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
fp->read(sram.data, sram.size);
|
|
|
|
}
|
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.
2015-12-19 08:52:34 +00:00
|
|
|
}
|
|
|
|
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
if(node["type"].text() == "eeprom") {
|
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.
2015-12-19 08:52:34 +00:00
|
|
|
hasEEPROM = true;
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
eeprom.size = min(8 * 1024, node["size"].natural());
|
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.
2015-12-19 08:52:34 +00:00
|
|
|
eeprom.bits = eeprom.size <= 512 ? 6 : 14;
|
|
|
|
if(eeprom.size == 0) eeprom.size = 8192, eeprom.bits = 0; //auto-detect size
|
|
|
|
eeprom.mask = mrom.size > 16 * 1024 * 1024 ? 0x0fffff00 : 0x0f000000;
|
|
|
|
eeprom.test = mrom.size > 16 * 1024 * 1024 ? 0x0dffff00 : 0x0d000000;
|
|
|
|
for(auto n : range(eeprom.size)) eeprom.data[n] = 0xff;
|
|
|
|
|
2017-01-13 01:15:45 +00:00
|
|
|
if(auto fp = platform->open(pathID(), node["name"].text(), File::Read)) {
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
fp->read(eeprom.data, eeprom.size);
|
|
|
|
}
|
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.
2015-12-19 08:52:34 +00:00
|
|
|
}
|
|
|
|
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
if(node["type"].text() == "flash") {
|
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.
2015-12-19 08:52:34 +00:00
|
|
|
hasFLASH = true;
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
flash.id = node["id"].natural();
|
|
|
|
flash.size = min(128 * 1024, node["size"].natural());
|
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.
2015-12-19 08:52:34 +00:00
|
|
|
for(auto n : range(flash.size)) flash.data[n] = 0xff;
|
|
|
|
|
|
|
|
//if flash ID not provided; guess that it's a Macronix chip
|
|
|
|
//this will not work for all games; in which case, the ID must be specified manually
|
|
|
|
if(!flash.id && flash.size == 64 * 1024) flash.id = 0x1cc2;
|
|
|
|
if(!flash.id && flash.size == 128 * 1024) flash.id = 0x09c2;
|
|
|
|
|
2017-01-13 01:15:45 +00:00
|
|
|
if(auto fp = platform->open(pathID(), node["name"].text(), File::Read)) {
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
fp->read(flash.data, flash.size);
|
|
|
|
}
|
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.
2015-12-19 08:52:34 +00:00
|
|
|
}
|
Update to v087r26 release.
byuu says:
Changelog:
- fixed FIFO[1] reset behavior (fixes audio in Sword of Mana)
- added FlashROM emulation (both sizes)
- GBA parses RAM settings from manifest.xml now
- save RAM is written to disk now
- added save state support (it's currently broken, though)
- fixed ROM/RAM access timings
- open bus should mostly work (we don't do the PC+12 stuff yet)
- emulated the undocumented memory control register (mirror IWRAM,
disable I+EWRAM, EWRAM wait state count)
- emulated keypad interrupts
- emulated STOP (freezes video, audio, DMA and timers; only breaks on
keypad IRQs)
- probably a lot more, it was a long night ...
Show stoppers, missing things, broken things, etc:
- ST018 is still completely broken
- GBC audio sequencer apparently needs work
- GBA audio FIFO buffer seems too quiet
- PHI / ROM prefetch needs to be emulated (no idea on how to do this,
especially PHI)
- SOUNDBIAS 64/128/256khz modes should output at that resolution
(really, we need to simulate PWM properly, no idea on how to do this)
- object mosaic top-left coordinates are wrong (minor, fixing will
actually make the effect look worse)
- need to emulate PPU greenswap and color palette distortion (no idea on
how do this)
- need GBA save type database (I would also LIKE to blacklist
/ patch-out trainers, but that's a discussion for another day.)
- some ARM ops advance the prefetch buffer, so you can read PC+12 in
some cases
2012-04-16 12:19:39 +00:00
|
|
|
}
|
Update to v087r08 release.
byuu says:
Added some more ARM opcodes, hooked up MMIO. Bind it with mmio[(addr
000-3ff)] = this; inside CPU/PPU/APU, goes to read(), write().
Also moved the Hitachi HG51B core to processor/, and split it apart from
the snes/chip/hitachidsp implementation.
This one actually worked really well. Very clean split between MMIO/DMA
and the processor core. I may move a more generic DMA function inside
the core, not sure yet.
I still believe the HG51B169 to be a variant of the HG51BS family, but
given they're meant to be incredibly flexible microcontrollers, it's
possible that each variant gets its own instruction set.
So, who knows. We'll worry about it if we ever find another HG51B DSP,
I guess.
GBA BIOS is constantly reading from 04000300, but it never writes. If
I return prng()&1, I can get it to proceed until it hits a bad opcode
(stc opcode, which the GBA lacks a coprocessor so ... bad codepath.)
Without it, it just reads that register forever and keeps resetting the
system, or something ...
I guess we're going to have to try and get ARMwrestler working, because
the BIOS seems to need too much emulation code to do anything at all.
2012-03-24 07:52:36 +00:00
|
|
|
|
2015-11-10 11:02:29 +00:00
|
|
|
information.sha256 = Hash::SHA256(mrom.data, mrom.size).digest();
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Cartridge::save() -> void {
|
|
|
|
auto document = BML::unserialize(information.manifest);
|
|
|
|
if(auto node = document["board/ram"]) {
|
2017-01-13 01:15:45 +00:00
|
|
|
if(auto fp = platform->open(pathID(), node["name"].text(), File::Write)) {
|
Update to v099r07 release.
byuu says:
Changelog:
- (hopefully) fixed BS Memory and Sufami Turbo slot loading
- ported GB, GBA, WS cores to use nall/vfs
- completely removed loadRequest, saveRequest functionality from
Emulator::Interface and ui-tomoko
- loadRequest(folder) is now load(folder)
- save states now use a shared Emulator::SerializerVersion string
- whenever this is bumped, all older states will break; but this makes
bumping state versions way easier
- also, the version string makes it a lot easier to identify
compatibility windows for save states
- SNES PPU now uses uint16 vram[32768] for memory accesses [hex_usr]
NOTE: Super Game Boy loading is currently broken, and I'm not entirely
sure how to fix it :/
The file loading handoff was -really- complicated, and so I'm kind of
at a loss ... so for now, don't try it.
Everything else should theoretically work, so please report any bugs
you find.
So, this is pretty much it. I'd be very curious to hear feedback from
people who objected to the old nall/stream design, whether they are
happy with the new file loading system or think it could use further
improvements.
The 16-bit VRAM turned out to be a wash on performance (roughly the same
as before. 1fps slower on Zelda 3, 1fps faster on Yoshi's Island.) The
main reason for this was because Yoshi's Island was breaking horribly
until I changed the vramRead, vramWrite functions to take uint15 instead
of uint16.
I suspect the issue is we're using uint16s in some areas now that need
to be uint15, and this game is setting the VRAM address to 0x8000+,
causing us to go out of bounds on memory accesses.
But ... I want to go ahead and do something cute for fun, and just because
we can ... and this new interface is so incredibly perfect for it!! I
want to support an SNES unit with 128KiB of VRAM. Not out of the box,
but as a fun little tweakable thing. The SNES was clearly designed to
support that, they just didn't use big enough VRAM chips, and left one
of the lines disconnected. So ... let's connect it anyway!
In the end, if we design it right, the only code difference should be
one area where we mask by 15-bits instead of by 16-bits.
2016-06-24 12:09:30 +00:00
|
|
|
if(node["type"].text() == "sram") fp->write(sram.data, sram.size);
|
|
|
|
if(node["type"].text() == "eeprom") fp->write(eeprom.data, eeprom.size);
|
|
|
|
if(node["type"].text() == "flash") fp->write(flash.data, flash.size);
|
|
|
|
}
|
|
|
|
}
|
2012-03-19 11:19:53 +00:00
|
|
|
}
|
|
|
|
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
auto Cartridge::unload() -> void {
|
2012-04-09 06:19:32 +00:00
|
|
|
}
|
|
|
|
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
auto Cartridge::power() -> void {
|
2012-04-09 06:19:32 +00:00
|
|
|
eeprom.power();
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
flash.power();
|
Update to v087r26 release.
byuu says:
Changelog:
- fixed FIFO[1] reset behavior (fixes audio in Sword of Mana)
- added FlashROM emulation (both sizes)
- GBA parses RAM settings from manifest.xml now
- save RAM is written to disk now
- added save state support (it's currently broken, though)
- fixed ROM/RAM access timings
- open bus should mostly work (we don't do the PC+12 stuff yet)
- emulated the undocumented memory control register (mirror IWRAM,
disable I+EWRAM, EWRAM wait state count)
- emulated keypad interrupts
- emulated STOP (freezes video, audio, DMA and timers; only breaks on
keypad IRQs)
- probably a lot more, it was a long night ...
Show stoppers, missing things, broken things, etc:
- ST018 is still completely broken
- GBC audio sequencer apparently needs work
- GBA audio FIFO buffer seems too quiet
- PHI / ROM prefetch needs to be emulated (no idea on how to do this,
especially PHI)
- SOUNDBIAS 64/128/256khz modes should output at that resolution
(really, we need to simulate PWM properly, no idea on how to do this)
- object mosaic top-left coordinates are wrong (minor, fixing will
actually make the effect look worse)
- need to emulate PPU greenswap and color palette distortion (no idea on
how do this)
- need GBA save type database (I would also LIKE to blacklist
/ patch-out trainers, but that's a discussion for another day.)
- some ARM ops advance the prefetch buffer, so you can read PC+12 in
some cases
2012-04-16 12:19:39 +00:00
|
|
|
}
|
2012-04-09 06:19:32 +00:00
|
|
|
|
2012-04-29 06:16:44 +00:00
|
|
|
#define RAM_ANALYZE
|
|
|
|
|
2015-11-10 11:02:29 +00:00
|
|
|
auto Cartridge::read(uint mode, uint32 addr) -> uint32 {
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
if(addr < 0x0e00'0000) {
|
2015-11-10 11:02:29 +00:00
|
|
|
if(hasEEPROM && (addr & eeprom.mask) == eeprom.test) return eeprom.read();
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
return mrom.read(mode, addr);
|
|
|
|
} else {
|
2015-11-10 11:02:29 +00:00
|
|
|
if(hasSRAM) return sram.read(mode, addr);
|
|
|
|
if(hasFLASH) return flash.read(addr);
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
return cpu.pipeline.fetch.instruction;
|
|
|
|
}
|
Update to v087r26 release.
byuu says:
Changelog:
- fixed FIFO[1] reset behavior (fixes audio in Sword of Mana)
- added FlashROM emulation (both sizes)
- GBA parses RAM settings from manifest.xml now
- save RAM is written to disk now
- added save state support (it's currently broken, though)
- fixed ROM/RAM access timings
- open bus should mostly work (we don't do the PC+12 stuff yet)
- emulated the undocumented memory control register (mirror IWRAM,
disable I+EWRAM, EWRAM wait state count)
- emulated keypad interrupts
- emulated STOP (freezes video, audio, DMA and timers; only breaks on
keypad IRQs)
- probably a lot more, it was a long night ...
Show stoppers, missing things, broken things, etc:
- ST018 is still completely broken
- GBC audio sequencer apparently needs work
- GBA audio FIFO buffer seems too quiet
- PHI / ROM prefetch needs to be emulated (no idea on how to do this,
especially PHI)
- SOUNDBIAS 64/128/256khz modes should output at that resolution
(really, we need to simulate PWM properly, no idea on how to do this)
- object mosaic top-left coordinates are wrong (minor, fixing will
actually make the effect look worse)
- need to emulate PPU greenswap and color palette distortion (no idea on
how do this)
- need GBA save type database (I would also LIKE to blacklist
/ patch-out trainers, but that's a discussion for another day.)
- some ARM ops advance the prefetch buffer, so you can read PC+12 in
some cases
2012-04-16 12:19:39 +00:00
|
|
|
}
|
|
|
|
|
2015-11-10 11:02:29 +00:00
|
|
|
auto Cartridge::write(uint mode, uint32 addr, uint32 word) -> void {
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
if(addr < 0x0e00'0000) {
|
2015-11-10 11:02:29 +00:00
|
|
|
if(hasEEPROM && (addr & eeprom.mask) == eeprom.test) return eeprom.write(word & 1);
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
return mrom.write(mode, addr, word);
|
|
|
|
} else {
|
2015-11-10 11:02:29 +00:00
|
|
|
if(hasSRAM) return sram.write(mode, addr, word);
|
|
|
|
if(hasFLASH) return flash.write(addr, word);
|
Update to v095r03 release and icarus 20151107.
byuu says:
Note: you will need the new icarus (and please use the "no manifest"
system) to run GBA games with this WIP.
Changelog:
- fixed caching of r(d) to pass armwrestler tests [Jonas Quinn]
- DMA to/from GBA BIOS should fail [Cydrak]
- fixed sign-extend and rotate on ldrs instructions [Cydrak]
- fixed 8-bit SRAM reading/writing [byuu]
- refactored GBA/cartridge
- cartridge/rom,ram.type is now cartridge/mrom,sram,eeprom,flash
- things won't crash horribly if you specify a RAM size larger than
the largest legal size in the manifest
- specialized MROM / SRAM classes replace all the shared read/write
functions that didn't work right anyway
- there's a new ruby/video.glx2 driver, which is not enabled by default
- use this if you are running Linux/BSD, but don't have OpenGL 3.2 yet
- I'm not going to support OpenGL2 on Windows/OS X, because these OSes
don't ship ancient video card drivers
- probably more. What am I, clairvoyant? :P
For endrift's tests, this gets us to 1348/1552 memory and 1016/1260
timing. Overall, this puts us back in second place. Only no$ is ahead
on memory, but bgba is even more ahead on timing.
2015-11-08 09:09:18 +00:00
|
|
|
}
|
2012-03-19 11:19:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|