Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - magog

Pages: [1] 2 3 ... 6
Hardware / Re: OpenGL ddk
« on: 2011.01.04, 03:53:55 »
After I now read the complete thread and with the basic knowledge of OpenGL plus the different implementations out there I have to say good that you ditched TinyGL. It's outdated stuff and more or less abandonware.
Keep in mind: A full OpenGL implementation is not something a small group could even pull off let alone a single person. On the other side there is also the big problem, who is going to implement something in the graphic drivers so this can be used at all. Even SciTech had problems here (they were ATI development partner)...but there are quite some open source drivers out there (but not for the latest hardware - still AMD did some progress in this area).

So what can be used?
As a full OpenGL implementation is out of question what about a subset? OpenGL ES v1.1 or the newer v2.0 version seem to be a good idea. This is what you can find in the smartphones based upon different ARM chips (TIs OMAP3xxx and OMAP4xxx, Apples A9, etc.). The devices like the Palm Pre (Plus; 2), iPhone (3GS; 4) or the Pandaboard/Beagleboard-xM (ARM based developer mainboard everyone you can buy for round about $150) have an 3D accelerator like e.g. the nVidia Tegra or the PowerVR SGX 5x0 (embedded into TIs OMAP processor). All those smartphones now use OpenGL ES v2.0.

I can't really answer the question what framework to use. For the application developer common frameworks are:
  • SDL (has also a 3D part and uses OpenGL if available) and there is an eCS and OS/2 port available!
  • Mesa3D (uses software rendering and if available also hardware accelerated 3D) at least an older eCS and OS/2 port is available (done by SciTech)!

Mesa3D brings it's own implementation and hardware implementation as far as I know and OpenGL ES v1 and 2 can be used.
This looks interesting but there is a high learning curve involved. The other "problem" is the usage of more linux/unix stuff. Drivers might use DRI2 or something else.
As I'm not into that area someone needs to look into it...seems to be Dee or someone else who as already some background and can at least some advice (e.g. the former SciTech gang: Kendall Bennett, Steve Wendt, Michal Necasek).

