@Elwood

It's not officially released yet...
Only for you who are already users
The archive and some docs must be finished first.

@Chris

I think you'll get used to it
The good thing now is that you can make the window tall to fit the screen so you can see many more of the options than before when you were always locked in on one page. The smallest size of the window is also smaller now so it may fit on a 640x256 screen for those still on ECS/AGA.

And you've got to admit the gadgets are grouped a lot more logically now. I have also made some more logical connections between the gadgets so more impossible combinations are excluded now.

@Ricossa

Oh, someone noticed, and liked it! I must say I feel quite pleased

Note though: It is required to have the check for automatic updates enabled for it to detect a new version _automatically_. Otherwise you can always do a manual check from the menu.

@CountRaven

I also had problem with AmigaAMP crashing on exit but I haven't seen this for ages on either OS4.0 or OS4.1.

I use the OS4 engine and set the config to AmigaOS4 (External), AHI unit 0 and use a plain skin.

Doesn't U-Boot default to 1024x768@75Hz or something?

Try changing the screenmode in Workbench to 640x480@60Hz, then reboot with this screen and wait until it (should) display Workbench and see if that works.

Or well, just check the specs...?

@TSK

I also get gfx distortion, i.e. uncleared screens. I have seen it on DOpus textviewer two pixels below its menu there are random pixels and when I open PicShow as a flash before it opens its black window ontop of it.

Tried ImageStudio, it has had clearing problems all the way since A1200+BVision where I had to grab a window and "paint" away the wrong backgound screen colour. I tried it with different resolutions and 640x480 it got an incorrect background which I could paint away, but with 1680x1050 it became all garbage (i.e. not the same colour) including the window contents(!) after I switched screen mode! I could paint away most of it though.

Normally running 1680x1050x32 on Radeon9250 A1XE/OS4.1 but think I noticed it on OS4.0 too.

@Chris

> External launchers like that are nothing new ...

I know. I just thought it wasn't explained clear enough why OWB itself couln't display a splash.

We in Amiga-land are not used to apps taking more than 1/10 second to load, unless loaded from a loud floppy where it is obvious when it is still loading...

Most apps having some kind of startup message on Amiga usually start the exe very quick but then takes a while to load data files. YAM and IBrowse are examples of that....

@BillE

Quote:

The thing is that OWB cannot open a splash screen if it is not running! It takes all this time to load and start the actual executable OWB. OWB itself isn't running until right before you see its window. Not until then can the program do anything, like opening a splash. Then it'll be a bit too late..

It takes all this time because 1) the executable is huge and takes a while to load, but mostly because of 2) all the .so file needs to be loaded (and they are also huge) and then they need to be linked by the OS before execution can begin.

An external splash loader is the only way to solve this.

@Rogue

Nice! Thanks

Now it just would be nice to be able to put this in something else than a PCI slot

@ZeroG

Quote:

Uhh, so that's why I only have around 50MB of gfx mem free on average! Well, good then, so the compositing is actually only using about 80MB, not 200MB..

@Hans

This looks cool!
How far off is 3D once 2D is working as with a Radeon9xxx?

Would it be possible to use the 66MHz slot in the AmigaOne if one removed the AGP card?

Would a fast gfx card be faster in a 66MHz PCI slot than a slower gfx card in an AGPx2 slot?

AGPx2 is like 66MHz DDR IIRC, no? = twice the speed of PCI 66?

@RacerX

That looks quit OK, yes.
My swap is at the end of the disk though, not efficient at all, but that's where I had the room for it... :(

But as someone mentioned, having the swap on a different driver would bet the best. I was thinking about that, but since I often put my second (mostly backup) driver to sleep, it wouldn't be smart to have the swap there, even if it will rarely be used.

@tonyw

I believe that HDs will use all surfaces at the same time in parallel to increase speed. With four surfaces you get a fourfold speed increase AND lower seeks since more data is avaiable "vertically" on the same cylinder rather than "horizontally" over several tracks.

I don't have facts to back this up, but it would seem most logical to me.

@RacerX

My experience is that it is most efficient to put the swap partition as close to the partition mostly used when you normally run out of memory.

To simplify:
Put Boot/WB partition first.
Then swap.
Last Work: or other large partitions which are not accessed in their completeness very often.

This makes the head swing the shortest way on average since the swap and boot/WB and beginning of Work: are closest to swap.

If you put it like this:
Boot/WB/programs
Work: (large)
Swap (end of disk)

