[cruciatus111]

Cost?

[R-M-I]

20$ pr board..
Cheaper the more boards are flashed in a single parcel (group-reflash) would be preferred with international "customers".
10 boards or so I'll do for 15$ each.20 for 12.50$ each.
On top of that comes the return shipping cost that will be divided among the x-ammount of people doing the reflashes.. Again, the more people getting a reflash, the cheaper it will be for each person
Your choice of firmware (based on the list above)

A third party sending all boards to me, I'll reflash them all (they should be marked with name and version you want flashed), then return all boards to the third party(of your choice) in the US that will return boards to the owners of the respective boards...

[Japy]

So there are no updates to E1 boards, correct? Not that I really care for the firing mode options, but it would be kinda cool.

Also part of the E1's battery consumption issue is that it's a digital on/off.. So it's always sucking juice even when turned off. I put a new battery in my E1 and let it sit all week and the battery was dead when I went to play with it the next time. Worst board design in the history of paintball boards. Really my only complaint with the board.

[R-M-I]

You guys have to understand that this will take some time

I have the firmware WRITING to E2's and ZeroB's ready to go...so I can flash ANY older firmware to the 1.10 or 1.20 firmware if anyone would want to have that done...


For me to be able to do anything about the E1 firmwares, these are the things I need to doI'm probably missing a few steps aswell)

- Get a programmer that can actually interface with the PIC\chip-type on the E1 board
- Get that programmer to interface with a pic-programmer-software
- Get the programmer-software to interface with the board (meaning having to figure out pinouts for the PIC on the E1) and making a connector or solder the leads directly to the backside of the board. (option 1 is clearly to prefer).
- Get the programmer to write and hopefully also read the PIC on the board
- Get AMAZINGLY good at assembly, as the only thing one would be able to get out of the PIC on the board would be HEX\Binary data. Which can't be "compiled\decompiled" back into C or whatever the hell kind of language they originally was written in.
- modify the firmware
- re-upload the modified firmware to the board

OR.
- Make the firmware from scratch..which would take AGES and AGES of programming.
- Upload\write the new firmware to the board.

This is actually pretty complicated stuff.
There are also space issues to keep in mind here as far as adding features etc. goes.


--

My priority right now is to make my programmer able to read out the firmware binaries\hex-files from the chips.( If someone out there wants to share the 0.19 0.24 etc E2 firmwares with me, feel free to PM me... As that would save me a lot of time\trouble).. If not I'll just build my second programmer(one which doesn't use outdated and way too complex technology). So I have a full collection of firmwares.

I do this mostly to learn...And although I would like to help out with the E1's. I WILL be focusing on E2's and "other" boards in the immediate future.
I am NOT a electronics specialist or anything.. I work in the IT-business. And do all of my tinkering in my spare time, (the tiny amounts of spare time I actually have).
If I am going to try to make a working firmware for the E1's from scratch..I will need to do that in collaboration with people capable of programming these things.


EDIT:
Holy batman-wall-of-text!
There are probably a lot of incoherent ranting going on up here.. But that's what you get when you ask away about the E1's like that
Hopefully things are understandable up there. If not, shoot me a PM or ask away in this thread.

[jonotwist]

id be very interested in wht comes of this, pm inbound but feel free to add me to any contact list. for ecocker service.

[Japy]

I had a feeling the E1 was a bit more complicated when I asked.

I wouldn't really worry about it. While it sounds like its doable, I don't know if the demand would really be there for the E1 board stuff to justify all the work you'd have to put into it. The battery life problem would still exist, we'd maybe gain some more programmability of the board but at what cost to make it worth your time?

I say skip the E1's. Like I said, the one thing that I really don't like about the board is the battery issue. You can cap the ROF on the E1 the same as the E2- it just takes more work. And with as bouncy as E1's are by design.. You really can't say that you "need" a firing mode option for them.

[cruciatus111]

the only mode i care about on an E1 is the classic mode, and im fine with that

[Willieocean14]

I jus installed the worrblade kit on my gun and its pretty amazing. The battery lasts like 3 times as long as my e1 theyre jus kinda hard to find now . I just wish it had a full auto mode

[LOKIm]

Ive got like 4 e1 boards I'd flash

[cmdrsuds]

Can you change / modify modes? Major differences between 1.10 and 1.20 software?

[hmcl281]

they just change the firing mode name from version 1.1 to 1.2

rmi sold the flashing equipment to doc

http://customcockers.com/forum/showt...lash-you-board

[R-M-I]

I still have a programmer... a multiPIC-programmer that SHOULD be a bit more versatile.. The E2 PIC's are code protected. The E1-boards are NOT however.. This is the project I'm currently working on as there seemed to be a lot of interest regarding the E1 boards.

EDIT:
So far I've managed to:
- Build a programmer that can actually interface with the PIC\chip-type on the E1 board
- Get that programmer to interface with a pic-programmer-software
- Get the programmer-software to interface with the board (meaning having to figure out pinouts for the PIC on the E1) and making a connector or solder the leads directly to the backside of the board. (option 1 is clearly to prefer). Option 1 used.
- Get the programmer to write and hopefully also read the PIC on the board

- Get AMAZINGLY good at assembly, as the only thing one would be able to get out of the PIC on the board would be HEX\Binary data. Which can't be "compiled\decompiled" back into C or whatever the hell kind of language they originally was written in.
- modify the firmware
- re-upload the modified firmware to the board

Figure the best way to go about it in the E1 would be to just wipe the entire PIC, programming it from the ground up.. I have laid out all the schematics, pinouts, routings for all the components on the board and all that..
All I need is some basic ramp-code..But I'm sure that could be pulled either from some open source project..or programmed fairly easily from the beginning.
If anyone has some HEX-code that would work with a E1-board, I'll be MORE than happy to try it. OR for the E2.

[yuik]

Hell yes , what kind of
Assembly is this crap in

[R-M-I]

The original code was most likely written in C. And then compiled into ASM, which in turn is compiled into HEX that one would feed into the PIC.

I can retrieve the hex-files from the chips using my current programmer. And convert them back into Hex, but it's not possible to reverse the process from assembly to a high-level language(back into C for example).

Which means "we" have two options:
- Rewriting the code from the ground up. (this is what would be REALLY fun).
-- Editing the assembly code that's already in place.

I'm also working on another programmer that should be able to interface with the board via serial. (this will work for both the E1 boards and E2 boards, possibly also the early Ego-boards(although a different connector will have to be used, as the pinout on the ego-chips is different aswell as the update-connectors). [already made a circuitboard with headerpins that will interface directly with the ego update-connectors on the board..making me able to interface with the board without having to solder in leads etc.].

I'm in no way a professional when it comes to these kinds of things. I simply do this for the fun of it..and to learn about new things

IF we have some good programmers in here, I'd love to get some help on the actual coding of the E1 boards.. Figuring limiting the modes to two modes would suffice to begin with (the memory of the E1's = limited), so..would be better to just code a few different firmwares with different modes. So one could choose which one to run.