Problem running applications in CP/M on new CF card

[Andrew Davidson]

Hi, I'm wondering if anyone can offer any help/advice/thoughts?

In summary, I have freshly installed CP/M on a Sandisk 128MB CF card, all appears OK until I transfer any apps across to the card and try to run them. They just hang, sometimes I get a few characters of garbage on the terminal, sometimes not, the only cure is to hit the reset.

The system is a newly built 'RC2014 compatible' system...

Stephen Cousins:

SC112  v1.0 6 slot backplane

SC110  v1.1 Serial with CTC

SC108 v1.0 Z80 CPU, RAM, ROM

RC2014:

Compact Flash Storage v1.0

Digital I/O v2.2

Firmware: Small Computer Monitor - S3

After building all appeared 100% OK running SCM, so my next step was to try and get CP/M going.

I've followed the following steps:

- using 128MB Sandisk CF card

- Used 'CPM v2.2 Format' from 'SCWorkshopProjects'

- Took the  SIO CPM22 hex file from the RC2014 Github repository

- Used SCWorkshopProjects CBIOS, 'PutSys Plus' and 'Download.com'

All went OK and as expected.

CP/M starts fine.

'Job done.', I thought, however when I tried to import a 'pkg' file with DOWNLOAD.COM the transfer appears to complete, I get an 'OK' prompt, but then the system hangs.

I have a pre-installed 128MB CF card that came with a RC2014 Pro, I tried plugging that in, it works fine. So I'm pretty confident the problem is either with the way I have installed CP/M or the CF card itself.

To try a different approach, I took an image of the disk with 'Gnome Disk Utility' and added a few files with cpmtools and restored the image. Again, all appeared fine, until I tried to run an app with the same results.

I can't help feeling I've missed something silly, but right now I'm stuck, any thoughts or ideas would be very welcome.

[Steve Cousins]

Hi Andrew,

I've just successfully installed CP/M and Apps by essentially following your method. I set up the same hardware and followed the following steps. Terminal output also included. The only step you can't see from the terminal output is where I selected settings and files in Tera Term.

Hardware: SC112, SC108, SC110, RC2014 CF module, Crucial 128MB CF card

Power supply: FTDI cable

Tera Term settings: 115200 baud, 8 data, no parity, 1 stop, no flow control*

* Note: turned this on later

Downloaded from Small Computer Central:

SCW020_SCM100_20190124.zip

Ran :

SCW020_SCM100_20190124\SCWorkshopProjects\CPM v2.2 Format\Format_CF128_code8000.hex

Ran:

SCW020_SCM100_20190124\SCWorkshopProjects\CPM v2.2 PutSys Plus\PutSys_RC2014_SIO_CF128_code8000.hex

CPM starts ok

Reset Z80 system

Ran:

SCW020_SCM100_20190124\SCMonitor\Apps\CPM_install_Download.com\SCMon_RC2014_Download_code8000.hex

Started CPM

Entered command:

SAVE 2 DOWNLOAD.COM

Turned on hardware flow control to throttle data to DOWNLAOD.COM

Tera Term settings: 115200 baud, 8 data, no parity, 1 stop, hardware flow control

(I don't normally run with flow control on, don't know why!)

Sent from the terminal a package containing MBASIC.COM

This took about 9 seconds

Started MBASIC with the command:

MBASIC

All works fine.

I later repeated the process with hardware flow control on all the time. All ok.

Terminal output:

Small Computer Monitor - S3

*Ready

*

*g8000

CP/M Formatter by G. Searle 2012

ABCDEFGHIJKLMNOP

Formatting complete

*Ready

*

*g8000

CP/M System Transfer by G. Searle 2012

........................

System transfer complete

*cpm

RC2014 CP/M BIOS 1.2 by G. Searle 2007-18

CP/M 2.2 Copyright 1979 (c) by Digital Research

A>dir

No file

A>

Small Computer Monitor - S3

