[M100] Is there a superoptimizer for the Intel 8085 (or maybe the Z80)?

[Douglas Quagliana]

Does anyone know if there is a superoptimizer for the Intel 8085 (or maybe
for the Z80)?

A superoptimizer in this context is a program that takes as its input an
assembly language source code file and then it tries a brute force search
of all possible machine language instructions (up to a certain length) for
any shorter/faster sequences of machine language instructions that would do
the same thing as the original sequence of instructions.

There's a GNU superoptimizer for 8086 and 68020, but I'm looking for one
for the 8085 (or Z80) so I can use the superoptimized results on a Model
100.

Regards,
Douglas

Re: [M100] Lapstar for Model 100/200?

[Douglas Quagliana]

Hi John,

The TEXT extension to add Wordstar "diamond" cursor movement keys was
TXTSTR (TextStar).
It's an assembly language program that uses a keyboard hook, checks the
stack to see if you're
running TEXT and does the appropriate manipulations to emulate Wordstar
cursor movements.
It's in the Compuserve archive in Lib-02-Text under "TXTSTR.ASM" and
"TXTSTR.DOC" and
in the March 1989 issue of Portable 100 Magazine.

I was curious about Lapstar which is supposed to be a "stripped down"
version of Wordstar.
Lapstar was written by CISS Corporation, but there's almost no information
about Lapstar
on the web.

Regards,
Douglas


On Fri, Sep 15, 2023 at 4:58 PM John R. Hogerhuis  wrote:

> I don't remember it being called that but portable 100 haf an article with
> a TEXT extension that adds wordstar key commands.
>
> That might be it.
>
> Let me know if you cannot find it (I'm on my phone).
>
> -- John
>
> On Fri, Sep 15, 2023, 2:15 PM Douglas Quagliana 
> wrote:
>
>> Friends,
>>I came across a couple of references to a software package called
>> Lapstar, which is supposed to be a stripped down version of Wordstar for
>> model T computers. Howver, I couldn't find a copy of it anywhere. Does
>> anybody have more information on Lapstar?
>> Douglas
>>
>

[M100] Lapstar for Model 100/200?

[Douglas Quagliana]

Friends,
   I came across a couple of references to a software package called
Lapstar, which is supposed to be a stripped down version of Wordstar for
model T computers. Howver, I couldn't find a copy of it anywhere. Does
anybody have more information on Lapstar?
Douglas

[M100] Generating and detecting other tones via the cassette port

[Douglas Quagliana]

Friends,

Has anyone experimented with generating and detecting tones on the cassette
port other than the standard cassette mark and space frequencies?

The ROM code seems to generate the standard tones just by varying the
timing loop iterations, and the detection is a slightly more complicated
timing loop while watching/waiting for the signal to go from high to low,
so it would *seem*  to be the case that changing the values would let you
use other audio frequencies in your own assembly code version of the
cassette port code. (Basic isn't fast enough.)

But...Has anyone actually written any assembly language code to do this? If
so, could you send it to me?

Douglas

[M100] Is there a tiny pascal compiler for the M100 ?

[Douglas Quagliana]

Does anyone know if there is a "Tiny Pascal" compiler for the M100/102/200?

I am looking for a Tiny Pascal compiler that runs on a PC or on a M100 that
compiles to assembly language statements for an assembler or that produces
an executable for the M100.  However, if someone knows of a working Tiny
Pascal compiler that compiles to P-code and has a P-code interpreter, then
I would be interested in hearing about that too.

I know there's a P-code Tiny Pascal compiler in an old issue of Byte
Magazine from the late 1970s, but I didn't want to retype it from the
magazine and it's probably been improved since that series of articles were
written...

Thanks,
Douglas

[M100] Photo from ARRL handbook or QST article for Model 100 packet radio

[Douglas Quagliana]

I'm looking for a photo which was probably published in the ARRL handbook
or perhaps in an issue of QST showing a Model 100 being used with a TNC for
(I think) Field Day packet radio.  There might also have been a large solar
panel.
This was probably in the mid-to-late 1980s.

Does anyone know what year's ARRL Handbook or what issue of QST this might
have been published in?

Thanks,
Douglas

[M100] Friends, Where does the 1500bps specification for the cassette port come from? How did they get "1500"?

[Douglas Quagliana]

The official specs that I found for the cassette port say that it runs at
1500 bps, but the bits are sent as a single 1200 Hz cycle or a single 2400
Hz cycle so the length of a single bit varies depending on whether it is a
one or a zero.

If you assumed an average density of ones and zeroes then the bit rate
would be the average or 1800bps, and if you said the user only "gets" eight
bits for every nine saved to tape then you would have 8/9th of 1800bps
which would be 1600, hmmm... that doesnt work out to 1500 either.

So, how do you get 1500bps as the cassette data rate specification?

Douglas

[M100] A DOS/Windows/Linux program to create a WAVE file for a .DO or .CO ?

[Douglas Quagliana]

Has anyone written a program for a DOS/Windows/Linux PC that will take a
.DO or .CO file that's on the PC and create a WAVE file that can be played
into a M100 cassette port to CLOAD the file onto the M100?

My modern PC doesn't have a built-in serial port and I'm doing some other
cassette port work for the M100, so this would make loading files on the
M100 easier for me.

Regards,
Douglas

Re: [M100] m200.def --- eventually m200smallclib hopefully

[Douglas Quagliana]

Hi Williard,

I found a cross reference list on Club100 at

https://ftp.whtech.com/club100/ref/cross1.doc

that says that 1BB1h on the 100 is 2697h on the 200 (for RSTDOG)

and another link at

https://ftp.whtech.com/club100/ref/cross2.doc

(the second list) says F932 on the 100 is F222 on the 200 although that
entry has an asterisk saying it didn't come from the same reliable source
as the other and that it isn't tested.   I'm willing to test on my T200 if
you have anything to test.

Regards,
Douglas




On Thu, May 20, 2021 at 2:25 PM Willard Goosey  wrote:

> So, due to popular demand (one d00d asked) I've started putting
> together a m200.def to match m100.def.  This will hopefully lead to an
> equally (in)capable m200smallclib, but first things first!!!
>
> This is complicated by the fact that I don't have a m200... This is
> pre-alpha completely untested stuff!
>
> So, starting from the club100 scan of the m200 techref, there are some
> addresses I just can't read. They are:
> CHPLPT
> SNDCOM(*)
> INZCOM
>
> (*)also need to know if SNDCOM is the same evil hack of "jump into the
> middle of sd232 (which preserves BC) so we need a dummy value on the
> stack" as the m100 call.
>
> Also, to get smallclib's cstart.a85 fully working I need the m200
> versions of these:
> RSTDOG (1bb1h on m100)
> POWERFLAG (0f932h on m100)
>
>
> Last week was hell at work so I haven't had a chance to do any other
> research. URLs to other m200 assembly docs welcome!
>
> Lastly, anybody have a m200 for sale? :-)
>
> Willard
> --
> Willard Goosey  goo...@sdc.org
> Socorro, New Mexico, USA
> I search my heart and find Cimmeria, land of Darkness and the Night.
>   -- R.E. Howard
>

[M100] Ordering a replacement NiCd for Model 100 - from where?

[Douglas Quagliana]

I have a Model 100 that wont boot consistently, or powers on to a screen
with all the pixels on. When it does boot it usually crashes or freezes
within a minute, but once or twice I have been able to get to BASIC and run
a short program.

I suspect the NiCd battery on the motherboard, which needs to be replaced
on this unit anyway at this point.  Trying to (re)charge it overnight
didn't work.

>From what I can find, the part number is either 3-51FT or maybe 3-51FT-A ?
What's the difference?

Does anyone on the mailing list sell them?  Where are people ordering their
replacement NiCd battery from?

Regards,
Douglas

Re: [M100] Memory release question

[Douglas Quagliana]

Charles writes:
> The RS M100 Assembler / Debugger application documentation has a brief
>appendix of ROM routines, listing purpose, entry and exit conditions and
>addresses, but unfortunately incomplete.  One new objective is to find a
>complete listing, hopefully commented

I would suggest starting with Robert Covington's M100 ROM map (it comes
in 7 parts, plus another file on ports/registers) available at

http://www.club100.org/library/libref.html

under the heading "Maps and List". Here's a typical entry:

190FH -  Read time from system clock and store it in the buffer
pointed to by HL
 Entry:
   HL - Points to start of time buffer.  The buffer will
