LONG not big enough

[IFW]

I don't think anyone used SAS/C with its own editor...
I certainly did not.
Used CygnusED+Opus and compiled with SAS+Devpac. You can build a very reasonable environment around these keeping the best bits of each. The last version of SAS/C was doing very decent optimisations for its time.
Obviously, these days you'd be way better of with a recent version of GCC or LLVM - and just use your favourite editor etc.

[mritter0]

			if (size>=102400)
			{
				size=(size*100+512)/1024/100;
				unit="TB";
			}

Fixed

[BigFan]

Originally Posted by mritter0

            if (size>=102400)
            {
                size=(size*100+512)/1024/100;
                unit="TB";
            }

Fixed

No, no. You can't be serious with that. I've given you the correct math and what are you doing?
If you still don't know what's wrong, i suggest you to attend some basic math lessons at school. It's obvious you didn't understand the code Thomas has provided.
USE a calculator to check your #*-§$% equation.
And a final warning, if you stick with 32 bit integer, you will be unable to query the numbers of blocks (or segments) from any drive bigger than 2 gigs tera if blocksize is 512 byte.

I'm out.

[thomas]

Originally Posted by BigFan

you will be unable to query the numbers of blocks (or segments) from any drive bigger than 2 gigs if blocksize is 512 byte.

2 tera, not giga.

[BigFan]

Originally Posted by thomas

2 tera, not giga.

Indeed!!
How, embarrassing

[thomas]

And you probably won't see drives bigger than 2 TB on AmigaOS anyway because of the same reason: both dos.library/Info() and HD_SCSICMD/Read Capacity use 32bit numbers for block size and number of blocks. If block size is 512, 2 TB is the limit. Whether block sizes other than 512 work on AmigaOS has not been proven yet.

[mritter0]

NumBlocks=2147483647 (1TB)
size=(NumBlocks/bpm*100+512)/1024; = 102,400
>=102400 yes
size=(size*100+512)/1024/100; = 100 (TB)
sprintf(BTUBuffer,"%lu.%02lu %s",size/100,size % 100,unit); = 1.00 TB


NumBlocks=3221225470 (1.5TB)
size=(NumBlocks/bpm*100+512)/1024; = 153,600
>=102400 yes
size=(size*100+512)/1024/100; = 150 (TB)
sprintf(BTUBuffer,"%lu.%02lu %s",size/100,size % 100,unit); = 1.50 TB


I know I will never see a TB drive on OS3.9, but if someone uses it on OS4, they all seem to have 1TB or 2TB drives.

[thomas]

Wrong test. Try NumBlocks = 3326452170. This is 1.549 TB which should round up to 1.55 TB. But your code displays 1.54 TB.

Here is a test driver which lets you enter block size and terabyte value:

int main (int argc,char **argv)

{
char buffer[20];
unsigned long b;
unsigned long n;
double f;

if (argc != 3)
	{
	printf ("invalid args\n");
	return (20);
	}

b = atol(argv[1]);
f = atof(argv[2]);

#define KB ((double)1024)

f *= KB * KB * KB * KB;

n = f / (double)b;

printf ("%lu * %lu = %s\n",b,n,nice_size(buffer,b,n));

return (0);
}

Please try to understand what the expression (x + 512) / 1024 does, especially why + 512 is in there.

Then think about why (y + 512) / 102400 does not do the same.

[mritter0]

OK....now we are all on the same page. Did some more testing, the numbers were working out simply because they are so large and were rounding close to the actual values. I was also testing with Google and another site that rounds to 3 places, so it always looked correct, but yes, I was off.

On to other parts of the project.............

[Thorham]

Very late, but... if it's for 68020+, just use 64bit divu/divs (inline some asm).

[matthey]

Originally Posted by Thorham

Very late, but... if it's for 68020+, just use 64bit divu/divs (inline some asm).

That would be straight forward if the 68020 had integer 64/64=64 and 64*64=64 but it has 64/32=32 (with 32 rem) and 32*32=64. It could be done with inlined assembler 68020 instructions but requires care as multiple instructions and multiple datatypes are needed (tricky to return a 64 bit int when the compiler doesn't support this datatype). It's easier and safer to use a compiler that supports 64 bit (long long) ints. The executable using inlined assembler may be faster for someone that is knowledgeable but there usually isn't much 64 bit math.