The reason CF read strobe needs signal conditioning but not write strobe is because data corruption is caused by the read activities of CF drive. Another word, it is the simultaneous transition of multiple data lines from CF fast drivers that generates the worst amount of noise AND it is the fast response of CF's read strobe input that most readily affected by that noise. To elaborate, when CF read strobe is asserted, 8 or 16 CF data lines are driving simultaneously; the worst case is when data bus went from all zeros to all ones. All outputs want to go high, really fast, pushing against the capacitive data bus, so if there are significant resistance and inductance on the ground return, the CF ground will sink below the reference ground. All this is happening when CF read strobe is asserting low which has lower noise margin. When the CF ground sunk to -1.5V even briefly, the responsive CF read strobe would see a corresponding +1.5V spike which causes it to advance the FIFO to next data.

In the case of CF write, it is the slow retro computer driving 8-bit data bus with CF write strobe still negated high which has good noise margin. By the time CF write strobe is asserted, everything is quiet and stays quiet for hold time period after the negation of write strobe.

Having ground plane absolutely help mitigating the noise problem, but if you are using an CF adapter, you need to examine the ground traces from your quiet ground plane to CF disk ground. Sadly the cheap adapter readily available on eBay has not done a good job with ground returns.

The lesson here is mixing today's technology with yesterday's technology can be troublesome--not to yesterday's technology, but to today's technology.
Bill

Hi Bill,

I'm using a 4-layer PCB from ExpressPCB, their MiniBoard Pro service. This features a full ground plane and power plane as the two inner layers. It's also a pretty small PCB, at 2.5" x 3.8". For the Compact Flash socket, I'm using a 3M 7E50 CF Socket which is directly soldered to the PCB, hence no adapter. All lines are quite short as well, but... there's a very short 30-pin ribbon cable (about 2-inches long) that connects the SBC (also the same type of 4-later PCB) to the RTC/IDE-CF adapter board.

On the SBC, I use an ATF22V10CSQ PLD for generating the read and write strobes (qualified to Phase 2 CPU clock) and the I/O selects, of which one is used for the RTC/IDE-CF adapter. The adapter uses the ATF16V8BL to further decode the chips selects for the RTC, CF Card and upper 8-bit read and write latches.

It's a bit odd that authentic SanDisk cards function without issues... different sizes ranging from 16MB to 8GB without issue. Only the non-SanDisk cards are problematic. Then again, the older IBM Microdrive also functions without issue.

Of course, thanks for insight on this... you've obviously spent more time working with CF Cards than I have.

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

Perhaps this makes sense if one considers that the internal design of the CF card will also be better or worse as far as the return path for the signals, the amount of ground bounce induced by that, and so on?

plasmo, your explanation was very enlightening!

_________________
Curt J. Sampson - github.com/0cjs

Hi Curt,

Missed your earlier post on the previous page... all good points. Based on my post, I'm thinking the 4-layer PCBs with power and ground planes, coupled with short traces should minimize most issues. Of course, the 2-inch ribbon cable connecting the boards can be a source of problems... but I'm reworking the adapter for better power supply decoupling specifically for the CF Card socket. I can also add the 100-ohm series resistor and 100pF capacitor to the Read_Strobe line as well. Overall, I'm pretty happy with the current operation with the authentic SanDisk cards so far... but more compatibility would be welcome.

I'm currently doing all testing and coding with an 8MHz setup, albeit the actual spec will be with a 6MHz CPU clock, as I only have one SCC2691 UART that runs at 8MHz, all the rest are 6MHz reliable only. Perhaps a slightly slower clock will help as well, time will tell. And I agree.... Bill has some great insight on this stuff. I picked up his Tiny68K board last year... nice bit of kit running CP/M 68K.

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

Yup, sounds about right. Though from that video I mentioned, short traces are nice, but not really important in the overall scheme of things. It directly suggests that you use longer traces wherever that helps improve the return path.


Whup! I'd missed that bit! You do have a ground return adjacent to every signal line on that cable, right? If not, that really sounds like something that would help. (Or, at the very least, ensure that the read strobe has a ground line on either side.)


My guess would be that it would make no difference: even at 1 MHz, the same fast edges are going to cause exactly the same problems in asynchronous interfaces. (With synchronous interfaces, of course, you should have much more time in the clock cycle for the lines to settle before something tries to read them.)

_________________
Curt J. Sampson - github.com/0cjs

Tiny68K is when I started researching into the CF interface problem. Initially Tiny68K worked with just few brands of CF, Sandisk was one of the brands that worked. I added 100-ohm data terminating resistors for all 16 data lines, added 100pf/100ohm filter for CF read strobe, I even have a SIP resistor pulled up half of the data bus to 'precharge' the data bus so only the other half will see the worst case 0-to-1 transition. By rev2.1 (the one you have), it can handle most CF disks, but there are still a few it failed. I've contrived several CF diagnostics, but the most effective one is actually the CP/M command: PIP D:=A:[V] which is copy the working directory, A:, to directory D: with verify.

These pictures of CF disks I tested are over 2 years old and I've tested more since. The large collection of CF disks are relatively easy to interface to, the 3 CF disks in the small picture are the 'nasties'. If your CF drive can handle them, it is probably good. I've never conquered the 'nasties' with 680x0, but I was successful with Z80 and Z280. All my boards are 2-layer, a 4-layer Tiny68K probably can fix the outstanding CF problems.
Bill

