[M100] BackPack - read data from CLI

[Georg Käter]

Hello together,

 

I tried to read "settings" from a BackPack+ with the following, but w/o success

 

10 REM read settings from BackPack/BackPack+
20 REM set variables
21 MAXFILES=2:DEFSTR A-K
22 CP="COM:98N1ENN"
30 REM open COM: for I/O
31 OPEN CP FOR OUTPUT AS 1
32 OPEN CP FOR INPUT AS 2
40 REM turn-on CLI mode
41 PRINT#1,STRING$(4,13)
50 REM send "set" command to BackPack/BackPack+
51 PRINT#1,"set";CHR$(13)
60 REM read data from BackPack (set returns 9? values)
61 INPUT#2,A,B,C,D,E,F,G,H,I
70 REM show "settings"
71 PRINT A,B,C,D,E,F,G,H,I
80 REM turn-off CLI mode
81 PRINT#1,"bye"
99 END

 

What is wrong in the above? Any idea?

 

btw this works:


10 REM read data from BackPack/BackPack+
20 REM set variables
21 MAXFILES=2:DEFSTR A-K
22 CP="COM:98N1ENN"
30 REM open COM: for I/O
31 OPEN CP FOR OUTPUT AS 1
32 OPEN CP FOR INPUT AS 2
40 REM read from BackPack/BackPack+ (Date=A, Time=B, Day=C)
41 PRINT#1,"FF";chr$(7);chr$(13)
42 INPUT#2,A,B,C
50 REM print values
51 PRINT A,B,C
99 END

 

Thanks for your help

Re: [M100] Possible BBS launch

[Daniel L]

OK. Tribbs?

On February 28, 2023 1:06:30 PM PST, Gregory McGill  
wrote:
>I don't run syncronet :)  I think I'm included in syncroterm tho
>
>Greg
>
>On Tue, Feb 28, 2023 at 11:55 AM Daniel L  wrote:
>
>> Your board is on digitalman's list of syncronet bbs's so I already had it.
>>
>> I logged in and poked around. I was surprised you're not on any of the
>> message echoes.
>>
>> D
>>
>> On 2/26/23 07:51, Gregory McGill wrote:
>>
>> The KEEP BBS online since 83
>> I have a model t area
>> Stephen recently logged in with mcomm
>> Dialup and telnet
>> Https://thekeep.net for details
>>
>> On Sun, Feb 26, 2023, 5:54 AM Jesse Lafleur  wrote:
>>
>>> You can 100% accomplish this using an affordable PAP2T ATA connected to
>>> either a local asterisk (free PBX software) or remote asterisk server over
>>> ethernet.
>>> This can be run entirely virtualised - no special hardware other than
>>> either a "landline" or the pap2t. (ill get to rotary later..)
>>>
>>> The PAP2T and asterisk can provide ulaw to allow 300bps connections. Yes,
>>> running a local asterisk is far more stable than trying to connect to one
>>> remotely, but ive done it!
>>> I have a setup functioning to 4800 baud for faster modems as well.
>>>
>>> The rotary element will likely need a pulse to tone adapter, lots of
>>> options for that, I use a PBX and I also have a few purpose devices new and
>>> old.
>>>
>>> You can easily have a BBS software or custom *NIX program to interface,
>>> and with the various termcap things in this group that have been shared,
>>> you can get a viable connection.
>>>
>>> On Sun, Feb 26, 2023 at 8:41 AM grima...@gmail.com 
>>> wrote:
>>>
 Hi Jesse,

 Do you happen to have any more details on your setup?

 I suppose in an ideal world, I’d like a setup that I can dial out from
 my rotary phone, and a second line that I could dial in to a modem.

 How difficult does that sound? I tried to use MagicJack previously but
 the compression codex they use doesn’t play well with data transfer.

 On Sun, Feb 26, 2023 at 8:11 AM Jesse Lafleur 
 wrote:

