Jump to content

Yet Another OpenSource USB Controller


Recommended Posts

Bug fix July 27, 2014

 

Bug Fix.

 

A bug was introduced in July 12, where I introduced a new feature to map ADC channels to any USB axis. It caused any ADC channel at and above HID_JOYSTICK_REPORT_TOTAL_NUM_ADC_AXES not being copied to the USB report. Default of this value is 8. So, you would not see ADC8 or above values.

 

Mea Culpa. I was an idiot and did not test all the axes.

 

Please pull new code.

 

 

All announcements can be found at here, http://www.hempstick.org/jforum/forums/show/5.page

Link to comment
Share on other sites

Cougar Demo project progress

 

Worked the whole weekend on the Cougar Demo project.

 

One of my old Cougars is in pieces. Every hole on the Cougar was probed. ;-) Thanks to ViperPits & Foxy sites' extensive information, saved me a lot of time.

 

All wires hooked up -- in a tangled mess. It's running..... As expected, no code modification required, only the axis and button mapping files are modified. But....

 

Found a problem with my TMStick code... I forgot to map the POV as a special USB POV 8 way, instead I just output them as 4x regular buttons... Buzz, wrong. Will need to modify the USB HID report to add a POV 8 way, then modify the TMStick code to map that 8 way data. Then shift all the buttons behind forward by 6 bits (there are 2 bits, 1 and 2 unused in Cougar, and 1 bit unused in Warthog (and Warthog took bit 2 and mapped it to button 19). This modification shouldn't take long. Should be just a couple of lines of code.

 

Changing the USB HID report descriptor could be a real pain in the your know where though... I ain't got expensive USB hardware sniffer... so If I get it wrong... the host would just ignore me and say NOTHING!

 

Minor correction, no big deal. It's all in the TMStick task and will not impact other parts.

 

Enough coding today... to be continued.

Link to comment
Share on other sites

The Hempstick Cougar Demo project is almost complete.

 

1. The sweet & short document is written.

2. Corrected the TMStick button mapping error (ha... thank goodness I implemented button/axis mapping, including TMStick button mapping. All I had to do is tweak the button mapping table to correct this problem).

3. Added 8 way Hat Switches support. I forgot one of the hat switches on TMStick is actually an 8-way. Doh...

 

Tested it in TARGET, showed up as a Cougar. Also tested it in Target Device Analyzer. ;-) But I do not use it myself in TARGET other than testing purpose. Man, I haven't touch my Cougars since Warthog came out.

 

I have a longer version of the document, detailing how the Hempstick event-based system works and how the FreeRTOS tasks interact with each other and where and how to implement the 8 way switch support. It's quite messy. But it does show some of the basics of how to add new tasks to extend Hempstick. Not sure if anybody is interested in this and it's not ready for release anyway. But if you re interested in such "work-in-progress developer's document", please contact me.

 

I will proof read the document and release the updated code tomorrow, July 30.

 

Stay tune.

Link to comment
Share on other sites

Cougar Demo Project Completed

 

The Cougar Demo Project is completed.

 

The official announcement is here, http://www.hempstick.org/jforum/posts/list/0/14.page#28.

 

 

You can use Hempstick to convert your whole Cougar, a lot of wiring works. But you will end up having an up-to-date electronics.

 

Why?

  1. Hempstick does 1KHz USB report while Cougar does 100Hz.
  2. Hempstick's ADC is a 12bit hardware, software enhanced to 14bit while Cougar has a 10bit ADC
  3. You could use Target to program Hempstick converted Cougar.

 

I imagine this would be interesting for the F16 crowd, but probably not for others. Nevertheless, this demo project was really to demo how easy it is to use Hempstick to do the whole joystick.

Link to comment
Share on other sites

Pre-Configured File Sets

 

From now on, Hempstick will come with sets of pre-configured configuration files.

 

It will be located in src/config/..., for instance, src/config/Cougar/. You just pick the set you want, copy all the files in there to src/config/ overwriting whatever is there and compile and burn the firmware.

 

If you have a set that you wish to contribute and share with others, please let me know, I will put it up to the official release.

Link to comment
Share on other sites

On Resolution

 

Here's an article I just wrote about controller resolution... http://www.hempstick.org/download/articles/OnResolution.pdf.

 

