Terminal program recommendations ?

[Peter Onion]

I want to setup a serial link between my Zed Pro and my Orton 3C.

Eventually I'll write a program for the Zed Pro to handle uploading and downloading Intel (*) Hex Records to and from the 3C, but to start all I need is a simple terminal program for the Zed Pro to test that the serial connection is working.

So I'm looking for recommendations for simple terminal programs the run on CP/M 3.

PeterO

(*) The observant will notice I've swapped from Motorola S records to Intel Hex records so I can directly upload the hex output files from M80/L80.

[Richard Deane]

Courtesy of Anna Christina - >>> You can find QTerm here: https://git.imzadi.de/acn/qterm

Richard

--
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 view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/360f77eb-579d-417b-b03e-284ab3ef2a89n%40googlegroups.com.

[Peter Onion]

Thanks Richard.   

 I've tried a couple of versions, but they all seem to be loosing characters after a few lines of dumped hex.  This may be due to my RomWBW VDA driver being a bit slow because to the RC2350 waits for frame sync when processing line feeds to avoid tearing, or because there is no flow control back to the 3C. 

 I can easily add flow control at the 3C end.  Just as a test I will first try adding some "end of line" delay in the 3C code.

PeterO

[Wayne Warthen]

Yeah, if using VDA, you will almost certainly need flow control.  Delays or lower baud rate may get it working.

-Wayne

[Peter Onion]

I will get my scope out when I get home and check if the Zed Pro is asserting the RTS line.  If it is I can add code to my bit-banged serial output to check the RTS line before sending a character.

PeterO

[Peter Onion]

The Zed Pro is raising RTS so I've added an extra input bit on the 3C so the transmit subroutine can test it's state before sending a character.  

I'm taking the opportunity to rewrite some other bits of the my code in the 3C's ROM at the same time so it may take a while before I can test the flow control.

PeterO

[Peter Onion]

With hardware flow control working the output from my Orton 3C is now displaying correctly on my ZedPro using qterm3c :-)

Only thing I've had to change is the inverse video is now using the top bit of the character rather than the vt100 escape sequence.

Next thing is to write a simple terminal program that will capture intelhex records when the 3C sends them, and then write them to disk.

Then add the ability to send them back to the 3C for a full "Load and Save" capability. 

PeterO

[Peter Onion]

Having now found and read the  qterm manual (it's in the files directory)  I've got it working to save the intel hex records from the 3C using the "catch file" feature, and to send them back to the 3C using the "print file to remote" feature.  

The print feature needs the CP/M 3 LST: device to also be set to COM1.

PeterO

[Peter Onion]

I'm having trouble when I try to capture a large intelhex memory dump from the 3C (It's actually a dump of Camel Forth).   It's about 1A00h bytes, so the intelhex version will be about 20kbytes.

It looks like the hardware flow control goes wrong when qterm has filled an internal capture buffer.  qterm stops displaying incommng text for a few seconds but it has not raised RTS- so the 3C continues to send data.

After a couple of seconds RTS- is raised and the 3C stops sending.  After ~250ms RTS- drops again, the 3C starts sending and qterm starts to display the incoming data again.

This only happens when qterm is capturing the incoming data.  I've tried a coulple of versions, qerm3c (CP/M 3 version) and qtermh1 (HBIOS version) and all produce the same results.

I've also tried using kercpm3 (kermit fpr CP/M 3) and that seems to work correctly.  It only raised RTS- when it was writing to disk (i.e. when the green LED on IDE the board was on).  However that's not a good solution as 

I don't seem to be able to get it out of CONNECTed  mode (Ctrl-/C does nothing).

I'm not sure if this is a problem with the HBIOS serial line driver or if it is a problem in qterm.  The fact the kermit seems to wok ok does suggest the latter as the cause.  I'll have a look at the source code for qterm.  

PeterO

[Peter Onion]