be filled with the time in the format hh:mm:ss.
 Exit:
   HL - Incremented to the end of the buffer.
   All other registers destroyed


There's also two *REALLY* good and well commented Model 100 ROM
disassemblies on Club100 at

http://www.club100.org/memfiles/index.php?=0==Ken%20Pettit/M100%20ROM%20Disassembly

Also check out "Hidden Powers of the Model 100" and " Inside the TRS-80
Model 100"  available at

http://www.club100.org/library/libdoc.html

Once you get to those Club100 pages, you'll probably find more stuff that's
interesting to you.

Regards,
Douglas




On Fri, Apr 30, 2021 at 12:37 PM Charles Hudson  wrote:

> Thanks, Peter, for your explanation of the memory segmentation issue; the
> fact that there is no 80C85 Jump Relative opcode and thus no relocation was
> unknown to me.  As you may deduce my depth on the M100 is pretty shallow.
> Until recently I had only the bar code reader software to play with (other
> than the ROM suite) and my bar code reader seems to be DOA, so not much
> familiarity with machine code.
>
> The RS M100 Assembler / Debugger application documentation has a brief
> appendix of ROM routines, listing purpose, entry and exit conditions and
> addresses, but unfortunately incomplete.  One new objective is to find a
> complete listing, hopefully commented, such as the one I have for my Model
> III ROM.
>
> Another objective is to develop a reliable method for tape duplication
> before I damage or wear out the OEM distributions.  I am thinking it might
> be possible to make a digital copy of the OEM tape on my Win10 machine,
> using a hi-fi tape deck as the playback source and Audacity as the DTR.
> With luck reversing the roles will yield a functional copy tape.  But
> again, if someone has a better idea...
>
> Thanks again for your input.
> -CH-
>

Re: [M100] Assembler question

[Douglas Quagliana]

By coincidence, I'm also looking for a good assembler for the M100/200.
Got a suggestion?

I found the book *8080 8085 Software Design* (Sams, 1978) by Christopher
Titus, Peter Rony, David Larsen and Jonathan Titus
is available at

https://archive.org/details/80808085SoftwareDesign

and the TEA book that I found is actually in Spanish(?) at

https://archive.org/details/teauneditorassemblerresidenteper80808085/mode/1up

I suppose the latter book has the same assembler listing for the TEA
software even though
the text is not in English.  I didn't find the actual TEA software binaries
anywhere.

Douglas


On Sun, Apr 25, 2021 at 9:38 AM Charles Hudson  wrote:

> Currently reading about 8080 / 8085 assembly language, a subject of
> interest as the M100 uses an 8085.  I am familiar with the concepts of
> assembly language and with the syntax of some other assemblers and
> processors' instruction sets, but this is terra incognita to me.
>
> Even stranger is the fact that one book, *8080 8085 Software Design*
> (Sams, 1978) by Christopher Titus, Peter Rony, David Larsen and Jonathan
> Titus, has examples written in a syntax and format which differs from any
> other assembler I have seen.  The assembler is of the authors' own design
> and is known by the acronym "TEA".
>
> Instead of four-delimited-fields-across format the assembler uses a
> one-byte-per-line format, i.e. a three-byte instruction, such as JMP, is
> written on three separate lines.  Also notable is the fact that labels are
> delimited with a comma, rather than colon, and comments with a forward
> slash rather than a semicolon.  And to top it off, the radix for numerical
> values is octal, which the authors claim is easier for beginners to learn.
> (Until now I had thought that octal went the way of high-button shoes and
> buggy whips.)
>
> So my questions are: Is anyone familiar with this assembler?  There was a
> book about its use, now out of print, but is a copy of the assembler itself
> available anywhere?
>
> Thanks for your assistance,
> -CH-
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_7536372778458213478_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: [M100] Packet radio like it's 1987

[Douglas Quagliana]

>How much of the 8085's time will be left to do anything useful at all with
the data with it essentially bit-banging the waveforms like that?

Probably not much CPU time will be left while receiving.  But packet radio
is half-duplex on HF and VHF.  If you are connecting to a packet radio BBS
or having a keyboard to keyboard chat with another human, there isn't much
that the CPU needs to do except display the received data and look for keys
being pressed on the keyboard.

