Can someone fix the emulation now, please?
About BMXY and similar commands, GhostWriterP reported a about not working in P modes . (That is a little strange). Someone with real hw can define more exactly what does mean "not working" in order to improve emulation?
I was talking about these things:
well, xy to linear and visa versa are two commands that do not work properly in P1, at least I never managed to
.
I'm not sure if this is emulated. Is it?
regular copy (LMMM) just works fine, just put the coordinates correctly (i.e. 2 bytes / 4 pixels aligned - since name table is 16 bit per tile). Although, there is some emulation issue in openMSX that it does not always update the name table when using command engine, guess some emulation code optimization implemented? But on real thing it works OK.
Can you make a test case for this one? That would help. (ROM or disk file preferred, with sources.)
No experience with P2, that is something you need to test yourself (on real hardware, do not trust openMSX just yet
)
I agree with this. But do report the differences and provide test software with sources and a description on what it does on real thing.
I was talking about these things:
well, xy to linear and visa versa are two commands that do not work properly in P1, at least I never managed to
.
I'm not sure if this is emulated. Is it?
without knowing what behaiviour to emulate it's hard to emulate. Looking at openMSX sources it does not appear to emulate anything strange
It has been over a decade (about 2008) when I tested these thing on real hardware.
But, I do remember that with BMXL the bytes written got a "step size" of 2 bytes, i.e. ABC became A B C . I expect BMLX would do something similar but inverse...
PS: And yes I am aware you need to do some adjustment with the address pointer, as is required for BMLL, but I tried several options back then without any success.
@manuel
I'm not sure if this is emulated. Is it?
Never tried it since, so I dunno.
Can you make a test case for this one? That would help. (ROM or disk file preferred, with sources.)
I have a rom image from the shelve, but it is highly confidential
.
GhostWriterP: according to the sources, BMXL does 2 bytes per iteration in 16bpp, but not so for the other modes. Anyway, there is no optimization implemented if it would affect how it works compared with real hardware, of course. At least not intentionally.
Can you make a small test program that demonstrates the issue? Then we have a chance to fix it!
according to the sources, BMXL does 2 bytes per iteration in 16bpp, but not so for the other modes. Anyway, there is no optimization implemented if it would affect how it works compared with real hardware, of course. At least not intentionally.
P1 is a weird interleaved mode, so that may have something to do with it. In B mode I used BMXL on occasion and it is correctly emulated.
The optimization relates to the other issue. Of the name table update during display by using command engine.
Can you make a small test program that demonstrates the issue? Then we have a chance to fix it!
I think about sending the rom image (and sources) after stripping a bit, where do I need send it to?
Just send it to me or put it in a tracker ticket on our GitHub site. That is the best option, as it will enable commenting and discussing there in a comfortable way.
Just had a brief look at the source code and it has a lot of other stuff in it what would only be confusing, plus it takes like 10 - 20 s before it goes wrong. I will see if I can simple test program in dos that will go wrong all the time... until it is fixed
