Hardware-handshaking not working on either EaZy80 or Ztoid

[Paul dB]

I'm unable to get hardware handshaking to work on either EaZy80 Rev2 or Ztoid Rev0 boards. The /RTS output signal always stays LOW. Note I did need to accommodate for a schematic error.*

I used a K80W Rev21 board for comparison and hardware handshaking works fine on that one. And yes, I did have hardware-handshaking turned on in my terminal program (picocom) for all tests of /RTS & /CTS.

I'm using the default 'RCZ80_ez512_std.asm' config file for both EaZy80 and Ztoid boards. I'm wondering if it's possible that /RTS is being turned-off in UART.ASM for EaZy80 (and Ztoid)?

* The /RTS signals are crossed on the EaZy80 Rev2 and Ztoid Rev0
schematics, compared with K80W where the /RTS connections are correct.
(REF: Z84C90 (KIO) datasheet)

KIO CHIP OUTPUT               K80W SER.CONN.          EASY80R2 SER.CONN.
-----------------------------                ----------------------------          -----------------------------------
PIN29 (/RTSA) (PC4)           P3 PIN1                          P2 PIN1 (labeled /RTSB)
PIN14 (/RTSB) (PC3)           P2 PIN1                          P3 PIN1 (labeled /RTSA)

Here's a composite image with the results of enabling/disabling hardware-handshaking on the K80W:


Any help greatly appreciated.
Thanks, Paul

[T Gerbic]

One thing you might try is to use DTR/DSR as the handshaking signals. The USB chips usually have four signals on the chips but which are used and what they call them is not always consistent. 

[Jaap van Ganswijk]

We have found hardware handshaking to almost always be very messy and hard to debug and you need extra wires. We prefer the Xon/Xoff software handshaking, but it must be properly understood. These bytes can't  go through the normal buffering process but must get priority. Once an Xoff is received the device must stop sending it's normal output until it receives an Xon byte. Please note that some Uart's have an internal sending pipeline of say 16 bytes, which may complicate the process.

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/482aa90b-1782-45c9-8a9e-b63eea9483dbn%40googlegroups.com.

[Doug Jackson]

I second the buffer issues with hardware handshaking, especially with USB dongles....

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/CADNzunyF91Jui642Ja_BLNZ92aRU50n8E0XnB7sgn6_huiAqRA%40mail.gmail.com.

[Paul dB]

The mystery is why does the _same_ KIO serial circuit (apart from the swapped /RTS wires) work on the K80W SBC and not on the EaZy80 or Ztoid SBCs. The composite image I attached to the OP shows RTS/CTS working on the K80W.

I've tested 2 EaZy80 boards and 2 Ztoid boards (Ztoid and EaZy80 have the same serial circuit and swapped signals), so it's obviously not a component or soldering mistake. That's why I'm trying to understand what in RomWBW could explain the why RTS/CTS is not working on the EaZy80 and Ztoid boards.

Here are the two serial circuits:

[Wayne Warthen]

I am crazy busy with personal stuff right now, but will try to look into this in a couple days.

Thanks, Wayne

[Paul de Bak]

No problem Wayne. Please take your time.

Paul

You received this message because you are subscribed to a topic in the Google Groups "retro-comp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/retro-comp/kyO5vGgp8po/unsubscribe.
To unsubscribe from this group and all its topics, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/5af23634-6e85-4797-adab-1f8a1cdbea6fn%40googlegroups.com.

--

Sent by way of Linux Mint

[Paul dB]

I _may_ have found the source of the problem with RTS/CTS not working on EaZy80 and Ztoid.

Bill's 'easymon512k-r03_released.asm' is missing the command to set bit D7 to 1 in KIO Command Register A. That would result in the 'SIO/PIA mux' not being set to use the extra modem control signals, i.e. /RTSA and /RTSB.

From 'Z84C90 KIO Serial/Parallel Counter/Timer Production Specification':

page 7:

    Command Logic Unit
        <snip>
    A third function of the Command Register allows the user to obtain use of the additional
    control signals of the SIO logic instead of the PIA port by programming bit D7 of the
    Command Register with a 1.


So from 'Table 2. KIO Registers' on page 14:

    Register 14: KIOACmd  equ 0eh    ;KIO command reg A
    Register 15: KIOBCmd  equ 0fh    ;KIO command reg B


