Segment Swap utility

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: Segment Swap utility

Post by kur4o »

2 search ranges give tons of combinations so it is not supposed to be ultra fast. It will be nice to be a little faster though.

I am thinking for some pid search that will need to be hardcoded.

Code: Select all

00 01 02 00 [00 04 9E BC]  00 03 01 00 [00 04 9E 82]
00 04 00 00 [00 04 9E 2C]  00 05 00 00 [00 04 9E 1A]
..........................

FC 46 00 00 00 04 4E 84  FC 47 00 00 00 04 4E 7E
FC 48 00 00 00 04 4E 78  FC 4A 02 00 00 04 4E 70

It usually start with this.

SO a search for something like this can be done

00 01 02 00 * * * * 00 03 01 00 * * * *
00 04 00 00 * * * * 00 05 00 00

When the start address is found a list can be generated.

The pid is the first 2 bytes

[00 01] 02 00 [00 04 9E BC] [00 03]

So it is pid number skip 6 bytes pid number > from the previous pid number skip 6 bytes.

The pids are in numerical order so next must be higher than previous until.

The search should be broke until FFFF pid number is reached or next is lower than previous.

For example you reach pid fc12 and next one is 1269. SO the last one should be fc12.

____________

second 2 bytes are the bytes the pid return

0000= 1 byte response
0100= 2 bytes response [word]
0200= 4 bytes response [dword]

Next 4 bytes are the address for the subroutine the value is taken for the pid.

Here is interesting part. You can jump to that address and search for the RAM value that is streamed.

SO the search should look like this jump to pid start address and search area will be till [4e 75][opcode for return] is hit.

The search should be for 10 38 * * for a byte pid and 30 38 * * for word pid. [* *] is the ram address being streamed.

Not all pid should have it but it will be something like that.
User avatar
joukoy
Posts: 392
Joined: Tue Dec 17, 2019 3:27 am
cars: Pontiac Firebird 1978

Re: Segment Swap utility

Post by joukoy »

Version 0.12.4
Found "the" bug from search engine (was parsing again already parsed strings)
"Small" speed improvements/optimization, too :thumbup:

Now starting to look PID searching.
User avatar
joukoy
Posts: 392
Joined: Tue Dec 17, 2019 3:27 am
cars: Pontiac Firebird 1978

Re: Segment Swap utility

Post by joukoy »

kur4o wrote:2 search ranges give tons of combinations so it is not supposed to be ultra fast. It will be nice to be a little faster though.

I am thinking for some pid search that will need to be hardcoded.

Code: Select all

00 01 02 00 [00 04 9E BC]  00 03 01 00 [00 04 9E 82]
00 04 00 00 [00 04 9E 2C]  00 05 00 00 [00 04 9E 1A]
..........................

FC 46 00 00 00 04 4E 84  FC 47 00 00 00 04 4E 7E
FC 48 00 00 00 04 4E 78  FC 4A 02 00 00 04 4E 70

It usually start with this.

SO a search for something like this can be done

00 01 02 00 * * * * 00 03 01 00 * * * *
00 04 00 00 * * * * 00 05 00 00

When the start address is found a list can be generated.

The pid is the first 2 bytes

[00 01] 02 00 [00 04 9E BC] [00 03]

So it is pid number skip 6 bytes pid number > from the previous pid number skip 6 bytes.

The pids are in numerical order so next must be higher than previous until.

The search should be broke until FFFF pid number is reached or next is lower than previous.

For example you reach pid fc12 and next one is 1269. SO the last one should be fc12.

____________

second 2 bytes are the bytes the pid return

0000= 1 byte response
0100= 2 bytes response [word]
0200= 4 bytes response [dword]

Next 4 bytes are the address for the subroutine the value is taken for the pid.

Here is interesting part. You can jump to that address and search for the RAM value that is streamed.

SO the search should look like this jump to pid start address and search area will be till [4e 75][opcode for return] is hit.

