Re: [M100] Any further info on TDock?

[Jim Anderson]

Hello (yes, I'm still alive, and still trying to get myself going again on the 
MVT100 font optimization/beautification project...)

I just wanted to chime in here on the use of the MVT100 on the BCR port and my 
experience.  It's *wonderful*.  It's a pretty easy mod inside the machine 
(solder a single jumper wire) and it allows me to use my M100 simultaneously 
with a serial line to a TPDD emulator and a (TTL) serial line to the MVT100 to 
a VGA monitor.  The current version of MVT100 can be powered right off the BCR 
port too (I modified my earlier version board for this, which again is an easy 
single jumper wire mod).  I happen to use this a lot for Wordstar on CP/M but 
it works just as well as the real DVI (imho) for Model T native software.  Huge 
upside vs using the DVI is not having to have a huge box on one's desk, not 
having to have the DVI hooks loaded and the various conflicts I understand this 
creates, and not having to worry about being able to read DVI disks/images on a 
PC because I'm loading/saving my files right to my Nextcloud via LaddieAlpha.

Being able to switch the TPDD emulator easily (ideally via a hotkey or escape 
sequence sent over the serial port) to open a tty session on the host box so I 
could use Linux from the Model T and VGA monitor would be icing.







jim

From: M100  On Behalf Of John R. Hogerhuis
Sent: Tuesday, May 9, 2023 13:16
To: m...@bitchin100.com
Cc: m100@lists.bitchin100.com
Subject: Re: [M100] Any further info on TDock?

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

What do you want it to do?

MVT100 exists. https://bitchin100.com/wiki/index.php?title=VT100

If you want external display and storage, I could possibly create a build of 
LaddieAlpha with a display window, terminal emulation and some kind of serial 
line multiplexing. Then any small form factor computer capable of running Mono 
or .NET with a serial port (pi) could be a dock. But with multiplexing, you 
either have rigid modes or else TPDD, TELCOM, etc have to be aware and 
cooperate with the multiplexer.

Or... IIRC I think MVT100 can use a cassette connector bitbang serial hack... 
which would free up the RS232 connector for file I/O client, TELCOM, ...

-- John.

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

[Jim Anderson]

> -Original Message-
> 
> Did you ever finish whatever it was you still needed to do for rexcpm?
> 
> I don't remember what the problem was supposed to be by now, but I
> remember to keep watching for some update to either cpmupd or to the
> disk image every time I reload my rexcpm, and I only know that the files
> haven't changed.
> 
> I guess for that matter the question should be "What was that problem
> supposed to be again?"

Another chime in from someone who is still around but lurking :)

I didn't want to bring this up because I have my own unfinished project I feel 
guilty about, but I will answer the question.  (My unfinished thing is that I 
started on a project to improve the font used on the MVT100 board, and I made a 
minor improvement to readability of a few characters (6, 9, and Q, I believe) 
which Stephen started distributing with new boards, and then I embarked on a 
project to dramatically improve the rendering of the 80x24 mode font and also 
reproduce the original DVI font, and then I got stalled out partway through the 
character set when Life Happened :( but I do mean to get back to it, I promise)

The thing that I think you're remembering is that there isn't enough directory 
entries in the CP/M image for the 4MB REXCPM.  I discovered this because I was 
filling mine up and I'm only able to use a little more than half the capacity 
IIRC (it might have been more approaching 2/3 capacity).  Philip said he would 
need to re-make the image for 4MB with a greater number of directory entries, 
and that anyone who wanted to use it would of course have to export their 
files, load the new disk image, and re-import their files back.  (A pain to be 
sure, if you've filled it up like I have, but a pain I'm quite willing to 
undergo.)

Two other things I've been hoping for for quite some time, and I'm not sure how 
much of this was Philip's thing and how much was Stephen's thing and/or someone 
else's thing, but there was talk of new versions of import/export which would 
support 8.3 filenames instead of just 6.2 when used with a compatible TPDD 
emulator...

The second thing was 76800bps support when used with a compatible TPDD 
emulator.  I know there's a private version of this floating around somewhere 
because the REX backup/restore utility supports it, and I've been aching to 
make use of it.

Maybe if I get my project moving and released?  My internal guilt makes me not 
want to ask for these things because I have failed so far to deliver on my 
thing... :P







jim

Re: [M100] Model 200 issues with Serial Wi-Fi Adapter

[Jim Anderson]

> -Original Message-
> 
> direct null modem (full cable) between a M102 and a M200, with TERM, the
> M200 will systematically lockup when the M102 hangs up ( EXIT/F8 )
> whereas the reverse is not true.

That completely tracks, because when the T102 (or M100) hangs up, it drops DTR 
(and RTS) which your null cable is sending to the T200 as DSR and CTS.  T200 
sees the loss of DSR and CTS, and TELCOM freezes.  The reverse is not true 
because the T102 (and M100) do not care whether or not they get those signals.

> This with both ends using (or supposed to use) hardware handshake (and
> xon/xoff disabled)

As a side note, TELCOM does not use hardware flow control (aside from locking 
up on the T200), you can only (E)nable or (D)isable software flow control in 
the STAT string.  If you disable software flow control, it doesn't do any flow 
control whatsoever.







jim

Re: [M100] Model 200 issues with Serial Wi-Fi Adapter

[Jim Anderson]

I’ve run into this before with the 200 – I don’t remember if it was CTS or DSR 
or both that it wants to see asserted, but it definitely does behave 
differently from the 100 and 102.  If you don’t have one or both of those lines 
high, the 200 appears to freeze up if you attempt serial communication using 
TELCOM (ctrl-Break recovers).  The 100 and 102 (at least in TELCOM) don’t seem 
to care.

There’s no real harm in jumpering both of these signals high if your wifi modem 
isn’t actively asserting either of them.  In a DB9 you would jumper 7 (RTS) to 
8 (CTS) and 4 (DTR) to 6 (DSR).  In a DB25 those would correspond with 4 to 5 
and 20 to 6.







jim

From: M100  On Behalf Of B 9
Sent: Wednesday, December 21, 2022 11:06
To: m...@bitchin100.com; Joseph Colson III 
Subject: Re: [M100] Model 200 issues with Serial Wi-Fi Adapter

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

That is odd. Handshaking and Carrier Detect can cause peculiar problems, but 
I'm wondering if maybe something else is wrong with the serial port.

I have a Tandy 200 and my belief is that the the serial port is the same as the 
102 (which came later). The only difference I know of is that one needs to add 
the extra letters "NN" to TELCOM's `STAT` command. (For example, `STAT 98N1ENN` 
instead of `STAT 98N1E`). If you forget the extra letters, TELCOM will silently 
ignore the setting.

[image.png]
Does your Tandy 200's serial port work when connecting to anything else? For 
example, to your Tandy 102 via a null modem?

—b9

On Wed, Dec 21, 2022 at 8:29 AM Joseph Colson III 
mailto:joecols...@outlook.com>> wrote:
I have been using a seral Wi-Fi modem with my Model 102 without much fuss for 
the past few days.   I switched it over to the Model 200 and no matter what I 
did I could not get it to work.   I searched the boards and found plenty of 
discussion on flow control on the WiFI232 modem.   While I don’t understand it 
completely, the Model100/102 does not require it while the Model 200 does.  The 
Wifi232 has solderable jumpers to fix this issue.   The board I’m using does 
not have this, so I was considering jumping pins on the DB9 side of the device, 
however I’m not completely sure what I’m supposed to JUMP.I don’t know if 
all that made much sense.   Hopefully, someone can decipher what am asking.

Any Help would be appreciated,

Joe

Re: [M100] is the m100 a trs-80? In walks like a, not is categorized as a

[Jim Anderson]

> -Original Message-
> Then, of course, you have the TRS-80 Model 100 and Tandy 200 computers.
> The Model 100 is almost entirely a rebadge of the Kyocera Kyotronic 85.
> The 200, never sold under the "TRS-80" banner, is incompatible.  The

Not entirely incompatible... it uses the same CPU and general architecture, and 
a lot of BASIC software ought to run on a T200 just fine unless it does 
anything specific to the 40x8 screen layout or makes any system calls.  
Machine-language programs and options ROMs for the M100/T102 won't run on the 
T200 of course, without modification (a number of titles were ported over).







jim

[M100] oh, and Hello again

[Jim Anderson]

Sorry I vanished for most of this year - depression is not a good place to be.

I am hoping to get rolling and finish off the font redesign for the MVT100 
board I was working on last winter.  I think Stephen had started sharing the 
interim firmware I made which had initial M100 graphic characters added and 
some minor readability improvements to some of the characters (particularly the 
numbers 6 and 9).

I haven't been keeping up with this list, just filing the messages in the hope 
I'd pull myself up and start reading them - it's quite the backlog so I don't 
know if I will get there or not, so I don't know if I've missed any big 
developments in the REX or REXCPM worlds - I think the big one I was hoping for 
was a new 4mb CP/M image with more file handles/descriptors... and of course, 
the first message I read in a long time this morning stirred some hope of using 
the M100 CP/M with an external keyboard when stationary!

Glad to see you all again, and hope I can stay on top of things for a while.







jim

Re: [M100] Re-directing CP/M console to serial port in REXCPM

[Jim Anderson]

First thought that comes to mind: it may be stopping because of the feature 
which pauses the screen output after 8 lines of consecutive output – try 
Label-F1-Label to toggle ‘Sc L’ to ‘Sc S’ to disable this before redirecting 
the console?

I’m glad to see this post because I honestly had been thinking a while back 
that “I wish there was a way to use a ps/2 keyboard with my MVT100 board as a 
full-blown terminal” but didn’t try anything because I’m not familiar enough 
with CP/M to know how to redirect the console like that.  What baud rate does 
it end up using when you do this?







jim

From: M100  On Behalf Of Tom Hoppe
Sent: Tuesday, November 16, 2021 10:50
To: m...@bitchin100.com
Subject: [M100] Re-directing CP/M console to serial port in REXCPM

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

I am trying to re-direct the REXCPM console to the M100 serial port but only 
having limited success. I am using 'stat con:=uc1:' to do the re-direct. It 
seems to work for a minute, then stops. I am using minicom in Linux and it 
works reliably using the REXCPM 'F3 toggle' feature to re-direct only the 
screen output (19200 8N1). Has anyone else tried doing this successfully?

Tom Hoppe

Re: [M100] linux file transfer with dl works

[Jim Anderson]

> -Original Message-
> So far I've only figured out how to use TS-DOS and it works fine. I can
> access the DRIVE and LOAD the files.
> A .DO file works great. A .BA file will transfer but never run.
> I understood from previous conversations that what I should do is rename
> the .BA files to .DO files. But that doesn't work. I can't rename the
> files to .BA. 

So, there are a couple of things here.  Transferring a .BA file that is a plain 
ASCII (ie. readable text) BASIC program will not work, and will end up causing 
you filesystem corruption in your Model T.  So, the first thing you need to do 
is determine whether the .BA file you want to transfer is in fact plain ASCII 
text or is a tokenized basic program.

Have a look at the .BA file on your computer.  I think you mentioned you were 
running Linux, so try looking at it in a text editor, or with 'more' or 'cat' 
or whatever utility you want.  If you see a plain text BASIC program with line 
numbers and intelligible statements, it's plain ASCII text.  If you see a bunch 
of 'garbage' with some text mixed in, but no line numbers or PRINT statements 
etc, the file is what is called 'tokenized BASIC' and should be transferrable 
as-is.

If the file is plain readable ASCII, then you need to rename it.  I think from 
what you described in a previous message that you are trying to rename it to a 
.DO file by hitting F1 in TS-DOS and then typing FILE.DO as the local name.  As 
I mentioned in a previous message, THIS WILL NOT WORK.  You can only rename the 
first part of a filename when using Load or Save in TS-DOS.  It will always 
preserve the two-character extension and will flag the file as that type in the 
filesystem.

What you need to do is to rename the file in the folder on your computer, ie 
'mv PROG.BA PROG.DO', and then launch your TPDD emulator and use TS-DOS to load 
the PROG.DO into your Model T.  Once you see the .DO file on your Model T, you 
can go into BASIC and type LOAD "PROG.DO" and it will load and tokenize it for 
you.  (If the program is long, it might take a minute or so.)  Once it's done 
loading you can type SAVE "PROG.BA" and it will save the tokenized version into 
the RAM filesystem.  You can then remove PROG.DO since you don't need it 
anymore.

If you want to save this hassle in the future, you can then fire up TS-DOS 
again and use F1 to save the tokenized PROG.BA back to your TPDD emulator in 
your computer.


You can also convert plain-text BASIC program listings into tokenized .BA files 
using either the Virtual T or Cloud T emulators, which I've done and is a bit 
faster than loading them in and out of your real machine, but that is probably 
a topic for a later time.  :)  Play around with this and get more comfortable 
with it first.







jim

Re: [M100] mcomm on linux

[Jim Anderson]

> -Original Message-
> But TSLOAD.CO doesn't do anything but loads
> DOS100.CO binary file. Which is 8k.

This is true, but with a difference.  It loads DOS100.CO on demand rather than 
have it reside in your RAM at all times, so when you quit TS-DOS you get the 
RAM back.  Sometimes you might prefer to have it sit there taking up 8k at all 
times, but sometimes you might prefer to have 8k available to work with.

> More than one way to do it!

Well, that's why I suggested two alternatives.  TEENY is definitely smaller, 
but IMHO for some people (and especially for someone just starting out with a 
Model T or with 8-bit computers in general) using TEENY is another hurdle 
compared with the interface of TS-DOS, and they're already trying to overcome 
multiple hurdles at once.  You can learn about how file transfers work with 
TS-DOS and then later decide if you want to learn to operate TEENY to save on 
RAM space.  It's easy to forget that when you're just starting out with this 
machine (like I was a few years ago) it takes a little while before file 
transfers and TPDD servers start to make sense rather than feeling like 
mysterious incantations.  :)







jim

Re: [M100] mcomm on linux

[Jim Anderson]

> -Original Message-
> 
> Well, if I try to rename ADVENT1.BA to ADVEN.DO, it still says file already 
> exists and
> actually it just creates ADVENT1.BA in RAM.

Just wanted to point out that when it was suggested to rename the file, the 
idea was to rename it on the PC end rather than typing a new name for it when 
you load it through TS-DOS.  If you give a new name, it will only rename the 
first part of the name - the two character extension cannot be changed during a 
TS-DOS load or save operation and it will insist on keeping the original file 
type.

One bit of key information you might not be aware of regarding file types, if 
the file you are transferring is a plain text listing of a BASIC program it 
must be transferred as a file ending in .DO so that the Model T will know it is 
a text file.  You can then go into BASIC on the Model T and load it, at which 
point it will tokenize it and you can save it as a tokenized .BA file.

If you load a .BA file using TS-DOS it must be a tokenized file.  You can check 
by opening the .BA file in a text editor on your PC and see if it's a text 
listing or if it's a lot of high-ASCII (looks like garbage) with some plain 
text strings mixed in.

Another thing, something you had said in a prior message sounded to me like you 
thought you needed to load the file from disk (the mComm server on the PC) and 
then save it in RAM.  It's useful to remember that RAM in the Model T *is* the 
filesystem, so you don't load into RAM and then save to local storage.  RAM is 
the local storage.  What the Save function in TS-DOS is used for is to copy 
files out of the RAM filesystem onto the disk device (the mComm server).  If 
you've been hitting Load and Save on a bunch of files, maybe take a minute to 
double-check what's in your mComm TPDD folder to make sure you didn't write 
back some of these empty or 1-byte files into your PC...

The easiest way to remember the meaning of Load and Save is to remember that 
originally you were Loading files from and Saving files to an external 
battery-powered floppy drive (the Tandy Portable Disk Drive, hence the acronym 
TPDD).  Now, we're using a PC with mComm or LaddieAlpha or dlplus or other TPDD 
emulators, so we're Loading from or Saving to those devices.

Aside from these things (which are useful bits of info to know when you are 
just starting out), I agree that it does sound like your Model T filesystem is 
corrupt.  The easiest thing to inject is TEENY because it's, well, tiny :) but 
IMHO even though it's bigger the easiest to deal with would be TSLOAD (by 
transferring the contents of TSL100.DO from Joshua's S3 bucket which he just 
posted about).  This will create TSLOAD.CO in your machine which loads TS-DOS 
on demand from the PC whenever you need it, so it's not taking up so much of 
your Model T's RAM.







jim

Re: [M100] RS232 Wifi Modem

[Jim Anderson]

> -Original Message-
> But that's only super convenient if you happen
> to have an Android phone or tablet. And I suppose only if moving files
> to a phone instead of your real computer is good enough, maybe via
> google drive.

Just wanted to add a thought here... I think I have posted about this before 
but it was probably more than a year ago.  I came up with what I felt was a 
slick solution for this which syncs the files in mComm on Android with 
everything else.

I had already put my TPDD folder in Dropbox because I was using mComm on 
multiple computers at home and at work and wanted to keep the files in sync.  
When I installed mComm on my Android device I used an app called Dropsync to 
perform the bidirectional sync between the TPDD folder in the Android 
filesystem and the TPDD folder in Dropbox.  (This is because the Dropbox client 
app for Android doesn't actually sync files with the device, it only allows you 
to download local copies; also you can't configure it to put files in an 
arbitrary folder in the Android filesystem.)  Once Dropsync is configured to 
perform bidirectional sync, it will do so on a configurable interval and also 
on demand whenever it detects changes in the local folder (ie. when you upload 
something from your Model T into mComm, Dropsync will see it and upload it to 
your Dropbox, and it will be on your other computers in a matter of seconds).

I still do something almost exactly like this, except I moved it all into a 
Nextcloud instance which I self-host.  The Nextcloud app for Android also does 
not sync locally (much like the Dropbox app) so I use an app called Synchronize 
Ultimate to do the same thing Dropsync did with Dropbox.  I had been thinking 
about moving away from Dropbox for some time because of data privacy and 
residency concerns (having to be cautious about not putting sensitive files in 
my Dropbox because it's stored in the U.S.), but then when they changed the 
free account to only allow installation on a small number of devices (which I 
had already exceeded) I was finally motivated to pull the plug and set up my 
own cloud storage.  No reason you couldn't still do it on Dropbox as long as 
the number of devices you want to keep synced is small (or if you pay them).







jim

Re: [M100] REXCPM 2M vs 4M

[Jim Anderson]

> -Original Message-
> Correct Jim, it hasn't been fixed yet. After Easter I can get back to
> it.

That'll be awesome, thanks for the update!  For now, it's incentive to keep my 
CP/M file count from bloating out of control :)







jim

Re: [M100] REXCPM 2M vs 4M

[Jim Anderson]

> -Original Message-
> For the record, I did end up successfully upgrading a 2M REXCPM to 4M
> using the RMLV3216AGSA linked below.

This reminds me... did I miss an announcement, or is the release of a CP/M 
image for the 4MB REX with increased directory entries still pending?  The 
current image linked on http://bitchin100.com/wiki/index.php?title=M100_CP/M is 
CPM410.BK which is the same filename as I have, so unless it's posted somewhere 
else I guess it hasn't been fixed yet.







jim

Re: [M100] DVI character set

[Jim Anderson]

> -Original Message-
> If you're going to do that much, then I will grab some more pics with a
> better camera and a tripod so my hand isn't moving, and manual focus.
> Maybe even a good straight-on centered shot without glare from the room
> lights. Maybe with manual controls I can get a shot in the dark without
> the text blooming.

