I2C 4 U

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
1024MAK
Posts: 7879
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 Sep 22, 2018 5:58 am

KenLowe wrote:
Fri Sep 21, 2018 10:46 pm
... and it will be nice to have the user port freed up for other things again.
Like UPURS :lol:

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

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

Re: I2C 4 U

Post by KenLowe » Sat Sep 22, 2018 9:13 am

1024MAK wrote:
Sat Sep 22, 2018 5:58 am
Like UPURS :lol:
I need to find out a bit more about this UPURS that I hear a lot of people talking about.

I'm guessing it stands for User Port something or another, and I'm sure a search of these forums would reveal a lot. :D

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

Re: I2C 4 U

Post by MartinB » Sat Sep 22, 2018 8:09 pm

So, here's V3 of the I2C rom attached as a single zip containing :

* Beeb (B, B+ & Master) 16k rom image (Checksum-32 = 0006B24C)
* A text file showing the above Checksum-32 value
* The updated v3 user-guide
* DFS ssd containing the rom image


A couple of important notes about I2C V3.....

1) The I2C bus has moved from the User Port to the Analogue Port!
2) There is no Electron version of V3 since the Elk has no electrically equivalent Analogue Port
3) Reading the manual is strongly advised!


I2C V3 Front Cover .jpg


Beeb I2C V3dot0 rom.zip
(972.1 KiB) Downloaded 9 times

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

Re: I2C 4 U

Post by Elminster » Sat Sep 22, 2018 10:03 pm

MartinB wrote:
Sat Sep 22, 2018 8:09 pm

2) There is no Electron version of V3 since the Elk has no electrically equivalent Analogue Port
Boo
3) Reading the manual is strongly advised!
A novel idea.

Just as I thought I was catching up on my projects, the goal posts move. Might give this a go on the beeb I fixed.

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

Re: I2C 4 U

Post by MartinB » Sun Sep 23, 2018 9:02 am

Duncan wrote:
MartinB wrote:

2) There is no Electron version of V3 since the Elk has no electrically equivalent Analogue Port

Boo

Is that Boo because the Elk has no Analogue Port or because there's no v3 I2C rom? If the latter, I think it's kind of irrelevant really because the Beeb etc. move was purely about de-confliction of the User 6522 VIA (viz the User Port) but I've yet to get my head around whether or not there is a similar issue with the Elk. For some time, there's only been my EUP offering a User Port and now there's Dave H's AP5 too but I don't really know what people use the Elk 6522 ports for? With EUP, I actually forward-provisioned for VIA Port B over-crowding by bespoking the UPURS interface at the outset to VIA Port A so with the existing Elk v2 I2C, I've obviously targeted Port B (to selfishly avoid clashing with UPURS) but I could change that if there were any compelling thoughts from other users.

Either way, never fear, there will indeed be future updates to the Elk I2C rom (I'll probably even call it v3 at the first enhancement) to include any or all of the forthcoming 'shiny' features.... :wink:

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

Re: I2C 4 U

Post by Elminster » Sun Sep 23, 2018 9:33 am

More boo because the electron and monitor sit on top of master so I have to remove it all to get at analogue port, to test new features. Easy just to get beeb out of storage complex (plastic box on top of wardrobe).

Plus I didn’t want everyone praise to go to your head, so I am grounding you. So now you can knuckle down and do more stuff in your cave. I really need a cave.
MartinB wrote:
Sun Sep 23, 2018 9:02 am
Either way, never fear, there will indeed be future updates to the Elk I2C rom (I'll probably even call it v3 at the first enhancement) to include any or all of the forthcoming 'shiny' features.... :wink:
Hurray. Shiny...

Edit: oh okay ... good job ... there I said it.
Last edited by Elminster on Sun Sep 23, 2018 9:34 am, edited 1 time in total.

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

Re: I2C 4 U

Post by MartinB » Sun Sep 23, 2018 9:44 am

Thank-you! 8) (I think.... :-k)

You're supposed to make an Analogue Port pass-through cable so you only have to access the connector once and then you're sorted.... :)

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

Re: I2C 4 U

Post by Elminster » Sun Sep 23, 2018 9:46 am

Was going to use paper clips and crocodile clips!

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

Re: I2C 4 U

Post by MartinB » Sun Sep 23, 2018 9:55 am

Fine - just make sure they're pass-through paper clips.

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

Re: I2C 4 U

Post by daveejhitchins » Sun Sep 23, 2018 2:39 pm

Martin . . .

Just something to think about while I on holiday (yes, yet another week in the sun :roll: ) - I'm coming to the end of the first batch of AP6s and I'm starting to think about any enhancements I could add - Reading your thread and as I'm in the throws of reverse engineering a Cumana Disc Interface - I thought about adding an I2C Clock/Calendar IC - Sooooo - What do you think about an I2C small, dedicated module that could be shoehorned into the AP6 ROM - - it would need to be Very small, no features other than to read/write to one particular part.

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ARA III, 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: 4956
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: I2C 4 U

