[cgrey8]

I split this tangent discussion off into its own thread. Here's the original thread where it formed from:
Why auto disassembly is tough

Original Post:

I just can't help but think how you guys struggle with 32-256k worth of memory. As EECs grow in capacity, so does their memory footprint...into the MBs. That's just not what I would expect is worth anybody's time to disassemble and compile into a definition without a LOT of help from a disassembler that can speed up that process.

This is why I keep thinking that a Megasquirt-like project where the EEC is replaced with open source code that is equally as capable, and in some cases, smarter than the stock tunes makes a lot of sense. Some people think that's a pipe dream since the mfgs have far more resources than an open source project does. But they also have far more regulations and constraints that we wouldn't have.

For instance, a LOT of their design work is done from simulations. They simulate hundreds of different engine designs with different cam timings, different compression, different strokes, different intake runner dimensions, etc, etc...until they get something they think is viable. Then they make the real HW. But their simulations are so accurate that they can get it to spit out a lot of the dynamic stuff that used to have to be found on the dyno before such as spark and cam timing. And with today's direct-injection combined with port injection, injection timing maps. So they are starting with a tune that's going to run the engine pretty well then they might tweak it a bit and add some logic to adjust for engine degradation over time. But beyond that, there's nothing else they really care about.

However we could code to take rough inputs like MAF curve, injector size, CID, and with a WB & knock sensor, we could figure out a LOT about what the engine needs as it runs. That's not something the EPA would like to hear, but we aren't as constrained by that during the tuning phase. To me, having code that can be applied to LOTs of different styles makes and models of engines seems a lot easier than disassembling each flavor of EEC each time a new one comes out.

If such a thing could get developed to work, then new code could be bolted on to handle specific features or specific stock sensors or peripherals as they are figured out. This might require some disassembly to understand how some of this stuff works so it can be recoded for. But once it's understood, no more looking at the disassembly for each make/model.

Is that even remotely possible? Or is this, again, a pipedream?

[jsa]

It is possible if enough resources are thrown at the problem.

Rather than develop new hardware, why not just use the newest eec and create new compiling software.

[cgrey8]

Actually, I was thinking the project would begin as a legacy EEC-IV/V J3 port solution and morph from there. These are far simpler EECs that control simpler applications with the J3 device being something like a Beaglebone. The Beaglebone's AM3358 processor has 200MHz Realtime coprocessors on them that are capable of keeping up with J3 port traffic on 24MHz EEC-Vs.Only the real-time stuff would be done at this level. All the logic of what to control and how to do it would be done in the AM3358's 1GHz ARM Cortex A8 processor running Linux and a JRE.

I didn't mean to hijack the thread. It's just the thought occurred to me if disassembly does get easier as the codebase bins get larger and thus all this difficulty in disassembly is limited to bins where the original code was hand-authored assembly to start with where programmers make "clever" programming choices that an automated tool wouldn't likely opt into doing. I realize there's no getting away from disassembly to figure out certain things and to get ideas of how the mfg handled certain tasks. But I'm hoping there's a way to get away from definition development.

[jsa]

Yes an eec-iv or v would do seeing as they are understood.

No getting away from a definition in some form if existing tuning software is leveraged, I think.

[cgrey8]

I'm thinking the Beaglebone could host a webserver that would present a webpage. Java is REALLY good at integrating server applets into Java code directly without the need to go through a formal definition file. And if the concept of Java pluggable modules was embraced, which Java9 makes pretty easy, then each plugin could contribute their own custom contribution to the webpage without the base code knowing anything about it. Now that we are going to Java for our firmware here at the office, I'm learning a HUGE amount about how Java can handle dynamic loading of "new" code on the fly. C never had anything close to this that we got to use. I never did much C++, but the closest thing I'm aware of for C++ is dynamically linkable DLLs (*.so files if you are in Linux). From what I understand C++11 and 14 add a good bit more that I'm not aware of that is similar, but Java just takes things to a whole new level that I wouldn't have even conceived of until I got exposed to it over this past year.

[tvrfan]

Honestly, if i was doing a home made tune today, I would not keep the EEC-IV or V. Even with a plug in module, it's too hard IMHO. I would simply replace it......

I totally agree with several points raised -

