79 replies to this topic

[kucalc]

I just thought I would like to announce that I will be working on MLC for the fx-9860 if it's OK with the rest of you. Since discovering how to read and write data: http://www.casiocalc...?showtopic=3168, it's possible to now write a port of MLC for the fx-9860. My MLC will aim for compatible of the MLC for the AFX, as I believe the original MLC was first written for the AFX. The only thing that will be lacking in my MLC will be grayscales however, but all MLC games written for the AFX will be able to run on the fx-9860 with my port.

Anyways, I just thought I would tell you this, as it would be kind of cool to continue the MLC legacy for new generations.

[huhn_m]

nice thing

I clearly have mist alot during my absence I'll try to keep track of the development. Could you publish the sources once you have a first working build? Maybe I could join in then and we make it compatible to MLC2 as well

[kucalc]

Of course huhn_m! Me and Kilburn have been wandering where have you been.

[huhn_m]

I'm sorry but I had the final exams of my first term at university and somehow they ate all my time

I'll be here regularily again for at least the next 2-3 months

[SRM]

Happy return to home huhn_m !!! I can't stand for a new beta !!!

[huhn_m]

I'm still working on it. Everything should be fine except the keyboard system is not yet there. (and somewhere is a stack error that I can't find so you temporarily have to live with a reboot instead of a clean exit, but no corrupted memory)

As soon as I have the keyboard system sorted out expect the beta that will allow you some (more or less) serious gaming

[E_net4]

I'll keep my fingers crossed for you.
Go for it.

[kucalc]

I almost forgot that I had a responsibility. Don't worry. I spent the afternoon starting MLC for the fx-9860G. Let me update you guys on the progress.

Sorry to say, but it uses the MLC1 standard. I did it for two reasons:

1. I'll wait for huhn_m so we both of us can take it to MLC2.
2. The TI guys working on MLC for TI calcs still use syntax similar to MLC1. Or at least I believe so, I'll have to contact them.

Anyways, what I have managed to get strings, integers, text, pixels, lines, functions, lines and if statements implemented. Here's the latest build of what I've got done so far plus a few demonstration tests:

MLC for fx-9860G and Compatibles - Build 18082007

Just download MLC.G1A and the *.MLC files into Storage Mem and try out the tests.

Currently the following commands are working: #CLRS, #TEXT, #LINE, #PIXL, #DRAW, #PAUS, #FNCT, #FEND, #FGOB, #FRUN, #IIFF, #HALT and #WAIT.

Strings and integers works:

%X=%A+.1
$STR="Hello World!"

[samy]

good!!!
i was planning to adapt mlc on this calc since there were no news from you
but now i'm relieved: you will make it in no time! so i don't need to bother me on this!

[Madskillz]

This is awesome to hear...Man I got a lot of catching up to do. You Casio guys sure made us TI guys look slow! Keep it up!

[kucalc]

good!!!
i was planning to adapt mlc on this calc since there were no news from you
but now i'm relieved: you will make it in no time! so i don't need to bother me on this!

Lol, if you like, you can help me write the on-calc text editor. That way we can write MLC progs on our calculators.

This is awesome to hear...Man I got a lot of catching up to do. You Casio guys sure made us TI guys look slow! Keep it up!

It would be great if MLC TI-83+ will be finished. Is bfr still working on it with you?

----------

Ok, latest release build of MLC fx-9860 now additionally supports sprites, bitmaps, arrays and multi-conditional if statements.

Valid list of statements:

#IIFF %X>.0&%X<.128
#SPRT ^BALL [A
^BALL.X=%X
^BALL.Y=%Y
#ARRY @TEST .5
@TEST(.0)=.0
@TEST(.1)=.1
@TEST(%I)=@TEST(.0)+@TEST(.1)

The following additional commands are now supported: #PIXT, #SHFT (only along y-axis for now), #STOP, #RCLP, #RECT, #DBMP, #DISP, #GKEY, #WKEY, #DATA, #DEND, #BITM, #SPRT, #ARRY and #RNDM.

Download the latest build with examples: MLC fx-9860G - Build 20082007

The keycodes being using in MLC fx-9860G is nearly the same as MLC AFX. A text file showing the keycodes is included in the link above.

MLC fx-9860G source code will be soon uploaded to here: http://sourceforge.n...ojects/mlc-calc.

[samy]

yeahhhh i 'll be very pleased to help you in this "task", even if i don't program very clearly
moreover i will not be able to start the editor before 7 september (i still have got exams). If by this time you haven't finished it already, i will enjoy to try to code it!

[Madskillz]

Well as one of the original guys behind MLC I have really slacked off. At the time I was making a transition into a new programming group and was rather busy. It fell off my radar for about a year/year and a half until I found an old build. As of now I am the only 83+ coder, but the main shell is fairly complete. I haven't talked to bfr in about a month but I think he is still working on the 68k version. I will show everybody what I have gotten done probably in september. I will work on getting the 86 and 83+ fully compatible and then I wanna get it up to date with you guys.

[E_net4]