Post by MartinB » Sun Sep 23, 2018 8:26 pm

Hmmm, I think this raises a few points Dave.... :-k

First off, because we have zero bespoke I2C master hardware in the computer, everything is software-driven in the I2C rom using the ubiquitous bit-banging technique. The consequence of this is that every part of the mandatory I2C protocol such as addressing, data-exchange, handshaking etc., has an associated piece of code driving it and as a result, the minimum framework can’t actually be reduced in any useful way on the basis of talking to just one device and, it’s much more than a handful of bytes. So, depends very much on what you mean by ‘small’ and ‘shoehorned’ - can you put an order of magnitude on that?

Secondly, what hardware do you propose to have in there to drive the I2C bus? (You need two open-drain I/O lines.)

Finally, I’m keen to standardise on a single I2C implementation in the Elk and Beebs (though the two necessarily can’t share the same VIA base address) and that way, I can use my (already protyped) RTC solution across both the Beeb and the Elk. The next iteration of both versions will actually include this support, I just need to settle on a final ‘home’ for the Elk SDA and SCL lines but for sure at either Port A or B of the ‘official’ $FCB0 VIA.

So, it sounds like (question?) you are suggesting an RTC solution whose dependency would be both an AP6 and a ‘new’ Cumana Disc Interface where many people would have neither. (Me included!) My thinking is that a common solution predicated on the standard Acorn-allocated 6522 via either an EUP or an AP5 would be much more attractive and accessible?

Thoughts back....?

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

Re: I2C 4 U

Post by Elminster » Sun Sep 23, 2018 9:06 pm

Or perhaps Dave’s question is actually ‘what is the easiest way to get a real time clock permanently into an Electron via one of my products’. And i2c is what springs to mind.

Could the ap6 Rom have some sort of magic paging and actually be 32k, could fit i2c in in its entirety then, although wouldn’t solve the EUP vs onboard issue.

Edit: the answer of course is magic dynamic i2c call interception.
Last edited by Elminster on Sun Sep 23, 2018 9:07 pm, edited 1 time in total.

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

Re: I2C 4 U

Post by MartinB » Sun Sep 23, 2018 9:33 pm

An important note for anyone planning on assembling an Analogue Port I2C cable!

When building an I2C Analogue Port cable, either dedicated or pass-through, and if using IDC-type connectors as I have demonstrated in the thread and manual, there is a possibility for confusion when isolating the four required cores from the fifteen in the ribbon cable. I will explain.....

If you are familiar with using IDC connectors, particularly on Beebs et al, you will know that the standard form is flat, with two rows of pins and normally, one of the two rows (typically the odd numbers) will have all the pins connected to ground (0v). This technique means that in the connected ribbon cable, the active signals are interleaved with ground lines which gives excellent cross-talk isolation for the non-ground signals. An important physical cable characteristic of this arrangement is that the number of each ribbon core, counting from Pin 1, will also align with the mating connector pin numbers - i.e. the first ribbon core is connected to Pin 1, the second core to Pin 2, the third to Pin 3 and so on, to the last core and pin.

Now, when using the IDC system for other connector types, such as the D-Type employed on the Beeb analogue Port, there is no standard for a Signal/Ground interleaved protocol and the connector pin numbering follows a different system. Of greater importance, the number of an individual connected ribbon cable core, other than Pin 1, will no longer align one-for-one with the pin number of the connector being mated to. It is very easy to miss this nuance and therefore to assemble such a cable incorrectly, especially when accessing a subset of cores as we are doing with our I2C connection.

So, rather than try and clumsily explain any further, here’s a picture summarising the detail of the required cable core connections if using an IDC-style connector and ribbon cable as I have. (Click for readable size!)


FDA4560C-61E2-4885-9D97-4B2893C1248A.jpeg

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

Re: I2C 4 U

Post by MartinB » Sun Sep 23, 2018 9:43 pm

Duncan wrote:Or perhaps Dave’s question is actually ‘what is the easiest way to get a real time clock permanently into an Electron via one of my products’. And i2c is what springs to mind.

Could the ap6 Rom have some sort of magic paging and actually be 32k, could fit i2c in in its entirety then, although wouldn’t solve the EUP vs onboard issue.

Edit: the answer of course is magic dynamic i2c call interception.
I’m not suggesting EUP is a necessity, the official Elk 6522 can also be achieved by the AP5 (or any other way) but I do think it makes good sense to predicate Elk I2C on a 6522 at $FCB0 and to predicate an all-computers RTC solution on this common I2C bus. Still, we’ll see if sunny Dave has any extra info to share on his thinking - maybe I’m missing something from his cunning plan!


