[jsa]

Posted 4.0.2 with following fixes

1. TEMP - sub command will ignore any extra parameters (symbol name should work)
2. TEMP - removed and ignore bank commands - not normally required anyway

3. Fixed problem with incorrect number of arguments (CARD and others)
4. Fixed problem with listing displaying incorrect number/symbol in indexed opcodes
5. Fixed 'NULL' symbol with word commands
6. Added more code to correctly size arguments. (was missing check when argument used as an address -> should fix CARD issue)
7. Fixed crash when commands overlap or fail - now gives error message instead
8. Fixed Windows path bug. Found when debuggung for the others.... causes processing to stop.

Sony, I didn't get a chance to try this release yesterday.

Also now prints a special func number for lookups - this will be basis of a new command setup (sorry JSA!)

You just know I want to override it with my own naming convention, that includes the address.

The variable argument changes meant BIG changes to subroutines, and honestly I haven't worked out how to allow user commands
along with the variable detect. This obviously needs to be done at some point.

Ok, the sooner the better.

Also I want to change the commands to make sizes simpler. instead of :S Y: Y: (or : SW : SW) layouts, I want your opinion on -

:Z n : where Z is siZe. n = 1 unsigned byte, 2 unsigned word, 3 unsigned long, 5 signed byte, 6 signed word, 7 signed long.
(this is actually what the code uses inside the program.)

I think numbers just obfuscate. Result is just another document to look up.

A convention already exists with names for function look ups and output code. Consistency is good.
mmmm, NO, I don't want to see 16FunLU1 or 3R4c <<=1

I think it is simpler to maintain a consistent convention, who's pattern becomes instantly recognized.

For the sake of change or tracking values;
:UB or :UY
:UW
:UL
:SB or :SY
:SW
:SL
Does that negate the need for Z:

Updated 4.0.2 to fix problem with sym names in multibanks (-> ironman)

Today's release crashes with my dir. I will let you know what I find.

[jsa]

Either of these entries alone in dir will crash today's SAD4.02

Code: Select all

Sub 7773 "Sub7773_UUByteLU"   : E 4 f0 N : W N #: F 1 32 Y U U

or

Code: Select all

Sub 7773 "Sub7773_UUByteLU"

[tvrfan]

jsa,

Firstly - OOPS !! You took a wrong understanding of my intent for the sizes, but it's my fault.
More....

You just know I want to override it with my own naming convention, that includes the address.

Yeah, sorry. I was totally focussed on getting var args to work.

The variable argument changes .....
Ok, the sooner the better.

I basically dropped all the 'per subroutine' analysis, and changed to a 'per arguments' approach, which means multiple commands per subroutine.
Next planned step is to get a split solution, where subroutines can be "fixed args" and have a subroutine attached arg list (just as per 3.08 did),
and the "per argument" for the variable arg subroutines. This means then I can put the command back (do need to work out a flag possibly to manually set "must emulate")

siZes - My Fault. I meant ONLY in the DIRS file. I should have said that. In the list print, it would keep the L,W,B,S,U flags.
I just thought the command options were getting overly large. If I could think of 6 letters which make obvious sense -

y,w,l unsigned and Y,W,L signed ..... no that's too easy to mess up
yeah - I guess pushing the letters together is a worthwhile compromise. I'll update command parser to allow that.

[ internally I did that setup so that (size 'AND' 4) is sign, and (size AND 3) gives 1,2,3 for B,W,L]

Question 1. (and other please comment too)
Are you OK with the default style of <name><num> ?? I think that's about the best way, but happy to consider suggestions.

Question 2.

Special funcs for lookups. (This also triggered the size suggestion)

Internally, I have the special lookup subrs as a number, where -

"UUBFunLU" is 1, "USBFunLU" is 2, "SUBFunLU" is 3, "SSBFunLU" is 4,
"UUWFunLU" is 5, "USWFunLU" is 6, "SUWFunLU" is 7, "SSWFunLU" is 8,

"UTabLU" is 9, "STabLU" is 10. and if ever we see word tables

so we could change the commn from F1 U U to just F1 , but I do see your point about another list to check.

Worthwhile ??

Posts crossed again !! thanks for dir line which breaks it !

[jsa]

Each of these alone will crash

Code: Select all

Sub 776d "Sub776D_SSByteLU"
Sub 7770 "Sub7770_USByteLU"
Sub 7773 "Sub7773_UUByteLU"
Sub 77e0 "Sub77e0_SSWordLU"
Sub 77e3 "Sub77e3_USwordLU"
Sub 77e6 "Sub77e6_UUWordLU"

