@joerg

While I don't know much more about uaescsi.device than you do, and the WinUAE documentation sucks right now (it's at least several versions outdated), it appears something isn't "there" for this to work, as it didn't work.

However, I was able to mount the image file I made as a "hardfile" in WinUAE, to find out it was an extra copy of an old system backup. Nothing I really needed to save anyway, as I still have the other copy I put on my server.

Thanks for the help.

I'll also try to find out more about the emulation. There are several devices that WinUAE creates, but I don't know if they all support NSD commands. I know uaehf.device does (as mentioned in the change log), as otherwise I wouldn't be able to use all 30 gigs of the hard drive I stuck in the PC for this.

I'd be curious to see if this could be made to work, that is once the driver actually supports the NSD commands.

I started a thread on Amigaworld.net (http://amigaworld.net/modules/newbb/v ... _id=25600&forum=27#430738) and didn't realize Joerg no longer had an account over there.

So, Joerg, is it possible to at least read the disk under OS3.9 somehow in my WinUAE setup? Would be nice if I could get it to read and write like under OS4, but I understand that isn't likely to happen. Would just like to be able to read the disk at least and copy some files off of it, since I can't remember what I had on it.

Just in case this turns out to be the only way to read it, I've started reading an image file on my Linux box with dd. I'll probably still experiment with it, try mounting it as a hardfile in WinUAE.

@Helge

Some people in here are more interested in crunching done only by AmigaOS machines with PPC chips.

I could care less, as I'm crunching for the TEAM, not for the Processor/OS.

I have 4 computers here crunching along 24/7. And yes, my checking account feels the crunch since it makes for some high electric bills during the summer while the AC is running in the apartment.

Only one of those even runs AmigaOS, and it's the AmigaOne. The other three are PCs running Windows or Linux.

Here's my current stat's page:
http://stats.distributed.net/particip ... p?project_id=25&id=313381

These computers have been running OGR25 since 2000, exclusively OGR25 since about 2 years ago. All for the Distributed Amiga team.

Here's their stats page:
http://stats.distributed.net/team/tms ... hp?project_id=25&team=200

These other stats pages are interesting, but the two above are all that matter to me on how "we" are doing.

@joerg

Quote:

Downloaded last night, along with new SFS, installed and rebooted. Working great, with a 2 second update rate!

Something I'm noticing about it now, and this might be a side effect of how you are calculating the CPU usage percentages, is the amount showing when only the background task (dnetc) is running. Seems the "non-background" amount keeps fluctuating between 1 and 3 percent, the same as it did with the faster update rate. I thought that maybe the docky was using that much CPU to do it's updating and that giving it a longer update time would reduce the amount used, but it looks about the same with a 2 second update rate versus it's original default.

Too bad we don't really have a program to compare this with. That's something I miss in Scout, is the live CPU usage display in the Tasks/processes window.

Or is there another program out there that can show that live usage like Scout did under OS3.x?

Anyway, I like this much better than before. CPUTemp.docky isn't as distracting now since it runs with a much slower pace on the display.

@joerg

Quote:

Cool! I'll be looking forward to it.

***BUMP***

Anyone else think this would be nice to have? I would have thought someone would have answered by now.

Something I would like to be able to do, but the current CPUTemp.docky doesn't seem to have an optioin for, is to be able to adjust the update rate for the CPU usage graph scrolling. I've always preferred my usage graphs to run slower, say one update every 1 second or so.

So, anyone else think this would be a "nice to have" option?

Thanks for the help, everyone. Getting the name right did the trick.

It is indeed "dnetc crunch #1", as Ranger showed me.

@joerg and salass00

I'll check again in Ranger. I noticed in Scout that it does not seem to show child tasks.

I've seen the dnetc crunch task show up in Scout before, and managed to make it show up last night, but only when I started dnetc from a shell. If I start it the normal way (the project icon in WBStartup), then only one process shows in Scout.

However, Ranger does show the crunch task, even when dnetc is started from the WBStartup project icon. I'll make sure of the name as it shows there and add that to the tooltype.

Thanks for the info. I think this will solve it, once I can give it a try.

With the new OS4 update, I've got the new CPUTemp.docky working in a dock, but noticed something odd about it.

The readme says the graph should use a darker color for "ignored" tasks. I've added dnetc to my icon tooltypes, but it doesn't seem to be showing it as a darker color. I do get on occasion a second usage percentage showing, just not the darker shading for the background usage.

Could I have done something wrong? Here are my tooltypes from the icon:

IGNORETASKS=CPUInfo.CPUTask|CPUClock.CPUTask|dnetc
TOP=175
LEFT=2000
STARTICONIFIED
SETENV
FAHRENHEIT

I removed all the disabled and/or comments entries.

My dnet client program name is dnetc, and is in SYS:dnetc/dnetc. I've tried it with the full path as well but it doesn't seem to make any difference.

Joerg? Any ideas?

@Rogue

Quote:

And I've now downloaded, with the new CPUTemp.docky up and working just fine.

Rogue (and everyone else at Hyperion), great job on OS 4!

@Rogue

Now THAT is what I call timing.

Glad to see the new update.

Joerg, I would say you no longer need to worry about rebuilding it.

In looking for joerg's "new" AmiDVD tool, I noticed that CPUTemp.docky was also updated to version 52.13. My version was 52.5, so I've obviously missed a few versions.

However, I run this and it requires newlib.library 52.20!! I have 52.3 right now, but have not been able to locate it anywhere to download. Is this in some obscure download place? Or is it soon to be released?

From reading the readme on CPUTemp.docky, I'd really like to run the newer one, since it has some features I'd like to use. Like the CPU usage graph that can show dnetc (or any other programs for that matter) separate from the rest.

@Swisso

My 7455 933MHz chip running at 1.0 GHz has been running like that for at least two years now. Before that it ran at Eyetech's original 800 MHz speed.

No problems with my system, but that is because I replaced my heatsink with a Zalman northbridge cooler and a homemade duct with an 80 mm fan in just a few months aftr I got the A1 (before even trying to overclock it). My CPUDocky is showing 131?F right now (about 55?C if I did my math right), and the Silverstone temp monitor in my top 5.25" drive bay is showing 120?F (the probe is measuring the temp of the heatsink above the CPU core, probe stuck between the fins with the tip touching the bottom of the heatsink). Note my CPUDocky is not calibrated, so this temp is likely off a bit. However, since the measured temp with an external probe is only a few degrees cooler on the fin side of the heatsink, I'm thinking the CPU's internal temp circuit is working fairly close to what it should be.

I suppose I could get it to run cooler, but this runs nearly silent. Much better than with the crappy fan/heatsink that Eyetech put on it originally.

Anyway, I mainly wanted to point out that I do not believe the reliability issue is the SPU itself, but likely the assembly of the CPU module and/or other parts on it. These PowerPC CPUs are originally designed for embedded operation, usually in environments that are not necessarily computer-friendly. I would have to say that Motorola/Freescale/IBM have likely "over-engineered" the CPU a bit so that they would work more reliably in those embedded environments.

And we know that Eyetech did not use the correct reference documentation for the CPU they actually used on most G4 setups, as they used an inadequate cooling solution and did not se the voltage to the correct one for the CPU. The 933 MHz 7455 that I have, along with many others, needed 1.79 volts, no the 1.6 they shipped it with, so I'm surprised any of them worked at all!