ASM: Hardware Track Loader

[pmc]

Originally Posted by musashi5150

Yes, as Dr Sting says it can be done with room to spare

Cool - I'll keep squeezing it down till I get there.

Originally Posted by musashi5150

packed all datas on the disk with my own cruncher.

Heavy skills.

Got any good advice for things to read for learning how to write my own cruncher...? Always nice to learn new things.

[musashi5150]

Originally Posted by pmc

Got any good advice for things to read for learning how to write my own cruncher...? Always nice to learn new things.

Unless you have uber skills to come up with something good yourself (not in my case ), it's a case of finding an algorithm you like from a paper or book and modding it so it works for you. I usually get it all working in C first and then just port and optimise the decrunching code to 68K The optimising part is the fun bit - I found I keep coming back to it and spend time shaving off a couple of bytes... or making it a whisker faster each time

[pmc]

Nice one.

Looks like another project added to my list will be my own crunch / decrunch routines at some point then.

In the meantime though I think I'll try to make my bb trackloader as small as possible and use something already available for crunching. Load and decrunch is what I need if I want to start thinking about making my own multipart demos.

[pmc]

Shortened version attached.

Now down to a bit more respectable 532 bytes.

Originally Posted by StingRay

Another (maybe not so obvious) optimizing tip is: bsr followed by rts -> bra =)

I didn't quite get what you meant by this Sting - is this something I could use to make the trackloader even shorter...?

[musashi5150]

Originally Posted by pmc

I didn't quite get what you meant by this Sting - is this something I could use to make the trackloader even shorter...?

He means if you replace (for example)...

.at_trk_0:         bsr.s .lower_head
                   move.b #0,d5 ;set track 0 as current track
                   bsr.s .dir_change
                   bsr.s .seek_inwards
                   rts

with

.at_trk_0:         bsr.s .lower_head
                   move.b #0,d5 ;set track 0 as current track
                   bsr.s .dir_change
                   bra.s .seek_inwards

it does the same job and saves some bytes by using the 'rts' in the .seek_inwards routine to jump 2 steps back if you like Do this in a few other places in your code and that's quite a saving

[pmc]

@ musashi5150 - ah, of course, thanks mate. I'll have a look through the code again.

Meantime, in case it's of any use, attached is the previous version only this time there's the StoneCracker optimised decrunch routine included. With this it totals 884 bytes so it still fits nicely onto a bootblock and can be used to trackload StoneCracker crunched binaries straight off disk.

[pmc]

Thanks to Sting and musashi5150, the trackloader, including the bootblock header stuff, is now 486 bytes.

Also attached is the shorter decrunch version too which is now 838 bytes.

Thanks guys, your advice has been really appreciated.

EDIT: Found some more savings - trackloaders are now smaller still as per new byte values.

EDIT 2: Found some more savings - trackloaders smaller again, as per new byte values.

EDIT 3: Added a version that does some nice old skool $dff180 colours on decrunch - adds 10 bytes to the code, but come on - it's for decrunch colours! \o/

EDIT 4: Found yet another saving - new byte sizes as per above.

Source code removed - newer smaller version posted further down this thread...

[StingRay]

Originally Posted by pmc

Thanks to Sting and musashi5150, the trackloader, including the bootblock header stuff, is now 486 bytes.

EDIT 4: Found yet another saving - new byte sizes as per above.

Nice =) Just for fun I had a look at the code and my version is 464 bytes.

[pmc]

ROFL!

I knew you'd win!

To be fair, without your and musashi5150's advice I wouldn't have got it down to 486 bytes anyway so even if I had made mine shorter it still would've been a joint victory!

Regardless, I really enjoyed minimising it and learned loads. Making code more compact is almost as fun as making code in the first place!

[StingRay]

Originally Posted by pmc

Making code more compact is almost as fun as making code in the first place!

Agreed. You can learn a lot when you size optimize code. Btw, my version is now 450 bytes. (but I have to stop now as I have to work ;D)

[pmc]

Originally Posted by StingRay

Btw, my version is now 450 bytes.

Now you're just rubbing salt in the wound!

Mind you, I should expect any man who can fit the whole Lotus Espirit Turbo game into 96k to have made a trackloader of 450 bytes or less.

Once you finish your uber shrinking of that ultra small trackloader I wouldn't mind having a peek at the source code if you wouldn't mind...? - it'll help me learn even more ways from the master about how to save bytes in code.

[Asman]

There are few obvious SIZE optimizing ( after StingRay correction. Thanks ) in your code, like changing some move.x to moveq. I'm sure you will find it.

