Finished wiring between RAM, CPLD, and 6502. This should allow me to power up and serially load program into RAM and execute. First I'm going to walk away for few hours to screw up enough courage to power it up.

Attached are schematic of the prototype board as well as the schematic of the CPLD.

After a nice lunch followed by a nap and puttering around in the garden, I decided to start out with a very simple program in ROM that just write an incrementing value to the transmit bit-bang register. Because data bit0 goes to the transmit output, I should see the output toggle every loop. This is just between CPLD and 6502, nobody else is involved.



And it works! With 7.37MHz clock I see a 409KHz square wave, 1.22uS high and 1.22 us low. 1.22uS is 9 7.37MHz clocks which is how long it takes to execute a loop. Current consumption is about 80mA.

Now a more complicated ROM program that reads a serial input, use it as the seed to run RAM diagnostic and toggles the serial transmit output when RAM diagnostic is completed correctly.



That works, too. So that means the wirings between 6502, CPLD, and RAM are correct.

This is also a good time to check the design margin. 14.7MHz clock works; 18.432MHz works; 20.28MHz works; but 22MHz failed, so the results are very similar to Proto65. I will now run the CRC65 at 14.7MHz

Now I need to go back to the bench and finish wiring up the compact flash interface and work on the bit-bang transmitter software. A good day!

Wiring on the CRC65 prototype is now completed. The attached photos show the component and solder sides of the completed CRC65 prototype. Now testings begin.

The first order of business is to write the bit-bang transmitter. The CPU clock is 14.7456MHz; each bit of 115200 is 128 clocks. Here is my attempt at creating 128 clocks delay for each bit of the data transmitted.



When writing to the bit-bang address, data bit 0 goes to the transmitter output. So the basic idea is putting value to be transmitted in the accumulator and write to the bit-bang address; the least significant bit will go out (serial transmit is least significant bit first, most significant bit last), rotate right, wait the appropriate time and write to the bit-bang address again. Do this 8 times to transmit the serial data. But wait, I also need to do the start bit and stop bit. Start bit is always 0, so I clear the carry flag and rotate left so carry is now data bit 0 (bit 7 is now in the carry flag). I can do the above algorithm 9 times to transmit start bit and 8 data bit. I then finish off by transmitting the stop bit and wait 1 bit time before exiting. I measured the serial transmit with a scope and it looks right. I do have to make sure the branch instruction does not cross page boundary.

With the bit-bang transmitter working, I wrote a little program to examine the Master Boot Record of the compact flash. Below is what it read. It looks right; bootstrap loader in first 14 lines; partition entry at 0x1BE and boot signiture of 0x55AA at the end.


Another good day.

Once the CF interface and bit-bang transmitter are working, the rest fall in place quickly.

EhBASIC is updated with bit-bang transmit algorithm so is the 256-byte Intel Hex file loader. So now EhBASIC can be loaded and run. An utility to write bootstrap program to CF's master boot record is also updated so now it can save EhBASIC in CF disk and retrieve it on next power cycle. The first picture shows that after a reset EhBASIC is copied from CF to memory (each dot represents a 512-byte sector copied), and EhBASIC running. I copy-paste the mandelbrot program and it ran in 77 seconds.

I measured the CF file transfer rate: EhBASIC resides on 21 sectors (10.5KB) and it took 17.3mS to transfer it from CF to memory. So that's about 600KB/sec. This is CF operating in PIO mode.

Last but not least is the I2C interface. It is working.

There are more testings to do, but I'm ready for pc board layout.
Bill

Nice to see such quick progress on this... I like how quickly you can manage the CPLD coding, impressive.

I've also been working on an IDE/RTC adapter for my C02 Pocket SBC. The hardware uses a set of latches to allow 16-bit data transfers and the BIOS code uses an interrupt service routine. I also run in PIO mode... with the 65C02 running at 8MHz, I can get data transfer rates around 300KB per second. Needless to say, this is mainly based on how quickly you can access the CF Card and move the data into memory. As you're running closer to 15MHz, that seems to be faster than what I'm getting. I'm thinking you're using the CPLD to interface to the CF Card?

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

