Code Site

Holy Shit, I finally found the internet sweet-spot in my apartment... unfortunately I have to straddle my computer to take a leak, but it's worth it.

So I've finally set up a code-site for my projects... or at least my most current one.
341x768 on a laptop display via an 8-bit AVR. Two-ish years' work getting this to this point!

https://code.google.com/p/avr-lvds-lcd/

and more pics at:
GeekAttempts Site

The Latest

It's been a while since I posted... my internet connection has been too flakey for months. And my combo of old and new technologies always leaves me a bit out of the loop.

In the meantime I've done quite a bit.

iBook G4 12in LCD upgrade

This thing came with 1024x768... my old system (which was stolen) had 1600x1200, so needless to say I was feeling a bit cramped.

Managed to locate a 12in 1400x1050 display on ebay for $30 that wouldn't work directly with this computer. (Details: This display is "dual-pixel" meaning it expects to receive two pixels at a time, rather than one... requiring entirely different circuitry and wiring. Managed to find parts via TI that could make the conversion... yep, it's not only doable; I've designed a circuit-board and have been using it for nearly a year now. 1024x768 was a bitch. Took a bit of effort, besides the circuit. I'm proud of that, too. The screen itself wasn't the same mounting, but when the housing was removed, it fit inside the old display's housing. All in all it was probably $50 worth of parts, including the display... Someone online had found another display that worked immediately, even used that display is still selling for nearly $200; so this was a bit more of a challenge. Had to create a fake EDID chip and figure out all the timing, etc. Huge process, I should probably document it better. For several months I used a hand-wired converter-circuit. Lots of tiny wires soldered directly to TQFP pins; I have no idea how it worked so well for so long. The PCB squeeked out a few more Hz refresh-rate, but isn't nearly as impressive... anyone with as much experience as I have can make a PCB!)

---

yeahp, tried to upload a pic, but the net's still too flakey.

----

The display came from an old "PenEnabled" computer, an old Windows Laptop/Tablet in the era before tablets were mainstream. So I also made the necessary circuitry to use the built-in Wacom tablet on my mac. It involved stealing 12V from the LCD inverter (which blew the fuse and was a pain to replace), voltage-regulators, and a simple AVR circuit to interface between the tablet and a bluetooth transmitter. Worked great, but the tablet itself was a bit wider than the bezel, so after months of leaving the display-housing off, I decided to remove it.

In other related-bits, took a bit of effort but managed to compile the latest GIMP on my PPC so I could use the tablet... even though I only used it a few times. It was nice, though... pressure-sensitive, etc.

LCD/AVR Interface

Apparently I'm somewhat fixated on the idea of using old laptop LCDs with AVR processors.

With quite a bit of hacking, I've managed to drive "FPD-Link" (LVDS) signals via an AVR, using PWM, no less. The latest status is about 1Hz refresh-rate with 341x768 resolution at 48 colors on a 1024x768 display. Leads to some interesting abilities and equally interesting limitations. Also tons of hacking was involved... all *extremely* rigorously documented in my code.

As it stands, I've a pretty decent "Mario Brothers" style Question-Box, which I ultimately intend on hanging somewhere... when you hit the underside, a random award will be displayed (1-up, Biggie, Flower-Power, Invincibility... and the occasional Goomba which you have to hit again to kill). It's *done* code-wise, now I just need to make the box, a robust and reliable "hit-switch," and figure out how to power it wherever I hang it.

I've also created a game ala "Racer" from the ol' TI-82 days... a course is laid out and as the screen slowly refreshes, you have to stay in the track... Sounds slow at such refresh-rates, but actually it's somewhat stimulating.

I've a few other ideas of "games" that can make use of such a slow, but high-resolution, display... one is "Story-board Mario"... showing snapshots of your progress as you go, multiple "story-boards" displayed in each refresh. It could *almost* be real-time like the original Super Mario Bro's itself, just in story-board fashion.

AVR/SDRAM (Free-Running)

I've also managed to figure out a way to connect an old SDRAM to an AVR in such a way that the entire memory can be output in a single (or repeated) burst... After the AVR is done loading the memory, the SDRAM itself is responsible for its own control and addressing... I call it "Free-Running Mode," where several of the SDRAM outputs are fed directly back into its inputs (command-signals, address-signals, etc).

I've used it to drive the same LCD, at full resolution and full-color... refresh-rates limited only by the SDRAM's clock-rate, which currently is (though needn't be) limited to the AVR's clock. Though, if you do the math, 1024x768x7 (x7 because there are 7bits in each LVDS transaction) leads to quite a bit of loading from the AVR, so this particular system is best-suited to stationary images, or those that change only a few pixels between each refresh.

Other possibilities include using the SDRAM as a high-bandwidth logic-analyzer (32bits, easily, probably 133MS/s for a few seconds, depending on the RAM size), and more.

The latest design uses no external components, just an SDRAM card and an AVR, oh and a crystal oscillator.

Other design-improvement ideas involve:

Using the SDRAM to completely control itself after loading a few basic instructions from the AVR... e.g. "write" and "read" as well as "nop." Possibly the SDRAM could generate its own clock signal, though this is a bit of a stretch.

These involve splitting the SDRAM into different "banks", one which is responsible for control, and another for actual data I/O.

Quite a bit was learned in each of these projects as far as (undocumented) abilities and limitations of these systems... For example:

SDRAM is supposed to be refreshed, in entirety, every 64ms... but realistically can last for several seconds without a refresh. Further, rather than using explicit "refresh" commands, simply opening and closing a memory-location is enough to refresh that location. This leads to some nice work-arounds; a typical "refresh" command requires that the entire memory be "closed;" meaning that the memory could no longer directly control itself... but it *can easily* open and close its own memory locations while doing other things in "free-running mode."

Similarly, LCDs are specified as having required timings WAY FASTER than an AVR can accomplish... but they also have technologies that accommodate being pushed well-beyond their documented limits. Because TFT displays have, essentially, memory at every pixel, refresh rates of 1Hz, or even 1/5Hz are achievable (on displays which allow out-of-range timing-signals, again completely undocumented). The image is held between each refresh by the transistor on each pixel.

And pushing things in ways they were never intended:

"FPD-Link" (aka LVDS) compatible signals can be generated via an AVR's PWM outputs, no joke. Since many signals are repeated multiple times, (e.g. "Horizontal Sync") it requires loading a PWM value, and allowing it to repeat while the processor is used for other (e.g. image-generation) tasks. Using the "Dead-Time Generator" on these PWM signals allows for creating *almost* serial data for the FPD-Link signal. A bit of hacking reveals that 48 colors distributed almost evenly across the whole range are possible by simply timing the different PWM signals with different start and stop times. 

Likewise, the PWM signals on this particular AVR can be run at frequencies much higher than the AVR's clock signal... The ATtiny861 is specified to run at 8MHz, and its PWM signals at 64MHz, but manipulation of some registers and fuses can push it to 16MHz and PWM at 128MHz... 128MHz FPD-Link is nearly the specification. So, if resolution (which is entirely dependent on the AVR's processing abilities) isn't a concern, the screen itself could be refreshed at nearly its specified rates.

Personally, I've found that a display flickering at 30Hz is less pleasing to the eye than one with a visible scrolling refresh every second... And the higher resolution is a big plus.

Another hack was due to the memory-limitations on the AVR... 512Bytes of RAM doesn't allow for full-screen frame-buffer. In fact, it can't even handle an entire row. So, instead of storing data in a frame (or row) buffer, I've opted for a "Row-segment buffer" wherein a row's image-data is stored as segments with a color-value and a value representing the number of pixels.

This works great for images where in a single row there isn't much change... But text, for instance, has a shitton of color-changes between each character, and even within a character. A simple solution is rotating the display (and text) 90 degrees. In the most complicated of characters, there might be 6 color-changes vertically, and since each "row-segment buffer" can handle something like 64 separate segments, we have no issue displaying several rows (separate from display-rows) of dense text in columns, where each LCD "row" is now a column, each "row-segment" is now a column-segment. This is getting hard to explain.

Anyways, the point is, there's quite a bit that can be done to make use of a display at 1Hz refresh with 341x768 usable pixels, 48 colors, and only 512Bytes of RAM...