> I can provide bell 103 compatible 100% online dial-in access to linux
> servers/services using voip/asterisk/etc. I use my m100 to dial into my
> local home pbx server, and ive even tried it over the web!
>
> On Sun, Feb 26, 2023 at 7:44 AM grima...@gmail.com 
> wrote:
>
>> What are the odds that any of these BBSes would allow dialing in from
>> a real phone line?
>>
>> There is a Commodore 64 BBS out there called BorderlineBBS that has a
>> hybrid Telnet/Dial-Up interface.
>>
>> I managed to use the acoustic couplers to dial in once from the Model
>> T, but ever since switching to VOIP I wasn’t able to get it to work.
>>
>> I really always loved BBSing, so I would be in full support of using a
>> Model T focused BBS.
>>
>> -George
>>
>> On Sun, Feb 26, 2023 at 7:30 AM Ben Strewens 
>> wrote:
>>
>>> On 2023-02-26 4:50 a.m., Daniel L wrote:
>>>
>>> I'm considering a specialized launch of a BBS catering to the modelT
>>> community. Any good boards out there already doing this that I can 
>>> peruse?
>>>
>>> Daniel
>>>
>>> I'm currently working on one that will support multiple systems,
>>> including the model 100. I'm aiming for going all the way down to the 
>>> Epson
>>> HX-20, but we'll see how that pans out. It won't be up and running for a
>>> while yet. We're supposed to get a new ISP here this year. The one who
>>> bought out the company I was with closed all my ports and had no clue 
>>> how
>>> to re-open them, so my BBS got shut down. In the meantime, I figured I'd
>>> work on one that caters to the vintage computer community. I still have
>>> lots of work ahead of me.
>>>
>>
>>

Re: [M100] - Text Sweet 2.3 Release

[grima...@gmail.com]

I used Renum1 from Club100 library.

I have inspected the tokenized BA in a hex editor. As far as I can tell,
line numbers aren’t really compressed in any way. So in my original
program, most of my line numbers were between 1000-3, and each
reference to them was 4-5 bytes.

Now most of my lines are 1-3 bytes after renumbering from 1.

I also do use Packer.BA from Club100. This removes comments, and combines
lines that aren’t referenced by GOTO, GOSUB, etc.

Best,
George

On Tue, Feb 28, 2023 at 9:49 PM B 9  wrote:

>
>
> On Tue, Feb 28, 2023 at 4:55 PM grima...@gmail.com 
> wrote:
>
>> Thanks all!
>>
>> At some point I’ll look into adding Tokenization directly into Github.
>>
>
> Awesome. It looks like compiling and running a C program may be trivial in
> the yaml file:
>
> - uses: actions/checkout@v3
>
> - run:   |
>  make
>  ./tokenize FOO.DO
>
>
> By the way, you may be able to use a Python lexer, such as ply
> , to create a Python program from my
> flex source code. However, I suspect that will be more work than it's
> worth.
>
>
> I also used a line renumberer which brought down the .BA file to 76% of
>> the previous version.
>
>
> Wow. What renumberer did you use? And why did renumbering reduce the file
> size?
>
> By the way, a tokenizer should be able to reduce the file size
> dramatically by simply omitting the string after REM statements. Having it
> remove vestigial lines completely would be slightly trickier and probably
> require a second pass as it'd have to make sure the line was not a target
> of GOTO (or any of the other varied ways of referring to line numbers).
>
> —b9
>

Re: [M100] - Text Sweet 2.3 Release

[B 9]

On Tue, Feb 28, 2023 at 6:40 PM B 9 hacke...@gmail.com
 wrote:

By the way, a tokenizer should be able to reduce the file size dramatically
> by simply omitting the string after REM statements. Having it remove
> vestigial lines completely would be slightly trickier and probably require
> a second pass as it'd have to make sure the line was not a target of GOTO
> (or any of the other varied ways of referring to line numbers).
>
Okay, I made a quick and dirty tokenizer that removes comments
 and extra white
