Transferring text files from Kaypro II to Windows machine.

[DavidWien]

Kaypro is set to 300 Bd. "stat dev:" returns "rdr: is tty:" . Type >b: . Type "aip b:kaypro.txt=rdr:" . Hit return. Pip loads and waits.

On pc, open teraterm5, set "serial, 300 BD, 10mS delay per char". Menu/Serial File opens window: drag kaypro.txt (2.6kB) to window, click "sequential read", hit OK. Teraterm and flashing LED indicate data transferred to Kaypro. When this stops, hit ^Z (or alt-026) in teraterm window. No reaction on Kaypro screen. Hit Kaypro reset button. dir b: shows kaypro.$$$ on drive. Type "save 250 b:kaypro.txt", type "b:kaypro.txt" shows some real text (probably to do with CP/M), but nothing that should be part of kaypro.txt. What next?

 

[durgadas311]

I'm not sure why you are mentioning "alt-026", the code that needs to be sent to the Kaypro is 0x1a so you must be sure that that code is sent. Normally, this is generated by holding down the Ctrl key and pressing 'Z'. Can you see that *something* gets sent when you press the ^Z ?

Can you post this "kaypro.txt" file so I can look at it? and also specify what text you typed?

 

[durgadas311]

To be clear, I'm asking to see the file that you got from doing the "SAVE 250 B:KAYPRO.TXT" command. A copy of the contents of the "kaypro.txt" file on your PC, that was sent to the Kaypro, would also help.

By the way, "SAVE 250 ..." is way too much, you should be fine with "SAVE 40 ...". Also, this file does not contain text, it contains the contents of memory which includes PIP.COM and other random data. This means that doing "TYPE B:KAYPRO.TXT" is not going to be pretty, and it may be very difficult to see if the text you sent is in that mess.

 

[Thorbjørn Ravn Andersen]

Kaypro is set to 300 Bd. "stat dev:" returns "rdr: is tty:" . Type >b: . Type "aip b:kaypro.txt=rdr:" . Hit return. Pip loads and waits.

On pc, open teraterm5, set "serial, 300 BD, 10mS delay per char". Menu/Serial File opens window: drag kaypro.txt (2.6kB) to window, click "sequential read", hit OK. Teraterm and flashing LED indicate data transferred to Kaypro. When this stops, hit ^Z (or alt-026) in teraterm window. No reaction on Kaypro screen. Hit Kaypro reset button. dir b: shows kaypro.$$$ on drive. Type "save 250 b:kaypro.txt", type "b:kaypro.txt" shows some real text (probably to do with CP/M), but nothing that should be part of kaypro.txt. What next?

Does the typing you see happen on the console (like you type it yourself) or does it happen when copying from the RDR: device.

Perhaps make a small video of what you do and what you see? Currently all we know is what you choose to tell us

 

[acgs]

I'm not sure why you are mentioning "alt-026", the code that needs to be sent to the Kaypro is 0x1a so you must be sure that that code is sent.

Another way to send any character on IBM compatibles is to hold down the Alt key and type the three decimal digit code for the character on the numeric keypad. Since ^Z is decimal character 26, the three digits would be 0-2-6.

Hit Kaypro reset button. dir b: shows kaypro.$$$ on drive.

Does the kaypro.$$$ file have a file size? If so, it might have at least part of the file you sent.

 

[durgadas311]

Since the KAYPRO.$$$ file was never closed, it won't have any data in it.

 

[DavidWien]

I'm not sure why you are mentioning "alt-026"

I tried that because it is the way to get ^Z into Word and other programs.

Normally, this is generated by holding down the Ctrl key and pressing 'Z'. Can you see that *something* gets sent when you press the ^Z ?

Yes. There is a blip of the blue LED in the cable, indicating pc to kaypro signal

To be clear, I'm asking to see the file that you got from doing the "SAVE 250 B:KAYPRO.TXT" command.

See photos.

Can you post this "kaypro.txt" file so I can look at it?

attached

and also specify what text you typed?

Not sure what you refer to. See photos, which are a sequence.

D

 

[durgadas311]

