How to get free bytes on volume?

[AGS]

Hi,

to get the free bytes I am trying to traverse the dos-lists and call Info() with the lock provided in a doslist node. I assume that this is a lock to the listed volume.

This is what I am doing:

        moveq    #LDF_VOLUMES,d2
        jsr    _LVONextDosEntry(a6)

        tst.l    d0
        beq    .ready

        move.l    d0,a0

        move.l    dol_Lock(a0),d1
        lea    fm_infodata(a4),a0
        move.l    a0,d2
        
        jsr    _LVOInfo(a6)
        
        tst.l    d0
        beq    .fail

        move.l    fm_infodata+id_NumBlocks(a4),d0
        sub.l    fm_infodata+id_NumBlocksUsed(a4),d0
        move.l    fm_infodata+id_BytesPerBlock(a4),d1
        bsr    mulu32
        
        ; free bytes now in d0

But I get always just the same value for all volumes, including ram:

2147483136 bytes free

Is something wrong with the way I do this? I expect different values.

Greets,
ags

[Toni Wilen]

Did you check if dol_Lock is zero? (Does it ever contain anything?) Zero equals boot drive root.

Multiplication also overflows if drive is larger than 2G.

[Cylon]

Also, a rather obvious idea would be to check if there is any value in d0 and d1 before you branch to this weird mulu32. Could be really easy done with the debugger.

[AGS]

I checked and the lock is always zero. So this way to get the free bytes does not work.

[thomas]

You may not call DOS functions while the DOS list is locked anyway. You could run into a deadlock.

You'll want to remember the names anyway, so just collect the names in a list and after you finished with the DOS list, call Lock() and Info() on each of them.

[AGS]

You may not call DOS functions while the DOS list is locked anyway.

Good to know. I did not find this in the docs. From there a deadlock can happen with LDF_WRITE when someone tries to send me a packet or so. I use LDF_READ.

[AGS]

It now seems to lock correctly, but how can I solve the 2G barrier problem?

I would like to output "15KB" or "2MB" or "124 Bytes" instead always the full number of bytes.

[Daedalus]

The 2GB thing is a little strange - the value you gave is exactly 512 bytes less than 2GB. How are you retrieving the result from the stack after the mulu32? Your comment says the result is in d0, but the result is a 64 bit number and so won't fit in d0. You need to retrieve the result from the stack in the case of mulu32, it's different to the mulu/muls operands.

As for giving the result in KB or MB, just divide the result down by 1024 (LSR 10) if it's over 1024 to get KB. If it's still over 1024, do the same to get MB. If it's still over 1024, do the same to get GB. If you want fractional parts (e.g., 1.5GB instead of just 1GB) multiply the whole lot by 10 at the start and format your result with a decimal point before the last character, or else use the floating point libraries for the dividing.

[AGS]

I think I need to use a library for a real mulu32 - if that exists - with return on stack. And convert that number to a string somehow.

[Daedalus]

Where does the mulu32 you're using come from? Utility.library contains the UMult64() function which does the same thing (32*32->64) and returns the result as two longwords in d0 and d1. Maybe the 2GB you see is only half of your result, the other half being in d1? It would depend on the implementation of mulu32...

The conversion to a string should be the last step and I'm sure can be done using a simple library call. Can't remember which off hand but it's a common function so shouldn't be too hard to find.

[AGS]

Its a plain d0.32 * d1.32 to d0.32 multiplication function.

[Daedalus]

Ah, sorry, I presumed it was a function returning the 64-bit result on the stack. What does it do that plain mulu doesn't? You could try the utility.library call anyway to ensure the multiplication is working correctly.

[AGS]

It's just a 68000 version of the 68020+ mulu. Thanks for the ideas.