Re: [M100] Model T clock doubler

[MikeS]

MVT100 Windows application???
  - Original Message - 
  From: Stephen Adolph 
  To: m...@bitchin100.com 
  Sent: Tuesday, November 21, 2023 11:53 AM
  Subject: Re: [M100] Model T clock doubler


  Ken I will try to complete a package of info for m100 in time!


  You could consider the BCR hack for serial comms over BCR port.  The VT100 
driver on M100 plus my MVT100 windows application would allow you to demo using 
the PC as an 80x25  monitor for M100.  No other hardware needed.


  Cheers Steve

  On Tuesday, November 21, 2023, Ken St. Cyr  wrote:

Amazing work, Steve! I've been thinking about doing an M100 mod 
extravaganza video, so this is one mod that I definitely want to do for that 
project. I'll likely be checking it out over Christmas break in a few weeks.   


//Ken S



From: M100  on behalf of Brian White 

Sent: Monday, November 20, 2023 12:46:06 PM
To: m...@bitchin100.com 
Subject: Re: [M100] Model T clock doubler 

Hah, all of my own boards get to about v 12 before I'm mostly happy, and 
then continue polishing for several more. It's almost like software, never 
really done.


bkw


On Sun, Nov 19, 2023, 7:56 PM Stephen Adolph  wrote:

  I jumped the gun a bit, needed to redo the boards and change the circuit. 
 

  On Sunday, November 19, 2023, Brian K. White  wrote:

None of the file links work, but I'm sure it *will* be awesome.
Sounds super.

On 11/18/23 10:54, Stephen Adolph wrote:

  Hi everyone,

  I've been working towards finishing off my project for increasing the 
speed of the Model T laptops.  The idea is to create a (relatively) easy to 
make and install solution that allows the user to switch the clock rate from 
2.5 MHz to 5 MHz.
  This is really nice on the 40x8 LCD machines.

  The universal software command to switch clock rate is
  OUT 85,1 for 2x mode and
  OUT 85,0 for 1x mode.

  Of course the Model T is not designed for this, but in my experience 
so far, it seems reliable.  I really like the upgrade and plan to install in 
all my laptops. Being able to operate in nominal clock mode is of course very 
useful because you may find some software to be incompatible.

  Models I have upgraded to date:
  * M100 (NA, early variant, not UK)
  * T102
  * T200
  * NEC PC-8201/8201a
  * Olivetti M10

  I am publishing all the information needed to DIY this upgrade. I 
don't have any plans to make these upgrades.  Consider this upgrade only if you 
are comfortable with soldering surface mount parts, and with making minor 
modifications to your laptop.

  Upgrades that are done and in the process of documentation are M100, 
T200, NEC.  Upgrades that need a new PCB design still are T102 and M10.  All 
information will be at this site:

  https://bitchin100.com/wiki/index.php?title=5MHZ_upgrade_for_Model_T 


  I am publishing
  * PCB designs for the clock doubler board (there are a few variants)
  * schematic
  * bill of materials for parts you need
  * documentation for building the clock doubler
  * installation documentation per laptop

  Things I have discovered while developing this;
  1.  Power consumption goes up by about 20% when you run at 2x clock.
  2.  Depending on the speed of your SRAM,  you may need to implement a 
modification to speed that up.  Each model has a specific mod you need.
  3.  In M100 with the custom socket pinout, in most cases you need to 
upgrade your Main ROM to something faster.  This usually involves an adapter 
board and an EPROM.
  4.  In the Tandy 200, one must slow down the machine temporarily to 
access the RTC.  There is a specific change for that.

  Anyhow, as I complete a particular laptop, I'll post the needed files.

  Hopefully this will be of some interest for those inclined to play 
around with hardware.  I have no problem if anyone wants to take the design and 
improve it or change it.

  Feel free to contact me directly with questions.

  cheers
  Steve






-- 
bkw

Re: [M100] Modifying TELCOM

[MikeS]

Where did you find a disassembly of TELCOM?

Thanks!

m

- Original Message - 
From: "mark audacity romberg" 
To: 
Sent: Thursday, May 04, 2023 8:42 PM
Subject: [M100] Modifying TELCOM


I was looking at the disasssembled TELCOM source today, and it seems there’s 
almost a kilobyte devoted to looking up and dialing phone numbers that could be 
ditched, which has me thinking that it shouldn’t be too cramped to add hardware 
handshaking and maybe even XMODEM once that (and ADDRSS and SCHEDL, another 333 
bytes of dead weight) are ripped out of the ROM. 

Has anyone tried anything like this? I know about HTERM, but I want to maintain 
modem functionality and I don’t care that much about VT emulation. 

—m.a=

Re: [M100] REXCPM

[MikeS]

Well, if you expect to find ordering info in the Wiki section...

Even when you finally find the REXCPM section there's no mention of ordering 
info in the contents index either; you have to guess that it's under 'Links' in 
the Overview section as though it were on some external site...

I see I'm not the only one, and the person I just told about it couldn't find 
it either (which is why I asked).



m

  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Wednesday, May 17, 2023 11:58 AM
  Subject: Re: [M100] REXCPM





  On Wed, May 17, 2023, 7:39 AM MikeS  wrote:

Having a lot of trouble finding stuff in Bitchin100 these days...
Where's the order page for REXCPM?

m



  I went to the wiki, typed rex into the media wiki search bar and it showed a 
link to the ordering page for rex#


  And since bitchin100 is now indexed by Google and bing you can just search 
them for bitchin100 ordering rex and it takes you to the order page. 


  So seems findable?


  -- John

[M100] REXCPM

[MikeS]

Having a lot of trouble finding stuff in Bitchin100 these days...

Where's the order page for REXCPM?

m

Re: [M100] Any further info on TDock?

[MikeS]

Non-volatile storage, network connectivity and a bigger display are all easily 
possible right now with little or no hardware required; why add the complexity 
of using the system bus, especially the M100 (vs. T102) connector version.

The DVI uses the system bus and the cabling has always been a big PITA; some of 
the various memory expansion etc. projects do use some of the signals on the 
bus as needed, as well as the system and option ROM sockets.

m
  - Original Message - 
  From: mark audacity romberg 
  To: m100@lists.bitchin100.com 
  Sent: Tuesday, May 09, 2023 6:03 PM
  Subject: Re: [M100] Any further info on TDock?


What do you want it to do?
MVT100 exists. https://bitchin100.com/wiki/index.php?title=VT100

  I'm aware of MVT, neat little project, but not really what I'm looking for.


  I am mainly interested in non-volatile storage and network connectivity, 
whether that's the host machine backing up the M100's files or the M100 being 
presented with a modem emulator. TRS-Box type functionality would be ideal. A 
bigger display would be nice, but is somewhat secondary for me.


  I don't see a reason to mess with the cassette port, BCR port, or serial port 
when the computer has the system bus exposed...and for exactly this purpose. In 
fact, I'm a little surprised that nobody has built any projects (that I'm aware 
of) that use the system bus. Seems ripe for experimentation, since it gives 
direct access to the CPU.z

  Side question: what kind of bandwidth is the system bus capable of? I can't 
find any information on that specifically.

  mark audacity romberg
  mark.romb...@gmail.com

Re: [M100] Adding Gotek to T100 Disk Video Interface

[MikeS]

>I’m no expert when it comes to using the DVI, I had a play about with it and 
>really enjoyed the fact I could write with a proper display connected.

You mean like this?



That's an old game display (xbox 360?) clamped on to my M100 back in the day, 
with an extended cable going back to the DVI.

>One question I must ask, how easy is it to read the contents of the disk 
>images on a regular pc? If say I wrote a document and wanted to access it on 
>my laptop, is that possible?

I always meant to look into that but never got around to it; apart from the 
novelty I really only used the DVI for the display and just loaded/saved the 
usual RS232 way. But there were quite a few parameter-driven format conversion 
programs around in the old days to deal with the hundreds if not thousands of 
different 'standards'  used by the various manufacturers, so I'd be surprised 
if it couldn't be done; maybe someone on here has in fact already done it.

Enjoy!

m



- Original Message - 
  From: james.z...@gmail.com 
  To: m...@bitchin100.com 
  Sent: Tuesday, May 09, 2023 3:17 PM
  Subject: Re: [M100] Adding Gotek to T100 Disk Video Interface


  Hey


  Just been reading this. My DVI is currently in storage, but I’ve been meaning 
to bring it out and swap the US PSU inside with a 240v unit I bought a while 
back.


  I’m no expert when it comes to using the DVI, I had a play about with it and 
really enjoyed the fact I could write with a proper display connected.



  One question I must ask, how easy is it to read the contents of the disk 
images on a regular pc? If say I wrote a document and wanted to access it on my 
laptop, is that possible?




  Many thanks! And great job getting your gotek to work, this has inspired me 
to do the same 





  Sent from my iPad


On 8 May 2023, at 4:21 pm, Gary Wilkinson  wrote:


 No, I think it was my fault. I missed out the “ [m100dvi]” you listed at 
the start of the FF.CFG file on your email Josh.  
I’m currently making a couple of blank images now to hold saved data & 
basic program. Thanks again for your help!


Sent from my iPhone


  On 8 May 2023, at 15:53, Josh Malone  wrote:


   
  I suspect the issue may be cskew=1 which is missing from my CFG. Grimakis 
is also using interface=shugart (vs. mine using 'ibmpc') so that will require 
the different drive number jumpering (effectively swapping 1 and 0 -- LFILES 0 
might have worked)



  Yeah, everyone should use Grimakis's files and ignore what I posted :)


  -Josh


  On Mon, May 8, 2023 at 10:45 AM Gary Wilkinson  
wrote:

Success 


I copied the CFG files from Grimakis GitHub and they worked!! I’ll now 
puzzle back and see what I had missed in my original CFG files, but for now I’m 
really delighted to have it working. Thanks guys for all the help!!


Sent from my iPhone


  On 8 May 2023, at 15:37, Gary Wilkinson  
wrote:


   I checked my CFG files and they match and I made sure to keep the 
file name the same on the img file you provided, but I’m still getting an 
error. 


  When I just have the Gotek drive installed I get the error “In Drive0 
is NOT a SYSTEM DISKETTE”


  If I configure the Gotek as drive 1 and boot from the floppy, I’m ok 
until I try and do a directory of drive 1 (LFILES 1) and then I get the error 
“?AT Error”


  Puzzling 


  Sent from my iPhone


On 8 May 2023, at 14:51, Josh Malone  wrote:


 
On Mon, May 8, 2023 at 7:42 AM Gary Wilkinson 
 wrote:

  Hi Josh! It was your YouTube video that inspired me to try this! 
I asked a question in the comments, but I think you use a streaming service and 
so must have missed it. I’ve been updating my comments as I go along so others 
have an idea how to set this up. Thanks for the initial  inspiration and for 
responding in here :)



Ah, yes - The "Amigos" folks re-post (with my permission) many of 
my live Twitch streams to YT and, of course, I don't get notified of comments 
there. I should probably come up with a way to fix that.


-Josh 

Re: [M100] Variable Concordance

[MikeS]

Yeah, that's what I was suggesting, mainly for legibility; importing into Excel 
would be a bonus

m

- Original Message - 
From: "Bert Put" 
To: 
Sent: Thursday, May 04, 2023 6:41 PM
Subject: Re: [M100] Variable Concordance


> You might consider using tabs instead of spaces; Excel can import 
> tab-delimited files just like comma-delimited, and they are still fairly 
> readable.  Just make sure you have only one tab between columns.  It 
> might mess up your spacing a bit. Just a thought.
> 
> Regards,Bert
> 
> 
> On 5/3/23 17:28, lloydel...@comcast.net wrote:
>> Peter,
>> 
>> I had pondered doing something like you suggested. I also thought about 
>> making everything separated by commas so it would import into Excel. I 
>> finally settled with keeping it simple and doing spaces.

Re: [M100] Variable Concordance

[MikeS]

I think the 'type' could be misleading since it could be redefined with a DEF 
statement; probably better to put that in the comments later if necessary.

Maybe the references could be in columns; most of the cross-references I use do 
that and it does seem to make it a little easier to read...

But it's pretty good as is!

m
  - Original Message - 
  From: Peter Noeth 
  To: Model 100 Discussion 
  Sent: Wednesday, May 03, 2023 5:59 PM
  Subject: Re: [M100] Variable Concordance


  A good idea, but since the program runs under Windows, why such a cryptic 
output?


  Wouldn't it be easier to use with more verbose column headers:


  Variable   Type  Defined in Line Used in Lines
  Comments
  
-
  B%   Integer0  1, 7(2)

  C  Double1  2(3), 4, 
5(2)
  E  Double1  7(5)
  .
  .
  .


  The Comments column label would be generated, but used later when the output 
file is edited to add notes about the variable usage, etc. This would make a 
good start to proper program documentation.


  Of course, since the source was provided, changes could easily be made :-)


  Regards,
  Peter 




  On Tue, May 2, 2023 at 1:15 PM  wrote:

--

Message: 1
Date: Mon, 1 May 2023 15:31:48 -0500
From: 
To: 
Subject: [M100] Variable Concordance - MTVarConcor
Message-ID: <000401d97c6b$f4e9acc0$debd0640$@comcast.net>
Content-Type: text/plain; charset="utf-8"

Hello all,



I?ve written a variable concordance program for Windows that will take a 
TRS-80 Model 100 BASIC program and will list the variables in alphabetical 
order with the line numbers where they appear.The name of this program is 
MTVarConcor.   The executable, source and a pdf file describing it can be found 
at www.GitHub.com/LEJ-Projects/MTVarConcor 
 .



As an example, the 10 line program, drop (written by David Plass) is as 
follows:



0 
CLS:POKE-902,PEEK(63795):F=.25+RND(1)/4:W=-.25+RND(1)/2:X=0:Y=1:B%=5+25*RND(1) 

1 
C=0:PRINT@280+B%,CHR$(27)"V?"SPACE$(9-E)"?":PRINT@200,"S:"S:PRINT"L:"5-L:PRINTUSING"W:#.#";W

2 C=C+F:PRINT@C," ??":IFX<>0THENPRINT@OX+40*OY%," 
":OX=X:OY%=Y:Y=Y+.3:X=X+W:GOTO6 

4 IFINKEY$=" "THENX=C+2:F=F*2:OX=0:OY%=0 

5 IFC>=37THENPRINT@37," ":C=0:GOTO2ELSE2 

6 IFY<7.01THENPRINT@X+40*FIX(Y),"?":GOTO4 

7 
IFX>=B%+1ANDX<=B%+10-ETHENPRINT@97,"Hit!":CALL4811:S=S+10*(E+1):E=E-(E<8):GOTO0 

8 L=L+1:IFL<5THENPRINT@97,"MISS!":CALL4811:GOTO0ELSEPRINT@55,"Game over":END



The output from MTVarConcor when the above program is the input is:



B% 0 1 7(2) 

C 1 2(3) 4 5(2) 

E 1 7(5) 

F 0 2 4(2) 

L 1 8(3) 

OX 2(2) 4 

OY% 2(2) 4 

S 1 7(2) 

W 0 1 2 

X 0 2(4) 4 6 7(2) 

Y 0 2(3) 6(2)



I hope someone will find this program useful.

Lloyd

Re: [M100] Variable Concordance - MTVarConcor

[MikeS]

- Original Message - 
From: "Joshua O'Keefe" 
To: 
Sent: Monday, May 01, 2023 8:57 PM
Subject: Re: [M100] Variable Concordance - MTVarConcor


> On May 1, 2023, at 5:03 PM, Mike Stein  wrote:
> 
> It worked fine on the test program; FYI, attached is the program it died on.
> 
I was able to reproduce the crash and ran it through gdb.

The last line of your "Eliza.bas" file seems to make line 100 of the code very 
unhappy.
It seems to be an 0x1a character and then a bunch of question marks.

If you delete that line of the input file, the program is parsed successfully.=
---
Right you are! The EOF problem; I should have looked a little more carefully.

Thanks for the tip, and thanks to Lloyd for the program (and Mtlineref) !

m

Re: [M100] Recognize this cable?

[MikeS]

I'm sure you're right; it's almost identical to the cable used by an IBM 
ethernet II adapter but there's an extra tiny bump that prevents it from going 
into the socket.

All my PCMCIA modems use different connectors so I think I can toss this cable 
with a clear conscience ;-)

Thanks again,

m
  - Original Message - 
  From: Brian Brindle 
  To: m...@bitchin100.com 
  Sent: Thursday, April 20, 2023 1:57 PM
  Subject: Re: [M100] Recognize this cable?


  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

[M100] Recognize this cable?

[MikeS]

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] MTLineRef - Resending

[MikeS]

Np; I was smart enough to understand what you meant ;-)

BTW, I tried it with 32-bit Win7 and it wouldn't run ("Not compatible with that 
version of Windows)...

m
  - Original Message - 
  From: lloydel...@comcast.net 
  To: m...@bitchin100.com 
  Sent: Monday, April 10, 2023 5:57 AM
  Subject: [M100] MTLineRef - Resending


  Here is what I meant to send.   Sorry about the poorly worded previous email.

   

  Good morning to all:

   

  I've written a Windows Console program in C that will take a TRS-80 Model 100 
BASIC program and will list the line number and first ten characters of each 
line that is referenced by another line. It will also list the line numbers 
that reference it.

  The program can be found at www.GitHub.com/LEJ-Projects/MTLineRef.

   

  I hope that someone finds this useful.

  Lloyd

   

   

Re: [M100] Removing DVI Disk Basic

[MikeS]

What and where is SWITCH.DSK?

- Original Message - 
From: "Brian K. White" 
To: 
Sent: Thursday, March 02, 2023 10:33 AM
Subject: Re: [M100] Removing DVI Disk Basic


> Ah, and SWITCH.DSK must be what I thought I remembered seeing before 
> about switching between dvi and other.
> 
> 
> On 3/2/23 10:29, Brian K. White wrote:
>> See L-DVI.100
>> 
>> On 3/2/23 10:18, grima...@gmail.com wrote:
>>> Just tried out BOOT.BA  and it works pretty well. Only 
>>> thing I don't love about it, is that you need to re-enter the 
>>> Time/Date after removing Disk-BASIC.
>>>
>>> I think I'm going to modify it to store the current date/time in 
>>> ALTLCD before clearing the ram, as I think that location ought to be 
>>> protected.
>>>
>>> -George
>>>
>>> On Thu, Mar 2, 2023 at 9:48 AM Brian K. White >> > wrote:
>>>
>>> I never noticed that, but I just tried it and you're right, the dvi
>>> needs the system disk on every power-on, not just for installation.
>>>
>>> -- bkw
>>>
>>> On 3/2/23 09:20, grima...@gmail.com  
>>> wrote:
>>> > I guess the need to pack the Disk BASIC away is pretty limited,
>>> since
>>> > when the DVI starts up, it loads software into it's RAM from the
>>> system
>>> > disk, the same disk which you can use to load Disk BASIC to the
>>> M100. So
>>> > even if you were to pack and reload Disk BASIC, the DVI will be
>>> useless
>>> > without the system disk. (unless there is a way to load the DVI
>>> software
>>> > into the DVI from the System Bus connector of the M100.)
>>> >
>>> > That would be great if possible, you could bootstrap a DVI
>>> without the
>>> > original disk.
>>> >
>>> > -George
>>> >
>>> > On Thu, Mar 2, 2023 at 9:11 AM Brian K. White
>>> mailto:b.kenyo...@gmail.com>
>>> > >> 
>>> wrote:
>>> >
>>> > On 3/2/23 07:37, grima...@gmail.com
>>>  >> > wrote:
>>> > > Hi Brian,
>>> > >
>>> > > Just reading the descriptions in your link and they seem 
>>> to be
>>> > exactly
>>> > > what I need.
>>> >
>>> > Looks like also D100.BA  >> > and DISABL.DVI
>>> >
>>> > I would have sworn I saw directions in the user manual, but I
>>> don't see
>>> > anything like that now.
>>> >
>>> > There may be yet other programs or texts elsewhere in the 
>>> m100sig
>>> > besides these too.
>>> >
>>> > I thought I saw some that don't just unload the dvi software
>>> but pack
>>> > it away for restoring later, and did the same for other
>>> dosses like for
>>> > chipmunk or tpdd, and let you flip back & forth between them.
>>> >
>>> > Here's something cool, search the entire m100sig using the 
>>> search
>>> > box on
>>> > github:
>>> >
>>> >
>>> 
>>> https://github.com/LivingM100SIG/Living_M100SIG/search?q=Disk%2FVideo 
>>>  
>>> >> >
>>> >
>>> > Whoa Nelly!
>>> >
>>> > --
>>> > bkw
>>> >
>>>
>>> -- bkw
>>>
>> 
> 
> -- 
> bkw

Re: [M100] - Backpack

[MikeS]

I wondered how you discriminated; clever!
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Thursday, March 02, 2023 1:20 PM
  Subject: Re: [M100] - Backpack


  "you would only have tokenized files on the M100 itself"


  Or cassette files, tpdd files, xmodem'd BA files tsdos sending to desklink, 
etc. ;-)


  But I think I know what you mean. It is mostly a closed system until you 
start transferring to a foreign host. Then you can stub your toe on this 
problem.


  One question is, could it have been solved on the tsdos side? I guess not.  
IIRC the distinguishing characteristics are at the end of a proper tokenized 
file versus text file since there are nuls (or not). 


  If you're going to detect it and take steps it has to happen on the host. 


  Which is where I addressed it in LaddieAlpha. 


  Even there, there are multiple ways to do it. I fix the presented extension. 
Another way would be to hide the bad file or give an error on open or read. 


  -- John. 

Re: [M100] - Backpack

[MikeS]

Well, I count a cassette or TPDD (or the DVI for that matter) as part of the 
stock 'closed' M100 system, with  TELCOM only able to transfer plaintext files 
in and out; xmodem and DLplus changed that and that's where the trouble started.

Back in the day it was never an issue; everything was ASCII text except for the 
.BA programs running or stored in the M100 system.

When I dug out my M100 many years later, lo and behold there were now lots of 
binary .CO and .BA files out there, but how to load them into the M100? Xmodem 
was one obvious answer, but how to load it in the first place? 

So, many thanks to Ron Wiesen (R.I.P.) and Traveling Software for the 
self-installing TEENY and DeskLink combo; that opened the door to lots of other 
stuff including TS-DOS etc.

A quite different environment these days thanks to all the innovative folks 
who've contributed over the last 40 years...

m


  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Thursday, March 02, 2023 1:20 PM
  Subject: Re: [M100] - Backpack


  "you would only have tokenized files on the M100 itself"


  Or cassette files, tpdd files, xmodem'd BA files tsdos sending to desklink, 
etc. ;-)


  But I think I know what you mean. It is mostly a closed system until you 
start transferring to a foreign host. Then you can stub your toe on this 
problem.


  One question is, could it have been solved on the tsdos side? I guess not.  
IIRC the distinguishing characteristics are at the end of a proper tokenized 
file versus text file since there are nuls (or not). 


  If you're going to detect it and take steps it has to happen on the host. 


  Which is where I addressed it in LaddieAlpha. 


  Even there, there are multiple ways to do it. I fix the presented extension. 
Another way would be to hide the bad file or give an error on open or read. 


  -- John. 

Re: [M100] Removing DVI Disk Basic

[MikeS]

- Original Message - 
From: "Brian K. White" 
To: 
Sent: Thursday, March 02, 2023 9:06 AM
Subject: Re: [M100] Removing DVI Disk Basic


> I would have sworn I saw directions in the user manual, but I don't see 
> anything like that now.
> 
 
You may be thinking of that notice you posted; it was an insert supplied with 
the DVI.

Re: [M100] VIDEO - Dial-A-ROM for the Model T computers (and others)

[MikeS]

Is there an XR4 manual anywhere by any chance?

m
  - Original Message - 
  From: Stephen Adolph 
  To: m...@bitchin100.com 
  Sent: Sunday, February 26, 2023 1:37 PM
  Subject: Re: [M100] VIDEO - Dial-A-ROM for the Model T computers (and others)


  Mike,
  XR4 did not have any "protect the user from switching an installed ROM" 
functionality.
  It just hard-switched.  You can see that when you disassemble the utilities.

  I think it had a couple of flip flops on the flex-board that wrapped the RAM 
chip.
  But I can't say for sure.  I don't have an XR4.  I do have an XR1. aka EXTRAM.
  Steve







  On Sun, Feb 26, 2023 at 12:22 PM Mike Stein  wrote:

Jeff,


Is there a way to reserve a DaR or BP for whenever they become available 
again?


Also if/when I order one of each will the shipping be combined?


TIA,


m



On Sun, Feb 26, 2023 at 8:32 AM  wrote:

  I’ll be doing a video on it eventually. It is quite a complex little 