You know what, I realize that I went straight to that screen photo image 
because I was looking for a clear image that had my XX pattern in 
80-column mode... and it's really not so blurry, but the capture in 
"Snapshot_20210127_233755.jpg" is sharper and does have the full character set 
showing.  Even though they're flanked by square brackets I think I can work 
with it.  (the square brackets don't go to the full left and right extent of 
the character cell, that's why I used X.)  Don't worry about going to any 
trouble for a sharper screen photo.  For my cleanup/rescaling of the original 
font I've been working off a handheld iphone photo of my monitor.

I also whipped something up to display the ROM data as large block pixels for 
an absolute reference to the original intended shapes so I think I've got 
everything I need (except time) :)







jim

Re: [M100] DVI character set

[Jim Anderson]

Hey, this is great - I think the photo from the LCD monitor output is the most 
useful - I have actually been using a photo I took of the original font output 
(flanked by X characters for scale and alignment) which I enlarge on-screen and 
overlay a 6x20 grid so I can visualize where the pixels will land as I clean up 
the original font.  I can do the same with your photo to make a scaled & 
cleaned-up DVI-inspired font.







jim

> -Original Message-
> From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Brian
> K. White
> Sent: Wednesday, January 27, 2021 22:15
> To: m...@bitchin100.com
> Subject: Re: [M100] DVI character set
> 
> CAUTION External Sender: Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> 
> 
> Added a few more snapshots from a low-end capture device with the
> composite from the DVI connected directly to the composite input of the
> capture device.
> The pics look bad, but they also look like what a typical small cheap
> color crt actually looks like, blurry and and with the red/blue
> artifacts.
> 
> On 1/28/21 12:42 AM, Brian White wrote:
> > I've put some snapshots from a video capture device up in the same
> > directory with the rom dumps.
> >
> > The image is scaled from composite 4:3 input to 1080p 16:9 hdmi
> > output, but not stretched. The aspect ratio is preserved.
> >
> > On Wed, Jan 27, 2021, 4:37 PM Jim Anderson  > <mailto:jim.ander...@kpu.ca>> wrote:
> >
> > > -Original Message-
> > > Hey DVI owners,
> > >
> > > Would someone mind doing a bit if information mining?
> > >
> > > I would love to get the font bitmap for the DVI.  Jim Anderson
> is
> > > working on improvements to MVT100 firmware and it would be cool
> > to copy
> > > and use these fonts.
> >
> > Something which would also be very useful would be a photo of the
> > DVI character set as displayed on-screen so I can get a sense of
> > the relative size and displayed shape of each character, since the
> > raw bitmap will likely need to be modified (at least to fit the
> > proportions of the new bitmap).
> >
> > If it's not too much trouble, a sharp photo of the DVI screen (in
> > WIDTH 80 mode) displaying the output of the following program
> > would be really helpful (just email the photo directly to me as I
> > will want the full resolution copy and it'll be at least a few
> mb).
> >
> > 10 screen 1,1
> > 20 width 80
> > 30 for c=32 to 255
> > 40 print "X";chr$(c);"X ";
> > 50 next c
> >
> >
> >
> >
> >
> >
> >
> > jim
> >
> 
> 
> --
> bkw

Re: [M100] DVI character set

[Jim Anderson]

There's a couple of problems.  For one, Peter Hizalev's version of the board 
uses a higher model of PIC and I'm not sure if the one used in the MVT100 
design is up to the task (Stephen and I had discussed going down this path at 
some point).  I just tried flashing Peter's .hex file into my MVT100 and that 
was a no-go - the LED didn't illuminate and no video output was produced.  (I 
tried v3.0.2 and v2.0.2 whose file size was more in line with the .hex file for 
this version of the board, but both produced the same non-result.)

I really don't know enough about these devices or the MPLAB toolkit to say what 
would be involved in compiling Peter's source to run on this PIC, not to 
mention whether it has the resources to run Peter's code.  On top of that, his 
version of the board doesn't have composite video output or baud rate jumpers, 
so those features would be lost unless someone with more skills than I have put 
that code back.  Not to mention, the M100 extra escape codes would need to be 
added and the 128-255 characters from the M100/DVI character set would need to 
be converted.

It's probably not impossible, but it's definitely not a task I'm cut out for.  
:)

I think the improvements I'm making will help quite a bit.  The original Geoff 
Graham design used a 6x12 font which was actually 5x10 if you subtract buffer 
space.  Of that, most characters only occupied 5x7 pixels and the rest was 
reserved for descenders and buffer space.  Then, in 24-line mode it would scale 
up to 6x18 by simply repeating every other scanline.  This made a bit of a mess 
of the characters, which I'm guessing had led Geoff to some compromises in the 
character shapes to minimize the negative side-effect of the scaling.

I'm re-drawing the characters as 6x18 (while still retaining the 6x12 character 
bitmaps for the code to use in 36-line mode) so a normal capital letter would 
occupy 5x11 pixels with up to 4 pixels available for descenders.  I was 
hand-scaling the original Geoff Graham character shapes (except for my improved 
6, 9, and Q) but then had the idea to look at the real DVI font to see if it 
has more pleasing character shapes.  At the very least, it's more authentic to 
the MVT100's purpose.  :)

(Note: if the DVI characters are horrible, I may just stick with Geoff's 
characters.  In all likelihood, I will probably end up with two full character 
sets, and in that case I guess people could choose to burn a .hex file with the 
DVI-inspired font or the Geoff-inspired font...)







jim

From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Mike Stein
Sent: Wednesday, January 27, 2021 12:53
To: m...@bitchin100.com
Subject: Re: [M100] DVI character set

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

Just thought since all the source files are there it might be helpful if you're 
also changing the MVT character set.

On Wed, Jan 27, 2021 at 2:25 PM Stephen Adolph 
mailto:twospru...@gmail.com>> wrote:
thanks Mike, similar motivations for sure.  The other part of it is that the 
M100 DVI character set is unique and related to the M100.  So, thinking to both 
improve it and change the character set to "M100 style".


On Wed, Jan 27, 2021 at 2:21 PM Mike Stein 
mailto:mhs.st...@gmail.com>> wrote:
https://github.com/petrohi/terminal/tree/master/firmware/Terminal.X<https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpetrohi%2Fterminal%2Ftree%2Fmaster%2Ffirmware%2FTerminal.X=04%7C01%7CJim.Anderson%40kpu.ca%7C87a9dab7855f472c06be08d8c3059ece%7C66b9f62d3042495eaab6db86f21500c0%7C0%7C0%7C637473776195987532%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=HRdKEMW9C46NhL10V2dKM%2BWOeXPTEd%2BnHiT8wDF7Sg8%3D=0>

"The updated Version 2 is a huge improvement to the display and character 
generation. It results in an easier to read and much clearer display. "

On Wed, Jan 27, 2021 at 1:05 PM Stephen Adolph 
mailto:twospru...@gmail.com>> wrote:
looks like 8x8 characters, 2KB total.

On Wed, Jan 27, 2021 at 12:00 PM Stephen Adolph 
mailto:twospru...@gmail.com>> wrote:
super cool thanks for the quick turn!
Steve

On Wed, Jan 27, 2021 at 11:52 AM Brian K. White 
mailto:b.kenyo...@gmail.com>> wrote:
On 1/26/21 10:42 PM, Stephen Adolph wrote:
> Hey DVI owners,
>
> Would someone mind doing a bit if information mining?
>
> I would love to get the font bitmap for the DVI.  Jim Anderson is
> working on improvements to MVT100 firmware and it would be cool to copy
> and use these fonts.
>
> It is stored in a 4 K eprom M17.  So I am wondering if someone could
> pull the chip and read the eprom data?
>
> Thanks
> Steve
>

Here ya go

https://drive.google.com/drive/folders/1yqVh_mj5vtBJhYng-Uitvsjnykq0Knnt?usp=sharing<https://can01.safelinks.protection.outloo

Re: [M100] DVI character set

[Jim Anderson]

> -Original Message-
> Hey DVI owners,
> 
> Would someone mind doing a bit if information mining?
> 
> I would love to get the font bitmap for the DVI.  Jim Anderson is
> working on improvements to MVT100 firmware and it would be cool to copy
> and use these fonts.

Something which would also be very useful would be a photo of the DVI character 
set as displayed on-screen so I can get a sense of the relative size and 
displayed shape of each character, since the raw bitmap will likely need to be 
modified (at least to fit the proportions of the new bitmap).

