Messages

1

Angstrom & OpenZaurus / ATI IMAGEN (w100) Specifications

« on: September 02, 2004, 02:42:36 am »

He said "further support". Nowadays they have support for bitblt and some other operations. Anyway, with the specifications, I think that the way to go is upgrading the kernel w100 driver, perhaps with some IOCTL operations to perform all the required primitives. This way, the driver would be usable for every ROM/distribution/flavor of X/QT/text/whatever system we want to develop.

So, anybody with good english skills could be so kind to redact a preliminary version for our "letter to ATI". Once this draft is made, we could contribute with ideas, for example, benefits for ATI if they open the code (a better driver, for sure).

2

Angstrom & OpenZaurus / ATI IMAGEN (w100) Specifications

« on: September 01, 2004, 01:11:26 pm »

AFAIK that page that Psycho linked is not based in reverse engineering, but in observation of the kernel driver for the w100 and other ATI cards with programming similities. Unfortunately, it's far from complete (no bitblt examples nor specifications for example) and the author is missing (I asked for it to the page maintainer and he didn't hear nothing from him for a while).

On the other side, we have to difference two things.
1.-The real access to the card, or the real API that ATI provided (with that SDK I suppose) is a bunch of C functions embedded in the libqte shipped with the Sharp ROM. Those starting with AtiCore (you can see them using   objdump -T libqte.so | grep Ati  )
2.-What I found to be buggy is the libqte.so itself. I don't know if it's a bad usage of the AtiCore API  or another mistake. Perhaps we will never know. The problem (there's an old post about it) is trying to render QPixmaps generated from a QImage tranformed using a QWMatrix.

What people from pdaxrom make is linking this libqte against their Xserver (and using directly AtiCore based on tracing the use of the functions on the original libqte). I think that Sashz was trying to use a dll with the Ati Core (with a wine dll loader, I think) to avoid loading all the libqte stuff.

Could the AtiCore bunch of functions or one of this dll be used on the Openzaurus stuff? Or will it be not legal?
I don't understand that technical limitation of soft-float linking, Mickeyl?

3

Angstrom & OpenZaurus / ATI IMAGEN (w100) Specifications

« on: August 29, 2004, 10:35:56 am »

Hello.
One of the reasons that avoids me to upgrade to OpenZaurus my C760, is the lack of a driver for the 2D/Video features of the graphic chipset on our Zaurus machines.
ATI is not releasing specifications for that chip, and the only QPE implementation that is using the 2D hardware features (bitblt, fillrect,...) of the chip is the libqpe.so bundled with the Sharp ROMS (anyway, it's a buggy implementation, and crashes using some qte operations).

I think that those specifications are a very important step to make Openzaurus really usable (at least for people running emulators and games). I also think that perhaps was a good idea that all the OZ community represented by a leader could make a petition for that information to be released (perhaps ATI gives more credibility to such a petition that one from a single person).

My english (as you can read) is pathetic. So, we'll need that someone with more english skills (that's an easy to reach requirement) will write a petition, informing about the advantages for ATI if the sources were released (better driver implementation, good publicity about their chip,...)

Then, after the letter was approved, someone could send it to ATI.

What do you think?

4

Software / Problem with SCUMMVM

« on: July 11, 2004, 07:49:32 am »

No idea about that 'w' option. I've checked the 0.5 cvs version (the older one I have) and there's no rest of that. Perhaps you can configure it in that frontend of yours.

And, anyway, what's the problem with the scummvm native frontend. I think it's great, with that retro appearance. ;-)

Regards.

5

Sharp ROMs / Problem with self-compiled kernel

« on: July 03, 2004, 07:25:47 am »

Hello. Trying to add a patch for the ATI Imageon 100, I've compiled a new kernel for my Zaurus c760. I've used some patches available in the network. After this, the kernel seems to work fine, but suspend/resume with the power button leads Qtopia to a very unestable state: it works extremely slow. It happens everytime I try to suspend/resume with the power button.
Any idea? Do I need to apply another patch?

Thanks.

6

Software / Will this let us play King\'s Quest on the Zaurus ?

« on: July 02, 2004, 02:53:18 pm »

