Re: [M100] Space Game for TRS-80 Model 100 or NEC PC8201A

[Charlie Hoey]

Thanks so much for making/sharing this!

I finally got around to loading this on my 102 today. Fired it up and
immediately realized I was *definitely* going have to check out that
manual, and I'm glad I did. Great story building, loved the dev backstory
too. Still trying to wrap my head around the spherical location stuff,
looking forward to playing more with it.

-Charlie

On Tue, Aug 8, 2023 at 6:14 PM  wrote:

> Thanks, Alan.
>
>
>
> I hope you enjoy playing it.
>
>
>
> Lloyd
>
>
>
> *From:* M100  *On Behalf Of *Alan Reed
> *Sent:* Tuesday, August 8, 2023 4:44 PM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] Space Game for TRS-80 Model 100 or NEC PC8201A
>
>
>
> Lloyd, this looks fantastic. I’ve scanned through your documentation and
> can only say “Wow. I must learn this game.” Thanks!
>
>
>
> On Jul 26, 2023, at 7:13 PM, lloydel...@comcast.net wrote:
>
> 
>
> Hello all,
>
>
>
> I’ve written a BASIC game for the TRS-80 Model 100 and NEC PC8201A.It
> is a 3D space battle simulation.   I wish I could say it was new, but it
> was something I had started back in 1978 on a DEC LSI-11.   It eventually
> found its way to a 16K TRS-80 Model I Level II machine.There were a few
> iterations since the TRS-80 Model I version, but it is the TRS-80 Model I
> version that I converted to the Model 100 and NEC 8201.
>
>
>
> You can find it at www.github.com/LEJ-Projects/SpaceGame
>
>

Re: [M100] M200 vs M100/2 RS232 Differences

[Charlie Hoey]

Thanks all! Being able to poll the status of CTS in BASIC was the missing
link. I've been doing a similar mini BASIC "printer driver" that would just
do garbage loops to delay enough to usually print. I'm going to read the
ports as described above and see if I can get things humming on the M100.
Will report back.

Re the 200 flow control, I can at least say pretty definitively that
respects external CTS signals even in BASIC or telcom. I've tried it on a
couple different RS-232C printers and both promptly overflow from a 100 or
102, but keep pace on the 200.

Which is great news, I wish it were so easy on the 100. My use case is
printing out basic code from EDIT by just saving to the COM port. Super
cool that I have a cable that'll at least let me do it on the 200.

Here's my cable (male db25 on both sides, left is computer, right is
printer).

1 - 1
2 - 3
5 --|_ 20
6 --|
7 - 7

https://www.thingiverse.com/thing:4610032 - also fwiw, had great luck with
this easy and quick-to-print db25 shroud (which from the photos was
designed by someone with a model t). Standard m3 hardware, everything fit
first time.

On Sun, Jun 11, 2023 at 1:09 AM John R. Hogerhuis  wrote:

> To print to a printer that relies on hardware flow control on a m100 you
> need to write a program to print the file. Can be in BASIC or ML.
>
> In a loop you read the file to print and send the data a byte at a time,
> before sending each character use I/O command to check you're not flowed
> off. You just loop waiting until you're allowed to send again.
>
> That can work if you have the full formatted file to print in an external
> or memory file. Or if you can modify the program that does the printing.
>
> I had no idea the T200 enforced hardware flow control in the uart, that's
> interesting news.
>
>
> -- John.
>

[M100] M200 vs M100/2 RS232 Differences

[Charlie Hoey]

Apologies for the longish post, didn't have time to write a short one!

*TL;DR* I've been happily serial printing on my 100/102, but my 200 doesn't
work, so I'm in search of a non-hardware solution to tying DTS/RTS together
on a 200 to let it send RS-232 data.

I've been experimenting with RS232 printing on an Apple Imagewriter ii, and
I noticed that my 100's and 102 will print to it just fine, but my two
200's both just time out trying to print (by print I mean, save a text file
to "com:88n1enn". Same deal when just playing around in the terminal, it
gets a little buggy and I can't even quit without powering on and off, and
identical behavior on both otherwise healthy 200's.  What gives?

I dug around the m100 list archives, and there's this thread from 2015
http://lists.bitchin100.com/htdig.cgi/m100-bitchin100.com/2015-January/069836.html
that's very similar (also this one

and
this one
,
an old problem). So I hooked my 102 and 200 up to a scope and made a
little test harness to look around, and long story short, the 200 indeed
refuses to send any RS232 data unless RTS/CTS are tied together. This
doesn't seem to be the case for the 100 and 102, which will happily send
data out blind.

Digging through the Technical Reference Manual
,
the 200 does indeed have a different chip (82C51A) for handling serial IO,
and perhaps it is pickier about when it allows outbound traffic. The TRM
has what amounts to a decent data sheet on that chip, and this part caught
my eye (bottom of pdf page 98):

