|Re: [hatari-devel] New version of WinUAE's cpu core|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Am Mon, 24 Nov 2014 13:59:18 +0100
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
> Le 24/11/2014 13:01, Troed Sångberg a écrit :
> > (The space filling nop in region one might be needed to set d0 to 0
> > if later code relies upon it of course)
> > I don't think region two can be solved (it's 7 words, not bytes as I
> > wrote earlier) in the same amount of code space, which means a
> > proper solution would need to jump to another part of memory to
> > execute proper initialization and then back. The only solution that
> > fits in seven words relies heavily on assumptions about (a0) not
> > being used for subsequent code, that we're free to abuse the even
> > memory locations (I'm unsure if that's valid on more modern Ataris)
Writing to the even addresses should be fine with Hatari (as long as
the uneven address is written in the same access, too).
> > and that uninitialized means zero or at least a known static value
> > (which is likely not true). That is - the following is not a real
> > suggestion, it's just what's needed to get code to fit in the same
> > space. Maybe it helps someone else coming up with something better.
> > lea $fffffa26.w,a0
> > clr.w (a0)+
> > move.w #$88,(a0)+
> > addq.w #1,(a0)+
> > addq.w #5,(a0)
> > /Troed
Right after the code, there is a:
$e02640 : 4a39 0000 0a87 tst.b $a87
I think this also could be shortened by two bytes by using $a87.w
instead? Of course, we would also have to make sure that no other code
jumps to $e02640 directly.
> thanks for your examples.
> I think it might be possible to find a place in the TOS area were
> some bytes are unused, this way we could replace the 2nd code by a
> jsr somewhere in this region, which leaves more space to put a small
> bit of code.
That could work, too. I also wonder what the Centurbo060 TOS is doing
for movep? Are they emulating it?
> IIRC, the tos performs a checksum of its region, but there's already
> some patches to set the corresponding variable to "checksum OK" ?
Right, since we're patching TOS already, the checksum is skipped for
all known TOS versions.