Way back in 2021, Tom Hoppe said:
Well, good news. If you set M100 CPM to 'Sc S' and 'Cu S' it works much better. I still found an issue playing Zork III where it says
"-----more-----" then stopped responding, requiring me to press enter on the M100.stat con:=uc1: <-- Redirect CP/M output to serial
portstat con:=tty: <-- Change it back to M100 native display (type this from terminal program on PC)I am using Minicom 2.7.1 on Linux (VT102
emulator with 19200 N81). I left it on overnight and it is still working this morning. TomOn Tue, Nov 16, 2021 at 2:55 PM Tom Hoppe <tjhoppe at
gmail.com <http://lists.bitchin100.com/listinfo.cgi/m100-bitchin100.com>> wrote:Correct, VT100 emulation.On Tue, Nov 16, 2021 at 2:15 PM
Stephen Adolph <twospruces at gmail.com <http://lists.bitchin100.com/listinfo.cgi/m100-bitchin100.com>> wrote:there will be escape
characters flowing over serial in this case, so you need to ensure that does not mess with things.If I understand what is happeningM100 ----> PC
(video terminal character flow)M100 <---- PC (input keyboard strokes)When you say the terminal works reliably using F3, you are using the PC as
a display for CP/M, right? And in this case, you selected VT100 emulation?On Tue, Nov 16, 2021 at 5:05 PM Tom Hoppe <tjhoppe at gmail.com
<http://lists.bitchin100.com/listinfo.cgi/m100-bitchin100.com>> wrote:I left minicom set to 19200 8N1 and it worked (until it didn't). The
Sc L vs Sc S is a good point! I will try changing this tonight and see if it helps. My ultimate goal is to ssh into my home PC from work so I can
play with CP/M during lunch :).TomOn Tue, Nov 16, 2021 at 11:21 AM Jim Anderson <jim.anderson at kpu.ca
<http://lists.bitchin100.com/listinfo.cgi/m100-bitchin100.com>> wrote:
Here's what I did that didn't work:
1. Fire up M100
2. CTL-C to get into CP/M
3. Change Sc to S and Cu to S (tried with M100 on F3, tried with RS23)
4. in CP/M, type stat con:=uc1:
5. in Linux, type minicom (/dev/ttyUSB0, VT102, 19200 8N1)
I don't get input or output at the linux side of things and on the m100,
it isn't responsive after doing stat, cuz it's waiting for serial
in/out, right?
What'd I do wrong? Is additional setup on the M100 required or some
setting in minicom (it claims to be offline in the status bar).
Also, what does this mean:
/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)/
Is this the same F3 from CP/M to go between (M100, RS23, or CASS) or is
it something else, if it's the same which one is the right one. If it's
different, where is it and what to set it to.
Thanks,
Will
On 3/20/24 8:53 PM, Philip Avery wrote:
Yes, the IO byte is fully implemented in M100 CP/M. Use 'stat
con:=uc1:'for serial port input. Currently no way of altering baud
rate, on the to-do list.
Search out this old thread:
[M100] Re-directing CP/M console to serial port in REXCPM
Philip
On 21/03/2024 12:02 pm, Will Senn wrote:
over on Vcf, I asked about whether serial over console was possible
and they said:
CP/M is basically indifferent about the details of the console,
that being contained within the BIOS created by the vendor for
the platform you're running on. I'm not familiar with the M100
platform, but if it has a serial port, *AND* the vendor
implemented CP/M "I/O redirection" in their BIOS, then you can
use STAT to re-assign the console to a serial port. You have to
determine which of the devices is the serial port, but then you'd
issue a command like "STAT CON:=TTY:" after which you should see
the "A>" prompt on the serial port. Note that if you reassign the
console to the wrong device, you won't be able to issue the
command to return to the original console device (e.g. "STAT
CON:=CRT:"), and will probably have to RESET and reboot. Read up
on the STAT command, as it can show you the available device
assignments, current assignments, etc.
Which kinda makes sense, but what is the serial port called? CON is
already TTY, so that's not it. Also, how do I set the baud rate and
suchlike in CP/M... anyway, " it has a serial port, *AND* the vendor
implemented CP/M "I/O redirection" in their BIOS"... does anyone know
if this is the case?
Thanks,
Will