beasty, need to take some time and really learn how to use it.



  Jeff Birt



  From: M100  On Behalf Of Daniel L
  Sent: Sunday, February 26, 2023 3:44 AM
  To: m100@lists.bitchin100.com
  Subject: Re: [M100] VIDEO - Dial-A-ROM for the Model T computers (and 
others)



  Good video Jeff. Anyone have a demo for that weather tracker? Looks DOPE

  On 2/25/23 07:31, bir...@soigeneris.com wrote:

Morning all,

I just made this video live this AM. The DARs for the Model T computers 
have sold out already but my friend is making more. 

In this video we take a look at the ‘Dial-A-ROM’ a spiffy new multi-ROM 
for vintage portable computers. It was designed by the same guy who did the 
Backpack drive. First, we’ll learn how to use the Dial-A-ROM with the ROM 
images that come preinstalled on it. Then we’ll see how to add our own ROM 
images if we so desire.

https://youtu.be/CejyLsI0HIw

Jeff Birt (Hey Birt!)

Re: [M100] - Text Sweet 2.3 Release

[MikeS]

Is that tokenizer Bob Pigford's version? AFAIK it was the latest and best of 
the various versions out there.

m
  - Original Message - 
  From: grima...@gmail.com 
  To: m...@bitchin100.com 
  Sent: Monday, February 27, 2023 7:42 AM
  Subject: Re: [M100] - Text Sweet 2.3 Release


  Thanks for the feedback!


  I’ll try to look into that line terminator business and see whats going on.


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


  Then you could tie it in with github actions to tokenize, pack, and commit 
the .DO and BA.


  Best I could find was an old EXE tokenizer meant to run on older version of 
Windows.


  Best,
  George


  On Sun, Feb 26, 2023 at 10:20 PM Stephen Adolph  wrote:

hey works great!!!
thanks George. I'm using my (updated!) MVT100 Desktop terminal emulator to 
play Tsweep!


steve



On Sun, Feb 26, 2023 at 6:02 PM grima...@gmail.com  
wrote:

  Hi Steve,


  I updated it again. I think I accidentally uploaded the wrong file 
initially.


  https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.2


  https://imgur.com/a/JyLsAdX


  I’ve linked photos of how it renders on a real DVI. The above is how I 
have intended it to look.


  Let me know if you’re getting the same results with your program.


  Re: ASCII not loading cleanly. I’ve been experiencing issues when loading 
the ASCII as .BA in Virtual T. However, if I load it as .DO first and then use 
BASIC to tokenize it (either in Virtual T or real hardware), it works fine.


  Not sure if perhaps there is a bug in Virtual T or not.


  -George


  On Sun, Feb 26, 2023 at 5:08 PM Stephen Adolph  
wrote:

thanks George.
I loaded it (.BA version, the .DO version won't load clean.


Runs, but the controls are on top of the bottom half of the board.  

but I can see it coming together!
cheers and thanks
Steve



On Sun, Feb 26, 2023 at 4:41 PM grima...@gmail.com  
wrote:

  Hi Steve,


  https://github.com/Grimakis/TextSweeper/releases/tag/2.5.1-beta.1


  I just put together a pre-release of 2.5.1, which I have tested 
against the original DVI hardware and it works now in both 40 col and 80 col 
mode. Feel free to check it out with your DVI Work Alike solution, and let me 
know what you think.


  Best,
  George


  On Sun, Feb 26, 2023 at 3:10 PM Stephen Adolph  
wrote:


yes, 

I have done a lot of work on making an external 80column video 
solution that is a  "DVI work alike" accessible without actually having a DVI.


First you need some driver software on the M100.
1) VT100 driver - found here --> 
https://bitchin100.com/wiki/index.php?title=VT100
or
2) via REX#/REXCPM.


To actually show video on an external monitor, the driver software 
treats Screen1 as RS-232 and Screen2 as serial via a hardware hack to the BCR 
port.   So, an external serial terminal can be used to show the video info.


Then you need a solution for serial terminal.
There are 2
1)  MVT100 video adapter, based on the Geoff VT100 serial terminal 
board --> https://bitchin100.com/wiki/index.php?title=VT100 
or
2) the MVT100 windows application found here --> 
http://club100.org/memfiles/index.php?direction===Steve%20Adolph/MVT100%20for%20PC;


Anyhow, I find external video quite nice to have but I never 
appreciated the DVI much myself.  Had 2, sold them both.








On Sun, Feb 26, 2023 at 2:50 PM grima...@gmail.com 
 wrote:

  I see, when you say your DVI software do you mean the software 
that emulates the DVI itself?


  Modifying the print statements is definitely doable, and I can 
add that to my TODOs.


  However, as someone who uses the DVI, I personally do like the 40 
column mode. Being able to switch between 40 and 80 col on demand is useful in 
my opinion. Very similar to how the Apple II works: 40col is just more legible 
in a lot of situations.


  -George 


  On Sun, Feb 26, 2023 at 2:42 PM Stephen Adolph 
 wrote:

my stuff doesn't support 40 columns.  that's why I was asking!
To me, 40 column mode on the DVI seems silly, but that's just 
me.


Anyways, if you don't want to adapt the print@ statements, I 
get it.
thanks anyways.




On Sun, Feb 26, 2023 at 2:40 PM grima...@gmail.com 
 wrote:

  I think the way I would prefer to handle it would be to check 
the initial setting of 40/80 when the program starts, switch the screen to 40, 
and then switch back on exit.


  Do you know is there a way to switch to 40 columns 

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

[MikeS]

Looks gorgeous!

  - Original Message - 
  From: Philip Avery 
  To: m...@bitchin100.com 
  Sent: Saturday, February 25, 2023 3:35 PM
  Subject: Re: [M100] M100 LCD repair video and alternative use for unused 
screen RAM


  Correct Mike, a 1950 Land Rover. This one:



  Philip


  On 26/02/2023 8:07 am, MikeS wrote:

 
Knowing Philip, more likely a Land Rover or a Jeep ;-)

  - Original Message - 
  From: B 9 
  To: m...@bitchin100.com 
  Sent: Saturday, February 25, 2023 4:01 AM
  Subject: Re: [M100] M100 LCD repair video and alternative use for unused 
screen RAM




  On Fri, Feb 24, 2023 at 1:21 PM Philip Avery  wrote:

My excuse is I was commissioned to 
do a vintage vehicle restoration which has soaked up all my spare time 
for the last 2-years. 


  Vintage vehicles are fun, too. This wouldn't happen to have been a Model 
T, would it?



The good news is I'm almost complete & I expect 
within a few months to get my vintage computing time back & be able to 
resolve any M100 CP/M issues & add new features...


  Yay! 



  —b9

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

[MikeS]

Knowing Philip, more likely a Land Rover or a Jeep ;-)

  - Original Message - 
  From: B 9 
  To: m...@bitchin100.com 
  Sent: Saturday, February 25, 2023 4:01 AM
  Subject: Re: [M100] M100 LCD repair video and alternative use for unused 
screen RAM




  On Fri, Feb 24, 2023 at 1:21 PM Philip Avery  wrote:

My excuse is I was commissioned to 
do a vintage vehicle restoration which has soaked up all my spare time 
for the last 2-years. 


  Vintage vehicles are fun, too. This wouldn't happen to have been a Model T, 
would it?



The good news is I'm almost complete & I expect 
within a few months to get my vintage computing time back & be able to 
resolve any M100 CP/M issues & add new features...


  Yay! 



  —b9

Re: [M100] R2.2 update for REX# and REXCPM

[MikeS]

Many computers including the M100 use the unique American standard MM/DD/YY 
while most of the world uses DD/MM/YY; apparently a few countries like Iran, 
China etc. use the international (SA) standard /MM/DD.

In Canada most folks use the American MM/DD/YY; just to keep it interesting my 
driver's licence uses /MM/DD while some banks use DD/MM/. 

FWIW, personally I use MM/DD/YY and agree that using the same format as the 
system is probably the least confusing. Assuming that international versions of 
the M100 also use MM/DD/YY, presumably folks in Europe and elsewhere have 
already gotten used to the DATE$ format.

m

- Original Message - 
From: 
To: 
Sent: Tuesday, January 31, 2023 10:35 AM
Subject: Re: [M100] R2.2 update for REX# and REXCPM


I agree with Brian, consistency with the system that can't be changed is 
probably the best.  At least there is consistency (even if it is confusing to 
someone used to MMDD).

Jonathan

>Original Message
>From : b.kenyo...@gmail.com
>Date : 2023-01-31 - 10:41 (CEST)
>To : m100@lists.bitchin100.com
>Subject : Re: [M100] R2.2 update for REX# and REXCPM
>
>Cosistency with the rest of the system which can't be changed is 
>definitely a legit point. Thanks for clarifying.
>
>-- 
>bkw
>
>On 1/31/23 03:03, Cedric Amand wrote:
>> As I'm the one who started the date debate :) let me clarify what my 
>> feedback to Steve was
>> In the context of my M200, there are multiple things that are 
>> confusing with dates,
>> First of I consider that the system time, the one reported by print 
>> DATE$ , should define the date format, otherwise you end up with 
>> multiple date formats.
>> As such, REX uses a different format than the system one (on my system, 
>> idk about everyone else's)
>> I fully realize rex is probably written in machine language, that nobody 
>> asks for internationalisation or user settings, all my feedback was is 
>> that it's using a different date format than the system here, which is 
>> confusing ( can you tell me what the date is when system date 
>> is 21/12/22 and REX date 222112 ? )
>> You end up with not only one but two ambiguous date formats.
>> I also remember an hidden part of REX (I think info on file in the tsdos 
>> part ?) uses yet another format, but I can't replicate this this morning 
>> as my tpdd is buried in a box.
>> More than that, and this is new feedback, when saving a new RAM image or 
>> overwriting one, REX does not update the DAY of the date, only the month 
>> and the year. I've reproduced that today.
>> I realize that out of context, this "date format" is a small 
>> problem, REX is now used internationally, and there are basically two 
>> Model T platforms (EU and US).
>> For my M102 I switched the ROM to the US one. Quite frankly - this 
>> creates more problem than it solves. But it makes REX work.
>> For my M200, with the help of Steve, I was able to keep my EU ROM and 
>> have REX working no problem, which is great for the international users.
>> In short, without interfering with anyone else's REX :) if it would be 
>> possible that REX displays it's file dates then same way the system 
>> does, that'd be great :)
>> Le 2023-01-31 08:32, jonathan.y...@telia.com  a 
>> écrit :
>> 
>> For what it's worth, I also like year month day dates, in part because I 
>> can easily sort them.  ISO 8601 specifies year, month, date, but it looks 
>> like the years are 4 digits
>> 
>
>-- 
>bkw
>
>

Re: [M100] Subjective poll on M100 "dialob box"

[MikeS]

OK, I've crossed the floor; left it is!

(Never thought I'd hear me say that... ;-)

m


- Original Message - 
From: "Ken Pettit" 
To: 
Sent: Monday, January 09, 2023 9:31 PM
Subject: Re: [M100] Subjective poll on M100 "dialob box"


> 
> On 1/9/23 5:25 PM, Daryl Tester wrote:
>> On 10/1/23 11:34, Brian K. White wrote:
>>
>>
>> This.  For me, the left is easier to initially pick out, but the right 
>> has "spacing"
>> between the outer box/title and inner text (between the "Options" 
>> title and the
>> first "Prog Mode" item).
> 
> Okay, how about the attached version?  It insets the left / right 
> borders from the outer text by 1/2 character width and adds an extra 
> space to the interior content of the box to compensate.  I think this 
> one looks better.
> 
> Ken
>

Re: [M100] Subjective poll on M100 "dialob box"

[MikeS]

RH Dialob box for me, pls; doesn't stand out as much but definitely neater and 
that is a rather unusual background after all

m

- Original Message - 
From: "Ken Pettit" 
To: 
Sent: Monday, January 09, 2023 7:44 PM
Subject: [M100] Subjective poll on M100 "dialob box"


> Hey gang,
> 
> I'm curious which of the two "dialog box" options people think look 
> better between the two shown in the attached diagram.  These were coded 
> up in BASIC, but I'm thinking of using it in an ASM program.
> 
> Ken
>

Re: [M100] M100 Audio / music

[MikeS]

There's quite a bit of 1-bit music out there for the PC, PET and other systems 
that only had a speaker, some of it remarkably good; should be possible to use 
similar techniques and even the same sound files on the M100.

Re MIDI: there was a project years ago to use an M100 as a MIDI sequencer; IIRC 
the baud rate was 'close enough'. I cobbled together an interface for a 
proof-of-concept and it seemed to work OK; never went beyond that though ;-(

m

- Original Message - 
From: "Ken Pettit" 
To: "Model 100 Discussion" 
Sent: Wednesday, December 28, 2022 3:59 PM
Subject: [M100] M100 Audio / music


> Hey gang,
> 
> I was trying to use the Linux based tools I wrote to create something a 
> little more advanced than WCCARD.BA.  It turns out getting the M100 to 
> orchestrate a piece that is a bit more expressive is more challenging 
> than just entering the notes from sheet music.  It's pretty amazing how 
> much interpretation an artist imparts that isn't on the page when 
> actually playing / performing!
> 
> Seems like to get a similar affect, I would need to extend my little 
> sheet music parser to include expressive components in addition to just 
> raw notes.  Makes me wonder how programmers developed music for the M100 
> back in the day when the M100 was the only computer they were using.
> 
> Ken

Re: [M100] New article on the Bitchin100 wiki... peeking Option ROM Space

[MikeS]

Great article, especially for learning different techniques.

A few years back I needed some extra RAM for a small database so I cobbled 
together a poor man's REX; just a 32K RAM chip piggybacked on the system ROM 
with a couple of flying leads for /WE, /CE etc.

Functionally it's a clone of EME's ExtRAM, compatible with all its tools and 
utilities to load/save/dump/swap/etc. memory, load & save files and, yes, PEEK 
and POKE the OptROM memory space.

As the database grew I started on a 4MB bank switched version along the lines 
of the XR4 but then Steve came out with the 4MB CP/M device; in the end I 
finally moved it to a PC anyway ;-)

m


  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Thursday, December 22, 2022 3:37 AM
  Subject: [M100] New article on the Bitchin100 wiki... peeking Option ROM Space


  I wrote up an article on PEEKing an Option ROM from a BASIC program based on 
a question that came up on Facebook.


  Well, really most of the article is about how to embed ML subroutines as 
strings in your program.


  
https://bitchin100.com/wiki/index.php?title=Peeking_the_Option_ROM_From_a_BASIC_Program



  -- John.

Re: [M100] DETOKE100.exe

[MikeS]

Looks like you've been looking since 2019:
https://www.mail-archive.com/m100@lists.bitchin100.com/msg08871.html

The answer is in the next message (SIG Lib08); of course it's probably not as 
good as yours...

m
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Thursday, December 22, 2022 3:50 PM
  Subject: [M100] DETOKE100.exe


  I wrote a 100/102 detokenizer last night because I needed one and couldn't 
find one. Probably I didn't look hard enough, I'm sure there are others!


  The emulators can do the job generally, but they would only pop an error and 
give up. DETOKE100 doesn't care, it just decodes :-)


  You can download from my personal library at Club100. I tested it on Windows 
and Linux.


  
http://club100.org/memfiles/index.php?=0==John%20Hogerhuis/Utilities



  If you find a file it doesn't work on or you need a feature added, let me 
know.


  -- John.

Re: [M100] TS-DOS Option ROM

[MikeS]

Yeah, the Club100 web site could certainly use a little update... ;-)

Meanwhile as noted, you'll find everything you need at Bitchin100.com.

You can't beat the price and utility of the REX, but before it became readily 
available some folks just replaced the system ROM with a 27C512 holding the 
system ROM plus a ROM image like TS-DOS, a socket, a couple of diodes and a 
resistor. That does preclude any other option ROMs in its socket however and 
only works for late model M100s using a JEDEC-standard 27256-compatible socket.

m
  - Original Message - 
  From: Wayne Lorentz 
  To: m...@bitchin100.com 
  Sent: Sunday, December 18, 2022 5:43 PM
  Subject: Re: [M100] TS-DOS Option ROM


  I thought about the REX#, but it looks discontinued.  There aren't any links 
on that page to order anything, and no contact information.   Not even a name.  
Super sketchy. 


  If I was going to get a REX, I'd get the CP/M version, as I'm a CP/M 
enthusiast. But $100 is more than I can do this close to Christmas. That's why 
I thought if I could find a TS-DOS chip, it might be cheap enough to tide me 
over. 


  I recently bought one of those Backpack SD card storage devices. The TS-DOS 
option ROM will work with that, right?



  —
  iPhoneから送信


On Dec 18, 2022, at 9:27 AM, Brian White  wrote:



I'd suggest get a REX#, which comes with ts-dos pre-loaded.
http://www.bitchin100.com/wiki/index.php?title=REX



You could build a plain rom with only ts-dos,
http://tandy.wiki/Teeprom
but it ends up costing almost the same as a REX# anyway plus more work.

--  

bkw

Re: [M100] Pinenut Wifi / BLE

[MikeS]

Good catch; yeah, if that baud rate can't be changed it's a non-starter.
  - Original Message - 
  From: Ken Pettit 
  To: m100@lists.bitchin100.com 
  Sent: Saturday, December 17, 2022 9:29 AM
  Subject: Re: [M100] Pinenut Wifi / BLE


  Hi Hiraghm,

  Serial/UART baud rate: 115200 bps

  That would be an issue in the Model 100 ... the UART can't run that fast, and 
even if it could, the 8085 would never keep up with the data rate.  Nice little 
board though!

  Ken


  On 12/17/22 6:16 AM, Hiraghm wrote:

I came across this tiny little board on the Pine64 site, and I wonder...

PineNut Wifi/BLE board


this thing is about 1" by 2/3" (25 x 14mm), and as I understand it provides 
wifi and bluetooth, via serial (TTL or UART, I think).




I think it could be mounted internally to the M100 (dunno about M102). 
Maybe a 200, too.


IF one could connect it to the modem serial connection, one could then 
theoretically use it to connect via wifi/bluetooth, and switch to the external 
rs232 port, keeping its functionality, with a minimum of "destruction" to the 
M100.




Or maybe, connect it to the barcode scanner, which, if possible for regular 
comms with the module, would leave you able to use the rs232 and the wifi at 
the same time.




I'm interested in any opinions on this, because imo it could massively 
improve the functionality of the M100 (yes, I know the same essential thing is 
possible with some of the wifi-capable arduino boards, but all I've seen of 
them are much larger than this).

Re: [M100] Pinenut Wifi / BLE

[MikeS]

Some confusion there I think...

The M100's serial port is in fact 'true' RS232; the official spec is +/- 3-15V 
and the M100's +/- 5V is well within that spec.

But today most hobbyist 'RS232' serial devices are intended to interface 
directly to a microprocessor of some kind, so they use 'TTL' RS232 which is 0 
to Vcc (5V or 3.3V) (with the opposite polarity).

https://www.sparkfun.com/tutorials/215

0 to 5V would probably indeed 'not make it'  connected to the serial port on 
your M100 since 0V is in the undefined region between +3V and -3V and it's 
'upside down, but connecting internally should be straight forward since the 
M100 is 'TTL RS232' internally (although you'd still need to shift  the voltage 
levels from 3.3 to 5V).

Aside from that I see no reason why the Pinenut module would not work; 
presumably you could even patch the ROM to change the 'M' default baud rate etc.

I've been meaning to do the same thing with a BT module instead of WiFi but 
just reaching for an external RS232-BT module is just sooo convenient..

m

 
  From: jonathan.y...@telia.com 
  To: m...@bitchin100.com 
  Sent: Saturday, December 17, 2022 9:39 AM
  Subject: Re: [M100] Pinenut Wifi / BLE


  Hello,


  I'm not sure that thing will hook up to a real RS-232.  I looked at the 
schematic and it talked about 3.3 v, which would not drive the RS-232 lines.   
Not sure how you would connect it. But maybe there is a level shifter in it.  
I've found that a lot of things talk about RS 232 but it is things like 0 to 
3.3 or 0 to 5 volts, and not even close to real RS 232.  I know the M100 
doesn't actually get there either, but I know 0 to 5 volts doesn't make it on 
my M100.



  I had been looking at this device, in part for a Psion 5 MX but it also for 
my M100 as well.  A 'hat' stuck on top of a Raspberry Pi zero W, plus a power 
supply.  Admittedly most of the work would be done by the Pi (the tcp/ip stack 
etc.) but you could use a terminal program to access a little linux box.  It 
was self-contained, even with a battery!!  I still have to figure out where to 
buy that level-shifter (the SP3232EEP) but most hats I've looked at for the pi 
zero w don't have hardware handshaking.



  https://www.kianryan.co.uk/2022-11-28-psion-sidecar-ppp-modem-and-terminal/


  Admittedly, this is probably to big to fit in an M100 but I am pretty sure it 
would work.  Increase the size of the battery and power the M100 with it!!



  Jonathan



Original Message
From : hira...@hotmail.com
Date : 2022-12-17 - 15:16 (CEST)
To : m100@lists.bitchin100.com
Subject : [M100] Pinenut Wifi / BLE


I came across this tiny little board on the Pine64 site, and I wonder...

PineNut Wifi/BLE board


this thing is about 1" by 2/3" (25 x 14mm), and as I understand it provides 
wifi and bluetooth, via serial (TTL or UART, I think).




I think it could be mounted internally to the M100 (dunno about M102). 
Maybe a 200, too.


IF one could connect it to the modem serial connection, one could then 
theoretically use it to connect via wifi/bluetooth, and switch to the external 
rs232 port, keeping its functionality, with a minimum of "destruction" to the 
M100.




Or maybe, connect it to the barcode scanner, which, if possible for regular 
comms with the module, would leave you able to use the rs232 and the wifi at 
the same time.




I'm interested in any opinions on this, because imo it could massively 
improve the functionality of the M100 (yes, I know the same essential thing is 
possible with some of the wifi-capable arduino boards, but all I've seen of 
them are much larger than this).

[M100] OT:Sony Clie

[MikeS]

Any Palm collectors out there want a Sony Clie?

m

Re: [M100] custom key mapping generator for Tandy 200

[MikeS]

Bonjour, Cedric,

If possible, I would try to get a chip from a different manufacturer. 

Even during normal programming people have found subtle differences among 
brands in the behaviour of some pins, especially /PGM (pin 27 in this case), 
and since this is a non-standard undefined use it's possible that what works 
with one will be unreliable with another.

Maybe also try to find a 120ns -12 version while you're at it.

m
  - Original Message - 
  From: Cedric Amand 
  To: m...@bitchin100.com 
  Sent: Saturday, November 19, 2022 6:56 AM
  Subject: Re: [M100] custom key mapping generator for Tandy 200


  Currently, I've been trying to replace my main 32KB ROM with a ST M27C256A-100
  This works.

  And I've been trying to replace the 8KB with a ST M27C64A-150
  This does not work for me. The system freezes after seconds, then becomes 
completely unusable to the point even the power button (or a hard reset) does 
nothing, screen displays garbage or just all black pixels

  I've ordered alternative parts, in case my 27C64 is marginal in some way, but 
the ROM reads and re-reads fine in a TL866, and it's a copy of the original ROM.

  I'm continuing my experiments when new parts arrive.


  Le 2022-11-19 01:19, Stephen Adolph  a écrit :
So, to recap, 

1.  We have a spreadsheet to create custom key maps for Tandy 200

2.  Separately, we are trying to confirm in hardware that a single 27C64 
rom can be substituted for M13, to implement the custom keymap.

I would encourage the approach for dealing with different keyboards on 
other machines.

Keep in mind.. if the actual characters themselves change, the modification 
is deeper.  Such is the case for M10 for example.  (Or just use the usa 
character set to make it easy).


Thanks
Steve

Re: [M100] custom key mapping generator for Tandy 200

[MikeS]

LOL!

" you went and remained the same MikeS as always. So by all means
refrain away in the future."

Some people seem to see a MikeS who generally tries to be friendly and helpful; 
maybe you can tell me off-list why you apparently see a different one.

Time to end this childish public exchange before we get a stern warning from 
John ;-)

m


  - Original Message - 
  From: Brian White 
  To: m...@bitchin100.com 
  Sent: Thursday, November 17, 2022 11:13 PM
  Subject: Re: [M100] custom key mapping generator for Tandy 200


  "We're never going to resolve this problem you have."


  -- 

  bkw


  On Thu, Nov 17, 2022, 10:34 PM Mike Stein  wrote:

And you too never disappoint ;-) Obviously you and I will never resolve 
whatever your problem is with me (and John?)



The discussion in question was indeed a total waste of time (as a few 
others in the past) and I think I'm entitled to choose how to spend my time; 
life's getting shorter all the time...



