AGI/Specifications/Other/AGI256/Implementation Details

In the original PC AGI interpreter v2.936 the engine holds the color and priority/control line information for each pixel in a 160x200 byte buffer. The color data for each pixel is held in the byte's lower 4 bits and the priority/control line data is held in the upper 4 bits.

AGI256 extends this 160x200 byte buffer to a 320x200 byte buffer so that the 256-color data is held in the right 160x200 half of the buffer and the original style 16-color and priority/control line information is held in the left 160x200 half of the buffer.

Used external info

I used Nick Sonneveld's disassemblies of various PC AGI interpreter versions when trying to figure out AGI256. Those IDA databases were highly useful for understanding. Thanks Nick. You can check out the disassemblies if you're interested at the AGI Development Site.

Differences between AGI v2.936 and AGI256

Added files in AGI256:

• AGIGRAF.OVL
• AGIOBJS.OVL

Differences in the following files:

• AGI.EXE
• AGIDATA.OVL

Disassembly of AGIOBJS.OVL

codeseg:9DB0 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
codeseg:9DB0 
codeseg:9DB0 ; AGIOBJS.OVL starts here at 0x9DB0
codeseg:9DB0 ; Attributes: thunk
codeseg:9DB0 
codeseg:9DB0 j_AO_agi256_saveArea proc near          ; CODE XREF: sub_45E+15�p
codeseg:9DB0                                         ; sub_5EDB+E4�p
codeseg:9DB0                 jmp     AO_agi256_saveArea ; savearea(struct Sprite *s) {
codeseg:9DB0 j_AO_agi256_saveArea endp               ;   int srcOffset = screenOffset(s->xPos, s->yPos);
codeseg:9DB0                                         ;   uint8 *src = agi256PicSeg[srcOffset + 160];
codeseg:9DB0                                         ;   for (int y = 0; y < s->ySize; y++)
codeseg:9DB0                                         ;     memcpy(s->buffer + s->xSize * y, src + 320 * y, s->xSize);
codeseg:9DB0                                         ; }
codeseg:9DB3 
codeseg:9DB3 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
codeseg:9DB3 
codeseg:9DB3 ; Attributes: thunk
codeseg:9DB3 
codeseg:9DB3 j_AO_agi256_restoreArea proc near       ; CODE XREF: sub_307+13�p
codeseg:9DB3                                         ; sub_5EDB+121�p
codeseg:9DB3                 jmp     AO_agi256_restoreArea ; restoreArea(struct Sprite *s) {
codeseg:9DB3 j_AO_agi256_restoreArea endp            ;   int destOffset = screenOffset(s->xPos, s->yPos);
codeseg:9DB3                                         ;   uint8 *dest = &agi256PicSeg[destOffset + 160];
codeseg:9DB3                                         ;   for (int y = 0; y < s->ySize; y++)
codeseg:9DB3                                         ;     memcpy(dest + 320 * y, s->buffer + s->xSize * y, s->xSize);
codeseg:9DB3                                         ; }
codeseg:9DB6 
codeseg:9DB6 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
codeseg:9DB6 
codeseg:9DB6 ; Attributes: thunk
codeseg:9DB6 
codeseg:9DB6 j_AO_agi256_blit proc near              ; CODE XREF: sub_45E+1E�p
codeseg:9DB6                                         ; sub_57CF+22�p ...
codeseg:9DB6                 jmp     AO_agi256_blit
codeseg:9DB6 j_AO_agi256_blit endp
codeseg:9DB6 
codeseg:9DB9 
codeseg:9DB9 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
codeseg:9DB9 
codeseg:9DB9 ; savearea(struct Sprite *s) {
codeseg:9DB9 ;   int srcOffset = screenOffset(s->xPos, s->yPos);
codeseg:9DB9 ;   uint8 *src = agi256PicSeg[srcOffset + 160];
codeseg:9DB9 ;   for (int y = 0; y < s->ySize; y++)
codeseg:9DB9 ;     memcpy(s->buffer + s->xSize * y, src + 320 * y, s->xSize);
codeseg:9DB9 ; }
codeseg:9DB9 ; Attributes: bp-based frame
codeseg:9DB9 
codeseg:9DB9 AO_agi256_saveArea proc near            ; CODE XREF: j_AO_agi256_saveArea�j
codeseg:9DB9 
codeseg:9DB9 spritePtr       = word ptr  8
codeseg:9DB9 
codeseg:9DB9                 push    si
codeseg:9DBA                 push    di
codeseg:9DBB                 push    bp
codeseg:9DBC                 mov     bp, sp
codeseg:9DBE                 sub     sp, 2
codeseg:9DC1                 mov     bp, [bp+spritePtr]
codeseg:9DC4                 mov     al, byte ptr [bp+Sprite.yPos] ; At some places only lowest 8 bits are used
codeseg:9DC7                 mov     ah, byte ptr [bp+Sprite.xPos] ; At some places only lowest 8 bits are used
codeseg:9DCA                 call    screenOffset    ; Calculates the screen offset for given coordinate? Video or AGI screen offset?
codeseg:9DCA                                         ; DI = AL * 320 + AH
codeseg:9DCA                                         ; (Destroys BX contents (Returns with BH = 0, BL = AH))
codeseg:9DCA                                         ; 
codeseg:9DCA                                         ; Maybe not named quite correctly?
codeseg:9DCD                 mov     si, di
codeseg:9DCF                 mov     ah, byte ptr [bp+Sprite.ySize] ; At some places only lowest 8 bits are used
codeseg:9DD2                 mov     al, byte ptr [bp+Sprite.xSize] ; At some places only lowest 8 bits are used
codeseg:9DD5                 mov     di, [bp+Sprite.buffer]
codeseg:9DD8                 push    ds
codeseg:9DD9                 mov     ds, agi256PicSeg
codeseg:9DDD                 xor     dx, dx
codeseg:9DDF                 mov     cx, dx
codeseg:9DE1                 jmp     AO_agi256_saveArea_loop_init ; DX = 320 - Sprite.xSize (AL)
codeseg:9DE1 AO_agi256_saveArea endp                 ; SI += 160 (This is done in part 2 of the loop init, actually)
codeseg:9DE1                                         ; This is elsewhere than directly inside AO_agi256_saveArea
codeseg:9DE1                                         ; probably because it didn't fit otherwise. Returns to AO_agi256_saveArea_loop
codeseg:9DE1                                         ; (Although calls AO_agi256_saveArea_loop_init_part2 first)
codeseg:9DE4 ; ---------------------------------------------------------------------------
codeseg:9DE4                 nop
codeseg:9DE5                 nop
codeseg:9DE6 
codeseg:9DE6 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
codeseg:9DE6 
codeseg:9DE6 ; Loop in pseudo C:
codeseg:9DE6 ; for (int y = 0; y < Sprite.ySize; y++) {
codeseg:9DE6 ;   memcpy(ES:DI, DS:SI, Sprite.xSize);
codeseg:9DE6 ;   SI += 320;
codeseg:9DE6 ;   DI += Sprite.xSize;  
codeseg:9DE6 ; }
codeseg:9DE6 
codeseg:9DE6 AO_agi256_saveArea_loop proc near       ; CODE XREF: AO_agi256_saveArea_loop+8�j
codeseg:9DE6                                         ; AO_agi256_saveArea_loop_init_part2+4�j
codeseg:9DE6                 mov     cl, al          ; Move Sprite.xSize bytes per row
codeseg:9DE8                 repe movsb              ; Move the bytes from DS:SI to ES:DI
codeseg:9DEA                 add     si, dx          ; Move to the next row
codeseg:9DEA                                         ; repe movsb added Sprite.xSize to SI
codeseg:9DEA                                         ; add si,dx adds (320 - Sprite.xSize) to SI
codeseg:9DEA                                         ; so the addition is Sprite.xSize + (320 - Sprite.xSize) = 320
codeseg:9DEC                 dec     ah              ; Loop Sprite.ySize times
codeseg:9DEE                 jnz     AO_agi256_saveArea_loop ; Loop in pseudo C:
codeseg:9DEE                                         ; for (int y = 0; y < Sprite.ySize; y++) {
codeseg:9DEE                                         ;   memcpy(ES:DI, DS:SI, Sprite.xSize);
codeseg:9DEE                                         ;   SI += 320;
codeseg:9DEE                                         ;   DI += Sprite.xSize;  
codeseg:9DEE                                         ; }
codeseg:9DF0                 pop     ds
codeseg:9DF1                 add     sp, 2
codeseg:9DF4                 pop     bp
codeseg:9DF5                 pop     di
codeseg:9DF6                 pop     si
codeseg:9DF7                 retn
codeseg:9DF7 AO_agi256_saveArea_loop endp ; sp =  0Ah
codeseg:9DF7 
codeseg:9DF8 
codeseg:9DF8 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
codeseg:9DF8 
codeseg:9DF8 ; restoreArea(struct Sprite *s) {
codeseg:9DF8 ;   int destOffset = screenOffset(s->xPos, s->yPos);
codeseg:9DF8 ;   uint8 *dest = &agi256PicSeg[destOffset + 160];
codeseg:9DF8 ;   for (int y = 0; y < s->ySize; y++)
codeseg:9DF8 ;     memcpy(dest + 320 * y, s->buffer + s->xSize * y, s->xSize);
codeseg:9DF8 ; }
codeseg:9DF8 ; Attributes: bp-based frame
codeseg:9DF8 
codeseg:9DF8 AO_agi256_restoreArea proc near         ; CODE XREF: j_AO_agi256_restoreArea�j
codeseg:9DF8 
codeseg:9DF8 spritePtr       = word ptr  8
codeseg:9DF8 
codeseg:9DF8                 push    si
codeseg:9DF9                 push    di
codeseg:9DFA                 push    bp
codeseg:9DFB                 mov     bp, sp
codeseg:9DFD                 sub     sp, 2
codeseg:9E00                 mov     bp, [bp+spritePtr]
codeseg:9E03                 mov     al, byte ptr [bp+Sprite.yPos] ; At some places only lowest 8 bits are used
codeseg:9E06                 mov     ah, byte ptr [bp+Sprite.xPos] ; At some places only lowest 8 bits are used
codeseg:9E09                 call    screenOffset    ; Calculates the screen offset for given coordinate? Video or AGI screen offset?
codeseg:9E09                                         ; DI = AL * 320 + AH
codeseg:9E09                                         ; (Destroys BX contents (Returns with BH = 0, BL = AH))
codeseg:9E09                                         ; 
codeseg:9E09                                         ; Maybe not named quite correctly?
codeseg:9E0C                 mov     si, [bp+Sprite.buffer]
codeseg:9E0F                 mov     ah, byte ptr [bp+Sprite.ySize] ; At some places only lowest 8 bits are used
codeseg:9E12                 mov     al, byte ptr [bp+Sprite.xSize] ; At some places only lowest 8 bits are used
codeseg:9E15                 push    es
codeseg:9E16                 mov     es, agi256PicSeg
codeseg:9E1A                 xor     dx, dx
codeseg:9E1C                 mov     cx, dx
codeseg:9E1E                 jmp     AO_agi256_restoreArea_loop_init ; DX = 320 - Sprite.xSize (AL)
codeseg:9E1E AO_agi256_restoreArea endp              ; DI += 160
codeseg:9E1E                                         ; This is elsewhere than directly inside AO_agi256_restoreArea
codeseg:9E1E                                         ; probably because it didn't fit otherwise. Returns to AO_agi256_restoreArea_loop
codeseg:9E21 ; ---------------------------------------------------------------------------
codeseg:9E21                 nop
codeseg:9E22                 nop
codeseg:9E23

