Compact Flash uSD Adapter in IDE Hard Drive Module

[Phillip Stevens]

On a different thread we were discussing the micro SD Compact Flash Adapter, and whether it works with Spencer's IDE Hard Drive Module (with the 82C55 Device).

Well, in short it does. The only limitation that I've found is that the maximum SD card suitable for use is 128GB. Beyond this it seems to crap out. That's mentioned (in a very roundabout way) on the packaging. FAT32 runs out at 128GB too, so it is really not a limitation.

 

So, rather than just posting some packaging, I've done a bit of testing versus a real modern CF card (Verbatim), and an Acer DOM. Cutting to the chase, the DOM is only very slightly faster to copy 1MB files in CP/M, about 3 seconds in 47 seconds.

This may be affected by the SD card chosen. I did my testing with a reasonably fast Ultra SanDisk SD card, but this may not be too important, given the rate we're working at.

However, in the PC world the SD Card performance is very variable. I tested a write speed of 4.2MB/s for a generic SanDisk, 10.8MB/s for an Ultra SanDisk, and 21.3MB/s for an Ultra A1 Sandisk. The Verbatim 1GB CF card achieves 17.2MB/s write speed, for reference.

So using PIP the it takes about 47 seconds to copy a 1MB file with either the uSD card in the CF Adapter, or a real CF Card. It takes about 44 seconds to do the same to an IDE DOM, which is insignificantly faster in the scheme of things.

It is usually much easier to handle uSD and SD cards than DOMs or CF cards in modern laptops and computers. So these Adapters look like the way forward.

The testing was done on CP/M-IDE. I'll do a follow-up post with RomWBW shortly.

Cheers, Phillip

[Nick Brok]

I use sd to cf adapters for a long time, they work very nice.

Look at the board behind the CPU. I use a 2GB sd  card in the cf adapter.

Op dinsdag 26 juli 2022 om 13:27:24 UTC+2 schreef Phillip Stevens:

[Phillip Stevens]

Nick wrote:

I use sd to cf adapters for a long time, they work very nice. Look at the board behind the CPU. I use a 2GB sd  card in the cf adapter.

I guess the other interesting thing is that it looks like there's an 8051 CPU driving the SD->CF Adapter.

I wonder what it looks like inside? Whether it has an exposed UART for example?

Not sure I want to break mine to find out though.

[Tadeusz Pycio]

Unfortunately, in my case, a similar looking SD to CF adapter blocks with each SD card (I tested from 128MB to 16GB) the start of RomWBW ~30 sec to finally start with a message of no media. I use the official IDE module from the PLCC PPI.

Using the SD to IDE adapter on the same SD cards starts the system and accesses their contents. It is possible that my adapter is different, despite the similarity. It is comforting to know that it works on a buffered CF module.

Good thing we started this thread as I have discovered another cheap source of storage for our RC2014s. It's an MSATA to IDE adapter which you can buy on a well-known Chinese online shop for $4 and you can get used 2GB MSATA modules at a similar price. I have ordered one set and when it arrives I will share my test results.

[Phillip Stevens]

Tadeusz wrote:

Unfortunately, in my case, a similar looking SD to CF adapter blocks with each SD card (I tested from 128MB to 16GB) the start of RomWBW ~30 sec to finally start with a message of no media. I use the official IDE module from the PLCC PPI.

Using the SD to IDE adapter on the same SD cards starts the system and accesses their contents. It is possible that my adapter is different, despite the similarity. It is comforting to know that it works on a buffered CF module.

I've just plugged in a "standard" RC2014 (z80 + SIO2 + 512k/512k + IDE), with an older v3.1.1-pre.58 image.

I don't have a slice file system installed (my drives are all FAT32), but it doesn't block at the ID phase, and it recognises the drive size, etc.

Below a screen shot with 1st. 2GB DOM, 2nd. 1GB CF Card, and 3rd. 32GB uSD card in adapter, RESET between each boot.

So, either there's a regression in the RomWBW driver, or there's something peculiar about the Z280 that isn't playing nice.

Not sure where the issue will be coming from, I'm sorry.

Cheers, Phillip

[Bill Shen]

