if false, the emulator is free to gain whatever speedup it can by not doing audio processing (shouldn't change anything sync related, though)
the core should still always call SoundProvider.GetSamples() after each FrameAdvance(), else DRAGONS
at the moment, only test-implemented in gambattehawk
Internally, Gambatte implements this as a full hard reset of everything except saveram. There are comments in the code to suggest that this is appropriate real console behavior...
i don't like doing this, but there were already two emus with special bandaid logic in MainForm.cs
i hope this doesn't break something, but if it does i'll fix it
in order to guarantee correct resolution of mappings and mmio every time, all calls go straight to the core and are not cached
this makes this domain slower in performance than the other ones. it can also be more difficult to use in some cases because you have to resolve mappings that you may not care about.
there is also the possibility of side-effects on reads, although i do not believe that this actually happens in any situations. still, use at your own risk.
--Haven't done anything with the flags because I don't know what they are supposed to do yet.
--Speedy Gonzales v2 doesn't sync after being converted, but I don't think that's my fault.
-Flags and other data will be parsed soon.
haven't decided yet whether i like the idea; it's mostly about playing nice with other audio mixing (from other applications)
well, it's not bad anyway...
per ilari, this should work correctly on certain games that poll the input in a particular way. however, it is completely non-functional on many other games. core digging is required for anything better.
--The only time I've seen this was in a game that used FGBG mode, and it looked messed up.
-Implemented the parsing of the background for Color Stack mode.
--Because the STIC Registers aren't populated, this doesn't do anything. I'm not sure when this is supposed to occur.
-Determined when Colored Squares mode is active. I'll try to implement this mode shortly.
--Did the same for the PSG because why not.
-Discovered that the Commando HLT happens after the CPU goes idle, so there's no point in further investigating the issue until I emulate that.
-Parsed the BACKTAB cards for the STIC's Draw().
-Attempted to draw the screen using the aforementioned cards.
--I'm only trying to apply color to the foreground.
---Instead of converting the FG color to RGBA, I'm making it all white for now.
--There's clearly some sanity to what's being drawn, so I think each 8x8 card is being drawn in the right place.
--I think the next step is trying to make each individual card draw properly.
--I believe the algorithm for populating the FrameBuffer is VERY inefficient in the way it accesses memory. Will need some suggestions as to how I can rewrite this.
it seems to be the most stable when the system is fast enough to maintain approximately 100% speed.
also fixed up metaspu in dumping and switched it to vecna. i can now have clean audio while running libsnes with lua script and ffmpeg dumping.
add two example resamplers that implement this: LinearResampler and CubicResampler. both are very basic and sound like shit compared to libresample4j
ultimately, a single good resampler with a better license than libresample4j should be selected and used
--VirtualHeight / Width will be useful due to how the scanlines are doubled on TVs, but for now, I will just be drawing to scale.
-Enabled XOR@, SAR, and COMR. Advanced Dungeons & Dragons provided more test cases.
-Noticed that Commando, as well as some other games, triggers a HLT. This should be looked into later.
--This number is fairly arbitrary, and I don't know why it works, but for now, it does.
--The values of INTRM don't match up exactly, but I think this is mostly a logging issue, though I still need to look into this.
-Fixed the Overflow Flag calculation.
--My original formula didn't compare the signs of the operands.
--It always needs to use the original operands, not the 2s complement one.
--As such, a result parameter has been added.
-Fixed the detection of a double swap, shift, and rotate in the related instructions. Ironically, I shifted one too many bits in my detection.
-Masked the result of left shifts and rotates to 0xFFFF so that the flags are calculated properly.
-Made RSWD (un)set the right flags.
-Enabled GSWD, MVI, SARC, CMP@, ADD, SUB@, INCR, RRC, SLR, SLL, RLC, ADDR, SUBR, SLLC, CMPR, and RSWD.
-COMR, NEGR, ADCR, SAR, ANDR, SUB, AND, XOR, and XOR@ remain disabled as I have yet to hit any test cases for them.
At this point, IntelliHawk is executing instructions indefinitely with what seems to be perfect results! I think I'm ready to hook up the screen.
goyuken