Hi Brian! Interesting program that SBINIT.COM - needs protected mode but can only get there with help of VCPI or DPMI. You can try to load CWSDPMI in resident mode (read the help, should be available at the DJGPP homepage at DJ Delorie), maybe DPMI works better than VCPI here.
> "DEVICE=C:\FDOS\BIN\HIMEMORY\EMM386 FRAME=NONE EMM=1024" > ... and any /EMM=xxxx values below 2354 cause the following error: Interesting, but then you already know the solution - use an EMM=... value above 2354. Or use NOEMS, unless you need EMS. > CS=1FA7 IP=01FE SS=1FE5 SP=4D6C DS=0000 ES=1FCA > EAX=0000DE0C EBX=00024BEA ECX=00010006 EDX=010037FC > ESI=0001FE04 EDI=0100FE1A EBP=00014D74 > OPCODES @CS:IP CD 67 9D 8B C1 1F 5F 5E This is: > --------E-67DE0C----------------------------- > INT 67 - Virtual Control Program Interface - SWITCH TO PROTECTED MODE > AX = DE0Ch > ESI = linear address in first megabyte of values for system > registers (see #03665) ... so the program tries to switch to protected mode and then something goes wrong. This could be debugged with help of Bochs PC simulator, but would SBINIT refuse to run if no SB card is installed? (registers are CR3, GDTR, IDTR, LDTR, TR, CS:EIP, by the way, and the GDT and IDT have to be in the first MB, maybe SBINIT tries to stretch that definition and has created the tables in the first FOUR MB?) > CS=0357 IP=0030 SS=0BA6 SP=000C DS=0000 ES=025D > EAX=00000700 EBX=00285E20 ECX=00000000 EDX=000037F0 > ESI=00000493 EDI=0000C4E0 EBP=00003A48 > OPCODES @CS:IP CD 67 84 E4 74 01 F9 FB Those segment values could be inside protected mode. So I assume that the opcode dump could be misleading. There is no function 07 in the int 67 EMM386 interface. The stack pointer is very low, maybe an internal error in EMM386 lead to a recursive exception which drained the protected mode stack (could happen if the error display routine does not take care of the different stack layout in protected mode exceptions properly). Apart from that, Michael will be able to tell you more about those error dumps. Maybe you two can figure out some more details together, off-list. > The "one board wonders" with onboard sound using the 686A & 686B VIA > ... BIOS blaster enabled are becoming scarce ... I think when I last tried such a board, DETECTION in DOS was okay but the mixer acted weird and I could not HEAR anything. So nice to hear that the BIOS SB emulation at least works sometimes ;-). > This is what has caused me to resort to using a PCI audio card You seem to be very keen on having that sound support - you even offered to send test hardware - so I suggest that you give your SOFTWARE a generic AC97 driver. Would that be an option? The FAQ lists some sample DOS AC97 code. Some comments to Bernds comments: > Do you have legal access to MS-DOS 6 or Windows 9x ? > in that case you could try MS's EMM386 You can download EMM386 from MS homepage, but it is closed source. > Not many people use (sound in) DOS anymore > Unfortunately I've given away my Soundblaster Live 5.1 I used SB AWE32 PnP ISA, and on other systems I used similar ISA PnP cards. I think I never tried PCI yet... but PCI, once the BIOS or a DOS program has activated the card, looks exactly like ISA for old DOS programs. The problem is that DOS programs cannot program the bus controls / activate cards themselves. And hardware people have switched from SB16 compatible sound chipsets to other standards and nonstandards (as long as it comes with a driver for "the standard OS" people do not really care for standardized hardware anymore :-(...!?). So Bernd, SB Live 5.1 works fine in DOS? Any TSR drivers needed for that? > I think AC97 codec has DOS drivers available, but I don't know how > compatible it is with the DOS standard cards AC97 hardware is completely different from SB16, but there are protected mode DOS drivers, sometimes even in BIOS, which trap access-to-SB16 attempts and translate and redirect them to AC97 hardware. Only VERY few DOS programs know how to use AC97 directly. But again, if YOU have the source, then YOU can add a native AC97 driver directly to your sound program. > some freeware emulators have decent SB16 emulation. VDMsound project, > Dosbox, Bochs, Qemu maybe, Microsoft's VirtualPC maybe, VDMsound / DOSBOX are special Windows things. Bochs and Qemu are simulators which simulate the a whole computer, and there are Linux and Windows versions of Bochs... DOSBOX simulates SB16 dsp and adlib/opl3. For Linux, there is DOSEMU which simulates not the CPU but only the peripherals (faster!), and it has SB16 dsp simulation and some support for MIDI. Opl3/AdLib support is experimental as far as I know. Eric ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