Sub 78ad "Sub78ad_STabLU"
Sub 78b0 "Sub78b0_UTabLU"

These are OK.

Code: Select all

Sub 7768 "Sub7768_SubyteLU"
Sub 77db "Sub77DB_SUWordLU"

Sub 789e "Sub789e_STabLU<<4"
Sub 78a1 "Sub78a1_UTabLU<<4"

[tvrfan]

Either of these entries alone in dir will crash today's SAD4.02

Code: Select all

Sub 7773 "Sub7773_UUByteLU"   : E 4 f0 N : W N #: F 1 32 Y U U

or

Code: Select all

Sub 7773 "Sub7773_UUByteLU"

Oh Bugger...............that's a STUPID code mistake from me...will fix now.


- - - - DONE - - - -

[jsa]

Next planned step is to get a split solution, where subroutines can be "fixed args" and have a subroutine attached arg list (just as per 3.08 did),
and the "per argument" for the variable arg subroutines. This means then I can put the command back (do need to work out a flag possibly to manually set "must emulate")

What are your thoughts on catering for one argument being used as an offset or base to multiple addresses?

siZes - My Fault. I meant ONLY in the DIRS file. I should have said that. In the list print, it would keep the L,W,B,S,U flags.
I just thought the command options were getting overly large.

Yes they can be lengthy. I prefer a longer consistent SAD wide convention over a slightly shorter obscure numbering system applicable to DIR only.

If I could think of 6 letters which make obvious sense -

y,w,l unsigned and Y,W,L signed ..... no that's too easy to mess up

Probably a little to subtle as well.

yeah - I guess pushing the letters together is a worthwhile compromise. I'll update command parser to allow that.

[ internally I did that setup so that (size 'AND' 4) is sign, and (size AND 3) gives 1,2,3 for B,W,L]

What ever is done should be across all files - msg, dir, lst and cmt.
Either B for Byte across everything or Y.
However B is Bit in lst, so Y for bYte it is. So special function names should become SUY_ not SUB_ etc.

Question 1. (and other please comment too)
Are you OK with the default style of <name><num> ?? I think that's about the best way, but happy to consider suggestions.

Before I go off on a tangent, please give some examples of <name><num> you are referring too?

Question 2.

Special funcs for lookups. (This also triggered the size suggestion)

Internally, I have the special lookup subrs as a number, where -

"UUBFunLU" is 1, "USBFunLU" is 2, "SUBFunLU" is 3, "SSBFunLU" is 4,
"UUWFunLU" is 5, "USWFunLU" is 6, "SUWFunLU" is 7, "SSWFunLU" is 8,

"UTabLU" is 9, "STabLU" is 10. and if ever we see word tables

so we could change the commn from F1 U U to just F1 , but I do see your point about another list to check.

I can see the advantage of keeping it to a number for coding SAD, but I'm against it for msg, dir, lst and cmt.
UUYFnLU works for me or even UUY_FLU or similar.

[tvrfan]

Thanks !

I didn't even spot the SBFunc.. SWFunc..
You are right. I'll change it to SY
Will change the table lookup too. (SYTabLu, UYTabLu) to make it consistent.

I also remember I have T: for biT in dir file..... I'll allow a B as well (and slowly drop the T).

Anything else you spot, let me know.

<name><num>

e.g. sub1, sub2, func1, func2, table1, table2 also if labels are switched on for jumps (not by default) it would be lab1,lab2,
I use exactly the same code to do the 'autonumbered' symbols. Just asking if you prefer something else....

[tvrfan]

Jsa,

did you ask about a data offset back there ??

This can be done anywhere in an argument list or data structure definition with a D <offset> command,
where offset is a hex value. I will check that it works for multibanks.

... when I put the args command back...............

next step is to split the subrs into 'fixed' and 'variable'. (hopefully this will be 4.0.3 unless I get a serious bug !)

[jsa]

I also remember I have T: for biT in dir file..... I'll allow a B as well (and slowly drop the T).

Anything else you spot, let me know.

Yes indeed T: for the biT flag SYM's.

<name><num>

e.g. sub1, sub2, func1, func2, table1, table2 also if labels are switched on for jumps (not by default) it would be lab1,lab2,
I use exactly the same code to do the 'autonumbered' symbols. Just asking if you prefer something else....

