2016-04-09 05:20:41 +00:00
|
|
|
auto PPU::read(uint24 addr, uint8 data) -> uint8 {
|
|
|
|
cpu.synchronizePPU();
|
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
switch((uint16)addr) {
|
2016-04-09 05:20:41 +00:00
|
|
|
|
|
|
|
case 0x2104: case 0x2105: case 0x2106: case 0x2108:
|
|
|
|
case 0x2109: case 0x210a: case 0x2114: case 0x2115:
|
|
|
|
case 0x2116: case 0x2118: case 0x2119: case 0x211a:
|
|
|
|
case 0x2124: case 0x2125: case 0x2126: case 0x2128:
|
|
|
|
case 0x2129: case 0x212a: {
|
2016-06-14 10:51:54 +00:00
|
|
|
return ppu1.mdr;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//MPYL
|
|
|
|
case 0x2134: {
|
2016-06-15 11:32:17 +00:00
|
|
|
uint result = (int16)r.m7a * (int8)(r.m7b >> 8);
|
2016-06-14 10:51:54 +00:00
|
|
|
ppu1.mdr = (result >> 0);
|
|
|
|
return ppu1.mdr;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//MPYM
|
|
|
|
case 0x2135: {
|
2016-06-15 11:32:17 +00:00
|
|
|
uint result = (int16)r.m7a * (int8)(r.m7b >> 8);
|
2016-06-14 10:51:54 +00:00
|
|
|
ppu1.mdr = (result >> 8);
|
|
|
|
return ppu1.mdr;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//MPYH
|
|
|
|
case 0x2136: {
|
2016-06-15 11:32:17 +00:00
|
|
|
uint result = (int16)r.m7a * (int8)(r.m7b >> 8);
|
2016-06-14 10:51:54 +00:00
|
|
|
ppu1.mdr = (result >> 16);
|
|
|
|
return ppu1.mdr;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//SLHV
|
|
|
|
case 0x2137: {
|
|
|
|
if(cpu.pio() & 0x80) latchCounters();
|
Update to v098r11 release.
byuu says:
Changelog:
- fixed nall/path.hpp compilation issue
- fixed ruby/audio/xaudio header declaration compilation issue (again)
- cleaned up xaudio2.hpp file to match my coding syntax (12.5% of the
file was whitespace overkill)
- added null terminator entry to nall/windows/utf8.hpp argc[] array
- nall/windows/guid.hpp uses the Windows API for generating the GUID
- this should stop all the bug reports where two nall users were
generating GUIDs at the exact same second
- fixed hiro/cocoa compilation issue with uint# types
- fixed major higan/sfc Super Game Boy audio latency issue
- fixed higan/sfc CPU core bug with pei, [dp], [dp]+y instructions
- major cleanups to higan/processor/r65816 core
- merged emulation/native-mode opcodes
- use camel-case naming on memory.hpp functions
- simplify address masking code for memory.hpp functions
- simplify a few opcodes themselves (avoid redundant copies, etc)
- rename regs.* to r.* to match modern convention of other CPU cores
- removed device.order<> concept from Emulator::Interface
- cores will now do the translation to make the job of the UI easier
- fixed plurality naming of arrays in Emulator::Interface
- example: emulator.ports[p].devices[d].inputs[i]
- example: vector<Medium> media
- probably more surprises
Major show-stoppers to the next official release:
- we need to work on GB core improvements: LY=153/0 case, multiple STAT
IRQs case, GBC audio output regs, etc.
- we need to re-add software cursors for light guns (Super Scope,
Justifier)
- after the above, we need to fix the turbo button for the Super Scope
I really have no idea how I want to implement the light guns. Ideally,
we'd want it in higan/video, so we can support the NES Zapper with the
same code. But this isn't going to be easy, because only the SNES knows
when its output is interlaced, and its resolutions can vary as
{256,512}x{224,240,448,480} which requires pixel doubling that was
hard-coded to the SNES-specific behavior, but isn't appropriate to be
exposed in higan/video.
2016-05-25 11:13:02 +00:00
|
|
|
return cpu.r.mdr;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//OAMDATAREAD
|
|
|
|
case 0x2138: {
|
2016-06-15 11:32:17 +00:00
|
|
|
uint10 address = r.oamAddress++;
|
|
|
|
if(!r.displayDisable && vcounter() < vdisp()) address = latch.oamAddress;
|
|
|
|
if(address & 0x0200) address &= 0x021f;
|
2016-04-09 05:20:41 +00:00
|
|
|
|
2016-06-15 11:32:17 +00:00
|
|
|
ppu1.mdr = oamRead(address);
|
|
|
|
obj.setFirstSprite();
|
2016-06-14 10:51:54 +00:00
|
|
|
return ppu1.mdr;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//VMDATALREAD
|
|
|
|
case 0x2139: {
|
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 address = getVramAddress();
|
2016-06-14 10:51:54 +00:00
|
|
|
ppu1.mdr = latch.vram >> 0;
|
|
|
|
if(r.vramIncrementMode == 0) {
|
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
|
|
|
latch.vram.byte(0) = vramRead(0, address);
|
|
|
|
latch.vram.byte(1) = vramRead(1, address);
|
2016-06-14 10:51:54 +00:00
|
|
|
r.vramAddress += r.vramIncrementSize;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
2016-06-14 10:51:54 +00:00
|
|
|
return ppu1.mdr;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//VMDATAHREAD
|
|
|
|
case 0x213a: {
|
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
|
|
|
uint16 address = getVramAddress();
|
2016-06-14 10:51:54 +00:00
|
|
|
ppu1.mdr = latch.vram >> 8;
|
|
|
|
if(r.vramIncrementMode == 1) {
|
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
|
|
|
latch.vram.byte(0) = vramRead(0, address);
|
|
|
|
latch.vram.byte(1) = vramRead(1, address);
|
2016-06-14 10:51:54 +00:00
|
|
|
r.vramAddress += r.vramIncrementSize;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
2016-06-14 10:51:54 +00:00
|
|
|
return ppu1.mdr;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//CGDATAREAD
|
|
|
|
case 0x213b: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bool l = r.cgramAddress & 1;
|
|
|
|
uint9 address = r.cgramAddress++;
|
|
|
|
if(!r.displayDisable
|
2016-04-09 05:20:41 +00:00
|
|
|
&& vcounter() > 0 && vcounter() < vdisp()
|
|
|
|
&& hcounter() >= 88 && hcounter() < 1096
|
2016-06-14 10:51:54 +00:00
|
|
|
) address = latch.cgramAddress;
|
2016-04-09 05:20:41 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
if(l == 0) {
|
|
|
|
ppu2.mdr = cgramRead(address);
|
2016-04-09 05:20:41 +00:00
|
|
|
} else {
|
2016-06-14 10:51:54 +00:00
|
|
|
ppu2.mdr &= 0x80;
|
|
|
|
ppu2.mdr |= cgramRead(address);
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
2016-06-14 10:51:54 +00:00
|
|
|
return ppu2.mdr;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//OPHCT
|
|
|
|
case 0x213c: {
|
2016-06-14 10:51:54 +00:00
|
|
|
if(latch.hcounter == 0) {
|
|
|
|
ppu2.mdr = (r.hcounter >> 0);
|
2016-04-09 05:20:41 +00:00
|
|
|
} else {
|
2016-06-14 10:51:54 +00:00
|
|
|
ppu2.mdr &= 0xfe;
|
|
|
|
ppu2.mdr |= (r.hcounter >> 8) & 1;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
2016-06-14 10:51:54 +00:00
|
|
|
latch.hcounter ^= 1;
|
|
|
|
return ppu2.mdr;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//OPVCT
|
|
|
|
case 0x213d: {
|
2016-06-14 10:51:54 +00:00
|
|
|
if(latch.vcounter == 0) {
|
|
|
|
ppu2.mdr = (r.vcounter >> 0);
|
2016-04-09 05:20:41 +00:00
|
|
|
} else {
|
2016-06-14 10:51:54 +00:00
|
|
|
ppu2.mdr &= 0xfe;
|
|
|
|
ppu2.mdr |= (r.vcounter >> 8) & 1;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
2016-06-14 10:51:54 +00:00
|
|
|
latch.vcounter ^= 1;
|
|
|
|
return ppu2.mdr;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//STAT77
|
|
|
|
case 0x213e: {
|
2016-06-14 10:51:54 +00:00
|
|
|
ppu1.mdr &= 0x10;
|
2016-06-15 11:32:17 +00:00
|
|
|
ppu1.mdr |= obj.r.timeOver << 7;
|
|
|
|
ppu1.mdr |= obj.r.rangeOver << 6;
|
2016-06-14 10:51:54 +00:00
|
|
|
ppu1.mdr |= ppu1.version & 0x0f;
|
|
|
|
return ppu1.mdr;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
//STAT78
|
|
|
|
case 0x213f: {
|
2016-06-14 10:51:54 +00:00
|
|
|
latch.hcounter = 0;
|
|
|
|
latch.vcounter = 0;
|
2016-04-09 05:20:41 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
ppu2.mdr &= 0x20;
|
|
|
|
ppu2.mdr |= field() << 7;
|
2016-04-09 05:20:41 +00:00
|
|
|
if((cpu.pio() & 0x80) == 0) {
|
2016-06-14 10:51:54 +00:00
|
|
|
ppu2.mdr |= 0x40;
|
|
|
|
} else if(latch.counters) {
|
|
|
|
ppu2.mdr |= 0x40;
|
|
|
|
latch.counters = false;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
2016-06-14 10:51:54 +00:00
|
|
|
ppu2.mdr |= (system.region() == System::Region::NTSC ? 0 : 1) << 4;
|
|
|
|
ppu2.mdr |= ppu2.version & 0x0f;
|
|
|
|
return ppu2.mdr;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
return data;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto PPU::write(uint24 addr, uint8 data) -> void {
|
|
|
|
cpu.synchronizePPU();
|
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
switch((uint16)addr) {
|
2016-04-09 05:20:41 +00:00
|
|
|
|
|
|
|
//INIDISP
|
|
|
|
case 0x2100: {
|
2016-06-15 11:32:17 +00:00
|
|
|
if(r.displayDisable && vcounter() == vdisp()) obj.addressReset();
|
2016-06-14 10:51:54 +00:00
|
|
|
r.displayBrightness = data.bits(0,3);
|
|
|
|
r.displayDisable = data.bit (7);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//OBSEL
|
|
|
|
case 0x2101: {
|
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
|
|
|
obj.r.tiledataAddress = data.bits(0,2) << 13;
|
2016-06-15 11:32:17 +00:00
|
|
|
obj.r.nameSelect = data.bits(3,4);
|
|
|
|
obj.r.baseSize = data.bits(5,7);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//OAMADDL
|
|
|
|
case 0x2102: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.oamBaseAddress = (r.oamBaseAddress & 0x0200) | (data << 1);
|
2016-06-15 11:32:17 +00:00
|
|
|
obj.addressReset();
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//OAMADDH
|
|
|
|
case 0x2103: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.oamPriority = data & 0x80;
|
|
|
|
r.oamBaseAddress = ((data & 0x01) << 9) | (r.oamBaseAddress & 0x01fe);
|
2016-06-15 11:32:17 +00:00
|
|
|
obj.addressReset();
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//OAMDATA
|
|
|
|
case 0x2104: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bool l = r.oamAddress & 1;
|
2016-06-15 11:32:17 +00:00
|
|
|
uint10 address = r.oamAddress++;
|
|
|
|
if(!r.displayDisable && vcounter() < vdisp()) address = latch.oamAddress;
|
|
|
|
if(address & 0x0200) address &= 0x021f;
|
2016-04-09 05:20:41 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
if(l == 0) latch.oam = data;
|
2016-06-15 11:32:17 +00:00
|
|
|
if(address & 0x0200) {
|
|
|
|
oamWrite(address, data);
|
2016-06-14 10:51:54 +00:00
|
|
|
} else if(l == 1) {
|
2016-06-15 11:32:17 +00:00
|
|
|
oamWrite((address & ~1) + 0, latch.oam);
|
|
|
|
oamWrite((address & ~1) + 1, data);
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
2016-06-15 11:32:17 +00:00
|
|
|
obj.setFirstSprite();
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BGMODE
|
|
|
|
case 0x2105: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.bgMode = data.bits(0,2);
|
|
|
|
r.bgPriority = data.bit (3);
|
|
|
|
bg1.r.tileSize = data.bit (4);
|
|
|
|
bg2.r.tileSize = data.bit (5);
|
|
|
|
bg3.r.tileSize = data.bit (6);
|
|
|
|
bg4.r.tileSize = data.bit (7);
|
2016-04-09 05:20:41 +00:00
|
|
|
updateVideoMode();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//MOSAIC
|
|
|
|
case 0x2106: {
|
2016-06-14 10:51:54 +00:00
|
|
|
uint mosaicSize = data.bits(4,7);
|
|
|
|
bg1.r.mosaic = data.bit(0) ? mosaicSize : 0;
|
|
|
|
bg2.r.mosaic = data.bit(1) ? mosaicSize : 0;
|
|
|
|
bg3.r.mosaic = data.bit(2) ? mosaicSize : 0;
|
|
|
|
bg4.r.mosaic = data.bit(3) ? mosaicSize : 0;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BG1SC
|
|
|
|
case 0x2107: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bg1.r.screenSize = data.bits(0,1);
|
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
|
|
|
bg1.r.screenAddress = data.bits(2,7) << 10;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BG2SC
|
|
|
|
case 0x2108: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bg2.r.screenSize = data.bits(0,1);
|
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
|
|
|
bg2.r.screenAddress = data.bits(2,7) << 10;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BG3SC
|
|
|
|
case 0x2109: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bg3.r.screenSize = data.bits(0,1);
|
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
|
|
|
bg3.r.screenAddress = data.bits(2,7) << 10;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BG4SC
|
|
|
|
case 0x210a: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bg4.r.screenSize = data.bits(0,1);
|
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
|
|
|
bg4.r.screenAddress = data.bits(2,7) << 10;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BG12NBA
|
|
|
|
case 0x210b: {
|
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
|
|
|
bg1.r.tiledataAddress = data.bits(0,3) << 12;
|
|
|
|
bg2.r.tiledataAddress = data.bits(4,7) << 12;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BG34NBA
|
|
|
|
case 0x210c: {
|
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
|
|
|
bg3.r.tiledataAddress = data.bits(0,3) << 12;
|
|
|
|
bg4.r.tiledataAddress = data.bits(4,7) << 12;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BG1HOFS
|
|
|
|
case 0x210d: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.hoffsetMode7 = (data << 8) | latch.mode7;
|
|
|
|
latch.mode7 = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
bg1.r.hoffset = (data << 8) | (latch.bgofs & ~7) | ((bg1.r.hoffset >> 8) & 7);
|
|
|
|
latch.bgofs = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BG1VOFS
|
|
|
|
case 0x210e: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.voffsetMode7 = (data << 8) | latch.mode7;
|
|
|
|
latch.mode7 = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
bg1.r.voffset = (data << 8) | latch.bgofs;
|
|
|
|
latch.bgofs = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BG2HOFS
|
|
|
|
case 0x210f: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bg2.r.hoffset = (data << 8) | (latch.bgofs & ~7) | ((bg2.r.hoffset >> 8) & 7);
|
|
|
|
latch.bgofs = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BG2VOFS
|
|
|
|
case 0x2110: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bg2.r.voffset = (data << 8) | latch.bgofs;
|
|
|
|
latch.bgofs = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BG3HOFS
|
|
|
|
case 0x2111: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bg3.r.hoffset = (data << 8) | (latch.bgofs & ~7) | ((bg3.r.hoffset >> 8) & 7);
|
|
|
|
latch.bgofs = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BG3VOFS
|
|
|
|
case 0x2112: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bg3.r.voffset = (data << 8) | latch.bgofs;
|
|
|
|
latch.bgofs = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BG4HOFS
|
|
|
|
case 0x2113: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bg4.r.hoffset = (data << 8) | (latch.bgofs & ~7) | ((bg4.r.hoffset >> 8) & 7);
|
|
|
|
latch.bgofs = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//BG4VOFS
|
|
|
|
case 0x2114: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bg4.r.voffset = (data << 8) | latch.bgofs;
|
|
|
|
latch.bgofs = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//VMAIN
|
|
|
|
case 0x2115: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.vramIncrementMode = data & 0x80;
|
|
|
|
r.vramMapping = (data >> 2) & 3;
|
2016-04-09 05:20:41 +00:00
|
|
|
switch(data & 3) {
|
2016-06-14 10:51:54 +00:00
|
|
|
case 0: r.vramIncrementSize = 1; break;
|
|
|
|
case 1: r.vramIncrementSize = 32; break;
|
|
|
|
case 2: r.vramIncrementSize = 128; break;
|
|
|
|
case 3: r.vramIncrementSize = 128; break;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//VMADDL
|
|
|
|
case 0x2116: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.vramAddress &= 0xff00;
|
|
|
|
r.vramAddress |= (data << 0);
|
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 address = getVramAddress();
|
|
|
|
latch.vram.byte(0) = vramRead(0, address);
|
|
|
|
latch.vram.byte(1) = vramRead(1, address);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//VMADDH
|
|
|
|
case 0x2117: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.vramAddress &= 0x00ff;
|
|
|
|
r.vramAddress |= (data << 8);
|
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 address = getVramAddress();
|
|
|
|
latch.vram.byte(0) = vramRead(0, address);
|
|
|
|
latch.vram.byte(1) = vramRead(1, address);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//VMDATAL
|
|
|
|
case 0x2118: {
|
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 address = getVramAddress();
|
|
|
|
vramWrite(0, address, data);
|
2016-06-14 10:51:54 +00:00
|
|
|
if(r.vramIncrementMode == 0) r.vramAddress += r.vramIncrementSize;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//VMDATAH
|
|
|
|
case 0x2119: {
|
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 address = getVramAddress();
|
|
|
|
vramWrite(1, address, data);
|
2016-06-14 10:51:54 +00:00
|
|
|
if(r.vramIncrementMode == 1) r.vramAddress += r.vramIncrementSize;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//M7SEL
|
|
|
|
case 0x211a: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.hflipMode7 = data.bit (0);
|
|
|
|
r.vflipMode7 = data.bit (1);
|
|
|
|
r.repeatMode7 = data.bits(6,7);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//M7A
|
|
|
|
case 0x211b: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.m7a = data << 8 | latch.mode7;
|
|
|
|
latch.mode7 = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//M7B
|
|
|
|
case 0x211c: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.m7b = data << 8 | latch.mode7;
|
|
|
|
latch.mode7 = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//M7C
|
|
|
|
case 0x211d: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.m7c = data << 8 | latch.mode7;
|
|
|
|
latch.mode7 = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//M7D
|
|
|
|
case 0x211e: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.m7d = data << 8 | latch.mode7;
|
|
|
|
latch.mode7 = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//M7X
|
|
|
|
case 0x211f: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.m7x = data << 8 | latch.mode7;
|
|
|
|
latch.mode7 = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//M7Y
|
|
|
|
case 0x2120: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.m7y = data << 8 | latch.mode7;
|
|
|
|
latch.mode7 = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//CGADD
|
|
|
|
case 0x2121: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.cgramAddress = data << 1;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//CGDATA
|
|
|
|
case 0x2122: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bool l = r.cgramAddress & 1;
|
|
|
|
uint9 address = r.cgramAddress++;
|
|
|
|
if(!r.displayDisable
|
2016-04-09 05:20:41 +00:00
|
|
|
&& vcounter() > 0 && vcounter() < vdisp()
|
|
|
|
&& hcounter() >= 88 && hcounter() < 1096
|
2016-06-14 10:51:54 +00:00
|
|
|
) address = latch.cgramAddress;
|
2016-04-09 05:20:41 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
if(l == 0) {
|
|
|
|
latch.cgram = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
} else {
|
2016-06-14 10:51:54 +00:00
|
|
|
cgramWrite((address & ~1) + 0, latch.cgram);
|
|
|
|
cgramWrite((address & ~1) + 1, data & 0x7f);
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//W12SEL
|
|
|
|
case 0x2123: {
|
2016-06-14 10:51:54 +00:00
|
|
|
window.r.bg1.oneInvert = data.bit(0);
|
|
|
|
window.r.bg1.oneEnable = data.bit(1);
|
|
|
|
window.r.bg1.twoInvert = data.bit(2);
|
|
|
|
window.r.bg1.twoEnable = data.bit(3);
|
|
|
|
window.r.bg2.oneInvert = data.bit(4);
|
|
|
|
window.r.bg2.oneEnable = data.bit(5);
|
|
|
|
window.r.bg2.twoInvert = data.bit(6);
|
|
|
|
window.r.bg2.twoEnable = data.bit(7);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//W34SEL
|
|
|
|
case 0x2124: {
|
2016-06-14 10:51:54 +00:00
|
|
|
window.r.bg3.oneInvert = data.bit(0);
|
|
|
|
window.r.bg3.oneEnable = data.bit(1);
|
|
|
|
window.r.bg3.twoInvert = data.bit(2);
|
|
|
|
window.r.bg3.twoEnable = data.bit(3);
|
|
|
|
window.r.bg4.oneInvert = data.bit(4);
|
|
|
|
window.r.bg4.oneEnable = data.bit(5);
|
|
|
|
window.r.bg4.twoInvert = data.bit(6);
|
|
|
|
window.r.bg4.twoEnable = data.bit(7);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//WOBJSEL
|
|
|
|
case 0x2125: {
|
2016-06-15 11:32:17 +00:00
|
|
|
window.r.obj.oneInvert = data.bit(0);
|
|
|
|
window.r.obj.oneEnable = data.bit(1);
|
|
|
|
window.r.obj.twoInvert = data.bit(2);
|
|
|
|
window.r.obj.twoEnable = data.bit(3);
|
2016-06-14 10:51:54 +00:00
|
|
|
window.r.col.oneInvert = data.bit(4);
|
|
|
|
window.r.col.oneEnable = data.bit(5);
|
|
|
|
window.r.col.twoInvert = data.bit(6);
|
|
|
|
window.r.col.twoEnable = data.bit(7);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//WH0
|
|
|
|
case 0x2126: {
|
2016-06-14 10:51:54 +00:00
|
|
|
window.r.oneLeft = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//WH1
|
|
|
|
case 0x2127: {
|
2016-06-14 10:51:54 +00:00
|
|
|
window.r.oneRight = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//WH2
|
|
|
|
case 0x2128: {
|
2016-06-14 10:51:54 +00:00
|
|
|
window.r.twoLeft = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//WH3
|
|
|
|
case 0x2129: {
|
2016-06-14 10:51:54 +00:00
|
|
|
window.r.twoRight = data;
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//WBGLOG
|
|
|
|
case 0x212a: {
|
2016-06-14 10:51:54 +00:00
|
|
|
window.r.bg1.mask = data.bits(0,1);
|
|
|
|
window.r.bg2.mask = data.bits(2,3);
|
|
|
|
window.r.bg3.mask = data.bits(4,5);
|
|
|
|
window.r.bg4.mask = data.bits(6,7);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//WOBJLOG
|
|
|
|
case 0x212b: {
|
2016-06-15 11:32:17 +00:00
|
|
|
window.r.obj.mask = data.bits(0,1);
|
2016-06-14 10:51:54 +00:00
|
|
|
window.r.col.mask = data.bits(2,3);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//TM
|
|
|
|
case 0x212c: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bg1.r.aboveEnable = data.bit(0);
|
|
|
|
bg2.r.aboveEnable = data.bit(1);
|
|
|
|
bg3.r.aboveEnable = data.bit(2);
|
|
|
|
bg4.r.aboveEnable = data.bit(3);
|
2016-06-15 11:32:17 +00:00
|
|
|
obj.r.aboveEnable = data.bit(4);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//TS
|
|
|
|
case 0x212d: {
|
2016-06-14 10:51:54 +00:00
|
|
|
bg1.r.belowEnable = data.bit(0);
|
|
|
|
bg2.r.belowEnable = data.bit(1);
|
|
|
|
bg3.r.belowEnable = data.bit(2);
|
|
|
|
bg4.r.belowEnable = data.bit(3);
|
2016-06-15 11:32:17 +00:00
|
|
|
obj.r.belowEnable = data.bit(4);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//TMW
|
|
|
|
case 0x212e: {
|
2016-06-14 10:51:54 +00:00
|
|
|
window.r.bg1.aboveEnable = data.bit(0);
|
|
|
|
window.r.bg2.aboveEnable = data.bit(1);
|
|
|
|
window.r.bg3.aboveEnable = data.bit(2);
|
|
|
|
window.r.bg4.aboveEnable = data.bit(3);
|
2016-06-15 11:32:17 +00:00
|
|
|
window.r.obj.aboveEnable = data.bit(4);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//TSW
|
|
|
|
case 0x212f: {
|
2016-06-14 10:51:54 +00:00
|
|
|
window.r.bg1.belowEnable = data.bit(0);
|
|
|
|
window.r.bg2.belowEnable = data.bit(1);
|
|
|
|
window.r.bg3.belowEnable = data.bit(2);
|
|
|
|
window.r.bg4.belowEnable = data.bit(3);
|
2016-06-15 11:32:17 +00:00
|
|
|
window.r.obj.belowEnable = data.bit(4);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//CGWSEL
|
|
|
|
case 0x2130: {
|
2016-06-14 10:51:54 +00:00
|
|
|
screen.r.directColor = data.bit (0);
|
|
|
|
screen.r.blendMode = data.bit (1);
|
|
|
|
window.r.col.belowMask = data.bits(4,5);
|
|
|
|
window.r.col.aboveMask = data.bits(6,7);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//CGADDSUB
|
|
|
|
case 0x2131: {
|
2016-06-14 10:51:54 +00:00
|
|
|
screen.r.bg1.colorEnable = data.bit(0);
|
|
|
|
screen.r.bg2.colorEnable = data.bit(1);
|
|
|
|
screen.r.bg3.colorEnable = data.bit(2);
|
|
|
|
screen.r.bg4.colorEnable = data.bit(3);
|
2016-06-15 11:32:17 +00:00
|
|
|
screen.r.obj.colorEnable = data.bit(4);
|
2016-06-14 10:51:54 +00:00
|
|
|
screen.r.back.colorEnable = data.bit(5);
|
|
|
|
screen.r.colorHalve = data.bit(6);
|
|
|
|
screen.r.colorMode = data.bit(7);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//COLDATA
|
|
|
|
case 0x2132: {
|
2016-06-14 10:51:54 +00:00
|
|
|
if(data.bit(5)) screen.r.colorRed = data.bits(0,4);
|
|
|
|
if(data.bit(6)) screen.r.colorGreen = data.bits(0,4);
|
|
|
|
if(data.bit(7)) screen.r.colorBlue = data.bits(0,4);
|
2016-04-09 05:20:41 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//SETINI
|
|
|
|
case 0x2133: {
|
2016-06-14 10:51:54 +00:00
|
|
|
r.interlace = data.bit(0);
|
2016-06-15 11:32:17 +00:00
|
|
|
obj.r.interlace = data.bit(1);
|
2016-06-14 10:51:54 +00:00
|
|
|
r.overscan = data.bit(2);
|
|
|
|
r.pseudoHires = data.bit(3);
|
|
|
|
r.extbg = data.bit(6);
|
2016-04-09 05:20:41 +00:00
|
|
|
updateVideoMode();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
auto PPU::latchCounters() -> void {
|
|
|
|
cpu.synchronizePPU();
|
2016-06-14 10:51:54 +00:00
|
|
|
r.hcounter = hdot();
|
|
|
|
r.vcounter = vcounter();
|
|
|
|
latch.counters = true;
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto PPU::updateVideoMode() -> void {
|
2016-06-14 10:51:54 +00:00
|
|
|
switch(r.bgMode) {
|
2016-04-09 05:20:41 +00:00
|
|
|
case 0:
|
2016-06-14 10:51:54 +00:00
|
|
|
bg1.r.mode = Background::Mode::BPP2;
|
|
|
|
bg2.r.mode = Background::Mode::BPP2;
|
|
|
|
bg3.r.mode = Background::Mode::BPP2;
|
|
|
|
bg4.r.mode = Background::Mode::BPP2;
|
|
|
|
memory::assign(bg1.r.priority, 8, 11);
|
|
|
|
memory::assign(bg2.r.priority, 7, 10);
|
|
|
|
memory::assign(bg3.r.priority, 2, 5);
|
|
|
|
memory::assign(bg4.r.priority, 1, 4);
|
2016-06-15 11:32:17 +00:00
|
|
|
memory::assign(obj.r.priority, 3, 6, 9, 12);
|
2016-04-09 05:20:41 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 1:
|
2016-06-14 10:51:54 +00:00
|
|
|
bg1.r.mode = Background::Mode::BPP4;
|
|
|
|
bg2.r.mode = Background::Mode::BPP4;
|
|
|
|
bg3.r.mode = Background::Mode::BPP2;
|
|
|
|
bg4.r.mode = Background::Mode::Inactive;
|
|
|
|
if(r.bgPriority) {
|
|
|
|
memory::assign(bg1.r.priority, 5, 8);
|
|
|
|
memory::assign(bg2.r.priority, 4, 7);
|
|
|
|
memory::assign(bg3.r.priority, 1, 10);
|
2016-06-15 11:32:17 +00:00
|
|
|
memory::assign(obj.r.priority, 2, 3, 6, 9);
|
2016-04-09 05:20:41 +00:00
|
|
|
} else {
|
2016-06-14 10:51:54 +00:00
|
|
|
memory::assign(bg1.r.priority, 6, 9);
|
|
|
|
memory::assign(bg2.r.priority, 5, 8);
|
|
|
|
memory::assign(bg3.r.priority, 1, 3);
|
2016-06-15 11:32:17 +00:00
|
|
|
memory::assign(obj.r.priority, 2, 4, 7, 10);
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 2:
|
2016-06-14 10:51:54 +00:00
|
|
|
bg1.r.mode = Background::Mode::BPP4;
|
|
|
|
bg2.r.mode = Background::Mode::BPP4;
|
|
|
|
bg3.r.mode = Background::Mode::Inactive;
|
|
|
|
bg4.r.mode = Background::Mode::Inactive;
|
|
|
|
memory::assign(bg1.r.priority, 3, 7);
|
|
|
|
memory::assign(bg2.r.priority, 1, 5);
|
2016-06-15 11:32:17 +00:00
|
|
|
memory::assign(obj.r.priority, 2, 4, 6, 8);
|
2016-04-09 05:20:41 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 3:
|
2016-06-14 10:51:54 +00:00
|
|
|
bg1.r.mode = Background::Mode::BPP8;
|
|
|
|
bg2.r.mode = Background::Mode::BPP4;
|
|
|
|
bg3.r.mode = Background::Mode::Inactive;
|
|
|
|
bg4.r.mode = Background::Mode::Inactive;
|
|
|
|
memory::assign(bg1.r.priority, 3, 7);
|
|
|
|
memory::assign(bg2.r.priority, 1, 5);
|
2016-06-15 11:32:17 +00:00
|
|
|
memory::assign(obj.r.priority, 2, 4, 6, 8);
|
2016-04-09 05:20:41 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 4:
|
2016-06-14 10:51:54 +00:00
|
|
|
bg1.r.mode = Background::Mode::BPP8;
|
|
|
|
bg2.r.mode = Background::Mode::BPP2;
|
|
|
|
bg3.r.mode = Background::Mode::Inactive;
|
|
|
|
bg4.r.mode = Background::Mode::Inactive;
|
|
|
|
memory::assign(bg1.r.priority, 3, 7);
|
|
|
|
memory::assign(bg2.r.priority, 1, 5);
|
2016-06-15 11:32:17 +00:00
|
|
|
memory::assign(obj.r.priority, 2, 4, 6, 8);
|
2016-04-09 05:20:41 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 5:
|
2016-06-14 10:51:54 +00:00
|
|
|
bg1.r.mode = Background::Mode::BPP4;
|
|
|
|
bg2.r.mode = Background::Mode::BPP2;
|
|
|
|
bg3.r.mode = Background::Mode::Inactive;
|
|
|
|
bg4.r.mode = Background::Mode::Inactive;
|
|
|
|
memory::assign(bg1.r.priority, 3, 7);
|
|
|
|
memory::assign(bg2.r.priority, 1, 5);
|
2016-06-15 11:32:17 +00:00
|
|
|
memory::assign(obj.r.priority, 2, 4, 6, 8);
|
2016-04-09 05:20:41 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 6:
|
2016-06-14 10:51:54 +00:00
|
|
|
bg1.r.mode = Background::Mode::BPP4;
|
|
|
|
bg2.r.mode = Background::Mode::Inactive;
|
|
|
|
bg3.r.mode = Background::Mode::Inactive;
|
|
|
|
bg4.r.mode = Background::Mode::Inactive;
|
|
|
|
memory::assign(bg1.r.priority, 2, 5);
|
2016-06-15 11:32:17 +00:00
|
|
|
memory::assign(obj.r.priority, 1, 3, 4, 6);
|
2016-04-09 05:20:41 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 7:
|
2016-06-14 10:51:54 +00:00
|
|
|
if(!r.extbg) {
|
|
|
|
bg1.r.mode = Background::Mode::Mode7;
|
|
|
|
bg2.r.mode = Background::Mode::Inactive;
|
|
|
|
bg3.r.mode = Background::Mode::Inactive;
|
|
|
|
bg4.r.mode = Background::Mode::Inactive;
|
|
|
|
memory::assign(bg1.r.priority, 2);
|
2016-06-15 11:32:17 +00:00
|
|
|
memory::assign(obj.r.priority, 1, 3, 4, 5);
|
2016-04-09 05:20:41 +00:00
|
|
|
} else {
|
2016-06-14 10:51:54 +00:00
|
|
|
bg1.r.mode = Background::Mode::Mode7;
|
|
|
|
bg2.r.mode = Background::Mode::Mode7;
|
|
|
|
bg3.r.mode = Background::Mode::Inactive;
|
|
|
|
bg4.r.mode = Background::Mode::Inactive;
|
|
|
|
memory::assign(bg1.r.priority, 3);
|
|
|
|
memory::assign(bg2.r.priority, 1, 5);
|
2016-06-15 11:32:17 +00:00
|
|
|
memory::assign(obj.r.priority, 2, 4, 6, 7);
|
2016-04-09 05:20:41 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|