I am not an attention glutton who always feels the need to call attention to my blog with each entry I post. Of course I appreciate compliments, praise and criticism, but I don't respond to every post with "Check out my blog, you will find the answer there." While I love the outlet this blog gives me, I do not believe it is the best way to present reference material about DOS games.
I have been inspired by the idea to create and host a website. My fantasy site would have an alphabetical link to a list of games, and each link would send the user to the page about the DOS game listed. Each page would identify the game, give the year of first release, developer & publisher. It would give screenshots of each game for each major mode it supports, 40 Column Color Text, 80 Column Color Text, Monochrome Text, CGA, Hercules Graphics, Amstrad, Tandy, EGA, MCGA/VGA, SVGA and VESA It would give sound clips for the various music in the game, if any. It will give technical specs, including minimum/recommended RAM, input support (joystick, keyboard, mouse), DOS version required (1.0, 1.1, 2.0, 2.1, 3.0, 3.1, 3.2, 3.3, 5.0), etc. Also patch downloads would be available and advice on running the games on DOS. Version information would be provided where available.
In some ways, I envision this site as a light version of MobyGames, but unlike MobyGames, I would intend the site to be focused strictly on DOS games (including PC booters). Entries would be limited to only the games and their official expansion packs. I don't intend to give any separate coverage to re-releases, combo packs, shovelware CDs.
Each game would take up a full page and have all its information on one page. Screenshots would be shown in their native resolution (typically 320x200) and can be clicked on to show a 640x400 screenshot using nearest neighbor interpolation. This would have to be set browser by browser.
Typically pngs would only be allowed for screenshots. PNGs compress 8-bit graphics (256 colors or less) very well. They also compress losslessly. Each image can be stored in less than 10K. Few DOS games support 16-bit color graphics. I would see to it that an "incorrect" screenshot would be replaced by a correct one when discovered.
Additionally, music will be stored not as standard wave recordings or the like, instead it will be stored in a format appropriate for the output device. This would have a tremendous savings on bandwidth. General MIDI or MT-32 music will be stored in a .MID file (with accompanying patch file, if necessary), Adlib in .DRO v.2 format. Hopefully, someone would be able to device a simple format for Tandy 3-voice, PC Speaker and Game Blaster music and a simple player that works in DOSBox and on real hardware, regardless of speed (within reason).
One important feature of my site would be a list and search feature. The list feature would show all games that use a certain mode, support a certain device, etc. I would really like my search feature to support boolean search terms so that someone could search the games that, for example, support Adlib but NOT EGA.
The site design would be extremely simple and basic. No fancy stuff like embedded video, wallpapers with large file sizes. Hopefully the site would be so low in bandwidth requirements that it would not need ads, at least not the intrusive kind. It would not be a throwback to bad old ideas like frames, embedded midis or animated gif logos.
Sites I would take visual inspiration from include uncreativelabs.net, minuszerodegrees.net, home.comcast.net/~ervind/index.html, textfiles.com, oldskool.org. While all but one is more or less frozen in time, they have several features I admire :
Simple formatted text on solid color or basic textured backgrounds.
Small pictures and quick loading
Display on any browser
Site scaling to any resolution, not stuck in the center of the screen
One thing I would NOT do is to post box, media or manual scans. First of all, they are comparatively large compared to game screenshots. Second, I do not have many boxes and would not want to take them from another site.
Perhaps the site may progress to a point where directory listings with file dates and checksums for the files off the installation disks will be able to be included. Additionally, to bypass copy protection, a listing of the appropriate programs that can crack the game will also be given.
The main goal of the site is to be hosted on pure DOS-appropriate hardware. This, in my opinion, means a 486 class machine. I believe that Pentium machines are more appropriate to Windows 95. Additionally, I would want the site to be so simple that it could be properly displayed on a DOS-based browser like Arachne.
The site is right now just a fantasy, but I would love to have it get to the point where others can contribute freely like a wiki where moderation is done after the fact, if necessary, and not before.
Sunday, March 30, 2014
Saturday, March 29, 2014
Working with MT-32 & Yamaha FB-01 MIDI Files and Patches
1. Description of the MT-32's Capabilities
The MT-32 consists of eight instrument parts and one rhythm/percussion part. It calls them Parts 1-8 and R. Any part can be assigned to any of MIDI channels 1-16. The default is that parts 1-8 are assigned to MIDI channels 2-9. There is a setting to change this to MIDI channels 1-8. The rhythm/percussion part is always assigned to MIDI channel 10 by default.
These parts share 32-voices/notes of polyphony, but the dynamic allocation of polyphony is not efficient over 22-24 voices, especially on a first generation unit. The MT-32 does support an Overlow Assign mode where excess polyphony can be sent to a second MT-32 unit, but operation in practice is unreliable with first generation units.
A patch, which contains all the essential information for an instrument, is assigned to each part. Each patch can require up to 4 voices/notes to play, so there are restrictions on the sounds that can be played from the module. The use of multiple parts enables the MT-32 to be called Multi-Timbral, hence the name. This is done via a Program Change MIDI message, and the MT-32 contains built-in 128 instrument patches and 30 rhythm patches. A patch is made up of a timbre plus the patch parameter. Timbres are made up of up to four partials and common parameter setting for all partials. Each partial has many settings which can be individually controlled. Each partial takes one polyphony note/voice and can use either a waveform (square, rectangle or sawtooth) or a 16-bit PCM sample (128 available) as the basis of its sound.
A patch can call on four timbre banks, A, B, M & R. Timbre bank A corresponds to the first 64 built-in patches of the MT-32, bank B the second 64 built-in patches, bank R corresponds to the 30 percussion patches of the rhythm section (and the 33 sound effects of the LAPC-I/CM-32L), and bank M corresponds to an area where up to 64 user-created timbres are stored.
The MT-32 is a synthesizer because user created patches can be stored and recalled from memory. The SC-55, by contrast, is not a synthesizer. While each of the patches used by the 16 parts of the SC-55 can be adjusted similarly to an MT-32 timbre, there is much less flexibility and you can only modify the active patch. While the SC-55 is battery backed, this is intended to store the general settings of the module.
To dump or send custom patch/timbre data to the MT-32, System Exclusive MIDI messages are required. The sysex messages for patch/timbre data are unique to the MT-32 series and sequencers do not understand what they do. Moreover, most sequencer programs assume that Program Changes correspond to General MIDI instrument assingments, but the MT-32 has very different assignments.
2. Format of MT-32 Patches
The structure of an MT-32 patch, as contained in a sysex file, is as follows :
The various areas can be in any order, since each area is separate and independent in the MT-32's memory. The temporary areas may not be required to be transmitted.
The MT-32 sends and receives data in packets no larger than 256 bytes (really 128 bytes, see below). In order to send or receive bytes to the MT-32's various memory areas, System Exclusive messages are required. Each message adds 10 bytes to the data to be transmitted. By doing the math, up to 71 (MT-32) or 72 (CM-32L) System Exclusive messages may be sent at the start of a game to a LA synthesizer. The structure of a system exclusive message is as follows :
F0 - Begin System Exclusive Message
41 - Manufacturer ID (Roland)
10 - Device ID/Unit # (Default is Unit 17)
16 - Model ID (Roland LA Device)
11 - Command ID (Request Data 1/RQ1)
This is sent from the computer to the synthesier to tell it to send the data in a memory area to the computer. Command ID 12 is Data Set 1/DT1, and it is used when writing data to the synthesizer.
10 00 00 - The address of the area of memory to be addressed
00 00 17 - The number of bytes of data to be requested with RQ1. With DT1, this can be up to 256 bytes with a single sysex command.
59 - Checksum
F7 - End of System Exclusive Message
The sysex files from Quest Studios also include an MT-32 Display Message at the beginning and at the end of the sysex file, adding approximately 58 bytes to the file. The format of these commands is as follows :
F0 41 10 16 12 20 00 00 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx ck F7
The Display of the MT-32 supports 20 characters, but the command data need not include all twenty character places. Text is encoded in 7-bit ASCII. You will have to calculate the checksum for the message. You can find a Windows program that will avoid that tedious business here :
http://www.bwalk.com.au/Convert/Convert.html
This program can be used to convert text file containing command strings into a syx or a mid file :
http://www.bwalk.com.au/MidiUtil/FileConvert.html
Note that addresses and data never use a value above 7F, this is because these bytes are actually 7-bit bytes, not 8-bit bytes, the high bit is never used. The above program can convert decimal and hexadecimal to the 7-bit values the MT-32 uses.
With a rev. 0 MT-32, there must be a 40 microsecond delay between the sending of system exclusive messages. Thus it will take a minimum of three seconds to send a full patch bank to the MT-32. The rev. 1 MT-32 and all other MT-32 compatible LA synthesizers do not have this limitation.
There is no reason why you cannot send more than one dump receive request at one time. You can combine all the above dump receive commands into one file and use the file to obtain all the data at once. The resulting file size for the MT-32 will be 18,541 bytes. For the CM-32L, it will be 18,635 bytes. After accounting for the text messages, this dump will be 16 bytes larger than the Quest Studio's dumps. This is because QS missed the temporary patch area for the rhythm part.
Yamaha FB-01 and IBM Music Feature Card
The Yamaha FB-01 FM Sound Generator supports seven patch/voice banks. Each bank can hold up to 48 patches. Banks 1 and 2 are RAM banks and this is where users can store their custom patches. Banks 3-7 are ROM banks and have 48 patches each. As its name suggests, these are the built-in patches. Unlike the MT-32, there is no distinction between instrument and percussion channels/patches. Thus the device supports 240 built-in patches and 96 user-created patches.
A Program Change command only works with numbers 0-47, essentially confining the non-FB-01 aware device to a small subset of its available patches. To change the patch/voice bank requires a System Exclusive command to change the configuration parameters. This is how another voice bank is selected. The FB-01 has 16 RAM and 4 ROM choices for its Configuration Memory, which assigns MIDI channels, polyphony reserve, channel volume and the like.
The FB-01 receives 8 MIDI channels (8 parts), and by default uses MIDI channel 1-8. It only supports 8 simultaneous note playback (8 note polyphony). Each instrument patch can take from 1-8 notes. The core of the device is the Yamaha YM2614 FM Operator Type-P, which is musicially and (almost) functionally identical to the YM2151 chip found in many, many arcade machines. This chip supports 4-operator FM synthesis.
Sierra's games store custom patches in both RAM banks, so both will need to be dumped. The FB-01 can only receive System Exclusive messages on the MIDI channel assigned to a specific module (thus up to 16 modules can be supported via the MIDI channels) The default is channel 0/1. The system exclusive commands to do this are as follows :
F0 43 75 00 20 00 00 F7 (Voice Bank 0)
F0 43 75 00 20 00 01 F7 (Voice Bank 1)
Each resulting file will be 6,363 bytes.
Additionally, you may also need to dump the configuration memory. The command to dump all configuration memory is :
F0 43 75 00 20 03 00 F7
The file will be 2,616 bytes.
Sierra's games also use System Exclusive messages to change instruments and voice banks and adjust certain events like Note On and Note Off with a finer degree of control than possible with a standard message. This sysex is not generally large, but must be included to obtain an accurate rendition of the song.
This method works with either the IBM Music Feature Card or the FB-01. The makers of the FB-01 helpfully also decided to allow you to also send data from the module using the front panel buttons, but using the sysex above allows for saving the resulting data in one step.
The IBM Music Feature Card defaults to the memory protection function to off. It does not have a battery. The FB-01 defaults memory protection to on and has a spot-welded CR2032 battery. It needs to be set to off for custom patch data to be received by the FB-01. The IBM Music Feature Card's power on defaults allow all MIDI messages to pass from the MIDI IN (with the breakout box) to the music hardware on the card.
When the FB-01 or IBM card receives patch/configuration dumps, it will send back the following sysex : F0 43 60 0x F7. The 02 indicates an ACK, 03 indicates error, and 04 usually means you forgot to set the memory protection to off. The FB-01 will also show dump/received!! for a good dump, a dump/error for a bad dump and memory/protect if the memory protection is on. If you send all three sets of data, you will see the above sysex three times in the monitor.
If you want to send one sysex file to dump all three areas, put the configuration memory command first, then followed by the voice bank commands. I have found that the FB-01 will not acknowledge the configuration memory dump if it immediately follows a voice bank dump command. If it still doesn't work, send the dump commands as separate sysex files. A complete sysex file with all three areas will be 15,342 bytes, and should have the configuration memory sent first.
Capturing MT-32 or FB-01 Music
In order to obtain MT-32 or FB-01 song data, the following steps must be accomplished :
1. Capture the custom patches, if any
Not all games that support the MT-32 use custom patches. Games like King's Quest IV, Police Quest II, LOOM, The Secret of Monkey Island and Ultima VI do not use custom patches. However, they may still use a modest amount of sysex to modify existing patch and device parameters. Most games only load patches once, but some games like Ultima VII and Serpent Isle load three sets of patches, and each must be captured to capture all the music.
Fortunately, most games do not send an MT-32 reset once the player quits them. Additionally, MIDI cables are hot-swappable, so there are many ways to cut off a game and preserve its patches. So the first task is to start a game and let load its patches, then quit. The patches will be kept in the MT-32's memory.
The next step is to obtain those patches. If you are looking to dump a Sierra game's patches, the work has probably already been done and you can skip this step. Download the Sierra MT-32 Sound Library here : http://www.midimusicadventures.com/queststudios/mt32-resource/utilities/
The way I present here is a slightly tedious process, but typically you need only do it once per game. It requires a windows-compatible MIDI interface and the MIDI-OX program. The module will need to have its MIDI in and MIDI out cables connected to the interface. I found that an rev. 0 MT-32 did not send all the data to MIDI-OX, but a CM-32L did. The idea is to send sysex commands requesting that the module send the data in its memory. You will need one command for each section of memory, then you will need to save the resulting data to a file and perhaps convert it from text to a binary sysex file.
MIDI-OX is good because it has command called "Send/Receive Sysex", which will automatically save your data to a .syx file.
Note that an LAPC-I will not work to capture patches in this way. The LAPC-I is equilavent to an MPU-401 connected to a CM-32L by a MIDI OUT cable only. As there is no MIDI IN connection, the synthesizer has no way of sending data to the MPU-401 and thus the computer has no way to read it. The SCC-1 and all wavetable daughterboards have the same issue, but typically patch information is not requested from those devices.
When capturing a dump, do not use a crappy UART MPU-401 compatible interface like the ones found on a Sound Blaster 16. They failed to complete transfers of the MT-32's timbre banks.
2. Record the MIDI as played in a game
DOSBox is extremely useful for recording MIDI via its Capture Raw MIDI function. It saves all MIDI data to a MID file for easy editing in just about any sequencer.
You can also do this via a sequencer, which should be able to record MIDI data. This works best with two computers. In this case, connect the MIDI IN from your interface on computer one to the MIDI THRU of your MT-32. Computer two, preferably the older machine, will play the game and connect its interface to the MIDI IN of your MT-32.
3. Edit MIDI in Sequencer
In order to work with any MIDI file, you need a Sequencer. The best two sequencers back in the day were Voyetra Sequencer Plus Gold and Cakewalk Pro. Since we are talking to the MT-32, it is best to use vintage sequencers, and Quest Studios provides Voyetra's software for DOS and Cakewalk for Windows 3.1 Find them here :
http://www.midimusicadventures.com/queststudios/mt32-resource/utilities/
Both work in DOSBox, but because DOSBox does not implement the MIDI IN function, their functionality is somewhat crippled. Personally I prefer Cakewalk Pro.
MIDI files can be edited in a Sequencer similarly to how audio files are edited in an audio editing program. In this case, however, you will want to remove all the patch data that DOSBox captured. For the MT-32, DOSBox will fill all 256 banks (and they are not enough) with the patch data. Delete all of it with the Event List View. Do not delete any other sysex. For the FB-01, DOSBox will not completely capture the voice bank data, but you must only delete the sysex banks with the size 1024.
One thing you will want to do is to mute or delete any channels other than 2-10 for the MT-32. In Sierra's early SCI games, for example, channel 1 contains PC speaker data and channels 11-15 contains Adlib data. A CM-64 and CM-500 use channels 11-16 for their CM-32P and thus unintended sound will play on these channels if you are using those modules.
Cakewalk has the ability to play MIDI files, and you should avail yourself of this functionality. However, before you play a file, make sure to transmit the sysex patch bank with the Sysx view first. Find an empty bank and send it.
4. Embed patch to MIDI file (optional)
Cakewalk Pro uses .syx files to load patch banks in its bank manager. Load the .MID, go into the Sysex View page and load the sysex bank. Click on the Auto button and save your MID file. That is it! Additionally, it may be advisable to also embed an MT-32 reset sysex command so that you are sure you are not using any leftover data from any MIDI you played on the device prior. Finally, you may want to add a few extra measures of silence at the beginning of the song.
I do not believe that embedding is the best way to present these files. Many MIDI players have difficulty with large files or files with lots of sysex in it. Windows Media Player does not have any such issues, nor does DOSmid.
The MT-32 consists of eight instrument parts and one rhythm/percussion part. It calls them Parts 1-8 and R. Any part can be assigned to any of MIDI channels 1-16. The default is that parts 1-8 are assigned to MIDI channels 2-9. There is a setting to change this to MIDI channels 1-8. The rhythm/percussion part is always assigned to MIDI channel 10 by default.
These parts share 32-voices/notes of polyphony, but the dynamic allocation of polyphony is not efficient over 22-24 voices, especially on a first generation unit. The MT-32 does support an Overlow Assign mode where excess polyphony can be sent to a second MT-32 unit, but operation in practice is unreliable with first generation units.
A patch, which contains all the essential information for an instrument, is assigned to each part. Each patch can require up to 4 voices/notes to play, so there are restrictions on the sounds that can be played from the module. The use of multiple parts enables the MT-32 to be called Multi-Timbral, hence the name. This is done via a Program Change MIDI message, and the MT-32 contains built-in 128 instrument patches and 30 rhythm patches. A patch is made up of a timbre plus the patch parameter. Timbres are made up of up to four partials and common parameter setting for all partials. Each partial has many settings which can be individually controlled. Each partial takes one polyphony note/voice and can use either a waveform (square, rectangle or sawtooth) or a 16-bit PCM sample (128 available) as the basis of its sound.
A patch can call on four timbre banks, A, B, M & R. Timbre bank A corresponds to the first 64 built-in patches of the MT-32, bank B the second 64 built-in patches, bank R corresponds to the 30 percussion patches of the rhythm section (and the 33 sound effects of the LAPC-I/CM-32L), and bank M corresponds to an area where up to 64 user-created timbres are stored.
The MT-32 is a synthesizer because user created patches can be stored and recalled from memory. The SC-55, by contrast, is not a synthesizer. While each of the patches used by the 16 parts of the SC-55 can be adjusted similarly to an MT-32 timbre, there is much less flexibility and you can only modify the active patch. While the SC-55 is battery backed, this is intended to store the general settings of the module.
To dump or send custom patch/timbre data to the MT-32, System Exclusive MIDI messages are required. The sysex messages for patch/timbre data are unique to the MT-32 series and sequencers do not understand what they do. Moreover, most sequencer programs assume that Program Changes correspond to General MIDI instrument assingments, but the MT-32 has very different assignments.
2. Format of MT-32 Patches
The structure of an MT-32 patch, as contained in a sysex file, is as follows :
| Length in Bytes (Decimal) | MT-32 Area | Sysex Receive String |
| 33 | System Area | F0 41 10 16 11 10 00 00 00 00 17 59 F7 |
| 154 | Patch Temporary Area | F0 41 10 16 11 03 00 00 00 01 10 6C F7 |
| 266 | Rhythm Setup Temporary Area | F0 41 10 16 11 03 01 10 00 02 00 6A F7 |
| 360 | Rhythm Setup Temporary Area (CM-32L) | F0 41 10 16 11 03 01 10 00 02 54 16 F7 |
| 1064 | Patch Memory | F0 41 10 16 11 05 00 00 00 08 00 73 F7 |
| 17024 | Timbre Memory | F0 41 10 16 11 08 00 00 02 00 00 76 F7 |
The various areas can be in any order, since each area is separate and independent in the MT-32's memory. The temporary areas may not be required to be transmitted.
The MT-32 sends and receives data in packets no larger than 256 bytes (really 128 bytes, see below). In order to send or receive bytes to the MT-32's various memory areas, System Exclusive messages are required. Each message adds 10 bytes to the data to be transmitted. By doing the math, up to 71 (MT-32) or 72 (CM-32L) System Exclusive messages may be sent at the start of a game to a LA synthesizer. The structure of a system exclusive message is as follows :
F0 - Begin System Exclusive Message
41 - Manufacturer ID (Roland)
10 - Device ID/Unit # (Default is Unit 17)
16 - Model ID (Roland LA Device)
11 - Command ID (Request Data 1/RQ1)
This is sent from the computer to the synthesier to tell it to send the data in a memory area to the computer. Command ID 12 is Data Set 1/DT1, and it is used when writing data to the synthesizer.
10 00 00 - The address of the area of memory to be addressed
00 00 17 - The number of bytes of data to be requested with RQ1. With DT1, this can be up to 256 bytes with a single sysex command.
59 - Checksum
F7 - End of System Exclusive Message
The sysex files from Quest Studios also include an MT-32 Display Message at the beginning and at the end of the sysex file, adding approximately 58 bytes to the file. The format of these commands is as follows :
F0 41 10 16 12 20 00 00 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx ck F7
The Display of the MT-32 supports 20 characters, but the command data need not include all twenty character places. Text is encoded in 7-bit ASCII. You will have to calculate the checksum for the message. You can find a Windows program that will avoid that tedious business here :
http://www.bwalk.com.au/Convert/Convert.html
This program can be used to convert text file containing command strings into a syx or a mid file :
http://www.bwalk.com.au/MidiUtil/FileConvert.html
Note that addresses and data never use a value above 7F, this is because these bytes are actually 7-bit bytes, not 8-bit bytes, the high bit is never used. The above program can convert decimal and hexadecimal to the 7-bit values the MT-32 uses.
With a rev. 0 MT-32, there must be a 40 microsecond delay between the sending of system exclusive messages. Thus it will take a minimum of three seconds to send a full patch bank to the MT-32. The rev. 1 MT-32 and all other MT-32 compatible LA synthesizers do not have this limitation.
There is no reason why you cannot send more than one dump receive request at one time. You can combine all the above dump receive commands into one file and use the file to obtain all the data at once. The resulting file size for the MT-32 will be 18,541 bytes. For the CM-32L, it will be 18,635 bytes. After accounting for the text messages, this dump will be 16 bytes larger than the Quest Studio's dumps. This is because QS missed the temporary patch area for the rhythm part.
Yamaha FB-01 and IBM Music Feature Card
The Yamaha FB-01 FM Sound Generator supports seven patch/voice banks. Each bank can hold up to 48 patches. Banks 1 and 2 are RAM banks and this is where users can store their custom patches. Banks 3-7 are ROM banks and have 48 patches each. As its name suggests, these are the built-in patches. Unlike the MT-32, there is no distinction between instrument and percussion channels/patches. Thus the device supports 240 built-in patches and 96 user-created patches.
A Program Change command only works with numbers 0-47, essentially confining the non-FB-01 aware device to a small subset of its available patches. To change the patch/voice bank requires a System Exclusive command to change the configuration parameters. This is how another voice bank is selected. The FB-01 has 16 RAM and 4 ROM choices for its Configuration Memory, which assigns MIDI channels, polyphony reserve, channel volume and the like.
The FB-01 receives 8 MIDI channels (8 parts), and by default uses MIDI channel 1-8. It only supports 8 simultaneous note playback (8 note polyphony). Each instrument patch can take from 1-8 notes. The core of the device is the Yamaha YM2614 FM Operator Type-P, which is musicially and (almost) functionally identical to the YM2151 chip found in many, many arcade machines. This chip supports 4-operator FM synthesis.
Sierra's games store custom patches in both RAM banks, so both will need to be dumped. The FB-01 can only receive System Exclusive messages on the MIDI channel assigned to a specific module (thus up to 16 modules can be supported via the MIDI channels) The default is channel 0/1. The system exclusive commands to do this are as follows :
F0 43 75 00 20 00 00 F7 (Voice Bank 0)
F0 43 75 00 20 00 01 F7 (Voice Bank 1)
Each resulting file will be 6,363 bytes.
Additionally, you may also need to dump the configuration memory. The command to dump all configuration memory is :
F0 43 75 00 20 03 00 F7
The file will be 2,616 bytes.
Sierra's games also use System Exclusive messages to change instruments and voice banks and adjust certain events like Note On and Note Off with a finer degree of control than possible with a standard message. This sysex is not generally large, but must be included to obtain an accurate rendition of the song.
This method works with either the IBM Music Feature Card or the FB-01. The makers of the FB-01 helpfully also decided to allow you to also send data from the module using the front panel buttons, but using the sysex above allows for saving the resulting data in one step.
The IBM Music Feature Card defaults to the memory protection function to off. It does not have a battery. The FB-01 defaults memory protection to on and has a spot-welded CR2032 battery. It needs to be set to off for custom patch data to be received by the FB-01. The IBM Music Feature Card's power on defaults allow all MIDI messages to pass from the MIDI IN (with the breakout box) to the music hardware on the card.
When the FB-01 or IBM card receives patch/configuration dumps, it will send back the following sysex : F0 43 60 0x F7. The 02 indicates an ACK, 03 indicates error, and 04 usually means you forgot to set the memory protection to off. The FB-01 will also show dump/received!! for a good dump, a dump/error for a bad dump and memory/protect if the memory protection is on. If you send all three sets of data, you will see the above sysex three times in the monitor.
If you want to send one sysex file to dump all three areas, put the configuration memory command first, then followed by the voice bank commands. I have found that the FB-01 will not acknowledge the configuration memory dump if it immediately follows a voice bank dump command. If it still doesn't work, send the dump commands as separate sysex files. A complete sysex file with all three areas will be 15,342 bytes, and should have the configuration memory sent first.
Capturing MT-32 or FB-01 Music
In order to obtain MT-32 or FB-01 song data, the following steps must be accomplished :
1. Capture the custom patches, if any
Not all games that support the MT-32 use custom patches. Games like King's Quest IV, Police Quest II, LOOM, The Secret of Monkey Island and Ultima VI do not use custom patches. However, they may still use a modest amount of sysex to modify existing patch and device parameters. Most games only load patches once, but some games like Ultima VII and Serpent Isle load three sets of patches, and each must be captured to capture all the music.
Fortunately, most games do not send an MT-32 reset once the player quits them. Additionally, MIDI cables are hot-swappable, so there are many ways to cut off a game and preserve its patches. So the first task is to start a game and let load its patches, then quit. The patches will be kept in the MT-32's memory.
The next step is to obtain those patches. If you are looking to dump a Sierra game's patches, the work has probably already been done and you can skip this step. Download the Sierra MT-32 Sound Library here : http://www.midimusicadventures.com/queststudios/mt32-resource/utilities/
The way I present here is a slightly tedious process, but typically you need only do it once per game. It requires a windows-compatible MIDI interface and the MIDI-OX program. The module will need to have its MIDI in and MIDI out cables connected to the interface. I found that an rev. 0 MT-32 did not send all the data to MIDI-OX, but a CM-32L did. The idea is to send sysex commands requesting that the module send the data in its memory. You will need one command for each section of memory, then you will need to save the resulting data to a file and perhaps convert it from text to a binary sysex file.
MIDI-OX is good because it has command called "Send/Receive Sysex", which will automatically save your data to a .syx file.
Note that an LAPC-I will not work to capture patches in this way. The LAPC-I is equilavent to an MPU-401 connected to a CM-32L by a MIDI OUT cable only. As there is no MIDI IN connection, the synthesizer has no way of sending data to the MPU-401 and thus the computer has no way to read it. The SCC-1 and all wavetable daughterboards have the same issue, but typically patch information is not requested from those devices.
When capturing a dump, do not use a crappy UART MPU-401 compatible interface like the ones found on a Sound Blaster 16. They failed to complete transfers of the MT-32's timbre banks.
2. Record the MIDI as played in a game
DOSBox is extremely useful for recording MIDI via its Capture Raw MIDI function. It saves all MIDI data to a MID file for easy editing in just about any sequencer.
You can also do this via a sequencer, which should be able to record MIDI data. This works best with two computers. In this case, connect the MIDI IN from your interface on computer one to the MIDI THRU of your MT-32. Computer two, preferably the older machine, will play the game and connect its interface to the MIDI IN of your MT-32.
3. Edit MIDI in Sequencer
In order to work with any MIDI file, you need a Sequencer. The best two sequencers back in the day were Voyetra Sequencer Plus Gold and Cakewalk Pro. Since we are talking to the MT-32, it is best to use vintage sequencers, and Quest Studios provides Voyetra's software for DOS and Cakewalk for Windows 3.1 Find them here :
http://www.midimusicadventures.com/queststudios/mt32-resource/utilities/
Both work in DOSBox, but because DOSBox does not implement the MIDI IN function, their functionality is somewhat crippled. Personally I prefer Cakewalk Pro.
MIDI files can be edited in a Sequencer similarly to how audio files are edited in an audio editing program. In this case, however, you will want to remove all the patch data that DOSBox captured. For the MT-32, DOSBox will fill all 256 banks (and they are not enough) with the patch data. Delete all of it with the Event List View. Do not delete any other sysex. For the FB-01, DOSBox will not completely capture the voice bank data, but you must only delete the sysex banks with the size 1024.
One thing you will want to do is to mute or delete any channels other than 2-10 for the MT-32. In Sierra's early SCI games, for example, channel 1 contains PC speaker data and channels 11-15 contains Adlib data. A CM-64 and CM-500 use channels 11-16 for their CM-32P and thus unintended sound will play on these channels if you are using those modules.
Cakewalk has the ability to play MIDI files, and you should avail yourself of this functionality. However, before you play a file, make sure to transmit the sysex patch bank with the Sysx view first. Find an empty bank and send it.
4. Embed patch to MIDI file (optional)
Cakewalk Pro uses .syx files to load patch banks in its bank manager. Load the .MID, go into the Sysex View page and load the sysex bank. Click on the Auto button and save your MID file. That is it! Additionally, it may be advisable to also embed an MT-32 reset sysex command so that you are sure you are not using any leftover data from any MIDI you played on the device prior. Finally, you may want to add a few extra measures of silence at the beginning of the song.
I do not believe that embedding is the best way to present these files. Many MIDI players have difficulty with large files or files with lots of sysex in it. Windows Media Player does not have any such issues, nor does DOSmid.
Monday, March 24, 2014
Raw Adlib Capturing with DOSBox & Playback with DOS
One of DOSBox's best features is its ability to capture raw OPL commands and data with timing data to preserve as perfectly as possible the music data for Adlib and Sound Blaster cards. The capture feature supports OPL2, dual OPL2 and OPL3. One of the biggest advantages to this format is that the resulting files are quite small, maybe 6-7K for a single track or song. Another advantage is that you are not capturing a wav file of an emulated OPL2/3, you can take this .dro file and play it back on real hardware.
The resulting files have a .dro extension, which stands for DOSBox Raw OPL format. Fortunately, the capturing does not begin until the first OPL reads and writes are detected, so there will not be a lot of silent dead time. However, beginning with 0.73, released on May 27, 2009, DOSBox updated its DRO capture format to version 2, which is incompatible with any software written for version 0.1 (formerly known as 1.0). For the differences between the two formats, they can be found here :
http://www.shikadi.net/moddingwiki/DRO_Format
If you use DOSBox 0.72 or below (feature has been present since 0.63), then DRO version 1 files will be created. 0.73 or higher will only create DRO version 2 files. Since most people intend to use DOSBox 0.74 or SVN, I have put together this guide to software. I recommend using a current SVN build with the following patch applied (use the patch as given in the latest post) :
http://www.vogons.org/viewtopic.php?f=41&t=38029
As you might guess, capturing OPL music from a game may not always give a clean track. The track may loop and you will need to delete the repeated portion, or a second track may immediately segue from a first track, and you want the tracks separate. Sound effects may be playing. The program DRO Trimmer v4r4 will work with version 1 or 2 .dro files, and is quite easy to use. It also functions as a player for either type of DRO version file. Get it here :
http://www.jestarjokin.net/apps/drotrimmer
As its name implies, DRO Trimmer is a bare-bones trimmer. If you want to use fade-ins and fade-outs or other more sophisticated editing techniques, you will need to use a tracker. I do not know of any that work with the .DRO format. Nor do I know of any utilities that would convert DRO into a tracker-friendly format like S3M.
The mainstay of playing Adlib files in DOS on real hardware is a program called AdPlay, based on the AdPlug library. It can play just about every OPL file format out there, including proprietary formats from Sierra, LucasArts, Origin, Apogee and Westwood. It also supports various tracker formats and Roland ROL and Creative Labs' CMF formats. However, the DOS port of AdPlay was last updated in 2007 and thus only supports DRO version 1 files. However, do not write it off just yet. Downloads are on this site :
http://adplug.sourceforge.net/index.php
More than just trimming DRO files, the DRO Trimmer program can also convert DRO version 2 files into DRO version 1 files. Additionally, there is a program called DRO2IMF, which will convert DRO version 1 and 2 files into the IMF format that Apogee games use. It is located here :
http://www.shikadi.net/utils/dro2imf
You will also need a DPMI extender to run AdPlay, and the one this program expects is called csdpmi. For this reason, a 386 or better is required for playback. A version that works with AdPlay can be found here :
ftp://ftp.delorie.com/pub/djgpp/current/v2misc/csdpmi5b.zip
AdPlay will play IMF files and DRO version 1 without a problem, so either should work as a solution. However, I found that the converted IMF file plays correctly with AdPlay while the converted DRO file did not. I assume a natural DRO version 1 file, as recorded from DOSBox 0.72 or below, would work correctly with AdPlay. However, because DRO version 1 files are less accurate and would not have the benefit of the patch identified above, I would not advise using the older DOSBox for accurate OPL capture.
Another solution is a program called imfplay, which has the benefit of working with .DRO version 2 files without conversion. This program I have personally tested in my 486DX2/66. However, there are several caveats with using it on real hardware. First, it only supports OPL2 writes, OPL3 writes in a DRO file are ignored. The irony of this limitation will soon be apparent. Second, the cache of the 486, internal and external, must be disabled or the music will come out garbled. Whether it works on faster machines is unknown to me. Third, a sound card with an OPL3 chip must be used. OPL3 chips require fewer delays with port writes than OPL2 chips, and imfplay was intended to work with DOSBox, which does not care about delays to its emulated OPL chips. AdPlay does not have the OPL2 limitation or the slowdown requirement. You can find imfplay here :
http://software.kvee.cz/imfplay/
One thing I initially overlooked when I first wrote this post was that Harekiet, one of the authors of DOSBox, had written a small utility called DROPLAY that would allow DOSBox to play the v.2 DRO files made with DOSBox 0.73 and later versions. You can get it in the last post from here :
http://www.vogons.org/viewtopic.php?f=32&t=16217
DROPLAY does work on real hardware, so you can use it with a 486 or even something lesser to play back DRO v.2 tunes. I would prefer to use DRO files over a converted IMF file because the IMF file may require timing information that seems specific to Apogee games but may not be applicable generally to OPL game music.
The resulting files have a .dro extension, which stands for DOSBox Raw OPL format. Fortunately, the capturing does not begin until the first OPL reads and writes are detected, so there will not be a lot of silent dead time. However, beginning with 0.73, released on May 27, 2009, DOSBox updated its DRO capture format to version 2, which is incompatible with any software written for version 0.1 (formerly known as 1.0). For the differences between the two formats, they can be found here :
http://www.shikadi.net/moddingwiki/DRO_Format
If you use DOSBox 0.72 or below (feature has been present since 0.63), then DRO version 1 files will be created. 0.73 or higher will only create DRO version 2 files. Since most people intend to use DOSBox 0.74 or SVN, I have put together this guide to software. I recommend using a current SVN build with the following patch applied (use the patch as given in the latest post) :
http://www.vogons.org/viewtopic.php?f=41&t=38029
As you might guess, capturing OPL music from a game may not always give a clean track. The track may loop and you will need to delete the repeated portion, or a second track may immediately segue from a first track, and you want the tracks separate. Sound effects may be playing. The program DRO Trimmer v4r4 will work with version 1 or 2 .dro files, and is quite easy to use. It also functions as a player for either type of DRO version file. Get it here :
http://www.jestarjokin.net/apps/drotrimmer
As its name implies, DRO Trimmer is a bare-bones trimmer. If you want to use fade-ins and fade-outs or other more sophisticated editing techniques, you will need to use a tracker. I do not know of any that work with the .DRO format. Nor do I know of any utilities that would convert DRO into a tracker-friendly format like S3M.
The mainstay of playing Adlib files in DOS on real hardware is a program called AdPlay, based on the AdPlug library. It can play just about every OPL file format out there, including proprietary formats from Sierra, LucasArts, Origin, Apogee and Westwood. It also supports various tracker formats and Roland ROL and Creative Labs' CMF formats. However, the DOS port of AdPlay was last updated in 2007 and thus only supports DRO version 1 files. However, do not write it off just yet. Downloads are on this site :
http://adplug.sourceforge.net/index.php
More than just trimming DRO files, the DRO Trimmer program can also convert DRO version 2 files into DRO version 1 files. Additionally, there is a program called DRO2IMF, which will convert DRO version 1 and 2 files into the IMF format that Apogee games use. It is located here :
http://www.shikadi.net/utils/dro2imf
You will also need a DPMI extender to run AdPlay, and the one this program expects is called csdpmi. For this reason, a 386 or better is required for playback. A version that works with AdPlay can be found here :
ftp://ftp.delorie.com/pub/djgpp/current/v2misc/csdpmi5b.zip
AdPlay will play IMF files and DRO version 1 without a problem, so either should work as a solution. However, I found that the converted IMF file plays correctly with AdPlay while the converted DRO file did not. I assume a natural DRO version 1 file, as recorded from DOSBox 0.72 or below, would work correctly with AdPlay. However, because DRO version 1 files are less accurate and would not have the benefit of the patch identified above, I would not advise using the older DOSBox for accurate OPL capture.
Another solution is a program called imfplay, which has the benefit of working with .DRO version 2 files without conversion. This program I have personally tested in my 486DX2/66. However, there are several caveats with using it on real hardware. First, it only supports OPL2 writes, OPL3 writes in a DRO file are ignored. The irony of this limitation will soon be apparent. Second, the cache of the 486, internal and external, must be disabled or the music will come out garbled. Whether it works on faster machines is unknown to me. Third, a sound card with an OPL3 chip must be used. OPL3 chips require fewer delays with port writes than OPL2 chips, and imfplay was intended to work with DOSBox, which does not care about delays to its emulated OPL chips. AdPlay does not have the OPL2 limitation or the slowdown requirement. You can find imfplay here :
http://software.kvee.cz/imfplay/
One thing I initially overlooked when I first wrote this post was that Harekiet, one of the authors of DOSBox, had written a small utility called DROPLAY that would allow DOSBox to play the v.2 DRO files made with DOSBox 0.73 and later versions. You can get it in the last post from here :
http://www.vogons.org/viewtopic.php?f=32&t=16217
DROPLAY does work on real hardware, so you can use it with a 486 or even something lesser to play back DRO v.2 tunes. I would prefer to use DRO files over a converted IMF file because the IMF file may require timing information that seems specific to Apogee games but may not be applicable generally to OPL game music.
Wednesday, March 19, 2014
Beware...beware the Big Green Dragon that Sits on your Doorstep...
He eats little boys...puppy dog tails and big, fat SNAILS.
Beware...take care...BEWARE!
The above lines are a quote from Bela Lugosi's Scientist character in Ed Wood's infamous 1953 Transvestitexploitation & Sexchangexploitation film Glen or Glenda? The lines are puzzling in the narrative of the film, but Lugosi, acting as a kind of omniscient narrator, is clearly warning someone, presumably the main character who struggles with his desire to wear women's clothing in the repressed atmosphere of the 1950s. In my opinion, he is warning the main character of the dangers of his behavior, the confusion of gender roles, risk of exposure, rejection, humiliation and ruin by an intolerant post-War society.
This blog is mostly about vintage PCs, not bad movie criticism. However, I believe the quote to be quite appropriate to one of the greatest obstacles to the use of vintage PCs, the Internet.
The Internet is a necessity for modern computers. To the technologically literate, it is as much of a necessity as a driving license for suburbanites. We use it to get our news, to watch video, download audio and stay connected with out friends, especially those we have never met in person and due to distances are never likely to so meet.
How does the Internet deal with vintage PCs? In short, it is mostly indifferent or fairly hostile to them. Let me start with DOS. DOS has no particular difficulty with certain Internet protocols like hosting an FTP server, but the days of using a text-based terminal emulator to access a BBS or Telnet program to access email and post messages are long gone. Browsers for DOS are ancient like Arachne or text-based like Lynx. Just try accessing gmail through them, it won't be a pleasant experience even if it works at all. I observed some time ago now that you cannot really access the Vintage Computer Forums with a browser that runs on DOS or a vintage non-PC compatible like a 68000 Amiga or Atari ST. The more sites tend to update, the more likely they will break and fail to display and work properly on older browsers.
DOS multiplayer relied generally on direct serial (null-modem) connections and modems for two players at maximum. A null modem connection required physical proximity and a modem required a reliable phone line. Later, IPX protocols were sufficiently prevalent to allow many games to be played over networks and with more than two people. However, IPX networks were built for closed office networks, not a wide area network like the Internet. The Internet uses TCP/IP, and during the mid-to-late '90s, people used IPX-to-TCP/IP matchmaking services like Kali and Kahn to connect over the Internet with games that did not officially support it.
Today, DOS games are rarely played in multiplayer, and almost never on real hardware. Nobody wants to use a slow modem, vintage computer enthusiasts are not close enough to connect their systems directly, and the matchmaking services mentioned above are long gone. Some games are played using source ports like ZDoom, but they don't run on DOS. There is a modern matchmaking site called Classic Gaming Arena but it requires DOSBox to emulate IPX games and few people seem to use it.
The next step up from DOS is Windows 9x, and the Internet has long passed those OSes by. Modern Internet generally requires more horsepower than is recommended for those systems. Windows 98-ME had an absolute limit of 1GB of RAM, which seems to be the minimum required to obtain full enjoyment from today's Internet. It tends to be limited to Pentium IV chipsets at best, later hardware does not have chipset drivers.
Browsers for Windows 9x aren't great. Internet Explorer is limited to 6.x, which was crap then and is abominable now. Many, many sites will not display properly with it. Firefox versions officially supported are ancient, and above v2, KernelEx is required. KernelEx is a compatibility layer for Win 9x that allows certain programs that only officially work with Windows 2000/XP to run. However, even with KernelEx, you are increasingly limited to seriously out of date browsers. Firefox 8 works with KernelEx, and its from 2011, but using KernelEx is in my opinion is cheating. Don't expect to watch Youtube videos, but if you needed to look at a text-based walkthrough, these options will do. Modern Adobe Flash absolutely chugs on Pentium IIIs and IVs. No Chrome, no Safari, and Opera is limited to 10.10 for Java support.
I know of few people who actively use multiplayer with Windows 9x games. Most have moved on to more modern games or source ports that run on Windows XP hardware. Some servers, even though the game supports Windows 9x, refuse to let clients running Windows 9x run on them, citing security and stability concerns. You may want to keep a Windows 9x system and a Windows XP system for this purpose. Most Windows 9x games can run more or less on Windows XP, but they may also allow you to connect to servers.
Moving along, you can still find many good modern browsers for Windows XP, and the Internet will run fine with it today. However, it is a dying OS and official support for it will end from Microsoft next month. This is a none-too-suble way of trying to get people to upgrade. There are plenty of unpatched exploits and malware, viruses, trojans, malicious programs... Many people today advise to pull the plug, keep those Windows XP systems for playing old games (in singleplayer), keep them on the home network, but don't let them connect to the Internet. There is some wisdom in this.
One thing you can do to decrease the risk is to download anything you need from a modern computer and transfer it to the vintage computer over a home network. Essentially the communication works best one way, as Windows 9x and sometimes XP have difficulties sending things to Windows 7/8 over a home network. There is little reason to have two-way communication over the home network. One exception is if you are using Windows 9x and need to access CD images using Daemon Tools. You can also "hide" Internet Explorer to prevent inadvertent connections to the Internet. You can also use links directly to sites you use frequently like GameFAQs.
Naturally, in my opinion, you should only be using vintage computers for games. You should not store important documents, personal items or work product on an unsecured computer. If you do acquire some nasty malware, you can pull the ethernet cable and find a solution. If there isn't one, wipe your HD (Darik's Boot 'N Nuke takes care of that) and reinstall (slipstream updates with Windows XP).
In short, its probably best to keep your vintage Internet explorations to Trusted Websites, Trusted Servers and Trusted Services (battle.net for example). Otherwise, the Big Green Dragon may eat you.
Beware...take care...BEWARE!
The above lines are a quote from Bela Lugosi's Scientist character in Ed Wood's infamous 1953 Transvestitexploitation & Sexchangexploitation film Glen or Glenda? The lines are puzzling in the narrative of the film, but Lugosi, acting as a kind of omniscient narrator, is clearly warning someone, presumably the main character who struggles with his desire to wear women's clothing in the repressed atmosphere of the 1950s. In my opinion, he is warning the main character of the dangers of his behavior, the confusion of gender roles, risk of exposure, rejection, humiliation and ruin by an intolerant post-War society.
This blog is mostly about vintage PCs, not bad movie criticism. However, I believe the quote to be quite appropriate to one of the greatest obstacles to the use of vintage PCs, the Internet.
The Internet is a necessity for modern computers. To the technologically literate, it is as much of a necessity as a driving license for suburbanites. We use it to get our news, to watch video, download audio and stay connected with out friends, especially those we have never met in person and due to distances are never likely to so meet.
How does the Internet deal with vintage PCs? In short, it is mostly indifferent or fairly hostile to them. Let me start with DOS. DOS has no particular difficulty with certain Internet protocols like hosting an FTP server, but the days of using a text-based terminal emulator to access a BBS or Telnet program to access email and post messages are long gone. Browsers for DOS are ancient like Arachne or text-based like Lynx. Just try accessing gmail through them, it won't be a pleasant experience even if it works at all. I observed some time ago now that you cannot really access the Vintage Computer Forums with a browser that runs on DOS or a vintage non-PC compatible like a 68000 Amiga or Atari ST. The more sites tend to update, the more likely they will break and fail to display and work properly on older browsers.
DOS multiplayer relied generally on direct serial (null-modem) connections and modems for two players at maximum. A null modem connection required physical proximity and a modem required a reliable phone line. Later, IPX protocols were sufficiently prevalent to allow many games to be played over networks and with more than two people. However, IPX networks were built for closed office networks, not a wide area network like the Internet. The Internet uses TCP/IP, and during the mid-to-late '90s, people used IPX-to-TCP/IP matchmaking services like Kali and Kahn to connect over the Internet with games that did not officially support it.
Today, DOS games are rarely played in multiplayer, and almost never on real hardware. Nobody wants to use a slow modem, vintage computer enthusiasts are not close enough to connect their systems directly, and the matchmaking services mentioned above are long gone. Some games are played using source ports like ZDoom, but they don't run on DOS. There is a modern matchmaking site called Classic Gaming Arena but it requires DOSBox to emulate IPX games and few people seem to use it.
The next step up from DOS is Windows 9x, and the Internet has long passed those OSes by. Modern Internet generally requires more horsepower than is recommended for those systems. Windows 98-ME had an absolute limit of 1GB of RAM, which seems to be the minimum required to obtain full enjoyment from today's Internet. It tends to be limited to Pentium IV chipsets at best, later hardware does not have chipset drivers.
Browsers for Windows 9x aren't great. Internet Explorer is limited to 6.x, which was crap then and is abominable now. Many, many sites will not display properly with it. Firefox versions officially supported are ancient, and above v2, KernelEx is required. KernelEx is a compatibility layer for Win 9x that allows certain programs that only officially work with Windows 2000/XP to run. However, even with KernelEx, you are increasingly limited to seriously out of date browsers. Firefox 8 works with KernelEx, and its from 2011, but using KernelEx is in my opinion is cheating. Don't expect to watch Youtube videos, but if you needed to look at a text-based walkthrough, these options will do. Modern Adobe Flash absolutely chugs on Pentium IIIs and IVs. No Chrome, no Safari, and Opera is limited to 10.10 for Java support.
I know of few people who actively use multiplayer with Windows 9x games. Most have moved on to more modern games or source ports that run on Windows XP hardware. Some servers, even though the game supports Windows 9x, refuse to let clients running Windows 9x run on them, citing security and stability concerns. You may want to keep a Windows 9x system and a Windows XP system for this purpose. Most Windows 9x games can run more or less on Windows XP, but they may also allow you to connect to servers.
Moving along, you can still find many good modern browsers for Windows XP, and the Internet will run fine with it today. However, it is a dying OS and official support for it will end from Microsoft next month. This is a none-too-suble way of trying to get people to upgrade. There are plenty of unpatched exploits and malware, viruses, trojans, malicious programs... Many people today advise to pull the plug, keep those Windows XP systems for playing old games (in singleplayer), keep them on the home network, but don't let them connect to the Internet. There is some wisdom in this.
One thing you can do to decrease the risk is to download anything you need from a modern computer and transfer it to the vintage computer over a home network. Essentially the communication works best one way, as Windows 9x and sometimes XP have difficulties sending things to Windows 7/8 over a home network. There is little reason to have two-way communication over the home network. One exception is if you are using Windows 9x and need to access CD images using Daemon Tools. You can also "hide" Internet Explorer to prevent inadvertent connections to the Internet. You can also use links directly to sites you use frequently like GameFAQs.
Naturally, in my opinion, you should only be using vintage computers for games. You should not store important documents, personal items or work product on an unsecured computer. If you do acquire some nasty malware, you can pull the ethernet cable and find a solution. If there isn't one, wipe your HD (Darik's Boot 'N Nuke takes care of that) and reinstall (slipstream updates with Windows XP).
In short, its probably best to keep your vintage Internet explorations to Trusted Websites, Trusted Servers and Trusted Services (battle.net for example). Otherwise, the Big Green Dragon may eat you.
Tuesday, March 18, 2014
The Monochrome Experience - CGA, EGA and VGA
A few posts back, I discussed some of the notable features of the Monochrome Display Adapter and Hercules Graphics Card. In this post, I intend to talk about monochrome graphics on other adapters of the time, namely CGA (and its derivatives Tandy and PCjr.), EGA and VGA. All these adapters could support monochrome monitors, although they were at their best when connected to color displays.
Some VGA games, including many of Sierra's SCI engine adventure games, had a driver which Sierra claimed would allow for up to 256 shades of "gray". This was nonsense, the hardware was limited to 64 shades of gray due to the 6-bits per color regardless of being displayed on a monochrome or color VGA monitor. This driver would show the same graphics whether used on a color or a monochrome VGA monitor. However, the color graphics driver wrote palette values directly to the VGA palette registers, so color information would be lost because only the green channel was being represented. Sierra could ensure a better representation of the color graphics in grayscale by using BIOS writes to the palette, which forces the VGA card to send color summed monochrome values to the monitor. This works whether the display is a color monitor or a monochrome monitor.
Sierra's driver did a very good job of preserving the detail of the color graphics for those forced to use color screens. Pinball Fantasies also supported a "mono" graphics display setting, using up to 64 grayscale shades in the Mode X modes it supports, 320x240 amd 360x350.
CGA, Tandy & PCjr.
At first, if you wanted to connect a CGA card to a monochrome monitor, you typically would use a monochrome composite monitor. The RCA jack on the CGA card would be used. If you were really lacking for a monitor, a black and white monitor would do in a pinch, but you probably would have to run the composite output of the CGA card through an RF converter box. The resulting graphics would be nowhere near as sharp as with a straight composite connection. Lets start with our test images :
Monochrome computer monitors typically would offer a high-contrast color : white on black, green on black or amber on black. Text was sharp at 40 columns and tolerable at 80 columns, especially when the screen size was 12" or less. Since composite monitors (in North America) refreshed at 60Hz, there was less need for the long persistence phosphors (and resulting ghosting) that was seen on the 50Hz MDA monitor.
The Compaq Portable used a 9" green composite screen. The IBM PC Portable used a 9" amber monochrome composite screen connected to a CGA card. Even though the IBM machine is close to a clone of the Compaq machine (which in turn is a clone of the IBM PC), their monitors are quite different. The IBM monitor is a bog-standard monochrome composite screen and connects with an internal version of the RCA jack on its CGA card. For this reason, you will see jailbars on the screen as you would see them on a color screen because the of the NTSC color decoding.
The screen on the Compaq is quite interesting. The Compaq's video adapter supports both MDA and CGA graphics, and in the 80x25 text mode will act like an MDA card, not a CGA card. Snow be gone! The display is a "dual-sync" display apparently capable of accepting both a 15KHz and 18KHz horizontal scan frequency signal. Otherwise the card acts like a CGA card. The input must be able to accept the TTL signals from the CGA card and convert them to grayscale. The resulting image is much sharper than on the IBM card (especially in 640x200 graphics) and will not show jailbars.
Early IBM CGA cards had a very basic monochrome support capability through the composite connector. Essentially there for the low intensity eight colors would transform into black, gray and white. For the high intensity colors, the same pattern would be seen, slightly brighter. Later CGA cards took hue into account when converting RGB colors into luminances, so that there would be a unique shade for each of the 16 colors. Here is an approximation of how the test images would look with the IBM PC Portable's amber monochrome screen and the early and late CGA cards.
CGA Mode 6 was a 640x200 monochrome mode, where the active pixel could be a color, but the background color would always be black. Any of the 16 CGA colors could be used, but typically the color would be white/light gray or white/high intensity white. The IBM PC BIOS did not support selecting the foreground color in this mode, to do this you had to use the Color Select register. It was not typically used because most CGA games preferred the more colorful if lower resolution Modes 4 & 5. Often, if you saw these graphics, it was intended for color composite graphics. The Wizardry games have intentional support for this mode, as do other games like SimCity, which benefits more from a high resolution than colorful graphics.
When the Color Composite bit was set in the Mode Control register, on a color composite monitor, the mode would display artifact colors. On an RGB or monochrome composite monitor, the color composite bit made no difference to the graphics in a real CGA card.
CGA Mode 5 was a 320x200 color mode on an RGBI monitor, which a palette of cyan, red and white (intensity selectable). On a composite monitor, whether color or monochrome, it displayed 2-3 (early CGA) or 4 (late CGA) shades of intensity, no color. Mode 5 would typically be supported as an option if the game supported Mode 4 color graphics or Mode 6 color composite graphics or Tandy/EGA/MCGA/VGA.
Eventually, there would be monochrome TTL monitors that would accept a CGA signal. In this case, the monitor converts RGBI into intensities of one color. Early LCDs were also monochrome devices, and brightness levels for each individual pixel were usually limited to on and off, although the IBM PC Convertible did advertise three levels of brightness for the CGA 4-color graphics modes. The PC Convertible's LCD had a native resolution of 640x200 and stretched 320x200 graphics modes horizontally by two. The aspect ratio would seem wrong except for applications intended for the Convertible's screen (typically from IBM). Here are approximations of how the test graphics would look on the Convertible's LCD screen :
Tandy and PCjr always displayed 16 intensities of one color when displayed on a monochrome composite monitor. It looks something like this :
EGA
IBM's EGA card could be connected to a color RGBI TTL monitor like the 5153 and support 8x8 text (Modes 0/1 and 2/3) and color 200 line modes (Modes 4, 5, 6, D & E). It could also a high resolution 6-bit RGB TTL monitor like the 5154 and support 8x14 text, color 200 and 350 line graphics modes (mode 10). Finally, it could be connected to a monochrome TTL monitor like the 5151 and support text at 9x16 (Mode 7) just like an MDA card, and additionally supported a 640x350 line monochrome graphics mode (Mode F). A real MDA monitor must be connected to use Mode F, which was similar to the Hercules Graphics in that it allowed each pixel to be turned on or off. It did not work in the same way as Hercules, and far fewer games supported it. While Hercules graphics were 720x348 pixels, usually only 640 horizontal pixels were actively used in Hercules as it was much easier to convert from 320 pixel graphics modes, so Hercules did not often have an advantage in resolution. However, since IBM derived the graphics mode from the text mode, each individual pixel can be made to blink or display in intense video. I do not know of any game which may have supported this functionality. Mode F is the only graphics mode supported when the EGA is connected to an MDA monitor.
In order to use an MDA monitor with an EGA card, the dipswitches or jumpers on the card must be set correctly. Switch 3 must be ON, switches 2 & 4 must be OFF. The EGA card, when connected to an MDA monitor, can be used with a CGA or a secondary EGA card connected to a color monitor.
Even though EGA can be connected to an MDA monitor and at first glance look identical to the MDA's text mode, using unusual text character attributes can show differences compared to the MDA. This can be seen in 101 Monochrome Mazes, a game IBM released strictly for the MDA. When you run this game on an EGA or VGA card, you will not see exactly the same "graphics". This game uses text attributes that fall outside the canonical 16 IBM valid MDA attribute choices for the EGA and VGA. Compare the following :
MCGA/VGA
When IBM released its PS/2 computers, it advertised monochrome analog high scan-rate monitors like the 8503 alongside more expensive RGB color analog high scan-rate (VGA) 8512 or 8513 monitors. Systems with built in monitors like the PS/2 Model 25 could be ordered with a monochrome or color monitor. The price difference was several hundred dollars at the beginning, so monochrome monitors were much more attractive for certain business and educational purchasers.
IBM's early VGA monitors designated two pins in the HD-15 VGA monitor connector to inform the card whether it was a mono or a color monitor. Three of the bits would inform the VGA whether a monochrome monitor or a color monitor was being used. Later, two more pins would be added to identify the specifications of other IBM monitors, and later these four pins would be repurposed to send the monitor's capabilities to the PC. A real IBM monochrome monitor and IBM VGA implementation would output pixel information on the green pin only.
VGA used an 18-bit color palette, with 6-bits for red, 6-bits for green and 6-bits for blue. Each pixel on the screen could be set to any of 256 colors from the 18-bit palette. When the monitor informs the card that it is a mono card, the VGA BIOS will convert the 18-bit color values into a 6-bit grayscale value by color summing the R, G and B values in a 30, 59, 11 ratio. In this manner, 64 intensities of the monitor color could be displayed using the 256 color graphics mode 13h. However, if the program wrote the palette registers directly, and most did, then only the information on their green channel would be sent to a monochrome display. In other modes, including 4-color and 16-color legacy CGA and EGA modes, the BIOS would set up the palette registers and convert them to grayscale unless a program wrote to the palette registers directly.
 |
