From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-04-28 19:45:24
On Mon, Apr 28, 2003 at 06:39:00PM +0200, Groepaz wrote: > as for the dual drives...well, this can not be the reason for not doing things > like i said above :) invent something to handle cbm dual drives then, dont > pollute the whole thing with this rather exceptional stuff :) (the same is > true for stuff like handling subdirectories...if its machine dependend, its > not very useful IMHO) As I said, my original idea was to use drive:filename, so I could live with that. Unfortunately, the CBM drives do *require* a drive number (the internal one), at least according to my docs. Otherwise two data channels are allocated instead of one, which limits the number of files that can be open at once. This is even true for single disk drives, because the ROMs are derived from the dual disk drive versions. > mmmh yeah well...it would limit the thing somewhat though. (not for newly > written code, but for porting existing code that uses write() it would > eventually add lotta extra work) But the drawbacks (rewriting the POSIX low level stuff for all platforms) are far worse than having the advantage of being able to port programs that use write() to use a ramdisk. write() is not even standard C, this would be a good excuse for not supporting ram disks on this level:-) > could this be made somewhat universal then ? (ie, have irq-loader for 1541, > ram-disc and maybe a /dev/ttyS0 ? :o)) If we decide to apply a special meanings to the names passed to fopen(), anything is possible. I would suggest using numerical drive numbers (I've already hated the A:, B:, C: stuff in DOS derived operating systems), and reserve drive numbers > 128 for virtual drives - or something similar. > (for example > reading a character from screen is not possible, thats why my cpeekchar stuff > :=)). This, and scrolling of rectangular areas are two possible extensions. Maybe later... > that problem with file i/o would be another thing like this.....as it > is, its just not possible to for example use an irq or fastloader (which you > really want to do when writing a serious game for example)... thats the only > reason for suggesting all this, preventing future hackery :) It is, in one way, dangerous to have too many ideas. There must be a balance between your ideas, and your ability to implement them. Having too many ideas, you will run into danger, never to implement something usable, because what you are doing is always under construction. You will also run into danger to change your APIs so often, that no one is actually able to use them. Of course, not having any ideas isn't a good idea either:-) Since file I/O and the extended memory subsystem are brand new, and there is not a single program I've heard of, that uses the latter, I would suggest just to wait some time and see what people are actually doing. In my experience, this is a good way to learn what is really needed and to have all necessary features in an API while at the same time keep it as minimalistic as possible. > well noone is is expecting YOU to do the work i guess :=) Yes. Maybe. But maybe not:-) > i like this one too :o) btw if you'd just define the api and implement one of > the drivers i am sure other people could convert other existing drivers > easily.... I've already started with the rewrite. The new header file is called "serial.h", so for some time, the new API and the old one can coexist. The API and driver framework should be mostly complete, and I'm currently converting the C64 driver, so that there is a reference implementation. Existing code is in the snapshot source. [OUTTEXT] > he :) i could add that, think i've even such a routine laying around > (optimized for size and not for speed though i think, so it'll be rather > slow). is the api defined in detail for that? i have to admit i didnt really > look at that yet :=) The API is defined, at least in my head:-) OUTTEXT should output the text at the current cursor position, with the direction and magnification defined by tgi_textstyle. If you would like to have a look at it, just go ahead (and remember those tabs:-) > as for that, since i am always working on/debugging/testing on real thing/etc > the actual nes library stuff.... if you could just add the crt0 (and some > solution for the heap thing :/) so i can continue working with that, then i > could clean up one of the other files after the other and just send it > over... Just download the snapshot sources, it's already in there. > however... i wouldnt mind if such a (maybe more detailed) todo list would be > available somewhere...maybe seperatily on the snapshot ftp or sth... some of > the tasks really look like other ppl could also do them, if they only knew > what to do :=) My experience with this is not very good, at least not outside a small circle of developers. Anyway, if someone is in desperate need for something to do the next weekend, here is a list out of my head: * Documentation: The function reference is still very imcomplete. Adding descriptions for more functions, short pieces of sample code or similar would probably help more people to use cc65 successfully. When starting your work, please be sure to change the right file (funcref.sgml). * More documentation: Having some system specific documentation would be nice. Such a documentation could explain the executable layout, the memory setup for a specific machine, possible linker configurations for other uses, features available (and not available), and a list of the machine specific functions in the library. * Drivers: APIs for loadable drivers exist for - extended memory, - graphics, and - joysticks. Maciej has written several drivers for VDC graphics (C128), there's one driver for the C64 hires mode, most machines have standard joystick drivers, and there is a wealth of extended memory drivers for several Commodore machines. Apart from this, most machines are lacking driver support. Something that should be rather easy to implement is a driver for the C16 and Plus/4 in 320*200 mode, since this mode is almost identical to the same mode on the C64. It should be possible to port the C64 driver with not too many changes. * dio (direct disk i/o) has been designed by Christian as a portable interface for low level disk i/o. Unfortunately, there's still just an implementation for the Atari. Having a dio implementation for the CBMs would allow writing programs that access disk directly in C (manipulate the directory and BAM for example). * For most platforms, the ctype tables needed by the tolower/toupper/is... functions are just copies of the ones for the Commodore machines. In addition to that, the sources are old, and I didn't use symbolic constants when writing the original Commodore one. Having ajusted tables for the Apple, and Oric Atmos would be nice. Using the symbolic constants from asminc/ctype.inc for better readability would be even nicer. There's more, but I need to get a beer now, since my mouth got dry from all the writing:-) Regards Uz  "Rothaus Tannenzšpfle" - wohl bekomm's:-) -- 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 : 2003-04-28 19:45:39 CEST