Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page

DOS386

12.07.2016, 19:12

MPXPLAY 1.61 beta 1 2016-Apr-17 and MOUSE-BUG (Announce)

http://sf.net/projects/mpxplay/files/Mpxplay/Mpxplay%20v1.61

> FileTypesExt =MP? ;loaded / displayed extra file types in player mode

What's new:

* extra file types (my MP5-files do show and play now :-) :-) :-) ...)
* see "WHATSNEW.161" (apparently nothing DOS-related)

BUG's:

* mouse cursor behaves very badly during playback (jumping, faking clicks) ... after stopping it using [S] key it is OK again ... I can reproduce it back to version 1.57 (older untested)

* for WAV files (but not for most other file types), the cool column diagram in top-left corner is sensitive to volume set during playback

Anyone else can reproduce those?

PS

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

DOS386

13.07.2016, 16:56

@ DOS386

MPXPLAY 1.61 beta 1 2016-Apr-17 and MOUSE-BUG

I can reliably reproduce the BUG with FreeDOS and EDR-DOS and with CTM 2.1 and with LOGITECH driver. However with CTM 2.04 it works well. Looks like a problem between BIOS and MPXPLAY.

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

Laaca

Czech republic,
16.07.2016, 11:31

@ DOS386

Not MPXplay bug but USB vs. CTmouse problem

CTMouse driver has some interferencies with USB stuff in some computers. Try check your problem with any USB disk plugged into USB port and also without any USB device at all. (don't change it on the fly, you have to make a complete boot).
Also try in your BIOS enable and disable the "Legacy emulation of USB mouse" option.

On my computer I have a little bit similar problem with 4-combination:
1) Legacy emulation of USB mouse off (in BIOS)
2) Plugged any USB device (I tried flashdisk and USB-IDE converter
3) Loaded CT mouse
4) Loaded national keyboard driver

In this situation, if I press up-arrow or down-arrow the keyboard act like capslock and/or CTRL is pressed and it is very frustrating to work then with the computer.

---
DOS-u-akbar!

DOS386

21.07.2016, 06:56

@ Laaca

Not MPXplay bug but USB vs. CTmouse problem

> CTMouse driver has some interferencies with USB stuff in some computers.
> Try check your problem with any USB disk plugged into USB port and also
> without any USB device at all. (don't change it on the fly, you have to
> make a complete boot).
> Also try in your BIOS enable and disable the "Legacy emulation of USB
> mouse" option

Thanks ... the Corpus Delicti does not even have USB mouse emulation ... and USB keyboard emulation was already OFF, and no USB device plugged in.

> On my computer I have a little bit similar problem with 4-combination:
> 1) Legacy emulation of USB mouse off (in BIOS)

bad with OFF and good with ON ?

> 4) Loaded national keyboard driver

I never use such stuff.

I tested on another PC, problem does NOT occur.

I doubt that it is related to USB, as USB is actually completely off, but something bad between MPXPLAY and the BIOS. Unfortunately I can't update the BIOS as the latest and best one is already installed. The previous version completely rejected the CPU, the PC reliably froze immediately after switch ON :-D

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

bretjohn

Rio Rancho, NM,
22.07.2016, 19:54
(edited by bretjohn, 22.07.2016, 20:07)

@ DOS386

Not MPXplay bug but USB vs. CTmouse problem

> I doubt that it is related to USB, as USB is actually completely off, but
> something bad between MPXPLAY and the BIOS.

Actually, I don't think this is a problem between MPXPLAY and the BIOS, it's probably just a problem with the BIOS. MPXPLAY shouldn't interact directly with the BIOS for the mouse at all -- it just interacts with CTMOUSE. CTMOUSE is what interacts with the BIOS.

The mouse BIOS is kind of weird, especially when dealing with mice that have extra buttons and wheels. The mouse driver (CTMOUSE) indirectly tells the BIOS (and the mouse hardware) how many bytes of data to send each time there is a mouse action (movement or button press/release). The BIOS can send either three or four bytes of data to the computer. If the mouse driver and the BIOS don't "agree" on how many bytes to send, everything gets unsynchronized and you get the weird stuff you described above.

