Using ROMWBW and CP/M with second serial port as printer?

[Richard Deane]

I'm trying to use CP/M (or Z/System) under RC2014 with ROMWBW to use second SIO port as a serial printer port but am stuck trying to use STAT commands to assign the serial port to LST:

I assumed that it might be something like STAT LST:=SIO1: but it doesn't like SIO1 as a value.

STAT shows:

B>stat val:

Temp R/O Disk: d:=R/O

Set Indicator: d:filename.typ $R/O $R/W $SYS $DIR

Disk Status  : DSK: d:DSK:

User Status  : USR:

Iobyte Assign:

CON: = TTY: CRT: BAT: UC1:

RDR: = TTY: PTR: UR1: UR2:

PUN: = TTY: PTP: UP1: UP2:

LST: = TTY: CRT: LPT: UL1:

B>

if the device names on stat val for LST: are correct then what makes the mapping from say SIO1 to UL1?

Any help greatly appreciated

Richard

[CubeCentral]

Richard,

 

On my RomWBW board, there aren’t a second row of headers connected to the “Enhanced Bus”.  Looking at the diagram of the SIO/2 board, you can see that TXB and RXB are hooked into pins 19 and 20 respectively on the “Enhanced Bus”.  Unless I am missing something – and there is a good chance I am – the RomWBW board has no knowledge of the second SIO port.  There isn’t a physical connection.

 

    -Randal   (at CubeCentral)

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/7bc514cf-f31a-4eec-ad60-5d09b2e8e69f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Cube Central]

Additionally, (sorry for the extra post):  On a "Vanilla" RC2014 system, some time ago, after a little tinkering, I managed to get an old serial printer hooked up to the second serial port on the SIO/2 and was able to print to it via PIP LST:=FILE.TXT

Thus encouraged, I was also able to transfer files to the system from another terminal by using PIP INCOMING.TXT=RDR:  ... It had been so long since I had done anything like that in CP/M I was quite pleased that it worked.  But this was on a system that is taking advantage of the Enhanced Bus extra pins.

[Jon Langseth]

As I don't have an RC2014 set up with official modules for neither CP/M or RomWBW, I can't give you a definite answer, but I can provide some tips. 

The first tip is that CP/M has a series of fixed device names, with their function defined by the IOBYTE as described at http://www.seasip.info/Cpm/iobyte.html

The second tip is that generally, the BIOS versions used on "standard" RC2014 and RomWBW seem to have the same base foundation, and typically use the CP/M CRT: and TTY: device names for serial ports of SIO/2.

So what makes the mapping of CRT: and TTY: is not shown in your "STAT VAL:" output, those are determined by the BIOS. But what gets assigned to the CON:, RDR:, PUN: and LST: device names can be read by using the "STAT DEV:" command, and set using the STAT command as described on http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch1.htm#Section_1.6.1

[Wayne Warthen]

I can try to clarify some of this with respect to RomWBW.

First, RomWBW definitely does recognize and fully support the second SIO port.  As mentioned, the RC2014 bus only supports a single serial port (one set of RX/TX lines).  However, the second SIO port on the SIO module can be connected directly via the second TTL output connector.  RomWBW has no idea how (or if) the second port is connected to the outside world.

Jon is exactly right in his description of how CP/M 2 deals with multiple devices.  There is a fixed set of devices available.  However, in addition to the ones Jon mentions, there is also the UC1 device (User Console 1).  If there is a second serial port on the system (such as the second SIO port), then RomWBW will map it to UC1.  As such, you can dynamically switch to that port with the command "STAT CON:=UC1:".  I am pretty sure I tested this when I added the SIO module support, but that was a while ago.  FYI, I do not use the CRT: device for serial ports -- I reserve that device to address "real" onboard video controller hardware.  Such hardware is not common yet on RC2014's, but I think I saw some posts that someone is working on such a thing.  Assuming there is no real video controller in the system, then any attempt to read/write CRT: will just be directed to the first serial port.

Finally, with respect to LST:, RomWBW reserves that device for a parallel printer port.  However, this work has never been completed and references to LST: will just go to the console.

Hope this helps!

-Wayne

[Cube Central]

Wayne, 

Thank you for your clarification, I stand corrected.  I'm not sure what I was thinking, but it certainly wasn't correct.

Trying a few things here, I found that:

B>STAT VAL:

Temp R/O Disk: d:=R/O

Set Indicator: d:filename.typ $R/O $R/W $SYS $DIR

