I2C V2 is mostly about a complete code optimisation to increase the I2C clock speed which is now around 20-22 KHz depending on the task being performed. For reference, the previous v1 clock speed was around 13KHz. In addition, I have fixed the single v1 bug whereby *I2CRXB could erroneously write its returned byte to a BASIC % variable even when not commanded - this change will be transparent to most users but for assembly-level use of the rom, there is an additional entry-condition flag to be set and this is documented in the revised v2 manual. Finally, I have amended the *HELP and *HELP I2C responses to include a leading blank line in keeping with what appears to be the protocol for sideways roms - thanks to Ken Lowe for pointing this out.

If you are an existing v1 I2C user, I suspect v2 will appear as something of a non-event because most of the interesting gadgets and projects are probably not predicated on speed of data transfer. However, with the v2 optimised foundation, there will be plenty more exciting features to come....

Note that there is now an I2C Version 3 rom which supersedes v2 for the B, B+ and Master 128 computers. V3 moves the I2C bus from the User Port to the Analogue Port and so whilst the v2 rom is still valid if the User Port is preferable to you, the v2 rom will no longer be supported or be subject to updates. See further down this thread for the v3 rom, posted 22-09-18.

.

Last edited by MartinB on Sun Dec 09, 2018 9:22 pm, edited 4 times in total.

Thanks Dave - I do follow them but probably a little sporadically so I hadn’t seen that. Very interesting and once again, I continue to be fascinated and enthralled by the wealth of things you can do with I2C

...and back on I2C things, my current favourite Beeb project, I have now sorted the ‘resident’ RTC implementation and its very nice, even for folk who don’t want to use the wider I2C features and who just want a clock/calendar. I’ll report in more detail when I’m back from hols.

I have actually looked at that on previous occasions Dave but there’s far more I2C gadgets already out there for the experimenter. Also, the One-Wire protocol mandates a maximum 15us bit ‘1’ time which is a little tight for the Beeb without needing additional hardware and thus using the 1MHz 6522.

Ah yes - I'm very familiar with the Electro-Magnetic Radiation (EMR) phenomena due to its being an exploitable weakness in sensitive data systems. Within the defence industry, equipment architectures have to be cognisant of, and designed to counter the effect and the 'science' generally falls under what is familiarly known as Red/Black Separation and Tempest compliance.

.

Last edited by MartinB on Sun Aug 19, 2018 10:07 am, edited 1 time in total.

I've been playing with I2C RTC modules and looking for viable ways, other than my own RAMagic!, to allow a clock/calendar to be permanently resident in a Beeb. So, as you know, my I2C implementation is based on the User Port and as appropriate as this use might be, it does unfortunately present a practical problem related to the popular MMC and SD card-based storage systems. Why? Well, since these appeared and have been adopted en-masse, those of us who like to develop Beeb User Port-controlled gadgets and who like to play extensively with the Beeb's wonderfully accessible I/O, (which, to be fair, was the original intention of the User Port), have a real problem in gaining audience appeal for any projects and applications that are predicated on free access to the User Port. It’s not the fact that these MMC systems utilise the port per se, it’s that because of their very nature, they inevitably come to dominate as the user’s primary filing system device and as such, they necessarily monopolise the User Port to the exclusion of all other would-be consumers.

Now, I obviously don't expect to be able to change this situation but as I alluded to earlier, when offering up something like the I2C system where a big part of the fun relies on accompanying loadable software-driven experiments, it can be quite frustrating to know that many people simply won't even bother looking because they can't, without a lot of difficulty, run software to drive hardware where the latter itself requires the User Port. This isn’t just a self-indulgent observation regarding I2C, I have received several similar independent comments offline and I have also received many enquiries from UPURS users over the years to ask whether I could move the latter to a different port to allow it to be used with MMC devices!

( As a topical aside, all of the preceding discussion is one reason why I'm really pleased - nay, delighted - to see the advent and rise of the Acorn-compatible Gotek systems which also exploit modern solid-state storage media but then nicely restore software I/O back to the Beeb's rightful disc interface port... )

Anyway, rather than shortening my life over this conundrum, I've decided instead on the obvious solution and I’m simply going to move I2C completely away from the User Port. Because though I still need a 6522 to avoid the need for any unattractive hardware additions, the I2C interface is moving to, wait for it....., the system VIA. Really....?, I hear you say, but how?

