4.0 software

[paintpiggie]

How did I get the code? I wrote it, and I'm the only one that has it.

demmit. now the secret's out.

[RTDynaflow]

First off, let me say i don't own an e/x-mag. I am just more or less curious.

Miscue, you wrote 4.0 software? Completely independent of AGD? I mean you don't work for AGD? How did people get the 4.0 software? Was it distributed with a batch of e/x mags? Do you flash markers to 4.2?

What are all the differences in the software? 1.2, 3.2, 4.1? Or whatever they may be...

I was also under the impression that ramping software would add balls after a certain bps was reach. For example, once you hit 15 it would add +1, or +2. When you hit 17 it would add it to 19, 18 to 20. Thus never keeping a steady bps. I see "ramps 3 bps.." all the time, esp on DM4s. That is how I came to that assumption. It would add 3bps after a certain bps was reached. It seems it would be "ideal" to add it +1 for every 2 over 15. Example: you hit 15, it adds 1, 17 it adds 2, 19 it adds 3. Would be difficult to find such things. Of course programming this would be hard, no?


Just curious, I am not looking to get my e-mag flashed to 4.2, as I don't own one. Just wanted to get some clarity.

[Miscue]

First off, let me say i don't own an e/x-mag. I am just more or less curious.

Miscue, you wrote 4.0 software? Completely independent of AGD? I mean you don't work for AGD? How did people get the 4.0 software? Was it distributed with a batch of e/x mags? Do you flash markers to 4.2?

What are all the differences in the software? 1.2, 3.2, 4.1? Or whatever they may be...

I was also under the impression that ramping software would add balls after a certain bps was reach. For example, once you hit 15 it would add +1, or +2. When you hit 17 it would add it to 19, 18 to 20. Thus never keeping a steady bps. I see "ramps 3 bps.." all the time, esp on DM4s. That is how I came to that assumption. It would add 3bps after a certain bps was reached. It seems it would be "ideal" to add it +1 for every 2 over 15. Example: you hit 15, it adds 1, 17 it adds 2, 19 it adds 3. Would be difficult to find such things. Of course programming this would be hard, no?


Just curious, I am not looking to get my e-mag flashed to 4.2, as I don't own one. Just wanted to get some clarity.

No, Tom asked me to make it. I started Q1.x right after AGD announced 3.0 and its features. I think it took me just a couple days to match 3.0's core features, and I put in some extra stuff like a BPS meter, and then I sent TK a copy of it - this led up to the AGD 4.x thing.

I didn't fill him in on 4.20 until I had it done and had some promising (but not yet definitive) results. I don't think he knew I was still thinking about it. Heck, I thought I was done with it at 4.01 and would leave it to die. And, that could very well be the case with 4.20 as well - unfortunately - even if I could eventually verify that it does fix the problems... not 100% sure on that yet... waiting for the odd-ball EMag that spoils it like last time.

Mostly AGD people have it, and a few markers were flashed at a California meet - and that's how I discovered the FA issues - the marker I was testing did not have these problems so I never ran into them beforehand.

The description of ramping that you're talking about, is pretty much how I think of it as well. Basically, it's "Turbo" or "Hyper" mode with a different name as disquise - since "Turbo" is specifically not allowed. But what makes it different from traditional turbo mode is that it can shoot at a variable speed, depending on what is being maintained on the trigger. I don't know if boards labeled as "Ramping" actually do what you described - could be something else, like outright turbo mode or some slight variation. The reason I think this is... the markers I've observed at the tournies - they basically shoot as though they are a steady full-auto as long as fingers are wiggled quick enough. They really take off - machine guns.

No, it's not particularly difficult to implement.

1.x was the original stuff for the EMag. 2.x eventually had ACE code for XMag. 3.x had rudimentary shot buffering. 4.x corrects 3.x's shortcomings - it's the result of a paintballer who owns the marker and knows what he wants in an electro, versus programmers who don't have those insights and are limited to what a client requests - and no extra.

[Z-man]

http://homepage.mac.com/zvetter/.Movies/SFL%204.0%20Testing.mov

[RTDynaflow]

wow, thank you. That video reminded me of why i dont post on pbn. Sweet mag btw.

[eadtf]

Thnaks for the Response...

This software does not let you harmlessly play Tetris on your PC - it controls a device that shoots projectiles - and there are safety issues.

So official sounding!

Lawsuits, probably not!

The electronics cannot make the marker do something that it mechanically is not capable of doing. Example, the worse program in the world cannot make the Air Tank explode. It cannot make the bolt start shooting bullets instead of paintballs. It cannot adjust the pressure released on the ball so that the ball is shooting 1000 fps. Yes you could damage your electronics, yes you could mechanically mess up the on/off, bolt action, and trigger assembly, these are hardly lawsuits. The only real danger you face external to the marker is full auto.

