RTS/CTS handshake with SIO/2 board possible?

437 views
Skip to first unread message

acn...@gmail.com

unread,
May 5, 2019, 9:41:08 AM5/5/19
to RC2014-Z80
Hallo,

Is it possible to use RTS/CTS handshake for the second port of the SIO/2 chip
on the standard SIO/2 card?

I bought a daisywheel typewriter that features a RS232 interface and connected it to my RC2014
via a RS232-to-TTL-adapter.

The typewriter interface uses 9600-N-8-1 together with RTS/CTS signalling, as it is ... ... a little slower :)

When connecting it, it works and prints some characters, but after 1-2 lines, it cannot keep up with the data.

In WordStar, I could configure a delay of 100ms after each character, which seems to work fine (as the
typeweriter can print about 10 chars/sec).

But for dBase, I did not find such an option - and for e.g. BASIC there is no such option.

I saw that the SIO/2 features RTS+CTS, but only one of them is connected to the FTDI header.

Is it complicated to enable it and does it need some other configuration?

Thanks a lot!

Regards,
Anna

PS. The typewriter is an Erika S3004 by Robotron from the GDR together with the IF6000 RS232 interface.

Alan Cox

unread,
May 5, 2019, 10:01:28 AM5/5/19
to rc201...@googlegroups.com
> I bought a daisywheel typewriter that features a RS232 interface and connected it to my RC2014
> via a RS232-to-TTL-adapter.
>
> The typewriter interface uses 9600-N-8-1 together with RTS/CTS signalling, as it is ... ... a little slower :)

Can it do XON/XOFF or only RTS/CTS and do you know how old it is (is
it RTS/CTS or one of the older hardware handshaking protocols ?). If
it can also do XON/XOFF that doesn't need any extra pins.

> But for dBase, I did not find such an option - and for e.g. BASIC there is no such option.

dBase is (correctly) expecting that any such delay is in the CP/M BIOS
for the relevant device. Historically you'd have modified your BIOS as
needed to do the delays on the printer device.

> I saw that the SIO/2 features RTS+CTS, but only one of them is connected to the FTDI header.

The other is present but appears to be grounded, so I imagine some
work would be needed bending up pins, soldering them etc.

Alan

acn...@gmail.com

unread,
May 6, 2019, 9:34:01 AM5/6/19
to RC2014-Z80
Am Sonntag, 5. Mai 2019 16:01:28 UTC+2 schrieb Alan Cox:

Hallo Alan,

> The typewriter interface uses 9600-N-8-1 together with RTS/CTS signalling, as it is ... ... a little slower :)

Can it do XON/XOFF or only RTS/CTS  and do you know how old it is (is
it RTS/CTS or one of the older hardware handshaking protocols ?). If
it can also do XON/XOFF that doesn't need any extra pins.

No, I cannot configure it to use Xon/Xoff instead of RTS/CTS.
 
> But for dBase, I did not find such an option - and for e.g. BASIC there is no such option.

dBase is (correctly) expecting that any such delay is in the CP/M BIOS
for the relevant device. Historically you'd have modified your BIOS as
needed to do the delays on the printer device.

Okay. But adding this would cause that the second serial port will *always* be slower, so that even
if I disconnect the typewriter and attach my WiFi-modem the transmission will be about 10 chars/sec :)
 
> I saw that the SIO/2 features RTS+CTS, but only one of them is connected to the FTDI header.

The other is present but appears to be grounded, so I imagine some
work would be needed bending up pins, soldering them etc.

And that would be the question: Is this possible and what needs to be done afterwards.
Will it "just work" or would some software modification (BIOS?) be needed?

Besides, I'm thinking about using a microcontroller (maybe a Teensy) to hook between the RC2014 and
the typewriter for acting as a kind of "print buffer" that uses two serial ports - one with only Rx/Tx for
the RC2014 and one with RTS/CTS enabled for the typewriter.
Maybe that would solve my problem :)

Bye,
Anna 

Spencer Owen

unread,
May 6, 2019, 5:29:26 PM5/6/19
to rc201...@googlegroups.com
Hi Anna,

I'm sure that somebody on here did modify their SIO/2 module to add in RTS and CTS, and I don't think that they had to make any changes to the BIOS, but I can't find the post to confirm this.

Using a Teensy, or any micro between the RC2014 and any other device is certainly a good idea.  Not only can you include RTS/CTS, but it can run the two ports at different speeds, and you could even have software shortcuts built in to "type" particular commands to either the RC2014 or the other device.

Cheers

Spencer

--
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/cfe3e665-16c5-4488-82bd-a8689b66e138%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

acn...@gmail.com

unread,
May 7, 2019, 7:38:35 AM5/7/19
to RC2014-Z80
Am Montag, 6. Mai 2019 23:29:26 UTC+2 schrieb Spencer Owen:

Hi Spencer,
 
I'm sure that somebody on here did modify their SIO/2 module to add in RTS and CTS, and I don't think that they had to make any changes to the BIOS, but I can't find the post to confirm this.

I'm just curious: Why did you design the SIO/2 card that way? :) What was your idea behind doing it this way?
 
Using a Teensy, or any micro between the RC2014 and any other device is certainly a good idea.  Not only can you include RTS/CTS, but it can run the two ports at different speeds, and you could even have software shortcuts built in to "type" particular commands to either the RC2014 or the other device.

I think I will try that. Thanks!

Regards,
Anna 

karlab