> With the modem and UART hardware doing the hard layer 1 work, the CPU
should have plenty of cycles to spare to deal with the bit stuffing,
encoding, CRC checks, AX25 packet structure, etc.

Can the Model 100's modem/UART hardware be configured to just demodulate
bits synchronously?  The way the modem/UART would be used over the phone
lines would be asynchronously (the "A" in "UART"), where every 7 (or 8)
data bits are placed in between a start bit and a stop bit, and maybe with
a parity bit at the end of the character being sent.  "8N1" is really a
start bit, eight data bits, no parity bit and one stop bit. These ten bits
for a character are sent, then there could be a pause for a small fraction
of a second and then the start bit for the next character is sent.  That's
"asynchronous" serial.

However, AX.25 packet radio doesn't work that way.  It's synchronous. AX.25
uses an HDLC flag byte (0x7E) as a "start of data frame" indicator and then
a continuous stream of bits (all the data bits for the whole packet one
after another) with zero bits stuffed in after five contiguous one bits and
then another HDLC flag for the end of the packet.  In AX.25 there are no
start bits, no stop bits and no parity bits.  If there is a way to tell the
Model 100's modem/UART "Hey just send me straight bits for what you see,
synchronously, not asynchronously" then maybe we can receive 300 baud AX.25
packet radio but if the UART is expecting start/stop/parity bits, then the
modem/UART won't be able to receive 300 baud AX.25 packet on HF.

You could still use the internal modem/UART to send/receive ASCII Bell 103,
start/data/stop/parity, but I don't know if anyone still uses that on HF
anymore. Probably, I just don't know. W1AW used to send ASCII bulletins,
but they replaced ASCII and AMTOR with PSK31 and MFSK16 back in 2009.  If
you go this route, I would just adjust RIT and XIT on the radio so that the
tones are what the modem expects for ORIG and ANSWER so that you don't need
to make hardware mods to the M100.

On the other hand, the cassette port data is similar to AX.25 packet in
that there is a sync/header byte and there (usually) aren't
start/stop/parity bits, just straight bits. (Some NECs write two stop bits
after the data byte.) The challenge is that the cassette port/RIM
instruction only gives you "signal is above zero" or "signal is below zero"
so all you can get is above/below and the timing information on the zero
crossings of the waveforms. It's not really an analog-to-digital converter
except for that one bit. See Figure 3-9 "Demodulation Circuit of Cassette
Interface" on page 17 of the Model 100 Technical Reference Manual.  But,
the nice part about this small circuit is that it doesn't care much what
the baud rate or the frequencies of the signals are.  It just takes an
analog input waveform and outputs a square waveform to the CPU pin.  All of
the cassette reading and writing is done in software in the ROM routines.
The cassette "format" that the M100 uses of 1500 baud with a mark of 2400Hz
and space of 1200Hz is entirely implemented in software timing routings
independent of any hardware. The challenge for receiving packet radio is to
rewrite the cassette ROM routines to change the baud rate to 1200 and the
mark to 2200Hz.  This would have to be done in 8085 assembly as BASIC just
isn't fast enough. Note that some other laptops similar to the Model100
like the NEC PC-8201A/PC-8300 already use a different baud rate for
cassette I/O. (The NEC laptops use 600 baud if I recall correctly.)  "It's
only software."

Ok...I'll be going back to looking at zero crossing demodulators

Does anybody have a ROM disassembly for the NEC PC-8201A/PC-8300 ?  I'd
like to see how they do the timing for their 600 baud cassette format.

Regards,
Douglas
*"The task of receiving 1200 baud AX.25 as cassette signals would be easier
if there was a timer that ran at 1200 Hz, but the uDP1990 chip can't
generate 1200 Hz.  By default its timer runs 256 times per second and while
you CAN hook that in software, 256 Hz won't help when we want a 1200 Hz
timer. But I digress...(More info on the uDP1990 and the 256 Hz interrupt
that you can hook see https://ftp.whtech.com/club100/ref/watchdog.doc and
note that this file ends in ".DOC" but it is a text file not a Microsoft
Word document.)

Re: [M100] Packet radio like it's 1987

[Douglas Quagliana]

All,

   I haven't tried the Bell 103 modem, but the cassette port is (in theory)