Oh, a further hack... LVDS requires weird voltage-ranges, as far as most devices are concerned... AVR's output roughly 1=V+ and 0=0V, where V+ is usually 3.3V or 5V, but LVDS requires a differential voltage with about 1V peak-to-peak... This has been found to be easily accomplished with standard TTL IC's, from the 1980's, no-less. By loading the outputs with an LVDS load (100-ohm resistance between the - signal and the + signal), the voltage-levels output by the TTL chips are right within range. Yes, this is stressing the chips quite a bit. These TTL LS chips are rated for 5V, and I'm running them at 3.3V, the outputs are specified to drive *way lower* loads than specified, but, amazingly, pushing them way outside their specified-ranges, the outputs seem to be darn-near *exactly* what's required by LVDS. (It's almost like LVDS was designed around out-of-range TTL chips?!).

Taking a step back... what else have I worked on recently...?

Audio-recording with an AVR to an SD card...

Nokia LCD display <- AVR

Hacking an old Nokia phone for keypad entry via a single AVR analog-comparator input.

Transferred a bunch of VHS's to AVI's

Experimented with (and determined damned-near-useless) Windows XP-64 on a computer found in my building's "free-section"

Determined the "ol' Plasma" to be a fruitless venture, but using its Tuner for my ol' tube TV to get HDTV stations.

Have an old XBox360 that has a flakey DVD drive, been trying to repair it repeatedly... seems to be an alignment issue (the gliders the head rides on seem to be askew) combined with a laser adjustment issue (those danged potentiometers seem to adjust perfectly for one DVD, but not for the next)... can't afford a new drive, so if nothing else, it's a good system for watching AVI's on.

Hey that XBox controller I bought is better than just for watching movies! Someone hacked a driver for MacOS to use it as a joystick... so I've been getting some ol' NES time in via Mednafen. Super Mario Bro's is way too frustrating, what with the need to restart from scratch every time you die... I suppose I could learn to use Mednafen's Save-State, but haven't yet.

This list, of course, is limited to my geekish-endeavors... There's plenty more going on in my life... Like fighting for causes that would be lost-causes except you can't call something a lost-cause if no one except you is fighting for 'em in the first place. Or, like, going to a bar I thought I had friends at, only to find out someone's dropped something in my drink and waking up in the hospital... and receiving a bill for half a year's income. Or, like, being flat-out-manipulated by people you consider friends. So, yeah, let's keep this geekish... I'm proud of my accomplishments.

Oh I forgot one...

My PBG4's keyboard was falling apart... missing several keys... etc. Discovered that the ol' PBG3 keyboard I had laying around was, in fact, pin-compatible... except for one thing... well, a dozen really. First: It was reversed... yeahp. Sounds like a simple fix, but these ribbon-cables can't be soldered-to, and certainly aren't long enough to twist. Managed to solder up an adaptor that *just fit* in the space available. Tons of tiny wires. But, Sweet. Had to cut a few pieces off the computer's housing to get it to fit (it's just *slightly* wider than the original). Did a few hacks here and there to get it to hold-in relatively well... It's a bit gummy-feeling, since it's not really mounted right, but overall it's certainly better than before. 

Oh, and this AMD64 I found in the "free-section" is a bit of a joke, but maybe I'll do something with it. I pieced together a couple machines that were sitting there, so now it's in a D-Vine "Home Entertainment PC" case, which could be groovy. Trying to download linux, let's see what this Mint thing is all about... (Lessee, I started on Slackware in middleschool, Debian in highschool, Ubuntoo recently on my PBG4 which I removed... was thinking about Arch, but apparently it's *heavily* dependent on a reliable net connection which I don't have...) A few more days' downloading and I might have a DVD image to burn.

It's a strange position to be in... having once had Cable Internet when others were still using dialup (or didn't even have internet at all), now being happy with 10KB/s downloads... nah *ecstatic* if I get 10KB/s, while all those "the internet is for geeks" folks are surfing YouTube on their phones...

And, since we're ranting... how is it that mainstream opensource distributors aren't even capable of something so ubiquitous as download-resume...?! And is there *anything* that exists anymore without a net-based-installer? I had to search for hours to find a distro that *might* install without reliable internet... Seriously... If I live in a first-world country, in the firstest-of-worlds communities and can only get flakey internet... how are people getting by elsewhere?! I mean, seriously... I can't even upload an image without the site crashing... Thankfully somehow it saved a draft! 'cause I've been getting a shitton of this:  "

An error occurred while trying to save or publish your post. Please try again. Dismiss"

The Latest...

It's been a while since I posted... my internet connection has been too flakey for months. And my combo of old and new technologies always leaves me a bit out of the loop.

In the meantime I've done quite a bit.

iBook G4 12in LCD upgrade
This thing came with 1024x768... my old system (which was stolen) had 1600x1200, so needless to say I was feeling a bit cramped.
Managed to locate a 12in 1400x1050 display on ebay for $30 that wouldn't work directly with this computer. (Details: This display is "dual-pixel" meaning it expects to receive two pixels at a time, rather than one... requiring entirely different circuitry and wiring. Managed to find parts via TI that could make the conversion... yep, it's not only doable; I've designed a circuit-board and have been using it for nearly a year now. 1024x768 was a bitch. Took a bit of effort, besides the circuit. I'm proud of that, too. The screen itself wasn't the same mounting, but when the housing was removed, it fit inside the old display's housing. All in all it was probably $50 worth of parts, including the display... Someone online had found another display that worked immediately, even used that display is still selling for nearly $200; so this was a bit more of a challenge. Had to create a fake EDID chip and figure out all the timing, etc. Huge process, I should probably document it better. For several months I used a hand-wired converter-circuit. Lots of tiny wires soldered directly to TQFP pins; I have no idea how it worked so well for so long. The PCB squeeked out a few more Hz refresh-rate, but isn't nearly as impressive... anyone with as much experience as I have can make a PCB!)

---
yeahp, tried to upload a pic, but the net's still too flakey.
----

The display came from an old "PenEnabled" computer, an old Windows Laptop/Tablet in the era before tablets were mainstream. So I also made the necessary circuitry to use the built-in Wacom tablet on my mac. It involved stealing 12V from the LCD inverter (which blew the fuse and was a pain to replace), voltage-regulators, and a simple AVR circuit to interface between the tablet and a bluetooth transmitter. Worked great, but the tablet itself was a bit wider than the bezel, so after months of leaving the display-housing off, I decided to remove it.
In other related-bits, took a bit of effort but managed to compile the latest GIMP on my PPC so I could use the tablet... even though I only used it a few times. It was nice, though... pressure-sensitive, etc.

LCD/AVR Interface
Apparently I'm somewhat fixated on the idea of using old laptop LCDs with AVR processors.
With quite a bit of hacking, I've managed to drive "FPD-Link" (LVDS) signals via an AVR, using PWM, no less. The latest status is about 1Hz refresh-rate with 341x768 resolution at 48 colors on a 1024x768 display. Leads to some interesting abilities and equally interesting limitations. Also tons of hacking was involved... all *extremely* rigorously documented in my code.
As it stands, I've a pretty decent "Mario Brothers" style Question-Box, which I ultimately intend on hanging somewhere... when you hit the underside, a random award will be displayed (1-up, Biggie, Flower-Power, Invincibility... and the occasional Goomba which you have to hit again to kill). It's *done* code-wise, now I just need to make the box, a robust and reliable "hit-switch," and figure out how to power it wherever I hang it.
I've also created a game ala "Racer" from the ol' TI-82 days... a course is laid out and as the screen slowly refreshes, you have to stay in the track... Sounds slow at such refresh-rates, but actually it's somewhat stimulating.
I've a few other ideas of "games" that can make use of such a slow, but high-resolution, display... one is "Story-board Mario"... showing snapshots of your progress as you go, multiple "story-boards" displayed in each refresh. It could *almost* be real-time like the original Super Mario Bro's itself, just in story-board fashion.

