• Please review our updated Terms and Rules here

Model II Serial handshake not working

I am using Hyperterm "send text file" to test, but I need proper handshakes because ultimately I want to use a transfer program that sends files in Intel HEX format (admittedly, text, but huge files) for reconstitution on the Model II. The handshaking is essential because where a file is too big to fit in the available memory it needs to be written to disk and during that time the serial communication must be paused, otherwise quite a big chunk of data will be lost.

Incidentally, this transfer utility works very well - I use it on a FPGA CP/M box that I built (it is one of the supplied utilities).

I can get a reasonable transfer on the Model II with a low enough baud rate, or character / line pacing, but only a genuine RTS/CTS type handshake that pauses the send operation will do here.
 
Last edited:
I can get a reasonable transfer on the Model II with a low enough baud rate, or character / line pacing, but only a genuine RTS/CTS type handshake that pauses the send operation will do here.
As my dad used to say, "It's terrible to want an not get".
It may be that CP/M on the model II just doesn't do what you want it to. You might just have to live with what it gives you.
 
Well, I have read every post here, and maybe I'm thick, but I still don't see any answer as to WHAT direction you are transferring...

Is this TO the TRS80, or TO the PC??

This would tell you which side of the handshake needs to be functional (at least at high speed).

Second, does the underlying OS&application recognize and control the HW handshake?

The simple way to test is to set up a transfer (long-so you have time to probe), and during the transfer, probe the handshake lines with a logic probe or oscope, and see if they are live & toggling. Then you'll at least know which lines are actually working and involved in a transfer...

gwk
 
It's PC -> Model II

Looks like the scope is the next stop, unless anyone has any other connection suggestions. It's easy to rewire this thing.
 
Some time ago I used this null-modem cable to connect between a PC (with a real hardware serial port) and my Model 12.

I used to 25 p. serial connectors with this wiring.

1 to 1
2 to 3; 3 to 2
4 to 5; 5 to 4
(6 and 20 together) to 8; 8 to (6 and 20 together)
7 to 7

The data need to be 7 bits intel format for the TRS 80's

Use bin2hex and hex2bin on the PC. you can find them on the internet. (16 bits MSDOS programs)

Use Tera Term Pro v. 2.3 to send the intel hex data. (on internet too)

Use RECEIVE on the M12.

The data is loaded on 3000 hex, but can be relocated or given an offset.
RECEIVE turns the the data back into a CMD file for you.

This all I can find about it.
 
No, I don't think so. It has serial options for hardware handshaking.

It all depends on what you're using on the TRS-80 end. If you're just using the CP/M command to copy serial port to file it may not support hardware handshaking. If you're using a transfer program it probably does support handshaking. Like it or not, Radio Shack did a lot of shortcuts in all of their products. I do know these ports support handshaking if the application does also.
 
I'm using the Lifeboat Associates CP/M terminal program "dumbterm" to test.

