ASM: Hardware Track Loader - Page 7

pmc · 23 March 2010, 15:10

Quote:

Originally Posted by StingRay

I have attached a new version for you Asm1 haters.

That's another thing about this little project for me - I have a new found love for Asm-One.

WB, RB, WS, WT and CC are *invaluable* tools.

StingRay · 23 March 2010, 15:17

Quote:

Originally Posted by pmc

That's another thing about this little project for me - I have a new found love for Asm-One.

WB, RB, WS, WT and CC are *invaluable* tools.

Yep, no doubt about that.

It's exactly these little but very useful features that make ASM-One the best choice for me as they save you a lot of time.

pmc · 23 March 2010, 15:25

Starting to stray a bit off topic this but a quick couple of questions about ASM-One:

I've been using v1.48

This version crashes as soon as it's run on 68000 ECS emulated Amiga - I have to use it on a > 68020 RTG emulated Amiga for it to work. Anything I can do about this...?

Also, this version seems to hang when I do CC. It calculates the bootblock checksum OK but just sits there and never dumps me back to a command line prompt. Is this a bug in this verson...?

Bearing in mind the above issues, any better version of ASM-One to use...?

StingRay · 23 March 2010, 15:31

Quote:

Originally Posted by pmc

Starting to stray a bit off topic this but a quick couple of questions about ASM-One:

I've been using v1.48

This version crashes as soon as it's run on 68000 ECS emulated Amiga - I have to use it on a > 68020 RTG emulated Amiga for it to work. Anything I can do about this...?

When I last used used Asm1 on a 68000 machine its version number was 1.06.

Only "tip" I have is to use an older version.

Quote:

Originally Posted by pmc

Also, this version seems to hang when I do CC. It calculates the bootblock checksum OK but just sits there and never dumps me back to a command line prompt. Is this a bug in this verson...?

Most probably a bug, yeah. Workaround: calculate the bootblock checksum yourself. :P

Quote:

Originally Posted by pmc

Bearing in mind the above issues, any better version of ASM-One to use...?

I am actually using Asm-Pro v1.16d and probably won't ever change as I know all of its bugs (and how to workaround them).

pmc · 23 March 2010, 15:34

OK cool.

Quote:

Originally Posted by StingRay

Most probably a bug, yeah. Workaround: calculate the bootblock checksum yourself. :P

LOL. True. I *think* I can remember the equation for that...

StingRay · 23 March 2010, 15:36

Quote:

Originally Posted by pmc

LOL. True. I *think* I can remember the equation for that...

If you can't, here's some code:

Code:

; calc bootblock checksum
    lea    DISK,a0
    lea    4(a0),a1
    clr.l    (a1)
    move.w    #1024/4-1,d7
    moveq    #0,d0
    moveq    #0,d1
.calc    add.l    (a0)+,d0
    addx.l    d1,d0
    dbf    d7,.calc
    not.l    d0
    move.l    d0,(a1)

phx · 23 March 2010, 15:42

BTW, did somebody try the trackloader yet?
I'm not sure if it really can find the correct track (the hardcoded track 2 in the source will work though). When looking at the stepping routine:

Code:

.move_to_trk:   btst.l  #0,d4
        bne.s   .odd_track 
        bsr.s   .lower_head
        bra.s   .do_move
.odd_track:     subq.b  #1,d4
        bsr.s   .upper_head
        cmp.b   d4,d5
        beq.s   .correct_trk 
.do_move:       addq.b  #1,d5
        cmp.b   d5,d4
        beq.s   .read_trk  
        bsr.s   .step_heads
        bra.s   .do_move
.correct_trk:   addq.b  #1,d4

...I noticed the addq.b #1,d5 in the .do_move loop, which may be wrong. d4 is the destination track and d5 is the current track. But when doing a step, you will step a cylinder, which means *two* tracks.

I have rewritten that part to fix it and save another six bytes

Code:

.move_to_trk:
        move.w  d4,d0
        sub.w   d5,d0
        lsr.w   #1,d0
        bcs.s   .odd_track 
        bsr.s   .lower_head
        bra.s   .do_move
.odd_track:
        bsr.s   .upper_head
        bra.s   .do_move
.seek_loop:
        bsr.s   .step_heads
        addq.w  #2,d5
.do_move:
        dbra    d0,.seek_loop

pmc · 23 March 2010, 15:47

It doesn't step a cylinder phx.

If track is even and d5 != d4 it steps a cylinder and selects lower head. If track is odd and d5 != d4, it steps to one track less (ie. to the even track) and selects the upper head.

Well, that's how it's supposed to work.