codeseg:9E23 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
codeseg:9E23 
codeseg:9E23 ; Loop in pseudo C:
codeseg:9E23 ; for (int y = 0; y < Sprite.ySize; y++) {
codeseg:9E23 ;   memcpy(ES:DI, DS:SI, Sprite.xSize);
codeseg:9E23 ;   DI += 320;
codeseg:9E23 ;   SI += Sprite.xSize;  
codeseg:9E23 ; }
codeseg:9E23 
codeseg:9E23 AO_agi256_restoreArea_loop proc near    ; CODE XREF: AO_agi256_restoreArea_loop+8�j
codeseg:9E23                                         ; AO_agi256_restoreArea_loop_init+D�j
codeseg:9E23                 mov     cl, al          ; Move Sprite.xSize bytes per row
codeseg:9E25                 repe movsb              ; Move the bytes from DS:SI to ES:DI
codeseg:9E27                 add     di, dx          ; Move to the next row
codeseg:9E27                                         ; repe movsb added Sprite.xSize to DI
codeseg:9E27                                         ; add di,dx adds (320 - Sprite.xSize) to DI
codeseg:9E27                                         ; so the addition is Sprite.xSize + (320 - Sprite.xSize) = 320
codeseg:9E29                 dec     ah
codeseg:9E2B                 jnz     AO_agi256_restoreArea_loop ; Loop in pseudo C:
codeseg:9E2B                                         ; for (int y = 0; y < Sprite.ySize; y++) {
codeseg:9E2B                                         ;   memcpy(ES:DI, DS:SI, Sprite.xSize);
codeseg:9E2B                                         ;   DI += 320;
codeseg:9E2B                                         ;   SI += Sprite.xSize;  
codeseg:9E2B                                         ; }
codeseg:9E2D                 pop     es
codeseg:9E2E                 add     sp, 2
codeseg:9E31                 pop     bp
codeseg:9E32                 pop     di
codeseg:9E33                 pop     si
codeseg:9E34                 retn
codeseg:9E34 AO_agi256_restoreArea_loop endp ; sp =  0Ah
codeseg:9E34 
codeseg:9E35 
codeseg:9E35 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
codeseg:9E35 
codeseg:9E35 ; Attributes: bp-based frame
codeseg:9E35 
codeseg:9E35 AO_agi256_blit  proc near               ; CODE XREF: j_AO_agi256_blit�j
codeseg:9E35 
codeseg:9E35 structPtr       = word ptr  8
codeseg:9E35 arg_1C          = byte ptr  24h
codeseg:9E35 
codeseg:9E35                 push    si
codeseg:9E36                 push    di
codeseg:9E37                 push    bp
codeseg:9E38                 mov     bp, sp
codeseg:9E3A                 sub     sp, 2
codeseg:9E3D                 mov     bp, [bp+structPtr]
codeseg:9E40                 mov     al, [bp+2]
codeseg:9E43                 push    ax
codeseg:9E44                 mov     si, [bp+10h]
codeseg:9E47                 test    byte ptr [si+2], 80h
codeseg:9E4B                 jz      dontMirror
codeseg:9E4D                 push    bp
codeseg:9E4E                 call    _BlitMirrorCell
codeseg:9E51                 pop     bp
codeseg:9E52                 mov     si, [bp+10h]
codeseg:9E55 
codeseg:9E55 dontMirror:                             ; CODE XREF: AO_agi256_blit+16�j
codeseg:9E55                 inc     si
codeseg:9E56                 lodsw
codeseg:9E57                 mov     dx, ax
codeseg:9E59                 mov     ah, byte ptr [bp+blitStruc.xPos]
codeseg:9E5C                 mov     al, byte ptr [bp+blitStruc.yPos]
codeseg:9E5F                 sub     al, dl
codeseg:9E61                 inc     al
codeseg:9E63                 call    screenOffset    ; Calculates the screen offset for given coordinate? Video or AGI screen offset?
codeseg:9E63                                         ; DI = AL * 320 + AH
codeseg:9E63                                         ; (Destroys BX contents (Returns with BH = 0, BL = AH))
codeseg:9E63                                         ; 
codeseg:9E63                                         ; Maybe not named quite correctly?
codeseg:9E66                 shl     dh, 1
codeseg:9E68                 shl     dh, 1
codeseg:9E6A                 shl     dh, 1
codeseg:9E6C                 shl     dh, 1           ; DH *= 16
codeseg:9E6E                 push    es
codeseg:9E6F                 mov     es, agi256PicSeg
codeseg:9E73                 mov     bl, 1
codeseg:9E75                 mov     bh, [bp+arg_1C]
codeseg:9E78                 shl     bh, 1
codeseg:9E7A                 shl     bh, 1
codeseg:9E7C                 shl     bh, 1
codeseg:9E7E                 shl     bh, 1           ; BH *= 16
codeseg:9E80                 mov     bp, di
codeseg:9E82                 xor     cx, cx
codeseg:9E84                 jmp     short startBlit ; Read byte from DS:[SI++]
codeseg:9E86 ; ---------------------------------------------------------------------------
codeseg:9E86                 nop
codeseg:9E87 
codeseg:9E87 ah_eq_dh:                               ; CODE XREF: AO_agi256_blit+61�j
codeseg:9E87                 cbw                     ; Sign extend AL to AX (0 <= AL <= 0x0F, so AH = 0)
codeseg:9E88                 add     di, ax          ; DI += AX
codeseg:9E8A 
codeseg:9E8A startBlit:                              ; CODE XREF: AO_agi256_blit+4F�j
codeseg:9E8A                                         ; AO_agi256_blit+83�j ...
codeseg:9E8A                 lodsb                   ; Read byte from DS:[SI++]
codeseg:9E8B                 or      al, al
codeseg:9E8D                 jz      zeroByte        ; Jump if it's zero
codeseg:9E8F                 mov     ah, al          ; Double the pixel
codeseg:9E91                 and     ax, 0F00Fh      ; Make lower nibble of AL contain pixel's color info and
codeseg:9E91                                         ; upper nibble of AH contain pixel's priority/control info
codeseg:9E94                 cmp     ah, dh
codeseg:9E96                 jz      ah_eq_dh        ; Sign extend AL to AX (0 <= AL <= 0x0F, so AH = 0)
codeseg:9E98                 mov     cl, al
codeseg:9E9A                 shr     ah, 1
codeseg:9E9C                 shr     ah, 1
codeseg:9E9E                 shr     ah, 1
codeseg:9EA0                 shr     ah, 1           ; Bring priority/control info to lower nibble of AH
codeseg:9EA2 
codeseg:9EA2 xLoop:                                  ; CODE XREF: AO_agi256_blit+81�j
codeseg:9EA2                                         ; AO_agi256_blit+B1�j
codeseg:9EA2                 mov     al, es:[di]     ; Read pixel
codeseg:9EA5                 and     al, 0F0h        ; Leave only the priority/control info
codeseg:9EA7                 cmp     al, 2 shl 4
codeseg:9EA9                 jbe     controlByte012  ; Jump if pixel's control info is 0, 1 or 2
codeseg:9EAB                 cmp     al, bh
codeseg:9EAD                 ja      priGreaterThanBH
codeseg:9EAF                 mov     al, bh          ; AL <= BH so
codeseg:9EAF                                         ; AL = BH <=> AL = MAX(AL, BH)
codeseg:9EB1 
codeseg:9EB1 loc_9EB1:                               ; CODE XREF: AO_agi256_blit+AE�j
codeseg:9EB1                 or      al, ah          ; AL |= AH
codeseg:9EB3                 jmp     AO_agi256_blit_sub ; ES:[160 + DI++] = AL & 0x0F;
codeseg:9EB3                                         ; BL = 0;
codeseg:9EB6 ; ---------------------------------------------------------------------------
codeseg:9EB6 
codeseg:9EB6 afterBlitSubCall:                       ; CODE XREF: AO_agi256_blit_sub+D�j
codeseg:9EB6                 loop    xLoop           ; Read pixel
codeseg:9EB8                 jmp     short startBlit ; Read byte from DS:[SI++]
codeseg:9EBA ; ---------------------------------------------------------------------------
codeseg:9EBA 
codeseg:9EBA zeroByte:                               ; CODE XREF: AO_agi256_blit+58�j
codeseg:9EBA                 dec     dl              ; DL--
codeseg:9EBC                 jz      zeroDL
codeseg:9EBE                 add     bp, 320
codeseg:9EC2                 mov     di, bp
codeseg:9EC4                 jmp     short startBlit ; Read byte from DS:[SI++]
codeseg:9EC6 ; ---------------------------------------------------------------------------
codeseg:9EC6 
codeseg:9EC6 controlByte012:                         ; CODE XREF: AO_agi256_blit+74�j
codeseg:9EC6                 push    di
codeseg:9EC7                 xor     ch, ch
codeseg:9EC9 
codeseg:9EC9 loc_9EC9:                               ; CODE XREF: AO_agi256_blit+A7�j
codeseg:9EC9                 cmp     di, 0D0C0h
codeseg:9ECD                 jnb     loc_9EDE
codeseg:9ECF                 add     di, 320
codeseg:9ED3                 mov     ch, es:[di]
codeseg:9ED6                 and     ch, 0F0h
codeseg:9ED9                 cmp     ch, 20h ; ' '
codeseg:9EDC                 jbe     loc_9EC9
codeseg:9EDE 
codeseg:9EDE loc_9EDE:                               ; CODE XREF: AO_agi256_blit+98�j
codeseg:9EDE                 pop     di
codeseg:9EDF                 cmp     ch, bh
codeseg:9EE1                 mov     ch, 0
codeseg:9EE3                 jbe     loc_9EB1        ; AL |= AH
codeseg:9EE5 
codeseg:9EE5 priGreaterThanBH:                       ; CODE XREF: AO_agi256_blit+78�j
codeseg:9EE5                 inc     di
codeseg:9EE6                 loop    xLoop           ; Read pixel
codeseg:9EE8                 jmp     short startBlit ; Read byte from DS:[SI++]
codeseg:9EEA ; ---------------------------------------------------------------------------
codeseg:9EEA 
codeseg:9EEA zeroDL:                                 ; CODE XREF: AO_agi256_blit+87�j
codeseg:9EEA                 pop     es
codeseg:9EEB                 pop     ax
codeseg:9EEC                 or      al, al
codeseg:9EEE                 jnz     zeroDL_notZeroAL
codeseg:9EF0                 mov     al, 1           ; f1 = Ego is invisible on the screen (Completely obscured by another object)
codeseg:9EF2                 test    bl, bl
codeseg:9EF4                 jnz     notZeroBL       ; Hide ego (Set ego as invisible)
codeseg:9EF6                 call    _ResetFlagAL    ; Show ego (Set ego as visible i.e. not invisible)
codeseg:9EF9                 jmp     short zeroDL_notZeroAL
codeseg:9EFB ; ---------------------------------------------------------------------------
codeseg:9EFB 
codeseg:9EFB notZeroBL:                              ; CODE XREF: AO_agi256_blit+BF�j
codeseg:9EFB                 call    _SetFlagAL      ; Hide ego (Set ego as invisible)
codeseg:9EFE 
codeseg:9EFE zeroDL_notZeroAL:                       ; CODE XREF: AO_agi256_blit+B9�j
codeseg:9EFE                                         ; AO_agi256_blit+C4�j
codeseg:9EFE                 add     sp, 2
codeseg:9F01                 pop     bp
codeseg:9F02                 pop     di
codeseg:9F03                 pop     si
codeseg:9F04                 retn
codeseg:9F04 AO_agi256_blit  endp
codeseg:9F04 
codeseg:9F05 
codeseg:9F05 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
codeseg:9F05 
codeseg:9F05 ; DX = 320 - Sprite.xSize (AL)
codeseg:9F05 ; SI += 160 (This is done in part 2 of the loop init, actually)
codeseg:9F05 ; This is elsewhere than directly inside AO_agi256_saveArea
codeseg:9F05 ; probably because it didn't fit otherwise. Returns to AO_agi256_saveArea_loop
codeseg:9F05 ; (Although calls AO_agi256_saveArea_loop_init_part2 first)
codeseg:9F05 
codeseg:9F05 AO_agi256_saveArea_loop_init proc near  ; CODE XREF: AO_agi256_saveArea+28�j
codeseg:9F05                 mov     dx, 320
codeseg:9F08                 push    ax
codeseg:9F09                 xor     ah, ah
codeseg:9F0B                 sub     dx, ax          ; DX = 320 - Sprite.xSize
codeseg:9F0D                 pop     ax
codeseg:9F0E                 jmp     AO_agi256_saveArea_loop_init_part2 ; This is elsewhere than directly inside AO_agi256_saveArea_loop_init
codeseg:9F0E AO_agi256_saveArea_loop_init endp       ; probably because it didn't fit otherwise. Returns to AO_agi256_saveArea_loop
codeseg:9F0E 
codeseg:9F11 
codeseg:9F11 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
codeseg:9F11 
codeseg:9F11 ; DX = 320 - Sprite.xSize (AL)
codeseg:9F11 ; DI += 160
codeseg:9F11 ; This is elsewhere than directly inside AO_agi256_restoreArea
codeseg:9F11 ; probably because it didn't fit otherwise. Returns to AO_agi256_restoreArea_loop
codeseg:9F11 
codeseg:9F11 AO_agi256_restoreArea_loop_init proc near
codeseg:9F11                                         ; CODE XREF: AO_agi256_restoreArea+26�j
codeseg:9F11                 mov     dx, 320
codeseg:9F14                 push    ax
codeseg:9F15                 xor     ah, ah
codeseg:9F17                 sub     dx, ax
codeseg:9F19                 pop     ax
codeseg:9F1A                 add     di, 160
codeseg:9F1E                 jmp     AO_agi256_restoreArea_loop ; Loop in pseudo C:
codeseg:9F1E AO_agi256_restoreArea_loop_init endp    ; for (int y = 0; y < Sprite.ySize; y++) {
codeseg:9F1E                                         ;   memcpy(ES:DI, DS:SI, Sprite.xSize);
codeseg:9F1E                                         ;   DI += 320;
codeseg:9F1E                                         ;   SI += Sprite.xSize;  
codeseg:9F1E                                         ; }
codeseg:9F21 
codeseg:9F21 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
codeseg:9F21 
codeseg:9F21 ; This is elsewhere than directly inside AO_agi256_saveArea_loop_init
codeseg:9F21 ; probably because it didn't fit otherwise. Returns to AO_agi256_saveArea_loop
codeseg:9F21 
codeseg:9F21 AO_agi256_saveArea_loop_init_part2 proc near
codeseg:9F21                                         ; CODE XREF: AO_agi256_saveArea_loop_init+9�j
codeseg:9F21                 add     si, 160
codeseg:9F25                 jmp     AO_agi256_saveArea_loop ; Loop in pseudo C:
codeseg:9F25 AO_agi256_saveArea_loop_init_part2 endp ; for (int y = 0; y < Sprite.ySize; y++) {
codeseg:9F25                                         ;   memcpy(ES:DI, DS:SI, Sprite.xSize);
codeseg:9F25                                         ;   SI += 320;
codeseg:9F25                                         ;   DI += Sprite.xSize;  
codeseg:9F25                                         ; }
codeseg:9F28 
codeseg:9F28 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
codeseg:9F28 
codeseg:9F28 ; ES:[160 + DI++] = AL & 0x0F;
codeseg:9F28 ; BL = 0;
codeseg:9F28 
codeseg:9F28 AO_agi256_blit_sub proc near            ; CODE XREF: AO_agi256_blit+7E�j
codeseg:9F28                 add     di, 160
codeseg:9F2C                 and     al, 0Fh
codeseg:9F2E                 stosb
codeseg:9F2F                 sub     di, 160
codeseg:9F33                 xor     bl, bl
codeseg:9F35                 jmp     afterBlitSubCall
codeseg:9F35 AO_agi256_blit_sub endp
codeseg:9F35 
codeseg:9F35 ; ---------------------------------------------------------------------------
codeseg:9F38                 db 0D8h dup(0)
codeseg:9F38 codeseg         ends
codeseg:9F38 