In view of so much interests in the pursuit of higher and higher resolution, I attempt to rationalize why I limit the resolution of Hempstick to 14bit. And to, again, dispute the 16bit resolution myth of the Warthog (damn it, this thing just won't go away!).

 

You be the judge.

Link to comment
Share on other sites

Here's an article I just wrote about controller resolution... http://www.hempstick.org/download/articles/OnResolution.pdf.

 

In view of so much interests in the pursuit of higher and higher resolution, I attempt to rationalize why I limit the resolution of Hempstick to 14bit. And to, again, dispute the 16bit resolution myth of the Warthog (damn it, this thing just won't go away!).

 

You be the judge.

Thank you for making an effort to counter the marketing bollocks.

 

A question. Bloatware is no good but some people find vendor programming software useful. Do you plan on introducing such software for Hempstick? A simple keyboard emulator maybe?


Edited by Bucic
Link to comment
Share on other sites

Interesting project!

Do you plan to make it compatible with ATMEGA16U2 Chips like in ATMEGA 2560 boards?

I dont understand the 32 buttons limitation you have. I actually use ATMEGA Boards where i can wire up to 256 buttons (2x 128 Buttons Joysticks) and it works smooth on DCS.

Link to comment
Share on other sites

Thank you for making an effort to counter the marketing bollocks.

 

A question. Bloatware is no good but some people find vendor programming software useful. Do you plan on introducing such software for Hempstick? A simple keyboard emulator maybe?

 

 

If it's just generating straight keystrokes, yes I will add that sometime in the future. It will just behave like a straight keyboard and you can use it to build a hell of a keyboard -- every key hooks up directly to an MCU pin, all hardware debounced, absolutely no matrix, thus absolutely no ghosting. But, unless you have a custom board, there are not enough pins brought out to build a full keyboard,

 

This is mainly intended for input like radio keypad input etc. I mean, you could use button for these, but if it's a keyboard, why not make it a keyboard.

Link to comment
Share on other sites

The Cougar Demo Project is completed.

 

The official announcement is here, http://www.hempstick.org/jforum/posts/list/0/14.page#28.

 

 

You can use Hempstick to convert your whole Cougar, a lot of wiring works. But you will end up having an up-to-date electronics.

 

Why?

  1. Hempstick does 1KHz USB report while Cougar does 100Hz.
  2. Hempstick's ADC is a 12bit hardware, software enhanced to 14bit while Cougar has a 10bit ADC
  3. You could use Target to program Hempstick converted Cougar.

 

I imagine this would be interesting for the F16 crowd, but probably not for others. Nevertheless, this demo project was really to demo how easy it is to use Hempstick to do the whole joystick.

 

did I read this correctly? A Hempstick modified Cougar can use TARGET? Fully? any Limitations? I have an old cougar in pieces and this would be a fun lil project

Link to comment
Share on other sites

did I read this correctly? A Hempstick modified Cougar can use TARGET? Fully? any Limitations? I have an old cougar in pieces and this would be a fun lil project

 

You read that right. I did that with my my Cougar-in-pieces too.

 

Of course there are limitations... there is no composite keyboard/mouse thing that Cougar does. You just get a bunch of buttons/axes that you can use inside TARGET and program them. But, that's all you need. You don't need those stinky virtual mouse/keyboard thing with TARGET. TARGET does that for you anyway.

 

You can't program Hempstick with Foxy either because I didn't implement any Cougar-specific settings like axis curving/button mapping thing that used to be stored on Cougar firmware. Why bother doing that anyway, it's a horrible way of doing things while you can do the same thing in TARGET. TM at least made a very good choice of moving this kind of stuff into TARGET instead of having it done in the firmware (both commercially and technically).

 

If you do embark on such a project. Let me know, I will help you produce a better mapping configuration so it's a lot easier to wire up (I use the ball of wires method, but it's possible to use a ribbon cable to make it neater and easier).

Link to comment
Share on other sites

However, let me give you a little warning about using Target with Hempstick.

 

Any USB firmware can do it, not just Hempstick. it's dead simple. No code modification needed.

 

If TM is unhappy about it, they can take it out anytime they wish. As somebody who makes a living out of programming, I fully respect their right to do whatever they wish with their software so I have no intention of circumventing that. Use it at your own risk.

 

However, if they want to take it out. They would have to do the followings.

1. Update Target.

2. Probably also update the drivers.

3. Update the firmware to match the driver change.

 

#2 & #3 above apply to all TARGET supported devices, including MFDs, Cougar, T.16000M.

 

So, as long as you don't update your TARGET and Driver... it will continue to work.

 

Now legality warning. It may be illegal to divulge how to make any non-TM-made controller to work with TARGET, due to DMCA. Although it may be perfectly legal to program Hempstick this way, it may violate your license agreement with TM for using TARGET in this manner. I am not a lawyer, but you have been warned.

Link to comment
Share on other sites

Interesting project!

Do you plan to make it compatible with ATMEGA16U2 Chips like in ATMEGA 2560 boards?

I dont understand the 32 buttons limitation you have. I actually use ATMEGA Boards where i can wire up to 256 buttons (2x 128 Buttons Joysticks) and it works smooth on DCS.

 

 

Absolutely no ATMegas! It defeats the whole purpose of using up-to-date electronics. ATMegas are too old as a joystick controller, so are a lot of the PIC MCUs used in today's joystick controllers. I wrote Hempstick mainly because I couldn't find one available on the market that is up-to-date and extendable. Why would I go backward?

 

As to 256 buttons... then I must ask this question. Why stop at 256? How about 1024, i.e. 8x composite joystick controller all in one physical controller? Is 1x 256 buttons controller better than 4x 64buttons $39 controllers? In what way?

 

To really understand why there is a limitation on how many buttons Hempstick is WILLING to handle, you have to understand event-based architecture Hempstick uses. I am writing an article about it right now that will explain why you don't want to use the old way of busy polling that everybody seems to be using, except a few newer ones. Hang tight.

Link to comment
Share on other sites

Hi Hempstead

We exchanged more than a few e-mails and opinions, but I just wanted to stop by and share my admiration to your project - in public :-)

 