| Space Quest II - 320x200x4c "RGB" Mode (Mode 4) |
 |
| Space Quest II - 640x200xMono "Composite Color" Mode (Mode 6 with Composite Color bit set) |
The Compaq Portable used a 9" green composite screen. The IBM PC Portable used a 9" amber monochrome composite screen connected to a CGA card. Even though the IBM machine is close to a clone of the Compaq machine (which in turn is a clone of the IBM PC), their monitors are quite different. The IBM monitor is a bog-standard monochrome composite screen and connects with an internal version of the RCA jack on its CGA card. For this reason, you will see jailbars on the screen as you would see them on a color screen because the of the NTSC color decoding.
The screen on the Compaq is quite interesting. The Compaq's video adapter supports both MDA and CGA graphics, and in the 80x25 text mode will act like an MDA card, not a CGA card. Snow be gone! The display is a "dual-sync" display apparently capable of accepting both a 15KHz and 18KHz horizontal scan frequency signal. Otherwise the card acts like a CGA card. The input must be able to accept the TTL signals from the CGA card and convert them to grayscale. The resulting image is much sharper than on the IBM card (especially in 640x200 graphics) and will not show jailbars.
Early IBM CGA cards had a very basic monochrome support capability through the composite connector. Essentially there for the low intensity eight colors would transform into black, gray and white. For the high intensity colors, the same pattern would be seen, slightly brighter. Later CGA cards took hue into account when converting RGB colors into luminances, so that there would be a unique shade for each of the 16 colors. Here is an approximation of how the test images would look with the IBM PC Portable's amber monochrome screen and the early and late CGA cards.
 |
