[034v]

Heads up.. From their site. Need to grab some SCT 6600's while you can if J3 is your thing.

Holiday Greetings!

As we move into the end of 2022, we sincerely want to say "THANK YOU ALL" for support and patronage. It's been a thrill helping folks with their efforts, and we've truly appreciated the opportunities to socialize, exchange ideas, learn, teach, and facilitate along the way.

We're closing down the webstore and related operations so that we can pursue the balance of our lives in different areas. There are several challenges that have led us to this decision, and we hope you can all appreciate the following:

The headwinds of production supply shortages have cut our supply lines to the marrow. Many components we've used have lead times of a year or more, with costs having increased significantly along the way. There's no end in sight, and we don't want to sacrifice quality with questionable sourcing or chase the costs by increasing prices.

We've been doing this for a while now, and we're tired and getting older. It's time for us to take a step back and focus on health, family, and overall wellness. Running Moates.net has taken a tremendous amount of time, which is a limited resource and in short supply. Between arthritis and chronic pain of hands, backs, and other various injuries of body parts, it is a challenge to physically perform tasks needed to keep things going and we need to change what we are doing to improve our quality of life.

We wish you the best on all your projects, whatever they may become. It's been an amazing experience, and again, we truly appreciate you all as we take this step!


Giving thanks,


Craig, Bonnie, and Dave

[jsa]

I asked Craig if he would open source the IP to the community, no was the response.

Needs some to redesign using available parts, ideally compatible with the existing protocols.

[cgrey8]

I know the part availability is real. We recently had to re-spin our hardware to use a different brand of FPGA since the lead-time for the one we were using both went way up and the price went from ~$5-6/part to $300/part!!!! Obviously the supplier just wanted to discontinue that skew but if we were willing to pay that exaggerated price, they'd still keep it (although it still wouldn't have improved lead time). That forced us to a competitor, as well as revisit the board design, FPGA programming, and production programming procedures. I was actually impressed that the team in charge of doing that was able to make that transition in a matter of 2 weeks. I expected that jitter to take way longer, but they figured it out.

Moates uses a CPLD on the Quarterhorse (similar to an FPGA) so it doesn't surprise me that availability of that part might've disappeared along with our FPGA. Being SPLDs and CPLDs are such old technology, my guess is anybody that is going to update a Quarterhorse may be forced to consider a respin to use an FPGA instead which does complicate things. FPGAs have to be loaded with their programming every time they are powered which takes a little time...time that the EEC is going to be trying to get its programming and getting nothing from the chip. It may only be milliseconds, but that's enough for the EEC to go off in the weeds and do stupid stuff (e.g. clear KAMRFs every time the EEC powers).

I have no clue about the EEPROMS used on the burnable chips. That's such old technology compared to what we are using at work, I have no feel for how available that stuff is or if those were also retired by the supplier.

I assume he's trying to sell the IP, not open-source it. But with the hardware requiring some updates and redesign, I don't know how many takers there'll be for the business given the specialty skill-set it'd require to get it usable and continue it. There aren't that many people that understand CPLD programming in the industry to start with.

[jsa]

Moates uses a CPLD on the Quarterhorse (similar to an FPGA) so it doesn't surprise me that availability of that part might've disappeared along with our FPGA. Being SPLDs and CPLDs are such old technology, my guess is anybody that is going to update a Quarterhorse may be forced to consider a respin to use an FPGA instead which does complicate things. FPGAs have to be loaded with their programming every time they are powered which takes a little time...time that the EEC is going to be trying to get its programming and getting nothing from the chip. It may only be milliseconds, but that's enough for the EEC to go off in the weeds and do stupid stuff (e.g. clear KAMRFs every time the EEC powers).

I recall you put forward the idea of a beaglebone, having looked I found some of those were 11 seconds to boot.
Any revision to new hardware would come with opportunity and challenges, but may be the only choice longer term.

I have no clue about the EEPROMS used on the burnable chips. That's such old technology compared to what we are using at work, I have no feel for how available that stuff is or if those were also retired by the supplier.

