From: Groepaz (groepaz_at_gmx.net)
Date: 2003-04-28 23:07:41
On Monday 28 April 2003 19:45, Ullrich von Bassewitz wrote: > 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:-) lol :o) well :=) i see what you mean though :) > 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. if you allow both (either A-Z or drive numbers starting with 1) you are even ISO compatible :) > > (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... i'll probably add the scroll stuff myself too :) got some effect in tetris now thats just terribly slow without it :=P > 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. ofcoz, no hurry :o) > 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. okie... i'll check that when i need the rs232 stuff :) > [OUTTEXT] > 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:-) uhmz...direction...mmmmh :O) gotta check if it makes sence to modify my routine :=P might be more work than rewriting it i fear :=P > > 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. ahh cool, just did last nite, didnt install yet :) > My experience with this is not very good, at least not outside a small > circle of developers. i just thought this could be a way to prevent ppl doing things that go one step to far already... ie, it makes more sence atm to implement the one or other tgi driver for some more platforms, than thinking about highlevel 3d functions that work on top of it :O) (mini-gl anyone? :=P). gpz ---------------------------------------------------------------------- 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 23:11:33 CEST