Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
86 user(s) are online (51 user(s) are browsing Forums)

Members: 0
Guests: 86

more...

Headlines

Forum Index


Board index » All Posts (COBRA)




Re: Picasso Bug ??
Not too shy to talk
Not too shy to talk


@Wol

Quote:

Not when the other screen is displayed on the other video card it isn't. This never happens with CyberGfx

Well, I used Cybergraphics both on a CyberVisionPPC graphics card, and a PicassoIV graphics card under 3.9 and it did not have screen dragging capability, like OS4, e.g. I could not drag a screen down to reveal the other screen behind it. MorphOS also uses Cybergraphics, and until the very recently released MorphOS 2.0 it did not support screen dragging.

Quote:
I was expecting the Picasso RTG system to be as capable as CyberGfx RTG system, but it seems Picasso has major design flaws and will never be able to handle more than one GFX card.


That is incorrect. You did not listen to what I wrote before. The screens are handled in a list by Intuition. Not Picasso96. Under AmigaOS, intuition handles the screens, and when you drag a screen down to reveal another one behind, that is handled by intuition.library. It is a limitation of intuition.library that it only keeps a single screen list, not separate screen lists for each graphics card. When you drag a screen down, intuition will look at which screen is behind it in the list of screens, and it will copy the contents of that screen to the area which is revealed by the dragging. It does so, without knowing physically on what graphics card that screen resides on. Picasso96 does know of course which graphic board each screen belongs to, and intuition could even get this information from P96, but it doesn't.

Basically, intuition is completely ignorant to having multiple displays simultaneously. Simply because it was not designed to handle that. That is why, for instance when you have 2 monitors side by side, you cannot move the mouse over from the left screen to the right one, or you cannot move a window over half way between the two screens. These are all design limitations of the original AmigaOS, which will of course be addressed in future versions. Some of them can be overcome by adding patches here and there, which is what both CybgerGfx and Picasso96 were doing, but a proper solution would be a major redesign.

Quote:
And somtimes when opening a new screen, it displays it on BOTH video cards at the same time...Insane..


You will have to give me more specific information from that. So far you haven't even told us what graphics cards you're using, what drivers you use with them, where you got those drivers from, etc, etc. There is no way to figure out a problem without having such information available.

Go to top


Re: Picasso Bug ??
Not too shy to talk
Not too shy to talk


@Wol

The problem is I don't know anyone who has a classic and uses multiple gfx cards, it works if you have two gfx cards on an AmigaOne... Can you give a bit more details? E.g. what monitor drivers do you have, where they are from, etc.? Also, what do you mean by screen cycle gadget? Does the same problem (e.g. monitor turning black) happen if you use LAmiga+M to cycle through the screens?

The fact that when you drag down a screen and it reveals the screen behind is however quite normal. AmigaOS never had real multi-monitor support, meaning that it maintains a single screen list, not a separate screen list for each graphics card. So if you drag a screen down, the one behind it in the screen list becomes visible, regardless of which video device the screen resides on. Intuition does not know, nor does it keep track of where physically each screen resides (e.g. what graphics card, that is completely transparent to intuition). So when you drag a screen down on one gfx card and you see the screen on the other gfx card behind it, what you're seeing is a limitation of the original AmigaOS design. The whole AmigaOS graphic system needs to be thrown out and replaced by something more modern, which would allow multi-monitor support as nice as what MacOS has, and that is planned.

Regarding screen switching, that is fast as long as your bitmaps fit into videomem. As long as the videomem runs full, the graphic system has to start moving graphics in/out of videomem. That causes slowdowns. Since OS4 uses a lot more graphics than 3.x, it means your videomem will fill up more quickly. However you can activate a much simpler GUI theme without all the fancy stuff, and you'll find that things will get quite a lot faster on a classic.

Go to top


Re: NTFS driver for OS4?
Not too shy to talk
Not too shy to talk


@pvanni

So consider I have installed the NTFS driver and the TD64 patch, how would I go about mounting a partition on a PC hard-disk with it?

Go to top


