18 replies to this topic

[huhn_m]

Download it here:

dead link

Just test the demo.
Me (or you ) will update the wiki asap.

Questions and bugs please here!

Next features:
Negative numbers
Arrays
Functions with parameters
(further suggestions?)


Warning: The config editor is NOT included due to a bug in my Delphi 2005 Personal Edition ... Maybe tomorrow. If you want to reconfigure the program (what should not be needed) then please edit the config.h manually.

And read the readme.txt! It is a current version!!!

[Deimos]

Looks nice, the mouse support seems a good idea
And there is a bug about it - you can move the mouse way out of the screen so it takes a while to get it back. It's especialy confusing if you move the curor beyond the right/left edge of the screen. it then appears at the oposite edge, just one row lower/higher, but obviously, doesn't work. I think you should add border cheking for the mouse.
I also observed another problem, but it might be just the example - after pressing the 'abort' button for a few times, the program freeses, and only resetting with the 'P' button helps.
I'll try to do more testing later.

[huhn_m]

Thanks. Seems as if I forgott the border checking. sorry
For the other thing I'll do some more investigation.

[SRM]

Beta 3 is great and your demo too. However, I corrected the demo. There was 2 important bugs about the progression bar. It didn't wait 27 seconds before exiting, but around 16 seconds (1 tick is 1/50 second not 1/30), and the progress bar continued a little after reaching the end. So here is the code :

mlccode:
	line0  db 'ML2:',0
	line1  db '#FNCT MAIN',0
	line2  db '#CLRS',0
	line3  db '%WaitTime=27',0
	line4  db '#RECT 9,19,100,60,10,0',0
	line5  db '#RECT 10,27,99,20,10,10',0
	line6  db '$Hello="Hello "',0
	line7  db '#TEXT 10,19,$Hello+"World",9',0
	line8  db '$Hello="Wait "',0
	line9  db '#PIXL 5,5,1',0
	line10 db '#TEXT 12,29,"Press Key"+" now",9',0
	line11 db '#MSET',0
	line12 db '#FRUN PAUSE',0
	line13 db '#CSTR %WaitTime,*$Number',0
	line14 db '#TEXT 10,37,$Hello+$Number+" sec ...",9',0
	line15 db '#RECT 15,46,97,49,10,0',0
	line16 db '#RECT 34,51,80,59,10,0',0
	line17 db '#TEXT 45,52,"ABORT",9',0
	line18 db '#MFNC MOUSE_HANDLER',0
	line19 db '#BREG 34,51,80,59,*%ID_Abort',0
	line20 db '%Counter=0',0
	line21 db '#FORL 1,%WaitTime*3,1,FORTEST',0
	line22 db '#HALT',0
	line23 db '#FEND',0

	line24 db '#FNCT PAUSE',0
	line25 db '#SKEY',0
	line26 db '#FEND',0

	line27 db '#FNCT FORTEST',0
	line28 db '%Counter=%Counter+1',0
	line29 db '#RECT 15,47,%Counter+15,48,10,10',0
	line30 db '#WAIT 17',0
	line31 db '#FEND',0

	line32 db '#FNCT MOUSE_HANDLER',0
	line34 db '#MOFF',0
	line33 db '#TEXT 1,1,"Moused",9',0
	line35 db '#WAIT 25',0
	line36 db '#FRUN MAIN',0
	line37 db '#FEND',0,0

I think you should add a button to force the interruption of the programme as AC/On. Because when there're bugs in the code, as an infinite loop, we must press the "P" button.

It could be a good idea to add a variable to the for loop. So we could use this directly in the loop function. For now, we must create a var to do it. I propose the syntaxe : FORL <var>,init,end,step,<function name>.

Is there a limit to the number of loop with FORL ? I've made a prog that lead to a strange calc behavior. Here it is :

mlccode:
	line0  db 'ML2:',0
	line1  db '#FNCT MAIN',0
	line2  db '#CLRS',0
	line11 db '#MSET',0
	line18 db '#MFNC MOUSE_HANDLER',0
	line19 db '#BREG 34,51,80,59,*%ID_Abort',0
	line20 db '%A=0',0
	line21 db '#FORL 1,33000,1,A',0
	line22 db '#FEND',0

	line23 db '#FNCT A',0
	line24 db '#CSTR %A,*$A',0
	line25 db '#CLRS',0
	line26 db '#RECT 34,51,80,59,10,0',0
	line27 db '#TEXT 45,52,"ABORT",9',0
	line28 db '#TEXT 10,10,$A,9',0
	line29 db '%A=%A+2',0
	line30 db '#WAIT 15',0
	line31 db '#FEND',0

	line32 db '#FNCT MOUSE_HANDLER',0
	line34 db '#HALT',0
	line37 db '#FEND',0,0

