SOGNA's WIN Format

[JG]

Ok, I finished going through the opcode assembly.  I've managed to map a great deal of the SGS system memory, but theres some variables I don't know the purpose of yet.  And some of the CALL functions hide what the opcode is doing, so I've got to go through these functions now:

Assembly code starting at following memory locations and continuing until the RETN:
411B4D (opcodes 03 and 04 - may perform some kind of viewport reset; 1 = invalidate client area, 0 = revalidate client area?)
412DA0 (opcodes 0E and 0F)
411BF3 (opcode 10)
411C28 (opcode 12)
4126B0 (opcode 27)
412972 (opcode 3B - we know what this opcode does but I need the code to compare against 3C)
4128FA (opcode 3C - I suspect this resets the volume and other system properties stored in registry)
412E4B (opcode 47)
412EB6 (opcode 49)


And also figure out what references the following memory locations:
420580 (this is some kind of system state variable; about a third of the opcodes set it but I haven't discovered its purpose yet)
420550, 42055C, 420564, and 420580 (opcodes 08 and 09)
423434 (opcodes 0A, 0B, 0C, 0D,a nd 18 - the bytes at this location indicate ANM properties)
423435 (opcodes 0A and 18)
420584 (opcodes 0C and 18)
420570 (opcode 15)
420574 (opcode 16)
42345C (opcode 17)
426BB4 (opcode 3E)
42758C (opcode 42)
4204E8 (opcode 43)
42054C (opcodes 45 and 46)



I think I found the debugger you were using (OllyDbg?) so I've managed to disassemble SGS in the same format you used.

[JG]

A couple of more confirmations:

[04][image]
Unload ANM.  Probably rarely used.  Since only 8 ANMs can be loaded at once, it might see more usage in later games (unless they allow more than the 8 ANMs that V6 does)

[0F]
Wait for keyboard or mouse input.  Exact same as 0E.
There is a boolean state flag at 4204AC that is set to 1 by both codes.  It may be that one of these two was intended to set 4204AC to 0 instead (later games might actually use 0F with a corrected flag value of 0)

[3B]
Clears state (as stored in registry keys SystemFlag and SaveSystem), see 3C

[3C]
Save state (as stored in registry keys SystemFlag and SaveSystem)
SystemFlag is a boolean in V6 (0 or 1), but I noticed later games use other bits.
SaveSystem is a copy of the first N register values (for V6 and V8, the first 16; haven't checked later games yet)
This could be used in conjunction with opcode 47 to allow save states controlled by code.



And partially confirmed:

[27][boolean]
Set full screen window mode? As best I can tell argument of 0 would set regular window mode, and value of 1 sets full screen mode.  If one of you guys can actually test this opcode in a custom WIN file, we'll know for sure.  (If not, I'll try it when I get my compiler working; still working on the decompiler now.)

[47][byte]
Resets a large number of flags.  Not sure what the byte value is used for yet.

[JG]

Update: No new work on determining opcode functionality.  I've instead been rewriting my decompiler to produce arrays of operation objects which contain arrays of argument objects which perform all the reading and writing to byte arrays and text.  While this complicates the decompiler I had (which wrote straight out to text) it will greatly simplify the compiler and allow me to collect some stats, such as how often certain opcodes are used, whether they precede certain opcodes or follow them, etc, and allow me to more easily capture key operations (like load_anm and set_anm_properties) to automate accurate animated GIF creation.  I've gotten to the point that my decompiler is back to the same functionality it was before while covering about half the code I need for the compiler (still need to write several text parsing functions to have a working compiler)

Hopefully will get some time to work on it over the Thanksgiving holiday, but will be in North Carolina most of the rest of the week, so don't count on it.

[golden]

I think I found the debugger you were using (OllyDbg?) so I've managed to disassemble SGS in the same format you used.

Yeah, I've been using Olly. I'd really like to help but I've been postponing work on my MSc thesis and I need to do some serious work on it for the following weeks or my mentor will flip out. But I'll be following this thread and when my schedule clears a bit I'll help you out.

[JG]

Totally understand.  I'm glad I had the option of a project instead of a thesis when I did my masters.

[黒い灯影]

Just my luck, the PHP module froze, as I was about to post something, lost most of what i wrote, got distracted by something else online  xD

Anyways, I was dusting off my old research notes,
Working off of RSR's 544.AMN

Code: [Select]

0A00 0000 0000 0180 0100 0103 0103 0103 0103 0103 0103 0103 0103
0A01 0000 0000 0380 000C 0103 0203 0303 0403 0503 0403 0303 0203

0A is the ANMsequence opcode,
byte - layer
word - OffsetX
word - OffsetY
byte - mode? (01  = no transparent,02 = run once,03 = loop w/ transparent,04 - 06 = invisible)
byte - not sure what this is(0x80)
byte - backgroundFlag?  frame01 becomes last image in ANM file, 02-7F crashes, 80-FF doesn't render a frame
byte - Color Palette Transparency Color (from the ANM's color palette) 0C is usually the blue color
then
[byte, byte] pairs until 0x00

[黒い灯影]

also, i dont know what to do with this
I coded my own WIN script reader, just outputs to plain text
and came across this, opcode [11]

This was from V16 I's DAY6B.WIN script.

of course, i could have made a mistake with my programming, but im pretty sure, everything is correct up until this point

[JG]

You've got something wrong in the previous opcode you have starting at 0x0F90.

The frames argument always comes in byte pairs. 15,0 is the first pair. You're incorrectly interpetting that zero as the termination byte, causing the 18,2 and 19,2 frames following it to run the wrong code up to the point of the 17,2 entry. 17 = 0x11.  There is no opcode 0x11 - it's probably something that was needed in PC98 but not in Windows.

I don't know why your addressing scheme is different, but this is the same block code extracted using my tool:

0x1B28: WRITE REGISTER=16 VALUE=40
0x1B2C: LOAD_ANM IMAGE=0 FILE="ANM\Y40"
0x1B36: CLEAR_IMAGE_PROPERTIES BUFFER=1
0x1B38: SET_IMAGE_PROPERTIES IMAGE=0 OFFSET=52 BUFFER=1 LEFT=0 TOP=0
0x1B40: SET_PALETTE_FROM_ANM IMAGE=0
0x1B42: ENABLE_ANIMATION_PAUSE
0x1B43: SET_BUFFER_PROPERTIES BUFFER=0 LEFT=0 TOP=0 FLAGS=0x8000 IMAGE=1 MASK_COLOR=0x00 FRAMES=(1:3, 1:3, 1:3, 1:3, 1:2)
0x1B58: SET_BUFFER_PROPERTIES BUFFER=1 LEFT=0 TOP=0 FLAGS=0x8002 IMAGE=0 MASK_COLOR=0x0C FRAMES=(28:3, 29:3, 30:3, 31:3, 32:2)
0x1B6D: DISABLE_ANIMATION_PAUSE
0x1B6E: FADE_IN_VIEWPORT_GRAYSCALE COLOR=0x00 CYCLES=1
0x1B72: WAIT_FOR_BUFFER_FRAMES BUFFER=0
0x1B74: SET_BUFFER_PROPERTIES BUFFER=1 LEFT=0 TOP=0 FLAGS=0x8003 IMAGE=0 MASK_COLOR=0x0C FRAMES=(15:0, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 16:2, 17:2, 15:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2, 19:2, 18:2)
0x1BE7: PLAY_PCM STREAM=0 FILE="PCM\IM200022"

[黒い灯影]

you're right, i JUST noticed that, just now, the 00 ends that part prematurely in my code
that IS strange that the offsets dont match up.  either my WIN script is messed up but it does match up when i open the scripts in a hex editor