space. It does not do the second pass to remove unneeded lines or anything
fancy, like converting ' to REM (which takes up less space). It's not as
good as the renumberer used on TSWEEP, but it's close, creating a binary
that is only 500 bytes larger.

—b9

Re: [M100] - Text Sweet 2.3 Release

[B 9]

On Tue, Feb 28, 2023 at 4:55 PM grima...@gmail.com 
wrote:

> Thanks all!
>
> At some point I’ll look into adding Tokenization directly into Github.
>

Awesome. It looks like compiling and running a C program may be trivial in
the yaml file:

- uses: actions/checkout@v3

- run:   |
 make
 ./tokenize FOO.DO


By the way, you may be able to use a Python lexer, such as ply
, to create a Python program from my
flex source code. However, I suspect that will be more work than it's
worth.


I also used a line renumberer which brought down the .BA file to 76% of the
> previous version.


Wow. What renumberer did you use? And why did renumbering reduce the file
size?

By the way, a tokenizer should be able to reduce the file size dramatically
by simply omitting the string after REM statements. Having it remove
vestigial lines completely would be slightly trickier and probably require
a second pass as it'd have to make sure the line was not a target of GOTO
(or any of the other varied ways of referring to line numbers).

—b9

Re: [M100] - Backpack

[John R. Hogerhuis]

On Tue, Feb 28, 2023 at 5:09 PM  wrote:

> I did some more testing and discovered that John is absolutely correct.
> Previously when I had tried to load a .BA which was really a .DO it made it
> about 3-4 line in and then stopped. This led me to believe it was an issue
> I have seen on other computer; when loading an ASCII file over serial the
> computer will tokenize the line when the CR is encountered. Just like it
> had been typed in on the keyboard. For these systems you have to add a 2
> second or so delay after each line to allow for tokenization.
>
> TSDOS does its own thing, like John says, and really makes a mess of it.
>
>
>

Yes. Thanks. In retrospect, it is about TS-DOS trusting the filename
extensions on the host system. It's a reasonable assumption on its/the
developers' part... files don't get the wrong extension by anything the
M100 can do when saving/loading files. M100 always names the files
correctly. If the file says .B* it gets inloaded to the BASIC file area.
TS-DOS doesn't even look at the content AFAIK.

The problem originates above the keyboard assembly.

For my part, LaddieAlpha checks the host file content itself and presents
them with the correct extension rather than risk TS-DOS inloading a
non-tokenized BA file and corrupting the system.

-- John.

Re: [M100] - Backpack

[birt_j]

I did some more testing and discovered that John is absolutely correct. 
Previously when I had tried to load a .BA which was really a .DO it made it 
about 3-4 line in and then stopped. This led me to believe it was an issue I 
have seen on other computer; when loading an ASCII file over serial the 
computer will tokenize the line when the CR is encountered. Just like it had 
been typed in on the keyboard. For these systems you have to add a 2 second or 
so delay after each line to allow for tokenization.

TSDOS does its own thing, like John says, and really makes a mess of it. 

 

Jeff Birt

 

From: M100  On Behalf Of John R. Hogerhuis
Sent: Saturday, February 25, 2023 7:40 PM
To: m...@bitchin100.com
Subject: Re: [M100] - Backpack

 

A side note but the reason files misnamed as BA cause a problem is that tsdos 
will load them into the BASIC program region verbatim and  treat the ASCII 
bytes as parts of binary formatted line numbers and tokens among other 
problems, ultimately causing a corrupted RAM file system. 

 

It was the convention on the old Club100 library  to name them this way but 
it's now a bad practice. 

 

-- John. 

 

 

 

On Sat, Feb 25, 2023, 5:30 PM mailto:bir...@soigeneris.com> > wrote:

Yes, someone already wrote such a program and shared it. If you just got a 
Backpack Drive Plus it is already on the SD card. You can also download it 
from: https://github.com/Jeff-Birt/Backpack/tree/main/User_Programs 

 

Re: [M100] Interfacing Model 100 with the Real World

[birt_j]

The first question is what I/O ports on the computer will work for the type
of interface you have in mind. 

 

