This will be very helpful. Thank you! I also need to do some studying on
bitmapped graphics on the LCD.
Scott
On 2/24/2026 5:51 PM, B 9 wrote:
P.S. For reading the barcode port on the M100, I think the best
resource I've seen is Oppedahl's "Inside the TRS-80 Model 100" (Ch
14., pp. 231–237) which includes sample code and even a little
schematic of how to use an opto-isolator so you don't blow out the
port. You can either poll the port, which probably makes more sense if
you are going to try to use similar code on the C64, or enable the BCR
interrupt which calls whatever handler you place at address F5F9 every
time it sees a "white" line.
You can get a sense for how it works with this one-liner which beeps
whenever pin 2 is grounded:
```BASIC
1 IF 8 AND INP(187) THEN BEEP:GOTO 1 ELSE 1
```
—b9
On Tue, Feb 24, 2026 at 2:14 PM B 9 <[email protected]> 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