Thank you, I designed with Altera CPLD in 1990's but moved on to their FPGA after 2000's. I did not appreciate their ROM capabilities until I revisited EPM7000 in the last few years. I bought a large salvage lot of EPM7128S and 7064S in 2008 when a local factory went out of business, so I'll be using them for many years to come.

The CF disk is operating in 8-bit mode with Set Feature command, so CF data bus is connected directly to 6502's data bus. Some CF disks are faster than others, so the PIO transfer rate may vary depends on the brand. running 6502 at 14.7MHz also improve the data transfer rate significantly, so 300KB/S at 8MHz is probably about right. My CPLD is not involved in the CF data path; CPLD generates the 3 CF control signals, CF write strobe, CF read strobe, and CF chip select. It also inserts 4 wait states for CF access.

Bill

Edit, you can find the schematics for CRC65 prototype board and CPLD in my Jan 7, 12:34pm post.

Thanks for the clarification on your CF Card interface. I did see that you were using an 8-bit transfer, but apparently it doesn't slow things down on the data transfer.

I just opted to implement a 16-bit data transfer... using an ATF16V8BQL to generate the CS0 and CS1 selects, along with the 4 control lines for the upper 8-bit latches. So far, all of the (working) CF Cards I have show as PIO mode 4, which is 120ns access time. As a result, I'm not using any wait states, nor is the hardware setup to introduce them.

I also found a few cards that just don't work very well for me... some are labeled as SanDisk, albeit the identity data shows as no actual manufacturer. Another is a STI card (labeled Cisco), which doesn't work. However, I do have an original 340MB IBM Microdrive which works perfectly. I'm just planning to stick with the true SanDisk cards for now. I've limited my BIOS routines for up to an 8GB CF Card and have tested with a SanDisk 8GB to confirm proper operation.

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

The CF data register becomes a fast 512-byte FIFO once the read command is accepted and executing. (when the DRQ flag is asserted). The data transfer bottleneck (in PIO mode) is 6502 which is limited by how fast it can move 8-bit data from CF data register to memory. Whether the data port is 8-bit or 16-bit really does not make a difference, in fact I suspect juggling 16-bit wide data into 8-bit data path may actually be slower than straight 8-bit-to-8-bit transfer.

CF-to-CF incompatibility is actually a long topic (SD cards also have their problems, too). Sadly I have lots of recent experiences and a large piles of CF disks to show for it. The bottom line is this: if a CF disk can be formatted, written, and verified on a PC or workstation, then the problem is not with the CF disk. I tend to have relaxed attitude toward prototyping, PC board layout, and transmission line effects because retro technology are too slow to matter EXCEPT with the CF interface. Because CF disk is modern technology operating at 5V, it generates tremendous amount of noises that's data dependent; it is worst when switching from all zeros to all ones and back. The retro technology actually ignore most of these noises, the problem is self-inflicted, that noises generate glitch on the CF read strobe causes a spurious read strobe. Serial termination, signal conditioning, reducing data bus width from 16 to 8, and even pull up half of the data bus and pull down the other half were techniques I've tried. Boil all that down is this: 8-bit is quieter than 16-bit; a 100 ohm series resistor and 100pF capacitor to ground for CF_read strobe is important; and 100 ohm source termination for data lines are desirable.

Bill

I layout the pc board for CRC65 and sent it off to JLCPCB yesterday. JLCPCB must be working the weekend because this morning I received their production notification and the picture of my board. This design meets my goal of 50mm X 100mm 2-layer pc board so I can step & repeat the Gerber artworks and produce 2 boards per 100mm X 100mm panel thus driving the board price to $0.5 each. But of course, the shipping cost will probably triple that.

