DOS ain't dead

Hello all, has anybody tried the last Michael's MPlayer WIP port?
It has enabled the CVidix driver. Had anybody success with it? For me works only the VESA output.
Tested on GeForce 4 MX and ATI Rage XL. Both chips are properly found but nothing is shown on the screen even if I set some graphics mode.

---
DOS-u-akbar!

> Hello all, has anybody tried the last Michael's MPlayer WIP port?
> It has enabled the CVidix driver. Had anybody success with it?

I tried the verison from 9 Jan (not the one from 18 Jan).The cvidix driver works for me with both my ATI MACH64 and ATI RADEON 9200 cards, but the implementation has some bugs, i.e. the image is always distorted and blured in the right part, in non full screen mode it is not centered (it is displayed from the top left corner of the screen), the video mode can't be changed and the image scaling options don't work. Anyway I prefer to use cvidix, because the vesa driver of mplayer is too slow even with my fastest computer, but with cvidix the speed is very good.

Playing with the version from 18 Jan I observed that if I set a certain graphic video mode and then I run mplayer with -vo cvidix -fs -zoom -x modexres -y modeyres -really-quiet options, the image quality is really great.
The "-zoom -x modexres -y modeyres" part is just for showing full screen the image. If removed, the image is shown centered and non-scaled.

A stupid question - how do I enable cvidix to switch to graphics mode?
when I use -vo cvidix it don't switch to graphics and leave in textmode.

---
DOS gives me freedom to unlimited HW access.

> A stupid question - how do I enable cvidix to switch to graphics mode?
> when I use -vo cvidix it don't switch to graphics and leave in textmode.

Read my post above your question.

"I set a certain graphic video mode"

You mean to use some other program for setting videomode? Should be simple call of INT10h to set vesa mode enough?

---
DOS gives me freedom to unlimited HW access.

> You mean to use some other program for setting videomode? Should be simple
> call of INT10h to set vesa mode enough?

Yes, use a batch which runs a program that just sets a vesa graphic video mode before mplayer is called.

> Yes, use a batch which runs a program that just sets a vesa graphic video
> mode before mplayer is called.

O'ou, didn't work. I just threw 4 lines to NASM to get SET1024.COM

MOV AX,4F02h
MOV BX,4118h
INT 10h
INT 20h

Then called batch

CLS
SET1024.COM
MPLAYER.EXE -vo cvidix -xy 1024 GAMMAR~1.AVI

But result was
http://rayer.ic.cz/350d/mplayer.jpg
it switched to required videomode but video still not visible.
I tried also different VESA mode numbers but still the same.

---
DOS gives me freedom to unlimited HW access.

> O'ou, didn't work. I just threw 4 lines to NASM to get SET1024.COM

It is very important to use mplayer with "-fs" option. Without "-fs" cvidix didn't work for me either. Also use "-really-quiet".

> It is very important to use mplayer with "-fs" option. Without "-fs"
> cvidix didn't work for me either. Also use "-really-quiet".

It seems to not work anyway:

"As Reimar has spotted it, this is irrelevant.
There's no chance vidix works with your 7300 (or has ever worked) as
this is an NV40+ architecture which do no longer support Overlay.
This has been replaced by texture blitting but is not yet implemented."

What VGA do you use?

---
DOS gives me freedom to unlimited HW access.

> What VGA do you use?

I don't understand your question, but if you ask about the cards I know cvidix to work well with, they are an old ATI MACH64 and an ATI RADEON 9200. OTOH cvidix doesn't work at all with a NVIDIA GeForce 7600 GS.
It seems that newer NVIDIA cards are still not supported by vidix drivers.

> I don't understand your question, but if you ask about the cards I know
> cvidix to work well with, they are an old ATI MACH64 and an ATI RADEON
> 9200. OTOH cvidix doesn't work at all with a NVIDIA GeForce 7600 GS.
> It seems that newer NVIDIA cards are still not supported by vidix drivers.

OK, it seems to be "solved". Your VGA works my not. But I can use VESA. But the major problem is that I cannont get sound - which is impossibe as I mentioned before on new mb. Maybe AC97/HDA driver will be implemented but Michael currently doesn't time to do it - it's quite complex task.

