Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!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 3) Message-ID: <1991May10.200724.4592@magnus.acs.ohio-state.edu> Date: 10 May 91 20:07:24 GMT Sender: news@magnus.acs.ohio-state.edu Organization: The Ohio State University Lines: 276 Originator: fseipel@bottom.magnus.acs.ohio-state.edu Nntp-Posting-Host: bottom.magnus.acs.ohio-state.edu Otherwise, it is double density (256 byte sectors). This method is not perfect. If you have a Percom drive you should read sector 1 (remember it is always 128 bytes) before getting the configuration to ensure accuracy. Reading sector one does not screw up other drives so it is safe to do under any conditions. Enhanced density disks can confuse the US Doubler and XF551 drives. I personally HATE enhanced density... One of my favorite snivels is "Why couldn't Atari have just used real double density???" (Imagine a loud voice with a strong nasal whine here.) Now that you know how to GET the configuration, you know how to SET it too. You set the DCB up with the same values except for the command which is $4f (79) and DSTATS which is $80 (128). The only values you can set are: Sectors per track (18 for single or double, 26 for enhanced), number of heads (0 or 1), density (0 or 4), and bytes per sector (128 or 256). Note that enhanced density requires a 4 in the density byte and 128 byte sectors as well as 26 sectors per track. The most useful place to use the set configuration command is immediately before issuing a format command. This ensures that the drive will for sure be formatted in the density you want. Some DOSes don't even do this. (Ever try to format a disk with DOS 2.0 that has previously been formatted in double density? Ugh!) The next command to mention is the STATUS command ($53 or 83 decimal). This can also be used to get the density of the drive. Again, the US Doubler can get confused and lie if enhanced density disks are used. (I HATE enhanced .....) To use this command you must set the DCB up to receive 4 bytes from the drive. The bytes received are described as follows: Byte Description ------------------ 1 Command status 2 Controller chip status 3 Timeout value for formatting 4 Unused (current track # for Indus drives) If the first byte of the data returned is greater than 127 then the drive is in enhanced mode (supposedly). Otherwise, if bit 5 is set the drive is in double density. Else the drive is in single density. If bit 3 is set the disk is write protected. Bits 0-2 are error bits. If any are set then some error has occured. Reading and writing sectors is the next thing on the agenda. To read a sector set the DCB up to receive data. Poke the low byte of the sector number into DAUX1 and the high byte into DAUX2. Then call SIOV and your sector will be read into memory - assuming the drive door is closed and there is a readable disk in there and everything. To write a sector do the same thing but set up DCOMND and DSTATS to send data instead of receive it. Finally, let's look at the format command. You must set the DCB up to receive data when you format a disk. The drive will return a bad sector list when the format is completed if successful. So poke a 64 into DSTATS and the address you want the bad sector list returned to in DBUFLO/HI. Also, poke a 0 in DBYTLO and a 1 in DBYTHI since the list can be 256 bytes long. Immediately after the format command, check for an error as described below. Then check the first two bytes of the bad sector list buffer. They should both be 255. If they aren't then there are bad sectors on the disk. Errors! Well, they are bound to happen sometime. Immediately after your call to SIOV you should PEEK(DSTATS) and make sure the value there is not less than zero. If it IS greater than 127 then an error has occured. If this happens, the value in DSTATS is the same value that would normally show up in location 195 if BASIC had generated an error. BASIC will NOT see or TRAP any errors that happen when you talk to the disk drive through the SIOV. So, make sure you check for them yourself. Don't get discouraged if your first attempt at doing direct sector I/O isn't successful. It took me some time to get comfortable with this method of communicating with periphials and I made some dandy mistakes too. I have even managed to format a partition or two on my hard drive. It'd probably be a pretty good idea to make sure you have a scratch disk in the drive when you do your experimenting.... Anyone interested in the IOCB's? There's 8 of those! Aw... maybe next month... A TRIO FOR TURBO BASIC ====================== by John Picken, GCACE Here are three short and easy programs. The first is a "fix", the second is a MyDOS 4.5 "mod" and the third is a new utility. Note that all three programs will only run under Turbo BASIC which is readily available to any user group member. There are two reasons for this: first to demonstrate some of Turbo's fine features and, more importantly, programming in Turbo is about ten times easier than in Atari BASIC (laziness wins again). My original version of MYDOS RAMDISK AUTOLOADER, that was published in the July PSAN, fits the expression "too smart by half". It works fine with 256K because, on the 256XL, an unformatted RAMdisk shows "65535 FREE SECTORS" which tells the loader formatting is needed. The rub is that an unformatted RAMdisk with the 320XE shows "255 FREE SECTORS". Since this could mean a nearly full, formatted RAMdisk, the loader doesn't format. Program A fixes the existing autorun file for the 320XE; it replaces the "smart" code with "smarter" NOP's so the loader formats any time DUP.SYS is not found in the RAMdisk. Apologies to any 320XE owners who have been "blue-ifying" the air. Program B makes a modification to MyDOS 4.5 DUP.SYS which results in different default colours and keyboard parameters. I find a white on black display to be more readable on a monochrome monitor but you are free to select any colors you like. The values for the keyboard produce a fast, quiet cursor; to change them, refer to page 208 in MAPPING THE ATARI. If you do something that results in a GRAPHICS 0, (Copy to/from S: or E:, load Turbo BASIC, etc.) the colors revert to normal but the keyboard parameters remain as set until you hit RESET. The modification uses two loops which is why COLOR3 and HELPFG are included - just leave them at 70 and 0. All internal changes are made so that your modified DUP will be written if you "Write DOS Files" from DUP. Program C produces a short machine language file that switches BASIC off or on. It is a toggle - if BASIC is on, it will be turned off; if off, it will be turned on. You can load the program anytime and/or, include it in an autorun file (it should be first with others appended to it). As an autorun, it has the effect of reversing the OPTION key so that you would need to press OPTION to enable BASIC at boot. 10 REM Program A: 320XE RDLoader Fix 11 DIM PRG$(700),JSR_AFP$(3) 12 PRG$(700)=CHR$(0) 13 JSR_AFP$=CHR$(32) 14 JSR_AFP$(2)=CHR$(0) 15 JSR_AFP$(3)=CHR$(216) 16 OPEN #1,4,0,"D1:AUTORUN.SYS" 17 TRAP #EOF 18 BGET #1,ADR(PRG$),LEN(PRG$) 19 # EOF:CLOSE 20 PRG$=PRG$(1,DPEEK($0358)) 21 PATCH=INSTR(PRG$,JSR_AFP$) 22 FOR B=0 TO 11 23 __PRG$(PATCH+B,PATCH+B)=CHR$(234) 24 NEXT B 25 OPEN #1,8,0,"D1:AUTORUN.SYS" 26 BPUT #1,ADR(PRG$),LEN(PRG$) 27 END 10 REM Program B: Modifier for 11 REM . MyDOS 4.5 DUP.SYS 12 DIM DUP$(7000) 13 DUP$(7000)=CHR$(0) 14 TRAP #EOF 15 OPEN #1,4,0,"D:DUP.SYS" 16 BGET #1,ADR(DUP$),7000 17 # EOF:CLOSE 18 DUP$=DUP$(1,DPEEK($0358)) 19 REM Code changes inside DUP 20 RESTORE #IN_MODS 21 FOR COUNT=1 TO 14 22 __READ INDEX,BYTE 23 __DUP$(INDEX,INDEX)=CHR$(BYTE) 24 NEXT COUNT 25 # IN_MODS:DATA 5,78,30,32 26 DATA 31,50,32,67 27 DATA 326,52,1682,79 28 DATA 1690,79,2385,78 29 DATA 2389,26,2393,5 30 DATA 2779,79,2986,79 31 DATA 5839,54,5840,48 32 REM Code added to end of DUP 33 RESTORE #ADD_MODS 34 FOR COUNT=6639 TO 6659 35 __READ BYTE 36 __DUP$(COUNT)=CHR$(BYTE) 37 NEXT COUNT 38 # ADD_MODS:DATA 162,4,189,70 39 DATA 67,157,196,2 40 DATA 189,74,67,157 41 DATA 216,2,202,208 42 DATA 241,142,28,2 43 DATA 96 44 REM Default bytes at end of DUP 45 DUP$(6660)=CHR$(12):REM Colr1 Text 46 DUP$(6661)=CHR$(0):REM Colr2 Bak 47 DUP$(6662)=CHR$(70):REM Color3 48 DUP$(6663)=CHR$(0):REM Col4 Border 49 REM Ref. Mapping The Atari p.208 50 DUP$(6664)=CHR$(18):REM KRPDEL 51 DUP$(6665)=CHR$(2):REM KEYREP 52 DUP$(6666)=CHR$(1):REM NOCLIK 53 DUP$(6667)=CHR$(0):REM HELPFG 54 OPEN #1,8,0,"D:DUP.SYS" 55 BPUT #1,ADR(DUP$),6667 56 END 10 REM Program C: Makes Basic Toggle 11 CLS :? :? :? "BASIC.COM Creator" 12 ? :? "Checking data lines":? 13 TRAP #EOD1 14 DO 15 __B=B+1 16 __READ A 17 __CS=CS+A*B 18 LOOP 19 # EOD1:RESTORE 20 IF CS=211369 21 __? :? "__Data OK. Insert disk," 22 __? "push START to write file." 23 __# KEY:ON PEEK(53279)<>6 GO# KEY 24 __TRAP #DISK_ERROR 25 __OPEN #1,8,0,"D1:BASIC.COM" 26 __TRAP #EOD2 27 __DO 28 ____READ A 29 ____PUT #1,A 30 __LOOP 31 __# EOD2:CLOSE 32 __? :? "BASIC.COM created." 33 ELSE 34 __? " Sorry, data incorrect." 35 __# RETRY 36 __? "Please check and re-run." 37 ENDIF 38 END 39 # DISK_ERROR:? CHR$(253) 40 ? " DISK ERROR #";ERR:GO# RETRY 41 DATA 255,255,0,1,54,1,162,160 42 DATA 173,1,211,73,2,141,1,211 43 DATA 41,2,141,248,3,240,2,162 44 DATA 192,134,106,162,0,142,75,3 45 DATA 169,72,141,68,3,169,196,141 46 DATA 69,3,169,12,141,74,3,141 47 DATA 66,3,32,86,228,169,3,141 48 DATA 66,3,76,86,228,226,2,227 49 DATA 2,0,1 (This article provided courtesy of the Garden City ACE, P.O. Box 6578, Victoria, B.C., Canada V8P 5N7.) XEP80 STATUS LINE ================= by Michael D. Bjorkman, S*P*A*C*E The XEP80 has a number of special features, not all of which were demonstrated in the DEMO80.BAS program which comes on the handler disk. One of these features is a one line text window below the 24th and last line of the normal 80 column screen display. This extra text line is called the Status Line and is handy for printing error messages, prompting for input, etc. for those cases where you don't want to mess up the regular 24 lines of text. The Status Line is not accessible from BASIC using the PRINT command. Therefore I've written a short ML routine which can be called with a USR command. My program will only print messages to the status line and will not accept input from the status line. That is left as an exercise for the reader. Listing 1 is a short demo I've written which uses my Status Line ML routine. The program first initializes the ML string, then lists half of the program to the screen, then prints a message to the status line, then lists some more of the program, and then erases the status line. Listing 2 is the UNICHECK checksum file for checking your typing. Do not type Listing 2, it is not part of the program. Listing 3 is the source code for the ML string. It was written to be relocateable so that it could be placed in a BASIC string. If you want to use the ML string in your own programs, then you will need lines 110, 120, 210, 220, and 1000-1080. The length of the message which can be printed to the status line should only be limited to the