EFIDynoTuning Forum

Just in case !!

If anything in here says/implies "This is DEFINITELY RIGHT!" in my wording then I didn't mean it. All of the explanations here are to the best of my understanding, so if you reckon there's a mistake, please ask. It's always possible I've screwed something up. None of us are perfect.

My IT career showed me a lot about how some people get defensive to "hey, I think this is wrong..." because they think their code/creation/... is "their baby". It just gets in the way. Yeah, you do have to change your attitude when someone says it to you for the first time, but it's always worth double checking.

Carry and overflow.

I think I got carry sorted with respect to previous instructions. It's the same basic idea as conditional jumps = 'which opcode last set the PSW' , but also some bins use the carry flag as a marker (just like setting a bit flag), so SAD should print these as 'if (CY = 0)' style. Signed/unsigned lookups in some bins use the carry flag. Most use a bit in a register.

Overflow - SAD v4 did the same as carry (look for last PSW setter) but I reckon it was often wrong - looking at those wonderful Ford manuals proved that OVF flag doesn't get set as I assumed. So for now, I've gone back to basic 'if (OVF = 1) style' whilst everything else gets fixed, and then I'll go back and check.

wwhite wrote: ↑2024 Jan 13, 15:43 I was working on an emulator for 8061, I had stopped because of exactly that, setting of the PSW.
I'm going to start working on it again.
PSW should be accessible globally in code.

I think what you are saying is SAD only checks previous instruction setting of PSW, but doesn't account for if an instruction doesn't set it, and hence doesn't know what the actual previous PSW was, wherever it was last set, if that makes any sense.

Yes, basically. Conditional jumps jump on the state of the PSW, which may or may not be set by the last instruction. If it isn't obvious where PSW was set from the jump then need something as a backup.....

Emulator -
I wrote an emulator ages ago, but it got horribly complicated, and I gave up. In effect you have to model all the internal 'registers' (PSW included) and all of the special function registers as a separate piece. What I didn't do was to include timing, which a was big mistake... every opcode takes a certain number of 'ticks' and it's different for different address modes, whether a conditional jump is taken or not...and stuff like A/D conversion takes even more ticks, even doing interrupts and so on.

I did most of the SFR stuff , but without any timing, and then I realised that to make an emulator viable, you actually also need some kind of 'engine model' so that the code 'fits' events that would be going on (PIP is most obvious one) with the right times/ticks... and I didn't and still don't have a clue how to do that in any sensible way. I set a fixed RPM (via PIPS coming in) but quickly the emulator set all the ignition timing to ridiculous values and fuel injection likewise....

Proper timing may have fixed this, but there's a LOT of it to do.

But honestly, good luck, I hope you find a way to crack it..

jsa wrote: ↑2024 Jan 13, 08:07

wwhite wrote: ↑2024 Jan 11, 23:10 Well, I have 5.0.5 working the best I can with my dir.

Now I get the following in msg from SAD:

Code: Select all

## sym 2 "CPU_OK" [B 6]               
   ## Error - '[' expected
## sym 4 "AD_Cmd" W [B 0 71]               
   ## Error - '[' expected after '_Cmd" ' 
## sym 5 "WDG_Timer" W [B 0 71]               
   ## Error - '[' expected after 'imer" ' 
   

In light of the math hex/dec issue in my last post, 71, is that hex or dec??

TVRfan what should it be and is it a contributing bug??

