Update to v087r04 release.
byuu says:
Changelog:
- gameboy/ -> gb/
- GameBoy -> GB
- basic memory map for GBA
- enough code to execute the first BIOS instruction (b 0x68)
I have the code resetting r(15) to 0 on an exception just as a test.
Since that flushes the pipeline, that means we're basically executing "b
0x68" at 8MHz, and nothing else.
... and I am getting __6 motherfucking FPS__ at 4.4GHz on an i7.
Something is seriously, horribly, unfuckingbelievably wrong here, and
I can't figure out what it is.
My *fully complete* ARM core on the ST018 is even less efficient and
runs at 21.47MHz, and yet I get 60fps even after emulating the SNES
CPU+PPU @ 10+MHz each as well.
... I'm stuck. I can't proceed until we figure out what in the holy fuck
is going on here. So ... if anyone can help, please do. If we can't fix
this, the GBA emulation is dead.
I was able to profile on Windows, and I've included that in this WIP
under out/log.txt.
But it looks normal to me. But yeah, there's NO. FUCKING. WAY. This code
should be running this slowly.
2012-03-18 12:35:53 +00:00
|
|
|
#include <gb/gb.hpp>
|
2010-12-28 01:53:15 +00:00
|
|
|
|
|
|
|
#define SYSTEM_CPP
|
2012-04-26 10:51:13 +00:00
|
|
|
namespace GameBoy {
|
2010-12-28 01:53:15 +00:00
|
|
|
|
2011-01-07 11:11:56 +00:00
|
|
|
#include "serialization.cpp"
|
2010-12-28 01:53:15 +00:00
|
|
|
System system;
|
|
|
|
|
2011-01-07 11:11:56 +00:00
|
|
|
void System::run() {
|
|
|
|
scheduler.sync = Scheduler::SynchronizeMode::None;
|
|
|
|
|
|
|
|
scheduler.enter();
|
|
|
|
if(scheduler.exit_reason() == Scheduler::ExitReason::FrameEvent) {
|
Update to v088r08 release.
byuu says:
From this WIP, I'm starting on the impossible task of
a declarative-based GUI, which I'm calling Ethos.
base/ becomes emulator/, and we add emulator/interface.hpp, which is
a base API that all emulation cores must implement in full.
(Right now, it's kind of a hybrid to work with the old GUI and the new
GUI at the same time, of course.)
Unlike the old interfaces, the new base class also provides all general
usability hooks: loading and saving files and states, cheat codes, etc.
The new interface also contains information and vector structs to
describe all possible loading methods, controller bindings, etc; and
gives names for them all.
The actual GUI in fact should not include eg <gba/gba.hpp> anymore.
Should speed up GUI compilation.
So the idea going forward is that ethos will build a list of emulators
right when the application starts up.
Once you've appended an emulator to that list, you're done. No more GUI
changes are needed to support that system.
The GUI will have code to parse the emulator interfaces list, and build
all the requisite GUI options dynamically, declarative style.
Ultimately, once the project is finished, the new GUI should look ~99%
identical to the current GUI. But it'll probably be a whole lot smaller.
2012-04-29 06:29:54 +00:00
|
|
|
interface->videoRefresh(ppu.screen, 4 * 160, 160, 144);
|
2011-01-07 11:11:56 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void System::runtosave() {
|
|
|
|
scheduler.sync = Scheduler::SynchronizeMode::CPU;
|
|
|
|
runthreadtosave();
|
|
|
|
|
2012-04-17 12:16:54 +00:00
|
|
|
scheduler.sync = Scheduler::SynchronizeMode::All;
|
2012-04-26 10:51:13 +00:00
|
|
|
scheduler.active_thread = ppu.thread;
|
2011-01-07 11:11:56 +00:00
|
|
|
runthreadtosave();
|
2012-04-17 12:16:54 +00:00
|
|
|
|
|
|
|
scheduler.sync = Scheduler::SynchronizeMode::All;
|
|
|
|
scheduler.active_thread = apu.thread;
|
|
|
|
runthreadtosave();
|
|
|
|
|
|
|
|
scheduler.sync = Scheduler::SynchronizeMode::None;
|
2011-01-07 11:11:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void System::runthreadtosave() {
|
|
|
|
while(true) {
|
|
|
|
scheduler.enter();
|
|
|
|
if(scheduler.exit_reason() == Scheduler::ExitReason::SynchronizeEvent) break;
|
|
|
|
if(scheduler.exit_reason() == Scheduler::ExitReason::FrameEvent) {
|
Update to v088r08 release.
byuu says:
From this WIP, I'm starting on the impossible task of
a declarative-based GUI, which I'm calling Ethos.
base/ becomes emulator/, and we add emulator/interface.hpp, which is
a base API that all emulation cores must implement in full.
(Right now, it's kind of a hybrid to work with the old GUI and the new
GUI at the same time, of course.)
Unlike the old interfaces, the new base class also provides all general
usability hooks: loading and saving files and states, cheat codes, etc.
The new interface also contains information and vector structs to
describe all possible loading methods, controller bindings, etc; and
gives names for them all.
The actual GUI in fact should not include eg <gba/gba.hpp> anymore.
Should speed up GUI compilation.
So the idea going forward is that ethos will build a list of emulators
right when the application starts up.
Once you've appended an emulator to that list, you're done. No more GUI
changes are needed to support that system.
The GUI will have code to parse the emulator interfaces list, and build
all the requisite GUI options dynamically, declarative style.
Ultimately, once the project is finished, the new GUI should look ~99%
identical to the current GUI. But it'll probably be a whole lot smaller.
2012-04-29 06:29:54 +00:00
|
|
|
interface->videoRefresh(ppu.screen, 4 * 160, 160, 144);
|
2011-01-07 11:11:56 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-09-15 12:41:49 +00:00
|
|
|
void System::init() {
|
2012-07-15 09:47:35 +00:00
|
|
|
assert(interface != nullptr);
|
2010-12-28 01:53:15 +00:00
|
|
|
}
|
|
|
|
|
2011-10-27 00:00:17 +00:00
|
|
|
void System::load(Revision revision) {
|
|
|
|
this->revision = revision;
|
2011-01-29 09:48:44 +00:00
|
|
|
serialize_init();
|
2012-07-15 09:47:35 +00:00
|
|
|
if(revision == Revision::SuperGameBoy) return; //Super Famicom core loads boot ROM for SGB
|
|
|
|
|
|
|
|
string manifest, firmware;
|
|
|
|
manifest.readfile({interface->path(ID::System), "manifest.xml"});
|
|
|
|
XML::Document document(manifest);
|
|
|
|
interface->loadRequest(
|
|
|
|
revision == Revision::GameBoy ? ID::GameBoyBootROM : ID::GameBoyColorBootROM,
|
|
|
|
document["system"]["cpu"]["firmware"]["name"].data
|
|
|
|
);
|
|
|
|
if(!file::exists({interface->path(ID::System), document["system"]["cpu"]["firmware"]["name"].data})) {
|
|
|
|
interface->notify("Error: required firmware ", firmware, " not found.\n");
|
|
|
|
}
|
2011-01-29 09:48:44 +00:00
|
|
|
}
|
|
|
|
|
2010-12-28 01:53:15 +00:00
|
|
|
void System::power() {
|
2010-12-29 11:03:42 +00:00
|
|
|
bus.power();
|
|
|
|
cartridge.power();
|
2010-12-28 01:53:15 +00:00
|
|
|
cpu.power();
|
2012-04-26 10:51:13 +00:00
|
|
|
ppu.power();
|
2011-01-22 08:15:49 +00:00
|
|
|
apu.power();
|
2010-12-28 06:03:02 +00:00
|
|
|
scheduler.init();
|
2011-01-06 10:16:07 +00:00
|
|
|
|
2011-01-07 11:11:56 +00:00
|
|
|
clocks_executed = 0;
|
2010-12-28 01:53:15 +00:00
|
|
|
}
|
|
|
|
|
Update to v087r28 release.
byuu says:
Be sure to run make install, and move required images to their appropriate system profile folders.
I still have no warnings in place if those images aren't present.
Changelog:
- OBJ mosaic should hopefully be emulated correctly now (thanks to krom
and Cydrak for testing the hardware behavior)
- emulated dummy serial registers, fixes Sonic Advance (you may still
need to specify 512KB FlashROM with an appropriate ID, I used
Panaonic's)
- GBA core exits scheduler (PPU thread) and calls
interface->videoRefresh() from main thread (not required, just nice)
- SRAM, FRAM, EEPROM and FlashROM initialized to 0xFF if it does not
exist (probably not needed, but FlashROM likes to reset to 0xFF
anyway)
- GBA manifest.xml for file-mode will now use "gamename.xml" instead of
"gamename.gba.xml"
- started renaming "NES" to "Famicom" and "SNES" to "Super Famicom" in
the GUI (may or may not change source code in the long-term)
- removed target-libsnes/
- added profile/
Profiles are the major new feature. So far we have:
Famicom.sys/{nothing (yet?)}
Super Famicom.sys/{ipl.rom}
Game Boy.sys/{boot.rom}
Game Boy Color.sys/{boot.rom}
Game Boy Advance.sys/{bios.rom[not included]}
Super Game Boy.sfc/{boot.rom,program.rom[not included]}
BS-X Satellaview.sfc/{program.rom,bsx.ram,bsx.pram}
Sufami Turbo.sfc/{program.rom}
The SGB, BSX and ST cartridges ask you to load GB, BS or ST cartridges
directly now. No slot loader for them. So the obvious downsides: you
can't quickly pick between different SGB BIOSes, but why would you want
to? Just use SGB2/JP. It's still possible, so I'll sacrifice a little
complexity for a rare case to make it a lot easier for the more common
case. ST cartridges currently won't let you load the secondary slot.
BS-X Town cart is the only useful game to load with nothing in the slot,
but only barely, since games are all seeded on flash and not on PSRAM
images. We can revisit a way to boot the BIOS directly if and when we
get the satellite uplink emulated and data can be downloaded onto the
PSRAM :P BS-X slotted cartridges still require the secondary slot.
My plan for BS-X slotted cartridges is to require a manifest.xml to
specify that it has the BS-X slot present. Otherwise, we have to load
the ROM into the SNES cartridge class, and parse its header before we
can find out if it has one. Screw that. If it's in the XML, I can tell
before loading the ROM if I need to present you with an optional slot
loading dialog. I will probably do something similar for Sufami Turbo.
Not all games even work with a secondary slot, so why ask you to load
a second slot for them? Let the XML request a second slot. A complete
Sufami Turbo ROM set will be trivial anyway. Not sure how I want to do
the sub dialog yet. We want basic file loading, but we don't want it to
look like the dialog 'didn't do anything' if it pops back open
immediately again. Maybe change the background color of the dialog to
a darker gray? Tacky, but it'd give you the visual cue without the need
for some subtle text changes.
2012-04-18 13:58:04 +00:00
|
|
|
System::System() {
|
|
|
|
for(auto &byte : bootROM.dmg) byte = 0;
|
|
|
|
for(auto &byte : bootROM.sgb) byte = 0;
|
|
|
|
for(auto &byte : bootROM.cgb) byte = 0;
|
|
|
|
}
|
|
|
|
|
2010-12-28 01:53:15 +00:00
|
|
|
}
|