ShuriZma
/
bsnes
mirror of https://github.com/bsnes-emu/bsnes.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
bsnes/higan/gba/ppu/memory.cpp

177 lines
4.2 KiB
C++
Raw Normal View History

Update to v099r13 release. byuu says: Changelog: - GB core code cleanup completed - GBA core code cleanup completed - some more cleanup on missed processor/arm functions/variables - fixed FC loading icarus bug - "Load ROM File" icarus functionality restored - minor code unification efforts all around (not perfect yet) - MMIO->IO - mmio.cpp->io.cpp - read,write->readIO,writeIO It's been a very long work in progress ... starting all the way back with v094r09, but the major part of the higan code cleanup is now completed! Of course, it's very important to note that this is only for the basic style: - under_score functions and variables are now camelCase - return-type function-name() are now auto function-name() -> return-type - Natural<T>/Integer<T> replace (u)intT_n types where possible - signed/unsigned are now int/uint - most of the x==true,x==false tests changed to x,!x A lot of spot improvements to consistency, simplicity and quality have gone in along the way, of course. But we'll probably never fully finishing beautifying every last line of code in the entire codebase. Still, this is a really great start. Going forward, WIP diffs should start being smaller and of higher quality once again. I know the joke is, "until my coding style changes again", but ... this was way too stressful, way too time consuming, and way too risky. I'm too old and tired now for extreme upheavel like this again. The only major change I'm slowly mulling over would be renaming the using Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as easily confused with the (u)int_t types ... but we'll see. I'll definitely continue to change small things all the time, but for the larger picture, I need to just accept the style I have and live with it.
2016-06-29 11:10:28 +00:00
auto PPU::readVRAM(uint mode, uint32 addr) -> uint32 {
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
addr &= (addr & 0x10000) ? 0x17fff : 0x0ffff;
Update to v094r35 release. byuu says: GBA timings are *almost* perfect now. Off by 1-3 cycles on each test, sans a few DMA ones that seem to not run at all according to the numbers (crazy.)
2015-07-01 10:58:42 +00:00
if(mode & Word) {
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
addr &= ~3;
return vram[addr + 0] << 0 | vram[addr + 1] << 8 | vram[addr + 2] << 16 | vram[addr + 3] << 24;
Update to v094r35 release. byuu says: GBA timings are *almost* perfect now. Off by 1-3 cycles on each test, sans a few DMA ones that seem to not run at all according to the numbers (crazy.)
2015-07-01 10:58:42 +00:00
} else if(mode & Half) {
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
addr &= ~1;
return vram[addr + 0] << 0 | vram[addr + 1] << 8;
Update to v094r35 release. byuu says: GBA timings are *almost* perfect now. Off by 1-3 cycles on each test, sans a few DMA ones that seem to not run at all according to the numbers (crazy.)
2015-07-01 10:58:42 +00:00
} else if(mode & Byte) {
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
return vram[addr];
}
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
unreachable;
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
}
Update to v099r13 release. byuu says: Changelog: - GB core code cleanup completed - GBA core code cleanup completed - some more cleanup on missed processor/arm functions/variables - fixed FC loading icarus bug - "Load ROM File" icarus functionality restored - minor code unification efforts all around (not perfect yet) - MMIO->IO - mmio.cpp->io.cpp - read,write->readIO,writeIO It's been a very long work in progress ... starting all the way back with v094r09, but the major part of the higan code cleanup is now completed! Of course, it's very important to note that this is only for the basic style: - under_score functions and variables are now camelCase - return-type function-name() are now auto function-name() -> return-type - Natural<T>/Integer<T> replace (u)intT_n types where possible - signed/unsigned are now int/uint - most of the x==true,x==false tests changed to x,!x A lot of spot improvements to consistency, simplicity and quality have gone in along the way, of course. But we'll probably never fully finishing beautifying every last line of code in the entire codebase. Still, this is a really great start. Going forward, WIP diffs should start being smaller and of higher quality once again. I know the joke is, "until my coding style changes again", but ... this was way too stressful, way too time consuming, and way too risky. I'm too old and tired now for extreme upheavel like this again. The only major change I'm slowly mulling over would be renaming the using Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as easily confused with the (u)int_t types ... but we'll see. I'll definitely continue to change small things all the time, but for the larger picture, I need to just accept the style I have and live with it.
2016-06-29 11:10:28 +00:00
auto PPU::writeVRAM(uint mode, uint32 addr, uint32 word) -> void {
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
addr &= (addr & 0x10000) ? 0x17fff : 0x0ffff;
Update to v094r35 release. byuu says: GBA timings are *almost* perfect now. Off by 1-3 cycles on each test, sans a few DMA ones that seem to not run at all according to the numbers (crazy.)
2015-07-01 10:58:42 +00:00
if(mode & Word) {
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
addr &= ~3;
vram[addr + 0] = word >> 0;
vram[addr + 1] = word >> 8;
vram[addr + 2] = word >> 16;
vram[addr + 3] = word >> 24;
Update to v094r35 release. byuu says: GBA timings are *almost* perfect now. Off by 1-3 cycles on each test, sans a few DMA ones that seem to not run at all according to the numbers (crazy.)
2015-07-01 10:58:42 +00:00
} else if(mode & Half) {
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
addr &= ~1;
vram[addr + 0] = word >> 0;
vram[addr + 1] = word >> 8;
Update to v094r35 release. byuu says: GBA timings are *almost* perfect now. Off by 1-3 cycles on each test, sans a few DMA ones that seem to not run at all according to the numbers (crazy.)
2015-07-01 10:58:42 +00:00
} else if(mode & Byte) {
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
//8-bit writes to OBJ section of VRAM are ignored
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
if(Background::IO::mode <= 2 && addr >= 0x10000) return;
if(Background::IO::mode <= 5 && addr >= 0x14000) return;
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
addr &= ~1;
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
vram[addr + 0] = (uint8)word;
vram[addr + 1] = (uint8)word;
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
}
}
Update to v099r13 release. byuu says: Changelog: - GB core code cleanup completed - GBA core code cleanup completed - some more cleanup on missed processor/arm functions/variables - fixed FC loading icarus bug - "Load ROM File" icarus functionality restored - minor code unification efforts all around (not perfect yet) - MMIO->IO - mmio.cpp->io.cpp - read,write->readIO,writeIO It's been a very long work in progress ... starting all the way back with v094r09, but the major part of the higan code cleanup is now completed! Of course, it's very important to note that this is only for the basic style: - under_score functions and variables are now camelCase - return-type function-name() are now auto function-name() -> return-type - Natural<T>/Integer<T> replace (u)intT_n types where possible - signed/unsigned are now int/uint - most of the x==true,x==false tests changed to x,!x A lot of spot improvements to consistency, simplicity and quality have gone in along the way, of course. But we'll probably never fully finishing beautifying every last line of code in the entire codebase. Still, this is a really great start. Going forward, WIP diffs should start being smaller and of higher quality once again. I know the joke is, "until my coding style changes again", but ... this was way too stressful, way too time consuming, and way too risky. I'm too old and tired now for extreme upheavel like this again. The only major change I'm slowly mulling over would be renaming the using Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as easily confused with the (u)int_t types ... but we'll see. I'll definitely continue to change small things all the time, but for the larger picture, I need to just accept the style I have and live with it.
2016-06-29 11:10:28 +00:00
auto PPU::readPRAM(uint mode, uint32 addr) -> uint32 {
if(mode & Word) return readPRAM(Half, addr & ~2) << 0 | readPRAM(Half, addr | 2) << 16;
if(mode & Byte) return readPRAM(Half, addr) >> ((addr & 1) * 8);
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
return pram[addr >> 1 & 511];
}
Update to v099r13 release. byuu says: Changelog: - GB core code cleanup completed - GBA core code cleanup completed - some more cleanup on missed processor/arm functions/variables - fixed FC loading icarus bug - "Load ROM File" icarus functionality restored - minor code unification efforts all around (not perfect yet) - MMIO->IO - mmio.cpp->io.cpp - read,write->readIO,writeIO It's been a very long work in progress ... starting all the way back with v094r09, but the major part of the higan code cleanup is now completed! Of course, it's very important to note that this is only for the basic style: - under_score functions and variables are now camelCase - return-type function-name() are now auto function-name() -> return-type - Natural<T>/Integer<T> replace (u)intT_n types where possible - signed/unsigned are now int/uint - most of the x==true,x==false tests changed to x,!x A lot of spot improvements to consistency, simplicity and quality have gone in along the way, of course. But we'll probably never fully finishing beautifying every last line of code in the entire codebase. Still, this is a really great start. Going forward, WIP diffs should start being smaller and of higher quality once again. I know the joke is, "until my coding style changes again", but ... this was way too stressful, way too time consuming, and way too risky. I'm too old and tired now for extreme upheavel like this again. The only major change I'm slowly mulling over would be renaming the using Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as easily confused with the (u)int_t types ... but we'll see. I'll definitely continue to change small things all the time, but for the larger picture, I need to just accept the style I have and live with it.
2016-06-29 11:10:28 +00:00
auto PPU::writePRAM(uint mode, uint32 addr, uint32 word) -> void {
Update to v094r35 release. byuu says: GBA timings are *almost* perfect now. Off by 1-3 cycles on each test, sans a few DMA ones that seem to not run at all according to the numbers (crazy.)
2015-07-01 10:58:42 +00:00
if(mode & Word) {
Update to v099r13 release. byuu says: Changelog: - GB core code cleanup completed - GBA core code cleanup completed - some more cleanup on missed processor/arm functions/variables - fixed FC loading icarus bug - "Load ROM File" icarus functionality restored - minor code unification efforts all around (not perfect yet) - MMIO->IO - mmio.cpp->io.cpp - read,write->readIO,writeIO It's been a very long work in progress ... starting all the way back with v094r09, but the major part of the higan code cleanup is now completed! Of course, it's very important to note that this is only for the basic style: - under_score functions and variables are now camelCase - return-type function-name() are now auto function-name() -> return-type - Natural<T>/Integer<T> replace (u)intT_n types where possible - signed/unsigned are now int/uint - most of the x==true,x==false tests changed to x,!x A lot of spot improvements to consistency, simplicity and quality have gone in along the way, of course. But we'll probably never fully finishing beautifying every last line of code in the entire codebase. Still, this is a really great start. Going forward, WIP diffs should start being smaller and of higher quality once again. I know the joke is, "until my coding style changes again", but ... this was way too stressful, way too time consuming, and way too risky. I'm too old and tired now for extreme upheavel like this again. The only major change I'm slowly mulling over would be renaming the using Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as easily confused with the (u)int_t types ... but we'll see. I'll definitely continue to change small things all the time, but for the larger picture, I need to just accept the style I have and live with it.
2016-06-29 11:10:28 +00:00
writePRAM(Half, addr & ~2, word >> 0);
writePRAM(Half, addr | 2, word >> 16);
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
return;
}
Update to v094r35 release. byuu says: GBA timings are *almost* perfect now. Off by 1-3 cycles on each test, sans a few DMA ones that seem to not run at all according to the numbers (crazy.)
2015-07-01 10:58:42 +00:00
if(mode & Byte) {
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
word = (uint8)word;
Update to v099r13 release. byuu says: Changelog: - GB core code cleanup completed - GBA core code cleanup completed - some more cleanup on missed processor/arm functions/variables - fixed FC loading icarus bug - "Load ROM File" icarus functionality restored - minor code unification efforts all around (not perfect yet) - MMIO->IO - mmio.cpp->io.cpp - read,write->readIO,writeIO It's been a very long work in progress ... starting all the way back with v094r09, but the major part of the higan code cleanup is now completed! Of course, it's very important to note that this is only for the basic style: - under_score functions and variables are now camelCase - return-type function-name() are now auto function-name() -> return-type - Natural<T>/Integer<T> replace (u)intT_n types where possible - signed/unsigned are now int/uint - most of the x==true,x==false tests changed to x,!x A lot of spot improvements to consistency, simplicity and quality have gone in along the way, of course. But we'll probably never fully finishing beautifying every last line of code in the entire codebase. Still, this is a really great start. Going forward, WIP diffs should start being smaller and of higher quality once again. I know the joke is, "until my coding style changes again", but ... this was way too stressful, way too time consuming, and way too risky. I'm too old and tired now for extreme upheavel like this again. The only major change I'm slowly mulling over would be renaming the using Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as easily confused with the (u)int_t types ... but we'll see. I'll definitely continue to change small things all the time, but for the larger picture, I need to just accept the style I have and live with it.
2016-06-29 11:10:28 +00:00
return writePRAM(Half, addr, word << 8 | word << 0);
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
}
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
pram[addr >> 1 & 511] = (uint16)word;
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
}
Update to v099r13 release. byuu says: Changelog: - GB core code cleanup completed - GBA core code cleanup completed - some more cleanup on missed processor/arm functions/variables - fixed FC loading icarus bug - "Load ROM File" icarus functionality restored - minor code unification efforts all around (not perfect yet) - MMIO->IO - mmio.cpp->io.cpp - read,write->readIO,writeIO It's been a very long work in progress ... starting all the way back with v094r09, but the major part of the higan code cleanup is now completed! Of course, it's very important to note that this is only for the basic style: - under_score functions and variables are now camelCase - return-type function-name() are now auto function-name() -> return-type - Natural<T>/Integer<T> replace (u)intT_n types where possible - signed/unsigned are now int/uint - most of the x==true,x==false tests changed to x,!x A lot of spot improvements to consistency, simplicity and quality have gone in along the way, of course. But we'll probably never fully finishing beautifying every last line of code in the entire codebase. Still, this is a really great start. Going forward, WIP diffs should start being smaller and of higher quality once again. I know the joke is, "until my coding style changes again", but ... this was way too stressful, way too time consuming, and way too risky. I'm too old and tired now for extreme upheavel like this again. The only major change I'm slowly mulling over would be renaming the using Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as easily confused with the (u)int_t types ... but we'll see. I'll definitely continue to change small things all the time, but for the larger picture, I need to just accept the style I have and live with it.
2016-06-29 11:10:28 +00:00
auto PPU::readOAM(uint mode, uint32 addr) -> uint32 {
if(mode & Word) return readOAM(Half, addr & ~2) << 0 | readOAM(Half, addr | 2) << 16;
if(mode & Byte) return readOAM(Half, addr) >> ((addr & 1) * 8);
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
Update to v092r09 release. byuu says: This will be another massive diff from the previous version. All of higan was updated to use the new foo& bar syntax, and I also updated switch statements to be consistent as well (but not in the disassemblers, was starting to get an RSI just from what I already did.) phoenix/{windows, cocoa, qt} need to be updated to use "string foo" instead of "const string& foo", and after that, the major diffs should be finished. This archive is the first time I'm posting my copy-on-write, size+capacity nall::string class, so any feedback on that is welcome as well.
2013-05-05 09:21:30 +00:00
auto& obj = object[addr >> 3 & 127];
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
auto& par = objectParam[addr >> 5 & 31];
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
switch(addr & 6) {
case 0: return (
(obj.y << 0)
| (obj.affine << 8)
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
| (obj.affineSize << 9)
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
| (obj.mode << 10)
| (obj.mosaic << 12)
| (obj.colors << 13)
| (obj.shape << 14)
);
case 2: return (
(obj.x << 0)
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
| (obj.affineParam << 9)
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
| (obj.hflip << 12)
| (obj.vflip << 13)
| (obj.size << 14)
);
case 4: return (
(obj.character << 0)
| (obj.priority << 10)
| (obj.palette << 12)
);
case 6:
switch(addr >> 3 & 3) {
case 0: return par.pa;
case 1: return par.pb;
case 2: return par.pc;
case 3: return par.pd;
}
}
}
Update to v099r13 release. byuu says: Changelog: - GB core code cleanup completed - GBA core code cleanup completed - some more cleanup on missed processor/arm functions/variables - fixed FC loading icarus bug - "Load ROM File" icarus functionality restored - minor code unification efforts all around (not perfect yet) - MMIO->IO - mmio.cpp->io.cpp - read,write->readIO,writeIO It's been a very long work in progress ... starting all the way back with v094r09, but the major part of the higan code cleanup is now completed! Of course, it's very important to note that this is only for the basic style: - under_score functions and variables are now camelCase - return-type function-name() are now auto function-name() -> return-type - Natural<T>/Integer<T> replace (u)intT_n types where possible - signed/unsigned are now int/uint - most of the x==true,x==false tests changed to x,!x A lot of spot improvements to consistency, simplicity and quality have gone in along the way, of course. But we'll probably never fully finishing beautifying every last line of code in the entire codebase. Still, this is a really great start. Going forward, WIP diffs should start being smaller and of higher quality once again. I know the joke is, "until my coding style changes again", but ... this was way too stressful, way too time consuming, and way too risky. I'm too old and tired now for extreme upheavel like this again. The only major change I'm slowly mulling over would be renaming the using Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as easily confused with the (u)int_t types ... but we'll see. I'll definitely continue to change small things all the time, but for the larger picture, I need to just accept the style I have and live with it.
2016-06-29 11:10:28 +00:00
auto PPU::writeOAM(uint mode, uint32 addr, uint32 word) -> void {
Update to v094r35 release. byuu says: GBA timings are *almost* perfect now. Off by 1-3 cycles on each test, sans a few DMA ones that seem to not run at all according to the numbers (crazy.)
2015-07-01 10:58:42 +00:00
if(mode & Word) {
Update to v099r13 release. byuu says: Changelog: - GB core code cleanup completed - GBA core code cleanup completed - some more cleanup on missed processor/arm functions/variables - fixed FC loading icarus bug - "Load ROM File" icarus functionality restored - minor code unification efforts all around (not perfect yet) - MMIO->IO - mmio.cpp->io.cpp - read,write->readIO,writeIO It's been a very long work in progress ... starting all the way back with v094r09, but the major part of the higan code cleanup is now completed! Of course, it's very important to note that this is only for the basic style: - under_score functions and variables are now camelCase - return-type function-name() are now auto function-name() -> return-type - Natural<T>/Integer<T> replace (u)intT_n types where possible - signed/unsigned are now int/uint - most of the x==true,x==false tests changed to x,!x A lot of spot improvements to consistency, simplicity and quality have gone in along the way, of course. But we'll probably never fully finishing beautifying every last line of code in the entire codebase. Still, this is a really great start. Going forward, WIP diffs should start being smaller and of higher quality once again. I know the joke is, "until my coding style changes again", but ... this was way too stressful, way too time consuming, and way too risky. I'm too old and tired now for extreme upheavel like this again. The only major change I'm slowly mulling over would be renaming the using Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as easily confused with the (u)int_t types ... but we'll see. I'll definitely continue to change small things all the time, but for the larger picture, I need to just accept the style I have and live with it.
2016-06-29 11:10:28 +00:00
writeOAM(Half, addr & ~2, word >> 0);
writeOAM(Half, addr | 2, word >> 16);
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
return;
}
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
if(mode & Byte) return; //8-bit writes to OAM are ignored
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
Update to v092r09 release. byuu says: This will be another massive diff from the previous version. All of higan was updated to use the new foo& bar syntax, and I also updated switch statements to be consistent as well (but not in the disassemblers, was starting to get an RSI just from what I already did.) phoenix/{windows, cocoa, qt} need to be updated to use "string foo" instead of "const string& foo", and after that, the major diffs should be finished. This archive is the first time I'm posting my copy-on-write, size+capacity nall::string class, so any feedback on that is welcome as well.
2013-05-05 09:21:30 +00:00
auto& obj = object[addr >> 3 & 127];
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
auto& par = objectParam[addr >> 5 & 31];
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
switch(addr & 6) {
case 0:
obj.y = word >> 0;
obj.affine = word >> 8;
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
obj.affineSize = word >> 9;
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
obj.mode = word >> 10;
obj.mosaic = word >> 12;
obj.colors = word >> 13;
obj.shape = word >> 14;
break;
case 2:
obj.x = word >> 0;
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
obj.affineParam = word >> 9;
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
obj.hflip = word >> 12;
obj.vflip = word >> 13;
obj.size = word >> 14;
break;
case 4:
obj.character = word >> 0;
obj.priority = word >> 10;
obj.palette = word >> 12;
break;
case 6:
switch(addr >> 3 & 3) {
case 0: par.pa = word; break;
case 1: par.pb = word; break;
case 2: par.pc = word; break;
case 3: par.pd = word; break;
}
}
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
static uint widths[] = {
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
8, 16, 32, 64,
16, 32, 32, 64,
8, 8, 16, 32,
8, 8, 8, 8, //invalid modes
};
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
static uint heights[] = {
Update to v087r20 release. byuu says: Changelog: - HALT waits 16 cycles before testing IRQs instead of 1 (probably less precise, but provides a massive speedup) [we will need to work on this later] - MMIO regs for CPU/PPU simplified by combining array accesses - custom VRAM/PRAM/OAM read/write functions that emulate 8->16-bit writes - 16-bit PRAM data (decent speedup) - emulated memory access speed (but don't handle non-sequential penalties or PPU access penalties yet) [amazingly, doesn't help speed at all] - misc. code cleanups For this WIP, FPS for Mr. Driller 2 went from 88fps to 172fps. Compatibility should be unchanged. Timers are still an interesting avenue to increase performance, but will be very tough to handle the 16MHz timers with eg a period of 65535 (overflow every single tick.) And that's basically the last major speed boost we'll be able to get. Blending and windowing is going to hurt performance, but it remains to be seen how much.
2012-04-09 06:41:27 +00:00
8, 16, 32, 64,
8, 8, 16, 32,
16, 32, 32, 64,
8, 8, 8, 8, //invalid modes
};
obj.width = widths [obj.shape * 4 + obj.size];
obj.height = heights[obj.shape * 4 + obj.size];
}
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
auto PPU::readObjectVRAM(uint addr) const -> uint8 {
if(Background::IO::mode == 3 || Background::IO::mode == 4 || Background::IO::mode == 5) {
if(addr <= 0x3fff) return 0u;
}
return vram[0x10000 + (addr & 0x7fff)];
}