If it happens off the field, you should have a barrel sock or plug anyways. If not the lawsuit may be against you! If it were to happen on a field, well I sure as hell would make the best of it and go for a few kills.

By the way my job is shooting projectiles! The best safety - my trigger finger!

[Miscue]

So official sounding!

Lawsuits, probably not!

The electronics cannot make the marker do something that it mechanically is not capable of doing. Example, the worse program in the world cannot make the Air Tank explode. It cannot make the bolt start shooting bullets instead of paintballs. It cannot adjust the pressure released on the ball so that the ball is shooting 1000 fps. Yes you could damage your electronics, yes you could mechanically mess up the on/off, bolt action, and trigger assembly, these are hardly lawsuits. The only real danger you face external to the marker is full auto.

If it happens off the field, you should have a barrel sock or plug anyways. If not the lawsuit may be against you! If it were to happen on a field, well I sure as hell would make the best of it and go for a few kills.

By the way my job is shooting projectiles! The best safety - my trigger finger!

The worst it can do is misfire and injure someone - shoot an eye or both out.

You bet it can result in a lawsuit. It's happened before. And even if it's determined that you're not at fault, it can cost hundreds of thousands to defend against the suit. It's a very real problem that has occurred before at great expense. And then there's the burden of knowing something you made hurt someone - even if it wasn't your fault it's hard not to blame yourself... and that's something you have to live with.

[Dayspring]

Well I'll put it to you this way.

Kid shoots his eye out. Parents sue Tom because it was his gun. (Not mentioning the fact that the kid did something stupid.) Tom procedes to sue Danny Tippmann because there was a Tippmann air tank attached and Tom's gun couldn't do anything if it wasn't for the tank. (true story, told by Tom himself.)

So lawsuits are a more real thing than you might be lead to believe. Also, your best safety may be your trigger finger, but do you trust everybody elses? I doubt it...

[shatter_storm]

Eadtf: Please take a little bit of advice from someone in the software industry.

Most programmers do not like sharing their code. We react quite like if someone had asked to see our wife naked - the answer is (usually) a resounding no and we get a bit offended. Miscue probably isn't going to give you his code and probably won't show any of it to anyone other than TK himself and the techs that would understand such code. I can't say I blame him, there are a few very good reasons why he shouldn't give it to anyone.

However, don't get discouraged. You can get what you want out of the e/x-mag. Find someone with:
1) Knowledge of embedded systems. You'll probably want them to have a degree or a few year's experience so that you know they'll produce something worthwhile.
2) Money. Programmers (the actual hardware itself) arn't free. I know AGD built some pins into the board for programming purposes - figure out if they're using serial or parallel programming mode and design an interface to fit.
3) Time. Miscue wrote 4.0 in "a couple of" days, he said. I don't doubt that fact, but I'm betting he has production level experience with embedded systems and probably has prior experience with the emag board or the chip used on it. Assuming you hit a few roadblocks and have to go digging for info or experimenting with things, I think you could have a semi stable codebase ready in a week or two.

At the end of all this, you'll be able to flash your gun to say whatever at boot, have multiple firing modes, and do whatever your little heart desires.

[adlar]

I agree with some of the programmers here. If you really want it, program it yourself. The project itself could be more interesting than the end result. Warpig has an article on how to play with BASIC stamps and get them working with paintball markers. Start by trying to understand Bill's code, then delve into pbasic and learn how to make it do what you want. This code is easier to understand than assembly languages. PBasic is a little more cryptic than C, Pascal, VB, Java and most scripting languages so don't expect to write code that makes sense overnight. I've got a Basic stamp sitting on my desk right now, and believe me making that first led blink on and off is a lot more exciting than the first hello world program many people write in their intro programming classes. Besides the programming itself, there is the battle to get the electronics and mechanics to do what your program is asking. Just because you can tell the solenoid to fire doesn't mean it will trip the sear. I think Miscue has had to really observe how his marker reacts to each revision of his code. Without that observation, having his code would offer you little insight into why he made the decisions he did, and how it affected the operation of the marker. Thus modifying the code would leave you open to making many of the mistakes he had already solved through his own development process.

[sig11]

There are no bugs - the software has been flawless for quite some time. The hardware has been the problem. If you can make a very small, cheap, and effective degausser - then you'll have my attention.

I liked your analogy. I assume you're wanting to degauss the HES? That would require a pretty large curren't even though the target is small won't it?

Lee

[Miscue]

I liked your analogy. I assume you're wanting to degauss the HES? That would require a pretty large curren't even though the target is small won't it?

Lee

Nope, not the HES.

[Miscue]

