[tvrfan]

Some more news, I was really annoyed to discover THIS in a binary, sent from someone who was telling me SAD didn't work correctly on the code, and I discovered why.... This again means possibly a change in the way to analyse, but confirms my old recursive arrangement wouldn't work. This is from the 0GGA binary. This makes me wonder if I'll never catch all the sneaky tricks, and perhaps I will have to do some kind of limited emulation, at least for the stack.....

(No, I'm not annoyed at the sender, it's good to find this stuff, but how the hell am I to deal with this code ???)

Code: Select all

  Sub211:
71b5: cc,18             pop   R18            R18 = pop();

  Sub218:
71b7: ae,19,14          ldzbw R14,[R18++]    R14 = (uns)[R18++];
71ba: b1,01,17          ldb   R17,1          R17 = 1;
71bd: 37,14,14          jnb   B7,R14,71d4    if (B7_R14)  {
71c0: 71,7f,14          an2b  R14,7f         R14 &= 7f;
71c3: ae,19,34          ldzbw R34,[R18++]    R34 = (uns)[R18++];
71c6: 41,07,00,34,1a    an3w  R1a,R34,7      R1a = R34 & 7;
71cb: ad,01,16          ldzbw R16,1          R16 = (uns)1;
71ce: 19,1a,16          shlb  R16,R1a        R16 = R16 << R1a;
71d1: 08,03,34          shrw  R34,3          R34 = R34 / 8; }
71d4: c8,18             push  R18            push(R18);
71d6: b3,15,b8,01,30    ldb   R30,[R14+1b8]  R30 = [R14+1b8];
71db: 44,fe,14,32       ad3w  R32,R14,Rfe    R32 = R14 + Rfe;
71df: b3,33,56,01,32    ldb   R32,[R32+156]  R32 = [R32+156];
.....

This means that the subroutine at 71b5 takes ONE or TWO argiments depending upon whether the first argument is negative, which is a new trick to me, so SAD doesn't handle it. WORSE, there is then THIS

Code: Select all

  Sub219:
745d: f8                clc                  CY = 0;
745e: 20,01             sjmp  7461           goto 7461;

  Sub217:
7460: f9                stc                  CY = 1;
7461: cc,18             pop   R18            R18 = pop();
7463: b2,19,1a          ldb   R1a,[R18++]    R1a = [R18++];
7466: b2,19,1b          ldb   R1b,[R18++]    R1b = [R18++];
7469: b2,19,1c          ldb   R1c,[R18++]    R1c = [R18++];
746c: b2,19,1d          ldb   R1d,[R18++]    R1d = [R18++];
746f: d3,05             jnc   7476           if (CY == 1)  {
7471: c9,b7,71          push  71b7           push(Sub218);
7474: 20,02             sjmp  7478           goto 7478; }
7476: c8,18             push  R18            push(R18);
7478: 91,40,a2          orb   Ra2,40         Ra2 |= 40;
747b: ad,1a,3e          ldzbw R3e,1a         R3e = (uns)1a;
747e: 28,26             scall 74a6           Sub186();
7480: ad,1c,3e          ldzbw R3e,1c         R3e = (uns)1c;
7483: 28,21             scall 74a6           Sub186();
7485: a2,1a,42          ldw   R42,[R1a]      R42 = [R1a];
7488: 8a,1c,42          cmpw  R42,[R1c]      
748b: d1,0b             jleu  7498           if ((uns) R42 > [R1c] )  {
748d: 3e,a2,0b          jb    B6,Ra2,749b    if (B6_Ra2) return;
7490: b0,1e,1a          ldb   R1a,R1e        R1a = R1e;
7493: 91,40,a2          orb   Ra2,40         Ra2 |= 40;
7496: 21,db             sjmp  7673           goto Sub197; }
7498: 71,bf,a2          an2b  Ra2,bf         Ra2 &= bf;
749b: f0                ret                  return;

which means the subroutines here are
745d gets 4 arguments, but jumps to another subroutine to get them (SAD can handle this OK)
7460 gets 5 or 6 arguments depending upon whether the fifth argument is negative or not.
7460 gets the extra 2 arguments by doing a PUSH instead of a CALL, so that the return calls 71b7 at the end of this subr, making it very complex to decipher, and is effectively a 'join together' of the 2 subroutines. This is why I had to change my scanning technique.