Disk Status  : DSK: d:DSK:

User Status  : USR:

Iobyte Assign:

CON: = TTY: CRT: BAT: UC1:

RDR: = TTY: PTR: UR1: UR2:

PUN: = TTY: PTP: UP1: UP2:

LST: = TTY: CRT: LPT: UL1:

B>STAT DEV:

CON: is TTY:

RDR: is TTY:

PUN: is TTY:

LST: is TTY:

B>STAT LST:=UC1:

Invalid Assignment

B>STAT PUN:=UC1:

Invalid Assignment

B>STAT RDR:=UC1:

Invalid Assignment

B>STAT CON:=UC1:

In fact switched the console to the 2nd SIO/2 port and I was able to connect and switch it back:

B>STAT CON:=TTY:

Unable to get the STAT to use any of the above, I tried:

B>pip UC1:=FILENAME.TXT

...which worked, and "printed" that file out the 2nd serial port.  This was on a very basic system with the RomWBW board, SIO/2, Clock, CPU, IDE, and CF modules.

I might not be understanding completely the mapping, or what STAT is looking for in the way of ports or names.  Perhaps this is what Richard was speaking about in his original post?

    -Randal   (at CubeCentral)

[Wayne Warthen]

Trying a few things here, I found that:

B>STAT VAL:

Temp R/O Disk: d:=R/O

Set Indicator: d:filename.typ $R/O $R/W $SYS $DIR

Disk Status  : DSK: d:DSK:

User Status  : USR:

Iobyte Assign:

CON: = TTY: CRT: BAT: UC1:

RDR: = TTY: PTR: UR1: UR2:

PUN: = TTY: PTP: UP1: UP2:

LST: = TTY: CRT: LPT: UL1:

The last four lines above are indicating the device assignments you can perform.  For example, the CON: line is indicating that CON: can be assigned to TTY:, CRT:, BAT:, or UC1:

B>STAT DEV:

CON: is TTY:

RDR: is TTY:

PUN: is TTY:

LST: is TTY:

The lines above are showing you the current assignments.  By default everything is assigned to the TTY port (which is the first SIO port in your case).

 

B>STAT LST:=UC1:

Invalid Assignment

B>STAT PUN:=UC1:

Invalid Assignment

B>STAT RDR:=UC1:

Invalid Assignment

None of the above assignments are allowed as indicated in the four last lines of the "STAT VAL:" command.

 

B>STAT CON:=UC1:

In fact switched the console to the 2nd SIO/2 port and I was able to connect and switch it back:

B>STAT CON:=TTY:

Yes, these are the correct commands to switch to and back from the second SIO port!  Glad to hear it is working.

 

Unable to get the STAT to use any of the above, I tried:

B>pip UC1:=FILENAME.TXT

...which worked, and "printed" that file out the 2nd serial port.  This was on a very basic system with the RomWBW board, SIO/2, Clock, CPU, IDE, and CF modules.

I might not be understanding completely the mapping, or what STAT is looking for in the way of ports or names.  Perhaps this is what Richard was speaking about in his original post?

You might want to review the CP/M Manual regarding devices and device assignments.

Thanks,

Wayne 

[Richard Deane]

Thank you for all your answers 

I am now able to do PIP UC1:=TEXTFILE successfully.

It would be good  to be able to use LST: (and PUN, RDR) with SIO so that programs like Wordstar can be configured to print; however I shall experiment more.

I have noticed that SIO port B defaults to 57600 baud; however the romwbw mode command always displays 115200 as the baud rate.

Also using mode to set baud rate has no effect, it stays at 57600 while the mode command shows 115200 rather than the attempted baud rate.

Tested on CP/M and ZSDOS.

Richard

[Richard Deane]

I note that on RC2014 standard grant-searle cp/m as supplied by Spencer that I can do

stat lst:=uc1:

pip lst:=hello.txt

which means that apps could be configured for LST: and print ok.

Richard

On Monday, 30 April 2018 23:02:09 UTC+1, Richard Deane wrote:

[Spencer Owen]

On 30 April 2018 at 23:35, CubeCentral <cubec...@gmail.com> wrote:

On my RomWBW board, there aren’t a second row of headers connected to the “Enhanced Bus”.  Looking at the diagram of the SIO/2 board, you can see that TXB and RXB are hooked into pins 19 and 20 respectively on the “Enhanced Bus”.  Unless I am missing something – and there is a good chance I am – the RomWBW board has no knowledge of the second SIO port.  There isn’t a physical connection.

