download.com not downloading

[craigm...@gmail.com]

I have a SC108, SC110, as well as the "Compact Flash Module for CP/M RC2014 Computer" by RFC2795 Ltd all connected via a SC112 backplane.  As far as I can tell, if I want CP/M running on this setup, I need the CP/M-B package.

It looks like the CF format SCM app along with the PutSys app work, because I can get into CP/M with what appears to be an empty drive A:.

I attempted to run the Install Download app. The "SAVE 2 DOWNLOAD.COM" command saves something to the drive.  But whenever I try uploading any of the .txt package files while in CP/M, it is acting as if download.com is locking up.  I see some hex output to screen in the upload popup, and no other files are created.  BTW, I am on a Linux system running minicom.

Any idea what may be going wrong?

Thanks,
Craig

[Steve Cousins]

Do you have hardware (rts/cts) flow control enabled?

[lordha...@gmail.com]

Might help: try running in Tera Term @9600 1ms delay 50ms line delay.  (set to 9600 using BAUD 1 $96 command)

cheers...

[Steve Cousins]

With that combination of hardware and my latest CP/M package you should be able to rely on the hardware flow control to prevent overflows with DOWNLOAD.COM

The above suggestion to use a slower baud rate and added delays will help identify if the fast speed is failing due to handshaking issues.

SCM does not need handshaking as it can keep up with 115k baud but CP/M can't. Thus the observed issue once you start using DOWNLOAD.COM could be explained by a flow control issue even though downloading to SCM works fine.

Steve

[craigm...@gmail.com]

I am using hardware flow control.  I will try reducing the speed down to 9600.

Also, I saw somewhere on this forum, that you can press 0's over and over when running download.com and it errors out.  I am not seeing that.  Download.com appears to be just locked up.

Thanks,

Craig

[craigm...@gmail.com]

I also have an SC114.  I connected the CF reader card to it and am able to get download.com to work on it using the CPM-A package.  So this tells me that the CF card reader is working.

[Steve Cousins]

I just downloaded the CP/M-B package and recreated Craig's system. I also had the same symptoms until I moved the modules about on the backplane.

I moved the modules so I was not using any of the same backplane sockets (just in case one is dodgy) and grouped the modules close together in a different order. Processor (SC108), Serial (SC110), CF (RC2014 from RFC2795 Ltd) was the order I happened to select. All okay now.

I also had similar problems when I used the RC2014 SIO module from RFC2795 Ltd instead of SC110. I didn't try a different processor module.

I seem to remember once doing a lot of moving modules around and "proved" that the CF module can interfere with the SIO. 

The proximity of the CF module to the processor module is known to be critical, sometimes!

Steve

[lordha...@gmail.com]

Sorry to hiijack this thread but my SC111 kit (using CPM-D) has similar issues of locking up, but since dropping speeds I get "======File Length Error======" on just about everything I try and download (using DOWNLOAD)... progress? I guess?

I did move my cards around but I will do some more reshuffling.

Andy

[lordha...@gmail.com]

Just moved all cards.  Definitely something weird happening now - I ran a DOWNLOAD.COM text package (hitchhikers) and after a few seconds of downloading it reboots my machine! 

Does it matter which "end" of the bus I plug into? I was previously populating the cards close to the reset button.

[lordha...@gmail.com]

Tried a few more moves. I tried 115200 with CTS/RTS.  Delays, no delays.  I tried 38k and 9600.  Hangs after a few minutes of uploading.  Tried again at 4800 (yes you read that right!) and .... success downloading. Not sure what all this means but anyway.... cheers!

[Steve Cousins]

Andy, I've just reproduced your setup.

I have SC111 + SC119 + RC2014 CF module, all on an SC112 backplane. For the purpose of these tests, I powered the system from the USB to serial adapter.

The modules are all grouped together in the order: SC119, SC111, CF

All is well when at the PSU end of the backplane and also in the middle of the backplane. I was surprised to find it wasn't reliable at the other end of the backplane, but I'm not convinced that is due to the distance from the unused PSU. My cards and backplane get a lot of abuse so it may just be mechanical issues. I may experiment further to test this theory.

It also fails if I put the CF and processor modules at one end of the backplane and the memory module at the other. Again this could just my backplane getting worn out and becoming unreliable. Time to make up a new one perhaps.

