Segment Swap utility
Re: Segment Swap utility
0.15.23
Removed leading zero for single digit values
Added support for # in tableseek, for example: 00 34 45 * * 56 # 21 21 02 * * * * 56 87 98
But need testing with real searchstring + compatible bin.
Removed leading zero for single digit values
Added support for # in tableseek, for example: 00 34 45 * * 56 # 21 21 02 * * * * 56 87 98
But need testing with real searchstring + compatible bin.
Re: Segment Swap utility
I did a quick test but doesn`t seem to work. No debug to help you more.
A search string for any e38 bin will be
# 21 21 02
It will get 7 hits for 7 different tables.
You need to get the found address of each hit, and put it as table address.
Than a more complex string can be tested.
A search string for any e38 bin will be
# 21 21 02
It will get 7 hits for 7 different tables.
You need to get the found address of each hit, and put it as table address.
Than a more complex string can be tested.
Re: Segment Swap utility
Fixed in 0.15.24kur4o wrote:I did a quick test but doesn`t seem to work. No debug to help you more.
A search string for any e38 bin will be
# 21 21 02
It will get 7 hits for 7 different tables.
You need to get the found address of each hit, and put it as table address.
Than a more complex string can be tested.
Re: Segment Swap utility
Find some small bugs.
It looks like the table address is 1 byte off. I guess +1 byte will give the correct address. Or it is some counting bug.
The offset also don`t work with the # search.
And another small bug the xdf export doesn`t apply offset to table address. When you open it in the universal patcher the start address is offset correctly.
The new printout of table editor`s values is really cool. NIce looking digits.
It looks like the table address is 1 byte off. I guess +1 byte will give the correct address. Or it is some counting bug.
The offset also don`t work with the # search.
And another small bug the xdf export doesn`t apply offset to table address. When you open it in the universal patcher the start address is offset correctly.
The new printout of table editor`s values is really cool. NIce looking digits.
Re: Segment Swap utility
I dont agree 1 byte off, checked with hex editor and address was correct.kur4o wrote:Find some small bugs.
It looks like the table address is 1 byte off. I guess +1 byte will give the correct address. Or it is some counting bug.
The offset also don`t work with the # search.
And another small bug the xdf export doesn`t apply offset to table address. When you open it in the universal patcher the start address is offset correctly.
The new printout of table editor`s values is really cool. NIce looking digits.
Edit: search return address of #, so it is 1 byte before first NUMBER of searchstring. Count it as an wildcard in searchstring
Address was saved to memory with offset included, but displayed and exported to xdf without offset.
Fixed in 0.15.25
Re: Segment Swap utility
Great work, now all works as expected. I tried it with more complex strings too.
You might still consider fixing that issue with the wildcharacter. It might bug some specific search. I guess the row bug is also related.
If fixed we can use print only rows in ls1 and can take column and rows from e38.
It will be something like this
# c 21 r 21 02
In e38 third byte do have some meaning 02 equals to signed byte table, 03 to unsigned byte table.
The table seek is now fixed with extra tables added.
You might still consider fixing that issue with the wildcharacter. It might bug some specific search. I guess the row bug is also related.
If fixed we can use print only rows in ls1 and can take column and rows from e38.
It will be something like this
# c 21 r 21 02
In e38 third byte do have some meaning 02 equals to signed byte table, 03 to unsigned byte table.
The table seek is now fixed with extra tables added.
- Attachments
-
- TableSeek-e38.rar
- (1000 Bytes) Downloaded 120 times
Re: Segment Swap utility
Please explain.kur4o wrote:Great work, now all works as expected. I tried it with more complex strings too.
You might still consider fixing that issue with the wildcharacter. It might bug some specific search. I guess the row bug is also related.
If fixed we can use print only rows in ls1 and can take column and rows from e38.
It will be something like this
# c 21 r 21 02
In e38 third byte do have some meaning 02 equals to signed byte table, 03 to unsigned byte table.
The table seek is now fixed with extra tables added.
What byte is for columns, what is for rows? For example searching: 21 21 02
Is it [columns] (rows) ?
Found at address: 1F819F
04 04 04 04 [04] 21 (21) 02 5A 5A 5A 5A 5A
Re: Segment Swap utility
[21] (21) 02
[21]first byte is column,
(21)second byte is row
[21]first byte is column,
(21)second byte is row
Re: Segment Swap utility
Ok, will add column search.kur4o wrote:[21] (21) 02
[21]first byte is column,
(21)second byte is row
But it must act like wildcard. If you already know rows = 21 and cols = 21, you don't need to read that information from binary.
If you don't know, you can't use row/col count for searching, you need wildcard instead.
Re: Segment Swap utility
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.
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.