Re: [hatari-devel] New version of WinUAE's cpu core

(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) 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

On Mon, Nov 24, 2014 at 12:17 PM, Troed Sångberg <troed@xxxxxxxxxxx> wrote:

The first region clears $fffffa01, 03, 05, 07, 09, b, d, f, 11, 13, 15, 17 - without touching the even addresses.. It's a nice and proper usage of the movep instruction. Achieving the same using the same amount of code space (18 bytes, makes for simple patching) is doable. Suggestion:

lea $fffffa01.w,a0
moveq #11,d0
loop clr.b (a0)
lea 2(a0),a0
dbf d0,loop
nop

(The last nop is a space filler, this code is actually smaller than the original)

In hex:

41f8 fa01
700b 4210
41e8 0002
51c8 fff8
4e71

The second region is trickier due to space limitations. It sets $fffffa27 to $00, 29 to $88, 2b to $01 and 2d to $05 using only 7 bytes of code. A naïve clr.b/move.b replacement is 12 bytes. I'll ponder it over lunch.

/Troed

On Mon, Nov 24, 2014 at 11:44 AM, Thomas Huth <th.huth@xxxxxx> wrote:
Am Mon, 24 Nov 2014 10:41:03 +0100
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 24/11/2014 08:47, Thomas Huth a écrit :
>
> > FYI, as a quick hack, I've patched the movep instructions that occur
> > during the boot process to nops:
> >
> > static const TOS_PATCH TosPatches[] =
> > {
> > ...
> > { 0x404, -1, "060fix", TP_ALWAYS, 0xE025E2, 0x01C80000, 12,
> > pNopOpcodes }, { 0x404, -1, "060fix", TP_ALWAYS, 0xE0263C,
> > 0x01C80026, 4, pNopOpcodes }, ...
> > };
> >
> > Then the desktop is successfully reached again also in 68060 mode..
> > So it's not that much that has to be fixed in TOS.
> >
>
> hi
>
> does it mean those movep were useless ? Shouldn't they be replaced by
> 2 move.b for example ?

First region seems to pre-initialize the MFP:

$e025dc : 41f8 fa01 lea $fffffa01.w,a0
$e025e0 : 7000 moveq #0,d0
$e025e2 : 01c8 0000 movep.l d0,0(a0)
$e025e6 : 01c8 0008 movep.l d0,8(a0)
$e025ea : 01c8 0010 movep.l d0,$10(a0)
$e025ee : 117c 0048 0016 move.b #$48,$16(a0)
$e025f4 : 08e8 0002 0002 bset #2,2(a0)

The second region is setting some more values there:

$e02632 : 41f8 fa01 lea $fffffa01.w,a0
$e02636 : 203c 0088 0105 move.l #$880105,d0
$e0263c : 01c8 0026 movep.l d0,$26(a0)

So it likely works in Hatari to nop them out because the MFP is in a
sane state at the beginning, but that's certainly not a proper fix and
should be replaced with correct code for setting up the MFP instead.

Thomas