Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (joerg)

Bottom

« 1 ... 83 84 85 (86) 87 88 »

joerg

Re: SFS Partition Dead

Posted on: 2007/1/29 18:36 #1701

Just can't stay away

@BillE

Quote:

Quote:
If you don't get everything you need back with the PartitionWizard Salvage function I can build a special version of SFS which tries to ignore the error/missing information,

That would be extremely useful, as Partition Wizard seems to have helped me copy over only a few small files so far.

For a start get this special version of diskcache.library.kmod, copy it into your SYS:Kickstart directory and do a cold reboot (<ctrl><alt><alt>). Depending on which sector(s) exactely is/are unreadable you may, or may not, be able to access more data on the broken partition.

Rename the old diskcache.library.kmod or copy it somewhere else to be able to restore it after you got your data back, with this special version everything is slower.

I've uploaded a special version of SFS as well now which doesn't do any retries on itself if there are errors, there are no other changes yet but that should at least speed up booting with the broken partition mounted for you.

Edited by joerg on 2007/1/29 18:51:26
Edited by joerg on 2007/1/29 18:53:20

Topic | Forum

joerg

Re: SFS Partition Dead

Posted on: 2007/1/29 7:36 #1702

Just can't stay away

@BillE

Quote:

I don't want to delete or format the partition as there is a LOT of stuff on it I want to keep

No current backup?

Quote:

Is there a way to repair this error, or at least reduce the endless delay so I can try and copy a few of the files to another partiton ?

There is no tool to repair SFS partitions, but you can use the "Salvage" function of PartitionWizard which will copy the rescued files to another partition.

The error from the first requester is a device error, probably one or more bad sector(s) which can't be repaired automatically by the drive.
Using retry doesn't help since the error wont go away, but using cancel doesn't help either and causes the second requester, without the data from the unreadable sector(s) SmartFileSystem can't continue ...