If it's not too much trouble, a sharp photo of the DVI screen (in WIDTH 80 
mode) displaying the output of the following program would be really helpful 
(just email the photo directly to me as I will want the full resolution copy 
and it'll be at least a few mb).

10 screen 1,1
20 width 80
30 for c=32 to 255
40 print "X";chr$(c);"X ";
50 next c







jim

Re: [M100] updates to REX# Version 2, REXCPM Version 2

[Jim Anderson]

It did get it back.  Of course, next time I go into UR-2 it’s gone again.  I 
guess for now as a workaround I could unload the REX hooks each time before 
using UR-2.  The UR-2 OPTROM image should still stay selected and available 
until the machine is next power-cycled, right?







jim

From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Stephen 
Adolph
Sent: Tuesday, January 26, 2021 18:54
To: m...@bitchin100.com
Subject: Re: [M100] updates to REX# Version 2, REXCPM Version 2

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

did you try clearing memory to get it back?  thx

On Tue, Jan 26, 2021 at 9:28 PM Jim Anderson 
mailto:jim.ander...@kpu.ca>> wrote:
At first I thought it was related to the larger size of RXCMGR, but then I saw 
I was having issues in images where there were several kb available, and then I 
did the exercise where it ate like 13+kb of memory in an empty filesystem...







jim

From: M100 
[mailto:m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>]
 On Behalf Of Stephen Adolph
Sent: Tuesday, January 26, 2021 04:14
To: m...@bitchin100.com<mailto:m...@bitchin100.com>
Subject: Re: [M100] updates to REX# Version 2, REXCPM Version 2

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

RXCMGR is now >1kb
I'll look into it, but, the VT100 driver exists in RAM now.  Is that the 
problem?
I could not find a way to place the VT100 driver in option ROM.  too 
challenging to understand how to make it work.


On Tue, Jan 26, 2021 at 4:54 AM Jim Anderson 
mailto:jim.ander...@kpu.ca>> wrote:
> -Original Message-
> From: M100 
> [mailto:m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>]
>  On Behalf Of
> Stephen Adolph
> Sent: Sunday, January 24, 2021 18:49
> To: m...@bitchin100.com<mailto:m...@bitchin100.com>
> Subject: Re: [M100] updates to REX# Version 2, REXCPM Version 2
>
> CAUTION External Sender: Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
>
> Glad to hear Jim.  Thanks!  And thanks for your patience.

There is one thing.  Since the upgrade I've been having some weirdness with 
Ultimate Rom II not behaving itself (refusing to open T-Base files, etc).

I thought it might have been some residual RAM image corruption left over from 
before that was fixed (I keep thinking I had checked or re-created all my RAM 
images since then, but always have a nagging feeling that I haven't...)

The most easily checked misbehaviour is that if I try to launch UR-2 where 
there are only a few kb of space left, I can't exit with F8 - it beeps and 
briefly flashes the word "Can't".  Have to use Reset to get out of it.

I won't bore you with all the things I tried, except the last: I thought I will 
re-create this RAM image from scratch where I have T-Base files with my gas 
receipts and my video collection.  Cold reset, check that I can run UR-2, then 
fire up TS-DOS to copy the T-Base files into RAM.  I run out of space.  This 
all fit before...

Cold reset again, check the free space, it's normal.  Fire up UR-2, exit.  Free 
space has suddenly been cut by nearly half, it's now only 16350 bytes.  The 
only things created in the RAM filesystem are CONFIG.DO which is the usual size 
and the UR-2 file to launch the ROM.  If I kill those, free space goes up a 
little bit but not back to normal.

I could make a backup, re-init my REXCPM back to v1 build 43 and try this to 
verify if you want, but I'm pretty sure it didn't do this before (although I 
can't swear to it, I just don't remember having problems with UR-2 before).  As 
a check I cold reset another machine with REX Classic and went into UR-2 and as 
expected, the free space has only gone down by the size of CONFIG.DO plus a few 
bytes for the UR-2 launch file.







jim

Re: [M100] vga monitor solutions

[Jim Anderson]

> -Original Message-
> From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of
> jonathan.y...@telia.com
> Sent: Thursday, January 21, 2021 01:47
> To: m...@bitchin100.com
> Subject: Re: [M100] vga monitor solutions
> 
> CAUTION External Sender: Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> 
> 
> Hi,
> 
> The web site at
> 
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeoffg
> .net%2Fterminal.htmldata=04%7C01%7CJim.Anderson%40kpu.ca%7C243eac70
> cb824a29a06f08d8bdf1744b%7C66b9f62d3042495eaab6db86f21500c0%7C0%7C0%7C63
> 7468192055341328%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=B1ltiTld1tcwIf1LmP6
> 3MUhFIk%2FGWLo7Vo6Xs8TIqrI%3Dreserved=0
> 
> says
> 
> Graphics resolution is 480x288 pixels in VGA 25 line mode, 480x432
> pixels in VGA 36 line mode, 288x216 in PAL composite and 264x180 pixels
> in NTSC composite mode
> 
> but maybe that's not the whole story.

AFAIK it's outputting a signal at the 640x480 scan rate, but seems to be 
leaving some underscan space at least at the top and bottom, probably also the 
sides but it may also not be modulating the horizontal signal as fast as would 
be necessary to get 640 pixels across.

FYI the 480x288 figure is a bit misleading - for one thing, that's the 
resolution you have available to address when using extended line/box/circle 
drawing graphics codes.  For another, it is always drawing the characters using 
480x432 pixels whether you're in 24-line mode or 36-line mode, it's just that 
in order to simplify things Geoff Graham (the original designer of the board 
the MVT100 is based on) used the same font bitmap for both modes and 
implemented a very simple 2:3 scaling mechanism for 24-line mode (every 3rd 
scanline is a repeat of the one before it).

That's one of the reasons the font doesn't look great (why the middle element 
of the H is so thick, or why X looks so weird, among many other things).  The 
other contributing factor for most people is that they're displaying it on an 
LCD monitor which has to scale up from the 640x480 output signal.  Even if you 
have a modern OS output a 640x480 signal onto an LCD monitor, text is going to 
look terrible because of the scaling.  On a CRT monitor, it looks much better 
because it doesn't have to try to map signal pixels onto discrete display 
elements.

I started out offering Stephen a hand with creating the M100-specific extended 
character bitmaps for the MVT100 firmware, but while I was at it I modified a 
couple of the existing characters to make them easier to read (in particular, I 
found the original shapes of 6 and 9 to be difficult to distinguish from 8, for 
instance, and Q was just weird).  In the process of creating the bitmaps for 
the extended character set I realized Geoff's code was scaling up the font in a 
non-linear manner because weird things were happening (I wasn't getting 
on-screen exactly what I defined in the bitmap).

Because I'm a bit OCD and the font thing is bugging me, I'm making further 
modifications to improve the appearance of the text (defining a clean font for 
it to use in 24-line mode rather than scaling up the font used in 36-line 
mode), and while I was at it I started to wonder about the odd shape of some of 
the characters and whether it would be truer to the purpose of the MVT100 board 
to model the characters after the font used in the DVI instead of sticking with 
Geoff's characters.

I haven't seen the actual DVI display, though, so maybe that font is actually 
worse?  :)







jim

Re: [M100] updates to REX# Version 2, REXCPM Version 2

[Jim Anderson]

At first I thought it was related to the larger size of RXCMGR, but then I saw 
I was having issues in images where there were several kb available, and then I 
did the exercise where it ate like 13+kb of memory in an empty filesystem...







jim

From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Stephen 
Adolph
Sent: Tuesday, January 26, 2021 04:14
To: m...@bitchin100.com
Subject: Re: [M100] updates to REX# Version 2, REXCPM Version 2

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

RXCMGR is now >1kb
I'll look into it, but, the VT100 driver exists in RAM now.  Is that the 
problem?
I could not find a way to place the VT100 driver in option ROM.  too 
challenging to understand how to make it work.


On Tue, Jan 26, 2021 at 4:54 AM Jim Anderson 
mailto:jim.ander...@kpu.ca>> wrote:
> -Original Message-
> From: M100 
> [mailto:m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>]
>  On Behalf Of
> Stephen Adolph
> Sent: Sunday, January 24, 2021 18:49
> To: m...@bitchin100.com<mailto:m...@bitchin100.com>
> Subject: Re: [M100] updates to REX# Version 2, REXCPM Version 2
>
> CAUTION External Sender: Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
>
> Glad to hear Jim.  Thanks!  And thanks for your patience.

There is one thing.  Since the upgrade I've been having some weirdness with 
Ultimate Rom II not behaving itself (refusing to open T-Base files, etc).

I thought it might have been some residual RAM image corruption left over from 
before that was fixed (I keep thinking I had checked or re-created all my RAM 
images since then, but always have a nagging feeling that I haven't...)

The most easily checked misbehaviour is that if I try to launch UR-2 where 
there are only a few kb of space left, I can't exit with F8 - it beeps and 
briefly flashes the word "Can't".  Have to use Reset to get out of it.

I won't bore you with all the things I tried, except the last: I thought I will 
re-create this RAM image from scratch where I have T-Base files with my gas 
receipts and my video collection.  Cold reset, check that I can run UR-2, then 
fire up TS-DOS to copy the T-Base files into RAM.  I run out of space.  This 
all fit before...

Cold reset again, check the free space, it's normal.  Fire up UR-2, exit.  Free 
space has suddenly been cut by nearly half, it's now only 16350 bytes.  The 
only things created in the RAM filesystem are CONFIG.DO which is the usual size 
and the UR-2 file to launch the ROM.  If I kill those, free space goes up a 
little bit but not back to normal.

I could make a backup, re-init my REXCPM back to v1 build 43 and try this to 
verify if you want, but I'm pretty sure it didn't do this before (although I 
can't swear to it, I just don't remember having problems with UR-2 before).  As 
a check I cold reset another machine with REX Classic and went into UR-2 and as 
expected, the free space has only gone down by the size of CONFIG.DO plus a few 
bytes for the UR-2 launch file.







jim

Re: [M100] updates to REX# Version 2, REXCPM Version 2

[Jim Anderson]

> -Original Message-
> From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of
> Stephen Adolph
> Sent: Sunday, January 24, 2021 18:49
> To: m...@bitchin100.com
> Subject: Re: [M100] updates to REX# Version 2, REXCPM Version 2
> 
> CAUTION External Sender: Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> 
> Glad to hear Jim.  Thanks!  And thanks for your patience.

There is one thing.  Since the upgrade I've been having some weirdness with 
Ultimate Rom II not behaving itself (refusing to open T-Base files, etc).

I thought it might have been some residual RAM image corruption left over from 
before that was fixed (I keep thinking I had checked or re-created all my RAM 
images since then, but always have a nagging feeling that I haven't...)

The most easily checked misbehaviour is that if I try to launch UR-2 where 
there are only a few kb of space left, I can't exit with F8 - it beeps and 
briefly flashes the word "Can't".  Have to use Reset to get out of it.

I won't bore you with all the things I tried, except the last: I thought I will 
re-create this RAM image from scratch where I have T-Base files with my gas 
receipts and my video collection.  Cold reset, check that I can run UR-2, then 
fire up TS-DOS to copy the T-Base files into RAM.  I run out of space.  This 
all fit before...

Cold reset again, check the free space, it's normal.  Fire up UR-2, exit.  Free 
space has suddenly been cut by nearly half, it's now only 16350 bytes.  The 
only things created in the RAM filesystem are CONFIG.DO which is the usual size 
and the UR-2 file to launch the ROM.  If I kill those, free space goes up a 
little bit but not back to normal.

I could make a backup, re-init my REXCPM back to v1 build 43 and try this to 
verify if you want, but I'm pretty sure it didn't do this before (although I 
can't swear to it, I just don't remember having problems with UR-2 before).  As 
a check I cold reset another machine with REX Classic and went into UR-2 and as 
expected, the free space has only gone down by the size of CONFIG.DO plus a few 
bytes for the UR-2 launch file.







jim

Re: [M100] updates to REX# Version 2, REXCPM Version 2

[Jim Anderson]

> -Original Message-
> A couple of issues were identified and addressed in both REX# and
> REXCPM, and updates are posted.  I have done a fair bit of testing on
> these changes as well as just general use.  As always bug reports are
> valuable thanks.

I finally got a chance to install this on my REXCPM a few nights ago, and 
although I haven't done a ton of testing, I have been moving between RAM images 
a fair bit and the issues I had with the previous build are resolved.  Also no 
sign of the line24/scroll lock issue moving in and out of M100/CPM modes.  My 
images are sorted by time/date too!  :)  So I guess if you never did get around 
to looking at that backup image I sent you, there's little point anymore.

I'm really really REALLY loving having the VT100/DVI functionality built-in 
now!  No more of the following dance:

- SCREEN 0
- RXCMGR
- change to a new RAM image
- Ctrl-X to unload
- VT100.CO
- SETIME.BA (reset time and date)
- SCREEN 2
- oops, I need something from another RAM image... rinse and repeat...

I need to build some new muscle memory to use Ctrl-A because I keep finding 
myself cursoring to (or typing) RXCMGR and while I'm doing so I remember 
there's a hotkey now.  :)  OTOH, if I get *too* used to it I'll be hitting it 
on all my other machines with REX Classic and wondering why they are broken...







jim

Re: [M100] vga monitor solutions

[Jim Anderson]

> -Original Message-
> I second that recommendation.  I've got exactly that unit and it works
> perfectly with the M-100 running REXCPM, through an MVT100 and using VGA
> input.

I'm curious, how does the font look on that monitor?  I've tried a few 
different LCDs and the one with the lowest resolution (1024x768) did the 
poorest job of scaling and made the text simply awful.  Other LCDs with higher 
resolution were not as bad, but still not great (imho) compared with a CRT.  
I'm curious whether it was purely a problem of my LCD not having enough pixels 
to be able to do a better job of scaling, or if it just used a really poor 
scaling algorithm because it's old.  This LCD you're using has the same 
horizontal resolution so I'm curious what it looks like.  If you could send a 
photo of some text on the screen it would be great!  (If you don't want to send 
to the list, just email me directly.)







jim

Re: [M100] REXCPM Upgrade to version 2 available

[Jim Anderson]

I tried upgrading to this new release (using RXCUPG), and encountered issues 
when restoring a RAM image back from backup.  The same thing happens sometimes 
when switching from one RAM image to another, but every time when restoring 
from an image (either through Ctrl-R or through RXCMGR).  The progress bar 
indicates data is being copied to RAM, but then the M100 locks up, sometimes 
showing a screen like the photo below, and sometimes just a frozen screen.  
Sometimes Reset or a power-cycle will recover the machine, sometimes it needs a 
cold reset.

I also tried using RXCINI (the new one from REXCPMV2_b11.ZIP) to create a new 
directory and load REX from scratch, and the same issue is present.  In 
addition, there are more strange behaviours - when starting from an empty 
directory I can create a new RAM backup, but if I try to create another RAM 
backup or switch to a RAM image I've loaded back from TPDD, RXCMGR just creates 
a new RAM image with the same name as the current one.  If I try to delete the 
non-active image I get a message which I thought I had committed firmly to 
memory (sorry) - it said something about 'error: flash not available' or not 
ready or something to that effect.

On the upside, my RAM image was actually being sorted correctly by date and 
time.  :)  I've restored my backup and running v1 build 43 again as it was 
essentially unusable the way things were.

[cid:image001.jpg@01D6EBA8.70354260]







jim

From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Stephen 
Adolph
Sent: Friday, January 15, 2021 17:02
To: m...@bitchin100.com
Subject: Re: [M100] REXCPM Upgrade to version 2 available

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

I found a minor issue just now;
When switching from M100 to CP/M, it is possible that the M100 leaves the 
SCREEN in the scroll lock state.

Here is a simple basic program that de-scroll locks the screen and starts CPM.
It assumes RXCMGR is installed.


CPM.BA

10 screen0:cls:print"Enabling scroll..."
20 screen2:printchr$(27);"W";
30 screen0:print"starting CP/M."
40 call32804,3


it is  a work around until i drop a new load with a fix.
cheers
Steve



On Fri, Jan 15, 2021 at 6:03 PM Stephen Adolph 
mailto:twospru...@gmail.com>> wrote:
The next version of REXCPM is now available for download.

http://bitchin100.com/wiki/index.php?title=REXCPM#Software

Version 2 provides the integrated VT100 driver, and adds in the CNTL-A 
quickmenu shortcut to start RXCMGR.

I have run through the upgrade process on my machines, from Version 1 build 43 
to Version 2 build 10.  Worked for me, and worked in VirtualT.

Please read the instructions carefully, and download the software and utilities 
bundle.
Delete your old utilities and use the new ones.
To do a fresh install (as in you have never installed it before) then use 
RXCINI.DO.
To UPGRADE an existing V1 install, please use RXCUPG.DO.

Let me know if there any problems, and of course bug reports are valuable.

Also, I have updated the BCR hack page with information on how to apply the 
hack to T102.

http://bitchin100.com/wiki/index.php?title=BCR_TTL_SERIAL_HACK#T102

thanks
Steve

Re: [M100] Serial-to-WiFi Converters and Rechargeable Batteries

[Jim Anderson]

> -Original Message-
> Hi everyone,
> 
> I just joined the flock and I'm an Original Flavor owner of a 32 KB M100
> when they were going for $399 (worth $964.98 today) in the mid-1980s,
> and now I can add nine more to my collection for that much in inflation-

If I'd had the money back then, I would have been right there with you.  :)  I 
only drooled over them when they were originally being sold, and only just got 
my first one and joined up with this wonderful community a few years ago.  
Since then, I've acquired more of them than I really want to admit, got my kids 
into it, built some REX modules, and had a lot of fun.

> I've heard that rechargeable batteries can be used in M100s by changing
> a resistor inside a unit, but I can't find any details about the value
> of the new resistor, which one it is on the PCB, etc.  Also, is the
> resistor value dependent on which battery chemistry is involved (NiCd,
> NiMH, LiH, LiPoly, LiFePO4, etc.)?

I posted something about this not too long ago - basically, from looking at the 
T200's factory-provisioned NiCd mod there are two changes they made by 
provisioning jumper locations on the memory PCB.  Neither of these changes are 
strictly necessary to permit use of rechargeable batteries, they just provide 
internal charging and re-scale the low battery voltage thresholds.

One of the jumpers connected a 27 ohm 1/4 watt resistor between the AA-holder 
positive terminal and the outer terminal of the DC input barrel jack, to charge 
the AA batteries while external 6VDC is connected.  (A service bulletin later 
recommended putting a diode in series to address an issue specific to the T200 
power control circuitry, so on an M100 or T102 this isn't really necessary.)  
The downside of this is that it's really only suitable for NiCd cells; I don't 
know if you could get away with something that basic for NiMH without cooking 
the cells, and certainly not for any of the Lithium type batteries.  Of course 
you couldn't plug in external power with Alkaline cells installed without the 
machine attempting to charge them.

The other half of the mod was a jumper which put a 94.4k ohm resistor in 
parallel with a 22.6k ohm resistor in the voltage divider circuit which 
determines the threshold voltages for the low battery LED and the low power 
shutdown.  This shifts the voltage thresholds down and lets the machine run 
longer and discharge NiCd batteries more deeply.  (Again, this would mess 
things up if you switched back to alkaline, although at least not in a 
dangerous way.)  The same mod could be done to an M100 or a T102 by soldering a 
94.4k resistor (or 100k if you've got one on hand) piggyback in parallel with 
R108.  Luckily, both of those machines label it R108 although it is in a 
different spot on each board.  On the M100 it's on the top side in a row of 
resistors just below the power supply section; on the T102 it's on the bottom 
(which is actually the component side) at the edge of the board not far from 
the power switch.

> Thanks and All the Best,
> Jim  KJ7JHE

Welcome from Canada (VE7TCP) :)







jim

Re: [M100] Joystick for the M100

[Jim Anderson]

> -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.







jim

Re: [M100] Joystick for the M100

[Jim Anderson]

> -Original Message-
> > The problem with an Atari style joystick is that it uses a common
> > ground. This means all of the keys to operate a game would need
> 
> His device was smart and interfaced with the system bus and was
> accessed via an IO port.

Seems to me that somebody had a scheme a while back where the joystick 
interfaced with the parallel port and status was polled that way (this avoids 
having to build a custom interface).







jim

Re: [M100] Subtle differences among various Model T models

[Jim Anderson]

> -Original Message-
> I've been a M100 owner since I got my first unit as a 16-year-old kid,
> who managed scratch up enough money to get one when Radio Shack was
> blowing them out the door to make room for the T102.  I still have that
> machine, plus a few other M100s as spares and for use with other
> projects.

Wow - I only drooled over them as a kid, dreamed about them but then filed it 
away in my memory under 'unachievable' until a few years ago.  Now that we have 
ebay and I have disposable income, I have a bit of a Model T Problem.  :)

> But the information about the keyboard is new to me, as is the claim
> that the T102 is more "durable".  If anything, I find the through-hole
> electronics on the M100 more appealing for long-term maintenance, as
> it's easier to work with.

I'd agree with that, although I think his comment about the T102 being more 
durable might just mean that he'd run into far fewer T102s in need of repair 
than M100s?  I'd just be guessing.

> For those of you who have experience with more than one model in the
> Model T line, do you agree with Rick's assessment about the keyboard and

Keyboards are really a matter of preference, although there are some which are 
universally regarded as 'bad' (ZX-81 membrane keyboard, PC-jr chiclet keyboard, 
etc).  I have one T200, a few T102s now, and several M100s.  I don't know if my 
T200 is an exception, but I find the keyboard sound and feel to be nearly 
identical to the T102.  It's slightly different, but then again the feel and 
sound can be slightly different between two T102s or two M100s so I don't know 
if I would categorically state that the T200 keyboard is different from the 
T102 keyboard.

For certain, the T200/T102 keyboards have a very different sound and feel from 
the M100 keyboard, although I think the key travel is about the same (I could 
be wrong).  The M100 keyboard (when clean and working freely) has a light touch 
and a clacky sound which I absolutely *love*.  It's no IBM Model M but it is 
much nicer to type on than a cheap generic PC keyboard.  The T200/T102 
keyboards don't seem to require greater keystroke effort but it may just feel 
that way to me because they are dampened at the bottom of the stroke which 
makes them much much quieter.  If you type slowly you could use a T200/T102 in 
a library, but I doubt you'd get away with that on an M100.  :)

> are obvious, and I'm also aware that the M200 came with Multiplan packed
> in, plus the ability to have multiple RAM banks, but Rick also mentions

So there's a couple of significant differences with the T200.  The multiple RAM 
banks are 24k apiece because the T200 required a bigger system ROM (40k) for 
its additional features.  They seem to have found room to implement hardware 
scrolling, for instance (the 16-line LCD would have been positively *painful* 
otherwise).  Since it was no longer possible to have 32k of RAM, they gave it 
the ability to switch banks, and changed the main menu screen a bit to give you 
the ability to Copy files between banks and to Kill files from the current bank 
using function keys right from the menu.  They took away the ability to launch 
a program or open a file by typing its name at the menu screen, though.  So, 
you've potentially got a total of 72k of RAM, but only 24k at a time.  It does 
give you a nice way of keeping three different projects on the go at the same 
time, each with its own filesystem.

Multiplan is built in and is selected by MSPLAN from the main menu, which 
launches it like it was an OPTROM (there's some additional hardware to let the 
machine select between main ROM, Multiplan, and the OPTROM socket).  What 
else... the cursor keys are normal keys in a diamond layout (big plus imho) 
instead of buttons like the F-keys.  The big LCD seems to have poorer contrast 
and a narrower range of viewing angles than the 8-line LCDs in the smaller 
machines, but on the plus side it's big and it scrolls text very quickly.

The power switch is a momentary pushbutton on the keyboard which has its good 
and bad points.  The upside is that auto-power-off puts the machine in exactly 
the same state as manually powering off.  There's no need to turn the switch 
off and then back on after it goes to sleep on you - just push the button.  You 
can also set an alarm interrupt so the machine turns itself on and executes a 
program at a specific time (POWER "00:00:00", "01/01/21", "NEWYR.BA").  The 
downsides are that the power control circuit is more complex and more finicky 
than in the M100/T102 and it requires a reasonable voltage from the memory 
backup battery to function.  If your memory backup battery is dead or missing, 
you can't turn it on.  If it's partially charged, you'll have to watch lines 
flicker on the LCD as it 'spazzes' for a while until the voltage gets high 
enough for the machine to turn on properly.  This is why you shouldn't replace 
the Ni-Cd battery with a supercap in the T200, since 

Re: [M100] Paladin MC-1 ROM

[Jim Anderson]

> -Original Message-
> Am I correct in understanding that this uses some sort of sonic
> triangulation?? That's an amazing bit of early tech!
> I see very little documentation on-line. Pass a note if you manage to
> get a youtube video or something online.
> I'd love to see this in action!

Exactly!  It's actually not as complex as it might first appear - the device 
knows when the pulse was triggered, and just has to look for that sharp impulse 
of sound from each mic within a small timeframe after the pulse (because the 
work area is finite), then time the arrival delay at each mic to find the 
distance.  It has a calibration routine to fine-tune measurements for the room 
temperature (the manual says it's calibrated for 74F, I got pretty accurate 
default readings at 68F here and spot-on after calibrating).  I remember having 
a Black & Decker sonic tape measure many years ago which bounced a sound pulse 
off the far wall of a room and gave a fairly accurate distance reading (usually 
within 1/8" iirc).  My boss (who had a gift for giving things and people odd 
name) referred to it as a 'wireless tape measure'.  :)

I should have taken some photos of the PCB while I had it open the other day 
checking component temperatures when I powered it on.  My memory is terrible 
but I think it had a 6502 processor inside.  The layout on the board was nice, 
with identical sections on the left and right for processing the signal from 
each microphone, processor and other ICs at the front centre, power supplies 
for low and high voltage (for the spark) at the rear.  I also got a printed 
manual in nice shape which I suppose should be scanned for archival purposes.

Interestingly, the manufacturer seems to have put a great deal of faith in the 
T102's memory battery.  I've been playing around with the software, going 
through the examples in the manual, and it has a lot of features such as the 
ability to define component items that would go into a job you're costing out 
based on drawings (for instance, calculating rolls of roofing material based on 
square footage, or calculating number of 2x4 studs needed based on wall lengths 
and a specified on-centre spacing) and then automatically calculate prices.  
However, it doesn't write any of these parameters or figures to a file, it just 
stores the variables while it's running and if you hit the rear Reset they're 
gone.  The user manual doesn't address what to do if the machine gets reset (no 
mention of CALL 63012) and in fact just tells you to turn the machine on and 
off and not to worry because all the parameters and measurements you've stored 
will just stay intact.  Although they've put a silver DIRE WARNING sticker over 
the memory power switch opening, they didn't cover or disable the Reset button 
so it's entirely possible for the user to fat-finger it and find themselves at 
the main menu screen.  I guess that's why they litter the company's 1-800 
number throughout the manual?

Making a video for youtube about this machine... an interesting idea.  I'm not 
sure I could hold a candle to Hey Birt! or some of our other youtubers on here, 
but it's something to think about.  :)







jim

Re: [M100] Star Blaze 100

[Jim Anderson]

> -Original Message-
> At the Club100 site, I found Star Blaze 100, apparently the only game
> Tandy every sold for the Model 100.
> [...]
> Now, the odd thing is, I find the game play to be virtually impossible.
> Not sure if that's the way it runs on real hardware or not.

I love this game on a real M100, but have never tried it in VirtualT.  I just 
gave it a shot and the keyboard response for the controls (and, in fact, for 
the F-keys to start each level) is extremely sluggish and delayed.  On a real 
M100, the F-key response is slightly slow (sometimes I find I need to hold the 
key for half a second) but the response for the ship control keys is always 
excellent.  In VirtualT, the ship controls need to be held before the ship 
starts moving, and then it continues moving for a time after the release of 
each key.  Also, up/down are confusing (reversed) on my PC keyboard because 
Ctrl is below Shift, not above.  Quite difficult to play.  :)







jim

[M100] Paladin MC-1 ROM

[Jim Anderson]

I have slain my white whale!

Finally got my latest Paladin MC-1 kit (for which I paid too much IMHO but this 
has become an obsession for me), and to my relief the EME Rombo I saw in the 
listing photos does indeed contain the MC-1 ROM necessary to make the measuring 
calculator work.  Also, although there were many parts missing and the 
re-badged T102 in the kit is in rough shape, the digitizer box does appear to 
work (unlike the last one I got, whose major accomplishment was to transform a 
pair of tantalum capacitors into magic smoke in under a minute).

If anybody has an MC-1 digitizer and no ROM, I've dumped it and posted it to my 
Club100 member area 
(http://club100.org/memfiles/index.php?=0=nom=Jim%20Anderson/Paladin%20MC-1).
  It works in REX but there isn't a lot you can do without the digitizer (you 
can hit ESC from the main screen to play with the calculations menu, Reset 
button to get out of it).  Someone who understands ML may find it an 
interesting curiosity, who knows.

As time permits, I want to capture the serial data exchanged over the RS-232 
link with the digitizer just to see what's going on.







jim

Re: [M100] revised MVT100 firmware, V1.3.2_SA

[Jim Anderson]

> -Original Message-
> > Pin 5 is an odd extra ground on the M100. Pin 7 is the ground for the
> > spec, all wands, and all machines with the port, including the 100.
> 
> fair, but pin5 is ground on an RS-232 DB-9.  So, that is what I used on
> MVT100.  I think in the future I will just wire both to ground on the
> MVT100 board.
> [...]
> on second thought you are right, ground should be on pin 7 since it is a
> TTL port.    It isn't an RS-232.

Hmm...  Well, if I may add my two cents' worth here...

When performing the BCR hack, transmitted data is wired to be sent out the 
unused pin 3 in order to make interfacing with MVT100 easy using a standard 
serial cable (it's already wired to receive on pin 3 from RS-232 devices).  The 
fact that the M100 already has pin 5 grounded is an easy convenience, but for 
the T102 (and maybe the T200 in the future) adding a ground jumper to pin 5 in 
the computer seems to me to be the right way to go.  If you ground pin 7 in the 
MVT100, it's going to drag down the computer's RTS signal whenever it's plugged 
in to an actual RS-232 interface.  Granted, RS-232 is supposed to be able to 
tolerate that, but it seems unnecessary.

Since the MVT100 is meant to connect to either RS-232 or the hacked BCR, I'd 
rather see the design of the MVT100 stay RS-232-friendly and put the onus upon 
the BCR hacker to supply TD on pin 3 and ensure there's a ground on pin 5 
(since they have to go inside the machine to perform the BCR hack anyway).







jim

Re: [M100] revised MVT100 firmware, V1.3.2_SA

[Jim Anderson]

> -Original Message-
> 
> Thank you for giving it a whirl Jim.  Hopefully it is now "solid".  I
> have it running beside me now. ;)
> So, you did the BCR hack as well? nice.