Differences between AGI v2.936's AGI.EXE and AGI256's hacked AGI.EXE

Disclaimer

This is a raw info dump from a personal file so things may be funny, wrong, weird or <insert your favorite adjective here> but there are details to be sure:

The raw info dump

Differences between original Sierra On-Line's AGI interpreter version 2.936
and the hacked AGI256's AGI.EXE:

/////////////////////////////////////////////////////////////////////////////

Copyright string changed and some other bytes...
not 100% sure if they are used or not... let's see.
If changed bytes from seg000:0065 to seg000:0077 to all zeroes and to all semirandomly
typed in numbers and all it did was that it made the AGI256 demo have some white color
pixels where they shouldn't be in the Larry's bar screen. So... it may very well be that they're used.

NOTE THAT:    E8 49 00    =    call sub_C4    =    db 'FI',0
AND there's a real subroutine starting at seg000:00C4 so it might be used as code!

- ORIGINAL 2.936 INTERPRETER:
seg000:0000 aAdventureGameI db 'Adventure Game Interpreter',0Dh,0Ah
seg000:0000                                         ; DATA XREF: seg001:0000�o
seg000:0000                                         ; sub_401D+59�r ...
seg000:0000                 db 'Copyright (C) 1984, 1985, 1986 Sierra On-Line, Inc.',0Dh,0Ah
seg000:0000                 db 'Authors: Jeff Stephenson & Chris Iden',0Dh,0Ah
seg000:0000                 db 'FI',0

