Problem with PCGET, Minicom and xmodem

[Jason Spitzak]

I am having issues using the PCGET command inside of CPM, I get the error: "Retry 0: NAK on sector" whenever I send the files. As mentioned I am using Minicom and xmodem. Some research led me to find people had similar problems but PCPUT worked and PCGET worked for very small files, I have gotten PCPUT to work but PCGET doesn't work no matter the file size. I have also seen people saying that the issue is USB adapters which I do use but I don't know how I would solve that so if there is another solution that would be greatly appreciated, thank you!

[Walt Perko]

Hi, 

I've had a similar problem ... look in the terminal program manual how to transfer programs with XMODEM ... I found that IMP245 uses a "R" command and that receives/downloads a file ... a "S" command sends/uploads a file.  

IF I try using TeraTerm - File - XMODEM I get that same error message.  

.

[Gwen Patton]

I use ExtraPuTTY, and it works fine for the XModem transfer in my SC131 Z180 machine. Maybe it operates differently?

--
You received this message because you are subscribed to the Google Groups "Altair-Duino" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altair-duino...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/5265dba6-c8c4-4903-8848-eb4a1e11f15en%40googlegroups.com.

[Walt Perko]

Hi, 

ExtraPuTTY is running on your PC?  It may have other built-IN XMODEM transfer commands ... check the manual.  

You might want to try TeraTerm ... that's what I use on my PC to connect to vintage computers.  

.

[Gwen Patton]

ExtraPuTTY is working just fine, and I use it for more than talking to my CP/M retros. I admit I haven't used it for Xmodem transfers to the Altair-duino, but I do use it for my other CP/M box, and it transfers fine. I don't get those errors. I used Xmodem to transfer a bunch of stuff I downloaded to my PC, including Turbo Pascal, dBase II, and Wordstar, three programs I used a LOT back when I was using an NEC PC-8001 CP/M box.

-=-=-=-=-=-=-=-=-

73,

Gwen, NG3P

On Fri, Dec 15, 2023 at 7:53 PM Walt Perko <r4r...@gmail.com> wrote:

Hi, 

ExtraPuTTY is running on your PC?  It may have other built-IN XMODEM transfer commands ... check the manual.  

You might want to try TeraTerm ... that's what I use on my PC to connect to vintage computers.  

.

On Friday, December 15, 2023 at 4:39:54 PM UTC-8 ard...@gmail.com wrote:

I use ExtraPuTTY, and it works fine for the XModem transfer in my SC131 Z180 machine. Maybe it operates differently?

On Fri, Dec 15, 2023, 2:22 PM Walt Perko <r4r...@gmail.com> wrote:

Hi, 

I've had a similar problem ... look in the terminal program manual how to transfer programs with XMODEM ... I found that IMP245 uses a "R" command and that receives/downloads a file ... a "S" command sends/uploads a file.  

IF I try using TeraTerm - File - XMODEM I get that same error message.  

.

On Thursday, December 14, 2023 at 3:33:31 PM UTC-8 jason....@gmail.com wrote:

I am having issues using the PCGET command inside of CPM, I get the error: "Retry 0: NAK on sector" whenever I send the files. As mentioned I am using Minicom and xmodem. Some research led me to find people had similar problems but PCPUT worked and PCGET worked for very small files, I have gotten PCPUT to work but PCGET doesn't work no matter the file size. I have also seen people saying that the issue is USB adapters which I do use but I don't know how I would solve that so if there is another solution that would be greatly appreciated, thank you!

--
You received this message because you are subscribed to the Google Groups "Altair-Duino" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altair-duino...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/5265dba6-c8c4-4903-8848-eb4a1e11f15en%40googlegroups.com.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/799875fb-0740-4e83-8909-14c81436aef1n%40googlegroups.com.

[Patrick Linstruth]

I don’t know how faithful the 2SIO emulation is on the AltairDuino simulator, but a real 2SIO will not receive data if DCD is low. I just ran a test with Minicom and PCGET on AltairZ80 simulator. I was getting the same Sector 0 NAK errors on Minicom. I then remembered about DCD and pulled it high. After that, the Xmodem transfer went just fine.

With DCD low, a real 2SIO will ignore all incoming characters.

So, it appears that PCGET for 2SIO works just fine with Minicom and sx.

[Patrick Linstruth]

The original SIO device for AltairZ80 wasn’t very accurate so I created M2SIO devices that are more accurate and also support SIMH’s TMXR system. This allows connecting real serial ports (or sockets) to the M2SIO devices. I pulled DCD high by connecting it to RTS on a breakout box. The M2SIO device can also be configured to ignore DCD and assume it’s high.

With real serial ports attached to the simulator, transfers with PCGET, FLOP2PC, etc. running communication software like IMP, MEX and CBBS and can be done.