This prog should count from 0 to 32 767 with a step=2, and then make an error because of the limit. However, it count like this :
0,2,...,254,000,2,4,...,254,000,2,4,6,calc menu !!!
I don't understand why. I tried the same prog using %A=%A*2 in place of +2, and starting at %A=1, and it count like this :
1,2,4,...,128,000,1024,2048,... error.

So I think there's an error with 256, but I don't know if it's a var error or a string error or anything else. I think there's also a little error with FORL.

I'd like to see a command to return at the beginning of the function, as FGOB did it in MLC 1, because if we use FRUN, an error occure very quickly.

We can see : "Compilation finished"... on one of the starting sceen. It would be better if this screen was cleared after pressing a key. For now, the prog starts with this screen, so we must clear it ourselves.

I feel the mouse cursor is quite slow. Could you increase its speed ?

I don't get all about the mouse programming. Can we have some MFNC or only one ? What represents *%ID_Abort ? I don't understand what it is. How should I proceed if I want the user to make a choice between 2 boxes ?

On your demo, if I press EXE when I'm out the abort button, nothing happens (ok, it works), but after, if I come on the button, the EXE press have been memorised and the prog directly execute the mouse function. Is it a bug ?

Why mouse diag (up+left, ...) doesn't work ?

What's the difference between #CSTR %WaitTime,*$Number and #CSTR %WaitTime,$Number ?


You did well, so continue like this. It's amasing. Don't be discouraged by what I said.

[huhn_m]

Thank you for this verry verbose output!

1) Variables will be given as parameter to the for loop function (so this is why I need the parameters )
2) Thank you for the correction. I just made it as a verry quick test and didn't care much if it looked right ---

3) The Bug with the output. This was verry helpful info. I'll look into it this evening. I think it is a bug in the int2string routine. I'll look into this. Probably a problem with division. Or it might as well be a bug within the add command. I'll look into it. Promised. Fixed till the weekend since it is quite serious!

4) There is currently no overflow trapping. I'll add this too.
5) I'll make AC/On go to a menu with the VM setup but am not sure when I get to doing this.
6) What is the error that occurs on using #FRUN? Can you give a program to reproduce it? Would be nice. I COULD add the FGOB but actually would rather like to see the #FRUN working since it should provide the same functionality.

7) Compilation finished does not appear if you set the appropriate flag in the Config.h file. Just change the setting to start the program immediately.
I just set the defaults so that programs are more easy to debug since you
can see if the compilation worked flawlessly.

8) Mouse Cursor. Yeah. I think its too slow too. I'll look into the keyboard handing since the routine seems to have a problem with key repetition. Therefor a "dirty hack" was used to make the feature work for the moment.

9) The mouse ... well as I sait the function is quite tricky without function parameters. So first, no, you can have multiple mouse functions. New latest one will always be used. Second the *%ID_Abort is a pointer to the integer variable abort that gets a unique ID assigned with the button. As soon as the function parameters do work there will be a parameter given by the program that indicates what button was pressed. This will then be used in conjunction with the #IIFF statement to check what button was pressed.

So #IIFF %0=%ID_Abort,Abort

would run the function Abort if the first parameter (represented by %0) is equal to the abort button. This is also how choices will be allowed. Now this is more of a proof-of-concept or a nice gimmic but the mouse will be extremely helpfull when it is 100% implemented.

10) Yeah. This seems to be a bug. The EXE key should only trigger the mouse function if it is over a button (at least for now). I'll check this and correct it.

11) Diagonal mouse needs to be implemented since multiple keys need to be checked. This was not doable on the emulator so it will probably take a while to be implemented since till the end of march the notebook will be my only dev platform. I just don't have time to work on the "big" computer. Sorry.

12) #CSTR %WaitTime,$Number should NOT work. The * indicates that the value after is given as a pointer and the compiler should also enforce the use of the *. Else we might get unpredictable results. Doesn't it show a compile error if you do only use the $Number? I think this was needed for the function to work correctly since there is a difference in the explicit pointer expected by the * (it references to another datasegment I think)



