MAXConvert Beta v0.5

[Pyriel]

Sorry Vamp, I got a little bored earlier this week and decided to have a go at this.

The program can be found at the following link along with the source:
[edit] New version. See post further down in thread for details:
MAXConvert V0.6

Old version as discussed in this post:
MAXConvert V0.5
[/edit]

This is a fairly early build with a handful of hours sunk into it. It handles most conversions quite well, but there are sure to be bugs. I only added minimal error-checking as I went along and the rest will have to wait until I have more time. If you encounter a bug, I've provided an e-mail address for bug reports in the read me.

What it does: Converts from any known format to any known format, including AR MAX. It cannot do CBv7+ or GSv5 (unless you strip off the extra lines that are prepended to GSv5 codes). Due to the vast difference between the MAX and other devices, very complex codes or obscure MAX code types may not convert exactly as they should. Check the readme in the zip file for what is and isn't handled and what potential errors exist.

As this is open source, feel free to use all or part of the included source in your own programs.

Thanks to Parasyte, Misfired for large portions of the encryption code and to Hellion for helping decipher the MAX commands.

[GMO]

this is great device, easy to use. i like the whole Ar max raw to raw.

[Dark_Killer]

well it sure as hell tops my simple raw to raw converter.

nj pyriel

[Pyriel]

A couple of things to note:

1. Be careful with the combination of the GSv3 input option and either AR MAX output option when the code you're converting contains a line that begins with 'E'. It does work, but I discovered that if you set the input to GSv3 and then enter a raw code of that type, say E003FFFB, the conversion to MAX will crash because in "decrypting" E003FFFB from GSv3 you get an extremely high number in the skip value. The MAX routine has to insert a special line after the last code under the joker/skip, so it blows up going to the last line. That's an error check that was high on my priority list anyway.

2. If you convert a code from AR MAX directly to RAW or another device format, be aware that the number of lines may change for a valid reason. For example, this code:
9ENJ-ZFER-ETMTD
HA6U-5AXQ-6JUPN
8F1M-4WPE-HJFUD

decrypts to this in MAX Raw:
030C990F 79800000
C41001E8 0003FF00
00600330 00004C00

Notice the last line. That's an 8-bit write of 0x00 at address 0x600330. However the fill is set to 0x4C (76) so the next 76 bytes of memory starting at 0x600331 will also have zero written to them. When going to raw (or any device format based on raw) with this code, you'd get an additional 76 lines of 8-bit writes. I have a "condensing" routine on my personal to do list, but it's lower priority than most other things.

[Vampmaster]

