Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rice!uw-beaver!ubc-cs!alberta!calgary!amc-vlsi!willy From: willy (William Gonnason) Newsgroups: comp.os.cpm Subject: Re: ZSID question Summary: Analysis of ZSID commands (mine) Message-ID: <854@amc-vlsi.UUCP> Date: 25 Nov 89 16:45:05 GMT References: <881@telesci.UUCP> Sender: news@amc-vlsi.UUCP Lines: 51 I don't have a copy of ZSID, so you may have to take the following analysis with a grain of salt. However, it's not too different in syntax from some other CP/M debuggers I've used... With the previous warning in mind, here is my analysis of your batch file: ZSID PROG.COM - invokes ZSID (Symbolic Debugger for Z80 ) and loads "PROG.COM" to transient Program Area (typically 0100H on conventional CP/M systems) A80 - assemble the following code beginning at address 0080H LD HL,6100 \ LD DE,6200 \ Relocates a large block of memory (I would LD BC,6001 / suspect the BIOS... ???) LDDR / (ie, shift 6001H bytes down by 0100H (assuming NOP the default assembler base is hexadecimal!) NOP . - end of code... P8B - got me, but I think this sets a breakpoint in ZSID at location 008BH, returning control to ZSID when address 008BH is encountered. It would appear to prevent the need for a "RET" instruction in the assembly code segment... G80 - execute code stating @ 0080H ( effectively a jump, which will relocate memory, then return control to ZSID... ) IPROG.COM - set up File Control Block for filename "PROG.COM" R - read in file set up with previous "I" command GO - execute program in TPA without reloading it (usually, this is effectively a JMP to 0100H ) - GO is a CCP command, meaning that you have exitted ZSID somehow between the "R" command and the "GO" command, although I don't see how (perhaps an embedded ^C in the batch file ???) SAVE 32 CPROG.COM - save 32 pages starting @ 0100H to the file "CPROG.COM" (one page being 256 bytes) - "SAVE" is also a CCP command, which makes me sure you have left ZSID by this point... The code is quite likely a quick and dirty way to read in a program, offset said program (somehow) and then write it out again. However, it sure plays hell on absolute addressing schemes... But, I can't offer any more information than this. Perhaps someone else on the net? - OS/2 - the other half takes EVEN MORE RAM ... [ willy@amc-vlsi.CA ] OS/2 - the other half takes EVEN MORE RAM ... [ willy@amc-vlsi.CA ]