EFIDynoTuning Forum

If you get blank files, SAD may have crashed 'silently'.
This may sound nuts, but I have noticed over a long time that Windows occasionally doesn't pick up a crash with file related errors.
(in the same category as 'file not found' or "illegal write to file" types). So your program just 'disappears'.
Windows always seems to catch memory violations though (like an illegal pointer to nowhere) and pops up a crash window.
OR it still could be a bug somewhere in SAD which just terminates when it should not.

Yep got that from jsa. Thanks.

a list of issues to fix, and appears I released a DEBUG version, which creates a (large) '<name>_dbg.txt' file. You can delete this safely. It doesn't change listing or message files.

(Damn...I thought v5 was doing well, but several things screwed up that I didn't see)

Ok - fixes coming soon....

--- Oops forgot to update version number and left in some debug stuff. Fixed. If you got it between this and last post, just download again ---

Guys,
just released 5.0.2 which has fixes for problems reported so far.

Drag and drop now works as far as I can tell. Tested in virtual machine (Windows XP) on my Linux PC. It was caused by SAD not handling the file paths correctly ('cos I didn't even think of drag and drop, being a UNIX dinosaur. V4 worked more by good luck than design)
Sometimes SAD crashed as bin file was not found due to messed up file paths.

Several errors were incorrectly reported in _msg file. Fixed & tidied those up.
I added a new check. SAD wasn't checking for too many/too few data items ... which leads me to ...

BOOSTED - some of your lines in the eqe3.dir as posted ARE duplicates, but many of the reported ones were SAD bug. The duplicate generated with SYM .... [W] [Bx] should have returned "too many data items" because a symbol only ever has zero or one set of 'extra definitions' The format should be [W Bx] in a single set of brackets. SAD also mishandled even the correct format if the W appears before the B, causing more confusion. Fixed that.

On to next set of (my) mistakes !

Thanks wwhite - is that from reusing SAD's _msg file , or from your dir ?? If I can't repro this, I may ask to you send me your dir file, if that's OK? (via PM if you prefer)

To all - I'll collect a few bugs and then fix them together.

A GENERAL QUESTION FOR ALL SAD USERS

jsa reported an error with paths - he told me he uses 'drag and drop' quite a lot on windows. I have tested 'open with' too
and it seems to fail the same way. (I would guess they do the same thing under the covers). This is where my UNIX and Linux background shows up, and I don't use these methods, so I didn't think to test them....

Do you guys use these methods or run SAD via SADwin ?? I am asking because the 'drag & drop' and 'open with' methods typically don't have extra options, (like paths) and this would mean adding a rule that my config file (sad.ini) MUST be in the same place as SAD.exe so that their paths are the same. Everything else, all the bins and listing etc could still be in separate places... I don't want to start fiddling with the Win registry and want to keep same code for windows and linux....


Any comments ?? [Thanks in advance]

Hey, nuthin' like enthusiasm !! No worries. I'm waiting for feedback anyway....

OK - quick scan - some of those commands ARE duplicates, but some are not. Quick check is that each symbol command needs to have something different somewhere in the command, and so from what SAD came back with, couple of examples -

SYM 0007 "ATOD_TIMED_CMD" #UY
SYM 0007 "ATOD_TIMED_RESULT" #UY IS a duplicate - correct

SYM 0015 "LSO_EXP_A" :W #UY
SYM 0015 "LSI_EXP_A" #UY IS NOT a duplicate, so SAD got that wrong....a mistake with read and write somewhere to find....

so some work for me to do....................

Thanks for being so quick !!
I normally blame jsa for these kind of faults so you have obviously formed a tag team !! (...joking...)

Seriously - I'll check those out against your commands file. I admit I tend to do less testing on the dirs/commands parsing as main thing for me is to try to get main binary analysis working as correctly as possible. There are still some bugs that I know of, but I decided to release it anyway, otherwise I'll be delaying it forever... looks like a 5.0.2 might be out faster than I thought....

Guys,
have just released latest SAD, version 5.0.1 to github/EEC-IV-disassembler.

Have added a some new features and done a big tidy up. Most likely still some bugs, but I want you guys to play with it and give me feedback.

This version has new syntax with math calculations and multi bit fields are supported. Can also use a field more than once for printing offsets and such. (old syntax still supported, so should still work with existing command files etc.)

Syms have address as as printed, so

SYM 1aa "name" # no bank for registers 0-3ff

The registers are real, just accessed weirdly (as previous post).

Yes that 1f00 (single bank) or 11f00 (multibank) pops up in several bins. I thought it might be a special chip. But then only zero seems to get written so maybe it is a time waster...but its strange....

whilst checking that previous post, I came across this in eqe3, and thought it worth posting
What does 0210c and 210f do ?? R0 and R1 are always zero. So it can't do anything.... What ???

....

....

It's a time waster... something in the hardware will need a defined amount of time to change state, and this is a way to build in a short delay. Looks like it's for HSI (high speed input).. You will also sometimes see a series of NOP (no operations),

while I am here - not sure if this is time waster or something for a specialist chip - does anyone know ??? (URAL bin)