sim> set m2sio1 ena
sim> attach m2sio1 connect=/dev/cu.usbserial-AL009KFH
sim> show mux
Multiplexer device: M2SIO1, ModemControl=enabled, Output Unit: M2SIO1,
    Input Polling Unit: M2SIO1,
    attached to Connect=/dev/cu.usbserial-AL009KFH;9600-8N2, connected, sessions=0
Connected to serial port /dev/cu.usbserial-AL009KFH
 Connected 00:00:02
 Modem Bits: RTS DCD CTS DSR  

  input (on)
  output (on)

I looked at serial.cpp for the AltairDuino simulator and it doesn’t appear to support any of the 2SIO control or status lines, so that probably isn’t the source of the Xmodem problem. But the symptom does appear to be PCGET not receiving data (or SOH) which will cause PCGET to send a NAK about every 3 seconds.

On Dec 17, 2023, at 11:07 AM, John Galt <furba...@gmail.com> wrote:

how do you pull dcd high on the emulator?

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

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/fa5408a6-c535-4df6-916e-bb91dcd3d0b7n%40googlegroups.com.

[Patrick Linstruth]

What is really needed is better diagnostic information… what is the sender sending, what is the receiver receiving, and what is the receiver’s response to the sender.

PCGET sends a NAK and waits for an SOH or CAN. If neither of these characters are received in approximately 3 seconds, it sends another NAK. It will do this forever.

After receiving an SOH, it waits approximately 1 second for the sector number. If a byte isn’t received it times out and sends a NAK and waits for another SOH or CAN.

After receiving the sector number it waits approximately 1 second for the compliment sector number. If a byte isn’t received it sends a NAK and waits for another SOH or CAN.

If the sector number and compliment don’t compare, it sends a NAK and waits for another SOH or CAN.

It now receives 128 bytes. If no bytes are received within 1 second, it sends a NAK and waits for another SOH or CAN.

It now waits for the checksum. If the checksum isn’t received in 1 second, it sends a NAK and waits for another SOH or CAN.

If the checksum does not match, it sends a NAK and waits for another SOH or CAN.

If the checksum matches, it sends an ACK and waits for another SOH or CAN.

Based on the information I’ve seen in these posts, it is not possible to know which of the above states is causing PCGET to send a NAK.

Can you use something like Minicom on the wifi modem end and TeraTerm on the other end to send single characters back and forth using the keyboards? Will the wifi modem send/receive single bytes 0x00 - 0xff as is?

I think the tools being used to diagnose the problem need to be simplified to verify the core functionality required for Xmodem work.

> On Dec 17, 2023, at 11:43 AM, John Galt <furba...@gmail.com> wrote:
>
> no matter what i try when i'm connected over a wifi modem to my unix machine i cannot receive a file, i can send but not recieve generates errors.
> if i am connected via usb connection then pcget and pcput work fine.
>
> i have not been able to find a solution.
>
> i tried stty clocal. and i've tried ixon ixoff, software flow control, etc... nothing works.

> To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/43553ec2-837d-4c4e-89b6-70c18e5fcfedn%40googlegroups.com.

[Patrick Linstruth]

Xmodem expects to see [SOH][SEC][~SEC][128 BYTES][CHECKSUM], all 8-bit data. It will respond with an ACK or NAK.

I am not sure how flow control (other than XON/XOFF) could cause a problem. Hardware flow control doesn’t (shouldn’t) change the data stream.

What we need is a better serial diagnostic tool other than Minicom and Xmodem. We need to see what is going back and forth. A poor-man’s protocol analyzer would be real nice.

The program “Serial” I use on the Mac can dump the raw data stream to a file. Does TeraTerm have anything useful like that?

If PCGET doesn’t work, we can certainly add some diagnostics to it, assuming the transfer is done on port B and the console is available for diagnostic output.

> On Dec 17, 2023, at 12:49 PM, John Galt <furba...@gmail.com> wrote:
>
> ===

> Can you use something like Minicom on the wifi modem end and TeraTerm on the other end to send single characters back and forth using the keyboards?

> ===
>
> i can make a connection between the wifi modem and teraterm, or wifi modem to a second wifi modem. i can send text back and forth between either modem or type of connection.
>
> minicom uses SX and RX so when trying to receive anything it fails. with crc or checksum errors.
> kermit will also allow me to send files but not receive same error.
>
> if i go to a Telnet BBS i have been able to successfully download a file using the modem.
>
> this lead me to play with the terminal settings stty on my unix machine. because it has to be a setting.
> but i have been unable to find it.
>
> if a text file is small it will receive it because it comes in before the Checksum or CRC error.
> its an issue with flow control and what Xmodem excepts to see when a packet is successful.
> ---
>
> ===

> Will the wifi modem send/receive single bytes 0x00 - 0xff as is?

> ===
> i believe it does, i remember looking that a few months ago.
> Software flow control does not seem to do anything, hardware flow control is non-existant. so mostly its flow control turned off.
> ---
>
> now i kind of dropped playing around with this wifi modem because i went into a new project but reading all this got me interested again.
>
> i will have to play around again.

> To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/d662b1ca-5d00-41d9-a66e-d6480ef6e37dn%40googlegroups.com.