I agree with some of the programmers here. If you really want it, program it yourself. The project itself could be more interesting than the end result. Warpig has an article on how to play with BASIC stamps and get them working with paintball markers. Start by trying to understand Bill's code, then delve into pbasic and learn how to make it do what you want. This code is easier to understand than assembly languages. PBasic is a little more cryptic than C, Pascal, VB, Java and most scripting languages so don't expect to write code that makes sense overnight. I've got a Basic stamp sitting on my desk right now, and believe me making that first led blink on and off is a lot more exciting than the first hello world program many people write in their intro programming classes. Besides the programming itself, there is the battle to get the electronics and mechanics to do what your program is asking. Just because you can tell the solenoid to fire doesn't mean it will trip the sear. I think Miscue has had to really observe how his marker reacts to each revision of his code. Without that observation, having his code would offer you little insight into why he made the decisions he did, and how it affected the operation of the marker. Thus modifying the code would leave you open to making many of the mistakes he had already solved through his own development process.

Yeah, the actual code took little time - when I said 2 days I meant about 48 hours, including debugging and testing... most of the bang-head-on-wall stuff I had taken care of in Q1.x. Everything up to AGD 4.x inclusively represents at least a couple hundred hours of time, including maintenance, field testing, and such. It's only like 750 instructions I think - and a lot of it is necessary background stuff, like the menu system, display driver, etc. 95%+ of my time was not spent on actual coding - a lot of testing and experimenting... trying different things, of course making some changes here and there. I put way more time doing robustness checks rather than coding - trying to break the software with every conceivable situation... making sure that it is indeed logically flawless and effectively deals with external problems.

Yeah, there are nuances that you would not think of, until you actually ran into these problems as you're working on it. The snags I ran into, I had no way of anticipating (it wasn't because I had program errors) - some of them took a good amount of time to figure out and fix... like stuff stored in the EEPROM magically disappearing at random because the chip is quirky - that was a fun one. Turned out to be EEPROM reads (not writes) under certain conditions would write garbage to the EEPROM... go figure. Heck, that last sentence represents hours worth of work and frustration, and lots of caffeine, to even figure that out - let alone fix it.

The problem reproduces itself on very rare occassion (and not on every marker = I had to thoroughly test multiple markers) and I had to drain the battery just right... recharge the battery, drain it... etc... to put it under the right conditions. I came up with an obscure solution to the obscure problem that happens at random once in a blue moon on some markers, a coded solution that is entirely unrecognizable to anyone but me - unless you understand why and when it happens, and how to avoid it... requiring hours of screwing with it much like I did. So, you guys just want me to just hand over the code eh?

It is related with a lack of hardware-based brown-out protection, and the chip operating incorrectly under low-voltage conditions (there's another $100 tip for ya). This is one of several oddities I ran into... and was not the worst of them. Anyone complain about 3.2's EEPROM storage and stuff like the shot counter and various settings getting screwed up? Now compare that to people complaining about 4.x EEPROM storage. Tee hee. There's a reason for that.

Your last two sentences are on the money - not everyone understands this, and it's hard to communicate that idea in a way that someone can swallow - so they don't think you're just trying to be evasive. In a way it requires a leap of faith, and the acceptance that I know what's going on - having very good reasons and the insight to not hand my work over... which I can't do anyway because it's not really mine anymore.

[Miscue]

Eadtf: Please take a little bit of advice from someone in the software industry.

Most programmers do not like sharing their code. We react quite like if someone had asked to see our wife naked - the answer is (usually) a resounding no and we get a bit offended. Miscue probably isn't going to give you his code and probably won't show any of it to anyone other than TK himself and the techs that would understand such code. I can't say I blame him, there are a few very good reasons why he shouldn't give it to anyone.

However, don't get discouraged. You can get what you want out of the e/x-mag. Find someone with:
1) Knowledge of embedded systems. You'll probably want them to have a degree or a few year's experience so that you know they'll produce something worthwhile.
2) Money. Programmers (the actual hardware itself) arn't free. I know AGD built some pins into the board for programming purposes - figure out if they're using serial or parallel programming mode and design an interface to fit.
3) Time. Miscue wrote 4.0 in "a couple of" days, he said. I don't doubt that fact, but I'm betting he has production level experience with embedded systems and probably has prior experience with the emag board or the chip used on it. Assuming you hit a few roadblocks and have to go digging for info or experimenting with things, I think you could have a semi stable codebase ready in a week or two.

At the end of all this, you'll be able to flash your gun to say whatever at boot, have multiple firing modes, and do whatever your little heart desires.

I'm in agreement with you. The source code is also not mine to give, even if I wanted to - which I don't for numerous reasons - primarily because it would get in the hands of incompetent or non-programmers, and good programmers do not need it to begin with... no good can come of it. To make significant changes, would require large portions of 4.x to be thrown out - might as well start over - it is not particularly modular code where you can simply cut and paste w/o breaking something else. Whatever I make is property of AGD - I do not own it, and thus cannot distribute it.

[RTDynaflow]

So, would you flash someone mag to 4.2 for a fee? If you would rather not answer this thats fine. Just curious how some of these people have the 4.0 stuff...

if this was answered previously forgive me