fast enough to see 1200 baud AFSK. The cassette port is supposed to run at
1500 baud. To receive AX.25 packet you would need to count the time between
zero crossing similar to the way the cassette port does it now, and figure
out if the current bit was a mark or space, then shift the bits into memory
as they are received.  Upon receiving the trailing HDLC flag you would need
to undo the zero bit stuffing, undo the NRZI encoding, and check the CRC.
The problem is that Bell212 (1200 baud packet radio) shifts AFSK tones when
one bit time has elapsed (1/1200th of a second) and that doesn't exactly
match up with the zero crossings for the 2200Hz tone, so you get a whole
1200Hz tone starting at whatever phase the waveform was then at, but more
than one 2200Hz tone per bit and the waves are contiguous so the next one
just starts where the previous one ends.  It doesn't start the phase over
at zero for the next bit.

   The M100 ROM has code for reading the cassette input pin at 6FDBH and it
will watch the cassette port input pin connected to the 8085 SID on pin 5
with the RIM instruction, and then return the number of t-states until the
wave will end.  This would have to be rewritten to take into account the
different frequencies for packet radio versus what the cassette frequencies
are.  For details on the routine at 6FDBH see
https://ftp.whtech.com/club100/ref/rcmap6.100 and go down to 6FDBH.

   I've already written code for AX25 for PCs that will undo the zero bit
stuffing, NRZI and CRC, but didn't get to the bit detection on a M100. I
did get as far as a "read the frequency on the cassette port" but not for
1200 baud bits.  I think it would be neat to receive and perhaps send
packet radio on the cassette port without a TNC. This has been on my bucket
list for a long time to see if it could even be done.  If you're interested
or if you know more about the cassette port routines, then please let me
know.

Douglas


On Wed, Apr 14, 2021 at 10:54 AM Alex ...  wrote:

> Figure this would be a fun one to share with the [M100] list. :)
>
> I recently bought a big box of random ham radio packet gear which included
> a bunch of old TNC modems and assorted cables. Unfortunately, it turns out
> the quad serial port card in my desktop PC is dead.
>
> Enter the Tandy 102 to the rescue! I was able to test all 4 of the TNCs on
> the air and sent a test email from the T through a local Winlink RMS node.
>
> This whole exercise got me wondering if the built-in Bell 103 modem could
> be adapted for HF packet radio use. Has anybody tried that yet?
>
> Pictured in the attached photo is the Tandy 102 hooked to a MFJ 1274
> modem, monitoring Network 105 traffic on 7104khz.
>
> -Alex
>

Re: [M100] Ham radio

[Douglas Quagliana]

I'd like to know if there's a way to get the cassette port to recognize
AX.25 Bell 202 packet radio tones (1200 Hertz and 2200 Hertz at 1200
baud).  I think the cassette port audio input pin get routed to the CPU but
it only knows "HI" and "LO" so I don't think it can detect sinewave
waveforms, but I would really like to be proven wrong on this. If it
worked, it would let you run packet radio right off the cassette port and
use the cassette motor as a push-to-talk.

Anybody know for sure about the processing of audio input on the cassette
port audio input pin?
Douglas

On Fri, Jul 27, 2018 at 7:49 PM, Jeff Gonzales 
wrote:

> Anyone still using their Model T for ham radio?
>

Re: [M100] gps

[Douglas Quagliana]

Regarding those Tripmates, they won't send GPS data to the computer until
you send the magic string "ASTRAL" to the Tripmate.
You can either send "ASTRAL" from the M100, or short pins 2 and 3 (TxD and
RxD) at either end of the cable.  The Tripmate
actually expects AND sends the "ASTRAL" string to the M100, thus shorting
pins 2 and 3 will send the string back to the Tripmate
and jump start it.
Douglas

On Tue, Jan 23, 2018 at 8:09 PM, Mike Stein  wrote:

> Mine is a Tripmate, which has a 9-pin RS-232 cable.
> e.g.:
>
> https://www.ebay.com/p/DeLorme-Tripmate-GPS-Receiver/140809409
>
>
> - Original Message -
> From: "Peter Vollan" 
> To: 
> Sent: Tuesday, January 23, 2018 2:09 PM
> Subject: Re: [M100] gps
>
>
> > Delorme Earthmate 9538 v1.0
> > Wasn't that the one you used?
> > I think maybe I could buy a serial cable instead of making one?
> >
> >
> >
> > On 22 January 2018 at 21:23, Mike Stein  wrote:
> >> What are you using for the receiver?
> >>
> >> - Original Message -
> >> From: "Peter Vollan" 
> >> To: 
> >> Sent: Monday, January 22, 2018 8:56 PM
> >> Subject: Re: [M100] gps
> >>
> >>
> >>> ISTR that there was a webpage about it. Right now I need the pinout
> >>> into to hack the serial cable together.
> >>>
> >>> The question of "why do this" has come up before as well. Let me worry
> >>> about that one
> >>>
> >>>
> >>> On 22 January 2018 at 13:58, Mike Stein  wrote:
>  That might be me; we did have some discussions about the protocol
> etc. way back when and I did use the M100 with a Delorme Tripmate to log my
> trips for a while; fun and some interesting data, but not terribly useful
> in the end.
> 
>  I can't find any notes or programs at a fast look but it wasn't very
> complicated; just a matter of parsing the data stream into its various
> fields.
> 
>  I'll have another look around for anything from those days.
> 
>  m
> 
>  - Original Message -
>  From: "Peter Vollan" 
>  To: 
>  Sent: Sunday, January 21, 2018 6:03 PM
>  Subject: [M100] gps
> 
> 
> >A while back, years ago probably, someone detailed how they used a GPS
> > unit with a serial connection to their Model 100. I went as far as
> > acquiring the GPS unit and the connector for it to splice into a
> > cable, then the project got stalled. Anyone know where I could find
> > this info?
> >
>

Re: [M100] Has anyone connected a Raspberry Pi Zero to the option ROM socket?

[Douglas Quagliana]

I don't think there's a speed issue. They benchmarked the speed of the GPIO
pins on a Raspberry Pi and they were able to toggle the output pins at 22
Megahertz using an optimized program written in C.  See

http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/

The Model T's 8085 CPU is running way slower than 22 Megahertz.  I would
think that there's plenty of time to read the GPIO pins, decode the
address, set the data lines and flip the OE pin (or whatever else needs to
be set).  No?