Since you have the same problem with all kinds of different mouse drivers, it sounds like your BIOS is always sending four bytes instead of waiting for the mouse driver to tell it to send four bytes. The BIOS should only send three bytes unless the mouse has a wheel and the mouse driver tells it to send four bytes. Either that, or the mouse driver is telling the BIOS to send four bytes and is expecting to receive four bytes but the BIOS is still only sending three.

You can use my PS2MTEST program (part of the USB driver package) to do some simple troubleshooting of this and see if that is really the problem.

DOS386

23.07.2016, 16:52

@ bretjohn

Not MPXplay bug but USB vs. CTmouse problem

> Actually, I don't think this is a problem between MPXPLAY and the BIOS,
> it's probably just a problem with the BIOS

but it occurs only when playing a file ...

> You can use my PS2MTEST program (part of the USB driver package) to do some
> simple troubleshooting of this and see if that is really the problem.

Thanks ... I'll test.

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

Mpxplay

25.07.2016, 20:05

@ DOS386

Not MPXplay bug but USB vs. CTmouse problem

> > Actually, I don't think this is a problem between MPXPLAY and the BIOS,
> > it's probably just a problem with the BIOS
>
> but it occurs only when playing a file ...
>
> > You can use my PS2MTEST program (part of the USB driver package) to do
> some
> > simple troubleshooting of this and see if that is really the problem.
>
> Thanks ... I'll test.

I think so the problem is the BIOS vs. south-bridge.

USB, SATA/PATA, soundchip: these are in the mainboard's south-bridge, and BIOS can't access them parallel... :-|

RayeR

CZ,
26.07.2016, 01:24

@ Mpxplay

Not MPXplay bug but USB vs. CTmouse problem

> USB, SATA/PATA, soundchip: these are in the mainboard's south-bridge, and
> BIOS can't access them parallel... :-|

It's normal that on PCI bus devices cannot talk parallel to CPU but it has buffers to overcome it and continue to stram data from/to buffer even if not handled by CPU... It's seems to be some specific BIOS issue, I don't experienced such problem on my DOS machines. Maybe it could help to move soundcard to a different PCI slot (it not onboard) to change some IRQ routing...

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

Mpxplay

27.07.2016, 05:49

@ RayeR

Not MPXplay bug but USB vs. CTmouse problem

> > USB, SATA/PATA, soundchip: these are in the mainboard's south-bridge,
> and
> > BIOS can't access them parallel... :-|
>
> It's normal that on PCI bus devices cannot talk parallel to CPU but it has
> buffers to overcome it and continue to stram data from/to buffer even if
> not handled by CPU... It's seems to be some specific BIOS issue, I don't
> experienced such problem on my DOS machines. Maybe it could help to move
> soundcard to a different PCI slot (it not onboard) to change some IRQ
> routing...

I have such problem with onboard Realtek/HDA soundchip & SATA.
While BIOS/DOS reads the disk, the sound can stop for a while.

Mpxplay doesn't use IRQ for PCI cards, but uses the INT08 timer interrupt for soundchip polling, and BIOS - probably - also doesn't use IRQ for ATA/USB.
If BIOS waits for an ATA/USB data, then it can block Mpxplay's soundchip polling too, by switching off all interrupts during the r/w process.
The good question is that, if BIOS doesn't use IRQs, why does it disable interrupts while processing?
But this is just an idea...

RayeR

CZ,
27.07.2016, 12:04
(edited by RayeR, 27.07.2016, 16:00)

@ Mpxplay

Not MPXplay bug but USB vs. CTmouse problem

> PCI cards, but uses the INT08 timer interrupt
> for soundchip polling, and BIOS - probably - also doesn't use IRQ for
> ATA/USB.

I belived that it use DMA so the soundcard should have enough samples in DMA buffer to play for a while during disk access...

> If BIOS waits for an ATA/USB data, then it can block Mpxplay's soundchip

Maybe USB emulation BIOS routines are too slow that DMA buffer underrun? I cannot belive it could take such long time... (I have USB legacy support disabled and still use PS/2 mouse and KBD so no need for it).

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

bretjohn

Rio Rancho, NM,
28.07.2016, 17:24

@ Mpxplay

Not MPXplay bug but USB vs. CTmouse problem