I rarely contribute anything anyway, certainly nothing that smarter folks 
won't also come up with, so as I said, I'll leave it up to them while I spend 
more time elsewhere; you've certainly contributed an impressive amount of 
knowledge and hardware to the community and I'll definitely continue to follow 
this list for useful information and just the sense of community.


m







On Thu, Nov 17, 2022 at 6:56 PM Brian K. White  wrote:

  On 11/17/22 16:23, MikeS wrote:

  > I think in future I'll refrain from wasting time

  Promise?
  I was ready to acknowledge and apologize because you're right, I didn't 
  really get that at first and did replicate something already said. But 
  then you went and remained the same MikeS as always. So by all means 
  refrain away in the future.

  -- 
  bkw

Re: [M100] custom key mapping generator for Tandy 200

[MikeS]

Congratulations on "solving the mystery".

Of course there never really was a mystery. 

I said as much , although not in so many words and without confusing the issue 
with irrelevant references to /WE and voltage levels and confusing Vpp with 
/PGM. It only needed confirmation by someone plugging in a 2764 that PGM 
overrides /OE, since it isn't defined in the datasheet, in case the particular 
unit in question had a different motherboard.

>From my posts:

"Pin 27 is the Program pin which looks like it might _effectively be an
active high OE_ (since there is no program voltage." and "if /OE and /PGM
disables data out then a 27C64 should work."

To which you replied that
"27C64 can't be used as-is", "pin 27, being /WE (/PGM), still needs to be held 
at VCC" etc.

To be followed by a tedious thread of me suggesting that someone with a 200 
actually try it, and you arguing at length that it couldn't work. Glad to see 
that you managed to solve the mystery all on your own.

I think in future I'll refrain from wasting time with technical comments and 
leave it to "experts" like you.

m

.






- Original Message - 
From: "Brian K. White" 
To: 
Sent: Thursday, November 17, 2022 1:30 PM
Subject: Re: [M100] custom key mapping generator for Tandy 200


> 
> 
> 
> On 11/14/22 11:47, Georg Käter wrote:
>> Hello together,
>> 
>> my Tandy 200 (European version, build in 1985) uses main PCB 
>> #-PLX178AHIX. This board accepts
>> 
>> standard UV-eraseable EPROM 27C256 (32kB) and 27C64 (8kB) 150ns type w/o 
>> any modification.
>> 
>> Maybe there are other revisions of PCB with different EPROM pinout I´m 
>> not aware of.
> 
> In a conversation off-list just now I think we just figured out why it 
> works.
> 
> I'll just describe verbally but to follow along and check the work, the 
> reference material you'll need are the service manual for 200 to get the 
> schematic for the 200, and the datasheets for HN61364, and 27C64. All 
> easily googled. And in the 200 schematic you're looking at the M13 and 
> M15 positions (top-right corner), and one gate on M29 that combines 2 
> signals into one pin on M15.
> 
> To start, all else being equal,
> * both chips get their /CS at the same time from the same /RD line from 
> the 200
> * both chips, (in a sense, if you count the OR gate on M29 as part of 
> M15) get their /OE at the same time from /BANK1 from the 200
> * A15 ends up interlocking the two chips so that when one is active the 
> other is inactive. When A15 is low, only M15 is enabled, and when A15 is 
> high only M13 is enabled. This assumes that the pin labelled /CE1 is 
> really an active high not an active low, and we CAN assume that, because 
> all other pins on both chips are not up for any kind of debate, they are 
> known and certain and not ambiguous. If pin 27 on M13 were actually 
> active-low, then both chips would be active at the same time.
> 
> (The pin names on M13 are a bit confising because for some reason the 
> 200 schematic labels the 3 OE pins as /CE0 /CE1 /CE2. But they are 
> really OE pins not CE pins. The /CE pin is /CS, and for this discussion 
> I'm calling the others /OE0, OE1, and /CE2. OE1 is really active-high so 
> that's yet another correction.)
> 
> So the tldr for the normal case with original parts is:
> A15 low=M15 high=M13
> 
> Now with a standard 27C64:
> * pin 1 is NC from the socket, which means VPP is floating. That is bad 
> in general, but you get away with it in this case because it's not a 
> normal input but a VPP that needs a much higher voltage than vcc or any 
> voltage  any other pin ever sees. Since no pin anywhere on the chip ever 
> sees anything outside the range of gnd to vcc, then a flapping input may 
> flap, but shouldn't be able to float any higher than vcc, and vcc is 
> just fine. Ideally we want that pin nailed to vcc even. It means we can 
> essentially ignore VPP, and ignore the write implications of /WE. We 
> can't ignore /WE, but we can ignore the *write* implications. It can 
> never write, regardless what state /WE is in, regardless what state any 
> other pins are in.
> * /OE has the same /BANK1 as the /OE on M15 (via M29)
> * A15 is on /WE
> 
> So, it's just down to answering: What happens when A15 is high, and when 
> it's low, when the states of the other pins are all VPP<=vcc, /CE low, 
> /OE low?
> 
> A15 low -> /WE low, which is technically undefined behavior being low at 
> the same time as /OE, but apparently overrides /OE and prevents output.
> /CE and /OE are both low so it wants to output data, but /WE blocks it, 
> and yet, /WE doesn't write either because of missing VPP.
> 
> And, that is what we happen to want. Above in the stock case, A15 low = 
> M13 disabled.
> 
> A15 high -> /WE disabled, /OE is low so the chip outputs, and again that 
> is what we want. Above, A15 high = M13 active.
> 
> So /WE without VPP is kind of being abused into acting as a secondary 
> active-high OE, which is what the HN61364 has explicitly 

Re: [M100] WP-2 and WP-3 conversion script

[MikeS]

FWIW, my WP-3 doesn't have a Citizen Watch copyright; just:
Copyright 1989 Something  Good Inc. V1.81
Copyright 1991 Microlytics Inc,Xerox V1.0

m

- Original Message - 
From: "Bert Put" 
To: 
Sent: Thursday, November 17, 2022 7:30 AM
Subject: Re: [M100] WP-2 and WP-3 conversion script


> Hi Brian,
> 
> Thank you for those hints -- both of those operations does reset the 
> machine.
> 
> All the messages show Copyright 1989:
> - No copyright version on the Citizen Watch CO. Ltd. line.
> - (C) Something Good Inc. V1.62
> - (C) Microlytics,UFO,Xerox V4.7
> 
> Thanks again, much appreciated.
> 
> Regards,Bert
> 
> 
> 
> On 11/15/22 18:00, Brian K. White wrote:
>> Reset pin, even just a tap not a long press, clears ram and shows some 
>> version numbers.
>> 
>> And I just discovered that Ctrl + F2 + Del appears to do exactly the 
>> same! Not only clears the current document and shows the same reset 
>> screen with version numbers, it clears ram including your system 
>> settings like the power-off time and the type of batteries.
>> 
>> Neither one clears the ramdisk though, as in the optional extra 32k or 
>> 128k chip that may or may not be installed inside.
>>

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

[MikeS]

It is indeed! Thank you!

 Original Message - 
  From: Henner Zeller 
  To: m...@bitchin100.com 
  Sent: Sunday, November 13, 2022 7:48 PM
  Subject: Re: [M100] TRS-80 Model 100 schematic transcribed to KiCAD


  On Sun, 13 Nov 2022 at 16:43, MikeS  wrote:

Yeah, that looks like quite the effort; thanks, Henner!

But I'm looking for that better scan of the original 'classic' schematic 
and it seems to no longer be at that location; any chance it's still available 
somewhere?


  Looks like it is here  
https://archive.org/details/trs-80-model-100-main-pcb-schematic-from-tech-ref-manual

TIA,

m
  - Original Message - 
  From: you got me 
  To: m...@bitchin100.com 
  Sent: Friday, July 29, 2022 11:23 PM
  Subject: Re: [M100] TRS-80 Model 100 schematic transcribed to KiCAD


  The job you did must have taken a loong time. Perhaps 
some people will be able to make a M100 kit in time for the 40th anniversary. 
Thank you for your hard work!


  You were saying that the schematics you had access to were hard to read? 
Years ago I made a scan of the schematic in what I considered to be 'high 
definition'. You may want to take a look at it.


  TRS-80 Model 100 Main PCB Schematic (from Tech Ref Manual).jpg


--

  From: M100  on behalf of Henner Zeller 

  Sent: Saturday, July 30, 2022 2:11 AM
  To: m100@lists.bitchin100.com 
  Subject: [M100] TRS-80 Model 100 schematic transcribed to KiCAD 

  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] TRS-80 Model 100 schematic transcribed to KiCAD

[MikeS]

Yeah, that looks like quite the effort; thanks, Henner!

But I'm looking for that better scan of the original 'classic' schematic and it 
seems to no longer be at that location; any chance it's still available 
somewhere?

TIA,

m
  - Original Message - 
  From: you got me 
  To: m...@bitchin100.com 
  Sent: Friday, July 29, 2022 11:23 PM
  Subject: Re: [M100] TRS-80 Model 100 schematic transcribed to KiCAD


  The job you did must have taken a loong time. Perhaps 
some people will be able to make a M100 kit in time for the 40th anniversary. 
Thank you for your hard work!


  You were saying that the schematics you had access to were hard to read? 
Years ago I made a scan of the schematic in what I considered to be 'high 
definition'. You may want to take a look at it.


  TRS-80 Model 100 Main PCB Schematic (from Tech Ref Manual).jpg


--

  From: M100  on behalf of Henner Zeller 

  Sent: Saturday, July 30, 2022 2:11 AM
  To: m100@lists.bitchin100.com 
  Subject: [M100] TRS-80 Model 100 schematic transcribed to KiCAD 

  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] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

Maybe I should have said that XON/XOFF is hit-and-miss depending on the 
hardware instead of 'unreliable' ;-) .

It's not always easy to know whether a particular setup will work or not; I've 
seen USB cables recommended that I couldn't get to work and, conversely, had no 
problems with others that supposedly did not.

FWIW, I normally also run at 19200bd but thought it would be safer to recommend 
9600 bd in this discussion since it usually works no matter what and makes very 
little difference in actual throughput.

Have you ever compared actual BASIC download speed at 9600 vs. 19200bd?

m

  - Original Message - 
  From: B 9 
  To: m...@bitchin100.com 
  Sent: Tuesday, November 01, 2022 3:33 AM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated




  On Mon, Oct 31, 2022 at 12:11 AM MikeS  wrote:
Reliable maximum download speeds on the M100 without handshaking are around:
BASIC: 600 bd to allow time to tokenize and store.
TERM: 2400 because of the slow LCD scrolling.
TEXT: 9600 since it does not display while loading.


  That sounds right when the other end does not have hardware-level XON/XOFF, 
but it should be much faster with a better UART on the PC, like an OX16C950 or 
a chip from FTDI or MOXA. As soon as the M100 sends XOFF, the UART chip in the 
serial port automatically stops the flow of data. No lag, no lost characters. I 
connect using 19,200 bps in BASIC (LOAD "COM:98N1ENN" ) and it works perfectly 
when I use certain USB serial adapters (and not others). 



  Has anyone with a Model 100 tried using a serial card or USB adapter that 
supports "automated in-band flow-control"? Do you see the same high-speed 
connection as I do on my Tandy 200?



  —b9

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

Sounds like what I do when I want separate versions and can't be bothered 
extracting the desired file from the main log. ;-)

On the PC using old venerable ProComm:

Save new version:
ESC:   terminates previous D/L
PgDn,7: selects new ASCII D/L
Enter version no.
Ready to receive next version, for save, restore, compare, whatever.
5 keystrokes

Restore previous version:
ESC: Get out of D/L mode.
PgUp,7:   select ASCII upload
Enter version number
'Enter' when the M100 is ready
5 keystrokes.

What can I say; if you're going to program on the M100 why not do it the way 
you could have done it in pre-Git and even pre-Windows days... No need to 
fumble with those newfangled mice either ;-)

One annoyance: It appears that BASIC does not send CR/LF so you have to enable 
that on the terminal. However, that now double-spaces 'normal' COM files so you 
either have to change the terminal settings or do your own CR/LFs.

(Unless someone has a better idea ?)

m
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Monday, October 31, 2022 4:30 PM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated






  On Sun, Oct 30, 2022 at 8:58 PM B 9  wrote:

On Sun, Oct 30, 2022 at 7:28 PM John R. Hogerhuis  wrote:

  You could always script it out to do a git commit after every ctrl-z


Sometimes, I don't know if you're joking or not... I mean, yes, that's 
brilliant and should work. But, oh boy. Once again, you've got my brain turning 
on completely needless, yet very cool ideas. ☺




  Wasn't joking... this time. 

  If you're going to keep a host-side running backup of a program you're 
working on in this way, might as well let the host side help you manage the 
versions. git will list out the versions and you can compare versions at will 
to see exactly what changed.


  Could be a useful workflow.

  The other way to do that is filesystems and backup agents that give you a 
time machine feature.


  -- John. 

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

In my rather verbose reply I probably didn't make it clear that there should be 
no problem uploading/saving to the server at 19,200bd; the issues are with 
downloading to the M100. I just keep it at 9600 because it isn't really much 
slower and I don't have to change baud rate on the server when I download a 
file.

m
  - Original Message - 
  From: B 9 
  To: m...@bitchin100.com 
  Sent: Sunday, October 30, 2022 9:54 PM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


  That sounds like a nice workflow. This ought to be in a FAQ of tips and hints 
for people new to the M100.



  I might just try it out. I'm pretty rigorous about using SAVE "COM:98N1ENN", 
but I have to tell my Unix box to receive the file each time (cp /dev/ttyUSB0 
foo.do). And every copy I save overwrites the previous one, unlike the natural 
history you'll have in your log file if you find you need to go back a few 
revisions. 



  One question though: why do you send at 9600 bps? I thought all Model T's 
could do 19,200bps.



  —b9



  On Sat, Oct 29, 2022 at 10:26 AM MikeS  wrote:

Hi Will,

Too many times I've made some changes and either accidentally deleted the 
file or messed it up so badly that I want to revert to the previous version, so 
I've learned the hard way that it's a good idea to save the work before making 
major changes.

One way is to SAVE it locally on the M100 as a .DO file ("Foo.do" or 
"Foo",A) , changing the name as appropriate; note that BASIC will save a file 
as .BA by default but will LOAD a .DO file without specifying the '.DO' or ',A' 
if no .BA file with the same file exists. Of course if it's a very large file 
you may not have room for both the .BA and .DO files in RAM at the same time.

What I do if I'm close enough to a PC to easily connect or stay connected 
is to open a file (e.g. "backup.txt") on the PC for ASCII text download with a 
terminal program and just leave it open.

On the M100 I've programmed F7 to 'Key 7, "COM:88N1E"', so when I want to 
save the file I'm working on I press F3 to save, F7 in response to 'Save "' and 
Return. It's a good idea to embed a version no. in the program and update it 
every time.

This concatenates all the saved files in one file; if you actually need to 
go back then you'd have to stop the transfer, edit the file on the PC and send 
it back to the M100. Of course you can open a new file on the PC every time if 
you don't mind typing on the PC every time.

To Load a .DO file from the PC, open TEXT, enter the File name, LOAD (F2) 
and enter 'COM:88N1E' in response to 'Load from:'; on the PC terminal program 
select Upload ASCII or whatever it's called and the file name (which does not 
have to be the same as on the M100). You may not see anything happening but the 
terminal program should indicate somehow when the transfer is finished. Type a 
CTL-Z on the PC and the file should appear on the M100; switch to BASIC and 
Load it, and Bob's your mother's brother.

This is mainly meant for folks who want to or have to just use the M100's 
built-in functions, and to show how to avoid overruns when Loading BASIC .DO 
programs as in a previous post here a few days ago.

Teeny, TS-DOS etc. certainly are very useful and in fact necessary if 
you're working with .BA tokenized files or Machine language code.

Other than my phone I'm not an Apple kind of guy, so I can't give any 
Mac-specific hints.

One other hint: to simplify switching from RUN to EDIT mode I've programmed 
'F6,"Edit"+chr$(13)'

Not too verbose, I hope...

m


  - Original Message - 
  From: Will Senn 
  To: m100@lists.bitchin100.com 
  Sent: Saturday, October 29, 2022 10:16 AM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it 
up appreciated


  Hi Mike,

  I'm curious about the COM stuff. In a later note you said:


  It's actually sorta been fun programming on the 'real' M100; I left a 
download running on the PC and every time I wanted to backup an interim version 
just in case, I just pressed F3 and F7 (which I'd programmed with the COM 
stats).

  and here, you say stuff about programming the function keys with 
"COM:88N1E"...

  It would be nice to be able to transfer / save from BASIC and/or my 
terminal on the Mac without the overhead of dl/TEENY.CO. I know enough to be 
dangerous and that the keys can easily be programmed to effectively type stuff. 
I'm just not clear on is how this works mechanically. Are you in BASIC, typing 
away, having just fixed some bit and are ready to SAVE it remotely, so you 
press F3 and voila, it just does it, or do you press F3 and then do something 
to get it transferring, or what?

  I have the cables hooked up and usually, I:
  1. SAVE from BASIC to .DO or .BA
  2. Start up DL on the Mac side, i

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

9






When uploading/saving from BASIC there doesn't seem to be much difference 
between 9600 and 19200, since it has to detokenize as it goes. Try it and see 
how it goes at 19200; TELCOM and text would probably be a little faster.



I've added an option to send the dump output to the com port; that seems to 
work fine at 19200.


BTW, I don't think we'll do much better than 34 seconds/50 lines; as I 
mentioned, LCD performance is pretty bad, especially scrolling.


For comparison, outputting to the com port halves the time to 17 seconds, 
and of course you can scroll, save and print that on your PC as well.


m



On Sun, Oct 30, 2022 at 9:54 PM B 9  wrote:

  That sounds like a nice workflow. This ought to be in a FAQ of tips and 
hints for people new to the M100.



  I might just try it out. I'm pretty rigorous about using SAVE 
"COM:98N1ENN", but I have to tell my Unix box to receive the file each time (cp 
/dev/ttyUSB0 foo.do). And every copy I save overwrites the previous one, unlike 
the natural history you'll have in your log file if you find you need to go 
back a few revisions. 



  One question though: why do you send at 9600 bps? I thought all Model T's 
could do 19,200bps.



  —b9



  On Sat, Oct 29, 2022 at 10:26 AM MikeS  wrote:

Hi Will,

Too many times I've made some changes and either accidentally deleted 
the file or messed it up so badly that I want to revert to the previous 
version, so I've learned the hard way that it's a good idea to save the work 
before making major changes.

One way is to SAVE it locally on the M100 as a .DO file ("Foo.do" or 
"Foo",A) , changing the name as appropriate; note that BASIC will save a file 
as .BA by default but will LOAD a .DO file without specifying the '.DO' or ',A' 
if no .BA file with the same file exists. Of course if it's a very large file 
you may not have room for both the .BA and .DO files in RAM at the same time.

What I do if I'm close enough to a PC to easily connect or stay 
connected is to open a file (e.g. "backup.txt") on the PC for ASCII text 
download with a terminal program and just leave it open.

On the M100 I've programmed F7 to 'Key 7, "COM:88N1E"', so when I want 
to save the file I'm working on I press F3 to save, F7 in response to 'Save "' 
and Return. It's a good idea to embed a version no. in the program and update 
it every time.

This concatenates all the saved files in one file; if you actually need 
to go back then you'd have to stop the transfer, edit the file on the PC and 
send it back to the M100. Of course you can open a new file on the PC every 
time if you don't mind typing on the PC every time.

To Load a .DO file from the PC, open TEXT, enter the File name, LOAD 
(F2) and enter 'COM:88N1E' in response to 'Load from:'; on the PC terminal 
program select Upload ASCII or whatever it's called and the file name (which 
does not have to be the same as on the M100). You may not see anything 
happening but the terminal program should indicate somehow when the transfer is 
finished. Type a CTL-Z on the PC and the file should appear on the M100; switch 
to BASIC and Load it, and Bob's your mother's brother.

This is mainly meant for folks who want to or have to just use the 
M100's built-in functions, and to show how to avoid overruns when Loading BASIC 
.DO programs as in a previous post here a few days ago.

Teeny, TS-DOS etc. certainly are very useful and in fact necessary if 
you're working with .BA tokenized files or Machine language code.

Other than my phone I'm not an Apple kind of guy, so I can't give any 
Mac-specific hints.

One other hint: to simplify switching from RUN to EDIT mode I've 
programmed 'F6,"Edit"+chr$(13)'

Not too verbose, I hope...

m


  - Original Message - 
  From: Will Senn 
  To: m100@lists.bitchin100.com 
  Sent: Saturday, October 29, 2022 10:16 AM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding 
it up appreciated


  Hi Mike,

  I'm curious about the COM stuff. In a later note you said:


  It's actually sorta been fun programming on the 'real' M100; I left a 
download running on the PC and every time I wanted to backup an interim version 
just in case, I just pressed F3 and F7 (which I'd programmed with the COM 
stats).

  and here, you say stuff about programming the function keys with 
"COM:88N1E"...

  It would be nice to be able to transfer / save from BASIC and/or my 
terminal on the Mac without the overhead of dl/TEENY.CO. I know enough to be 
dangerous and that the keys can easily be programmed to effectively type stuff. 
I'm just not clear on is how this works mechanically. Are you in BASIC, typing 
away, having just fixed some bit and are

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

I added a couple of options:
H:  Hexadecimal addresses
D:  Decimal addresses
L:   List on LCD
C:  List to COM port (for scrolling, saving, printing etc.)

Timings (seconds for 50 lines):
HL: 39 (As the previous version)
DL: 36
HC: 19
DC: 17

One last minute addition: the variable W in line 160 is the width, i.e. the 
number of bytes per line -1. Useful if you're listing on a terminal (e.g. 15 
will list 16 bytes)

No error checking; defaults are H and L as before.

Sorry; got a little carried away ;-) Try it; you'll like it! ;-)

m
-
1 DEFINTJ-Z:DIMH$(15):FORI=0TO15:REM V4
10 H$(I)=CHR$(48+I-(7*(I>9))):NEXT:CLS
15 GOSUB200:INPUT"From";A:INPUT"to";B
20 T$=TIME$: FORI=ATOBSTEPW+1
25 IFDTHENPRINT#1,USING"#";I;:PRINT#1,": ";:GOTO50
30 K=I/4096:PRINT#1,H$(K);
35 L=(I-K*4096):PRINT#1,H$(L\256);
40 PRINT#1,H$((LMOD256)\16)H$(LMOD16)" ";
50 L$="":FORJ=0TOW:X=PEEK(I+J)
55 PRINT#1,H$(X\16);H$(XMOD16)" ";
60 Y$=".":IFX>31ANDX<127THENY$=CHR$(X)
65 L$=L$+Y$:NEXT:PRINT#1,L$:NEXT
70 E$=TIME$:PRINT#1," "T$+" to "+E$
100 T=VAL(MID$(TIME$,4,2))*60+VAL(RIGHT$(TIME$,2))
110 R=VAL(MID$(T$,4,2))*60+VAL(RIGHT$(T$,2))
120 PRINT#1," "T-R" seconds":END
200 D$="H":INPUT"(H)EX or (D)ec address";D$
210 D=INSTR("dD",D$)>0:B$="88n1e":C$="L"
220 INPUT"(L)CD or (C)om output ";C$
230 IF INSTR("cC",C$)=0THENOPEN"LCD:"FOR OUTPUT AS 1:GOTO260
240 INPUT"Stat (88N1E)";B$
250 F$="COM:"+B$:OPENF$FOR OUTPUT AS 1
260 W=15:RETURN

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

This is the period-accurate pre-Git equivalent ;-)

We're doing it the hard way, without VirtualT, REX etc.; more fun that way ...

m
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Sunday, October 30, 2022 10:26 PM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


  You could always script it out to do a git commit after every ctrl-z


  -- John. 

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

Hi Will,

Too many times I've made some changes and either accidentally deleted the file 
or messed it up so badly that I want to revert to the previous version, so I've 
learned the hard way that it's a good idea to save the work before making major 
changes.

One way is to SAVE it locally on the M100 as a .DO file ("Foo.do" or "Foo",A) , 
changing the name as appropriate; note that BASIC will save a file as .BA by 
default but will LOAD a .DO file without specifying the '.DO' or ',A' if no .BA 
file with the same file exists. Of course if it's a very large file you may not 
have room for both the .BA and .DO files in RAM at the same time.

What I do if I'm close enough to a PC to easily connect or stay connected is to 
open a file (e.g. "backup.txt") on the PC for ASCII text download with a 
terminal program and just leave it open.

On the M100 I've programmed F7 to 'Key 7, "COM:88N1E"', so when I want to save 
the file I'm working on I press F3 to save, F7 in response to 'Save "' and 
Return. It's a good idea to embed a version no. in the program and update it 
every time.

