ASM: Hardware Track Loader - Page 3

pmc · 22 March 2010, 12:32

Quote:

Originally Posted by StingRay

See, I knew you can do it.

Cool!

Thanks man - it means a lot for you to have faith in me.

Gotta say again though - if it weren't for your insights I couldn't have done it. So thanks.

EDIT: Still no work on CIA timer routine but newly shaved versions attached...

444 bytes, 796 bytes and 806 bytes respectively.

EDIT: Non CIA amended versions removed.

pmc · 22 March 2010, 13:47

CIA timer routine amended and a couple of other small amendments. I think all size optimising is done on these now - I can't currently see anything else.

New sizes are: 434, 786 and 796 bytes respectively.

StingRay · 22 March 2010, 13:53

Quote:

Originally Posted by pmc

I think all size optimising is done on these now

move.b #0,d5 ;set track 0 as current track
move.w #71,d7 ;head settle time

Sorry.

Edit:
move.l (a3),d0 ;MFM coded sector header to d0
move.l 4(a3),d1 ;and d1

Sorry again.

pmc · 22 March 2010, 14:33

LOL.

No worries mate.

I was thinking while I ate my lunch today that there might be another lea in there somewhere I could do without... Not sure on this, need to check.

And in the meantime you've supplied some more savings.

StingRay · 22 March 2010, 14:42

Quote:

Originally Posted by pmc

And in the meantime you've supplied some more savings.

Some (not so) subtle hints: moveq/sf; movem.l

Good job btw!

Nicely size optimized loader you have now! =)

pmc · 22 March 2010, 15:25

OK. Turned out I could remove another lea. So, that plus Sting's other size savings means there's now a 424 byte version attached.

Asman · 22 March 2010, 15:36

I have questions.
For what or why stack pointer and supervisor stack pointer are relocated ? In other words I don't understand code between comments ( ;Relocate stack pointers and ;Setup disk controls.
Is possible to remove that code ?

StingRay · 22 March 2010, 15:36

Nice!

In case you wonder why I mentioned movem.l, I would have replaced
move.l (a3),d0
move.l 4(a3),d1

with
movem.l (a3),d0/d1

as I didn't check if a3 could be trashed or not.

Also, it's better to use meaningful offsets for the CIA accesses, e.g.

move.b #%01111111,ciabicr-ciabprb(a6)
instead of
move.b #%01111111,3072(a6)

as that's pretty much unreadable.

Let the assembler calculate the offsets.

pmc · 22 March 2010, 15:40

@ Sting - you replied just while I was replying.

Regarding your extra stuff - agreed. I did intend (honest!) to change those evil offsets so, like you say, it's more readable.

I'll do that soon.

Regarding a3 - I have to add offsets to it after those moves so I wouldn't want a3 to be trashed. Would your suggested movem trash a3 then or I have misunderstood...?

@ Asman - All I'm doing is moving the stack pointers low in memory (below where the disk buffers are...) so that I know where they are and they can't accidentally get overwritten by what gets read off the disk into memory.

StingRay · 22 March 2010, 15:44

Quote:

Originally Posted by pmc

Regarding what your extra stuff - agreed. I did intend (honest!) to change those evil offsets so, like you say, it's more readable.

No problem, thought you didn't know how to do it so I mentioned it. =)
Remember: boring stuff -> let the assembler do it.
Another advantage is that you always know which CIA base register ax points to as it's used in the offset calculations (e.g. ciabicr-ciabprb(a6) -> a6 = ciabprb)

Quote:

Originally Posted by pmc

Regarding a3 - I have to add offsets to it after those moves so I wouldn't want a3 to be trashed. Would your suggested movem trash a3 then or I have misunderstood...?

My movem.l version does exactly the same as your move.l (a3),d0 move.l 4(a3),d1 approach, it's just shorter. In other words, a3 is not trashed.

pmc · 22 March 2010, 15:50

Quote:

Originally Posted by StingRay

My movem.l version does exactly the same as your move.l (a3),d0 move.l 4(a3),d1 approach, it's just shorter. In other words, a3 is not trashed.

More savings! \o/

Nice one.

Toni Wilen · 22 March 2010, 15:52

Quote:

Originally Posted by pmc

@ Asman - All I'm doing is moving the stack pointers low in memory (below where the disk buffers are...) so that I know where they are and they can't accidentally get overwritten by what gets read off the disk into memory.

Nothing prevents your bootblock code getting overwritten by your relocated stacks

StingRay · 22 March 2010, 15:54

Quote:

Originally Posted by pmc

More savings! \o/

Nice one.

I don't think so because your
move.l (a3)+,d0 ;MFM coded sector header to d0
move.l (a3),d1 ;and d1

is fine and also 4 bytes (just liked the movem version)

Quote:

Originally Posted by Toni Wilen

Nothing prevents your bootblock code getting overwritten by your relocated stacks

Yup.

pmc · 22 March 2010, 15:54

Hey Stinger - just noticed that movem.l (a3),d0/d1 is the same length as what I changed that code to, namely:

move.l (a3)+,d0
move.l (a3),d1

So, as it turns out, not another saving...

Toni - you're right - any way this *can* be prevented...?

StingRay · 22 March 2010, 15:56

Quote:

Originally Posted by pmc