---
DOS gives me freedom to unlimited HW access.

Wow! It works!
To be more precious - it doesn't work on my primary machine: CPU 1,3GHz with GeForce 4MX card. But it doesn't hurt becouse this computer is fast enough for VESA output.
But what is important, it works great on my secondary machine: CPU 300MHz with ATI Rage XL. It is much faster than the VESA output - it is even comparable to QuickView hardware acceleration. BTW: maybe QV also uses some DOS port of Vidix?
I suggest this command line: "mplayer -vo cvidix -fs -zoom VIDEO.AVI" (without -x and -y parameters)
On the 300MHz machine is the VESA output for AVIs so so but via CVidix is it perfect. DVD via VESA is jerky, via CVidix OK. WMV is probably very CPU intensive, even CVidix doesn't help much

But what is bad: AVI output is stable (for both VESA and CVidix) but WMV and even more DVDs are quite unsable and crash after 10-20 seconds. Can someone with some more powerful machine confirm it?

BTW: the crash in CVidix output is very funny because even if the textmode is again set, there is still viewed the graphics window. It sound and looks crazy but there really remains in the textmode perfectly smooth graphics image. (Has any demo coder some use for it?)
And you can do nothing with it If you change the videomode it doesn't help. The only solution is to run again MPlayer or QuickViewer (if you have the hardware acceleration allowed)

---
DOS-u-akbar!

> OK, it seems to be "solved". Your VGA works my not. But I can use VESA.

I have also a NVIDIA GeForce 7600 GS and I didn't notice that you talk about the same card type.

> But the major problem is that I cannont get sound - which is impossibe as
> I mentioned before on new mb. Maybe AC97/HDA driver will be implemented
> but Michael currently doesn't time to do it - it's quite complex task.

Fortunatelly I have an old CS-4235 PCI sound card which has hardware SB PRO emulation and the Allegro sound driver works well enough with it. The best solution would be to port/adjust an already existent driver package. Did you try to compile the DOS port of Mplayer for yourself using Michael's diffs?

> I have also a NVIDIA GeForce 7600 GS and I didn't notice that you talk
> about the same card type.

Aha, but you wrote something about ATI Mach and Radeon in 1st post :)

> Fortunatelly I have an old CS-4235 PCI sound card which has hardware SB
> PRO emulation and the Allegro sound driver works well enough with it. The
> best solution would be to port/adjust an already existent driver package.

So be lucky, but I'm nearly 100% sure it's due to your older mobo/chipset not soundcard itself. I have SB Live which also have SB emulation, on prev. 440BX mobo it worked fine, now not. I also tried MediaForte FM801 which was noticed to work by Eric Auer but for me not and also CMI 8738 - the same. Even I have mb with ISA but no ISA soundcard works there because of intel removed necessary signals from ICH6 and newer to implement ISA DMA for PCI-ISA bridge. Simply intel has decided to vanish all legacy stuffs from PC.

> Did you try to compile the DOS port of Mplayer for yourself using
> Michael's diffs?

Not yet. I usualy have problems when compiling big projecsts, e.g. I wanted recompile CVS RHIDE with repaired RHGDB but gave it up. Also others on yahoo DJGPP group didn't compiled it. The only reason for which I should try to compile mplayer would be to implement SB live driver from mpxplay (which is mix of ASM and OpenWatcom) and it would be quite complex task without knowledges of both compilers and even no time to spend it on...

---
DOS gives me freedom to unlimited HW access.

I just test it on my notebook PIII 1.2G with ATI Radeon Mobility and cvidix works fine (VESA is noticably slow on this machine even with mtrr-wc) (but also nosound due to crippled ESS1869 PCI)

---
DOS gives me freedom to unlimited HW access.

> Fortunatelly I have an old CS-4235 PCI sound card which has hardware SB
> PRO emulation and the Allegro sound driver works well enough with it. The
> best solution would be to port/adjust an already existent driver package.
> Did you try to compile the DOS port of Mplayer for yourself using
> Michael's diffs?