Let's put my words in another context so users can understand :

If hempstick was released a year ago I would probably embrace it and develop firmware for MFG Crosswind together with Hempstead...that's how promising this thing looks :-)

 

Nice article on resolution too, good reading.

If it can make you feel better, I know warthog is NOT 16 bit stick :-)

 

I've just thrown a few words myself about sensor resolution, digital versus analog...sensor accuracy... to stop the hype about digital sensors. My words are ment for more general public without going too deep or nicely structured as yours :

http://simhq.com/forum/ubbthreads.php/topics/3990928/Re:_Slaw_VS._Milan_the_battle_#Post3990928

I hope you won't mind if I share a link to your document.

 

Subject that you described about resolution, or should I say only "scratched the surface" in your manual is truth :-)

I would say that your document on resolution also touch the subject of extracting more juice than sensor and ADC are capable of :-)...and could be useful to build up on top of my explanation :-)

 

However...I'll stress out a few things that you did not touch

Human performance of reaction within 100ms, or 200 ms...don't matter...is a performance delay BEFORE even reaching mechanical input which trigger sensor reading - and further delay in signal processing to simulator reaction. That's why it is important to keep electronics speedy, but 10 ms delay to windows output is truthly enough.

Why I say this...human reaction + signal delay...

If it's human 200 ms + 1 ms signal delay...or 200ms + 20ms...it makes some minor difference and can be noticed by virtual aces :-)

 

Pure Signal output speed to windows is not that critical. The way signal is processed can fool the end user and I belive that's what Warthog is all about.

In your document you assume that averaging takes place like...wait for a bunch of samples...then calculate and send...so it take sampling time

I can't reveal my code here but I'll give you a hint

 

When taking last sample from the sensor you DON'T WAIT for other samples...but get the juice for resolution based on the samples that were taken in the past.

Easy way to use it...is just like histogram... you retain high resolution as well as fast output ...but in the end...it's fooling...as value that is output to windows is calculated upon values in the past...( I belive it's warthog's way)

Better way to use this method is to make such equatation that more recent samples are more important than older samples...getting best of both worlds...require some juice from MCU...so put ARM to good use :-)

Even better way is to add some averaging and decimation for "each sample that count" in the process...get you greatest juice.

 

On top of that...since I only use 3x axis on pedals so I have cycles to spare...more than one calculation can be used...one for fast movements and one for fine movements...this get the best of both worlds in terms of reaction time, noise and resolution...again...a bit MCU intensive. I call it "adaptive FIR, Low pas, averaging and oversampling method"

Link to comment
Share on other sites