Both machines have:

Parallel port - Output only

Serial port - Bidirectional required a smart device to interface to

BCR port - serial input

System Bus - the most complicated, most flexible and easiest to mess up

 

Out of all of these the serial port is probably your best bet. The OWL I
mentioned briefly in my last video connects to the serial port. It has its
own microcontroller to handle the I/O tasks and the M100 takes care of
logging, scaling inputs, sending commands to turn outputs on/off, etc.

 

There were a lot of books in the 1980s with titles like: 'Interfacing your
Commodore 64'. Even if the code is these books is only marginally helpful
the ideas about interfacing with the real world will apply.

 

Jeff Birt

 

From: M100  On Behalf Of Joseph Colson
III
Sent: Monday, February 27, 2023 7:44 PM
To: m100@lists.bitchin100.com
Subject: [M100] Interfacing Model 100 with the Real World

 

I'm very interested in interfacing the Model 100 or Model 102 with sensors,
such as temp, wind and other that would be helpful.   Are there any books
that I can read that are somewhat specific to the Model T's that would help
in the endeavor? 

Re: [M100] Interfacing Model 100 with the Real World

[Joseph Colson III]

I know a little bit about the OWL but I’m not able to locate anything 
documenting the interface board.   I know Jeff has one as well and has it on 
his to do list to create some videos about it.   Which by the way I’m really 
looking forward to watching!   But in the mean time I was hoping to locate some 
books and such documenting how to interface with it.

From: M100  On Behalf Of Peter Vollan
Sent: Tuesday, February 28, 2023 2:30 PM
To: m...@bitchin100.com
Subject: Re: [M100] Interfacing Model 100 with the Real World

There are model 100s that were used solely for that purpose. I think it was 
called an OWL, Outdoor Weather Logger. So that's a good place to start at least.


On Mon, 27 Feb 2023 at 18:08, Joseph Colson III 
mailto:joecols...@outlook.com>> wrote:
I’m very interested in interfacing the Model 100 or Model 102 with sensors, 
such as temp, wind and other that would be helpful.   Are there any books that 
I can read that are somewhat specific to the Model T’s that would help in the 
endeavor?

Re: [M100] Possible BBS launch

[Gregory McGill]

I don't run syncronet :)  I think I'm included in syncroterm tho

Greg

On Tue, Feb 28, 2023 at 11:55 AM Daniel L  wrote:

> Your board is on digitalman's list of syncronet bbs's so I already had it.
>
> I logged in and poked around. I was surprised you're not on any of the
> message echoes.
>
> D
>
> On 2/26/23 07:51, Gregory McGill wrote:
>
> The KEEP BBS online since 83
> I have a model t area
> Stephen recently logged in with mcomm
> Dialup and telnet
> Https://thekeep.net for details
>
> On Sun, Feb 26, 2023, 5:54 AM Jesse Lafleur  wrote:
>
>> You can 100% accomplish this using an affordable PAP2T ATA connected to
>> either a local asterisk (free PBX software) or remote asterisk server over
>> ethernet.
>> This can be run entirely virtualised - no special hardware other than
>> either a "landline" or the pap2t. (ill get to rotary later..)
>>
>> The PAP2T and asterisk can provide ulaw to allow 300bps connections. Yes,
>> running a local asterisk is far more stable than trying to connect to one
>> remotely, but ive done it!
>> I have a setup functioning to 4800 baud for faster modems as well.
>>
>> The rotary element will likely need a pulse to tone adapter, lots of
>> options for that, I use a PBX and I also have a few purpose devices new and
>> old.
>>
>> You can easily have a BBS software or custom *NIX program to interface,
>> and with the various termcap things in this group that have been shared,
>> you can get a viable connection.
>>
>> On Sun, Feb 26, 2023 at 8:41 AM grima...@gmail.com 
>> wrote:
>>
>>> Hi Jesse,
>>>
>>> Do you happen to have any more details on your setup?
>>>
>>> I suppose in an ideal world, I’d like a setup that I can dial out from
>>> my rotary phone, and a second line that I could dial in to a modem.
>>>
>>> How difficult does that sound? I tried to use MagicJack previously but
>>> the compression codex they use doesn’t play well with data transfer.
>>>
>>> On Sun, Feb 26, 2023 at 8:11 AM Jesse Lafleur 
>>> wrote:
>>>
 I can provide bell 103 compatible 100% online dial-in access to linux
 servers/services using voip/asterisk/etc. I use my m100 to dial into my
 local home pbx server, and ive even tried it over the web!

 On Sun, Feb 26, 2023 at 7:44 AM grima...@gmail.com 
 wrote:

> What are the odds that any of these BBSes would allow dialing in from
> a real phone line?
>
> There is a Commodore 64 BBS out there called BorderlineBBS that has a
> hybrid Telnet/Dial-Up interface.
>
> I managed to use the acoustic couplers to dial in once from the Model
> T, but ever since switching to VOIP I wasn’t able to get it to work.
>
> I really always loved BBSing, so I would be in full support of using a
> Model T focused BBS.
>
> -George
>
> On Sun, Feb 26, 2023 at 7:30 AM Ben Strewens 
> wrote:
>
>> On 2023-02-26 4:50 a.m., Daniel L wrote:
>>
>> I'm considering a specialized launch of a BBS catering to the modelT
>> community. Any good boards out there already doing this that I can 
>> peruse?
>>
>> Daniel
>>
>> I'm currently working on one that will support multiple systems,
>> including the model 100. I'm aiming for going all the way down to the 
>> Epson
>> HX-20, but we'll see how that pans out. It won't be up and running for a
>> while yet. We're supposed to get a new ISP here this year. The one who
>> bought out the company I was with closed all my ports and had no clue how
>> to re-open them, so my BBS got shut down. In the meantime, I figured I'd
>> work on one that caters to the vintage computer community. I still have
>> lots of work ahead of me.
>>
>
>

Re: [M100] Interfacing Model 100 with the Real World

[Peter Vollan]

There are model 100s that were used solely for that purpose. I think it was
called an OWL, Outdoor Weather Logger. So that's a good place to start at
least.


On Mon, 27 Feb 2023 at 18:08, Joseph Colson III 
wrote:

> I’m very interested in interfacing the Model 100 or Model 102 with
> sensors, such as temp, wind and other that would be helpful.   Are there
> any books that I can read that are somewhat specific to the Model T’s that
> would help in the endeavor?
>

Re: [M100] Possible BBS launch

[Daniel L]

Your board is on digitalman's list of syncronet bbs's so I already had it.

I logged in and poked around. I was surprised you're not on any of the 
message echoes.


D

On 2/26/23 07:51, Gregory McGill wrote:

The KEEP BBS online since 83
I have a model t area
Stephen recently logged in with mcomm
Dialup and telnet
Https://thekeep.net  for details

On Sun, Feb 26, 2023, 5:54 AM Jesse Lafleur  wrote:

You can 100% accomplish this using an affordable PAP2T ATA
connected to either a local asterisk (free PBX software) or remote
asterisk server over ethernet.
This can be run entirely virtualised - no special hardware other
than either a "landline" or the pap2t. (ill get to rotary later..)

The PAP2T and asterisk can provide ulaw to allow 300bps
connections. Yes, running a local asterisk is far more stable than
trying to connect to one remotely, but ive done it!
I have a setup functioning to 4800 baud for faster modems as well.

The rotary element will likely need a pulse to tone adapter, lots
of options for that, I use a PBX and I also have a few purpose
devices new and old.

You can easily have a BBS software or custom *NIX program to
interface, and with the various termcap things in this group that
have been shared, you can get a viable connection.

On Sun, Feb 26, 2023 at 8:41 AM grima...@gmail.com
 wrote:

Hi Jesse,

Do you happen to have any more details on your setup?

I suppose in an ideal world, I’d like a setup that I can dial
out from my rotary phone, and a second line that I could dial
in to a modem.