AVR/SDRAM (Free-Running)
I've also managed to figure out a way to connect an old SDRAM to an AVR in such a way that the entire memory can be output in a single (or repeated) burst... After the AVR is done loading the memory, the SDRAM itself is responsible for its own control and addressing... I call it "Free-Running Mode," where several of the SDRAM outputs are fed directly back into its inputs (command-signals, address-signals, etc).
I've used it to drive the same LCD, at full resolution and full-color... refresh-rates limited only by the SDRAM's clock-rate, which currently is (though needn't be) limited to the AVR's clock. Though, if you do the math, 1024x768x7 (x7 because there are 7bits in each LVDS transaction) leads to quite a bit of loading from the AVR, so this particular system is best-suited to stationary images, or those that change only a few pixels between each refresh.
Other possibilities include using the SDRAM as a high-bandwidth logic-analyzer (32bits, easily, probably 133MS/s for a few seconds, depending on the RAM size), and more.
The latest design uses no external components, just an SDRAM card and an AVR, oh and a crystal oscillator.
Other design-improvement ideas involve:
Using the SDRAM to completely control itself after loading a few basic instructions from the AVR... e.g. "write" and "read" as well as "nop." Possibly the SDRAM could generate its own clock signal, though this is a bit of a stretch.
These involve splitting the SDRAM into different "banks", one which is responsible for control, and another for actual data I/O.

Quite a bit was learned in each of these projects as far as (undocumented) abilities and limitations of these systems... For example:
SDRAM is supposed to be refreshed, in entirety, every 64ms... but realistically can last for several seconds without a refresh. Further, rather than using explicit "refresh" commands, simply opening and closing a memory-location is enough to refresh that location. This leads to some nice work-arounds; a typical "refresh" command requires that the entire memory be "closed;" meaning that the memory could no longer directly control itself... but it *can easily* open and close its own memory locations while doing other things in "free-running mode."
Similarly, LCDs are specified as having required timings WAY FASTER than an AVR can accomplish... but they also have technologies that accommodate being pushed well-beyond their documented limits. Because TFT displays have, essentially, memory at every pixel, refresh rates of 1Hz, or even 1/5Hz are achievable (on displays which allow out-of-range timing-signals, again completely undocumented). The image is held between each refresh by the transistor on each pixel.

And pushing things in ways they were never intended:
"FPD-Link" (aka LVDS) compatible signals can be generated via an AVR's PWM outputs, no joke. Since many signals are repeated multiple times, (e.g. "Horizontal Sync") it requires loading a PWM value, and allowing it to repeat while the processor is used for other (e.g. image-generation) tasks. Using the "Dead-Time Generator" on these PWM signals allows for creating *almost* serial data for the FPD-Link signal. A bit of hacking reveals that 48 colors distributed almost evenly across the whole range are possible by simply timing the different PWM signals with different start and stop times.

Likewise, the PWM signals on this particular AVR can be run at frequencies much higher than the AVR's clock signal... The ATtiny861 is specified to run at 8MHz, and its PWM signals at 64MHz, but manipulation of some registers and fuses can push it to 16MHz and PWM at 128MHz... 128MHz FPD-Link is nearly the specification. So, if resolution (which is entirely dependent on the AVR's processing abilities) isn't a concern, the screen itself could be refreshed at nearly its specified rates.
Personally, I've found that a display flickering at 30Hz is less pleasing to the eye than one with a visible scrolling refresh every second... And the higher resolution is a big plus.

Another hack was due to the memory-limitations on the AVR... 512Bytes of RAM doesn't allow for full-screen frame-buffer. In fact, it can't even handle an entire row. So, instead of storing data in a frame (or row) buffer, I've opted for a "Row-segment buffer" wherein a row's image-data is stored as segments with a color-value and a value representing the number of pixels.
This works great for images where in a single row there isn't much change... But text, for instance, has a shitton of color-changes between each character, and even within a character. A simple solution is rotating the display (and text) 90 degrees. In the most complicated of characters, there might be 6 color-changes vertically, and since each "row-segment buffer" can handle something like 64 separate segments, we have no issue displaying several rows (separate from display-rows) of dense text in columns, where each LCD "row" is now a column, each "row-segment" is now a column-segment. This is getting hard to explain.

Anyways, the point is, there's quite a bit that can be done to make use of a display at 1Hz refresh with 341x768 usable pixels, 48 colors, and only 512Bytes of RAM...

Oh, a further hack... LVDS requires weird voltage-ranges, as far as most devices are concerned... AVR's output roughly 1=V+ and 0=0V, where V+ is usually 3.3V or 5V, but LVDS requires a differential voltage with about 1V peak-to-peak... This has been found to be easily accomplished with standard TTL IC's, from the 1980's, no-less. By loading the outputs with an LVDS load (100-ohm resistance between the - signal and the + signal), the voltage-levels output by the TTL chips are right within range. Yes, this is stressing the chips quite a bit. These TTL LS chips are rated for 5V, and I'm running them at 3.3V, the outputs are specified to drive *way lower* loads than specified, but, amazingly, pushing them way outside their specified-ranges, the outputs seem to be darn-near *exactly* what's required by LVDS. (It's almost like LVDS was designed around out-of-range TTL chips?!).

Taking a step back... what else have I worked on recently...?

Audio-recording with an AVR to an SD card...
Nokia LCD display <- AVR
Hacking an old Nokia phone for keypad entry via a single AVR analog-comparator input.
Transferred a bunch of VHS's to AVI's
Experimented with (and determined damned-near-useless) Windows XP-64 on a computer found in my building's "free-section"
Determined the "ol' Plasma" to be a fruitless venture, but using its Tuner for my ol' tube TV to get HDTV stations.
Have an old XBox360 that has a flakey DVD drive, been trying to repair it repeatedly... seems to be an alignment issue (the gliders the head rides on seem to be askew) combined with a laser adjustment issue (those danged potentiometers seem to adjust perfectly for one DVD, but not for the next)... can't afford a new drive, so if nothing else, it's a good system for watching AVI's on.
Hey that XBox controller I bought is better than just for watching movies! Someone hacked a driver for MacOS to use it as a joystick... so I've been getting some ol' NES time in via Mednafen. Super Mario Bro's is way too frustrating, what with the need to restart from scratch every time you die... I suppose I could learn to use Mednafen's Save-State, but haven't yet.

This list, of course, is limited to my geekish-endeavors... There's plenty more going on in my life... Like fighting for causes that would be lost-causes except you can't call something a lost-cause if no one except you is fighting for 'em in the first place. Or, like, going to a bar I thought I had friends at, only to find out someone's dropped something in my drink and waking up in the hospital... and receiving a bill for half a year's income. Or, like, being flat-out-manipulated by people you consider friends. So, yeah, let's keep this geekish... I'm proud of my accomplishments.

Oh I forgot one...
My PBG4's keyboard was falling apart... missing several keys... etc. Discovered that the ol' PBG3 keyboard I had laying around was, in fact, pin-compatible... except for one thing... well, a dozen really. First: It was reversed... yeahp. Sounds like a simple fix, but these ribbon-cables can't be soldered-to, and certainly aren't long enough to twist. Managed to solder up an adaptor that *just fit* in the space available. Tons of tiny wires. But, Sweet. Had to cut a few pieces off the computer's housing to get it to fit (it's just *slightly* wider than the original). Did a few hacks here and there to get it to hold-in relatively well... It's a bit gummy-feeling, since it's not really mounted right, but overall it's certainly better than before.

Oh, and this AMD64 I found in the "free-section" is a bit of a joke, but maybe I'll do something with it. I pieced together a couple machines that were sitting there, so now it's in a D-Vine "Home Entertainment PC" case, which could be groovy. Trying to download linux, let's see what this Mint thing is all about... (Lessee, I started on Slackware in middleschool, Debian in highschool, Ubuntoo recently on my PBG4 which I removed... was thinking about Arch, but apparently it's *heavily* dependent on a reliable net connection which I don't have...) A few more days' downloading and I might have a DVD image to burn.

It's a strange position to be in... having once had Cable Internet when others were still using dialup (or didn't even have internet at all), now being happy with 10KB/s downloads... nah *ecstatic* if I get 10KB/s, while all those "the internet is for geeks" folks are surfing YouTube on their phones...

And, since we're ranting... how is it that mainstream opensource distributors aren't even capable of something so ubiquitous as download-resume...?! And is there *anything* that exists anymore without a net-based-installer? I had to search for hours to find a distro that *might* install without reliable internet... Seriously... If I live in a first-world country, in the firstest-of-worlds communities and can only get flakey internet... how are people getting by elsewhere?! I mean, seriously... I can't even upload an image without the site crashing... Thankfully somehow it saved a draft! 'cause I've been getting a shitton of this:  "

An error occurred while trying to save or publish your post. Please try again. Dismiss"

How many times... re: motion-ramping

I guess there are just some things I have to admit are my white whale...

I can't count the number of times I've coded the same thing to come to the same conclusion. It seems simple at first... You have a motor which moves from one position to another... you have a top speed, and you want it to ramp from stop to the top speed, continue at that speed for a while, then ramp back down to stop at the end position.