-> AGI256 INTERPRETER:
seg000:0000 aAgi256ColorsCS db 'AGI 256 colors ',0Dh,0Ah ; DATA XREF: seg001:0000�o
seg000:0000                                         ; sub_401D+59�r ...
seg000:0000                 db '(C) Sierra On-Line - by Jeff Stephenson and Chris Iden',0Dh,0Ah
seg000:0000                 db 'Hacked by Dark Minister',0Dh,0Ah
seg000:0000                 db 'FI',0

seg000:0065                 db 87h                  ; Unknown data from 0x0065 to 0x0077
seg000:0066                 db  49h ; I
seg000:0067                 db  29h ; )
seg000:0068                 db  23h ; #             ; DATA XREF: sub_4125+12�r
seg000:0068                                         ; sub_4125+27�r ...
seg000:0069                 db 92h
seg000:006A                 db 99h
seg000:006B                 db 99h
seg000:006C                 db 11h
seg000:006D                 db  11h ;  
seg000:006E                 db 11h
seg000:006F                 db  19h ;  
seg000:0070                 db 88h
seg000:0071                 db  37h ; 7
seg000:0072                 db 83h
seg000:0073                 db  83h ; â
seg000:0074                 db  73h ; s
seg000:0075                 db  87h ; ç
seg000:0076                 db  38h ; 8
seg000:0077                 db  83h ; â

