6502.org

The internet, being the fount of all knowledge, offers two options.

Pins are numbered 1-25 on one row, and 26-50 on the other... but the question is, is the 1/26 end the end with the thin groove, or the thick groove.

https://en.wikibooks.org/wiki/Practical ... lash_cards suggests it's the thick groove, but https://connector.pinoutguide.com/50_pi ... sh_female/ suggests rather the opposite (without explicitly saying so!)

My test board is laid out with 1/26 at the thick groove, and I'm currently clutching at straws in the 'why doesn't it do anything' stakes... maybe it is indeed upside down.

Anyone got a working CF design that they can confirm with?

Thanks,

Neil

Or as a flash of inspiration suggests, is my footprint wrong in another way?

Looking _into_ the CF card sockets, top right is connected to what is referred to as pin 1 on the footprint... and I'm wondering if that ought to be pin 26 and I've got the rows swapped... that could answer a lot of questions!

Neil

Looking into the CF socket (e.g. you are looking at pins, facing you, that you would plug the end of the CompactFlash card into), if the LARGER slot on the side of the CF card would go to your right, then I believe pin1 is lower right (based on socket pinouts from Hirose and Wurth connectors).

Ignore the fact that the socket is upside down in this drawing - you can get them in both "label up" and "label down" configurations. Instead, look at the skinny and wider polarity slots on the sides. This view is looking into the connector at the pins that you card will plug into. Edited for spelling.

Thanks Sam,

On my socket the wider slot is on the left looking into it from the card. That's t'other way up from your example, and so puts pin one top left, with a longer pin on the socket than most of the others (pin 13, pin 38, and pin 50 are also longer; pins 25 and 26 are shorter). It looks like the power pins are designed to connect first, then the normal pins, then the card detect pins last.

That's a bit depressing; I appear to have got the correct footprint. Looking into the _card_ and that seems to be what my PCB is doing. Oh well, I'll try a reflow of the connection - it looks a bit rough - and then once more into the programming. Before I bolt this onto a 6502 I'm driving the control signals directly on my test PCB, so it's possible there's something screwy there.

Neil

edit: corrected pin numbering.
edit 2: corrected narrow and wide slot positions

When I was playing with CompactFlash, I wired it directly to the 6502 bus (8 data lines and bottom 4 address lines) and had a GAL that generated the separate RD* and WR* signals and a chip select.
I activated it in IDE 8-bit mode by writing $04 to the STATUS register (reset the card), with busy polling of the high bit of the STATUS register to see when it's done, then writing $01 to the FEATURE register and finally $EF to the STATUS register. It's worth mentioning that only about half of my compact flash cards will initialize in 8-bit IDE mode.
Most of my software to access the card was written in Forth. I wrote enough support to read files off a FAT32 partition on the card. I can probably locate my hardware if you need more help at the hardware level.

Thanks Sam. I don't think I'm polling after the $01 to FEATURE, but I should get more chance to investigate. At the moment I'm not even reading the info block.

Neil

I only polled after the reset command at the beginning. I didn't poll after $01 to FEATURE or $EF to STATUS. My board is running at 7-8MHz. The next time I poll is right after sending a READ SECTORS command ($20 to STATUS).

I had better luck with older cards. Some of the newer ones, it appears, do not support the 8-bit access mode. I have seen other designs with latches that allow capturing or setting the high 8 bits during reads and writes, allowing 16-bit access to the card, but I never got around to building that and just made do with the handful of cards I had that did work.

I would think that the command to identify the drive should work, at least enough to get every other byte if turning on 8-bit mode failed. If that's not working, then it's possible that one of the several selection/enable lines is not set properly. I think I have several tied to GND or VCC. Do you have a schematic or good photo showing how you have it hooked up at the moment?

I think it's fairly common to just use every other byte, if that works for you.

Set FEATURE to 8-bit should work. CF is fast, so it is faster to set it to 8-bit mode than high/low access in 16-bit mode. Problem with CF access is because it is so fast that simultaneous switching of 16 or 8 data bits can glitch the ground which, in turn, glitch the control lines causing spurious read or writes. Signal integrity is important interfacing to CF.
Bill

Odd: single stepping through the driver code shows the correct bits set on the output pins of the Nucleo in the debugger, but they're staying low with the card in. Further investigation probably tomorrow (if I don't go flying ) but possibilities:

1 - check levels with card removed. If they're still wrong, I'm setting up the ARM chip incorrectly.
2 - start with an initial wait for the card to become ready - I've seen mention that in some cases that can take many seconds.

Circuit is about as simple as possible, and compliant with many examples (all of which seem to be derived from the same source, but I don't know where that source is).
Neil

Aha! Looks like I've screwed up the pin direction and data port commands on the ARM. Not fixed yet, but possibly getting there...

Neil

I checked my notes and it looks like I didn't have issues with 8 vs 16-bit, but rather trying to get it into True-IDE mode. The SanDisk and Lexar cards I had worked fine, but some of the newer no-name brands did not work. I never ended up investigating the ones that didn't work any further than finding that others on the interwebs have also had cards that don't do True-IDE mode.

I'm interested to hear if you end up getting this working. Once I got mine working, I found it so much easier to work with than sd cards. At some point in time, I do want to interface to a real spinny disk (is that retro now? - it would have to be an IDE or PATA type). Virtually all of the real hard drives don't support the 8-bit IDE interface, so I really would need to build a 16-bit interface for that.

You mention an ARM - is that just for testing or is that its final configuration? If you are going to hook it up to a 6502 system, are you going to put it on a 6522 or wire it directly to the bus?

Sam,

This is displacement activity while I think about my almost-working 128 byte roms... I'm currently using an ARM STM32L073 on a Nucleo dev board with a small PCB that fits the Nucleo pins and holds the CF just as a proof of concept. The GPIO from that should be able to talk to the CF at 3.3v (all except a couple are 5v tolerant as inputs) and a similar idea used as an eeprom programmer works pretty well, but I fear I haven't got my head around the direction changes on the data bus.

I'm using a single 16-bit port (GPIOB) with the lower eight bits for data, three bits for register address, one unused, and the remaining four for ~cs0, ~rd, ~wr, and ~reset. I've tried various approaches and I think the issue is to do with the sequence of pins being driven.

The data pins are by default inputs (and set so after any write) so a read just needs the address bits set, ~cs0 and ~rd setting low, reading the input port after 300ns, and pulling ~cs0 and ~rd high again.

A write is a bit more complex because I have to include the data in the output port, then change the direction of the lower 8 bits to output. There could be an issue there because the top bits are permanently output so the ~cs0 and ~wr pins drop before the data is available. It might be worth rethinking that port to keep those bits as inputs with pull high until I need them - something for the morning?

Because at the moment, I'm not seeing anything useful; reading the ports produces the same value on each read, but not consistently.

Neil

This is really doing my head in now... I have read so many data sheets and timing diagrams that I'm dreaming the damn things...

I have tried now with three different makes of CF: SanDisk, Kingston, and a no-name generic part with no joy; all give me a card information block full of zeros. The basic pinout can be found here from Grant: http://searle.x10host.com/cpm/CFConnPinout.jpg and I found a comment in a SanDisk datasheet that indicated that pin 33 should be grounded for 3.3v work. It made no difference.

Neil