anyway to let TeraTerm pad the last xmodem packet with 0xFF?

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I found out that TT will pad the last Xmodem-CRC packet with 0x1A.
hehe, I just became a little bit picky here, is there anyway to change TT to make it pad 0xFF instead?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of course, the TT source is freely available so you could modify it to do whatever you like. Having said that I'll bet the 0x1A is a single byte in the .EXE and by simply editing the .EXE you might be able to make the mod without even needing to rebuild.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

what software should I use to edit .exe file?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found the source file of TT pro 2.3 from:
http://cvs.sourceforge.jp/cgi-bi...

and found the code for padding 0x1A:

Quote:

[SOURCE\TTFILE] -- source files of TT(P)FILE.DLL
BPLUS.C/H B-Plus protocol
FTLIB.C/H Routines for file transfer
KERMIT.C/H Kermit protocol
QUICKVAN.C/H Quick-VAN protocol
TTFILE.C Main
XMODEM.C/H XMODEM protocol
ZMODEM.C/H ZMODEM protocol
FILE_RES.H Resource IDs (32-bit)
FILE_R16.H Resource IDs (16-bit)

Then I should install a MS-Visual C/C++ and remake the executable code, right?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

darthvader wrote:
Hi,

I found out that TT will pad the last Xmodem-CRC packet with 0x1A.
hehe, I just became a little bit picky here, is there anyway to change TT to make it pad 0xFF instead?

From http://en.wikipedia.org/wiki/XMODEM:

Quote:

The padding was originally the SUB character (called CPMEOF in the standard) which has value of 26 decimal. But the padding is actually allowed to contain anything according to the standard. This is necessary because the length of the file is not transmitted. If the receiver has no way how to determine that the file has ended, he's going to continue interpreting the padding. So the sender constructs the padding in a way that it's harmless for the used interpretation.

From the above, 0x1f=26d.

Why would you want to change a working de-facto standard protocol? Then you cannot use any other XMODEM software to upload your stuff. And then you must create your own upload software.

There already is a non-standard modification of XMODEM where the first packet to be sent is not 1 but 0, and it includes file name and stuff.

I would create the data I send with XMODEM so that the first thing to be sent is how many bytes there are in a transmission, so we can stop at the padding.

I'd even make the first 128 bytes (a whole packet) of file data as a header, which could include anything, like how many bytes will follow, the data file version or comments or some unlocking magic numbers if it is going to be flashed into code memory or something.

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, Jani, I send out compiled bin file through bootloader code to my Rx flash, and it's safer to pad the last packet with 0xFF rather than 0x1A. Of course, it's not a big deal, but you know, it feels safer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not have the terminal send the exact byte length simply as ASCII digits before it initiates the Xmodem protocol, that way you'd know how many bytes (presumably all 0x1As) to ignore before you start

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But, Cliff, can Xmodem-CRC protocol send out the length of the file?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

darthvader wrote:
But, Cliff, can Xmodem-CRC protocol send out the length of the file?

No.

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

darthvader wrote:
Hi, Jani, I send out compiled bin file through bootloader code to my Rx flash, and it's safer to pad the last packet with 0xFF rather than 0x1A. Of course, it's not a big deal, but you know, it feels safer.

Alright, then I have a solution for you:

Can you add 0xFF padding to the binary file to make the file size a multiple of 128?

I mean, if you program these padding bits anyway to the memory, you could just increase the binary size, instead of letting the protocol handle the padding.

In any case, whether you pad the data at file or the protocol level, be sure that you don't for example start programming 10 bytes at address 0xffff or anything like that would cause the memory addresses to wrap or write over boot loader code or something.

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, Jani, padding the bin file directly is also an option, but can you tell me how?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have downloaded and installed the free Microsoft Visual C++ 2005 Express Edition and tried to build exe from source code of TT 2.3, then I got a lot of errors for not finding the include files like:windows.h, afxwin.h, winsock2.h, stdafx.h. Any one knows where to set the correct path for these files in VC++ 2005?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I also niticed that this source file said it needs

Quote:

Microsoft Visual Studio 8\Common7\IDE\vc7\crt
Microsoft Visual Studio 8\Common7\IDE\vc7\atlmfc

as path for its debug source files, but I can't find these folders in this VC++ 2005 express edition, should I find a full edition?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

darthvader wrote:
Hi, Jani, padding the bin file directly is also an option, but can you tell me how?

There are numerous ways, and all of them are propably easier than trying to compile TeraTerm :)

So this is binary data file (.bin) instead of hex data file (.hex)?

There must be a way how to convince compiler or linker to generate the padding. This way, when the binary file comes out of the compiler, it already is padded.

If you find no way of doing this (like linking a table of 0xff bytes into the end of the code segment, you can use C code or Perl or maybe even DOS/Unix tools to do this postprocessing in makefile.

I'd propably write C code to open the file, examine file size, and if file size modulo 128 is nonzero, I'd write 128-(size modulo 128) bytes more and close the file.

- Jani