Hi,

we've been trying to connect a F18A (FPGA replacement of the TMS9918) to a 1MHz 6502 Apple 1 clone board. All the chip select signals (/CSW and /CSR) have been "phi2-qualified" but we still have troubles writing to the video chip.

After some troubleshooting (which included reading lot of posts on this forum ), we think we have identified the issue, namely the FPGA being too quick to read the data during the 6502 write cycle. There is a small delay ("tMDS" in the 6502 data sheet) after the rising edge of phi2 when the address is ready but the data is not. So we think the FPGA is sampling the bus too early.

Indeed if we repeat

the VRAM in the F18A doesn't get the accumulator's value, but $C0 gets written instead, which is the value that is present on the data bus just before the data byte because of opcode fetching of "sta $c000" ($C0 is the high byte of $C000).

We then tried to delay the phi2 signal (by adding chain of gates or by RC circuit), making some values being written but still all is very unreliable.

So my questions are:

1) why does the 6502 sets the R/W signal BEFORE the data is ready?

2) what is the "standard" way to write to a fast and asynchronous peripheral like the F18A? is some extra circuitry needed?

Any suggestion is appreciated as we are stuck on this project, thanks!

Welcome.

You need to latch the data in when phase 2 falls, not when it rises.

_________________
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?

welcome! (oops, crossed in the post)

I believe the right thing to do for a write is to sample address and data on the falling edge of phi2 - a fast FPGA won't need much time to deal with the inputs.

I believe we've also seen approaches where the FPGA (or firmware in the case of a soft peripheral) samples the inputs and control signals repeatedly and then uses the last sample where phi2 is high - in other words, one sample earlier than the falling edge.

Using the rising edge of phi2, an approach of taking a few more samples before deciding you have valid data should also work - depending of course on the two relative clock rates.

Whenever sampling signals which are asynchronous to the sample clock, it's wise to put them through one or two stages of a shift register before using them, to avoid metastability trouble. This is called synchronising, and it adds a few clocks of delay, but at the fast clock rate. As a slight refinement of that, it's often possible to synchronise just a few clock and/or control inputs and to use other inputs direct from a latch, but I wouldn't recommend being too clever at first: start by being safe.

thanks for the replies, so if my understanding is correct:

- when writing to I/O, data needs to be latched on phi2 falling edge and then processed by the I/O peripheral.
- when writing to RAM, phi2 rising edge can be used because temporary invalid data gets overwritten with good data when phi2 goes low, so it doesn't matter.

Regarding the metastability, it doesn't seem to be an issue on the real TMS9918, but certainly it is on the FPGA world. I wrote a FPGA implementation of the LM80C computer for the MiST and I had to add a one stage shift register on the whole chip interface to solve metastability; otherwise all reads and writes were garbage. (The LM80C has a 3.5 MHz Z80 and 10.738 MHz TMS9918).

(You can't really use the rising edge to get the bad data, unless you're writing transparently throughout the phi2 high period. Which is normal, I think, but it's better not to think of it as using the edge.)

@revaldinho did some long-running stability tests at one point and I think he found that one stage was OK but two stages was better, in his case. Possibly even three stages were needed to run reliably for several hours. So, be sure to test for long enough, and preferably with both elevated and depressed supply voltage, to explore the margins.

Agree. Better to consider a write to RAM as being the same as a write to a transparent latch -- ie; a 74xx373 (not 74xx374). (Notice this is consistent with what you said about temporary invalid data later getting overwritten with good data.)

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html