For interested parties, I scratched the protective blob off the CPU and read the following:
TMS320VC5402 PGE100 C5-64AL3JW G4
All I wanted was a fast text console. I don't want a splash screen, I don't want alternate video resolutions. I just want something with low-to-no overhead and which has speedy screen updates. (I've run into really slow console updates under many flavors of virtualization, which makes things almost unusable.) I looked around on the web for many days, and finally had to trace the boot process in painful detail to figure it out.
The plymouth package is the software that displays bootspash screens and such. It tries to figure out whether or not a real graphics console is available, loading several kernel modules in the process. plymouth does not respect any kernel boot options (including: nofb nomodeset vga=normal nosplash). The only way to prevent plymouth from loading up the framebuffer driver is to either remove the software (which will come back to bite you when you upgrade), or to blacklist the framebuffer drivers so modprobe will not load them for any reason. I did the latter.
So add the following to the /etc/modprobe.d/blacklist file:
blacklist vga16fb
Done. Fast console.
After discovering the fix, I did find the following web pages, which also comment on these issues:
https://bugs.launchpad.net/ubuntu/+bug/582145
https://wiki.ubuntu.com/FoundationsTeam/LucidBootExperience
A few weeks ago, I bought one of these sound level meters in order to get a better sense of the noise level around my house. I chose this specific model because it had a serial port, figuring it would be easy to hook the meter up to a small embedded system and gather ongoing samples throughout the day. Nope.
I wasted quite a bit of time trying to get the meter working. For a while I could only get it to work on a Windows machine using their special software. After pulling out the oscilloscope and multimeter, I finally figured it out.
The documentation is wrong. The 1/8" TRS jack doesn't have TX, RX, and GND. Instead:
tip: logic 0 (positive voltage)
ring: tx data
sleeve: logic 1 (negative voltage)
Internally, these three pins are connected to an optocoupler in order to separate the external serial connection from the on-board 5v logic. For embedded systems, this turns out to be somewhat convenient, because one can provide whatever voltages are desired between tip and sleeve and then read the data which uses those same voltages from ring. (For example, the internal circuit allows you to use CMOS levels without having to use something like a MAX232 by connecting sleeve to GND and tip to +3.3v.)
The cable supplied with the device has a 1/8" male plug on one end and a female DB-9 on the other. It's connected as follows:
1: nc
2: ring
3: nc
4: tip
5: nc
6: tip
7: sleeve
8: sleeve
9: nc
Or, in graphic form:
Those of you out there who know your EIA232 pinouts will note that nothing, in fact, is connected to pin 5, usually GND. How can that be? The designers of this product are "cheaping out" and assuming that the end-user will have fully functioning serial port...
In order to use the supplied cable, your serial port must be able to drive both RTS and DTR independently. Setting DTR=1 and RTS=0 will put the right voltages on sleeve and tip, which makes the signal on ring range between the same voltages for 0 and 1 that your serial port itself provides. Once set, you will be able to read data at 19200 8N1 without trouble.
I regularly play the piano for English Country Dances and Contra Dances. My main axe is a Yamaha P120, an 88-key keyboard with weighted keys. I take it to most every gig, since one never knows what kind of piano will be available at each hall. The downside is that it's 41 pounds, which is a bit heavy.
To cut down on weight, I resolved to build my own. I wanted to find a weighted keyboard mechanism that I could remove, cut down to somewhere between 64 and 73 keys, and turn into a very simple MIDI controller. Last week, I found such an item on craigslist for a mere $100 -- a Kawai CN2 Digital Piano with a bad controller board:
Upon getting it home, I discovered that the controller board wasn't dead. While there was a lot of digital hash coming out of the speakers, one could hear notes being sounded (very softly) in response to keys being played. The situation improved markedly after disabling the reverb. From this, I guessed that the problem must be located in an area of scratch RAM being used to do the reverb simulation. I opened the box in order to find out:
At first I was disappointed, because there were only two ICs on the board -- one was a Fujitsu microcontroller, and the other I assumed to be a highly-integrated ASIC containing samples, DSP, scratch RAM, and so forth. I relaxed a bit after removing the board, because it had plenty of other silicon on the reverse:
After typing in some of the part numbers into search engines, I found the RAM chip: the G-Link GLT6200L08, a 256k x 8 CMOS SRAM. After examining it under a magnifying glass and poking at it with a probe, I could see that some of the solder joints were poor. I sharpened my soldering iron (quite literally, since I don't usually work on TSOP chips), applied some flux, and heated each of the pins in turn to ensure a good joint. I plugged the board back into the chassis, fired everything up, and everything worked perfectly!
Today I brought the keyboard to the office -- I'm trying to work up some jazz tunes with my workmates so we can sit in at the local pub one evening.
Back to searching for a dead keyboard...
Just so I don't have to struggle to remember this any more:
- grab a disk image of the desired net installer (e.g. http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-i386/current/images/netboot/boot.img.gz)
- insert usb flash drive, find it using diskutil list, then unmounting it (e.g. diskutil eject /dev/disk3
- write the contents of the uncompressed file to the raw flash drive -- not a partition/slice (e.g. dd if=boot.img of=/dev/disk3)
Boot your x86 box from the USB stick.
Well, here it is -- a blog, managed by software, rather than a set of hand-maintained HTML pages.