The Macintosh serial ports are a neglected programming subject. Few (if any) books on programming cover them, and this lack of information is compounded by an absence of source code to study.

The simplest way of programming the serial ports is to use a high level language and fool the compiler into thinking that the ports are disk files. Then you can use the languages generic file I/O routines for serial I/O. While this solution provides a simple way of dealing with the serial ports, it may not provide the speed or flexibility that may be required in certain applications.

I thought that a better approach would be to write a set of low level routines that can be linked with compiler generated code, or with assembly language. How difficult could this be? All Id need was the hardware manual for the Macs serial port chip, a copy of Inside Macintosh, a steady source of caffeine and a few hours of coding...right?

I quickly discovered that the task of writing drivers for the Mac is serious business. Life is too short for the hassles involved in trying to write a driver for the the complex (and bizarre) serial port chip, a Zilog 8530 SCC. Besides, its already been done; Kirk Austins excellent articles A Midi Library for Pascal and Midi Demo Uses Midi Library in the July, 1987 and December, 1987 issues of MacTutor show how to write drivers for this chip, if youre interested in working close to the bare metal of the machine.

How I Learned To Stop Complaining And Love The Device Manager or Gee, I didnt realize it would be this easy

Midi has certain timing and handshaking constraints that demand specialized serial drivers. I needed something a lot simpler; a set of routines that could send and receive data, at baud rates that would probably never exceed 19200 kilobaud. There had to be a way of doing this that didnt involve writing a complex driver. As often happens when programming the Macintosh, a solution became obvious only after re-reading several chapters of Inside Macintosh (or to put it another way: when all else fails, read the manual). While the Serial Drivers chapter would seem like the obvious place to look for information on using the serial ports, the Device Manager chapter is far more important; the Macintosh treats the serial ports as devices, so accessing the drivers requires using the Device Manager I/O routines.

The Device Manager can be divided into Pascal based file I/O routines, and low level traps. The high level Pascal routines (they can also be called from C. But you already knew that) have an extremely simple calling sequence, and insulate the programmer from the inner workings of the Device Manager. However, since these routines are not in the ROMs, the glue routines have to be linked with any assembly language program that uses them.

The low level Device Manager traps require more work to use, but they provide greater control over the I/O. I could have used the high level routines in my program, but since I had to use a low level Device Manager trap to configure the serial port, I decided to write everything using the other low level traps; the code is smaller and probably a bit faster.

The serial ports have been assigned four driver reference numbers, which are used by the Device Manager to identify the device it is working with:

Modem port input ( port A ) -6

Modem port output ( port A ) -7

Printer port input ( port B ) -8

Printer port output ( port B ) -9

Ive used these reference numbers directly in the code, instead of using the reference numbers returned by the _Open trap (the numbers should be the same). It simplifies the coding, at the risk of making the routines non-functional if and when Apple decides to change the reference numbers.

The Device Manager traps use a block of memory (pointed at by register A0) called a parameter block. It holds the pointers, commands and flags that may be required by the Device Manager trap being called. Depending on the call, it may also contain information returned from a device. A generic parameter block can be up to 80 bytes long, but when calling the serial ports most of the parameter block entries can be ignored. This still means that my routines have to set up and maintain a parameter block each time they are called. At first, even this small overhead in execution time and memory requirements made me uncomfortable; however this is an acceptable compromise considering the amount of code required to write a low level serial driver.

In retrospect, using the Device Manager to control the serial ports turned out to be an easy task, although I spent more time than Im willing to admit learning how to write these serial I/O routines. In the process, I discovered that Apple provides serial port drivers in a resource called SERD (built into the ROMs of the more recent Macs). At the time I wrote my routines, SERD was not in ROM and its use was (and still is) poorly documented. It was also more code than I had expected, so I went ahead with my routines.

One of my first attempts at using the Device Manager was a simple terminal program written in Turbo Pascal. It worked, but I decided to re-write it in assembly because (I know many of you will cringe) I enjoy writing in assembly language! I realize that its an acquired taste and that most of you would prefer to keep your contacts with assembly language to a minimum, so these routines have been written to make them accessible from Pascal. The routines will also work with C, but you may have to modify them to match the C parameter passing protocol. Ive also written a small terminal program that shows the routines in use. The bulk of the program consists of code to use TextEdit, manipulate the clipboard and code to do the usual housekeeping routines. Youll almost need a magnifying glass to find the calls to the serial routines!

