kur4o wrote:If it is a wildchararter it will not work as expected. No need to add it. A workaround could be to read colum or row form search result with some offset added.
For example take column from byte 5 of the found address and so on.
I think it will be better to add some search range.
Absolute range xxxxxx-yyyyyy
Segment range 1,2,7 [search within only segment 1,2 and 7]
empty - search full bin.
Should I remove support for rows (r) too?
Of course it is possible to use r and c for pointing to rows and columns in searchstring and ignore them in searchstring otherwise, but I don't see any reason for this. If you know row & column count, you can add them to TableSeek setting.
Or is there something I dont undestrand?
I did a quick test of the segment range but couldn`t figure how to use it. Any hints will be welcomed.
I put some numbers like 1 - for OS segment and 6 - for engine oper segment, but than it stops finding tables at all, even though I removed the entry.
I suspect some bug too.
kur4o wrote:I did a quick test of the segment range but couldn`t figure how to use it. Any hints will be welcomed.
I put some numbers like 1 - for OS segment and 6 - for engine oper segment, but than it stops finding tables at all, even though I removed the entry.
I suspect some bug too.
Fixed in 0.15.27
Forget to check if range is null, which it can't be, unless value is removed.
I think there is another bug somewhere. I tried to use segment 1 and 99[bootblock] to search old style table address and no matter what I do it didn`t worked.
I removed segment number[didn`t work also], tried to specify range[also not working].
Check it with ls1 table seek too and there also some tables are not found with range and segments not specified.
kur4o wrote:I think there is another bug somewhere. I tried to use segment 1 and 99[bootblock] to search old style table address and no matter what I do it didn`t worked.
I removed segment number[didn`t work also], tried to specify range[also not working].
Check it with ls1 table seek too and there also some tables are not found with range and segments not specified.
Have no clue where to look for the bug.
It's not possible to use c for column, it gets mixed with hex value c
Use k instead (better ideas welcome, but k is now in use)
Did a good testing and no issues so far. Great work.
I am wondering can we add some table address validation, since e38 search relies on not very reliable method and on very rare occasions some false results can be found.
Now it looks on table header which in our case is 21[column] 21[row] 02[identifier].
Problem is that 16bit tables use slightly different header 00 21 00 21 and no identifier. This can lead to false results easily.
A workaround can be a table address validation.
It can work as this. Find table address that starts at for example 00 21 00 21[ no offset added, no wild characters added]. Than store the address to a buffer in 4 byte format. Than use the address for a second search string that can be something like this
[3c 60 @ @ 38 63 @ @] or [* * @ @ * * @ @]
The @ must be exchanged with the address from the buffer and actual string will be [3c 60 00 1f 38 63 34 aa] or [* * 00 1f * * 34 aa] for example. If there is a match than the table address is validated.
Since there is also a chance for $10000 bytes offset it will be good to check for offset address too. For example add 10000 to the table address and run the validation search again, in this eample will be [3c 60 00 20 38 63 34 aa] or [* * 00 20 * * 34 aa]
The validation search string can be defined in a separate column. Using @ @ to specify the address.
If the validation string can`t be found mark the searched table as false and don`t include it the search hit counter. SInce most of the tables relies heavily on hit counter.
On a separate request can we move the description in the seek tab at the last column for nicer look.
