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"
