I recently bought an SC114 SBC (RC2014), which is a great little
computer and fits my needs perfectly, mostly testing the T3X backend
for the Z80 a real CP/M system. Thanks to Derek, whom I have seen
posting here, for selling me a completely assembled kit.

There is one thing that gives me some headache, though. I cannot seem
to get serial communication, especially the on-board port, to work
properly.

My SC114 has a SC139 68B50 ACIA in addition to the on-board port
and a CF adapter from which it runs CP/M. The ACIA is connected via
the adapter that came with the computer and the on-board port is
hooked up with a three-wire connection. Both use FTDI adapters of
the kind that came with the SC114.

I can connect to the SCM console on the SC114 using either port,
both work fine. CP/M seems to want the ACIA as its console, which
is also OK. As soon as I try to do other things with the serial
ports, things get a bit weird, though. I am sure I am missing
something here, so maybe someone can help.

(1) I cannot get xmodem uploads to work with cu and lrzsz.

The machine I use for connecting to CP/M is a FreeBSD machine, so
I use "cu -l cuaU0 -115200" to connect. So far so good. When I start
an xmodem session using "~C sx -q file" and "xmodem file /r /x0 /q" on
CP/M, I get a NAK on every sector. I have set up the port for 8N1
and rts/cts. Now here are the weird things:

- The same sx command works for uploading files to my NC100, which
also needs hardware flow control.

- The same sx command works on the SC114 when using minicom instead
of cu.

However, I really prefer cu, because it is basically a command line
tool, so if anybody has an idea about what is going wrong, I would
be most grateful.

(2) The other thing: as far as I understand it, CP/M should provide
the on-board serial port as the TTY: device. STAT DEV: shows

CON: is CRT:
RDR: is TTY:
PUN: is TTY:
LST: is TTY:

Ok, so the first thing I tried is to connect another cu to the cuaU1,
which is connected to the on-board port (cu -l cuaU1 -9600), and run

PIP PUN:=CON:

which, if I remember correctly. should echo console input on the
serial port. I does echo input on the console, though, and nothing
appears on the other port.

Next thing I tried was STAT CON:=TTY:. Ok, now CON: is assigned to
TTY:, but the console is still connected to the same port. Looks like
CRT: and TTY: are really both the ACIA port. Can someone confirm? If
so, can this be changed?

Xmodem transfers on PUN: and RDR: simply time out, which would make
sense, because there is no connection to the on-board port.

This is how far I got. Any help would be much appreciated!

Nils

--
Nils M Holm < n m h @ t 3 x . o r g > http://t3x.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, October 28, 2023 at 12:43:29 PM UTC-4, Nils M Holm wrote:

I recently bought an SC114 SBC (RC2014), which is a great little
computer and fits my needs perfectly, mostly testing the T3X backend
for the Z80 a real CP/M system. Thanks to Derek, whom I have seen
posting here, for selling me a completely assembled kit.

There is one thing that gives me some headache, though. I cannot seem
to get serial communication, especially the on-board port, to work
properly.

My SC114 has a SC139 68B50 ACIA in addition to the on-board port
and a CF adapter from which it runs CP/M. The ACIA is connected via
the adapter that came with the computer and the on-board port is
hooked up with a three-wire connection. Both use FTDI adapters of
the kind that came with the SC114.

I can connect to the SCM console on the SC114 using either port,
both work fine. CP/M seems to want the ACIA as its console, which
is also OK. As soon as I try to do other things with the serial
ports, things get a bit weird, though. I am sure I am missing
something here, so maybe someone can help.

(1) I cannot get xmodem uploads to work with cu and lrzsz.

The machine I use for connecting to CP/M is a FreeBSD machine, so
I use "cu -l cuaU0 -115200" to connect. So far so good. When I start
an xmodem session using "~C sx -q file" and "xmodem file /r /x0 /q" on
CP/M, I get a NAK on every sector. I have set up the port for 8N1
and rts/cts. Now here are the weird things:

- The same sx command works for uploading files to my NC100, which
also needs hardware flow control.

- The same sx command works on the SC114 when using minicom instead
of cu.

However, I really prefer cu, because it is basically a command line
tool, so if anybody has an idea about what is going wrong, I would
be most grateful.

(2) The other thing: as far as I understand it, CP/M should provide
the on-board serial port as the TTY: device. STAT DEV: shows

