How can I compile asMSX in windows 10?

Pagina 2/2
1 |

Van Giangiacomo Zaffini 2

Master (167)

afbeelding van Giangiacomo Zaffini 2

16-03-2019, 10:51

@gdx
Thank You. I will try Zasm soon.

Van bore

Expert (115)

afbeelding van bore

16-03-2019, 11:54

vasm also have support for phase/dephase.
Haven't tried to compile it for Win10, but it was easy to compile for both Amiga and Win7. (No external dependencies or POSIX reliance, just plain ISO-C)

Van dhau

Paragon (1557)

afbeelding van dhau

19-03-2019, 03:57

Giangiacomo Zaffini, it is fantastic you figured out how to compile winflexbison from source.

But I think it is easier to to install winflexbison on Windows using Chocolatey.

Once you installed chocolatey package manager, you can install winflexbison with the following command:
choco install winflexbison

Van dhau

Paragon (1557)

afbeelding van dhau

19-03-2019, 04:16

Metalion wrote:

I have used asMSX for years, and I was a great defender of that cross-assembler. But at the end of last year, as I developed a new and bigger game, I finally gave up and switched to sjasm.

Metalion, sorry asMSX didn't work out for you. I am glad you found sjasm to work well. Between fubu and I, we quashed a large number of bugs. Probably introduced some new as well Smile Hopefully it's more stable now. Robsy did amazing work with asMSX, it has many cool unique features. But it was written in C by an assembler programmer, and as a result, almost all variables are global, most code modifies global state directly. There are no unit tests at all. Code is large enough that following through on what is going on is difficult.

What I did is use available static code analyzers (cpptest and vs2017 analyzer) and compiler warnings (gcc, clang, vs2017) and fixed the code until most of those warnings were addressed.

What fubu did is use valgrind on debug build to find potential memory leaks and address those.

What we want to do is to stabilize the code further, by moving all the logic to small, stand-alone, pure functions. Those functions would be composable and testable. And they would never touch any global state. All input and all output would be done via parameters and return. This would allow us to add test coverage for most of the code. Once the code is covered, we can start debugging lexers and parser, add new features like externded macros, inline sprite definitions, built-in data cruncher and so on, confident we won't break the functionality that's already working.

I understand there are better assemblers, but I don't want to see asMSX languish behind. For me it is an interesting challenge in refactoring. If we manage to make the code modular, testable and easy to understand and follow, I'll be very happy.

By the way, my most recent PR fixed broken wav writing code that didn't work since the original GPLv3 release by cjv99. To do this, I first wrote a python prototype, got it working, and then wrote equivalent C code.

Van Metalion

Paladin (1013)

afbeelding van Metalion

19-03-2019, 18:10

And I respect the work on it and the vision that you have ...
But that 'NOP' bug is really annoying and still not solved with asMSX v.0.18.4
I think the team should address that specific problem as a #1 priority.

PS : Now I remember that, actually, the event that made me switch to another cross-assembler was that asMSX just stopped compiling my code. It refused to compile it. Even after restart of my computer, or changing some minor détails in the code. It just refused. Just a single line on screen saying "unable to compile" or something like that. That was the last straw.

Van fubukimaru

Rookie (28)

afbeelding van fubukimaru

19-03-2019, 19:59

Thanks for the feedback Metalion.
I hace still no clue about why the NOP bug happens, but I believe it is relates to the global state and the code tags from what I have seen. If we manage to refactor the code, as dhau says, into manageable modules it will be easier to trace that bug Smile.

Van dhau

Paragon (1557)

afbeelding van dhau

19-03-2019, 23:48

Metalion wrote:

And I respect the work on it and the vision that you have ...
But that 'NOP' bug is really annoying and still not solved with asMSX v.0.18.4
I think the team should address that specific problem as a #1 priority.

I'd like to do it, but neither of us can reproduce the issue.

Are you using Windows or Linux version? Does it happen on a specific asm file or on any asm file? If you have a specific asm file, would you be willing to share it with one of us either privately through an email or better yet through a github issue?

I'd really appreciate your help.

Pagina 2/2
1 |