Serial I/O Routines

The serial I/O routines make extensive use of the stack, for parameter passing and for holding the parameter block required by the Device Manager routines theyll be calling.

Parameter blocks are common structures, and can be found in most Macintosh I/O routines. In assembly language, we can define a parameter block as a buffer in the global variable space, or we can use the approach used by many high level language compilers and define the parameter block as a temporary structure on the stack. On entry, each routine sets aside a small section of the stack, known as a stack frame, and points to it with register A6. This private section of memory is then set aside as a parameter block.

Making the parameter block a temporary structure on the stack saves us from having to declare it as part of the global variable space; the local stack frame and all its contents are discarded when the routine terminates. Using this technique increases the complexity of the routines, but their portability and ease of use far outweighs the minor increase in execution time and code size.

Before we use a serial port, its driver must be open and the port must be configured. OpenSerial opens the specified serial port driver (either the modem or the printer port) and kills any pending I/O operations to it. The routine uses the drivers input reference number (-6 for the modem port and -8 for the printer port) to open both the input and output sections, and expects to find the appropriate number on the stack. Figure 1 shows the local stack for the OpenSerial routine.

OpenSerial starts by setting up the stack frame and allocating the space for the parameter block. It then makes register A0 point to the parameter block, as expected by the Device Manager. OpenSerial uses the Device Manager _Open trap which at most has only three entries in its parameter block. Since none of these serial I/O routines are making asynchronous calls to the Device Manager, OpenSerial can ignore the ioCompletion pointer. It can also ignore the ioPermssn byte, leaving only ioNamePtr, which is filled after OpenSerial checks which port is to be opened. Since both the input and output sides of a port must be opened, OpenSerial calls the Device Manager _Open trap twice. Once this is done, the routine saves the result code (returned in the parameter block at ioResult) on the return stack and calls the Device Manager one more time, to kill any pending I/O operations to the port. Since the parameter block remains unchanged, OpenSerial can call the _KillIO trap directly. Before returning to the calling program, OpenSerial discards the local stack (and the parameter block) and clears the port number from the return stack, leaving only the result word.

The code segment below shows the calling sequence for OpenSerial (PortA refers to the modem port driver and was set to -6 by an equate statement somewhere else in the program).

Since OpenSerial is usually followed by the configuration routine, I leave the result code on the stack (it will be zero if the port opened successfully) and use it to mark the space for the the next routines result code. Config resets the serial port and sets it to the new baud rate, data bits, stop bits and parity desired. Config doesnt modify some of the other important serial port parameters (mainly handshaking) since the default parameters suited my needs. Like OpenSerial, Config expects to see the ports input driver reference number on the stack. It also expects to see a configuration word, which represents the baud rate, data bits, stop bits and parity being set. Figure 2 shows the local stack for Config and the code section below shows its calling sequence.

Config uses the Device Manager _Control trap, which requires a few more parameters than OpenSerial. Two parameters, ioCompletion and ioVRefNum (serial ports dont have volume names) can be ignored, but it must set the ioRefNum to that of the port being configured. Config uses the csCode parameter to tell the Device Manager to reset the port. The new configuration value is passed in csParam.

For some applications, opening and configuring the serial port is all you need to do to initialize it for use. Unfortunately, the default size of input drivers buffer (set by the Device Manager) is a tiny 64 bytes, and this small buffer can become a major problem.

We all know that TextEdit is no speed demon. If youre writing a communications program and use TextEdit to display the incoming text, characters may be received by the port faster than TextEdit can display them. The 64 byte serial input buffer will quickly overflow and you will lose some characters. Luckily, this input buffer can be resized using SetBuf. This routine, like OpenSerial and Config, requires a reference number for the ports input driver. It also requires a long word that represents the buffers new size.

SetBuf, like all the other routines, starts by setting aside some room for the parameter block. It will then request a nonrelocatable block from the Memory Manager to serve as the new input buffer. If SetBuf succeeds in getting the new block, it tells the input driver to use this buffer through the Device Manager _Control trap. Figure 3 shows the local stack for SetBuf.

In this example, the input buffer is made 512 bytes long. Since SetBuf is usually the last step in initializing a serial port, the result word that was floating on the stack from the previous two routines (OpenSerial and Config) finally gets popped off. As weve come to expect, if SetBuf has a problem allocating the memory for the buffer, this word will be non-zero.

