Re: Prodos external command oddness

[mspangler@gemsi.com (Michael Spangler)]

I think I fixed the problem. 

After taking great care to save the location of the primary pathname
buffer, the programmer reloaded the addresses just before exiting with
hard-coded values. These changed as soon as Basic.System incremented a
version. So I reloaded the saved address from its stored location. The
revised version works with Basic.System 1.1, 1.41, and 1.5. (These are
not the versions of prodos itself here.)

To fix your copy of Copy, Bload it. It will load at $4000. Then enter
the monitor, and type
434E:9C DE BE A5 06 8D CC BE A5 07

Exit the monitor, and  BSAVE COPY and the new version should work OK.

Except on original 6502 processors. That 9C is a store zero command,
which only works on 65C02 and newer CPUs. I did this intentionally
because I did not want to attempt to patch the relocation code. Using
the STZ instruction saved the LDA $#00 pair, which gave me enough room
to fit the patch in place.

If you are running an apple II+, you are probably not losing much with
staying with the prodos 1.1.1 on the original Big-U disk anyway.

I find being able to do a copy directly from basic to be very handy,
so I'm glad it works now.

As a note, does anyone know of a program that changes BE6C and BE6D?
These are where the location of the primary pathname buffer is stored
in the global page. I'm not sure why they stored a backup copy in the
first place. This is not in the parameter tables, where you expect
things to change, and in fact where the actual problem in the code was
located. (The next read command tried to read the pathname from some
random hexadecimal code, which worked poorly at best.)

Hope this helps 

Mike S.