page 27:

KIO Command Register

Command Register A is used to program software resets and to configure the internal
interrupt daisy chain priority (see Figure 31). This register should be programmed before
all others. The reset control bits are momentary; writing a 1 pulses an internal reset signal
to the appropriate device.

From 'Figure 31. KIO Command Register A' on the same page:

    Bit D7  SIO/PIA mux: 0=PIA, 1=SIO

Now to figure out how to read register KIOACmd and verify that bit D7 is actually 0 ...

[Bill Shen]

Paul,
Sorry about not being responsive.  I've had medical issue since December last year and my recovery has been rather slow.  On top of that, the shutting down of retrobrewcomputers.org where most of my design information were stored has been very discouraging.  I'm trying to get back to retrocomputing, but one baby step at a time.  I can confirm Eazy80 can't receive files using XMODEM under RomWBW v3.6.  I'll try to solve the problem, but probably slowly. 

It is good to have a problem to focus my mind.
Bill

[Paul dB]

Bill, sorry to hear about your medical issue. Here's hoping for a fast and complete recovery!

I'm glad I'm able to help in giving you a problem to focus on ;-)

Regarding the shutting down of retrobrewcomputers.org, in case you don't have a backup of your project pages (text & images), I have a number of these that I saved earlier on my harddisk that I can supply.

