I2C 4 U

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
1024MAK
Posts: 8104
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

User avatar
KenLowe
Posts: 411
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: 5025
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

Edit 26-11-18 : If you have a BBC B, B+ or Electron, please use later versions further down the thread.

Beeb I2C V3dot0 rom.zip
(972.1 KiB) Downloaded 15 times
Last edited by MartinB on Mon Nov 26, 2018 7:55 am, edited 1 time in total.

User avatar
Elminster
Posts: 3143
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: 5025
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: 3143
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: 5025
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: 3143
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: 5025
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: 4531
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: 5025
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: 3143
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: 5025
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: 5025
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: 411
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: 3143
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: 5025
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: 4531
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: 411
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: 5025
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: 3143
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: 8104
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

User avatar
Elminster
Posts: 3143
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: 5025
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: 5025
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!)

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

Re: I2C 4 U

Post by MartinB » Wed Oct 31, 2018 9:29 pm

In response to a private question, I apologise to anyone who has been kept waiting for the RTC functionality I promised but you may have seen that I got diverted onto fixing a couple of UPURS issues and they have taken up the best part of the last two weeks.... :shock: :roll:

Anyway, I’m now back in the room and will get onto to finalising the RTC rom release forthwith! :)



.
Last edited by MartinB on Wed Oct 31, 2018 9:31 pm, edited 2 times in total.

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

Re: I2C 4 U

Post by KenLowe » Mon Nov 05, 2018 9:28 pm

That's my user port freed up again! Thank you Martin :)
Attachments
20181105_211838.jpg
20181105_211959.jpg

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

Re: I2C 4 U

Post by MartinB » Mon Nov 05, 2018 10:31 pm

You are most welcome and very nicely done Ken.... =D> 8)

That's exactly the method I've adopted for all my I2C gadgets except for the RTC module which I intend to mount internally using either miniature probe clips or by soldering four wires to the reverse of the motherboard (most likely the latter) since the clock is to be a permanent enhancement to all my Beebs.

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

Re: I2C 4 U

Post by MartinB » Sat Nov 10, 2018 12:15 am

I'm away from my Beeb stuff for a couple of days so I can't do any more testing on the 3.1 RTC release of the I2C rom in the short-term. Therefore, I'm posting what I believe to be the mature development 3.1 image for anyone who fancies having a play-test and I'll formalise the release next week if all seems well. I haven't done any user-guide updates yet so I'll explain here on-the-fly for the time being.

This release will report as 3.1m since this is my development minor-version and so the 'm' will disappear with the formal issue. The full set of rom commands are as follows with the new additions since I2C 3.0 being *TBRK onwards.....

I2C31m help.jpg

There are a number of RTC star commands intended for immediate mode (prompt) use as follows....

I2C31m command prompt functions.jpg

and....

I2C31m misc functions.jpg

*TBRK is a toggle (flip-flop) command that turns the time-on-break display on and off. The current state is reported after each use and is maintained in NVM being persistent through power cycles as long as the RTC module battery is good.

*NOW$ is a 'silent' version of *NOW and is for use within BASIC programs enabling easy time and date access via standard string handling. The ASCII text string, as produced by *NOW (see above), is generated at address &0A00 and can be quickly accessed using the BASIC string indirection operator, <string name>=$&0A00, as shown in the example above.

Note that *TSET and *DSET are very stringent on the syntax and it must be followed exactly - you will be told if not and will be reminded of the correct format. (The 3-character day can be entered in upper-case.)



I2C31m OSWORD &0E 1 and 4.jpg

For assembler-programming, the rom implements OSWORD &0E (decimal 14) Type 1 exactly as Acorn-documented and as appears on the Master range of computers. Additionally, I have added a new OSWORD 14 sub-type, number 4, that performs the equivalent of *NOW$ but the 25-character string is placed at the address pointed to by the OSWORD entry XY. See the above screenshot for an example use of Type 1 and of Type 4.



The following two shots show a quick example of how easy it is to access the time and date information from BASIC.....

I2C31m easy BASIC time.jpg

I2C31m easy BASIC time (2).jpg


Anyway, if you are able, have a play and report back any issues. Thanks in advance.... 8)



Edit 26-11-18 : See formal v3.1 release (and any later releases) further down the thread

.
Last edited by MartinB on Mon Nov 26, 2018 7:59 am, edited 3 times in total.

User avatar
1024MAK
Posts: 8104
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 Nov 10, 2018 1:00 am

@Martin

Thanks :D

I’m currently at an ABUG meet-up. I will give this a whirl when I return within range of my RTC modules...

Mark

Post Reply