IBM include a 5-pin DIN cassette port in the IBM PC Model 5150. This was intended for systems sold without floppy disk drives, which were still very expensive in 1981. Until the PC was discontinued in 1987, you could still buy a 5150 from IBM without a floppy disk drive (Model 104).
The 5-pin DIN connector used a TRS-80 cassette cable to connect to a tape recorder deck. The Radio Shack CCR-81 and 82 came with the cables and had both Mic and Aux input jacks. IBM never made a cable for the PC, and the only software it ever supplied was IBM PC Diagnostics and Advanced Diagnostics. Otherwise, use of the cassette port was intended solely for users of Cassette BASIC. Cassette BASIC, built into the system, used its save and load commands to access the cassette drive. In this IBM followed other 8-bit microcomputers of the day, as Cassette storage was the cheapest form of storage available for home computing.
When IBM released the XT, it removed the cassette port circuitry but kept Cassette BASIC in ROM for compatibility with Disk BASIC, Advanced BASIC (BASICA) and programs which relied on any of the three. You could no longer save or load a program in Cassette BASIC. However, IBM also used the same cassette interface logic for the PCjr. This time, IBM released a cable to connect to the unique cassette port on the PCjr.
The IBM PC and PCjr. communicate with the cassette deck via Int 15. At the low level, the audio coming from the deck to the system is digitized and read serially on bit 4 of the 8255 Port C. Audio generated from the system to the deck is generated by 8253 Timer 2, which also controls the PC Speaker and then sent to the cassette. The motor is controlled by bit 3 (and bit 4 in the PCjr) of the 8255 Port B. The BIOS routine writes a 1 bit is with a tone of 1 millisecond (1000Hz), and a 0 bit with a tone of 0.5 millisecond (2000Hz).
To signal the beginning of a program to BASIC, there will be a "leader" of 256 bytes where all the bits are 1, followed by a 0-bit and then ASCII Hex 16. Then a 256-byte data block will be written, followed by a 2-byte Cyclic Redundancy Check, and then more data + CRC blocks until the whole program has been written. The maximum size that can be written is probably close to 64K, since that is the absolute maximum size of a BASIC program on the PC.
Typing SAVE"[program name] will save a BASIC program to the cassette. Typing LOAD"[program name] in Cassette BASIC will instruct BASIC to start the cassette and search for the file. It is up to the user to remember where the program is located. If the system cannot "hear" a program, it will eventually quit trying and give the "Device Timeout" error message. If there is some kind of problem with what it is trying to load, it will say "Device I/O Error." You should keep the volume as high as possible when recording and playing back.
By using the cassette cable, you can record the output of the IBM PC's Speaker without any other adapter hardware. You can of course plug the other end of the cable into a PC instead of a recording deck. It is better to use the audio jack of the PCjr. to record sounds from it, as that jack can record from the PC Speaker, the 3-voice sound chip, the PCjr. Speech Attachment or the audio coming from the cassette.
Using the cassette port is may be a good method to record PC speaker music from a PC, but note that unlike the internal Speaker, the PC will generate a solid tone from the time it signals a system ready beep until software takes control of the PC Speaker.
One program that specifically supports the cassette port is Electronic Arts Music Construction Set. This program has a setting to output 1 note PC Speaker or 4 note (tweaked) PC Speaker music, and has an option to output it to the internal PC Speaker or the cassette port. 4-voice output may sound better through a powered speaker than the internal speaker, but the basic sound will be the same.
One issue with the PC and PCjr. is that both support being connected to the Mic or Aux input of a tape deck. The PC does so via a jumper on the system board near the PC Speaker header. The jumper block is a 2x2 block. If the jumper is placed across the pins closest to the M silkscreened on the board, then the audio will be sent at a level appropriate for a Mic Input. If the jumper is placed across the pins closest to the A silkscreened on the board, then the audio will be sent at a level appropriate for a Line Input. The PCjr sends both the Mic and Aux input lines to the C connector, but the official cable only uses the Aux line. Some modern cassette recorders only come with a Mic Input.
Sunday, April 20, 2014
The Aztech Labs Sound Galaxy Nova Pro16 Extra
I found this card installed in a 386/486 vintage Packard Bell. I took it as it looked interesting.
The card has had the DAC/ADC functionality of a Sound Blaster 2.0, a UART compatible MPU-401, a gameport, a Yamaha OPL3 chip and also is Microsoft Windows Sound System compatible. It has a line in, a mic in, a line out and an amplified out (for headphones or unpowered speakers) and a gameport.
The card is set either via software or EEPROM, which is mostly jumper selectable. All but one jumper has its function marked on the card, and there are four :
J1 - PC Speaker Amplification - Closed = High, Open = Low
JX1 - Microphone Type - 1-2 Closed = Condenser, 2-3 Closed = Carbon
JMPCFG - Configuration Type - 1-2 Closed = EEPROM setting, 2-3 Closed = Software setting
JMPBO - Base Address - 1-2 Closed = 220H, 2-3 Closed = 240H.
There are DOS configuration utilities buried in its Windows drivers. They will be in the directory with the file, EASYSTAR.EXE, which functions as a gateway to the audio configuration and testing programs and the mixer application. If you know the settings, no drivers need be loaded on bootup. The HWSET utility can be used to set the IRQ and DMA values and should be used to set the mixer values, as the EEPROM will not store the mixer values, despite what the MIXTSR program says.
There are headers on the card for CD-in (4-pin white connector), Modem-in (4-pin blue connector), multimedia PC speaker (4-pin header) and a Waveblaster-compatible MIDI card.
The mixer functionality allows for 16 volume levels for the Master Volume, CD/Line In, FM/Wavetable, Sound Blaster Voice (DAC) and Microphone. All but the microphone can have the volume of the left and right channels independently selected.
The UART MPU-401 uses a separate resource setting than the Sound Blaster or Windows Sound System.
The Sound Blaster and the MPU-401 can use either IRQ 2/9, 3, 5 or 7, but will not share an IRQ. The card uses DMA 1 for the Sound Blaster and DMA 3 for the Microsoft Windows Sound System, and neither can be changed. Like a real SB 2.0, it can be set to I/O 220 or 240 only. Similarly, like the SB 16, the MPU-401 port can be set to I/O 330 or 300.
The Microsoft Windows Sound System can be set to I/O 530, 604, E80 & F40. It can use IRQ 2, 7, 10 or 11 and DMA 0, 1 or 3. I believe it uses DMA 3 and IRQ 10. The Galaxy drivers insert the following line in AUTOEXEC.BAT :
SET GALAXY=A220 I7 D1 K10 P530 T6
There are three proprietary CD-ROM interfaces on the card, Panasonic, Sony and Mitsumi.
The Microsoft Windows Sound System, MPU-401 and game port can be disabled.
The 16-bit portion of the card is used only for the extra IRQ and DMA signals for the CD-ROM interfaces. They can use IRQ 11, 12 or 15 and DMA 0 or 3. Otherwise the card should work in an 8-bit slot.
One warning about this card, when it grabs an IRQ, it does NOT like to play nice. If you set its IRQ to the mouse's IRQ, for example, your mouse cursor will stop working. There is a TSR in the DOS utilities to provide for some level of Sound Blaster Pro compatibility, but it will not provide stereo panning support for Wolfenstein 3D. The headphone output is really noisy, with lots of hiss. The game port is as speed sensitive as a real pre-16 Sound Blaster, so in a fast 386 or a 486 system you will probably want to use something else.
Wednesday, April 16, 2014
Simple Soldering Mods for Vintage PC Components
There are some simple, yet extremely useful modifications you can perform to some vintage PCs and cards using a soldering iron and a bit of solder or a few wires. In this post, I am going to outline some well-known, highly useful modifications requiring soldering no more than three wires or chips. Of course, you should have a solder sucker or desoldering braid to repair any mistakes.
Before I detail the mods, there is a debate between lifting pins and cutting traces. In my opinion, its easier to cut a trace than it is to lift a pin. I once broke a pin off an IC and had to remove and replace the whole IC. Cut traces can easily be repaired by wiring the two pins connected by that trace together.
IBM XT & Portable 640KB System Board
All IBM XTs and Portables use the same basic motherboard design. For those motherboards marked 64KB-256KB System Board, there is an empty socket at U84. These Boards were intended to support only 256KB, but through a very easy mod and a chip replacement, they can all support 640KB on the motherboard. This is the maximum amount of RAM that an 8-bit PC compatible is designed to use and it saves an expansion slot.
First, fit a 74LS158 chip into the U84 socket. Second, replace the 64Kx1 DRAM chips in banks 0 & 1 with 256Kx1 chips, 150ns or better. That is 18 chips (since the XT uses parity memory). If banks 2 & 3 are empty, you can put those 64kx1 chips in those sockets. Third, bridge the two points marked with an E2 on the motherboard. It is near the power supply. You just need solder and maybe a bit of wire to make the connection, because this is not a mod you are likely to want to reverse. Finally, set switches 3 & 4 to the Off position if you haven't already done so. This informs the system that all four banks of memory are populated. More detailed instructions are here :
http://www.uncreativelabs.net/textfiles/hardware/XTMB640K.MOD
IBM Bidirectional Parallel Port
The IBM 8-bit cards all had a unidirectional parallel port, but could be modified to support a basic PS/2-style bidirectional port with one wire. To do this, you need to solder pin 1 of the appropriate 74LS374 to pin 15 of the appropriate 74LS174. You also need to cut away the trace that connects pin 1 of the 74LS374 to ground or lift the pin out of its solder hole. Here are the correct chip numbers for each card :
IBM PC Monochrome Display and Printer Adapter :
74LS374 - U41
74LS174 - U39
IBM PC Printer Adapter :
74LS374 - U4
74LS174 - U7
IBM PC AT Serial/Parallel Adapter :
74LS374 - U18
74LS174 - U4
IBM PCjr. Parallel Printer Attachment :
74LS374 - ZM4
74LS174 - ZM11
Hercules Graphics Card (long, 13" version)
74LS374 - U32
74LS174 - U22
AST Six Pak Plus Type 1
74LS374 - U73
74LS174 - U81
74LS374 - U76
74LS174 - U71
IBM LPT2 Parallel Port
The IBM Parallel cards, with the exception of the IBM PC AT Serial Parallel Adapter, are set to use only one set of addresses. The IBM PC Monochrome Display and Printer Adapter uses addresses at 3BC-3BF and these should never be changed. The BIOS will always assign LPT1 to a Monochrome card's parallel port, and the port must be at those addresses. For the standalone parallel adapters, while they are set at 378-37F, they can be changed to use 278-27F. The BIOS will assign LPT1 (assuming no mono card is in the system) to the parallel port at 378 and LPT2 to the parallel port at 278.
To make the IBM PC Printer Adapter use address starting at 278, you need to cut the trace connecting J1. To reverse this, you need to solder a pair of staking pins to the pads at J1 and place a jumper over them. Some solder sucker should be used to obtain clean holes first.
To change the address on a IBM PCjr. Parallel Printer Attachment, there are two traces that need to be cut and two wires soldered. The instructions are here : http://www.brutman.com/PCjr/lpt2_mod.html
IBM CGA Thin-font
The IBM CGA card contains two character sets or fonts in its character generator ROM. The standard font is the thick-font, which was designated as the default font because the characters were much easier to see on a TV screen or a composite monochrome monitor. There is also a thin font available by connecting the two solder pads just below pins 1 & 2 of the 6845 CRTC chip. Solder in a two-pin header and you can use a jumper to switch between the two.
IBM PCjr. Tandy-mod
One of the most popular modifications to enhance the PCjr.'s graphical capabilities is to install the Tandy mod. This mod, which requires one common 74 series TTL chip, cutting a trace and soldering three wires, is relatively easy to do. With the mod, the problem of the Venetian Blinds with games only supporting Tandy 320x200 and 640x200 (if there are any) graphics will go away. This will fix many games. The best instructions can be found here : http://vintagemashups.net/2011/12/ibm-pcjr-tandy-1000-graphics-mod/
So, shouldn't all PCjr.'s have this mod installed? Well, in my opinion, a PCjr. should be used and maintained as a unique computer, not an ersatz Tandy 1000. Unlike the Tandy 1000s with their speed options (7.16MHz 8088s to 10MHz 80286s), the PCjr. is stuck at 4.77MHz as a practical matter. Even installing a V20 and RAM above 128KB is not going to provide the speed necessary to run many games at a good speed which use the ubiquitous graphics 320x200x16c Mode 09h. While it is possible to increase the clock speed of a PCjr. above 4.77MHz, the modification is much more involved than the Tandy mod and the results are not very reliable above 7.37MHz.
In addition, the Tandy mod does not solve all compatibility problems that a game specifically supporting only Tandy graphics and sound would have on the PCjr. A review of the technical references of the Tandy 1000 and the PCjr. (available online) shows many differences in their respective graphics registers. Their keyboard handling at the hardware level is very different. Even their sound chips (the PCjr, uses a true TI SN76496, the Tandys typically use a NCR 8496 clone, discrete or integrated) have their differences.
In short, if you have or intend to acquire a Tandy 1000, leave your PCjr. alone. If you have no interest or desire for a Tandy 1000 machine, then by all means consider the mod, but
CMOS Battery Replacement
CMOS batteries typically give 3-6V. They generally come in three varieties for generic motherboards, the Dallas 1287 or 12887 RTC module, the barrel-type and the CR2032 coin-style with holder. Each variety was common until the Pentium era, where the coin-style battery holder became ubiquitous. The CR2032s can be readily replaced, because only the holder is soldered to the board. The Dallas RTC module has a battery built-in that will eventually fail. In these cases, the part is typically socketed and can be replaced. A coin-style battery holder can be soldered to the appropriate legs, thereby extending the life of the part indefinitely. A sharp hobby knife, or better still a dremel, will be needed to cut away enough of the plastic to expose the "thick" portion of the legs to solder the battery holder terminals. Detailed instructions can be found here : http://www.mcamafia.de/mcapage0/dsrework.htm or here : http://www.classic-computers.org.nz/blog/2009-10-10-renovating-a-dallas-battery-chip.htm
The barrel style batteries are the most annoying of the bunch. Too frequently they corrode and leak, causing damage to the motherboard. If you buy a motherboard with one, remove it immediately, even if it hasn't leaked. Remove the leads from the motherboard using solder braid or a solder sucker, or simply solder the battery holder terminals to the extended leads. Some of the barrel batteries are Ni-Cd rechargeable types, and standard batteries will not take the recharge current. With a bit of searching, you can find modern Ni-MH barrel-style batteries that will work as a direct replacement. Here is an example : http://www.jameco.com/1/1/48175-5560830312-nimh-rechargable-batteries-3-6v-rechargeable.html
If you want to instead solder a battery holder, you will need to wire a schottky diode in between the battery's + terminal and the motherboard's + point to prevent the current from going from the motherboard to the battery.
If you do not want to solder a battery clip, some motherboards have a pin header to connect an external battery. There are 3xAA and 4xAA battery holders with 2-pin or 4-pin connectors ideal for the task. 3xAA is 4.5v, which is quite sufficient to power CMOS, but 2xAA is only 3v, which is the bare minimum. 3 and 4 battery holders will last longer.
Before I detail the mods, there is a debate between lifting pins and cutting traces. In my opinion, its easier to cut a trace than it is to lift a pin. I once broke a pin off an IC and had to remove and replace the whole IC. Cut traces can easily be repaired by wiring the two pins connected by that trace together.
IBM XT & Portable 640KB System Board
All IBM XTs and Portables use the same basic motherboard design. For those motherboards marked 64KB-256KB System Board, there is an empty socket at U84. These Boards were intended to support only 256KB, but through a very easy mod and a chip replacement, they can all support 640KB on the motherboard. This is the maximum amount of RAM that an 8-bit PC compatible is designed to use and it saves an expansion slot.
First, fit a 74LS158 chip into the U84 socket. Second, replace the 64Kx1 DRAM chips in banks 0 & 1 with 256Kx1 chips, 150ns or better. That is 18 chips (since the XT uses parity memory). If banks 2 & 3 are empty, you can put those 64kx1 chips in those sockets. Third, bridge the two points marked with an E2 on the motherboard. It is near the power supply. You just need solder and maybe a bit of wire to make the connection, because this is not a mod you are likely to want to reverse. Finally, set switches 3 & 4 to the Off position if you haven't already done so. This informs the system that all four banks of memory are populated. More detailed instructions are here :
http://www.uncreativelabs.net/textfiles/hardware/XTMB640K.MOD
IBM Bidirectional Parallel Port
The IBM 8-bit cards all had a unidirectional parallel port, but could be modified to support a basic PS/2-style bidirectional port with one wire. To do this, you need to solder pin 1 of the appropriate 74LS374 to pin 15 of the appropriate 74LS174. You also need to cut away the trace that connects pin 1 of the 74LS374 to ground or lift the pin out of its solder hole. Here are the correct chip numbers for each card :
IBM PC Monochrome Display and Printer Adapter :
74LS374 - U41
74LS174 - U39
IBM PC Printer Adapter :
74LS374 - U4
74LS174 - U7
IBM PC AT Serial/Parallel Adapter :
74LS374 - U18
74LS174 - U4
74LS374 - ZM4
74LS174 - ZM11
Hercules Graphics Card (long, 13" version)
74LS374 - U32
74LS174 - U22
AST Six Pak Plus Type 1
74LS374 - U73
74LS174 - U81
AST Six Pak Plus Type 2 or Type 3
74LS374 - U76
74LS174 - U71
The IBM Parallel cards, with the exception of the IBM PC AT Serial Parallel Adapter, are set to use only one set of addresses. The IBM PC Monochrome Display and Printer Adapter uses addresses at 3BC-3BF and these should never be changed. The BIOS will always assign LPT1 to a Monochrome card's parallel port, and the port must be at those addresses. For the standalone parallel adapters, while they are set at 378-37F, they can be changed to use 278-27F. The BIOS will assign LPT1 (assuming no mono card is in the system) to the parallel port at 378 and LPT2 to the parallel port at 278.
To make the IBM PC Printer Adapter use address starting at 278, you need to cut the trace connecting J1. To reverse this, you need to solder a pair of staking pins to the pads at J1 and place a jumper over them. Some solder sucker should be used to obtain clean holes first.
To change the address on a IBM PCjr. Parallel Printer Attachment, there are two traces that need to be cut and two wires soldered. The instructions are here : http://www.brutman.com/PCjr/lpt2_mod.html
IBM CGA Thin-font
The IBM CGA card contains two character sets or fonts in its character generator ROM. The standard font is the thick-font, which was designated as the default font because the characters were much easier to see on a TV screen or a composite monochrome monitor. There is also a thin font available by connecting the two solder pads just below pins 1 & 2 of the 6845 CRTC chip. Solder in a two-pin header and you can use a jumper to switch between the two.
IBM PCjr. Tandy-mod
One of the most popular modifications to enhance the PCjr.'s graphical capabilities is to install the Tandy mod. This mod, which requires one common 74 series TTL chip, cutting a trace and soldering three wires, is relatively easy to do. With the mod, the problem of the Venetian Blinds with games only supporting Tandy 320x200 and 640x200 (if there are any) graphics will go away. This will fix many games. The best instructions can be found here : http://vintagemashups.net/2011/12/ibm-pcjr-tandy-1000-graphics-mod/
So, shouldn't all PCjr.'s have this mod installed? Well, in my opinion, a PCjr. should be used and maintained as a unique computer, not an ersatz Tandy 1000. Unlike the Tandy 1000s with their speed options (7.16MHz 8088s to 10MHz 80286s), the PCjr. is stuck at 4.77MHz as a practical matter. Even installing a V20 and RAM above 128KB is not going to provide the speed necessary to run many games at a good speed which use the ubiquitous graphics 320x200x16c Mode 09h. While it is possible to increase the clock speed of a PCjr. above 4.77MHz, the modification is much more involved than the Tandy mod and the results are not very reliable above 7.37MHz.
In addition, the Tandy mod does not solve all compatibility problems that a game specifically supporting only Tandy graphics and sound would have on the PCjr. A review of the technical references of the Tandy 1000 and the PCjr. (available online) shows many differences in their respective graphics registers. Their keyboard handling at the hardware level is very different. Even their sound chips (the PCjr, uses a true TI SN76496, the Tandys typically use a NCR 8496 clone, discrete or integrated) have their differences.
In short, if you have or intend to acquire a Tandy 1000, leave your PCjr. alone. If you have no interest or desire for a Tandy 1000 machine, then by all means consider the mod, but
CMOS Battery Replacement
CMOS batteries typically give 3-6V. They generally come in three varieties for generic motherboards, the Dallas 1287 or 12887 RTC module, the barrel-type and the CR2032 coin-style with holder. Each variety was common until the Pentium era, where the coin-style battery holder became ubiquitous. The CR2032s can be readily replaced, because only the holder is soldered to the board. The Dallas RTC module has a battery built-in that will eventually fail. In these cases, the part is typically socketed and can be replaced. A coin-style battery holder can be soldered to the appropriate legs, thereby extending the life of the part indefinitely. A sharp hobby knife, or better still a dremel, will be needed to cut away enough of the plastic to expose the "thick" portion of the legs to solder the battery holder terminals. Detailed instructions can be found here : http://www.mcamafia.de/mcapage0/dsrework.htm or here : http://www.classic-computers.org.nz/blog/2009-10-10-renovating-a-dallas-battery-chip.htm
The barrel style batteries are the most annoying of the bunch. Too frequently they corrode and leak, causing damage to the motherboard. If you buy a motherboard with one, remove it immediately, even if it hasn't leaked. Remove the leads from the motherboard using solder braid or a solder sucker, or simply solder the battery holder terminals to the extended leads. Some of the barrel batteries are Ni-Cd rechargeable types, and standard batteries will not take the recharge current. With a bit of searching, you can find modern Ni-MH barrel-style batteries that will work as a direct replacement. Here is an example : http://www.jameco.com/1/1/48175-5560830312-nimh-rechargable-batteries-3-6v-rechargeable.html
If you want to instead solder a battery holder, you will need to wire a schottky diode in between the battery's + terminal and the motherboard's + point to prevent the current from going from the motherboard to the battery.
If you do not want to solder a battery clip, some motherboards have a pin header to connect an external battery. There are 3xAA and 4xAA battery holders with 2-pin or 4-pin connectors ideal for the task. 3xAA is 4.5v, which is quite sufficient to power CMOS, but 2xAA is only 3v, which is the bare minimum. 3 and 4 battery holders will last longer.
Saturday, April 12, 2014
Tandy 1000TX vs. 1000TL
The Tandy 1000TX was released in 1987. Its successor, the Tandy 1000TL was released in 1988. The TL was mainly a refresh of the earlier machine, with some enhancements. However, in its efforts to become more PC compatible, some things were lost. Let's compare each machine.
Consider what both machines possessed in common :
80286 CPU @ 8MHz in PLCC Socket
80287 Socket
5 ISA Slots
65W Power Supply
640KB built-in/768KB upgradeable
Lets look at some features :
Video :
TX - Composite Video Output
TL - 640x200x16c and MDA/Hercules Graphics Emulation
Composite video is useful to record
video from the computer, since there are many, many devices that will
record a composite video signal, even a not-quite standard signal
that the Tandy outputs. It is also works very well with games that use a true (Maniac Mansion, Starflight) or effective (King's Quest) 160x200x16c graphics mode. In this mode, there is minimal artifacting and the colors presented are generally close to their RGB counterparts. True composite artifact color games, generally made for the IBM CGA card, will show incorrect colors which no amount of fiddling with the tint control will perfectly fix. Still, the results will look much better than on an RGB monitor. However, recordings using the 320x200x16c mode will not look great, because the composite video signal does not have the bandwidth to keep up with the color changes. The TX can also support a true 200-line 80 column text mode. The TL will display a rolling screen using the MODE 200 command that came with the system disks. You can use an updated MODE.COM from the RL system disks.
The Tandy 640x200x16c mode was rarely used in games, and those games also supported the corresponding EGA mode and all of the known games support VGA as well. Deskmate 3's draw application uses it, but Deskmate 3 does have VGA and probably EGA drivers. The built-in graphics controller can also emulate MDA/Hercules, but there are three issues with it. First, if you use the machine as an MDA/Hercules card, you will also need a TTL monochrome monitor like the IBM 5151. Second, since there is only one video output port, using MDA/Hercules disables the built-in Tandy graphics support, as you cannot see it anyway with the MDA monitor connected to the port. Third, some games will detect a Tandy 1000 and insist on using the Tandy or CGA graphics modes. It can be useful if you have upgraded to VGA, but then you could simply obtain a generic system for a VGA/MDA combo.
The TX can add a MDA or Hercules card and retain the ability to output Tandy graphics to a separate video monitor. Still, some games will autodetect Tandy and not work correctly with the Hercules card.
While both the TX and TL support upgrading to an EGA or 8-bit compatible VGA card, there is a very nice utility called VSWITCH that will allow you to switch between the built-in Tandy video and VGA. More recently, someone made a similar program called ESWITCH for EGA cards. However, due to the differences in disabling the built-in video on the TX and the TL, the program only works in the TL or later Tandy 1000s with 768KB of RAM.
The TX can add a MDA or Hercules card and retain the ability to output Tandy graphics to a separate video monitor. Still, some games will autodetect Tandy and not work correctly with the Hercules card.
While both the TX and TL support upgrading to an EGA or 8-bit compatible VGA card, there is a very nice utility called VSWITCH that will allow you to switch between the built-in Tandy video and VGA. More recently, someone made a similar program called ESWITCH for EGA cards. However, due to the differences in disabling the built-in video on the TX and the TL, the program only works in the TL or later Tandy 1000s with 768KB of RAM.
Advantage - Tie
Audio :
TX - 3 Voice Sound & Sound Blaster 1.0-2.0 Support
TL - 3 Voice Sound & built-in DAC/ADC
While the TX only has the basic 3 voice chip, it also can work with a Sound Blaster 1.0-2.0, or any other 8-bit sound card that only works with DMA1. Many early Sound Blaster-supporting titles only work if the card is at IRQ7 and DMA1. However, because the built-in joystick port cannot be disabled in software, the gameport of the Sound Blaster must be disabled.
The TL has a very decent mono DAC built in, which can use the internal speaker for output. The ADC can sample at a higher rate than a Sound Blaster 2.0, but in the TL it is speed sensitive. While this is immaterial to Tandy Deskmate, third-party programs may have difficulty with recording. Some early games like SimCity and Outrun only support the Tandy DAC and not Sound Blaster. Overall, many more games support a Sound Blaster than the Tandy DAC.
The DAC was never released as an add-on card, so at its original ports (where many games expect it) it is unique to the 1000 TL and SL and successors up to and including the RLX. The TL's joystick port can be disabled in software, but using a Sound Blaster 1.0 or 2.0 will cause the system to freeze if the Tandy DAC is used. Using a Sound Blaster Pro, with the DMA channel set to 3 and the IRQ set to 5, would allow the Sound Blaster and Tandy DAC to work fine. Many early games refuse to work with a Sound Blaster unless the DMA is set to 1. Additionally, the DAC and the built-in joystick ports cannot be used at the same time, so a game supporting the DAC is not likely to read the joystick port, built-in or on an expansion card, while using the DAC.
The DAC was never released as an add-on card, so at its original ports (where many games expect it) it is unique to the 1000 TL and SL and successors up to and including the RLX. The TL's joystick port can be disabled in software, but using a Sound Blaster 1.0 or 2.0 will cause the system to freeze if the Tandy DAC is used. Using a Sound Blaster Pro, with the DMA channel set to 3 and the IRQ set to 5, would allow the Sound Blaster and Tandy DAC to work fine. Many early games refuse to work with a Sound Blaster unless the DMA is set to 1. Additionally, the DAC and the built-in joystick ports cannot be used at the same time, so a game supporting the DAC is not likely to read the joystick port, built-in or on an expansion card, while using the DAC.
Advantage - TX
Drive Bays :
TX - 2 x 5.25” slots
TL - 1 x 5.25” slot & 2 x 3.5” slots
Two 5.25" slots allows for more flexibility than one 5.25" and two 3.5" slots. If you wanted to install a 5.25 floppy drive and internal CD-ROM, you could do so in a TX but not a TL. However, the TL offers a more appropriate setup of one bay for a 3.5" floppy drive, one for a 5.25" floppy drive and one for a 3.5" hard drive. With a TX, you would need to use a hardcard. The 3.5" bays on the TL are not generally useful for external drives because the faceplate is moulded into a certain shape and cutout. The faceplate is made of plastic, so it can be dremeled out.
Advantage - TL
Keyboard Support :
TX - Tandy 1000 90-Key Keyboard or Northgate Omnikey 101-Key Keyboard (with adapter)
TL - Tandy Enhanced 101-Key Keyboard or Tandy 1000 90-Key Keyboard (with adapter)
The Tandy 1000 Keyboard has 90 keys and is slightly awkward to use from a modern perspective. The keys use springs, but feel mushy. The interface is proprietary to the 1000TX and earlier 1000 machines and the Tandy 2000.
The Tandy Enhanced keyboard has the standard 101-key layout, but feels too stiff. The keyboard can automatically switch into XT or AT mode, and can work an IBM PC Model 5150 or a 2014 motherboard with a PS/2 port.
The TX can use a Northgate Omnikey keyboard with a special passive adapter cable for 101-key support. You will not be able to use the F1-F4 function keys when booting with the Northgate.
The TL can use a 1000 Keyboard, with a special passive adapter cable. The TL can use any keyboard that supports XT operation, including the IBM PC Model F keyboard and the IBM Model M keyboards made prior to 1993. However, there are some games that expect a 1000 keyboard and will refuse to work at all (Snow Strike) or freeze (King's Quest Tandy booter) if the wrong key is pressed with a standard XT keyboard.
The Tandy Enhanced keyboard has the standard 101-key layout, but feels too stiff. The keyboard can automatically switch into XT or AT mode, and can work an IBM PC Model 5150 or a 2014 motherboard with a PS/2 port.
The TX can use a Northgate Omnikey keyboard with a special passive adapter cable for 101-key support. You will not be able to use the F1-F4 function keys when booting with the Northgate.
The TL can use a 1000 Keyboard, with a special passive adapter cable. The TL can use any keyboard that supports XT operation, including the IBM PC Model F keyboard and the IBM Model M keyboards made prior to 1993. However, there are some games that expect a 1000 keyboard and will refuse to work at all (Snow Strike) or freeze (King's Quest Tandy booter) if the wrong key is pressed with a standard XT keyboard.
Advantage - Tie
Real Time Clock :
Installable RTC
Built-in RTC
The TL has a standard RTC and uses a replaceable CR2032 coin battery. The TX requires a no-slot clock like the Dallas 1216E, which has a built-in battery and is seated under a ROM socket. The height added by the clock chip can make the slot next to it suitable for only short cards. Tandy DOS 3.3 has built-in support for the TL's clock, the TX requires an upgrade.
Advantage - TL
Heavy Shielding inside Case
No Shielding inside Case
The TX has shielding virtually all around the motherboard, making the internal slots and jumpers difficult to get to. It's case cover is plastic. The TL apparently solved any RFI problems of the older machine by using a metal case cover, because there is no shielding getting in the way.
Advantage - TL
Configuration and Built-in Software :
Basic BIOS & Jumpers
DOS & Deskmate in ROM, EEPROM
Settings
The TX is configured by eight jumpers or dipswitches. The TL has five functional jumpers/dipswitches, the rest is configured by a program included on the DOS disks. The TX uses Function Keys, pressed on startup, to use the monochrome mode, swap floppy drives, use the 40-column/200 line TV mode and set the processor to low speed.
The TL does all but the TV mode via the setup program. The settings are written to an EEPROM. If that EEPROM fails...
The TL does all but the TV mode via the setup program. The settings are written to an EEPROM. If that EEPROM fails...
The TL also has a portion of DOS and Deskmate 3 in ROM. This is only useful if you do not have a hard drive. If you have a hard drive, then the DOS on that will boot and a standalone version of Deskmate may be required to be installed.
Advantage - Tie
Advantage - Tie
Bundled Software :
TX - Personal Deskmate 2 & DOS 3.2
TL - Deskmate 3.2 & DOS 3.3
DOS 3.3 is better than DOS 3.2, there is no doubt about it. Since neither the TX nor TL can support a high density floppy drive with its built-in controller, the best quality DOS 3.3 brings is its support for more than one 32MB hard drive partition. However, the TX can use Tandy DOS 3.3 without any difficulty. Deskmate 3 looks similar to Personal Deskmate 2, but 3rd party programs can easily be installed to it. Of course, you can upgrade the TX to Deskmate 3. On the TL, Deskmate 3 has music and sound programs in the ROM. The music programs in Personal Deskmate 2 and Deskmate 3 should share compatible files. However, the DOS installable version of Deskmate 3 does not come with the music program, so you will need to keep Personal Deskmate 2 for that on the TX.
Memory Upgrade :
The TX and TL both allow their memory to be upgraded from 640KB to 768KB, and when upgraded the video no longer encroaches on the conventional memory. DOS will report 640KB available. Both are upgraded in the same way, by adding four 64Kx4 DRAM chips. The TL automatically will detect the chips, the TX requires a jumper to be removed. However, the upgrade is incompatible with certain programs (detailed in a later post), forcing you to use CGA modes for those games. To disable the upgrade, you must physically remove the chips in the TL, but you only need replace the jumper in the TX.
Advantage - TX
Memory Upgrade :
The TX and TL both allow their memory to be upgraded from 640KB to 768KB, and when upgraded the video no longer encroaches on the conventional memory. DOS will report 640KB available. Both are upgraded in the same way, by adding four 64Kx4 DRAM chips. The TL automatically will detect the chips, the TX requires a jumper to be removed. However, the upgrade is incompatible with certain programs (detailed in a later post), forcing you to use CGA modes for those games. To disable the upgrade, you must physically remove the chips in the TL, but you only need replace the jumper in the TX.
Advantage - TX
Sunday, March 30, 2014
The Blog at 100 (Posts)
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.
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.
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.
Subscribe to:
Posts (Atom)