Its important to set the input buffer back to the default value before terminating your program (the programmers motto should be always leave things the way you found them). This can be done with SetBuf by passing a value of 0 as the size of the buffer. The Device Manager will then set the input buffer back to its default value.

Once the serial port has been opened and initialized and the size of the serial input buffer has been increased, your program is ready to send and receive data through the port.

The input routine GetSerial takes two parameters, the port number and a pointer to the buffer that will hold the incoming data (note that this isnt the same as the input driver buffer). GetSerial first checks to see if there are any characters waiting to be read by calling SerGetBuf, which is a special version of the Device Manager _Status trap. This Device Manager call returns a long word containing the number of characters in the drivers input buffer. If the input buffer is empty, GetSerial will leave this zero count on the stack and end. If there are characters available (and if you use TextEdit, there will be quite a few backed up), GetSerial reads them into the new buffer using the Device Manager _Read trap. GetSerial then leaves the character count on the stack and ends. Figure 4 shows the local stack for GetSerial. Heres an example from the terminal program:

PutSerial simply shoves data out the port, letting the Device Manager worry about errors (like overflowing the output buffer). Since we are calling PutSerial synchronously, this is not a serious shortcoming and PutSerial will work well, without problems.

PutSerial takes three parameters, the port number, a pointer to the buffer holding the data to be sent and the number of characters to be sent. Even though PutSerial ignores errors, it returns a no errors result value to the calling program; this is to keep it consistent with the other routines and to make room for a real error value if a future version of the routine does check for errors. The calling sequence is pretty simple:

These serial I/O routines are lacking in a few features (mainly better and more complete error checking) but since the interface to the calling program (be it a high level language or assembly) is consistent, these routines can be used as the basis for more complete routines, or used as-is, without any major changes to the calling program.

Using the Serial I/O Routines in the Real World: An Example

The easiest way to learn how to use the serial I/O routines is with an example. Term is an extremely simple terminal program; it sends characters typed at the keyboard out the modem port and uses TextEdit to display the incoming characters. Besides the standard File and Edit menus, Term has a Command menu with an Erase Screen item and four (300, 1200, 2400 and 9600) baud settings. It also uses the clipboard, so you can cut and paste text to and from its window. While the text that is pasted to the terminal window is displayed, it is not sent out the port (as my old calculus book would say the solution to this problem is left to the reader). The main window in Term is moveable, but not resizable. This is a minor annoyance, which can be easily fixed.

Term will run on almost any Macintosh (it doesnt run on Macs with the old 64K ROMs) and is structured to serve as the skeleton of a more complex communications program. To maximize speed and reduce the need for global variable storage, most assembly language programmers store frequently used handles and pointers in unused CPU registers. Since I dont know what you plan to do with Term, Ive tried to minimize the use of registers for handle storage. Most of the menu and window handles are kept as global variables.

Macintosh applications often share the same basic structure and even some of the initialization and event parsing routines. Term is no exception. It is a quilt of routines that have been borrowed from other applications. Term begins by initializing the modem port and going through the usual ritual of setting up things and initializing managers. It finishes the initialization by copying the contents of the clipboard to the TextEdit scrap. Term ends when a non-zero value is passed to the event loop, either when the user selects Quit from the menu or clicks in the program windows close box. Term then cleans up, resets the input buffer back to its default size and returns to the Finder.

Since Macintosh programs spend most of their time in the event loop, this is the best place for Term to check the modem port and display any new characters that may have been received. You may notice that the EventRecord is declared and used as a global variable. It used to be a common practice to declare the EventRecord as a constant; this saved a few keystrokes when typing in the program. The practice did not cause problems when the program was running because the 68000 doesnt make any distinctions between the memory used for variable storage and that used for constants and code. With the 68020, 68030 and future CPUs, memory management becomes part of the computer hardware. With an MMU, an operating system could set aside memory to be used as storage for a programs code and constants... and declare this memory to be read only. Imagine the surprise of a program trying to write to a write-protected EventRecord!

Term Routines

Instead of a detailed description of every routine in Term, Ill focus on the routines that make it different.

PutScreen filters the characters in the input buffer, IOBuf, and transfers the displayable characters to Outbuf, the output buffer. The variable CharCnt is used to tell TextEdit how many characters are in the output buffer.

