DOS ain't dead

Laaca wrote:

> Since we can use the DJGPP version by Michal Kostylev I don't see any
> reason why to bother with Windows version under HX.

Heh ??? Having newer versions, some of the DGJPP versions can't play OGG Theora at all

> (The absolutely great feature of DJGPP version is ability to use the
> hardware video acceleration via VIDIX library)

This is great ... although I haven't tested it yet.

> And the absolutely sad feature of the DJGPP version is that Mik seems to
> have disappeared from the face of the earth, and it hasn't been updated
> for a year.



> <hope>Unless you know something I don't. </hope>

I do: the Win32 version from 2009-12-20 works with HX again

Apparently Sherpya enabled SDL, and even worse, linked it statically in (no attempt to access SDL.DLL), and, even worse, it works, it works well, and is fast (the "GL" that used to work some years ago was slow as hell, apparently some timing BUG ...)

Rugxulo wrote:

> Roberto Perotti to me

He still ASS'umes to be banned or is he really banned from here ?

> Sherpiya have released some modified dll for hx for running mplayer on
> dos with hx.

YES. But for me it works witout them also. And, Japheth included the changes, so this hack by Sherpya is obsolete anyway

> I see no reason why the HX-version should not continue to be be developed,
> and maybe it will eventually become as useable as the DJGPP version is now.

There is no "HX-version", just the Win32 version works with HX

There are following flaws in this last version:

- Very large and hot DeLL HeLL needed (see list below)
- Startup takes centuries (see debug report in link)
- Missing imports, or use HX 2.17
- There is no sound

http://freefile.kristopherw.us/uploads/temp/mpwsdl.txt



************************************************************************

MPW.EXE 14'357'504
75CE5205CFAAE2382864E9F81DAFC0B6

MPlayer Sherpya-SVN-r30075-4.2.5 (C) 2000-2009 MPlayer Team
Compiled with runtime CPU detection.

************************************************************************

CRTDLL.DLL   184'320 bad license
DADVAPI.DLL   10'752
DCIMAN32.DLL   4'096
DDDRAW.DLL    13'824
DGDI32.DLL    27'136
DKRNL32.DLL   80'896
DUSER32.DLL   41'984
GLU32.DLL    139'712 bad license
HXGUIHLP.DLL  14'848
MSVCRT.DLL   278'581 bad license
OLE32.DLL      5'120 OLEeeee OLEeeeee
OPENGL32.DLL 733'296 bad license
SB16.DLL       6'144 unnecessary
SHELL32.DLL    4'096
VESA32.DLL     9'728
WINMM.DLL     12'288
WS2_32.DLL     5'632
WSOCK32.DLL  446'976 could be less bloated
DPMILD32.EXE  18'351
HDPMI32.EXE   35'756 resident
HXGUIHLP.INI   2'659

************************************************************************


I haven't tested the CMOVNTQ issue yet

Definitely thanks to Sherpya

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

> And the absolutely sad feature of the DJGPP version is that Mik seems to
> have disappeared from the face of the earth, and it hasn't been updated
> for a year. <hope>Unless you know something I don't. </hope>

Mik is still active and meantimes he has continued to update his Mplayer port adding some nice features (e.g. OSS audio support), but he refuses to make it publicly available for an idiosyncratic reason.

---
Glory to God for all things

> FYI, the CMOVNTQ's are not gone at all
>
> http://pastebin.com/m2b5d7a67

He should avoid -march=i686 or higher and just use -mtune=generic instead.

> > INC/DEC are slow on Pentium 4 on up
>
> And Pentium 4 always had the biggest performance problems, why don't you
> just get an 80386, 8086, or 4004 not causing such trouble ???

P4 isn't that bad, speed-wise. At least the high clock speeds and SSE2 compensated. But it did break some common optimizations. However, that doesn't mean that Intel hasn't improved upon things. Atom is in-order and thus uses lots less power while being as fast as a high-end PIII or low-end P4. There are even dual-core / 64-bit Atoms now, cheap! (See Darek's blog.)

> > GCC actually generates this a lot when using -mtune=generic or similar.
>
> And what mtune disables such absurdity ???

I know at least -march=pentium won't use it, but that can penalize newer chips, so I wouldn't recommend it without a good reason.

> > (EDIT: That reminds me, I just found out [a year late, heh] that Darek
> > http : / / www . emulators . com / download . htm open-sourced the DOS
> > version of PC Xformer 3.80, but it's hidden inside the GEMCE900.ZIP
> > sources under \atari8\ folder, apparently needs MASM and VC6 or better.
>
> You love such unrelated side notes

Well, it's not THAT unrelated. He's a big pro regarding optimization, e.g. his work on speeding up BOCHS, his very fast Atari800 emulator (runs fast on 486, no small feat!).

> I'm sure GCC optimization experts will be able to explain me:
>
> - What's the goal of REP RET
> - What's the goal of O16 NOP

AMD optimization, just like "O16 NOP", IIRC. P4 has jump hints (ds jz), and SSE2 has "pause" (rep nop). Yeah, I know it's weird.

> - What's the goal of avoiding PUSH and POP and using MOV [ESP+blah]
> instead
>>
>> mov [esp+8],edi ; Why not PUSH ???

It would take more instructions, not necessarily better.

>> mov edi,[esp+8] ; Restore - why not POPE ???

This way keeps ESP unmodified.

> - How bloat (redundant repeated encoding of "boring" or same numbers as
> 32-bit values) improves performance

Cpu design, e.g. one-byte LODSB is slower than bigger, manual MOV due to more RISC-y internal structure since 486. XCHG (atomic) is also slower than push / pop (pairable on original Pentium).

> - Why preserve EBP when you don't need it at all

Dunno, probably a compiler shortcoming.

Well, this is old ... but

> FYI, the CMOVNTQ's are not gone at all

Well, since 2010-01-20, they are gone

r30886 2010-03-13 is out:

* Still works well in DOS with -vo sdl
* Still works well on Pentium 1
* Better Theora compliance (but "offset" still ignored, and DUGL PLAYER much better)

* BUG: -vo sdl causes ugly artifacts if width is odd (it is a problem specific to "-vo sdl", not the decoder)
* BUG/FLAW (of HX ?): can't play a movie bigger than screen size (looks very crappy)
* BUG/FLAW: "-vo yuv4mpeg" always uses the "420" format

For comparison, VLC 1.0.5: needs Windaube, 3 times more bloat, needs a crack (on ME), installation completes hapilly after taking centuries, and the final effect ? IT DOESN'T WORK - silent give-up, maybe CMOVNTQ (tested on Pentium 1) ???

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

> > INC/DEC are slow on Pentium 4 on up, and forbidden completely in 64-bit
> > mode. GCC actually generates this a lot when using -mtune=generic or
> > similar.
>
> Quotation needed. AFAIK on Pentium 4 etc. INC and DEC ar as fast as SUB 1
> ADD 1. Perhaps you want to say that multiple INCs and DECs are slower than
> ADD and SUB or that on 64-bit CPUs the carry flag is not affected by them
> as opposed to SUB 1 and ADD 1.

I don't remember exactly, so I may be saying it incorrectly. But I think it really is slower on P4s. On 64-bit, I thought the REX prefix was the INC/DEC opcode reused (so as to not pollute / bloat the opcode space).