Do you spot that jump to sub197 too ? That's yet another wrinkle to sort out ....

AAARGHHHH!!!!

So at the moment I'm very very frustrated with this, and can't seem to make progress. Emulation or not ?? Hmmmm.......

[cgrey8]

I don't see how you've made the progress you have made so far without emulating both internal registers, the stack, and possibly the RAM.

The problem is still to do that, you have to feed in values that will hit every code path or you'll need to keep track of which code paths you've walked so on future passes, you can analyze what it is that is required to hit the "if-conditions" that weren't being hit on the 1st pass(es).

[tvrfan]

I don't see how you've made the progress you have made so far without emulating both internal registers, the stack, and possibly the RAM.

Well, I *have* , so I'll just assume I'm a genius...... (joking!)

SAD tracks all the jumps and calls, and then looks at each 'branch' of the tree produced.
There are a couple of fiddles for vector/subroutine lists etc, but they end up being a subroutine call too.
This way it gets all the paths. That's a much neater/simpler way (I think) than emulating everything.
It does keep track of addresses accessed (for data), instead of emulating all the registers.

BUT - when I see code as above, it makes me realise that this technique isn't flexible enough to handle new ways of stack modificiation and arguments,
and adding extra code for each new case isn't practical in the long run....hmmmmm...... I need to find another method......perhaps flag the subroutines which mod the stack? That's a background idea I've had floating around for a while........off to have an extended think about this.....

As you say, I can't imagine how to emulate all the conditions to get the paths, which is why I didn't go that way.

[cgrey8]

It's going to take a combination of emulation and your way of doing it.

Since you already have a very sophisticated way of identifying what you've got, I'm thinking you start with what you know including the tricks. Then from there, start emulating the parts of the code where the simulator realizes it's gone off the rails...assuming it can eventually figure that out and back up to some point of more confidence. That may be a lot of hand-waving and easier-said-than-done behavior. But it does seem like you can start with what you know, then start emulating from there and "find" the areas where the emulator does something different than what was "assumed" by the tricks and code checks you already have.

If I understood better the challenges you've already gone through to get what you've got and understood how to read assembly better, I would love to help. But for me to jump in at this point would not be helpful, I don't think. For example, I went trying to read the code above, and I didn't get at all what you eventually explained. And even after you explained it, it still took some staring to convince myself what you were saying had relevance to the code. I'm just too much of a modern-day coder that needs variable names, function names, familiar syntax, and code comments.

What's more, some of the tricks you are having to combat makes me wonder was Ford just trying to obfuscate or is there truly performance benefits to their trickery that just happens to have the side-effect of obfuscation. Or was it programming laziness at its worst?

[tvrfan]

Yeah, No worries, as they say here (and in Australia).

I guess I am an 'old school' coder, I started a long time ago. I didn't do a huge amount of assembler, but I did use languages quite close to the underlying hardware, and a lot of 'C'. C is very powerful, but I reckon C power is in its ability to use multiple level pointers, which confuses a lot of coders who are used to "this is me, right here" languages, whereas 'C' excels at "that's me, over there!". A lot of tech guys don't understand more advanced pointer arithmetic, because newer languages don't require them to. It's less error prone, that's for sure !

Yes, I've been thinking about limited emulation for a while, it also may help with identifying the more advanced data structures. I think I'm going to have to apply several methods in sequence, and perhaps go back over sometimes. Ah well, more fun coding to do, at least it keeps my brain sharp (I hope)

I don't think Ford did these things as a deliberate obfuscation - they could have made it a *LOT* harder (I think even I could !). The A9L looks to me as if it was edited at low level after being compiled, with a couple of 'short cuts' but it's just my guess. That 0gga code looks quite well structured, like a compiler output, but unless Ford used a very advanced compiler, I can't see a compiler producing the above shortcut - but it's possible it did. I reckon the compiler may have had a "CODE" option, which most(?) C compilers still do, so that you can easily embed this kind of low level trick inside ordinary code. Not convinced there is much performance improvement, but I guess certainly for the slower CPUs, they may have been forced to short cut to keep up....

Anyway.....onwards and upwards.....

[cgrey8]

Most of what I've been doing is C, but rather high-level C. Occasionally I got to dabble in C# & Java for one-off projects for this or that (mostly writing test programs). And here recently, I've been learning GNU C++ on Linux.

