Re: Applesoft/Prodos/ONERR GOTO/File existence question

["Peter Watson" <paw77@N_O_hotmail_S_P_A_M.com>]

The trick is to reset the stack with CALL -3288.

Having said that, I couldn't remember the exact address so I did a quick
Google to remind myself. I found a little more than I wanted to know, for
example that the above call is not *ALWAYS* reliable, especially in
subroutines (although I never noticed any problems in my programs). I also
found a Beagle bros ML routine which they poked into memory and ran to
handle cases where the error code might have to handle 43+ errors. Neither
of those strike me as critical in most cases.

BTW, as others have said, the VERIFY command is the way to test for file. It
is the only reason it was left in ProDOS - its original function (literally
to verify that the file was readable) didn't survive past DOS 3.3.

--
Peter Watson
-- Write to MSDOS disks on the Apple IIgs?
-- Impossible!  ;-)


"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
qhfzhxiqn9.fsf@ruckus.brouhaha.com">news:qhfzhxiqn9.fsf@ruckus.brouhaha.com...
> Hans Franke and I submitted an entry to the Retrocode competition at
> VCF 6.0 today, and came in second.  I had a bit of a problem in one
> area, and thought maybe one of you experts out there might offer a
> suggestion.
>
> The code looked vaguely like this:
>
> 10 DIM M%(38,38)
> 20 GOSUB 10000: REM Load or generate maze
>
> ...
>
> 10000 GOSUB 20000: REM Try to load maze from data file
> 10010 IF M%(0,0)=15 THEN RETURN: REM Loaded maze
> 10020 REM Generate a new maze
> ...
> 10500 REM Write maze to file
> 10510 PRINT CHR$(4);"OPEN MAZE.DAT"
> 10520 PRINT CHR$(4);"WRITE MAZE.DAT"
> ... nested loops with PRINT statements
> 10580 PRINT CHR$(4);"CLOSE MAZE.DAT"
> 10590 RETURN
>
> ...
>
> 20000 REM Try to read maze from file
> 20010 ONERR GOTO 20040: REM In case the file doesn't exist
> 20020 PRINT CHR$(4);"OPEN MAZE.DAT"
> 20030 PRINT CHR$(4);"READ MAZE.DAT"
> ... nested loops with INPUT statements
> 20040 PRINT CHR$(4);"CLOSE MAZE.DAT"
> 20050 POKE 216,0: REM Cancel ONERR
> 20060 RETURN
>
> I'm not claiming that this is particularly good style.  We only had 3
hours
> to write the whole contest entry, and most of the time was spent on the
game
> algorithms and debugging.
>
> Anyhow, the problem was that any time the program was run without a
> preexisting MAZE.DAT file, it would get the error and trap to line 20050,
> but when it got to the RETURN statement in 20060, it would then get a
> RETURN WITHOUT GOSUB error.
>
> So I have two questions:
>
> 1)  Does an error trapped using ONERR really lose the subroutine stack?
>     Or do I need to do something else to make the RETURN work?  Note that
>     I definitely do NOT want to RESUME the statement that caused the
>     error.
>
> 2)  Is there a better way from a BASIC program to determine the existence
>     of a file?
>
> I presume the answer to my second question would probably be different
> for DOS as opposed to Prodos.
>
> For those that are curious, the game was originally intended to be a
> first-person maze game with monsters to fight.  However, we spent nearly
> 45 minutes of our alloted three hours getting a second Apple working.
> (About three different things bit us.  We ended up borrowing another IIgs
> from an exhibitor.)
>
> Since we ran out of time, we ended up with an overhead 2D view instead,
> because I already had written the 2D display in lores graphics to debug
> the maze generator.  The result was similar to the old "Dragon Maze" game,
> but with the entire maze visible and nine monsters wandering around.
> I estimate that the first person view could have been completed in another
> half hour or so.  Maybe I'll try that next weekend.
>
> Generating a maze took over a minute, so I added the code to save and
> reload the maze to speed up debugging of the rest of the game.
>
> At the moment I don't have a convenient way to transfer the program to
> another computer to put it on the web, but I'll do that eventually.
>
> This was the first non-trivial Applesoft program I've written in 17 years,
> and even back then I mostly programmed the Apple in other languages,
> mostly assembler (using Microsoft ALDS), XPL0, Apple Pascal, or
> Kyan Pascal.  These days the vast majority of the code I write is in C,
> with occasional assembly for hardware-related code.
>
> Thanks,
> Eric