I've solved this problem, already, with a convoluted solution: treat the ramping motion like a quarter of a sine-wave, and instead of setting the *speed*, give a simpler motion algorithm (without ramping) multiple intermediate endpoints along that sine-wave, telling it how long to take between each step (a constant time-value). If you're on a circle it makes more sense... the overall speed around the circle is constant; it takes the same amount of time to traverse from one angle on the circle to another... A circle, of course, has a maximum speed of 1 and a minimum of 0 along a single axis while rotating over 90 degrees. Then taking that back to a single-axis you're simply telling it to take a certain amount of time to traverse between different angles on the sine-wave.

But every time I set the project down for a year or two, I look at it and think "damn that's convoluted, why don't I just vary the velocity constantly?" And I recode it with a seemingly simple algorithm. Tonight's was: for the first third of the distance vary the speed linearly from 0 to max, continue at max for the second third, then vary the speed linearly down from max to 0.

Seems simple, really, it probably is, too, because that's how it's taught to implement "simple ramping." But there're several inherent problems I always run into. First: Distance, Time, (and the calculations!) are discrete, here... so it doesn't quite work like in physics. The math doesn't *quite* work out. It works great for ramping UP, but ramping DOWN is a pain, the math is off by a tiny fraction here or there, that error adds up, and suddenly I'm at velocity zero long before the endpoint.

It really seems my problem is I keep trying to approach this from the ideal physics/math standpoint; I keep thinking about *speed* as the main concern, when really time (and position) is what matters (and *works*). If I can fully wrap my head around why the sine-wave approach works, I could probably use the same logic to implement linear-ramping. Maybe instead of using points on a sine-wave, I could use points on a parabola... tell it exactly how long to take between each of those points. Because, without ramping, I can easily get from one point to the next in a specific amount of time. Either way, sinusoidal ramping is smoother than linear, so it doesn't *really* make sense to go back, except to simplify the code that's already written and works (but always has to be modified slightly each time I'm reusing it).

It's just friggin' annoying that I keep recoding this over and over to come to the same conclusions. This last time I didn't even realize I was coding the same thing until the very end... I came to the same faulty conclusion from a completely different direction... thought I had that ah-hah moment, only to realize it was exactly the same as before.

Sine waves, stick to 'em!

back and forward in bash

One of the things I like about window-based file-browsing is the back and forward buttons...

So here're my bash scripts. Feel free to use them. If you find them handy buy me a beer (or post a comment)! Unless, of course, you're planning to profit off 'em, then you can and should buy me a brewery after asking my permission.

There are four files. mycd.sh, back.sh, fwd.sh, and mycdlist.sh
They have to be run in a way I just learned about today (in order to export the variables back to the running bash session) using "source" or "." (explained further, below)

I have added the following to my ~/.bash_profile:
####### For scripts, etc. that need to export variables back to bash ######
# create the script as normal
# all variables in the script are set when returning to bash...
# so best to use this only when all variables are safe...
# (Maybe call another script from the one that's exporting variables?)
# either call them as ". script.sh", "source script.sh" or add them here:
# alias script="source script.sh"
alias cd="source ~/myexecs/mycd.sh"
alias back="source ~/myexecs/back.sh"
alias fwd="source ~/myexecs/fwd.sh"
alias cdls="source ~/myexecs/mycdlist.sh"

So, I have overridden bash's "cd" command with my own... we'll see how safe this is with some testing, but currently it seems to work great. (Thinking about using this method for rm to move things to the trash... not sure yet. The trash is kinda annoying sometimes. Or at least to require a verification beforehand...)

mycd.sh is called just like a normal "cd" command, and should, in fact, work identically, with the addition of creating a variable for history...
back.sh is a simple command, has no arguments, steps one step back in the history written by mycd.sh. As set up in my bash-profile, it's called by typing "back" at the command prompt
fwd.sh does the opposite (called by typing "fwd")
mycdlist.sh lists the history and shows where you are currently (no arguments). I call it by "cdls" and its output looks like this (after calling "back" once):
MYCDPOS='1'
MYCDLASTPOS='2'
[0]='/Users/meh'
[1]='/Users/meh/Another Directory' <-- You Are Here [2]='/Users/meh/Another Directory/AndYetAnother' Here are the files (Don't forget to chmod +x). Oh, one thing... I'm not a genius, and lots of what's in here is new to me as of the past few hours... it hasn't been tested for longer than that. I'll post updates if I revise these. ******** mycd.sh: #!/bin/bash if [ "$MYCDPOS" == "" ] ; then MYCDLASTPOS=0 MYCDPOS=0 MYCDHIST[0]="$PWD" # Make these available to scripts that are called WITHOUT "source" # (Actually, I don't think this works... mycdlist was difficult with this assumption) export MYCDLASTPOS export MYCDPOS export MYCDHIST fi MYCDPOS=$(( MYCDPOS + 1 )) if [ $(( MYCDLASTPOS >= $MYCDPOS )) -eq 1 ] ; then
echo "- Overwriting history -"
fi


MYCDLASTPOS=$MYCDPOS

#echo "$@"

#cd "$@"
### Stolen from /usr/bin/cd from: $FreeBSD: src/usr.bin/alias/generic.sh,v 1.2 2005/10/24 22:32:19 cperciva Exp $
#builtin ${0##*/} ${1+"$@"}
# Doesn't work, I assume, because this is technically mycd.sh even though it's aliased as cd
builtin cd ${1+"$@"}

MYCDHIST[$MYCDPOS]="$PWD"


*************** back.sh:


#!/bin/bash

# Check if there's any history yet...
if [ "$MYCDPOS" == "" ] ; then
echo "- No history yet -"

# Check if there's still history to enter
elif [ $((MYCDPOS - 1)) -lt 0 ] ; then
echo "- End of history -"

#This shouldn't happen in the back case, but it's still a decent test...
elif [ "${MYCDHIST[$((MYCDPOS - 1))]}" != "" ] ; then

MYCDPOS=$(( MYCDPOS - 1 ))

# Check if we're entering old history...
# This happens when back is used a couple times
# then mycd is used, then fwd is used...
# mycd will place new entries beginning at the last
# position used (via back/forward),
# which might overwrite a history entry,
# but it doesn't clear all entries
# This doesn't matter, but it might be helpful to know
if [ $((MYCDPOS > MYCDLASTPOS)) -eq 1 ] ; then
echo "- In old history -"
fi

echo "'${MYCDHIST[$MYCDPOS]}'"
builtin cd "${MYCDHIST[$MYCDPOS]}"

# WTF?
else
echo "- WTF? -"
fi




***************** fwd.sh:


#!/bin/bash

# Check if there's any history yet...
if [ "$MYCDPOS" == "" ] ; then
echo "- No history yet -"

# Check if there's still history to enter
elif [ "${MYCDHIST[$((MYCDPOS + 1))]}" != "" ] ; then

MYCDPOS=$(( MYCDPOS + 1 ))

# Check if we're entering old history...
# This happens when back is used a couple times
# then mycd is used, then fwd is used...
# mycd will place new entries beginning at the last
# position used (via back/forward),
# which might overwrite a history entry,
# but it doesn't clear all entries
# This doesn't matter, but it might be helpful to know
if [ $((MYCDPOS > MYCDLASTPOS)) -eq 1 ] ; then
echo "- Entering old history -"
fi

echo "'${MYCDHIST[$MYCDPOS]}'"
builtin cd "${MYCDHIST[$MYCDPOS]}"

# Reached the end of the history
else
echo "- End of history -"
fi


***************** mycdlist.sh:


#!/bin/bash

MYCDTEMPitemNum=0

echo "MYCDPOS='$MYCDPOS'"
echo "MYCDLASTPOS='$MYCDLASTPOS'"
#Allegedly (and experimentally) there's no way to export arrays
#Thus mycdlist.sh must also be called via "source" or "."
#even though it's only *reading* the variables which are shown
#in bash when you type "set." I'm no export expert, this is kinda voodoo to me.

#echo "MYCDHIST="

if [ "$MYCDPOS" != "" ] ; then
while [ 1 ]
do
MYCDTEMPitem="${MYCDHIST[$MYCDTEMPitemNum]}"
# echo "item='$MYCDTEMPitem'"
if [ "$MYCDTEMPitem" == "" ] ; then
break
else
if [ $MYCDTEMPitemNum -eq $MYCDPOS ] ; then
echo "[$MYCDTEMPitemNum]='$MYCDTEMPitem' <-- You Are Here"
else
echo "[$MYCDTEMPitemNum]='$MYCDTEMPitem'"
fi
fi
MYCDTEMPitemNum=$(( MYCDTEMPitemNum + 1 ))
done
else
echo "- No history -"
fi


************ That's it! I suppose zip files would be nicer...

ó vs ó

(Wow, I can actually see the difference, when typed in this window!) ó vs ó ó vs ó ó vs ó
Maybe not... might just be antialiasing...
Anyhow.

Apparently MacOS's bash handles these differently in different cases.

Comparing the following two strings returns FALSE:

'Debaixo Dos Caracóis'
'Debaixo Dos Caracóis'

whereas comparing these two returns TRUE:

'Debaixo Dos Caracóis'
'Debaixo Dos Caracóis'

Duh!

The weird thing is that they come from the same source. The only difference is that one was entered directly with the filename (which contains this string) typed using tab-completion, and the other was entered via for-loop of all files in the directory. Seems like a bug to me, but what do I know?

Some investigating led to how to remove accents from characters: Source
It didn't work for me directly, I had to do some fiddling to get any conversion for the second string (otherwise it would return "iconv couldn't convert")

using the command echo "$string" | iconv -t UTF-7 I get the following two values:

'Debaixo Dos Carac+APM-is'
'Debaixo Dos Caraco+AwE-is'

So, apparently the two accented o's are coming up different, even though they appear the same! Again, oddly, if I run my script within a for loop iterating over all files in the directory, I get "o+AwE-" and if I use tab-completion on the command line I get "+APM-" and the strings match.

Further investigation reveals some useful info: printf can be run from the command line! Source


$ first=`echo "+APM-" | iconv -f UTF-7 -t UTF-8`
$ second=`echo "o+AwE-" | iconv -f UTF-7 -t UTF-8`
$ echo $first
ó
$ echo $second
ó
$ printf '%d\n' "'$first"
-61
$ printf '%d\n' "'$second"
111
$ if [ "$first" == "$second" ] ; then echo YEP ; fi
$

So there you have it... their values aren't even the same. Are they ASCII? I have no idea. This locale and Unicode and other codepage stuff completely eludes me. Here's the page that can tell you all about it. It's WAY over my head: Locale And it doesn't even seem there's such thing as a universal Unicode chart (like there is for 7-bit ASCII)

All I know is that my bash is set with a locale of en-US.UTF-8 and apparently that doesn't match the filenames on my hard drive (?!)

That "o+AwE-" is strangely remniscent of how accents (used to?) be entered on Macs way back in the OS7.5 days... first you typed the letter, then some combination of CTRL and whatnot. I was fascinated by it once and wrote a whole chart. The "+APM-" seems more like PC-style entering a value directly using ALT-###, but I could be imagining things.

This would make my whole project extremely more difficult, except I'd already been working on fuzzy string-matching for differences like McDonalds vs MacDonalds so thankfully I can use that instead of trying to figure out a table of special cases like this. Otherwise, frankly, I'd be at a complete loss as to how to procede without dropping the character entirely. Even the iconv locales don't seem to convert them to anything directly-comparable (only visually). Actually, it could still become a problem for filenames with too many accents... UGH

MP3 Spectrograms

Since MP3s are encoded by frequency-content, shouldn't it be *extremely fast* to convert an mp3 to a spectrogram? Utilities I've seen, so far, (such as sox) seem to convert it to samples first, then back to frequency-content.

---

Been looking into it, a bit. I think the reason this isn't highly-effective is because the actual frequency-content encoded into an MP3 bitstream is something like 32 (or 16?) samples... so even if a DCT is visualizable similar to a FFT spectrogram (which I have yet to find on the 'net), for an MP3 it would only be 32 frequencies tall (including DC), (and *really* wide). I can't quite wrap my head around all this, but I think that's the jist. So, I guess lower frequencies appear DC in these small snippets.