I've been lucky in that I haven't had to deal much at all with assembly. I've seen areas of our code base where there are pragmas for in-line assembly, but that's in the VERY early startup routines where the chip config registers are being done to setup for activating peripherals, and that's code that got written once 15 years ago, and never needed touching again.

[tvrfan]

Yeah, the early stuff I remember was typically the same, assembler packaged into subroutine(s) for low level functions I/O etc, then called from a higher level language. Very common way to do it. Then operating systems took over the hardware interface and hid it....

Compilers and their techniques have improved a lot since early days, and so perhaps what we see in the EEC bins is all compiler produced... I know the UNIX 'C' compilers can do some very clever short cuts, so perhaps the Ford one did too...

I worked on a 16 bit computer series which then got updated with 2 bit address extension, then 4 bit, then 8 bit as memory got bigger, so I don't find the eec BANK hard to understand, just the functional details of 8065 was hazy, but I reckon that's pretty much sorted now.

It all seems so prehistoric today, with Ghz 64 bit CPUs in tiny packages !!

[tvrfan]

After a request from a poster here, and email refusing to let me send an executable through the mail, attached is the latest TEST version of SAD.

It fixes several bugs from the released version, it still has some odd behaviour and is a work in progress. If it helps with your binary then that's good, but no guarantees !! Note that it now prints in hex by default in data structures. so the 'X' option meaning is now swopped over, and means 'print in decimal'

Other than that, directives are the same. It should find more data structures than before, but multibanks still don't work quite right without extra 'scan' commands.

Now looking at a simulation method for the clever code tricks, as explained above, so another probably big change to code...

Windows 32 bit exe, built on win XP...

[File removed, use the one posted below]

Andy.

[ender11]

Hi Andy!
It asks for VCL35.bpl and don't start. I can't find any redistributable with this file. looks like in the past it was static linked in SAD?

[ranga83]

asked the same for me, I just found it online and d/l it and copy/paste into required folder/s. also I know you said it may not work for all but just some feedback. will not work with the early oz falcon eec-v (ef falcon bins) but looks like it works better for the later eec-v (au falcon bins)

[tvrfan]

OH sh*t, I did the wrong kind of software build. Development builds use an embedded library within the tools for debugging purposes.....and so error doesn't show up on your development Windows machine !!

Production built one attached here ......Sorry about that, my screw up.

If you do get a vcl35 from the web, just make sure it's not one with an embedded virus, there were some dodgy ones around.
It is one of the [older] standard Borland C++ libraries. Yes, I'm still using that old tool !! Hey...it still works on Xp and I paid for it so why not ?

Andy.

[cgrey8]

...Yes, I'm still using that old tool !! Hey...it still works on Xp and I paid for it so why not ?...

Because Visual Studio and .NET using VB or C# is far easier to work with (and free).

Unfortunately there's not an easy way to port Borland code over if there's a lot of UI associated with your program. However if the vast majority of your program is logic, that portion should port over fairly easily depending on how sophisticated you got with implementing it. We had a program that was 1/2 baked developed years ago in Borland that was purely for developer testing. When I needed to make some additions to it, I found it unbelievably difficult to work with (knowing nothing about Borland programming). So I rewrote it in C# (and knowing nothing about C# at the time either).

In 2 days, I had something usable. In 4 days, I had almost every bit of functionality the Borland version had plus the functionality I couldn't figure out how to do in Borland. Over the next 2 weeks I used the tool for testing, I continued to refine it to cater to what I was doing. I have to say, I was quite surprised by how easy it is to learn C#.NET with nothing more than Google to guide me through things I couldn't figure out on my own. Granted, I had done some VB (pre .NET) programming in college. And because C# is so similar to VB in syntax, I probably did pick it up much faster.

But if what you have does everything you need it to, there's no reason to switch.

[ender11]

Because Visual Studio and .NET using VB or C# is far easier to work with (and free).

