Re: [M100] Using CP/M for assembly work

[Brian Brindle]

Quick correction, if you don't have a Z80 rst 7 is gonna end poorly - try
rst 6 instead.
Only see these things AFTER hitting send..

Start DDT
A100  # Start assembly at location $100

mvi c,2   # Put 2 in the C-register for Console Out
mv e,48  # $48 is ASCII H
call 5  # entry point for all system calls (BDOS)
mvi c,2   # Put 2 in C-register for Console Out
mvi e,49  #$49 ASCII I
call 5   # BDOS call again
rst 6# return to DDT

g100 to execute, should print something like "HI" with memory location
after.

Still tons of fun!

On Sat, Mar 16, 2024 at 4:03 PM Brian Brindle  wrote:

> Simple DDT "HI" program - can be expanded to "hello world" if ambitious
> enough.
>
> Start DDT
> A100  # Start assembly at location $100
>
> mvi c,2   # Put 2 in the C-register for Console Out
> mv e,48  # $48 is ASCII H
> call 5  # entry point for all system calls (BDOS)
> mvi c,2   # Put 2 in C-register for Console Out
> mvi e,49  #$49 ASCII I
> call 5   # BDOS call again
> rst 7# return to DDT
>
> g100 to execute, should print something like "HI" with memory location
> after.
>
> Tons of fun!
>
> Brian
>
>
>
> On Sat, Mar 16, 2024 at 3:12 PM Will Senn  wrote:
>
>> Brian,
>>
>> Definitely. DDT is great. I'll be working through that next. I finally
>> got a program working and assembled - from the 2.2 manual - read chars
>> until *. Now, I just gotta get hello, world working I was sure, it
>> would work... oh, wait, when it says to CALL CPM, I bet it's not talking
>> about where CP/M is DE1EH... I bet it's that 0005H entry point... off to
>> explore.
>>
>> Will
>>
>> On 3/16/24 1:08 PM, Brian Brindle wrote:
>>
>> If you just want to play, don't discount ddt in CP/M. Cheap and dirty way
>> to play with everything.
>>
>> On Sat, Mar 16, 2024, 1:48 PM Stephen Adolph 
>> wrote:
>>
>>> regarding file transfer, use
>>> IMPORT
>>> or
>>> EXPORT
>>> in CP/M.  Included in package.
>>> These programs access a "TPDD".  Filenames are 8.3 format,
>>>
>>> cheers
>>> Steve
>>>
>>> On Sat, Mar 16, 2024 at 1:36 PM Will Senn  wrote:
>>>
>>>> I broke down and started reading the manuals (REXCPM, CP/M 2.2, etc).
>>>> It's starting to come together (again?)... I've inlined the answers I
>>>> figured out for posterity or the next clueless newb who comes along.
>>>>
>>>> On 3/16/24 11:00 AM, Will Senn wrote:
>>>>
>>>> 2. CP/M works from RexCPM, which is great, cuz CP/M recognizes more
>>>> memory:
>>>>
>>>> 64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0
>>>>
>>>> Yes, it does recognize more memory and it serves up an A: drive that's
>>>> a big chunk of that 2MBs. Solid. Talked about here:
>>>> http://bitchin100.com/wiki/index.php?title=M100_CP/M
>>>>
>>>> My questions are as follows:
>>>>
>>>> 4. In CP/M, how do I get back to MENU?
>>>>
>>>> Duh, F8 :).
>>>>
>>>> 5. When I start CP/M, is it just running CP/M against the M100's memory
>>>> or am I in some special whizbang virtual environment where I have
>>>> additional disks available somehow?
>>>>
>>>> It's a whizbang environment for sure - 64K ram and a nearly 2MB A:
>>>> drive.
>>>>
>>>> As for my broken ASM, another duh, thanks John for the tip - I need to
>>>> write a CP/M friendly program that call it's routines and not the ROM 
>>>> calls.
>>>>
>>>> CP/M seems the way to go, though. It kinda reminds me of RT11, but with
>>>> ASM instead of MACRO11.  ed... well, after you figure out that you need to
>>>> retrieve the file contents into the buffer, it kinda makes sense - nice
>>>> video - I love ED:
>>>> https://www.youtube.com/watch?v=7pqaj050X7g
>>>>
>>>> Still need to figure out how to get files into and out of cp/m though...
>>>>
>>>> Off to read some more.
>>>>
>>>> -will
>>>>
>>>
>>

Re: [M100] Using CP/M for assembly work

[Brian Brindle]

Simple DDT "HI" program - can be expanded to "hello world" if ambitious
enough.

Start DDT
A100  # Start assembly at location $100

mvi c,2   # Put 2 in the C-register for Console Out
mv e,48  # $48 is ASCII H
call 5  # entry point for all system calls (BDOS)
mvi c,2   # Put 2 in C-register for Console Out
mvi e,49  #$49 ASCII I
call 5   # BDOS call again
rst 7# return to DDT

g100 to execute, should print something like "HI" with memory location
after.

Tons of fun!

Brian



On Sat, Mar 16, 2024 at 3:12 PM Will Senn  wrote:

> Brian,
>
> Definitely. DDT is great. I'll be working through that next. I finally got
> a program working and assembled - from the 2.2 manual - read chars until *.
> Now, I just gotta get hello, world working I was sure, it would work...
> oh, wait, when it says to CALL CPM, I bet it's not talking about where CP/M
> is DE1EH... I bet it's that 0005H entry point... off to explore.
>
> Will
>
> On 3/16/24 1:08 PM, Brian Brindle wrote:
>
> If you just want to play, don't discount ddt in CP/M. Cheap and dirty way
> to play with everything.
>
> On Sat, Mar 16, 2024, 1:48 PM Stephen Adolph  wrote:
>
>> regarding file transfer, use
>> IMPORT
>> or
>> EXPORT
>> in CP/M.  Included in package.
>> These programs access a "TPDD".  Filenames are 8.3 format,
>>
>> cheers
>> Steve
>>
>> On Sat, Mar 16, 2024 at 1:36 PM Will Senn  wrote:
>>
>>> I broke down and started reading the manuals (REXCPM, CP/M 2.2, etc).
>>> It's starting to come together (again?)... I've inlined the answers I
>>> figured out for posterity or the next clueless newb who comes along.
>>>
>>> On 3/16/24 11:00 AM, Will Senn wrote:
>>>
>>> 2. CP/M works from RexCPM, which is great, cuz CP/M recognizes more
>>> memory:
>>>
>>> 64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0
>>>
>>> Yes, it does recognize more memory and it serves up an A: drive that's a
>>> big chunk of that 2MBs. Solid. Talked about here:
>>> http://bitchin100.com/wiki/index.php?title=M100_CP/M
>>>
>>> My questions are as follows:
>>>
>>> 4. In CP/M, how do I get back to MENU?
>>>
>>> Duh, F8 :).
>>>
>>> 5. When I start CP/M, is it just running CP/M against the M100's memory
>>> or am I in some special whizbang virtual environment where I have
>>> additional disks available somehow?
>>>
>>> It's a whizbang environment for sure - 64K ram and a nearly 2MB A: drive.
>>>
>>> As for my broken ASM, another duh, thanks John for the tip - I need to
>>> write a CP/M friendly program that call it's routines and not the ROM calls.
>>>
>>> CP/M seems the way to go, though. It kinda reminds me of RT11, but with
>>> ASM instead of MACRO11.  ed... well, after you figure out that you need to
>>> retrieve the file contents into the buffer, it kinda makes sense - nice
>>> video - I love ED:
>>> https://www.youtube.com/watch?v=7pqaj050X7g
>>>
>>> Still need to figure out how to get files into and out of cp/m though...
>>>
>>> Off to read some more.
>>>
>>> -will
>>>
>>
>

Re: [M100] Using CP/M for assembly work

[Brian Brindle]

If you just want to play, don't discount ddt in CP/M. Cheap and dirty way
to play with everything.

On Sat, Mar 16, 2024, 1:48 PM Stephen Adolph  wrote:

> regarding file transfer, use
> IMPORT
> or
> EXPORT
> in CP/M.  Included in package.
> These programs access a "TPDD".  Filenames are 8.3 format,
>
> cheers
> Steve
>
> On Sat, Mar 16, 2024 at 1:36 PM Will Senn  wrote:
>
>> I broke down and started reading the manuals (REXCPM, CP/M 2.2, etc).
>> It's starting to come together (again?)... I've inlined the answers I
>> figured out for posterity or the next clueless newb who comes along.
>>
>> On 3/16/24 11:00 AM, Will Senn wrote:
>>
>> 2. CP/M works from RexCPM, which is great, cuz CP/M recognizes more
>> memory:
>>
>> 64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0
>>
>> Yes, it does recognize more memory and it serves up an A: drive that's a
>> big chunk of that 2MBs. Solid. Talked about here:
>> http://bitchin100.com/wiki/index.php?title=M100_CP/M
>>
>> My questions are as follows:
>>
>> 4. In CP/M, how do I get back to MENU?
>>
>> Duh, F8 :).
>>
>> 5. When I start CP/M, is it just running CP/M against the M100's memory
>> or am I in some special whizbang virtual environment where I have
>> additional disks available somehow?
>>
>> It's a whizbang environment for sure - 64K ram and a nearly 2MB A: drive.
>>
>> As for my broken ASM, another duh, thanks John for the tip - I need to
>> write a CP/M friendly program that call it's routines and not the ROM calls.
>>
>> CP/M seems the way to go, though. It kinda reminds me of RT11, but with
>> ASM instead of MACRO11.  ed... well, after you figure out that you need to
>> retrieve the file contents into the buffer, it kinda makes sense - nice
>> video - I love ED:
>> https://www.youtube.com/watch?v=7pqaj050X7g
>>
>> Still need to figure out how to get files into and out of cp/m though...
>>
>> Off to read some more.
>>
>> -will
>>
>

Re: [M100] Uploaded Model 600 service manual

[Brian Brindle]

Fantastic thank you!

On Sat, Mar 2, 2024, 1:23 PM  wrote:

> Nice!
>
> -Original Message-
> From: M100  On Behalf Of Brian K. White
> Sent: Saturday, March 2, 2024 6:09 AM
> To: m...@bitchin100.com
> Subject: [M100] Uploaded Model 600 service manual
>
> Finally scanned and uploaded the Model 600 Programmers reference and
> Service Manual.
>
> https://archive.org/details/tandy_600_26-3901_programmers_reference_and_bios_specification/
> https://archive.org/details/tandy_600_26-3901_servicemanual/
>
> Note that archive.org web viewer kind of destroys it, especially the
> schematics. Download the pdf to get the real thing.
> There's copies here too http://tandy.wiki/Model_600#Manuals
>
> Another copy of the programmers ref already existed but the service manual
> is new.
>
> --
> bkw
>
>
>
>

Re: [M100] Portcomm

[Brian Brindle]

Portable Communicator was written by Chris DeHerrera. The article sort of
mangles his name. The newer version/package info can be found here. Not
sure if the original portable communicator exists anywhere though.

http://www.club100.org/library/doc/wp2docs.html


On Fri, Dec 22, 2023 at 12:28 AM Brian K. White 
wrote:

> Apparently at one time Club100 sold a MS-DOS TPDD server called Portcomm.
>
> Anyone ever seen it? I can find nothing on Club100 or anywhere else.
>
> https://archive.org/details/P100-Magazine/1989-11/page/22/
>
> --
> bkw
>

Re: [M100] MiniNDP

[Brian Brindle]

Nice!

On Sat, Dec 16, 2023 at 5:33 PM Brian K. White  wrote:

> down to 6 lines
> inserted spaces for easier manual read & type
> got rid of I variable name to avoid looking like 1
>
> 1 CLEAR 0,61000 :OUT 129,2 :FOR N=0 TO 9 :B=INP(131) :NEXT
> 2 GOSUB 6 :S=N :GOSUB 6 :L=N :E=S+L :GOSUB 6 :X=N
> 3 N=S+1007 :FOR A=S TO E :B=INP(131) :POKE A,B
> 4 IF A=N THEN OUT 129,1
> 5 ?"."; :NEXT :?"type CLEAR 0,"S":NEW" :SAVEM "RAMDSK",S,E,X
> 6 N=INP(131) :N=N+INP(131)*256 :RETURN
>
> And line 5 can actually be reduced to just:
>
> 5 NEXT :CALL X
>
> --
> bkw
>
> On 12/16/23 12:57, Brian K. White wrote:
>
> I now have a working manual BASIC bootstrap that can load RAMDSK.CO from
> the device after a cold restart.
> https://github.com/bkw777/NODE_DATAPAC/blob/main/software/RAMDSK/RBOOT.DO
>
> It is only 8 lines like the old docs say BOOT.BA was
> Well, it's 7 lines not counting a comment and a message, or 9 lines
> counting both.
> But they are not very neat or convenient. It's still kind of a lot to
> manually type in for a bootstrap, but if you had a print out you could type
> it in a couple minutes and then you have RAMDSK back a few seconds after
> that.
> This is not exactly a convenient way to install, but it should exist as an
> option just on principle.
> You're on the road, suffer a cold reset, everything's safely backed up on
> the RAMPAC, but you need to get RAMDSK installed somehow.
>
> I was dreaming it might be possible to write something short enough to
> print right on the card in the silkscreen. hahaha no. :)
> Maybe it can be improved over time.
>
> I also wrote a simple inspector that can read raw data from anywhere on
> the devivce, in either bank, and display in either ascii or hex, and the
> ascii also shows all the non-printing control characters as their CTRL-x
> character in inverse video so the display doesn't get messed up and no
> bytes are hidden either. So 0x00 shows as inverse "@" for instance.
> https://github.com/bkw777/NODE_DATAPAC/tree/main/software/RPI
>
> The main point of it is to be small and scrutable, uses no machine code,
> supports banks.
>
>
> --
> bkw
>
>

Re: [M100] 19.2Kbps on the Tandy 102

[Brian Brindle]

Johnatahn,

Ebay is another good source, not sure exactly what you have to go through
these days in Sweden to get things. If it's the level converter you are
having issues with let me know. They are super tiny and I think I paid $20
for 50 of them. You could get a Christmas Card with TTL to RS232 joy.

On the CP/M emulation front - I've been using the z88dk
https://z88dk.org/site/ for most of my stuff lately. Seems to play very
nicely with everything I'm doing and contains some cross compiling
environments specifically for Tandy and other retros I use. The disk utils
work great with the D88 image files I'm using on the Epson. I'll take a
look at the one you suggested though, looks interesting. Thanks!

Brian



On Thu, Dec 14, 2023 at 4:06 AM jonathan.y...@telia.com <
jonathan.y...@telia.com> wrote:

> Hi Brian,
>
> Thanks for the details.  Looks like the level shifter board is the key to
> the size, but I'll confess I never thought of mounting a DB 25 directly on
> the case of the pi (purchased or otherwise).  I looked around and those
> boards are available, just need to decide for the best way to purchase one
> (I'm in the Sweden so orders from outside the EU get hit with import duty
> AND a handling charge).
>
> I've used Pareg Patel's z80 instruction set emulator for emulating CPM
> under Unix and I've run it on several environments with no hiccups (AIX,
> Digital, and Linux of course).
>
> Jonathan
>
> Original Message
> From : bbrin...@gmail.com
> Date : 2023-12-13 - 22:34 (CEST)
> To : m...@bitchin100.com
> Subject : Re: [M100] 19.2Kbps on the Tandy 102
>
> Haha - Glad you like it Joshua if I do happen to make more or improve on
> this one I'll let you know. I don't exactly have ADD but what I do seem to
> have is the inability to control what my current interests are and recently
> it's been playing with CP/M on the M100, PX-8 and building up a CP/M
> emulation environment on the TanPi. That was going great till I managed to
> get my hands on one of the MiniNDPs Brian K White made and now I'm all
> about his recent 512K upgrade. Never thought I'd get to play with an NDP so
> this is exciting stuff.
>
> I have a WP-2 and have tried to use the TanPi on it, but usually ended up
> frustrated with the lack of needed keys. When doing unixy stuff having
> pipes, curly braces, back ticks etc are handy. The M100 seems to have
> everything I need, although you do have to know to hit shift GRPH - to do a
> pipe and GRPH ( for { etc.
>
> I like ROM-View 80 but for me it's not enough of a payoff to have to
> reconfigure the local terminal settings to accommodate the new layout. The
> way I use the TanPi is primarily for content creation and syncing. I will
> write documents either with a real editor or just by typing cat > file.txt
> and typing away with CTRL-C to stop. Then sync the files with my local
> storage or the cloud when I have WiFi. If I need to do something really
> heavy I'll use an external screen or my VNC session with my phone.
>
> A lot of times when I'm at home I will ssh into my TanPi from my desktop
> and can drag/drop files over SSH, use the real keyboard and monitor for
> stuff and it's quite handy.
>
> It's a fun toy.
>
> Brian
>
>
>
> On Wed, Dec 13, 2023 at 1:29 PM Joshua O'Keefe < maj...@nachomountain.com>
> wrote:
>
>> > On Dec 13, 2023, at 6:22 AM, Brian Brindle < bbrin...@gmail.com>
>> wrote:
>> > My whole setup is a total kludge / hack that I never expected to use
>> long term. I was just doing a POC and built the whole thing in about 10
>> minutes with stuff I had laying around but here we are almost five years
>> later...
>>
>> Brian, you may consider this rig a kludge, but I'm jealous and think it's
>> gorgeous.  Using the T as a portable terminal with a perfectly capable tiny
>> Linux box cleverly attached is a great hack.  I wish I had one of these!  A
>> 9-pin WP-2 version—what with the 80-column display—would be amazing.
>>
>> Now that I think about it, have you tried using either one of the
>> 80-column software setups, like ROM-View 80 or Ultrascreen100?  It might
>> make for an even more pleasant terminal experience.
>>
>> Gosh, I'm tempted to ask if you'd slap another one together in your
>> copious free time!
>
>
>
>

Re: [M100] 19.2Kbps on the Tandy 102

[Brian Brindle]

r than scavenge the parts. The math does not justify it at all
> since I'm not broke, plus the chipquick and kimwipes and flux-off isn't
> free, but I just can not make myself not scavenge those parts!
>
> My REX Classic is on revision 30 or so by now, and I have 3 or 4 rexs
> that have had their chips transplanted like 10 times, and so far
> everything has seemed to survive all that accumulated solder hot time
> and ultrasonic cleaner time. Everything is still working anyway.
>
> --
> bkw
>
>
> On 12/13/23 16:34, Brian Brindle wrote:
> > Haha - Glad you like it Joshua if I do happen to make more or improve on
> > this one I'll let you know. I don't exactly have ADD but what I do seem
> > to have is the inability to control what my current interests are and
> > recently it's been playing with CP/M on the M100, PX-8 and building up a
> > CP/M emulation environment on the TanPi. That was going great till I
> > managed to get my hands on one of the MiniNDPs Brian K White made and
> > now I'm all about his recent 512K upgrade. Never thought I'd get to play
> > with an NDP so this is exciting stuff.
> >
> > I have a WP-2 and have tried to use the TanPi on it, but usually ended
> > up frustrated with the lack of needed keys. When doing unixy stuff
> > having pipes, curly braces, back ticks etc are handy. The M100 seems to
> > have everything I need, although you do have to know to hit shift GRPH -
> > to do a pipe and GRPH ( for { etc.
> >
> > I like ROM-View 80 but for me it's not enough of a payoff to have to
> > reconfigure the local terminal settings to accommodate the new layout.
> > The way I use the TanPi is primarily for content creation and syncing. I
> > will write documents either with a real editor or just by typing cat >
> > file.txt and typing away with CTRL-C to stop. Then sync the files with
> > my local storage or the cloud when I have WiFi. If I need to do
> > something really heavy I'll use an external screen or my VNC session
> > with my phone.
> >
> > A lot of times when I'm at home I will ssh into my TanPi from my desktop
> > and can drag/drop files over SSH, use the real keyboard and monitor for
> > stuff and it's quite handy.
> >
> > It's a fun toy.
> >
> > Brian
> >
> >
> >
> > On Wed, Dec 13, 2023 at 1:29 PM Joshua O'Keefe  > <mailto:maj...@nachomountain.com>> wrote:
> >
> >  > On Dec 13, 2023, at 6:22 AM, Brian Brindle  > <mailto:bbrin...@gmail.com>> wrote:
> >  > My whole setup is a total kludge / hack that I never expected to
> > use long term. I was just doing a POC and built the whole thing in
> > about 10 minutes with stuff I had laying around but here we are
> > almost five years later...
> >
> > Brian, you may consider this rig a kludge, but I'm jealous and think
> > it's gorgeous.  Using the T as a portable terminal with a perfectly
> > capable tiny Linux box cleverly attached is a great hack.  I wish I
> > had one of these!  A 9-pin WP-2 version—what with the 80-column
> > display—would be amazing.
> >
> > Now that I think about it, have you tried using either one of the
> > 80-column software setups, like ROM-View 80 or Ultrascreen100?  It
> > might make for an even more pleasant terminal experience.
> >
> > Gosh, I'm tempted to ask if you'd slap another one together in your
> > copious free time!
> >
>
> --
> bkw
>
>

Re: [M100] 19.2Kbps on the Tandy 102

[Brian Brindle]

Haha - Glad you like it Joshua if I do happen to make more or improve on
this one I'll let you know. I don't exactly have ADD but what I do seem to
have is the inability to control what my current interests are and recently
it's been playing with CP/M on the M100, PX-8 and building up a CP/M
emulation environment on the TanPi. That was going great till I managed to
get my hands on one of the MiniNDPs Brian K White made and now I'm all
about his recent 512K upgrade. Never thought I'd get to play with an NDP so
this is exciting stuff.

I have a WP-2 and have tried to use the TanPi on it, but usually ended up
frustrated with the lack of needed keys. When doing unixy stuff having
pipes, curly braces, back ticks etc are handy. The M100 seems to have
everything I need, although you do have to know to hit shift GRPH - to do a
pipe and GRPH ( for { etc.

I like ROM-View 80 but for me it's not enough of a payoff to have to
reconfigure the local terminal settings to accommodate the new layout. The
way I use the TanPi is primarily for content creation and syncing. I will
write documents either with a real editor or just by typing cat > file.txt
and typing away with CTRL-C to stop. Then sync the files with my local
storage or the cloud when I have WiFi. If I need to do something really
heavy I'll use an external screen or my VNC session with my phone.

A lot of times when I'm at home I will ssh into my TanPi from my desktop
and can drag/drop files over SSH, use the real keyboard and monitor for
stuff and it's quite handy.

It's a fun toy.

Brian



On Wed, Dec 13, 2023 at 1:29 PM Joshua O'Keefe 
wrote:

> > On Dec 13, 2023, at 6:22 AM, Brian Brindle  wrote:
> > My whole setup is a total kludge / hack that I never expected to use
> long term. I was just doing a POC and built the whole thing in about 10
> minutes with stuff I had laying around but here we are almost five years
> later...
>
> Brian, you may consider this rig a kludge, but I'm jealous and think it's
> gorgeous.  Using the T as a portable terminal with a perfectly capable tiny
> Linux box cleverly attached is a great hack.  I wish I had one of these!  A
> 9-pin WP-2 version—what with the 80-column display—would be amazing.
>
> Now that I think about it, have you tried using either one of the
> 80-column software setups, like ROM-View 80 or Ultrascreen100?  It might
> make for an even more pleasant terminal experience.
>
> Gosh, I'm tempted to ask if you'd slap another one together in your
> copious free time!

Re: [M100] 19.2Kbps on the Tandy 102

[Brian Brindle]

Hi Jonathan,

My whole setup is a total kludge / hack that I never expected to use long
term. I was just doing a POC and built the whole thing in about 10 minutes
with stuff I had laying around but here we are almost five years later...
One day I'll get off my butt and make a proper 3d printed case etc.

I'll provide some amazon links to similar stuff I used but shop around I'm
sure you'll find better prices.

I was building contact tracing devices during Covid so had a surplus of Pi
Zero's and these cases:
https://www.amazon.com/Vilros-Raspberry-Zero-Compatible-Transparent/dp/B08ZDPNM4H

I cut a hole in it with a file, drilled two holes for the screw mounts.

I used a standard bulk-head mount DB-25 Pin male connector, cut all the
pins off the backside so they were flush, used some small gage wire to
connect to a Mini RS232 to TTL MAX232 Convert board like these:

https://www.amazon.com/KOOBOOK-MAX3232-Converter-Adaptor-Transfer/dp/B07VNLVJ57

Wired up TX/RX to the RIN1 and ROUT1 of the converter board, then wired the
DIN1 / DOUT1 to the proper GPIO ports on the PI soldering directly to the
pads. Grabbed 3V off the Rpi to power the converter. (3V ran cooler than
trying to run off 5V. 5V got super hot.)

Here are some photos of the unit including a bonus photo of me on the bus
being all cyber-punk with my M102 and my heads up display. It was pandemic
times so forgive the mask.
https://niedobry.com/mod100/tanpi/

On Wed, Dec 13, 2023 at 7:06 AM jonathan.y...@telia.com <
jonathan.y...@telia.com> wrote:

> Hello,
>
> I know it is starting to be off-topic, but some details about how you did
> the pi (I assume a zero-w) and the case with the level-shifter would be
> nice.  I've done this with other components, but I've never gotten anything
> nearly so small.  I have a pi-hat with a level shifter, and it basically
> doubled the size of pi zero.  Something this small and that would plug
> right into the serial port of the m100 would be great.
>
> Jonathan
>
> >Original Message
> >From : run@rin.run
> >Date : 2023-12-13 - 02:11 (CEST)
> >To : m...@bitchin100.com
> >Subject : Re: [M100] 19.2Kbps on the Tandy 102
> >
> >Wow Brian!
> >
> >This setup with the Pi attached to the back looks amazing. It's attached
> >so cleanly as well. I appreciate you doing the `stty' at the end,
> >hopefully mirroring your setup will help me get things working better on
> >my end.
> >
> >I do wonder if the fact that you are using the Pi's GPIO pins to do
> >serial instead of a USB adapter is part of why your system is working so
> >well. If you have a USB adapter floating around, I'd be really curious
> >if you got the same results with that connected to the PI instead of
> >connecting it directly.
> >
> >Thanks again for sharing your experience getting this working.
> >
> >On Tue, Dec 12, 2023 at 05:42:28PM -0500, Brian Brindle wrote:
> >>This has come up in discussion a few times so I wanted to show that
> >>19.2Kbps on the Tandy 100 is possible with only software flow
> control.
> >>
> >>Here is a video of me creating a 500 line 40 col file that is 20KB,
> >>transferring it to the M102 and back again using the 19.2Kbps serial
> >>connection. It gets slowed down due to the screen being so slow
> making
> >>it absolutely of no value to be running at those speeds but does
> >>demonstrate that flow control can be used on a Linux device in this
> >>situation.
> >>
> >>Hardware flow control would work best and is what I would recommend
> but
> >>I wanted a device that would work on a stock M100/102 and on a M200
> >>where the flow control lines do not work properly.
> >>
> >>It's apparently really hard to film, type and remember what to say
> so I
> >>apologize for that..
> >>
> >>[1]https://youtu.be/BGxx__Zr1O4
> >>
> >>Brian
> >>
> >> References
> >>
> >>1. https://youtu.be/BGxx__Zr1O4
> >
>

Re: [M100] 19.2Kbps on the Tandy 102

[Brian Brindle]

>  Also T200 not working with hardware flow control? It used to. Steve
ported HTERM to it. I do recall we had issues with the > 19200bps baud
rates on the T200.

Well, know how part of the theme of this thread is things not happening the
way we remember them? I had this flagged as a flow control issue, guess it
sort of is but what I was remembering is the T200 using the DTR signal for
chip select on the tone generator. On the M100/102 if you disable hardware
flow control they will ignore DTR as expected. The T200, regardless of how
you set flow control, wanders off and doesn't come back until you present
it with DTR.

So in this case, my setup will not work unless you loop back DTR with a
jumper.

Brian

On Tue, Dec 12, 2023 at 9:25 PM Daryl Tester <
dt-m...@handcraftedcomputers.com.au> wrote:

> On 13/12/23 09:39, John R. Hogerhuis wrote:
>
> > But what I recollect and what happened are not always the same thing.
>
> Oh man, I hear you there, especially the more ... "seasoned" I get.
>
> Cheers,
>--dt
>

Re: [M100] 19.2Kbps on the Tandy 102

[Brian Brindle]

Thanks Runrin,

I was pretty happy with how the Pi Zero version turned out. I've had this
setup in some form or another for several years. The original version of
this was on a larger raspberry pi so I have used USB to serial adapters
without issues. Initially the Zero was run off of a USB to serial adapter
as well until one day I thought I might be able to stuff a MAX232 inside
the tiny case with a bulkhead mount RS323 and it worked. So presently you
can use my Zero on the M100 either via ttyUSB0 or ttyS0. Results are the
same. I do recommend using a FT232RL based converter or an authentic
Prolific PL2303 if you can find it. That way you know you are getting
something with correct voltage levels.

Brian


On Tue, Dec 12, 2023 at 8:13 PM runrin  wrote:

> Wow Brian!
>
> This setup with the Pi attached to the back looks amazing. It's attached
> so cleanly as well. I appreciate you doing the `stty' at the end,
> hopefully mirroring your setup will help me get things working better on
> my end.
>
> I do wonder if the fact that you are using the Pi's GPIO pins to do
> serial instead of a USB adapter is part of why your system is working so
> well. If you have a USB adapter floating around, I'd be really curious
> if you got the same results with that connected to the PI instead of
> connecting it directly.
>
> Thanks again for sharing your experience getting this working.
>
> On Tue, Dec 12, 2023 at 05:42:28PM -0500, Brian Brindle wrote:
> >This has come up in discussion a few times so I wanted to show that
> >19.2Kbps on the Tandy 100 is possible with only software flow control.
> >
> >Here is a video of me creating a 500 line 40 col file that is 20KB,
> >transferring it to the M102 and back again using the 19.2Kbps serial
> >connection. It gets slowed down due to the screen being so slow making
> >it absolutely of no value to be running at those speeds but does
> >demonstrate that flow control can be used on a Linux device in this
> >situation.
> >
> >Hardware flow control would work best and is what I would recommend
> but
> >I wanted a device that would work on a stock M100/102 and on a M200
> >where the flow control lines do not work properly.
> >
> >It's apparently really hard to film, type and remember what to say so
> I
> >apologize for that..
> >
> >[1]https://youtu.be/BGxx__Zr1O4
> >
> >Brian
> >
> > References
> >
> >1. https://youtu.be/BGxx__Zr1O4
>

Re: [M100] 19.2Kbps on the Tandy 102

[Brian Brindle]

Thanks Mike, all good suggestions for sure but I was aiming to make the
worst possible situation to push the flow control as hard as I could.

John, before you questioned it I was certain, but now my memory may be
failing me but I seem to recall the T200 stealing the flow controlines to
run the latch logic for the barcode port? I'll need to go back through my
notes on that one though. I could be confusing it for another retro
computer.




On Tue, Dec 12, 2023, 6:09 PM John R. Hogerhuis  wrote:

>
>
> On Tue, Dec 12, 2023 at 3:00 PM Mike Stein  wrote:
>
>> I've never had any problems at 19.2K using Windows so, as John
>> suggests. there may be Linux-specific issues.
>>
>> There are buffers in most if not all USB-RS232 adapters and also in
>> the program on the PC at the other end, and sometimes these need to be
>> tuned a bit. When I send a 25K file from TeraTerm to an M100, TeraTerm
>> finishes in 1/2 minute or so, but the M100 still receives data for
>> another minute.
>>
>> And don't forget that TEXT is usually effectively faster for
>> transferring files since it doesn't have to display or scroll.
>>
>> m
>>
>>
> Well Brian is seeing xon/xoff working fine with Linux at high speed with
> his setup.
>
> Maybe time to try the experiments again to figure out what is different.
>
> Also T200 not working with hardware flow control? It used to. Steve ported
> HTERM to it. I do recall we had issues with the > 19200bps baud rates on
> the T200.
>
> But what I recollect and what happened are not always the same thing.
>
> -- John.
>

[M100] 19.2Kbps on the Tandy 102

[Brian Brindle]

This has come up in discussion a few times so I wanted to show that
19.2Kbps on the Tandy 100 is possible with only software flow control.

Here is a video of me creating a 500 line 40 col file that is 20KB,
transferring it to the M102 and back again using the 19.2Kbps serial
connection. It gets slowed down due to the screen being so slow making it
absolutely of no value to be running at those speeds but does demonstrate
that flow control can be used on a Linux device in this situation.

Hardware flow control would work best and is what I would recommend but I
wanted a device that would work on a stock M100/102 and on a M200 where the
flow control lines do not work properly.

It's apparently really hard to film, type and remember what to say so I
apologize for that..

https://youtu.be/BGxx__Zr1O4

Brian

Re: [M100] M100 ergonomics

[Brian Brindle]

Correction on my last e-mail - muscle memory took over and I typed 98N1D -
this should 98N1E with the E to enable XON/XOFF.  Classic case of target
fixation right there. Don't type D, don't type D.. Typed D.

John, I have had some issues with how enabling flow control is done. The
method I settled on was to enable it with stty after logging in through a
sourced .bashrc script. I abandoned trying to get it to work natively in
getty, even eventually swapped out getty for the more supported agetty set
in "old" mode.

While I may be connecting at 19200 the speed is dependent on the screen
unfortunately. That can get downright frustrating. Hackerb9 explains
several other fixes for keys and stuff way better than I ever could in that
git hub link I put up earlier. I recommend just about everything he talks
about except I can't condone the use of emacs or nano. Real men use VI.

One other possibility would be the serial adapter you are using. I have had
issues with the voltage levels being just off enough on cheap USB to serial
adapters that the M100 had troubles.

Brian


On Mon, Dec 11, 2023 at 4:45 PM John R. Hogerhuis  wrote:

> Interesting... I could never go that fast without h/w flow control...
> Linux wouldn't drop characters, but it would overrun the T's receive buffer
> because it didn't react immediately to xoff. I don't know why... my theory
> was maybe the driver doesn't see the xoff until it popped out of the
> stream. Maybe screen in the middle processes the xoff sooner. All I had in
> the loop was getty or equivalent.
>
> Between that and ANSI escapes from xterm and utf8 and whatnot full screen
> console stuff was always messed up without HTERM to filter and flow
> control.
>
> -- John.
>

Re: [M100] M100 ergonomics

[Brian Brindle]

I'm using the Andi Diller termcap, just because it's the one I had on hand.
These should work for you:
https://bitchin100.com/wiki/index.php?title=Model_T_Termcap

This guy here put together a really good resource for more information on
how to setup your environment:
https://github.com/hackerb9/Tandy-Terminfo

I keep my system set at 19200bps, enable xon/xoff through stty at login,
have the Tandy set to 98N1D and I typically don't have any issues other
than the expected ones due to the small screen size. It is painfully slow,
but it works.

To get around issues with flow control when SSHing I use screen with
xon/xoff enabled. The Pi will do the buffering so I typically don't have
any overrun issues.


On Mon, Dec 11, 2023 at 2:36 PM runrin  wrote:

> Brian-
>
> Could you share the terminfo file you use on your raspberry pi to get
> your M100 working?
>
> I regularly use a Heathkit terminal with my OpenBSD machine, and that
> works extremely well with `crtscts' in stty at 19200 baud, even though
> the terminal itself can only handle 9600 baud without flow control. I've
> got everything tuned nicely to avoid any issues with color codes/etc on
> that machine and I really enjoy using it.
>
> Despite that, I've struggled a lot to get my linux machines to play nice
> with the small screen of the M100. I've tried out 3 or 4 different
> terminfos
> I've seen floating around the net, but haven't gotten consistent enough
> results to actually want to use the M100 as a terminal for any length of
> time.
>
> I've also tried multiple different USB serial adapters, and have had
> issues at speeds greater than 300 baud, even with `ixon ixoff' in stty
> and flow control enabled on the M100. I am able to start and stop
> incoming data manually with `^S' and `^Q', so I'm sure that is working,
> but I still get garbage whenever the M100 has to slow down drawing to
> the screen.
>
> Tips to getting the M100 working better with linux would be greatly
> appreciated.
>
> Thanks!
>
> On Mon, Dec 11, 2023 at 07:08:05AM -0500, Brian Brindle wrote:
> >I've got several and they get used often. Daily task is usually note
> >taking with IDEA! or journaling with the built in text editor. I do
> use
> >the Ultimate ROM II and View80 a LOT.  I also use it pretty
> extensively
> >for Amateur radio, primarily logging and satellite tracking. I also
> >spend quite a bit of time messing around in CP/M mode doing weird
> stuff
> >with DDT.
> >
> >I have a raspberry-pi connected that I've dubbed the "Tan-PI". It's
> got
> >several programs on it to do file sharing / TPDD emulation and I have
> a
> >hacked together perl script that sends each key press from the Tandy
> to
> >the X-windows system as keyboard input allowing me to use the M100 as
> >the keyboard to the Raspberry Pi system. I will often remote the
> >Raspberry Pi with VNC on my phone when I need a "real desktop" to send
> >an e-mail or go to a web stie the tandy can't handle from the Linux
> >CLI.
> >
> >These are my two go-to addons. I use a small USB power bank and this
> >for power:
> >[1]https://www.amazon.com/gp/product/B0BJDSG28P
> >
> >I also have a bunch of these Laptop "Foot" devices. Just drop one at
> >the back, middle of the Model-T and it greatly improves the ergonomix.
> >They are cheap so I keep one in my bag and one on my desk.
> >[2]
> https://www.amazon.com/SUPBEE-Universal-Computer-Anti-Slip-Ventilate
> >d/dp/B085QL2QXS
> >
> >On Mon, Dec 11, 2023 at 6:30 AM Gary Wilkinson
> ><[3]gpwilkin...@hotmail.com> wrote:
> >
> >  My T102 is connected as a terminal to my VAX4000. I have a DVI
> >  connected to an LCD screen with composite video, so I get 80 column
> >  full screen text. Very useable.
> >
> >  Sent from my iPhone
> >
> >  > On 11 Dec 2023, at 10:25, Lee Osborne
> >  <[4]leeosbo...@fastmail.co.uk> wrote:
> >  >
> >  > 
> >  > I use mine quite a lot for journalling and writing articles,
> >  mainly because it has the best keyboard of any device I own. I find
> >  that a desk or table is fine as long as the light is reasonably
> >  good. I can type faster on it than most other computers or
> >  keyboards.
> >  >
> >  > Lee
> >  >
> >  >> On Mon, 11 Dec 2023, at 00:47, runrin wrote:
> >  >> Hey all!
> >  >>
> >  >> I was wondering if people would be willing to share how they
> >  

Re: [M100] M100 ergonomics

[Brian Brindle]

Hey Jonathan,

I made a terrible video of it a few years ago. You can see it here:
https://www.youtube.com/watch?v=GIv831sT50w

I wish in the demo I had typed somewhere other than the terminal to show it
works anywhere on the desktop, not just there. For example I am sending
this e-mail right now from FireFox on the Raspberry Pi using the M102 as my
keyboard.

This was just meant as a proof of concept and I never got around to doing
much else with it. My current job is weird, so my github is not public. The
code is basic, doesn't need to be perl I just used it because I was
familiar with how to make it read individual keys quickly with Glib. Glib
modules are not installed by default so would need to be added.

I had to re-map some keys, added some mouse movements and a "command mode"
where you can type key combinations since that is impossible natively.  The
way that I use it is access my Pi via the serial port, type perl ./
keyboard.pl and type away. (CTRL-C for the remote system has been re-mapped
to GRPH-C)

The script will work fine with a running X windows environment on the
native / hardware display but if using VNC you will need to fiddle with
X-security settings.

[BEGIN PERL SCRIPT]
#!/usr/bin/perl

#Simple script to send keypresses from CLI to xdtool
#Brian Brindle July, 2021

use warnings;
use strict;
use Glib;
use Glib qw/TRUE FALSE/;
use Term::ReadKey;
$|++;

#$SIG{'INT'} = 'IGNORE';   #Ignore Ctrl-C for now work on more elgant way
of handling.
$ENV{'DISPLAY'} = ':0.0';  # Set X-display

sub xdo_cmd {
 ReadMode('normal'); # restore normal tty settings
 print "INPUT KEYS:";
 my $keyin = ;
 chomp $keyin;
 qx (xdotool key "$keyin");
 ReadMode('cbreak'); #read single char
 return;
}

ReadMode('cbreak'); #read single char

my $main_loop = Glib::MainLoop->new;

Glib::Idle->add(
sub{
my $char;
if (defined ($char = ReadKey(0)) ) {#ReadKey(0) - use 1 for
non-blocking (Return undef)
 if (ord($char) == 10) { print "[RETURN->]\n"; qx (xdotool key
Return); }
 elsif  (ord($char) == 30) { print "[UP->]\n"; qx (xdotool key
Up); }
 elsif  (ord($char) == 31) { print "[DOWN->]\n"; qx (xdotool
key Down); }
 elsif  (ord($char) == 29) { print "[LEFT->]\n"; qx (xdotool
key Left); }
 elsif  (ord($char) == 28) { print "[RIGHT->]\n"; qx (xdotool
key Right); }
 elsif  (ord($char) == 132) { print "[CTRL-C->]\n"; qx (xdotool
key ctrl+c); } #GRPH + C
 elsif  (ord($char) == 1) { print "[MOUSE LEFT]\n"; qx (xdotool
mousemove_relative --polar  270 10); }
 elsif  (ord($char) == 6) { print "[MOUSE RIGHT]\n"; qx
(xdotool mousemove_relative --polar  270 10); }
 elsif  (ord($char) == 20) { print "[MOUSE UP]\n"; qx (xdotool
mousemove_relative --polar  0 10); }
 elsif  (ord($char) == 2) { print "[MOUSE DOWN]\n"; qx (xdotool
mousemove_relative --polar  180 10); }
 elsif  (ord($char) == 34) { print "[QUOTATION]\n"; qx (xdotool
key 0x0ad3); }
 elsif  (ord($char) == 174) { xdo_cmd(); } #CMD + / to enter
xdotool combos. Example ctrl+alt+del
else {
print "$char-> chr\$(", ord($char),")\n";
# Action wtih key presses here:
qx (xdotool type "$char");
}
 }
  return TRUE; #Loop
  });

$main_loop->run;
ReadMode('normal'); # restore normal tty settings
__END__
[END PERL SCRIPT]

Brian

On Mon, Dec 11, 2023 at 10:43 AM jonathan.y...@telia.com <
jonathan.y...@telia.com> wrote:

> Hello,
>
> That perl script and whatever else is needed to let the M100 act as
> keyboard input for X windows sounds interesting.  I assume you have the
> raspberry pi video output device showing X?  Would you be willing to share
> the details?
>
> Jonathan
>
> Original Message
> From : bbrin...@gmail.com
> Date : 2023-12-11 - 13:08 (CEST)
> To : m...@bitchin100.com
> Subject : Re: [M100] M100 ergonomics
>
> I've got several and they get used often. Daily task is usually note
> taking with IDEA! or journaling with the built in text editor. I do use the
> Ultimate ROM II and View80 a LOT.  I also use it pretty extensively for
> Amateur radio, primarily logging and satellite tracking. I also spend quite
> a bit of time messing around in CP/M mode doing weird stuff with DDT.
>
> I have a raspberry-pi connected that I've dubbed the "Tan-PI". It's got
> several programs on it to do file sharing / TPDD emulation and I have a
> hacked together perl script that sends each key press from the Tandy to the
> X-windows system as keyboard input allowing me to use the M100 as the
>

Re: [M100] M100 ergonomics

[Brian Brindle]

Hi Lee,

I don't typically have any issues with it. I'm using V2.12 with the built
in TS-DOS support without any issues. Works fine on all my TPDD emulators.
I will admit since I'm using a REX I will often swap the URII for TS-DOS
just because I can when I'm doing lots of file stuff. What sort of issues
are you seeing with yours? You using it with REX or have a real / emulated
ROM?

Brian


On Mon, Dec 11, 2023 at 7:13 AM Lee Osborne 
wrote:

> Brian - I really like the Ultimate ROM II, but I've had a lot of trouble
> getting it to play ball with TS-DOS. I don't know if you've tried doing
> that at all, but if you have, I'd appreciate tips on getting it to work.
>
> Lee
>
> On Mon, 11 Dec 2023, at 12:08, Brian Brindle wrote:
>
> I've got several and they get used often. Daily task is usually note
> taking with IDEA! or journaling with the built in text editor. I do use the
> Ultimate ROM II and View80 a LOT.  I also use it pretty extensively for
> Amateur radio, primarily logging and satellite tracking. I also spend quite
> a bit of time messing around in CP/M mode doing weird stuff with DDT.
>
> I have a raspberry-pi connected that I've dubbed the "Tan-PI". It's got
> several programs on it to do file sharing / TPDD emulation and I have a
> hacked together perl script that sends each key press from the Tandy to the
> X-windows system as keyboard input allowing me to use the M100 as the
> keyboard to the Raspberry Pi system. I will often remote the Raspberry Pi
> with VNC on my phone when I need a "real desktop" to send an e-mail or go
> to a web stie the tandy can't handle from the Linux CLI.
>
> These are my two go-to addons. I use a small USB power bank and this for
> power:
> https://www.amazon.com/gp/product/B0BJDSG28P
>
> I also have a bunch of these Laptop "Foot" devices. Just drop one at the
> back, middle of the Model-T and it greatly improves the ergonomix. They are
> cheap so I keep one in my bag and one on my desk.
>
> https://www.amazon.com/SUPBEE-Universal-Computer-Anti-Slip-Ventilated/dp/B085QL2QXS
>
>
>
>
> On Mon, Dec 11, 2023 at 6:30 AM Gary Wilkinson 
> wrote:
>
> My T102 is connected as a terminal to my VAX4000. I have a DVI connected
> to an LCD screen with composite video, so I get 80 column full screen text.
> Very useable.
>
> Sent from my iPhone
>
> > On 11 Dec 2023, at 10:25, Lee Osborne  wrote:
> >
> > 
> > I use mine quite a lot for journalling and writing articles, mainly
> because it has the best keyboard of any device I own. I find that a desk or
> table is fine as long as the light is reasonably good. I can type faster on
> it than most other computers or keyboards.
> >
> > Lee
> >
> >> On Mon, 11 Dec 2023, at 00:47, runrin wrote:
> >> Hey all!
> >>
> >> I was wondering if people would be willing to share how they typically
> >> use their Model Ts.
> >>
> >> I've found that it's pretty difficult for me to find a comfortable
> >> position to use my Model 100 for any length of time. I'm always bending
> >> forward to get a better view when I sit at a table or desk, and when
> >> it's on my lap the lack of palmrest causes the keyboard to slide too
> >> close to my body making it hard to type.
> >>
> >> Do you typically only use them on desks? Do you use yours on your lap?
> >> Do you use a lap desk? Any tips for how you comfortably use a Model T
> >> for longer stretches (30+ minutes) would be appreciated.
> >>
> >> Thanks!
> >>
> >
> > Lee Osborne
> > West Lothian, Scotland
> > 07960 096282
> > leeosbo...@fastmail.co.uk
> > www.journeyman.online/services
>
>
> Lee Osborne
> West Lothian, Scotland
> 07960 096282
> leeosbo...@fastmail.co.uk
> www.journeyman.online/services
>

Re: [M100] M100 ergonomics

[Brian Brindle]

I've got several and they get used often. Daily task is usually note taking
with IDEA! or journaling with the built in text editor. I do use the
Ultimate ROM II and View80 a LOT.  I also use it pretty extensively for
Amateur radio, primarily logging and satellite tracking. I also spend quite
a bit of time messing around in CP/M mode doing weird stuff with DDT.

I have a raspberry-pi connected that I've dubbed the "Tan-PI". It's got
several programs on it to do file sharing / TPDD emulation and I have a
hacked together perl script that sends each key press from the Tandy to the
X-windows system as keyboard input allowing me to use the M100 as the
keyboard to the Raspberry Pi system. I will often remote the Raspberry Pi
with VNC on my phone when I need a "real desktop" to send an e-mail or go
to a web stie the tandy can't handle from the Linux CLI.

These are my two go-to addons. I use a small USB power bank and this for
power:
https://www.amazon.com/gp/product/B0BJDSG28P

I also have a bunch of these Laptop "Foot" devices. Just drop one at the
back, middle of the Model-T and it greatly improves the ergonomix. They are
cheap so I keep one in my bag and one on my desk.
https://www.amazon.com/SUPBEE-Universal-Computer-Anti-Slip-Ventilated/dp/B085QL2QXS




On Mon, Dec 11, 2023 at 6:30 AM Gary Wilkinson 
wrote:

> My T102 is connected as a terminal to my VAX4000. I have a DVI connected
> to an LCD screen with composite video, so I get 80 column full screen text.
> Very useable.
>
> Sent from my iPhone
>
> > On 11 Dec 2023, at 10:25, Lee Osborne  wrote:
> >
> > 
> > I use mine quite a lot for journalling and writing articles, mainly
> because it has the best keyboard of any device I own. I find that a desk or
> table is fine as long as the light is reasonably good. I can type faster on
> it than most other computers or keyboards.
> >
> > Lee
> >
> >> On Mon, 11 Dec 2023, at 00:47, runrin wrote:
> >> Hey all!
> >>
> >> I was wondering if people would be willing to share how they typically
> >> use their Model Ts.
> >>
> >> I've found that it's pretty difficult for me to find a comfortable
> >> position to use my Model 100 for any length of time. I'm always bending
> >> forward to get a better view when I sit at a table or desk, and when
> >> it's on my lap the lack of palmrest causes the keyboard to slide too
> >> close to my body making it hard to type.
> >>
> >> Do you typically only use them on desks? Do you use yours on your lap?
> >> Do you use a lap desk? Any tips for how you comfortably use a Model T
> >> for longer stretches (30+ minutes) would be appreciated.
> >>
> >> Thanks!
> >>
> >
> > Lee Osborne
> > West Lothian, Scotland
> > 07960 096282
> > leeosbo...@fastmail.co.uk
> > www.journeyman.online/services
>

Re: [M100] Intermittent problem at higher baud rates on RS-232 interface

[Brian Brindle]

And of course I didn't see my mistake until seconds after hitting send..
The settings to enable flow control are STAT 88N1E - sorry about that.



On Mon, Jul 10, 2023 at 7:02 AM Brian Brindle  wrote:

> Hey Jesse - congrats on getting the model T! They make great packet
> stations for sure. The issue you are describing sounds like a flow control
> one. Depending on what TNC you are using you should be able to activate
> XON/XOFF. On my old Timewave I think the command is XFLOW ON.
>
> Then just ensure that you have flow control enabled in TERM with STAT
> 88N1D (For 9600 bps) and you should be good to go.
>
> Great to see other amateurs on the list and I know you are going to love
> the M100 as a tool. My club used them and the LOGBA program for field day
> this year and it worked out fantastic. Can't beat that screen and battery
> life.
>
> 73 - DE KW4KB
>
> Brian
>
>
> On Sun, Jul 9, 2023 at 6:20 PM Jesse Bertier  wrote:
>
>> First time getting my hands on a model T.  I am attempting to connect to
>> a TNC at 9600 baud.  I have both matched for 8,N,1 and 9600 baud.  TNC
>> works with other PCs.  I’m using TELCOM and set the parameters correctly.
>> What happens at 9600 baud is the text coming into the m100 is garbled
>> mostly and on occasion some valid words come across.  When I set both to
>> 300 baud, works perfectly.   It seems to be problematic if there’s a solid
>> block of text coming in, like a string of 20-30 words for example.
>>
>> Before I dig into the problem with the service manual and get out the
>> scope, does anyone know if these are supposed to work well at 9600 or up to
>> 19,200 ?  Or, does the buffer or machine get overloaded at higher rates?
>> Is TELCOM the issue?
>>
>> Sent from my iPhone
>
>

Re: [M100] Intermittent problem at higher baud rates on RS-232 interface

[Brian Brindle]

Hey Jesse - congrats on getting the model T! They make great packet
stations for sure. The issue you are describing sounds like a flow control
one. Depending on what TNC you are using you should be able to activate
XON/XOFF. On my old Timewave I think the command is XFLOW ON.

Then just ensure that you have flow control enabled in TERM with STAT 88N1D
(For 9600 bps) and you should be good to go.

Great to see other amateurs on the list and I know you are going to love
the M100 as a tool. My club used them and the LOGBA program for field day
this year and it worked out fantastic. Can't beat that screen and battery
life.

73 - DE KW4KB

Brian


On Sun, Jul 9, 2023 at 6:20 PM Jesse Bertier  wrote:

> First time getting my hands on a model T.  I am attempting to connect to a
> TNC at 9600 baud.  I have both matched for 8,N,1 and 9600 baud.  TNC works
> with other PCs.  I’m using TELCOM and set the parameters correctly.  What
> happens at 9600 baud is the text coming into the m100 is garbled mostly and
> on occasion some valid words come across.  When I set both to 300 baud,
> works perfectly.   It seems to be problematic if there’s a solid block of
> text coming in, like a string of 20-30 words for example.
>
> Before I dig into the problem with the service manual and get out the
> scope, does anyone know if these are supposed to work well at 9600 or up to
> 19,200 ?  Or, does the buffer or machine get overloaded at higher rates?
> Is TELCOM the issue?
>
> Sent from my iPhone

Re: [M100] Recognize this cable?

[Brian Brindle]

That's an old school PCMCIA MODEM telephone cable with A 41H8105 connector.
You'd cram that huge crazy end into the PCMCIA modem and the other into
your wall jack.

On Thu, Apr 20, 2023 at 12:00 PM MikeS  wrote:

> Thought I'd ask here if anyone recognizes/wants this cable before it hits
> the trash; kinda looks like it might be for a PDA of some kind.
>
> m
>

Re: [M100] Merry Christmas, Happy Hanukah, Happy New Year

[Brian Brindle]

I got the forward from Stephen, that was pretty awesome Ken! Thank you and
happy holidays to all!

I had no idea the M100 could hit notes that high...

Brian


On Sun, Dec 25, 2022 at 2:45 PM Stephen Adolph  wrote:

> I received it!  Very cool Ken, and creative!  Happy holidays, Steve
>
> On Sun, Dec 25, 2022 at 1:46 PM Ken Pettit  wrote:
>
>> Hmm,  that might explain why John was the only one to respond!  I wonder
>> if it was stripped because of a binary tokenized file being attached.
>>
>> No worries though, I uploaded it to my Personal Libraries section at
>> Club100 under the "Media" folder.
>>
>> Ken
>>
>> On 12/25/22 10:39 AM, Brian K. White wrote:
>> > On 12/25/22 13:28, John R. Hogerhuis wrote:
>> >> I highly recommend not letting the day go by without checking out
>> >> Ken's Christmas card.
>> >
>> > I see no message about this. I checked my spam folders and two
>> > different accounts (though both are gmail)
>> >
>>
>>

Re: [M100] Questions about tokenizing BASIC in UNIX

[Brian Brindle]

One way under Linux I have gotten around the issues of software flow
control is to use screen for my serial terminal sessions. It has software
flow control support built in. A must if you want to use ssh or another app
that doesn't play well with stty.

Brian


On Fri, Sep 23, 2022, 5:59 AM Brian White  wrote:

> I don't believe this is enough to ensure clean data. I must have a dozen
> real ftdi adapters from different manufacturers and I keep having to
> increase the per-byte sleep in dlplus' bootstrapper and tsend.ps1 and
> PDDuino as I discover new basic programs to feed in.
>
> Some programs will ingest fine at 5ms/byte, some will fail on some
> particular part of one line, always the same spot, unless the sleep is
> increased to 6ms.
>
> Then I discover some other code that fails at 6 but succeeds at 7.
>
> Some of the problem code I just found in the M100SIG, some were new things
> like the REX setup utils, some I created the new problem by refactoring
> existing tpdd client loaders to make them smaller. This made them
> apparently more difficult to ingest, but they are still legal correct
> BASIC, so any procedure needs to be able to handle the worst case or else
> it's no good.
>
> For an example, one of the loaders I re-worked, used to work fine before,
> and then the reworked version would always be missing a : in the middle of
> one long line of code. Always the same byte missing. And it didn't cause
> the transfer to fail immediately, it tokenized on the fly without apparent
> error. But the program was broken and didn't work when you try to run it.
>
> This is all with real ftdi adapters and with xon/off enabled on both ends.
>
> It may work at 1200 or something where the low baud rate does the same job
> as a sleep between bytes, but no way at 19200.
>
> I will put together a few test cases that expose the problem. And if this
> method does somehow work then that would indeed be pretty interesting and
> good to know.
>
> I believe all the right chip does is help, and make more code more likely
> to make it through, but not actually guarantee it. It probably does make a
> large improvement, and you can probably show numerous examples of data that
> fails on one adapter and succeeds on an ftdi chip.
>
> --
> bkw
>
> On Thu, Sep 22, 2022, 8:57 PM John R. Hogerhuis  wrote:
>
>>
>>
>> On Thu, Sep 22, 2022 at 5:32 PM B 9  wrote:
>>
>>>
>>> Of particular note for troubleshooting is that, if some of the data gets
>>> transferred, but it is garbled or you get a ?DS ERROR, then the problem
>>> is that your PC's serial port does not support "ON CHIP SOFTWARE FLOW
>>> CONTROL".  One solution is to buy a serial card or USB cable with an FTDI
>>> chip in it. (Other companies make ICs that support on chip software flow
>>> control, I even have a cheap Prolific 2303 device that does, but FTDI is
>>> the only company I know of whose chips are supposed to always work. )
>>>
>>>
>> I've never heard of this on-chip software flow control.All I knew was
>> that software flow does not work under Linux. My experience is software
>> flow control with a Model T *does* work on Windows.
>>
>> Is that something you have to enable? Seems awfully strange to have the
>> chip interceding in-band. Automatic hardware flow control I have heard of.
>>
>> This failure on Linux is why I made HTERM to use hardware flow control
>>
>> If there's a consistent way to make it work on Linux, it would be good to
>> know. Even just with FTDI chipset. Windows prolific drivers are trash. I
>> don't know about Prolific on Linux.
>>
>> Is the stty command you put supposed to enable on-chip software flow
>> control? Which part?
>>
>> *s**tty -F /dev/ttyUSB0 ixon ixoff  stop ^S start ^Q  -onlcr -icrnl  eof
>> ^Z  19200*
>>
>> -- John.
>>
>>>

Re: [M100] M100 Linux keyboard via inputattach?

[Brian Brindle]

I was trying to do this myself and ended up going a different way. I have
done this with xdotool and a perl wrapper that allows me to re-map some
keys and use the xdotool commands to do special key combinations and even
mouse basic movements. I had all kinds of plans to do stuff with this but
when I added the feature to hit CODE+/ and could enter in the xdotool
keywords to do anything I sort of lost momentum. Not to mention I switched
directions and started playing with an adafruit bluefruit EZ-key for serial
to BT connectivity. I thought the hardware version would be more useful for
typing on anything that could accept BT Keyboard's.

The perl script is below for inspiration and here is a link to a video of
me using it:
https://www.youtube.com/watch?v=GIv831sT50w

#Simple Perl script to send keypresses from CLI to xdtool
#Brian Brindle July, 2021

use warnings;
use strict;
use Glib;
use Glib qw/TRUE FALSE/;
use Term::ReadKey;
$|++;

#$SIG{'INT'} = 'IGNORE';   #Ignore Ctrl-C for testing - Ctrl-C remapped to
GRPH-C
$ENV{'DISPLAY'} = ':0.0';  # Set X-display

ReadMode('cbreak'); #read single char

my $main_loop = Glib::MainLoop->new;

Glib::Idle->add(
sub{
my $char;
if (defined ($char = ReadKey(0)) ) {#ReadKey(0) - use 1 for
non-blocking (Return undef)
 if (ord($char) == 10) { print "[RETURN->]\n"; qx (xdotool key
Return); }
 elsif  (ord($char) == 30) { print "[UP->]\n"; qx (xdotool key
Up); }
 elsif  (ord($char) == 31) { print "[DOWN->]\n"; qx (xdotool
key Down); }
 elsif  (ord($char) == 29) { print "[LEFT->]\n"; qx (xdotool
key Left); }
 elsif  (ord($char) == 28) { print "[RIGHT->]\n"; qx (xdotool
key Right); }
 elsif  (ord($char) == 132) { print "[CTRL-C->]\n"; qx (xdotool
key ctrl+c); } #GRPH + C
 elsif  (ord($char) == 1) { print "[MOUSE LEFT]\n"; qx (xdotool
mousemove_relative --polar  270 10); }
 elsif  (ord($char) == 6) { print "[MOUSE RIGHT]\n"; qx
(xdotool mousemove_relative --polar  270 10); }
 elsif  (ord($char) == 20) { print "[MOUSE UP]\n"; qx (xdotool
mousemove_relative --polar  0 10); }
 elsif  (ord($char) == 2) { print "[MOUSE DOWN]\n"; qx (xdotool
mousemove_relative --polar  180 10); }
 elsif  (ord($char) == 34) { print "[QUOTATION]\n"; qx (xdotool
key 0x0ad3); }
 #CODE+/ for xdotool keyword input for complex key
combinations
 elsif  (ord($char) == 174) { print "INPUT KEYS:"; my $keyin =
;chomp $keyin; qx (xdotool key "$keyin"); }
   else {
  print "$char-> chr\$(", ord($char),")\n";
# Action wtih key presses here:
   qx (xdotool type "$char");
}
}
  return TRUE; #Loop
  });

$main_loop->run;
ReadMode('normal'); # restore normal tty settings
__END__

On Sun, Sep 11, 2022 at 8:08 PM B 9  wrote:

> On Wed, Sep 7, 2022 at 5:43 AM Hiraghm  wrote:
>
>> This is probably a dumb question, maybe even one that was asked/answered
>> long ago, but...
>>
>> would it be possible to use a model 100/102/200 as a keyboard for a
>> Linux workstation via "inputattach"?
>>
>
> Yes, inputattach would work fine, but this seems like a peculiar request
> and has me curious what you are doing. Is this to work with an emulator on
> the Linux workstation?  Do you have a Model 100 with no screen? Are you so
> used to the Model 100 keyboard layout that switching to this new-fangled
> IBM keyboard layout doesn't seem worth it?
>
> Actually, now that I think on it, that last point is not such a bad idea.
> I have a DEC VT-340 serial terminal which uses the LK-201 keyboard that
> inspired IBM's AT keyboard layout. I cannot stand the placement of the CTRL
> key and it doesn't even have a proper Esc key. However, if I had a Model
> 100 I could plug it directly into the VT-340's keyboard port (which I
> believe speaks 600 baud RS-232) and it'd make a dandy keyboard. And, a
> Model 100 would fit better on my desk tha DEC's huge, honkin' keyboard with
> all sorts of wacky "application editing" keys. Now, I just need to find a
> Model 100/102 with a defunct screen!
>
> —b9
>

Re: [M100] TRS-80 Model 100 schematic transcribed to KiCAD

[Brian Brindle]

Fantastic work! Thank you for sharing!

Brian


On Fri, Jul 29, 2022 at 10:12 PM Henner Zeller  wrote:

> Hi,
>
> I recently got a TRS-80 Model 100 and for fixing the the main-board I
> poured over various scans of the original schematic found on
> archive.org; and while it is great that these exist, the original
> schematic is still somewhat hard to read, so I decided to transcribe
> them to a modern schematic format - KiCAD
>
> I put the schema and symbols file as well as a generated PDF on github
> https://github.com/hzeller/trs80-100-schematic
>
> Status: Transcribed the full main-board (not the LCD board). All BOM
> entries (number+value) match with the list found in the documentation,
> all pin-assignments are accurate. Even deduced some values that are
> missing in the schematic (R162, 100Ohm discharging C78 in the reset
> circuit, as well as the designator for the 10n capacitor near the
> primary in the power supply .. C62). Schematic passes electrical rule
> check, so at least there are no obvious mistakes in there.
>
> I tried to keep the original layout as much as possible for easy
> recognition, but did slight changes to improve readability.
> For instance, I added a gap between the 'analog' and 'digital' part so
> that it is possible to print out on two sheets and glue together
> without losing content (or simply folding a large print-out without
> damaging important stuff). Also using IEC resistor symbols for
> readability and changed capacitor units where nanofarad is better
> (3300pF -> 3.3nF; 0.047μF -> 47nF); they didn't seem to use 'Nano'
> back in the day. Renamed some signals to be more useful, so `Ⓐ*` is
> now `RDRW*`. Used color encoding for the different buses on the system
> to easier see what is going on at a glance.
>
> If you find any mistakes (I am sure I missed something), please file
> an issue in the github's issue tracker.
>
> Cheers,
>   Henner.
>

Re: [M100] Rechargeable batteries

[Brian Brindle]

May not be the direction you are looking for, but I use one of those cheap
USB battery banks with a USB to 6v power adapter. They are pretty easy to
make but show up on Ebay pre-made quite often. I can run my M100 and some
peripherals for months without having to re-charge and fall back to the AAs
when I have to.

Brian


On Mon, Jun 20, 2022 at 3:13 PM  wrote:

>
>
>
>
> >>Also, I believe there were previous discussions about replacing the
> memory ni-cad with a super capacitor.
>
>
>
> I have done that on one M100. It works fine but does not last nearly as
> long as a new NiMh battery.
>
>
>
> Jeff Birt
>

[M100] Ron Wiesen

[Brian Brindle]

Hi everyone,

I learned today from an amateur radio contact that WD8PNL, Ronald R. Wiesen
passed away July 23rd, 2021. He was 71.

Ron was noticeably absent from the list recently, especially with the
current topics being right up his alley. He brought us many cool programs
related to Amateur Radio as well as utilities for the M100. He was a US
Marine with combat experience and had dozens of entertaining, crazy stories
to go along with all of that. He ran Little Orphan Annie crypto challenges,
would spin yarns about the simplest of things and was just pain fun.

Ron was an awesome guy, he was already missed but knowing he is gone
forever makes me immeasurably sad.

73 my friend,
WD8PNL, Keeper of the Primordial Bit (mother of all bits), -= Ron Wiesen
=-   (SK)

As of yet, we have received no comment from Bubba.


Brian

Re: [M100] (re)introduction

[Brian Brindle]

Jake!

Wow, very cool to hear from you and catch up. We had theorized about you
and I think someone hit up FB at one point noting that you had discovered
motorcycles, cars and women. For the record I always enjoyed seeing you on
the list. Mostly because I could identify with your situation. Back around
the time the M100 was actively used (1987) I was 12 years old and
discovered BBSes. There weren't many young people on them in those days and
I annoyed the crap of out a lot of people but also made some good friends.
(Tiny bit weirded out that guys my age hung out with 12-13yr old kid now..
But hey, different times.)  Also, I never owned a M100 back then, couldn't
afford it. I bought my first one off eBay when I was about the age you are
now just because it was something I always wanted and never got. Now I
carry it with me almost every day.

Speaking of, check out the list and what you missed over the last 7 years!
It's incredible. I often wish that Rick Hanson was still around because we
have finally realized all of the things he wanted out of his M100, where he
could sit in his truck and punch out work orders, wirelessly transmit them
to his home PC or the cloud. With the proliferation of hobby
microcontrollers and some pretty awesome collaborative development
environments, easy PCB manufacturing and sharing things have really taken
off.

In regards to your keyboard woes, I don't know of any physical difference
in the switches used for the keys from 1983 to 1984. The boards did have
different revisions, but I think they mechanical keys stayed the same. I do
know they are subject to breaking down over time from either lack of use or
from having things stacked on them and being compressed for a while. May
want to look at the switches themselves for why it's mushy. Not much to the
KB and the switches tend to be pretty robust so I'd def take a look at the
traces on the one with the bad keys.

Keep plugging on the job front, you aren't wrong that cars and computers
are the same but the real value comes from having a troubleshooting mind.
That's a rare talent and if you've got one it's easy to find jobs where
people pay you for what you know instead of what you do.

Brian





On Fri, Nov 26, 2021 at 11:01 PM Jake Bickhard 
wrote:

> Hi all.
>
> I think it's been about 7 years since I fell off the face of the earth
> here and after recently digging my M100 out of my basement and giving it
> some R in an attempt to shoehorn it into some aspect of my modern
> workflow I felt a twinge of nostalgia and was amazed at how active this
> community still is.
>
> But some thanks are in order. To Ken and Steve especially, but also to the
> whole group here who put up with my 15 year old socially inept homeschooled
> self making a general ass of myself 10 years ago. Your collective kindness
> and patience (so much patience) is in no small part responsible for my
> current life and career here in Wichita.
>
> I believe I fell off of the vintage computer hobby after my junior year of
> highschool (the first year I'd gone to a public school after being raised
> homeschooled) and my mental health took a nosedive. Graduated by the skin
> of my teeth and floundered through a year of state university before
> dropping out to drift aimlessly for a while working as a car mechanic. Cars
> became my main hobby at that point, and I quickly realized the entire
> industry was a septic tank of horrible people top-to-bottom and quickly got
> out to get back to what I was good at: computer things. Ended up at a small
> datacenter run by one dude with the task of keeping the lights turned on
> while the company could sell off its assets (as many as possible) and cease
> operations. It was a crash course in Linux server admin, IP telephony,
> wireless multipoint networking, and managing multiple buildings entire IT
> infrastructure here in downtown Wichita. Eventually it closed and I've
> worked at a few MSPs here in Wichita honing my people-skills and developing
> my knowledge of Microsoft-based infrastructure, cloud tech, etc. It's been
> fun.
>
> In the interim I moved out, got married, lived barely paycheck-to-paycheck
> in a trap house in the rough part of town, got a small fixer-upper in
> the... less rough part of town? No kids; a few pets. Simple stuff. Kept the
> automotive thing as a hobby and realized that a good mechanic and a good IT
> guy have very similar skillsets, just different occupational hazards. A
> couple years ago I started a vlog-style YouTube channel at the urging of
> some friends given my hilariously poor luck with cars and the potential
> entertainment value. That has since been monetized to an extent that
> allowed my hobby (with an extreme amount of work; two 10-20 minute videos
> per week for the last year and a half) to more or less pay for itself and
> afforded me opportunities I could never do otherwise (there are some 4-6
> other automotive youtubers here in Wichita with substantial followings; I'm
> the 

[M100] VT100 like ESP32 device with a lot of features

[Brian Brindle]

I stumbled on this cool little device last night, hadn't noticed it
mentioned here so I figured I'd share. It's a DIsplay Controller / Emulator
and ANSI/VT Terminal all rolled into one made by FabGL.


https://github.com/fdivitto/FabGL

https://www.youtube.com/watch?v=Ww_pH_ZOLqU

Has a pretty extensively documented API for working with the graphics
library, some cool emulation demos too. Looks relatively easy to build and
although out of stock, the author has some very reasonable prices on his
prefab stuff. ($16-40)

Could be some fun,
Brian

Re: [M100] TPDD Client in pure bash

[Brian Brindle]

This is very cool, love the effort on all of this to not use anything
external but mostly I love the animations.

Thanks!
Brian


On Fri, Aug 20, 2021 at 9:38 PM Brian K. White  wrote:

>
> I've been working on this for a few weeks and I just hit the main
> milestone that not only all the normal file access functions work, but
> the FDC-mode functions work, including, dumping and restoring a whole
> disk works. I just bootstrapped from a restore from a dump of a factory
> tpdd1 utility disk.
>
> https://github.com/bkw777/pdd.sh
>
>
> So, it's now possible to create a TPDD1 Utility Disk from a download,
> with no exotic hardware, just the TPDD1 drive itself and serial
> connection, and the software, aside from this script itself, is just bash.
>
> And the special challenge I set myself because I just knew it was
> possible: It's not only all done just in bash, it's all done right in
> the initial single process. No subshells, let alone external programs
> like awk etc, not even tr/cp/rm etc, not even other instances of bash
> from FOO=$(function... ).
>
> It's all in-memory ops and all in the single initial instance.
>
> Of course every absolute statement has to have exceptions...
> It has to call "stty" once at startup, and it has to run "mkfifo" once
> at startup if the fifo doesn't happen to be still lyng around from a
> previous run. In both cases, the external doesn't constitute much of a
> dependency because they are both so standard. I even addressed a pretty
> wide range of platform differences for the stty command so it should
> work out of the box on all the bsds, osx, as well as linux. And sine
> they are just run once at start up, not many times in the middle of some
> loop or in an aft-used function, they dont constitute an inefficiency
> either.
>
> It was quite a challenge figuring out a way to collect, store,
> manipulate, & reproduce binary data including NUL without resorting to
> an external utility but there turns out to be a way to do it with read()
> and a kind of brute force read-one-byte-at-a-time method where it is
> possible to tell the difference between "the variable is empty because
> there was no data", vs "the variable is empty because read() ate a nul
> byte as a delimiter, by looking at the exit value from read(). That's
> enough to let you store the information where the null byte existed,
> which is all you need. to re-create it later in a file or tty.
>
> Then there is sleep that actually sleeps not a cpu eater poll, without
> /usr/bin/sleep, and generally every bashism in the book.
>
> To be clear, my goal was to leverage bash for all it's worth, not to to
> try for something like compatibility with ancient posix sh. The idea is
> that bash is no longer new and exotic, and actually has a lot of
> powerful tricks available built right in. It's possible to make actually
> performant things in bash if you just do it right. Of course "do it
> right" is pretty context sensitive. In order to satisfy the goal of
> avoiding forks, you have to violate a lot of other good practices like,
> this thing is a sea of global state and side effects. Fine, might as
> well wallow in it then.
>
> And now that that's working well enough that a restore of the tpdd1 util
> disk works, What I really wanted was to see if I could successfully copy
> this Disk Power for KC-85 disk I have. This is a TPDD client for KC-85,
> that I got a working original disk and tape with an ebay purchase , and
> it turns out that it does not include a way to back itself up, and when
> you try to back it up some other way using Floppy on a 100 or PDD210.EXE
> in dosbox etc, the copy looks fine, but the install doesn't work. You
> need both the cassette and the singular irreplaceable original disk to
> install it, which is a situation I refuse to accept. ;)
>
> I *believe* I can now make a copy that's thorough enough thanks to the
> FDC-mode functions, that the copy would work... and *just* when I
> reached this point where I'm finally ready to try it... My KC-85 stops
> working Well it's marginal. Sometimes it comes on and works, but if
> I cold-reset, the screen goes blank and stays that way. "beep" doesn't
> beep.
>
> Here a few pics of the Disk Power disk & tape.
>
> https://photos.app.goo.gl/YvPBJsYnP8N3JffW7
>
> If anyone has a working KC-85 and wants to try it... you can get the
> DiskPower disk dump here
> https://drive.google.com/drive/folders/1HMZNi7S7O4s6Nn7sUcFVwrBVeVIFXSvA
>
> As well as the install file from the cassette. I think the install
> program from the tape isn't as picky as the disk. As long as you get the
> file onto the kc-85 by any method and run it while the drive is
> connected and has the disk inside, I don't think it works. Not there is
> a file with the same name on the disk, but it's a lot smaller and seems
> to just be a stub or something.
>
>
> --
> bkw
>

Re: [M100] dc jack

[Brian Brindle]

I know it's a 5.5x2.1mm size barrel connector that goes in the bulk-head
mount, but finding one that is a drop in replacement for the M100 is going
to be tricky without modification.
I'd probably try something like this -
https://www.digikey.com/en/products/detail/cui-devices/PJ-032A/1644525




On Thu, Aug 5, 2021 at 10:35 AM Gregory McGill 
wrote:

> nobody?
>
>
> On Sun, Jul 11, 2021 at 9:53 PM Gregory McGill 
> wrote:
>
>> I was asked today if I had replacement DC jacks for the M100 is there a
>> part out there I can get from one of the usual suppliers?
>>
>> Greg
>>
>>>

[M100] M100 + Raspberry Pi and VNC

[Brian Brindle]

I've been working on a crazy project to assemble / build utilities for the
Raspberry Pi to maximize the usefulness of it with the M100. I crammed a
TTL-RS232 converter inside a tiny little case. Slapped a button on one of
the GPIO ports to trigger an APC-Shutdown and that's pretty much it. I
tried running the Pi off the M100 using BKWs incredibly awesome
BCR-USB-Power adapter (https://github.com/bkw777/BCR_Breakout) - it works,
but eats the batteries too quickly. So I'm using a tiny little power bank
instead and it works fine. (Even have a nifty little USB to 6V power cable
now that also runs the M100.)

R-Pi gives me storage, wifi and a host of other utilities but it's all
through the tiny little screen. I constantly find myself breaking out my
phone / tablet or laptop to do complicated stuff and it got me wanting to
leverage the M100 keyboard and the full graphic capabilities of the Pi.

I fired up a VNC server on the Pi, it's part of the raspi-config setup now
so super easy to do, and went to work trying to figure out how to pass
keypresses from the Linux CLI to the host. I figured I could use my phone
or tablet as a remote display for the Pi X11 Desktop.

After learning WAY more about barcode readers than expected I settled on a
keyboard wedge method using X11-Test. Lashed together a quick little perl
script to send the keys to the X11 server and amazingly it worked!

I still need to add some inelegance for special characters but I am sending
this e-mail right now, from G-Mail, using my R-Pi as the host and my M100
as the keyboard. The Pi-Zero is horribly underpowered memory wise though,
so it's painfully slow. May be worth using a pi (or other device like my
GPD Micro PC, wouldn't even need VNC for that since it has a screen.) with
more memory..

 Here is a quick video demo for anyone who is confused/curious:
https://youtu.be/GIv831sT50w

Brian

Re: [M100] A decent replacement for M100 "Feet"

[Brian Brindle]

Had a myriad of crazy issues lashing together my test unit for this..
Somehow I ended up with a tape of level converters where the first three
were good all the rest (dozens) are counterfeit..

Anyway, the serial trace is identical to what I posted before, but here is
the behavior I am seeing shown with debug info:

This is debug information captured from the PDDuino attempting to load
DOS100.CO from UR2.

PDDuino with a cold boot, fails to load DOS100.CO. After loading TS-DOS,
listing a directory (OR making any FDC requests) DOS100.CO loads.

First half of the request is identical:

0 - 5A;Z

0 - 5A;Z

0 - 7

0 - 0

0 - F8

T:7|L:0.

command_status()

return_normal()

R:Norm 0

0 - D

0 - 5A;Z

0 - 5A;Z

0 - 0

0 - 1A

0 - 44;D

1 - 4F;O

2 - 53;S

3 - 31;1

4 - 30;0

5 - 30;0

6 - 2E;.

7 - 43;C

8 - 4F;O

9 - 20

A - 20

B - 20

C - 20

D - 20

E - 20

F - 20

10 - 20

11 - 20

12 - 20

13 - 20

14 - 20

15 - 20

16 - 20

17 - 20

18 - 46;F

19 - 0

1A - 88

T:0|L:1A.

command_reference()

SF:0

Ref: DOS100.CO

This is where the difference is. Left is cold boot PDDuino, right is after
a FDC command. Note the directory information, it seems to stay resident
once loaded but is not initialized on cold boot.

directoryAppend()*directoryAppend(DOS100.CO <http://DOS100.CO>)*

directory[/] *directory[//]*

->   ->

directory[/] *directory[//DOS100.CO <http://DOS100.CO>]*

directoryAppend() end*directoryAppend(DOS100.CO <http://DOS100.CO>) end*

return_reference()   return_reference()

returnReference()returnReference()

R:RefR:Ref

upDirectory()upDirectory()

directory[/] *directory[//DOS100.CO <http://DOS100.CO>]*

directory[/] directory[//]

1A - 5A;Z1A - 5A;Z

1A - 5A;Z1A - 5A;Z

1A - 1   1A - 1

1A - 1   1A - 1

0 - 30 - 3

1 - FA   1- FA

T:1|L:1. *T:1|L:1D*

command_open()   command_open()

directoryAppend()*directoryAppend(DOS100.CO <http://DOS100.CO>)*

directory[/] directory[/]

->   ->

directory[/] *directory[//DOS100.C0]*

directoryAppend() end*directoryAppend(DOS100.CO <http://DOS100.CO>) end*

directoryAppend(/)   *upDirectory()*

directory[/] *directory[//DOS100.CO <http://DOS100.CO>]*

->   *directory[//]*

directory[//]*return_normal()*

directoryAppend(/) end   R:Norm 0

R:Norm 0



Now to look at the code and figure out why...


Brian




On Tue, Jul 13, 2021 at 7:36 PM Brian Brindle  wrote:

>
>
> On Tue, Jul 13, 2021 at 6:18 PM Brian White  wrote:
>
>> Dang, TS-DOS is specifically requesting the name "ROOT", which means I
>> have to make PDDuino use that, and you can't have a real directory named
>> ROOT.
>>
>> There is a macro or const you can edit in the main .ino to change that
>> from "SD:   " to "ROOT  ".
>>
>> Probably won't affect UR2 but if it's baked into something like TS-DOS
>> since 35 years ago, then I just have to go along.
>>
>> Then again... TS-DOS is the one thing that actually works pretty well as
>> it is. So then, no I don't ???
>>
>> Anyway thanks for the captures.
>>
>
> I don't think that's the issue, in this case the capture was taken from
> the perspective of the TPDD so RX is what the TPDD is receiving and TX is
> what it is sending, so it sent ROOT - didn't ask for it and in this case it
> was actually correct.. That was the name of the dir. (Sorry,that was
> probably confusing.) Capture was done with a NADs box since it would be
> successful.
>
> What I was seeing during testing was loading DOS100.CO from the UR2
> didn't an FDC Emulation mode command (M1) and the PDDuino didn't seem to
> know how to proceed without having the dmeLabel set. If you run through
> one cycle with TS-DOS where it does check for FDC, everything works after
> that point. So I think there is something broken in the routine to allow
> for a non FDC Emulation request, although I haven't been able to nail it
> down yet and I did majorly screw everything up trying to "improve"
> debugging before..
>
> Lashing together a modular test setup now with the serial port broken out
> for capture. Should make it easier to get a full capture of the issue.
>
> Brian
>
>

Re: [M100] M100 as Terminal to Raspberry Pi

[Brian Brindle]

On Tue, Jul 13, 2021 at 9:08 PM Tom Wilson  wrote:

> Huh. The timing on this is interesting.
>
> I just started writing a line based text editor; my long term plan is to
> run it in Linux, CP/M, and Commodore computers (including the upcoming
> Commander X16.)
>
> If you're interested in trying it on your Pi/Model M setup, I can ping the
> list here when it's ready for an initial test (probably a couple of weeks.)
>
>
Hey Tom, that is some pretty cool timing, I would definitely be interested
in trying it out. Thanks!
Brian

Re: [M100] M100 as Terminal to Raspberry Pi

[Brian Brindle]

HI Bill,

Glad you got it sorted in the end. A re-install would be my first direction
too. Typically ioctl gets upset for specific reasons, one of them being
that the initiation script for the PI didn't complete on it's first run,
another would depend on how the serial console was setup.

I'm going to assume a lot from your email, but it sounds like this was
working at home with the M100 but not at work. The only difference would be
you had WiFI connectivity at home is what I'm gathering, so I'm wondering
if you were also SSHing to the Pi from a PC or other device? That would
activate a controlling console (the SSH session) and allow an incorrectly
privileged or configured  to work. So maybe that was it?

I would highly recommend setting up a USB serial port as a getty rather
than letting the configuration scripts place a console on it. That
configuration is OK with the UARTs present on the PI, but they are there
always, the USB devices are added later in the boot so you can get into a
race condition where it doesn't start right.

I do hope it works for you, I have a blast using my M100 at work. I think
my most favorite time was during some required inservices at work. I knew I
was going to be stuck at a table all day so I wanted to have a good toy to
play with. The M100 is somewhat of a legend where I work, since I am the IT
director. I find that using a 30 year old computer as my daily driver and
being in charge of everyone's technology to really bother people, and I
enjoy that. Added bonus, the required inservice was on "Accepting Change".

Brian


On Tue, Jul 13, 2021 at 9:33 PM Bill Miranda  wrote:

> I started over with a new install of Raspian and that made errors go away
> at home. It will be curious how it works at the office.
>
>
> On Tue, Jul 13, 2021 at 7:12 PM Bill Miranda 
> wrote:
>
>> The errors I am getting are as follows:
>>
>> -bash: cannot set terminal process group (868): Inappropriate ioctl for
>> device
>> -bash: no job control in this shell
>> Then it is not registering all my keystrokes on the Pi connected by the
>> USB serial cable that I got from Retrofloppy.com
>>
>>
>>
>> On Tue, Jul 13, 2021 at 3:48 AM Brian Brindle  wrote:
>>
>>> Hey Bill,
>>>
>>> Weird, what sort of error is it giving you? That absolutely should work
>>> without any issues.. Dumb quesiton, do you have flow control enabled? (Last
>>> character on your STAT should be an E to accomplish this.) Sometimes that
>>> can cause this. Editing the wpa_supplicant file can be a bit of a challenge
>>> from the M100 with a traditional editor.. I do find it easier to
>>> either have my wpa_supplicant file pre-loaded, but there are options..
>>>
>>> When sitting at your local coffee shop, scan for wireless networks. Run: 
>>> *sudo
>>> iwlist wlan0 scan *to list the nearby networks. Do some fancy grep work
>>> or make sure you have your dot-matrix printer at the ready to capture it
>>> all. It's gonna scroll across the screen for the next 10 minutes, so sit
>>> back and enjoy your coffee, enjoy all the new friends you will make with
>>> your dot matrix printer screaming away - or alternatively just look for the
>>> wifi network on your phone.
>>>
>>> To add the config from the M100 and not use an editor:
>>>
>>> sudo wpa_passphrase *SSID-of-WiFi-Here* >>
>>> /etc/wpa_supplicant/wpa_supplicant.conf(Always make backups of the
>>> original files when on the M100! Easier to copy back than to try and edit
>>> with a tiny screen.)
>>>
>>> It should prompt you for the network password. Enter that and it will
>>> append the network to your existing wpa_suplicant.conf file.
>>>
>>> Then issue:
>>> sudo wpa_cli -i wlan0 reconfigure
>>>
>>> This will activate the changes.
>>>
>>> Hope this helps,
>>> Brian
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jul 13, 2021 at 12:38 AM Bill Miranda 
>>> wrote:
>>>
>>>> Brian your response was much appreciated.  I am still having a problem
>>>> with my Pi. I got it working at home but then I took it to the office and
>>>> plugged it in but I thought I would be able to change the wifi from the
>>>> terminal connection. No joy.  I guess I need to change the wpa supplicant
>>>> file at home.  When I got to the office, the M100 can log into the Pi but I
>>>> get a bash error with every command, even something simple like "ls".
>>>>
>>>> On Mon, Jul 12, 

Re: [M100] A decent replacement for M100 "Feet"

[Brian Brindle]

On Tue, Jul 13, 2021 at 6:18 PM Brian White  wrote:

> Dang, TS-DOS is specifically requesting the name "ROOT", which means I
> have to make PDDuino use that, and you can't have a real directory named
> ROOT.
>
> There is a macro or const you can edit in the main .ino to change that
> from "SD:   " to "ROOT  ".
>
> Probably won't affect UR2 but if it's baked into something like TS-DOS
> since 35 years ago, then I just have to go along.
>
> Then again... TS-DOS is the one thing that actually works pretty well as
> it is. So then, no I don't ???
>
> Anyway thanks for the captures.
>

I don't think that's the issue, in this case the capture was taken from the
perspective of the TPDD so RX is what the TPDD is receiving and TX is what
it is sending, so it sent ROOT - didn't ask for it and in this case it was
actually correct.. That was the name of the dir. (Sorry,that was probably
confusing.) Capture was done with a NADs box since it would be successful.

What I was seeing during testing was loading DOS100.CO from the UR2 didn't
an FDC Emulation mode command (M1) and the PDDuino didn't seem to know how
to proceed without having the dmeLabel set. If you run through one cycle
with TS-DOS where it does check for FDC, everything works after that point.
So I think there is something broken in the routine to allow for a non FDC
Emulation request, although I haven't been able to nail it down yet and I
did majorly screw everything up trying to "improve" debugging before..

Lashing together a modular test setup now with the serial port broken out
for capture. Should make it easier to get a full capture of the issue.

Brian

Re: [M100] A decent replacement for M100 "Feet"

[Brian Brindle]

>
> I always had the idea that there could be a whole raft of virtual files
> that don't actually exist but that could be used to issue commands or
> return data like RTC time etc, like /proc /sys etc. They could even be in
> their own virtual sub dir. The dir could even be invisible where it isn't
> listed in  the root directory listing, but never the less works if you
> request the right dir and filenames.
> I like the idea that, at least for some things, you might be able go use
> them by just opening the "file" in TEXT. Or sched or addr for that matter.
> You could have a 2 MB address book for real, but a virtual addr.do that
> only sees a 5k window of it at any given time.
> I don't actually know what all the useful uses might be but it just seems
> obvious to provide the facility simply because you can, and maybe someone
> else comes up with functions that are made possible by using the facility.


 The virtual files would be very useful, if not found in current dir - look
to the magic directory and serve up the file. Would be great for SARDINE
and DOS and I don't think would cost too much memory/program wise. I could
just never get past the whole, do I search the "magic" directory for
specific files defined somewhere or if it doesn't exist I just check for
predefined files? I thought about a config file that would be read on
boot/insertion that would set these hints but with the limited memory I
didn't want that to get too big. Maybe read the file each time?  Maybe just
one directory where you put things and they always show, but then how do
you treat duplicates? Fun stuff to play with.

I really like the /proc file system idea, that's pretty smart to use the
file system to transmit the data. One thing I would also like to see though
is serial communication that does something similar. IE: a serial command
that can pull real time clock info as well as the /proc/. That would give
me the best of both worlds for doing things. I really do miss the CLI
interface the NADs has when using this device.

-Brian

Re: [M100] M100 as Terminal to Raspberry Pi

[Brian Brindle]

Hey Bill,

Weird, what sort of error is it giving you? That absolutely should work
without any issues.. Dumb quesiton, do you have flow control enabled? (Last
character on your STAT should be an E to accomplish this.) Sometimes that
can cause this. Editing the wpa_supplicant file can be a bit of a challenge
from the M100 with a traditional editor.. I do find it easier to
either have my wpa_supplicant file pre-loaded, but there are options..

When sitting at your local coffee shop, scan for wireless networks. Run: *sudo
iwlist wlan0 scan *to list the nearby networks. Do some fancy grep work or
make sure you have your dot-matrix printer at the ready to capture it all.
It's gonna scroll across the screen for the next 10 minutes, so sit back
and enjoy your coffee, enjoy all the new friends you will make with your
dot matrix printer screaming away - or alternatively just look for the wifi
network on your phone.

To add the config from the M100 and not use an editor:

sudo wpa_passphrase *SSID-of-WiFi-Here* >>
/etc/wpa_supplicant/wpa_supplicant.conf(Always make backups of the
original files when on the M100! Easier to copy back than to try and edit
with a tiny screen.)

It should prompt you for the network password. Enter that and it will
append the network to your existing wpa_suplicant.conf file.

Then issue:
sudo wpa_cli -i wlan0 reconfigure

This will activate the changes.

Hope this helps,
Brian










On Tue, Jul 13, 2021 at 12:38 AM Bill Miranda 
wrote:

> Brian your response was much appreciated.  I am still having a problem
> with my Pi. I got it working at home but then I took it to the office and
> plugged it in but I thought I would be able to change the wifi from the
> terminal connection. No joy.  I guess I need to change the wpa supplicant
> file at home.  When I got to the office, the M100 can log into the Pi but I
> get a bash error with every command, even something simple like "ls".
>
> On Mon, Jul 12, 2021 at 9:43 AM Brian Brindle  wrote:
>
>> Hi Bill,
>>
>> I totally missed that you actually had your console working, sorry the
>> systemd changes make me blind with rage.
>>
>> If you are primarily using BBSes X-modem works pretty well, if you have
>> an X-Modem capable term on your M100. You can also send files to/from the
>> M100 via the Linux command line with the sx (send x-modem) command.
>>
>> Brian
>>
>>
>> On Mon, Jul 12, 2021 at 8:15 AM Bill Miranda 
>> wrote:
>>
>>> Thank you so much! Embarrassingly I discovered my problem was that that
>>> I had to go into raspi-config and designate my country so the WiFi would
>>> work.  The packages I was trying to install on my raspberry pi weren’t
>>> installing because no internet.  Once I got that sorted and made a couple
>>> changes to configure I was good to go and successfully contacted a BBS with
>>> the setup.  Now I need to sort out out to exchange files.  Thanks again for
>>> your response.
>>>
>>> Regards,
>>> Bill Miranda
>>> bill.mira...@gmail.com
>>>
>>> On Jul 12, 2021, at 6:18 AM, Brian Brindle  wrote:
>>>
>>> 
>>> HI Bill,
>>>
>>> The divergence from systemd is frustrating but at last current versions
>>> of Raspian still have ifconfig...
>>>
>>> I'm using Raspian 10 here are my quick and dirty hints:
>>>
>>> Get your termcap sorted:
>>> https://zork.net/~octal/mod100.xhtml
>>>
>>> You will note that termcap doesn't exist like it should though, so save
>>> the cap to a file and install it like so:
>>>
>>> tic 
>>>
>>>  I assume you are going to to the easy route and use a USB to serial
>>> adapter. You can use the onboard UART with some level conversion as I have
>>> done, but you have to get creative with the hardware. Check out the photos
>>> of my M100 hooked to my pi zero here:  http://niedobry.com/mod100/tanpi/
>>>
>>> Copy the template file */lib/systemd/system/**serial-getty@.service* to*
>>> /etc/systemd/system/serial-getty@ttyUSB0.service*(Provided you are
>>> using ttyUSB0)
>>>
>>> In [Service] modify the ExecStart line to say the following: (Adjust
>>> your baud as you like.)
>>> ExecStart=-/sbin/agetty -o '-p -- \\u' 19200 %I trs100
>>>
>>> Issue *systemctl enable serial-getty@ttyUSB0.service*
>>>
>>> Do a ps -ax  | grep getty and you should now see a getty process running
>>> on the USB port.
>>>
>>> Connect your Model-T with a null modem cable to the serial port, set
>>> your TERM to STAT 98N1E and you should be good to go. Lots 

Re: [M100] A decent replacement for M100 "Feet"

[Brian Brindle]

>> That is strange. Remember, UR2 works with a real tpdd which has no such
thing as a current directory label, and as well, the whole point of the UR2
stub on-demand loader is that you don't have TS-DOS installed, either ram
or rom.

I'm probably not articulating what I'm trying to say right, it's
sometimes impossible for me to talk without a whiteboard. I'd explain why,
but we'd need a whiteboard.

Here is the behavior I have observed:

TS-DOS seems to always use M1, or at least does when loading a directory
anyway. UR2 does not when asking for DOS100.CO.

(Working Dev)
UR2:
RX: 5A 5A 07 00 F8 0D - ZZ
TX: 12 01 00 EC 0D 0A 3E 20 - >

RX: 5A 5A 00 1A 44 4F 53 31 30 30 2E 43 4F 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 46 00 - ZZ..DOS100.CO  F
TX:  11 1C 44 4F 53 31 30 30 2E 43 4F 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 46 FF FF 9D - DOS100.CO F
RX: 5A 5A 01 01 03 FA - ZZ
TX: 12 01 00 EC
RX: 5A 5A 03 00 FC - 

TS-DOS:
RX: 4D 31 0D 5A 5A 08 00 F7 0D - M1 ZZ
TX: 12 0B 00 52 4F 4F 54 20 20 2E 3C 3E 20 96 - ROOT <>
RX: 0D 4D 31 0D 5A 5A 07 00 F8 - M1 ZZ
TX: 12 01 00 EC
RX: 4D 31 0D 5A 5A 08 00 F7 0D - M1 ZZ
TX: 12 0B 00 52 4F 4F 54 20 20 2E 3C 3E 20 96 - ROOT <>
RX: 0D 4D 31 0D 5A 5A 07 00 F8 - M1 ZZ
TX: 12 01 00 EC
RX: 5A 5A 08 00 F7 - ZZ
TX: 12 0B 00 52 4F 4F 54 20 20 2E 3C 3E 20 96 - ROOT <>
RX: 5A 5A 00 1A 44 4F 53 31 30 30 2E 43 4F 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 46 00 - ZZ DOS100.CO F
TX: 11 1C 44 4F 53 31 30 30 2E 43 4F 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 46 FF FF 9D - DOS100.C0 F

So, in my playing it looks like when you swap back to TS-DOS, load a
directory it runs the PDDuino through the M1 routine, sets the dmeLabel then
when you flip to the UR2, do the load DOS it takes the ZZ DOS100.CO F
without any issue. Do just the ZZ DOS100.CO F without dmeLabel set it just
looks at you.

- Brian



On Mon, Jul 12, 2021 at 11:26 PM Brian White  wrote:

>
>
> bkw
>
> On Mon, Jul 12, 2021, 9:48 PM Brian Brindle  wrote:
>
>>
>>
>> On Mon, Jul 12, 2021 at 5:34 PM Brian K. White 
>> wrote:
>>
>>>
>>>
>>> master actually? or latest default branch which is not master but 0.4.1?
>>> I didn't have master marked as default currently because I thought I had
>>> made it worse, you know like the partly-broken point mid-way in a
>>> refactor, so I made the last-known at least basically-minimally-working
>>> version default.
>>>
>>> But if you're actually using the master branch that's great and I'll
>>> switch that to default. That is where I started porting Jim's main loop.
>>>
>>
>> I'm using the Master. I had a lot of issues with the current default.
>> Granted I didn't improve my situation by mucking with it, but I stumbled on
>> the Master, saw the changes you made and liked them so went with it. It's
>> been working pretty well since.
>>
>> Biggest thing I saw was the PDDuino would wander off looking for
>>
>>> > label information and not respond to drive commands. Like when trying
>>> to
>>> > load TS-DOS from the UR2 it would fail unless you could force the
>>> > PDDuino to get a disk label, IE: swap to TS-DOS rom, list a directory,
>>> > then it would happily go on to the load step. It is somewhat working
>>> now
>>> > so I took a break from it, although my M0 still doesn't work and I'm
>>> not
>>> > 100% sure why but I think it's the guy from SdFats fault..
>>>
>>> I'd love to know the fix for that. I wrote a whole paragraph in the
>>> front page readme about it just as a bug description to be figured out
>>> sometime.
>>>
>>
>> I did a lot of debugging on this, both with a serial monitor and with the
>> debug options on the pdduino. I came to the conclusion that it had
>> something to do with dmeLabel not getting set. When watching the
>> interactions it looked like the UR2 just does a ZZ - ZZ DOS100.CO and
>> that's it. TS-DOS did a little dance that gave it the root dir first and
>> set dmeLabel.
>>
>
>
> That is strange. Remember, UR2 works with a real tpdd which has no such
> thing as a current directory label, and as well, the whole point of the UR2
> stub on-demand loader is that you don't have TS-DOS installed, either ram
> or rom.
>
> Ken Pettit has a TS-DOS disassembly in his directory on club100 that we
> can consult too when it comes to nailing down a real mystery.
>
> Maybe it's something where IF the server says it supports directory
> extensions (by acknowledging one of the commands that should be unknown to
> a real tpdd), THEN the label must actually be supplied at various times,
> and I'm missing some.
>

Re: [M100] A decent replacement for M100 "Feet"

[Brian Brindle]

On Mon, Jul 12, 2021 at 5:34 PM Brian K. White  wrote:

>
>
> master actually? or latest default branch which is not master but 0.4.1?
> I didn't have master marked as default currently because I thought I had
> made it worse, you know like the partly-broken point mid-way in a
> refactor, so I made the last-known at least basically-minimally-working
> version default.
>
> But if you're actually using the master branch that's great and I'll
> switch that to default. That is where I started porting Jim's main loop.
>

I'm using the Master. I had a lot of issues with the current default.
Granted I didn't improve my situation by mucking with it, but I stumbled on
the Master, saw the changes you made and liked them so went with it. It's
been working pretty well since.

Biggest thing I saw was the PDDuino would wander off looking for

> > label information and not respond to drive commands. Like when trying to
> > load TS-DOS from the UR2 it would fail unless you could force the
> > PDDuino to get a disk label, IE: swap to TS-DOS rom, list a directory,
> > then it would happily go on to the load step. It is somewhat working now
> > so I took a break from it, although my M0 still doesn't work and I'm not
> > 100% sure why but I think it's the guy from SdFats fault..
>
> I'd love to know the fix for that. I wrote a whole paragraph in the
> front page readme about it just as a bug description to be figured out
> sometime.
>

I did a lot of debugging on this, both with a serial monitor and with the
debug options on the pdduino. I came to the conclusion that it had
something to do with dmeLabel not getting set. When watching the
interactions it looked like the UR2 just does a ZZ - ZZ DOS100.CO and
that's it. TS-DOS did a little dance that gave it the root dir first and
set dmeLabel. I mucked with this quite a bit but stupidly went down the
route of trying to make DOS100.CO found no matter what the current
directory was but regretted that after I started thinking it was
short-sighted for other things not DOS100.CO. I'll have some more time here
soon to keep playing.


>
> So far, actually the lowly 32u4 feather board is actually my favorite.
> The teensy's have gobs more power obviously, but for this task the 32u4
> does the job so the extra power doesn't matter until we start adding
> features beyond straight tpdd. Either feather is better than the teensy
> (until you start needing the horsepower) for the sake of:
> * asymmetrical pin headers for polarity enforcement,
> * built-in lipo manager
> * card detect switch,
> * ...which an interrupt can be assigned to
> * extra on-board led for the card slot
>
> I'm with you on the 32u4's now. Very impressed with what they have and can
> do. I hadn't really touched them much before. The form factor of all of
> this is my favorite, the feather mount boards totally make it all work.
> Great job on those.


Brian

Re: [M100] M100 as Terminal to Raspberry Pi

[Brian Brindle]

Hi Bill,

I totally missed that you actually had your console working, sorry the
systemd changes make me blind with rage.

If you are primarily using BBSes X-modem works pretty well, if you have an
X-Modem capable term on your M100. You can also send files to/from the M100
via the Linux command line with the sx (send x-modem) command.

Brian


On Mon, Jul 12, 2021 at 8:15 AM Bill Miranda  wrote:

> Thank you so much! Embarrassingly I discovered my problem was that that I
> had to go into raspi-config and designate my country so the WiFi would
> work.  The packages I was trying to install on my raspberry pi weren’t
> installing because no internet.  Once I got that sorted and made a couple
> changes to configure I was good to go and successfully contacted a BBS with
> the setup.  Now I need to sort out out to exchange files.  Thanks again for
> your response.
>
> Regards,
> Bill Miranda
> bill.mira...@gmail.com
>
> On Jul 12, 2021, at 6:18 AM, Brian Brindle  wrote:
>
> 
> HI Bill,
>
> The divergence from systemd is frustrating but at last current versions of
> Raspian still have ifconfig...
>
> I'm using Raspian 10 here are my quick and dirty hints:
>
> Get your termcap sorted:
> https://zork.net/~octal/mod100.xhtml
>
> You will note that termcap doesn't exist like it should though, so save
> the cap to a file and install it like so:
>
> tic 
>
>  I assume you are going to to the easy route and use a USB to serial
> adapter. You can use the onboard UART with some level conversion as I have
> done, but you have to get creative with the hardware. Check out the photos
> of my M100 hooked to my pi zero here:  http://niedobry.com/mod100/tanpi/
>
> Copy the template file */lib/systemd/system/**serial-getty@.service* to*
> /etc/systemd/system/serial-getty@ttyUSB0.service*(Provided you are
> using ttyUSB0)
>
> In [Service] modify the ExecStart line to say the following: (Adjust your
> baud as you like.)
> ExecStart=-/sbin/agetty -o '-p -- \\u' 19200 %I trs100
>
> Issue *systemctl enable serial-getty@ttyUSB0.service*
>
> Do a ps -ax  | grep getty and you should now see a getty process running
> on the USB port.
>
> Connect your Model-T with a null modem cable to the serial port, set your
> TERM to STAT 98N1E and you should be good to go. Lots and lots of
> customization needed for it to be useful, I'm working on getting my notes
> together on this and hope to have it somewhere for reference soon.
>
> Hope this helps,
> Brian
>
>
> On Sun, Jul 11, 2021 at 11:09 PM Bill Miranda 
> wrote:
>
>> Can anyone point me to current instructions on how to configure a
>> Raspberry Pi so that I can connect my M100 as a serial console? I found
>> numerous websites with instructions for older versions of Raspian which
>> were pre-systemd.  I was able to get the M100 to connect to the Pi after a
>> lot of experimenting but I once I login I can’t get anything to work.
>>
>> Regards,
>> Bill Miranda
>> bill.mira...@gmail.com
>>
>

Re: [M100] A decent replacement for M100 "Feet"

[Brian Brindle]

I agree on the risk with the USB ports, you wouldn't typically design
something like this. But I appreciate the out of the box thinking that got
me past that. The current limiting etc can easily be done in the end
device, and that's what I choose to do. In reality, only one person is
likely ever going to use this thing and we are already plugging USB ports
into DB9s so.. Brian did at least consider the M100 user group and
instructed everyone to use plastic DB9s so I think that is sufficient.

Jim - congrats on the new gig. Hope you find some time to play soon. I used
both your code and Brian W's to get my PDDuino going. Found the re-org of
the code very helpful in figuring things out and appreciated all the
documentation. I was chasing a few bugs that it looks like you guys both
sorted out, or moved, in the latest master branch. Biggest thing I saw was
the PDDuino would wander off looking for label information and not respond
to drive commands. Like when trying to load TS-DOS from the UR2 it would
fail unless you could force the PDDuino to get a disk label, IE: swap to
TS-DOS rom, list a directory, then it would happily go on to the load step.
It is somewhat working now so I took a break from it, although my M0 still
doesn't work and I'm not 100% sure why but I think it's the guy from SdFats
fault..

Brian




On Mon, Jul 12, 2021 at 4:04 AM Scott McDonnell 
wrote:

> “That IS a bit risky. Ideally there should be some sort of current limit
> to avoid drawing more than 50 or 60 ma. But I don't know how to do that in
> a small practical way.”
>
>
>
> Wouldn’t a 82 (or 100 for 50ma) ohm resistor in series do the trick?
>
>
>
> Scott M.
>
>
>
> *From: *Brian White 
> *Sent: *Sunday, July 11, 2021 2:33 PM
> *To: *m...@bitchin100.com
> *Subject: *Re: [M100] A decent replacement for M100 "Feet"
>
>
>
>
>
>
>
> On Sun, Jul 11, 2021, 8:14 AM Brian Brindle  wrote:
>
> > I didn't think anyone else was actually trying them out.
>
>
>
> BKW - I just assumed the MountT was wildly popular based on how simple and
> awesome it was. I'm genuinely jealous that I didn't think of it.. I'll be
> honest, there is something in my training/experience that was like DO NOT
> HOOK THINGS UP WITHOUT BUFFERING/PROTECTION/ETC!
>
>
>
> You are not wrong of course. But little diy toys like this have to be
> compromises to make them doable.
>
>
>
>
>
> Then you go and pop a USB jack on the BC port and the world didn't end and
> it's worked great.
>
>
>
>
>
> That IS a bit risky. Ideally there should be some sort of current limit to
> avoid drawing more than 50 or 60 ma. But I don't know how to do that in a
> small practical way.
>
>
>
> At least I made sure the BOM has a plastic plug and stressed in the docs
> why this is important even though that plug is uncommon and expensive while
> normal metal shell plugs are dirt cheap.
>
>
>
> (the metal shell of normal de9f shorts the power and ground pins, you
> should never use a metal shell de9f in the bcr port)
>
>
>
>
>
>
>
>
>
>
>
> I'm a daily carrier of my Model-T, I write a lot but 90% of what I do with
> it is useless tinkering to make it do stuff similar to what my phone and
> readily available laptop can do. In fact, in most instances my laptop is
> hooked up and running to debug the thing that isn't working right on the
> M100. That being said, the PDDuino provided weeks of endless debugging
> entertainment.
>
>
>
> Yes that does still need a lot of debugging sorry ;)
>
>
>
> Jim Brain did some work on it and the idea didn't work out, but there is a
> lot he did that are good ideas that I'd been meaning to cherry pick.
> Actually I already did some of that.
>
>
>
> It's still not quite all the way there yet. It still doesn't work with
> other clients like WP-2. I think it's still limited to TS-DOS.
>
>
>
> My problem last time I was working on it was I think enabling debugging is
> screwing it up. Things work without debugging, and break with debugging,
> well great now what? haha
>
>
>
>
>
> I checked out your latest code for it recently with the new main loop and
> it works very well now and is my "daily-driver" for storage.
>
>
>
> I very much respect all of you guys who can not only do this stuff but
> document it where others can play along. I seem to fail miserably at that.
> I do have a current project in the works that I hope to change that with..
> We will see.
>
>
>
> After 20+ years of using M100s I stumbled on an M102 cheap and snatched it
> up. I worked at Radio Shack back in the 90s as a teen and remember lusting
> after the discontinued M102 but hadn't touched one since th

Re: [M100] M100 as Terminal to Raspberry Pi

[Brian Brindle]

HI Bill,

The divergence from systemd is frustrating but at last current versions of
Raspian still have ifconfig...

I'm using Raspian 10 here are my quick and dirty hints:

Get your termcap sorted:
https://zork.net/~octal/mod100.xhtml

You will note that termcap doesn't exist like it should though, so save the
cap to a file and install it like so:

tic 

 I assume you are going to to the easy route and use a USB to serial
adapter. You can use the onboard UART with some level conversion as I have
done, but you have to get creative with the hardware. Check out the photos
of my M100 hooked to my pi zero here:  http://niedobry.com/mod100/tanpi/

Copy the template file */lib/systemd/system/**serial-getty@.service* to*
/etc/systemd/system/serial-getty@ttyUSB0.service*(Provided you are
using ttyUSB0)

In [Service] modify the ExecStart line to say the following: (Adjust your
baud as you like.)
ExecStart=-/sbin/agetty -o '-p -- \\u' 19200 %I trs100

Issue *systemctl enable serial-getty@ttyUSB0.service*

Do a ps -ax  | grep getty and you should now see a getty process running on
the USB port.

Connect your Model-T with a null modem cable to the serial port, set your
TERM to STAT 98N1E and you should be good to go. Lots and lots of
customization needed for it to be useful, I'm working on getting my notes
together on this and hope to have it somewhere for reference soon.

Hope this helps,
Brian


On Sun, Jul 11, 2021 at 11:09 PM Bill Miranda 
wrote:

> Can anyone point me to current instructions on how to configure a
> Raspberry Pi so that I can connect my M100 as a serial console? I found
> numerous websites with instructions for older versions of Raspian which
> were pre-systemd.  I was able to get the M100 to connect to the Pi after a
> lot of experimenting but I once I login I can’t get anything to work.
>
> Regards,
> Bill Miranda
> bill.mira...@gmail.com
>

Re: [M100] A decent replacement for M100 "Feet"

[Brian Brindle]

> I didn't think anyone else was actually trying them out.

BKW - I just assumed the MountT was wildly popular based on how simple and
awesome it was. I'm genuinely jealous that I didn't think of it.. I'll be
honest, there is something in my training/experience that was like DO NOT
HOOK THINGS UP WITHOUT BUFFERING/PROTECTION/ETC! Then you go and pop a USB
jack on the BC port and the world didn't end and it's worked great.

I'm a daily carrier of my Model-T, I write a lot but 90% of what I do with
it is useless tinkering to make it do stuff similar to what my phone and
readily available laptop can do. In fact, in most instances my laptop is
hooked up and running to debug the thing that isn't working right on the
M100. That being said, the PDDuino provided weeks of endless debugging
entertainment. I checked out your latest code for it recently with the new
main loop and it works very well now and is my "daily-driver" for storage.

I very much respect all of you guys who can not only do this stuff but
document it where others can play along. I seem to fail miserably at that.
I do have a current project in the works that I hope to change that with..
We will see.

After 20+ years of using M100s I stumbled on an M102 cheap and snatched it
up. I worked at Radio Shack back in the 90s as a teen and remember lusting
after the discontinued M102 but hadn't touched one since then. I much
prefer the size/weight and keyboard to my M100. I also like the system bus
being accessible like it is so built a little jig for my project. I
followed your example and added a USB port to it to power my PDDuino, once
I get a real board made for it I'll get the right length USB cord and it
will look as awesome as the M100 does with the MountT, but here it is:

http://niedobry.com/mod100/images/bus_jig.jpg

Brian



On Sat, Jul 10, 2021 at 4:08 AM Brian K. White  wrote:

> On 7/9/21 4:21 PM, Peter Vollan wrote:
> > You'll have to explain what that is past the printer and serial ports.
> https://github.com/bkw777/MounT
> https://github.com/bkw777/BCR_Breakout
> https://github.com/bkw777/PDDuino
>
> I didn't think anyone else was actually trying them out.
>
> --
> bkw
>
>
> > On Fri, 9 Jul 2021 at 13:01, Brian Brindle  > <mailto:bbrin...@gmail.com>> wrote:
> >
> > I found this thing called a "Laptop Foot" at the checkout of my
> > local Barnes and Noble the other day. I am slightly embarrassed to
> > admit that I paid $12 for it but also I've been very happy with how
> > it works so...
> >
> > It's just the one wedge, you pop it under the back of the M100 and
> > it just sort of tripods. It's very stable, no rocking or anything
> > and has it at a decent angle for me. I find it easier to keep up
> > with and quicker to deploy than my plastic feet.
> >
> > Quick Amazon search for "Laptop Foot" or Universal Laptop/Notebook
> > stands will reveal 4-packs available from $10-$13 but totally lacks
> > the instant gratification I received for 4x the price, not to
> > mention the blank look from my SO as I ran from the checkout to the
> > Starbucks inside, ripped my rubberized wedge from its box and
> > plopped my M102 on it happily exclaiming "Hu?! HU?!! Awesome right?!"
> >
> > She didn't respond, likely because it was too awesome for her to
> > handle. Anyway, I thought you guys would appreciate it.
> >
> > Behold - the M100 foot!
> >
> > http://niedobry.com/mod100/images/ <
> http://niedobry.com/mod100/images/>
> >
> >
> > Brian
> >
>
>
> --
> bkw
>

Re: [M100] A decent replacement for M100 "Feet"

[Brian Brindle]

Haha, no - not Jim Brian but I appreciate the association.  That's a MountT
on the BC port for power and a PDDuino TPDD Emulator on the RS232 port,
built from the info on the git repository.

I've been having a blast playing with the PDDuino over the last few months.
Learned more about the TPDD protocol than I ever expected and I might just
yell at Bill Greiman of SdFat if I ever meet him. Incredibly useful and fun
device. I just recently got a M102 so haven't gotten around to flipping the
USB port on the MountT so it points the right way yet. I've also been
stealing power off the System Bus port instead since it's closer but forgot
my cable today. The setup with the right length USB cord looks wicked cool
on an M100. Very awesome work BKW, thank you!

Brian


On Fri, Jul 9, 2021, 9:08 PM Brian K. White  wrote:

> I do like how simple that is, and I have been annoyed that my plastic
> legs are never exactly the right length and the unit always rocks a
> little until I spend a minute adjusting. And one loose part is better
> than 2 loose parts.
>
> I like it.
>
> And I recognize them add-ons ;)
>
> Did you build them or get them from Jim Brain or are you Jim Brain ?
> Because I don't remember giving any to anyone else but they look neat
> and properly built from what I can see.
>
> --
> bkw
>
>
> On 7/9/21 4:00 PM, Brian Brindle wrote:
> > I found this thing called a "Laptop Foot" at the checkout of my local
> > Barnes and Noble the other day. I am slightly embarrassed to admit that
> > I paid $12 for it but also I've been very happy with how it works so...
> >
> > It's just the one wedge, you pop it under the back of the M100 and it
> > just sort of tripods. It's very stable, no rocking or anything and has
> > it at a decent angle for me. I find it easier to keep up with and
> > quicker to deploy than my plastic feet.
> >
> > Quick Amazon search for "Laptop Foot" or Universal Laptop/Notebook
> > stands will reveal 4-packs available from $10-$13 but totally lacks the
> > instant gratification I received for 4x the price, not to mention the
> > blank look from my SO as I ran from the checkout to the Starbucks
> > inside, ripped my rubberized wedge from its box and plopped my M102 on
> > it happily exclaiming "Hu?! HU?!! Awesome right?!"
> >
> > She didn't respond, likely because it was too awesome for her to handle.
> > Anyway, I thought you guys would appreciate it.
> >
> > Behold - the M100 foot!
> >
> > http://niedobry.com/mod100/images/ <http://niedobry.com/mod100/images/>
> >
> >
> > Brian
> >
>
>

[M100] A decent replacement for M100 "Feet"

[Brian Brindle]

I found this thing called a "Laptop Foot" at the checkout of my local
Barnes and Noble the other day. I am slightly embarrassed to admit that I
paid $12 for it but also I've been very happy with how it works so...

It's just the one wedge, you pop it under the back of the M100 and it just
sort of tripods. It's very stable, no rocking or anything and has it at a
decent angle for me. I find it easier to keep up with and quicker to deploy
than my plastic feet.

Quick Amazon search for "Laptop Foot" or Universal Laptop/Notebook stands
will reveal 4-packs available from $10-$13 but totally lacks the instant
gratification I received for 4x the price, not to mention the blank look
from my SO as I ran from the checkout to the Starbucks inside, ripped my
rubberized wedge from its box and plopped my M102 on it happily
exclaiming "Hu?! HU?!! Awesome right?!"

She didn't respond, likely because it was too awesome for her to handle.
Anyway, I thought you guys would appreciate it.

Behold - the M100 foot!

http://niedobry.com/mod100/images/


Brian

Re: [M100] REX question

[Brian Brindle]

Hi Bill,

Yes, you can use the same REX in a model 100 or 102.

If they are mod100/102's have the same amount of memory you will have no
issues with stored RAM Images, but if they are different you will get a
memory size mismatch when attempting to load them. Easy to fix using the
file browse feature and creating a new Image though.

Brian


On Thu, Jul 8, 2021 at 2:55 PM Bill Miranda  wrote:

> Is REX module interchangeable between model 100 and model 102?
>
> Thanks!
>
> Bill
>

Re: [M100] calling Ron Weisen

[Brian Brindle]

He has been notably missing for a couple of years. I was curious about his
whereabouts myself..

Brian


On Fri, Oct 9, 2020 at 2:02 PM Stephen Adolph  wrote:

> Hey folks,
> Has anyone heard from Ron lately?
> Is he on the list still?
>
> I disassembled Teeny to fix it to work on Z80 and I'm mostly done, but it
> would be nice to let Ron know what I am up to.
>
> thanks
> Steve
>

Re: [M100] CP/M install issue

[Brian Brindle]

Oh for crying out loud...  Put a 0 and a comma in front of what you are
typing and ignore my error laden attempt to type this on a mobile device...

CLEAR 0,6



On Fri, Jul 24, 2020 at 8:06 PM Brian Brindle  wrote:

> Correction, CLEAR 0,6000 - fingers slipped.
>
> On Fri, Jul 24, 2020 at 8:06 PM Brian Brindle  wrote:
>
>> Try CLEAR 0,2
>>
>> Brian
>>
>>
>> On Fri, Jul 24, 2020 at 7:45 PM Tom Hoppe  wrote:
>>
>>> I just received my REXCPM module last Wednesday and got it installed. I
>>> was able to get it working with the REX functionality and that works great,
>>> but I'm having an issue when trying to run the CLEAR command before running
>>> CPMUPD.CO to install CP/M. Even if I start from a clean state with
>>> nothing in RAM (29638 Bytes free) when I run CLEAR I get the following
>>> error:
>>>
>>> CLEAR 6
>>> ?OV Error
>>> Ok
>>>
>>> I'm trying to determine where to go from here. Thanks.
>>>
>>> Tom Hoppe
>>>
>>>

Re: [M100] CP/M install issue

[Brian Brindle]

Correction, CLEAR 0,6000 - fingers slipped.

On Fri, Jul 24, 2020 at 8:06 PM Brian Brindle  wrote:

> Try CLEAR 0,2
>
> Brian
>
>
> On Fri, Jul 24, 2020 at 7:45 PM Tom Hoppe  wrote:
>
>> I just received my REXCPM module last Wednesday and got it installed. I
>> was able to get it working with the REX functionality and that works great,
>> but I'm having an issue when trying to run the CLEAR command before running
>> CPMUPD.CO to install CP/M. Even if I start from a clean state with
>> nothing in RAM (29638 Bytes free) when I run CLEAR I get the following
>> error:
>>
>> CLEAR 6
>> ?OV Error
>> Ok
>>
>> I'm trying to determine where to go from here. Thanks.
>>
>> Tom Hoppe
>>
>>

Re: [M100] CP/M install issue

[Brian Brindle]

Try CLEAR 0,2

Brian


On Fri, Jul 24, 2020 at 7:45 PM Tom Hoppe  wrote:

> I just received my REXCPM module last Wednesday and got it installed. I
> was able to get it working with the REX functionality and that works great,
> but I'm having an issue when trying to run the CLEAR command before running
> CPMUPD.CO to install CP/M. Even if I start from a clean state with
> nothing in RAM (29638 Bytes free) when I run CLEAR I get the following
> error:
>
> CLEAR 6
> ?OV Error
> Ok
>
> I'm trying to determine where to go from here. Thanks.
>
> Tom Hoppe
>
>

Re: [M100] REXCPM working!

[Brian Brindle]

Very impressive! Sounds ridiculous but hunting down an LBR extractor and
dealing with all the old school archive formats has really put me in a
state of nostalgia. Funny thing, when I was younger I used to think self
dissolving archives (SDA) were the most awesome thing on the planet and why
would anyone use anything else? 30+ years later... Oh.. I get it.

lbrate from here works well under linux if anyone is looking:
http://www.svgalib.org/rus/lbrate.html

This is fun!
Brian



On Fri, Jul 24, 2020 at 7:24 AM Stephen Adolph  wrote:

> Awesome.  CP/M action!
>
> On Friday, July 24, 2020, Ron Klein  wrote:
>
>> Got my REXCPM installed and running. It's impressive.  Thanks Steve, Phil
>> and others for making this happen.  Of course, not all SW works well with a
>> 40X 8 screen, but some is configurable.  Any CP/M program that can be
>> configured for a VT52  or Heath-Zenith  H19 terminal has a head start at
>> working. I plan to post some M100 configured CP/M SW in the Club 100 user
>> library when I can.  Starting to remember the DDT commands. Uh oh
>>
>> Ron Klein
>>
>

Re: [M100] Husky (and Hunter)

[Brian Brindle]

I had one for a few years. Primarily used it as a portable terminal. The
charging circuit failed in it disastrously though absolutely destroying
most of it while it charged on the bench one night. I have not spent the
time to fix it. My TRS-80 is 30 years old now though and working just fine.

Brian


On Thu, Jul 23, 2020 at 9:13 AM Erik van der Tier  wrote:

> I saw this on a recent episode of The 8Bit guy:
> https://www.old-computers.com/museum/computer.asp?c=285=1
> I had never heard of these, its predecessor is from 1981 and these have
> pretty similar specs as the M100/T102 in addition to being near
> indestructable. Has anybody here every had one (or still)?
> It clearly loses from the M100/T102 on the keyboard front though...
>
> Cheers,
>Erik
>

Re: [M100] tranch #2 of REXCPM is off the docks!

[Brian Brindle]

Just checked the mail ten minutes ago and found mine in the box! Have to
say, very impressed with the quality of everything. Even enjoyed the extra
effort and details in the initialization software. Fantastic work!

Thanks for everything Steve!
Brian


On Thu, Jul 16, 2020, 2:17 PM John R. Hogerhuis  wrote:

>
>
> On Thu, Jul 16, 2020 at 7:36 AM Stephen Adolph 
> wrote:
>
>> John, what flavor?  T102 or M100?
>> cheers
>>
>>>

> M100 please
>
> -- John.
>

Re: [M100] mem test

[Brian Brindle]

Some simple ones in the club 100 library that have always worked well for
me:
http://club100.org/library/libutl.html

I have used RAMCHK.BA  with good results identifying bad ram.

Brian


On Tue, Jul 21, 2020 at 12:12 AM Gregory McGill 
wrote:

> is there a good memory test program for the m100? I just built one of
> these throughhole ram boards and want to test it..
>
> Greg
>

Re: [M100] NADSBox status

[Brian Brindle]

Hey Ken,

Man, that's a ton of bad luck right there. Take care of yourself and I wish
you a speedy recovery!

Brian

On Fri, Oct 5, 2018, 9:18 PM Ken Pettit  wrote:

> Hey Gang,
>
> I had reported a couple of weeks ago that I had maybe a dozen NADSBoxes
> that I would be able to sell fairly soon.  Just wanted to updated
> everyone that the effort has kinda been put on old for a bit because I
> was in the hospital the past week and a half.
>
> I went in last Monday because I felt I needed more stents, which I did.
> They ended up putting in 2 more stents ... I think I'm up to 20 now.
> Normally this would be a 2-3 day visit to the hospital and then back to
> work the following week.  But this time because of the amount of
> blockage in the main artery, they needed to put me on a breathing
> machine and sedate me fully (in an expeditious manner since they only
> discovered this during the proceedure).
>
> While placing the breathing tube, they lacerated the right side of my
> tongue REALLY BADLY, then I spent the next 7 days in the ICU.  I just
> got home on Wednesday evening and am still recovering with a swollen
> tongue and neck (secondary brusing from all the bleeding).
>
> I still plan to work on these over the next few weeks, but it will have
> to be at a slower rate than I was originally thinking.
>
> Ken
>

Re: [M100] REX 4.9 Revision 236 bug

[Brian Brindle]

Yes, I do see a progress bar in the bottom right when it happens.

I know it's a buggy revision but I'm just having fun playing with it. Other
than this oddity I've had great success with it.

Thanks,
Brian

On Nov 11, 2017 2:16 PM, "Stephen Adolph" <twospru...@gmail.com> wrote:

> Ok.
> thanks for the report.
> When REX writes to flash you always get the progress bar.
> Do you see the progress bar when you suspect rex is writing the RAM to the
> backup image?
>
>
>
> On Sat, Nov 11, 2017 at 1:10 PM, Brian Brindle <bbrin...@gmail.com> wrote:
>
>> Thanks for the reply Stephen,
>>
>> Short version is if you follow the steps above REX will overwrite a RAM
>> image before prompting you to ask if it's ok and when you first launch
>> REXMGR before you've selected any options.
>>
>>
>>
>> On Nov 11, 2017 11:36 AM, "Stephen Adolph" <twospru...@gmail.com> wrote:
>>
>>> Brian can you more clearly lay  out the issue?
>>>
>>>
>>>
>>> On Sat, Nov 11, 2017 at 10:13 AM, Brian Brindle <bbrin...@gmail.com>
>>> wrote:
>>>
>>>> Found an interesting little condition today utilizing the Quick Menu
>>>> Features with REX to backup RAM. If you do things in this order REX will
>>>> write over the current RAM image before asking permission. I doubt this
>>>> would cause any major issues for anyone but it's interesting none the less.
>>>>
>>>> Select a RAM image, let's call this RAM-A. Do a total wipe / reset of
>>>> the M100 then reload REXMGR but this time select a different RAM image so
>>>> say RAM-B.
>>>>
>>>> If you at any time hit CTRL-B to backup RAM the image will be written
>>>> immediately then you will be prompted for confirmation. If you say no - too
>>>> bad, it already happened.
>>>>
>>>> So I tested a few more times just loading REXMGR and noted that the
>>>> progress bar did it's thing in the right corner of the screen when loading
>>>> REXMGR. So started over, switched to a different RAM image again and
>>>> created a file. Verified that indeed just going into REXMGR was causing a
>>>> write to the RAM image without selecting it or requesting a backup.
>>>>
>>>> Seems to be somehow related to REX remembering the last image you were
>>>> in? The one with the asterisk? If I do a refresh of the one with the
>>>> asterisk everything works as it should.
>>>>
>>>> Just figured I'd throw that out there in case it wasn't known.
>>>>
>>>>
>>>> Thanks,
>>>> Brian
>>>>
>>>>
>>>
>

Re: [M100] REX 4.9 Revision 236 bug

[Brian Brindle]

Thanks for the reply Stephen,

Short version is if you follow the steps above REX will overwrite a RAM
image before prompting you to ask if it's ok and when you first launch
REXMGR before you've selected any options.



On Nov 11, 2017 11:36 AM, "Stephen Adolph" <twospru...@gmail.com> wrote:

> Brian can you more clearly lay  out the issue?
>
>
>
> On Sat, Nov 11, 2017 at 10:13 AM, Brian Brindle <bbrin...@gmail.com>
> wrote:
>
>> Found an interesting little condition today utilizing the Quick Menu
>> Features with REX to backup RAM. If you do things in this order REX will
>> write over the current RAM image before asking permission. I doubt this
>> would cause any major issues for anyone but it's interesting none the less.
>>
>> Select a RAM image, let's call this RAM-A. Do a total wipe / reset of the
>> M100 then reload REXMGR but this time select a different RAM image so say
>> RAM-B.
>>
>> If you at any time hit CTRL-B to backup RAM the image will be written
>> immediately then you will be prompted for confirmation. If you say no - too
>> bad, it already happened.
>>
>> So I tested a few more times just loading REXMGR and noted that the
>> progress bar did it's thing in the right corner of the screen when loading
>> REXMGR. So started over, switched to a different RAM image again and
>> created a file. Verified that indeed just going into REXMGR was causing a
>> write to the RAM image without selecting it or requesting a backup.
>>
>> Seems to be somehow related to REX remembering the last image you were
>> in? The one with the asterisk? If I do a refresh of the one with the
>> asterisk everything works as it should.
>>
>> Just figured I'd throw that out there in case it wasn't known.
>>
>>
>> Thanks,
>> Brian
>>
>>
>

[M100] REX 4.9 Revision 236 bug

[Brian Brindle]

Found an interesting little condition today utilizing the Quick Menu
Features with REX to backup RAM. If you do things in this order REX will
write over the current RAM image before asking permission. I doubt this
would cause any major issues for anyone but it's interesting none the less.

Select a RAM image, let's call this RAM-A. Do a total wipe / reset of the
M100 then reload REXMGR but this time select a different RAM image so say
RAM-B.

If you at any time hit CTRL-B to backup RAM the image will be written
immediately then you will be prompted for confirmation. If you say no - too
bad, it already happened.

So I tested a few more times just loading REXMGR and noted that the
progress bar did it's thing in the right corner of the screen when loading
REXMGR. So started over, switched to a different RAM image again and
created a file. Verified that indeed just going into REXMGR was causing a
write to the RAM image without selecting it or requesting a backup.

Seems to be somehow related to REX remembering the last image you were in?
The one with the asterisk? If I do a refresh of the one with the asterisk
everything works as it should.

Just figured I'd throw that out there in case it wasn't known.


Thanks,
Brian

Re: [M100] Any writers still using an M100?

[Brian Brindle]

I had the opportunity to work with Mr. Martin last November. I showed him
my M100 setup. He was not impressed.

On Nov 5, 2017 8:43 AM, "Bill Loguidice"  wrote:

> I don't think anyone could or would dispute that people still use their
> M100 series systems, or ANY vintage computer or game system for that
> matter. Everything has its fans. I think the core question is if any
> professional writers use it as part of their workflow. I know I would never
> trust vintage tech when writing all the things that I write. I'm too
> spoiled by the automatic redundancy/safety and features made possible with
> modern machines. At the same time, I'd be OK with using it for casual
> writing, the type that something like the Freewrite is used for today,
> i.e., the type where you just write and then worry about doing edits on
> something else (fiction, really). With that kind of writing, losing your
> work would not be quite as devastating and the special form factor might
> also help minimize distractions/help you get into a specific mindset.
>
> Of course, even though I would never use vintage tech like the M100 series
> in my professional writing for a variety of reasons, it doesn't mean
> someone doesn't. Certainly there are famous examples of writers like George
> R.R. Martin who uses WordStar 4.0 on a DOS era setup. So the question then
> becomes, can we point to any examples of someone using an M100 series
> computer today in a genuinely professional capacity? If so, I would suspect
> it would be mostly of the Freewrite variety, where it's used in the
> preparation of fiction, rather than non-fiction material.
>
> -Bill
>
> 
> Bill Loguidice | About me and other ways to get in touch
> 
> 
>
> On Sat, Nov 4, 2017 at 7:01 PM, Mike Stein  wrote:
>
>> - Original Message -
>> From: Mitch Parker
>> To: m...@bitchin100.com
>> Sent: Thursday, November 02, 2017 8:52 PM
>> Subject: Re: [M100] Any writers still using an M100?
>>
>>
>> > 2.  If there is anyone that can credibly make that statement, it would
>> be him.
>> --
>> I think the people on this list who actually own and use one of the M100
>> class  of computers are much better qualified to comment.
>> --
>>
>> Doesn't change that the m100 does a lot and there may be a few people
>> still using theirs.
>> --
>> "may be"?!? If you follow this list at all then you'd know that there *are
>> *indeed quite a few people using theirs and prepared to invest time
>> and/or money to make them even more useful while retaining the features
>> that make them unique.
>>
>> From my reply to Evan:
>> "How many modern computers have a full size regular keyboard in a tablet
>> format with a display that's clearly legible in bright sunlight, instant
>> on, cheap batteries that last for days and can be replaced in seconds, etc.
>> ?"
>>
>> m
>>
>> >Mitch
>>
>

Re: [M100] Any writers still using an M100?

[Brian Brindle]

Mike,

Maybe it's my e-mail client but I didn't see your response to what Evan
said.

I worked for Radio Shack in the 90s and I can say positively that reporters
using the M100 was not an urban legend. I supported dozens for many years
and was often offered more than retail for the equipment I had after Radio
Shack discontinued selling it. The reporters I supported were more
frustrated with the decline in phone booths than they were the aging or
capabilities of their equipment. I never did run into any sports reporters
though so maybe that's the urban legend.

I still use my M100 regularly today. I often get asked why I use such an
ancient device and usually the person who asks me is still using pen and
paper to take notes in a meeting so I just point out they like that ancient
technology for taking notes - I can type like a maniac so this works for
me. (And is technically newer.) I recently brought my TRS80 to one of our
"diversity" meetings at work. Just so happens this one was titled "Who
Moved My Cheese" and was all about dealing with change. I thought it was
quite appropriate I brought my 30 year old computer to that to take notes.
While I was in there a former reporter from the Roanoke TImes and World
News, who is now our Development Director, took one look at it and started
to tell us stories of him using a M100 to cover a news story in Washington
DC late 90's early 2000s. He mentioned how easy it was to type and submit
the articles for the copy editors. He was quite impressed with my REX
capabilities and tiny storage options available today indicating if he were
a reporter and had stuff like that he might consider still using it.

Granted, those usage stories are still over 17 years ago but I still use my
M100s as often as possible and it's mostly for writing. Computers have, in
my opinion, only gotten to the same level of convenience as the M100 in the
last few years. I do love my surface, it is instant on, has a decent
keyboard, decent battery life and actually makes my M100 feel bulky. But
still it's expensive and over complicated for most things. Still sometimes
sits with a software update screen when I power it on. So just like 90% of
the folks will grab a pen and paper instead of firing up their laptop to
their favorite text/note program when inspiration strikes I prefer to grab
my M100 as that tool.

Brian




On Thu, Nov 2, 2017 at 5:53 PM, Mike Stein  wrote:

> I thought some of you might be amused by this reply to a post I made in a
> CCtalk mailing list thread discussing the best device for undistracted
> writing with a good keyboard, display and battery life:
>
> FWIW, Evan is a well-known figure in the vintage computer community.
>
> m
>
> - Original Message -
> From: "Evan Koblentz via cctalk" 
> To: "General Discussion: On-Topic and Off-Topic Posts" <
> cct...@classiccmp.org>
> Sent: Monday, October 30, 2017 3:47 PM
> Subject: Re: looking at buying a pocket PC / PDA
>
>
> >> Radio Shack M100 ... still used by some writers for the very reason you
> mention.
> >
> > That is not true.
> >
> > It was an urban legend in the 1990s that a handful of old farts in the
> > entirely sportswriting industry (thousands of writers overall) may
> > "still" be using their Model 100s. I'm sure if you looked hard enough
> > some of them still used typewriters too.
> >
> > In 2017? It's ridiculous to even speculate.
>

Re: [M100] new project

[Brian Brindle]

Stephen, yes - that works perfectly. The situation I was describing above
is after a CTRL-BREAK-RESET total wipe of the M100 after I have wedged it
completely - then reload RAM from REX.


On Wed, Nov 1, 2017 at 8:43 AM, Stephen Adolph <twospru...@gmail.com> wrote:

> At some point in REX I included a feature to maintain clock setting
> through ram image swaps.
>
> On Wed, Nov 1, 2017 at 8:21 AM, Brian Brindle <bbrin...@gmail.com> wrote:
>
>> Peter,
>>
>> The current clock in the M100 does just fine usually. Unless it sits for
>> a long time. My request for another one is just me being lazy. (sort of).
>>
>> I use my m100 in strange ways and often I have issues where it crashes or
>> locks up and requires a total system reset.
>> Most of my activities with it require accurate time. I'm either logging
>> things, tracking things or just doing notes etc.
>> With REX it's like a dream to recover from these situations. Granted,
>> more times than not REX is also the cause..
>>
>> But right now I reset, load REXMGR, reload the RAM image and it takes
>> seconds.
>>
>> Then I have to set the clock by either going into BASIC and setting the 3
>> variables or attaching one of my external devices
>> and running a basic program to do it for me.
>>
>> Not hard mind you but when I do this same thing in VirtualT the time is
>> always right so maybe I'm spoiled.
>>
>>
>> Brian
>>
>>
>>
>>
>> On Oct 31, 2017 7:01 PM, "Peter Vollan" <dprogra...@gmail.com> wrote:
>>
>> Let me sure that I understand: however correctly you set the time on
>> your Model 100, it will "drift off", because it cannot keep correct
>> time?
>>
>>
>> On 26 October 2017 at 12:58, John R. Hogerhuis <jho...@pobox.com> wrote:
>> >
>> >
>> > On Thu, Oct 26, 2017 at 12:22 PM, Brian Brindle <bbrin...@gmail.com>
>> wrote:
>> >>
>> >> Hey John,
>> >>
>> >> To move RAM images around I"m using REX, creating a backup of the RAM
>> >> image and saving it to "disk" or in this case Mcomm or my NADS. I like
>> Mcomm
>> >> because the directory it saves everything in on the phone is
>> automatically
>> >> backed up (by another application) to dropbox right now. Then I load
>> that
>> >> image in VirtualT on the PC.
>> >>
>> >
>> > Ah. Well, I did write a program to sync time with NADSBox.
>> >
>> > http://bitchin100.com/wiki/index.php?title=Synchronize_Time_
>> with_your_NADS
>> >
>> > -- John.
>>
>>
>>
>
>

Re: [M100] new project

[Brian Brindle]

Peter,

The current clock in the M100 does just fine usually. Unless it sits for a
long time. My request for another one is just me being lazy. (sort of).

I use my m100 in strange ways and often I have issues where it crashes or
locks up and requires a total system reset.
Most of my activities with it require accurate time. I'm either logging
things, tracking things or just doing notes etc.
With REX it's like a dream to recover from these situations. Granted, more
times than not REX is also the cause..

But right now I reset, load REXMGR, reload the RAM image and it takes
seconds.

Then I have to set the clock by either going into BASIC and setting the 3
variables or attaching one of my external devices
and running a basic program to do it for me.

Not hard mind you but when I do this same thing in VirtualT the time is
always right so maybe I'm spoiled.


Brian




On Oct 31, 2017 7:01 PM, "Peter Vollan" <dprogra...@gmail.com> wrote:

Let me sure that I understand: however correctly you set the time on
your Model 100, it will "drift off", because it cannot keep correct
time?


On 26 October 2017 at 12:58, John R. Hogerhuis <jho...@pobox.com> wrote:
>
>
> On Thu, Oct 26, 2017 at 12:22 PM, Brian Brindle <bbrin...@gmail.com>
wrote:
>>
>> Hey John,
>>
>> To move RAM images around I"m using REX, creating a backup of the RAM
>> image and saving it to "disk" or in this case Mcomm or my NADS. I like
Mcomm
>> because the directory it saves everything in on the phone is
automatically
>> backed up (by another application) to dropbox right now. Then I load that
>> image in VirtualT on the PC.
>>
>
> Ah. Well, I did write a program to sync time with NADSBox.
>
> http://bitchin100.com/wiki/index.php?title=Synchronize_Time_with_your_NADS
>
> -- John.

Re: [M100] new project

[Brian Brindle]

Hey John,

To move RAM images around I"m using REX, creating a backup of the RAM image
and saving it to "disk" or in this case Mcomm or my NADS. I like Mcomm
because the directory it saves everything in on the phone is automatically
backed up (by another application) to dropbox right now. Then I load that
image in VirtualT on the PC.

The times when I need an accurately set clock are not always when I'm
backing things up. Time drift is a constant issue when tracking sats with
the M100 in the middle of a field with radio gear strapped all over you. I
have several external devices that can set the clock for me in times like
this but it requires loading a basic program to do so. Not difficult mind
you but not quite just a power cycle either.

I like Thought in SuperROM but wrote some perl scripts to manipulate Idea!
data files many years ago so am pretty set on using it. Your talking to a
guy who still uses his 34 year old PC so I'm pretty resistant to change.

Brian


On Thu, Oct 26, 2017 at 3:10 PM, John R. Hogerhuis <jho...@pobox.com> wrote:

> On Thu, Oct 26, 2017 at 11:59 AM, Brian Brindle <bbrin...@gmail.com>
> wrote:
>
>>
>> The RTC request is based on the way I utilize my M100s. I'm constantly
>> doing a total wipe on them for one reason or another
>>
>
>
> What file service do you use if any? You mentioned moving images around to
> VIrtualT does that mean you use TBACK?
>
> I could add a time sync extension to either TBACK or LaddieAlpha.
>
> If TBACK, I could make it skip the clock when restoring an image.
>
>
>> but I use Idea! pretty heavily and rely on a correct date/time. Just
>> always thought it would be nice if it was always correct since it's
>> something I constantly forget to set.
>>
>>
> Have you used Thought in SuperROM?
>
> Idea is compiled BASIC code, IIRC, Thought is MUCH faster.
>
> -- John.
>
>
>

Re: [M100] new project

[Brian Brindle]

This does look awesome Stephen so forgive the selfish RTC request - I don't
want to seem like I'm diminishing all the other incredibly amazing / mind
blowing things you are already bringing. I don't know how I've gone this
long without having a REX but I did and I've spent the last two weeks
positively giddy with my new capabilities. I used to have different M100s
for different projects and would grab the appropriate one when I wanted to
do that thing. My (now horribly neglected) satellite tracking project for
example. Because of the size of the Keplerian database and my lack of
ambition to do anything like load stuff from SD card I just kept it all
loaded on one unit. Now I can pop that image on the current M100 I'm
working on, copy it to my phone, sync via dropbox or GoogleDrive and play
with that image on VirtualT then reverse the process to get it back on
physical hardware. It's downright amazing. Everyone needs a REX.

The RTC request is based on the way I utilize my M100s. I'm constantly
doing a total wipe on them for one reason or another but I use Idea! pretty
heavily and rely on a correct date/time. Just always thought it would be
nice if it was always correct since it's something I constantly forget to
set.

On Wed, Oct 25, 2017 at 9:05 PM, Stephen Adolph <twospru...@gmail.com>
wrote:

> I looked a bit at a supercap but...we have a battery...we just need a
> wire!.
>
> What would one need an rtc For?
>
>
> On Wednesday, October 25, 2017, Brian Brindle <bbrin...@gmail.com> wrote:
>
>> Any thoughts of a battery backup and or a RTC?
>>
>> On Oct 25, 2017 6:49 PM, "Josh Malone" <josh.mal...@gmail.com> wrote:
>>
>>> Wow. This sounds very cool! I've never actually run CP/M, and I'm not
>>> sure that running it on Model-T is super exciting (probably just because I
>>> haven't tried it) but the capabilities of the REXCPM sound awesome.
>>>
>>> I'm fine with a 3-wire install. Hell, any number of wires to the mobo
>>> would not be a turn-off for me using it; basically as long as trace-cutting
>>> isn't involved it won't bother me.
>>>
>>> I'm assuming the CPLD and SRAM are on the other side? Man, that board is
>>> gonna be crammed! :)
>>>
>>> -Josh
>>>
>>

Re: [M100] new project

[Brian Brindle]

Any thoughts of a battery backup and or a RTC?

On Oct 25, 2017 6:49 PM, "Josh Malone"  wrote:

> Wow. This sounds very cool! I've never actually run CP/M, and I'm not sure
> that running it on Model-T is super exciting (probably just because I
> haven't tried it) but the capabilities of the REXCPM sound awesome.
>
> I'm fine with a 3-wire install. Hell, any number of wires to the mobo
> would not be a turn-off for me using it; basically as long as trace-cutting
> isn't involved it won't bother me.
>
> I'm assuming the CPLD and SRAM are on the other side? Man, that board is
> gonna be crammed! :)
>
> -Josh
>

[M100] Micro-TPDD2

[Brian Brindle]

Just happened on this board on OSHPark - this from anyone have any info on
it?

https://www.oshpark.com/profiles/Stardust

Re: [M100] REX Castellated board

[Brian Brindle]

Hang in there Josh,

I had this with one of mine. Turned out to be "solder balls" that formed
from the solder paste I was using under the CPLD. I couldn't see them till
I pulled the chip. I'd recommend visually inspecting everything with high
magnification - use your phone or digital camera if nothing else - and then
test each neighboring pin with a meter for bridges. If that's all clear
test the programming headers back to the appropriate CPLD pins for
continuity.

As a good friend always reminds me - "success lies on the far side of
failure" so fail quickly and fail often if you want to get ahead.

Brian



On Sun, Oct 22, 2017 at 5:01 PM, Josh Malone <josh.mal...@gmail.com> wrote:

> Built my first functional REX on the castellated PCB. Programs and tests
> okay.
>
> But, I've also built me second non-functional REX, too. So far I'm
> 3-out-of-5 for successful builds. Not sure I'm really up to this. :(
>
> Maybe I can figure out what's wrong w/ this board. Impact says it
> finds lots of unknown devices on the chain and barfs. Reflowed the
> CPLD pins but it didn't help. Bugger.
>
> At least I have one functional REX for my 102, so, yay!
>
> -Josh
>
> On Fri, Oct 20, 2017 at 10:05 PM, Brian White <bw.al...@gmail.com> wrote:
> > That would be awesome of course!
> >
> > On Oct 20, 2017 12:35 PM, "Stephen Adolph" <twospru...@gmail.com> wrote:
> >>
> >> good to hear the castellated board is working.
> >> I revised the REX PCB design to (1) remove unneeded parts (2) use ground
> >> and power planes and (3) provide a pad to bridge 3.3V onto PORT_EN with
> a
> >> solder bridge.  I don't myself plan to test the board but I can post it
> for
> >> others to test.
> >> Steve
> >>
> >> On Fri, Oct 20, 2017 at 12:23 PM, Josh Malone <josh.mal...@gmail.com>
> >> wrote:
> >>>
> >>> My parts should arrive tomorrow. How to take a stab at try two soon.
> >>> thanks to everyone for all the help.
> >>>
> >>> On Oct 20, 2017 11:38 AM, "Brian Brindle" <bbrin...@gmail.com> wrote:
> >>>>
> >>>> Reflow of the board seemed to fix it. Guess I need to play around with
> >>>> my methods a little. Working as expected right now.
> >>>>
> >>>> On Oct 20, 2017 8:31 AM, "Brian White" <bw.al...@gmail.com> wrote:
> >>>>>
> >>>>> Yeah that looks good.
> >>>>>
> >>>>> On Oct 20, 2017 6:32 AM, "Brian Brindle" <bbrin...@gmail.com> wrote:
> >>>>>>
> >>>>>> I'm using some AM29F800BB-90EF I had. Waiting on the AM29F800BB-7EK
> >>>>>> from China still. Should be here today.
> >>>>>>
> >>>>>>
> >>>>>> On Oct 19, 2017 8:47 PM, "Brian White" <bw.al...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> What exact flash part number do you have?
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, Oct 19, 2017 at 1:22 PM, Brian Brindle <bbrin...@gmail.com
> >
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> I have one put together that programmed up OK but am having issues
> >>>>>>>> getting the REX software on it. It erases all the blocks just
> fine but hangs
> >>>>>>>> when re-loading to block 0. Probably something up with the flash..
> >>>>>>>>
> >>>>>>>> I'll report back when I have more info.
> >>>>>>>>
> >>>>>>>> Brian
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Thu, Oct 19, 2017 at 7:25 AM, Stephen Adolph
> >>>>>>>> <twospru...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> Has anyone made a REX successfully with that modified PCB yet?
> >>>>>>>>> I would like to know if that artwork is good or bad.
> >>>>>>>>>
> >>>>>>>>> ..Steve
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>
> >
>

Re: [M100] REX Castellated board

[Brian Brindle]

Thanks Stephen for all of this. Been a fun project. Running my new Rex
through it's paces now. Loaded everything from backup and it's doing great.



On Oct 20, 2017 12:35 PM, "Stephen Adolph" <twospru...@gmail.com> wrote:

good to hear the castellated board is working.
I revised the REX PCB design to (1) remove unneeded parts (2) use ground
and power planes and (3) provide a pad to bridge 3.3V onto PORT_EN with a
solder bridge.  I don't myself plan to test the board but I can post it for
others to test.
Steve

On Fri, Oct 20, 2017 at 12:23 PM, Josh Malone <josh.mal...@gmail.com> wrote:

> My parts should arrive tomorrow. How to take a stab at try two soon.
> thanks to everyone for all the help.
>
> On Oct 20, 2017 11:38 AM, "Brian Brindle" <bbrin...@gmail.com> wrote:
>
>> Reflow of the board seemed to fix it. Guess I need to play around with my
>> methods a little. Working as expected right now.
>>
>> On Oct 20, 2017 8:31 AM, "Brian White" <bw.al...@gmail.com> wrote:
>>
>>> Yeah that looks good.
>>>
>>> On Oct 20, 2017 6:32 AM, "Brian Brindle" <bbrin...@gmail.com> wrote:
>>>
>>>> I'm using some AM29F800BB-90EF I had. Waiting on the AM29F800BB-7EK
>>>> from China still. Should be here today.
>>>>
>>>>
>>>> On Oct 19, 2017 8:47 PM, "Brian White" <bw.al...@gmail.com> wrote:
>>>>
>>>>> What exact flash part number do you have?
>>>>>
>>>>>
>>>>> On Thu, Oct 19, 2017 at 1:22 PM, Brian Brindle <bbrin...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I have one put together that programmed up OK but am having issues
>>>>>> getting the REX software on it. It erases all the blocks just fine but
>>>>>> hangs when re-loading to block 0. Probably something up with the flash..
>>>>>>
>>>>>> I'll report back when I have more info.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 19, 2017 at 7:25 AM, Stephen Adolph <twospru...@gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Has anyone made a REX successfully with that modified PCB yet?
>>>>>>> I would like to know if that artwork is good or bad.
>>>>>>>
>>>>>>> ..Steve
>>>>>>>
>>>>>>
>>>>>>
>>>>>

Re: [M100] REX Castellated board

[Brian Brindle]

Reflow of the board seemed to fix it. Guess I need to play around with my
methods a little. Working as expected right now.

On Oct 20, 2017 8:31 AM, "Brian White" <bw.al...@gmail.com> wrote:

> Yeah that looks good.
>
> On Oct 20, 2017 6:32 AM, "Brian Brindle" <bbrin...@gmail.com> wrote:
>
>> I'm using some AM29F800BB-90EF I had. Waiting on the AM29F800BB-7EK from
>> China still. Should be here today.
>>
>>
>> On Oct 19, 2017 8:47 PM, "Brian White" <bw.al...@gmail.com> wrote:
>>
>>> What exact flash part number do you have?
>>>
>>>
>>> On Thu, Oct 19, 2017 at 1:22 PM, Brian Brindle <bbrin...@gmail.com>
>>> wrote:
>>>
>>>> I have one put together that programmed up OK but am having issues
>>>> getting the REX software on it. It erases all the blocks just fine but
>>>> hangs when re-loading to block 0. Probably something up with the flash..
>>>>
>>>> I'll report back when I have more info.
>>>>
>>>> Brian
>>>>
>>>>
>>>> On Thu, Oct 19, 2017 at 7:25 AM, Stephen Adolph <twospru...@gmail.com>
>>>> wrote:
>>>>
>>>>> Has anyone made a REX successfully with that modified PCB yet?
>>>>> I would like to know if that artwork is good or bad.
>>>>>
>>>>> ..Steve
>>>>>
>>>>
>>>>
>>>

Re: [M100] REX Castellated board

[Brian Brindle]

I'm using some AM29F800BB-90EF I had. Waiting on the AM29F800BB-7EK from
China still. Should be here today.


On Oct 19, 2017 8:47 PM, "Brian White" <bw.al...@gmail.com> wrote:

> What exact flash part number do you have?
>
>
> On Thu, Oct 19, 2017 at 1:22 PM, Brian Brindle <bbrin...@gmail.com> wrote:
>
>> I have one put together that programmed up OK but am having issues
>> getting the REX software on it. It erases all the blocks just fine but
>> hangs when re-loading to block 0. Probably something up with the flash..
>>
>> I'll report back when I have more info.
>>
>> Brian
>>
>>
>> On Thu, Oct 19, 2017 at 7:25 AM, Stephen Adolph <twospru...@gmail.com>
>> wrote:
>>
>>> Has anyone made a REX successfully with that modified PCB yet?
>>> I would like to know if that artwork is good or bad.
>>>
>>> ..Steve
>>>
>>
>>
>

Re: [M100] REX Castellated board

[Brian Brindle]

I have one put together that programmed up OK but am having issues getting
the REX software on it. It erases all the blocks just fine but hangs when
re-loading to block 0. Probably something up with the flash..

I'll report back when I have more info.

Brian


On Thu, Oct 19, 2017 at 7:25 AM, Stephen Adolph 
wrote:

> Has anyone made a REX successfully with that modified PCB yet?
> I would like to know if that artwork is good or bad.
>
> ..Steve
>

Re: [M100] REX build failure - post mortem

[Brian Brindle]

Josh,

I looked at one of the REX boards I had that didn't work. The regulator was
getting hot on it and I had the same low resistance measurements on the VCC
and ground. I know on this particular one I killed the CPLD by shorting the
FTDI VCC and ground when jumping VCC to R3.

Brian

On Oct 18, 2017 7:22 PM, "Brian White" <bw.al...@gmail.com> wrote:

> I guess if you're going to build over 60 of them it starts to matter. I
> just figured if I'm going to go to this much effort it took just to build
> one at all, that $1 wasn't even visible, but a built and in-use rex that
> fails some day when it might have lived, is visible. So I went for the
> better-ish versions of all parts. The factors for this are not the same as
> for mass producing a clock that will sell in dollar stores.
>
> On Wed, Oct 18, 2017 at 6:39 PM, Stephen Adolph <twospru...@gmail.com>
> wrote:
>
>> Commercial is fine
>>
>>
>> On Wednesday, October 18, 2017, Josh Malone <josh.mal...@gmail.com>
>> wrote:
>>
>>> Also, meant to ask:
>>>
>>> Brian's BOM includes the  Industrial variant of the CPLD. The
>>> commercial variant is almost $1 cheaper and seems well within
>>> tolerance
>>>
>>> (voltage min is 3 instead of 2.7, temp is 0 - 70 C instead of 40 - 85 °C)
>>>
>>>
>>> Any reason not to sub this part in?
>>>
>>> -Josh
>>>
>>> On Wed, Oct 18, 2017 at 4:56 PM, Josh Malone <josh.mal...@gmail.com>
>>> wrote:
>>> > Thanks. I'm going to just order new parts and try again.
>>> >
>>> > On Wed, Oct 18, 2017 at 4:49 PM, Brian Brindle <bbrin...@gmail.com>
>>> wrote:
>>> >> 11.7k on 2 of mine.
>>> >>
>>> >>
>>> >> On Oct 18, 2017 4:25 PM, "Stephen Adolph" <twospru...@gmail.com>
>>> wrote:
>>> >>>
>>> >>> I can try to measure it later today for you.
>>> >>>
>>> >>> On Wed, Oct 18, 2017 at 4:24 PM, Stephen Adolph <
>>> twospru...@gmail.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> either the chip is a dud, or you have soldered it down in the wrong
>>> >>>> orientation (which is kinda easy to do)...  Do you have more CPLDs?
>>> >>>>
>>> >>>> On Wed, Oct 18, 2017 at 4:22 PM, Josh Malone <josh.mal...@gmail.com
>>> >
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> Thanks for the leads.
>>> >>>>>
>>> >>>>> I removed the CPLD and the resistance from 3v3 to gnd went to open;
>>> >>>>> repopulated it and it went to 3-ohms. Dunno what to try next. Maybe
>>> >>>>> put the same CPLD back on an original REX board (non-castellated)
>>> and
>>> >>>>> see what happens. But, I'd *really* love for someone to measure the
>>> >>>>> resistance on a known-good REX board and let me know what it should
>>> >>>>> be. Assuming the CPLD draws <= 1ma (datasheet says 17uA standby), R
>>> >>>>> should be over ~3k.
>>> >>>>>
>>> >>>>> -Josh
>>> >>>>
>>> >>>>
>>> >>>
>>> >>
>>>
>>
>

Re: [M100] REX build failure - post mortem

[Brian Brindle]

11.7k on 2 of mine.


On Oct 18, 2017 4:25 PM, "Stephen Adolph"  wrote:

> I can try to measure it later today for you.
>
> On Wed, Oct 18, 2017 at 4:24 PM, Stephen Adolph 
> wrote:
>
>> either the chip is a dud, or you have soldered it down in the wrong
>> orientation (which is kinda easy to do)...  Do you have more CPLDs?
>>
>> On Wed, Oct 18, 2017 at 4:22 PM, Josh Malone 
>> wrote:
>>
>>> Thanks for the leads.
>>>
>>> I removed the CPLD and the resistance from 3v3 to gnd went to open;
>>> repopulated it and it went to 3-ohms. Dunno what to try next. Maybe
>>> put the same CPLD back on an original REX board (non-castellated) and
>>> see what happens. But, I'd *really* love for someone to measure the
>>> resistance on a known-good REX board and let me know what it should
>>> be. Assuming the CPLD draws <= 1ma (datasheet says 17uA standby), R
>>> should be over ~3k.
>>>
>>> -Josh
>>>
>>
>>
>

Re: [M100] REX build progress

[Brian Brindle]

Quick update:

Well, the castellated boards look good after I deburred them. Took about 30
minutes to fully assemble one with hot air and solder paste. If I can make
a solder mask I think I could do it even faster. Should be able to do
several at a time in the $15 toaster oven once I get rolling but I am still
waiting on my FLASH from China.. Tried to flash one this morning but keep
having issues where Impact crashes or reports invalid ID on the chip..
Maybe my $20 programmer wasn't such a good deal. Could be an issue with the
friction hold header pins. I plan on making a programming jig where I can
put the boards face down on top of some contacts (metal screws) and quickly
program them. We will see how that work.



On Sun, Oct 1, 2017 at 4:21 AM, Brian White  wrote:

> Note, those directions are just the latest versions of everything I could
> find. But as far as I can tell, and I think Stephen said as much in a post
> sometime, that all the updates take the form of a full write, meaning you
> can use any update also as a fresh/initial load or downgrade, not just to
> update.
>
> So the end-user can switch to any version they want with no special tools
> or software.
>
> So if you want one of the earlier versions instead of the last build
> number of 4.9, you should be able to just install it, either as the builder
> doing it the first time, or as the end-user wanting something different
> than what the builder loaded.
>
> To flash any version of the firmware, you only need:
>
> * the update files (see bitchin100 and Stephen's directory on club100)
>
> * a modern pc (any os) running a tpdd server (laddie alpha, dlplus, etc)
>
> * serial connection (9f-25m "modem" cable, 9pin mini null-modem adapter,
> any usb-serial adapter)
>
> And you needed all that stuff anyway just to load ordinary software. The
> end-user can do it any time.
>
> You only need the special Xilinx programmer and software the very first
> time you program the cpld (or I suppose if the cpld somehow ever gets wiped
> or corrupted), so only the builder needs that, not the user.
>
> --
> bkw
>
>
>
> On Oct 1, 2017 3:14 AM, "Josh Malone"  wrote:
>
>> The CPLD load is coded April 24, 2011 (no rst). The REX SW version is 4.9.
>>
>> http://tandy.wiki/Building_a_REX
>>
>>
>> On Sat, Sep 30, 2017 at 5:25 PM, Georg Kaeter <
>> georg.kae...@gk-engineering-services.de> wrote:
>>
>>> Is there an opportunity to get at least 3 of the "new REX" ? I would
>>> like to update my M100 and  2 M102 with REX (I've already one running in my
>>> M200).
>>> Additional question:  What Revision you're using for the generic
>>> programming?
>>>
>>> Regards
>>> Georg
>>>
>>> Am 30.09.2017 21:08 schrieb "Gregory McGill" :
>>>
 woohoo!  good job Josh!! my 3 months of procrastination pays off :D

 Greg

 On Sat, Sep 30, 2017 at 8:26 AM, John R. Hogerhuis 
 wrote:

>
> On Sat, Sep 30, 2017 at 5:22 AM Josh Malone 
> wrote:
>
>> Success! I have a working REX built from the parts Greg sent. Turns
>> out that my 102 has no memory issues -- rather, CoolTerm was being stupid
>> about flow control and probably corrupting the transfer when I tried to
>> load TSDOS before. The CPLD programming went swimmingly and the REX
>> flashing was super easy thanks to mComm for Android (thanks Kurt!)
>>
>> Now I see what all the buzz is about with the REX. This is an awesome
>> product Stephen! I can't wait to build more of them.
>>
> Congratulations Josh. The more people that can build a REX the better.
>
> Club100 is us. It was even when Rick was minding the store, but now
> even more so.
>
> -- John.
>
> -- John.
>


>>

Re: [M100] Who wants a REX? Gauging interest

[Brian Brindle]

I took advantage of the 3 day weekend and worked on my boards. Stupidly I
started them in a temporary location rather than the "bench" and scrapped
the 1st board with a stupid cutting mistake after I had it already
populated.

I have built many things in my lifetime but this project is somehow special
and has been a journey in self discovery. I have learned so much about
myself. First, I am a very angry man. Second, I am apparently blind now
requiring more magnification and light than I thought ever possible. Third,
I suffer from some weird form of aphasia that only lets me figure out that
what I'm vigilantly checking and double checking is completely backwards
when it's impossible to fix. Finally, always go with what you know. I tried
several of the new fandangled methods for SMT soldering that seemed less
complicated but ultimately what worked is my old methods of doing things
that I thought were inferior. Trust your gut.

Anyway, I too have some cad/stellated boards on the way to test and have a
pretty good process for cutting/shaping the existing ones. I've also
determined that hot air is the way to go for assembling these things but
still I can only crank out about one an hour. I'm using some solder paste
and one of these guys:
https://www.amazon.com/WEP-858D-Soldering-Station-Suitable/dp/B0055B6NGE

I got some epoxy (to hold the flash on) and plan to try the hot skillet
method later this week. If I can do several boards at once I may be willing
to both share my setup and help with production of these things if
necessary.

More to come in the next few days.

Brian


On Mon, Oct 9, 2017 at 8:46 AM, Josh Malone  wrote:

> I'm shooting to produce them at the same $60 price that club100 sold
> them previously.
>
> As a status update, I'm expecting delivery of the castellated board
> test this week. Assuming I can validate this modification to the PCB
> design, I think the pre-castellated board from OSH Park will be the
> way to go. Still hoping to announce a small board run sometime this
> month. We'll see.
>
> -Josh
>
> On Mon, Oct 9, 2017 at 4:42 AM, James Zeun  wrote:
> > I've little experience in this area, but a friend of mine makes hardware
> for
> > the ZX Spectrum, Timex computer to those in the states. I know he ended
> up
> > out sourcing work to China as it was cheaper then populating 30+ boards
> by
> > hand. I don't believe his IDE adapter was anymore complicated then the
> > REX,not sure if he had to flash chips.
> >
> > If the decision is to solder them ourselves, I'll put my hand up and
> offer
> > to help out. My soldering isn't too ropey, probably not as good as some
> of
> > the chaps on here :-)
> >
> > How much is an assembled REX? I already own one, but wouldn't mind
> having a
> > spare.
> >
> >
> >
> > On 9 Oct 2017 6:31 a.m., "ray gordon"  wrote:
> >>
> >> Hi,
> >>
> >> I hav'nt been monitoring the list for a couple weeks, but I'm certainly
> >> interested in several rexes
> >>
> >>
> >>
> >>
> >> 
> >> From: M100  on behalf of Jim
> Anderson
> >> 
> >> Sent: Thursday, October 5, 2017 7:01 PM
> >> To: m...@bitchin100.com
> >> Subject: Re: [M100] Who wants a REX? Gauging interest
> >>
> >> > -Original Message-
> >> >
> >> > You don't need any tpdd device, you just need any modern pc and a usb
> >> > serial cable and some free software.
> >>
> >> Sorry, by 'TPDD device' I meant TPDD emulators as well, not just the
> >> actual Tandy drives or NADSBox or whatnot.  I guess I should have said
> 'some
> >> kind of TPDD-compatible device'.
> >>
> >> > The only problem would be if the cpld programming is not the same for
> >> > 100 vs 200. If not, then it would probably not be possible to take a
> 100
> >> > rex and re-flash it to a 200 rex using only a 200.
> >>
> >> It's the same CPLD code.  AFAIK re-flashing a 100 REX with 200 firmware
> in
> >> a 200 ought to work the same way as re-flashing a 4.8 REX to 4.9...
> >>
> >> > I have a 200, but I don't remember if Stephen has made the 200 version
> >> > firmware available yet.
> >>
> >> Yes, it's available.  (So is the NEC firmware.)
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> jim
>

Re: [M100] can somebody help with REX parts shipping?

[Brian Brindle]

Jim,

Unfortunately I already ordered and received mine. I did however note if
you search for AM29F800BB on ebay there are plenty of chips available from
various sellers.

Also, while I have not tried any of these the Macronix MX29F400CBTI-70G
available from Digikey looks to be a compatible match.


Brian




On Thu, Sep 21, 2017 at 12:09 AM, Jim Anderson  wrote:

> So... I decided to pull the trigger on building my own set of REX modules,
> and now I'm a bit stuck at verical's shipping-charges gunpoint...
>
> The main thing I was concerned about was that the cost of the boards from
> OSH Park was not discussed anywhere and not available without making an
> account, so I'd assumed it was going to be the most outrageous cost of the
> whole project.  After finding out that it's not anywhere near what I was
> expecting to pay (and shipping to Canada is free), I was nearly giddy and
> ordered six REX boards and three QUAD boards (figured why not, it was only
> a little bit more and if I can figure out what SRAM chip would work with it
> I could build some).
>
> Ordering from Digikey is also no problem - switch over to digikey.ca and
> shipping is only $8 for orders under $100.
>
> Then I go to order the flash chips from verical.  I'm sitting here staring
> at the checkout form now, jaw agape, as it offers me a choice of shipping
> methods ranging in price from $46.70 to $57.76 (for half a dozen
> chips!!!).  Apparently they only ship to Canada by courier.  Chatted with
> their customer service and this was confirmed - no option for a cheaper and
> slower shipping method.
>
> From the activity over the last day or two here, it seems like I might
> have missed the boat on this, but: if anybody is ordering the flash chips
> from verical, would you mind adding six more chips to your order and
> mailing them to me after you get them?  I'll happily pay you in advance.
>
> (I used to have things shipped to a PO box service in Point Roberts, WA
> whenever I would run into highway robbery shipping like this, but I don't
> currently have a valid passport so I can't drive across to pick anything up
> now.)
>
>
>
>
>
>
>
> jim
>
>

Re: [M100] Questions regarding REX

[Brian Brindle]

I just got three boards from OSH Park and have all the parts. The WiKi was
awesome taking care of the hardest bit of sourcing all the parts. Other
than that it doesn't look like too awful of a job. I'd be happy to take
some photos during the construction to add to the cause.

I have a few ideas on some programming jigs and reflowing the boards but I
hadn't really considered making more than a few. If it goes well maybe I'll
make a couple of runs. I've had a really bad experience in the past making
RS232 Boards for the C64 that started out fun and turned into a nightmare
quickly though so not really that ambitious about being a "supplier". I
have the utmost respect for all the guys in this group who have built these
projects and distributed them. But maybe the documentation will help make
them more prolific.

Brian - KW4KB




On Sep 20, 2017 5:55 AM, "Brian White"  wrote:

> Thank you for spotting that. I have found it and uploaded a copy to the
> linked google drive folder.
>
> Just for the record, it was still there in the form of the reference links
> to the original files from Steven's upload folder on club100 and the rex
> page on bitchin100.
> So, the "sources and support files" link on the bottom under "references"
> had it.
>
> Yes, that is exactly my aim was to take the raw data from Steven and
> digest it some more. Like looking at the eaglecad files to deduce some
> things that aren't otherwise documented or explained explicitly. Figure out
> what is the minimum software required and the minimum hardware required to
> program the cpld. If you just google normally, you might think you need a
> $250 programmer, when you only need a $25 one.
> I'm trying to make a recipe that can be followed, so that "build your own"
> does NOT translate as "figure it out".
>
> It IS still a pretty ambitious build even with full hand-holding. I had
> done a few FigTronix boards before trying the rex, and maybe that was the
> perfect ramp-up/practice project. Simpler easier soldering, simpler easier
> programming.
>
> There is a lot of more improving to do still.
>
> I could use some more pictures to go with some of the directions.
>
> I could also separate out the few files that are actually used, and retain
> everything else separately off to the side as reference. I could expand the
> directions for bootstrapping dlplus & teeny, and add Windows-based
> directions since everything I have now is just linux based.
>
> I need to write something clearer about the roms too. There are a few
> different places to get copies of various roms, but for rex, I think you
> want to use specifically the ones in the roms.zip that Steven put on the
> rex documentation on bitchin100. But there are a few others. For one thing,
> roms.zip includes mforth, but now there is a newer version of mforth than
> the one in roms.zip, and I've dumped a couple roms myself that I haven't
> seen anywhere else. (Disk+2.0 and OWL)
>
> I think there must also be some work-alike flash memory chips available
> from DigiKey that could be added to the digikey cart so you can get
> everything at once instead of having to do that annoying special order from
> Verical.
>
> But, as you say, it was a lot to get it this far, so I figured get what I
> had up there in any fashion, and then improve it over time. And being that
> it's a wiki, it would be easy enough to improve a little here & there over
> time, or someone else could.
>
> --
> bkw
>
> On Wed, Sep 20, 2017 at 4:04 AM, Jim Anderson  wrote:
>
>> > -Original Message-
>> >
>> > Steven has published the files and info needed to make them yourself. I
>> > have proven that nothing was missing by doing it and making a few, and
>> > writing up the steps, parts, and tools, and filling in some details into
>> > a more explicit recipe that more people should be able to follow, and
>> > put that on a wiki so that anyone else can improve the recipe even
>> > further.
>> >
>> > If you want to buy a rex, instead of build one for yourself, first you
>> > have to find someone who wants to build them for you. They need to be
>> > able to follow this:
>> >
>> > http://tandy.wiki/REX
>>
>> When I saw this I have to admit I initially had the same letdown reaction
>> I've had in the past when I've asked about REX and been told 'go build your
>> own'.  It seemed like a project that was totally out of reach for me - a
>> bit like your average home PC user would feel after being told 'tired of
>> windows?  Go install Linux!'
>>
>> In all the reading I have done on REX, I have never run across this wiki
>> before.  I immediately went and read through your whole writeup a couple of
>> times.  This is fantastic.  In the space of time it took to read and digest
>> this, I went from feeling like this is an out-of-reach project to feeling
>> like this might actually be doable, and in fact might be something the kids
>> and I could do together.  (I'll have to see how I handle SMD 

Re: [M100] A z-code interpreter for the model 100

[Brian Brindle]

Very cool! Thanks Clint!

On Sat, Aug 29, 2015 at 11:37 AM, Andrew Roach ajroac...@gmail.com wrote:

 Is it possible to compile modern sourcecode to v3 files using inform?
 On Sat, Aug 29, 2015 at 11:31 AM Clinton Reddekop 
 clinton.redde...@gmail.com wrote:

 Hello everyone,

 I've just put a project into the Club100 Member Upload area that I hope
 will interest some of you.  It is a z-code interpreter for playing
 version-3 Infocom games on the Model 100 + REX.  I've been playing ZORK I
 quite a bit over the last 3 weeks with no problems.

 It is here:

 http://www.club100.org/memfiles/index.php?direction=0order=directory=Clinton%20Reddekop

 Some notes:
 * PLEASE keep your RAM backed up in REX just in case of bugs.  I'm not
 aware of any but there could be one or two or several lurking in there.
 * works with version-3 z-code files only (this covers *most* Infocom
 games)
 * you will probably need at least 24K RAM installed in your machine
 * save files can only be written to/read from the RAM file system
 * it doesn't support non-ASCII characters yet
 * if a game fails to start, or if saving a game fails, you probably don't
 have enough free RAM
 * As-built it works with REX v4.8, and the packaging program z100pkg.exe
 is a Windows executable.  See build.txt for instructions to build it on
 Windows; modify if your needs are different.

 Thanks,
 Clint