Loading ...
Sorry, an error occurred while loading the content.

Re: CP/M HEX file question

Expand Messages
  • W Tom
    Marten, I guess I could check to see if BSTAM is older than Modem, but BSTAM is obscure and I think got started with Micro to Mainframe synchronous transfer. I
    Message 1 of 41 , Jul 19, 2013
    • 0 Attachment
      Marten,

      I guess I could check to see if BSTAM is older than Modem, but BSTAM is obscure and I think got started with Micro to Mainframe synchronous transfer. I mention it because it does work and I have a configuration for MITS and Vector Graphic. This program part of microcomputer history and I think it should be preserved.


      > The XMODEM protocol is the original serial transfer protocol with 128-byte checksummed blocks, and ACK/NACK handshaking. This was written by Ward Christensen in 1977, as the transfer protocol for his MODEM program - you can read about it on Wikipedia:
      >
      > http://en.wikipedia.org/wiki/XMODEM

      I'll read WikiPedia. I got my information and some software directly from Ward Christensen. More information came from using and operating RCPMs.

      > All these other protocols (Kermit, XMODEM-CRC, MODEM7, YMODEM, ZMODEM, etc.) are derivatives of XMODEM, meant to solve various issues. The write-ups for these protocols on Wikipedia are pretty good.

      Too bad Wikipedia was not around in 1977. I had to use the source code comments and communicate with users and authors on a BBS. The protocols solved issues. The programs that implemented them had other features that improved over time.

      > The XMODEM protocol does not care which port you use. It can be implemented on the console port, another serial port, an internal modem, whatever. Different implementations of XMODEM programs have implemented this protocol in various ways, but the data transfer between them are all compatible.

      The protocol does not care, but the user and programs do. Most early RCPMs used a PMMI or later a Hayes S-100 modem. Xmodem would use the the modem port. The Console port was different and was mirrored on the modem port by BYE.

      Modem, Modem7, Mex, and other Terminal programs interfaced to the user on the Console and transfered files on the Modem port. These programs were intended for local use. Xmodem was intended for remote use in combination with BYE.

      > Hyperterm (on the PC) does indeed implement XMODEM-CRC, as well as the original checksum error checking. Hyperterm automatically detects whether the other end is CRC-capable, and uses checksums if not.

      OK, what about Batch Transfers? Type  XMODEM SB C:*.* on a remote system. Which Windows program can receive the files sent?

      >My XMODEM program implements both checksumming and CRC, and works perfectly with Hyperterm in either mode. It is really easy to use, even without menues, etc. To receive a file, you'd type on the CP/M console:

      Different syntax for switches than the original XMODEM.

      My version of XMODEM was used on my RCPM. I'm curious about newer versions but don't want to write one. I do CP/M to CP/M transfers in the style used on an RCPM.


      > I like (and recommend) the XMODEM protocol because of its simplicity and universality. True, some of the other protocols are higher-performance, but honestly, who cares about a few percentage points of performance improvement when we are dealing with trailing-edge technology anyway? We need something that just works reliably.

      I use a version of a program that supports CRC and Batch transfers. I won't use the XMODEM program until I set up an RCPM.  I can't XMODEM for everything, because it is special purpose and lacks features. Marten talks about protocols and I talk about programs. Program protocols vary with program version and age. I recommend Modem7, MDM7xx, and MEX programs. KERMIT is good because of the number of systems it supports. 

      >True, some of the other protocols are higher-performance, but honestly, who cares about a few percentage points of performance improvement when we are dealing with trailing-edge technology anyway? We need something that just works reliably.

      Some of us are interested trailing-edge software technology. The old programs were reliable over bad phone lines. I now transfer over Ethernet. I'm curious how YMODEM and ZMODEM compare to XMODEM on the Internet. I like Modem7, but want to learn features of MDM7xx and MEX.

      I'll look at a newer (20th century) XMODEM program after I get a version of BYE Running. I'll look at MDM7xx programs too, but MODEM 7.12 works fine with an XMODEM program, but has more features.

      My point is don't confuse protocol with program name and version matters. New programs can implement old protocols, but some old programs work good. PC operation and boot disk creation creation is different from using an RCPM.

      W. Tom S.







      --- In altaircomputerclub@yahoogroups.com, "mfeberhard" wrote:
      >
      > Tom,
      >
      > The XMODEM protocol is the original serial transfer protocol with 128-byte checksummed blocks, and ACK/NACK handshaking. This was written by Ward Christensen in 1977, as the transfer protocol for his MODEM program - you can read about it on Wikipedia:
      >
      > http://en.wikipedia.org/wiki/XMODEM
      >
      > I had the pleasure of using the XMODEM protocol in its earliest implementation when I was accessing the CACHE BBS, the Chicago Area Computer Hobbyist Exchange's bulletin board. (I believe this was the first public use of XMODEM.)
      >
      > All these other protocols (Kermit, XMODEM-CRC, MODEM7, YMODEM, ZMODEM, etc.) are derivatives of XMODEM, meant to solve various issues. The write-ups for these protocols on Wikipedia are pretty good.
      >
      > The XMODEM protocol does not care which port you use. It can be implemented on the console port, another serial port, an internal modem, whatever. Different implementations of XMODEM programs have implemented this protocol in various ways, but the data transfer between them are all compatible.
      >
      > The XMODEM CRC enhancement was written by John Byrnes, and was meant to improve reliability. it's a simple enhancement to XMODEM, that (when implemented correctly) is backward-compatible with plain XMODEM implementations that only support checksumming.
      >
      > Hyperterm (on the PC) does indeed implement XMODEM-CRC, as well as the original checksum error checking. Hyperterm automatically detects whether the other end is CRC-capable, and uses checksums if not.
      >
      > My XMODEM program implements both checksumming and CRC, and works perfectly with Hyperterm in either mode. It is really easy to use, even without menues, etc. To receive a file, you'd type on the CP/M console:
      >
      > XMODEM /R
      >
      > to send a file, you'd type
      >
      > XMODEM /S
      >
      > I like (and recommend) the XMODEM protocol because of its simplicity and universality. True, some of the other protocols are higher-performance, but honestly, who cares about a few percentage points of performance improvement when we are dealing with trailing-edge technology anyway? We need something that just works reliably.
      >
      > -Martin
      >
      >
      > --- In altaircomputerclub@yahoogroups.com, "W Tom" yahoo@ wrote:
      > >
      > > I haven't used the new transfer programs much, because the old ones work
      > > fine. One problem is that newer programs have less features.
      > >
      > > One of the oldest products is BSTAM. This commercial product is old. I
      > > have versions for MITS and Vector Graphic. I used this program to get
      > > started because it was the first on I got on a MITS format diskette.
      > >
      > > The MODEM program used the "XMODEM" protocol before XMODEM was written,
      > > so the MODEM protocol and the XMODEM protocol are the same. Both
      > > programs used Checksums in the protocol and are obsolete. Modem
      > > protocol or XModem protocol is ambiguous because the protocol evolved.
      > >
      > > The MODEM program was designed to be operated through the Console port
      > > and transfers were done a second port. The Xmodem program was designed
      > > for an RCPM where the Console was mirrored on the transfer port.
      > >
      > > Modem was desiged as a terminal program the gave commands to Xmodem on a
      > > different system. Xmodem performed a transfer without output to the
      > > console. Modem could output to the console because the Console and
      > > transfer ports were different.
      > >
      > > Modem7 was an enhanced Modem with a menu, batch transfers, and CRC
      > > checks. XMODEM was enhanced to add Modem 7 protocol features. Part of
      > > the confusion is that protocol enhancements were added to Modem before
      > > Xmodem. Whether you call it Modem or Xmodem Protocol, the protocol
      > > changed over time. Program version is important and program names can be
      > > confused with the protocols supported. I'm using Xmodem-CRC over the
      > > internet and would like to benchmark it and compare to YMODEM and
      > > Zmodem.
      > >
      > > In the modern world the Xmodem protocol may be discussed without knowing
      > > if CRC checking and Batch transfers are supported. Later protocol
      > > enhancements changed block size to improve performance. YModem Protocol
      > > was optimized for 1200 BPS and ZModem was another enhancements.
      > >
      > > I have the Modem7 program on MITS and Vector Graphic format. The problem
      > > is that HyperTerm and the new protocols don't support CRC and Batch
      > > transfer.
      > >
      > > Modem7 evolved to MDM7xx and provided overlays to configure for
      > > different modems and IO chips. Overlays are useful, but by the time they
      > > evolved, Motorola 6850 support was outdated.
      > >
      > > Modem7 evolved to the MEX product (Modem Executive). This version was
      > > ported to MSDOS. I have MEX in Altair format.
      > >
      > > MODEM7, MDM7xx, and MEX work good, but Windows programs lack support. I
      > > have KERMIT in MITS and Vector Graphic configurations and format and use
      > > KERMIT for batch transfers.
      > >
      > > The newer programs are small and simple to get started bootstrapping a
      > > system. The first thing I would do is transfer Modem7 and Kermit. MEX is
      > > next. XMODEM would be later.
      > >
      > > On the PC side, I'm thinking maybe a MSDOS Virtual Machine and Procomm
      > > Plus. PCTalk should work too.
      > >
      > > W. Tom S.
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > > --- In altaircomputerclub@yahoogroups.com, "mfeberhard" wrote:
      > > >
      > > > I have used Mike's PCPUT and PCGET programs, and they are excellent.
      > > His way of bootstrapping works very well.
      > > >
      > > > (You could even use PCGET to load the source code for my Xmodem
      > > program :-) )
      > > >
      > > > -Martin E
      > > >
      > > > --- In altaircomputerclub@yahoogroups.com, "deramp5113" deramp5113@
      > > wrote:
      > > > >
      > > > > Theo,
      > > > >
      > > > > I agree with Martin, use XMODEM to transfer any CP/M file you find
      > > on the internet into your Altair over a serial port. This operation
      > > writes the file to your APE disk drive.
      > > > >
      > > > > I have a ready to run CP/M program for doing just this if your
      > > serial board is a 2SIO board. The program PCGET retrieves any files from
      > > a PC into a CP/M machine using the XMODEM protocol. For example, typing:
      > > > >
      > > > > A>PCGET DEMO.COM
      > > > >
      > > > > Prompts you to start an XMODEM send operation on your terminal
      > > emulator. The file comes in over the same serial port you are using for
      > > the console and is written to the CP/M disk file "DEMO.COM"
      > > > >
      > > > > But... how do you get PCGET.COM onto your computer to begin with? I
      > > posted instructions for doing this in the "PCGET and PCPUT" folder in
      > > the files section:
      > > > >
      > > > > "Files > Burcon (MITS) CPM > PCGET and PCPUT"
      > > > >
      > > > > Mike
      > > > >
      > > > >
      > > > > --- In altaircomputerclub@yahoogroups.com, "tkaragiris" wrote:
      > > > > >
      > > > > > Is there a way that a hex dump created using the CP/M dump utility
      > > can be converted back into a .com file?
      > > > > >
      > > > > > I use the APE emulator to run CP/M on my Altair, but unfortunately
      > > there aren't many usable applications in APE. It would be great to have
      > > some method of importing files from other CP/M disks.
      > > > > >
      > > > >
      > > >
      > >
      >
    • tkaragiris
      Here s an update on the APE project posted by Frank on the VCF:
      Message 41 of 41 , Aug 8, 2013
      • 0 Attachment
      Your message has been successfully submitted and would be delivered to recipients shortly.