How difficult does that sound? I tried to use MagicJack
previously but the compression codex they use doesn’t play
well with data transfer.

On Sun, Feb 26, 2023 at 8:11 AM Jesse Lafleur
 wrote:

I can provide bell 103 compatible 100% online dial-in
access to linux servers/services using voip/asterisk/etc.
I use my m100 to dial into my local home pbx server, and
ive even tried it over the web!

On Sun, Feb 26, 2023 at 7:44 AM grima...@gmail.com
 wrote:

What are the odds that any of these BBSes would allow
dialing in from a real phone line?

There is a Commodore 64 BBS out there called
BorderlineBBS that has a hybrid Telnet/Dial-Up interface.

I managed to use the acoustic couplers to dial in once
from the Model T, but ever since switching to VOIP I
wasn’t able to get it to work.

I really always loved BBSing, so I would be in full
support of using a Model T focused BBS.

-George

On Sun, Feb 26, 2023 at 7:30 AM Ben Strewens
 wrote:

On 2023-02-26 4:50 a.m., Daniel L wrote:

I'm considering a specialized launch of a BBS
catering to the modelT community. Any good boards
out there already doing this that I can peruse?

Daniel


I'm currently working on one that will support
multiple systems, including the model 100. I'm
aiming for going all the way down to the Epson
HX-20, but we'll see how that pans out. It won't
be up and running for a while yet. We're supposed
to get a new ISP here this year. The one who
bought out the company I was with closed all my
ports and had no clue how to re-open them, so my
BBS got shut down. In the meantime, I figured I'd
work on one that caters to the vintage computer
community. I still have lots of work ahead of me.

Re: [M100] - Text Sweet 2.3 Release

[grima...@gmail.com]

I work for a relatively major fintech company, and we have used GitHub
actions at scale to automate a ton of workflows, some examples include:

- code and file validation.
- unit testing.
- cloud infrastructure deployment.

Github Actions are just a good way to automate and glue together different
things. For example, embedding your tokenizer into an action would
potentially allow anyone who wants to write Tandy BASIC code and publish it
to GitHub to automatically tokenize it from ASCII on commit.

Alternatively if you prefer to be a bit more generic, you could put your
Tokenizer behind an API and then create a Github action that basically just
interfaces with that API. That way people who aren’t using Github could
still access your Tokenizer-As-A-Service (TAAS)

This seems like a promising solution. However, I don’t really know anything
about C executables, I’m afraid I live over in Python land.

-George


On Tue, Feb 28, 2023 at 2:20 PM B 9  wrote:

> On Mon, Feb 27, 2023 at 7:51 AM grima...@gmail.com grima...@gmail.com
>  wrote:
>
> Currently I’m using VS Code and Virtual T in tandem to develop. It would
>> be great if there were a modern tokenizer and packer written in Python or
>> similar.
>
> Last year I wrote a tokenizer in C. ¹
>
> https://github.com/hackerb9/tokenize
>
> It can handle WIDTH and DSKO$ and it’s easy to add new tokens if some
> other variant of BASIC appears.
>
> While it will work fine for your project, I consider it incomplete as it
> does not generate N82 BASIC tokens, yet.
>
> I’m curious about people’s experiences using GitHub Actions. I haven’t
> used them as I worried it would tie my projects too closely to one company.
> Now that Nektos' act  exists, I'm
> reconsidering.
>
> —b9
> --
>
> ¹ Technically, I wrote it in flex which made tokenization trivial. Flex
> outputs C code, so the program runs anywhere without requiring flex as a
> dependency. I haven’t tried it, but there is a tool called Flex.js which is
> supposed to output JavaScript, if you’re into that kind of thing.
>

Re: [M100] - Text Sweet 2.3 Release