[Patrick Linstruth]

"stty -ixon” disables XON/XOFF. If you’ve given it that flag, then it isn’t XON/XOFF causing the problem unless your character driver is broken.

If either of the modems are transmitting at a rate faster than the link (DCE) rate or faster than the receiving system can process in the incoming data, then Xmodem will not work. This would typically appear when trying to send files because the sending data will get lost if data is being sent faster than something along the path can process it. Unfortunately, most software doesn’t report overrun conditions.

Can you send a large text file and have it appear at the other end without any loss of data?

A good test may be to create a large file with repeated “0123456789” so it is easy to see if a character is dropped somewhere along the way. Be sure that all character/line delays are disabled.

I suspect you are not having a software problem (other than bugs in drivers).

> On Dec 20, 2023, at 1:28 PM, John Galt <furba...@gmail.com> wrote:
>
> software flow control seems to be the issue.
>
> i can't figure it out.
>
> basically if i have 2 Wifi modems on two s-100 computers and i use IMP 2.47 on both, i can send and receive files.
> if i change one computer to a pc and use teraterm, once again i can connect but i can only send from one side usually s-100 to teraterm. but not the other way.
> there are no settings in teraterm i can find...
> if i connect to a telnet BSS then i can recieve files, if i use teraterm and connect to a telnet bbs i can recieve a file, if i try to use a wifi modem as a inbetween then i can't
> same with the unix box. i can send but not receive.
> its like something is getting lost with the software flow control. i thought it was telnet mode for the wifi modem but that didn't matter.
> i played around with STTY till blue in the face but still won't work... also if i use teraterm and the wifi modem on wo machines it will not work correctly
> it tells me it isn't the modems but the software i'm using to talk over them
>
> now i found a Zmodem cp/m modem program and i want to try that but i have no had time to play with it everything just takes hours and hours to setup only to find no solution.

> To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/aa58722a-f33b-4499-83d2-5b4c48e32bfan%40googlegroups.com.

[fridtjof.ma...@gmail.com]

Actually, given the protocol - a single file with 00.7f another with 80..ff each with 00 ff 55 aa 00 ff 55 aa as a leader (8 bytes, so 136 bytes total). IF THESE TWO GET THROUGH EXACTLY, xmodem will work. Note - dropping nulls (00) or FF or ANYTHING and the protocol will fail. You don't need "flow control" a packet is 128 bytes and a couple of bytes of overhead. You don't need to send the two packets back to back. Just one, verify it went through ok, then the next. And yes, your "wifi modem" may well be eating characters -- thus the 00 FF at the very front (to validate). Making sure the unix terminal is in "raw mode" is important, AND that the whole path is 8-bit clean.

[Patrick Linstruth]

If you can get IMP and TeraTerm to display those non-printable characters then sure, that would work too. But I don’t think those tools support that.

I am attempting to rule out a flow control problem with the tools at hand. If we can rule out flow control, which is what was being alluded to with the "it’s like something is getting lost with the software flow control” comment, we can then move on.

I am working on a tool that can be run under CP/M will test all of this, because trying to diagnose this kind of problem with tools that aren’t designed to diagnose this kind of problem doesn’t seem like the best approach.

> To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/7d69f7f0-8c82-45fc-904f-10f379b8d6cfn%40googlegroups.com.

[Patrick Linstruth]

Telnet is a protocol. Have you tried using Netcat (nc)? I believe that does raw socket connections.

> On Dec 20, 2023, at 7:03 PM, John Galt <furba...@gmail.com> wrote:
>
>
> Telnet doubles the 255 character is there a way to turn that off for a file transfer?

> To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/467d94d5-18b3-4238-8124-86c138d5d48en%40googlegroups.com.

[Walt Perko]

Hi, 

When running IMP 2.47 or other versions ... when you tell the target computer to "Send" you a file, you ESC-E back to the IMP command line, type "R<enter>" and it should receive the file via the IMP internal XMODEM protocol.  

.

On Thursday, December 21, 2023 at 8:03:35 AM UTC-8 John Galt wrote:

kind of interesting....

i've been fighting with teraterm.

so i have teraterm 4 and teraterm 5.

I have my altair setup with a wifi modem running IMP 2.47.

both teraterm can connect over IP to the wifi modem which i have setup to auto answer. i can send text back and forth over the terminal for imp and teraterm.
if i try to send an Xmodem file from the altair to the pc or receive a file  from pc to altair under teraterm 4 it fails.

under teraterm 5. i can send a file from altair to pc no problem.

when i try to send from pc to altair (teraterm to wifi modem imp) it fails but in a different way then teraterm 4.

so i started to play around with the terminal settings 

i played with new line characters Receive and transmit. i tired CR, LF and CR+LF and that resulted in different errors.

i spent hours messing around but really did not get much further.

i tried changing things in IMP and CRC verse Checksum and 1K mode i lost track of what i was doing basically.

there is a log but i didn't play with it.