A communications program must be able to display characters on the screen quickly, especially at the higher baud rates, when data may be flooding in through the serial port. On the Macintosh, the quickest way to get a character on the screen is to use QuickDraws DrawChar function, and this is what I used in the early versions of Term. Unfortunately, DrawChar does little else besides drawing a character on the screen. All text manipulations (simple things like backspace and carriage return) must be handled with a stupendous amount of code. I knew that TextEdit could handle some of these simple functions, and TextEdit had the extra bonus of making it easy to cut and paste the text to the clipboard and back. Unfortunately, TextEdit is extremely slow. My initial attempts to use TextEdit were a miserable failure; I was losing most of the incoming data. The solution, of course, was to increase the size of the serial input buffer.

While TextEdit is an improvement over DrawChar, it will only recognize a limited number of control characters, so PutScreen must deal with any control characters it finds in IOBuf. In this version of PutScreen, only the carriage return (CR), Bell, Tab and backspace (BS) characters are recognized; all other control characters are discarded. By replacing the simple compare and branch code with a lookup table, PutScreen could be made to emulate a real terminal, like the VT-52 or VT-100.

PutScreen lets TextEdit handle carriage returns. To backspace, PutScreen decrements the output buffer pointer by one (to erase the previous character) and decrements the character count by two (to account for the deleted character and the backspace character). If the character count is zero, then no characters have to be displayed, and PutScreen passes control to the NextEvent routine. If CharCnt is greater than zero, there are still characters to be processed, and PutScreen goes on to the next character in IOBuf. If the CharCnt is less than zero, we are no longer dealing with fresh characters and must delete a character that has already been displayed. To do this, PutScreen passes the BS character directly to the _TEKey trap, which deletes the last character displayed. It then passes control to the NextEvent loop.

If the control character is a Bell (control G) PutScreen will generate a short beep, decrement the character count, and continue with the filtering.

Tabs are hard coded for five spaces. PutScreen places five spaces in the output buffer and increments the character count by four (we dont want the tab character itself to be displayed) before continuing with the filtering.

Displayable characters are transferred from the IOBuf to the OutBuf, and the filtering continues until all the characters have been dealt with. PutScreen then uses _TEInsert to pass the OutBuf to TextEdit, which displays it. PutScreen also calls _TESelView, to scroll the window, if needed.

KeyDown takes characters typed at the keyboard and saves them in IOBuf. If the command key is pressed, it converts the character to a control character, and inserts it into the IOBuf. KeyDown then sends the character out the modem port.

InBaud is used to change the baud rate. This routine unchecks the previous menu item, checks the new one and sets the new baud rate, using the Config routine.

Possible Enhancements

Like most programs, Term has room for improvements. The easiest additions would be to make the window resizable and make the program MultiFinder friendly.

Term will operate at 19,200 baud; I was just too lazy to add it as a menu option. A menu option to change the default port might be useful, but dangerous. Since the printer port is used with networks and printers, the routine to switch ports must check to see if AppleTalk is active or if the printer port is being used by another program.

A slightly more difficult task would be to have Term send text pasted in its window, from the Clipboard, out the serial port. Another TextEdit related problem is a cosmetic one; I implemented a screen erase function in Term by clearing out the all the data in the TextEdit record. It works, but it makes the screen flash like an IBM PC screen...somewhat disconcerting.

A final improvement would be to add a file transferring capability, using the MacBinary extension to the XMODEM protocol. This wouldnt be as difficult as it sounds; both the MacBinary and XMODEM protocols are well described. It would be a good idea to increase the input serial buffer to at least 1280 bytes, room enough to fit a 1K XMODEM block. This would speed up the data rates by allowing the program to work on one block of data while another block is being received in the background.

Borrowed Routines

A few of the routines and techniques that I used in Term were borrowed from other programs.

The code to deal with the clipboard is a slightly modified version of the code in the Clipboard chapter in Dan Westons The Complete Book of Macintosh Assembly Language Programming, Volume II. Some of the ideas on how to handle TextEdit came from Dans The Complete Book of Macintosh Assembly Language Programming, Volume I. It should be pretty obvious that these are two very useful (if somewhat dated) books on Macintosh assembly language programming.