I have tested my SD to CF adapter on 68332 with 16-bit CF data bus, it worked.  I also tested it with Z80 with 8-bit CF interface, it also worked.  I have not tested it with Z280 in ROMWBW setup, so I’ll try that later today.

  Bill

[Tadeusz Pycio]

I built a similar set up, unfortunately I didn't have the same version of RomWBW so I compiled the closest one to the one shown - same effect, stopping after PPIDE: IO=0x20 (shorter this time) and then continuing to boot without detected media. Must be something different about my SD to CF adapter.

[Wayne Warthen]

Interesting discussion...  I have never tried one of these SD-CF adapters.  I just ordered a couple of them and should get them on Thursday.  This should allow me to replicate most of the scenarios being described.

I guess there could be an issue with RomWBW, but it seems unlikely since there do not seem to be any issues with CF Cards in general (other than hardware anomalies on the unbuffered boards).

Thanks,

Wayne

[Tadeusz Pycio]

I don't think it's a RomWBW problem, probably these adapters are different despite identical markings. Mine works with the PC and with the buffered CF module, but in the IDE module it won't work. It's a good thing it finally worked, as it had been lying in a drawer uselessly for a year. I've been wanting to build an IDE module, a GIDE replica on a 74HCT646 customised for RC2014 for a while, but I keep putting it off. Maybe it will behave differently there.

[Bill Shen]