> If BIOS waits for an ATA/USB data, then it can block Mpxplay's soundchip
> polling too, by switching off all interrupts during the r/w process.
> The good question is that, if BIOS doesn't use IRQs, why does it disable
> interrupts while processing?
> But this is just an idea...

The USB BIOS doesn't use IRQ's at all -- it uses System Management Mode (SMM) and the System Management Interrupt (SMI). This is somewhat reminiscent of the Non-Maskable Interrupt (NMI) because it doesn't go through the Programmable Interrupt Controller (PIC), but is even worse (from the perspective of the ability to control it).

SMI has an even higher priority in the hardware than NMI, and puts the CPU into a special mode (SMM) that only the BIOS can control. And, usually, whatever happens in SMM is very slow, so it really screws things up if you're wanting any type of "real-time" response. You really don't want to let the USB BIOS control things if you care about response times.

At least on some CPU's, it is possible to temporarily disable the SMI pin of the CPU so that the USB BIOS won't interrupt anything. I know one user was able to do this because he needed "real-time" responses and the USB BIOS was really screwing him up. I don't know the exact details of what he did (I think it might have been something in the Model Specific Registers, but don't know for sure). I do know he was able to disable the SMI pin when he wanted the USB BIOS to leave him alone.

RayeR

CZ,
28.07.2016, 19:36

@ bretjohn

Not MPXplay bug but USB vs. CTmouse problem

> I do know he was able to disable the SMI pin
> when he wanted the USB BIOS to leave him alone.

Interesting, I know that it is possible to program CPU external SERR# pin routing to disable generating SMI from external sources but I don't know it can be disabled at all. I think it may be even dangerous on modern HW because SMI handles some dynamic voltage and frequency control. Second usage of SMI is for legacy HW emulation - you can programm a trigger to generate SMI when e.g. keyboard I/O port is accessed (and SMI handler then execute USB handling code for it). It's true that esp. this USB handling routines can take quite a lot of time but I think there's some limit that SMI cannot execute too long to not break the OS scheduling. I don't know exactly but this time should be much less than 1ms - this should not be so long that you could observe it by jumpy mouse movement. It may happen that due to some BUG SMI waits for some timeout that is longer than expected...

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

DOS386

29.07.2016, 16:17

@ Mpxplay

Not MPXplay bug but (NOT USB!!!) PS/2 vs. CTmouse problem

> Mpxplay v1.61 beta 5 is released on http://mpxplay.sourceforge.net

WOW! that was fast ... from b1 directly to b5 ;-)

> diffs between v1.61 beta 5 and beta 1
> -DOS: added new devices to Intel HDA soundcards, extended chip infos

COOL :-)

Thanks to all who answered.

> USB, SATA/PATA, soundchip: these are in the mainboard's south-bridge,
> BIOS can't access them parallel

Again, in my case no USB is involved, just IDE HD (ATA-33) (try to disable HD DMA ??), genuine PS/2 keyboard and rat (very hard to buy nowadays), and PCI sound card.

I'll test (see above) and additionally beta 5.

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

RayeR

CZ,
31.07.2016, 01:54

@ DOS386

Not MPXplay bug but (NOT USB!!!) PS/2 vs. CTmouse problem

> Again, in my case no USB is involved, just IDE HD (ATA-33) (try to disable
> HD DMA ??), genuine PS/2 keyboard and rat (very hard to buy nowadays), and
> PCI sound card.

Did you tried to move soundcard to a different PCI slot?

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

DOS386

01.08.2016, 09:58

@ RayeR

Not MPXplay bug but (NOT USB!!!) PS/2 vs. CTmouse problem

NO XDMA - no change
CT driver with or without wheel enabled - no change

> Did you tried to move soundcard to a different PCI slot?

not yet

> just everybody should check that nothing is worse in the DOS/console versions,
> than in the previous versions. (I mean there is no new bug)
> Please report the wrong changes only,
> don't report such (hw) bugs, which exist in the earlier versions too.

Minimal 1.61b5 test:

+ BUG with some old MPEG video+audio files (garbage noise) seems fixed (1.60 bad, 1.61b5 good)
- BUG with FLV seeking (sometimes hangs) NOT fixed (1.60 bad, 1.61b5 bad)
? BUG with very short (< 1 s) MP5 (MPEG-1-layer-3) files (MPXPLAY rejects the file) not tested