I'm in no way discuraged! In contrast I'm glad that I get so much and verbose response by you. It even more makes me want to finish this project and lead it to an successfull end. Thank you a lot for the debugging. I'll address many of the things you mentioned in the Beta3R2 since there are serious bugs contained in this version obviously that need to be fixed. Don't nail me on a date but I hope to have most of the complaints fixed by next weekend or the weeked after.

Once again, thanks a lot!

[SRM]

6) You're right, without exemple, you can't understand. Sorry. I made this prog (I don't write all the #) :

FNCT MAIN
FRUN A
FEND

FNCT A
FRUN MAIN
FEND

The program is launched without compile error. But after a short half second, there's an error message. I can't remember if the message stay or not and what is written.

So, I think this program go quickly on the FRUN limit.

For now, I don't see a way to make infinite loops, as all games do. Perhaps the while loop will lead FGOB obsolete, but here, we need something like this.

12) I didn't see any difference when I deleted *. There wasn't any error message.


I made other tests. If we don't put HALT at the end of the prog, the calc doesn't return to the main menu, but continues to desesperatly do nothing. So, to help programmers, I think the FEND of the MAIN function should make the calc to exit the program. Else, the user has no other way than "P" button to exit.

I made some graphic tests. First, I did this :

mlccode:
	line0  db 'ML2:',0
	line1  db '#FNCT MAIN',0
	line2  db '#CLRS',0
	line3  db '#WAIT 50',0
	line4  db '%A=0',0
	line5  db '#FORL 1,128,1,POINT',0
	line6  db '%A=0',0
	line7  db '#FORL 1,128,1,LINE',0
	line8  db '#SKEY',0
	line9  db '#HALT',0
	line10 db '#FEND',0

	line11 db '#FNCT POINT',0
	line12 db '#PIXL %A,1,10',0
	line13 db '%A=%A+1',0
	line14 db '#WAIT 10',0
	line15 db '#FEND',0

	line16 db '#FNCT LINE',0
	line17 db '#LINE %A,3,64,32,10',0
	line18 db '%A=%A+1',0
	line19 db '#WAIT 10',0
	line20 db '#FEND',0,0

So, a horizontal line should be drawn due to a point repetition (FORL point), then a line should move with an angle (FORL line). However, nothing appears on the screen. I conclued you must have forgotten to put the command draw in their coding. Then, I tried an other prog to verify the issue didn't come from me. I replaced the point by a rect :

mlccode:
	line0  db 'ML2:',0
	line1  db '#FNCT MAIN',0
	line2  db '#CLRS',0
	line3  db '#WAIT 50',0
	line4  db '%A=0',0
	line5  db '#FORL 1,128,1,RECT',0
	line6  db '%A=0',0
	line7  db '#FORL 1,128,1,LINE',0
	line8  db '#SKEY',0
	line9  db '#HALT',0
	line10 db '#FEND',0

	line11 db '#FNCT RECT',0
	line12 db '#RECT %A,46,97,49,10,0',0
	line13 db '%A=%A+1',0
	line14 db '#WAIT 10',0
	line15 db '#FEND',0

	line16 db '#FNCT LINE',0
	line17 db '#LINE 1,3,64,32,10',0
	line18 db '%A=%A+1',0
	line19 db '#WAIT 10',0
	line20 db '#FEND',0,0

Here, the rect is drawn, but not the line. However, the rect that should start at the coordinate 0,46, started at 127 (or 126, I don't really remember but not 0),46. The coordinates 97,49, beeing > 0,46, the calc jump one line and continue from x=0.
So, graphically, I had approximatively this :

0000000000000000000000
00000000000000000000__
_____________0000000|0
000000000000|0000000__
_____________000000000
0000000000000000000000
0000000000000000000000

In place of this :

0000000000000000000000
_____________000000000
|00000000000|000000000
_____________000000000
0000000000000000000000
0000000000000000000000
0000000000000000000000


I hope you will easily debug this. Sorry for the hard job I give you. Perhaps I should wait the 3R2 release before testing again.

One last thing, the exit bug there was in the beta 2R1 desapeared, it's fixed. I was thinking you must know it.

Could you define again the color code ? In the doc, you say black is 6, and in your demo it's 9 or 10 (is 10 the code for inverse ? I'll test it). How much colours will there be in the last version ?

