As I've been testing my recent BIOS code against my RTC/IDE adapter, I've found some CF Cards that don't work... I've recently purchased some additional cards for testing. What I've found is interesting. Pretty much any common SanDisk Card work without issue. Then again, I used the SanDisk documentation to create the BIOS routines.

In my current collection, I have some SanDisk cards which are:

16MB, 32MB, 96MB, 128MB, 256MB, 512MB and 2.0GB

- all of these show as SanDisk in the manufacturer's field in the identify data except the 256MB cards. One shows as STI (which I think is Simple Tech Inc.) and one shows as an invalid identity record. All of the true SanDisk cards work fine with my BIOS for Reset, Self Diagnostics, Block Read, Block Write and Block Verify. The STI and unknown don't work and lock up the system when access is attempted.

Also, I have a pair of Cisco branded cards, both 64MB. One is a SanDisk brand and the other is a STI brand. As above, the SanDisk card works and the STI card doesn't.

I also found my old IBM 340MB Microdrive... this also works fine with my adapter and BIOS code. I also grabbed a SanDisk 8GB Extreme Card (used in my Tascam HD-P2 digital audio recorder) and that works too.

So, I'm wondering/hoping that someone else out here has done some more extensive work with some of these non-SanDisk cards with success. I haven't done a lot of research on this problem yet, but will likely need to get the logic analyzer out next.

_________________
Regards, KM
https://github.com/floobydust

I believe hoglet found an anomaly with a bit-banging SD interface, because the code unfortunately assumed - rather subtly - that some undefined bit would be a zero. So a legit card - a rare one - wouldn't work.

It's also true that counterfeits abound and it's more difficult than you'd think to get a clean supply chain. See Bunny's blog here.

Thanks Ed,

Some good info linked.... and yes, I've seen some of this kind of thing before. Early days... many manufacturers would cross brand products as it's more economical.... then you have the rogue stuff, which is generally not acceptable quality but finds it's way on the market.

I need to do some additional testing on the CF Cards. As the earliest dates back to 1994, I actually have an early 96MB card... even the manufacturer is identified as SunDisk (which later became SanDisk). This card has a 1994 date on the back. Oddly, some of the newer ones I have are mid 2000 dates.... but what appears to be non-official cards are showing 1994 dates on 256MB cards, with a very late logo on the label.

It's possible that some of these oddball cards need some different timings and/or delays to be properly accessed. I also found some information on retrobrewcomputers.... where one of the posters who's building 68K boards needed to put some series resistance on the upper data lines and pull-up resistors on the lower data lines, otherwise he found corrupted data on transfers. Link:
https://www.retrobrewcomputers.org/doku ... cf_problem

For my own adapter, I think it's easy enough to get some original SanDisk cards and use those as they work fine. I'm also going to measure the current of the various cards as I found certain cards gave me problems with data corruption using the Xmodem-CRC download function in my Monitor code... swapping to a different power supply resolved it. I debugged the problem tot CRC check failures... the corrupted data was hex $00 data bytes being received as hex $80, but all other received bytes were fine, who knew? Oddly, the CF Card was never being accessed or even detected by using an earlier BIOS... just having it plugged in resulted in data corruption... change to a different CF Card, no problem... change the power supply and the problem goes away, and I'm using good quality supplies as well!

In any case, time to drag out a scope, logic analyzer and multimeter.... the fun of home brew systems!

_________________
Regards, KM
https://github.com/floobydust

Ah, sorry, I missed the point here that these are CF not SD. So I don't have any experience to offer - as you say, monitoring the bus activity is a good way to proceed, to find out what's happening. It could be timing, or voltage levels, for example, which aren't as expected.

I use compact flash cards in 8-bit "True-IDE" mode (hooked directly to the 8-bit data bus and I have a GAL that does address decoding as well as generating active low /RD and /WR signals). While all of the cards I have seem to support "True-IDE" mode, not all of them support 8-bit True-IDE mode. The ones that don't support it will raise the error flag immediately after you request it. Trying to access the card after that points shows that they did switch to IDE mode, but are in 16-bit mode (and I only get every other byte of data on my 8-bit bus).

Interesting to me is that it's only the "newer" cards I have that seem to support 8-bit IDE mode. I have a 2GB Sandisk "Ultra" and a 4GB Sandisk "Extreme III" that work, while my 128MB SanDisk "CompactFlash" and 256MB Lexar "Professional CompactFlash" cards do not support 8-bit mode.

While this doesn't directly answer your question, it at least shows that there are different levels of IDE support even among Sandisk branded cards. All of my cards were bought in-store, so I have reasonable faith they are what they say on the label.