> You can use my PS2MTEST program (part of the USB driver package) to do
> some simple troubleshooting of this and see if that is really the problem.

Nice ... works ... last 2 of 4 UINT16's are always ZERO, other results are sane, both with and without mouse driver loaded.

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

DOS386

03.08.2016, 07:10

@ DOS386

Not MPXplay bug but (NOT USB!!!) PS/2 vs. CTmouse problem

Strange results from PS2MTEST:

"bad" PC (MPXPLAY pukes)

last 2 of 4 UINT16's are always ZERO, other results are sane,
wheel movements detected, no movements on the "extra-wheel" reported,
both with and without mouse driver loaded

"good" PC (MPXPLAY works)

last 2 of 4 UINT16's are NOT always ZERO, other results are strange too,
wheel movements detected, but reports movements of the extra wheel,
despite the mouse has only 1 wheel

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

bretjohn

Rio Rancho, NM,
22.07.2016, 19:32

@ Laaca

Not MPXplay bug but USB vs. CTmouse problem

Laaca:

This sounds like a problem with your national keyboard driver -- you may want to use a different one.

Back in the early days of PC's, IBM changed the "standard" keyboard layout, effectively swapping the Control and CapsLock keys, and a lot of people didn't like it. There were TSR's written that did nothing but swap the Control and CapsLock keys to make these users happy. It's possible your driver has this "option" turned on. You may be able to turn it off with some kind of command-line switch, or recompile (if you have the source code), or use a different program.

BTW, the programs designed to swap the two keys don't really work very well. This is because the keyboard hardware itself will sometimes send different codes to the computer depending on whether or not Control key is pressed in combination with other keys. So, the keyboard hardware and computer software both need to "agree" on where the Control and CapsLock keys actually are. If all you do is change the software (at least just do a simple software change) but don't change the hardware (and you can't change the hardware), you're going to have problems.

Mpxplay

25.07.2016, 20:13

@ DOS386

MPXPLAY 1.61 beta 5 -> final

Sorry, I cannot do anything with the hardware and 3rd party bugs...

btw. I think so I've finished the rework / merge of Mpxplay 1.61 / MMC,
just everybody should check that nothing is worse in the DOS/console versions,
than in the previous versions. (I mean there is no new bug)

https://sourceforge.net/projects/mpxplay/files/Mpxplay/Mpxplay%20v1.61

Please report the wrong changes only,
don't report such (hw) bugs, which exist in the earlier versions too.

https://sourceforge.net/p/mpxplay/discussion/219198/thread/95dc4d6a/

thnx
Attila

RayeR

CZ,
26.07.2016, 03:38

@ Mpxplay

MPXPLAY 1.61 beta 5 -> final

Hi,
I made a quick test of 1.61b5 under DOS playing also internet radios via swsock and didn't find any problem. Mouse wheel with ctmouse also works nice.

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

Mpxplay

27.07.2016, 06:01

@ DOS386

MPXPLAY 1.61 beta 1 2016-Apr-17 and MOUSE-BUG

> * for WAV files (but not for most other file types), the cool column
> diagram in top-left corner is sensitive to volume set during playback
>

MP2/MP3/MPC/OGG have internal spectrum analyzer, analyzing the input audio data (finally the decoder's sub-band channels are displayed as spectrum analyzer).

Spectrum analyzing of other file types (WAV,APE,FLAC,WMA,etc.) happens in the audio mixer, at the end of the audio process, including the volume change.

Rugxulo Usono, 17.11.2017, 02:23 @ Mpxplay	MPXPLAY 1.61 beta 1 2016-Apr-17 and MOUSE-BUG Post reply
	Using a Netbook as a DOS-only music player (Druaga1, 20:41)

Rugxulo Usono, 22.11.2017, 12:32 @ Rugxulo	MPXPLAY + DOS 7.1 on a netbook Post reply
	Installing DOS 7.1 on a Netbook (Druaga1, 52:49) N.B. This is more of a hackfest for the fun of it rather than anything professional, so don't blame him for not knowing literally everything.

Back to index page

22632 Postings in 2109 Threads, 402 registered users, 395 users online (0 registered, 395 guests)
DOS ain't dead | Admin contact

powered by my little forum