@tonyw

Quote:

You got a point there ;)
Maybe hot-swapping would actually work, although unmount/mounting has to be done manually.

@AmigaBlitter

Looks like normal bitmaps. Compositing should be able to handle most of these formats I presume. At this time there is probably some incompatibility between the surfaces most SDL programs use and Amiga, so a software conversion has to be run before the bitmap is blitted.

I don't know where this conversion happens. Maybe there is a manual copy/conversion from SDL to an Amiga bitmap somewhere that is actually unnecessary, but added for maximum platform independence. It would probably be possible to use a blitting function here for most cases, or maybe even skip this step completely, just put it on a composition bitmap and off it goes. Don't know the abstraction inside SDL, but it's probably quite high so lots of conversions and layers needed to go through.

@samo79

+1
Better spend a fraction of the time on Odyssey. It just needs a new webkit and it's all we need.

Seems the problem is in the SDK; the compiler being too old to compile webkit with its C++11 feature requirements.

Without having any idea how SDL works, I'd say: Sure, that's possible!

Hi

Since SATA is hotswap compatible I though I'd just put in my backup disk while my X1000 was running, but it was nowhere to be seen. No lockup though (unlike with the A1-XE PATA ).

I wasn't expecting it to popup like USB, because I know fixed disks are not hotswap compatible in AmigaOS, but I was still hoping to manually be able to mount it with mounter or something. Unfortunately it was nowhere to be seen, not even after a softreboot the disk still did not appear on the sb600sata.device. I had to do a slow annoying cold reboot to make it appear.

Aren't the disk drivers supposed to scan the bus on (soft)reboot? What about MediaToolbox? I though it would scan all ports to detect new devices.

Anyway, after making my backup I unmounted all partitions and pulled out the disk. This was a few days ago and the machine is still running without a second reboot, so that's good

Conclusion of SATA hotswap:
- Hotswap without power down/up: OK.
- Hotswap as in mounting a new device without (cold) reboot: NOT OK.

Yeah... Guess I'm just desperately dreaming a little here... Too bad everything modern should be so damn complicated and hard to implement and use. And of course, everything has to be secret (no docs).

Doesn't get less frustrating by me having run out of time an enthusiasm for coding a couple of years ago, after nearly 20 years of hobby-coding...

@Hans & LiveForIt

Yes I know it's a lot of work. It always is But there is no device in the world today that doesn't use HW decoding for mainly h264. All phones, tablets and laptops do HW decoding. My Surface actually refuse to play any video formats it doesn't have HW for! I can't play plain mpeg2 for example.

Is it really that secret and exotic to make it a reality? We only need h264 and we only need it for Radeon.

But Hans, what do you mean by "there's a lot of software that needs to be ported/written/updated in order to do so"? There is only mplayer that needs this primarily, with support in your Radeon driver probably.

@tommysammy

Quote:

I have a couple of green videos with, what I believe is the latest version. One version from last year that only has the comp driver works without being green in those videos. Otherwise it seems quite bug free, yes

Maybe I missed a new version very recently?

@LiveForIt

Quote:

Why can't we use this hardware acceleration then if it exists instead of finding a slow SW version?!??!

Addressing PCI space isn't that different on Amiga that it can't be done..?!

@Spectre660

RAM disk can be pretty slow. Try from a fast and modern SFS formatted disk. Could be faster. Especially in the old days, RAM disk was dead slow. A UDMA harddisk was much faster.

MorphOS has done stuff to improve the RAM disk speed, so has OS4. Maybe MOS got it better? But check the mplayer config etc first.

@hotrod

About the memory usage: Webkit caches all memory it uses. It never frees anything back to the system, but if you close one tab and open another, the memory will be reused.

It would be very nice with Load-on-click for tabs when restoring a session though.

@Atheist

Yeah, I agree, that's pretty slow. However, I usually see speeds faster than that when copying only big files. 50-60MB/s *copy* speed is not uncommon, especially on my main disk which clearly is faster.

