@kas1e

This is most likely because when SFS runs out of space it has to clean up the .recycled directory to make room. What happens is that the disk is actually completely full, it just hides the .recycled files from the free space. Because the disk is full it is also probably quite fragmented.

Since SFS (like PFS and JXFS I presume) are single-threaded and cannot accept a new command until the previous has been completely finished the read command from TuneNet gets put in queue (and TuneNet is halted) until the copy (including the .recycled cleanup on the fragmented disk) has finished.

Only way to fix this is to increase the play buffer size in TuneNet if possible so it can play a little longer without disk access. Or of course get a new disk :)

@ZeroG

How do I make the NOAMIGAATTR permanent and global??

I never store any files on USB that I later need special Amiga attributes on. Perhaps that fixes some problems..?

@vox

Java,
Flash,
stable USB 2.0.

Better memory protection, like enforced MEMF_PRIVATE flag (or a new such flag) would be very welcome too.

@Mrodfr

Since someone meantioned USB was fixed I never bothered to test anything more, like USB to SFS formated stick. But I have now a strict read-only policy on all my USB (which are FAT32) devices. Delete is the only thing I perform, and only if I really need to, and only one file at a time.

The FAT32 screwup is annoying.

We also concluded that it must be the cygwin implementation, not windows. Also duscussed MinGW but we think it might be difficult moving our huge build system.

Comparing different things is exactly the point here. Linux does it one way, which is obviously faster, windows+cygwin does it one way which turns out to be extremely slow and Amiga (D)OS does it one way which seems less than optimal too.

Doing all tests in exactly the same way is not realistic and therefore even more pointless.

@severin
I also tried version >>ram:data but reopening and seeking the output stream turned out to be a quite slow process. 136/10 seconds is like 14/second. Very slow. I got something similar when tested this too.

@xeron

Since the scripts are so rediculously small their execution time is negligable compared to loading an executable and run it. But feel free to make a loop around SystemTags instead if you wish.

But DOS scripts are better for real life tests since a lot of them, as small one-liners, are often used inside makefiles. Specially crafted benchmark batch executables are not.

At work we had a kind of special problem with our build system that runs in Cygwin and Linux. On Linux the dependency generation is probably 20 times as fast as on windows+cygwin.

It turned out to be completely related to how fast a proces can be created in cygwin vs. Linux.

We tried a simple experiment:
while true; do date; done | uniq -c

This will execute 'date' as fast as possible and uniq will print a line everytime date prints something different, i.e. once a second.

On my WinXP Core i7 @ 2.66GHz uniq says that date was executed about 64 times/second. That's pretty slow, but we knew that already. On another much slower Linux machine the same number was 1400! Hugely much faster but still what you might expect. Surprizingly a Win7 machine with Core i7 could only manage 14 executions of date per second in cygwin. Strange, but it could be related to antivirus and stuff maybe.

Anyway, I decided to test this on OS4 (G4 @ 866MHz) and I expected high values due to the light-weight processes of Amiga OS. Unfortunately the while loop could not be used with uniq because uniq would not print anything while the loop was running and the loop could not be ended with Ctrl+C in abc-shell. So I had to let date print live instead which probably affected the result a bit due to our ultra slow console printing on Amiga OS.

This is the result of "while true; do date; done": 62 printouts/second. Executing with explicit path I could get 70.

I also tried this in an AmigaDOS script:
lab upp
version
skip upp back

Result: 180 executions/second.

Of course this machine is slower than the Linux machine and much slower than the Core i7, but I still expected higher values.

Comments?

@Amigo1

I saw you solved it, but I might just comment anyway.

AllKeys cannot map qualifier keys, only the key press and release. I have thought about expanding my MapMenu tool to map other keys because that one is designed to map qualifier keys only but currently only maps the meny key to something...

@Hans

Quote:

Then I'm sure it is, just saying.... :)

@poweramiga

A capacitor may be broken on the 5VSB. Caps typically don't like holidays. If they were bad before, they will break when powered on after a week of power off.

If you have the skills, open the PSU and look for bulged capacitors. If you find any, replace them with something similar, but never lower voltage.

Or try bridging the 5VSB to 5V using a not too weak diod.

@vox

