I've been playing around with I2C on my 65C02GPD board over the last few days and, as I'm not overly familiar with I2C, have been looking at various tutorials.
I'm now building a small library of routines. Remembering what Garth has said regarding using PB7 as a clock and PB0 as data, I've followed this and am now using the following test circuit along with using a clock cycle stepper to see the affects of my code (the LEDs and R1 & R2 allow me to see the condition of the lines at a glance).

As an aside: The good thing about the above test circuit is that due to the resistor values the LEDs are dim when PB7 / PB0 are high by setting the pins to input (so they float high). If the pins (due to coding errors) drive the lines high then more current is allowed to flow through the LEDs (as it's now coming from the VIA) and so they are glow brighter. A good way of spotting a mistake as the only time the PB7 / PB0 pins should be drive is to hold them low.

Now, my code works by setting the output value for PB0 and PB7 as low so that if the DDR (data direction) for any of those pins is set to output (high) then those lines go low. If the DDR is set to input (low) then the lines float high because of the pull up resistors R3 and R4.

I've built the basic initialisation, start and stop routines by myself and have no started on the byte send routine. I've based it off of Garth's "generic" (but very efficient) code here:
http://wilsonminesco.com/6502primer/GENRLI2C.ASM

I've tried to implement this code, but noticed that when I pulse the clock low (PB7) then back high again and the data (PB0) is low, data goes high at the same time as the clock goes low. I'm scratching my head as to why.

Here's my code:

Actually, I think I've gotten the INC and DEC the wrong way around. Will test shortly.

[edit] Yep, that was it. Meh, I hate it when I look at something for ages and find out that the solution has been staring me in the face all along .
BTW we need a face-palm icon

Ok, got the protocol the wrong way around (hence INC and DEC not working as originally written. Clock must start out low and pulse high when data is ready then back low.

Just a quick note, you stated PB7 is the clock line and PB0 is the data but that should have been the other way around. Your code is correct, PB7 is data and PB0 is clock. Good work so far. What I2C devices do you plan to use?

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Yes, bit 0 for clock and bit 7 for data. INC DEC will put a positive pulse on the clock in bit 0 without affecting the other bits, as long as you be sure to start with it being a 0. Bit 7 is automatically transferred to the N bit to test after many of the operations, so it makes sense to have that be the data.

As a possible tip for efficiency: your STA &0000 in some assemblers may assemble a three-byte absolute instruction 8D 00 00, rather than a two-byte ZP instruction 85 00, and will take an extra cycle. STA &00 (or STA $00 or STA 00H in most assemblers, or just STA 0 since 0 is 0 in any base) will assemble the more-efficient two-byte instruction.

It would be good to give the location a meaningful name though, and refer to it by that name in the code. When you come back to it to improve it two years later, you'll need the name telling you what that location is supposed to contain. Also, if you need to change the location, giving it a name takes away the need to change a number in every line it's used. You'll only need to change it in the one line where it's assigned, for example,
or your assembler may offer a way to consecutively assign variables, so if you decide one in the middle of the list now needs three bytes instead of two, you don't have to manually adjust all the EQU's that come after it. The 2500AD assembler I used from the mid 80's to the mid-90's used BLKB, meaning, "Allot a block of n bytes," where 'n' was the parameter given after the BLKB directive, like in this line which gave the next two available bytes to variable KEY_TM ("key time"):

Assuming your assembler allows it (I haven't seen any that don't), putting the comments to the right of the instructions will make the source code a lot easier to look at.

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

Agreed. These old eyes were having some difficulty with banedon's source, for that reason.

Mike B.

Yeesh! Mike, a fella who's only in his forties has no business complaining about his "old eyes" !!

So wait til Monday, eh? Happy birthday in advance,

Jeff

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

Thanks for the input, guys.
I've progressed a little bit further. I've now got my source code for writing a byte and also checking the the ack signal.
I'm now working on trying to read a byte that I've written (will test that tomorrow).

With regard to the &0000 memory location: I was going to change this to a variable name in code clean-up (I put &0000 just so that it stands out). My assembler automatically puts it in zero page address mode, so no biggie although I do see your concern if I use a different assembler.

As for comments on the same line within my code: Unfortunately, my home-made/not-quite-finished assembler doesn't yet support this, but I'll add this in when I get the chance. In the meantime I'll try and format my code to make it a little easier to read if I post it. BTW I tend to use notepad++ to write 6502 in as I've created a custom 6502 xml "language" in it which highlights commands, comments, etc. in different colours and so is very easy to read. It's when I post the code it looks a bit gack.

I2C device-wise, I have four 24AA1026-I/P 1Mbit EEPROMs (each chip has 2 banks of 512Kbits), some RAM and also a serial RTC somewhere which I intend to dig out and use.
Ideally, I'll be adding an extra VIA to the next version of my 65C02GPD PCB which will be dedicated to system devices such as at least two of the above EEPROMs ICs and an RTC. I'll also being looking around to see what else I can get in I2C.
With the EEPROMs I can reserve a portion of one of the banks in one IC for the BIOS settings, etc. and the rest can be used by user programs.

Oh, and yes I did indeed get completely turned around when I posted earlier with SCL and SDA. PB7 is SDA (data) and PB0 is SCL (clock).

I'm also in my forties and the ol' eye sight is definitely beginning to degrade (along with a few other bits ).

I brought this up recently in one of Randall Meyer's (the biologist's) topics, but in case you din't see it:
For a hobbyist-friendly I²C connector for little plug-in I²C modules, I'd like to recommend our I2C-6, shown and described at viewtopic.php?f=4&t=2155, along with reasons. Daryl (8BIT, who posted above) put it on his SBC-4 which he sells.

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