ASM: Hardware Track Loader

[Asman]

Originally Posted by StingRay

Not really the best idea when the system is completely killed. Besides, relocating stacks is nothing bad.

I assume that if you can do Forbid then mean you can do AllocMem before it.

[Toni Wilen]

Possible pointless "advanced" optimization: start DMA, wait for 2 wordsync interrupts, decode first sector, wait for next wordsync, decode next sector. More Amiga-like! (not that you really gain any real speed ups because waiting for stepping is still slow)

(I did it like this in Digital Disco II's track loader, not sure why..)

[StingRay]

Originally Posted by Asman

I assume that if you can do Forbid then mean you can do AllocMem before it.

Yeah, of course. However, if you kill the system and don't ever use any system functions anymore (bad idea anyway) you can freely relocate the stackpointers as the system is "yours".

[phx]

Some more optimizations:

        move.w  (a3)+,d6
        cmp.w   #$4489,d6
-->
        cmp.w   #$4489,(a3)+

Same for "move.w (a3),d6" below.

Also you may want to change "lsl.l #1,Dn" into "add.l Dn,Dn", which saves no byte but is faster on 68000.

[pmc]

Originally Posted by StingRay

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.

That's the idea with this trackloader --> to take over the whole system and not allow any exit other than a reboot or power cycle.

Originally Posted by StingRay

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

Sting, Toni - I'll look at this more system friendly stuff. Might as well do these things right. This type of correct OS stuff is what I'm bad with - I don't really understand the OS at all - I only know (some) things about hardware bashing.

@ phx - superb stuff - thanks for those optimisations.

Thanks to those, here's a 420 byte version of the trackloader. I also fixed the timer offsets so that they're more readable.

EDIT: 420 byte version removed.

[Toni Wilen]

It still does not handle condition when the very first word isn't $4489 (cmp.w #$4489,(a3)+ always skips first word) but also remember extra words in gap when fixing this.

[pmc]

Toni - the comparison for $4489 steps through the MFM buffer one word at a time until it hits a $4489 and then makes sure it hits a second $4489 word before decoding the sector header.

I thought cmp.w $4489,(a3)+ didn't skip the first word - it's post increment isn't it? - as in check what's in (a3) then increment + .w

As disk read is triggered at $4489 (as set in the dsksync register) would there ever actually be a situation where this routine won't sync properly?

I'm just trying to avoid adding any code I can get away with not adding if at all possible.

[StingRay]

Originally Posted by pmc

That's the idea with this trackloader --> to take over the whole system and not allow any exit other than a reboot or power cycle.

I know. As otherwise you wouldn't really need a trackloader. :P

Originally Posted by pmc

Sting, Toni - I'll look at this more system friendly stuff. Might as well do these things right. This type of correct OS stuff is what I'm bad with - I don't really understand the OS at all - I only know (some) things about hardware bashing.

This is not too complex, actually, the only thing that's important is that you copy your code to some safe location so it can't be trashed. Doing that is simple:

- use AllocMem to allocate memory for your bootblock code (you could also use absolute addresses but I don't really like this)
- copy the code into the just allocated memory space
- check if your code is running on a OS2.0+ machine and if so, call Exec's CacheClearU to flush caches
- execute the code you just copied to the safe location code
- have fun

Originally Posted by pmc

Thanks to those, here's a 420 byte version of the trackloader. I also fixed the timer offsets so that they're more readable.

420 bytes is quite cool, I'm waiting for your first bootblock intro. =)

[pmc]

@ Stinger - thanks for that explanation mate.

Just out of further curiosity what's the cache flush for...?

I've seen stuff from you before where you've admonished people for not clearing caches.

Yeah, 420 bytes is nice.

A bootblock intro is something I'll surely attempt at some point.

[StingRay]

Originally Posted by pmc

@ Stinger - thanks for that explanation mate.

Just out of further curiosity what's the cache flush for...?

I've seen stuff from you before where you've admonished people for not clearing caches.

I'm sure you're referring to a certain demo that was recently released. But there it wasn't about flushing cache, it was about disabling cache as that's required once you use SMC (self modifying code). Flushing cache would have the same effect but disabling cache completely is the better solution in case you're gonna use lots of SMC.

Flushing cache is required on CPU's with cache (yeah, hard to guess eh? ) once you modified code so the CPU won't execute stuff that's still in the cache as that's surely not what you want (good example was a "Check Config" routine in the game Manchester United Europe, it copied code around and on my A4060 the game crashed once it tried to execute that very code). More info can be found here.

[pmc]

OK cool.

Originally Posted by StingRay

I'm sure you're referring to a certain demo that was recently released.

LOL. Yeah, that's what I was referring to.

[StingRay]

Originally Posted by pmc

I thought cmp.w $4489,(a3)+ didn't skip the first word - it's post increment isn't it? - as in check what's in (a3) then increment + .w

That's correct, the cmp.w #$4489,(a3)+ is fine.

Originally Posted by pmc

As disk read is triggered at $4489 (as set in the dsksync register) would there ever actually be a situation where this routine won't sync properly?

Only reason I can think of would be a corrupt sector or smth, e.g. wrong/no sync markers.

[pmc]

Yeah, I thought so - nice one Stinger.

I know I *could* check for errors (bad syncs, bad checksums etc.) but it seems like overkill to me - even if I do check for errors a disk won't load or be read properly under those conditions so I'm not really too bothered if something corrupt == crash.

[Toni Wilen]

Originally Posted by StingRay

That's correct, the cmp.w #$4489,(a3)+ is fine.

No, it isn't, if first word isn't 4489 (it isn't a special case), first sector data is completely skipped. It still technically works fine if DMA length is big enough (first sector repeats completely at the end) but...

[pmc]

What would be a better (ie.works in all cases) solution for the sector start comparison Toni...?

[StingRay]

Originally Posted by Toni Wilen

No, it isn't, if first word isn't 4489 (it isn't a special case), first sector data is completely skipped. It still technically works fine if DMA length is big enough (first sector repeats completely at the end) but...

I don't really get this, $4489 is the SYNC marker so why is it wrong to search for it? Also, I suppose about 99% of all trackloaders are buggy then as I can hardly remember one that doesn't do a cmp.w #SYNC,(ax)+. =) Can you explain a bit more please?

[Toni Wilen]

Originally Posted by StingRay

I don't really get this, $4489 is the SYNC marker so why is it wrong to search for it? Also, I suppose about 99% of all trackloaders are buggy then as I can hardly remember one that doesn't do a cmp.w #SYNC,(ax)+. =) Can you explain a bit more please?

Technically they are buggy but practically it never causes any problems because standard read length is long enough. (I just tested Digital Disco 2 track loader, which also has same issue, and it still worked fine even if first word was always non-4489 = first sector was "lost")

btw, I was wrong, no 4489 at the start is very rare condition, it can only happen if dma is started when disk position is just after first bit of first 4489 and before start of next 4489.

[Asman]

size optimization: instead of $8000 you should choose something like $7fffe then you can use lea $7fffe.w,a4 instead of lea $8000.l,a4.

[StingRay]

Originally Posted by Asman

size optimization: instead of $8000 you should choose something like $7fffe then you can use lea $7fffe.w,a4 instead of lea $8000.l,a4.

This is not very useful because load address is not constant, i.e. I consider it the same kind of optimization that I mentioned earlier, I'd only do that for some kind of "code the shortest trackloader" compo as it limits the functionality (you can only load to addresses <$8000). And 2 bytes aren't worth it.

[phx]

Originally Posted by Toni Wilen

btw, I was wrong, no 4489 at the start is very rare condition, it can only happen if dma is started when disk position is just after first bit of first 4489 and before start of next 4489.

Sorry to join this conversation, but AFAICS not even this special case poses any problem to pmc's source. He wrote:

.decode_header: movea.l a2,a4           ;restore start of this track's decode b
        cmp.w   #$4489,(a3)+
        bne.s   .decode_header
        cmp.w   #$4489,(a3)
        beq.s   .decode_header

Which IMHO accepts either one sync or more, but requires at least one.

EDIT: Or is the first detected sync skipped by the hardware and not written into the buffer? I cannot remember ATM. In this case you're right, of course!