2012-04-26 10:51:13 +00:00
|
|
|
struct PPU : Thread, MMIO {
|
2016-02-09 11:51:12 +00:00
|
|
|
static auto Enter() -> void;
|
2015-11-21 07:36:48 +00:00
|
|
|
auto main() -> void;
|
2016-06-05 05:03:21 +00:00
|
|
|
auto mode(uint) -> void;
|
|
|
|
auto coincidence() -> bool;
|
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 refresh() -> void;
|
2016-06-05 05:03:21 +00:00
|
|
|
auto wait(uint clocks) -> void;
|
2015-11-21 07:36:48 +00:00
|
|
|
|
|
|
|
auto hflip(uint data) const -> uint;
|
|
|
|
|
|
|
|
//mmio.cpp
|
|
|
|
auto vram_addr(uint16 addr) const -> uint;
|
|
|
|
auto mmio_read(uint16 addr) -> uint8;
|
|
|
|
auto mmio_write(uint16 addr, uint8 data) -> void;
|
|
|
|
|
|
|
|
//dmg.cpp
|
|
|
|
auto dmg_read_tile(bool select, uint x, uint y, uint& data) -> void;
|
|
|
|
auto dmg_scanline() -> void;
|
|
|
|
auto dmg_run() -> void;
|
|
|
|
auto dmg_run_bg() -> void;
|
|
|
|
auto dmg_run_window() -> void;
|
|
|
|
auto dmg_run_ob() -> void;
|
|
|
|
|
|
|
|
//cgb.cpp
|
|
|
|
auto cgb_read_tile(bool select, uint x, uint y, uint& attr, uint& data) -> void;
|
|
|
|
auto cgb_scanline() -> void;
|
|
|
|
auto cgb_run() -> void;
|
|
|
|
auto cgb_run_bg() -> void;
|
|
|
|
auto cgb_run_window() -> void;
|
|
|
|
auto cgb_run_ob() -> void;
|
|
|
|
|
|
|
|
auto power() -> void;
|
|
|
|
|
|
|
|
auto serialize(serializer&) -> void;
|
|
|
|
|
2013-12-11 11:19:17 +00:00
|
|
|
uint8 vram[16384]; //GB = 8192, GBC = 16384
|
|
|
|
uint8 oam[160];
|
|
|
|
uint8 bgp[4];
|
|
|
|
uint8 obp[2][4];
|
|
|
|
uint8 bgpd[64];
|
|
|
|
uint8 obpd[64];
|
|
|
|
|
2016-01-12 11:08:34 +00:00
|
|
|
function<auto () -> void> scanline;
|
|
|
|
function<auto () -> void> run;
|
|
|
|
|
2010-12-29 11:03:42 +00:00
|
|
|
struct Status {
|
2016-06-05 05:03:21 +00:00
|
|
|
bool irq; //STAT IRQ line
|
2015-11-21 07:36:48 +00:00
|
|
|
uint lx;
|
2010-12-30 07:18:47 +00:00
|
|
|
|
|
|
|
//$ff40 LCDC
|
|
|
|
bool display_enable;
|
|
|
|
bool window_tilemap_select;
|
|
|
|
bool window_display_enable;
|
|
|
|
bool bg_tiledata_select;
|
|
|
|
bool bg_tilemap_select;
|
2011-10-28 09:51:43 +00:00
|
|
|
bool ob_size;
|
|
|
|
bool ob_enable;
|
2011-01-02 04:46:54 +00:00
|
|
|
bool bg_enable;
|
2010-12-30 07:18:47 +00:00
|
|
|
|
|
|
|
//$ff41 STAT
|
|
|
|
bool interrupt_lyc;
|
|
|
|
bool interrupt_oam;
|
|
|
|
bool interrupt_vblank;
|
|
|
|
bool interrupt_hblank;
|
2016-06-05 05:03:21 +00:00
|
|
|
uint2 mode;
|
2010-12-30 07:18:47 +00:00
|
|
|
|
|
|
|
//$ff42 SCY
|
|
|
|
uint8 scy;
|
|
|
|
|
|
|
|
//$ff43 SCX
|
|
|
|
uint8 scx;
|
|
|
|
|
|
|
|
//$ff44 LY
|
|
|
|
uint8 ly;
|
|
|
|
|
|
|
|
//$ff45 LYC
|
|
|
|
uint8 lyc;
|
|
|
|
|
Update to v097 release.
byuu says:
This release features improvements to all emulation cores, but most
substantially for the Game Boy core. All of blargg's test ROMs that pass
in gambatte now either pass in higan, or are off by 1-2 clocks (the
actual behaviors are fully emulated.) I consider the Game Boy core to
now be fairly accurate, but there's still more improvements to be had.
Also, what's sure to be a major feature for some: higan now has full
support for loading and playing ordinary ROM files, whether they have
copier headers, weird extensions, or are inside compressed archives. You
can load these games from the command-line, from the main Library menu
(via Load ROM Image), or via drag-and-drop on the main higan window. Of
course, fans of game folders and the library need not worry: that's
still there as well.
Also new, you can drop the (uncompressed) Game Boy Advance BIOS onto the
higan main window to install it into the correct location with the
correct file name.
Lastly, this release technically restores Mac OS X support. However,
it's still not very stable, so I have decided against releasing binaries
at this time. I'd rather not rush this and leave a bad first impression
for OS X users.
Changelog (since v096):
- higan: project source code hierarchy restructured; icarus directly
integrated
- higan: added software emulation of color-bleed, LCD-refresh,
scanlines, interlacing
- icarus: you can now load and import ROM files/archives from the main
higan menu
- NES: fixed manifest parsing for board mirroring and VRC pinouts
- SNES: fixed manifest for Star Ocean
- SNES: fixed manifest for Rockman X2,X3
- GB: enabling LCD restarts frame
- GB: emulated extra OAM STAT IRQ quirk required for GBVideoPlayer
(Shonumi)
- GB: VBK, BGPI, OBPI are readable
- GB: OAM DMA happens inside PPU core instead of CPU core
- GB: fixed APU length and sweep operations
- GB: emulated wave RAM quirks when accessing while channel is enabled
- GB: improved timings of several CPU opcodes (gekkio)
- GB: improved timings of OAM DMA refresh (gekkio)
- GB: CPU uses open collector logic; return 0xFF for unmapped memory
(gekkio)
- GBA: fixed sequencer enable flags; fixes audio in Zelda - Minish Cap
(Jonas Quinn)
- GBA: fixed disassembler masking error (Lioncash)
- hiro: Cocoa support added; higan can now be compiled on Mac OS X 10.7+
- nall: improved program path detection on Windows
- higan/Windows: moved configuration data from %appdata% to
%localappdata%
- higan/Linux,BSD: moved configuration data from ~/.config/higan to
~/.local/higan
2016-01-17 08:59:25 +00:00
|
|
|
//$ff46 DMA
|
|
|
|
bool dma_active;
|
|
|
|
uint dma_clock;
|
|
|
|
uint8 dma_bank;
|
|
|
|
|
2010-12-30 07:18:47 +00:00
|
|
|
//$ff4a WY
|
|
|
|
uint8 wy;
|
|
|
|
|
|
|
|
//$ff4b WX
|
|
|
|
uint8 wx;
|
2010-12-29 11:03:42 +00:00
|
|
|
|
2011-10-27 00:00:17 +00:00
|
|
|
//$ff4f VBK
|
|
|
|
bool vram_bank;
|
|
|
|
|
|
|
|
//$ff68 BGPI
|
|
|
|
bool bgpi_increment;
|
|
|
|
uint6 bgpi;
|
2011-01-02 04:46:54 +00:00
|
|
|
|
2011-10-27 00:00:17 +00:00
|
|
|
//$ff6a OBPI
|
|
|
|
bool obpi_increment;
|
|
|
|
uint8 obpi;
|
|
|
|
} status;
|
|
|
|
|
Update to v088r03 release.
byuu says:
static vector<uint8_t> file::read(const string &filename); replaces:
static bool file::read(const string &filename, uint8_t *&data, unsigned
&size); This allows automatic deletion of the underlying data.
Added vectorstream, which is obviously a vector<uint8_t> wrapper for
a data stream. Plan is for all data accesses inside my emulation cores
to take stream objects, especially MSU1. This lets you feed the core
anything: memorystream, filestream, zipstream, gzipstream, httpstream,
etc. There will still be exceptions for link and serial, those need
actual library files on disk. But those aren't official hardware devices
anyway.
So to help with speed a bit, I'm rethinking the video rendering path.
Previous system:
- core outputs system-native samples (SNES = 19-bit LRGB, NES = 9-bit
emphasis+palette, DMG = 2-bit grayscale, etc.)
- interfaceSystem transforms samples to 30-bit via lookup table inside
the emulation core
- interfaceSystem masks off overscan areas, if enabled
- interfaceUI runs filter to produce new target buffer, if enabled
- interfaceUI transforms 30-bit video to native display depth (24-bit or
30-bit), and applies color-adjustments (gamma, etc) at the same time
New system:
- all cores now generate an internal palette, and call
Interface::videoColor(uint32_t source, uint16_t red, uint16_t green,
uint16_t blue) to get native display color post-adjusted (gamma, etc
applied already.)
- all cores output to uint32_t* buffer now (output video.palette[color]
instead of just color)
- interfaceUI runs filter to produce new target buffer, if enabled
- interfaceUI memcpy()'s buffer to the video card
videoColor() is pretty neat. source is the raw pixel (as per the
old-format, 19-bit SNES, 9-bit NES, etc), and you can create a color
from that if you really want to. Or return that value to get a buffer
just like v088 and below. red, green, blue are 16-bits per channel,
because why the hell not, right? Just lop off all the bits you don't
want. If you have more bits on your display than that, fuck you :P
The last step is extremely difficult to avoid. Video cards can and do
have pitches that differ from the width of the texture. Trying to make
the core account for this would be really awful. And even if we did
that, the emulation routine would need to write directly to a video card
RAM buffer. Some APIs require you to lock the video buffer while
writing, so this would leave the video buffer locked for a long time.
Probably not catastrophic, but still awful. And lastly, if the
emulation core tried writing directly to the display texture, software
filters would no longer be possible (unless you -really- jump through
hooks and divert to a memory buffer when a filter is enabled, but ...
fuck.)
Anyway, the point of all that work was to eliminate an extra video copy,
and the need for a really painful 30-bit to 24-bit conversion (three
shifts, three masks, three array indexes.) So this basically reverts us,
performance-wise, to where we were pre-30 bit support.
[...]
The downside to this is that we're going to need a filter for each
output depth. Since the array type is uint32_t*, and I don't intend to
support higher or lower depths, we really only need 24+30-bit versions
of each filter. Kinda shitty, but oh well.
2012-04-27 12:12:53 +00:00
|
|
|
uint32 screen[160 * 144];
|
2013-12-11 11:19:17 +00:00
|
|
|
|
2013-12-07 09:12:37 +00:00
|
|
|
struct Pixel {
|
|
|
|
uint16 color;
|
|
|
|
uint8 palette;
|
2013-12-11 11:19:17 +00:00
|
|
|
bool priority;
|
|
|
|
};
|
|
|
|
Pixel bg;
|
|
|
|
Pixel ob;
|
|
|
|
|
|
|
|
struct Sprite {
|
2015-11-21 07:36:48 +00:00
|
|
|
uint x;
|
|
|
|
uint y;
|
|
|
|
uint tile;
|
|
|
|
uint attr;
|
|
|
|
uint data;
|
2013-12-11 11:19:17 +00:00
|
|
|
};
|
|
|
|
Sprite sprite[10];
|
2015-11-21 07:36:48 +00:00
|
|
|
uint sprites;
|
2013-12-11 11:19:17 +00:00
|
|
|
|
2015-11-21 07:36:48 +00:00
|
|
|
uint px;
|
2013-12-11 11:19:17 +00:00
|
|
|
|
|
|
|
struct Background {
|
2015-11-21 07:36:48 +00:00
|
|
|
uint attr;
|
|
|
|
uint data;
|
2013-12-11 11:19:17 +00:00
|
|
|
};
|
|
|
|
Background background;
|
|
|
|
Background window;
|
2010-12-29 11:03:42 +00:00
|
|
|
};
|
|
|
|
|
2012-04-26 10:51:13 +00:00
|
|
|
extern PPU ppu;
|