I would use a Megasquirt (or similar type) EEC for any project. You can get at all the parameters and tune it yourself, or in fact with an EGO (or two) and knock sensors it can virtually tune itself. By the time you talk money, there isn't that much difference in the end. If you're a geek type, you can even get at the original source code !! Plus (I think this is right) you can reflash the main program if you wish, as well as the calibration.

When you know you can also get adapter boards for all Ford/EEC sensors (and even mix and match others), it's simply a no brainer to me.
The CPUs are fast enough to run all sorts of algorithms on the side and still keep up with the engine. Game over for the 20 (30!!) year old boxes.

Note: I'm not actually doing SAD for my vehicles now (I don't even have a Ford engine any more, not even on the garage floor !).
I'm doing SAD as a brain challenge now, and keep my hand in. I retired more than 5 years ago, and at the speed IT moves I'm already a dinosaur....

Languages -
Personally, I really like 'C' , but I have used it for over 20 years. I would be the first to admit it's old and dangerous and has no memory safety checks or housekeeping like later languages. I don't think C++ comes into its own until large projects - its 'class' handling (the heart of its approach) is really only useful when you are sharing libraries and services across a large project. It would be of no help to write SAD in C++ (IMHO) it would just be a different (and longer) language syntax for the same thing. I might get a little from its auto construct/destruct, but it's no hassle to write 'C' routines to do that (as in SAD).

And I've never used Java for real projects, so can't comment, I tend to think of Java as 'C+++' rightly or wrongly.

[cgrey8]

Well I wouldn't write a home-made EEC-IV/V tune. The plan is that the Beaglebone's processor would simply "feed" the EEC opcodes and operands that would get it to read and write the registers of interest...and that's ALL the EEC's processor would do is marshall data from the I/O and the J3 port. All logic would be done by the BBB's codebase. In fact, it wouldn't be a program at all. It'd simply be a stream of the opcodes and operands needed to perform these tasks when they need to be performed.

Assuming the BBB could be made to work with the EEC-IV/V, it wouldn't be a stretch to use the BBB on other similar EECs like GMs that use chips or to a custom hardware specifically intended to replace stock EECs.

[tvrfan]

You could do that, sure.

For me, to make it as simple as possible, I would still just go with MegaSquirt (or Emerald etc) replacement, and get the right hardware sensor interface bits/options for the engine. KISS principle wins....

I see there's DIY retrofits for stuff like the old mechanical Bosch CIS injection, and TR6 PI and even carb retrofits with 'bulk' type continuous injectors. Great way to get better mileage and/or power.

But then if I decided to buy, say, an old Triumph (saloon or Stag) I would most likely change the engine for something more modern (and unleaded) anyway, so it's whatever you fancy... Those web pics of the Toyota 1UZ-FE V8 in the Stag look very, very, sexy to me.

[motorhead1991]

I can't help but think of Hondata in this case...
From what I understand, the ROM chip is replaced with an interface controller, which also adds features like boost control and flex fuel.

[tvrfan]

I can't help but think of Hondata in this case...
From what I understand, the ROM chip is replaced with an interface controller, which also adds features like boost control and flex fuel.

Er, unless I am misunderstanding, isn't that exactly the same as the various J3 port plug in boards ?
They too replace the OE ROM with a custom ROM.
So you can't add sensors or controllers that way (unless there's already an option wired up in the EEC).

[cgrey8]

What I'm thinking of could do this too and likely do what that Hondata does too, just using different opcodes...same concept.

But to your other point, unlike the J3 port devices of today, what I'm envisioning could allow you to add more I/O than what's on the EEC stock. With a device like a DataQ and/or Innovate connected, the BBB's processor could be tasked to get its inputs from more than just the EEC allowing which would allow it to endow much older vehicles with features those era vehicles simply didn't have the ability to do from the factory.

[motorhead1991]

I can't help but think of Hondata in this case...
From what I understand, the ROM chip is replaced with an interface controller, which also adds features like boost control and flex fuel.

Er, unless I am misunderstanding, isn't that exactly the same as the various J3 port plug in boards ?
They too replace the OE ROM with a custom ROM.
So you can't add sensors or controllers that way (unless there's already an option wired up in the EEC).

I've seen S300s provide a stock civic computer with "boost by gear", so no it's not like the current Ford options.

The early ones were though.

[jsa]

With a device like a DataQ and/or Innovate connected, the BBB's processor could be tasked to get its inputs from more than just the EEC allowing which would allow it to endow much older vehicles with features those era vehicles simply didn't have the ability to do from the factory.

