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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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