The search should be for 10 38 * * for a byte pid and 30 38 * * for word pid. [* *] is the ram address being streamed.

Not all pid should have it but it will be something like that.
Implemented in 0.12.5
File Info -> Get PID list
User avatar
joukoy
Posts: 392
Joined: Tue Dec 17, 2019 3:27 am
cars: Pontiac Firebird 1978

Re: Segment Swap utility

Post by joukoy »

0.12.6
Bug fix to PID search: found (wrong) RAM addresses to PID's which don't have address.
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: Segment Swap utility

Post by kur4o »

It is much better and faster but might still need some work. Again the result differ. It might be because of the hit counter. It also produce different results.

It may be a good debugging idea to turn off hit counter temporarily and to print all searched results and maybe some debug print also for searching. And turn off all kind of filtering for now, until the search engine is reliable enough.

The pid search is great. Almost perfect but at longer subroutines it is not identifying some ram addresses. Can we print the pid number in 4 digit hex instead of decimal.

We can start some pid list with the most known pids with conversion and use it as a lookup to print more details on the pid search results.
I have some partial list that needs some revision.

For v6 the pid search have 2 more bytes added in front of the pid number and it will be skip 8 bytes, but I will need some time to figure the exact search sequence.
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: Segment Swap utility

Post by kur4o »

This can be used as a search sequence for v6 pids

Code: Select all

00 00 02 00 * * * * * * 00 01 02 00 

And here is the decode of the list

Code: Select all

00 00 02 00 00 00 F6 FA 03 00 00 01 02 00 00 00 F7 1A 09 00

00 00 pid number
02 00 bytes response
00 00 F6 FA subroutine
03 00 [??priority??]

00 01 
02 00 
00 00 F7 1A 
09 00
It is almost the same as ls1 pids list with the added 2 extra bytes for ?? priority??.


I tried the variable search and it worked great. It will save a lot of time on some table ident.
User avatar
joukoy
Posts: 392
Joined: Tue Dec 17, 2019 3:27 am
cars: Pontiac Firebird 1978

Re: Segment Swap utility

Post by joukoy »

0.12.7

Added PID search for V6 bins
Now it searches RAM address first with "10 38", if not found then "30 38"
If this is worse than previous, I can switch bak to "10 38" for 1 bytes and "30 38" for 2 bytes.

Search engine optimized more and now it can find quite lot of tables.
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: Segment Swap utility

Post by kur4o »

The variable search somehow got broken and the search result differ again. I think there is a bug since on the search field it shows 38* instead of 38 32 as it is set in the config.

Pid search gives much more results I will explore the empty fields for future improvements.
User avatar
joukoy
Posts: 392
Joined: Tue Dec 17, 2019 3:27 am
cars: Pontiac Firebird 1978

Re: Segment Swap utility

Post by joukoy »

kur4o wrote:The variable search somehow got broken and the search result differ again. I think there is a bug since on the search field it shows 38* instead of 38 32 as it is set in the config.
Should be fixed in 0.12.8
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: Segment Swap utility

Post by kur4o »

Variable search is fixed.

I should have been more specific for the other bug.

On this search string
30 38 * * 0-60 32 38 * * 0-60 74 row:1:int 20 7C @addr:4:HEX 4E B9

You got something like that.
30 38 * * * 38 * * * * 20 7C @addr:4:HEX * * * 4E B9

32 and 74 somehow got replaced with a * on search.

When there is multiple hits can we print all the address of the hits.

For example 00019283;00183645;00012636:data

I am still getting mixed results on 2 identical strings

30 38 val1:2:HEX 0-60 32 38 val2:2:HEX 0-60 74 row:1:int 20 7C @addr:4:HEX 4E B9

and

30 38 * * 0-60 32 38 * * 0-60 74 row:1:int 20 7C @addr:4:HEX 4E B9

I think the program have 2 issues. Handling ** vs val1:2:HEX and the count hits also differs. Maybe we should bracket those so the search algorithm doesn`t get confused.
Post Reply