[Coco] f83 for the CoCo, Update and a laundry-list of questions.

Brett Heath bkheath at gmail.com
Sun Nov 9 14:47:41 EST 2008


On 11/9/08, Darren A <mechacoco at gmail.com> wrote:
> On 11/9/08, Brett Heath wrote:
>>
>> ...
>>
>> With one exception the file interface to Disk EDTASM and OS9 (and
>> presumably Nitros) looks to
>> be fairly straightforward. The exception is determining file size. The
>> only way I see to do this
>> in EDTASM DOS is to do repeated reads if increasing record numbers
>> until an error is returned, inelegant to say the least.
>
> In RSDOS, walking the FAT will tell you many granules the file uses
> and how many sectors are used in the last granule. Bytes 14 and 15 of
> the file's directory entry indicate how many bytes are used in the
> last sector. The file's size can then be calculated as:
>
> fileSize = (numGrans - 1) * 2304 + (lastGranSectors - 1) * 256 +
> lastSectorBytes
>
>
>> A more fundamental problem is that I haven't found any way to find out
>> from RSDOS if
>> a diskette has been changed, and thus that the resident RAM copy of a
>> drive's FAT is no
>> longer valid.
>>
>> Please tell me that I've missed something.
>
> Each of the RAM resident FAT tables are preceded by a 6-byte header.
> Only the first two bytes are used. The first byte indicates how many
> files are open on the drive. The second byte is the Dirty Flag. When
> the second byte is 0, the RAM resident FAT has not been modified.
>
> Darren

I wasn't clear.

I'm bypassing RSDOS because it's pretty much useless unless you use
Basic to make
the system calls, which is unacceptable. I've already implemented a
SET-SIZE function and
most of the other low-level functions needed to emulate a DOS
(including dynamically
allocated FAT buffers, part of the code for which was pasted as
Teaser2) using DSKCON. What I don't see how to do, and what will
become critical as I implement functions that
modify the FAT and/or Directory sectors, is a way to tell if the user
has changed the
diskette since the last time the drive was accessed.

If I can't get this without Basic taking over on an error I'll have to
implement secondary
buffers to hold the unmodified FATS and do a read-back and compare
before any updates.
That's messy, slow, eats memory and will be another PITA on top of
having to emulate functions that should be available as system calls.

Disk EDTASM and OS9 qualify as actual DOS's so I can let them worry
about the low-level
stuff like diskette changes.

On the other hand, I've already solved the file size issue for RSDOS
but didn't see a direct
way to get file sizes from the system calls for EDTASM and OS9. If
it's necessary the same technique used for RSDOS will work on Disk
EDTASM but it's doubtful that OS9 will allow user apps to directly
manipulate such sensitive low-level stuff.

Getting the file size seem to be pretty basic functionality, perhaps
it's available through some
of those "wildcard" device status calls?

Anyway, sorry for the confusion, I should have realized that if you
didn't see my first
message on f83  (It's Alive!) or didn't remember most of the details
then this last message
wouldn't make much sense.

Another update. The kernel now loads and runs a slightly modified
version of the Flex
6809 Assembler. The modifications were to support long branches and to
acommodate
the changes made for position independence. The flex assembler has a
somewhat cleaner
syntax than the CHROMIUM assembler I'm using now and is more
compatible with the
f83 meta-compiler.

I'm going to go play with my new assembler for a while before I go
back to slogging through
the low-level DOS emulation.

Brett K. Heath



More information about the Coco mailing list