/////////////////////////////////////////////////////////////////////////////

In function _StatLineWrite (Function name taken from Agi2917.idb):
Changes _WindowLineClr call to setWhiteMenuBar call
which clears first 8 rows of video memory with white.
So changes the code that clears the status line before writing to it.

Rationale:
Probably because of wanting VGA support.

- ORIGINAL 2.936 INTERPRETER:
seg000:34D7 E8 CC F6                    call    sub_2BA6 ; _WindowLineClr in Agi2917.idb

-> AGI256 INTERPRETER:
seg000:34D7 E8 80 65                    call    near ptr 9A5Ah

0x9A5A - 0x9800 = 0x025A in the AGIGRAF.OVL:

seg000:025A ; Clears first 8 rows (320*8 bytes) of video memory
seg000:025A ; with white pixels (Color 15).
seg000:025A 
seg000:025A setWhiteMenuBar proc near
seg000:025A                 push    cx
seg000:025B                 push    es
seg000:025C                 push    di
seg000:025D                 push    ax
seg000:025E                 mov     ax, 0A000h
seg000:0261                 mov     es, ax
seg000:0263                 assume es:nothing
seg000:0263                 xor     di, di
seg000:0265                 mov     ax, 0F0Fh
seg000:0268                 mov     cx, 500h
seg000:026B                 repe stosw
seg000:026D                 pop     ax
seg000:026E                 pop     di
seg000:026F                 pop     es
seg000:0270                 assume es:nothing
seg000:0270                 pop     cx
seg000:0271                 retn
seg000:0271 setWhiteMenuBar endp

/////////////////////////////////////////////////////////////////////////////

In _ArrangeMem (Name from Agi2917.idb):
Changed to allocating twice the memory than with the original interpreter.
Saves the allocated memory's segment to SBuff_Seg in Agi2917.idb and
to agi256PicSeg in AGI256's disassembly.

Rationale:
Need another screen besides the 16 color & control line & priority info screen
for 256 color info so that doubles the memory need.

0x690 in paragraphs (16 bytes) is 160*168 bytes.
0xD20 is twice that.

- ORIGINAL 2.936 INTERPRETER:
seg000:4240                 mov     bx, 690h

-> AGI256 INTERPRETER:
seg000:4240                 mov     bx, 0D20h

/////////////////////////////////////////////////////////////////////////////

In _ArrangeMem (Name from Agi2917.idb):
Changed to allocating twice the memory than with the original interpreter.
Saves the allocated memory's segment to wHGCFontData in Agi2917.idb.

Rationale:
Don't really know. Maybe not needed at all? Or it's also possible that the
wHGCFontData is not a correct name for the variable and/or the allocate
area is used for something else and Hercules font data.

0x690 in paragraphs (16 bytes) is 160*168 bytes.
0xD20 is twice that.

- ORIGINAL 2.936 INTERPRETER:
seg000:4259                 add     ax, 690h

-> AGI256 INTERPRETER:
seg000:4259                 add     ax, 0D20h

/////////////////////////////////////////////////////////////////////////////

