bsnes/supergameboy/interface/interface.hpp
byuu a266a2b5e2 Update to bsnes v066 release.
Major features in this release are: serial controller emulation, a brand new scheduler that supports multiple simultaneous coprocessors, and accuracy improvements.
The serial controller is something devised by blargg. With the proper voltage adjustments (5v-9v), it is possible to wire an SNES controller to a serial port, which can then be used for bidirectional communication between the SNES, and (usually, but not only) a PC. The support in bsnes was added so that such programs could be debugged and ran from within an emulator, and not just on real hardware.
The scheduler rewrite was meant to allow the combination of coprocessors. It was specifically meant to allow the serial controller thread to run alongside the SuperFX and SA-1 coprocessor threads, but it also allows fun things like MSU1 support in SuperFX and SA-1 games, and even creating dev cartridges that utilize both the SuperFX and SA-1 at the same time. The one thing not yet allowed is running multiple instances of the exact same coprocessor at the same time, as this is due to design constraints favoring code inlining.
There are two important accuracy updates. The first is that when PAL video mode is used without being in overscan mode, black bars are shown. Emulators have always shown this black bar at the bottom of the screen, but this is actually incorrect. resxto took pictures from his PAL TV that shows the image is in fact vertically centered in the screen. bsnes has been updated to reflect this.
Also interesting is that I have backported some code from the dot-based PPU renderer. In the game Uniracers, it writes to OAM during Hblank, and expects the write to go to a specific address. In previous releases, that address was hard-coded to go to the required memory location. But the way the hardware really works is that the write goes to the extended attribute address for the last sprite that the PPU fetched, as the PPU is still asserting the OAM address bus. Now, due to the precision limitations, I was not able to also port timing access during the active display period. However, this is sufficient to at least remove the last global hack from the older, speed-focused scanline renderer.
2010-08-01 05:46:17 +00:00

80 lines
1.7 KiB
C++

class SuperGameBoy : public Gambatte::VideoBlitter, public Gambatte::InputStateGetter {
public:
Gambatte::GB *gambatte;
//SuperGameBoy::MMIO
unsigned vram_row;
uint8_t vram[320];
struct MMIO {
uint8_t r6000;
uint8_t r6003;
uint8_t r6004;
uint8_t r6005;
uint8_t r6006;
uint8_t r6007;
uint8_t r7000[16];
unsigned r7800;
uint8_t mlt_req;
} mmio;
//SuperGameBoy::Packet
static const char command_name[32][64];
struct Packet {
uint8_t data[16];
uint8_t& operator[](unsigned addr) { return data[addr & 15]; }
};
Packet packet[64];
unsigned packetsize;
unsigned joyp_id;
bool joyp15lock;
bool joyp14lock;
bool pulselock;
bool strobelock;
bool packetlock;
Packet joyp_packet;
uint8_t packetoffset;
uint8_t bitdata, bitoffset;
void joyp_write(bool p15, bool p14);
//SuperGameBoy::Core
uint8_t *romdata, *ramdata, *rtcdata;
unsigned romsize, ramsize, rtcsize;
bool version;
bool init(bool version);
void term();
unsigned run(uint32_t *samplebuffer, unsigned samples);
void save();
void serialize(nall::serializer &s);
void power();
void reset();
void row(unsigned row);
uint8_t read(uint16_t addr);
void write(uint16_t addr, uint8_t data);
void mmio_reset();
void command_1e();
void render(unsigned row);
SuperGameBoy();
~SuperGameBoy();
//Gambatte::VideoBlitter
unsigned bufferWidth, bufferHeight;
uint32_t *buffer;
void setBufferDimensions(unsigned width, unsigned height);
const Gambatte::PixelBuffer inBuffer();
void blit();
//Gambatte::InputStateGetter
Gambatte::InputState inputState;
const Gambatte::InputState& operator()();
};
extern SuperGameBoy supergameboy;