byuu says:
Changelog:
- removed Emulator::Interface::videoFrequency(), audioFrequency()¹
- (MS,GG,MD)/PSG: removed inversion on noise channel LFSR update
[mic_]
- MD/PSG: lowered volume to match YM2612 volume
- MD/YM2612: added Cydrak's emulation of FM channels and LFO²
¹: These were no longer used by the UI. The video frequency is
adaptive on many systems. And the audio frequency is meaningless due to
Emulator::Audio always outputting a consistent frequency specified by
the UI. Plus, take the Genesis where there's two sound chips running at
different frequencies. So, these had to go.
²: Due to some lurking bugs, the audio is completely broken
unfortunately. Will need to be debugged :(
First pass looking for any typos didn't yield any obvious results.
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.
byuu says:
Changelog:
- MD: restructured DMA to a subclass of VDP
- MD: implemented VRAM copy mode (fixes Langrisser II ... mostly)
- MS: implemened PSG support [Cydrak]
- GG: implemented PSG stereo sound support
- MS: use the new struct Model {} design that other cores use
The MS/GG PSG should be feature complete, but I don't have good tests
for Game Gear stereo mode, nor for the noise channel. There's also a
really weird behavior with when to reload the channel counters on volume
register writes. I can confirm what Cydrak observed in that following
the docs and reloading always creates serious audio distortion problems.
So, more research is needed there.
To get the correct sound out of the PSG, I have to run it at 3.58MHz /
16, which seems really weird to me. The docs make it sound like it's
supposed to run at the full 3.58MHz. If we can really run it at
223.7KHz, then that's help reduce the overhead of PSG emulation, which
will definitely come in handy for Mega Drive, and possibly later Mega
CD, emulation.
I have not implemented the PSG into the Mega Drive just yet. Nor have I
implemented save states or cheat code support into the MS/GG cores yet.
The latter is next on my list.
byuu says:
Changelog:
- Super Game Boy support is functional once again
- new GameBoy::SuperGameBoyInterface class
- system.(dmg,cgb,sgb) is now Model::(Super)GameBoy(Color) ala the PC
Engine
- merged WonderSwanInterface, WonderSwanColorInterface shared
functions to WonderSwan::Interface
- merged GameBoyInterface, GameBoyColorInterface shared functions to
GameBoy::Interface
- Interface::unload() now calls Interface::save() for Master System,
Game Gear, Mega Drive, PC Engine, SuperGrafx
- PCE: emulated PCE-CD backup RAM; stored per-game as save.ram (2KiB
file)
- this means you can now save your progress in games like Neutopia
- the PCE-CD I/O registers like BRAM write protect are not
emulated yet
- PCE: IRQ sources now hold the IRQ line state, instead of the CPU
holding it
- this fixes most SuperGrafx games, which were fighting over the
VDC IRQ line previously
- PCE: CPU I/O $14xx should return the pending IRQ bits even if IRQs
are disabled
- PCE: VCE and the VDCs now synchronize to each other; fixes pixel
widths in all games
- PCE: greatly increased the accuracy of the VPC priority selection
code (windows may be buggy still)
- HuC6280: PLA, PLX, PLY should set Z, N flags; fixes many game bugs
[Jonas Quinn]
The big thing I wanted to do was enslave the VDC(s) to the VCE. But
unfortunately, I forgot about the asynchronous DMA channels that each
VDC supports, so this isn't going to be possible I'm afraid.
In the most demanding case, Daimakaimura in-game, we're looking at 85fps
on my Xeon E3 1276v3. So ... not great, and we don't even have sound
connected yet.
We are going to have to profile and optimize this code once sound
emulation and save states are in.
Basically, think of it like this: the VCE, VDC0, and VDC1 all have the
same overhead, scheduling wise (which is the bulk of the performance
loss) as the dot-renderer for the SNES core. So it's like there's three
bsnes-accuracy PPU threads running just for video.
-----
Oh, just a fair warning ... the hooks for the SGB are a work in
progress.
If anyone is working on higan or a fork and want to do something similar
to it, don't use it as a template, at least not yet.
Right now, higan looks like this:
- Emulator::Video handles the platform→videoRefresh calls
- Emulator::Audio handles the platform→audioSample calls
- each core hard-codes the platform→inputPoll, inputRumble calls
- each core hard-codes calls to path, open, load to process files
- dipSettings and notify are specialty hacks, neither are even hooked
up right now to anything
With the SGB, it's an emulation core inside an emulation core, so
ideally you want to hook all of those functions. Emulator::Video and
Emulator::Audio aren't really abstractions over that, as the GB core
calls them and we have to special case not calling them in SGB mode.
The path, open, load can be implemented without hooks, thanks to the UI
only using one instance of Emulator::Platform for all cores. All we have
to do is override the folder path ID for the "Game Boy.sys" folder, so
that it picks "Super Game Boy.sfc/" and loads its boot ROM instead.
That's just a simple argument to GameBoy::System::load() and we're done.
dipSettings, notify and inputRumble don't matter. But we do also have to
hook inputPoll as well.
The nice idea would be for SuperFamicom::ICD2 to inherit from
Emulator::Platform and provide the desired functions that we need to
overload. After that, we'd just need the GB core to keep an abstraction
over the global Emulator::platform\* handle, to select between the UI
version and the SFC::ICD2 version.
However ... that doesn't work because of Emulator::Video and
Emulator::Audio. They would also have to gain an abstraction over
Emulator::platform\*, and even worse ... you'd have to constantly swap
between the two so that the SFC core uses the UI, and the GB core uses
the ICD2.
And so, for right now, I'm checking Model::SuperGameBoy() -> bool
everywhere, and choosing between the UI and ICD2 targets that way. And
as such, the ICD2 doesn't really need Emulator::Platform inheritance,
although it certainly could do that and just use the functions it needs.
But the SGB is even weirder, because we need additional new signals
beyond just Emulator::Platform, like joypWrite(), etc.
I'd also like to work on the Emulator::Stream for the SGB core. I don't
see why we can't have the GB core create its own stream, and let the
ICD2 just use that instead. We just have to be careful about the ICD2's
CPU soft reset function, to make sure the GB core's Stream object
remains valid. What I think that needs is a way to release an
Emulator::Stream individually, rather than calling
Emulator::Audio::reset() to do it. They are shared\_pointer objects, so
I think if I added a destructor function to remove it from
Emulator::Audio::streams, then that should work.
byuu says:
Changelog:
- I caved on the `samples[] = {0.0}` thing, but I'm very unhappy about it
- if it's really invalid C++, then GCC needs to stop accepting it
in strict `-std=c++14` mode
- Emulator::Interface::Information::resettable is gone
- Emulator::Interface::reset() is gone
- FC, SFC, MD cores updated to remove soft reset behavior
- split GameBoy::Interface into GameBoyInterface,
GameBoyColorInterface
- split WonderSwan::Interface into WonderSwanInterface,
WonderSwanColorInterface
- PCE: fixed off-by-one scanline error [hex_usr]
- PCE: temporary hack to prevent crashing when VDS is set to < 2
- hiro: Cocoa: removed (u)int(#) constants; converted (u)int(#)
types to (u)int_(#)t types
- icarus: replaced usage of unique with strip instead (so we don't
mess up frameworks on macOS)
- libco: added macOS-specific section marker [Ryphecha]
So ... the major news this time is the removal of the soft reset
behavior. This is a major!! change that results in a 100KiB diff file,
and it's very prone to accidental mistakes!! If anyone is up for
testing, or even better -- looking over the code changes between v102r01
and v102r02 and looking for any issues, please do so. Ideally we'll want
to test every NES mapper type and every SNES coprocessor type by loading
said games and power cycling to make sure the games are all cleanly
resetting. It's too big of a change for me to cover there not being any
issues on my own, but this is truly critical code, so yeah ... please
help if you can.
We technically lose a bit of hardware documentation here. The soft reset
events do all kinds of interesting things in all kinds of different
chips -- or at least they do on the SNES. This is obviously not ideal.
But in the process of removing these portions of code, I found a few
mistakes I had made previously. It simplifies resetting the system state
a lot when not trying to have all the power() functions call the reset()
functions to share partial functionality.
In the future, the goal will be to come up with a way to add back in the
soft reset behavior via keyboard binding as with the Master System core.
What's going to have to happen is that the key binding will have to send
a "reset pulse" to every emulated chip, and those chips are going to
have to act independently to power() instead of reusing functionality.
We'll get there eventually, but there's many things of vastly greater
importance to work on right now, so it'll be a while. The information
isn't lost ... we'll just have to pull it out of v102 when we are ready.
Note that I left the SNES reset vector simulation code in, even though
it's not possible to trigger, for the time being.
Also ... the Super Game Boy core is still disconnected. To be honest, it
totally slipped my mind when I released v102 that it wasn't connected
again yet. This one's going to be pretty tricky to be honest. I'm
thinking about making a third GameBoy::Interface class just for SGB, and
coming up with some way of bypassing platform-> calls when in this
mode.
byuu says:
Changelog:
- SMS: fixed controller connection bug
- SMS: fixed Z80 reset bug
- PCE: emulated HuC6280 MMU
- PCE: emulated HuC6280 RAM
- PCE: emulated HuCard ROM reading
- PCE: implemented 178 instructions
- tomoko: removed "soft reset" functionality
- tomoko: moved "power cycle" to just above "unload" option
I'm not sure of the exact number of HuC6280 instructions, but it's less
than 260.
Many of the ones I skipped are HuC6280-originals that I don't know how
to emulate just yet.
I'm also really unsure about the zero page stuff. I believe we should be
adding 0x2000 to the addresses to hit page 1, which is supposed to be
mapped to the zero page (RAM). But when I look at turboEMU's source, I
have no clue how the hell it could possibly be doing that. It looks to
be reading from page 0, which is almost always ROM, which would be ...
really weird.
I also don't know if I've emulated the T mode opcodes correctly or not.
The documentation on them is really confusing.
byuu says:
Changelog:
- converted Emulator::Interface::Bind to Emulator::Platform
- temporarily disabled SGB hooks
- SMS: emulated Game Gear palette (latching word-write behavior not
implemented yet)
- SMS: emulated Master System 'Reset' button, Game Gear 'Start' button
- SMS: removed reset() functionality, driven by the mappable input now
instead
- SMS: split interface class in two: one for Master System, one for
Game Gear
- SMS: emulated Game Gear video cropping to 160x144
- PCE: started on HuC6280 CPU core—so far only registers, NOP
instruction has been implemented
Errata:
- Super Game Boy support is broken and thus disabled
- if you switch between Master System and Game Gear without
restarting, bad things happen:
- SMS→GG, no video output on the GG
- GG→SMS, no input on the SMS
I'm not sure what's causing the SMS\<-\>GG switch bug, having a hard
time debugging it. Help would be very much appreciated, if anyone's up
for it. Otherwise I'll keep trying to track it down on my end.
byuu says:
Changelog:
- SMS: emulated the remaining 240 instructions in the (0xfd, 0xdd)
0xcb (displacement) (opcode) set
- 1/8th of these were "legal" instructions, and apparently games
use them a lot
- SMS: emulated the standard gamepad controllers
- reset button not emulated yet
The reset button is tricky. In every other case, reset is a hardware
thing that instantly reboots the entire machine.
But on the SMS, it's more like a gamepad button that's attached to the
front of the device. When you press it, it fires off a reset vector
interrupt and the gamepad polling routine lets you query the status of
the button.
Just having a reset option in the "Master System" hardware menu is not
sufficient to fully emulate the behavior. Even more annoying is that the
Game Gear doesn't have such a button, yet the core information structs
aren't flexible enough for the Master System to have it, and the Game
Gear to not have it, in the main menu. But that doesn't matter anyway,
since it won't work having it in the menu for the Master System.
So as a result, I'm going to have to have a new "input device" called
"Hardware" that has the "Reset" button listed under there. And for the
sake of consistency, I'm not sure if we should treat the other systems
the same way or not :/
byuu says:
Changelog:
- 68K: MOVEQ is 8-bit signed
- 68K: disassembler was print EOR for OR instructions
- 68K: address/program-counter indexed mode had the signed-word/long
bit backward
- 68K: ADDQ/SUBQ #n,aN always works in long mode; regardless of size
- 68K→VDP DMA needs to use `mode.bit(0)<<22|dmaSource`; increment by
one instead of two
- Z80: added registers and initial two instructions
- MS: hooked up enough to load and start running games
- Sonic the Hedgehog can execute exactly one instruction... whoo.
Tim Allen