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