I just checked the Wayback Machine (https://web.archive.org/) for captures of your retrobrewcomputers.org pages. There are several, and the most recent capture (I believe) is this URL from 2025-08-02:

https://web.archive.org/web/20250802122656/https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:start

The captures of the links on the page are a bit of hit or miss, but the page itself can perhaps provide an "outline" of your projects to help you build up your github page.

Paul

[Paul dB]

This looks like the cause of the problem:

Excerpt from kio.asm (starting line 57)
--------------------------------------------------------------

;HCS initialize KIO if NOT EZ512
;HCS      do not write to KIO command register, if EZ512
;HCS      because it is already done in monitor and will upset the bank register
#IF (SDMODE != SDMODE_EZ512)        ; Z80 PIO ON EAZY80-512
       ; INITIALIZE KIO
       LD A,%11111001                 ; RESET ALL DEVICES, SET DAISYCHAIN
;PdB           ^                                  D7 is NOT set for EZ512    (SIO/PIA mux: 0=PIA, 1=SIO)
;PdB                                               it not set in the monitor either
       OUT (KIO_KIOCMD),A        ; DO IT
#ENDIF

(Hope the spacing doesn't get messed up!)

Paul

[Wayne Warthen]

Paul,

I have not had time to look at this closely, but I agree this could be the problem.

Thanks, Wayne

[Paul dB]

I found something that seems odd (in the RomWBW source code); the code in both 'ez512_mon.bin' and 'zrc512_mon.bin' is identical (both contain the 'ZRC512 Monitor v0.3 10/15/23' code). As far as I understand, that monitor is configured for use with a CPLD, not a KIO, or ??

Paul

[Paul dB]

Wayne, Bill,

To continue this discussion, I've opened an issue in RomWBW. That way a solution can be found as time (and health) allows.

Thanks,

Paul

[Wayne Warthen]

Refer to RomWBW Issue #674 at https://github.com/wwarthen/RomWBW/issues/674 for updates.

Thanks, Wayne

[Bill Shen]

Paul,

Thanks for providing the latest homepage of my design on Wayback Machine.  My design files are backed up, but what I’m sad about the demise of retrobrewcomputers is the large volume of private messages between me and many users of my designs.  I’m also sadden by the lost of many wonderful public posts contributing to the evolution of my designs; long discussion on topics like Z280, CB030, Tiny68K, and many more.  I have prioritized my limited energy on non-electronic tasks I’ve neglected during my recovery.  I’m still behind getting my design files uploaded to GitHub and providing simple descriptions of how these design files tied together.  This will be a year-long process.  I thank you for your patience.

Bill

[Bill Shen]

It took some time to get reacquainted with Eazy80 design.  The port C of KIO is used to control the 16k banks of RAM, so it can not serve the SIO hardware handshakes function.  The Eazy80 monitor is setting up KIO correctly by writing 0 to data bit 7 of command register  to configure it as memory bank register.  I don’t think it can be multiplexed to serve both PIA and SIO functions.  So the fallback XMODEM transfer function is to reduce the serial port speed.  Assuming you are running Eazy80/Ztoids with 22Mhz Z80, you can issue “I 0 57600” command at RomWBW command to change serial port to 57600, then you should be able to do XMODEM transfer without hardware handshakes.  This is not ideal, but at least the XMODEM function can still work.

Bill

[Paul dB]

Bill, thanks for looking into my confusion regarding the KIO Port C modes ;-)

I raised an issue on RomWBW GitHub (see Wayne's post above from the 14th of May) regarding EaZy80's RTS/CTS problem since it looked like it might have been a software problem.

Wayne had the time to look at the schematic and came to the same conclusion as you did, i.e. Port C either functions as PIA or as SIO modem support. Somehow I had gotten the idea that the port was more flexible than it was.

A bit OT, but I'm quite fond of Ztoid, EaZy80's offspring. It's rather like the Z80 equivalent of Steven Cousins' Z180-based SC131 pocket computer; not quite as fast but perhaps a bit more flexible with I/O and free to set the CPU speed thanks to the KIO. I think a possible respin to remove the non-functional RTS traces, a half-size can oscillator, addition of serial 1K input (current-limiting) resistors and perhaps squeezing in some test points for easier access to the left-over KIO I/O (not to mention fixing the corners so it will fit in your Altoids tin ;-)).

That reminds me, I found some small boxes on AliExpress that fit the Ztoid, although it's a somewhat tight fit. Removing about 1mm from the narrow side of the PCB lets it sit nicely in the box.

In case anyone is interested, here's a link to the seller: https://www.aliexpress.com/item/1005008263313735.html
I'll attach a photo of the small box.

Paul

[Wayne Warthen]

In theory, it would be possible to manipulate the PIA Channel C bits 3&4 manually to achieve flow control.  However, this would incur a lot more overhead in bank switching to maintain the flow control bits during bank changes.  Bank switching is the most performance impacting function in RomWBW.

Bill's suggestion to lower the baud rate makes the most sense.  I would be inclined to build a custom ROM with 57,600 baud as the default.

-Wayne

[Paul dB]

Yes, lowering the default baud rate to 57600 baud would certainly be the simplest solution.

I was thinking of perhaps using two of the pins on Port A to emulate the RTS signal when KIO is enabled, by adding conditionals to sio.asm.

But even if the emulation was fast enough to work, it would be - what's it called? - 'a corner case' and unnecessarily add complication to RomWBW, apart from wasting two good I/O pins ;-)

Paul

[Paul dB]

 

Bill's suggestion to lower the baud rate makes the most sense.  I would be inclined to build a custom ROM with 57,600 baud as the default.

-Wayne

Just to follow up, I've now done some testing with a custom ROM, as suggested using 57,600 baud. At that baud rate and with hand-shaking disabled in my terminal program (picocom),  'xm' has worked perfectly with about a dozen files I've tried. The largest was hitechc.zip at about 220 kB, which resulted in a transfer speed of BPS:3562 which seems fast enough.

IMHO, using 57,600 baud as default is a good solution for the 22Mhz EaZy80 and Ztoid SBCs. The computers still work nice and fast without having to think about hand-shaking or issuing the 'I 0 57600' command just to use 'xm' :-)

Bill & Wayne, thanks for the help,

Paul

[Wayne Warthen]

Glad to hear 57,600 baud is working well.

I can change the default baud rate for the EZ80 platform in RomWBW to 57,600, but I think it needs to match the baud rate of the hardware ROM.  I will leave it to Bill to decide if he wants to change the baud rate of the hardware ROM and will follow his lead on that.

Thanks, Wayne

[Jaap van Ganswijk]

Have you considered disabling all  hardware handshaking and using the xon-xoff system? Want me to explain it?

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

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/5c599624-d468-4ac8-88eb-878ece413f1en%40googlegroups.com.

[Wayne Warthen]

On Sun, May 24, 2026 at 1:41 PM Jaap van Ganswijk <jaapvan...@gmail.com> wrote:

Have you considered disabling all  hardware handshaking and using the xon-xoff system? Want me to explain it?

