ASM: Hardware Track Loader

[zaz]

Originally Posted by StingRay

I think I remember some trainers you made back in the day. If you are the same zaz that was in Dual Crew on Amiga too that is ;D

Yep, that's me. Incidentally the super cars ii trainer was also an exercise in size optimization, but that's another story.

[StingRay]

Originally Posted by zaz

372 bytes now.

Cool! Gotta check your version in a sec! "I'm a bit rusty", yeah, right. ;P

Originally Posted by zaz

But what happens if $60000 is allocated already? Even with AllocAbs() the loader will fail if that happens...

This is a very "dirty" solution anyway which I really do not like. However, in case of using AllocAbs you could call AllocAbs in a loop until it succeeds. F.e. $40000 first, fails -> increase by say $1000 bytes -> loop

Originally Posted by zaz

After the system is killed we could copy the loader to $c0 or some low address and just assume the bootblock is not loaded there (like with the stack relocations), but then it's no longer safe to use library calls to flush the cache...

This is the same as my "copy to $60000" approach then (as I also assume that the bootblock isn't loaded there, AFAIK OS loads bootblock quite low into memory). Cleanest approach would be to call AllocMem and copy the code then (I used exactly that approach in the Bootblock intro I made for FAP) but then the stack relocation wouldn't be safe anymore which is why I didn't use it.

[zaz]

After loading an unspecified number of tracks to $8000 AllocMem() would not have helped, so might as well leave it as it is.

I had a brief idea about AllocMem()ing a big chunk for the loader, MFM buffer, and loaded program, but the loaded program itself is presumably assembled for an absolute address etc... Coming up: bootblock trackloader with amiga hunk loader & relocator? I think not

EDIT: loader is already AllocMem()ed of course but still...

[StingRay]

Originally Posted by zaz

After loading an unspecified number of tracks to $8000 AllocMem() would not have helped, so might as well leave it as it is.

That was exactly the reason why I didn't use it. Absolute addresses for the MFM buffer/stacks = good bye AllocMem.

Originally Posted by zaz

I had a brief idea about AllocMem()ing a big chunk for the loader, MFM buffer, and loaded program

That thought actually crossed my mind too. But it would only work if there are no absolute addresses used anywhere. It would be clean and safe!

[StingRay]

I checked your version and I can show you what I meant with "I wanted to keep the code readable" and thus didn't use lea dsklen,a5:

	move.w	#%0000000000000010,intreq(a5)	;clear disk interrupt bit

This is a bug, a5 is not $dff000 anymore. So it would have to be:

	move.w	#%0000000000000010,intreq-dsklen(a5)	;clear disk interrupt bit

[Asman]

@Toni, zaz - Thank you for information.

If I understand correctly. Bootblock code is allocated by AllocMem and is not necessary to think about stack pointers relocation, right ?
Mean we should use AllocMem for buffer.

I know The OS is for wimps

[zaz]

@StingRay: Check again, this is what BASEREG does and why I changed all custom reg EQU from $000 etc to $dff000 etc.

[phx]

Originally Posted by StingRay

This is the same as my "copy to $60000" approach then (as I also assume that the bootblock isn't loaded there, AFAIK OS loads bootblock quite low into memory).

Exactly. The OS always starts to allocate lowest regions first.

Cleanest approach would be to call AllocMem and copy the code then

When we take over the machine it doesn't make sense to call AllocMem. There can never be much memory allocated in this early phase when the bootblock is read, so I would simply relocate to a high region which exists on all Amigas, as you did, and we are safe.

[zaz]

Ok 360 bytes version attached.

[StingRay]

Originally Posted by zaz

@StingRay: Check again, this is what BASEREG does and why I changed all custom reg EQU from $000 etc to $dff000 etc.

I checked again and I have to say: Nice one!
Edit: I never used BASEREG, looks like a nifty feature! =)
And I missed that you changed the custom reg equates, now it does make sense to me.

Originally Posted by phx

When we take over the machine it doesn't make sense to call AllocMem. There can never be much memory allocated in this early phase when the bootblock is read, so I would simply relocate to a high region which exists on all Amigas, as you did, and we are safe.

Allocating memory works w/o any problem in the bootblock (see my Bootblock intro for a proof). Besides, the machine has not been taken over at the time I'd allocate memory so it is still the safest (=cleanest) approach as long as no absolute addresses are used anywhere.

[FrenchShark]

Hello,

FYI, I am using the trackloader code in a verilog testbench to check the correct functionning of Paula / disk emulation.
I think I spotted a bug line 403:
bne.s .time_not_expired
It should be a BEQ not a BNE since ICR bit is set when timer A transitions from 0000 to FFFF.
What do you think ?

Regards,

Frederic

[pmc]

Yes, it should. Already fixed in my own version of the trackloader a long time ago - just never said anything about it here.

[FrenchShark]

Originally Posted by pmc

Yes, it should. Already fixed in my own version of the trackloader a long time ago - just never said anything about it here.

Ok, thanks.
There is actually another one in the Disk DMA enable instruction, it should be:
move.w #%1000001000010000,(a0) ;enable disk DMA
Bit #9 has to be set too.

Regards,

Frederic

[JokerX]

Hi guys, many thanks for this interesting thread.

There's another bug when you try to read from track 1. I added something like this to line 359:

    cmp.b #1,d0
    bne .notTrack1
    bclr.b #2,(a6)
.notTrack1:

Bare with me, i'm pretty new to ASM, so there's probably a more optimized solution than mine.

[ross]

Originally Posted by JokerX

Hi guys, many thanks for this interesting thread.

There's another bug when you try to read from track 1. I added something like this to line 359:

    cmp.b $1,d0
    bne .notTrack1
    bclr.b #2,(a6)
.notTrack1:

Bare with me, i'm pretty new to ASM, so there's probably a more optimized solution than mine.

I've not checked the code at all, but

cmp.b $1,d0

sounds bad to me. Maybe you meant

cmp.b #1,d0

.

[JokerX]

Originally Posted by ross

I've not checked the code at all, but

cmp.b $1,d0

sounds bad to me. Maybe you meant

cmp.b #1,d0

.

you're right, typo on my end, as i didn't copy and paste as it was that short

thanks for pointing it out, i've corrected the code above.