Commander X16

+++ EDIT - SEE END


Fab - thanks for all that help.

I now have BASLOAD working on my emulator R44, pretty straight forward!

I have a LOT of label issues - not a surprise. I've taken care of many of them - duplicate label here & there, labels mis-typed etc.

Now all I have left are the more subtle ones.

One downer with BASLOAD from what I can tell here is that the error messages are barely useful - I get a line number but to what it references I'm not sure - It's hit & miss how close/accurate it is referring to the original source code text file.

Given that the source is a bit over 1300 lines this could take a while - a frustrating while at that.

I might even have to resort to coding my own parser just to check the labels!! It might actually be quicker!

Thanks for the update on ASMEDIT - I was thinking of the CODEX app, which looks fab. I'll play with ASMEDIT when I get back home to my hardware.

I'll take a look at that other assembler you referenced that is also in BASIC - always fun to see how other folks do things and learn better ways!

Cheers

Martin

+++ EDIT


OK - there's a bug in version 0.2.4 of BASLOAD - it is clearly missing out great chunks of my original source code yet it is generating references to the missing code and then citing these references to nowhere as an error with my labels.

So, I can't sort out what's a true error with my source code and the BASLOAD code.

It's not missing out code from the end - its a variety of chunks here and there it seems.

Apologies - I forgot 0.2.4 BASLOAD recently was experimenting with an "optimization" to automatically remove REMs. This makes the resulting tokenized product smaller with the idea of giving a bit more "BASIC RAM" for the program to work with.

The BASLOAD github is here, and on the right is a "Release" button. Yes, I've had more luck with the prior 0.2.3 version:
https://github.com/stefan-b-jakobsson/b ... /tag/0.2.3

I believe the REM issue has been fixed (per Discord discussions) but an updated build isn't out yet.

Sorry for the bad initial experience there - BASLOAD is really very nice. The only issue is that eventually a BASIC program may become too large or sophisticated its runtime may conflict with BASLOAD. But the solution there is running two instances of the emulator: one to execute BASLOAD and SAVE the result back as a PRG, and the other "non-BASLOADed" instance to load and run the PRG.




ASMEDIT will also take a little getting used to. F3 to enter the editor once you specify a filename and buffer to work with. Then I think ESC to get back to its command input, and SHIFT+X (not just X) to actually SAVE. I think I had to get that through the manual PDF since the in-program HELP wasn't clear on some of that.

Thanks for that - I went to the previous version 0.2.3 and now the missing code is no longer missing.

What I'm getting though is generated code where the long variable names are unchanged, and this results in syntax errors when I run.

What I also get as BASLOAD is 'compiling' is the same list of line numbers as before, and with the same error -
ERROR IN LINE 505: UNDEFINED OR MISSING LABEL AFTER GOTO OR GOSUB

When I look at line 505 in the generated code I have
505 X=PCODEZCNTR:GOSUB640:X1=7:X2=1:X3=0

And for line 640 I have
640 REM PUSH X INTO STACK

I've checked the above BASLOAD source code, and there are labels there which conform from what I can see to the rules for labels in terms of use and definition. And the code is correct.

I checked the lines for all the listed error messages - all seem OK except for the last 2 - those line numbers don't exist in the source code.

I have to say I'm stumped at the moment!

Cheers

Martin

Martin Schmalenbach wrote: ↑Thu Oct 26, 2023 4:57 am Thanks for that - I went to the previous version 0.2.3 and now the missing code is no longer missing.

What I'm getting though is generated code where the long variable names are unchanged, and this results in syntax errors when I run.

What I also get as BASLOAD is 'compiling' is the same list of line numbers as before, and with the same error -
ERROR IN LINE 505: UNDEFINED OR MISSING LABEL AFTER GOTO OR GOSUB

When I look at line 505 in the generated code I have
505 X=PCODEZCNTR:GOSUB640:X1=7:X2=1:X3=0

And for line 640 I have
640 REM PUSH X INTO STACK

I've checked the above BASLOAD source code, and there are labels there which conform from what I can see to the rules for labels in terms of use and definition. And the code is correct.

I checked the lines for all the listed error messages - all seem OK except for the last 2 - those line numbers don't exist in the source code.

I have to say I'm stumped at the moment!

Cheers

Martin

When I look at line 505 in the generated code I have
505 X=PCODEZCNTR:GOSUB640:X1=7:X2=1:X3=0

You want to be looking at 505 in the source file. BASLOAD Output doesn't make that quite clear.

My text editor is Kate, it does line counting. If your editor doesn't just have to cursor down and count manually.

(Most likely a typo in a lable name. Something like GOTO LABLE1 when you really want GOTO LABEL1. )

Brilliant!

Thanks ahenry3068 - that seems to be the solution - and it's mistyped labels just as you said!!!

Cheers

Martin

HOORAY!!!


I get BASLOAD to 'compile' without any reported errors - thanks to aHenry and Voidstar for their help getting me to this point.

Just one small problem...

None of the long variable names have been converted in to a 1 or 2 character variable name as I expected, which means the generated code from BASLOAD is runnable but utterly useless.

Did I misread the instructions for BASLOAD, and it only accepts long label names, and not long variable names?

The short answer is - YES!!!

I read what I wanted to see... I spent a lot of time changing the variable names in to something more readable...

BUGGER!!!

OK - I want variable names that are truly meaningful. This maybe some way off for Stefan, if he's able to do it at all without a full rewrite. Totally understand.

