I2C 4 U

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

Re: I2C 4 U

Post by MartinB » Sat Apr 30, 2016 1:10 pm

I'll just add a note in the manual to say that the % integer variable direct access facility is for BASIC only and is not 2nd Processor compatible. The commands will always read from and write to page &0A as the buffer but will only access the page &04 integer variable space if explicitly invoked by the user in the given command. The I2C rom commands are very flexible and are not in any way predicated on the BASIC integer variable facility, I just try to make things as accessible as possible for everyone whether expert or novice.

I'll stay with &86-&8F unless it actually causes any problems. I think I've used these forever with all my stuff and I've never been made aware of any issues. I can easily change things if it becomes necessary.

I expect the rom to mature over time when people start using it - I prefer to make changes in response to actual user experiences than in response to theoretical issues.

User avatar
CMcDougall
Posts: 6123
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

Re: I2C 4 U

Post by CMcDougall » Sat Apr 30, 2016 1:35 pm

1024MAK wrote:24.75oC, that's a bit warm for you! Even taking into account the I2C module being sat on top of the Beeb's hottest chip]
Yeah, but -5oC room temp, hence the famous gloves are out again :shock: =D> [-o< :P
good work Martin!!
ImageImageImage

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

Re: I2C 4 U

Post by MartinB » Sat Apr 30, 2016 2:46 pm

Ha! It wasn't quite -5 Col but if you look at the graph on the monitor, it wasn't much above 10 degrees either in the Beeb vaults when I first switched on... <shivers> :shock: :x

...and yes, the parting mitt shot was for your benefit :wink:

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

Re: I2C 4 U

Post by MartinB » Sun May 01, 2016 5:58 pm

It's tough being a dinosaur in a modern world... :roll:

So I bought something on ebay called an "I2C Logic Level Converter Bi-Directional Module 5V to 3.3V For Arduino" (what is Arduino btw?) and it wasn't until I was about to flush it down the toilet that I realised (RTFM) that you have to provide the 3.3v supply! :shock: I mean, wtf! What's the point of a level converter that will only work if you provide both the levels... :x
Level Shifter.jpg
Ok, ok - I'm just annoyed at myself for making assumptions but I still think it's a pants way of working. I'm sure that given the minuscule currents involved they could have put a surface mount regulator on there.... :roll:

Anyway, undaunted, I've nailed a humongous TO-220 3.3v regulator on the back (its all I had in stock) and we're good to go... :D
Nunchuck 5v to 3.3v.JPG
Nunchuck $52 ACK.JPG

User avatar
sweh
Posts: 1930
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: I2C 4 U

Post by sweh » Sun May 01, 2016 6:10 pm

MartinB wrote:(what is Arduino btw?)
Boards based around the ATmega programmable microcontroller chipset. Lots of I/O (digital, analogue), small amount of RAM. The core design was expandable with "shields" (eg an ethernet shield, a wifi shield) and this allowed a whole ecosystem to grow around it.

The super-cheap SD card holders used for the "40p MMC boards" are designed for Arduinos.
Rgds
Stephen

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

Re: I2C 4 U

Post by MartinB » Sun May 01, 2016 6:45 pm

Thank-you Stephen 8)

( It can be very lonely back here in the 80's.... )

User avatar
sweh
Posts: 1930
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: I2C 4 U

Post by sweh » Sun May 01, 2016 7:19 pm

MartinB wrote:Thank-you Stephen 8)

( It can be very lonely back here in the 80's.... )
What I found interesting was the parallel between programming an Arduino I/O port and programming the 6522 I/O ports. Some concepts are very consistent across time :-)
Rgds
Stephen

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: I2C 4 U

Post by paulb » Sun May 01, 2016 7:23 pm

I've bought this one before and it works fine. I'll admit to using it with an Arduino or with something that is natively 3.3V, the latter in combination with the Arduino or a breadboard power supply providing 5V.

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

Re: I2C 4 U

Post by MartinB » Sun May 01, 2016 7:41 pm

Ah - don't get me wrong Paul, this one works just fine too - provided you already have a 3.3v supply [-X . The one you have shown is actually very similar, also requiring an external 3.3v supply and so would suffer just the same issue in this application. I only have a Beeb with +5v and various passive I2C devices hanging off the User Port so the 3.3v has to come from somewhere. I had assumed (incorrectly) that these level shifters would have had an on-board 5v <> 3.3v regulator but it seems alas not... :roll: :(