Hello.
I was looking at the patches in that page you said. What I've found is that they relay in a kernel patch for rotating the framebuffer, so the blitting operations are no needed to rotate the surfaces to go on the screen.
I applied that patch to the Sharp kernel sources and compiled a new kernel for my c760. Now, I have the /proc/drivers/w100/rotation entry needed for this DIRECT_FB to run and also the w100_init_vga_rotation driver function to rotate vga modes (the original driver is only able to rotate QVGA modes).

After this, I applied the SDL patches manually on my zports SDL, and the speed was increased, not as spectaculary as yours:

# export SDL_FB_DIRECT=0
# ./testsprite
SlSharedManager: can't get proc entry
Display size = 480x640
QT_GetMachine: /proc/deviceinfo/product is 'SL-C760
'
 detected machine is 'Sharp SL-C760'
QT_GetRotation: Read spec from '/tmp/qtembedded-zaurus/QtEmbedded-0.spec'
 spec is 'Transformed:Rot270:Vga:0'
 Rot=3, Qvga=0
QT_SetVideoMode: SL-C700 Style is Input style
Your kernel is Special kernel
FBVideoMode: 640x480
QT_SetVideoMode: argSize=640x480
QT_SetVideoMode: qteSize=640x480
QT_SetVideoMode: fbSize=640x480
QT_SetVideoMode: qteRotation=0
QT_SetVideoMode: userRotation=-1
QT_SetVideoMode: sdlRotation=0
QT_SetVideoMode: qteKeyRotation=0
QT_SetVideoMode: sdlKeyRotation=0
Screen is at 16 bits per pixel
Screen is in system memory
Sprite is in system memory
Sprite blit uses RLE acceleration
27.98 frames per second
SlSharedManager: can't get proc entry
Display size = 480x640

# export SDL_FB_DIRECT=1
# ./testsprite
SlSharedManager: can't get proc entry
Display size = 480x640
QT_GetMachine: /proc/deviceinfo/product is 'SL-C760
'
 detected machine is 'Sharp SL-C760'
QT_GetRotation: Read spec from '/tmp/qtembedded-zaurus/QtEmbedded-0.spec'
 spec is 'Transformed:Rot270:Vga:0'
 Rot=3, Qvga=0
QT_SetVideoMode: SL-C700 Style is Input style
Your kernel is Special kernel
FBVideoMode: 640x480
Direct paint mode
QT_SetVideoMode: argSize=640x480
QT_SetVideoMode: qteSize=640x480
QT_SetVideoMode: fbSize=640x480
QT_SetVideoMode: qteRotation=0
QT_SetVideoMode: userRotation=-1
QT_SetVideoMode: sdlRotation=0
QT_SetVideoMode: qteKeyRotation=0
QT_SetVideoMode: sdlKeyRotation=0
Screen is at 8 bits per pixel
Screen is in system memory
Sprite is in system memory
Sprite blit uses RLE acceleration
34.46 frames per second
SlSharedManager: can't get proc entry
Display size = 480x640


Anyway is a good speed increase. Is not good enough to play Toppler at 640x480, but we are on the way. I was testing some scummvm games and they seem to work fine. Perhaps I include this patches on the next zports SDL release, but I'm afraid to break the support for some models, I don't know. Also, the need of the "special" kernel to get the speed increase is a problem.


I was thinking that perhaps the solution is try to improve the framebuffer w100 kernel driver, and including functions for blitting and so on (using the hardware capabilities of the w100), if ATI only will release the specifications. :-(


Anyway, cmisip, thanks for the info. ;-)

7

User Request for Applications / GDB

« on: June 24, 2004, 09:20:46 am »

When you get that real-time event, just type

cont

the program will continue running. That's what I make when debugging sdl based programs.

8

Qt/Qtopia / Problem trying to paint a QPixmap

« on: June 24, 2004, 07:26:58 am »

Remembering, I think that I asked you in the irc channel some months ago about this same problem.

Well, all this, as you posibly remember, was focused to get 2D acceleration on the libSDL.

Perhaps could be possible to add 2D acceleration to Opie. It's the next step we could try, I've seen that somebody has made some work using the linux imageon chip driver at:
http://www.mnementh.co.uk/docs/imageon/