[image: image.png]
It seems like perhaps it's possible to fix this with software? Or, am I way
overthinking this whole thing, and there's another way to do it that's even
easier? I know I can just get a null modem cable, but it's kind of a bummer
to have to get all new cables to use a 200 with printers the 100/102
happily connected to.

Thanks for reading / any advice.
-Charlie

[M100] M102 bag trade for m100?

[Charlie Hoey]

I picked up an M100 in a 102 bag at a flea a while back, and was wondering
if anybody had a 100 bag they would like to trade for a 102 bag? Not
perfect but not rips.

Forgive me if there's a big value difference here I'm not aware of, figured
someone might be in the same boat.

-C

Re: [M100] Rex# Crash on an M102

[Charlie Hoey]

Thanks for the updates! I tried the following:

1. Flash REX# firmware via TPDD, which appeared to work but then exhibited
the same behavior of trying to load some ghost image on start and then
crashing
2. Flash REX# with the test.do, which I realize would lose the flash images
but I've got backups. However this also crashes, though with some
old-school panache, video here: https://photos.app.goo.gl/XfT9VQaVRBXG4HHM7

@Steve Thank you for the offer but I am pretty sure I have things backed
up. If I don't have any luck doing the full reflash, I may drop you a line
directly. This 102 is occasionally flakey, so once I'm back near another
machine I will give it one more go and see if it's 102 specific or if I've
bricked my poor rex.

Thanks again,
-Charlie

On Fri, May 26, 2023 at 12:32 AM Brian K. White 
wrote:

> First thing verify the connection to all the pins in the socket. It's a
> common weak point. No weak/compressed pins, no oxidization, rex# fully
> seated etc.
>
> Otherwise what Steve said, run the install/update tool to reflash the Rex#.
>
> --
> bkw
> On 5/25/23 21:27, Charlie Hoey wrote:
> > Hello there!
> >
> > I had my first crash on a Rex# that I can't get myself out of, curious
> > if anybody has any tips.
> >
> > I was in the process of creating a clean bank for a new project, and it
> > failed somewhere near the end. I RESET and then ran `CALL 63012` to
> > reload REX, but now whenever I start REXMGR, it attempts to load/write
> > something and hangs. I've done a cold reset, pulled batteries etc, so I
> > think it's in eeprom/flash somewhere. Here's a shot of what I'm seeing:
> >
> > Screen Shot 2023-05-25 at 9.13.23 PM.jpg
> > If images don't work here, launching REXMGR shows the standard top line
> > with "REX #2.1" in the top left, and the bottom right is the progress
> > bar, which fills up most of the way and then hangs.
> >
> > Any way I might peek/poke my way back to a usable state? I don't care
> > about the in progress job that failed, so if I could clear a flag or get
> > it to just abandon it that would be fine.
> >
> > Thanks as always!
> > -Charlie
>
>
>

[M100] Rex# Crash on an M102

[Charlie Hoey]

Hello there!

I had my first crash on a Rex# that I can't get myself out of, curious if
anybody has any tips.

I was in the process of creating a clean bank for a new project, and it
failed somewhere near the end. I RESET and then ran `CALL 63012` to reload
REX, but now whenever I start REXMGR, it attempts to load/write something
and hangs. I've done a cold reset, pulled batteries etc, so I think it's in
eeprom/flash somewhere. Here's a shot of what I'm seeing:

[image: Screen Shot 2023-05-25 at 9.13.23 PM.jpg]
If images don't work here, launching REXMGR shows the standard top line
with "REX #2.1" in the top left, and the bottom right is the progress bar,
which fills up most of the way and then hangs.

Any way I might peek/poke my way back to a usable state? I don't care about
the in progress job that failed, so if I could clear a flag or get it to
just abandon it that would be fine.

Thanks as always!
-Charlie

[M100] T200 printing issues + memory test

[Charlie Hoey]

Hey friends,

I nabbed a lovely clean T200 recently, and after writing a few letters on
it, I'm trying to print over parallel to an LPT-equipt typewriter I know to
work. Using the t200 built in page formatter (shift-print) in a doc, it has
the following behavior:

No errors, and LPT typewriter begins printing the first line in the doc, a
short date string, and then immediately follows with the rest of a random
line, then prints the final line and ends. The same doc prints perfectly
when moved to my only other T200 using a TPDD backpack. No obvious
corrosion on the connector, did full resets and swapped to a known good
Rex. Feels like either bad ram, or maybe a connector problem with a bad
clock line or ground or something? Any ideas? Fairly certain it is hardware
someplace, but so far it's the only issue I can find on the machine.