Re: NTFS driver for OS4?
Not too shy to talk
Not too shy to talk


@thomas

That's only for 3.x and MorphOS though, and only allows reading. As far as I can tell it's not based on the NTFS-3G project?

Did anyone try that under OS4 btw?

Go to top


NTFS driver for OS4?
Not too shy to talk
Not too shy to talk


Hi,

Would anyone be interested in porting this to OS4?

http://en.wikipedia.org/wiki/NTFS-3G

It already exists for the following OS'es:
Linux, Mac OS X, FreeBSD, NetBSD, Solaris, BeOS, Haiku

Would it be difficult to make an OS4 driver out of it?

Go to top


Re: AmigaOne U-Boot bugs - please read
Not too shy to talk
Not too shy to talk


@LyleHaze

I have the same optical drive, yes this is an issue with that particular drive. I was helping to debug this with Stephane Guillard (the guy who developed the IDE drivers), it seems that in DMA mode the drive puts something on the IDE bus that it's not supposed to, messing everything up. The sad thing is that even the latest firmware of the drive does not fix it. I don't know how they solve this in other OS'es, either they only enable DMA after drive initialization, or they have some other workaround for particular misbehaving devices. Last time I talked to Stephane about this, he didn't like the idea of putting workarounds into his drivers, but I'll ask him again if he could have a look at this.

In the meantime, the solution is to put some lines into the beginning of your startup-sequence to enable interrupts, that works for me.

Go to top


Re: Sam440ep memory module type?
Not too shy to talk
Not too shy to talk


@Valiant

You can, but I can't imagine for what you would need more than 512MB on AmigaOS...

Go to top


Re: Overlay with CV3D and DVPlayer (OS4.0 Classic)
Not too shy to talk
Not too shy to talk


@Amigamancer

On a BVisionPPC or CyberVisionPPC it is slower than 16-bit RGB, because those cards do not actually have overlay capability in hardware. Instead overlay is "emulated" by using the 3D engine of the GPU, mapping a texture onto polygons, and drawing the polygons many times per second. This is why it slows things down on those cards. On all other cards there is proper hardware overlay, and it can really speeds things up.

Go to top


Re: Overlay with CV3D and DVPlayer (OS4.0 Classic)
Not too shy to talk
Not too shy to talk


Well, I believe the source of the problem is that DvPlayer uses a custom GUI inside the window, apart from the overlay, and this means DvPlayer must fill part of the window with the colour of the colorkey, to make the overlay visible. This requires DvPlayer to know what colour to fill that part of the window with, and querying that colour was not previously implemented in older drivers AFAIK. Thus the drivers have to be updated to support this new functionality. If you use a player, which opens a simple GUI-less window, then you can rely on P96 to automatically fill the window's interior with the correct colour, in which the overlay is visible.

I do have an A4000 with a PicassoIV, but I don't have a working CSPPC card on it to test this problem with OS4 to get to the bottom of this...

Go to top


Re: OWB 2.11 !!
Not too shy to talk
Not too shy to talk


@pvanni

Quote:

pvanni wrote:
@COBRA
Quote:
Right now I'm very busy with WarpView 1.0

I hope you'll resolve displaying big images


Already have.

Go to top


Re: OWB 2.11 !!
Not too shy to talk
Not too shy to talk


@samo79

As I said, nothing changed in DvPlayer that would make it worthy for a new version to be released, and right now I'm very busy with WarpView, and I can't get distracted with other things, I have _very_ limited spare time...

Go to top


Re: OWB 2.11 !!
Not too shy to talk
Not too shy to talk


@samo79

Quote:
So why not released yet on AmigaOS 4.0 ?


There weren't any significant changes that would make it worth the hassle of doing another release right now.

Quote:
Great, I translate 0.9 it in italian, tell me before release 1.0, I will doing an update


Well, WarpView is not localised yet, I guess I should add locale support to it and DvPlayer at some point, so that it can be translated to different languages. But first I want to make sure that every important functionality I planned for it is in there.

Go to top


