Experimental build system for MSX Basic Dignified and traditional MSX Basic on Sublime using openMSX.

Resident (39)

31-05-2019, 23:23

So...
There was I working on my Sublime Python installation when it came the time to install a new build system.
All was going fair and square until the moment I thought: "wait a minute!"

Well, I got a little carried away and a day and a half of pain and suffering later, here am I with a new build system for MSX Basic Dignified and MSX Basic in general on Sublime 3 (only on MacOS for now, sorry)

MSX Badig Build is on the same repo as MSX Sublime Syntax.
It converts the opened source to a chosen folder and file (settings via an .ini), open openMSX, load a save state (obligatory), mount the folder as a disk, turn throttle on (to speed things up, optional) and run the converted basic program.
To end the test just close openMSX.
It is not instantaneous but the whole thing is faster and maybe more usable than I thought it would be.

My initial ideia was to check if there was already a running instance of openMSX to avoid opening it every time but so far I couldn't figure out how to do it.

It is working like a charm on my computer but it has a lot of moving parts and I have no way to test it on a different environment. If someone is interested, please take a look, I would love some feedback.

Cheers.

Por Manuel

Ascended (19469)

01-06-2019, 00:03

Cool project!

Regarding MSX Basic Dignified: perhaps you would also want it to generate more optimized MSX-BASIC, with a minimum amount of lines, spaces and REMs. After all, this code doesn't need to be readable. The real source is readable.

Por farique

Resident (39)

01-06-2019, 01:09

That is a very good idea.
For now it can strip empty lines, labels, blank spaces and you can use comments that do not convert but that is it.
I wonder what kind of analysis and interpretation would be necessary to proactively concatenate lines together, remove variables on NEXT and so on.

Por thegeps

Paragon (1192)

03-06-2019, 08:12

Before removing spaces remember to avoid ambiguity: if you remove spacea from "ax or bx" it will be interpreted as "a xor bx"...

Por farique

Resident (39)

03-06-2019, 16:08

Straight to the TODO list.

# TODO: Move main program paths to .ini on Packages folder
# TODO: Maybe REM tags on the source with build instructions: paths and args
# TODO: Keep spaces on AX OR BX to avoid confusion with A XOR BX

Thanks, @thegeps.

Por Grauw

Ascended (10772)

03-06-2019, 16:22

MSX-BASIC variable names are at most 2 characters long, which is not very descriptive. Maybe you could allow for arbitrary length variable names, and automatically pick an unused 2-character one in the conversion.

Por PingPong

Enlighted (4140)

03-06-2019, 20:14

Quote:

MSX-BASIC variable names are at most 2 characters long,

like commodore basic that had it's heritage in microsoft.
however gwbasic allow more significant charaters on variable identifier. Was it done because of memory / resources restrictions?

Por thegeps

Paragon (1192)

03-06-2019, 22:11

Not only AX OR BX.. all variables wich second character is X... BX OR AX, CX OR FX, ZX OR AB (the problem is first variable that ends with X character)

Por farique

Resident (39)

04-06-2019, 01:48

@Grauw, that would be nice but I think I would have to mess too much into the Basic syntax to properly catch all occurrences of the variables. TODOed. Something for the future, definitively, along with the ultracompact mode suggested by @Manuel.

@thegeps, the way I think I'll implement it ignores the variables and focus only on the occurrences of "X OR" regardless of what is around (at that point in the code the quotes, rems, labels and data are stored so only instructions will be affected)
I had a somewhat similar problem creating the syntax highlight. FN from DEF FN IIRC cannot be uses as a variable so that was fine, but AS from OPEN AS, etc. can, so I had to be careful. AXORB, lucky highlights in the correct way.

Por farique

Resident (39)

04-06-2019, 14:58

...
Actually, if you declare the variables beforehand the problem goes away.
There is still the possibility of conflict if non declared two letters variables are used, but these are easier to solve.

Por farique

Resident (39)

22-07-2019, 15:47

Hi. Its been some time but I've updated MSX Basic Dignified.

I've implemented @Grauw and @thegeps suggestions along with bug fixes and other improvments.

It now supports variables with long names. You have to declare them but I think it is very straightforward. You can put them on a declare line: declare variable1, variable2, variable3 or just add an ~ the first time you use them.

I remade almost all the code and It is now a little more strict (instructions must have spaces separating them, stops execution on some errors, etc) but more robust.

I also refined the syntax highlight. There is now one for the Classic basic (.bas) and one for the Dignified version that now should use a .bad extension. This allowed them to be more specific.

Finally the build system is a lot more fleshed out, also treating Classic and Dignified code differently, I wouldn't call it experimental anymore.

The Sublime tools were moved to an new repo https://github.com/farique1/MSX-Sublime-Tools since it was no longer only syntax.

Hope you like it.

Cheers.