CON: is CRT:
RDR: is TTY:
PUN: is TTY:
LST: is TTY:

Ok, so the first thing I tried is to connect another cu to the cuaU1,
which is connected to the on-board port (cu -l cuaU1 -9600), and run

PIP PUN:=CON:

which, if I remember correctly. should echo console input on the
serial port. I does echo input on the console, though, and nothing
appears on the other port.

Next thing I tried was STAT CON:=TTY:. Ok, now CON: is assigned to
TTY:, but the console is still connected to the same port. Looks like
CRT: and TTY: are really both the ACIA port. Can someone confirm? If
so, can this be changed?

Xmodem transfers on PUN: and RDR: simply time out, which would make
sense, because there is no connection to the on-board port.

This is how far I got. Any help would be much appreciated!

Nils

--
Nils M Holm < n m h @ t 3 x . o r g > http://t3x.org

Nils

/X0 means use CON: -- yes. But, here is the thing CON: on CP/M 2.2 is 7 bit, not 8 bit. Do you have a utility that switches CON to 8 bit? Next device assignment and the IOBYTE in CP/M 2.2 is up to the BIOS. It is likely not rx, etc. but the BIOS on the
CP/M side. Now, xmodem only sends 128 + a couple of bytes as a packet, in a very tight loop. It then waits for ACK/NAK. Which means that flow control is normally not needed. I wouldn't go to 115200... I usually stick to 38400 as a max (which is as fast
as an Altair or IBM SSSD floppy disk was).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, 28 October 2023 at 19:34:32 UTC+1, fridtjof.ma...@gmail.com wrote:

On Saturday, October 28, 2023 at 12:43:29 PM UTC-4, Nils M Holm wrote:

I recently bought an SC114 SBC (RC2014), which is a great little
computer and fits my needs perfectly, mostly testing the T3X backend
for the Z80 a real CP/M system. Thanks to Derek, whom I have seen
posting here, for selling me a completely assembled kit.

There is one thing that gives me some headache, though. I cannot seem
to get serial communication, especially the on-board port, to work properly.

My SC114 has a SC139 68B50 ACIA in addition to the on-board port
and a CF adapter from which it runs CP/M. The ACIA is connected via
the adapter that came with the computer and the on-board port is
hooked up with a three-wire connection. Both use FTDI adapters of
the kind that came with the SC114.

I can connect to the SCM console on the SC114 using either port,
both work fine. CP/M seems to want the ACIA as its console, which
is also OK. As soon as I try to do other things with the serial
ports, things get a bit weird, though. I am sure I am missing
something here, so maybe someone can help.

(1) I cannot get xmodem uploads to work with cu and lrzsz.

The machine I use for connecting to CP/M is a FreeBSD machine, so
I use "cu -l cuaU0 -115200" to connect. So far so good. When I start
an xmodem session using "~C sx -q file" and "xmodem file /r /x0 /q" on CP/M, I get a NAK on every sector. I have set up the port for 8N1
and rts/cts. Now here are the weird things:

- The same sx command works for uploading files to my NC100, which
also needs hardware flow control.

- The same sx command works on the SC114 when using minicom instead
of cu.

However, I really prefer cu, because it is basically a command line
tool, so if anybody has an idea about what is going wrong, I would
be most grateful.

(2) The other thing: as far as I understand it, CP/M should provide
the on-board serial port as the TTY: device. STAT DEV: shows

CON: is CRT:
RDR: is TTY:
PUN: is TTY:
LST: is TTY:

Ok, so the first thing I tried is to connect another cu to the cuaU1, which is connected to the on-board port (cu -l cuaU1 -9600), and run

PIP PUN:=CON:

which, if I remember correctly. should echo console input on the
serial port. I does echo input on the console, though, and nothing
appears on the other port.

Next thing I tried was STAT CON:=TTY:. Ok, now CON: is assigned to
TTY:, but the console is still connected to the same port. Looks like
CRT: and TTY: are really both the ACIA port. Can someone confirm? If
so, can this be changed?

Xmodem transfers on PUN: and RDR: simply time out, which would make
sense, because there is no connection to the on-board port.

This is how far I got. Any help would be much appreciated!

Nils

--
Nils M Holm < n m h @ t 3 x . o r g > http://t3x.org

Nils

/X0 means use CON: -- yes. But, here is the thing CON: on CP/M 2.2 is 7 bit, not 8 bit. Do you have a utility that switches CON to 8 bit? Next device assignment and the IOBYTE in CP/M 2.2 is up to the BIOS. It is likely not rx, etc. but the BIOS on the

