bsnes/higan/processor/hg51b/hg51b.hpp

56 lines
981 B
C++
Raw Normal View History

#pragma once
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
//Hitachi HG51B169 (HG51BS family/derivative?)
namespace Processor {
struct HG51B {
auto exec(uint24 addr) -> void;
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
virtual auto read(uint24 addr) -> uint8 = 0;
virtual auto write(uint24 addr, uint8 data) -> void = 0;
auto power() -> void;
auto serialize(serializer&) -> void;
//uint16 programROM[2][256];
uint24 dataROM[1024];
uint8 dataRAM[3072];
protected:
auto push() -> void;
auto pull() -> void;
auto sa() -> uint;
auto ri() -> uint;
auto np() -> uint;
auto instruction() -> void;
//registers.cpp
Update to v102r27 release. byuu says: Changelog: - processor/gsu: minor code cleanup - processor/hg51b: renamed reg(Read,Write) to register(Read,Write) - processor/lr35902: minor code cleanup - processor/spc700: completed code cleanup (sans disassembler) - no longer uses internal global state inside instructions - processor/spc700: will no longer hang the emulator if stuck in a WAI (SLEEP) or STP (STOP) instruction - processor/spc700: fixed bug in handling of OR1 and AND1 instructions - processor/z80: minor code cleanup - sfc/dsp: revert to initializing registers to 0x00; save for ENDX=random(), FLG=0xe0 [Jonas Quinn] Major testing of the SNES game library would be appreciated, now that its CPU cores have all been revised. We know the DSP registers read back as randomized data ... mostly, but there are apparently internal latches, which we can't emulate with the current DSP design. So until we know which registers have separate internal state that actually *is* initialized, I'm going to play it safe and not break more games. Thanks again to Jonas Quinn for the continued research into this issue. EDIT: that said ... `MD works if((ENDX&0x30) > 0)` is only a 3:4 chance that the game will work. That seems pretty unlikely that the odds of it working are that low, given hardware testing by others in the past :/ I thought if worked if `PITCH != 0` before, which would have been way more likely. The two remaining CPU cores that need major cleanup efforts are the LR35902 and ARM cores. Both are very large, complicated, annoying cores that will probably be better off as full rewrites from scratch. I don't think I want to delay v103 in trying to accomplish that, however. So I think it'll be best to focus on allowing the Mega Drive core to not lock when processors are frozen waiting on a response from other processors during a save state operation. Then we should be good for a new release.
2017-06-19 02:07:54 +00:00
auto registerRead(uint8 addr) const -> uint24;
auto registerWrite(uint8 addr, uint24 data) -> void;
struct Registers {
bool halt;
uint24 pc;
uint16 p;
bool n;
bool z;
bool c;
uint24 a;
uint24 acch;
uint24 accl;
uint24 busdata;
uint24 romdata;
uint24 ramdata;
uint24 busaddr;
uint24 ramaddr;
uint24 gpr[16];
} regs;
uint24 stack[8];
uint16 opcode;
};
}