ohoho, I chose screen 1 cause colortable is only 32 bytes, and I can use multiple patterntables. I didn't add a sprite flickering routine, I need the sprite overflow bit for mid-screen pattern table split later.
Congratulations for the game. It's very close to the original and I enjoyed a lot
As previously people here said, please don't let it become vaporware...
@hap
Is it running on screen1?! Really impressive! With it's "8 patterns colorbleed" limitation, you got a hell of a good result on this game!
I did some tests to check for bugs, and here are the results. I hope they help you:
1) Turbo test: passed!
2) SubSlot handling: passed Acid1Test!
3) MSX coding guidelines compliance: Failed Acid2Test, uses some hardcoded I/O access.
4) BIOS interface test: Passed running both on C-BIOS and on the Sharp Hotbit!
Wow that is a really frustrating game, but nicely made
3) fails: I like to write to I/O ports yes, such as out ($98),a for vdp. IMO using BIOS-calls is unneccesary, and I'd have to learn a new 'API' when I'm already expert on direct hardware access.
I support hap's programming approach, Acid2Test is matter to discussion, I don't think all coders want to respect the recommended guidelines as original approach can be better than normalized approach.
Err, doesn't the Acid2 test merely require that you check the system variables to find out which I/O ports to use for the odd MSX computer that uses different I/O ports?
Where are the ports for PPI and PSG stored then?
disasm the biosrom call code where they are accessed?
also, which MSX computer(s) is the odd MSX computer that uses different I/O ports? I can imagine that the NEOS MSX1-to-MSX2 kit uses different ports, but I've never seen one.
err, well.. uhm... only check which I/O ports to use for the VDP then?
Don't get me wrong, I agree that in the real world this check is hardly relevant.