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

201 lines
5.6 KiB
C++
Raw Normal View History

Update to v087r14 release. byuu says: Fixed aforementioned issues. [From a previous post: - mul was using r(d) instead of r(n) for accumulate. - mull didn't remove c/v clear. - APU register mask was broken, so SOUNDBIAS was reading out wrong. - APU was only mapping 0x088 and not 0x089 as well. - Halfword reads in CPU+PPU+APU were all reading from the low address each time.] All CPU+PPU registers are now hooked up (not that they do anything.) SOUNDBIAS for APU was hooked up, got tired of working on it for the rest :P I recall from the GB APU that you can't just assign values for the APU MMIO regs. They do odd reload things as well. Also, was using MMIO read code like this: return ( (flaga << 0) || (flagb << 1) || (flagc << 2) ); Logical or doesn't work so well with building flags :P Bad habit from how I split multiple conditionals across several lines. So ... r14 is basically what r13 should have been yesterday, delaying my schedule by yet another day :(
2012-04-01 01:41:15 +00:00
uint8 PPU::read(uint32 addr) {
switch(addr) {
Update to v087r12 release. byuu says: Enough to get through the BIOS and into cartridge ROM. I am a bit annoyed that I was basically told that the GBA PPU wasn't that bad. Sprites are a clusterfuck, easily worse than Mode7, docs don't even begin to explain them in enough detail. This is going to be fun.
2012-03-31 08:14:31 +00:00
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +00:00
//DISPCNT
case 0x04000000: return regs.control >> 0;
case 0x04000001: return regs.control >> 8;
//GRSWP
case 0x04000002: return regs.greenswap;
case 0x04000003: return 0u;
//DISPSTAT
case 0x04000004: return regs.status >> 0;
case 0x04000005: return regs.status >> 8;
Update to v087r12 release. byuu says: Enough to get through the BIOS and into cartridge ROM. I am a bit annoyed that I was basically told that the GBA PPU wasn't that bad. Sprites are a clusterfuck, easily worse than Mode7, docs don't even begin to explain them in enough detail. This is going to be fun.
2012-03-31 08:14:31 +00:00
//VCOUNT
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +00:00
case 0x04000006: return regs.vcounter >> 0;
case 0x04000007: return regs.vcounter >> 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
//BG0CNT,BG1CNT,BG2CNT,BG3CNT
case 0x04000008: case 0x04000009:
case 0x0400000a: case 0x0400000b:
case 0x0400000c: case 0x0400000d:
case 0x0400000e: case 0x0400000f: {
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& bg = regs.bg[(addr >> 1) & 3];
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
unsigned shift = (addr & 1) * 8;
return bg.control >> shift;
}
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +00:00
//WININ
Update to v087r22 release. byuu says: Changelog: - fixed below pixel green channel on color blending - added semi-transparent objects [Exophase's method] - added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable) - EEPROM uses nall::bitarray now to be friendlier to saving memory to disk - removed incomplete mosaic support for now (too broken, untested) - improved sprite priority. Hopefully it's right now. Just about everything should look great now. It took 25 days, but we finally have the BIOS rendering correctly. In order to do OBJ windows, I had to drop my above/below buffers entirely. I went with the nuclear option. There's separate layers for all BGs and objects. I build the OBJ window table during object rendering. So as a result, after rendering I go back and apply windows (and the object window that now exists.) After that, I have to do a painful Z-buffer select of the top two most important pixels. Since I now know the layers, the blending enable tests are a lot nicer, at least. But this obviously has quite a speed hit: 390fps to 325fps for Mr. Driller 2 title screen. TONC says that "bad" window coordinates do really insane things. GBAtek says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240 ? 240 : x2; I like the GBAtek version more, so I went with that. I sure hope it's right ... but my guess is the hardware does this with a counter that wraps around or something. Also, say you have two OBJ mode 2 sprites that overlap each other, but with different priorities. The lower (more important) priority sprite has a clear pixel, but the higher priority sprite has a set pixel. Do we set the "inside OBJ window" flag to true here? Eg does the value OR, or does it hold the most important sprite's pixel value? Cydrak suspects it's OR-based, I concur from what I can see. Mosaic, I am at a loss. I really need a lot more information in order to implement it. For backgrounds, does it apply to the Vcounter of the entire screen? Or does it apply post-scroll? Or does it even apply after every adjust in affine/bitmap modes? I'm betting the hcounter background mosaic starts at the leftmost edge of the screen, and repeats previous pixels to apply the effect. Like SNES, very simple. For sprites, the SNES didn't have this. Does the mosaic grid start at (0,0) of the screen, or at (0,0) of each sprite? The latter will look a lot nicer, but be a lot more complex. Is mosaic on affine objects any different than mosaic of linear(tiled) objects? With that out of the way, we still have to fix the CPU memory access timing, add the rest of the CPU penalty cycles, the memory rotation / alignment / extend behavior needs to be fixed, the shifter desperately needs to be moved from loops to single shift operations, and I need to add flash memory support.
2012-04-13 11:49:32 +00:00
case 0x04000048: return regs.windowflags[In0];
case 0x04000049: return regs.windowflags[In1];
case 0x0400004a: return regs.windowflags[Out];
case 0x0400004b: return regs.windowflags[Obj];
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +00:00
//BLTCNT
case 0x04000050: return regs.blend.control >> 0;
case 0x04000051: return regs.blend.control >> 8;
Update to v087r12 release. byuu says: Enough to get through the BIOS and into cartridge ROM. I am a bit annoyed that I was basically told that the GBA PPU wasn't that bad. Sprites are a clusterfuck, easily worse than Mode7, docs don't even begin to explain them in enough detail. This is going to be fun.
2012-03-31 08:14:31 +00:00
}
return 0u;
}
Update to v087r14 release. byuu says: Fixed aforementioned issues. [From a previous post: - mul was using r(d) instead of r(n) for accumulate. - mull didn't remove c/v clear. - APU register mask was broken, so SOUNDBIAS was reading out wrong. - APU was only mapping 0x088 and not 0x089 as well. - Halfword reads in CPU+PPU+APU were all reading from the low address each time.] All CPU+PPU registers are now hooked up (not that they do anything.) SOUNDBIAS for APU was hooked up, got tired of working on it for the rest :P I recall from the GB APU that you can't just assign values for the APU MMIO regs. They do odd reload things as well. Also, was using MMIO read code like this: return ( (flaga << 0) || (flagb << 1) || (flagc << 2) ); Logical or doesn't work so well with building flags :P Bad habit from how I split multiple conditionals across several lines. So ... r14 is basically what r13 should have been yesterday, delaying my schedule by yet another day :(
2012-04-01 01:41:15 +00:00
void PPU::write(uint32 addr, uint8 byte) {
switch(addr) {
Update to v087r12 release. byuu says: Enough to get through the BIOS and into cartridge ROM. I am a bit annoyed that I was basically told that the GBA PPU wasn't that bad. Sprites are a clusterfuck, easily worse than Mode7, docs don't even begin to explain them in enough detail. This is going to be fun.
2012-03-31 08:14:31 +00:00
//DISPCNT
case 0x04000000: regs.control = (regs.control & 0xff00) | (byte << 0); return;
case 0x04000001: regs.control = (regs.control & 0x00ff) | (byte << 8); return;
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +00:00
//GRSWP
Update to v087r22 release. byuu says: Changelog: - fixed below pixel green channel on color blending - added semi-transparent objects [Exophase's method] - added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable) - EEPROM uses nall::bitarray now to be friendlier to saving memory to disk - removed incomplete mosaic support for now (too broken, untested) - improved sprite priority. Hopefully it's right now. Just about everything should look great now. It took 25 days, but we finally have the BIOS rendering correctly. In order to do OBJ windows, I had to drop my above/below buffers entirely. I went with the nuclear option. There's separate layers for all BGs and objects. I build the OBJ window table during object rendering. So as a result, after rendering I go back and apply windows (and the object window that now exists.) After that, I have to do a painful Z-buffer select of the top two most important pixels. Since I now know the layers, the blending enable tests are a lot nicer, at least. But this obviously has quite a speed hit: 390fps to 325fps for Mr. Driller 2 title screen. TONC says that "bad" window coordinates do really insane things. GBAtek says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240 ? 240 : x2; I like the GBAtek version more, so I went with that. I sure hope it's right ... but my guess is the hardware does this with a counter that wraps around or something. Also, say you have two OBJ mode 2 sprites that overlap each other, but with different priorities. The lower (more important) priority sprite has a clear pixel, but the higher priority sprite has a set pixel. Do we set the "inside OBJ window" flag to true here? Eg does the value OR, or does it hold the most important sprite's pixel value? Cydrak suspects it's OR-based, I concur from what I can see. Mosaic, I am at a loss. I really need a lot more information in order to implement it. For backgrounds, does it apply to the Vcounter of the entire screen? Or does it apply post-scroll? Or does it even apply after every adjust in affine/bitmap modes? I'm betting the hcounter background mosaic starts at the leftmost edge of the screen, and repeats previous pixels to apply the effect. Like SNES, very simple. For sprites, the SNES didn't have this. Does the mosaic grid start at (0,0) of the screen, or at (0,0) of each sprite? The latter will look a lot nicer, but be a lot more complex. Is mosaic on affine objects any different than mosaic of linear(tiled) objects? With that out of the way, we still have to fix the CPU memory access timing, add the rest of the CPU penalty cycles, the memory rotation / alignment / extend behavior needs to be fixed, the shifter desperately needs to be moved from loops to single shift operations, and I need to add flash memory support.
2012-04-13 11:49:32 +00:00
case 0x04000002: regs.greenswap = byte >> 0; return;
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +00:00
case 0x04000003: return;
//DISPSTAT
case 0x04000004:
Update to v087r22 release. byuu says: Changelog: - fixed below pixel green channel on color blending - added semi-transparent objects [Exophase's method] - added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable) - EEPROM uses nall::bitarray now to be friendlier to saving memory to disk - removed incomplete mosaic support for now (too broken, untested) - improved sprite priority. Hopefully it's right now. Just about everything should look great now. It took 25 days, but we finally have the BIOS rendering correctly. In order to do OBJ windows, I had to drop my above/below buffers entirely. I went with the nuclear option. There's separate layers for all BGs and objects. I build the OBJ window table during object rendering. So as a result, after rendering I go back and apply windows (and the object window that now exists.) After that, I have to do a painful Z-buffer select of the top two most important pixels. Since I now know the layers, the blending enable tests are a lot nicer, at least. But this obviously has quite a speed hit: 390fps to 325fps for Mr. Driller 2 title screen. TONC says that "bad" window coordinates do really insane things. GBAtek says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240 ? 240 : x2; I like the GBAtek version more, so I went with that. I sure hope it's right ... but my guess is the hardware does this with a counter that wraps around or something. Also, say you have two OBJ mode 2 sprites that overlap each other, but with different priorities. The lower (more important) priority sprite has a clear pixel, but the higher priority sprite has a set pixel. Do we set the "inside OBJ window" flag to true here? Eg does the value OR, or does it hold the most important sprite's pixel value? Cydrak suspects it's OR-based, I concur from what I can see. Mosaic, I am at a loss. I really need a lot more information in order to implement it. For backgrounds, does it apply to the Vcounter of the entire screen? Or does it apply post-scroll? Or does it even apply after every adjust in affine/bitmap modes? I'm betting the hcounter background mosaic starts at the leftmost edge of the screen, and repeats previous pixels to apply the effect. Like SNES, very simple. For sprites, the SNES didn't have this. Does the mosaic grid start at (0,0) of the screen, or at (0,0) of each sprite? The latter will look a lot nicer, but be a lot more complex. Is mosaic on affine objects any different than mosaic of linear(tiled) objects? With that out of the way, we still have to fix the CPU memory access timing, add the rest of the CPU penalty cycles, the memory rotation / alignment / extend behavior needs to be fixed, the shifter desperately needs to be moved from loops to single shift operations, and I need to add flash memory support.
2012-04-13 11:49:32 +00:00
regs.status.irqvblank = byte >> 3;
regs.status.irqhblank = byte >> 4;
regs.status.irqvcoincidence = byte >> 5;
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +00:00
return;
case 0x04000005:
Update to v087r19 release. byuu says: Changelog: - added FIFO buffer emulation (with DMA and all that jazz) [Cydrak] - fixed timers and vcounter assign [Cydrak] - emulated EEPROM (you have to change size manually for 14-bit mode, we need a database badly now) [SMA runs now] - removed OAM array, now decoding directly to struct Object {} [128] and ObjectParam {} [32] (faster this way) - check forceblank (still doesn't remove all garble between transitions, though??) - lots of other stuff Delete your settings.cfg, or manually change frequencyGBA to 32768, or bad things will happen (this may change back to 256KHz-4MHz later.) 15 of 16 games are fully playable now, and look and sound great. The major missing detail right now is PPU blending support, and we really need to optimize the hell out of the code.
2012-04-09 06:19:32 +00:00
regs.status.vcompare = byte;
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +00:00
return;
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
//BG0CNT,BG1CNT,BG2CNT,BG3CNT
case 0x04000008: case 0x04000009:
case 0x0400000a: case 0x0400000b:
case 0x0400000c: case 0x0400000d:
case 0x0400000e: case 0x0400000f: {
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& bg = regs.bg[(addr >> 1) & 3];
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
unsigned shift = (addr & 1) * 8;
bg.control = (bg.control & ~(255 << shift)) | (byte << shift);
return;
}
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +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
//BG0HOFS,BG1HOFS,BG2BOFS,BG3HOFS
case 0x04000010: case 0x04000011:
case 0x04000014: case 0x04000015:
case 0x04000018: case 0x04000019:
case 0x0400001c: case 0x0400001d: {
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& bg = regs.bg[(addr >> 2) & 3];
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
unsigned shift = (addr & 1) * 8;
bg.hoffset = (bg.hoffset & ~(255 << shift)) | (byte << shift);
return;
}
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +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
//BG0VOFS,BG1VOFS,BG2VOFS,BG3VOFS
case 0x04000012: case 0x04000013:
case 0x04000016: case 0x04000017:
case 0x0400001a: case 0x0400001b:
case 0x0400001e: case 0x0400001f: {
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& bg = regs.bg[(addr >> 2) & 3];
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
unsigned shift = (addr & 1) * 8;
bg.voffset = (bg.voffset & ~(255 << shift)) | (byte << shift);
return;
}
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +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
//BG2PA,BG3PA
case 0x04000020: case 0x04000021:
case 0x04000030: case 0x04000031: {
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& bg = regs.bg[(addr >> 4) & 3];
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
unsigned shift = (addr & 1) * 8;
bg.pa = (bg.pa & ~(255 << shift)) | (byte << shift);
return;
}
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +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
//BG2PB,BG3PB
case 0x04000022: case 0x04000023:
case 0x04000032: case 0x04000033: {
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& bg = regs.bg[(addr >> 4) & 3];
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
unsigned shift = (addr & 1) * 8;
bg.pb = (bg.pb & ~(255 << shift)) | (byte << shift);
return;
}
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +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
//BG2PC,BG3PC
case 0x04000024: case 0x04000025:
case 0x04000034: case 0x04000035: {
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& bg = regs.bg[(addr >> 4) & 3];
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
unsigned shift = (addr & 1) * 8;
bg.pc = (bg.pc & ~(255 << shift)) | (byte << shift);
return;
}
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +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
//BG2PD,BG3PD
case 0x04000026: case 0x04000027:
case 0x04000036: case 0x04000037: {
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& bg = regs.bg[(addr >> 4) & 3];
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
unsigned shift = (addr & 1) * 8;
bg.pd = (bg.pd & ~(255 << shift)) | (byte << shift);
return;
}
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +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
//BG2X_L,BG2X_H,BG3X_L,BG3X_H
case 0x04000028: case 0x04000029: case 0x0400002a: case 0x0400002b:
case 0x04000038: case 0x04000039: case 0x0400003a: case 0x0400003b: {
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& bg = regs.bg[(addr >> 4) & 3];
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
unsigned shift = (addr & 3) * 8;
bg.lx = bg.x = (bg.x & ~(255 << shift)) | (byte << shift);
return;
}
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +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
//BG2Y_L,BG2Y_H,BG3Y_L,BG3Y_H
case 0x0400002c: case 0x0400002d: case 0x0400002e: case 0x0400002f:
case 0x0400003c: case 0x0400003d: case 0x0400003e: case 0x0400003f: {
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& bg = regs.bg[(addr >> 4) & 3];
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
unsigned shift = (addr & 3) * 8;
bg.ly = bg.y = (bg.y & ~(255 << shift)) | (byte << shift);
return;
}
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +00:00
//WIN0H
case 0x04000040: regs.window[0].x2 = byte; return;
case 0x04000041: regs.window[0].x1 = byte; return;
//WIN1H
case 0x04000042: regs.window[1].x2 = byte; return;
case 0x04000043: regs.window[1].x1 = byte; return;
//WIN0V
case 0x04000044: regs.window[0].y2 = byte; return;
case 0x04000045: regs.window[0].y1 = byte; return;
//WIN1V
case 0x04000046: regs.window[1].y2 = byte; return;
case 0x04000047: regs.window[1].y1 = byte; return;
//WININ
Update to v087r22 release. byuu says: Changelog: - fixed below pixel green channel on color blending - added semi-transparent objects [Exophase's method] - added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable) - EEPROM uses nall::bitarray now to be friendlier to saving memory to disk - removed incomplete mosaic support for now (too broken, untested) - improved sprite priority. Hopefully it's right now. Just about everything should look great now. It took 25 days, but we finally have the BIOS rendering correctly. In order to do OBJ windows, I had to drop my above/below buffers entirely. I went with the nuclear option. There's separate layers for all BGs and objects. I build the OBJ window table during object rendering. So as a result, after rendering I go back and apply windows (and the object window that now exists.) After that, I have to do a painful Z-buffer select of the top two most important pixels. Since I now know the layers, the blending enable tests are a lot nicer, at least. But this obviously has quite a speed hit: 390fps to 325fps for Mr. Driller 2 title screen. TONC says that "bad" window coordinates do really insane things. GBAtek says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240 ? 240 : x2; I like the GBAtek version more, so I went with that. I sure hope it's right ... but my guess is the hardware does this with a counter that wraps around or something. Also, say you have two OBJ mode 2 sprites that overlap each other, but with different priorities. The lower (more important) priority sprite has a clear pixel, but the higher priority sprite has a set pixel. Do we set the "inside OBJ window" flag to true here? Eg does the value OR, or does it hold the most important sprite's pixel value? Cydrak suspects it's OR-based, I concur from what I can see. Mosaic, I am at a loss. I really need a lot more information in order to implement it. For backgrounds, does it apply to the Vcounter of the entire screen? Or does it apply post-scroll? Or does it even apply after every adjust in affine/bitmap modes? I'm betting the hcounter background mosaic starts at the leftmost edge of the screen, and repeats previous pixels to apply the effect. Like SNES, very simple. For sprites, the SNES didn't have this. Does the mosaic grid start at (0,0) of the screen, or at (0,0) of each sprite? The latter will look a lot nicer, but be a lot more complex. Is mosaic on affine objects any different than mosaic of linear(tiled) objects? With that out of the way, we still have to fix the CPU memory access timing, add the rest of the CPU penalty cycles, the memory rotation / alignment / extend behavior needs to be fixed, the shifter desperately needs to be moved from loops to single shift operations, and I need to add flash memory support.
2012-04-13 11:49:32 +00:00
case 0x04000048: regs.windowflags[In0] = byte; return;
case 0x04000049: regs.windowflags[In1] = byte; return;
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +00:00
//WINOUT
Update to v087r22 release. byuu says: Changelog: - fixed below pixel green channel on color blending - added semi-transparent objects [Exophase's method] - added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable) - EEPROM uses nall::bitarray now to be friendlier to saving memory to disk - removed incomplete mosaic support for now (too broken, untested) - improved sprite priority. Hopefully it's right now. Just about everything should look great now. It took 25 days, but we finally have the BIOS rendering correctly. In order to do OBJ windows, I had to drop my above/below buffers entirely. I went with the nuclear option. There's separate layers for all BGs and objects. I build the OBJ window table during object rendering. So as a result, after rendering I go back and apply windows (and the object window that now exists.) After that, I have to do a painful Z-buffer select of the top two most important pixels. Since I now know the layers, the blending enable tests are a lot nicer, at least. But this obviously has quite a speed hit: 390fps to 325fps for Mr. Driller 2 title screen. TONC says that "bad" window coordinates do really insane things. GBAtek says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240 ? 240 : x2; I like the GBAtek version more, so I went with that. I sure hope it's right ... but my guess is the hardware does this with a counter that wraps around or something. Also, say you have two OBJ mode 2 sprites that overlap each other, but with different priorities. The lower (more important) priority sprite has a clear pixel, but the higher priority sprite has a set pixel. Do we set the "inside OBJ window" flag to true here? Eg does the value OR, or does it hold the most important sprite's pixel value? Cydrak suspects it's OR-based, I concur from what I can see. Mosaic, I am at a loss. I really need a lot more information in order to implement it. For backgrounds, does it apply to the Vcounter of the entire screen? Or does it apply post-scroll? Or does it even apply after every adjust in affine/bitmap modes? I'm betting the hcounter background mosaic starts at the leftmost edge of the screen, and repeats previous pixels to apply the effect. Like SNES, very simple. For sprites, the SNES didn't have this. Does the mosaic grid start at (0,0) of the screen, or at (0,0) of each sprite? The latter will look a lot nicer, but be a lot more complex. Is mosaic on affine objects any different than mosaic of linear(tiled) objects? With that out of the way, we still have to fix the CPU memory access timing, add the rest of the CPU penalty cycles, the memory rotation / alignment / extend behavior needs to be fixed, the shifter desperately needs to be moved from loops to single shift operations, and I need to add flash memory support.
2012-04-13 11:49:32 +00:00
case 0x0400004a: regs.windowflags[Out] = byte; return;
case 0x0400004b: regs.windowflags[Obj] = byte; return;
Update to v087r13 release. byuu says: Contains all of Cydrak's fixes, sans PPU. On the PPU front, I've hooked up 100% of read and write registers. All three DISPSTAT IRQs (Vblank, Hblank, Vcoincidence) are connected now as well. Super Mario Advance now runs without *appearing* to crash, although it's hard to tell since I have no video or sound :P ARM Wrestler is known to run, as is the BIOS.
2012-03-31 08:17:36 +00:00
//MOSAIC
case 0x0400004c:
regs.mosaic.bghsize = byte >> 0;
regs.mosaic.bgvsize = byte >> 4;
return;
case 0x0400004d:
regs.mosaic.objhsize = byte >> 0;
regs.mosaic.objvsize = byte >> 4;
return;
//BLDCNT
case 0x04000050: regs.blend.control = (regs.blend.control & 0xff00) | (byte << 0); return;
case 0x04000051: regs.blend.control = (regs.blend.control & 0x00ff) | (byte << 8); return;
//BLDALPHA
case 0x04000052: regs.blend.eva = std::min(16, byte & 0x1f); return;
case 0x04000053: regs.blend.evb = std::min(16, byte & 0x1f); return;
//BLDY
case 0x04000054: regs.blend.evy = std::min(16, byte & 0x1f); return;
case 0x04000055: return;
Update to v087r12 release. byuu says: Enough to get through the BIOS and into cartridge ROM. I am a bit annoyed that I was basically told that the GBA PPU wasn't that bad. Sprites are a clusterfuck, easily worse than Mode7, docs don't even begin to explain them in enough detail. This is going to be fun.
2012-03-31 08:14:31 +00:00
}
}