In an AGI screen buffer filling function (_SBuffClear in Agi2917.idb):
Fills the AGI screen buffer with AX contents. Filling space doubled in AGI256.
(There's some obsolete Hercules code in this function, but it's not used so
it doesn't matter).

Use cases:
AX = 0x4040 (Fill with lowest priority i.e. 4 and black color i.e. 0).
AX = 0x4F4F (Fill with lowest priority i.e. 4 and white color i.e. 15).

Rationale:
Needed because the 256 color screen and the normal 16 color screen are
horizontally adjacent. Probably only needed for clearing the 16 color
screen because the 256 color screen is always fully filled when loading
an AGI256 picture resource into it.

160*168   = 0x3480 * 2
160*168*2 = 0x6900 * 2
There's a repe stosw using cx after this instruction.

- ORIGINAL 2.936 INTERPRETER:
seg000:525E                 mov     cx, 3480h

-> AGI256 INTERPRETER:
seg000:525E                 mov     cx, 6900h

/////////////////////////////////////////////////////////////////////////////

In _SBuffXLine (Name from Agi2917.idb):
Changes direct pixel manipulation code to a function call.
Functionally changes nothing as the called function is functionally
identical to the code that was replaced.

Rationale:
Maybe not needed at all? Maybe some leftover modification that wasn't used
after all?

0x9A4F must be pointing to:

seg000:024E ; Sets and/or clears current pixel bits
seg000:024E ; AL = ES:[DI] = PIXEL
seg000:024E ; (PIXEL |= BH) &= BL
seg000:024E 
seg000:024E setClrCurrPixel proc near
seg000:024E                 nop
seg000:024F                 mov     al, es:[di]
seg000:0252                 or      al, bh
seg000:0254                 and     al, bl
seg000:0256                 mov     es:[di], al
seg000:0259                 retn
seg000:0259 setClrCurrPixel endp

in AGIGRAF.OVL! So that makes their relocation value 0x9A4F - 0x24E = 0x9801...
wait... that's not even... let's see, there's a nop in setClrCurrPixel's start.
Let's throw that away so we'd jump right into 0x24F so the relocation value
would be 0x9A4F - 0x24E = 0x9800... now that's better :-).

- ORIGINAL 2.936 INTERPRETER:
seg000:5298 loc_5298:                               ; CODE XREF: sub_526F+34�j
seg000:5298                 inc     di
seg000:5299                 mov     al, es:[di]     ; CHANGED
seg000:529C                 or      al, bh          ; CHANGED
seg000:529E                 and     al, bl          ; CHANGED
seg000:52A0                 mov     es:[di], al     ; CHANGED
seg000:52A3                 loop    loc_5298

-> AGI256 INTERPRETER:
seg000:5298 loc_5298:                               ; CODE XREF: sub_526F+34�j
seg000:5298                 inc     di
seg000:5299                 call    near ptr 9A4Fh  ; CHANGED
seg000:52A3                 loop    loc_5298

/////////////////////////////////////////////////////////////////////////////

In _SBuffYLine (Name from Agi2917.idb):
This converts the vertical drawing loop to use 320 rather than 160 as the
offset between rows. Also changes direct pixel manipulation code to a
function call with functionally identical code in it.

Rationale:
As there are now two AGI screens horizontally adjacent to each other (Left
160x168 one is the normal 16 color screen and the right 160x168 one is the
new 256 color screen) the vertical line drawing loop has to use 320 as the
offset between rows rather than 160. The pixel manipulation code replacement
with a function call is probably not needed as it doesn't functionally change
anything.

- ORIGINAL 2.936 INTERPRETER:
seg000:52E3 loc_52E3:                               ; CODE XREF: sub_52AB+34�j
seg000:52E3                 add     di, 0A0h ; 'á'
seg000:52E7                 mov     al, es:[di]
seg000:52EA                 or      al, bh
seg000:52EC                 and     al, bl
seg000:52EE                 mov     es:[di], al
seg000:52F1                 loop    loc_52E1

-> AGI256 INTERPRETER:
seg000:52E3 loc_52E3:                               ; CODE XREF: sub_52AB+34�j
seg000:52E3                 add     di, 140h
seg000:52E7                 call    near ptr 9A4Fh
seg000:52F1                 loop    loc_52E1

which is effectively the same as:

seg000:52E3 loc_52E3:                               ; CODE XREF: sub_52AB+34�j
seg000:52E3                 add     di, 140h
seg000:024F                 mov     al, es:[di]
seg000:0252                 or      al, bh
seg000:0254                 and     al, bl
seg000:0256                 mov     es:[di], al
seg000:52F1                 loop    loc_52E1

/////////////////////////////////////////////////////////////////////////////

In _SBuffPlotPixel (Name from Agi2917.idb):
Changes multiplication from 160 to 320 in calculation x + y * 320.
(16 to 32 really but they're multiplied by 10 before these changes).

Rationale:
As there are now two AGI screens horizontally adjacent to each other (Left
160x168 one is the normal 16 color screen and the right 160x168 one is the
new 256 color screen) the pixel plotting code has to use 320 as the offset
between rows rather than 160.

- ORIGINAL 2.936 INTERPRETER:
seg000:5311                 shl     di, 1
seg000:5313                 shl     di, 1
seg000:5315                 shl     di, 1
seg000:5317                 shl     di, 1

-> AGI256 INTERPRETER:
seg000:5311                 shl     di, 4
seg000:5314                 shl     di, 1

/////////////////////////////////////////////////////////////////////////////

In _SBuffPlotPixel (Name from Agi2917.idb):
Changes direct pixel manipulation code to a function call.
Functionally changes nothing as the called function is functionally
identical to the code that was replaced.

Rationale:
Maybe not needed at all? Maybe some leftover modification that wasn't used
after all?

- ORIGINAL 2.936 INTERPRETER:
seg000:532F                 mov     al, es:[di]
seg000:5332                 or      al, bh
seg000:5334                 and     al, bl
seg000:5336                 mov     es:[di], al

-> AGI256 INTERPRETER:
seg000:532F                 call    near ptr 9A4Fh

/////////////////////////////////////////////////////////////////////////////

In _SBuffPicFill (Name from Agi2917.idb):
Changes multiplication from 160 to 320 in calculation x + y * 320.
(16 to 32 really but they're multiplied by 10 before these changes).

Rationale:
As there are now two AGI screens horizontally adjacent to each other (Left
160x168 one is the normal 16 color screen and the right 160x168 one is the
new 256 color screen) the pixel plotting code has to use 320 as the offset
between rows rather than 160.

- ORIGINAL 2.936 INTERPRETER:
seg000:5483                 shl     di, 1
seg000:5485                 shl     di, 1
seg000:5487                 shl     di, 1
seg000:5489                 shl     di, 1

-> AGI256 INTERPRETER:
seg000:5483                 shl     di, 4
seg000:5486                 shl     di, 1

/////////////////////////////////////////////////////////////////////////////

In _Pic_Show (Name from Agi2917.idb):
Before calling j_EGAPutBlock (Name from Agi2917.idb) or j_AG_agi256PutBlock
(Name from AGI256's disassembly) rotate the AGI screen buffers' pixels right
by four in place (Writes the rotated values back to the buffer, that is)
if a certain variable is one (rotate_sbuff). Probably exchanges the places
of color and priority information.

Rationale:
As there are now two AGI screens horizontally adjacent to each other (Left
160x168 one is the normal 16 color screen and the right 160x168 one is the
new 256 color screen) priority screen showing code needs to use 320 as the
offset between rows rather than 160. But because the code is just a single
loop for rotating the whole screen and rotating the 256 color values (If
they aren't shown) doesn't matter (As presumably they are rotated back to
their normal values afterwards) it is easier to just rotate both screens.

160*168   = 0x6900
160*168*2 = 0xD200

- ORIGINAL 2.936 INTERPRETER:
seg000:5563                 mov     cx, 6900h

-> AGI256 INTERPRETER:
seg000:5563                 mov     cx, 0D200h

/////////////////////////////////////////////////////////////////////////////

In _FBuffOffset (Agi2917.idb), agiToScreenCoords (AGI256 disassembly):
Changes graphics driver dependent (CGA, EGA, Hercules etc) specific
switches to a single VGA specific code.

Rationale:
AGI256 requires VGA so there's no need for the other switches.

// The original 2.936 interpreter's part in pseudo C:
{
    uint16 display = *(ds:0x1130); // enum {CGA, Tandy, HGC, EGA, VGA?};
    uint16 computer = *(ds:0x112e); // enum { IBM_PC?, PCJr?, Tandy?, ...?}

    if (display == VGA)
        x *= 2;
    
    if (computer == IBM_PC) {
        x /= 2;
        if (display == EGA)
            x /= 2;
    }

    if (computer == Tandy) {
        if (display == EGA)
            x /= 4;
    }

    offset += x;
    retn;
}

// AGI256 interpreter's part in pseudo C:
di += bx * 2;
retn;

- ORIGINAL 2.936 INTERPRETER:
seg000:5636                 cmp     word ptr ds:1130h, 4
seg000:563B                 jnz     loc_563F
seg000:563D                 shl     bx, 1
seg000:563F 
seg000:563F loc_563F:                               ; CODE XREF: seg000:563B�j
seg000:563F                 cmp     word ptr ds:112Eh, 0
seg000:5644                 jnz     loc_5651
seg000:5646                 shr     bx, 1
seg000:5648                 cmp     word ptr ds:1130h, 3
seg000:564D                 jnz     loc_5651
seg000:564F                 shr     bx, 1
seg000:5651 
seg000:5651 loc_5651:                               ; CODE XREF: seg000:5644�j
seg000:5651                                         ; seg000:564D�j
seg000:5651                 cmp     word ptr ds:112Eh, 2
seg000:5656                 jnz     loc_5663
seg000:5658                 cmp     word ptr ds:1130h, 3
seg000:565D                 jnz     loc_5663
seg000:565F                 shr     bx, 1
seg000:5661                 shr     bx, 1
seg000:5663 
seg000:5663 loc_5663:                               ; CODE XREF: seg000:5656�j
seg000:5663                                         ; seg000:565D�j
seg000:5663                 add     di, bx
seg000:5665                 retn

-> AGI256 INTERPRETER:
seg000:5636                 shl     bx, 1
seg000:5638                 add     di, bx
seg000:563A                 retn

/////////////////////////////////////////////////////////////////////////////

In _PicBuffOffset (Agi2917.idb), screenOffset (AGI256 disassembly):
Changes multiplication from 160 to 320 in calculation x + y * 320.
(16 to 32 really but they're multiplied by 10 before these changes).

Rationale:
As there are now two AGI screens horizontally adjacent to each other (Left
160x168 one is the normal 16 color screen and the right 160x168 one is the
new 256 color screen) the AGI screen pixel position calculation has to use
320 as the offset between rows rather than 160.

- ORIGINAL 2.936 INTERPRETER:
seg000:5676                 shl     di, 1
seg000:5678                 shl     di, 1
seg000:567A                 shl     di, 1
seg000:567C                 shl     di, 1

-> AGI256 INTERPRETER:
seg000:5676                 shl     di, 4
seg000:5679                 shl     di, 1
seg000:567B                 nop
seg000:567C                 nop
seg000:567D                 nop

/////////////////////////////////////////////////////////////////////////////

Function that is called near the  _EnablePicDraw's beginning in Agi2917.idb:

If the relocation value 0x9800 works here too (Why wouldn't it?) then
we're changing jump from ???GRAF.OVL's first subroutine (Not from the
jump table in its head but after that at 0x0015 is the first subroutine)
to a straight return. The first subroutine the the ???GRAF.OVL is the video
mode setting routine. At least in AGIGRAF.OVL it sets 320x200 256 color video
mode (Mode 13h), sets ds:[videoOfs] to 0xA000 and clears first 64 KiB of video
memory with zeroes.

Rationale:
So this basically throws away some video mode specific stuff and replaces
it with a VGA specific "nothing needed here" code :).

// The original 2.936 interpreter's part in pseudo C:
{
    uint16 display = *(ds:0x1130); // enum {CGA, Tandy, HGC, EGA, VGA?};
    uint16 computer = *(ds:0x112e); // enum { IBM_PC?, PCJr?, Tandy?, ...?}
    
    if (computer == IBM_PC && display != HGC && display != EGA)
        setVideoMode(); // goto near ptr 0x9815;
    else
        retn;
}

// AGI256 interpreter's part in pseudo C (Eh :)):
retn;

- ORIGINAL 2.936 INTERPRETER:
seg000:569F                 jmp     near ptr 9815h

-> AGI256 INTERPRETER:
seg000:569F                 retn

/////////////////////////////////////////////////////////////////////////////

If the relocation value 0x9800 works here too (Why wouldn't it?) then
we're changing jump from ???GRAF.OVL's second subroutine (Not from the
jump table in its head but after that at 0x0037 is the second subroutine)
to a straight return. The second subroutine the the ???GRAF.OVL is the text
mode setting routine. At least in AGIGRAF.OVL it sets 40x25 16 color text mode,
enables background intensity (Colors 8-15), sets some cursor stuff and
clears the text screen using some attribute.

So this basically throws away some video mode specific stuff and replaces
it with a VGA specific "nothing needed here" code :).

// The original 2.936 interpreter's part in pseudo C:
{
    uint16 display = *(ds:0x1130); // enum {CGA, Tandy, HGC, EGA, VGA?};
    uint16 computer = *(ds:0x112e); // enum { IBM_PC?, PCJr?, Tandy?, ...?}
    
    if (computer == IBM_PC && display != HGC && display != EGA)    
        setTextMode(); // goto near ptr 0x9837;
    else
        retn;
}

// AGI256 interpreter's part in pseudo C (Eh :)):
retn;

- ORIGINAL 2.936 INTERPRETER:
seg000:5937                 jmp     near ptr 9837h

-> AGI256 INTERPRETER:
seg000:5937                 retn

/////////////////////////////////////////////////////////////////////////////

'GAMEID' -string's (No trailing zero btw) start is turned into 'DM', 0

Rationale:
DM is probably short for "Dark Minister" who was the hacker who made the
AGI256 hack. Is this modification needed? Is this checked as the game ID
or something? Don't know...

- ORIGINAL 2.936 INTERPRETER: 
seg000:5B6C                 'GAMEID' (A string without the trailing zero)

-> AGI256 INTERPRETER:
seg000:5B6C                 'DM', 0 (, 'eID')

/////////////////////////////////////////////////////////////////////////////

In _MenuInput (Agi2917.idb):
Changes _WindowLineClr (Agi2917.idb) call near the function's beginning to
AGIGRAF.OVL's setWhiteMenuBar which clears first 8 rows (320*8 bytes) of
video memory with white pixels (Color 15).

Rationale:
Probably needed for VGA support when handling the menu/status line.

- ORIGINAL 2.936 INTERPRETER:
seg000:93ED                 call    sub_2BA6

-> AGI256 INTERPRETER:
seg000:93ED                 call    near ptr 9A5Ah

/////////////////////////////////////////////////////////////////////////////

- ORIGINAL 2.936 INTERPRETER & AGI256 INTERPRETER -info combined:
seg001:0000                 dd    0 ;
seg001:0004                 db    0 ;  
seg001:0005                 db    0 ;  
seg001:0006                 dd unk_9800
seg001:000A                 dw seg seg006
seg001:000C                 db  86h ; Ã¥
seg001:000D                 db    0 ;  
seg001:000E                 db    0 ;  
seg001:000F                 db    0 ;  
seg001:0010                 db    0 ;  
seg001:0011                 db    0 ;  
seg001:0012                 db  2Bh ; +
seg001:0013                 db    0 ;  
seg001:0014                 db    0 ;  
seg001:0015                 db    0 ;  
seg001:0016                 dd unk_9800
seg001:001A                 dw seg seg004
seg001:001C                 db  93h ; ô
seg001:001D                 db    0 ;  
seg001:001E                 db    0 ;  
seg001:001F                 db    0 ;  
seg001:0020                 db    0 ;  
seg001:0021                 db    0 ;  
seg001:0022                 db  1Eh ;  
seg001:0023                 db    0 ;  
seg001:0024                 db    0 ;  
seg001:0025                 db    0 ;  
seg001:0026                 dd unk_9800
seg001:002A                 dw seg seg005
seg001:002C                 db 159
seg001:002D                 db    0 ;  
seg001:002E                 db    0 ;  
seg001:002F                 db    0 ;  
seg001:0030                 db    0 ;  
seg001:0031                 db    0 ;  
seg001:0032                 db 37                   ; Changed 0x25 (37) -> 0x28 (40) in AGI256 hack, size in paragraphs
seg001:0033                 db    0 ;  
seg001:0034                 db    0 ;  
seg001:0035                 db    0 ;  
seg001:0036                 dd unk_9800
seg001:003A                 dw seg seg007
seg001:003C                 db 172
seg001:003D                 db    0 ;  
seg001:003E                 db    0 ;  
seg001:003F                 db    0 ;  
seg001:0040                 db    0 ;  
seg001:0041                 db    0 ;  
seg001:0042                 db 91
seg001:0043                 db    0 ;  
seg001:0044                 db    0 ;  
seg001:0045                 db    0 ;  
seg001:0046                 dd unk_9800
seg001:004A                 dw seg seg003
seg001:004C                 db 185
seg001:004D                 db    0 ;  
seg001:004E                 db    0 ;  
seg001:004F                 db    0 ;  
seg001:0050                 db    0 ;  
seg001:0051                 db    0 ;  
seg001:0052                 db 23                   ; Changed 0x17 (23) -> 0x28 (40) in AGI256 hack, size in paragraphs
seg001:0053                 db    0 ;  
seg001:0054                 db    0 ;  
seg001:0055                 db    0 ;  
seg001:0056                 dd unk_9DB0
seg001:005A                 dw seg seg008
seg001:005C                 db 197
seg001:005D                 db    0 ;  
seg001:005E                 db    0 ;  
seg001:005F                 db    0 ;  
seg001:0060                 db    0 ;  
seg001:0061                 db    0 ;  
seg001:0062                 db 22                   ; Changed 0x16 (22) -> 0x19 (25) in AGI256 hack, size in paragraphs
seg001:0063                 db    0 ;  
seg001:0064                 db    0 ;  
seg001:0065                 db    0 ;  
seg001:0066                 dd unk_9DB0
seg001:006A                 dw seg seg009
seg001:006C                 dw 210
seg001:006E                 db    0 ;  
seg001:006F                 db    0 ;  
seg001:0070                 db    0 ;  
seg001:0071                 db    0 ;  
seg001:0072                 dw 38
seg001:0074                 db    0 ;  
seg001:0075                 db 40h
seg001:0076                 db    0 ;  
seg001:0077                 db    0 ;  
seg001:0078                 dd seg seg009+0BF10000h
seg001:007C                 dw 0DFh
seg001:007E                 db    0 ;  
seg001:007F                 db    0 ;  
seg001:0080                 db    0 ;  
seg001:0081                 db    0 ;  
seg001:0082                 db 0E8h ; F
seg001:0083                 db    1 ;  
seg001:0084                 db 0FFh ;  
seg001:0085                 db 0FFh ;  
seg001:0086 aCga_graf_ovl   db 'CGA_GRAF.OVL',0     ; Changed to an empty string in AGI256 hack
seg001:0093 aJr_graf_ovl    db 'JR_GRAF.OVL',0      ; Changed to an empty string in AGI256 hack
seg001:009F aEga_graf_ovl   db 'EGA_GRAF.OVL',0     ; Changed to 'AGIGRAF.OVL',0 in AGI256 hack
seg001:00AC aHgc_graf_ovl   db 'HGC_GRAF.OVL',0     ; Changed to an empty string in AGI256 hack
seg001:00B9 aVg_graf_ovl    db 'VG_GRAF.OVL',0      ; Changed to an empty string in AGI256 hack
seg001:00C5 aIbm_objs_ovl   db 'IBM_OBJS.OVL',0     ; Changed to 'AGIOBJS.OVL',0 in AGI256 hack
seg001:00D2 aHgc_objs_ovl   db 'HGC_OBJS.OVL',0     ; Changed to an empty string in AGI256 hack
seg001:00DF aAgidata_ovl    db 'AGIDATA.OVL',0
seg001:00EB aAgi_exe        db 'AGI.EXE',0

/////////////////////////////////////////////////////////////////////////////