Absolutely no ATMegas! It defeats the whole purpose of using up-to-date electronics. ATMegas are too old as a joystick controller, so are a lot of the PIC MCUs used in today's joystick controllers. I wrote Hempstick mainly because I couldn't find one available on the market that is up-to-date and extendable. Why would I go backward?

 

Ok understood, i don't criticize i just ask a question, i'm a totally noob concerning all that microcontroller stuff!

 

As to 256 buttons... then I must ask this question. Why stop at 256? How about 1024, i.e. 8x composite joystick controller all in one physical controller? Is 1x 256 buttons controller better than 4x 64buttons $39 controllers? In what way?

 

The limitation to 32 or 64 is a concern with devices like the CDU using 67 buttons alone, which means two cards for the same Peripheral, with a board that can mangage that huge amount of buttons is that i only need 1 board to make my CDU (i can also placemy board into the same enclosure) ofcourse i'll probably never use 256 buttons for the same device but i have enough room to create the biggest device with only one board.

 

Anyway i think your work is very interesting and opens more rooms for guys like me that create home cockpits, and i'll follow your project with massive attention!

 

To really understand why there is a limitation on how many buttons Hempstick is WILLING to handle, you have to understand event-based architecture Hempstick uses. I am writing an article about it right now that will explain why you don't want to use the old way of busy polling that everybody seems to be using, except a few newer ones. Hang tight.

Looking forward to read it! :thumbup:

Link to comment
Share on other sites

Ok understood, i don't criticize i just ask a question, i'm a totally noob concerning all that microcontroller stuff!

 

 

 

The limitation to 32 or 64 is a concern with devices like the CDU using 67 buttons alone, which means two cards for the same Peripheral, with a board that can mangage that huge amount of buttons is that i only need 1 board to make my CDU (i can also placemy board into the same enclosure) ofcourse i'll probably never use 256 buttons for the same device but i have enough room to create the biggest device with only one board.

 

Anyway i think your work is very interesting and opens more rooms for guys like me that create home cockpits, and i'll follow your project with massive attention!

 

 

Looking forward to read it! :thumbup:

 

I didn't detect any criticism. I am a programmer by trade. I talk straight.

 

CDU is a good example I didn't think of. Good point. My mistake.

 

There are basically two approaches to solve this problem.

1. Brute force it. Get a bigger MCU with more leads. But that depends on the manufacturer, and it costs more money. Or get multiple $39 boards. This sucks.

2. Extend it to read more buttons other ways.

 

The whole point of Hempstick is that we can extend it relatively easily. ;-)

 

I'd say #2. Controlling one device with two boards is just stupid. There are basically two ways to solve this problem.

A. Use a matrix.

B. Use a buffer like TMStick does, or use a bunch of input extender chips like BU839X does.

 

I'd go with B with buffers like TMStick has for two reasons.

i). Hempstick already has a TMStick module to read the buffer with pure hardware. And it does software debounce on it already. And we know the hardware buffer solution has worked well for oh so last decade or more.

ii). No diode to deal with., no ghosting either, and the wires number is ---- you guessed it, 5. Less wiring than a matrix solution. And less MCU pin demands too!

 

The hardware cascaded buffer is so simple to construct, you can use a breadboard if you want. But I wouldn't recommend using breadboards, b/c if we drive the damned thing through a couple of MHz, you are going to run into trouble. Yes, even these old old chips can run into a couple MHz... I just felt it wasn't necessary to drive them that hard and ran them at a couple of hundred KHz. Moreover, the longer the wire the more problem there could be with higher frequency. But with more chips cascaded, you probably want to run them at higher freq. so it doesn't take too long to read. Hardware reads it anyway, it doesn't use more CPU at all (well, except that originally I copy three bytes, now I copy 16).

 

There are two parts to this modifications.

1. Steal the TMStick code and you can construct a cascaded buffer just like TMStick has. Cascade it to infinity & beyond, ok. ok, up to 128. Cascading this thing longer than that is a bit crazy. But there is nothing stopping you from doing that.

2. Optional. If 128 is all you want. Change the USB report to be 128 instead of the current 64. Trivial.

If you want more than 128, well, change the USB report to have to HID report descriptors, and then send back two reports. Each containing 128 buttons. This is not so trivial, but not exactly difficult. Very minimal amount of code change.

 

Time to order a bunch of those buffer chips.

Link to comment
Share on other sites