Was also going to test the ram, but was wondering how folks load testram
without loading TS-DOS, and thus changing the MAXRAM and preventing the
ramtst from running. Probably a noob question, but curious the easiest
approach to ramtest a fresh machine using a TPDD device to load software.
Or maybe there's a diagnostic ROM image folks like?


Thanks as always

Re: [M100] Tandy Portable Disk Drive 2

[Charlie Hoey]

Not sure if the TPDD2 model has dip switches, but perhaps they're in the
wrong setting?

On Mon, Nov 14, 2022 at 8:34 AM Josh Malone  wrote:

> Are you using the correct bootstrap? (Pdd 1 vs pdd 2)
>
> I made a video a few years ago showing various failure modes if that helps.
>
> https://youtu.be/p4q6pqPSaCU
>
> On Mon, Nov 14, 2022, 07:27 Stephen Adolph  wrote:
>
>> hi, just a few questions-
>>
>> Do you hear any activity at all, like the disk spinning?
>> Any LED activity at all?
>> When you toggle power on/off, does the LED flicker once?
>> Are you using battery or external power?  Would be good to confirm the
>> internal power supply is getting power and working correctly.
>>
>> steve
>>
>>
>>
>>
>>
>> On Sun, Nov 13, 2022 at 11:13 PM Spencer  wrote:
>>
>>> Hello.
>>>
>>> Received a drive from ebay yesterday and it needed some fixing, wouldn't
>>> take in a floppy (fixed) but kept getting a "Drive not Ready" after I
>>> tested it again. So I popped the hood again and the belt was melted. I
>>> cleaned the belt wheels and put in a new belt; hoped this fixed it but
>>> nope. I ran the IPL from T200 memory and ran the floppy command, but keep
>>> getting the same error. I'll check the data ribbon again tomorrow to make
>>> sure I plugged it in fully, but other than that does anyone have any ideas
>>> of anything else I can check to fix this error?
>>>
>>> Thanks,
>>> Spencer.
>>>
>>

[M100] Keycap compatibility between models

[Charlie Hoey]

Does anybody know off hand which, if any, keycaps are swappable between
model T models?

I've got a caps lock key from a 100 that looks _awfully_ close, but doesn't
quite snap into my 200. Wondering if my keyswitch is gummed up/damaged, or
if they're just not compatible.

[M100] my PDDuino SD card floppy setup

[Charlie Hoey]

Hey everybody. Just wanted to quickly share my build of BKW's fantastic
PDDuino TPDD emulator project - https://github.com/bkw777/PDDuino.

This is a little module that plugs into the 25 pin serial on a Model T and
lets you use an SD card as a TPDD floppy drive. TS-DOS seems to play nicely
with it, and I can save/load any kind of file to an SD card, and even
bootstrap TS-DOS on a fresh machine. It works on several boards, I went
with an Adafruit Feather version, and it's rather remarkable how little
design or assembly was required. The parts were probably ~$40 all in, w/
lipo battery management and charging, and micro sd card slot all there out
of the box. Aside from the serial port adapter, all you have to solder are
header pins.

