##################################################################### # # PRODUCT # Thor-2 Windows 95 Driver # and the Application Programming Interface (API) # # PRODUCT NUMBER # SDA-1003-1 # # PRODUCT REVISION # See topmost history entry below # # COMPILER # Visual C++ 5.0 # # SEE ALSO # API Reference Guide for Thor Windows 95 Driver (1211-1-SDA-1003) # # CONTACT INFORMATION # Odin TeleSystems Inc. # 800 East Campbell Road, Suite 300 # Richardson, Texas 75081-1873 # U. S. A. # Tel: +1-972-664-0100 # Fax: +1-972-664-0855 # Email: Support@OdinTS.com # URL: http://www.OdinTS.com # # Copyright (C) Odin TeleSystems Inc., 1996-1998 # ##################################################################### Technical Support: ================= Email: Support@OdinTS.com Fax : +1-972-664-0855 Phone: +1-972-664-0100 (M-F 9 a.m. - 5 p.m. CST (GMT-6)) Distribution Directory structure: ================================= LIB Thor-2 API lib compiled with Visual C++ 5.0 (32-bit mode). INC Thor-2 API Header files UTILS Utilities need to use the Thor-2 Board (T2boot and T2config). For a complete description these program please See "User Guide for Thor-2", Doc No. 1412-1-HAA-1004-1. SYSTEM Contains the Thor-2 Virtual Device Driver file: Thor2.vxd This file is also copied to the Windows System directory (E.g. C:\WINDOWS\SYSTEM\ ) by the installation program. DEMOS Demo programs (source and executable) using the Thor-2 API. SAPIAPP: HDLC send/receive demo program using the System API. Loops two Line interfaces. LAPIAPP: HDLC send/receive demo program using the Low Level API. Loops two Line interfaces. HAPIAPP: HDLC send/receive demo program using the High Level API. Loops two Line interfaces. DATAAPP: Example program using Transparent Mode Pipes. Transfers a binary file between two Line interfaces. PATAPP: Example program using Transparent Mode Pipes. Processing of full 2,048 Mbit/s stream. Continuously sends and receives data on 32 time-slots. T1APP: Example program demoing how to use the T1 specific features, such as the bit-robbed signaling. E1APP: Example program demoing how to use the E1 specific features, such as access to the Si and Sa bits. PHONEAPP: Example program for using the codecs (handsets) and the DTMF transceivers. STATUSAPP: Simple application which checks the status of the driver and the installed Thor-2 boards. PERFAPP: Example program demoing the use of multiple pipes (time-slots) to constantly send and receive HDLC frames. AUDIOAPP: Demostrates Thor-2's audio capabilities and the use of hdlcMemoryXXXXX() API functions. SS7APP: Demostrates Thor-2 drivers SS#7 support and the use of hdlcSS7XXXXX() API functions. V86APP: Demonstrates how a DOS aplication can use the 32-bit Win95 Driver (VxD). This is not generally recommended but possible. Make 32-bit apps whenever possible. What is new in release, 1.36 ============================ Added status message LPU_INTERRUPT_REQUEST. What is new in release, 1.35 ============================ Internal storage of serial number information changed. Corrected a bug in drvCleanup() where this function would return a return code other than THOR_SUCCESS, even though the function call completed successfully. Clock mode MVIP_MASTER_CLK (when Thor-2 is a MVIP slave) now works properly. Users of SAPI can use the Error.H include file to convert from a ThorRC code to an error string. What is new in release (1.31) =================================== Clock modes INTERNAL and EXTERNAL_8K are now correctly sourced. What is new in release (1.30) ============================= Added thorDtmfStatus() in the V86 lib. There are no longer side effects from calling thorPhoneOn() and then calling thorSendDtmf(). The handset now remains connected during the transmission of the DTMF digits. What is new in release (1.29) =============== ============= The VxD is now dynamically loadable and unloadable. The driver is initially setup to load when the system is booted (statically loaded) and unload when the system is shut down. Edit the registry to disable the static loading and use dynamic loading instead. Do the following. A) Export the existing entries so they can easily be restered later. 1) start regedit 2) find the key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\THOR2 3) select menu "registry/export registry file" 4) select a good filename and location for the exported data B) Delete the key that was exported in step A. To restore static loading just use regedit to import the the file created in step A or add the entries manually. (The exported file is plain text command file interpreted by regedit). When the driver is not statically loaded an application linked with the thor2.lib will try to load the thor2.vxd from the current directory. If this doesn't work the application (the linked lib, actually) will try to load the thor2.vxd from the Windows\System directory. The install program places thor2.vxd in the Windows\System directory by default so dynamic loading should work transparently once the registry entry has been deleted. For most users static loading is preferable, but in cases when it is required to switch back and forth between different versions of the driver dynamic loading may be more convenient. In this revision of the driver a libV86 library is provided that allows DOS applications running in a Windows 95 window to load, unload and access the same VxD as Win32 applications use. Support for super stable onboard oscillator (1ppm) as available on Thor2 1.2 has also been added. What was new in Release 1.24.3 ============================== Implemented drvFifoXXX() functions which allow the application to monitor the status of the driver's message FIFO. Corrected an undesired feature that caused the drvReadMemBlock() to return wrong data. What was new in Release 1.24.1 ============================== Corrected an undesired feature that caused the HDLC controller to report older received HDLC messages as currently received messages. What was new in Release 1.24 ============================ The driver now provides support for SS#7. Pipes can be configured in PM_HDLC_SS7 mode. In the SS#7 mode pipes will constantly send Fill-In Signalling Units (FISUs). At the receiving end, the FISUs (as well as LSSUs or MSUs) can be filtered out by specifying applicaple filter mask. See 'Apps\SS7App\SS7App.c' and 'inc\hdlc.h' for details. The new hdlcSS7XXXX() functions are: hdlcSS7SetFisu(...) hdlcSS7GetSendStatus(...) hdlcSS7GetReceiveStatus(...) hdlcSS7SetFilter(...) hdlcSS7GetFilter(...) hdlcSS7SendData(...) LAPIAPP now provides an example on how to access and use multiple Thor-2 boards in one PC. What was new in Release 1.23 ============================ The Driver now comes with T2ConfigW.exe application, which provides a graphical user interface for configuration the T1/E1 communications parameters on the board. The driver now also implements new hdlcMemoryXXXX() functions: hdlcMemoryAlloc(...) hdlcMemoryFree(...) hdlcMemoryWrite(...) hdlcMemoryRead(...) hdlcMemoryCheckId(...) hdlcMemoryCheckUsage(...) hdlcMemoryStartIdlePattern(...) hdlcMemorySendData(...) hdlcMemorySendDataList(...) hdlcMemoryGetSendStatus(...) which allow data (e.g. transparent data) to be pre-loaded to the memory and then send from there over and over again. for more details on these functions please refer to 'Apps\AudioApp\AudioApp.c', 'inc\hdlc.h' header file and the API reference guide. The driver also supports sending of MF digits using the Codecs. cdSendMf(..) For more information, see the header file 'inc\cd.h' and the API reference guide. What was new in Release 1.22 ============================ The driver now supports event driven applications. The System API (SAPI) can notify the application with a Win32 Event when a message has been received or line/HW status has changed. (See IOCTL_DRV_START_EVENT_NOTIFICATIONS) The Low-Level API (LAPI) and High-Level API (HAPI) contain functions that allow the application to register a call-back function to be called by the driver upon reception of a message or Line/HW status change. (See drvRegisterCallback() and thorRegisterCallback(), respectively ) The demo applications (LAPIAPP, HAPIAPP, SAPIAPP, PHONEAPP, T1APP, and E1APP) have been modified to work with this event driver paradigm. I.e. they do not poll the driver any more. They will go to sleep instead and will only wake up when they receive an event/callback from the driver or a Windows keyboard event. What was new in Release 1.21 ============================ More demo applications. What do I need to know before upgrading to this release? ======================================================== If you are upgrading from Driver Revision 1.16 or older, please note the following changes: The API interface has a minor change. The drvInit() function now takes a driver mode as a parameter. For now always use DM_STANDALONE. This is in preparation for next releases where the driver will support several different modes: DM_STANDALONE // This driver is handling everything. There is no other // Thor-2 driver running. Can be used in either LPU or CPU DM_LOW_LAYER_LPU // (LPU only) The LPU is handling the lower protocol layers // (implies that the CPU driver must be in DM_HIGH_LAYER_CPU mode) DM_HIGH_LAYER_CPU // (CPU only) The CPU is handling the upper protocol layers // (implies that the LPU driver must be in DM_LOW_LAYER_LPU mode) DM_PARALLEL_LPU // (LPU only) The LPU driver is handling some pipes. The CPU driver // is handling some other pipes (the tasks are totally independent). DM_PARALLEL_CPU // (CPU only) The CPU driver is handling some pipes. The LPU driver is // handling some other pipes (the tasks are totally independant). The IOCTL codes have changed (they are now shared with the NT driver). Any application using the SAPI interface must be recompiled and any application using the LAPI or HAPI interfaces must be re-linked with the new Library. The applications using the SAPI interface must be compiled with #define T2_VXD_DRV (See the demo makefiles). How to Build the Demos? ======================= To build the Demo Applications open the DEMOS.DSW Workspace in the Microsoft Developer Studio 5.0. The DEMOS.DSW file is located in the DEMOS directory. Each Demo program has their project file *.dsp located in the corresponding source directory. Alternatively, use the make-file (with Microsoft nmake) located in the directory of each demo. For more information on each demo, please refer to the header comment in the beginning of each source file. For a description of the API please refer to the document: Appliation Programming Interface (API) Reference Guide, Doc. No. 1211-1-SDA-1003. How to test that the Thor-2 Driver/Board works? =============================================== Using StatusApp --------------- Run STATUSAPP.EXE in a DOS command window. Example output for one working board is shown below: STATUSAPP, Nov 5 1997, Odin TeleSystems Inc. Checks the status of the driver and the installed boards Using Driver 'Thor-2 Windows 95 Driver SDA-1003-1, Rev 1.24, Nov 5 1997' Driver status is OK! Number of Boards installed: 1 Irq = 5 IoBaseAddr = 0x280 InfoBufferSize = 32768 BOARD #0: memWinOffset = 0xD0000 memWinSize = 0x2000 ioWinOffset = 0x290 ioWinSize = 0x10 brdDramSize = 2097152 Searching for Thor-2 Board #0 ....Found. Checking board #0 status ....OK. Using LapiApp ------------- Connect the Li0 RJ11 and Li1 RJ11 together with the supplied Li Loop Cable. Start Application LAPIAPP.EXE in a DOS command window. Verify that the the Physical layer comes up: Li:0 Layer 1 Status = OK Li:1 Layer 1 Status = OK Press 't' to send a dummy HDLC messages from Line Interface 0 to Line Interface 1 through the Loop Cable. The received message should be displayed in the screen. Send a message on pipe 0 0 Src: 001 #005 09:24:52.22 [00] HDLC 00 01 02 03 04 05 06 07 08 09 00 01 02 03 04 05 06 07 08 09 00 01 02 03 04 05 06 07 08 09 00 01 02 Planned improvements in future releases: ======================================== Add support for V.110 and X.30 Add support for different driver operation modes: DM_STANDALONE, DM_LOW_LAYER_LPU, DM_HIGH_LAYER_CPU, DM_PARALLEL_LPU, and DM_PARALLEL_CPU