| IBM PC Portable with Early CGA Card, 3 Intensities Available |
 |
| IBM PC Portable with Late CGA Card, 4 Intensities Available (note extra detail on the broom) |
When the Color Composite bit was set in the Mode Control register, on a color composite monitor, the mode would display artifact colors. On an RGB or monochrome composite monitor, the color composite bit made no difference to the graphics in a real CGA card.
CGA Mode 5 was a 320x200 color mode on an RGBI monitor, which a palette of cyan, red and white (intensity selectable). On a composite monitor, whether color or monochrome, it displayed 2-3 (early CGA) or 4 (late CGA) shades of intensity, no color. Mode 5 would typically be supported as an option if the game supported Mode 4 color graphics or Mode 6 color composite graphics or Tandy/EGA/MCGA/VGA.
Eventually, there would be monochrome TTL monitors that would accept a CGA signal. In this case, the monitor converts RGBI into intensities of one color. Early LCDs were also monochrome devices, and brightness levels for each individual pixel were usually limited to on and off, although the IBM PC Convertible did advertise three levels of brightness for the CGA 4-color graphics modes. The PC Convertible's LCD had a native resolution of 640x200 and stretched 320x200 graphics modes horizontally by two. The aspect ratio would seem wrong except for applications intended for the Convertible's screen (typically from IBM). Here are approximations of how the test graphics would look on the Convertible's LCD screen :
 |