The shift register chip, CD4021BC by Fairchild, used inside Cougar/Warthog is obsolete. Can't buy it anymore from regular channels. So, I found a replacement HCF4021 from ST. It runs up to 20MHz, although it only goes up to 10V instead of 15V, it's good for both 3.3V & 5V operations.

 

It's so cheap that I had to order 100 of them ($19.40) and still couldn't justify the s/h, so I also ordered a bunch of MCP23S17 IO expander chips with SPI interface. We will see which one works out better. Maybe I will support both.

Link to comment
Share on other sites

Thanks for your kind words, Milan!

 

Hi Hempstead

 

 

When taking last sample from the sensor you DON'T WAIT for other samples...but get the juice for resolution based on the samples that were taken in the past.

Easy way to use it...is just like histogram... you retain high resolution as well as fast output ...but in the end...it's fooling...as value that is output to windows is calculated upon values in the past...( I belive it's warthog's way)

Better way to use this method is to make such equatation that more recent samples are more important than older samples...getting best of both worlds...require some juice from MCU...so put ARM to good use :-)

Even better way is to add some averaging and decimation for "each sample that count" in the process...get you greatest juice.

 

On top of that...since I only use 3x axis on pedals so I have cycles to spare...more than one calculation can be used...one for fast movements and one for fine movements...this get the best of both worlds in terms of reaction time, noise and resolution...again...a bit MCU intensive. I call it "adaptive FIR, Low pas, averaging and oversampling method"

 

 

 

Well said, Milan.

 

That's exactly the strategy I took in Hempstick! ;-)

 

I used an internal timer to trigger ADCs at a configurable frequency, at 1KHz x 4^n oversampling rate to match the 1ms USB reporting rate. And let the ADC run on its own pace at that rate. All 16 channels can be sampled by one timer trigger event. The ADC module will automatically sample all the channels I enable in one shot. Once it's all done, it does a DMA transfer to my designated buffer, and then issue an interrupt to my ADC interrupt handler, all done without intervention. The interrupt handler simply copies the data away from the buffer and reload the DMA buffer pointer preparing the buffer for next ADC trigger. Then it does a "give" on a semaphore to trigger a FreeRTOS task. And it returns immediately so that it doesn't hog the CPU in the interrupt handler for longer than it needs to. Then, the FreeRTOS task handling the ADC will get unblocked and scheduled to run by FreeRTOS to process the ADC values. This ADC task just does a decimation on the existing buffer of the running circular buffer and a running average low pass filter. Then it copies the latest values to the USB report and went back to blocking waiting for the next notification of ADC value availability. So, even if I have multiple ADC conversions during one USB report period, say due to CPU being too busy or FreeRTOS scheduling delay of the ADC processing, it will always report to the USB host the latest available values, never wait for ADC conversion to finish. The ADC conversions simply run independent of the USB reports. ;-)

 

This way, the host computer always gets the latest of what you "feel" in your hand and is available for reporting, minimizing the delay as much as possible. I imagine it would be very hard to formally quantify the delay quality when it comes down to sub-10ms range without a rigorous large scale study. And I can't find any hard data on this subject. So, I took the safe route of over kill strategy since I got a lot of CPU power to bring to bear and Hempstick is an event-based architecture so it doesn't use any CPU cycle when there is no event to process. I give you 1ms USB reports, and the latest ADC/button values. So, that gives the upper bound of the delay to 1ms as well (as long as the ADCs don't take more than 1ms to sample all enabled channels and the CPU is not too busy; this is why I can only do 3x 16bit oversampled axes, because 4x would take more than 1ms to sample).

 

Since I have a lot of CPU... I don't do adaptive anything. I just brute force it to keep the code simple and straight forward. ;-)

 

In short, I basically ensure that the oldest report USB is going to get is 1ms old and it's the latest one, if the CPU is not overwhelmed.

Link to comment
Share on other sites

I don't know if you considered the other end - reciving such responsive control in a simulator

What you are doing now is sending 1000 updates per second for a simulator to interpret...

I don't know how coding of flight simulator to a game controller goes...depending on a coder....but consider this

 

Fire up joytester to give you only a graphical representation of the axis...simple job right. Now...at 1ms update rate...take a look how much joytester alone consume PC's CPU :-) I didn't thought about it either untill I've tried it on my notebook and vent's started spinning like crazy :-)

 

All I'm saying...is that speed really necessary...and if it come with a performance hit within a simulator or not...I suggest :