¿Are the patches applyed in the SVN of the Mplayer project?

> Not yet. I usualy have problems when compiling big projecsts, e.g. I
> wanted recompile CVS RHIDE with repaired RHGDB but gave it up. Also others
> on yahoo DJGPP group didn't compiled it. The only reason for which I should
> try to compile mplayer would be to implement SB live driver from mpxplay
> (which is mix of ASM and OpenWatcom) and it would be quite complex task
> without knowledges of both compilers and even no time to spend it on...

Yes, I know that... I needed many many hours for compiling the source of ozone gui. But I am happy that I have done it, now it is very easy to continua developement.

> Are the patches applyed in the SVN of the Mplayer project?

No, they aren't. You must patch yourself the source code using Michael's diffs.
Maybe someone could add the sound drivers from Vsync Mame or the svgaline video drivers from Advance Mame (the last ones are a "light" version of those from SVGALib Linux library). They already compile with DJGPP, work well in DOS and I don't think that there are license conflicts. Regarding myself, I'm not well used to *niX tools and I don't have enough time for this either.

Laaca wrote:

> It has enabled the CVidix driver

Benefit ? Hardware scaling ? LFB becomes faster ? And why doesn't it set the mode ?

Khusraw wrote:

> Maybe someone could add the sound drivers from Vsync Mame or

MPXPLAY ?

> They already compile with DJGPP, work well in DOS and

Would be nice to have reusable drivers relying neither on WATCOM nor on D**PP

> I'm not well used to *niX tools and I

... was personally not very smart from MPXPLAY source, nor from Loonix kernel source nor from any other source of sound drivers, finally I have some several 100 KiB "official" sound VXD's - but it's really the last

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Benefit ? Hardware scaling ? LFB becomes faster ?
> And why doesn't it set the mode ?

Read my previous post.

---
DOS-u-akbar!

> > Maybe someone could add the sound drivers from Vsync Mame or
>
> MPXPLAY ?

I agree that Mpxplay has the most up-to-date DOS sound card drivers, but "translating" them from WATCOM syntax to DJGPP takes some more time and it seems that all persons interested in MPlayer DOS port don't have enough time for the project.

> Would be nice to have reusable drivers relying neither on WATCOM
> nor on D**PP

Perhaps this would be nice, but it's not actual, and if the goal is to have a better MPlayer DOS port ASAP, the best solution is to port/adjust some drivers written for GCC. For example MPlayer source code has SVGAlib video output option, so it would be easy to apply Andrea Mazzoleni's DJGPP patches to the library and to enable "-vo svga" in the DOS port too. IMO this would be a more elegant solution for hardware acceleration than CVidix. Newer NVIDIA chips will still not be supported, because I think their specs are not available yet for open source projects.

> I agree that Mpxplay has the most up-to-date DOS sound card drivers, but
> "translating" them from WATCOM syntax to DJGPP takes some more time and it
> seems that all persons interested in MPlayer DOS port don't have enough
> time for the project.

Even it contains a lot of inline assembly. And WC use normal intel syntax and DJGPP uses AT&T syntax (there's a way to link external obj file produced by other assembler) but it's evil... I browsed mpxplay SB Live drivers but not smart from them enough. But I never programed soundcard under DOS or other OS. simply noone can do everything...

---
DOS gives me freedom to unlimited HW access.

> Even it contains a lot of inline assembly. And WC use normal intel syntax
> and DJGPP uses AT&T syntax

Actually this is not true. Mpxplay sound card drivers don't contain "a lot" of inline assembly and newer GAS versions support intel syntax. For inline assembly use "-masm=intel" switch for GCC (I use DJGPP port of GCC v 4.22 ).

> lot" of inline assembly and newer GAS versions support intel syntax. For
> inline assembly use "-masm=intel" switch for GCC (I use DJGPP port of GCC
> v 4.22 ).

I know about -masm=intel option but it made some bugs (gcc crashes) when compiling some sources. But I don't remmeber if is was fixed.

---
DOS gives me freedom to unlimited HW access.