Of course, the gravity felt at the surface wouldn't be 5x as much. It's surprisingly much less. A planet with 5x the mass at the same overall density would have approximately 1.7x the radius. (Volume scales as the cube of the radius, and at constant density, mass scales linearly with volume. The cube root of 5 is approximately 1.7.)
Gravity decreases with the inverse of the square of the distance from the center of gravity. So, while the planet would exhibit 5 times the gravity, the amount of gravity felt at the surface would only be about 1.7x what we see here on Earth. The reason is, you're 1.7x further from the center, and so the effect of that gravity is 1.7 x 1.7 less.
A planet where everything is 70% heavier than it is here on Earth still seems like it could be very Earth-like, with similar forms of life. We might find it uncomfortable until we adapted, but I imagine it's actually something humans could adapt to even.
You can, of course, just avoid direct quotation if it makes sense to do so. For example "Kavya writes to ask how a baby is formed." That's a true statement, it conveys the question, and it does not purport to quote the original message.
Well, I can say it doesn't work on the default install of Ubuntu 8.04.1 for x86-64. I uses version 0.8.2 of Gnash. I'm not motivated enough to try to work around Ubuntu's package system and install a more recent version.
Seeing as Ubuntu 8.04.1 comes with Gnash 0.8.2 and they're only up to 0.8.3, I'm not sure what the point would be anyway. The problem is most likely a codec problem, and most of the interesting codec DLLs that FFmpeg will use (on Gnash's behalf) seem to be 32-bit only.
Most importantly: People don't generally pay sales tax when purchasing across state lines, and most people don't bother paying the use taxes they're obligated to pay. It seems in general that if you don't pay sales tax on an object because you bought it out of state, you're then technically liable for use tax. Most people just don't realize it. Since we're talking about Ohio, here's what Ohio's site has to say:
The most common situation that gives rise to a use tax liability is when an Ohio customer makes a mail order purchase from an out-of-state seller. Use tax is also due when the purchaser improperly claims exemption from the sales tax or if the sales tax paid is less than the total use tax in effect in the county where the item is used or benefit of the service is received.
One of the main reasons for the use tax is to protect Ohio vendors from unfair competition from out-of-state sellers, since the in-state merchant is required to collect sales tax when selling to an Ohio resident or business. All states that have a sales tax have a use tax.
There was a big stink about use tax in recent months, when Maine started enforcing its use tax against folks flying into the state in their personal planes and leaving their planes in the state longer than 20 days, thereby making them liable to the state's use tax.
While a tad sloppy on the music maker front, TI really had their shit together as far as putting together a platform during a time when people didn't know what you could use a home computer for.
Well, yes and no. They definitely had more of a turn-key, consumer product focus. Unfortunately, their model consumer product was the Speak & Spell. With the Home Computer, they went into the toy business.
This is evident in many design decisions. The BASIC interpreter was slow for three reasons:
Not much CPU addressable RAM. You need an extra level of indirection to get to video RAM.
The BASIC interpreter was written in GPL, which was itself an interpreted language.
They added explicit delay loops on top of the above in the character I/O routines and a few other places.
I learned #3 from the guy that hired me into TI.
Have you ever wondered why text scrolled up the screen at about the rate of a printing calculator in TI BASIC, and you couldn't make it go faster? They didn't want stuff to scroll by too fast for beginners and children. So, they made it impossible to do from BASIC. I believe that's also why CALL HCHAR and CALL VCHAR are so slow, but that latter part is just a hunch.
TI Extended BASIC fixed many of these issues, but it was still rather slow. TI XB II, which would have come with the TI-99/8, appears to fix all those issues. I don't know--I've never gotten to play with it. It's notable though that the TI-99/8 announces itself simply as "Texas Instruments Computer," rather than "Texas Instruments Home Computer." The shift in mindset is a big thing.
Don't get me wrong: The 99/4A was the first computer I owned, and I loved it dearly. I learned assembly language using the Mini Memory cartridge and even wrote some BASIC extensions. (Mostly, 40 col character access from BASIC that was dodgy at best.) It was turn-key, air-tight and did just what it was designed to do. Unfortunately, that also probably figured largely in its undoing as well, especially in the era of the tinkerer.
Ironically, one of its competitors succeeded by being quite the opposite--a tinker friendly, open system, complete with schematics and source code for the PROMs. That company grew up to be one of the most successful suppliers of turn-key, air-tight, does-just-what-it-was-designed-to-do systems. That company's Apple.
Between the TI-99/4A and New Coke, though, I learned if Bill Cosby tries to sell me something other than Jell-O, it's a gonner.;-)
Something to do with the fact that anything being processed by the graphics processor needing to be compiled first.
Somehow I doubt it. The TI Home Computer did keep its data in video RAM, and a great bulk of TI programs were written in Graphics Programming Language (GPL), an interpreted language and stored on serial ROM. Even TI BASIC was written in GPL. Video RAM wasn't directly accessible by the CPU. It was accessed through a register window on the VDP. GPL provided abstractions that made it easier for programmers to code despite this indirection. This combination of indirect addressability and interpreted code is probably what you're thinking of.
But that doesn't cut it as an explanation for why Music Maker stored pretty much the entire Video RAM, whereas other programs (including the built in BASIC) only stored what they needed. The routines were there for storing structured files in all sorts of formats. The only explanation that really works for me is laziness on the part of the programmers.
Since I work for TI now, I could probably ask around and find out if anyone knows who wrote Music Maker.:-) I know some guys who worked with the Home Computer folks. In fact, I was hired in by the lead logic designer of the TMS9995 CPU that was meant for the ill fated TI-99/8.
Sorry, I didn't mean to mislead you.:-) That's why I had the;-) in there. I still think that that was an amusing use of the audio from that tape.
The Scott Adams adventures irritated me greatly back in the day. I could never get very far and gave up quickly. Maybe now that I'm 20+ years older, I'll appreciate them better.
I do have some of my classic crappy games on cassette that I wrote. I'm still kicking myself, though, for my accidentally taping over my crowning achievement of the era: Tank Wars. It was my TI Extended BASIC attempt at a tank battle game, but with even bigger tanks!:D
And then there's all my Music Maker compositions. Music Maker was a blast. Why the hell did it save all 14K of usable VRAM to tape for even the shortest composition?
I'd like to post a minor correction in case someone comes along and notices the above description. I wrote the above from memory, and later realized I goofed on a couple details.
The lead-in to a block of data is a minimum of 256 zeros, followed by 4 32-bit words that have '1s' at the end in a special pattern that forms a "countdown until live". So, the header is a bit longer than I stated.
On the flip side, the total recorded block can have multiple sub-blocks associated with it, so the cost of that lead-in is amortized over a longer space. So, each 15x37 sub-block (555 bits) contains 32x10 = 320 useful bits. That's not so bad an overhead, really. Therefore, the peak bit rate is closer to 1700 bps.
Adding to the sophistication, the cassette drive has a 4-track head. The four tracks are divided up as follows:
Prerecorded data
Prerecorded audio
Writable data
Writable audio
The unit used specially formatted data tracks to time animations with respect to the audio, using a system called PicSe (pronounced "pixie"). You could store your own data on the data track, and in programs such as French Language cassette, you could store your own speech to compare against the pre-recorded model speech. Like I said, a very sophisticated system.
It was put together by a handful of bright folks working for APh Consulting out of Cal-Tech, actually. I've actually met one of the two people involved in that project.
Just a quick followup: By 3000bps, I'm referring to the Manchester decoded bits. As I recall, the hardware actually did the Manchester decode, and then interrupted the CPU with every new bit. Good thing the Keyboard Component was a dual-CPU system.:-)
Probably the most elaborate scheme I've seen so far is the Mattel Electronics Keyboard Component. It encodes everything into blocks of 32 10-bit words, each protected by a 5-bit detect-2-correct-1 Hamming code. The 32 words are then re-interleaved as 15 32-bit words. Each 32-bit word gets prefixed with a 5-bit framing header. That's prefixed by a block of zeros and a special 64-bit sync pattern per block. (I believe the whole sync structure was about 256 bits long.) The whole shebang is then Manchester encoded and put out to tape. Furthermore, the drive had a carrier-detect signal that it supplied in addition to the Manchester decoded bits.
The net result is a fairly robust protocol. Because the 32 data words were interleaved, dropout errors would get spread among multiple words. Thus, a burst error would show up only as 1 or 2 bit errors in each individual word. In addition, if a given word shows up as non-correctable, it was sometimes recoverable by flipping bits based on where the carrier was lost and trying again.
Other nifty aspects of its design: There was an additional pre-header on blocks that was recorded at (I think) 1/3rd the normal carrier frequency. This allowed the drive to detect interesting headers while fast-forwarding or rewinding. Since the drive was computer controlled, it allowed for fully automatic operation, including hardware seeks.
What was the bit rate? Well, I believe the raw bit rate for data bits coming off the tape was about 3000 bps. Factoring in encoding overhead, though, I'd say the final throughput was less than half that. A quick calculation suggests a nominal throughput around 1200 baud, give or take.
The 2-bit thing is still a hack that only buys back some of the performance. The original intention was to use the VIA's (I mistakenly called it the PIA) shift register, which would have kept it fast. For those of you who really care, someone actually wrote this all up on Wikipedia.
And you're right, I was thinking of a different loader that uses the synchronous serial mode, and that requires a hardware mod. *sigh* I never owned a C64 back in the day (though I have one now), so I only got to hear about all these hacks.
No. PSK is a constant carrier frequency with shifts in phase. PSK still uses constant bit periods. Apple's format uses two different frequencies, with a constant number of cycles per bit.
No. It's FSK, but it used a constant number of zero crossings per bit, rather than a constant bit period. So, to decode it, you count the average time between zero crossings rather than the number of zero crossings in a fixed time window.
On the plus side, it seems like the Woz scheme has some benefits. If you assign the shorter bit period to the more common bit value (likely, '0'), you shorten your average recording length a little. On the minus side, if you get an extra zero crossing in there (say, due to noise that wasn't filtered away by a Schmitt trigger or other hysteresis somewhere), recovery may be awkward.
BTW, the C64 floppy drives were slow as heck, but that had nothing to do with the bitrate for its media. There's some goofy history there, involving bugs in the shift register on the VIC-20's PIA, the decision to use CPU control loops instead to determine the bit period when communicating between the drive and the machine, and then the greater cycle-stealing period of the VIC-II as you get to the C64 throwing a monkey wrench in the works. The fast-load carts worked by restoring the native CIA hardware shift register to get rid of the CPU-controlled bit shifting to read bits from the floppy, restoring its speed to performance levels similar to the old IEEE-488 based bus they used back in the Commodore PET era. But that's a different story for another day.
If the schematic files are available in source format, and possibly the CAM information (Gerber files, drill files, etc), I'd call that open source, since that's the material used to generate the boards. It's one thing to print a schematic. It's quite another to publish the board layout in an editable form.
I haven't looked at what this project is doing, but it sounds like the latter.
It's an important point of law, if nothing else. It's these sorts of details that separate "preponderance of evidence" from "beyond a reasonable doubt." This is how you end up with OJ being found not guilty at the criminal trial (where "beyond a reasonable doubt" is the threshold), but still being found guilty at a civil liability trial where the threshold's lower ("preponderance of evidence").
You may think it's silly, but that's how the American law system works.
Interestingly, TI's C64x family of DSPs has special instructions that speed up INTERCAL. The "SHFL" instruction directly implements INTERCAL's "mingle" operator. The "DEAL" instruction implements common special cases of the "select" operator. Nifty, eh?
I guess if you use it for gaming, maybe. I actually have used it for data entry, and I can't imagine (a) needing to enter data and mouse at the same time, (b) trying to enter large quantities of data with my left hand. If I were left handed, though, it might make sense.
I wondered if those cuts were to identify home-row, and it sounds like they are.
Did you miss the part where he says he uses a Mac? If you don't do it The Apple Way (TM), the machine will fight you every step of the way, which is precisely what CmdrTaco complained about. It sounds like it's a "at the desk with a real keyboard" vs. "out and about using the built in keyboard" issue. It also sounds like one setting controls how both keyboards get interpreted, rather than separate settings for built in and external keyboards.
Whatever small compass we shove the matter into, it'll have exactly the same amount of gravity before and after. If we happen to shove it into a tight enough space that it becomes a black hole, it will be spectacularly tiny. It'll only start to accrete matter as it interacts with it. And, it'll have to get close enough to do it.
Gravity being what it is, it seems far more likely that a black hole formed in the lab would get drawn to the Earth's center of gravity (just like everything else on Earth is) rather than causing the Earth's center of gravity to shift. Shifting the Earth's center of gravity dramatically toward the LHC would take way more energy than what we're putting into the particles at the LHC.
Yeah, I'm definitely an assembler geek. Probably a good skill to have, seeing as I'm now on a CPU architecture team.:-) I managed to get my BSEE back in 1996. I'd rather do assembly code than database work, so I think I ended up in the right place.
Slashdot Mirror
Of course, the gravity felt at the surface wouldn't be 5x as much. It's surprisingly much less. A planet with 5x the mass at the same overall density would have approximately 1.7x the radius. (Volume scales as the cube of the radius, and at constant density, mass scales linearly with volume. The cube root of 5 is approximately 1.7.)
Gravity decreases with the inverse of the square of the distance from the center of gravity. So, while the planet would exhibit 5 times the gravity, the amount of gravity felt at the surface would only be about 1.7x what we see here on Earth. The reason is, you're 1.7x further from the center, and so the effect of that gravity is 1.7 x 1.7 less.
A planet where everything is 70% heavier than it is here on Earth still seems like it could be very Earth-like, with similar forms of life. We might find it uncomfortable until we adapted, but I imagine it's actually something humans could adapt to even.
You can, of course, just avoid direct quotation if it makes sense to do so. For example "Kavya writes to ask how a baby is formed." That's a true statement, it conveys the question, and it does not purport to quote the original message.
Well, I can say it doesn't work on the default install of Ubuntu 8.04.1 for x86-64. I uses version 0.8.2 of Gnash. I'm not motivated enough to try to work around Ubuntu's package system and install a more recent version.
Seeing as Ubuntu 8.04.1 comes with Gnash 0.8.2 and they're only up to 0.8.3, I'm not sure what the point would be anyway. The problem is most likely a codec problem, and most of the interesting codec DLLs that FFmpeg will use (on Gnash's behalf) seem to be 32-bit only.
I imagine I'm not the only person in this boat.
Most importantly: People don't generally pay sales tax when purchasing across state lines, and most people don't bother paying the use taxes they're obligated to pay. It seems in general that if you don't pay sales tax on an object because you bought it out of state, you're then technically liable for use tax. Most people just don't realize it. Since we're talking about Ohio, here's what Ohio's site has to say:
There was a big stink about use tax in recent months, when Maine started enforcing its use tax against folks flying into the state in their personal planes and leaving their planes in the state longer than 20 days, thereby making them liable to the state's use tax.
Well, yes and no. They definitely had more of a turn-key, consumer product focus. Unfortunately, their model consumer product was the Speak & Spell. With the Home Computer, they went into the toy business.
This is evident in many design decisions. The BASIC interpreter was slow for three reasons:
I learned #3 from the guy that hired me into TI.
Have you ever wondered why text scrolled up the screen at about the rate of a printing calculator in TI BASIC, and you couldn't make it go faster? They didn't want stuff to scroll by too fast for beginners and children. So, they made it impossible to do from BASIC. I believe that's also why CALL HCHAR and CALL VCHAR are so slow, but that latter part is just a hunch.
TI Extended BASIC fixed many of these issues, but it was still rather slow. TI XB II, which would have come with the TI-99/8, appears to fix all those issues. I don't know--I've never gotten to play with it. It's notable though that the TI-99/8 announces itself simply as "Texas Instruments Computer," rather than "Texas Instruments Home Computer." The shift in mindset is a big thing.
Don't get me wrong: The 99/4A was the first computer I owned, and I loved it dearly. I learned assembly language using the Mini Memory cartridge and even wrote some BASIC extensions. (Mostly, 40 col character access from BASIC that was dodgy at best.) It was turn-key, air-tight and did just what it was designed to do. Unfortunately, that also probably figured largely in its undoing as well, especially in the era of the tinkerer.
Ironically, one of its competitors succeeded by being quite the opposite--a tinker friendly, open system, complete with schematics and source code for the PROMs. That company grew up to be one of the most successful suppliers of turn-key, air-tight, does-just-what-it-was-designed-to-do systems. That company's Apple.
Between the TI-99/4A and New Coke, though, I learned if Bill Cosby tries to sell me something other than Jell-O, it's a gonner. ;-)
Somehow I doubt it. The TI Home Computer did keep its data in video RAM, and a great bulk of TI programs were written in Graphics Programming Language (GPL), an interpreted language and stored on serial ROM. Even TI BASIC was written in GPL. Video RAM wasn't directly accessible by the CPU. It was accessed through a register window on the VDP. GPL provided abstractions that made it easier for programmers to code despite this indirection. This combination of indirect addressability and interpreted code is probably what you're thinking of.
But that doesn't cut it as an explanation for why Music Maker stored pretty much the entire Video RAM, whereas other programs (including the built in BASIC) only stored what they needed. The routines were there for storing structured files in all sorts of formats. The only explanation that really works for me is laziness on the part of the programmers.
Since I work for TI now, I could probably ask around and find out if anyone knows who wrote Music Maker. :-) I know some guys who worked with the Home Computer folks. In fact, I was hired in by the lead logic designer of the TMS9995 CPU that was meant for the ill fated TI-99/8.
--Joe
Sorry, I didn't mean to mislead you. :-) That's why I had the ;-) in there. I still think that that was an amusing use of the audio from that tape.
The Scott Adams adventures irritated me greatly back in the day. I could never get very far and gave up quickly. Maybe now that I'm 20+ years older, I'll appreciate them better.
I do have some of my classic crappy games on cassette that I wrote. I'm still kicking myself, though, for my accidentally taping over my crowning achievement of the era: Tank Wars. It was my TI Extended BASIC attempt at a tank battle game, but with even bigger tanks! :D
And then there's all my Music Maker compositions. Music Maker was a blast. Why the hell did it save all 14K of usable VRAM to tape for even the shortest composition?
I'd like to post a minor correction in case someone comes along and notices the above description. I wrote the above from memory, and later realized I goofed on a couple details.
The lead-in to a block of data is a minimum of 256 zeros, followed by 4 32-bit words that have '1s' at the end in a special pattern that forms a "countdown until live". So, the header is a bit longer than I stated.
On the flip side, the total recorded block can have multiple sub-blocks associated with it, so the cost of that lead-in is amortized over a longer space. So, each 15x37 sub-block (555 bits) contains 32x10 = 320 useful bits. That's not so bad an overhead, really. Therefore, the peak bit rate is closer to 1700 bps.
Adding to the sophistication, the cassette drive has a 4-track head. The four tracks are divided up as follows:
The unit used specially formatted data tracks to time animations with respect to the audio, using a system called PicSe (pronounced "pixie"). You could store your own data on the data track, and in programs such as French Language cassette, you could store your own speech to compare against the pre-recorded model speech. Like I said, a very sophisticated system.
It was put together by a handful of bright folks working for APh Consulting out of Cal-Tech, actually. I've actually met one of the two people involved in that project.
Slightly OT, but will it decode this copy of Pirate Adventure? ;-)
Just a quick followup: By 3000bps, I'm referring to the Manchester decoded bits. As I recall, the hardware actually did the Manchester decode, and then interrupted the CPU with every new bit. Good thing the Keyboard Component was a dual-CPU system. :-)
Probably the most elaborate scheme I've seen so far is the Mattel Electronics Keyboard Component. It encodes everything into blocks of 32 10-bit words, each protected by a 5-bit detect-2-correct-1 Hamming code. The 32 words are then re-interleaved as 15 32-bit words. Each 32-bit word gets prefixed with a 5-bit framing header. That's prefixed by a block of zeros and a special 64-bit sync pattern per block. (I believe the whole sync structure was about 256 bits long.) The whole shebang is then Manchester encoded and put out to tape. Furthermore, the drive had a carrier-detect signal that it supplied in addition to the Manchester decoded bits.
The net result is a fairly robust protocol. Because the 32 data words were interleaved, dropout errors would get spread among multiple words. Thus, a burst error would show up only as 1 or 2 bit errors in each individual word. In addition, if a given word shows up as non-correctable, it was sometimes recoverable by flipping bits based on where the carrier was lost and trying again.
Other nifty aspects of its design: There was an additional pre-header on blocks that was recorded at (I think) 1/3rd the normal carrier frequency. This allowed the drive to detect interesting headers while fast-forwarding or rewinding. Since the drive was computer controlled, it allowed for fully automatic operation, including hardware seeks.
What was the bit rate? Well, I believe the raw bit rate for data bits coming off the tape was about 3000 bps. Factoring in encoding overhead, though, I'd say the final throughput was less than half that. A quick calculation suggests a nominal throughput around 1200 baud, give or take.
--Joe
The 2-bit thing is still a hack that only buys back some of the performance. The original intention was to use the VIA's (I mistakenly called it the PIA) shift register, which would have kept it fast. For those of you who really care, someone actually wrote this all up on Wikipedia.
And you're right, I was thinking of a different loader that uses the synchronous serial mode, and that requires a hardware mod. *sigh* I never owned a C64 back in the day (though I have one now), so I only got to hear about all these hacks.
I get off your lawn if you get off mine. ;-)
No. PSK is a constant carrier frequency with shifts in phase. PSK still uses constant bit periods. Apple's format uses two different frequencies, with a constant number of cycles per bit.
No. It's FSK, but it used a constant number of zero crossings per bit, rather than a constant bit period. So, to decode it, you count the average time between zero crossings rather than the number of zero crossings in a fixed time window.
On the plus side, it seems like the Woz scheme has some benefits. If you assign the shorter bit period to the more common bit value (likely, '0'), you shorten your average recording length a little. On the minus side, if you get an extra zero crossing in there (say, due to noise that wasn't filtered away by a Schmitt trigger or other hysteresis somewhere), recovery may be awkward.
BTW, the C64 floppy drives were slow as heck, but that had nothing to do with the bitrate for its media. There's some goofy history there, involving bugs in the shift register on the VIC-20's PIA, the decision to use CPU control loops instead to determine the bit period when communicating between the drive and the machine, and then the greater cycle-stealing period of the VIC-II as you get to the C64 throwing a monkey wrench in the works. The fast-load carts worked by restoring the native CIA hardware shift register to get rid of the CPU-controlled bit shifting to read bits from the floppy, restoring its speed to performance levels similar to the old IEEE-488 based bus they used back in the Commodore PET era. But that's a different story for another day.
--Joe
If the schematic files are available in source format, and possibly the CAM information (Gerber files, drill files, etc), I'd call that open source, since that's the material used to generate the boards. It's one thing to print a schematic. It's quite another to publish the board layout in an editable form.
I haven't looked at what this project is doing, but it sounds like the latter.
--Joe
It's an important point of law, if nothing else. It's these sorts of details that separate "preponderance of evidence" from "beyond a reasonable doubt." This is how you end up with OJ being found not guilty at the criminal trial (where "beyond a reasonable doubt" is the threshold), but still being found guilty at a civil liability trial where the threshold's lower ("preponderance of evidence").
You may think it's silly, but that's how the American law system works.
Interestingly, TI's C64x family of DSPs has special instructions that speed up INTERCAL. The "SHFL" instruction directly implements INTERCAL's "mingle" operator. The "DEAL" instruction implements common special cases of the "select" operator. Nifty, eh?
I guess if you use it for gaming, maybe. I actually have used it for data entry, and I can't imagine (a) needing to enter data and mouse at the same time, (b) trying to enter large quantities of data with my left hand. If I were left handed, though, it might make sense.
I wondered if those cuts were to identify home-row, and it sounds like they are.
Left handed number pad? And who's been chewing on your keys?!
Did you miss the part where he says he uses a Mac? If you don't do it The Apple Way (TM), the machine will fight you every step of the way, which is precisely what CmdrTaco complained about. It sounds like it's a "at the desk with a real keyboard" vs. "out and about using the built in keyboard" issue. It also sounds like one setting controls how both keyboards get interpreted, rather than separate settings for built in and external keyboards.
Whatever small compass we shove the matter into, it'll have exactly the same amount of gravity before and after. If we happen to shove it into a tight enough space that it becomes a black hole, it will be spectacularly tiny. It'll only start to accrete matter as it interacts with it. And, it'll have to get close enough to do it.
Gravity being what it is, it seems far more likely that a black hole formed in the lab would get drawn to the Earth's center of gravity (just like everything else on Earth is) rather than causing the Earth's center of gravity to shift. Shifting the Earth's center of gravity dramatically toward the LHC would take way more energy than what we're putting into the particles at the LHC.
I dare say that's the first spoonerism I've seen that was born as a typo. Bravo!
You've never heard of Jethro Tull? (Ok, that's the name of the band, but please tell me you've heard of them?)
Yeah, I'm definitely an assembler geek. Probably a good skill to have, seeing as I'm now on a CPU architecture team. :-) I managed to get my BSEE back in 1996. I'd rather do assembly code than database work, so I think I ended up in the right place.
And yes, it was probably Tacit's journal. :-)
--Joe