Hey Stinger - just noticed that movem.l (a3),d0/d1 is the same length as what I changed that code to, namely:

move.l (a3)+,d0
move.l (a3),d1

So, as it turns out, not another saving...

I replied already. :P

Quote:

Originally Posted by pmc

Toni - how come? Stacks grow downwards don't they so how can they overwrite the stuff loaded of disk that's "above" the stacks in memory?

What Toni means is, your bootblock can be loaded anywhere in memory by the OS so you don't really know where your code is located and thus it can be trashed by your loader. Copy the complete bootblock code to some location in highmem (f.e.) and execute it then.

pmc · 22 March 2010, 16:01

Yeah, I edited my post as I'd cottoned onto what Toni meant.

Thanks guys.

Asman · 22 March 2010, 16:03

Quote:

Originally Posted by pmc

@ Asman - All I'm doing is moving the stack pointers low in memory (below where the disk buffers are...) so that I know where they are and they can't accidentally get overwritten by what gets read off the disk into memory.

Maybe easier is to use exec function AllocMem instead of relocate stack pointers.

Toni Wilen · 22 March 2010, 16:03

These kinds of low memory "relocations" are one cause for games and demos that only work if number of external drives = <some specific number that coder had>. Do not do that

pmc · 22 March 2010, 16:05

@ Asman - OS functions are for wimps!

Seriously though, worth considering - thanks.

Toni - I bow to your superior knowledge.

StingRay · 22 March 2010, 16:08

Quote:

Originally Posted by Asman

Maybe easier is to use exec function AllocMem instead of relocate stack pointers.

Not really the best idea when the system is completely killed. Besides, relocating stacks is nothing bad.
Edit: As long as the system is completely killed and you don't plan to return to the OS.

Quote:

Originally Posted by Toni Wilen

These kinds of low memory "relocations" are one cause for games and demos that only work if number of external drives = <some specific number that coder had>. Do not do that

And while we are at it, also don't forget to flush caches on CPU's >=68020 after you copied your bootblock to some safe location in memory (call Exec's CacheClearU(), only works on Kick 2.0+ though).

22 March 2010, 13:47	#42
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	CIA timer routine amended and a couple of other small amendments. I think all size optimising is done on these now - I can't currently see anything else. New sizes are: 434, 786 and 796 bytes respectively. Last edited by pmc; 22 March 2010 at 15:24.

22 March 2010, 15:25	#46
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	OK. Turned out I could remove another lea. So, that plus Sting's other size savings means there's now a 424 byte version attached. Last edited by pmc; 22 March 2010 at 17:35.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
HD loader example	st!	Coders. General	4	16 October 2012 21:56
Game loader stuck on certain track after save state restore	andreas	support.WinUAE	2	26 March 2011 19:59
Can't transfer Supaplex cause of CSL track loader !	Vollldo	support.Games	4	12 March 2011 21:51
Hardware File Loader	h0ffman	Coders. General	9	02 December 2010 16:40
mfm/custom regs/track loader	snyp	Coders. General	9	06 June 2006 19:42

22 March 2010, 14:33	#44
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	LOL. No worries mate. I was thinking while I ate my lunch today that there might be another lea in there somewhere I could do without... Not sure on this, need to check. And in the meantime you've supplied some more savings.

22 March 2010, 15:36	#47
Asman 68k Join Date: Sep 2005 Location: Somewhere Posts: 828	I have questions. For what or why stack pointer and supervisor stack pointer are relocated ? In other words I don't understand code between comments ( ;Relocate stack pointers and ;Setup disk controls. Is possible to remove that code ?

22 March 2010, 15:36	#48
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	Nice! In case you wonder why I mentioned movem.l, I would have replaced move.l (a3),d0 move.l 4(a3),d1 with movem.l (a3),d0/d1 as I didn't check if a3 could be trashed or not. Also, it's better to use meaningful offsets for the CIA accesses, e.g. move.b #%01111111,ciabicr-ciabprb(a6) instead of move.b #%01111111,3072(a6) as that's pretty much unreadable. Let the assembler calculate the offsets.

22 March 2010, 15:40	#49
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	@ Sting - you replied just while I was replying. Regarding your extra stuff - agreed. I did intend (honest!) to change those evil offsets so, like you say, it's more readable. I'll do that soon. Regarding a3 - I have to add offsets to it after those moves so I wouldn't want a3 to be trashed. Would your suggested movem trash a3 then or I have misunderstood...? @ Asman - All I'm doing is moving the stack pointers low in memory (below where the disk buffers are...) so that I know where they are and they can't accidentally get overwritten by what gets read off the disk into memory.

22 March 2010, 15:54	#54
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	Hey Stinger - just noticed that movem.l (a3),d0/d1 is the same length as what I changed that code to, namely: move.l (a3)+,d0 move.l (a3),d1 So, as it turns out, not another saving... Toni - you're right - any way this can be prevented...?

22 March 2010, 16:01	#56
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	Yeah, I edited my post as I'd cottoned onto what Toni meant. Thanks guys.

22 March 2010, 16:03	#58
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	These kinds of low memory "relocations" are one cause for games and demos that only work if number of external drives = <some specific number that coder had>. Do not do that

22 March 2010, 16:05	#59
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	@ Asman - OS functions are for wimps! Seriously though, worth considering - thanks. Toni - I bow to your superior knowledge.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)