Date:	Wed, 6 Apr 1994 22:27:37 +0200
From:	Stefan Eckart <S_Eckart AT lis DOT e-technik DOT tu-muenchen DOT de>
To:	djgpp AT sun DOT soe DOT clarkson DOT edu, dmb AT ai DOT mit DOT edu
Subject:	Re: Soundblaster code lockups?

> Date: Wed, 06 Apr 94 11:40:53 -0400
> From: David Baggett <dmb AT case DOT ai DOT mit DOT edu>
> 
> 
> Has anyone looked at my sound blaster code in contrib/sblaster?  I wrote it
> months ago and still have no idea what's causing it to lock up.  This would
> be the start of a really nice SB library for DJGPP, and I'd be willing to
> invest more time in it if someone were to send me a patch to either my code
> or GO32 (whichever is hosed).
> 
> Gerhard Kordmann <kordmann AT utrurt DOT uni-trier DOT de> sent me code that he claims
> fixes the choppiness.  Has anyone fixed the other problem?
> 
> Dave
> 

I'm currently also trying to find the cause of the lockup of your code.
The choppiness was easy to solve. You had programmed DMA and SB with
the buffer length instead of length-1.

As far as the lockup is concerned, it is caused by the real mode callback.
The code always hangs when the SB interrupt occurs while the CPU is in
real mode. The first bug I have found is in GO32: the hardware interrupts
are shifted from their usual 0x8..0xf vector location to a different and
variable location by reprogramming the interrupt controller. This shift
should be taken into account by the dpmisim int 31. Currently this works
only for the protected mode interrupt vector but not for the real mode
set vector function. So the real mode callback is installed at the original
vector location (8 + irq-number) and never called. I have tried to fix
this temporarily, but now the system hangs completely each time sb is
started. Either I've done something wrong or there is yet another bug
lurking somewhere. When I have found the cause I'm going to provide a
more formal bug report.

Bye,

Stefan.
--
stefan AT lis DOT e-technik DOT tu-muenchen DOT de

- Raw text -