From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2000-03-10 10:19:19
Hi! > I don't think I've used overly much of the original Dunning > code. The patch I've sent to you moves those files into an > "old" directory, therefore they appear very prominently in > the patch file... I had a discussion about using Johns code with Mark lately. My position on this is: Don't use it. The most prominent argument against it is the copyright: It is not as free as it could be. In addition, the code is old and does need a rewrite in many places anyway, so it is not much more work to just leave it alone and write your own (maybe better) stuff. I have tried to keep the library clean in this respect and it would be a pity to reintroduce old license with the atari port. I have to admit that this is a personal preference (licensing issues for open source stuff are usually an almost religious issue anyway:-). I was in the situation more than once, that I could not use a piece of code for a freeware project because it was GPLed. So I'm somewhat sensitive when it comes to licensing issues. Of course anyone may choose the license he likes best for his own code, but this does not mean that I don't have any preferences:-) > One of the biggest differences I found is in cputc.s. You use the CIO > for this, my version writes directly to screen. I also had a CIO > version before, but I changed it, because I think the conio stuff > (and so cputc, compared to putc) is optimized for speed!? > What do you (and others) think? I don't know anything about CIO, but what I had in mind with the conio module was to give fast and easy low level access to screen and keyboard. For the CBMs (and the Apple) this was not possible without using direct access. Some of the interface definitions for the conio functions disallow using kernal functions on the CBMs. An example is cputc: It should be possible to write to the lower right screen position without scrolling. Without this, it is impossible to use conio for building screen masks. I don't know if the CIO interface allows this level of control. If so, it would be ok to use it. On the other side, it is often not a good idea to mix different access levels to a device, because using high level functions on one side and accessing stuff directly on the other may not work well together. The standard C functions (putc, getc, printf, ...) were thought to do the high level access. On the CBMs they should use the official kernal functions (or at least, be compatible with these functions). Because these functions do not exist for now, the difference may not be that obvious. > I here define a EXEHDR segment, which contains > the data for the Atari DOS EXE header, and an additional > segment AUTOSTRT, which provides autostart when > loaded from plain DOS. (see crt0.s on how both are > set up). I like the idea to put the header in a separate segment. This would also allow to have two different headers for different types of executables and throw away the headers not needed by assigning an empty output file. > I would prefer a possibility to define an address at > link time (this works with %S), and fall back to some > default value (specified here in target.c) if no "-S" > switch is given at link time. I don't know whether > this is possible with current ld scripts? (Uz?) > Similarly I would like to specify the size of RAM > to something like "$c000-start". Is this possible? This is currently not possible, but a minor change in the linker. All that the linker has to do is to treat the default start address as target specific. So, as an example, if the atari target is enabled, 0xB00 is assigned to the start address and %S is used in the linker config file. If no start address is specified, the default one is used. > PS: we're still using/adapting much JRD stuff. Does anybody > know about his current whereabouts? I would also be glad if someone had an mail/postal address so I could try to contact him. Regards Uz -- Ullrich von Bassewitz uz_at_musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:35 CET