From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-11-23 22:18:34
On Sat, Nov 23, 2002 at 02:48:46AM +0100, groepaz wrote: > well..... should i do sth like > > /samples/c64/<prog> > for programs that are c64 specific (ie the plasma, > fire demo, radial demo) Many programs are not really platform specific. Making the plasma demo multi platform was not very difficult, the same is true for the fire demo. I do even think, I can make it run on the Plus/4 without too much trouble. > guess we should define something that works well for everyone ... also > some kind of naming sheme for the archives (i'd prefer timestamp over > versionnumbers for that matter ;)) I don't think it makes sense to regulate the directory structure in an archive. > (btw i noticed that snapshot is missing the silversurfer rs232 > module i made.... gotta add that aswell :o) ... wasnt there some plan > about changing the api or sth?) The RS232 code could also go into a module. This would have the advantage that the hardware could be selected at runtime without linking in all the code. However, this is a vision of distant future. I would like to test the driver concept using the new graphics API. When this works satisfactorily, it is time to think about other areas where modules could be used. > yeah probably... so is there a working example (that runs on the c64) > on how to use that stuff yet? shouldnt be a major problem to convert > the stuff i've done so far then.... The current snapshot contains the 320*200*2 driver for the C64. The only problem is the naming convention. Since there are target platforms with a maximum of 6 chars in a filename (+ extension), I've decided to keep my old approach only for the source file. So the driver source is named c64-320-200-2.s, and is compiled into c64-320-200-2.tgi, but the actual driver is later named c64-hi.tgi. The name is important, because one of the initialization routines for the graphics can take a constant describing the resolution requested. This is then translated into a matching driver name by platform specific code. This way, a platform independent program can request a graphics mode "320*200, two colors" and will get this mode, if there is a driver available. You can take the source of the existing driver as an example. Some of the functions are not complete, and there will be minor changes, but the big stucture should be in place. The samples directory contains a program named "tgidemo", that shows how to work with the graphics module. To review the API, have a look into the tgi.h header file. 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 : 2002-11-23 22:18:40 CET