I guess there's no way for you to post the B:KAYPRO.TXT file you saved on the Kaypro. Perhaps you can dump it in hex using DUMP.COM and then stop it (^S, ^Q resumes) at the right point. The *address* of the text saved by PIP should be at 1FCAH, which means the *offset* shown by DUMP.COM should be 1ECAH. A screen shot of this might help. What I'm looking for is evidence that PIP received the text, but also to see what's at the end of the text... if there are "odd" control characters that might indicate what PIP is seeing when you try to type ^Z. Generally, CP/M does not care about the parity bit, but make certain you've configured Tera Term for no parity (8 bits no parity).

 

[durgadas311]

I wonder if Tera Term might not automatically resume "terminal mode" when it finishes sending the file (and thus ignoring attempts to type ^Z - but you did say the LED flickered). A better test might be to just enter some short text in terminal mode, followed by ^Z.

 

[durgadas311]

So I ran this test on my simulator: "PIP TEST.TXT=RDR:" and then typed a sentence into a terminal connected to the "serial port". When I pressed ^Z then PIP exited. But, I went ahead and did "SAVE 40 TEST.OUT" at that point anyway. Then I used DUMP.COM to show the file TEST.OUT. At the right spot, I stopped it with ^S.


You can see that the text I types starts at offset 1ECAH ("the quick brown fox..."). In this case, there are ^Z characters after the CR-LF since PIP saw the ^Z and then filled out the rest of the record with ^Z. In your case, we're looking for what actually got stored at 1ECAH and beyond.

 

[durgadas311]

Just to re-emphasize, when you do the SAVE you are saving everything from 0100H onward (to the number of pages specified). This will include the PIP.COM program code, which is not something you can display with any meaning by TYPE. But it is imperative that you do not run any other programs between doing the RESET to terminate PIP and the SAVE.

 

[durgadas311]

Another thing you might do, to get a "cleaner" memory image, is to run this before running PIP:

A>ddt
DDT VERS 2.2
-f100,8000,0
-g0

Warm Boot

A>

This will fill most of memory with zeroes so that after the PIP and RESET (and SAVE) there should be no garbage in memory - making it easier to see the end of the PIP program and the text area.

 

[Thorbjørn Ravn Andersen]

So I ran this test on my simulator: "PIP TEST.TXT=RDR:" and then typed a sentence into a terminal connected to the "serial port". When I pressed ^Z then PIP exited.
You can see that the text I types starts at offset 1ECAH ("the quick brown fox..."). In this case, there are ^Z characters after the CR-LF since PIP saw the ^Z and then filled out the rest of the record with ^Z. In your case, we're looking for what actually got stored at 1ECAH and beyond.

What do you see with "TYPE TEST.TXT" now?

 

[durgadas311]

TEST.TXT (TEST.$$$, actually - there is no TEST.TXT) is 0 bytes (records), and so there is nothing to TYPE as far as CP/M is concerned. I know that PIP does not write any records to disk until it gets a ^Z (or fills memory), so there is not going to be any data on disk anywhere.

 

[davidrg]

I wonder if Tera Term might not automatically resume "terminal mode" when it finishes sending the file (and thus ignoring attempts to type ^Z - but you did say the LED flickered). A better test might be to just enter some short text in terminal mode, followed by ^Z.

While it involves too much typing compared to TeraTerms GUI, I wonder if Kermit 95 might actually make this particular task easier. And if sending files via the kermit protocol will be happening later it might end up being needed anyway as IIRC someone else had difficulty getting Tera Terms Kermit implementation to talk to Kermit on a Kaypro several weeks back in another thread.

Something approximately like this should work from either Kermit 95 or C-Kermit. The TRANSMIT command doesn't send with any particular protocol - its equivalent to Tera Terms "Send File" feature.

; Configure the serial line. You can type SHOW COMMUNICATIONS (or SH COM for short) to see current settings
set line com1              ; Use COM1
set speed 9600             ; 9600bps
set flow none              ; No flow control
set serial 8N1             ; 8 data bits, no parity, 1 stop bit
set carrier-watch off      ; Not using a modem, no need to wait for carrier