Don't also forget that some CF cards work better than others, and some don't work at all.

Conclusion: 

It is well known in our community that directly connecting a CompactFlash card to the Z80 family bus is less than perfect. There are issues like timing and ground bounce that make the whole thing a bit marginal. When you have a cooperative CF card and the modules are placed in optimum positions it can be perfectly reliable and provide you with fast storage. Defining optimal positions is problematic.

Some CF modules, such as Karl's (karlab) later designs have additional circuitry to help with these issues. The more reliable method is the parallel port IDE design, often called the hard drive module. This fixes the timing issues, helps with ground bounce, and isolates the CF data bus from the processor data bus. However, this provides slower storage as the data and control signals are generated by software rather than the processor's bus timing. It is also worth noting that the PPIDE does not have as much software support as the direct IDE interface. I don't think there is support to use the PPIDE for a classic CP/M 2.2 system (the type we are discussing here). Perhaps someone can correct me here if there is such support. The PPIDE module also costs more. RomWBW fully supports the PPIDE.

Steve

[Tadeusz Pycio]

PPIDE is not a perfect solution either, its stability depends on the PPI 8255 used, in case of Z180 with 18.432MHz bus also unexpected errors appear. I suspect that for IDE it is worth to bring back the old idea of GIDE on 74x646, and for CF cards check if Karl's #74b module will solve all problems.

[Steve Cousins]

I have considered building a module with similar functionality to the 8255 based PPIDE module but using 74 series logic. This should cope reliably with faster clock speeds and hopefully be reliable. It would mean yet another set of driver software. Version hell just gets worse!

[lordha...@gmail.com]

According to Tindie Karl is "away" until 2030!

One more QQ for you: where do suggest I get XMODEM from?  I went to https://web1.foxhollow.ca/cpm/xmodem/ but I wonder if there are other recommendations?

[Phillip Stevens]

Steve wrote:

Don't also forget that some CF cards work better than others, and some don't work at all.

Conclusion: 

It is well known in our community that directly connecting a CompactFlash card to the Z80 family bus is less than perfect. There are issues like timing and ground bounce that make the whole thing a bit marginal. When you have a cooperative CF card and the modules are placed in optimum positions it can be perfectly reliable and provide you with fast storage. Defining optimal positions is problematic.

Some CF modules, such as Karl's (karlab) later designs have additional circuitry to help with these issues. The more reliable method is the parallel port IDE design, often called the hard drive module. This fixes the timing issues, helps with ground bounce, and isolates the CF data bus from the processor data bus. However, this provides slower storage as the data and control signals are generated by software rather than the processor's bus timing. It is also worth noting that the PPIDE does not have as much software support as the direct IDE interface. I don't think there is support to use the PPIDE for a classic CP/M 2.2 system (the type we are discussing here). Perhaps someone can correct me here if there is such support.

Hi Steve,

sorry to correct you, but YES there is a CP/M 2.2 System specifically designed to provide support for Spencer's (nee Ed's) IDE Hard Drive Module. It is called CP/M-IDE and it has been around for the past 4 years. I wrote a full explanatory note just a few days ago, as I noted the first commit anniversary was passing.

I wrote it to produce a minimal cost CP/M 2.2 System that avoids the well known issues with driving the CF Card directly off the Z80 bus by using the IDE 8255 Hard Drive Module, and it can operate with any Compact Flash card, specifically including the large (modern) 1GB and 2GB drives that are common these days. It supports either the ACIA Serial Module or the SIO/2 Serial Module.

There is software support for the both Z80 and 8085 CPUs from CP/M-IDE, and in the Z88DK, so there's an extensive set of libraries and tools available with support for the IDE Hard Drive Module with both CP/M 2.2 and to read and write FAT32 and FAT16 formatted drives.

The Z88DK support includes two C compilers (SDCC and SCCZ80), a macro assembler, linker, multiple floating point libraries, an emulator, debugger with live trace, etc. I'm probably correct to say that there is a greater variety of Z80 assembly available for CP/M-IDE (via Z88DK) than any other platform around.

Hi Andy,

Using CP/M-IDE I've tested (hammered) the PPIDE Module for hours in both the RC2014 Z80 bus (7.3MHZ), and using a Z180 (36MHz), using FATFS file copy programs and using CP/M based testing, to both CF cards (in 16-bit native mode) and to SSD and magnetic media hard drives.

