💾 Archived View for mirrors.apple2.org.za › archive › apple.cabi.net › FAQs.and.INFO › DOSandProDOS … captured on 2024-12-17 at 12:54:01.

View Raw

More Information

⬅️ Previous capture (2023-01-29)

-=-=-=-=-=-=-

Path: news1.icaen!news.uiowa.edu!iagnet.net!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!newsfeed.internetmci.com!128.223.220.25!news.uoregon.edu!!nparker
From: nparker@inferno.uoregon.edu (Neil Parker)
Newsgroups: comp.sys.apple2.programmer
Subject: Re: how to read a DOS 3.3 catalog?
Date: 22 Sep 1997 06:34:30 GMT
Organization: I need to put my ORGANIZATION here.
Lines: 79
Message-ID: <6053hm$6ec$1@pith.uoregon.edu>
References: <jstrout-ya02408000R1909970826360001@news.ucsd.edu>
NNTP-Posting-Host: ssil.uoregon.edu
X-Trace: pith.uoregon.edu 874910070 6604 nparker 128.223.108.115
X-Complaints-To: usenet@news.uoregon.edu
Originator: nparker@

In article <jstrout-ya02408000R1909970826360001@news.ucsd.edu>,
Joseph J. Strout <jstrout@ucsd.edu> wrote:
>Short question: How can I get a listing of files on the DOS 3.3 disk from
>my Applesoft program?

A short question, but one needing a long answer.  Alas, DOS 3.3 doesn't
provide any easy way for a BASIC program to read a disk's catalog.

Below is a program that shows one trick that can be used to do it.  This
works by setting up a machine-language routine to capture output into a
memory buffer, and then does a CATALOG into the buffer.  When it's done it
prints out the contents of the buffer to prove that it got the right
information...you'll probably want to do something more complex than just
print it out.

10 D$ =  CHR$ (4):A = 768
20  READ X: IF X >  = 0 THEN POKE A,X:A = A + 1: GOTO 20: REM Poke ML
30  DATA 134,53,162,0,129,6,230,6,208,2,230,7,166,53,96,145,40,169,160,96,-1
40  POKE 54,0: POKE 55,3: POKE 56,15: POKE 57,3: CALL 1002: REM Connect
     our special I/O routines
50  POKE 6,0: POKE 7,64: REM Start buffer at 16384 ($4000 hex)
60  PRINT D$"CATALOG": REM Store the catalog in memory
70  A =  PEEK (6) + 256 *  PEEK (7) - 1: REM Find end of buffer
80  PRINT D$"PR#0": PRINT D$"IN#0": REM Restore normal I/O routines
90  FOR X = 16384 TO A: PRINT  CHR$ ( PEEK (X) - 128): NEXT: REM Print buffer

The machine language in line 30 disassembles as follows:

BUFPTR  EQU 6               ;Pointer to user's buffer
BASL    EQU $28             ;Pointer to current screen line
YSAV1   EQU $35             ;Place where COUT can save a register
;
; Replacement output routine:  store char in buffer, advance buffer ptr
;
COUTX   STX YSAV1           ;Preserve X
        LDX #0
        STA (BUFPTR,X)      ;Store character in buffer
        INC BUFPTR          ;Advance buffer pointer
        BNE L1
        INC BUFPTR+1
L1      LDX YSAV1
        RTS
;
; Replacement input routine:  pretend a space character was read
;
KEYIN1  STA (BASL),Y        ;Remove cursor from screen
        LDA #$A0            ;Simulate space character from kbd
        RTS

(The replacement output routine is needed to prevent the catalog from
pausing after every 22 lines.)

By the time line 80 is done, the catalog is in memory starting at location
16384 and ending at location "A".  The only thing you'll have to worry
about is running out of memory--a full catalog (105 files) takes slightly
over 4000 bytes.  (But some disks--such as disks that have been modified by
the "TWO-TRACK CAT" program from Beagle Bros' "Silicon Salad"--may need
more memory than that...the "Silicon Salad" disk itself requires over 4600
bytes.)

The catalog data in memory consists of exactly the characters that would
have been printed out on the screen in a normal CATALOG command--a couple
of carriage returns, a "DISK VOLUME 254" header, another couple of carriage
returns, and a list of file types, sizes, and names, all in ASCII with the
high bits set.

Once you've got the catalog in memory, it might help to print it out to a
text file.  Then other programs that want to read the catalog can do so by
opening the text file and reading the filenames with INPUT.

BTW, don't run this program under ProDOS.  The techniques it uses do work
under ProDOS, but not without modification.

               - Neil Parker
-- 
Neil Parker, nparker@inferno.uoregon.edu (temporarily, until cie-2.uoregon.edu
comes back up)

Unsolicited commerical e-mail is not welcome, and will be discarded unread.