Well, as a new and permanent home for the I2C interface, I intend, (hopefully with the blessing of my existing I2C project adopters ), to use (share) the Beeb's analogue port and specifically, for the necessary two I2C active signal lines, SDA and SCL, I’m going to use (share) the two joystick fire-button lines. This may sound odd and will immediately elicit cries of conflict but if we look more closely, we can easily show that this configuration is actually a very elegant solution for Beeb I2C, with no electrical conflict and with no need whatsoever for there to be any logical conflict. Further, we can now happily have a resource-transparent, internal or external RTC without any need for switches or connector juggling.

To explain the technical aspects of the new configuration, let's look first at a purely electrical (voltage/current) schematic of the I2C bus....

Electrically, the above diagram is a true I2C bus representation where in reality the switches inside each device are implemented as Open-Drain (or more familiarly to many, Open-Collector) gates but, if bus speed wasn’t an issue, these switches could just as easily be say toggles, relays or even morse-code tappers! Importantly though, the single-most defining feature of I2C is demonstrated clearly in the diagram and this is that any of the attached devices, be they Masters or Slaves, only have the ability to drive the bus lines low and they cannot drive the lines high. To achieve the latter, the devices must actually release (disconnect from) the bus and the high state will then be achieved by the pull-up resistors Rd and Rc biasing the lines up to Vcc. One very significant characteristic of this arrangement is that even in the presence of random faults, errors, or misbehaving devices, there is no state or combination of states that any of the attached Masters or Slaves can adopt that can cause electrical conflict - the worst any device can do is autonomously overwrite a bus high by driving a low but unlike a TTL High/Low collision, no damage can occur with I2C, we only get a logical conflict (so data corruption.)
It is also worth noting that the Slaves don't actually need a switch on the clock (SCL) line unless a particular I2C implementation is required to support something called clock-stretching. If the latter is to be enabled, then a given Slave is allowed to pull the clock line low to indicate a busy state and a handler for this protocol must also be implemented in the bus Master. (I have for example implemented this in Beeb I2C.)

Ok, holding those thoughts and with the above diagram imprinted on your mind, let’s cut to the chase and look at a second schematic I’ve put together which combines a couple of snips from the Beeb circuit diagram along with the schematic of a Beeb-compatible joystick (click to enlarge!)....

If you look carefully at both diagrams, you should suddenly enjoy an epiphany and see where I’m going with this . By implementing an I2C bus using the Beeb System 6522 and by specifically exploiting the I0 and I1 lines, (the joystick PB0 and PB1 fire button inputs), we have created a classic I2C bus configuration where the VIA is the Master, R66 and R67 are bus pull-up resistors Rc & Rd respectively and, of significant interest to us, a connected joystick or joysticks would simply appear as a valid but unintelligent I2C slave device employing one or two fire buttons as its clock and data switches! (Were you paying attention earlier? )

So, what does all this mean in practical terms? Well, it means that we can now completely de-conflict Beeb I2C from the congested User Port and nicely hide the capability within the analogue port in such as way as to offer multiple flexible I2C connection options such as :

First or second external option above combined with internally connected I2C device(s)

Finally for this post, (though much more to come!), what about the use of joysticks and specifically the fire buttons when sharing the two system VIA lines with I2C? We’ve already shown that I2C can happily co-reside in this configuration and that it’s fine electrically, but what about logically? Well, the simple fact is that if you were to play with the fire buttons simultaneously with an I2C device access then you would undoubtedly be able to corrupt the data. However, my take on this is that I can think of absolutely no reason at all why anyone would ever want to use joysticks whilst accessing I2C - it just doesn’t make any sense! Even with a permanent RTC installed, there still isn’t any reason for the clock to accessed at the same time as using sticks, there just isn’t. Still, that all said, even if someone did conjure up some clever reason for needing an X-Y-Insert controller to use in conjunction with an I2C gadget, then I’d actually thoroughly recommend the use of an I2C controller such as the Wii Nunchuck - see earlier in this thread or in my I2C Rom User Guide for details!

I've probably missed a few points I intended to make but I'll wait for any questions, comments and/or complaints and to see if anyone spots a fatal flaw in the scheme but my nominal plan is to next roll out a v3 rom which will migrate Beeb I2C to the analogue port as described. That done, I'll add support for a resident Clock/Calendar in the manner of RAMagic! followed by the implementation of some other useful features from that package. Exciting!

