ASM: Hardware Track Loader

[Toni Wilen]

Originally Posted by StingRay

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.

Yes, I know. I did say it "technically works"

EDITQUOTE:

what's ciabicr+1?

CIA-A (CIA-B 8-bit data lines are connected to CPU data line bits 8-15, CIA-A = data line bits 0-7) but nothing happens because CIA-A chip select is inactive. (not so simple on 68020+ Amigas but basically same) Still, don't do that

[pmc]

Hello boys.

Please see the attached *fixed* trackloader.

This one works correctly no matter what start track is used - any valid track number, even *or* odd will work OK.

The length increased slightly but is still a nice and small 408 bytes.

All other shorter versions in this thread will work only if the start track is an even number so please use this one if you want one that works from any start track.

Thanks to phx for putting a foot in my arse and making me test my code properly!

EDIT: Code removed - get the fixed fixed version below.

[phx]

Hmm... I'm sorry to annoy you again, but the seek-code still looks suspicious to me.

.move_to_start:	btst.l	#0,d4
	bne.s	.odd_track
	bsr.s	.lower_head
	bra.s	.step_to_start
.odd_track:	bsr.s	.upper_head
	subq.b	#1,d4
.step_to_start:	addq.b	#1,d5
	cmp.b	d5,d4
	beq.s	.at_start
	bsr.s	.step_heads
	bra.s	.step_to_start

Now you successfully made it work with track 3. But IMHO track 1 would fail.
Example:
d5 = 0 (current track)
d4 = 1 (start track to seek)
Your function calls .upper_head and then decrements d4, which becomes 0.
Then you increment d5 and compare it with d4 to see if the destination is reached. It will fail (for the next 255 steps )!

Unless I'm completely confused (which might be possible) I think that this part of the trackloader will never work, because you still increment the current-track counter d5 by just *one* when you make a step to the next cylinder (which equals *two* tracks).

[zaz]

Originally Posted by StingRay

Nowadays you seem to be more interested in 6510 coding though. Greetings to B ;D

6510 is nice but recently I'm also interested in 68000 Will forward to B!

Originally Posted by StingRay

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.

Well this is all an educational exercise anyway, right? For practical applications I'd use trackdisk.device in the bootblock to load the first track and use a hard loader from there. IIRC the first track is already buffered in trackdisk.device.

The bootblock checksum etc was included in the size measurement, so I included that optimization, while pmc said the load routine should be possible to use standalone so I didn't remove that stuff.

[pmc]

@ phx - you're right about the track 1 thing - I forgot to include my little check for that - I'll sort it at some point - thanks for pointing it out.

Regarding d5 - although it's called "current track" in the code, I regard it as more of a "current cylinder" counter - for example, to get to track two *or* three from the start point of cylinder 0, the code steps the heads just once. Hence d5 == 1 when track == 2 or 3.

Originally Posted by phx

Hmm... I'm sorry to annoy you again

It never annoys me if people to look at my code and ask questions or point out mistakes. It helps me look at things from different perspectives and, in the case of a mistake (something I make a lot of! ), learn something in the process.

So, I say - keep annoying me!

Edit: fixed fixed version (412 bytes), works for track 1 starts - thanks again to phx for giving me another kick.

[zaz]

This could work, yes?

.move_to_start:
    lsr.b #1,d4
    bcc.s    .step_to_start
    bsr.s    .upper_head
.step_to_start:    
    cmp.b    d5,d4
    beq.s    .at_start
    bsr.s    .step_heads
    addq.b  #1,d5
    bra.s    .step_to_start

and something for the trackloader loop:

.trackloader:
    bsr.s    .read_trk
    bchg    #2,(a6)
    bne.s   .do_next
    bsr.s    .step_heads
.do_next:    
    dbra    d3,.trackloader

Also now .upper_head and .lower_head are only called once each so you can save more by removing the subroutine calls.

[phx]

Originally Posted by pmc

Regarding d5 - although it's called "current track" in the code, I regard it as more of a "current cylinder" counter - for example, to get to track two *or* three from the start point of cylinder 0, the code steps the heads just once. Hence d5 == 1 when track == 2 or 3.

Ok. But then d4 must be the start-cylinder and not the start-track. Otherwise you cannot compare the two.

So, I say - keep annoying me!

Will do!

[phx]

Originally Posted by zaz

This could work, yes?

Yes. Looks much better to me, and is very similar to the "lsr-bcc" approach which I posted yesterday. It's even shorter (and I still had a bug in it)!

[pmc]

Hey zaz - I thought you said you were out of practice!

[zaz]

I hope you assembled & tested my suggestions before saying that -- I didn't

[pmc]

Funny you should say that zaz - I just amended, assembled and tested the source including your code in place of mine and it works like an absolute charm and is also now only 380 bytes!

Legendary work fella.

I love seeing how really good coders think about and solve things in contrast to my decidedly amateur efforts.

A richly deserved credit to you is now in the source too.

[phx]

Very nice!

But something is missing. Although both stack pointers were relocated you didn't care to relocate the trackloader itself to a safe location. As you don't know where the OS had written the boot block there is always the danger that you overwrite it while reading from disk.

This will bring you near to 400 bytes again. But you can delete the Forbid() call, because the interrupts are disabled anyway.

[pmc]

Originally Posted by phx

But something is missing. Although both stack pointers were relocated you didn't care to relocate the trackloader itself to a safe location. As you don't know where the OS had written the boot block there is always the danger that you overwrite it while reading from disk.