Man, I was going to lose hope on this project! I'm going to try it right now.
Also, why don't you explain the pieces of code you have there?

[kucalc]

Hey E_net4. Nice to see you here again.

A newer build of MLC fx-9860 is about to be released soon. As for a good explanation about the MLC language, take a look here: http://web.archive.o...=mlc-readme.php

[E_net4]

This IS good stuff.
And I must report that the Pong game example doesn't work for me. The ball does never reach the other side, as when it collides to the center, the other player scores/the game's over...

I'll be back with something nice!


Edit: ...Dang, I can't find the Sprites Maker. Where is it?

[bfr]

Cool stuff, kucalc.

[kucalc]

This IS good stuff.
And I must report that the Pong game example doesn't work for me. The ball does never reach the other side, as when it collides to the center, the other player scores/the game's over...

Yeah, I'm looking into the problem right now. But the interpreter is at a stage in that you can teach yourself and do some simple things with MLC.

I'll be back with something nice!
Edit: ...Dang, I can't find the Sprites Maker. Where is it?

I think Photocasio now supports MLC. It's in French, but you should still be able to use it: http://www.planet-ca...v...es&showid=5

Cool stuff, kucalc.

Hey, it's nice to see you here.

[iwantanimac]

Excellent. I posted the (Slightly) newer build's link on CK. Hope you don't mind.

This is great. Shame PONG is buggy =P

Now i gotta learn it. =D

[kucalc]

@iwantanimac: Ok, cool.

I've uploaded the sources to the fx-9860's portion of the MLC page. You can find it in the repository: http://mlc-calc.svn....LCfx9860/trunk/

Anyone is free to help find bugs and problems in it. Now that Revolution-FX v0.3 is out of way, I'll go and try to nuke these bugs.

[E_net4]

I think Photocasio now supports MLC. It's in French, but you should still be able to use it

Wonderful, thanks! I won't have much trouble with it. After all, I had 3 years of french in school.

By the way, what's the syntax of a Bitmap's Data? I really want to know this.

[kucalc]

For a 8x8 sprite:

First line: 8 bytes for the light gray buffer.
Second line: 8 bytes for the dark gray buffer.
Third line: 8 bytes for the bit mask. Used often for checking for collisions and transparency.

You have to write it out it hex code, but I'll try writing a on-calc sprites editor for the fx-9860G.

[E_net4]

Let me see what I understood:

........
........
...DL...
..DDDL..
..BDDD..
...BD...
........
........

Here's a bitmap.
D=Dark grey
L=Light grey
B=Black
.=White

Taking conclusions from your explanation, I realized that each byte of a line represents a line of the bitmap. And since each line has 8 pixels, then this makes sense.
Each byte has 8 bits, so each bit would be a pixel.
We could then create 3 blocks of binary, each one with 8 bytes, for each line of the data.
Now, I think the light grey buffer determines if a pixel is light grey or not, while the dark grey buffer determines this colour. If both values of a pixel are 1, then the pixel would be black. (is this right?)
Here's how it worked:

The first one would be:

00000000 -> 00
00000000 -> 00
00001000 -> 08
00000100 -> 04
00100000 -> 20
00010000 -> 10
00000000 -> 00
00000000 -> 00
The second one shall be:

00000000 -> 00
00000000 -> 00
00010000 -> 10
00111000 -> 38
00111100 -> 3C
00011000 -> 18
00000000 -> 00
00000000 -> 00

This one is for collisioning and transparency. For a precise form, every transparent pixel should be 1, non-transparent pixels should be 0:
11111111
11111111	 Do this yourself!
11100111  
11000011
11100111
11111111
11111111

Now it's simple. I just need to convert these bytes into Hex values and join them.

0000080420100000
000010383C180000
FFFFE7C3C3E7FFFF

Presto!
Phew, I'm smart. I better use my intellingence for something good to the community.

Note: I am not quite sure of this, so I request any necessary fixes to what I said. Thank you.

[kucalc]

Taking conclusions from your explanation, I realized that each byte of a line represents a line of the bitmap. And since each line has 8 pixels, then this makes sense.
Each byte has 8 bits, so each bit would be a pixel.
We could then create 3 blocks of binary, each one with 8 bytes, for each line of the data.
Now, I think the light grey buffer determines if a pixel is light grey or not, while the dark grey buffer determines this colour. If both values of a pixel are 1, then the pixel would be black. (is this right?)

Yep, that's right.

I've released a new build a MLC fx-9860. It has a ton of bug fixes, file system implemented and supports for sprite properties (to simulate acceleration). You can download here:

https://sourceforge....lease_id=536295

Now many MLC AFX games should run now. PONG works perfectly now. PHALANX (space shooting game), BOUNCE and RACE can also be played on MLC fx-9860.

However, #SHFT is not 100% yet and the bit masks should be used for sprite collision. I'll fix them later. But the games should be fun and playable now.

[E_net4]

Yay!

I am willing to test it right now. Let me tell you that I have a surprise for MLC users.
Just wait for tomorrow!

EDIT: *BEEEP!* I found bugs!