; Configure the TRANSMIT command. You can type SHOW TRANSMIT (or SH TR for short) to see current settings
set transmit eof \{26}     ; send ^Z at the end of the file
set transmit echo off      ; Don't echo transmitted characters
set transmit pause 10      ; Wait 10ms after each line (text mode) or character (binary mode)
set transmit prompt 0      ; Don't wait for a sign from the other end that its ready for the next line in text mode
set transmit linefeed on   ; send CR+LF for each line rather than just CR when transmitting in text mode

; Send a file using either text mode (stuff happens per line, with optional character set translation) or binary mode (stuff happens per character)
transmit /text /transparent foo.txt  ; Send foo.txt followed by Ctrl+Z, pausing for 10ms after each line, don't translate character sets
transmit /binary foo.txt             ; Send foo.txt followed by Ctrl+Z, pausing for 10ms after each character

Settings will of course need adjusting based on what you're sending to and how fast you want to send it. Eg, Kermit can be set to wait for the host to echo back each character (binary mode) or a line feed (text mode) before it sends the next character or line, etc. HELP SET TRANSMIT and HELP TRANSMIT have all the details, as does the C-Kermit book.

 

[Thorbjørn Ravn Andersen]

TEST.TXT (TEST.$$$, actually - there is no TEST.TXT) is 0 bytes (records), and so there is nothing to TYPE as far as CP/M is concerned. I know that PIP does not write any records to disk until it gets a ^Z (or fills memory), so there is not going to be any data on disk anywhere.

I misread what you wrote - I thought it was DavidWien who got his serial communications working and missed that the PIP syntax should write a file. My bad.

Why doesn't PIP close the file when you type Ctrl-Z? Did I miss more?

 

[durgadas311]

Why doesn't PIP close the file when you type Ctrl-Z? Did I miss more?

David's problem is that when he types ^Z then PIP does not seem to recognize it. In my tests, ^Z always works and the file is closed and contains the text I typed. To simulate the conditions David is experiencing, I tested without pressing ^Z and just doing the RESET and SAVE.

As I think about it, since we don't have any idea why ^Z isn't working, perhaps David should run a test to ensure that his copy of PIP is not corrupted. If he ran "PIP TEST.TXT=CON:" and then typed some text on the Kaypro followed by ^Z, that will tell us if PIP is really looking for the ^Z or not. I do see that David's Kaypro has modifications for "international languages" and so perhaps we need to be certain that ^Z is still ^Z on that machine.

 

[Thorbjørn Ravn Andersen]

As I think about it, since we don't have any idea why ^Z isn't working, perhaps David should run a test to ensure that his copy of PIP is not corrupted. If he ran "PIP TEST.TXT=CON:" and then typed some text on the Kaypro followed by ^Z, that will tell us if PIP is really looking for the ^Z or not. I do see that David's Kaypro has modifications for "international languages" and so perhaps we need to be certain that ^Z is still ^Z on that machine.

I still think a video of what actually happens would be very helpful. It might clear up misunderstandings we have not even identified yet.

 

[durgadas311]

...
See photos.

attached

Not sure what you refer to. See photos, which are a sequence.

D

Upon reviewing these photos closer, I notice that your version of CP/M does not "signon" the same as the standard Kaypro distribution. The copy I have signs on with:

KAYPRO II 64k CP/M vers 2.2

A>

while yours signs on with:

KAYPRO II
64k CP/M v 2.2

A>

So, there are some differences we may need to figure out.

In addition, when you do the SAVE you should be saving the contents of memory which should start with a copy of PIP.COM followed by the text you typed. But the first bytes of PIP.COM contain a ^Z (1AH) character at location 9 and so if you were to TYPE that you'd only get 9 characters max. The output of the "TYPE KAYPRO.TXT" command should have been:

CNδIʹʹIʹʹ

and that's all.

So, we need to start looking at what is "non-standard" in your version of CP/M. Or else how your procedure might not actually be saving what we think it is.

 

[durgadas311]

@DavidWien Can you share the disk image you are using to boot CP/M? If you downloaded it somewhere, share the URL. Else if you have an IMD or TD0 for it, find a place to share it? Worst case, I can setup ftp/scp access to my public server so you can put a copy there.