I will have time on the weekend to work on the SDK.
AHelper wrote:
I will have time on the weekend to work on the SDK.
Great! Much thanks and appreciation. 
KermMartian wrote:
AHelper wrote:
I will have time on the weekend to work on the SDK.
Great! Much thanks and appreciation.
Anything I can do to help this along, AHelper? 
AHelper promises that the next two weeks are available for him to work on Prizmy things, and I believe that Tari, Jonimus, and Merth might have some time as well. I will have time to do testing, although I can't guarantee how much time I'll be able to contribute. Shall we get this sorted ASAP?
No promises, but I should have more free time.
The native prizm target for GCC is a low priority for me now, so probably with the sh3eb target for now. We should either update the ram section size to be larger than 64k, since we have a large space shared with the stack of about 512k. Even better would be having that specified on the linker command line, but I don't know if that's possible.
The native prizm target for GCC is a low priority for me now, so probably with the sh3eb target for now. We should either update the ram section size to be larger than 64k, since we have a large space shared with the stack of about 512k. Even better would be having that specified on the linker command line, but I don't know if that's possible.
Also, on the Jonimoose tree of libfxcg at GitHub, several header definitions on the includes folder are missing, and many confirmed to work syscalls are missing too. The custom function PRGM_GetKey is broken, not detecting any keys or at least not returning the proper PRGM codes; I fixed it with what I had here (which I believe was written by AHelper) and now it works fine (at least, it is able to build the latest version of the Utilities add-in, where I use most of the "new" syscalls).
I suggest looking at my libfxcg fork at https://github.com/gbl08ma/libfxcg and merging that, or parts of that, eventually along with AHelper's modifications too, with the main libfxcg tree.
About the stack being 500 or 512k, I have used it like that on two of my add-ins already (the Utilities one and the yet-to-be-released Image Viewer, which has an huge buffer in the stack) and I don't see any problem in making it the default; this is just my point of view of course.
In fact, I believe the OS uses the stack more than the heap (most of the things in the OS have a fixed limit size which makes me believe fixed allocation is used for many things, but I can only confirm this if I have a way to call the Test Mode at any point in the OS).
I suggest looking at my libfxcg fork at https://github.com/gbl08ma/libfxcg and merging that, or parts of that, eventually along with AHelper's modifications too, with the main libfxcg tree.
About the stack being 500 or 512k, I have used it like that on two of my add-ins already (the Utilities one and the yet-to-be-released Image Viewer, which has an huge buffer in the stack) and I don't see any problem in making it the default; this is just my point of view of course.
In fact, I believe the OS uses the stack more than the heap (most of the things in the OS have a fixed limit size which makes me believe fixed allocation is used for many things, but I can only confirm this if I have a way to call the Test Mode at any point in the OS).
Just in the interest of preserving my sanity, can you send a pull request to the main libfxcg repository?
One thing that shouldn't require major testing (so I think we should include in this new version) is finishing the process of moving syscall prototypes into the fxcg include directory and fully deprecate the ugly header names. I'm not sure offhand how much of that I finished, but I'm pretty sure it wasn't all of it.
One thing that shouldn't require major testing (so I think we should include in this new version) is finishing the process of moving syscall prototypes into the fxcg include directory and fully deprecate the ugly header names. I'm not sure offhand how much of that I finished, but I'm pretty sure it wasn't all of it.
Tari wrote:
Just in the interest of preserving my sanity, can you send a pull request to the main libfxcg repository?
One thing that shouldn't require major testing (so I think we should include in this new version) is finishing the process of moving syscall prototypes into the fxcg include directory and fully deprecate the ugly header names. I'm not sure offhand how much of that I finished, but I'm pretty sure it wasn't all of it.
One thing that shouldn't require major testing (so I think we should include in this new version) is finishing the process of moving syscall prototypes into the fxcg include directory and fully deprecate the ugly header names. I'm not sure offhand how much of that I finished, but I'm pretty sure it wasn't all of it.
I believe you put pretty much all of the prototypes in the fxcg folder, and those you didn't I put already and are in my fork... I'll go checking which are missing, add them and then push the changes to my fork so I can submit a pull request.
What about the file libraries that AHelper worked out, plus his libm stuff? From what I remember from our discussions, his file stuff is OK to pull into the main libfxcg, but I believe you (Tari) had concerns about the licensing on the libm code that he pulled in.
His C++ file browser library? Based on your C version of it I have many reservations about using it, but hey, just because something's on libfxcg not everyone using PrizmSDK is forced to use it.
I also think your file browser library is a bit overcomplicated (I got to the same results in fewer lines of code, without mallocs and without system errors, will publish soon).
libm sounds like a very good addition specially for those interested in developing a CAS for the Prizm... about the licensing, it's not my stuff
I also think your file browser library is a bit overcomplicated (I got to the same results in fewer lines of code, without mallocs and without system errors, will publish soon).
libm sounds like a very good addition specially for those interested in developing a CAS for the Prizm... about the licensing, it's not my stuff
KermMartian wrote:
What about the file libraries that AHelper worked out, plus his libm stuff? From what I remember from our discussions, his file stuff is OK to pull into the main libfxcg, but I believe you (Tari) had concerns about the licensing on the libm code that he pulled in.
I am still waiting to catch wind of whatever these issues are with using it. libm carries this copyright notice:Code:
/*
* ====================================================
* Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
*
* Developed at SunPro, a Sun Microsystems, Inc. business.
* Permission to use, copy, modify, and distribute this
* software is freely granted, provided that this notice
* is preserved.
* ====================================================
*/Please note that libm is not built into libfxcg. I have a modified version of uClibc that I can build libm from and install the sources to my cross-compiling setup.
gbl08ma wrote:
I believe you put pretty much all of the prototypes in the fxcg folder, and those you didn't I put already and are in my fork... I'll go checking which are missing, add them and then push the changes to my fork so I can submit a pull request.
Bumping this.
I take issue with a few things in your changes, mostly related to naming and a few choices of header. I cherry-picked the changes that are okay, but I'd like the things I commented on to be fixed before I pull those.
I'd just like to know how to name TScrollbar since you feel that name is too C++ish. "Scrollbar" is already used, it's a syscall name (unless we rename it and all its friends to DrawScrollbar or something similar?).
I, personally I'm out of ideas for other names (that TScrollbar name was given by Simon L. and later used by AHelper IIRC).
I, personally I'm out of ideas for other names (that TScrollbar name was given by Simon L. and later used by AHelper IIRC).
gbl08ma wrote:
I'd just like to know how to name TScrollbar since you feel that name is too C++ish. "Scrollbar" is already used, it's a syscall name (unless we rename it and all its friends to DrawScrollbar or something similar?).
Simply lower-case 'scrollbar'. There's no name collision because it's a struct, and we're not typedef'ing it. This is the pattern you see in POSIX, with things like the 'stat' struct.
If it is, change it so it's not. Neither TShapeProps (display_shape?) nor TBdispFillArea (display_fill?) are typedef'd.
Examining those two, I also see the structs were defined but aren't used anywhere. I assume the nearby syscalls such as Bdisp_ShapeBase take pointers to such structs (given the void * parameters I see), so those prototypes should be updated to be pointers to the necessary structs.
Examining those two, I also see the structs were defined but aren't used anywhere. I assume the nearby syscalls such as Bdisp_ShapeBase take pointers to such structs (given the void * parameters I see), so those prototypes should be updated to be pointers to the necessary structs.
Tari wrote:
If it is, change it so it's not. Neither TShapeProps (display_shape?) nor TBdispFillArea (display_fill?) are typedef'd.
Examining those two, I also see the structs were defined but aren't used anywhere. I assume the nearby syscalls such as Bdisp_ShapeBase take pointers to such structs (given the void * parameters I see), so those prototypes should be updated to be pointers to the necessary structs.
Examining those two, I also see the structs were defined but aren't used anywhere. I assume the nearby syscalls such as Bdisp_ShapeBase take pointers to such structs (given the void * parameters I see), so those prototypes should be updated to be pointers to the necessary structs.
That was I was going to do... So we need to typedef TShapeProps/display_shape and TBdispFillArea/display_fill, right (otherwise the headers won't compile)?
No, don't typedef any of them. Just qualify them as structs where necessary.
For example:
Code:
For example:
Code:
struct display_fill {
int x1;
int y1;
int x2;
int y2;
unsigned char mode;
};
struct display_shape {
int dx;
int dy;
int wx;
int wy;
int color;
struct display_fill saved;
};
void Bdisp_ShapeBase(unsigned char *work, struct display_shape *shape, int color, int line_width, int zero1, int zero2);Register to Join the Conversation
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement