--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.
-Added and Interrupted flag to make it so that interrupts only trigger once per falling edge.
-For now, interrupts take 28 cycles.
-Made it so that the STIC tracks Pending / Total Executed Cycles just like the CPU.
-Forwarded the cycles executed in the CPU to the STIC's Execute.
-SR1 is now inverted when there are no pending cycles.
--If SR1 is high, 14394 cycles are added to the pending cycles.
--If SR1 is low, 3791 cycles are added to the pending cycles.
beirich