Segment Swap utility

[joukoy]

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.

[kur4o]

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.

[joukoy]

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.

Fixed in 0.15.24

[kur4o]

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.

[joukoy]

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.

I dont agree 1 byte off, checked with hex editor and address was correct.
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

[kur4o]

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.

[joukoy]

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.

Please explain.
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

[kur4o]

[21] (21) 02

[21]first byte is column,
(21)second byte is row

[joukoy]

[21] (21) 02

[21]first byte is column,
(21)second byte is row

Ok, will add column search.
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.

[kur4o]

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.