So I'm going to write a short/quick(?!) preprocessor that will generate a new text file of the source code, with all variable names replaced with a meaningless 2 character variable name. I'll do the same for labels so that the labels follow a simple "LBL00000:" format. For now I'll write it in PureBasic to run quickly on my MacBook until Blitz on the X16 can handle file operations and then I'll bring it over to the X16 to run natively there. While I'm doing this I think I might at some point throw in a few simple constructs for my own edification - IF-THEN-ELSE, REPEAT-UNTIL, WHILE-DO, etc to speed up my development cycle with the Pascal compiler and my assembler.

Martin Schmalenbach wrote: ↑Thu Oct 26, 2023 5:59 am Brilliant!

Thanks ahenry3068 - that seems to be the solution - and it's mistyped labels just as you said!!!

Cheers

Martin

I just recently did this transfer with my HANGMAN program. I had about 1/2 dozen errors like that to clean up after I finished the conversion. Just curious.. Did you start the CONVERSION with REMLINE as I had suggested. ? I used QB64 to compile the REMLINES.BAS source. I bet PureBasic could handle it too, maybe.

Martin Schmalenbach wrote: ↑Thu Oct 26, 2023 6:17 am HOORAY!!!


I get BASLOAD to 'compile' without any reported errors - thanks to aHenry and Voidstar for their help getting me to this point.

Just one small problem...

None of the long variable names have been converted in to a 1 or 2 character variable name as I expected, which means the generated code from BASLOAD is runnable but utterly useless.

Did I misread the instructions for BASLOAD, and it only accepts long label names, and not long variable names?

The short answer is - YES!!!

I read what I wanted to see... I spent a lot of time changing the variable names in to something more readable...

BUGGER!!!

OK - I want variable names that are truly meaningful. This maybe some way off for Stefan, if he's able to do it at all without a full rewrite. Totally understand.

So I'm going to write a short/quick(?!) preprocessor that will generate a new text file of the source code, with all variable names replaced with a meaningless 2 character variable name. I'll do the same for labels so that the labels follow a simple "LBL00000:" format. For now I'll write it in PureBasic to run quickly on my MacBook until Blitz on the X16 can handle file operations and then I'll bring it over to the X16 to run natively there. While I'm doing this I think I might at some point throw in a few simple constructs for my own edification - IF-THEN-ELSE, REPEAT-UNTIL, WHILE-DO, etc to speed up my development cycle with the Pascal compiler and my assembler.

I use descriptive variable names in my Longer basic programs. CBM allows them it just ignores them. I do a lot of using my text editors search function to make sure I haven't tromped on another 2 letter name . Two characters with both Alpha & Numeric characters available gives you more room than you think for variable names.

Fantastic to hear the progress!

Correct, BASLOAD won't do long variable names. Stefan has been working on handling that, on and off for a few weeks. But he also helps with SMC and core system features (like gamepad, PS/2 keyboard interfacing) and those get a bit higher priority. That's all mostly stable, but for instance an unexpected gamepad issue propped up again just this past week.

This "long variable" handling sounds "easy" from something like a Python script, but he has to manage this on-system in 6502 assembly. So it becomes a bit of a database problem, and he has to be careful about the memory usage. This is partially why the LABELS he chose to limit them to 12 characters (and whatever number he picked, we'll always wish we had "just a few more characters longer!" haha).

Labels were "easy" since there are only a few use cases: GOTO GOSUB RESTORE. But variables are used all over the place. It's very admirable he's even trying to tackle this - but I think will be very worthwhile since it makes a very new kind of experience on using these systems (one that I wish we had in the 80s!!). To me, it has "made BASIC fun again."


I see the p-code parser example the article is actually in Pascal itself. It has line numbers, except they are just file index numbers. So that may take some doing to adapt into BASIC, as a way to "emulate" the resulting compiled Pascal p-code - we could skip that (I mean a BASIC version of that), if your off-system version is suitable enough for testing (and for on-system focus on the p-code to 6502 conversions).


Oh, before I forget: the X16 "natively" doesn't have { } braces, the typical comment symbols in Pascal. The work around is we can use CTRL+O to enter "ISO mode" which offers the more standard ASCII symbol set. (I actually don't know how to exit ISO mode, except for a system reset). But the system starts in a PETSCII mode, in tribute to the Commodore heritage. And PETSCII doesn't have underscore - instead I think it is '`' which in PETSCII maps to a left pointing arrow. Again using ISO mode resolves this (or at least masks it).


To me, the "dream" is any high level language supported on system that:

- can define multi-line functions with arguments, like check_engine(a, 7)
- supports some form of record data structure
- can handle "large" allocations (beyond the ~32K that BASIC offers)
- function recursion isn't too critical to me, though most high-levels will support that
- pointers to types

It's a lot of small steps first. But ultimately, another (long term) goal is:

- not just that data declarations >32K, but the code-portion can also be >32K. (i.e. the logic/size of the program results in >>32K of processing code, or even 64K. That'll get tricky: data declarations will have to get assigned a bank, with some "master table" keeping track of what those bank assignments are, and supporting generated code to automatically switch to those banks when the corresponding data is being accessed, etc. (one entire bank could be dedicated to that table, maybe). The same will apply to individual functions (and its corresponding code- which we won't know apriori {we can approximate the size need from the p-code sequence}; but that code could get assigned to banks too -- but since we don't know which arguments will get passed and which banks those arguments will get pulled from; so then it's extra smarts to probe for those needs, switch bank, copy what we need to a temporary space- go back to our runtime bank, etc). It's all do-able, but challenging to orchestrate and test.

Not even cc65 (I think) has tackled the above. the cx16.cfg has some bank assignments, but the linker itself doesn't have smarts to handle a "variable to bank" kind of association (at least as far as I know). So doing a malloc in cc65 with much more than about 20K (depending on your code size) doesn't work. But this is all "for later" details - just something to keep in mind down the road. For now, parsing "any Pascal" would be very neat to see (for the other benefits of long variable names and actual properly defined functions and record data structures).