It's unclear where the bottleneck is. If it were anywhere in the OS we would see high CPU load, but CPU remains low, so maybe unfavorable DMA read/writes? Polling delays?

@ChrisH

So you had this problem for a long time while never rebooting the machine? The mediaplayer in Odyssey is buggy and causes memory corruption. If facebook or any other site "accidently" or intentionally played any video, the system should be considered unstable and normal crashes should be disregarded until reproduced without running Odyssey. IMHO.

This looks a bit like a simple regexp pattern matching. The link you clicked probably contains some of the keywords in this line.

Maybe that's why some links just fail to work for me to in random places!

@yoodoo2

What happen if you rotate the monitor, then reboot (with "Detect settings automatically" selected in ScreenMode prefs?

Or: Rotate the screen, then create a new screenmode with the swapped parameters. You can have two screenmode.prefs files saved and all you need to do is to copy one of the files over ENV:Sys/screenmode.prefs and it will use the new settings immediately. (I did this for AHI.prefs and WBPattern.prefs.)

The monitopr will have roatation sensors and tries to tell the computer. The Amiga won't listen of course, but if you rotate the screen, then copy the new screenmode.prefs it should sense that it has a new rotated screen and display it correctly.

(I need to try this, I also have a rotationable screen :))

@logicalheart

I have a 4k drive in my X1000 (I'm pretty sure).

I have several partitions on it. I just tested copying 383MB of mixed files (some code and some music) from RAM: to one SFS/512 partition and one SFS2/4k partition.

Copying to the 4096 block size SFS2 partition was about twice as fast, at 40.7MB/s vs. 20.3MB/s to the SFS/512 partition. Note: This disk is a 2TB WD Caviar Green energy saving disk, so not optimally fast.

Anyway, I don't think SFS2 is that much faster than SFS1, much rather does the 4k block size make it faster than using 512 byte block size.

When I created the partitions I was very careful to place the partitions on a 8-cylinder boundary, assuming Partition Wizard thinks in 512 byte terms. So if you know what you're doing, you can take advantage of the 4k drives on Amiga as well

Hi,

Just wondering what the js limitations are of our Odyssey (1.23 for OS4) and what possible improvments we still don't have.

I was just trying to use web.skype.com but it doesn't work. Seems it just stops processing in the middle of some java-script.

I looked at the source and saw this file: main.js and it is obfuscated and is on one or a few veeeerry long lines.

Does Odyssey/webkit have a problem with super long lines of js or something?

@amigakit

Quote:

I know! These are great steps forward!

I enjoy the composited display acceleration at least weekly. But the raw power of the (single-core) CPU is simply not enough to decode 720p h264, as encoded by my phone or my action camera. I have to (spend hours) re-encoding to mpeg2 to watch the videos, but thanks to compositing I can keep the HD resolution.

Don't use 3D very much though, and I have the wrong card apparently, a RadeonHD 6xxx. Southern Island is 7xxx, isn't it?

@Srtest

My arguments for more power is to be able to play HD videos. The X1000 currently cannot play normal HD videos with the normal HD codec, h264. Also, any web browsing that includes more than a little javascript is very slow.

Of course there two problems could be solved by HW video decoding by the gfx-card and javascript-JIT. But will we ever get any of those things?

We need more power

600-700MB. And I agree it's not low memory, but maybe if some calculation was wrong, maybe then it calculated it to be low. It was not with the latest version. I'll try with the latest version.

Btw. It's pretty much always when using Odyssey that the crash or lockup happens in some random place when memory goes down to 600-700MB free...

@Raziel

Quote:

There's no "left behind" function. The mouse is always at the top of any display. It has to be switched off manually in code. There is obviously a bug that only switches off the mouse pointer when you switch to full screen, but not when starting in full screen. LiveForIt could fix this easily, if you write a bug on the database site.