...if you call it "programming". why not call "programming" the development in VB, php or dialing number on the cellphone? scheduling your VCR to record some air is also "programming" in this case :)
and let me talk about faith: I beleive, that there is some special hell for .net developers - compact and simplex. well, that works with "hello world" programs of 2 days. when it's something more complex, more problems are coming up. our accounting used some .net based reporting application. it was impossible to troubleshoot when it blup out error. well, it may be useful thing when you have sources, development environment and something, but otherwise all you can do is spend an extra hour to complete uninstall, the reinstall framework of strictly given version, then it's service pack, then some redistributables like windows scripting host and another useless stuff, then reinstall application, crypto provider and keys... hate that.
in my opinion, it's better not to switch development platform, as it can kill your project. It's even better to keep with the version of GCC you started with.
at last, who cares? let it be Borland.

[cgrey8]

I can't argue with that. If you are proficient in your development environment AND you are happy with it, then switching is a distraction and there's no need for it. I'll even grant you that if you ever have to do something complex that's "off the reservation" of what MS envisioned for development, then you end up fighting the framework or just reinventing the wheel with no assistance at all from the framework. As for useless error messages, I can't blame the framework for that. I blame lousy programming not doing a better job of catching exceptions and reporting them to the user in a more meaningful way. That's not specific to .NET.

But .NET does have shortcomings. This falls back to use the right tool for the right job. In many ways, Java is FAR FAR better than .NET in it's flexibility. But for quick throw-together things for testing or to do generic stuff that isn't highly complex (i.e. NOT distributed computing, NOT heavy database interaction, NOT complex UI interaction), .NET is quite nice. Look at BinaryEditor and EEC Analyzer. So no, I don't believe there is a special hell for .NET developers. I do believe there's a special hell created right here on earth when the wrong tool is chosen for the job they are trying to do. And that hell may not be endured by the developer(s), but by end users.

[ender11]

Look at BinaryEditor

I can't run it: it works only when you set your "local settings" to "english (USA)", and it's not an option for me. it looks like another framework issue, something about microsoft data access components.
for small, easy programs .net is not a good option, as you'll better redistribute a needed framework with your program (when you find out, that .net 4.0 doesn't replace .net 2.0, you start thinking that something is went wrong).
for me, .net is non-existing technology. like, say, Qt, which I tried once, when it was popular.

[cgrey8]

...it works only when you set your "local settings" to "english (USA)"...

Why isn't your computer setup for God's language?

Just kidding. That's probably going to offend a lot of people, but whatever.

Seriously, I have no clue what that's about. MS is world wide. I would think that's not a problem with .NET as much as it is possibly the way BE has been deployed. There's probably something Clint could do to modify BE to work better for other languages, however the what would likely not be easy.

One of the things we have to contend with at work (also selling internationally) is languages. Every single piece of text anywhere in our system that is generic has to be a language ID that corresponds to the correct text in a language pack that contains the correct phrasing. And sometimes the company that does the translation for us get things wrong. I remember about 10 years ago somewhere in our software, there was a reference to a table (similar to tables in EEC tuning). And evidently in French, table translates differently depending on whether you are referring to a grid with numbers or the thing you sit and have dinner. They translated using the dinner table version and the French & French Canadians were not impressed. But being an international company with a fair percentage of our income coming from international sales, we deemed supporting other languages as necessary.

But what he'd have to do to make BE work on other languages simply may not be practical. I don't know. But it does seem like even if he chose not to support other languages that .NET would at least make the software so that English words appeared regardless of the language choice. I do have to admit if it were me, I would've chosen to do BE and EA in Java, not .NET. I certainly wouldn't write it in C or C++...and I'm a C/C++ developer at work. However what I do is embedded Linux development, not desktop development.

[XantheFIN]

...it works only when you set your "local settings" to "english (USA)"...

Why isn't your computer setup for God's language?

Just kidding. That's probably going to offend a lot of people, but whatever.

Oh well.. For me BE opens normally in Win 8 or XP when tryed. This .NET Clean Up Tool is good when there is some error with .NET. Just needs to be installed everything about .NET to work without problems. After that Visual Basic stuff for random reasons.

[tvrfan]

Having read that conversation, the only programming I've ever done for Windows is via Borland C.

I've heard many arguments about the merits of Java vs. .Net vs. C# and stayed away from them. I write in 'C' and or C++ becuase they are familar to me, and I can understand the code (and can deal with multiple levels of pointers without a struggle), that, and various flavours of SQL and UNIX shell scripts and tools.