CP/M side. Now, xmodem only sends 128 + a couple of bytes as a packet, in a very tight loop. It then waits for ACK/NAK. Which means that flow control is normally not needed. I wouldn't go to 115200... I usually stick to 38400 as a max (which is as fast
as an Altair or IBM SSSD floppy disk was).

When you connect using CU open another terminal on you bsd box and run stty -a -F /dev/ttyS0 to find out what CU as set the port to do - does it have -crtscts -cdtrdsr or crtscts cdtrdsr (your serial port is probably not ttyS0, bsd i think uses cu.
usbxxxxxxx)

There is a lot of confusion for dtr and cts. so you may need to pretend it's reversed. ie DTE to DCD and not DCD to DTE.

The bit bang port is very simple, no interrupts on receive etc so it "stops" all other functions while it waits for data. Not something you want. It cuases all sorts of problems. For example is you try and run Turbo Pascal using the 9600 port. You can
not do ^KD to exit the editor, it times out the ^K before the D can be pressed. But it works fine on the ACIA port.

I know also that the console may not switch functions when the ACIA port is in use so both 9600 port and ACIA end up the same. You would need to start hacking about in the CBIOS to get this to work as expected.

Derek

A lot of trial and error needed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, 28 October 2023 at 19:49:20 UTC+1, Derek Cooper wrote:

On Saturday, 28 October 2023 at 19:34:32 UTC+1, fridtjof.ma...@gmail.com wrote:

On Saturday, October 28, 2023 at 12:43:29 PM UTC-4, Nils M Holm wrote:

I recently bought an SC114 SBC (RC2014), which is a great little computer and fits my needs perfectly, mostly testing the T3X backend
for the Z80 a real CP/M system. Thanks to Derek, whom I have seen posting here, for selling me a completely assembled kit.

There is one thing that gives me some headache, though. I cannot seem
to get serial communication, especially the on-board port, to work properly.

My SC114 has a SC139 68B50 ACIA in addition to the on-board port
and a CF adapter from which it runs CP/M. The ACIA is connected via
the adapter that came with the computer and the on-board port is
hooked up with a three-wire connection. Both use FTDI adapters of
the kind that came with the SC114.

I can connect to the SCM console on the SC114 using either port,
both work fine. CP/M seems to want the ACIA as its console, which
is also OK. As soon as I try to do other things with the serial
ports, things get a bit weird, though. I am sure I am missing
something here, so maybe someone can help.

(1) I cannot get xmodem uploads to work with cu and lrzsz.

The machine I use for connecting to CP/M is a FreeBSD machine, so
I use "cu -l cuaU0 -115200" to connect. So far so good. When I start
an xmodem session using "~C sx -q file" and "xmodem file /r /x0 /q" on CP/M, I get a NAK on every sector. I have set up the port for 8N1
and rts/cts. Now here are the weird things:

- The same sx command works for uploading files to my NC100, which
also needs hardware flow control.

- The same sx command works on the SC114 when using minicom instead
of cu.

However, I really prefer cu, because it is basically a command line tool, so if anybody has an idea about what is going wrong, I would
be most grateful.

(2) The other thing: as far as I understand it, CP/M should provide
the on-board serial port as the TTY: device. STAT DEV: shows

CON: is CRT:
RDR: is TTY:
PUN: is TTY:
LST: is TTY:

Ok, so the first thing I tried is to connect another cu to the cuaU1, which is connected to the on-board port (cu -l cuaU1 -9600), and run

PIP PUN:=CON:

which, if I remember correctly. should echo console input on the
serial port. I does echo input on the console, though, and nothing appears on the other port.

Next thing I tried was STAT CON:=TTY:. Ok, now CON: is assigned to
TTY:, but the console is still connected to the same port. Looks like CRT: and TTY: are really both the ACIA port. Can someone confirm? If
so, can this be changed?

Xmodem transfers on PUN: and RDR: simply time out, which would make sense, because there is no connection to the on-board port.

This is how far I got. Any help would be much appreciated!

Nils

--
Nils M Holm < n m h @ t 3 x . o r g > http://t3x.org

Nils

