Page 1 of 2

Q68 I2C addresses.

Posted: Sat Jun 08, 2019 4:52 pm
by Whopper
Hi All,

Please could someone confirm for me the memory addresses for the I2C clock and I2C data lines.

I seem to be able to control $1C1C4 & $1C1C6 but not $1C1C0.



Re: Q68 I2C addresses.

Posted: Sat Jun 08, 2019 6:33 pm
by Derek_Stewart

According to the Q68 manual, page 6:

    I²C Interface

    Provides an internal I²C master-only interface.It is also connected to the Q68 realtime clock DS1374, which occupies the binary I²C bus address 1101000.The Q68 supports I²C communication by two simple byte-wide registers:

    I2C_SCL at $1C1C0: I² Serial Clock output, 0=Low, 1=High
    I2C_SDA at $1C1C4: I² Serial Data input / output, 0=Low, 1=High (open-drain pullup)

    The Q68 normally expects the connected I²C slave devices operated at 3.3V.By an internal weak clamp diode, usage with 5V devices is also possible, provided the overall pullup resistance does not fall not below 470 

    The power output on the I²C bus connectore is shared with the extension bus.The maximum supply current specified there must not be exceeded by the sum of both currents.

I have no information about address $1C1C6, but I do some research on this and report back.

Re: Q68 I2C addresses.

Posted: Sat Jun 08, 2019 7:07 pm
by Whopper

Thanks for the reply.

I have also examined the Q68 manual and that section.

However While I can control $1C1C4, i.e. set it to 1 and read back a 1, then set it to 0 and read back a 0, I cannot set / reset $1C1C0. It remains a 0 no mater what I do. So I was wondering if the manual was in error and that $1C1C6 might be involved in some way.


Re: Q68 I2C addresses.

Posted: Sat Jun 08, 2019 10:34 pm
by Derek_Stewart

I do have any information on location $1C1C6

Are you sending the correct data format to the IC2_SCL location?

I was reliabley told that the Q68 Manual was correct.

I have some TF Services I2C interfaces, so can try the Q68 I2C interface.

Can you tell me which interface your using?

Re: Q68 I2C addresses.

Posted: Sun Jun 09, 2019 5:28 pm
by Whopper

Currently I am using SuperBasic PEEK & POKE to control the IO ports.

I intend to bitbilt the ports to drive the Q68s I2C pins directly. The pins themselves will drive a level changer to the desired voltage for the external device.

The coding is being done in assembler and C.

There are no I2C devices being used.


Re: Q68 I2C addresses.

Posted: Sun Jun 09, 2019 6:46 pm
by Dave
I played with the Q68 I2C port but found it unsatisfying. I got a lot of timing errors due to other events sharing CPU time, giving me no real ability to match the data with the clock, with no programming guidance given. Being limited to S*BASIC I just shifted my attention to the expansion port. I then found I needed accurate timing diagrams as some timings were different from a 40MHz 68SEC000. Peter is working on that part of the manual in free time.

I suggest you email Peter and ask him to expand on the I2C port.

Peter is very smart, so he is able to make conclusions from his own instructions that us ordinary folks can't reach ;) He does document clearly, but it not.... exhaustively?

I have always found him very willing to fill in the blanks. I think once two people ask him the same question, it becomes more a more efficient use of his time to simply expand the documentation. For every person that asks him, there are 5 who didn't but gave up.

Re: Q68 I2C addresses.

Posted: Sun Jun 09, 2019 8:19 pm
by martyn_hill
Hi Whopper and team

Whilst Peter will certainly be the authority here, I do recall reading that the Q68 I2C implementation is 'Minerva compatible', so might assume that using the Minerva's I2C published source code would provide a suitable set of primitives to base any further work - once the port addresses are replaced for the Q68 equivalents.

If so, then you might want to take a look at M_ii_drive_asm from the Minerva source tree.

Dave - you might have hit a problem with the standard SDRAM being contended periodically for video word access to build the display - whilst relatively 'infrequent', IIRC it can offset timing by 6uS or thereabouts each time it occurs - it was enough to mean that the Q68 Network code had to be moved in to the uncontended/fast 12kB SRAM block to give reliable code timings.

Watching with interest...

Re: Q68 I2C addresses.

Posted: Sun Jun 09, 2019 9:51 pm
by Derek_Stewart

According to the Q68 SMSQ/E manual, there is 10Kb of Fast Memory on the Q68, can the I2C code be loaded in the Fast Memory, then there should a reduce any contension.

As Martyn indicated the Q68 I2C interface is compatible withr the I2C interface on the Minerva MKII, so the TF Services I2C interfaces will work, just requires the IWC bitbanged code to drive the interface.

I have got the TF Services Analogue, Power, Relay Interfaces, so could connect them up to the Q68.

Re: Q68 I2C addresses.

Posted: Mon Jun 10, 2019 11:07 am
by Peter
There are no timing problems with Q68 I2C, one just needs to know how to do I2C bitbanging correctly (not a Q68-specific issue).
Unlike QL network, I2C has no maximum timing requirements that could be violated by the short delays caused by video burst. Using internal SRAM is not required.

Sometimes I used the Q68 32-bit high resolution clock at $1C060 to make Q68 I2C usage more efficient. That can be recommended, but it is also not required.

My hope was that bitbanging I2C is simple enough, so people could live without me providing example code. It seems not so - and I stille have providing I2C example code on my to-do-list. Sorry time is limited, and I need to give the technologically demanding issues higher priority.

The Q68 manual is correct regarding i2C addresses. Note that the clock register is output only, nothing you can read there.

Re: Q68 I2C addresses.

Posted: Mon Jun 10, 2019 1:05 pm
by Derek_Stewart
Hi Peter,

Does the I2C Bitbang code have be compiled or can interprted SBASIC provide the correct level of data to the I2C registers.