I2C 4 U

[MartinB]

Thanks Mark and there’s no rush or dependency whatsoever. I’m only posting it in the off chance that someone has a minute and because I’m away from my Beeb stuff. I’ll crack on to formal release in the week anyway because there are to be further versions as I progressively add feature sets.

Some more notes...

• I’ve now added unknown OSWORD handling so I will shortly also be adding new OSWORD numbers for all the I2C functions in the rom - it’s already done in fact but I need to do a bit more testing for those.
• There will of course be an identical Elk version, I just haven’t tested the latest changes on a real Electron yet.
• For the screen-shots above, I’ve used BeebEm with some RTC emulation - just saying in case things look a bit static!
• The ASCII/BCD character string produced by *NOW$ and by OSWORD 14 Type 4 does include the current temperature as the trailing two-character number representing Degrees Centigrade with a resolution of one degree but it does not include the “degC” as shown by the *TEMP and *NOW commands. This is intentional as the choice of temperature units annotation is regarded as the remit of the particular application software accessing the string data. (e.g. as provided by the *TEMP and *NOW commands.)

.

[Elminster]

Ditto. All 8 bit stuff on back burner for a while, while I catchup on some certification exams. So can’t offer my usual unconstructive critism at the moment.

[MartinB]

So can’t offer my usual unconstructive critism at the moment.

No worries my friend, there’s no rush

(Although, I certainly won’t rest until I know it’s Duncan-proof.... )

[MartinB]

When I migrated the Beeb I2C interface to the System VIA (with access via the Analogue Port connector), referring to the Electron....

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

To also allow the Electron to benefit from the easy RTC enhancement, I am in parallel producing an Elk version of the Beeb 3.1 I2C rom and for consistency and ease of support, I therefore intend to maintain the use of the 6522 d4 and d5 lines but employing VIA Port A as per Elk UPURS. The Elk I2C clock and data lines will therefore sit snugly next to the UPURS Port A d6 and d7 control lines and as explained in the quote above, by keeping Electron UPURS and I2C as Port A interfaces, the popular Port B remains free for other consumers such as MMC interfaces (if there are other Port B consumers on the Elk?)

Anyway, unless anyone has any sensible objections, I'll carry on with my plans as described. Lucky old Elk - four wires, a rom and a £3 module to get a fully integrated battery-backed RTC....!


EDIT : Nope! Cancel that - the Elk I2C lines need to stay as they are! I was forgetting that Dave H has already tracked-in an I2C header on the AP5 using PB0 and CB2 as I originally designed. No worries though, the Elk RTC stands and I’ll still release an Electron 3.1 rom with RTC support but I’ll leave the I2C 6522 as is.


.

[MartinB]

I've just given 3.1E a whirl on an Elk for the first time and it's all good by the looks. I made a short video of the excitement for my YT project collection and it's posted below but you'll only be needing a small bag of popcorn.

All we have is an Elk, a Plus 1 (could be a Rombox/Rombox+), an EUP for the 6522 User Port and rom socket (could be an AP5), the 3.1 I2C rom and one of the pennies RTC modules mentioned above.

[MartinB]

Right folks, it's time to equip yer Beebs and Elks with a clock...

Here's the 3.1 'RTC' version of the I2C rom attached as a single zip containing :

* Beeb (B+) v3.1B 16k rom image (Checksum-32 =$00091906)
* Electron v3.1E 16k rom image (Checksum-32 = $0009C486)
* A text file showng the above two Checksum-32 values
* The updated v3.1 Manual and User-Guide
* DFS ssd containing both rom images

I'll just quote from the manual for the introduction.....

The Beeb I2C rom implements and exploits a Philips-NXP compliant I2C bus master capability in the Acorn Model B, B+, Master 128 and Electron computers. From version 3.0 onwards, for all computer models other than the Electron, the connection point for the I2C bus is the rear-facing Analogue Port connector through which the System 6522 at $FE40 is utilised by the rom to implement the 2-wire I2C bus. For the Electron, the basic computer must be upgraded to provide a 6522 VIA and this is normally achieved through the addition of a Plus 1 expansion unit together with either an AP5 (legacy ACP or modern Retro-Hardware) or a modern Stardot EUP module. Since an expanded Electron still does not have the Analogue Port of its larger siblings, the Elk I2C bus is accessed through the User Port utilising Port B of the 6522 at $FCB0. Refer to the Supporting Information section beginning on page 14 of this manual for detailed connection and cable details.