- After you scroll down the list of programs and then select up, the last program on the screen won't show up.
- In the game Phalanx, the ship doesn't quickly respond to my key presses.
- In the game Bounce at the third level, there are 2 lines as a part of the it. Sometimes the ball goes through them instead of colliding.

By the way, I suggest the light grey colour to be a little darker and the dark grey colour to be a little lighter.
The light grey forces the eye to see it, and the difference between dark grey and black is sort of un-noticeable. At least in here.

[kucalc]

Yay!

I am willing to test it right now. Let me tell you that I have a surprise for MLC users.
Just wait for tomorrow!

Cool, can't wait to see it!

- After you scroll down the list of programs and then select up, the last program on the screen won't show up.

Oh yeah, I forgot about that. I noticed that problem before. That will be fixed in the next release. But here should be no problems though selecting the last program.

- In the game Phalanx, the ship doesn't quickly respond to my key presses.

The game is actually suppose to be like that. What you are experiencing is acceleration. MLC allows sprites to have acceleration. It takes time for speed to go up and also it takes time for the ship to stop "sliding".

- In the game Bounce at the third level, there are 2 lines as a part of the it. Sometimes the ball goes through them instead of colliding.

I'm not sure if it's whether the game or the interpreter, but it's most likely the interpreter. I'll look into it.

By the way, I suggest the light grey colour to be a little darker and the dark grey colour to be a little lighter.
The light grey forces the eye to see it, and the difference between dark grey and black is sort of un-noticeable. At least in here.

I guess I could use 3 buffers, but I would then have to rewrite most of the graphics code and MLC will run drastically slower with probably a lot more flicker when it's reupdating the 3 buffers.

[E_net4]

Oh well... let's just make sure people don't use light grey for text or something you have to look at.
Also, I get to see some flickering in my calc, but I think it's because of the battery 'n' stuff... it's running low.

[kucalc]

Oh well... let's just make sure people don't use light grey for text or something you have to look at.

Yeah, it's also hard to see the light gray text on the AFX also. You can try adjusting the contrast of the calculator and make it darker. Another solution is to edit the MLC file itself changing the color from .1 (light gray) to .2 (dark gray) People like using light gray to make some things look settled or to annoy others.

Also, I get to see some flickering in my calc, but I think it's because of the battery 'n' stuff... it's running low.

You should get some rechargeable batteries. I use them and they're awesome. Haven't bought another pack of batteries for my calculator in years.

[iwantanimac]

Thumbs up for the new release. Working well here.

[E_net4]

I do use rechargeable batteries. In fact, they're being recharged right now.
The surprise is up! Gopher it!


OffTopic: Like my Avatar?

[kucalc]

The surprise is up! Gopher it!

Cool MLC sprite editor. Make sure you upload it to here: http://www.casiocalc....MLC.PC#totitle

OffTopic: Like my Avatar?

Looks pretty cool. You've got the fx-9860 in there.

[E_net4]

Um, not yet.
I will as soon as I release version 0.8. It has many differences from 0.5, in order to make things easier!
I hope this'll be for today.

Back on topic: Having to create an MLC program on the PC and sending it to the calc is exhausting. On-Calc MLC program editor is requested.

[iwantanimac]

Kucalc said he's working on it, so i guess we just gotta be patient.

[E_net4]

Pacience sucks.
And that's why I released version 0.8 right now!

[kucalc]

Back on topic: Having to create an MLC program on the PC and sending it to the calc is exhausting. On-Calc MLC program editor is requested.

Yeah, I told samy he could work on it. I'm sure he will work on it soon. But if not, then I guess I could work on it.

EDIT: Cool, 600th post.

[samy]

i've got an exam at the end of the week, after i'll try to do an editor.
I've a few questions:
-can you do like the mlc on afx, i mean the source code is in a program , so the editor would be an useful tool but not obligatory
-where are the source codes stored in the memory? (i mean did the interpreter looks for among all the directories or just in the root?)

[E_net4]

*poke* Any progress?

[kucalc]

-can you do like the mlc on afx, i mean the source code is in a program , so the editor would be an useful tool but not obligatory

I'm not fully sure I understand what you're saying. Do you mean the sources are in a separate file. If so, they are. If you open the MLC files you'll find the code. Or do you mean using the BASIC editor for editing the MLC files? I don't know if that's possible since I don't know.

-where are the source codes stored in the memory? (i mean did the interpreter looks for among all the directories or just in the root?)

They are stored in the in the root folder. They can be accessed though either the SD card or Storage Memory.

*poke* Any progress?

I'm still working on it. Don't worry.

[E_net4]

I've been experiencing some crashes when shutting down an MLC game. The calculator just stops and you are forced to use the reset button.
And how's the work?

[kucalc]

I've been experiencing some crashes when shutting down an MLC game. The calculator just stops and you are forced to use the reset button.

I have never experienced this. Are you running a program that you created? If so where does it occur?

And how's the work?

On-calc editor is now in the works. A PC version of MLC fx-9860 is also being planned. Official discussion of MLC fx-9860 has now been allocated to the UCPF: http://ucpf.programb...pic.php?f=5&t=8