Anyway, I can probably get a smaller regulator but I was hoping for a COTS solution so that non-electronics folk could enjoy a reasonably plug'n'play I2C experience if they fancy having a play. I'll think of something, early days yet.... :wink:

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: I2C 4 U

Post by paulb » Sun May 01, 2016 9:05 pm

MartinB wrote:Ah - don't get me wrong Paul, this one works just fine too - provided you already have a 3.3v supply [-X . The one you have shown is actually very similar, also requiring an external 3.3v supply and so would suffer just the same issue in this application. I only have a Beeb with +5v and various passive I2C devices hanging off the User Port so the 3.3v has to come from somewhere. I had assumed (incorrectly) that these level shifters would have had an on-board 5v <> 3.3v regulator but it seems alas not... :roll: :(
No lecturing from my side, here. :) I'm sure I have a level converter or a regulator, maybe the latter :- , that I couldn't make any use of before I realised that I needed the product I linked to for my level-shifting needs. The 3.3V supply wasn't the problem for me.

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

Re: I2C 4 U

Post by MartinB » Tue May 03, 2016 11:03 pm

Just a quick Shaky-Cam update regarding progress with the Nunchuck.... 8)




The Nunchuck is initialised in lines 90 & 100 and is actively read in lines 320 & 330.

Code: Select all

   10 REM * NUNCHUCK CROSSHAIR TEST *
   20 MODE0
   30 GCOL3,1
   40 VDU23;8202;0;0;
   50 MOVE0,0
   60 X%=512:Y%=512
   70 PROCCROSS
   80 :
   90 *I2CTXB 52 #F0 55
  100 *I2CTXB 52 #FB 00
  110 :
  120 REPEAT
  130  PROCNUNCH
  140  DX%=(NX%-128)/4:DY%=(NY%-128)/4
  150  IF ABS(DX%)>14 THEN DX%=DX%+(DX%/2)
  160  IF ABS(DY%)>14 THEN DY%=DY%+(DY%/2)
  170  IF DX%<>0 OR DY%<>0 THEN PROCXMOVE
  180  IFC%=0 THEN PLOT69,X%,Y%
  190  IFZ%=0 THEN PLOT69,X%,Y%
  200  PRINTTAB(10,10);C$
  210  PRINTTAB(50,10);Z$
  220 UNTILFALSE
  230 :
  240 DEFPROCXMOVE
  250  PROCCROSS
  260  X%=X%+DX%:Y%=Y%+DY%
  270  PROCCROSS
  280 ENDPROC
  290 :
  300 DEFPROCNUNCH
  310  :
  320  *I2CTXB 52 00
  330  *I2CRXD 52 06
  340  :
  350  NX%=?&A00:NY%=?&A01
  360  C%=?&A05 AND &02
  370  Z%=?&A05 AND &01
  380  C$="      ":IFC%<>0THENC$="FIRE-C"
  390  Z$="      ":IFZ%<>0THENZ$="FIRE-Z"
  400 ENDPROC
  410 :
  420 DEFPROCCROSS
  430  MOVEX%-16,Y%:DRAWX%-64,Y%
  440  MOVEX%,Y%-16:DRAWX%,Y%-64
  450  MOVEX%+16,Y%:DRAWX%+64,Y%
  460  MOVEX%,Y%+16:DRAWX%,Y%+64
  470 ENDPROC
Last edited by MartinB on Mon Jul 09, 2018 8:20 pm, edited 3 times in total.

User avatar
paulv
Posts: 3629
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: I2C 4 U

Post by paulv » Tue May 03, 2016 11:52 pm

That is awesome!! =D> =D> :D :D

Before you even mentioned it I was thinking whether you'd be able to put a controller shim into Elite to control the flight of the ship. The tilt could be used to accelerate/decelerate the ship, one fire button could be used for the lasers and the other could be used to launch a missile after target lock is acquired. That would be awesome....

Beware however. Doing this may just launch you from obscurity into the mainstream big time. Elite is such an iconic game, Elite:Dangerous and its upgrades are hot property and there's a lot of interest in the original too. Blending a Wii controller with the original Elite would be awesome and breathe yet more life into the historic 32 year old game which I still play more than Elite:Dangerous despite all the glorious graphics and whizz-bang effects. I love them both but the original just has something special about it.

I can picture it now...

Wiilite - second processor edition