And it does seems to work - I have successfully tested and been loading things with each version of the trackloader I've posted before posting.

You have got me thinking though - I'll do more testing.

PS - six byte saving is nice.

phx · 23 March 2010, 15:54

Quote:

Originally Posted by pmc

It doesn't step a cylinder phx.

If track is even an d5 != d4 it steps a cylinder and selects lower head. If track is odd and d5 != d4, it only swaps heads.

So far I understood.

Quote:

Well, that's how it's supposed to work.

And it does seems to work - I have successfully tested and been loading things with each version of the trackloader I've posted before posting.

Hmm... then I'm too stupid. The .do_move loop checks if d5 has reached d4, but d5 will be incremented by just 1 for every step...?

pmc · 23 March 2010, 15:59

Quote:

Originally Posted by phx

Hmm... then I'm too stupid.

Now, I *know* that's not true.

Your doubts is why you've now got me thinking.

It's supposed to read from the start track sequentially like this:

move to start track, modifying for odd if necessary by track minus one and select upper head.

Read one track at a time (only plus one to current required track number in d5)

Each time performing the is it odd / is it even check and either stepping the heads and selecting the lower head (for even tracks) or only swapping to the upper head as necessary (for odd tracks).

phx · 23 March 2010, 16:04

Quote:

Originally Posted by pmc

Read one track at a time (only plus one to current required track number in d5)

Each time performing the is it odd / is it even check and either stepping the heads and selecting the lower head (for even tracks) or only swapping to the upper head as necessary (for odd tracks).

Ok... I guess this will work once you have found your start track and just step to the next.

But what happens when your start track is track 20 instead of track 2? It has to step ten times in your loop and IMHO you will step nearly 20 times (maybe 19?) instead.

pmc · 23 March 2010, 20:21

@ phx - you have a point, up to a point.

I went away and did some testing.

If the start track is *any* even track, it works fine.

But, if the start track == an odd numbered track, the trackloader fails.

I think I can see the reason for this in the debugger so I should be able to implement a fix.

zaz · 24 March 2010, 08:31

Can I join this intellectual game? I was once quite interested in making 68k programs short and I enjoyed reading the discussion up to now.

This is so obvious that I think I must have missed something:

Code:

        move.w  sr,d0
        andi.w  #%1101111111111111,d0   ;restore user mode
        move.w  d0,sr

But there's an instruction for this !?

Code:

        andi.w  #%1101111111111111,sr   ;restore user mode

But I guess the question is, why go back to user mode at all?

Next, I wonder if it's worth 6 bytes to preserve the SPMODE bit of CIA B? I think it's in fact not used:

Code:

.wait_timer:    andi.b  #%11000000,ciabcra-ciabprb(a6)
        ori.b   #%00001000,ciabcra-ciabprb(a6)

->

Code:

        move.b   #%00001000,ciabcra-ciabprb(a6)

Then I think there's a bootblock-specific one, not 100% sure about this one, but you're not going to put AmigaDOS files on this floppy anyway:

Code:

start:  dc.b    "DOS",0         ;DOS disk identifier
        dc.l    0               ;room for bootblock chksum
        dc.l    0               ;room for rootblock pointer
        ...
        move.l  #$7fff7fff,d0

->

Code:

start:  dc.b    "DOS",0         ;DOS disk identifier
        dc.l    0               ;room for bootblock chksum
rootblkp:
        dc.l    $7fff7fff
        ...
        move.l  rootblkp(pc),d0

And another one that might be worth trying:

Code:

        move.l  d0,intena(a5)
        move.w  d0,dmacon(a5)
        ...
        move.b  #%01111111,ciabicr-ciabprb(a6)

->

Code:

        move.l  d0,intena(a5)
        move.w  d0,dmacon(a5)
        move.w  d0,ciabicr-ciabprb(a6)
        ...

Let me know if I was right about these, I'm a bit rusty

StingRay · 24 March 2010, 09:33

Quote:

Originally Posted by zaz

Can I join this intellectual game? I was once quite interested in making 68k programs short and I enjoyed reading the discussion up to now.

Nowadays you seem to be more interested in 6510 coding though.

Greetings to B ;D

Quote:

Originally Posted by zaz

This is so obvious that I think I must have missed something:

Code:

        move.w  sr,d0
        andi.w  #%1101111111111111,d0   ;restore user mode
        move.w  d0,sr

But there's an instruction for this !?

Code:

        andi.w  #%1101111111111111,sr   ;restore user mode

But I guess the question is, why go back to user mode at all?

That's indeed quite an obvious one and tbh, I totally overlooked that one.

Quote:

Originally Posted by zaz

Next, I wonder if it's worth 6 bytes to preserve the SPMODE bit of CIA B? I think it's in fact not used:

Code:

.wait_timer:    andi.b  #%11000000,ciabcra-ciabprb(a6)
        ori.b   #%00001000,ciabcra-ciabprb(a6)

->

Code:

        move.b   #%00001000,ciabcra-ciabprb(a6)

6 bytes saved I guess.

Quote:

Originally Posted by zaz

Then I think there's a bootblock-specific one, not 100% sure about this one, but you're not going to put AmigaDOS files on this floppy anyway:

Code:

start:  dc.b    "DOS",0         ;DOS disk identifier
        dc.l    0               ;room for bootblock chksum
rootblkp:
        dc.l    $7fff7fff
        ...
        move.l  rootblkp(pc),d0

Yes, this will work and save 2 bytes but it is, as you said, bootblock specific. And if we are going to apply "bootblock optimizations" we can as well remove the step to track zero, switch directions and check if drive is ready routines.

Quote:

Originally Posted by zaz

And another one that might be worth trying:

Code:

        move.l  d0,intena(a5)
        move.w  d0,dmacon(a5)
        ...
        move.b  #%01111111,ciabicr-ciabprb(a6)

->

Code:

        move.l  d0,intena(a5)
        move.w  d0,dmacon(a5)
        move.w  d0,ciabicr-ciabprb(a6)
        ...

I might be missing something but I don't think move.w is the same as move.b

and since d0.b = $ff move.b won't work either.

Asman · 24 March 2010, 09:48

According to phx idea with two bset maybe we can do the same things with two bclr. Mean

Code:

	bclr.b	#7,(a6)		;dskmotor low
	bclr.b	#3,(a6)		;select df0: with dskmotor low to start motor

---->

Code:

 andi.b #01110111,(a6)

pmc · 24 March 2010, 10:46

Hey zaz, nice to see you here.

Quote:

Originally Posted by zaz

Code:

andi.w  #%1101111111111111,sr   ;restore user mode

Sting / zaz - I didn't think andi sr was allowed...?

Manipulating the sr is privileged - I thought only a move to or from sr was allowed - hence move, and, move rather than just and.

At least I thought I read that somewhere, maybe I was wrong and anding the sr is OK...?

EDIT - my mistake - andi sr looks to be OK.

Toni Wilen · 24 March 2010, 10:59

Quote:

Originally Posted by Asman

According to phx idea with two bset maybe we can do the same things with two bclr. Mean

Code:

	bclr.b	#7,(a6)		;dskmotor low
	bclr.b	#3,(a6)		;select df0: with dskmotor low to start motor

---->

Code:

 andi.b #01110111,(a6)

Do not do this. Motor state must be set before activating select. (select is latch signal for motor flipflop, changing both will not work with all hardware implementations)

Toni Wilen · 24 March 2010, 11:09

Quote:

Originally Posted by zaz

And another one that might be worth trying:

Code:

        move.l  d0,intena(a5)
        move.w  d0,dmacon(a5)
        ...
        move.b  #%01111111,ciabicr-ciabprb(a6)

->

Code:

        move.l  d0,intena(a5)
        move.w  d0,dmacon(a5)
        move.w  d0,ciabicr-ciabprb(a6)
        ...

Urgh

Technically it will work but I don't think it will work with all models. (like some 68060 accelerators) Please, don't do this

Quote:

Originally Posted by StingRay

I might be missing something but I don't think move.w is the same as move.b

and since d0.b = $ff move.b won't work either.

High byte (0x7f) goes to ciabicr, low byte (0xff) goes nowhere.

StingRay · 24 March 2010, 11:18

Quote:

Originally Posted by Toni Wilen

High byte (0x7f) goes to ciabicr, low byte (0xff) goes nowhere.

I know but exactly this "goes nowhere" is what I didn't like (what's ciabicr+1?). Also, AFAIK CIA regs should only be written .b, not .w.

Quote:

Originally Posted by StingRay

but I don't think move.w is the same as move.b

Asman · 24 March 2010, 11:29

Quote:

Originally Posted by Toni Wilen

Do not do this. Motor state must be set before activating select. (select is latch signal for motor flipflop, changing both will not work with all hardware implementations)

Thank you for info. As I said yesterday. Life is hard to save some bytes

.

