ASM: Hardware Track Loader

[Vortex]

Gentlemen,

Attached is the code for a basic hardware track loader.
Tested it on a real Amiga 500, and df0: is still alive

Some remarks:
- Hardly any checks in there. For instance, if you want to try and read track 2000..., the result will be ehhhm.. undefined.
- It can probably be coded a little more compact, but at least it's readable now
- Uses df0: (hardcoded).
- The example loads track 0 and 1 from disk and then exits. use D DecodeBuffer or H DecodeBuffer to see what has been read (Both ASMOne).

Enjoy, and comments are always welcome.

Cheers,

V.

[pmc]

Nice one mate.

Time to download and check.

[xaind]

Thanks Vortex, especially for commenting the code so well.

[pmc]

Watcha chaps.

I made a small trackloader routine that can be installed on a bootblock (526 bytes total) and I'm trying to test it to see if it works OK.

I wrote the trackloader bootblock to disk using Asm-One and calculated the checksum and the disk is bootable so that seems to have worked.

I can see that when it boots it finds track 0 OK, moves to the required track OK and reads that track. But then it just sits there.

If I hit the HRTMon freeze button I can see that where it's sitting is in a loop looking for the $44894489 MFM sync mark longword.

This is making me think I'm not writing my test binary routine that I want to load and execute with the trackloader to disk correctly with Asm-One.

Well, either that or my code isn't working as I think it should...

Anyone got any advice either about using Asm-One correctly or whether the approach I've used in my code is OK?

EDIT: Old version of code removed.

[StingRay]

Had a quick look and can't see anywhere that you properly "kill" the system and stuff. Which is most probably the reason for your problem (track not loaded correctly, no SYNC marker => bang bang you're dead)

[pmc]

OK so I still have to do all the forbid stuff up front then...?

Originally Posted by StingRay

(track not loaded correctly, no SYNC marker => bang bang you're dead)

Am I also writing the track to disk wrong in the first place too then...?

[StingRay]

Originally Posted by pmc

OK so I still have to do all the forbid stuff up front then...?

Yeah, just kill interrupts/dma etc and then enable disk dma. for a very quick (and dirty) test a move.w #$4000,$dff09a might be enough.

Originally Posted by pmc

Am I also writing the track to disk wrong in the first place too then...?

If you're using ASM1 to write the track then there shouldn't be any problems.

[pmc]

Nice one mate - I'll do more testing.

[pmc]

Added a jsr forbid, and move.w $7fff to intena, dmacon and intreq to the code and now when it boots it just gurus out.

More testing needed I think...

[Toni Wilen]

Sync check is bad, always use word comparison because there can be 0 to 2 sync words at the beginning depending on disk position when DMA was started. (and position of Paula's internal word counter)

EDIT: or was it 0 to 1? I don't remember and too lazy to check

[pmc]

Cheers Toni - I'll swap longword cmp over to two word cmp's.

[StingRay]

Originally Posted by pmc

Added a jsr forbid, and move.w $7fff to intena, dmacon and intreq to the code and now when it boots it just gurus out.

Now that doesn't make sense. Check your code. And what Toni said (just noticed that too).

[pmc]

OK - new version of code attached.

This one forbids multitasking and turns off dma and interrupts and doesn't guru out in doing so.

Also, it now locates the $4489 sync words a word at a time instead of as one longword and seems to find the syncs as it doesn't freeze anymore.

However, what it does now is in some ways worse! It starts stepping the heads and runs away and tries to step them up and beyond cylinder 79. Ooooops!

So - DON'T run this version on a real Amiga!!

Glad I'm testing this on WinUAE or I might now have a dead drive!

More bugfixing to do but I'm nearly there I think...

EDIT: Bad code described above removed - I looked at the decode routine again this morning (I always spot bugs in code in the morning! ) and found some *really* obvious mistakes. They've been fixed so now just some more testing...

[pmc]

OK chaps forget all about my previous trackloader attempt per my posts above - I was trying to cut way too many corners with that one and, in short, it was a load of crap.

Anyways, I went away, actually *thought* about it and recoded it from scratch.

So, tested working bootblock trackloader (736 bytes total size) attached.

[StingRay]

Originally Posted by pmc

So, tested working bootblock trackloader (736 bytes total size) attached.

Nice that you got it to work. It can easily be made smaller (mine is 494 bytes :P) and faster, you can access the CIA registers indirect like the HW regs f.e. =) Also, there is no need to start/stop motor for each track, just turn on the motor, check if the drive is ready, load your tracks and then turn the motor off.

[pmc]

Originally Posted by StingRay

It can easily be made smaller (mine is 494 bytes :P) and faster

LOL!

One step at a time! I was just glad to get it working!

Thanks for the advice on some of the savings I can make - now that it's working OK I can go back and optimise.

This is probably a silly question but has your bootblock trackloader got enough space left over to also do decrunch of the loaded data...?

I just wonder whether it might be posslble for me, after I trim the existing loader down, to add a decrunch routine too...

[StingRay]

Originally Posted by pmc

One step at a time! I was just glad to get it working!

I know.

Originally Posted by pmc

This is probably a silly question but has your bootblock trackloader got enough space left over to also do decrunch of the loaded data...?

Not a silly question at all. Actually, I never really made a "bootblock trackloader", I just coded a size optimized trackloader which happens to fit on a bootblock. And yes, there is enough space for a decruncher, the CRM decruncher I am using is 328 bytes so that makes 494+328=822 bytes. Still 190 bytes (1012-822) left for code.

Originally Posted by pmc

I just wonder whether it might be posslble for me, after I trim the existing loader down, to add a decrunch routine too...

I'm sure you can do that!

[pmc]

Originally Posted by StingRay

I know.

Originally Posted by StingRay

And yes, there is enough space for a decruncher, the CRM decruncher I am using is 328 bytes so that makes 494+328=822 bytes. Still 190 bytes (1012-822) left for code.

Cool.

For my trackloader though, 736 + 328 = 1064

I better get optimising!

[StingRay]

Originally Posted by pmc

I better get optimising!

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

[musashi5150]

Yes, as Dr Sting says it can be done with room to spare I did a bootblock trackloader and decruncher for an old crack of Strider I did when I was learning and then packed all datas on the disk with my own cruncher. I made sure it did depack stripes of course for that 'pro' touch

Once you've written your own trackloader the natural progression from there is cracking y'know Well, it was for me