From: French Luser Newsgroups: comp.os.cpm Subject: To count one's Z80.LIB files... Date: Sat, 09 Sep 2006 13:47:54 +0200 Message-ID: <65a5g2lv8emjmit23g7hteetr17i0hht30@4ax.com> References: <44f6f883$1@news.starhub.net.sg> <44fa4d8c@news.starhub.net.sg> <44feee00@news.starhub.net.sg> <45012296$0$5103$ba4acef3@news.orange.fr> X-Newsreader: Forte Free Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0636-3, 08/09/2006), Outbound message X-Antivirus-Status: Clean Lines: 127 Organization: les newsgroups par Orange NNTP-Posting-Date: 09 Sep 2006 13:47:55 CEST NNTP-Posting-Host: 80.11.68.242 X-Trace: 1157802475 news.orange.fr 27411 80.11.68.242:63693 X-Complaints-To: abuse@orange.fr Z80LIB.TXT ---------- "To count one's Z-80.LIB files (before they are assembled)" by Emmanuel ROCHE Ok. So, it was expected that, tonight, I would finally be able to answer the interesting question of Yong Lak: "Is it possible to emulate M80's PHASE and DEPHASE pseudo-ops under RMAC?" Unfortunately, I had a problem with the computer that I use to write my messages to the comp.os.cpm Newsgroup (using WordStar 4 or VDE for TXT files), so I gave it to a computer shop. One week later, I got it as planned... except that the hard disk (the most important piece of the computer) was no longer working as expected! So, tonight, I spent a good deal of time debugging the hardware, a thing that I rarely do, prefering to give my computers to a friend of mine, who is the most experienced electronician that I know. Unfortunately, this time, I had not enough time (he lives 500 kilometers away), so I was obliged to do it myself. After erasing the Windows and MS-DOS directories, installing DR-DOS 7.03, and playing with FDISK and VDISK, I finally have a computer... but is it working? (It would be a pity to lose all my files...) Let us review the problem. Among other things, Yong Lak published his boot code. So, I retyped it. It was containing 2 MACLIB pseudo-ops (some other assemblers use INCLUDE). One was involving Z80.LIB, the well-known library of macros from Digital Research enabling MAC and RMAC to generate Z-80 code like LDIR (MAC and RMAC are both 8080 assemblers, as is M80). The second was named JR180: obviously some macros dealing with the Z80S180, since the code was containing names such as CBAR, BBR, and CBR. (Not much comments, yong!) So, I said: "Easy, find a copy of Z80.LIB, then assemble with dummy CBAR, BBR, and CBR values, then write the message. What could be simpler?" So, to check if my computer was running correctly, I typed: "find z80.lib" at the system's prompt. (I must explain that I don't use the standard MS-DOS FIND (searching for strings in files) but a FINDFILE program because (according to the system) there are 18,000 files in 900 directories. The computer shop owner told me that I was his record holder: normally, he deals with companies which only have one accounting program under Windows. He had never seen before an individual with so many programming languages and documents in his computer. And everything in characters, not huge giant, inefficient PDF files... One of those directory happens to be the DRIPAK file that is available on the Internet. FIND also found 2 other copies, one in the BIOS of CP/M Plus for the North Star Horizon of Howard Harte, the other in the directory of UNLOAD Version 2.0. C:\DRIPAK\MAC\Z80.LIB 9856 bytes C:\DRIPAK\MAC-RMAC\Z80.LIB 6016 bytes C:\DRIPAK\RMAC\Z80.LIB 6016 bytes C:\DRIPAK\CPM_2-2\SYSTEM\Z80.LIB 9984 bytes C:\DRIPAK\CPM_3-0\SOURCES\Z80.LIB 5904 bytes C:\DRIPAK\MPM_2\DRI\Z80.LIB 6016 bytes C:\NSTAR\BIOS3\Z80.LIB 5904 bytes C:\TEMP\UNLOAD\Z80.LIB 9856 bytes So, big problem: I was expecting to find one Z80.LIB file, and I discover, at first sight, at least 4 versions of it! From smallest to biggest: 5904 bytes (2 copies) 6016 bytes (3 copies) 9856 bytes (2 copies) 9984 bytes (1 copy) So, I copied copies of them (FIRST.LIB, SECOND.LIB, etc), then compared them with my COMPARE program (what would I be able to do, without it?). It turns out that: 1) The difference between the 5904-bytes and 6016-bytes files is that the 5904-bytes file ends with 00H bytes filling the "slack bytes" (at the end of a file, after the CP/M "end-of-file" character), while the 6016-bytes file ends with a string of 1A bytes, filling the next record. (Those smaller files have the comments, at the beginning of the files, removed, obviously to speed assembly. 00H files were probably generated by a non-CP/M editor, while 1AH files were, obviously, generated by a CP/M editor.) 2) The difference between the 9856-bytes and 9984-bytes files is that the 9984-bytes file contains a handful of control characters that are not present in the 9856-bytes file. (VDE displays control characters on screen, so it was very easy to find them and erase them. Recommended if you are still using MS-DOS. In addition, VDE used to run under CP/M -- where I discovered it.) Conclusion ---------- If you are using Z80.LIB to generate Z-80 opcodes using Digital Research's MAC and RMAC, be sure to use the 9856-bytes long file (found in the DRIPAK, in the MAC directory -- probably a copy of the work disk of Gary Kildall). (Control characters can produce very hard to find subtle errors in macro-assemblers. Me, twenty years ago, I spent several hours before discovering that, after typing an "ENDM", I had typed a "space", before pressing the "RETURN" key... Of course, this space was not appearing when I was displaying the source code with ED, or printing the file on my daisy-wheel printer! I was obliged to dump the file -- fortunately, I had managed to find where in the listing things were going wild -- before understanding the source of the bug. So, beware of spaces after "ENDM" pseudo-ops!) Time to go to bed. Maybe this week-end?... Yours Sincerely, "French Luser" EOF