Beta 4 Released
Posted 17 September 2006 - 02:55 PM
For all of you who thought this day would never come: The Beta 4 of MLC2 is out.
The string system has been fixed and is working wonderfully.
Additionally some more bugs have been fixed and changes have been made.
Here is an (uncomplete) list:
Added VM Setup menu (AC/On Key)
Added Source View to Debugger
Added Data View to Debugger
ADded Stack views to Debugger
Added Extra view to debugger
Changed the whole string system to support transparent strings and garbage collection
Fixed 0 not displaying as white but as transparent
Fixed white printing
Fixed rectangles printing slow/wrong when x0 > x1 or y0 > y1
Fixed mouse bound checking that was missing from previsous release
Fixed mouse_Flag reset that lead to program "remembering" mouse press
Fixed Integer conversion routine not working correctly for 256 - 999
Fixed Bug where pointers were not enforced
Fixed Bug where too many arguments on line were ignored
Fixed Bug where FunctionName could only be the last argument of a command
Fixed Bug with new Color functions
Fixed Bug where color was not correctly restored for an internal handler
Introduced overflow handler, not yet working
Initial support for negative numbers (please do NOT use them just yet!)
Marked missing entry check for FOR loops as feature instead of a bug
(especially looking at the neg numbers that would render this check impossible anyways)
Replaced WriteWord with WriteByte in FOR loops. Old command caused wrong addition to be executed resulting in a corrupted stack.
Fixed RET from main routine not leading to termination but needing a prior HALT command.
Fixed CCSTR beeing a memory leak and rewrite it including a "garbage collector" for strings.
I also fixed the Static strings bug.
Fixed some other minor bug
Added the String viewer and used the "right" endian format there
You can not join more than 2 strings. Please use multiple lines or temporary variables to do this. This will be fixed in the next verison.
The Restart Program entry in the debugger does NOT work. I don't know if this is going to be fixed at all...
The 2 known bugs should not bother you right now. They are not major problems and will be fixed ASAP.
You know the drill, as always. Install OS.exe (uncompressed) or OSU.exe (compressed) on your calc to test
the system. Programs are still built in and can be updated like in the previous builds.
Dont forget to call make.bat after changing the mlcsource.inc file!
Please do also not forget that you can tweak the program by changing config.h (but please include you config.h if you changed it and do report bugs and do also tell me if the bug does occur with the default settings as well)
Have fun and happy testing. I'm awaiting your bug reports while I'm coding the conditional statements and
the key management. (which sadly are not in this release due to lack of time).
Posted 17 September 2006 - 05:01 PM
Here it is: http://www.mh-dev.com/Beta4R1.rar
Posted 18 September 2006 - 09:50 AM
And now shall we test...
Posted 19 September 2006 - 12:03 PM
Installing on the calc & testing...
Posted 19 September 2006 - 12:31 PM
Posted 19 September 2006 - 12:52 PM
"Ver: 000/Beta 3"
And now for the problems i noticed. I've been testing the MLC with the default OS.exe supplied with it.
- After entering the VM menu, there doesn't seem to be any way to exit it, except for choosing any option
- Trying to choose "restart program" not only doesn't work (as you said), but also crashes the calc - only "p" reset helps (and results in clearing of main memory btw)
- Choosing "exit MLC2" launches debugger instead of actually quitting the mlc. Exitting the debugger now crashes the calc ("p" reset => main memories clear)
- the VM menu still works in the debugger called after attempting to exit mlc, allowing you to launch another instance of debugger. What is interesting, it works normally, and after exiting it you are returned to the previous debugger. Trying to exit this one ends up just like described above.
- I don't kow if it's a problem with mlc code, or vm, but the screen isn't cleared at all - mouse cursor leaves an ugly trail behind it.
- After a program ends its execution normally, MLC breaks into the debugger (just like after trying to quit MLC), and crashes after trying to exit it. Also the mouse cursor is still being drawn in the debugger (it doesn't happen when entering debugger any other way).
- I debugger's sources view, you can only scroll the screen down, scrolling up doesn't work.
Anyway, you've done a great work on the mlc - keep it up . I can't wait to see next versions
Posted 19 September 2006 - 01:53 PM
(WARNING! This version does contain some experimental code for negative numbers! Please DO NOT use them in your source code. They are highly unstable!)
Posted 19 September 2006 - 03:01 PM
- Restarting program still crashes the calc and clears main mems
- Trying to exit the debugger restarts the calc AND sometimes clears the main memories - at least you don't have to reset it manualy
- The screen does get cleared prpperly now.
Posted 19 September 2006 - 04:11 PM
I can only fix the clearing of memories when I am able to connect the calc to the PC again. Right now I can only test with the emulator, that does not reset memories (logically ). THE REBOOTING IS STILL INTENTIONAL.
Please set exit_Method in config.h to emTerminate and test if it does exit to the main menu. It might crash the calc then but is worth a try. It should currently be set to emReboot (reboots calc on exit)
However, I'm back to my PC next week but won't get internet again till the following weekend. (unless I can use the internet at the university hotspots. I'll see ...)
So please test as much as you can and report all bugs except those above till saturday. This is the last day I am here.
Posted 19 September 2006 - 06:26 PM
(emTerminate) => Exiting the debugger after rogram ends its execution normaly only reboots the calc, si it's fine, memory get cleared only when debugger is called from VM menu by attempting to exit mlc2.
(emReboot) => just like above - if program ends normally, mlc exits to the menu without any problems, but when it's interrupted by calling debugger from vm menu, exitting causes a crash with artifacts on the screen.
For restart program option - can't you disable it, if it's not used, liks save and load options? Now it's easy to hit it even accidentally
And btw, it seems that folder name in the archive is still one version backward - a folder beta3R1 sits in the archive beta3R2.rar
Posted 19 September 2006 - 07:46 PM
Thanks for your extensive test. I think I do know now where the error in the program lies. If it only fails after calling the debugger then it could be an error with the programs stack. Maybe I can even figgure this out without the calc. I'm not arround tomorrow, so expect more on thursday.
Also I got the negative numbers in. They even work for for loops and are quite stable now (well there were only about 2-3 dozend lines that needed to be changed. So easy I will do some more test with the multiplication and stuff to ensure that everything works and then put this and the other fixes in the Beta4R3.
Beta5 will (hopefully) include Keyboard Support, Conditional Statements and Timer Support.
This should enable you to write the first interresting games.
Beta6 is aiming for the sprites (without animation!) then.
Beta7 is aiming for external source code support. (hope I can write an editor till then)
Beta8 is aiming for another interresting feature that I'll call "JNR Maps". More to be announced later, but they will be extremely helpfull to code "commander keen" like games!
Yeah, I'm always behind with the version numbers .... Well I try to do better in Beta5 or Beta4R3 ... but I know me... Expect Beta4R3 to be called correctly
In the meantime have fun and thanks for your extensive tests & your interrest in MLC2
Posted 26 September 2006 - 04:50 PM
i have a suggestion about the sprites: (so you have time to think of it )
I wonder if it would be possible to create a function which could draw a sprite in the other side...
by this I mean:
If we have a sprite "(==>" for example the function would enable to draw the sprite like this "<==)"
It would be pretty useful too every sort of game and would save a lot of memory (it prevents to create twice more sprites...)
Posted 27 September 2006 - 12:44 PM
Great work Huhn_n but I don't success to write programs. I don't really understand why.
Posted 27 September 2006 - 01:00 PM
I'd never seen it before, but i'm happy because
it 's far most greater than I have just suggest
Posted 29 September 2006 - 06:33 PM
give me the code you put into the mlcsource.inc file and
the error the compiler outputs or the intended/seen behaviour.
I have some problems with my freenet DSL so I can't access the forums (probably for the next 7 days)
Posted 29 September 2006 - 09:12 PM
So I've only tested the default prog you made. It seems to be good, but sparkle a lot. I think you should make a virtual screen like in MLC 1 to avoid this effect.
Posted 30 October 2006 - 07:02 PM
Posted 31 October 2006 - 12:22 PM
Posted 09 November 2006 - 02:10 PM
Posted 11 November 2006 - 06:34 PM
have been implemented and work.
Boolean expressions are also implemented and do work partially (99%, some problems with brackets).
I'll not release the new beta until the keyboard system does work.
Posted 13 November 2006 - 05:04 PM
Continue like it. However, I hope you will increase the 99% success of boolean expressions up to 100%.
With conditions and keyboard, the first games will be able to come out. This is so good.
Have you corrected the issue I told you before with the editor ?
I hope the next MLC version won't delete memories, because when you forget it, it can be very bad...
Posted 13 November 2006 - 05:37 PM
but not longer (e.g.)
but this will be fixed soon.
I have the folowing operators:
= --> Equal
! --> Not Equal
> --> Bigger (only int)
< --> Smaller (only int)
=> --> Bigger or equal (only int)
=< --> Smaler or equal (only int)
There can be nested ifs and elses.
The problem with the memory is not (yet) corrected. It seems to be a stack error that is not easily traceable but I'll do my best
Posted 27 November 2006 - 04:40 PM
- FFII to close the IIFF condition : Why don't you use FEND. I think it's easier to remind.
- => and =< : Generally, it's use like >= and <= to not confuse with => as the implicate fonction.
If you think it's a lot time expansive for near nothing, don't mind me.
Are you advancing on the keybord utilities ? Have-you solved the other issues like boolean conditions, the issu I had with the export process (so I couldn't check the line drawing fonction)... ?
Posted 28 November 2006 - 09:52 AM
2) I'll see if I can do it easily. It is a quite minor change.
As for booleans, there are still implications that make them not work under certain conditions. I'll tell you these conditions upon release of Beta 5 if I have not solved them. In generall the main problem is if you have several booleans linked with & or | . If you have just 2 linked it works.
Keyboard utilities: Because I do intend to port MLC2 to the ClassPad after the Beta5 I'm still thinking about how to implement the best system that works on CP and on the AFX/FX/FX9860. I think I have the idea but was too lazy in the last time to implement since it is verry complex (but not too difficult. Just complex )
I'll do my best to get the Beta5 out in Dezember but don't expect it the first week. Also depends on the work I have at university (since I just engaged in a satelite project that I'm verry interrested in)
Posted 28 November 2006 - 05:15 PM
About the syntax I think the best to do is a vote. FFII has sens because it's like it close IIFF, however, FEND seems to be IfEnd and was used in MLC 1.
Posted 28 November 2006 - 07:16 PM
About you export problem: Can you tell me the exact error message? (and did you upload osu.exe? This is the compressed one and is recommended)
I correct myself:
FEND ist the end of a function. Conditional statments were 1 line in MLC1 (i think). I can not change it to fend unless I want conflicts with function ends.
Posted 29 November 2006 - 11:42 AM
IIFF / IEND
(IFEND would be easier to remember, but since all insctuctions are 4 letters...)
Somehow, the FFII doesn't really convice me. Of course, if it gets implemented it won't be very hard to get used to
And btw, everything compiles just fine for me.
Make sure you're give the name of target executable to the make.bat, preferably from command line (but also can be done by creating a shortcut to make.bat), like that:
Also, make sure that everything except the patr you want to compile is commented out in the mlccode.inc file (has ';' character at the begining of the line). If it still doesn't work, then maybe ry extracting exerything from the archive it was published in - it should work right out of the box...
Posted 30 November 2006 - 05:24 PM
And what about IFND ? I think users will get it quickly, because F an E are near each other, and it begins by IF.
Thank you for your helps about compiling, I'll try. I must be a silly man !! Or it's too much complex for most people. BTW, this problem will be deleted with the editor.
Huhn_m, do you think the conversion for classpad will be fast or long ? It's for us to estimate when to expect the beta 6.
Posted 01 December 2006 - 08:34 AM
Posted 01 December 2006 - 12:03 PM
I finally succed to export my files. The problem was with the make.bat : I've tryed to replace the make.bat and the pack.bat of the beta4R2 by the make.bat and the pack.bat of the beta3R1 and it's now functionnal.
I detected a bug with lines. I've written this prog :
mlccode: db 'ML2:',0 db '#FNCT MAIN',0 db '#CLRS',0 db '%B=0',0 db '#FORL 1,5,1,Yo',0 db '#SKEY',0 db '%A=0',0 db '#FORL 1,999,1,Fin',0 db '#HALT',0 db '#FEND',0 db '#FNCT Yo',0 db '%A=0',0 db '#FORL 1,10,1,DrawLine',0 db '%B=%B+10',0 db '#SKEY',0 db '#FEND',0 db '#FNCT DrawLine',0 db '%A=%A+1',0 db '#LINE %A+10,%B+1,%A+15,%B+8,10',0 db '#FEND',0 db '#FNCT Fin',0 db '#CSTR %A,*$A',0 db '#TEXT 2,30,$A',0 db '%A=%A+1',0 db '#CLRS',0 db '#FEND',0,0
Normaly, this should make some diagonals lines (like /////), but the calc makes verticals lines (like |||||) !!
About FORL, it seems to be ok from 1 to 999, so I think you debugged it well. However, it would be easier for programmers to have a variable change like in Basic Casio. I think it's not easy for you but I'll see this command like this :
FORL <init value>,<end value>,<step>,<var>,<function> (to compare with the basic command : For <init value> -> <var> To <end value> Step <step> )
So in place of :
db '#FNCT Yo',0 db '%A=0',0 db '#FORL 1,10,1,DrawLine',0 db '#SKEY',0 db '#FEND',0 db '#FNCT DrawLine',0 db '%A=%A+1',0 db '#LINE %A+10,%B+1,%A+15,%B+8,10',0 db '#FEND',0
We would have :
db '#FNCT Yo',0 db '#FORL 1,10,1,%A,DrawLine',0 db '#SKEY',0 db '#FEND',0 db '#FNCT DrawLine',0 db '#LINE %A+10,%B+1,%A+15,%B+8,10',0 db '#FEND',0
I really think it's much more easier to use.
And what about IFND ? And >= in place of => ?
About the VM : when a prog stop with the HALT command, we can quit the VM without a clearing memory, but if we press AC when the prog runs and then we quit, there's a clearing memory. If it can help you...
I'm a bit criticize today, excuse me, it's only because I want a perfect MLC 2 !!! However, you made a wonderfull work.
Posted 14 December 2006 - 02:55 PM
Posted 14 December 2006 - 04:28 PM
I'll look into the lines problem.
The for loop: This is already planned. The running variable is intended to be passed as parameter to the function is called. But for this to work I just have to implement the feature of passing arguments to functions When this is done you also have the running variable at the same time.
As for the relational symbols. I'll see what I can do. If it is easy to change I'll change it. Else I'll leave it.
Also thank you for your very valuable information on the memory reset problem. This will help me really much solving the problem. Also expect this to be fixed in Beta5 (thats what I hope).
I'm also sorry to say that the Beta5 will be pushed till the 1.1.2007 since I do currently have some commercial project running that I need to gather some money, so it has highest priority at the moment. When this is done I'll be right back to MLC2
I don't forget about this! THis you can be sure of (I did too much work that is still unnoticed because it sleeps in the engine and needs to be implemented into the compiler to awake )
Thanks for your question anyways since this tells me that there is interrest in the project and motivates me!!!
Posted 15 December 2006 - 12:52 PM
Posted 31 December 2006 - 09:15 AM
I had some commercial project running and some work with university ... so ... not too much time.
Posted 14 January 2007 - 02:15 AM
Then I will make a break in development for AFX and develop a Classpad version
Oh, I already started this. I had this project many months ago.
Posted 14 January 2007 - 09:51 PM
Posted 15 January 2007 - 09:48 PM
But, perhaps this is too hard for me (I never made a parser before ) then huhn_m could adapt his interpreter for ClassPad, and I'd implement it into an interface.
Posted 18 January 2007 - 03:29 PM
Posted 22 January 2007 - 12:39 PM
Posted 22 January 2007 - 07:19 PM
It should be compatible with AFX and TI games, but there may be some problems because ClassPad actually has only 1 grayscale
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users