Re: [cc65] Apple2 Libraries - Current status of file io ?

Ullrich von Bassewitz wrote:

>Hi!
>
>On Tue, Jul 27, 2004 at 09:37:01AM -0400, jim wrote:
>  
>
>> int fstat(int fd, struct stat *buf);  /* standard POSIX call */
>> int dio_get_file_info(int fd, struct a2_stat *buf);  /* apple namespace */
>>    
>>
>
>I haven't looked further into the issue, but it's probably not a good idea to
>add the latter to the dio api. dio was made to allow low level (not file
>oriented) disk i/o. The function could be made apple2 specific, however.
>
>  
>
I only suggested the dio namespace as apple has 2 functions that 
read/write a block of data.

>>I am looking for a status of what's been done and if we're even
>>compatible.  Oliver might be working on ProDOS 16 implementation where
>>I'm working in ProDOS 8.
>>    
>>
>
>Does this mean there are several different file I/O libraries needed for the
>Apple? If so, would it be possible to find a common denominator for all of
>them?
>  
>
A little history (as I understand it)- you can skip if you heard it.

1st "dos" on apple was a 13-sector solution that was called DOS 3.2. A 
firmware upgrade converted the 13-sector encoding into 16-sectors which 
is known as DOS 3.3.  Apple rewrote DOS to provide support for hard 
drives and called it ProDOS, which is known as ProDOS 8 as it can run on 
most Apple II hardware.  The IIGS which is an extentsion of the line 
used the 65816 processor and ProDOS 16.  The GS also has GS/OS which is 
very MAC like.

I have a GS but I never got into the GS/OS stuff, so I don't know it 
well at all - I am assuming that most people will want either a DOS 3.3 
or ProDOS 8 library as those two options will cover 80% of the machines 
(??).

ProDOS 8 interface is real easy to work with, set up a structure with 
the info and call the main routine.  DOS 3.3 is harder - you have to 
fill in objects inside DOS and call a couple of routines.

Long story short - there is not too much that is common - most of the 
code is setting up the function call.

>  
>
>>I'm not too sure what you mean by this.  Functionally ? Internal
>>structure ? Syntax ?
>>    
>>
>
>I'm trying to keep the overall design consistent. This extends into several
>areas, internal structure is one of them. Portability is another: Anything
>that could be done in a portable way, shouldn't have a platform specific
>solution. If it is not possible to make something completely portable, it is
>often possible to split it into a platform independent part and a platform
>dependent one. I'm trying to make the platform independent part as large as
>possible (share as much code among the platforms as possible), because this is
>easier to test and to maintain.
>
>  
>
>>For example: I've coded the Apple libraries to correspond with the POSIX
>>calls
>>int chdir(const char* path);
>>int __fastcall__ close(int fd);
>>int creat(const char *name, mode_t mode);
>>int flush (int fd);
>> ... and so on ...
>>    
>>
>
>Good approach, this is how it should be! However, there's at least one
>problem: The library does already have a chdir function in the common
>(platform independent) part. It calls a platform specific function named
>__syschdir which must return a platform specific error code in A (similar to
>remove(), which calls __sysremove).
>
>As you can see from the above, I'm trying to get overall structure right, so
>the parts and platform code fit together nicely.
>
>  
>
Ah !  I get it.  I didn't see the __sysremove call.

>>The hacks in the write and read functions have been worked with so that
>>using the STDIO consts work.
>>    
>>
>
>Great! This is how it should work. Does reopening these streams also work?
>
>        freopen (stdout, "w", "output.txt");
>
>A perfect solution would even allow to close and reopen the low level file
>descriptors (STDIN_FILENO, STDOUT_FILENO and STDERR_FILENO), and reopen them
>pointing to a file. This is difficult on some platforms, and not implemented
>everywhere, so don't bother if you have hardcoded checks for the standard file
>descriptors (which means that reassigning them will not work).
>
>  
>
I don't allow the STDIO to be remapped - it's possible.  How should the 
tty be represented ?
"/dev/tty" ?  I don't want to make a Apple II Unix with dev inodes and 
such on the disk -  the disks are too small for standard Apple II's.  I 
can see using /dev/tty and /dev/stty0, ...
Cygwin uses "CONIN$" "CONOUT$"

There has to be some way to allow the code to select the "right" device 
on reading or writing.  Which leads to a device table.
devices:
console (r/w)
serial (r/w)
parallel (r/w)
disk(r/w)
joystick(r)
clock ?

Would it be possible to implement the new loadable driver idea with the 
disk ?  The console routines would be an easy extension - the functions 
would always point to ROM or library functions.


Thanks
Jim

>If you're doing larger changes/additions, I would suggest to check back with
>me early. It is frustrating if you have spent several weekends to code the
>ultimate cc65 addition, just to have me reject it for some reasons you didn't
>know when you started. Or, request large changes. And, believe me, having to
>do this is also very frustrating for me!
>
>I'm glad about every cc65 contribution. But I do also want to keep cc65 clean
>and consistent. It wouldn't be helpful to accept contributions just to be
>polite, even if they do not fit into the overall concept or if there are some
>other reasons, they shouldn't go into the main distribution. This would
>ultimately make cc65 a mess. Checking back with me early helps to resolve any
>problems that might arise with a contribution and therefore reduce the
>frustration for both of us.
>
>Regards
>
>
>        Uz
>
>
>  
>


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