Also, there's something about frequency subbands and long vs short blocks which I can't wrap my head around, either. From what I can piece together from the libmad code, the inverse-DCT seems to be performed directly on small chunks, written directly into an array of samples. I can't figure out where the subbands come into play, nor if they somehow overlap... (which would, I presume, imply "sampleArray[i]+=" instead of "sampleArray[i]=").

This wasn't my original intent, but my original project takes literally 24 hours to process 7GB worth of music... so I guess it was a worthy venture to look into.

Script-fu

I shoulda known it would be slow... but this is absurd. A much more complex program in C processes this image in less than a minute... Script-fu's been running for over an hour and is only at 10%.

That's what I get for spending two days learning a new language. I shoulda known by "script" in the title...

"Preparing to remove partition"

I briefly tried Ubuntu on my PowerBook G4 and haven't touched it since, so decided it was time to free up those partitions for MacOS.

Enter the problem... Click the partition in Disk Utility, click the minus button, and apply... and it hangs, forever, no messages in the log, just hangs at "Preparing to remove partition." Even tried booting from the MacOS Install CD, same thing. There're quite a few posts about this online. Most seem to think that using Ubuntu's partition manager somehow caused the problem... Most suggest backing everything up and writing a fresh partition table from Disk Utility on the MacOS Install CD, then doing a restore from the backup. Others suggest using linux's partition utilities from now on... (which is silly if you're trying to *remove* linux).

I've figured out a trick, I guess... resize a partition (using Disk Utility). Not sure if it matters which one... as long as it's possible to resize it. Best-bet, erase/reformat the unwanted (ubuntu) partition into a Mac resizeable format (Mac OS Extended, Case-sensitive, Journalled, in my case). Resize that partition to something smaller. Afterwards it seems to delete partitions as expected. (Hopefully I didn't jinx myself by saying that and it still boots next time!)

----

Turns out it's a tad more complicated if you want to do more than just delete the partition (and why would you want to do that, instead of just reformatting, unless you planned to make new partitions of different sizes, or merge two partitions, etc?).

In my case, the Ubuntu partition was somewhere in the middle of the drive, and I wanted to merge it with later partitions to make one large partition. (This is a feat in itself, because merged partitions will only keep the data from the first in the partition-list... read below) Here's a link that got me started: http://macheist.com/forums/viewtopic.php?id=15828, and another: http://ubuntuforums.org/showthread.php?t=1181936

First: Run "diskutil list" from the terminal... (and "man diskutil"!)

And, a handy trick I discovered in the first link, create a blank disk-image, create a partition-table similar to the one you're planning to modify, and try everything you're planning to attempt inside that disk-image first. (Handy for making sure the merge command is going to keep the files on the first partition, among other things... like discovering that "eraseVolume" does not erase the volume from the partition table, but reformats it.).

The problem with creating a new partition and/or merging, at this point, arose because of the *hidden* "Boot OSX" partitions located before each partition, and the "Apple_bootstrap" partition created by ubuntu. These were not deleted with the deleted partition(s) with which they were associated, and are located in the space that otherwise appears empty. "Partition failed with the error: MediaKit reports partition (map) too small." I have no idea how Apple even thought the resize function could work in this case... (I can't recall how, but long ago I set up Disk Utility to show hidden partitions. This can also be done via diskutil in terminal).

As I recall, I ended up reformatting the BootOSX partitions into a usable-viewable format, then merging into/past them (more on merge later). Alternatively, and more intuitively, after reformatting (in Disk Utility, if you can figure out how to show hidden partitions), they'll show up in the partition-list and can be deleted. BEWARE: The BootOSX partition associated with your OSX partition is *necessary for booting* so be sure you know what you're doing! As far as I can tell, the "Boot OSX" partition that's located *immediately before* the OSX partition is the one that boots it, but I don't know this for certain for all cases.

As for merging two (or *multiple*) partitions, look into the man-page for diskutil. (The terminal command is: diskutil merge "format type" "name" disk#s# disk#s#) The format-type and name are necessary, even if you're not planning to reformat, it doesn't seem to affect the drive if everything's right.

Notes: I'm running 10.5.8 (Leopard? Tiger? Bobcat? Puma? I have no idea) on a PowerPC G4. These BootOSX partitions may vary a bit on intel, I don't know. Also: "Disk Utility" is the one located in Applications/Utilities/Disk Utility, and "diskutil" is a terminal (command-line) program akin to fdisk with a bunch more features).

Hope this helps someone!

sharing from DOS woes and solution

It's easy! Just follow the instructions posted all over the web... (e.g. here: http://bbright.tripod.com/information/dosnetwork.htm)

Basically, download a "new" version of "net.exe" (from WFW3.11) and its associated files, it adds the command "net share." It'll complain that share.exe doesn't exist, or wasn't loaded, but they've even got that covered; just ignore the message (you don't need it, according to MS, or create an empty file called share.exe so some other programs won't complain).

If you're setting it up from scratch, those instructions should do it for yah.

BUT! It didn't work on my system (which already had networking set up, just not sharing). I don't know what's going on with my setup... I do know this much: a Google search for the error I'm receiving returns ziltch, nada, literally. It's hard to believe... so here it is:

I try: net share shared=c:\shared

and it replies: "Error 7381: File sharing has been disabled by your network administrator."

(Update: I found the solution. wfwsys.cfg was the culprit, so you can save yourself the boredom of reading below, except at the very end... though there is some useful info re: mapping a drive instead of start - run \\dosMachine\share, etc.).

I've been at this for hours, so you can imagine I've looked at system.ini countless times, and tried everything I've found on the web... (which is pretty limited, since no one mentions this message). I *am* the network administrator dangit! I don't know what's wrong.

----
I have since backed up my old configuration and started fresh using the instructions at http://bbright.tripod.com/information/dosnetwork.htm (and many other locations). And have gotten rid of the dreaded "disabled" message. The command "net share" shows the shares, but I can't get my WinXP nor my Mac to connect to it using either the name nor the IP. I can ping it from both machines.

The Mac gives an error almost immediately: "There was an error connecting to the server. Check the server name or IP address and try again." It sounds vague enough, but I tried connecting to an IP I know doesn't exist and receive a slightly different message after quite some time... so it seems the Mac is at least aware of the DOS box (maybe only because it's acting as the DHCP server?)

The XP machine seems to just time-out after quite some time with the ol' "The network path was not found."

Now, I've had trouble connecting the DOS machine when running Win98SE to my Mac shares... that's another story entirely. I read somewhere about an update to NTLM2(?) that was supposed to fix it, but it didn't work for me. So I've been connecting to the Win98 share from my Mac, instead. But now (in DOS) I can't connect either way. I can, however, connect the DOS machine to a WinXP share, and the Mac to the same WinXP share... so at least there *is* a way to transfer files between DOS and the Mac. (The Mac is my main machine). But, I was able to do that long before I started this venture, and I've wasted countless hours to get just sparse nibbles of hope for what would've been a minor inconvenience at most... (so hopefully this diatribe helps someone, now that I've figured it out...)