I think the wise choice would be CAN. There's a lot of CAN bus add on hardware out there. Some of it more economical than innovate.

[cgrey8]

...I've seen S300s provide a stock civic computer with "boost by gear", so no it's not like the current Ford options.

The early ones were though.

As long as the EEC has the ability to control the boost (presumably some electronic wastegate control), I don't see why boost-by-gear couldn't be done without additional input. Assuming the computer doesn't know what transmission is installed, the computer could easily "learn" how many gears there are and what gears produce what RPMs for the current MPH. Thus adding special control to limit boost at lower gears and allow higher amounts of boost at higher gears wouldn't be that complicated. The hardest part I can see at this point, would be figuring out the RPM-to-MPH for each gear with a loose torque converter. I believe BE can already deduce what gear the vehicle is in on manuals if you give it the trans and rear gear ratios and your tire diameter. I don't know how well it works on automatics given the potential for TC slop.

...I think the wise choice would be CAN. There's a lot of CAN bus add on hardware out there. Some of it more economical than innovate.

I didn't know that. The TI AM3358 micro has CAN controllers built into it and the BBB has CAN capes to access at least one of them. What I don't know is if there are enough pins available to run the CAN controller while also being a J3 controller; a task that takes up most of the BBB's available GPIO pins. But if the BBB is being used on a J3, you'd just task the EEC's processor to marshall the CAN data over the J3 similar to how the I/O would be managed.

[tvrfan]

I want to add something to this - a view from the hardware/electronics viewpoint -

If you've got access to the ROM ( = program) you can actually repurpose ANY of the inputs and outputs to do something else, within reason.
Each injector output is effectively a PWM driver with a decent current capability - this would also drive a (suitable type) wastegate, idle speed valve,
and many other kinds of valves too (even a fuel pump for variable pressure ?).

The inputs are either digital (interrupts, high and low speed I/O) or analogue (via AtoD input). So you can swop around any of these with the program to match, and it should work just fine. Use interrupts for truly time critical stuff (ignition related stuff mostly), and plain I/O for everything else.

Earlier boxes had fewer inputs and outputs wired, but later boxes had a lot more.

As an example, the FrankenCIS setup uses an old GM HC11 unit repurposed so that one or both of its PWM bank injector outputs are moved to control parts of the mechanical injection system - that's a good example of what I'm talking about. There has to be a huge range of valves and controllers across the various manufacturers, so there is actually a wealth of stuff here for a 'DIY fiddler'

Just my 2C worth....

[jsa]

^ Yes Ford repurposed 6cyl hardware to include boost control on the cossie.

The analog inputs are not straight forward as the circuits different for temps vs hego vs 5v vs maf.

[cgrey8]

...you can actually repurpose ANY of the inputs and outputs to do something else, within reason.
Each injector output is effectively a PWM driver with a decent current capability - this would also drive a (suitable type) wastegate, idle speed valve,
and many other kinds of valves too (even a fuel pump for variable pressure ?).

The inputs are either digital (interrupts, high and low speed I/O) or analogue (via AtoD input). So you can swop around any of these with the program to match, and it should work just fine. Use interrupts for truly time critical stuff (ignition related stuff mostly), and plain I/O for everything else.

Earlier boxes had fewer inputs and outputs wired, but later boxes had a lot more...

That's an awesome point. I hadn't considered it since I was thinking in terms of people reusing whatever EEC they currently had.

But it's completely possible that if you could simply upgrade your EEC to one with LOTS more I/O on it, then you could repurpose I/O that Ford initially intended for completely different purposes. The sucky part would be modifying an old EEC-IV 60 pin wiring harness to a 104 pin harness to work in the newer EEC-Vs. Or perhaps there'd suddenly be a market for 60-to-104 pin adapters that would route your old wiring harness to the likely-candidate pins on the newer EEC and break-out the additional I/O for auxiliary use.

...The analog inputs are not straight forward as the circuit 8s [is?] different for temps vs hego vs 5v vs maf.

That's true. HEGOs come to mind because they are 2.56v instead of 5.12v AND they are inversed such that an A/D bit value of all 0 bits translates to 2.56v, not 0v as most of the A/Ds do.

I wasn't aware that the 5v (e.g. TPS & EVP) and MAF were electrically different, but it doesn't surprise me being the MAF is treated as a high speed input.

