Search This Site

Wizard file Technical Reference

This section describes the actual layout of the My Wizard files, all of this information has been attained by trial and error. I take no responsibility for any misinterpretation, or inaccuracy of this information.


Go to top of page

Standard Code Format

Standard lines of code begin with a 16 bit (2 byte) Word identifier which is the line number of the code, after this 2 byte line number, is a single character which is a length identifier that contains the amount of bytes that this line of code takes up in the file, then there is the code itself.

Identifiers are symbolised by a 16-Bit (2 byte) identifier with the first character usually being a FE (254) character, the table listed below shows these codes and which functions they correspond with (NOTE: This table has been made via creating a program and then examining the WZD file and writing down the code numbers which leaves it prone to errors or exclusions). These codes are actually stored in a data file (BasicSDK.SIN) that comes with the wizard compiler.

However, I couldn't work out how to decompress it so this was the only way to get the identifier codes, I know this is the file because if you rename the file, reload the SDK application then recompile a program, the resulting WZD file contains no 2-byte identifiers.

Variable names, and parameters (including brackets) are inserted as normal text directly into the WZD file, which makes the job of making a decompiler VERY simple. The only part I had to do was to work out which identifiers didn't require brackets, as the ones that don't require brackets must have a space inserted after the identifier when the code is generated where as the ones that do require brackets don't need the space after them.

At the end of each line is a 0D (13, Carriage Return) character which designates that the current line ends, and either a end of program 75 31 (117,  49) or new line identifier (Line Number identifier) proceeds the end of line character.


Go to top of page

Password Protection

It has been raised to me that some people don't want there programs to be decompiled, this is an issue that I have been trying to work out for a while, the problem is, no matter what one does, there is always a way around protection for programs. I have decided to put a password protection item into the next version of the wizard decompiler.

This password protection will allow a password of up to 6 characters which will be required before the wizard decompiler will decompile a certain program. The password will be stored in an encrypted format in the WZD file, I am not going to explain where and how the password will be stored (for obvious reasons), but this is in no way fool proof, any person can compare programs to see where the password is stored and clear it.

Another MAJOR problem is that the older versions of the decompiler will still be able to decompile the programs. If anyone has any ideas that have a bit more stealth please drop me an e-mail.


Go to top of page

Identifier Table

This table lists the identifier with their 16-bit (2 byte) representations.

Byte1 Byte2 Identifier Notes
$FE $21 OPEN
$FE $22 CLOSE
$FE $25 RANDOMIZE
$FE $26 Degree
$FE $27 Radian
$FE $28 GRAD
$FE $29 Beep
$FE $2A WAIT
$FE $2B GOTO
$FE $2E Clear
$FE $2F USING
$FE $30 Dim
$FE $31 CALL Note that his function is not included in the normal version of SharpSDK
$FE $32 POKE Note that his function is not included in the normal version of SharpSDK
$FE $33 GPRINT
$FE $34 PSET
$FE $35 PRESET
$FE $3A Erase
$FE $3C KILL
$FE $50 Cls
$FE $51 LOCATE
$FE $52 TO
$FE $53 STEP
$FE $54 THEN
$FE $55 ON
$FE $56 IF
$FE $57 FOR
$FE $58 LET
$FE $59 REM (comments not available) Actual comments are not included in the wizard file, only this identifier.
$FE $5A END
$FE $5B NEXT
$FE $5C STOP
$FE $5D READ
$FE $5E Data
$FE $60 Print
$FE $61 INPUT
$FE $62 GOSUB
$FE $65 RETURN
$FE $66 RESTORE
$FE $68 GCURSOR
$FE $69 LINE
$FE $6F Circle
$FE $70 PAINT
$FE $71 OUTPUT
$FE $72 APPEND
$FE $73 AS
$FE $76 ELSE
$FE $80 MDF
$FE $81 REC
$FE $82 POL
$FE $86 TEN
$FE $87 RCP
$FE $88 SQU
$FE $89 CUR
$FE $8A HSN
$FE $8B HCS
$FE $8C HTN
$FE $8D AHS
$FE $8E AHC
$FE $8F AHT
$FE $90 FACT
$FE $91 LN
$FE $92 LOG
$FE $93 EXP
$FE $94 SQR
$FE $95 SIN
$FE $96 COS
$FE $97 TAN
$FE $98 INT
$FE $99 ABS
$FE $9A SGN
$FE $9B DEG
$FE $9C DMS
$FE $9D ASN
$FE $9E ACS
$FE $9F ATN
$FE $A0 RND
$FE $A1 AND
$FE $A2 OR
$FE $A3 NOT
$FE $A4 VER / PEEK Actually a PEEK command, pointing at address &H0047,&HBFFA, PEEK commands pointing to this address are converted to VER functions, otherwise they are PEEK commands, note however, that the PEEK command is not included in the normal version of the SharpSDK.
$FE $A5 XOR
$FE $AD POINT
$FE $AE PI
$FE $AF FRE
$FE $B0 EOF
$FE $B2 LOF
$FE $B6 NCR
$FE $B7 NPR
$FE $BF CUB
$FE $D0 ASC
$FE $D1 VAL
$FE $D2 LEN
$FE $D3 GLEN
$FE $E9 INKEY$
$FE $EA MID$
$FE $EB LEFT$
$FE $EC RIGHT$
$FE $F0 CHR$
$FE $F1 STR$
$FE $F2 HEX$
$FE $F3 Date$
$FE $F4 TIME$
$FE $F6 ERROR
$FE $F7 ERN
$FE $F8 ERL
$FE $F9 RESUME


Go to top of page

Icons

The icons are only stored in the WZD files, not in the OBJ files, they start after the <BIN> heading in the WZD file. After the <BIN> header there is a carriage return ($0D - 13) and then a line feed ($0A - 10). After the line feed is a single character length identifier which equates to the amount of characters after this character before the first line of code. The characters between the line feed and the first line of code are the icon. The icon size is 12 x 12 pixels, and is represented by two bytes per line. The last 4 bits of the second byte for each line are ignored. For Example:

1 2 4 8 16 32 64 128 1 2 4 8 Decimal Hex
X X 188,15 FC0F
X X X X X X X X 2,12 020C
X X X X X X X X X 1,10 010A
X X 255,9 FF09
X X X X X X X X 1,13 010D
X X X X 61,13 3D0D
X X X X X X 67,13 450D
X X X X 61,13 3D0D
X X X X X X 67,13 450D
X X X X 61,13 3D0D
X X X X X X X X 1,13 010D
X 255,7 FF07

So the bytes for this icon are:
      FC 0F 02 0C 01 0A FF 09 01 0D 3D 0D 45 0D 3D 0D 45 0D 3D 0D 01 0D FF 07

Therefore, because this is the default icon, if you edit a compiled WZD file and look for these characters they will be in the file after the <BIN> statement, plus three more characters (0E (13 - Carriage Return) 0A (10 - Line Feed) and a single length identifier).


Go to top of page

Memory Bank Spacing Characters

Every 8192 (roughly) characters from the first character after <BIN>{CR}{LF}, there could be a 0E (Character 14, sub linefeed) and then a series of FF (255, null) characters. These characters are padding, and will pad the current bank of 8192 characters so that the next line doesn't get split up across banks of memory (At least that is what I think these characters are for). When the decompiler finds character 0E it simply ignores all FF characters following it and assumes that the next line begins at the first non FF character after the 0E character.