Ullrich von Bassewitz wrote: >On Thu, Jul 29, 2004 at 09:49:09AM +0200, Oliver Schmidt wrote: > > > <snip> > >>Another target would mean no ProDOS support for the 6502 machines - wouldn't >>it? >> >> > >See my library proposal in the other mail. Would it be possible to separate >the code so cleanly that using two or more disk I/O libs could solve the >problem? There can be references from the main code into the disk I/O >libraries, but the interface needs to be the same for all of them. > >Since using constructors for initialization is also an option, I think this >should work (provided that the linker is able to handle it). > > What I've been planning is having the same interface, but different code libraries. For example: ; int open(const char *name,int flags,...); will not change, but in open_p8.s is the prodos code and open_d3.s is the dos 3.3 code - and this is a hack - switch make files to build two libraries. Actually the "sub" libraries might work. Main Lib -> Read = existing routine (STDIN). Sub Lib1 (DOS) -> Read = DOS 3.3 routine with STDIN. Sub Lib2 (ProDOS) -> Read = ProDOS routine with STDIN. There has to be a way to specify other libraries to search or as GCC does "-L". (What to do about the listing flag ?) Example: cl65 -t apple2 -C apple2.cfg -Lpdos8 libfloat libgraphics -l -m a2_misc.map a2_misc.c -o a2misc The apple2.cfg is used because it moves the ram start from 0x800 to 0x2000 for easier debugging. I have to read up on the cfg format to specify a hole from $2000-$3fff and $4000-$5fff depending on what the developer wants for the hi-res screen holes. Thanks Jim ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Thu Jul 29 13:09:57 2004
This archive was generated by hypermail 2.1.8 : 2004-07-29 13:10:06 CEST