Have to agree with xeron here. Way too much work in the wrong direction. If you want to use Windows you move your chair 50cm to the left and simply use that PC instead. I'm sure you have one, everyone does, except me that is

The point of using Amiga(OS) is to have the applications running in this lovely OS instead of in a stupid OS, like winblows. So making winsuck run on AmigaOS kind of looses the point

Besides, how many apps of the kind you wish for really exists for NT PPC??! Now if this sandboxed NT PPC is supposed to emulated x86 versions of the software you might as well use an _existing_ emulator like DOSbox instead.

Or you could just dual-boot Linux

@poweramiga

Does anything happen? Do disks spin up, fans, any output on the monitor/serial, anything?

I think it could be the 5VSB. What does the 5VSB read when powered off but plugged in? It should still be 5V and the network light should be blinking if a cable is plugged in. (Does the A1 have network lights?)

If the power button works at all you could try bridging the 5VSB to 5V with a diod. That way the 5V would help lift the 5VSB up to a decent level if the PSU starts at all that is. The ring marking on the diod towards the 5VSB!

Reversed IFF..? As in little endian :)

Anyway, its just anoth 32-bit chunk format. A very logical way of storing information in files. Doesn't really have anything to do with IFF since such a chunk format isn't that hard to "accidently" invent....

@tboeckel

Quote:

A new version of MUI, or a new version of Ringhio?

@vox

I so miss Dopus Magellan for OS4!
What happened to it?!? Guru Meditation should have it but it seems they just buried it which is so sad ((

DOpsu4 is sooo tiresome with its limit of only two listers. Yea, I tried Filer but it's just not there, being in the way all over WB, not having a button bar and no global hotkeys that doesn't require a qualifier.

I want a good full screen file manager and DOpus is the only program that can do it for me.

@Elwood

Are you a beta-tester with access to the fixed USB driver/thingy? If not, we will of course have to wait until the next OS4 update.

If you are a beta tester and you can still reproduce some kind of bug, even if not exactly the same, it means I'm right and CrashDOSfilesystem does have a bug too.

Still, better with one bug down than none

@Daniel

MakeCD can do it on-the-fly if you have the CPU power for it, that is, a PPC.

Otherwise you can use CodeAudio, close the wizard, flip to the Mpega page. Click "Use list", add your mp3s, enable "Write output file", select AIFF or WAV, choose an output path, select "Diable audio" and click "Play".

Now you will have plain AIFF or WAV samples that you can burn directly as an audio CD.

@salass00

Quote:

Ah, didn't know that. Even easier then

On second thought I guess mplayer uses either stdio or unistd which might not be 64-bit compatible yet..?

@drHirudo

Quote:

I think the player itself it stream based and will play forever. However, the file model needs to face the facts and bites the dust when it comes to *seek* into the actual file, even if it may be able to hold the size of the stream. Reading can be done incrementally though, just like my 68k programs BackUp and JoinSplitter which are plain 32-bit but still can handle large files.

Should be easy to fix though. For backward compatibility to OS4.0 a simple if(os_version) statement could be used to choose between GetFileSize and Examine in mplayer.

@joerg

Quote:

So the NPAPI is implemented and working but disabled in the OS4 verison of OWB??!??! Why on earth would you disable it if it exists and is working. To me that hardly seems like a good way of encouraging progress.

Perhaps I misunderstood "plugin" completely. Maybe an OWB plugin cannot ever be a stand-alone file on disk (an actual plug-in) but has to be compiled in in its completeness (by you then). That would require a pretty close cooperation between you and afxgroup I suppose.

Quote:

If that was trivial it would have been done years ago. So, clearly not trivial. The hard part may not be the compiling part then of course, but political, stubborness, boredom, whatever. I don't know, that's why I started this thread.

However, it is said to be too slow to have it enabled and I get that. But what if the user could enable it manually for the places he wants to prevent it from loading heavy ads everywhere. "Right-click: Enable Gnash here.".

Quote:

To draw in an Amiga window you need the rastport or a layer or something. You can get that from a MUI window and a custom class would provide the area x,y in which to draw. I do this in Detris and DeeJay'D. In MultiRen I use stand-alone files as plugins. They don't draw graphics though so don't really have to touch MUI.

Anyway, is there any docs of this NPAPI that I can use to test something, or would it have to be compiled in as I asked earlier?