And temps are usually thermistors, so again that doesn't surprise me that the circuitry to read them is different.

[tvrfan]

That's true about Analogue inputs, as the sample schematics I've seen often have a resistor network of some type, either to change voltage or to adjust the sensor results. Anything of non-linear response is of course is easy, that's what the 1D function lookup takes care of.... but Yes, a possible gotcha there.

Isn't the EGO at 2.56V because it can go up or down (i.e. 2.56V is a virtual zero volts at centre)? Or have I got that wrong ??

Yes, temp sensors probably need a current limiter, as they can self heat otherwise. Hot wire and flap airflow I don't think will change fast enough for high speed I/O..... er.... I reckon.... (not sure about hot wire)

I didn't know the 4 cyl Cossie YB effectively had a 6 cyl Box for the extra drivers (wastegate etc) but it makes perfect sense - and is also an excellent example within Ford's own manufacture.

and Yes, if you go this way, use an EEC-V with the extra pins (= I/O and extra chips, interrupts, faster and lots of ROM to go at)

[cgrey8]

...Isn't the EGO at 2.56V because it can go up or down (i.e. 2.56V is a virtual zero volts at centre)? Or have I got that wrong ??...

I'm not aware of their ability to go negative. Even if they did, that wouldn't explain why an A/D value of 0 represents 2.56v and the max A/D (12,500 I think) correlates to 0v. If it was a "signed" input, then I'd expect 0v to correlate to an A/D of 6,250 so that the entire range would represent -2.56v to 2.56v. But AFAIK, that's not how they work. I don't have a good explanation at all as to why they are configured they way they are. If they were any other sensor, I would guess they were trying to maximize the sensitivity or accuracy of the A/D counts, but that makes no sense given the EEC logic treats them like a boolean sensor with a fixed switchpoint voltage despite them being an analog input. If somebody has a theory on why they are 1/2 the voltage span AND inversed, I'd be interested in hearing it.

[jsa]

The hego sensor max is around 1V I believe. Sometimes ford multiplexes binary inputs on the hego pin. Clamps the analog channel to 5V when some switch closes.

[cgrey8]

The hego sensor max is around 1V I believe...

That's correct.

Sometimes ford multiplexes binary inputs on the hego pin. Clamps the analog channel to 5V when some switch closes.

It's a minor point but just so I understand, when you say HEGO pin, do you mean EEC pin or processor pin? What's confusing me is that you say they clamp it to 5v however we were talking about how the EEC's circuitry is configured such that HEGO inputs scale their A/D counts 2.56-0v. Assuming the circuitry was tolerant of 5v, I guess if you fed the input 5v, the A/D would output the same count as it would with 2.56v. But is that really what happens or in these cases of multiplexed binary value(s) on analog lines, was the EEC circuitry different between that EEC pin and processor pin or was Ford literally using the same circuit board as other applications using that pin as a HEGO?

[tvrfan]

Ah, I see....

A quick check of Wikipedia reveals that EGOs and HEGOs actually work like batteries, so they GENERATE voltage, and therefore do not require a 5v volt feed like a throttle sensor (which is just a variable resistor).

From wiki -

The zirconium dioxide, or zirconia, lambda sensor is based on a solid-state electrochemical fuel cell called the Nernst cell. Its two electrodes provide an output voltage corresponding to the quantity of oxygen in the exhaust relative to that in the atmosphere.

An output voltage of 0.2 V (200 mV) DC represents a "lean mixture" of fuel and oxygen, where the amount of oxygen entering the cylinder is sufficient to fully oxidize the carbon monoxide (CO), produced in burning the air and fuel, into carbon dioxide (CO2). An output voltage of 0.8 V (800 mV) DC represents a "rich mixture", which is high in unburned fuel and low in remaining oxygen. The ideal setpoint is approximately 0.45 V (450 mV) DC. This is where the quantities of air and fuel are in the optimal ratio, which is ~0.5% lean of the stoichiometric point, such that the exhaust output contains minimal carbon monoxide.

But after that, there's no true voltage information for wideband sensors, or the variations of metals etc. but it does explain how they work.
It does imply that at the wide band sensors DO work more like a variable resistor, (current driven) and 0-5v as they have local circuitry before the AD measurement. If current driven then they will need a resistor network to convert to voltage.

So that might help....

[search for 'Oxygen sensor' ]

