Re: [hatari-devel] test needed on a 4MB STF

[ Thread Index | Date 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 :)


Nicolas





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/