I also believe that the 8255 works completely reliably at 36MHz (to Tadeusz's later point), but I'd suggest perhaps the RC2014 Z80 bus isn't the most reliable bus system to use at 36MHz? To my knowledge 36MHz operation at isn't directly supported and I've not tested it either.

There are some bodges that Ben and others contributors have developed for the standard CF Module, which Karl has further developed and "productised". Perhaps you can try those bodges on your own CF Module in the interim? They're documented here in the Group. A search will find them.

Cheers, Phillip

[Phillip Stevens]

Andy wrote:

One more QQ for you: where do suggest I get XMODEM from?  I went to https://web1.foxhollow.ca/cpm/xmodem/ but I wonder if there are other recommendations?

Andy,

Tony keeps a version in his Hi-Tech C 3.09 repository (also highly recommended to use this), which he has tuned for the RC2014.

I've also been playing with it, and left a gist of minor timing changes and a few other tweaks from this post here.

But, there's nothing additional to see unless you're interested in 8085 assembly.

Cheers, Phillip

[Phillip Stevens]

Andy wrote:

One more QQ for you: where do suggest I get XMODEM from?  I went to https://web1.foxhollow.ca/cpm/xmodem/ but I wonder if there are other recommendations?

Tony keeps a version in his Hi-Tech C 3.09 repository (also highly recommended to use this), which he has tuned for the RC2014.

I should also note the original XMODEM source can be found from the link here.

You can build it yourself using the DRI MAC assembler, and MLOAD (or a little more uncomfortable LOAD) tool.

P.

[lordha...@gmail.com]

thanks guys!

[Tadeusz Pycio]

I will make a temporary change of topic, as I have long been interested in the possibility of using M-System DiskOnChip chips in the RC2014 environment. Nowhere have I found documentation on how to use these chips directly without using the manufacturer's proprietary TrueFFS drivers. Does anyone have such documentation? Or maybe it is proprietary information and I can forget about using them?

[Alan Cox]

On Tue, 12 Apr 2022 at 22:47, Tadeusz Pycio <ta...@wp.pl> wrote:

I will make a temporary change of topic, as I have long been interested in the possibility of using M-System DiskOnChip chips in the RC2014 environment. Nowhere have I found documentation on how to use these chips directly without using the manufacturer's proprietary TrueFFS drivers. Does anyone have such documentation? Or maybe it is proprietary information and I can forget about using them?

There is a complete low level hardware implementation in Linux. It was done from M-Systems provided documentation although I don't know if the documents were ever public or just permission to produce an implementation. On top of that you need a flash translation layer. As far as I know TrueFFS was never public.

On Fuzix David Given has been using dhara, which is tight enough for some devices. ( https://github.com/dlbeer/dhara ). Dhara is basically a mutable radix tree giving block device like semantics on raw flash which you then stick a conventional file system on top of. So for example you could slap the CP/M file system over dhara over flash.

Or you could just use fram. because fram is cool and avoids all of this nonsense although it does need 3v3 conversion on the SPI interface or whatever you use.

[lordha...@gmail.com]

Hi Phillip - I think I had a good root around the  Hi-Tech C 3.09 repository but nothing leapt out saying "XMODEM" when I had a look.

I also looked at the sources at Deramp but those hex files are not packaged for the DOWNLOAD.COM (from Steve Cousin's website.)

Is there a non-tortuous route for me to get XMODEM.COM using the DOWNLOAD that I have?

thanks for your patience!  Andy

[Phillip Stevens]

Andy wrote:

Hi Phillip - I think I had a good root around the  Hi-Tech C 3.09 repository but nothing leapt out saying "XMODEM" when I had a look.

 

Sorry a bit of a red herring there. Tony's version is packaged for Z280, for Bill's SBC Z280RC.

But it is easy to build your own version on a host by using a cpm emulator, like RunCPM. You then need to use the DRI MAC.COM tool to assemble the source code, then MLOAD.COM to write the resulting HEX  into an executable COM file. But this won't help if you have nothing on your CF card to get the file over there.

 

I also looked at the sources at Deramp but those hex files are not packaged for the DOWNLOAD.COM (from Steve Cousin's website.)

Is there a non-tortuous route for me to get XMODEM.COM using the DOWNLOAD that I have?

It looks like Steve has a small program called SCM_Install_Download_code8000.hex that loads the DOWNLOAD.COM file into RAM and then runs it. But, if DOWNLOAD.COM is not working because of a CF Card hardware issue, then things become a little tortuous if you want to continue down that route, I'm afraid.

I'm not sure what other most non-tortuous routes there are, I'm afraid.

P.

[Tony Nicholson]

On Wednesday, April 13, 2022 at 12:22:29 PM UTC+10 Phillip Stevens wrote:

Andy wrote:

Hi Phillip - I think I had a good root around the  Hi-Tech C 3.09 repository but nothing leapt out saying "XMODEM" when I had a look.

 

Sorry a bit of a red herring there. Tony's version is packaged for Z280, for Bill's SBC Z280RC.

I massaged Martin Eberhard's XMODEM V2.9 sourcecode from Intel 8080 assembler

mnemonics into Zilog Z80 mnemonics.  There's two "customised" versions - one for

Bill Shen's Z280RC (which includes code to use the Z280's built-in console UART),

and the single-board minimal Z80-MBC2 board (which is a 4-chip system using just

a Z80 CPU, RAM and a microcontroller for I/O).  Both versions can be built as a

"vanilla" XMODEM by not defining a couple of conditional symbols using Microsoft

M80 or Hector Peraza's ZSM4 macroassemblers.

The Z280RC version is in the folder at

https://github.com/agn453/Z280RC/tree/master/utilities

and the Z80-MBC2 version is at

https://github.com/agn453/Z80-MBC2-master/tree/master/bios

As for "boot-strapping" them onto a system, if you have CP/M 2 already running,

you can use PIP to transfer the Intel HEX object file to a disk file and then use

the LOAD command to produce a COM file.

Set your communications program to add inter-character delays and a delay after

a CR (I have used both minicom under Linux or TeraTerm under Windows - 1ms

delay is sufficient to simulate a fast typing speed without losing characters).

Start PIP to receive an Intel HEX file from the console -

A> PIP XMODEM.HEX=CON:[HZ]

Now, send the HEX file in ASCII mode (using Ctrl-A Send ASCII from minicom or

File/Send-file... from TeraTerm).  PIP validates it as a Intel HEX file and detects

the end of file transfer address record to end the transfer.  Just use LOAD to

produce the COM file -

A> LOAD XMODEM

FIRST ADDRESS 0100

LAST ADDRESS 10FF

BYTES READ 1000

RECORDS WRITTEN 20

Now you can use the XMODEM command (with appropriate switches) to transfer

a binary file.  You should tinker with an XMODEM.CFG file to set the appropriate

defaults (like which serial port to use for file transfers etc.)  See the comments

in the assembler source file for details.

Tony

 

[Bill Shen]

Tony,
I like your method a lot, it is much cleaner than my method of using hex loader in my monitor to load XMODEM.HEX to memory starting from 0x100 and then start CP/M and type "save 17 xmodem.com".  My method requires RAM in lower half of the memory space and a monitor resides in upper half of memory but below CP/M.
  Bill

[Karl Matthias]

Grant Searle's original packager only appears to run on Windows and I am on a Mac or Linux box depending. I am sure there is some other tool that works (that I didn't find), but as a simple exercise I packaged up a little Ruby tool to upload files to CP/M using DOWNLOAD.COM, but it also talks to the serial port and directly uploads the file. It does all the encoding and invokes DOWNLOAD.COM on the fly.

You can run it in another terminal window while you have e.g. minicom open and running. Just run it like:

./upload.rb --file <your filename>

If you need to configure the serial port or other settings, you may find those settings in help:

$ ./upload.rb --help
Options:
  -d, --download-path=<s>    Path to DOWNLOAD.COM on CP/M (default: A:DOWNLOAD)
  -f, --file=<s>             File to upload
  -u, --user=<i>             The CP/M user ID to upload to (default: 0)
  -p, --port=<s>             The path to the serial port (default: /dev/cu.usbserial-FTDOMLSO)
  -s, --serial-speed=<i>     Serial port speed (default: 115200)
  -h, --help                 Show this message

If you are interested, you can find it here: https://github.com/relistan/cpm-uploader