|Re: [hatari-devel] test needed on a 4MB STF|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 22/12/2016 à 19:29, Christian Zietz a écrit :
I guess this is what manifests itself as strange scrolling patterns in
your test program?
Yes, that's it. When you set video address between end of RAM and before
4MB, you can see the activity on the bus (this means you can't see it on
a 4MB STF/STE)
I have another small program that runs 4000 similar instructions in a
row while pointing to this region.
In that case, if you execute 4000 "nop" in a loop for example (ie 4000
"nop" then a branch to restart the loop), then you clearly see that the
pattern on screen correspond to the word $4e71 read in all 4 bitplanes,
so you get some kind of pattern repeated on screen using color 15.
Same if you execute 4000 "or.b #0,d0" (which is the value $0000), then
you see that the empty region won't display random pattern, but just
some bitmap using color 0 (as $0000 will be loaded in all 4 bitplanes))
If you do 4000 "or.b d0,d0" (hex $8000), then you will see some vertical
1 pixel line using color 15, repeated every 16 pixels.
Of course, each time the cpu prefetch some different instructions, then
you change the data bus content and you alter the result on screen,
hence the idea to repeat the same instruction a lot of times to be able
to see what happens on the bus during a longer period.
If so, then I also see the "hole" in the 40000 -> 80000 region on my STF
with the Ricoh MMU. I don't know how to reproduce your test case on the
STF with the IMP MMU, though, given that it doesn't support different
bank sizes between banks 0 and 1.
Indeed, I don't see how to do it on IMP MMU.
Might be some bit combinations again that are supposed to work when we
go beyond total ram, but that triggers in some unexpected cases too.
Again, the circuitry inside the MMU that decides which bank is accessed
is very complex. Thus, it's hard to say, but probably it doesn't cover
all combinations of bank sizes properly.
I agree, not really needed for emulation too, but it's true that when
you nearly have a description of the inner working of this part of the
MMU, it would be nice to understand the reason and duplicate even the
strangest effect :)