Can anyone tell me how ram writes work over the mbus ?

From what I see there is no combination of st, it & di that would allow writes, is there an extra WE line not shown in the J3 pinouts ?

Regards

Writes on the MBus work much like reads do. The only difference is that the DI (Direction Indicator) control line doesn't change state. The processor maintains control of the bus and clocks while commanding the 8 data/address lines.

The onboard RAM will analyze whether the write was within its mapped area and commit the write if it is or ignore the write if it isn't.

The onboard ROM will always ignore writes. A non-datalogging chip device emulating ROM also ignores writes.

In the case of the TwEECer or the Quarterhorse, writes are processed. The TwEECer only accepts writes in a certain way. I don't recall the exact details but the jist of its support is it only listens to 32 bytes worth of data in a specific location in the memory map. So anything you want to datalog must be relayed to that range, even things that reside in RAM. This requires patch code to tell the EEC to fetch the offsets you want and write them to the locations that the TwEECer will accept writes to. This patch code is an overhead to the processor. How much is debatable, but for years people have sworn that their car acted different/better when they wrote their tune to a chip once they were done tuning with the TwEECer. How much of that is real or imaginary, I couldn't say with any certainty.

The Quarterhorse handles datalogging a little differently. It emulates the entire memory map as though it is RAM. So when the EEC processor makes a write to RAM, it can commit ALL of those writes to its own RAM, in effect maintaining a shadow image of the processor's on-board RAM. When the PC asks the QH for certain offsets, the Quarterhorse doesn't have to actively do anything or require patch code of any type. It just serves up the latest value(s) out of its shadow RAM. So the PC can ask for as much as it wants and it has no effect on the EEC processor. The exception here is that some values we want access to are in internal ram space to the processor and thus writes to those locations in the memory map are never "heard" on the MBus. To get datalogging access to those parameters, we still need patch code to write those values out to arbitrary locations in the memory map that will go out onto the MBus. The good news is the overhead to do this is not even 1/2 of what the TwEECer's overhead is because the values being relayed are already in the EEC processor's internal register space. There's no fetch required. And there's only about 10 values, if that, that need to be relayed. So the amount of data being relayed is less than it is with the TwEECer patch code. It's simply a superior way to handle datalogging as compared to the TwEECer.

BTW in both cases, the patch code required to do the relay of info is inserted into your tune automatically by BinaryEditor. The insertion, as well as figuring out which of your payload items are subject to needing this support is all dealt with by BE behind the scenes so the user never has to think about it. The only time the user is burdened is with the TwEECer where only 32-bytes worth of payload data can be datalogged.

That's way more info that I believe you asked for. But I suspected if you are talking about Control lines on the MBus, these were topics you were probably also curious about.

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

....still trying to decipher what im reading. I feel really stupid and am sorry for the lack of input. lol

_________________
1993 Cobra- bone stock

Thanks cgrey8, that clears things up a bit.

Few more questions,

To get the 2 bytes into the RAM it would go Low byte then High byte, or is it the same as addressing with High byte first then low byte ?

Are the Ram writes addressable through both the SPC and DAR counters ?

Also can we write odd bytes only?

I may have to run some experiments to get the full picture.

You got it. Low Byte 1st because in a Little Endian processor, as Intels are, the lower byte goes in the lower RAM address value. This assumes you are writing using the DAR. I don't know if SPC writes are ever done by the processor since you really don't have control over whether the processor does SPC or DAR writes from the programming level. SPC, as far as I know it, is only instructions (operands and opcodes) and DAR is only fetching data. It's almost Harvard-centric on a VonNeumann architecture. For those non-CS majors out there reading that, Harvard and VonNeumann are computer memory architectures. Google them for more details.

Answered above before I even read this question. But to be explicit, my answer is I don't know. However from all the conversation I've had with Craig about what he's seen via scope, SPC is only used for reads. That doesn't mean it is never writing. It just means if it is, it's not known. It would be nice to know for sure.

Yes and no. Conceptually, you can. But in reality, no. The way the processor does this is when you make a single byte write to an odd address, the processor must fetch the even address before performing the 2-byte DAR write which always starts with the even address. Since it cannot write directly to odd address without 1st writing to the even, it needs the existing value of the even byte so it doesn't tromple it while updating the odd byte of a word.

Good luck. I'd love to see some good scope or logic analyzer feedback to put some clarification on this. It seems the only people that know this stuff are the people that build hardware for the MBus and thus need to know it. It may be documented somewhere, I just haven't found it. I would say look int he 8096 docs, but the 8096 memory architecture is different than the 8061/5, so I don't know that it would apply.

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

Thanks, that is very helpful, If I discover anything extra I will be sure to pass it on.

I have seen a logic capture of the MBus floating around somewhere. In the capture, you can clearly see the writes occurring. The write is the same sequence as loading the DAR register, but with 4 bytes instead of 2. When you strobe over more than 2 bytes without inverting the DI line, it is a RAM write.

Brian
EFI-Unlimited

I've searched here and there, but havn't found it. what is the frequency mbus operates at? what delay between, say, writing high and low address bytes?