--------

I managed to get WinXP to connect to the DOS share. I don't remember exactly how. I did notice that the MS Networking Client created a few entries in system.ini that weren't correct (two entries for protman, so I got rid of one). Also, It wouldn't connect using Start - Run \\dosServer\share. The new error message was something along the lines of "invalid resource." So I tried mapping the drive directly and it worked!

Still can't get the Mac to connect to it, I've tried many different methods: from Connect To Server (in the finder) to using mount through terminal, to using smbclient and others. Each method gave a different error. At one point I got something like "invalid header received from server," and another mentioning something about user-level sharing not being enabled. Anyhow, I chalk this up to MacOS... and someone online said something about SMB probably not being tested too thoroughly on MacOS since "the developer doesn't have a mac" (?). Also mention of Apple disabling some types of authentication due to insecurities (most likely to exist in old DOS networking!) But I dunno.

I guess my goal was to figure out what was *causing* the original error message (sharing disabled by my network administrator), and instead ended up installing the DOS networking fresh (which fixed it). Maybe one of my original networking files had been modified by a net-admin (I acquired this network boot disk from an old job), maybe it was a combination of differing versions of drivers and utilities (the version of net.exe on the network boot disk did not have support for "net share"), maybe something was loaded (or not loaded) to cause the problem. I did notice that the ms network client installer loads two additional drivers in autoexec.bat. I may look into it further. For now, follow the instructions at the link above and do a fresh install (be sure to back up your original files! I have them in two separate directories, also config.sys and autoexec.bat) and look closely at boot messages and system.ini, try mapping a drive instead of using Start-Run, and that's what worked for me.

-------
FOUND IT!
The file wfwsys.cfg has apparently been customized. You can get a functional normal one from the MS Network Client installation disks (downloadable, see above link).

The modified file serves two purposes I can see so far. One is to disable file-sharing from the machine (yay!). The second (and likely the reason it was modified in the first place) is so a username.pwl file is not created each time the boot-disk is used. Not that it would matter, the pwl file would be saved to the ramdrive and lost with a reboot. I think the main reason is so it doesn't give the message asking whether you'd like to create the pwl file every time you log on.

No shit!?

I closed the page, but I'm 99% certain I read that OnTrack Disk Manager breaks all the current size barriers, supporting 136GB+ drives on systems all the way back to the original PC/AT. Could you imagine an 8088 with a 1TB drive?! Have you even *seen* an 8088?

And I just discovered the setup switch to install Win98SE on a 386. WTF is the world coming to?!

Voltage Regulators 102, Op-Amps 101: AC-coupling!

I built this power supply several years ago, always with the intention of adding an amplifier for the current-sense circuitry.

I used a .01ohm resistor for current-sensing, 'cause I didn't want it to interfere with the output voltage. The resistor was tied in series with the +Vout path.

The voltage across this resistor is measured, currently, directly. So, measurements are 1/100th of the actual value (kinda confusing to read on a multimeter).

So I've been fighting with analog circuitry for a few days to try to amplify this 100x. Seems simple enough with the "ideal Op-Amp." Yeah, right. First things first, I have to consider CMRR (Common-Mode-Rejection-Ratio)... something I hadn't considered an issue.

The differential voltage (voltage across the resistor) varies from 0 to 0.04V (with a 4A load, max for my supply, I want to amplify this to 0-4V). The Common Mode voltage (voltage at the resistor, WRT ground) is 0-24V. We're talking 100's of times difference between CMV and differential voltage. I don't remember my dB conversions at the moment, but I'm pretty sure a 100dB CMRR (which is *excellent*, and nowhere near the ability of standard Op-Amps and resistors) is not nearly enough for this circuit.

So, what's happening? As the output voltage of the power-supply varies, so does the output voltage of my Op-Amp, dramatically. The differential voltage (across the resistor) is being amplified in there, somewhere, I think. But it's completely lost.

