XMODEM 2.7 Release :-)

[mfebe...@gmail.com]

XMODEM 2.7 fixes a bug created in 2.6, where XMODEM would misbehave when receiving a file, and no XMODEM.CFG file was present. You can download XMODEM 2.7 here:

https://drive.google.com/open?id=0B-XdfCubTNJJV2UzSWxWc0hudFU

This was a tricky bug having to do with when I move the stack into CP/M's command buffer. Thanks mbra...@gmail.com for the excellent bug report that helped me to identify and squash this bug quickly!

-Martin E.

[mbra...@gmail.com]

I downloaded the new version, it works extremely well so far. xmodem.cfg not needed.

Thanks for the quick fix!

FYI: I am getting approx 4k/sec to the RC2014 Z80 115.2k via the CON:

[Uwe Nass]

Hi,

is there a chance to get the files WITHOUT google?

Thanks,

Uwe.

[mbra...@gmail.com]

I will have them on my website tonight. I'll post a message later. I need to create some relocatable hex files before I post them for our Z80 sbc.

[mbra...@gmail.com]

I have it available here: http://web1.foxhollow.ca/cpm/xmodem/xmodem.zip

The new version works very well.
I have made a small change to work better with my RC2014 Z80 SBC.
I have changed the port defaults to /X0
That means you only need to type: xmodem filename /r

In the ZIP file, I have the newly compiled/assembled xmodem.com, xmodem.pkg which can be pasted into the command line (if using download.com on the RC2014). I have also included a xmodem.hex (relocated hex) that can be pasted and saved from the boot monitor.

I find this version to be faster than older versions, I am getting about 4k/sec on large files.

Thanks for the new release!

[mfebe...@gmail.com]

Uwe,

Just for my education, what's the issue with downloading the files from my google drive?

Thanks,
Martin

[Uwe Nass]

Hi Martin,

I have to register first!

Uwe

[mfebe...@gmail.com]

But don't you have to register with Google anyway to post on this forum?

[Udo Munk]

On Friday, October 13, 2017 at 4:35:02 PM UTC+2, mfebe...@gmail.com wrote:

> But don't you have to register with Google anyway to post on this forum?

No, one also can post into the usenet newsgroup, c.o.c isn't a
Google forum.

[mfebe...@gmail.com]

Ah. Makes perfect sense. And I totally get why someone might not want to register with Google. Any suggestions of another place "in the cloud" to post files easily?

[Axel Berger]

Udo Munk wrote:
> No, one also can post into the usenet newsgroup,

Nobody is going to follow it up today, but one can ask, whether it is
even leagl to post into Usenet from Google. I remember the time when the
first gateways were opened from e.g. the German MausNet into the quite
closed and regimented UseNet. Every UseNet group in every single BBS had
to have a MausNet moderator keeping a close look on what was posted and
how and there was a real risk of the whole BBS network getting booted
out in case of misbehaviour.
Then came AOL and Boris Becker's proficiency in getting into things --
the term Eternal September was not coined for nothing.

--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

[Udo Munk]

I finally found the time to test it with the z80pack Altair machine, using
Martin's setup for direct I/O via 2SIO B port. On the host side I'm using
the terminal program minicom and lrszs for the X/Y/Z modem file transfer.
Works nicely, I have put a disk image with the bits here, good for google
non-fans too:

http://www.autometer.de/unix4fun/z80pack/ftp/altair/

In case you are wondering why I want to use Xmodem between a VM and
the host it's running on, there are quite some disk formats in usage, not
working with cpmtools. It's the same as if you have a physical machine
but can't write disks for it from you PC, so you use serial file transfer.

[mfebe...@gmail.com]

:-) That's a pretty cool use of XMODEM that I never anticipated.

[Peter Dassow]

On 14.11.2017 at 19:34 Udo Munk wrote:
>
> In case you are wondering why I want to use Xmodem between a VM and
> the host it's running on, there are quite some disk formats in usage, not
> working with cpmtools. It's the same as if you have a physical machine
> but can't write disks for it from you PC, so you use serial file transfer.
>

So I'm curious about it - would be nice to know what disk formats are
not working with cpmtools...

[Udo Munk]

On Friday, December 1, 2017 at 8:56:16 PM UTC+1, Peter Dassow wrote:

> So I'm curious about it - would be nice to know what disk formats are
> not working with cpmtools...

The format used by the MITS 88dsk controller.
Cromemco DD and other DD formats with first track formatted SD.
Non CP/M filesystems like used by Cromix, FUZIX, where the OS can run CP/M programs.

[Peter Dassow]

Ok, MITS 88-DSK means hard sectored (32 sectors, 77tracks, 8") floppy
disks, but I thought the disk drive is (almost) identical with the IBM
3740 drive (standard 8" one), although this had only 26 sectors per
track. At least "Alien 1.4" does list up 4 different Cromenco formats,
may be an alternative for cpmtools (must be run with DOS not linux).

[Udo Munk]

On Saturday, December 2, 2017 at 10:50:11 PM UTC+1, Peter Dassow wrote:

> Ok, MITS 88-DSK means hard sectored (32 sectors, 77tracks, 8") floppy
> disks, but I thought the disk drive is (almost) identical with the IBM
> 3740 drive (standard 8" one), although this had only 26 sectors per
> track.

It uses 137 bytes sectors with 128 bytes payload and on tracks 0-5 the
sectors are different from sectors on tracks >= 6.

> At least "Alien 1.4" does list up 4 different Cromenco formats,
> may be an alternative for cpmtools (must be run with DOS not linux).

Probably the SD formats, these can be defined too for cpmstools.

[coinst...@gmail.com]

I have a curious problem with XMODEM 2.7. I have a homebrew Z80 running at 22MHz with a compact flash interface. I use XMODEM 2.7 to transfer files from my PC (running TeraTerm v4.97 at 115200-N-8-1) over USB-to-serial adapter to my homebrew Z80. The TPA of my homebrew running CP/M 2.2 is 56K. I can XMODEM transfer files smaller than 56K without any problems with the command:

xmodem file /r/c/x0/z1

If the file is greater than 56K, then the file transfer is paused at 56K while the partial file is written to CF disk and resume to completion--but only if I start the file transfer quickly. If I don't have the file ready to go in the default directory and went looking for it, then it will transfer 56K, write the partial file to CF, and resume briefly and then hang. My workaround for the last few months was getting the files ready in the default directory and starting file transfer quickly after issuing the xmodem command. That has worked perfectly, but I finally have enough experiences and curious enough to ask why how quickly I start a file transfer determines whether a large file transfer can complete successfully or hang at the first TPA file size boundary? Thanks for your help.
Bill Shen

[Tony Nicholson]

XMODEM buffers the file transfer in the free available transient program area, then when it needs to, it writes data to the destination file and pauses its protocol acknowledgement (no ACK is sent to request the next packet) for a few seconds.

I experienced the same problem on your Z280RC board and found a workaround was to reset the USB to serial device (using the Control menu Reset Port function in TeraTerm) prior to initiating a file transfer. I'd only be guessing at the root cause of this (since it's not easy to connect a serial line monitor to look at bytes flying back and forth on the console port). I suspect it is a USB serial device driver issue in Windows. It's been my experience that a lot of the non-FTDI chip serial-to-USB interfaces have issues with high baud rates when bursty serial data transfers are involved.

Also, the delay timers in XMODEM are marginal for high speed cpus. I could only manage using /Z8 to set the processor speed to 8MHz - which is what impacts the xmodem protocol time-outs if you're not swift enough initiating the transfer in TeraTerm.

Tony

[coinst...@gmail.com]

I lower the CPU clock of my homebrew Z80 to 7.37MHz and the serial baud to 38400-N-8-1. If I wait long enough before starting the file transfer, I will still encounter the same problem of transfer hanging after first 56K of data is written to CF. Lower the CPU clock and serial baud even lower to 3.68MHz and 19200-N-8-1 and the same problem is still there, if I waited long enough before start file transferring.

Everything is slowed down enough at 3.68MHz, I can start to characterize the problem. The 'waiting long enough' is interesting. I believe there are two waiting stages. First stage is a long wait where file transfer won't start until the long wait is over. The 2nd stage is short wait such that file transfer will start immediately during the 2nd stage. When xmodem command is issued, it enters the first stage of waiting, it is a long wait but eventually it will transmit a packet and which marks the beginning of 2nd stage and that's also when file transfer will start if the user has picked the file during the first stage of waiting. The file transfer will complete successfully if it is picked during the first stage of waiting. During 2nd stage of waiting, the xmodem software sends out query packet relatively frequently and file transfer will start immediately. File transfer will hang at the 1st 56K block if it is started after the query packet in the 2nd stage of waiting.

start ---------------------------------|------|xxxxx|xxxxx|xxxxx|xxxxx|xxxxx|

Here is a time line.
- means the file transfer completes OK if started during this time period
x means the file transfer hangs after 1st 56K if started during this time period
| is query packet from xmodem software


Bill

[Larry Kraemer]

Udo,
Here are some Cromemco Definitions I conjured up. Give them a test and see
if they work for you.

# CRO1 Cromemco CDOS - SSSD 48 tpi 5.25" - 128 x 18
diskdef cro1
seclen 128
tracks 40
sectrk 18
blocksize 1024
maxdir 64
skew 5
boottrk 3
os 2.2
end

[cro1]
description = CRO1 Cromemco CDOS - SSSD 48 tpi 5.25" - 128 x 18
cylinders = 40
heads = 1
secsize = 128
sectors = 18
secbase = 1
datarate = SD


# CRO2 Cromemco CDOS - DSSD 48 tpi 5.25" - 128 x 18
diskdef cro2
seclen 128
tracks 80
sectrk 18
blocksize 1024
maxdir 64
skew 5
boottrk 3
os 2.2
end

[cro2]
description = CRO2 Cromemco CDOS - DSSD 48 tpi 5.25" - 128 x 18
sides = alt
cylinders = 80
heads = 2
secsize = 128
sectors = 18
secbase = 1
datarate = SD


# CRO3 Cromemco CDOS - SSDD 48 tpi 5.25" - 512 x 10
diskdef cro3
seclen 512
tracks 40
sectrk 10
blocksize 1024
maxdir 64
skew 4
boottrk 2
os 2.2
end

[cro3]
description = CRO3 Cromemco CDOS - SSDD 48 tpi 5.25" - 512 x 10
cylinders = 40
heads = 1
secsize = 512
sectors = 10
secbase = 1
datarate = DD


# CRO4 Cromemco CDOS - DSDD 48 tpi 5.25" - 512 x 10
diskdef cro4
seclen 512
tracks 80
sectrk 10
blocksize 2048
maxdir 128
skew 4
boottrk 2
os 2.2
end

[cro4]
description = CRO4 Cromemco CDOS - DSDD 48 tpi 5.25" - 512 x 10
sides = alt
cylinders = 80
heads = 2
secsize = 512
sectors = 10
secbase = 1
datarate = DD


# CRO5 Cromemco CDOS - DSDD 8" - 512 x 16
diskdef cro5
seclen 512
tracks 154
sectrk 16
blocksize 2048
maxdir 256
skew 11
boottrk 2
os 2.2
end

[cro5]
description = CRO5 Cromemco CDOS - DSDD 8" - 512 x 16
sides = alt
cylinders = 154
heads = 2
secsize = 512
sectors = 16
secbase = 1
datarate = ED


# CRO6 Cromemco CP/M - SSDD 48 tpi 5.25" - 512 x 10
diskdef cro6
seclen 512
tracks 40
sectrk 10
blocksize 2048
maxdir 128
skew 3
boottrk 2
os 2.2
end

[cro6]
description = CRO6 Cromemco CP/M - SSDD 48 tpi 5.25" - 512 x 10
cylinders = 40
heads = 1
secsize = 512
sectors = 10
secbase = 1
datarate = DD


# CRO7 Cromemco CP/M - DSDD 48 tpi 5.25" - 512 x 10
diskdef cro7
seclen 512
tracks 80
sectrk 10
blocksize 2048
maxdir 128
skew 3
boottrk 2
os 2.2
end

[cro7]
description = CRO7 Cromemco CP/M - DSDD 48 tpi 5.25" - 512 x 10
sides = alt
cylinders = 80
heads = 2
secsize = 512
sectors = 10
secbase = 1
datarate = DD


As for the Cromemco DD and other DD formats with first track formatted SD, I have a quick work around that allows me to access the files. Here is what I do.

I run the following command to get a .RAW file from the .IMD file.

IMDU WSMMSSDB.IMD WSMMSSDB.RAW /B /E /D >> WSMMSSDB.TXT

The .TXT file contains:

IMageDisk Utility 1.18 / Mar 07 2012
IMD 1.02: 6/08/2005 12:28:41

Working Copy (installed) CP/M 86, pip, stat

WordStar MailMerge SpellStar dBASE II

The .TXT file shows the first track as SD:

Assuming 1:1 for Binary output
0/0 500 kbps SD 26x128 = 3328 = 0x0D00
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
D D D D D00D00D00D00D D D D D D D D D D D D D D D D D D
0/1 500 kbps DD 26x256 = 6656 = 0x1A00
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
D D D D D D D D D D D D00D00D D D D D D D D D D D D D
1/0 D DE5DE5D DE5DE5D DE5DE5D DE5DE5D DE5DE5D DE5DE5D DE5DE5DE5DE5DE5DE5DE5
1/1 DE5D D DE5D D DE5D D DE5D D DE5D D DE5D D D D D D D D D D
2/0 D D D D D D D D D D D D D D D D D D D D D D D D D D
2/1 D D D D D D D D D D D D D D D D D D D D D D D D D D

I skip the first 3328 bytes and copy the 6656 bytes of Track 0B to a file named TRACK0B.RAW

dd if=WSMMSSDB.RAW bs=1 skip=3328 count=6656 of=TRACK0B.RAW

Then make a modified M*.RAW file.

cp TRACK0B.RAW MWSMMSSDB.RAW
dd if=WSMMSSDB.RAW bs=1 skip=3328 seek=6656 of=MWSMMSSDB.RAW conv=notrunc

At this point I use HEXEDIT (in Linux - Debian) and locate the Directory
Starting address in HEX. If it isn't at the correct location for the number of Boot Tracks, I use offset 9984 (in Decimal) and bootrk 0

# NECC NEC APC CP/M-86 - DSHD 8" - 256 x 26
diskdef necc
seclen 256
tracks 154
sectrk 26
blocksize 2048
maxdir 256
# skew 3
boottrk 0
# 0x2700
offset 9984
os 2.2
end

Now cpmtools can access the files in the CP/M Image.

cpmls -f necc -D MWSMMSSDB.RAW
Name Bytes Recs Attr update create
------------ ------ ------ ---- ----------------- -----------------
CPM .BAK 28K 222
CPM .SAV 28K 222
CPM .SYS 28K 222
L . 2K 1
MAILMRGE.OVR 12K 90
PIP .CMD 8K 59
SPELSTAR.DCT 96K 758
SPELSTAR.OVR 24K 181
STAT .CMD 10K 73
WINSTALL.CMD 40K 306
WS .CMD 22K 170
WS .INS 56K 443
WSMSGS .OVR 30K 227
WSOVLY1 .OVR 42K 322
WSU .CMD 22K 170
15 Files occupying 448K, 544K Free.

Thanks.

Larry

[coinst...@gmail.com]

Udo's comment of 11/14/17 is how I use XMODEM for my homebrew Z80. I use a command in my Z80 monitor to format a new CF disk; convert XMODEM.COM to Intel Hex format with an offset of 0x100; send XMODEM.HEX file to Z80; boot up CP/M; issue a 'save 17 XMODEM.COM' to create the first file on the new CF disk; then use XMODEM to bring in 'unarj.com' and the rest of CP/M executables that was compressed with 'arj.exe'. Sounds complicated, but it is very quick. I only find out later that there are tool to format CF disk on PC and transfer disk image created with cpmtools to the CF. I still haven't use that method because XMODEM is so efficient.
Bill

[Richard Deane]

Does anyone have an example set of data for xmodem.cfg to work with RC2014 and Z80SBC (using LiNC80 CP/M) with Zilog SIO/2 chip (i.e. not working via CP/M console routines

I have Tom's z80sbc setup working with serial io but cannot get xmodem to work to CRT (/X0) which I assume is to Console bios or bdos routines so I thought I'd try hitting Zilog SIO/2 direct. Is that possible or will it break subsequent CP/M console access?

I'm working at 115200,8,N,1 and have tried various USB-TTL serial devices (FTDI and CP2104) all of which work fine to support CP/M console, just not working with Xmodem.

Richard