Victor Bargers Rose Curve Generator program is an excellent example of good code layout and presentation. Ive tried to make Term as easy to read.

PCalc is a full-featured, scriptable scientific calculator with support for hexadecimal, octal, and binary calculations, as well as an RPN mode, programmable functions, and an extensive set of unit... Read more

FileZilla 3.10.2 - Fast and reliable FTP...

FileZilla (ported from Windows) is a fast and reliable FTP client and server with lots of useful features and an intuitive interface.
Version 3.10.2:
Note: Now requires a 64-bit Intel processor.... Read more

The Hit List 1.1.11 - Advanced reminder...

The Hit List manages the daily chaos of your modern life. It's easy to learn - it's as easy as making lists. And it's powerful enough to let you plan, then forget, then act when the time is right.... Read more

Bartender 1.2.32 - Organize your menu ba...

Bartender lets you organize your menu bar apps.
Features:
Lets you tidy your menu bar apps how you want.
See your menu bar apps when you want.
Hide the apps you need to run, but do not need to... Read more

ClamXav 2.7.5 - Free virus checker, base...

ClamXav is a free virus checker for OS X. It uses the tried, tested, and very popular ClamAV open source antivirus engine as a back end.
I hope you like and use ClamXav a lot and that it helps keep... Read more

xScope 4.1.2 - Onscreen graphic measurem...

xScope is powerful set of tools that are ideal for measuring, inspecting, and testing on-screen graphics and layouts. Its tools float above your desktop windows and can be accessed via a toolbar,... Read more

MacFamilyTree 7.3.3 - Create and explore...

MacFamilyTree gives genealogy a facelift: it's modern, interactive, incredibly fast, and easy to use. We're convinced that generations of chroniclers would have loved to trade in their genealogy... Read more

Skype 7.5.0.738 - Voice-over-internet ph...

Skype allows you to talk to friends, family and co-workers across the Internet without the inconvenience of long distance telephone charges. Using peer-to-peer data transmission technology, Skype... Read more

PushPal 3.0 - Mirror Android notificatio...

PushPal is a client for Pushbullet, which automatically shows you all of your phone's notifications right on your computer. This means you can see who's calling or read text messages even if your... Read more

Gameloft has excitedly announced that Dungeon Hunter 5 is on its way! Once again, you will adventure across the land of Valenthia exploring dungeons and fighting monsters. The game will have a new asynchronous multiplayer mode called Strongholds... | Read more »

It Came From Canada: Jurojin: Immortal N...

At this point it’s pretty safe to say that no MOBA is going to dethrone Dota 2 and League of Legends anytime soon. After all, if Batman can’t do it, nobody can. However, with a genre as popular and profitable as this one, there’s still room for... | Read more »

Final February Fun at 148Apps
How do you know what apps are worth your time and money? Just look to the review team at 148Apps. We sort through the chaos and find the apps you’re looking for. The ones we love become Editor’s Choice, standing out... | Read more »

GDC 2015 – Does Not Commute is Definitel...