..the head would need to swing all the way over the large Work: partition everytime you load a program and run out of RAM:, then back to WB to load some more, the over to swap, then back to WB etc.. lot of swing and tear of the drive and slow swapping.

@Swoop

Vcore is short for Voltage in the Core of the CPU.

Setting it too low will cause the machine to become unstable and crash or lock up randomly. Often during boot I have noticed... the CPU will run very cool though.

If you set the Vcore too high you will overheat your CPU and typically get lockups randomly. If you set it way too high it will fry and never work again.

When you overclock a CPU you typically also need to raise the Vcore to compensate for the shorter (and hence smaller) clock/data signals in the CPU.
Problem is that the both a high Vcore and a high clock frequency raises the temperature (and power requirement) of the CPU, and combined the increase is multiplied. That is why it is so easy to burn a CPU when overclocking unless you have massive cooling and made sure it has a good contact with the CPU.

You could try undervolting and see if it helps. If the CPU runs hot, lower the Vcore might be the cure.

@Atheist

What the *ell is Brandy..?!
Use a real language instead

@joerg

Just a small update on this:
I *think* I get these ISIs on startup (either before or after the window has opened) if I move the mouse while it is starting!

Since I never start OWB from shell, but from the icon or IBrowse I tend to move the mouse after launching it.

I need to confirm this, but I did notice two crashes when I moved the mouse a lot, and one correct start when I didn't move the mouse at all.

First I thought it could have to do with if the mouse is over the window when it opens, but it leans towards mouse move instead perhaps....

@Severin

Perhaps a new hotkey (or menu item+hotkey) could be assigned so that it doesn't collide with the Ctrl+double-click->scroll?

@LiveForIt

Quote:

If I may reply on this quote, electronic hobbyist with some knowledge as I am :)

The main problem with designing something fast and modern is not the logic, how to get all the signals correctly connected between all chips and stuff. I'm sure this guy can logically design what you propose (CELL, 2GB RAM etc.). I might as well be able to do it.

The main problem is to get the electrical characteristics correct. At one GHz and above it is for example absolutely crusial that all wires from the memory controller to the actual RAM chips have exactly the same length (which must also not exceed some maximum of a few centimeters). How do you solve that with 64 wires of data, 32 wires for address, and a few others??
You must also have a compatible impedance for both the controller and the RAM chips, otherwise you get either a too weak signal, or signal reflection, with memory errors as a result. The impedance depends on lane width and how close it is to earth planes etc. (Do we know about a computer which has trouble with this..? Yes we do, it's called AmigaOne, and its RAM only runs at 133MHz.. ).

At these frequencies all signals emit quite a high level of radio noise as well resulting in cross-talk and bad signals. This must be taken into the equation too about where you can route the signals on the board, how many earth planes you need to cancel out noise etc. etc.

You need a very advanced autorouting PCB tool to accomplish this unless you're extremely good at it.

Take a look at a modern motherboard (the AmigaOne will do) and you see that a lot of signals, expecially around the RAM and CPU, are routed in zig-zag for no apparent reason. Well, the reason for this is to keep all lanes at an equal length. And, as I said, that's just one aspect.

If I may add to this:
The only downside of SFS is that there is no data recovery tool. But there is no need for such a tool IMO! The most probably cause of data loss is accidental deletion of files, and there is the .recycled undelete function for that, or the HD may physically crash and there is no recovery from that, other than to have a backup. FFS is no better at reading a destroyed disk than SFS, or atleast not better than PFS. That I know.

I have used PFS 2&3 for many years on my A1200 and now SFS since almost the beginning on my A1 and I find them very similar in speed and reliability.

I have never had any problem at all with any of them. There have been rare occasions when I have gotten a strange requester about some incorrect block with SFS but never any data loss.

Not only are PFS and SFS much faster and more reliable (since you don't loose data by accidental reboot or crash during writes, except for that which was just currently written), but they both have this .deldir/.recycled directories where you very easily can "undelete" files from, and not just the last deleted or overwritten file, but many versions back too!

I have SFS on all but one partition. Don't know why I left one as FFS2 really, guess I was unsure in the beginning. I will soon install SFS2 on my largest 150GB partition as I recently got a DVD burner.

@tonyw

I'm not exactly new at programming so I'll probably figure that out.
Thanks anyway!
(unless there are some tricky pitfalls you know about that are common to fall into!)

@joerg

Ok. So since the program compiled when configured for 64-bit it expects normal fopen, fseek etc to return 64-bit sizes, which won't work at all then..?

So: Do I wait for a new SDK (how long?) or do I replace all file I/O functions with AmigaOS 64-bit calls?