I do see the bug in the health bars now though, thanks for pointing it out! Looks like a bug in playfield priority setting, should be pretty simple to fix, I'm surprised it didn't come up before.
EDIT: oh yeah, I had trouble with that file too. mF8_sega.cs was included in the merge, and it shows up properly in the the folders, but for some reason isn't recognized by the project. I don't understand why though.
EDIT:
So it turns out this is a more complicated issue then I originally suspected. What the game is doing is setting playfield priority like this:
A5 04 LDA CXM0FB
85 0A STA CTRLPF
So it's loading A from the collision register that keeps track of collisions between missile 0 and playfield/Ball. Then it uses this to set playfield priority at 0A.
The problem is that the playfield priority bit is bit 2 of CTRLPF, but CXM0FB only uses bits 6 and 7. CXM0FB is a TIA read register, and as far as I know the CPU cannot write to the 2 bit of it (and anyway this would be a write to NUSIZ0 at 04 in the TIA write registers.)
This is all very confusing. I don't see how bit 2 of CXM0FB could be 1, as needed to change the playfield priority in this way, unless there is something unmodelled about the physical arrangement of these registers. Still researching an explanation.
EDIT AGAIN
Ok, apparently this is a well known issue of deciding what to do when there are unused pins on the data bus. Stella's solution is to simply use the last value that was there for each unused pin. It also however gives the option to randomly drive the pins.
Current AtariHawk code implicitly sets the pins to 0, since it's just returning a new byte with the appropriate collision bits set.
Apparently the unused ones are 'usually' in there previous state enough to make the Stella approach more desirable.
A bit sloppy to program something this way, but I'll try to account for it, since there are examples on real hardware that correctly display the health bar.
Ok, so on the left we see the old glitch version where the health bars show through the background. On the right the fixed version where they dont.
This is really just a programming error on the part of the game developer. Certainly he meant to write LDA #04, but forgot the '#' and simply wrote LDA 04 in whatever compiler he was using, a simple and common error. #04 is what is needed to change the playfield priority in the usual way. It is a stroke of luck that Loading CXM0FB doesn't change the bus state (04 being the last fetch and that register only effecting bits 6 and 7.) Any other situation would have made the error obvious.
Ultimately I simply added a bus state variable that is tracked along with everyhting else to fix this. Were it not for such an obscure case I surely would never have even thought of it. Maybe future work would be to make the bus state part of the CPU, but maybe not I'm not sure how practical / useful that would be.
Anyway that was an interesting excercise in bug hunting.
It turns out there was a rather serious bug in AtariHawk itself where PeekMemory actually pointed to ReadMemory in the system. This caused chaos when I tried to trace log out what was going, as the tracelogger peeks changed banks too when it shouldn't have. Once that got fixed it was only a matter of tracking down where banks weren't being changed properly.
The ultimate problem was just an incorrectly placed closing bracket. :(
Anyway this is still displaying things a bit Different then Stella, so I'll have to see why, but the test program looks perfect and anyway this is the only example game I could find.
EDIT: turns out I just needed to add in a vblank delay in the same manner as the numerous other latch delays. The demo game draws the screen in a unique fashion using vblank and needed this delay to match up the drawing edges. With this inclusion the game draws perfectly, so it looks like 4A50 and the associated bugs are now resolved.
Of course just getting it loaded up is only a small part of the battle, as there is currently no way to send it any meaningful input, but it's a start!
The most important things that came out of this is realizing that console startup needs to have improved accuracy for the compumate to work. The 'game' does not set the stack pointer appropriately before doing basic operations (as most games typicaly do) instead relying on the 6532 start up sequence. This sequence sends a reset signal to the 6507 which sets the stack pointer to FD.
The current code does not utilize this start up sequence instead just setting everything to default, which for the 6507 is stack pointer 0, which unfortunately overlaps TIA addresses, corrupting the return address of a JSR.
Anyway, I hardcoded in an initial stack pointer of FD simulating post reset behaviour, but I am ultimately not very satisfied with this approach and will probably try to use reset correctly, but right now I don't know how this will work with the current machinery.
