Update to v085r08 release.
byuu says:
Changelog:
- follow the Laevateinn topic to get most of it
- also added NMI, IRQ step buttons to CPU debugger
- also added trace masking + trace mask reset
- also added memory export
- cartridge loading is entirely folder-based now
FitzRoy, I'll go ahead and make a second compromise with you for v086:
I'll match the following:
/path/to/SNES.sfc/*.sfc
/path/to/NES.fc/*.prg, *.chr (split format)
/path/to/NES.fc/*.fc (merged format)
/path/to/GB.gb/*.gb
/path/to/GBC.gbc/*.gbc
Condition will be that there can only be one of each file. If there's
more than one, it'll abort. That lets me name my ROMs as
"Game.fc/Game.fc", and you can name yours as "Game.fc/cartridge.prg,
cartridge.chr". Or whatever you want.
We'll just go with that, see what fares out as the most popular, and
then restrict it back to that method.
The folder must have the .fc, etc extension though. That will be how we
avoid false-positive folder matches.
[Editor's note - the Laevateinn topic mentions these changes for
v085r08:
Added SMP/PPU breakpoints, SMP debugger, SMP stepping / tracing,
memory editing on APU-bus / VRAM / OAM / CGRAM, save state menu,
WRAM mirroring on breakpoints, protected MMIO memory regions
(otherwise, viewing $002100 could crash your game.)
Major missing components:
- trace mask
- trace mask clear / usage map clear
- window geometry caching / sizing improvements
- VRAM viewer
- properties viewer
- working memory export button
The rest will most likely appear after v086 is released.
]
2012-02-12 05:35:40 +00:00
|
|
|
struct Window {
|
2010-08-09 13:28:56 +00:00
|
|
|
struct {
|
|
|
|
|
bool bg1_one_enable;
|
|
|
|
|
bool bg1_one_invert;
|
|
|
|
|
bool bg1_two_enable;
|
|
|
|
|
bool bg1_two_invert;
|
|
|
|
|
|
|
|
|
|
bool bg2_one_enable;
|
|
|
|
|
bool bg2_one_invert;
|
|
|
|
|
bool bg2_two_enable;
|
|
|
|
|
bool bg2_two_invert;
|
|
|
|
|
|
|
|
|
|
bool bg3_one_enable;
|
|
|
|
|
bool bg3_one_invert;
|
|
|
|
|
bool bg3_two_enable;
|
|
|
|
|
bool bg3_two_invert;
|
|
|
|
|
|
|
|
|
|
bool bg4_one_enable;
|
|
|
|
|
bool bg4_one_invert;
|
|
|
|
|
bool bg4_two_enable;
|
|
|
|
|
bool bg4_two_invert;
|
|
|
|
|
|
|
|
|
|
bool oam_one_enable;
|
|
|
|
|
bool oam_one_invert;
|
|
|
|
|
bool oam_two_enable;
|
|
|
|
|
bool oam_two_invert;
|
|
|
|
|
|
|
|
|
|
bool col_one_enable;
|
|
|
|
|
bool col_one_invert;
|
|
|
|
|
bool col_two_enable;
|
|
|
|
|
bool col_two_invert;
|
|
|
|
|
|
|
|
|
|
uint8 one_left;
|
|
|
|
|
uint8 one_right;
|
|
|
|
|
uint8 two_left;
|
|
|
|
|
uint8 two_right;
|
|
|
|
|
|
2011-04-27 08:57:31 +00:00
|
|
|
uint2 bg1_mask;
|
|
|
|
|
uint2 bg2_mask;
|
|
|
|
|
uint2 bg3_mask;
|
|
|
|
|
uint2 bg4_mask;
|
|
|
|
|
uint2 oam_mask;
|
|
|
|
|
uint2 col_mask;
|
2010-08-09 13:28:56 +00:00
|
|
|
|
|
|
|
|
bool bg1_main_enable;
|
|
|
|
|
bool bg1_sub_enable;
|
|
|
|
|
bool bg2_main_enable;
|
|
|
|
|
bool bg2_sub_enable;
|
|
|
|
|
bool bg3_main_enable;
|
|
|
|
|
bool bg3_sub_enable;
|
|
|
|
|
bool bg4_main_enable;
|
|
|
|
|
bool bg4_sub_enable;
|
|
|
|
|
bool oam_main_enable;
|
|
|
|
|
bool oam_sub_enable;
|
|
|
|
|
|
2011-04-27 08:57:31 +00:00
|
|
|
uint2 col_main_mask;
|
|
|
|
|
uint2 col_sub_mask;
|
2010-08-09 13:28:56 +00:00
|
|
|
} regs;
|
|
|
|
|
|
Update to v068r12 release.
(there was no r11 release posted to the WIP thread)
byuu says:
This took ten hours of mind boggling insanity to pull off.
It upgrades the S-PPU dot-based renderer to fetch one tile, and then
output all of its pixels before fetching again. It sounds easy enough,
but it's insanely difficult. I ended up taking one small shortcut, in
that rather than fetch at -7, I fetch at the first instance where a tile
is needed to plot to x=0. So if you have {-3 to +4 } as a tile, it
fetches at -3. That won't work so well on hardware, if two BGs fetch at
the same X offset, they won't have time.
I have had no luck staggering the reads at BG1=-7, BG3=-5, etc. While
I can shift and fetch just fine, what happens is that when a new tile is
fetched in, that gives a new palette, priority, etc; and this ends up
happening between two tiles which results in the right-most edges of the
screen ending up with the wrong colors and such.
Offset-per-tile is cheap as always. Although looking at it, I'm not sure
how BG3 could pre-fetch, especially with the way one or two OPT modes
can fetch two tiles.
There's no magic in Hoffset caching yet, so the SMW1 pixel issue is
still there.
Mode 7 got a bugfix, it was off-by-one horizontally from the mosaic
code. After re-designing the BG mosaic, I ended up needing a separate
mosaic for Mode7, and in the process I fixed that bug. The obvious
change is that the Chrono Trigger Mode7->Mode2 transition doesn't cause
the pendulum to jump anymore.
Windows were simplified just a tad. The range testing is shared for all
modes now. Ironically, it's a bit slower, but I'll take less code over
more speed for the accuracy core.
Speaking of speed, because there's so much less calculations per pixel
for BGs, performance for the entire emulator has gone up by 30% in the
accuracy core. Pretty neat overall, I can maintain 60fps in all but,
yeah you can guess can't you?
2010-09-04 03:36:03 +00:00
|
|
|
struct Output {
|
|
|
|
|
struct Pixel {
|
2010-08-09 13:28:56 +00:00
|
|
|
bool color_enable;
|
|
|
|
|
} main, sub;
|
|
|
|
|
} output;
|
|
|
|
|
|
Update to v068r12 release.
(there was no r11 release posted to the WIP thread)
byuu says:
This took ten hours of mind boggling insanity to pull off.
It upgrades the S-PPU dot-based renderer to fetch one tile, and then
output all of its pixels before fetching again. It sounds easy enough,
but it's insanely difficult. I ended up taking one small shortcut, in
that rather than fetch at -7, I fetch at the first instance where a tile
is needed to plot to x=0. So if you have {-3 to +4 } as a tile, it
fetches at -3. That won't work so well on hardware, if two BGs fetch at
the same X offset, they won't have time.
I have had no luck staggering the reads at BG1=-7, BG3=-5, etc. While
I can shift and fetch just fine, what happens is that when a new tile is
fetched in, that gives a new palette, priority, etc; and this ends up
happening between two tiles which results in the right-most edges of the
screen ending up with the wrong colors and such.
Offset-per-tile is cheap as always. Although looking at it, I'm not sure
how BG3 could pre-fetch, especially with the way one or two OPT modes
can fetch two tiles.
There's no magic in Hoffset caching yet, so the SMW1 pixel issue is
still there.
Mode 7 got a bugfix, it was off-by-one horizontally from the mosaic
code. After re-designing the BG mosaic, I ended up needing a separate
mosaic for Mode7, and in the process I fixed that bug. The obvious
change is that the Chrono Trigger Mode7->Mode2 transition doesn't cause
the pendulum to jump anymore.
Windows were simplified just a tad. The range testing is shared for all
modes now. Ironically, it's a bit slower, but I'll take less code over
more speed for the accuracy core.
Speaking of speed, because there's so much less calculations per pixel
for BGs, performance for the entire emulator has gone up by 30% in the
accuracy core. Pretty neat overall, I can maintain 60fps in all but,
yeah you can guess can't you?
2010-09-04 03:36:03 +00:00
|
|
|
struct {
|
|
|
|
|
unsigned x;
|
|
|
|
|
bool one;
|
|
|
|
|
bool two;
|
|
|
|
|
};
|
|
|
|
|
|
2010-08-09 13:28:56 +00:00
|
|
|
void scanline();
|
|
|
|
|
void run();
|
|
|
|
|
void reset();
|
|
|
|
|
|
|
|
|
|
void test(
|
|
|
|
|
bool &main, bool &sub,
|
|
|
|
|
bool one_enable, bool one_invert,
|
|
|
|
|
bool two_enable, bool two_invert,
|
|
|
|
|
uint8 mask, bool main_enable, bool sub_enable
|
|
|
|
|
);
|
Update to v068r12 release.
(there was no r11 release posted to the WIP thread)
byuu says:
This took ten hours of mind boggling insanity to pull off.
It upgrades the S-PPU dot-based renderer to fetch one tile, and then
output all of its pixels before fetching again. It sounds easy enough,
but it's insanely difficult. I ended up taking one small shortcut, in
that rather than fetch at -7, I fetch at the first instance where a tile
is needed to plot to x=0. So if you have {-3 to +4 } as a tile, it
fetches at -3. That won't work so well on hardware, if two BGs fetch at
the same X offset, they won't have time.
I have had no luck staggering the reads at BG1=-7, BG3=-5, etc. While
I can shift and fetch just fine, what happens is that when a new tile is
fetched in, that gives a new palette, priority, etc; and this ends up
happening between two tiles which results in the right-most edges of the
screen ending up with the wrong colors and such.
Offset-per-tile is cheap as always. Although looking at it, I'm not sure
how BG3 could pre-fetch, especially with the way one or two OPT modes
can fetch two tiles.
There's no magic in Hoffset caching yet, so the SMW1 pixel issue is
still there.
Mode 7 got a bugfix, it was off-by-one horizontally from the mosaic
code. After re-designing the BG mosaic, I ended up needing a separate
mosaic for Mode7, and in the process I fixed that bug. The obvious
change is that the Chrono Trigger Mode7->Mode2 transition doesn't cause
the pendulum to jump anymore.
Windows were simplified just a tad. The range testing is shared for all
modes now. Ironically, it's a bit slower, but I'll take less code over
more speed for the accuracy core.
Speaking of speed, because there's so much less calculations per pixel
for BGs, performance for the entire emulator has gone up by 30% in the
accuracy core. Pretty neat overall, I can maintain 60fps in all but,
yeah you can guess can't you?
2010-09-04 03:36:03 +00:00
|
|
|
|
|
|
|
|
void serialize(serializer&);
|
|
|
|
|
Window(PPU &self);
|
|
|
|
|
|
|
|
|
|
PPU &self;
|
|
|
|
|
friend class PPU;
|
2010-08-09 13:28:56 +00:00
|
|
|
};
|