Hello there!

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 Debugger
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

Known Bugs:

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).

OOPS! I forgot the link

Here it is: http://www.mh-dev.com/Beta4R1.rar

great job!!!! And I reckon that I feared this day would never come.
And now shall we test...

It seems that you made a typo: the folder inside Beta4R1.rar file is named Beta3R1
Installing on the calc & testing...

lol. I took the archive of the beta3 and just put the new files in the folder overwriting the old ones. Never thought about changing the name, but anyways, I'm too lazy to do this now

Happy testing

It seems that you also forgot to change version number on the mlc loading screen too, now it's:
"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.

I'll try to do some more testing later.

Anyway, you've done a great work on the mlc - keep it up . I can't wait to see next versions

New Version: http://www.mh-dev.com/Beta4R2.rar

(WARNING! This version does contain some experimental code for negative numbers! Please DO NOT use them in your source code. They are highly unstable!)

Here are my observations for the new version, more will follow later, i don't have too much time now

• 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.

Restarting the program has not been fixed at all. I didn't even attempt to

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.

Some more detaled info:
(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

I think I fixed the issue with the "Program restart" at least partitially. You can restart it now about 6 times without problems. The sixth time it crashes but I'm still investigating why.

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

hello huhn_m
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...)

Samy : this fonction is designed in the doc.

Great work Huhn_n but I don't success to write programs. I don't really understand why.

yeah you're right
I'd never seen it before, but i'm happy because
it 's far most greater than I have just suggest

@srm:

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)

I think the issue comes from the make.bat. The 1st time, I used the "edit MLC source" to try your lines example. Then I put the EXE in the calc and the prog wasn't the one I expected (one with a cursor). So I decided to delete the EXE and restart the make.bat, and this one made an error, so no EXE was created. I don't understand why.

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.

Any news ?

Sorry. I have been involved with reverse engineering the 9860 recently. I will do sth. as soon as I find time. I Hope to have a version with keyboard support and conditions (IF etc) out by december. Then I will make a break in development for AFX and develop a Classpad version that should have the same status as the AFX version and will write a 9860 version as soon as we have a SDK. The sprites will only be developed when we are on the same level for all three applications.

A ClassPad verion... When? Hope it will come soon...

#IIFF <boolean expression>
#ELSE
#FFII

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.

Sweat !!!

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...

well, booleans do currently only work like:

((%A=10)&("B"!"C"))

but not longer (e.g.)

(((%A=10)&("B"!"C"))|("C"="C"))

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

After a small review of your topic, huhn-m, I have 2 very little syntax objections :

- 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)... ?

1) I used FFII because I thought it is easy to remember (like in bash, IF and FI) but if you like FEND more I'll change it. (it is no work. Just 1 string to change)

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)

Ok, all what I expect to you is to not quit the MLC 2 project.

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.

OK. I'll make a poll.

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)

*edit*

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.

And how about
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:
make.bat os

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...

Excuse me for FEND, it makes a long time not used.

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.

I think it will be rather long, since I'm a total noob at C++ (object oriented) and the tutorial is not a real help here ...

We should ask people if they want to do the classpad conversion. You'll earn time.

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 :



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 :


So in place of :


We would have :


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.

Nobody wana reply ?!!!

I'm really sorry. I had much work to do. I read your post but forgot to reply to it.

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!!!

Cu huhn_m

Yeah, I really think MLC2 will be a world star when it's finished, if it's finished one day (this only mean perhaps there'll be always upgrades for our greatest pleasure !!!).

I know, I know ... and I'm even sorry for it. I had much work lately and will not get the Beta 5 out during the next 2 weeks. I still hope it will be in january but you see, postponing release dates is my pashion

I had some commercial project running and some work with university ... so ... not too much time.

Oh, I already started this. I had this project many months ago.

Hi Kilburn. Could you tell us what you did exactly on your development ? You should share your informations with us. This way, we'll have compatible progs.

I didn't do many things. I started to build a UI, and I implemented Marco's font. But I'm thinking about a compiler now.... and my own variable management system.

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.

I think the one that could answer you is huhn_m himself. It could be a good idea for you 2 to work together.

Huhn_m, are you advancing in the beta 5 development ? We are really waiting for this !! Did you corrected the beta 4 bugs ?

If only I had an AFX... Well I think I've found my own variable management system and error handler. I've just started building the compiler now.
It should be compatible with AFX and TI games, but there may be some problems because ClassPad actually has only 1 grayscale