GDC 2015 – Does Not Commute is Definitely a Game You Should Keep an Eye on
Posted by Rob Rich on March 2nd, 2015 [ permalink ]
We were teased about Mediocre Games’ (Smash Hit,
| Read more »

F84 Games & POW! Announce Stan Lee V...

F84 Games has announced that it is working with legendary comic creator Stan Lee and POW! Entertainment to produce Stan Lee’s Hero Command. The game will be a action adventure of heroic proportions.
| Read more »

Setlyst Keeps Your Set Straight So You C...

Setlyst Keeps Your Set Straight So You Can Focus On Rocking Out.
Posted by Jessica Fisher on March 2nd, 2015 [ permalink ]
Universal App - Designed for iPhone and iPad
| Read more »

Space is Vast, So Space Agency Has a Vas...

Space is Vast, So Space Agency Has a Vast New Update!
Posted by Jessica Fisher on March 2nd, 2015 [ permalink ]
Universal App - Designed for iPhone and iPad
| Read more »

Size DOES Matter Review

Size DOES Matter Review
By Campbell Bird on March 2nd, 2015
Our Rating: :: HARD TO BEATUniversal App - Designed for iPhone and iPad
This rhythm game has a unique control scheme and performance system that make it feel like a true... | Read more »

The first ever action 3D card battler Al...

On the other hand, you probably haven’t played an action 3D card battler – until now. Step forward, All Star Legion.
All Star Legion is a 3D QTE-based action RPG card battler, but fear not – the game itself isn’t as convoluted as its description.... | Read more »

Price Scanner via MacPrices.net

Another Tranche Of IBM MobileFirst For iOS Ap...

IBM has announced the next expansion phase for its IBM MobileFirst for iOS portfolio, with a troika of new apps to address key priorities for the Banking and Financial Services, Airline and Retail... Read more

Sale! 15-inch Retina MacBook Pros for up to $...

B&H Photo has the new 2014 15″ Retina MacBook Pros on sale for up to $250 off MSRP for a limited time. Shipping is free, and B&H charges NY sales tax only:
- 15″ 2.2GHz Retina MacBook Pro: $... Read more

WaterField Designs Introduces the Minimalist...

With Apple Pay gaining popularity, Android Pay coming in May 2015, and loyalty cards and receipts that can be accessed from smartphones, San Francisco’s WaterField Designs observes that it may be... Read more

Sale! 15-inch 2.2GHz Retina MacBook Pro for $...

Best Buy has the 15″ 2.2GHz Retina MacBook Pro on sale for $1774.99 $1799.99, or $225 off MSRP. Choose free home shipping or free local store pickup (if available). Price valid for online orders... Read more

13-inch 2.5GHz MacBook Pro (refurbished) avai...

The Apple Store has Apple Certified Refurbished 13″ 2.5GHz MacBook Pros available for $170 off the cost of new models. Apple’s one-year warranty is standard, and shipping is free:
- 13″ 2.5GHz... Read more

13-inch 2.5GHz MacBook Pro on sale for $100 o...

B&H Photo has the 13″ 2.5GHz MacBook Pro on sale for $999.99 including free shipping plus NY sales tax only. Their price is $100 off MSRP.
Read more

27-inch 3.5GHz 5K iMac in stock today and on...

B&H Photo has the 27″ 3.5GHz 5K iMac in stock today and on sale for $2299 including free shipping plus NY sales tax only. Their price is $200 off MSRP, and it’s the lowest price available for... Read more

Apple Launches Free Web-Based Pages and Other...

Apple’s new Web-only access to iWork productivity apps is a free level of iCloud service available to anyone, including people who don’t own or use Apple devices. The service includes access to Apple... Read more

Survey Reveals Solid State Disk (SSD) Technol...

In a recent SSD technology use survey, Kroll Ontrack, a firm specializing in data recovery, found that while nearly 90 percent of respondents leverage the performance and reliability benefits of SSD... Read more

Save up to $600 with Apple refurbished Mac Pr...

The Apple Store is offering Apple Certified Refurbished Mac Pros for up to $600 off the cost of new models. An Apple one-year warranty is included with each Mac Pro, and shipping is free. The... Read more

Jobs Board

*Apple* Solutions Consultant - Retail Sales...

**Job Summary** As an Apple Solutions Consultant (ASC) you are the link between our customers and our products. Your role is to drive the Apple business in a retail
Read more

*Apple* Pay Automation Engineer - iOS System...

**Job Summary** At Apple , great ideas have a way of becoming great products, services, and customer experiences very quickly. Bring passion and dedication to your job
Read more

Sr. Technical Services Consultant, *Apple*...

**Job Summary** Apple Professional Services (APS) has an opening for a senior technical position that contributes to Apple 's efforts for strategic and transactional
Read more

Event Director, *Apple* Retail Marketing -...

…This senior level position is responsible for leading and imagining the Apple Retail Team's global engagement strategy and team. Delivering an overarching brand
Read more

*Apple* Pay - Site Reliability Engineer - Ap...

**Job Summary** Imagine what you could do here. At Apple , great ideas have a way of becoming great products, services, and customer experiences very quickly. Bring
Read more

MacTech is a registered trademark of Xplain Corporation. Xplain, "The journal of Apple technology", Apple Expo, Explain It, MacDev, MacDev-1, THINK Reference, NetProfessional, Apple Expo, MacTech Central, MacTech Domains, MacNews, MacForge, and the MacTutorMan are trademarks or service marks of Xplain Corporation. Sprocket is a registered trademark of eSprocket Corporation. Other trademarks and copyrights appearing in this printing or software remain the property of their respective holders. Not responsible for typographical errors.

All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.