My experience is on UNIX and its various flavours, and lower level stuff, so I'm one of those geeks that can edit in vi 10 times faster than most Windows tools (because regular expressions really are wonderful if you've got the right kind of twisted brain for them), I can write programs in perl that really work, and shell script, and join command lines together to do massive changes in a few characters, and all the other stuff that Windows pretty much sucks at. I think Perl is wonderful for example. But then I know that Windows is far more popular.

Borland C++ was a cheap deal at the time, and so makes it easy to program on windows without having to learn the Win32 interface. I guess I could load Visual C Personal (or whatever), but I quite like the Borland toolset, even though it is ancient now (like me !!)

Here's one of my programs which I wrote for a friendly contest ....the smallest tic tac toe program in perl, and semi-obfuscated too.
541 chars isn't bad....Yes it IS real, Yes it DOES run, but can you fathom out how ?? (evil grin)

Code: Select all

@g=(7,56,73,84,146,273,292,448,196,385,416);
sub B{for($k=0;$k<9;){print" ",@_[$k]?@_[$k]:"-",++$k%3?' |':"\n".($k<8&&"-"x11)."\n"}}
sub C{B@z;for(@g[0..7]){(@_[0]&$_)-$_||@_[0]&&die"@_[1] WIN\n"}$.>4&&die"DRAW\n"}
sub V{for(@g[0..@_[1]]){$a=(@_[0]^$_)&$_;$m=0;while($a&&~$a&1){$a>>=1;$m++}$a-1||@z[$m]||return$m}9}
sub F{for(4,0,2,6,8,1,5,3,7){@z[$_]||return$_}}
B 1..9;while($v=9){C$c,I;while($v<0||$v>8){print'(1-9)?: ';$v=<>;@z[--$v]&&($v=9)}$p+=1<<$v;
@z[$v]=O;C$p,YOU;$v=V$c,7;$v>8&&($v=V$p,10);$v>8&&($v=F);$c+=1<<$v;@z[$v]=X}

[tvrfan]

Seriously but, I have actually structured SAD to have a separate interface module, so that the 'core' which does the work (in 'C') doesn't care whether it is graphical or text based, and so I aim to have Win and Linux versions with the same core. The core will compile on gcc (or at least did last time I tried it out), so I just need an X windows interface for it.

[cgrey8]

That program above reminds me of arguments I've had with people at work. Back in the 80s and 90s, guys there used to pride themselves on entering obfuscation contests where they would write the most jumbled and unreadable code possible that did something trivial like showed an ASCII art picture of a train and made a Choo Choo sound.

I never understood why they were so proud of themselves for writing "write-only" code that nobody else could read including themselves months later. It was if they patted themselves on the back for being clever enough to outwit others. But that level of cleverness is lost in a multi-developer environment where the value in the developers is not writing code that works, but writing working code that it is understandable by others on the team that will have to read it years later to either debug, restructure, or add features. It's quite annoying to have to figure out "clever" code that isn't documented. I don't read code like that and think to myself, "Wow the person that wrote this was so smart!" I read code like that and am annoyed. The more time I have to spend trying to decipher somebody else's work is time I'm not being productive to the company.

I guess a lot of that tendency did stem from the days when memory was in short supply and every byte had to count. And "pretty" code simply wouldn't fit in memory so tricks had to be played to make every byte count. So the difference between ++i and i++ were relevant to both performance and memory. Today, compilers are sophisticated enough to figure out when they can reorganize the code for better performance and still get the same behavior as was literally coded. And of course, memory in most applications (even tiny embedded processors) is far more than 20 years ago. 1kb processors were not uncommon. I don't think you can find a Cortex M-series processor with less than 32k of RAM and just as much flash built-in.

Anyway, enough of that. Back on topic.

[tvrfan]

I couldn't agree more in terms of project teams - you can't write crap like that in a professional development environment - code and designs have to be open and maintainable, and documented (a weak point for many !!) so that others can continue to maintain it. In older times, yes, we had to keep an eye on code size, but those same rules applied, along with 'always explain any clever tricks with good comments'. The cleverness was in finding the simplest way to do complex logic in small code. Some of the older farts now claim this is a lost art - I'm not convinced it is - coding has just morphed and changed, like everything else.

C++ original intent was to improve large team software development with formal libraries (etc) over C,
I think Java too had similar aim, but different method of acheiving it (?)