Other brands of J3 chips seem to be available still...who knows for how long. Trouble is different brands require different programming tools at some cost.

I assume he's trying to sell the IP, not open-source it. But with the hardware requiring some updates and redesign, I don't know how many takers there'll be for the business given the specialty skill-set it'd require to get it usable and continue it. There aren't that many people that understand CPLD programming in the industry to start with.

Others have said they've asked to buy or license the IP, but no as well.
Any QH compatible new design could do with some enhancements like A/D channels and CANbus.

Of those that understand CPLD, how many have a significant interest in these old EEC's??

A quick search for the CPLD and other IC's used on the QH, reveals the CPLD is on back order at many places until April. Prices on the CPLD wildly vary from ~$14 to 200 from those with stock. May all depend on what, the new owner, AMD plan to do with the Xilinx product lines.

The FTDI chip is on back order at Mouser but available elsewhere. The others seem readily available.

The TwEECer is still available, so that seems to be the emulator fallback position, but what does that mean in terms of usability?

[jsa]

Holiday Greetings!

I see all the support literature has gone from the site as well!

[xd41efisc]

I see all the support literature has gone from the site as well!

They could have at least given some warning so we could have made copies of documentation that is needed to use some of this stuff.
They could also have passed the documentation on to sites like this, so the people who have supported them and still use the equipment don't get screwed.
I have needed some of that documentation quite a few times over the last 12 years or so.

[Diabolic1]

So for those of us with a QH and BE and have a tune ready to burn to a J3 chip......where can we get a J3 chip to write the tune to? I have an Ostrich to burn my chip but no chip. I was going to order one for Christmas but that doesn't look like it can happen any longer.

[034v]

You folks can keep checking here to see if the Docs get loaded up.

http://gearhead-efi.com/gearhead-efi/moates/

[jsa]

Yeah, I don't get the callous disregard for the user base with regard to the support information.

Moates J3 are going to be difficult to track down. It has been said the sct chip is an option. TI performance have chips which will require their tools.

It'd be worth checking the way back web archive for support info.

[AuroraGirl]

Frankly I would be offended if I was any of you all here trying to work with your vehicles, and be enthusiasts. I was hoping for the future, but now its definitely gonna have to wait on 1) probably global supply of computer components 2) Someone to re-engineer the stuff in question or find a new avenue.

I find it concerning that they are both unopen to open sourcing their creations and selling.... is this some kind of hill to die on kind of thing? Be remembered as the kid who got tired so he took the ball home with him and everyone else was left to eat dirt?

Their reasoning for being done is fair but they are not acting consistent because they would only benefit and others would benefit if they were to sell/make it open source. I dont get it. But hopefully someone finds a way. I almost wonder if a larger EFI company might not swoop in with new production or modified original EEC units that have built in interfacing technology that allows something equivalent or something. Hopefully its not MSD(joke there for those of you who know what I mean)

[jsa]

Yep, but it seems out of character from my previous interactions with Moates though still a kick in the guts for the existing user base.

The chip shortage issue is a problem across all industries, so the impact of that on QH is understood. The more drastic measures don't make sense if retiring, got too wonder what other influences are at play.

The tweecer is available to use now. Flash tuning can be done on EEC-V. Elsewhere, others have stated an interest in doing replacement commercial product. No, not MSD :).

Probably enough combined knowledge on here to do something open source in time, but is the Tweecer so limiting as to warrant it.

[cgrey8]

I wouldn't be surprised if there is a deal in the works but it cannot be discussed publicly until it is a done-deal. I don't know that there is, but being how out of character this is and how quickly this has happened, I just kinda suspect there's more to the story that will be revealed in time.

As for my idea for a J3 device, it was based on the Beaglebone Black (aka BBB) but that's 17 year old technology now. What's sad is that more modern solutions like the Raspberry pi don't have the realtime capabilities of the BBB. But the beagleboard.org does have a new solution, the Beaglebone AI-64 which is a much more modern dev board and even more realtime capabilities which makes it a very interesting platform with lots of options for growth.