This concatenates all the saved files in one file; if you actually need to go 
back then you'd have to stop the transfer, edit the file on the PC and send it 
back to the M100. Of course you can open a new file on the PC every time if you 
don't mind typing on the PC every time.

To Load a .DO file from the PC, open TEXT, enter the File name, LOAD (F2) and 
enter 'COM:88N1E' in response to 'Load from:'; on the PC terminal program 
select Upload ASCII or whatever it's called and the file name (which does not 
have to be the same as on the M100). You may not see anything happening but the 
terminal program should indicate somehow when the transfer is finished. Type a 
CTL-Z on the PC and the file should appear on the M100; switch to BASIC and 
Load it, and Bob's your mother's brother.

This is mainly meant for folks who want to or have to just use the M100's 
built-in functions, and to show how to avoid overruns when Loading BASIC .DO 
programs as in a previous post here a few days ago.

Teeny, TS-DOS etc. certainly are very useful and in fact necessary if you're 
working with .BA tokenized files or Machine language code.

Other than my phone I'm not an Apple kind of guy, so I can't give any 
Mac-specific hints.

One other hint: to simplify switching from RUN to EDIT mode I've programmed 
'F6,"Edit"+chr$(13)'

Not too verbose, I hope...

m


  - Original Message - 
  From: Will Senn 
  To: m100@lists.bitchin100.com 
  Sent: Saturday, October 29, 2022 10:16 AM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


  Hi Mike,

  I'm curious about the COM stuff. In a later note you said:


  It's actually sorta been fun programming on the 'real' M100; I left a 
download running on the PC and every time I wanted to backup an interim version 
just in case, I just pressed F3 and F7 (which I'd programmed with the COM 
stats).

  and here, you say stuff about programming the function keys with 
"COM:88N1E"...

  It would be nice to be able to transfer / save from BASIC and/or my terminal 
on the Mac without the overhead of dl/TEENY.CO. I know enough to be dangerous 
and that the keys can easily be programmed to effectively type stuff. I'm just 
not clear on is how this works mechanically. Are you in BASIC, typing away, 
having just fixed some bit and are ready to SAVE it remotely, so you press F3 
and voila, it just does it, or do you press F3 and then do something to get it 
transferring, or what?

  I have the cables hooked up and usually, I:
  1. SAVE from BASIC to .DO or .BA
  2. Start up DL on the Mac side, if it isn't already running in my ~/m100 
directory
  3. Press F8 to get menu
  4. Select TEENY.CO
  5. Type S HEXIT .DO
  6. Watch it complete without error (so long as HEXIT.DO doesn't already 
exist, I think) 

  What I'm imagining happen is:
  1. SAVE from BASIC to .DO or .BA
  2. Press F3
  3. Magically a file is sent and received on the Mac (where does it's name 
come from?)
  4. Celebration
  or
  1. F2 from BASIC
  2. Start sending a file (how?) from the Mac
  3. Celebration

  Just curious!

  Will



  On 10/28/22 12:30 PM, MikeS wrote:

 
Yeah, that's a setup I used for a while, sort of a poor man's 
tablet/clamshell 'convertible. ;-) No problem extending the cable to around 2 
feet.

Never did use the disk drives very much although I did install a second  
one; even today while playing with Will's dump program it's so simple to plug 
in the cable to the PC, select download or upload on the PC and either BASIC F3 
(SAVE) to com: or TEXT F2 (LOAD) from com:, not to mention being able to print 
on the PC and send/receive over the Internet.

Question for the experts: I have "COM:88N1E" stored in one of the BASIC 
function keys; I don't suppose there's a way to do that for TEXT?

Back 

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

Verbose ruminations? We doan need no steenkin' documentation!

Here's my latest (final?) version incorporating some of the ideas and hopefully 
a little less esoteric. Time to print 50 lines from 61 seconds down to 34, size 
from 635 bytes down to 406. Funny to watch it dump itself ;-)

BTW, just to repeat: LOADing from a PC using TEXT runs flawlessly at 9600bd 
whereas loading from BASIC definitely drops characters. 

It's actually sorta been fun programming on the 'real' M100; I left a download 
running on the PC and every time I wanted to backup an interim version just in 
case, I just pressed F3 and F7 (which I'd programmed with the COM stats).

As usual, constructive criticism welcome.

1 DEFINTJ-Z:DIMH$(15):FORI=0TO15:REM V3
10 H$(I)=CHR$(48+I-(7*(I>9))):NEXT:CLS
15 INPUT"From";A:INPUT"to";B:T$=TIME$
20 FORI=ATOBSTEP8:K=I/4096:PRINTH$(K);
25 L=(I-K*4096):PRINTH$(L\256);
30 PRINTH$((LMOD256)\16)H$(LMOD16)" ";
40 L$="":FORJ=0TO7:X=PEEK(I+J)
50 PRINTH$(X\16);H$(XMOD16)" ";
60 Y$=".":IFX>31ANDX<127THENY$=CHR$(X)
70 L$=L$+Y$:NEXT:PRINTL$:NEXT
80 E$=TIME$:PRINTT$+" to "+E$:END

-
 1 Initialize
10 Load H$( array with 1-F
15 Get range, start timer
20-30 Convert & print every 8th address
40 PEEK 8 bytes
50 Convert & print bytes
60 Replace invalid chars with '.'
70 Assemble and print text
80 Print elapsed time



  - Original Message - 
  From: Will Senn 
  To: m100@lists.bitchin100.com 
  Sent: Friday, October 28, 2022 1:54 PM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


  Oh yes, am I ever. A bit overwhelmed, actually. It'll take me a month to work 
through all of these suggestions and potential optimizations :). I suspected 
there were folks in the world who took BASIC to its edges, but I had no idea 
:). The thread on that weird listing a while back should have been a clue, but 
I thought it was a one-off. I'm in awe of y'all's grasp of the finer points and 
look forward to learning more. I tend to try to avoid the more esoteric 
optimizations in favor of clarity, but in this case, so long as I notate 
appropriately, I'll get over it! It seems like folks tend to move their more 
verbose ruminations out of the BASIC files and into accompanying .DO files, 
that about right?

  Thanks, 

  Will

  On 10/28/22 2:07 AM, MikeS wrote:

 
Thanks for that; I'll have to check it out later. Meanwhile, I think if 
we're going to use a lookup table at all then I also prefer your use of an 
array for H$, but I'd load it a little differently (as John and I were 
discussing):

5 DIM H$(15):FOR T=0 TO 15:H$(T)=CHR$(48+T-(7*(T>9))):NEXT

Tsk, tsk; you're cheating by inputting the range in decimal so you don't 
have to do a HEX to decimal conversion ;-) I suppose it makes sense though...

More serious, using integers for the addresses restricts the dump to 
<8000H; I had the same problem first time around.

Enjoying the thread... wonder if Will's getting anything out of it ;-)

m
  - Original Message - 
  From: B 9 
  To: m...@bitchin100.com 
  Sent: Thursday, October 27, 2022 11:38 PM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it 
up appreciated


  On Thu, Oct 27, 2022 at 3:04 PM John R. Hogerhuis  
wrote:



With hex it's a question though since MOD 16 can be done with AND 15 
which is probably faster than a general integer 16 modulus. There's no bitshift 
operator so you still need a integer divide by 16%. Who knows how efficient an 
integer divide by 16 is in the interpreter versus 4096 (integer) divides.  



  That's a good question about efficiency. Integer division by 4096 seems 
reasonably quick, but it would have been nice if BASIC had exposed the bit 
shift operators. (I'm presuming the 8085 had some, right?)



  I'm not sure it'd be any faster than division by 4096, but one could use 
the fact that we're using a 2-byte integer for the address and just look at 
each byte. 

  hexit.do
1 TS$=TIME$
5 DIM H$(15): FOR T=0 TO 9:H$(T)=CHR$(48+T): NEXT T: FOR T=ASC("A") TO 
ASC("F"): H$(T-55)=CHR$(T): NEXT
6 DIM R$(7): FOR T=0 TO 7: R$(T)=" ": NEXT
10 DEFINT A-F, P: D=0: P=VARPTR(D)
15 INPUT "Start"; ST%
16 INPUT "End"; EN%
20 FOR D=ST% TO EN%
30 IF (D MOD 8) = 0 THEN PRINT" ";: FOR T=0 TO 7: PRINT R$(T);: NEXT: PRINT: 
S=0: GOSUB 400
40 GOSUB 200
90 NEXT
100 REM Timing
110 TE$=TIME$
115 PRINT
120 PRINT TS$ " to " TE$
199 END
200 REM Print 2 hexits
201 ' Input: D is address of an 8-bit integer
202 ' Output: None, but 2 hexits are printed followed by a space
210 A=PEEK(D)
220 PRINT H$(A\16); H$(A MOD 16); " ";
230 IF A<32 THEN A=46
240 R$(S)=CHR$(A)
250 S=S+1
260 RETURN
400 REM Print 4 hexits
401 ' Input: P is address of a 16-bit little endi

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

Well, I'm still not convinced that there's an advantage in this case, although 
it does sound more suited to machine language. The only padding I had to  do 
(the way you describe) was to bring the HEX range user input values to a fixed 
4 digits, but I think as in B 9's example it probably makes more sense to input 
in decimal.

I think I'll leave the Forth version for another day ;-)

m
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Friday, October 28, 2022 5:52 PM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated






  On Thu, Oct 27, 2022 at 6:04 PM Mike Stein  wrote:

I don't see where it makes much difference In general in BASIC but in this 
case there is a justification for MSB first ;-)
It goes from MSB to LSB because the same routine does 4 or 2 digits 
depending on where you enter; line 5 gives the 4 digit address and it falls 
through to line 7 which also gives the 2 digit bytes peeked and creates the 
ASCII value for the text on the right hand side.


  The general idea is to do-while convert until you get to zero on the value 
being converted to string. So in reverse, you wouldn't need multiple entry 
points, it works for either 1-4 nibbles length.

  That leaves a question of zero-padding, but RIGHT$("000"+D$, 2 or 4) always 
works.


  FWIW, Forth's "pictured numeric output" is organized around this principle of 
LSB to MSB. It goes beyond radix conversions to support advanced number 
formatting like BASIC supports through PRINT USING. It probably helps that 
Forthers are used to doing everything backwards ;-)


  
https://www.jimbrooks.org/archive/programming/forth/forthPicturedNumericOutput.php



  Also of note for M100 specifically, MFORTH has a built-in DUMP word that can 
be compared for speed, though I actually don't know if that word is implemented 
in ML or threaded code. There's also an 8085 assembler for it, so it should 
make a nice environment for directly experimenting with machine code.


  -- John.




I suppose going the other way I'd always have to start at the beginning and 
return after two digits 'if' doing peeks instead of addresses; more complicated 
IMO.


m




On Thu, Oct 27, 2022 at 6:04 PM John R. Hogerhuis  wrote:





  On Thu, Oct 27, 2022 at 1:10 PM MikeS  wrote:

More good tips, thanks. Yes, I have to look at defining the various 
types, especially the ones that can go above 32768.

Concatenation with '+' is a habit from other languages I've worked 
with; as a matter of fact in most cases the M100 lets you print without any 
separators at all, e.g. print A$" to "B$ or a"plus"b

Interesting discussion (at least for some of us ;-) )



  One overall thing in outputting numbers in any radix, is that it is 
*usually* most tractable in reverse of how you output since we generally 
write/read numbers with the most significant digit first. So for generating a 
number to output, It is most efficient to extract the least significant digit, 
shift or otherwise divide by the radix, prepend the extracted number onto a 
string/buffer, and when the value gets to zero, you're done, output the string.


  So for the number 1235 in decimal,


  1235 MOD 10 = 5. Prepend ASC('0') + 5 on buffer. Divide remaining value 
by 10
  123 MOD 10 = 3. Prepend  ASC('0') + 3 on buffer.  Divide remaining value 
by 10
  12 MOD 10 = 2.  Prepend  ASC('0') + 2 on buffer.  Divide remaining value 
by 10
  1 MOD 10 = 1. Prepend  ASC('0') + 1 on buffer. Divide remaining value by 
10
  Remaining value is 0, so we're done. Buffer contains the number  

  In your subroutine at 5 it is doing it MSB to LSB, I think. Overall your 
way may still be faster in BASIC even with the larger divisors.

  With hex it's a question though since MOD 16 can be done with AND 15 
which is probably faster than a general integer 16 modulus. There's no bitshift 
operator so you still need a integer divide by 16%. Who knows how efficient an 
integer divide by 16 is in the interpreter versus 4096 (integer) divides.  


  -- John.

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

Yeah, that's a setup I used for a while, sort of a poor man's tablet/clamshell 
'convertible. ;-) No problem extending the cable to around 2 feet.

Never did use the disk drives very much although I did install a second  one; 
even today while playing with Will's dump program it's so simple to plug in the 
cable to the PC, select download or upload on the PC and either BASIC F3 (SAVE) 
to com: or TEXT F2 (LOAD) from com:, not to mention being able to print on the 
PC and send/receive over the Internet.

Question for the experts: I have "COM:88N1E" stored in one of the BASIC 
function keys; I don't suppose there's a way to do that for TEXT?

Back in the day IIRC the DVI and the M100 were both around $800; probably still 
have the receipts somewhere; don't know what that'd be today..

And yes, the Model T and NEC BASICs are remarkably versatile, especially 
considering the size constraints.

Definitely unique and, I don't know, friendly in a way...

m

  - Original Message - 
  From: B 9 
  To: m...@bitchin100.com 
  Sent: Friday, October 28, 2022 12:39 AM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated






  On Thu, Oct 27, 2022 at 8:51 AM MikeS  wrote:

 It might not be so bad on a 200 but my main annoyance is having to scroll 
up and down on the M100's 8 line screen; as a matter of fact the larger screen 
was the main reason I bought a DVI when they came out.


  When they came out? I wonder if they were more expensive when they were new 
or now that they are rare and "vintage". Is that a picture of your Disk/Video 
Interface setup? Looks nifty!


 For a lot of stuff in the old days I actually used GWBASIC or TBASIC to 
program on a PC; except for screen printing and graphics they're almost 
completely compatible and with a few conditional lines many programs could be 
run and tested on both the PC and the M100.


  There's something I didn't know! I've been surprised at how capable the Model 
T's 8-bit BASIC is. Was it the last one Microsoft made? Given what I had 
expected after seeing the Apple ][ and C64, it's quite a bit more advanced. 
(For example, ON COM GOSUB). And I read that the NEC 8201A version of the DVI 
allowed not only color graphics, but extended the BASIC language with graphics 
commands that I think may be from GW-BASIC.


 I can understand that some folks want to relive the total experience of 
doing everything on the old hardware [...]


  Sure, and there's nothing wrong with reliving the past. But, that's not me. I 
didn't get to experience the M100 when it was current. This is my first time 
around with this technology, so part of the fun is trying to see what it was 
like back then. I know, it's sort of like people who go camping for a week to 
get in touch with their primitive hunter-gatherer ancestors. Not likely to be 
terribly accurate, but still, it's fun.


Nevertheless, for just noodling around while relaxing on the couch not much 
can beat the M100.


  I'm beginning to learn that! I still haven't got a true Model 100. I only 
have a Tandy 200 because my neighbor was throwing it away and wondered if I 
could use "an old laptop".  I had no idea what it was. But, given my 
experiences so far, maybe I should look into getting the real thing some day.



  —b9

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

Thanks for that; I'll have to check it out later. Meanwhile, I think if we're 
going to use a lookup table at all then I also prefer your use of an array for 
H$, but I'd load it a little differently (as John and I were discussing):

5 DIM H$(15):FOR T=0 TO 15:H$(T)=CHR$(48+T-(7*(T>9))):NEXT

Tsk, tsk; you're cheating by inputting the range in decimal so you don't have 
to do a HEX to decimal conversion ;-) I suppose it makes sense though...

More serious, using integers for the addresses restricts the dump to <8000H; I 
had the same problem first time around.

Enjoying the thread... wonder if Will's getting anything out of it ;-)

m
  - Original Message - 
  From: B 9 
  To: m...@bitchin100.com 
  Sent: Thursday, October 27, 2022 11:38 PM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


  On Thu, Oct 27, 2022 at 3:04 PM John R. Hogerhuis  wrote:



With hex it's a question though since MOD 16 can be done with AND 15 which 
is probably faster than a general integer 16 modulus. There's no bitshift 
operator so you still need a integer divide by 16%. Who knows how efficient an 
integer divide by 16 is in the interpreter versus 4096 (integer) divides.  



  That's a good question about efficiency. Integer division by 4096 seems 
reasonably quick, but it would have been nice if BASIC had exposed the bit 
shift operators. (I'm presuming the 8085 had some, right?)



  I'm not sure it'd be any faster than division by 4096, but one could use the 
fact that we're using a 2-byte integer for the address and just look at each 
byte. 

  hexit.do
1 TS$=TIME$
5 DIM H$(15): FOR T=0 TO 9:H$(T)=CHR$(48+T): NEXT T: FOR T=ASC("A") TO 
ASC("F"): H$(T-55)=CHR$(T): NEXT
6 DIM R$(7): FOR T=0 TO 7: R$(T)=" ": NEXT
10 DEFINT A-F, P: D=0: P=VARPTR(D)
15 INPUT "Start"; ST%
16 INPUT "End"; EN%
20 FOR D=ST% TO EN%
30 IF (D MOD 8) = 0 THEN PRINT" ";: FOR T=0 TO 7: PRINT R$(T);: NEXT: PRINT: 
S=0: GOSUB 400
40 GOSUB 200
90 NEXT
100 REM Timing
110 TE$=TIME$
115 PRINT
120 PRINT TS$ " to " TE$
199 END
200 REM Print 2 hexits
201 ' Input: D is address of an 8-bit integer
202 ' Output: None, but 2 hexits are printed followed by a space
210 A=PEEK(D)
220 PRINT H$(A\16); H$(A MOD 16); " ";
230 IF A<32 THEN A=46
240 R$(S)=CHR$(A)
250 S=S+1
260 RETURN
400 REM Print 4 hexits
401 ' Input: P is address of a 16-bit little endian integer
402 ' Output: None, but 4 hexits are printed followed by a space
410 A=PEEK(P+1): B=PEEK(P)
420 PRINT H$(A\16); H$(A MOD 16); H$(B\16); H$(B MOD 16); " ";
430 RETURN

--

  —b9

Re: [M100] Compute a 16-bit signed value in BASIC

[MikeS]

Yeah, i try to avoid IF..THEN wherever I can, especially if it requires an 
extra line.

It does give some strange-looking code though, like line 40 in the HEX to 
decimal conversion in my dump program that conditionally converts the from/to 
address digits to upper case if necessary by subtracting 32 (a simple AND 95 
would probably have been simpler ;-) )

Convert up to 4 HEX digits in X$ to decimal equivalent in X:

20 X=0:X$=RIGHT$(""+X$,4)
30 FORI=1TO4:Y=ASC(MID$(X$,I,1))
40 Y$=CHR$(Y+(Y>95)*32)
50 L=INSTR(1,H,Y$)-1:X=X+L*(16^(4-I))

  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Thursday, October 27, 2022 5:19 PM
  Subject: Re: [M100] Compute a 16-bit signed value in BASIC


  I was curious if loading a string pointer could be done without an explicit 
IF.


  Seems like what we're doing is J as LSB, K as MSB

  K>127: J + K*256-65536
  or
  K<=127: J + K*256 - 0


  Taking J + K * 256 - 65536


  factoring out 256 and putting both functions in a similar form:

  K > 127: J + 256 ( K - 256)
  K <= 127: J + 256 ( K - 0 )

  Knowing comparisons can be done without 'IF'... if an expression is true you 
get -1 and 0 if false, we can inline the conditional into the expression 

  So the computation without IF would be

  J + 256% * ( K + 256% * (K > 127%))

  So something like this:

  10 DEFINTP:DEFSTRH
  20 H=CHR$(201)
  30 P=VARPTR(H)+1
  1000 P=PEEK(P)+256%*(PEEK(P+1)+256%*(PEEK(P+1)>127))
  1010 PRINTP


  Not sure if this works, particularly with the integer constants. And there 
might be speed optimizations... certainly it is doing the MSB peek twice.


  -- John.

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

More good tips, thanks. Yes, I have to look at defining the various types, 
especially the ones that can go above 32768.

Concatenation with '+' is a habit from other languages I've worked with; as a 
matter of fact in most cases the M100 lets you print without any separators at 
all, e.g. print A$" to "B$ or a"plus"b

Interesting discussion (at least for some of us ;-) )

m
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Thursday, October 27, 2022 3:39 PM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated





  On Thu, Oct 27, 2022, 12:14 PM MikeS  wrote:

Good tips.

DEFINT a-z reduced the time to print 50 lines from 61 seconds to 51

I'd also forgotten about integer division; that reduced it another 4 
seconds to 47.

Any more ideas?

m


  Seems like you can declare constants in expressions as integers? So 4096 
would be 4096% I guess.


  I haven't experimented much with it but it might prevent copies, casts, 
intermediate calculations from going to double precision floats..


  And I don't know if there's much difference but you added two strings that 
were being printed. It might be faster to use ; instead of + since it doesn't 
do a intermediate string copy. 


  -- John. 

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

Good tips.

DEFINT a-z reduced the time to print 50 lines from 61 seconds to 51

I'd also forgotten about integer division; that reduced it another 4 seconds to 
47.

Any more ideas?

m
  - Original Message - 
  From: B 9 
  To: m...@bitchin100.com 
  Sent: Thursday, October 27, 2022 1:16 AM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


  You can get a small (~15%) speedup just by doing this:


  0 DEFINT A-D, L, X, Y


  —b9



  On Wed, Oct 26, 2022 at 8:46 PM MikeS  wrote:

Oops; looks like I forgot to attach my version last night; good thing, 
found a couple of bugs tonight.

Looks like it could be speeded up a bit; no error checking.

I'd forgotten what a PITA it was to program on the real hardware.

1 DEFSTRH:H="0123456789ABCDEF":GOTO100
5 A=INT(X/4096):X=X-A*4096:B=INT(X/256)
6 PRINTMID$(H$,A+1,1)+MID$(H$,B+1,1);
7 C=INT((XMOD256)/16):D=XMOD16:Y=C*16+D
8 PRINTMID$(H,C+1,1)+MID$(H,D+1,1)+" ";
9 RETURN
20 X=0:X$=RIGHT$(""+X$,4)
30 FORI=1TO4:Y=ASC(MID$(X$,I,1))
40 Y$=CHR$(Y+(Y>95)*32)
50 L=INSTR(1,H,Y$)-1:X=X+L*(16^(4-I))
60 NEXT:RETURN
100 INPUT"From";S$:INPUT"to";E$
110 X$=S$:GOSUB20:S=X
120 X$=E$:GOSUB20:E=X
200 B$=TIME$:FORI=STOESTEP8:X=I:GOSUB5
210 L$="":FORJ=0TO7:X=PEEK(I+J):GOSUB7
220 Y=C*16+D
230 Y$=".":IFY>31ANDY<127THENY$=CHR$(Y)
240 L$=L$+Y$:NEXT:PRINTL$:NEXT
250 PRINTB$+" to "+TIME$:END

Constructive criticism welcome.

m

- Original Message - 
From: "runrin" 
To: 
Sent: Wednesday, October 26, 2022 10:24 PM
Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


> this seemed fun so i gave it a quick try. here's what i came up with.
> 
> it's a shame you can't do bitshift operations because i suspect
> ``((V AND 240) >> 4)'' would be faster than using integer division.
> 
> i'm a total neophyte when it comes to basic so i don't think this code
> is actually very fast. at least it's faster than the screen scrolls :P.
> in both examples i'm just peeking 0-59 since it's what fits on the
> screen nicely. that's also the reason for the "  ".
> 
> i like this version because it makes the print statement easy to read,
> it takes a lot more memory to store each character as it's own string
> though.
> 
> 10 DATA "0","1","2","3","4","5","6","7","8","9","A","B","C","D","E","F"
> 20 DIM H$(15)
> 30 FOR I = 0 TO 15
> 40 READ H$(I)
> 50 NEXT
> 60 FOR I = 0 to 59
> 70 V = PEEK(I)
> 80 PRINT H$(V \ 16); H$(V AND 15); "  ";
> 90 NEXT
> 
> ---
> 
> i made another version that uses string pointers because i felt bad
> using 16 strings. the PEEKS seem to be pretty expensive though, so i
> think it's actually slower than the previous version, but the code is a
> bit clearer. using MID$ is probably faster, but i mostly just did this
> for fun. this is more along the lines of how i would do something like
> this in C, which is the language i'm most familiar with.
> 
> string pointers are weird in basic. the pointer returned by VARPTR(S$)
> points to the following:
> 
> ptr + 0 = string length
> ptr + 1 = low byte of pointer to string
> ptr + 2 = high byte of pointer to string
> 
> i had to look in the basic language lab (pp. 182) to find that
> information. it's not even listed on
> https://help.ayra.ch/trs80-reference . i think i would have preferred
> if it just returned the string pointer with null terminator lol. not
> sure why they did it this way. anyway, here's the code:
> 
> 10 H$ = "0123456789ABCDEF"
> 20 P = VARPTR(H$)
> 30 SP = PEEK(P + 1) + PEEK(P + 2) * 256
> 40 FOR I = 0 TO 59
> 50 V = PEEK(I)
> 60 PRINT CHR$(PEEK(SP + (V \ 16))); CHR$(PEEK(SP + (V AND 15))); "  ";
> 70 NEXT
> 
> i know those extra spaces make my code slower, i'm just formatting it
> that way here so its actually legible.
> 
> -runrin

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

