I2C 4 U

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
MartinB
Posts: 4899
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sat Jul 28, 2018 8:06 am

Ok, here's V2 of the I2C rom attached as a single zip containing :

* Beeb (B, B+ & Master) 16k rom image (Checksum-32 = 0006A865)
* Electron 16k rom image (Checksum-32 = 0006FB96)
* A text file showng the above two Checksum-32 values
* The updated v2 user-guide
* DFS ssd containing both rom images


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.... :D


front cover.jpg


Beeb I2C V2dot0 B&E roms + manual.zip
(664.25 KiB) Downloaded 12 times

.
Last edited by MartinB on Sat Jul 28, 2018 8:13 am, edited 2 times in total.

User avatar
Elminster
Posts: 2907
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: I2C 4 U

Post by Elminster » Sat Jul 28, 2018 8:43 am

I never finished v1 of the manual, at least have something to read in the shower now.
However, with the v2 optimised foundation, there will be plenty more exciting features to come.... :D
Waiting for shiny things..... stilll waiting ..... no hurry .... done yet?

User avatar
KenLowe
Posts: 334
Joined: Mon Oct 18, 2004 4:35 pm
Location: Scotland
Contact:

Re: I2C 4 U

Post by KenLowe » Sat Jul 28, 2018 9:20 am

Looks good. Still reading from my I2C RTC without any problem. *HELP also looking better. =D> =D> =D>

User avatar
MartinB
Posts: 4899
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sat Jul 28, 2018 10:39 am

Thanks Ken, feedback much appreciated as always... 8)
Duncan wrote:Waiting for shiny things..... stilll waiting ..... no hurry .... done yet?
Even I’m starting to get excited now about the forthcoming shiny things but “No children! We’re not quite there yet ! :x

User avatar
daveejhitchins
Posts: 4343
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: I2C 4 U

Post by daveejhitchins » Sat Aug 18, 2018 9:10 am

Martin . . . Not sure if you follow EEVBlog (?) but noticed this project : during a mailbag vid may be useful?

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
MartinB
Posts: 4899
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sat Aug 18, 2018 11:51 am

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 =D>

User avatar
Elminster
Posts: 2907
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: I2C 4 U

Post by Elminster » Sat Aug 18, 2018 12:09 pm

Was excited but then I remember I have seen that one.

I have my i2c (edit: doh) multi whatsit input board thing now mention by You (Martin) above, and an OLED on order.
Last edited by Elminster on Sat Aug 18, 2018 12:49 pm, edited 1 time in total.

User avatar
MartinB
Posts: 4899
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sat Aug 18, 2018 12:11 pm

Sounds good Duncan! :D

...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.

Also, before coming away, I prototyped the Beeb-as-Slave functionality and again, it’s pretty cool 😃

User avatar
Elminster
Posts: 2907
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: I2C 4 U

Post by Elminster » Sat Aug 18, 2018 12:50 pm

MartinB wrote:
Sat Aug 18, 2018 12:11 pm
Sounds good Duncan! :D

...and back on I2C things,
I meant i2c, not spi, I have edited my post so now it just looks like you are crazy.

User avatar
MartinB
Posts: 4899
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sat Aug 18, 2018 12:54 pm

I’ve never tried to hide the fact..🤪

User avatar
1024MAK
Posts: 7783
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: I2C 4 U

Post by 1024MAK » Sat Aug 18, 2018 2:17 pm

Sooo, SPI as your next project?... :wink:

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
MartinB
Posts: 4899
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sat Aug 18, 2018 2:34 pm

