Your sync method sounds reasonable. If it doesn't work, maybe consider Stephen Adolph's hardware hack to send a signal to the gluelogic to start sending data .
Yes, M100 LCD is black and white only, zero shades of gray. I believe the Model 100 screen is 240x64 pixels. Since you are using a 128x128 chip, you may want to look around and see if anybody you know has a Tandy 200 as those have 240x128 pixel screens. Both Firefox translate and Google translate had some difficulties with that German article, but I think I got the gist. One question: Why does he say the RAM chip will need to be replaced often? —b9 On Tue, Feb 24, 2026 at 2:59 PM Scott McDonnell <[email protected]> wrote: > Yes, the scanning and timing would be done in either a CPLD or a small > micro. Probably will cheat and use a small micro just because it will have > the clock, etc.. already and keep parts count down. And sadly, modern > micros are cheaper than PLDs or discrete chips. > > My current plan is to use different pulse widths for timing information. > The micro would continuously scan. At the beginning of the scan, it will > output a longer pulse to indicate frame start. Then just shift the pixel > data. I may end up inserting a new line sync if necessary, but I don't > think I will need to since we can just count pulses from the start point. > > Some level of gray scale is possible by repeatedly testing a bit and > determining the time it takes before it fully decays and flips to zero. But > that is irrelevant to the Model 100, I think (can't do greyscale on the > Model 100 LCD, right?) > > On the C64, I was going to use the 4 direction lines for grayscale and the > fire button for the sync pulses. > > The idea is that if I can make this work on a Model 100, I should be able > to make this work on an 80s robot. > > Here is some information on the concept. Lots of older magazine articles > about it as well. > > http://www.kurzschluss.com/kuckuck/kuckuck.html > > Scott > On 2/24/2026 5:14 PM, B 9 wrote: > > Cool idea! I don't think the Bar Code Reader port has enough (any?) output > ports to address the RAM, so I'm guessing your "glue logic" is going to > spew bits to the BCR, right? What's your thought on synchronizing with the > M100? > > Whether this ends up working or not, I'd love to see whatever you come up > with. > > —b9 > > On Tue, Feb 24, 2026 at 8:33 AM scottgmcdonnell <[email protected]> > wrote: > >> It certainly would. And it has all the signals required to not need much >> additional circuitry. >> >> But it is more of a 'because I can' excercise. Speed is not a major issue >> for this. The Model 100 serial speed at the barcode port is capable of >> speeds much faster than such a camera. >> >> As well, this is not a realistic justification (doing 1980s marketing >> roleplaying here), but the average person would be more willing to plug a >> peripheral in to the barcode port. The system bus feels more 'advanced' and >> "Radioshack technician" installable. >> >> Not that this is 1984 and we are making an actual product or dealing with >> a "typical user" today. >> >> >> Anyway, just for novelty as well as the ability to make one circuit that >> works with both the C64 and the Model 100. >> >> Scott >> >> Sent from my T-Mobile 5G Device >> >> >> -------- Original message -------- >> From: "Alex ..." <[email protected]> >> Date: 2/24/26 8:51 AM (GMT-05:00) >> To: [email protected] >> Cc: [email protected] >> Subject: Re: [M100] DRAM camera capture on the Model 100 >> >> Wouldn't the system bus interface be your best bet for speed? >> >> On Tue, Feb 24, 2026 at 5:14 AM Scott McDonnell < >> [email protected]> wrote: >> >>> In my robotics group, we have been talking about an old concept of using >>> a DRAM IC as an image sensor. >>> >>> Essentially you take an old DRAM IC in ceramic package with the metal >>> lid and knock off the lid. You pre-charge the DRAM with all 1s and then >>> as light hits each cell, it drains the capacitor and will flip the bit. >>> The brighter the light, the faster it flips. >>> >>> A 4164 DRAM of this type has two 128x256 arrays with a small gap in >>> between. Generally one would just use 128x128 of one half. The camera >>> lens would be arranged to focus on that. A 4164 DRAM is a 1 bit by 64K >>> DRAM. Just one digital output. >>> >>> Now, from robot vision, my brain started working out how to off-load a >>> bunch of the scanning and glue logic, I came to the conclusion that I >>> could capture an image through the joystick port of a Commodore 64. >>> >>> And then I thought, Hmm, this should be possible on the barcode port of >>> the Model 100 as well... >>> >>> On the joystick port, I was thinking a frame sync and the one digital >>> bit. This could be modified to use a longer pulse to indicate a frame >>> start on the Model 100. >>> >>> This could be used to scan in a document or take very, very low >>> resolution images on the Model 100. >>> >>> Doing it through the barcode port would mostly just be for the novelty, >>> of course. The printer port might be the better option. >>> >>> >> >> -- >> Disclaimer: Any resemblance between the above views and those of my >> employer, my terminal, or the view out my window are purely coincidental. >> Any resemblance between the above and my own views is non-deterministic. >> The question of the existence of views in the absence of anyone to hold >> them is left as an exercise for the reader. >> The question of the existence of the reader is left as an exercise for >> the second god coefficient. (A discussion of non-orthogonal, non-integral >> polytheism is beyond the scope of this article.) Thanks /usr/games/fortune >> >
