New beta release 1.2.7r2021

I've just sent you the files .)

[boriel]

Okay, version 1.2.7r2032 seems to have another fix. Please re-download and reinstall now and tell me
http://www.boriel.com/wiki/en/index.php ... nt_Version

Tested and working all right.

Thanks again Boriel

[boriel]

Okay, LCD was right. I''ve fixed up another important bug related to string parameters management.
Download, please, latest version which is 1.2.7r2035 from here: http://www.boriel.com/files/zxb

Please, test and tell me.

PS: Since v1.2.7, every released is tested against 100+ tests automatically prior to being released here. Please don't think I just throw new releases "as is" and leave all the heavy testing to you:!: Everytime someone discovers a bug, I create a new test to make the compiler fail. Then fix it. And finally apply all the previous test + the new one added before announcing it in the forum. So the number of tests is growing (the more the better, it's supposed ).

Also, LCD suggested me to create an .MSI to allow multiple installations of different ZXB versions. I think this would be hard, but there's a workaround: a ZIPped .exe version which does not require installation. So you can uncompress the .exe version of the compiler in a subdirectory. This will be uploaded soon.

Meanwhile, remember that the .py version can be used this way, and does not require any installation, just a Python interpreter installed.

Okay, LCD was right. I''ve fixed up another important bug related to string parameters management.
Download, please, latest version which is 1.2.7r2035 from here: http://www.boriel.com/files/zxb

Please, test and tell me.

Okay boriel, I'm downloading it now, but it is very late now. I will test it tomorrow later.

PS: Since v1.2.7, every released is tested against 100+ tests automatically prior to being released here. Please don't think I just throw new releases "as is" and leave all the heavy testing to you:!: Everytime someone discovers a bug, I create a new test to make the compiler fail. Then fix it. And finally apply all the previous test + the new one added before announcing it in the forum. So the number of tests is growing (the more the better, it's supposed ).

That was just a joke about the bugs in Strings . I know that you have tests, but we, the users, are elected to find bugs not covered by the tests . Our projects we are working on, are excellent way to find these bugs, because they are different from your tests and sometime cover unexpected way to code something. You should also know that your Compiler is my favourite retro-dedicated program for the PC. I hope, the Zacate notebooks are available soon, to make me a mobile retro crossdevelopment workstation.

Also, LCD suggested me to create an .MSI to allow multiple installations of different ZXB versions. I think this would be hard, but there's a workaround: a ZIPped .exe version which does not require installation. So you can uncompress the .exe version of the compiler in a subdirectory. This will be uploaded soon.

This will do the job too, and allow to test the latest compiler without changing between versions, if the latest version has a critical bug.

Meanwhile, remember that the .py version can be used this way, and does not require any installation, just a Python interpreter installed.

I know and installed python, but somehow it was not possible to compile anything. Maybe a Win7 32 problem. I will try on my WinXP system later too.

PS: Since v1.2.7, every released is tested against 100+ tests automatically prior to being released here. Please don't think I just throw new releases "as is" and leave all the heavy testing to you:!:

Don't understimate the power of crappy programing. One of my crap routines can easily beat 100 test routines

I'll test it tonight, I'm going to be out all the day.

My tests show that the build 2035 still has a problem with my game (working well in build 1866), it still blocks after 28 steps (72 AP left).

[boriel]

My tests show that the build 2035 still has a problem with my game (working well in build 1866), it still blocks after 28 steps (72 AP left).

The funny thing is r1866 has other bugs in the string params
Will check it. Thanks

My tests show that the build 2035 still has a problem with my game (working well in build 1866), it still blocks after 28 steps (72 AP left).

The funny thing is r1866 has other bugs in the string params
Will check it. Thanks

I know this fact that 1866 has other bugs, so I wonder myself why the game is working in 1866 but not in 2035. Maybe the 1866 bugs are less critical .

[boriel]

My tests show that the build 2035 still has a problem with my game (working well in build 1866), it still blocks after 28 steps (72 AP left).

The funny thing is r1866 has other bugs in the string params
Will check it. Thanks

I know this fact that 1866 has other bugs, so I wonder myself why the game is working in 1866 but not in 2035. Maybe the 1866 bugs are less critical .

It seems you don't use strings the way it caused the other bugs.
Basically, variables passed as byVal parameters from one function to another may (not always) crash your code. In fact, these bugs not always crash. The problem comes from a FREE pointer of a string value TWICE.

[boriel]

Okay, a new version, 1.2.7-r2044. Try this one. It seems it produces the same asm output 18xx did.
http://www.boriel.com/files/zxb

Yes, it does and the game works again. Thanks! So you took some optimisations back?

[boriel]

Yes, it does and the game works again. Thanks! So you took some optimisations back?

I haven't touched the optimization at all! It was in another part of the compiler. The string parameter management was wrong when calling a function with strings from *another function*. When fixing this, I broke "calling a function" from the *global program scope*. Now both work well (or should).

I'm now going to implement ucase and lcase function for strings. Many string functions have a duplicated implementation suffixed with "2", e.g. strpos2, in which all string parameters are passed by reference, because it's faster.

Finally, what has been done for the compiler preprocessor must be done for the compiler assembler (yes, a preprocessor for the assembler when its used standalone). Fortunately the assembler is much easier to test, and the preprocessor ZXBPP (the one of BASIC) can be reutilized.

Yes, it does and the game works again. Thanks! So you took some optimisations back?

I haven't touched the optimization at all! It was in another part of the compiler. The string parameter management was wrong when calling a function with strings from *another function*. When fixing this, I broke "calling a function" from the *global program scope*. Now both work well (or should).

It was because you said: "it produces now the same ASM Output as 1866, so please be not shocked, I misunderstood you .

I'm now going to implement ucase and lcase function for strings. Many string functions have a duplicated implementation suffixed with "2", e.g. strpos2, in which all string parameters are passed by reference, because it's faster.

Well, currently ucase and lcase are external librarys, so it is a excellent idea to make them internal functions. This will save more memory. As for "2" suffixed string functions: You say, we can use them like normal BASIC function, but pass parameters by reference and not value? This should be documented too.

[boriel]

Yes, it does and the game works again. Thanks! So you took some optimisations back?

I haven't touched the optimization at all! It was in another part of the compiler. The string parameter management was wrong when calling a function with strings from *another function*. When fixing this, I broke "calling a function" from the *global program scope*. Now both work well (or should).

It was because you said: "it produces now the same ASM Output as 1866, so please be not shocked, I misunderstood you .

I'm now going to implement ucase and lcase function for strings. Many string functions have a duplicated implementation suffixed with "2", e.g. strpos2, in which all string parameters are passed by reference, because it's faster.

Well, currently ucase and lcase are external librarys, so it is a excellent idea to make them internal functions. This will save more memory. As for "2" suffixed string functions: You say, we can use them like normal BASIC function, but pass parameters by reference and not value? This should be documented too.

The idea is to put them as external libraries, as most of the functions.
This make the compiler more portable to other archs.

That's the strong point of C. You will see C everywhere, because it's a tiny language with a big standard set of libraries. Unfortunately, there is not such a thing for BASIC.

I would like to implement also READ/DATA/RESTORE (in a limited way, at least) to improve compatibility, before this release.
1.2.7 is a "big step" towards 2.0. Unfortunately, except the new preprocessor most of ZX BASIC 2.0 should be rewritten *from scratch*
I'm even thinking in renaming the compiler to something like "ZXB" or "Retrobasic" or alike...