Another issue with CF interface, completely unrelated to grounding and signal integrity issues, is setup time. The CF chip_select needs to be asserted ahead of CF read/write strobes, and chip_select must not negate before CF read/write strobes. The IDE spec is very conservative, but many CF disks will start to fail with lesser than 50nS setup. Sandisk can handle almost no setup time at all. Because 680x0 asserts read/write first before address strobe, I've seen several 680x0-based CF interface that connected 680x0 read/write to CF read/write and address qualified with address strobe to CF chip select. Very very few CF disks can handle that kind of timing. It is best to add wait states so you can assert CF chip_select first, wait a clock, then assert the read or write strobes, and then negate all signals at the same time.
Bill

I am working on a 6502 monitor from scratch, mostly to teach myself 6502 assembly and also because CRC65 is CFdisk-centric SBC which needs more CFdisk-related commands. I now have the basic 4-function monitor (load,run, display, modify) working. When powered up or reset, the monitor is automatically loaded by the CF bootstrap. Picture below shows the monitor booted after reset, displayed the help menu, executed examine/change memory, display memory, and run application (EhBASIC).

The CFdisk-related commands I plan to have are:

read a specified CF sector,
write a specified CF sector
read CF manufacture ID
test CF disk
format CF disk
save applications to CF
load & run applications
update CF bootstrap program

My plan is putting CF read functions (read sector, read ID, load applications) in the monitor but put the write functions as an utility application that can be loaded separately. The reason I'm segregating write functions from the read functions is because I'm concerned about these write functions can erase portion of CF disk and need to be kept away from normal use.

I have received an email from JLCPCB that my boards are shipped. I expect to have them Friday. Looking forward to build up a few boards.
Bill

CRC65 does not have interrupt sources on board, so I have not experimenting with 6502's interrupt yet. It does have two buses, a RC6502-like 39-pin parallel bus including both IRQ and NMI, and a I2C interface with IRQ. The prototype board does not have the RC6502 bus wired in (too many wires, I'm waiting for the PC board), but it does have the I2C interface, so I thought I'll work on a "clock" mini project.

The first mezzanine board contains a PCF8563 RTC which plugs in the I2C connector on CRC65 prototype. In turn, it has a 4-pin connector to accept a 128x64 OLED display. So there are two I2C devices on the bus, PCF8563 RTC and SSD1306 (OLED controller). The idea is having RTC generating periodic interrupt and display the time on the OLED. Another word, a clock.

This is a clock running on the prototype CRC65. The display is a 128x64 OLED driven with I2C and the time base is a PCF8563 RTC also driven with I2C.

PCF8563 RTC is programmed to generate 1Hz interrupt. The interrupt service routine clears the interrupt flag, updates the hour/minute/second variables and drives the clock display. Everything is done over the 2-wire I2C bus except a separate interrupt output from PCF8563 RTC to 6502's IRQ input.

Bulk of the work is in displaying the analog clock face. I'm not proficient enough to do line drawing calculations, so I used Excel spreadsheet to generate the three tables for hour, minute, and second hands, the 6502 basically uses the hour/minute/second values to lookup the corresponding set of pixel values in their respective tables and display them. I struggled quite a bit to get my head around the multi levels of indirect, indirect addressing. I think I've got it right finally. The program is 3.5K of 6502 assembly plus 8K for OLED display memory.

I have a separate utility that set the PCF8563 RTC with the correct time. The clock program reads the PCF8563 once at start up to initialize the local time and then uses the 1 Hz interrupt to update the local time variables. I plan to modify the CF bootstrap code so when power is initially applied, the clock program will be read into memory and run. So for once I will actually have an useful appliance based on retro technology!
Bill

Edit: Just now looking at this clock I'm thinking: I can buy a better clock, but I can not possibly pay more than this one!

An application! Excellent. It's but a small step to make this an alarm clock and a stopwatch... or egg timer.

I just read through this thread. This is a neat project with some impressive results.

Thank you. I'm still waiting for my pc boards. At least they are here in the USA last time I checked. BigEd's comment about alarm clock does make me want to design another board for the Arduino mega enclosure with clock, light and buzzer--a real appliance that may impress my bride of 38 years. Then again, maybe not...

My pc board shipment is taking a walkabout all over USA. It came through Los Angeles gateway early last Friday morning, then went to San Diego, then to Phoenix, to Tucson, back to Phoenix, and now is on hold in Cincinnati. I complained and DHL quickly replied with an apology--must be an AI customer assistance software. I probably have pissed off the Matrix and will never get the pc board now!
Bill

Edit, I probably should remind DHL, a Germany-based company, that Albuquerque is in New Mexico, Not Mexico!

Most unfortunate! I hate when that happens, but I've had similar situations over the years. Oddly I would have thought it would have gotten stuck in Phoenix, AZ..... DHL have a large facility there (or did), as I managed a SOA (Service Oriented Architecture) project with them back in the mid 2000's. Hoping you get your PCBs soon... looking forward to seeing what your first version looks like.

I wish I could configure the FPGA stuff like you do.... I'd have more fun!

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