[huhn_m]

I corrected some bugs:

BUGS:
=================

FIXED: Mouse Bound Checking is missing
=================================

Mouse bound checking has been implemented. Small bug where the mouse is not clipped on the right.
The clipping is not implemented at all for now so bear with me Should be a minor thing.


FIXED: Mouse Click is cached (when clicking on non-button area and moving mouse over button without clicking function is triggered)
================================================================================
=

Fixed. MOuse_Interrupt Flag was not reset on all cases where no button was clicked!
Change reset so that all buttons are affected


FIXED: Number 256 is not displayed correctly (make for loop that counts till 1000)
================================================================================

Fixed. The bug occured because the divison for 3 digit numbers was only done on bytes.
However, 500 is also a 3 digit number and does NOT fit in a byte so the top most
chiffre was not shown. This has been corrected. Seems as if I was too eager optimizing


Overflows on numbers are not caught
=======================================

IntO calls implemented. Now only the Int4 handler needs to be written ,,,
(possible solution: call INTo after execution risky operations. Should not slow down execution too much ...)


Problems with stack in for loop (variables are not used correctly somehow ... need to check this)
================================================================================
===============

unresolved (does NOT seem to break the compiler. It works as intended. Need to talk to SRM about it ..)

as for the Function calls ... the maximum is currently 1024 Function calls recursively. It works, I tested it. You should better use an infinite loop or something. I will also introduce a #STOP command to make the program stop but I don't see a sense in this except for mouse only input.

For the line drawing I haven't found the bug yet. I'll lock into it. Promised. I also did a lot of the negative number alterations so expect the neg numbers to be used soon!

[huhn_m]

The bugzilla is now online.
It can be accessed under:

http://mh-development.de/bugzilla

The easiest way would be to just register there and file the bugs.
It helps me keep track of them and keep them in an order
and it helps you so you see the actuall reports and we can discuss each
bug on an individual basis.
Also we can keep track of the current status of the bug and in what release it will be / has been resolved

[huhn_m]

Yippie!

I found a fix for the bug with the for loops. Actually it is more of a workarround. I'll release the beta3R2 tomorrow. It has some more bug
fixes and even some new features!

To apply the workarround yourself set the memory model to mmIndependant in config.h This will add 1KB to the executable (uncompressed) but will
prevent the stack from going rogue!

Cu Huhn_m

[SRM]

Any news ?

[huhn_m]

I'm really sorry.
I got a lot to do at work, had a lot of work with a GF and found another bug after I fixed the last one.

I came to the conclusion, that there will be NO Beta3R2 but I'll go immediately to Beta4. The target features stay the same.
No release before march
I have no notebook so development could take some time
I finished my job so I have more time at hands now!

Again sorry, but I'm not dead

[SRM]

Do you think you'll be able to fix all the beta 3's bugs ? I hope so much. It seems to be very hard... Perhaps someone could help.

[huhn_m]

I fixed most of them.

The only thing left is a bug with the FOR loop.

If you set the memory management to mmShared then it taks ~120 iterations of the loop and the stack will somehow be altered in an unknown way. In the mmIndependant mode it takes about a thousand iterations but is still there. This is strange, since in independant mode the stacks are actually SMALLER ...

You could help ... just look at the sources and tell me why this difference is there between independant mode and shared mode while it is expected to be the other way arround. The relevant file is interpreter.asm in the inc directory. (and of course config.h for configuring )

After the stack has changed the program always continues after the for loop but it is not good anyways...

[SRM]

I'm sorry, but I don't have any skills in ASM.

[huhn_m]

ok. thanks though was wort a try!

[SRM]

Any news ?

[huhn_m]

nope

I have no time. Don't ask me why cause I don't know myself.

Maybe it is because this %()/"?/ Windows XP is so unresponsive on my dual-core processor. It freaks me out if I have to wait 5 minutes for the explorer to refresh. They HAVE to do sth. about it!

[2072]

hmmm... you should check what dlls explorer.exe is running, long refresh times can be related to third party "addons" that puts dlls in explorer.exe...

[huhn_m]

good idea. Will try that. Though it might be also some driver since until it shows "Starting windows" (the little window) it takes more than 2 minutes. I have a startup time of ~5 minutes on a freshly installed system! This seems crazy to me...