.
Last edited by MartinB on Sun Sep 23, 2018 9:54 pm, edited 2 times in total.

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

Re: I2C 4 U

Post by KenLowe » Sun Sep 23, 2018 10:06 pm

MartinB wrote:
Sun Sep 23, 2018 8:26 pm
Thoughts back....?
Perhaps not directly related, but I'm looking to use an I2C RTC in my IntegraB redesign. The IntegraB uses memory mapped IO at addresses &FE38 and &FE3C to talk to the old RTC IC. I was considering using these addresses to implement the I2C protocol. Obviously I would need some address decoding hardware to pick up these addresses.
Last edited by KenLowe on Sun Sep 23, 2018 10:21 pm, edited 1 time in total.

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

Re: I2C 4 U

Post by Elminster » Sun Sep 23, 2018 10:09 pm

MartinB wrote:
Sun Sep 23, 2018 9:43 pm
Duncan wrote:Or perhaps Dave’s question is actually ‘what is the easiest way to get a real time clock permanently into an Electron via one of my products’. And i2c is what springs to mind.

Could the ap6 Rom have some sort of magic paging and actually be 32k, could fit i2c in in its entirety then, although wouldn’t solve the EUP vs onboard issue.

Edit: the answer of course is magic dynamic i2c call interception.
I’m not suggesting EUP is a necessity, the official Elk 6522 can also be achieved by the AP5 (or any other way) but I do think it makes good sense to predicate Elk I2C on a 6522 at $FCB0 and to predicate an all-computers RTC solution on this common I2C bus. Still, we’ll see if sunny Dave has any extra info to share on his thinking - maybe I’m missing something from his cunning plan!
Dave said AP6, they don’t have a 6522, unless I misread something. I think his thinking is to have the RTC inside the plus1. I.e. permanent whatever cartridge is installed, with his calendar feature. Although personally I keep my calendar on my phone.

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

Re: I2C 4 U

Post by MartinB » Sun Sep 23, 2018 11:21 pm

I know he said AP6 and no, they don’t have a 6522. I thought he also proposed fitting the RTC module inside the reworked Cumana disc interface, not resident in the Plus 1 but reading it again, I think you are correct and he meant inside the Plus 1. My point though is that this couldn’t be any further from a common solution, something I know you (Duncan) are fond of and indeed, prod me about! I will add RTC Clock & Calendar support to the next version of the I2C rom and that support will be agnostic to how the I2C is achieved at the hardware level but it will expect to find the I2C command set (and equivalent low-level calls) as I have implemented them. Since someone actually has to do the work for all these things, I was just recommending a common 6522/I2C(4U) approach because it makes parallel support for the Beeb (including variants) and the Electron a doable reality.

@Ken : Are those address just general purpose (open-drain) I/O or is there a 6522? If you’re talking about a separate stand-alone project then it doesn’t matter how the bus is achieved but as per my discussion with Duncan, if we’re after commonality, for my I2C rom at least, any variance in the hardware implementation just makes support harder.


.
Last edited by MartinB on Sun Sep 23, 2018 11:36 pm, edited 5 times in total.

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

Re: I2C 4 U

Post by daveejhitchins » Mon Sep 24, 2018 5:53 am

Leaving for Newcastle airport in 30 min. I'll have a ponder and get back about all the questions ASAP.

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

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

Re: I2C 4 U

Post by KenLowe » Mon Sep 24, 2018 6:03 am

MartinB wrote:
Sun Sep 23, 2018 11:21 pm
@Ken : Are those address just general purpose (open-drain) I/O or is there a 6522? If you’re talking about a separate stand-alone project then it doesn’t matter how the bus is achieved but as per my discussion with Duncan, if we’re after commonality, for my I2C rom at least, any variance in the hardware implementation just makes support harder.
The IntegraB just uses plain (buffered) data bus I/O. No 6522s involved. The &FE38 and &FE3C addresses are used to strobe in / out data to / from the RTC IC. I was considering using the same addresses to read / write to the I2C slave devices.

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

Re: I2C 4 U

Post by MartinB » Mon Sep 24, 2018 6:44 am

Ok, thanks Ken - I was just curious as to how it manages the physical layer of needing latched open-drain I/O in order to achieve a compliant bus. You don't have a schematic or just that snip do you?

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

Re: I2C 4 U

Post by Elminster » Mon Sep 24, 2018 8:43 am

MartinB wrote:
Sun Sep 23, 2018 11:21 pm
Since someone actually has to do the work for all these things, I was just recommending a common 6522/I2C(4U) approach because it makes parallel support for the Beeb (including variants) and the Electron a doable reality.
Hmmm. Okay. In the thread back a couple of pages you said the reaosn you couldnt use the Electron Plus1's Analogue port for I2C was
a Plus 1 doesn't have any programmable tri-state or bi-directional devices which is an essential prerequisite for I2C
Is there some way that the Analgoue port could be 'fixed' as part of Dave's AP6 mkII ? Thereby allowing I2C on analogue port on the Electorn and the BBC.

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