- testing various update speeds within a Sim

- making update rate adjustable...like option for 1,5,10,15 ms update rate

 

Did you consider making a windows front end application for making such adjustments like I did, so less experienced user can simply plug in a few cables, burn appropriate firmware...and hook up axis,buttons, filtering and other behaviour on a user friendly way...not a coder friendly way :-)

 

I've just published manual for my application, it's within a software package. I suggest to download and take a look of user adjustable features within windows for my chip

http://mfg.simundza.com/download.php

 

It's suited for pedals, and hamptstick should have a couple of more features there :-)

 

It's coded in a way to communicate trough HID buffer just like any other axis. I took an easy route with already done comunication by using mcHID.dll

 

Also...a bootloader stuff for upgrading firmware, I guess Atmel has some already prepared

Since you used Atmel tools to allow true open source with a free tool from Atmel to change the code...I guess application should follow the same principle ...but what is a free tool to make it

Link to comment
Share on other sites

Did you consider making a windows front end application for making such adjustments like I did, so less experienced user can simply plug in a few cables, burn appropriate firmware...and hook up axis,buttons, filtering and other behaviour on a user friendly way...not a coder friendly way :-)

 

I've just published manual for my application, it's within a software package. I suggest to download and take a look of user adjustable features within windows for my chip

http://mfg.simundza.com/download.php

 

It's suited for pedals, and hamptstick should have a couple of more features there :-)

 

It's coded in a way to communicate trough HID buffer just like any other axis. I took an easy route with already done comunication by using mcHID.dll

 

Also...a bootloader stuff for upgrading firmware, I guess Atmel has some already prepared

Since you used Atmel tools to allow true open source with a free tool from Atmel to change the code...I guess application should follow the same principle ...but what is a free tool to make it

 

No, I will not write a UI for configuring it or burning firmware through bootloader. Somebody else can write it, if they feel so urged to. Or get somebody else to burn it for you. Hell, buy one that is burned for you, if somebody wants provide such a trivial service and charge a fee for it.

 

I do consider other method for configuring Hempstick dynamically, there are some very good ideas I could do, but this functionality has much lower priority than other core functionality Hempstick currently lacks.

 

Releasing it as an OpenSource has its perks. Modify it as you wish. I made it easy to just change couple of configuration .h and .c file, you change it and you compile & burn the firmware yourself. That's why I spend so much time writing the User's Manual providing step-by-step instructions of the "screenshot digest" format. So you can install the IDE and tool chain yourself, load up the project, modify the config files, and then press just one button and the IDE will do everything including compiling/linking, upload and burn the firmware for you automatically.

 

The IDE does a wonderful job at that. Why bother writing another application to upload and burn the firmware through the bootloader while the IDE does a better job? I actually consider this process better for an OpenSource one than using a bootloader. I'd rather spend my time ensuring that Hempstick is not a pig instead of putting lipstick on it. I am not saying writing a GUI is always lipstick, it's necessary for closed sourced ones, but not so much with an OpenSourced one. Yes, it's less user-friendly... if somebody else really wants it that bad, s/he can write it.

 

I also intend to use this to "entice" people to learn this development process a little bit so they get their feet wet into this by start with modifying the configuration files a bit and then eventually starting writing things that they want themselves; or stay at the level of end user by downloading a set of config files created by others. Play with it, start your own project and create a set of your configuration files by modifying the existing one, then contribute it back to the community!

 

For instance, if you don't want to use 1ms USB report rate, go change src/config/conf_usb.c inside the USB device descriptor to whatever value you want, then burn your own firmware. Or, if you get a set of config files that have cleaner wiring for, say Cougar Throttle, than mine, share your config files.

 

In other words, b/c it's OpenSourced and the process of building/burning firmware is so easy, the Windows configuration GUI gets downgraded from "essential" to optional status, hence much lower priority.

Link to comment
Share on other sites

Let me put it this way....

 

If the flower power artists can do Arduino and even write some code on it, you as pit builders have no excuse of saying this building/burning Hempstick from source code is too difficult.

 

Remember, my intended audience is those people who tinker/build their pit/joystick etc., not the virtual aces, although they are welcome too. If the virtual aces don't wanna learn this technical stuff... so much better we nerds get to kick their asses in the air!

 

Remember, if it's a fair fight, you didn't plan it right (or hack it right!).

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...