There's nothing wrong with first command, can't see why that fails. That's a BUG...
The next two fail because the 'W' is outside the brackets - all options MUST be tied to a data item, and each set of '[ ]' is a new data item. So that's right, cmd needs a '['

You can have nested data items i.e. [W [B0]] but 'bit 0' is still a separate data item from a syntax point of view. One extra 'global' (for that command) is allowed, format is [$ ...], only for some commands (e.g. struct) which is used for layout and other things.

NOTE - there are several bugs reported in the command reader to be found - it seems to report the wrong error a lot, i.e. "Duplicate Command" when it's "invalid address" , and "overlaps" when it's not.

The '71' should be rejected as an invalid bit number, only 0-31 is allowed (a 'long') so again, wrong error reported..

PSWSET and ( 0 >= 0) - why.... [note for both 8061 and 8065...]

When the code does a conditional jump (JLE, JE, JLEU, etc) SAD scans backwards for the instruction which sets the PSW. why?, because some opcodes don't set PSW. Most common are LDW and LDB. So if you see code something like the conditional jump will jump if R98 < 0, NOT Rba... Yes, it's not obvious at first glance. If then you see Then SAD may print 'if (0<=0)' because it cannot find the instruction that set the PSW. I was in the process of providing for an 'answer' from a subroutine to be specified to help fix this, using the '=' in a different way in a global option, as per command

subr 3234 [$ = 34]

and then in the listing it would print and then the jleu would know what to use... but it isn't finished yet. It doesn't have a size for example (yet)

BUT - SAD still needs a PSWSET command even then because, how about this little trick in AA ? The very first thing this subroutine does is a conditional jump, but how the hell to decide where the PSW was last set, as subr can be called from different places.....so there's no way to decide in SAD....

Well, I hope that explains why (0 >= 0) may turn up. If I think of any way to solve this (better) automatically .....

wwhite wrote: ↑2024 Jan 11, 23:24 Ok, fixed it. My dir actually works, still need to verify.

I removed all subroutines, like sub 2131 "Background_Loop" , caused duplicate command
because it is defined as sym 2131 "Sub_2131"

I also removed all symbols that were #Auto Added by SAD.
It appears without them defined in the dir, SAD will auto create on the fly.

Here's my resulting msg file:

Code: Select all

# ----------------------------
# SAD Version 5.0.5 Alpha (11 Jan 2024)
# ----------------------------

# ---------------------------------------------------------------------------------------------
# NB - All commands and errors are printed in new command format
# ---------------------------------------------------------------------------------------------


# Input file is 'C:\Users\wwhite\Programming\SAD\\KID2.bin'

# File is 56K (0xe000) bytes


# Read commands from directive file 'C:\Users\wwhite\Programming\SAD\\KID2_dir.txt'



# ----- Start Disassembly phase 1 -----

# ----- End   Disassembly phase 1 -----

# ----- Start Disassembly phase 2 -----

# ----- End   Disassembly phase 2  -----

# ----- Output Listing to file C:\Users\wwhite\Programming\SAD\\KID2_lst.txt



# ---------------------------------------------------------------------------------------------
# The disassembler has scanned the binary and produced the following equivalent command list.
# This list includes any user commands read in. It can be copied and pasted into a directives file.
# Commented command lines printed for information but may be uncommented (e.g. bank)
# ---------------------------------------------------------------------------------------------

DAMN!!! That's a bug with sym (re)name rules. Anything the user specifies in a DIR file should be KING, but I noticed that it's not being honoured properly from a previous report (jsa?) of 'special' subr names (lookups) being overwritten. That was working in v4, so I've screwed that up somewhere in new code.

jamie - I think I have found the crash in func (and tab) printing - need to do some testing before I am sure .... I need to fix my Virtualbox setup first, as it's still broken. May be a few days...

If I am right, and you want a quick fix -
if you temporarily change the calc command in your funcs from

fun ce22 ce3d "func_ce22_": UW X 10 V 4 : UW X 10 # in=410_n old syntax
to
fun ce22 ce3d "func_ce22_" [ UW = int ( x / 4.0) ] [ UW X 10 ] # new syntax

it will not crash. It looks like a fault in the handling of floating values....so make it into an integer as a temp fix.

NB. explain - old form of 'V 4' , divide by 4, is converted in new syntax to '= float(x/4)' as a calc format

Boosted...

Rbase zero - it's possible v4 allows it when it should not... and v5 catches it , but v5 should report an invalid address... not a duplicate.

System RBASES - SAD auto detects registers which are set to only one value ever (an address), and it then makes them rbases and valid everywhere. The 'master' setup is held at 2020 in 8061 bins, and 82060 (or 12060 in multibanks) 8065. Often there are more setup in other places, but their value is always the same (they point to same address). But in other places a 'temp base' may be used in the code for say a stack of data references only in one subroutine. Typically that will be to set a register to a value (address) and then do a lot of indexed opcodes [Rx + offset]. SAD does not get those, as the register is used for other things in other places. So those rbases are done with user commands, and have a range (i.e. valid only from here to there).

That list also shows the quirk of the way banks work. Anything below 0x400 has no bank (internal to CPU), anything else must have a bank, and SAD adds the default data bank (= 1). Haven't found any bin which has any data bank other than 1 (so far...)

BOOSTEDEVERYTHING wrote: ↑2024 Jan 11, 12:43

Code: Select all

RBA    52 00 0230E 02382                     << Warning - Duplicate Command Ignored

That's a bug as you should not ever be able to set an RBASE register to ZERO !!

Guys, thanks for the reports. I haven't changed any argument code since 5.0.2 so those must have been lurking.

So a list of stuff to sort out for 5.0.6 ...

There are differences in the way Windows and Linux handle crashes, memory, etc. So a coding error can sneak through one OS and not the other. Have had this a few times - string/character handling seems to be a prime suspect so far.

Off topic tech -
I think jsa uses Windows too, I'm probably the only Linux geek ! Linux desktop is still only about 3% of world total. Windows desktop still rules (> 90%), but Linux is king for phones, web servers, server farms, TVs, IOT etc.) Windows 11 demanding new hardware may give Linux a boost though, as Linux will run on anything from a Pentium/Athlon upwards, so you can keep using your older kit (and it's free to download).