[Joshua O'Keefe]

> On Feb 28, 2023, at 11:21 AM, B 9  wrote:

> Last year I wrote a tokenizer in C. ¹ [well, lexx]
> https://github.com/hackerb9/tokenize
> 

Thank you for reminding me of this!  I was trying to remember it and it was the 
lexx I wanted!

Re: [M100] - Text Sweet 2.3 Release

[B 9]

On Tue, Feb 28, 2023 at 11:03 AM B 9  wrote:

> Last year I wrote a tokenizer in C. ¹
>
> https://github.com/hackerb9/tokenize
>
Addendum: the binaries it generates work fine on actual machines, but
Virtual T is overly persnickety about the memory pointers. I'd forgotten
about this as I patched my copy of Virtual T.

—b9

Re: [M100] - Text Sweet 2.3 Release

[B 9]

On Mon, Feb 27, 2023 at 7:51 AM grima...@gmail.com grima...@gmail.com
 wrote:

Currently I’m using VS Code and Virtual T in tandem to develop. It would be
> great if there were a modern tokenizer and packer written in Python or
> similar.

Last year I wrote a tokenizer in C. ¹

https://github.com/hackerb9/tokenize

It can handle WIDTH and DSKO$ and it’s easy to add new tokens if some other
variant of BASIC appears.

While it will work fine for your project, I consider it incomplete as it
does not generate N82 BASIC tokens, yet.

I’m curious about people’s experiences using GitHub Actions. I haven’t used
them as I worried it would tie my projects too closely to one company. Now
that Nektos' act  exists, I'm reconsidering.

—b9
--

¹ Technically, I wrote it in flex which made tokenization trivial. Flex
outputs C code, so the program runs anywhere without requiring flex as a
dependency. I haven’t tried it, but there is a tool called Flex.js which is
supposed to output JavaScript, if you’re into that kind of thing.

Re: [M100] M100 LCD repair video and alternative use for unused screen RAM

[B 9]

On Sat, Feb 25, 2023 at 12:37 PM Philip Avery  wrote:

> Correct Mike, a 1950 Land Rover.
>

Wow! That looks like it just rolled out of the factory.

—b9

Re: [M100] Interfacing Model 100 with the Real World

[Mike Stein]

There are lots of ways to interface to the M100 aside from the 'normal'
ports, for instance using the Bar Code port to measure frequency and/or
voltage, using the RS-232 control lines as digital I/O lines and of course
the easiest of all, the cassette motor relay.

But the actual details of the interface will depend entirely on your
sensors and what you want to do with them.

Years ago John W. designed and built a great little interface called the
"ADIOS', with several digital and analog I/O ports that it would
send/transmit over the RS-232 port; maybe someone would want to copy it
(with his permission of course).

m

On Tue, Feb 28, 2023 at 4:50 AM Daniel L  wrote:

> I dont but you may find it useful to watch Birt's latest video on youtube
> where he adds a rom to a multirom jobber on his 100 and that he will use it
> to collect weather data. Read the thread announcing the video about
> dial-a-rom. It's a fascinating new feature he highlighted and im interested
> in seeing the outcome.
>
> D
>
> On February 27, 2023 5:43:56 PM PST, Joseph Colson III <
> joecols...@outlook.com> wrote:
>>
>> I’m very interested in interfacing the Model 100 or Model 102 with
>> sensors, such as temp, wind and other that would be helpful.   Are there
>> any books that I can read that are somewhat specific to the Model T’s that
>> would help in the endeavor?
>>
>

Re: [M100] Interfacing Model 100 with the Real World

[Daniel L]

I dont but you may find it useful to watch Birt's latest video on youtube where 
he adds a rom to a multirom jobber on his 100 and that he will use it to 
collect weather data. Read the thread announcing the video about dial-a-rom. 
It's a fascinating new feature he highlighted and im interested in seeing the 
outcome.

D

On February 27, 2023 5:43:56 PM PST, Joseph Colson III  
wrote:
>I'm very interested in interfacing the Model 100 or Model 102 with sensors, 
>such as temp, wind and other that would be helpful.   Are there any books that 
>I can read that are somewhat specific to the Model T's that would help in the 
>endeavor?