i also tried setting the modem in telnet mode and not in telnet mode, didn't make a difference.

the reason i say its a handshake issue is there something is getting lost between the two machines telling either one it has received a packet and it is good and please send another one.

different errors have been NAK, or packet number does not match, header error. etc.

but there does not seem to be enough options to play with at least in teraterm. maybe i need o go back and explore putty or kitty, if they have some more options to mess around with

i think putty allowed you to play with the FF OO settings for ixoff ixon. teraterm does not have that option.

with kermit it was the same issue. i could send a file from the altair with wifi, but when i tried to receive a file it would generate packet errors or get about 12 packets in then fail with crc or checksum errors.

or unexpected packet number this was when i was making all kinds of STTY changes on my unix machine.

PCget and PCput on there own work fine at least with teraterm and my pc with a direct serial connection(no wifi modem)

i did try something but it did not work. I connected my wifi modem to teraterm, then i ran a little program i made that would send characters to a serial port and a message displayed on my teraterm terminal.

that confirmed the wifi modem was talking to teraterm. then i tried to run pcput to send a file through pcput to teraterm but nothing got through.

i called it a night, deal with it another time.

for months i have been trying to get the wifi modem to be able to download a file with Xmodem and i just get stopped.

i did try this a few months ago.

i connected two PCs with teraterm to the modems and tried to send a file back and forth and if i remember that also failed. 

that was when i setup two altairs with wifi modems and ran imp on both machines and was able to send files back and forth even at 1K no problem

that showed me it was a software issue as the hardware could send and receive a file properly.

originally i thought there was a problem with the wifi modems but that proved not to be the case.

i need to find more time...

[Jason Spitzak]

Thanks everyone for the responses! I unfortunately do not have access to the Altair until after my schools winter break but your help is much appreciated! When I get back early January I will be able to test your theories.

[Jason Spitzak]

I wanted to give an update on this, and I will start by clarifying that I am a extreme beginner at this, consequently I haven't been able to understand many of the solutions that have been recommended. So let me just start by saying that I can only use linux for this, so many of the programs recommended like ExtraPUTTY are not an option. A suggestion that seemed promising was the one suggested by Pat, but I couldn't understand your guide for actually pulling DCD high (maybe because it was made for the emulation). One piece of information that probably isn't helpful but PCGET does create an empty file when used but that is probably a trait of PCGET rather than xmodem. Here are a bunch of screenshots (posted one at a time) of the Altair and minicom configuration. If there is one specific screenshot that would help please ask... in layman terminology preferably.

[Jason Spitzak]

[Jason Spitzak]

On Thursday, January 18, 2024 at 3:48:54 PM UTC-8 Jason Spitzak wrote:

[Jason Spitzak]

[Jason Spitzak]

[fridtjof.ma...@gmail.com]

John -- yup, telnet protocol changes FF to FF FF. Sad, and xmodem protocol does NOT work over telnet protocol. Also, xmodem as a protocol is very simple: SOH,packet#,~packet#, 128 bytes,checksum. It then waits for ACK or NAK. On ACK, send the next packet. On NAK, send the pack again (and this is off the top of my head). So 131 bytes per packet. Really easy. The receiver paces. The sender waits for the ACK/NAK. and then sends next or resend current. The receiver sends an unadorned ACK or NAK. The receiver times out in 10 seconds, and then NAK, which starts things. That is needed IF the receiver starts first. EOT instead of SOH -> NAK, EOT again -> end of file. CAN for cancel (either side) if you want to be "fancy". Given the simplicity it is trivial to write the code. But... all bytes must send/receive. no line ends or buffering or flow control or that sort of thing. On linux, I (generally) use the bluetooth module for my terminal.

The following command gives me a serial port:

sudo rfcomm connect /dev/rfcomm0 00:BA:90:02:0F:62 1 &

This makes the bluetooth connection to the AltairDuino and that becomes device /dev/rfcomm0

(change the address as needed for your device) Now, I need a terminal on top of that: I launch xterm:

xterm -ti vt340 -132 -sl 20480             \
      -fg green -bg black                  \
      -fa Dec-Terminal-Modern -fs 10       \
      -tb -fc 5                            \
      -xrm "XTerm*deleteIsDEL: true"       \
      -xrm "XTerm*allowFontOps: true"      \
      -xrm "XTerm*allowWindowOps: true"    \
      -xrm "XTerm*backarrowKey: true"      \
      -xrm "XTerm*on4Clicks: group"        \
      -xrm "XTerm*on5Clicks: all"          \
      -xrm "XTerm*maxGraphicSize: 800x480" \
      -xrm "XTerm*pointerShape: pencil"    \

Note that this gives sixel, regis and 4014 graphics, and a reasonable text terminal

Within the xterm, I run picocom to attach to /dev/rfcomm0 (or, the usb or the real serial port --

whichever is in use).

picocom --escape \]     \
        --baud 9600      \
        --flow n         \
        --databits 8     \
        --stopbits 1     \
        --noreset        \