*Ready

*

*g8000

Download.com is ready to be saved.

Start CP/M and enter SAVE 2 DOWNLOAD.COM

*cpm

RC2014 CP/M BIOS 1.2 by G. Searle 2007-18

CP/M 2.2 Copyright 1979 (c) by Digital Research

A>save 2 download.com

A>A:DOWNLOAD Mbasic.com

................................................................

................................................................

..............................................................

OK

A>

A>dir

A: DOWNLOAD COM : MBASIC   COM

A>mbasic

BASIC-80 Rev. 5.21

[CP/M Version]

Copyright 1977-1981 (C) by Microsoft

Created: 28-Jul-81

29752 Bytes free

Ok

[Andrew Davidson]

Thanks Steve,

It's always reassuring to know for sure what I did at least should work.

I've got it working in the end thanks to some tips from Alan Cox via email.

I reformatted the CF and reinstalled CP/M, again, just to be double sure all was OK.

I had the CF Storage card one slot removed from the Z80 - just to make access easier.

I moved it next to the Z80 card and all of my problems went away. Who knew? I can't see any obvious explanation.

It's interesting that the pre-installed card I had worked OK. I could have made an error with the CP/M install but I'm 99% sure I didn't (I re-installed several times).

Anyway, happy to have it working, thanks for your help.

[Steve Cousins]

I'm running my system with SC108, unused slot, SC110, unused slot, RC2014 Compact Flash.

The whole business of connecting a CF card directly to the processor bus does seem to cause problems, but your symptoms were odd.

Steve

[Karl Albert Brokstad]

Hi Andrew

The problem could lay in the CF card.

I have seen similar problems with some CF cards of lesser quality.

Remember CF cards of these sizes are not in production any longer, so most of the cards are old refurbished cards.

It is my impression that the CF card provided by Spenser is of very good quality, but you may have received the odd one, or it failed in use.

I did send you some emails in reply to your post.( not shown here)

Try if you can copy a disk image to your CF card, and try it out. 

https://www.z80.no/info/InitCFdrive.html

The disk images available for download is made with SCM.

I also pointed to that the S3 rom was used. I have R3 in my setup. Maybe SteveC can comment on that.

Karl

[Bill Shen]

Hi Andrew,

Be sure to do this test to make sure your CF is really working:

pip d:=a:*.*[v]

This assume drive d: is empty and drive a: contains CPM system files. If this operation completed without errors, then most likely your CF disk will work reliably in the current configuration.

Unfortunately your setup is marginal, it can break when you added or remove a card.

Bill

[Andrew Davidson]

I've investigated this problem a bit further today and I'm happy that the issue is definitely related to the CF I have used.

Your suggested pip test does indeed fail:

A>pip e:=a:*.*[v]

COPYING -
ASM.COM
DDT.COM
DEPKG.COM
DISPLAY.COM
DOWNLOAD.COM
DUMP.COM
ED.COM
KERMIT.COM
L80.COM
VERIFY ERROR: =A:*.*[V]

I can reliably reproduce the original problem, by moving the card one slot away from the Z80.

If I use my other CF card the problem definitely does not occur.

Interestingly, I ran the SCM Compact Flash test and this passes without any reported errors at all, which surprised me after the failure of the 'pip test'

A bit strange, but for whatever reason the CF is not reliable, the simple solution is to get another CF I think!

Andrew

[Bill Shen]

Andrew,
PIP-with-verify is a simple & quick way to verify the CF disk is working properly. You'll find it consistently failed on the same file, the failure is data pattern dependent. If you can adjust the 5V supply from 4.5V to 5.5V, you may find it more reliable at lower voltage and less reliable at higher voltage. The CF disks that failed are the newer, faster CF. it is the older, slower CF disks that work. Cisco brand of 64MB or 128MB seems most reliable.
Bill
PS, I believe a reliable CF interface is possible with noise filtering and proper termination of data bus, but the current solution is trying different CF disks until a working one is found. Not a good situation, IMO.