unread,
May 7, 2019, 7:58:32 AM5/7/19
to RC2014-Z80
Hi
I am not sure if this answer the question but; 
both my (#34) and Steve's serial modules (SC104) have implemented RTS and CTS lines on the SIO/2 modules.



I don't know if that will work in the given situation above, or changes have to be applied to the bios.

Karl

Jim McGinnis

unread,
Feb 8, 2020, 2:14:37 PM2/8/20
to RC2014-Z80
I modified the standard RC2014 SIO/2 board to respect A2 by exploiting one gate of the Hex inverter on the board (only one gate is used). The others have floating inputs and outputs.

Here is a pic of that mod...


The RC2014 SIO/2 board does not engage the CTSA or CTSB pins on the SIO/2 chip or FTDI connectors.

So, another mod. Not as clean. It requires SIO/2 chip pins to be flying...




Now I can send data to slow devices and data will be throttled as needed by the distant device - I am using RomWBW 2.9.2...

In my case, I chose to connect the Okidata MK321 Turbo Supervisory Signal to the DB-9 pin 7. The Okidata is configured for 200ms hold-offs. the scope trace reflects that same hold-off timing by the Okidata printer.

I use MAX232 like converters from Sparkfun.  BOB-11189.

Wired as follows...
I hope this is helpful. 

I have two more of the RC2014 SIO/2 cards to modify. One is not populated, yet. I can cut the traces for CTSA and CTSB from the GND plane and avoid the SIO/2 flying pins.

Or, just pick up Steve's the SC104 module and avoid the trouble.


No more botched printouts!  What a relief.

Best regards,

Jim


Jim McGinnis

unread,
Feb 8, 2020, 2:20:09 PM2/8/20
to RC2014-Z80
Oh, one more point.
I isolated the '138s G1/E3 (pin6) enable input pin for A2 address qualification after it is inverted. It requires cutting a GND trace which can be seen in the pic just between the 138 pin rows.

Cheers
Jim

Jim McGinnis

unread,
Feb 8, 2020, 2:26:20 PM2/8/20
to RC2014-Z80
I have built up a 12 slot enclosure and here is how the FTDI like converter is packaged...  Shrink-wrap to keep it out of trouble in the enclosure.

 

 

Jim McGinnis

unread,
Feb 8, 2020, 2:29:35 PM2/8/20
to RC2014-Z80

Some day I am going to get my head on straight - no edit capability sure does expose my randomness!

The FTDI CTS pins need to be isolated from ground (on rear side) as well..

I THINK I am done...   Cooked at 350F for 20 minutes....  :-)

Tony H

unread,
Feb 10, 2020, 2:20:30 PM2/10/20
to RC2014-Z80
Jim,

Thanks for the solution to the mirrored ports on the SIO/2 board. For some reason I didn't see that simple fix. Only took a few minutes to do it. Now I can set my SC104 module from Stephen Cousins to 084H without any port conflict issues. 

Tony

Jim McGinnis

unread,
Feb 12, 2020, 1:38:28 PM2/12/20
to RC2014-Z80
Glad it is a useful mode.

I am an amateur at HW modifications.  And this mod fit my skill level! LOL

I have also modified the RC2014 CF Card to eliminate its shadow addresses, as well...
The CF card is software driven using port addresses 0x10 though 0x17. But it also responds to port 0x90 through 0x97.

But it isn't exactly a preferred solution - the 1N4148 diodes and the pull-down (10K) works just fine. There is a trace to cut that goes from A6 to U2, Pin 4.

A6 and A7 have diodes attached which go to U2, Pin4. The resistor is also connected from U2, Pin4 to GND.



It adds A7 to the address select logic - A7 is ignored in the original design.

The mod limits the card to the low addresses only.



Todd Decker

unread,
Sep 4, 2020, 11:40:44 AM9/4/20
to RC2014-Z80
Jim,

What does the " respect A2 " statement refer to?  I've been reviewing posts on the CTS topic.  And, in doing so I've seen discussions about what resister values should be used (1K instead of 2K2).  Also, I've seen the 10K pull-up fix for RTS.  There are also some discussions on bad clone MAX chips for RS232 voltage converters.  Finally, I have seen concerns about in interrupt problem causing stalling in BASIC.  But, your note is the first I've seen on "respect A2".  Could you explain or point me to the thread where this is discussed?  I'm trying to collect the various points I should keep in mind and mods I should consider.

Thank you!

P. Todd Decker

Jim McGinnis

unread,
Sep 4, 2020, 6:34:20 PM9/4/20
to RC2014-Z80
Hi!
The reference to Address Line A2 is just one example of a common practice among many boards that do not decode all of the address lines. Instead of appearing at a single address or group of compact addresses, the board appears at multiple locations in the address space. This "loose" addressing does not mean that the card is not going to work correctly. It just takes up additional addresses needlessly - that may conflict with another board that may exist now or in the future.

By respecting A2 (using it to decode the address selection logic on the board) you can avoid wasting memory or port address space and avoid potential address conflicts with other boards - now or in the future. By tidying up the addressing for the board, the "shadow" addresses are eliminated. 

But let me repeat that the A2 mod does not affect the performance of the SIO/2 board. No impact whatsoever. The SIO/2 board is a fine performer.

I hope I have answered your question reasonably.

Best regards,

Jim

Todd Decker

unread,
Sep 4, 2020, 6:41:36 PM9/4/20
to rc201...@googlegroups.com
Yes, this answered my question very well and I understand.  Thank you 

---
P. Todd Decker
913-284-8814

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/Vd9c5WSYQ6g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/1d205f1e-043c-4c84-ae5d-e5865abf2905n%40googlegroups.com.

Reply all
Reply to author
Forward
0 new messages