| 640x200xMono Color Composite Mode (Mode 6 with Composite Color bit set) |
 |
| 320x200x4 RGB Mode (Mode 4) |
EGA
IBM's EGA card could be connected to a color RGBI TTL monitor like the 5153 and support 8x8 text (Modes 0/1 and 2/3) and color 200 line modes (Modes 4, 5, 6, D & E). It could also a high resolution 6-bit RGB TTL monitor like the 5154 and support 8x14 text, color 200 and 350 line graphics modes (mode 10). Finally, it could be connected to a monochrome TTL monitor like the 5151 and support text at 9x16 (Mode 7) just like an MDA card, and additionally supported a 640x350 line monochrome graphics mode (Mode F). A real MDA monitor must be connected to use Mode F, which was similar to the Hercules Graphics in that it allowed each pixel to be turned on or off. It did not work in the same way as Hercules, and far fewer games supported it. While Hercules graphics were 720x348 pixels, usually only 640 horizontal pixels were actively used in Hercules as it was much easier to convert from 320 pixel graphics modes, so Hercules did not often have an advantage in resolution. However, since IBM derived the graphics mode from the text mode, each individual pixel can be made to blink or display in intense video. I do not know of any game which may have supported this functionality. Mode F is the only graphics mode supported when the EGA is connected to an MDA monitor.
 |
| Microsoft Flight Simulator 3 - 640x350x16c Mode 10 |
 |
| Microsoft Flight Simulator 3 - 640x350xMono Mode 0F |
Even though EGA can be connected to an MDA monitor and at first glance look identical to the MDA's text mode, using unusual text character attributes can show differences compared to the MDA. This can be seen in 101 Monochrome Mazes, a game IBM released strictly for the MDA. When you run this game on an EGA or VGA card, you will not see exactly the same "graphics". This game uses text attributes that fall outside the canonical 16 IBM valid MDA attribute choices for the EGA and VGA. Compare the following :
 |