I'm more than glad to share my thoughts on this idea and see if there are others interested in starting up a project. I do not want to be the lead, but I would love to have my hands in something like this and contribute where I think I could be most useful.

[jsa]

I'd be interested to hear your ideas.

Cost needs to be kept down otherwise it ends up being better to just get a 3rd party ECU.
I like the idea of having IO on board, say a QH / super logger combined.
Expose the IO values to the EEC side as well as PC side.
Another option, add CANbus to it, so gauges can be hung off of it that display EEC values, or have CAN sensor values dropped into spare EEC ROM space. Basically it acts as a gateway for (pre CAN) EEC hardware. Could do that already by hanging an interface device off the QH UART.

Yeah, having the time and knowledge to lead something like this to completion in a timely manner is a big ask for something open source.
It is far more straight forward if a commercial replacement comes to market relatively quickly.

[cgrey8]

https://eectuning.org/forums/viewtopic. ... RU#p131604
As it turns out, you were a part of that discussion.

The places I know I'm technically weak are hardware board design, UI/web development, and some algorithmic details that I'm sure people that can read Ford bins could assist with. Firmware Architecture, diagnostics/debugging, and protocol design are my strengths.

[AuroraGirl]

Yep, but it seems out of character from my previous interactions with Moates though still a kick in the guts for the existing user base.

The chip shortage issue is a problem across all industries, so the impact of that on QH is understood. The more drastic measures don't make sense if retiring, got too wonder what other influences are at play.

The tweecer is available to use now. Flash tuning can be done on EEC-V. Elsewhere, others have stated an interest in doing replacement commercial product. No, not MSD :).

Probably enough combined knowledge on here to do something open source in time, but is the Tweecer so limiting as to warrant it.

I wonder if it has to do with "going out of business because of COVID harships" that the state or fed may have some kind of program for. Selling a functioning company and assets would be less profitable than bailout or maybe insurance kind of claim. who knows haha

and oh yeah I forgot about the EEC-V can EEPROM overwrite , lol, well, at least mine can. i assume they all should.

[Jtab]

A simple heads-up would have brought them enough sales to change their mind about closing.

[cgrey8]

A simple heads-up would have brought them enough sales to change their mind about closing.

Unfortunately not if the problem was with parts supply.

[cgrey8]

I'd be interested to hear your ideas.

I've got a document written up that goes through everything I've researched and know right now. It's more of a proof-of-concept document than a design document. But I think it gets the point across, at least to those VERY familiar with the EEC-IV/V architecture. The document isn't meant for "light reading". Only the bin hackers are likely to fully understand what some of the details are referring to. Add to that, I could've gotten some of the details wrong. So having someone read it over and point out oversights and wrong assumptions would certainly be welcome.

I would post the doc here, but it's not even close to ready for public consumption. There's way too much speculation and assumption being made right now. But if individuals are interested in reading it over, I'd be glad to email it out. PM me with contact details.

[jsa]

https://eectuning.org/forums/viewtopic. ... RU#p131604
As it turns out, you were a part of that discussion.

Ah, yes, I'll reread it when I get a chance.

I'd be glad to email it out. PM me with contact details.

Ok.

[Shaker666]

I've been a TwEECer user since the early-2000s and suddenly realized it was the only viable option after Moates closed their doors. Mike Glover, the creator of the TwEECer, admitted that he's had some issues sourcing parts as well and that it may very well need a board respin soon. I don't know how many of you have dug into the circuitry of the Quarterhorse or the TwEECer, but myself and another friend of mine from the Megasquirt side of the world are wondering: is it really necessary to run an FPGA or CPLD to communicate with the J3 port on the EEC? We were thinking that perhaps the decision to go that route was based on the state of the art at the time the devices were developed. The current state of the art has a gamut of ARM Cortex microprocessors with enough capability to likely supplant the FPGA/CPLD implementation done for the aforementioned devices.

