Spurred by the acquisition of a 386 ZIF socket adapter, I revived the semi-mysterious 386 board acquired over a year ago. To recap, the board is unusual in that it has CPU frequency configurable via jumpers, but I had trouble getting anything other than the soldered-on Am386DX-40 to run.
Experimenting with the PGA processor socket showed somewhat odd behavior: Plugging in another Am386DX-40, the board worked and both CPUs seemed to run. Lowering the frequency, it was even possible to have an Intel 386 CPU running in the PGA socket. But a Cyrix or TI processor would not work. The current theory is that as delivered, a CPU plugged into the PGA socket would be active, but the soldered-on processor ran as well. As long as the two were more or less identical, the system would work. Continue reading →
The question of how to feed an Intel SBT2 board has been answered thanks to a very kind blog reader. Interestingly, there are two different answers. The official one is this:
The Delta Electronics RPS-350 B power supply comes from a SC5000 chassis and is exactly what the SBT2 board calls for. It has the right 24-pin ATX-style power connector and the right 10-pin special I²C power connector, as well as the uncommon auxiliary connector. It’s a redundant power supply, meaning that the system should survive the failure of one of the two PSUs within the housing (notice the two handles on the back).
With the SSI switch panel (likewise from a SC5000), my SBT2 started up right away (well, almost, see below). Integrated graphics, 4GB RAM (this is a board from 2000!), 1GHz Xeon. Continue reading →
By sheer coincidence, three different yet similar wavetable daughterboards landed on my desk. They’re of different ages but all use Dream synthesizer chips. Together they provide an interesting window into the evolution of MIDI synthesizers.
The oldest daughterboard is from mid-1994 and was likely sold under the TerraTec WaveSystem brand. It uses the SAM9203 synthesizer chip. The middle-aged board is from late 1994 and uses the widespread SAM9233 synth chip. It was sold as Hizon DB333 and under other names. The newest of the bunch is significantly more modern—a Dreamblaster S1 from 2014 using a SAM2195 all-in-one chip. Continue reading →
Those are the power connectors on an Intel Server Board SBT2, produced circa 2000. I can’t find the right thing to plug into them.
The 24-pin connector should be more or less regular ATX, but it’s not enough to power up the board (nothing happens when I short the power switch pins). I don’t know if the 10-pin connector is required to be used as well, or if perhaps the auxiliary connector in between has to be. It’s also possible that the board is simply dead, although there is no obvious damage. Continue reading →
After a long wait, I decided to bite the bullet and order a ZIF (Zero Insertion Force) socket adapter suitable for 386 CPUs through Digi-Key. The manufacturer is Aries Electronics and the part number is 196-PRS14001-12, as established some time ago. The main motivation was plug-testing of a pile of 386 CPUs, which is not much fun with standard 386 LIF (Low Insertion Force) sockets.
To be precise, this is an adapter which plugs into a conventional LIF socket and provides a ZIF socket with a classic lever for a PGA chip.
The one big downside of the product is price. The adapter cost me 65 Euro plus VAT, and the minimum order quantity was two units. That adds up quickly. In addition, the item isn’t stocked and it took well over a month to arrive.
The primary upside on the other hand is that the adapter really works, and it saves a lot of time, frustration, and bent pins. Testing twenty 386 CPUs is a matter of minutes and requires no tools, no force, and if anything, straightens the pins of the processors. Continue reading →
My first experience with the Windows 10 media creation tool was, in a word, terrible. After 20 minutes or so of downloading, the tool told me that “Something happened” and the only option was to exit. That’s probably what passes for error diagnostics at Microsoft nowadays. Don’t overburden the user with information in case it might be helpful, at most tell them to try again because errors magically fix themselves (and if not, they’re SOL anyway).
After applying some common sense, I guessed that the tool was probably running out of disk space and made more room on the system drive. Lo and behold, the media creation tool worked and spat out a functioning ISO image!
It should be noted that the target for the ISO image was a drive with tons of free space, but drive C: only had about 3GB free. The tool seems to need roughly twice the size of the final ISO image on the system drive before the image ends up on the target filesystem.
In the bad old days of dark 1980s, it was considered standard practice to check available disk space and if it ran out, report that that’s what happened. Apparently the old generation of programmers at Microsoft died out and the new one hasn’t learned this advanced technique yet.
A while ago, a reader commented that in certain circles, it’s well known that there were “fake” OPL3 chips. This does not appear to be widespread knowledge. After a bit of digging, an interesting chapter in the history of PC hardware unfolds.
First let’s remember that the Yamaha OPL3 FM synthesizer, typically an YMF262 or an YMF289B, was an essential part of a Sound Blaster compatible sound card (let’s forget about exceptions like Ensoniq SoundScape and its bizarre OPL3 “emulation”). At the same time the Yamaha chips were somewhat expensive, and protected by a patent.
It is apparent that someone manufactured OPL3 copies, disguised them as nondescript chips, and sold them to many more or less reputable sound card OEMs. It is not clear what exactly these chips were. However, the sound they produce is normally close enough to real Yamaha chips that they were likely manufactured based on stolen “blueprints” of the originals. And the fact that companies like ESS, Crystal, OPTi, or Aureal couldn’t produce 100% accurate OPL3 clones strongly hints that there’s something fishy about these chips. Continue reading →
Once again it’s summer and the frequency of site updates will slow down somewhat. In the next two weeks I’ll be gone with very limited or no Internet access. So if you don’t get an answer right away, please be patient…
The C99 family of INTN_C and UINTN_C macros fills a real gap in the language, but it also lays extremely nasty traps for the unwary. The evolution of how the macros are defined in the C99 language standard shows that they were poorly defined from the beginning.
Consider code such as this:
unsigned x = 1024 / UINT32_C(1 << 8);
Depending on how the UINT32_C macro is implemented, the value of x might end up being 262144 or 4, or perhaps something different altogether.
That’s not how the macro is supposed to be used you say? That may be true, but why does the compiler not complain then? No error, not even a warning. Or were the language designers really so foolish as to expect every programmer to know the entire text of the Standard by heart? Say it ain’t so… Continue reading →