Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!jgreco
From: jgreco@csd4.milw.wisc.edu (Joe Greco)
Newsgroups: comp.sys.cbm
Subject: Re: Where's the load file name?
Message-ID: <2901@csd4.milw.wisc.edu>
Date: 13 Jun 89 17:30:44 GMT
References: <7000016@silver>
Sender: news@csd4.milw.wisc.edu
Reply-To: jgreco@csd4.milw.wisc.edu (Joe Greco)
Organization: Not around here. Totally Unorganized.  A Real Mess.
Lines: 46

In comp.sys.cbm article <7000016@silver>, rschofie@silver.bacs.indiana.edu wrote:
]  I recently asked if anyone knew the name of the file that the Final
]Cartridge III trys to load through its "DLINK" hook. Since I didn't
]get any responses, I will rephrase the question.
]
]  Where, if anywhere, is the name of the file being loaded stored in
]memory? I've tried loading a file and then searching through drive
]memory for the file name, but haven't been successful. I've looked at
]the drive (I'm talking 1541 here) memory maps in "Inside Commodore DOS"
]and haven't found anything helpful either.
]
]  Does anyone know of a way to find the name of the most recently loaded
]file? (Or most recently *attempted* file)

(187) or ($BB hex) maintains an indirect pointer to the "current file
name."  183 or $B7 hex is the length of said file name.  These values
are set up by the SETNAM Kernal call, to be used by the OPEN/LOAD/SAVE
Kernal procedures.

If you were to execute the statement

10 OPEN 2,8,2,"0:ASEQFILE,S,R"

187 and 188 would be set to the address of a location in BASIC
program space (where the text of the filename is stored), and 183
would be set equal to 14 (length of EVERYTHING inside the quotes).

One way to print out the last filename accessed might be
FORA=0TOPEEK(183):PRINTCHR$(PEEK(PEEK(187)+256*PEEK(188)+A));:NEXT

But that's sloppy and slow (and may not work if the filename is a
temporary BASIC string).

I would call the Kernal portion of LOAD designed to tell you what the
filename is, which is located at $F5C1.  So SYS62913 will do the same
thing.  I wouldn't use that in a program, since the Kernal can change,
but as a "quick hack" it is perfectly fine.

Now, one more thing.  If your cartridge checks the error channel in
such a way that a file is opened AFTER the load is attempted, those
pointers will be destroyed.
--
jgreco@csd4.milw.wisc.edu		Joe Greco at FidoNet 1:154/200
USnail: 9905 W Montana Ave			     PunterNet Node 30 or 31
	West Allis, WI  53227-3329	"These aren't anybody's opinions."
Voice:	414/321-6184			Data: 414/321-9287 (Happy Hacker's BBS)