[net.micro.cbm] files not saved on Editor64/Asm64

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