| 101 Monochrome Mazes MDA |
 |
| 101 Monochrome Mazes EGA/VGA |
When IBM released its PS/2 computers, it advertised monochrome analog high scan-rate monitors like the 8503 alongside more expensive RGB color analog high scan-rate (VGA) 8512 or 8513 monitors. Systems with built in monitors like the PS/2 Model 25 could be ordered with a monochrome or color monitor. The price difference was several hundred dollars at the beginning, so monochrome monitors were much more attractive for certain business and educational purchasers.
IBM's early VGA monitors designated two pins in the HD-15 VGA monitor connector to inform the card whether it was a mono or a color monitor. Three of the bits would inform the VGA whether a monochrome monitor or a color monitor was being used. Later, two more pins would be added to identify the specifications of other IBM monitors, and later these four pins would be repurposed to send the monitor's capabilities to the PC. A real IBM monochrome monitor and IBM VGA implementation would output pixel information on the green pin only.
VGA used an 18-bit color palette, with 6-bits for red, 6-bits for green and 6-bits for blue. Each pixel on the screen could be set to any of 256 colors from the 18-bit palette. When the monitor informs the card that it is a mono card, the VGA BIOS will convert the 18-bit color values into a 6-bit grayscale value by color summing the R, G and B values in a 30, 59, 11 ratio. In this manner, 64 intensities of the monitor color could be displayed using the 256 color graphics mode 13h. However, if the program wrote the palette registers directly, and most did, then only the information on their green channel would be sent to a monochrome display. In other modes, including 4-color and 16-color legacy CGA and EGA modes, the BIOS would set up the palette registers and convert them to grayscale unless a program wrote to the palette registers directly.
 |
| Conquests of the Longbow - 320x200x256c Mode 13 Color |
 |
| Conquests of the Longbow - 320x200x"256c"Mode 13 Grayscale |
 |
| Conquests of the Longbow - 320x200x256c Mode 13 Color as Displayed on a Monochrome Display |
By the late 80s and early 90s, monochrome plasma displays were common on laptops, and this design allowed them to give some definition to what would otherwise have been color graphics. However, this display technology was somewhat limited, as the gas plasma display in the IBM PS/2 Model P70 (a luggable) could only manage 16 shades of the orange color of that display. In 320x200, IBM would selectively dither a 2x2 block of pixels (remember that the display stretches 320x200 to 640x400) to simulate the 64 intensities that should be available.
Some VGA games, including many of Sierra's SCI engine adventure games, had a driver which Sierra claimed would allow for up to 256 shades of "gray". This was nonsense, the hardware was limited to 64 shades of gray due to the 6-bits per color regardless of being displayed on a monochrome or color VGA monitor. This driver would show the same graphics whether used on a color or a monochrome VGA monitor. However, the color graphics driver wrote palette values directly to the VGA palette registers, so color information would be lost because only the green channel was being represented. Sierra could ensure a better representation of the color graphics in grayscale by using BIOS writes to the palette, which forces the VGA card to send color summed monochrome values to the monitor. This works whether the display is a color monitor or a monochrome monitor.
Sierra's driver did a very good job of preserving the detail of the color graphics for those forced to use color screens. Pinball Fantasies also supported a "mono" graphics display setting, using up to 64 grayscale shades in the Mode X modes it supports, 320x240 amd 360x350.
 |
| Pinball Fantasies - 320x240x256c Mode X Color |
 |