I thought there might be an electrical incompatibility (wrong voltage,
can't source/sink enough current) or something else that prevented a direct
hookup between the GPIO pins and the option ROM pins.

C'mon... Nobody even tried this yet?

Douglas

On Wed, Sep 20, 2017 at 10:03 AM, John R. Hogerhuis 
wrote:

> A raspberry pi cannot simulate a ROM chip as far as I know.
>
> Seems like it would be a speed issue.
>
> You could do interface a pi to serial port though, that has been done.
>
> -- John
>

[M100] Has anyone connected a Raspberry Pi Zero to the option ROM socket?

[Douglas Quagliana]

Here some "Thinking before coffee" but...

Has anyone connected a Raspberry Pi Zero to the option ROM socket?

The Raspberry Pi Zero is one of several flavors of the Raspberry Pi
ARM computer.  The notable thing about the RPi Zero is that it is
extremely flat and measures only 65mm by 30mm (about 2.5 inches
by about 1.2 inches).

A quick google search found several projects where people "connected"
a Raspberry Pi (not a Raspberry Pi Zero) to a Model T over a serial port,
and one where they gutted(!) the Model T and put a Raspberry Pi in its
place (internally) but I could not find one where the Model T is unmodified
and a Raspberry Pi is acting like an EPROM in the option socket.
The RPi zero has a number of GPIO pins...

Has anyone tried this, or is there a good reason why you couldn't connect
up the GPIO pins through a mess of wires to the appropriate option
ROM socket pins? Are the GPIO pins electrically incompatible with
the option ROM pins?

Douglas

Re: [M100] New to the Group and "T"

[Douglas Quagliana]

Hi Dave,
   Welcome.
   I'll just add that you should also check the baud rate on the TNC.  Some
TNCs have a set of DIP switches to set the baud rate. It needs to match the
baud rate on your Model 102.  And, while the PC/laptop was probably happy
writing to the screen at 9600 baud and faster, the Model 102 might be
happier at a slower baud rate. If you see it dropping characters, change
both the TNC and Model 102 to a slower speed and/or enable flow control
(either XON/XOFF or RTS/CTS depending on what your TNC supports).
Douglas

On Fri, Sep 15, 2017 at 7:23 PM, Dave Christensen  wrote:

> Greetings,
>
>
>
> This is Dave from Utah and I am new to this group and to a “T”.  I
> purchased two TRS-80 Model 102 with 24K of memory from Ebay and they should
> arrive next week.  I do a lot of public service Amateur Radio work using
> Packet Radio Terminal Node Controllers and have been using a laptop PC.
> The really long events require hauling a generator to keep these running
> SO…..
>
> 1.  I am hoping to run the packet nodes from a “T” using a terminal
> program running 9600 baud with 8,N,1 settings.  I believe I will need a
> null modem cable to do this and some commands to set the serial port
> correctly.
>
> 2.  I would like to carry some DOCs on the 102 with me which means I need
> to get files to/from the PC and the 102.  I hope to find something easy to
> do this.
>
> 3.  How much value is finding and installing the extra 8K of memory?  Are
> there other ways to extend the file storage?
>
> 4.  I see they have an internal NiCad battery.  What happens if it can’t
> hold a charge?  How hard are they to replace?  Where do you get them?
>
> 5.  Any utility programs or other diversions you might recommend?
>
>
>
> My first computer was a Commodore 64  That I had for a long time.  I then
> had an Apple 2 PC with I think 128K of memory.  My next PC was an Epson
> with a hard drive (cost over $2500 in 1986 dollars).
>
>
>
> Thanks for any help you might give me and I am excited to take a trip back
> in time…..
>
>
>
> Dave
>
>
>

Re: [M100] Model 100 serial port

[Douglas Quagliana]

Other tricks that might be helpful:
- for another alternating bits sequence, repeatedly send capital letter
"U"  (a different sequence of alternating ones and zeros).
- for a long pulse, set the baud rate to the slowest speed that the serial
port supports and then send 0x00 or send 0xFF


On Wed, Aug 2, 2017 at 11:47 AM, Mike Stein  wrote:

> Good advice; the most likely culprit (because it's indirectly connected to
> the outside world with its static, lightning, ground loops etc.) is M35, a
> (1)4584.
>
> The only other IC would be M24, a 40H032 (which could probably be replaced
> with a 74HC(T)32).
>
> m
>
> - Original Message -
> From: "John Gardner" 
> To: 
> Sent: Wednesday, August 02, 2017 12:23 PM
> Subject: Re: [M100] Model 100 serial port
>
>
> > ...the problem is somewhere between the db25 and the UART...
> >
> > Most likely.  I'm no great troubleshooter,  but if I may...
> >
> > Set up a test file which contains a long series of 0xAAs,  as in
> >
> > 10101010...
> >
> > Send the file at a baud rate which is easy for you to see with
> >
> > whatever you've got for test equipment.
> >
> > While the file is being sent,  look for the signal.  When you find it,
> >
> > the fault is between that point & the DB25.  I expect the problem
> >
> > is either a PCB trace,  solder joint,  a defective buffer,  or the DB25
> >
> > connector itself (It happens...).
> >
> > There's also a small possibility that the UART is at fault,  but not
> likely.
> >
> > I'd be interested to hear what you find.
> >
> >
> >
> >
> >
> > On 8/2/17, John R. Hogerhuis  wrote:
> >> Well the good news is the problem is somewhere between the db25 and the
> >> UART :-)
> >>
> >> -- John.
> >>
>

Re: [M100] Upload: Model 100 Small-C library 0.0.7

[Douglas Quagliana]

Hi Willard,
   Can you add an wrapper entry for the FINDFREQ ROM routine that finds the
frequency
of the cassette port input?

Here's the info from the Covington map file

6FDBH -  Find the frequency of the cassette port.  This routine
measures the duration from the start to the stop of half of
the wave presented on the cassette port.  The result is the
number of 29 t-state cycles required to find the end of the
wave.  The byte at FF8EH determines if the count will trigger
on a high or low pulse.  For example, a 1200 hz signal, which
would take 416 ms to go through half of the wave, would cause
this routine to exit with a value aound 35.  If the sound
option is turned on (see FF44H), this routine will click the
beeper on each call.  Note:  Although this routine analyses
the cassette port in 29 T-state intervals, the actual routine
requires much more time to execute.
 Exit:
C - Number of 29 T-state cycles
A - Destroyed
   C flag - Set if the routine was canceled by a shift break

