Announcement

Collapse

Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

Xmodem CRC16 for 8080/Z80 CP/M file Transfer

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Xmodem CRC16 for 8080/Z80 CP/M file Transfer

    Greetings,

    I hope this information is not old. I searched the forum and didn't find anything on Xmodem - I hope I didn't miss something.

    I have had success with using Xmodem CRC16 for transferring files in and out of my Imsai 8080 which works nicely for acquiring files from and backing up to the outside world. Previously I tried PIP and found it to be very slow requiring the injection of character and line delays. To acquire a large source listing file I found I needed to break the file up into chunks small enough to fit into the buffer as otherwise data was lost during disk write cycles. This required patching the source code back together with my favorite CP/M line editor. The PIP process was prone to error and I couldn't figure out how to use it for binary file transfers.

    For Xmodem I am using a 9600 Baud port and the transfer throughput runs around 6 KB/S. It interfaces with Windows XP Hyperterminal quite nicely. I have transferred a number of files and have not noticed any errors. I transferred a COM file out and then back in again and it still ran OK on the Imsai.

    I found this news group post describing an Xmodem source listing for 8080/Z80 CP/M machines:

    https://groups.google.com/forum/#!to...pm/1EdJzNh1ekM

    The source listing looked very professional to me so I decided to try and get it to run on my Imsai. I decided direct communications to the port would be better than passing data via CP/M using the PUNCH/READER API. This required modifying the source listing a little with simple IO interface routines with the appropriate port status and data bus addresses. Sample interface routines were given in the source code comments which made this process easy. The most difficult part for me after I managed to get the source code loaded into the Imsai was re-learning how to use the line editor and CP/M assembler tools (it has been over 35 years since I did this, (:/))). Getting the source listing fixed back up with the characters that were lost during the PIP file transfer required a few re-assembler cycles. The Xmodem source listing can be found here:

    https://docs.google.com/file/d/0B-Xd...it?usp=sharing


    A special thanks goes to Martin Eberhard for his good work and for posting this source code!

    Best Regards,
    tma

    #2
    Martin has updated his XMODEM utility since the version you referenced in your post. Now, a parameter file (plain text file) configures XMODEM at run-time to work with most any serial port configuration you could have. This means you don't have to edit or assemble the original source file to make XMODEM work on different hardware configurations.

    Here's a link to the new version: http://deramp.com/downloads/index.ph...re%2Fxmodem%2F

    Mike

    Comment


      #3
      Greetings Mike,

      Many thanks for bringing this update to my attention! I have downloaded the later version.

      As you stated it appears the cfg file could match most any serial port. In my case the dual-serial/dual-parallel port card is by Solid State Music. With it the Baud rate and data parameters are set via hardware strapping options thus all I should need to do is update the cfg file /P option with port numbers and ready status mask info. This would have saved me some effort but I must admit I had fun re-learning how to edit and assemble under CP/M. The extra time spent provided a useful refresher.

      The most difficult effort was getting the source file loaded into the IMSAI. As mentioned above I needed to split the source code up to fit into the IMSAI PIP RAM buffer then patch it back together. I broke it down into four files then I used a powerful freeware Windows terminal program called RealTerm to transfer it in via PIP. RealTerm permits one to insert character and end-of-line delays. I used 10mS character and 15mS end-of-line delays which reduced the 9600 Baud port throughput down by about 10 times. Even at this slow rate a few characters were still dropped during the transfer. But the files were easy to fix up with the CP/M editor. Now that I have Xmodem working it will be simple to transfer the updated version into the IMSAI. It is very easy to do now when running Xmodem. This file transfer ability reward was certainly worth the effort!

      Thanks Again,
      tma




      Originally posted by deramp5113 View Post
      Martin has updated his XMODEM utility since the version you referenced in your post. Now, a parameter file (plain text file) configures XMODEM at run-time to work with most any serial port configuration you could have. This means you don't have to edit or assemble the original source file to make XMODEM work on different hardware configurations.

      Here's a link to the new version: http://deramp.com/downloads/index.ph...re%2Fxmodem%2F

      Mike
      Originally posted by deramp5113 View Post
      Martin has updated his XMODEM utility since the version you referenced in your post. Now, a parameter file (plain text file) configures XMODEM at run-time to work with most any serial port configuration you could have. This means you don't have to edit or assemble the original source file to make XMODEM work on different hardware configurations.

      Here's a link to the new version: http://deramp.com/downloads/index.ph...re%2Fxmodem%2F

      Mike

      Comment


        #4
        I have written numerous versions of two programs, PCGET and PCPUT, for a wide variety of serial boards. These are essentially XMODEM pre-configured to receive a file from a PC (PCGET) or write a file to a PC (PCPUT). What serial board are you using in your IMSAI?

        Mike

        Comment


          #5
          Hi Mike,

          My IMSAI IO board was a kit from Solid State Music, if I recall correctly it is a model IO4. It provides two RS232 serial ports and two parallel ports. As mentioned above the Baud rate and data settings for the serial ports are hardware selected via wired strapping options.

          Nice to hear that there are alternative Xmodem protocol file transfer CP/M programs. The single Xmodem.com application I mentioned here will do file transfers in either direction using either CRC16 or checksum modes as determined by command line switches. I have the impression that your PCGET and PCPUT programs provide the equivalent functionality. Great stuff!

          Many thanks!
          tma



          Originally posted by deramp5113 View Post
          I have written numerous versions of two programs, PCGET and PCPUT, for a wide variety of serial boards. These are essentially XMODEM pre-configured to receive a file from a PC (PCGET) or write a file to a PC (PCPUT). What serial board are you using in your IMSAI?

          Mike

          Comment


            #6
            getting /X0 to work on receive?

            Originally posted by tma View Post
            As you stated it appears the cfg file could match most any serial port.
            I'm trying to get this to work with CP/M running on a custom Z80 kit from http://cpuville.com/computer_details.html

            I can SEND files using the console's serial port with 'xmodem <filename> /X0 /Q /S', but when I try to RECEIVE a file, I'm running into an issue... I start the transfer, then go to my terminal software's send, but it just sits there waiting for the receiver to start.

            Looking up the XModem protocol, I see the transfer is controlled by the receiver... and that the receiver should sit there, sending an ASCII 'c' every three seconds until the sender acknowledges, but this software only sends the 'c' once (and much more quickly than I can select the file to send on my end). It also only seems to send the 'c' when I'm not in quiet mode, but I'm not sure thats actually an issue or not.

            Has anyone successfully used this to receive files from a console serial port, or have I found a legit bug?

            Thanks,

            -db

            Comment


              #7
              Originally posted by bokmann View Post
              I'm trying to get this to work with CP/M running on a custom Z80 kit from http://cpuville.com/computer_details.html

              I can SEND files using the console's serial port with 'xmodem <filename> /X0 /Q /S', but when I try to RECEIVE a file, I'm running into an issue... I start the transfer, then go to my terminal software's send, but it just sits there waiting for the receiver to start.

              Looking up the XModem protocol, I see the transfer is controlled by the receiver... and that the receiver should sit there, sending an ASCII 'c' every three seconds until the sender acknowledges, but this software only sends the 'c' once (and much more quickly than I can select the file to send on my end). It also only seems to send the 'c' when I'm not in quiet mode, but I'm not sure thats actually an issue or not.

              Has anyone successfully used this to receive files from a console serial port, or have I found a legit bug?

              Thanks,

              -db
              Xmodem is OK but by far the best way to transfer via serial ports is move-it.

              Move-it runs on CP/M 80, CP/M 86, and DOS.

              It has a bit of the flavor of FTP, you can get local or remote directory - even a way to auto start a remote CP/M program (by xfering a $$$.sub file).

              Move-it has multiple sites with it available as well as the manual.

              http://maben.homeip.net/static/s100/...olf/index.html


              PS I always used a console port to capture a hexified version then use load filename.hex to convert back to binary to do the initial xfer to the target site.



              Randy

              Comment


                #8
                In general, it is best to set up a config file and use direct port I/O (X2 option) since there is a very good chance that the console input routine in your BIOS strips the msbit and XMODEM requires 8 bit transfers. Although, I don't believe this would cause the not-starting symptom you're seeing.

                Which version of XMODEM did you download?

                Mike

                Comment


                  #9
                  Originally posted by deramp5113 View Post
                  Martin has updated his XMODEM utility since the version you referenced in your post. Now, a parameter file (plain text file) configures XMODEM at run-time to work with most any serial port configuration you could have. This means you don't have to edit or assemble the original source file to make XMODEM work on different hardware configurations.

                  Here's a link to the new version: http://deramp.com/downloads/index.ph...re%2Fxmodem%2F

                  Mike
                  Here is an updated link to the XMODEM program mentioned: http://deramp.com/downloads/misc/software/xmodem/

                  Mike

                  Comment


                    #10
                    The new link is here: http://deramp.com/downloads/misc_software/xmodem/

                    Comment


                      #11
                      I realize this is from a few years ago, but the link to Move-it is no longer alive. Anyone have a link for the msdos move-it program?

                      - Gary

                      Originally posted by Randy McLaughlin View Post
                      Xmodem is OK but by far the best way to transfer via serial ports is move-it.

                      Move-it runs on CP/M 80, CP/M 86, and DOS.

                      It has a bit of the flavor of FTP, you can get local or remote directory - even a way to auto start a remote CP/M program (by xfering a $$$.sub file).

                      Move-it has multiple sites with it available as well as the manual.

                      http://maben.homeip.net/static/s100/...olf/index.html


                      PS I always used a console port to capture a hexified version then use load filename.hex to convert back to binary to do the initial xfer to the target site.



                      Randy

                      Comment

                      Working...
                      X