If you decide the limelight is too much, do it anyway and release it to just me :lol: :lol:

Paul

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

Re: I2C 4 U

Post by MartinB » Wed May 04, 2016 9:08 am

Thanks Paul 8)

I think the hard part as always will be patching memory-rammed things like Elite. I suspect something such as Aviator will be easier for an initial trial of the Nunchuck 'motion-control' and then I might ask for assistance from any bored individuals who fancy a hacking challenge :wink:

I need to mature the rom in terms of workspace (just zp storage really) and 2P compatibility but it's early days yet. As far as I'm concerned the I2C rom is still very much in development and I'm certainly in no rush but as I said in the video, I am really pleased with the way the rom command set is naturally transpiring to align with the interface requirements of the various I2C devices I've been testing. Looking at other systems such as Arduino (I'm still not 100% clear what this is - thanks for the explain though Stephen :) ) and the Pi, their I2C control library stuff looks more complicated than my Beeb rom implementation but perhaps that's because I'm not a C programmer.... :? :wink:

Zarchos
Posts: 2355
Joined: Sun May 19, 2013 8:19 am
Location: FRANCE

Re: I2C 4 U

Post by Zarchos » Wed May 04, 2016 10:17 am

How fast is it to read the values ?
Sorry I haven't read precisely the whole thread but when you want to read the values, what actions are performed ?
Reading sthing already in main memory of the computer, or on the expansion device, is it already there, buffered, or the hardware has to operate some time consuming operations to then deliver the values ?
How many cycles does all this take ?

Overall how many extra cycles versus normal operation without the device plugged in does it take ? Including servicing interrupts, if any ...
Sorry as I said I haven't read the whole thread and the technical details. (I will, of course).
Very interesting, in all cases.

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: I2C 4 U

Post by paulb » Wed May 04, 2016 10:46 am

MartinB wrote:Looking at other systems such as Arduino (I'm still not 100% clear what this is - thanks for the explain though Stephen :) ) and the Pi, their I2C control library stuff looks more complicated than my Beeb rom implementation but perhaps that's because I'm not a C programmer.... :? :wink:
If you want to see a simple-and-dirty I2C library, look at some code I've written for a little Linux palmtop that just rests on top of a library exposing the general purpose input/output connections. Some of those libraries out there have the tendency to go "framework", meaning that the primitives are quickly buried under a load of "convenience" operations to supposedly make applications easier to write. (Also, there may be some hardware support for I2C on some of these boards, meaning that you'll be confronted with weird register operations to set up transfers that won't make any sense without the chipset documentation, and perhaps don't make much sense with the documentation, either. :wink: )

I've not been motivated to get back to that particular project, but products like this are so inexpensive these days (from a historical perspective) that it's hard not to dabble with them.

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

Re: I2C 4 U

Post by MartinB » Wed May 04, 2016 11:41 am

Cheers for that Paul and ok, I can see how it's being done on other platforms and systems. I think I have pitched this Beeb rom at the correct level then because you can go from gadget+datasheet to a working program in a few minutes and I've kept all the vagaries of the I2C interface away from the user.

I have one of those gyro-cum-accelerometer modules, it was about £2.50 or so and I showed it working in the first video - great fun... =D>
The Nunchuck is based in part on one of these too except of course it's nicely packaged :D

@ Zarchos : I mentioned previously that I've made no attempt as yet to make any speed optimisations in the early development phase of the rom so I think at the moment, the typical average communication rate is only about 10KHz. I can certainly speed that up a lot but I'm waiting until the rom is mature in respect of the base functionality. The 2MHz 6502 and the 6522 VIA will ultimately impose their limitations on the maximum speed but I'm not sure yet what that will be.

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

Re: I2C 4 U

Post by 1024MAK » Wed May 04, 2016 1:02 pm

It should be noted, that I2C interfaces are relatively slow compared to microprocessor speeds.
In most areas of use, this does not matter. If your program needs quick access to a value, treat it like a keyboard system with a buffer in RAM, or like the ADC for the analogue joystick port. That is, use an time-interval interrupt routine to routinely get the data from the I2C device and store the results in RAM. Then the main programme just reads the results from the RAM buffer.

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

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

Re: I2C 4 U

Post by 1024MAK » Wed May 04, 2016 1:09 pm

There are various I2C code modules for various micro-controllers, plus some have inbuilt hardware support. It's not limited to the Arduino.

I have seen I2C code snippets in both assembly language and in C. No doubt there is plenty more, should you wish to go looking.

As an example, here is a PDF from Microchip.

You can, also use bit-banging, here is an interesting page, using Microchip PIC micro-controllers.

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

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

Re: I2C 4 U

Post by MartinB » Wed May 04, 2016 1:30 pm

I have that slide pack thanks Mark. In fact, over the last 12 months, I've probably hoovered up every bit of I2C info going so there's not much I don't know on the topic. Indeed, I am something of a self-confessed I2C nerd.... :-P

( Bit-banging is exactly what my rom is doing.... :wink: )

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

Re: I2C 4 U

Post by 1024MAK » Wed May 04, 2016 1:57 pm

I had already guessed that you would have hoovered up all manner of I2C info :wink:

Thought I would post to help widen the horizons of your readers :lol:

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

User avatar
sweh
Posts: 1930
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: I2C 4 U

Post by sweh » Wed May 04, 2016 2:34 pm

paulb wrote:Some of those libraries out there have the tendency to go "framework", meaning that the primitives are quickly buried under a load of "convenience" operations to supposedly make applications easier to write.
Very much this. When I was learning some basic Arduino tasks I wrote a program to flip a single channel back'n'forth (the pin that happened to be connected to the LED)

Code: Select all

  void loop()
  {
    boolean x=false;
    int y;
    while(1)
    {
      x=!x;
      if (x) { y=HIGH; } else { y=LOW;}
      digitalWrite(LED_BUILTIN,y);
    }
  }
That resulted in a 70Khz square wave.

When I removed the call to digitalWrite() and flipped the bits directly:

Code: Select all

  DDRD=B11111111;
  boolean x=false;
  while(1)
  {
     x=!x;
     if (x) { PORTD=255; } else { PORTD=0;}
  }
That went up to 748Khz; 10 times faster. It showed just how much overhead the standard library applied.

I then cheated and removed the logic and just flipped the pins back'n'forth

Code: Select all

  DDRD=B11111111;
  while (1)
  {
    PORTD=255;
    PORTD=0;
  }
And that went to 3.9Mhz! Although the signal wasn't equal 'cos of how the assembly worked out.
Image

If I stuck a couple of "nops" in to balance the signal out then I got a consistent 2.6Mhz.
Image
If I disabled interrupts around that loop then it went up to 2.66Mhz, which is pretty much chip speed.

So we went from 70Khz up to 2.66Mhz just by coding closer and closer to the hardware.
Rgds
Stephen

paulb
Posts: 811
Joined: Mon Jan 20, 2014 9:02 pm
Contact:

Re: I2C 4 U

Post by paulb » Wed May 04, 2016 7:33 pm

MartinB wrote:I think the hard part as always will be patching memory-rammed things like Elite. I suspect something such as Aviator will be easier for an initial trial of the Nunchuck 'motion-control' and then I might ask for assistance from any bored individuals who fancy a hacking challenge :wink:
Actually, can't you hook into the operating system's ADVAL support here? That's probably one of the OSBYTE calls (without looking up to check), meaning that you might be able to insert your code in the chain of handlers and have the I2C stuff pretend to be the ADC. Then, Elite and other things would probably just work.

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

Re: I2C 4 U

Post by MartinB » Wed May 04, 2016 8:23 pm

Yes, you're absolutely right Paul and before mentioning Aviator, I had already taken a quick scan of the code and spotted some ADC-related OSBYTE calls so I am perfectly in tune with your thinking 8). I don't know if Elite uses standard calls, I expect so with it being an Acornsoft product, so the issue might just be finding some scraps of memory to make the I2C calls. (For the latter, I have provisioned a jump table in the rom so we don't have to assemble a star command and use OSCLI, we can call the routines directly.) If by any chance Elite uses page &0A, I'll have to make a tweak there because that's my chosen default I2C buffer although the Nunchuck only actually needs 6 bytes of said buffer.

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

Re: I2C 4 U

Post by MartinB » Thu May 05, 2016 10:26 pm

Very quick and dirty, wet finger scaling only for proof of concept but looking good all the same..... :D

This is the motion-sensing (well, actually G-sensing) accelerometers btw, not the joystick I tested previously.


Last edited by MartinB on Mon Jul 09, 2018 8:21 pm, edited 1 time in total.

User avatar
paulv
Posts: 3629
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: I2C 4 U

Post by paulv » Thu May 05, 2016 11:51 pm

It's interesting to see the lag in the reaction of the cursor compared to your motions. When using the Wii, it doesn't feel that laggy but thinking about it, for a space or other flight sim, that lag would effectively emulate a bit of inertia in the physics of the flight so I wouldn't mind if it remained in a controller like that.

Having said that, I assume your optimisations once you have a good handle on the feature set will reduce that lag by quite a margin and if you were to use a pure assembler shim for the driver to inject the I2C data into the ADC buffers, the lag would be further reduced simply because of the benefits of using assembler rather than BASIC to interact with the data.

It'd be an interesting exercise if you could introduce a configurable lag into the shim so that you could introduce that feeling of inertia into flight sim games whilst removing it for other games.

Just a thought ;)

Paul

User avatar
sweh
Posts: 1930
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: I2C 4 U

Post by sweh » Fri May 06, 2016 12:13 am

paulv wrote:When using the Wii, it doesn't feel that laggy
How much of that is due to the _type_ of motion normally used. When using the nunchuck I'm normally making large movements (eg Boxing) and so the delay isn't really that noticable. For "fine grained" movement you use the main Wiimote and the IR sensor panel. Martin was making relatively small movements and so the delay was more noticable.

Plus, of course, slow BASIC and OSCLI calls and a slow CPU...
Rgds
Stephen

User avatar
paulv
Posts: 3629
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: I2C 4 U

Post by paulv » Fri May 06, 2016 12:46 am

sweh wrote:
paulv wrote:When using the Wii, it doesn't feel that laggy
How much of that is due to the _type_ of motion normally used. When using the nunchuck I'm normally making large movements (eg Boxing) and so the delay isn't really that noticable.


I guess for the majority of games yes, but I've played plenty of games where the accelerometer in the nunchuck is used for more reactive situations, usually FPS style games and on rails games where the nunchuck really comes into its own for control and yes, whilst there read last even on the Wii, it wasn't as pronounced as that.
sweh wrote:For "fine grained" movement you use the main Wiimote and the IR sensor panel. Martin was making relatively small movements and so the delay was more noticable.
Your kidding right? The analogue stick on the nunchuck is for fine grain movement, the IR in the Wiimote is by its design pretty rough around the edges for accuracy. The little plus addition to the Wiimote and subsequent upgraded Wiimotes with the more accurate 3D space awareness improved accuracy a lot but again, that's not the IR interface.
sweh wrote:Plus, of course, slow BASIC and OSCLI calls and a slow CPU...
As noted in my post. Hence the idea of actually allowing for the introduction of lag into the system once it's optimised to tune the system for different game types. In some cases, lag is not a bad thing and I think in the flight sim scenario (space or otherwise) a bit of lag to model inertia would introduce a level of realism that a digital or analogue joystick cannot provide.

Paul

User avatar
sweh
Posts: 1930
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: I2C 4 U

Post by sweh » Fri May 06, 2016 2:13 am

paulv wrote:Your kidding right? The analogue stick on the nunchuck is for fine grain movement
Right, but now we're not dependent on the accelerometer; Martin's earlier video showed the stick working pretty neatly :-)
Rgds
Stephen

User avatar
tricky
Posts: 2624
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: I2C 4 U

Post by tricky » Fri May 06, 2016 6:14 am

The accelerometers have always had lag and also have a range that can easily be exceeded on the older controllers.
For Wii games, this is OK, as the game can be written to allow for it.
The motion sensors are interesting and may work fora few games, but the stick and buttons will be more generally useful, but it is all fun to play with ;)

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

Re: I2C 4 U

Post by MartinB » Fri May 06, 2016 7:19 am

Thanks for the discussion Paul and Stephen - as I alluded to earlier, I only threw together a few lines in the crosshair program so we could see the Nunchuck working as a motion sensor. I think there's much more sophisticated non-linear algorithms that could be applied across the three axes to improve the response. My coarse linear first-pass creates some hysteresis and low sensitivity around the 0g 'straight & level' point but I was just desperate to see it working... :wink:

As tricky says, I think in the end it'll come down to a case of horses-for-courses - it looks to me as if games of the Missile Command and Cylon Attack genre might be cool with the motion stuff and maybe flying sims like Aviator and possibly Elite but we shall see.

Anyway, I still have plenty of I2C rom stuff to finish and document before I get fully into playing about mode... 8)

Post Reply