Thanks,
Douglas


On Thu, Jul 27, 2017 at 1:59 AM, Willard Goosey  wrote:

> The Model 100 library for Small-C 85 has been uploaded to:
> http://www.sdc.org/~goosey/m100/m100smallc0.0.7.zip
> -and-
> to my ("Willard Goosey") personal library at Club 100, under "linux
> cross development".
>
> In this release, the Printer output functions, printr(), prttab(), and
> pnotab() were verified as working, and test code and documentation
> added.
>
> This marks the first time I've had a dot-matrix printer hooked up since
> 2011... Did you know that the IBM proprinter has a dip-switch setting
> to let CR=CRLF just like Tandy printers? I didn't either, until I read
> the DOCS! :-) (And yes, you can still get ribbons for a Proprinter!)
>
> Next comes a bit of a long slog, as I need to verify that the wrapper
> functions for all the rs232 ROM calls are correct... After that, I
> should be clear to call it beta and freeze the spec for the wrapper
> functions.
>
> Willard
> --
> Willard Goosey  goo...@sdc.org
> Socorro, New Mexico, USA
> I search my heart and find Cimmeria, land of Darkness and the Night.
>   -- R.E. Howard
>

Re: [M100] Mystery Rom in Option Rom slot

[Douglas Quagliana]

You could try writing a little FOR loop in basic to PEEK the memory and print 
the contents. 

Perhaps something like

FOR I=62000 TO 65535: PRINT CHR( PEEK(I)); : NEXT 

then look for something readable like "Option ROM (C) 1986 Club100" ... or 
whatever. You might need to change the starting and ending addresses. 

Good luck,
Douglas

> On Mar 12, 2017, at 8:56 AM, hargarg trurthsr  wrote:
> Is there any way to figure out 
> what the rom is from basic ?
> 

Re: [M100] Hello (again) from a newly-minted ham radio operator

[Douglas Quagliana]

Welcome to the group Roger.  I still have a couple items on my "to do"
list for writing M100 assembly code to read the frequency of the
cassette port and decode digital data.
Douglas KA2UPW/5

On Wed, Jan 11, 2017 at 7:54 PM, Ken Pettit  wrote:
> Hey Jeff,
>
> What do yo umean by "digital stuff"?  I do digital stuff every day
> (designing a 14nm ASIC).  With 7 mm^2 of unused die area, I keep thinking
> how cool it would be to shove a full M100 implementation in there.  :)
>
> Ken
>
>
> On 1/11/17 11:03 AM, Jeff Gonzales wrote:
>
> anyone doing any digital stuff?  what's all the rage these days?  what about
> managing to still incorporate an m100?
>
> On Wed, Jan 11, 2017 at 1:47 PM, Phil Wheeler  wrote:
>>
>> Many of us go back and forth, Josh: Just wait awhile :-)
>>
>> Phil W7OX
>>
>> On 1/10/17 3:14 PM, Josh Malone wrote:
>>
>> I guess i went the other other way - cleared out my ham gear and piled my
>> desk full of vintage computers. It was fun but I guess I lost interest.
>>
>> -Josh
>> (Formerly KG4NGV)
>>
>> On Jan 10, 2017 3:05 PM, "Howard Pepper"  wrote:
>>>
>>> Congratulations on passing your Tech and General exams, and welcome back
>>> to the community!
>>>
>>> 73, Howard
>>> AC4FS
>>>
>>> On 01/10/2017 02:02 PM, Mark Wickens wrote:
>>>
>>>
>>> On Tue, 10 Jan 2017 at 18:52, Roger Mullins  wrote:

 Hi all-

 I was actually a member of this list several years back, but I've sort
 of neglected my M100 the last little bit (two young kiddos tend to
 monopolize free time!).  Anyhow, I passed my Technician and General exams a
 few months ago for my amateur radio license and have been learning the 
 ropes
 as an operator.  In my search for a good way to log contacts I happened
 across Ron Wiesen's programs and that led me to dust off my 100 and... here
 I am.  Looking forward to being back in the community!

 73, Roger KM4WVE





>>> Congratulations - I went the other way, sold my Tandy Model collection to
>>> fund my new amateur radio habit!
>>>
>>> Best of luck, Mark.
>>>
>>>
>>
>
>