2012-03-19 11:19:53 +00:00
|
|
|
#include <gba/gba.hpp>
|
|
|
|
|
|
2012-03-21 11:08:16 +00:00
|
|
|
//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)
|
2012-03-29 11:58:10 +00:00
|
|
|
//frame: 228 scanlines (280896 cycles)
|
2012-03-21 11:08:16 +00:00
|
|
|
|
2012-04-26 10:51:13 +00:00
|
|
|
namespace GameBoyAdvance {
|
2012-03-19 11:19:53 +00:00
|
|
|
|
Update to v097r02 release.
byuu says:
Note: balanced/performance profiles still broken, sorry.
Changelog:
- added nall/GNUmakefile unique() function; used on linking phase of
higan
- added nall/unique_pointer
- target-tomoko and {System}::Video updated to use
unique_pointer<ClassName> instead of ClassName* [1]
- locate() updated to search multiple paths [2]
- GB: pass gekkio's if_ie_registers and boot_hwio-G test ROMs
- FC, GB, GBA: merge video/ into the PPU cores
- ruby: fixed ~AudioXAudio2() typo
[1] I expected this to cause new crashes on exit due to changing the
order of destruction of objects (and deleting things that weren't
deleted before), but ... so far, so good. I guess we'll see what crops
up, especially on OS X (which is already crashing for unknown reasons on
exit.)
[2] right now, the search paths are: programpath(), {configpath(),
"higan/"}, {localpath(), "higan/"}; but we can add as many more as we
want, and we can also add platform-specific versions.
2016-01-25 11:27:18 +00:00
|
|
|
PPU ppu;
|
2012-04-03 23:50:40 +00:00
|
|
|
#include "background.cpp"
|
2012-04-03 00:47:28 +00:00
|
|
|
#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"
|
2012-04-03 00:47:28 +00:00
|
|
|
#include "screen.cpp"
|
2012-03-31 08:14:31 +00:00
|
|
|
#include "mmio.cpp"
|
2012-04-09 06:41:27 +00:00
|
|
|
#include "memory.cpp"
|
Update to v087r26 release.
byuu says:
Changelog:
- fixed FIFO[1] reset behavior (fixes audio in Sword of Mana)
- added FlashROM emulation (both sizes)
- GBA parses RAM settings from manifest.xml now
- save RAM is written to disk now
- added save state support (it's currently broken, though)
- fixed ROM/RAM access timings
- open bus should mostly work (we don't do the PC+12 stuff yet)
- emulated the undocumented memory control register (mirror IWRAM,
disable I+EWRAM, EWRAM wait state count)
- emulated keypad interrupts
- emulated STOP (freezes video, audio, DMA and timers; only breaks on
keypad IRQs)
- probably a lot more, it was a long night ...
Show stoppers, missing things, broken things, etc:
- ST018 is still completely broken
- GBC audio sequencer apparently needs work
- GBA audio FIFO buffer seems too quiet
- PHI / ROM prefetch needs to be emulated (no idea on how to do this,
especially PHI)
- SOUNDBIAS 64/128/256khz modes should output at that resolution
(really, we need to simulate PWM properly, no idea on how to do this)
- object mosaic top-left coordinates are wrong (minor, fixing will
actually make the effect look worse)
- need to emulate PPU greenswap and color palette distortion (no idea on
how do this)
- need GBA save type database (I would also LIKE to blacklist
/ patch-out trainers, but that's a discussion for another day.)
- some ARM ops advance the prefetch buffer, so you can read PC+12 in
some cases
2012-04-16 12:19:39 +00:00
|
|
|
#include "serialization.cpp"
|
2012-03-19 11:19:53 +00:00
|
|
|
|
2015-11-16 08:38:05 +00:00
|
|
|
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 {
|
2016-02-09 11:51:12 +00:00
|
|
|
while(true) scheduler.synchronize(), ppu.main();
|
2012-03-19 11:19:53 +00:00
|
|
|
}
|
|
|
|
|
|
2015-11-16 08:38:05 +00:00
|
|
|
auto PPU::main() -> void {
|
Update to v087r26 release.
byuu says:
Changelog:
- fixed FIFO[1] reset behavior (fixes audio in Sword of Mana)
- added FlashROM emulation (both sizes)
- GBA parses RAM settings from manifest.xml now
- save RAM is written to disk now
- added save state support (it's currently broken, though)
- fixed ROM/RAM access timings
- open bus should mostly work (we don't do the PC+12 stuff yet)
- emulated the undocumented memory control register (mirror IWRAM,
disable I+EWRAM, EWRAM wait state count)
- emulated keypad interrupts
- emulated STOP (freezes video, audio, DMA and timers; only breaks on
keypad IRQs)
- probably a lot more, it was a long night ...
Show stoppers, missing things, broken things, etc:
- ST018 is still completely broken
- GBC audio sequencer apparently needs work
- GBA audio FIFO buffer seems too quiet
- PHI / ROM prefetch needs to be emulated (no idea on how to do this,
especially PHI)
- SOUNDBIAS 64/128/256khz modes should output at that resolution
(really, we need to simulate PWM properly, no idea on how to do this)
- object mosaic top-left coordinates are wrong (minor, fixing will
actually make the effect look worse)
- need to emulate PPU greenswap and color palette distortion (no idea on
how do this)
- need GBA save type database (I would also LIKE to blacklist
/ patch-out trainers, but that's a discussion for another day.)
- some ARM ops advance the prefetch buffer, so you can read PC+12 in
some cases
2012-04-16 12:19:39 +00:00
|
|
|
scanline();
|
|
|
|
|
}
|
|
|
|
|
|
2015-11-16 08:38:05 +00:00
|
|
|
auto PPU::step(uint clocks) -> void {
|
2012-03-19 11:19:53 +00:00
|
|
|
clock += clocks;
|
2016-02-09 11:51:12 +00:00
|
|
|
if(clock >= 0 && !scheduler.synchronizing()) co_switch(cpu.thread);
|
2012-03-19 11:19:53 +00:00
|
|
|
}
|
|
|
|
|
|
2015-11-16 08:38:05 +00:00
|
|
|
auto PPU::power() -> void {
|
2016-02-09 11:51:12 +00:00
|
|
|
create(PPU::Enter, 16'777'216);
|
2012-03-19 11:19:53 +00:00
|
|
|
|
2015-11-16 08:38:05 +00:00
|
|
|
for(uint n = 0; n < 240 * 160; n++) output[n] = 0;
|
2012-03-29 11:58:10 +00:00
|
|
|
|
2015-11-16 08:38:05 +00:00
|
|
|
for(uint n = 0; n < 1024; n += 2) pram_write(n, Half, 0x0000);
|
|
|
|
|
for(uint n = 0; n < 1024; n += 2) oam_write(n, Half, 0x0000);
|
2012-04-09 06:19:32 +00:00
|
|
|
|
2016-02-25 10:38:03 +00:00
|
|
|
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;
|
2012-03-31 08:17:36 +00:00
|
|
|
regs.greenswap = 0;
|
2016-02-25 10:38:03 +00:00
|
|
|
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;
|
2012-03-31 08:17:36 +00:00
|
|
|
regs.vcounter = 0;
|
2013-05-05 09:21:30 +00:00
|
|
|
for(auto& bg : regs.bg) {
|
2016-02-25 10:38:03 +00:00
|
|
|
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;
|
2012-03-31 08:17:36 +00:00
|
|
|
bg.hoffset = 0;
|
|
|
|
|
bg.voffset = 0;
|
|
|
|
|
bg.pa = 0;
|
|
|
|
|
bg.pb = 0;
|
|
|
|
|
bg.pc = 0;
|
|
|
|
|
bg.pd = 0;
|
|
|
|
|
bg.x = 0;
|
|
|
|
|
bg.y = 0;
|
2012-04-07 08:17:49 +00:00
|
|
|
bg.lx = 0;
|
|
|
|
|
bg.ly = 0;
|
2012-03-31 08:17:36 +00:00
|
|
|
}
|
2013-05-05 09:21:30 +00:00
|
|
|
for(auto& w : regs.window) {
|
2012-03-31 08:17:36 +00:00
|
|
|
w.x1 = 0;
|
|
|
|
|
w.x2 = 0;
|
|
|
|
|
w.y1 = 0;
|
|
|
|
|
w.y2 = 0;
|
|
|
|
|
}
|
2016-02-25 10:38:03 +00:00
|
|
|
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
|
|
|
}
|
2012-03-31 08:17:36 +00:00
|
|
|
regs.mosaic.bghsize = 0;
|
|
|
|
|
regs.mosaic.bgvsize = 0;
|
|
|
|
|
regs.mosaic.objhsize = 0;
|
|
|
|
|
regs.mosaic.objvsize = 0;
|
2016-02-25 10:38:03 +00:00
|
|
|
for(auto& above : regs.blend.control.above) above = 0;
|
|
|
|
|
regs.blend.control.mode = 0;
|
|
|
|
|
for(auto& below : regs.blend.control.below) below = 0;
|
2012-03-31 08:17:36 +00:00
|
|
|
regs.blend.eva = 0;
|
|
|
|
|
regs.blend.evb = 0;
|
|
|
|
|
regs.blend.evy = 0;
|
2012-03-29 11:58:10 +00:00
|
|
|
|
2015-11-16 08:38:05 +00:00
|
|
|
for(uint n = 0x000; n <= 0x055; n++) bus.mmio[n] = this;
|
2012-03-29 11:58:10 +00:00
|
|
|
}
|
|
|
|
|
|
2015-11-16 08:38:05 +00:00
|
|
|
auto PPU::scanline() -> void {
|
Update to v087r26 release.
byuu says:
Changelog:
- fixed FIFO[1] reset behavior (fixes audio in Sword of Mana)
- added FlashROM emulation (both sizes)
- GBA parses RAM settings from manifest.xml now
- save RAM is written to disk now
- added save state support (it's currently broken, though)
- fixed ROM/RAM access timings
- open bus should mostly work (we don't do the PC+12 stuff yet)
- emulated the undocumented memory control register (mirror IWRAM,
disable I+EWRAM, EWRAM wait state count)
- emulated keypad interrupts
- emulated STOP (freezes video, audio, DMA and timers; only breaks on
keypad IRQs)
- probably a lot more, it was a long night ...
Show stoppers, missing things, broken things, etc:
- ST018 is still completely broken
- GBC audio sequencer apparently needs work
- GBA audio FIFO buffer seems too quiet
- PHI / ROM prefetch needs to be emulated (no idea on how to do this,
especially PHI)
- SOUNDBIAS 64/128/256khz modes should output at that resolution
(really, we need to simulate PWM properly, no idea on how to do this)
- object mosaic top-left coordinates are wrong (minor, fixing will
actually make the effect look worse)
- need to emulate PPU greenswap and color palette distortion (no idea on
how do this)
- need GBA save type database (I would also LIKE to blacklist
/ patch-out trainers, but that's a discussion for another day.)
- some ARM ops advance the prefetch buffer, so you can read PC+12 in
some cases
2012-04-16 12:19:39 +00:00
|
|
|
cpu.keypad_run();
|
|
|
|
|
|
2012-03-31 08:17:36 +00:00
|
|
|
regs.status.vblank = regs.vcounter >= 160 && regs.vcounter <= 226;
|
|
|
|
|
regs.status.vcoincidence = regs.vcounter == regs.status.vcompare;
|
|
|
|
|
|
|
|
|
|
if(regs.vcounter == 0) {
|
|
|
|
|
frame();
|
2012-04-07 08:17:49 +00:00
|
|
|
|
|
|
|
|
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;
|
2012-03-31 08:17:36 +00:00
|
|
|
}
|
2012-03-29 11:58:10 +00:00
|
|
|
|
2012-03-31 08:17:36 +00:00
|
|
|
if(regs.vcounter == 160) {
|
Update to v097r17 release.
byuu says:
Changelog:
- ruby: if DirectSoundCreate fails (no sound device present), return
false from init instead of crashing
- nall: improved edge case return values for
(basename,pathname,dirname,...)
- nall: renamed file_system_object class to inode
- nall: varuint_t replaced with VariadicNatural; which contains
.bit,.bits,.byte ala Natural/Integer
- nall: fixed boolean compilation error on Windows
- WS: popa should not restore SP
- GBA: rewrote the CPU/APU cores to use the .bit,.bits functions;
removed registers.cpp from each
Note that the GBA changes are extremely major. This is about five hours
worth of extremely delicate work. Any slight errors could break
emulation in extremely bad ways. Let's hold off on extensive testing
until the next WIP, after I do the same to the PPU.
So far ... endrift's SOUNDCNT_X I/O test is failing, although that code
didn't change, so clearly I messed up SOUNDCNT_H somehow ...
To compile on Windows:
1. change nall/string/platform.hpp line 47 to
return slice(result, 0, 3);
2. change ruby/video.wgl.cpp line 72 to
auto lock(uint32_t*& data, uint& pitch, uint width, uint height) -> bool {
3. add this line to the very top of hiro/windows/header.cpp:
#define boolean FuckYouMicrosoft
2016-02-23 11:08:44 +00:00
|
|
|
if(regs.status.irqvblank) cpu.regs.irq.flag |= CPU::Interrupt::VBlank;
|
Update to v087r30 release.
byuu says:
Changelog:
- DMA channel masks added (some are 27-bit source/target and some are
14-bit length -- hooray, varuint_t class.)
- No more state.pending flags. Instead, we set dma.pending flag when we
want a transfer (fixes GBA Video - Pokemon audio) [Cydrak]
- fixed OBJ Vmosaic [Cydrak, krom]
- OBJ cannot read <=0x13fff in BG modes 3-5 (fixes the garbled tile at
the top-left of some games)
- DMA timing should be much closer to hardware now, but probably not
perfect
- PPU frame blending uses blargg's bit-perfect, rounded method (slower,
but what can you do?)
- GBA carts really unload now
- added nall/gba/cartridge.hpp: used when there is no manifest. Scans
ROMs for library tags, and selects the first valid one found
- added EEPROM auto-detection when EEPROM size=0. Forces disk/save state
size to 8192 (otherwise states could crash between pre and post
detect.)
- detects first read after a set read address command when the size
is zero, and sets all subsequent bit-lengths to that value, prints
detected size to terminal
- added nall/nes/cartridge.hpp: moves iNES detection out of emulation
core.
Important to note: long-term goal is to remove all
nall/(system)/cartridge.hpp detections from the core and replace with
databases. All in good time.
Anyway, the GBA workarounds should work for ~98.5% of the library, if my
pre-scanning was correct (~40 games with odd tags. I reject ones without
numeric versions now, too.)
I think we're basically at a point where we can release a new version
now. Compatibility should be relatively high (at least for a first
release), and fixes are only going to affect one or two games at a time.
I'd like to start doing some major cleaning house internally (rename
NES->Famicom, SNES->SuperFamicom and such.) Would be much wiser to do
that on a .01 WIP to minimize regressions.
The main problems with a release now:
- speed is pretty bad, haven't really optimized much yet (not sure how
much we can improve it yet, this usually isn't easy)
- sound isn't -great-, but the GBA audio sucks anyway :P
- couple of known bugs (Sonic X video, etc.)
2012-04-22 10:49:19 +00:00
|
|
|
cpu.dma_vblank();
|
2012-03-29 11:58:10 +00:00
|
|
|
}
|
|
|
|
|
|
2012-03-31 08:17:36 +00:00
|
|
|
if(regs.status.irqvcoincidence) {
|
Update to v097r17 release.
byuu says:
Changelog:
- ruby: if DirectSoundCreate fails (no sound device present), return
false from init instead of crashing
- nall: improved edge case return values for
(basename,pathname,dirname,...)
- nall: renamed file_system_object class to inode
- nall: varuint_t replaced with VariadicNatural; which contains
.bit,.bits,.byte ala Natural/Integer
- nall: fixed boolean compilation error on Windows
- WS: popa should not restore SP
- GBA: rewrote the CPU/APU cores to use the .bit,.bits functions;
removed registers.cpp from each
Note that the GBA changes are extremely major. This is about five hours
worth of extremely delicate work. Any slight errors could break
emulation in extremely bad ways. Let's hold off on extensive testing
until the next WIP, after I do the same to the PPU.
So far ... endrift's SOUNDCNT_X I/O test is failing, although that code
didn't change, so clearly I messed up SOUNDCNT_H somehow ...
To compile on Windows:
1. change nall/string/platform.hpp line 47 to
return slice(result, 0, 3);
2. change ruby/video.wgl.cpp line 72 to
auto lock(uint32_t*& data, uint& pitch, uint width, uint height) -> bool {
3. add this line to the very top of hiro/windows/header.cpp:
#define boolean FuckYouMicrosoft
2016-02-23 11:08:44 +00:00
|
|
|
if(regs.status.vcoincidence) cpu.regs.irq.flag |= CPU::Interrupt::VCoincidence;
|
2012-03-29 11:58:10 +00:00
|
|
|
}
|
|
|
|
|
|
2012-04-03 00:47:28 +00:00
|
|
|
if(regs.vcounter < 160) {
|
Update to v087r26 release.
byuu says:
Changelog:
- fixed FIFO[1] reset behavior (fixes audio in Sword of Mana)
- added FlashROM emulation (both sizes)
- GBA parses RAM settings from manifest.xml now
- save RAM is written to disk now
- added save state support (it's currently broken, though)
- fixed ROM/RAM access timings
- open bus should mostly work (we don't do the PC+12 stuff yet)
- emulated the undocumented memory control register (mirror IWRAM,
disable I+EWRAM, EWRAM wait state count)
- emulated keypad interrupts
- emulated STOP (freezes video, audio, DMA and timers; only breaks on
keypad IRQs)
- probably a lot more, it was a long night ...
Show stoppers, missing things, broken things, etc:
- ST018 is still completely broken
- GBC audio sequencer apparently needs work
- GBA audio FIFO buffer seems too quiet
- PHI / ROM prefetch needs to be emulated (no idea on how to do this,
especially PHI)
- SOUNDBIAS 64/128/256khz modes should output at that resolution
(really, we need to simulate PWM properly, no idea on how to do this)
- object mosaic top-left coordinates are wrong (minor, fixing will
actually make the effect look worse)
- need to emulate PPU greenswap and color palette distortion (no idea on
how do this)
- need GBA save type database (I would also LIKE to blacklist
/ patch-out trainers, but that's a discussion for another day.)
- some ARM ops advance the prefetch buffer, so you can read PC+12 in
some cases
2012-04-16 12:19:39 +00:00
|
|
|
if(regs.control.forceblank || cpu.regs.mode == CPU::Registers::Mode::Stop) {
|
2012-04-09 06:19:32 +00:00
|
|
|
render_forceblank();
|
|
|
|
|
} else {
|
2015-11-16 08:38:05 +00:00
|
|
|
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
|
|
|
}
|
|
|
|
|
render_window(0);
|
|
|
|
|
render_window(1);
|
2012-04-09 06:19:32 +00:00
|
|
|
render_objects();
|
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
|
|
|
render_backgrounds();
|
2012-04-09 06:19:32 +00:00
|
|
|
render_screen();
|
|
|
|
|
}
|
2012-04-03 00:47:28 +00:00
|
|
|
}
|
|
|
|
|
|
2012-04-07 08:17:49 +00:00
|
|
|
step(960);
|
2012-03-31 08:17:36 +00:00
|
|
|
regs.status.hblank = 1;
|
Update to v097r17 release.
byuu says:
Changelog:
- ruby: if DirectSoundCreate fails (no sound device present), return
false from init instead of crashing
- nall: improved edge case return values for
(basename,pathname,dirname,...)
- nall: renamed file_system_object class to inode
- nall: varuint_t replaced with VariadicNatural; which contains
.bit,.bits,.byte ala Natural/Integer
- nall: fixed boolean compilation error on Windows
- WS: popa should not restore SP
- GBA: rewrote the CPU/APU cores to use the .bit,.bits functions;
removed registers.cpp from each
Note that the GBA changes are extremely major. This is about five hours
worth of extremely delicate work. Any slight errors could break
emulation in extremely bad ways. Let's hold off on extensive testing
until the next WIP, after I do the same to the PPU.
So far ... endrift's SOUNDCNT_X I/O test is failing, although that code
didn't change, so clearly I messed up SOUNDCNT_H somehow ...
To compile on Windows:
1. change nall/string/platform.hpp line 47 to
return slice(result, 0, 3);
2. change ruby/video.wgl.cpp line 72 to
auto lock(uint32_t*& data, uint& pitch, uint width, uint height) -> bool {
3. add this line to the very top of hiro/windows/header.cpp:
#define boolean FuckYouMicrosoft
2016-02-23 11:08:44 +00:00
|
|
|
if(regs.status.irqhblank) cpu.regs.irq.flag |= CPU::Interrupt::HBlank;
|
Update to v087r30 release.
byuu says:
Changelog:
- DMA channel masks added (some are 27-bit source/target and some are
14-bit length -- hooray, varuint_t class.)
- No more state.pending flags. Instead, we set dma.pending flag when we
want a transfer (fixes GBA Video - Pokemon audio) [Cydrak]
- fixed OBJ Vmosaic [Cydrak, krom]
- OBJ cannot read <=0x13fff in BG modes 3-5 (fixes the garbled tile at
the top-left of some games)
- DMA timing should be much closer to hardware now, but probably not
perfect
- PPU frame blending uses blargg's bit-perfect, rounded method (slower,
but what can you do?)
- GBA carts really unload now
- added nall/gba/cartridge.hpp: used when there is no manifest. Scans
ROMs for library tags, and selects the first valid one found
- added EEPROM auto-detection when EEPROM size=0. Forces disk/save state
size to 8192 (otherwise states could crash between pre and post
detect.)
- detects first read after a set read address command when the size
is zero, and sets all subsequent bit-lengths to that value, prints
detected size to terminal
- added nall/nes/cartridge.hpp: moves iNES detection out of emulation
core.
Important to note: long-term goal is to remove all
nall/(system)/cartridge.hpp detections from the core and replace with
databases. All in good time.
Anyway, the GBA workarounds should work for ~98.5% of the library, if my
pre-scanning was correct (~40 games with odd tags. I reject ones without
numeric versions now, too.)
I think we're basically at a point where we can release a new version
now. Compatibility should be relatively high (at least for a first
release), and fixes are only going to affect one or two games at a time.
I'd like to start doing some major cleaning house internally (rename
NES->Famicom, SNES->SuperFamicom and such.) Would be much wiser to do
that on a .01 WIP to minimize regressions.
The main problems with a release now:
- speed is pretty bad, haven't really optimized much yet (not sure how
much we can improve it yet, this usually isn't easy)
- sound isn't -great-, but the GBA audio sucks anyway :P
- couple of known bugs (Sonic X video, etc.)
2012-04-22 10:49:19 +00:00
|
|
|
if(regs.vcounter < 160) cpu.dma_hblank();
|
2012-03-31 08:17:36 +00:00
|
|
|
|
2012-04-07 08:17:49 +00:00
|
|
|
step(240);
|
2012-03-31 08:17:36 +00:00
|
|
|
regs.status.hblank = 0;
|
Update to v087r30 release.
byuu says:
Changelog:
- DMA channel masks added (some are 27-bit source/target and some are
14-bit length -- hooray, varuint_t class.)
- No more state.pending flags. Instead, we set dma.pending flag when we
want a transfer (fixes GBA Video - Pokemon audio) [Cydrak]
- fixed OBJ Vmosaic [Cydrak, krom]
- OBJ cannot read <=0x13fff in BG modes 3-5 (fixes the garbled tile at
the top-left of some games)
- DMA timing should be much closer to hardware now, but probably not
perfect
- PPU frame blending uses blargg's bit-perfect, rounded method (slower,
but what can you do?)
- GBA carts really unload now
- added nall/gba/cartridge.hpp: used when there is no manifest. Scans
ROMs for library tags, and selects the first valid one found
- added EEPROM auto-detection when EEPROM size=0. Forces disk/save state
size to 8192 (otherwise states could crash between pre and post
detect.)
- detects first read after a set read address command when the size
is zero, and sets all subsequent bit-lengths to that value, prints
detected size to terminal
- added nall/nes/cartridge.hpp: moves iNES detection out of emulation
core.
Important to note: long-term goal is to remove all
nall/(system)/cartridge.hpp detections from the core and replace with
databases. All in good time.
Anyway, the GBA workarounds should work for ~98.5% of the library, if my
pre-scanning was correct (~40 games with odd tags. I reject ones without
numeric versions now, too.)
I think we're basically at a point where we can release a new version
now. Compatibility should be relatively high (at least for a first
release), and fixes are only going to affect one or two games at a time.
I'd like to start doing some major cleaning house internally (rename
NES->Famicom, SNES->SuperFamicom and such.) Would be much wiser to do
that on a .01 WIP to minimize regressions.
The main problems with a release now:
- speed is pretty bad, haven't really optimized much yet (not sure how
much we can improve it yet, this usually isn't easy)
- sound isn't -great-, but the GBA audio sucks anyway :P
- couple of known bugs (Sonic X video, etc.)
2012-04-22 10:49:19 +00:00
|
|
|
if(regs.vcounter < 160) cpu.dma_hdma();
|
2012-03-31 08:17:36 +00:00
|
|
|
|
2012-04-07 08:17:49 +00:00
|
|
|
step(32);
|
2012-03-31 08:17:36 +00:00
|
|
|
if(++regs.vcounter == 228) regs.vcounter = 0;
|
2012-03-19 11:19:53 +00:00
|
|
|
}
|
|
|
|
|
|
2015-11-16 08:38:05 +00:00
|
|
|
auto PPU::frame() -> void {
|
2013-12-20 11:40:39 +00:00
|
|
|
player.frame();
|
Update to v098r04 release.
byuu says:
Changelog:
- SFC: fixed behavior of 21fx $21fe register when no device is connected
(must return zero)
- SFC: reduced 21fx buffer size to 1024 bytes in both directions to
mirror the FT232H we are using
- SFC: eliminated dsp/modulo-array.hpp [1]
- higan: implemented higan/video interface and migrated all cores to it
[2]
[1] the echo history buffer was 8-bytes, so there was no need for it at
all here. Not sure what I was thinking. The BRR buffer was 12-bytes, and
has very weird behavior ... but there's only a single location in the
code where it actually writes to this buffer. It's much easier to just
write to the buffer three times there instead of implementing an entire
class just to abstract away two lines of code. This change actually
boosted the speed from ~124.5fps to around ~127.5fps, but that's within
the margin of error for GCC. I doubt it's actually faster this way.
The DSP core could really use a ton of work. It comes from a port of
blargg's spc_dsp to my coding style, but he was extremely fond of using
32-bit signed integers everywhere. There's a lot of opportunity to
remove red tape masking by resizing the variables to their actual state
sizes.
I really need to find where I put spc_dsp6.sfc from blargg. It's a great
test to verify if I've made any mistakes in my implementation that would
cause regressions. Don't suppose anyone has it?
[2] so again, the idea is that higan/audio and higan/video are going to
sit between the emulation cores and the user interfaces. The hope is to
output raw encoding data from the emulation cores without having to
worry about the video display format (generally 24-bit RGB) of the host
display. And also to avoid having to repeat myself with eg three
separate implementations of interframe blending, and so on.
Furthermore, the idea is that the user interface can configure its side
of the settings, and the emulation cores can configure their sides.
Thus, neither has to worry about the other end. And now we can spin off
new user interfaces much easier without having to mess with all of these
things.
Right now, I've implemented color emulation, interframe blending and
SNES horizontal color bleed. I did not implement scanlines (and
interlace effects for them) yet, but I probably will at some point.
Further, for right now, the WonderSwan/Color screen rotation is busted
and will only show games in the horizontal orientation. Obviously this
must be fixed before the next official release, but I'll want to think
about how to implement it.
Also, the SNES light gun pointers are missing for now.
Things are a bit messy right now as I've gone through several revisions
of how to handle these things, so a good house cleaning is in order once
everything is feature-complete again. I need to sit down and think
through how and where I want to handle things like light gun cursors,
LCD icons, and maybe even rasterized text messages.
And obviously ... higan/audio is still just nall::DSP's headers. I need
to revamp that whole interface. I want to make it quite powerful with
a true audio mixer so I can handle things like
SNES+SGB+MSU1+Voicer-Kun+SNES-CD (five separate audio streams at once.)
The video system has the concept of "effects" for things like color
bleed and interframe blending. I want to extend on this with useful
other effects, such as NTSC simulation, maybe bringing back my mini-HQ2x
filter, etc. I'd also like to restore the saturation/gamma/luma
adjustment sliders ... I always liked allowing people to compensate for
their displays without having to change settings system-wide. Lastly,
I've always wanted to see some audio effects. Although I doubt we'll
ever get my dream of CoreAudio-style profiles, I'd like to get some
basic equalizer settings and echo/reverb effects in there.
2016-04-11 21:29:56 +00:00
|
|
|
Emulator::video.refresh(output, 240 * sizeof(uint32), 240, 160);
|
2016-02-09 11:51:12 +00:00
|
|
|
scheduler.exit(Scheduler::Event::Frame);
|
2012-03-19 11:19:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|