I now see the sentence you were referring to. Not really sure what they
mean about changing the chip frequently. I could guess that he meant for
experimenting with different brands, but I am not sure. If he was not
sealing it with glass after de-lidding, he could be referring to it
oxidizing or perhaps concerns about old parts having bad bits (dead
pixels). But those are guesses.
I bet basic will be plenty fast.
I ended up splurging and buying the MicronEye Bullet camera for the
Commodore 64 that I had been watching on eBay for years. $650, but it is
the only one I have seen listed in the past 6 years, so I finally bit
the bullet. This was a commercial product based on the IS32 which
appears to be a professionally modified 4164 DRAM IC. So I will at the
very least have some frame of reference.
Scott
On 2/24/2026 9:54 PM, B 9 wrote:
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 pixel PRESET(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
