dmsc
commented
4 years ago Hi!
Thank you for developing this great IDE! Your totally modern and alternative approach to BASIC really reinvents the whole idea of high-level programming for 8-bit. It doesn't have so much optimized commands as Turbo BASIC but anyway, the numberless coding for 8-bit is a fantastic improvement. I keep my eye close on this project and would like to express my big respect!
Thanks!
I admit that I have not spent much time improving the Atari IDE, as much of the requests I receive are from people doing development on PC or using other editor, so lets see your suggensitons:
I've tried to make a complete application with it and find several things, which I miss during development.
- Line delete and instant jump to a given line number. I really miss line copy and paste but the first two could be even more helpful because it takes the time to navigate between a far proc and a header section.
Line delete is the standard SHIFT-DELETE key, I could implement SHIFT-INSERT easily, it is the same as CONTROL-A, ENTER, UP.
For go-to-line number, using CONTROL-G seems right?
Copy and paste is difficult, as I don't currently have a buffer to store copied text, only a buffer for current line.
What I could do is a key that remembers a line and then another that inserts a copy of that line in the current position, to do that I could store the memory address of an edited line. CONTROL-M (mark) and CONTROL-C (copy) ?
- A documented memory location which can be tested from the working code to tell whether it's executed under IDE or as a stand-alone program. This could help placing program break conditions in the code without removing it each time before compilation.
That is not as easy as it seems because the program is written without fixed memory locations - at compile time the linker decides where to put each piece of code.
One possibility is using the value returned by "FRE()", as the value should be much lower when your program runs in the IDE. This is simple, but does not work if a user runs your program in a computer with less RAM.
A more complicated option is using the interpreter pointer (this is like the program-counter of the interpreter) and test if it is greater than a give value, then you are under the IDE. The pointer is currently at ZP locations $85 and $86. Problem is, if your program is big, the code could be bigger even outside the IDE.
Currently, in FBI, the IDE uses memory up to about $4140, then there is the program text and after that you have your program code, so you could assume that the code pointer is always > $4150 when run from the IDE.
See this program:
? DPEEK($85)It writes 16752 from the integer IDE, 10474 compiled from the IDE to disk, 8648 compiled with the cross-compiler.
- Bitwise shift commands. This command is native to the processor and could improve execution time of frequently used power of 2 divisions and multiplications use3d in processing of graphics.
I could implement simple shift operators, but I'm not sure about the syntax. Currently the interpreter has two shift tokens, used internally, a simple shift-left by 2 and another shift-left-by 8. The first is used at array access, as the index must be multiplied by 2 to get the memory address, the second is used for SOUND, PMADR, XIO and OPEN.
And there is another question - for right-shifts, ¿do you want arithmetic or logic shift?
I recommend that you create a new enhancement request with only this, so we can discuss the syntax and options.
- LOCATE command or equivalent function. It can be emulated via proc (which I've done along with area fill but it runs too slow.
There is a LOCATE command in the current version! It is used the same as the Atari BASIC one.
- Of course I also miss lot of familiar commands both from standard and Turbo basic and hope that sometimes the most popular of those will be implemented but I understand that it will make the IDE occupy more memory, so I'm not asking to implement everything.
If you have specific requests, please create a separate issue with that, so I can track it.
Some of the graphics commands of TurboBasic XL are not that useful (IMHO), and there are ones like the flood-fill that are really complicated - to be as fast as possible there is a custom fast PLOT routine for each Atari graphics mode, and the code is about 1kB.
And by the way, is there any chance that some time in the future you will implement stack-operated function calls? Currently I've found a way for processing recursive code, using global temporary variables for data interchange between procedures and some array-emulated stack, but it's so complicated and so slow that becomes impractical.
Problem is that the FastBasic stack is really small, so I don't want to add stack operated calls, but you can call procedures recursively (and the cross compiler even optimizes tail-calls to jumps).
Again, it is better to discuss this with specific examples.
Meanwhile, since we are playing by rules of not using line numbers, labels and non-conditional jumps, implementing stack and functions could be super-helpful for keeping the code structured and readable. Sometimes I still miss labels and good old GOTO.
I plan to implement PROCedures with parameters, to simplify code with a lot of procedures, but functions are really difficult because the way the compiler generates code.
When you write an assignment like "A(3) = B + 5" the compiler calculates the address of the expression "A(3)", and stores it in a special register, like "SADDR = ADR(A) + 3 2". Then, the rest of the line calculates the expression "B + 5" and at the end the value is stored to the SADDR location. It is like the code transforms to "SADDR = ADR(A) + 3 2 : DPOKE SADDR, B+5 "
In fact, the code generated for "DPOKE ADR(A) + 3 * 2, B+5" is exactly the same as the code generated for "A(3) = B + 5".
This is simple - as the address to store calculation is separated from the assignment - and also fast, because the store is always to an address in a ZP location, but has a problem. If you could write user-defined functions, any POKE, DPOKE or array store in the function would overwrite the value in SADDR, and make the code invalid.
Note that originally FastBasic used the stack for storing the addresses, but this was a lot slower because the 6502 code was bigger for each POKE and DPOKE.
Thanks.
You are welcome!
rpocc
Thank you for developing this great IDE! Your totally modern and alternative approach to BASIC really reinvents the whole idea of high-level programming for 8-bit. It doesn't have so much optimized commands as Turbo BASIC but anyway, the numberless coding for 8-bit is a fantastic improvement. I keep my eye close on this project and would like to express my big respect!
I've tried to make a complete application with it and find several things, which I miss during development.
And by the way, is there any chance that some time in the future you will implement stack-operated function calls? Currently I've found a way for processing recursive code, using global temporary variables for data interchange between procedures and some array-emulated stack, but it's so complicated and so slow that becomes impractical. Meanwhile, since we are playing by rules of not using line numbers, labels and non-conditional jumps, implementing stack and functions could be super-helpful for keeping the code structured and readable. Sometimes I still miss labels and good old GOTO. Thanks.