Re: OWB 2.11 !!
Not too shy to talk
Not too shy to talk


@abalaban

The most important difference is that when you have 4-5 windows stacked on top of each other with a different webpage in each one, it's really difficult to toggle between the different pages, e.g. you'd have to cycle through all of them by pressing the window depth button many times, to finally find the one you're after. While with Tabs, all webpages are just a single click away, and you can instaltly see which pages you have open at the same time. If you want to have two webpages visible at the same time on your screen side by side, you can still open a new window, and drag across a tab from the other window, to make the same webpage shown in the new window (this is with FireFox at least). So yes, tabs are important.

Go to top


Re: OWB 2.11 !!
Not too shy to talk
Not too shy to talk


@samo79

Quote:

samo79 wrote:
@COBRA

Just a curiosity, what's new in 0.67 ?


A couple of minor fixes IIRC, I don't have the HOC here at work to check now. Right now I'm very busy with WarpView 1.0 which I hope to finish some time in November, after that I can start to look at DvPlayer again.

Go to top


Re: OWB 2.11 !!
Not too shy to talk
Not too shy to talk


@mufa

No, there's only a 0.67 of DvPlayer SE version, and it does not contain anything new compared to the latest registered version v0.65.

Go to top


Re: OWB 2.11 !!
Not too shy to talk
Not too shy to talk


@sofistisoftware

Quote:
p.s.: when new version of DVPlayer ??


Not for a while, I'm working on another project currently.

Go to top


Re: OWB 2.11 !!
Not too shy to talk
Not too shy to talk


@abalaban

But OWB already has multiple windows :) Not tabs unfortunately, which makes it much easier to switch between different webpages, compared to when you have 4-5 windows open on a screen on top of each other...

Go to top


Re: OWB 2.11 !!
Not too shy to talk
Not too shy to talk


@sofistisoftware

Quote:
thanks for reply, is possible reduce cpu usage and improve scrolling in current OWB doduo ??


The main difference why scrolling in for instance IBrowse is smoother, is that IBrowse renders all elements which make up a webpage into videomem, and after that scrolling a page only requires blit operations to construct parts of the webpage, no CPU rendering is needed.

However when you have CSS support this is not so simple, because CSS pages can do things like alpha blending, etc. which for example is only possible to do in hardware using the new composite engine in OS4.1. A switch to Cairo was an important step, but right now since the OS4 port of Cairo is rather new, quite a few drawing operations are not yet hardware accelerated, which means quite a few things have to be rendered by the CPU instead. So as Cairo gets more hardware acceleration (hopefully in upcoming updates for 4.1), rendering of webpages can become fully hardware accelerated, which would allow for smoother scrolling.

However in my opinion the current speed of OWB is already very nice, and scrolling on simpler webpages is quite smooth on my uA1. I think that for animated content there could be some optimizations made still, because having just a few simple gif anims (like dancing bananas ) can really slow down the scrolling.

Go to top


Re: OWB 2.10 out
Not too shy to talk
Not too shy to talk


@pjs

The 25-entry-max popup menus is only a temporary quick solution, I'm sure it will be properly supported sooner or later, but joerg only has 24 hours in a day, so we have to be a bit patient ;)

Go to top


Re: Sam 440 Flex board?
Not too shy to talk
Not too shy to talk


The reason the Sam-Flex will not have a 460EX processor is that it would require a complete redesign, e.g. a completely new circuit to be designed. So for the Flex it will use a 440EP, and if it sells well enough, that will encourage ACube to design a new board around the 460EX.

The reason the 440EP-based boards have only PCI slots and no AGP or PCI-Express is that the 440EP only has a PCI bus interface. You can get a PCI 9250 128MB directly from ACube for 35 EUR which is not a bad price.

I don't know about the zigbee module, you should ask ACube on that, but as far as I can tell from the picture, the module has to be soldered on, so either you get one with or without it, you would't be able to add it later (unless you're good with soldering).

Go to top



TopTop
« 1 ... 5 6 7 (8) 9 10 11 ... 14 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project