Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!pacbell.com!iggy.GW.Vitalink.COM!widener!dsinc!ub!csn!magnus.acs.ohio-state.edu!fseipel From: fseipel@magnus.acs.ohio-state.edu (Frank E Seipel) Newsgroups: comp.sys.atari.8bit Subject: Z-Magazine Issue #192 (Part II) Message-ID: <1991May10.150955.1651@magnus.acs.ohio-state.edu> Date: 10 May 91 15:09:55 GMT Sender: news@magnus.acs.ohio-state.edu Organization: The Ohio State University Lines: 233 Originator: fseipel@bottom.magnus.acs.ohio-state.edu Nntp-Posting-Host: bottom.magnus.acs.ohio-state.edu This is a continuation of Z-Magazine Issue #192 (see previous article). A.C.E.C. (614)-471-8559 3oo/12oo/24oo bps Pandora (614)-471-9209 3oo/12oo bps Thousands of 8-bit downloads, full access on first call. Thirty Pounds overseas by airmail) can you afford NOT to try it? ---------------------------------------------------------- To: SynTax, 9 Warwick Road, Sidcup, Kent DA14 6LJ ENGLAND Please send me the current issue/ the next six issues of SynTax in colour/mono Cheques/POs etc should be made payable to S Medley - all payment in Sterling please. Name.................................................... Address................................................. ............................... Postcode................ THE ABC COMPILER ================ by Mark Farmer, S*P*A*C*E (Reprinted from the Puget Sound Atari News, May 1990) If you 8-Bit Atari users would like to speed up your Basic programs so that they run like the high speed and memory efficienct compiled languages such as Forth, "C", Action, or Assembler then, do I have a Basic compiler for you! Monarch Data Systems has a Basic compiler called the ABC Compiler that will translate your Basic programs into compact pseudo-code, also known as p-code. Once compiled this p-code can be executed like any other binary program. ABC compiled programs run from four to twelve times faster than the original Basic program, depending on how well the source code is written. This makes it possible to use compiled Basic for professional game developement and other speed critical applications. I first bought the ABC Compiler back in 1983. I own version 1.03, but know that it has been upgraded twice since I purchased it and now is at version 1.05. The ABC Compiler was the best back then and is the only Basic compiler out for the Atari 8-bit (the DataSoft and MGM compilers are no longer made). Even if these two compilers were still out the ABC Compiler is the easiest to use. I am very happy with the ABC Compiler (a job hard to do, ask my wife). The ABC Compiler is cheaper now than it was when I originally purchased it ($50.00). The compiler comes with the program disk and a well put together manual that tells you how to use it. I highly recommend this Basic compiler. If you have any questions about the ABC compiler you can send a letter to me at: SSG Mark S. Farmer 156-52-8733 A Co. 1/506 Inf APO, SF 96251 The address and phone number for Monarch Data Systems is as follows: Monarch Data Systems, Inc. 25 Cambridge Ct. Morganville, NJ 07751 Phone: (201) 591-9774 THE 8-BIT DCB A Programming Tutorial ============= by Dan Knauf of S*P*A*C*E (Reprinted from the Puget Sound Atari News, March 1991) Something that a lot of people seem to have a hard time learning to understand is the Device Control Block (DCB) in the Atari Computer. Actually, there are two of them - the one available to any programmer located in page 3 (memory location $300 or 768 in decimal) and the one located in zero-page that is used by the operating system and DOS. For now, we'll just worry about the one in page 3. The main purpose of the DCB is to provide a uniform method of talking to any periphials attached to the computer. In the 8-bit Atari, this includes items attached to the SIO port and (for XL's and XE's) the expansion port. This includes such interesting devices as disk drives, cassette drives, hard drive interfaces, and the 850 interface to name a few. To keep this as simple as possible, we'll just talk about disk drives. This information pretty much applies to all periphials though. The DCB is a table containing 12 bytes of information that is required by the operating system to talk to any and all these periphials. This info includes a device identifier (to specify D:, P:, etc.), a device unit number, a command byte, a status byte, a buffer address, a timeout byte, a buffer size, two auxilliary bytes, and one spare (unused) byte. Here is a list of the addresses and the official Atari names of each of these fields: * Hex Dec Name Purpose ------------------------- *$300 768 DDEVIC Buss ID *$301 769 DUNIT Unit number *$302 770 DCOMND Command *$303 771 DSTATS Status *$304 772 DBUFLO Lo byte of buffer address *$305 773 DBUFHI Hi byte of buffer address *$306 774 DTIMLO Timeout value *$307 775 DUNUSE Spare byte - unused *$308 776 DBYTLO Lo byte of buffer size *$309 777 DBYTHI Hi byte of buffer size *$30A 778 DAUX1 Auxilliary byte #1 *$30B 779 DAUX2 Auxilliary byte #2 Once this table has been set up with the correct data, all that is necessary to talk to a periphial is a call to the operating systems Serial Input Output Vector (SIOV) located at address $E459 (58457 decimal). So if it's so easy, what goes in the table? Well, here is an expanded description of each item in the DCB and, where appropriate, legal values and their purpose. DDEVIC is used to select a particular periphial. For now we'll just worry about talking to a disk drive. To do that DDEVIC must contain a $31 (49) which is the ID value for disk drives. DUNIT is used to select the unit number. To talk to drive one, a value of 1 must be in DUNIT. For drive two, a 2 and so on. DCOMND is the command to be executed. There are several valid commands, some of which are: * Format $21 33 * Format enhanced $22 34 (1050 compatibles only) * Get configuration $4E 78 * Set configuration $4F 79 * Put (no verify) $50 80 * Read $52 82 * Status $53 83 * Write (w/verify) $57 87 There are some other commands but these are the most useful and will allow you to do just about anything with a disk drive. DSTATS is an interesting part of the table and the one I tended to forget about the most when I was learning how to use the DCB. First, it holds the status of the operation after a call to SIOV. If it is greater than 127 an error has occured and the number contained here is the Atari number for the error encountered. For example, a 138 here means the device addressed is not on-line (device time-out). Second, (the part I kept forgetting) it is used to indicate the direction of any data transfer to be peformed during the execution of the command. To send data do the drive, POKE $80 (128) here. To receive data from the drive POKE $40 (64). For commands not involving any data POKE a 0 in this location. Virtually all commands involve the transfer of some data so a zero isn't used here too often. DBUFLO and DBUFHI contain the address of the data buffer. If you are sending data, it will be sent from this address. If you are receiving data it will received at this address. Example: HI=INT(BUFADR/256):LO=BUFADR-256*HI:POKE DBUFLO,LO:POKE DBUFHI,HI. DTIMLO is used to set the amount of time you want to system to wait on the periphial in seconds. I use a value of 7 a lot here. The default value is something over 30 seconds and I am an impatient sort. Usually if 7 seconds isn't long enough 30 isn't going to be either. The exception is the format command. I use a value of $F8 (248) because the format takes lotsa time. DBYTLO and DBYTHI are used to indicate the number of bytes to transfer. This usually 128 (for single or enhanced density disks) or 256 (double density). Example: HI=INT(SIZE/256):LO=SIZE-256*HI:POKE DBYTLO,LO:POKE DBYTHI,HI. DAUX1 and DAUX2 contain the number of the sector to be read or written to. As with all the two byte fields this data is stored in 6502 format. Ie., the low byte is in DAUX1 and the high byte is in DAUX2. For example, to read sector 1 DAUX1 would contain a 1 and DAUX2 would be zero. Example: HI=INT(SECTOR/256):LO=SECTOR-256*HI:POKE DAUX1,LO:POKE DAUX2,HI. This concludes the description of the DCB. Now let's look at some of the commands and how they are used. First comes the get configuration command. Before doing any reading or writing to the disk you must know what density it is in so you know whether to write 128 or 256 bytes to a sector. The exception to this is sectors 1-3. They are ALWAYS 128 bytes long. All drives I know of except the 810 contain a 12 byte configuration table that is user alterable. This table sets the density among other things. Here is a listing of the drive configuration table. *Byte # Purpose* * 1 Number of tracks * 2 Step rate * 3 Sectors per track - Hi byte * 4 Sectors per track - Lo byte * 5 number of heads -1 * 6 Density 0=single 4=Double or Enhanced * 7 Bytes per sector Hi byte * 8 Bytes per sector Lo byte * 9 Drive present flag * 10 Not used (Stock XF551 returns a $41 here) * 11 Not used * 12 Not used Notice that the two-byte values are NOT in 6502 format. The high byte of these values comes first! Another thing to be aware of is that hard drives use some of these locations a little differently. The number of heads is invalid for hard drives. And the first two bytes of the table contain the total number of sectors in the partition instead of tracks and step rate. I know this to be true of the BlackBox interface and think it holds true for the MIO also. To read the table from the drive, you must set up the DCB to receive 12 bytes of data at an address you specify. Then poke $4E (78) into DCOMND and call SIOV. Here is a one line call to SIOV from BASIC. X=USR(ADR("hLYd")):REM the 'd' is inverse. Once you have read the configuration look at byte 7. It should be either a 1 or a 0. If it is 0 the disk is single or enhanced density.