The code competitions are really only like anything else - "I'm the best !" being the aim of the game. We stayed friendly and did it for a good laugh and arguments over one (or several) beers about why one was better than the other, probably just like any other argument - why GM engines are better than Ford, or vice versa, why football is better than rugby/baseball/whatever, and so on. I don't think any person I remember working with would argue !!

Just thought I'd fight back in the endless UNIX vs.Windows vs. best coding language debate.

perhaps I should write SAD in perl ?

[ender11]

Why isn't your computer setup for God's language?

well, maybe because I'm communist?
whatever. that error have nothing with system language, it's more about numbers format, decimal point and things.
I just can't look at that annoying USA date/time and numbers format, a pain in eyes :)
it's like the imperial system: I always have to remember, that 1 inch is 25,4mm and do some calculations (on calculator) for numbers to make sense.

[cgrey8]

...well, maybe because I'm communist? whatever...

I was just kidding... I wasn't trying to create a holy war on the forum. If that's what's forming, I'll drop it and apologize for a bad joke.

...it's like the imperial system: I always have to remember, that 1 inch is 25,4mm and do some calculations (on calculator) for numbers to make sense.

I have to agree with you on imperial vs metric. Metric is clearly superior and here we are 40 years later and we still haven't made a clean break from imperial. Engines and electric motors are still rated in HP. Heat is still in BTUs. Pressure in PSI. But the bright side is I have twice the number of wrenches and sockets!!! Oh wait. That's not an upside. Why did we bother converting if we weren't serious?

However I do prefer the decimal to the comma. 1,234.56 just looks better to me. Dates being MM/DD/YYYY vs DD/MM/YYYY I could care less about. But I it is confusing to know if 07/08/2014 is July 8th or August 7th. Every time I travel internationally, I screw my birthdate up on the international customs forms.

[ender11]

I was just kidding... I wasn't trying to create a holy war on the forum. If that's what's forming, I'll drop it and apologize for a bad joke.

you must be kidding: can't beleive you take it seriously :) I've read the book and there is no reference for hell, so you can keep writing in C# :)

[tvrfan]

...it's like the imperial system: I always have to remember, that 1 inch is 25,4mm and do some calculations (on calculator) for numbers to make sense. I have to agree with you on imperial vs metric. Metric is clearly superior and here we are 40 years later and we still haven't made a clean break from imperial. Engines and electric motors are still rated in HP. Heat is still in BTUs. Pressure in PSI. But the bright side is I have twice the number of wrenches and sockets!!! Oh wait. That's not an upside. Why did we bother converting if we weren't serious?

Well I think it *IS* good that there are 2 sets of sockets, sometimes it's just that slightly smaller socket for the knackered bolt head....and some of us have both imperial and metric classic cars.....

And what - you can't convert miles to kms, HP to Kw to joules, ft/lbs to Nm, pounds to kilos, degrees F to C to K, mpg to l/100km, and PSI to hectopascals in your head ??? SHAME on you !! (Yeah, OK, I'll go back to the topic now as well)

[ender11]

well, the only what imperial here is pipe threads. but if you don't do plumping yourself, you can never know what size is 1/2" or 3/8 pipe :) well, metric threads sometimes gives questions, like what is standart pitch for M12 thread? chaos :)
Celsy to K is pretty easy, I've learned is at school, as well as that you can't convert Kw to joules :)

[tvrfan]

Ender11 - sorry, I thought you were in the USA for some reason...my mistake.

Here in New Zealand everything is officially metric, even weather forecasts use hectopascals ! We too do have some imperial stuff for backwards compatible, such as plumbing (as you said) , and you can still buy UNC and UNF bolts for classic cars etc. but have to order some of them, and finding matches for some threads is really tough, as metric fine isn't much different from UNF, for example.

Personally I still think of petrol economy in miles-per-gallon, and engine power in HP, as it's more meaningful to me, but most other things I handle in metric now....with the occasional conversion.....454 grams to the pound and all that.... My TVR speedo is in mph so I have to keep a quick convert list in my head to avoid speeding fines....

[ender11]

we still haven't made a clean break from imperial

Russia entered the metrix in 1917. may be you try 1917 too? :)

[BillMarkViii]

Have you also used the interrupt table and background tables to find function entry points?

Many of those are never entered by 'foreground' code.

[decipha]

how can you multiply an equation in the directive file?

lets say I need x*512

recip is V +0.001953125 but your only allowed 3 decimals

???