Thanks for the additional info.... my hardware setup uses an Atmel ATF16V8BQL GAL to generate select signals for the two chip selects on the CF Card (in True IDE mode), plus the 4 lines that manage the upper byte latch and the DS1511 RTC. The RD and WR lines are generated by an Atmel ATF22V10CQZ, which is the single glue logic on the 65C02 SBC.

If you use the Identity command ($EC), you can access the 512-byte block that contains the card details... which will include the manufacturer, serial number, firmware revision, etc. This is likely the only way to tell what the brand of card is and some other interesting details.

On another note, I did some additional testing last night (software only). I found an odd issue with the non-SanDisk cards. Just moving the BIOS routines around in memory can result in failure to read the non-SanDisk cards. The routines themselves are identical, just their location in EEPROM changes and results in failures!

This reminds me of working with the Commodore 1581 diskette drive and modifying the source code. There's a macro in there that looks at the lower address lines. If an access to the WD1772 floppy controller falls on an odd 6502 address, the macro inserts a NOP to move the code down a byte. Without this "feature" the code doesn't work. I never did figure out why, but the problem I'm experiencing with non-SanDisk CF Cards seems to be a similar issue. As there's quite a few accesses in multiple routines to the CF Card, I'm going to try and implement a similar macro and see what happens... who knows!

