Re: COM int not reachable
GØnter Knab wrote: > a dos program can't reach the COM1 int 4 under dosemu. This int seems > to be mapped to int 12. The program itself can't be configured to use > this int. Hmm. That seems strange since irq4 is always mapped to int12 in dos unless you manually reprogram the master PIC. So try looking for the problem elsewhere. I can sucessfully use com ints (12 for com1 and 11 for com2) under suid-root console dos. Nothing wrong here IMHO. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED]
Re: Re: Re: question on dosemu
Hans Lermen wrote:
>> Stas Sergeev did send me a patch that solve the problem.
> hmm, what patch are we talking about here?
I have posted a potential fix to Andreas and it works.
The explanation is that if we want to prevent calling int > 0xe0, we have
to do it for ax=0x300 and not for any other functions, where bl is undefined.
I don't have any app to test it so I can be wrong. It was just a quick look
to a dpmi ref. Below is this patch, if you want.
I have also other patches including some dpmi patches, but I am still
waiting for the next official pre-patch to appear on ftp before posting them
because if the changes from 1.0.2 would be merged, it will probably be
necessary for me to rediff my patches.
>> What is not solve is the problem that my clipper application uses 99% of cpu
>> time.
> this is normal. DOS thinks it owns the whole machine and 'waits' by
> loop-polling. With hogthreshold you can tune this a bit, but if your DOS
> application isn't looping at DOSEMU expected points (e.g. the BIOS),
> than you are lost.
This is true for hogthreshold because it tries to be smart and not to slow
down the app. But why can't we add another option that will push dosemu
periodically to sleep unconditionally and slow down the execution in favour
of saving a cpu power?
This patch was sent to Andreas:
---
--- src/dosext/dpmi/dpmi.c Sat Aug 11 02:59:46 2001
+++ src/dosext/dpmi/dpmi.c Sat Aug 25 04:28:26 2001
@@ -1308,13 +1308,13 @@
if (inumber==0x0300) {
REG(cs) = ((us *) 0)[(_LO(bx) << 1) + 1];
REG(eip) = ((us *) 0)[_LO(bx) << 1];
+if ((_LO(bx) >= 0xe0) && (REG(cs) < 0xf000)) { /* avoid hardreboot !! */
+ D_printf("DPMI: Interrupt vector overwritten!");
+ leavedos(99);
+}
} else {
REG(cs) = rmreg->cs;
REG(eip) = (long) rmreg->ip;
- }
- if ((_LO(bx) >= 0xe0) && (REG(cs) < 0xf000)) { /* avoid hardreboot !! */
-D_printf("DPMI: Interrupt vector overwritten!");
-leavedos(99);
}
if (!(rmreg->sp==0)) {
REG(ss) = rmreg->ss;
-
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: Re: Re: question on dosemu
Andreas Moroder wrote: > I changed my apllication to use the Yield function in the following asm > file, but it seem sto help nothing ( This function helps very much in win > NT ) > ;; Author: Sz,l Viktor <[EMAIL PROTECTED]> This is strange since this method _is_ supported by dosemu via hogthreshold option. Try increasing the hogthreshold value. If this still doesn't help, post a full example, because the function itself seems (to me, visually) to be OKey. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mouse causes crash & dos4gw doesn't like keyboard
Keith Duthie wrote:
> The game is called Ringworld: Revenge of the Patriach. This problem could
This is really great: this game crashes when moveing the mouse and it does
*not* use dpmi. Previously I sought it is a dpmi problem, but now I see how I
was wrong.
Also now I think I understand where the real problem is.
Can you please try the attached patch?
It is not a final solution, it is just a hacks only to prove if my theory is
right. And it seems problematic to make it work properly with dpmi.
But if it solves your problem, then I hope that someone from dosemu developers
will help me to make a correct patch that will prevent from crashing also
dpmi apps.
--- src/base/mouse/mouse.c Sun Nov 12 20:02:07 2000
+++ src/base/mouse/mouse.c Tue Aug 28 02:01:53 2001
@@ -1510,6 +1510,19 @@
void
mouse_event()
{
+ if(!in_dpmi) {
+ unsigned char * ssp;
+ unsigned long sp;
+ ssp = (unsigned char *)(LWORD(ss)<<4);
+ sp = (unsigned long) LWORD(esp);
+ LWORD(esp) = (LWORD(esp) - 4) & 0x;
+ pushw(ssp, sp, REG(cs));
+ pushw(ssp, sp, LWORD(eip));
+ REG(cs) = PIC_SEG;
+ LWORD(eip) = PIC_OFF;
+ }
+ pic_icount++;
+
if (mouse.mask & mouse_events && (mouse.cs || mouse.ip)) {
if(in_dpmi && !in_dpmi_dos_int
&& !((mouse.cs == DPMI_SEG) &&
--- src/base/mouse/mouseint.c Sun Nov 12 20:04:26 2000
+++ src/base/mouse/mouseint.c Tue Aug 28 01:59:07 2001
@@ -462,9 +462,16 @@
unsigned char rBuf[MOUSE_BUFFER];
int nBytes;
+ if (pic_icount) {
+ pic_request(PIC_IMOUSE); // hack: return the request back to PIC
+ return;
+ }
+ if (mice->type == MOUSE_X)
+ mouse_event();
+ else {
nBytes = RPT_SYSCALL(read(mice->fd, (char *)rBuf, sizeof(rBuf)));
if (nBytes>0 && !config.usesX) {
m_printf("MOUSE: Read %d bytes\n", nBytes);
DOSEMUMouseProtocol(rBuf, nBytes);
- }
+ }}
}
--- src/base/misc/ioctl.c Sun Nov 12 20:02:07 2000
+++ src/base/misc/ioctl.c Mon Aug 27 02:35:07 2001
@@ -170,7 +170,8 @@
default: /* has at least 1 descriptor ready */
- if ((mice->intdrv || mice->type == MOUSE_PS2 || mice->type == MOUSE_IMPS2)
+ if ((mice->intdrv || mice->type == MOUSE_PS2 || mice->type == MOUSE_IMPS2
+|| mice->type == MOUSE_X)
&& mice->fd >= 0)
if (FD_ISSET(mice->fd, &fds)) {
m_printf("MOUSE: We have data\n");
--- src/base/dev/pic/pic.c Mon Aug 27 14:40:14 2001
+++ src/base/dev/pic/pic.c Tue Aug 28 01:52:36 2001
@@ -1214,7 +1219,8 @@
pic_seti(PIC_IRQ0, timer_int_engine, 0); /* do_irq0 in pic.c */
pic_unmaski(PIC_IRQ0);
pic_request(PIC_IRQ0);/* start timer */
- if (mice->intdrv || mice->type == MOUSE_PS2 || mice->type == MOUSE_IMPS2) {
+ if (mice->intdrv || mice->type == MOUSE_PS2 || mice->type == MOUSE_IMPS2
+|| mice->type == MOUSE_X) {
pic_seti(PIC_IMOUSE, DOSEMUMouseEvents, 0);
pic_unmaski(PIC_IMOUSE);
}
--- src/base/init/init.cSun Nov 12 20:02:07 2000
+++ src/base/init/init.cMon Aug 27 02:32:48 2001
@@ -208,7 +208,8 @@
pic_unmaski(PIC_IRQ1);
pic_seti(PIC_IRQ8, rtc_int8, 0);
pic_unmaski(PIC_IRQ8);
- if (mice->intdrv || mice->type == MOUSE_PS2 || mice->type == MOUSE_IMPS2) {
+ if (mice->intdrv || mice->type == MOUSE_PS2 || mice->type == MOUSE_IMPS2
+|| mice->type == MOUSE_X) {
pic_seti(PIC_IMOUSE, DOSEMUMouseEvents, 0);
pic_unmaski(PIC_IMOUSE);
}
--- src/env/video/X.c Sun Oct 8 00:33:40 2000
+++ src/env/video/X.c Mon Aug 27 02:26:36 2001
@@ -1531,7 +1531,8 @@
busy = 0;
#if CONFIG_X_MOUSE
- mouse_event();
+ pic_request(PIC_IMOUSE);
+// mouse_event();
#endif
#if 0
[patch] mouse driver update
Hello.
The purpose of this patch is to fix a crash when mouse moves under X.
It prevents reentering to the mouse handler by using a standart PIC model
of handling interrupts. This should work for every program including dpmi apps.
I beleave that other internal drivers should also be changed to this model
for better stability.
The patch changes alot and needs some testing.
If it does bad things or doesn't fix the problem, please let me know.
--- src/include/pic.h Wed May 2 15:22:52 2001
+++ src/include/pic.h Thu Sep 6 21:59:00 2001
@@ -65,8 +65,6 @@
#define PIC_IMOUSE 17 /* internal mouse driver */
#define PIC_IPX18 /* IPX Signal */
-#define PIC_IRQALL 0xfffe /* bits for all IRQs set. This never changes */
-
/* pic_irq_list translates irq numbers to pic_ilevels. This is not used
by pic routines; it is simply made available for configuration ease */
EXTERN unsigned long pic_irq_list[] INIT({PIC_IRQ0, PIC_IRQ1, PIC_IRQ9, PIC_IRQ3,
@@ -87,6 +85,7 @@
EXTERN unsigned long pic_isr; /* interrupt in-service register */
EXTERN unsigned long pic_iflag;/* interrupt enable flag: en-/dis- =0/0xfffe */
EXTERN unsigned long pic_icount; /* iret counter (to avoid filling stack) */
+EXTERN unsigned long pic_irqall; /* bits for all IRQs set. */
EXTERN unsigned long pic_ilevel INIT(32);/* current interrupt level */
EXTERN unsigned long pic0_imr INIT(0xf800); /* interrupt mask register, pic0 */
@@ -108,6 +107,7 @@
struct lvldef {
void (*func)();
+ void (*callback)();
intivec;
};
@@ -120,7 +120,7 @@
Bit8u read_pic1(ioport_t port); /* read from PIC 1 */
void pic_unmaski(int level); /* clear dosemu's irq mask bit */
void pic_maski(int level); /* set dosemu's irq mask bit */
-void pic_seti(unsigned int level, void (*func), unsigned int ivec);
+void pic_seti(unsigned int, void (*), unsigned int, void (*));
/* set function and interrupt vector */
void run_irqs(); /* run requested irqs */
#define pic_run() if(pic_irr)run_irqs() /* the right way to call run_irqs */
@@ -141,7 +141,7 @@
#define pic_set_mask pic_imr=(pic0_imr|pic1_imr|pice_imr|pic_iflag)
#define pic_sti() (pic_iflag=0,pic_set_mask, (void)0) /*emulate STI
*/
-#define pic_cli() (pic_iflag=PIC_IRQALL,pic_set_mask, (void)0) /*emulate CLI
*/
+#define pic_cli() (pic_iflag=pic_irqall,pic_set_mask, (void)0) /*emulate CLI
+*/
/* Experimental TIMER-IRQ CHAIN code */
extern void timer_int_engine(void);
--- src/include/mouse.h Sun Nov 12 20:02:07 2000
+++ src/include/mouse.h Tue Sep 4 16:57:16 2001
@@ -160,6 +160,7 @@
extern void DOSEMUMouseEvents(void);
extern void mouse_event(void);
+extern void do_mouse_irq(void);
extern void mouse_move_buttons(int lbutton, int mbutton, int rbutton);
extern void mouse_move_relative(int dx, int dy);
--- src/base/dev/pic/pic.c Tue Sep 4 19:56:47 2001
+++ src/base/dev/pic/pic.c Thu Sep 6 22:21:56 2001
@@ -191,6 +191,7 @@
static unsigned long pic_wirr; /* watchdog timer for pic_pirr */
static unsigned long pic_wcount = 0; /* watchdog for pic_icount */
unsigned long pic_icount_od = 1; /* overdrive for pic_icount_od */
+unsigned long pic_irqall = 0xfffe;
#if 0
unsigned long pic0_imr = 0xf800; /* IRQs 3-7 on pic0 start out disabled */
unsigned long pic1_imr = 0x07f8; /* IRQs 8-15 on pic1 start out disabled */
@@ -216,15 +217,16 @@
NEVER};
#define PNULL (void *) 0
-static struct lvldef pic_iinfo[32] =
- {{PNULL,0x02}, {PNULL,0x08}, {PNULL,0x09}, {PNULL,0x70},
- {PNULL,0x71}, {PNULL,0x72}, {PNULL,0x73}, {PNULL,0x74},
- {PNULL,0x75}, {PNULL,0x76}, {PNULL,0x77}, {PNULL,0x0b},
- {PNULL,0x0c}, {PNULL,0x0d}, {PNULL,0x0e}, {PNULL,0x0f},
- {PNULL,0x00}, {PNULL,0x00}, {PNULL,0x00}, {PNULL,0x00},
- {PNULL,0x00}, {PNULL,0x00}, {PNULL,0x00}, {PNULL,0x00},
- {PNULL,0x00}, {PNULL,0x00}, {PNULL,0x00}, {PNULL,0x00},
- {PNULL,0x00}, {PNULL,0x00}, {PNULL,0x00}, {PNULL,0x00}};
+static struct lvldef pic_iinfo[32] = {
+{PNULL,PNULL,0x02}, {PNULL,PNULL,0x08}, {PNULL,PNULL,0x09}, {PNULL,PNULL,0x70},
+{PNULL,PNULL,0x71}, {PNULL,PNULL,0x72}, {PNULL,PNULL,0x73}, {PNULL,PNULL,0x74},
+{PNULL,PNULL,0x75}, {PNULL,PNULL,0x76}, {PNULL,PNULL,0x77}, {PNULL,PNULL,0x0b},
+{PNULL,PNULL,0x0c}, {PNULL,PNULL,0x0d}, {PNULL,PNULL,0x0e}, {PNULL,PNULL,0x0f},
+{PNULL,PNULL,0x00}, {PNULL,PNULL,0x00}, {PNULL,PNULL,0x00}, {PNULL,PNULL,0x00},
+{PNULL,PNULL,0x00}, {PNULL,PNULL,0x00}, {PNULL,PNULL,0x00}, {PNULL,PNULL,0x00},
+{PNULL,PNULL,0x00}, {PNULL,PNULL,0x00}, {PNULL,PNULL,0x00}, {PNULL,PNULL,0x00},
+{PNULL,PNULL,0x00}, {PNULL,PNULL,0x00}
Re: Is the dosemu project maintained?
George Petri wrote: > 1. To compile DOS programs > 2. To play games > Point 1 works fine but DosEMU has MAJOR problems with Point 2. > This is because sound support is pathetic and 16-bit SVGA support What about root console dosemu instead of xdos? SVGA support seems to work well under console. And sound support is problematic because it requires a DMA emulation and DSP emulation - both things are difficult to implement. Just motivate someone by paying him and you'll get it :) > is almost non-existent. And DPMI needs a little work. DPMI have some permanent problems that will probably never be fixed. There are also some bugs that can be fixed, but don't count on it too much :) You can always try to fix it yourself as many users do (including me:) > Now, when and will these problems be fixed? Does anyone in the Do you want to know the date? Look, it's free software. People mostly do what they need and when they need. > I am *most* annoyed that I can't play many games properly in DosEMU. What prevents you from using, say, vmware? > If Windows 98 can do it, Linux should be able to, too :). This is not correct. Win98 allows dos programs to directly access hardware so any dos program under win98 can crash the entire system (I can give you an examples if you want). This is unacceptable under linux. You can compare dosemu with WinNT dos session and dosemu will mostly win. As a user, I also have to admit that some parts of dosemu are really not maintained at all and it is sad. That is why when I felt need to use a special backup hardware called arvid (www.arvid.ru) under dosemu and found it unusable, I had only one choice: to start fixing it myself. Now I almost have no problems using it (I am still hoping that Hans Lermen will accept my PIC fixes, or using this hardware will not be possible for others). The advantage of GPL soft is that you always have sources and encouraged to do what you need with them. PS: I apologize to dosemu team. Hope I did not offended anyone by this flame. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem formatting disk (a: or b:)
Narendra wrote: > problem in formatting a removable disk (a or b) by using format in xdos. Do you really need to format it in dosemu? Why don't you just use mkdosfs instead? - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dosemu and dpmi application
Marcus Roeckrath wrote: > I discovered that if you run the old dosemu code with the new kernel it > works well *provided* that it is run by root. Suid root is not enough. I > cannot explain this, but this is actually happening... > I would also appriciate any hints. The answer is here: http://marc.theaimsgroup.com/?l=linux-msdos&m=99263649830327&w=2 - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dosemu and dpmi application
Stas Sergeev wrote: > Marcus Roeckrath wrote: > > I discovered that if you run the old dosemu code with the new kernel it > > works well *provided* that it is run by root. Suid root is not enough. I > The answer is here: > http://marc.theaimsgroup.com/?l=linux-msdos&m=99263649830327&w=2 And this is only for dosemu-1.0.2. If you really mean *old* dosemu, not 1.0.2, then it is not an answer to your question, sorry. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dosemu sessions crashing after 30 mins of keyboard inactivity
"David Milligan" wrote:
> Some of our (and others) programmes appear to either "crash" or "pause" if
> they are left running for around 30 minutes or more.
Is this with dosemu-1.0.2?
> This is especially apparent in our programmes which have a screen saver
> feature. The screen saver routine is pretty simple and does some screen
> writes, keyboard idle loop, and some Novell semaphore checking. It does also
Are you playing with timer's speed? Are you using timer-related delays?
> I haven't determined conclusively what happens but sometimes the programmes
> get "stack overflow" errors, sometimes just lock permanently, sometimes get
Seems like PIC problems again...
> Some more tidbits :-
> get out of screen saver or something else) the CPU util in TOP for that
> DOSEMU session goes up to >90%. Tracing system calls, it repeats a sequence
> of vm86() calls over and over.
This is "normal" behavior.
> While a fix for this behaviour would be good a "fudge" such as putting some
> kind of dumby key press in the dosemu keyboard source may get around this.
You can try to implement such a workaround but I doubt you will ever get it
into the official version (just IMHO).
> Can anyone point me in the direction of what to do here?
Well, in case you are really going to fix it, you should start with the
following:
- apply the attached patch. It will increase the log file limit up to 30Mb and
make it circular, else dosemu will just exit when log size reach 10Mb (patch
untested).
- make a log: dosemu -D9+grI -o /tmp/dosemu.log
- as the PIC implementation is very buggy, it would be a good idea to
make a separate log for PIC with -D9+r option. I beleave that the PIC is the
root of all evil for a *random* crashes and stack overflows.
Ok, making everything mentioned above should be a good starting point
for hunting such a bug. The logs should give you a clue such as what is failing.
--- src/base/misc/utilities.c Wed Oct 4 13:53:20 2000
+++ src/base/misc/utilities.c Sun Oct 29 19:52:16 2000
@@ -51,7 +51,7 @@
#define INITIAL_LOGBUFSIZE 0
#endif
#ifndef INITIAL_LOGBUFLIMIT
-#define INITIAL_LOGFILELIMIT (10*1024*1024)
+#define INITIAL_LOGFILELIMIT (30*1024*1024)
#endif
#ifdef CIRCULAR_LOGBUFFER
@@ -213,15 +213,16 @@
log_written += fsz;
if (log_written > logfile_limit) {
fflush(dbg_fd);
-#if 0
+#if 1
ftruncate(fileno(dbg_fd),0);
fseek(dbg_fd, 0, SEEK_SET);
log_written = 0;
-#endif
+#else
fclose(dbg_fd);
shut_debug = 1;
dbg_fd = 0; /* avoid recursion in leavedos() */
leavedos(0);
+#endif
}
}
}
Re: DOSEmu require root access for console graphics, while Win2K doesn't???
<[EMAIL PROTECTED]> wrote: > As you may know, to have fast, fullscreen console graphics, DOSEmu must be > run as root or SUID root. > (please note that a small bug in 1.0.2 prevents you from running as root but AFAIK, it prevents from running SUID, but running _as_ root works. > Hans Lerman posted a small fix a while ago, anyway...). He already made an official fix available on ftp in 'fixes' directory so the problem has now gone. > My question is: How come Win2K doesn't require you to run NTVDM as > Administrator or anything like that but *still* has fast, fullscreen > graphics? Note that newer svgalib also does not require root, but it means nothing since it uses special kernel module. So there can be different approaches. I don't know much about windows, but it seems that the situation is the same as with svgalib: WinNT/2K does not allow dos progs to access any hardware (and you can't change this by modifying privileges) but the video card. It is allowed to be accessed directly via ports: all my programs that sets non-standard video modes works. But if I set some VESA modes and then press Alt-Enter, my NT locks:) I think it is possible to make dosemu to use svgalib's kernel module so it wold not require root for video either. But I am not shure if this approach would really minimize a risk of the direct hardware access. So, the only way to get *fast* fullscreen graphics is to allow the program to access video hardware directly. (suid-)root is just an easy way to do this. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I've got problem
slaanesh wrote:
> I need help with dosemu-1.0.1-10. I installed dosemu, freedos and xdos
Thing to try: install latest version dosemu-1.0.2.1
> on my computer. I set in dosemu.conf line "$_hdimage = bootdir" where i
> put dos files ( /var/lib/dosemu/bootdir). However when i type dos or
> xdos on the console i've got repply "Segmentation fault (core dumped)"
Even if you have incorrect configuration, it shouldn't crash so early (if it
dumps core, I suppose the crash occured before SEGV hanler was set).
> and i can't fix it.
But you can do backtrace using gdb with generated core file and make a
bugreport (recompile dosemu with debug info at first).
Also try the attached patch. I am using it to fix the same problem.
--- src/base/init/config.c Sun Oct 15 23:55:41 2000
+++ src/base/init/config.c Mon Aug 13 19:52:58 2001
@@ -628,7 +628,10 @@
char *p = getenv("DOSEMU_OPTIONS");
if (p) {
memset(usedoptions,0,256);
-do usedoptions[(unsigned char)*p] = *p; while (*++p);
+while (*p) {
+ usedoptions[(unsigned char)*p] = *p;
+ p++;
+ }
}
}
Re: dosemu and 2.4 (mandrake) kernels
Russell Poyner wrote: > PS. I am contacting the vendor of avimark to try and decipher the > mysterious "Runtime error 200" message. This error message is magic and this question is asked very frequently. Try starting this program before starting your program: http://www.geocities.com/stssppnn/sdiv.zip For more info I suggest you to search google. This problem is well-known and not dosemu-related anyway. If the executable of your program is not packed, you can also try this trick: find a hex sequence F7 D0 F7 D2 B9 37 00 F7 F1 and replace it with, for example, B8 FF FF BA FF FF 90 90 90 - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: nothing works
Martin 'pisi' Paljak wrote: > time, no program that uses dos4gw.exe [whatever it is, I'm not a dos > professional] doesnt work. If i'm not mistaken this one provides some kind > of memory managment or something. Maybe there is a way to make them work > somehow? Definitely, there is. Everything (almost) must work. dos4gw can use dpmi, which is supported by dosemu. > any suggestions ? What your dosemu.conf looks like? I bet you just have something configured incorrectly. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Doom, Duke 3D, etc & p-mode POPF not trapped
"Vlad Romascanu (LMC)" wrote: > it seems that in p-mode, if cpl > iopl, popf instructions are not trapped. No, if cpl > iopl, they *are* trapped, and otherwise they are executed. > under window$ nt this freezes the dos session (virtual interrupts are never > reenabled because popf is not trapped). This can be only if IOPL=3 (because CPL==3 in VM86 always), which is impossible in a multitasking OS like WindowsNT or Linux. If this problem really exist under WinNT, then it is nothing more than a bug in it's VM monitor. I don't know about NT, but older Linux kernels really have this bug. > my question is: how does dosemu work around this limitation? There is no limitation. Actually, linux kernel deals with this instructions, not dosemu itself, see vm86.c from kernel sources. The problem is that there was a bug in the kernel which sometimes prevented dosemu from reacting to such instructions and syncing its internal flags with virtual IF, but I have fixed this somewhere around 2.4.7, so, if you have this problem - upgrade your kernel and popf will be trapped properly. Anyway, I am curious about how you have triggered this problem with doom, since this game always works perfectly under dosemu. And I am even more curious if there is the same bug also in NT. If it is, then someone in Microsoft simply steals code from Linux kernel:) - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Doom, Duke 3D, etc & p-mode POPF not trapped
Hans Lermen wrote: > > it seems that in p-mode, if cpl > iopl, popf instructions are not trapped. > correct. > DPMI under DOSEMU runs in normal Linux user space, hence protected mode > with IOPL=0 and CPL=3. > In protected mode popf _never_ traps (except for stack fault), from > the Intel Programmers Manual: Oops, sorry, didn't know about this. Knowing that it *is* trapped in VM86, I assumed that the same rules are correct also for protmode/dpmi since IOPL and CPL are the same as in VM86 and popf doesn't have enough privs... And the described limitation is also valid for VM86 on older linux kernels which doesn't return to dosemu when VIF is changed hence leaving it with disabled ints. So there are seems to be two similar limitations, not one. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
DMA-Sound support in dosemu
Hello.
Yesterday I have looked into the sound code of dosemu and found it in not
as miserable state as I expected after so many complains in this list.
Now I already made some programs to work with sound: pv (mp3 player),
iplay (stm player) some other utilities and some games.
The fact that I don't have a sound card appears to be not a big problem: I have
pc-speaker, and that just required some more hacks.
The attached patch does not solve all of the sound problems in dosemu, but
it is probably still worth to test, though it is a bit hackish yet.
Mostly it must fix DMA Auto-Init modes, but also improves direct DSP writes a
little.
And, as I can't test it very well myself without a sound card, report the
results, please.
The diffs are against dosemu-1.1.2, but should work with 1.0.2 either.
--- src/include/dma.h Sat Nov 17 05:40:34 2001
+++ src/include/dma.h Sun Nov 18 00:15:35 2001
@@ -31,6 +31,7 @@
void dma_drop_DACK(int channel);
void dma_assert_DREQ(int channel);
void dma_assert_DACK(int channel);
+int dma_get_block_size (int channel);
#define DMA_HANDLER_READ 1
--- src/include/sound.h Mon Oct 29 23:01:37 2001
+++ src/include/sound.h Sun Nov 18 01:13:06 2001
@@ -94,9 +94,9 @@
__u8 data; /* Data is available */
__u8 write_size_mode; /* Are we writing the upper or lower byte */
__u8 last_write;/* First part of a multi-byte instruction */
- __u16 length;/* Length of the DMA transfer */
- __u16 blocksize; /* **CRISK** Block size of transfer */
- __u16 bytes_left; /* No. of bytes left in current blk */
+ int length;/* Length of the DMA transfer */
+ int blocksize; /* **CRISK** Block size of transfer */
+ int bytes_left; /* No. of bytes left in current blk */
/*
* This is the maximum number of bytes transferred via DMA. If you turn
* it too low, the dosemu-overhead gets too big, so the transfer is
@@ -105,7 +105,7 @@
* jump in too high steps
*/
#define MAX_DMA_TRANSFERSIZE 512
- __u16 dma_transfer_size;
+ int dma_transfer_size;
__u8 empty_state; /* what we have to do when transfer ends */
#define DREQ_AT_EMPTY 1
#define IRQ_AT_EMPTY 2
@@ -154,7 +154,7 @@
void (* DMA_stop)(void);
int (* DMA_complete_test)(void);
void (* DMA_complete)(void);
- void (* DMA_set_blocksize)(__u16); /* **CRISK** */
+ void (* DMA_set_blocksize)(int, int); /* **CRISK** */
/*
* Miscellaneous Functions
@@ -267,6 +267,7 @@
*/
#define DSP_QUEUE_SIZE 64
+#define DSP_CMD_QUEUE_SIZE 5
EXTERN struct SB_queue_t {
__u8 output[DSP_QUEUE_SIZE]; /* Output Queue */
--- src/base/dev/dma/dma.c Mon Oct 29 23:01:37 2001
+++ src/base/dev/dma/dma.c Sun Nov 18 00:22:16 2001
@@ -180,7 +180,7 @@
dma[controller].status |= mask;
- if(!dma[controller].i[ch].mask)
+// if(!dma[controller].i[ch].mask)
activate_channel (controller, ch);
}
@@ -602,8 +602,21 @@
h_printf ("DMA: Wrote 0x%x into Channel %d Length (Byte %d)\n", value,
(dma_c *4) + channel, dma[dma_c].ff);
+ if (dma[dma_c].ff)
+h_printf("DMA: Transfer size set to %d\n",
+ dma_get_block_size((dma_c * 4) + channel) + 1);
dma_toggle_ff (dma_c);
+}
+
+int dma_get_block_size (int channel)
+{
+ int controller, ch;
+
+ controller = (channel & 4) >> 2;
+ ch = channel & DMA_CH_SELECT;
+ return (dma[controller].length[ch].data[0] +
+ (dma[controller].length[ch].data[1] << 8));
}
inline void dma_write_mask (int dma_c, Bit8u value)
--- src/arch/linux/dosext/sound/linux_sound.c Mon Oct 29 23:01:37 2001
+++ src/arch/linux/dosext/sound/linux_sound.c Sun Nov 18 01:55:05 2001
@@ -61,8 +61,10 @@
/* New fragment control - AM */
static int sound_frag_size = 0x9; /* ie MAX_DMA_TRANSFERSIZE (== 512) */
+static int sb_frag_size= 512;
static int num_sound_frag = MAX_NUM_FRAGMENTS;
static int extra_buffer= 8000*BUFFER_MSECS/1000;
+static int bits_per_samp = 0;
/* MPU static vars */
static int mpu_fd = -1; /* -1 = closed */
@@ -70,9 +72,11 @@
extern void sb_set_speed (void); /* From sound.c */
-void linux_sb_dma_set_blocksize(__u16 sb_blocksize)
+void linux_sb_dma_set_blocksize(int sb_blocksize, int dma_blocksize)
{
- __u16 blockbits, oss_blocksize, oss_blocknum;
+ int blockbits, oss_blocksize, oss_blocknum;
+
+ sb_frag_size = sb_blocksize;
/*
* The blocksize we are passed is the actual number of bytes to include in a
@@ -93,10 +97,10 @@
* starts.
*/
- if(sb_blocksize > MAX_DMA_TRANSFERSIZE) {
+ if(dma_blocksize > MAX_DMA_TRANSFERSIZE) {
oss_blocksize = MAX_DMA_TRANSFERSIZE;
} else {
-oss_blocksize = sb_blocksize;
+oss_blocksize = dma_blocksize;
}
block_size = oss_blocksize;
@@ -110,11 +114,11 @@
/* This is intentionally here, because fragments should not be greater
than the SB block size */
- sb_blocksize += extra_buffer;
+ dma_blocksize += extra_buffer;
- oss_blockn
Re: Writing plugin code
Rodrigo Gallardo wrote: > When receiving commands from the DOS program, the emulation sets a > timer. After it expires, it tries to raise an interrupt (IRQ 6), so > the DOS programm will go on. In my timer handler, I call > pic_request(pic_irq_list[6]). I beleive you can do pic_request(PIC_IRQ6) instead, which is similar, but looks better. > The log output indicates that the IRQ is > set to be triggered, but it never is! You have to check if the apropriate bit is set in pic_irr, you can see it in the PIC log (-D9+r). > floppy_plugin_dosemu_irq = pic_irq_list[6]; > pic_seti(floppy_plugin_dosemu_irq, floppy_irq_trigger, 0); > pic_unmaski(floppy_plugin_dosemu_irq); > So, anyone knows what could be wrong? Check your bit in the pic_imr and pice_imr. Also check VIF flag. The function that activates an interrupts is called run_irqs() so you have to trace this function to find out why it doesn't activate your int. The problem with this function is that it is written in asm. But there are some efforts to rewrite it in C. I can mail you a patch that provides a C version if this is what you need. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DMA-Sound support in dosemu
Oliver Ob wrote: > > Now I already made some programs to work with sound: pv (mp3 player), > > iplay (stm player) some other utilities and some games. > > The fact that I don't have a sound card appears to be not a big problem: I > have > > pc-speaker, and that just required some more hacks. > what games? The complete list is too long:) But it is worth to mention SimCity2000, Settlers2, Dune, ThemeHospital, Grand Thief Auto and some other games that use DMA transfer as well as some older games that use direct DAC writes. Doom and other famous ID games doesn't work (and probably never will), the reason was pointed out by Vlad Romascanu (it just locks dosemu, and if it was suid-root under console, it locks the whole linux box when sound is enabled). > and what have you changed? The patch was attached to my letter, didn't you notice it? Anyway, it was mostly a hacks and workarounds. The only purpose I posted it here was to enshure whether it works for the real soundcards, since the only sound device I have is pc-speaker and I had to make some tricks to adjust the code for that "device". There were several people complaining the sound support in dosemu. As they are unwilling to test the patch, they'll have to complain further, until someone with a soundcard will fix their problems:) - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: DMA-Sound support in dosemu
Hello. "Vlad Romascanu (LMC)" wrote: > For Doom and the like it should be easy to incorporate a workaround into > DosEmu (it's tougher to do in WinNT because NT's NTVDM.EXE does not > expose a proper interface for what is needed, but anyway). According to this, it would be easier to patch doom itself: http://www.jsiinc.com/dl/SoundFX.txt > If interrupts have been > disabled for more than a certain amount of time (easy to detect from within > the emulated IRQ0 generator, maybe coupled with the CLI/STI trap handler), > DosEmu could force the enabling of interrupts. Then Doom should then get > past the "Initializing timer..." lockup and work properly. Can someone test > that? Yes, it should, because it works when I commented out a dpmi_cli() call from where it must be so that ints are not disabled at all. Wait for a certain period and reenable ints could probably be a good workaround, but there are seem to be some problems: this cli/popf sequence really *locks* dosemu, it's timer stops, it eats 100% CPU, it doesn't receive signals anymore, nothing, only kill -9. And if it was suid-root and started under console with RAW keyboard access enabled, then only magic keys helps because keyboard stays in the RAW mode. I don't know where the problem is, maybe someone from dosemu developers knows this, but it seems that cli in PM does something more than just disabling an emulated ints under dosemu. There was a similar problem for realmode (and for DPMI's realmode callbacks as well, that is why I described it when it was not necessary to, sorry:), but it appears to be a bug in the linux kernel and was fixed in 2.4.7. But as PM dpmi code executes in the userspace, now the problem is elsewhere. BTW, you suggested me to visit your page to find out undocumented DSP commands. One very old game called Millenium writes to DSP the following commands: 0x06, 0x6b and 0xe2. Then it reads from a Reset address, while Creative's manuals claims that it is Write-only. I failed to find in your code something that could give me a hint such as what this program expects from DSP... How bad the fact that there is no a pc-speaker driver for NT so that I could try your code out. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: DMA-Sound support in dosemu
Hello.
"Vlad Romascanu (LMC)" wrote:
> No good; most of the games patched using cli2nop crash after a few seconds;
> -- if the game uses sti/cli for mutual exclusion then keeping interrupts
> enabled all the time won't guarantee any mutual exclusion. If DosEmu *does*
> disable interrupts but forcefully re-enables them later (as opposed to
> always keeping them enabled), then you're somewhat safer.
I agree.
> > receive signals anymore, nothing, only kill -9.
> Linux timer. All the rest (i.e. keyboard) should be dead except for magic
> key combinations, this is normal.
I can continue: it stops DMA, it stops logging (even timer events), it ignores
dosdebug connections, it ignores window closing when it is under X.
Not what I could call "normal" behavior:)
Anyway, I have just found a cure, see attachment. So I think if this is applied,
it would be possible to do also what you suggest.
> independently of the CPU's frequency). If the program reads several times
Yes, 4 times.
> in a row from port 0x226 (I think that's the reset one) then it's just a
> delay trick.
Thanks.
> Command 0xe2 was a pain to reverse-engineer. Are 0x06 and 0x6b actual
> commands, or arguments to a command (e.g. 0xe2)?
Exactly, that were arguments to 0xe2:) Anyway, until 0xe2 is unknown, this
Millenium game doesn't produce any sound under dosemu.
But atleast it doesn't lock now, when arguents are handled "correctly", i.e.
known what is to ignore.
> Get a sound card! Or are you out of ISA/PCI slots? :)
Exactly, you guessed also this. How are you doing it?:)
Damn this engineers who put only 1 ISA (or even 0!) to the MB!
> There is a PC-speaker driver for Windows, but it is fully synchronous (i.e.
I knew it was for win95 but never seen it for NT.
--- src/dosext/dpmi/dpmi.c Mon Oct 29 23:01:37 2001
+++ src/dosext/dpmi/dpmi.c Thu Nov 22 03:08:48 2001
@@ -2502,13 +2519,17 @@
#else
if (_cs != UCODESEL){
#endif
-#if 1
+#if 0
if (in_win31 || (dpmi_eflags & IF)) {
D_printf("DPMI: return to dosemu code for handling signals\n");
Return_to_dosemu_code(scp,0);
} else dpmi_eflags |= VIP;
#else
/* DANG_FIXTHIS We shouldn't return to dosemu code if IF=0, but it helps - WHY? */
+/*
+ Because IF is not set by popf and because dosemu have to do some background
+ job (like DMA transfer) regardless whether IF is set or not.
+*/
D_printf("DPMI: return to dosemu code for handling signals\n");
Return_to_dosemu_code(scp,0);
#endif
Re: DMA-Sound support in dosemu
Oliver Ob wrote: > Hi Bart, please be so kind as to What do you need? Sound support is incomplete anyway so not only Doom is silent. Enjoy Wolf for now:) > technically exlpain why "no sound" with DOS-DOOM Quoting http://www.jsiinc.com/dl/SoundFX.txt: --- Execution of an CLI or STI instruction causes a trap to the emulator which then updates the virtual interrupt state. Many programs save the interrupt state before disabling them by executing a pushf instruction. Unfortunately due to a limitation in the Intel architecture when running a process in protected mode at a privilege level above 0 the popf instruction that would normally restore the interrupt state does not cause a trap and hence the virtual interrupt state in the VDM gets out of step with what the program expects and further virtual interrupts such as timer, mouse or sound card are not delivered to the program. The only solution is to fix the application. --- There are still some workarounds to try so all is not lost. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: virtual 8086
pp wrote: > I got dosemu 1.0.2.1, and after trying to tun application I got such an error: > "Phar Lap err 35: The 386 chip is currently executing Phar Lap and other dos-extenders are used to work under dosemu if dpmi is enabled. > What should I do? Check $_dpmi option in your dosemu.conf, it is probably disabled. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: DMA-Sound support in dosemu
Hello. "Vlad Romascanu (LMC)" wrote: > If interrupts have been > disabled for more than a certain amount of time (easy to detect from within > the emulated IRQ0 generator, maybe coupled with the CLI/STI trap handler), > DosEmu could force the enabling of interrupts. Then Doom should then get OK, after some messing around DMA code, I managed Doom to work with sound this way... > past the "Initializing timer..." lockup and work properly. Can someone test > that? Tested, not good. Doom uses cli/popf not only on startup but each time it produces the sound. So, if the delay is 1 sec and you are running with a chainsaw which always produces sound, you will see a frequent pauses - slideshow. And if the delay is reduced to several msecs, Doom works fine but the workaround triggers also for other apps compromissing the stability. Btw, I patched CPUemu to update dosemu flags on popf and Doom works with sound, but emulated CPU is too slow:( - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Program hogs CPU
Ross Boylan wrote: > I have tried various settings of hogthreshold, but I can't prevent a > certain program (GrandView) from grabbing all the CPU when it runs. > Is there something I can do about this? Currently there is probably nothing to do, but you can still try playing with nice(1). > The program is a full-screen character mode program (an outliner) from > the DOS era. It does respond to the mouse, which I suspect is the > problem (that is, the program responds to the mouse by polling > continuously). dosemu can handle mouse polling condition. But it doesn't handle (AFAIK) direct keyboard polling via port 0x60 and that seems to be a problem in most cases. > When I run it under MS Win 2K it consumes almost no CPU. There are some plans on improving the setuation during the current or next devcycle of dosemu, but you know how slowly the things are going... > By the way, I find the description in README.txt a bit confusing. It It is confusing in many places:) > says: > $_hogthreshold = (1) # 0 == all CPU power to DOSEMU > # 1 == max power for Linux > # >1 the higher, the slower DOSEMU will be The last line is probably a mistake: there are alot of places in dosemu sources with the code like this: if(++trigger>=config.hogthreshold) usleep(...); > Does this mean that 1 essentially is the same as setting the value to > infinity? AFAICS, 0 is "infinity" here. The more the value, the more CPU power dosemu eats, I think. > The discontinuity of scale is a bit surprising; based on > the description of >1 I would expect 1 means "DOSEMU runs as fast as > possible". It just means that someone who wrote this doc was not as good in Math as you are:)) - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Experemental patch: prevent from hogging CPU
Hello.
The complain that dosemu hogs CPU when program is idle, appears to be
very frequent in this ML, so I decided to post my experemental patch here
in hope that someone who have this problem, will test it. I beleave that the
problem is that dosemu doesn't release time slices when the program polls
keyboard via int16 or directly via port0x60. I want some feedbacks just to
know if my guesses are correct and the problem is really with polling the
keyboard (there could be lots of other reasons).
The patch is highly UNtested, so be prepared to everything. It can even
yield rejects on "stable" dosemu, because I use devel version, but this is
unlikely.
So, everyone who wants to see this problem fixed in the near future, is
encouraged to test this and write a feedback.
--- src/base/async/int.c Mon Oct 8 01:31:55 2001
+++ src/base/async/int.c Mon Oct 8 13:27:20 2001
@@ -1414,6 +1414,12 @@
else
return NO_REVECT;
+ case 0x16: /* Keyboard */
+if (config.hogthreshold)
+ return REVECT;
+else
+ return NO_REVECT;
+
#if 0 /* no need to specify all */
case 0x10: /* BIOS video */
case 0x13: /* BIOS disk */
@@ -1494,13 +1500,24 @@
return;
}
-#ifndef USE_NEW_INT
/* KEYBOARD */
static void int16(u_char i) {
+extern Bit8u port60_buffer;
+static Bit16u oldESP;
+static int trigger = 0;
real_run_int(0x16);
-return;
+if(config.hogthreshold) {
+ if((_AH==0x01 || _AH==0x11) && (port60_buffer & 0x80) &&
+oldESP==_ESP && READ_WORD(BIOS_KEYBOARD_BUFFER_HEAD) ==
+READ_WORD(BIOS_KEYBOARD_BUFFER_TAIL)) {
+ if(++trigger >= config.hogthreshold*100) {
+ usleep(INT2F_IDLE_USECS);
+ trigger=0;
+ }
+ } else trigger=0;
+ oldESP=_ESP;
+}
}
-#endif /* not USE_NEW_INT */
/* BASIC */
static void int18(u_char i) {
@@ -2118,9 +2135,7 @@
interrupt_function[0x13] = int13;
interrupt_function[0x14] = int14;
interrupt_function[0x15] = int15;
-#ifndef USE_NEW_INT
interrupt_function[0x16] = int16;
-#endif /* not USE_NEW_INT */
interrupt_function[0x17] = int17;
interrupt_function[0x18] = int18;
interrupt_function[0x19] = int19;
--- src/base/keyboard/serv_8042.c Fri Sep 7 00:28:13 2001
+++ src/base/keyboard/serv_8042.c Mon Oct 8 02:08:16 2001
@@ -22,6 +22,7 @@
*
*/
+#include
#include "emu.h"
#include "iodev.h"
#include "int.h"
@@ -272,10 +273,22 @@
Bit8u keyb_io_read(ioport_t port)
{
Bit8u r = 0;
+ static Bit8u oldval = 0;
+ static int trigger = 0;
switch (port) {
case 0x60:
r = read_port60();
+
+ if(config.hogthreshold) {
+if((r & 0x80) && r == oldval) trigger++;
+ else trigger=0;
+ if(trigger >= config.hogthreshold*10) {
+ usleep(INT2F_IDLE_USECS);
+ trigger=0;
+}
+oldval=r;
+ }
/* We ought to untrigger IRQ1, in case DOS was reading port60h with interrupts off,
* but currently the PIC code doesn't support this. */
Re: Slow printing
"Steve K. Sears" wrote: > Got it down to 35 seconds before it starts to print by following your > suggestion. Still don't know why it takes that long to process a 2K > ASCII file. > I thought maybe dosemu was hogging all the resources (from reading > previous threads), When dosemu hogs CPU, it actually means that it lets the dos program to hog CPU so the program is executed faster, but other linux processes are executed slower. Dosemu itself does not require a lot of CPU power. > but it only takes about 1% when this program runs (or > even prints). And this can be the the reason why you have slow execution or slow printing: dosemu is not allowed to pass alot of CPU power to the dos app. Try allowing dosemu to hog CPU and see if it helps. To do that, you should set $_hogthreshold to 0. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Does cmdline.com still work?
Hello.
Sergey Suleymanov wrote:
> I've used cmdline.exe and anything work fine. But now
> cmdline.com (link to generic.com ) doesn't do his work. Has
> something broken?
Seems like that. The forgotten braces and other wierd things indicates that
the code was never executed since porting to coopthreads (or am I missing
something?).
Try the attached patch.
I don't know whether it fixes all the problems, but at least it makes
cmdline.com to work for me.
--- src/plugin/commands/cmdline.c Sat Nov 17 05:40:34 2001
+++ src/plugin/commands/cmdline.c Sat Dec 1 20:34:40 2001
@@ -23,23 +23,27 @@
int msetenv(char *,char *);
-#define CMDBUFFSIZE 1
+#define CMDBUFFSIZE 256
/* This program just reads stdin... */
int cmdline_main()
{
char *buff = malloc(CMDBUFFSIZE), *p, *q, *endb;
- if (!buff)
+ if (!buff) {
perror("malloc failure");
return(1);
+ }
*(endb = buff + read(0,buff,CMDBUFFSIZE)) = '\0';
for (p = buff; p < endb; p = q + strlen(q)+1)
if (*p != '-' && ((q = strchr(p,'='))!=0)) {
*q++ = '\0';
- if (msetenv(p,q))
+ if (msetenv(p,q)) {
+ free(buff);
return (1);
}
+ }
else q = p;
+ free(buff);
return 0;
}
Re: Print Screen key on Dosemu (again)
Pablo Bacherer E. wrote:
> Is it really so difficult to make the print screen key work on dosemu (as
> expected)?
Yes, sometimes it turns out to be really a bit difficult to get working a thing
that is not implemented yet:)
> I've unsuccessfully tried with Dosemu 1.0.1 under the following conditions:
Upgrade to 1.1.2 and try the attached patch which (hopefully) implements a
priliminary PrintScreen support.
> Any ideas?
Let me know whether it works for you.
--- src/include/lpt.h Sat Nov 17 05:40:34 2001
+++ src/include/lpt.h Wed Dec 12 20:26:57 2001
@@ -30,6 +30,12 @@
};
+/* public functions */
+int printer_open(int prnum);
+int printer_close(int prnum);
+int printer_flush(int prnum);
+int printer_write(int prnum, int outchar);
+
/* status bits */
#define LPT_TIMEOUT 0x1
#define LPT_IOERR 0x8
--- src/base/async/int.c Fri Nov 30 20:01:10 2001
+++ src/base/async/int.c Wed Dec 12 20:14:28 2001
@@ -27,6 +27,7 @@
#include "disks.h"
#include "bios.h"
#include "iodev.h"
+#include "lpt.h"
#include "bitops.h"
#include "xms.h"
#include "int.h"
@@ -1503,6 +1508,21 @@
}
}
+static void do_print_screen() {
+int x_pos, y_pos;
+ushort *base=SCREEN_ADR(READ_BYTE(BIOS_CURRENT_SCREEN_PAGE));
+g_printf("PrintScreen: base=%p, lines=%i columns=%i\n", base, li, co);
+printer_open(1);
+for (y_pos=0; y_pos < li; y_pos++) {
+ for (x_pos=0; x_pos < co; x_pos++)
+ printer_write(1, READ_BYTE(base + y_pos*co + x_pos));
+ printer_write(1, 0x0d);
+ printer_write(1, 0x0a);
+}
+printer_flush(1);
+printer_close(1);
+}
+
static void int05(u_char i) {
if( *SEG_ADR((Bit8u *), cs, ip) == 0x62 ) { /* is this BOUND ? */
if(!IS_REDIRECTED(5)) { /* avoid deadlock: eip is not advanced! */
@@ -1510,7 +1530,13 @@
leavedos(54);
}
g_printf("BOUND exception\n");
+}
+else if(REG(cs) == BIOSSEG) {
+ g_printf("INT 5: PrintScreen\n");
+ do_print_screen();
}
+else
+ g_printf("INT 5: Unknown event, passing to user\n");
default_interrupt(i);
return;
}
Re: German keytable?
Peter Eser wrote: > ...I send it again (Stas), first time it was not at the whole mailgroup > In earlier releases I worked as normal user with suidroot, but that > seems to be forbidden now. What's your problem? You've been (privately) suggested to upgrade to 1.0.2.1 because it is a fix for your problem (or, at least, it pretends to be:) Have you tried that? Or it doesn't work for you either? - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I can't execute two consecutive commands in dosemu, xdosemu seems OK
Chris Elvidge wrote: > E.g. after invoking ./dosemu > dir -> directory listing > dir -> linux shell prompt This is already a second report of this bug. With first reporter we came to a conclusion that Scroll() is called with an invalid screen address for some reasons. Could you please make a Video logging (-D9+v) to see if it is the same bug? > boot.log says: > Running unpriviledged in low feature mode Does it makes sense running suid-root? With console access? With video bios access? What kind of dosemu.conf I need to reproduce this problem (i.e. show me your dosemu.conf please:)? > Linux 2.2.19 kernel, Slack 7+, hdb2 is ReiserFS, 384Mb RAM > Any other info required? Yes, please: dosemu version, what dos/version are you using, does it crashes if you skip config.sys and autoexec.bat etc. Both reports were after the release of 1.0.2, so my guess is that you are using 1.0.2 or 1.0.2.1 dosemu. If it is true, could you reproduce the crash with 1.0.1? Also it would be very good if you do a stack trace with GDB at a crash point. Previous reporter was not able to do that because the stack was corrupted, but maybe you are more lucky with this (recompile dosemu with debug info to do it). - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCI sound cards that work in dosemu?
"John C. Alden" wrote: > What PCI sound cards work OK within dosemu? The idea is to emulate a classic SoundBlaster's DSP (and DMA) and output a sound to /dev/dsp, so that you will be able to use *any* sound card that is supported by Linux kernel, while the dos prog will think that it uses SB (you have to specify SB in the setup of your dos progs). This doesn't work currently, however, but expected to work in the near future. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DMA-Sound support in dosemu
Hello. pesarif wrote: > I got dropped from the list for a while (don't know why so I rejoined), did I > miss any other of your patches? If so, please send them to me. No, I haven't posted any more due to a complete lack of interest. But I have just uploaded a latest version to http://www.dosemu.org/~stas/snd-patches0-1.1.2.tar.gz so give it a try. There is a sound patch and 2 additional small fixes that will improve an SB usage for some DPMI programs. Note: some features mostly related to a detection of soundblaster's presence are disabled because it requires a changes to PIC, which are not yet merged to a mainstream. But this is not very noticeable, I hope. Note2: you have to select "Sound Blaster clone" or "Sound Blaster or 100% compatible" in your games, but not "Sound Blaster Pro" and of course not "Sound Blaster 16 or AWE32". > The particular patch that you sent with the email I'm replying to is really > great. Now Liero works perfectly (it didn't before) and so does Warcraft II Thanks for a good feedback:) > (without MIDI, of course). Have you tried to select "General MIDI" or "MT32" or something "MPU401" for midi? It must work perfectly if you have /dev/midi working (your sound card must support this feature) and dosemu is properly configured. And Adlib midi is a sad story: it doesn't work currently and I can't help it due to a lack of the sound card (actually I don't have a free slot for it, maybe I have to by an USB->ISA converter, but it is still *very* expensive). But I am working on porting my pc-speaker driver to a newer OSS api to make it compatible with SoftOSS, that will hopefully allow me to use midi with it... > Trouble is, a game that worked perfectly before (One Must Fall 2097 - go to Oops, I was not aware of some games that used to work before :) > "War International" in the links section of www.omf.com to download - the > game is now freeware), now has abnormally fast music. Please fix this. OK, the patch you have tested was produced within a few hours and it was mostly a set of workarounds for the problems I noticed at a first look. So it was not very good and it had some bugs inside. Later I have convinced myself that fixing the current code is a wrong way to go, so I mostly rewrote it. That said, my current patch doesn't share any bugs with previous (maybe it have enough of its own however:), so I hope this problem is fixed. > Please continue producing more excellent code (esp. sound code)! I'll try. The current TODO for the sound code is very small: - move the actual I/O from dma.c to linux_sound.c - merge additional fixes and interfaces to the mainstream - find any bugs remaining - convince myself that the code works not only with pc-speaker - try all of the proposed workarounds for doom's problem (deferred) I really hope to complete this all within a month or two, but currently things are getting very slowly for several reasons (mostly because I have to submit other things at first, but also due to my lack of a free time). - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Two questions: Number Pad and Terminal/Console
"Edward Mendelson" wrote: > To run WordPerfect for DOS, I wanted the Number Pad Plus and Minus keys > to work they work under ordinary DOS. By commenting out the $_X_keycode = > (off) Why don't just change it to $_X_keycode=(on)? > Shift-F1 gets interpreted by WPDOS as Shift-F3, Shift-F2 gets interpreted as > Shift-F4, etc. The Alt- and Ctrl- function keys seem not to work as expected > at all. This will *probably* get fixed in dosemu-1.1.3. At least it is in progress now. > Also, in the console, I can't figure out how to tell DOSEMU to use the box > drawing characters in hardware instead of the replacment characters that get > used instead. Is there a fix for this? I think that root (suid) is an only solution for that. > Finally, I've experienced the same bug reported elsewhere on this list in > which DOSEMU shuts down after giving one or two commands, Nobody made a good bugreport on this one yet... > and I hope someday > it becomes possible to use hardware graphics as an ordinary user, not > as root. It is possible under X. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with Novag's universal chess board
Hello. "Bernhard Bialas" wrote: > 1). I get only connection (by starting the driver) when I start DOSEMU > from the console as root.When I start as normal user, the driver fails > to start and I dosemu hangs.What I can do to get the communication from > xdos? (looking in the ChangeLog) I am under an mpression that it was fixed in 1.1.2. > - fritz3 receive the moves from the chessboard, but the chessboard > seems > not to receive the moves from the chessprogram: the LED's on the board > are not blinking, i.e they are not indicating the move. Under true DOS > it works. What could be the problem? It could be a bugs in the serial port emulation... > How I can solve? You can try my patch at http://www.dosemu.org/~stas/ser_irq-1.1.2.diff which fixes one problem I have found in the code. If you are lucky, that could fix your problem. Otherwise try producing a log of serial port events. > I am using Dosemu 1.02 This one is known to be a bit buggy. > Linux Kernel 2.4.0 Ouch, why don't you upgrade? OK, it have nothing to do with dosemu. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sound questions
Hello. "Peter Jay Salzman" wrote: > also, someone on the list sent me email saying that he thinks the sound > code in dosemu is completely broken, as in, dosemu can't utter a peep > right now. but he wasn't sure. But why can't you just check it out? > is this pretty much the situation for > dosemu 1.1.2? It is true only partially. Adlib emulation is broken. DSP and DMA emulation is buggy, but some programs used to work with it. And MPU emulation seems to be very usable. New DSP and DMA code are already available for testing. If you are willing, get it at http://www.dosemu.org/~stas/snd-patches1-1.1.2.tar.gz and tell me how it works for you. > Cachesize = 3802576 > Cacnum = 2 > 0- ptr: 0x4085b040, leng: 322560, lock: 255 > 1- ptr: 0x4691fb, leng: 3480016, lock: 0 > Cache length sum = 3802576 > i'm at an utter loss -- i don't know how to diagnose something i can't > understand. can someone guess as to what's happening? It seems like the program (DPMI?) encountered some errors and prints its internal variables. This info is not related to dosemu, so it can't help to find a problem. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MSDOS 6.22 running with/in Dosemu.
Hello. "John Goley" wrote: > I think I remember you saying on list that you go Dosemu > 1.0.2.1 running ^^ > Trying version 1.0.2 with freedos on my new P4 1.7 ghz machine wouldn't > work at all. This was fixed in 1.0.2.1 and in 1.1.2, so upgrade. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some thoughts about dosemu
Hello. > ERROR: general protection at 0xfadf: 66 > ERROR: SIGSEGV, protected insn...exiting! > shouldn't dosemu catch segmentation violations and perhaps print a more It does, else you would have been seeing "segmentation fault (core dumped:)". This is just an evil dos4gw trying to enter protected mode, when it is impossible. It checks DPMI presence, then VCPI presence, and then it goes on trying to set protected mode with priveledged instructions, at which point dosemu gets a SIGSEGV. You have specify 80286 cpu in dosemu.conf to prevent dos4gw from doing wierd things. > useful message? Messages could be enabled with -D switch. > or am i missing the point and dosemu IS catching a > sigsegv? Apparently. SIGSEGV is extensively used by dosemu for emulating port access and some other things. > the dosemu howto is one of the > shortest howtos out there. it deserves to be one of the largest. ;-) That's right:) - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DMA-Sound support in dosemu
Hello. pesarif wrote: > I did all your patches at that URL (sound + serial) and got: > i.e. the serial patches required "fuzzing" and the DPMI patch failed. Using > dosemu 1.0.2.1. What I am doing wrong? At least one thing: serial patches have nothing to do with sound stuff, so it is not necessary to apply at all (testing them is a good idea anyway:). And DPMI patch was diffed against dosemu-1.1.2 and it is necessary only for better SB detection, but there were some more patches for this, which I am currently submitting, so detection will be available later. I am excluding DPMI and PIC fixes from my sound patch to prevent any further confusion. Don't forget to reinstall your sources after you got rejects. > And, btw, what do the serial patches do (do they make null-modem games > work?)? Maybe, but I was solving a problem that prevented me from transferring files more that 10Kb size via modem. With that patch I am no longer limited in a transfer size. I would be glad to hear that it also fixes something else (which is rather possible). > > Note2: you have to select "Sound Blaster clone" or "Sound Blaster > > or 100% > > compatible" in your games, but not "Sound Blaster Pro" and of course > > not "Sound Blaster 16 or AWE32". > Why not? I used to be able to select "Sound Blaster Pro", but I can't > anymore in any of my games and this is reducing the sound quality in some > games. This is not a mandatory, at least I hope that all the programs that used to work with SB Pro before, will work with it also now. I just want to warn you that some programs will not work if you specify SB Pro, and will work with SB. I don't want to drop any functionality of course. My original goal was to completely outperform the old code. But your tests indicates that this goal will require some more work than I expected. > I've had mixed results with your new patches. In general, the code seems to > have gotten slower but works better. What do you mean by "code seems to have gotten slower"? Slow execution or slow sound? Or somethig else? > Here are some results of testing: You have done a very good work actually, thank you for such a detailed testing (esp. for the comparision with the old code!) > Program no sound patchesoriginal sound patches new sound >patches > (sb pro)(sb pro)(sb or sb >clone) > > Jill of the Jungleno sounddistorted perfect (even >better than win98!#) > Scream Tracker 3 locks uplocks upperfect > Wolfanstine 3Dno soundno soundperfect # Seems strange: Wolf used to work for me previously. And the detection problems are Adlib-related I think. > Swiv3Dno soundintro works perfect > Descent perfect stuttersperfect > Warcraft 2stutters horribly works perfect > Spitwad Willy no sound? perfect What is "?" :) This all looks very good. Detection problems are deferred, as I mentioned above. > Count Downinitial sound, lock up stutters,clicking >perfect,clicking Clicking is generally caused by an OSS limitations (buffer must be empty if I want to change speed, I have to reopen (!!!) the device if I want to change fragment size) or by direct DAC writes (which I can't improve - pc-speaker problems). So this is also deferred (see below). > One Must Fall 2097perfect music is too fast music skips & >stutters * Fixed: http://www.dosemu.org/~stas/snd-patch1-1.1.2.diff.gz This game uses an undocumented ability of a command 0x1C to set a transfer length. Previously none of my programs does this, so I didn't implemented this, while now I can see it was implemented in the old code. Thanks for pointing this anomaly. Actually I was thinking that my "test suit" is rather large, but apparently it was not. > Liero no soundperfect sound stutters >* I can only hope that it is the same problem as above. And if it is not, I need this game (link) or the debugging output. > Clyde's Adventure no soundpartial partial What is "partial"? > Need for Speedno soundno soundno sound > Shell Shock perfect no soundno sound * Not good. Link or debugging output needed. > Monster Bash no soundno soundno sound > Kiloblaster no soundno soundno sound > Clyde's Revenge no soundno soundbombs out > Mugen no sounddos4gw exceptiondos4gw >exception What??? Give me a link to this one, please! Oh, I beleive it is DMA probl
Re: DMA-Sound support in dosemu
Hello. pesarif wrote: > Liero and OMF2097 sound stutters a bit (the kind of sound stuttering you hear > when a system is under a heavy load). OK, as I said before, OMF's problem is fixed. LIERO's problem is now also fixed, get a new patch: http://www.dosemu.org/~stas/snd-patch5-1.1.2.diff.gz Liero was setting a very small transfer size, so sometimes it happened that it was not able to handle interrupt until another one is arrived, hence stuttering. I worked around the problem by pausing DMA between the interrupt request and acknowledge. I am not shure if it is correct, but testing indicates no breakages for other programs and also it was done this way in the old code. In this new patch I have finally done everything I planned (including many more bugfixes), so it is pretty much what I am going to submit if no serious bugs are triggered (which is possible after such a big modifications I've just made to it again). Also my patience ran out and I used indent at dma.c, which is why the diff is now much bigger. BTW, recording might work now. I just can't test it, but all necessary code is already in place. > I was given version 1.33 (freeware) by a friend. > http://www.freewaregaming.com/aa/liero.html All of your links were broken. I have found Liero with ftpsearch, but no other games. After trojansoft was closed, it is very difficult to find any good game over the internet:( > I can't find a link. > Perhaps I could send it to you OL (it's shareware after all)? You'd better upload it somewhere and give me a link, please. > http://www.elecbyte.com > It was written in DJGPP/Allegro (and most games that use this combo don't > work and cause a dos4gw exception). Hmm, I thought dos4gw was generally used with Watcom C and not with djgpp. Correct me if I am wrong. > http://www.apogee1.com/downloads.html > 2.4keen.zip - Goodbye Galaxy v1.4 shareware episode (712k) This link exists, but it is broken. > Just wondering...but how can you write and test sound code without a sound > card? I mean, you're doing a very good job without one! The reason why people always underestimate pc-speaker is simply because there was no good driver for it. I made one (based on Michael Beck and David Woodhouse work), then I connected my motherboard with an external speakers and enjoing high-quality 6-bit sound:) (actually pc-speaker is a single-bit DAC, but it is possible to emulate 6 and even 8 bit on it). BTW, quality of sound is really very good:) And why I like dosemu and my sound code is because the absence of the sound card is no longer noticeable even for DOS programs. If I had a sound card, I would probably have never started this work:) > It would be good with DOSemu could do mixing with other applications like What is necessary for this is only to write another sound driver plugin for dosemu. It is easy (you can steal one from mikmod and do a minor modifications to make it work with dosemu). The problem is to find a really good sound server, but ESD or ARTS are apparently not good at all. > xmms playing the background because DOSEmu currently seg-faults when some > other application is hogging /dev/dsp. Dosemu must never segfaults. If I am using /dev/dsp on dosemu's startup, dos programs just fails to detect SB, but no segfaults. Was it the same with the old sound code, or this segfault is mine? Is there any way I can reproduce it? If no, then make a full log please (-D9+a) and mail it to me compressed. I don't think the log will be too big if dosemu segfaults on startup. > > > This is my favourite game and now it doesn't work very well at all :( > > It will. But don't try to tell me that you are going to play on a speed > > like that:) (the game doesn't seem to use timer for synchronization). I > > assume you are using this game only to enjoy its music (which is pretty > > nice:). > The gameplay is good too! It is too fast, how can you play? Are you using any slowdown programs for this? Or maybe your computer is 386SX? :) - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VLM.EXE crashes with dosemu-1.0.2
Hello. "Sergey Suleymanov" wrote: > Grigory>Hi! I'm testing dosemu-1.0.2. VLM.EXE from Novell > Grigory> Netware client crashes when I try to use it. > I guess, you need suid root dosemu.bin to vlm.exe work. One small addition: you need suid-root *and* dosemu-1.1.2, because AFAIK suid-root doesn't do a good job for dosemu-1.0.2. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DMA-Sound support in dosemu
Hello. pesarif wrote: > > OK, as I said before, OMF's problem is fixed. LIERO's problem is now also > > fixed, get a new patch: > Thanks, I'll test out your patch. I worked around clicking in many progs by increasing the minimal OSS buffer size. It adds latency, but it is better than clicking. So better get this: http://www.dosemu.org/~stas/snd-patch6-1.1.2.diff.gz >From now I'll stop modifying it and start waiting for the results (if no serious bugs are discovered). [if Alistair is reading: this patch contains the types changes] > > > I was given version 1.33 (freeware) by a friend. > > > http://www.freewaregaming.com/aa/liero.html > > All of your links were broken. I have found Liero with ftpsearch, but no > This is strange...all the links I gave you were from "Official" sites. As of Liero, there was a site, but I found only Linux version of the game on it. Other links were broken. > > > I can't find a link. > > > Perhaps I could send it to you OL (it's shareware after all)? > > You'd better upload it somewhere and give me a link, please. > It doesn't happen anymore :) That could be due to some parts of the patch are disabled. It is possible that after one particular game, another game will fail. So you have to restart dosemu after each test. This is related to additional fixes that I am currently submitting, and, as soon as they are in, I'll enable everything in my patch so there will be no more such setuations. > > > Just wondering...but how can you write and test sound code without a > > > sound card? I mean, you're doing a very good job without one! > > And why I like dosemu and my sound code is because the absence of the > > sound card is no longer noticeable even for DOS programs. If I had a sound > > card, I would probably have never started this work:) > Is this cool feature in DOSemu? No, this is a cool feature of a pc-speaker driver - it acts like any other OSS driver so that any program (including dosemu) can play sound. Dos programs thinks that there are SB installed, but if not for dosemu, I would not be able to use pc-speaker as SoundBlaster for DOS progs, but I would be able to use it for Linux progs anyway. If I have real sound card, I could just reboot to DOS and enjoy sound, so no need to write sound support for dosemu. And now dosemu is the only way for me to hear sound from dos progs, that is why I am doing this:) > I have a computer without a sound card. I haven't ported my pc-speaker driver to 2.4 kernels yet because I am still using 2.2.20. But you can try it's predecessor by Michael Beck and David Woodhouse at ftp.infradead.org/pub/pcsp. But it is incomplete and practically not very usefull and produces absolutely horrible sound sometimes (and sometimes good). So you are unlikely to find an OSS-compatible pc-speaker driver until I switch to 2.4 kernel:) > > > xmms playing the background because DOSEmu currently seg-faults when some > > > other application is hogging /dev/dsp. > > Dosemu must never segfaults. If I am using /dev/dsp on dosemu's startup, > > dos programs just fails to detect SB, but no segfaults. > I'll get back to you after testing the patch. OK, but problem with segfaults is also an important one. > > It is too fast, how can you play? Are you using any slowdown programs for > > this? Or maybe your computer is 386SX? :) > If you press ESC during gameplay, you can control the speed. > I have an i686. OK, pretty nice game (took me ~20min to complete the whole game at a "Veteran" difficulty level:), but actually just another clone of Mortal Kombat, I would say (but with very nice music:) - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: DMA-Sound support in dosemu
Hello. "Vlad Romascanu (LMC)" wrote: >> Liero was setting a very small transfer size, so sometimes it >> happened that >> it was not able to handle interrupt until another one is >> arrived, hence >> stuttering. I worked around the problem by pausing DMA between the >> interrupt request and acknowledge. > Pausing until receiving the ACK is correct for SB16, but is not correct for > SBPro-s and lower Just to be more specific: I am only pausing DRQs, which doesn't always mean pausing DMA, but for single mode it does. Also we are transferring not a 1byte/request, but much more (up to 512bytes/request) to reduce the overhead. This last detail seems to make pausing unavoidable. About SB16: it is not emulated anyway, but why pausing is correct? I assume that pausing DMA will result in stuttering on the real hardware. When we have an intermediate OSS buffer, it is OK, but is the real DSP have some intermediate buffering to allow DMA pauses? And what if the program doesn't care about ACKing at all? Is this possible? I assume that DSP will still assert DRQ if it is in auto-init mode, and the output will not be stopped. That is why when a dos program crashes, real sound card still produces a noice forcing to reboot the compter, I suppose. > at least one app -- I can't recall which right now, > though -- will fail if configured for SBPro but the emulator behaves as > a SB16 Maybe that app just uses auto-init and doesn't ACKing? For this I have a work-around-the-workaround: if OSS buffer is empty, but the INT was not ACKed yet, I am forceing DRQ. Dunno if this works, however, but the post- crashing noice is in place:) >> BTW, quality of sound is really very good:) > ..except it's mono... :) Yes, but it is still better (much better) than nothing:) And, as a bonus, it allows me to control a modem's transfer speed (sound quality depends on the int frequency from serial ports because I use irqtune to give a higher priority to serial ports). So, when the sound quality is good, I know that modem's connection is broken and I have to reconnect:) Anyway I am going to by an USB->ISA converter as soon as there will be a linux drivers available. They promised it within a year. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: DMA-Sound support in dosemu
Hello. "Vlad Romascanu (LMC)" wrote: >> Just to be more specific: I am only pausing DRQs, which doesn't always >> mean pausing DMA, but for single mode it does. > OK. On SB-16 DMA *transfers* will pause What exactly it does to pause DMA? OK, atleast my code must be correct for SBPro (which is what is emulated) regarding the workaround that finally forces DRQ. >> but is the real DSP have some >> intermediate buffering to allow DMA pauses? > Yes. Actually in the "Generic DAC/ADC DMA commands", in the "Command > byte", you will see there is a bit field for "FIFO" -- setting it enables > internal buffering Yes, I see it. So, the default state for it is enabled, right? It is good because I can't avoid OSS buffering anyway. > Good point about sound looping when program crashes -- I observed this > behaviour on my old SB-Pro (consistent); has anyone observed this on a > real SB16? Yes. > ISR may dutifully ACK every IRQ (thus the sound would loop on forever), This is possible because even warm reboot with QEMM's quick boot used to stop this, but unlikely by resetting DSP (it could reset DMA though). BTW, I observed this after crashes from dos4gw so it is unlikely that there was an old handler alive. But I don't have SB handy and it was long ago so I can confuse something... > Is there such a thing as a USB<->ISA > "bridge"? It sounds like such a Frankenstein -- imagine all the > hacking going behind the scenes needed to trap I/O and translate > IRQ's (from actual > "made-for-ISA" drivers) into something that can be pushed around on a > USB interface. That is why it costs way too much:( Initially it required the rewriting of the drivers. But recently they made something that allows to work with ISA drivers. For more info visit www.arstech.com > BTW, about the Scream Tracker 3 problem that needs DMA to be halted What do you mean? I am not halting it, just delaying it's start. > during "disabled speaker" periods -- is that documented somewhere, or > is it also an empirical observation? :) It was a logical conclusion:) ST3 sets a DMA transfer from the int handler. If you request the int immediately, this handler will be called again and will set the same transfer again - infinite loop. It just wants to execute some commands after a return from handler - this is all what it demands. I assume that even when speaker is disabled, DMA transfer still goes and takes some time. I am not going to emulate any timings, instead I just detect if the transfer was set from inthandler, in which case I delay it for some CPU cycles. That works just fine. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DosEmu error
Hello. "Julius Chrobak" wrote: > Caldera Dr-Dos. If I want to run it now it writes this: > Phar Lap err 35: The 386 chip is currently executing in virtual 8086 > mode under the control of another program. You must turn off this other > program in order to use 386|DOS-Extender to run in protected mode This generally means that you haven't enabled DPMI. Check $_dpmi option in your /etc/dosemu.conf - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mouse in xdosemu
Hello. "John Goley" wrote: > mouse doesn't work like it is suppose to. It will not work at all if I just > "left" mouse click on the menus. Nothing happens. But if I hold down > the right mouse button and then click "hard" with the left button then it > will work sometimes. What is wrong? Is there a setting change in a config > file somewhere that could fix this problem? Try $_hogthreshold=(0) When this is enabled, dosemu executes sleep() when the program is polling the mouse while mouse is inactive. This can lead to a missing mouse events. When you hold the right button, dosemu thinks that mouse is active and ceases executing sleep(), hence not losing the click. > Or can you disable the mouse driver > and load a driver that will work? This is unlikely even under console. Not possible under X. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: DMA-Sound support in dosemu
Hi. "Vlad Romascanu (LMC)" wrote: > However, even if the transfer was "block" it will still pause on > terminal-count if DREQ is deasserted, no? >From manual: "The difference between Block and Demand is that once a Block transfer is started, it runs until the transfer count reaches zero. DRQ only needs to be asserted until -DACK is asserted." So I don't think DSP have something to stop it. But also I am not sure whether it is possible to use block mode for sound transfers at all: how then DSP can control a transfer speed (sampling rate)? So, if it is not possible, then pausing DRQ == pausing DMA. > Seriously, though -- trackers will want 16-bit stereo sound. Is this why FastTracker2 plays twice as slow with my code? How good does it work with yours? > 16-bit DMA is very easy to implement. I don't know exactly how easy it is to implement, but I suspect this will require an implementation of DMAC cascading/cascade mode, which what I don't currently know how it works (probably in need of a good specs). >> No: starting DMA transfers from the inthandler, relying at >> the same time on >> the execution outside of inthadler seems to be stupidity in any case. >Why? I was merely suggesting using "Pause" as a >non-reentrancy/guarding >technique (other than cli) -- called from *within* the int handler, of >course. Because int is mostly an async event. Yes, you can pause DMA and safely leave the handler, but how can you know *where* will you be after iret? Where is to put an unpause? You will have to do some synchronisation probably with global volatile variables and waitpoints in the main code. But then it is better to start transfer from the main code and do only ACKing from the handler. This is all about that 5-byte xfers that ST3 does for SB detecting. If you are going to do real transfers, than you may not worry about recurseing into inthandler and it is OK. But doing *short* test transfers from within inthandler seems unreliable to me. >> ST3 sets a transfer with disabled speaker. >> This produces an interrupt. > One moment -- "Disable Speaker" (0xD3) is not supposed to generate > IRQs, no? I didn't say that. "ST3 *sets a transfer* with disabled speaker" is what I said. Interrupt is produced by the transfer (when it is over), not by the disabling speaker, of course. > It theoretically only acts as a "mute" (and, according to my docs, it Maybe. But I have a feeling that when you do a transfer with a speaker being disabled, DSP keeps DRQ asserted during the whole transfer, ignoring the sampling rate. So it is possible that the transfer with the disabled speaker is going much faster than with enabled. But this is nothing more than my internal feeling:) There is nothing in my docs about it. >> What I do: >> If (speaker_is_disabled && transfer_started_from_inthandler) >> wait_for_a_several_cpu_cycles; >> Start_the_transfer; > Tzk, tzk, tzk, you cheated -- the SB is not supposed to know that the > CPU is in an interrupt handler. ;) Long before I started doing sound stuff, I wanted to implement a safeguard for PIC that will prevent the inthandler for an int with the equal or lower prio to be executed without giving some CPU cycles to a main code. This would solve the aforementioned as well as many other problems. But my PIC patches are still kept away from dosemu:) That is why I am introducing such a dirty hacks:( > Interesting, though -- I assume ST3 sets up such a small DMA block size > that the IRQ occurs while the ISR is pre-empted. ... only at a detection phase, of course. > This is a pain, though, because other games (e.g. Rex Nebular) will > actually > fail SB detection if the IRQ does not come soon (they set the DMA block > size to a few bytes, e.g. 4 bytes, and time-out/fail detection if an IRQ is > not emulated within 5-10ms). This is exactly what I have with IPlay (Inertia Player), but fortunately it is clever enough to not set such a short transfers from within an inthandler so no problems with it. I wonder if it is possible to figure out under NT is the process currently inside an inthandler or not? >> I can feel like ST3 doesn't work under your emulator, right?:) > And differences between DMA "DMA block > size" and DSP "DMA block size" are not an issue for me, all cases > (less, equal, greater) work fine with other apps. :) This means that you are doing a smoother transfers, probably you even have another thread for DMA? Dosemu is single-threaded (threading support was removed not so long ago for the reasons unknown to me) so I have to do a very large xfers (I can't be sure that I will have a control within the next few seconds or not). This produces a nasty bursts and some programs stuttering. That is why I have some heuristic code about a transfer sizes, but unfortunately this doesn't work very well. I don't know what to do with it:( > I suspected DPMI before I saw your message a But ST3 doesn't use DPMI! Dosemu have a global variable in_dpmi that allows to figure out easi
Re: DMA-Sound support in dosemu
Hello. pesarif wrote: > I've just tested out your patch. Thanks:) > In general, it's perfect :) except that most programs still can't detect it This is improved in the devel version of dosemu, but don't expect perfection anyway. > and there's no music :( Upgrade your soundcard with a midi daughterboard:) BTW, how about SoftOSS? > (btw, when you write the music code (please!), What I know for sure is that I am not going to write an OPL code. I am thinking about stealing it somewhere, or make it possible to use timidity for an MPU401 midi on top of the /dev/dsp. But even this is not going to happen soon (if you are not volunteering for help, of course:) > Here are some of the more interesting results of testing (i.e. the results that you >probably want to know about): > Nice, the top three are my favourite DOS games :) Nice:) > Warcraft 2 is misdetecting the sound emulator as "Ensoniq Soundscape" (which >incidently is my real sound card). ... and still works correctly? > If I start Count Down and wait for the initial scream (yes, this is an interesting >game) to finish before pressing a key, > the intro music and the sound is fine. But if I interrupt the initial scream (i.e. >don't wait for it to finish before pressing a key), lots of sound > (almost all the sound in the game) disappears and if there is any sound, it lasts >for a few seconds and then stops; with the into music, it skips > entire segments and then stops :( This game is commercial and is by Access >Software, which has been bought out by MS so I can't give it to you :( > This behaviour occurs on the 2.4.7 kernel. > If I use 2.4.3, Count Down _always_ stuffs up no matter what I do. Wow, it looks like a problems with OSS drivers! I can't keep in secret anymore the fact that I have done a lot of hacking on my pc-speaker driver implementing such an unusual things like a non-blocking close and sorting out a races before I managed to get it working correctly with dosemu (while it used to work with all other apps long before that). dosemu (my sound code) does a very weird things with a linux sound driver, stressing it so high that if there are any hidden bugs or semi-implemented features, they are going to be triggered and cause a bad results. Anyway, I would like to see a log of the sound events (-D9+S) to be sure that it is not my fault:) > Really Bad > > > Clyde's Revenge no soundbombs out locks up (dosemu >complains about vfree'ing something) But vfree() is a kernel's internal function AFAIK and it have nothing to do with dosemu! Apparently your driver is falling apart and can't satisfy the requirements of my sound code:( Only my pc-speaker can:))) But show me the exact error message, please. BTW, it would be *extremely* interesting if you try ALSA with OSS emulation enabled to see how good is... ALSA:) > Commander Keen 4 no soundlocks upno sound I am still wondering what is going on with this keen. Could you please upload it somewhere? Or, atleast, do a sound log? > The latency is now very obvious in Liero, with an annoying 1/2 second But is the 1/2 second delay is really so annoying??? > The clicking still happens in the game "Count Down". Make a log. Maybe I will be able to diagnose a problem without having a game itself. > btw, I've found out when and why OMF2097 stutters. > (I'm using a Pentium II to give you an idea of how fast/slow my computer is) I have the same with Athlon 700:( > If I select "Sound Blaster (mono)" and then choose "Very High Quality" > or "Ultra High Quality", it misses or repeats or a few beats. > If I select "Sound Blaster (mono)" and then choose <= "High Quality", then it's fine. > In an unpatched DOSemu 1.0.2.1, If select "Sound Blaster Pro" and then > choose "Ultra High Quality", there's not a problem. And what about the latency with an unpatched dosemu? BTW, I have the described above problem also with unpatched dosemu. > So, I think your code is a little slow :( This really seems like a performance problem. I am trying to do a smoother transfers than the old code does, hence more overhead. But, as I already said, I have this problem also with unpatched dosemu, so... Maybe it is also due to a different kernel drivers: my driver is extremely cpu-hungry. BTW, when I decreased a sampling rate twice, OMF stops stuttering and produced a perfect sound (not counting that it was twice as slow:) so it is a performance problems for sure. Anyway, setting OMF to High Quality solves the problem, so I am going to leave it as it is. > Segfaults have always been happening when a program tries to start > with SB (even with unpatched dosemu 1.0.2.1). But you missed the fact that it happens only with OMF and also it happens if you disable sound in your dosemu.conf. So it is definitely not a bug in my code and most likely a bug in OMF itself. It is trying to use SB even if it is not present, but specified in OMF's setup. Not a good b
RE: DMA-Sound support in dosemu
Hello. "Vlad Romascanu (LMC)" wrote: > you (the SB) can always deassert DRQ and the DMAC > will actually check DRQ when reaching terminal-count, no? Yes (even in auto-init I think, my docs are incomplete though), but how to stop block DMA xfer when TC is not yet? I mean I can issue a "Pause" command to DSP at any moment, and what DSP can do? Buffer the end of the block? > So even if you are in auto-init, the SB would still be able to "insert" > transfer pauses (until its internal buffer is almost empty) during > auto-init DMA. > Of course, all this assuming that pre-SB16 > cards did have buffering (which is not so obvious). I think (again, only my internal feeling:) that DSP simply asserts DRQ with frequency equal to its sampling rate, so buffering is not necessary (8-bit DMA transfers 1byte/request). That is why I assume that block mode transfers are not possible here - DRQ freq doesn't matter in this case and buffering the entire block is not possible as you already mentioned. > I have a good data-sheet from Intel from the DMAC -- I think I grabbed > it on ALSA (or was it Bochs?) I can also e-mail it to you if you want. This would be nice:) > No, you pause DMA, do all the time-consuming double-buffer memory xfer, > then resume DMA and IRET. But here you are probably talking about auto-init (for DSP), while ST3 uses single-cycle. > Once the memory xfer is done (i.e. DMA has been > resumed), the ISR doesn't really care about re-entrance anymore unless If we are talking about single-cycle (and atleast I am talking about it:) then DMA will not start anyway until you have done everything so what is the use of pausing it? > or it's doing 10-byte long transfers between IRQs :) ... which is exactly what it does:) > I'be been hacking away at NTVDM.EXE for quite a while. Hmm... Do you have a sources for it or whatever?? > Yes, I have another thread for DMA. > But I guess you have the advantage of being notified by the emulated > DMAC whenever data is to be transferred... or are you not? No. Emulated DMAC doesn't control the transfer at all. Transfer function is called ocasionally (on timer tick or on fault) and trying to fill up an OSS buffer. So it is Linux driver who controls the transfer. If there is some free space in linux buffer, I am transferring, if no - I am waiting (actually it is simply a non-blocking write()). > It's been one year > since I peeked at DosEmu, I guess many things have changed in that > interval too. :) The short answer is... No, not at all:( Almost nothing (except for the current devcycle). > I grab data every T milliseconds, where T self-adjusts between > user-define bounds (default 5 and 15ms). I would expect this T to actually depend of a sampling rate:) And how many data you are transferring at once? OSS manual recommends to transfer a one full fragment per one write() call, so I am very limited here... I am ignoring this recommendation, of course, but this makes some drivers to work unreliably:( I wonder if I can steal some OPL code from your emulator? Does it produce a digital sound, or it uses a midi capabilities for output? - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: nvidia cards?
Hello. "bascule" wrote: > hi, i've joined this list to see if i can get some help on getting dosemu to > work - or rather to play 'monkey isalnd 2', i run mandrake 8.1 plus > cooker enhancements i.e. bits if it are bleedin edge:-) dosemu version is > 'dosemu-1.0.1-8mdk', Have you tried Mandrake's bugzilla? The better way to get some help here is to use a self-compilled (with debug info) latest version of dosemu. > 'xdos' fom a console > leaves the following output: > ERROR: cpu exception in dosemu code outside of VM86()! > Page fault: write instruction to linear address: 0x1cadaf74 > CPU was in user mode > Exception was caused by non-available page xdos must not be started from a console, but this page fault is interesting anyway. Could you provide a stack trace with gdb at a crash point? > given that i have a sblive with no dos drivers i was rather hoping that > dosemu might be a way to get sound in the game! This is possible, but you will most likely have to apply some patches for that. > $_dpmi = (4096) # in Kbyte Setting it to at least 16Mb is highly recommended for most games. > $_sound = (off) # sound support on/off And how are you going to get any sound with the settings like this one?:) - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: nvidia cards?
Hello. "bascule" wrote: >> is to use a self-compilled (with debug info) latest version of dosemu. > i tried compiling the latest mandrake src.rp, it didn't run, i'll > recompile and post the error I mean sources from ftp.dosemu.org/pub/dosemu/Development And, if you need sound, then patches from ftp.dosemu.org/pub/dosemu/testing and some additional patches like www.dosemu.org/~stas/sound-patch8-1.1.2.8.tar.gz >> This is possible, but you will most likely have to apply some patches >> for that. > ah, new territory for me! Get used to it: this is a fastest way of updating software. Otherwise you can wait several month (or years?) until MDK releases a new version. > > > $_sound = (off) # sound support on/off > > And how are you going to get any sound with the settings like this > > one?:) > i turned it off in an attempt to rule out sound as a point of failure! You'd better turn off sound in your game's setup, otherwise you'll get additional problems. > ok, i assume by debug you mean running xdos (or dos) -o somefile? This is a way to create a log file, but to find out where your dosemu gets a page fault, you have to start your xdos from within gdb, and when dosemu crashed, you must do 'bt' to make a stack backtrace. > i couldn't find anything about a debug compile option When you do ./default-configure in your source tree, you have to specify a parameter '--enable-dodebug' (i.e. ./default-configure --enable-dodebug ) Otherwise a stacktrace is useless. > is there any other info i can give? Have you tried starting dos (not xdos) from a console (not KDE konsole) with root priveledges (suid-root)? - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: random reboots
Hello.
Jacob Perkins wrote:
> Whenever I run dosemu-freedos 1.0.2.1 it will eventually
> cause my
> computer to reboot. I'm running Gentoo Linux with kernel
> 2.4.17 with preempt patch.
Due to an obvious bug in the latest 2.4 kernels, dosemu can
easily cause the system to panic. Generally it only oopses,
but maybe with preempt patch it reboots instead.
Try the attached fix.
No guarantee that it will fix your particular problem (I've
seen only oopses, lots of them, but no reboots) but it might
fix the segfaults (but not page faults) on startup and some
other crap people lately observed with dosemu.
--- linux/arch/i386/kernel/traps.c Sun Sep 30 23:26:08 2001
+++ linux/arch/i386/kernel/traps.c Sat Feb 9 02:48:31 2002
@@ -269,8 +269,12 @@
static void inline do_trap(int trapnr, int signr, char *str, int vm86,
struct pt_regs * regs, long error_code, siginfo_t *info)
{
- if (vm86 && regs->eflags & VM_MASK)
- goto vm86_trap;
+ if (regs->eflags & VM_MASK) {
+ if (vm86)
+ goto vm86_trap;
+ else
+ goto trap_signal;
+ }
if (!(regs->xcs & 3))
goto kernel_trap;
Re: Bug Report: (CRASH) Exception Caused By Non-Available Page (During Runtime)
Hello. Megas of Vecanti wrote: > I doubt that it's 2.4-specific, then-Since I've seen this page fault > happen even back when I was running 0.98 on 2.2 kernels! You are right, it is not:( > I'll probably try Mr. Sergeev's kernel patch, though. No need: I explicitly stated in brackets that it doesn't fix page faults (neither at startup nor at runtime). > But I don't > like patching my kernel for ANY reason, so it'll be a tough decision to > make just for DOSEMU... This patch touches only vm86 part of the kernel, which is used *only* by dosemu. So even if the patch is incorrect, it will break only dosemu. But it will not fix your problem anyway, so... BTW, your program (MegaZeux) uses DPMI, right? In this case you are out of luck, I suppose, as there is currently no active DPMI maintainer AFAIK. And if it doesn't use DPMI, it is worth to have a look at. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug Report: (CRASH) Exception Caused By Non-Available Page (During Runtime)
Hello. "Stas Sergeev" wrote: > BTW, your program (MegaZeux) uses DPMI, right? In this case > you are out of luck, I suppose, as there is currently no > active DPMI maintainer AFAIK. > And if it doesn't use DPMI, it is worth to have a look at. Hmm, it doesn't seem to use DPMI and the crash is really 100% reproduceable - very good point to get it fixed:) I'll have a closer look at it within a few days (if noone will do it sooner:) to see what the problem is and if it is possible to do somethihg with it... - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re:
Hello. Boris wrote: > That sound patch from stas works great. Thanks :) > -Their seems to be abit of a bug in it though. I would be happy if there is only one bug, but in fact there are many more right now (development stage). I was updating the patch rather frequently, but now I am slightly out of time, so it wasn't updated last week. I am going to update it at a weekend to fix some of the reported issues. > I have the shareware > version of Fatty Bears Birthday Surprise with plays audio and when the > character speaks, I hear the voice when they speak the first sentence > but > then it goes to the next sentence, I hear nothing. There are 2 ways of getting such bugs fixed: - You can produce and mail me a log (-D9+S), and this can probably help me to diagnose and fix the problem. - You can upload the game itself on an FTP and mail me a link so that I can have a look at it. There are also some known problems with the SB emu, that can't be fixed in a short term, so no guarantee that your particular game will work. Big note: There are many bugs in the OSS sound drivers that can prevent SB emu from working correctly. I am going to make it more OSS-friendly, but only a software mixing layer can really fix all the issues with the OSS/Free. > -The third is that when tring to run doom1,doom2, It loads the data, > but > *always* halts when setting up the "I_StartupTimer(). If you try it on an older (eg. 1.0.2) dosemu, it will lock up even earlier, so some work was done on it, but the problem is not fully resolved yet. > This is when > sound[Sound FX] is turned on. When I turn sound off, It works no > problem. > Any ideas how to fix that? That would be a plus. This was discussed a lot in this list. The problem was explained by Vlad Romascanu and there were some workarounds proposed here as well as privately in my mailbox. I liked the idea of switching to CPUemu when interrupts are disabled (propossed by Steffen), but switching to/from CPUemu under DPMI doesn't seem to be possible right now... Another proposed workaround was to do a run-time code patching to eliminate the evil cli instructions, but I am suspicious about this one... Anyway, for now you can use CPUemu to play Doom2. This is slow and unreliable, but currently it seems to be the only way to get this game running with sound. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re:
Hello. Boris wrote: > -The third is that when tring to run doom1,doom2, It loads the data, > but > *always* halts when setting up the "I_StartupTimer(). Almost forgot: several month ago I have already implemented one of the possible workarounds (not the best one though) and it works. Revisit my page at dosemu.org (and also get a new sound patch there:) - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re:
Hello. > file-->save-->1.txt, It says "Edit was unable to find the > path 'C:\1.txt". > I can't seem to create new files. I can open up an > existing file and save > it. It just has problems saving new files. Any ideas on > how to fix that? I wonder if a log (something like -D9+dRW) can shed some light on the problem? - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: emu serial port help
Hello. gobo wrote: > trying to access com1 (3f0 - 3ff)under dosemu. i've > given dosemu access to that address range. dosemu emulates serial ports, so no need to use a direct access. Have you tried a $_comX settings in dosemu.conf? > no matter > what i try, i can't get to the ports. You can't use a direct access to serial ports because linux kernel already controls it. > if i run as a > user, it complains about not being able to build the > lock file. if i run as suid root, dosemu says not to > do this. Both problems were already fixed, upgrade your dosemu from 1.0.2 to something more modern (unfortunately the problem with lock files was fixed only in a devel branch, so you will have to upgrade to a devel version I suppose). > is there a magic combination that will work? Yes and it is not magic at all. By trying a direct access you made a problem for yourself that wasn't existed initially:) - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sound+dpmi patch
Hello. Boris wrote: > So is something wrong with the DPMI part of dosemu that > haults Doom2? This patch simply measures a time period of a disabled interrupts and re-enables them in case of a timeout (timeout is set in a $_features, my recommendation is 200 usecs). Doom2 needs this because it uses a popf instr to enable the ints, which doesn't touch the IF flag because IOPL < CPL and doesn't generate an exception due to a bug/limitation/feature of an Intel's CPUs. But force re-enabling the interrupts can hurt other programs esp. given the current state of the dosemu's PIC code (badly broken), that is one problem. The other problem is that 200us timeout is OK for Doom2 (but as you told, it stutters) but probably not OK for some other progs and you will have to calibrate it in your dosemu.conf. > If so, why is it a dangerous hack and why not put it into > the main source [and not have to use the features option to set it?]. Right, of course it doesn't hurt unless explicitly enabled. The reason why it is still not in the mainstream (atleast why I haven't submitted it) is because I have to try some other ways of solving this problem. For example we can do a blacklist of a cli unstructions that have triggered an extended timeout (1 sec for ex) and ignore (rather than patching out) that cli's for the subsequent passes. That will (atleast theoretically) allow to get rid of the both stated above problems. > Also, It says that the sound patch emulates a SB Pro, ... which still have some problems... Classic SB, however, is emulated nearly perfectly now, speaking about its DSP. > Does it do MIDI > yet? OKey, the confusion here is that my patch deals only with the following subsystems: SB DSP, SB Mixer and DMA. Other parts (such as MPU401 and OPL) are yet out of the scope. So, for MIDI you can use an MPU401 which used to work nearly perfectly for years in dosemu but you'll need a built-in MIDI support in your sound card and /dev/midi configured. OPL is not supported yet, but I have some plans on supporting it in the future (with the MAME OPL2 emulator, I think). > a midi hack would be excellent too. :) The midi "hack" is not trivial to hack it in:) Even with the ready-for-use MAME OPL emu, we still need a software mixing layer to get it working together with a digital sound. > Is the IPX part of dosemu broken? It would be nice to get > IPX > applications working and have network games. :) I will send the > information to stas about the dosemu information when running these > programs. No need: I have never dealt with dosemu's IPX support. So try dosemu-bugs mailing list CC'ing here at the same time, and maybe someone will pick it up. There are many developers that are silent in this list, but reading it. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cdrom question
Hello. Peter Jay Salzman wrote: >C:\>mscdex /D:MSCD0001 /L:E >Not enough drive letters available > can someone help me resolve this error message? Have you tried something like LASTDRIVE=Z adding in your config.sys? > i never really used > DOS, so i don't grok things very well. For most Linux users DOS is mostly a legacy and dosemu helps them to continue using what they could have lost otherwise (for me it is a special backup hardware that doesn't have a linux drivers). But I am a bit curious about a reason why the one can *start* using DOS under dosemu? The only reason I can imagine is a good old dos games:) - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cdrom question
Hello. Peter Jay Salzman wrote: > unfortunately, the system freezes up for something like 30 seconds when > the cdrom is first accessed (or when i do a DIR in a cd directory that > hasn't been cached yet). Are you using a redirector to access your cd, or dosemu's cdrom.sys? With cdrom.sys this takes no more than about a 5 seconds for me, but mounting my cd-rom takes just about as many time, so I don't think it is a dosemu-related probelm. 30 sec is really seems too long, but how long does it take to mount your cd? > i'm going to try installing the sound > patches next (unless someone tells me that the next version of dosemu > along with the patches will be released soon). Go for trying it, as they will not:) Maybe they will be included during the next devcycle, but not in the current one, I think. > i can't even play tomb raider on > it because it doesn't support her ESS sound chipset... i was hoping to > play this game under dosemu. I don't know about a tomb raider, but I have recently made Duke3d and some other ID games working, so I can hope that tomb raider will work as well. Just give it a try with my latest patches. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cannot get raw serial port access ...
Hello. Bryan J. Smith wrote: > Tried this under both DOSEmu 1.0.2 and 1.1.1. Try 1.1.2 (or, better, even 1.1.2.9) > 1. Run as su'ed root (so I can access /dev/ttyS0) > 2a. Set $_com1 = "/dev/ttyS0" > 2b. Set $_ports = "device /dev/ttyS0 range 0x3F8,0x3FF" > If I don't do #1, I get an error on DOSEmu start when I try to control > /dev/ttyS0. Was fixed in 1.1.2. > If I don't do #2a or #2b, I get an error in the program > that the COM port is inaccessable. 2a is the right way, 2b will not work. > The program works perfectly under both _except_ for > COM access. I'll just get a "blank" terminal screen in the program > under DOSEmu -- no communication, although the port is accessable > (otherwise, I get an error). Try 1.1.2.9 - it have some fixes for serial ports interrupt handling. > I guess the COM ports registers/status > bits are still being emulated somehow? Right, they are (in case of 2a). - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Slow loading
Hello. Johan Gill wrote: > I have Dosemu 1.1.3 installed, under which I run Msdos 6. > I am trying to run Star Trek 25th Anniversary, CD version on this > setup, > with all sound disabled. It works, but it loads REALLY slowly, about 10 > minutes to get it going. How comes? $_hogthreshold now behaves differently, recalibrate (increase the value). - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Printing Problem
Hello. Suporte wrote: > Problem: > The Dosemu starts to send the report for the spool of Linux(lpt1) before > the application finishes to generate the report, with this, the report > is printed in parts without control. > How to leave printer_timeout infinite? ==> This resolve? You mentioned that your program generates a report for a 5 minutes, which seems to be unreasonably long. Is it so also in a pure dos, or such a slowdown is dosemu-specific? If it is dosemu-specific, then you should try to increase a $_hogthreshold value to make a faster processing, so you will probably not trigger a timeout then. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dosemu Crash
Hello. Dosemu List wrote: > I use dosemu-1.0.2.1 from Debian...really nice product ! You may want to upgrade to dosemu-1.1.3 > Mar 19 15:14:47 costes kernel: invalid operand: > Mar 19 15:14:47 costes kernel: CPU:0 > Mar 19 15:14:47 costes kernel: EIP: > Mar 19 15:14:47 costes kernel: Code: Bad EIP value This seems like a problem with the latest 2.4 kernels. Get a kernel patches from www.dosemu.org/~stas and see if it fixes the Oops. Of course it will not solve your IPX problems, but atleast your kernel must not "execute an invalid opcode" anymore with them applied. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dosemu Crash
Hello. Dosemu List wrote: >> This seems like a problem with the latest >> 2.4 kernels. > I have the dosemu 1.1.3 with the patch for 2.4 kernel but now the > system is block > when I have a pb and I am oblige to do a kill . Do you mean dosemu gets blocked, not the whole system I guess, else how can you do 'kill'? How are you starting dosemu? In console, in xterm or under X like xdos? Have you tried Ctrl-Alt-PgDn instead of kill? Have the Oops disappeared? - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 1.1.3 doesn't compile
Hello.
Witold Filipczyk wrote:
> And now a few programs, that don't work as they should:
> R80 - Spectrum emulator - any keypress cause exit with General
> Protection Fault.
Yes, DPMI gets broken in 1.1.3 somehow:(
It must (and hopefully will) be fixed,
but I've no idea when:)
Try the attached patch, please
(don't forget `make clean` after
applying it).
> Pair Tetris - game from PTS-DOS - no sound, pieces don't moves down.
Do you mean it used to work with sound
under dosemu before 1.1.3?
--- src/base/dev/pic/pic.c Tue Mar 19 19:45:50 2002
+++ src/base/dev/pic/pic.c Tue Mar 19 19:54:14 2002
@@ -806,7 +806,7 @@
#endif
if(pic_ilevel < 16) pic_push(pic_ilevel);
if (in_dpmi) {
- run_pm_int(intr);
+ run_pm_int(intr, 1);
} else {
#ifndef USE_NEW_INT
pic_cli();
--- src/dosext/dpmi/dpmi.h Tue Mar 19 19:45:49 2002
+++ src/dosext/dpmi/dpmi.h Tue Mar 19 19:56:56 2002
@@ -37,6 +37,7 @@
EXTERN int in_win31 INIT(0); /* Set to 1 when running Windows 3.1 */
EXTERN int dpmi_eflags INIT(0);/* used for virtual interruptflag and pending
interrupts */
EXTERN int in_dpmi_dos_int INIT(0);
+EXTERN int in_dpmi_hw_int INIT(0);
EXTERN int in_dpmi_timer_int INIT(0);
EXTERN int dpmi_mhp_TF INIT(0);
EXTERN unsigned char dpmi_mhp_intxxtab[256] INIT({0});
@@ -47,7 +48,7 @@
void dpmi_fault(struct sigcontext_struct *);
#endif
void dpmi_realmode_hlt(unsigned char *);
-void run_pm_int(int);
+void run_pm_int(int, int);
void run_pm_mouse();
void fake_pm_int(void);
--- src/dosext/dpmi/dpmi.c Tue Mar 19 19:45:51 2002
+++ src/dosext/dpmi/dpmi.c Tue Mar 19 21:01:00 2002
@@ -2016,8 +2016,9 @@
* DANG_END_FUNCTION
*/
-void run_pm_int(int i)
+void run_pm_int(int i, int async)
{
+ unsigned short CLIENT_PMSTACK_SEL;
us *ssp;
#ifndef USE_NEW_INT
@@ -2044,9 +2045,19 @@
return;
}
- if (dpmi_stack_frame[current_client].ss == PMSTACK_SEL)
+ if (async && !in_dpmi_hw_int) {
+D_printf("DPMI: Switching to locked stack\n");
+CLIENT_PMSTACK_SEL = PMSTACK_SEL;
+ }
+ else {
+D_printf("DPMI: Not switching to locked stack, in_dpmi_hw_int=%d\n",
+ in_dpmi_hw_int);
+CLIENT_PMSTACK_SEL = dpmi_stack_frame[current_client].ss;
+ }
+
+ if (dpmi_stack_frame[current_client].ss == PMSTACK_SEL || in_dpmi_hw_int)
PMSTACK_ESP = client_esp(0);
- ssp = (us *) (GetSegmentBaseAddress(PMSTACK_SEL) +
+ ssp = (us *) (GetSegmentBaseAddress(CLIENT_PMSTACK_SEL) +
(DPMIclient_is_32 ? PMSTACK_ESP : (PMSTACK_ESP&0x)));
/* ---
| 000FC925 | <- ssp here, executes pm int
@@ -2087,10 +2098,12 @@
}
dpmi_stack_frame[current_client].cs = Interrupt_Table[i].selector;
dpmi_stack_frame[current_client].eip = Interrupt_Table[i].offset;
- dpmi_stack_frame[current_client].ss = PMSTACK_SEL;
+ dpmi_stack_frame[current_client].ss = CLIENT_PMSTACK_SEL;
dpmi_stack_frame[current_client].esp = PMSTACK_ESP;
if (i == 0x08 || in_dpmi_timer_int) in_dpmi_timer_int++;
in_dpmi_dos_int = 0;
+ if (async || in_dpmi_hw_int)
+in_dpmi_hw_int++;
#ifdef USE_NEW_INT
dpmi_cli();
#endif /* USE_NEW_INT */
@@ -2200,7 +2213,7 @@
case 0x1c:/* ROM BIOS timer tick interrupt */
case 0x23:/* DOS Ctrl+C interrupt */
case 0x24:/* DOS critical error interrupt */
- run_pm_int(VM86_ARG(retval));
+ run_pm_int(VM86_ARG(retval), 0);
break;
default:
#ifdef USE_MHPDBG
@@ -2506,6 +2519,7 @@
in_dpmi++;
in_win31 = 0;
in_dpmi_dos_int = 0;
+ in_dpmi_hw_int = 0;
pm_block_root[current_client] = 0;
memset((void *)(&realModeCallBack[current_client][0]), 0,
sizeof(RealModeCallBack)*0x10);
@@ -2983,6 +2997,13 @@
} else if (_eip==DPMI_OFF+1+HLT_OFF(DPMI_return_from_pm)) {
D_printf("DPMI: Return from protected mode interrupt handler\n");
+ if (in_dpmi_hw_int) {
+ in_dpmi_hw_int--;
+ if (!in_dpmi_hw_int && _ss != PMSTACK_SEL) {
+ error("DPMI: Client's PM Stack corrupted!\n");
+ leavedos(91);
+ }
+ }
/* ---
|(000FC925)|
|(dpmi_sel)|
Re: dosemu: versions: still com ports
Hello. > I am wondering about the versions of dosemu. Somebody suggested I use > dosemu-1.1.3. However, while i did find a redhat package with this > version number, You are definitely confusing something - pre-packaged dosemu-1.1.3 must not exist. Could you provide a link to where you've seen it? > My present version is 1.0.2, and this also > appears to > be the latest stable version at dosemu.org. This is almost true, however there is a fix version 1.0.2.1. > Can somebody explain this > to me? Your statement about rpm'ed version of 1.1.3 seems really unexplainable to me... > Also, I am still trying to figure out what permissions root has that I > don't > have that is allowing root to work the com ports in dosemu while I > still can't. You will be figuring that out probably for eternity unless you upgrade to atleast 1.1.2 :) - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dosemu-1.1.3 and Novell vlm.exe
Hello.
Grigory Batalov wrote:
> Ok, DR-DOS 7.03 works little better, vlm is working. But dosemu
> crashes when I start FoxPro 2.6/DOS:
> DPMI: realmode hlt: 0xfc920
> DPMI: switching from real to protected mode
> DPMI: Free Mem Blk. for handle 0003
> MAPPING: free, cap= DPMI, addr=0x404ad000, mapsize=6ed000
> DPMI: msdos_fault, err=0
It is unclear from this log (add +r option to
see also PIC events), but seems like the famous
dpmi problem.
Try the attached patch (several people reported
success with it). Also try PIC patches from
www.dosemu.org/~stas
It would be better to apply them together with
this one, but then you'll have to resolve a
trivial reject (apply PIC patches at first).
--- src/base/dev/pic/pic.c Tue Mar 19 19:45:50 2002
+++ src/base/dev/pic/pic.c Tue Mar 19 19:54:14 2002
@@ -806,7 +806,7 @@
#endif
if(pic_ilevel < 16) pic_push(pic_ilevel);
if (in_dpmi) {
- run_pm_int(intr);
+ run_pm_int(intr, 1);
} else {
#ifndef USE_NEW_INT
pic_cli();
--- src/dosext/dpmi/dpmi.h Tue Mar 19 19:45:49 2002
+++ src/dosext/dpmi/dpmi.h Tue Mar 19 19:56:56 2002
@@ -37,6 +37,7 @@
EXTERN int in_win31 INIT(0); /* Set to 1 when running Windows 3.1 */
EXTERN int dpmi_eflags INIT(0);/* used for virtual interruptflag and pending
interrupts */
EXTERN int in_dpmi_dos_int INIT(0);
+EXTERN int in_dpmi_hw_int INIT(0);
EXTERN int in_dpmi_timer_int INIT(0);
EXTERN int dpmi_mhp_TF INIT(0);
EXTERN unsigned char dpmi_mhp_intxxtab[256] INIT({0});
@@ -47,7 +48,7 @@
void dpmi_fault(struct sigcontext_struct *);
#endif
void dpmi_realmode_hlt(unsigned char *);
-void run_pm_int(int);
+void run_pm_int(int, int);
void run_pm_mouse();
void fake_pm_int(void);
--- src/dosext/dpmi/dpmi.c Tue Mar 19 19:45:51 2002
+++ src/dosext/dpmi/dpmi.c Tue Mar 19 21:01:00 2002
@@ -2016,8 +2016,9 @@
* DANG_END_FUNCTION
*/
-void run_pm_int(int i)
+void run_pm_int(int i, int async)
{
+ unsigned short CLIENT_PMSTACK_SEL;
us *ssp;
#ifndef USE_NEW_INT
@@ -2044,9 +2045,19 @@
return;
}
- if (dpmi_stack_frame[current_client].ss == PMSTACK_SEL)
+ if (async && !in_dpmi_hw_int) {
+D_printf("DPMI: Switching to locked stack\n");
+CLIENT_PMSTACK_SEL = PMSTACK_SEL;
+ }
+ else {
+D_printf("DPMI: Not switching to locked stack, in_dpmi_hw_int=%d\n",
+ in_dpmi_hw_int);
+CLIENT_PMSTACK_SEL = dpmi_stack_frame[current_client].ss;
+ }
+
+ if (dpmi_stack_frame[current_client].ss == PMSTACK_SEL || in_dpmi_hw_int)
PMSTACK_ESP = client_esp(0);
- ssp = (us *) (GetSegmentBaseAddress(PMSTACK_SEL) +
+ ssp = (us *) (GetSegmentBaseAddress(CLIENT_PMSTACK_SEL) +
(DPMIclient_is_32 ? PMSTACK_ESP : (PMSTACK_ESP&0x)));
/* ---
| 000FC925 | <- ssp here, executes pm int
@@ -2087,10 +2098,12 @@
}
dpmi_stack_frame[current_client].cs = Interrupt_Table[i].selector;
dpmi_stack_frame[current_client].eip = Interrupt_Table[i].offset;
- dpmi_stack_frame[current_client].ss = PMSTACK_SEL;
+ dpmi_stack_frame[current_client].ss = CLIENT_PMSTACK_SEL;
dpmi_stack_frame[current_client].esp = PMSTACK_ESP;
if (i == 0x08 || in_dpmi_timer_int) in_dpmi_timer_int++;
in_dpmi_dos_int = 0;
+ if (async || in_dpmi_hw_int)
+in_dpmi_hw_int++;
#ifdef USE_NEW_INT
dpmi_cli();
#endif /* USE_NEW_INT */
@@ -2200,7 +2213,7 @@
case 0x1c:/* ROM BIOS timer tick interrupt */
case 0x23:/* DOS Ctrl+C interrupt */
case 0x24:/* DOS critical error interrupt */
- run_pm_int(VM86_ARG(retval));
+ run_pm_int(VM86_ARG(retval), 0);
break;
default:
#ifdef USE_MHPDBG
@@ -2506,6 +2519,7 @@
in_dpmi++;
in_win31 = 0;
in_dpmi_dos_int = 0;
+ in_dpmi_hw_int = 0;
pm_block_root[current_client] = 0;
memset((void *)(&realModeCallBack[current_client][0]), 0,
sizeof(RealModeCallBack)*0x10);
@@ -2983,6 +2997,13 @@
} else if (_eip==DPMI_OFF+1+HLT_OFF(DPMI_return_from_pm)) {
D_printf("DPMI: Return from protected mode interrupt handler\n");
+ if (in_dpmi_hw_int) {
+ in_dpmi_hw_int--;
+ if (!in_dpmi_hw_int && _ss != PMSTACK_SEL) {
+ error("DPMI: Client's PM Stack corrupted!\n");
+ leavedos(91);
+ }
+ }
/* ---
|(000FC925)|
|(dpmi_sel)|
Re: Slow loading examined
Hello. Johan Gill wrote: > This is the symptom: Dosemu seems to lock up for some time when the > game > is supposed to read from CD. Refreshing of the Dosemu X window stops > for at least half a minute. Try starting xdos from within gdb and interrupt it with ^c when it locks. Then you can do a stack trace and see where it is sitting. > However, if I do 'make install' in a source > tree, > or something else to keep the disk busy, CD I/O is much faster. Then this is more likely not dosemu problem. I have similar problem with network cards: the communication is deadly slow (telnet's echo appears 1-2 minutes after typed), but if I do a flood ping in parallel, then everything works without any slowdown. (yes, this is not a joke about flood ping). Linux's hardware drivers are full of the curious things:( - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sherlock - an old DOS game
Hello. Jim Hartley wrote: > I have an old DOS game called Sherlock which I would like to run under > Dosemu. It does not work, just hangs up Just started it under xdos (dosemu-1.1.3), and it works perfectly. Console dosemu currently doesn't work for me, but I am sure that if the program works under xdos, it must also work under console. We are probably talking about different sherlocks however. My sherlock is a logic puzzle game. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sherlock - an old DOS game
Hello. Jim Hartley wrote: > So what's the trick? You say "xdos" ... does that mean I use "xdosemu" > to run it? Yes. "xdosemu" is a link to a startup script called "dosemu", but it makes sense which one to start. xdos is a link to a binary called "dos", which was used in older dosemu versions and still works for me (you probably don't have it, so use xdosemu). > And you mention 1.1.13 I think I mentioned 1.1.3 :) > that's a development version, not a > "stable" version, right? Right, but it is hard to say which one is really stable. They both have some known bugs, but my personal opinion is that 1.1.3 is more stable than 1.0.2.1 in many cases except DPMI support. Atleast it closes many known bugs from 1.0 branch. > But I guess I can get it and try it if it will > help If you have graphics at least in a single game but not in sherlock, then yes, go ahead and try 1.1.3. But if you can't get any graphics at all, then better focus on some docs to find out what are you doing incorrectly. In general x-dos must open a separate window called something like "DOS in X Box". If your dos starts up directly in xterm instead, then you have problems. > I assume I'll have to build it from a source tarball? Yep. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dosemu general protection error
Hello. > I'm running MSDos 6.2 on dosemu 1.0.2. The program asm5600.exe, which > runs in native dos, causes the below error message when run in dosemu. Just tried under PC-DOS 7.0, dosemu-1.1.3: Motorola DSP56000 Assembler Version 5.3.20 Copyright Motorola, Inc. 1987-1994. All rights reserved. So it works, which likely means that you have something wrong in your dosemu config file. Maybe not enough XMS/EMS/DPMI memory specified. Or maybe you need dosemu-1.1.3 - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dosemu-1.1.3 and Novell vlm.exe
Hello. Grigory Batalov wrote: > I. Dosemu-1.1.3 and freedos still crashes while loading vlm: > ERROR: general protection at 0x20360: 50 > Program=do_vm86.c, Line=389 Make sure you have enough XMS/EMS/DPMI memory configured. >> It would be better to apply them together with >> this one, but then you'll have to resolve a >> trivial reject (apply PIC patches at first). > I've done this. Any noticeable changes? (maybe not only with vlm) > 2. hangs after some period of inactivity. Can be killed, not loads CPU. Maybe it just gets very slow, but not hangs? Try increasing $_hogthreshold value (or set it to 0). > 3. crashes in different places while loading or working in FoxPro > 2.6/DOS. You didn't mentioned that it used to work sometimes. At this point the log (-D9+Mr) would be good. Btw, Sergey Suleymanov suggests to comment out the line "pic_request (PIC_IPX);" from src/arch/linux/async/signal.c. Try this and if it works, then you have nothing to do except waiting until this is fixed (probably during the current devcycle). - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Printing Problem
Hello. Suporte wrote: > send directly for the LTP1, the dosemu close job and sends a piece of > the archive for the spool of the Linux. > Because the Dosemu does not wait that the application finishes the > execution of the report to order job for the spool of the Linux? > What I can modify in source of dosemu to resolve this problem? This subject is rather old and you already have been suggested what is to modify in source. But one thing still puzzles me here, so I am wondering: Of course you have tried increasing $_printer_timeout value in your config file, havent you? Does this help? If not, then it is probably a bug that must be fixed. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Installing dosemu-1.0.2.tgz?
Hello. Felix Karpfen wrote: > My remaining question is, are there benefits from overwriting the > installed (already-working) dosemu-1.0.2 by the compiled version? The benefit is that you can compile something more modern instead of your 1.0.2, which is known to be buggy. And also you will be able to manually include any patches you want (like for ex. new Sound Blaster emulation:) Compiling the same 1.0.2 will unlikely to make any noticeable difference though. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dosemu-1.1.3 and Cyrillic_er
Hello. Sergey Suleymanov wrote: > Grigory> looks like 'P') when in X. Some time ago I got patch from > Grigory> Sergey Suleymanovor for dosemu-1.0.2 that fixes problem for > Grigory> 1.0.2 version. Maybe such patch exist for 1.1.3? > Just for 1.1.2 + Eric's patch. I think that this Eric's patch (was in this list: "Add koi8-r support for the russion hackers") went in dosemu-1.1.2.8, so why not? Or do you mean some other Eric's patch that wasn't in this list? And where is this glorious patch of yours? Having a proper keymap could be very handy. I was not reading this list for a long time so I probably have missed something in this thread. But as this subject is rather important for me, I have to pick up this old message. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dosemu-1.1.3 and Cyrillic_er
Hello.
Sergey Suleymanov wrote:
> Stas> And where is this glorious patch of yours? Having a proper
> Stas> keymap could be very handy.
> Well, here is it. (for 1.1.3)
Thanks, it works.
But one thing is strange: when I use a native
X switch (Xkb) to switch to Cyrillic, everything
works OK except the BackSpace key.
When I use a dos switch (KeyRus), everything
works OKey. So I suspect the problem is in
your patch somewhere.
For testing I wrote this prog:
---
#include
#include
int main() {
for (;;)
printf("%i\n",bioskey(0));
}
---
When Xkb is in US mode, this program shows
3592 when BackSpace is pressed (KeyRus state
is irrelevant). When Xkb is in RU mode,
program shows 3711 at BackSpace, which is not
correct.
All other keys seem to work good.
Under console also everything works, the
bug triggers only in X mode.
Any ideas why this happens with BackSpace?
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dosemu-1.1.3 and Cyrillic_er
Hello. Stas Sergeev wrote: > Sergey Suleymanov wrote: >> Stas> And where is this glorious patch of yours? Having a proper >> Stas> keymap could be very handy. >> Well, here is it. (for 1.1.3) > Any ideas why this happens with BackSpace? Well, turning off X_keycode "fixes" the problem. Can live with this:) - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dosemu-1.1.3 and Cyrillic_er
Hello.
Sergey Suleymanov wrote:
>>> Any ideas why this happens with BackSpace?
> Stas> Well, turning off X_keycode "fixes" the problem. Can live with
> Stas> this:)
> Hmm, can't reproduce that :(. 3592 in both modes.
Well, I have investigated a little more
and found that the attached patch fixes
the problem. Actually only the change to
altgr table is enough.
Does this help?
Why 127 is there?
--- src/plugin/kbd_unicode/keymaps.cTue Apr 23 17:32:37 2002
+++ src/plugin/kbd_unicode/keymaps.cWed Apr 24 16:53:09 2002
@@ -1755,7 +1755,7 @@
CONST t_keysym key_map_ru[] =
{
U_VOID, 27, '1', '2', '3', '4', '5', '6',
- '7', '8', '9', '0', '-', '=', 127, 9,
+ '7', '8', '9', '0', '-', '=', 8, 9,
'q', 'w', 'e', 'r', 't', 'y', 'u', 'i',
'o', 'p', '[', ']', 13, U_VOID, 'a', 's',
'd', 'f', 'g', 'h', 'j', 'k', 'l', ';',
@@ -1772,7 +1772,7 @@
CONST t_keysym shift_map_ru[] =
{
U_VOID, 27, '!', '@', '#', '$', '%', '^',
- '&', '*', '(', ')', '_', '+', 127, 9,
+ '&', '*', '(', ')', '_', '+', 8, 9,
'Q', 'W', 'E', 'R', 'T', 'Y', 'U', 'I',
'O', 'P', '{', '}', 13, U_VOID, 'A', 'S',
'D', 'F', 'G', 'H', 'J', 'K', 'L', ':',
@@ -1789,7 +1789,7 @@
CONST t_keysym altgr_map_ru[] =
{
U_VOID, 27, '1', '2', '3', '4', '5', '6',
- '7', '8', '9', '0', '-', '=', 127, 9,
+ '7', '8', '9', '0', '-', '=', 8, 9,
0x439,0x446,0x443,0x43A,0x435,0x43D,0x433,0x448,0x449,0x437,0x445,0x44A,
13, U_VOID,
0x444,0x44B,0x432,0x430,0x43F,0x440,0x43E,0x43B,0x434,0x436,0x44D,0x451,
@@ -1807,7 +1807,7 @@
CONST t_keysym shift_altgr_map_ru[] =
{
U_VOID, 27, '!', '@', '#', '$', '%', '^',
- '&', '*', '(', ')', '_', '+', 127, 9,
+ '&', '*', '(', ')', '_', '+', 8, 9,
0x419,0x426,0x423,0x41A,0x415,0x41D,0x413,0x428,0x429,0x417,0x425,0x42A,
13, U_VOID,
0x424,0x42B,0x412,0x410,0x41F,0x420,0x41E,0x41B,0x414,0x416,0x42D,0x401,
Re: dosemu-1.1.3 and Cyrillic_er
Hello. Grigory Batalov wrote: > Why do you prefer that patch than koi8-r from extra_charsets plugin? > It seems working for me. It works for me as well except for typing cyrillic since there is no "ru" keymap without this patch. How are you getting it to understand the cyrillic typing using a system switch? - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dosemu-1.1.3 and Cyrillic_er
Hello.
Sergey Suleymanov wrote:
> Stas> altgr table is enough.
> Actually only these are needed at all. ;)
But in fact this means that the problem
is still there.
The problem is that normally altgr map is
similar to the alt map, so the special keycodes
in it are mapped as for the alt map.
But you are reserving altgr map for Cyrillic,
so it must be treated as a plain map.
And for the plain map, the BackSpace keycode
gets altered back to 8, see init_misc_plain_map()
and init_misc_shifted_map().
So I think that the real fix would be something
like the attached patch.
> Stas> Does this help? Why 127 is there?
> I presume this is ^?. Anyway, ^H also works. Thanks.
Actually I think it is a bios keycodes, so it
must be 8. Which is done with the attached patch
and no need to modify the keymaps at all.
This patch also fixes some other small
problems with ctrl and alt modifiers in
cyrillic mode.
Does this look like a correct fix to you?
And of course the root of the problem
seems to be that dosemu currently doesn't
natively support the layout switching.
--- src/plugin/kbd_unicode/serv_xlat.c Tue Apr 23 17:32:37 2002
+++ src/plugin/kbd_unicode/serv_xlat.c Thu Apr 25 13:53:46 2002
@@ -361,11 +361,11 @@
}
static void init_misc_altgr_map(t_keysym *rule)
{
- rule[NUM_SPACE] = KEY_SPACE;
+ init_misc_plain_map(rule);
}
static void init_misc_shift_altgr_map(t_keysym *rule)
{
- rule[NUM_SPACE] = KEY_SPACE;
+ init_misc_shifted_map(rule);
}
static void init_misc_ctrl_alt_map(t_keysym *rule)
{
@@ -1134,10 +1134,11 @@
if ((shiftstate & ANY_ALT) && (shiftstate & ANY_CTRL)) {
ch = state->rules->map.ctrl_alt[key];
}
- else if ((shiftstate & (R_ALT|ALTGR_LOCK)) && (shiftstate & ANY_SHIFT)) {
+ else if ((shiftstate & ALTGR_LOCK) && (shiftstate & ANY_SHIFT) &&
+ !(shiftstate & (ANY_CTRL | ANY_ALT))) {
ch = state->rules->map.shift_altgr[key];
}
- else if (shiftstate & (R_ALT|ALTGR_LOCK)) {
+ else if ((shiftstate & ALTGR_LOCK) && !(shiftstate & (ANY_CTRL | ANY_ALT))) {
ch = state->rules->map.altgr[key];
}
else if (shiftstate & ANY_ALT) {
Re: dosemu-1.1.3 and Cyrillic_er
Hello. Grigory Batalov wrote: >> Grigory> Also I set $_external_char_set = "koi8-r" >> Grigory> $_internal_char_set = "cp866" in ~/dosemu/conf/dosemurc and >> Grigory> it works. >> As the Alt+keypad sequences. >Is it bad? =) Are you sure that you are using a *system* switch (xrus, xxkb) rather than a dos' switch (keyrus, keyb.com)? Because dos's switch works under xdos also without Sergey's patch, but not the system switch. And if yes, then how are you setting the $_layout option? Cause I don't think you can set it to "ru" without a Sergey's patch. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sound in dosemu ?
Hello. Thomas Weidner wrote: > what do i need to get sound in old dos games working ? You need this: 1. dosemu-1.1.3 sources 2. New SB (Pro) emulator from this page: http://dosemu.sourceforge.net/~stas/ > Do i need a dos soundblaster > driver ? No, you don't need any because old SB cards are supported directly by the dos programs. You have to only set the BLASTER variable to match your dosemu.conf settings. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sound in dosemu ?
Hello. Justin Zygmont wrote: > I tried that When? Are you using the latest revision (16) of the patch? > but the sound would only work for about 5 seconds, then > freeze up dosemu. Have you applied only SB patch, or also some other patches? Does it lock dosemu hard (so that Ctrl-Alt-PgDn doesn't work) or only the dos program locks? Please send me a full bugreport including the name (and URL if applicable) of the program you are running, sound log (-D9+S) and specify whether your program uses DPMI or not and does it work OK when sound is disabled. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MS-DOS and clipper
Hello. Bill Giannakopoulos wrote: > when i > am typing wrong the the program and dosemu is crach. > Do you have any idea what to do?? You have to provide an URL to your program and the exact instructions of how to reproduce the crash with the latest dosemu, which is currently 1.1.3. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need advise on how to proceed in debugging ...
Hello. Bryan J. Smith wrote: > 1. I'm having a bit of difficulty trying to figure out how to enable > debugging. There are a lot of debug options. You may enable the debug logging with -D9+xxx option, where xxx specifies the type of events you are going to log. So, to enable a file access logging, you'll have to specify something like "-D9+d -o /tmp/log" as a dosemu command-line arguments. Consult "man dos" for more. If you want to debug the program that is running under dosemu, you have to start "dosdebug" program that comes with dosemu. And if you want to debug dosemu itself (which is what you have to do in case it locks up), you have to recompile it with debug info and attach a gdb to it. > difference. I understand you can also "boot" a non-mounted, > "native/real" C: partition too. If so, can I run multiple instances of > DOSEmu, or am I limited to only 1 now since I'm booting a real > partition? Even if you are not strictly limited, you'll certainly have a filesystem corruption once the both instances of dosemu are going to write something simultaneously. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Strange dosemu behavior.
Hello. [EMAIL PROTECTED] wrote: > Is there any way I can get some debug output? Debugging output can be enabled with -D option (consult `man dos`), and with -o option you have to specify the file to which the logging being written. Also try to start the game under console suid-root dosemu since it works more reliably this way than under X. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sound in Doom
Hello. Stian Sletner wrote: > I know this has been discussed before, Sure. > I searched the archives but > couldn't deduce a clear answer. Very strange... > Is sound in Doom definitely out of the question, both now and in the > foreseeable future? Doom, Duke3d and the like games are *already* fully functional under dosemu and they work *with sound* (thanks to Vlad Romascanu for the info and hints on getting that games working with sound). What you need is just to visit this page: dosemu.sourceforge.net/~stas - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mouse Clicking Problem
Hello. Thomas Neidhart wrote: > i have some problems getting the mouse to work under dosemu-1.0.2. And you are lucky that you don't have many other problems with that particular version. > First i had the problem that the mouse movement was just not smooth, > but with > setting hogthreshhold to 0 this was much better. This was hopefully fixed/improved in 1.1.3. > But mouse clicking does not work anyway, if i click on the left button, > the > mouse cursor jumps to the upper left corner, and then right back, > without any effect. This is strange indeed... Just for the correct statistic: was that you who filled this bugreport on sourceforge, or this problem happens for several people now? > Any suggestions? Only one so far: upgrade your DOSEMU! Latest from 1.1 branch is 1.1.3.1 Latest from 1.0 is 1.0.2.1 (without mouse fix) And if the mouse problems are still there, please specify the program you are running under dosemu when this happens. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mouse Clicking Problem
Hello. Thomas Neidhart wrote: > i tried dosemu-1.1.3.1 and it got somewhat better: Good:) > The mouse clicking problem is also getting > better, > although from time to time it occurs again. Please produce the -D9+Xm log. > But upgrading to 1.1.3.1 also created some new problems. With DPMI programs, right? If so, then it is a known problem of 1.1.3 (since 1.1.2.7) > I have tested > it with > "Die Fugger 2", and this causes xdosemu to crashe > it crashes right after moving the mouse, Visit dosemu.sourceforge.net/stas page and grab the necessary patches from there. Let me know the results. And specifying the program's name doesn't help too much, please specify also an URL for download. > Also the mouse runs not smooth in this game > without > setting hogt. to 0. Does setting hogthreshold to 5, 10, 50 etc helps, or only 0? - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mouse Clicking Problem
Hello.
Thomas Neidhart wrote:
> i have tried all patches from you, and with them the programs don't
> crash anymore.
Very good. These patches are aimed to fix
the 1.1.3 DPMI breakage and, while they don't
currently cover the whole issue, they are
getting there (addressing many other problems
at the same time).
> Anyway the mouse move and click problem still remains.
Yes, this I have never been able to reproduce
hence I don't have a cure.
> The problem is that the mouse click behavior is not deterministic.
But is there something that affects it?
Does hogthreshold make any difference?
Is this problem happens only with a specific
program ("Die Fugger 2"), or with all programs?
> Sometimes
> it works fine, and the next time i start xdosemu it doesn't work right.
This smells really bad...
> The mouse click gets recognized if i "delay" the click and release the
> button then.
Does this make sense if you enable mouse grab
by pressing Ctrl+Alt+Home?
(your mouse must be blocked inside the xdos
window after you do this)
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Changes between 1.01 and 1.02
Hello. > Now I examined the dosemu 1.0.3 1.0.3 is a non-existant version. Do you mean 1.0.2, or 1.1.3, or is it something SuSE-specific? > I'm using symlinks c/d pointing to mounted real dos drives in > /var/lib/dosemu > in dosemu 1.0.1. Has this possibility gone in 1.0.2? It is still there. > Can someone tell me if an update to 1.0.2 could solve the problems Upgrade to 1.0.2 is not recommended. If you want 1.0 branch, use 1.0.2.1. > running > dpmi software like dbase IV. dosemu-1.1.3.1 with patches from dosemu.sourceforge.net/stas have more chances to solve your DPMI problems, but it depends on what the problems are exactly. > Is there a significant better serial code > which > was not working as good as it is wished when running dos fido mailers. Yes, atleast TMail was not working very well on some systems until dosemu-1.1.3. In general all progs that uses a FIFO mode and does early EOI, might hopefully feel better now and there was also a fix that prevents loseing the data in non-fifo mode. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dosemu packet driver, IPX
Hello. Kara Van Horn wrote: > When I tried adding WINPKT.COM (as > mentioned in the docs) to my IPX stack (WINPKT replacing PDIPX, > followed by > VLM), and specified a packet driver address as 0x60, it said there was > not one at that location. Make sure that $_vnet is *off* and then: E:\TEMP\PKTDRV>winpkt.com 0x60 Virtual packet driver for Windows 3.x, version 11.2 Portions Copyright 1991 Roger F. James Packet driver skeleton copyright 1988-90, Russell Nelson. This program is free software; see the file COPYING for details. NO WARRANTY; see the file COPYING for details. And never forget about logging. -D9+Pn will help you in that quest. > I installed the dosnet.o module into the kernel, > configured the dsn0 interface to have a subnet of 192.168.144.0, and > routed > a gateway for that same network out my linux box to eth0. $_vnet is on In case you want to have dosnet, you have to give root permissions to dosemu. > I tried both setuid root on and off the dosnet executable. dosnet.o is not an executable, it is a kernel module. > I also wasn't sure if I could also run the Greg Page suite of IPX tools > (i.e., ipx_configure, ipx_interface, et. al.) in conjunction with any > Dosemu > functionality. For this you have to configure IPX under linux and turn $_ipxsupport on. This seem to be possible. You have to disable dosnet in that case, I think. And if you turn IPX on, you don't need pdipx any more. If you have $_ipxsupport disabled, you can't use IPX tools. > requires a constant IPX connection (through a watchdog TSR). This is > when > the application fails, and I traced it back to this packet driver > issue. Dosemu's internal IPX support seems to be independant from dosemu's packet driver because it utilises linux kernel IPX functionality. So I don't think you have tracked your problem correctly. > I would also > appreciate some idea as to the progress of the Dosemu programming > effort. No (active) developers. If you need some functionality, you have to contribute yourself:( IPX is out of maintenance since 1997. > It appears to be somewhat stalled, from what I can tell. I agree. But you can always have a look into the ChangeLog for details. > I did not notice > much interaction with the programmers and this list, either, which does > not bode well. Dosemu have large enough user base (just see the sourceforge stats to get a clue of how large is it), but no developers to support. Hence the lack of the interraction and progress. I really think that the users have to contribute a little more in development process if they want to have a fully functional product. PS: Everything I told about IPX is based only on a single look at an IPX code I made yesterday to find out why doom's ipxsetup crashes. So my info may be incorrect. I have never used this functionality myself. And even a single look to that code was enough to find some bugs in it:( - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's up with Space Quest 2?
Hello. Johan Gill wrote: > I have dosemu-1.1.3.1 with mouse and dpmi_iret patches applied. According the log, it doesn't seem to use DPMI, so dpmi_iret patch might not affect. > When I try running Space Quest 2, dosemu exits. How good is it without any patches? Does it work on dosemu-1.0.2.1? It seems to use DMA before crash, does it make sense if you disable sound in program's setup or apply the sound patch? Do you have $_sound=(on) ? - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's up with Space Quest 2?
Hello. Johan Gill wrote: > It also crashes on 1.1.3. I don't remember exactly what went wrong with > 1.0.2.1 since it was a while ago. OK, I have downloaded something called the Space Quest, which turned to be a game dated 1987 with CGA graphics, by Sierra. If this is the game you mentioned, then it works fine here under dosemu-1.1.3.1 with PC-DOS 7.0, so you have to check your local configs. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unable to boot as user
Hello.
> At last I was able to track down the problem. It turned out to be that
> one should have the real floppy accessible in order to boot from the
> image. In my case, ordinary users have no access to /dev/fd0.
> I suggest the change below.
Your patch doesn't seem to attack
the root of the problem:)
Does the attached patch fixes this?
--- src/base/misc/disks.c Tue Mar 19 00:58:12 2002
+++ src/base/misc/disks.c Fri Jun 14 23:17:10 2002
@@ -1011,10 +1011,9 @@
int checkdp_val;
disk = LO(dx);
- if (disk < FDISKS) {
-if (!disk && use_bootdisk)
- dp = &bootdisk;
-else
+ if (!disk && use_bootdisk)
+dp = &bootdisk;
+ else if (disk < FDISKS) {
dp = &disktab[disk];
switch (HI(ax)) {
#define DISKETTE_MOTOR_TIMEOUT (*((unsigned char *)0x440))
Re: Interrupt divide by zero
Hello. > the > aplication I try to run is a Multi-user mode application that run on > DOS sessions Such programs might not work under dosemu. I am afraid you expecting way too much. > Error [35]: General Protection Fault in ZIMRTMU.EXE at 0377:011C Make sure that this program works on either WinNT or Win2000. Then you have chances. But if it doesn't - just give up trying it under dosemu and use bochs instead. > I have try many thigs like incresing memory for xms and ems and DPMI? > I have tryied > to load the HIMEM.SYS but I dosn?t work. You don't need himem.sys under dosemu (and it won't work either). > I have a RH7.2, the latest version of dosemu and the patch. There are many patches, which one? - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mapping Control and Shift Function Keys
Hello. Stephen Lee wrote: > I forgot to mention that Dosemu is run under Redhat 7.2 No, you forgot to mention the version of dosemu you are using. > My Foxpro application recognizes the F1-F12 keys fine but not the Shift > or the Control Fkeys. I ran a keyboard scan program in the DOS session > and it does not detect any of the Control or Shift Fkeys either. Where > to look next? Try dosemu-1.1.3.2 to take an advantages of a new keyboard code. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unofficial prerelease 1.1.3.2 for testing
Hello. Bart Oldeman wrote: > Please test the improved joystick support from Clarence Dang: it looks > very nice, but I don't have a joystick. He claims it works faster if > you enable pthreads (see compiletime-settings), but I experienced DPMI > crashes that way (DJGPP gcc immediately nukes DOSEMU), so left that out by > default. Can anyone confirm? Well, as I don't have a joystick, I can only confirm that dosemu doesn't even start on my machine when I enable pthreads. No problems with them disabled though. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
