EFIDynoTuning Forum

Been a bit busy with other stuff....and trying to fix args.

Yes, at the moment there is no way to name a VALUE (i.e. a scalar) separately from an ADDRESS (which may be a subroutine or a data structure, etc.) It's also very difficult from the code to tell which is which, and so SAD does handle some printout incorrectly and attaches a symbol name when it should not. A tricky problem to solve. Yes jsa and I have been discussing possible solutions, or workarounds. A symbol with a range kind of works....

Alternate thought -
Here in New Zealand there are some good options for 'ex-lease refurbished' gear, and consumer guarantee act still applies, so you still have a right of return if it goes faulty. Lots of good priced laptops, typically 30-60% less than retail. My laptop is a refurb, now over 5 years old and I haven't had any problems with it. I paid a huge $150 US (equiv.) for it. (yes, it's about time to upgrade....). Maybe you get the odd scratch and wear mark, but so what ??

Don't know if this applies in USA, but thought I would mention it. Good way to save your money and/or get more power for your budget.

Always open to new ideas, and I hope you understand if I ask "why?" it's not because I object, but more info on why you ask may lead to a different and better idea between us all, or may merge into something else. More info is always better !

1. Overlapping fields (word and byte) - do you have an example where this is used ? As far as I know values are not used interchangeably as word and byte (and long) anywhere except when used for scaling purposes (e.g. x/128 or x * 128). Some values are used multiple times and scaled differently, but stay as one base 'size' . If it's for symbol names, I changed the validation after discussions with jsa so that names CAN overlap, and only a true duplicate is rejected. In the latest V5, but args broken.

2. Looped scan - Um, sorry don't know what you are after. Currently a 'scan 01234' should start at 01234 and then do the whole 'tree' of code below it - everything called or jumped to. An example and more info please (even if it's made up) ? Thanks.
If it's linked to the idea that a code loop is emulated to get all the DATA it refers too, this is on my agenda already, but I haven't got that far. Yes, there are lots of 'lists' of things that would then pop up.

Everyone,
I haven't disappeared, still working away to try to solve the various problems on version 5. As the missing arguments picked up by you guys seems to be a design issue (not a bug as such), it's going to take a while to fix, as I need some new ideas. But I'm not giving up.

To confirm, the version I added as 4.0.7 in stable branch is 4.0.7.16 (dated June '21), and I don't think it has any serious bugs left.

So for the best overall disassemble right now, stick with 4.0.7, or 4.0.12 for slightly newer version, but I think it has a few address glitches ?

Andy.

Quick web scan says that those .vbf files may be in something called MIPS assembly code, which (if true) isn't just for Ford stuff. It makes sense that if later EEC boxes are PowerPC or similar, then the CPU and architecture is no longer proprietary to Ford and so other tools and programs may already exist to read and decipher them. I see a couple of tools advertised which will read and write .vbf files to Ford boxes, so probably more things to find, if you want to get into that.

Just for an example, the '80s GM boxes (Yes, sorry..) used a widely available 68HC11 CPU and a standard EPROM chip that was even plugged into a socket and so easily removable, so those boxes got reprogrammed for a wide range of stuff. All you needed were standard off the shelf hardware and software tools to do it. It was like the 'flash' system today, but 40 years ago, and you physically swopped the EPROM chip.
This was standard practice for lots of small computer solutions in offices and businesses in those days.

Always an ongoing IT debate about proprietary or standard/open solutions....

If newer pcms are like everything else, they will be full of tiny little 'blobs' with unreadable codes stamped on them, and the CPU may be a combined chip with other things like RAM already inside. (later EEC-V did this already! ) Time always moves on ....


I guess you just get to see part numbers ... ? (and prices...)

Boosted - SAD is only for 8061 and 8065 CPUs (EEC-IV and V). These CPUs were made only for Ford, and were based on the Motorola 8096 CPU, with extensions added.

Some Euro builds moved to a different CPU at some point in 2000's,and Ford moved on to using IBM's PowerPC in er.. 2005 ish? . Not sure if this has been pensioned off for something new by now. These are totally different CPU hardware and memory layout, so would need to write a brand new disassembler for them.

PowerPC was not made especially for Ford like 806x were, and PowerPC were used in IBM servers and other things, so it's possible tools for PowerPC may work. I don't know for sure. I think there are several different versions of PowerPC too. (not interchangeable ?)

The main board/hardware design of EEC-V limits max memory to 4 x 64K banks = 256K, although 8065 CPU supports 16 banks (= 1 megabyte) and so does SAD. (= a 20 bit address range, 16 + 4 bank select).

Alternate methods/versions -

I already have a SETOPTS command (and matching CLROPTS) to set 'global' options, so it could easily be expanded for alternate disassembly methods as well as the current list. Current options are mostly layout related. This would be neater than having alternate versions hanging around.

So the mechanism to do this is already there. Maybe it's a good idea to keep in mind. I am open to that.
I would still like to get one version as correct as possible though.

Thanks.

On the plus side v5 has its code design split into modules for easier maintenance, and has new user features (some still being developed).
On the negative side, V5 is a step backwards from v4 for disassembly results, but will be improved.

I don't think SAD will ever be perfect, too many styles of code and logic to deal with in the bins.
Some of the data will always be difficult to decode I reckon.
User commands are already too complex, but have to be to actually do the job.

But I can get it closer than it is now ....

efloth - Trouble is that you end up in a catch-22. Been there several times. One idea works for some bins, but not for others, and changing for another way then doesn't work for original bins, and around and around it goes. I reckon there is no way to do it perfectly. Emulate the whole thing (as some previous posts) seems right, but that doesn't work, as you have to ensure all events happen in the right order at the right time, and there's all the error checks/fault codes, and other things/events that probably only happen in a real environment with a real ICE. Way too hard.

In some ways you have a good point - different SAD for different bins, but how do you know which is right for which ?

Maybe one day from someone who knows how to train an AI system with thousands of rules .... but that isn't me....

Released version 5.0.8 with some more fixes.

PROBLEM -
I have found things which mess up my 'elegant' v5 design, and I think it means some of my v5 rewrite won't ever work right... Damn, Damn, Damn!!! (and 'F' words) It may take a while to fix some of these issues. Very frustrating as I thought I had a neat solution, only to find it don't work for some bins. In the meantime v4 works OK, and you can use its output to feed into v5 to add calcs and new features, modify and/or make your own commands to fix the v5 issues.

So I may be quieter for a while...but I am still working on getting SAD to work as well as I can.