Really a nice job done Csaba Fekete. Like the "new language". But there is one point I dislike. The names FUN ENDFUN should be FUNC ENDFUNC (as it was in the COMAL-80 language).
It's pretty cool. A nice feature would be if it allowed inline assembly code for when you need super optimized code or if you're doing something naughty. Also integration in some kind of IDE like Eclipse or VS would be useful.
Hey Robin, I hope you will talk one day about Kick C implementation for c64 and "c64 debugger". I recently watched in action on polish retro channel and it looked really interesting and fast.
Great video! My only feedback is that I view a lot of content on my phone or on my TV, so standard sized text from a PC desktop is really difficult to read due to its small size. I don’t know if anyone else has the same view, but I would say increasing text size (in your editor and when looking at web sites) to 150% would be perfect.
6:31 For the purposes of storing data in memory -- it doesn't matter if it is signed or unsigned, it all requires the same number of bytes. The only time it matters (and only to the programmer) is when doing arithmetic with them. (signed) -1 - -1 = -1 + 1 = 0xFFFF + 0x0001 = 0x10000 ; 0x0000 with a carry of 1 (unsigned) 65535 + 1 = 0xFFFF + 0x0001 = 0x10000 ; 0x0000 with a carry of 1 The **ALU does not care** about the value being signed or unsigned as both results are the same (0 with a carry of 1). So the only thing that matters ( **to the programmer** ) is whether to use or ignore the generated carry, under or overflow, etc.
At first glance XCBASIC looks less like a BASIC and more like a macro assembler with the low-level assembly instructions removed and a small library added. The main thing that makes it more than higher-level assembler is it does have lexically scoped procedures and proc-local variables with support for recursion. Notably the stack is only 256 bytes, just like BASIC, so I'm curious how it handles lots of local vars, tail calls, etc. That's not a criticism of XCBASIC! It's what I often think I want in a language for a micro. I wonder if XCBASIC programmers would have any use for inline assembly, which seems feasible as long as it respects the memory layout. I'd be curious what everyone thinks are the defining qualities of the "BASIC" family of languages and how XCBASIC compares.
I don't think it's only a set of macros with library. You wouldn't be able to parse and evaluate complex expressions with a set of macros., e.g. PRINT x + 45 * PEEK(n + 3) / (6 - a*b). If you only had a set of macros, you'd have to write all your operations in some kind of reverse polish notation like in FORTH. XC=BASIC allows almost the same syntax as CBM BASIC (there are limitations of course!). As for the stack size: 256 bytes are surprisingly good (call stack, expressions, etc), but you can run into problems with recursions and very complex expressions. BASIC is a family of languages that are easy to learn, without really knowing what's going on under the hood. This is especially true for CBM BASIC. Just think of the only numeric type, the floating point (well, effectively the only type). Beginners don't even know what a FP is and yet they can write pretty nice programs. This is not true for XC=BASIC. It requires you to understand the basics of computing but your reward is the much-much higher execution speed.
@@CsabaFekete1 I appreciate the reply. I didn't mean "macro assembler" literally, but rather I was gesturing towards the gradation of high level languages. I look at XC BASIC source and I can easily imagine the compiled assembly behind it-which is an advantage for a low level compiled language! I'm not convinced that the sole key feature of the BASIC family is being easy to learn. That's how it's advertised, surely ("Beginners All-purpose etc."). But nearly every language in the family trades away some usability for an ability to be entered and interpreted directly on a micro. Low memory line editors, two letter variable names, a lack of labels, etc. seem just as definitional to BASIC as its approachable high level-ness. Contrast with Lua, which is generally considered to be approachable for beginners, but ends up being too large to run on a micro, let alone edited and interpreted. Surely XC BASIC uses "BASIC" in the name to refer to its accessibility (which is entirely fine, not criticizing). I'm suggesting that the contours of the language are meaningfully different from the BASIC family.
It would be interesting to see the assembly it's creating and how it handles the stack. Stack manipulation and even a lot of JSR RTS can be very cycle consuming that can hamper compiled languages for 6502.
1:39 They mention a bunch of features that Commodore BASIC doesn't have. Will the compiler accept any Commodore-BASIC program? 3:30 Nope. 3:55 "goto loop" - seems odd that it doesn't have a 'while' loop. 4:00 I don't see how you can have both long variable names and optional spaces without creating an ambiguous syntax or severe restrictions on variable names. You're invariably going to use the simpler keywords in variable names: go to fn if on or and def dim end get not run sin exp cos rem. 4:18 According to the dictionary, the correct pronunciations are "tild-ah" or "tild-ee". 7:24 There should be nearly 100 bytes of zero page available, since most of BASIC isn't needed. 9:01 Where's the NOT operator? How are booleans handled, as 0 and 1? 19:02 It seems like running the emulator at 10% makes the frame rate only 10% as well. 21:14 This language is a bit C-like without having any compatibility with anything. Why not write a C compiler instead?
For you last question: some people just prefer BASIC I guess? shrug? It's also much easier to write a BASIC compiler than it is to write a C compiler, especially if you're aiming for a feature-complete C compiler. And if you're instead wondering whether a modern C compiler for the C64 exists, the answer is yes (cc65, which also includes a good assembler, so I'd suggest it for that alone anyway)
@@andlabs: In the case of insisting on BASIC, it makes the most sense to make the compiler accept Commodore BASIC programs, since there's a large base of such programs that could benefit greatly from being compiled, whereas with an ad-hoc dialect of BASIC, the only existing code base is the examples on the website.
I wonder if the author was inspired by "batari Basic" which is a somewhat similar (but even more stripped down) BASIC-inspired compiler targeting the Atari 2600. I'm kind of fond of these strange dialects of BASIC, going back to the first ones I remember: AMOS and Blitz BASIC on the Amiga.
It's funny how there's these words I never use in conversation so nobody has ever corrected me on "tilde" before. It's neat that I get a choice to use "dee" or "duh" as the second syllable. Maybe I'll use both! "til-dee-duh" has a nice ring to it.
Are the section titles that pop up under the video and as you scan the timeline a new UA-cam feature or just something most people don't take the time to put in? This video is the first time I've ever noticed it
I've been putting a timestamped index in my video descriptions for at least a year, but just recently UA-cam has started parsing that out and putting it into the timeline. Pretty cool feature!
I've been seeing it show up in the last week or so. And it even seems to be propagating backwards to older videos........but not all of them at least not yet.
Unfortately almost, but not quite, what I was looking for in a modern BASIC for retrocomputing. And none of the others were quite right either. Turbo Rascal Syntax Error was almost there too, but still not right. So I will have to implement my own.
Normally when calling something recursively will want to harvest a function result - seems kind of odd that only procedures (which return no value) support recursion.
I see it doesn't have any built in graphics or sound routines, but I imagine that's because those would be found in some external library that would linked early in the program.
No, the graphics and sound commands are supposed to go into separate extensions in order to keep the runtime library small. Although only the SPRITE extension is completed at the moment :-(
@@JustWasted3HoursHere I'm not sure, I think they're the same :-) I guess I use the word extension because it is the old school BASIC-ish way for something that adds a set of commands to the language, right?
@@CsabaFekete1 In a compiled language it works out the same because when you "include" the library at the beginning of your code any functions, etc in that library become the same as new commands. I seem to remember back in the good old days, though, that there were individual commands that could be added to CBM BASIC that didn't need to be included in any sort of program (although they did have to be loaded before you could use them. They would insert themselves into the kernal so that they would be recognized as new commands). This is what I would call an extension, but the difference is very subtle.
Actually, there's no real context-sensitivity to AND and OR in Commodore BASIC. They're always bitwise, which is why you have to be careful . . . `NOT 1` is a nonzero and therefore true value. It's just that the relational operators return -1 for true so that bitwise operators applied to them yield the correct result.
Commands available seem a bit Spartan, in some ways more restricting and less powerful than even the regular Commodore Basic 2.0. Any more ambitions project, either an app, a game or a demo, would have to relay heavily on machine code subroutines. And if you can write efficient assembly language subroutines, why even bother with this cross-compiler, why not just skip the middleman and write everything in assembly. UNLESS I am missing something important and there are additional libraries that can be added if needed. If so, is there a linker tool for this?
Would you believe if I said to you that SPARTAN was the code name of this project in the early beginning? :-D You can write pretty fast games in XC=BASIC without a single line of embedded assembly (even scrolling games to some extent), but it's true that for being able to this, you need to understand the machine very well. Some folks find it useless while some use it for writing their next game. I can understand both.
@@CsabaFekete1 That's interesting, I would really like to see some examples of software written in XC=BASIC, preferably with the source code. Please, leave a link if you have any handy.
@@NemanjaVuj Here are some examples: xc-basic.net/doku.php?id=game_gallery "Flying Saucers" is the most advanced out of these, although it's not yet completed. It features scrolling background, sprites, sound effects and joystick control.
As for the linker: no, that thing doesn't work like in C. Source files can not be compiled separately. There is an INCLUDE directive which barely injects one source into another and this is how separate source files are combined. There is also INCBIN that injects binary data in the program.
I wish they'd drop the "you can omit spaces" thing, just so you can have more freedom with the identifiers. I mean, havingtoreadcodelikethis is painful, isn't it? And once it's converted to machine language the identifiers are dropped anyway.
The author of XC=BASIC here. Thanks a lot for making this video! And thanks for interpreting the otherwise awful documentation perfectly :-)
Nice work on it, and I didn't find the docs too bad :)
Really a nice job done Csaba Fekete. Like the "new language". But there is one point I dislike. The names FUN ENDFUN should be FUNC ENDFUNC (as it was in the COMAL-80 language).
@@aso4200 well I didn't know Comal but thanks!
@@aso4200 Yeah I'd day it should be FUNC -- not because of COMAL, but because it matches the naming convention of PROC.
Shorten, shorten, shorten.
XC=Basic has really evolved by leaps and bounds in 2024. TRSE is also worth looking at.
This is great. Thanks for sharing!
It's pretty cool. A nice feature would be if it allowed inline assembly code for when you need super optimized code or if you're doing something naughty. Also integration in some kind of IDE like Eclipse or VS would be useful.
Inline assembly is supported. Code highlighting for Textadept is available.
Wow, looks interesting, I think I'm gonna try to write a small game with this language. Thanks for the video, Robin.
Hey Robin, I hope you will talk one day about Kick C implementation for c64 and "c64 debugger". I recently watched in action on polish retro channel and it looked really interesting and fast.
Great video! My only feedback is that I view a lot of content on my phone or on my TV, so standard sized text from a PC desktop is really difficult to read due to its small size.
I don’t know if anyone else has the same view, but I would say increasing text size (in your editor and when looking at web sites) to 150% would be perfect.
Alas, by popular demand, the internet becomes less friendly to luxurious desktop monitors year by year.
I'll take 27" over 7" any day.
6:31 For the purposes of storing data in memory -- it doesn't matter if it is signed or unsigned, it all requires the same number of bytes.
The only time it matters (and only to the programmer) is when doing arithmetic with them.
(signed) -1 - -1 = -1 + 1 = 0xFFFF + 0x0001 = 0x10000 ; 0x0000 with a carry of 1
(unsigned) 65535 + 1 = 0xFFFF + 0x0001 = 0x10000 ; 0x0000 with a carry of 1
The **ALU does not care** about the value being signed or unsigned as both results are the same (0 with a carry of 1).
So the only thing that matters ( **to the programmer** ) is whether to use or ignore the generated carry, under or overflow, etc.
At first glance XCBASIC looks less like a BASIC and more like a macro assembler with the low-level assembly instructions removed and a small library added. The main thing that makes it more than higher-level assembler is it does have lexically scoped procedures and proc-local variables with support for recursion. Notably the stack is only 256 bytes, just like BASIC, so I'm curious how it handles lots of local vars, tail calls, etc.
That's not a criticism of XCBASIC! It's what I often think I want in a language for a micro. I wonder if XCBASIC programmers would have any use for inline assembly, which seems feasible as long as it respects the memory layout.
I'd be curious what everyone thinks are the defining qualities of the "BASIC" family of languages and how XCBASIC compares.
I don't think it's only a set of macros with library. You wouldn't be able to parse and evaluate complex expressions with a set of macros., e.g. PRINT x + 45 * PEEK(n + 3) / (6 - a*b). If you only had a set of macros, you'd have to write all your operations in some kind of reverse polish notation like in FORTH. XC=BASIC allows almost the same syntax as CBM BASIC (there are limitations of course!). As for the stack size: 256 bytes are surprisingly good (call stack, expressions, etc), but you can run into problems with recursions and very complex expressions.
BASIC is a family of languages that are easy to learn, without really knowing what's going on under the hood. This is especially true for CBM BASIC. Just think of the only numeric type, the floating point (well, effectively the only type). Beginners don't even know what a FP is and yet they can write pretty nice programs. This is not true for XC=BASIC. It requires you to understand the basics of computing but your reward is the much-much higher execution speed.
@@CsabaFekete1 I appreciate the reply. I didn't mean "macro assembler" literally, but rather I was gesturing towards the gradation of high level languages. I look at XC BASIC source and I can easily imagine the compiled assembly behind it-which is an advantage for a low level compiled language!
I'm not convinced that the sole key feature of the BASIC family is being easy to learn. That's how it's advertised, surely ("Beginners All-purpose etc."). But nearly every language in the family trades away some usability for an ability to be entered and interpreted directly on a micro. Low memory line editors, two letter variable names, a lack of labels, etc. seem just as definitional to BASIC as its approachable high level-ness. Contrast with Lua, which is generally considered to be approachable for beginners, but ends up being too large to run on a micro, let alone edited and interpreted.
Surely XC BASIC uses "BASIC" in the name to refer to its accessibility (which is entirely fine, not criticizing). I'm suggesting that the contours of the language are meaningfully different from the BASIC family.
It would be interesting to see the assembly it's creating and how it handles the stack. Stack manipulation and even a lot of JSR RTS can be very cycle consuming that can hamper compiled languages for 6502.
I hadn’t heard of this one, thanks for covering it. I bet it wouldn’t be a stretch to get this working on other commodore machines like the vic.
New target platforms such as VIC-20, C16 and Plus/4 will be supported in the next version!
1:39 They mention a bunch of features that Commodore BASIC doesn't have. Will the compiler accept any Commodore-BASIC program? 3:30 Nope.
3:55 "goto loop" - seems odd that it doesn't have a 'while' loop.
4:00 I don't see how you can have both long variable names and optional spaces without creating an ambiguous syntax or severe restrictions on variable names. You're invariably going to use the simpler keywords in variable names: go to fn if on or and def dim end get not run sin exp cos rem.
4:18 According to the dictionary, the correct pronunciations are "tild-ah" or "tild-ee".
7:24 There should be nearly 100 bytes of zero page available, since most of BASIC isn't needed.
9:01 Where's the NOT operator? How are booleans handled, as 0 and 1?
19:02 It seems like running the emulator at 10% makes the frame rate only 10% as well.
21:14 This language is a bit C-like without having any compatibility with anything. Why not write a C compiler instead?
For you last question: some people just prefer BASIC I guess? shrug? It's also much easier to write a BASIC compiler than it is to write a C compiler, especially if you're aiming for a feature-complete C compiler. And if you're instead wondering whether a modern C compiler for the C64 exists, the answer is yes (cc65, which also includes a good assembler, so I'd suggest it for that alone anyway)
@@andlabs: In the case of insisting on BASIC, it makes the most sense to make the compiler accept Commodore BASIC programs, since there's a large base of such programs that could benefit greatly from being compiled, whereas with an ad-hoc dialect of BASIC, the only existing code base is the examples on the website.
@@csbruce Ah yes; good point that i somehow didn't connect when you also made it in the OP
I wonder if the author was inspired by "batari Basic" which is a somewhat similar (but even more stripped down) BASIC-inspired compiler targeting the Atari 2600. I'm kind of fond of these strange dialects of BASIC, going back to the first ones I remember: AMOS and Blitz BASIC on the Amiga.
It's funny how there's these words I never use in conversation so nobody has ever corrected me on "tilde" before. It's neat that I get a choice to use "dee" or "duh" as the second syllable. Maybe I'll use both! "til-dee-duh" has a nice ring to it.
Are the section titles that pop up under the video and as you scan the timeline a new UA-cam feature or just something most people don't take the time to put in? This video is the first time I've ever noticed it
I've been putting a timestamped index in my video descriptions for at least a year, but just recently UA-cam has started parsing that out and putting it into the timeline. Pretty cool feature!
@@8-bitshowandtell247 - Ah that's great, thanks for the info
I've been seeing it show up in the last week or so. And it even seems to be propagating backwards to older videos........but not all of them at least not yet.
Nice review.
Reminds me of the French Silk Assembler/Compiler for the (16K+) Expanded Vic20 though FS was more direct with CBM BASIC than this is.
Unfortately almost, but not quite, what I was looking for in a modern BASIC for retrocomputing. And none of the others were quite right either. Turbo Rascal Syntax Error was almost there too, but still not right. So I will have to implement my own.
Normally when calling something recursively will want to harvest a function result - seems kind of odd that only procedures (which return no value) support recursion.
What's this song at the start? Would like to see you try TRSE's support for int-driven .SID songs
sounds a bit 28 days later.....
I see it doesn't have any built in graphics or sound routines, but I imagine that's because those would be found in some external library that would linked early in the program.
No, the graphics and sound commands are supposed to go into separate extensions in order to keep the runtime library small. Although only the SPRITE extension is completed at the moment :-(
@@CsabaFekete1 Cool. How does an extension differ from an imported library?
@@JustWasted3HoursHere I'm not sure, I think they're the same :-) I guess I use the word extension because it is the old school BASIC-ish way for something that adds a set of commands to the language, right?
@@CsabaFekete1 In a compiled language it works out the same because when you "include" the library at the beginning of your code any functions, etc in that library become the same as new commands. I seem to remember back in the good old days, though, that there were individual commands that could be added to CBM BASIC that didn't need to be included in any sort of program (although they did have to be loaded before you could use them. They would insert themselves into the kernal so that they would be recognized as new commands). This is what I would call an extension, but the difference is very subtle.
@@JustWasted3HoursHere You're absolutely right and I'll consider calling them "libraries" when the docs are rewritten for the upcoming version 3.
Looks very interesting project. Shame there are no graphic commands or extensions yet. Great work though.
Actually, there's no real context-sensitivity to AND and OR in Commodore BASIC. They're always bitwise, which is why you have to be careful . . . `NOT 1` is a nonzero and therefore true value. It's just that the relational operators return -1 for true so that bitwise operators applied to them yield the correct result.
Need to do an update, V3 is out and changes the syntax to more BASIC style.
Commands available seem a bit Spartan, in some ways more restricting and less powerful than even the regular Commodore Basic 2.0. Any more ambitions project, either an app, a game or a demo, would have to relay heavily on machine code subroutines. And if you can write efficient assembly language subroutines, why even bother with this cross-compiler, why not just skip the middleman and write everything in assembly. UNLESS I am missing something important and there are additional libraries that can be added if needed. If so, is there a linker tool for this?
Would you believe if I said to you that SPARTAN was the code name of this project in the early beginning? :-D You can write pretty fast games in XC=BASIC without a single line of embedded assembly (even scrolling games to some extent), but it's true that for being able to this, you need to understand the machine very well. Some folks find it useless while some use it for writing their next game. I can understand both.
@@CsabaFekete1 That's interesting, I would really like to see some examples of software written in XC=BASIC, preferably with the source code. Please, leave a link if you have any handy.
@@CsabaFekete1 Oh, you're the author of the XC, I saw that now in the comment bellow. Congrats on good work.
@@NemanjaVuj Here are some examples: xc-basic.net/doku.php?id=game_gallery
"Flying Saucers" is the most advanced out of these, although it's not yet completed. It features scrolling background, sprites, sound effects and joystick control.
As for the linker: no, that thing doesn't work like in C. Source files can not be compiled separately. There is an INCLUDE directive which barely injects one source into another and this is how separate source files are combined. There is also INCBIN that injects binary data in the program.
I LOVE C64 👍🥂🎩
I wish they'd drop the "you can omit spaces" thing, just so you can have more freedom with the identifiers.
I mean, havingtoreadcodelikethis is painful, isn't it? And once it's converted to machine language the identifiers are dropped anyway.
I'd love to see something like this for the NES
Hi.
I have only just read this, and cannot respond fully now. The short answer is NO.
Kind Regards.
Looks great, but seems to lack a packaged, ready-to-go finished product binary that just.... works. Bummer.
16.5 bits? More like 16.58495 bits! amiright? HEYOOOO. right?! sorry.
Or am I off by one?
I get log2(65536+32768) = 16.58496250072116. There are 65536 values from 0 to 65535 and 32768 values from -1 to -32768.
@@csbruce I couldn't decide if it should have been that or 65535+32768 . And then lost interest in thinking about it too hard :D
It looks a lot like microsoft visual basic.
Basic? No thanks, I definitely prefer C. Btw, show us the generated assembly code to evaluate the compiler optimizations.
Lots of us prefer C. But why the fuck did you click on this? Just to whine about the content? GTFO.