bsnes/higan/gba/ppu/ppu.cpp

189 lines
4.4 KiB
C++
Raw Normal View History

#include <gba/gba.hpp>
//pixel: 4 cycles
//hdraw: 240 pixels ( 960 cycles)
//hblank: 68 pixels ( 272 cycles)
//scanline: 308 pixels (1232 cycles)
//vdraw: 160 scanlines (197120 cycles)
//vblank: 68 scanlines ( 83776 cycles)
//frame: 228 scanlines (280896 cycles)
namespace GameBoyAdvance {
PPU ppu;
#include "background.cpp"
#include "object.cpp"
Update to v087r28 release. byuu says: Be sure to run make install, and move required images to their appropriate system profile folders. I still have no warnings in place if those images aren't present. Changelog: - OBJ mosaic should hopefully be emulated correctly now (thanks to krom and Cydrak for testing the hardware behavior) - emulated dummy serial registers, fixes Sonic Advance (you may still need to specify 512KB FlashROM with an appropriate ID, I used Panaonic's) - GBA core exits scheduler (PPU thread) and calls interface->videoRefresh() from main thread (not required, just nice) - SRAM, FRAM, EEPROM and FlashROM initialized to 0xFF if it does not exist (probably not needed, but FlashROM likes to reset to 0xFF anyway) - GBA manifest.xml for file-mode will now use "gamename.xml" instead of "gamename.gba.xml" - started renaming "NES" to "Famicom" and "SNES" to "Super Famicom" in the GUI (may or may not change source code in the long-term) - removed target-libsnes/ - added profile/ Profiles are the major new feature. So far we have: Famicom.sys/{nothing (yet?)} Super Famicom.sys/{ipl.rom} Game Boy.sys/{boot.rom} Game Boy Color.sys/{boot.rom} Game Boy Advance.sys/{bios.rom[not included]} Super Game Boy.sfc/{boot.rom,program.rom[not included]} BS-X Satellaview.sfc/{program.rom,bsx.ram,bsx.pram} Sufami Turbo.sfc/{program.rom} The SGB, BSX and ST cartridges ask you to load GB, BS or ST cartridges directly now. No slot loader for them. So the obvious downsides: you can't quickly pick between different SGB BIOSes, but why would you want to? Just use SGB2/JP. It's still possible, so I'll sacrifice a little complexity for a rare case to make it a lot easier for the more common case. ST cartridges currently won't let you load the secondary slot. BS-X Town cart is the only useful game to load with nothing in the slot, but only barely, since games are all seeded on flash and not on PSRAM images. We can revisit a way to boot the BIOS directly if and when we get the satellite uplink emulated and data can be downloaded onto the PSRAM :P BS-X slotted cartridges still require the secondary slot. My plan for BS-X slotted cartridges is to require a manifest.xml to specify that it has the BS-X slot present. Otherwise, we have to load the ROM into the SNES cartridge class, and parse its header before we can find out if it has one. Screw that. If it's in the XML, I can tell before loading the ROM if I need to present you with an optional slot loading dialog. I will probably do something similar for Sufami Turbo. Not all games even work with a secondary slot, so why ask you to load a second slot for them? Let the XML request a second slot. A complete Sufami Turbo ROM set will be trivial anyway. Not sure how I want to do the sub dialog yet. We want basic file loading, but we don't want it to look like the dialog 'didn't do anything' if it pops back open immediately again. Maybe change the background color of the dialog to a darker gray? Tacky, but it'd give you the visual cue without the need for some subtle text changes.
2012-04-18 13:58:04 +00:00
#include "mosaic.cpp"
#include "screen.cpp"
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
#include "io.cpp"
#include "memory.cpp"
#include "serialization.cpp"
PPU::PPU() {
output = new uint32[240 * 160];
regs.bg[0].id = BG0;
regs.bg[1].id = BG1;
regs.bg[2].id = BG2;
regs.bg[3].id = BG3;
}
PPU::~PPU() {
delete[] output;
}
auto PPU::Enter() -> void {
while(true) scheduler.synchronize(), ppu.main();
}
auto PPU::main() -> void {
scanline();
}
auto PPU::step(uint clocks) -> void {
clock += clocks;
if(clock >= 0 && !scheduler.synchronizing()) co_switch(cpu.thread);
}
auto PPU::power() -> void {
create(PPU::Enter, 16'777'216);
for(uint n = 0; n < 240 * 160; n++) output[n] = 0;
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
for(uint n = 0; n < 1024; n += 2) writePRAM(n, Half, 0x0000);
for(uint n = 0; n < 1024; n += 2) writeOAM(n, Half, 0x0000);
regs.control.bgmode = 0;
regs.control.cgbmode = 0;
regs.control.frame = 0;
regs.control.hblank = 0;
regs.control.objmapping = 0;
regs.control.forceblank = 0;
for(auto& enable : regs.control.enable) enable = 0;
for(auto& enablewindow : regs.control.enablewindow) enablewindow = 0;
regs.greenswap = 0;
regs.status.vblank = 0;
regs.status.hblank = 0;
regs.status.vcoincidence = 0;
regs.status.irqvblank = 0;
regs.status.irqhblank = 0;
regs.status.irqvcoincidence = 0;
regs.status.vcompare = 0;
regs.vcounter = 0;
for(auto& bg : regs.bg) {
bg.control.priority = 0;
bg.control.characterbaseblock = 0;
bg.control.unused = 0;
bg.control.mosaic = 0;
bg.control.colormode = 0;
bg.control.screenbaseblock = 0;
bg.control.affinewrap = 0;
bg.control.screensize = 0;
bg.hoffset = 0;
bg.voffset = 0;
bg.pa = 0;
bg.pb = 0;
bg.pc = 0;
bg.pd = 0;
bg.x = 0;
bg.y = 0;
bg.lx = 0;
bg.ly = 0;
}
for(auto& w : regs.window) {
w.x1 = 0;
w.x2 = 0;
w.y1 = 0;
w.y2 = 0;
}
for(auto& flags : regs.windowflags) {
for(auto& enable : flags.enable) enable = 0;
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.mosaic.bghsize = 0;
regs.mosaic.bgvsize = 0;
regs.mosaic.objhsize = 0;
regs.mosaic.objvsize = 0;
for(auto& above : regs.blend.control.above) above = 0;
regs.blend.control.mode = 0;
for(auto& below : regs.blend.control.below) below = 0;
regs.blend.eva = 0;
regs.blend.evb = 0;
regs.blend.evy = 0;
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
for(uint n = 0x000; n <= 0x055; n++) bus.io[n] = this;
}
auto PPU::scanline() -> void {
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
cpu.keypadRun();
regs.status.vblank = regs.vcounter >= 160 && regs.vcounter <= 226;
regs.status.vcoincidence = regs.vcounter == regs.status.vcompare;
if(regs.vcounter == 0) {
frame();
regs.bg[2].lx = regs.bg[2].x;
regs.bg[2].ly = regs.bg[2].y;
regs.bg[3].lx = regs.bg[3].x;
regs.bg[3].ly = regs.bg[3].y;
}
if(regs.vcounter == 160) {
if(regs.status.irqvblank) cpu.regs.irq.flag |= CPU::Interrupt::VBlank;
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
cpu.dmaVblank();
}
if(regs.status.irqvcoincidence) {
if(regs.status.vcoincidence) cpu.regs.irq.flag |= CPU::Interrupt::VCoincidence;
}
if(regs.vcounter < 160) {
if(regs.control.forceblank || cpu.regs.mode == CPU::Registers::Mode::Stop) {
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
renderForceBlank();
} else {
for(auto x : range(240)) {
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
windowmask[0][x] = false;
windowmask[1][x] = false;
windowmask[2][x] = false;
Update to v087r28 release. byuu says: Be sure to run make install, and move required images to their appropriate system profile folders. I still have no warnings in place if those images aren't present. Changelog: - OBJ mosaic should hopefully be emulated correctly now (thanks to krom and Cydrak for testing the hardware behavior) - emulated dummy serial registers, fixes Sonic Advance (you may still need to specify 512KB FlashROM with an appropriate ID, I used Panaonic's) - GBA core exits scheduler (PPU thread) and calls interface->videoRefresh() from main thread (not required, just nice) - SRAM, FRAM, EEPROM and FlashROM initialized to 0xFF if it does not exist (probably not needed, but FlashROM likes to reset to 0xFF anyway) - GBA manifest.xml for file-mode will now use "gamename.xml" instead of "gamename.gba.xml" - started renaming "NES" to "Famicom" and "SNES" to "Super Famicom" in the GUI (may or may not change source code in the long-term) - removed target-libsnes/ - added profile/ Profiles are the major new feature. So far we have: Famicom.sys/{nothing (yet?)} Super Famicom.sys/{ipl.rom} Game Boy.sys/{boot.rom} Game Boy Color.sys/{boot.rom} Game Boy Advance.sys/{bios.rom[not included]} Super Game Boy.sfc/{boot.rom,program.rom[not included]} BS-X Satellaview.sfc/{program.rom,bsx.ram,bsx.pram} Sufami Turbo.sfc/{program.rom} The SGB, BSX and ST cartridges ask you to load GB, BS or ST cartridges directly now. No slot loader for them. So the obvious downsides: you can't quickly pick between different SGB BIOSes, but why would you want to? Just use SGB2/JP. It's still possible, so I'll sacrifice a little complexity for a rare case to make it a lot easier for the more common case. ST cartridges currently won't let you load the secondary slot. BS-X Town cart is the only useful game to load with nothing in the slot, but only barely, since games are all seeded on flash and not on PSRAM images. We can revisit a way to boot the BIOS directly if and when we get the satellite uplink emulated and data can be downloaded onto the PSRAM :P BS-X slotted cartridges still require the secondary slot. My plan for BS-X slotted cartridges is to require a manifest.xml to specify that it has the BS-X slot present. Otherwise, we have to load the ROM into the SNES cartridge class, and parse its header before we can find out if it has one. Screw that. If it's in the XML, I can tell before loading the ROM if I need to present you with an optional slot loading dialog. I will probably do something similar for Sufami Turbo. Not all games even work with a secondary slot, so why ask you to load a second slot for them? Let the XML request a second slot. A complete Sufami Turbo ROM set will be trivial anyway. Not sure how I want to do the sub dialog yet. We want basic file loading, but we don't want it to look like the dialog 'didn't do anything' if it pops back open immediately again. Maybe change the background color of the dialog to a darker gray? Tacky, but it'd give you the visual cue without the need for some subtle text changes.
2012-04-18 13:58:04 +00:00
layer[OBJ][x].write(false);
layer[BG0][x].write(false);
layer[BG1][x].write(false);
layer[BG2][x].write(false);
layer[BG3][x].write(false);
layer[SFX][x].write(true, 3, pram[0]);
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
}
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
renderWindow(0);
renderWindow(1);
renderObjects();
renderBackgrounds();
renderScreen();
}
}
step(960);
regs.status.hblank = 1;
if(regs.status.irqhblank) cpu.regs.irq.flag |= CPU::Interrupt::HBlank;
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
if(regs.vcounter < 160) cpu.dmaHblank();
step(240);
regs.status.hblank = 0;
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
if(regs.vcounter < 160) cpu.dmaHDMA();
step(32);
if(++regs.vcounter == 228) regs.vcounter = 0;
}
auto PPU::frame() -> void {
player.frame();
scheduler.exit(Scheduler::Event::Frame);
}
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
auto PPU::refresh() -> void {
Emulator::video.refresh(output, 240 * sizeof(uint32), 240, 160);
}
}