For me it is always SubXXXX for the single banks at least. Where XXXX is the hex address of the subroutine start.
Currenty, Sub1, Sub2, etc. changes on each disassembly run as new subroutines are uncovered.
During the discovery phase of disassembly, I could never get a sense of the structure or any memorized recognition of the code flow from one SAD run to the next.
There was no recognition of things like R34=4510 being a Sub. Sub4510 rings a bell, Sub123...nope...noth'n.
Secondly, the address of the Sub is always immediately obvious. I found it far more productive for jumping around the lst following calls and jumps.

Eventually I append a description like; SubXXXX_Eng_Cons

Scalar, Func, Table, initially get to be
S.XXXX, F.XXXX, T.XXXX
Once understood have become;
S.Some_Sw
F.Maf_Transfer
T.Some_Table
or the Ford strategy names for S, F & T.
I dropped the addresses in the names for these as some are quite long, however a lot of the addresses end up adjacent as comments.

So I am always wanting a way to apply the address to names, if it is default output, then I say perfect!

Jsa,

did you ask about a data offset back there ??

This is waht I was referring to back there;
viewtopic.php?f=8&t=22520&start=300#p132678

[jsa]

(hopefully this will be 4.0.3 unless I get a serious bug !)

Sub and Sym names are not being applied

In DIR

Code: Select all

SYM   12 "Tmr"
sub 2032 "Sub2032_InitAll_Rst"  
SUB 2149 "Sub2149_Startup"
sub 5963 "Sub5963_I_HSO_2"

$12, $2149 & $2032 in CMT, being ignored

Code: Select all

2001 |# Jumps to Address 0x2149 $2149
2001 |# Clears byte R2A=0 so that $12 is cleared
2001 |# SCalls Address 0x2032 $2032

4.02 crash fix version LST output.
Names are missing or default is substituted

Code: Select all

# Jumps to Address 0x2149 
# Clears byte R2A=0 so that  is cleared
# SCalls Address 0x2032 Sub1

2010: 63,59               vect  5963             I_HSO_2

[jsa]

Seeing widespread naming gremlins

Consider this in DIR

Code: Select all

rbase f4 c79e
.
.
SYM   62 "Incorrect"                 #W # 
.
.
SYM C800 "Correct"

4.01 applies the name of the offset, when it should be the base+offset result.
Should be R42=Correct
Output in lst.

Code: Select all

2097: a3,f4,62,42         ldw   R42,[Rf4+62]     R42 = Incorrect;

The address is resolved to C8000 but the name is not applied

4.02 crash fix version LST

Code: Select all

2097: a3,f4,62,42         ldw   R42,[Rf4+62]     R42 = [c800];

[tvrfan]

