2016-08-19 14:11:26 +00:00
|
|
|
//TI TMS9918A (derivative)
|
2016-08-17 12:31:22 +00:00
|
|
|
|
|
|
|
struct VDP : Thread {
|
|
|
|
static auto Enter() -> void;
|
|
|
|
auto main() -> void;
|
|
|
|
auto step(uint clocks) -> void;
|
2016-08-19 14:11:26 +00:00
|
|
|
auto refresh() -> void;
|
|
|
|
|
2016-12-26 12:09:56 +00:00
|
|
|
auto vlines() -> uint;
|
|
|
|
auto vblank() -> bool;
|
|
|
|
|
2016-08-19 14:11:26 +00:00
|
|
|
auto power() -> void;
|
|
|
|
|
Update to v101r24 release.
byuu says:
Changelog:
- SMS: extended bus mapping of in/out ports: now decoding them fully
inside ms/bus
- SMS: moved Z80 disassembly code from processor/z80 to ms/cpu
(cosmetic)
- SMS: hooked up non-functional silent PSG sample generation, so I can
cap the framerate at 60fps
- SMS: hooked up the VDP main loop: 684 clocks/scanline, 262
scanlines/frame (no PAL support yet)
- SMS: emulated the VDP Vcounter and Hcounter polling ... hopefully
it's right, as it's very bizarre
- SMS: emulated VDP in/out ports (data read, data write, status read,
control write, register write)
- SMS: decoding and caching all VDP register flags (variable names
will probably change)
- nall: \#undef IN on Windows port (prevent compilation warning on
processor/z80)
Watching Sonic the Hedgehog, I can definitely see some VDP register
writes going through, which is a good sign.
Probably the big thing that's needed before I can get enough into the
VDP to start showing graphics is interrupt support. And interrupts are
never fun to figure out :/
What really sucks on this front is I'm flying blind on the Z80 CPU core.
Without a working VDP, I can't run any Z80 test ROMs to look for CPU
bugs. And the CPU is certainly too buggy still to run said test ROM
anyway. I can't find any SMS emulators with trace logging from reset.
Such logs vastly accelerate tracking down CPU logic bugs, so without
them, it's going to take a lot longer.
2016-12-17 11:31:34 +00:00
|
|
|
//io.cpp
|
|
|
|
auto vcounter() -> uint8;
|
|
|
|
auto hcounter() -> uint8;
|
|
|
|
auto data() -> uint8;
|
|
|
|
auto status() -> uint8;
|
|
|
|
|
|
|
|
auto data(uint8) -> void;
|
|
|
|
auto control(uint8) -> void;
|
|
|
|
auto registerWrite(uint4 addr, uint8 data) -> void;
|
|
|
|
|
2016-12-30 07:24:35 +00:00
|
|
|
//background.cpp
|
|
|
|
struct Background {
|
|
|
|
auto scanline() -> void;
|
|
|
|
auto run() -> void;
|
|
|
|
|
|
|
|
auto power() -> void;
|
|
|
|
|
Update to v102r10 release.
byuu says:
Changelog:
- removed Emulator::Interface::Capabilities¹
- MS: improved the PSG emulation a bit
- MS: added cheat code support
- MS: added save state support²
- MD: emulated the PSG³
¹: there's really no point to it anymore. I intend to add cheat codes
to the GBA core, as well as both cheat codes and save states to the Mega
Drive core. I no longer intend to emulate any new systems, so these
values will always be true. Further, the GUI doesn't respond to these
values to disable those features anymore ever since the hiro rewrite, so
they're double useless.
²: right now, the Z80 core is using a pointer for HL-\>(IX,IY)
overrides. But I can't reliably serialize pointers, so I need to convert
the Z80 core to use an integer here. The save states still appear to
work fine, but there's the potential for an instruction to execute
incorrectly if you're incredibly unlucky, so this needs to be fixed as
soon as possible. Further, I still need a way to serialize
array<T, Size> objects, and I should also add nall::Boolean
serialization support.
³: I don't have a system in place to share identical sound chips. But
this chip is so incredibly simple that it's not really much trouble to
duplicate it. Further, I can strip out the stereo sound support code
from the Game Gear portion, so it's even tinier.
Note that the Mega Drive only just barely uses the PSG. Not at all in
Altered Beast, and only for a tiny part of the BGM music on Sonic 1,
plus his jump sound effect.
2017-02-22 21:25:01 +00:00
|
|
|
//serialization.cpp
|
|
|
|
auto serialize(serializer&) -> void;
|
|
|
|
|
2016-12-30 07:24:35 +00:00
|
|
|
struct State {
|
|
|
|
uint x;
|
|
|
|
uint y;
|
|
|
|
} state;
|
|
|
|
|
|
|
|
struct Output {
|
|
|
|
uint4 color;
|
|
|
|
uint1 palette;
|
|
|
|
uint1 priority;
|
|
|
|
} output;
|
|
|
|
} background;
|
|
|
|
|
|
|
|
//sprite.cpp
|
|
|
|
struct Sprite {
|
|
|
|
auto scanline() -> void;
|
|
|
|
auto run() -> void;
|
|
|
|
|
|
|
|
auto power() -> void;
|
|
|
|
|
Update to v102r10 release.
byuu says:
Changelog:
- removed Emulator::Interface::Capabilities¹
- MS: improved the PSG emulation a bit
- MS: added cheat code support
- MS: added save state support²
- MD: emulated the PSG³
¹: there's really no point to it anymore. I intend to add cheat codes
to the GBA core, as well as both cheat codes and save states to the Mega
Drive core. I no longer intend to emulate any new systems, so these
values will always be true. Further, the GUI doesn't respond to these
values to disable those features anymore ever since the hiro rewrite, so
they're double useless.
²: right now, the Z80 core is using a pointer for HL-\>(IX,IY)
overrides. But I can't reliably serialize pointers, so I need to convert
the Z80 core to use an integer here. The save states still appear to
work fine, but there's the potential for an instruction to execute
incorrectly if you're incredibly unlucky, so this needs to be fixed as
soon as possible. Further, I still need a way to serialize
array<T, Size> objects, and I should also add nall::Boolean
serialization support.
³: I don't have a system in place to share identical sound chips. But
this chip is so incredibly simple that it's not really much trouble to
duplicate it. Further, I can strip out the stereo sound support code
from the Game Gear portion, so it's even tinier.
Note that the Mega Drive only just barely uses the PSG. Not at all in
Altered Beast, and only for a tiny part of the BGM music on Sonic 1,
plus his jump sound effect.
2017-02-22 21:25:01 +00:00
|
|
|
//serialization.cpp
|
|
|
|
auto serialize(serializer&) -> void;
|
|
|
|
|
2016-12-30 07:24:35 +00:00
|
|
|
struct Object {
|
|
|
|
uint8 x;
|
|
|
|
uint8 y;
|
|
|
|
uint8 pattern;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct State {
|
|
|
|
uint x;
|
|
|
|
uint y;
|
|
|
|
} state;
|
|
|
|
|
|
|
|
struct Output {
|
|
|
|
uint4 color;
|
|
|
|
} output;
|
|
|
|
|
|
|
|
array<Object, 8> objects;
|
|
|
|
} sprite;
|
|
|
|
|
Update to v102r10 release.
byuu says:
Changelog:
- removed Emulator::Interface::Capabilities¹
- MS: improved the PSG emulation a bit
- MS: added cheat code support
- MS: added save state support²
- MD: emulated the PSG³
¹: there's really no point to it anymore. I intend to add cheat codes
to the GBA core, as well as both cheat codes and save states to the Mega
Drive core. I no longer intend to emulate any new systems, so these
values will always be true. Further, the GUI doesn't respond to these
values to disable those features anymore ever since the hiro rewrite, so
they're double useless.
²: right now, the Z80 core is using a pointer for HL-\>(IX,IY)
overrides. But I can't reliably serialize pointers, so I need to convert
the Z80 core to use an integer here. The save states still appear to
work fine, but there's the potential for an instruction to execute
incorrectly if you're incredibly unlucky, so this needs to be fixed as
soon as possible. Further, I still need a way to serialize
array<T, Size> objects, and I should also add nall::Boolean
serialization support.
³: I don't have a system in place to share identical sound chips. But
this chip is so incredibly simple that it's not really much trouble to
duplicate it. Further, I can strip out the stereo sound support code
from the Game Gear portion, so it's even tinier.
Note that the Mega Drive only just barely uses the PSG. Not at all in
Altered Beast, and only for a tiny part of the BGM music on Sonic 1,
plus his jump sound effect.
2017-02-22 21:25:01 +00:00
|
|
|
//serialization.cpp
|
|
|
|
auto serialize(serializer&) -> void;
|
|
|
|
|
2016-08-19 14:11:26 +00:00
|
|
|
private:
|
2017-01-13 01:15:45 +00:00
|
|
|
auto palette(uint5 index) -> uint12;
|
|
|
|
|
2017-01-13 23:59:38 +00:00
|
|
|
uint32 buffer[256 * 264];
|
Update to v101r24 release.
byuu says:
Changelog:
- SMS: extended bus mapping of in/out ports: now decoding them fully
inside ms/bus
- SMS: moved Z80 disassembly code from processor/z80 to ms/cpu
(cosmetic)
- SMS: hooked up non-functional silent PSG sample generation, so I can
cap the framerate at 60fps
- SMS: hooked up the VDP main loop: 684 clocks/scanline, 262
scanlines/frame (no PAL support yet)
- SMS: emulated the VDP Vcounter and Hcounter polling ... hopefully
it's right, as it's very bizarre
- SMS: emulated VDP in/out ports (data read, data write, status read,
control write, register write)
- SMS: decoding and caching all VDP register flags (variable names
will probably change)
- nall: \#undef IN on Windows port (prevent compilation warning on
processor/z80)
Watching Sonic the Hedgehog, I can definitely see some VDP register
writes going through, which is a good sign.
Probably the big thing that's needed before I can get enough into the
VDP to start showing graphics is interrupt support. And interrupts are
never fun to figure out :/
What really sucks on this front is I'm flying blind on the Z80 CPU core.
Without a working VDP, I can't run any Z80 test ROMs to look for CPU
bugs. And the CPU is certainly too buggy still to run said test ROM
anyway. I can't find any SMS emulators with trace logging from reset.
Such logs vastly accelerate tracking down CPU logic bugs, so without
them, it's going to take a lot longer.
2016-12-17 11:31:34 +00:00
|
|
|
uint8 vram[0x4000];
|
2017-01-13 01:15:45 +00:00
|
|
|
uint8 cram[0x40]; //MS = 0x20, GG = 0x40
|
Update to v101r24 release.
byuu says:
Changelog:
- SMS: extended bus mapping of in/out ports: now decoding them fully
inside ms/bus
- SMS: moved Z80 disassembly code from processor/z80 to ms/cpu
(cosmetic)
- SMS: hooked up non-functional silent PSG sample generation, so I can
cap the framerate at 60fps
- SMS: hooked up the VDP main loop: 684 clocks/scanline, 262
scanlines/frame (no PAL support yet)
- SMS: emulated the VDP Vcounter and Hcounter polling ... hopefully
it's right, as it's very bizarre
- SMS: emulated VDP in/out ports (data read, data write, status read,
control write, register write)
- SMS: decoding and caching all VDP register flags (variable names
will probably change)
- nall: \#undef IN on Windows port (prevent compilation warning on
processor/z80)
Watching Sonic the Hedgehog, I can definitely see some VDP register
writes going through, which is a good sign.
Probably the big thing that's needed before I can get enough into the
VDP to start showing graphics is interrupt support. And interrupts are
never fun to figure out :/
What really sucks on this front is I'm flying blind on the Z80 CPU core.
Without a working VDP, I can't run any Z80 test ROMs to look for CPU
bugs. And the CPU is certainly too buggy still to run said test ROM
anyway. I can't find any SMS emulators with trace logging from reset.
Such logs vastly accelerate tracking down CPU logic bugs, so without
them, it's going to take a lot longer.
2016-12-17 11:31:34 +00:00
|
|
|
|
|
|
|
struct IO {
|
2016-12-26 12:09:56 +00:00
|
|
|
uint vcounter; //vertical counter
|
|
|
|
uint hcounter; //horizontal counter
|
|
|
|
uint lcounter; //line counter
|
|
|
|
|
|
|
|
//interrupt flags
|
|
|
|
bool intLine;
|
|
|
|
bool intFrame;
|
|
|
|
|
|
|
|
//status flags
|
|
|
|
bool spriteOverflow;
|
|
|
|
bool spriteCollision;
|
|
|
|
uint5 fifthSprite;
|
Update to v101r24 release.
byuu says:
Changelog:
- SMS: extended bus mapping of in/out ports: now decoding them fully
inside ms/bus
- SMS: moved Z80 disassembly code from processor/z80 to ms/cpu
(cosmetic)
- SMS: hooked up non-functional silent PSG sample generation, so I can
cap the framerate at 60fps
- SMS: hooked up the VDP main loop: 684 clocks/scanline, 262
scanlines/frame (no PAL support yet)
- SMS: emulated the VDP Vcounter and Hcounter polling ... hopefully
it's right, as it's very bizarre
- SMS: emulated VDP in/out ports (data read, data write, status read,
control write, register write)
- SMS: decoding and caching all VDP register flags (variable names
will probably change)
- nall: \#undef IN on Windows port (prevent compilation warning on
processor/z80)
Watching Sonic the Hedgehog, I can definitely see some VDP register
writes going through, which is a good sign.
Probably the big thing that's needed before I can get enough into the
VDP to start showing graphics is interrupt support. And interrupts are
never fun to figure out :/
What really sucks on this front is I'm flying blind on the Z80 CPU core.
Without a working VDP, I can't run any Z80 test ROMs to look for CPU
bugs. And the CPU is certainly too buggy still to run said test ROM
anyway. I can't find any SMS emulators with trace logging from reset.
Such logs vastly accelerate tracking down CPU logic bugs, so without
them, it's going to take a lot longer.
2016-12-17 11:31:34 +00:00
|
|
|
|
2016-12-26 12:09:56 +00:00
|
|
|
//latches
|
Update to v101r24 release.
byuu says:
Changelog:
- SMS: extended bus mapping of in/out ports: now decoding them fully
inside ms/bus
- SMS: moved Z80 disassembly code from processor/z80 to ms/cpu
(cosmetic)
- SMS: hooked up non-functional silent PSG sample generation, so I can
cap the framerate at 60fps
- SMS: hooked up the VDP main loop: 684 clocks/scanline, 262
scanlines/frame (no PAL support yet)
- SMS: emulated the VDP Vcounter and Hcounter polling ... hopefully
it's right, as it's very bizarre
- SMS: emulated VDP in/out ports (data read, data write, status read,
control write, register write)
- SMS: decoding and caching all VDP register flags (variable names
will probably change)
- nall: \#undef IN on Windows port (prevent compilation warning on
processor/z80)
Watching Sonic the Hedgehog, I can definitely see some VDP register
writes going through, which is a good sign.
Probably the big thing that's needed before I can get enough into the
VDP to start showing graphics is interrupt support. And interrupts are
never fun to figure out :/
What really sucks on this front is I'm flying blind on the Z80 CPU core.
Without a working VDP, I can't run any Z80 test ROMs to look for CPU
bugs. And the CPU is certainly too buggy still to run said test ROM
anyway. I can't find any SMS emulators with trace logging from reset.
Such logs vastly accelerate tracking down CPU logic bugs, so without
them, it's going to take a lot longer.
2016-12-17 11:31:34 +00:00
|
|
|
bool controlLatch;
|
|
|
|
uint16 controlData;
|
|
|
|
uint2 code;
|
|
|
|
uint14 address;
|
|
|
|
|
|
|
|
uint8 vramLatch;
|
|
|
|
|
|
|
|
//$00 mode control 1
|
|
|
|
bool externalSync;
|
|
|
|
bool extendedHeight;
|
|
|
|
bool mode4;
|
|
|
|
bool spriteShift;
|
|
|
|
bool lineInterrupts;
|
|
|
|
bool leftClip;
|
|
|
|
bool horizontalScrollLock;
|
|
|
|
bool verticalScrollLock;
|
|
|
|
|
|
|
|
//$01 mode control 2
|
|
|
|
bool spriteDouble;
|
|
|
|
bool spriteTile;
|
|
|
|
bool lines240;
|
|
|
|
bool lines224;
|
|
|
|
bool frameInterrupts;
|
|
|
|
bool displayEnable;
|
|
|
|
|
|
|
|
//$02 name table base address
|
|
|
|
uint1 nameTableMask;
|
|
|
|
uint3 nameTableAddress;
|
|
|
|
|
|
|
|
//$03 color table base address
|
|
|
|
uint8 colorTableAddress;
|
|
|
|
|
|
|
|
//$04 pattern table base address
|
|
|
|
uint8 patternTableAddress;
|
|
|
|
|
|
|
|
//$05 sprite attribute table base address
|
|
|
|
uint1 spriteAttributeTableMask;
|
|
|
|
uint6 spriteAttributeTableAddress;
|
|
|
|
|
|
|
|
//$06 sprite pattern table base address
|
|
|
|
uint2 spritePatternTableMask;
|
|
|
|
uint1 spritePatternTableAddress;
|
|
|
|
|
|
|
|
//$07 backdrop color
|
|
|
|
uint4 backdropColor;
|
|
|
|
|
|
|
|
//$08 horizontal scroll offset
|
|
|
|
uint8 hscroll;
|
|
|
|
|
|
|
|
//$09 vertical scroll offset
|
|
|
|
uint8 vscroll;
|
|
|
|
|
|
|
|
//$0a line counter
|
|
|
|
uint8 lineCounter;
|
|
|
|
} io;
|
2016-08-17 12:31:22 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
extern VDP vdp;
|