Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #1428 > unrolled thread

XMS transfer troubles with Turbo C

Back to article view | Back to comp.os.msdos.programmer

Contents

  XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-24 19:18 +0200
    Re: XMS transfer troubles with Turbo C Johann Klammer <klammerj@NOSPAM.a1.net> - 2014-07-24 22:00 +0200
      Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-25 08:12 +0200
    Re: XMS transfer troubles with Turbo C Ross Ridge <rridge@csclub.uwaterloo.ca> - 2014-07-25 15:54 -0400
      Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-26 16:34 +0200
        Re: XMS transfer troubles with Turbo C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-26 13:21 -0400
          Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 09:57 +0200
            Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 10:38 +0200
              Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 11:01 +0200
                Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 11:20 +0200
                  Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 12:07 +0200
                    Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 12:41 +0200
                      Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 15:46 +0200
                      Re: XMS transfer troubles with Turbo C Johann Klammer <klammerj@NOSPAM.a1.net> - 2014-07-27 16:39 +0200
                        Re: XMS transfer troubles with Turbo C Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 20:09 +0200
            Re: XMS transfer troubles with Turbo C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-27 12:32 -0400
              Re: XMS transfer troubles when AWEUTIL is loaded (exception 0D) Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 20:23 +0200
        Re: XMS transfer troubles with Turbo C Ross Ridge <rridge@csclub.uwaterloo.ca> - 2014-07-27 12:25 -0400
          Re: XMS transfer troubles when AWEUTIL is loaded (exception 0D) Mateusz Viste <mateusz.viste@localhost> - 2014-07-27 20:05 +0200
            Re: XMS transfer troubles when AWEUTIL is loaded (exception 0D) "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-07-28 22:13 -0700
              Re: XMS transfer troubles when AWEUTIL is loaded (exception 0D) rugxulo@gmail.com - 2014-07-29 15:08 -0700
                Re: XMS transfer troubles when AWEUTIL is loaded (exception 0D) Mateusz Viste <mateusz.viste@localhost> - 2014-07-30 08:25 +0200
    Re: XMS transfer troubles Mateusz Viste <mateusz.viste@localhost> - 2014-07-28 21:10 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1490 — Re: XMS transfer troubles when AWEUTIL is loaded (exception 0D)

Hi,

On Tuesday, July 29, 2014 12:13:01 AM UTC-5, Alexei A. Frounze wrote:
> On Sunday, July 27, 2014 11:05:08 AM UTC-7, Mateusz Viste wrote:
>
> > I used a temporary 'tmpseg' word here, simply because I couldn't make a 
> > direct "mov es, ds" (watcom asm is not allowing this and complains about 
> > 'invalid operands').
> 
> It's not "watcom asm". There simply isn't an x86 instruction to move a
> value from a segment register into another segment register. Look up
> your favorite x86 instruction set reference.

Yes, I was just about to respond about this. Indeed, no x86 assembler
should support such an instruction. If it does (A86? can't remember),
then it's changing it to something else behind the scenes,
e.g. "push ds // pop es".

http://stanislavs.org/helppc/mov.html

The only supported forms where segreg is source don't also include
segreg as target, only reg16 or mem16.

[toc] | [prev] | [next] | [standalone]

#1497 — Re: XMS transfer troubles when AWEUTIL is loaded (exception 0D)

Hi Alexei, Rugxulo,

On 07/30/2014 12:08 AM, rugxulo@gmail.com wrote:
> Yes, I was just about to respond about this. Indeed, no x86 assembler
> should support such an instruction. If it does (A86? can't remember),
> then it's changing it to something else behind the scenes,

That's what I suspected when I saw wasm complaining about 'invalid 
operands'. But in full truth, I didn't care much enough to bother 
checking it more closely, just threw a tmp variable in there and went away.

Thanks for taking the time to clarify, it's always good to know what's 
going on :)

cheers,
Mateusz

[toc] | [prev] | [next] | [standalone]

#1487 — Re: XMS transfer troubles

Hello all,

Just for the completeness of this thread, I'm posting a summary of the 
issue I had (well, still have) related to using XMS.

First of all, I corrected the subject of this thread - it's not about 
Turbo C anymore. Shortly after running into troubles (and because Turbo 
C 2.01 doesn't provide any clean INT chainnig function), I switched to 
OpenWatcom. The XMS problem is still the same, but OpenWatcom feels 
fine, so I am keeping it for now.

The exact problem I had/have is that when I was writing to port 0x330 
(the standard MIDI port) to play a few notes, my program was triggering 
a reboot of my PC. Then, I installed JemmEx, which told me more: the 
problem was not a 'clean' reboot, but an exception. An "Exception 0D", 
to be precise.

After struggling for days, I finally found the culprit: which doesn't 
seem to be in my code at all (not for this specific problem at least). 
The "exception 0D" trouble occurs *only* when the AWEUTIL driver is 
loaded with MIDI emulation switched on. This AWEUTIL thing is a hack 
from Creative Labs, that provides an MPU-401 emulation for my 
SoundBlaster 64 AWE sound card. As I understand it, AWEUTIL catches 
requests to the 0x330 port using some NMI magic, translates them to 
native commands of the SB64 AWE chip, and feeds them to the onboard 
"EMU8000" synth.

If I don't load AWEUTIL, then everything works fine. Well, of course I 
have no MIDI sounds, because my MIDI bytes are going into the MIDI OUT 
port of the card instead of being translated and fed to the SB64 synth, 
but when I connect a MIDI keyboard to my card, I hear it's all working fine.

The problem seems related to the fact that after writing a note to the 
port 0x330, the AWEUTIL TSR performs some "background" work, and if it 
performs this work when I happen to be in the middle of handling XMS 
calls, nasty things happen. Also, if I don't use XMS, then everything 
works fine as well (even with AWEUTIL enabled).

Looking on the internet, I see I am not the first one to suffer from 
such symptoms. Here is a link that talks about exactly the same problem 
(basically a guy that is unable to run the Privateer game with MIDI 
using AWEUTIL, because it triggers a reboot after playing a few notes):

http://www.wcnews.com/chatzone/threads/privateer-and-the-sb-awe64.3893/

Unfortunately I don't have any solution, and I am kind of doubting there 
is a "clean" solution at all to this. However, I found a workaround: if 
I wait a short time after sending each of my messages to the 0x330 port, 
then my program is working fine. Waiting 2ms is enough. I assume that 
AWEUTIL have enough time to do its hidden stuff within the 2ms I wait, 
and then I am free to do any XMS work until the next time I need to feed 
the 0x330 port with some data.

Of course another approach would be to implement a native AWE driver in 
my program, and stop using the MTU-401 interface at all, but that's yet 
another level of challenge.

cheers,
Mateusz

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.msdos.programmer

csiph-web