Hi,

It might not be so bad on a 200 but my main annoyance is having to scroll up 
and down on the M100's 8 line screen; as a matter of fact the larger screen was 
the main reason I bought a DVI when they came out.

The keyboard is definitely better than most laptops but I prefer a good solid 
desktop keyboard; IMO programming on a modern PC is just so much faster and 
smoother in general. I haven't used it much but Virtual T has to be the perfect 
compromise. 

For a lot of stuff in the old days I actually used GWBASIC or TBASIC to program 
on a PC; except for screen printing and graphics they're almost completely 
compatible and with a few conditional lines many programs could be run and 
tested on both the PC and the M100.

I can understand that some folks want to relive the total experience of doing 
everything on the old hardware but personally I prefer to use whatever's 
fastest, most convenient, has the most options etc.

Nevertheless, for just noodling around while relaxing on the couch not much can 
beat the M100.

m



 
  - Original Message - 
  From: B 9 
  To: m...@bitchin100.com 
  Sent: Thursday, October 27, 2022 12:45 AM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


  I'm curious what you've found the biggest PITA about programming on real 
hardware has been? I've been directly programming on my Tandy 200 and maybe 
it's just because my expectations were so low, but it's actually surprisingly 
nice. 16 lines of text is a good enough window. The arrow keys on the T200 are 
easy to use (and make sensible jumps with SHIFT and CTRL). Even so, just for 
fun I've been trying to learn what all the CTRL keys do. (I heard that it was 
vaguely WordStar like, but I never used that.) My biggest problem with coding 
on the T200 right now is that I am low on memory, so I can only EDIT small 
chunks of the program at a time.All in all, though, quite fun!



  —b9



  On Wed, Oct 26, 2022 at 8:46 PM MikeS  wrote:

Oops; looks like I forgot to attach my version last night; good thing, 
found a couple of bugs tonight.

Looks like it could be speeded up a bit; no error checking.

I'd forgotten what a PITA it was to program on the real hardware.

1 DEFSTRH:H="0123456789ABCDEF":GOTO100
5 A=INT(X/4096):X=X-A*4096:B=INT(X/256)
6 PRINTMID$(H$,A+1,1)+MID$(H$,B+1,1);
7 C=INT((XMOD256)/16):D=XMOD16:Y=C*16+D
8 PRINTMID$(H,C+1,1)+MID$(H,D+1,1)+" ";
9 RETURN
20 X=0:X$=RIGHT$(""+X$,4)
30 FORI=1TO4:Y=ASC(MID$(X$,I,1))
40 Y$=CHR$(Y+(Y>95)*32)
50 L=INSTR(1,H,Y$)-1:X=X+L*(16^(4-I))
60 NEXT:RETURN
100 INPUT"From";S$:INPUT"to";E$
110 X$=S$:GOSUB20:S=X
120 X$=E$:GOSUB20:E=X
200 B$=TIME$:FORI=STOESTEP8:X=I:GOSUB5
210 L$="":FORJ=0TO7:X=PEEK(I+J):GOSUB7
220 Y=C*16+D
230 Y$=".":IFY>31ANDY<127THENY$=CHR$(Y)
240 L$=L$+Y$:NEXT:PRINTL$:NEXT
250 PRINTB$+" to "+TIME$:END

Constructive criticism welcome.

m

- Original Message - 
From: "runrin" 
To: 
Sent: Wednesday, October 26, 2022 10:24 PM
Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


> this seemed fun so i gave it a quick try. here's what i came up with.
> 
> it's a shame you can't do bitshift operations because i suspect
> ``((V AND 240) >> 4)'' would be faster than using integer division.
> 
> i'm a total neophyte when it comes to basic so i don't think this code
> is actually very fast. at least it's faster than the screen scrolls :P.
> in both examples i'm just peeking 0-59 since it's what fits on the
> screen nicely. that's also the reason for the "  ".
> 
> i like this version because it makes the print statement easy to read,
> it takes a lot more memory to store each character as it's own string
> though.
> 
> 10 DATA "0","1","2","3","4","5","6","7","8","9","A","B","C","D","E","F"
> 20 DIM H$(15)
> 30 FOR I = 0 TO 15
> 40 READ H$(I)
> 50 NEXT
> 60 FOR I = 0 to 59
> 70 V = PEEK(I)
> 80 PRINT H$(V \ 16); H$(V AND 15); "  ";
> 90 NEXT
> 
> ---
> 
> i made another version that uses string pointers because i felt bad
> using 16 strings. the PEEKS seem to be pretty expensive though, so i
> think it's actually slower than the previous version, but the code is a
> bit clearer. using MID$ is probably faster, but i mostly just did this
> for fun. this is more along the lines of how i would do something like
> this in C, which is the language i'm most familiar 

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

Thanks; that was on my mental list of possible speedups. Speaking of, I ran 
into the same signed integer issue as John, i.e. MOD can only deal with values 
up to 32768.

What you say about GOTO and GOSUB is interesting; that suggests that they 
should always be forward references as opposed to being close to the beginning. 
Further research is indicated ;-)

m
  - Original Message - 
  From: B 9 
  To: m...@bitchin100.com 
  Sent: Thursday, October 27, 2022 1:16 AM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


  You can get a small (~15%) speedup just by doing this:


  0 DEFINT A-D, L, X, Y


  —b9



  On Wed, Oct 26, 2022 at 8:46 PM MikeS  wrote:

Oops; looks like I forgot to attach my version last night; good thing, 
found a couple of bugs tonight.

Looks like it could be speeded up a bit; no error checking.

I'd forgotten what a PITA it was to program on the real hardware.

1 DEFSTRH:H="0123456789ABCDEF":GOTO100
5 A=INT(X/4096):X=X-A*4096:B=INT(X/256)
6 PRINTMID$(H$,A+1,1)+MID$(H$,B+1,1);
7 C=INT((XMOD256)/16):D=XMOD16:Y=C*16+D
8 PRINTMID$(H,C+1,1)+MID$(H,D+1,1)+" ";
9 RETURN
20 X=0:X$=RIGHT$(""+X$,4)
30 FORI=1TO4:Y=ASC(MID$(X$,I,1))
40 Y$=CHR$(Y+(Y>95)*32)
50 L=INSTR(1,H,Y$)-1:X=X+L*(16^(4-I))
60 NEXT:RETURN
100 INPUT"From";S$:INPUT"to";E$
110 X$=S$:GOSUB20:S=X
120 X$=E$:GOSUB20:E=X
200 B$=TIME$:FORI=STOESTEP8:X=I:GOSUB5
210 L$="":FORJ=0TO7:X=PEEK(I+J):GOSUB7
220 Y=C*16+D
230 Y$=".":IFY>31ANDY<127THENY$=CHR$(Y)
240 L$=L$+Y$:NEXT:PRINTL$:NEXT
250 PRINTB$+" to "+TIME$:END

Constructive criticism welcome.

m

- Original Message - 
From: "runrin" 
To: 
Sent: Wednesday, October 26, 2022 10:24 PM
Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


> this seemed fun so i gave it a quick try. here's what i came up with.
> 
> it's a shame you can't do bitshift operations because i suspect
> ``((V AND 240) >> 4)'' would be faster than using integer division.
> 
> i'm a total neophyte when it comes to basic so i don't think this code
> is actually very fast. at least it's faster than the screen scrolls :P.
> in both examples i'm just peeking 0-59 since it's what fits on the
> screen nicely. that's also the reason for the "  ".
> 
> i like this version because it makes the print statement easy to read,
> it takes a lot more memory to store each character as it's own string
> though.
> 
> 10 DATA "0","1","2","3","4","5","6","7","8","9","A","B","C","D","E","F"
> 20 DIM H$(15)
> 30 FOR I = 0 TO 15
> 40 READ H$(I)
> 50 NEXT
> 60 FOR I = 0 to 59
> 70 V = PEEK(I)
> 80 PRINT H$(V \ 16); H$(V AND 15); "  ";
> 90 NEXT
> 
> ---
> 
> i made another version that uses string pointers because i felt bad
> using 16 strings. the PEEKS seem to be pretty expensive though, so i
> think it's actually slower than the previous version, but the code is a
> bit clearer. using MID$ is probably faster, but i mostly just did this
> for fun. this is more along the lines of how i would do something like
> this in C, which is the language i'm most familiar with.
> 
> string pointers are weird in basic. the pointer returned by VARPTR(S$)
> points to the following:
> 
> ptr + 0 = string length
> ptr + 1 = low byte of pointer to string
> ptr + 2 = high byte of pointer to string
> 
> i had to look in the basic language lab (pp. 182) to find that
> information. it's not even listed on
> https://help.ayra.ch/trs80-reference . i think i would have preferred
> if it just returned the string pointer with null terminator lol. not
> sure why they did it this way. anyway, here's the code:
> 
> 10 H$ = "0123456789ABCDEF"
> 20 P = VARPTR(H$)
> 30 SP = PEEK(P + 1) + PEEK(P + 2) * 256
> 40 FOR I = 0 TO 59
> 50 V = PEEK(I)
> 60 PRINT CHR$(PEEK(SP + (V \ 16))); CHR$(PEEK(SP + (V AND 15))); "  ";
> 70 NEXT
> 
> i know those extra spaces make my code slower, i'm just formatting it
> that way here so its actually legible.
> 
> -runrin

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

Oops; looks like I forgot to attach my version last night; good thing, found a 
couple of bugs tonight.

Looks like it could be speeded up a bit; no error checking.

I'd forgotten what a PITA it was to program on the real hardware.

1 DEFSTRH:H="0123456789ABCDEF":GOTO100
5 A=INT(X/4096):X=X-A*4096:B=INT(X/256)
6 PRINTMID$(H$,A+1,1)+MID$(H$,B+1,1);
7 C=INT((XMOD256)/16):D=XMOD16:Y=C*16+D
8 PRINTMID$(H,C+1,1)+MID$(H,D+1,1)+" ";
9 RETURN
20 X=0:X$=RIGHT$(""+X$,4)
30 FORI=1TO4:Y=ASC(MID$(X$,I,1))
40 Y$=CHR$(Y+(Y>95)*32)
50 L=INSTR(1,H,Y$)-1:X=X+L*(16^(4-I))
60 NEXT:RETURN
100 INPUT"From";S$:INPUT"to";E$
110 X$=S$:GOSUB20:S=X
120 X$=E$:GOSUB20:E=X
200 B$=TIME$:FORI=STOESTEP8:X=I:GOSUB5
210 L$="":FORJ=0TO7:X=PEEK(I+J):GOSUB7
220 Y=C*16+D
230 Y$=".":IFY>31ANDY<127THENY$=CHR$(Y)
240 L$=L$+Y$:NEXT:PRINTL$:NEXT
250 PRINTB$+" to "+TIME$:END

Constructive criticism welcome.

m

- Original Message - 
From: "runrin" 
To: 
Sent: Wednesday, October 26, 2022 10:24 PM
Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


> this seemed fun so i gave it a quick try. here's what i came up with.
> 
> it's a shame you can't do bitshift operations because i suspect
> ``((V AND 240) >> 4)'' would be faster than using integer division.
> 
> i'm a total neophyte when it comes to basic so i don't think this code
> is actually very fast. at least it's faster than the screen scrolls :P.
> in both examples i'm just peeking 0-59 since it's what fits on the
> screen nicely. that's also the reason for the "  ".
> 
> i like this version because it makes the print statement easy to read,
> it takes a lot more memory to store each character as it's own string
> though.
> 
> 10 DATA "0","1","2","3","4","5","6","7","8","9","A","B","C","D","E","F"
> 20 DIM H$(15)
> 30 FOR I = 0 TO 15
> 40 READ H$(I)
> 50 NEXT
> 60 FOR I = 0 to 59
> 70 V = PEEK(I)
> 80 PRINT H$(V \ 16); H$(V AND 15); "  ";
> 90 NEXT
> 
> ---
> 
> i made another version that uses string pointers because i felt bad
> using 16 strings. the PEEKS seem to be pretty expensive though, so i
> think it's actually slower than the previous version, but the code is a
> bit clearer. using MID$ is probably faster, but i mostly just did this
> for fun. this is more along the lines of how i would do something like
> this in C, which is the language i'm most familiar with.
> 
> string pointers are weird in basic. the pointer returned by VARPTR(S$)
> points to the following:
> 
> ptr + 0 = string length
> ptr + 1 = low byte of pointer to string
> ptr + 2 = high byte of pointer to string
> 
> i had to look in the basic language lab (pp. 182) to find that
> information. it's not even listed on
> https://help.ayra.ch/trs80-reference . i think i would have preferred
> if it just returned the string pointer with null terminator lol. not
> sure why they did it this way. anyway, here's the code:
> 
> 10 H$ = "0123456789ABCDEF"
> 20 P = VARPTR(H$)
> 30 SP = PEEK(P + 1) + PEEK(P + 2) * 256
> 40 FOR I = 0 TO 59
> 50 V = PEEK(I)
> 60 PRINT CHR$(PEEK(SP + (V \ 16))); CHR$(PEEK(SP + (V AND 15))); "  ";
> 70 NEXT
> 
> i know those extra spaces make my code slower, i'm just formatting it
> that way here so its actually legible.
> 
> -runrin

Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up appreciated

[MikeS]

Hi Steve,

I was going to mention your amazing code from way back when we played with 
one-line programs (and maybe even steal some code ;-) ) but didn't feel like 
hunting through the archives; didn't think of the personal libraries, duh!

m
  - Original Message - 
  From: Stephen Adolph 
  To: m...@bitchin100.com 
  Sent: Wednesday, October 26, 2022 10:41 AM
  Subject: Re: [M100] Notoriously S.L.O.W BASIC posted - help speeding it up 
appreciated


  Will,
  Here is a bit of compact code I wrote to convert bases given a number.  There 
may be some simplifications and or speed ups here.



  The one line version
  1 V$=" 
"+CHR$(13)+CHR$(8)+"0123456789ABCDEF":E=INSTR(V$,INKEY$):ONEGOTO1:F=(F-(E=2))MOD3:G=9*F+2-F^2:C=-C*(E=2)-(C*G+E-4)*(E>3ANDE:BASE :CLEAR":PRINT"<+> inc <-> decr":V$=" "+ 
CHR$(13)+"-"+ CHR$(8)+ "+0123456789ABCDEF"
  2 C=0
  3 C=C+E-4:C=C*(C<2^16)*(C>-1)
  4 F=(F-(E=2)) MOD 4:G = INT((F^3)*(4/3) - (F^2)*6 + F*(32/3) + 2):PRINT:PRINT 
MID$("BINOCTDECHEX",3*F+1,3);":";:IF F THEN Z= INT(C/256):D =Z:GOSUB 8:D 
=C-Z*256:GOSUB 8
  5 IF F\2 OR F=0  THEN D = C: GOSUB 10
  6 S$=INKEY$:E=INSTR(LEFT$(V$,5+G),S$):ON E+1 GOTO 
6,6,4,3,2,3:K=C*G+E-6:C=-K*(K<2^16):PRINT S$;:GOTO 6
  8 PRINT" ";
  9 PRINT CHR$(D AND D>31 OR 32 AND D<32);
  10 PRINT" ";:FOR I= 11*(F=0)-4 TO 0:J=G^I:X=INT(D*J):PRINT 
MID$(V$,X+6,1);:D=D-X/J:NEXT:RETURN


  Steve







  On Wed, Oct 26, 2022 at 10:22 AM Will Senn  wrote:

Hi All,

For those of you following my previous BASIC memory dump discussion, I have 
posted the code and some commentary on my blog at: 
http://decuser.blogspot.com/2022/10/notoriously-slow-basic.html

Take a look and if you have suggestions for improving it or find any 
errors, please let me know. I'll be working on its efficiency in the meantime 
and adding to the post as I figure stuff out.

Thanks,

Will

Re: [M100] BASIC slowness

[MikeS]

How slow is 'so swww' ?

I wrote a little program and it takes about a second per line, listing to the 
screen; haven't tried listing to the printer or the com port.

Scrolling is notoriously slow on the M100 but I believe there's a way to speed 
it up a bit.

Doesn't really seem out of line for a short run but if I needed a large block 
in a hurry I think I'd use a PC.

BTW, is that sample actually in the M100 somewhere? Not at  in mine ;-) 

m

- Original Message - 
  From: Will Senn 
  To: Model 100 Discussion 
  Sent: Tuesday, October 25, 2022 9:32 PM
  Subject: [M100] BASIC slowness


  OMG. I wrote my banner doing it's read of rom for character maps and sure, it 
takes a while to print a banner out using print statements, but it's bearable. 
But, my memory dumper is gosh awful slow. I have a subroutine to convert hex to 
dec, one to convert dec to hex, and one to pad strings given a length and 
character. My code calls the dec to hex conversion routine as it loops through 
a set of decimal addresses (destined for peeks). It then calls peek and the pad 
routine to print lines of the form:

  : 36 B6 21 17 46 00 6A 06  6.!.F.j.
  0008: B5 F0 3D 2E 51 E3 A6 26  ..=.Q..&

  But, ooohhh so swww!

  I figure I can inline the conversion routines or write them in machine code 
and CALL them which will speed them up, but I'm not sure about the padding 
stuff. I can probably do them in machine code, and I'll definitely try that, 
but in the meantime, is there a trick to fast output I'm missing?

  Regards,

  Will

Re: [M100] TRS-80 Video/Disk Interface 26-3806

[MikeS]

If you really want a 'real' DVI I could part with my dual-drive unit for $250.00

m
  - Original Message - 
  From: Spencer 
  To: m100@lists.bitchin100.com 
  Sent: Sunday, September 04, 2022 8:53 PM
  Subject: [M100] TRS-80 Video/Disk Interface 26-3806


  Hello.


  Anyone have an extra working 26-3806 they'd consider selling or trading? Or 
is there an alternative that one of you guys created?


  Thanks.

Re: [M100] M100 Linux keyboard via inputattach?

[MikeS]

Thanks very much; I'll check it out.

m
  - Original Message - 
  From: B 9 
  To: m...@bitchin100.com 
  Sent: Sunday, September 11, 2022 1:17 PM
  Subject: Re: [M100] M100 Linux keyboard via inputattach?


  On Thu, Sep 8, 2022 at 9:14 AM Joshua O'Keefe  
wrote:

  On Sep 8, 2022, at 9:09 AM, MikeS  wrote:
  Where can I find a good termcaps file?


I don't have a file in termcap format but the terminfo I use is in my 
bucket.  It's by far the most comprehensive of those I've come across:


http://public.nachomountain.com/files/m100/


  The original source of that terminfo is here:


  https://github.com/hackerb9/tandy-terminfo


  It does work pretty well and I haven't had to update it in a while so the 
copy in Joshua's Nacho Mountain is probably current. But I still recommend 
checking out the original github page as it has extra tips on how to use it and 
how to work around programs which do not use terminfo. (Unfortunately, the 
number of programs doing that is growing every year.) It also has a handy 
script for setting up the workarounds, currently called td200 because I only 
have a Tandy 200 to test on. I'd love to get feedback from people with other 
machines so I can make it more general.


  By the way, if a termcap is actually needed, the infotocap program (which 
comes with ncurses) will create one for you.



  —b9

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

[MikeS]

What and where is BYTEIT?

Thanks,

m
  - Original Message - 
  From: Charlie Hoey 
  To: m100@lists.bitchin100.com 
  Sent: Tuesday, September 06, 2022 8:51 AM
  Subject: [M100] what's the Right Way to code and assemble on model-t hardware


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


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


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


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


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


  Thanks!

Re: [M100] M100 Linux keyboard via inputattach?

[MikeS]

Where can I find a good termcaps file?

m

  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Wednesday, September 07, 2022 4:43 PM
  Subject: Re: [M100] M100 Linux keyboard via inputattach?


  It's an interesting idea, should work.

  When I hook to linux I set a termcap / getty. Either wired or a wimodem.

  And HTERM to do flow control and let me see some UTF-8 output including line 
drawing characters.

  But if you want to use the host's display only inputattach seems like a 
better way.

  WP-2 should work too, it has a terminal program.



  -- John.


  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"?

As I understand it, inputattach connects a serial device to the input 
stream of a Linux system.

Rather than modifying the keyboard to an M100/102/200, this would leave 
the M100/102/200 intact, and one could still telnet onto the Linux box 
from the M100/102/200 sometimes.

I wonder if this could be done with a WP-2, as well?

Re: [M100] How to shadow the RAM with own RAM from the system bus bay ?

[MikeS]

I've mounted chips 'upside-down' like that myself; never dreamed anyone did it 
commercially.

m

- Original Message - 
From: "Brian K. White" 
To: 
Sent: Wednesday, August 24, 2022 2:36 AM
Subject: Re: [M100] How to shadow the RAM with own RAM from the system bus bay ?