No problem, I was really excited to see this functionality fixed (I was leery 
of editing files using the external display because I didn't know whether it 
was 'just' an issue with backscroll or if it was just a symptom of some other 
display corruption I might not notice until I'd made a big mess of some file...)

I did the BCR hack some time ago after the failed recap of my first M100 board 
(which I still haven't got around to fixing).  While I was in a soldering mood 
I figured I might as well open up my daily driver (the machine with REXCPM) and 
do the mod since I was getting tired of moving the serial cable between display 
and TPDD duty.  While I was in there I also jumpered the power from pin 9 of 
BCR to pin 22 of the serial port (which comes out as pin 9 on a 9-pin adapter) 
and added a jumper to the MVT100 board to draw power from pin 9.  (This also 
let me enable the jumper to power my NADSBox from serial pin 9.)







jim

Re: [M100] revised MVT100 firmware, V1.3.2_SA

[Jim Anderson]

> -Original Message-
> 
> Regarding the firmware for the MVT100 video adapter, I have updated the
> firmware to address the scroll issue with TEXT.   I've done some
> "designer testing" and it looks good.  Of course I always appreciate
> test reports, thanks.  Really helps me to conserve time.  ( you would
> not believe how much time I have been dumping into my projects since
> Covid).
> [...]
> Good luck with the upgrade, and let me know how it goes. 

Hooray!  Some brief testing with a few .DO files shows that TEXT works great 
backscrolling even with the label line turned on!  Excellent!

Loading the upgrade worked very well.  The one note I might add is to remind 
people that loading the new firmware reverts the saved config settings back to 
default.  This might be obvious to some but I took a bit to clue in - I was 
baffled (and a little scared) when I brought it back to my M100 and it wouldn't 
output anything after the bootup message!  I'm using the BCR hack so it was 
just a matter of setting the baud rate back to 57600; most people will need to 
set it to 19200 and re-enable the RS232 signal invert.  (Oh, and if you use the 
composite output, or even if you plan to try it in the future, change it from 
PAL to NTSC so you won't be stuck wondering why it doesn't work...)









jim

Re: [M100] Version 2 VT100 driver for M100

[Jim Anderson]

> -Original Message-
> 
> Quite right, found a bug.  90% of the time, it is me not thinking about
> the code in front of my nose.
> Build 22 is posted.

Spectacular!  Seems to do everything the first version did, plus launching .DO 
and .BA files from the menu!







jim

Re: [M100] NADSBox and WP2

[Jim Anderson]

> -Original Message-
> 
> Now I'm trying to get the NADSBox to work with the WP2 without success

Does it entirely fail to work, ie. If you go into the WP-2's TELCOM with F2-9, 
can you hit Enter and get the NADSBox command-line prompt?  If you get nothing 
at all, see below...

> so far.  For the moment I'm stuck because my serial cable is not a full
> null cable, so I've got a replacement on its way (snail mail is very

So, unless you've changed the jumpers inside your NADSBox, you actually need a 
straight cable - its serial port is wired DCE and doesn't require a null cable 
to connect to a Model T or a WP-2 (which are both wired DTE, in spite of what 
the connector gender differences imply).  The adapter that comes with the 
NADSBox is just 25M straight to 9F, and for use with the WP-2 you just want 9F 
straight to 9F.  At first I used a 9F to 9F cable, then I bought one of those 
low-profile 9F-9F gender changers so the NADSBox could hang right off the back 
of the WP-2.  (Downside is that it fits quite loosely compared with the adapter 
Ken provided for use with the Model Ts, and also those compact adapters flip 
upside-down so you can only see the reflection of the NADSBox LED in the table 
surface.)

> My question is: Does there need to be any kind of file similar to
> DOS100.CO on the SD card for the NADSBox to work with the WP2?  Or will
> it "just work"?

No need for any special files - the WP-2 has everything it needs to speak to a 
TPDD in ROM.

> Can I also assume that I can just continue to use my existing SD Card
> with the M-100 6.2 filenames on it?  Presumably it will just "find" the
> files in the root directory when I do a file listing?

Yes, because the WP-2 was only designed to talk to a real TPDD it isn't aware 
of the TS-DOS directory extensions we all know and love, so you will only see 
whatever is in the TPDD emulator's current directory.  One of the great things 
about using the WP-2 with a NADSBox is that you can go into TELCOM and use the 
cd command to move around your SD card to the directory you want.  When you go 
back to FILES and look at the disk contents, that's the directory the WP-2 will 
see.

You can read and write 6.2 and 8.2 files from the WP-2.  There's a caution in 
the NADSBox manual (bottom of page 20) about setting 'config wp2=on' from its 
command line first because there are some circumstances under which the WP-2 
can crash because it doesn't handle 6.2 filenames elegantly (I'm not going to 
paste the whole paragraph here).  :)







jim

Re: [M100] VT100 update

[Jim Anderson]

> -Original Message-
> 
> ESC D and ESC M scroll the screen. The problem is that most "ANSI"
> implementations don't implement the full VT-100 command set, so that one
> may not be supported on most terminal emulators.

You know what... my faulty memory got me again.  I was remembering when I was 
configuring WordStar and there were two sets of escape codes for Insert Line 
and Delete Line which VT100 does not have but which WS-BIBLE.DOC recommends 
using with devices which do support it (like Kaypros) to speed up display 
refreshes (because there's the ruler and status lines at the top, you can 
scroll the screen when moving down a document and just re-draw those lines when 
you stop, but if you scroll backwards the ruler and status lines would move 
down with the text... on VT100 it re-draws what it can between each Ctrl-W and 
re-draws the whole thing when you stop, but on a machine with Insert Line 
capability it could insert the new lines just below the ruler line and let the 
terminal scroll the rest down the screen...)

I mixed up the lack of Insert/Delete Line functionality with the backwards 
scrolling that doesn't currently work right in TEXT.  Sorry Stephen.







jim

Re: [M100] Version 2 VT100 driver for M100

[Jim Anderson]

> -Original Message-
> 
> Jim, you are not trying to use VT100.CO with REX are you?  They are
> not compatible. ..Steve

I'm using it in a machine which has a REXCPM in it, but I unload the REX hooks 
with Ctrl-X and power-cycle before invoking VT100.CO - this always worked with 
the previous version of VT100.CO so I concluded when you said it wasn't 
compatible with REX that it just wouldn't work while the REX manager hooks were 
in place.  Are you saying even with REX hooks unloaded it won't work, that the 
REX has to be physically removed from the socket?  (If that's the case, I could 
try it in another machine that has REX classic so I can get VT100.CO in there, 
unhook REX, pull it from the socket, and then try it... or does VT100.CO have 
to be loaded into a totally virgin cold-booted machine?)







jim

Re: [M100] VT100 update

[Jim Anderson]

> -Original Message-
> 
> Exactly. I had to add custom vt100 commands to thr vt100 terminal
> firmware.. I just did it wrong.

Well, I don't know about 'wrong' if the M100 OS expects the display device to 
have an ability the VT100 doesn't provide...

> Anyone can jump in and fix it if they want.  Don't wait for me.

Wow... well, there's *can* and there is *able*... it's been at least 25 years 
since I did anything non-trivial in C and I was never a working programmer, I 
went off into system and network administration after I graduated and gradually 
left programming behind... I would love to pitch in but I really doubt I'd have 
the ability to imbue a VT100 emulator with functionality the real VT100 never 
had!  :)







jim

Re: [M100] REX update questions (probably only answerable by Stephen)

[Jim Anderson]

> -Original Message-
> 
> Active block is always first, does seem to fit what is happening? I just
> checked on my end and it seems to be working.  Active block first, then
> sorted by date/time.

Yes, it shows the active block first as always, it's the rest of the entries 
which aren't sorting.  When I applied the 43 update each image had a bogus 
date/time (something like 63/12/15, I don't remember exactly) but I've cycled 
through each of them and they all now have a date/time stamp from some time in 
the last two days, however the sort order remains exactly the same sequence as 
always regardless of the date/time attached to each image.

If it might be helpful for you to look at, I could make a backup of the REX 
area of my REXCPM and send you a link to the backup file to try it on your 
system.


BTW, I thought I'd mention that after rebuilding and reloading the other 
machine with the REX classic, at some point after filling up the OPTROMs and 
RAM images I noticed that the SYSTEM# entry has re-appeared in the OPTROM image 
list.  When I hit B it says it refers to block 0.  I recall now that the # 
indicates an image which is active in another bank (on my T200 REX) and I 
remember you saying you had added bank support (but I thought that was only in 
the new REX# release?)... anyhow, maybe this will help shed an additional clue 
as to what happened and/or why SYSTEM# is showing up in the menu now.







jim

Re: [M100] Version 2 VT100 driver for M100

[Jim Anderson]

> -Original Message-
> 
> Updated to build 21, with a bug fixed.
> Please report any issues, thanks!

I tried this out tonight after I finished restoring everything to my other 
REX...

I didn't have much success with it - it does initialize, but after going into 
BASIC and issuing either SCREEN 1 or SCREEN 2, if I exit back to the menu I 
can't launch TEXT or even go back into BASIC anymore - have to use the Reset 
button to recover.  (Also, whether I try to select a .BA or .DO file, or even 
select BASIC or TEXT, I get the same menu corruption as before.  No matter what 
item I select, it just beeps and displays the corrupt menu screen.)







jim

Re: [M100] VT100 update

[Jim Anderson]

> -Original Message-
> 
> Problem #2 below is actually an issue with the MVT100 video adapter
> firmware.  It also has a bug I need to fix.  HAven't gotten to that
> yet,,,

Just wondering (because it seemed likely to me that this is what is happening), 
does it happen because the M100 expects to be able to backscroll the display 
content and there's no VT100 function for backscrolling?  I ask because if 
you're planning to add an escape code to implement backscrolling in the MVT100 
firmware this would be *fantastic* for speeding up WordStar since it's capable 
of using a backscroll code but the standard VT100 doesn't have that feature... 
:)







jim

Re: [M100] REX update questions (probably only answerable by Stephen)

[Jim Anderson]

> -Original Message-
> 
> I see you understand "S" not "O".  I've checked it out on my end and it
> was working.  If the date/time stamps are the same, sort order won't
> change.

The sort order does change with each press of S (reverse and forwards), it's 
just that the sort order is something other than by date/time and seems to be 
the same order the entries appeared in before the update.  Images dated Dec 
20th appear in the middle of the list, surrounded on either side by entries 
dated the 19th bearing various timestamps (also not in sequence by time).  
Hopefully that's clear.







jim

Re: [M100] REX update questions (probably only answerable by Stephen)

[Jim Anderson]

> -Original Message-
> 
> Re REXclassic: sounds like your directory is corrupted at first
> glance.  I would do a full rebuild, not just the software.
> Let me know if you cannot find the tools you need.

Argh... OK, yeah, hard lesson about backup-before-trying-something-new learned 
(again).  It's hardly the first time.  :(  I was just hoping there might be 
some flag that could be flipped or reset to point back at the block containing 
the TS-DOS image or something.

Out of curiosity, is the SYSTEM# entry supposed to be visible in the OPTROM 
list when accessed via Ctrl-O from the M100's menu?  What does it do?







jim

Re: [M100] REX update questions (probably only answerable by Stephen)

[Jim Anderson]

A couple of additional notes:

> update, of course).  Press O to change sort order only reverses the

OCD self-nitpick: I meant S, not O.  :)

> and cats... my T102 locked up solid and the Reset button wouldn't

Amendment: I noticed a couple of additional things.

- Although the Reset button won't recover the machine from the state it's in, 
pressing Ctrl-Break (note: NOT Shift-Break) will immediately cold-reset the 
T102 from this state, without touching the Reset button.

- When I execute CALL 63012 after a cold reset, the first half of whatever text 
is on the first line on the LCD clears, followed about a second later by the 
second half.  After that, nothing happens (except the aforementioned Ctrl-Break 
weirdness).

- I have re-applied the 260 update and it still behaves the same way.  I would 
strongly prefer not to have to use the full-reset version of the 260 update if 
I don't have to (I have most of the images backed up, but not all are current 
of course...), I'm hoping there is some way to reset whatever flag I've 
inadvertently set in the flash by choosing that SYSTEM# entry, since it seems 
to be trying to go back to whatever that points to every time and failing.

REALLY REALLY REALLY hoping these symptoms give you an 'a-ha!' moment, Stephen. 
 :)







jim

[M100] REX update questions (probably only answerable by Stephen)

[Jim Anderson]

I recently applied the 260 update to two of my REX classics and the 43 update 
to my REXCPM.  Two questions:

REXCPM - I see a date and time stamp on the images now, awesome!  However, for 
me the images are still being sorted by their original order (I think it's the 
order in which the images were created) even though I've cycled through all of 
them and they all now have an valid date/time stamp (they started with garbage 
date/time data after the update, of course).  Press O to change sort order only 
reverses the original sort order back and forth.  Is there a trick to it?  Do I 
have to offload, delete, and re-load them?

REX classic - I was using my T102 this morning and hit Ctrl-O from the main 
screen to change option ROM images.  I noticed the last image in the list was 
something I hadn't seen before, named SYSTEM#, and out of curiosity I selected 
it.  Well, you know what they say about curiosity and cats... my T102 locked up 
solid and the Reset button wouldn't recover it.  Ctrl-Break-Reset will do a 
cold reset, but as soon as I CALL 63012 it locks up solid again.  Powering off 
and on doesn't help, removing and reinstalling the REX doesn't help.  I guess 
I'll have to try doing the 260 update again (and if that doesn't help, the full 
260 reinstall...) but I wanted to find out what SYSTEM# is and why it locked 
REX up tight.  (Perhaps it's not meant to show in the list?)







jim

Re: [M100] VT100 update

[Jim Anderson]

> -Original Message-
> 
> Sounds great Bob! I think where it would break is if you try to open a
> basic program from MENU without going into BASIC first and
> loading/running it.
> If you want, give that a try.
> Same is true for a .DO file.
> Ex.
> in Basic type SCREEN1.
> then F8, back to MENU.
> now move to select and run a .BA program directly.
> I think that crashes.

Hey, I've been using the VT100 driver too, and I have this problem as well.  
Not having ever used a real DVI I wasn't sure if this was expected behaviour or 
not.  I did find it's not really 'crashed' as such, just the menu display is 
messed up.  I can cursor back up to BASIC and hit Enter, then F8 back to the 
menu and everything is fine again.  (Moving the selection bar back up to BASIC 
has to be done by memory based on the screen position of the file you were 
selecting, as the updating of the selection bar on the screen is wrong.)

The only other bug I found (and didn't report yet, sorry) is that if I am in 
TEXT editing a file longer than screen length, it doesn't handle backwards 
scrolling correctly.  If I am at the end of the file and I cursor up to the top 
of the screen, when I go up further it only refreshes the top line on the 
screen with the line the cursor has moved to, and doesn't push down or redraw 
the rest of the text below.

Very excited about having the VT100 functionality integrated with REXCPM/REX# 
in the future!







jim

[M100] NADSbox battery stats question

[Jim Anderson]

Hi, wondering if anybody else has had this odd thing happen.  I noticed a while 
ago that the battery statistic information in my NADSbox has become corrupt, or 
at least I assume that's what has happened.  The "Bat Date" field was showing 
the current date (even though I had not changed the batteries; in fact, they 
were the same batteries I had been using since I got the NADSbox), and the "Num 
Batt" field said 0.5 which seems somewhat implausible.

After doing the power mod for my MVT100 and the BCR serial mod in my M100, and 
also jumpering power to pin 22 (Ring Indicate) on the serial port, I remembered 
the NADSbox had a jumper to allow it to receive power from that pin as well, 
and opened mine to enable it.  This meant having to remove the AA batteries 
since it won't draw power from the serial port if the batteries are installed.  
After having used it with and without AA batteries for a few months now, I 
thought to look at the stats and the "Bat Date" had updated to the last time I 
re-installed the batteries, however "Num Batt" still says 0.5.

Has anybody run into this?  Is there a way to clear/reset the stats or 
otherwise force it to start incrementing?







jim

Re: [M100] adding 4xAA NiMH to M100

[Jim Anderson]

> -Original Message-
> It worked beautifully.  Later I installed a LM317 voltage regulator on a
> heatsink inside the uinti so I could power it with 12V, like the rest of
> my Amateur Radio gear.

Oh man... I wanted to do this, too, and I was going to make a rectangular 
opening in the top case above the barrel jack and mount an Anderson plug flush 
to the opening, in the empty space under the logo plate.  Again, never got 
around to it...

> Lesson learned:   Do not leave NiCads on charge for too long.

This is yet another reason why I'm afraid to charge the batteries inside the 
machine with just a resistor in series rather than a charge control circuit.  :)







jim

Re: [M100] adding 4xAA NiMH to M100

[Jim Anderson]

> -Original Message-
> Jim, this sounds like a fantastic solution to one of my problems.  I
> don't need in-circuit charging (I always have spare NiMH AAs, but I
> rarely travel with an AC adapter) but I would love for the low batt
> light to actually provide some function again.

Yeah, same for myself - although for different reasons.  I alternate between 
rechargeable and alkaline batteries, but I most frequently run the machine off 
a small USB phone charger battery (because it's perfectly happy taking 5V 
instead of 6V at the barrel jack - low battery indication doesn't start until 
4.2V and auto power-off is at about 3.7V IIRC so there's no issue running the 
machine on 5V all the time, it's just like being on half-exhausted batteries).  
I keep a set of AA batteries in the machine just to keep the memory alive when 
I disconnect my phone charger battery.

If I were going to use my machine on rechargeable AA batteries more frequently, 
I think I'd rather do what you do and have two or more sets to swap out in an 
external charger rather than have to plug my whole model T in for charging any 
time it's dead.  Arguably, my use case (usually using it with external power) 
might be the best for having it internally charge the AA batteries, but that's 
one thing 5V is not quite high enough for - I'd have to use a 10 ohm (or lower) 
resistor, no diode, and just make peace with the fact that the AAs would never 
really get fully charged... and then they'd get roasted if I used the machine 
on a 6V supply.  :(

If I were going to do this for my machine, I'd want to install a little dpdt 
switch that would mimic the jumpers in the T200 (which clearly were meant for a 
switch that they decided not to include - they're right next to the memory 
power switch and you can see a rectangular impression in the bottom case where 
the cutout would have been molded) - throwing the switch would connect the 
battery for charging and simultaneously bridge a 100k resistor onto R108.  But 
then, where to put the switch... so, I never got around to it.  :)

> Is the location for the mod also similar on the 102?  I may be a
> hardware novice but I'm pretty sure I could manage to piggyback a
> resistor if I knew where to put it.

Checking the T102 service manual, you're in luck - in the 102 it's still called 
R108 and it's still a conventional through-hole resistor instead of a 
surface-mount device like most of the rest of the resistors.  On page 7-4 
(which is page 73 of 111 in my PDF copy) you'll find the main PCB bottom view, 
and R108 is down at the bottom edge of the board as shown on that page, right 
next to the round power transformer OT2.  This would be the underside of the 
front right of the board as it's installed in the machine.  It shouldn't be too 
hard if you have moderate soldering skills to dead-bug piggyback a 100k 
resistor onto R108, or solder it to the pads on the top side, whichever you 
feel most comfortable with.  You'd probably want to extract the board from the 
bottom case to have a look and be certain you've got the right resistor even if 
you decide to solder your mod on the top side.  (In the M100 the resistor in 
question is in a clearly-marked neat row of resistors right on top in the power 
supply section, so you could do this without doing any more disassembly than 
splitting the case and folding it open...)







jim

Re: [M100] adding 4xAA NiMH to M100

[Jim Anderson]

> -Original Message-
> Option 1: 47 ohm
> - works, but does not prevent reverse conduction from batteries to an
> unplugged wallwart
> 
> option 2:  10 ohms + silicon diode:
> - protects from reverse current, but drops the voltage for charging
> 
> option 3:  10 ohms + schottky diode
> - also protects , maybe a little  less voltage drop?

I had a look at the T200 service manual to see what the official solution was 
for internal ni-cd charging, and essentially the jumper on J302 just places a 
27 ohm 1/2 watt resistor between the barrel jack sleeve input and the AA-holder 
positive terminal.  So, same modification, but now we have three different 
resistance value suggestions.  :)

