rmiller@musial.ucr.edu (robert james miller) (06/30/90)
First, I'd like to thank everyone who responded to my first requests for help. (In particular, Bob Larson and Bill Shephard). Second, I'd like to apologize for the obnoxious .sig. I was messing around with it for fun, and I forgot my- self for a while. Sorry :-(. Now, I'd like to make just one more small request. I have done some FTP'ing and looking around the uunet.uu.net archives for the comp.sources.XXX newsgroups, and I downloaded a few things, including MG2A (thanx again, Bob), but most of it is not, of course, ported to OSK. While I am not afraid to port stuff myself, I've decided that I'm not going to do any porting until I've received my TOPS package so I don't waste valuable development hours and bandwidth. Could any- body out there possibly mail me a list of files available on the net that they know to be OSK. It's impossible to tell without downloading them, uncompressing them, dearchiving them, and basically wasting a lot of time and money if they turn out negative. There aren't even author/contributor lists so I can look for key names. The list doesn't have to be comprehensive, I'd just like to get my hands on the excellent PD stuff that's out there. BTW, has anybody looked into the idea of installing a comp.sources.osk list some- where? If not a newsgroup, then how about just an archive that's all in one place? I don't have the resources to support it, but when I look at FTP lists, I always seem to notice some that say "Looking for suggestions..." I'm going to do a little inquiring to see if I can find someplace. If someone just has a bunch of disk space with nothing to do with it, I'm sure that there are some people (like myself) who'd like to see a centralized archive. And with the new machines running OSK being released soon, there will be a lot more interest all of a sudden in the near future. I'm willing to take the time to make the ar- rangements for setting up an archive like that, which is saying a lot because I am as busy as I'm sure everybody else is, if people seem to want one. Anyone interested in cooperating? Thanks in advance for any input. I'm also trying to get a feel for projects that people would like to see done, or haven't had time to do on their own. I'm about to start development, and I'd ap- preciate ideas so I can see what there's a demand for. I would be happy to do PD work, I plan on it anyways. 'Til next time... - Robert James Miller (rmiller@ucrmath.ucr.edu) (A little better guys?) :-)
grunwald@Tokyo.ira.uka.de (Grunwald Betr. Tichy) (07/06/90)
There are a lot of project to be done (and i would start them, if i could spend
the time):
1. Creating a object of the GNU-C Compiler and giving some instructions to the
installation. This should be done for 68000 and 68020 Systems. The Port is
available from Japan, but there seem to be Problems with the Compilation.
2. An example RBF-Driver written in C. Complete with a makefile and the
hardware Parts marked. The Driver should have Versions like:
Primitive
Multisector
Trackprefetch
Cache and other performance features included.
An OSK - RBF - Driver needs a lot of administrative work inside to give a
good performance. This parts could be distributed to ease the writing of
Drivers. I have some sources and a lot of ideas for that task, but not the
time to do it correctly (i.e. I can work with it, but there are to few
coments and the decisions are not properly overthougt).
3. A Socketmanager. There is only a commercial product and this is bundled to
the X-Windows System to my knowledge.
4. A SuperSCF-Manager with functions like insert,delete and history. Also
Functionkeys should be supported.
5. A Grafical filemanager to get a standard interface for Grafics. Only the
primitives like bitblit, line, arc and character display should be
supported. Also clipping only against one window. The Manager should notice
the capabilties of a device and only the functions not available should be
emulated. The RAVE from Microware has only 8 bit colors and that is to big
for black and white grafics.
Suggestion: Only copy rectangle to display and the draw line has to be done
by the driver the rest could be done by the filemanger or not
if the driver/device is capable of the function.
The create function opens a window and delete closes it.
Open and close gain access to it and makdir creates subwindows.
The read and write operation can possibly arranged, such that
copying a window to and from the disk is possible.
6. The stdio-lib should be reworked to give more performance. Esspecially the
write operation should switch of the verify and do the verify by itself.
May be with a sizeable verify buffer.
The getc and putc routines are also slower as they could be.
7. The cc and dsave commands should be reworked, to avoid the access of shell.
If someone uses another shell this can be annoying.\
That are my suggestions.
Knut Grunwald, Maximilianstr. 25, 6729 Jockgrim, 07271/51891ralf@ppcnet.ppc.sub.org (Ralf Sauther) (07/10/90)
grunwald@Tokyo.ira.uka.de (Grunwald Betr. Tichy) writes: > An OSK - RBF - Driver needs a lot of administrative work inside to give a > good performance. This parts could be distributed to ease the writing of Well... the performance of the MCW-RBF isn't very high. And things like directory-cacheing are not implemented. So, is it possible to use the OS-9000 RBF with OS9 ? Gruss Ralf -- Ralf Sauther | ..doitcr!rnihd!ppcnet!ralf | ralf@ppcnet.ppc.sub.org An Fronte Karl 31, D-6728 Germersheim, 07274/4169