This will bring you near to 400 bytes again. But you can delete the Forbid() call, because the interrupts are disabled anyway.

Yeah, this is as Toni mentioned previously in this thread. That and some cache flushing after relocating the code, as per some additional advice from StingRay, now needs to be added to make the code more safe and friendly.

[StingRay]

Originally Posted by zaz

6510 is nice but recently I'm also interested in 68000 Will forward to B!

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

Originally Posted by zaz

Well this is all an educational exercise anyway, right? For practical applications I'd use trackdisk.device in the bootblock to load the first track and use a hard loader from there. IIRC the first track is already buffered in trackdisk.device.

Yes that's what I'd do too, though, it's not always possible to use trackdisk.device, f.e. if you need to load very low into memory for whatever reason a custom trackloader is needed (well, you could of course use trackdisk to load to a "safe" location and then copy the code around but... ;D)

Originally Posted by zaz

The bootblock checksum etc was included in the size measurement, so I included that optimization, while pmc said the load routine should be possible to use standalone so I didn't remove that stuff.

I see where you are coming from but it still is a bootblock specific optimization, i.e. you can't use the loader as is anymore once you applied it. It is a nice little trick though which I thought of too (usually I use the "rootblock offset" as ID for my own stuff) but didn't post it due to aforementioned reasons. It would be interesting to see what the smallest "use any trick in the book" bootblock trackloader would look like, if I'm bored enough I might code one.

Originally Posted by phx

But you can delete the Forbid() call, because the interrupts are disabled anyway.

I removed that already but seems PMC didn't use any of my optimizations (the lea dsklen(a5),a0 etc is gone too) in the latest version of his trackloader.

Originally Posted by Toni Wilen

Yes, I know. I did say it "technically works"

I know!

Originally Posted by Toni Wilen

CIA-A (CIA-B 8-bit data lines are connected to CPU data line bits 8-15, CIA-A = data line bits 0-7) but nothing happens because CIA-A chip select is inactive. (not so simple on 68020+ Amigas but basically same) Still, don't do that

Thanks for the info! Still not an optimization I'd ever use.

Originally Posted by pmc

Funny you should say that zaz - I just amended, assembled and tested the source including your code in place of mine and it works like an absolute charm and is also now only 380 bytes!

Could be even smaller (look above)

[StingRay]

Just had a look at the new version of the trackloader and this is my version of the "move_to_start" routine:

.move_to_start:
	lsr.b	#1,d4
	beq.b	.at_start
	bcc.s	.step_to_start
	bclr.b	#2,(a6)		;select upper disk head
.step_to_start:
	bsr.b	.step_heads
	subq.b	#1,d4
	bne.b	.step_to_start

Didn't test it but I think it should work. I also did some other optimizations and also added the "copy code to safe location and flush cache" stuff. Size: 400 bytes (my magic number ;P). Not tested at all but *might* still work.

Edit: optimized the "copy to safe location" routine, 398 bytes now. ;D

[Asman]

I have questions. What is exactly happen when disk is inserted right after reboot ? Is there any documentation about it ?
When OS want to load bootblock somewhere then how he choose the place ( OS do AllocMem for bootblock or something ??? ).

[Toni Wilen]

Originally Posted by Asman

I have questions. What is exactly happen when disk is inserted right after reboot ? Is there any documentation about it ?
When OS want to load bootblock somewhere then how he choose the place ( OS do AllocMem for bootblock or something ??? ).

Identifier (dostype) is checked, memory allocated normally (afaik it is always from chip ram), boot block loaded, checksum checked and finally boot block code is executed with following register contents:

A1 = trackdisk.device io request
A6 = execbase

I don't know if official documentation exists.

[zaz]

There's at least this from Devices:
http://amigadev.elowar.com/read/ADCD.../node007D.html

[pmc]

Originally Posted by zaz

Well this is all an educational exercise anyway, right? For practical applications I'd use trackdisk.device in the bootblock to load the first track and use a hard loader from there. IIRC the first track is already buffered in trackdisk.device.

Originally Posted by StingRay

Yes that's what I'd do too, though, it's not always possible to use trackdisk.device, f.e. if you need to load very low into memory for whatever reason a custom trackloader is needed (well, you could of course use trackdisk to load to a "safe" location and then copy the code around but... ;D)

You guys would use the trackdisk.device instead of getting hardcore and bashing the hardware directly...?

The OS is for wimps - I thought you were real men!

Originally Posted by StingRay

I removed that already but seems PMC didn't use any of my optimizations (the lea dsklen(a5),a0 etc is gone too) in the latest version of his trackloader.

Sorry dude - I didn't mean to be disrespectful to your optimisations.

Originally Posted by StingRay

Could be even smaller (look above)

When you're around and hunting for optimisations, I don't doubt it.

Originally Posted by StingRay

I also did some other optimizations and also added the "copy code to safe location and flush cache" stuff.

Great work Stinger.

Originally Posted by Asman

I have questions. What is exactly happen when disk is inserted right after reboot ? Is there any documentation about it ?
When OS want to load bootblock somewhere then how he choose the place ( OS do AllocMem for bootblock or something ??? ).

I'd like to know these type of things too - I know next to *nothing* about the OS or OS type functions and calls.

EDIT - too slow posting - Toni and zaz to the rescue.

[zaz]

372 bytes now.

Using dsklen as base register was discussed before; this version has it and keeps readability by using asmone/phxass/vasm BASEREG.

Also some bset/bclr to CIA is collapsed to move/ori but should be in a safe manner.

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

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...

opt_bb_trkldr_zaz.68k