I don't know enough about differences between charging ni-cd and ni-mh to 
comment on which resistor value would be most appropriate for each type.

Also, your mention of a diode reminded me of the service bulletin 200:3 which 
called for using a 1N914 diode in place of the jumper at J302 to prevent 
problems with lockup of the power-on circuit of the T200 in the event that the 
wall wart is unplugged and the power button is pressed while the barrel plug is 
still inserted... The service bulletin did not suggest changing the resistor 
value from 27 ohms to compensate for the voltage drop across the diode.

The other half of the T200 mod is not essential, but nice - J301 which puts a 
94.4k resistor (R93) in parallel with 22.6k resistor (R94) to shift down the 
trigger voltages for the low battery LED and auto power-off.  This could be 
done in exactly the same way by piggybacking a 94.4k 1/4W resistor parallel 
onto R108 in the M100.  Calculating it out, the resistance value would only be 
1.1% higher by using a 100k resistor instead of 94.4k so that might make this 
part of the mod more appealing for those who have common resistors on hand.  :) 
 (The 94.4k resistor shifts the combined value of the two resistors 19.3% lower 
whereas a 100k resistor shifts the combined value 18.4% lower - not a huge deal 
imho.)

All this just made me realize that this is why negative tip/positive barrel was 
so common on older gear like this - the insertion switch in the jack is 
connected to the barrel contact, so you have to use the barrel for whichever 
polarity you want to switch away from the batteries - to use tip 
positive/barrel negative you'd have to switch the negative side of the battery 
pack...







jim

Re: [M100] REXCPM software update

[Jim Anderson]

> -Original Message-
> One of our list members (David Grissom) has been able to show that there
> was a problem created in the M100 file directory when switching in and
> out of CP/M.  To do so took a fair amount of effort so thanks David.

Wacky - I've had a couple of corruption issues with the M100 filesystem but was 
never able to track it down and just started forming a habit of using Ctrl-R to 
restore from REX backup after exiting CP/M.  I guess I should have mentioned it 
to you but I have a hard time drawing the line between reporting bugs and 
feeling like I'm complaining about a good thing I'm grateful to have :)







jim

Re: [M100] Back from the hospital

[Jim Anderson]

> -Original Message-
> The Dr. released me from the hostpital last Thursday and I have been
> just taking it easy until my new medication has time to kick in (it

Glad to hear you're home and doing well - here's hoping that the new medication 
does its job.







jim

Re: [M100] Anyone selling dead Model 100 (shells or otherwise)?

[Jim Anderson]

> -Original Message-
> Nice thought Robert, but I don't have any parted out and don't have time
> to do that; right now I am completely occupied selling off bits and
> pieces of my reel-to-reel collection

Audio or data?  ;)

> Josh: All I know about the 200 is that it seems to power up and
> occasionally shows the directory; otherwise the screen blacks out (i.e.
> all the pixels go black at the same time -- from what I remember,  I
> think there is rolling bar that shows as well).

