Closed neilsf closed 2 years ago
Most features are obviously for C64 only (for ex. no sprites on VIC-20).
Love the INTERRUPT's! I believe we can make some type of timer with it.
I would like to see some type of pre-processer for #defines, #if, #else, #endif and a way to tell what machine I am running on. So.....
print "C64 - we can use sprites"
print "no sprites"
pragma so we can #include files only once.
Not sure what you mean. Can you pls explain?
FreeBasic has #pragma But what I am looking for and maybe you have a way to do this already...
You can also do it with #define, #ifdef, #ifndef also.
Do I have you confused yet? ;)
How FreeBasic does it: #include [once] "file"
I see. INCLUDE in XC=BASIC is already a preprocessor directive. The difference is that it doesn't use the # prefix. It can be improved to have the ONCE option.
How about CHAIN so that compiled programs can call other compiled programs?
How about CHAIN so that compiled programs can call other compiled programs?
Can you pls explain a use case?
A huge game. This idea was inspired by EPYX Winter and Summer games.
OK, lets design a game called Space Explore.
1st PRG is the startup screen, high score screen and game main menu.
2nd PRG is the ship maintenance screen where you outfit you ship, buy and sell parts. Upgrades.
3td PRG is the Bar. You have a drink and buy / sell things to fund you space ship
4th PRG is the flying screen, fly another planet and attack / get attacked by other ships
So 4 PRG's, each one of these PRG has a whole 64k of RAM instead of trying to shove it all into one PRG. I see huge games! ;) You can use UDT's and save/load to disk to pass vars.
A huge game. This idea was inspired by EPYX Winter and Summer games. OK, lets design a game called Space Explore. 1st PRG is the startup screen, high score screen and game main menu. 2nd PRG is the ship maintenance screen where you outfit you ship, buy and sell parts. Upgrades. 3td PRG is the Bar. You have a drink and buy / sell things to fund you space ship 4th PRG is the flying screen, fly another planet and attack / get attacked by other ships
So 4 PRG's, each one of these PRG has a whole 64k of RAM instead of trying to shove it all into one PRG. I see huge games! ;) You can use UDT's and save/load to disk to pass vars.
LOAD and GOSUB can do that...
Main program:
LOAD "firstprg", 8, @here : GOSUB here
LOAD "secondprg", 8, @here : GOSUB here
END
ORIGIN $0900
here:
Of course you need to compile firstprg and secondprg to exclude the BASIC stub and start at a fixed address ($0900).
This "windows" system in AMOS (Amiga) would be handy to have on C64 (for pure text or a text-graphics combination): https://www.ultimateamiga.co.uk/HostedProjects/AMOSFactory/AMOSProManual/5/564.html BASIC 7.0 for Commodore 128 featured a similar (albeit less sofisticated) command: https://www.commodore.ca/manuals/128_system_guide/sect-05.htm#5.7.1 QBASIC had VIEW (for graphics) https://www.qbasic.net/en/reference/qb11/Statement/VIEW.htm VIEW PRINT (for text) https://www.qbasic.net/en/reference/qb11/Statement/VIEW-PRINT.htm
Also, is there a way to erase/free memory from address to address?
Hi @Diduz
This "windows" system in AMOS (Amiga) would be handy to have on C64
That's something I believe the Amiga supports by hardware (via Blitter).
BASIC 7.0 for Commodore 128 featured a similar (albeit less sofisticated) command: https://www.commodore.ca/manuals/128_system_guide/sect-05.htm#5.7.1
It's a feature of the C128 KERNAL that the C64 doesn't have. XC=BASIC uses KERNAL for screen I/O.
QBASIC had VIEW (for graphics) https://www.qbasic.net/en/reference/qb11/Statement/VIEW.htm
I'm not sure what this one exactly does. I tried the example in QB64 on Linux and got this:
Also, is there a way to erase/free memory from address to address?
If you mean filling a memory range with a value, there's MEMSET for that.
BASIC 7.0 for Commodore 128 featured a similar (albeit less sofisticated) command: https://www.commodore.ca/manuals/128_system_guide/sect-05.htm#5.7.1
It's a feature of the C128 KERNAL that the C64 doesn't have. XC=BASIC uses KERNAL for screen I/O.
Yeah, I've discovered C16/Plus 4 had it too, but their BASIC 3.5 lacked the "WINDOW" command to easily activate that (you had to press some keys to trigger the feature). Too bad for C64, but I think I read some sort of C64 code somewhere that could at least "protect" some lines on the screen from scrolling. Not exactly a "window", alas. And I guess that would be Assembly territory I'm not familiar with. :-P
QBASIC had VIEW (for graphics) https://www.qbasic.net/en/reference/qb11/Statement/VIEW.htm
I'm not sure what this one exactly does. I tried the example in QB64 on Linux and got this:
I don't know about VIEW (the graphic version of that command), but VIEW PRINT is a pretty easy way to create different text windows. Some time ago I gave it a try through Freebasic (I compiled the code in legacy qbasic mode though).
Also, is there a way to erase/free memory from address to address?
If you mean filling a memory range with a value, there's MEMSET for that.
So a MEMSET with a 255 / FF value would "erase"/"clean" that byte? (Newbie here, sorry for some stupid questions :-D ).
I think I read some sort of C64 code somewhere that could at least "protect" some lines on the screen from scrolling.
I wonder how that thing worked. Maybe a customized KERNAL in RAM?
So a MEMSET with a 255 / FF value would "erase"/"clean" that byte?
What do you mean by erasing? You can set a byte any value between 0 and 255. What is considered to be "erased" is only a choice of your application.
The FRE statement to tell how much memory we have left. It would be nice to tell what methods of programming madness consume less memory. https://www.c64-wiki.com/wiki/FRE
The FRE statement to tell how much memory we have left. It would be nice to tell what methods of programming madness consume less memory. https://www.c64-wiki.com/wiki/FRE
It only makes sense in an environment that dynamically allocates memory (eg. CBM BASIC). In XC=BASIC, the compiler should display the memory information after compilation. It was working in V2 but somehow I missed to implement it in V3. Will do.
Multi vars dim'd on 1 line. DIM a,b,c AS BYTE
And assigning value on the same line DIM a AS BYTE = 10 instead of DIM a AS BYTE : a = 10
Bitwise operators e.g. "&", "|", "^" and "~" evaluated in higher precedence level (i.e. before comparison operators). No need for parenthesis in
IF a & 1 = 0 AND b & 1 = 0 THEN
vs
IF (a AND 1) = 0 AND (b AND 1) = 0 THEN
Arrays inside user defined types e.g.
TYPE MyType
arr(10) AS INT
END TYPE
CONSTs values and expression evaluated in DATA AS XXX statements e.g.
CONST AXIS_SPD = 5
CONST DIAG_SPD = 8
X_Movement:
DATA AS INT AXIS_SPD, DIAG_SPD, 0, -DIAG_SPF, -AXIS_SPD, -DIAG_SPD, 0, DIAG_SPD
Bitwise operators e.g. "&", "|", "^" and "~" evaluated in higher precedence level (i.e. before comparison operators).
@orlof what BASIC supports this? It seems a little strange for me..
Btw, (a AND 1) = 0 AND (b AND 1) = 0
can be simplified as (a OR b AND 1) = 0
.
@neilsf I don't know any 😞 ...but I don't know any other BASIC that supports embedded assembler either 😉 But seriously, it is just my thinking that bitwise and logical operators should have different precedences - I understand if you like the BASIC tradition more 👍
I don't know any other BASIC that supports embedded assembler either wink
Freebasic also has ASM ... END ASM blocks.
bitwise and logical operators should have different precedences
Yes, in other languages, such as C, bitwise operators are distinct from logical operators (e. g. &
and &&
), bitwise operators having higher precedence. But BASIC is different.
Not sure if this can be put into 3.0, so maybe 3.1 but an equivalent of the TI/TI$ variables in BASIC would be nice. I tried to be sneaky and map a variable to the TI memory location but it didn't work because I think it's mapped backwards in memory.
@Thraka there you go: https://xc-basic.net/doku.php?id=v3:ti
Have these predefined. CONST TRUE = 255 CONST FALSE = 0 I add them to everyone of my Included files.
I add them to everyone of my Included files.
Don't do that. Add SHARED CONST TRUE = 255
once and it will be visible everywhere.
Add an under score _ to split lines
Add an under score _ to split lines
Sadly, that would cause grammar ambiguities because _
is a valid identifier in XC=BASIC. I suggest resurrecting the tilde ~
char from XCB2.
Add an under score _ to split lines
Sadly, that would cause grammar ambiguities because
_
is a valid identifier in XC=BASIC. I suggest resurrecting the tilde~
char from XCB2.
I could do a '~' just fine. ;) Lets resurrect it.
I'd love to see an improved visual representation of binary variables
In the ACME assembler code (I know, not BASIC..), "." and "#" can be used instead of "0" and "1" in a binary formatted value. So, these values would be equivalent:
%00011000
%000##000
%...11...
%...##...
In my opinion that can be super useful to make reading bitmasks a bit easier on the eye
How about fusing MEMSHIFT and MEMCPY? Having one work upwards and another downwards saves one comparison in assembler, but in many cases that comparison is then done in Basic and there is no speed benefit. It also causes occasional bugs and I often need to verify which is which from the docs. To maintain backwards compatibility they could both work exactly the same - both directions.
A function that reads a character from coordinates - similar (but "opposite") to CHARAT
ELSEIF expr THEN
branches
Closing this as v3.1 is past feature freeze. Thanks for your suggestions, those that didn't make it to the next release will be considered in a later one.
Is there a list of what will be 3.1?
@Thraka The bulk of what has been added is written in this file. I also look at this page in the wiki documentation to keep updated with the latest additions. In the keyword and function reference of the documentation, all the new features are tagged with "v3.1" :)
I haven't updated the README file in a while, but I will do that before the final release. The docs pretty much cover all the new features and changes.
This is the list of planned features for version 3.1. Please add your thoughts and wishes.
Sprites
(Highly inspired by Hesware's Graphics BASIC)
Joystick
Interrupts
Sound
(Highly inspired by Hesware's Graphics BASIC)