I have only a small space for him, maximum 430 Bytes
If you have other version that work better and don't exceeds 430 byte, I want it
(I have also other version of AlphaOne trackloader but who are bigger)

Hmmm I can't reproduce this bug here on Standard A1200, my tloader version is from 2005 but the code is nearly 100% identical.https://www72.zippyshare.com/v/gGq0E5HE/file.html
Get the same error with this?
I tried also with $17 in d0 and mulu, no problems.

First thing you should do is adding a range check in the MFM decoding loop. That way you can easily see if the loaded data is OK or not. My guess is that the MFM buffer gets trashed for one reason or another.

Also, if you really need very small code you shouldn't add instructions which are much longer than the original ones (move.l #0,d2 *cough*).

What are you doing that you don't even have space for a simple move.l #xxxx,dx instruction?

I understand what you are saying but, the question is :
Why I don't have this 'crash/don't woking issue' when I don't use mulu...

As you say it's simple math: $58e44+$1fa00>$76ebc
With or without mulu it should not be working !

This is not the case.
Without mulu, it's working !

It's random.
You have an MFM buffer of $1900*2 bytes from $76ebc, so up to $7a0bc, that is partly after the file buffer.
It depends on where the floppy head start to read on physical track if you crash or not.
Different code and timing make subtle differences.
(you've no idea, when you have to patch old code.. a few cycles differences make a production works no more)

I understand what you are saying but, the question is :
Why I don't have this 'crash/don't woking issue' when I don't use mulu...

As you say it's simple math: $58e44+$1fa00>$76ebc
With or without mulu it should not be working !

This is not the case.
Without mulu, it's working !

Earlier in the thread, you point out that when you don't use a mulu, you put a different (lower) number into D0 ($1e460 rather than $1fa00). This means much less of the buffer gets overwritten.

IMHO this explains everything: the MFM buffer contains the $4489 sync word(s) somewhere. Apparently, in this particular case the sync word(s) happen to only exist near the start of the buffer. As such, overwriting a larger part of the buffer can cause this problem by removing the sync words.

Edit: a bit late here it seems

--
However, I'd say it's not actually all that relevant why this buffer overwriting sometimes does and sometimes does not cause problems. The relevant problem here is that the buffer is overwritten to begin with.

@Giants: why don't you write you own trackloader? It's a good exercise and so you can understand the inner working.
And it's fun too

Hi Ross I completely agree here! Writing an own loader is indeed a good exercise and helps to avoid mistakes such as using a wrong location for the MFM buffer or it makes one adding certain checks to detect such problems easily. Another advantage is that own code can easily be tailor-made for special situations. And yes, it's fun too.