| Pinball Fantasies - 320x240x"256c" Mode X Grayscale (note the loss of detail on the table art) |
Saturday, March 15, 2014
The Perfect Keyboard
In my opinion, the perfect keyboard has yet to be made. I envision a keyboard with the solid construction of an IBM Model F keyboard, the removable keycaps, LED faceplate and keycap lettering of the IBM Model M, the compatibility and much the layout of a Northgate Omnikey Ultra with a bit of the Apple Extended Keyboard.
The layout of the Model F, either the PC/XT or the AT version may be lacking for the 21st Century, but its build quality is second to none for PC keyboards. It uses buckling spring technology with stiff springs over a printed circuit board where the keyswitches are located. No membranes in these keyboards. They used steel and heavy duty plastic and weighed almost as much as the Model M, which used slightly lighter materials. Although rather annoying, every part of every key could be replaced. One lesser known feature of the Model F was that it did support N-key rollover, which the Model M does not.
Improvements of the Model M were keycaps that could be replaced without needing to replace key stems, making it much easier and quicker to rearrange the keyboard to the user's preference. The basic layout is standard today. The lettering IBM used on the keys and the LED panel is classic and professional. However, if you wanted a more stylish design, you can by replacing the keycaps. Replacing keycaps is easier than having to replace the keystem of the Model F. The cables, whether coiled or straight, were fairly heavy duty as these cables went. The SDL connector at the rear allowed you to change cables instead of using adapters, but today a lower cost connector could be used instead.
The Model M was criticized for putting the function keys above the keyboard instead of on the left side as on the PC/XT and AT keyboards. The Northgate Omnikey Ultra T put a set of function keys on the left side as well as on top. F1-F10 on the left side is in the same place as you would have found them on a PC/XT or AT keyboard, and F11-F12 are to the left of the Escape key, as they were added later. There was a switch to designate the top or the side rows of function keys are the primary and secondary function keys. With 24 function keys, any user should have enough keys for just about anything he or she wished to have a separate button.
Northgate's keyboards could emulate a wide variety of keyboards, including the PC/XT keyboard, the AT/Model M keyboard, the Tandy 1000, the Amstrad PCs, the ATT 6300, even the Amiga 2000 with dipswitches. My ideal keyboard would keep as much of this functionality as possible, using a dipswitch panel. A special driver should not be required for support in this day and age where cheap and powerful microcontrollers are readily available.
The Northgate Omnikey keyboards support N-key rollover, which the IBM Model M does not. They also have their keyswitches soldered onto a PCB. The IBM Model M uses a membrane sandwiched between the black plastic key housing frame and the PCB. The whole structure of the keyboard is held together by plastic rivets.
One thing about the Northgate and Apple keyboards is that they split the large + key on the numeric keypad into + and = (Northgate) and + and - (Apple). The Apple keyboard have added five keys, F16-F19 and an eject/power key on various keyboards. It also has F13-F15 where the Print Screen, Scroll Lock and Pause/Break keys are on an IBM keyboard. F13-F19 usually have no commonly defined role and there are plenty of keys in my ideal keyboard to accomodate them.
F16-F19 on an Apple keyboard occupy the area where the option LEDs are on an IBM Model M keyboard. Many keyboards have LEDs next to the Caps Lock, Num Lock and Scroll Lock keys. I am neutral to this. However, the keys that would be where the LED panel would be should be exactly the same size and use the same keystems as the rest of the keyboard.
The modern Windows 104-key keyboard includes the Windows keys, which seem to be a functional equivalent of the Apple Command keys. Occasionally, Windows keys can be helpful, but they can also very very annoying in their default usage. However, the menu key is a useless key that can be replicated with a right mouse button click or a shift F10. There is no reason for it to have a key as it really cuts down on the size of the spacebar. In my perfect keyboard, it does not exist on the spacebar row. There are plenty of function keys to assign it to.
Big L shaped enter keys, who needs them? I have never found them to be particularly helpful, and they cause the \ key to be put in odd places. Northgate shortened the right shift key, which is the only real flaw in its non-101 designs.
The layout of the Model F, either the PC/XT or the AT version may be lacking for the 21st Century, but its build quality is second to none for PC keyboards. It uses buckling spring technology with stiff springs over a printed circuit board where the keyswitches are located. No membranes in these keyboards. They used steel and heavy duty plastic and weighed almost as much as the Model M, which used slightly lighter materials. Although rather annoying, every part of every key could be replaced. One lesser known feature of the Model F was that it did support N-key rollover, which the Model M does not.
Improvements of the Model M were keycaps that could be replaced without needing to replace key stems, making it much easier and quicker to rearrange the keyboard to the user's preference. The basic layout is standard today. The lettering IBM used on the keys and the LED panel is classic and professional. However, if you wanted a more stylish design, you can by replacing the keycaps. Replacing keycaps is easier than having to replace the keystem of the Model F. The cables, whether coiled or straight, were fairly heavy duty as these cables went. The SDL connector at the rear allowed you to change cables instead of using adapters, but today a lower cost connector could be used instead.
The Model M was criticized for putting the function keys above the keyboard instead of on the left side as on the PC/XT and AT keyboards. The Northgate Omnikey Ultra T put a set of function keys on the left side as well as on top. F1-F10 on the left side is in the same place as you would have found them on a PC/XT or AT keyboard, and F11-F12 are to the left of the Escape key, as they were added later. There was a switch to designate the top or the side rows of function keys are the primary and secondary function keys. With 24 function keys, any user should have enough keys for just about anything he or she wished to have a separate button.
Northgate's keyboards could emulate a wide variety of keyboards, including the PC/XT keyboard, the AT/Model M keyboard, the Tandy 1000, the Amstrad PCs, the ATT 6300, even the Amiga 2000 with dipswitches. My ideal keyboard would keep as much of this functionality as possible, using a dipswitch panel. A special driver should not be required for support in this day and age where cheap and powerful microcontrollers are readily available.
The Northgate Omnikey keyboards support N-key rollover, which the IBM Model M does not. They also have their keyswitches soldered onto a PCB. The IBM Model M uses a membrane sandwiched between the black plastic key housing frame and the PCB. The whole structure of the keyboard is held together by plastic rivets.
One thing about the Northgate and Apple keyboards is that they split the large + key on the numeric keypad into + and = (Northgate) and + and - (Apple). The Apple keyboard have added five keys, F16-F19 and an eject/power key on various keyboards. It also has F13-F15 where the Print Screen, Scroll Lock and Pause/Break keys are on an IBM keyboard. F13-F19 usually have no commonly defined role and there are plenty of keys in my ideal keyboard to accomodate them.
F16-F19 on an Apple keyboard occupy the area where the option LEDs are on an IBM Model M keyboard. Many keyboards have LEDs next to the Caps Lock, Num Lock and Scroll Lock keys. I am neutral to this. However, the keys that would be where the LED panel would be should be exactly the same size and use the same keystems as the rest of the keyboard.
The modern Windows 104-key keyboard includes the Windows keys, which seem to be a functional equivalent of the Apple Command keys. Occasionally, Windows keys can be helpful, but they can also very very annoying in their default usage. However, the menu key is a useless key that can be replicated with a right mouse button click or a shift F10. There is no reason for it to have a key as it really cuts down on the size of the spacebar. In my perfect keyboard, it does not exist on the spacebar row. There are plenty of function keys to assign it to.
Big L shaped enter keys, who needs them? I have never found them to be particularly helpful, and they cause the \ key to be put in odd places. Northgate shortened the right shift key, which is the only real flaw in its non-101 designs.
Monday, March 10, 2014
Early PC CD-ROM Games
The Compact Disc may have been first prototyped in the 1970s, and the first CD-ROM drives available in the late 1980s, but it was the 1990s when CD-ROM games came to PCs. At first, however, they were little more than the same games on floppy disks with some kind of Redbook CD-Audio. Not long afterward, they were used to store digital audio in files and more detailed or higher resolution graphics and movies.
The first known CD-ROM game released for the IBM PC was The Manhole. This was a port of the floppy disk version of the B&W Macintosh original by Robyn and Rand Miller. The Millers would later go on to create Myst, but in the Manhole, you can see a definite beginning of the style of game for which they would become famous. The Manhole was released sometime around July, 1990. It supports VGA, MCGA, EGA and Tandy graphics. However, while the game uses VGA and MCGA graphics modes and supports a much wider variety of colors than the 16-color EGA and Tandy graphics modes, it displays no more than 16 colors on the screen at any one time. This was common back in 1989 when the floppy disk version was released, as using many more colors meant redrawing the graphics.
The CD format for The Manhole was a mixed-mode CD, consisting of one data track and one or more audio tracks. The CD standard can support a maximum of 99 tracks, and the Manhole uses 95 audio tracks (this does not count the data track) to store music, speech and sound effects. There is no need for a sound card to hear full audio with the CD version. Since there is no save feature, the game is run entirely off the CD-ROM. The floppy disk version supported Adlib, Roland MT-32 and Tandy 3-Voice music and Sound Blaster and Tandy DAC for speech. The audio is obviously much improved in quality and quantity over the floppy version. The graphics, however are exactly the same as the disk version. This version of The Manhole is very obscure today, and the game was re-released twice on CD-ROM format, once for DOS and Windows as The Manhole - New and Enhanced Edition (also on floppy) and once for Windows as The Manhole - CD-ROM Masterpiece Edition. These editions are much more common, much more impressive graphically, and use far fewer CD Audio tracks.
Just about one year later (1991), Sierra began to release its first CD-ROM conversions. While there probably were other games released beforehand, this was the first time a gaming company committed substantial resources and effort into promoting the new "multimedia" experience offered on disc. First came Mixed-Up Mother Goose, then Jones in the Fast Lane, followed by Stellar 7, King's Quest V and Space Quest IV. Like the Manhole, all had previously been released on floppies. They were also more expensive than the older floppy versions. Don't forget that a CD-ROM was a very expensive proposition in 1991, Sierra was charging $795.00 for a CD-ROM kit. At least the hardware, a SCSI CD-ROM and a Mediavision Pro Audio Spectrum (later 16), were high quality products.
Sierra's evolution of the CD-ROM format was simple. Jones in the Fast Lane included all its speech on one large audio track. The game would instruct the CD-ROM driver to play samples at specific times on the track. Music would require separate music hardware, as the only one CD-Audio track can play at a time.
Stellar 7 used its single CD-Audio track for speech during cutscenes for voice acting and the music. Sound effects were unchanged from the floppy version, relegating users to Adlib and MT-32 sound effects. One benefit to having all the music on one track was there would be less of a pause for the music to restart. However, preserving the timing of the track was especially critical, especially when making copies.
Mixed Up Mother Goose signalled a different approach. This time, the CD-ROM would be used strictly as a data CD, with the speech samples stored in one large audio file instead of on an audio track. A DAC like the Sound Blaster, Pro Audio Spectrum, Thunderboard, Tandy DAC or PS/1 Game/Audio Card would be required to hear the speech, which would be stored in an 8-bit sample format. Without this innovation, no more than 74 minutes of speech could be stored on a CD-ROM. Additionally, it was very annoying when the CD had to spin up to play a voice sample.
The most limiting aspect of the CD-ROM was the total inflexibility of pre-recorded audio. To adjust the parameters of a piece of music played on an MT-32, the programmer would only need to send a few kilobytes of data to the module. To adjust the music on a CD-ROM meant changing to another track. With 74 minutes maximum and 99 tracks, the musician could easily run out of space. LucasArts' games using the iMUSE dynamic sound system would always use the CD-ROM versions for voice acting.
Most CD-ROMs use the ISO-9660 format, which is standard for CD-ROMs and is widely used. Some of these early CD-ROMs, especially those from Sierra, use an earlier format called the High Sierra Format. MS-DOS's MSCDEX supports either format, but DOSBox has trouble with HSF. DOSBox will not IMGMOUNT a HSF image, but will MOUNT a drive using Daemon Tools and read the disc from that drive. Also, you can convert HSF images to ISO images using a program like Nero Burning ROM.
King's Quest V and Space Quest IV would continue the large audio file approach. A common approach to voices at this time was to use company members to voice various parts. Roberta Williams and other employees of Sierra, would lend their voices to many of these CD-ROM releases. Unfortunately, the resulting quality of the voice acting was somewhat lacking, since these individuals were not trained actors. Many other companies would follow Sierra's lead.
One company that never went the "Starring the programmers" route was LucasArts, which always sought professional voice talent for its CD-ROM conversions beginning with LOOM and Indiana Jones and The Fate of Atlantis. Professional voice actors had been relegated to roles voicing cartoon characters, announcers, bit parts and the like. Now there was a whole new avenue of employment for them for companies who cared enough about their expensive product to spring for decent voice acting. Eventually, "name" actors would be given roles.
Another type of CD-ROM release which began to appear in 1992 or so is the compilation release. On these CDs, there was nothing you could not have obtained on a disc, but the size of a CD allowed the inclusion of several (older) games (Interplay 10th Anniversary) or a game and all its expansion packs (Wing Commander Deluxe).
Data compression and relatively low bitrate techniques helped keep the size of speech files in check, and companies began to put full motion video on their discs. Interplay would re-release its Lord of the Rings : Fellowship of the Rings with animated scenes taken from the Ralph Bakshi movie of the 1970s. Sierra King's Quest VI CD-ROM would include a longer, better animated version of the introduction contained in the previously released floppy version.
One final issue with CD-ROMs games of the time is that these versions always seemed just to have something goat-glanded onto the floppy version. When the 7th Guest turned out to be a huge hit in 1993, all of a sudden the market for CD-ROM only games became attractive to developers. The 7th Guest used high resolution graphics throughout, digitized video around every corner and plenty of voice acting. It also came on two CD-ROMs. Far too much would have had to be cut to put the game on floppies, so Trilobyte took a gamble and did not bother to release a floppy version.
Just after The Seventh Guest, LucasArts released Day of the Tentacle simultaneously on floppy and CD. Up to this point in time, CD releases would lag several months behind floppy disk releases. Additionally, by the time the CD was released, there would be interface changes and the like. For DOTT, the game was more or less identical except that the CD version had a very large audio file. Floppy users still had the benefit of speech during the opening scenes. By the end of 1993, many, many games were being designed with CD-ROM first and then a cutdown floppy version would follow, usually compressed onto many disks.
The first known CD-ROM game released for the IBM PC was The Manhole. This was a port of the floppy disk version of the B&W Macintosh original by Robyn and Rand Miller. The Millers would later go on to create Myst, but in the Manhole, you can see a definite beginning of the style of game for which they would become famous. The Manhole was released sometime around July, 1990. It supports VGA, MCGA, EGA and Tandy graphics. However, while the game uses VGA and MCGA graphics modes and supports a much wider variety of colors than the 16-color EGA and Tandy graphics modes, it displays no more than 16 colors on the screen at any one time. This was common back in 1989 when the floppy disk version was released, as using many more colors meant redrawing the graphics.
The CD format for The Manhole was a mixed-mode CD, consisting of one data track and one or more audio tracks. The CD standard can support a maximum of 99 tracks, and the Manhole uses 95 audio tracks (this does not count the data track) to store music, speech and sound effects. There is no need for a sound card to hear full audio with the CD version. Since there is no save feature, the game is run entirely off the CD-ROM. The floppy disk version supported Adlib, Roland MT-32 and Tandy 3-Voice music and Sound Blaster and Tandy DAC for speech. The audio is obviously much improved in quality and quantity over the floppy version. The graphics, however are exactly the same as the disk version. This version of The Manhole is very obscure today, and the game was re-released twice on CD-ROM format, once for DOS and Windows as The Manhole - New and Enhanced Edition (also on floppy) and once for Windows as The Manhole - CD-ROM Masterpiece Edition. These editions are much more common, much more impressive graphically, and use far fewer CD Audio tracks.
Just about one year later (1991), Sierra began to release its first CD-ROM conversions. While there probably were other games released beforehand, this was the first time a gaming company committed substantial resources and effort into promoting the new "multimedia" experience offered on disc. First came Mixed-Up Mother Goose, then Jones in the Fast Lane, followed by Stellar 7, King's Quest V and Space Quest IV. Like the Manhole, all had previously been released on floppies. They were also more expensive than the older floppy versions. Don't forget that a CD-ROM was a very expensive proposition in 1991, Sierra was charging $795.00 for a CD-ROM kit. At least the hardware, a SCSI CD-ROM and a Mediavision Pro Audio Spectrum (later 16), were high quality products.
Sierra's evolution of the CD-ROM format was simple. Jones in the Fast Lane included all its speech on one large audio track. The game would instruct the CD-ROM driver to play samples at specific times on the track. Music would require separate music hardware, as the only one CD-Audio track can play at a time.
Stellar 7 used its single CD-Audio track for speech during cutscenes for voice acting and the music. Sound effects were unchanged from the floppy version, relegating users to Adlib and MT-32 sound effects. One benefit to having all the music on one track was there would be less of a pause for the music to restart. However, preserving the timing of the track was especially critical, especially when making copies.
Mixed Up Mother Goose signalled a different approach. This time, the CD-ROM would be used strictly as a data CD, with the speech samples stored in one large audio file instead of on an audio track. A DAC like the Sound Blaster, Pro Audio Spectrum, Thunderboard, Tandy DAC or PS/1 Game/Audio Card would be required to hear the speech, which would be stored in an 8-bit sample format. Without this innovation, no more than 74 minutes of speech could be stored on a CD-ROM. Additionally, it was very annoying when the CD had to spin up to play a voice sample.
The most limiting aspect of the CD-ROM was the total inflexibility of pre-recorded audio. To adjust the parameters of a piece of music played on an MT-32, the programmer would only need to send a few kilobytes of data to the module. To adjust the music on a CD-ROM meant changing to another track. With 74 minutes maximum and 99 tracks, the musician could easily run out of space. LucasArts' games using the iMUSE dynamic sound system would always use the CD-ROM versions for voice acting.
Most CD-ROMs use the ISO-9660 format, which is standard for CD-ROMs and is widely used. Some of these early CD-ROMs, especially those from Sierra, use an earlier format called the High Sierra Format. MS-DOS's MSCDEX supports either format, but DOSBox has trouble with HSF. DOSBox will not IMGMOUNT a HSF image, but will MOUNT a drive using Daemon Tools and read the disc from that drive. Also, you can convert HSF images to ISO images using a program like Nero Burning ROM.
King's Quest V and Space Quest IV would continue the large audio file approach. A common approach to voices at this time was to use company members to voice various parts. Roberta Williams and other employees of Sierra, would lend their voices to many of these CD-ROM releases. Unfortunately, the resulting quality of the voice acting was somewhat lacking, since these individuals were not trained actors. Many other companies would follow Sierra's lead.
One company that never went the "Starring the programmers" route was LucasArts, which always sought professional voice talent for its CD-ROM conversions beginning with LOOM and Indiana Jones and The Fate of Atlantis. Professional voice actors had been relegated to roles voicing cartoon characters, announcers, bit parts and the like. Now there was a whole new avenue of employment for them for companies who cared enough about their expensive product to spring for decent voice acting. Eventually, "name" actors would be given roles.
Another type of CD-ROM release which began to appear in 1992 or so is the compilation release. On these CDs, there was nothing you could not have obtained on a disc, but the size of a CD allowed the inclusion of several (older) games (Interplay 10th Anniversary) or a game and all its expansion packs (Wing Commander Deluxe).
Data compression and relatively low bitrate techniques helped keep the size of speech files in check, and companies began to put full motion video on their discs. Interplay would re-release its Lord of the Rings : Fellowship of the Rings with animated scenes taken from the Ralph Bakshi movie of the 1970s. Sierra King's Quest VI CD-ROM would include a longer, better animated version of the introduction contained in the previously released floppy version.
One final issue with CD-ROMs games of the time is that these versions always seemed just to have something goat-glanded onto the floppy version. When the 7th Guest turned out to be a huge hit in 1993, all of a sudden the market for CD-ROM only games became attractive to developers. The 7th Guest used high resolution graphics throughout, digitized video around every corner and plenty of voice acting. It also came on two CD-ROMs. Far too much would have had to be cut to put the game on floppies, so Trilobyte took a gamble and did not bother to release a floppy version.
Just after The Seventh Guest, LucasArts released Day of the Tentacle simultaneously on floppy and CD. Up to this point in time, CD releases would lag several months behind floppy disk releases. Additionally, by the time the CD was released, there would be interface changes and the like. For DOTT, the game was more or less identical except that the CD version had a very large audio file. Floppy users still had the benefit of speech during the opening scenes. By the end of 1993, many, many games were being designed with CD-ROM first and then a cutdown floppy version would follow, usually compressed onto many disks.
Saturday, March 8, 2014
Joystick Problems with DOS and Approaches to the Problem
IBM's Game Control Adapter was designed as something of an afterthought, a simple to use expansion card (for a programmer) as a way to provide for connecting a low-priority input device. It sat at port 201, supported four digital inputs, intended for buttons and four analog inputs, intended for paddles or joystick axes.
When it was released as one of the original expansion cards for the new IBM PC, it was perfectly adequate for the time. The Apple II joystick port operated in the same way but only supported three buttons. The Tandy Color Computer also supported four analog axes and four buttons, and its joysticks were later used in the mostly-PC compatible Tandy 1000 line. The Commodore VIC-20 only supported one Atari-style joystick or two Atari-style paddles. Only the Atari 400 and 800, with their four joystick ports, supported more game inputs.
In IBM's design, a joystick is a pair of potentiometers which are turned by moving the joystick. Each three-terminal, 100 kOhm potentiometer is connected through the joystick cable to a +5v line and a capacitor on the game control adapter. This capacitor is tied to an input on the NE558 Timer IC. The Timer compares the capacitance on its input with a reference capacitance, and outputs a 1 when the capacitance is not equal and a 0 when the capacitance is equal. The resistance value from the potentiometer determines how quickly the capacitor on the input will be charged. If the capacitor is turned to a lower resistance, the capacitor charges more quickly, and if turned to a higher resistance, the capacitor charges more slowly.
When the programmer wants to read the joystick position, he writes to port 201. This discharges the capacitors. Then the programmer reads and reads port 201 until there is a 1 for the axis he is trying to measure. The time taken for the value to become a 0 represents the position of the joystick. Many games have joystick calibration prompts requiring the player to move his stick to its maximum positions and its center to obtain the timing required to properly calibrate the stick.
Eventually the limits of the design began to emerge. The first was that the joystick had to be read several times to get an accurate measurement of the stick's position. This took a substantial portion of a 4.77MHz 8088 CPU's time. However, when there was only one CPU and one speed used in PC and compatibles, this was just an inconvenience, because the timing would be equivalent on all machines. For many simpler games, which relied on digital controls, fine measurement of the joystick axes was not an issue. However, when faster CPUs and clock speed began to emerge, joystick routines would consequently run faster. Thus routines would take 20% of the CPU's time an 8088 may only take 10% or less of the CPU's time on the more efficient 286. When CPU speeds began increasing to 6MHz, 8MHz and beyond, routines that were designed for the IBM PC would complete themselves far too quickly to get an accurate read of the joystick.
A second issue with the inherent accuracy of the components used to determine the joystick's position. Linear potentiometers such as used in the PC are not known for their rigorous accuracy. While the adjustment dials on each axis can help, they can shift or loosen over time. Moreover, the housings containing the resistive element and wiper are not hermetically sealed or anything close to it. Dust and dirt and oils over time can seep in and cause jittery or inaccurate reads. Wear on the resistive element can make it harder for the stick to give an accurate resistance.
IBM gave a formula to measure the time the stick would take to charge the capacitor at any given resistance (0-100). When it released the IBM PC AT, with its 6MHz 80286 CPU, it introduced Int 15, subfunction 84 to give a BIOS routine to read the joystick. Unfortunately, the clone PC makers had already spent substantial time and money cloning the original IBM PC BIOS, and this new BIOS call did not necessarily make it into every clone. Tandy 1000s do not support it. The advantage of the function was to give reliable reads because the routine was tied to the processor and speed(s) which the system board was designed to run.
Other companies tried to offer solutions to these problems. Tandy 1000 joysticks used the design from the Tandy Color Computer. Instead of using the potentiometers as variable resistors, Tandy uses them as voltage dividers by connecting the third terminal to ground. Inside the machine, the voltage is compared to a voltage ramp which, when port 201 is written to, is charged from 0v to +5v in a set period of time. When the voltage ramp is greater than the voltage from the joystick, a 0 is reported. This method has been said to give more precise and less jittery results than the timer-resistance method used on a true PC.
The Amstrad PC-1512 gave a unique solution to the joystick problem. It supported one Atari-style digital joystick with two buttons. This joystick plugged into the keyboard. The directionals and buttons for the joystick were assigned to unique keyboard scancodes 7C-77. However, when reported by the BIOS, pressing the directionals would give scancodes assigned to the cursor keys on the numeric keypad. Since many, many games used the keypad cursor control keys for movement, this was a highly compatible way to implement digital input. It would not work if the program read directly from the keyboard input port instead of the BIOS unless the program was Amstrad-aware. The two joystick buttons could be assigned to represent any key through the use of a program which would write to the Amstrad's non-volatile RAM. This memory would retain the buttons' settings until the next time the buttons' settings were changed.
When the Sound Blaster came along, it implemented a standard joystick port. Until the Sound Blaster 16, the port did not change. In the Sound Blaster 16, the old DIP-style NE558 timer was replaced with surface mounted components, which presumably have lower latencies which work better with faster processors. The Gravis Ultrasound implemented a hardware version of a speed adjustable gameport, and came with a program to adjust the sensitivity of the gameport without the use of an external dial or jumper.
Other companies made speed-adjustable gameports. In these gameports, a dial would be routed outside the computer to adjust the speed of the gameport. In the Thrustmaster ACM Game Card, the dial was a potentiometer which would adjust the resistance going to the reference capacitor. The ACM Game Card had a second joystick interface at port 209, requiring a second NE558. The dial controls the resistance for both reference capacitors.
The Gravis Gamepad was very popular in the early 90s because it provided four buttons and a NES-style D-pad. However, inside the Gravis Gamepad were transistors to convert the digital values of a D-pad into the analog resistance values expected by the PC gameport. Essentially pressing one side of the pad would give the maximum resistance value of the axis, the other side would give the minimum resistance value and not pressing the pad would give the middle of the resistance value.
Later joysticks, like the Gravis Gamepad Pro and the Microsoft Sidewinder gamepads would give options for truly digital controller with more than four buttons. These sticks would use the gameport to send binary codes to the program. The downside is that a DOS program had to have specific support for the gamepad, or the digital functionality of the gamepad would only work in Windows 95 with a driver.
Another late innovation was to take inspiration from computer ball mice. Computer mice and trackballs use optical rotary encoders to track movement, just like the dials on most arcade machines, the Atari driving controller and the N64 thumbstick. Reading from the encoders is much more reliable than the timer-potentiometer method and not prone to speed sensitive issues or the same kind of wear. The Microsoft Sidewinder 3D Pro had this function and many buttons, but unless a DOS program understood it, it had to emulate the analog potentiometer method
Once IBM ceded leadership of the PC market, no other company came up with a standardized digital gameport solution. Eventually, USB input devices of all kinds, gamepads, joysticks, driving wheels, rudder pedals, throttles, yokes put all the speed issues to software. However, USB really didn't catch on until Windows 98, so for almost twenty years game players had to deal with the analog gameport.
When it was released as one of the original expansion cards for the new IBM PC, it was perfectly adequate for the time. The Apple II joystick port operated in the same way but only supported three buttons. The Tandy Color Computer also supported four analog axes and four buttons, and its joysticks were later used in the mostly-PC compatible Tandy 1000 line. The Commodore VIC-20 only supported one Atari-style joystick or two Atari-style paddles. Only the Atari 400 and 800, with their four joystick ports, supported more game inputs.
In IBM's design, a joystick is a pair of potentiometers which are turned by moving the joystick. Each three-terminal, 100 kOhm potentiometer is connected through the joystick cable to a +5v line and a capacitor on the game control adapter. This capacitor is tied to an input on the NE558 Timer IC. The Timer compares the capacitance on its input with a reference capacitance, and outputs a 1 when the capacitance is not equal and a 0 when the capacitance is equal. The resistance value from the potentiometer determines how quickly the capacitor on the input will be charged. If the capacitor is turned to a lower resistance, the capacitor charges more quickly, and if turned to a higher resistance, the capacitor charges more slowly.
When the programmer wants to read the joystick position, he writes to port 201. This discharges the capacitors. Then the programmer reads and reads port 201 until there is a 1 for the axis he is trying to measure. The time taken for the value to become a 0 represents the position of the joystick. Many games have joystick calibration prompts requiring the player to move his stick to its maximum positions and its center to obtain the timing required to properly calibrate the stick.
Eventually the limits of the design began to emerge. The first was that the joystick had to be read several times to get an accurate measurement of the stick's position. This took a substantial portion of a 4.77MHz 8088 CPU's time. However, when there was only one CPU and one speed used in PC and compatibles, this was just an inconvenience, because the timing would be equivalent on all machines. For many simpler games, which relied on digital controls, fine measurement of the joystick axes was not an issue. However, when faster CPUs and clock speed began to emerge, joystick routines would consequently run faster. Thus routines would take 20% of the CPU's time an 8088 may only take 10% or less of the CPU's time on the more efficient 286. When CPU speeds began increasing to 6MHz, 8MHz and beyond, routines that were designed for the IBM PC would complete themselves far too quickly to get an accurate read of the joystick.
A second issue with the inherent accuracy of the components used to determine the joystick's position. Linear potentiometers such as used in the PC are not known for their rigorous accuracy. While the adjustment dials on each axis can help, they can shift or loosen over time. Moreover, the housings containing the resistive element and wiper are not hermetically sealed or anything close to it. Dust and dirt and oils over time can seep in and cause jittery or inaccurate reads. Wear on the resistive element can make it harder for the stick to give an accurate resistance.
IBM gave a formula to measure the time the stick would take to charge the capacitor at any given resistance (0-100). When it released the IBM PC AT, with its 6MHz 80286 CPU, it introduced Int 15, subfunction 84 to give a BIOS routine to read the joystick. Unfortunately, the clone PC makers had already spent substantial time and money cloning the original IBM PC BIOS, and this new BIOS call did not necessarily make it into every clone. Tandy 1000s do not support it. The advantage of the function was to give reliable reads because the routine was tied to the processor and speed(s) which the system board was designed to run.
Other companies tried to offer solutions to these problems. Tandy 1000 joysticks used the design from the Tandy Color Computer. Instead of using the potentiometers as variable resistors, Tandy uses them as voltage dividers by connecting the third terminal to ground. Inside the machine, the voltage is compared to a voltage ramp which, when port 201 is written to, is charged from 0v to +5v in a set period of time. When the voltage ramp is greater than the voltage from the joystick, a 0 is reported. This method has been said to give more precise and less jittery results than the timer-resistance method used on a true PC.
The Amstrad PC-1512 gave a unique solution to the joystick problem. It supported one Atari-style digital joystick with two buttons. This joystick plugged into the keyboard. The directionals and buttons for the joystick were assigned to unique keyboard scancodes 7C-77. However, when reported by the BIOS, pressing the directionals would give scancodes assigned to the cursor keys on the numeric keypad. Since many, many games used the keypad cursor control keys for movement, this was a highly compatible way to implement digital input. It would not work if the program read directly from the keyboard input port instead of the BIOS unless the program was Amstrad-aware. The two joystick buttons could be assigned to represent any key through the use of a program which would write to the Amstrad's non-volatile RAM. This memory would retain the buttons' settings until the next time the buttons' settings were changed.
When the Sound Blaster came along, it implemented a standard joystick port. Until the Sound Blaster 16, the port did not change. In the Sound Blaster 16, the old DIP-style NE558 timer was replaced with surface mounted components, which presumably have lower latencies which work better with faster processors. The Gravis Ultrasound implemented a hardware version of a speed adjustable gameport, and came with a program to adjust the sensitivity of the gameport without the use of an external dial or jumper.
Other companies made speed-adjustable gameports. In these gameports, a dial would be routed outside the computer to adjust the speed of the gameport. In the Thrustmaster ACM Game Card, the dial was a potentiometer which would adjust the resistance going to the reference capacitor. The ACM Game Card had a second joystick interface at port 209, requiring a second NE558. The dial controls the resistance for both reference capacitors.
The Gravis Gamepad was very popular in the early 90s because it provided four buttons and a NES-style D-pad. However, inside the Gravis Gamepad were transistors to convert the digital values of a D-pad into the analog resistance values expected by the PC gameport. Essentially pressing one side of the pad would give the maximum resistance value of the axis, the other side would give the minimum resistance value and not pressing the pad would give the middle of the resistance value.
Later joysticks, like the Gravis Gamepad Pro and the Microsoft Sidewinder gamepads would give options for truly digital controller with more than four buttons. These sticks would use the gameport to send binary codes to the program. The downside is that a DOS program had to have specific support for the gamepad, or the digital functionality of the gamepad would only work in Windows 95 with a driver.
Another late innovation was to take inspiration from computer ball mice. Computer mice and trackballs use optical rotary encoders to track movement, just like the dials on most arcade machines, the Atari driving controller and the N64 thumbstick. Reading from the encoders is much more reliable than the timer-potentiometer method and not prone to speed sensitive issues or the same kind of wear. The Microsoft Sidewinder 3D Pro had this function and many buttons, but unless a DOS program understood it, it had to emulate the analog potentiometer method
Once IBM ceded leadership of the PC market, no other company came up with a standardized digital gameport solution. Eventually, USB input devices of all kinds, gamepads, joysticks, driving wheels, rudder pedals, throttles, yokes put all the speed issues to software. However, USB really didn't catch on until Windows 98, so for almost twenty years game players had to deal with the analog gameport.
Friday, March 7, 2014
Tutorial : Compiling DOSBox SVN with Screenshot, Video Capture and IPX/Modem Support in Windows
DOSBox is a wonderful program, but in case you haven't noticed, the last official release, 0.74, is rapidly approaching its fourth birthday (05/12/2010). This is by far the longest time span between releases of the program. But DOSBox has not been sitting idly by, the developers have continued to fix bugs and add new features. While it is easy enough to find a pre-compiled version of the latest SVN, it may not be able to support screenshots without crashing (EmuCR), has more options in the config file than an average DOSBox user may need (DOSBox-X, Yhkwong's build) or simply won't have the features of that particular patch you are looking for. Until the development team releases 0.75, this is the closest you can get.
This tutorial is intended to guide a beginner through the compiling process in order to obtain a fully featured build of DOSBox SVN with important optional features such as IPX and Modem support and Screenshot and Video Recording in Windows. I have omitted adding the debugger features, if you need them, then this tutorial is probably too basic for you. To include the debug features, you need the curses library, and the best library for implementing the debugger in Windows is the pdcurses 3.4 library.
1. The Compiler
This tutorial assumes you are running DOSBox on some modern version of Windows and using an x86 CPU. (No Windows RT.) Since we will be using a Microsoft product to compile the source code, it will not work on any other system. It is easy enough to compile a DOSBox with the basic features. There is a good tutorial on how to do it in Visual Studio 2008 Express Edition. You can find it here and you may wish to consult with it if anything in this tutorial is unclear : http://www.dosbox.com/wiki/Building_DOSBox_with_Visual_C_2008_Express
I am indebted to the author, for this is the way I learned how to compile DOSBox, being a Microsoft loyalist since I first used a PC compatible in the early 90s. You can also use MinGW and MSYS, but that is a Unix/Linux approach utterly foreign to me (and I could never figure it out anyways).
VS2008 is getting a bit old in the tooth, and some of the more modern project files do not really support VS2008. So in this tutorial, I will be using Visual Studio 2010 Express, also freely downloadable from Microsoft. Virtual Studio includes Visual C++. Find it here :
http://www.visualstudio.com/en-us/downloads#d-2010-express
The installer will download the program and the modules it needs and will install them. It will also set file associations for the files we will be using.
2. The Source Code
Now, you need the source code. First start with the current DOSBox SVN, found here :
http://source.dosbox.com/dosboxsvn.tgz
You should use a program like 7zip to uncompress this file. It is doubly compressed. Please see my DOSBox patching guide if you want to add any patches, as you can at this stage :
http://nerdlypleasures.blogspot.com/2014/02/patching-dosbox-for-beginners.html
Next, you will need the Simple Directmedia Layer (SDL) to build libraries that DOSBox needs to function. DOSBox is only compatible with the 1.2 versions and the last version of SDL is 1.2.15. However, you should obtain the source code for 1.2.14, which is the last SDL 1.2 version that will compile easily in VS2010. You can download it here :
http://www.libsdl.org/release/SDL-1.2.14.zip
3. Optional Libraries
If you want to add the optional features to your compiled DOSBox, you will need some more source code to build libraries.
1. For Modem/IPX support, you need SDL_net. SDL_net's mirrors SDL's versions, and the most current version that will compile easily in VS2010 is 1.2.7. Get it here :
http://www.libsdl.org/projects/SDL_net/release/SDL_net-1.2.7.zip
Now what you have obtained above is the easy part. For working screenshots and video recording, you will need to compile libpng and zlib libraries from source. After that, then you compile DOSBox.
For libpng, the current stable source is 1.6.9. You can obtain it here :
http://prdownloads.sourceforge.net/libpng/lpng169.zip?download
You use libpng to compile both libpng.lib and zlib.lib, but for the latter, you need the zlib source code, and specifically 1.2.5 (even though 1.2.8 is the most recent version, but libpng expects 1.2.5). You can obtain 1.2.5 here :
http://www.winimage.com/zLibDll/zlib125.zip
4. Directory Setup
Once you have installed VS2010 and downloaded your source code and libraries, you need to put the source somewhere. Make a folder like \Project and unzip your source code and libraries so they look like this :
\Project\dosboxsvn
\Project\lpng169
\Project\SDL_net-1.2.7
\Project\SDL-devel-1.2.14
\Project\zlib-1.2.5
This will be important for the next step and make it easier to point the compiler to the various include and library files later on.
5. Compiling libpng.lib and zlib.lib
Go to \Project\lpng69\projects\vstudio\libpng and double click on libpng.vcxproj A vcxproj file is a Project File that tells a compiler how to build code. This will start the compiler. You should see Solution Explorer on the left hand side of the program. There are seven projects here, but we only need two of them. Right click on Solution 'vstudio' (7 projects), click on Properties and check the button that says Multiple startup projects: Set libpng and zlib to Start and the rest to None. Press Apply and OK.
Libpng relies on zlib, so we want to make sure zlib is compiled first. Right click on libpng in the Solution Explorer and go to Project Dependencies. In the drop down box, select libpng and make sure there is a checkmark next to zlib in the box below and none on any other box. Then click on the Build Order tab and you should see that zlib comes first and libpng comes second.
Next right click on Solution 'vstudio' (7 projects) and click on Configuration Manager. Under Active solution configuration: click Release Library. In the box below, next to libpng and zlib, change the Configuration to Release Library. For the other options, uncheck the boxes next to the Build so they will not be compiled. Do not worry if they compile anyway, these extra projects are mainly for testing.
Next, in the Solution Explorer right click on libpng and go to properties. On the left hand side, you should see a line called Configuration Properties. On the right side of the window, you will see a line that says Configuration Type. Click on the dropdown box next to it and set it to Static library (.lib) if it is not already.
Then click on VC++ Directories. The window here is a bit small for what you need to do, but be very careful here. Clicking on the wrong thing will wipe out the default directory entries, and if you do that the compiler will not know where to find the code it needs to compile.
Next to the line that says Include Directories, click once on the box after the partition. This will show a down arrow button. Click on that once and then click on On the next window, click on the icon of a file with an asterisk in the corner, then click on the box with the ... On the Select Directory Window, navigate to the directory with the zlib Include files. The directory is typically : \Project\zlib-1.2.5. When done, click OK.
To compile the libraries, hit F7. In the output window, you will see the compiler crunch code and turn it into libpng.lib and zlib.lib. If you succeed, the compiler will indicate where the .lib files are located. If you fail, then the compiler will report an error and your files will not be built. In this example, you can find the .lib files in \Project\lpng169\projects\vstudio\Release Library\ as zlib.lib and libpng16.lib.
6. Compiling SDL and SDL_net
In this guide, I have completely avoided using developer libraries. While there are appropriate Visual C ++ developer libraries that work with VS2010 available for SDL and SDL_net, I think its best to compile your own libraries. Since you have to do this for libpng and zlib, you already should begin to get a feel for how to incorporate include and library directories. Compiling your own libraries can improve DOSBox performance and compatibility with your particular system.
To compile SDL, you will need the DirectX SDK. The DirectX 10 SDK from June 2010 seems compatible, and you can get it here :
http://www.microsoft.com/en-us/download/details.aspx?id=6812
You only need to install the libraries. The installer may give an error if the rest of the components aren't installed, but the libraries will be installed. You will be able to find them typically in C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)
Now, in the SDL-1.2.14 directory, there will be a zip file named VisualC.zip. Unzip it so that you can see files in the next level subdirectory. Go into that subdirectory and open the file SDL.sln. This is a solution file used by older versions of Visual C++ to build a project. VS2010 will run a conversion tool that will convert it into something it can manage properly. Click on Next and then Finish. You may see some warnings but you shouldn't see any errors.
In the resulting Solution Explorer, you will see two projects, SDL and SDLmain, and you will need to compile both of them. First, right click on Solution 'SDL' (2 projects) and go to properties. Then click on the button that says Configuration Manager. From the Active solution configuration: dropdown menu, click on release, and for the Configuration menu drop downs next to SDL and SDLmain, set them both to release. Close the Configuration Manager. At this point, the Configuration dropmenu should show Active(Release). Click on Apply and then OK.
Next, in the Solution Explorer right click on SDL and go to properties. On the left hand side, you should see a line called Configuration Properties. On the right side of the window, you will see a line that says Configuration Type. Click on the dropdown box next to it and set it to Static library (.lib) if it is not already. DOSBox needs the libraries to compile, and SDL should still create an SDL.dll when you compile it.
Then click on VC++ Directories. This is where you add the DirectX SDK libraries you installed at the beginning of this step Next to the line that says Include Directories, click once on the box after the partition. This will show a down arrow button. Click on that once and then click on On the next window, click on the icon of a file with an asterisk in the corner, then click on the box with the ... On the Select Directory Window, navigate to the directory with the DirectX SDK Include files. The directory is typically : \Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include When done, click OK.
On the line that says Library Directories, you are going to do almost the same thing. This time, you want to add the directory for the DirectX SDK Library files. The directory is typically : \Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x86. Make sure you select the x86 (for 32-bit) and not the x64 (64-bit, DOSBox doesn't like 64-bit code). Once you are done, you can press OK to get back to the Solution Explorer. Now press F7 and you should be have created sdl.lib and sdlmain.lib in their respective Release directories, \Project\SDL-1.2.14\VisualC\SDL\Release and \Project\SDL-1.2.14\VisualC\SDLmain\Release
SDL_net requires the SDL libraries, which is why we compiled the SDL libraries first. Like with SDL, you will need to unzip the VisualC.zip file and convert the solution file SDL_net.sln. Set SDL_net to Release in the Configuration Properties.
Open the SDL_net properties page, set the Configuration Type to Static library (.lib) and then click on VC++ Directories. For the Include Directories, you need to add the directory containing the SDL Include files. They can be typically found here : \Project\SDL-1.2.14 Next you need to add the directories containing the SDL Library files. These are \Project\SDL-1.2.14\VisualC\SDL\Release and \Project\SDL-1.2.14\VisualC\SDLmain\Release. You need to add both. After you have done all this, you can exit the properties window and press F7 to compile. You should end up with sdl_net.lib.
7. Setting Up the DOSBox Compiling Environment
Now that you have all your libraries, you can compile as full a DOSBox as you like. Navigate to \Project\dosboxsvn\dosbox\visualc_net and click on dosbox.vcxproj
In the Solution Explorer Window, right click on dosbox. Set the active configuration to Release using the Configuration drop box and the Configuration Manager button first.
In the VC++ Directories, you will need to add the following directories to the Include Directories :
\Project\lpng169
\Project\SDL_net-1.2.7
\Project\SDL-1.2.14\include
\Project\zlib-1.2.5
\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include
If you are compiling code specific to Windows, you may also need to include a directory like :
\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\sys
You will need to add the following directories to the Library Directories :
\Project\lpng169\projects\vstudio\Release Library\
\Project\SDL_net-1.2.7\VisualC\Release
\Project\SDL-1.2.14\VisualC\SDL\Release
\Project\SDL-1.2.14\VisualC\SDLmain\Release
\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x86
On the left side of the Property Page, click on C/C++ and then on General. On the line that says Treat Warnings As Errors, click on the box next to it and set it to No (/WX-) The compiling process will give many warnings, and if this is not set these warnings will cause the build to fail.
Next click on Linker and next to the Force File Output, click on the box next to it and select Multiply Defined Symbol Only (/FORCE:MULTIPLE). Next to the Treat Linker Warning As Errors, click on the box next to it and select No (/WX:NO). These "errors" and warnings are not going to affect a compiled DOSBox, but they certainly will stop DOSBox from compiling correctly.
Finally, underneath Linker, click Input. The following line needs to be present :
dinput8.lib;dxguid.lib;libpng16.lib;sdl_net.lib;opengl32.lib;winmm.lib;sdlmain.lib;sdl.lib;ws2_32.lib;zlib.lib;%(AdditionalDependencies)
Many of these items are already present. You will need to add dinput8.lib and dxguid.lib and rename libpng.lib to libpng16.lib. Since the space is very small, you should check the spelling and formatting very carefully. Each library, including the last, needs a semicolon ; after it.
8. Adjusting the DOSBox Code and compiling
In the Solution Explorer, clock on Source Files and then click on visualc and then double click on config.h. The code listing will appear to the right. If you are not compiling with IPX and Modem support, then change the values from 1 to 0 in the lines :
#define C_MODEM 1
#define C_IPX 1
If you are not compiling with screenshot and video recording support, change the value from 1 to 0 in the
line :
#define C_SSHOT 1
Next, for a speed boost, change the value from 0 to 1 in the line :
#define C_CORE_INLINE 0
Finally, you should see in the Solution Explorer a file called winres.rc. Right click on that and select View Code Change the line that says #include "afxres.h" to #include "Windows.h"
In the Solution Explorer, right click on dosbox, go to properties an then the Configuration Manager. Makes sure the Active solution configuration and the dosbox project configuration are both set to Release, NOT Debug. Release builds are faster than debug builds. Debug DOSBox builds exhibit an annoying issue with the Adlib music where it will stutter unless the cycle count is set very low in DOSBox. After you close the Configuration Manager window, you should see in the Configuration drop down menu Active(Release). Exit the dosbox Property pages.
Now you are ready to compile. Hit F7 and be prepared to wait. If you are successful, you will have a dosbox.exe in \Project\dosboxsvn\dosbox\visualc_net\Release. You probably will not need any .dll files since the libraries should be statically linked within the DOSBox executable, but if you do, you can obtain them from the official 0.74 DOSBox.
DOSBox will generate a .conf file on its first run if one is not present. Look in the status window to find it and move it to the directory in which you will use DOSBox. It is typically buried in AppData on Windows Vista/7/8. It will save screenshots and other captures to a folder named capture, but by default will save them to the same place as it wrote the .conf file.
If you are using Windows 8.1, you will find that the mouse movement will be extremely jerky when using this build. This is due to some changes Microsoft made in handling mouse input. To fix the problem, apply the appropriate patch for your OS (32-bit or 64-bit) from here : http://support.microsoft.com/kb/2908279
This tutorial is intended to guide a beginner through the compiling process in order to obtain a fully featured build of DOSBox SVN with important optional features such as IPX and Modem support and Screenshot and Video Recording in Windows. I have omitted adding the debugger features, if you need them, then this tutorial is probably too basic for you. To include the debug features, you need the curses library, and the best library for implementing the debugger in Windows is the pdcurses 3.4 library.
1. The Compiler
This tutorial assumes you are running DOSBox on some modern version of Windows and using an x86 CPU. (No Windows RT.) Since we will be using a Microsoft product to compile the source code, it will not work on any other system. It is easy enough to compile a DOSBox with the basic features. There is a good tutorial on how to do it in Visual Studio 2008 Express Edition. You can find it here and you may wish to consult with it if anything in this tutorial is unclear : http://www.dosbox.com/wiki/Building_DOSBox_with_Visual_C_2008_Express
I am indebted to the author, for this is the way I learned how to compile DOSBox, being a Microsoft loyalist since I first used a PC compatible in the early 90s. You can also use MinGW and MSYS, but that is a Unix/Linux approach utterly foreign to me (and I could never figure it out anyways).
VS2008 is getting a bit old in the tooth, and some of the more modern project files do not really support VS2008. So in this tutorial, I will be using Visual Studio 2010 Express, also freely downloadable from Microsoft. Virtual Studio includes Visual C++. Find it here :
http://www.visualstudio.com/en-us/downloads#d-2010-express
The installer will download the program and the modules it needs and will install them. It will also set file associations for the files we will be using.
2. The Source Code
Now, you need the source code. First start with the current DOSBox SVN, found here :
http://source.dosbox.com/dosboxsvn.tgz
You should use a program like 7zip to uncompress this file. It is doubly compressed. Please see my DOSBox patching guide if you want to add any patches, as you can at this stage :
http://nerdlypleasures.blogspot.com/2014/02/patching-dosbox-for-beginners.html
Next, you will need the Simple Directmedia Layer (SDL) to build libraries that DOSBox needs to function. DOSBox is only compatible with the 1.2 versions and the last version of SDL is 1.2.15. However, you should obtain the source code for 1.2.14, which is the last SDL 1.2 version that will compile easily in VS2010. You can download it here :
http://www.libsdl.org/release/SDL-1.2.14.zip
3. Optional Libraries
If you want to add the optional features to your compiled DOSBox, you will need some more source code to build libraries.
1. For Modem/IPX support, you need SDL_net. SDL_net's mirrors SDL's versions, and the most current version that will compile easily in VS2010 is 1.2.7. Get it here :
http://www.libsdl.org/projects/SDL_net/release/SDL_net-1.2.7.zip
Now what you have obtained above is the easy part. For working screenshots and video recording, you will need to compile libpng and zlib libraries from source. After that, then you compile DOSBox.
For libpng, the current stable source is 1.6.9. You can obtain it here :
http://prdownloads.sourceforge.net/libpng/lpng169.zip?download
You use libpng to compile both libpng.lib and zlib.lib, but for the latter, you need the zlib source code, and specifically 1.2.5 (even though 1.2.8 is the most recent version, but libpng expects 1.2.5). You can obtain 1.2.5 here :
http://www.winimage.com/zLibDll/zlib125.zip
4. Directory Setup
Once you have installed VS2010 and downloaded your source code and libraries, you need to put the source somewhere. Make a folder like \Project and unzip your source code and libraries so they look like this :
\Project\dosboxsvn
\Project\lpng169
\Project\SDL_net-1.2.7
\Project\SDL-devel-1.2.14
\Project\zlib-1.2.5
This will be important for the next step and make it easier to point the compiler to the various include and library files later on.
5. Compiling libpng.lib and zlib.lib
Go to \Project\lpng69\projects\vstudio\libpng and double click on libpng.vcxproj A vcxproj file is a Project File that tells a compiler how to build code. This will start the compiler. You should see Solution Explorer on the left hand side of the program. There are seven projects here, but we only need two of them. Right click on Solution 'vstudio' (7 projects), click on Properties and check the button that says Multiple startup projects: Set libpng and zlib to Start and the rest to None. Press Apply and OK.
Libpng relies on zlib, so we want to make sure zlib is compiled first. Right click on libpng in the Solution Explorer and go to Project Dependencies. In the drop down box, select libpng and make sure there is a checkmark next to zlib in the box below and none on any other box. Then click on the Build Order tab and you should see that zlib comes first and libpng comes second.
Next right click on Solution 'vstudio' (7 projects) and click on Configuration Manager. Under Active solution configuration: click Release Library. In the box below, next to libpng and zlib, change the Configuration to Release Library. For the other options, uncheck the boxes next to the Build so they will not be compiled. Do not worry if they compile anyway, these extra projects are mainly for testing.
Next, in the Solution Explorer right click on libpng and go to properties. On the left hand side, you should see a line called Configuration Properties. On the right side of the window, you will see a line that says Configuration Type. Click on the dropdown box next to it and set it to Static library (.lib) if it is not already.
Then click on VC++ Directories. The window here is a bit small for what you need to do, but be very careful here. Clicking on the wrong thing will wipe out the default directory entries, and if you do that the compiler will not know where to find the code it needs to compile.
Next to the line that says Include Directories, click once on the box after the partition. This will show a down arrow button. Click on that once and then click on
To compile the libraries, hit F7. In the output window, you will see the compiler crunch code and turn it into libpng.lib and zlib.lib. If you succeed, the compiler will indicate where the .lib files are located. If you fail, then the compiler will report an error and your files will not be built. In this example, you can find the .lib files in \Project\lpng169\projects\vstudio\Release Library\ as zlib.lib and libpng16.lib.
6. Compiling SDL and SDL_net
In this guide, I have completely avoided using developer libraries. While there are appropriate Visual C ++ developer libraries that work with VS2010 available for SDL and SDL_net, I think its best to compile your own libraries. Since you have to do this for libpng and zlib, you already should begin to get a feel for how to incorporate include and library directories. Compiling your own libraries can improve DOSBox performance and compatibility with your particular system.
To compile SDL, you will need the DirectX SDK. The DirectX 10 SDK from June 2010 seems compatible, and you can get it here :
http://www.microsoft.com/en-us/download/details.aspx?id=6812
You only need to install the libraries. The installer may give an error if the rest of the components aren't installed, but the libraries will be installed. You will be able to find them typically in C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)
Now, in the SDL-1.2.14 directory, there will be a zip file named VisualC.zip. Unzip it so that you can see files in the next level subdirectory. Go into that subdirectory and open the file SDL.sln. This is a solution file used by older versions of Visual C++ to build a project. VS2010 will run a conversion tool that will convert it into something it can manage properly. Click on Next and then Finish. You may see some warnings but you shouldn't see any errors.
In the resulting Solution Explorer, you will see two projects, SDL and SDLmain, and you will need to compile both of them. First, right click on Solution 'SDL' (2 projects) and go to properties. Then click on the button that says Configuration Manager. From the Active solution configuration: dropdown menu, click on release, and for the Configuration menu drop downs next to SDL and SDLmain, set them both to release. Close the Configuration Manager. At this point, the Configuration dropmenu should show Active(Release). Click on Apply and then OK.
Next, in the Solution Explorer right click on SDL and go to properties. On the left hand side, you should see a line called Configuration Properties. On the right side of the window, you will see a line that says Configuration Type. Click on the dropdown box next to it and set it to Static library (.lib) if it is not already. DOSBox needs the libraries to compile, and SDL should still create an SDL.dll when you compile it.
Then click on VC++ Directories. This is where you add the DirectX SDK libraries you installed at the beginning of this step Next to the line that says Include Directories, click once on the box after the partition. This will show a down arrow button. Click on that once and then click on
On the line that says Library Directories, you are going to do almost the same thing. This time, you want to add the directory for the DirectX SDK Library files. The directory is typically : \Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x86. Make sure you select the x86 (for 32-bit) and not the x64 (64-bit, DOSBox doesn't like 64-bit code). Once you are done, you can press OK to get back to the Solution Explorer. Now press F7 and you should be have created sdl.lib and sdlmain.lib in their respective Release directories, \Project\SDL-1.2.14\VisualC\SDL\Release and \Project\SDL-1.2.14\VisualC\SDLmain\Release
SDL_net requires the SDL libraries, which is why we compiled the SDL libraries first. Like with SDL, you will need to unzip the VisualC.zip file and convert the solution file SDL_net.sln. Set SDL_net to Release in the Configuration Properties.
Open the SDL_net properties page, set the Configuration Type to Static library (.lib) and then click on VC++ Directories. For the Include Directories, you need to add the directory containing the SDL Include files. They can be typically found here : \Project\SDL-1.2.14 Next you need to add the directories containing the SDL Library files. These are \Project\SDL-1.2.14\VisualC\SDL\Release and \Project\SDL-1.2.14\VisualC\SDLmain\Release. You need to add both. After you have done all this, you can exit the properties window and press F7 to compile. You should end up with sdl_net.lib.
7. Setting Up the DOSBox Compiling Environment
Now that you have all your libraries, you can compile as full a DOSBox as you like. Navigate to \Project\dosboxsvn\dosbox\visualc_net and click on dosbox.vcxproj
In the Solution Explorer Window, right click on dosbox. Set the active configuration to Release using the Configuration drop box and the Configuration Manager button first.
In the VC++ Directories, you will need to add the following directories to the Include Directories :
\Project\lpng169
\Project\SDL_net-1.2.7
\Project\SDL-1.2.14\include
\Project\zlib-1.2.5
\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include
If you are compiling code specific to Windows, you may also need to include a directory like :
\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\sys
\Project\lpng169\projects\vstudio\Release Library\
\Project\SDL_net-1.2.7\VisualC\Release
\Project\SDL-1.2.14\VisualC\SDL\Release
\Project\SDL-1.2.14\VisualC\SDLmain\Release
\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x86
On the left side of the Property Page, click on C/C++ and then on General. On the line that says Treat Warnings As Errors, click on the box next to it and set it to No (/WX-) The compiling process will give many warnings, and if this is not set these warnings will cause the build to fail.
Next click on Linker and next to the Force File Output, click on the box next to it and select Multiply Defined Symbol Only (/FORCE:MULTIPLE). Next to the Treat Linker Warning As Errors, click on the box next to it and select No (/WX:NO). These "errors" and warnings are not going to affect a compiled DOSBox, but they certainly will stop DOSBox from compiling correctly.
Finally, underneath Linker, click Input. The following line needs to be present :
dinput8.lib;dxguid.lib;libpng16.lib;sdl_net.lib;opengl32.lib;winmm.lib;sdlmain.lib;sdl.lib;ws2_32.lib;zlib.lib;%(AdditionalDependencies)
Many of these items are already present. You will need to add dinput8.lib and dxguid.lib and rename libpng.lib to libpng16.lib. Since the space is very small, you should check the spelling and formatting very carefully. Each library, including the last, needs a semicolon ; after it.
8. Adjusting the DOSBox Code and compiling
In the Solution Explorer, clock on Source Files and then click on visualc and then double click on config.h. The code listing will appear to the right. If you are not compiling with IPX and Modem support, then change the values from 1 to 0 in the lines :
#define C_MODEM 1
#define C_IPX 1
If you are not compiling with screenshot and video recording support, change the value from 1 to 0 in the
line :
#define C_SSHOT 1
Next, for a speed boost, change the value from 0 to 1 in the line :
#define C_CORE_INLINE 0
Finally, you should see in the Solution Explorer a file called winres.rc. Right click on that and select View Code Change the line that says #include "afxres.h" to #include "Windows.h"
In the Solution Explorer, right click on dosbox, go to properties an then the Configuration Manager. Makes sure the Active solution configuration and the dosbox project configuration are both set to Release, NOT Debug. Release builds are faster than debug builds. Debug DOSBox builds exhibit an annoying issue with the Adlib music where it will stutter unless the cycle count is set very low in DOSBox. After you close the Configuration Manager window, you should see in the Configuration drop down menu Active(Release). Exit the dosbox Property pages.
Now you are ready to compile. Hit F7 and be prepared to wait. If you are successful, you will have a dosbox.exe in \Project\dosboxsvn\dosbox\visualc_net\Release. You probably will not need any .dll files since the libraries should be statically linked within the DOSBox executable, but if you do, you can obtain them from the official 0.74 DOSBox.
DOSBox will generate a .conf file on its first run if one is not present. Look in the status window to find it and move it to the directory in which you will use DOSBox. It is typically buried in AppData on Windows Vista/7/8. It will save screenshots and other captures to a folder named capture, but by default will save them to the same place as it wrote the .conf file.
If you are using Windows 8.1, you will find that the mouse movement will be extremely jerky when using this build. This is due to some changes Microsoft made in handling mouse input. To fix the problem, apply the appropriate patch for your OS (32-bit or 64-bit) from here : http://support.microsoft.com/kb/2908279
Subscribe to:
Posts (Atom)