Faicuai Posted September 17, 2019 Author Share Posted September 17, 2019 12 hours ago, dmsc said: Hi! I tough about extensions, but it is not that easy, because the parser is "compiled", so you can't add more words easily. Also, my planed mechanism is more like "modules", so the don't be at a fixed location, and the idea is that you could add new statements specifying an ASM code and expected parameters. Having a (simple) assembler is possible, and this is related to the above. Currently, adding assembly modules is already possible with the cross-compiler, and there you have the full CA65 assembler available, so the included assembler could be only for small routines. I don't think that would be useful, as all the arithmetic would be in 16bit, so the speed would be exactly the same. Why do you want that? Variables currently are not at a fixed location to allow the compiled code to be anywhere in RAM, an the interpreter optimizes the access so that it is already fast enough. For the interpreter, the slower part is reading from the instruction stream the variable address (as you have to read and increment the instruction pointer: "LDY #0 ; LDA (ptr),Y ; INC ptr ; BNE skip; INC ptr+1; skip: ", 14 cycles minimum). And in my current full cross-compiler (the one that compiles to 6502 code) variables are at fixed locations. My code does not touch those registers, this is the code of the editor startup: '------------------------------------- ' Initializes E: device PROC InitScreen close #0 : open #0, 12, 0, "E:" poke @@LMARGN, $00 poke @KEYREP, 3 ENDPROC The CLOSE/OPEN is there because after running an user program you don't know the state of E: anymore, so a re-initialization is needed. I though that 80 column drivers allowed to set different start values for the color registers. Have Fun! Perfectly fine with whatever modular approach you take, as long as memory-access penalties are kept at a minimum. I wanted (or wondered) about extracting down to the last drop of speed (I hoped it would be obvious from my question). I do wonder, however, if cross-compiler variables-allocation (and other optimizations) could also be incorporated into native 6502 compiler, running directly on Atari host. That's precisely the problem with current code: it does not even read existing (already-set) values of 709,710 locations (!) As an example, you may try on your own adding "SCRDEF=10,160,0,0" to your SDX autoexec.bat, in plain simple 40-col. Then invoke FastBasic editor, and watch what happens. I DO SEE it working well when loading RC_GR8.SYS and CON.SYS with a specific SCRDEF declaration during driver load. However, it does not really work for 40-cols (seems like defaulting to what is hard-coded on OS). Please, let me know what exact FB thread you refer to in the Programming forum, and I will ask this whole chain to be moved there. Cheers! Quote Link to comment Share on other sites More sharing options...
drpeter Posted September 17, 2019 Share Posted September 17, 2019 On 9/16/2019 at 9:24 PM, FifthPlayer said: FastBasic inserts a DLI at the very top of the display list that it manages and is for its own use Why not just do this in VBI code? Quote Link to comment Share on other sites More sharing options...
dmsc Posted September 18, 2019 Share Posted September 18, 2019 Hi! On 9/16/2019 at 5:24 PM, FifthPlayer said: Yes, I have an idea. Go with the second option (update the DLI vector at the conclusion of every DLI). To synchronize, FastBasic inserts a DLI at the very top of the display list that it manages and is for its own use. That DLI is used to start the chain of user-defined DLIs. To deal with dynamic updates to the DLI chain, you could add a mutex flag so that the DLI chain is temporarily disabled while the main program updates the DLI chain. But, how do you know that the first DLI should be called? From the perspective of the software, the problem with DLI is that all call the same handler, so you must differentiate on which line you are. So, this is why you need a VBI (or a screen kernel code) to synchronize. On 9/16/2019 at 5:24 PM, FifthPlayer said: This idea has some problems. 1) It isn't totally transparent to the developer 2) it might cause compatibility problems for programmers who provide their own bespoke display lists. With the mutex method I proposed, the system won't crash into hyperspace due to a partially updated DLI vector but 3) there could be temporary instances where DLIs don't fire because the interrrupt list is being updated. Abobe are not real problems, because current FastBasic code simply deactivates DLIs before setting the handler and then reactivates it. Have Fun! Quote Link to comment Share on other sites More sharing options...
dmsc Posted September 18, 2019 Share Posted September 18, 2019 Hi! 2 hours ago, drpeter said: Why not just do this in VBI code? Yes, this is an option. Why I'm reluctant? Because the facility should be transparent to the Basic program, and there should be the possibility of using the VBI for other purposes (like a music player), so the "DLI" stuff ideally should not interfere with that. My idea is to expand the language so that simple games could be written in it. My target should be this kind of logic: PMGRAPHICS 2 X0 = 128 X1 = 128 X2 = 128 X3 = 128 ' P/M data DATA PM0() BYTE = 2, 5, 12, 55, 170, 85 DATA PM1() BYTE = 45, 129, 34, 129, 85, 170 DATA PM2() BYTE = 255, 129, 129, 129, 255 DATA PM3() BYTE = 0, 126, 126, 126, 0 ' Clear P/M MSET PMADR(0), 128, 0 MSET PMADR(1), 128, 0 MSET PMADR(2), 128, 0 MSET PMADR(3), 128, 0 ' At line 10, set position and colors of player/missiles for objects 0 and 1 DLI 10, [ PMHPOS 0, X0 : PMHPOS 1, X0 : PMHPOS 2, X1 : PMHPOS 3, X1 : PMCOLOR 0, 14, 6 : PMCOLOR 1, 12, 10 : PMCOLOR 2, 9, 4 : PMCOLOR 3, 2, 2 ] ' At line 100, set position and colors of player/missiles for objects 2 and 3 DLI 100, [ PMHPOS 0, X2 : PMHPOS 1, X2 : PMHPOS 2, X3 : PMHPOS 3, X3 : PMCOLOR 0, 13, 8 : PMCOLOR 1, 12, 10 : PMCOLOR 2, 4, 4 : PMCOLOR 3, 1, 6 ] ' Set P/M MOVE ADR(PM0), PMADR(0) + 30, 6 MOVE ADR(PM1), PMADR(1) + 30, 6 MOVE ADR(PM2), PMADR(2) + 30, 6 MOVE ADR(PM3), PMADR(3) + 30, 6 MOVE ADR(PM0), PMADR(0) + 80, 6 MOVE ADR(PM1), PMADR(1) + 80, 6 MOVE ADR(PM2), PMADR(2) + 80, 6 MOVE ADR(PM3), PMADR(3) + 80, 6 DO PAUSE 0 ' Update values of positions, etc. X0 = X0 + 1 X1 = X1 + 2 X2 = X2 - 1 X3 = X3 - 2 ' ..... LOOP The result should be similar than the attached program (compiled with my current working version). Sadly, supporting thinks like "PMHPOS" or "PMCOLOR" inside DLI statements would require a much more complicated parser than the one available now. This is because the DLI is converted to assembly language at parsing time, and the parser lacks the ability to perform arithmetic of any kind (for example, to transform "PMHPOS 1, 3" to "POKE $D000 + 1, 3", or "PMCOLOR 3, 6, 8" to "POKE $D012 + 3, 6 * 16 + 8). Also, the parser does not know how to find the address of variables, needed for the "PMHPOS 1, X0". The way the parser works currently, all the arithmetic is transformed to be evaluated at runtime. Only the cross compiler is capable of simplifying constant expressions. Well, attached is the test program (.BAS and .XEX). pmtest1.asm pmtest1.xex 1 Quote Link to comment Share on other sites More sharing options...
dmsc Posted September 18, 2019 Share Posted September 18, 2019 Hi! 22 hours ago, Faicuai said: Perfectly fine with whatever modular approach you take, as long as memory-access penalties are kept at a minimum. I wanted (or wondered) about extracting down to the last drop of speed (I hoped it would be obvious from my question). I do wonder, however, if cross-compiler variables-allocation (and other optimizations) could also be incorporated into native 6502 compiler, running directly on Atari host. It could be done, yes, but it would be a lot of code. FastBasic language was not designed to be easily compiled to assembly (like Action, for example), so the compiler needs a lot of code to optimize it enough. And the current parser is too optimized to emit the current VM code - and to be as small as possible. A new, simpler language should be easier to make a full compiler. Thinks that should make a compiler easier are: Declaring variables. This allows variables to be of any type, including "byte" and "word", and makes the variable size known at compile time. Only allowing constant sized arrays, so you know the array address at compile time. Same with strings. Remove (or at least limit) FOR loops. FOR loops are difficult to compile (and in FastBasic are interpreted) because you can have the STEP size and limits as arbitrary expressions, so you need to create additional variables to store those, and select the correct comparison ("< LIMIT" or "> LIMIT") depending on the sign of the STEP. Mos of those can be dealt in a cross compiler because you can do full program analysis, but the Atari don't have enough memory for that. Old compilers used multiple passes to disk, but this is slow and complicated. 22 hours ago, Faicuai said: That's precisely the problem with current code: it does not even read existing (already-set) values of 709,710 locations (!) As an example, you may try on your own adding "SCRDEF=10,160,0,0" to your SDX autoexec.bat, in plain simple 40-col. Then invoke FastBasic editor, and watch what happens. I DO SEE it working well when loading RC_GR8.SYS and CON.SYS with a specific SCRDEF declaration during driver load. However, it does not really work for 40-cols (seems like defaulting to what is hard-coded on OS). But as I said, FastBasic IDE does not write any value to those locations, it does not know about them. And the SDX manual says "Setting SCRDEF alone does nothing. For it to take effect reload the COMMAND.COM e.g. with EXIT.", so this is why it does not work. A solution for you could be modifying the FastBasic editor, change lines 562 and blow to this: '------------------------------------- ' Initializes E: device PROC InitScreen close #0 : open #0, 12, 0, "E:" ' Set non standard background setcolor 1, 0, 10 setcolor 2, 10, 0 poke @@LMARGN, $00 poke @KEYREP, 3 ENDPROC This will make the IDE exactly 10 bytes bigger. 22 hours ago, Faicuai said: Please, let me know what exact FB thread you refer to in the Programming forum, and I will ask this whole chain to be moved there. Don't worry, here is ok. For new threads, the other forum is better. Have Fun! Quote Link to comment Share on other sites More sharing options...
FifthPlayer Posted September 18, 2019 Share Posted September 18, 2019 (edited) 3 hours ago, drpeter said: Why not just do this in VBI code? He said he didn't want to do that. I was trying to brainstorm an alternative. 1 hour ago, dmsc said: But, how do you know that the first DLI should be called? From the perspective of the software, the problem with DLI is that all call the same handler, so you must differentiate on which line you are. So, this is why you need a VBI (or a screen kernel code) to synchronize. Hmmm... I see what you're getting at. If FastBasic manages the display list on behalf of the programmer (a change from the current behavior), it would be able to implement my idea with a two-step approach. First, a display list with a single DLI at the top of the screen. Then in that DLI add the other DLIs to the display list (this could be done by swapping lists) and start the DLI chain. All that said, I think a VBI is a better idea for what you are trying to do. FastBasic could provide its own hook vector to allow a developer to provide a chunk of code that gets run from within the FastBasic VBI. Not as transparent as you might like, but it would still allow game developers to provide some assembly (or maybe even some basic code?) that gets run with the VBI. This is fun stuff to think about.... Stuff like display list interrrupts have heretofore been impossible to do solely in Basic, so this is an exciting development. Edited September 18, 2019 by FifthPlayer Quote Link to comment Share on other sites More sharing options...
dmsc Posted September 18, 2019 Share Posted September 18, 2019 2 hours ago, dmsc said: Well, attached is the test program (.BAS and .XEX). pmtest1.asm 9.04 kB · 2 downloads pmtest1.xex 1.45 kB · 4 downloads I noticed I did not attach the BAS source file, here it is. Have Fun! pmtest1.bas Quote Link to comment Share on other sites More sharing options...
vitoco Posted September 30, 2019 Share Posted September 30, 2019 Line 32 of pmtest1 says: DLI [ POKE @HPOSP0, PEEK($600) : POKE @HPOSP1, PEEK($600) : POKE @HPOSP2, PEEK($601) : POKE @HPOSP3, PEEK($601) : POKE @COLPM0, $D8 : POKE @COLPM1, $CA : POKE @COLPM2, $44 : POKE @COLPM3, $16 ] Why the "@"? It is not in the manual (yet?). Is it available only in the crosscompiler? Quote Link to comment Share on other sites More sharing options...
dmsc Posted October 1, 2019 Share Posted October 1, 2019 Hi! On 9/30/2019 at 10:44 AM, vitoco said: Line 32 of pmtest1 says: DLI [ POKE @HPOSP0, PEEK($600) : POKE @HPOSP1, PEEK($600) : POKE @HPOSP2, PEEK($601) : POKE @HPOSP3, PEEK($601) : POKE @COLPM0, $D8 : POKE @COLPM1, $CA : POKE @COLPM2, $44 : POKE @COLPM3, $16 ] Why the "@"? It is not in the manual (yet?). Is it available only in the crosscompiler? Yes, the "@" and "@@" symbols allows to include symbols from the assembler into the program, and it is only available in the cross compiler, see https://github.com/dmsc/fastbasic/blob/master/compiler/USAGE.md#linking-other-assembly-files Have Fun! Quote Link to comment Share on other sites More sharing options...
a8isa1 Posted October 2, 2019 Share Posted October 2, 2019 On 9/17/2019 at 11:44 PM, dmsc said: I noticed I did not attach the BAS source file, here it is. Have Fun! pmtest1.bas 1.52 kB · 5 downloads I received this error when compiling your example. ./fb pmtest1.bas pmtest1.asm Compiling 'pmtest1.bas' to assembler 'pmtest1.asm'. pmtest1.bas:32:4: parse error, expected: statement or variable assignment, integer variable, variable assignment DLI <--- HERE -->[ POKE @HPOSP0, PEEK($600) : POKE @HPOSP -SteveS Quote Link to comment Share on other sites More sharing options...
vitoco Posted October 2, 2019 Share Posted October 2, 2019 I guess that you aren't using the latest beta that includes DLI. It was shared in this post: Quote Link to comment Share on other sites More sharing options...
a8isa1 Posted October 2, 2019 Share Posted October 2, 2019 12 minutes ago, vitoco said: I guess that you aren't using the latest beta that includes DLI. ./fastbasic-fp -v reports the following: FastBasic 4.1-b3 - (c) 2019 dmsc -SteveS Quote Link to comment Share on other sites More sharing options...
dmsc Posted October 4, 2019 Share Posted October 4, 2019 Hi! On 10/2/2019 at 4:39 PM, a8isa1 said: ./fastbasic-fp -v reports the following: FastBasic 4.1-b3 - (c) 2019 dmsc -SteveS Yes, current beta version does not have DLI support yet, as I'm not yet convinced the current syntax is the best possible. Have Fun! Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.