USB/serial converters with dosbox. Which matched the settings on the com port from the old Mac and the settings in the timeclock software. I assumed since I set. Change DOSBox serial port settings: You also need to set up the serial ports if you want to communicate with the Organiser. Near the end of the settings file is a section marked serial. There it describes the various settings that are possible, but the one that I use is as follows.

• Dosbox Serial Port Settings In Windows Xp
• Dosbox Serial Port Settings
• Dosbox Com Port Configuration
• Dosbox Serial Port Configuration
• Serial Port Cable
• Dosbox Serial Port Settings On Linux

1. It may take some pushing around to find this information, but if you have a conventional serial data port on your computer, it will be there. If you are using a serial data port that is connected via USB (common on more recent computers), you are simply not going to be (easily) able to do direct serial data communications in DOS.
2. How to setup DOSBox using RS-232 serial port. DOSBox USB to Serial RS232 on Linux 10 January, 2017. To setup a USB to serial converter to use with DOSBox on Linux. Note device ID for USB to serial adapter.
3. DOSBox is capable of timing-compatible implementation of the serial ports, which can enable older hardware and software dependent on serial port timing to work; however, some USB devices that are supported by the host OS can act as a replacement for older serial port devices when using the emulator. OS emulation.
4. Download VirtualBox, it's free. Set up a virtual machine for DOS, with the appropriate amount of RAM and so on, it's pretty straightforward to go through the wizard. Once the VM is created, click Settings and then go to Serial Ports and enable it, select 'Host Device' mode, and type in the COM1 (or whatever real COM port you want to pass through).

DOSBox is an emulatorprogram which emulates an IBM PC compatible computer running a DOS operating system. Many IBM PC compatible graphics and sound cards are also emulated. This means that original DOS programs (including PC games) are provided with an environment in which they can run correctly, even though the modern computers have dropped support for that old environment.

• 2Features
• 3Ports
• 4Usage

History[edit]

DOSBox is free software written primarily in C++ and distributed under the GNU General Public License. DOSBox has been downloaded over 34 million times since its release on SourceForge in 2002.^[8]

A number of usability enhancements have been added to DOSBox beyond emulating DOS. The added features include virtual hard drives, peer-to-peer networking, screen capture and screencasting from the emulated screen.

More than 9 years have passed between 2010's 0.74 and the 2019's latest version 0.74-3, 'a security release' made in absence of version 0.75, which 'should have been released by now, but some bugs took a lot longer than expected'.^[9] But throughout these years development has been ongoing in the SVN version.^[vague] Forks such as DOSBox SVN Daum and DOSBox SVN-lfn provide additional features, which include support for save states and long filenames (LFN), while others such as DosBox-X add emulation for Japanese systems like the NEC PC-98 and increase compatibility with various Demoscene productions.^[10]

A number of vintage DOS games have been commercially re-released to run on modern operating systems by encapsulating them inside DOSBox.^{[citation needed]}

Features[edit]

DOSBox is a command-line program, configured either by a set of command-line arguments or by editing a plain text configuration file. For ease of use, several graphical front-ends have been developed by the user community.^[11]

A popular feature of DOSBox is its ability to capture screenshots and record gameplay footage. The video is compressed using the losslessZip Motion Block Video codec.^[12] In its uncompressed state the footage is almost an exact replica of the actual program. The video recording feature was added in version 0.65. In earlier versions, one had to rely on custom modifications and a third-party screen recorder to record video, but the quality and emulator performance was generally very poor.^[13]

The DOSBox project has a policy of not adding features that aren't used by DOS games if they take significant effort to implement, are likely to be a source of bugs or portability problems, and/or impact performance. Perhaps the most common hardware feature of DOS-era PCs that the official version of DOSBox doesn't emulate is the parallel port that was used to connect printers. As an alternative, the PrintScreen function of modern OSs can be used to capture the output of DOSBox. For similar reasons, no support for long filenames and Ctrl-Break is added into official versions, though support for them is available in some unofficial enhanced SVN builds.

Hardware emulation[edit]

DOSBox is a full CPU emulator, capable of running DOS programs that require the CPU to be in real mode or protected mode.^[14] Other similar programs, such as DOSEMU or VDMs for Windows and OS/2, provide compatibility layers and rely on virtualization capabilities of the 386 family processors. Since DOSBox can emulate its CPU by interpretation, the environment it emulates is completely independent of the host CPU.^[14] On systems which provide the i386instruction set, however, DOSBox can use dynamic instruction translation to accelerate execution several times faster than interpretive CPU emulation.^{[citation needed]} The emulated CPU speed of DOSBox is also manually adjustable by the user to accommodate the speed of the systems for which DOS programs were originally written.^[15]