If there's any part of the TRANScrypt that you want to use, that's open source too. I've had to leave it alone for a while because I've spent most of my summer away from university working on that and now I really need to find some work before I go back. There are some things I discoverd about commands though. I planned to include the CB2 commands (I don't know if CB7 & CB8 will take the same ones when decrypted).

I discovered that the AR2 also accepts the codebreaker command "pointer write". EDIT: See the non max MGS2 codes at CJs. So those type of codes are convertable (probably on most devices since a lot of them were based on the same one) although it does need an extra line adding when converting from AR2/CB2 to AR MAX. I also had a multi line skip command converter that counts the number of lines untill the next 00000000 40000000 and then makes that the number of lines to skip in the AR2/CB2 code. Apart from the commands that use signed values I've managed to find a way around converting most commands between AR MAX and other devices although sometimes this involves adding or removing extra lines of code.

EDIT 2: Does it accept the DEADFACE 1456E7A5 (encryption off) keycode?
EDIT 9: It does everything I was asking in my last 7 edits,

I was using this code to test how the TRANScrypt dealt with nested multi skips:

KXXZ-0EV0-XHJJZ
R9CP-WZJ8-QTNJH
0FRD-EK98-RA6KD
Y6NZ-N7UD-0U471
387T-Z7H7-F2KAM
E9AV-P1AZ-A9RYX
NFVH-D81R-TZ6EG
63BE-C23Q-4MDE3
CHZ0-4UNQ-10670
RYRF-M6JV-CXTRU
63BE-C23Q-4MDE3
C68Z-7HZM-4QXPV
Q0NZ-B8K7-T2CHQ
55BD-8WHB-DNT53
63BE-C23Q-4MDE3
KFYB-XKJ7-ETX28
5F4G-RRP0-FD2PJ
03AH-5PBC-9K2T7
59WN-FN88-QV66P
03AH-5PBC-9K2T7
DZK5-KNZV-47QYF
8NUV-H6W7-MXJCU
6YA2-UQ99-0A3AF
03AH-5PBC-9K2T7

I tried it on the MAXConvert and the no of lines to skip was off. I think the 1st one should skip 9 lines, the 2nd one should skip 6 and I think the last should skip 2. If I've understood the MAX commands correctly it should ignore the extra 00000000 4000000, but that crashes it. Some of those lines turn into Fs instead of Es.

[superkui]

what is ARmax convert to AR2V2 keycode?

[Vampmaster]

When you're making an AR2 master code you can the line DEADFACE followed by one of these:
Keycode 00000000 makes the AR2 accept raw hex codes
Keycode 05100518 makes the AR2 codes where 1456E7A5 = 00000000
Keycode 02110416 makes the AR2 codes where F8FCFEFE = 00000000
Keycode 04030209 makes the AR2 codes where BCA99B83 = 00000000
Encrypt using the default encryption and use the encryption that goes with the keycode for every other line. A handy thing to put into this new converter would be an option to find deadface lines and replace them with the keycode (it's probably in there already). With the TRANScrypt, I had three sets of seeds (keycodes). I think it would only really need one for remembering what it was decrypting from and one for remember what it was encrypting to.

[Pyriel]

Thanks, Vamp. Is 6 also a pointer write on CB? I've seen CMX use C before but it looks like more of a 16-bit offset write than a pointer write.

This sort of code is exactly why I made this thing available for testing early on:

4A28FAA8 00007EFF
04132EA0 0040F809
0033B170 00000004
0A28FAA8 0000DEFF
04132EA0 0C054D04
02132D10 00000220
8A200000 0000FFFF
02132D28 00000020
02132D80 00000160
8A200000 0000FFFF
04132DA0 00021143
02132DC8 00000160
04132DFC 00021143
8A200000 0000FFFF
021325A8 00000040
0213264C 00000040
00000000 40000000
02132430 00000040
00000000 40000000
02132500 00000040
02132370 000001D8
041082F8 24080020
00000000 40000000

It gets lost in the nested skips. I need to add some logic to maintain counts across recursive calls.

I'll add a description of AR2 Key codes in the readme. I should probably also display the default AR2 key, which is 1853E59E (BCA99B83).

[Vampmaster]

Yep, 6 is pointer write on codebreaker. In fact GMO thought is was only codebreaker. That code isn't supposed to do anything, by the way. I just made it up for testing. One think I wasn't sure about is if it allows nested skips (another thing that held up the transcrypt). I think it only allows them if all the codes in one nest are finished by the same terminator.

See attatched files.

EDIT:

Did you say you couldn't find an AR MAX multi-write? I think it's this:

-------------------------------
// Type "z4" : Fill & Slide //
-------------------------------

2 lines code.

00000000 8XXXXXXX
Y1Y2Y3Y4 Z1Z2Z3Z4


Address = 8XXXXXXX AND 0x81FFFFFF

Size = (address >> 25) AND 0x03

Value = Y1Y2Y3Y4

Address increment = Z3Z4 (signed! : min=-65536, max=+65535, 0x8000 = -65536)


NOTE : When using halfword (or word), make address increment >> 1 (or >> 2) when computing
the code.

Value increment = Z1 (signed! : min=-128, max=+127, 0x80 = -128)

Number of codes to write = Z2 (unsigned! : min=0, max=+255, 0x80 = 127)

There's even more info in Kenobi's guide. I can send you it if you don't already have it.

[Pyriel]

Yeah, I have the format of the two-line, multi-address writes. I just haven't written conversion routines for them yet. The trouble is skips and value increments. 32-bit writes should be fairly easy, they'll just have to be exploded when the value increment is used and the output device doesn't support it. 16- and 8-bit writes will almost always have to be exploded (or un-condensed if you will).

I just finished writing a fill-condensing routine for single-line 8- and 16-bit writes and I'm currently working on changing the way joker codes are handled so that the counts will be correct even if the number of codes under it changes during conversion. It's working for two-skip jokers right now. The fill-condensing routine moved up in priority after somebody sent me an 8-bit write code that had nearly 1,000 bytes of additional fill. The output would far exceed the number of codes that can be handled unless condensed.

This is what you call "a bitch and a half".

Edit: Looks like the 6 command has a slightly different format on the CB.