Maybe it really is dumb! I was expecting it to honor the system settings (that is, "hardware handshake", which I quoted from the LA manual previously, and chosen in the LA setup program). I shall have to look further into it. The end game is usage of a transfer program which I have the source for. I am certain this is using CTS/RTS protocol because that is how it works on the FPGA CP/M box (the serial port doesn't have DCD etc lines, just CTS/RTS/TXD/RXD/GND).
 
I have been thinking about what you've been experiencing. It makes me think one end or the other is not using hardware handshaking at all. It has been my experience that when hardware handshaking fails, one of the machines involved locks up.

Why not try getting a copy of kermit over to the model II? It seems there is a version of it. http://www.columbia.edu/kermit/cpm.html

Convert it to hex format, transfer that over using ascii pacing, convert it back to binary and then use that to transfer your files. Here's a source for some of the needed files: http://www.z80.eu/kermit.html

You're looking for
Code:
CPVTLB.HEX  TRS-80 model II with Lifeboat 2.25C CP/M Display
CPVTPT.HEX  TRS-80 model II with Pickles + Trout CP/M Display
 
JonB, is it possible that your CPU board had the Bisync modification? See Tech Bulletin II:17. This would screw up standard serial port operation.
 
I have been thinking about what you've been experiencing. It makes me think one end or the other is not using hardware handshaking at all. It has been my experience that when hardware handshaking fails, one of the machines involved locks up.

Why not try getting a copy of kermit over to the model II? It seems there is a version of it. http://www.columbia.edu/kermit/cpm.html


Convert it to hex format, transfer that over using ascii pacing, convert it back to binary and then use that to transfer your files. Here's a source for some of the needed files: http://www.z80.eu/kermit.html

You're looking for
Code:
CPVTLB.HEX  TRS-80 model II with Lifeboat 2.25C CP/M Display
CPVTPT.HEX  TRS-80 model II with Pickles + Trout CP/M Display


I've tried to do that, but I need MLOAD.COM, which I don't have on the Model II.

I did try to transfer MLOAD's hex file but it's too big. The MII has to write it to disk in chunks, and it loses bits of the hex file while doing this, because it is not able to tell the PC to pause, due to lack of hardware handshake.

Maybe there is another way to LOAD these two hex files to create a working KERMIT. LOAD.COM only takes one argument though.
 
It's PC -> Model II

Looks like the scope is the next stop, unless anyone has any other connection suggestions. It's easy to rewire this thing.

With all that you've tried so far, I bet it is some (non) interaction between the HW & SW. In some cases, as with HW that can buffer MANY MBs of data, HW handshake alone will do the trick. But in this case, I'd venture to say that you have to have your transfer progs controlling the HW port handshake (as in setting it up properly and minding it's limits in SW)...

gwk
 
Unknown. Is that a mod to both ports or just port A?

Port A only.

Also, are you using the Dummy Terminator on the unused serial port? This is required as per the Model 2 DOS Reference Manual.
 
What??

I tried with Port B as well. No difference. Am beginning to think griffk is onto something. I do have the transfer client on there, and I will be looking at its source to see what it does explicitly for handshake (it doesn't work but may serve as a guide). But I would have thought that, having set the port options in SETUP.COM, all programs - in particular PIP as it is part of CPM - should honour them. Otherwise what is the point of a global settings application!
 
I had a look at the source for the transfer client and it has no explicit handshaking code in it.

This would imply to me that the interface is asserting CTS only when the transfer code is expecting a character via CONIO. It actually loops until a char is ready:

Code:
; Wait for a char into A (no echo)
GETCHR: 
	LD	E,FFH
	LD 	C,CONIO
	CALL 	BDOS
	CP	0
	JR	Z,GETCHR
	RET

That said, this wasn't written for a TRS 80, but it does provide an example of the sort of code I need (and like I said, it does not assert handshake lines explicitly).

EDIT: ...and a look at the VHDL implementation of the 6850 ACIA that this code is ultimately talking to, via the BDOS, shows that the hardware is asserting the handshake independently of the operating system, when its own internal buffer is half full.

On the other hand (from http://fixunix.com/cp-m/611-hardware-flow-control-z80-sio.html )

I think there are a lot of examples how to program the Z80SIO with
hardware handshake in the good old KERMIT source files! Look at

http://www.columbia.edu/kermit/cpm.html

for more details.

..which suggests I may need to do it in code.
 
Last edited:
On the other hand (from http://fixunix.com/cp-m/611-hardware-flow-control-z80-sio.html )



..which suggests I may need to do it in code.

I hate to rain on a parade, but I had a look at Kermit sources for CPM80 and there doesn't seem to be support for anything but XON/XOFF SW flow control...

Depending on the UART involved, it should either have a pollable status line for "buffer full", or an interrupt vector to your CPM COM user routine to handle the buffer. Either of these methods will implement your HW handshake up through the OS, so that the calling program can do a "getchar()" or a "GetBuffer()", and subsequently reset the UART status through the driver routine.

It would probably be instructive to know what the CPM COM routine is doing -- I don't have a listing in front of me (nor, with your specific HW could I), but even just a straight disassembly of the routine would do the trick -- then you'll know for sure, how CPM is trying to handle HW handshake on your machine.

You did say you were using CPM, right?? :}
:confused:
gwk
 
I have found that on the Model II you really need to break large files into chunks. If you don't, when the drive activates and it writes out data, you will absolutely lose data every single time and your transfer will be corrupted.

Fortunately it's pretty simple to stitch things back together using DDT.

I hate to rain on a parade, but I had a look at Kermit sources for CPM80 and there doesn't seem to be support for anything but XON/XOFF SW flow control...

Depending on the UART involved, it should either have a pollable status line for "buffer full", or an interrupt vector to your CPM COM user routine to handle the buffer. Either of these methods will implement your HW handshake up through the OS, so that the calling program can do a "getchar()" or a "GetBuffer()", and subsequently reset the UART status through the driver routine.

It would probably be instructive to know what the CPM COM routine is doing -- I don't have a listing in front of me (nor, with your specific HW could I), but even just a straight disassembly of the routine would do the trick -- then you'll know for sure, how CPM is trying to handle HW handshake on your machine.

You did say you were using CPM, right?? :}
:confused:
gwk
 
Back
Top