I saw the mention of EEPROM as well and I've noticed that a lot of the larger die ARM processors have onboard EEPROM - not emulated in flash or anything, but bonafide EEPROM on the die. An example of this is the TI MSP432... which is also one of the micros I was considering to be capable of supplanting the FPGA.

[jsa]

Here is a link to an ARM based idea;
viewtopic.php?f=8&t=22712&start=30#p135788

[tvrfan]

John (jsa) and I have talked about these ideas, and ways to go, so I'll repeat some of it here for everyone to comment.

Probably the two extremes are - the 'J3 plugin', through to a complete new CPU and board (a Megasquirt type answer). Then there's several possible solutions in-between those, like emulating the 806x code in a different CPU, emulating all or part of the hardware, and so on. * BUT * There's a lot of niggly but important stuff to be solved. We STILL don't know all the little quirks for the 8065 CPU for sure, and typically today someone has to trip over a problem for a new wrinkle to be found/sorted out. The same applies for the various specialist/proprietary chips which got more frequent in later EECs, along with mods to the 8065 CPU (we reckon) . So they become problems if emulating the code or hardware. With older EECs the in/out interfaces are well sorted (like injectors, ISC, TFI and so on) but again this gets less certain with later and more capable EEC boxes which had semi-autonomous chips (which are almost a 'sub-CPU' for some) and we don't have any reliable documentation.

With the power of today's CPUs it should be trivial to emulate the code quickly enough, but if only it was that simple (as above). Do we have a full picture of all the external inputs + outputs for all the various sensors/actuators/drivers/motors/whatever ??

