:llama: http://www.kickstarter.com/projects/1034145369/high-speed-laser-optical-sensor (http://www.kickstarter.com/projects/1034145369/high-speed-laser-optical-sensor) :llama:Excellent! I have a few opto-mechanical trackballs that I would like to modify like this.
If you have an old trackball that needs a DPI boost, then you're in luck right now. The Avago ADNS-9800 is an 8200 DPI laser module that is used in a lot of high end gaming mice right now. It just has to be connected to a teensy to work. I plan to mod a Microsoft Trackball Optical with the one I ordered.
I'm not really worried about it fitting, I'll just MAKE it fit. I'm worried about being able to modify that code to my needs. I've never coded for hardware before, just website languages and C++. That teensy code looks similar to C++, so I understand some of it at least.
Do you think there's any way to combine the optical reading teensy code with a "small keyboard matrix" reading code? said trackball also has a tenkey on it, and I would love to get it working with one one USB device.
Is this for a mouse? If so, hew do you reverse/switch the Y-axis for a trackball?
Software? Hardware?
ed: Time to reload tabs before I read them... going a little slow this late at night.
Flipping the axis (X or Y) is easy. Just multiply the value retrieved from the SPI port by -1. That is how I did it in the video.
-JK
I don't mind at all to help you out on the programming side as it relates to a Teensy 2.0. I can donate what is already up on Github as well as my full implementation of the trackball I made with all the bells and whistles. I don't mind sharing.
As for mod'ing existing trackballs, my old trackman marble wheel remains intact as it was in the early '90s when I bought it. I didn't see any great way to mod it for adding a new sensor to it. As was noted earlier in this thread, this sensor does require more room than I saw available in the existing body. I ended up printing an entirely new trackball body of my own design to get what I wanted. I look forward to seeing how creative people can be by ripping out the guts of their existing trackball and equipping it with a new high-resolution sensor.
JK
Indeed, I do have a copy of the C8051F347 files. When I asked for it, they even sent me the source code, which surprised me. Collectively, the chip refers to this as the "A4" code version. I formatted the binary hex compiled file from the A4 firmware into the Arduino sketch there on my Github, so it is there for everyone to get.
Since this is interrupt driven, the call to the subroutine that reads from the chip is not called from the main loop like most other subroutines. Near the top of my source code, look at this statement:
attachInterrupt(0, UpdatePointer, FALLING);
Using this, you don't need anything in the main loop to get functionality of the chip. The UpdatePointer subroutine calls each time the interrupt 0 pin goes low. My code is an Arduino sketch, not C++. In my full trackball code, my main loop is dedicated to scanning buttons to see if any of them have been pushed and dealing with those events.
When I asked for the firmware, they sent me the "A4" text file that just has a string of hex values, one per line. Also included in their response was a folder named:
A5059M_NRD1101_V2_8_Full_Spd-1ms_hardwareSPI_9800_(with TCL N SROM hardcode)
Inside this folder is another subfolder labeled:
C8051F347
Inside of that is all the C source code. I have not done anything with the source code. I just took the A4 file they sent and reformatted that for my Arduino sketch and use that to upload to the chip each time it boots. It works. I'm not sure how I would go about cross compiling the source code for that chip as I'm not sure what architecture it uses.
Color me confused, but if you're using a Teensy 2.0 or ++2.0 then you're already using it at 5v IO levels. Have you just gotten lucky and not burnt it out?
Proper 5v support would be a really good idea for anyone using the Teensy 2.0/++2.0
Good luck with that? If you make something useful of it, let me know.
Indeed, programming code from real programmers looks nothing like my professors taught me in college. What you learn in college computer science classes lays a good foundation of the base concepts, but it is really fundamental compared to what is really out there in production work.
I noticed a fair bit of assembler code in there along with the C code...interesting.
-John
Can you give/link me your full trackball code?
Feel free to splain the difference ?
What is liftoff distance?
Hey guys, I was out of town last week. I'm back and had time to test the new revision that includes the 3.3V and 5.0V option today. It works great at both voltages using a 5V and 3.3V Teensy 2.0. I've still got a few pre-order spots left over at Tindie.Com until Monday the 17th for these if you want to get in on it.
-John
There are MULTIPLE versions of firmware for the ADNS-9800... A4, A5 (89), and A6...The newest FW should also fix the smoothing/lag issue.
There are SOME people that say that laser sensors have a ~1.5% acceleration, but even if they do there is no way you'd be able to notice it and it wouldn't affect you.It's more like 5%, easy to test for, A9800 didn't really improve in that regard over the A9500.
Cool piece of kit.
That specific toggle switch I linked is (on)-on-(on). It's SP3T! I never knew those existed until a few days ago.All the SP3T toggle switches I know have the functionality through a customer installed jumper. What switch is it, if I may ask? it looks nice, such switches are usually in the $8-$10 range.
(on) = momentary
Firstly, where did you get those trackballs? I looked around, and all I could find in 2.125" were some steel ones from iowa. Ideally, I'd be able to get some excellent ceramic or hard polymer or something.
Secondly, what trackball are you modifying again? I'm trying to figure out exactly which of my trackballs I'd modify. I'm leaning towards an old kensington, as it has good ball bearings, but my best trackballs is probably a penny & giles, though it has no case or buttons, so it'd be more work to fabricate a case for it.
ON to the meat of my questions, I notice you posted about driving LED's from the teensy 3.0 PWM pin? I'm looking into doing that myself, and I wanted to know if you knew more about it thanI think a ULN2803 using the VUSB pin as it's 5V power should make the LEDs work with the teensy 3.0. Teensy PWM is256hz488.28hz, and I assume that should work just fine with a ULN2803. Can anyone think of a reason that it wont work before I order some ULN2803 ICs?
It's stupid that the teensy 3.0 is 3.3v, that's too low for a lot of things to interface without a logic level converter in-between. Or in the case of LEDs a transister IC like the ULN2803 because of the higher current needs.
So you are driving the LED's from the PWM pin of the teensy. From what I know about transistors this makes sense. I am wanting to power an LED matrix I have with some form of brightness control, so I am wondering if a similar scheme would work. I need to know about the power requirements of the transistors. How do I calculate how much power they waste as heat? I want to do some accounting to ensure I don't go over my limit for a USB device. Would it be better to have a few transistors in parallel acting as one, or having each "group" of LED's driven by a transistor?
Anyone know what an ADNS-9818 model is? My guess is it is the same as the ADNS-9800, but just a specific part number for a manufacturer as it seems to have the same specs as far as I can tell.
Ed,
I dropped your package of sensors off in the mail this morning. I put yours in with your dad's.
-John
My code is FAR from a 1.0 release... (Probably September before anybody will see that...)Do you mean you will be getting 1230 counts per rotation in your application? If so, that's roughly 5 times the number you'd be getting on most normal quadrature trackballs.
I will not be using the motion pin interrupt (which has a maximum of 12khz?), I will be using a 1khz IntervalTimer PIT interrupt to read the motion. At 8200DPI and 150ips that's a maximum of 1230 pixels per cycle (far greater than the 127 you could get with only the lower 8 bits of X and Y). Thus you CAN have errors happen with the way you coded it, but if it works for your purposes it's fine the way it is. I will be gaming with my trackball so I can't afford to turn the opposite direction because I moved the ball too fast.
Some interesting (and quite expensive...) headers will be used to make everything fit. I haven't been able to find them for cheaper than [$4.50 for 4]/[$5.60 for 8] for the 14 pin right angle SMT headers, and [$12.28 for 10]/[$19.95 for 20] for the dual insulator headers. Anyone else know where to get them for cheaper?
To make the scroll wheel work it looks like a TX-IR IC and 4MHz ceramic resonator need to be added...
I'm also gonna have to add a 32.768KHz crystal and a 10uf capacitor to the teensy... (I hope 10uf doesn't cause too much inrush current...)
To make the scroll wheel work it looks like a TX-IR IC and 4MHz ceramic resonator need to be added...
I'm also gonna have to add a 32.768KHz crystal and a 10uf capacitor to the teensy... (I hope 10uf doesn't cause too much inrush current...)
How will you make and place the scroll wheel? As a ring-type scroll or as a separate wheel?
To make the scroll wheel work it looks like a TX-IR IC and 4MHz ceramic resonator need to be added...
I'm also gonna have to add a 32.768KHz crystal and a 10uf capacitor to the teensy... (I hope 10uf doesn't cause too much inrush current...)
How will you make and place the scroll wheel? As a ring-type scroll or as a separate wheel?
This info is old and incorrect. I will be using the new "IntervalTimer" function that has been added to Teensyduino which uses the 4 PIT timers in the teensy 3.0, and "supposedly" doesn't conflict with Tone() anymore. No TX-IR IC, 4MHz ceramic resonator, or 32.768KHz crystal needed. But I will still need the 10uf capacitor.
Because I am modding existing trackballs (Me and my Dad's Microsoft Trackball Opticals) the scroll wheel already has it's place. I will most likely post pictures of progress next weekend.
The_ed: will your code support using the ball itself as a scrollwheel by (for example) pressing a button? I find this to be a good solution, especially if one plans to add buttons.
Do you have a copy of the Avago C8051F347 Firmware that they supply to people who are going to make mice with their ADNS-9800 laser sensors? That way it should be much easier to change the code to my purposes since it already has code for:
the ADNS-9800 pointer movement
a scroll wheel
3 mouse buttons (I would add support for 2 more)
3 LEDs roughly indicating DPI (I would alter them to light up the socket when the mouse is being moved)
and 2 buttons to increment/decrement the DPI by 200 (they can also be used to increment/decrement the liftoff distance by 0.3mm) (I would alter it to change between 5-8 defined DPI levels)
(This is in the PDF sheet for Avago's C8051F347 Firmware Version 2.8 from 11JAN12)
Trackball and Mouse movement
9 buttons (2 for DPI)
Toggle (DPI and liftoff)
Vertical scroll (2-bit and buttons)
2 RGB indicator LEDs
2 Ball socket movement LEDs
11 Liftoff distance levels
8 DPI levels
Snap_Angle
Rest 1, 2, 3
Motion_Burst
500ma
1000hz IntervalTimer
Future:
Ball scroll
Profiles/layers
Horizontal scroll (2-bit and buttons) and center button
FPS button
Digital:
9 buttons
2 scroll
3 toggle
8 LEDs
5 laser
Future:
1 ball scroll
1-2? profiles/layers
3 horizontal scroll
1 FPS button
If you need a sensor, be quick. I'm almost sold out. I'm working on ordering more supplies, but I'll probably be out before the new supplies arrive. Only 4 left.
-John
If you need a sensor, be quick. I'm almost sold out. I'm working on ordering more supplies, but I'll probably be out before the new supplies arrive. Only 4 left.
-John
If you need a sensor, be quick. I'm almost sold out. I'm working on ordering more supplies, but I'll probably be out before the new supplies arrive. Only 4 left.
-John
Thanks for notifying me. I am still contemplating getting a mouse and gutting it for parts instead though. I have a lot of Omron switches left over, but the cost of those are negligible. It will cost me $40 + $33 for Avago sensor and Teensy 3.0, it will require more effort and I will need a few more parts as well. It stands between that and gutting a mouse which will give me a bit less versatility I guess.
If you need a sensor, be quick. I'm almost sold out. I'm working on ordering more supplies, but I'll probably be out before the new supplies arrive. Only 4 left.
-John
Thanks for notifying me. I am still contemplating getting a mouse and gutting it for parts instead though. I have a lot of Omron switches left over, but the cost of those are negligible. It will cost me $40 + $33 for Avago sensor and Teensy 3.0, it will require more effort and I will need a few more parts as well. It stands between that and gutting a mouse which will give me a bit less versatility I guess.
But if you gut a mouse how will you use the sensor?... They don't come on breakout boards, they're soldered directly to the main PCB. If the mouse sensor isn't an ADNS-9800 you're gonna have to find the firmware elsewhere. If you don't use a teensy 3.0 you can't use my code, and if you use a teensy 2.0 you'll have to modify John's code, and if you use neither you'll probably have to code from scratch for whatever controller you're using.
Ah I see, but what would be the point of butchering a mouse when you couldn't customize anything? Making the shape of the mouse more ergonomic is all I can think of that you could do by purely butchering.
Sort of what I am doing. (http://geekhack.org/index.php?topic=47179.0) I didn't want to clutter down your thread.
If you need a sensor, be quick. I'm almost sold out. I'm working on ordering more supplies, but I'll probably be out before the new supplies arrive. Only 4 left.
-John
Could someone please send me the latest firmware version they have for this sensor? I have A4, as posted here: https://github.com/mrjohnk/ADNS-9800. However, I'm going crazy trying to figure out what's wrong. I have successfully uploaded the firmware, activated the laser, and am able to correctly read registers such as product ID, revision ID, and SQUAL. The problem is that the motion pin never changes from high, and delta x and delta y are always zero (plus the motion bit of the motion register is always zero). I have two of these sensors, and get the same result with both, so it likely isn't hardware. Please help! Is there perhaps some other register I have to set up in order to begin to sense motion? So far I've set up the sensor as shown using the sample code, and then tried to read the motion, x_l, x_h, y_l, y_h registers.
I have two of these sensors,
Got me a working sensor now! :)
Could someone please send me the latest firmware version they have for this sensor?
As for restocking, that will probably be at least 3 weeks. These sold out way faster than I anticipated, so I'm working with the vendors to source new stock.
The newest FW should also fix the smoothing/lag issue.
The newest FW should also fix the smoothing/lag issue.
What is the lag issue that you speak of? I'm trying to find ways to make this sensor as accurate as possible, and wondering if I should concern myself with getting the latest firmware.
The interesting "Media" keys that are found on some keyboards and typically include mail, browser and a few other interesting things actually require an endpoint of their own.
Pretty sure this (https://github.com/tmk/tmk_keyboard/blob/master/protocol/pjrc/usb_extra.c) a chunk of that support out of hasu's tmk
Not sure if there's anything like that with pointing devices that have a ton of extra buttons and things.
Ed,
your trackball project is fascinating. I have a related question about the 9800:
As you might have read in Bullveyrs post on page 3 in your thread, the 9800 has acceleration issues of about 5 % in the form of a sinus curve. See here for a graphic: http://www.teamliquid.net/forum/viewpost.php?post_id=18189604
Do you have any idea where this acceleration could come from? From the firmware running on the 9800 itself or from the firmware running on the Teensy 3.0?
Patrick
There is absolutely NO acceleration from the Teensy 3.0, any acceleration would be from the ADNS-9800 itself (if there truly is any, ESPECIALLY with the current A6 firmware).
Las time I measured, there was acceleration. This wasn’t with the latest firmware, but as was posted by Bullveyr, this acceleration is likely unfixable.
I was thinking maybe one could use the computing power of the Teensy 3.0 to process the flawed data the sensor outputs. But that would be quite difficult, I’d guess.
You do realize that these graphs you linked show that there is NO acceleration right? It shows that there is an error margin in the sensing of distance moved, and the poster even points that out... Acceleration can be linear, a curve, exponential, or even stepped. None of those apply to the graphs because it is purely an error margin WITHOUT any acceleration.
To correct the error margin with math on the teensy would assume that every sensor's error margin at every speed was exactly the same. That is impossible, thus to correct the error margin you would have to get the graph of your specific sensor and calculate the math for it.
If you still don't like the ADNS-9800 sensor because of what you've read, then don't use it. But just realize that EVERY sensor has an error margin, which means that every mouse does too.Show Image(http://cdn.overclock.net/3/3a/350x700px-LL-3a123337_belsqdbh6ng4hh0nr.gif)Show Image(http://666kb.com/i/beluh5x7m0nnjthuf.gif)
BTW, these questions belong in the thread and not my inbox.
S9818 is Razers special version of the ADNS-9800. Razer and Logitech usually have special versions of Avago (now PixArt) sensor.Anyone know what an ADNS-9818 model is? My guess is it is the same as the ADNS-9800, but just a specific part number for a manufacturer as it seems to have the same specs as far as I can tell.
I think the "ADNS-9818"/"ADNS-S9818" are just typos that have been perpetuated throughout the internet... That happens quite often as people are too lazy to do research on what they are reporting on or reviewing. They just copy, paste, add some comments, annnd done.
The overall curve goes upward, the picture of the Xai shows this more clearly.
I don’t like the ADNS-9800 not only for what I read, but for what I measured, too: I measured an ADNS 3090 at 1 % maximum deviation/acceleration. I did the same for the ADNS 9500 of the Sensei and got 5-7 %.
Sorry for taking this to your inbox. I’ll stop now! ;)
BTW: If you were to math away the acceleration of the 9x00, they would name whole forums after you …
The curve does NOT go upward for either the XAI or the G9X. If you look at 0.75m/s-3m/s you'll see that it is perfectly flat for both of them. The line does NOT show any of the types of acceleration (linear/curve/exponential/stepped). Sensors are *usually* the most inaccurate/unpredictable when sensing at slow speeds, so the erratic error margin below 0.75m/s is normal. The error margin simply stabilizes its form after 0.75m/s and becomes quite predictable.
It sounds like the ADNS-3090 is the perfect sensor for your OCD then. But my thread is about the ADNS-9800 breakout boards and everything related to them, NOT about comparing the ADNS-9800 to other sensors on the market.
Start replying in my thread then...
Again, it's NOT acceleration! And as I have just said, you would have to get the data from your specific sensor for math to do any good as every sensor that has ever been manufactured will have its own unique error margin. If I did the math for my ADNS-9800 to get 0% error margin, you would still have an error margin with your ADNS-9800 using that same math.
Ed,
I define it as acceleration. I know it’s a dirty definition, but that’s how people call it. Do you know this thread? http://www.teamliquid.net/forum/viewmessage.php?topic_id=333648#i-iii
Maybe it helps you with your project. :)
Patrick
Iirc first 9800 were a bit laggy (not as direct) because there was quite some smoothing which was corrected with newer FWs.
1.3 Mousekey
KC_MS_U, KC_MS_D, KC_MS_L, KC_MS_R for mouse cursor
KC_WH_U, KC_WH_D, KC_WH_L, KC_WH_R for mouse wheel
KC_BTN1, KC_BTN2, KC_BTN3, KC_BTN4, KC_BTN5 for mouse buttons
1.4 System & Media key
KC_PWR, KC_SLEP, KC_WAKE for Power, Sleep, Wake
KC_MUTE, KC_VOLU, KC_VOLD for audio volume control
KC_MNXT, KC_MPRV, KC_MSTP, KC_MPLY, KC_MSEL for media control
KC_MAIL, KC_CALC, KC_MYCM for application launch
KC_WSCH, KC_WHOM, KC_WBAK, KC_WFWD, KC_WSTP, KC_WREF, KC_WFAV for web browser operation
Iirc first 9800 were a bit laggy (not as direct) because there was quite some smoothing which was corrected with newer FWs.
Would you mind sending them my way? I'd like to try all the options before going down the road of making my own absolute encoder with this thing, but I'm pretty convinced now that I'll need to in order to get the accuracy I want.
Thanks
I could send you the package of files (including firmwares A4, A5 (89), and A6) that John sent me.
I could send you the package of files (including firmwares A4, A5 (89), and A6) that John sent me.
That would be great. Can you put them on dropbox and email me the link or something? I was thinking of emailing John, but I wasn't sure if he even had the newer ones.
Here is my drawing in inches.
I seem to be finding a lot of information on how to declare the endpoints in the USB device descriptor, but nothing really on how to actually send the data to them on an arduino... Can somebody point me in the right direction?I have added forward/back buttons and horizontal wheel to arduino and mbed mouse libraries. I only needed to modify descriptor and data to be passed to the PC.
--- arduino-1.0.5 (2)/hardware/arduino/cores/arduino/USBAPI.h 2013-05-18 04:48:38.000000000 +0900
+++ arduino-1.0.5/hardware/arduino/cores/arduino/USBAPI.h 2013-09-05 18:02:41.530330129 +0900
@@ -52,6 +52,8 @@
#define MOUSE_RIGHT 2
#define MOUSE_MIDDLE 4
#define MOUSE_ALL (MOUSE_LEFT | MOUSE_RIGHT | MOUSE_MIDDLE)
+#define MOUSE_BACK 8
+#define MOUSE_FORWARD 16
class Mouse_
{
@@ -63,7 +65,7 @@
void begin(void);
void end(void);
void click(uint8_t b = MOUSE_LEFT);
- void move(signed char x, signed char y, signed char wheel = 0);
+ void move(signed char x, signed char y, signed char wheel = 0, signed char pan = 0);
void press(uint8_t b = MOUSE_LEFT); // press LEFT by default
void release(uint8_t b = MOUSE_LEFT); // release LEFT by default
bool isPressed(uint8_t b = MOUSE_LEFT); // check LEFT by default
--- arduino-1.0.5 (2)/hardware/arduino/cores/arduino/HID.cpp 2013-05-18 04:48:38.000000000 +0900
+++ arduino-1.0.5/hardware/arduino/cores/arduino/HID.cpp 2013-09-05 20:20:40.945700558 +0900
@@ -55,14 +55,14 @@
0x85, 0x01, // REPORT_ID (1)
0x05, 0x09, // USAGE_PAGE (Button)
0x19, 0x01, // USAGE_MINIMUM (Button 1)
- 0x29, 0x03, // USAGE_MAXIMUM (Button 3)
+ 0x29, 0x05, // USAGE_MAXIMUM (Button 5)
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x25, 0x01, // LOGICAL_MAXIMUM (1)
- 0x95, 0x03, // REPORT_COUNT (3)
+ 0x95, 0x05, // REPORT_COUNT (5)
0x75, 0x01, // REPORT_SIZE (1)
0x81, 0x02, // INPUT (Data,Var,Abs)
0x95, 0x01, // REPORT_COUNT (1)
- 0x75, 0x05, // REPORT_SIZE (5)
+ 0x75, 0x03, // REPORT_SIZE (3)
0x81, 0x03, // INPUT (Cnst,Var,Abs)
0x05, 0x01, // USAGE_PAGE (Generic Desktop)
0x09, 0x30, // USAGE (X)
@@ -73,6 +73,15 @@
0x75, 0x08, // REPORT_SIZE (8)
0x95, 0x03, // REPORT_COUNT (3)
0x81, 0x06, // INPUT (Data,Var,Rel)
+
+ 0x05, 0x0c, // USAGE_PAGE (Consumer Page)
+ 0x0a, 0x38, 0x02, // USAGE (AC Pan)
+ 0x15, 0x81, // LOGICAL_MINIMUM (-127)
+ 0x25, 0x7f, // LOGICAL_MAXIMUM (127)
+ 0x95, 0x01, // REPORT_COUNT (1)
+ 0x75, 0x08, // REPORT_SIZE (8)
+ 0x81, 0x06, // INPUT (Data,Var,Rel)
+
0xc0, // END_COLLECTION
0xc0, // END_COLLECTION
@@ -221,14 +230,15 @@
move(0,0,0);
}
-void Mouse_::move(signed char x, signed char y, signed char wheel)
+void Mouse_::move(signed char x, signed char y, signed char wheel, signed char pan)
{
- u8 m[4];
+ u8 m[5];
m[0] = _buttons;
m[1] = x;
m[2] = y;
m[3] = wheel;
- HID_SendReport(1,m,4);
+ m[4] = pan;
+ HID_SendReport(1,m,5);
}
void Mouse_::buttons(uint8_t b)
Have these been integrated into any successful projects yet? I bought one to have in my 'kit', but I would love to see some finished products.
I'd really like to make something special. I need to try a good trackball for a while to see how I like it. I wonder if there is anyone out there that is gaming with a trackball...Well, I highly recommend getting a "good" trackball with actual ball bearings. there are some new penny&giles units on ebay that the seller will let you have for $25 shipped that are very nice with their ball bearings. You will need to make an enclosure for them, however. I have a few trackballs with "good' bearings (assimilation, kensington (turbo mouse, none of this lame new stuff), penny& giles, itac, etc.) and it's much more worthwhile converting one of these than a trackball with lesser quality bearings (CST, newer kensington, basically everything)
Have these been integrated into any successful projects yet? I bought one to have in my 'kit', but I would love to see some finished products.
I know mr. kicklighter has modified his own trackball. I am planning on modding some of mine, but haven't gotten 'round to it yet.
3. If either/both of these make it into the code, the mouse will likely not work in the BIOS. The culprits responsible for that will be the Report IDs required to send the feature report for smooth scrolling, and the 2-byte mouse movement (so you'll have to comment out/in parts if you need it to work in the BIOS)I don't think any of my pointing devices work in any of my BIOS's, or will this affect EFT / UEFI compatibility?
3. If either/both of these make it into the code, the mouse will likely not work in the BIOS. The culprits responsible for that will be the Report IDs required to send the feature report for smooth scrolling, and the 2-byte mouse movement (so you'll have to comment out/in parts if you need it to work in the BIOS)I don't think any of my pointing devices work in any of my BIOS's, or will this affect EFT / UEFI compatibility?
I wonder how many times I've revised the code by now... Hopefully I don't mix up the versions of the pieces...
I wonder how many times I've revised the code by now... Hopefully I don't mix up the versions of the pieces...
are you using some sort of version control like mercurial?