Kinda sounds like the symptoms of a bad memory nicd (I get the same thing on 
T200 when the memory supercap isn't charged after it's been sitting without 
batteries; this is why I'm going to change the supercap back to a nimh battery 
because the T200 doesn't handle lack of memory battery voltage very well).  
Does it refuse to power off when you press the power button while the screen is 
rolling/flickering?







jim

Re: [M100] STRUGGLING to get REXCPM loaded

[Jim Anderson]

> -Original Message-
> unable to load file named
> TSD100.BY
> Note the different extension (.BY).
> Why is RXCMGR asking for a file with the .BY extension?

.BY files are the RAM image backups - are you sure you're loading from the 
optrom screen instead of the ram image screen?







jim

Re: [M100] WP-2

[Jim Anderson]

> -Original Message-
> The 2430 cells are not hard to find.
> Just type CR2430 into amazon or google and they are available new and
> cheap. You by a card of 5 or 6, install one, stick another in the pocket
> in the slip case, and you're set for "ever". I don't know why everyone
> makes such a big deal about that battery.

In my case, the battery was an annoyance because it was a surprise - when I 
first got my WP-2 it didn't have one installed, and because having stuff 
shipped to Canada takes forever I didn't want to wait several more weeks for a 
battery for it.  I went to a couple of places locally before finding one for 
sale for about $10.  Adding insult to injury, it went dead in little more than 
a year (probably had spent years on the shelf).  That's what led me to spend a 
little time making a CR2032 fit in the holder, since I have plenty of those on 
hand for other things.







jim

Re: [M100] WP-2

[Jim Anderson]

> -Original Message-
> I’ve had no issues with the WP-2 not keeping up when I type, except when
> inserting text, and that is easily overcome by inserting a CR so that
> insertions are at the end of a line not the middle - then SHIFT-DEL to
> close the space back up afterwards.

Heh, yeah, I use this trick (and on the Model Ts, too).

> One issue with my WP-2 is that when connected to a PC, it can save files
> using TS-DOS, but while it can read the mComm directory, it can’t load
> [...]
> It works just fine both ways with LaddieAlpha on my Mac, though that

IIRC, this is expected behaviour - the WP-2 has a different way of loading the 
directory from a TPDD compared with TS-DOS on an M100, and LaddieAlpha is coded 
specifically to address that, while mComm isn't.

Oh!  I almost forgot to mention something else important about the WP-2 for the 
benefit of Nick (and others who might not be aware): file format.  The WP-2 
saves .DO files, but they aren't the same as the plain text .DO files the Model 
Ts produce.  First thing to note is the end-of-line termination.  The Model T 
series use a CR-LF pair like DOS/Windows machines do, and of course the Unix 
family (yes, Macs too) use a single LF character so you folks are already 
familiar with these issues and the 'dos2unix' and 'unix2dos' conversion 
utilities.  The WP-2 designers went a different direction and terminate lines 
with a single CR character, same as MacOS 9.x and earlier used to.  I'm not 
sure if the MacOS of the 80s influenced the WP-2 designers to go that way or if 
it was for some other reason.

The other (relatively minor) gotcha is that the .DO files have a non-plaintext 
header before the text of the document starts, which contains document 
formatting information (this is detailed at 
http://bitchin100.com/files/wp2/wp2format.html).  You can get around this by 
going to the Files screen and hitting F1-A "Ascii convert" which will turn the 
selected file into a .DA file which will be plain text (but still with CR 
end-of-line termination).  You can then upload the .DA to your TPDD (but as 
soon as you go back to editing it, the WP-2 will turn it back into a .DO).  
Alternatively, you can strip the header (the first 128 bytes of the file) from 
the .DO file after copying it to your desktop computer.  On a Windows box you 
can load it up in Notepad++ and you can fairly easily see where the header ends 
and the text of your document begins.  You'll also need to go to the end and 
strip extraneous text from the Ctrl-Z (shows as SUB in Notepad++) to the end of 
the file.  I use Notepad++ for this because it also has a handy menu option for 
fixing the CR EOL terminators (Edit... EOL Conversion... choose Windows or 
Unix).  I also whipped up a small set of ugly conversion shell script files for 
dealing with this entirely at the Linux CLI (converting from .DO or .DA files 
to plain Unix text, DOS text, and for converting from plain text formats back 
to CR-terminated .DA if you want to load a text document into the WP-2 to edit 
while you're on the go).







jim

Re: [M100] WP-2

[Jim Anderson]

> -Original Message-
> From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Nick
> Shaner
> Sent: Sunday, November 15, 2020 21:18
> To: m...@bitchin100.com
> Cc: M100 List 
> Subject: Re: [M100] WP-2
> 
> CAUTION External Sender: Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> 
> 
> any report on keyboard quality versus the model t? I really appreciate
> this timely thread because I've been looking at the WP-2 of late.

I bought one to use as a note-taking device, and for that purpose I'd say it 
would be fabulous for most people (unfortunately, not for me - see below).  The 
keyboard isn't as nice to type on as an M100, but it's MUCH quieter and when 
taking notes during a meeting or lecture the M100 is just unacceptably noisy.  
I love the M100's keyboard and prefer typing on it where noise doesn't matter.  
Note that the T102 and T200 both have a softer and quieter keyboard than the 
M100, and the WP-2 keyboard is a different design and is a bit softer and 
quieter still compared with those two models.  They are perfectly usable 
keyboards but I don't enjoy typing on them nearly as much as on the M100.  
(Full disclosure, I have an IBM Model M keyboard on my work computer and I love 
love love it - I would rather give up my firstborn than that keyboard.  I guess 
I'm a bit of a keyboard snob.)

I also appreciate having a spell check with a large dictionary on-board without 
having to have an external device attached.  Spell check is slow of course as 
the document gets larger, just like with Sardine on the Model T machines... The 
screen is a plus and a minus for me - you get 80 columns, but the characters 
are tiny, and in poor light it's harder to make out simply because the 
characters are smaller.

I added a 128k ramdisk chip to mine which is great feature, since you work on 
documents in the 32k on-board ram and can copy them to the ramdisk chip 
periodically to make a backup in case you royally mess something up in your 
document.  You'll still want to backup to a TPDD device of some kind in case 
the memory goes b0rk (same solutions you'd use for the M100, except the WP-2 
has a PC-standard 9-pin male connector so you need a different but arguably 
easier-to-find cable - I'm lucky to have a NADSbox so I just have a slim-line 
double-sided 9-pin female adapter to couple it right onto the back of the 
WP-2).  Speaking of memory b0rk, I did have a situation once where my WP-2 
crashed in the middle of a meeting (because I was goofing around and typed a 
control character sequence that froze the machine) and I had to use the reset 
pinhole on the bottom to recover.  It wiped the internal memory but the 
contents of the 128k ramdisk remained intact.  Whew!  I wouldn't necessarily 
count on that happening that way in the future, but it saved me quite a loss 
that day.

Speaking of memory contents, they're maintained by a CR-something 
non-rechargeable lithium coin battery.  You can make a spacer (mine is made 
from wadded paper) to make a cheap and readily available CR-2032 fit in the 
holder instead of tracking down the larger and much more expensive correct 
replacement battery.

OK, so back to what I alluded to at the beginning - as mentioned in this thread 
already, the WP-2 keyboard has a problem with fast typists.  Not all fast 
typists, mind you, so if you don't mind spending the money and discovering it 
isn't happy with the way you type, go ahead and get one.  I was disappointed 
because I didn't have any warning ahead of time that this might happen, and 
nobody on this mailing list at the time had had a similar experience, so I 
bought a second WP-2 assuming mine was just defective - same problem.  :(

There's two possibilities I have considered: either the keyboard decoding can't 
keep up with typing above a certain speed, or the keyboard decoding is unable 
to handle the way I (and others, apparently including C.Magaret) type.  I 
strongly suspect this second cause based on some tests and study I conducted on 
myself.  I learned to type on electronic typewriters and computers in high 
school, and I studied my technique a little more carefully when I first 
discovered this problem with the WP-2 and got my mom to try it.  She can blast 
away on it about as fast as I do without a single erroneous character 
appearing, while I get very specific and very repeatable erroneous characters 
when I type certain sequences of characters.  What I noticed is that my fingers 
are sort of 'chording' the keys (but not an actual chord, more of a rolling 
chord), pressing subsequent keys while previous keys are still in the process 
of being released, whereas my mom learned to type fast on manual (mechanical) 
typewriters as a secretary in the 1950s and types as fast as I do but with very 
precise individual keystrokes.  Typing as I do would jam up a manual typewriter 
at speed, but most electronic keyboards are able to decode the 

Re: [M100] CPM emulation

[Jim Anderson]

> -Original Message-
> When I looked at this, I saw that it was based on the z80 code written
> [...]
> Trying to access the unix fs directly, I could run the ws.com in the
> tests directory and it save the file to my unix filesystem.  Winstall
> there gave an error, but I've seen this before when the ws.ins file
> doesn't match the version of ws.  This program certainly needs further
> investigation.

I hadn't even looked in the tests folder!  It seems to be WS3.0, and yeah, I 
get the same error about WS.INS when I try using my good copy of WS3.3 that I 
installed on my M100, so I know there's nothing wrong with my WS.INS.  Coupled 
with what Joshua was saying about having issues with saving files that don't 
end in .BAK (which I guess implies that the crash is caused when WS attempts to 
create a .BAK file, which it can't do if you're already editing a .BAK file), I 
think there are some issues with the unix filesystem access functionality.

As I mentioned in an earlier message, I was hoping the 'cpmtool' utility 
bundled with this emulator would be of some help to get around the 
getunix/putunix issues, but it just seems to corrupt the directory in disk 
images I've tried it on...

Hey, maybe you know (or maybe someone else does): some time ago I posted on 
this list when I first got WS3.3 working, but SpellStar had the wrong terminal 
emulation settings and I couldn't find a list of patch addresses for 
SPELSTAR.OVR to fix it.  Well, it turns out after some experimenting that there 
aren't any... SpellStar just uses the terminal settings from WS.COM, except it 
seems to have a bit of a bug when it comes to VT100.  I realized what the issue 
was when I was working on editing the aforementioned Star Wars arcade game from 
Heath H19 terminal codes to VT100.  The Heath terminal (and a lot of other 
terminals) use a more efficient cursor positioning sequence where the row and 
column are represented by the decimal value of two characters in the escape 
sequence, often with an offset of 32 so that a space character represents row 
or column 1, ! is 2, " is 3, # is 4... you get the idea.  VT100 uses numeral 
characters instead, so the string [12;40H puts the cursor at row 12 column 
40.  Simpler for humans to understand, but less efficient because it transmits 
six to eight bytes rather than four (Y+G for the H19 to go to row 12 
column 40).

Anyway, WordStar accommodates this in the terminal configuration by having 
multiple fields for specifying the cursor positioning codes - the leading 
sequence, the separator (if any), the trailing sequence, and a flag for 
parameter order (R,C or C,R).  There's also a flag to specify whether the row 
and column values are numeral characters or the ASCII value of the characters, 
and what offset (if any) they use.  After I came to realize that some terminals 
use the ASCII value of the characters, I paid a little more attention to the 
output of SpellStar because I had noticed that it *IS* using VT100 sequences 
(some text is in inverse video) and that they do change if I reconfigure WS.COM 
for a different terminal, it's just the VT100 cursor positioning sequence that 
it's getting wrong, and it's not entirely wrong because there are [;H sequences 
littered all over the output.  The thing is that it's just not paying attention 
to the flag that says it should send the row and column values as numeral 
characters rather than byte values, so it's sending stuff like 
[;(H for row 12 column 40 instead.  This, of course, doesn't 
work, and makes me wonder if this is a known bug in SPELSTAR.OVR that can be 
fixed - how could nobody have noticed this, unless VT100s were really really 
uncommon in the CP/M days?







jim

Re: [M100] wordstar 4 wants a z80

[Jim Anderson]

> -Original Message-
> 
> Exactly, altering the drive tables of the Linux emulator should enable
> execution of an M100 CP/M image I would think. Conversely, massaging the
> image to suit what the emulator expects might be the way to go. You'd
> need to be conversant with "CP/M Alteration Guide" - it contains all
> info regarding Disk Partition Table, etc.

Owww...  :)

I mean... I probably *could* become conversant with it... I've done worse 
before... I need a box of round tuits.







jim

Re: [M100] CPM emulation

[Jim Anderson]

> -Original Message-
> Since I asked the original question about CP/M emulation I thought I
> should share what I had been using to prompt it:
> 
> This emulator has BDOS integration directly to the filesystem (no
> getunix/putunix because it just sees the host directory):

I'm really glad you shared that!  As Jonathan pointed out already, it's based 
on the same emulator he's been using, but the ability to access the unix 
filesystem adds an interesting dimension to it.  (I'm not sure I approve of the 
author's decision to make the emulator interpret ADM-3A/Kaypro terminals and 
then hard-code the translation to ansi/vt100 instead of using a curses 
library... although I understand the motivation since you're very likely to 
find CP/M software already configured (or hard-coded) for Kaypro display 
codes... I recently spent several hours editing a Star Wars shooting gallery 
type game [in BASIC] which contained hard-coded Heath H19 sequences so it would 
display properly on the MVT100, and at least that was something I *could* edit 
myself)

> It seems to work well in some respects, but fail in others.  For
> example, I can WINSTALL wordstar 3.3 and run it, but it crashes while
> saving -- but only if the document is not a .BAK file.  Disabling
> backups doesn't fix this.  I can run the WINSTALL equivalent for
> WordStar 4, but it dies early in the process.

You got further than I did.  I tried running WINSTALL using my copy of WS3.3 I 
installed on my M100 and it complains about WS.INS and aborts.  (this was using 
it with the WordStar files in the unix filesystem - I also tried with a disk 
image, see below...)

> Many other commands work just fine.  It also has a non-BDOS integration
> mode that will use a disk image.  I have not tried it but since my
> problems all seem to be around file access, it might work better.

It also comes with an interesting utility (cpmtool) for manipulating disk 
images, which I tried to use to put my WS3.3 files into a disk image to see 
whether either emulator would be happy running it from there, but it corrupts 
the image when I try to copy files into it...







jim

Re: [M100] wordstar 4 wants a z80

[Jim Anderson]

> -Original Message-
> what I have, there are differences.  As you stated, if I took out the -
> DPOSIX_TTY from the Makefile, the github source compiled for me, and I
> could get the A> prompt, but the drive was empty so I couldn't test
> getunix.com and putunix.com because they weren't there.

Ah, that got me for a second when I first ran it, too - you have to gunzip 
A-Hdrive.gz (I don't know why it was gzipped when the whole source bundle was 
compressed into a zip file already).  There isn't a lot in that image (no pip! 
no stat!) but at least getunix.com and putunix.com are there.

> I can send you the 'legacy' code that I have if you are interested.
> z80.tgz is only 57823 bytes., the binary is around 200 k.  It gives some
> warnings but compiles OK, and I have left in the -DPOSIX_TTY.
> 
> My latest compile (it's a gentoo system):
> 
> ldd z80
> linux-vdso.so.1 (0x7ffce679a000)
> libc.so.6 => /lib64/libc.so.6 (0x7f62b8534000)
> /lib64/ld-linux-x86-64.so.2 (0x7f62b8719000)

Very similar on the binary I compiled from the github source on an ubuntu 
system here:

ldd z80
linux-vdso.so.1 (0x7fff8c155000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1a1126a000)
/lib64/ld-linux-x86-64.so.2 (0x7f1a1186c000)

I'd love to try the version you've got - at least try compiling the old source, 
and if I fail with that I might want to try the binary.  I'm also curious to 
hear whether you have the same problem I do with getunix and putunix in the new 
github source.







jim

Re: [M100] wordstar 4 wants a z80

[Jim Anderson]

> -Original Message-
> point is, it is not a straight binary dump.
> 
> Said another way, if there is an agreed format for making an M100 CP/M
> A: disk dump accessible on simulated CP/M, lets look at that for next
> drop of RXCUTL.

Well, for what it does (image backup/restore) whether it's a raw memory image 
or something that's usable as a virtual disk in an emulator, as long as the 
backup and restore are consistent with one another and performance of the 
backup/restore process is not impacted I guess it doesn't matter.  If it's more 
efficient or easier to backup/restore the current image format then maybe a 
tool to convert a backup into a vdisk might be useful?  Or, instead of trying 
to use it in one of these other CP/M emulators, maybe some way of loading a 
REXCPM backup image into/out of VirtualT?  (I haven't played with this in a 
while, honestly - I remember Philip made something available to run CP/M in 
VirtualT maybe a year or two ago which I did play with and got very excited 
over, but I have no idea what the current state of that is, maybe there is 
already a way to move REXCPM backup images back and forth to use them for CP/M 
in VirtualT...?) 







jim

Re: [M100] wordstar 4 wants a z80

[Jim Anderson]

> -Original Message-
> I wonder if you changed the drive geometry info in CP/M to match the
> M100 definition, if it would work?

Probably - the readme says A: and B: emulate the 'ST-506 5Mb 5" 5Mb drive' and 
any other drives (C: and down) emulate 'traditional 8" 256k drives'.

I have no idea how to do that, though.  :(  I never got that deep into CP/M.







jim

Re: [M100] wordstar 4 wants a z80

[Jim Anderson]

> -Original Message-
> It was written ages ago by someone named Pareg Patel.  I lost contact
> with him after a while but I recently found the source on github:
> [...]
> Just for a lark, I tried to compile just now and while it gave some
> errors, it did produce a useable binary (gcc 9.3.0, linux 5.4.48) but
> that was the original 25-year-old source I had from way back, not from
> github so that might have been fixed.

This is pretty fantastic!  I got it to compile (Ubuntu 18.04) with some errors 
just by removing -DPOSIX_TTY from the Makefile CFLAGS, and it does execute, but 
unfortunately that's as far as I can get with it - both the getunix and putunix 
utilities cause the emulator to segfault.  putunix gets as far as creating an 
empty file in unix before the segfault, getunix doesn't end up creating 
anything in CP/M (although it is able to access the unix filesystem, since it 
gives the message ERROR1 if I specify a file that doesn't exist, but segfaults 
if I specify a file which does exist).

I'd be curious to know whether the binary you just produced actually allows 
getunix and putunix to work or not.  Without them it's not too useful.  (On a 
lark, I also tried taking my REXCPM backup file and dropping it in place of the 
emulator's A: virtual disk file but as I expected that didn't work so well - 
DIR shows a few files I recognize from my M100 but it's all corrupt.)







jim

Re: [M100] Back in the hospital yet again

[Jim Anderson]

> -Original Message-
> 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.

Ouch, I also hope that this is quickly and easily resolved by your doctors.  
Best wishes for a quick stay and recovery.







jim

Re: [M100] patching wordstar 3.3 for the m100 keyboard

[Jim Anderson]

> -Original Message-
> Hello,
> 
> My notes on patching ws 3.3 from the cpmarchive.  I think I have the
> addresses correct on the far left, but I don't have any way to print
> from the m100 so I had to copy from the screen.
> [...]
> 0655 1C 00 d0 63
> 0659 1D 00 0a 63
> 065D 1E 00 b4 64
> 0661 1F 00 9a 64

This is great!  I added cursor key support to my copy, and fixed BKSP/DEL 
functionality.  I skipped adding the 1F entry at 0661h and just went with the 
change at 0545h.  I did want to mention a typo for the benefit of anyone else 
who wants to do this: in the entry for 0659h the address bytes should be DA 63 
rather than 0A 63 - it didn't work, so I checked against the address for cursor 
left and found the typo.

0659 1D 00 DA 63







jim

Re: [M100] User number in CP/M for M-100?

[Jim Anderson]

> -Original Message-
> Supercalc 2 also throws you back to user 0, as does wordstar 3.3 (the
> version on the cpm archive, which I have patched for the M100 cursor
> keys, and the behaviour I like for the bcksp/del key).  The version of
> adventure (the colossal cave) on the m100 site also returned me to user
> 0, as does DDT.COM.

See my previous message from tonight (this morning, I guess - insomnia is 
great!) regarding user areas.

I did want to comment on your WordStar patching though - this is my fault for 
obtaining WS-BIBLE.DOC but not actually reading it thoroughly, but I didn't 
know there were patch addresses for changing key commands and the behavior of 
backspace/delete!  I've been using WordStar quite a bit on my M100, actually, 
and putting up with the backspace problem - trying to remember to hit 
shift-backspace, failing to remember, and then noticing that I'm 'plowing' 
several characters ahead of the cursor as I type because I backspaced them...  
I had noticed by happy accident that the cursor down key produces a control 
character which WordStar also maps as delete, so sometimes I remember to hit 
that instead of backspace and it works, and other times I hit backspace, curse 
myself, and then hit Ctrl-G to delete right (or Ctrl-T to delete the word if 
I've backspaced several characters).

I also noticed while reading WS-BIBLE.DOC something that I probably would have 
noticed if I read more carefully while using WINSTALL - you can specify your 
current WS.COM (or whatever you named it) instead of the default WSU.COM as the 
source file for altering settings and you will start with the settings in that 
file.  Here I have been generating new executables starting 'from scratch' with 
WSU.COM each time, having to pick the terminal type again, etc. etc.  Also you 
can hit + to get to a hidden menu to make your own changes by specifying hex 
addresses which should be a little nicer than using DDT.  I'm going to go fix 
the backspace in my copy now!

One thing I wanted to ask: you mentioned patching it to respond to the M100 
cursor keys - did you replace the Ctrl-E,S,D,X key sequences or did you find 
somewhere to add the M100 cursor key codes in addition?  One of the things I've 
always loved about WordStar is the ability to do most things without taking my 
hands off the home position on the keyboard, one-handed cursor movement with 
Ctrl and the ten keys closest to it makes it such a breeze to use.  It would be 
nice to add the ability to use the M100 cursor keys but not if it meant 
replacing the default Ctrl sequences.







jim

Re: [M100] User number in CP/M for M-100?

[Jim Anderson]

> -Original Message-
> > In my experience with using it on the M100, I end up back in USER 0
> > after executing any .COM program *except* for STAT.COM for some reason.
> > Anything else I have tried, whether it's 3rd party of part of CP/M
> > (MBASIC.COM, PIP.COM, etc.) all land me back in USER 0 after execution.
> 
> But you can run other programs and the user area does not change.
> Weird.
> [...]
> This may be a quirk with IMPORT, since we know it is in very early
> development right now.

I think you misread or misunderstood what I had said - when I run almost any 
program EXCEPT for STAT.COM (and now I've discovered D.COM and SWEEP.COM behave 
nicely too), I end up back in user 0.  Only those few programs which don't 
perform a cold start on termination keep me in the same user area.  Every other 
program I've tried using in another user area (third-party programs, DDT, 
MBASIC, even PIP) put me back in user 0 after they end.

See what I wrote to Philip Avery in my previous message - I think I've found 
the reason for this behavior, and it seems to be expected according to the 
documentation, depending on the behavior of programs when they terminate.







jim

Re: [M100] REXCPM playing and observations

[Jim Anderson]

> -Original Message-
> Hi Jim
> 
> Fear not, we can increase the size of the Directory making full use of
> 4MB. This will require BIOS changes & an OS update. That means... at
> present you'll have to re-import all your user files. Can you reply

So it goes - that's the price we pay for being on the bleeding edge.  :)

> please with what D.COM states for directory status/usage, I don't need
> each file size.

Certainly - and now that I understand how it allocates multiple directory 
entries for large files, I understand why D.COM reports different counts for 
the number of files and number of entries.

User 0 - 39 files 55 entries.
User 1 - 17 files 32 entries.
User 2 - 52 files 56 entries.
User 3 - 54 files 71 entries.
User 4 - 24 files 42 entries.

Wouldn't you know it, that totals to 256 entries.  :)  Back-of-the-napkin math 
indicates that's optimal for an average file size of about 13.7kb (or large 
files of (X*16)+13.7kb) in a 3.5mb filesystem, and it feels to me like the 
average file size for an old system would be quite a bit lower than that 
(probably only a few kb).  I've chewed those 256 entries up in about 2mb worth 
of files, so that's roughly 8kb apiece.  I have no idea what the conventional 
wisdom is for how many directory entries to allocate for a given size of disk 
in CP/M 2.2 so I'll keep quiet now :)

> With NADSBox I had 'checksum error' at various stages when loading large
> files (>32KB). I presumed my NADSBox was faulty. Is your error
> consistently at the 64KB size?

Yes, and in fact I don't get an error message from IMPORT.COM at all, it seems 
to terminate normally (except that the transferred file is only 64kb in size).  
It also produces a number of progress-indicator dots proportional with a 64kb 
file (ie. if I copy the same large file from mComm running on my phone, I get a 
proportionally larger number of progress dots - twice as many if the file is 
128kb, etc).  I'm not sure how the TPDD protocol handles large files, whether 
it is able to tell IMPORT.COM the correct size and the NADSbox is just telling 
it 64kb so it stops at 64kb, or if IMPORT.COM has no idea how big the file is 
and just reads until the TPDD device says it's done, or what...

> Returning to User 0 after execution: This doesn't seem right to me, I'll
> look into this

Looking at the CP/M 2.2 manual, it says (top of page 1-3) that a user's program 
can overlay memory areas used by the CCP and/or BDOS and that by branching to 
the bootstrap loader at the end of execution it causes the complete CP/M 
monitor to be reloaded from disk.  Further on (page 1-12) it says about the 
USER command, "The active user number is maintained until changed by a 
subsequent USER command, or until a cold start when user 0 is again assumed."  
I have noticed since reading this that the few commands which do preserve the 
active user number exit immediately to the A> prompt, whereas most other 
commands which put me back in user 0 have a bit of a delay when exiting before 
the A> prompt appears - the exact same amount of time it takes to reload CP/M 
if you hit Ctrl-C at the A> prompt and watch for a new A> prompt to appear.

Since there's no disk activity indicator, it hadn't hit me before that this 
little delay (and subsequently ending up back in user 0) was the system 
reloading.  It sounds like the difference is that some programs (like the 
variants of D.COM, SWEEP, STAT) don't need to reload the system after 
execution, and I find myself still in the same user area, whereas PIP, DDT, 
MBASIC, IMPORT, EXPORT, and almost everything else I've loaded into my machine 
does perform this reload at termination.

> Steve: Drive B: proposal. Initially I'm reluctant as it chews up part of
> our 64KB RAM with an extra Drive tables - there's quite a bit of
> overhead for that. However it maybe the way to go, I'll have a good
> think on that. But... a souped-up IMPORT with wildcards/sub directory
> ability would solve this issue I believe.

Yes Please :)







jim

Re: [M100] REXCPM playing and observations

[Jim Anderson]

> -Original Message-
> thinking out loud here,
> 
> Sure, the directory structure for a single large disk could get fixed to
> address the issue.
> I wonder though if we might want something else.
> 
> What if we had a smallish (360kB) drive B, intended for file sharing?

This might be a useful thing - hopefully it would be in addition to increasing 
the number of directory entries because right now there's only enough to 
accommodate an average file size of 13.7kb (or 29.7kb, or 45.7kb) on the 4mb 
REXCPM image.

I suppose the option of having a B: drive would be something that would have to 
be baked into the starting image - you wouldn't be able to choose to allocate 
some space on the fly for a B: drive, right? 







jim

Re: [M100] Wordstar 3.3 for MVT100 and CP/M on M-100

[Jim Anderson]

> -Original Message-
> diskette, and it was a wordstar file.  I'm pretty sure I downloaded
> something from Microsoft to import the file.

Some research turned up that MS apparently discontinued this many years ago.  I 
did locate and install it on my machine here which has Office 2016, but Word 
doesn't seem to know it exists.

Best I could do is select 'US-ASCII' encoding when loading a native-format 
WordStar document, which automatically strips the high bit from the trailing 
characters and renders the file readable, but it doesn't seem to interpret 
paragraph flow or any other formatting...







jim

Re: [M100] Wordstar 3.3 for MVT100 and CP/M on M-100

[Jim Anderson]

> -Original Message-
> For matrix printer ribbons you need oil-based stamp pad ink.
> [...]
> BCH is a good brand, but office supply stores usually have something on
> the shelf too but not quite as good quality.

I'm going to have to order some online I guess, or do some sleuthing for an 
independent office-supply store locally which might carry it.  I dropped in to 
Staples a few days ago and they only carry water-based stamp pad ink.







jim

Re: [M100] Sardine Plus

[Jim Anderson]

> -Original Message-
>> possible to modify the UR-2 that's meant to work with this module to
>> somehow access these four ROM images in a REX... so you'd have the full
>> dictionary available without having a TPDD device connected.
> 
> I haven't played with it. But I'll pull the roms and post them.

I wish I had the skills necessary to take analyze Sardine and figure out how it 
could be made to access ROM images from REX or REXCPM... it's a dream I'd love 
to be able to make use of but don't have the ability to make happen on my own.  
:)







jim

Re: [M100] rexcpm and mvt100 success

[Jim Anderson]

> -Original Message-
> 
> This will be SO great - I think I mentioned already loading in the full
> distribution of WordStar 4.0 :)

By the way, I didn't follow up on this - I had no success with WordStar 4.0 and 
I suspect the reason might be that the version posted on classiccmp.org might 
be for Z80 rather than 8080.  It doesn't actually say on the site which CPU 
it's for, but it's from 1987 so I'm inclined to think it might not have been 
uploaded by an 8080 user...  I'm guessing it isn't 8086 code because the 
executables are .COM files, not .CMD, and I can at least execute some of the 
small utilities like the ones to do with spellcheck, and they display a bit of 
output indicating that I didn't supply a filename on the command line or 
whatnot... but if I execute WS.COM or WINSTALL.COM the machine displays no 
output and locks up solid - F8 won't even go back to the M100 menu.

I kept a backup image of it in case anybody with more CP/M experience has any 
suggestions, but I did go back to my old image from before I started copying WS 
4.0 into the machine so it's a bit time-consuming to try anything (35 minutes 
to restore the WS 4.0 image, and another 35 minutes to restore my current image 
back).







jim

Re: [M100] CP/M keyboard

[Jim Anderson]

> -Original Message-
> I see your point, Steve. What I could do is have a function key to
> select between say STD, VT100, USER key maps. USER could be
> user-definable as we may encounter software which isn't configurable.

I like this idea.

> Similarly with the video output for the M100 LCD. I was envisaging STD,
> ADM3a, USER. (ADM3a was an early cursor-controlled screen popular with
> CP/M).  This will allow much more software to run on the M100 LCD,
> albeit 40 col, not 80.

So this is a switch for toggling the behavior of the internal LCD between its 
native control codes and ADM3a control codes (and user-defined control codes)?  
Sounds useful as well, although would this add a lot of processing overhead?

> One improvement I'll make (and I'm surprised no one has mentioned) is
> for M100 CP/M to boot-up in its previous configuration, eg if video is
> directed to RS-232 or CASS, it will do that for subsequent boots. Same
> with cursor flash & scroll lock settings.

I actually wanted this almost immediately, but didn't ask because I'm so happy 
to have what we've got :) and don't want to be too demanding for more.  If you 
do implement this, may I suggest that when entering CP/M with the console 
device set to something other than the LCD, it might be good to display a 
message on the LCD to the effect of 'Console on RS-232' or 'Console on BCR' 
etc. so that if the user forgets it was previously set that way they won't be 
banging their heads against the wall trying to 'fix' their broken CP/M install 
because it doesn't seem to be booting...







jim

[M100] REXCPM playing and observations

[Jim Anderson]

So I recently wanted to try printing from WordStar 3.3 and discovered that 
worked quite nicely.  I also discovered that WordStar 4.0 has support for the 
early HP LaserJets (and, therefore, possibly my HP 4000N may understand it), 
and also the spell check may be better integrated and/or at least configurable 
for VT100 unlike the version of SPELSTAR that is on classiccmp.org (and 
reliably check spelling, although I have figured that problem out - more 
below).  Naturally I went on to try putting WordStar 4.0 in USER 4 on my REXCPM 
since I still had more than half the disk space available :)

I ran into a few issues which I thought I'd mention here for the benefit of 
others, and resolved some of them (but not others).

First, a hardware thing: in order to run RXCUTL.BA (the utility for backing up 
and restoring the REX and CP/M parts of the REXCPM memory), you need to unload 
the REX hook (Ctrl-X from the M100 menu screen) and then power-cycle the M100 
to reset the REX module's state.  Well, I was trying to run a backup tonight 
and kept getting the error (I forget the exact message) you get if you forget 
the power-cycle step (which I had definitely not forgotten - multiple times).  
Turns out, while I've got my DMP-105 hooked up to the parallel port and powered 
on, when I turn the M100 off there's power being fed back into the M100 from 
the printer through the parallel port and this keeps the REX from resetting.  I 
only figured this out because it *also* causes the 'low battery' LED on the 
M100 to illuminate when the power is switched off.  Weird, and probably nothing 
can be done about this - I haven't even checked with another parallel printer 
to see if this is unique to the DMP-105 or not.  I just thought I'd mention it 
in case anybody else runs into such a thing.

So, WordStar 4.0 - I discovered in the process of copying this over that 
IMPORT.COM was only copying the first 64kb of any large files over 64kb in 
size.  Further testing shows that this only happens when using IMPORT.COM with 
my NADSbox - if I use mComm on my phone it imports the full file (the largest 
was 163kb).  I don't know if this is a limitation of the NADSbox or just some 
weird interaction between it and IMPORT.COM - of course, there isn't really any 
other way to test pulling a large file over 64kb from the NADSbox that I'm 
aware of...

This got me worried about backup integrity because I'd been making backups 
using RXCUTL.BA to my NADSbox and those files are enormous (545kb for the REX 
backup and 3457kb for the CP/M backup).  What if it doesn't write good data for 
large files?  I know I did a full backup and restore as a test in the first few 
days after I got my REXCPM but I don't remember if that restore was done using 
mComm, LaddieAlpha, or the NADSbox.  I tested tonight making backups to mComm 
and to the NADSbox (this is why I was whining about the speed again earlier 
tonight :) ) and diffed the resulting files - they are identical.  Whew, my 
backups are good.  I'll test later what happens if I restore one of these 
backups from the NADSbox and try to remember to post my results - it will be 
interesting to see if it only supplies the first 64kb or if it goes the 
distance.

Last point - what led me to this whole backup/restore thing is that while I was 
copying over WordStar 4.0 into a new user area I've run into a CP/M limit and 
put too many files into A: for the directory structure to handle.  Sorry, I 
should have counted them to see how many there were, but I'm sure it's a 
documented figure.  It may be that 4mb is overkill for REXCPM unless you're 
planning to store mostly very large files (or unless there's a fix for the 
directory structure limits?), like maybe using WordStar to write a big novel or 
something, or writing very large programs.  I forgot to count the number of 
files I had in all user areas at the time (I've since made a backup and deleted 
a bunch of cruft) but I did note that there was still 1430kb free.

Okay, the above statements about large files etc. may not be so valid - doing a 
little late-night googling right now, I'm finding some info which indicates 
that the file system allocates a directory entry for every 16kb of a file (as a 
workaround for the fact that each directory entry can only keep track of 16 1kb 
blocks)... this means that even if you load it up with large files you're going 
to run out of directory space as a 160kb file would consume ten directory 
entries.  It also seems that the directory can be different sizes on different 
systems and disk formats... so:

I guess this is a question for Philip Avery - how big is the directory 
structure in the 2mb and 4mb REXCPM images?  Can it be made bigger in the 4mb 
image?  If so, is this something one could do oneself (not being an expert on 
filesystems, but being adventurous and willing to play with a hex editor), or 
best left to the professionals?  :)







jim

Re: [M100] REXCPM in M-100 - Success!

[Jim Anderson]

> -Original Message-
> >> - D.COM (A better directory lister)
> >> - SWEEP.COM (also known as New Sweep, file operations program)
> >
> > I would love to give these utilities a try, if you find somewhere to
> upload them.
> >
> 
> Yes, I have a WIKI account now so I believe I can upload them to the

I've been meaning to get around to this for quite some time (been having an 
awful time with work the last couple of weeks) but I did finally download these 
files and try them out - they're awesome!  Thank you for sharing!







jim

Re: [M100] rexcpm and mvt100 success

[Jim Anderson]

