Since the next The Third Creation deadline is on monday, March 1st,
I've decided to give everyone who is releasing a demo the opperrtunity test an alpa of freesd which I've been working on along with TyRaNiD.
Currently there are issues with freesd (which I believe reside somewhere in the init function), but I won't have time to fix them before
monday, but it should be working fine with block transfers which is what amigamod & SjPCM use.
Here is a little current state list:
- Note2Picth, Pitch2Note not implemented.
- BlockTrans does not support WRITE_FROM
- Issues with voices & effects, they seem to be working fine sometimes when I've loaded libsd first, which is why I believe
its somewhere in init the trouble is.
Download : http://www.lukasz.dk/files/freesd-0.8-alpha.zip
The final version will be released as a binary aswell as the source which will be commited to ps2drv in cvs.
Also there will an addon irx for freesd, which will make it possible to use freesd from EE, so basicly a RPC server. And ofcourse
a EE lib which will be the interface to this addon irx.
Any bugs and comments can be made in this thread.
Lukasz Bruun
freesd.irx 0.8 Alpha
RPC should always be optional, not bolted into a low level driver. By bloat I meant bloat freesd.irx with code that may never get used in practice. If the common practice is to interface with sjpcm via RPC, but sjpcm communicates with freesd on the IOP, what's the point of running a RPC server inside freesd if it's never activated?
The power of the IOP is that everything is modularized, you can have an IOP-only interface if you want to use the IOP in the background, and you can have an optional EE RPC interface in case you need to touch the device using the EE. The key is keeping drivers small so that you don't consume resources you might not use.
The power of the IOP is that everything is modularized, you can have an IOP-only interface if you want to use the IOP in the background, and you can have an optional EE RPC interface in case you need to touch the device using the EE. The key is keeping drivers small so that you don't consume resources you might not use.
I'll state it in simpler terms:
- This freesd is just a clone of libsd, but is free to use.
- The author has mentioned writing separate module as a RPC interface for it.
- There is one already available (sjpcm), so I suggest something different (putting rpc services directly into freesd).
- You say that its bloat.
- I reiterate how since there's already sjpcm, he could do something different, or not at all.
- You give a lecture on how it is bloat.
For the record, I know how the IOP is supposed to work with each module having a single function and living in modular harmony. Can we move past that?
Since sjpcm already exists, freesd works with it, if he's going to write rpc services:
1) Why not do something different and put them right into freesd?
2) Why write RPC it at all if sjpcm exists?
- This freesd is just a clone of libsd, but is free to use.
- The author has mentioned writing separate module as a RPC interface for it.
- There is one already available (sjpcm), so I suggest something different (putting rpc services directly into freesd).
- You say that its bloat.
- I reiterate how since there's already sjpcm, he could do something different, or not at all.
- You give a lecture on how it is bloat.
For the record, I know how the IOP is supposed to work with each module having a single function and living in modular harmony. Can we move past that?
Since sjpcm already exists, freesd works with it, if he's going to write rpc services:
1) Why not do something different and put them right into freesd?
2) Why write RPC it at all if sjpcm exists?
1) Because it's bloat.
2) I couldn't care less where RPC goes, where it lives now, or if it's written at all, not putting it in the direct access module is common practice and you are the only person that has ever suggested different.
With all this back in forth, in the end it's up to Lukasz to decide where it goes, and that doesn't make me any difference either :). I'm not debating what he should do, just why what you suggest isn't the thing to do.
2) I couldn't care less where RPC goes, where it lives now, or if it's written at all, not putting it in the direct access module is common practice and you are the only person that has ever suggested different.
With all this back in forth, in the end it's up to Lukasz to decide where it goes, and that doesn't make me any difference either :). I'm not debating what he should do, just why what you suggest isn't the thing to do.
Mainly because of the mess its in at the moment, however I will clean i up asap and commit it to CVS and have some more eyes on it and hopefully find the bugs faster, as you stated yourself Marcus :)mrbrown wrote:If it's this far along, what's the holdup in putting it into CVS?
As for the RPC, seperate or not, the way i see it, freesd will be open source and people can alter it in anyway they want for their needs.
But i'm going for seperate as there are already irxs like SjPCM and Amigamod which do not require it, so I don't see much pointing filling iop memory up with code which is optional to use.