Charles J Knight wrote: > > > > I've not heard much about the Nipkow disks lately, anyone? > > > > Next time I make photo film for PC boards, maybe I'll make a disk. > > Could make a bunch at a time for not too much money. If I can find > > some > > LED array that has good density (like better than 0.8+mm between > > LED's!) > > it'd help; 0.8mm LED width means that we have a limit of about 1mm > > per > > LED, so 25.4 dots/inch, for the emitter array. I'd really *like* > > 300 > > dpi, for a 640x480 HUD. > > 2 things -- why would you need an array for a nipkow device, since they > are supposed to use a single modulated source per display? Unless > you intend to build an array of linked displays, like Rehmi did. (4 > displays > "on top" of each other, all on the same disk) The more LEDs you have, the more light you can put on the display, and easier. (I may go for the "cylinder" or "cone" method; whatever method, you can put more light on screen with many LED's, than with just one.) You then assign pixels to the individual LED's and to a certain slot on the disk/cone/cylinder. Instead of 480 apertures and one LED, you can use 20 apertures and 24 LED's, or 10 apertures and 48 LED's, or whatever; You then can use say 5 sets of apertures per revolution and still have a fast refresh rate, with a 1/5 as fast motor speed on the disk/cylinder/cone, which is good. On thinking, it's not that bad a problem that the SMD LED's are apart, you just scan like this, interlacing the pixels; 1 stands for the pixels that LED 1 makes, 2 stands for the pixels that LED 2 makes, and this could be either a row or a column, designers' choice: 1234567812345678 (with 8 LED's for this example.) So, if you make your LED spacing uniform, on second thought, you don't need 300dpi, just to interlace. Somewhat harder to do, do-able though. You then modulate all those LED's as appropriate, you still get the slightly warped display potentially (arcs and longer display on one side than the other, etc.) You might need small trim pots, 1 per LED, or some PWM value stored in EEProm or something to balance LED brightness, maybe I should look at this design again and figure out a better way to do that, not all LED's have identical emissions (pretty close, though), but some sort of self-levelling should be do-able here if it's a problem, with a phototransistor or could use another LED as a light sensor (When you shine light onto some LEDs, they'll generate voltage, some LEDs do this really well, others not well at all.) Probably, not a problem at all, just use the LEDs straight. Spacing can be arranged pretty closely, use a "standard shim" between the LEDs, hold them in place while held a precise distance apart, solder, remove shims. I suspect that'd do! > And, shouldn't the array used by the P4 be available somewhere, > commercially? Perhaps as a Nintendo Virtual Boy repair part... Could be! Does that array do what we want, or can it be made to do what we want? <G> > BTW: I took apart my VB, and the two displays are utterly independent, > physically. Electronically, they are both fed from the same board, which > implies that if there is a link it is probably the sync signal from the > driver > board. Nothing else, including the display information (displays are > independently addressable) is common to them both. > > > I've seen the Model 100 rigged for data logging in the Arctic; You > > > > batteries, which do OK in the cold as well.) Good machine for it's > > time, and fairly expandable. (Electrolytics don't freeze well...) > > It's actually a pretty good machine for any time. I wish someone > would produce a pocket version of the M100 -- the Game Boy is > a Z80 based machine, so it's "close." Look at the HP200LX, see http://www.hplx.net/ and so on; Not a bad machine, lasts a week or so on 2 AA nicads, CGA mono screen, has a low-power PCMCIA slot that'll handle Flash easily, can be upgraded to 96Mb RAM disk and 32MHz clock on it's 80186 CPU. (I do that upgrade.) One's in my pocket right now <G> > The whole thing could fit into my phone number "organizer," and > still have a decent keyboard. > > Doesn't seem like it'd be too hard to produce a "programmable > organizer" device, based on the M100. > > > Newer machine IS faster, it's just that some coding is good at > > Of course -- but Win95 is so pathetically inefficient, and ridiculously > bloated, that I can't stand using it. W98 is slightly more efficient, > but still just as bloated. > > > nice tight self-modifying assembly, but so few can cope with it <G> > > Actually, tomorrow is the last day of my assembly course, other > than the final exam, at least. Doubt they recommend self-mod code <G> It's really great for things like when some person's going to try to crack your code with a simulator; FEW simulators properly model the read-ahead of the pipelined CPUs we run (and have run for some time!) - the CDC 6400 I used to do self-mod code on, had a Sim that was pretty good, but didn't do this. So the first thing you'd do when trying to defeat "crackers", was write to *+1 in codespace, in the 2nd or later instruction of a word (up to 4 instructions per word on that 60-bit beast), the next instruction had already been read in by the actual CPU - the simulator didn't (until I changed it at least for my personal use!) know better than to read that modified jump instruction you'd just written there, that would never be seen by the CPU, so the actual CPU went one way and the cracker went another, into a twisty maze of little passages, all alike, hopefully to never be seen again <G> A few nice tricks like that, and your code to prevent people playing "Advent" during daylight hours, couldn't easily be cracked. > -- Chuck Knight Mark -- I re-ship for small US & overseas businesses, world-wide. (For private individuals at cost; ask.) -- Subcription/unsubscription/info requests: send e-mail with subject of "subscribe", "unsubscribe", or "info" toWear-Hard Mailing List Archive (searchable): http://wearables.blu.org
From Wear-Hard Mailing list Archive (WH)
Maintained by R. Paul McCarty
Archive created with babymail