I've made a few minor modifications to the hardware and PCB layout (non are for the problem described here), but they are:
1- add a jumper for the IRQ to the CF Card
2- add a jumper for the IRQ to the RTC chip
3- Remove the battery for kicstart feature on the RTC (it won't be used with the 65C02 SBC)
4- Fixed the CF Card PCB component
5- Rearranged some components and spread them out a bit

In testing, I found that if a routine goes awry and runs through memory, it can clobber the RTC. In several cases, this resulted in activating the interrupt from the DS1511 (RTC). As there's no ISR that services the RTC IRQ, the system hangs on a coldstart. I had to lift the IRQ output from the RTC to get the system up, then go and reset the RTC data, hence adding the IRQ jumper for it. I had some similar issues initially when writing the code for the CF Card, so opted to add an IRQ jumper for it as well.

_________________
Regards, KM
https://github.com/floobydust

That sounds like it may be a timing issue and if the bits on the address/data bus happen to have been the right value from the previous/next instruction it works. What speed is your SBC running at and do you qualify your *RD and *WR lines with PHI2 (I'm assuming yes, which makes them half a cycle long)?

The "True-IDE" interface in the CompactFlash specification has some historical connections to the ISA bus (it's really just an extension of most of the ISA bus out onto a ribbon cable), which had a maximum speed of 8MHz but took multiple cycles to transfer data. Accessing an IO port (like the configuration registers for the CF card) might use 4 cycles to transfer data with the the *IORD and *IOWR lines held low for 1.5-2 cycles. The minimum time for the *IORD signal to be asserted is 165ns in the ISA (and IDE) specification, and the CompactFlash specification has that exact same minimum time listed (I'm looking at Table 3-13 in the Sandisk CompactFlash Card OEM Product Manual available from https://media.digikey.com/pdf/Data%20Sheets/M-Systems%20Inc%20PDFs/SanDisk%20CompactFlash%20Memory.pdf. It's on page 33 in my PDF viewer (page "3-15" if you go by the page numbers on the bottom of each page).

If you are running a 4MHz clock and are qualifying the *RD and *WR signals with the PHI2 clock, then you will only be asserting them for half a cycle or around 125ns. If it's easy to do, you may want to try running your board on a slower clock (1MHz, for example) and see if your CompactFlash card in True-IDE mode behaves better at that speed.

You may want to just write a program that just reads or writes to one of the registers (you can write the LBA address all you want, for example) in a tight loop and verify the read and write timings with a scope.

I didn't even investigate timings when I started with my project, and now I wonder if my older cards don't work (in 8-bit IDE mode) because I'm simply accessing them too fast and the newer cards work because they are faster than the original CompactFlash specification. I'm running at 7.3728MHz on my SBC.

I've done some additional (software only) testing. In short, I'm not having any issues with the SanDisk CF Cards. I even have a very early 96MB Card which shows the manufacturer as SunDisk, so that's about as early as it gets. They work perfectly fine... just the ones that are non-SanDisk have issues... and are consistent.

As is proper, RD and WR signals are qualified with PH2, that's handled by the ATF22V10 as well. My C02 Pocket SBC has a design point of 6MHz, but I have one SCC2691 that runs at 8MHz, so that's my typical dev board setup... as I use the other ones (at 6MHz) for long term testing. I'm very familiar with the original ISA bus.... I was level 2 tech support for the IBM PC group from 1984 through the PS/2 line of machines.... and yes, I was there when we brought out the first machines with IDE drives. But as noted... 8MHz is pretty much the bus limit, albeit I had some modified PC-AT's and some un-announced systems boards that I had running reliably at 10MHz and 12.5MHz, as we were able to get early chips direct from Intel as samples and test.... fun times.

It's also crossed my mind that the STI sourced CF Cards are at their limit with bus timing. I'll switch out the can oscillator to a slower one and see if anything changes with the STI cards. I have noticed some odd bits about the identification block on these... they show LBA support, but show a 32-bit field of zero for available sectors but show the correct number of accessible LBAs. The STI cards don't have DMA support (the SanDisk cards do) but that doesn't matter as I'm using PIO mode with interrupts.

We have the same SanDisk doc.... I also have an older SanDisk doc and recently found a Transcend CF Card doc as well. For the most part they agree on details. I've since updated the BIOS to include sensing the LBA capability... it will provide a message on boot that LBA is not supported. Still some more work to do on the BIOS before it's really solid, but it's still relatively small in size.

My github page has the full schematics and code for the PLD used on the C02 Pocket SBC. I'll be adding the RTC-IDE adapter soon, but will probably get the Version 1.01 PCBs done and tested first. Thanks for the input of course.... I'll post back once I try a slower clock speed. Here's the schematic for the RTC-IDE adapter:

_________________
Regards, KM
https://github.com/floobydust

My understanding on the PIO timing is taken from the SanDisk documentation on page 36. PIO Mode 4 has a minimum cycle time of 120ns. This is based on the Identity Block, word 68, which is 120(ns). Based on this, the timing "should" be okay. The SanDisk and STI cards both show 120 in Word 68.

The only marginal timing in this PIO mode would be the Read and Write timing minimums of 70ns. I did swap out the oscillator to 4MHz, but the STI cards still function the same, so I need to look into this more deeply to see what's going on.

_________________
Regards, KM
https://github.com/floobydust

I didn't even realize that you could ask the CF card what its minimum timings were. I guess it makes sense, given the various speeds that ended up being made. I'd be interested in hearing if you find out what your issue ends up being.

For my application, the CF card is essentially a mini hard-drive for my SBC and I just ended up giving my board one of the CF cards that worked with it and putting the troublesome card in my camera, but it sounds like you would prefer general compatibility. Also, thanks for posting your schematic. Now that I know that some cards don't support True-IDE in 8-bit mode, I'd probably go for a 16-bit interface similar to what you've built if I were to do it again.

Well, I keep reading the Seagate and Sandisk documentation... and keep finding more details. It also turns out that the faster cycle times are for 16-bit data operations. But, back to my current status....

I haven't gotten around to getting the logic analyzer out due to lack of free time. I have done more software testing and have rewritten certain routines the in BIOS. Some to ensure error conditions and sensed and handled and also to check for LBA support. The STI flash card is still problematic, but I'm less focused on that specific card for now.

I am finding that some cards are not responding properly when reading or writing block numbers. Case in point, attempting to access a LBA that is out of range (higher than the total LBA count) should result in an error, with an extended error code of 21h (which is LBA out of range). Some CF Cards do work, while others show no error and there's no data transfer. I'm finding a similar issue when accessing a LBA in the higher range of the card, no error, but no data transfer either. I'm not sure of the CF Card is the problem or on my side (HW or SW), but I don't think it's on my side, so some additional testing yet to do.

As you're using a CF Card on your SBC, are you using some type of filesystem? I'd be interested to know how you're using it.

_________________
Regards, KM
https://github.com/floobydust

I'm using FAT32. The software to access the CF card is written in Forth (Tali Forth 2) and is a work in progress. I can currently change directories, get a directory listing, open a file for reading, seek around, read one byte or one line at a time, and check if you have reached the EOF. These are essentially all the things you can do without having to modify the FAT. I haven't worked up the courage (or the free time, really) to start on modifying the FAT yet.

I also got block support for Forth working, so you can create a block file (single file where every 1024 bytes is a new "screen" of code) and that's the only part of my code that reads and writes - it doesn't let you resize the file so it's only modifying the data in the already-assigned sectors and I create that block file on my Linux machine. Forth accesses the blocks by number and has a simple virtual memory system to bring them in and out of storage.

Forth doesn't care where the blocks come from, so once you write a block driver to save and recall the blocks, you can just use them in Forth. I usually set it up so an I2C EEPROM uses the lower block numbers and the FAT32-based block file is access by using higher block numbers. The driver support for the I2C EEPROM is in ROM, and I've been putting the FAT32 support in the EERPROM and using that almost like a boot disk to bring in the FAT32 support when I want to use the CF card.

With all of that said, I kinda wish I just did FAT16 support. The 32-bit numbers needed for FAT32 are a pain to juggle on TaliForth2's 16-bit stack. I also could have just used the CF card as a direct array of blocks, but that's more difficult (but possible in Linux) to deal with on the PC side.