source: sbliveos2/trunk/Build.txt@ 171

Last change on this file since 171 was 170, checked in by sandervl, 25 years ago

* empty log message *

  • Property svn:eol-style set to native
  • Property svn:keywords set to Author Date Id Revision
File size: 6.3 KB
Line 
1/* $Id: Build.txt 170 2001-03-25 22:06:20Z sandervl $ */
2 SoundBlaster Live! OS/2 Audio driver Build Instructions
3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4Contents
5========
61 Introduction
72 Required tools
83 Recommended tools for debugging
94 Building the driver
105 SBLive driver architecture
116 Difference between the two kinds of 32 bits drivers
12
131 Introduction
14==============
15This document lists all the needed tools and compilers to build the SB Live
16OS/2 audio driver.
17It also tries to give some information about the architecture of the driver
18and explain some technical details.
19
20However, it does not attempt to explain everything. People that are not
21familiar with either device drivers or MMPM/2 audio drivers should
22read the PDD & MMPM/2 driver references. Although those two documents
23are not meant for beginners, they do contain a lot of very useful information.
24
25You can always email me (sandervl@xs4all.nl) if you wish to help out with the
26development of the driver and have some questions.
27Please make sure you've read at least the pdd & mmpm2 references and try
28to understand the source code before doing so.
29
30
312 Required tools
32================
33- Watcom C/C++ version 11.0b
34- ALP 4.x (IBM assembler; comes with ddk)
35- IBM OS/2 DDK (http://service.boulder.ibm.com/ddk/)
36 - Base headers/libraries/tools (combase.zip)
37 Due to a typo in devhelp.h, you must change the DevHelp_VMProcessToGlobal macro:
38 USHORT DevHelp_VMProcessToGlobal(ULONG Flags, LIN LinearAddr, ULONG Length, PLIN GlobalLinearAddr);
39 #pragma aux DevHelp_ProcessToGlobal = \
40
41 - MMPM/2 base (mmpmdd.zip)
42 - PDD & MMPM/2 driver reference
43
443 Recommended tools for debugging
45=================================
46- ICAT debugger (follow link from IBM DDK page)
47- OS/2 Debug kernel
48
49
504 Building the driver
51=====================
52You can build the driver from the main directory by executing:
53 WMAKE -f makefile.os2 /ms
54
55To build the debug version of the driver (which can be used with ICAT
56for source-level debugging) run
57 WMAKE -f makefile.os2 DEBUG=1 /ms
58
59To build the KEE enhanced version of the driver
60 WMAKE -f makefile.os2 KEE=1 /ms
61
62
635 SBLive driver architecture
64============================
65Simplified overview of the flow of control from a multimedia application
66to the SB Live driver. (for a more complete overview, check the MMPM/2
67Device Driver Reference; Audio Physical Device Driver Template/PDD architecture)
68
69 |=============|
70 | |
71 | application |
72 | |
73 |=============|
74ring 3 | ^
75--------------------------------------------------------------------------------
76ring 0 | |
77 v |
78 |=============|
79 | |
80 --->| MMPM/2 |
81 | | |
82 | |=============|
83 | | IOCtls |
84SHD calls | | |
85to return | | | IDC
86buffers | | |
87 | | |
88 | v v
89 | |-------------| OSS cmds |-------------|
90 | | | <---------> | |
91 ----|sblive16.sys | irqs |sblive32.sys |
92 | | ----------> | |
93 |-------------| |-------------|
94 ^ |
95--------------------------------------------------------------------------------
96hardware
97 irqs | |
98 | | hardware programming
99 |==============| |
100 | | |
101 | SB Live card |<-----------
102 | |
103 |==============|
104
105
106The drv16 directory contains the sources for the 16 bits driver that handles
107all MMPM/2 commands and communicates (IDC) with the 32 bits core driver using
108OSS (Linux audio api) commands.
109Sblive32.sys contains a small wrapper that interprets the IDC commands and
110translates them into appriate calls to the original Linux OSS driver (ioctls/
111open/close/read/write).
112Basically, the Linux code in sblive32 treats the 16 bits driver as a Linux
113application trying to use the audio card.
114
115During the init complete strategy call of sblive16, it sends the init command
116to the 32 bits driver. Which ends up calling module_init in the Linux code
117(sblive\main.c). At this point the Linux code tries to detect the sblive
118hardware using Linux pci kernel calls.
119All Linux kernel calls are implemented in sblive32 using OS/2 system calls.
120(i.e. kmalloc uses DevHlp_VMAlloc)
121
122The original Linux SB Live! sources have not changed for the most part.
123An exception is the acknowledgment that part of a buffer has been played/
124recorded. (emu10k1_waveout_bh/emu10k1_wavein_bh in sblive\audio.c)
125OSS32_ProcessIRQ is called from those procedures to tell the 16 bits driver
126to query the current position and return/queue buffers if needed.
127
128The 16 bits driver is more or less a generic MMPM/2 driver that could be used
129(in theory) to port any OSS Linux audio driver.
130The wrapper and linux kernel calls implemented in the lib directory can
131also be reused.
132
133
1346 Difference between the two kinds of 32 bits drivers
135=====================================================
136Warp Server for e-Business (and now Warp 4 too; with fixpack 13) feature
137a new 32 bits kernel api for physical device driver (well, not entirely true).
138
139The 'standard' 32 bits driver (not compiled with KEE=1) is a 32 bits compact
140memory model driver. (cs=ds, ss!=ds; small code, large data)
141The stack is still 16 bits and the SS and DS selectors are not identical.
142Therefor all pointers are far by default. (32 bits far; meaning 16:32, 16
143bits selector, 32 bits offset)
144
145Using this memory model works fine, but is a bit inefficient and not ideal
146for porting 32 bits code (which may have hidden dependencies on the 32 bits
147flat memory model; the sblive driver has none).
148That also explains why the standard 32 bits driver is 18kb larger than the
149KEE version.
150
151The 'enhanced' 32 bits driver uses the KEE interface to create a true 32 bits
152driver (cs=ds=ss).
153
154A small 16 bits part is still needed as our IDC, strategy and irq handlers
155are expected to be in the 16 bits code segment.
156An assembly file (drv32\startup.asm) takes care of the thunking that is
157required.
158
159
Note: See TracBrowser for help on using the repository browser.