The primary focus of the version 3.1 release is to facilitate the easy addition of a properly integrated, real-time battery-backed clock and calendar to the BBC B, B+ and Electron range of computers. The I2C 3.1 rom command extensions implement bespoke support for readily available and inexpensive DS3231 I2C RTC modules (again, see Supporting Information) offering new time and date ‘star’ commands and dedicated OSWORD calls, together offering easy access to time and date information from both BASIC and assembler.

Significantly, the RTC user interface does not require the user to have any I2C knowledge (or interest!) whatsoever in order to take advantage of the clock and calendar functions. Indeed, other than seeing the I2C command set in the rom *HELP dialogue, the user will not be exposed to the I2C layer of the rom unless they specifically choose to use those advanced aspects for their own I2C projects.

I2C V3dot1 Rom Files.zip

(1.61 MiB) Downloaded 97 times

[1024MAK]

I've just given 3.1E a whirl on an Elk for the first time and it's all good by the looks. I made a short video of the excitement for my YT project collection and it's posted below but you'll only be needing a small bag of popcorn.

Who is Peter Griffin and why is he using Batmans monitor/telly? [It’s hanging upside down from a shelf by the looks...!]

Mark

[MartinB]

Who is Peter Griffin...

I use a couple of aliases in the internet world - it can be an unpleasant place and sometimes a spot of anonymity can be useful. (Actually, there are occasions when I wish I had an alias on here.... ) For Peter Griffin btw, you need to watch Family Guy on TV....

....why is he using Batmans monitor/telly? [It’s hanging upside down from a shelf by the looks...!]

It's one of a pair of identical 8" TV monitors I acquired from separate sources. They're very neat, perform well in the retro world and you can flip the display through the menus so by doing that and hanging the unit from the shelf, I don't lose any valuable worktop space!

Here's a couple of photos.....

...and, importantly, they have a VGA input so look what's hiding behind.....

.

[KenLowe]

Right folks, it's time to equip yer Beebs and Elks with a clock...

Great work