/X0 means use CON: -- yes. But, here is the thing CON: on CP/M 2.2 is 7 bit, not 8 bit. Do you have a utility that switches CON to 8 bit? Next device assignment and the IOBYTE in CP/M 2.2 is up to the BIOS. It is likely not rx, etc. but the BIOS on

the CP/M side. Now, xmodem only sends 128 + a couple of bytes as a packet, in a very tight loop. It then waits for ACK/NAK. Which means that flow control is normally not needed. I wouldn't go to 115200... I usually stick to 38400 as a max (which is as
fast as an Altair or IBM SSSD floppy disk was).

When you connect using CU open another terminal on you bsd box and run stty -a -F /dev/ttyS0 to find out what CU as set the port to do - does it have -crtscts -cdtrdsr or crtscts cdtrdsr (your serial port is probably not ttyS0, bsd i think uses cu.

usbxxxxxxx)

There is a lot of confusion for dtr and cts. so you may need to pretend it's reversed. ie DTE to DCD and not DCD to DTE.

The bit bang port is very simple, no interrupts on receive etc so it "stops" all other functions while it waits for data. Not something you want. It cuases all sorts of problems. For example is you try and run Turbo Pascal using the 9600 port. You can

not do ^KD to exit the editor, it times out the ^K before the D can be pressed. But it works fine on the ACIA port.

I know also that the console may not switch functions when the ACIA port is in use so both 9600 port and ACIA end up the same. You would need to start hacking about in the CBIOS to get this to work as expected.

Derek

A lot of trial and error needed.

I forgot to say, the bit-bang serial port, with the standard CP/M does not work with xmodem. See:

https://groups.google.com/g/retro-comp/c/Vlix-_HGzQc/m/pno-cFxgAQAJ

If you want a pre-patched version of putsys_cpm_128k let me know and i'll post it here for you.

Derek

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, 28 October 2023 at 19:34:32 UTC+1, fridtjof.ma...@gmail.com wrote:

/X0 means use CON: -- yes. But, here is the thing CON: on CP/M
2.2 is 7 bit, not 8 bit. Do you have a utility that switches CON
to 8 bit? [...]

It appears that the SC114 CPM console operates in 8-bit mode, since
the TTY is configured for 8N1. It also works with xmodem now, see below.

Derek Cooper <derek.cooper.phone@gmail.com> wrote:

When you connect using CU open another terminal on you bsd box
and run stty -a -F /dev/ttyS0 to find out what CU as set the port
to do - does it have -crtscts -cdtrdsr or crtscts cdtrdsr (your
serial port is probably not ttyS0, bsd i think uses cu.usbxxxxxxx)

Testing with stty indeed did the trick! I had configured /dev/cuaU0
to use rts/cts (crtscts) before starting cu and also checked after
starting cu. However, when cu forks a child process to run sx it
seems to clear crtscts. So I wrote a little script that sets crtscts
again before running sx and now it works flawlessly.

Thanks for pointing me in the right direction!

The bit bang port is very simple, no interrupts on receive etc
so it "stops" all other functions while it waits for data. Not
something you want. It cuases all sorts of problems. For example
is you try and run Turbo Pascal using the 9600 port. You can not
do ^KD to exit the editor, it times out the ^K before the D can be
pressed. But it works fine on the ACIA port.

I see. Does your patch fix this issue too?

I know also that the console may not switch functions when the
ACIA port is in use so both 9600 port and ACIA end up the same. You
would need to start hacking about in the CBIOS to get this to work
as expected.

So if I (hypothetically) wanted to use the bitbang port as the CP/M
console, I would have to disable the ACIA? Not going actually to do
this. I might hack the BIOS at some point, though, to get PUN: and RDR:
up and running. Where do I get the sources and necessary tools to set up
a new system?

If you want a pre-patched version of putsys_cpm_128k let me know
and i'll post it here for you.

That would be great!

BTW, this is the first post I am seeing from you (via indivual.net
NNTP), but I see other posts of you and Fridtjof on Google groups.
Strange, but I will look out there in case I do not see anything here.

Nils

--
Nils M Holm < n m h @ t 3 x . o r g > http://t3x.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, 29 October 2023 at 09:03:58 UTC, Nils M Holm wrote:

On Saturday, 28 October 2023 at 19:34:32 UTC+1, fridtjof.ma...@gmail.com wrote:

/X0 means use CON: -- yes. But, here is the thing CON: on CP/M
2.2 is 7 bit, not 8 bit. Do you have a utility that switches CON
to 8 bit? [...]