For the driver part:
The guy(s) who did the Panorama driver have also a driver (port) for the R100 and R200 chipsets (R100 = ATI Radeon 7000...7500; R200 = ATI Radeon 8500...9250). It would be a good idea to get in touch with the developers using the website or Roderick Klein (
Question is: Is the code for those drivers available somewhere? Would be good to get the 3D stuff actually working.

As stated above it might be possible to port more applications based upon SDL or directly Mesa3D as OpenGL (ES) implementation. With the limited acceleration and the latest progress on Java 1.6 even Mindcraft ( - which is a Java 3D application - might be working later.

There is a lot of work involved to pull this off even with only OpenGL ES! Everyone should be aware of that.

Edit: There might be some typos left...I should be sleeping since 3 hours which doesn't really help typing. ;)

Open Bounties / Re: TrueCrypt port
« on: 2010.03.14, 21:50:54 »
Andy wrote:
But, who needs an encrypted boot partition with OS/2?
IMHO Truecrypt used without boot partition encrypted is dangerous. I.e. in the swapper.dat you will find many value information of the files you want to hide.
In the end, you have to protect your boot partition also.

It may contain names of files in more or less clear form but that's not a problem as long as you can't access the file(s) in question.
The other thing is, that you have to implement additional code (basically HPFS/bootable JFS code to the TrueCrypt code) to be able to boot from an encrypted HPFS/JFS partition. This makes it a lot more complicated. Basically this feature is only a long term goal at best.

If work on a TrueCrypt port is done the basic and easiest features to implement would be sufficient for the moment (a TrueCrypt container file and the mount container file as partition function).

magog  wrote:
eNova now has an AES-based X-Wall encryption chip for SATA (X-Wall MX) but so far there doesn't seem to be a simple PCB you can directly attach to your SATA drive like it was possible with the old Abit Secure IDE solution with the DES encryption.
Looking for the same solution, I could put my hands on an piece of hardware with the X-Wall MX256. Im using this chip now fpr almost one year. It is fully transparent for all operations. [..]
If you want such a PCB with two FOBs (no, the old DES-FOBs doesnt work) PM me.

Interesting, you get a PM shortly.

Open Bounties / Re: QT 4.x framework Port
« on: 2010.01.25, 20:56:35 »
I think you are using the wrong audio output setting. As I haven't installed SMPlayer I can't tell you where to set it exactly (maybe there is a setting to allow user-defined settings).

For audio you should be able to use "kai:dart" or "kai:uniaud".

For video you can choose between:
"kva:dive", "kva:snap" or "kva:wo"

Dive should always works, snap obviously only with SNAP installed (I'm not sure if a card supported by SNAP Overlay is needed) and wo is for WarpOverlay only.

All settings can also set in a global mplayer configuration (c:\home\default\.mplayer\config).

Applications / Re: Pixel
« on: 2009.12.22, 14:14:20 »
If you read the Pixel forum you'll see a lot of other people that don't like the current status of Pixel...I could have used stronger words but I think you get the idea. ;)
The major problem seems to be "the next version will include much more features" instead of fixing the bugs that prevent Pixel from beeing used in the first place. As it's a one man show this also doesn't help the project.
Yes, Pixel could be everything we need for a decent graphic application if the core of Pixel would be more stable. You can't compare Pixel and PMView as Pixel is a painting program while PMView is simply a very good picture viewer.
One other think I would like to see on OS/2 would be Inkscape but as it's using GTK as it's base this is highly unlikely. Some parts also use Cairo (also used in Mozilla products). Maybe they move to Qt some day so there would be a chance for an OS/2 port.

Article Discussions / Re: OpenSNAP geplant/OpenSNAP planned
« on: 2009.12.19, 19:35:41 »
Forget about GRADD that's not an issue. GRADD was IBMs attempt to get more video drivers by reducing the efford needed to get a working driver. It allows to implement hardware functionality in parts. Parts not covered are done in software (--> softdraw.dll).
Best example is GenGRADD which is doing everything in software using VESA functions. GRADD allows direct hardware access which SciTech used. I don't think IBM added special functions not available in the GRADD DDK.

As I said before I'm not sure Altrichmond has access to the source code of the closed source drivers as SciTech developed them in Partnership with ATI (plus some stuff under NDA with Matrox). If they (Altrichmond) have the full code, I'm sure at least ATI had to agree (most likely also Matrox).
If there are parts in the SNAP base that might be a problem but I'm not sure that's the case.
To get more information I strongly suggest to get in touch with Kendall Bennett (directly or over Steve Wendt).
Both should be able to clear the basic questions currently discussed here (are NDAs and code developed using NDAs part of the SNAP package Altrichmond got,...). After that you have to deal with Altrichmond directly.

Hardware / Re: OpenGL ddk
« on: 2009.12.17, 20:52:46 »
Can I also be included in your mail delivery list? ;)

Done...see inbox.

Article Discussions / Re: OpenSNAP geplant/OpenSNAP planned
« on: 2009.12.17, 20:47:19 »
I don't know how many man-hours of work there is to split the source out but what they were asking for was the cost to be covered.  It may be possible for someone to sign an NDA and do some of the work to lessen the cost but I hadn't asked that at the time.

I don't know anything about the cost as I have no idea what the "split the code" is all about. It's not possible or at least not very well-thought-out to only release the OS/2 part. Driver developed should be running on all platforms otherwise SNAP doesn't make sense at all. If someone is fiddling around with the OS/2 SNAP backend modifying it would break using drivers from other platforms. Is this something they want? I don't think so.

What Altrichmond has should be only the part that can be open sources. I don't think it is possible they also got the drivers in source SciTech developed under NDA (ATI and Matrox drivers).
When it comes down to the source the best options to pick up the work are Kendall, Steve and Michal....supported by other people (whoever that might be).

Article Discussions / Re: OpenSNAP geplant/OpenSNAP planned
« on: 2009.12.17, 02:24:03 »
where is Steve Wendt now?
where does he works now?

Is there any way to contact him and clarify his statement?

Steve is working for Kendall Bennetts other company since SciTech closed far as I know no hardware stuff but business applications (I don't have up-to-date information so I might be wrong).
Michal Necasek moved on to Sun.
If you need to contact Steve look here (the dark gray line at the top):

Altrichmond(.ca) never released anything about SNAP beside that they bought the code. OpenSNAP was only something that Steve released as selling SNAP wasn't going forward at that time. When selling the tech was going forward again OpenSNAP was dead (before it even started).
So now it only depends on Altrichmond if it's possible to continue developing drivers. As Mensys already talked to them, they have to push it.

Open Bounties / Re: OpenWengo port
« on: 2009.12.17, 01:58:01 »
as soon as Qt4 is finished we may look at it closer. which does not mean we will work on it.

for me personal all depends a bit how the sponsoring of Qt4 goes further. if it stays like it is at the moment (hardly new sponsor units), i'm not that motivated to port anything i don't need.

Hi Silvan, I going to add 100 EUR within the next couple of days so +1% (Edit 1: Just placed the order for the QT4 support...).
I hope some kind of motivation will be there otherwise this has to be done using other hardware (AVM Fritz!Box Router,...).

Edit 2: I re-checked QuteCom but it seems to be update in 12 month. If VoIP (SIP) should be a target we have to look again for a working project, that can be ported. This still excludes Skype.

The only think I currently have in mind might be something attached to Jabber /XMMP or what the protocol is called. I will look into this area in about 3 month because I'm working on a project which plans to use a settop box for IP-Telephone conversions (big maybe....later even video conferencing). It's an embedded Linux system using an STMicro Chip. First tests will use cameras that stream out H.264 encoded video so for OS/2 and eCS USB supporting the Video Class interface are most likely needed.

Hardware / Re: OpenGL ddk
« on: 2009.12.17, 01:46:15 »

If you need the Hardware Accelerated OpenGL DDK...look into your inbox. ;)

Can I be included in your mail delivery list ;)


