Tyger
Moderator: Terryn
http://pastebin.com/P2WxegP2
Ruffian code I am using based off ZZT.EXE disassembly using IDA. Slightly different than what I posted before but it should match the original 100%. I know nothing about Python though. But if I did I'd commit some tasty stuff.
Ruffian code I am using based off ZZT.EXE disassembly using IDA. Slightly different than what I posted before but it should match the original 100%. I know nothing about Python though. But if I did I'd commit some tasty stuff.
I have a lot of the inner workings of ZZT documented in IDA and wrote a simulator called Lyon to verify that I understand it and that its behavior matches the original ZZT. It's not intended to compete with Tyger, but rather assist in its development. I don't know Python but would like to help in some way at least :)
I don't know if you ever plan to support Super ZZT, but I have a lot of info about that as well.
I don't know if you ever plan to support Super ZZT, but I have a lot of info about that as well.
- Smilymzx
- I hope she made lotsa spaghetti!
- Posts: 182
- Joined: Sat May 20, 2006 2:58 am
- Location: LocacoLocacoL :LoL!
RE: Saxxonpike's ZZT Disassembly?
A ZZT Disassembly? You are awesome! That is just what I need help to redo ZZT on my own,
In important business: Can I please use the disassembly for remodeling my DOS binaries or such?
(but I can distribute the binaries of the ASM file)
I was to make a new hack that I attempted years ago but never got anywhere! (because it's Graphics mode, and trying to convert my old, archived ASM/BASIC pseudo-code is a pain in the buttocks!%$#@)
This is all I need for redoing ZZT, via PM or my Email if possible,
Thank you, Will give credit if it's ever used!
EDIT: If so, Also want SuperZZT stuff, Optional for SZZT Hacks for my games!
EDIT2: Typo Fixed!
EDIT3: Added Prototype Pseudo-code, From a thread at DigitalMZX,
WARNING: This is very hard to put in QB45, I tried, but sucked at it:
EDIT 4: Woohoo! 50th Post,
In important business: Can I please use the disassembly for remodeling my DOS binaries or such?
(but I can distribute the binaries of the ASM file)
I was to make a new hack that I attempted years ago but never got anywhere! (because it's Graphics mode, and trying to convert my old, archived ASM/BASIC pseudo-code is a pain in the buttocks!%$#@)
This is all I need for redoing ZZT, via PM or my Email if possible,
Thank you, Will give credit if it's ever used!
EDIT: If so, Also want SuperZZT stuff, Optional for SZZT Hacks for my games!
EDIT2: Typo Fixed!
EDIT3: Added Prototype Pseudo-code, From a thread at DigitalMZX,
WARNING: This is very hard to put in QB45, I tried, but sucked at it:
Code: Select all
; Arguments: cx = character-cell X, cy = character-cell Y
; c = character code, f = foreground color, b = background color
videooffset = ((cy * 80) * 14) + cx; base address of the character cell on each plane
videobase = $A000; the start of EGA memory
characterseg = (? >> 4); where ? = the base address of your character set
characterbase = (? & $0F) + (c * 14); as above
for i = 0 to 13
DEF SEG characterseg; or however this is represented in x86 assembly
load A, (characterbase + i); the register names are all dummies here, use whatever works
DEF SEG videobase; set to write to video RAM
for j = 0 to 3
out $3C4, 2; a bit of voodoo programming to select the plane to access, since low-level EGA documentation
out $3C5, (1 << i); seems very hard to find
if (f & (1 << j) != 0) and (b & (1 << j) != 0) then store $FF, (videooffset + lineoffset)
else if (f & (1 << j) != 0) then store A, (videooffset + lineoffset)
else if (b & (1 << j) != 0) then store (A XOR $FF), (videooffset + lineoffset)
else store $00, (videooffset)
next
videooffset += 80
next
I didn't look into how ZZT initializes its graphics mode. That isn't really the point of my research and I didn't bother documenting those parts of the disassembly. The main focus was discovering exactly how elements interact in the game world. How it is rendered to the screen is entirely independent of ZZT's behavior. This behavior (main game loop, element interactions) will be documented in great detail soon.Smilymzx wrote:A ZZT Disassembly? You are awesome! That is just what I need help to redo ZZT on my own,
In important business: Can I please use the disassembly for remodeling my DOS binaries or such?
(but I can distribute the binaries of the ASM file)
I was to make a new hack that I attempted years ago but never got anywhere! (because it's Graphics mode, and trying to convert my old, archived ASM/BASIC pseudo-code is a pain in the buttocks!%$#@)
This is all I need for redoing ZZT, via PM or my Email if possible,
Thank you, Will give credit if it's ever used!
Additionally, if you don't know much about 8086 assembly, you won't find the disassembly useful at all.
- Smilymzx
- I hope she made lotsa spaghetti!
- Posts: 182
- Joined: Sat May 20, 2006 2:58 am
- Location: LocacoLocacoL :LoL!
I know x86 Assembly already for some of my other hacks, Just QBasic variants or such does not have any of the routines to do the inline assembly,Saxxon wrote: I didn't look into how ZZT initializes its graphics mode. That isn't really the point of my research and I didn't bother documenting those parts of the disassembly. The main focus was discovering exactly how elements interact in the game world. How it is rendered to the screen is entirely independent of ZZT's behavior. This behavior (main game loop, element interactions) will be documented in great detail soon.
Additionally, if you don't know much about 8086 assembly, you won't find the disassembly useful at all.
Here is My trade/contribution: info on ZZT/SZZT Graphics in detail, and info on Text Attribute Assembly,
Default Font Size: 8x14, 80 column ZZT, 40 column SZZT,
Default is at Seg 0xB800, Graphics (Text mode) 03h (Depends on Color mode)
Unless there is any 16bit x86 BASIC variant that is freeware or open-source that is compatible with both inline ASM and (Q)BASIC syntaxes, I'm all out of luck, Which makes that useful a lot for the Disassembly!
Also, I know the store and load parts require MOV and such. Characters in ZZT use a CMP instruction of some sorts and/or adds/subtracts/replaces where applicable,
Example: It is possible to convert White text to a REAL DkWhite on White BG: B8 00 0F to B8 00 7f if you know where the text routines are
In short- White (Black BG) text is seperate from Colored BG text!
if x86 is anything like 6502, CMP is essentially a subtraction except it only sets flags and doesn't store the result.Smilymzx wrote:Also, I know the store and load parts require MOV and such. Characters in ZZT use a CMP instruction of some sorts and/or adds/subtracts/replaces where applicable
So you are working on commenting the game logic saxxon?
*POW* *CLANK* *PING*
Yup. I've located all the major functions related to logic in ZZT and Super ZZT. The game loops for the two are very different and some of the element logic is also different. Both games will be included in the document. It'll be rather large, and I'm sure parts of Tyger will have to be rewritten to match it.Commodore wrote:So you are working on commenting the game logic saxxon?
- Dr. Dos
- OH YES! USE VINE WHIP! <3
- Posts: 1772
- Joined: Tue Mar 11, 2003 12:00 am
- Location: Washington
Making more work I see >:(
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter
Apologies for the old post you may have just read.
Follow Worlds of ZZT on Twitter
Apologies for the old post you may have just read.
- premchai21
- draco somniculosus
- Posts: 20
- Joined: Thu Oct 01, 2009 1:00 am
(Admittedly this is straying somewhat from the original thread topic.)
I d'no; to me that takes most of the fun out of it. Yes, I could have gone through and disassembled the ZZT executable by now, but it would have been boring and not very meaningful. Part of the point is to see what you can derive from external behavior only, rather like those "blackbox" puzzles. (E.g., deriving what I've termed caesural reëntry and what it would look like underneath regarding when the player tile gets stacked back onto the board.)
Oh well. I suppose I should have known it would happen. I haven't decided whether I'll look at it should I ever get anywhere further with ZLT, as opposed to being busy with things that are in all likelihood more useful and meaningful…
(But I'll still have the bit that compiles the ZZT-OOP down to a machine representation with interned symbols and 32-bit instruction words. Bwahahahaha. Though it's going to make handling #zap restart trickier.)
I d'no; to me that takes most of the fun out of it. Yes, I could have gone through and disassembled the ZZT executable by now, but it would have been boring and not very meaningful. Part of the point is to see what you can derive from external behavior only, rather like those "blackbox" puzzles. (E.g., deriving what I've termed caesural reëntry and what it would look like underneath regarding when the player tile gets stacked back onto the board.)
Oh well. I suppose I should have known it would happen. I haven't decided whether I'll look at it should I ever get anywhere further with ZLT, as opposed to being busy with things that are in all likelihood more useful and meaningful…
(But I'll still have the bit that compiles the ZZT-OOP down to a machine representation with interned symbols and 32-bit instruction words. Bwahahahaha. Though it's going to make handling #zap restart trickier.)
- Dr. Dos
- OH YES! USE VINE WHIP! <3
- Posts: 1772
- Joined: Tue Mar 11, 2003 12:00 am
- Location: Washington
Honestly I appreciate the effort!
I just feel bad because other projects and also things for school since I'll be graduating this april have been taking a lot of time and I've been neglecting work on Tyger for months.
I just feel bad because other projects and also things for school since I'll be graduating this april have been taking a lot of time and I've been neglecting work on Tyger for months.
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter
Apologies for the old post you may have just read.
Follow Worlds of ZZT on Twitter
Apologies for the old post you may have just read.