dpw@rayssd.UUCP (07/02/84)
I was working with the Editor64 package and when I did a put "filename" it seem to work.(not disk errors) When I went back to read it nothing was there. The only clue that I have is that the Editor doesn't seem check to see if the slot it is trying to write to is large enough for the file. I have not problem writting BASIC program or with the Editor if is the last file on the disk. While we are on the subject of problem when I load the object code into C000 hex it does funny thing to basic and have to turn the system off to recover. I would be grateful for any help. Thanks Darryl Wagoner !allegra!rayssd!dpw
miller@uiucdcs.UUCP (07/06/84)
#R:rayssd:-48600:uiucdcs:36100085:000:2098 uiucdcs!miller Jul 5 17:09:00 1984 Sorry to be off the net for so long. I've been trying to finish my MS thesis. If my advisor likes what I just gave him, I'll have more time to contribute soon. I'm planning some articles on how to align your 1541, plus a new series on how the guts of the Basic interpretor works. >Darryl Wagoner: >When I went back to read it nothing was >there. The only clue that I have is that the Editor doesn't seem check to see >if the slot it is trying to write to is large enough for the file. I have >not problem writting BASIC program or with the Editor if is the last file >on the disk. If I understand your question correctly, you're barking up the wrong tree. The only "slot" I know of is when a file is deleted off disk. The next file created on disk will be assigned the earliest possible position in the directory. This may give the appearance that the file resides in the previous deleted file's disk area, but that is not necessarily the case. It is only occupying its location in the directory. At any rate, even if it did start allocating sectors at the same location, the new file is allowed to be larger than any previous file that happened to reside there. The 1541 subroutines look at the BAM and return an unallocated sector when a file needs it, and then chains the sectors together via the first two bytes on each sector. Assuming your software uses the 1541 routines correctly and does not try and do its own sector allocation, you'll have no problems. > While we are on the subject of problem when I load the object code >into C000 hex it does funny thing to basic and have to turn the system off >to recover. $C000 is the start of the 4K fragmented RAM by the Basic ROM. It is into this area that the 1541 "wedge" is loaded. Thus, if you are running the wedge that comes on your demo disk with the 1541, you'd better be careful about loading code into that area. Basic will indeed flake out if you smash the wedge while it is active. If you are not running the wedge, then you have other problems and I can't help you without more info. A. Ray Miller Univ Illinois
patrick@ism780.UUCP (07/23/84)
#R:rayssd:-48600:ism780:14900008:000:66 ism780!patrick Jul 9 10:47:00 1984 The wedge lives from approximately $CC00 to $CFFF. Unless you're
patrick@ism780.UUCP (07/23/84)
#R:rayssd:-48600:ism780:14900009:000:437
ism780!patrick Jul 9 10:53:00 1984
....
Please excuse the previous half-note; our note-response software isn't very
user-friendly, and I got confused.
Start again:
The wedge lives at $CC00 through $CFFF. Unless you're loading a very big
program into the $C000 block of memory, there should be no conflicts.
Patrick Curran
Interactive Systems Corp.
1212 Seventh St.
Santa Monica, CA 90401.
...{uscvax|ucla-vax|vortex}!ism780!patrick
...decvax!yale-co!ima!ism780!patrick