Also thanks again to Brian for sharing all this, and fielding my many
questions about his library with great explanations. (most of these are in
this issue thread for anyone curious:
https://github.com/bkw777/PDDuino/issues/5)

Software for the build is here:
* PDDuino firmware, flashable w/ Arduino - https://github.com/bkw777/PDDuino

Hardware consists of:
* Adafruit Feather M0 Adalogger - https://www.adafruit.com/product/2796
(microcenter also often has these on the shelf)
* Adafruit Feather-sized battery - https://www.adafruit.com/product/3898
* Brian's Feather MounT board w/ 25pin serial connector + assorted parts -
https://oshpark.com/shared_projects/61udqrJB
* any old micro sd card

The MAX3232 is the hardest of the whole bunch to get (I imagine Jeff must
know this pain well from his backpack project). I ended up having to buy a
couple on ebay, but it wasn't too bad. Other than that and a few jellybean
0803 caps, it's just soldering on some headers and a switch. The battery
Adafruit sells is designed to tuck in between a Feather and a wing-sized
module, with exactly the right sized leads. The whole thing feels compact
and solid, though I would like to design a printable case for it. Not quite
coffee-shop-friendly at the moment.

A few pics:
Attached to M102 - https://charliehoey.com/projects/model-t/feather-102.jpg
25pin side - https://charliehoey.com/projects/model-t/feather-angle.jpg
top side - https://charliehoey.com/projects/model-t/feather-top.jpg
hidden lipo battery -
https://charliehoey.com/projects/model-t/feather-battery.jpg

I'll wrap up there, but this has been working great for me for a month
now, so I wanted to spread the word. Curious if anybody else has given it a
try?

Re: [M100] assembly language first steps

[Charlie Hoey]

I have been dipping my toes in as well, mostly writing/assembling on the
hardware itself with BYTEIT, and more recently CMZASM (both available here:
http://www.club100.org/library/libprg.html). Both work by writing your asm
code in the TEXT app and then compiling separately. BYTEIT assembles out to
a specific memory address immediately, while CMZASM outputs a .BA file that
POKEs everything in, which I didn't really get at first but actually has
some appeal / is easier to reuse.

Been meaning to write up the little bit I've done so far somewhere, so far
I've just gotten a short LFSR seedable random number generator routine
going that I can CALL from basic, but I'm pretty sure I'm doing something
wrong because things still get a little crashy.

On Mon, Sep 26, 2022 at 9:44 PM Ken Pettit  wrote:

> Hi Will,
>
> I think most people on the list prefer tasm, though I use only the
> assembler in VirtualT personally.  Of course I wrote it and so therefore
> know how to use it and all of it's quirks.
>
> Ken
>
> On 9/26/22 5:13 PM, Will Senn wrote:
>
> It will only be a matter of time before I want to program in assembly on
> my m100. I've read up and familiarized myself with the landscape on this
> and find it a bit confusing.
>
> What is the preferred (or most common method) of getting an
> assembly/machine language program to run on the m100. I know that I can use
> basic to run machine code, but that's kludgy. I believe there is a basic
> assembler program in the wild and I've read about Custom Software's
> assembler, are either or both available online?
>
> Thanks!
>
> Will
>
>
>

[M100] Spare T200 caps-lock keycap

[Charlie Hoey]

Got a T200 that's in good shape aside from the caps-lock key cap being
cracked. Anybody have a spare they would be willing to sell? Just need the
cap, switch is okay

Re: [M100] what's the Right Way to code and assemble on model-t hardware

[Charlie Hoey]

Thanks for that Ken! Nice to have confirmation on taht.

And yeah I found BYTEIT over here on the programming section of the club100
archives: http://www.club100.org/library/libprg.html

Just in case it's useful to anybody, so far I've ported over an LFSR
pseudo-random number generator over from here:
https://64nops.wordpress.com/2021/02/07/pseudo-random-number-generators/ ,
I went with the short 16bit one. His code is for Z80, but in this case no
instructions the 8085 doesn't also have. My version adapted for M100
BYTEIT is as follows:

; 64nops galois 16bit lfsr routine
ORG 56300
LFVAR EQU 56301
START LXI HL,6128H
DAD HL
SBB A
ANI 83H
XRA L
MOV L,A
SHLD LFVAR
MOV HL,BC
MOV M,BC
RET
END

After assembling the above, from BASIC I can then run `CALL 56300` to
generate a new number, and `PEEK(56301)` to retrieve it.

Anyhow, so far so good, but I may check out CMZASM, since it seems like if
I want to easily share/reuse things, it's handy to have it installable
through basic.

Re: [M100] Warning: Not a(n) M100 but a PC-2 question.

[Charlie Hoey]

Thanks a lot for that, Jeff. I believe I actually used a switching 5v
supply, which turned out to be enough.

Would it be a safe-ish strategy to aim for a regulated/switching power
supply that hits the lower end of the battery pack's voltage? I had
imagined it would just draw as much current as it needed as long as I kept
the voltage under control, but I hadn't considered the battery being a sort
of active power regulation component in the way you're describing. Super
interesting, there's always more to know.

[M100] what's the Right Way to code and assemble on model-t hardware

[Charlie Hoey]

Hey all, looks like the search might be broken in the archives, so
apologies if there's a whole thread on this I missed.

So I've done some 6502 development, and I have recently been enjoying
learning some basics of 8080 assembly on my 100 and 102 using BYTEIT. Very
informative to learn a second architecture. So far I'm just porting in a
few LFSR random number routines and trying to get the lay of the land.

I've read a fair bit on club100, and this doc (
http://www.club100.org/library/doc/ramabout.html) feels like it should have
the answers I want, but I'm still a bit lost.

So if I type `?HIMEM` in basic, is that showing me the upper limit of what
BASIC will attempt to allocate in RAM? Basically like, how do I carve out a
chunk of RAM that is safe-ish from getting clobbered? Right now, I'm
setting HIMEM to 5, telling BYTEIT to assemble there, and ORGing small
routines up in the 56000 range. Seems to work for a while, but looks wrong
from how memory is described in the doc above.

Basically wondering the best way to determine a safe range for sandboxing
assembly on the machine itself.

Thanks!

Re: [M100] Warning: Not a(n) M100 but a PC-2 question.

[Charlie Hoey]

Was perusing the archive and noticed this thread, I can confirm the PC-2
plotter runs happily without a battery if you upgrade the power supply.
Just get newer one with the same polarity and voltage, but higher amperage.
I think mine was 2A, but *definitely* double check that polarity!

Also, first post on the forum so hopefully I'm not spamming everybody with
a 3 year old thread