| Author |
Message |
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
 Posted: 03 Dec 2007 02:32:52 pm Post subject: |
|
|
It's been a while since I've updated this project, eh? I'm still (slowly) working on it, but you can expect a release sometime in the next week or so.
I've been running a few tests on Celtic III and I've been writing some programs to test the app's practicality. I've verified that det command 24 (read list element from archive) works perfectly and outputs errors in the event something goes wrong, though I should probably add in a way to check the dimension of such list while it is in archive. I've also checked some of the commands used to extract picture files out of groups, and that works out well, too. With the testing, I found that I needed to include a way to check for free RAM, and if possible, a way to check for free archive space.
I'll be checking the display routines for stability and when I get the string and sprite routines down, I'll release Celtic III.
On a side note, I installed the development version of Celtic III on my calc and performed some of those needed tests. I somehow broke the application's interface and that crashes, but I'll have it fixed ASAP. I say this because I was able to work around installation by writing an ASM program not unlike the one that is included in the distribution to autoinstall. Hooray for work-arounds :)
Some feedback would be appreciated. Perhaps easy-to-implement features in the feature request thread? |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 17 Dec 2007 07:17:19 pm Post subject: |
|
|
Alright. It's not quite in a "release" state yet, since I've got a few more things to add in, and a feature I want to modify (fix), but so far, this is what happened since the last update.
For the det() tokens:
I fixed command 21 to work properly, and I added in more documentation for it.
For the string tilemapper, I added in command 22 and 23 to convert the hex string to and from binary, respectively.
I added in a command that'll allow retrieval of elements from a REAL type list from archive. Putting in zero as an input is the same as retrieving its dimensions.
I added in commands 25 and 26 to check for amounts of free RAM and ROM, respectively.
I added in command 27 to check for the size of any entry in a group.
Command 28 was placed because it needed no input and it wouldn't work as an identity command because of the app's input checking. This command is used to update the screen with the contents of the screen buffer (plotsscreen)
Command 29 was added in to execute a hex string on the spot. The limit is 768 bytes squished and it is executed from the savesscreen buffer.
Command 30 (WIP) is used to convert a REAL type number to a string. It *should* support decimals of all kinds and scientific notation. Keep in mind that if any number contains *only* fractional parts (numbers between 1 and 0), it'll fall back on scientific notation regardless of the number. Later, it'll support conversions of lists and matrices (both real type) to strings.
For the identity() tokens:
All pic files are named weird still. Check the ReadME for information on the naming schemes.
Command 6 was added to toggle an image file between RAM and ROM given its number.
A command (7) was added to display a Pic file given its number using either an overwrite method or one of the three bitmasks against the buffer.
Commands 8 and 9 were added to assist in extracting pic files from groups.
Command 10 was added to display a binary string tilemap. See det() commands 22 and 23 and the ReadME for this command's usage.
Commands 11 and 12 for the identity() set have not been tested yet. You might try command 12, but do NOT try command 11. They're not properly documented, but if you still want to try to use the commands, then you can read the source under _utility.asm to find how they work (usage is in the comments).
The error list has expanded a bit since the last time I updated. I'm pretty sure the readme is so far complete as to what the possible error codes are.
And as a final word, Celtic III now compiles to around 9.5K, so enjoy this half-full app. |
|
| Back to top |
|
|
vuurrobin
Advanced Member
Joined: 09 Aug 2006
Posts: 428
|
| Posted: 21 Dec 2007 07:57:44 pm Post subject: |
|
|
I am currently busy with finishing my gamepack, but after that I will test this out.
I did look in the readme and I noticed some things. first of all, you forgot to include the token table.
second, I notised with the tilemapper that you need to give the width, but not the height. also the width must be bigger than 12. I suggest to let people also input the height and let the width be smaller than 12 so people can use a HUD for health, money ect. or have an scrolling map like in the xlib demo.
thirtly, there are some commands that are missing and that will be usefull for this. I will post them in the suggestion topic later since I don't have much time now.
and lastly, you may want to advertise this on other sites like omnimaga, so more people can use this.
great job so far. |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 08 Jan 2008 01:27:12 pm Post subject: |
|
|
vuurrobin wrote: ...
second, I notised with the tilemapper that you need to give the width, but not the height. also the width must be bigger than 12. I suggest to let people also input the height and let the width be smaller than 12 so people can use a HUD for health, money ect. or have an scrolling map like in the xlib demo.
...
[post="117599"]<{POST_SNAPBACK}>[/post]
The "width" property is there to give a two-dimensionality to a one-dimensional structure (strings). Because I never intended on the user displaying material outside of the tilemap, I never considered a height feature to be necessary. The best I can do about "windowed" tilemaps at the moment is to provide a way to stop displaying on the right and bottom edge of the map, though if I can rework something, I'll allow two more arguments (on top of the two I implied) that'll allow the tilemap to not draw on the top and left side as well. I still consider it the user's responsibility to not draw material that is outside of the tilemap since coding in potential bounds problems is not on the top of my priorities.
---
In other news, I've begun to implement complete xLIB compatibility. That would basically mean you can swap xLIB out with Celtic III and the program that use xLIB should never notice the difference.
So far, I've coded in the following features, taken from the ReadMe of xLIB v0.602b:
cmd 00 : clear screen
cmd 03 : recall pic
cmd 04 : scroll screen
cmd 05 : change contrast
cmd 06 : update LCD
cmd 07 : Run indicator
cmd 08 : getkey (with enhancement "A")
cmd 09 : create pic
cmd 10 : execute archived prog (with enhancement "B")
cmd 11 : get calc version
cmd 12 : draw shape (box only, still coding line part)
cmd 13 : text mode
cmd 14 : check RAM (same as the CIII's version)
I am missing commands 01 (draw sprite), 02 (draw tilemap).
Enhancement "A" includes the other possibilities of multiple arrow key presses, mapped to codes 150 to 156. Useful for DDR-style games where you may need to register the mashing of all four arrow keys.
Enhancement "B" involves the use of Celtic III's file handling system, which empowers the lookup of programs with the same properties of any of Celtic III's file lookup. That is to say, it also supports lowercase letters, appvars, and hidden programs only for the lookup. It will not apply any of these to the temporary program, as its name is predefined.
So far, the known limitation is that the box drawing will not handle small boxes appropriately. Something that will be fixed to allow for full compatibility. I also intend on building a line drawing routine (though I'd appreciate it if someone could help me with that), a tilemap routine, and a sprite routine so as to complete the list as defined in the ReadME.
If I have missed anything, including additional xLIB commands that was not mentioned in this list, please let me know.
Last edited by Guest on 08 Jan 2008 01:28:31 pm; edited 1 time in total |
|
| Back to top |
|
|
vuurrobin
Advanced Member
Joined: 09 Aug 2006
Posts: 428
|
| Posted: 08 Jan 2008 04:24:32 pm Post subject: |
|
|
awesome, the addition of xlib will make this even better (and there will be no doubt that it can replace xlib  )
the only 'feature' that it may miss, is the code to check if xlib is installed.
Code:
1
real(0
if ans
then
disp "install xlib
stop
end
just make sure that real(0 wont influence ans and it should be okay |
|
| Back to top |
|
|
elfprince13
Retired
Super Elite (Last Title)
Joined: 11 Apr 2005
Posts: 3500
|
| Posted: 08 Jan 2008 04:47:50 pm Post subject: |
|
|
wow, its been a while since I've checked up on this project, but seriously impressive work  |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 08 Jan 2008 06:15:51 pm Post subject: |
|
|
Hmm. I guess I can't wait. More or less, I just want a copy of the source code somewhere other than my flashdrive, since all those compile jobs must be taking a heavy toll on the flashdrive ( I know it's a minimum 100K writes, but... I'm trigger happy and each compile job performs more than ten in the same place).
Most of the xLIB functions are in place, except for the ones I mentioned in the last post. I fixed a behavioral bug that vuurrobin had the foresight to mention.
Now, test this one out. Keep in mind that I have not checked any of the xLIB functions (haven't the time at the moment) so be wary when you try to use them. The most important features of xLIB (the drawing stuffs) are not implemented yet, so I can say this is nowhere near complete.
The readme neglects to mention a few things, including the "draw box" command in the identity series. Fortunately, you can access pretty much the same thing using the xLIB compatibility. A copy of tr1p1ea's readme for xLIB is included for as long as he doesn't complain about it and as long as I need to have it in there.
There are two versions of the readme for Celtic III. "ReadMe3" is not finished yet, and "ReadMe2" is the current version. Tell me which one you like better.
Also, I've included the token table in this package.
The compression option is still not supported for picture database entry. Don't try to use it yet.
I also forgot to mention and neglected to change the readme to reflect the fact that variable to string conversion *should* work now. You'll want to test this one out, but remember that any number between 0 and 1 will have scientific notation forced on it. |
|
| Back to top |
|
|
vuurrobin
Advanced Member
Joined: 09 Aug 2006
Posts: 428
|
| Posted: 10 Jan 2008 04:13:31 pm Post subject: |
|
|
I like readme2 better than readme3, having the number and name of the command in a different colom makes it easier to search for a command. also, as you said, readme3 is incomplete and misses the explanation for some commands.
I do like the input including what can be omitted and the output (if any). but make sure that with omitting arguments, that you include the ",", since that must be omitted to  |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 28 Jan 2008 11:19:22 pm Post subject: |
|
|
Just as a heads-up, Celtic III APP's command list is going through a major overhaul, so all those commands you've warmed up to is going to require a total rewrite.
Most notable is replacing det(0) with a functional equivalent that does away with seven scattered commands, and the other commands have been moved back to reflect those changes. I'm going to write an updated ReadME file (with a newer-looking format) that will explain those changes a bit more clearly. |
|
| Back to top |
|
|
tifreak8x
Elite
Joined: 27 Aug 2005
Posts: 956
|
| Posted: 29 Jan 2008 09:06:03 am Post subject: |
|
|
Glad I still use C2 then. :)
Will this rewrite open up some space to you? |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 29 Jan 2008 02:49:47 pm Post subject: |
|
|
tifreak8x wrote: Glad I still use C2 then. :)
Will this rewrite open up some space to you?
[post="119654"]<{POST_SNAPBACK}>[/post]
Maybe. This rewrite will, however, allow me to possibly add in a few functions that could've been useful but were absent from the orginal. Mostly, this rewrite is a consolidation of commands so that there are less commands to sift through. The consolidation will (hopefully) make each command a little easier to use. While I'm at it, I'll shove some of the more useful commands up to the top of the list.
This rewrite will also help solve a couple of issues I've always known about but never told anyone.
So, if anything, this will cause the application to bloat up by a couple hundred bytes. No worries, right? I've got 4K remaining in the app and just about everything I need is already there. I mean, 4K might be a little tight if one were to add features, but definately a load of elbow room if a few features needed to be fixed. |
|
| Back to top |
|
|
vuurrobin
Advanced Member
Joined: 09 Aug 2006
Posts: 428
|
| Posted: 04 Feb 2008 06:10:30 pm Post subject: |
|
|
I think that 4k is more than enough for some functions, most functions range from 50 to 500 bytes, and celtic 4 needs the functions to be less than 7xx (somewhere in the 700 ish) bytes, right?
I hope you can free up some space and I can't wait for the new release |
|
| Back to top |
|
|
Art_of_camelot
Member
Joined: 05 Jan 2008
Posts: 152
|
| Posted: 04 Feb 2008 11:48:35 pm Post subject: |
|
|
Quote: I am missing commands 01 (draw sprite), 02 (draw tilemap).
Do you intend on adding these two features in? Personally I think draw sprite is the *much* more useful of the two, as a programmer can write their own algorithm to draw the tilemap. |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 05 Feb 2008 12:11:22 am Post subject: |
|
|
Art_of_camelot wrote: Quote: I am missing commands 01 (draw sprite), 02 (draw tilemap).
Do you intend on adding these two features in? Personally I think draw sprite is the *much* more useful of the two, as a programmer can write their own algorithm to draw the tilemap.
[post="119972"]<{POST_SNAPBACK}>[/post]
If you had read the entire post you quoted that from, you would find the answer to that one.
---
On another topic, I've got another ReadME on which this version of Celtic III will be modeled. Clicky the attachment and give it a read, and tell me what you think.
Keep in mind that the build I currently have does not have those features in that order quite yet, so it'll be a while before I release the next version in that way. While I'm rearranging things, though, I might find it easier to address a few feature requests. I've already resolved the getkey bug, but if you want an immediate fix, just reassemble the app with the "CPL" command right before the "AND $0F" underneath the label "getKBDSC.6:". That *should* fix that. I say this here because this doesn't really deserve its own post in the bug reports forum indicating that the problem was fixed.
Those sprite and tilemap routines are a pain to implement. Sure, the concept is pretty easy, but all those conversions and keeping track of which register does what before the tilemap is reconstructed is... icky. Shouldn't complain about this, though. With enough though, this'll be solved just like any of my other problems I've had to wade through.
vuurrobin: Most of those additional features you suggested in the other topic should be able to fit in less than 200 bytes. Maybe even less than 100. The linking feature, however, would take not only space, but some thought as to how to implement it reliably.
Edit: There are romcalls used for linking. Exactly what kind of kind of "link" do you think the calc should support?
Edit2: I found that adding in support to check the first five bytes of the serial (best I can do so far) and the calc's OS version number totals to about 40 bytes. Yays.
Last edited by Guest on 05 Feb 2008 07:34:52 pm; edited 1 time in total |
|
| Back to top |
|
|
Art_of_camelot
Member
Joined: 05 Jan 2008
Posts: 152
|
| Posted: 05 Feb 2008 08:16:56 pm Post subject: |
|
|
| My apologies. I read the entire post, however it seems I somehow missed that part the first time through. |
|
| Back to top |
|
|
vuurrobin
Advanced Member
Joined: 09 Aug 2006
Posts: 428
|
| Posted: 07 Feb 2008 04:08:48 am Post subject: |
|
|
I like the readme, explains the commands good and easy to search something.
Iambian wrote: Edit: There are romcalls used for linking. Exactly what kind of kind of "link" do you think the calc should support?
if the other calc is connected, has celtic3 installed, and is bussy with some code, then preferrably:
send var: sends and stores a variable to the other calc
get var: get a variable from the other calc and returns it, so we can use it in other commands and so it won't overwrite variables on this calc.
check linkport: check to see if the linkport is bussy, so you would know when that 10 kb list is finished sending. and maybe a check to see if the calcs are connected?
dunno if this is all possible, though.
Quote: Edit2: I found that adding in support to check the first five bytes of the serial (best I can do so far) and the calc's OS version number totals to about 40 bytes. Yays.
[post="119976"]<{POST_SNAPBACK}>[/post]
|
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 25 Feb 2008 07:34:22 pm Post subject: |
|
|
The best part I can say is that I'm still rearranging the command lists, but mostly this is for the PicArc functions ( identity ). I've also rewritten the parser hook so that it should (hopefully) faster and easier to work with. Mostly the "easier to work with" part, since the way I had it before, the arguments that get popped off the stack stay in reverse order when I need to use the values. This time around, I've got it so that it's in forward-order, making it much easier for me to ignore missing arguments (preset to zero). This is important since I can directly reference the numbers I store on the table instead of having to load values from an offset and risk a buffer overflow if the user "forgot" an argument or two.
I've also rearranged all of my code so that it's far easier to manage. I've also documented all of the subroutines in some of my new files since it was getting tedious going through all those lines and re-read code to determine what input or output each subroutine took or gave out. I've also cleaned up some code and taken out bits and bytes where the code either got redundant or where I noticed a patch of obsolete code leftover from previous revisions.
On another note, xLIB integration is going terribly slow. It should've been done already, but I've always dreaded implementing those tilemap and sprite routines. |
|
| Back to top |
|
|
vuurrobin
Advanced Member
Joined: 09 Aug 2006
Posts: 428
|
| Posted: 17 Mar 2008 05:33:49 pm Post subject: |
|
|
how is progress. maybe you can give us a beta version so we can get used to the rearanged command list  |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 20 Mar 2008 02:04:14 pm Post subject: |
|
|
I know it's been a while since I last stopped by with anything regarding anything, but to tell you the truth, I haven't really been working on the application. I just ran a few tests to ensure that Celtic III basic set of functions (lineread and linewrite) still work with this revision, but I'm just "assuming" that everything else works. Absolutely none of the PicArc functions (identity) is expected to work, since that had the heaviest amount of revision.
This is what I have so far. I apologize for the long wait, even though I know this version will most likely disappoint. |
|
| Back to top |
|
|
Liazon
title goes here
Bandwidth Hog
Joined: 01 Nov 2005
Posts: 2007
|
| Posted: 20 Mar 2008 07:42:57 pm Post subject: |
|
|
| take your time man. not all good things come from rushing ^^ |
|
| Back to top |
|
|
|
Celtic III => Your Projects