> -Original Message-
> IMPORT.COM is in line for upgrade, though it'll be into next year before
> I get to it. By then we may have 8.3 filename support from the TPDD
> emulators. I intend to upgrade IMPORT to:
> - support wildcard filenames
> - 8.3 filenames
> - subdirectories

This will be SO great - I think I mentioned already loading in the full 
distribution of WordStar 4.0 :)

(also, HINT HINT to John, Kurt, etc: 76800bps large packet support!  I've been 
doing REX backups and restores lately and oh boy, could I ever use more speed!  
Even if it's a pre-release version!)







jim

Re: [M100] Wordstar 3.3 for MVT100 and CP/M on M-100

[Jim Anderson]

> -Original Message-
> 
> Yes, M100 CP/M prints to the M100 parallel port. Try LPRINT in MBASIC to
> get your setup working - it does definitely work. I don't know for sure
> with WordStar, but it could be necessary to do STAT LST:=LPT:   before
> firing up WordStar.

I dragged my Tandy DMP-105 out of the closet to try this out, and initially I 
met with failure because I went straight into assigning LST: to LPT: as you 
suggested.  I didn't even try it out of the box first, and it turns out it just 
works as-is!  Fantastic!

The ribbon in my printer is pretty dry and the sponge is rotting apart.  I knew 
about this problem already so this time I took the cartridge apart (which I've 
had a saved search set on ebay going for over a year now with no luck), cut out 
a new sponge which is not exactly round but close enough to work, and then 
realized I don't have any ink and don't really know what sort of ink would be 
appropriate (I'm thinking it should be thick?) nor where to buy it.  I'd guess 
the ink they sell for refilling your own inkjet cartridges is too thin?  Anyone 
have experience with re-inking printer ribbons?







jim

Re: [M100] Wordstar 3.3 for MVT100 and CP/M on M-100

[Jim Anderson]

> -Original Message-
> > when we get generally agreed "good adaptations" of CP/M software that
> people are happy with, I think post-configuration versions of the
> applications should be stored at the wiki.  It will save time for
> others!
> >
> 
> yes - that would be SUPER helpful for CP/M noobs like myself who are
> currently struggling to get WS configured for the Tandy 100. :-/

I was wondering how useful it would be to have a ZIP file posted of all the 
necessary files to run WordStar 3.3 (including a WS.COM pre-configured for 
VT100, standard printer on LST:, and all default options), and then have a 
subfolder inside that with the optional files in case you want to run WINSTALL 
to customize it yourself.  It would save a fair bit of copying if you just want 
to be able to get it loaded and running quickly.  WordStar 3.3 only needs three 
files to run (WS.COM, WSMSGS.OVR and WSOVLY1.OVR) and three more files to 
customize for different terminal types, printers, and other program options 
(WINSTALL.COM, WS.INS and WSU.COM).  I don't think the WS.COM available for 
download on classiccmp.org is configured for VT100 though, so a ZIP with a 
VT100-preconfigured WS.COM would probably be helpful.

Actually, I think there are more things that would go well inside said ZIP file 
- I've tracked down PDFs of the installation manual and reference manual, a 
training guide (although I think that's for 3.0), a short list of patch points, 
and a long list of patch points (WS-BIBLE.DOC).  Another thing that would be 
helpful would be a little write-up on the WordStar file format and on 
conversion - I found a little perl script which strips the high bit from the 
trailing character of each word, which can also be done pre-transfer with a PIP 
command - modern word processors seem to have no facility to import a WordStar 
document and this at least lets you bring in the text of the document even if 
it doesn't interpret the formatting codes and dot commands.







jim

Re: [M100] Sardine Plus

[Jim Anderson]

> -Original Message-
> I have here a PG Design ROM expansion that fits T102.
> 
> The unit has 4 molex sockets with the 100/200 pinout to take standard
> option roms, and 4 regular dip sockets with apparently regular 27C256
> pinout.
> 
> All 4 regular sockets are filled with this Sardine Plus, which look like

I'm a bit behind on this, but I don't see any messages to this effect - did you 
get this going?  Ever since I heard of this all-ROM version of Sardine, I have 
thought about how awesome it would be if it were somehow possible to modify the 
UR-2 that's meant to work with this module to somehow access these four ROM 
images in a REX... so you'd have the full dictionary available without having a 
TPDD device connected.







jim

Re: [M100] User number in CP/M for M-100?

[Jim Anderson]

> -Original Message-
> Hi Jim,
> 
> I do not recall CP/M ever dumping me back into user area 0 whenever I
> run a program.  On the Kaypro and the M-100 I stay in my current user
> area, unless I change it with another USER command.  The documentation
> states that behavior as well.

Maybe this was something specific to the Kaypro distribution of CP/M?  In my 
experience with using it on the M100, I end up back in USER 0 after executing 
any .COM program *except* for STAT.COM for some reason.  Anything else I have 
tried, whether it's 3rd party of part of CP/M (MBASIC.COM, PIP.COM, etc.) all 
land me back in USER 0 after execution.  Needless to say, this makes loading a 
software package with multiple files a tedious process:

A>USER 4
A>IMPORT SIXCHR.NM EIGHTCHR.NAM

A>USER 4
A>IMPORT NEXTFI.LE NEXTFILE.TXT

...repeat times 40 files for WordStar 4.0 (including all the sample documents) 
which is something I was just working on tonight.







jim

Re: [M100] Wordstar 3.3 for MVT100 and CP/M on M-100

[Jim Anderson]

> -Original Message-
> I finally got some time to assemble my MVT100 and get it going, and now
> I have a good console for CP/M on my M-100!  I can get my copy of
> WordStar running on it but it is configured for my Kaypro and the
> control codes are not the same.  Has anyone configured WordStar for
> MVT100 and if so, is it available?  I can do it but I want to be sure
> it's OK to post before I do that.  Thanks.

I've done it, but it's quite easy to do yourself - if you go to 
http://www.classiccmp.org/cpmarchives/cpm/Software/rlee/M/MICROPRO/WORDSTAR/V3-3/8080/
 and download WINSTALL.COM, WS.INS, and WSU.COM (assuming you don't already 
have them), you can then run WINSTALL and generate a new WS.COM containing your 
own customized parameters (there's a lot more you can customize beyond just the 
terminal type).  VT100 is a standard terminal type (I think it is selection F 
on the first screen of terminals).

I'm still trying to figure out how to edit the terminal control codes for 
SPELSTAR.OVR because the version on that site is configured for some other 
terminal type, there isn't an installer for it, and aside from that there's 
something wrong with their copy of SPELSTAR.DCT because I only seem to have 
less than 50% success spell-checking files - it often aborts saying that 
there's an invalid dictionary entry.

As an aside, a general question for anyone familiar with CP/M (or maybe this is 
a question specifically for Phil Avery): is there printing support from within 
M100 CP/M to the M100 parallel port?  If so, what would I select as my printer 
output device in WordStar to make this happen?  I tried setting it to the 
"Standard List Device (LST:)" and when I try printing the machine seems to lock 
up, which may just be because I didn't have a printer hooked up at the time.  I 
do have a parallel cable, and my trusty old LaserJet 4000N has a parallel port, 
I guess I just have to get going and move the MVT100 and monitor closer to the 
printer so I can actually try it...







jim

Re: [M100] low VEE voltage - help me?

[Jim Anderson]

> -Original Message-
> While the +5 and -5 are off the same transformer, the +5 is designed for
> a much greater current draw.  Regulation on the -5 is simply by
> zener.  A back of the envelope analysis of the Zener supply suggests
> that with the 180 ohm R97, and a -7.6v supply, it is only rated at 15mA
> or so, which is not much, so any excessive load will drop the -5v.

I learned something today!  After reading this and googling 'zener diode 
regulation' I now understand what is going on - I did not previously know about 
this property of zener diodes and I was assuming (given its orientation) that 
it was just there to help rectification by shunting any positive voltage to 
ground (although this made no sense since D15 already ensures there won't be 
any positive voltage at that point in the circuit).  I had assumed that somehow 
the value of R97 had been chosen so that they would end up with -5v assuming a 
constant load, which also made little sense since other motherboards I've 
checked produce a pretty solid -5v with or without the LCD module plugged in...

> I would be looking at the 4585 chips driver chip, or the opamps used for
> the modem, or those caps etc.
> 
> You could remove the -5v supply to M29 and M38, by carefully cutting the
> trace to pin 11 - that would remove the -5v and see if that
> helped.  Same for M35, pin 7 is the -5v supply.

Ouch.  Well, I guess I can try that by finding points on the board where it 
would be easy to bridge the cut with solder later.  I keep hoping these 
desoldering needles are going to show up...

One thing I've got which may be helpful is an old Fluke digital multimeter I've 
had since I was a pre-teen (Dad gave it to me because his employer was throwing 
it out!!).  It's an 8030A which is an LED-based 3.5-digit unit from the '70s 
(runs on 4 NiCd C-cells) but it still works great and it has a nice DC current 
function that goes from 2000 milliamps down to a 200 microamp scale (with 
decimal point for a 1/10 microamp resolution).  I guess I can just as easily 
tell whether I've isolated the problem component by whether or not the voltage 
can maintain -5v :) but it would be nice to know what exactly it's trying to 
draw.

> This will be a complex repair - but when you find it it will be
> extremely satisfying.

Thanks so much for chiming in on this issue - I would be lost without your 
guidance!  :)  My kids are here this week so I may not have time to get back at 
it until after next Sunday, I'll post again when I have more info.







jim

Re: [M100] having fun with MVT100

[Jim Anderson]

> -Original Message-
> Jim, to your question on speed, the limit is actually the VT100 adapter.
> The M100 can easily overdrive the VT100 adapter with characters.  You
> can do this with BASIC even, just sending characters flat out will
> eventually fill the buffer and overflow on the PIC processor.
> 
> So, 57600 is really just a convenient rate for the BCR hack.

Ah, OK.  I hadn’t really compared side-by-side with the old VT100-clone 
terminal I had been using before.  (I’d only be able to compare at 19200, 
though – aside from not going up to 57600, it doesn’t do TTL)

I did notice that the MVT100 handles the output of native M100 applications 
better, of course (because of the escape sequences you added to the firmware) 
but there is a bug I've noticed - when using TEXT to edit a file longer than 
one screen, if you scroll down to the bottom of the file the text scrolls 
properly, but if you then cursor-up back past the top of the screen, as you 
continue to cursor-up it only re-draws the new line at the top of the screen 
and doesn't move the rest of the text down.  I don't know if there's a 
reverse-scroll escape code it is trying to use, or if it should be re-drawing 
the whole screen as you go backwards in the file (I hope not, but that's what 
WordStar has to do on the VT100 when you scroll back in a file, so maybe there 
isn't such a code).  I don't see anything about a reverse-scroll escape code on 
your VT100 wiki page (in the codes list at the bottom).







jim

Re: [M100] having fun with MVT100

[Jim Anderson]

> -Original Message-
> Jim,
> yah, I think we will find things that can be improved.  for a next board
> spin (I only ordered 30 boards initially) I can add a track/ jumper.
> nice idea to "power" the DB25 port also!

I've actually been meaning to do this for quite a while, to power my Bluetooth 
serial adapter, but never got around to it.  Sadly, it seems the Bluetooth 
adapter draws too much power - I don't know if a freshly-recapped motherboard 
would be able to power it or not, but the machine I put these jumpers in only 
has a new memory battery - the first board I recapped is the one with the bad 
VEE supply that I'm still trying to fix.  In any case, the modified serial port 
will power the MVT100 just fine, but my Bluetooth adapter drags VDD down quite 
a bit, the display dims, the machine starts rebooting (I'm guessing the power 
supply shuts down and then restarts itself?) so I will have to put this idea 
aside for the future to see if a recapped motherboard can handle the load.

> The issue of how the fonts look is a bit beyond my pay grade for
> now.  What is implemented is exactly what was done in the original
> design.
> [...]
> The font has grown on me ;)

Yeah, I realize the issue, and please don't think I'm complaining to you about 
the way the font scales :) - to fix it properly would require something much 
beefier than a PIC and a whole lot more coding because you'd have to be able to 
output different resolutions to match the native resolution of the attached 
monitor, and you'd have to scale the font to the output resolution.  (I suppose 
it would be easier to support a limited set of output resolutions and store 
individually scaled bitmapped fonts for each of those resolutions... still a 
heck of a lot of work, and it won't fix it for every monitor.)

Of course, at that point it's easier to take the sledgehammer approach - build 
a Pi image that just boots up and displays an 80x24 console terminal running 
'screen /dev/ttyS0' to the HDMI output ;)







jim

Re: [M100] low VEE voltage - help me?

[Jim Anderson]

> -Original Message-
> 
> The -5V supply is off the same transformer as the +5 v supply.

I know, that's what really baffles me - how the +5 could be fine and -5 be so 
low!

> The fault domain could be:
> 
> 1) D15 Shorted or Open - Check with multimeter

I did lift a few of the diodes off - D15 shows 0.54 volts forward drop and open 
in reverse.  I'm not sure if that's a good value for that diode or not, but at 
least it isn't shorted or open.

> 2) R97 Open - Check with Multimeter

Checked, and it's 180 ohms.

> 3) Zener D14 Shorted, or incorrect voltage - Check supply voltage Across
> C85

I lifted and checked D14 and got 0.73 volts forward drop and open in reverse 
(again, not sure if this is an appropriate value or not).  I didn't check the 
voltage across C85 before lifting D13, D14 and D15 - would it be any use 
testing the voltage between the D15 input (terminal 9 on the transformer) and 
ground?  Or should I put the diodes back in circuit before powering it on?

> 4) C86 shorted or leaky

I did just finish replacing all the caps and it's pretty much the same as it 
was with the old caps.  I just double-checked C86 with an ohmmeter and it seems 
as expected (starts in the megohms and declines into the hundreds of kilohms 
over the space of several seconds).

> 5) Excessive load on -5V supply - Just R97 and see what the available
> supply is between D15-R97 and ground.

I'm not sure what you mean - is 'just' a typo?  Did you mean to lift R97 and 
then check the voltage (across C85, basically)?  I did this (after putting D13 
and D15 back first) and I get -7.6 volts which is about what the service manual 
says it should be (page 4-32) without R97 and D14 to stabilize it at -5 volts.  
(I still have D14 lifted and when I touch R97 back into place the voltage drops 
immediately to -1.7 volts, so D14 doesn't seem to be contributing anything to 
the fault.)

I've been thinking a bit about this idea of excessive load - I know the LCD 
needs VEE but I don't have the LCD module connected to this board, so what else 
uses it?  I know RS-232 needs negative voltage, and I see it used several 
places there for six pulldown resistors and feeding into pin 7 of M35.  After 
more peering at the schematic (sort of a "where's waldo" for VEE arrows) I 
spotted it on M29 and M30 pin 11 (listed as bipolar op amps), at T1 through 
R113 (presumably as a pulldown for the buzzer circuit - R113 tests OK at 3.2 
kilohms), and of course the LCD connector pin 3.  I didn't spot anything else - 
could that be all?

Not sure where to go from here - assuming I've identified all the places VEE 
goes on the motherboard, I guess I'd have to pull M35, M29, and M30 (one at a 
time, of course) to see if one of them is the culprit.  I don't have a good 
desoldering vacuum (just a springloaded handheld one) and I'm still waiting for 
the set of desoldering needles I ordered from China to arrive.  I would think 
that with the desoldering needles I'd be able to disconnect just one pin from 
an IC without pulling the whole thing... but that's just my theory, I haven't 
ever tried them.

> Check out my awesome clocks at

I love these!  Time to start saving my pennies again... :)







jim

[M100] having fun with MVT100

[Jim Anderson]

On a more uplifting note, I received my MVT100 in the mail last week and I've 
been having a blast with it!  I thought I'd share a few things which others 
might find helpful:

I added the jumper for the BCR TTL serial hack to the machine I've been using 
for my REXCPM (the old SOD hack, because I'm unlikely to go the Z80 route and 
didn't want to be bothered patching things).  While I was in there I also ran a 
jumper to supply VDD (which I picked off from a nearby via which supplies pin 9 
in the BCR port) to pin 22 on the RS-232 port - this is the Ring Indicate 
signal from a modem and isn't connected to anything in the M100, but more 
importantly, it maps to pin 9 when you use a DE-9 adapter.  I was inspired by 
Stephen's post about adding a jumper to the MVT100 to power it off pin 9 (which 
I have also done) and which reminded me that my old Bluetooth serial adapter 
also is capable of drawing power from pin 9.  This way, I can run the MVT100 
off either the BCR or the RS-232 port and it'll receive power.

If there's a future need to revise the MVT100 board design, it might be useful 
to add a trace and a jumper to allow the user to easily enable/disable power 
draw from pin 9 - the way it is now, I'm not sure whether Bad Things would 
happen if I tried using the board as a USB serial adapter while it was 
connected to my M100, since that would common the M100's VDD with the USB power 
supplied by the PC...

A note on screen resolutions: I had not even thought about this until I got it 
and started playing around with it, but the text font the MVT100 uses can look 
absolutely hideous when it's being scaled poorly by an LCD monitor.  This isn't 
specifically an MVT100 issue - LCD monitors often wreak havoc on text when they 
are scaling from a non-native resolution, and it's something I'd just forgotten 
about because it's been so long since I had to drive an LCD at its non-native 
resolution.  My original plan for my MVT100 was to use it with an older NEC 15" 
LCD I had which is native 1024x768 - too low to be useful for a PC, but I 
thought the compact size and 4:3 aspect ratio would make it a perfect terminal 
display.  Alas, it's actually almost the worst thing to use, because the MVT100 
output is 640x480 and that means there aren't enough pixels to do an acceptable 
job of scaling, giving characters that alternate from skinny to fat as you read 
down a line of text...

I also tried with a 1280x1024 LCD on the theory that I might be able to tweak 
the pixel clock settings in the monitor and get it to map at least the 
horizontal pixels 2:1 but this monitor doesn't let you tweak very much (it 
mostly relies on the auto-adjust routine).  I got it looking better than the 
small LCD but I still wasn't very happy with it (and it still didn't look as 
good as sending it into a bit 1920x1080 LCD).

Of course, it looks the best by a long shot when you send it into a good old 
VGA CRT, which arguably is the most retro-looking solution of all, and lucky 
for me I never did throw away that little paper-white monochrome VGA monitor I 
got back in the 90s (yes, I said monochrome VGA!).  It's kind of perfect for 
this - it doesn't even pretend to represent all colours, it only uses the green 
signal (which is all the MVT100 is jumpered to output as I received it) so it 
all works out almost as if it was meant to!

One other thing: I don't know what is limiting the display output speed, but 
when I started using the BCR at 57600bps I was expecting the display to update 
faster and it seems like it actually is the exact same speed as it was on the 
serial port at 19200bps.  From past experience using dumb terminals I had been 
feeling like even the 19200 output was displaying a bit slower than it could 
(it felt like 9600) and I'm wondering if this is just a result of the processor 
having to take turns between executing program instructions and bit-banging 
each output byte.  Please don't take this as a complaint about it being slow - 
the speed is fully in keeping with my expectations for the platform, and it's 
lightning-fast compared with the internal LCD :) I just wonder what is limiting 
it because I know the M100 is capable of faster data transfer... (speaking of 
which, I'm still dying to have access to the high-speed large-packet data 
transfer capability for backing up and restoring REXCPM)

Anyway, it all works great and I couldn't be happier with this solution!  Many 
thanks to Stephen for sharing your genius ideas with us!







jim

Re: [M100] low VEE voltage - help me?

[Jim Anderson]

I did the full set of electrolytics, a total of 17 – C49, C50, C52, C54, C55, 
C75, C76, C77, C78, C82, C83, C84, C85, C86, C90, C92, C103.  (I know the 
majority of these have nothing to do with the power supply, it’s mostly meant 
to prevent future issues due to capacitor failure.)







