Somethings things just don’t make much sense. Like this, for example:
What’s unusual about an ISA sound card with a wavetable daughterboard? Nothing. But experts will recognize that the host card is a Terratec Maestro 32/96, which already has a built in-synth.
There oddest things about this setup is that the host card’s synth is essentially a superset of the one on the daughterboard. For that reason, the daughterboard’s presence has very questionable utility. Continue reading →
While digging into the implementation of Sound Blaster compatibility on PCI cards, I found an unexpected gem. Ensoniq’s U.S. Patent 5,790,837 includes partial source code for the Sound Blaster emulation driver used with the Ensoniq Soundscape VIVO boards, SSINIT.COM.
Ensoniq Soundscape VIVO
The VIVO boards were Ensoniq’s last ISA-based product (introduced in 1995) and shared a common trait with the PCI-based ES1370 and later devices: There was no hardware Sound Blaster compatibility. Instead, Sound Blaster digital audio as well as AdLib FM synthesis were emulated.
Now the VIVO was a bit of a mixed bag. While the Sound Blaster compatibility wasn’t bad, it required EMM386 and a TSR and was therefore fundamentally incompatible with certain games. The AdLib emulation was not so much emulation as approximation, as it tried to replace a FM synth with wavetable synthesis, with mixed results. On the upside, the wavetable synth (1MB ROM) was not at all bad, and the cards were cheap (and therefore used in many OEM systems). Continue reading →
As previously mentioned, the Wave Blaster II (aka WB2) documentation makes no mention of possible bidirectional MIDI communication. But while trying the Wave Blaster II control panel with various host cards out of desperation, an interesting thing happened: When attempting to go to the preset screen, I was informed that I couldn’t because “MIDI In is currently busy”.
Now that’s interesting because the MIDI implementation chart for WB2 makes absolutely no mention that the device might send anything. Then again the chart does not list system exclusive messages (SysEx) at all.
A quick look at WP2CPL.EXE with a disassembler confirmed that the control panel preset dialog only opens if the device responds to a SysEx. What does the SysEx do? Continue reading →
I have continued to dig into the mysteries of Wave Blaster (WB) connectors, daughterboards, and DB-50XG MIDI. To recap, the objective is to find how to convince a Yamaha DB-50XG to send MIDI data, if at all possible.
A closer look at a DB-50XG confirmed that both MIDI IN and OUT are definitely connected. Pins 4 and 8 of the WB connector are connected to pins 15 and 16 (I think!) of the Hitachi H8/3002 MPU. Those are the Rx and Tx pins, so that makes good sense. The signals are routed all around the daughterboard.
So technically a DB-50XG is definitely capable of outputting MIDI data. Whether it can actually do it is a different question. Without detailed documentation or a firmware dump I’m just guessing.
Even if it does work, the next question is whether bi-directional MIDI communication is possible on a typical PC sound card with a WB connector. But there’s more about that too. Continue reading →
A T4x ThinkPad with a supervisor password is a ticking time bomb. The password is not needed during boot and is only required to change certain BIOS settings, something which isn’t typically needed. But if CMOS settings are lost, the BIOS setup must be entered and the SVP will be required.
That’s exactly what happened to me. I had an old T42p (2.0 GHz Pentium M) with unknown SVP, happily working. Then somehow the CMOS got scrambled. I have no idea why, because the backup battery still seems fine. At any rate, the SVP was required and I didn’t know it. Bricked.
To recover the password, it can be read from an EEPROM but then has to be decoded. That may or may not work. Or a $100+ USB gadget can be procured—worthless for a single use because a replacement T42p system board would cost less. Or the EEPROM could be desoldered and replaced with a “good” password-less one (which I don’t have). Neither option seemed appealing so the T42p was sitting around gathering dust for a while.
Then a kind reader posted this link. Clearing the password with no special tools and no soldering? What could possibly go wrong… Continue reading →
I seem to have embarked on another crazy research project. It was spurred by a broken Yamaha DB-50XG wavetable daughterboard. The DB-50XG was a bit dirty but not obviously damaged. It produces no output but gets warm exactly like a functioning specimen, so it shouldn’t be completely blown.
DB-50XG (not broken)
But because there’s no obvious damage, I don’t know where to start looking for defects. It could be that the MIDI IN signal doesn’t even arrive, or the digital part is damaged, or the analog part isn’t working… lots of possibilities. So I thought, if I could get the daughterboard to send some MIDI data back, I’d at least know that the MIDI processing stages work, right?
Well… after a few days of poking around, I still don’t know if it’s even theoretically possible, let alone how to do it. Let’s list the various obstacles… Continue reading →
On some systems, it has been observed that Solaris 7 panics during boot from installation media and reboots the system. At least Solaris 7 U1 (3/99) and U4 (11/99) are affected. Only “fast” systems (definitely including Sandy Bridge 3+ GHz processors) exhibit this problem, and the exact behavior depends on hardware configuration.
When booting with kadb, the system doesn’t reboot itself and the panic information can be easily read:
A while ago I tried to set up Voodoo 2 SLI on an old Pentium system running Windows 98 SE. I used two seemingly identical Creative CT6670 boards (Voodoo 2, 12 MB RAM) which should have worked just fine. But didn’t—SLI wasn’t detected, and strangely, one of the boards seemed to not have Creative Voodoo 2 drivers loaded.
When I looked more closely (with the Win98 system information utility), I realized that one of the boards was recognized as a Voodoo 1 based on its PCI ID. How is that possible? Continue reading →
In the late 1980s and the early 1990s, the so-called Bus Wars raged. A few years after the PC/AT was released, it became clear that the ISA bus could not keep pace with faster CPUs and peripherals, especially graphics cards and SCSI HBAs.
IBM’s solution, Microchannel or MCA (1987) was technically excellent, radical, and ultimately a failure. Compaq and the “gang of nine” bet on EISA (1989), a less ambitious but in many ways very similar bus with one major difference—backwards compatibility. EISA was in practice even less successful than MCA and practically unheard of outside of servers and some workstations.
Around 1992, the VESA committee standardized the VESA Local Bus or VLB, geared towards but by no means limited to graphics cards, and designed primarily for the 486’s local bus. For about two years, VLB was very successful and graphics cards designed for VLB were unbeatable.
Around the same time, Intel worked on PCI, a bus which successfully learned from past mistakes. In late 1993, the first PCI systems and adapters became available, and PCI in combination with Pentium systems very quickly destroyed all competition.
For a short while, all five buses (ISA, MCA, EISA, VLB, PCI) existed in the market. Some adapters were available in two or three bus variants and a precious few went all the way. One of those was ATI’s mach32 graphics chip and the adapters based on it, Graphics Ultra Pro and Graphics Ultra + (using VRAM vs. DRAM, respectively).
The mach32-based ATI Graphics Ultra is a true child of the bus wars. In 1994, ATI sold the Graphics Ultra in all five bus variants, something not imaginable any any other point in PC history. The OS/2 Museum presents the entire family: Five ATI mach32 graphics cards built in 1994.