Looking good. I guessed something like this was in the works when we all spent evenings stabbing beebs in their analogue ports with multimeter probes!

Hmmm. Now what do I do? I use every storage method except Mmc so my user port only normally has upurs in (some other dodgy user port thingy). As this issue was solved on the Electron by AP5 with two user ports I had on my todo list, item 12, build dual userport for 1mhz bus .....

I suppose writing a game using my voltage joystick which displays the time on the screen at the same time is out, but I can live with that.

I am assuming that unless someone implements calls to the i2c master from their joystick control software there can be no conflict. And that is why it is impossible, I.e. you would specifically need to write something to break this setup? Which would be a bit pointless.

Last edited by Elminster on Tue Sep 04, 2018 11:24 pm, edited 2 times in total.

Duncan wrote:I guessed something like this was in the works when we all spent evenings stabbing beebs in their analogue ports with multimeter probes!

The interesting thing about R66 and R67 on the Beeb is that whilst the design was intended to give 10k of pull-up on the joystick fire-buttons, because of of the 6522 having internal ~1k pull-ups, the external resistors actually have the effect of reducing the effective pull-up resistance to ~900 ohms as many of you measured! On the Master, because the CMOS 6522 doesn't have internal pull-ups, we do get the intended 10k but either way, the resistance itself isn't critical, the effect on I2C is actually a function of the pull-up resistance combined with the inherent capacitance of the bus. Then, if the overall CR time-constant were too high, you would start to get some leading edge shark's-finning but on the Beeb and Master though, with our I2C operating at less than 50KHz, either of our pull-up values are fine.

and wrote:I suppose writing a game using my voltage joystick which displays the time on the screen at the same time is out, but I can live with that.

I am assuming that unless someone implements calls to the i2c master from their joystick control software there can be no conflict. And that is why it is impossible, I.e. you would specifically need to write something to break this setup? Which would be a bit pointless.

Actually, the reality of a logical conflict is even more obscure than I suggested. I have used the first joystick fire button as SCL and because of clock-stretching, the Master checks before using the bus that no device is busy so if the first fire button were pressed at the time of an I2C rom call, the latter would wait for the fire button to be released. Furthering this, if you did actually want to do as you suggest and write some dual access code, you could do exactly the same in the controlling software and wait for the fire buttons to be released before making the I2C call so you have two-layer protection. It's also virtually impossible to create manual fire-button pulse steams on the fire buttons that don't have plenty of time between pulses to use I2C. So yes, you would have to work very hard to create situations or write software where there might be an I2C mis-read due to a joystick fire button being pressed. Overall, a non-problem...

Duncan wrote:What about the Electron? In theory I would expect more Electron +1 owners than AP5/EUP owners. So that would open i2c to more Electrons as well.

There already is a v2 Elk I2C rom out there and that's predicated on the standard (and only) Elk 6522 VIA address so the v3 Beeb Analgue Port migration won't affect the Elk. As for an RTC and supporting functions, yes, if there were interest then I could port the forthcoming Beeb RTC support to the Elk rom.

and wrote:And will support containue for the user port should someone want to use it (not sure why, your argument very convincing) ?

The v2 rom still stands and since the I2C *<commands> are agnostic to the bus implementation, programs exploiting the I2C rom will be backwards and forwards compatible. However, in respect of the dedicated RTC and other shiny functions that I'm going to import from RAMagic!, I only intend to do that for the new v3 Analogue Port system. (tbh, I'd rather everyone switched because commonality is always best but it's of course entirely up to the individual user.)

I've just re-read your question and I've realised I didn't actually fully answer what you were asking. Unfortunately, a Plus 1 doesn't have any programmable tri-state or bi-directional devices which is an essential prerequisite for I2C. (As you now know from my I2C tutorial above, we need two lines that can each be programmed to be either low output or high-impedance input - my schematic 'switches'.) I did manage to get UPURS working using just a Plus 1 with a little hardware mod and Dave (hoglet) later followed suit with an MMC implementation but neither had a tri-state dependency.

So, the full answer to your question is that for Elk I2C, without needing any 'new' hardware, you must first have a 6522 through the auspices of either an EUP or an AP5, it can't be implemented with a Plus 1 alone.

Last edited by MartinB on Thu Sep 06, 2018 11:58 am, edited 1 time in total.