So you could say that a Megasquirt may be the best way, but then you are losing all the Ford code and expertise on their own engines... how valuable is that code ?? (I'm just giving this as an example, not leaning either way).

So it's great to discuss new ideas and the best way forwards, but we do have to be hard on those ideas to get the most practical solution, and try to ditch what probably won't work.

[jlowens76]

I asked Craig if he would open source the IP to the community, no was the response.

Needs some to redesign using available parts, ideally compatible with the existing protocols.

Doing exactly that. Check us out @ boostednw.com.

Working on a burner now, already replaced a couple adapters, Emulator next, shooting for working with existing protocols.

[jlowens76]

Holiday Greetings!

I see all the support literature has gone from the site as well!

His response was people can use internet archive to get what they want...

[jsa]

I asked Craig if he would open source the IP to the community, no was the response.

Needs some to redesign using available parts, ideally compatible with the existing protocols.

Doing exactly that. Check us out @ boostednw.com.

Working on a burner now, already replaced a couple adapters, Emulator next, shooting for working with existing protocols.

Cool, I see you have a burn2 replacement on your site.
Are these open or closed source products?

Yes, Internet Archive has support information, though somewhat chaotic to find the right archive date.

[jsa]

With older EECs the in/out interfaces are well sorted (like injectors, ISC, TFI and so on) but again this gets less certain with later and more capable EEC boxes which had semi-autonomous chips (which are almost a 'sub-CPU' for some) and we don't have any reliable documentation.
.
.
With the power of today's CPUs it should be trivial to emulate the code quickly enough, but if only it was that simple (as above).

At the moment emulation of ROM is all that a QH or Tweecer does.
Emulation of the 806x uP code is a messy jump considering the 806x processing offload to DUCE, CART/EBC, EDIS, AICE, DARC, etc.

So you could say that a Megasquirt may be the best way, but then you are losing all the Ford code and expertise on their own engines... how valuable is that code ?? (I'm just giving this as an example, not leaning either way).

MS is messy as well for the majority of use cases. I think they have plug and play versions for a couple applications, beyond that wiring and other hardware changes are required.
Ford VS MS code probably gets down to how well the respective code works for each application.

I think there is merit in keeping Ford hardware/firmware for regulatory compliance and maintenance purposes.

[cgrey8]

...With the power of today's CPUs it should be trivial to emulate the code quickly enough...

That is an interesting idea. I'd had the idea that emulating the processor was the way to go to get disassemblies. But this is interesting and it has me thinking it might actually be easier to write an infrastructure to treat the tune as a "script" that calls subroutines that are modeled after the opcodes.

Right now, I'm struggling with how ROM emulation can be done on a platform like the BBAI64. The latencies to get to DDR are just greater than the time we have to get responses onto the MBus. But if we emulated the uP to literally process the tune on the BBAI64, that would solve that problem. But we'd have to emulate the HSI, HSO, DUCE, AICE, and all those other peripherals too. And without documentation of exactly how they are supposed to operate in all cases, the best we could do is test our assumed behaviors of those peripherals on known tunes that use them and see how close we got.

From the EEC processor's perspective, it wouldn't actually see any of the "tune" the way it would with ROM emulation. The interactions between the processing platform and the EEC processor would be no different than "control mode" as described in the concept document. Doing this might actually help us to code up the logic necessary for control mode to interact with those various peripherals in EECs that have them. This is a ton more work to write a processor emulator, but that might be fun too...

[tvrfan]

Yes to jsa and cgrey.

I hope that the 8065 behaviour is pretty much nailed down, but we don't know what (if any) tweaks were made later. An example is the 'Odd address Word Register" tweak, which seemed to only appear a little later in 8065 code. (This flags to 'use register bank+1'). And even that change wasn't obvious (but those software manuals DID have that covered.) Exactly right, we don't know much detail at all about the add-on 'clever' chips.

It does seem like the earlier the EEC, the easier it will be to sort/modify/emulate/... , which makes sense to me. I also wonder if Megasquirt code would handle newer engines easily, stuff like VVT for example, or if it's better suited for classic (= simpler) stuff.

When I look at my 2010 Toyota (2GR-FE V6) engine bay wiring, there are sensors and actuators everywhere, and I reckon that EEC must have a stack of code algorithms to handle them all. We are a LONG way from carbs and dizzy springs, that's for sure. We are even a long way from old style Efi....

[cgrey8]

How interested would you be in being a contributor for such an effort? Assuming it ever gets legs and grows beyond the idea-phase?

I've purchased a BBAI64 and have been working with it for a few weeks now. Even the purchasing wasn't just a matter of pay your money and its in the mail. I had to submit export control documentation to assert this wasn't intended to be shipped out of the country (only a US thing). No clue why all that was necessary...but if I had to guess, it has something to do with the chip's encryption capabilities.

I'm finding that a lot of documentation on the forums is specific to the older platform and you really have to dig for good info on this platform. It's out there, but you have to ask the questions and get directed to it if you don't just happen to stumble on it. Point is, it's my hope to get to a point where I have a solid working foundation on hardware as well as an example VirtualBox VM with all the debugging code and helper stuff that I've had to painfully learn is needed already present and installed so people interested in helping out can "jump right in" a little faster. They'll have to come up to speed, but they won't have to pave so many potholes with their butt cheeks.

[tvrfan]

I'm happy to help where I can. I know nothing about the BB stuff, but I'm sure documentation is on web.... I see it runs various Linux OSes and others.

I hope I can help with 806x instruction sets and so on. What I learned writing SAD disassembler, etc. I have done quite a bit in my career with lower level assembler and 'C' code linked quite closely with proprietary hardware (and autonomous add-ons). I have written (and debugged) equivalent of 'device drivers' and 'interrupt handlers' on a few different hardware platforms, but it's very rusty (and ancient) by today's standards as I'm now retired ... The code may be old, but the methods don't age nearly as fast, if at all.

From your earlier post - I did write a basic 8061 emulator for DOS/Windows in 'C', which had a 'jump table' where each opcode value called a handler (= subroutine), almost exactly as you describe. So a valid idea. Emulator would run my very early 'AA' bin code, and I think A9L, but the input/output sim was very basic, and I/O timings went weird after a short while. I never finished it, but it proved the concept. It was purely for interest to see what the code was doing, rather than for any emulation device.