It is so much bizzarre than i'm ashamed to tell about:
the R18 corruption seems to appear not very often, if the misgnaling between the new r18 value and the cmd engine takes one scanline to re-align i expect to see the corruption more than one time x scanline on the average. this is because the vdp can move rougly more than 1 byte x scanline during command execution.
I expect that the misaligning got fixed just after the next byte read or written after the corrupted one.
so the idea was this. if i can pause the VDP CMD engine as long enough to delay the vdp byte write/read operation from CMD Engine, by issuing a in a, (0x98) there is a chance that the CPU I/O request takes place stealing a cycle to the VDP engine, the readed byte could be corrupted, but it does not matter, because its value is discarded.
However there should be the chance that the vdp has already in queue a byte I/O for the cmd engine and the CPU I/O got delayed. in this scenario, corruption occours.
But maybe my idea could serve as a basis for another similar approach.
I'm not sure if i explained clearly the trick, anyway
What's do you think about this?
ARTRAG wrote:
Something like this ?
ld de,value+(18+128)*256
ld c,0x99
out(c),e
in a,(0x98)
out(c),d
I.e. by occupying the bus with the CPU, the command engine should take the slot after R18 has been changed
the problem may be .... when exactly one should "shoot" the in a, (0x98) ? maybe there is a pending cmd byte transfer ... how much it is safe to wait for the final out(c),d ? complex....
thx, but this scenario is more like a trial and error scenario. Most probably i need to try different test based on the previous ones, this lead to a too much higher interation between us, like try v1:
not working:
"modifify". rebuild the rom re-send re test.
it would be better to have a test based on .com file to quickly rebuild and test.
thx, but this scenario is more like a trial and error scenario. Most probably I need to try different tests based on the previous ones, this leads to a much higher interaction between us, like try v1:
not working:
"modify". rebuild the ROM re-send re-test.
it would be better to have a test based on a .com file to quickly rebuild and test.
We can do COM or ROM. I can run both. ROM is easier since not every MSX has FDD. Send me the source, preferably in TNIASM, but I can modify it if it is in a different assembler. And then I can compile and test and take a picture with results.