No problem you should also find something in your inbox (PDF Docs + DDK files).
I forgot to include a link to the main DDK files for the two other guys who asked about the DDK but that file is also there in the same directory. An updated mail is on it's way.

Dual Head is only possible with the SNAP driver and it's only possible with the cards listed in the SciTech SNAP readme.txt file. The original Matrox driver doesn't support it and also none of all the other drivers ...except for a driver for an "ELSA Winner 2000/OFFICE" graphic card which should allow this.
The default setup options for "Primary" and "Secondary" display of OS/2 have nothing to do with the dual head support you want.

For SNAP the IBM or standard release might not allow to enable dual head. I think you need the "pro" version. The key for that one has been released a while back after SciTech cancelled future work on SNAP and began to sell the technology.

Other restrictions of the DualHead Mode have been listed by Andi (same resolution,...).

One other thing is the Clone-Mode. This is determined by the BIOS of the card and turned on by default most of the time. For example the ATI X800 or X1950 and also HD4870 display the content of the first screen output also on the second defined by the BIOS.

Hardware / Re: OpenGL ddk
« on: 2009.12.16, 15:23:38 »
Hi, all. If this post is in the wrong place or inappropriate, please remove accordingly. I'm trying to  collect info on opengl and display programming (sourcecode, etc) and am trying to find the OS/2 Hardware Device Driver Toolkit (openglddk). Searches online seem to suggest it is rarer than hen's teeth. The relevant OS/2 yahoo groups of the day seem to now be defunct. As the toolkit is now effectively abandonware, is it possible that anyone on these forums has this file that they can provide or can point me to it's location, by PM if necessary.  Any assistance would be greatly appreciated.
Thanks, TJ.

Hi, it's a little bit late but if you still need some information about the Hardware DDK, you can first read this post from two years ago:,com_smf/Itemid,63/topic,515.msg2485/#msg2485

If you need the Hardware Accelerated OpenGL DDK...look into your inbox. ;)

Moderator Note: If you cannot see the above link, please copy and paste this one into your browser window:,515.msg2485.html#msg2485

Code: [Select],515.msg2485.html#msg2485

Open Bounties / Re: OpenWengo port
« on: 2009.04.30, 16:36:21 »
OpenWengo is dead but the successor is QuteCom:

It's still using QT4 and therefore the QT4 Bounty is practically bound to this one.

Open Bounties / Re: TrueCrypt port
« on: 2009.01.14, 15:45:01 »
For the GUI I would say it would be a good idea to create it using WDSibyl (Pascal/Delphi).
This can be done fast and is not very complicated. Even people without programming experience could click the GUI together (except for the functionality).

The GUI can be used to call the commandline applications. This way the development can be split up.

An encrypted bootdrive is indeed too much work but an encrypted partition should be doable. But I think for the start support for encrypted container files (*.tc) should be enough.

Edit: Added (*.tc) to container files --> Truecrypt container == a file containing an encrypted partition

Open Bounties / Re: QT 4.x framework Port
« on: 2009.01.14, 15:33:38 »
There is a lot of silence about the Qt port.
As Nokia just changed the license model of Qt to LGPL I hope this will help to update the Qt 3.3.x Port to Qt 4.5.
Is there anything we can do to make this fly (beside the bounty?).

I actually don't know which compiler has been used in the past for Qt, but as Paul updated GC  to 4.3.x (seems to work quite good) and also OpenWatcom get's an update (1.8 rc2 is out) this might help to get some developers working on a new Qt version for OS/2.
There are a lot of applications using Qt so it would be great to get a new version of it.

Pages: [1] 2 3 ... 6