Re: [cc65] Apple2 file io - here: memory management questions

Ullrich von Bassewitz wrote:
> Hi,
> This is of course possible but I think it will complicate things in early
> stages, because currently there is no such linker support. Adding directories
> and possibly mutliple libraries to the apple2 target now needs additional
> makefiles.

I've taken an initial stab at setting up sub-directories and creating 
the makefiles.  The top makefile has a couple of "../.." which doesn't 
work once you get to 3 levels of directories.

> 
> My suggestion is still to add file i/o support for a selected disk operating
> without bells and whistles, but keeping in mind the discussion and what you
> said about the different scenarios. Once this is done, file i/o can be used
> and remaining design/code problems resolved. Such problems could be memory
> issues, buffer allocation or whatever.
> 

I agree.

> The next step would be to add the necessary hooks of the disk operating system
> dependent routines where these hooks have not been supplied before. This step
> would also include moving stuff to subdirectories to separate stuff that
> depends on one disk i/o system from the common code.
> 
> The final step would be to add code for a second disk operating system and
> polish the API in this process.
> 
> Please note however, that this is just the way, I would tackle the problem,
> because I have learned that trying to solve too many problems at once will
> often not work for me. If someone goes ahead, ignores all my talk and
> implements all things at once, I will be happy about it. Different people have
> different ways of achieving something, and doing it step by step is mine.
> 
> Regards
> 
> 
>         Uz
> 
> 

I've been working for about 13 years in software and I've also found 
that release early and often does work better than other methods, 
however, I do like to see most of the functionality implemented.

Everyone has been wonderful in commenting on what's been done and what 
should be done which is good in uncovering assumptions that I've made 
which may not be suitable for others.

My goal is to have something and explore further.  I want to avoid 
painting myself into a corner or doing so much work and having it 
rejected because it was an unsuitable direction.

I would suggest that the IIGS be offered as another "type".  The biggest 
reason is that the GS is truly a different machine which just happens to 
have a emulation mode for the II line.

Anyway - my current direction is to complete the test suite.  I've 
reduced the number of ProDOS buffers to 5, which is 8 file handles in 
total, which I think is good as it reduces the memory footprint yet 
keeps the guarantee(?) that the code makes with the FOPEN_MAX.  I've 
also implemented the oserror functions which again keeps the platform in 
sync with the others.

The test suite is going to:
   1. open a non-existing file & close.
	Goal: test file creation & mode options.  Functionality is part of open.
   2. open an existing file, write x bytes and close.
	Goal: test file writing
   3. open file used in 2 and read bytes.
	Goal: test reading

2 & 3 will also need to be tested with the mode parameter on open.

   4. open file used in 2, seek to eof+n, write x bytes and close.
      open file & read
	Goal: test current seek
      also part of mode test (w+ or a)
   5. open file used in 2, seek beyond eof, write x bytes, seek to 
begining and read x bytes.
	Goal: test absolute seek & file extension.
   6. rename file
	Goal: test rename function
   7. destroy file
	Goal: test remove function.
   8. Open file, change volume and write.
	Goal: test error functions.  Changing volumes will throw an error and 
such error should prevent a write.
	- this functionality needs to be coded as an open does not store the 
current volume yet.


Once this passes - I believe that the library can be released.  At this 
point I will have to upgrade to the current development effort & 
stabilize against the new code.

So,  what have I missed ?

Thanks
Jim

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.