--send-cmd sx    \
        --receive-cmd rx \
            /dev/rfcomm0

Here, notice that I will use sx and rx to send and receive files. On the end of the AltairDuino, I

use PCGET and PCPUT. 9600 baud is just fine... if speedier is needed, the micro-sd can be directly

mounted and I use altairdsk. (Note: be careful, minicom does not allow complete passthrough of everything,

so is problematic. picocom is "dumb enough" to work properly)

https://github.com/phatchman/altair_tools

altairdsk directly supports the altair floppy format, the "tarbell", the hd format, *and* my modified hd format.

As I don't use the 5.25 inch formats, this works perfectly for me.

 

Note - faster speeds are "doable"; 38400 would be right around the speed of the Altair floppy disk! With 64kb of memory,

sending ALL of ram in a minute is fine for me (which is what 9600 achieves).

Cooking up a custom rx/sx for linux would be an hour or so of work -- my github has la36 which you can crib for the bulk of the effort:  https://github.com/ratboy666/la36 I haven't done so, because sx/rx has worked just fine for me.

As I do not have a WIFI module for my AltairDuino (and really don't care about that -- the bluetooth works just fine) I cannot

speak to that - I do know that xmodem protocol with rx/sx on linux, aginst bluetooth, usb and serial is flawless. (and, I

also cannot speak to Windows, because I don't have that -- just Linux and FreeBSD).

So -- ditch minicom in favor of picocom. xterm preferred for reasonable (accurate) terminal emulation. xterm respects the vt100 escape sequence to enter vt52 mode, which is needed (for example) for spellstar operation under wordstar 3.3.

xterm support 4014, sixel and regis which you find useful and interesting.

altairdsk provides for direct usage for altair hard sector floppy format on linux and the 5mb hard-disk formats -- both the "standard" and my enhanced 1024 directory entry version https://github.com/ratboy666/hd1024

Fred Weigel

On Wednesday, December 20, 2023 at 7:03:23 PM UTC-5 John Galt wrote:

Telnet doubles the 255 character is there a way to turn that off for a file transfer?

On Wednesday, December 20, 2023 at 4:48:39 PM UTC-5 pat...@deltecent.com wrote:

[fridtjof.ma...@gmail.com]

The xterm options are chosen to have 1 click position cursor,
double click select word, triple click select line, quadruple click select paragraph/block, quintuple click select all (for middle button paste)

[Jason Spitzak]

If XMODEM doesn't work are there any alternatives? PCGET uses XMODEM by default, is there a way to change that?

[Patrick Linstruth]

PCGET/PUT can be written to support any transfer protocol, but those other protocols will probably also fail because the problem isn’t with PCGET/PUT or Xmodem. The problem is more than likely with the transport.

For example, running PCGET/PUT over the Telnet protocol isn’t a problem with PCGET/PUT or Xmodem. The problem is attempting to use a binary-incompatible transport to transport binary data.

There has been a lot of discussion about Xmodem not working, but nobody has been able to point their finger as to WHY it isn’t working, just that it doesn’t work.

Last weekend, I did several PCGET/PUT transfers between AltairZ80 and Serial on Mac using Wifi modems without any problems. I also did several rz/sz under Linux with Serial on Mac and PCGET/PUT on Altairz80 using Wifi modems without the failures described here.

I did notice some timeouts, but Xmodem always recovered as it should. I hope to figure out the cause of the timeouts.

The only complete Xmodem failures I’ve had are when Teraterm and Windows are involved. Shocker.

Someone needs to document an rz/sz environment that fails, that someone else can reproduce and determine the cause of the failure rather than throwing darts at the problem hoping to find a solution. Other than using an incompatible transport, I have not been able to make Xmodem fail.

As far as Windows/Teraterm goes, I’ll hopefully figure out the cause this weekend. Might just be a Windowsism.

> To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/4f587dbe-0d33-4516-b1ab-9fe2fdc38716n%40googlegroups.com.

[fridtjof.ma...@gmail.com]

Thank you. I also haven't had any issue with XMODEM as a protocol. It is so simple that it is nearly "foolproof" except...

There isn't need for "flow control"  -- the "inner loop of an xmodem receive is but 8 instructions

(or so): at 250,000 instructions/second -- the Altair (and AltairDuino) can receive 25000 bytes per second.. or 250kbaud. Sure. Just do NOT use interrupt driven receive -- unless (maybe) you interrupt on the first receive character and then get the rest of the packet in a loop.

Make sure the line is "8 bit clean" All characters from 000H to 0FFH must be transmitted and received AS IS. No funny stuff. If you have to deal with a 7-bit line, or strange control characters -- use kermit (or something else). XMODEM is not for you.

 As I have mentioned, I do not use a "WiFi modem" -- bluetooth serial for me! (original AltairDuino). I cannot imagine WiFi modem is any different. I have even written a "hayes emulator" that I use with the AltairDuino: https://github.com/ratboy666/hayes

And, yes xmodem works over the hayes emulation! (if you care). What this looks like:

(and in [[]] is annotated comments)

A>r mdm7 [[Use R.COM to launch MDM7.COM, patched with serial port going to RS232 port, connected to Linux machine running hayes]]

MDM740 modem pgm (type M for Menu)
Copyright (c) 1984 - Irvin M. Hoff
ALTAIR SIO [[Just validating it is using the SIO port]]

A3>>COMMAND: T [[Enter terminal mode in MDM740]]

at [[issue AT command, to validate that the hayes emulator is alive]]

OK [[hayes replies with OK... it is here!]]
atdt sh [[issue a dial command -- this is not a real modem, so the command is executed as a command on the Linux box -- we are asking for a shell!]]

CONNECT [[Yup, it connects]]
sh-5.2$  [[and, now we can use rx/sx etc on the unix side to transfer files]]

[[and to illustrate, let us look at a file "run"]]

sh-5.2$ cat run
killall cpnet
killall hayes
./cpnet -ini ./cpnet.ini &
./hayes -t /dev/ttyUSB0 &
sh-5.2$ sx run [[use sx to send "run"]]

^E [[get to MDM740 menu - control+E]]

r xxx [[receive as filename xxx]]

File open, ready to receive
CRC in effect
Received # 1
[Transfer completed]
[[ the last line is from the sx command -- I think...not 100% sure]]

and, all done... Now let us check the file:

A>
A>type xxx
killall cpnet
             killall hayes
                          ./cpnet -ini ./cpnet.ini &
                                                    ./hayes -t /dev/ttyUSB0 &

And... tada - unix line ends (LF only...) this is correct.

Now, I deliberately used a very small file. I did NOT use PCPUT/PCGET -- here I used the "original" XMODEM as implemented in MDM740 (and yes, I know there are earlier versions). Just to demonstrate that this stuff did/does work. My hayes emulation is just "icing on the cake" here. It allows my AltairDuino to "reach out and interact" much like the real Altairs and Imsais would have in the '70s. I do have a modem that I could use, but it is a pain. In the same way as AltairDuino lets me trip down memory lane, hayes does the same thing. Using ssh, I can then use eg. ATDT telnet some-server, or ATDT ssh another-system and have it make the

connection, without MDM740 suspecting that it is using anything other that a hayes modem!

If you want me to write a diagnostic for you, I can... I would need to know what serial you are targeting on the AltairDuino (SIO SIO/2 port A SIO/2 port B). Also, I will NOT be able to help you on the terminal side if you are using Windows or MacOS. Only Linux or FreeBSD, please. (my life is too short as it is, sorry -- I know MacOS is "BSD" on the inside, but I don't care). Alternative: look for M7SIO.ASM (in my hayes package) and use that as base for your own diagnostic! (that would be much more fun, I should think).

You can get MDM740.COM from any "normal" CP/M download site. the M7SIO.ASM patch to allow Altair SIO port as the communications port is included in the hayes source (because that is what I wrote hayes.c for in the first place). Nothing big, but it filled in the gap on the (Linux) side. And just shows XMODEM is versatile, and still works after more than 40 years.

[Patrick Linstruth]

I think an Xmodem diagnostic would be great! I was working on a diagnostic version of PCGET/PUT but got distracted.

> To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/490b7b2e-2ac2-4a02-a167-91ba746c92f9n%40googlegroups.com.

[fridtjof.ma...@gmail.com]

Sorry for the delay -- I got sidetracked by coding up a ADM-3A to VT52 shim. I should have some cycles to put a diagnostic together this week.

Fred

[Jason Spitzak]

I wanted to give a small update on this, I tried using picocom and after running rz -vv -E -X (my file) I got these errors

A>pcget binadd.c
Send the file now using XMODEM...
*** file: -X /home/jspitzak/minicom-upload/BINADD.C
$ rz -vv -E -X /home/jspitzak/minicom-upload/BINADD.C

rz: ready to receive /home/jspitzak/minicom-upload/BINADD.C
Retry 0: Got 025 sector header
Retry 1: Got 025 sector header
Retry 2: Got 025 sector header
Retry 3: Got 025 sector header
Retry 4: Got 025 sector header
Retry 5: Got 025 sector header
Retry 6: Got 025 sector header
Retry 7: Got 025 sector header
Retry 8: Got 025 sector header
Retry 9: Got 025 sector header
Blocks received: -1
rz: /home/jspitzak/minicom-upload/BINADD.C removed.

Transfer incomplete

*** exit status: 128 ***


Transfer Aborted

A>

Does anybody know what might be the issue, I couldn't find anything after looking into exit status 128 or the 025 sector header errors. I am new to this so please explain what you are describing

[fridtjof.ma...@gmail.com]

O25 is octal 25 for the first character. That is hex 15, which is NAK. The response to NAK is to resend. 10 retries, and out.

The RECEIVER sends an initial NAK, which triggers the send. You did PCGET (receive) talking to rz -X (receive).

They just bounce NAK back and forth...

Try PCPUT instead. PCPUT with rz -X (or, simply rx) PCGET with sx (sz -X).

picocom is preferred to minicom for this as picocom doesn't filter control characters.

- Fred 

[John Galt]

I wanted to give my follow up to a similar issue.

Here is what i have learned over the last few months.

i have tested different wifi modems and all have the same problem or feature depending on how you look at it.

this can also be related to people having issues with PCGET.

this started when i tried to connect to my UNIX machine over WIFI modem. everything worked correctly until i tried to send a file back and forth over XMODEM.

I have a working PCGET AND PCPUT connection between my ALTAIR and windows 10 machine using TERATERM. 

the reason it works is because it is a direct serial connection from the Altair to the Windows 10 machine over a USB to serial converter cable.

TERATERM sees this as Serial to serial.

my UNIX connection is via TELNET.

this is where the problem is.

(people connecting to APPLE Computers do not seem to have the issue. however many people are connecting to PCs and Raspberry pi and other machines.)

i noticed on my UNIX machine no matter what software i used over a WIFI modem, i could upload from the Altair to the UNIX machine but a download resulted in Time outs.

this extended to TELNET BBS as i tried to go down the list of BBS and ran into the same problem.

the wifi modems would default to TELNET MODE ON. so i started to turn off the TELNET MODE and only connect to TELNET BBS that were not over a Telnet Port.

the result was i could upload and download no problem.

i then Setup a Windows XP machine with PROCOMM PLUS and setup a Home BBS Hosted using ASPECT Language and started to see what was happening.

Basically the WIFI modems when in TELNET MODE will block or modify the expected characters that allow the error checking for any file transfer protocol to proceed.

IF i direct connected over Serial no problem at all.

So in the case of the OP if they are connecting over WIFI modem to a PC in TELNET MODE the file transfer will fail.

in my Case i would have to either directly connect to my UNIX machine over serial and setup a Serial terminal connection on my UNIX machine to allow a connection.

or i would have to setup a direct null modem connection

or i would have to take a WIFI modem and plug it into my UNIX machine and configure a connection over that serial device then use the Altairs WIFI modem and in effect

create a WIFI Null modem connection between the two machines.

Neither makes sense for how my equipment is setup.

Also note that the WIFI modem which emulate a Haynes modem, really don't they act much more like a WIFI Null modem cable connection then they do a real modem

that presents issues for remote machines that expect a real over the phone modem connection.

when also testing the wifi modem on a modern pcs i had the same issues showing how TELNET mode on these modems is causing a block to occur.

this explains why i could make a Teraterm WIFI modem to second Teraterm wif modem connection with telnet mode OFF and have no issues sending files back and forth.

as another solution i could put a Raspberry pi on the desk and connect it to the altair via serial then i could telnet into my remote Unix box and WGET files or RX SX files from the unix box to the raspberry pi then 

because it was a serial connection i could XMODEM those back to my Altair.

So if your connecting a wifi modem from your altair to your PC using Teraterm its going to be in a telnet mode and it will block your Xmodem transfer which is what pcget and pcput are using.

you would need a second wifi modem on the PC to establish a complete serial null modem link between the two machines and allow the Xmodem transfer to complete properly.

for me i have already setup a direct serial connection to my PC next to my altair i have a serial switch box where i have a Printer, wifi modem, terminal screen capture. i have my direct serial file transfer cable using a different port with

a special version of pcget and pcput i modified for higher Port numbers.

when using the wifi modem i can connect to my unix machine i just cannot transfer a file directly back from it. i use that unix machine to get on the internet with my altair and i can also view color photos from websites on my terminal.

when connecting to TELNET BBS i find the ones that are not Telnet based and then i can download and upload files as much as i want. for the Telnet BBS i can interact with door games and send messages i just cannot download files

as the wifi modem blocks. however i can get files from those telnet BBS in different ways.

well after experimenting the last few months i know understand what is happening, i have found numerous posts with this same issue on various forums and usenet groups and no body ever has a solution because there is no solution to this issue.

it is simply how the wifi modems work when in TELNET mode and how they handle collapsing 2 characters into a single character.

[Patrick Linstruth]

One thing to consider is TELNET is a protocol, like SMTP and HTTP. It get’s confusing because the “telnet” program is often used to make raw socket connections using telnet port 23.

I would think that a Wifi Modem either doesn’t need to support the TELNET protocol or have it disabled by default.

I bought a couple of Serial Wifi Adapters to experiment with. Unfortunately, the source code to the version I received (The Old Net v6.0) hasn’t been posted to Github and the author has essentially disappeared. If not careful, a firmware update will disable the DE9 port.

I also think you are correct that software expecting a modem and status signals, such as DCD, may not work. That was something I was hoping to fix if the source code was available.

Thank you for the all the effort you have put into this.

To view this discussion on the web visit https://groups.google.com/d/msgid/altair-duino/f35cffbf-cca4-4ccc-a39a-406224519b30n%40googlegroups.com.

[John Galt]

you can default the modem to turn it off. In my case my unix machine is setup for Telnet or SSH and that in itself blocks the wifi modem.

I can log right in with teraterm on my PC and send files back and forth no problem.

The issue is a Wifi modem to a telnet connection is where the block occurs.

The old net: yup same issue i have run into the Author was very easy to contact when the modem first came out now the last 1.5 years he has ghosted everyone which is really sad.

i have the firmware he sent out in 2023 in march with a build date from either January or February of 2023.

every firmware after that is garbage.

now i have gone through over 10 wifi modems: here is the scary part;

The old net wifi modem is the best of all of them hands down. even after the author ghosted everyone i would still buy another theoldnet wifi modem over anyone else.

after all my testing and crashing various modems to the point of needing to reflash them to get them working again theoldnet one is the most realiable and easiest to just reset after a crash without fear.

may of the available wifi modems are SO SO much worse. many of them just randomly drop wifi or forget their IP number and then you have constantly reset them.

its so frustrating.

I even had 2 of them i bricked just using them and no support at all when i email various people i bought from on Tindie.

this:

https://www.tindie.com/products/retrodisks/wirsa-v2-wifi-rs232-serial-modem-adapter-with-sd/

is my second best recommendation and it has ALOT of issues like to the point i would just buy the oldnet one again.

this one had lots of features and promise

https://www.tindie.com/products/8bit_bruno/simple-wifi-rs232-modem-v2/

and i bricked it completely in 2 days i can't even get it to reload firmware.

this

https://www.tindie.com/products/theoldnet/rs232-serial-wifi-modem-for-vintage-computers-v4/

was still the best out of all of them just make sure you never update the firmware.

there was one firmware update that kind of worked but it nuked the HTML access to the modem and the file server. the slight bugs it fixed were not worth it.

what sucks about all these modems that have an internal file server BBS is they only use Y or Z modem protocols.

best of the worst...

[John Galt]

oh yes and CODE wise, nobody releases there code they all point to the generic WIFI modem code on github, but they have been modified extensively in some cases and you can't even get the complied firmware.

[fridtjof.ma...@gmail.com]

John,

Never looked at these "wifi modems". Certainly not the source code. I have been aware that these devices existed. If you have a linux (freebsd, whatever -- I use linux) micro-system with serial and wifi... have my hayes project:

https://github.com/ratboy666/hayes

that will give you hayes modem emulation and NOTHING else. It can be easily extended to provide configuration -- indeed connection is just the command, so that is your configuration mechanism... give it another command ATD is "dial" -- how about AT: for configure?

Now, command line configuration of the wifi, and we are done. As well, the linux micro-system could run SLIP or PPP over serial, and normal httpd (apache), ftp whatever you want!

I do NOT do hardware -- just software, so I am not going to be making this... you may be interested, though. Licensing for hayes is MIT -- do whatever you want with it. I have been using it for a few years on my Altair-Duino (with MDM740)

Note hayes does NOT do "telnet" -- It just implements the timing base attention sequence (that hayes patented, back in the day).

hayes could implement DTR based disconnect.... I didn't bother.

-Fred 

[John Galt]

Really now that i understand what is happing the only casualty has been roll playing like its 1977/78 again.

 

no need to go in depth for a workaround when i already have multiple workarounds. 

really back to the original OP having the issue of why they could not PCGET or PCPUT to work with a wifi modem on the altair connecting to another machine.

the wifi modem has telnet mode and non-telnet mode, but when connecting over IP to the remote machine it can be miss on a PC.

i fooled around with TERATERM settings making sure to turn off telnet when connecting to the wifi modem and it still blocks.

users with MAC computers don't seem to have a problem this is because the communications software on the mac seems to compensate for the difference allowing for a file transfer to work

 where the PC is just doing things traditionally.

what i found was in order for my altair to make a WIFI modem connection to another PC or non-mac machine when  Xmodem transfer is needed I would have to have a second WIFI modem serially connected on that remote machine.

this would establish a WIFI Null modem connection that acts just like a direct serial null modem connection between the two machines and everything is happy.

this was the issue the OP was having and generating all those time outs and ACK messages.

frustratingly WIFI modems really do not act like a real modem as i found out when i setup a BBS in my office for testing. i had to make many changes to the connection routines so that it would see the handshake and even now its a little flakey

once the connection starts the software trigger that tells the BBS you have a user logging in gets confused and loops until it gets into sync once it understands there is an established connection then it works forever until you disconnect the modems.

a lot of BBS software did not have source code so you can't make changes to how they see a RING and CONNECT, thus the wifi modems will not trigger the start properly and i have seen this behavior occurring over TELNET BBS when they are running original software on vintage hardware. 

it is interesting seeing the bugs out in the wild on different BBS software now that i understand it from seeing my Home test BBS reacting to the wifi modem connection verse a real Modem connection from my Laptop.

lost technology as the world changed.

:D