Re: I2C 4 U

Post by 1024MAK » Mon Sep 24, 2018 9:36 am

The Plus 1 for the Elk uses a standard 74 series TTL chip for the two fire button inputs on the analogue port. The chip used is a tri-state buffer wired so it can only read the logic level on the fire button inputs.

It is possible to extend the functionality in a new version of a Plus 1 (or equivalent). You don’t actually need a 6522 VIA, but do need two latched outputs (two bits) connected to open collector or open drain drivers (could be transistors).

In terms of hardware, this is well within the capabilities of a CPLD. Or standard 74 series TTL chips.

One problem with this approach is that it would require a fair amount of reworking of the code that drives the hardware. As the addresses are different, the bits used are different etc.

All the above can also apply to any other address used in any other hardware configuration. Each bespoke hardware arrangement would need a different version of the software :(

In order to make Martin’s software easy to maintain, the best approach is to use the same addresses and the same I/O bits for all Electron systems. With the same hardware configuration. That is a 6522 VIA at the official Acorn address range.

So the logical solution is to shoehorn a 6522 VIA in. However, this then creates another problem. You can’t then have any other device connected that also has a 6522 VIA at the official Acorn address range.

So either the hardware device should provide a full user port implementation, or put it’s 6522 VIA at a different address range. But then Martin would have to make two different software versions available.


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

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

Re: I2C 4 U

Post by Elminster » Mon Sep 24, 2018 12:06 pm

I suspect we will have to wait to see what Dave’s post holiday thinking is. On paper is sounds like a useful feature, but sounds like a lot of rework to achieve with i2c maybe there is another way to achieve it.one day I might even be able to answer my own questions as well.

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

Re: I2C 4 U

Post by MartinB » Mon Sep 24, 2018 12:28 pm

I do understand Dave's thinking to a point - the RTC modules are physically small and easy to stash in any hidey-hole and he thought that if I could snip out a small subset of the I2C rom, sufficient to perform just some basic Clock/Calendar functions, he could add this code to the AP6 rom and job done! The missing part of the story though is the SDA & SCL control - I don't know what he had in mind for those - and a potential flaw is the one I mentioned above in that the rom subset wouldn't be particulary small.

I maybe caused some fog and a rod for my own back by over-highlighting my use of the Analogue Port because that connector is actually only used as an access point to a different 6522 (the System VIA) and the I2C bus itself has no connection to, or involvement in, any part of the analogue interface. I think we are therefore maybe getting into a needless flat spin over this because of the Elk but both I2C solutions remain virtually identical in that they are both predicated on two data lines of one port of a 6522. The point being that whether or not the Elk has an Analogue Port is totally irrelevant - through the auspices of either an EUP or an AP5, the Elk can have a 6522 and thus the I2C rom Clock & Calendar functions will be supported for all machines.


.
Last edited by MartinB on Mon Sep 24, 2018 2:14 pm, edited 2 times in total.

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

Re: I2C 4 U

Post by MartinB » Fri Oct 19, 2018 10:30 pm

I'm just doing final tests of the first iteration of the I2C rom 'shiny features' and the first release is all about equipping your Beeb (and Elk!) with a properly integrated, battery-backed RTC. This upgrade is of course predicated on I2C so all you need is the subject rom, an inexpensive DS3231-based RTC module and a cable (or even just four bits of wire!) to connect the module to your computer, employing one of the simple, something-for-everyone choices of connection and mounting.

I'll be posting v3.1 of the rom in the next few days so here's a preview of what's on the way for all you lucky adopters..... :wink:


RTC-on-Break.jpg

I2C_3dot1 HELP.jpg


Ideally, you should get yourself one of the first module types shown below as they also have a 32k EEPROM on-board and I have plans to exploit that feature in future developments. You do need to remove one SMD resistor (easily done, no particular expertise required) to disable the charging circuit and allow the module to be used with a Lithium coin cell. I'll cover that when I post the rom but if you look back in this thread a little way, Mark K (1024MAK) has already posted the details.

DS3231 + E2 module.JPG

Any other I2C DS3231 module would doubtless also be fine, such as the one shown below, but if it doesn't have the on-board E2, you might miss out on further shiny features down the line....

DS3231 + No E2 module.JPG


Note that in both cases I have removed the seller details as there are dozens of buying options and I just wanted to show what's needed together with a guide price. (Do note though that many sellers are based in China which is fine if you don't mind the wait but there are lots of UK-based sellers too!)

Post Reply