Nope, too many wires... [-(

I’m very minimalistic these days :-D

Kazzie
Posts: 185
Joined: Sun Oct 15, 2017 7:10 pm
Location: North Wales
Contact:

Re: I2C 4 U

Post by Kazzie » Sat Aug 18, 2018 4:53 pm

MartinB wrote:
Sat Aug 18, 2018 2:34 pm
Nope, too many wires... [-(

I’m very minimalistic these days :-D
If you want even fewer wires, how about communicating between Beebs by smoke signals? I'm sure you could come up with some cunning way of using their old X2 capacitors... :)
BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM (mid- restoration)
Acorn System 1 home-made replica

User avatar
MartinB
Posts: 4899
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sat Aug 18, 2018 5:14 pm

Nah, you obviously weren’t around back in 2010 when I did zero wires ..... \:D/



User avatar
daveejhitchins
Posts: 4343
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: I2C 4 U

Post by daveejhitchins » Sat Aug 18, 2018 8:57 pm

There's always the One Wire technology as used by Dallas/Maxim . . .

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
MartinB
Posts: 4899
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sat Aug 18, 2018 9:30 pm

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.

Kazzie
Posts: 185
Joined: Sun Oct 15, 2017 7:10 pm
Location: North Wales
Contact:

Re: I2C 4 U

Post by Kazzie » Sun Aug 19, 2018 4:58 am

MartinB wrote:
Sat Aug 18, 2018 5:14 pm
Nah, you obviously weren’t around back in 2010 when I did zero wires ..... \:D/
No, I hadn't read that one, but I have read BigEd's ideas on how to save data with no I/O devices at all over on the 6502 forum...
Last edited by Kazzie on Sun Aug 19, 2018 5:00 am, edited 1 time in total.
BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM (mid- restoration)
Acorn System 1 home-made replica

User avatar
MartinB
Posts: 4899
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sun Aug 19, 2018 10:06 am

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.

User avatar
Elminster
Posts: 2907
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: I2C 4 U

Post by Elminster » Sun Aug 19, 2018 11:45 am

It it why I wallpapered my house in tin foil and sleep in a faraday cage.

User avatar
1024MAK
Posts: 7783
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: I2C 4 U

Post by 1024MAK » Sun Aug 19, 2018 11:52 am

Forget the tin foil. Just put up a load of shelving and line up a row of at least ten working ZX Spectrum computers per outside wall, each running Manic Miner...

The resulting RF interference will confuse the hell out of whatever equipment "they" are using :lol:

Mark
Last edited by 1024MAK on Sun Aug 19, 2018 11:52 am, edited 1 time in total.
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
MartinB
Posts: 4899
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sun Aug 19, 2018 12:08 pm

I don’t let it worry me.... 8-[ :-


EF43ECB5-1A7E-4CE6-9FF3-D8AA59FD889B.jpeg
EF43ECB5-1A7E-4CE6-9FF3-D8AA59FD889B.jpeg (23.53 KiB) Viewed 352 times

torrind
Posts: 82
Joined: Fri Dec 01, 2017 4:57 pm
Location: Bristol
Contact:

Re: I2C 4 U

Post by torrind » Mon Aug 20, 2018 8:11 pm

Foiled Again!

User avatar
MartinB
Posts: 4899
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Tue Sep 04, 2018 9:22 pm

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! #-o

( 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... =D> )

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? :-k

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....

I2C Electrical Schematic.JPG

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!)....

Joystick schematic.jpg

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? :wink:)

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 :
  • Dedicated I2C-only using 4 lines (PB0, PB1, +5v, 0v) from 15-way D-type connector (no joysticks connected)
  • Short 15-way D-type Plug-to-Socket ribbon pass-thru with 4-line I2C tap-off (joysticks as normal)
  • Internally mounted I2C device(s) such as RTC module using 4-off probe clips (joysticks as normal)
  • Internally mounted I2C device(s) such as RTC module using 4-off soldered wires (joysticks as normal)
  • 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! :wink:

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! :D

User avatar
daveejhitchins
Posts: 4343
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: I2C 4 U

Post by daveejhitchins » Tue Sep 04, 2018 10:50 pm

Excellent, as usual, Martin =D>

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
Elminster
Posts: 2907
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: I2C 4 U

Post by Elminster » Tue Sep 04, 2018 11:14 pm

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.

User avatar
MartinB
Posts: 4899
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Wed Sep 05, 2018 6:09 am

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... :wink:

User avatar
Elminster
Posts: 2907
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: I2C 4 U

Post by Elminster » Wed Sep 05, 2018 8:31 am

Sounds FAB. 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.

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

User avatar
MartinB
Posts: 4899
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Wed Sep 05, 2018 12:34 pm

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.)

User avatar
Elminster
Posts: 2907
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: I2C 4 U

Post by Elminster » Wed Sep 05, 2018 12:37 pm

MartinB wrote:
Wed Sep 05, 2018 12:34 pm
, yes, if there were interest then I could port the forthcoming Beeb RTC support to the Elk rom.
I think you should, but then it isnt me that has to find the time to do it :)

User avatar
MartinB
Posts: 4899
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Wed Sep 05, 2018 6:03 pm

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.

Post Reply