Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.13 $; site uiucdcs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!inuxc!pur-ee!uiucdcs!miller
From: miller@uiucdcs.UUCP
Newsgroups: net.micro.cbm
Subject: Re: files not saved on Editor64/Asm64 - (nf)
Message-ID: <36100085@uiucdcs.UUCP>
Date: Thu, 5-Jul-84 18:09:00 EDT
Article-I.D.: uiucdcs.36100085
Posted: Thu Jul  5 18:09:00 1984
Date-Received: Sat, 7-Jul-84 01:20:18 EDT
References: <486@rayssd.UUCP>
Lines: 39
Nf-ID: #R:rayssd:-48600:uiucdcs:36100085:000:2098
Nf-From: uiucdcs!miller    Jul  5 17:09:00 1984

#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