All help testing the X16's new Blitz-style BASIC compiler welcome. Currently Alpha 1, so very early days
Much of the X16's extensions aren't yet implemented (just SCREEN, VPOKE, BIN$ HEX$) but should be done soon (most of them are just kernal calls). The core BASIC is complete (but probably has bugs, and other errors).
If you download and unzip release 1 it has everything to make it work, including the "balls demo", except Python 3. Windows and Linux only (though it should work on a Mac)
Trying to open any of the files just makes the emulator lock up until I reset it. Thinking I just have an issue with my stupid computer. Programs just don't work on it half the time. For instance, the creation kit for skyrim for some mysterious reason is missing files it needs to perform half its functions. Reinstalling doesn't fix this, and the issue is present in both the 'legendary' and 'special' versions. My anti-virus also won't let me run java programs I download from the internet, and it won't stop blocking them no matter how many times I tell it not to (it seems to think each time I try to one each program is a separate program entirely, meaning telling it to exclude it never works). I'm thinking here this stupid worthless machine just won't let me use the files. This computer is such a piece of trash. As I've said in another post, I've never even really seen this thing as a computer. To me its just a game console with a web browser, because that's all its good for! Fml...
How am I actually supposed to 'install' things? Dumping them in the folder where all my self-made basic programs go doesn't seem to work. On a side note, I decided to peek at the python files in the 'release' folder. There's one file in there called cat.py which is completely blank. What is that for?
At the moment it's early alpha for testing. It's not integrated into the X16 (yet). There's a file in the release called test.bas which is the file that is compiled to p-code and then run.
It should be possible in Windows to just extract it into its own directory and run COMPILE.BAT then RUN.BAT from the CLI. I've just download the file (release.zip) and it works.
cat.py does the same as the linux cat command e.g. concatenates files. It's there to make it easier to run under Windows. It shouldn't be empty (it's only a dozen or so lines but it's not empty). It's this file https://github.com/paulscottrobson/blit ... pts/cat.py ; if you aren't getting that out of the zip file you have a problem somewhere. You could try cloning the whole github.
Ok, so the secret sauce is the script files (.BAT for the Windowites, .sh for Linuxers like me.)
First, the compile script is run, that compiles the basic program to blitz into a... P-Code thing by tokenising the basic program and sticking it together ('cat' in the programming vernacular.) into a bigger runtime:
# Convert the test.bas source file to a tokenised format
python3 tokenise.py test.bas temp/test.prg
# Concatenate to the compiler
python3 cat.py blitz.prg temp/test.prg temp/compile.prg
Then, for whatever reason, you have to concatenate it some more prior to running the emulator:
python3 cat.py runtime.prg temp/pcode.bin temp/runnable.prg
MOAR CATS! We need MOAR CATS!
I also had to make the .sh scripts executable, but that's just par for the course.
Actually, it works just fine. But the whole thing seems... well, way more complicated than basic.
Learning assembly seems easier.
Oh! Forgot to add: On linux, you need to have Python3 installed, which is easily done through the command line with:
sudo apt install python3
It is like this now, but this is the development version. David suggested I let people see it even though it's not finished (in the sense that most of the X16 commands are still missing, not that these are difficult).
It could be used in several different ways. You could compile source from memory to disk or banked memory, or from disk source or the editor (maybe, would require tokenising) into memory and run it. Or from disk to disk like the original. Or it could be linked into a seperate 6502 emulator and run as a cross development compiler.
The big advantage of it being non-integrated like this, which is very old school, at the moment, is that when bug fixing everything is in memory at a known place, which means I can dump symbol tables, the runtime variables and match them all up without worrying about what is banked where etc.
Honestly, I wasn't really looking to use it, I was wanting to see for myself what difference 'blitzing' a program made. I guess I have that through the gif, but I'd still like to be able to see it with other programs, such as the 'lines' program, or something more elaborate.