[Karl Albert Brokstad]

As I mentioned earlier, the CF card provided by Spencer is of generally good quality.

And I have experienced the same as Andrew with industrial CF cards, they may not be up to specs.

I wonder how much the CPU speed is influencing the read/write to CF, since the CISCO CF is a bit slower but more reliable?

Karl

[Bill Shen]

From CPU speed of 7Mhz to 20MHz, the CF disk is generally fast enough that no wait state is needed. Slowing down or speeding up the CPU clock does not change the CF interface characteristic. The 'fast' or 'slow' CF disk refers to the rising and falling edges of the CF output signals. When the eight data lines of a fast CF disk simultaneously drive capacitive loads such as a backplane with many boards, especially from all 0's to all 1's, a large instaneous current is flowing out of the CF disk, which cause its ground to sink lower than the system reference ground. The ground negative spike is too brief to affect Z80 and older TTL technology, but the CF_read line see a brief positive spike when CF's ground is spiking down. The CF_read controls a FIFO, so a spike can cause the FIFO to advance to next data byte thus discarding current byte of data thus corrupt the data packet. In short, the data corruption is self inflicted that only 'fast' CF can generate the fast ground spike that the 'fast' CF_read can react to. For the 'slow' CF, the ground spike is of insufficient magnitude or duration to cause its 'slow' CF_read to skip a byte of data. This is obviously a simplified explanation, the reality is much more chaotic and difficult to instrument and troubleshoot. We are now in the real of RF Black Magic, so when moving the CF card around on the backplane, we are effectively looking for a quiet spot where reflected wave cancelled the incident wave sufficiently for it to function properly, a precarious situation.

You can imagine the problem is worse when 16 data lines are switching simultaneously instead of 8 which is the case when interfacing to CF in its native 16-bit mode.

Bill

PS, all these issues are fixable or CF disks would never have worked in the real world. The later version of IDE spec delved quite a bit into the problems and solutions of CF interface.

[Phillip Stevens]

Bill Shen wrote:

You can imagine the problem is worse when 16 data lines are switching simultaneously instead of 8 which is the case when interfacing to CF in its native 16-bit mode.

I guess, it is time to insert an advertisement for Spencer's (Ed's) 82C55 native 16-bit mode CF interface board.

Driving the native 16-bit CF interface with a properly buffered PPI and with short IDE cables (no stubs, Tees, etc), doesn't produce the same kind of randomness that slapping a CF card on the main CPU bus seems sure to originate.

Phillip

[Bill Shen]

I've posted these two pictures of slow-medium-CF-disks and fast-CF-disks before, but they may be worth repeating here.  These are random disks I purchased from eBay and used to test my CF interface designs.  They are random samples of whatever are available off eBay.  They all work (having randomly purchased 400+ used CF disks off eBay, 97-98% of them are working), slow-medium-CF disks should work in most CF boards, the fast-CF-disk only work in properly designed CF boards.  The generic no-brand CF disk on the left was marked 'NG'--No Good because for the longest time I couldn't talk to it until I figured out the noise issues.

Buffering the CF data bus is a valid solution, so is using terminating resistors.  Who in the USA has the 82C55 CF board?  I have a fast CF disk, SanDisk 256MB (on the right of 2nd picture), that won't work on many CF boards including some of my early CF designs.  I have many of these, so I'm happy to mail it, at my expense, to anyone in the USA to test on your 82C55 CF board.  This disk absolutely works on correctly designed CF boards.  If it works on the 82C55 CF board, you'll have a very fast CF disk.  You may keep it in any cases.  
  Bill

[Phillip Stevens]

Bill Shen wrote:

Who in the USA has the 82C55 CF board?  I have a fast CF disk, SanDisk 256MB (on the right of 2nd picture), that won't work on many CF boards including some of my early CF designs.  I have many of these, so I'm happy to mail it, at my expense, to anyone in the USA to test on your 82C55 CF board.  This disk absolutely works on correctly designed CF boards.  If it works on the 82C55 CF board, you'll have a very fast CF disk.  You may keep it in any cases.

Would love to get something for free, but I have neither the CF board, nor live in USA. Doh!

But, can I flip the question around?

Have you tried this green Verbatim 1GB CF card? Or its 2GB brother (that is available in USA).

https://www.ebay.com/itm/Verbatim-1GB-CompactFlash-Memory-Card/222243052611

I'd be interested to know whether you consider it in your fast or slow categories?

Or, whether it would normally be troublesome?

From my point of view, using the 82C55 IDE adapter, I find it never any trouble and just a little slower than a real PATA SSD.

https://www.ebay.com/itm/Kingspec-2-5-IDE-PATA-SSD-MLC-Solid-State-Drive-fr-Notebook-ASUS-HP-Laptop-16GB/253805119386

But not objectionably slower.

The speed of removing it from its RC2014 IDE adapter, and then putting it in a PC front panel CF socket to transfer files, more than compensates for the few milliseconds extra I have to wait for XMODEM. ;-).

Phillip

[Bill Shen]

I went ahead and order a Verbatim 2G green CF from here:
https://www.ebay.com/itm/Verbatim-47012-Verbatim-2GB-CompactFlash-Memory-Card-1-Card-1-Pack/172029857351     I have several CF designs I can try it on to determine whether it is slow/medium/fast.

I only have tried one brand of Disk-on-module on a correctly designed CF interface.  It worked fine.  https://www.ebay.com/itm/Lot-of-10-Secure-Disk-On-Module-PQI-Disk-32MB-44-Pin-DQ0032M23RD0-New/202031405987    DOM pin assignments are mirror image of 44-pin IDE, so it is not easy to try it on other CF designs I have on hand.  I'll have to think about it a bit...

  Bill

[Phillip Stevens]

Bill Shen wrote:

I went ahead and order a Verbatim 2G green CF from here:
https://www.ebay.com/itm/Verbatim-47012-Verbatim-2GB-CompactFlash-Memory-Card-1-Card-1-Pack/172029857351     I have several CF designs I can try it on to determine whether it is slow/medium/fast.

Looking forward to hear.

Phillip 

[Mark T]

Would a short length of ribbon cable be able to mirror the connections for the DOM?

[Nick Brok]

Hello,

I use a derived PPIDE interface in 8 bit mode with a 82C55 and most modern CF cards work fine for CP/M. In Fuzix there are sometimes some initialization issues, but once initialized the card works fine.

Spencer's way of connecting the CF-card directly on the z80 bus is asking for problems if you count in HF propagation. So as earlier written Spencer's CF card was better be buffered with 74HCT245 and 74HCT244 on the bus.  Look at the old schematics of IDE interfaces of the (IBM) PC, there is the cpu-bus also buffered.

I have Spencer's rc2014 pro (Complete with CP/M) and the position of the CF-interface on the backplane makes that it works or not. HF impedance problems. Like the SWR in a transmission line of a transceiver.

greeting,

Nick de PE1GOO

[Karl Albert Brokstad]

OK, I get the point. CF cards are good, the implementation is bad :)

It is like bitbanging a serial port, it works but at a cost of speed/reliability.

I have seen Bill has added resistors to the data lines on his "bitbanged" CF adapter .

And as Nick suggest, putting a 74HCT244 on the address and 74HCT245 on the data lines may improve the reliability?

I may experiment with this, as a way to improve reliability, but it will still not be a "clean" implementation as using 82c55 or wdcxxxx.

Karl

[Richard Lewis]

Maybe try a 74HCT7541 which adds hysteresis? I haven't read through the tread carefully but maybe a noise issue?

[Steve Cousins]

Bill

Great explanation of the problem, thanks.

Steve