Damn, I'll have look at those - I thought I'd caught all the naming glitches.
(I had to change various things to get emulation to work properly, and address handling in each operand was one, especially for indirect and indexed ops, so that's why.)

I could go <type><address>" instead.........the numbering at the moment is very arbitrary, and agree it DOES change.
e.g. sub1234 (sub12345 for multibanks) func 1234, tab 1234, etc. so change the arbitrary serial numbers to addresses?
I'll look at that. It's certainly more rigourous and repeatable.

changed command parser to allow for no spaces between letters, so UY now works (in fact can do UYN for name check)

Thanks for doing the testing !!

[tvrfan]

Seeing widespread naming gremlins

Consider this in DIR

Code: Select all

rbase f4 c79e
.
.
SYM   62 "Incorrect"                 #W # 
.
.
SYM C800 "Correct"

4.01 applies the name of the offset, when it should be the base+offset result.
Should be R42=Correct
Output in lst.

Code: Select all

2097: a3,f4,62,42         ldw   R42,[Rf4+62]     R42 = Incorrect;

The address is resolved to C8000 but the name is not applied

4.02 crash fix version LST

Code: Select all

2097: a3,f4,62,42         ldw   R42,[Rf4+62]     R42 = [c800];

I can't reproduce this..... I have these lines

Code: Select all

Sub 7773 "Sub7773_UUByteLU"

opts   :C F G N P S 

bank 8   2000   ffff


STR 5442 54F1 :R N: Y O 3 : Y D 260 N: Y O 2 : W P 1: W | R N: Y O 3 : Y D 260 N: Y O 2 : W P 1

vect 54E8 54E9

scan 4510


sub 2032 "Sub2032_InitAll_Rst"  
SUB 2149 "Sub2149_Startup"
sub 5963 "Sub5963_I_HSO_2"


SYM C800 "Correct"

in CARD_dir.txt and it works....both Win and Linux.

It might be a line somewhere else that is messing up the processing ??

[ironmanisanemic]

Updated 4.0.2 to fix problem with sym names in multibanks (-> ironman)

Also taken opportunity whilst fixing to add bank number in indirect [xxxx] or indexed [Rn + xxxx] psuedo code where code is sure that the address is an absolute one. (i.e. greater than 0x2000 and less than 0xffff). Those indexed addresses can be negative offsets, so have to add extra checks.

I think it's right though..............

Still seem to be having the issue with the latest revision.

[jsa]

so change the arbitrary serial numbers to addresses?

Yes

changed command parser to allow for no spaces between letters, so UY now works (in fact can do UYN for name check)

Cool.

Thanks for doing the testing !!

No worries, all for the common good and a bit of self interest.
Thanks for the ongoing improvements to SAD.

I can't reproduce this..... I have these lines

Code: Select all

opts   :C F G N P S 

bank 8   2000   ffff

in CARD_dir.txt and it works....both Win and Linux.

It might be a line somewhere else that is messing up the processing ??

I don't have opts or bank.
Could be something else, I shall try to isolate it.

[jsa]

It might be a line somewhere else that is messing up the processing ??

Yeah, getting varying results. The example above works for me now but other stuff is not.

Most notably, SYM's associated with LU's are hit and miss.
May take some time to nail down.

Code: Select all

SYM 200a "S.ROM_TO-Checksum"

word 200a 200b

Code: Select all

# Read commands from directive file at E:\AllFiles\EEC-IV\Disassembly\SAD\SAD20191218\spare anti oem upr 56k_dir.txt
word 200a 200b

              ^ Command Failed. Overlaps?

[tvrfan]

jsa and ironman -

Yep, probably a tricky bug in command parser - You can always send me your .dir files and I'll try to isolate where it goes wrong.
(email is in my profile - tvrfan99 at gmail ...). I may need the exact sequence to catch those bugs.

Crashes are dead easy with CodeBlocks or Codelite as they have built in debugger which catches it and comes back with the actual code line.
Very cool.

But even then, trickier bugs can sneak through without a crash and can be harder to find.

Thanks again for the free testing....... (self interest is fine, it still helps me too.)

[tvrfan]

It might be a line somewhere else that is messing up the processing ??

Yeah, getting varying results. The example above works for me now but other stuff is not.

Most notably, SYM's associated with LU's are hit and miss.
May take some time to nail down.

Code: Select all

SYM 200a "S.ROM_TO-Checksum"

word 200a 200b

Code: Select all

# Read commands from directive file at E:\AllFiles\EEC-IV\Disassembly\SAD\SAD20191218\spare anti oem upr 56k_dir.txt
word 200a 200b

              ^ Command Failed. Overlaps?

(for debugging -)
please try as a single line -

word 200a 200b "S.ROM_TO-Checksum"

does that work ??

[jsa]

does that work ??

No

That line only in DIR, gives MSG

Code: Select all

# Read commands from directive file at E:\AllFiles\EEC-IV\Disassembly\SAD\SAD20191218\spare anti oem upr 56k_dir.txt
word 200a 200b "S.ROM_TO-Checksum"

               ^ Illegal Option

and LST

Code: Select all

2004: 02,00,ff,df,00,ff,e1,6c ??? 

[jsa]

TVRfan,

Only these 3 entries in DIR

Code: Select all

SYM  A7 "Warg2"                      #Y # Present value
func D44A D457 :S Y V +1 :Y V +16 P +5
SYM  D44A "F.Warg1"

Output in LST

Code: Select all

   STabLU1:
2680: ef,e5,50            call  7768             SUBFunLU1(F.Warg1,a7); 

Typical of many LU's, name for argument 2 is not output to LST.

Do you get the same?

[tvrfan]

I think I've found the 200a bug, and I see that the args commands for funcs (as your example) in the msg file doesn't have the 'N' flag, so SAD won't even look for a symbol name.... at least I know what to look for on this one.

Probably in the resize. Everything arguments starts off as bytes as the code gets the values that way, then if used as a word later (or an address), it gets reset to word. This also was linked to that 5 arg instead of 4 problem.

I reckon there are still some calls where arguments of 2 bytes should really be 1 word, when I get to next phase, your dir 'sub' commands should work again to correct this.

More to check with symbol names too ...

Put addresses in names instead of sequence number as per request, so now says "sub_1234" , "func_1234". "table_12345" style for multibanks
I decide it looked much better with the underscore..

[jsa]

Any reason why the specials can't have the N flag by default?
A missing name has not presented any issue previously, in my experience.

Yes, quite likely 2Y vs 1W errors remain.
Most likely anything related to
viewtopic.php?f=8&t=22520&start=300#p132678

[tvrfan]

Yes.

If you just enable N by default, then some absolute numbers will be interpreted as registers.
e.g. if you have value of 2, it will display as symbol "LSO_PORT".

For this reason, I inhibited auto 'N' for byte values, as they are more likely to be absolutes. So all args start as bytes, and later get converted to word or encoded addresses and at THAT point an 'N' flag should be added. (I found where it's missing by the way).

There isn't an easy answer to this, as early bins actually keep AD raw values in registers, but most of the later ones keep all such 'worthwhile' values in RAM somewhere, and so > 0xff and referred to by WORD.

Similarly for indexed offsets, although mostly they are either rbase offsets (and SAD knows these are to have N flag, or absolutes with small R (lists/arrays of things) so it looks for a name for the absolute address...

But I'm sure there's a few odd cases lurking around, and always have been.

Looking at variable args again, forget the split approach. It's too hard to sort out reliably. I'll stick with KISS, so rules will be
1. If you specify an argument list with the sub, SAD will always use that list. (i.e. SUB 1234 :WN :WN) will ALWAYS be 4 bytes as 2 words
2. If you specify a name, SAD will always use that name and never change it, even if it's a special type/lookup.
3. If you specify a special subr type, SAD will always use that type.

otherwise SAD will emulate for args and select name as required.

I think that covers the requirements in the simplest way.....

[jsa]

Yes.

If you just enable N by default, then some absolute numbers will be interpreted as registers.
e.g. if you have value of 2, it will display as symbol "LSO_PORT".

Sorry I did not mean it in a global sense. Just name flags for arguments to Lookups.
I have not seen a lookup taking an Immediate value, could exist I suppose but I'm not coming up with a practical application of that.

For this reason, I inhibited auto 'N' for byte values, as they are more likely to be absolutes. So all args start as bytes, and later get converted to word or encoded addresses and at THAT point an 'N' flag should be added. (I found where it's missing by the way).

[/quote]
That example above A7, is a word size arg 00A7 for the content of a byte size register.

There isn't an easy answer to this, as early bins actually keep AD raw values in registers, but most of the later ones keep all such 'worthwhile' values in RAM somewhere, and so > 0xff and referred to by WORD.

Ok so early ones have a byte size argument that is an address between 0x13 and 0xEF excluding Rbase.
So if a SYM is defined for an address R13-REF and it is a lookup byte size argument is for a lookup, I am not seeing a downside to applying that.
I think I need to see some code where that does not work to understand why it could not work.

Similarly for indexed offsets, although mostly they are either rbase offsets (and SAD knows these are to have N flag, or absolutes with small R (lists/arrays of things) so it looks for a name for the absolute address...

Certainly anything that is part an immediate address mode operation, can't have auto naming as they are constants sometimes.

Where I have seen plenty of name false positives, is in the Subs that take arguments to derive multiple word size addresses.

Looking at variable args again, forget the split approach. It's too hard to sort out reliably. I'll stick with KISS, so rules will be
1. If you specify an argument list with the sub, SAD will always use that list. (i.e. SUB 1234 :WN :WN) will ALWAYS be 4 bytes as 2 words
2. If you specify a name, SAD will always use that name and never change it, even if it's a special type/lookup.
3. If you specify a special subr type, SAD will always use that type.

1. Sounds right. Sub command with user argument list is always going to be after the first cold start run. SAD will have layed the ground work using your best logic. In a lot of cases an argument list won't be needed.
2. Yep, user names take priority. Again would only exist if SAD has not nailed it on the first run.
3. Ok, user rules.

otherwise SAD will emulate for args and select name as required.

Yes, the norm, unless the user had a reason to change from the initial automatic disassembly.

I think that covers the requirements in the simplest way.....

Yes, I think that conclusion was reached after discussion for an earlier version.

[jsa]

Sub40F8 is an example where 4.02 resolves a word argument when it is 2 byte size. Line 2E34
Those 2 bytes are used to;
* B7 set 1 determine if hysteresis is applied or not
* derive the RAM address of a counter 0x1B4
* derive the ROM addresses of two scalars 0xDD36 0xDD87
* derive the RAM address of a bit flag B0_1E4
* derive the KAM address of a bit flag B0_78A
* derive the KAM address of a value 0x79B

If SAD progressed to the point where that could be resolved automatically then names would be applicable to the addresses in the list, but not to the raw arguments.

Being able to place multiple offsets per argument in a Sub command could allow the end user to instruct SAD.

[jsa]

Sub4456 requires further investigation on my part at least.

Code: Select all

2f0f: ef,44,15            call  4456             Sub69(53c,dc8c);
.
2f19: ef,3a,15            call  4456             Sub69(dc8a,53c);
.
2f2b: ef,28,15            call  4456             Sub69(11a,42,f1);
.
2f54: ef,ff,14            call  4456             Sub69(f144,1a,1);

[jsa]

Sub40DF is all bytes, no words.
Resolves as per Sub40F8

Code: Select all

342c: ef,b0,0c            call  40df             Sub50(180d,e,19,1a0f,1b10,2821);

[tvrfan]

4456 - A quick check shows lzbw, which I suspect is not being interpreted correctly for an argument (for size), making arg a word as the end result is a word....now on my list....

and for the names, here's an A9L example of why it's hard to decide what to do..........

Code: Select all

757b: 80,03               #args  
757d: ef,4f,09            call  7ecf             ChkSensor(Fiept,Veptil,Eptmin,32,34);   # PFE/EVP/ (sonic) voltage below closed limit
7580: 80,03,40,91,34,91,32,34 #args  

That's actually exactly right - the 32 and 34 are error codes, NOT registers.

[jsa]

Ok, CARD has fault codes as args too, but word size. Neither are for lookups.
Ok, you are right, a sym for a lookup could be applied to a non lookup sub arg.
We have sym address ranges though.

A name could be appled to a fault code though. The user's sym would be confined to an address range just as a sym for any other name is now.

I am using sym's confined to an address range in 3.08 and earlier.

The decision to name is part of the sub command.
Where to name is part of the sym command.

For any and all sub commands, special or not, with a N flag;
No sym, then no name is applied, so the native hex value is output to lst.
Sym with an address range has the name output to lst within the range and hex value outside the range.
For sym, without address range, output name to lst for every occurence.

So N and sym continue to work as previous versions.
Once sym address ranges were added I applied N like a default and controlled its application by address range.

N is largely redundant, so it could be dropped from the cmd string.

[tvrfan]

ARRGHH !!!!!

I thought I had the bins pretty well sorted, and then I get an invalid opcode at 0xd006 whilst trying to get the subroutines command to work,
and I run into THIS wonderful liitle bit of code.... (ears.bin)

Code: Select all

 
d414: 06,d0               vect  d006             Sub_d006
d416: 06,c0               vect  c006             Sub_c006
d418: 06,e0               vect  e006
d41a: 09,d0               vect  d009             Sub_d009
d41c: 09,c0               vect  c009             Sub_c009
d41e: 09,e0               vect  e009

   Sub_d420:
d420: fa                  di                     disable ints;
   Sub_d421:
d421: a3,01,00,0d,14      ldw   R14,[R0+d00]     R14 = [d00];
d426: 99,2a,15            cmpb  R15,2a           
d429: d7,3b               jne   d466             if (R15 != 2a) goto d466;
d42b: 3c,24,1e            jb    B4,R24,d44c      if (B4_R24 = 0)  {
d42e: 38,0a,1b            jb    B0,Ra,d44c       if (HSO_OVF = 0)  {
d431: 47,01,0e,20,06,82   ad3w  R82,R6,[R0+200e] R82 = IO_Timer+200e;
d437: d7,02               jne   d43b             if (R82 = 0)  {
d439: 07,82               incw  R82              R82++; }
d43b: a0,82,0e            ldw   Re,R82           HSI_Time = R82;
d43e: b1,0f,0d            ldb   Rd,f             HSO_Cmd = f;
d441: c9,4c,d4            push  d44c             push(@Sub_d44c);
d444: ad,04,30            ldzbw R30,4            wR30 = 4;
d447: cb,31,14,d4         push  [R30+d414]       push([R30+d414]);
d44b: f0                  ret                    return; } }

Kudos to the clever coders who did this for a variable cal console call address, but it messes up my vector list analysis (SAD tries to call those addresses as if they are a subroutine list)

Why did I miss this when it's been there all this time ? I discovered a typo in my pattern matching check (which looks for keywords "Invalid" "Reject" etc), which runs at the end of the batch test of several bins.
Amazing how stuff like this sneaks through and doesn't get spotted - a bug in the test scripts !

I reckon I will need a 'suspect address' list for defined addresses (cal console, additional chips like DUCE etc...) . They might be valid in one bin but not in another.