23 March 2010, 15:42	#127
phx Natteravn Join Date: Nov 2009 Location: Herford / Germany Posts: 2,551	BTW, did somebody try the trackloader yet? I'm not sure if it really can find the correct track (the hardcoded track 2 in the source will work though). When looking at the stepping routine: Code: .move_to_trk: btst.l #0,d4 bne.s .odd_track bsr.s .lower_head bra.s .do_move .odd_track: subq.b #1,d4 bsr.s .upper_head cmp.b d4,d5 beq.s .correct_trk .do_move: addq.b #1,d5 cmp.b d5,d4 beq.s .read_trk bsr.s .step_heads bra.s .do_move .correct_trk: addq.b #1,d4 ...I noticed the addq.b #1,d5 in the .do_move loop, which may be wrong. d4 is the destination track and d5 is the current track. But when doing a step, you will step a cylinder, which means two tracks. I have rewritten that part to fix it and save another six bytes Code: .move_to_trk: move.w d4,d0 sub.w d5,d0 lsr.w #1,d0 bcs.s .odd_track bsr.s .lower_head bra.s .do_move .odd_track: bsr.s .upper_head bra.s .do_move .seek_loop: bsr.s .step_heads addq.w #2,d5 .do_move: dbra d0,.seek_loop

23 March 2010, 15:47	#128
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	It doesn't step a cylinder phx. If track is even and d5 != d4 it steps a cylinder and selects lower head. If track is odd and d5 != d4, it steps to one track less (ie. to the even track) and selects the upper head. Well, that's how it's supposed to work. And it does seems to work - I have successfully tested and been loading things with each version of the trackloader I've posted before posting. You have got me thinking though - I'll do more testing. PS - six byte saving is nice. Last edited by pmc; 23 March 2010 at 15:54.

23 March 2010, 20:21	#132
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	@ phx - you have a point, up to a point. I went away and did some testing. If the start track is any even track, it works fine. But, if the start track == an odd numbered track, the trackloader fails. I think I can see the reason for this in the debugger so I should be able to implement a fix. Last edited by pmc; 24 March 2010 at 08:21. Reason: Removed the inaccurate stuff I posted when I'd been looking at code so long I'd gone cross eyed :-D

24 March 2010, 08:31	#133
zaz Registered User Join Date: Mar 2010 Location: Lkpg/Swe Posts: 12	Can I join this intellectual game? I was once quite interested in making 68k programs short and I enjoyed reading the discussion up to now. This is so obvious that I think I must have missed something: Code: move.w sr,d0 andi.w #%1101111111111111,d0 ;restore user mode move.w d0,sr But there's an instruction for this !? Code: andi.w #%1101111111111111,sr ;restore user mode But I guess the question is, why go back to user mode at all? Next, I wonder if it's worth 6 bytes to preserve the SPMODE bit of CIA B? I think it's in fact not used: Code: .wait_timer: andi.b #%11000000,ciabcra-ciabprb(a6) ori.b #%00001000,ciabcra-ciabprb(a6) -> Code: move.b #%00001000,ciabcra-ciabprb(a6) Then I think there's a bootblock-specific one, not 100% sure about this one, but you're not going to put AmigaDOS files on this floppy anyway: Code: start: dc.b "DOS",0 ;DOS disk identifier dc.l 0 ;room for bootblock chksum dc.l 0 ;room for rootblock pointer ... move.l #$7fff7fff,d0 -> Code: start: dc.b "DOS",0 ;DOS disk identifier dc.l 0 ;room for bootblock chksum rootblkp: dc.l $7fff7fff ... move.l rootblkp(pc),d0 And another one that might be worth trying: Code: move.l d0,intena(a5) move.w d0,dmacon(a5) ... move.b #%01111111,ciabicr-ciabprb(a6) -> Code: move.l d0,intena(a5) move.w d0,dmacon(a5) move.w d0,ciabicr-ciabprb(a6) ... Let me know if I was right about these, I'm a bit rusty

24 March 2010, 09:48	#135
Asman 68k Join Date: Sep 2005 Location: Somewhere Posts: 829	According to phx idea with two bset maybe we can do the same things with two bclr. Mean Code: bclr.b #7,(a6) ;dskmotor low bclr.b #3,(a6) ;select df0: with dskmotor low to start motor ----> Code: andi.b #01110111,(a6)

23 March 2010, 15:25	#123
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	Starting to stray a bit off topic this but a quick couple of questions about ASM-One: I've been using v1.48 This version crashes as soon as it's run on 68000 ECS emulated Amiga - I have to use it on a > 68020 RTG emulated Amiga for it to work. Anything I can do about this...? Also, this version seems to hang when I do CC. It calculates the bootblock checksum OK but just sits there and never dumps me back to a command line prompt. Is this a bug in this verson...? Bearing in mind the above issues, any better version of ASM-One to use...?

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

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