Cheers

[StingRay]

Originally Posted by pmc

Once you finish your uber shrinking of that ultra small trackloader I wouldn't mind having a peek at the source code if you wouldn't mind...? - it'll help me learn even more ways from the master about how to save bytes in code.

Edit: just in case you misunderstood, I optimized your code, not mine.

I can do but I'm sure you can find ways to kill some bytes yourself, it's more fun that way. =)
Some hints:
- add.l -> add.w
- lea $xxxx.l -> lea $xxxx.w
- move.l ax,$xx.l -> move.l ax,$xx.w
- "chain" your routines, e.g.
move.w #val,d7
bra.w .wait_timer
; some other code
move.w #val,d7
bra.w .wait_timer
; some other code
move.w #val,d7
bra.w .wait_timer


can be changed to:
move.w #val,d7
bra.b .w_timer
; some other code
move.w #val,d7
bra.b .w_timer
; some other code
move.w #val,d7
.w_timer
bra.w .wait_timer

- check the wait_timer routine (absolute cia addresses used there), just noticed that so it would be <450 bytes if I would have time to "fix" that

etc

Originally Posted by Asman

There are few obvious speed ups in your code, like changing some move.x to moveq. I'm sure you will find it.

Even though this is correct this is about SIZE optimizing, not speed optimizing. And usually, the shorter the code, the slower it is.

[pmc]

Originally Posted by StingRay

I can do but I'm sure you can find ways to kill some bytes yourself, it's more fun that way. =)

You know what, you're right.

Since my last post I shaved off another 2 bytes and now, with your extra advice, I'm sure I can shave off some more on my own.

@ Asman - thanks for checking my code fella.

What Sting said though - never mind speed, I just want to make the shortest possible trackloader that I can make. \o/

[pmc]

Originally Posted by StingRay

Edit: just in case you misunderstood, I optimized your code, not mine.

You're right - I had misunderstood. I didn't realise you'd shaved *my code* down to under 450!

I'll try to shave it myself!

If I can shave it down like you did do you think it might be the world record shortest Amiga trackloader...?

What I mean is - surely there must come a point where any routine just *can't* become any smaller...?

[StingRay]

Originally Posted by pmc

If I can shave it down like you did do you think it might be the world record shortest Amiga trackloader...?

What I mean is - surely there must come a point where any routine just *can't* become any smaller...?

Of course there'll be a point where you can't optimize anymore, then it's just a matter to decide if you want to do some "hardcore" optimizing or not, e.g. in this case: it's a bootblock trackloader -> no need to step to track 0 (OS did that already). But then it wouldn't be a "normal" trackloader anymore which is of course a disadvantage. Decisions, decisions.

[pmc]

Originally Posted by StingRay

Of course there'll be a point where you can't optimize anymore, then it's just a matter to decide if you want to do some "hardcore" optimizing or not, e.g. in this case: it's a bootblock trackloader -> no need to step to track 0 (OS did that already). But then it wouldn't be a "normal" trackloader anymore which is of course a disadvantage. Decisions, decisions.

Hmmmm... I like the sound of doing hardcore optimising but I'm not sure if I want to remove the seek track 0 stuff cos I'd like to also be able to use this trackloader in a non-bootblock situation... As you know, my reason for coding a trackloder wasn't initially to do a bootblock one - I need a trackloader for other (top secret project ) reasons.

By the way - trackloader now currently standing at 470 bytes and counting.

[StingRay]

Originally Posted by pmc

Hmmmm... I like the sound of doing hardcore optimising

It's a lot of fun. If you really like the sound of doing hardcore optimizing try to code a bootblock intro.

Originally Posted by pmc

but I'm not sure if I want to remove the seek track 0 stuff cos I'd like to also be able to use this trackloader in a non-bootblock situation... As you know, my reason for coding a trackloder wasn't initially to do a bootblock one - I need a trackloader for other (top secret project ) reasons.

I know. It was just an example, a bootblock trackloader is a special case of a trackloader and thus it's possible to cut some corners. But except for some "code the shortest trackloader that fits on a bootblock" compo I wouldn't do such optimizations.

Originally Posted by pmc

By the way - trackloader now currently standing at 470 bytes and counting.

20+ bytes to go.

[pmc]

Trackloader now 444 bytes.

Still not done any work on the CIA timer routine absolutes as yet...

[StingRay]

Originally Posted by pmc

Trackloader now 444 bytes.

Still not done any work on the CIA timer routine absolutes as yet...

See, I knew you can do it. Cool!