I can't find anything that tells me how to actually build qterm from all the .Z files.  There seems to be a version of ZSM.COM included but I can't figure out how to use it as it seems to just take a single .Z file as input and produces a .COM file for output.

PeterO

[Peter Onion]

With a few hints from Anna Christina Naß I've managed to workout enough magic incantations to build a new working version.  Now I can try to find the bug (if it is in qterm).

PeterO

[Wayne Warthen]

Not sure what is going on with QTERM.  The flow control is managed by the HBIOS driver.  Both QTERMH1 and KERCPM3 would be using the same exact driver.  Actually, QTERMH1 should be slightly better because it is calling the HBIOS API directly instead of going through CP/M.  I'll try to do some quick tests of flow control on QTERMH1.

On KERCPM3, the key sequence to return to the command prompt is a little funky.  Hold down Ctrl while pressing "\" (backslash), then release Ctrl and press the letter C.  Above, it appears you might be using ctrl-/ (forward slash).

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 view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/97108430-d3bc-4cf6-9f66-a1bb4ec366e5n%40googlegroups.com.

[Peter Onion]

On Fri, 2025-11-07 at 09:08 -0800, Wayne Warthen wrote:
> Not sure what is going on with QTERM.  The flow control is managed by the HBIOS driver. 
> Both QTERMH1 and KERCPM3 would be using the same exact driver.  Actually, QTERMH1 should
> be slightly better because it is calling the HBIOS API directly instead of going through
> CP/M.  I'll try to do some quick tests of flow control on QTERMH1.
>
> On KERCPM3, the key sequence to return to the command prompt is a little funky.  Hold
> down Ctrl while pressing "\" (backslash), then release Ctrl and press the letter C. 
> Above, it appears you might be using ctrl-/ (forward slash).
>
> Thanks, Wayne
>

Wayne,

After a bit of a struggle I've got a set of tools and sources that I can use to rebuild
qterm.

What I have noticed int the code is a call to send an XOFF character before it starts to
write the capture buffer to disk. Obviously that is not going to work as my 3C doesn't
support XON/XOFF.

The sequence of events is very strange but I think there must be some disk buffering going
on because the IDE activity led only comes on after qterm restarts displaying incoming
characters. I'm about to connect up my set of seven segment displays so I can use them
for debugging (Turning LEDs on when qterm is writing the capture buffer for example).

Strangely the rebuild version seems to behave slightly differently and is less prone to
actually loosing characters. 

I'll let you know what I find.

PeterO

[Wayne Warthen]

Interesting.  It the 3C is ignoring the XON/XOFF, it shouldn't matter.

I exercised flow control on QTERMH1 pretty thoroughly and could not make it misbehave for me.  I don't have the same setup as you, so this may not be very useful information.

Thanks, Wayne

[Peter Onion]

I finally got to the bottom of this.  It was caused by qterm having a configurable pause after it sends XOFF to the host.  It does this before flushing the full capture buffer to disk.  For some reason that I've not figured out yet it was pausing for ~2½ seconds, during which time it was putting incoming characters into a ring buffer.  Now my Orton 3CX doesn't do XON/XOFF flow control, so it just keep sending characters, and qterm puts them into its ring buffer which isn't big enough to hold 2½ seconds worth of characters, so it starts discarding them.  That's why the data loss was happening, not as I suspected due to lost SIO interrupts.

SO now I can get on with working out how much data to save when  Camel Forth has had new words added to its dictionary :-)

PeterO

   

[Wayne Warthen]

Nice sleuthing Peter.  That is odd behavior by QTERM.

-Wayne

[Peter Onion]

Thanks Wayne.

It must have made sense to some one at some point, and I guess if you don't have hardware flow control it makes sense to send a preemptive XOFF before stating to write 16k of buffer to possibly a slow floppy disk ?  But the feature interaction between having hardware flow control and the mis-configured XOFF pause and ring buffer size meant neither flow control scheme was working.

I'll "tidy up" the qterm source code by either removing the XON/XOFF or making its use configurable (and off by default).

PeterO