This is why Analog circuitry has always let me down. It seems like a simple circuit. Even 2 years' training in EE lead me to believe it would be. Instead, it's a battle at every step. The resistors have to be matched to 0.01% tolerance (HAH! 1% is alot to ask for, even in my vast collection of assorted parts.). The op-amp itself has to be of high-quality... (so much for all these standard LM series chips I'd been meaning to do something with). I wanted to do it with a single-supply (+/GND as opposed to +/-/GND) which was the first difficulty which even a "single-supply op-amp" like the LM324 makes difficult. The list goes on.

Here are a couple references I came across to verify my experimental results: http://www.maxim-ic.com/app-notes/index.mvp/id/1180 http://www.maxim-ic.com/app-notes/index.mvp/id/746

So, apparently, high-side current monitoring is difficult. Let's switch to low-side! Still having issues... Not sure why, exactly. But I'm tired.

So: Op-Amps 101: they work best with AC signals (audio, etc), coupled through a capacitor. Anything else and you're setting yourself up for disaster.
Voltage Regulators 102: Measuring current on the high-side is difficult, to say the least.

Voltage Regulators 101

Years ago I built a power supply with two adjustable outputs. It works for most of my needs, but it's still a work in progress. I built in an old digital multimeter with *incandescent display* (no, not LCD, not LED, not even vacuum fluorescent). Actually, that's the main reason I built the supply; I had to do *something* with that unusual display.

Functionally:

The two separate channels are completely independent. I could use it as a +/- supply by connecting CH1's positive output and CH2's negative output to GND. Or I could have two separate positive voltage supplies by connecting CH1 and CH2's negative terminals to GND.

The multimeter is connected internally to readout voltage or current from either channel and also has a third voltage measurement input (the middle terminals), the measurement can be selected via the pushbuttons between the voltage-setting dials.

Electrically:

It has two 24V 4A switching power supplies, on top. I think they were from a laptop. I used a simple adjustable-voltage-regulator circuit for the output; each output can vary roughly 2V-22V, and the regulators are rated to 5A.

The current-readout is a little bit flawed... I designed it to measure the voltage across a tiny-valued resistor in series with the output. I wanted the output voltage to be the least-affected over a wide range of loads. Unfortunately, that means the multimeter displays a fraction of the actual current (I think it's 1/100th) which is easy to deal with if you're using it all the time, but kinda confusing if you only turn it on once or twice a year.

So, one of the things I've been planning to do is add a simple op-amp circuit to amplify the voltage across the resistor to something more logical (1mA = 1mV would make sense!). This is more difficult than it sounds. For one thing, I'm not particularly good at op-amp circuits... It might well be because all the old op-amps I inherited from the 70's are burnt out, because I didn't have nearly as much trouble with those same circuits in school.

For another thing, I have to figure out which power source to run it off of! I might have to build two identical amplifier circuits, one for each channel, running off that channel's power supply. I'm not sure how well this will work if the voltages input into the op-amp are right near the rail. Or another option would be to run it off the multimeter's power supply. Either way, there're limitations. None of the internal supplies are bipolar. Also, I have no idea what would happen to the multimeter if it shared a voltage source with the measurement. It's circuitry is way beyond me (what's this piece of glass with wires coming out of it?! And this welded-shut-aluminum box?).

Tonight I had the brilliant idea that the circuit might work off a single-supply... how those single-supply op-amps work is magic to me... but they have example circuits in the datasheets. Anyways, I came to the conclusion it might be worthwhile to explore...

Part of that exploration came to checking whether there'd ever be a case where the output current would be negative. So I thought sure, what if I had one supply set to 12V and the other to 5V, sharing grounds, and I wanted to make use of the 7V in between...

Yeah, enter Voltage Regulator 101:

I hooked up a resistor inbetween 24V on one supply (long story, one of my regulators blew a long time ago and I don't have a replacement) and 20V on the other and was surprised to measure... no current. Zero (measured to .0001V). I measured the 20V output and saw it at 24V (higher than the regulator can output!). I tried a lower voltage setting, measuring it *with* the load resistor (connected at the other side to 24V)... set it to 20V and it looked like it was working. But when I removed the load, it dropped down to 8V!

Turns out, these adjustable voltage regulators *require* a minimum load. That's handled by the adjustment-circuitry, usually. But, by driving current *into* the regulator, that minimum load wasn't met. Sure enough, the datasheet says: "all quiescent operating current is returned to the output establishing a minimum load current requirement. If there is insufficient load on the output, the output will rise."


Anyways, this entire self-indulgent post to point out this little tidbit, because people use adjustable regulators for power-supplies all the time. They work great as long as your load *is positive*!


Realistically, there probably aren't many cases where this is a problem... Most circuitry returns the current back to ground, anyhow, as well it probably should. But part of the point of having an adjustable powersupply is for experimentation... And this is one thing that could be quite confusing. And, I have thought of a case where it might be handy to use the supplies as I just attempted... The minimum output is ~2V; if I needed 1V (and the regulators worked as I imagined before), I would have set one to 2V and the other to 3V and used the difference. But they don't work that way, so I need to put a note on my powersupply... maybe have a warning indicator if the regulators are dropping out.


In the meantime, I guess this makes my amplifier circuitry easier... I don't have to worry about negative-current cases. (Then again, it *did* work when I set the voltage *much* lower... I wonder if that's hard on the regulator circuitry).

catch-22: water filters which remove fluoride use oxidized aluminum... which is thought to cause alzheimers.

(yeh, I was a health-nut at one point).

Jury Duty and prosecutors

I did jury duty once.

Everyone it's come up with seems to have basically the exact same mentality: "only idiots get stuck with jury duty," IOW: if you're smart, you'll get out of it.

I did jury duty once. This is how it went:

Dude1 and Dude2 have known each other for quite some time and got into a fight and Dude1 ended up needing an ambulance. When asked why by 911, his girlfriend said that there was a fight. Because of this, the police were required to come. Because they were required to come, they were required to take Dude2 and they were required to file a report. Because they were required to file a report, it went to the prosecutor who was required to try to get some money for the county for making use of the police (who were required to be called). Because the prosecutor was involved, Dude1 thought he could make a buck suing Dude2.

That's it. Petty bullshit. Neither Dude1 nor Dude2 would have been in court if the prosecutor hadn't been required to at least ask Dude1 to be a witness for her case which wasn't really even about Dude1, it was about getting back some bucks for Dude2's police-involvement (which no one involved even asked for).

And I didn't even mention the pettiness the prosecutor showed in assuming we, the jury, wouldn't uphold *THE LAW* ("innocent until proven guilty, beyond a reasonable doubt") because "he seemed like a shady character who would do something like that" (actually, undoubtedly-so. Then again the prosecutor seemed to be just downright evil and good at hiding it behind legalese and professionalism).

It's a good thing all the smart folks avoid jury duty so all the dumb-folks can put each other away for petty personal-issues on a hunch... until there's not enough dumbfolks to be put away and they start putting away smartfolks for being unpatriotic.

And now my mom wants to work for the prosecutor "to give back to the community," because she's having a petty bickering-match with her boss.

I'm sure there are cases that are positive... hopefully most. Hopefully some against our country's own law-breaking. I just need to keep telling myself that, because mom's trying to work fo the po-po now.

I-Movie

BIG MISTAKE when trying to make a movie from footage that was originally on VHS:

thinking you can capture the *whole video* into a file on the computer then make clips and edit from there. 

After twenty minutes the audio sync is about twenty seconds off. Granted, I'm working with *old/expensive* and *new/cheap* equipment that really wasn't meant to work together... But I don't care enough about this project, at this point, to invest in both a new computer and a DV camera with firewire out and composite-in just so I can make a 3 minute collage from 4 hours of footage taken nearly a decade ago on an old-at-the-time camera that barely worked, and transferred to a worn-out old VHS tape. Presently, there's nothing really going on in my life to justify a DV camera, it's not really a path I'm interested in going down except for this project, and when/if that time comes the camera I get now will be outdated.

I could probably borrow one from a friend of a friend, or maybe the library...  Maybe I'll go that route some day...

"My education at insert tech-college here has given me a career where, above everything, I feel useful and that I'm making a difference."

Combine that with the guy who says "my education at insert tech-college here has given me a career where I can come home at the end of the day and spend more time with my family" and you've got one useful dude; he's on 24/7!

Besides doing something all day where he's making a difference, he's also looking out for the next generation by spending time with his children. On top of that, he gets the joy of being with them and his wife.

I've met him, he was a real go-getter, quite intelligent, a nice guy, and I'm sure a great father...

It was odd, though; at the time it seemed to me his need to feel useful didn't extend beyond *his* need to *feel* useful, as it seemed (at the time, to me) that he hadn't thought-through what *useful* meant in the grand scheme of things, nor the impact of the difference he was making. Otherwise, I was certain (at the time and for a while thereafter), he wouldn't have felt useful and that he was making a positive difference doing what he did.

Now? I have no idea what to think... Things aren't nearly as cut-and-dried as they had once been to me, which is odd considering how much thought and discussion went into coming to those original conclusions.

I wish I was capable of being in his shoes.

On Google+

Yeah, I've been posting a LOT in the past few days... I have a LOT of rants built-up. I'm sure this will slow soon... Especially considering I haven't even touched anything electronic in months prior to this latest burst.

When I thought about starting this blog, I contemplated looking into Google+. I have no idea what it does, I figured it's just Facebook-Google-style. Which wouldn't be so bad for a rant-column like this. But whatever.

On Google: Back in the day there was AltaVista, Yahoo, and AOL... if you used something else, you were outside the realm of normalcy. I had a friend who told me about Google... This dude was into OpenSource... ran Linux and all that. Listened to indie music before indie music had a nickname... believed in online privacy... Yahknow, a real outsider. So, he told me about Google, and I looked at it, and I thought "wow, here's a great search engine that doesn't give you all the garbage, and is a friend of the OpenSource community..." HAH! I won't even go into what it's become. Oh, and then I read an article about their Beowulf clusters (yahknow, thousands of linux machines... COOL!) And then they stood up when the DOJ tried to subpoena search records from them... I actually respected them for that move! Then I found out that they actually have a *censored* version of Google in China... And it makes you wonder... Their algorithms are pretty good at censoring information already, by burying things that
the mainstream isn't looking for under thousands of pages of pop-culture... But who knows what censoring they're *intentionally* doing here already. I remember when searching google meant actually *knowing what you're looking for* and *knowing how to locate it.* Now, if I do a search for "EDID" I get top results for "Edit" and no info on how to correct the search. I miss my raw-text search engines... yahknow 'EDID monitors OR monitor OR vga -edit AND OSX OR "OS X"' if anyone knows of a better one, or a way to convince Google to work the way I remember... please let me know.

Anyways, Google+ is kinda creepy right off the bat. I tried to create an account using a nickname for trial-purposes and here's what I got:

It's not enough that I submitted to their rigorous Gmail sign-up procedure?!
I don't even want to go into the details of *everything that's wrong* with this... It reminds me of a quote, I'm sure I heard it was a literal quote from someone high-up at Google... basically said something like "when your kids turn 18, they should seriously consider changing their names because of the online profiles they had as kids." Google's scary, sorry. Yeah, blogger's via Google... I know. And it's still my only search engine... And, maybe one day if someone actually bothers to read this blog, I could make some money through their targetted advertising... can always hope :)

