From: groepaz (groepaz_at_gmx.net)
Date: 2002-11-24 00:25:43
Hello Ullrich, UvB> Many programs are not really platform specific. Making the plasma demo multi UvB> platform was not very difficult, the same is true for the fire demo. I do even UvB> think, I can make it run on the Plus/4 without too much trouble. well ok, thats true... actually they should all be portable to platforms with a redefineable characterset (with some lookup-tables also to regular ascii terminals...ehrm ;=P i'll do that when my 8032sk is set up hehehe) >> 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 ;)) UvB> I don't think it makes sense to regulate the directory structure in an UvB> archive. well, i like them a way that they dont result in a funny mess when unpacking more than one of them at once :o) that was the main reason to ask for "regulation" for them...i am not really sure if its a good idea to let the (often very unexperienced in our case, many ppl appearently are learning c by using cc65) user alone with a bunch of archives with non-organized directories in them which end up into a non-working clumsy mess when unpacked. also to me its bad practise to just zip up some source-dir and spread it as an _example_, when you cant be sure that the thing builts without problems and _unchanged_. (i have seen M$ visual-crap examples that dont built at all if you dont fix them first for that matter.... *shudder*) UvB> The RS232 code could also go into a module. This would have the advantage that UvB> the hardware could be selected at runtime without linking in all the code. UvB> However, this is a vision of distant future. I would like to test the driver UvB> concept using the new graphics API. When this works satisfactorily, it is time UvB> to think about other areas where modules could be used. ok, thats true... UvB> The current snapshot contains the 320*200*2 driver for the C64. The only UvB> problem is the naming convention. Since there are target platforms with a UvB> maximum of 6 chars in a filename (+ extension), I've decided to keep my old UvB> approach only for the source file. So the driver source is named UvB> c64-320-200-2.s, and is compiled into c64-320-200-2.tgi, but the actual driver UvB> is later named c64-hi.tgi. The name is important, because one of the UvB> initialization routines for the graphics can take a constant describing the UvB> resolution requested. This is then translated into a matching driver name by UvB> platform specific code. This way, a platform independent program can request a UvB> graphics mode "320*200, two colors" and will get this mode, if there is a UvB> driver available. mmmh just two chars to describe unique modes? thats very little if you ask me ;=P also, why put that restriction on a platform that dont need it when you translate from constants to real filenames anyway? (and also drivers would only work on one specific platform) also wouldnt it be smarter to embed the type of resolution (or any other capabilities) into the module-file so the application really doesnt need to know which drivers are present? (to me its an important point that additional drivers can be developed and used even with applications whose source is not available...and that also means they cannot be relinked against updated libs that know about new drivers) UvB> You can take the source of the existing driver as an example. Some of the UvB> functions are not complete, and there will be minor changes, but the big UvB> stucture should be in place. The samples directory contains a program named UvB> "tgidemo", that shows how to work with the graphics module. To review the API, UvB> have a look into the tgi.h header file. perfect, i'll have a look at it.... gotta take a small break from the retroreplay related stuff anyway (until bugreports come back to me ;=P)... lets see how that works out :) -- Best regards, groepaz mailto:groepaz_at_gmx.net ---------------------------------------------------------------------- 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-24 00:25:59 CET