If you don't get everything you need back with the PartitionWizard Salvage function I can build a special version of SFS which tries to ignore the error/missing information, but in any case some data is lost.
(Not the actual data, unless there are more problems, but the information where the data blocks of some files are stored on the HD. But that doesn't make much difference ...)

If you get everything back with PartitionWizard and want to reformat the partition you have to do a full format, with a quick format the bad sector(s) would stay and cause problems again. Only do that after verifying you really got back all important data, don't only check that all files are there, check the contents of the files as well.

Topic | Forum

joerg

Re: Calibrating CPUTemp.docky

Posted on: 2007/1/23 23:48 #1703

Just can't stay away

@ssolie

Quote:

ssolie wrote:
I'm wondering what it would take to calibrate the CPUTemp.docky.

I have access to a calibrated temperature probe (Fluke) that I could use to measure the exact temperature of the heat sink or similar.

Checking the temperature of the heatsink is problematic since it takes some time to heat up while CPUTemp displays the CPU core temperature which increases much faster when switching on the system.
For an usable calibration you'd need a sensor directly at the die of the CPU.

Quote:

If I take a few measurements with the probe and peek at CPUTemp.docky a few times perhaps I can come up with a meaningful difference.

Prepare your system to boot as fast as possible, no user-startup, everything but CPUTemp.docky removed from WBStartup, everything not required for the test disabled in U-Boot, etc.

Switch it off and let it cool down to room temerature.

Switch it on and as soon as CPUTemp.docky is running for about 5 seconds displaying a (nearly) constant temperature use the probe and note down the results of both the probe and what CPUTemp.docky displays until you get to the normal, idle temperature of your system and it doesn't change anymore. Then start something, or several programs, which use the CPU a lot, something which uses AltiVec if you have a 74xx CPU. For example dnetc. Note down the results of the probe and what CPUTemp.docky displays again until you reach the max. teperature of your busy system. Make sure the TEMPOFFSET and TEMPFACTOR tooltypes are not set when you do this.

Now you should have a table with at least 10 pairs of real temerature (from your probe) and what CPUTemp displays without calibration for them. Using this table and real_temperature = CPUTemp_displayed_temperature * x + y calulate x and y integers in such a way that the average error is minimal and add TEMPFACTOR = x and TEMPOFFSET = y to the CPUTemp.docky tooltypes.

Quote:

I just hope the relationship is linear.

That's unlikely.

In case someone is interested in more details and how bad the TAU is check TAU_Calibration_10s.pdf. I didn't find anything like that from Freescale, except that officially it's not supported at all on 74xx CPUs (even if it works

Topic | Forum

joerg

Re: Collector 3.5 and Index Files loading

Posted on: 2007/1/17 19:46 #1704

Just can't stay away

@sundown

Quote:

sundown wrote:
@joerg

I use DOpus v4.18 ppc for copying.

I just checked and didn't find an option to change the copy buffer size in it's configuration, plese tell the current maintainer of the AmigaOS4 version of DOpus4 to increase the size of the buffer it's using for copying to at least 5 or better 10 MB, or make it configurable.

Quote:

I uncommented the BUFSIZE tooltype in AsyncWB & put in your buffer size & that made a big difference, a 12MB file copies in under 1 sec now. I have some avi movie files that are 700MB in size & they copy in 55 sec. Does that sound normal?

That's about 25 MB/s (reading 700 MB + writing 700 MB / 55 seconds), if source and destination are on the same HD it's OK.
If source and destination are on different HDs, especially if both are on different ports, it should be faster.

Quote:

Buffers=1000 & blocksize=1024. I played with bigger block sizes, but no difference in copy time.

I thought you are using SFS? SFS doesn't get faster with larger blocksizes, some operations even get slower with larger blocks. You should always use 512 bytes/block for SFS partitions (but you don't need to reformat your partitions if you used something else, the differences are minimal).
On FFS2 partitions it should make a big difference, 512 bytes/block is very slow with FFS, you should use 2048 bytes/block for normal FFS2 partitions on which most file are small (Workbench, etc.), and 4096 or 8192 bytes/block for partitions used only for very large files like videos, CD images, etc.

Topic | Forum

joerg

Re: Collector 3.5 and Index Files loading

Posted on: 2007/1/16 9:46 #1705

Just can't stay away

@sundown

Quote:

sundown wrote:

USB CF cards are slow, especially some older cards. I did some speed tests with my card & this is what I got copying that 12MB file.

HD > CF 48 secs
CF > HD 15 secs
HD > HD 15 secs

Partition to partition is under 2 secs & the HD to HD seems way to slow to me, but I have no idea what I'm missing. Both drives are set to UDMA 5 & use SFS. Could be because each HD is on a separate ide port.

No, that should be faster than 2 partitions on the same HD. What did you use for copying?

If you use the workbench add/change the BUFSIZE tooltype in AsyncWB to BUFSIZE=10485760 (if you want to use something else make sure it's a multiple of 65536, for example using BUFSIZE=1000000 would cause slow partial block reads/writes), the default buffer size is very small causing very slow copies. (BUFSIZE is in bytes.)

If you use C:Copy in a shell use something like "copy buffer 20000 source dest", the default is a small buffer (= slow copy) as well. (BUFFER is number of blocks.)

If you use something else for copying check the configuration/options and if there is a setting/option to change the buffer size increase it to a few MB.

Topic | Forum

joerg

Re: Turn off 68K Emu?

Posted on: 2007/1/14 19:56 #1706

Just can't stay away

@bean

Quote:

bean wrote:
Hi,

Is it possible to turn the 68K emulation off entirely under OS4?

No. You can remove the JIT emulation by removing or commenting out the line "MODULE Kickstart/petunia.library.kmod" in your SYS:Kickstart/Kicklayout, but it's not possible to disable the interpreting m68k emulator.

Topic | Forum

joerg

Re: Collector 3.5 and Index Files loading

Posted on: 2007/1/14 18:36 #1707

Just can't stay away

@sundown

Quote:

sundown wrote:
@joerg

I'm using the VIA-ide on a micro which is slow.

Why is it slow? The micro doesn't have the DMA problems an unfixed XE has and you can use UDMA. The default is PIO, you have to switch it manually to UDMA, by putting something like "C:idetool -x a1ide.device 0 69" in your S:User-Startup or by setting U-Boot variables.
A SII0680 could only be faster if you would have a HD which is faster than 100 MB/s since the max. speed on the VIA is UDMA5 (100 MB/s) while the SII0680 supports UDMA6 (133 MB/s).

Quote:

I applied your change, but still slow here. Are you guys using a sil card?

I'm using a SII0680, but I just switched it to PIO4 and it's still much faster than without the patch. Without the patch the index file posted here takes 23 seconds to load, no matter if I use UDMA or PIO, with the patch it takes 2-3 seconds with UDMA5 and 4-5 seconds with PIO4 loading it from a SFS partition.
I have an old HD connected to the VIA as well, which of course runs in PIO mode since my XE isn't fixed, and even loading it from a FFS2 partition from the HD connected to the VIA it takes only about 5 seconds with the patch and 23 seconds without the patch.

Topic | Forum

joerg

Re: There is hope for OS4 on the Classic.

Posted on: 2007/1/14 0:33 #1708

Just can't stay away

@Raziel

Quote:

Raziel wrote:
@Rogue

So, i might be on the lucky side, then?

A4000 64MB Ram (2 MB Chip)
Cyberstorm PPC604e@200MHz
CybervisionPPC
Using SCSI from the Cyberstorm

Although you could use AmigaOS4 with just 64 MB RAM it's not much fun and you should get more. On AmigaOS4 you need more RAM than on AmigaOS 3.x: The kickstart is in the RAM instead of a ROM (and it's much larger than the 512 KB of AmigaOS 3.x), the MMU table need some RAM, the translation buffers for running m68k software with the JIT, PPC native executables are larger than m68k ones, etc.

Quote:

A little question (only if you've got the time)
What horse should i bet on, if i want to change to DMA-able
IDE/ATA (SCSI is getting too noisy and too slow) in the near
future?

AFAIK there is no DMA IDE controller for classic Amigas at all.

Topic | Forum

joerg

Re: Collector 3.5 and Index Files loading (SOLVED)

Posted on: 2007/1/13 16:25 #1709

Just can't stay away

@Pierre55

Quote:

Pierre55 wrote:
@joerg

Hi,

A bug in Collector? I could not beleive that! eheh

The patche you wrote work very well... what it does exactly?

Collector uses the graphics.library function WaitTOF() ("Wait for the top of the next video frame"), probably to sychronise the display of the progress gauge with the screen refresh rate, which doesn't make any sense and only slows it down (unless you have an incomplete graphics driver like the Update4 ATIRadeon.card which does nothing when WaitTOF() is called).
For example games can use the WaitTOF() function after rendering a frame and wait until it's time for the next one, that way you get for example 80 FPS if you are using a 80 Hz screenmode since it makes no sense to render 200 FPS when the monitor only updates the display 80 times per second.
My patch disables the WaitTOF() calls in Collector.

Topic | Forum

joerg

Re: Collector 3.5 and Index Files loading

Posted on: 2007/1/13 8:38 #1710

Just can't stay away

@sundown

Quote:

I'm having a hard time believing a 12MB index file could load in under 2 sec.

Why? If it's not in the disk caches yet loading 12 MB takes about 0.2-0.4 seconds, if it's cached already it takes less than 0.1 seconds. But Collector loads it with over 10000 tiny reads instead of a few small ones which slows it down a lot, it probably does some other things while loading the data, and it's an emulated m68k executable, which results in a load time of about 2-3 seconds for this index file here after removing the useless screen refresh sync waiting from the Collector executable.
Even loading it from a FFS2 partition takes only about 5 seconds with the patched Collector executable.

Topic | Forum

joerg

Re: Collector 3.5 and Index Files loading

Posted on: 2007/1/13 8:16 #1711

Just can't stay away

@Pierre55

Quote:

Pierre55 wrote:
@joerg

You got it... I replace the ATIRadeon.chip file in kickstart
with the one in OS4 Pre4 and the speed loading is like before.

Now... you know how it is sometimes, we fix some bug(s) and
create new one(s)! ;o) I Hope it is a bug!

Yes, but in Collector.

Quote:

Now should I keep the old ATIRadeon.chip?

Of course not, you have this bug back (no working WaitTOF()), no overlay support, etc. with the Update4 version. Install the AmigaOS4 final version again.
To fix the problem in Collector load the Colloctor020 executable (111452 bytes, md5sum d4d281063da710d103a90fc0adf04f3a)
into a hex editor and at offset 0x1ABD8 (109528) change 2 bytes from 2F 0E to 4E 75. If you have the 68000 executable installed (111944 bytes, md5sum 8b4e3e9ec8a6e8a5ed3a3c5bf5fcfc7b) the offset is 0x1ADC4 (110020).

Topic | Forum

joerg

Re: Collector 3.5 and Index Files loading

Posted on: 2007/1/12 21:32 #1712

Just can't stay away

@Pierre55

Quote:

No I'm really talking about the time to load the index file.

OS4 Pre4 -=> 1.8 sec
OS4 Final -=> 23-25 secs

I don't understand why you don't have the speed difference,

I don't have any differences either, 23 seconds with OS4 final as well as with Update4.

But Collector does next to nothing when it loads the index, it's waiting for something most of the time, and it's not waiting for the data it reads. Maybe it only updates the progress gauge once every frame and if you are using a Readon maybe that didn't work in Update4 yet.
You could try if using the ATIRadeon.chip from Update4 with the rest from AmigaOS final makes it faster again, if that's the case it was a bug/missing feature in the Radeon driver which was fixed in the final version of OS4.

Topic | Forum

joerg

Re: Collector 3.5 and Index Files loading

Posted on: 2007/1/11 18:03 #1713

Just can't stay away

@Pierre55

Quote:

Pierre55 wrote:
@joerg

Hi,

Ok if you want to test the loading speed you need to
be able to revert to your OS4 Pre.4.

You can download (everyone that would like to test this) an
index file at: ftp://invite:invite@pgx.dynu.com/CartesAffaires.idx

Thank you.

I didn't test it with Update4 yet (I currently don't have a partition with Update4 installed), but was this index file really loaded in about 2 seconds on Update4 by Collector 3.5 on your system? That's of course possible, but since the rest of Collector is very slow here (before it crashes ...) it seems to be unlikely.
On my system Collector 3.5 loads this index file in about 23 seconds from a SFS partition and in about 24 seconds from RAM Disk:.