Here're some fine examples from the Google+ "Name Policy:"

There's more!

Violations!

Nah... we're not talking "recommendations" here, we're talking flat-out "violations." I won't bother to paste all the BS they claim they can and will do if you violate their policies... let's just say it's ugly.

Appeals! This is the best part, seriously... They have this down to a friggin' science... It's more complicated to appeal your name on Google+ than it is to get a replacement Social Security Card (I've had to do it). And you have to give them more *personal* information!

And name-changes... again with the more complicated and rigorously-enforced than Social Security:

I like this part at the bottom of the sign-up page:

HAHAHAHA "and almost nothing with your boss." Why? Because all the people who'd be willing to submit to these terms-of-service either are too young to have a boss, or never aspire to working for a place like Google? 'Cause, seriously... I'm starting to think the Google services are nothing more than weed-out processes for (or great means for spying on) potential employees.

Oh good god, I really worry what tinted-window-vans will be parked outside my apartment after posting this.

RED = POSITIVE, BLACK = COMMON

It's simple... Everything electronic as far back as I can remember (and I've been taking apart electronics since I was 6) has had this scheme. RED is connected to the positive terminal, and BLACK is connected to the common (usually "GROUND", "COMMON", or "RETURN") terminal. We're talking 5V systems, we're talking PCs, we're talking remote control cars, TV remotes, VCRs, CD players... When you enter college for EE you're provided two wires with clips for your power supplies... a black one and a red one. The labels on the power supplies are Red and Black. Guess which terminals they are... For your signal generators you've got a red connector which is the signal and a black wire which is the ground... It may not be rocket-science, it may not even make 100% sense, but it's pretty simple and it's damn-near universal.

So why is it that two devices I've worked on in the past few days have EVADED this scheme?!

Example 1: PowerBook G4: has a connector with three wires; Red, Black, White running to the hall-effect switch used for putting the system in standby. As I recall (I've since closed it, and have no intention of opening it again) RED was the signal back from the hall-effect. WHITE was GROUND, and BLACK was +3.3V.

Example 2: USB mouse. My stupid mouse, the cheapest you can buy, has a break in the cord near the connector... had to cut it apart to resolder... Wait, something's wrong... what's this red wire doing on GND and this yellow wire doing on 5V?! I musta twisted something when I cut the cables... I checked my logic numerous times... opened up the mouse itself... sure enough, the PCB's labelled with the USB connections, and sure enough they're wired in that weird scheme. (Gray and Black are apparently the USB data signals).

I'm just saying...

Example 1A is a little less exemplary: multiple iBooks: have a four-wire connector leading to the LCD backlight inverter. It's handy to have a 1+kV voltage source around... if not to light up LCD backlights, then just to give yourself a good zap every once in a while. (Seriously, it's a health-thing... kinda like accupuncture). Not *certain* they didn't use the regular scheme, but after Example 1, I'm no longer convinced the reason it wouldn't light-up when connected to 5V or 12V was due to one of the other wires being an "enable." (I still have 'em sitting around for later electropuncture experiments, maybe I'll look at the circuitry next time).

Anyways, it's just stupid. Plain and simple. I have a hard time believing it's not intentional... some Chinese kid is laughing his ass off right now because a repair job on a mouse that wasn't even worth the five minutes it woulda taken to repair turned into twenty minutes... Forty, if you count the ranting here. Meh, I guess it's kinda fun to be frustrated sometimes over stupid stuff with no real victims. (Sorry chinese kids).

(And, if you want some other ranting, this German freak I worked for for way too long insisted that Europeans use Blue for positive and Green for ground, and insisted I follow the same scheme, like I never worked with electronics before I worked for him... goddamned German freak... I love him like an uncle, but I'm still not on speaking terms with him... certainly it's because of the Blue/Green thing. And another thing, Blue and Green?! Seriously!? What about people who're colorblind?! What about low-lighting conditions? I'm pretty sure he just made that shit up so he could use two wires next to each other on rainbow ribbon-cables.)

Time Wasted: Dynex Mini-DVI to Composite (TV) adaptor

I bought this thing on ebay for a few bux. Was so ready to use my TV for movies instead of the tiny LCD on my PowerBook G4 (yep, I'm running an OLD system).

Got the thing and was immediately having trouble. I'm sure you can find out all about its incompatibility with my computer online. But I was so sure it was just a timing issue. I discovered the device actually reports itself to the computer as something like "fake device." So, that's it! All I had to do was manually configure the display parameters...

Yeah, manual display configuration... strangely reminiscent of my old XFree86 days with a fixed-frequency monitor. No biggie, I've done this before. Found a couple utilities on the 'net that actually allow you to manually tune those parameters in OSX (holy crap).

I fought those params for HOURS... looked into the NTSC specification, figured out numerous methods for calculating proper values that would work with a TV that ALSO were outputtable by my vidcard...

First of all, I could never get a timing value that synced with the TV. Either I had multiple pictures, or the picture would scroll... Yeah, it's just a timing thing, I'll figure it out, right? Found a bunch of timing-parameters for NTSC that people have used to drive a TV straight from their VGA port... yeah, that's basically what this cheap adaptor is doing...

But there was something else... it was only in black and white.

Boiled down to one thing I hadn't considered... It may well be possible to use a simple circuit (like the one in this adaptor) to merge the timing signals with the video signals... but there's no way feasible to take three separate color signals and merge them into a single composite output.

Basically, it was a tremendous waste of time. I learned a bit, I suppose... but I spent at least two days fighting with that. There's a lesson here, somewhere... I need to learn to not fight to make a $3 adaptor do something it wasn't designed to do. This adaptor was NOT designed to work with this laptop... it was designed to work with ones that have that circuitry already built-in (probably in the GPU itself)... which is why the Apple adaptor that's made for this computer costs upwards of $40.

This was never an issue of "well, if Apple can do it with their adaptor, then this adaptor just needs some timing parameters, or the mac just needs to be convinced this is an Apple adaptor" it was an issue of this is a simple pass-through adaptor and the Apple one has active circuitry inside... I've run into these things plenty of times, I should have known better.

What did I learn? I don't know, actually... I guess I learned that it's possible to change timing parameters manually on MacOS just like can be done for X... that's kinda nice to know... not that I've needed to mess with that stuff for nearly a decade. I guess I learned a little bit about NTSC and composite signals... I could do to learn a little more... (how do they merge that color info, anyways?)

Actually, after writing this, there's one other possibility I hadn't thought of... I was messing with timing parameters, assuming the device was merely passively merging the colors and timing from the VGA output into a single composite output... There is a small possibility that active-circuitry I was talking about is in fact inside the mac, and all I have to do is fake the EDID information so instead of reporting "fake device" to the system, it reports the same info as the Apple adaptor would... then the drivers would recognize it and activate that circuitry. It's plausible... (Though, the driver loaded by the system *was* the TVOut driver... I dunno.)

I am sure this isn't worth all this trouble... but these sorts of challenges seem to be the only types capable of keeping my mind at bay these days. What kinds of challenges? I guess (though I'm not sure) small-scale ones that are easily shoved to the side when they don't work... can be picked up months later when I get a tiny bit of inspiration like this and need something to drown out my thoughts... This is the dilemma of the year, if not longer... what can I do with the brain I've got, the way it's been working lately? Sleep...