There seems to be a bit of confusion on the hardware here.  The 512k ROM 512k RAM (RomWBW) Module doesn't connect to the 2nd serial port, or even the 1st serial port.  It connects to the SIO/2 chip via the address and data bus, and it is the SIO/2 that provides the two serial ports.  The TXB and RXB on the enhanced bus are just a duplicate of the signals going to the Port B 6 pin header on the SIO/2 Module so that you can use Port B either via the 6 pin header or, with something like the ESP8266 Module, via the backplane.

Hope that helps

Spencer

[CubeCentral]

Richard,

 

When I was testing “printing” last night, my SIO port B runs at 115200 baud.  Could it be a jumper setting on your SIO/2 board that is set at something other than the left-most position?  I have the RomWBW v2.9.1 Prerelease 1 running on mine and both Serial board jumpers set to 7.3728MHz.

 

                -Randal   (at CubeCentral)

 

From: rc201...@googlegroups.com [mailto:rc201...@googlegroups.com] On Behalf Of Richard Deane
Sent: Tuesday, May 1, 2018 02:09
To: RC2014-Z80 <rc201...@googlegroups.com>

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/9bb8b474-458f-4011-b870-15c2bcbdf1e2%40googlegroups.com.

[Wayne Warthen]

On Tue, May 1, 2018 at 2:01 AM Richard Deane <rwd...@gmail.com> wrote:

I note that on RC2014 standard grant-searle cp/m as supplied by Spencer that I can do

stat lst:=uc1:

pip lst:=hello.txt

which means that apps could be configured for LST: and print ok.

Richard

These commands should work the same way on RomWBW.  Are you saying you have tried and it doesn't work?

-Wayne

[CubeCentral]

Hi Wayne,

In my previous e-mail, I pointed out that:

B>STAT LST:=UC1:

Invalid Assignment

 

And you had replied that it wasn’t a valid option indicated by:

B>STAT VAL:

Temp R/O Disk: d:=R/O

Set Indicator: d:filename.typ $R/O $R/W $SYS $DIR

Disk Status  : DSK: d:DSK:

User Status  : USR:

Iobyte Assign:

CON: = TTY: CRT: BAT: UC1:

RDR: = TTY: PTR: UR1: UR2:

PUN: = TTY: PTP: UP1: UP2:

LST: = TTY: CRT: LPT: UL1:

 

“The last four lines above are indicating the device assignments you can perform”

 

So this is in reference to a RC2014 system running the 512K RAM/ROM RomWBW board, and not a vanilla system where this command works.

 

                -Randal   (at CubeCentral)

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CADQpb5O0RFp5Kb40yQQNXQG7RqWa_B2k71PEZ63MO5A6BKEteQ%40mail.gmail.com.

[Wayne Warthen]

I have noticed that SIO port B defaults to 57600 baud; however the romwbw mode command always displays 115200 as the baud rate.

Also using mode to set baud rate has no effect, it stays at 57600 while the mode command shows 115200 rather than the attempted baud rate.

The baud rate on the SIO module is determined solely by your hardware configuration.  CP/M is unable to tell what the current baud rate is or modify it.  As a result, RomWBW assumes the baud rate is 115200 (which is the most common config) and any attempt to modify it is ignored.  RomWBW supports a wide variety of hardware -- the MODE command works fine on any hardware that supports on-the-fly baud rate changes.

I guess it would be better if any attempt to modify the baud rate using the MODE command with the SIO module resulted in a friendly error message.

[Wayne Warthen]

On Tuesday, May 1, 2018 at 7:44:06 AM UTC-7, Cube Central wrote:

Hi Wayne,

In my previous e-mail, I pointed out that:

B>STAT LST:=UC1:

Invalid Assignment

 

And you had replied that it wasn’t a valid option indicated by:

B>STAT VAL:

Temp R/O Disk: d:=R/O

Set Indicator: d:filename.typ $R/O $R/W $SYS $DIR

Disk Status  : DSK: d:DSK:

User Status  : USR:

Iobyte Assign:

CON: = TTY: CRT: BAT: UC1:

RDR: = TTY: PTR: UR1: UR2:

PUN: = TTY: PTP: UP1: UP2:

LST: = TTY: CRT: LPT: UL1:

 

“The last four lines above are indicating the device assignments you can perform”

 