It appears that the SC114 CPM console operates in 8-bit mode, since
the TTY is configured for 8N1. It also works with xmodem now, see below. Derek Cooper <derek.coo...@gmail.com> wrote:

When you connect using CU open another terminal on you bsd box
and run stty -a -F /dev/ttyS0 to find out what CU as set the port
to do - does it have -crtscts -cdtrdsr or crtscts cdtrdsr (your
serial port is probably not ttyS0, bsd i think uses cu.usbxxxxxxx)

Testing with stty indeed did the trick! I had configured /dev/cuaU0
to use rts/cts (crtscts) before starting cu and also checked after
starting cu. However, when cu forks a child process to run sx it
seems to clear crtscts. So I wrote a little script that sets crtscts
again before running sx and now it works flawlessly.

Thanks for pointing me in the right direction!

The bit bang port is very simple, no interrupts on receive etc
so it "stops" all other functions while it waits for data. Not
something you want. It cuases all sorts of problems. For example
is you try and run Turbo Pascal using the 9600 port. You can not
do ^KD to exit the editor, it times out the ^K before the D can be
pressed. But it works fine on the ACIA port.

I see. Does your patch fix this issue too?

I know also that the console may not switch functions when the
ACIA port is in use so both 9600 port and ACIA end up the same. You
would need to start hacking about in the CBIOS to get this to work
as expected.

So if I (hypothetically) wanted to use the bitbang port as the CP/M
console, I would have to disable the ACIA? Not going actually to do
this. I might hack the BIOS at some point, though, to get PUN: and RDR:
up and running. Where do I get the sources and necessary tools to set up
a new system?

If you want a pre-patched version of putsys_cpm_128k let me know
and i'll post it here for you.

That would be great!

BTW, this is the first post I am seeing from you (via indivual.net
NNTP), but I see other posts of you and Fridtjof on Google groups.
Strange, but I will look out there in case I do not see anything here.
Nils

--
Nils M Holm < n m h @ t 3 x . o r g > http://t3x.org

Here is the version with my fixes for the bit-bang-9600. it allows for xmodem over the port.

https://drive.google.com/file/d/148Souv_dQQKMwJQs2gK_7W8DlpUGQM1X/view?usp=drive_link

Before you use it, make sure you get a copy of the original from smallcomputercentral (steve's website).

Reset to the * prompt
send the file or past it as ascii to the console. It should come back to a * without error.
type: G 8000
that will write it to the cf-card. then boot with cpm.


It only address's the bit-bang port xmodem problem.

the smallcomputercentral web site has a section called SMALL COMPUTER WORKSHOP, this is the workbench used to build the various tools like the SCM Rom, CPM etc.

Derek

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Derek Cooper <derek.cooper.phone@gmail.com> wrote:

Here is the version with my fixes for the bit-bang-9600. it allows
for xmodem over the port.

https://drive.google.com/file/d/148Souv_dQQKMwJQs2gK_7W8DlpUGQM1X/view?usp=drive_link

Thank you!

Before you use it, make sure you get a copy of the original from smallcomputercentral (steve's website).

Will do.

the smallcomputercentral web site has a section called SMALL
COMPUTER WORKSHOP, this is the workbench used to build the various
tools like the SCM Rom, CPM etc.

Oh, Windows-only, I guess I am out of luck then. Never owned a
Windows machine in my entire life.

--
Nils M Holm < n m h @ t 3 x . o r g > http://t3x.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, 29 October 2023 at 17:06:19 UTC, Nils M Holm wrote:

Derek Cooper <derek.coo...@gmail.com> wrote:

Here is the version with my fixes for the bit-bang-9600. it allows
for xmodem over the port.

https://drive.google.com/file/d/148Souv_dQQKMwJQs2gK_7W8DlpUGQM1X/view?usp=drive_link

Thank you!

Before you use it, make sure you get a copy of the original from smallcomputercentral (steve's website).

Will do.

the smallcomputercentral web site has a section called SMALL
COMPUTER WORKSHOP, this is the workbench used to build the various
tools like the SCM Rom, CPM etc.

Oh, Windows-only, I guess I am out of luck then. Never owned a
Windows machine in my entire life.
--
Nils M Holm < n m h @ t 3 x . o r g > http://t3x.org

I think you can compile the source with a cross compiler. I just built a windows VM on my linux box to run it. Then turn it off fast!

Derek

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)