[cgrey8]

That's true. HEGOs produce a voltage, usually no higher than about .9ish volts although I guess there's some out there that reach above that??? Mine have only ever hit in the low .8v range when run hard rich and most of the time, not even that high.

As for Wideband O2 (aka lambda) sensors, yes, they are current-based devices which is why the need a controller. Add to that, I don't believe they produce that current the way a HEGO does. The controller has to supply that input current. The controller is also monitoring and managing a sense-line's current as well as translating it to a 0-5v signal that our devices typically want to work with. If you can't envision this, think of a typical house breaker box with 240v AC. Each leg is 120v to neutral. If you load one leg with a 120v 100w lightbulb, then the neutral see's the current of that bulb. However if you added another 100w bulb on the other leg, the current would flow from one leg, through both bulbs, to the other leg. As a result, the neutral's current would be 0 amps (theoretically). The HC and O2 chambers are the bulbs and the neutral line is the sense-line.

In most any exhaust, you'll have both present even if the mix was a stoichiometrically perfect mix going in. At some point during the combustion, unburned oxygen and hydrocarbons will become rare enough that even if they are present, they aren't in close enough contact with each other to react with each other. As a result, you get a small amount of both HC and O2 out the exhaust. The intent of the WB is to have the current produced by the HC electrically flow in the opposite polarity as the current produced by the presence of O2. This way both can be present, but if the mix is stoich, the sense-line current is ~0 mA. It's only when the mix is not stoich that the WB controller's sense-line see's a current flow. The direction indicates rich or lean. The amount represents the lambda proportion.

The interesting thing is this is SUPPOSED to make WBs immune to misfires or lousy-burn conditions. But that's not always the case in practice. Typical conditions are where an abundance of HC is usually paired with a significantly low amount of O2. And under lean-burn conditions, an abundance of O2 is paired with a significantly low amount of HC. So in most cases, the total current just isn't that high. However during a misfire, you will have a HUGE amount of HC and O2 and thus a high corresponding current through those chambers. And under theoretical conditions, despite each chamber producing a high current, they'd still cancel each other out and yield a sense-line current flow that would represent the Air/fuel lamda. But my suspicion is when both chambers are trying to command high current, the internal components (most likely of the controller) can't keep up. The condition may not cause damage, but the demand is enough that the resultant sense-current is not reliable. As I said, I suspect this is NOT a fault of the sensor, but a weakness of cheaper WB controllers that aren't able to sustain the supply current flow the chambers are trying to conduct. This would explain why you might have 2 different WB controllers report wildly different lambda (AFR) during a cold run and do so regardless of what WB sensor you connect to the controller.

During cold engine combustion, my tune commands a fair amount of cold ECT enrichment. But my LC1 doesn't report the lambda as rich as I believe is present for the amount of fuel the injectors are delivering during the first 20-or-so seconds of cold-engine start. I suspect if I had a more expensive WB controller, I'd see different numbers during this period.

[jsa]

It's a minor point but just so I understand, when you say HEGO pin, do you mean EEC pin or processor pin?

This pic should clear up the connections.

Two EEC pins go too one 8061 pin

HEGO and ST.png (76.94 KiB) Viewed 37384 times

What's confusing me is that you say they clamp it to 5v however we were talking about how the EEC's circuitry is configured such that HEGO inputs scale their A/D counts 2.56-0v.

Bench testing of my EEC-IV with a 0-5v input to the pin 48 does not support your inverted volts to ADC logic.

Assuming the circuitry was tolerant of 5v, I guess if you fed the input 5v, the A/D would output the same count as it would with 2.56v. But is that really what happens or in these cases of multiplexed binary value(s) on analog lines,

Analog lines.
0-5.xxxV scales to 0-1023bits from my bench testing

was the EEC circuitry different between that EEC pin and processor pin or was Ford literally using the same circuit board as other applications using that pin as a HEGO?

Having looked at Euro EEC's mostly, it is common for them to be configured like the diagram above. I've not looked at other hardware in detail.

[tvrfan]

Hmmmm..... Digging out my rusty electronics knowledge...

Er......Isn't that the perfect example of how the wide band works?

IC16.1 will adjust the current flow through pin 48 via Q1CA (?) transistor, according to voltage fed in from pin 44, and the CPU/EEC can monitor
that current by voltage drop through R237 (and R99 provides a 'centre' voltage at zero current flow, or open circuit pin 48)
IC16.1 will therefore attempt to keep pin 44 at a constant voltage (which matches wide band description in wiki)....