So this is in reference to a RC2014 system running the 512K RAM/ROM RomWBW board, and not a vanilla system where this command works.

 

                -Randal   (at CubeCentral)

Sorry Randal, you are right.  UC1: is not a valid assignment for LST:. As far as I know the STAT command itself would not allow such this assignment unless the STAT command itself was modified.

So... the real question is how "STAT LST:=UC1:" could be working on Grant Searle's CP/M.    Can someone double check this on Grant Searle's CP/M?

Thanks,

Wayne

[CubeCentral]

Wayne,

I didn’t have the forethought to issue a “STAT DEV:” or “STAT VAL:” on the vanilla system, but if I remember correctly, I was simply able to use LST: as is on a "Vanilla" RC2014 system.  Meaning that the LST: logical device points to the second serial port by default.

Additionally, the RDR: logical device also points to the second serial port by default, but for “Input”  -  I was able to send a file from the second serial port to the first serial port (CON:)

 

Printing worked using PIP LST:=FILE.TXT

And receiving a file worked using PIP INCOMING.TXT=RDR:

 

I can swap out the boards later this afternoon back to a Vanilla configuration and get more information if someone else already hasn’t.

 

                -Randal   (at CubeCentral)

 

 

Sorry Randal, you are right.  UC1: is not a valid assignment for LST:. As far as I know the STAT command itself would not allow such this assignment unless the STAT command itself was modified.

 

So... the real question is how "STAT LST:=UC1:" could be working on Grant Searle's CP/M.    Can someone double check this on Grant Searle's CP/M?

 

Thanks,

 

Wayne

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/e138459b-17f5-47d2-8802-a948522469d9%40googlegroups.com.

[Wayne Warthen]

On Tuesday, May 1, 2018 at 8:04:24 AM UTC-7, Cube Central wrote:

Wayne,

I didn’t have the forethought to issue a “STAT DEV:” or “STAT VAL:” on the vanilla system, but if I remember correctly, I was simply able to use LST: as is on a "Vanilla" RC2014 system.  Meaning that the LST: logical device points to the second serial port by default.

Additionally, the RDR: logical device also points to the second serial port by default, but for “Input”  -  I was able to send a file from the second serial port to the first serial port (CON:)

 

Printing worked using PIP LST:=FILE.TXT

And receiving a file worked using PIP INCOMING.TXT=RDR:

 

I can swap out the boards later this afternoon back to a Vanilla configuration and get more information if someone else already hasn’t.

 

                -Randal   (at CubeCentral)

Thanks Randal,

Probably not worth the effort of reassembling your system.

I am making some minor updates to RomWBW to handle the LST: situation better.  I will publish a new pre-release of v2.9.1 later today.  In this version, LPT: will refer to the second serial port if it is available.  Since LPT: can be assigned to LST:, this will allow WordStar, etc. to print to the second serial port.

I will also update the default IOBYTE, so that the initial assignment of LST: to LPT: is the default.  Thus, at boot, LST: will go to the second serial port if it exists.

I still don't understand how Grant Searle's CP/M could possibly accept the "STAT LST:=UC1:" command, but probably irrelevant at this point.

Thanks,

Wayne

[CubeCentral]

Wayne,

 

I wanted to be clear that on the Vanilla RC2014 I never used “UC1:” or “STAT LST:=UC1:”

Just the logical devices LST: and RDR:

If you do make a change, I might suggest allowing RDR: as Input from Serial Port B, as I found that to be a potential way to transfer files into the RC2014 system.

 

                -Randal   (at CubeCentral)

 

 

From: rc201...@googlegroups.com [mailto:rc201...@googlegroups.com] On Behalf Of Wayne Warthen
Sent: Tuesday, May 1, 2018 09:35
To: RC2014-Z80 <rc201...@googlegroups.com>
Subject: Re: [rc2014-z80] Re: Using ROMWBW and CP/M with second serial port as printer?

 

On Tuesday, May 1, 2018 at 8:04:24 AM UTC-7, Cube Central wrote:

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/2a6033ec-1d00-4229-b5c4-b942aef5d20b%40googlegroups.com.

[Wayne Warthen]

On Tuesday, May 1, 2018 at 8:54:56 AM UTC-7, Cube Central wrote:

Wayne,

 

I wanted to be clear that on the Vanilla RC2014 I never used “UC1:” or “STAT LST:=UC1:”

Just the logical devices LST: and RDR:

Got it.  Richard Deane made a post that indicated he was able to issue a "STAT LST:=UC1:" on Grant Searle's CP/M.  That is the post I was referring to.

 

If you do make a change, I might suggest allowing RDR: as Input from Serial Port B, as I found that to be a potential way to transfer files into the RC2014 system.

I didn't mention it, but the IOBYTE default will indeed now setup RDR: and PTR: to the second serial port.

I will publish v2.9.1-pre.2 on GitHub shortly.  I don't currently have a good way to test my changes, so it would be helpful if someone could try it.

Thanks!

Wayne

[CubeCentral]

Wayne,

 

I would be happy to test the changes.

Please list what changes you have made so that I can be thorough.   Or instructions on how to test a change if it’s not something obvious… :)

 

                -Randal   (at CubeCentral)

 

 

From: rc201...@googlegroups.com [mailto:rc201...@googlegroups.com] On Behalf Of Wayne Warthen
Sent: Tuesday, May 1, 2018 10:04
To: RC2014-Z80 <rc201...@googlegroups.com>
Subject: Re: [rc2014-z80] Re: Using ROMWBW and CP/M with second serial port as printer?

 

On Tuesday, May 1, 2018 at 8:54:56 AM UTC-7, Cube Central wrote:

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/11625e7e-56dc-4aae-8380-096767260590%40googlegroups.com.

[Wayne Warthen]

On Tuesday, May 1, 2018 at 9:05:54 AM UTC-7, Cube Central wrote:

Wayne,

 

I would be happy to test the changes.

Please list what changes you have made so that I can be thorough.   Or instructions on how to test a change if it’s not something obvious… :)

 

                -Randal   (at CubeCentral)

OK, I published RomWBW v2.9.1-pre.2 on GitHub.  The only thing to test is that LST:, RDR:, and PUN: all refer to second serial port, if a second serial port exists.

Thanks,

Wayne

[Cube Central]

I've tested it out some, the results are promising:

B>STAT VAL:

Temp R/O Disk: d:=R/O

Set Indicator: d:filename.typ $R/O $R/W $SYS $DIR

Disk Status  : DSK: d:DSK:

User Status  : USR:

Iobyte Assign:

CON: = TTY: CRT: BAT: UC1:

RDR: = TTY: PTR: UR1: UR2:

PUN: = TTY: PTP: UP1: UP2:

LST: = TTY: CRT: LPT: UL1:

B>STAT DEV:

CON: is TTY:

RDR: is PTR:

PUN: is PTP:

LST: is LPT:

...and...

PIP LST:=FILENAME.TXT

PIP LPT:=FILENAME.TXT

PIP PUN:=FILENAME.TXT

PIP PTP:=FILENAME.TXT

...all work sending output to Serial B and ...

B>STAT CON:=UC1:

...to switch the console to the other Serial port

B>STAT CON:=TTY:

...to switch it back to Serial Port A.

This naturally fails:

B>PIP RDR:=FILENAME.TXT

CANNOT WRITE: RDR:

...as well as...

B>PIP PTR:=FILENAME.TXT

CANNOT WRITE: PTR:

B>PIP UR1:=FILENAME.TXT

CANNOT WRITE: UR1:

B>PIP UR2:=FILENAME.TXT

CANNOT WRITE: UR2:

The following write the file to the console I'm using on Serial Port A

PIP UP1:=FILENAME.TXT

PIP UP2:=FILENAME.TXT

PIP UL1:=FILENAME.TXT

And I get an occasional (?) failure with

B>PIP UC1:=FILENAME.TXT

ABORTED: FILENAME.TXT

...or sometimes it silently fails only printing a single line to Serial Port B.

A strange thing I encountered was with the RDR:  I seem to remember on the Vanilla system being able to transfer a file to the system from another terminal on Serial B by using PIP INCOMING.TXT=RDR: and then "ending" the file (EOF) with a CTRL-D or CTRL-Z.  With some playing I think it will work, as I do get what I typed into Serial B to show up in the INCOMING.TXT file.  I will play with it more, but it does show that the input is happening so it's not a assignment error.

I hope this list and test is helpful.  Please let me know if there's something I missed or if clarification is needed.  Cheers!

    -Randal   (at CubeCentral)

[Wayne Warthen]

Thanks for the testing Randal.  Sounds generally positive.

I will try to find a way to get my RC2014 running so I can try the last two things you mention that seem to be behaving oddly.  My workspace is under construction right now, so it is a bit problematic.

-Wayne