For getting a handle on the screen bitmap, you can start out with just BASIC until you find it too slow:
PSET (237,63) ' Bottom right pixelPRESET(237,63) ' Clear that pixel As for having to replace/refresh the chip often, here’s the original passage in German: Nun werden die Druckeranschlüsse mittels eines Kabels mit der IC-Fassung verbunden, auf die später das DRAM gesteckt werden soll. Diese Fassung sollte eine gute Qualität haben (vergoldete, gedrehte Kontakte oder eine ZIF-Fassung), da der Chip ja doch öfters gewechselt wird. And, yes, indeed, now the fun begins! :-) —b9 On Tue, Feb 24, 2026 at 4:02 PM Scott McDonnell <[email protected]> wrote: > The 4164 is actually two arrays of 128x256, 256x256 total, but there is a > gap in between the arrays that would mess up the image. The 128x128 is just > how many have used it for simplicity by just reading a portion. Since it is > random access, you can read as much or as little as you want. > > 240x64 is the resolution of the Model 100. If we turn the DRAM to > landscape mode, the orientation fits pretty well. We can just read 240x64 > directly. > > But it would be fund to also try it out on a Model 200. > > I think that must be a translation error. He is saying that DRAM needs to > be refreshed regularly unlike SRAM. > > I just received the 4164 today, so the next step will be to get the metal > lid off safely and glue a piece of glass over it. After getting it spitting > out bits, I will then need to play with optics. The fun begins. > > Scott > On 2/24/2026 6:20 PM, B 9 wrote: > > 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 >>> >>
