I don't believe I was getting the acknowledge. I'll check this morning!

I just realized that I made a small change to the registers from table 4. I write the value $12 to register $00, instead of $01. With $01 the screen remains black.

Here's a copy of my bit file: main.bit. It should produce colorbars in NTSC format. On my PAL TV, I see them in B/W, which is what I would expect from the signal.

Edit: the bit file produces composite out. I haven't checked the other outputs, but it could be that they aren't working, because there are separate amplifiers and enable bits.

Right. I have enough info thanks to those waveforms you posted. I see the value $03, then the low for a write, then the ACK. I see the 3 ACK's. Now I understand I2C. It finally 'clicked'!

I don't see the ACK's on my board. I separated the short mentioned before. Troubleshooting... My SCL is right at 100kHz. I'm going to reflow the solder on the CS4954.

Did you try the bit file ? It will be a simple test to check for hardware problems. You've tried the other bit file before, the one that generated the screen with the blue border, and black/white bars in varying widths. Since that one worked, I wouldn't expect a hardware problem at this point.

Edit: if you want, you can also send me your bit files, and I'll try them on my board to see if they work.

Ah you're right. It should work.
I've tried getting an ACK from the 1 DS1085 I have on the bus too. Nothing. So I went back to the original 65Org16. Still nothing, and the waveforms look exactly like the DS1085 datasheet!

I will modify my program for the original 65Org16 to send the following values in a loop: $00,$03,$01. Right now it waits for a keypress from the PS2 keyboard to send the data while running C'mon on the TFT. Give me a few minutes.

The 'ifdef' statements! I just realized I had been copying and pasting the cpu.v verilog file from my testbench for simulation right into my project folder. This must be it. Sec...

EDIT: Clarified file as cpu.v

That wasn't it. Sorry. I have a another task to complete that will take a few hours.

I apologize for having left as bruptly as I did. Family matter, no worries...

I came home, tested again with the latest .b core and a loop on my main TFT project top level schematic, with the 65Org16 software gutted except for your I2C software sending 3 bytes: $00, $03, $01. Then a $FFFF countdown delay and it all starts over. I am still seeing no ACKs. Had to use the sample function on my scope as there is no steady trigger.

Here is the top_level .bit file.

EDIT: This file server is much better. File is only available for 7 days though.
EDIT: This one is correct. Looking at it this morning I found a bne A, instead of a bne AA. Was looping into never never land. Signals are stable now. No ACKs.

I am really stuck here. Arlet, if your .bit project file outputs a good video signal this means my hardware is OK. I am seeing good signals on the scope for SCL and SDA, using my project file, which means the software and .b core are OK. So what possibilities are left for no ACK?

I'll try your bit file tonight when I get back from work. Maybe that'll reveal something...

I have a feeling you will see what I am seeing.... Been doing some more testing.

I've run your I2C progam through M. Kowalski's simulator to try to get a feel for what is going on. And now something is clear to me that wasn't so clear before, i.e. why you were doing an ADC #$00. When sending a zero data, the last shift will set the carry flag and add a $01 to the Accumulator, sending SDA high. Which is not happening in my case. I have tested the carry on the .b core and it seems to be ok. I have a hunch that the carry is being set 1 cycle too late on the .b core. This probably means my decoding is not tight enough... And I can see right now a load_reg is being performed incorrectly on a CLC, and SEC. I will fix this and restest.

Oh, I also just realized you SEC and ROL 8x to get the carry set after 8 ROLs. In my case it is 16 ROLs. I must do 8 ROLs right after the SEC. Testing...

Yes, I just tested your top level bit file, and it doesn't work on my board. Your SDA doesn't go back high after the 8th clock pulse. The I2C ACK means that the client device pulls the SDA down at the 9th clock, but that only works if the master lets it go back high first.

My code is a bit tricky. It shifts out 8 bits from the 8 bit data register, but then it shifts out a 9th bit from the same place. Because of this code in i2c_wrbyte:the 9th bit is always a '1'. Because you have a 16 bit CPU, the SEC is not effective. Instead, at the top of the i2c_wrbyte routine, you should move the 8 data bits to the most significant 8 bits (shift left , and then ORA #$0080 to make sure the 9th bit is set before entering the loop. The SEC instruction in the loop can be removed.

No, if you do 8 ROLs, the entire data byte will be gone. You need to do 1 ROL per loop iteration, to shift out 1 bit at at time.

You can also e-mail the file directly if you prefer.