> Heads up though, Steve has me convinced about that (A)* idea he 
> mentioned in an earlier post.
> 
> I've made a new version based on that idea but it needs some testing to 
> work out how hard (A)* should be pulled, a dead short or a resistor of 
> what value? A simple short would make the pcb simpler but right now I 
> made room and got an 0805 footprint crammed in there.
> 
> I'm going to rig up a test using one of my older version boards that I 
> already have without needing to wait for it to be made. My latest 
> versions were just like this with the only difference being (A)* is N/C.
> That's convenient because it's trivial, all that needs is a single bodge 
> wire from bus pin 16 to gnd, maybe through a resistor.
> 
> The idea is, original QUADv4 disables the internal ram by holding RAMRST 
> high, which ends up blocking /OE on all the internal ram.
> 
> The new idea is leave RAMRST alone (other than using it for power, but 
> don't override it), instead, hold (A)* low. This blocks the (A)* signal 
> output from M20 reaching M3 & M4 input, which prevents any /CE1-/CE16 
> from being selected.
> 
> So rather than having all the internal ram active but just output 
> disabled, the ram is all inactive.
> 
> It's still overriding something, it just goes from overriding RAMRST to 
> overriding (A)*. (A)* is an output from M20, and I don't know what it 
> means for M20 to just short an output to gnd, but Steve already said he 
> tested it and it seems fine, and other commercial products even 
> supposedly did that.
> 
> What I want to do is see if maybe a resistor can pull it down good 
> enough to inhibit M3 & M4 from activating, and see just what it takes.
> Maybe the output is pretty strong and maybe it takes a pretty low value 
> resistor to overcome it, but maybe anything is better than nothing and 
> maybe we can at least reduce the current through that output a little.
> Or maybe a simple trace is no problem after all. Either way I want to 
> try it to find out.
> 
> This version is in the v011 branch until it's tested.
> 
> https://raw.githubusercontent.com/bkw777/reQUAD/v011/PCB/reQUAD.svg
> https://github.com/bkw777/reQUAD/tree/v011
> 
> The pcb is done too, and the bom is good except it's missing the 
> resistor. But no links to buy a pcb because this isn't verified yet.
> 
> 
> That's not a bad idea about the on-board battery. The PG Design version 
> of this has an on-board battery, but it's a bit more complex device and 
> works somewhat differently since it does not conflict with the internal 
> ram. The internal ram becomes bank1, and the added ram is banks 2 
> through 8 depending on what size model. It's pretty handy that you can 
> remove the device and not lose the contents.
> http://tandy.wiki/PG_Design
> https://photos.app.goo.gl/m8rpRFAL22FcjxLu6
> 
> That device looks a bit more complicated though to allow not fighting 
> with the internal ram, and have a battery without draining it 
> immediately. For one thing, most of it's logic is actually all in a PAL. 
> (the chip with the barcode sticker on it in the pics there)
> 
> 
> A similar device from Cryptronics also had a battery, a larger 3-cell 
> pack connected by wires, soldered, and stuffed in between the optrom & 
> bus socket.
> 
> https://photos.app.goo.gl/68qSfxdPD9WwdhzHA
> 
> Looks like a user bodge, but I've seen other pictures and they 
> apparently all shipped this way. I have one but have never fired it up, 
> so I don't know if it blocks out the internal ram or not. That thing has 
> a lot going on "the hard way" with no PAL.
> 
> The silkscreen says 64K, but there *appears* to be 96K worth of chips. 
> There are 12 chips, but they are stacked and you can only see the 
> markings on the top set, which is 4 x 6264, which is 4 x 8KB for 32K. 
> It's possible the hidden chips are not 6264, or possible the unit is a 
> revision that stuffs more ram onto the same pcb.
> 
> Those chips on the bottom of the pcb are actually installed upside down 
> from the point of view of the pcb surface, but it's so they can be in 
> same orientation as the rest of the stack. That's why you can't read any 
> markings. Notice the injection mold marks. The entire stack of 3 chips 
> must all be connected parallel right through the board except for a 
> couple control lines. They must have had to bend all those pins with a jig.
> 
> Lot of hand work on that puppy.
> 
> -- 
> bkw
> 
> 
> On 8/23/22 22:52, Henner Zeller wrote:
>> Thanks both Stephen and Brian for working on QUAD and Brian for the dive 
>> into the history and sharing some of the gotchas discovered.
>> 
>> I think this last version looks very nice
>>  * we have power all the time, using the VDD 

Re: [M100] Questions about tokenizing BASIC in UNIX

[MikeS]

If B9's UNIX BASIC is somewhat compatible and he promises not to laugh or 
criticize I can try to find the Tbasic source code.

m
  - Original Message - 
  From: Brad Grier 
  To: m...@bitchin100.com 
  Sent: Monday, July 25, 2022 3:32 PM
  Subject: Re: [M100] Questions about tokenizing BASIC in UNIX


  Club100 Member directory for Mike Stein has Entoke.exe - 
http://www.club100.org/memfiles/index.php?=0=nom=Mike%20Stein


  And a wayback machine crawl reveals detoke.exe - 
https://web.archive.org/web/2017155020/http://www.xibalba.com/website100/software.html




  On Mon, Jul 25, 2022 at 11:58 AM Peter Vollan  wrote:

There are tokenise and detokenise programs for DOS, in the Compuserve 
archive, I think.


On Sun, 24 Jul 2022 at 23:42, John R. Hogerhuis  wrote:

  Not as far as I know. I think Robert Pigford's program is it. PowerBASIC 
is a compiler though so I guess its binaries would run under a Linux DOS 
emulator. I've certainly run DOS assemblers like TASM as part of a GNU/Linux 
Makefile.

  You would need a tokenizer for each BASIC variant you want to support 
(M100/102, 8201A/8300, and maybe t200?)

  The ROM of each machine is of course already capable of doing it properly 
by definition via LOAD/CLOAD. So emulators effectively support tokenization as 
well. VirtualT is fully scriptable over telnet/socket.

  For myself I just use my laptop or emulator to created tokenized files.

  One note... there are valid, specially constructed BA  files that do not 
fully LIST, and are not convertible to ASCII BASIC text and back again, with 
high numbered lines and/or machine language embedded in it. To create such 
files goes beyond simple tokenization, but it may be useful and interesting to 
create advanced special BA binary file generators. Most such files require 
special measures to create.


  -- John.


  -- 

  -- 
  Brad Grier

Re: [M100] is the list actually working?

[MikeS]

As John says, sometimes only a few people might have an answer to your question 
and they may not be reading the list at that very time.

There's an option in your list profile to see or not see your own posts; try 
turning that on if it's off.

m
  - Original Message - 
  From: Peter Vollan 
  To: m...@bitchin100.com 
  Sent: Tuesday, May 03, 2022 2:55 PM
  Subject: Re: [M100] is the list actually working?


  I'd appreciate if someone could respond to my messages just so I know they 
got through. I have posted about the weird error I am getting with Kurt 
McCullum's Mcomm twice without a peep, and I don't want to bore people to death 
if they have already seen it. 


  On Tue, 3 May 2022 at 11:03, Gregory McGill  wrote:

A good way to tell is the discord email list channel, it has 99% of the 
messages except the ones that exceed 2000 characters.. those are skipped due to 
limitations on the importer
Greg

Re: [M100] low profile pcb pins

[MikeS]

Our friend Al K suggested some "Flip Pins' in response to Steve's query on VCF; 
they look interesting, $.09/pin:

https://www.evilmadscientist.com/2016/fliptronics-flip-pins/

m

- Original Message - 
From: "RETRO Innovations" 
To: 
Sent: Saturday, February 27, 2021 3:19 PM
Subject: Re: [M100] low profile pcb pins


> On 2/27/2021 12:20 PM, Mike Stein wrote:
>> Yeah, many people use those for this application and I even have some, 
>> both DIP and SIP, but the thickness of the pins on the ones I've been 
>> able to find is more than an IC leg and they don't fit well into 
>> machined pin sockets; are yours thin enough?
> 
> I feel they are. And, they fit into machine pin sockets.
> 
> I've used them in commercial products for 15 years, and no complaints, 
> even after folks reverted back to non machine pin ICs.
> 
> I don't think one has to be exactly as thin as an IC pin (they make IC 
> pins just thick enough to handle the force of pushing into a socket, no 
> more :-), but rather no larger than the expected width a leaf socket 
> expects.
> 
>>
>> And I don't use the component carriers as is; I extract the pins while 
>> watching a baseball game or some other mindless distraction and then 
>> insert them from the top through the pcb, trimming off the forks after 
>> soldering. Admittedly, I wouldn't want to do 100 pcbs in one sitting 
>> that way...
> 
> Yeah, I can see that as viable for very small batches, but I get ROM 
> adapters and such assembled in batches of 100 or 200 at a time. The 
> cost to handle it that way would be prohibitive to the hobbyist nature.
> 
> I do agree the regular square pins available at most electronics 
> connector houses are too wide, they spread the leaf socket out too 
> much. As has been noted, the cheaper Arduino male-female headers you 
> can buy on eBay work great as well. They are about .1mm thicker than 
> the IC pin thickness.
> 
> Jim

Re: [M100] low profile pcb pins

[MikeS]

Why not just order a few? Here's a place with no minimum order as far as I can 
see:

https://www.elliottelectronicsupply.com/catalogsearch/result/?q=carrier=29=21=relevance=desc
  - Original Message - 
  From: Stephen Adolph 
  To: m...@bitchin100.com 
  Sent: Saturday, February 27, 2021 8:50 AM
  Subject: Re: [M100] low profile pcb pins


  Mike, those look very useful, but to know if I can use it in this case I'll 
need to find a drawing and see what the height is.
  thanks for the tip!


  Steve



  On Sat, Feb 27, 2021 at 1:32 AM MikeS  wrote:

Also:



https://www.peconnectors.com/component-carriers/hws16187/
  - Original Message - 
  From: Stephen Adolph 
  To: m...@bitchin100.com 
  Sent: Friday, February 26, 2021 11:32 AM
  Subject: Re: [M100] low profile pcb pins


  this is what I am using today.  works really well, should have bought 
hundreds of them! 






  On Fri, Feb 26, 2021 at 8:51 AM Stephen Adolph  
wrote:

Greg, thanks for that, and I hope you feel better soon! 
I counted and I have enough pin headers to build a grand total of 12 
more REX# NEC/M10.  then that's it.

Steve


On Fri, Feb 26, 2021 at 8:46 AM Greg Swallow  wrote:

  Steve, 

  I should have some of what I use to make system ROM sockets fom T102. 
Am in VA hospital for a day or two. Took a dizzy fall at work and gotta find 
out why. Hope to be home by Sat and will dig up what I got and let you know. 

  I believe they were 1x20 @ 2.54mm spacing. No longer in my eBay 
purchase history. 

  God Bless, 

  GregS <>< 



  Feb 26, 2021 5:55:48 AM Stephen Adolph :

Hi folks. 
I'm struggling to find a good pcb pin for building REX# NEC/M10. 


I have tried working with those leadframes, but I find it difficult 
to work with them.  I have to file them down so that the pins don't catch, and 
they don't work on machine sockets either. 



https://www.te.com/usa-en/product-1544210-2.html 




Can someone recommend a good low cost low profile solder machine 
pin? 


What I have today is absolutely perfect, but I can't find any more. 
 It is a 28 pin DIP header based on machine pins that has a really thin plastic 
frame.  So the module plugs in and sits almost directly flush to the host 
socket. 


thx 
Steve 

Re: [M100] low profile pcb pins

[MikeS]

Also:



https://www.peconnectors.com/component-carriers/hws16187/
  - Original Message - 
  From: Stephen Adolph 
  To: m...@bitchin100.com 
  Sent: Friday, February 26, 2021 11:32 AM
  Subject: Re: [M100] low profile pcb pins


  this is what I am using today.  works really well, should have bought 
hundreds of them!






  On Fri, Feb 26, 2021 at 8:51 AM Stephen Adolph  wrote:

Greg, thanks for that, and I hope you feel better soon!
I counted and I have enough pin headers to build a grand total of 12 more 
REX# NEC/M10.  then that's it.

Steve


On Fri, Feb 26, 2021 at 8:46 AM Greg Swallow  wrote:

  Steve, 

  I should have some of what I use to make system ROM sockets fom T102. Am 
in VA hospital for a day or two. Took a dizzy fall at work and gotta find out 
why. Hope to be home by Sat and will dig up what I got and let you know. 

  I believe they were 1x20 @ 2.54mm spacing. No longer in my eBay purchase 
history. 

  God Bless, 

  GregS <>< 



  Feb 26, 2021 5:55:48 AM Stephen Adolph :

Hi folks. 
I'm struggling to find a good pcb pin for building REX# NEC/M10. 


I have tried working with those leadframes, but I find it difficult to 
work with them.  I have to file them down so that the pins don't catch, and 
they don't work on machine sockets either. 



https://www.te.com/usa-en/product-1544210-2.html 




Can someone recommend a good low cost low profile solder machine pin? 


What I have today is absolutely perfect, but I can't find any more.  It 
is a 28 pin DIP header based on machine pins that has a really thin plastic 
frame.  So the module plugs in and sits almost directly flush to the host 
socket. 


thx 
Steve 

Re: [M100] Joystick for the M100

[MikeS]

I haven't seen a joystick article for the Model T but there's a mouse driver in 
Feb/90 P.8

m
  - Original Message - 
  From: Lee Kelley 
  To: m...@bitchin100.com 
  Sent: Tuesday, January 05, 2021 2:30 AM
  Subject: Re: [M100] Joystick for the M100


  I can't quote the issue and page but I do recall there being an article in 
Portable 100 magazine about connecting a joystick to the Model T computers.

   Virus-free. www.avg.com  



  On Mon, Jan 4, 2021 at 10:41 PM Daryl Tester 
 wrote:

On 5/1/21 6:24 am, Jim Anderson wrote:

> As I recall, the way it worked was that the five switches (directional
> switches and fire) were wired to the first five output bits, and the
> common return from all five switches was wired to BUSY.  To poll the
> joystick you'd cycle through outputting ASCII 1, 2, 4, 8, and 16, and
> read BUSY each time.  Whichever bits resulted in assertion of BUSY
> meant that switch was currently closed.

Probably need diodes in there as well, to stop from inadvertantly
driving an output low and high at the same time if the joystick
had more than one switch closed (e.g. up and fire).

Cheers,
   --dt





  -- 

  "I will never in my lifetime make a film that cannot be seen by the whole 
family"  Arther P. Jacobs

Re: [M100] Joystick for the M100

[MikeS]

>From Kim Holviala kim at holviala.com 
Wed Feb 23 2011

Yup, got my side project, the Atari/Commodore joystick interface for 
M100 working reliably.

This is a simple passive interface only requiring two connectors, some 
cable and five diodes. Total cost is under $10 including a case for the 
Sub-D9 connector.

Schematic:

LPT port   D9 male
3  PD0 --|<--- 1 UP
5  PD1 --|<--- 2 DOWN
7  PD2 --|<--- 3 LEFT
9  PD3 --|<--- 4 RIGHT
11 PD4 --|<--- 6 BUTTON
21 BUSY -- 8 GROUND

Parts:

1  2x13 pin female flat cable connector (0.1" spacing)
1  D9 male connector (solder type)
1  D9 connector case
6" 26-pin flat cable (or at least 4 inches)
5  1N4148 (or similar)

I used 1N4007 for the diodes, but using something physically smaller 
like 1N4148 is easier if you want to fit everything into the D9 case.

Theory of operation:

We're doing it all backwards. Instead of feeding ground through joystick 
port pin 8 and reading the directions from pins 1-4 and 6, we're feeding 
signals through 1-4 and 6 and reading the result from pin 8 (which is 
connected to BUSY in LPT port).

Using with 100% Basic:

This works (even though it shouldn't) but isn't very reliable. We're 
fighting with the keyboard interrupt, and quite often it hits between 
our OUT and IN messing up the readings.

OUT 185,254:U=INP(187) AND 4
OUT 185,253:D=INP(187) AND 4
OUT 185,251:L=INP(187) AND 4
OUT 185,247:R=INP(187) AND 4
OUT 185,239:B=INP(187) AND 4

Variables U/D/L/R and B now contain 0 if that particular direction is 
selected and 4 if the direction is not selected.

Mostly Basic, but some assembly required:

This version seems to be 100% reliable even though it doesn't disable 
interrupts between the assembler out and in.

10 CLS
20 A$=CHR$(211)+CHR$(185)+CHR$(219)+CHR$(187)+CHR$(119)+CHR$(201)
30 AS=PEEK(VARPTR(A$)+1)+(256*PEEK(VARPTR(A$)+2))
40 U%=0:D%=0:L%=0:R%=0:B%=0
50 CALL AS,254,VARPTR(U%):U%=U% AND 4
60 CALL AS,253,VARPTR(D%):D%=D% AND 4
70 CALL AS,251,VARPTR(L%):L%=L% AND 4
80 CALL AS,247,VARPTR(R%):R%=R% AND 4
90 CALL AS,239,VARPTR(B%):B%=B% AND 4
100 IF U%=0 THEN PRINT " U" ELSE PRINT " *"
110 IF L%=0 THEN PRINT "L "; ELSE PRINT "* ";
120 IF R%=0 THEN PRINT "R" ELSE PRINT "*"
130 IF D%=0 THEN PRINT " D" ELSE PRINT " *"
140 IF B%=0 THEN PRINT "BTN" ELSE PRINT " * "
150 PRINT CHR$(11);
160 GOTO 50

The assembler code on line 20 is as follows (needs a bitmask in A, 
outputs joystick info to [HL]):

out 185
in 187
mov m,a
ret

That's about it. Now back to the WiFi adapter...


- Kim


 
  - Original Message - 
  From: Brian White 
  To: m...@bitchin100.com 
  Sent: Tuesday, January 05, 2021 7:16 AM
  Subject: Re: [M100] Joystick for the M100





  On Mon, Jan 4, 2021, 2:55 PM Jim Anderson  wrote:

> -Original Message-
> For input, there are only 2 signals, BUSY and BUSY_N.  Each of these can
> be read independenty.

As I recall, the way it worked was that the five switches (directional 
switches and fire) were wired to the first five output bits, and the common 
return from all five switches was wired to BUSY.  To poll the joystick you'd 
cycle through outputting ASCII 1, 2, 4, 8, and 16, and read BUSY each time.  
Whichever bits resulted in assertion of BUSY meant that switch was currently 
closed.





  Nice.


  -- 
  bkw

Re: [M100] Simple communication, M100 -> com1: ... can download from PC, but can't upload

[MikeS]

Just curious: Which version of Windows were you using for this?

m
  - Original Message - 
  From: Russell Flowers 
  To: m...@bitchin100.com 
  Sent: Wednesday, November 11, 2020 9:24 PM
  Subject: Re: [M100] Simple communication, M100 -> com1: ... can download from 
PC, but can't upload


  Update on this - the paperclip test did show data looping back through.


  I used a simple program called "RealTerm" and everything performed as 
expected, just fine.


  For some reason, using Windows CMD prompt ("copy com1: filename.txt", or 
"copy com1: con:") produces nothing. I *can* send files TO the 100 with "copy 
filename.txt com1:" ... so it's not worth worrying about, since every other 
connection method works fine.


  Thanks, all.


  On Wed, Nov 11, 2020 at 8:40 AM Russell Flowers  wrote:

Thanks, I will try that tonight.


On Wed, Nov 11, 2020 at 8:22 AM Brian K. White  wrote:

  I would do John's suggestion with the paper clip loopback test. That 
  tests both your TX and RX in a very quick and easy way.

  Looking at the back of the M100, you want to jumper pins 2 and 3 
  together. Pins 2 and 3 are on the top row, all the way to the right 
  except 1.

o o o o o o o o o o * * o
 o o o o o o o o o o o o

  -- 
  bkw

  On 11/11/20 9:12 AM, Russell Flowers wrote:
  > I am very sorry, I posted the wrong link.
  > 
  > THIS is the link I meant : 
  > 
https://www.ordersomewherechaos.com/rosso/fetish/m102/web100/docs/pc-xfer.html 
  > 

  > 
  > On Tue, Nov 10, 2020 at 11:29 PM Mike Stein  > wrote:
  > 
  > I have the same problem finding what is referenced; how are you
  > sending and receiving on the PC end?
  > 
  > m
  > 
  > On Wed, Nov 11, 2020 at 12:24 AM John R. Hogerhuis  > wrote:
  > 
  > I'm not clear what instructions you're following. The link goes
  > to a long page and the table at the beginning doesn't have
  > anything about file transfer.
  > 
  > I wonder if you're having a hardware problem? Bad pin? Cable
  > issue?Or possibly some flow control is on.
  > 
  > One thing you can do if you have a db25 is use a paper clip to
  > loop back tx to rx and see if you can see what you type come
  > back. That allows you to check the tx rx on UART.
  > 
  > -- John.
  > 


  -- 
  bkw

Re: [M100] Back in the hospital yet again

[MikeS]

Joining the well-wishers; all the best!!

m

- Original Message - 
From: "Kenneth Pettit" 
To: 
Sent: Monday, November 09, 2020 9:37 PM
Subject: [M100] Back in the hospital yet again


Hey gang,

Well I’m back in the hospital again with angina and shortness of breath.  
Hopefully it will be just. A couple of days for a stent or two and then home 
again.  Will let you know.

Ken

Sent from my iPhone=

Re: [M100] Scans of the Model 100 schematics from the Technical Reference Manual

[MikeS]

Very nice; Thank you!

m

- Original Message - 
From: "Michael Kohne" 
To: 
Sent: Monday, October 26, 2020 2:46 PM
Subject: [M100] Scans of the Model 100 schematics from the Technical Reference 
Manual


>I had a lot of problems using the schematics that were previously
> scanned from the technical reference manual, so I bought a copy of the
> manual and scanned just the schematics, in higher resolution, on a
> large format scanner.
> 
> They've been uploaded to the internet archive at
> https://archive.org/details/trs-80-model-100-main-pcb-schematic-from-tech-ref-manual
> The original files are TIFFs, but they aren't that big (a little over
> 1 Mb for the pair). Do whatever you like with them.
> 
> I saw no reason to rescan anything else from the manual, as the rest
> of it is quite readable in my opinion.
> 
> -- 
> Michael Kohne
> mhko...@kohne.org
> 
> Anything real you do that's important will be scary. Having kids.
> Getting married. Donating a kidney.  Writing a book. Do it anyway. -
> Neil Gaiman

Re: [M100] CCR-82

[MikeS]

Tell us more about the "bag of 80 or so tape belts of various sizes."

m

- Original Message - 
From: "Kevin Becker" 
To: 
Sent: Friday, April 24, 2020 9:36 PM
Subject: Re: [M100] CCR-82


I replaced the belts in mine with a similar giant random belt assortment and it 
works fine. No caps needed replacing. 

> On Apr 24, 2020, at 6:32 PM, me  wrote:
> 
> 
> I just ordered this
> 
> https://www.ebay.com/itm/143565229494
> 
> Also ordered a bag of 80 or so tape belts of various sizes.
> 
> I'll replace the belts but I'm also sure the caps will be replacing. Anyone 
> sell cap kits for it? I'm going to look for the service manual.
> 
> If I can't get it working, it'll be used for parts. He had a cheaper shipping 
> method available so I took the plunge.
>

Re: [M100] Video adapter.

[MikeS]

Which one, the original or the Tindie version? I thought the Tindie version ( 
U$52.00`+ S ) is out of stock?

m


- Original Message - 
  From: Gregory McGill 
  To: m...@bitchin100.com 
  Sent: Thursday, April 16, 2020 2:40 PM
  Subject: Re: [M100] Video adapter.


  doh that's the one I ordered... will have to do a run of the other boards 
then :) and put it in my store when you get it all figured out I'll get that in 
motion


  On Thu, Apr 16, 2020 at 10:11 AM Stephen Adolph  wrote:

yes, I am basing this off the original design not the one on Tindie.
The tindie design uses new firmware, and a faster clock.  Not doing that 
work.





On Thu, Apr 16, 2020 at 1:07 PM Mike Stein  wrote:

  Hi Steve,

  Did it ultimately end up essentially identical to the original except for 
the DE-9? (The original board has a 4-pin low voltage TTL header).

  I ask because I have a few extra of the original board just in case 
someone wants to do it the hard way, assuming any firmware upgrades will be 
compatible.

  m
- Original Message - 
From: Stephen Adolph 
To: m...@bitchin100.com 
Sent: Thursday, April 16, 2020 12:13 PM
Subject: Re: [M100] Video adapter.


regarding the kit. 
The kits available don't have a convenient RS-232 connector.
I redesigned the PCB to support a DB-9 connector.  If you can wait, 
I'll have that ready soon.
If not, then I think you can go for Tindie ($$$) or the source that 
Geoff cites on his site.




On Thu, Apr 16, 2020 at 12:06 PM Tom Wilson  wrote:



  Where did you find it, Greg? I haven’t been able to find a kit. 


  On Thu, Apr 16, 2020 at 7:36 AM Gregory McGill 
 wrote:

agreed, super cool.. i just ordered one of these boards 


Greg


On Thu, Apr 16, 2020 at 7:09 AM Brian White  
wrote:

  this is really cool


  bkw


  On Thu, Apr 16, 2020, 8:47 AM Stephen Adolph 
 wrote:

next update:
I have a beta version of the VT100 driver working now.  It's 
pretty neat to have a modern display hanging off of the M100!
The current version works with the "stock VT100 adapter" with a 
few issues.  What needs to happen next is a software load for the VT100 adapter 
that provides a few extra commands that the M100 needs.


The VT100 driver works just like Microsoft Disk Basic, in that 
it integrates with the M100 OS to enable direct access to an external CRT.  



cheers
Steve











On Tue, Apr 14, 2020 at 10:44 AM Stephen Adolph 
 wrote:

  update: 
  Towards the goal of a next-generation video solution for 
M100, I have some progress to share.
  Recall this thread where I suggest that the "Geoff VT100 
adapter" as the hardware to focus on.


  First, I have a "beta" VT100 driver solution, which is 
closely based on Microsoft Disk-Basic (minus the disk stuff).
  While still buggy, I can now drive the VT100 board, and 
attached VGA monitor from BASIC.


  Secondly, in order to really support M100, the software 
component in the VT100 emulator board needs to be extended. I'm working on 
that.  This does imply that the "Geoff VT100" board, as it was originally 
designed, won't work perfectly for M100.   But, I'll post the updated software 
image so anyone with this board already can update their board.


  I'll keep posting updates as this progresses.


  Steve




  On Sun, Apr 5, 2020 at 8:41 AM Stephen Adolph 
 wrote:

As some of you may recall, it is fairly straightforward to 
access an 80x24 screen in CP/M through the use of the M100 serial port, and an 
external VT100 emulator.


This device:
http://geoffg.net/terminal.html


is a great example of how to connect a modern VGA flat 
screen display to the M100.  However, this exact design isn't really 
convenient, as the serial data has to be connected with a custom cable.  (see 
the little white 4 pin header).


I've decided to make a variant of this design that has a 
DB-9 connector on it, for serial data, so that it can be easily connected to 
the M100.


I'll be making kits available for this design, and the 
price will be 30$ US.  Hopefully by making this affordable and easier to 
connect, this can become the defacto solution to 80x24 display!


This solution will work with CP/M right away, but the next 
task will be - how to use this solution with Model T natively.  This will take 
some software work.  A port of the "DVI software" to leverage serial 
communication to the VT100 adapter is one way to do this. 

Re: [M100] DVI cable length

[MikeS]

Mine's 2 feet long, no problems.

You can't see the DVI in this pic but it's off to the left:


  - Original Message - 
  From: James Zeun 
  To: m...@bitchin100.com 
  Sent: Wednesday, March 11, 2020 7:11 PM
  Subject: [M100] DVI cable length


  Hey everyone


  Just a quick question, how long can a DVI link cable be? My new cable arrived 
today and while it's longer than what I had, I could still do with it being 
20-30cm longer.

Re: [M100] Dungeon Master's Personnel Service

[MikeS]

We'll see once the effects of the wine wear off...

  - Original Message - 
  From: James Zeun 
  To: m...@bitchin100.com 
  Sent: Wednesday, January 08, 2020 2:45 AM
  Subject: Re: [M100] Dungeon Master's Personnel Service


  I'll have one of its going spare ;-)) hehe


  On Wed, 8 Jan 2020, 7:29 am Mike Stein,  wrote:

Truly BITCHIIN !!!

Great job, John! Might as well get rid of all my 'real' M100s ;-)

m
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Wednesday, January 08, 2020 1:56 AM
  Subject: Re: [M100] Dungeon Master's Personnel Service


  For those who don't know about CloudT, Dan's program loads easily:

  For those who want to try the above program in CloudT:


  a) Select (only) the program text in the email
  b) Ctrl-C or Right-Click- copy
  c) Open CloudT : https://bitchin100.com/CloudT/
  d) Scroll to the bottom of the screen
  e) Paste the text into the rectangular text control (Ctrl-V) (or 
Right-Click Paste)
  f) Click on "Add Plain Text" Button
  g) A window will pop up asking you for a name, type HOARD.DO
  h) Click on the Model 100 screen
  i) Select BASIC, hit Enter
  j) Type CLOAD and hit Enter
  k) type RUN and hit Enter

  CloudT is available on most any device if you want to mess around with 
Model 100 BASIC programming.


  -- John.

Re: [M100] Peripherals for the M100

[MikeS]

e.g.:
$8.99

https://www.harborfreight.com/hand-tools/chisels-punches-stamps/punches/9-piece-hollow-punch-set-3838.html

Don't know what size is required, so can't say whether it contains the right 
sizes.

  - Original Message - 
  From: Charles Hudson 
  To: m100@lists.bitchin100.com 
  Sent: Tuesday, January 07, 2020 8:02 AM
  Subject: [M100] Peripherals for the M100


  On January 6th Mike Stein wrote:


  "... or a $10 set of punches... ;-)" If you can find a matched set of punches 
of the proper diameters for $10 I want to shop where you shop. -CH- 

Re: [M100] Null modem cable

[MikeS]

Even easier, make that 9-25 pin cable a null-modem cable with the correct 
genders to go straight from the M100 to the USB adapter.

e.g.:
https://www.primecables.ca/p-314140-cab-479-all-null-modem-db9fdb25m-molded-cable-4-lengths-available-monoprice?atc_source=search%23null+modem+cable#sku314140

  - Original Message - 
  From: Tim Russell 
  To: Model 100 Discussion 
  Sent: Friday, October 10, 2014 8:33 PM
  Subject: Re: [M100] Null modem cable


  Well, I've been using a USB->9 pin serial cable, then a 9-pin to DB25 cable, 
and then an old DB25-DB25 null modem block and it works swimmingly, nothing 
custom.

  Point being, I think if you get the genders and size right, and use a null 
modem, I don't see how you can get it wrong.

  Tim


  On Oct 10, 2014 6:03 PM, "James Zeun"  wrote:

So I made a cable for my m100 and so far I've yet to get a single file on 
the tiny machine. As it's just not working with mcomm.

Any know where I can buy a pre-made cable? Just so I can eliminate it from 
the list of things stopping me from getting file transfers working.

Cheers
James

Re: [M100] RealTerm

[MikeS]

Does it work on the Bar code port?


  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Sunday, April 07, 2019 6:57 PM
  Subject: [M100] RealTerm


  I think I've mentioned it before, but for serial protocol work I use RealTerm 
on Windows.

  It may not be your cup of tea. There are certainly more minimalist programs 
to use, but for talking directly to serial protocol based devices this is the 
best I've found. You can see the flow control lines, view in hex or ascii, 
paste in hex formatted and have it send as binary bytes, get it to detect some 
basic message framing etc. etc.


  It's one of those pieces of software that you can tell it was written by 
technicians for technicians.


  https://realterm.i2cchip.com/  



  -- John.

Re: [M100] TeraTerm - still not communicating

[MikeS]

That depends. If you're looking at the _pins_ in the position you show (5 on 
the bottom) then it is the 2nd and 3rd from the right on the bottom row.

If you're looking at the _holes_ then it's the 2nd and 3rd from the left.

If you look very closely with a magnifying glass you'll probably find that the 
pins and sockets are actually numbered in the connector.

  - Original Message - 
  From: Thomas Morehouse 
  To: m...@bitchin100.com 
  Sent: Friday, April 05, 2019 3:49 PM
  Subject: Re: [M100] TeraTerm - still not communicating


  Twenty-seven messages in this thread, plus my two previous threads, and I've 
received lots of good info.  But I'm more lost than ever.


  For the "loopback adapter", what pins am I trying to connect? In other words, 
looking at the external pins on the 102 serial port:


  o o o o
  o o o o o


  which two of those nine pins am I supposed to be connecting?


  (This seems to be a bit more thorny and problematic than I'd expect.)


  Tom M.




  On Fri, Apr 5, 2019 at 3:40 PM John R. Hogerhuis  wrote:

I agree with all this anti-prolific sentiment, but Thomas has what he has. 

Thomas if you want to prove out your cabling without buying a new USB 
adapter you will need to come up with a way to rig up a loopback adapter. If 
the device can send a byte and receive it back over the loopback, then it is 
good enough for what you are trying to do.

There is more than one way to do this, but you need to prove out the 
transmit and receive lines on your adapter, and on the model T.


-- John.

Re: [M100] question regarding floppy disks.

[MikeS]

... But it's actually 256 bytes/sector, 18 sectors/track, 35 tracks ...

;-)
  - Original Message - 
  From: Mike Stein 
  To: m...@bitchin100.com 
  Sent: Monday, March 25, 2019 12:28 PM
  Subject: Re: [M100] question regarding floppy disks.


  Sounds similar to the original IBM 5.25" format, single-sided, 512 
bytes/sector, 8 sectors/track, 40 tracks, 250Kbps.
- Original Message - 
From: Stephen Adolph 
To: m...@bitchin100.com 
Sent: Monday, March 25, 2019 11:54 AM
Subject: Re: [M100] question regarding floppy disks.


when attached to a CoCo, you get 160k.


On Mon, Mar 25, 2019 at 11:02 AM Kurt McCullum  wrote:

  Yeah that does sound strange. And I agree, the drive 'should' switch 
based on the hole in the disk. Does it format to 720 or 1.44 when the hole is 
covered?


  On Mon, Mar 25, 2019, at 7:37 AM, Stephen Adolph wrote:

Kurt, agree with everything you have said.



The odd thing is-



* using an HD disk in an DD/HD drive, and covering the hole with tape, 
would seem to be BAD

---> because you are telling the drive to use the wrong current 
settings for the actual disk media.



However, this is apparently the way to make my system functional.



so, strange.  I would have thought it would be the opposite - let the 
drive decide what current to use, matched to the "cookie".





On Mon, Mar 25, 2019 at 10:19 AM Kurt McCullum  
wrote:



  The magnetic coercivity on HD disks is different than on regular 
disks. It requires more energy to lay down the tracks. If you start with a 
blank HD disk rather than a pre-formatted disk then you have a better chance. 
That's because once the HD tracks are laid down, you need to erase them for 
your new format. If your drive doesn't have enough energy to completely erase 
the existing track, it wont work. 720k disks have a lower coercivity and 
therefore work with either a 720k or 1.44mb drive. A 1.44 drive has a sensor 
for the open hole and when it sees that hole, it will use a higher level of 
write energy to properly work with the media. When that hole is covered, it 
will use a lower level which is what the 720k media is looking for. Though I do 
remember that formatting a 720k disk in a 1.44mb drive didn't always work when 
going back to a 720k drive. 



  Not sure about the Coco drive, but my TPDD2 does not work reliably 
with HD disks. I have only been able to format one properly and it had data 
failure shortly after.



  Kurt



  On Sun, Mar 24, 2019, at 6:32 PM, Stephen Adolph wrote:

interestingly,



Yes, if I take an HD disk, and tape over the hole to make it appear 
to be a DD disk, then it works.



But why?



the floppy is capable of both formats...



On Sun, Mar 24, 2019 at 7:39 PM Mike Stein  
wrote:



  Have you tried closing the HD sense hole with a piece of tape or 
similar?

- Original Message -

From: Stephen Adolph

To: m...@bitchin100.com

Sent: Sunday, March 24, 2019 6:08 PM

Subject: Re: [M100] question regarding floppy disks.



the Coco is using it's standard controller



When issuing the DSKINI 0 command the coco tries to format for 
180kB.



The combination of 

(Coco, std controller, PC 1.44MB drive + a 720kB dd floppy) 
works



whereas

(Coco, std controller, PC 1.44MB drive + a 1.44MBB hd floppy) 
does not work



this is something I don't understand!







On Sun, Mar 24, 2019 at 5:42 PM Gregory McGill 
 wrote:

  likely the floppy controller doesn't support 80 tracks or 
high density..  most of the controllers of the era are ds/sd 40 track or dsdd 
40 track..   are you able to format 720k? ds/dd 80 track? 



  Greg



  On Sun, Mar 24, 2019 at 2:38 PM Stephen Adolph 
 wrote:

I'll start by saying this isn't an M100 or TPDD discussion, 
but just looking to understand something.



I have a Tandy Coco3 with a 3.5 inch floppy drive.  The 
drive is a standard PC drive and it is working well.



Seems though that I cannot use 1.44 MB floppies in that 
drive. They don't seem to want to format.



I really don't understand where the problem could be.

- the drive and the floppy are compatible

- the disk is known good and formats at 1.44MB in a PC

- if it can support 135 TPI, why can't it support 35 TPI?



Does anyone know what's going on?



thx

Steve

Re: [M100] Few questions and Olivetti M10

[MikeS]

I don't see the terminating zeroes in the final HEX version; something also 
looks odd at the beginning, they're not all the same.

Maybe being an M10 file accounts for some of that?

m
  - Original Message - 
  From: Mauro Pintus 
  To: m...@bitchin100.com 
  Sent: Friday, March 08, 2019 3:23 PM
  Subject: Re: [M100] Few questions and Olivetti M10


  My file?? I'll double check!!
  Thank you
  Mauro

  Inviato da iPhone

  Il giorno Mar 8, 2019, alle ore 16:57, Mike Stein  ha 
scritto:


It looks to me as though the file was truncated somewhere along the way.
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Thursday, March 07, 2019 6:30 PM
  Subject: Re: [M100] Few questions and Olivetti M10


  The wav2cas programs around don't know the Model T format, I guess. I 
guess it's possible that all TRS-80s use the same format, but I wouldn't assume 
it.

  If you managed to decode the WAV file, what you have is a "tokenized 
BASIC" program. You need to detokenize it, that is, convert it to ASCII or load 
it into the M10 as is using a binary transfer utility and then the M10 can list 
it (or run it).

  DETOKE.EXE is exactly what you need, but I don't know who has it. I 
didn't see it in the Personal Libraries.

  Can anyone share please?


  -- John.

Re: [M100] Dust Covers

[MikeS]

I've got a couple of the clear original ones like the one that Brian pointed 
to; they're a nice fit and protect the screen & keyboard from something dropped 
or placed on the unit.

- Original Message - 
From: "C. Magaret" 
To: 
Sent: Tuesday, February 05, 2019 4:25 PM
Subject: Re: [M100] Dust Covers


I believe this is the black plastic cover that is being discussed here:

http://www.megarat.com/tmp/m100_cover.jpeg

I recall that it was originally billed for the purpose of protecting the M100’s 
screen and keyboard during travel, and two of its selling points were that it 
was form-fitted enough so that (a) it would stay on by itself, and (b) have a 
low-enough profile that an M100 with a cover attached attached would still fit 
into its original black slipcase.  Perhaps the plastic of this cover has shrunk 
over time, because neither of those details apply.  

As it stands, this particular cover would suffice as a stylish dust shield for 
a stationary unit, but that’s about it.

Cam



> On Feb 5, 2019, at 08:24, VANDEN BOSSCHE JAN  
> wrote:
> 
> With those 'deep' mechanical switches, it probably wasn't…
>  
>  
> Jan
>  
> From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of JIM FARLEY
> Sent: maandag 4 februari 2019 21:49
> To: m...@bitchin100.com
> Subject: Re: [M100] Dust Covers
>  
> Back in the 'old days', the late 1970s thru early 1990s, at the telcom 
> company for which I worked, we used translucent plastic computer covers which 
> would protect the computer/terminal if the overhead sprinklers went off.  I 
> don't remember dust being a major concern.
>  
> Jim Farley
>  
>  
> VIVAQUA et HYDROBRU ont fusionné. 
> VIVAQUA est votre société d'eau en Région de Bruxelles-Capitale.
> 
> VIVAQUA en HYDROBRU zijn gefusioneerd. 
> VIVAQUA is uw waterbedrijf in het Brusselse Hoofdstedelijk Gewest.
> 
>  Rejoignez-nous sur Facebook - Volg ons op Facebook
> 
> 
> DISCLAIMER
> 
> Pensez à l’environnement, n’imprimez cette page et ses annexes que si c’est 
> nécessaire. Ce message électronique, y compris ses annexes, est confidentiel 
> et réservé à l’attention de son destinataire. Si vous n’êtes pas le 
> destinataire de ce message, merci de le détruire et d’en informer 
> l’expéditeur. Toute divulgation, copie ou utilisation de ce mail est dans ce 
> cas interdite. La sécurité et l’exactitude des transmissions de messages 
> électroniques ne peuvent être garanties.
> 
> Denk aan het milieu; druk deze pagina en de bijlagen alleen af als het nodig 
> is. Dit e-mailbericht (inclusief zijn bijlagen) is vertrouwelijk en is 
> uitsluitend bestemd voor de geadresseerde. Als dit bericht niet voor u 
> bestemd is, wordt u verzocht het te wissen en de afzender te informeren. Het 
> is in dat geval niet toegestaan dit bericht te verspreiden, te kopiëren of te 
> gebruiken. We kunnen niet garanderen dat de gegevensoverdracht via het 
> internet veilig en nauwkeurig is.
> 
>   ­­

Re: [M100] Low power check

[MikeS]

Yeah; how could we have missed that /LPS signal all this time...

Thanks, Kurt!
  - Original Message - 
  From: Stephen Adolph 
  To: m...@bitchin100.com 
  Sent: Thursday, June 28, 2018 1:58 PM
  Subject: Re: [M100] Low power check


  Wow.  Very nice.  Learn something new every day.

  On Thursday, June 28, 2018, Kurt McCullum  wrote:

Will,



Found it in the Robert Covington's M100 ports/registers file. Port D0 (208) 
is where the low power signal is. The file indicates this is the same for both 
the 100 and 200.



PRINT INP(208)



That command should give you the status of the power. Bit 7 is the 
indicator so the value will change by 128.



Kurt





On Thu, Jun 28, 2018, at 10:32 AM, Kurt McCullum wrote:

  It's actually a INP(216) command not a PEEK(216). I didn't realize that 
when I first posted. But the memory locations on the 200 would be different 
than the NEC.



  So for the NEC, in BASIC the following command would show the value:

  PRINT INP(216)



  Kurt





  On Thu, Jun 28, 2018, at 9:53 AM, William Winter wrote:

FYI... I just tried the PEEK (216) on my Model 100 and it returned 85 
with both the battery light on and off. 



-Will



On Thu, Jun 28, 2018 at 12:42 PM Kurt McCullum  
wrote:



  That's what I was afraid of. However, I did find something that is 
worth a try when I get home tonight. In the NEC 8201 technical manual (yes I 
read these things) on page 256, it looks like bit 7 of memory location D8 (216) 
is set when there is a low power signal.  If that is correct, a PEAK(216) which 
returns a value greater than 127 should indicate a low power state. But I'll 
have to test this later since I am not in front of the machine.



  Kurt





  On Thu, Jun 28, 2018, at 9:16 AM, Stephen Adolph wrote:

no, I don't think so.  there is no A/D function or alarm point that 
is readable.  would have been a good idea.



On Thu, Jun 28, 2018 at 12:11 PM, Kurt McCullum 
 wrote:



  Is there a PEEK I can do in BASIC to see if the low power light 
is on. I would assume that the 100/200/NEC all have different locations in 
memory but is this possible?





  Kurt

Re: [M100] Tandy Portable Disk Drive...

[MikeS]

No one knows what happens in private off-list ...(except the NSA of course, but 
they don't care ;-)

m
  - Original Message - 
  From: Kevin Becker 
  To: m...@bitchin100.com 
  Sent: Monday, March 26, 2018 1:00 PM
  Subject: Re: [M100] Tandy Portable Disk Drive...


  I'd really like a copy to try.  The Color Computer community seems to be 
pretty fast and loose with old copyright abandonware but I don't know what 
people's thoughts are about it here. 


  On Sun, Mar 25, 2018 at 12:56 PM, Chris Kmiec  wrote:

Unless there are any objections, I can share the .CO file here.


Chris


On Sun, Mar 25, 2018 at 7:36 AM, Kevin Becker  wrote:

  Is this available somewhere? I’d be curious to try an official Tandy 
video game on the M100. 


  - Kevin



  On Mar 25, 2018, at 7:54 AM, Chris Kmiec  wrote:


One thing I did manage to do last night though was to load one of the 
original cassette programs - a game called Starblaze 100 by Tandy from 1983. 
First time I've used a cassette to load a program in probably 30 years!


Chris


On Sun, Mar 25, 2018 at 6:47 AM, Chris Kmiec  wrote:

  Ha, cleaned with my disk cleaning kit...


  Chris


  On Sat, Mar 24, 2018 at 7:17 PM, Fugu ME100  
wrote:






Might need the heads cleaning?  








From: M100  on behalf of Chris 
Kmiec 
Sent: Sunday, March 25, 2018 00:14

To: m...@bitchin100.com
Subject: Re: [M100] Tandy Portable Disk Drive...

That's a little above my pay grade :) I'm a software guy, and have 
learned just enough hardware skills to be dangerous. I'm spending my limited 
skills and time on troubleshooting the DVI original drive with blown caps while 
waiting for a replacement... 


Chris


On Sat, Mar 24, 2018 at 7:06 PM, Fugu ME100  
wrote:

  OK.  All the internal voltages on the drive are good?  






--

  From: M100  on behalf of Chris 
Kmiec 
  Sent: Sunday, March 25, 2018 00:02
  To: m...@bitchin100.com
  Subject: Re: [M100] Tandy Portable Disk Drive... 

  I don't think that's the issue as the drive responds to commands, 
and I can see the head move. When trying to format a blank disk, it actually 
goes through the motions, and gets to the last track, before it fails. 


  Chris


  On Sat, Mar 24, 2018 at 6:57 PM, Fugu ME100  
wrote:

I/O Error generally means the drive is not being seen on the 
serial port.  Does the serial port on the machine work?  Can you check it out 
make sure it is working? Link to a PC and use TELECOM to a terminal program or 
try the new mcomm out.   





Could be a bad TPDD cable I had problems with mine it was not 
making good contact into the drive, I had to have it just in the right position 
to work.  I stopped using it after that :)   








From: M100  on behalf of 
Chris Kmiec 
Sent: Saturday, March 24, 2018 23:46
To: m...@bitchin100.com
Subject: Re: [M100] Tandy Portable Disk Drive... 

Well, I have REX, with TS-DOS, and also tried the 
installation/bootup procedure from the manual. Didn't work either way - I/O 
Error. I looked over the board, and don't see anything obvious. Everything 
cleaned, etc. 


My "big score" with a DVI, TPDD, and M100 has had an issue with 
every single component... At least it came with a ton of cables, manuals, and 
disks! 


Unless somebody can suggest anything else I can try, I'm giving 
up on the TPDD for now, too many things I'm working on, including getting the 
drive in the DVI to work.


Chris


On Thu, Mar 22, 2018 at 9:20 AM, Brian White 
 wrote:

  The "M100SIG" archive contains a few programs just for 
dealing with the incompatibility of different dosses. There is at least one or 
two programs just for loading and unloading the dvi dos and a tpdd dos so you 
can switch between them without actually wiping and reinstalling each time. 






There is (on p. 7 of the TPDD2 Manual) a cryptic related 
reference that the utility disk can’t be used with a computer in conjunction 
with the DVI, so maybe these can’t all be used at once,


  -- 
  

Re: [M100] List of wanna haves

[MikeS]

Duh; of course the DVI has a 40 column mode...

- Original Message - 
  From: Mike Stein 
  To: m...@bitchin100.com 
  Sent: Wednesday, February 14, 2018 11:24 AM
  Subject: Re: [M100] List of wanna haves


  Now, now, Jan, no need to get snippy ;-)

  Although I'm pretty sure that the answer is as Brian posted, I did (and still 
do) want to do some testing  on a real DVI as you asked instead of making an 
assumption; I thought about the same thing quite a few years ago and did some 
investigating, even disassembling parts of the Disk BASIC overlay, but 
unfortunately can't find my notes from that time.

  Unfortunately I didn't realize that this was an urgent issue requiring 
immediate action and thought it could wait until I could find some time to dig 
the DVI out of storage, find a monitor, hook up an LA, etc. etc.

  Sorry you couldn't wait; that's the trouble with asking hobbyists to do 
something for you...

  I understand that you want a solution that connects through the system bus 
and emulates DVI video exactly; I just wanted to display the M100's screen 
across the room on a 40" TV while comfortably reposing an the couch playing 
games, so I chose the easy way using the serial port.

  I thought maybe this would be interesting while waiting for Ken's complete 
solution (especially since using the com port allows a wireless Bluetooth 
connection), but apparently not, so I was curious what you and others wanted to 
do that this didn't satisfy.

  As John pointed out it does tie up the serial port, but it seems that you 
might also be able to use the same connection with TS-DOS or similar.

  BTW, there's also an article in Portable100 about using the parallel port, 
but although I happen to have the exact obsolete hardware used it looked a lot 
more complicated and limiting.

  I'm not sure where you're getting '40 x 16' video as in your other post; 
AFAIR it's either the normal 8 x 40 or 24/25 x 80.

  One other thing: the DVI is text only; if you're going to the trouble (as Ken 
probably will) then you might want to also add graphics (even if only the PSET 
etc. functions) and maybe even colour, which will obviously complicate the 
situation somewhat.

  m
- Original Message - 
From: VANDEN BOSSCHE JAN 
To: m...@bitchin100.com 
Sent: Wednesday, February 14, 2018 8:33 AM
Subject: Re: [M100] List of wanna haves


What's so interesting abou an external screen ? I can hook up a HDMI 24" 
screen to my modern laptop, but you don't see me hauling one around. It is just 
another thing that makes working on you computers a bit more comfortable when 
you're not on the move. You only use your Model T when you travel ?

 

The DVI is the old-school equivalent of a docking station or a 
port-replicator. Why would it be useless to re-create that with modern 
technology, certainly now that 'its so cheap?

 

Anyway, forget it, forget I asked. I have gotten the impression that by 
asking something that doesn't sound useful for the technical guys, I have 
irritated those people. 

Sorry guys, I won't do it again. Just drop it.

 

Greetings from the TyRannoSaurus / Jan-80@work

 

From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of John R. 
Hogerhuis
Sent: dinsdag 13 februari 2018 20:16
To: m...@bitchin100.com
Subject: Re: [M100] List of wanna haves

 

 

On Tue, Feb 13, 2018 at 11:02 AM Mike Stein  wrote:

  I guess the thing that makes it relatively uninteresting for me is that 
you'll have to be tethered to a display of some kind, which negates the most 
attractive aspect of the ModelT, its portability; you might as well just run VT 
on a laptop.

   

  m

 

Well might nice for dev on real hardware. But the only time I do that is 
when I’m testing serial port stuff so, yeah. 

 

Which I think is why when we’ve talked about this before the parallel port 
seems the better way. But then you need even more hardware. 

 

— John. 

VIVAQUA et HYDROBRU ont fusionné. 
VIVAQUA est votre société d'eau en Région de Bruxelles-Capitale. 

VIVAQUA en HYDROBRU zijn gefusioneerd. 
VIVAQUA is uw waterbedrijf in het Brusselse Hoofdstedelijk Gewest. 

 Rejoignez-nous sur Facebook - Volg ons op Facebook 



DISCLAIMER

Pensez à l’environnement, n’imprimez cette page et ses annexes que si c’est 
nécessaire. Ce message électronique, y compris ses annexes, est confidentiel et 
réservé à l’attention de son destinataire. Si vous n’êtes pas le destinataire 
de ce message, merci de le détruire et d’en informer l’expéditeur. Toute 
divulgation, copie ou utilisation de ce mail est dans ce cas interdite. La 
sécurité et l’exactitude des transmissions de messages électroniques ne peuvent 
être garanties.

Denk aan het milieu; druk deze pagina en de bijlagen alleen af als het 
nodig is. Dit e-mailbericht (inclusief zijn bijlagen) is 

Re: [M100] Re-assembly of 102... again

[MikeS]

Yup, the green wires are standard, as are the mods around the cassette port.

 As Josh suggests, it's easier to assemble face down; watch out for the reset 
button!

Good luck!

  - Original Message - 
  From: Chris Kmiec 
  To: m...@bitchin100.com 
  Sent: Sunday, February 11, 2018 5:16 PM
  Subject: [M100] Re-assembly of 102... again


  Ok, I'm about ready to go Office Space on my Tandy 102. I've taken it apart a 
while back to remove the NiCd battery, and had a hell of a time putting it back 
together. Thought it worked fine, but now that I got a REX and have started 
playing with it, something was off - the entire keyboard was bowing, etc. Took 
it apart again, and now I just can't make it fit at all...


  Here is what's happening:


  1. I have the motherboard laying nice and flat, and it appears to fit well. 
All switches are properly aligned. The motherboard does have a thick green 
cable on the back - is that original? (Picture attached)


  2. The LCD fits into two holes on left and pegs on the right - appears to be 
correct.


  3. The keyboard... If I just lay it flat, with no support, it has a pivot 
point around the middle, length-wise. I can put the top case on it, and it more 
or less fits, but the bottom of the keyboard has too much give. If I put the 3 
support blocks as I remember them (picture attached), the keyboard is nice and 
sturdy, BUT I cannot fit the top case on - it's either tight on top or bottom, 
and if I force it down, the outside functions keys don't work, no matter how 
well I align everything.


  Sorry for the long post, but I REALLY want to get this assembled properly. 
Can anyone tell me what am I doing wrong? Are the support blocks in the wrong 
spot? Am I missing a step? 


  Thanks for any help...


  https://1drv.ms/f/s!AiOtw8Sr4zlvjYB6sYuFRJhwZ_WtPw

Re: [M100] EPROM equipment

[MikeS]

What do you want to burn?
  - Original Message - 
  From: Darryl Pruett 
  To: m100@lists.bitchin100.com 
  Sent: Friday, February 09, 2018 9:50 PM
  Subject: [M100] EPROM equipment


  What’s the best burner for model Ts ?

Re: [M100] HD44103 data sheet

[MikeS]

Works for me (have to join the two parts)

  - Original Message - 
  From: Gregory McGill 
  To: m...@bitchin100.com 
  Sent: Monday, February 05, 2018 11:42 AM
  Subject: Re: [M100] HD44103 data sheet


  link is broken


  On Sun, Feb 4, 2018 at 11:44 PM, Brian White  wrote:

The most commonly found data sheet for the HD44103 lcd driver chip on the 
lcd pcb is pretty low quality and doesn't include a pinout for the QFP-44 
package used in the M100.

I extracted a nicer version of the data sheet from a larger combined pdf 
(Hitachi-LCD.pdf) that had sheets for several related chips, and worked out the 
pinout from looking at the m100 service manual, and found an editable SVG 
template for qfp-44 and assembled a new pdf for hd44103 with the nice clean 
main data sheet and with a page inserted for the qfp-44 diagram. The rest of 
the datasheet still refers to only the FP-60 pin numbers, but you can ignore 
the pin numbers and just use the signal names VCC, X1, V1, etc...


​I extracted a nicer pdf for HD44012 also, but ​that didn't need any 
additions or changes. It's just a clearer version of the same info. It might be 
a little more complete. The source document Hitachi-LCD.pdf seems to be a later 
version than the scanned fax looking version that you find on most datasheet 
sites.


https://drive.google.com/open? ​​id=13ITleFmcEjuzxSp1kvVipo__T1ec2KmT



-- 

bkw

Re: [M100] How to dump ROM(s)?

[MikeS]

ROMCOM for sure, but wouldn't R2D also work with DL or Laddie?

m
  - Original Message - 
  From: Stephen Adolph 
  To: m...@bitchin100.com 
  Sent: Thursday, November 23, 2017 3:35 PM
  Subject: Re: [M100] How to dump ROM(s)?


  ROMCOM does it.  R2D is Rom to Disk.  I seem to recall making a program also. 
 ROMCOM gives you binary out.  My program gives you ascii hex.

  ROMCOM:
  ftp://ftp.whtech.com/club100/eme/romcom.100


  mine:
  
http://club100.org/memfiles/index.php?=0==Steve%20Adolph/ROM2S





  On Thu, Nov 23, 2017 at 1:00 PM, Mike Stein  wrote:

I think one of the EXTRAM programs (R2D?) does that; are you set up to 
communicate with a PC?

m
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Thursday, November 23, 2017 12:44 PM
  Subject: Re: [M100] How to dump ROM(s)?




  On Thu, Nov 23, 2017 at 9:41 AM  wrote:

The easiest way would be to PEEK through the address space (maybe 4 or
8K at a time) and output the values somewhere (maybe over serial to
another PC).




  You need an machine language program that runs from RAM to dump an option 
rom.


  I’m sure someone has written one, hopefully they’ll post a link.  


  — John. 

Re: [M100] model 200 dvi cable

[MikeS]

I sent a picture on Oct. 17. Normal crimp-on male header plug with twisted 
wires.

m
  - Original Message - 
  From: Brian White 
  To: m...@bitchin100.com 
  Sent: Wednesday, November 08, 2017 6:54 PM
  Subject: [M100] model 200 dvi cable


  Does anyone have a picture of a real original dvi cable for model 200? 
Specifically, the plug that goes in the 200?

  I have a working cable using standard female plugs on both ends, plus a pin 
header gender changer stuck in the 200 end.


  It works fine and is cheap and easy to make, and it's fine for myself and 
most people to use, assuming they are the same people who read the directions 
that said "plug it in this way..." and not a grandkid a few years later who 
found all the stuff in a box.

  But I don't just want a cable. I want to document how to make a cable, and 
for that this isn't great.
  * It's not polarity keyed.
  * When you unplug from the 200, the pin header is equally likely to stay in 
the 200 as on the cable, so, you would have to glue the pin header to the cable 
or something if you don't want to keep prying and digging at the 200. Or use 
two cables with the pin header in the middle (blech).
  * Male pins should be shrouded to protect them from shorting on things.
  * Male pins should be shrouded to protect them from getting bent.


  For model 102 it's easy. A standard idc male box header fits. It's more of a 
pain in the neck to build the cable, since you have to seperate and twist the 
wires, but the end result is a cable that is safely polarity keyed on both ends 
and the pins are shrouded.


  But the opening around the bus connector on the model 200 is smaller, and the 
box header doesnt' fit, at least not the crimp-on ones.

  So I'm wondering what did they give to customers originally? A cable made 
with a soldered box header? (the shroud is smaller on those and might possibly 
fit in the opening) Some funky custom made plug? A part that used to be 
off-the-shelf but just isn't any more (like the molex option rom)? Exposed pins 
with no polarity mechanism or protection?

  I suppose one way you could at least make your own polarity key without 
getting too crazy with fabricating, is just by gluing a single piece of 
something flat and strong to the non-notched side of the plug, to make a solid 
wall along one row of pins. If you try to plug in the wrong way, the wall will 
hit the polarity bump in the model 200.


  -- 
  bkw

Re: [M100] DVI cable

[MikeS]

What's the make/model of the HD drive? Might be trivial to configure it to read 
a DD diskette.

Do you only have one system disk?
  - Original Message - 
  From: Brian White 
  To: m...@bitchin100.com 
  Sent: Saturday, October 28, 2017 1:50 AM
  Subject: Re: [M100] DVI cable


  Welp, the dvi spins the motor on a 1.2m drive.


  So I looked at the bad drive and found a small patch of corroded traces and 
solder joints. The patch is under a couple small electrolytic caps that don't 
look swelled or leaking, but there's nothing else to explain the corroded spot.


  I cleaned up the area and re-soldered some parts and replaced a couple of 
traces with wire.


  Now the drive spins, and the dvi recognizes that the door was closed, and 
tries to read the disk.


  But now it says Drive0 is not a system disk.


  So I might have a bad boot disk, or this drive might still have some other 
issues.


  Oh well. Closer!


  -- 
  bkw




  On Oct 27, 2017 1:31 PM, "Brian White"  wrote:



  0: Everything turned off. Everything connected. Drive door open. No disk 
in drive. Monitor on.


  1: M100 on.


  2: DVI on.


  3: Wait for dvi to say "Insert System Diskette"


  4: Insert disk and close drive door.


  ...doesn't matter what comes next, because nothing else happens.


  --
  Motor doesn't spin? Light does not come on?
  --


Light comes on before even inserting a disk or closing the door, which is 
odd, but is what the manual says to expect.


Main motor does not spin or even twitch at all. With the cover off the dvi, 
I can feel the bottom of the motor itself, where the speed calibration sticker 
is, so I'm not relying just on sound.


Certainly the first step is to just plug some other drive into the dvi or 
plug this drive into something else.


I don't have any half height 360k drives handy, but I do have a few 1.2M 
drives. It wouldn't hurt anything to just plug one of those in, and insert a 
scrap disk, just to see if the dvi makes the motor spin. That alone would clear 
the dvi.


Once I know that much, I can get another drive, maybe repair the drive I 
have, or possibly figure out the jumpers on my 1.2M drive to get it to work as 
a 360k drive.


-- 
bkw

[M100] VT on 64bit Win 7

[MikeS]

I'm trying to bring a friend into the wonderful world of Virtual T and the M100.

There shouldn't be any issues installing/running VirtualT on a 64 bit Windows 7 
machine, should there? He seems to be having some trouble.

Thanks,

m

Re: [M100] Questions regarding REX and file transfer

[MikeS]

That'd be my first choice to get started if we're dealing with a PC with a real 
com port; I think a USB<>RS232 converter would probably be a problem.

You M100 owners should also determine whether you have the old or the new 
version; IIRC serial numbers starting with around 311 are the threshold.

m
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Monday, September 18, 2017 7:04 PM
  Subject: Re: [M100] Questions regarding REX and file transfer


  Also for binary file transfers is TEENY.CO client.


  Much smaller, less than 800 bytes I think.

  Compared to, I think, 8K for the RAM version of TS-DOS.


  -- John.

Re: [M100] The list archive search function is fixed

[MikeS]

Thanks, John!
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Tuesday, August 29, 2017 3:55 PM
  Subject: [M100] The list archive search function is fixed


  I got notified by Dreamhost that our list archive Search box is fixed (htdig 
error no longer happens).


  I gave it a quick go and it seems to be functioning.


  -- John.

Re: [M100] Model 100 serial port

[MikeS]

6.7V indeed does not sound good, but there aren't any 148x chips in there, just 
a 4584 biased at +/- 5V.

What's the Vcc of the 6402 (pin 1 of M22) ?

m

- Original Message - 
From: "Francesco Messineo" 
To: 
Sent: Thursday, August 03, 2017 3:49 AM
Subject: Re: [M100] Model 100 serial port


> On Thu, Aug 3, 2017 at 12:01 AM, Kurt McCullum  wrote:
>> Testing thus far reveals that pin 25 of the UART doesn't fluctuate at all. 
>> It sits a 6.7 volts even when I'm not sending data. I wrote a BASIC program 
>> that sends a character, waits a half a second then sends another.
> 
> 6.7V doesn't sound right when talking about a 5V part (the UART).
> i'd remove the level translator chip (148x) and try again.
> 
>>
>> I'll do more testing but my first impression is that it's the UART.
>>
>> Kurt
>>
>> -Original Message-
>> From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of John 
>> Gardner
>> Sent: Wednesday, August 02, 2017 9:24 AM
>> To: m...@bitchin100.com
>> Subject: Re: [M100] Model 100 serial port
>>
>> ...the problem is somewhere between the db25 and the UART...
>>
>> Most likely.  I'm no great troubleshooter,  but if I may...
>>
>> Set up a test file which contains a long series of 0xAAs,  as in
>>
>> 10101010...
>>
>> Send the file at a baud rate which is easy for you to see with
>>
>> whatever you've got for test equipment.
>>
>> While the file is being sent,  look for the signal.  When you find it,
>>
>> the fault is between that point & the DB25.  I expect the problem
>>
>> is either a PCB trace,  solder joint,  a defective buffer,  or the DB25
>>
>> connector itself (It happens...).
>>
>> There's also a small possibility that the UART is at fault,  but not likely.
>>
>> I'd be interested to hear what you find.
>>
>>
>>
>>
>>
>> On 8/2/17, John R. Hogerhuis  wrote:
>>> Well the good news is the problem is somewhere between the db25 and
>>> the UART :-)
>>>
>>> -- John.
>>>
>>

Re: [M100] Molex part number

[MikeS]

Pretty cool indeed!

- Original Message - 
  From: Brian White 
  To: m...@bitchin100.com 
  Sent: Thursday, July 20, 2017 10:39 PM
  Subject: Re: [M100] Molex part number


  One of my Shapeways orders came in.


  This is the cheapest option Shapeways offers, and it turns out the cheapest 
lowest quality option (from Shapeways) is good enough.


  The white one is the "White Strong Flexible", with no extra finishing options 
added.


  The black one is the same thing just black.


  The print is accurate enough that everything fits perfect, and the material 
is strong enough that it doesn't break when you install or remove the module 
from the socket.



  I have a couple more still on the way, in more expensive material and quality 
options.


  This is cool but not really that useful except for Model 600.


  This is great for 600, because 600 takes a standard 27C256 pinout. Just slap 
a 27C256 in the carrier and you have a model 600 option rom.


  But 100, 102, and 200 don't have a normal pinout, so the only way this could 
be used is if you had some kind of pcb in the carrier instead of a normal dip28 
chip.


  Hm, that might be a neat idea after all. You could pack a rex or a figtronix 
into one instead of using extraction ribbons and pieces of cardstock spacers. 
We could modify the cad file pretty easily to make a version customized to fit 
a REX exactly. Then you get the key slots so you can't plug the rom in 
backwards, and it's just a cleaner tidier little module than one with ribbon 
and cardboard.


  Pretty cool!


  https://photos.app.goo.gl/IHQCxST40Cp72NLj1


  https://drive.google.com/folderview?id=0Bys6eLbSbYyhTFItVWZjU2xJd0E



  -- 
  bkw

Re: [M100] Directory entry status bits?

[MikeS]

Is  p. 72 of Hidden Powers relevant? 
"bit 7 is 1 if the entry is currently being used and 0 if it is invalid."

BTW, just curious: what function of REX is the most valuable for you?

m


- Original Message - 
From: "Willard Goosey" 
To: "m100 list" 
Sent: Thursday, June 29, 2017 8:37 PM
Subject: [M100] Directory entry status bits?


> So I grabbed the NEC 8201 Technical Reference. I see part of what I've
> been doing wrong... (so many cold starts! Thank Skuld for REX!!!)
> 
> On the NEC bit 1 of the Directory entry status byte (0010b) is the
> Open File flag. I can't seem to find anything in my Model 100 docs to
> confirm this. Is it the same for the M100?
> 
> Willard
> -- 
> Willard Goosey  goo...@sdc.org
> Socorro, New Mexico, USA
> I search my heart and find Cimmeria, land of Darkness and the Night.
>  -- R.E. Howard

Re: [M100] List rules reminder

[MikeS]

+1
  - Original Message - 
  From: Bob Pigford 
  To: m...@bitchin100.com 
  Sent: Friday, June 16, 2017 8:00 PM
  Subject: Re: [M100] List rules reminder


  Thanks, John!  This is the most helpful and respectful list I know use.  I 
appreciate each and every member for their comments and offers to help newbies! 
 

Re: [M100] Translating BASIC code from 100 to NEC.

[MikeS]

By the way:

Not all those lines need to be changed; don't change lines 3, 6, 7, 9, 10 and 
18.

15 and 16 can be tricky ;-)

If MID$ is at the beginning of a line or immediately after a ":" or a "THEN" 
then it needs to be changed; otherwise it's OK as it is.

It's handy, but in my opinion the fact that in the M100 it can have two 
different meanings actually makes it more confusing than the straightforward 
NEC version.

As to your comment, "Such a shame, really a hard life for guys that want to 
program on NEC," you'd say the same thing about the M100 if you were converting 
a NEC program to the M100... ;-)

m




- Original Message - 
From: "NEC" 
To: 
Sent: Wednesday, June 14, 2017 3:53 PM
Subject: [M100] Translating BASIC code from 100 to NEC.


> Hi folks.
> My first post as new member here in the list.
> I'm trying to translate a BASIC program from TRS 80/100 to NEC 8201A.
> In order to do it more easily I'm using the BASCON v2.0 conversion utility by 
> Gary Weber. 
> After running that utility I get a converted BASIC code together with a .RPT 
> file where the outcome of the conversion is written.
> In the report it's written that some program's lines have to be investigated 
> due occurrences of MID$ that should be better to check for their usage as an 
> assignment.
> The actual message is this:
> 
> BASCON v2.0 - Conversion of 100.BA to NEC.BA
> Date/Time: 06-12-2017 12:41:58
> 
> *** Lines to investigate:
> 
> Line XXX --  Occurrence(s) of MID$ (check for usage as an assignment)
> 
> The lines involved are these:
> 
> 1 MID$(PB$(1),4,5)=LEFT$(D$,5) 
> 
> 2 MID$(PB$(1),10,4)="19"+RIGHT$(D$,2):MID$(PB$(2),4,8)=T$:CLS 
> 
> 3 J=ASC(MID$(PA$(Y%),X%,1))-48:IF J<1OR J>5THEN340
> 
> 4 MID$(PB$(Y%),X%,1)=K$:PRINT K$; 
> 
> 5 IF X%=4AND Y%=6THEN MID$(PB$(Y%),X%+1,11)=SPACE$(11):GOSUB1970 
> 
> 6 A2=(M/60+D)/360*P2:IF MID$(PB$(3),13,1)="S"THEN A2=-A2 
> 
> 7 IF MID$(PB$(4),13,1)="W"THEN O2=-O2 
> 
> 8 R=5:C=4:N=3:GOSUB1960:F2=V*P2/360:IF V<1THEN MID$(PB$(5),5,1)="9":GOTO280
> 
> 9 FOR I=1 TO NB%:IF MID$(PB$(6),4,LEN(BN$(I)))=BN$(I) THEN680
> 
> 10 L2=(D+M/60)/360*P2:IF MID$(PB$(8),4,1)="-" THEN L2=-L2
> 
> 11 MID$(PB$(6),4,12)=SPACE$(12):GOSUB1970
> 
> 12 
> MID$(PB$(6),4,12)=BN$(I)+SPACE$(9):T0!=BC!(I,0):T1!=BC!(I,1):T2!=BC!(I,2):GOTO1720
> 
> 13 T2!=SQR(ABS(1-T0!*T0!-T1!*T1!)):MID$(PB$(6),4,12)=SPACE$(12)
> 
> 14 MID$(PB$(8),4,1)=D$:A=ABS(M3*10):GOSUB1980:T$=" ":IF M3<0 THEN T$="-" 
> 
> 15 MID$(PB$(5),12,4)=T$+MID$(D$,5,1)+"."+MID$(D$,6,1):GOSUB1970:RETURN 
> 
> 16 MID$(PB$(B),4,3)=MID$(D$,1,3):MID$(PB$(B),8,2)=MID$(D$,4,2)
> 
> 17 MID$(PB$(B),11,1)=MID$(D$,6,1):RETURN
> 
> 18 V=VAL(MID$(PB$(R),C,N)):RETURN
> 
> ---
> 
> Line 1 is the only one that BASCON rewrites differently from the original:
> 
> ORIGINAL LINE: 1 MID$(PB$(1),4,5)=LEFT$(D$,5) 
> 
> Same line as converted by BASCON: 1 
> PB$(1)=LEFT$(D$,5)+RIGHT$(PB$(1),LENPB$(1)-4)++RIGHT$(PB$(1),LENPB$(1)-5)
> 
> I guess the double "+" just before RIGHT$(PB$(1),LENPB$(1)-5) it's a spurious 
> typo from BASCON.
> Anyway, single "+" or double "+", it doesn't work.
> 
> On http://bitchin100.com/wiki/index.php?title=Synchronize_Time_with_your_NADS 
> and especially In "Designing cross-compatible programs for Model 100 to NEC 
> 8201A/8300" on http://www.web8201.net/ there are some explanations about how 
> simulate the function of a MID$ assignment with a routine like this:
> 
> 3 ZO=LEN(OX$):TX$=OX$:OX$=LEFT$(TX$,NX-1)+NX$
> 30010 IFZO-LEN(OX$)>0THENOX$=OX$+RIGHT$(TX$,ZO-LEN(OX$))
> 30020 OX$=LEFT$(OX$,ZO):RETURN
> 30030 ' MID$ by Gary Weber
> 30040 ' Entry: OX$=String to modify, NX=Target position, NX$=Target text
> 30050 ' Exit: OX$ contains modified string
> 
> but honestly I understood little and nothing.
> Is there somebody who can explain me better or pointing to me any inherent 
> document so that I can translate all the 18 lines in the right way for the 
> NEC 8201A?
> 
> Thanks in advance,
> 
> Peppino

Re: [M100] how about using (3) 2/3 AAA nicad cells for the internalbattery?

[MikeS]

The important thing is to open up the computer and make sure that there are no 
signs of leakage. Even if it looks clean it might be a good idea to replace the 
NiCd anyway; whatever you replace it with will probably do a good job for many 
years.

m

- Original Message - 
From: "John Gardner" 
To: 
Cc: 
Sent: Thursday, June 01, 2017 8:04 PM
Subject: Re: [M100] how about using (3) 2/3 AAA nicad cells for the 
internalbattery?


> Dunno about the fit,  but it oughta work.
> 
> If you're at all concerned about cells leaking though,  Mike's
> 
> Li phone battery is a better idea,  IMHO - Alkaline batteries
> 
> are arguably your worst possible choice...
> 
> Might be a good idea to "diode-OR" it   have a healthy
> 
> resistor, say 100K,  between the battery & the rail too.  I don't
> 
> know much about Mike's setup - He'd be the guy to ask.
> 
> On 6/1/17, user evers  wrote:
>> Would there be space for 3x 2/3 AAA cells wired in series for replacing the
>> existing nicad?
>>
>> The 3.6v battery inside is 15mm diameter and AAA cells are 10mm. But twice
>> as long. Maybe just solder in some leads and then hot-glue the battery pack
>> off to the side?
>>

Re: [M100] Oh no - think my internal nicad finally given up theghost

[MikeS]

Have a look at Portable Computing March/86 P. 30; no soldering required:

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

Lithium's another story of course...

m
  - Original Message - 
  From: Josh Malone 
  To: m...@bitchin100.com 
  Sent: Thursday, June 01, 2017 8:39 AM
  Subject: Re: [M100] Oh no - think my internal nicad finally given up theghost


  I've often wanted to build a AA charging circuit into my 102. Or, even an 
internal lithium battery - since I have a 150mA boost converter board lying 
around that I never actually did anything with. Except that I'd still need a 
charging circuit because the board I bought is boost-only and boost+charge 
boards are readily available now.


  *sigh*



  On Thu, Jun 1, 2017 at 2:09 AM, Brian White  wrote:

Oh what a great idea using a cap.


Not just that. I had already heard of doing that, but the caps discharge 
time is shorter than a battery, so I didn't really consider it a good answer 
except for the fun of trying it.


But anyone can make themselves a REX now, and REX provides among other 
things, on-board full ram backups.


capacitor + rex = win


If you can easily take a snapshot of your entire ram, saved to the REX's 
flash, then it's no problem if the cap dies in a few days instead of a few 
weeks.



Of course if you're willing to hack even more, sure you could rewire the 
AAs a little and add a real charging circuit, and have it so the AAs *always* 
charge the cap, and the wall power recharges the AAs without removing them, 
just like any modern device. Then you never have to touch the insides again, 
just the battery cover, and even that only every 5 years.


But with the ability to make backups right on-board, you can get away with 
a simple in-place cap swap with no other mods.


Not having to worry about leakers in a few years, or overcharging, would be 
nice.



-- 
bkw


On May 31, 2017 10:08 PM, "Josh Malone"  wrote:



  On Wed, May 31, 2017 at 2:29 PM, John Gardner  wrote:

That's what it is in the 8201a too,  IIRC.  So if the rail is 5V the 
NiCD

is seeing a charge current of ~ 3 mA - Which may explain some of the

resurrections of dormant laptops after prolonged noodling around with

them...

Thanks for sharing!

 ...



On 5/31/17, Josh Malone  wrote:
> The m100 techref schematic shows 1.6k (I think - it's an awful 
photocopy I
> found online)
>
> 
https://dl.google.com/dl/androidjumper/mtp/502266/androidfiletransfer.dmg




  D'oh! I completely posted the wrong link - meant to link to the m100 
techref. Sorry


  In any case, 3mA is more-or-less C/20, so yeah, kindof a slow charge.