Topic | Forum

joerg

Re: Collector 3.5 and Index Files loading

Posted on: 2007/1/10 19:21 #1714

Just can't stay away

@Pierre55

Quote:

Pierre55 wrote:
@joerg

Hi,

I just try to reinstall from scratch the Collector program
and I had the same problem, it crash when trying to make
thumbnails. I replace a library.

Check in your libs if you have the latest popupmenu.library,
maybe you overwrite the one you have or you did not have
one, after replacing this library with that one
(popupmenu.library 52.1 (2006-12-09) It doe'nt crash anymore.

If you can't find this lib just E-Mail me...

I have popupmenu.library 52.1 installed, but the crashes are not popupmenu.library related anyway, it crashes in MPImage.library.
Maybe MPImage.library works with some image formats but not the ones I used (JPEG and GIF, IIRC the crashes were always with JPEG images, but I'm not sure).

Topic | Forum

joerg

Re: Storm screen manager

Posted on: 2007/1/7 17:30 #1715

Just can't stay away

@Swoop

Quote:

Swoop wrote:
I wonder if anyone has managed to get the stormscreen manager working under OS4 Final.

I have Amigawriter installed and it works running on workbench, but if I want to run it on it'e own screen I have to put stormscreenmanager in wbstartup. at which point I get a guru, sorry Grim Reaper.

I have tried blacklisting it but that doesn't seem to have any effect, and I still get a visit from the grim reaper.

No idea if stormscreenmanager uses it, but for most Haage&Partner software make sure you have the AmigaOS4 wizard.library from http://software.alinea-computer.de/seiten/downloads_uk.php installed and not an old m68k version.

Topic | Forum

joerg

Re: Games working (or not) on OS4 Final

Posted on: 2007/1/7 14:47 #1716

Just can't stay away

@BrandonLee

Quote:

BrandonLee wrote:
@acefnq

FREESPACE
-crashes.I'll see what can be done, since it is supposed to work.

WIPEOUT2097
-after the prefs screen, it crashes.Same as Freespace, I think something can be done.

WipeOut2097 can't work since it's a WarpOS program, AFAIK there is no m68k version of it, and if you are using the WarpOS version of FreeSpace, not sure if there is a m68k or OS4 version of it, it's of course the same.

No matter how much people ruin their AmigaOS4 final systems that way, and even if some seem to have some partial success: The versions of powerpc.library includeed in Update3 and Update4 do not work on AmigaOS4 final. If you didn't install AmigaOS4 final on an empty partition, or copied everything from your Update4 partition to the OS4 final partition after installing it on an empty partition, make sure to delete LIBS:powerpc.library and LIBS:Warp3DPPC.library - unless you want to have an unstable system.

Topic | Forum

joerg

Re: SDK-Gurus: ScummVM_OS4 needs your help

Posted on: 2007/1/7 11:04 #1717

Just can't stay away

@hnl_dk

Quote:

hnl_dk wrote:
@joerg

atan2( 0, 0) = 0.000000
atan2( 0, 1) = 0.000000
atan2( 1, 0) = 1.570796
atan2( 1, 1) = 0.785398
atan2( 0,-1) = 3.141593
atan2(-1, 0) = -1.570796
atan2(-1,-1) = -2.356194

that are the correct results (according to glibc)

I've fixed it in newlib.library 52.7, but atan2(0,0) still returns NaN, just like in libnix, which is correct IMHO and the 0 from glibc and clib2 are wrong!?

Topic | Forum

joerg

Re: SDK-Gurus: ScummVM_OS4 needs your help

Posted on: 2007/1/7 10:25 #1718

Just can't stay away

@Jack

Quote:

Jack wrote:
@hnl_dk and raziel

It could be easily verified by compiling the atan2 test program (I would test 7 calls, pairs of args such as:(1,1) (0,1) (-1,1) (-1,0) (-1,-1) (0, -1) and (1, -1).

Compile it vs clib2 and via newlib and check results.

And what are the correct results?

atan2() is broken in at least 2 of 3 AmigaOS C libraries

6.RAM Disk:> type test.c
#include <math.h>
#include <stdio.h>

int main(void)
{
printf("atan2( 0, 0) = %f\n", atan2( 0, 0));
printf("atan2( 0, 1) = %f\n", atan2( 0, 1));
printf("atan2( 1, 0) = %f\n", atan2( 1, 0));
printf("atan2( 1, 1) = %f\n", atan2( 1, 1));
printf("atan2( 0,-1) = %f\n", atan2( 0,-1));
printf("atan2(-1, 0) = %f\n", atan2(-1, 0));
printf("atan2(-1,-1) = %f\n", atan2(-1,-1));
return 0;
}
6.RAM Disk:> gcc -Os -Wall test.c -o test
6.RAM Disk:> test
atan2( 0, 0) = NaN
atan2( 0, 1) = 3.141593
atan2( 1, 0) = -1.570796
atan2( 1, 1) = 0.785398
atan2( 0,-1) = 3.141593
atan2(-1, 0) = -1.570796
atan2(-1,-1) = -2.356194
6.RAM Disk:> gcc -Os -Wall test.c -o test -mcrt=clib2 -lm
6.RAM Disk:> test
atan2( 0, 0) = 0.000000
atan2( 0, 1) = 0.000000
atan2( 1, 0) = 1.570796
atan2( 1, 1) = 0.785398
atan2( 0,-1) = 3.141593
atan2(-1, 0) = -1.570796
atan2(-1,-1) = -2.356194
6.RAM Disk:> m68k-amigaos-gcc -Os -Wall test.c -o test -noixemul -lm
6.RAM Disk:> test
atan2( 0, 0) = NaN
atan2( 0, 1) = 0.000000
atan2( 1, 0) = 1.570796
atan2( 1, 1) = 0.785398
atan2( 0,-1) = 3.141593
atan2(-1, 0) = -1.570796
atan2(-1,-1) = -2.356194

Topic | Forum

joerg

Re: Optimizing OS final install

Posted on: 2007/1/6 18:19 #1719

Just can't stay away

@lazi

Quote:

I am surprised how much memory is used after booting OS4 final on my micro A1.
There is certainly some commodities in the wbstartup, so it should be normal, but 182 megs free from the installed 256 is surprised me compared to my classic Amiga experiences.

Do you have SFS partitions? If yes you could remove it's global cache, diskcache.library.kmod, from your kicklayout to get about 20 MB more free memory (or less free memory if you have a lot of SFS partitions, without diskcache.library each one will use it's own, partition local caches instead), but much slower disk speed.

If you don't use SFS removing diskcache.library.kmod doesn't make much difference, you'd only get 15 KB more free RAM, or about 150 KB if you remove SmartFileSystem as well.

Topic | Forum

joerg

Re: SFS2 with OS 4.0 Final

Posted on: 2007/1/5 21:03 #1720

Just can't stay away

@PEB

Quote:

Actually, I was planning on experimenting with burning >4GB .iso files using FryingPan at the moment.

No idea if FryingPan supports files > 4 GB or not, I've never used it and don't need it since I've written my own DVD burning tool some years ago

, but it's very unlikely that the AmigaOS4 version of FryingPan supports large files already. Check it's documentation, at least 99% of the software which doesn't mention anything about 64 bit file size support in it's documentation doesn't work with files > 4GB.

Topic | Forum

Top

« 1 ... 83 84 85 (86) 87 88 »