jim

From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Stephen 
Adolph
Sent: Thursday, October 15, 2020 04:18
To: m...@bitchin100.com
Subject: Re: [M100] low VEE voltage - help me?

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

Which capacitors in particular did you replace?

On Thu, Oct 15, 2020 at 2:21 AM Jim Anderson 
mailto:jim.ander...@kpu.ca>> wrote:
Hi,

My first M100 died on me about two years ago with a problem where the VEE 
supply voltage is low (between -1.4 and -1.7 volts, instead of the expected 
-5v).  At the time I posted here and the best guesses centered around one or 
more bad capacitors, particularly C85.  I did get around to removing C85 at the 
time and it did have a tiny amount of fuzzy crud on the bottom around the 
leads.  I put the whole thing aside and swapped in a motherboard from another 
parts machine.

Fast forward to this year, after continuously putting off ordering the 
capacitors from digikey, I finally ordered several capacitor replacement kits 
and nimh memory batteries from arcadeshopper and today sat down to re-cap this 
motherboard.  Well, it seems maybe I should have started with a different 
machine because all I've done is blow a few hours and frustrate myself.  I 
checked after replacing C85 and VEE was still only -1.7 volts, so I soldiered 
on in the vain hope that maybe another bad cap was at fault - replaced all the 
caps and sure enough it was still only -1.7 volts when I was done.  :(

VDD is correct (+4.97 volts) and the memory nimh is charging when power is 
connected (voltage at the battery rises).  I'm testing the motherboard without 
the lcd or keyboard connected as I'm pretty sure it's supposed to be able to 
make -5v on VEE without those components connected...

I'm not really familiar with expected diode test values, but to give you guys 
some additional info to go on (in case any of these are bad) I lifted one end 
on each of D13, D14, and D15 to test them, measured 0.22, 0.73, and 0.54 volts 
forward drop respectively and open circuit in reverse.  I don't know if those 
are appropriate values.  I also checked R97 and it is 180 ohms as expected.

Help!!!  I feel like I've been banging my head against the wall all evening.







jim

[M100] low VEE voltage - help me?

[Jim Anderson]

Hi,

My first M100 died on me about two years ago with a problem where the VEE 
supply voltage is low (between -1.4 and -1.7 volts, instead of the expected 
-5v).  At the time I posted here and the best guesses centered around one or 
more bad capacitors, particularly C85.  I did get around to removing C85 at the 
time and it did have a tiny amount of fuzzy crud on the bottom around the 
leads.  I put the whole thing aside and swapped in a motherboard from another 
parts machine.

Fast forward to this year, after continuously putting off ordering the 
capacitors from digikey, I finally ordered several capacitor replacement kits 
and nimh memory batteries from arcadeshopper and today sat down to re-cap this 
motherboard.  Well, it seems maybe I should have started with a different 
machine because all I've done is blow a few hours and frustrate myself.  I 
checked after replacing C85 and VEE was still only -1.7 volts, so I soldiered 
on in the vain hope that maybe another bad cap was at fault - replaced all the 
caps and sure enough it was still only -1.7 volts when I was done.  :(

VDD is correct (+4.97 volts) and the memory nimh is charging when power is 
connected (voltage at the battery rises).  I'm testing the motherboard without 
the lcd or keyboard connected as I'm pretty sure it's supposed to be able to 
make -5v on VEE without those components connected...

I'm not really familiar with expected diode test values, but to give you guys 
some additional info to go on (in case any of these are bad) I lifted one end 
on each of D13, D14, and D15 to test them, measured 0.22, 0.73, and 0.54 volts 
forward drop respectively and open circuit in reverse.  I don't know if those 
are appropriate values.  I also checked R97 and it is 180 ohms as expected.

Help!!!  I feel like I've been banging my head against the wall all evening. 







jim

Re: [M100] User number in CP/M for M-100?

[Jim Anderson]

> -Original Message-
> I'm specifically looking for support for "user numbers" since CP/M does
> not support directories.  My Kaypro runs CP/M 2.2G and 2.2H.  In those
> versions, the user number is part of the prompt, such as A0> or A1>.
> Also, if you navigate to user area 1 with "USER 1", you can call any
> executable in user area 0 in case it does not exist in user area 1.
> There are 16 such user areas available, 0 to 15.

Okay, so I feel dumb now - I just finished writing up a response to a message 
you sent on the weekend including a dive into what I did with user areas, and I 
hadn't caught up yet on today's messages so I didn't know this has already come 
up.  But yeah, in summary, there are user areas in 2.2 and no, they don't show 
in the prompt and you can't execute things from user areas other than the one 
you're currently logged to (which leads to the fun gymnastics of getting 
PIP.COM into each user area).  You might still be able to make use of the info 
in that message about fixing the terminal emulation in your copy of WordStar 
though.







jim

Re: [M100] compile and execute Turbo Pascal

[Jim Anderson]

> -Original Message-
> Never used Pascal myself, but a co-worker wrote me a File Management
> program that started AutoCAD, on MS-DOS 5 under Windows 3.11 and passed
> startup commands to it. Borland Turbo Pascal had a nice facility for
> starting another DOS Shell in which you could start another program with
> full memory available to the program, including the 386K of Extended
> Memory in a 1Mb system.

This brings back memories of one of the more 'serious' things I wrote in Turbo 
Pascal (for DOS) before moving on to C, which was a mouse-driven application 
launcher for my sister's PC.  That was the first thing I used where I called 
interrupts (to interface with the DOS mouse driver), and although it started 
out with a hand-built data file for defining each of the applications in the 
launcher menu I did eventually add on a data file maintenance (add/edit/remove 
entries) subsystem which was also mouse-driven.  It wasn't exactly enormous, 
but it was the largest project I wrote in Turbo Pascal.

I was also an early adopter of the multi-monitor workstation once I got VGA - I 
had a Hercules clone MDA adapter and an amber monitor off to one side of my 
desk.  You could switch between your colour and MDA monitors using the DOS 
'mode' command, and Turbo Pascal (as well as Turbo C) had a dual monitor option 
you could enable where it would display program output on whichever monitor was 
active at launch, and the IDE interface on the other monitor.  This was 
fabulous for line-by-line debugging because normally TP would have to flash 
between the output screen and the IDE every time you hit the F-key for stepping 
to the next line, which was not only slow but you couldn't really see what had 
happened on the output screen.  With the output on its own monitor you could 
watch it as it changed, and the steps were pretty much instantaneous.  Fun 
times!

I also kept this dual setup when I was running OS/2, because not only did TP 
and TC still work fine with dual monitors in a full-screen DOS box in OS/2, but 
you could leave something running in a DOS box in the background which you had 
full-screened and switched to mono, and it would stay on the mono monitor for 
you to keep an eye on it when you hit Ctrl-ESC to go back to the OS/2 GUI.  
IIRC, I think Turbo C for OS/2 also would let you output a text-mode program 
full-screen to the mono monitor even though it was a GUI-based IDE...







jim

Re: [M100] REXCPM in M-100 - Success!

[Jim Anderson]

> -Original Message-
> I also transferred some executables from my Kaypro to this machine and
> they work as well:
> - D.COM (A better directory lister)
> - SWEEP.COM (also known as New Sweep, file operations program)

I would love to give these utilities a try, if you find somewhere to upload 
them.

> - Wordstar 3.3, which runs but as we discussed, will not fit on an 8x40
> char screen, and being configured for the Kaypro, likes to write a *lot*
> of control characters to the screen.

I put WordStar 3.3 on my M100 not long after getting it up and running, and 
I've actually been using it for quite a bit of writing (sitting in front of the 
TV, using a C.Itoh VT100-compatible amber CRT terminal as the display while I 
wait for the MVT100 board), combining the wonderful feel of the M100 keyboard 
and the familiarity of WordStar commands.  I never used WordStar back in the 
day, but I did use an editor in DOS (I think it was called TED) that used 
WordStar control-key commands, so it feels like home.

I downloaded it from 
http://www.classiccmp.org/cpmarchives/cpm/Software/rlee/M/MICROPRO/WORDSTAR/V3-3/8080/
 which also has WINSTALL.COM so you can configure it for a VT100 terminal (or 
whatever terminal type you want).  I also installed SPELSTAR which is available 
there, too, but there doesn't seem to be a way to configure the terminal 
emulation for SPELSTAR.OVR and I can't turn up documentation on patch addresses 
for that file.  It spews a weird mixture of VT100 escape sequences and some 
sequences I'm not familiar with.  (It also throws an error about an invalid 
entry in the dictionary when spell checking more than 50% of the files I tried 
it on, so...)

Another option for fixing your WordStar copy is to change the Kaypro terminal 
escape sequences to VT100 sequences right in WS.COM by patching it (editing it 
with DDT).  I found a nice document covering the patch addresses of several 
different WordStar versions, but didn't keep at tab open (just saved the text 
file) and I can't seem to find it again tonight in spite of all my Googling 
efforts.  I could email it to the list if more than one person wants it.  I did 
turn up other lists of patch addresses for specific versions but none of them 
seemed to be as clean as this list.  The most verbose resource (which is also 
easy enough to find) is an old WordStar document called WS-BIBLE.DOC which 
covers the patch addresses in great detail, but the version I found needed to 
have the high bits stripped as it's an actual WordStar document and (as many of 
you may already be aware) modern word processors don't seem to have a WordStar 
import mechanism for whatever reason...

I don't know if this warrants a separate post or new thread or anything, but I 
was going to mention something I found very helpful to organize the enormous 
REXCPM disk space - user areas.  This might be totally obvious to everyone 
else, I don't know, but it was new to me since I'd never used CP/M seriously 
before and had never had an opportunity to worry about organizing large 
disparate collections of files on a single disk without subdirectories.

There are several fun caveats about user areas, one of which is that you can't 
execute commands from another user area like you can from another disk drive, 
so you get into a bit of a catch-22 starting out.  I wanted to put WordStar and 
my document files in their own user area (I actually have user areas 0 through 
3 in use for various different groupings of files now) and so you at least need 
IMPORT.COM in that user area to bring files in from your TPDD device.  PIP has 
an option to copy files from another user area, PIP IMPORT.COM=IMPORT.COM[G0] 
(where [G0] means 'get this file from user area number 0').  That's great, 
except PIP.COM is not in the new user area yet so you can't execute it.  To get 
PIP.COM into a new user area the CP/M manual has the following handy (?!?) 
solution (I'll save you the trouble of calculating it and tell you that in the 
CP/M image for REXCPM the NEXT value is 1E00 and the number 's' below is 
therefore 29 - also note that at least in my PDF of the CP/M manual there is a 
typo or possibly OCR error and G0 (gee zero) was erroneously written as GO (gee 
oh) which frustrated me until I realized the mistake):

==
Note: to copy files into another user area, PIP.COM must be located in that 
user area. Use the
following procedure to make a copy of PIP.COM in another user area.

USER 0  Log in user 0.
DDT PIP.COM (note PIP size s) Load PIP to memory.
G0  Return to CCP.
USER 3  Log in user 3.
SAVE s PIP.COM

In this procedure, s is the integral number of memory pages, 256- byte 
segments, occupied by
PIP. The number s can be determined when PIP.COM is loaded under DDT, by 
referring to the
value under the NEXT display. If, for example, the next available address is 
1D00, then
PIP.COM requires 1C hexadecimal pages, or 1 times 16 + 12 = 28 pages, 

Re: [M100] compile and execute Turbo Pascal

[Jim Anderson]

I thought so, I just wanted to be sure.  Now I understand what you meant about 
removing the 8085 undocumented opcodes (to make CP/M run on the Z80).  On first 
reading I somehow got the opposite impression but then wondered why you 
specifically mentioned the dual CPU board…







jim

From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Stephen 
Adolph
Sent: Wednesday, September 30, 2020 4:16 PM
To: m...@bitchin100.com
Subject: Re: [M100] compile and execute Turbo Pascal

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

oh, right ;)  Turbo Pascal on CP/M only runs on Z-80, not 8080 or 8085.

On Wed, Sep 30, 2020 at 6:34 PM Jim Anderson 
mailto:jim.ander...@kpu.ca>> wrote:
I’m not sure if you’re saying it running on the 80C85 or the Z80?







jim

From: M100 
[mailto:m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>]
 On Behalf Of Stephen Adolph
Sent: Wednesday, September 30, 2020 3:17 PM
To: m...@bitchin100.com<mailto:m...@bitchin100.com>
Subject: [M100] compile and execute Turbo Pascal

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

Well, that feels good!

I finally got Turbo Pascal 3.01 configured (well enough) and running on Model 
100!  And I compiled and ran a demo provided by Borland.  Sweet!

Setup:
REXCPM 2MB
M100 CP/M (modified to remove 8085 undoc opcodes)
Dual CPU board with 80C85 and NSC800 (socket at CPU on M100)
Dual Main ROM adapter (need a specific mainROM for each processor)

Re: [M100] compile and execute Turbo Pascal

[Jim Anderson]

That’s exactly how long it’s been for me, too, and how I felt about it before I 
started to learn C.  :)







jim

From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Ken Pettit
Sent: Wednesday, September 30, 2020 4:42 PM
To: m100@lists.bitchin100.com
Subject: Re: [M100] compile and execute Turbo Pascal

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

Hmm, I haven't programmed in Pascal since Freshman year in college.  Back then 
it was my favorite programming language (I hadn't learned C yet).  Not sure I 
would even recognize it now.  :)

Ken
On 9/30/20 4:16 PM, Stephen Adolph wrote:
oh, right ;)  Turbo Pascal on CP/M only runs on Z-80, not 8080 or 8085.

On Wed, Sep 30, 2020 at 6:34 PM Jim Anderson 
mailto:jim.ander...@kpu.ca>> wrote:
I’m not sure if you’re saying it running on the 80C85 or the Z80?







jim

From: M100 
[mailto:m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>]
 On Behalf Of Stephen Adolph
Sent: Wednesday, September 30, 2020 3:17 PM
To: m...@bitchin100.com<mailto:m...@bitchin100.com>
Subject: [M100] compile and execute Turbo Pascal

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

Well, that feels good!

I finally got Turbo Pascal 3.01 configured (well enough) and running on Model 
100!  And I compiled and ran a demo provided by Borland.  Sweet!

Setup:
REXCPM 2MB
M100 CP/M (modified to remove 8085 undoc opcodes)
Dual CPU board with 80C85 and NSC800 (socket at CPU on M100)
Dual Main ROM adapter (need a specific mainROM for each processor)

Re: [M100] compile and execute Turbo Pascal

[Jim Anderson]

I’m not sure if you’re saying it running on the 80C85 or the Z80?







jim

From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Stephen 
Adolph
Sent: Wednesday, September 30, 2020 3:17 PM
To: m...@bitchin100.com
Subject: [M100] compile and execute Turbo Pascal

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

Well, that feels good!

I finally got Turbo Pascal 3.01 configured (well enough) and running on Model 
100!  And I compiled and ran a demo provided by Borland.  Sweet!

Setup:
REXCPM 2MB
M100 CP/M (modified to remove 8085 undoc opcodes)
Dual CPU board with 80C85 and NSC800 (socket at CPU on M100)
Dual Main ROM adapter (need a specific mainROM for each processor)

Re: [M100] Our experiences repairing a faulty RS-232 circuit in a NEC PC-8201a

[Jim Anderson]

I wonder what might be wrong with the RS-232 on my T102.  On some rare 
occasions the port works (most often after I haven’t used it for a while), but 
after a few minutes it reverts to the usual problem, which is that it seems to 
receive a stream of garbage characters whenever the RS-232 port is connected to 
something.

If I go into TELCOM on the T102 and go online with F4, then connect my NADSbox 
and turn it on (or connect a serial cable from a PC), the screen starts filling 
with bursts of garbage characters.  In the case of connecting it to a PC, the 
garbage characters appear whether the COM port is open or not, and if I open 
the COM port with PuTTY or something similar and type some characters, I don’t 
see them in the stream of garbage.

As soon as there is no signal voltage coming in to the T102’s port (whether by 
unplugging or just switching off the connected device), the garbage stream 
stops.  Needless to say, the same devices and cables work perfectly on several 
other M100s and a T200.  I only have the one T102, and it has had this problem 
since I acquired it.

Anybody run into this before?







jim

From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Jeffrey Birt
Sent: Thursday, August 20, 2020 12:21
To: m...@bitchin100.com
Subject: Re: [M100] Our experiences repairing a faulty RS-232 circuit in a NEC 
PC-8201a

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

Silly me. I completely missed there was two parts 

Jeff Birt


From: M100 
mailto:m100-boun...@lists.bitchin100.com>> 
On Behalf Of Terry Stewart
Sent: Thursday, August 20, 2020 2:02 PM
To: m...@bitchin100.com
Subject: Re: [M100] Our experiences repairing a faulty RS-232 circuit in a NEC 
PC-8201a


On Fri, 21 Aug 2020, 1:24 am Jeffrey Birt, 
mailto:bir...@soigeneris.com>> wrote:
Great write up. I always enjoy the troubleshooting process as much as the fix.

Given that both chips failed at once I
Jeff,

Thanks. Good thoughts but I'm not sure if you read the second article (part 2) 
where we found the real culprit (:

Terry (Tez)

Re: [M100] Model T Terminal

[Jim Anderson]

TEXT definitely uses it.  It’s hard to tell because the emulation isn’t quite 
right using PuTTY, but when I was messing with VT100.CO it seemed like the 
screen in TEXT got all messed up when scrolling down through a large file 
unless I sized the window at 80x25.  It still seems to get really messed up if 
I turn on the Label line (although worse if it’s 80x24).  I think BASIC is 
pretty messed up with the Label line turned on, too.  I’ll have to go try it.

Are TEXT and TELCOM maybe the only M100 applications which actually make use of 
the full 80x25 of a DVI?  I hadn’t really thought about it.  If the screen area 
of the MVT100 is not user-selectable then I guess 80x24 is the most compatible 
mode – not so useful for TEXT or TELCOM or having the Label line turned on in 
BASIC but definitely best for CP/M and at least it’ll give a large area to 
scroll for BASIC programs that weren’t intended for the M100…







jim

From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Stephen 
Adolph
Sent: Tuesday, July 28, 2020 5:05 PM
To: m...@bitchin100.com
Subject: Re: [M100] Model T Terminal

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

it is 80x24.  I don't think any M100 applications use 80x25 at all actually. 
Does anything use DVI?

Re: [M100] Model T Terminal

[Jim Anderson]

Question for you: is it going to be 80x24, or 80x25, or user-selectable?  I 
know the DVI was 80x25 and applications in the M100 environment are probably 
going to expect that, whereas CP/M applications expecting a VT100 are mostly 
going to be expecting 80x24 (some allow you to configure the screen size, some 
don’t)…







jim

From: M100 [mailto:m100-boun...@lists.bitchin100.com] On Behalf Of Stephen 
Adolph
Sent: Tuesday, July 28, 2020 3:20 PM
To: m...@bitchin100.com
Subject: Re: [M100] Model T Terminal

CAUTION External Sender: Do not click links or open attachments unless you 
recognize the sender and know the content is safe.

It is going.  Thanks for asking.

I have tested the pcb and it seems ok.
I have some parts now.
I have some bugs to fix with the firmware for the video adapter tho.

There's always bugs.  I was thinking that anyone who got one would eventually 
need to learn how to upgrade the firmware on their own... so no reason not to 
get it out there.




On Tuesday, July 28, 2020, dano none 
mailto:daneiche...@hotmail.com>> wrote:
Hi Steve,
 For those of us playing from home, how goes work on the Model T Terminal 
Adapter, the last I remember reading on the list was you were having problems 
with the loader?
Thanks,
Dano