also, the author(s) says that all this work is based in the GPL linux driver. So, I suppose it could be used in Opie with no license problem.

Implementing in libSDL direct calls to the hardware to get acceleration is not possible, because I've got conflicts between libSDL and QTopia. We'll need an opie accelerated version, I think.

I also remember that you talked me about some effort to get the code from imageon driver free. Any move on that direction?

Regards.

9

Qt/Qtopia / Problem trying to paint a QPixmap

« on: June 24, 2004, 03:57:14 am »

I see that the last post is from Myckeyl, but I'm not able to read it. Myckeyl, could you please repost your answer? I'm impatient. ;-)

Perhaps some little leak on the forum migration, but some threads are notifying more posts than they really show.

Regards.

10

Software / Problem with SCUMMVM

« on: June 23, 2004, 04:26:01 pm »

Strange. The index said that I was the last one posting on this thread, but after opening it, I see that the last one is yzord's.
Anyway, I've uploaded a new scummvm version where I've included right button emulation. After looking at the code, I would say that it was never supported. What I've made is look for the shift key modifier to convert the tap to a right button event.
I've tested it with BASS and it seems to work.

Your feedback will be welcomed.

11

Software / Will this let us play King\'s Quest on the Zaurus ?

« on: June 21, 2004, 03:37:32 am »

Scummvm zport is trying to set the video mode to 640x480. That\'s why is not working on your 5600, and that\'s why the version is 0.6.0-zports_c7x0-4.

Anyway, the libSDL is still not detecting your 5600. I don\'t know why. I\'m starting to think that perhaps sarien is using a statically linked libSDL. Psycho, could you throw some light on this? I\'ll also take a look at the detection code, but with that /proc/deviceinfo/product it should be detected as a 5600 correctly.

Regards.

12

Software / Problem with SCUMMVM

« on: June 20, 2004, 03:39:40 pm »

Strange. Anyway the pld instruction is used to optimize memory access as a hint for the processor, telling it that an access to that memory address is expected.

You can:
  Take that lines out because that file is not being used now.

Anyway: it\'s working for me. Perhaps we\'re using different compilers.
 What line is make using to compile that file (SDL_blit_arm.S) ?
  What version of cross gcc are you using. For me:

$ arm-linux-gcc -v
Reading specs from /opt/Embedix/tools/lib/gcc-lib/arm-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)

Regards.

13

Software / Problem with SCUMMVM

« on: June 19, 2004, 01:40:48 pm »

You don\'t need the configure script. Actually, CVS code usually doesn\'t include a configure script. I don\'t have now the sources at hand, but, isn\'t there an autoconf.sh? Just run that autoconf.sh and them run configure.qtopia.sh (just a wrapper for configure to set some environment variables).
That Blit32 function failing in your link process is one of the assembler ones I wrote for the speedup. I\'ve taken out those calls in the updated CVS repository. Anyway, the problem was your \"copy over\" of the 1.2.7 version, because its automake stuff has no references to that Blit32 function.
My advice is: do it with the CVS using the autoconf.sh (or autogen.sh) I don\'t remember now. If you have any problems, tell me, and I will try a configuration from scratch commenting all the steps.

Regards.

14

Software / Problem with SCUMMVM

« on: June 19, 2004, 12:54:14 pm »

The 0.6.0-zports_c7x0-3 was really the brief zport ever known.
I\'ve uploaded a new version (0.6.0-zports_c7x0-4) with Simon the Sorcerer working. The problem was again an alignment issue of the compiler.

Enjoy.

15

Software / Problem with SCUMMVM

« on: June 19, 2004, 12:00:25 pm »

@datajerk: You can download the source code from the zports CVS.

@everybody: I\'ve just uploaded a new scummvm version (0.6.0-zports_c7x0-3) with Beneath a Steel Sky working (at least I was able to see the presentation of the floppy version, and to be shooted by a guard).
 
The bug was related with the compiler, I just had to force an struct to be \"packed\". The strange thing is that with the same compiler version, but for x86, there\'s no such bug or \"feature\".

Regards.