Andrew from SciTech writes: “SciTech SNAP Graphics now supports 180 different graphic chipsets. With that said we have been hearing that we now support too many different cards. So OSNews faithful, how many graphics cards should we support and which cards should make the cut in the next release?” And to add to this question, which OSes SciTech should add support for?
SciTech Asks OSNews Readers About Future Support
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Don’t know about which cards to cut in the next release, but in the OS department (and i’m sure Eugenia won’t find this surprising), may i suggest BeOS and (especially) BeOS derivatives.. OpenBeOS, Zeta, etc.
DaaT
http://www.beosjournal.org
It might be a “technical” issue here, as BeOS only supports PCI and AGP, while SciTech supports some ancient VLBus and ISA gfx cards, which BeOS wouldn’t able to support…
But yes, I would like to see a cleaned-up version of SNAP which only supports PCI and AGP cards and only offer the ISA/vlbus options for an embedded product… Especially IF supporting ISA/VLBus/EISA cards affect the performance of the AGP/PCI drivers…
It’s not an OS i know (shameless plug :-), but how about developing a way for DirecFB to use SNAP drivers, those guys have a great graphics system for linux but no real driver support.
http://www.directfb.org
drivers: http://www.directfb.org/modules.xml
PS: I thinks SNAP is great, THANKS!
I was a very happy customer, as scitech display doctor was vital for me in the DOS era, my card bios didnt have VESA 2.0 support. Eugenia, i dont think BeOS can take advantage of VLB
cards, since It doesnt work on 486 computers (that allways made me sad, as it worked great on my pentium 100). It is also great to hear what scitech has done for openwatcom too.
So, if anyone from scitech is reading this i’d like to personally thank you for being such a cool company
I guess videocards just got incredibly more complicated than setting a videomode, switching pages or using a framebuffer, or
even the cool windowing and triple buffering extensions from your drivers, so it’s a harder market to support.
As a bussiness practice, maybe scitech could contribute some
to the Xfree project, to improve driver support, while at the same time selling a compatible and commercial version of it with propertary drivers (their license allows it). Pretty much the same bussines model as OSS(4front)/OSS free, or thekompany. I think most linux users (myself included) and even distros like redhat/etc would love this kind of product.
Hi Andrew from SciTech
I think SNAP sounds like a prommising product … and look forward to use it in AmigaOS 4.x :O)
I have used SciTech Display Doctor in the past and hope SNAP will be as good as it was :O)
Best regards,
Henning Nielsen Lund [Denmark]
How about 3D and OpenGL support?
It might be a “technical” issue here, as BeOS only supports PCI and AGP, while SciTech supports some ancient VLBus and ISA gfx cards, which BeOS wouldn’t able to support…
No Amiga platform supports VL or ISA, but it hasn’t prevented them signing a deal.
But yes, I would like to see a cleaned-up version of SNAP which only supports PCI and AGP cards and only offer the ISA/vlbus options for an embedded product… Especially IF supporting ISA/VLBus/EISA cards affect the performance of the AGP/PCI drivers…
I think that the SciTech people are competent enough not to let driver diversity influence performance.
I’d like to see FreeBSD supported personally…
I’d like to see support for FreeBSD and (as DaaT said) BeOS and it’s derivatives.
Hello SCi-Tech people,
Would it be possible for SCI-TECH to GPL the source for old video drivers that you want to obsolete? The GPL would prevent anyone from selling your code and if people wish to make changes to your code, they must submit them to you if they want to distribute it (for free.)
I realize that this “old” code was the bread and butter that put Sci-Tech on the map, but the OS’ that can benefit from your drivers would be ones such as FreeDOS with SEAL 2.0 GUI, or other DOS clones. Also, people do create their own PC-Firewalls based out of old 486s, even some 386s. Your old ISA and VLB drivers would definitely have some use there (western digital video cars, YUCK.)
Your new PCI & AGP drivers, are your core business now. As the old commercial for retarded US citizens goes “Don’t throw us away” –us being users of old hardware, not retarded people.
GPL-ing your old drivers, would, I think, pose no threat to your current business or business model, you’d provide the old software “as-is” with no warranty–caveat emptor.
Allowing others to view your GPL’ed code may possibly open new markets for your company as well–> look at 802.11b for linux, many people have contributed code for the various chipsets and drivers out there for Linux and BeOS–This only increased sales of 802.11b hardware and created a lot of cooperation and discussion between buyer and seller–buyers got the support they wanted, sellers got free marketing insight into what these customers really wanted- customers from a previously untapped market– and some skilled customers even helped with the deveopment of the drivers for free, cutting time-to-market and costing nothing.
For Sci-Tech GPL’ing your drivers for use on older hardware would certainly get your name out and give you at the least some free advertising–as a company that supports open standards and is willing to give their customers the best of both worlds: a lean piece of PCI-AGP software, and for those with older machines drivers for their video cards and an opportunity to play with the source code and possibly get it to work on another operating system– Remember, if you GPL the code, you get to see all the changes, and you decide what changes will get added to the source. As a result you MAY get free coders working on direct ports or software derivatives for Linux, BeOS, or other alternative, previously untapped OS–then apply those techniques to your current PCI-AGP projects. Basically it’s free research and development. Setup a forum specifically for the GPL’ed source code and you’ll have free technical support for it.
It’s a win-win situation. You’d be surprise how many people still use “old” machines–or Single Board Computers. Look at the PC104 form factor (looks like a 16bit eisa card)–people are STILL developing for it!!
just my $0.02.
best of luck,
Dave S.
SciTech SNAP primarily supports PCI and AGP video cards; ISA/VLB cards would fall back on VBE (best case) or VGA. The only exceptions to this are a couple laptop chipsets. As for the “affecting performance” comment – it makes absolutely no difference, as each driver is distinct from all others, and only the one needed gets loaded (this is hidden from the user, as all drivers are bound up together in a graphics.bpd file). We can of course make customized versions of the BPD file which support any subset of the drivers, and do in fact do this for certain customers.
Regarding the comments by reduz – yes, they are much more complicated, and so are our drivers! SciTech SNAP has nothing in common with our old UniVBE drivers, which is what you are describing.
We are working on an X11 driver and will be announcing a beta soon – As for contributing back we have made are SNAP SDK available for use under a dual License (Commercial and GPL) Similar to QT.
Performance has been very good in early testing beating many of the OEM supplied drivers. A promise to OSNEWS: We will announce the release of SciTech SNAP Linux here first!
Cheers,
Andrew
What i’d like to see is a way to have people other than SciTech themselves code support for the drivers in operating systems. They seem to be doing a really good job, but unless they see your project as something big, you have no chance of support, which is a shame.
As for them gpl’ing stuff…even just gpl’ing older stuff like mach64 drivers would be appreciated by many.
Not quite GPL;) but useful and free products all the same – enjoy!
http://www.scitechsoft.com/products/enterprise/free_titles.html
As for the code being made available via GPL to or old drivers… many if not all of the drivers are based on code we received under NDA. This fact makes it next to impossible to get permission to release but we continue to try.
We cannot GPL the source code for the majority of our drivers, as that would violate NDAs we have with the hardware vendors. However, as Andrew mentioned, the SNAP SDK is available under a dual license, and it is certainly possible for others to write SNAP drivers.
Take a look at our website you will see that we are actually GPL’ing a lot of our proprietary code – The SNAP SDK leaps to mind as a recent case in point.
http://www.scitechsoft.com/products/embedded/sdk_home.html
Hi SciTech,
My $0.02 worth is to cast a vote in the FreeBSD arena =)
Thanks
Andrew: thanks for the link, interesting stuff.
Whats the average driver size? What are we talking about here…100kb, 500kb, 3mb? I’ve written a 2kb VGA driver before, but well, it wasnt for SNAP, and i dont think it’s very comparable.
Lets say someone wanted to make their OS (alternative OS) use SNAP drivers instead of coding their own. What would all be required? Porting the SDK and the MGL? What else?
Thanks.
So is it safe to assume that dropping chip support is not high on anyones list? If so perhaps we should turn this discussion to the subject of OS support….
What you offered me today, the hope of good gfx support on alternative OSes, is really appreciated.
I’ll definately keep your name in mind, and I’ll be looking at implementing SNAP graphics driver support for my own alternative OS.
Thanks for all this open source code!! You guys own!
Our chipset drivers currently range in size from 74K to 354K, which doesn’t include the support code.
To support another OS, you would have to create an OS-specific shell driver, which exposes the acceleration functions in a way that the OS understands. You would also need to port the SDK (which already runs on most operating systems, and is intended to be very portable), but you don’t necessarily need MGL, as that is a higher-level toolkit.
The original premise is a joke. Anyone who says too many drivers is bad has no complaint and is making things up just to belittle the announcement.
I do think that 3D has been a sticking point. Without 3D these days, you might as well be using VESA.
I can see where any driver support at all will help Amiga, however for the other OS’s, without 3D support for ATI and Nvidia cards there is no point using your drivers.
It is unfortunately a harsh reality of today’s users.
Mutiny
For anyone interested Rocklyte recently ported SciTech SNAP for use on the AtheneOS. You can learn more about this project here: http://www.rocklyte.com
Additionally we estimate that you can add support for SciTech SNAP Graphics for your OS in as little as 1000 lines of code – if your a coffee drinker and excited about your project this should mean that in less than 1 week you can offer fully 2D accelerated graphics support for nearly every chipset ever created!
Mutiny,
If you’re a gamer I completely agree with your 3D assessment – However, for most embedded systems and nearly every office/business system 3D simply does not come into play.
Now before everyone jumps on me for copping out on this issue… Let me say that 3D is a critical requirement to be considered a *cool* product and we would be foolish to ignore this smart observation, but NDA’s prevent me from saying more;)
Andrew-
Only 1000 lines of code? That’s pretty good. As I stated previously, i’d like to BeOS and FreeBSD to be supported. Perhaps also Syllable, i’m not sure if Syllable is far along enough in it’s development but it for 1000 lines of code it would be a great way to get a lot of drivers.
Why are they asking a bunch of dolts on a third rate website about business decisions? Everybody knows that if you want to get an honest,coherent and objective answer you should submit it to Slashdot ie. “Ask Slashdot”.
I guess that even if the BeOS market is small, the soon-to-be-released Zeta is injecting new life on the community. I guess SNAP and BeOS would actually be a perfect match.
OTOH, we are developing an opensource version of BeOS (OpenBeOS) and I guess supporting that (at least when we have a graphics/driver framework in place) would be a boost for the project.
-Bruno
John,
Thanks for your 2 cents we often request feedback from various groups whom we feel offer fair, and unbiased oppinions. Slashdot is often included and somtimes is not.
Speaking to your “dolts” comment – I must ask, why are you visiting this particular site and providing advice. Could it be that you are in fact a dolt?
Regards,
Andrew
> Everybody knows that if you want to get an *honest, coherent and objective* answer you should submit it to Slashdot
Riiiiight.
FreeBSD is an option and one that some in our engineering group would give at least one primary bodypart inorder to get supported – how can we say no to an offer like that;)
Whatever happened to your Display Doctor 7.0 for Windows? That was the first version to give NT/2K/XP VESA support, and had much greater promise than Ken Silverman’s NOLFB.COM wrapper. It would be a pity to see SDD7/Win enter obscurity…
We have been busy migating our technology to SciTech SNAP, and as such have moved away from the technology that SDD was based on. However, we will be making a SciTech SNAP for windows product available in the very near future.
Are you implying that I might be a dolt?
HAHAHA
Ofcourse I’m a dolt!
Hi guys,
In reference to one of the early posters who suggested that we GPL the old product source code, you must be a mind reader! We have in fact been pursuing this exact route for about the last 6 months, and have been getting ready to release the source code for the old UniVBE product under the GPL license. The catch (and the reason this is taking so long) is that most of these old drivers were written with information under NDA from hardware manufactuers. For the last six months we have been trying (not so successfully
) to obtain an NDA release from the hardware companies that still exist so we can make a GPL release of the old UniVBE code. So far most companies have said ‘OK’, but for some we are still waiting to get legal approval (S3 and ATI spring to mind). NVIDIA is the lone company that basically told us to ‘go take a hike’, so all NVIDIA code will be ripped out of the GPL UniVBE before we release it.
Anyway, we have been working on this and one option we have been considering is simply to release what we can today, and then add more drivers into the source code as we get permission from the hardware vendors. Perhaps there is enough interest in this that doing the release with many drivers missing initially would still be interesting to the community?
Finally in reference to the person who wondered what happened to SDD/7 for Windows – the core of that product was always SciTech SNAP, and one of the primary reasons why it was dropped was because we failed to implement a functional VESA VBE driver for Windows 2000/XP. Due to basic incompatibilties in the DOS box architecture in Windows 2000/XP, it is simply not possible for us to build this driver. We actually had it close to working, but ran into such critical problems that the whole project was scrapped. We will have a SNAP Graphics for Windows product, but it will just the new SNAP based Windows display drivers without any VESA VBE DOS box support (actually on Windows 9x/Me the DOS box support will still be there).
In response to Andrew, any end user OS needs 3D. Unless you are creating just another smart phone, 2D is not enough.
To be taken seriously in the near future, any device will need some 3D capability. By the near future, I mean the development time of an OS.
Every device we are exposed to these days is leading towards 3D interfaces. That is what we expect. To create anything at this point and not include some 3D support is shooting yourself in the foot.
In my case, I am interested in creating an OS tuned for video editing use. So far I am using a Linux kernel since both 3D and 1394 support is available. I like the ideas in several other small OS’s, but porting both OpenGL and 1394 is simply too much.
I’m glad to hear that you do have something in the works for 3D. I hope it carries on the same commitment to quality your other products have shown.
Mutiny
What kind of super secret methods are used in programming these cards that the companies require an NDA? From what little hardware programming I did EONS ago I remember that most of what’s involved is shoving values into IO ports and writing to a specific memory address. What are these companies doing that is so different (from one another) that they feel the need to use NDAs?
Just wanted to thank you for your efforts making parts of your programs/drivers available under GPL. I really like dual licensing, commercial and GPL, since this can satisfy both the commercial industry as well as the free software community. I wish you best luck on this way! =)
PS: I guess we can’t expect anything better from Nvidia…
Everybody knows that if you want to get an *honest, coherent and objective* answer you should submit it to Slashdot
LMAO!
OK I am not sure if it could work right, but for the small/ hobby/ toy/ etc OSs out there would it be posble to make a UDI driver. This could be sent out in a binary format and still run on any x86 OS (that has UDI support). That way you could still include NDA type code.
Oh wait, you said ‘an OS’ could add support for your existing Bins from just 1Kloc.. Is this right?!?
Please. Give us an easy way to play games in console or X, without the problem of games freezing the keyboard and mouse, leaving no way to get out of the wrecked game/prog without remotely logging in or hard resetting…, all this with OpenGL and maybe even directx translation… I would surely pay for it. In short, make Linux a gamer’s paradise
First of all, thank you for allowing us readers to be able to provide this kind of feedback. I am a software developer and have recently published a commercial application for the Sharp Zaurus SL-5500. I am currently developing a code base for arcade games for this platform also, but the only solution out there is the SDL (Simple Directmedia Layer) project. It is quite good, but not as mature as it needs to be for producing commercial stuff, and I would love to see SNAP available for the Sharp Zaurus including the upcomming 400mhz model.
Finally in reference to the person who wondered what happened to SDD/7 for Windows – the core of that product was always SciTech SNAP, and one of the primary reasons why it was dropped was because we failed to implement a functional VESA VBE driver for Windows 2000/XP. Due to basic incompatibilties in the DOS box architecture in Windows 2000/XP, it is simply not possible for us to build this driver. We actually had it close to working, but ran into such critical problems that the whole project was scrapped.
Thanks. It’s a pity that you never got it working – the main reason for my interest in it was because of the promise of 2K/XP VESA support in DOS boxes. Out of interest, have you looked at NOLFB.COM? http://www.advsys.net/ken/build.htm
I think it works by translating VESA 2.0 calls to 1.3, which 2K/XP seem to support a bit better. It certainly works with Build-based games, anyway, if a little poorly.
I was pleased to here the news about SNAP drivers for AmigaOS 4. Have heard good things about SciTechs products.
What we Amiga users really want, like everyone else is good accelerated 3D. Hope you can work with the Hyperion guys to make this a reality.
It would not be bad with SNAP ported to AROS (www.aros.org) :-).
(various NDA related comments)
/me dislikes NDAs more and more each day.
NDA sux.
Btw, no there are no super secrets you don’t have to know, it’s just a gov’s conspiracy =)
Actually, it’s just that companies fool themselves in thinking their IP is protected through obscurantism… Which of course is totally wrong. that won’t stop a competitor from reverse engineering or other things, though it does affect opensource OSes as they can’t sign an NDA that requires the driver source to remain closed. Besides, to me signing an NDA to get specs is a moot point. I mean this really belong to the user documentation. As a user I have the right to know how the thing I bought is to be used. And of course on opensource OSes where no driver exist, the datasheet _is_ the user manual.
This makes me really mad when I see my parent’s 20 year old TV set came with complete schematics and I have the plans for my old ORIC Atmos, whereas now I can’t even have the specs of an _interface_ to the thing _I_ own. If I had money I’d really enjoy suing nvidia for not providing me the specs to the chipset that is in the ELSA card I own.
And, to say something about ATI, well if I were them I wouldn’t ask ppl to sign NDA to write drivers when I’m not able to write them myself. The only problems I had with my rage pro card were in windoze (and updating the driver resulted in windoze not even booting), whereas Linux had perfect support, and BeOS almost perfect (and the Dano driver fixed the overclocking problem when using overlay).
Oh, and I’m still waiting for a reply to the mail I sent to S3 support asking for docs :^)
> REPLACE XFREE !!!
> make Linux a gamer’s paradise
Just don’t use XFree
BeOS doesn’t use X11 and is really a paradise of a desktop OS. Yes it does have oGL (not many hw support for now though). Sometimes using something else is much simpler than trying to fix
> 2K/XP VESA support in DOS boxes.
What about using a real OS and Bochs ?
It’s funny M$ took so many years to depart from this legacy thing (well it looks like there are still some crap in), and see users wanting to revert =)
> GPL
Yeah, go for GPL !
Btw, I vote for *BeOS/Zeta support, of course =)
btw, just to remind you there are 2 petitions I really invite you to sign if you believe as I do that NDA sux and specs should be available freely:
http://www.petitiononline.com/zxcv7nm/petition.html
and
http://www.camodi.org/
(which still seems to have registration issues, hope they will be solved soon).
Hello,
I hope you will support the new NVDIA/ATI graphiccards like GeforceFX or the Radeon 9700/9700Pro and so on for
the new AMIGA OS 4.0.
Bye.
BlackHawk
XFree supports pretty much the same hardware, has driver modules which are OS neutral and is under a Free License. XFree also has 3D support and a lot more advanced features than SNAP, right out of the box.
So why would anyone care about SNAP?
> XFree supports pretty much the same hardware, has driver
> modules which are OS neutral and is under a Free License.
> XFree also has 3D support and a lot more advanced features
> than SNAP, right out of the box.
>
> So why would anyone care about SNAP?
Because drivers are written using bytecode? So not only is it os-agnostic, it is also architecture independent?
Also, remembering the nVidia drivers for XFree, they work only with a specific kernel version of Linux, I don’t call that very portable.
My list of wished OS’es:
X11 /Linux / BSD
Beos & Clones
AmigaOS
RiscOS (iyonix)
The idea to GPL the older ISA and VL drivers sounds good, and the AGP&PCI drivers will possibly be sold like hot pretzels to the companies like RedHat and SuSE.
Ahhh, and letting out drivers?
I don’t see the point, to be honest.
When there are problems in performance, diversify the drivers somehow, e.g. PCI, AGP, VL ,ISA all as separate packages.
For embedded use, I think you already have a “to fit” solution.
> Because drivers are written using bytecode? So not only is
> it os-agnostic, it is also architecture independent?
Bzzt. Wrong. SNAP drivers, just like XFree drivers are written in C and compiled for each separate architecture.
> Also, remembering the nVidia drivers for XFree, they work
> only with a specific kernel version of Linux, I don’t call
> that very portable.
The drivers for nVidia GeForce & similar cards included with XFree are portable. The proprietary drivers from nVidia (which were not written by XFree) are not. Maybe nVidia will write non-portable SNAP drivers too, who knows?
> Bzzt. Wrong. SNAP drivers, just like XFree drivers are
> written in C and compiled for each separate architecture.
Right, maybe I should have looked at this presentation before assuming that “binary portable drivers” meant cross-architecture when it is tied to the x86: http://www.scitechsoft.com/pdf/snap_presentation.pdf
Maybe the next step SNAP should try to take is in using a true bytecode. I’m not thinking of Java or .NET here, but something along the lines of the GCC internal code used by the optimizer, the layer between the language-dependent and the cpu-dependent backends, where optimisations are performed. Maybe this “bytecode” could be used for the drivers and the final GCC-styled backend/assembler convert to native machine code the driver at load time.
Were part way to your purposed solution already with our recent release of SciTech SNAP for QT Embedded:)
Is there a statute of limitations on the NDA’s you SCi-TECH guys signed? If so, how long?
Thanks,
Dave
Support for the open source BeOS clones (OpenBeOS in particular
would be fantastic, as well as the various BSDs. I’m curious about something, though: it’s generally felt that the MIT & BSD licenses are incompatible with the GPL; in licensing terms, how would SciTech make it possible for these open source OSs to use the SNAP technology?
e
What is the point in getting SNAP into BSD, except for the sake of coolness? All BSDs (MacOS and others notwithstanding) are non-graphical OSes, and if you happen to have graphics output in your box, it’s just used as a poor terminal. Graphics support is the least of BSD’s worries.
Hi over there!
Your question concerning supported OSs. I would be glad to hear that you’ll support Amiga OS4 (and beyond) as well as MorphOS (eventually).
Concerning the graphic boards: I think its a goog course to support as many boards as possible. But if you’ll have to concentrate, well why not supporting the mostly selled chipsets within desktop and other high selling markets (but supporting as much as so far is the best solution you can get in my opinion, because you’ll sell/licence more of your drivers; if you want improvement what about integrating 3D support eventually in cooperation with Hyperion so you can advertis a “Whole in one low level driver for about 180 different products”!?).
Than for supporting OS4
Kind regards
Concerning the graphic boards: I think its a goog course to support as many boards as possible. But if you’ll have to concentrate, well why not supporting the mostly selled chipsets within desktop and other high selling markets…
Some further diversity should be a sound choice. Not just the best-sellers from Taiwan, but also some fulfilling particular needs and niches. Certain high-power boards, certain low-power chips, odd multi-screen configs and so on.
the GPL license doesn’t prevent someone to sell, m
the GPL license doesn’t prevent someone to sell, make or use a product that fits in another product using BSD/MIT or closed source…
the only tricky thing would be to dsitribute both together
(though I think with the MIT licence it would be ok as it’s listed as FreeSoftware and compatible with the GPL, and as SciTech is the authorthey can do whatever they want with teh code, including a distribution authorisation clause for OpenBeOs or its derivatives if they want).
There are indeed GPLed hardware drivers available for Windows IIRC (don’t remember for what), so…
(sorry for the dbl post, tab sux)
I’d be very happy to see a driver for the GeForce2Go chipset.
and it brings up some interesting thoughts …
theres probably a link somewhere but since im feeling too lazy to poke around…. just how much is the commercial licence?
while the thought of having the drivers available on the bsd’s is appealing…. having the gpl in a place like that makes me kind of uneasy
in particular the little bit they said about “dynamic linking”
Just for ‘random end user opinion’ reference, one thing that really puts me off Linux is all the hassle trying to get 3D drivers working under Linux; I’d bet such a system would actually sell, even in Linux land — I’d certainly buy.
What’s SNAP’s real market? If it’s just embedded solutions (which is fine, of course), why ask us, mostly a bunch of ordinary-but-slightly-geeky desktop users? I think if you’re interested in doing more business on the desktop, it’s clear that 3D is a biggie (and probably even more of a biggie at your end
Linux is clearly the largest market for such a system (given that Windows is generally supported by most card manufacturers anyway)… give us simple drop-in 3D drivers and you’ll sell!
I have a Matrox G450 eTV card. I’d like to be able to use it on my Amiga One. I think I read that you have a driver for the G450. Would additional drivers be needed for the eTV features, or just the programs that access the eTV features?
Thanks for joining the Amiga revolution.
Please to support BeOS. Another support focus might be on laptop devices, and this is the largest growing market at the moment and I have heard constitutes 50% of new computer sales.
Alan
in terms of the original question, ie what chipsets to support, the I would be interested in support for the VIA PLE/CLE integrated chipsets as used in VIA’s MiniITX motherboards.