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. "Michael Spangler" wrote in message news:1a410081.0402092040.1974690c@posting.google.com... [SNIP] 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. Not sure what you mean Mike. Those are pointers in the global page that point to a pathname buffer. BE6C/6D VPATH1 ;Pathname 1 buffer BE6E/6F VPATH2 ;Pathname 2 buffer (RENAME) Basic system itself will change those pointers as it goes about its business.