ASMOne: Sectors and Tracks

[Vortex]

Gentlemen,

I'm a little bit confused about the terms 'track' and 'sector' as used by ASMOne in relation to the Amiga floppy disk geometry of a DD disk described here: http://lclevy.free.fr/

Based on the info from the ASMOne guide (V1.4x) I come to the following conclusion:

Sector:

From the ASMOne guide: "The Amiga floppy disk (880 Kb formatted) has 1760 sectors. Each sector is 512 bytes in size". A sector in ASMOne is what they call a block on the website.

So a RS command with offset = 22 and length = 11 would read 11 * 512 bytes from cylinder 1, side 0 (up).

Track:

From the ASMOne guide: "The Amiga floppy disk (880 Kb formatted) has 80 tracks. Each divided into 11 sectors."

That makes 880 sectors, only half of the 1760 they mentioned before. I think what they call tracks in ASMOne they call cylinders on the website and the ASMOne guide should really state: "The Amiga floppy disk (880 Kb formatted) has 80 tracks (cylinders). Each track (cylinder) has 2 sides, each in turn divided into 11 sectors."

So a RT command with offset 0 (start track = 0) and length 1 (1 track) would read 22 * 512 bytes from cylinder 0, both sides of disk. Same as block (sector in ASMOne) 0 - 21.


Hope some of the enlightened can confirm (or trash...) my findings.

Cheers,

Lar... Eh Vortex..

[StingRay]

RT with length 1 reads 512*11 bytes. You can easily check that yourself, create a buffer, fill it with a pattern and do the RT command. You can easily see how much data was read then. I.e.

BUF dcb.l 10000,"TRK!"

Assemble this and when asked for the "RAM PTR" just use BUF. Once you executed the RT command you can check the buffer with "h.l BUF". Hope that helps.

[Vortex]

Thanks Stingray...

RT indeeds reeds 512 * 11 bytes.
Also tried to read track 159, works ok.
Fails when I try to read track 160 (as would be expected).

Guess that '80 tracks' in the ASMOne guide tricked me..

I.ve been doing a lot of reading on disk related stuff, want to make a trackloader...
All theory up till now. No trial and terror yet..., will do that soon enough.
Your little example shows it's the best way of discovering how something works.

[StingRay]

Originally Posted by Vortex

I.ve been doing a lot of reading on disk related stuff, want to make a trackloader...

I read that in PMC's demo thread Good luck with it, if you read the HRM carefully you should have all info that's required to code a basic trackloader.

[Photon]

Well, a disk has 80* cylinders, each containing one track per head, just as for harddisks. So "sector 1759" and "track 159" is an arbitrary addressing method. Sectors per track depends on density and file system, so it's different for every type of media and file system, whereas cylinders and heads are physical characteristics of any disc-based media. Er, except CDs, which the drive manufs in their infinite wisdom made a spiral, like on a good ol' LP.

And, what Stingray said, get Hardware Reference Manual if you haven't already. It's a reliable source for correct info.

[Vortex]

Stingray, Photon, thanks for the info.