and the voltage at R237/R99 juction will never rise beyond 1/2 Vcc, = 2.56v. So it's not really duplex connection, but the wide band driver.

Or is that wrong ??? It's only a best guess, so might be wrong....but it matches up nicely.

[jsa]

Pin 44 is from the narrowband HEGO volts.
Pin 48 is the Self Test Input.

That one is a single HEGO box.

The dual HEGO box I have looked at had something else multiplexed on that 2nd HEGO channel as well.

I have bench tested it purely from the standpoint of Volts in on pins to see ADC values in software.

The schematics I have shamelessly pilfered from all over the web are not an exact match for the boxes I have here so I have not taken much interest in how it should work.

Wide band driver you say, now I'm suddenly more interested.

[tvrfan]

Well, so much for THAT idea.....

Unless..... is it possible that the EGO (driver) will never actually reach 2.56V, and so the self test can do a check of - IF equals 2.56V THEN self test, otherwise it's WB input (ie. 0- 2.55) ? Then it would indeed be duplexed.

OOPS I've just spotted - I assumed R99 went to GROUND, not to Vcc....

so rework - assuming EEC pin is input only (i.e. AD input)
transistor has a 1k resistor so minimum voltage is 1.82/1 = 0.55 Vcc plus a bit for forward voltage drop for silicon, 0.6V perhaps less if a FET, say 2.75 + 0.5 = 3.25 volts.

1) if you ground pin 48, EEC will see 2.56V or less , down to 1v (approx) if transistor is conducting.
2) open circuit pin 48 could see range 3v (approx) - 5V, solely depends upon transistor (and therefore pin 44) and what's connected - I am assuming it goes to +Vcc via whatever (WB pump?) and the transistor works as a current drain (it doesn't make sense otherwise)

IC op amp output is normally 1/2Vcc when + and - inputs are the same, so for case 2) pin 48 volts depends upon
pin 44, depending upon what it is connected to.....

So Yes, I think that would work, 2.56V or less is self test, > 2.56v would dictate pin 48 is NOT grounded and therefore could be connected to HEGO
as current drain and driven by pin 44. Yep. works as far as I can tell.

[cgrey8]

Interesting stuff coming from this discussion. But I have something that I need clarified. This is specific to the GUFx era EECs since that's what I have def files for. Both HEGOs have a def file conversion formula as follows:
(5.12-(X/12800))/2

Most 0-5v sensors have a X/12800 conversion formula in the def file which directly results in a display value of 0-5.12v. In the case of the HEGOs, it's X/12800 minus 5.12 which inverts the value from 0-5.12v to 5.12-0v. Then divide all that by 2 which gets it to 2.56-0v. Maybe this is directly related to the input multiplex so the code can detect when the analog sensor is not to be trusted because the binary switch is active???

However now that you mention it, 12,800 for A/D counts is far more resolution than I would expect from these EECs. 0-1024 A/D counts (10-bit inputs) seems far more reasonable. So why is software translating 1024 A/D counts to 12,800? Is there some kind of smoothing or averaging going on that Ford wanted to use to "pretend" the input has better resolution than it actually does? Or is there some other purpose for this?

And is it relates to the HEGOs in the case of GUFx strats, why the inverse?

It is interesting that they've multiplexed a binary value along with an analog with the assumption the neither will be requires simultaneously...at least that's my interpretation of what was said above.

[jsa]

One thing jumped out when I did the bench testing. Purely watching AD counts on the software side, all Analog channels changed in steps of 64bits.

Somewhere in the pipeline 2^10 is being bumped to 2^16.

Any time I have low confidence in my disassembly I always look at known hardware value VS questionable software value. Not much else I can add for GUFB.

[cgrey8]

...One thing jumped out when I did the bench testing. Purely watching AD counts on the software side, all Analog channels changed in steps of 64ADC...

So for whatever reason, the hardware is putting the A/D counts in the upper 10 bits of a 16 bit word as opposed to the lower 10 bits. That's why it would jump by values of 64.

...Any time I have low confidence in my disassembly I always look at known hardware value VS questionable software value...

I fully agree. I just don't have a hardware setup to do that...yet. So for now, I rely on those out there that have to get me useful info like this.