My SD-to-CF adapter works with unbuffered CF interface (i.e., no 74245 between CF data lines and Z80's data line).  However, many of my designs bootstrap from the first sector of CF disk (Master Boot Block).  I'm not able to bootstrap from SD-to-CF adapter for those designs, but I think that's a different issue.  

I do have a Z280 design with the traditional 512K RAM, ROM and unbuffered CF interface.  It works with SD-to-CF adapter.
  Bill

[Tadeusz Pycio]

I checked this adapter with Steve's test program, the top result on Spencer and Karl's #10f modules gives the same result, below already correctly recognised SD card after using the buffered CF module.
Perhaps this correctly read information is different from the adapters you have? I am curious about the results.

[Bill Shen]

SCMonitor's CF information Apps does not run on my Z280 hardware, so I did a quick mod of my monitor to send the "Identity" command ($EC) and display the returned raw data.  The raw data are byte-swapped, so the adapter information is:

Rev 1.5 FC-1307 SD to CF Adapter V1.5

I guess it is a newer model (rev1.5) than yours (rev 1.3).
  Bill

[Phillip Stevens]

Bill  wrote:

SCMonitor's CF information Apps does not run on my Z280 hardware, so I did a quick mod of my monitor to send the "Identity" command ($EC) and display the returned raw data.  The raw data are byte-swapped, so the adapter information is:

Rev 1.5 FC-1307 SD to CF Adapter V1.5

I guess it is a newer model (rev1.5) than yours (rev 1.3).
  Bill

Tadeusz wrote:

I checked this adapter with Steve's test program, the top result on Spencer and Karl's #10f modules gives the same result, below already correctly recognised SD card after using the buffered CF module.
Perhaps this correctly read information is different from the adapters you have? I am curious about the results.

I've written a little program which will print out the low level disk attributes, and found that my brand new SD->CF adapter is firmware revision 1.3.

So this is getting quite curious...

I wonder how many different firmware versions are in the wild?

B>diskchk

**** Initialise disk ****
 disk_initalize(0) - ok

**** Get firmware revision ****
 disk_ioctl(0, ATA_GET_REV, 0x17EB) - ok
 Firmware revision is Rev 1.3

**** Get model name ****
 disk_ioctl(0, ATA_GET_MODEL, 0x17EB) - ok
 Model name is FC-1307 SD to CF Adapter V1.3          

**** Get serial number ****
 disk_ioctl(0, ATA_GET_SN, 0x17EB) - ok
 Serial number is 042FCB67            

**** Get drive size ****
 disk_ioctl(0, GET_SECTOR_COUNT, 0xE1E1) - ok
 Number of sectors on the drive is 62333952

**** Get sector size ****
 disk_ioctl(0, GET_SECTOR_SIZE, 0xE1E7) - ok
 Size of sector is 512 bytes.

**** Get block size ****
 disk_ioctl(0, GET_BLOCK_SIZE, 0xE1E5) - ok
 Size of the erase block is 1 sector(s).

[Tadeusz Pycio]

We are back to square one. We have the same adapters, with the same firmware, and different results. Today I'm going to try to bypass the buffer, as I have a different way of controlling it, relative to the available CF modules (thank you Steve and Bill - interestingly I've reached the same point as someone has before - https://github.com/PickledDog/rc-cfcard), and further this doesn't solve the problem of not working in the IDE module. I will share the results without the 245 buffer later.

[Tadeusz Pycio]

Removing the buffer 245 and bridging, no change, the adapter still works. The problem is in the control, a question whose timing we do not provide....

[Spencer Owen]

FWIW,  I tried a couple of the full size SD adapters with a selection of cards and didn't get any positive results. They were just tested with the standard image I use on CF cards, and the test was just a working/non-working test, but after a few goes I gave up on them.

Spencer 

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/7eae9ffd-5419-4d48-8c10-06cfcde24d24n%40googlegroups.com.

[Bill Shen]

Apparently the SD-to-CF adapter requires positive setup time (t1) from CF chip select asserted to CF_read or CF_write asserted.  Some brand of CF card works with no setup time or even negative setup time, but not this SD-to-CF adapter.  Positive setup time can be achieve by generating CF chipselect from M1 and addresses (no IORQ involved) and generating CF_write and CF_read qualified with IORQ.
  Bill

[Tadeusz Pycio]

Bill, my module works according to the method you describe, it may be worth trying to take a different path, delay the appearance of /RD and extend the low level /IORQ which controls the full decoder /CS of the CF card.

[Phillip Stevens]

Spencer wrote:

FWIW,  I tried a couple of the full size SD adapters with a selection of cards and didn't get any positive results. They were just tested with the standard image I use on CF cards, and the test was just a working/non-working test, but after a few goes I gave up on them.

Spencer

Spencer did you try them with your IDE Hard Drive Module, as per the OP subject?

I’ve a feeling that they are made to work in native 16-bit IDE Mode, as per packaging, “True IDE” and “ATA 0-3”.

Anyway if you’ve still got them have a look with your IDE Module and let us know what you think.

Cheers Phillip

--

Sent from a Mobile Device. Replies may appear terse.

[Bill Shen]

Tadeusz,
When CPLD is available, my CF interface design looks like this.



When design with TTL logic, my CF interface looks like this.

Both designs are very robust with Zx80 timing.  However, the CPLD CF design doesn't work 100% when implemented in 680x0 timing where I also need to implement the hold time (t9), and even that is still not 100%.  There is a forum member here who seems to be able to reach 100% success with 680x0 CF interface, I hope he'll chime in.
  Bill
PS, the PDF-to-JPEG conversion is not very good.  Here are the original PDF files

[Phillip Stevens]

Wayne wrote:

Interesting discussion...  I have never tried one of these SD-CF adapters.  I just ordered a couple of them and should get them on Thursday.  This should allow me to replicate most of the scenarios being described.

I guess there could be an issue with RomWBW, but it seems unlikely since there do not seem to be any issues with CF Cards in general (other than hardware anomalies on the unbuffered boards).

Another data point:

To check whether there is a regression in RomWBW HBIOS, I've built the latest dev branch for the standard RC2014 configuration (SIO2 + 512k/512k + Spencer IDE).

I can confirm RomWBW pre.183 is working with the SD->CF Adapter with the firmware v1.3, with Spencer's IDE Module.

Also, I can confirm that HBIOS is much faster than CP/M in disk access.

The HBIOS Monitor using the FATFS file system can copy 1MB in 18 seconds, vs 47 seconds on CP/M file system for the same file copy.

So on CP/M the uSD card in the CF adapter can do about 50kBytes/sec using PIP.

And PIP is super optimised. It is very difficult to do faster within CP/M.

With HBIOS + FATFS the same storage medium can do about 116kBytes/sec (average of read and write).

I've attached the C program (uploaded into the RomWBW Monitor) which reads a file called random1.txt and writes random2.txt, then deletes it.

Because the RC2014 doesn't have a system tick, timing has to be done by hand.

zcc +rc2014 -subtype=hbios -clib=sdcc_iy -SO3 -m --list --max-allocs-per-node100000 -llib/hbios/time -llib/hbios/diskio_hbios -llib/hbios/ff fileCopyTest.c -o fileCopyTest -create-app

[Wayne Warthen]

I have received the SD-CF Adapters that I ordered.  In the attached picture, the first one (Red) is like everyone else seems to have.  The second one (White) also calls itself an Extreme CF Adapter, but says something about "3rd generation" -- no idea what that refers to.

Red identifies itself as:

SN: "50277237            "
Revision: "Rev 1.3 "
Model: "FC-1307 SD to CF Adapter V1.3           "

White identifies itself as:

SN: "2C1003531           "
Revision: "00000011"
Model: "INIC-2051 CompactFlash Card             "

In my testing, I am finding that both cards struggle with an unbuffered IDE interface.  Neither work in my RC2014 CF Module.  However, Red does work in Bills ZZ80MB where White does not.  I conclude that they are generally not happy with the unbuffered IDE interface.  Access via a PPIDE interface was universally successful on all platforms.

I found that Red was happy operating in either 8-bit or 16-bit mode.  However, White did not handle 8-bit mode at all.  It just accepted the command to go into 8-bit mode (without error), but clearly continued to operate in 16-bit mode.

I observed no issues with either Red or White related to the size of the SD Card.  When either one was in a configuration that worked, I could use a wide variety of SD Card sizes (tested up to 8GB).

I used RomWBW for all my testing and I did not see any indication of software related issues.

If anyone has a specific scenario that they want me to try, just let me know and be sure to describe the full test configuration completely (there are a lot of variables).

Thanks,

Wayne

[Bill Shen]

Not able to set to 8-bit mode with “set feature” command will definitely cause problems with many of my 8-bit CF designs.  I also recall encountered older CF that do not support 8-bit mode, or do not return to native 16-bit mode with reset unless it is power-on reset.  Operating CF in its native 16-bit mode may solve some of the problematic cases.

  Bill

[Phillip Stevens]

Wayne wrote:

I have received the SD-CF Adapters that I ordered.  In the attached picture, the first one (Red) is like everyone else seems to have.  The second one (White) also calls itself an Extreme CF Adapter, but says something about "3rd generation" -- no idea what that refers to.

Red identifies itself as:

SN: "50277237            "
Revision: "Rev 1.3 "
Model: "FC-1307 SD to CF Adapter V1.3           "

White identifies itself as:

SN: "2C1003531           "
Revision: "00000011"
Model: "INIC-2051 CompactFlash Card             "

Access via a PPIDE interface was universally successful on all platforms.

Wayne, thanks for the 2nd and 3rd confirmation data points that these SD->CF adapters are universally successful on Spencer's IDE Hard Drive Module.

Now that I know that they're universally useful, it brings me to an interesting philosophical question.

Is it worth building a CF specific true IDE (16-bit) Adapter?

If it were not for the global chip shortage (e.g. of 82C55), I think the answer is a clear yes.

In the past I've not liked the CF format because:

1. Not universal - can't be read on laptops / PCs unless equipped with special adapter.
2. Old CF cards are too small, unreliable, and difficult to source.
3. New CF cards are too expensive (WRT other formats).
4. CF is generally a dead technology.

But as an alternative, SD cards need a serial SPI interface and are a PITA to interface to the Z80, requiring cycle consuming bit-bang and Byte reversal to make them work (and then only very slowly).

The uSD card housings are also fiddly and small and generally all require SMD soldering. So not ideal for easy construction.

Spencer's existing IDE Hard Drive module is perfect as it stands. It can connect to everything from 5" hard drives down through to 1.8" SSD, or embedded DOM devices, and including CF Cards too.

Although I prefer the DOM use case is the cleanest (low profile, doesn't interfere with other slots) and my current preference, it is a bit fiddly to back up the CP/M drive files on a PC.

It requires an USB-IDE adapter and a socket reversal adapter to read the DOM contents on a PC.

I think now it would be ideal to have a true IDE (16-bit) CF Module with a through-hole CF connector (like Wesley found), with the CF Adapter module set low on the card.

That would allow me to:

1. Use uSD cards of any size up to 128GB, storing many thousands of CP/M drives.
2. Be able to easily back up my work in any modern laptop / PC.
3. Avoid "floating drive" where the drive is attached to an IDE cable pigtail.
4. Not sacrifice any performance of my CP/M system.

And the final positive thing is that (if the marketing image below is to be believed) the SD->CF adapters contain a 8051 CPU, which could be considered a retro-authentic I/O Co-Processor.

So then I could have my RC2014 system with i8085, i8051, and i8231 processors all on one back-plane.

I think that would win an Intel Retro Trifecta.

Cheers, Phillip

[Tadeusz Pycio]

It looks like I have a not fully working SD to CF adapter, or there are differences in the operation of the IDE modules. Another thing, I have already ruled out the effect of the buffer on the operation of this adapter in the CF modules, here the differences are in the control (exactly in the timing dependencies).

[Phillip Stevens]

Tadeusz  wrote:

It looks like I have a not fully working SD to CF adapter, or there are differences in the operation of the IDE modules.

Not sure, but possibly your SD-CF Card Adapter is faulty?

Perhaps get another one to test again?

I've just tested with a V1 of Ed's IDE Adapter, and it is working just the same as Spencer's.

Nothing exceptional to report. The i8085 is a bit slower at I/O than the z80, but it is marginal.

Cheers, Phillip

[Tadeusz Pycio]

Hi Philip,

I have already ordered a second one that looks the same and will check that it works in the IDE module. What bothers me is that the adapter I currently have works in a particular CF module (which works on similarly to the SC145).

[Phillip Stevens]

Tadeusz wrote:

Hi Philip,

I have already ordered a second one that looks the same and will check that it works in the IDE module. What bothers me is that the adapter I currently have works in a particular CF module (which works on similarly to the SC145).

Just a random thought, but how are you powering the RC2014 host?

In theory the SD-CF Adapter may be running the uSD Card in a “high power” high speed mode. We’re not controlling that. And the current requirements may not be met by a USB 5v supply filtering through the RC2014 bus.

The SD Design Guide Standard talks about 400mA at 3.3V for some modes.

Perhaps that’s an explanation?

Cheers, P. 

[Tadeusz Pycio]

Hi Phillip,

Yes I pointed this out earlier, as I have a RESET chip on a TL7705 and it was resetting my computer during reads when powered by USB only.

I found some interesting information about this adapter, I don't know if the information about the power supply voltage applies only to the SD card or also to the CF interface. This would need to be checked, the information on the VS1 pin may also be helpful: "Voltage Sense Signals. -VS1 is grounded so that the CompactFlash Storage Card or CF+ Card CIS can be read at 3.3 volts"

[Nick Brok]

This is the adapter I use and works in every combination. (PPIDE/IDE unbuffered as in rc2014 and buffered.) it is a delock adapter.

Op vrijdag 29 juli 2022 om 11:51:13 UTC+2 schreef Tadeusz Pycio:

[Tadeusz Pycio]

As expected, the SD to CF adapter with buffer (I checked HC, HCT and ACT) is not recognised with the classic /CS, /RD, /WR signal control like Spencer's CF module. This and previous experience rules out the need for it for this adapter (for some CFs it works).

[karlab]

Hi Tadeusz

If your module works with some CF cards it is still useful.

I made many variants of CF cards.  I did not find the buffering to give a significant improvement in the robustness of the module.

The best solution was to put resistors on the data lines and caps on the RD/WR lines which was suggested by Bill.

Enclosing pictures of some of my CF modules. 

Karl

 

[Tadeusz Pycio]

Another clue, I already have confidence that the time dependencies of the control signals are of great importance. Top screenshot of RomWBW startup when I use 74HCT32, below when it is 74ACT32. It's high time to analyse this with an oscilloscope and logic state analyser.

/CFRD is the /IORD input of the CF card, /SEL from the address decoder and it controls the /CE input of the CF card.

[Bill Shen]

How was /SEL generated?  Just with addresses and /M1?  I assume 15080MB is the correct disk size?  Did ACT32 consistently read 96MB disk size.  ACT and AC logic are so fast which can generate reflection affecting proper CF access.

  Bill