So far almost no time for Amiga. Only managed to put my silly copper routine (http://eab.abime.net/showthread.php?t=44895) on the bootblock in a lost hour. Like how you just insert your disk and zap.., instant copper bars on screen. Hardly a major achievement, but I'm having a blast (from the past...).

Guess I really should find the time now to get some coding done, cause I've run out of stuff to read...

Lars

[Vortex]

Little update: I spent my Friday night coding the track loader (), and it's is almost finished. It loads and decodes without any problem as far as I can tell.
As a test, I loaded the copperbars routine (mentioned earlier in this thread) from track 0 into mem. After scanning the loaded data using: "h DataBuffer", I located the start address of the copperbar routine.
j $<copperbar_routine_start_address> showed me 3 moving bars...

Only thing left to do is to decode the MFM data to the right position in the data buffer but that doesn't look like rocket science to me.

I'm quite pleased I must say.


Hey PMC, what about a mega demo?

If any one is interested I can put the code in the code tutorial sub forum once completely done

Cheers

[pmc]

Originally Posted by Vortex

So far almost no time for Amiga. Only managed to put my silly copper routine (http://eab.abime.net/showthread.php?t=44895) on the bootblock in a lost hour. Like how you just insert your disk and zap.., instant copper bars on screen.

Nice one. Like most things (!) I'd have no idea how to do that.

Originally Posted by Vortex

Little update: I spent my Friday night coding the track loader (), and it's is almost finished. It loads and decodes without any problem as far as I can tell.
As a test, I loaded the copperbars routine (mentioned earlier in this thread) from track 0 into mem. After scanning the loaded data using: "h DataBuffer", I located the start address of the copperbar routine.
j $<copperbar_routine_start_address> showed me 3 moving bars...

Good stuff. You don't hang around do you! Sounds like you've gone from zero to hero in your trackloader knowledge in no time. Top man.

Originally Posted by Vortex

If any one is interested I can put the code in the code tutorial sub forum once completely done

Yes please. Sign me up as first on the list of people who are interested.

Originally Posted by Vortex

Hey PMC, what about a mega demo?

Cool.

Two things I'd be struggling with: one - coming up with ideas for routines and two - when I do come up with an idea, actually making code for it that works! I still feel like such a lamor most of the time.

[StingRay]

Originally Posted by Vortex

Only thing left to do is to decode the MFM data to the right position in the data buffer but that doesn't look like rocket science to me.

Hmm, how do you decode in your current loader then? Because I don't really understand that you can already decode your data but not to the right location? Enlighten me please.

Originally Posted by Vortex

If any one is interested I can put the code in the code tutorial sub forum once completely done

Please do, I'd like to have a look. =)

Originally Posted by pmc

Nice one. Like most things (!) I'd have no idea how to do that.

Not hard to do, if your code is smaller than 1024-12 (bootblock header is 3*4 bytes) bytes you can just create a normal bootblock and include your code, i.e. after the bootblock header your code follows. If it's larger than 1024-12 bytes you can just load your code via trackdisk.device.

[Vortex]

Good morning all,

Originally Posted by pmc

Nice one. Like most things (!) I'd have no idea how to do that.

Takes a few simple steps to make your own bootblock with custom code. I don't know about this trackdisk.device Stingray mentioned so I'll just quickly explain how to make one for max 1024-12 bytes using ASMOne.

Add:
bootBLockHeader:
dc.b "DOS",0
dc.l 0,880

to the start of your code.
1st long word contains disktype + flags.
2nd long word is the checksum (we'll get to that later).
3rd long word is the # for the rootblock, which is 880 ($370) by default but when you're using your own track loader you don't care what this is. I just set it to 880.

Now, assemble your code and use WS (Write Sector) in ASMOne (I guess the others xASMx's will have this option too).
You need to enter dataPtr, which is bootBLockHeader.
start sector, which is 0 and length which is 2 (so you'll write sector 0 and 1 for an ass-whooping 1024 bytes ).

Next, you'll need to make sure the checksum is ok. You can use CC in ASMOne for this. Just enter CC on the command line and ASMOne will calculate and write the checksum for you.

Now, reset the mig and watch your code running from the bootblock.

Originally Posted by pmc

Cool.

Two things I'd be struggling with: one - coming up with ideas for routines and two - when I do come up with an idea, actually making code for it that works! I still feel like such a lamor most of the time.

So far I've seen a sin scroller, plasma and a complete intro. Looks like you do get stuff to work I'd say..

Originally Posted by StingRay

Hmm, how do you decode in your current loader then? Because I don't really understand that you can already decode your data but not to the right location? Enlighten me please.

I'll try.. What I ment was the first sector you read is not always the first sector of the track. As an example, in your MFM Buffer you could have sector 8 - 9 - 10 - 0 - 1 - 2 - 3 - 4 - 5 - 6 - 7.
If you decode this without paying attention to what sector needs to be decoded first you'll end up with correctly decoded data in the wrong order (block wise).
The decoding itself works fine though.
Hope I did a better job of explaining, but with low levels of coffee in my system on a sunday morning it's really hard...

Once ready I'll post the code in the tutorial sub forum for you to have a laugh...



Cheers,

Lars

[pmc]

Originally Posted by Vortex

So far I've seen a sin scroller, plasma and a complete intro. Looks like you do get stuff to work I'd say..

Too kind, too kind. What you haven't seen are the ten (or twenty!) non-working routines for every working one.

Originally Posted by Vortex

I'll just quickly explain how... ...using ASMOne.

Sounds from your explanations that ASMOne contains lots of these useful features that I'm not sure if Devpac does. Might be time for me to RTFM for Devpac. Or check out ASMOne...

[StingRay]

Originally Posted by Vortex

Next, you'll need to make sure the checksum is ok. You can use CC in ASMOne for this. Just enter CC on the command line and ASMOne will calculate and write the checksum for you.

If the assembler is not able to calculate the boot checksum, the following small routine can be used (uncommented, coded it years ago, but easy to understand anyway):

; calc bootblock checksum
    lea    BOOT,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)
    rts

Originally Posted by Vortex

I'll try.. What I ment was the first sector you read is not always the first sector of the track. As an example, in your MFM Buffer you could have sector 8 - 9 - 10 - 0 - 1 - 2 - 3 - 4 - 5 - 6 - 7.

Ok, now I understand. That problem is not hard to fix, all info you need is in the sector header.

[Vortex]

Gents,

It appears I have a working hardware track loader.
Wasted some time tracing a silly bug. . Initially it would go KABOOM on me when trying to load more than 1 track but that's fixed now.
So, guess I'll run some more tests, clean up the code and post it in the 'Coders Tutorials' section for any one who might be interested...

Now for that mega demo... Any volunteers


P.S. df0: is still in one piece

[pmc]

Originally Posted by Vortex

It appears I have a working hardware track loader.

Originally Posted by Vortex

P.S. df0: is still in one piece

Cool. Well done Vortex. And without killing your hardware too - result.

Originally Posted by Vortex

So, guess I'll run some more tests, clean up the code and post it in the 'Coders Tutorials' section for any one who might be interested...

Yes please - will be very interesting to look at.

Originally Posted by Vortex

Now for that mega demo... Any volunteers

I can't promise I can produce anything worthy but I'd be willing to try.

[StingRay]

As said on IRC already, it's cool that you finished the trackloader! And your drive even survived the attacks of the killer trackloader. :P

[Vortex]

Track loader source is in the coders tutorials section... http://eab.abime.net/showthread.php?t=45654 Have fun.

Originally Posted by StingRay

And your drive even survived the attacks of the killer trackloader. :P

Yes, setting the wrong bit to change direction is not a smart thing to do... Especially when you try pushing the drive head beyond cylinder 0 ...
But not to worry, that's fixed in the example code..

Have fun

[Toni Wilen]

Originally Posted by Vortex

Yes, setting the wrong bit to change direction is not a smart thing to do... Especially when you try pushing the drive head beyond cylinder 0 ...

Most drives ignore the step in this situation (or "noclick" programs would not have never worked). AFAIK only really old drives (for example A1000-era drives) try to step beyond cylinder 0 and make strange sounds

[Vortex]

Yup, HRM mentions that all 'new' drives must refuse to step beyond cylinder 0.
Only problem here is, what can be considered a 'new' drive? Judging by the fact that mine still works, I consider the one in my mig a 'new' drive

[Jope]

Like Toni said, only the very old 84-85 clunkers don't like it.

Noclick works in the same fashion. If your drive goes silent with a noclick program, then you can feel free to step outwards from track0 as much as you like.

[Photon]

Is there a difference between NoClick and AntiClick? For me, I always had trouble with NoClick and AntiClick worked properly.