...unfortunately, I'm using a different RTC module, with a different I2C addresses (0x6F), so it doesn't work for me straight off the bat. I'm actually using a modified Tiny RTC module, where I've replaced the onboard DS1307 with a pin compatible MCP79412 (for reasons that I won't go into here).

A quick comparison of the MCP79412 datasheet against the DS3231 datasheet reveals that the primary time & date functions at each register (0x00 thru 0x06) are pretty much the same. There are some subtle differences relating to leap year, and oscillator enable / disable. Also, the alarm functions don't map directly, with the DS3231 alarm functions starting at 0x07, but the MCP79412 equivalent starting at 0x0A. However, I don't think you're currently using any of the alarm functionality in your ROM?

As well as having 64 bytes of SRAM starting at register 0x20 in the RTC module, the MCP79412 also has it's own embedded 128 bytes of EEPROM at I2C address 0x57. This is in addition to the 32k of EERPOM space that is available on a separate 24C32 on the Tiny RTC module, which is accessible via I2C address 0x50!

So, my question is; how easy would it be to patch your ROM to use I2C address 0x6F for the RTC function, and address 0x50 for the EEPROM (unless I can just use the 128 bytes of EEPROM that is embedded in the MCP79412, and which has the same I2C address that you are using)?

[MartinB]

Hi Ken and thanks as ever for the encouragement

I shouldn’t imagine it would be too difficult at all, I’ll have a study of your datasheet and report back.

I have one question - you previously mentioned that you have a special focus on alarm functionality I think? The DS3231 has two alarms but I haven’t provided any bespoke alarm commands because a user can easily use I2C rom functions to access these. However, what I have done is to use one of the Alarm2 parameters as an NVM scratchpad, specifically for the Time-on-Break (ToB) flag, because I didn’t want to rely on the presence of any on-board eeprom since not all modules have this. The upshot of this then is that with the DS3231 modules, there is only Alarm1 available to a user - I didn’t see this as an issue since I doubt anyone will use even one alarm, let alone two! Anyway, if that is an issue for you, if your module has some scratch NVM on-board, then I could also patch the ToB function to use that instead of Alarm2.

[KenLowe]

I'm in the process of developing a remake of the old IntegraB add on board for the beeb (currently on hold due to other priorities). I was looking to implement the IntegraB time / date / alarm / SRAM functionality that is currently provided by the obsolete CDP6818E, using a compatible I2C based RTC module instead. From memory, there are limited I2C based RTC ICs that come with the time, alarm & SRAM functionality that is used by the IntegraB. Most come with either time & alarm OR time & SRAM; not all 3. I think the MCP79412 was the only one I found that did all 3.

The CDP6818E only has one alarm, so using alarm2 on the MCP79412 for your ToB workspace shouldn't be a problem for me - other than the alarm2 registers are at a different location on the MCP79412 compared to the DS3231.

The MCP79412 does actually have 64 bytes of SRAM, so it would probably be more appropriate to use one of those SRAM locations to store the ToB flag instead of using one of the alarm2 registers. The IntegraB already uses a number of these SRAM locations in the CDP6818E to store non volatile data (like plugged / unplugged status, boot screen mode, start up language ROM number, start up file system ROM number, OSMODE etc). I intend using the same SRAM locations in the MCP79412 for the IntegraB remake.

[MartinB]

Hi Ken

It looks as if the changes needed to support the MCP79412 wouldn't be too great as we thought. One thing I notice is that your chip doesn't have an embedded temperature sensor so whilst you could just ignore the *TEMP command, I presume you'd want the ToB display to have that element occulted rather than it showing a random value?

Of the 64 on-board SRAM locations, can you nominate a specific one you know is free that I could reserve for the ToB function?

Other than ironing out any unexpected details, an initial test build doesn't seem too daunting, I just need to find a little time!

(Incidentally, OSWORD calls for the fundamental I2C control star commands are coming - the basic unknown call handler is in place so I'll add the rest to one of the 3.x series of releases.)



.

[KenLowe]

It looks as if the changes needed to support the MCP79412 wouldn't be too great as we thought. One thing I notice is that your chip doesn't have an embedded temperature sensor so whilst you could just ignore the *TEMP command, I presume you'd want the ToB display to have that element occulted rather than it showing a random value?

You're right. The MCP79412 doesn't include a temperature sensor, so it would be great if there was an option to hide that.

Of the 64 on-board SRAM locations, can you nominate a specific one you know is free that I could reserve for the ToB function?

I would suggest using the 32nd SRAM address. The SRAM starts at address offset 0x20 on the MCP79412, so that would mean using address offset 0x40 for the ToB function.

For reference, this is what the RTC addresses are currently being used for in the IntegraB (I haven't documented them all yet):

Code: Select all

\\RTC Clock Address
;Address &00 - Seconds:	 	00
;Address &01 - Sec Alarm:	00
;Address &02 - Minutes:	 	00
;Address &03 - Min Alarm:	00
;Address &04 - Hours:		00
;Address &05 - Hr Alarm:	00
;Address &06 - Day of Week:	07 (Saturday)	Note: This was set to 2 (Mon), which was correct when century was 1900
;Address &07 - Day of Month:	01
;Address &08 - Month:		01 (January)
;Address &09 - Year:		00
;Address &0A - Register A
;Address &0B - Register B
;Address &0C - Register C
;Address &0D - Register D

\\RTC User RAM (add offset &0E to get real RTC user RAM address - addresses &00-&0D are for RTC clock)
;Address &00
;Address &01
;Address &02
;Address &03
;Address &04
;Address &05
;Address &06 - &FF:	*INSERT status. Default: All 16 ROMS enabled:
;Address &07 - &FF:
;Address &08
;Address &09
;Address &0A - &17:	0-2: MODE / 3: SHADOW / 4: TV Interlace / 5-7: TV screen shift
;Address &0B - &20:	0-2: FDRIVE / 3-5: CAPS. Default was &23. Changed to &20
;Address &0C - &19:	0-7: Keyboard Delay
;Address &0D - &05:	0-7: Keyboard Repeat
;Address &0E - &0A:	0-7: Printer Ignore
;Address &0F - &2D:	0: Tube / 2-4: BAUD / 5-7: Printer
;Address &10 - &A1:	0: File system / 4: Boot / 5-7: Data. Default was &A0. Changed to &A1

[MartinB]

Ok Ken, what I think I'll do is use SRAM address $40 as a multi-purpose bit-level control register making say bit 0 the ToB flag and adding bit 1 as a Temperature-Display-Inhibit flag. I won't though add any new star command to access the temperature inhibit flag because it could be easily be set from the prompt using something like...

*I2CRXB 6F #40 B%
B%=B% OR 2 (or B% AND &FD to clear)
*I2CTXB 6F #40 B%

...and you’d only really be doing it once per module anyway! I’d obviously also complement that by ensuring that *TBRK only toggles bit 0 and leaves the other bits unaffected.

Other than that, I just need to change the RTC base address to $6F, make the *TBRK and *NOW display outputs respect the new temperature occult flag and finally just confirm that any other residual bits and bytes all align to the DS3231 where relevant. We don’t need to worry about the eeprom addresses yet because as of v3.1, I haven’t exploited that storage.

I’ve made it sound so simple!

(Finding a little time might not be so simple... )


.

[MartinB]

Here we go Ken, version 3.1K for you to try on your setup. I haven’t been able to test the changes because I don’t have one of your module types and whilst I wrote some DS3231 emulation for BeebEm to test the mainstream versions of the rom, I don’t have time (and it wouldn’t be worth the effort tbh) to modify it to support the MCP chip. Hence, I’m slightly nervous about the changes because there are quite a number but if you have problems, I can do some remote debugging with your help.

I’d leave the temperature display on initially and test the standard functions as per the manual before you try the temperature display suppression flag. It just means that the two temperature digits will be random, may be just zero, but it won’t cause any problems. Then, if everything seems to be otherwise working, you can switch the temperature display off (and back on if needs be) as I suggested above but to repeat - the new flag is an inhibit and is bit 1 of device absolute address $40 (SRAM address $20) so to occult the temperature element....

*I2CRXB 6F #40 B%
B%=B% OR 2 (or B% AND &FD to reinstate)
*I2CTXB 6F #40 B%

Anyway, enough waffle, give it a go and let me know how you get on!


EDIT : Since you're not downloading it until later, I've re-attached the rom image as a proper .zip file because I'm not really too keen on the renaming trick


V1 removed and V2 of 3.1K image posted further down but note that this is a special version for Ken Lowe only.


.

[KenLowe]

Thanks Martin. I'll give it a go tomorrow (actually today, now) evening once I get back from work.

[MartinB]

No worries Ken, whenever you have time. Note that since last night I have edited the attachment to be a proper compressed zip file so don't rename it, just unzip as normal.

[1024MAK]

I use the FileApp application to zip and unzip stuff on the iPad mini that I use.

Unzipping is normally perfectly fine. Zipping up is also good. But sometimes files don’t show up in the iOS file browser. So I copy the file to another suitable application (“Notes” is easiest). Then copy the file back to the FileApp area. Now the iOS file browser (from the browse selection in the attachment box) can see the file

Mark

[KenLowe]

I use Android

[KenLowe]

Here we go Ken, version 3.1K for you to try on your setup. I haven’t been able to test the changes because I don’t have one of your module types and whilst I wrote some DS3231 emulation for BeebEm to test the mainstream versions of the rom, I don’t have time (and it wouldn’t be worth the effort tbh) to modify it to support the MCP chip. Hence, I’m slightly nervous about the changes because there are quite a number but if you have problems, I can do some remote debugging with your help.

I’d leave the temperature display on initially and test the standard functions as per the manual before you try the temperature display suppression flag. It just means that the two temperature digits will be random, may be just zero, but it won’t cause any problems. Then, if everything seems to be otherwise working, you can switch the temperature display off (and back on if needs be) as I suggested above but to repeat - the new flag is an inhibit and is bit 1 of device absolute address $40 (SRAM address $20) so to occult the temperature element....

*I2CRXB 6F #40 B%
B%=B% OR 2 (or B% AND &FD to reinstate)
*I2CTXB 6F #40 B%

Anyway, enough waffle, give it a go and let me know how you get on!

That all seems to be working just fine! Initially the value 0x48 was stored in register 0x40, so nothing was being displayed on reset. I changed the value to 0x03, and that got the date & time displayed (without the temperature) on reset. I then changed to the value to 0x01, and got the time, date and temperature displayed. The temperature came back as 0 DegC. Switched back to 0x03, and it's back to displaying date & time without temperature.

Many thanks for doing this for me. I really wasn't expecting that.

[MartinB]

That all seems to be working just fine!

Good news!

Yes, the two flags are opposites in that bit 0 : ToB is an enable whilst bit 1 : TEMPinh is an inhibit. So, for you, the ‘normal’ state is 0x03 as you have noted which gives time & date on reset with temperature occulted. The three commands I suggested above allow you to turn temperature on and off without disturbing ToB which is of course toggled with *TBRK.

Many thanks for doing this for me. I really wasn't expecting that.

No worries at all Ken, you have always supported my projects and been very kind with feedback and suggestions so it’s the least I can do...

[KenLowe]

The three commands I suggested above allow you to turn temperature on and off without disturbing ToB which is of course toggled with *TBRK.

Duh. I forgot about that! Just tested *TBRK but it doesn't seem to be working correctly. I think it reads the state correctly, but doesn't appear to change the state:

[MartinB]

Oh well, it was nearly a full house!

I’ll have a look now, I’m not busy for an hour or so....

EDIT : (minutes later) I can see why already! I modified *TBRK to make sure it only toggles bit 0 and doesn't affect the new bit 1 TEMPinh flag but forgot to move the re-write of the new value to the new SRAM address - i.e. *TBRK reads your new SRAM register but then still writes the newly toggled value to the DS3231 register

I'll post a new version in a little while....

[MartinB]

Here you go Ken - it's only two bytes different from the previous image and one of those is the date going from 02 to 03

Let me know when tested, no rush.......


EDIT : 3.1k attachment removed to avoid confusion with mainstream product!


.

[KenLowe]

That fixed it

[MartinB]

Nice one

Delete the first image then so it can't ever escape to the wild and I'll remove it from the earlier post.

One last point - *NOW$ (but not *NOW) and OSWORD 14 Type 4 (new) will always still produce a 25 character string where the last two digits are temperature but you can just ignore these when/if snipping the string up into its parts. This way, all the low-level info in the manual is still correct for your Special-K version (see what I did there.... )

Shout up if you find anything else or have any other compatibility issues with the rom.

[MartinB]

I’ve just noticed that someone else has downloaded v3.1k from a couple of posts above and I need to stress that this is a special bespoke version for Ken Lowe’s Integra B project and is not my mainstream I2C rom! This version will not work as per the Beeb I2C rom manual!

For the mainstream Model B & Electron products, see versions 3.1B and 3.1E further up the thread.

(I shall take down the K version now!)

[MartinB]

How does that work? Would be interested in one! Or maybe three.

Sorry for the slow reply, I’m away in London at the mo....

If you grab the manual from a few posts above, the easy RTC is mostly explained but first of all, it’s important to note that you can ignore all the I2C aspects if that stuff doesn’t tickle your fancy! Then, it’s just a matter of a couple of quid for a cheap’n’cheerful clock module with four wires to connect it and a slot for the rom - you do ideally need a physical eprom, a sideways ram copy would lose many of the benefits of having a clock! You can hook-probe or solder the wires internally if you like (done that on all mine) or you can make a cable as per the manual.

Anyway, have a read and if it sounds to your liking, by all means ask away on here for more info or help....


.

[MartinB]

Following a further couple of enquiries, here’s some pics of one of my Beebs with the I2C RTC mounted internally. The parts list is just a clock module plus battery (with an SMD resistor removed to kill the charge circuit - details as per thread), four-wires which can be easily salvaged from an old PC harness including a connector or simply use four soldered wires and finally, the I2C rom!

The I2C rom manual has most of the details but doesn’t explicitly show this internal mounting arrangement where there are no external cables or connectors whatsoever and the only machine resource consumed is one rom socket.

Final point - do you need to know how to use the I2C aspects of the rom to enjoy the clock? For the last time, NO!, the rom does it all for you! Just fit and enjoy!

[sweh]

I think I've found a flaw... it causes your monitor to be displayed upside down!