Q68, QL-NET and I2C

Nagging hardware related question? Post here!
Post Reply
FrancoisLanciault
Trump Card
Posts: 167
Joined: Mon Aug 08, 2011 11:08 pm

Q68, QL-NET and I2C

Post by FrancoisLanciault »

Hi,

Hope to have some spare time during the holidays. On the program: using I2C on the Q68 and one day, the QL-NET.

A few questions:

I2C:

From the Q68 user manual, I see that the two I2C pins can be controlled by writing bytes at address $1C1C0 and $1C1C4. I also remember reading that there is no support in the operating system for any kind of I2C communication (yet) and that the idea would be to "bitbang" those two registers at the correct speed and following the correct protocol to have a functioning bus. Fair enough, I can start working on this. I guess the code should be ran from SRAM in order for it to run at a constant speed whatever the display resolution chosen.

However the utility Q68SETRTC already exist to communicate, via I2C, to the real time clock. Could some code be re-used from this utility ? Is the source code available ? Does this utility communicate to the I2C bus in 68000 code bitbanging those same $1c1C0 and $1c1c4 address or does it "talk" to the FPGA and it is the FPGA that takes care of the I2C protocol ?

The manual states that the DATA pin has a internal 10kOhms pull up resistor. Does the clock signal also have a pull up resistor ?

QL-NET

Here is what I understand is needed to have a working QL-NET on the Q68.

Produce the small electronic add-on needed and wire it to the QLNET pin#4 on the Q68 bus, to the +5V (or 3.3V ?) pin and to Ground. This add on circuit was posted long ago by someone, need to find it again. (easy)

Re-introduce the QL-NET code in the SMSQ/E OS for Q68. (I have not enough knowledge about the SMSQ/E compilation process to do this myself unfortunately)
Modify the QL-NET code in order to talk to the new QLNET pin on the Q68 bus instead of the way it was done on a regular QL. (No idea what is involved here but someone must know. This is probably the most time consuming aspect of the project)
Modify all software timing loops to adjust for Q68 SRAM speed. (I can help with this, have a scope and many QL systems for reference, however a good understanding of the QLNET driver is needed to know where those timing loops are implemented)

So, it seems that for the QL-NET, I cannot do much myself, but I will contribute as much as possible is other parties want to help.

François


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Q68, QL-NET and I2C

Post by Dave »

I sent you an email.


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68, QL-NET and I2C

Post by Peter »

FrancoisLanciault wrote:I also remember reading that there is no support in the operating system for any kind of I2C communication (yet) and that the idea would be to "bitbang" those two registers at the correct speed and following the correct protocol to have a functioning bus. Fair enough, I can start working on this. I guess the code should be ran from SRAM in order for it to run at a constant speed whatever the display resolution chosen.
Constant speed is not required for I2C, it should just not be too fast. There is very little SRAM, so it should only be used if speed is critical. I2C is low speed, so unless there are very special applications, normal SDRAM is okay.
FrancoisLanciault wrote:However the utility Q68SETRTC already exist to communicate, via I2C, to the real time clock. Could some code be re-used from this utility ?
Depends for what it should be re-used. It is written in C, you might want assembler. Much better to use the Minerva I2C routines as a "standard" driver interface (they also do bitbanging). The Q68 high resolution timer (yet to be documented) could be used instead of instruction loops to generate delays.
FrancoisLanciault wrote:Is the source code available ?
I did not release it, because my code is undocumented and not an example for general I2C programming.
FrancoisLanciault wrote:Does this utility communicate to the I2C bus in 68000 code bitbanging those same $1c1C0 and $1c1c4 address or does it "talk" to the FPGA and it is the FPGA that takes care of the I2C protocol?
It simply bitbangs. There is no hardware support for the actual I2C protocol inside the FPGA.
FrancoisLanciault wrote:The manual states that the DATA pin has a internal 10kOhms pull up resistor. Does the clock signal also have a pull up resistor ?
No. The Q68 is always master, so it drives the clock as output.
FrancoisLanciault wrote:So, it seems that for the QL-NET, I cannot do much myself, but I will contribute as much as possible is other parties want to help.
There is ongoing implementation effort.

All the best
Peter


FrancoisLanciault
Trump Card
Posts: 167
Joined: Mon Aug 08, 2011 11:08 pm

Re: Q68, QL-NET and I2C

Post by FrancoisLanciault »

Peter wrote: Constant speed is not required for I2C, it should just not be too fast. There is very little SRAM, so it should only be used if speed is critical. I2C is low speed, so unless there are very special applications, normal SDRAM is okay.
Ok, good to know. I get it now, data follow the clock signal, clock signal can run at any speed, but not too fast . I will pull up the I2C standard and read it.
Peter wrote: Much better to use the Minerva I2C routines as a "standard" driver interface (they also do bitbanging). The Q68 high resolution timer (yet to be documented) could be used instead of instruction loops to generate delays.
The Minerva code is implemented in the ROM pointed to by vector $172. I will check the Minerva disassembly and start from there.
Peter wrote:
FrancoisLanciault wrote:The manual states that the DATA pin has a internal 10kOhms pull up resistor. Does the clock signal also have a pull up resistor ?
No. The Q68 is always master, so it drives the clock as output.
Agreed. Pull up resistors are needed when input is expected on a signal pin.
Peter wrote:
FrancoisLanciault wrote:So, it seems that for the QL-NET, I cannot do much myself, but I will contribute as much as possible is other parties want to help.
There is ongoing implementation effort.
Well feel free to tell them about me if they need help. Hope to see progress report here or elsewhere. (Software section would be more appropriate)

François


Post Reply