Yeah, I have considered it and I am familiar with it.  To be honest, I have never liked it because it tends to cause issues with binary transfers.  I know there are ways to work around that, but I guess I just personally prefer hardware handshaking.

Thanks, Wayne

[Jaap van Ganswijk]

Might be a good point. Xon/xoff works best in an Ascii stream off course. You'd have to code binary data using one of the two usual ways I guess but it costs an overhead of about 30% I guess. Will think about it some more.

[7alken]

hi guys, I also vote for 57600 as better default for retro projects; as I was testing xmodem without rts/cts I got the same results and it worked all well also over TTL serial-bluetooth converter I used here instead of proper RS-232 cables; it would be good also for Fuzix, not sure what default was there now;

hi Bill, sad for me you lost that personal content and also your health issues, me here slightly similar complications since end of 2025, but working on it all slowly ... during entire may I returned somehow to the LLM things, not following it all for half a year also, being deeply busy here, and it was insane what all evolved - I know that many hate it, but guys, its not bad, these possibilities now with "codex app" are crazy, it can give to many new blood into system )) ... even new optimisim, contrary to general fear ... at least my view (and ya, I am also mainly conservative as hell, be sure), so I started to test codex, first asking how it all grasp, afraid and unsure, but it was blowing my mind after few minutes of first tries ... I can write something more about it as separate post, if there will be some kind of interest (btw those first tries are on m github - apws); sadly, during this testing I was also (again) trying/selecting which distro of linux use to replace my more and more ugly win11 (since permanent hypervisor runs on bottom, my virtualbox VMs were unusable as even legacy vbox mode cant get hw accelerations from cpu, so I started to hate that host ... and one day (just May 16) I must admit, I greatly helped nice CachyOS and his Calamares installer to unintentionally nuke my win C drive/ssd )) ... those preselected defaults to first system drive are evil, without any explicit selections/confirm... but okay, no stress, I tried some quite smart DMDE recovery (sure should work on regular hdd) on filesystem, great hopes, but that SSD controller (trim) was fast and smarter than me ... so I have only some remnants of ntfs mft with filenames and timestamps, so somehow possible to restore at least timeline what all was lost (most things in cloud, everything important till end 2025 - work things are on other drives locally too, and as I prepared cleaning of ugly OneDrive so, had hydrated it locally on backup disk also (just preparing it for the the linux client - not too smart idea also, but there was projects folder, lots of important things, but again MS blocked some syncs since start of 2026 due to some error I ignored ... so, semi-ugly incident ... resulting with my permanent selection of CachyOS (or some other distro, will see, but this is not bad - as host system for virtuals, even win10 (not 11 again, but I used  something down to win2k, all broken for year or so) from there and virtualbox or kvm ... far better approach finally, so I am not sad too much ... also, as I have everything till end of 2025, I can find ALL things I PDFed from retrobrew, some those yours forums, at least to something around M68k I have here archived, it is in my YYMMDDx timelined local storage, will do query and can sent whats here, at least .. but, for the retrobrew site, if they had also some bad hw incident or  its only some kind of politics, we can organize some campaign to get at least those data ... these days, also with help of that "ugly codex", is possible to do lots of smart recovery and transformations and ... even that uploading to github can be automated by this tool, believe me (will test it on my project also)... when I offered to you some help, I didnt knew nothing about codex yet, but today, I am SURE its great help to many things (plus, also dangerous in wrong hands, sure) ... excuse me this OT here, I wish you good recovery and some new optimism too ... I got it, even after my deeply unhappy "nukedc" incident;

take care, all guys here;
Petr

[Alan Cox]

If you are using actual classic hardware things tend to go pear shaped about 19200/38400 baud because most older terminals can't keep up.

The 115,200 used on rc2014 and Grant's machines though is simply a property of using a 7.37MHz system clock. As there's no separate clock for the ACIA or SIO that's the only useful baud rate you can obtain.

Alan

--

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

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/566bef99-9839-4a54-ab7e-d13e9774eb5en%40googlegroups.com.

[7alken]

hi Alan, ya, even better for defaults, for me was quite pain to reconfigure that BT-serial adapter, so I was lazy, wishing to have one shared settings for everything ))