DOSBox can emulate a wide range of graphics and sound hardware. Graphics emulation includes text mode, Hercules, CGA (including some composite modes and the 160x100x16 tweaked modes), Tandy, EGA, VGA (including Mode X and other tweaks), VESA, and full S3 Trio 64 emulation.^[14] Sound hardware that can be emulated includes the PC speaker (played back through the host's standard sound output, not its physical internal PC speaker), AdLib, Gravis Ultrasound, Tandy, Creative Music System/GameBlaster, Sound Blaster 1.x/2.0/Pro/16, and Disney Sound Source. MIDI output through an emulated MPU-401 interface is available if the host is equipped with a physical MIDI-Out connector or a suitable software MIDI synthesizer. (MT-32/CM-32L emulation is included in unofficial enhanced builds,^[10] but not in the official source code repository due to need for copyrighted ROM images.) Storage is handled by mapping (either through the configuration file or through a command within the emulator) a drive letter in the emulator to a directory, image file, floppy disk drive, or CDROM drive on the host. A permanently mapped Z: drive stores DOSBox commands and startup scripts.

Emulation of Voodoo cards is in development as of October 2010.^{[16][needs update]} This should give not only support for games that use the Glide API, but also provide Direct3D support to Win9x guests.

DOSBox, unlike many other emulators, can simulate peer-to-peer or Internet/Intranet networking. This includes modem simulation over TCP/IP, allowing for DOS modem games to be played over modern LANs or the Internet, and IPX network tunneling, which allows for old IPX DOS multiplayer games to be played as UDP/IP over modern LANs or the Internet. Win32 and Linux specific builds support direct serial port access. Some third-party patches also allow DOSBox to emulate an NE2000-class network interface card as a passthrough to the host computer's own network card, essentially allowing full internet connectivity (for example, using Windows 3.1 and Trumpet Winsock) and web browsing using programs such as Netscape Navigator, although this is more of a curiosity than a useful feature.

DOSBox is capable of timing-compatible implementation of the serial ports, which can enable older hardware and software dependent on serial port timing to work; however, some USB devices that are supported by the host OS can act as a replacement for older serial port devices when using the emulator.

OS emulation[edit]

DOSBox provides a high level emulation of the DOS and BIOS interrupts, and contains its own internal DOS-like shell. This means that it can be used without owning a license to any real DOS operating system. Most commands that are typically used in installer batch files are supported, but many of the more advanced commands of later DOS versions (e.g. post-Windows 98 DOS shells) are not. In addition to its internal shell, it also supports running image files of games and software originally intended to start without any operating system. The DOS emulation enables DOSBox to mount folders of the host OS as virtual drives.

It can also boot disk images with real DOS environments (e.g. MS-DOS, PC DOS, DR-DOS or FreeDOS) as well as other operating systems. Since DOSBox is not optimized for this mode of operation, booting any real OS inside DOSBox entails the loss of the use of directory-based virtual hard drives and some other enhancements that aren't directly compatible with the way real operating systems access hardware. For the kinds of hardware (such as disk drive controllers and computer mice) that are almost always accessed by DOS-based games through DOS and/or through the BIOS and/or through a software driver, rather than through direct access to hardware registers, DOSBox generally provides no hardware-level emulation. This means that the direct use of copy-protected physical media or of floppy disks in non-standard formats is generally not possible from DOSBox.

Commands[edit]

The following list of commands is supported by DOSBox.^[17]

• BOOT
• CONFIG
• IMGMOUNT
• MIXER
• RESCAN

DOSBox has no MOVE command. The REN command can be used to move files.^[18]

Ports[edit]

DOSBox uses the SDL library and has been ported to many operating systems. A port for Microsoft Xbox (called DosXbox) was released in 2004. Using the HX DOS Extender, it can even run in DOS.^[19] The source code has also been forked to provide compatibility on a number of non-x86 PC computer platforms, including the Palm OS, PlayStation Portable, Android, iOS,^[20]Symbian, Maemo, BlackBerry PlayBook, Wii(Require Homebrew Channel with Homebrew Browser installed), and the GP2X, on various computing architectures including PowerPC, SPARC, MIPS and ARM. DOSBox is included in the software repositories of many Linux distributions such as Fedora, Debian, and Ubuntu. There is also a port to Google Native Client called NaClBox,^[21][22] a port to Java applets called jDosbox,^[23] and a port of jDosBox to GWT (using the Canvas element) called jsDOSBox.^[24]

There is a port of DOSBox that can run in a modern browser called Em-DOSBox. It uses Emscripten to compile its C/C++ source code to JavaScript or WebAssembly, and Emscripten's port of SDL 2 so graphics, input, and sound work in a browser.

DOSBox and the Wine compatibility layer[edit]

Starting with version 1.3.12, the developers of the Winecompatibility layer have begun the process of integrating DOSBox into Wine to facilitate running DOS programs that are not supported natively by the Wine Virtual DOS machine (winevdm).^[25]

Adobe photoshop cs6 full version buy 1. After Extracting run Setup. After downloading you got Zip file open it and Extract it as shown in Figure. Don’t worry about it you will find the link below.

Usage[edit]

Commercial deployment[edit]

id Software has used DOSBox to re-release vintage games such as Wolfenstein 3D and Commander Keen on Valve's Steam. In the process, it was reported they violated the program's license, the GNU GPL; the breach, which was reported as an oversight, was promptly resolved.^[26][27]Activision Blizzard has also used it to re-release Sierra Entertainment's DOS games. LucasArts used it to re-release Star Wars: Dark Forces for modern machines on Steam. 2K Games producer Jason Bergman stated the company used DOSBox for Steam re-releases of certain parts of the X-Com series.^[28]GOG.com uses DOSBox for some of their DOS releases.^[29]Bethesda Softworks recommends DOSBox and provides a link to the DOSBox website on the downloads page for The Elder Scrolls: Arena and The Elder Scrolls II: Daggerfall.^[30][31] Bethesda also included DOSBox with both games in The Elder Scrolls Anthology release. 3D Realms also recommends DOSBox and, like Bethesda Softworks, provides a link to the DOSBox website on their downloads page.^[32]

Electronic Arts uses DOSBox for some of their classic games on their Origin client like Wing Commander III, Crusader: No Remorse, and SimCity 2000.

dBase LLC utilizes DOSBox in their dbDOS product since 2012.

Non-commercial notable uses[edit]

Since 23 December 2014, the Internet Archive hosts thousands of PC games that can be played in a browser, using the Em-DOSBox port.^[33][34][35] The collection is provided for 'scholarship and research purposes only'.^[36]

See also[edit]

Similar software

• Rpix86 - A DOS emulator for the Raspberry Pi.
• vDOS ^[37] - A DOS emulator designed for the running the more 'serious' DOS apps (not games) on 64-bit NT systems (effectively a replacement for NTVDM on modern systems).

Misc.

References[edit]

1. ^'Project of the Month, May 2009'. SourceForge. Archived from the original on November 17, 2009. Retrieved January 17, 2013.
2. ^'Project of the Month, January 2013'. SourceForge. Retrieved January 17, 2013.^{[permanent dead link]}
3. ^https://sourceforge.net/projects/dosbox/files/dosbox/0.74-3/ SourceForge Binaries Available (Release Version)
4. ^'SVN changelog (DOSBox Home web)'.
5. ^'DOSBox Wiki - SVN Builds Info'. Dosbox.com.
6. ^'EmuCR Compiled Binaries - DOSBox official & unofficial builds'.
7. ^'p/dosbox/code-0 - Revision 4006: /dosbox/trunk'. Sourceforge. Retrieved February 9, 2017.
8. ^'Download Statistics'. Retrieved August 8, 2017.
9. ^'DOSBox 0.74-3 has been released!'. 'DOSBox'. June 26, 2019. Retrieved July 3, 2019.
10. ^ ^ab'SVN Builds'. DOSBox. December 1, 2012. Retrieved January 8, 2012.
11. ^'DOSBox Frontends'. DOSBox. December 15, 2008. Retrieved January 3, 2009.
12. ^'DosBox Capture Codec'. March 9, 2008. Retrieved January 3, 2009.
13. ^bakkelun (March 7, 2008). 'Recording video from DosBox'. Archived from the original on December 11, 2008. Retrieved January 3, 2009.
14. ^ ^abcQbix (April 30, 2008). 'Interview with Qbix' (Interview). Interviewed by Classic Dos Games. Retrieved January 3, 2009.
15. ^Hoffman, Chris (October 5, 2015). 'How To Use DOSBox To Run DOS Games and Old Apps'. How-To Geek. Retrieved February 9, 2017.
16. ^http://kingofgng.com/eng/2010/10/20/3dfx-voodoo-graphic-cards-emulation-coming-to-dosbox/
17. ^https://www.dosbox.com/DOSBoxManual.html
18. ^Commands - DOSBoxWiki
19. ^japheth (July 25, 2013). 'HX DOS Extender'. Archived from the original on October 13, 2014. Retrieved December 30, 2013.
20. ^FAST Intelligence. 'DOSpad, DOSBox for iOS'. Retrieved February 5, 2013.
21. ^NaClBox. 'NaClBox homepage'. Retrieved February 5, 2013.
22. ^Endagdet (May 12, 2011). 'NaClBox brings DOS-based gaming to Chrome along with sweet, sweet nostalgia'. Retrieved February 5, 2013.
23. ^danoon2 and co. 'jDosBox homepage'.
24. ^Kevin O'Dwyer. 'jsDOSBox homepage'.
25. ^'Wine 1.3.12 Brings Initial DOSBox Integration'. January 21, 2011. Retrieved August 26, 2011.
26. ^'Are id Software and Valve Thieves?'. Softpedia. August 6, 2007. Retrieved January 3, 2009.
27. ^Purchese, Rob (August 7, 2007). 'id sorts GPL Steam issue'. Eurogamer. Retrieved January 3, 2009.
28. ^Bergman, Jason (September 4, 2008). 'Comments-morning discussion'. Shacknews. Retrieved January 3, 2009.
29. ^'Our Thanks'. GOG.com. Retrieved January 3, 2009.
30. ^'The Elder Scrolls Official Site - The Elder Scrolls: Arena'. Bethesda Softworks. Retrieved March 3, 2011.
31. ^'The Elder Scrolls Official Site - The Elder Scrolls: Daggerfall'. Bethesda Softworks. Retrieved March 3, 2011.
32. ^'3D Realms Site: Master Download Page'. 3D Realms. Retrieved November 5, 2009.
33. ^Ohlheiser, Abby (January 5, 2015). 'You can now play nearly 2,400 MS-DOS video games in your browser'. Washington Post. Retrieved January 8, 2015.
34. ^Each New Boot a Miracle by Jason Scott (December 23, 2014)
35. ^collection:softwarelibrary_msdos in the Internet Archive (2014-12-29)
36. ^'Internet Archive's Terms of Use, Privacy Policy, and Copyright Policy'. archive.org. December 31, 2014. Retrieved January 8, 2015. Access to the Archive’s Collections is provided at no cost to you and is granted for scholarship and research purposes only.
37. ^'vDos'.

External links[edit]

• 'Official DOSBox forum'. Very Old Games On New Systems (VOGONS).
• 'Interview with Qbix (a developer of DOSBox)'. Classic DOS Games. April 30, 2008.
• 'DOSBox 0.73, interview with the developers'. King of Ghouls and Ghosts (GNG). June 10, 2009.
• 'DOSBox SVN variants that do support printing'. Unofficial variants downloader.

Serial Programming: Introduction and OSI Network Model-- RS-232 Wiring and Connections-- Typical RS232 Hardware Configuration-- 8250 UART-- DOS-- MAX232 Driver/Receiver Family-- TAPI Communications In Windows-- Linux and Unix-- Java-- Hayes-compatible Modems and AT Commands-- Universal Serial Bus (USB)-- Forming Data Packets-- Error Correction Methods-- Two Way Communication-- Packet Recovery Methods-- Serial Data Networks-- Practical Application Development-- IP Over Serial Connections

• 3Finding the Port I/O Address for the UART
• 5Basic Serial Input
  • 5.1Polling the UART
• 6Interrupt Drivers in DOS
• 7Terminal Program Revisited

Introduction[edit]

It is now time to build on everything that has been established so far. While it is unlikely that you are going to be using MS-DOS for a major application, it is a good operating system to demonstrate a number of ideas related to software access of the 8250 UART and driver development. Compared to modern operating systems like Linux, OS-X, or Windows, MS-DOS can hardly be called an operating system at all. All it really offers is basic access to the hard drive and a few minor utilities. That really doesn't matter so much for what we are dealing with here, and it is a good chance to see how we can directly manipulate the UART to get the full functionality of all aspects of the computer. The tools I'm using are all available for free (as in beer) and can be used in emulator software (like VMware or Bochs) to try these ideas out as well. Emulation of serial devices is generally a weak point for these programs, so it may work easier if you work from a floppy boot of DOS, or on an older computer that is otherwise destined for the trash can because it is obsolete.

For Pascal, you can look here:

• Turbo Pascal [1] version 5.5 - This is the software I'm actually using for these examples, and the compiler that most older documentation on the web will also support (generally).

• Free Pascal [2] - *note* this is a 32-bit version, although there is a port for DOS development. Unlike Turbo Pascal, it also has ongoing development and is more valuable for serious projects running in DOS.

For MS-DOS substitution (if you don't happen to have MS-DOS 6.22 somewhere):

• FreeDOS [3] Project - Now that Microsoft has abandoned development of DOS, this is pretty much the only OS left that is pure command line driven and following the DOS architecture.

Hello World, Serial Data Version[edit]

In the introduction, I mentioned that it was very difficult to write computer software that implements RS-232 serial communications. A very short program shows that at least a basic program really isn't that hard at all. In fact, just three more lines than a typical 'Hello World' program.

All of this works because in DOS (and all version of Windows as well.. on this particular point) has a 'reserved' file name called COM1 that is the operating system hooks into the serial communications ports. While this seems simple, it is deceptively simple. You still don't have access to being able to control the baud rate or any of the other settings for the modem. That is a fairly simple thing to add, however, using the knowledge of the UART discussed in the previous chapter Programming the 8250 UART.

To try something even easier, you don't even need a compiler at all. This takes advantage of the reserved 'device names' in DOS and can be done from the command prompt.

What you are doing here is taking input from CON (the console or the standard keyboard you use on your computer) and it 'copies' the data to COM1. You can also use variations of this to do some interesting file transfers, but it has some important limitations. Most importantly, you don't have access to the UART settings, and this simply uses whatever the default settings of the UART might be, or what you used last time you changed the settings to become with a serial terminal program.

Finding the Port I/O Address for the UART[edit]

The next big task that we have to work with is trying to find the base 'address' of the Port I/O so that we can communicate with the UART chip directly (see the part about interface logic in the Typical RS232-Hardware Configuration module for information what this is about). For a 'typical' PC system, the following are usually the addresses that you need to work with:

Looking up UART Base Address in RAM[edit]

We will get back to the issue of the IRQ Number in a little bit, but for now we need to know where to start accessing information about each UART. As demonstrated previously, DOS also keeps track of where the UART IO ports are located at for its own purpose, so you can try to 'look up' within the memory tables that DOS uses to try and find the correct address as well. This doesn't always work, because we are going outside of the normal DOS API structure. Alternative operating systems ( FreeDOS works fine here ) that are otherwise compatible with MS-DOS may not work in this manner, so take note that this may simply give you a wrong result altogether.

The addresses for the serial I/O Ports can be found at the following locations in RAM:

Those addresses are written to memory by the BIOS when it boots. If one of the ports doesn't exist, the BIOS writes zero to the respective address. Note that the addresses are given in segment:offset format and that you have to multiply the address of the segment with 16 and add the offset to get to the physical address in memory. This is where DOS 'finds' the port addresses so you can run the first sample program in this chapter.

In assembler you can get the addresses like this:

In Turbo Pascal, you can get at these addresses almost the same way and in some ways even easier because it is a 'high level language'. All you have to do is add the following line to access the COM Port location as a simple array:

The reserved, non standard, word absolute is a flag to the compiler that instead of 'allocating' memory, that you already have a place in mind to have the computer look instead. This is something that should seldom be done by a programmer unless you are accessing things like these I/O port addresses that are always stored in this memory location.

For a complete program that simply prints out a table of the I/O port addresses for all four standard COM ports, you can use this simple program:

Searching BIOS Setup[edit]

Assuming that the standard I/O addresses don't seem to be working for your computer and you haven't been able to find the correct I/O Port offset addresses through searching RAM either, all hope is still not lost. Assuming that you have not accidentally changed these settings earlier, you can also try to look up these numbers in the BIOS setup page for your computer. It may take some pushing around to find this information, but if you have a conventional serial data port on your computer, it will be there.

If you are using a serial data port that is connected via USB (common on more recent computers), you are simply not going to be (easily) able to do direct serial data communications in DOS. Instead, you need to use more advanced operating systems like Windows or Linux that is beyond the scope of this chapter. We will cover how to access the serial communications routines in those operating systems in subsequent chapters. The basic principles we are discussing here would still be useful to review because it goes into the basic UART structure.

While it may be useful to try and make IRQs selectable and not presume that the information listed above is correct in all situations, it is important to note that most PC-compatible computer equipment usually has these IRQs and I/O port addresses used in this way because of legacy support. And surprisingly as computers get more sophisticated with even more advanced equipment like USB devices, these legacy connections still work for most equipment.

Making modifications to UART Registers[edit]

Now that we know where to look in memory to modify the UART registers, let's put that knowledge to work. We are also now going to do some practical application of the tables listed earlier in the chapter 8250 UART Programming.

To start with, let's redo the previous 'Hello World' application, but this time we are going to set the RS-232 transmission parameters to 1200 baud, 7 databits, even parity, and 2 stop bits. I'm choosing this setting parameter because it is not standard for most modem applications, as a demonstration. If you can change these settings, then other transmission settings are going to be trivial.

First, we need to set up some software constants to keep track of locations in memory. This is mainly to keep things clear to somebody trying to make changes to our software in the future, not because the compiler needs it.

Next, we need to set the DLAB to a logical '1' so we can set the baud rate:

In this case, we are ignoring the rest of the settings for the Line Control Register (LCR) because we will be setting them up in a little bit. Remember this is just a 'quick and dirty' way to get this done for now. A more 'formal' way to set up things like baud rate will be demonstrated later on with this module.

Following this, we need to put in the baud rate for the modem. Looking up 1200 baud on the Divisor Latch Bytes table gives us the following values:

Now we need to set the values for the LCR based on our desired setting of 7-2-E for the communication settings. We also need to 'clear' the DLAB which we can also do at the same time.

Are things clear so far? What we have just done is some bit-wise arithmetic, and I'm trying to keep things very simple here and to try and explain each step in detail. Let's just put the whole thing together as the quick and dirty 'Hello World', but with adjustment of the transmission settings as well:

This is getting a little more complicated, but not too much. Still, all we have done so far is just write data out to the serial port. Reading data from the serial data port is going to be a little bit trickier.

Basic Serial Input[edit]

In theory, you could use a standard I/O library and simply read data from the COM port like you would be reading from a file on your hard drive. Something like this:

There are some problems with doing that with most software, however. One thing to keep in mind is that using a standard input routine will stop your software until the input is finished ending with a 'Enter' character (ASCII code 13 or in hex $0D).

Usually what you want to do with a program that receives serial data is to allow the user to do other things while the software is waiting for the data input. In a multitasking operating system, this would simply be put on another 'thread', but with this being DOS, we don't (usually) have threading capabilities, nor is it necessary. There are some other alternatives that we do in order to get the serial data brought into your software.

Polling the UART[edit]

Perhaps the easiest to go, besides simply letting the standard I/O routines grab the input) is to do software polling of the UART. One of the reasons why this works is because serial communications is generally so slow compared to the CPU speed that you can perform many tasks in between each character being transmitted to your computer. Also, we are trying to do practical applications using the UART chip, so this is a good way to demonstrate some of the capabilities of the chip beyond simple output of data.

Serial Echo Program[edit]

Looking at the Line Status Register (LSR), there is a bit called Data Ready that indicates there is some data available to your software in the UART. We are going to take advantage of that bit, and start to do data access directly from the UART instead of relying on the standard I/O library. This program we are going to demonstrate here is going to be called Echo because all it does is take whatever data is sent to the computer through the serial data port and display it on your screen. We are also going to be configuring the RS-232 settings to a more normal 9600 baud, 8 data bits, 1 stop bit, and no parity. To quit the program, all you have to do is press any key on your keyboard.

Simple Terminal[edit]

This program really isn't that complicated. In fact, a very simple 'terminal' program can be adapted from this to allow both sending and receiving characters. In this case, the Escape key will be used to quit the program, which will in fact be where most of the changes to the program will happen. We are also introducing for the first time direct output into the UART instead of going through the standard I/O libraries with this line:

The Transmit Holding Register (THR) is how data you want to transmit gets into the UART in the first place. DOS just took care of the details earlier, so now we don't need to open a 'file' in order to send data. We are going to assume, to keep things very simple, that you can't type at 9600 baud, or roughly 11,000 words per minute. Only if you are dealing with very slow baud rates like 110 baud is that going to be an issue anyway (still at over 130 words per minute of typing.. a very fast typist indeed).

Interrupt Drivers in DOS[edit]

The software polling method may be adequate for most simple tasks, and if you want to test some serial data concepts without writing a lot of software, it may be sufficient. Quite a bit can be done with just that method of data input.

When you are writing a more complete piece of software, however, it becomes important to worry about the efficiency of your software. While the computer is 'polling' the UART to see if a character has been sent through the serial communications port, it spends quite a few CPU cycles doing absolutely nothing at all. It also get very difficult to expand a program like the one demonstrated above to become a small section of a very large program. If you want to get that last little bit of CPU performance out of your software, we need to turn to interrupt drivers and how you can write them.

I'll openly admit that this is a tough leap in complexity from a simple polling application listed above, but it is an important programming topic in general. We are also going to expose a little bit about the low-level behavior of the 8086 chip family, which is knowledge you can use in newer operating systems as well, at least for background information.

Going back to earlier discussions about the 8259 Programmable Interrupt Controller (PIC) chip, external devices like the UART can 'signal' the 8086 that an important task needs to occur that interrupts the flow of the software currently running on the computer. Not all computers do this, however, and sometimes the software polling of devices is the only way to get data input from other devices. The real advantage of interrupt events is that you can process data acquisition from devices like the UART very quickly, and CPU time spent trying to test if there is data available can instead be used for other tasks. It is also useful when designing operating systems that are event driven.

Interrupt Requests (IRQs) are labeled with the names IRQ0 to IRQ15. UART chips typically use either IRQ 3 or IRQ 4. When the PIC signals to the CPU that an interrupt has occurred, the CPU automatically start to run a very small subroutine that has been previously setup in the Interrupt Table in RAM. The exact routine that is started depends on which IRQ has been triggered. What we are going to demonstrate here is the ability to write our own software that 'takes over' from the operating system what should occur when the interrupt occurs. In effect, writing our own 'operating system' instead, at least for those parts we are rewriting.

Indeed, this is exactly what operating system authors do when they try to make a new OS.. deal with the interrupts and write the subroutines necessary to control the devices connected to the computer.

The following is a very simple program that captures the keyboard interrupt and produces a 'clicking' sound in the speaker as you type each key. One interesting thing about this whole section, while it is moving slightly off topic, this is communicating with a serial device. The keyboard on a typical PC transmits the information about each key that you press through a RS-232 serial protocol that operates usually between 300 and 1200 baud and has its own custom UART chip. Normally this isn't something you are going to address, and seldom are you going to have another kind of device connected to the keyboard port, but it is interesting that you can 'hack' into the functions of your keyboard by understanding serial data programming.

There are a number of things that this program does, and we need to explore the realm of 16-bit DOS software as well. The 8086 chip designers had to make quite a few compromises in order to work with the computer technology that was available at the time it was designed. Computer memory was quite expensive compared to the overall cost of the computer. Most of the early microcomputers that the IBM-PC was competing against only had 64K or 128K of main CPU RAM anyway, so huge programs were not considered important. In fact, the original IBM-PC was designed to operate on only 128K of RAM although it did become standard with generally up to 640K of main RAM, especially by the time the IBM PC-XT was released and the market for PC 'clones' turned out what is generally considered the 'standard PC' computer today.

The design came up with what is called segmented memory, where the CPU address is made up of a memory 'segment' pointer and a 64K block of memory. That is why some early software on these computers could only run in 64K of memory, and created nightmares for compiler authors on the 8086. Pentium computers don't generally have this issue, as the memory model in 'protected mode' doesn't use this segmented design methodology.

Far Procedure Calls[edit]

This program has two 'compiler switches' that inform the compiler of the need to use what are called far procedure calls. Normally for small programs and simple subroutines, you are able to use what is called relative indexing with the software so the CPU 'jumps' to the portion of RAM with the procedure by doing a bit of simple math and 'adding' a number to the current CPU address in order to find the correct instructions. This is done especially because it uses quite a bit less memory to store all of these instructions.

Sometimes, however, a procedure must be accessed from somewhere in RAM that is quite different from the current CPU memory address 'instruction pointer'. Interrupt procedures are one of these, because it doesn't even have to be the same program that is stored in the interrupt vector table. That brings up the next part to discuss:

Interrupt Procedures[edit]

The word 'interrupt' after this procedure name is a key item here. This tells the compiler that it must do something a little bit different when organizing this function than how a normal function call behaves. Typically for most software on the computer, you have a bunch of simple instructions that are then followed by (in assembler) an instruction called:

This is the mnemonic assembly instruction for return from procedure call. Interrupts are handled a little bit differently and should normally end with a different CPU instruction that in assembly is called:

or Interrupt return for short. One of the things that should also happen with any interrupt service routine is to 'preserve' the CPU information before doing anything else. Each 'command' that you write in your software will modify the internal registers of the CPU. Keep in mind that an interrupt can occur right in the middle of doing some calculations for another program, like rendering a graphic image or making payroll calculations. We need to hand onto that information and 'restore' those values on all of the CPU registers at the end of our subroutine. This is usually done by 'pushing' all of the register values onto the CPU stack, performing the ISR, and then restoring the CPU registers afterward.

In this case, Turbo Pascal (and other well-written compilers having a compiler flag like this) takes care of these low-level details for you with this simple flag. If the compiler you are using doesn't have this feature, you will have to add these features 'by hand' and explicitly put them into your software. That doesn't mean the compiler will do everything for you to make an interrupt procedure. There are more steps to getting this to work still.

Procedure Variables[edit]

These instructions are using what is called a procedure variable. Keep in mind that all software is located in the same memory as variables and other information your software is using. Essentially, a variable procedure where you don't need to worry about what it does until the software is running, and you can change this variable while your program is running. This is a powerful concept that is not often used, but it can be used for a number of different things. In this case we are keeping track of the previous interrupt service routine and 'chaining' these routines together.

There are programs called Terminate and Stay Resident (TSRs) that are loaded into your computer. Some of these are called drivers, and the operating system itself also puts in subroutines to do basic functions. If you want to 'play nice' with all of this other software, the established protocol for making sure everybody gets a chance to review the data in an interrupt is to link each new interrupt subroutine to the previously stored interrupt vector. When we are done with whatever we want to do with the interrupt, we then let all of the other programs get a chance to used the interrupt as well. It is also possible that the Interrupt Service Routine (ISR) that we just wrote is not the first one in the chain, but instead one that is being called by another ISR.

Getting/Setting Interrupt Vectors[edit]

Again, this is Turbo Pascal 'hiding' the details in a convenient way. There is a 'vector table' that you can directly access, but this vector table is not always in the same location in RAM. If instead you go through the BIOS with a software interrupt, you are 'guaranteed' that the interrupt vector will be correctly replaced.

Hardware Interrupt Table[edit]

This table gives you a quick glance at some of the things that interrupts are used for, and the interrupt numbers associated with them. Keep in mind that the IRQ numbers are mainly reference numbers, and that the CPU uses a different set of numbers. The keyboard IRQ, for example, is IRQ1, but it is numbered as interrupt $09 inside the CPU.

There are also several interrupts that are 'generated' by the CPU itself. While technically hardware interrupts, these are generated by conditions within the CPU, sometimes based on conditions setup by your software or the operating system. When we start writing the interrupt service routine for the serial communication ports, we will be using interrupts 11 and 12 ($0B and $0C in hex). As can be seen, most interrupts are assigned for specific tasks. I've omitted the software interrupts mainly to keep this on topic regarding serial programming and hardware interrupts.

Other features[edit]

There are several other parts to this program that don't need too much more explanation. Remember, we are talking about serial programming, not interrupt drivers. I/O Port $60 is interesting as this is the Receiver Buffer (RBR) for the keyboard UART. This returns the keyboard 'scan code', not the actual character pressed. In fact, when you use a keyboard on a PC, the keyboard actually transmits two characters for each key that you use. One character is transmitted when you press the key down, and another character when the key is 'released' to go back up. In this case, the interrupt service routine in DOS normally converts the scan codes into ASCII codes that your software can use. In fact, simple keys like the shift key are treated as just another scan code.

The sound routines access the internal PC speaker, not something on a sound card. About the only thing that uses this speaker any more is the BIOS 'beep codes' that you hear only when there is a hardware failure to your computer, or the quick 'beep' when you start or reboot the computer. It was never designed for doing things like speech synthesis or music playback, and driver attempts to use it for those purposes sound awful. Still, it is something neat to experiment with and a legacy computer part that is surprisingly still used on many current computers.

Terminal Program Revisited[edit]

I'm going to go back to the serial terminal program for a bit and this time redo the application by using an interrupt service routine. There are a few other concepts I'd like to introduce as well so I'll try to put them in with this example program. From the user perspective, I would like to add the ability to change the terminal characteristics from the command line and allow an 'end-user' the ability to change things like the baud rate, stop bits, and parity checking, and allow these to be variables instead of hard-coded constants. I'll explain each section and then put it all together when we are through.

Serial ISR[edit]

Dosbox Serial Port Settings In Windows Xp

This is an example of a serial ISR we can use:

This isn't that much different from the polling method that we used earlier, but keep in mind that by placing the checking inside an ISR that the CPU is only doing the check when there is a piece of data available. Why even check the LSR to see if there is a data byte available? Reading data sent to the UART is not the only reason why the UART will invoke an interrupt. We will go over that in detail in a later section, but for now this is good programming practice as well, to confirm that the data is in there.

By moving this checking to the ISR, more CPU time is available for performing other tasks. We could even put the keyboard polling into an ISR as well, but we are going to keep things very simple for now.

FIFO disabling[edit]

There is one minor problem with the way we have written this ISR. We are assuming that there is no FIFO in the UART. The 'bug' that could happen with this ISR as it is currently written is that multiple characters can be in the FIFO buffer. Normally when this happens, the UART only sends a single interrupt, and it is up to the ISR to 'empty' the FIFO buffer completely.

Instead, all we are going to do is simply disable the FIFO completely. This can be done using the FCR (FIFO Control Register) and explicitly disabling the FIFO. As an added precaution, we are also going to 'clear' the FIFO buffers in the UART as a part of the initialization portion of the program. Clearing the FIFOs look like this:

Disabling the FIFOs look like this:

We will be using the FIFOs in the next section, so this is more a brief introduction to this register so far.

Working with the PIC[edit]

Up until this point, we didn't have to worry about working with the Programmable Interrupt Controller (the PIC). Now we need to. There isn't the need to do all of the potential instructions for the PIC, but we do need to enable and disable the interrupts that are used by the UART. There are two PICs typically on each PC, but due to the typical UART IRQ vector, we really only have to deal with the master PIC.

This adds the following two constants into the software:

After consulting the PIC IRQ table we need to add the following line to the software in order to enable IRQ4 (used for COM1 typically):

When we do the 'cleanup' when the program finishes, we also need to disable this IRQ as well with this line of software:

Remember that COM2 is on another IRQ vector, so you will have to use different constants for that IRQ. That will be demonstrated a little bit later. We are using a logical and/or with the existing value in this PIC register because we don't want to change the values for the other interrupt vectors that other software and drivers may be using on your PC.

We also need to modify the Interrupt Service Routine (ISR) a little bit to work with the PIC. There is a command you can send to the PIC that is simply called End of Interrupt (EOI). This signals to the PIC that it can clear this interrupt signal and process lower-priority interrupts. If you fail to clear the PIC, the interrupt signal will remain and none of the other interrupts that are 'lower priority' can be processed by the CPU. This is how the CPU communicates back to the PIC to end the interrupt cycle.

The following line is added to the ISR to make this happen:

Modem Control Register[edit]

This is perhaps the most non-obvious little mistake you can make when trying to get the UART interrupt. The Modem Control register is really the way for the UART to communicate to the rest of the PC. Because of the way the circuitry on the motherboards of most computers is designed, you usually have to turn on the Auxiliary Output 2 signal in order for interrupts to 'connect' to the CPU. In addition, here we are going to turn on the RTS and DTS signals on the serial data cable to make sure the equipment is going to transmit. We will cover software and hardware flow control in a later section.

Dosbox Serial Port Settings

To turn on these values in the MCR, we need to add the following line in the software:

Interrupt Enable Register[edit]

We are still not home free yet. We still need to enable interrupts on the UART itself. This is very simple, and for now all we want to trigger an interrupt from the UART is just when data is received by the UART. This is a very simple line to add here:

Putting this together so far[edit]

Here is the complete program using ISR input:

Dosbox Com Port Configuration

At this point you start to grasp how complex serial data programming can get. We are not finished yet, but if you have made it this far you hopefully understand each part of the program listed above. We are going to try and stay with this one step at a time, but at this point you should be able to write some simple custom software that uses serial I/O.

Command Line Input[edit]

There are a number of different ways that you can 'scan' the parameters that start the program. For example, if you start a simple terminal program in DOS, you can use this command to begin:

or perhaps

Obviously there should not be a need to have the end-user recompile the software if they want to change something simple like the baud rate. What we are trying to accomplish here is to grab those other items that were used to start the program. In Turbo Pascal, there is function that returns a string

which contains each item of the command line. These are passed to the program through strings. A quick sample program on how to extract these parameters can be found here:

Dosbox Serial Port Configuration

One interesting 'parameter' is parameter number 0, which is the name of the program that is processing the commands. We will not be using this parameter, but it is something useful in many other programming situations.

Grabbing Terminal Parameters[edit]

Serial Port Cable

For the sake of simplicity, we are going to require that either all of the parameters are going to be in that format of baud rate, bit size, stop bits, parity; or there will be no parameters at all. This example is going to be mainly to demonstrate how to use variables to change the settings of the UART by the software user rather than the programmer. Since the added sections are self-explanatory, I'm just going to give you the complete program. There will be some string manipulation going on here that is beyond the scope of this book, but that is going to be used only for parsing the commands. To keep the user interface simple, we are using the command line arguments alone for changing the UART parameters. We could build a fancy interface to allow these settings to be changed while the program is running, but that is an exercise that is left to the reader.

Serial Programming: Introduction and OSI Network Model-- RS-232 Wiring and Connections-- Typical RS232 Hardware Configuration-- 8250 UART-- DOS-- MAX232 Driver/Receiver Family-- TAPI Communications In Windows-- Linux and Unix-- Java-- Hayes-compatible Modems and AT Commands-- Universal Serial Bus (USB)-- Forming Data Packets-- Error Correction Methods-- Two Way Communication-- Packet Recovery Methods-- Serial Data Networks-- Practical Application Development-- IP Over Serial Connections

Dosbox Serial Port Settings On Linux