I'm doing speed test of the prototype CRC65 and verify it can still run to 20.28MHz. However, the CPLD is already fully utilized so some functions have to be sacrificed to enable the additional logic needed for 20.28MHz operation. So while I do have the speed margin for higher clock, CRC65 design in current form is locked to 14.7MHz clock.

I'll look into Klaus' 6502 function test and work on a monitor for CRC65 while waiting for the pc board. Homepage for CRC65 is under construction here: https://www.retrobrewcomputers.org/doku ... asmo:crc65
Bill

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Given that they do five 10×10 boards for $2, doesn't the price per board come down to $0.20 each? They also do an almost-as good price of $5 for ten 10×10 boards, which seems to increase shipping by only about 25%, so there's some savings there, too.

But how do you separate the boards when you do this? Is there a way to specify some sort of "crease" on these panels when you make the doubled-up Gerber files, or do you just leave a bit of space and saw them apart very carefully?

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

Unfortunately, JLCPCB charges "engineering fee" for making V-cut. The last time (about a year ago) the engineering fee was $8, so it makes no sense to go with JLCPCB for multiple designs on a panel. I use SeeedStudio instead. Seeed charges $4.90 for 10 panels up to 100mm x 100mm and does not charge extra for v-cut, but SeeedStudio is quite a bit slower than JLCPCB so I only send them designs that have been proven and pick the cheapest shipping. Even in that case shipping is still more expensive than pc boards.

V-cut is shallow cut with a V-shape router bit on both sides of a pc board. The router bit cut about 20% into the board, weaken it so a steady bending pressure will snap the board cleanly in half. Zoom in around the red arrows and you can see the v-shape groove. V-cut is also quite thin and can be precisely placed right next to circuitry. In the picture the thick traces next to v-cut is 0.025", there is not much clearance between V-cut and trace.
Bill

Great advise and wisdom.

Thanks for this information... nothing like having a lot of experience in implementation. I'm wondering why the read-strobe line is more of the problem and it appears that the write_strobe isn't affected.

On my hardware, I did notice in some cases I was getting some data corruption doing a Xmodem transfer with the CF Card adapter attached (CF Card not accessed during Xmodem). Changing the power supply to a different one did resolve this however. Scoping the power supply line didn't show anything between different supplies. I'm also using 4-layer PCBs with heavier supply traces to all components and have a lot of bypass capacitors and numerous 68uF polymer electrolytic capacitors (5 in total).

I'm in the process of a re-design of the RTC/IDE-CF adapter and have added additional supply filtering to the CF Card. I have an extra output pin on the ATF16V8 PLD I use for address decoding and chip selects. I can configure this output to drive the read_strobe on the CF Card and insert the 100-ohm resistor and 100pF capacitor. This should isolate the CF read_strobe from the rest of the system. Any thoughts on this approach?

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

Maybe this is just me having recently watched too many videos on signal integrity, but could it be that these lines on many cards are particularly sensitive to even very short and small glitches, and great care with the return paths for those signals would help? If you don't have an absolutely continuous ground plane directly underneath the the entire line all the way back to the source of the signal, perhaps running a second ground line in parallel to the signal line could help? I might even go so far as to sandwitch the read and write strobes between three ground lines. (Note that in this case, putting the traces as close together as possible should be optimal: that field between the signal and ground traces is what's actually transferring the power.)


That sounds like something to do with impedence matching and/or slowing down the edges, both of which make sense from what I've learned. (In particular, edges that are too fast for a design seems to be the biggest source of issues in signal integrity.)

Another thing you might consider, if you have a spare pin or two (like anyone ever does :-P), is holding an adjacent output pin to ground and ensuring your return path comes right up to that. This should, in theory, take the return path through the bond wires in the package and, perhaps more importantly, reduce the issues caused by multiple pins switching at the same time. Or so it seems to me. (Again, take this all with a grain of salt.)

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