[Tadeusz Pycio]

Maybe try a 74HCT7541 which adds hysteresis? I haven't read through the tread carefully but maybe a noise issue?

Hi Richard,

In my constructions I use HC245, CF cards are much better, even problematic ones. It's better to use HC instead of HCT, CF works on CMOS levels.

[Nigel Kendrick]

Here's another working DOM on a DIY RC2014 board.

Also goes to show how some signal skew can be tolerated too!

Nigel

[Sergey Kiselev]

If it is a voltage drop issue, adding a couple of low ESR capacitors really close to the CF power pins should help.

It might be also that ground connection is insufficient (one or two pins in case of RC2014). In this case soldering an additional (short and thick) wire between the backplane ground and the CF card should help.

Regarding MHz - keep in mind that the bus timing of Z80 is different from ISA bus.

First of all ISA bus normally tops at 8 MHz (some systems allowed overclocking that, but many ISA controllers will not work reliably at 10 MHz or more).

Next, a standard 8088 bus cycle takes four clock cycles, while normal Z80 I/O read/write cycles take only 3 clock cycles.

Moreover, even with a 8088 running at 4.77 MHz, ISA inserts a wait state for every I/O bus cycle, and in case of an AT-class machine, as many as 4 wait cycles are inserted for 8-bit I/O cycles. RC2014 doesn't insert any wait cycles...

So even with Z80 running at 7.3728 MHz, we are exceeding ISA timing specs...

[Bill Shen]

While the DOM pin assignments are mirror image of the 44-pin CF, it is possible to solder one side DOM connector to the opposite side of the 44-pin CF and manually wired the missing connections across.  There are only 8 manual wires required.  The resulting board is more compact compare to the CF disk.  The DOM works fine with this modification, passing the PIP-with-verify test.
  Bill

[Tadeusz Pycio]

Today I have conducted tests of using the SD card instead of CF. On the PPIDE interface, the SD-IDE module works correctly, I was unable to start using the SD-CF module.

[Bill Shen]

I have the same brand of CF-to-SD adapter (Type I Extreme CF Adapter), but uses standard SD card instead of micro SD card.  It works fine with the CF board shown in the picture of my post this morning.
  Bill

[Bill Shen]

I received the Verbatim 2G CF disk in the mail this morning.  I tried it on half a dozen CF interfaces with various combination of 8bit/16bit bus, Z80/Z280/68000/68332, and with or without terminations.  They all worked.  I even went back to my very first 68000 version 1 design that had no termination at all and only work with few brands of CF disks and it worked there as well.  This is obvious a modern CF disk with fast read/write access, but its interface characteristic is like a "slow" CF disk.  I think it either have internal termination or controlled slew rate on its I/O lines.  It is a very well behaved CF disk, I recommend it.
  Bill

[Phillip Stevens]

Bill Shen wrote:

I received the Verbatim 2G CF disk in the mail this morning.  I tried it on half a dozen CF interfaces with various combination of 8bit/16bit bus, Z80/Z280/68000/68332, and with or without terminations.  They all worked.  I even went back to my very first 68000 version 1 design that had no termination at all and only work with few brands of CF disks and it worked there as well.  This is obvious a modern CF disk with fast read/write access, but its interface characteristic is like a "slow" CF disk.

I'm glad that it is a good CF disk. One of the few new CF cards now available on Amazon / eBay.

I also find it good, and almost as fast as a Kingspec PATA SSD in practice (when in PIO 0 mode).

 

I think it either have internal termination or controlled slew rate on its I/O lines.  It is a very well behaved CF disk, I recommend it.

Good that it is well behaved, but it doesn't help differentiate whether the 82C55 based IDE interface manages "bad" or "fast" CF cards better than the RC2014 CF interface, or not.

I guess we'll have to find someone who has both Spencer's (Ed's) IDE interface, and a "fast" card to know more about this story.

Anyway, was an interesting experiment.

Phillip